Crossfire wrote:
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.
Nobody use krb4 with OpenAFS anymore. krb4 was used when it was
first branched from transarc.
OpenAFS use MIT krb5 or heimdal.
MIT krb5 (http://web.mit.edu/kerberos/) is straightforward, installation
wise. I do it with a script from:
http://www.acay.com.au/~oscarp/tutor/ under "Setup Kerberos Server".
With this script I can setup MIT krb5 in less than a minute.
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.
This sounds like you have been severely inflicted by AFS. This is not as
masochistic a software tool as you seem to project.
One attraction why we use OpenAFS is its simplicity of Operation, and
Management.
Precisely the opposite of what you are trying to project.
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.
Unix/Linux quota falls short as an Enterprise tool. This is also true of the
Unix/Linux permissions (or ACLs in AFS language). That's why many
applications that requires Quota and/or ACL bypass those tools that come
with Unix/Linux. These applications made up their own either by patching
the kernel or making utilities that run in userspace along with the
application.
AFS is only one of a number of Enterprise Software that made up their own.
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.
This is baloney. I have 6 workstations with three servers at home and
System Administrations
time has been tremendously reduced after I switched to OpenAFS. Now I
have a single
and unified view of all file systems regardless of which server it is
located at. I can
ascertain very quickly where to locate files. No more extended time
using locate or find or
any of those tools or switching from one server to the other or a
complicated tracker
system.
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.
Check the lists for OpenAFS. There are sites that use this. I don't.
They use these
because these sites have legacy workstations that cannot run AFS client, too
archaic.
Truly, there is no need for Samba to live along with AFS unless you've
archaic
systems.
Hope this helps.
O Plameras
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
