remote install of 4.1.1
remote machines (without cd-drives). It took me this long to reasonably
test everything and to stop adding features.
In this document, I'll try to
describe everything I did. It does look long and it did take me
a while to implement, but the result is definitely worth it. You
will want to modify the scripts for your own setup.
But first a quick summary:
We have 3 cd-drives and about 150 machines on campus. The main
idea is to have the cd-drives centraly located and have all the other
machines use them remotely but (and this is the catch) without having
to go through the hassle of setting up diskless clients all over the place.
I also tried to preserve security whenever I could and took advantage
of the fact that suninstall was running under the control of my
script to include all the security fix I know about, to fix up
rc*, to put in DNS, dynamically linked mount and rcp and so on.
At the time I installed 4.1.1 on my machine, I added (using suninstall)
4 diskless clients, one per architecture, called epflsun3, epflsun3x, ...
I then copied a few files over from the miniroot (among which suninstall :-)
over to my /export hierarchy. When we want to bring up a machine to 4.1.1,
I run a script on my machine setting bootparams, permissions and so on:
about 60 seconds in all and the remote machine can then boot diskless from
mine. Once booted, no need to copy the miniroot, just run suninstall et
voila!
In fact, suninstall can be run remotely since we are running multi-user
and since the cd-drive can accomodate more than one user, we are
not limited to upgrading one machine at a time.
We still haven't received our official tapes and documentation of 4.1.1,
so the following was done without any documentation.
This document and assorted scripts and tar files can be found
by anonymous ftp on the machine ltisun.epfl.ch (128.178.119.94) under
the install.4.1.1.Z. I describe each part of my "distribution" at
the end of this document and in the file README.
I'll be updating the copy on ltisun as improvements are made
and eventually submit to whole package to comp.sys.sun to be archived.
Quick description of normal installation
The whole process resolves on the need to boot from somewhere
else than the local disks because they need to be overwritten. Originally
this meant boot from tape, copy miniroot to swap partition and boot
from miniroot using only the swap partition. Then came machines
without local tapes so we couldn't boot from the tape anymore. The
answer: make this machine a diskless client of another one (with tape),
boot diskless and then copy the miniroot and so on.
Then came cd's, just do the same as tapes. But cd's can't
be copied as tapes could be, they are now a scarce resource.
The fact that we have less cd-drives than streamers doesn't even
come into play since we have far less OS cd's that cd-drives!
But what Sun hasn't seem
to realize (if I'm not missing anything) is that once a machine
is booted diskless, why bother using the miniroot: the disks are
already available for suninstall! So this is what I do: run suninstall
from regular vmunix.
This paper is fairly long since it represents about 1 or 2 days
of work for the site administrator; not counting the time to run
suninstall on your boot server. In all, this paper represents about
two weeks of trial and errors but it sure simplifies upgrading all
the other machines.
Initial setup of bootserver: /export partition
The first step and the one that takes the most time for the administrator
of the site is to set up a central boot server on which all the other
machines will be able to boot. To do this you need to add to it
one diskless client per architecture that you have on your site. This
is easily done at the time the boot server is itself brought up to 4.1.1.
Choose the names of those pseudo clients carefully. Especially if
you would like to use my scripts as they are since they depend
on the name having for suffix `arch -k`.
Remember not to set the shell of root to sh: see description of
bug in previous e-mail to sun-managers. The path of root MUST
include /usr/etc, on all machines whose cd-rom drive you will
be wanting to use, which isn't the case for an rsh if the shell of
root is sh but is the case if you use csh and the .cshrc is setup
appropriately.
Suninstall needs / and /usr to be rw (for root of course)
at run-time. So to upgrade more than one client
of one architecture at the same time, you will need an individual
/etc/install per client. This is done at install time by
my install script in practice you need an individual /etc, my
script just nfs mounts a "private" copy over /etc.
Swap files are created on the fly by my setup script.
I know that suninstall writes the list of available architectures under
/usr/etc/install/tar (grrr, why there?) and it also writes under
/usr/share/lib/zoneinfo. Since
presumably all your machines have the same time zone, sharing this
shouldn't be a factor. And since you will be reading all from the
same cd, the available architectures (/usr/etc/install/tar/avail_arches)
will always be the same.
This setup (one client per architecture) takes 62MBytes on my
/export partition including about 2,8MBytes per root. To that
you will need to add 4MBytes of swap for each client which are
being installed simultaneously (Yes, 4MBytes is enough regardless
of actual memory in client).
We'll come back to the missing files (ex: suninstall) later, now
I have to describe the diskless boot process and how my scripts work.
Installation scripts
A diskless boot (ex: b le(,3940)) follows the following steps
rarp broadcast to find internet address for client, needs to have
a rarpd running on local ethernet
tftp request to get boot program, this can cross routers since it
uses its internet address combined with the value
I gave it (3940->.57.64). My boot server then downloads
the boot program.
rarp broadcast (again)
broadcast Pmap for a bootparamd which has to be on the local ethernet:
it responds to use root and swap mount from my boot server.
rarp broadcast (again)
mountd request to nfs mount / and swap from the boot server.
So we need a responder machine on the local ethernet that
will respond to the arp requests and to the boot param request. This is
done automatically by my script add_client_local.
CAVEAT: SparcStation 2's don't use the "old" b xx() syntax
anymore; while all other sun4c's do, they are broken in the sense
that the numbers you give it are ignored. My scripts take this into account.
add_boot_client
This script is run on the boot server and does the following
things:
1- find out if the client is on the same ethernet, if
yes: run add_client_local
2- setup /tftpboot for this client iff not a sun4c
3- create a swap file for this client
4- setup /etc/exports
5- enable permissions so that the client can access a cd-drive
6- (if needed) e-mail administrator of client to tell him
to run add_client_local with appropriate parameters.
add_client_local
If the boot server is on the same local ethernet as the client,
add_boot_client has already ran this script. Otherwise,
you will need a third machine: the responder on the same local
ethernet as the client. You will have to run add_client_local
on the responder (the client has to be alive at the time).
It does the following things:
1- adds the machine to /etc/ethers
2- adds the machine to /etc/bootparams
3- starts rarpd and rpc.bootparamd
4- setup /tftpboot for this client iff it is a sun4c
Filling in the missing files in /export
Sun has conveniently left out a few files under /usr/etc/install,
among which we find suninstall and get_software_info. You will
have to copy them over from the miniroot or you can use the
/usr/etc/install that I made available. At least
we don't have to worry about sun3x and sun4c since they seem to
be using the same binaries as sun3 and sun4 (tested for sun4c).
If you choose to use my distribution, then:
cd /export/exec/sun4.sunos.4.1.1/etc
mv install install.sun
tar xf /usr/share/install.4.1.1.tar usr.sun4.install
mv usr.sun4.install install
cd /export/exec/sun3.sunos.4.1.1/etc
mv install install.sun
tar xf /usr/share/install.4.1.1.tar usr.sun3.install
mv usr.sun3.install install
Otherwise boot one station of each architecture (sun3 and sun4) using
the miniroot. If you don't have a local cd-drive on the client,
run both scripts above for this machine, mount the cd-rom
on the boot server:
mount -t hsfs -r /dev/sr0 /cdrom
# copy the miniroot to disk (where it will be visible to the clients)
cp /cdrom/export/exec/kvm/sun3.sunos.4.1.1/miniroot_sun3 /export/exec/kvm/sun3.sunos4.1.1
cp /cdrom/export/exec/kvm/sun4.sunos.4.1.1/miniroot_sun3 /export/exec/kvm/sun4.sunos4.1.1
umount /dev/sr0 # to prevent suninstall from choking later on.
For each station (one sun3 and one sun4):
b le(,xxxx) -s xxxx: last one (two) internet numbers in hex of
boot server
# cd /usr/kvm
# dd if=miniroot_sun3 bs=63k of=/dev/rsd0b
# sync
# sync
# halt
> b le(,xxxx)-asw
4.2
sd0b
vmunix
4.2
sd0b
spec
sd0b
y
# Now, we are booted on the miniroot, and we want to keep a few files:
this is how I have done it, looking back, I assume I could just have
created a tar file instead of creating the directory on the local disk.
mkdir /mnt
mount /dev/sd0a /mnt # save them on disk
cd /usr/etc
tar cf - install | ( cd /mnt ; tar xfB - )
mv /mnt/install /mnt/usr.install
cp /etc/install/label_script /mnt # I think there was a problem with
# label_script, but I don't remember
# what it was. It probably is that
# only one of the version worked, either the vmunix one (probable) or the miniroot one.
# A simple trial run will tell you, it is used in getting the software information
# I have included it in the /usr/share/local/install.4.1.1.tar in my distribution.
########### For sun3's REMOVE all the symbolic links under /mnt/usr.install,
########### they seem to bother vmunix quite a bit: "file" would tell me
########### that it is a strange file; trying to remove one of
########### them under vmunix would crash the machine leaving the file
########### system in a sorry state. (Backups can be so good for moral :-).
cd /mnt/usr.install
rm -f list_files re-preinstall show_diskette sys-config
L1-A
Now go on your boot server, mount via nfs that root partition
with our missing files. For the sun4 binaries:
cd /export/exec/sun4.sunos.4.1.1/etc
mv install install.sun
copy with tar the miniroot install.
For sun3's, it looks like it isn't as simple, there seems
to be some incompatibility between the programs in the miniroot
and the ones for vmunix. You will have to mix and match, the
tar file I provided works for me and according to a diff, between
directories, the following is what I have done:
cd /export/exec/sun3.sunos.4.1.1/etc
tar cf - install | ( cd .. ; tar xfB - )
mv ../install install.sun
cd COPY_of_miniroot_install
cp add_user config_host easyinstall extract_files get_disk_info get_host_info get_sec_info install.bin installation run_configure suninstall sys-unconfig /export/exec/sun3.sunos.4.1.1/etc/install
(I was sure that I had to copy get_software_info from the
miniroot, check to see if it is present in the vmunix directory. Let
me know if it isn't, I'll add it to this list).
Now we are almost done, next you need to run a script very similar
to the following:
sh
cp cg6reg.h /export/exec/sun3/include/sundev/ # missing from 4.1.1
cp cg6reg.h /export/exec/sun4/include/sundev/ # available from tar file
cd /export/root
for dir in epfl* ; do
cd $dir
mkdir a
touch .MINIROOT # YES you need this!!!
for i in 0 1 2 3 4 ; do
./MAKEDEV xd$i
./MAKEDEV xy$i
./MAKEDEV sd$i
done
for i in 000 001 002 003 004 ; do
./MAKEDEV id$i
done
case $dir in
epflsun3 )
touch .cshrc .login .rhosts .forward
cd etc
mv install _install # To allow sharing of root
mkdir install # between more than one client
cd .. ; continue
;;
esac
rm -f .cshrc .login .rhosts .forward
ln ../epflsun3/.[a-z]* .
cd etc
mv install _install # for lo mount to allow multiple machines
mkdir install # to use same root at the same time
rm -f passwd rc* hosts inetd.conf
ln ..http://epflsun3/etc/passwd ..http://epflsun3/rc ..http://epflsun3/rc.boot ..http://epflsun3/rc.single ..http://epflsun3/rc.local .
cd install
rm -f default_sys_info
ln /epflsun3/etc/install/default_sys_info .
cd ..http://..
done
Now, configure passwd, .cshrc and so on as appropriate. Make sure
/usr/etc will always be in the path (.cshrc). Your boot server
will have to be in the .rhosts and you may as well setup the .forward.
I made the /etc/rc* as small as possible and provide them in the
tar file.
In default_sys_info, you can define a few things for your site.
You will have to create files called
/export/root/*/etc/install/release which should contain the string
generated by:
`arch`.`arch -k`.sunos.4.1.1
You may also want to remove the miniroots you copied from the cd,
they are big (> 7MBytes).
perl_install_4.1.1
I also included a perl script and its subroutines in the tar
file. It bothered me that strangers could boot up their machine
on mine, log in as root (to run suninstall) and they had rw
access to my /usr. So I decided to create an account called
install which would start suninstall. After suninstall is run,
the .rhosts of the machine holding the cd-drive is cleaned up,
the manager is put into a shell after a chroot to its own disks
is done and after all this, the machine is rebooted single user:
not once has the foreign manager access to my files!
The script has grown quite a bit since: > 450 lines! It not only
runs suninstall but also:
# setup the DNS
# cp the needed file to /etc
# cp the new libc with the resolver routines
# setup the mail
# cp the sendmail.cf to /etc
# use the MX sendmail
# rc.boot
# Fix broadcast mask -> ifconfig
# rc.local
# remove all ifconfig
# Add screenblank
# remplace in.routed with a default route
# Fix one security bug
# use the dynamic linked mount for nfs and static for the other mounts
# Comment out keyserv and rpc.ypupdated : they are only needed for
# secure nfs.
# Uncomment out ypxfrd for NIS master.
# rc
# put sbin in the path ahead of /usr/bin to pickup the static linked mount# hosts
# remove entries copied over from boot server /etc/hosts
# remove loghost reference: we added it to /etc/localhost.rev:
# loghost.epfl.ch. IN A 127.0.0.1
# hosts.equiv
# remove +, in fact just remove the whole file
# inetd.conf
# Add entry for tfs and the calendar manager
# magic put in the one updated for the file manager
# filetype for the file manager
# /usr/include/sundev/cg6reg.h : was forgotten in the 4.1.1 distribution,
# use the copy from 4.1
# Fix security bug with login, rpc.yppasswdd, rpc.pwauthd
# Fix security bug in kernel
# Fix security bug with /usr/bin/mail
This is done also for any diskless clients, at the end
ypinit -m is run if the client is a master NIS. And so on, check it
out for yourselves, the files are called:
perl_install_4.1.1 login shell for account install
extract_client_boot_4.1.1 extract information about diskless clients
configure_client_boot_4.1.1 configure machines as described above.
For now, I haven't done anything special for slave servers.
For individual description of the scripts, check the README file
included and CHECK each script individually. Especially the
configure_client_boot_4.1.1 script since you might not wish to do
a lot of what it does (like the sendmail setup for example).
Also included are the files for the security patches and
a dynamically linked rcp and mount (from 4.0.3, but they work).
Alain Brossard, Ecole Polytechnique Federale de Lausanne,
SIC/SII, EL-Ecublens, CH-1015 Lausanne, Suisse
----- End Included Message -----
