[ (^_^ ) ( ^_^) ]
- Sections
-
home > how to > linux over quota session
How to gracefully handle when Linux users exceed their quota and the grace time expires.
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.
The problem
If you have administered Linux machines where the users have a quota imposed on their home directory then you'll be familiar with the problem that arises when a user exceeds their quota and the grace time expires. With the set up described above their user name and password are accepted, they see a few seconds of blank screen and then get taken back to the login screen. Typically the user will then declare that they can't log in although they can log in, the problem is that their session fails so they get logged out again.
Why does this behaviour occur? By default X creates a .Xauthority file in the user's home directory. If the home directory is not available then X is supposed to create the .Xauthority file in /tmp. (Where it will be called something like .Xauthrandomchars to prevent clashes.) If the user is over quota and grace time is expired their home directory can't be written to. The problem is that in the described set up the user can actually still create files in their home directory but they are created zero length. So the .Xauthority file is created in the user's home directory, X sees that it got created but doesn't see that it got created zero length. X tries to use the zero length file, the X session fails.
If you search on Google you'll find numerous computing support pages which talk about logging on to a command line session on a different console then getting yourself back under quota. Whilst this solution is perfectly valid and I myself have written a FAQ entry for it the past, it is extremely unfriendly for inexperienced users. Firstly there is no explanation given to the user that they are over their quota. When all they get is a few seconds of blank screen, how are they supposed to know they they are over quota and that they should then log in with a command line session unless they happen to have already read the info on this scenario whilst they were able to log in and remembered it? Secondly, the solution assumes that the user is comfortable using the command line. If they're not, then they're stuck. With this in mind I decided to try and come up with a better solution.
The solution
In brief
When a user logs in a check is made to see if they are over quota. If they are, then a second X session is spawned on a different console, a message is displayed telling the user what has happened, they're given the choice of running a script which will delete various cache files to try and get them back under quota and if that fails they will get a minimal graphical environment with a GUI file manager, a command line and some helpful instructions.
In more detail
The first thing we need to is a way to check the user's quota when they log in. This is done using a script (quotacheck - downloadable along with all other files mentioned via the link at the end of this guide) which is put in to /etc/X11/xinit/xinitrc.d
When an X session starts up everything in /etc/X11/xinit/xinitrc.d gets run (as the user who is logging in). quotacheck attempts to write a 1byte file in to the user's home directory and checks to see if the string "Disk quota exceeded" appears on stderr. If it does, then the second X session is launched. (It is necessary to start a second X session because the one that started when the user logs in will fail.) If it doesn't the 1byte file is deleted and the script doesn't do anything else so the X session just carries on as usual.
The second X session is launched using a modified version of the system startx script. See the comments at the top of the file for what is different, but it includes putting the .Xauthority file in to /tmp where it will be properly created rather than trying to put it in the user's home directory. The startx script calls an xinitrc file which controls what runs in the second X session.
The first thing that happens is a little script gets run which uses imagemagick to display an image in the root window to give the effect of wallpaper. Initially I didn't have this but I found that the default background is a pattern which on some monitors is very unpleasant to look at on some monitors as it appears to move.
The second thing that happens is the blurbandautofix script gets run and the user sees a message:
If the user selects 'Yes please' then then they see either this:
or this:
depending on whether the freeupdiskspace script got them back under quota or not.
The freeupdiskspace script is something I wrote about a year before I came up with this over quota session idea. Since I wrote it I've come with a few config tweaks that help users stay under quota by moving cache files to the local disk and hence make the script less useful than it was originally, which may be the subject of another How To, but it's still worth trying in when a user is over quota.
If the freeupdiskspace script doesn't get the user back under quota or they declined the offer to run the script then the minimalist graphical environment is launched. The idea is to give users the tools the need to get back under quota and nothing more. So that's a file manager, to delete files with, a command line for them to check their quota at (by running the quota command) and some helpful instructions. The session looks like this (note that the windows have been moved to nice positions for the purposes of the screenshot and some parts of the image have been deliberately smudged).
When the user types 'exit' at the command prompt the second X session will end, the user will get taken back to the first X session which then gives the user the usual few seconds of blank screen and then the user ends up back at the login screen.
I use Konqueror as the file manager because the machines I implemented this on give users KDE as the default environment. Using Konqueror does present a problem when when files can't properly be created in the user's home directory. Hence a fake home directory is created and Konqueror is launched using the konqwrapper script. Yes, I could have given them some other file manager and avoided the need to mess around creating a fake home dir and all the rest, but the point of this exercise is to help people and it's more helpful to give them a file manager they recognise than something they've never seen before. So I consider the hacking required to get Konqueror working worthwhile.
A .kde directory containing some config is copied in to the fake home directory. This sets various helpful things like a profile which displays the files in the user's home dir in a manner which lists the files sizes (as opposed to the defalt icon view which just shows the filename), makes the Delete item show in the context menu and ensures that the filesize view icon is visible. Note that making the filesize view icon visible is done using the konqueror.rc file in the .kde directory and this file may potentially cause you problems. Other files in the .kde directory are very minimal. I set the options on my own account, checked where they were represented in the config files and created config files that contain just those settings. This didn't work for the konqueror.rc file - I had to copy the entire file from my account. So it may cause you problems if there is stuff in there which is specific to KDE 3.5 under SLED 10.
Unfortunately it is not possible to remove the 'Move to Wastebin' option from the Konqueror context menu without altering the Konqueror source and re-compling. Which is way too big a job to be worth the effort. It's a shame that the KDE folks chose to include a user config option to add the Delete option but not to remove the Wastebin option but there you go. (Note that SLED 10 uses the name Wastebin, other distros may use different names such as Deleted Items or Trash.) From a technical point of view having the wastebin option there is not an issue because Konqueror is running with a fake home so if a user uses the Move to Wastebin option the file will actually go in to the trash dir in the fake home rather than their own home directory which would not do anything to reduce their quota usage. It is unfortunate from a user communication perspective though because the Move To Wastebin option doesn't do what it does when they're logged in with a normal session. This is avoided by stating in the instructions that they should use the Delete option instead (even though the Move to Wastebin option would actually have the same effect) and hoping the user bothers to read the help provided.
Notes
The files
All files mentioned above are here overquotasessionfiles.tar.gz
Notable packages required
To implement this solution as described the following packages need to be installed.
Set ups other than the one described
Whilst this solution has only been tested in the production environment described it should be usable for any version of Linux though some adaptation may possibly be required and some behaviour may be different to what is described in this guide. For example I have observed that when a user's home directory is on the local disk of the Linux machine with a quota applied, once grace time has expired and the user logs in the .Xauthority file is created in /tmp but then KDE produces various error messages (none of which give any hint to the user as to what is wrong), fails to start up and the the user ends up back at the login screen.
Testing
To implement this solution you'll obviously need to test it. This will require an account which you can put over quota at will and have grace time expire without waiting for the standard 7 days. I set up a non-production NFS server for the purpose and set grace time to 2 minutes. The easiest way to put the account over quota is to set the quota to a few tens of MB and then use dd to create a file of a size between the soft and hard limits.
How to take screenshots
Screenshots were produced using the method described here.
^ Top
modified:29th August 2008
xhtml
css