comp.unix.admin.large

[Rusty Wright]

I manage a fileserver (tuna) that exports directories to our campus.
Anybody on campus can nfs mount its disks and use the stuff on it;
public domain software and site-licensed stuff.  One of the primary
constraints I have to work within is that people may have their own
copy of what I have on tuna so it can't conflict or require special
installation gyrations.  Also, people need to be able to "test drive"
what's on tuna easily.  These are goals that aren't always met; for
example, as someone pointed out, stuff that uses shared libraries
throws a monkey wrench into the works.

Tuna is soon to be upgraded to a faster and more capacious server and
I've been thinking about reorganizing how things are laid out.
Currently the arrangement is fairly convenient for users but causes me
problems.  Each exported filesystem is named /tuna_a, /tuna_b,
/tuna_c, etc.  tuna_a contains only Sun 3 binaries and tuna_e contains
only Sun 4.  I also want to support DECstations on the new tuna.  I'm
currently using the "separate bin, man, lib, and so on directories for
each package" scheme; e.g.  /tuna_a/tex82/bin, /tuna_a/x11r4/bin, etc.
The main hassle I have with this setup is that it doesn't give me any
flexibility when there are space problems; i.e., I'd like to be able
to move the tex stuff to a different partition but tuna_e is only Sun
4 and tuna_a is only Sun 3.  It also doesn't allow me to update stuff
that only works with a new version of the OS; for example; tuna_e
started out being compiled under SunOS 4.0.3 and when I needed to
start compiling stuff under SunOS 4.1 I had to give everyone several
weeks advance notice.

The scheme I'm planning on implementing is somewhat similar to the
Depot scheme, but the first paper where I read about a similar scheme
was a paper by Shing and Ni from Michigan State University given at
the Sun User Group conference this winter in San Jose.  I greatly
prefer the MSU scheme over the Depot scheme.  Depot is overly complex
for my tastes and one of my major complaints with the Depot is that
you can't test drive any of the software without mounting everything
just so (I found the thing where you mount the arch.arch-os directory
on the empty arch directory particularly irksome and unnecessarily
arcane).  I currently have the restriction that tuna_a must be mounted
as /tuna_a, and likewise for /tuna_e.  The other problem is that for
any shared libraries the clients must make links pointing to them in
/usr/local/lib.  So there are restrictions, but I think I've reduced
them pretty well.

In the MSU scheme you have directories on the server like

	/tuna_a/x11r4/bin/sun3
	/tuna_a/x11r4/lib/sun3
	/tuna_a/x11r4/bin/sun4
	/tuna_a/x11r4/lib/sun4
	/tuna_b/x11r4/bin/pmax
	/tuna_b/x11r4/lib/pmax
	/tuna_a/x11r4/include
	/tuna_a/x11r4/man

I prefer the Depot method of putting the architecture directory first;

	/tuna_a/x11r4/arch.sun3-os3/bin
	/tuna_a/x11r4/arch.sun3-os3/lib
	/tuna_a/x11r4/arch.sun4-os4/bin
	/tuna_a/x11r4/arch.sun4-os4/lib
	/tuna_b/x11r4/arch.pmax-os4/bin
	/tuna_b/x11r4/arch.pmax-os4/lib
	/tuna_a/x11r4/include
	/tuna_a/x11r4/man

But I'm going to leave the "arch." out of the directory name; e.g.,
just sun3, not arch.sun3.  But I will have the os as part of the name
so that I can support different/incompatible os versions;

	/tuna_a/x11r4/sun3_os3.5/bin
	/tuna_a/x11r4/sun3_os3.5/lib
	/tuna_a/x11r4/sun3_os4.1/bin
	/tuna_a/x11r4/sun3_os4.1/lib
	/tuna_a/x11r4/sun4_os4.1/bin
	/tuna_a/x11r4/sun4_os4.1/lib
	/tuna_b/x11r4/pmax_os4.1/bin
	/tuna_b/x11r4/pmax_os4.1/lib

I'm probably also going to push things down one level and have all of
the tuna mounts in a /tuna directory;

	/tuna/a/x11r4/sun3_os3.5/bin
	/tuna/a/x11r4/sun3_os3.5/lib
	/tuna/a/x11r4/sun3_os4.1/bin
	/tuna/a/x11r4/sun3_os4.1/lib
	/tuna/a/x11r4/sun4_os4.1/bin
	/tuna/a/x11r4/sun4_os4.1/lib
	/tuna/b/x11r4/pmax_os4.1/bin
	/tuna/b/x11r4/pmax_os4.1/lib

Having things mounted in the root creates some problems when you use
the automounter.

So, with the above scheme, as before, the clients will have to mount
the tuna directories in the right place and make the symbolic links in
/usr/local/lib for any shared libraries and then they can test drive
and use the software.

Another idea that the MSU and Depot schemes bring up is making it
fairly transparent to the user.  One of the problems with my current
setup is that you have /tuna_e/<whatever>/bin in your path when you're
on a Sun 4 and /tuna_a/<whatever>/bin when you're on a Sun 3; I like
to be able to use the same .cshrc file on all of my accounts.  What I
will do is, similar to the MSU scheme, provide a shell script that
makes a bunch of symbolic links.  It will attempt to determine the
client's architecture and then link the appropriate directories.  The
links will be made in /tuna_0:

	/tuna_0/x11r4/bin	-> /tuna/a/x11r4/sun4_os4.1/bin
	/tuna_0/x11r4/lib	-> /tuna/a/x11r4/sun4_os4.1/lib
	/tuna_0/x11r4/man	-> /tuna/a/x11r4/man
	/tuna_0/x11r4/include	-> /tuna/a/x11r4/include

One of the main places I diverge from MSU scheme is putting the
symbolic links in /usr/local.  Lots of departments and groups here
have their own /usr/local and I have no control over how they've set
up their systems and I don't want my stuff interferring with their
stuff.  The biggest wart is the symbolic links for the shared
libraries.  At least you can use ldconfig to specify additional
directories, but I'd really like to be able to embed in the programs
(applications) the location where to try first for the shared
libraries.

I have to say that I found David Curry's scheme pretty wacky;
subdirectories in /usr/local/bin?  And manual pages in /usr/man/manl?!
Is that copies of the man pages or symbolic links?  And how in the
world do you keep track of manual pages that need to be removed when a
command has been decomissioned or renamed due to a new release of the
software package?  And what about software packages that have
libraries (i.e., man pages that would go in man3)?  Having separate
man trees for each package works nicely with the Sun man command and
the MANPATH environment variable.  Too bad DEC doesn't support it.