Opzioni Bind su Debian con SystemD

Debian 8 si è ormai allineato alle altre distribuzioni passando a SystemD per la gestione e l’avvio dei servizi di sistema. Per la gestione dei comandi di avvio, spegnimento o riavvio dei servizi si utilizzano infatti i file presenti in /lib/systemd/system che vanno a sostituire i sistemi ormai deprecati basati su script bash in /etc/init.d.

Nel caso di Bind una delle opzioni più utilizzate è quella per disabilitare l’IPv6, che consiste nell’aggiungere il parametro -4 alla linea di comando di avvio. Per fare questo si modificava la variabile OPTIONS presente in /etc/default/bind9, ma con il nuovo sistema quesot file viene praticamente ignorato.

Per risolver il problema è possibile modificare direttamente il file /lib/systemd/system/bind9.service modificando il parametro ExecStart, oppure è possibile aggiungere una direttiva per specificare in quale file vengono impostate le variabili d’ambiente.

Ecco un esempio del file bind9.service:

Il file /etc/default/bind9 va modificato in questo modo:

Notare che è stato aggiungo il parametro -f necessario per il corretto funzionamento di named in systemd.

Linea vuota sul crontab

Quando nei sistemi Linux si configurano operazioni da eseguire periodicamente tramite cronjobs utente (crontab -e) è opportuno ricordarsi di inserire una riga vuota alla fine del file. In caso contrario cron ignora l’intero contenuto del file e non esegue nessuna delle operazioni pianificate.

Creare una rete privata virtuale con OpenVPN

Al giorno d’oggi le reti private virtuali sono uno strumento fondamentale per chi lavora in remoto o chi vuole accedere in modo sicuro a risorse esterne senza dover esporre i servizi direttamente sulla rete pubblica. La VPN permette di creare una vera e propria LAN dedicata in cui far accedere solo i dispositivi considerati Trusted, o consente l’accesso a reti già esistenti attraverso sistemi di autenticazione, cifratura o accesso selettivo.

Tra le varie soluzioni esistenti ricopre un ruolo fondamentale la PPTP, ben supportata dai sistemi Apple (compresi iPad ed iPhone), su Android e dai sistemi Windows grazie ad un’integrazione nativa. Questa soluzione, oltre ad essere ormai datata, presenta diverse lacune dal punto di vista della sicurezza, ed inoltre si basa su un tunnel GRE (protocollo IP 47) per il traffico dati punto-punto, soluzione che spesso costringe a configurazioni particolari sopratutto nel caso in cui sia necessario stabilire più VPN sulla stessa macchina.

Una delle soluzioni più utilizzate oggi in campo enterprise è l’IPSec. In realtà con il termine IPSec si intende tutta una serie di strumenti utilizzati per cifrare, certificare e rendere sicuro il traffico all’interno di reti generiche, ma l’utilizzo più diffuso si ha nella creazione di VPN. Il sistema è largamente supportato da router/firewall hardware come Cisco o Juniper e sui sistemi Windows è presente un client nativo che consente di creare tunnel con protocollo L2TP/IPSec. Nei sistemi operativi Linux è necessaria l’installazione di software dedicati come OpenSWAN. La tecnologia è molto robusta dal punto di vista della sicurezza ma è più complessa rispetto ad altre soluzioni e richiede una configurazione molto articolata per un corretto funzionamento.

Al giorno d’oggi si stanno diffondendo diverse soluzioni proprietarie che fanno uso di client specifici installati sul sistema operativo. Se da un lato questa soluzione rende più semplice la connessione, dall’altro complica il libero utilizzo del computer perché i client installati sono in grado di configurare ogni aspetto del sistema operativo, comprese le regole di routing, DNS e firewall. Queste configurazioni sono necessarie per le VPN che di fatto inseriscono i PC direttamente nelle reti aziendali.

Una delle soluzioni più sicure, efficaci, meno invasive e sopratutto OpenSource è OpenVPN. Questo sistema, che ultimamente si sta diffondendo anche grazie a delle personalizzazioni commerciali spesso fornite con firewall hardware, fa uso di una soluzione mista tra un driver kernelspace ed un demone userspace. Di fatto il driver crea un’interfaccia di rete virtuale che può dialogare con le altre interfacce degli altri nodi per mezzo del demone in esecuzione.

