[OpenAFS] OpenAFS on MacOS X

[Derek Atkins]

"Patrick J. LoPresti" <patl@curl.com> writes:

> That problem is not so much "down" as "unavailable".  We have two
> offices at opposite sides of the U.S.  The connectivity between them
> is pretty good but not perfect.  I was hoping to get away with a
> single AFS cell by making careful use of replicated volumes.

Two ways around this:

	a) Make two AFS cells with cross-realm authentication.  This
	   is more difficut to setup but is probably the better
	   long-term solution.  Each cell can act independently, but
	   people have access across the board.  You could even (if
	   you wanted to) run a single Krb5 realm so that there is
	   even a single namespace across both cells (similarly to how
	   at MIT there is 'athena', 'dev', 'sipb', and a bunch of
	   other cells that all use the 'ATHENA.MIT.EDU' kerberos
	   realm).

	b) You can make sure that user's homedirs are located on
	   'local' servers.  This way you will be assured that users
	   can always get to their own homedir when they're sitting at
	   their home site.  Obviously this doesn't help the
	   'unavailable' situation, but quite honestly there is
	   practical difference between 'down' and 'unavailable' as
	   far as AFS is concerned.

In neither case would a single 'users' directory work in the case of a
downed connection between the offices.  Obviously in the first case
you are necessarily tying a user's homedir to their home site, whereas
in the latter case you are not.  OTOH, in the latter case you may lose
connectivity to the sync-site server if the network connection goes
down.  This implies that if you're on the 'wrong' side you can't
perform any administrative tasks such as volume changes, group
changes, password changes, etc.

The question is, what do you want to happen when the network goes
down?  You have to live with _some_ visible changes (dropouts) -- what
are you willing to live with?

> As someone else pointed out, sometimes the only interesting
> information about the mount point is that it is a directory.  Of
> course, I would only want this as an option (per-mountpoint would be
> ideal), not as the default.  Someone suggested this for root.afs; I am
> suggesting it could be useful elsewhere.

The difference is that 'root.afs' is considered "special" in the cache
manager (well, the 'root volume' is considered special, and 'root.afs'
is the default root volume).  This means it's a bit easier to deal
with the root volume than anything else.  You would basically have to
change the definition of a mountpoint in order to add this
functionality, and I'm not sure how one could do that in a
backwards-compatible way.

> You could get really fancy and have the stat() return "correct"
> information if the data were readily available (say, already in the
> cache?) but return "faked" information otherwise.  Or return one thing
> for stat("foo") and something else for chdir("foo");stat(".").  OK,
> maybe not :-).  But having the permissions shown by stat() be wrong,
> or even having them change randomly, is a small price to pay for
> letting Windows and Mac users browse around in an environment with
> dodgy connectivity, IMHO.

As I said earlier, if you have dodgy connectivity you are going to
have to live with SOME kind of loss when the connectivity goes away.
The question is: what kind(s) of loss are you willing to live with?

>  - Pat

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available