Tips: Non solo Dropbox

Tutti ormai conosciamo, ed in buona parte siamo dipendenti, dai servizi di sincronizzazione di file come Dropbox o i molti servizi alternativi dello stesso tipo. Sono servizi fantastici, in quanto la loro natura set-and-forget permette di avere sempre i propri file sincronizzati su una o più macchine, e/o con i propri collaboratori, senza alcuno sforzo aggiuntivo.

In alcuni casi, però, si vorrebbe avere un maggior controllo sui propri file: il “cloud” è bello, ma cedere la gestione dei propri file ad un’azienda esterna a volte può essere preoccupante, soprattutto se si tratta di documenti aziendali di carattere riservato.

Ultimamente sto sperimentando, per ora su piccola scala, un prodotto che si chiama ownCloud, e che ha il vantaggio di poter essere installato sul proprio server. Essendo open source, è compatibile con molte delle distribuzioni linux, ed in oltre si iniziano a trovare dei server che fanno hosting del servizio. In particolare, su OpenSUSE 12.3 l’installazione è stata condotta il 30 secondi utilizzando il pacchetto di installazione.

La modalità di funzionamento è simile a Dropbox, dove i propri dati sono salvati su un server (e sono accessibili anche via web, con tanto di accesso alle versioni precedenti ed ai file cancellati), mentre sulle proprie macchine occorre installare un piccolo “client” di sincronizzazione (disponibile per tutti i sistemi operativi, compresi quelli mobili, anche se per questi ultimi è a pagamento).

Oltre al fatto di poter decidere dove memorizzare i propri dati (eventualmente su un proprio server aziendale, assumendosi ovviamente la responsabilità della gestione e dell’integrità degli stessi), un altro vantaggio è dato dalla possibilità di definire molte cartelle di sincronizzazione indipendenti, e non necessariamente solamente il contenuto di un’unica cartella. Le funzioni di condivisione sono anche più avanzate in quanto prevedono la nozione esplicita di “gruppi”.

Il client è molto essenziale ed un po’ immaturo, ma l’impressione è che lo sviluppo proceda rapidamente (da pochi giorni è disponibile una nuova versione sensibilmente modificata).

Sicuramente un prodotto da tenere sul radar e continuare a provare.

L’abbandono di sun.com

Chi ha assistito allo sviluppo dei primi anni di Internet avrà certamente un particolare affetto per la Sun Microsystems, che con le proprie SparcStation ha diffuso le workstation grafiche basate su Unix (pardon, SunOs, poi divenuto Solaris) negli ambienti di ricerca e di ufficio. Ricordo ancora la workstation su cui ho svolto la tesi, che con il suo monitor 17” a colori, l’ambiente grafico X-Windows, mouse e CPU RISC faceva morire di invidia i colleghi che lavoravano su terminali VT100 o DECterm.

Più recentemente, il nome Sun si è guadagnato un nome nel campo del software per avere creato e fatto crescere il linguaggio Java e tutto l’ecosistema che ne deriva. Che siate fan di Java o acerrimi oppositori, sicuramente non è qualcosa che si possa ignorare ed ha profondamente influenzato lo sviluppo di applicazioni software nell’ultimo decennio.

A chi ha vissuto queste fasi certamente l’acquisizione di Sun da parte di Oracle non ha certamente fatto piacere, più che altro per l’immagine di multinazionale vorace che Oracle ha sempre fatto di tutto per guadagnarsi.

Ora leggo che il dominio sun.com sarà abbandonato da Oracle: parte del contenuto sarà trasferito su qualche sito sotto il dominio oracle.com (come ha già iniziato a succedere sin dall’acquisizione), ed il resto semplicemente sarà abbandonato.

È pur vero che nulla può durare per sempre, ma qui si tratta veramente di demolire un nome storico per pure ragioni (non del tutto condivisibili) di immagine e di marketing. Anche perché le motivazioni sul costo del mantenere attivo il dominio, addotte da Oracle, sono realmente patetiche oltre che infondate.

Murphy non dorme…

…e nello scorso week-end è passato a trovarmi.

Qualsiasi ingegnere (e non solo, direi chiunque abbia a che fare con la scienza o la tecnologia, come utente o come ricercatore o sviluppatore) ha sempre una forte adorazione riverenziale per la Legge di Murphy.

