What happens to LDAP user authentication and NFS home directory shares when away from the network?

Question

At present I have several machines on the home network which are a mixture of static desktops and laptops. Its getting unmanageable for me and impractical for all of them to have local home directories, settings and security so I am considering using LDAP for common user management and NFS for shared home directories.

What happens when one of the laptops are out on the road? The home network is unreachable so will auth fail and fall back to local storage? Also, when the laptop returns is there a way to resync the home storage to the NFS server?

Answer 1

Neither NFS nor LDAP support disconnected operation: i.e., when the laptop cannot reach the servers, it will not be able to access any NFS-mounted directories, nor will it be able to perform user lookups. Basically, it will be stuck.

A couple of workarounds could be the following.

Instead of mouting home directories via NFS, you could keep local directories an use unison to synchronize them with the one on the central server. You can run unison from cron, guarded by a test that aborts operation if the server is unreachable. This post on AskUbuntu and this other one provide a discussion on the topic of synchronization and some useful suggestions.

Regarding the user authentication/authorization problem, solutions revolve around using the libnss-db as a source for user information:

• Install libnss-db, then configure /etc/nsswitch.conf to look up the db source in addition to the regular files:

  passwd: files db group: files db shadow: files db

  The db source files are located in /var/lib/misc (/var/lib/misc/passwd.db etc.). You can then keep a master copy of these files on your central server and synchronize the clients with rsync+cron. Disadvantages: there are no ready-made management scripts to manage the db files on the server (that I know of), plus you incur a synchronization delay and have to setup a way for rsync to connect to the master server.

• The nss-updatedb and libpam-ccreds packages provide a cleaner way to set this up: with nss-updatedb you can recreate locally the passwd.db and group.db, whereas the shadow information is managed by libpam-ccreds. Instructions how to set these up can be found in the README files accompanying the packages.

Answer 2

Files

As for files, I would go for a net based sync for common files (say Ubuntu One or Dropbox) and then have a shared folder for bigger files (maybe Music, Photos, Video and Ubuntu ISOs). This could be an NFS mount, that when it fails doesn't matter too much, or a Samba share, or probably one of a number of other technologies.

LDAP

LDAP failing definitely causes trouble. All sorts of system accounts you're normally unaware of can't be translated (name <-> id number) and the system will, at best, repeatedly hang for a minute at a time while waiting for a response from the LDAP server before falling back to the local system. Or the system might just lock up and fail completely.

There are some ways around this. You can set up a local copy and sync it, in various ways - see other answers to this question and to the linked question. You can also tell LDAP to not get the system users from the LDAP directory, but from local files. On our servers we have put the following at the end of our ldap.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

You would want to make sure that all system users are in that list. Even then it's probably not enough for laptop usage.

From the nss_ldap man page

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.

So basically LDAP pretends it doesn't know those users without even contacting the master server, so the NSS falls back on the local users and the system works fine.

One last idea is that if you're willing to spend the time learning LDAP, you could instead learn some basic puppet and use that to keep all your users the same across all systems - see this puppet recipe for example. Puppet will allow you to do a lot of other things aswell - installing common packages, common set up of various aspects ...