Hi, Tzafrir Cohen wrote: > On Fri, 22 Feb 2002, Eran Tromer wrote: >> >>I wonder about the following scenario, which is quite common: >>A large network consisting of many users and many Unix boxes. Users >>aren't supposed to have root access to any box. All home directories >>reside on a central fileserver. How do you configure the networked >>filesystem? [snip] > AFS? CODA? intermezzo? > > I'm not sure how mature are the latter two. AFS and CODA are built around > kerberos, AFAIR.
Both CODA and InterMezzo are not suitable for general deployment, according to their websites. This leaves AFS, which has two implementations -- OpenAFS and Arla. Both are open source, and OpenAFS (by IBM) looks very mature. I spent some times studying their documentation, and here are some observations. 1. AFS is available for many Unix flavors as well as WinNT/2K, but the support is not nearly as universal as that of NFS. Very few distributions have it built in. 2. AFS is not fully compatible with the Unix filesystem semantics. Significantly: - No group/other permissions using chmod: must use new commands to manage ACLs. - Permissions are set per directory, not per file. - No hard links across directories. - No 'mkfifo' (I do use it, really!). This is enough to cause major annoyance, and to make safe transition from an existing NFS-based network rather difficult. 3. Correct installation and configuration is stupendously complicated, partly because of powerful features (like replication) that are of little use in the scenario I described (AFS can't replicate read/write volumes), and partly without any apparent reason. Take a glimpse at the so-called "Quick Beginnings" document of OpenAFS, and be amazed: http://www.openafs.org/frameless/doc/QuickStartUnix/auqbg002.htm#ToC For a basic Linux installation of server+client functionality on a single computer and a single cell, I counted roughly 60 (sixty) high-level operations, consisting of roughly 100 command-line commands. The above is a great HOWTO, and yes someone could write a script, but if this is the general approach then I wonder if you'll be able to do basic administration and problem-solving without spending *quite* some time studying the voluminous AFS documentation. I would guesstimate that getting a grip on NFS+NIS or NT Server requires about 1/10 of the effort for a person of comparable skill. 4. One should expect various system facilities to fail on AFS, because the "local root can do anything" assumption no longer holds. For instance, older versions of 'lpr' pass the *name* of the file to print to 'lpd', and under AFS 'lpd' will not be able to read that file, because it runs in a process that doesn't have your authentication token. Other examples are fingerd and Samba. This can be solved (often suboptimally) by appropriate case-specific tinkering. To conclude, it appears that AFS is a viable option only if the sysadmin is willing to spend a lot of studying the gritty details AFS and fixing apparently unrelated stuff that gets broken, and the users are willing to relearn a some basic commands and live with the occasional bizzare failure when they run stuff that relies on Unix filesystem semantics. Not a pretty situation, for something as basic as a network filesystem in which you don't have to totally trust all client boxes! And let's admit it, WinNT shows that better solutions are possible. I wonder why the Unix community is so cavalier about the matter. Regards, Eran Tromer ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