Ed è per me un onore testimoniare che Murphy ha prestato attenzione alla mia umile persona e dimora, pochi giorni fa.

Non si potrebbe spiegare altrimenti una contemporanea ed improbabile moria di oggetti tecnologici nelle mie vicinanze. Andando con ordine, nell’arco di due giorni sono passati a nuova vita:

1. un alimentatore per notebook (originale HP), che poiché presentava in uscita una tensione di 0 V, è stato prti fontamente sostituito con esborso di euro
2. il circuito di carica del notebook HP che mi aveva fedelmente servito da 4 anni: il PC funziona ancora perfettamente, ma non riceve alimentazione dal trasformatore (neppure da quello nuovo, che a questo punto ho comprato inutilmente, ed è in questi dettagli che si apprezza il genio di Murphy), per cui una volta scaricate le batterie, kaputt… non vi è più nulla da fare
3. l’alimentatore del PC fisso che avevo in casa (rimasto l’unico disponibile, ovviamente, dopo l’ammutinamento del portatile). O meglio, si è guastata la ventola dell’alimentatore. Ma anche probabilmente il circuito di protezione, per cui a ventola ferma l’alimentatore non si è disabilitato (come dovrebbe), ma a continuato a lavorare producendo calore sufficiente a deformare le parti circostanti. Basta ovviamente cambiare l’alimentatore. Senonché ti fanno sapere che di quella forma e potenza ve ne sono pochi in giro, e sarà difficile (o lungo) trovare il sostituto.
4. il mattino dopo ovviamente ti svegli di buona lena, intenzionato a comprare il trasformatore (speri ancora di trovarlo al primo colpo) e ad informarti sui prezzi dei notebook (sapendo già che farà male al portafoglio ricomprare un PC intero per un solo integrato morto ma non riparabile perché HP lo posiziona in modo da dover cambiare l’intera scheda madre). Ovviamente tutto il programma della mattina salta perché ti accorgi di avere l’orologio bloccato sull’ora sbagliata. E speriamo che sia solo la batteria…

L’unica nota positiva, l’unico punto di orgoglio: non ho perso neppure un file, neppure un byte, neppure una mail, neppure un bookmark né in indirizzo di mail. L’ho sempre sentito che essere paranoici sui backup, alla fine, paga. E d’ora in avanti farò più attenzione all’ipotesi implicita che “è troppo improbabile che si guastino due cose contemporaneamente”.

Backup: BackupPC su OpenSuse

Una delle prime cose che solitamente cerco di fare capire ai miei studenti del primo anno, o comunque a chi si avvicina all’informatica, è l’importanza dei backup.

Immaginate se, arrivando a casa (o in ufficio) scopriste che il vostro computer non parte più, perché si è guastato l’hard disk. Succede, sempre, è solo questione di tempo. Questione di “quando succederà”, non di “se succederà”.

A questo punto chiedetevi: a quando risale l’ultima copia di sicurezza dei miei dati?

L’unico modo per essere certi di non perdere dati è quello di dotarsi di un sistema di backup automatico, che non richieda interventi umani né di ricordarsi “che cosa avrò modificato nell’ultima settimana?”. Idealmente, un backup gira da solo, magari di notte, e copia diligentemente tutti i file modificati.

Fortunatamente Windows 7 ora integra già un sistema di backup automatico ed incrementale, che permettere di salvare i propri dati su un server di rete.

Per i gruppi di lavoro, ad esempio dove noi usiamo dei server Linux, esistono tre soluzioni open source solitamente adottate: amanda, bacula e BackupPC. Personalmente ho usato per diversi anni amanda, quando facevo backup su nastro di una rete di server Sun. Non ho mai usato bacula, mentre per i backup su disco uso BackupPC.

Tutto questo lungo discorso per segnalare che, su OpenSuse 11.2, la distribuzione di BackupPC non funziona automaticamente, perché ci sono incompatibilità tra le impostazioni di sicurezza del server apache (che non accetta di eseguire degli script cgi-bin con setuid) ed i prerequisiti del tool di amministrazione via web, che invece richiede il setuid su uno script CGI.

