CentOS 7.3 per Raspberry uscita il 14 dicembre

Dal 14/12 sono state rese disponibili le nuove immagini della CentOS 7 per Raspberry aggiornate alla versione 7.3. Ne ha dato annuncio Fabian Arrotin sulla mailing list dedicata al progetto. Le immagini sono reperibili alla URL:

http://mirror.centos.org/altarch/7/isos/armhfp/

insieme a quelle dedicate al Banana Pi, Cubieboard e Cubietrack.

Maggiori particolari reperibili alla URL:

https://wiki.centos.org/SpecialInterestGroup/AltArch/Arm32

Per chi avesse (come me) già installata la versione 7.2 uno [ yum update ] provocherà il passaggio alla nuova versione tramite aggiornamento di 191 pacchetti.

P.S.

Aggiungo come nota personale che è rimasto un fastidioso bug riguardante il servizio ntpd. Nonostante venga messo in stato “enabled” non parte automaticamente all’avvio del sistema. Al momento non ho trovato una soluzione, gli script di sistema sembrano a posto, per cui in caso di reboot del server farlo ripartire manualmente.

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.

 

 

Centos 7 per RPi2, lo sviluppo continua

E’ un po’ che non ne parlo, ma lo sviluppo della Centos 7 per RPi2 sta andando avanti. Sono reperibili immagini ready-to-use aggiornate all’indirizzo:

http://dev.centos.org/centos/7/isos/armhfp/

Allo stato attuale di sviluppo si tratta di un’immagine “minimal” adatta ad un uso headless della distribuzione, ed è perfino disponibile un’installazione dedicata al Raspberry Pi3. Ricordo che si accede con un utente root con password centos.

La mailing list di sviluppo (piuttosto attiva) per chi volesse contribuire anche solo al testing della distro si può attivare qui:

https://lists.centos.org/mailman/listinfo/arm-dev

 

 

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.

Raspberry PI2 – Prepariamolo per usare i GPIO

A differenza di Arduino il Raspberry Pi2 non è pronto per utilizzare sensori, attuatori e quant’altro sui 40 pin che sono installati sulla scheda. Bisogna installare alcune librerie in modo tale che realizzando codice, in C o in Python che sia, si possa accedere a questi collegamenti.

Molti utilizzano Raspbian forse perché esiste più documentazione su Internet, io preferisco le distribuzioni Linux della famiglia Redhat (RedHat, Centos, Fedora, RedSleeve) per cui farò riferimento per l’installazione alla Centos 7 che è attualmente in fase di sviluppo (vedi post precedenti) ma che però mi risulta del tutto usabile al momento attuale. Ipotizzo che con Fedora e RedSleeve 7 il procedimento sia del tutto simile, e quindi proverò, tempo permettendo, anche su quelle piattaforme.

(1) Innanzitutto da utente root installiamo alcuni pacchetti con Yum:

(2) Procuriamoci le librerie GPIO PYTHON per la gestione dei 40 pin del RPi2

Scarichiamo il pacchetto RPi.GPIO 0.5.11.tar.gz

In questo momento si tratta dell’ultima versione disponibile ma se dovesse uscire una versione più recente è sempre bene scaricare quella.

(3) Estraiamo il file scaricato con un comando tar

(4) Entriamo dentro la directory /root/RPi.GPIO-0.5.11

(5) Installiamo le librerie:

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

(6) Ora installiamo le librerie GPIO per il linguaggio C.

Controlliamo sempre che sia un rassicurante messaggio “All done.”.

Testiamo la libreria con il comando:

Abbiamo la versione della libreria appena installata e l’individuazione dell’hardware corrente. E’ stato trovato correttamente un RPI2.

Ancora meglio, chiediamo la mappatura dei PIN del nostro Raspberry con il comando:

Schermata 2015-07-26 alle 13.36.21

Questo schema è importantissimo. Stampiamocelo perché verrà usato come riferimento quando programmeremo in C. Nelle 2 colonne centrali sono mappati i PIN FISICI del RaspBerry Pi2 e ai lati ci sono le codifiche corrispondenti GPIO. Generalmente useremo la BCM per cui ad esempio collegando il PIN FISICO 11, questo sarà in effetti indicato nel software come GPIO 17, ma attenzione perché su alcune board di collegamento troveremo serigrafato GPIO0. Un po’ di sana confusione insomma, tanto per renderci la vita complicata. La vita del Maker è sicuramente più rilassata con Arduino. 🙂

