What happens to LDAP user authentication and NFS home directory shares when away from the network?
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?
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 thedb
source in addition to the regularfiles
: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 withrsync
+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 forrsync
to connect to the master server. The
nss-updatedb
andlibpam-ccreds
packages provide a cleaner way to set this up: withnss-updatedb
you can recreate locally thepasswd.db
andgroup.db
, whereas theshadow
information is managed bylibpam-ccreds
. Instructions how to set these up can be found in theREADME
files accompanying the packages.
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 ...