OpenSuse per Raspberry Pi3: perplessità

Una cosa mi ha lasciato molto perplesso: ho provato a fare in modo che la distribuzione partisse senza interfaccia grafica, per poterla utilizzare in modo molto più efficiente come server. Conosco la Suse da anni e so che da diverso tempo non gradisce in genere che si intervenga direttamente sui file di configurazione in /etc per cui ho utilizzato Yast (Gestione Servizi) per portare la distro a livello “Multi User”, ovvero con partenza in modo testuale senza desktop.

Alla ripartenza tutto appare bloccato, la console non dà segni di vita e il Raspberry non entra neanche in rete, negando un accesso remoto SSH che avrebbe aiutato ad investigare il problema. Come controprova ho creato un’altra microSD e fatto ripartire il sistema ho riprovato ad effettuare la stessa operazione da Yast, che dovrebbe risultare totalmente lecita (da una OpenSuse su piattaforma Intel effettua effettivamente il passaggio al runlevel Multi-User). Niente da fare, stesso risultato. Blocco completo della OpenSuse.

Non so se questa cosa sia riproducibile anche da altri che hanno installato questa distribuzione, ma nel mio caso mi dà senz’altro un’impressione di fragilità e instabilità intollerabile per l’utilizzo sul Raspberry. Francamente mi dispiace perché almeno su piattaforma Intel ritengo la OpenSuse una delle migliori distro in circolazione, ma sul Raspberry non me la sento proprio di utilizzarla in queste condizioni.

OpenSuse per Raspberry Pi3: un vero sistema operativo a 64 bit

E’ ora di mettere alla prova il nostro Raspberry Pi3 con un vero sistema operativo a 64 bit. Per ciò che mi risulta finora nessuno si è mosso tramite la Suse, che comunque in precedenza non mi aveva impressionato molto favorevolmente con la sua immagine per Raspberry. Da novembre 2016 Suse ha messo a disposizione sul suo sito la versione Enterprise (SLES) per Raspberry, ma trattandosi comunque di una release commerciale ha messo a disposizione degli utenti 1 anno di aggiornamenti gratuiti (previa registrazione) dopo di che si paga.

Quando l’ho letto mi è venuto un pò da ridere, pensavo a qualcuno che possa inserire un sistema Linux su un Raspberry per pagare una subscription annuale, cosa che su server professionali su piattaforme Xeon  ci può anche stare, ma su un Raspberry…… dai……… andiamo……… :)))

Comunque speravo che si muovesse anche la release OpenSuse, ed infatti dal mese di febbraio 2017 è stata aggiornata anche questa versione, completamente gratuita e quindi in linea con la filosofia di utilizzo di un Raspberry. Gli ultimi files immagine risalgono al 17 marzo, quindi tra l’altro sono stati aggiornati molto recentemente.

Innanzitutto dove scaricare le immagini “ready-to-use” per l’RPI3?

Da qui:

https://en.opensuse.org/HCL:Raspberry_Pi3

Consiglio di installare la Leap Image (quella più in alto nella pagina) e nel mio caso ho preferito quella con la grafica gestita da XFCE, semplice ma molto gradevole a vedersi.

Nel sito ci sono anche delle brevi istruzioni relative alla copia dell’immagine sul supporto microSD che utilizzeremo nel Raspberry quindi non mi dilungo. Alla partenza della distribuzione ci sarà un ridimensionamento automatico delle partizioni per cui non sarà necessario nessun adattamento manuale per poter utilizzare tutto lo spazio della microSD. Inoltre esiste solamente l’utente “root” a cui la Suse ha assegnato la password “linux”.

La scheda ethernet prenderà in DHCP un indirizzo sulla propria rete, quindi se è connesso un cavo  lan l’RPI3 sarà subito in rete, se abbiamo solo una connessione WI-FI……. non funzionerà. Ebbene sì, la scheda wi-fi non viene riconosciuta e bisogna modificare un file di configurazione per farla riconoscere e funzionare.

