[479] in athena10
Re: Simulating AFS outages with pyhesiodfs
daemon@ATHENA.MIT.EDU (Geoffrey Thomas)
Wed Sep 3 15:06:08 2008
Date: Wed, 3 Sep 2008 15:05:22 -0400 (EDT)
From: Geoffrey Thomas <geofft@MIT.EDU>
To: Jonathan D Reed <jdreed@mit.edu>
cc: athena10@mit.edu
In-Reply-To: <Pine.LNX.4.64L.0809031401100.32734@infinite-loop.mit.edu>
Message-ID: <alpine.DEB.1.10.0809031435130.8559@vinegar-pot.mit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
On Wed, 3 Sep 2008, Jonathan D Reed wrote:
> The situation is still pretty much unusuable, though. Rather than try and
> let Ubuntu figure out what's up with the user's homedir, is it worth adding
> code to the login sequence that explicitly checks if a user's homedir is
> available and punts if it isn't?
It's worth adding code to support fallback lockers (e.g., if
/afs/sipb/project/sipb is not available, attach /afs/athena/contrib/sipb).
As part of this, it might make sense to have an intelligent default case,
if no locker is available. Would simply returning ENOENT or an unwritable
directory make GDM deal close to properly?
We could plausibly mount a tmpfs there and syslog a message saying we did
so, if there were a reasonable way to catch that and print the "You are
using a temporary homedir, don't type 'inc'" message; is there?
Alternatively, we could mount a tmpfs that includes a .cshrc and a .bashrc
that prints this message.
The pyHesiodFS code also needs to periodically recheck locker
availability. It might be good to implement this alongside periodically
redoing Hesiod lookups rather than effectively caching them forever.
--
Geoffrey Thomas
geofft@mit.edu
