On Thu, 16 Apr 1998, Paul Blackburn wrote:
: Rich,
:
: >The University of Michigan directory structure (which is the same one being
: >proposed) is indeed the right one to use. Given the afs_id you know
: >exactly where the users home directory. This is exactly what you want,
: >no lookups.
:
: How would you compare and contrast the UoM structure with the following:
:
: Let's say you have decided on 64 "mid level" directories
: (eg /afs/@cell/u/u0/ through /afs/@cell/u/u63/).
: You add a new user "deedee" with AFS-id, say, 1025.
: Take modulo 64 of 1025 gives 1.
: So, volume user.deedee is mounted at /afs/@cell/u/u1/deedee
: and make a symbolic link /afs/@cell/home/deedee -> /afs/@cell/u/u1/deedee
:
: Given the AFS-id, it is trivial to locate the $HOME.
: Also, the key advantage of this is that the user volumes
: are spread evenly across all the 64 "mid level" directories.
:
: If you really wanted, you could still have the /afs/@cell/user/d/e/deedee
: as a symbolic link to /afs/@cell/u/u1/deedee (at account creation).
: --
In my experiance ths following example is a nightmare. We had this with a
40,000 account cell. It was not obvious to the average user where someone
elses home space was. People would copy other peoples shell scripts or
source code and the paths where always wrong, which added more confusion.
The attempt to work around this was as you suggested with a link to a common
directory. Think about about "cd /afs/@cell/home/ ; ls -Fs". With Netatalk
for the MAC and AFS or Samba for the PC, their browsers would hang for long
long times, and have little value with 40,000 folders.
We have since joined much of this cells filesystem with another cell that
supports a good number of departments, many with their own AFS (or NFS)
servers. (i.e. they manage those quotas and those users.)
Our current layout looks like this from the cells we support;
ls /:/home
bmgt econ enag enee enma enre glue isr math psyc zool
chem elves ence enfp enme ense ipr lbsc micb socy
csc enae ench engr ennu ents ipst lps phys wam
With system:enee-managers maintaining /:/home/enee/*.
Some of these are further divided into administrative boundries.
ls /:/home/enee/
admin alumni faculty grad staff ugrad
But any directory with much more then a screenfull of subdirectories
gets put in to the format others have mentioned;
ls /:/home/phys/
a b c d e f g h i j k l m n o p q r s t u v w x y z
The general undergrad area (40,000) is two deep.
ls /:/home/wam/a/
0 2 4 6 8 a c e g i k m o q s u w y
1 3 5 7 9 b d f h j l n p r t v x z
However, the path in the passwd file looks the same for everyone.
hesinfo rsw passwd
rsw:X:5378:20:Randall Winchester,CSC-1319,53690:/homes/rsw:/bin/tcsh
We do this with amd (the public domain automounter) which we run on
everything.
hesinfo rsw homes.amd
fs:=/afs/glue.umd.edu/home/elves/rsw/home
This also allows us to support NFS or DFS in a similar fashion.
Everyones home is in /home/$USER, but "cd /home ; ls -Fs" only shows
currently accesses directories, which makes the PC and MAC browsers alot
happier.
(side note: "hesinfo" is from Hesiod, which means we keep *alot* of our
information in our DNS servers.)
Actually our "user" volume layout is different then most also.
/users/$USER gets you (wuth the automounter) to the top of a users volume.
They all look like this:
ls /users/rsw
backup home mail pub
They do not have "administrative" control over the top of the volume.
This allows us to keep the "home" private. In "pub" are their web pages and
other public and ftpable files. Their "INBOX" is in "mail" along with
.forward, .vacation, etc... files. We mount their backup volume as "backup".
Access list for . is
Normal rights:
system:authuser k
system:anyuser rl
Access list for backup is
Normal rights:
system:authuser k
system:anyuser rl
Access list for home is
Normal rights:
rsw rlidwka
Access list for mail is
Normal rights:
admin:postmaster rlidwka
rsw rlidwk
Access list for pub is
Normal rights:
system:anyuser rl
rsw rlidwka
So to summarize a bit, the /:/homesdir/r/s/rsw directory structure is easy
for a user to pick up on, and it is easy to code (user[0]/user[1]/user).
If you have additional administrative boundries, use obvious names, like
"procurement, engineering, enee, math, chem...." that users will understand.
/u{0-N} is not user friendly. Even if a newly hired EE secretary forgets
a faculty members username, they stand a chance of finding it in:
/:/home/enee/faculty/.
If you want to get fancy, use an automounter to maintain the links.
The bottom of our amd.conf file looks like the following. It is intended to
make life easy for the user, and consistant across a large environment.
##############################################################################
# Individual Mount Point Definitions
[ /data ]
map_name = hesiod.data
[ /group ]
map_name = hesiod.group
[ /home ]
map_name = hesiod.home
[ /homes ]
map_name = hesiod.homes
[ /mail ]
map_name = hesiod.mail
[ /pub ]
map_name = hesiod.pub
[ /users ]
map_name = hesiod.users
[ /scratch ]
map_name = hesiod.scratch
[ /software ]
map_name = hesiod.software
[ /src ]
map_name = hesiod.src
