Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!uunet!olivea!orc!inews!quasar!kseshadr From: kseshadr@quasar.intel.com (Kishore Seshadri) Newsgroups: comp.unix.admin Subject: Re: comp.unix.admin.large Message-ID: <1573@inews.intel.com> Date: 3 Jan 91 17:57:38 GMT References: <609@synopsys.COM> <1990Dec28.173354.1738@erg.sri.com> Sender: news@inews.intel.com Reply-To: kseshadr@quasar.UUCP (Kishore Seshadri) Organization: Intel Corporation, Santa Clara, California Lines: 56 In article <1990Dec28.173354.1738@erg.sri.com> davy@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) 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) Intel Corporation <..!intelca!mipos3!kseshadr> "For a successful technology, reality must take precedence over public