These notes describe client-side issues and their solutions when using Kerberos on Ubuntu dapper. This content was originally at https://wiki.oucs.ox.ac.uk/oucs/OULD/KerberosAndAFS but was moved here to increase the visibility.
What to do when Sun's Java overwrites kinit
Sun's java also has a program called kinit which does very similar things. It overwrites /usr/bin/kinit, given the chance. This results in an error message:
Exception: krb_error 0 Could not load configuration file /etc/krb5.conf (No such file or directory) No error KrbException: Could not load configuration file /etc/krb5.conf (No such file or directory) at sun.security.krb5.Config.<init>(Config.java:143)
The solution to this is:
apt-get install --reinstall krb5-user
This will overwrite the java kinit with the normal one. In theory this should be solvable using the alternatives system, but that approach doesn't seem to work for me, since the kinit from kerberos doesn't register with the system.
What to do when you accidently use kinit when running as root
The error message:
Password for syeates@OX.AC.UK: kinit(v5): Internal credentials cache error when initializing cache
indicates that the current user doesn't have write permissions for the 'credentials cache,' which is a file in /tmp/. I've run into it twice, in both cases the root of the problem was issue the kinit command from a shell running as root, which resulted in the cache being owned, readable and writable only by root. The fix is to find the file and delete it (you'll need to be root to delete it).
sudo rm -i /tmp/krb5*
Will do the trick nicely.
Kernel update invalidates openAFS module
Problem here is that because I'm using custom AFS kernel modules, whenever the standard Ubuntu kernel gets updated (usually for very good reasons, like security or bug fixes), the new kernel doesn't pick up the modules because they no longer match. The result is a complete lack of any OpenAFS error messages from the booting new kernel (it literally doesn't know it's meant to be doing AFS at all), until the point where the user logs in and $HOME can't be loaded, because the system has never heard of /afs/. X login fails with:
Sep 22 09:29:14 syeates-oucs gconfd (syeates-5018): Failed to load source "xml:readwrite:/afs/ox.ac.uk/user/test/syeates/homedir/.gconf": Failed: Could not make directory `/afs/ox.ac.uk/user/test/syeates/homedir/.gconf': No such file or directory ... Sep 22 09:29:15 syeates-oucs gconfd (syeates-5018): Failed to log addition of listener x-session-manager (Failed: Failed to open gconfd logfile; won't be able to restore listeners after gconfd shutdown (No such file or directory))
The solution is to follow the instructions are rebuild a new OpenAFS module, load it as instructed and reboot. Everything should now work fine.
Ideally there would be a mechanism to rebuild such local modules automagically when installing a new kernel, but there doesn't appaer to be.