La soluzione comprende autenticazioni per mezzo di certificati SSL fino a 4096 bit e può utilizzare sistemi di cifratura come l’AES-256. Il traffico dati tra un demone e l’altro può avvenire per mezzo di connessioni TCP o UDP, con porte completamente configurabili. Uno dei punti di forza di questa tecnologia è quello di poter lavorare sia in modalità “tun” che in modalità “tap”. La prima stabilisce una connessione punto punto in Layer3 ISO/OSI, mentre la seconda stabilisce un link su Layer2 ISO/OSI consentendo di creare un vero e proprio Switch di rete virtuale al quale ogni client accede e si collega.

Ho iniziato una piccola guida per la creazione di una VPN semplice da configurare. Potete trovarla nella pagina dedicata.

Linux live boot problem with KMS

The Linux Kernel support for modern video cards nowadays improves day by day, thanks to the great work in Open Source drivers. A new graphic system for Linux Kernel was introduced several years ago to support higher resolutions and deeper color space directly into the kernel-space rather than user-space, allowing fast virtual terminal switch and better video/monitor support. This system is called “Kernel ModeSetting”.

But sometimes the system fails to proper recognize how to setup the video card starting from the very boot sequence. The system may hangs during MKS-enabling and frame buffer module loading, especially booting in live systems.

In case of problems, Kernel Modesetting can be disabled in boot time editing the Kernel Command Line from your bootloader (lilo or grub) by simply adding this flag:

In this way your kernel will boot in standard VGA screen resolution allowing at least the usage of a standard console for data recovery or system backup.

Arduino Yun continuous reset

Default Arduino Yun behavior is to wait for WiFi interface to work.
If you disable Wireless interface (maybe if you want to use it as a simple Arduino with Ethernet features), its startup system will run a command called “wifi-live-or-reset” and your arduino will auto-reset about every minute.

If you don’t need WiFi feature, just comment out the line in your /etc/rc.local startup file and your Arduino starts working as expected.

If you have already disabled WiFi interface, you have to do it as faster as possible, just before your system reboot.

ioQuake3 Ubuntu mouse

ioQuake3 su Ubuntu e derivate ha un problema con il mouse.

Il puntatore ritorna automaticamente alla posizione di partenza circa ogni 1 o 2 secondi. Il problema si presenta fin dall’inizio del gioco, rendendo quasi impossibile selezionare le voci del menù e spostando la visuale durante il gioco.

Il problema si verifica in entrambe le versioni 32 e 64 bit.

Per risolvere il problema è sufficiente lanciare il binario impostando una variabile su BASH:

In questo modo il mouse si comporta in maniera corretta.

SolarMax LoGgeR

New version of SolarMax LoGgeR released.

New release implement Command Line Options and support using a configuration file.

All source code is available at https://github.com/sardylan/smlgr

I keep an instance running into a RaspberryPi with an external MySQL database. Binary executable built and stripped for ARM architecture is only 17KB.

Statistiche sul fotovoltaico

Pannelli fotovoltaici
Pannelli fotovoltaici

Al giorno d’oggi è sempre più frequente vedere nei tetti delle case impianti fotovoltaici per la produzione di energia elettrica. La diminuzione dei costi di produzione e lo sviluppo tecnologico stanno portando alla creazione di impianti sempre più moderni e all’avanguardia, ed in un mondo sempre più smart l’informatica non poteva di certo stare fuori da un ambiente in continuo sviluppo come questo.

Ogni impianto fotovoltaico, oltre ai pannelli sul tetto ed i vari cavi, possiede un inverter che si occupa di “convertire” la corrente continua prodotta dai pannelli in corrente alternata adatta ad essere immessa nella rete di distribuzione.
Ed è proprio l’inverter il cuore pulsante di ogni impianto, apparecchi che al giorno d’oggi sono diventati, oltre alla parte per così dire “di potenza”, dei veri e propri computer, molti dei quali con porte di comunicazione seriale o perfino schede ethernet.

Nell’impianto a casa dei miei genitori è stato installato un inverter modello S3000 prodotto dalla casa svizzera SolarMax. Questo modello può erogare una potenza istantanea massima di 2750 Watt e possiede una porta ethernet con connettore RJ45 sul fondo per essere interfacciata con altri dispositivi della casa produttrice oppure per essere interrogato con dei software ufficiali prodotti dalla stessa SolarMax (disponibili per Linux, Mac, Windows e perfino per Android).

