O Plameras was once rumoured to have said:
[snip] 
> Try AFS (www.openafs.org).
> 
> Why use AFS? Benefits: ACLs, Quota and easy management with rock-solid
> security. Has de-facto global FS thru VPN if you so require.

Security is suspect due to the use of a modified krb4 as its primary
authentication system.  You can use K5 instead, but its fidgetty with
MIT K5.  I know nothing about Heimdal K5 and AFS however as Heimdal
uses a different krb4 compatabiity system.

That said, its security is better than NFS.  Or SMB for that matter.
If you can put up with the strangeness AFS inflicts upon you.

> As you probably know, getting ACLs and Quota using a Linux server is a pain
> as all sorts of weird utils and kernel patches are involved. Not good
> for people maintaining the production lines. This is a piece of cake
> with AFS.

You know, if you're having trouble with linux quota support, btw,
you're not doing something right.  Linux diskquota has been around
since the dark ages.  Of course, ACLs are a different matter
altogether.

And whilst AFS does ACLs, it does so for directories only.  Oh, yeah,
and it doesn't use the Unix/Posix mechanism for controlling them.

Same deal with Quota -- Quota is per volume, and again uses its own
mechanisms to interogate.

The thing about AFS is its also about 20x more complicated than the
average individual needs.

More specifically, AFS is not just a simple filesystem exporter, its a
full blown distributed filesystem.  And its a distributed filesystem
based around the principle that you have a single global namespace
(/afs) for all systems running AFS, and you snap your volumes into
that space and arrange them as suits you.  This means any directory on
AFS can actually be on any given machine.  (there are tools to manage
this).  

Oh, and then lets add access permissions and authentication, tickets,
etc.  The average unix user has not experienced PAGs and Tickets and
the associated joys.  Trying to explain to a user why their background
job suddenly stopped being able to access their home directory 24
hours after they logged in would probably bring on all sorts of
amusement.

So yeah, whilst this all sounds good in theory, in practice is a bitch
to manage unless you *REALLY* *REALLY* need it.

If you're doing a public access system for over 500 users, I would
qualify that as really needing it, if you have the manpower to support
it.

For a hosting system, or smaller systems, its overkill.

> AFS can handle Samba thru translators, if you really need it. But why
> would you ?

Eh?

AFS can only mount AFS.  Windows machines can access AFS either
natively (using the windows AFS client which involves smoke, mirrors
and black magic and hence runs like a dog) or via a samba server
running in plaintext password mode (unless somebody has come up with
some funky AFS ticket forwarding mechanism since I last looked) which
negates the point of ticket based authentication.

There is no way to mount an SMB path into an AFS tree.  To allow such
would be horribly wrong anyway.

C.
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Reply via email to