La Knowledge Base di Kurgan (2.0)

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
==== Migrazione di un PDC samba3 da un server a uno nuovo ====


Questa procedura descrive le operazioni necessarie per sostituire un server (PDC con Samba 3.0.14a) con un nuovo computer con samba 3.0.24. si tratta di una sostituzione in blocco, quindi il nuovo server prende il posto del vecchio e il vecchio viene spento. E` stata provata anche con diverse versioni di samba 3.x piu` recenti (3.2.x, 3.5.x), ed ha sempre funzionato.

E` importante ricordare che i client scambiano chiavi con il server e che queste chiavi cambiano nel tempo, quindi durante la migrazione occorre che i client siano spenti (cosi` non modificano le loro chiavi) e una volta riaccesi sul nuovo server non e` detto che sia possibile tornare indietro al vecchio. Nel caso in cui un client non riesca piu` a riconoscere il dominio a causa di un cambio di chiavi avvenuto in un momento critico della migrazione lo si dovra` togliere e rimettere nel dominio.


==== Backup delle informazioni ====

  * Salvare il SID del vecchio server (non si sa mai)<code>
net getdomainsid > sid.txt
</code>
  * Salvare l'elenco dei mapping dei gruppi del vecchio server<code>
 net groupmap list > gruppi.txt
</code>
  * Salvare l'elenco degli utenti del vecchio server (questo va bene per riferimento ma non posso usarlo per ricaricare gli utenti, quindi va bene se gli utenti sono pochi e possono essere, in caso di casini, corretti a mano. Se non fosse cosi`, occorre esportare in XML). Per fortuna non ho mai avuto problemi con gli utenti durante la migrazione.<code>
 pdbedit -L -v > users.txt
</code>

