Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!ucsd!ucbvax!agate!agate!rusty From: rusty@belch.Berkeley.EDU (Rusty Wright) Newsgroups: comp.unix.admin Subject: Re: comp.unix.admin.large Message-ID: Date: 3 Jan 91 23:54:56 GMT References: <609@synopsys.COM> Sender: usenet@agate.berkeley.edu (USENET Administrator) Followup-To: comp.unix.admin Organization: University of California Berkeley Lines: 131 In-Reply-To: barnett@grymoire.crd.ge.com's message of 28 Dec 90 12:22:11 GMT 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//bin in your path when you're on a Sun 4 and /tuna_a//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.