NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/sys/sgi/13639

Internet Message Format | 1992-09-14 | 7.3 KB

Path: sparky!uunet!europa.asd.contel.com!darwin.sura.net!spool.mu.edu!uwm.edu!ogicse!news.u.washington.edu!milton!dittrich
From: [e-mail] (Dave Dittrich)
Newsgroups: comp.sys.sgi
Subject: DiskPOOR rather than diskless client setup (inst question)
Message-ID: <dittrich.716516292@milton>
Date: 15 Sep 92 00:18:12 GMT
Article-I.D.: milton.dittrich.716516292
Sender: [e-mail] (USENET News System)
Organization: University of Washington
Lines: 112

We have a lab facility with 20 SGI Indigos and a 4D/35.  The 4D/35 is
set up as an NFS/NIS server, and the Indigos are all mounting portions
of the 1.2GB internal disk for utility software (e.g. GNU stuff) and all
of an external 1.6GB disk for user files.  I want these workstations to
all look the same to users, but to have them tuned for either software
development or interactive use.

Since the Indigos were all purchased with the smaller 236MB disk drives,
once IRIX and several software products are loaded on these machines
there is very little space left.  We also have a third party software
product that suggests a repartitioning of the disk drive to increase
swap space to 100MB.  These two demands have exhausted disk space and
preclude any more software (such as Code Vision, Explorer) being
installed on the Indigos.

Thus my problem is as follows:  without adding extra disk space to the
Indigos I would like to have some of IRIX and other SGI products be
installed on the server to be used via NFS and the rest to be installed
locally.  I want to do this in such a manner that the Indigo does not
have to be on the network to run the basic operating system (some of them
are moved on occasion to be used in classrooms or lecture halls and I
simply tar the desired programs into a temporary directory on the Indigo
which is booted after a "chkconfig network off" and enabling of the
guest account), but if it is on the network I want all of the products
available on the server (e.g.  the development option, FORTRAN, Code Vision)
to be accessible.  Then as we add more products that are not very high
demand, we can just put them on the server and run them from there.

When I pose this question often the first response is, "why don't you
just set the Indigos up as diskless hosts?"  As diskless hosts I would
be forced to have all software installed on the server and NFS mounted
over the net.  This would result in poor performance on the workstations
and higher network load.  The remaining space on the Indigos would also
be wasted since running diskless means that only swap space is local
(is this right? -- I'm not a diskless workstation guru).

The next response is, "why not just buy bigger disks?"  With 20 machines,
the cost of increasing available disk space to accommodate everything
would be in the $20,000 to $30,000 range; too much money.  I could
easily justify adding another 1.6GB or 2.0GB disk to the server to
accommodate more NFS exported software, but not to duplicate these same
products on each Indigo.  Short of adding disk space I would have to
further restrict what is installed, making the machines more and more
unique and thus less widely usable and more costly to administer (just
having to have backups becomes a nightmare when you get more than two or
three different configurations--with only one or two basic
configurations I can just upgrade and clone 1 or two machines and do disk
to disk copies to upgrade the remaining machines).

My initial concept of a solution to this problem would be to mount a
complete file system from the server that has all of the software that
we are licensed for installed on it.  We would then chose those products
that we wish to be installed on a minimal system (e.g. IRIX, X/GL, the
development option on a few machines, Explorer on a few others, etc.)
and remotely mount the remainder of the authorized software.  This lets
me tune the performance more (development machines should compile code
quicker, machines that run third party molecular modeling software
should do that quicker, etc.) and still make each machine "look" the
same to all users (no special $PATH entries, no special .cshrc/.profile
additions, a small number of consistent NFS mount points).

The easy way to accomplish this task would be to have a complete
distribution available via NFS and for every product that is not mounted
locally have its constituent files be links in the standard places
(e.g., /usr/bin, /usr/lib) that point to the NFS mounted complete tree.
This is a hybrid variation of the diskless workstation theme--diskPOOR
would be a better term.

I have looked at the way that inst and clinst are used in a diskless
environment and it appears that this is in fact what inst does, but it
does it all on the server assuming that the entire file system will be
mounted from a COMPLETELY diskless host.  What would seem reasonable to
me (as a user, of course, not a vendor) would be for this same mechanism
to be used for configurations where some of the products are installed
locally on the workstation and others are installed remotely on a server.

From what I can tell, doing a clinst on the server does indeed produce
links from the share tree (the complete distribution I want to set up)
into the client tree (the same file system structure I desire on each
client, only this one is on the server instead).  My guess is that I MAY
be able to invert the logic of how to use clinst/inst to create the
share tree on the server, mount it on the Indigo and set up a link to
make it look like it is a share tree on the Indigo, make a link from the
client tree on the Indigo that points to the "standard places," and
then just do a client install for those products that I wish to have
remotely mounted rather than locally installed.

If I haven't made any gross logical errors (which is quite likely, since
I'm only a human :-) I *THINK* this might work.  I would prefer that SGI
provide a simple way to just create the links for me in the manner I
desire, but since only now are large lab environments like ours becoming
a feasibility I image I am on the "bleeding edge" of this kind of
requirement.  (In fact, several VMS lovers in the department have told
me that what I want to do is "no problemo" with a VAXcluster and is
exactly what the Local Area VAXcluster was designed to do -- what a
great selling point, SGI, to have the same functionality available with
IRIX! [hint, hint] I sure don't want to go back to VMS just to get it :-)

If anyone has any suggestions/warnings/etc.  I would be glad to hear
them.  Like I said, I think this kind of configuration will become more
and more prevalent as UNIX workstations decrease in price.  I can
guarantee you that dollars for systems administrators like myself are
not increasing at the same rate, so the administrative overhead will become
a large barrier to increased sales of UNIX workstations unless they can
be made easier to setup and administer in large numbers.  (I have already
heard lots of hot air coming out of Redmond WA about simplified system
administration features of NT/LANman.  Quite frankly I will not waste my
time debating a know problem vs. a non-existent solution, but I do
understand why the hype is flowing so heavily.)  I don't see much rapid
progress towards OSF/1 and DCE/DME either, although I would prefer this
kind of standard solution to a proprietary one such as VAXcluster or
[the premature, not-quite-ready-for-Beta] NT/LANman.