(7) Installiamo le librerie per il processore BCM2835 per il linguaggio C

Tranquilli, sul RPI2 abbiamo il BCM2836 ma le ultime versioni (credo dalla 1.39) di questa libreria supportano anche il Pi2.

Andiamo sul sito http://www.airspayce.com/mikem/bcm2835/

e se possiamo leggiamoci tutta la pagina. E’ piena di informazioni interessanti per chi vuole approfondire. Inoltre NON SCARICHICHIAMO LA VERSIONE 1.42 proposta dalla pagina che ha un problema di compilazione con l’RPi2 (un modulo assembler dà errori) ma cambiamo la riga di download per prendere l’ultima versione, che attualmente è la 1.44. Procediamo poi con la compilazione e installazione.

Mi raccomando, controllare sempre che dopo l’esecuzione del ./configure sia andato tutto bene, senza messaggi di errore o di librerie mancanti.

All’interno della libreria c’è del codice C di esempio. Proviamo una compilazione per vedere se tutto è ok.

Consiglio di fare qualche prova con questi esempi anche per familiarizzare con le chiamate alle funzioni di libreria per confrontarle eventualmente con quelle usate da Arduino.

Centos 7 per Raspberry: test image

Prosegue l’ottimo lavoro da parte del team che sta preparando una distro Centos 7 per i Raspberry e per le schede Banana. E’ disponibile una immagine ready-to-use per RPi all’indirizzo: http://people.centos.org/hughesjr/armv7hl/rpi2/images/

Sono ancora in fase di test e per installare qualche pacchetto aggiuntivo ho dovuto marcare come disabled i repository segnalati in /etc/yum.repos.d/CentOS-Base.repo lasciando attivi gli altri, ma si vede già da adesso che verrà fuori un ottimo lavoro.

Di nuovo complimenti al team.

RedHat 7: troppo presto per usarla?

Il “problema”, se proprio vogliamo chiamarlo così, è stato l’introduzione di systemd per la gestione dei servizi al posto dell’ormai collaudatissimo initd. Systemd è sicuramente più evoluto del suo predecessore ma quando si parla di server ci si chiede sempre se è in grado di fornire la stessa stabilità che si aveva in precedenza. Parallelizzare i processi di boot per velocizzarlo, riavviare automaticamente servizi in caso di errore va tutto bene, ma non è certamente ciò di più importante che ci si può aspettare da un server. Non voglio poi nemmeno prendere in considerazione Gnome 3 perché, trattandosi quella dei server di un’installazione completamente testuale, l’ambiente grafico diventa in assoluto ininfluente.

Al momento in cui scrivo siamo arrivati anche ad avere, grazie agli aggiornamenti in linea, la versione 7.1. Di fatto però, parlo per esperienza personale, negli ambienti di sviluppo/test e a maggior ragione nelle macchine di produzione si continua ad usare la RedHat 6.x e non è difficile imbattersi ancora in ambienti RedHat 5.x. Questo discorso vale ovviamente anche per la distribuzione “gemella” CentOS che molto spesso per motivi di costi viene usata al posto della RedHat.

E’ pur vero che già da diverso tempo questa soluzione è stata implementata su Fedora, ma si tratta di un sistema operativo dedicato agli ambienti desktop e non è soggetto agli stessi criteri di affidabilità e agli uptime mostruosi richiesti ad un server di produzione. D’altro canto non credo che vedrò mai in un data center un’installazione Fedora 21 Server, ne sono piuttosto certo.

Journal, che ha sostituito il tradizionale system log: non sono solo io a storcere il naso, ho sentito altri pareri di colleghi sistemisti non proprio entusiasti. Ne parlo qui in un altro articolo a proposito della Fedora Remix sul Raspberry; ho rimesso subito la situazione così com’era.

Comunque sia, il cammino oramai sembra questo per cui tanto vale cominciare a predisporre qualche ambiente, magari virtuale, dove testare in parallelo alle release precedenti progetti in fase di collaudo. Per gli ambienti di produzione, si sa, le cose procedono molto più lentamente e si aspetta sempre che qualcuno abbia il coraggio di osare per poi vedere come funziona il tutto.

Due link di riferimento, in inglese,  per approfondire il tema:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/7.0_Release_Notes/index.html

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Migration_Planning_Guide/index.html