megaflexdestiny.net

[ if swallowed seek immediate medical advice ]
Sections

home > how to > linux log in without home


How to allow users to log in to Linux machines when their home directory is missing.

This guide is written based upon the following production environment set up: Linux machines run SUSE Linux Enterprise Desktop 10. The desktop environment is KDE 3.5. The home directories are mounted via NFS from a Solaris server and are mounted/unmounted as required by autofs at /home/username with the mountpoint inside /home being created/removed by autofs. Autofs uses a map supplied by a NIS server.

The problem

If you administer Linux machines where the user's home directories are mounted from a remote server then you may have experienced the annoying situation where that server goes down for some reason and as a result no one can log in to your Linux machines. (Well they can log in, they just get kicked out again due to not having a home directory.) This is a terrible situation because it means the Linux machines become useless to people. All they can do is sit and glare at them whilst they wait on hold to the Helpdesk to find out what is going on. This is a situation that unfortunately, due to failure of servers that are not under my control, I have experienced more than once and with downtime being measured in days rather than hours. It got me thinking that it would be really good if there was some way that a user could get logged in with a full graphical session even if their home directory was missing. Sure they won't have access to their files or usual settings, but they will actually be able to use the machine which would be a vast improvement.

Unfortunately I couldn't find any information about how to do something like this. I did find one reference on an MIT webpage that mentioned that their machines had such a facility but they were removing it. Someone there was kind enough to reply to my query regarding how they achieved what sounded like I wanted to do but it turned out their method used binary files and was clearly beyond my ability to implement. Not that surprising really given that X was originally developed at MIT. So I set about trying to figure out a solution for myself.

The solution

In brief

When a user logs in a check is made to see if their home directory got mounted from the server or not. If it hasn't, then a home directory is created on the machine's harddisk, autofs is turned off to allow the creation of a symbolic link in /home to that points to that directory, the user gets logged in with that directory as their home directory. Some information is then displayed which explains to the user what has happened and what they should do about it. When the user logs out the symbolic link in /home is removed and autofs is started up again.

In more detail

First off I'm going to have a bit of moan about something called GnomeVFS on account of how the first solution I came up with, which was a lot neater than the one I ended up implementing, wasn't usable because of the way GnomeVFS works. Getting this out of the way may stop you thinking "why don't you just do..." later on. My first solution involved dropping a script in to /etc/X11/xinit/xinitrc.d which checked to see if the directory specified by $HOME existed and if not, created a directory on the local disk and redefined the value of $HOME to that instead. This worked in so much that KDE started up fine using the newly created directory as the user's home directory because according to the value of $HOME, that was the user's home directory. However it became apparent that this wonderfully simple solution wasn't going to be usable in practice when I tried to run Firefox. Various GTK based software including Firefox makes use of GnomeVFS. GnomeVFS wants to know where a user's home directory is but it does not look at $HOME. Instead it does a getent call and that call returns the location of the user's home directory as defined in /etc/passwd or whatever source is defined in /etc/nsswitch.conf. That location is where the user's home directory should be. But the point of this scenario is that the user's home directory doesn't exist. E.g. getent says that the user's home directory is /home/bob but because /home is controlled by autofs and /home/bob couldn't be mounted, /home/bob does not exist. So as I discovered, applications that uses GnomeVFS will not run because they try to use a home directory that does not exist. It took running Firefox under strace and going through the output to figure this out. I expect there's a reason GnomeVFS behaves how it does but for the purposes of this exercise it is frankly bloody annoying.

So now I've got my GnomeVFS rant out of the way, I'll explain the solution I actually implemented. To make applications that use GnomeVFS run the user's home directory needs to exist at the location specified by getent. Which is a problem because autofs controls /home so you can't create anything in there whilst autofs is running. So autofs needs to be turned off and this can of course only be done by root. Which in turn means you have to get something running as root whilst the user logs in. I did this by modifying the XDM Xstartup and Xreset scripts. The modification is done by S09xdmmod, (downloadable along with all other files mentioned via the link at the end of this guide), which as you may guess from the name is used as an init.d script. I put it in /etc/init.d/rc5.d/ Putting the script here means that if the modifications to the Xstartup and Xreset files are lost due to an update being applied they are replaced when the machine is rebooted. (The machines I administer are configured to only apply updates during the shutdown sequence which helps with keeping custom configs and tweaks in place.) The modification is kept to a minimum, a single line is added which calls a script, tmphomedirhandler, with an argument to indicate whether it's being called at log in or log out. The tmphomedirhandler does all the hardwork, it creates the temporary home directory if required and stops/starts autofs as required. It also copies some minimal KDE config information in to the newly created directory to set the home directory to something which should leave the user in no doubt that they are not logged in with their regular home directory.

This is what the user sees when they log in and their home directory couldn't be mounted: Message warning the user their home directory did not get mounted This is what they see once KDE has started up The information the user is shown regarding what's happened and what to do about it The clickme icon on the panel will display the information again. Here is the wallpaper in all it's unsubtle glory. I don't get it, what are you trying to say?

Like I said, I do not like the solution I ended up implementing as much as my original one. The original solution did not involve modifying any existing files and everything ran with the privileges of the user who was logging in. Modifying XDM files is far from ideal, but it works, not just in testing, I use it in a production environment and have seen it work on several occasions where a user's home directory couldn't be mounted.

Notes

The files

All files needed to implemet this solution are here tmphomefiles.tar.gz

Things to be aware of

An unfortunate side effect of this solution if the user fred logs in to the machine whilst the user bob is logged in with a temporary home directory then fred's home directory won't get mounted because autofs is turned off.


^ Top

modified:21st October 2008

xhtml

css