Path: utzoo!attcan!uunet!aplcen!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!swrinde!emory!utkcs2!de5
From: de5@de5.ctd.ornl.gov (Dave Sill)
Newsgroups: comp.unix.admin
Subject: Re: Setting up Home dirs...
Message-ID: <1990Sep20.141822.26387@cs.utk.edu>
Date: 20 Sep 90 14:18:22 GMT
References: <2422@dali> <1990Sep20.053541.18081@cs.utk.edu>
Sender: news@cs.utk.edu (USENET News System)
Reply-To: Dave Sill <de5@ornl.gov>
Organization: Oak Ridge National Laboratory
Lines: 61

In article <1990Sep20.053541.18081@cs.utk.edu>, moore@betelgeuse.cs.utk.edu (Keith Moore) writes:
>
>We use amd instead of Sun's automount, for several reasons -- but mainly
>because it's more flexible, more robust, and it runs on all of our machines.

Where can one obtain and/or learn about amd?  What does it do?  Who
wrote it?  What are the security issues?

>Our users' home directories (in the passwd file) are all of the form
>/$color/homes/$user.  We don't imbed the name of the machine that does
>the file service...because we want to have the freedom to move users around
>between machines to balance load and disk usage between groups of users.
>We use colors as partition names precisely because they are arbitrary.
>Each machine has a symlink for each color from /$color/homes -> /amd/$color,
>and the amd map associates a machine and disk partition with the particular
>color.

I'm easily confused, I guess.  Could you give a simple example with a
couple servers and a couple clients?

>(The ".../homes/..." part is an anachronism from the days when these were 
>hard NFS mounts in /etc/fstab and the system would hang if you typed `pwd'
>and any directory in any ancestor of your current directory happened to be 
>an NFS mount point on a unreachable file server....Yuk!

This is something that amd/automounter fixes?

>This scheme actually works remarkably well, but there are lots of little
>things we've had to learn about.  The biggest problems we have found 
>have been with mail -- sendmail isn't prepared to deal with the kinds of 
>failure modes you run into in a distributed file system.   (e.g. What if 
>a user's .forward file is missing because the file server that contains 
>his home area is down?)  I've managed to solve these problems without 
>patching sendmail by replacing the "local", "prog", and "file" mailers 
>with small programs or shell scripts that do some error checking before
>actually delivering the mail.  

What are ``the "local", "prog", and "file" mailers''?

>Other problems have been due to NFS mapping root->nobody on remote mounts.
>Most recent NFS server implementations provide a way around this, but we
>still have a few machines that don't fix this problem.  We therefore have
>a special version of "calendar" that does an "su" to the owner of the
>calendar file in order to read it, in case it's not readable by "nobody".

Don't use no double negatives, Keith.  :-)

>This version of calendar also does "ypcat passwd" instead of reading
>the /etc/passwd file, so it scans directories for every user in the entire
>passwd map...we have to make sure that only one system in the entire 
>"cluster" runs calendar, else things slow down to a crawl.  We run it
>on our mail server, since the mail that calendar generates will end up
>there anyway.

Again, I show my ignorance.  What's this "calendar" program?  And how
can you use ypcat if you aren't running YP/NIS?

-- 
Dave Sill (de5@ornl.gov)
Martin Marietta Energy Systems
Workstation Support