Architecture

Overall, Layered Athena will look a lot like mkserv in terms of how it works. Layered Athena will be distributed as a filesystem very similar to a regular Athena system pack, with an added directory of configuration files and programs to implement Layered Athena. There will be a simple command line based client which does all of the work, handling installations, removals, and updates. Both a graphical user interface and an friendly ASCII interface will be written as a front-ends for the simple client, but will not duplicate the actual guts of the code.

There are two different kinds of things to be done: set options and manipulate subsets. The options affect how and when subsets are loaded, immediate configuration changes of the workstation, and the eventual functioning of the subsets once they are running. The options are:

• Handling of updates--whether to auto-update when a newer version is available, or just to send an email notification that an update is needed
• Who to notify about system maintenance, such as the availability of new versions
• When the last message requesting an update was sent to the workstation owner mentioned above. This is necessary so that they do not get messages once an hour.
• If the owner has acknowledged notification of an update request, and does not want to receive further notices about this particular version (they will start again anyway when the next release is available).
• Whether to allow monitoring of the workstation configuration via SNMP
• Where an additional copy of the configuration information is stored. A local file is always maintained, but a remote copy may also be kept up-to-date.
• If this workstation is centrally registered--should I/S be informed in an automated manner about configuration changes of this workstation?
• Local customization scripts: the workstation may have customizations to the standard Athena software

For each subset, several options are recorded:

• Subset status: ignored, use it remotely, copy it local
• Version: what version is currently loaded

These settings are stored in a configuration file on the local disk. This is a flat ascii file with a format similar to that described below for subset configuration. This file will be placed in a ``Layered Athena directory'', such as /var/athena although it will be different for different vendor operating systems. Any other state that must be remembered is also kept in files in this directory.

The graphical client has dialogs to set each of these options. The standard client implements them by registering and storing the configuration if requested, copying any necessary files to the local disk with synctree, then running scripts to finish the installation and/or customize the subsets. Eventually mkserv options should be supported and run during an update as well, but this will not be attempted for the first phase. Mkserv must fail gracefully if attempted on a Layered Athena workstation.

Some subsets and configurations require boot-time support. This is handled by an rc.athena script. This script handles the initial activation of the workstation. A reactivate script also needs to be run occasionally. This will be done hourly through cron, and the script will check to see if anyone is logged in before doing anything disruptive. Reactivation of a private workstation consists of checking for any needed updates, changing the attached system pack if the hesiod information changes, updating AFS cell configuration, detaching lockers attached by users no longer logged in, and resetting zephyr locations for logged out users. If the workstation is running the Athena login program, then password and group file cleanup must be performed as well.

 
• Communication