Apriamo il terminale.

Quindi entriamo nel file /etc/dracut.conf.d/raspberrypi_modules.conf con un editor come VI e togliamo dalla prima riga “sdhci_iproc” lasciando tutto il resto.

Lanciamo il comando < mkinitrd -f > e facciamo un reboot. Ora saremo in grado di sfogliare le reti wi-fi disponibili e collegarci alla nostra. Come dicevo l’aspetto del desktop è piuttosto gradevole.

Nei prossimi giorni cercherò di utilizzarla sia come ambiente desktop che server per vedere come si comporta rispetto alla “solita” Raspbian, tenendo conto che in questo caso si tratta di un vero ambiente a 64 bit.

 

Linux Mint 18 sul MacBook Bianco

macbook_biancoMi serviva un portatile dedicato per Linux. Solo Linux, senza virtualizzazione né doppia partenza con un altro sistema operativo. Perché non riciclare il mio vecchio MacBook bianco fine 2009? E’ fornito “solamente” di una CPU Intel Core 2 Duo a 2.26 GHz, ma col passare del tempo l’ho dotato di 8 Gb di RAM e di un paio di SSD (rispettivamente 240 Gb e 480 Gb) al posto dell’HDD a piatto rotante originale e dell’ormai (quasi) inutile masterizzatore DVD. Si difende quindi molto bene, anche se confrontato con un attuale portatile di fascia media. Non ha certo le prestazioni di una game machine, ma per un uso “office” va più che bene.

Ho deciso di installarci l’ultima Linux Mint attualmente disponibile, la 18 Cinnamon, probabilmente una delle scelte più indicate per un’installazione desktop ma soprattutto perfetta per chi, come me, non ama molto Unity e tantomeno le ultime GUI Gnome. Come dicevo prima, volevo che la macchina facesse girare solamente Linux in modo nativo e che soprattutto non avesse problemi con l’hardware Apple, principalmente la scheda di rete wi-fi e la telecamera iSight.

Prima di procedere, quando ancora c’e ancora Mac OS installato (ora si chiama di nuovo così a partire da Sierra) è bene fare in modo che il “Dong” classico dei Mac emesso alla partenza venga regolato ad un volume piuttosto basso perché dopo, sotto Linux non sarà più possibile variarne il volume.

L’installazione della Mint è semplice: inserito il DVD della distro in un lettore esterno, nel mio caso, è stato sufficiente far ripartire il Mac con il tasto Alt premuto ed aspettare che il Bios proponesse se partire con Mac OS, la partizione di ripristino oppure Windows (!). Sì, proprio Windows. Ovviamente si trattava del DVD esterno con su Linux, ma tant’è…..

Finita l’installazione, arrivato il momento di far ripartire la distro installata, il Mac si bloccava. Ho dovuto spegnere e riaccendere il portatile e la Mint è partita correttamente. Chiaro però che c’era un problema a fare un “warm reboot” con Linux (reboot da GUI, da terminale che sia). Il problema si presentava molto fastidioso, perché tra l’altro impediva di riavviare in qualche modo da remoto il portatile. Probabilmente qualcosa che non andava tra la funzione del kernel in “reboot.c” e il Mac stesso. Fortunatamente il problema è risolvibile e richiede l’inserimento di un parametro nel file di configurazione di GRUB, il boot manager di Linux. Vediamo come.

Entriamo da terminale nella directory /etc/default ed apriamo con l’editor “vi” il file “grub”

ora modifichiamo la riga contenente GRUB_CMDLINE_LINUX_DEFAULT in modo che contenga:

aggiorniamo GRUB con il comando

e saremo in grado di far ripartire correttamente Linux. Devo dire che questo è un problema lamentato da molti che hanno deciso di togliere Mac OS dal portatile Apple a favore di una distro Linux (mi risulta che anche Linus Torvalds lo abbia fatto sul suo Mac Book Air 🙂 ) e che in alcuni casi viene riferito che il problema sia stato risolto con il parametro “reboot=bios”. Non è comunque il mio caso con questo modello di MacBook.