==== Copia dei dati di config dalla vecchia macchina a quella nuova ====

  * Fermare samba su tutti e due i server
  * Copiare dal server vecchio a quello nuovo:
    * utenti e gruppi Linux (con gli stessi UID e GID).  NOTA: Nella mia prova con pochi utenti, ho ricreato a mano i gruppi e gli utenti con gli stessi GID e UID. Questo va fatto sia per gli utenti che per gli account delle macchine nel dominio (quelli che finiscono in "$"). Dovendone fare di piu`, e` meglio trovare un altro sistema, come ad esempio copiare le entry rilevati in ''/etc/passwd'', ''/etc/shadow'' e ''/etc/group''. E` anche possibile copiare le entry da passwd, eventuali entry con password in shadow, e poi usare ''pwconv'' per allineare shadow a passwd. E` anche utile usare ''pwck'' e ''grpck'' per verificare che i files passwd e group (se li avete editati a mano) siano coerenti e non abbiano errori.
    * tutta /etc/samba (richiede ovviamente aggiustamenti se, per dire, cambia l'hostname, o se ci sono parametri che sono cambiati, hanno diversi default, eccetera.)
    * tutti i files "*.tdb" e "*.ldb" da /var/lib/samba allo stesso posto nel nuovo server, avendo cura di cancellare i tdb e ldb che vi fossero, per evitare di avere casini fra vecchie e nuove versioni. Dentro questi files ci sono tutti i dati degli utenti e dei gruppi di Samba. Questi files verrano automaticamente convertiti e aggiornati dal nuovo samba quando verra` avviato, e lo si potra` vedere anche nel log.

  * Se occorre, modificare hostname e indirizzo ip del server nuovo
  * Se ci sono stampanti condivise, riconfigurarle su cups o altro sistema. Gli abbinamenti driver/stampante fatti in Samba restano validi se si copiano i files tdb e i files dei drivers (lo share print$).
  * Lanciare testparm sul server nuovo e vedere se ci sono errori
  * Lanciare Samba sul server nuovo (senza client accesi!)
  * Verificare se samba e` partito correttamente (ps ax, una guardata ai log, o un "smbstatus"
  * Verificare il local SID e il domain SID del server nuovo (''net getdomainsid''), e se e` nullo o cambiato causa cambio dell'hostname, reimpostarlo. Nota: nella mia prova, in cui ho cambiato hostname del server, ma non nome del dominio, ho dovuto reimpostarlo.
<code>
net setlocalsid <SID del vecchio che avevi salvato in sid.txt>
net setdomainsid <SID del vecchio che avevi salvato in sid.txt>
</code>
  * Verificare con ''net groupmap list'' se il mapping dei gruppi e` ancora a posto (gruppi, mapping, SID dei gruppi uguali a come erano prima). Nota: nella mia prova lo erano.
  * Verificare con ''pdbedit -L -v'' se gli utenti sono a posto (dominio, SID, GID, home) Nota: nella mia prova lo erano, pero` non avevo gruppi strani oltre a users, guests e admins.
  * Provare a fare login sul dominio con un client, usando un utente che gia` si collegava al client e poi uno che al client non si e` mai collegato, e vedere i log per verificare che non ci siano errori palesi. Verificare se sul client viene eseguito il login script.

==== Problema dei dischi mappati che non vanno ====

Capita (non so perche`) che dopo il cambio i dischi mappati non siano piu` accessibili, mentre i percorsi UNC funzionano benissimo. Nel caso, e` sufficiente smappare e rimappare i dischi. Puo` essere fatto cancellandoli a mano e poi rieseguendo il logon script oppure inserendo in cima al logon script una riga che smappi tutto, cosi`:
<code>
net use * /delete /yes
</code>

==== Problemi di charset ====

Se il vecchio server usava (sul file system) charset che non siano utf-8 e il nuovo invece usa utf-8, puo` essere necessario convertire il charset (oppure dire a samba di usare il charset vecchio). Vedasi [[:LinuxDebian:Rsync]] per come convertire il charset con rsync (anche in locale, senza fare una copia)


==== Problema del mapping dei gruppi ====

In Samba 3.0.24 la generazione dei GID dei gruppi che non siano stati definiti con "net groupmap" e` cambiata. Quindi se si migra da un server vecchio a uno con 3.0.23 o superiore occorre fare bene attenzione a quanto segue:

The user and group internal management routines have been 
rewritten to prevent overlaps of assigned Relative Identifiers 
(RIDs).  In the past the has been a potential problem when either 
manually mapping Unix groups with the 'net groupmap' command or 
when migrating a Windows domain to a Samba domain using 'net rpc 
vampire'.

Unmapped users are now assigned a SID in the S-1-22-1 domain and 
unmapped groups are assigned a SID in the S-1-22-2 domain. 
Previously they were assign a RID within the SAM on the Samba 
server.  For a DC this would have been under the authority of the 
domain SID where as on a member server or standalone host, this 
would have been under the authority of the local SAM (hint: net 
getlocalsid).

The result is that any unmapped users or groups on an upgraded 
Samba domain controller may be assigned a new SID.  Because the 
SID rather than a name is stored in Windows security descriptors, 
this can cause a user to no longer have access to a resource for 
example if a file was copied from a Samba file server to a local 
NTFS partition.  Any files stored on the Samba server itself will 
continue to be accessible because Unix stores the Unix gid and not 
the SID for authorization checks.

A further example will help illustrate the change.  Assume that a 
group named 'developers' exists with a Unix gid of 782 but this 
user does not exist in Samba's group mapping table. it would be 
perfectly normal for this group to be appear in an ACL editor.  
Prior to 3.0.23, the group SID might appear as 
S-1-5-21-647511796-4126122067-3123570092-2565. With 3.0.23, the 
group SID would be reported as S-1-22-2-782. Any security 
descriptors associated with files stored on an NTFS disk partition 
would not allow access based on the group permissions if the user 
was not a member of the 
S-1-5-21-647511796-4126122067-3123570092-2565 group. Because this 
group SID not reported in a user's token is S-1-22-2-782, Windows 
would fail the authorization check even though both SIDs in some 
respect referred to the same Unix group.

The current workaround is to create a manual domain group mapping 
entry for the group 'developers' to point at the 
S-1-5-21-647511796-4126122067-3123570092-2565 SID.