SolarMax S3000
SolarMax S3000

Grazie alle preziose informazioni raccolte in questo post, dove è accuratamente spiegato il protocollo di comunicazione tra l’inverter ed i vari software, ho potuto realizzare un piccolo demone scritto in linguaggio C (smlgr, disponibile in GPLv2 su GitHub) che si occupa di interrogare l’inverter circa ogni 10 secondi per poi memorizzare i dati in un database MySQL. Il demone è molto leggero e consuma pochissima RAM. Dipende solo dalle librerie MySQL ed è possibile compilarlo ed installarlo perfino a bordo di un router.
Dopo che i dati sono memorizzati su database possono essere interpretati semplicemente con una serie di pagine in PHP (anche questo progetto è disponibile su GitHub).

Per realizzare il tutto ci sono voluti circa 2 giorni.
Il primo problema da risolvere è stato collegare l’inverter alla LAN interna. Tutti gli apparati di rete (Modem, Router e AccessPoint) stanno al piano di sopra, mentre l’inverter è stato installato nel garage. Si potrebbe potuto passare un cavo di rete nell’impianto elettrico, ma per ora ho deciso di utilizzare un link WiFi usando una Fonera 2100 con firmware OpenWRT configurato per lavorare in modalità client (e non Access Point) così da agganciarsi al già esistente segnale WiFi della casa e collegare la sua porta ethernet alla LAN.

Fonera serial interface
Fonera serial interface
Flashing Fonera with OpenWRT
Flashing Fonera with OpenWRT

A causa dell’hardware della fonera non è possibile configurare in bridge le due interfacce di rete (via cavo e wifi), quindi ho dovuto configurare la fonera per abilitare il forwarding tra le due interfacce ed ho dovuto aggiungere una route statica nel router domestico.
Inoltre la Fonera è famosa per essere un apparecchio che scalda parecchio, specialmente in periodi caldi dell’anno.
Per ovviare a questo problema ho forato il coperchio superiore della fonera ed ho installato una vecchia ventola per CPU alimentandola a 5 Volt invece che a 12, così da farla girare molto più lentamente, facendo meno rumore e durando più a lungo, e garantire un flusso d’aria continuo.

Fonera Wi-Fi client
Fonera Wi-Fi client

Una volta collegato l’inverter alla LAN ho iniziato a realizzare il demone scrivendo in C le varie funzioni. Non ho ancora raggiunto una versione stabile, però posso già dire che il sistema funziona e memorizza i dati sul database, e sopratutto il continua a funzionare sia nel caso un cui il database dovesse andare off-line, sia nelle ore notturne in cui inverter si spegne e non risponde più alle richieste del socket.

La cosa più difficile è stato gestire le stringhe di comunicazione ed implementare quindi il protocollo creato dalla SolarMax. Grazie alle utilissime informazioni del post son riuscito a scrivere una funzione che mi prepara la stringa da inviare all’inverter per interrogarlo ed una funzione per parsare la risposta.

Ogni stringa è chiusa tra parentesi grafe ed è divisa in 3 sezioni separate da un simbolo di pipe (|).
La prima a sinistra contiene nell’ordine l’indirizzo del “mittente”, quello del “destinatario” e la lunghezza del messaggio. FB identifica il computer, mentre 01 è il numero dell’inverter configurabile nel menù dell’inverter stesso, ed utile nel caso in cui nell’impianto siano presenti più di un inverter.
In questo caso 32 è la lunghezza in bytes dell’intero messaggio comprese le parentesi grafe, espressa in numero esadecimale. La lunghezza sarà quindi sempre pari a 13 + lunghezza della query + 6.
La seconda parte inizia sempre con “64:” ed è seguita dalla query.
Nella terza ed ultima parte è presente il checksum della stringa. Su questa parte ho perso un po’ di tempo, ma alla fine ho capito che si tratta della somma di tutti i valori ASCII dell’intera stringa limitata a 16 bits, cosa che si può facilmente ottenere con l’operatore modulo, ed espressa sempre in esadecimale aggiungendo zeri fino ad ottenere 4 cifre. Il checksum va calcolato in tutti i caratteri a partire da “FB” fino all’ultima pipe compresa (escludendo quindi la prima parentesi grafa). La stringa deve essere formattata correttamente, ed i valori di lunghezza e checksum devono essere corretti, altrimenti l’inverter non risponderà.

