Migrazioni - Parte 3/4

Mentre rsync arranca faticosamente noi non perdiamo tempo: copiamoci le configurazioni di Samba e dei smbldap-tools da archiold a archinew. Tutto cio' non presenta particolari difficoltà, limitiamoci a seguire la nostra guida "attingendo" da archiold ove possibile, ma prestando attenzione ad una cosa importante: il SID del dominio. Proseguiamo poi con la copia e la sincronia del database di OpenLDAP che contiene tutti i nostri utenti, le relative password e i gruppi.

Samba

Il file di configurazione di Samba ce lo possiamo copiare come stà: non abbiamo bisogno di personalizzare niente dal momento che il nome del server e le condivisioni non devono cambiare.

In più copiamoci anche lo gli script di logon creato e quelli di manutenzione. Per copiare i file da un server all'altro mi sono servito sempre di scp.

Aggiungiamo ogni file che ci interessa, nel mio caso erano questi :

scp /etc/samba/smb.conf archinew:/etc/samba
scp /etc/samba/logon.pl archinew:/etc/samba
scp /usr/local/sbin/purge archinew:/bin
scp /usr/local/sbin/setchown archinew:/bin

Niente di complicato insomma, solo un po' di attenzione nello individuare i file necessari.

SID

Abbiamo già visto cosa sia questo SID, in una nuova installazione prendiamo nota di quanto genera Samba e lo utilizziamo.

Questo non và bene in una migrazione, se cambia il SID del dominio dobbiamo rifare la join da tutte le workstation di rete: naturalmente questo non è accettabile. Quindi dobbiamo "forzare" il SID di archinew perchè sia lo stesso di archiold.
Niente di complicato una volta capito il concetto di SID. Da archiold digitiamo :

net getlocalsid

e ottengo ad esempio qualcosa del genere :

SID for domain MEDE is: S-1-5-21-2005849605-4084296952-1658462044

Ora forziamolo su archinew. Posizioniamoci sul nuovo server e digitiamo :

net setlocalsid S-1-5-21-2005849605-4084296952-1658462044

A questo punto il SID e il nome NETBIOS dei due server sono uguali e ci dobbiamo preoccupare di non avviare contemporaneamente Samba sui due server pena una esplosione termonucleare incontrollata :P .

Ora possiamo configurare gli LDAP Tools inserendo gli opportuni valori "carpiti" da archiold.

Database LDAP

E veniamo al clou: il database di openLDAP.

Qui si presenta un piccolo problema: archiold con Fedora ha un database in formato LDBM, ora non più supportato in favore del più moderno BDB. Questo fà sì che non possiamo semplicemente copiare i file, ma dobbiamo convertire i dati nel nuovo formato.
Il modo più semplice di farlo è con un backup e restore in formato LDIF, una sorta di "dump" come avviene per i database SQL.

Backup e Restore di server LDAP

Possiamo farlo online e senza specifici prodotti, ma utilizzando le utilità OpenLDAP Client Utilities come ldapadd, ldapsearch etc..., è possibile eseguire rapidamente e semplicemente l'operazione di copia completa delle entry di un server LDAP remoto, nonché di scrittura di tale copia su un LDAP server "vuoto".

Entrambi i comandi vanno eseguiti da archinew.

Per il backup, usiamo ldapsearch:

ldapsearch -x -b "dc=mede,dc=it" -h archiold -D "cn=Manager,dc=mede,dc=it" -w secret "(objectclass=*)" > archidump.ldif

dove:

• -x specifica l'utilizzo della "sample authentication" (anzichè SASL)
• -b "dc=mede,dc=it" indica il BaseDN del server, ovvero la posizione dalla quale effettuare la copia di tutti i nodi e le entry contenute
• -h archiold indica l'indirizzo del server LDAP remoto (possiamo usare l'indirizzo IP)
• -D "cn=Manager,dc=mede,dc=it" specifica l'identificativo dell'utenza ai fini dell'autenticazione al server remoto
• -w secret permette di specificare la password di accesso per l'utenza precedentemente indicata
• "(objectclass=*)" da istruzione al ldapsearch di restituire tutte le entry
• archidump.ldif è il file, in formato LDIF, ove salvare il risultato della ricerca.

Il file LDIF prodotto può quindi essere utilizzato per ripristinare anche un server il cui contenuto è andato perso. Pertanto, il seguente comando può essere utilizzato (attenzione!) per ripristinare un LDAP server vuoto privo di entry. Questo è il nostro caso, e allora ripristiniamo il contentuto su archinew con il comando ldapadd :

ldapadd -D "cn=Manager,dc=mede,dc=it" -x -w secret -h archinew -f archidump.ldif

Per il significato dei parametri, fare riferimento alla precedente descrizione.

Replica

A questo punto abbiamo il nuovo database su archinew, ma dato che dobbiamo lavorare con bocce "in movimento" potrebbe capitare che qualcuno apporti modifiche al database su archiold (ad esempio qualcuno che cambia la password), quindi sarebbe opportuno mantenere il database su archinew "allineato" al vecchio.
Esistono diversi modi di farlo, il più semplice è utilizzando il meccanismo di replica di openLDAP.
La replica è gestita dal servizio slurpd, su Archlinux è già attivato di default (ma non ci serve qui), su Fedora và avviato.

Su entrambi i server editiamo il file /etc/openldap/slapd.conf e inseriamo (specificando i parametri opportuni) :

Su archiold :

replica     host=archinew:389

            suffix="dc=mede,dc=it"

            binddn="cn=Manager,dc=mede,dc=it"

            bindmethod=simple credentials=secret


replogfile  /var/lib/openldap/replogfile

Su archinew :

updatedn    cn=Manager,dc=mede,dc=it

updateref   ldap://archiold

e riavviamo i servizi ldap. Come possiamo vedere abbiamo detto ad archiold di replicare le modifiche su archinew dove abbiamo autorizzato archiold a farlo.
Ora ogni modifica su archiold sarà fedelmente replicata su archinew.

Siamo praticamente pronti allo "switch" dei server, lo faremo nella prossima e ultima parte.

A presto!