Sun Managers,
I received an extensive list of responses to my question regarding
diskless vs. dataless environments. The overall consensus is that if
you have local disks on your SUN you should configure your system to do
the swapping locally. This makes good sense. Most responses said to
leave / and /usr on the server and make swap, /tmp, and /var/tmp local.
The reason being that the administration of upgrading was going to be a
nightmare. Everyone who responded had good thing to say and the
following two individuals had some informative thoughts that I wanted to
pass on:
From: Dave Wilmot <dawi@is-rocker.gwl.com>
In response to your request for input, here's my opinion.
I have about 400 Sun4/Sun4c machines on my net. We have expended
a lot of effort to get rid of each and every diskless node. Diskless
nodes are not worth the effort in my opinion. The diskful machines
nodes are not worth the effort in my opinion. The diskful machines
swap locally and don't require that much additional effort if you
manage them properly. Most important... have a floating disk which
has the most recent version of the OS that your company is running.
Clone the disk for each machine you want to setup new or upgrade.
A clone script would look something like this:
cs-picard -102) cat setup.sd1
mount /var
set term=sun
format < part.inp
newfs /dev/rsd0a
newfs /dev/rsd0d
newfs /dev/rsd0e
newfs /dev/rsd0g
fsck -p /dev/sd0a
fsck -p /dev/sd0d
fsck -p /dev/sd0e
fsck -p /dev/sd0g
mount /dev/sd0a /mnt
dump 0f - /dev/rsd1a | (cd /mnt; restore rf -)
rm /mnt/restoresymtable
cd /usr/mdec
installboot -lvt /mnt/boot bootsd /dev/rsd0a
cd /
umount /mnt
mount /dev/sd0d /mnt
dump 0f - /dev/rsd1d | (cd /mnt; restore rf -)
rm /mnt/restoresymtable
cd /
umount /mnt
mount /dev/sd0g /mnt
dump 0f - /dev/rsd1g | (cd /mnt; restore rf -)
rm /mnt/restoresymtable
cd /
umount /mnt
mount /dev/sd0a /mnt
mv /fstab /mnt/etc/fstab
rm /mnt/setup.*
rm /mnt/part*
cs-picard -103)
cs-picard -103) cat part.inp
0
pa
a
0
34/
b
34
200/
d
234
133/
e
0
0
f
0
0
g
367
887/
lab
y
pr
q
q
cs-picard -106)
****************
The cat of part.inp is th einput parameters to the format command for
a particular geometry.
From: liz@isis.cgd.ucar.EDU (Liz Coolbaugh):
I'd like to put in several comments:
1) the dataless setup is working well for us for system adminstration.
1) the dataless setup is working well for us for system adminstration.
However, we'd like to make it easier for users to keep running if a
server goes down. If I were starting from scratch, I'd consider more
of a standalone setup, with /, /usr and swap on each disk, with /usr
being very minimal, and all additional software mounted under /usr/local
from the servers. Then I'd use amd to supply /usr/local. Amd will
allow failover from one server to another so you can supply identical
/usr/local partitions to your clients and if one server goes down, the
other can take over. From a system administration point of view, I
wouldn't try to implement this without first having a script, preferably
in perl, available to clone new clients with a minimum of fuss. We use
this technique for installing dataless workstations and it mostly
works pretty well.
2) If you are going to double the size of your network in terms of
the number of clients, do yourself a favor and avoid the problems I've
had. Plan on dividing your network in to subnets right now. I'd
look at the Etherswitch for a neat way to give yourself adequate
bandwidth. You didn't mention your network configuration, so if you've
already got this covered, disregard the above comment. :-)
In summary, our servers are supporting easily a lot more dataless
clients than they would diskless, so I think the direction you are
moving is a good one. The disadvantages are the need to automate tasks
more to keep all the desktop systems the same and the fact that
dataless systems are still dependent on a single server.
Liz Coolbaugh
cool@ncar.ucar.edu
Thanks to the rest of the respondants:
ebumfr@ebu.ericsson.se (Mike Rembis 6259)
eeimkey@eeiua.ericsson.se (Martin Kelly)
<mcgrew@dartagnan.rutgers.edu>
era@niwot.scd.ucar.EDU (Ed Arnold)
adb@albert.bu.edu (Adam Bryant)
Jim Guyton <guyton@condor.rand.org>
david@msri.org (David Mostardi)
wolfgang%sunspot.nosc.mil@nosc.mil
Robert Willett <independent.uucp!rob>
jallen@nersc.gov (John Allen)
Sheryl Coppenger <sheryl@seas.gwu.edu>
kevinmac@ll.mit.edu (Kevin McElearney)
mdl@cypress.com (J. Matt Landrum)
danny@ews7.dseg.ti.com
Gustavo Vegas <gustavo@davinci.concordia.ca>
mlg@cstp.umkc.edu (Meg Grice)
Steve Elst.uk>
Steve Elliott <se@computing.lancaster.ac.uk>
Gregory Higgins <higgins@math.niu.edu>
Torsten.Lif@eos.ericsson.se
bernards@ECN.NL (Marcel Bernards)
"Anthony A. Datri" <datri@concave.convex.com>
Kathy Holle <holle@asc.slb.com>
jc@raven.bu.edu (James Cameron)
matt@wbst845e.xerox.com (Matt Goheen)
Chris Keane <chris@rufus.state.COM.AU>
justice@dao.nrc.ca (Gerald Justice)
paul@dcs.edinburgh.ac.uk
hul@dcs.edinburgh.ac.uk
paul@dcs.edinburgh.ac.uk
hlr@lems.brown.edu (Henry Robinson)
Bill Evans <evans@c4west.eds.com>
Once again, thanks for the input!
Curt
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:47 CDT