The Unix Daemons

Several software daemons are used to maintain the experimental system. These are described in more detail below. Note that the unix daemons run with the user identifier ``wanda'' and must be started as user wanda. If you do not have access to the wanda password, you cannot start the unix daemons.

The Modified Trader

The trader is based on the Ansa 3.1 trader, with an extended interface which allows it to be used as a general purpose database. Each host in the wanda world has an entry in the trader. This describes the properties of the host in terms of its physical devices etc, and specifies several properties which are used by other Unix daemons to boot, reset, and gather console output from the machine. The entries common to all hosts are:

• Aliases: A list of strings which are alternative names for the host
• BootFrom: This field indicates whether the machine uses serial line booting or mop booting, either of which require special action on the part of xwcons.
• BootTime: The time that the host was last booted.
• BootTimes: The number of times that the machine has been booted.
• CPU: Information regarding the CPU in the host.
• Console: Information for the use of a console program such as xscons or xwcons, which states which console line the host uses, and what protocol to use when connecting to it. For example, an entry ``tel:maidenhead9-r'' means ``use telnet to contact the telnet service on maidenhead9-r''.
• DFile: The default kernel file which should be booted into the machine when it is not being used for experimental research.
• DHost: The default hostinfo (environment variables etc) to supply to the host when it boots, when not being used for user research.
• InterfaceId: This field is inserted by the trader, and is a unique identifier for the trader entry for this host. Consult the Ansa manual for details on interface references. This field should not be modified under any circumstances. See the manual page for tco, tci for further details.
• MSNL: The primary msnl interface identifier for the host.
• MSNLAliases: Addresses of additional msnl interfaces for the host.
• MachType: The type of machine e.g. Fairisle-Switch.
• Memory: The amount of memory the host has.
• Name: The primary name of the host.
• NetName: The name of the host as used in the network - frequently the same as Name.
• Peripherals: A list of any peripheral devices attached to the host.
• ResetRelay: For all hosts attached to the reset server, this is the reset relay number which is attached to the host. The reset server uses the reset relay for the host to hard reset the host when it crashes and cannot be restarted in software.
• Type: The type of interface (entry) which this entry represents in the trader. For all wanda hosts this has the value ``MachInfo''.
• UFile: The user specified boot kernel for the host. Used only if the host is currently locked by an xscons or xwcons session.
• UHost: The user specified hostinfo supplied to the machine when it boots.
• WConsId: This is the interface reference of the console program which is currently or which last locked this host and connected to the console output device. It is used by xscons, xwcons and the boot server.

Applications which use the trader

Several application programs use trader as a database. These include:

• xwcons: A console program which displays the output a wanda machine in a window on the X display. It presents the user with an interface which allows the user to log and scroll through the console output, reset the machine, and view many of the trader entries for the machine. When xwcons starts it locks the trader entry for the host by filling in the field `` WConsId'' with its own interface reference which is also exported to the trader. This ``locks'' the machine for the exclusive use of the person running xwcons, and ensures that when the machine boots it will use the ``UFile'' and ``UHost'' entries for the boot kernel.
• xscons: A console program for a Fairisle switch. This is very similar to xwcons, except that it uses the switch size to determine how many console windows to create. There is one window per port on the Fairisle switch. Xscons allows the user to soft reset and hard reset the switch. Soft resets are done using the wreset mechanism (see below). Hard resets make use of the reset server and the reset relay for the switch. Note that hard resets of a Fairisle switch reset all ports on that switch.
• bootset: This application modifies the ``UFile'' and ``UHost'' entries for the host, or the `DFile'' and ``DHost'' entries if the appropriate command line option is given. Note that the default boot entries are set by the system managers to sensible values. Modifying these is strongly discouraged.
• bootinfo: This application retrieves the booting information for the host, including the number of times that the boot server has booted the host since the kernel entry was modified. It also prints the last boot time of the host.
• wwho: Lists all known xscons and xwcons sessions in existence.
• wcheck: Allows the user to check that a specified xscons or xwcons session is still active.
• wunlock: Removes the lock on a particular host. This is useful when the xscons or xwcons session has been killed without removing its interface reference from the trader.
• wreset: Allows the user to reset, either in software, or by physically resetting a host.
• tco and tci: These are applications which provide a friendly interface to the trader. Manual pages are available, and the user should take special note of the ``BUGS'' section!

The Boot Server

The boot server listens for boot requests from wanda machines. It listens for these requests at a well known address (consult the msnl services document for details). When a wanda machine or Fairisle port boots, it contacts the boot server whose msnl address is given to it in a rarp reply message by a rarp daemon. When it receives a boot request the boot server queries the trader to find out which kernel should be booted into the machine. If the machine is currently locked (i.e. somebody has an xscons or xwcons session on the machine) then the user booting information is used. Otherwise the default booting information is used. The boot server creates an image from the supplied kernel and hostinfo, and sends it to the booting machine using the boot protocol. Once the machine has loaded its new image, it begins to execute the new kernel.

The Grim Reaper

The Grim Reaper is an Ansa 3.1 service which removes old or out of date entries from the trader when the processes owning the interface references exported to the trader and the notification service are killed or exit. For details of this service see the Ansa manual.

The Request Server

The request server provides a Unix file service to the Ansa clients on Wanda. It has been largely replaced by the Wanda Dumb File System.

MSNL Internet Daemon

The MSNL Internet Daemon is a unix daemon which responds to msnl connection requests for the msnl echo and msnl tracing facilities, mecho and mtrace. It provides a mechanism for testing the connectivity of the msnl network and the routes used to reach a particular host through the network. For more information see the manual page.

MSNL Name service

The msnl name service is used to resolve name queries of the style of gethostbyname(3n), for msnl addresses. For both unix and wanda, library functions called getmsnlhostbyname() and getmsnlhostbyaddr() (see the man pages) are available to enable application programs to resolve name queries. The name service uses the trader for some of its information, and queries the DNS for other information. See the msnl name service document elsewhere in this collection.

Wanda Dumb File System

The wanda dumb file system and wanda dumb directory service provide access to the unix file space from wanda machines. The interface to these services is the standard BSD file interface, and the underlying communication mechanism is a RPC protocol which uses msrpc to read and write blocks of a file. This service currently operates with msrpc rather than msrpc2. This should be modified in the near future.

Starting the Unix Daemons

At the time of writing, the unix daemons are started by a script which currently resides in
/usr/groups/wanda/info/unixdaemons . This script must be executed as user wanda, and on the designated wanda service machine. Currently the default services run on the machine aspall, although many Fairisle switches boot from experimental boot services on other machines. This is likely to change in the near future, when the service machine aspall is upgraded to run the new MSNL code. At that time the wanda daemons will (should) get started automatically when the machine boots.