Qu'advient-il de l'authentification des utilisateurs LDAP et des partages du répertoire de base NFS lorsqu'ils sont loin du réseau?

À l'heure actuelle, j'ai plusieurs machines sur le réseau domestique qui sont un mélange d'ordinateurs de bureau et d'ordinateurs portables statiques. Cela devient ingérable pour moi et peu pratique pour tous d'avoir des répertoires de départ locaux, des paramètres et de la sécurité, donc j'envisage d'utiliser LDAP pour la gestion des utilisateurs communs et NFS pour les répertoires de départ partagés.

Que se passe-t-il lorsque l'un des ordinateurs portables est en déplacement? Le réseau domestique est inaccessible, donc l'authentification échouera-t-elle et retombera-t-elle sur le stockage local? De plus, lorsque l'ordinateur portable revient, existe-t-il un moyen de resynchroniser le stockage à domicile sur le serveur NFS?

Ni NFS ni LDAP ne prennent en charge les opérations déconnectées: c'est-à-dire que lorsque l'ordinateur portable ne peut pas atteindre les serveurs, il ne pourra pas accéder aux répertoires montés sur NFS, ni effectuer des recherches d'utilisateurs. Fondamentalement, il sera bloqué.

Quelques solutions de contournement pourraient être les suivantes.

Au lieu de monter des répertoires personnels via NFS, vous pouvez conserver les répertoires locaux et les utiliser à l' unisson pour les synchroniser avec ceux du serveur central. Vous pouvez exécuter unisson à partir de cron, protégé par un test qui abandonne l'opération si le serveur est inaccessible. Ce post sur AskUbuntu et celui-ci fournissent une discussion sur le sujet de la synchronisation et quelques suggestions utiles.

En ce qui concerne le problème d'authentification / autorisation des utilisateurs, les solutions tournent autour de l'utilisation de libnss-dbcomme source d'informations sur les utilisateurs:

• Installez libnss-db, puis configurez /etc/nsswitch.confpour rechercher la dbsource en plus de la régulière files:

  passwd: fichiers db group: fichiers db shadow: fichiers db

  Les dbfichiers source se trouvent dans /var/lib/misc ( /var/lib/misc/passwd.dbetc.). Vous pouvez ensuite conserver une copie principale de ces fichiers sur votre serveur central et synchroniser les clients avec rsync+ cron. Inconvénients: il n'y a pas de scripts de gestion prêts à l'emploi pour gérer les fichiers db sur le serveur (que je sache), en plus vous subissez un délai de synchronisation et devez configurer un moyen pour rsyncvous connecter au serveur maître.

• Les packages nss-updatedbet libpam-ccredsoffrent un moyen plus simple de configurer cela: avec nss-updatedbvous pouvez recréer localement le passwd.dbet group.db, tandis que les shadowinformations sont gérées par libpam-ccreds. Les instructions pour les configurer peuvent être trouvées dans les READMEfichiers accompagnant les packages.

Des dossiers

En ce qui concerne les fichiers, j'opterais pour une synchronisation basée sur le net pour les fichiers communs (disons Ubuntu One ou Dropbox ), puis j'aurais un dossier partagé pour les fichiers plus gros (peut-être la musique, les photos, la vidéo et les ISO Ubuntu). Cela pourrait être un montage NFS, que lorsqu'il échoue, cela n'a pas trop d'importance, ou un partage Samba, ou probablement l'une des nombreuses autres technologies.

LDAP

Un échec LDAP provoque définitivement des problèmes. Toutes sortes de comptes système que vous ignorez normalement ne peuvent pas être traduits (nom <-> numéro d'identification) et le système, au mieux, se bloque à plusieurs reprises pendant une minute à la fois en attendant une réponse du serveur LDAP avant retomber dans le système local. Ou le système peut simplement se bloquer et échouer complètement.

Il y a plusieurs façons de contourner cela . Vous pouvez configurer une copie locale et la synchroniser de différentes manières - voir d'autres réponses à cette question et à la question liée. Vous pouvez également dire à LDAP de ne pas obtenir les utilisateurs du système du répertoire LDAP, mais des fichiers locaux. Sur nos serveurs, nous avons mis ce qui suit à la fin de notreldap.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

Vous souhaitez vous assurer que tous les utilisateurs du système figurent dans cette liste. Même alors, ce n'est probablement pas suffisant pour l'utilisation d'un ordinateur portable.

Depuis la page de manuel 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.

Donc, fondamentalement, LDAP prétend qu'il ne connaît pas ces utilisateurs sans même contacter le serveur maître, donc le NSS se rabat sur les utilisateurs locaux et le système fonctionne bien.

Une dernière idée est que si vous êtes prêt à passer du temps à apprendre LDAP, vous pouvez plutôt apprendre des marionnettes de base et les utiliser pour garder tous vos utilisateurs identiques sur tous les systèmes - voir cette recette de marionnettes par exemple. Puppet vous permettra de faire bien d'autres choses également - installer des packages communs, configurer différents aspects ...