Inviando la stringa così formattata si riceve in risposta una stringa simile, con in più i valori sempre espressi in esadecimale.
Si può notare che i valori di “mittente” e “destinatario” del messaggio ora sono giustamente invertiti, che il valore della lunghezza è superiore rispetto a prima (ora contiene anche i valori), e che il checksum è differente. Tutti i parametri sono riproposti nello stesso ordine dell’interrogazione, e ciascuno è seguito da un segno = e dal corrispondente valore.
Tralasciando la parte iniziale e finale, ho splittato la stringa in più parametri usando il carattere ; come separatore, e su ciascuna porzione ho usato il segno = per separare i parametri dai valori. In questo modo ho creato una lista circolare di argomenti da usare per costruire la query SQL per la memorizzazione dei dati.
Il demone come prima cosa crea e connette il socket, poi invia i dati. Quando riceve la risposta, la interpreta e salva le informazioni sul database. Alla fine chiude la connessione al DB, chiude il socket e rimane in sleep per 10 secondi. Il tutto è racchiuso in un ciclo while infinito.
Tutte queste operazioni sono sequenziali. Se una fallisce, le successive non vengono eseguite. In questo modo mi assicuro che se l’inverter non risponde (spento oppure non c’è connessione) il demone non crasha e continua il suo ciclo finché non ritorna raggiungibile. Idem per il database, dove la connessione viene ogni volta aperta e chiusa. Se l’inverter funziona ma il database non risponde i dati vengono scartati senza interrompere il funzionamento del demone.

Nel database MySQL occorre creare una tabella che contenga un campo per ogni parametro richiesto, infatti il demone salva nel database i valori chiamandoli con lo stesso nome dei parametri. È necessario inoltre aggiungere un campo che contenga il timestamp in cui è stata fatta l’interrogazione.
Questo è un esempio di query SQL eseguita dal demone:

Al momento della creazione della tabella, i campi relativi ai valori sono stati creati di tipo INT. In questo modo è possibile esprimere i valori da inserire usando direttamente la notazione esadecimale e quindi inserendo i valori così come sono stati inviati dall’inverter, semplicemente aggiungendo all’inizio la stringa “0x”.

smlgr working
smlgr working

Per l’interpretazione dei dati è possibile usare in qualsiasi sistema che può interfacciarsi con il database MySQL.
Ho creato un piccolo sito internet scritto in PHP e jQuery che mi visualizza in tempo reale l’andamendo della produzione. Avendo i dati sul DB ed avendo un refresh di circa 10 secondi è possibile fare un’analisi sulla produzione di energia sia sulla base oraria, sia giornaliera, ma anche a lungo termine.

Tutta l’infrastruttura gira a bordo di una Raspberry Pi model B, e consuma pochissima CPU e poca RAM.

smlgr Web Interface
smlgr Web Interface

Icecast + MySQL Stats

Icecast è ormai considerato uno dei migliore software per realizzare un server di relay per flussi audio in streaming basato su formati e codice Open Source. Non solo è stato uno dei primi a supportare più flussi su un unico server, ma può essere usato anche con flussi audio/video basati su formati OGG.

Per quanto riguarda le statistiche di ascolto, il software di per se fornisce già alcuni dati come il numero di ascoltatori attuali per ogni flusso e quello del picco massimo, e consente di ottenere informazioni maggiori usando soluzioni esterne, come parser i files di log oppure software esterni che interrogano periodicamente il server.

Faccio parte del Team di UnicaRadio, la webradio degli Studenti dell’Università di Cagliari. Lavorando nell’ambiente ho capito l’importanza di un dato come il tempo medio di permanenza degli ascoltatori. Dopo aver valutato diverse soluzioni e provato diversi software, ho deciso di implementare la cosa lavorando direttamente sul codice sorgente, così da ottenere data ed ora di connessione e disconnessione di ogni singolo ascoltatore.

L’uso di un database esterno mi è sembrata la migliore soluzione, sia per l’inserimento dei dati da parte di Icecast, sia per la consultazione delle statistiche ottenute che può essere implementata anche con un semplice sito internet PHP+HTML.

Ho creato un repository su GitHub, raggiungibile all’indirizzo https://github.com/sardylan/icecast-mysql nel quale a breve riporterò tutte le modifiche che ho fatto fin’ora al sorgente originale.

Stay Tuned…