Per il resto sono piuttosto soddisfatto. I tasti relativi alla luminosità dello schermo funzionano, quelli di regolazione volume idem, la scheda di rete wi-fi ha funzionato al primo colpo e così ha fatto anche la iSight con Skype. Rimane da vedere quanto sarà ottimizzato il consumo della batteria, che dopo 6.5 anni di onorato servizio durava sotto Mac OS ancora circa 3 ore e mezza. Vedremo.

Non mi risulta che Linux, nonostante la Mint utilizzi un kernel molto recente, gestisca in automatico il trim degli SSD (ma potrei sbagliarmi) quindi nel dubbio provvederò a mettere nella crontab utente le chiamate periodiche all’eseguibile “fstrim”.

Mi manca il trascinamento a 3 dita delle finestre presente in Mac OS nel menu Accessibilità che trovo comodissimo quando si usa solo il trackpad; quindi è necessario tenere il dito schiacciato sul pad e muovere per spostare una finestra sullo schermo. Questo mi dà un pò fastidio, ma non è un problema insormontabile.

Inutile dire che con la IDE di Arduino tutto funziona perfettamente 🙂

 

Nel caso si voglia installare una distribuzione più adatta ad agire come server, una RedHat o CentOS 6.x, la versione di Grub è differente (la 1, più vecchia di quella usata dalla Mint) per cui lo stesso comando va inserito nel file /etc/grub.conf in tutte le voci di menu (come da figura). Non esiste un comando update-grub quindi va fatto il poweroff del notebook per poi ripartire. Quando si aggiorna il kernel e quindi viene creata una nuova voce nel menu va aggiunto di nuovo l’opzione reboot=pci.

centos

RedHat / CentOS 7 – Far ripartire automaticamente un processo dopo un crash

Ci sono dei processi su un server che abbiamo necessità siano sempre up, ovvero funzionanti. Può accadere che a causa di un crash questi cadano e purtroppo, tranne alcuni casi, siamo costretti a controllare manualmente e  a intervenire per riavviarli da console. Vedremo come fare in modo da impostare un processo in modo tale che in caso di caduta riparta da solo in automatico. Va da sé che se il nostro processo ha delle problematiche tali che cade in continuazione anche se riavviato dobbiamo capire perché questo succede ed eliminare la causa del malfunzionamento. Ma per fortuna la maggior parte delle volte un processo può essere fatto ripartire senza problemi. Farò l’esempio del demone “ntpd” (l’aggiornamento dell’ora esatta) perché mi capita, specialmente sui Raspberry, di trovarlo qualche volta “caduto” misteriosamente.

Premetto che questa procedura funziona esclusivamente sulle distribuzioni di Linux che utilizzano “systemd” come controllore di processi, quindi Raspbian Jessie e Centos 7 nel caso dei Raspberry. Nelle distro precedenti, basate su “initd” si interveniva all’interno del file /etc/inittab o con l’upstart e non mi dilungherò su queste procedure.

Innanzitutto avremo fatto in modo che il nostro servizio sia in grado di ripartire automaticamente al reboot del server, tramite il comando:

Fatto questo entreremo nella directory sotto indicata e cercheremo il file .service associato al nostro servizio:

Eccolo qui, evidenziato (ntpd.service). Apriamo un editor e aggiungiamo nella sezione Service la riga contenente Restart=always

Salviamo il file, ricarichiamo i demoni e facciamo ripartire il nostro servizio.

A questo punto per testare se effettivamente funziona la ripartenza automatica NON useremo un comando systemctl stop, che essendo uno stop volontario non causerà una ripartenza ma dovremo fare un kill del processo, simulando un crash. Facciamo ad esempio un systemctl status ntpd e leggiamo il Main PID del processo. Supponendo sia 8382 diamo poi un comando:

Chiedendo di nuovo lo status del processo vedremo che è stato immediatamente fatto ripartire, ovvero lo troveremo in stato active running.

 

 

