By user12625760 on Sep 27, 2004
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:
on81 / -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 information.
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