My first introduction to the automounter was when it arrived as
part of NSE in the days of SunOS 3.5 it was always kind of neat, but
with the advent of autofs it was ready for some real abuse.
From contacts with the development team and comments in bug
reports it is now clear that it was never intended that you could do
some of the things that you can do with the automounter, and parts of
this certainly fall into that category.
One of the problems with sustaining Solaris is that you have to
have a build system for each architecture and release you are
sustaining. Needless to say this either leads to you having to
install a build system each time or have some form of multi boot or
have lots of systems.
We used to opt of the lots of systems but that meant that they
were relatively small and so builds would take a long time. Plus they
each sat idle for long periods of time.
Reinventing the wheel
To solve this we built 2 systems, one SPARC and one x86 onto which
we restored all the root images of our build servers in a sub
directory such that we could chroot into the directories and build
any release. Neat and for the most part it worked very well. Only
recently did I discover from a colleague that this was the same as
one of the original uses for chroot.
Dr. Marshall Kirk Mckusick, private communication:
``According to the SCCS logs, the chroot call was added by Bill Joy
on March 18, 1982 approximately 1.5 years before 4.2BSD was released.
That was well before we had ftp servers of any sort (ftp did not show
up in the source tree until January 1983). My best guess as to its
purpose was to allow Bill to chroot into the /4.2BSD build directory
and build a system using only the files, include files, etc contained
in that tree. That was the only use of chroot that I remember from
the early days.''
This all relies on the interface between the kernel and libc not
changing for the system calls used in the build, which fortunately
for SunOS 5.6 to 5.9 is the case. However for 5.10 we have had to
build new systems, but hey we still only have 4 build systems instead
of 10. This allows those systems to be really powerful and hence our
builds take less time.
Once all this was done we realised that it would be nice to have
our home directories and other mount points available under the
chroots, so we loopback mounted the /home autofs mount point from the
real root, then there were other mount points so we started, but did
not get far with, building a /etc/vfstab file that would do this. The
revelation was when we used the automounter
to mount the chroot areas. We use it to mount all the files and
directories from the real root file system to get things working.
Lets look at the automounter map entry for 5.9:
/ -suid,ro cpr-bld.uk:/export/d10/roots/&/$CPU
/devices -fstype=lofs,rw /devices
/dev -fstype=lofs,rw /dev
/etc/passwd -fstype=lofs,ro /etc/passwd
/etc/shadow -fstype=lofs,ro /etc/shadow
/share -fstype=lofs /share
/home -fstype=lofs /home
/vol -fstype=lofs /vol
/usr/dist -fstype=lofs /usr/dist
/var/tmp -fstype=lofs /var/tmp
/var/nis -fstype=lofs,ro /var/nis
/var/run -fstype=lofs /var/run
/var/adm/utmpx -fstype=lofs,ro /var/adm/utmpx
/var/spool/mqueue -fstype=lofs /var/spool/mqueue
/tmp -fstype=lofs /tmp
/export -fstype=lofs /export
/local -fstype=lofs,ro /local
/local/root -fstype=lofs,ro /
/opt/cprbld -ro cpr-bld.uk:/export/d10/roots/cprhome/$CPU
/ws -fstype=lofs /ws
/net -fstype=lofs /net
/usr/local -fstype=lofs /usr/local
/proc -fstype=lofs /proc
/opt/SUNWspro -fstype=lofs,ro /share/on81-patch-tools/SUNWspro/SC6.1
/opt/teamware -fstype=lofs,ro /share/on81-patch-tools/teamware
/opt/onbld -fstype=lofs,ro /share/on81-patch-tools/onbld
/etc/mnttab -fstype=lofs,ro /etc/mnttab
/var/spool/clientmqueue -fstype=lofs,rw /var/spool/clientmqueue
/share/SUNWspro_latest -fstype=lofs /share/eu/lang/solaris/$CPU/links_perOS/latest_5.9/SUNWspro
/share/SUNWspro_prefcs -fstype=lofs /share/eu/lang/solaris/$CPU/links_perOS/prefcs_5.9/SUNWspro
Now you can see we are automounting all sorts of things that you may
not expect. In particular /etc/passwd and /etc/shadow so that we get
the same password entries as the host system. In our world /home and
/share are automount points, but for since the automounter runs in
the real root automount maps that contain $OSROOT to select a
particular OS specific mount point get the wrong entry when in the
chroot. Hence we have the two entries that are in green.
The one thing that does not work is
/etc/mnttab, since unlike the mnttab
used in zones it has no knowledge of the chroot so gives bogus
Does it work? Yes, well enough for our old build systems to be
consigned back to the lab for general use and us to be allowed to
have some fast ones with lots of CPUs for our real systems.
For those Sun Employees who wish to know more see http://pod6.uk