Archivi tag: software libero

Munin: monitorare macchine remote senza SNMP

cpu-munin.pngLa gestione remota di un sistema server è una delle grandi problematiche di chi si occupa di fornitura di servizi informatici. Soprattutto quando i sistemi in gestione sono molti, e magari dislocati in aree diverse del territorio, il tener monitorata la situazione di tutti i sistemi senza dover passare la propria giornata lavorativa con questo unico scopo, comporta l’uso di una serie di tecnologie.

Per anni, uno dei modi più utilizzati per questo scopo è stato il protocollo SNMP, che consente (oltre alla gestione remota di apparati) l’analisi prestazionale di server ed apparecchiature di rete. I problemi di sicurezza intrinsechi del protocollo però (anche semplicemente la possibilità di gestire remotamente un apparato che esponga un servizio SNMP), hanno reso sempre piuttosto diffidenti i sistemisti nella massiccia adozione di questa tecnologia, pur efficace. Inoltre la non banale configurazione degli strumenti OpenSource in grado di dialogare con SNMP per generare dei grafici che consentano di capire e monitorare l’andamento dei sistemi (MRTG), non ha certo semplificato il lavoro.

Per ovviare a questo problema, è nato un interessante pacchetto applicativo, munin, il cui preciso scopo è quello di rendere semplice ed intuitiva la gestione del monitoraggio remoto anche di numerosi sistemi. In grado di interfacciarsi all’occorrenza anche con periferiche SNMP (per includere nel monitoraggio anche apparecchiature di rete limitando comunque l’esposizione dei servizi SNMP alla rete locale), munin si avvale di una struttura modulare e di un protocollo testuale piuttosto semplice, oltre che di una strutturazione client-server piuttosto semplice da configurare.

Strutturazione

Come si accennava, munin ha una struttura “client-server”: sui nodi da monitorare verrà installata la parte server, che dialoga con l’hardware e raccoglie le informazioni su richiesta del client; questi invece si occupa di contattare i vari server, collezionare i dati e generare delle paginette web con i grafi statistici risultanti dai dati raccolti, tracciati grazie all’uso di RRD Tool.

Installazione e configurazione (debian)

L’installazione, in debian perlomeno, è resa banale dal fatto che sia la parte client che la parte server di munin sono già pacchettizzate. Sarà sufficiente installarli per avere già una prima parte di monitoraggio, che comprende alcuni dati standard quali uso dei filesystem e della memoria, carico del sistema, carico di rete, monitoraggio delle connessioni entranti, entropia disponibile sul sistema, numero di processi e “fork rate”. Il pacchetto “server” si chiama “munin-node”, e viene avviato automaticamente al momento della sua installazione, mentre il pacchetto client andrà configurato adeguatamente come vedremo. Per installare sia il client che il server, daremo il comando

# apt-get install munin munin-node

Potete dare un’occhiata al file di configurazione della parte server di munin, /etc/munin/munin-node.conf che è comunque piuttosto semplice e scarno. L’unico dato eventualmente da modificaere, potrebbe essere il nome dell’host da comunicare al/ai client, che trovate commentato nella versione originale del file di configurazione e che porta quindi munin ad utilizzare i nomi riportati in /etc/hosts per questo aspetto. Altro parametro che potrebbe risultare importante da modificare è l’elenco degli host dai quali accettare connessioni (di default il solo 127.0.0.1), aggiungendoli (sotto forma di espressioni regolari) all’ultima riga del file citato.
La configurazione del nodo è in parte automatizzata dall’applicativo munin-node-configure incluso nel pacchetto e che analizza tutti i plugins installati(che trovate in /usr/share/munin/plugins/) alla ricerca di quelli che hanno un senso sul sistema locale. Questo viene fatto grazie ad un sistema di autoconfigurazione che viene implementato dai vari plugins, i quali rispondono dovrebbero rispondere ad una loro esecuzione con il parametro “autoconf” con un “yes” o con un “no” (o addirittura con dei suggerimenti sulla configurazione) a seconda che il plugin possa funzionare o meno sul sistema. Per aggiungere un plugin a quelli da far utilizzare a munin, sarà sufficiente farne un link simbolico (eventualmente componendone adeguatamente il nome) all’interno della directory /etc/munin/plugins/. Ad esempio, per aggiungere il monitoraggio dell’uptime di sistema e del traffico dell’interfaccia di rete ‘eth1’, sarà sufficiente dare i seguenti comandi:

