NFS is the NAS equivalent of Democracy: the worst implementation except for all the others. If you want a remote home directory for your users, chances are you’ve contemplated Automount as the solution for it.  I’ve been working on Automount support for the web UI in FreeIPA.  Here’s the concept.  When you add a user, you want to delay creation of the users home directory on some subset of Network Devices.  This is a tricky problem to solve.  Here’s why.

First, the why of “delaying directory creation.”  Lets say that your organization has multiple offices around the globe.  Each office has its own local home directory NFS server.  You don’t want to go remote (offsite) for home directories, because the latency and network instability of outside providers can make your system unusable.

However, lets add in that you are a tech company with lots of “labs.” and the home directories inside the labs are not supposed to be visible to the world outside the labs.  You still manage home directories via Automount, but they are separate from a users ‘normal’ home directories.

OR:

Lets say that your organization is huge, but is primarily a Windows shop.  Only those users that are actually going to be involved in the Linux/Unix side of development need access to the NFS home directories.

Basically, what it PAM Odd Job has to do can be thought of as:

getent users $USER
stat $HOME
mkdir $HOME
cp -r /etc/skel/* $HOME
chown -R $USER:$GROUP /home

OK.  So we only want to creat Unix home dirs on demand.  The simplest setup is to just mount the entire /home directory on the client machines, and then use the PAM Odd Job module to create the directories on demand.  The problem is that typically you don’t want to set up NFS this way.  NFS should be set up with root squash, which means the Odd Job module, which runs as root, won’t have permissions to create the /home/$USER directory it needs to, nor to chown it.

It actually is a little more complex than even this.  The typical setup for Automount is that you don’t want to mount the entire /home tree, as doing ls /home on any system can really bog down with enumerating all of the different users.  Instead, you want to use the Automount pattern ruls that lets you mount just /home/$USER when $USER logs in.  Now we have areal chicken/egg problem, as that user is trying to mount a directory that has not even been created on the NFS server. Automount will keep the Odd Job process from actually creating a subdir under /home locally and NFS will deny the request to make the directory remotely.

Here’s a brain-dead approach:

1. create a user.  Set a temporary password
2. Admin logs in on the nfs server as that user to trigger directory creation
3. Admin resets the users password.

OK, there has to be a better way.  At a minimum, we’d like to use something along the lines of

ssh root@nfsserver mkhomedir_helper $USER

which creates the home directory if it doesn’t exist. Of course, this means that the nfserver has to be a Fedora type device. For many NAS applicances, that might not be true. It also has to allow ssh as root on to it, which is a security hole.

Another option is to mount the /home directory as root on the IPA server, and configure the NFS server not do to root squash from the IPA server. Again, a possible security hole.

So, the next improvement is to create a user that has permissions to create directories on the NFS server, and to mount the share on the IPA server as this user, and then use a mechanism to create the home dir as this user. This use should have permissions to chown the new directory to the newly created user. There is significant documentation out there on NFS that explains how to get (local) root perform actions as a different remote user. Actually, since the IPA server runs as “httpd” it might be tempting to make the httpd user be the one that can create the remote directories, and then kick off the script from mod_wsgi. A better approach would be to use sudo to do it, as the httpd daemon should have limited privileges. What we’d really like is a PAM shim here. System security services daemon (sssd)  is growing into that role.

A very common case is that the home directories are stored on a storage array co-located with the host, and replicated to other sites across the enterprise. For a laptop, the home directory would be locally managed, and then syncronized with a centralized backing store.  Máirín Duffy wrote up a pretty good prototype based on her setup: http://mairin.wordpress.com/2011/05/25/fedora-sparkleshare-howto/.  In this case, auto-creation of the home directory on the laptop would be necessary but not sufficient.

Should ipa user-add have a hook to call out to a remote script?  A possibility is that we have a directory structure, some thing like :  /etc/ipa/scripts/user/add  and anything we drop in there that gets tagged as executable will get executed when a user gets added.  We’d probably only allow execution for add and delete cases, as list and show get executed too many times.  reporting the result afterwards would be problematic, too:  we’d need to collect up the output and save it to a log, as well as providing a small amount of feedback to the end user.  While this approach provides a high degree of flexibility, it does nothing to deal with the on-demand and multi-directory issues listed above, but it would cover many basic use cases.

FUSE provides an interesting toolkit in which to craft solutions.  One approach might be to provide a very thin shim on top of /home that, if stat or open fails on $HOME for a user  performs a authorization check and creates the directory on demand.

I’d be interested in hearing other people solutions to home directory creation.