Cosa succede all'autenticazione utente LDAP e alle condivisioni della directory home NFS quando si è lontani dalla rete?

Al momento ho diverse macchine sulla rete domestica che sono una miscela di desktop e laptop statici. Sta diventando ingestibile per me e poco pratico per tutti avere home directory locali, impostazioni e sicurezza, quindi sto pensando di utilizzare LDAP per la gestione degli utenti comuni e NFS per le home directory condivise.

Cosa succede quando uno dei laptop è in viaggio? La rete domestica non è raggiungibile, quindi l'autenticazione fallirà e tornerà alla memoria locale? Inoltre, quando il laptop ritorna, c'è un modo per risincronizzare l'archiviazione domestica sul server NFS?

NFS e LDAP non supportano operazioni disconnesse: ad esempio, quando il laptop non è in grado di raggiungere i server, non sarà in grado di accedere ad alcuna directory montata su NFS, né sarà in grado di eseguire ricerche dell'utente. Fondamentalmente, sarà bloccato.

Un paio di soluzioni alternative potrebbero essere le seguenti.

Invece di eseguire il mouting delle home directory tramite NFS, è possibile mantenere le directory locali un uso all'unisono per sincronizzarle con quella sul server centrale. È possibile eseguire all'unisono da cron, sorvegliato da un test che interrompe l'operazione se il server non è raggiungibile. Questo post su AskUbuntu e quest'altro forniscono una discussione sul tema della sincronizzazione e alcuni suggerimenti utili.

Per quanto riguarda il problema di autenticazione / autorizzazione dell'utente, le soluzioni ruotano attorno all'uso di libnss-dbcome fonte di informazioni per l'utente:

• Installa libnss-db, quindi configura /etc/nsswitch.confper cercare l' dborigine oltre al normale files:

  passwd: file db group: file db shadow: file db

  I dbfile di origine si trovano in /var/lib/misc ( /var/lib/misc/passwd.dbecc.). È quindi possibile conservare una copia master di questi file sul server centrale e sincronizzare i client con rsync+ cron. Svantaggi: non ci sono script di gestione già pronti per gestire i file db sul server (di cui sono a conoscenza), inoltre si incorre in un ritardo di sincronizzazione e si deve impostare un modo per rsyncconnettersi al server principale.

• I pacchetti nss-updatedbe libpam-ccredsforniscono un modo più pulito di configurarlo: con nss-updatedbte puoi ricreare localmente passwd.dbe group.db, mentre le shadowinformazioni sono gestite da libpam-ccreds. Le istruzioni su come impostarle sono disponibili nei READMEfile che accompagnano i pacchetti.

File

Per quanto riguarda i file, preferirei una sincronizzazione basata su rete per i file comuni (ad esempio Ubuntu One o Dropbox ) e quindi avere una cartella condivisa per file più grandi (forse musica, foto, video e ISO di Ubuntu). Potrebbe trattarsi di una montatura NFS, che quando fallisce non importa troppo, o una condivisione Samba, o probabilmente una di una serie di altre tecnologie.

LDAP

Fallimento LDAP sicuramente causa problemi. Non è possibile tradurre tutti i tipi di account di sistema di cui normalmente non si è a conoscenza (nome <-> numero ID) e, nella migliore delle ipotesi, il sistema si bloccherà ripetutamente per un minuto alla volta in attesa di una risposta dal server LDAP prima ricadendo nel sistema locale. Oppure il sistema potrebbe semplicemente bloccarsi e fallire completamente.

Ci sono alcuni modi per aggirare questo . Puoi configurare una copia locale e sincronizzarla, in vari modi: vedi altre risposte a questa domanda e alla domanda collegata. Puoi anche dire a LDAP di non ottenere gli utenti di sistema dalla directory LDAP, ma dai file locali. Sui nostri server abbiamo messo quanto segue alla fine del nostroldap.conf

# We need to ensure that various things can work without LDAP being available
# for example: booting, ssh in as root, apache ...
nss_initgroups_ignoreusers avahi,avahi-autoipd,backup,bin,daemon,dhcp,dhcpd,games,gdm,gnats,haldaemon,hplip,irc,klog,libuuid,list,lp,mail,man,messagebus,munin,mysql,nbd,news,ntp,nut,polkituser,proxy,pulse,root,sshd,statd,sync,sys,syslog,uucp,www-data

Si desidera assicurarsi che tutti gli utenti del sistema siano in tale elenco. Anche allora probabilmente non è abbastanza per l'utilizzo del laptop.

Dalla pagina man nss_ldap

nss_initgroups_ignoreusers <user1,user2,...,userN>
          This option directs the nss_ldap implementation of initgroups(3)
          to return NSS_STATUS_NOTFOUND if called with a listed  users  as
          its argument.

Quindi in sostanza LDAP finge di non conoscere quegli utenti senza nemmeno contattare il server principale, quindi l'NSS ricade sugli utenti locali e il sistema funziona bene.

Un'ultima idea è che se sei disposto a dedicare del tempo all'apprendimento di LDAP, potresti invece imparare alcune marionette di base e usarle per mantenere tutti gli utenti uguali su tutti i sistemi - vedi ad esempio questa ricetta fantoccio . Puppet ti permetterà anche di fare molte altre cose: l'installazione di pacchetti comuni, la configurazione comune di vari aspetti ...