# ln -s /usr/share/munin/plugins/uptime /etc/munin/plugins/
# ln -s /usr/share/munin/plugins/if_eth1 /etc/munin/plugins/

Al termine della configurazione, basterà riavviare munin per applicare le modifiche richieste

# /etc/init.d/munin-node restart

Alcuni plugins richiedono una configurazione particolare per funzionare: ad esempio i plugin di analisi del traffico, dei processi e del volume di dati scambiato dal server web apache, richiedono che venga attivato, sul server web, una particolare pagina (server-status) che riporta questi dati. Le eventuali configurazioni necessarie al funzionamento dei plugins sono solitamente indicate all’interno dell’intestazione del plugin stesso. Per verificare il funzionamento di un plugin, può essere utile eseguirlo e verificare che stampi a video dati numerici (e non stringhe di errore, o il valore ‘U’)

root@giotto:/etc/munin# /etc/munin/plugins/cpu
user.value 24249601
nice.value 26903
system.value 2823798
idle.value 582652748
iowait.value 287010
irq.value 96008
softirq.value 104576

Per quanto riguarda invece al configurazione della parte client, il discorso non è poi molto più complicato. Mettendo le mani nel file /etc/munin/munin.conf, potremo definire l’elenco degli host che il client dovrà contattare ad ogni esecuzione (che dovrebbe essere automaticamente inclusa in cron al momento dell’installazione del pacchetto client), il “nome host” che dovrà richiedere (uno stesso server può gestire, come vedremo, diversi host), l’indirizzo ip da contattare (o il nome fqdn), ed eventualmente il parametro “use_node_name”, che limita, se impostato ad un valore positivo (“yes”, “y” o “1”), il fetch dei dati ai soli configurati per il nodo (escludendo ad esempio macchine monitorate in snmp da quel nodo).

Non troverete username ne passwords: il protocollo di munin, estraendo solamente dati (non è pensato per fare gestione remota dell’apparato come invece è possibile fare con SNMP), non prevede una fase di autenticazione. Per questo motivo può essere interessante configurare munin per accettare connessioni solamente da localhost ed utilizzare ssh per mappare (sotto cifratura) la porta di munin-node (di dafault la 4949) sul sistema che fa il fetch dei dati (dedicherò alla questione un post ad-hoc, nei prossimi giorni).

Il risultato

Una volta che avrete terminato la configurazione del server e del client, quest’ultimo comincerà a generare (di default il /var/www/munin/) delle pagine html che riportano i dati raccolti. Un esempio del risultato, potete trovarlo direttamente sul sito di Munin. Un aspetto interessante di questa interfaccia web, oltre a consentire una comoda visualizzazione dei dati (eventualmente raccolti anche per gruppi, modificando adeguatamente munin.conf), è che nella pagina di riepilogo colora diversamente le sezioni dei vari nodi a seconda dei risultati raccolti: se ad esempio uno dei dischi di un sistema si sta riempiendo, oltre ad inviare una mail all’indirizzo riportato in munin-node.conf (sempre che lo abbiate decommentato) apparirà dapprima in giallo, poi in rosso, nella pagina web, richiamando la vostra attenzione.

GPLv3: pensieri volanti

Ieri sera notte, mentre cercavo di convincere Danilo che era ampiamente ora di andare a dormire (tentativo fallito, visto che alla fine ha dormito su un tavolo), mi sono trovato a fare quattro interessanti chiacchiere in materia di “GPLv2 vs. GPLv3” insieme a Guido Serra, Marco Bertorello, Matteo Flora e Daniel Donato, dell’HackLab 81100.
Dal discorso (nonostante i fumi dell’alcool che non risparmiavano probabilmente nessuno dei partecipanti ed astanti) sono venute fuori una serie di considerazioni interessanti che mi sono annotato e riproposto di elencare qui, a memoria d’uomo.