Arduino IDE e OS X

Sento ancora parlare di problemi di riconoscimento delle schede da parte di computer Apple con la IDE di Arduino, anche dopo aver disabilitato le protezioni messe in atto dalla casa di Cupertino da Yosemite in poi. Per mia esperienza personale devo dire che su 3 portatili che uso non ho avuto problemi provando a disabilitare la S.I.P., mentre il mio glorioso iMac fine 2009 rivitalizzato da diverso tempo con 12Gb di Ram e un disco SSD si dimostra un po’ capriccioso perfino nel riconoscere al volo le schede originali Arduino, figuriamoci i cloni e le ESP8266.

Ripeto che la soluzione migliore a mio parere rimane sempre e comunque quella di lasciare la S.I.P. (System Integrity Protection) di Apple attivata ed installare una Virtual Machine Linux sul Mac. Io personalmente utilizzo la Linux Mint su VMware Fusion,

mint_arduinoma si può tranquillamente utilizzare qualsiasi derivata Ubuntu. Ricordarsi sempre di aggiungere l’utente usato al gruppo “dialout” per garantirgli l’accesso alle porte seriali/USB virtuali create dalle schede. Come ambiente per le VM va benissimo il gratuito Virtualbox, ma ancora meglio VMware Fusion se già lo abbiamo acquistato. Altra cosa da non dimenticare una volta fatta partire la Virtual Machine è di “passare” il controllo dell’interfaccia USB a cui sono collegate le schede dall’host Apple alla VM tramite il menu “Macchina Virtuale”, altrimenti non verrà visto niente. In caso di inserzione successiva alla partenza della VM del cavo USB sarà lo stesso OS X a chiedere a chi si vuole assegnare la periferica.

Un’altra cosa molto comoda secondo me è depositare la cartella degli Sketch su una directory residente in un qualsiasi Cloud, in modo tale da avere codice e soprattutto librerie utente sempre sincronizzate in caso di accesso da più PC, qualsiasi sia il sistema operativo usato. Ovviamente questo tipo di approccio richiede l’installazione di un client per il nostro cloud che generi una cartella sincronizzata locale; l’accesso web non basta.

 

Aggiornamento manuale di OwnCloud Server

