Differences between revisions 3 and 4
Revision 3 as of 2005-06-03 18:04:13
Size: 10385
Editor: Kurgan
Comment:
Revision 4 as of 2005-06-03 22:36:03
Size: 11962
Editor: Kurgan
Comment: Prima release definitiva
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
== Questi sono SOLO APPUNTI e non vanno presi per una procedura collaudata == Questa procedura e` stata verificata con Samba 3.0.14a su Debian Sarge, migrando da un NT4 sp6a.
Line 3: Line 3:
Scopo: migrare un dominio da NT4 a samba3. === Scopo dell'operazione ===
Line 5: Line 5:
=== Dettagli: === Migrare un dominio da NT4 a samba3, tenendo buoni gli utenti e gli account delle workstation. I gruppi vanno modificati e quindi non e` importante tenerli.
Line 7: Line 7:
 * gli utenti ci sono gia` sul server samba, hanno gli stessi username di quelli del dominio, ma il server samba non partecipa al dominio.
 * gli utenti del server samba al momento hanno come dominio "linuxsrv" il che non va bene, il dominio deve diventare "giepr"
 * sul server samba non ci sono ovviamente gli account delle workstation
 * i gruppi sul server samba saranno del tutto diversi da quelli del server NT (occorrera` rimettere gli utenti nei gruppi)