Tanto per cominciare, GPLv3, a differenza della GPLv2, richiede (con l’obiettivo di combattere la TiVo-izzazione) il rilascio della “tool-chain”. Questo non significa che debbano essere rilasciati tutti gli apparati a contorno del software (ad esempio script dello sviluppatore che aiutano nella customizzazione del software, ad esempio), ma semplicemente che l’utente finale, che ha il sorgente a disposizione, deve essere in grado (non è detto che debba poterlo fare comodamente) di ricompilare e reinstallare il software a sua disposizione. L’obiezione di Guido, in ogni caso, rimane pienamente valida: questa ulteriore ristrettezza rispetto alla GPLv2, peggiora il ritorno dell’investimento commerciale che lo sviluppatore potrebbe aver affrontato.
Questo è probabilmente dovuto ad una scelta di fondo, che ad un certo punto si è posta e doveva essere necessariamente affrontata: il rapporto tra software commerciale e software libero. La mia opinione è che con la GPLv2, i “lavoratori del software libero” potevano essere anche sviluppatori, investitori, scrivendo del codice da zero, rilasciaro sotto GPL e vedere comunque un rientro economico tale da coprire l’investimento fatto, perchè veniva sfruttata una “zona grigia”: si tratta di un equilibrio piuttosto delicato del quale qualcuno (Novell ad esempio, nell’ambito dell’accordo con Microsoft di cui tanto si è parlato, ma non è certo la sola) ha abusato, portando ad una revisione di questo argomento nell’ambito dello sviluppo della GPLv3.

La scelta a questo punto era tra mantenimento e garanzia delle “libertà digitali” del software e dei suoi utilizzatori, e attrattiva commercial-industriale dello stesso, è la strada presa dalla GPLv3 è piuttosto palese, nonché ovvia conoscendo i personaggi che ne guidano la filosofia. Questa scelta non è di per sé negativa, ma va preso atto che rende il software libero poco attraente da un punto di vista prettamente commerciale.

Un’interessante osservazione è poi nata dalla discussione, ed è quella sul rilascio dei diritti sui brevetti, che da quel che ricordo la GPLv3 richiede; mentre la GPLv2 non citava in alcun modo i brevetti, lasciando un’alone di indecisione che poteva (forse) essere sfruttato per implementare algoritmi coperti da brevetti software dei quali non si possiedono i diritti (non essendo questi validi in alcune legislazioni, come quelle europee), la GPLv3 ne richiede l’esplicito rilascio, che nonè possibile effettuare se non si possiedono i diritti in questione, ponendo un’ulteriore limitazione alle possibilità di sviluppo, questa volta in senso molto più largo di quello prettamente commerciale.

Infine, si esprimevano dubbi sulla localizzazione della licenza: la GPL è scritta per la legislazione americana. In Italia, è valida? Non va forse a contraddire qualche articolo di qualche legge sui contratti commerciali, o simili, che potrebbero portarla ad essere invalidata? Sotto questo aspetto (il solito paradosso della legislazione e dell’informatica, fatto di frontiere fisiche che esistono nel mondo reale ma non nel mondo digitale), il discorso andrebbe approfondito con persone competenti, perchè io rischio solo di fare inutili congetture ed illazioni 🙂

Giocando con F-Spot, DBus and Gnome-Screensaver

Lavoro duro su F-Spot. Non il solito, banale, “noioso” lavoro si bug-fixing, che in comunque nasconde non poche difficoltà per coloro che, come me, non conoscono a fondo ne il C# ne il codice di F-Spot.

Il gran lavoro di questi giorni è legato al tentativo di fix del bug #427478, che può apparire estremamente semplice a prima vista, ma nasconde una serie di insidie da non sottovalutare.
Scovare il punto del codice di F-Spot dove andare a mettere le mani e lanciare messaggi di “inibizione” e “deinibizione”, è stato piuttosto semplice. Il codice è ben scritto, e con un po’ di ricerche si trova tutto.
Il problema si è posto nel tentativo di comprendere come si potesse parlare con DBus, da Mono. L’unica implementazione di cui ho notizia, è DBus-sharp a cui si fa riferimento anche come “managed D-Bus” in quanto si tratta di una completa riscrittura della libreria, che mal si adattava all’interazione con Mono.

Innanzi tutto sembra che non esistano esempi comprensibili a disposizione. Pullula di casi di test, ma un pezzo di codice d’esempio che faccia la classica cosa stupidissima, non c’è verso di trovarlo. Ci ho bestemmiato dietro per 2 giorni, finché il buon Stephane Delcroix non se n’è uscito con questo sample:

using NDesk.DBus;
using System;

public class ScreenSaver {

        [Interface ("org.gnome.ScreenSaver")]
        public interface IScreenSaver {
                uint Inhibit (string appname, string reason);
                void Lock ();
        }

        public static void Main () {
                IScreenSaver screensaver = Bus.Session.GetObject<IScreenSaver>("org.gnome.ScreenSaver", new ObjectPath ("/org/gnome/ScreenSaver"));
                screensaver.Lock ();
        }
}

