PHP 7: rilascio in arrivo

PHP 7

Il PHP 7 è in arrivo. Il rilascio è stato pianificato per ottobre 2015 e già nel corso dell’estate dovremmo vedere le prime RC.

Grandi novità in vista, perciò, come in ogni occasione di nuova major version. L’ultima volta era stato nel lontanissimo luglio del 2004, con l’uscita della 5.0 e l’avvio di una consistente avventura OOP.
E gli effetti si sono visti: la programmazione a oggetti è diventata irrinunciabile, il nuovo modo di programmare ha scatenato la cascata di pattern e framework che oggi conosciamo e la condivisione del codice ha prodotto maturazioni nella comunità degli sviluppatori che all’epoca non erano nemmeno immaginabili.

Sarà difficile anche questa volta fare una previsione sugli effetti “di costume” che produrrà il nuovo rilascio. Il salto in avanti certamente ci sarà e quello che possiamo fare adesso è iniziare ad annusare le novità.

Performance

PHP Next-Gen (PHPNG) è il nome che è stato dato alla reingegnerizzazione dello Zend Engine, che anima l’esecuzione dei nostri programmi. I risultati sembrano stupefacenti, come annuncia lo stesso Zeev Suraski.

L’obiettivo, in casa Zend, era almeno raggiungere le performance ottenute con HHVM in casa Facebook. Obiettivo raggiunto, a quanto pare, che raddoppia, triplica, quadruplica le velocità di esecuzione, a seconda dei benchmark e dei test nel mondo reale.

Real word apps - Benchmark

Real word apps – Benchmark

I valori in campo sembrano annunciare una vera e propria rivoluzione. Oltre al tempo di esecuzione in senso stretto, logiche di compilazione JIT (Just In Time) uso intensivo di OPCache e parallelismo estremo garantiranno la possibilità di sopportare carichi di lavoro elevatissimi. La sfida proposta dall’hacking di casa Zuckemberg è raccolta, e con successo.