=== Stato della rete prima dell'operazione ===
Line 12: Line 9:
=== Scopo === Il server NT che vogliamo eliminare e` il PDC, nella rete si trova un server Samba 3 il quale ha utenti locali con lo stesso username del server NT4, per consentire agli utenti del dominio di accedere al server Samba anche se questo non partecipa al dominio di NT.
Line 14: Line 11:
Concettualmente l'idea e` di rendere il server samba un PDC, tenendo gli utenti che ci sono ora o eventualmente sovrascrivendoli con quelli del server NT, perche` i nomi di utente coincidono. '''nota: gli utenti devono tenere lo stesso SID nella migrazione? credo di si`''' Occorre vedere come si puo` fare a vampirare gli utenti per tenere il SID, tuttavia e` chiaro che cose come la logon home invece non vanno tenute. in un paragrafo dell'howto dice che per migrare gli utenti e` meglio passare da tbdsam a smbpasswd e ritorno, cosa che strippa tutte le informazioni del dominio... e i SID? Chiedere in lista. Il metodo indicato funziona anche se il server Samba viene installato ex-novo, quindi non ha mai lavorato in affiancamento all' NT, e non ha utenti locali. Inoltre funziona anche se il server Samba contiene solo alcuni utenti locali e non tutti quelli del server NT.
Line 16: Line 13:
 * Il SID del dominio cosi` come gli account di macchina, che al momento su samba non ci sono, dovrebbero essere mantenuti in modo da evitare assolutamente di dover togliere e rimettere le macchine nel dominio. Questo e` fondamentale. Il metodo indicato NON funziona se il server Samba contiene utenti locali che vanno mantenuti (e che accedono a Samba) che pero` non ci sono nell' NT. in questo caso occorrera` esportare questi utenti dal tdbsam e reimportarli alla fine. Questo caso non e` pero` spiegato.
Line 18: Line 15:
 * I gruppi vanno rifatti in toto, quindi la migrazione dei gruppi sarebbe meglio non farla proprio. Il server Samba, non partecipando al dominio, non ha machine accounts in locale, ne` conosce quelli dell' NT.
Line 20: Line 17:
 * Share e stampanti vanno rifatti in toto. I gruppi, gli shares, le stampanti, sono totalmente diversi su Samba rispetto a NT, ed esistono gia` su Samba, in parte o per intero, quindi vanno preservati ed eventualmente integrati. Se anche non esistessero la procedura e` valida lo stesso, andranno creati in seguito secondo le proprie esigenze.
Line 22: Line 19:
 * I login script vanno cambiati === Vincoli tecnici e organizzativi ===
Line 24: Line 21:
 * Il server WINS deve passare dall' NT al Samba al momento in cui anche il PDC passa.  * Linux deve diventare PDC e NT va eliminato dalla rete nello stesso istante.
 * La migrazione va fatta a rete totalmente ferma, quindi il tempo di migrazione deve essere breve (un weekend al massimo)
 * Dal momento del cambio di PDC in poi e` chiaro che i client non accederanno piu` ad alcuno share sul vecchio NT, quindi occorre che stampanti e share non siano piu` in uso sull' NT da prima della migrazione. Di fatto l' NT deve avere solo funzione di PDC ed eventualmente di WINS server.
 * Il SID del dominio va mantenuto fra i due PDC, altrimenti non funziona piu` nulla
 * il SID dei gruppi principali (Domain Users, Domain Admins, e Domain Guests) va tenuto uguale durante la migrazione. Per fortuna questi SID hanno valori standard (513, 512 e 514) e quindi si mantengono senza dover fare nulla di particolare.
 * il nome del dominio va mantenuto, come sopra.
 * Il nome del server Samba e` diverso da quello dell' NT, e lo rimarra`.
 * Il nome e il SID degli account di utente vanno mantenuti, cosi` come le password di accesso degli utenti. Per fortuna gli username usati sull' NT sono compatibili con Linux in termini di lunghezza e caratteri usati.
 * Il nome e l' UID (lato linux) degli account gia` presenti sul server Samba prima della migrazione vanno mantenuti, cosi` come le home. Questo perche` nel nostro caso ci sono gia` dati e share su Linux a cui gli utenti accedono.
 * Il nome e il SID degli account delle macchine vanno mantenuti, cosi` da non dover rimettere tutti i client nel dominio.
 * I gruppi presenti su NT vanno persi, i gruppi gia` presenti su Linux (e le assegnazioni degli utenti ai gruppi) vanno conservati e integrati eventualmente con alcuni nuovi.
 * Non vi sono policy da mantenere nella migrazione
 * I dati (files degli utenti) sono gia` stati sistemati e non ci sono contenuti degli share da migrare all'atto del cambio di PDC.
 * Gli script di login vanno rifatti adatti alle nuove esigenze
 * Le stampanti condivise sono gia` presenti sul server Linux, e vanno mantenute.
 * La funzione di server WINS deve passare dall' NT al Samba al momento della migrazione.
Line 26: Line 38:

=== Migrazione utenti e machine account ===

Per migrare i dati di utenti e macchine, mantenendo i SID dell' NT e rifacendo pero` i gruppi, occorre poter vampirare i dati dal server NT su una macchina temporanea con samba, poi modificarli, e caricarli sul server samba definitivo. Per fare questo si puo` tentare di usare la conversione da tdbsam a xmlsam, poi si edita il file XML a mano, e poi si riconverte indietro. Questo dovrebbe permettere di:

 * tenere i SID degli utenti
 * tenere i SID degli account macchina
 * non importare i gruppi fra il server di appoggio dal quale si vampira e il server di produzione su cui si carica la roba alla fine.
 * verificare facilmente se ci sono nomi utente o macchina che non vanno bene per gli standard di samba.

Gli utenti lato linux ci sono gia`, e devono mantenere gli UID che hanno ora, per cui non li copio dal server di migrazione a quello di produzione. Ovviamente eventuali utenti che non ci siano possono essere creati senza vincoli di UID.

Gli account di macchina vanno creati, ma alla peggio si tratta di copiaincollare un pezzo di {{{/etc/passwd}}} e di {{{/etc/shadow}}} dal linux che vampira a quello di produzione.

E` '''importante''' che il SID del dominio sul server di produzione sia uguale a quell' dell NT. Vediamo come si puo` fare.

E` '''importante''' che i SID per i gruppi di base (domain admins, domain users) siano coerenti con quelli dell' NT???

Comandi per esportare/importare i dati da tdbsam a xml: (This module requires libxml2 to be installed)
{{{
$ pdbedit -e xml:filename (per esportare sul file "filename")
$ pdbedit -i xml:filename (per importare)
}}}
NOTA: occorre avere installato (cioe` presente) il plug-in XML per pdbedit, il quale non fa parte di nessuna distro samba per Debian. Il workaround molto sporco e` stato prendere quello della Suse 9 della versione di Samba corrispondente con quella che uso. Detto file e` {{{/usr/lib/samba/pdb/xml.so}}}, ed e` disponibile qui: attachment:xml.so

=== Cambio WINS ===
Per cambiare il WINS server e` sufficiente inserire in smb.conf {{{wins server = yes }}} e modificare il server DHCP in modo che dia ai client il nuovo server WINS al posto del vecchio.
Per verificare che cosa viene registrato nel wins, e` utile leggere (volendo editare anche) il file {{{/var/lib/samba/wins.dat}}} che e` in testo.
Line 57: Line 41:
=== Checklist per eseguire il vampire ===
 '''ATTENZIONE:''' dal momento che si joina il dominio come BDC, i client cominciano a chiedere al BDC di autenticare, quindi siccome stiamo ancora migrando le configurazioni di fatto i client ricevono risposte farlocche che pero` considerano valide! Questo significa che durante questa operazione e fino a che non si sono stabilizzate le cose i client danno i numeri di brutto!
== Operazioni da eseguire per migrare ==
Di seguito sono indicate le operazioni da eseguire in sequenza nel momento in cui si effettua la migrazione.
Line 60: Line 44:
 * Salvare le configurazioni
  * copiare /etc/passwd, /etc/group, /etc/shadow, e tutti i files di /var/lib/samba
  * copiare i files in /var/spool/samba
=== Backup configurazioni Linux ===
 * Copiare /etc/passwd, /etc/group, /etc/shadow, e tutti i files di /var/lib/samba da qualche parte.
 * Copiare i files in /var/spool/samba da qualche parte.
Line 64: Line 48:
=== Esecuzione del "vampire" ===
'''ATTENZIONE:''' dal momento che si joina il dominio come BDC, i client cominciano a chiedere al BDC di autenticare, quindi siccome stiamo ancora migrando le configurazioni di fatto i client ricevono risposte farlocche che pero` considerano valide! In questa fase la rete deve essere ferma.

 * Fermare Samba
 * Cancellare (ne abbiamo una copia) il file {{{/var/lib/samba/passdb.tdb}}} contenente gli account utente di Samba.
Line 66: Line 55:
  * usare i comandi {{{net groupmap modify}}} per mappare almeno i tre succitati gruppi   * usare i comandi {{{net groupmap modify}}} per mappare almeno i tre succitati gruppi.
L'esempio di seguito effettua entrambe le operazioni sopra descritte.
Line 74: Line 64:
 * Joinarsi al dominio come BDC 
  * mettere {{{domain master=no}}}
 * Joinarsi al dominio come BDC
  * mettere {{{domain master=no}}} in smb.conf
Line 83: Line 73:
  * usare il comando {{{net rpc vampire -S oldnt4pdc -U Administrator%password > vam.log 2>errori_vamp.log}}} per vampirare loggando.    * usare il comando {{{net rpc vampire -S oldnt4pdc -U Administrator%password > vam.log 2>errori_vamp.log}}} per vampirare loggando stdout e stderr.
Line 85: Line 75:
A questo punto ci si trova con uno strano casino. Gli utenti sono portati correttamente, e gli account delle macchine anche, sempre che rispettino i limiti di dimensione dei nomi degli utenti e delle macchine. Quello che non viene portato correttamente sono i gruppi con gli spazi, che proprio non vengono creati. Inoltre l'appartenenza degli utenti ai gruppi e` fatta a meta`, perche` il comando che esegue la funzione di "add user to group" in realta` lo aggiunge al gruppo indicato, ma lo rimuove da quelli in cui era prima, cosa che non dovrebbe fare. La cosa tuttavia non ci preoccupa perche` i gruppi sono da rifare. A questo punto ci si trova con uno strano casino. Gli utenti sono portati correttamente, e gli account delle macchine anche, sempre che rispettino i limiti di dimensione dei nomi degli utenti e delle macchine. Gli utenti che in Linux (/etc/passwd) esistevano gia` sono rimasti li` e hanno conservato l' UID, il GID, e tutte le impostazioni presenti in /etc/passwd e /etc/shadow. Gli utenti nuovi sono stati creati con un default che dipende dalla configurazione di Samba. Lo stesso identico discorso vale per i gruppi in /etc/group.
Line 87: Line 77:
Sarebbe bene verificare nei log del comando di vampire che gli errori siano circoscritti e gestibili. Quello che non viene portato correttamente sono i gruppi con gli spazi, che proprio non vengono creati. Inoltre l'appartenenza degli utenti ai gruppi e` fatta a meta`, perche` il comando che esegue la funzione di "add user to group" in realta` aggiunge l'utente al gruppo indicato, ma lo rimuove da quelli in cui era prima, cosa che non dovrebbe fare. Il risultato e` che gli utenti sono membri solo dell'ultimo gruppo in cui appaiono. La cosa tuttavia non ci preoccupa perche` i gruppi sono da rifare.
Line 89: Line 79:
Nota che gli account di macchina vengono messi dentro al GID 513 (domain users) anziche` 514 (domain guests) come fa Linux se joini le macchine al dominio. La cosa non dovrebbe provocare casino, pero`. Sarebbe bene verificare nei log del comando di vampire che gli errori siano circoscritti e gestibili. (tipicamente sono circoscritti a utenti o gruppi con nomi non validi, ovvero con spazi dentro)
Line 91: Line 81:
=== Checklist per diventare PDC dopo il vampire === Nota che gli account di macchina vengono messi dentro al GID 513 (domain users) anziche` 514 (domain guests) come fa Linux se joini le macchine al dominio. La cosa non dovrebbe provocare casino, pero`, quindi li lasciamo cosi` a meno che non abbiamo tempo da perdere.


=== Promozione di Linux a PDC dopo il vampire ===
Line 95: Line 88:
 * Provare con {{{pdbedit -L -v}}} se a naso i SID sono quelli giusti (cioe` parte del dominio interessato alla migrazione)  
 * Pulire i files /etc/passwd ed /etc/group
 * Provare con {{{pdbedit -L -v}}} se a naso i SID sono quelli giusti (cioe` parte del dominio interessato alla migrazione)
 * Mettere a punto i files /etc/passwd ed /etc/group
Line 99: Line 92:
   * Se qualche utente e` stato aggiunto, verificare che sia a posto e che magari non sia obsoleto e da cancellare.
  * Verificare se in /etc/passwd sono state creati gli account di macchina e sono giusti come gruppo e home.
  * Nota che in /etc/shadow gli utenti aggiunti ex-novo hanno "!" al posto di "*" come password disattivata. Aiuta a capire quali sono nuovi.
  * Editare /etc/group ed eliminare tutti i gruppi inutili. Occhio al gruppo "Users" che viene creato e che ovviamente non e` "users" standard. Eliminarlo senza pieta`.
   * Se qualche utente e` stato aggiunto nella migrazione, verificare che sia a posto e che magari non sia obsoleto e da cancellare.
  * Verificare se in /etc/passwd sono state creati gli account di macchina e sono giusti come GID e home.
  * Nota che in /etc/shadow gli utenti aggiunti ex-novo hanno "!" al posto di "*" come password disattivata. Questo aiuta a capire quali sono nuovi.
  * Editare /etc/group ed eliminare tutti i gruppi inutili che sono stati migrati. Occhio al gruppo "Users" che viene creato e che ovviamente non e` "users" standard. Eliminarlo senza pieta`.
Line 104: Line 97:
Line 109: Line 101:
  * editare /etc/group, magari prendendo pezzi dal backup, per rimettere a posto i gruppi che c'erano prima. Probabilmente con un minimo di occhio si puo` riprendere il backup senza stare tanto a copiaincollare.
  * Pulire il group mapping di samba a colpi di {{{net groupmap delete ntgroup="nome gruppo"}}} eliminando tutti i gruppi vecchi.
  * Aggiungere i gruppi nuovi con {{{net groupmap add ntgroup="groupname" unixgroup=groupname type=d}}} (non e` chiaro se serva, dal momento che non c'e` nulla da mappare se i nomi dei gruppi sono uguali)
  
  * editare /etc/group, magari prendendo pezzi dal backup, per rimettere a posto i gruppi che c'erano prima. Probabilmente con un minimo di occhio si puo` riprendere il backup senza stare tanto a copiaincollare, in quanto non ci interessa tenere i nuovi gruppi e invece ci interessa tenere i vecchi, che possono essere stati massacrati dal problema dell' "add user to group" citato prima.
  * Pulire il group mapping di samba a colpi di {{{net groupmap delete ntgroup="nome gruppo"}}} eliminando tutti i gruppi vecchi che sono stati migrati ma non ci servono.
  * Aggiungere i gruppi nuovi con {{{net groupmap add ntgroup="groupname" unixgroup=groupname type=d}}} (non credo che serva, dal momento che non c'e` nulla da mappare se i nomi dei gruppi sono uguali fra Linux e Windows)
Line 117: Line 108:
=== Checklist per il test del nuovo PDC === === Test del nuovo PDC ===
Line 120: Line 111:
 * Tentare con un client di fare logon al dominio con diversi utenti, anche utenti che non si siano mai loggati da quel client  * Tentare con un client di fare logon al dominio con diversi utenti, anche utenti che non si siano mai loggati da quel client, per saltare la cache.
Line 128: Line 119:
=== Cose da verificare === === Cose utili da sapere ===
Line 130: Line 121:
 * Ci sono nomi di utenti o nomi di macchine con uno spazio in mezzo?
 * Ci sono nomi di utenti piu` lunghi di 8 caratteri?
 * Ci sono nomi di macchine piu` lunghi di 16 caratteri?
 * Ci sono caratteri strani nei nomi di macchina o di utente? Quali?
E` possibile esportare e importare i dati dal backend tdbsam a un file XML, il che puo` venire utile per editarli a mano.

I comandi sono i seguenti:
{{{
$ pdbedit -e xml:filename (per esportare sul file "filename")
$ pdbedit -i xml:filename (per importare)
}}}

NOTA: occorre avere installato (cioe` presente) il plug-in XML per pdbedit, il quale non fa parte di nessuna distro samba per Debian. Il workaround molto sporco e` stato prendere quello della Suse 9 della versione di Samba corrispondente con quella che uso. Detto file va messo in {{{/usr/lib/samba/pdb/xml.so}}}, ed e` disponibile per Samba 3.0.14a qui: attachment:xml.so. Occorre anche installare il pacchetto {{{libxml2}}}

Per verificare che cosa viene registrato nel wins, nel caso in cui i client dovessero avere difficolta` a trovare il PDC, e` utile leggere (volendo editare anche) il file {{{/var/lib/samba/wins.dat}}} che e` in testo. il PDC ha come nome netbios una stringa composta dal nome del dominio seguita dal carattere "1B" hex.

Questa procedura e` stata verificata con Samba 3.0.14a su Debian Sarge, migrando da un NT4 sp6a.

Scopo dell'operazione

Migrare un dominio da NT4 a samba3, tenendo buoni gli utenti e gli account delle workstation. I gruppi vanno modificati e quindi non e` importante tenerli.

Stato della rete prima dell'operazione

Il server NT che vogliamo eliminare e` il PDC, nella rete si trova un server Samba 3 il quale ha utenti locali con lo stesso username del server NT4, per consentire agli utenti del dominio di accedere al server Samba anche se questo non partecipa al dominio di NT.

Il metodo indicato funziona anche se il server Samba viene installato ex-novo, quindi non ha mai lavorato in affiancamento all' NT, e non ha utenti locali. Inoltre funziona anche se il server Samba contiene solo alcuni utenti locali e non tutti quelli del server NT.

Il metodo indicato NON funziona se il server Samba contiene utenti locali che vanno mantenuti (e che accedono a Samba) che pero` non ci sono nell' NT. in questo caso occorrera` esportare questi utenti dal tdbsam e reimportarli alla fine. Questo caso non e` pero` spiegato.

Il server Samba, non partecipando al dominio, non ha machine accounts in locale, ne` conosce quelli dell' NT.

I gruppi, gli shares, le stampanti, sono totalmente diversi su Samba rispetto a NT, ed esistono gia` su Samba, in parte o per intero, quindi vanno preservati ed eventualmente integrati. Se anche non esistessero la procedura e` valida lo stesso, andranno creati in seguito secondo le proprie esigenze.

Vincoli tecnici e organizzativi

  • Linux deve diventare PDC e NT va eliminato dalla rete nello stesso istante.
  • La migrazione va fatta a rete totalmente ferma, quindi il tempo di migrazione deve essere breve (un weekend al massimo)
  • Dal momento del cambio di PDC in poi e` chiaro che i client non accederanno piu` ad alcuno share sul vecchio NT, quindi occorre che stampanti e share non siano piu` in uso sull' NT da prima della migrazione. Di fatto l' NT deve avere solo funzione di PDC ed eventualmente di WINS server.
  • Il SID del dominio va mantenuto fra i due PDC, altrimenti non funziona piu` nulla
  • il SID dei gruppi principali (Domain Users, Domain Admins, e Domain Guests) va tenuto uguale durante la migrazione. Per fortuna questi SID hanno valori standard (513, 512 e 514) e quindi si mantengono senza dover fare nulla di particolare.
  • il nome del dominio va mantenuto, come sopra.
  • Il nome del server Samba e` diverso da quello dell' NT, e lo rimarra`.
  • Il nome e il SID degli account di utente vanno mantenuti, cosi` come le password di accesso degli utenti. Per fortuna gli username usati sull' NT sono compatibili con Linux in termini di lunghezza e caratteri usati.
  • Il nome e l' UID (lato linux) degli account gia` presenti sul server Samba prima della migrazione vanno mantenuti, cosi` come le home. Questo perche` nel nostro caso ci sono gia` dati e share su Linux a cui gli utenti accedono.
  • Il nome e il SID degli account delle macchine vanno mantenuti, cosi` da non dover rimettere tutti i client nel dominio.
  • I gruppi presenti su NT vanno persi, i gruppi gia` presenti su Linux (e le assegnazioni degli utenti ai gruppi) vanno conservati e integrati eventualmente con alcuni nuovi.
  • Non vi sono policy da mantenere nella migrazione
  • I dati (files degli utenti) sono gia` stati sistemati e non ci sono contenuti degli share da migrare all'atto del cambio di PDC.
  • Gli script di login vanno rifatti adatti alle nuove esigenze
  • Le stampanti condivise sono gia` presenti sul server Linux, e vanno mantenute.
  • La funzione di server WINS deve passare dall' NT al Samba al momento della migrazione.


Operazioni da eseguire per migrare

Di seguito sono indicate le operazioni da eseguire in sequenza nel momento in cui si effettua la migrazione.

Backup configurazioni Linux

  • Copiare /etc/passwd, /etc/group, /etc/shadow, e tutti i files di /var/lib/samba da qualche parte.
  • Copiare i files in /var/spool/samba da qualche parte.

Esecuzione del "vampire"

ATTENZIONE: dal momento che si joina il dominio come BDC, i client cominciano a chiedere al BDC di autenticare, quindi siccome stiamo ancora migrando le configurazioni di fatto i client ricevono risposte farlocche che pero` considerano valide! In questa fase la rete deve essere ferma.

  • Fermare Samba
  • Cancellare (ne abbiamo una copia) il file /var/lib/samba/passdb.tdb contenente gli account utente di Samba.

  • Mappare i gruppi di base (domain admins, domain users, domain guests)
    • creare il gruppo ntadmins
    • usare i comandi net groupmap modify per mappare almeno i tre succitati gruppi.

L'esempio di seguito effettua entrambe le operazioni sopra descritte.

adduser ntadmins
net groupmap modify ntgroup="Domain Guests" unixgroup=nogroup
net groupmap modify ntgroup="Domain Admins" unixgroup=ntadmins
net groupmap modify ntgroup="Domain Users" unixgroup=users
  • Joinarsi al dominio come BDC
    • mettere domain master=no in smb.conf

    • mettere il dominio giusto in smb.conf
    • Lanciare samba
    • usare il comando net rpc join -S sntgiepr01 -W GIEPR -UAdministrator%password per joinare il dominio

    • Volendo, usare il comando net rpc samdump -S sntgiepr01 -W GIEPR -UAdministrator%password > filename per dumpare su un file tutti i dati degli utenti e gruppi del server NT. Non e` necessario, ma aiuta poi a capire cosa c'e` che non va, nel caso.

    • Operazioni di pulizia dei gruppi (probabilmente inutili)
      • Fermare samba, rinominare il file /var/lib/samba/group_mapping.tdb, eseguire net groupmap list per verificare se i gruppi sono tutti non mappati

      • Rieseguire la mappatura di base dei gruppi. Notare se i SID dei gruppi contengono i valori propri del dominio NT che stiamo migrando.
    • usare il comando net rpc vampire -S oldnt4pdc -U Administrator%password > vam.log 2>errori_vamp.log per vampirare loggando stdout e stderr.

A questo punto ci si trova con uno strano casino. Gli utenti sono portati correttamente, e gli account delle macchine anche, sempre che rispettino i limiti di dimensione dei nomi degli utenti e delle macchine. Gli utenti che in Linux (/etc/passwd) esistevano gia` sono rimasti li` e hanno conservato l' UID, il GID, e tutte le impostazioni presenti in /etc/passwd e /etc/shadow. Gli utenti nuovi sono stati creati con un default che dipende dalla configurazione di Samba. Lo stesso identico discorso vale per i gruppi in /etc/group.

Quello che non viene portato correttamente sono i gruppi con gli spazi, che proprio non vengono creati. Inoltre l'appartenenza degli utenti ai gruppi e` fatta a meta`, perche` il comando che esegue la funzione di "add user to group" in realta` aggiunge l'utente al gruppo indicato, ma lo rimuove da quelli in cui era prima, cosa che non dovrebbe fare. Il risultato e` che gli utenti sono membri solo dell'ultimo gruppo in cui appaiono. La cosa tuttavia non ci preoccupa perche` i gruppi sono da rifare.

Sarebbe bene verificare nei log del comando di vampire che gli errori siano circoscritti e gestibili. (tipicamente sono circoscritti a utenti o gruppi con nomi non validi, ovvero con spazi dentro)

Nota che gli account di macchina vengono messi dentro al GID 513 (domain users) anziche` 514 (domain guests) come fa Linux se joini le macchine al dominio. La cosa non dovrebbe provocare casino, pero`, quindi li lasciamo cosi` a meno che non abbiamo tempo da perdere.

Promozione di Linux a PDC dopo il vampire

Nota: occorre staccare dalla rete il vecchio PDC NT prima di lanciare samba sul nuovo. Questa roba viene fatta con i demoni di samba spenti.

  • Provare con pdbedit -L -v se a naso i SID sono quelli giusti (cioe` parte del dominio interessato alla migrazione)

  • Mettere a punto i files /etc/passwd ed /etc/group
    • Verificare se in /etc/passwd sono stati creati gli utenti
      • Se gli utenti erano tutti gia` presenti, non dovrebbero essere stati creati ex-novo
      • Se qualche utente e` stato aggiunto nella migrazione, verificare che sia a posto e che magari non sia obsoleto e da cancellare.
    • Verificare se in /etc/passwd sono state creati gli account di macchina e sono giusti come GID e home.
    • Nota che in /etc/shadow gli utenti aggiunti ex-novo hanno "!" al posto di "*" come password disattivata. Questo aiuta a capire quali sono nuovi.
    • Editare /etc/group ed eliminare tutti i gruppi inutili che sono stati migrati. Occhio al gruppo "Users" che viene creato e che ovviamente non e` "users" standard. Eliminarlo senza pieta`.
    • Se si eliminano utenti, magari farlo con userdel -r per fare secche le home (controlla prima che non puntino a qualcosa che sia pericoloso!) e le entry in shadow.

  • Sistemare i nuovi gruppi
    • Aggiungere root al gruppo ntadmins in /etc/group
    • modificare l'account di root con pdbedit per dargli il primary group SID 512 (domain admins) pdbedit root -r -G="S-1-5-21-610474926-686117454-311576647-512"

    • verificare con pdbedit se gli utenti sono stati messi correttamente tutti con il primary group SID 513 (domain users)
    • editare /etc/group, magari prendendo pezzi dal backup, per rimettere a posto i gruppi che c'erano prima. Probabilmente con un minimo di occhio si puo` riprendere il backup senza stare tanto a copiaincollare, in quanto non ci interessa tenere i nuovi gruppi e invece ci interessa tenere i vecchi, che possono essere stati massacrati dal problema dell' "add user to group" citato prima.
    • Pulire il group mapping di samba a colpi di net groupmap delete ntgroup="nome gruppo" eliminando tutti i gruppi vecchi che sono stati migrati ma non ci servono.

    • Aggiungere i gruppi nuovi con net groupmap add ntgroup="groupname" unixgroup=groupname type=d (non credo che serva, dal momento che non c'e` nulla da mappare se i nomi dei gruppi sono uguali fra Linux e Windows)

  • Modificare smb.conf mettendo domain master=yes e wins support = yes, e levando wins server = 10.0.0.251

  • Modificare il server DHCP per riflettere la modifica al WINS SERVER.
  • Lanciare samba

Test del nuovo PDC

  • eventualmente tracciare il traffico con tethereal sul server per avere una visione piu` chiara.
  • Tentare con un client di fare logon al dominio con diversi utenti, anche utenti che non si siano mai loggati da quel client, per saltare la cache.
  • verificare empiricamente se i permessi di accesso ai profili locali sul client sono ancora al loro posto
  • dal client eseguire qualche net user <username> /domain per vedere se i dati dell'utente (e la mappatura dei gruppi) vengono letti bene dal nuovo PDC.

  • provare a joinare un nuovo client al dominio e vedere se funziona.


Cose utili da sapere

E` possibile esportare e importare i dati dal backend tdbsam a un file XML, il che puo` venire utile per editarli a mano.

I comandi sono i seguenti:

$ pdbedit -e xml:filename (per esportare sul file "filename")
$ pdbedit -i xml:filename (per importare)

NOTA: occorre avere installato (cioe` presente) il plug-in XML per pdbedit, il quale non fa parte di nessuna distro samba per Debian. Il workaround molto sporco e` stato prendere quello della Suse 9 della versione di Samba corrispondente con quella che uso. Detto file va messo in /usr/lib/samba/pdb/xml.so, ed e` disponibile per Samba 3.0.14a qui: attachment:xml.so. Occorre anche installare il pacchetto libxml2

Per verificare che cosa viene registrato nel wins, nel caso in cui i client dovessero avere difficolta` a trovare il PDC, e` utile leggere (volendo editare anche) il file /var/lib/samba/wins.dat che e` in testo. il PDC ha come nome netbios una stringa composta dal nome del dominio seguita dal carattere "1B" hex.

Samba/MigrazioneDominio (last edited 2009-04-12 17:33:24 by localhost)