da compilare tramite il comando gmcs ScreenSaver.cs -r:NDesk.DBus.dll per ottenere uno stupidissimo programmino che richiede, tramite DBus, l’attivazione dello screensaver di Gnome. Era davvero cosi difficile da ottenere? :/

Una volta capito il meccanismo, inviare la chiamata di inhibit e dehinibit allo screensaver è stato piuttosto semplice, con l’unica difficoltà di dover suddividere il codice in due files, e doverli quindi mettere insieme, inserendo in entrambi tutte le condizioni a contorno per il relativo funzionamento.

Al lavoro su f-spot

Dopo aver giocato a fare lo sviluppatore patchando f-spot, l’altro giorno, mi sono reso conto che ci sta lavorando praticamente il solo Stephane Delcroix. Cosi ho deciso di dargli una mano, cominciando con il fixare qualche bug che le mie competenze sul codice in questione (zero) mi consentono di fare.

code

Nel frattempo ho scoperto che la mia patch relativa a Flickr, è servita a Lor enzo Milesi a sistemare un bug analogo anche per PicasaWeb. Ottimo 🙂

F-Spot, flickr e patch

F-Spot mi piace molto. Funziona bene, mi consente di gestire le foto, di importarle dalla scheda SD o dalla macchina fotografica, di esportarle su Flickr, di taggarle, riordinarle, modificarle… insomma, un bel prodotto, ben fatto.
Peccato che abbia, da tempo immemore ormai, un bug: inverte l’ordine delle foto durante l’upload su Flickr. In realtà lo fà solo se è non è impostato il “Reverse Order” del menu. Il workaround sarebbe semplice, quindi: si abilita il “Reverse Order”, si fà l’upload, e si ripristina l’ordine precedente.

Ma perchè rassegnarsi ad un malfunzionamento? Cosi questa mattina mi sono pescato il codice dell’SVN di sviluppo su Gnome, trovato il punto incriminato, modificato, testato, scritto la patch e l’ho attaccata al bug in questione. Già che c’ero, ho anche segnalato la cosa al team di ArchLinux, in modo che (magari) patchino il pacchetto della distro, in attesa di una nuova release di F-Spot che (spero) integri la patch e corregga il problema.

Il fatto positivo? Avviare la versione SVN di F-Spot modifica la struttura del database delle foto, che è cosi incompatibile con la versione “normale” (0.4.0). Mi sono dovuto pacchettizzare la SVN e lavorare con quella. Pazienz…

Edit: poche ore dopo, la patch viene accettata, integrata, il bug fixato. Ottimo.

Index: f-spot/ChangeLog
===================================================================
— f-spot/ChangeLog (revision 3355)
+++ f-spot/ChangeLog (revision 3356)
@@ -1,5 +1,10 @@
2007-09-10 Stephane Delcroix <stephane@delcroix.org>

+ * src/FlickrExport.cs: ensure correct upload order. Patch from Giacomo
+ Rizzo. Fixes bgo #345864.
+
+2007-09-10 Stephane Delcroix <stephane@delcroix.org>
+
* src/PhotoStore.cs: Creates versions with the same extension as the
default version, not original.

Samba si schiera “in gpl3”

Quando ieri Microsoft ha cominciato ad alzare gli scudi relativamente alla GPLv3, modificando unilateralmente i tanto discussi “patents agreement” stipulati con diverse realtà del mondo dell’opensource, facendo in modo di non trovarsi a distribuire codice coperto da GPLv3, questa era una delle mosse che mi sarei augurato.

Samba passa in GPLv3 (a partire dalla versione 3.2.0), contribuendo attivamente alla lotta contro le pretese, in termini di “proprietà intellettuale”, di Redmond. Infatti dal momento in cui Samba sarà rilasciato con questa nuova licenza, non sarà più possibile distribuirne le nuove versioni ed allo stesso tempo avanzare (dubbie) richieste relativamente a brevetti e proprietà intellettuale.
A giudicare, tra l’altro, dai dati resi pubblici da palamida, Samba è il primo progetto di una certa entità ad adottare la nuova licenza.

Che questa sia la volta buona che Microsoft debba dire addio ad una “propensione verso l’interoperabilità” di facciata (con il sottotitolo “è standard quello che diciamo noi”), e cominci a darsi da fare per l’interoperabilità reale, quella che ha proposto Red Hat e che loro hanno sdegnosamente rifiutato?