comp.unix.admin.large

[Kishore Seshadri]

In article <1990Dec28.173354.1738 at erg.sri.com> davy at erg.sri.com writes:
>
>Why complicate matters?  I saw the paper presented at LISA.  Sure, it's an
>interesting idea, and I don't want to disparage others' work.  But the whole
>time I was listening, the thought kept running through my mind:  "Why on
>earth would you ever want to confuse your life like this?"
>
I wholeheartedly second this. As someone who manages public domain tools
for a network of 500 workstations, I would strongly recommend keeping things
simple.

A few general guidelines:

Keep your directory trees shallow (if thats the right word..). Complexity
in the naming scheme can turn into a nightmare, especially in groups that
see a high turnover of system managers, or groups that have a large number
of superusers (yes, strangely enough, this does happen).

Use a consistent naming scheme for the various architectures and os's. Being
logical in this helps..

Identify systems (for each os/architecture combination) to be used as
master systems for testing and distributing new software. Then make sure
everyone sticks to these. 

Spending a little more for disk space is worth it if managing all the different
/usr/locals is greatly simplified. This is especially true for large networks 
as the cost can be amortized over many clients.

Avoid having mount points on NFS filesystems. This can be a real pain..

The hysteresis principle- resist change! Your user community should have to
handle as few changes as possible. Ease of transition to a new structure should
be a dominant factor in any changes recommended. For example, requiring changes
to everbody's .login or .cshrc, when you have 700 users can prove to be
somewhat problematic.

Use something like rdist or coda for keeping /usr/locals consistent across
servers.

Ideally each machine should only be able to see the /usr/local stuff that is 
specific to its os and architecture. This may not be possible if many of
your users are developers...


At all costs avoid a complicated setup that looks elegant on paper.

----------------------------------------------------------------------------
Kishore Seshadri,(speaking for myself)       <kseshadr at mipos3.intel.com>
Intel Corporation                            <..!intelca!mipos3!kseshadr>
"For a successful technology, reality must take precedence over public
 relations, for Nature cannot be fooled." -Richard Feynmann
----------------------------------------------------------------------------
Kishore Seshadri,(speaking for myself)       <kseshadr at mipos3.intel.com>
Intel Corporation                            <..!intelca!mipos3!kseshadr>
"For a successful technology, reality must take precedence over public