SUMMARY: proposed local directory scheme

From: Mark Bergman (bergman@phri.nyu.edu)
Date: Tue May 07 1996 - 15:06:23 CDT


I got a surprising number of responses on my query about
re-organizing my NFS and local disks. My original propoasl
was:
-----------------------------------------------------------------
  I'm contemplating a re-organization of the NFS and local disks on our
  network, and I wanted your collective responses.

  Like most places, we have software available on each machine
  that falls into one of three categories:
          system software
                  it came with the OS, and has a well-defined location
                  whether on a disk that's attatched to the machine or
                  NFS mounted.
          local enterprise-wide software
                  not part of the OS, but available on every
                  machine: GNU stuff, local tools, etc.
          really local-local software
                  local to a particular machine--news/mail server,
                  licensed software, admin tools on a non-user machine, etc.

  I'm envisioning installing the system software locally on each diskfull
  machine.

  The "local enterprise-wide" stuff would be stored on a central server,
  and NFS mounted to /usr/local on each client.

  The really local-local software would be kept in directories like:
          /usr/$hostname/bin
          /usr/$hostname/sbin
          /usr/$hostname/lib
          /usr/$hostname/etc
          /usr/$hostname/src
          (etc. as needed)

  There would be lines in the system /etc/.login such as:
          HOST=`$hostname`
          set path = ( $path /usr/$hostname/bin )
  to ensure that users get the correct local software.
-----------------------------------------------------------------

Thaks to:
            davem@cp.tybrin.com (Dave McFerren)
            js@cctechnol.com (Johnie Stafford)
            Kevin.Sheehan@uniq.com.au (Kevin Sheehan {Consulting Poster Child})
            Henry Katz <hkatz@panix.com>
            Glenn.Satchell@Uniq.com.au (Glenn Satchell - Uniq Professional Services)
            keith@oz.health.state.mn.us (Keith M Willenson)
            norton@nrlmry.navy.mil
            iwa@stars1.hanscom.af.mil (Marc Gibian)
            Michael Covington <covingto@msmary.edu>

A number of people mentioned automounter or suggested that I simply
come up with a name for the "local-local" directory, rather than
relying on the host name. I'm not going to use automounter right now,
but I think I'm going to go with:

        enterprise-wide-local-stuff from the server mounted
        on /usr/shared/{bin,lib,man,etc,...} on each client

        use /usr/local/{bin,lib,man,etc,...} on each client
        for software purely local to that machine.

-----------------------------------------------------------------
Notable responses:

From: iwa@stars1.hanscom.af.mil (Marc Gibian)
I would also note that commercial layered products, stuff you appear
to catagorize as system software is not as well thought out as you
seem to assert. I find myself having to juggle even the base OS stuff
around a bit due to dumb decisions made for me during system
installation time. A convention I use is to automount layered product
stuff and even a lot of the public domain stuff (not that we, on an
Air Force base run any of the latter) on the mount point:

/project/*

I then use the automounter with indirect tables to mount everything. I
try to favor placing things in the /project area over the /usr/share
area. I then provide standard initialization files that the users use
to setup their environments to match the way things are placed on
their systems.

From: norton@nrlmry.navy.mil
Yes - overly complex (at least for me). You might want to check out
Depot from CMU at:

http://andrew2.andrew.cmu.edu
        [ I looked. depot looks too complex for us! --MB]

From: Glenn.Satchell@Uniq.com.au (Glenn Satchell - Uniq Professional Services)
Why not set up your NFS/automounter so that local-local stuff is
automounted to appear under /usr/local as well, but only on those
systems that need it? That way the path doesn't get overly complicated,
eg in the automounts get certain stuff locally before going to the
network wide /usr/local automount map:

        [Automount map example deleted]

My personal preference is to never put installed stuff in /usr unless
it is part of a Solaris 2 package. This makes upgrades and re-installs
much easier.

From: Henry Katz <hkatz@panix.com>
Presumably you are doing this on some SunOS boxes. My only suggestion is
that unless you specifically need to identify the origin of an NFS
mount within its directory path you go on to the automount naming
style under solaris: that of simply putting all non-system software
under /opt. Here the auto_opt automount map would look like:

key1 serverA:/local/0/opt/dirA
key2 serverB:/local/2/opt/dirB

where the mount points on each server are at /local/[0-9]. Using this
scheme you have much finer granularity - on a per application level
rather than at the set of apps residing on a server.

The automaster is simply:

...
/opt auto_opt
...

If you want to have local apps put them on a mount point using the
loopback file system (amd is better suited here even on 4.1.4) on

/myopt auto_myopt

with the same auto_myopt map with the servers all being localhost.

From: Kevin.Sheehan@uniq.com.au (Kevin Sheehan {Consulting Poster Child})
Hal Stern has an excellent discussion of this problem in NFS&NIS.
>
> The "local enterprise-wide" stuff would be stored on a central server,
> and NFS mounted to /usr/local on each client.

You probably want more than one copy if it read-only, just in case
the central server goes down...

You probably don't want to put things in /usr, it means modifying
the installed OS quite a bit. I'd suggest putting it in /usr/local
as packages (like /usr/local/frame) instead of tying it to hostnames.
Then you can use the automounter to get the correct version. It
also means you can have more standard paths, and that you don't
build huge NFS search paths, which can be expensive to search.

----
Mark Bergman                       bergman@phri.nyu.edu
System and Network Administrator   212-578-0822
Public Health Research Institute   Rm. 1074, 455 1st Ave, NY NY, 10016



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:10:59 CDT