My original query:
Now that Autoclient is not supported in Solaris 8, I'm wondering
how sites with 100's (or 1000's) of Sun workstations are
If you have been using some other strategy I would like to hear about it.
If you have been using AutoClient and have decided how to deal
with Solaris 8, I would also like to hear about it.
First, my apology for the long delay in my posting this summary.
The replies from this list are easy to summarize. I was simultaneously
trying to get more info from Sun, and that took the time.
The only real alternative to Autoclient is Jumpstart. I got several
replies describing approaches to automating it. The most detailed was from
Birger.Wathne@getronics.no, and I've attached his note.
Our own systems group looked at Jumpstart and still don't consider
it an adequate substitute. Jumpstart doesn't really address keeping
patches up to date. You also lose the ability to swap hardware at
a moments notice ( a full Jumpstart with patches takes much of an hour).
Now here is what I learned from Sun. This info is informal and should
be taken with a grain of salt.
1) Autoclient 2.X will remain unsupported in Solaris 8.
2) Sun is planning a new feature for a future version of Solaris
called Jumpstart Flash. It adds some features of Autoclient to Jumpstart.
What features, I don't know.
3) Sun is planning to port Autoclient 3.0 to Solaris 8 as a transition
aid until Jumpstart Flash is available.
How firm 2) and 3) are is not clear. I was told that neither is committed
I guess I should say a little about Autoclient 3.0. This was a redesign
of 2.X done by a Sun support group in Ireland. It was meant to be in limited
distribution to certain contract customers. We saw it during its beta
for Solaris 7. I don't really know who is eligible to get it. First we
were told that it would not be ported to Solaris 8. Now we are hearing
(as above) that they are considering a port to Solaris 8 as a transition.
Our own systems group has decided to stick with Solaris 7 for another
6 months and see what really materializes. I can't say that I'm very
impressed with how Sun has handled this. We have had to at times delay
OS upgrades because of third party products. This is the first time we
have been delayed by Sun internal software.
Ken Mandelberg | firstname.lastname@example.org
Emory University |
Dept of Math and CS | Phone: Voice (404) 727-7963
Atlanta, GA 30322 | FAX (404) 727-5611
Date: Fri, 9 Jun 2000 10:21:03 +0200 (MET DST)
From: Birger Wathne <Birger.Wathne@getronics.no>
To: Ken Mandelberg <email@example.com>
Subject: Re: 100's of Suns without Autoclient?
We used to run autoclients, but due to political reasons we were forced to
'do things the same way as other departments' (i.e. local installation of
the OS on all workstations). Some people were afraid we would run into
problems with vendor support for 3rd party software if we didn't run a
'standard' local OS install.
So instead, I have created a JumpStart config. In many ways, this is even
easier than autoclient. You have to patch on each client, but you don't
have to worry about compatibility issues when patching the common usr
area, etc. I also remember some problems with certain patches when
applying them to autoclient environments.
We never upgrade workstations. We always do a fresh install, as
workstations should be 100% standardized. Doing a full jumpstart where
patches are applied automatically after the first reboot (we have not
toyed with prepatching the install area) takes about 1 hour. It's
completely hands-off, and includes OS, OpenGL, ADSM client software,
sendmail, etc, etc. Ideally, there should be no need to do backups of
these workstations (after all, we do full reinstalls, right?), but we just
know that some day some workstation will crash, and we will discover that
some department had some software locally installed.
Here is how I do it:
Under jumpstart, I have a few subdirs. 'files', 'profiles', 'finish' and
'profiles' is used to hold various profiles. I have separate profiles for
each disk size for standard workstations, as well as specialized profiles
for print spoolers, etc.
'finish' holds the finish scripts where all of the work is done. I have a
handfull of different scripts (workstation, xdm-server, spool-server,
etc) that set a few variables and then source appropriate files in a
subdir called 'include'. I have one file for all common config for all
hosts, one file for diskfull, one for diskless (we still have 2 of them),
and a bunch of small files for patching, installation of software
'files' holds files used by the finish scripts (config files, stuff to
install in /etc/init.d, etc).
'sysidcfg' currently has 2 subdirs, one for workstations and one for
servers where the only difference is that the server sysidcfg file sets
the terminal type to vt100.
I also have a script at the top level that asks for any neccesary info
(hostname, mac address, kernel architecture and console terminal
(graphical/tty) and then runs add_install_client with all those nice
We have a well-structured netgroup hierarchy, so my finish/include/common
script deduces what it needs from the netgroup membership for the host. To
add a new host I just have to enter it into DNS and NIS netgroup, run my
script, and jumpstart boot it. To initiate a jumpstart on a host that is
up and running, use
/etc/reboot -- "net - install"
Just ask if you want more...
Senior Systems Consultant
Getronics Norge AS (+47) 55 98 28 00 (switchboard)
Postboks 154 Kokstad (+47) 55 98 28 06 (direct)
N-5863 Bergen, Norway (+47) 55 98 28 80 (fax)
U BEFORE POSTING please READ the FAQ located at
. and the list POLICY statement located at
A To submit questions/summaries to this list send your email message to:
A To unsubscribe from this list please send an email message to:
E and in the BODY type:
R unsubscribe sun-managers
. unsubscribe sun-managers firstname.lastname@example.org
L To view an archive of this list please visit:
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:14:13 CDT