E’ uscita la nuova versione di Owncloud, la 9.0.0. Owncloud è uno dei più utilizzati ed apprezzati Cloud server, accessibile anche a piccoli computer come i Raspberry e schede simili. Le novità sono piuttosto interessanti (https://owncloud.org/blog/owncloud-server-9-0-released/) per cui ho deciso di aggiornare la versione 8.2 che già utilizzo per uso personale. Per quanto riguarda i Server che amministro nell’Azienda in cui lavoro ho deciso di aspettare ancora che si definisca bene il fatto che le applicazioni Calendario e Contatti sono considerate “deprecate” e quindi sostituite da nuove componenti. A riguardo si possono trovare notizie sul Forum del sito ufficiale, per chi invece vuole procedere ugualmente illustrerò la procedura che ho eseguito per aggiornare il mio server casalingo alla versione 9.

Innanzitutto premetto che trattandosi di una procedura manuale è richiesta una certa confidenza con la shell linux e con i suoi comandi di base, inoltre è saggio provvedere al backup della directory attuale del prodotto (e dei dati, se contenuti nello stesso path) prima di procedere, per ripristinare eventualmente la situazione precedente se qualcosa fosse “andato storto”.

La procedura verrà eseguita da utente “root”, attuabile su ambienti Debian (ma anche Raspbian o Bananian) o Centos / Redhat ( e quindi anche Centos 7 per arm e RedSleeve).

Questa procedura suppone che il server Owncloud sia installato nella directory

/var/www/html/owncloud

sia nel caso si tratti di una distribuzione di tipo Debian che Centos/RedHat e che sia stato effettuato un backup della directory indicata sopra.

1 . Scaricare dal sito Owncloud il pacchetto owncloud-9.0.0.tar.bz2 e copiarlo dentro la directory /var/www/html. NON DECOMPRIMERLO ORA.

2 . Entrare nella directory /var/www/html/owncloud/config ed editare il file config.php inserendo la direttiva

oppure modificarla, se già esistente, da “false” a true”. Salvare il file e riavviare il server apache.

DEBIAN 7 o CENTOS/REDHAT 5/6 versioni (INITD)

DEBIAN 8 o CENTOS/REDHAT 7 versioni (SYSTEMD)

Questo metterà il server in “maintenance mode” per tutti gli utenti collegati in modo tale che non potranno apportare modifiche ai dati, ma soprattutto manterrà la nuova versione in questo stato quando la metteremo in linea fino a che non avremo completato l’upgrade.

Quando saremo sicuri che nessuno è più collegato al cloud fermiamo il web server. Ripetiamo il comando dato sopra sostituendo il comando “stop” a “restart”.

 

3. Rinominiamo l’attuale installazione di Owncloud in Owncloud_old.

 

4. Ora possiamo decomprimere la nuova versione da dentro la directory /var/www/html

questo creerà la nuova cartella “owncloud” contenente la nuova versione.

 

5. Entriamo nella vecchia installazione e copiamo il file config.php nella nuova.

 

6. Ora, se abbiamo mantenuto i dati dentro la cartella owncloud/data copiamoli dentro l’installazione nuova, se abbiamo configurato un path esterno saltiamo questo step, ci penserà il file config.php appena copiato a referenziarli anche nella nuova versione.

e attendiamo la fine della copia, che può impiegare svariati minuti a seconda dei dati memorizzati. Stiamo facendo una copia quindi va da sé che nella partizione dobbiamo avere spazio almeno per il doppio dello spazio cubato dai dati del cloud, altrimenti dovremo provvedere ad eseguire un comando ‘mv’, ovvero move. Il comando move si presenta più rischioso in quanto se lo spostamento non andasse per qualche motivo a buon fine non avremmo più i dati (o parte dei dati) nella posizione originale.

A causa di questo fatto, in previsione di upgrade di Owncloud è sempre bene alla prima installazione portare fuori dalla directory del prodotto la directory dei dati configurando il path nel file “config.php”

 

7. Se stiamo usando applicazioni di terze parti situate in owncloud_old/apps copiarle nella nuova installazione controllando attentamente i diritti dei file.

 

8. Abbiamo agito da utente root: ora dobbiamo assegnare alla cartella “owncloud” e a tutto ciò che vi è sotto la proprietà dell’utente “apache.apache” su Centos/Redhat o “www-data.www-data” su Debian

DEBIAN

CENTOS / REDHAT

 

9. Avviamo il web server. In virtù del file “config.php” copiato in precedenza il nuovo server si avvierà in “maintenance mode”.

DEBIAN 7 o CENTOS/REDHAT 5/6 versioni (INITD)

DEBIAN 8 o CENTOS/REDHAT 7 versioni (SYSTEMD)

 

10. Lanciamo la procedura finale di upgrade. Può volerci anche molto a seconda dei dati presenti sul cloud.

DEBIAN

CENTOS / REDHAT

 

Se tutto è andato bene avremo un output di questo tipo:

 

11. Entriamo in /var/www/html/owncloud/config/config.php e rimettiamo a false la direttiva del maintenance mode. Per ultimo riavviamo il web server con un comando start come descritto prima.

Ora possiamo controllare le connessioni e verificare che tutto sia andato bene.

 

Centos 7 – Togliere firewalld e ripristinare IpTables

Tra le varie novità portate dalla Centos/RedHat 7 c’è anche il nuovo firewall, che si chiama appunto firewalld. La gestione è molto differente dal classico IpTables, per cui potrebbe verificarsi la necessità (o la voglia) di disabilitarlo per gestire il firewall nella maniera classica. Ecco i comandi:

Da questo momento in poi potremo riprendere a gestire “alla vecchia maniera” il nostro firewall.

Proviamo iptables -L per vedere come sono sistemate di default le chain e non dimentichiamoci che se non abbiamo ripristinato il “vecchio” /var/log/messages qualora dovessimo loggare i pacchetti droppati dovremo controllare il log di sistema con il comando journalctl -f

Questa procedura è applicabile anche alla Centos 7 per processori arm e naturalmente a Fedora e RedSleeve 7.

RedSleeve 7.1 – L’annuncio ufficiale

RedSleeve7

Ho visto solo da qualche giorno che il 18 luglio sul sito ufficiale della RedSleeve è stato pubblicato un annuncio riguardante l’uscita della RedSleeve 7.1. In effetti l’immagine è rimasta sempre quella pubblicata a Maggio del 2015, quindi gli aggiornamenti risiedono nei pacchetti contenuti nei repository ufficiali. L’ho installata su una nuova microSD per testarla di nuovo e in modo più approfondito. Nel mio caso si tratta di quella realizzata per il Raspberry Pi2. Ricordo che l’utente root ha come password preimpostata “password”. Appena fatta partire ho effettuato alcune operazioni preliminari che descrivo sinteticamente, senza entrare nei particolari per il momento. Il problema più grosso sono i repository di Yum che non esistono più e vanno sostituiti con i nuovi.

  1. Ridefinito la password di root con una più sicura.
  2. Cambiato il nome host in (/etc/hostname).
  3. Aggiunte alcune variazioni nel file /boot/config.txt assegnando il mimimo possibile di memoria alla GPU e aggiungendo lo schema di clocking del RPi2

4. Tolto il NetworkManager che risulta attivo (stop e disable) e ho lasciato gestire la lan wired dall’ifcfg-eth0. Tutto OK.

5. Tra i (pochi) servizi attivi ho rimosso Postfix (stop e disable) che se non utilizzato va tolto da un minimal server.

6. Verificato che Selinux fosse disabilitato e che (per il momento) il firewall (firewalld) fosse spento.

7. Espansa la partizione di root (/) alla capacità massima della scheda, in questo caso 64Gb.

8. I repository di YUM nella directory (/etc/yum.repos.d) non funzionano. Ho rinominato quelli presenti in .old e ho provveduto a creare un nuovo RedSleeve.repo contenente:

Il comando < yum upgrade > li trova correttamente, dopo di che lo < yum update > aggiorna  una certa quantità di pacchetti.

A questo punto inizierò la fase di test, controllando varie tipologie di utilizzo, comprese l’installazione e l’uso delle librerie GPIO che per ora vengono giudicate affidabili (a ragione) solo in ambiente Raspbian. Spero che si dimostri una distro affidabile, visto che la Centos 7 mi risulta ancora in fase Alpha e ci vorrà  svariato tempo prima di essere completata.

 

 

 

Fedora 22 (intel): non ci siamo….

L’ho provata sulla piattaforma di virtualizzazione VMware Fusion. Purtroppo il login manager gdm utilizza di default Wayland, e ho rilevato che puntualmente dopo qualche minuto che si è fatta la login Fedora “butta fuori” l’utente e torna  alla schermata di login. Come se non bastasse , essendo costretti a rifare di nuovo la login, e la cosa già sarebbe grave, troviamo il processo Xwayland che occupa stabilmente la cpu al 100%. Ora: passi il kernel 4, passi il nuovo gestore dei pacchetti dnf al posto di Yum, ma se una cosa non è stabile non mettetela, e per di più installata di default. Non ci siamo, non ci siamo proprio…… peggio di Windows!

Questo problema l’ho rilevato sulla versione principale che utilizza come gestore grafico Gnome. Provando le cosiddette “spin”, come quella Xfce ed anche Mate per fortuna tutto questo non succede. Oramai Gnome nella mia lista di preferenze dei Desktop Manager è veramente scivolata all’ultimo posto un po’ in tutte le distribuzioni.