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!