Subject: Re: [netatalk-admins] Whereabouts of AFS

From: [email-masked] (William P. McGonigle)
Date: 15 Apr 98 16:58:05 EDT

--- Tony Moran wrote:
Oh..ok..  (showing his ingenue now) So how come support for it is provided
for it in Asuns 1.4b2 distribution - where does AFS fit into the Netatalk
picture ?
--- end of quote ---

Strictly, it's provided in the asun distribution because it's provided in the UMich distribution.

It's provided in the UMich distribution because they (presumably) use AFS at UMich.

Say, for instance, you want AppleShare access to ten different machines. Or a hundred machines, or a thousand machines.

You probably don't want to run that many copies of netatalk.

So, you run netatalk on one machine and access the drives on the other machines through AFS.

Why AFS and not, say NFS?  For one, it supports Kerberos principals for file permissions.

Say you have an insanely huge number of users, like hundreds of thousands.  You want to store those users' names and passwords exactly once so you don't need an army of account administrators.  Then you use a UAM that authenticates you off of Kerberos for access to netatalk.  

One name and password works everywhere.  Slick, eh?

-Bill

PS AFS now stands for AFS.  It used to stand for Andrew File System, then Transarc bought it so it's not part of Andrew (CMU) anymore.

---

From: Dan Pritts <[email-masked]>
Date: Wed, 15 Apr 1998 18:16:03 -0400 (EDT)

> It's provided in the UMich distribution because they (presumably) use

definitely

> Say, for instance, you want AppleShare access to ten different
> machines. Or a hundred machines, or a thousand machines.

> other machines through AFS.

While theoretically accessing afs does allow you to have access to
ten or a hundred or a thousand machines' files, it doesn't work 
really as you describe. 

In practice, you don't just make j.random.machine an AFS file server
and serve its local files to all the other machines at your
installation; you dedicate machines to afs file service (as well as
authentication and other database services) and store (perhaps all)
your files on the afs servers.

The unix clients see a filesystem tree (usually) mounted under /afs and
can see your AFS cell under, eg, /afs/umich.edu/.  Other afs cells are
also available, if their adminisrators have chosen to announce them
and/or aren't filtering out afs traffic on their internet links.

Performance is much better than NFS in WAN applications since each
client has a local disk cache of AFS files.  Each server can handle
many many more clients than an NFS server due to the client-side
caching.

There is a Windows NT client as well.  Earlier windows and macs must
have some sort of translation done to access files in /afs.  samba is
typically used for this for windows; netatalk for macs (cap may work
also, i don't know).

One downside is that the client side of AFS requires significant
kernel-level work, and transarc doesn't support every unix under the
sun (you can, though, make an AFS-NFS translator much like you would
use netatalk), and has had some reliability problems (eg, under solaris
2.3).

dan pritts 
734/996-0169
think i'm gonna buy myself a Rolls, maybe a Chevrolet...