karen@umbc3.umbc.edu (Karen Petraska-Veum) (12/15/90)
I have 4 DS3100s, one acting as a server and the other three diskless, presently running Ultrix 3.1. I'm getting ready to upgrade them to Ultrix 4.1, and due to disk space constraints, I'm considering setting up the diskless clients so that the /usr they mount is the server's /usr, not the /dlenv0/root0.mips/usr. (this is the way that the diskless Sun's are set up). I've read through the Ultrix 4.0 documentation (i haven't seen any new manuals yet for Ultrix 4.1, other than release notes) and this scenario is not mentioned, therefore I assume that DEC does not support this configuration. Is anyone out there doing this? I remember hearing discussion somewhere (maybe here) a while back that people were annoyed about having to spend the disk space for what is essentially two complete usr's. Can anyone give me any good reasons why I should, or more importantly, should NOT do this? What is really screwing me up is that I will have to put all of Ultrix/SQL, and some compilers on the systems once I upgrade, and putting those products on twice will really require alot of space. I'd appreciate any input. Thanks, Karen Petraska-Veum, Systems karen@umbc3.umbc.edu
davecb@yunexus.YorkU.CA (David Collier-Brown) (12/16/90)
karen@umbc3.umbc.edu (Karen Petraska-Veum) writes: | I have 4 DS3100s, one acting as a server and the other three diskless, | presently running Ultrix 3.1. I'm getting ready to upgrade them to Ultrix | 4.1, and due to disk space constraints, I'm considering setting up the | diskless clients so that the /usr they mount is the server's /usr, not the | /dlenv0/root0.mips/usr. (this is the way that the diskless Sun's are set | up). We did this once, as an experiment, just before going to diskfull clients. It seemed to work, but we had some probably unrelated problems with 3.1c and didn't try it on our main lab (40 2100s, 4 servers). For sanity's sake we put all the to-be-shared applications in the client /usr (/dlenv0) and put symlinks in from the server /usr. If anything was going to be licenced on the server only, we would have put in in the server /usr only, and vice versa. If circumstances permitted, I'd have tried it on one of the servers, but we chickened out due to time pressures: we needed the system up for last september. --dave [ps: anyone else out there with diskless 2100/3100's: we have some serious performance problems and are working madly with dec to get them speeded up for January] -- David Collier-Brown, | davecb@Nexus.YorkU.CA, ...!yunexus!davecb or 72 Abitibi Ave., | {toronto area...}lethe!dave or just Willowdale, Ontario, | postmaster@{nexus.}yorku.ca CANADA. 416-223-8968 | work phone (416) 736-5257 x 22075
cks@hawkwind.utcs.toronto.edu (Chris Siebenmann) (12/18/90)
Just as another datapoint, I've always run diskless clients with /usr
imported from the server /usr and not from <whatever path it is this
release>/dlenv?/usr. You have to make sure you have a real /var
(either by doing an advanced install when you set up your system or by
some tar'ing afterwards). We don't have any licensed software that
can't run on the clients, so I haven't had to worry about that. You
can even set it up so the clients have a root filesystem but get /usr
off the server, although this requires editing your client
/etc/rc.local's up a bit and making a few programs be really there
instead of symlinks.
Another cute thing you can do to save disk space if you have
multiple clients of the same architecture is hardlink all the
executables together (heck, you can do this for almost all the files
in their root areas). The disk space savings are noticable.
I've never understood why DEC does so many stupid things with their
diskless client setup and associated programs, although I've heard a
vague rumour that dms is being completely overhauled soon (about
time). For one thing, I'd love a non-interactive version; stick all
the data into a file, run a program, the client is set up; almost all
the time I have a batch of clients who differ only in Ethernet # and
hostname to set up. Maybe someday I'll reverse-engineer the dms
script(s) and see what the hell they really do.
--
"The Law of Software Development and Envelopment at MIT:
Every program in development at MIT expands until it can read mail."
- greg@math.berkeley.edu
cks@hawkwind.utcs.toronto.edu ...!{utgpu,utzoo,watmath}!utgpu!cks