[OpenAFS-port-darwin] disktool -r in OpenAFS StartupItems script

Ragnar Sundblad ragge@nada.kth.se
Wed, 23 Apr 2003 02:09:07 +0200


--On den 22 april 2003 19:04 -0400 Steve Lidie <sol0@lehigh.edu> wrote:

> The biggest problem here at Lehigh is that we use kaserver for
> authentication, and so far neither of the krb plugins can get me an AFS
> token.

I don't remember if we ever discussed this, I think not -
you probably has to set the
 string_to_key_type = XXX
in /Library/Preferences/edu.mit.Kerberos to something that makes
it use afs style string-to-key, my guess would be "afs_string_to_key"
based on a strings on the Kerberos lib.

>  That's a big problem during login, since Mac OS X wants to
> read/write ~/Library.  My current kludge is a Perl/Tk program that runs
> as a LoginHook to re-authenticate (e.g. does a klog).  Until a token is
> acquired, login proceeds very slowly (i.e. ~= 60 seconds).

I guess this is the good old 3 second delay bug/feature that kicks
in when something fails to often, it is (kind of) fixed in modern
openafs servers. But you want to have tokens at login time anyway.

> I wasn't aware that anyone else was using AFS as a home directory, so I'd
> like to hear all war stories.  I can say that IE's default cache size of
> 10 MB can cause login to fail if you only have a 10 MB quota.

We use the Arla client which currently only caches entire files and
not parts thereof, which makes every write to the IE cache a
10MB transfer and IE go very slow.

To fix this, we at login time as root set up a directory
/tmp/<uid>/Caches using the loginhook feature, and we have a
for-every-user login program that, as the user, runs a shell
script that creates a link ~/Library/Caches to /tmp/<uid>/Caches.
This fixes the page cache, not the download cache though, that
one seems much more stubborn.
We also set up a /var/tmp/<username>/ and a link
~/Desktop/"Local Temporary Files" while we are at it.

Apart from IE, must things works very well and are very well
behavied and has no problems living in AFS. We don't do anything
special at all to have users use their ordinary unix accounts
and afs home directories. They just log in and things work.

Regarding "disktool -r":
We use "disktool -r" whenever we mount or unmount afs (there is
a nice GUI program to do these things with arla, it can also
set cache size and other things, very good for mobile users).
This has always, or at least for very long, been working very
well regardless of when you do it or if someone is logged in
on the console or not. On most machines we just do it once
when we mount afs at boot time, of course.

/ragge