L’incompatibilità si può risolvere grazie all’utilizzo del modulo mod_suexec di apache per forzare l’identità dell’utente che esegue uno script CGI, senza dover ricorrere ai setuid bit. Le istruzioni sono reperibili nel seguente messaggio: http://www.mail-archive.com/backuppc-users@lists.sourceforge.net/msg02018.html. Unica avvertenza (non specificata nel documento linkato): ricordarsi di rendere /usr/sbin/suexec2 setuid root (permessi -rwsr-xr-x), altrimenti apache non riesce comunque a cambiare utente.

Magari a qualcun altro potrà essere utile… sicuramente lo sarà per me, la prossima volta che dovrò reinstallare un server!

Acrobazie LDAP

In questi giorni ho potuto apprezzare una volta di più la flessibilità dei sistemi operativi basati su linux (o unix in generale), specie quando devi compiere operazioni di amministrazione di sistema un po’ fuori dal normale.
In questo caso sto gestendo la migrazione degli utenti di un server che era basato su una vecchia versione di Mandriva, e gestiva il database utenti su un server LDAP utilizzando una serie di script (smbldap) da tempo non supportati, migrando il tutto su un nuovo server con openSUSE 11.2. L’obiettivo è continuare ad utilizzare un backend LDAP, ma rimappando la rappresentazione dei dati (il cosiddetto schema LDAP) secondo quanto gestito nativamente dall’ottimo strumento di amministrazione YaST proprio di openSUSE.
Durante la migrazione volevo anche cambiare il login name di alcuni utenti (principalmente come blanda misura antispam) e cancellare altri utenti, non più necessari. Il tutto senza conoscere la password di nessuno, quindi dovevo preservare tutte le password presenti.
LDAP è una di quelle cose che devi affrontare poco per volta, è un directory server di cui la documentazione ti dice tutto ciò che ti server per creare dei fantasmagorici schema personalizzati, e come interrogarli con query anche molto complesse. Ma nessuno ti dice chiaramente come le varie distribuzioni Linux memorizzano i dati degli utenti al suo interno.
O meglio, le informazioni ci sono, anche se poco leggibili, nelle RFC 2256 (A Summary of the X.500(96) User Schema for use with LDAPv3) e RFC 2307 (An Approach for Using LDAP as a Network Information Service). Devi solo leggerle 3 volte, per capire che tutta l’informazione relativa ad un utente si può riassumere in:

dn: uid=loginname,ou=people,dc=cad,dc=polito,dc=it
objectClass: top
objectClass: inetOrgPerson
objectClass: posixAccount
cn: Nome Cognome
sn: Cognome
givenName: Nome
uid: loginname
uidNumber: 12345
gidNumber: 13254
homeDirectory: /home/loginname
loginShell: /bin/bash
userPassword:: e1NTS********dYUmw=

I campi in corsivo sono quelli relativi ad ogni singolo utente, e la userPassword ovviamente è stata modificata per motivi di sicurezza.








Non rimane che creare un bel file di testo contenente esattamente queste informazioni, esportando dal server LDIF precedente quanto serviva, eliminare gli attributi non più utilizzati, rinominare gli attributi che venivano usati in modo diverso nei due schema, ed infine eliminare gli utenti non più desiderati. Alla fine si importa tutto nel nuovo server LDIF, et voilà, login al primo colpo!


I vari passaggi seguiti non sono così interessanti da esser divulgati qui, ma voglio segnalare i principali tool utilizzati:

• per esportare i dati da un server LDAP usiamo ldapsearch

ldapsearch -L -x -D 'cn=Administrator,dc=cad,dc=polito,dc=it' -W \
-b 'ou=Users,dc=cad,dc=polito,dc=it' '(objectclass=posixAccount)' 

• per eliminare gli attributi non desiderati, niente di meglio di una serie di grep –v

ldapsearch -L -x -D 'cn=Administrator,dc=cad,dc=polito,dc=it' -W \
-b 'ou=Users,dc=cad,dc=polito,dc=it' '(objectclass=posixAccount)'

• per rinominare attributi o valori, un po’ di sed e di regular expression

sed 's/uid=\(.*\),ou=Users/uid=\1,ou=people/'

• infine, per i ritocchi manuali, il grande ldapvi

ldapvi -D cn=Administrator,dc=cad,dc=polito,dc=it

Provate a fare lo stesso su un sistema Windows!