[ Rfc: PHPNG (next generation) #Performance Evaluation ]

Novità del linguaggio

Meno impressionanti, invece, sembrano essere le novità del linguaggio. Alcune vecchie funzionalità vengono definitvamente rimosse, mentre vengono aggiunte nuove raffinatezze che però, ad una prima occhiata, non sembrano cambiare il nostro modo di programmare.

Vediamo in dettaglio qualche novità.

Dichiarazione del tipo restituito

L’amministrazione dei tipi sembra essere la novità più importante. Garantirà maggiore robustezza al codice,nuova potenza alle interfacce e miglior chiarezza documentale rispetto al semplice commento testuale.

Sarà possibile definire a priori il tipo di variabile restituito dalle funzioni.

Il vincolo sarà stringente: le funzioni così definite non potranno più restituire tipi diversi a seconda degli argomenti in ingresso. In altre parole, una volta definito il tipo restituito non avremo più quei casi che siamo abituati a commentare come  mixed  o array|string . In particolare, non sarà possibile nemmeno che il valore restituito sia null , obbligandoci a ricorrere a valori che ricadono in false o, meglio ancora, alle eccezioni.

La forza del vincolo sarà più o meno stringente, a seconda della scelta dello sviluppatore. Nel prossimo paragrafo si capirà perché.

[ Rfc: Return Type Declarations ]

Type hinting per gli scalari

Si direbbe l’argomento più controverso, che ha richiesto più di una Rfc. La soluzione è stata affidare questa opportunità ad una dichiarazione preliminare, per lasciar decidere allo sviluppatore se farne uso o meno. Ma vediamo di che si tratta.

Siamo abituati a richiedere che gli argomenti di una funzione siano oggetti di una certa classe:

Questa opportunità funziona solo con argomenti che siano oggetti di una certa classe, con gli array (PHP >= 5.1) o con lo “pseudotipo” callable (PHP >= 5.4).

Il PHP 7 introduce una nuova dichiarazione che ha effetto solo per il file corrente, che consente di definire il tipo degli argomenti anche per i tipi scalari:

La declare(strict_type = 1); deve essere inserita nel file dove avviene la chiamata alla funzione, non in quello in cui la funzione viene definita. Questo consente di fare liberamente hinting dei tipi in fase di preparazione, affidando la scelta al momento dell’assemblaggio dell’applicazione.

Si osservi che declare(strict_types=1); ha effetto anche sul tipo restituito, rendendone stringente l’indicazione. Se si sceglie di usarla, la conversione di tipi in uscita dalle funzioni non sarà più ammessa e cadremo in un «Catchable fatal error».

[ Rfc: Scalar Type Declarations ]

Operatore di confronto combinato (spaceship operator)

Il nuovo operatore è  <=>  ed è un operatore di confronto ternario, che non restituisce il tradizionale booleano (vero o falso), ma una terna di possibilità (maggiore, minore e uguale) rappresentate da 1 ,  -1  e 0  .

A cosa può servire? Un buon esempio sono i casi di ordinamento, in cui “maggiore” e “minore” non devono essere trattati come se fossero “uguale”.

[ Rfc: Combined Comparison (Spaceship) Operator ]

Operatore di fusione

Il nuovo operatore è ?? e serve a sbrogliare la seccatura di assegnare un valore di default a variabili non definite.
Tradizionalmente:

Il nuovo operatore, invece, consente di scrivere una forma compatta simile all’ultima, senza errori:

[ Rfc: Null Coalesce Operator ]

Funzionalità rimosse o deprecate

Il processo di rimozione di alcune funzionalità fa un passo in avanti.

Genereranno un errore E_DEPRECATED:

  • I costruttori in stile PHP4, definiti con il nome stesso della classe e non con __construct() ; [ Rfc ]

Verranno del tutto rimossi:

  • L’estensione mysql ; attenzione quindi a quei vecchi programmi che usavano mysql_connect() e le altre funzioni associate: non funzioneranno più; si dovrà usare, invece, PDO_mysql ; [Rfc ]
  • Gli “asp tag” ( <% e %> ) e le forme <script language="php"> ; sopravvivono invece, per quanto sconsigliate, le forme abbreviate  <?<?= ; [ Rfc ]

Conclusioni

Non sembra che lo sforzo degli sviluppatori per passare al PHP 7 sarà particolarmente gravoso. Le nuovi gestioni dei tipi introdurranno un maggiore rigore che potrà essere apprezzato. Ma la scelta, come si è visto, è stata morbida e raramente pratiche più vecchie o approssimative porteranno a dei fallimenti.

Gioie e dolori di sempre, quindi, con un linguaggio che mantiene la caratteristica di essere di facile apprendimento per il principiante, ma che nasconde la trappola di lasciare che pratiche non eccellenti continuino a girare nelle CPU dei webserver di tutto il mondo.

Difficile, invece, immaginare dove porterà il nuovo scenario delle performance, che si accompagnerà naturalmente alle nuove potenze di calcolo dell’hardware e alle sempre nuove tecnologie di cluster. Il linguaggio, insomma, sarà adatto ad imprese possenti ed è evidente che Zend, in questa operazione, si rivolge ai colossi di Internet, offrendo l’opportunità di sostenere carichi di lavoro pazzeschi a costi tanto ridotti quanto sono ridotti i tempi di esecuzione.

Domotica: il riscaldamento controllato via web, con Raspberry PI – Parte 2

Il Raspberry Pi e il relay

Il Raspberry PI e il relay mantengono le promesse.

Scendiamo nei dettagli dei due apparati concentrandoci su come domarli. Niente di particolarmente complesso.

Il Raspberry PI è nostro amico sin da subito.

Il relay è un po’ strano per chi non ha mai gestito una comunicazione su porta seriale a bassissimo livello, ma funziona egregiamente con qualche magia del mestiere.

[Continua da http://sergiovaccaro.it/domotica-il-riscaldamento-controllato-via-web-con-raspberry-pi-1/]

La consegna

Entrambi gli strumenti sono arrivati dopo quattro o cinque giorni dal giorno dell’ordine.

La confezione del Raspberry PI è divertente, ricorda una scatola di medicine e promette di far bene alla salute.

La scatola del Raspberry PI

La scatola del Raspberry PI

 Il Raspberry PI

Non c’è molto da dire sul Raspberry PI. Non solo perché è stato già scritto moltissimo, ma anche perché non riserva sorprese rispetto a quanto desideriamo.

Il Raspberry PI è un computer a tutti gli effetti, si accende inserendo l’alimentazione e si spegne con un normale shutdown -h now. È quasi stupefacente collegare un oggetto da 3 pollici e mezzo al nostro gigantesco monitor da 27 pollici. O forse no, non ce ne stupiamo più.

Nel mio carrello ho inserito anche la scheda Wifi – che funziona perfettamente, il box trasparente e una scheda SD con sistema già installato, l’offerta era conveniente e non volevo perder tempo con l’installazione.

Prima esecuzione

Il primo avvio va eseguito con monitor e tastiera. Non parte un sistema operativo, ma uno strumento di installazione.

Non me l’aspettavo, ma nella scheda ci sono sei sistemi operativi.

Sistemi operativi del Raspberry PI

Sistemi operativi del Raspberry PI

Ho scelto Raspbian, derivato dalla robusta, ben nota, vecchia, cara, accogliente Debian. Anche Arch e RiscOS PI sono stati una tentazione, così come forte è stata la tentazione di metterci la solita Gentoo. Ma ho scelto di non distrarmi e andare sulla strada più diffusa e sperimentata: Raspbian, appunto.

Raspbian

L’installazione va da sé.
Conviene tenere il monitor e la tastiera finché non abbiamo configurato la rete e le utenze.

Per tutto il resto, è Debian e giochiamo in casa.
Potrei chiudere qua, visto che di guide Debian ce ne sono un mucchio e non sono stati necessari accorgimenti speciali o inaspettati.

A mia memoria, invece, faccio un rapidissimo riepilogo di come ho impugnato il sistema. Chi conosce Debian salterà al paragrafo successivo.

La filosofia di Raspbian è quella di Ubuntu: niente password di root ma un utente chiamato pi, con password – ma guarda – raspberry.  Io ho scelto le solite manovre e ho preso la root con:

 

Poi ho trafficato con  apt per installare i tool necessari o preferiti, ho fatto un giretto per la /etc, ho configurato le reti, ho creato utenze e gruppi.

Ho installato vim, gkrellmd, rdiff-backup, syslog-ng (solo perché lo conosco meglio),  vixie-cronapache2, php5. E ho trovato utile per comprendere e domare la porta seriale che verrà emulata dal relay, installare setserial.

Per la wlan0 ho dovuto trafficare con wpa_supplicant. Poiché la configurazione non mi entra mai in testa, la riporto qua:

 

La configurazione della rete che ho adottato è “quasi” quella di default, con l’aggiunta – appunto – della gestione di wpa_supplicant :

 

Poi ho fatto fuori quell’utenza standard e ho preparato le mie preferite: una che si chiama relay, per le operazioni automatiche, e una che si chiama sergio, per me.

Infine ho organizzato l’avvio dei servizi secondo il mio piacere.

In tutti questi modi, ho cucinato quanto basta perché il sistema fosse mio e pronto per andare nella caldaia.

Il relay

Con il relay c’è stato da divertirsi di più.

I connettori

Vale la pena di guardare meglio la fotografia per comprendere NC, C e NO.

KMtronic USB Relay Controller

KMtronic USB Relay Controller

L’idea è che uno dei i due poli del circuito da governare deve essere connesso a C, mentre l’altro a NC o NO, a seconda della preferenza.

NC, infatti, sta per Normally Connected, mentre NO sta per Normally Open.

Quindi, a relay off, e quindi anche quando non è governato, il connettore NC è connesso a C, mentre NO è staccato. Quando il relay è on, con la spia status accesa, NO è connesso a C e NC è disconnesso.

Ho scelto di connettere il cavo del termostato a NC, per rendere reversibile l’installazione. Se il Raspberry PI è spento, la caldaia sarà governata dal solito termostato.

Questa scelta, quindi, produrrà qualche leggera emicrania: quando il relay è acceso, cioè è in stato 1, il connettore NC è aperto e la caldaia è spenta, cioè è in stato 0. E viceversa.

Dunque so come collegare in serie il relay (inizialmente spento, 0) e il termostato.

Non resta che governarlo.

Il programma di KMTronic

KMTronic fornisce un programma per controllare l’USB relay, con codice sorgente.

È scritto in C, funziona a dovere ed è perfettamente descritto nella pagina di presentazione. Ha il solo difetto di rispondere un po’ lentamente quando si interroga il relay per conoscerne lo stato.

Chi ha in mente usi manuali si troverà perfettamente a proprio agio.

Prima che KMTronic pubblicasse quel programma, però, avevo già adottato una soluzione tutta bash. Inaspettatamente, i miei script ai miei occhi funzionano meglio, perché pensando al web ho bisogno di più velocità.

Perciò propongo ancora la mia soluzione. Un po’ per le prestazioni e un po’ perché è stato un esercizio interessante.
Esercizio o no, io continuo ad usarla.

Alternativa: governare il relay con bash

Quando ho scoperto il programma KMTronic mi sono sentito sollevato, con bash mi ero avventurato in un territorio a me sconosciuto e ho pensato di affidarmi subito al loro software.

Ma poi me ne sono pentito.

Quando si richiede lo stato del relay, il programma ha due difetti: emette un output troppo verboso e risponde lentamente.

Quello che io desidero infatti è un programma che risponda con un semplice 1  o 0, il più rapidamente possibile, pensato per essere usato come API verso il relay da parte di altri programmi.

Modificare il programma in C per alleggerire l’output è abbastanza semplice, mentre non mi è chiara la ragione del ritardo, probabilmente nascosta agli occhi della mia conoscenza scolastica del C all’interno di  termios.h.

Insomma, per farla breve, preferisco ancora i miei strumenti bash.

Comunicare con la porta

Per iniziare, la porta seriale emulata dal relay è /dev/ttyUSB0 (o un numero diverso).

Possiamo inviare segnali a quella porta con un semplice echo:

 

L’opzione -e è utile, anzi fondamentale, perché abilita l’interpretazione dell’escaping fatto con il backslash \. Ci servirà.

Naturalmente il relay non reagirà al saluto.

Analogamente, possiamo leggere le comunicazioni in arrivo dal relay con un semplice cat:

 

In realtà eseguendo questo comando non  succede un bel niente e dovremo chiudere con un CTRL+C. Certo, il motivo è che il relay non ha nulla da dire, proprio ora. Ma il motivo è anche che il relay non invia né segnali di EOL e nemmeno di EOF per indicare che il suo eventuale messaggio è finito. Dovremo lavorarci su.

I segnali del relay

Per iniziare, è necessario configurare la comunicazione.

Essendo molto semplice, il relay non invia segnali di EOL e questo non è il comportamento di default delle comunicazioni seriali. Dovremo perciò informare il kernel di questa caratteristica. Inoltre dovremo impostare una velocità di comunicazione che KMTronic stabilisce a 9600 baude. Entrambe le istruzioni si eseguono con un unico comando.

 

A questo punto il relay comprenderà tre messaggi:

 

Questo segnale accende il relay e la spia rossa si illumina. Poiché stato usato il connettore NC, questo vuol dire che la caldaia viene spenta.

 

Questo segnale spegne il relay e la spia rossa si attenua.  Poiché è stato usato il connettore NC, questo vuol dire che la caldaia viene accesa.

Fin qui è facile. Più complicato è richiedere lo stato, anzi è complicato leggere la risposta.

 

Questo segnale invia al relay una richiesta di stato. La risposta, completamente asincrona, è un messaggio del tipo:

 

Con xx  uguale a 00  (relay spento, caldaia accesa) o 01  (relay acceso, caldaia spenta).

Il lavoraccio è leggere quella risposta.

La risposta, infatti, viene inviata in modo completamente asincrono. Se eseguissimo la richiesta di stato e subito dopo leggessimo la risposta quasi certamente non troveremmo un bel niente. La risposta arriva infatti troppo in fretta.

L’unica soluzione è usare due programmi: uno in background che legge la risposta e che viene eseguito per primo, mettendosi in attesa; uno in foreground che invia la richiesta subito dopo, mentre quello in background è pronto a ricevere.

Il risultato è il seguente:

 

La lettura della risposta è il processo che viene inviato in background alla riga 20. È una concatenazione di roba. La richiesta, successiva, è la riga 26.

Il problema che ho dovuto affrontare era che il programma in background deve restituire la risposta a quello in foreground.

Per questo, ho usato una named pipe. (Linux Journal ha un ottimo articolo sulle named pipe.)

Una named pipe è un file speciale che si comporta proprio come la più nota pipe anonima ( |), solo che è posizionata nel filesystem e consente di far comunicare tra loro processi dalla vita separata.

Dunque, prima si crea la named pipe, poi si manda in background il processo di lettura, che scriverà quello che cattura nella named pipe, poi si invia la richiesta di stato e poi si legge il contenuto “depositato” nella named pipe. Voilà.

Due parole possono essere spese sulla riga che legge la risposta.

/usr/bin/timeout provvede semplicemente a fermare l’esecuzione dopo due secondi in caso di fallimento (vedremo perché potrebbe fallire).

/usr/bin/xxd legge i primi tre caratteri ( -l3) dal file /dev/ttyUSB0 e converte da esadecimale a decimale. Non solo esegue la conversione, insomma, ma si occupa da solo del fatto che il relay non invia segnali di fine messaggio (il messaggio è di tre caratteri, tutto qui).

La lettura viene inviata a /usr/bin/cut, che si occupa di leggere l’unica cifra che ci interessa, che sarà 0 (relay spento, caldaia accesa) o 1 (relay acceso, caldaia spenta).

Il risultato viene scritto nella pipe, in attesa che qualcuno lo legga. Poi il processo va in background.

A parte un piccolo sleep  per dare il tempo al processi di lettura di avviarsi, il resto è abbastanza elementare.

Questo programma è molto più veloce di quello fornito da KMTronic. Ha l’unico difetto di non essere del tutto affidabile. In condizioni sfortunate , infatti, la creazione della named pipe e l’avvio del processo di lettura in background potrebbero richiedere un tempo apprezzabile, tanto che la risposta del relay potrebbe arrivare troppo presto. In quel caso il programma va in timeout dopo due secondi senza emettere output.
Ecco perché quello sleep. Ho fissato il valore a un decimo di secondo a tentativi e per me così funziona.

Preferisco questa soluzione. Se questo script deve essere usato come API è più efficiente. Un eventuale fallimento può essere gestito dal programma che invoca l’API.

Il montaggio nella caldaia

Non è andato bene come speravo. Sia il Raspberry PI e sia il relay sono molto piccoli, ma il groviglio di cavi e l’alimentatore mini USB hanno il loro ingombro. Piuttosto che tagliuzzare i cavi e schiacciare tutto, ho preferito aggiungere una scatola da esterno per collegamenti elettrici, comprata in un qualsiasi negozio di ferramenta e fissata con il nastro biadesivo che avevo a casa.

IMG_20131019_102928

L’unico elemento libero è il Raspberry PI nella caldaia: si vedono le lucine rosse. Il resto è nella scatola.

Il grosso cavo arancione porta l’elettricità dalla caldaia all’alimentatore micro USB del Raspberry PI, con una banale derivazione. Uno dei due cavi neri più grandi porta l’alimentazione al Raspberry PI. L’altro cavo nero collega la porta USB del Raspberry PI al relay e i due cavi più sottili, marrone e azzurro, sono in serie con il circuito del termostato.

Questa mattina all’alba c’è stata una violenta bufera, il vento sollevava molta acqua fino al soffitto (la porta finestra era completamente bagnata) e il client GKrellM installato nel mio desktop mi informava che il Raspberry PI era perfettamente allegro e funzionante :)

Ecco perché mi son deciso a scrivere questa seconda parte.

 

[Continua da http://sergiovaccaro.it/domotica-il-riscaldamento-controllato-via-web-con-raspberry-pi-1/]

old_passwords in MySQL e interazione con il PHP

old_passwords

Nel dicembre 2003 MySQL ha modificato il sistema con cui vengono cifrate le password. Fino alla versione 4.0 veniva usato un hash a 16 caratteri, mentre da 4.1 in poi è stato introdotto un hash più complesso, a 41 caratteri (in realtà sono 40, con un asterisco iniziale).

Per garantire la compatibilità con i vecchi client (cioè quelli più vecchi del 2003), MySQL ha introdotto l’opzione di configurazione old_passwords, che se posta a  1 continua a codificare le password con i vecchi hash a 16 caratteri.

Il vecchio sistema, naturalmente, è meno sicuro e fortemente scoraggiato.

No one should be using these anymore. This variable makes the password hashing algorithm compatible with that of MySQL 4.0. I’m pretty sure 4.0 was released 9 years ago. I don’t know of anyone still using it (or 4.0 client libraries).

http://planet.mysql.com/entry/?id=27450 (del 2011)

L’unico motivo per utilizzare  old_passwords=1 è se si ritiene che ci siano in giro client precedenti al 2003.

I dettagli del sistema di gestione delle password sono raccontati a http://dev.mysql.com/doc/refman/5.0/en/password-hashing.html

I nuovi client MySQL sono comunque compatibili con il vecchio sistema. I nuovi client, in altre parole, inviano entrambi gli hash e possono connettersi anche al vecchio MySQL < 4.1.0 e al nuovo MySQL > 4.1.0 con old_passwords=1. (Il caso MySQL 4.1.0 è particolare e transitorio).

In altre parole, il tentativo di login con il client MySQL funziona in ogni caso e sembra che non ci siano problemi. A meno che…

Gli hash a 16 caratteri sono considerati così vecchi e poco sicuri che esiste un’altra opzione di configurazione, secure_auth, che serve ad impedire il login con vecchie password. A partire da MySQL 5.6.5 (marzo 2012secure_auth è attivata per default.

Le conseguenze sul PHP

Se le password vengono generate mentre old_passwords=1, le conseguenze sul PHP sono abbastanza dolorose e producono effetti a catena. Riguardano la qualità dei programmi, le performance, la compatibilità con gli aggiornamenti futuri e la sicurezza. E dipendono dalla versione.

A partire dalla versione 5.3.0 (giugno 2009), il PHP può connettersi al MySQL in due modi. O utilizzando le librerie fornite da MySQL (libmysqlclient) oppure con un client interamente riscritto in casa Zend (mysqlnd) per adattarsi alle particolarità delle applicazioni web.

L’uso delle mysqlnd è altamente raccomandato:

using the built-in mysqlnd library is highly recommended

http://www.php.net/manual/en/mysqlinfo.library.choosing.php

Un’applicazione web, infatti, esegue molto spesso query ripetute. Il client mysqlnd, perciò, possiede caratteristiche ulteriori come il caching delle query nel client e le lazy connections, eseguite solo quando le query hanno veramente bisogno di essere lanciate e non al momento indicato dal programmatore. Un gran vantaggio di performance, soprattutto in siti web con un numero medio/alto di visite.

Ma quando le mysqlnd sono state introdotte erano passati più di 5 anni da quando in casa MySQL hanno inventato il novo sistema di hash. Un tempo enorme per la velocità con cui si evolvono i software; e in casa PHP non hanno garantito così tanta compatibilità all’indietro: le mysqlnd NON sono compatibili con i vecchi hash a 16 caratteri.

La conseguenza, come si diceva, è diversa a seconda della versione del PHP.

Fino al PHP 5.5.0 escluso, le diverse librerie erano associate alle API disponibili. Le uniche API capaci di autenticarsi con gli hash a 16 caratteri erano le mysql_*, che sono procedurali, impongono tecniche di programmazione obsolete e sono ormai deprecate (http://www.php.net/manual/en/function.mysql-connect.php). Le  mysql_*, infatti, non hanno protezioni contro l’SQL injection, e quindi la sicurezza è affidata soltanto all’esperienza e alla concentrazione del programmatore, cioè è a rischio di errore umano.

Con versioni del PHP precedenti alla 5.5.0, insomma, si è costretti irrimediabilmente a scrivere programmi di cattiva qualità, molto meno sicuri, meno performanti e che impediranno gli aggiornamenti futuri del PHP.

A partire da PHP 5.5.0 (giugno 2013) la situazione è migliorata perché le librerie che fanno da client MySQL sono state sganciate dalle API. In altre parole, i programmi vengono scritti indipendentemente da come è stato compilato il PHP. La scelta, perciò, è tutta in fase di installazione.
Se in una rete anche un solo database MySQL ha le password codificate con gli hash a 16 caratteri ( old_passwords=1 ), il PHP degli host che dovranno accedere a quel database – fosse anche occasionalmente e per applicazioni minori – dovrà essere compilato con le libmysqlclient, degradando le performance di tutti i siti ospitati.

Con il PHP 5.5.0, insomma, si possono scrivere programmi migliori e più sicuri. Ma a causa delle vecchie password codificate in hash a 16 caratteri bisogna accettare un degrado delle prestazioni.

Lavorare nel web allo stato del 2003 fa piuttosto effetto. Nel 2003:

  • L’ADSL era nato da poco
  • Non esisteva Gmail
  • Non esisteva Google Maps
  • Non esisteva Facebook
  • Non esisteva Twitter
  • Non esisteva WordPress
  • C’era il PHP 4 e non prevedeva la programmazione a oggetti
  • C’erano Windows XP e Explorer 5.5
  • Mozilla Firefox non era ancora nato, c’era Netscape Navigator
  • AJAX era appena nato
  • Si parlava ancora di pagine web e non di applicazioni

Le tecnologie, il fenomeno sociale e le esigenze degli utenti, insomma, erano l’ombra di quelli attuali.

La soluzione

Non è sicuro che ci sia una soluzione.

Per saperlo, bisogna valutare il tipo di dato della colonna  Password della tabella degli utenti, mysql.user.

La verifica può essere fatta eseguendo, come amministratore:

 

Se la colonna  Password della tabella  mysql.user è CHAR(16), le nuove password NON possono essere utilizzate. Questo potrebbe verificarsi se la tabella degli utenti è stata importata da un vecchio database senza gli adeguati accorgimenti.

Se invece la colonna  Password è  CHAR(41) si può passare alle nuove password senza preoccupazioni.

Nella documentazione si legge infatti:

4.1 and later clients can authenticate using accounts that have short or long hashes

http://dev.mysql.com/doc/refman/5.0/en/password-hashing.html#idm47969038334240

(In realtà anche il caso sfavorevole dovrebbe essere riconvertibile a quello favorevole attraverso lo strumento amministrativo mysql_upgrade. Ma in ambienti di produzione non è una manovra consigliabile.)

Ma veniamo alla soluzione.

Se la colonna Password della tabella  mysql.user è CHAR(41) , la prima operazione da compiere è rimuovere l’opzione old_passwords.
È importante ricordare che  old_passwords non ha effetti sul sistema di autenticazione, ma solo su come vengono codificate le password al momento della creazione o della modifica. Quindi bisogna ancora procedere al rinnovo delle password esistenti, per renderle adeguate alle mysqlnd del PHP.

A questo scopo, senza urgenza, ogni utente (e solo l’utente può farlo, perché bisogna manipolare la password) deve semplicemente reimpostare la password:

 

MySQL, a questo punto, conserva il nuovo hash a 41 caratteri.

L’amministratore del database, quindi, può convocare i propri utenti uno ad uno – rispettandone i tempi di reazione – e richiedere che venga eseguita la manovra (e magari attivare infine secure_auth).

Per conoscere quali utenti abbiano ancora la vecchia codifica è sufficiente guardare quali hash hanno 16 caratteri.

 

Qualora ci siano ancora dei vecchissimi client che hanno bisogno di password codificate con hash a 16 caratteri, gli utilizzatori di quei client dovranno semplicemente evitare la manovra.

Se dovesse essere necessario intervenire su quelle vecchie codifiche, infine, si può ancora modificare una password mantenendo l’hash a 16 caratteri:

 

Ma chi è che usa ancora client del 2002?

 

Informatica: equivoci semplici, soprattutto negli ambienti di lavoro della PA

Quando lavoriamo cerchiamo soluzioni di questo tipo per risolvere problemi: http://sergiovaccaro.it/accesso-sshsftp-ad-un-host-remoto-tramite-php-con-scambio-di-chiavi/
In quel caso si trattava di eseguire il trasferimento di molti file da un host di produzione all’altro, con criteri di selezione.

Per ottenere questi risultati, ci sono due modi.

C’è quello di far salire l’adrenalina e buttarsi a testa bassa sulla prima soluzione che viene in mente, fosse anche quella di affollarsi tutti a stampare i file, portarli in sala server e copiarli a mano.
Un lavoro immenso, un sacco di persone, una grande fatica, un tempo interminabile, uno strascico di errori, gente che resterà in ufficio fino alle nove, che darà grande soddisfazione ai deliri di onnipotenza di certi capi e dei Calderoli di turno. «Da noi si lavora tantissimo.»

E poi c’è il metodo raccontato là (o tanti altri simili), che è il contributo che possiamo dare noi. Una mattinata a casa a studiare le pieghe di certe tecnologie, la scrittura di un documentino, un programma di esempio, una realizzazione.
Un lavoro elegante, che produce risultati in tempi brevi, ben dispiegati negli ambienti di produzione, riproducibili e a prova di errore umano. In informatica, si sa, un lavoro ben fatto è un lavoro che non si vede.

Qual è il ruolo che si vuole che noi abbiamo in un contesto lavorativo?
Aiutare anche noi a portare le stampe in sala server o trovare soluzioni di quel tipo?

Credo che il primo obiettivo che si debba cercare è «lavorare meno perché si lavora con intelligenza», non «lavorare tanto perché non sappiamo come fare».
Ne gioverebbe il risultato, oltre che la qualità della vita.

Certo, come si fa ad introdurre questi concetti in un ambiente non specializzato? La differenza tra i due approcci è caratteriale, umana, culturale – non si cambia la testa delle persone.
Però da qualche parte si può iniziare.

Si può iniziare rimuovendo alcuni equivoci.

Cerchiamo di lavorare poco

Chi si sforza tanto per ottenere un risultato che un altro ottiene con sforzo minore non ha lavorato di più, ha solo faticato di più.

Certo, in un meccanismo lavorativo organizzato come una fabbrica dell’Ottocento – in cui è solo il conto ore ad essere davvero misurabile – chi ha passato tutto il giorno ad eseguire un task «non si è fermato un attimo». Chi invece in un’oretta ha finito la stessa operazione «ha passato tutto il giorno a bighellonare», magari “trastullandosi” a studiare nuove cose.

Questo vuol dire premiare la minor professionalità.

Stabiliamo il principio che chi lavora poco è più bravo di chi lavora tanto, se il risultato è lo stesso.
Non è questione di gloria, chi lavora poco per lo stesso risultato avrà il tempo per continuare a curare la propria crescita, sottraendosi al gorgo del fare che impedisce il saper fare. Ma in molti contesti lavorativi vale il contrario: chi è più competente viene trattato come un servo, a vantaggio di chi sbandiera il principesco «non lo so fare». Spesso è il «non lo so fare» ad essere premiato.

Premiare il «non lo so fare» vuol dire consolidarlo.

Chi sa cos’è l’informatica?

Quelli che ripetono continuamente la parola «informatica» quasi sempre ne ignorano il significato.

Prendo Wikipedia e salto il senso semantico del termine, perché poco adatto agli ambienti di basso livello culturale. Ma attenzione, nel lavoro ci sono inquadramenti contrattuali e formali di cui si deve tener conto.
Ma veniamo al paragrafo «Informatica pratica e informatica teorica», che sicuramente è l’unico che interessa. Copio e incollo la prima parte.

Esistono frange di persone che confondono l’informatica con aree vocazionali che tipicamente riguardano l’utilizzo di software applicativo e che comprendono il semplice utilizzo di programmi per l’ufficio, il navigare sul web o il gaming. L’informatica invece vede editor di testo, browser e videogame come semplici strumenti di lavoro o svago. Quello che interessa, nell’informatica pura, non è tanto saper usare i cosiddetti applicativi per come essi si presentano, quanto piuttosto capirne, tramite ad esempio l’analisi del codice sorgente, la struttura ed eventualmente saperla migliorare con l’uso di algoritmi più efficienti sotto diversi criteri (uso di memoria, numero di istruzioni, parallelismo, …).

Per i detrattori di Wikipedia, cito anche la Treccani, ancora alla voce informatica:

Scienza che studia l’elaborazione delle informazioni e le sue applicazioni; più precisamente l’informatica si occupa della rappresentazione, dell’organizzazione e del trattamento automatico della informazione. Il termine informatica deriva dal francese informatique (composto di INFORMATion e automatIQUE, «informazione automatica») e fu coniato da P. Dreyfus nel 1962.
L’informatica è indipendente dal calcolatore che ne è solo uno strumento, ma è chiaro che lo sviluppo dell’informatica è stato ed è tuttora strettamente legato all’evoluzione del calcolatore

E più avanti.

Per quanto riguarda le conoscenze necessarie per interagire con l’ambiente virtuale (per es., per la ricerca di particolari informazioni sulla rete o per scambiare messaggi di posta elettronica), un aspetto ricorrente è che le conoscenze in oggetto solo in parte vengono apprese nelle strutture formative. In larga misura esse vengono apprese sul campo, utilizzando i programmi disponibili localmente o in rete per scopi di lavoro o di svago, navigando nella rete, guidati dalle istruzioni via via fornite all’utente.

Non sembrano esserci molti margini: chi usa uno strumento non è un informatico, è una persona che svolge un’attività, ad esempio un lavoro.
L’informatico invece è colui che lo strumento lo costruisce. Anzi, è colui che lo progetta, allo scopo di fornire a chi svolge l’attività un apparato che la consenta o la agevoli.

E il processo di apprendimento è autonomo. Chi si affida alla formazione si sta sottraendo alla conoscenza stessa.

Dunque chi svolge un lavoro non è in diritto di delegare le proprie competenze. E può ricorrere al supporto di un informatico solo nella piena consapevolezza che lo sta sottraendo al suo lavoro, disturbando la sua produttività e capacità di autoformazione e chiedendogli di eseguire attività che per lui non sono abituali. In altre parole, chi si rivolge all’informatico per svolgere il proprio lavoro corrente si sta rivolgendo ad un dilettante, rivelando in tal modo un dilettantismo evidentemente ancora maggiore.

E non solo.
Chi ritiene che le proprie competenze siano in carico ad altre responsabilità rispetto alla propria (la lagna della formazione e del corso) sta negando proprio le basi della costruzione della conoscenza dei propri strumenti. È la Treccani a dirlo, non quegli “hacker” di Wikipedia. E se mancano le basi…

Occorrerebbe, insomma, ristabilire i concetti in gioco in ambito lavorativo. Darsi delle regolette lessicali è utile di facile realizzazione.

Il tempo per lavorare e il tempo per imparare

Un altro equivoco drammaticamente frequente riguarda ancora il senso del tempo.

Il tempo impiegato all’acquisizione di nuove conoscenze è il vero tempo virtuoso, altro che tempo perso.

Quando si fa fatica a comprendere uno scenario o ad usare uno strumento nuovo dovrebbero accendersi tutti gli special della crescita, del miglioramento della professionalità, dell’impennata della competenza, dell’aggiornamento, dell’aumento del rapporto tra risultato e sforzo.
Chi sa lavorare trova perfino eccitante questo meccanismo, perché sta mettendo in saccoccia il sollievo da alcune fatiche future e una capacità di produrre risultati che prima non possedeva.

C’è invece chi corre subito da chi «ci mette di meno», mutilandosi della capacità di svolgere lavori futuri, di comprendere il proprio stesso operato perché delegato, perfino di valutare la qualità dei propri risultati – già, ci sono strumenti anche per quello.

Ecco perché si ricorre all’«informatico». L’informatica sembra essere quella comunità di persone che ha a cuore la propria crescita, contrapposta a chi si sente già vecchio, andato, finito, inutile, capace al massimo di ripetere sempre e sempre gli stessi gesti, senza intelligenza.

Equivoco lessicale o meno, potrebbe e dovrebbe essere chiaro che nell’era in cui l’informazione viaggia su binari automatici l’evoluzione dei saperi e degli strumenti è l’unico lavoro realmente sensato, per gli «impiegati di concetto» (vecchio termine, che ancora mi piace).

C’è chi ritiene che rifugiarsi nello svolgimento di quanto già portato a compimento in passato sia la migliore garanzia di qualità lavorativa. Niente di più disastroso. La ripetizione è il lavoro delle macchine, quello degli umani è l’apprendimento e l’invenzione.

La negazione di questo principio è la causa del rendimento disastroso delle PA, ne sono molto convinto.

Informazione ed energia

C’è quindi da rimuovere un ulteriore assunto: «con l’informatica si fanno cose informatiche».

All’università ho studiato cibernetica, che è stata definita così: «lo studio della natura vista attraverso gli scambi di informazioni», contrapposta alla fisica che studia la natura attraverso gli scambi di energia. Eravamo negli anni ’90, prima di Internet.
Con quell’approccio, si scopre, tutto quello che avviene può essere interpretato e determinato in chiave di informazione.

Pochi anni dopo l’informazione è diventata il nuovo petrolio.

Disporre di strumenti intellettuali e materiali per il trattamento delle informazioni determina qualsiasi processo dell’esistenza.

E a maggior ragione vale per il lavoro immateriale e cognitivo.

Non occorre ripetere quello che già sappiamo a proposito di come Internet ha cambiato la nostra vita. Quello che ancora non sembra del tutto chiaro è come gli strumenti hanno cambiato le attività produttive. Eppure i lavoratori del pubblico impiego trascorrono le giornate al computer. Se ne accorgono?

Dunque il computer non è un capriccio per giovani disoccupati che si trastullano con Facebook. È lo strumento davanti al quale trascorriamo le nostre dannate giornate di lavoro, è attaccato a noi come un maledetto innesto corporale, una protesi esistenziale che anche se circoscritta all’orario di lavoro è parte integrante di tutto quello che facciamo. Non è questione di «mi piace» o «non mi piace», è uno strumento di governo (e malgoverno), anzi un contenitore di strumenti. Quello che facciamo senza passare per il computer, a pensarci bene, è quasi nulla.

E il motivo è quell’asserzione vincente con cui è stata definita la cibernetica, in quell’aula. Sarà proprio per via degli strumenti, ma solo chi è in grado di governare l’informazione è in grado di svolgere un lavoro cognitivo. (E sfido chiunque anche a spingere una carriola se non sa cosa metterci dentro, dove andare e perché farlo.)

Allora l’assunto è «con i mezzi forniti dall’informatica faccio quasi tutto».  Il punto è scoprire se uso gli strumenti giusti, se ce ne sono di migliori, se la crescita delle mie competenze mi consentirà di svolgere un lavoro meno faticoso producendo risultati maggiori. Occorre capire se altri riescono a svolgere attività simili alle mie con fatica minore e effetti migliori.

Calma allora. Inventiamo nuovi modi di lavorare, chiediamo agli informatici (questo sì) strumenti di lavoro che ci sollevino dalla ripetizione e dal risultato mediocre. Fermiamoci, studiamo, impariamo. Facciamo cose, avvalendoci di ogni mezzo necessario. Anche l’informatica.

Chi l’ha capito?

 

Accesso in SSH/SFTP ad un host remoto tramite PHP con scambio di chiavi

Key based SSH authentication

L’accesso in SSH/SFTP ad un host remoto tramite PHP sembra una faccenda abbastanza semplice, ma poi finisce per non funzionare.

Il motivo è che la soluzione proposta spesso nei forum è quella di eseguire l’autenticazione tramite ssh2_auth_password() , che emula l’autenticazione da tastiera.

Ma spesso non funziona, perché molti server SSH sono configurati con

 

Ed è giusto. Quando facciamo l’autenticazione da tastiera le credenziali vengono inviate in modo cifrato attraverso PAM e SSH stesso. La PasswordAuthentication da sola, invece, invia la password in chiaro indebolendo il sistema.

Poiché stiamo parlando della configurazione del server, piegare un server a questa vulnerabilità solo per far girare una certa applicazione non è una buona idea.

Conviene usare l’autenticazione tramite chiavi e la funzione PHP ssh2_auth_pubkey_file() .

L’autenticazione tramite chiavi

L’autenticazione tramite chiavi è ben raccontata in giro. A me piace la pagina Keychain del wiki di Gentoo, ma ci sono moltissime altre guide.

L’idea (molto molto brevemente) è che nell’host dove viene eseguito il client viene generata una coppia di chiavi, una pubblica e una privata, che consentono di cifrare e decifrare i messaggi.

Basta copiare la chiave pubblica locale nel lato server (e in particolare nella home dell’utente remoto) per garantire le comunicazioni.

Ad ulteriore sicurezza, la chiave privata viene protetta da una passphrase. Assomiglia ad una password nell’uso, ma la differenza sostanziale è che viene richiesta localmente per accedere alla chiave privata e non viaggia nella rete.

Nel nostro caso dovremo curare due aspetti particolari:

  1. Se il PHP viene eseguito attraverso Apache, creare le chiavi per l’utente che esegue Apache (diciamo apache ), che è un utente di sistema e per il quale non abbiamo una home e non riusciremo a fare su - apache .
  2. Gestire le chiavi con il PHP

Creare la coppia di chiavi per l’utente apache

Agiremo come  root  nell’host locale.
Per intenderci, chiameremo  client.mydomain  il client e  server.theirdomain  il server. Nel server vogliamo autenticarci con l’utente jhonny .

Per prima cosa, creiamo una directory per la conservazione delle chiavi:

 

Poi generiamo le chiavi, con un piccolo accorgimento rispetto alle guide:

 

L’accorgimento è l’ultima opzione (-C), che serve a modificare il “comment”, cioè l’ultima parte della chiave pubblica.

Dovremmo avere il seguente dialogo (attenzione, la posizione dei file NON è quella di default):

 

Due osservazioni.
La prima è che, contrariamente al suggerimento, abbiamo richiesto di depositare le chiavi nella directory creata poco prima.
La seconda è che non è il caso di fare economia di passphrase: inseriamo una passphrase robusta, tanto non dovremo digitarla se non al momento di inserire i parametri nel programma PHP.

Una nota aggiunta successivamente: in alcuni scenari – ad esempio lavorando con Debian Wheezy e PHP 5.4.4-14+deb7u7 – è emersa la necessità di lavorare con chiavi private cifrate. L’argomento è trattato nell’ultimo paragrafo.

Ora dobbiamo gestire proprietà e permessi del materiale appena creato.

Il materiale appartiene ad apache:apache :

 

E non deve essere letto da tutti:

 

L’ultimo passaggio è copiare la chiave pubblica (attenzione) nella home dell’utente con cui vorremo autenticarci, in server.theirdomain .

 

L’autenticazione in questa fase avverrà nel solito modo. Se la directory  ~/.ssh  non esiste in server.theirdomain , spostiamoci prima lì e creiamola, con permessi 0700 .

Il programma in PHP

A questo punto il programma in PHP che esegue la connessione e si autentica è il seguente.

 

Dovrebbe funzionare e mostrare il contenuto della propria home remota.

Una nota aggiunta successivamente: qualora non funzioni, potrebbe essere per le ragioni indicate nell’ultimo paragrafo.

Considerazioni

È utile. A me vengono in mente diversi utilizzi, quali eseguire comandi remoti e trasferire file in modo affidabile con SFTP.

Ma è utile anche se usato nello stesso sistema locale. Sì, parlo di fare connessioni SSH a localhost. In questo modo, infatti, si aggira il mai troppo ben risolto problema di far agire Apache come utente diverso da apache , ad esempio per manipolare i file locali.

Il bug 58573 del PHP

Aggiungo questo paragrafo successivamente, dopo essermi imbattuto nel bug usando il Raspberry PI.

A causa del bug 58573, in quasi nessun caso PHP riesce a utilizzare la chiave privata se è stata generata con  libssh2  compilato con il supporto libgcrypt . È uno scenario per niente raro, che si verifica normalmente in Debian Wheezy e nelle sue derivate (Ubuntu, Mint, Raspbian, eccetera) e ovviamente anche in altri casi.

La soluzione può essere ricompilare  libssh2  con il supporto openssl , ma c’è anche un workaround (a cui si accenna in fondo al bug report) che risolve tutto. C’è un caso, infatti, in cui il PHP riesce a gestire la cifratura della chiave privata nonostante il bug: la cifratura PEM.

Il grosso delle differenze è nella preparazione delle chiavi. Si usa necessariamente RSA invece che DSA.

 

Poi si genera la chiave cifrata.

 

Infine, nel programma in PHP, si utilizza la chiave cifrata appena costruita.


 

Et voilà.

Idee per il progetto collettivo di una radio in streaming

Collettivo

Premessa

Avere una radio in streaming è un progetto praticabile, che appaga il bisogno e l’entusiasmo di chi è appassionato di musica e di chi ritiene che sia un modo per attraversare confini, barriere, costi e differenze.

L’ho già fatto, è stato emozionante. Mi piacerebbe rifarlo in un collettivo.

Una radio in streaming è anche una sfida più complessa di quello che sembra. A meno di non voler delegare, cioè rinunciare.

Occorre confrontarsi con lo scenario particolare della rete, con la sua ageograficità, con ascoltatori che non hanno né lingua né timezone e con un interminabile e fluttuante catalogo di caratteri.

Poi ci sono le questioni legali, le spese, la necessità di un impegno che  sappia dare a se stesso continuità, l’uso avanzato degli strumenti IT.

E poi ci sono le differenze. Sì, c’è chi come me pensa che le differenze siano un’opportunità, ma le differenze devono essere conosciute, riconosciute, accettate, amministrate e valorizzate. Costruire un collettivo è bello e difficile.

È difficile. E proprio per questo è elettrizzante.

Ne parlo qua proprio perché voglio condividere la mia idea. Come qualcuno sa già, ho una piccola esperienza: un grandissimo successo come one man endeavour, una piccola cosa rispetto a ciò che può fare in gruppo.

Allora ne parlo qua, è un modo per condividerlo. Butto giù il mio punto di vista e aspetto delle critiche.

Cos’è una radio in streaming (secondo me)

Una radio in streaming è una collezione di flussi simultanei e ininterrotti di musica, con un carattere preciso e un’armonia d’insieme, ascoltati da persone che utilizzano abitualmente dispositivi connessi ad Internet, persone assetate di musica che usano quei dispositivi per alimentare la loro insaziabile avidità di suoni e di emozioni, persone che hanno voglia di un flusso ininterrotto di linfa da iniettare nelle loro esigentissime vene auricolari.

Queste persone, così esigenti e attratte, sono equipaggiate con casse mostruose o cuffie di grandi qualità, hanno una buona connessione ad Internet e sanno come utilizzarla al meglio. Hanno uno, due, tre computer sottomano e trascorrono ore a cercare di placare la loro sete.
Hanno, queste persone, bisogno di un flusso interminabile, amano scoprire e approfondire. Hanno coraggio estetico e sono destrutturate. Non sono soddisfatte del mainstream. Hanno superato il concetto di brano e hanno sviluppato il concetto di mood.
La mia radio si chiamava Moodcast.

L’interminabilità del flusso è uno dei caratteri che contraddistingue la radio in streaming. In rete non ci sono orari né confini culturali. La musica è l’unica lingua transnazionale e può parlare a tutti.

Una radio in streaming ha diversi canali.

Una radio in streaming verrà ascoltata nelle favelas di Rio e nelle vetrose case di Reykjavík. Verrà ascoltata nelle serate di Wellington che sono simultanee alle grige albe di Berlino. Verrà ascoltata tra gli idiomi gutturali di Mumbay e l’armoniosa durezza di Irkutsk. Verrà ascoltata a New York mentre gli scugnizzi alluccano nei vicoli di Napoli.

Non è una mania di grandezza, sarà proprio così.

Una radio in streaming non trasmette pubblicità di alcun genere, se non a se stessa.

Cosa NON è una radio in streaming (secondo me)

Una radio in streaming non è una radio tradizionale.
Non ha le stesse modalità di ascolto. Non viene ascoltata in auto e non viene ascoltata distrattamente. Non viene nemmeno ascoltata attentamente, perché i suoi ascoltatori sono davanti a un computer, hanno avviato i loro player preferiti e non sono né in discoteca né al supermarket. Una radio in streaming non è buona per ogni momento e non è buona per tutti. È per chi ha voglia di una armoniosa e sostenibile inondazione di musica.

Una radio in streaming non è una radio locale.

Una radio in streaming non è un video di YouTube. Non è una fruizione occasionale, frammentata, sparsa. Non è una cosa fica di cui vantarsi con gli amici, non è alla moda e non si ascolta al cellulare. Una radio in streaming accompagna un pomeriggio di lavoro, la serata di un locale, una cena.

Una radio in streaming non è un’enciclopedia musicale. Non deve raccontare, parlare, spiegare. La musica parla da sola e nessuna parola deve spezzare il flusso. La tecnologia fornisce titoli o autori, chi vuol saperne di più è già al computer e apra Wikipedia o LastFM. Se abbiamo informazioni originali avremo anche un blog.

Una radio in streaming non è un allegro sito colorato né un social network. Non è pensata per essere usata per forza attraverso un portale, vive senza browser, non fa assistenza, non ha bisogno di continui click e mi piace. La musica parla da sola.

Una radio in streaming non è una radio “per tutti i gusti”. Una radio in streaming ha un carattere specifico per ogni canale e di quel carattere ha rispetto e osservanza. È un flusso ininterrotto che accompagna e genera umori e stati d’animo ben precisi. Una radio in streaming non insegue nessuno.

Una radio in streaming non ha bisogno della diretta. La destrutturazione oraria anzi priva di senso questa idea. Quella linguistica pure. Si può alimentare la musica in diretta – anche da casa – ma ha senso farlo solo in occasioni particolari che potrebbero non verificarsi mai.

La musica, il collettivo e il carattere

Quando penso a rendere collettiva la mia idea ciò che mi spaventa di più è la disomogeneità dei gusti musicali.

Ciò che rende identificabile una radio è il carattere. Le radio, in Internet, sono almeno 50mila. Ciò che rende uniche alcune di esse è il carattere. E il carattere è tutto nella qualità del flusso di dati, nella musica, nell’emozione che trasmettono a chi ha voglia di riceverla.

Come si fa a rendere uniforme il gusto di un collettivo? Probabilmente non si può, se non con il tempo e con le fantastiche contaminazioni di cui noi tutti siamo assetati.

Una parte del lavoro da fare è proprio quella di costruire un carattere collettivo, approfittando dell’opportunità dei canali multipli – che consentono alle differenze di convivere – ma senza perdere un’identità tutta da formare.

L’inizio è difficile e caotico.

L’impegno

Una radio in streaming richiede meno impegno quotidiano di quello che sembra. La musica può accumularsi lì, le playlist possono durare decine e decine di ore, non occorrono dirette.

Inoltre ad una radio in streaming si lavora da casa, tè, caffè, vino, giorno, notte, ciascuno a modo suo. E si lavora ascoltando musica, è bello. L’impegno è quello di scoprire e alimentare la musica, che è facile, lo facciamo già ciascuno per sé.

Ma l’impegno è anche quello di pulire, di censurare quello che è inappropriato o stantio. È anche quello di normalizzare le playlist che inizialmente si allungano indefinitamente, è quello di gestire i tag, quello di normalizzare i volumi, quello di convertire i formati, quello di alimentare il sito.
E poi è quello dei social network, sia specializzati e sia generici.

C’è un impegno manageriale.

E poi c’è il collettivo, che è a sua volta un impegno.

L’impegno che occorre è a lungo termine. È quello di continuare ad esserci, dopo il primo mese e il primo anno. È quello di non lasciarsi andare ai facili entusiasmi, all’inverno che ci tiene a casa che sarà seguito da un’estate sempre in giro. È la parte più difficile.

La tecnologia

Una radio in streaming è una collezione di server in esecuzione in un host in Internet. Occorre mettersi dall’altra parte del cavo. Imparare ad usare gli strumenti di lavoro quando ci sono e a costruirne quando non se ne trovano. Non c’è posto per il «non lo so fare» e per il «me lo fai tu?», non avrebbe senso.

Una radio in streaming non è un blog o un post in un forum. Non basta in click e non ha una multinazionale alle spalle che ti offre strumenti, bisogna inventarla.

Una radio in streaming ha bisogno di idee e di soluzioni, non può funzionare per delega. Non è un’azienda che scaraventa tutto sugli specialisti.

La disponibilità della tecnologia inoltre costa. Costano gli apparati di base e costa la connettività. E costano gli strumenti, i software specializzati, i servizi di assistenza, le garanzie di continuità.

La conoscenza della tecnologia aiuta a contenere i costi, perché «non lo so fare» ha un costo, sempre. Ma anche la conoscenza ha un costo, in termini di tempo e fatica. Il bilancio non sarà mai semplice.

La maledetta questione dei diritti

E dal punto di vista legale?

Chi ci capisce è bravo. La legge, si sa, è sempre la legge del più forte. Non ha importanza che non sia chiaro quale sia la legge ad essere in vigore, di quale stato.

Di certo l’agenzia italiana pretenderà il suo pizzo, non appena scoperti.  Non ti chiedono di certo se i tuoi server sono in Romania o Mongolia, né se i tuoi ascoltatori sono in Bolivia o in Siberia. Ti chiedono il pizzo e basta, poi sta a te trovare il modo per difenderti. E come si fa?

L’approvvigionamento di musica

La musica può essere trovata a costi molto contenuti.

I costi

Messi insieme i costi per gli apparati di base e le spese per la musica, il mio conto va a finire sui mille euro all’anno. È più un conto fatto a fiuto che una pianificazione. Poi ci vorranno le spese per i software che io ritengo non essenziali, ma senza i quali moltissimi saranno disorientati. Delegare è mortale.

Le entrate

Entrate? Quali entrate?

Mi vengono in mente solo tre tipi di approvvigionamento: il proprio portafogli, il Donate di PayPal e il sostegno esterno.

Tre punti tutti deboli. Bisognerà inventare.

L’esistente e gli esempi migliori

Le radio in streaming del mondo, in buona approssimazione, sono elencate qua: http://www.shoutcast.com/
Poco importa se ciascuna di queste ha un proprio sito e una propria modalità di presentazione, i flussi di musica sono quelli, i giocattoli per gli smartphone o i player per i browser si fanno dopo, se serve.
Quello è anche il punto di partenza di qualsiasi radio. Con i propri pochi ascoltatori e con i propri generi e brani bisogna distinguersi nell’elenco, la rete poi amplifica con i suoi modi.

L’esempio più bello secondo me è SomaFM: http://somafm.com/
31 canali di musica indipendente o alternativa, ciascuno con un proprio carattere. Sì, certo, vengono da un’esperienza decennale come radio tradizionale dell’area di San Francisco. A mio modo di vedere, sono un’eccellenza.

La domanda

Vi interessa?

 

Avviare un sistema senza disco, con PXE, dnsmasq e syslinux

PXE

Si può far funzionare un computer senza hard disk? In una rete in cui sia presente un altro computer capace di erogare un kernel e un filesystem si può, senza rinunciare a nulla.
Vediamo come, con PXE, dnsmasq e syslinux, in GNU/Linux.

Obiettivo

Si può aver bisogno di un sistema operativo interamente remoto per diverse ragioni. Ad esempio per risparmiare il costo di un hard disk – magari uno per decine di postazioni, o perché abbiamo un dispositivo molto piccolo e non abbiamo spazio, oppure per amministrare un unico sistema da replicare in diversi computer o per svolgere gli interventi di manutenzione offline, quando il computer destinatario è spento. O altro.

Ingredienti

Occorrono un po’ di cose.

  • Il firmware del computer destinatario, che chiameremo slave, deve essere dotato di sistema di boot PXE (quasi sempre vero nei normali computer).
  • Occorre almeno un altro computer che fornisca il necessario allo slave, e lo chiameremo master. In scenari complessi, il ruolo di master può essere suddiviso tra diverse postazioni. Il master dovrà a sua volta agire come:
    • DHCP server, per avviare la partecipazione alla rete dello slave;
    • TFTP serve, per fornire almeno un bootloader e un kernel;
    • NFS server, per fornire un filesystem al computer senza disco.
  • Una rete Ethernet o WiFi o mista.
  • Un bootloader capace di avviare il sistema in queste condizioni.

E inoltre un po’ di destrezza e un paio di pomeriggi di pioggia.

Questo scenario ammette delle varianti, alle quali faremo soltanto cenno alla fine dell’articolo.

Lo slave

In termini strettamente fisici, lo slave deve solo disporre di un firmware in grado di avviarsi in modalità PXE. Questo si verifica nella quasi totalità dei computer moderni, con la sola eccezione di sistemi molto piccoli, come il Raspberry PI.

Questo non vuol dire che non occorre occuparsene. Il master deve fornire allo slave un kernel e un impianto di programmi adeguati all’hardware ricevente e agli scopi prefissati. In altre parole, dovremo comunque costruire un sistema operativo completo adeguato allo slave, anche se i file risiedono in hard disk remoti.

Come fare a costruire un sistema completo in queste condizioni esula dagli scopi di questo articolo. Possiamo immaginare di usare una distribuzione live, oppure di trovare in rete dei filesystem generici. Alcuni sanno perfettamente come costruire un sistema operativo per un computer che ancora non c’è, come i coraggiosi utilizzatori di LFS o i più prosaici utilizzatori di Arch Linux e Gentoo Linux.

Il metodo più semplice, anche se probabilmente meno utile, è quello di disporre inizialmente di un hard disk anche per lo slave, installare o avere già installato lì il nostro sistema operativo e copiare tutto il materiale necessario con rsync, poi possiamo rimuovere l’hard disk in prestito.

Per semplicità, facciamo riferimento a quest’ultimo metodo, anche se è quello che appare meno utile e interessante. Immaginiamo quindi di avere già a disposizione il sistema operativo necessario.

Preparazione del sistema slave

Dovremo assicurarci che il sistema dello slave abbia alcune caratteristiche.

Caratteristiche dello slave

Chi configura il proprio kernel deve assicurarsi di compilare monoliticamente gli elementi necessari per il funzionamento della rete e del client NFS. Anche se le operazioni iniziali verranno eseguite dal bootloader, infatti, il sistema ha bisogno di questi elementi per funzionare. Appoggiarsi ad una initrd può essere una soluzione, tanto più che ormai va fatta per forza, ma probabilmente è più intelligente adottare una configurazione di questo genere.

Inoltre avremo bisogno dei pacchetti necessari per la gestione user-space del client NFS. Ad esempio, in Gentoo:

Nel corso dell’articolo utilizzeremo NFSv4, ma non è indispensabile.

D’altro canto non avremo più bisogno di alcuni pacchetti. Ad esempio non avremo più bisogno del bootloader, ma nemmeno di tutte quelle utility di gestione del disco, come LVM, hdparm o i gestori dei filesystem. Potremo fare dopo un po’ di pulizia.

Trasferimento dei file dello slave nel master

Prepariamo pertanto una directory del master per ospitare il filesystem che forniremo. In questo articolo useremo

Ora non dovremo fare altro che trasferirlo in una directory del master, con un comando simile a:

Sarà bene controllare attentamente questo comando, secondo le caratteristiche specifiche del sistema slave.

Preparazione finale

Occorrono ancora un paio di accorgimenti.

Per rispettare i vincoli di sicurezza del TFTP, sarà utile spostare il kernel e l’eventuale initrd in una directory diversa, in quella che sarà fra poco la nostra tftp-root.

Ovviamente i nomi dei file possono essere differenti. Alla fine la directory /diskless/filesystems/slave/boot potrebbe essere cancellata, ma sarà utile tenerla per gli aggiornamenti futuri.

Inoltre abbiamo omesso del materiale importante: alcune directory di sistema e una coppia di device che saranno utili per l’avvio. Rimettiamo tutto a posto.

Infine, in paio di accorgimenti di configurazione.

Terminato il processo di avvio, li kernel rimonta nuovamente il filesystem utilizzato dal bootloader in sola lettura, utilizzando le indicazioni contenute in /etc/fstab. Dunque dobbiamo rimuovere tutti i montaggi concepiti per il disco locale e avere una riga assomigliante alla seguente:

Inoltre potremo eliminare gli script di avvio della rete, che risulterà già configurata prima ancora che il processo init sia stato avviato. Oppure, per non spezzare le dipendenze tra gli script di avvio, il servizio rete rete dovrà avviarsi senza modificare lo stato dell’interfaccia.
Ad esempio, in Gentoo:

Fatto questo, lo slave è pronto.

Il sistema master

Per due degli scopi del master, utilizziamo un unico software: dnsmasq.
dnsmasq riunisce in un unico demone i servizi di DHCP, DNS e TFTP server. È un software delizioso per soluzioni piccole e medie e anche per questo esempio. Ha una configurazione molto versatile e convive facilmente con sistemi di rete più complessa, operando come cache dove l’infrastruttura è più potente.

Non ci addentreremo in tutta la movimentata configurazione di dnsmasq, ma ci occuperemo solo di quella manciata di opzioni che serviranno al nostro bootstrap remoto.

Installiamo dunque dnsmasq. In Gentoo:

Come bootloader utilizziamo syslinux. È un bootloader pensato per agire in situazioni non convenzionali e una di queste è proprio PXE.

Installiamo subito anche syslinux. In Gentoo:

Si osservi che syslinux dovrà avviare lo slave, ma viene installato nel master. Niente di strano, visto quel che dobbiamo fare, ora abbiamo a disposizione un equipaggiamento di file da utilizzare più avanti. E nessun timore: il bootloader del master non verrà toccato.

Il server DHCP

Abbiamo detto che il sistema che si avvia in PXE inizia la sua attività con la ricerca di un server DHCP. dnsmasq agisce per default come server DHCP. Tutto quello che dobbiamo fare è gestire la specificità di PXE. In /etc/dnsmasq.conf :

La prima opzione seleziona una signature del richiedente e un indirizzo IP. Anzi, nel caso dell’esempio non seleziona nulla, offrendo a qualsiasi richiesta PXE quanto necessario.
La seconda opzione indica il nome del bootloader che dovrà essere caricato tramite TFTP.

Poiché non ci sono altre opzioni, lo slave considererà che l’host che fa da server TFTP è lo stesso del DHCP. Nello slave è ancora il firmware ad agire e una volta configurata la propria rete chiederà il bootloader al server TFTP.

Il server TFTP

Dobbiamo preparare dnsmasq per agire anche come server TFTP:

La prima opzione non fa altro che abilitare il server. La seconda stabilisce il punto d’origine dei file che possono essere trasferiti. La directory è stata già creata quando abbiamo preparato il kernel dello slave.

Con questa semplice configurazione, il server TFTP è pronto a ricevere la richiesta dello slave, che chiede, come abbiamo stabilito, il bootloader pxelinux.0.

syslinux

Copiamo il bootloader dall’equipaggiamento di syslinux nella tftp-root:

Non basta. La prima operazione del bootloader è interrogare di nuovo il server TFTP per ottenere un file di configurazione. Questo è un comportamento predefinito.
Il file di configurazione verrà cercato nella directory pxelinux.cfg, sempre all’interno della tftp-root. Creiamo quindi la directory:

Il nome del file di configurazione da fornire viene ricavato da una sequenza. Il primo file che viene cercato è quello il cui nome è costruito sulla base del MAC address dello slave. In mancanza di questo, vengono cercati in sequenza file il cui nome è ottenuto dalla rappresentazione esadecimale dell’indirizzo IP che è stato fornito, o di tutte le parti sinistre di quella rappresentazione. In mancanza di questi, infine, viene fornito un file chiamato default.

Ad esempio, per uno slave di tipo Ethernet (ARP type 1) con MAC address 88:99:AA:BB:CC:DD e che abbia ricevuto un indirizzo IP 192.0.2.91, la sequenza di ricerca è:

Questa sequenza consente di preparare configurazioni personalizzate, raggruppate o generalizzate. Per saperne di più basta leggere How do I Configure PXELINUX?, nel wiki di syslinux (da cui ho copiato l’esempio).

Nel nostro caso, poiché abbiamo un sistema operativo costruito per una macchina in particolare, utilizziamo il nome di file basato sul MAC address. Il file di configurazione dunque è:

syslinux supporta i menu di avvio, come lilo e grub. Dunque la prima riga indica il blocco da avviare per default e il blocco successivo, che in questo caso è l’unico, indica la configurazione da utilizzare.

La riga SAY è evidentemente un testo che verrà stampato a video.
KERNEL indica il file che dovrà essere prelevato come kernel, ovviamente sempre attraverso il TFTP. E infatti si tratta proprio del file che abbiamo copiato nella sezione relativa alla preparazione dello slave.
APPEND sono le opzioni di boot del kernel. Come si vede è una riga articolata, dove possiamo divertirti a utilizzare le opzioni più raffinate, che già conosciamo. Alcune, però, sono specifiche per questo scenario:

  • bootif indica di esegure il bootstrap solo se il MAC è quello indicato; in questo caso è una ridondanza, visto che lo stesso file di configurazione è destinato al quel MAC;
  • root  è apparentemente la solita opzione, ma assume un valore simbolico che indica che la directory root (/) verrà prelevata tramite NFS; si osservi che è una notazione simbolica, il device /dev/nfs non esiste;
  • nfsroot  è il percorso della root (/), che verrà montata tra poco.

Come si vede, la procedura di avvio inizia ad assumere forme più simili a quelle già note. Resta solo da allestire il server NFS.

Il server NFS

Questo è un lavoro che sappiamo già fare.

Per agire come NFS server il master deve avere un kernel adeguato:

Deve inoltre disporre delle stesse utility user-space dello slave:

Una volta equipaggiati a dovere, il nostro /etc/exports deve apparire più o meno come segue:

Questa configurazione in realtà è un po’ troppo permissiva, ma funzionerà. In un caso meno scolastico, converrà assegnare staticamente un indirizzo IP al MAC address e fornire quel filesystem solo al destinatario desiderato. Oppure concepire scenari più complessi. Per il nostro esercizio la lasciamo così.

Non resta che avviare lo slave.

Riepilogo dei file del master

È utile, probabilmente, riepilogare la struttura di file che abbiamo utilizzato.

A partire da questo assetto, è possibile costruire configurazioni più complesse, in grado di avviare più macchine con diversi scenari.

Avvio dello slave

Tra le opzioni di boot fornite dal BIOS dello slave, dovrebbe essercene una che riguarda l’avvio tramite rete. Non occorre fare altro che selezionarla.

PXE boot selection

PXE boot selection

Con un po’ di fortuna il computer si avvierà regolarmente e sarà pronto per l’uso.

Opportunità e limitazioni

Ci sono dei pro e dei contro.

Iniziamo dai contro. Sebbene lo slave sia una macchina funzionante a tutti gli effetti, patirà le sofferenze di una rete lenta pure essendo libero da quelle di un eventuale disco lento.Ad esempio, l’avvio di X attraverso una connessione WiFi di media qualità si è rivelato faticoso, in quanto talmente lento da incappare nel timeout di 60 secondi che lo stesso X da a se stesso per partire. Questo scenario è stato riscontrato nel tentativo di utilizzare KDM (il dispaly manager di KDE) ed è stato facilmente aggirato utilizzando al suo posto LXDM (il display manager di LXDE). Con LXDM, poi, è stato possibile avviare KDE in modo un po’ lento ma sostanzialmente normale.
Un altra limitazione, in uno scenario del genere, potrebbe essere la swap. L’uso del file di swap è generalmente abbastanza avvilente, ancora più drammatico sarebbe in una postazione senza disco con una rete lenta. Con l’equipaggiamento di RAM dei computer moderni, comunque, l’uso dello swap è sempre più raro.

In generale, se la rete è lenta, l’avvio dei programmi potrebbe essere altrettanto lento. Una volta avviati, però, i programmi si comportano in modo sostanzialmente normale e l’esperienza d’uso del computer è quella di sempre.

Ci sono anche dei vantaggi, però. Primo tra tutti quello di effettuare la manutenzione offline, cioè quando lo slave è spento.

È immediato, infatti, comprendere che i file di configurazione dello slave sono immediatamente disponibili nel master. Ma non è tutto qui, si può animare il sistema slave (purché sia costruito per la stessa architettura del master) e renderlo vivo, accedendovi in modo quasi normale.

Questo si può fare con tutti i sistemi Linux. La magia, perché appare proprio una magia, è quella di preparare il filesystem dello slave e poi eseguire il chroot:

chroot  esegue un programma (il secondo argomento) considerando come root (/) il primo argomento. In pratica ci si ritrova esattamente nello slave e si può operare.

Di fatto, occorrono alcuni accorgimenti: una volta fatto il chroot occorre ricaricare tutte le variabili d’ambiente dello slave, rileggere il file  /etc/profile  e considerare che la configurazione di rete e i servizi sono quelli ereditati dal master.

Una volta compresi tutti i dettagli di questa manovra – come sono abituati a comprendere gli utenti di Gentoo Linux e Arch Linux – sarà possibile aggiornare e installare i pacchetti, compilare nuovi kernel (ricordiamo di portarne una copia in tftp-root!) e gestire tutte le caratteristiche del sistema, in attesa di un vero avvio.

Un esempio diverso: SystemRescueCD

Una delle applicazioni più interessanti di questa tecnologia è la possibilità di garantire un avvio di emergenza a tutti i computer della rete, con SystemRescueCD o con altri sistemi live.

Poiché quasi tutti i computer possiedono PXE come opzione di boot, si può fornire un avvio di questo tipo a tutta la rete, per tutti quei casi in cui il sistema operativo ordinario sia danneggiato al punto da non consentire un avvio normale.

SystemRescueCD possiede già al momento del download tutti gli ingredienti necessari: è sufficiente un montaggio di tipo loop della iso scaricata e la copia del kernel e della initrd associata nella tftp-root.

Poi bisogna costruire una configurazione (file default) di questo genere:

Infine, aggiungere una riga corrispondente a /etc/exports:

Non ci addentriamo ulteriormente, ma se si vuole un buon esempio si può leggere il wiki di Funtoo, attraverso il link qui in basso, che usa proprio SystemRescueCD per descrivere PXE.

Scenari alternativi

Tutto quello che è stato descritto adesso si può ottenere in modi leggermente diversi.

Non è detto che il filesystem debba essere fornito in NFS. Se ci accontentiamo di un filesystem in sola lettura, possiamo montare un filesystem in HTTP. Se invece abbiamo bisogno di piena funzionalità, possiamo considerare anche NBD ed eventualmente altri scenari ancora.

Anche l’uso di dnsmasq è assolutamente soggettivo. Una scelta più tradizionale potrebbe suggerire di usare dhcpcd e tftp-hpa.

Una volta compreso il meccanismo, insomma, si aprono scenari a ventaglio.

Riferimenti

Domotica: il riscaldamento controllato via web, con Raspberry PI – Parte 1

Alloggiamento nella caldaia

Accendere e spegnere il riscaldamento con un Raspberry PI e crontab, si può. E conviene.
Naturalmente con Linux.

In questa prima parte costruisco un progetto, prima di passare ai fatti.

[Segue a http://sergiovaccaro.it/domotica-il-riscaldamento-controllato-via-web-con-raspberry-pi-2/]

Obiettivi

Gli obiettivi di questo progetto di domotica sono due.

  • Accendere e spegnere la caldaia attraverso un sistema di scheduling altamente configurabile, come un crontab, magari seduto alla tastiera del computer, non necessariamente in piedi accanto al muro dove c’è l’obsoleto “cronotermostato”.
    E magari anche senza essere a casa.
  • Accendere e spegnere la caldaia in modo estemporaneo, perché sto tornando a casa prima, perché non sono tornato a casa mentre pensavo di sì, perché chissà. Magari con il telefono.

Ingredienti

  • Un Raspberry PI, dotato di scheda WiFi. Il Raspberry PI dovrà essere alloggiato nella caldaia, quindi la connessione WiFi è indispensabile. E avrà un relay allacciato ad una porta USB, quindi sarà un Raspberry PI B, che ha due USB. Inoltre dovrà stare in balcone, meglio prendere anche il box.
    Spesa prevista, compresi la SD e tutti gli accessori: poco più di 50 euro.
  • Un relay USB, come ad esempio KMtronic USB Relay Controller, che è già “boxed” e può stare in balcone. La porta USB emula una porta seriale e può essere usata per controllare il relay con gli strumenti nativi dei sistemi Linux.
    Spesa prevista 23 euro più spedizione, tasse e seccature.
  • La cavetteria che è già nella caldaia, e cioè l’alimentazione AC e un cavo per il relay, a cui è già allacciato il relay del termostato (che ovviamente è in casa). Più una ciabatta per l’alimentazione elettrica.
  • Un po’ di magia.

L’idea

Collegamenti e collocazione fisica

Si stacca il cavo di alimentazione della caldaia e vi si allaccia una ciabatta a due prese. Alla ciabatta si allacceranno la caldaia stessa e il Raspberry PI. Il Raspberry PI verrà fissato alla buona (con dello scotch o degli elastici) all’interno della caldaia stessa, di spazio come si vede ce n’è.

Si stacca il cavo del termostato, che è già predisposto per accendere e spegnere il riscaldamento tramite il relay del termostato e in serie si inserisce il relay collegato via USB al Raspberry PI. L’alimentazione non occorre, perché è USB. Il relay, a sua volta, verrà fissato con scotch o elastici, come il Raspberry PI.

Tutto qui.

Valutazione economica

Realisticamente, compreso lo scotch, la ciabatta e altre spesette secondarie, siamo andati a spendere 100 euro. In un inverno io spendo 500 euro di gas, quindi supponendo che il sistema funzioni per due anni soltanto, dovrà farmi risparmiare il 10%.

Il mio riscaldamento è acceso inutilmente per il 10% del tempo? Nel mio caso assolutamente sì. Io ho una settimana piuttosto irregolare e per il solo scheduling più accurato prevedo di ridurre il tempo di accensione del 25%.
Mai più riscaldamento acceso, inoltre, se non rientro a casa.

Impagabile, poi, il beneficio in termini di qualità: mai più casa fredda per un rientro improvviso.

In verità faccio tutto ciò per divertimento.

Sistema operativo, connessioni di rete e impianto software generale

Il sistema operativo è il Raspbian da manuale, senza interventi particolari, su SD da 8GB (compresa nel prezzo). I software applicativi sono certamente Apache, probabilmente il PHP, le console non mancano, il crontab… insomma, il solito catalogo di un buon sistema Linux pensato per il web, nessuna invenzione particolare.

La connessione di rete è attraverso la scheda WiFi al router ADSL di casa. Il router dovrà essere configurato per inoltrare le richieste che giungono ad una certa porta esterna (la 8000?) alla porta 80 del Raspberry PI.

Il Raspberry PI dovrà inoltre essere equipaggiato per le comunicazioni con il relay. Anche per chi non se ne intende, la semplice documentazione e il materiale di esempio forniti da KMtronic sono decisamente esaustivi.

Architettura applicativa

Messi insieme tutti i pezzi, l’architettura applicativa diventa relativamente semplice.

Prendiamo per buoni – salvo sottoporli a test e forse a qualche patch – gli script di esempio forniti insieme al relay.

Lo script sembra supporre che qualsiasi utente del sistema possa accedere alla porta seriale emulata dal relay. Prendiamo per buono anche questo assunto, per ora. Successivamente si potrà rinforzare la sicurezza dell’impianto.

  1. Crontab
    Il crontab dovrà solo invocare lo script di accensione e quello di spegnimento, nei giorni e negli orari desiderati. È un esercizio scolastico.
  2. Applicazione web
    L’applicazione web dovrà eseguire quattro task: 

    • informare sullo stato attuale del sistema;
    • consentire di accendere, se spento;
    • consentire di spegnere, se acceso;
    • consentire la manipolazione del crontab.

    L’ultimo task è più delicato, soprattutto per questioni di privilegi e di permessi. Molto interessante sembra il Crontab manager proposto da NetTusPlus. Per iniziare, comunque, si può momentaneamente accantonare. Presi per buoni gli script forniti con il relay e rimandato il problema dei permessi, l’applicazione web è piuttosto semplice, quasi scolastica appunto.
    L’accesso, ovviamente, dovrà avvenire tramite un token di autenticazione, senza gestione delle utenze. Tutto su http semplice, non mi sembra necessario fare https.

Conclusione

Fatti tutti i conti, mi sembra proprio che si possa fare. Vediamo di comprare quel che serve.

Il Raspberry PI, con la SD da 8Gb e Raspbian già installato, l’interfaccia WiFi USB e il case trasparente mi è costato 54.52 €, spedizione inclusa.
Il relay mi è costato 23.00 € più 2.50 € di spedizione, per un totale di 25.50 €.

Messo tutto insieme, la spesa per l’elettronica è di 80.02 €.
Non mi resta che aspettare i pacchetti.

 

[Segue a http://sergiovaccaro.it/domotica-il-riscaldamento-controllato-via-web-con-raspberry-pi-2/]