%
% $Header: root.tex,v 1.2 88/08/10 22:17:26 raeburn Exp $
% $Source: /mit/raeburn/re/RCS/root.tex,v $
% $Locker:  $
%
\documentstyle[twoside,supertab]{report}

% Underscore frobbing.
\newcommand{\underscore}{{\tt \char"5F}}
\catcode`_=\active \def_{\underscore} % use \sb for subscript

% Caret frobbing.
\catcode`^=\active \def^{\^{ }}

\newcommand{\arrow}{$\rightarrow$}
\newcommand{\file}[1]{{\tt #1}}

\begin{document}

\renewcommand{\thesection}{\arabic{section}}
\addtocounter{page}{-1}

\title{A Proposal For Reducing the Size of the Root File System on
Public Workstations}
\author{Ken Raeburn}
\date{Draft B: 24 July 1988}
\maketitle

\newcommand\dollar{\$}

\sloppy

\addtolength{\parskip}{2ex}

\newcount\numcol
\newcount\maxcol
\newcommand{\nextfrep}{%
	& \ifnum\numcol=\maxcol \nextline \global\numcol=0 %
	\fi%
	\global\advance\numcol by 1 \tt }
\newenvironment{multicol}[1]{
	\global\numcol=#1
	\global\maxcol=\numcol%
	\begin{supertabular}{llllllll}%
	\nextfrep}{\end{supertabular}}

\section{Introduction}

This proposal is aimed towards determining precisely which files and
programs must remain on the local disk of the public workstation.
Some of this proposal is taken from electronic mail sent by Win Treese
on the matter; other contributions have come from discussion with Mike
Shanzer.  Some comments on the earlier draft of this document have
been incorporated.  The list of files at the end of this document
should be nearly complete.

This document is {\em not} oriented towards private workstations,
although it is intended that they use the public configuration as a
starting base.

It is also not intended to be The Definitive List of files for any
release.  In its final form it will serve as a guideline for setting
up the root of the 6.0C release, but for various reasons the
correspondence will not be exact.

Some proposed general criteria used for selection of files needed on
the workstation root partition:

\begin{enumerate}

\item Programs used in the normal boot process before the network and
remote packs are available must be on the root.  The machine must be
able to boot and activate normally.

\item Programs needed for minimal network debugging are needed on the
root.

\item File-system maintenance programs that are not normally used in
the boot process need not be on the root, if the machine can be
manually brought up to use network services.

\item Server programs (for file service, remote logins, ``finger'',
{\it etc.}) are not needed on the root of public workstations.
Private workstations must be customized by their maintainers.

\item Oft-used programs for which residence on the root would make a
significant difference at relatively low cost should be on the root.

\end{enumerate}

These criteria are based in part on the following observations:

\begin{enumerate}

\item We usually have too much on the root on the RT/PC, and
occasionally too much for the VAX.

\item The typical operational procedure when a public workstation
fails is to re-install it, not to attempt to diagnose and fix the
problem.  Nevertheless, it must be possible to perform some amount of
debugging sufficient to determine the cause of loss of network
connectivity; beyond that, debugging software may be provided via
remote file service.

\item The less we have on the root, the faster and easier
installations and updates can occur.  Indeed, one can imagine a fairly
significant release that only requires changing the RVD packs.  (If
the kernel, executables, and configuration files on the root don't
change, the workstation need not be touched in order to effect the
update.)

\end{enumerate}

Private workstations pose a problem with this strategy.  While the
general issue should be addressed, the following provisions for
simplifying maintenance of private workstations at least permit the
current level of operability:

\begin{enumerate}

\item The ``track'' statistics file stored on the RVD will list all
data relating to files in the \file{bin}, \file{dev}, \file{etc}, and
\file{lib} directories.  Maintainers of private workstations may copy
and modify the subscription list that determines which files on the
server are imported as files and which are accessed via links, and
therefore may keep any files local that they please.  (This list
should in general also specify that the subscription list should not
be tracked from the RVD.)  The subscription list used for public
workstations will specify that the files are not to be imported but
used via links.

\item The installation kits have an option to install a workstation
without destroying the contents of the \file{/site} file system.  Such
a kit therefore allows re-installation of a private workstation
without losing all data on the disk, and hence simplifies the
operational problems.  Furthermore, if the machine's file system is
only slightly damaged, it may only be necessary to be able to boot the
machine and run one or two programs from removable media in order to
make it functional again.

While re-installing or booting from removable media (or from the
network) is not an optimal solution for a private workstation, the
possibility does eliminate the need to keep every possible debugging
tool on the local disk.

\end{enumerate}

Finally, this configuration is not precisely that of server and
timesharing systems, which do require additional files.  Those systems
can probably be treated as differences from the basic public
workstations, however.  The steps necessary to install such systems
from this reduced-root configuration have not been fully examined.

\section{Some details...}

This section contains a few notes about the contents of the root file
system.  

\begin{itemize}

\item \file{/lib} is a symbolic link to \file{/srvd/lib}; nothing in
this directory is critical for the boot path or for debugging.

\item \file{/srvd}, \file{/urvd}, and \file{/mit} are mount points (or
contain them) for file systems accessed via ``attach''; \file{/mnt} is
for general-use temporary mounting.  Having these present saves work
for attach.

\item \file{/usr} is a directory containing only symbolic links.  On
the vax, it currently contains one directory, \file{/usr/rtingres}.
This will be deleted.  No file system known to hesiod contains the
string ``ingres'' in the name or the mount point; if someone has need
of it on his (presumably private?) workstation, he can re-create it.

\item \file{/site/tmp} must exist as a part of the root for use by
programs run before \file{/site} is mounted.  Similarly,
\file{/site/usr/tmp} should also exist as a part of the root file
system, though it also is not likely to get more than minimal use.

\item \file{/tp} will contain standalone diagnostics.  We do not
currently have these available on the workstation, but we have had
requests for their availability.  For the moment, the only file in
this directory will be rqbads, and only on the microvax.  On the RT,
this directory will not exist.

\item Many of the files currently used are not required on the root,
but removing them would require some slight modification of existing
software.  Two examples of this are \file{csh} and \file{grep}.  The
only use of \file{grep} by the deactivated workstation is in parsing
\file{attachtab}, which can be done with \file{awk}.  \file{Awk} is
needed on the root.

\item Several programs, such as \file{csh} and \file{ls}, will be
provided for convenience and efficiency.  This list should be
reviewed at some point.

\item The \file{mkdir} and \file{rmdir} programs can be combined and
optimized for space usage on the RT.  They have similar structure, and
both use {\it printf\/}, which requires linking with floating-point
emulation code, when they could instead use cheaper standard-I/O
routines.

\item \file{attach}, \file{detach}, and \file{nfsid} will become one
program with Rob French's version.

\item The file \file{named.local} will be empty by default.  Since it
is listed in \file{named.boot}, the alternative of removing
\file{named.local} would require demanding that users customizing
\file{named.local} also edit \file{named.boot} and maintain this
across releases.

\item The file \file{/etc/athena/rvd} need not be present if the
functionality of the programs \file{rvdflush} and \file{rvdgetm} is
merged into the \file{rvdclient} program in \file{/bin/athena}.

\item The \file{cut_msgs} script can probably be done away with
completely, since \file{newsyslog} handles the work for which it seems
to have been designed, although in a slightly different manner.

\end{itemize}

\section{Comments from Draft A}

Some of the comments I received, and responses, are as follows.

\begin{itemize}

\item \file{/bin/adb} would be useful to patch kernels.  {\it Not
common usage on public workstations by random users running without
library packs.}

\item \file{mkfs}, \file{newfs}, and \file{disktab} should stick
around to help when cleaning messes.  {\it Operations would probably
re-install.  If you're insistent, you can still get the library packs
if the root file system is reasonably intact.}

\item Having \file{more} would be convenient.  {\it Perhaps for
performance, but not otherwise.  As for use on the console, \file{cat}
and {\tt ^S/^Q} should be sufficient.}

\item The program \file{od} is useful for looking at files with
non-ascii components.  {\it Probably not much more useful than ``cat
-v''.}

\item \file{rcp} would be a more convenient alternative to \file{ftp}.
{\it Only if we add kinit, and provide users with someplace to copy to
or from.  Using \file{ftp} is probably easier.}

\item \file{mt} to recover from \file{tar} problems.  {\it The problem
described was for the RT 4.2 release; 4.3 should have the problem
fixed.}

\item Some parameter which can be monitored with \file{pstat} may be
causing problems with RVD or network access.  {\it Which parameters?
No such comments were received from Operations.}

\item In the event of network failure, \file{fastboot} and
\file{fasthalt} may be desirable.  {\it No.  They only differ from
\file{reboot} and \file{halt} in the actions taken while booting.}

\item What is \file{savephys} for?  {\it It appears to be the same
program as \file{savervd} and \file{zaprvd}; not likely to be
something useful outside of an RVD server.}

\end{itemize}

\section{Listing of root file system contents}

The following pages contain a list of the files on the root in release
5.5T for both VS and RT workstations.  (Thanks to Jay Berkenbilt for
doing most of the work.)  Comments added indicate whether each file
will be on the root or only on the RVD, and whether this is a change
from the current state.

After configuring my own workstations to this format, the root file
system capacities were roughly as follows: VS2: 4M of 7.4M used
(59\%); RT: 6K of 7.4M used (92\%).  Your mileage may vary.

\end{document}
