Import moira repository

In preparation for using the Moira git repo as a remote, import the
moira repository.  This is an ugly commit, primarily because this also
switched Moira from Svn to Git, and the RCSID tags no longer get
populated, so literally every file has changed.

README.md

@@ -0,0 +1 @@
+The Moira service management system.  See moira/README for build instructions.

VERSION

@@ -1 +1 @@
-4.0.0.1.0
+4.0.0.2

doc/Makefile

@@ -0,0 +1,25 @@
+SHELL=/bin/sh
+
+.SUFFIXES: .ps .dvi .tex
+
+.tex.ps:
+	latex $<
+	@rm -f $*.log $*.aux
+	dvips -o $@ $*.dvi
+	@rm -f $*.dvi
+
+all: dcm.ps manual.ps queries.ps
+
+manual.ps: /mit/consult/lib/tex/macros/psbox.sty
+	@echo latex $<
+	@env TEXINPUTS=/mit/consult/lib/tex/macros: latex $<
+	@env TEXINPUTS=/mit/consult/lib/tex/macros: latex $<
+	@rm -f $*.log $*.aux $*.toc $*.idx
+	dvips -o $@ $*.dvi
+	@rm -f $*.dvi
+
+/mit/consult/lib/tex/macros/psbox.sty:
+	attach -h -n consult
+
+clean:
+	rm -f *.ps *.dvi *.aux *.idx *.log *.toc

doc/dcm.tex

@@ -0,0 +1,132 @@
+\documentclass{article}
+\usepackage{fullpage}
+\begin{document}
+\begin{center}
+{\Large The DCM}
+\end{center}
+
+The Data Control Manager, or DCM, is the part of Moira that keeps all
+of the system servers updated with current data from the Moira
+database. It is run by the cron daemon at some time when the database
+is not busy. Its operation may be controlled external to Moira by the
+presence of {\it /etc/nodcm}, or through Moira by the value of {\bf
+dcm\_enable} in the database.
+
+\section{Options}
+
+In normal operation, the DCM will be invoked by {\it startdcm}, which
+redirects all logging to {\it /moira/dcm.log}. When invoked by {\it
+startdcm}, the DCM checks all services.
+
+Alternately, services can be specified on the command line, in which
+case, only those services will be checked.
+
+\section{Operation}
+
+If started with no services specified on the command line, the DCM
+first checks for the existence of {\it /etc/nodcm}; if this file
+exists, it exits. Next it connects to the database and retrieves the
+value of {\bf dcm\_enable} from the values relation of the database; if
+this value is zero, it will also exit.
+
+It then scans each of the services which:
+
+\begin{itemize}
+\item are {\it enable\/}d
+\item do not have {\it hard\_error\/}s
+\item the {\it update\_interval\/} is non-zero
+\item {\it /moirabin/{\bf service}.gen\/} exists
+\end{itemize}
+
+It first compares {\it dfcheck\/} and the {\it update\_interval\/}
+against the current time. If it is time for an update, it will run
+{\it /moira/bin/{\bf service}.gen}, instructing it to produce {\it
+/moira/dcm/{\bf service}.out}. If this finishes without error, {\it
+dfgen} and {\it dfcheck} are updated to the current time. If it exits
+indicating that nothing has changed, only {\it dfcheck} is updated to
+the current time. If there is a soft error (an expected error that
+might go away if we try again) then the {\it error\_message} is
+updated to reflect this, and nothing else is changed. If there is a
+hard error, {\it hard\_error} and {\it error\_message} are set, and a
+Zephyr message is sent to class {\bf MOIRA} instance {\bf DCM}.
+
+For each of the services which pass the 4 checks above, regardless of
+the result of attempting to build data files, or even if it was not
+time to build data files, the hosts will be scanned. The DCM forks off
+a separate process to deal with scanning the hosts and propagating the
+data to them. (The original DCM process continues scanning the
+services.) The hosts are scanned to find those which:
+
+\begin{itemize}
+\item are {\it enable\/}d
+
+\item do not have {\it hosterror\/}s
+
+\item have not been successfully updated since the data files were generated
+\end{itemize}
+
+For each of these hosts, an update is attempted. First, the data files
+are sent to all of the updatable hosts. If it fails to update any
+host, it sets the {\it hosterrmsg\/} and {\it ltt\/} (last time tried)
+for that host, plus {\it hosterror\/} if a hard error occurred. If the
+service is of {\it type\/} {\bf UNIQUE} or {\bf DISTRIB}uted, the DCM
+will then continue trying to send the data files to the remaining
+hosts. If it is of {\it type\/} {\bf REPLICAT}ed, it will stop there.
+
+After sucessfully sending the data files to all of the hosts (or to
+some subset for a {\bf UNIQUE} or {\bf DISTRIB}uted service), the DCM
+will attempt to send and run the service {\it script\/} on each host
+that received the new data. If it succeeds, it will update the {\it
+lts\/} (last time successful) flag for the host, and proceed to the
+next. If it fails, it will update {\it hosterrmsg\/} (and, for a hard
+failure, it will set {\it hosterror\/} and send a Zephyr warning).
+
+If an error occurs at any point when updating hosts for a {\bf
+REPLICAT}ed service, the {\it hosterrmsg\/} and {\it hosterror\/}
+values are copied to the service's {\it errmsg\/} and {\it
+harderror}, so that the service will be disabled until the error
+condition is fixed.
+
+
+\section{Files}
+
+The source is primarily in {\it dcm/dcm.pc}. The routines to perform a
+server update are in {\it update/client.c} and associated files in
+that directory.
+
+
+\section{Data File Generators}
+
+There must be one of these for each service that is supported. Each
+generator is an executable program stored in {\it /moira/bin/{\bf
+service}.gen}, where {\bf service} is the service name in lower case.
+For {\bf UNIQUE} and {\bf REPLICAT}ed services, the DCM will invoke
+the generator with one argument, the name of the output file it should
+produce. Most of them will write to standard output if no output file
+is specified, although this is not required. For {\bf DISTRIB}uted
+services, the argument is ignored: they always output files to the
+directory {\it /moira/dcm/{\bf service}\/}: one file for each server
+to be updated.
+
+The generator exit status should be a value from {\em
+$\langle$mr\_et.h$\rangle$}. It must be a value from this set, because
+only the least significant 8 bits of the return code are available to
+the parent process, so the com\_err table identifier is lost. In
+particular, if nothing has changed and the files do not need to be
+re-generated, MR\_NO\_CHANGE is returned.
+
+Each generator is different, although there are some conventions.
+Most of them check the mod-time on the target file, and compare this
+with the mod-times in the tblstats relation in the database for each
+table that affects that file.  This determines if the data files need
+to be regenerated.  Some of the generators produce a tar file
+containing several other files.  These have their working directory
+hard-coded in, usually {\it /moira/dcm/{\bf service}}.  Each file that is
+produced is written to a different name (usually the desired name with
+a twiddle appended), then a rename is performed if the file is
+produced successfully.  In this way, if part of the generation fails,
+whatever is left should be a set of complete files.
+
+The source to the generators lives in the {\it gen\/} directory.
+
+\end{document}

doc/definitions.mss

@@ -0,0 +1,170 @@
+@Device(PostScript)
+
+Here it is necessary to define each of the entities that Moira manages.
+If the definitions are accurate and complete, then the database and
+queries can be designed in terms of these definitions.
+
+@begin(Description)
+
+Person@\A @i(person) is the human behind a particular @i(user) account.
+This person might or might not have an @i(account) at this time.  Each
+person has attributes such as their real name, their ID number, and
+their class (academic year, staff, etc) which will not change or will
+change very infrequently.  The person's real name is not necessarily
+unique, although their ID number is.  This information is usually
+obtained from the registrar.  Only administrators are allowed to
+change this information.  It is considered private, and is not
+publicly available.  Each person also has a version of their name
+that they show to the public, along with their address and phone
+number.  This "finger information" is public, and can be modified by
+that person.
+
+User@\The term @i(user) will refer usually to a @c(unix) account, not to
+the @i(person) using the account.  An account has a @c(unix) login name, a
+UID, a GID, and associated information, and is also a kerberos
+principal.  The login name is initially chosen by the person, and may
+not be changed except by an administrator.  The UID and GID are
+assigned by athena and may not be changed by the user.  The account
+also has a shell and a @i(mail drop) which can be set by the user.  A
+person is associated with most accounts, although a person may have
+more than one account, and an account might not belong to a single
+person.  All account information is publicly available.
+
+Mail Drop@\This is where mail addressed to a particular account is
+sent.  It may be either a post office box, or an SMTP address.  A post
+office box is a drop on a post office server machine.  The box name is
+the same as the user's login name, and the machine must be a
+registered post office.  SMTP addresses are character strings which
+are not parsed by the Service Management System.  They should be mail
+addresses that make sense from the Athena Mail Hub.  This information
+is publicly available.
+
+Machine@\A machine is a host computer on the network.  It may be a
+workstation or a server.  It has a name, one or more addresses, and a
+type such as @b(vax) or @b(rt).  It also belongs to a collection of
+service @i(clusters).  This information is publicly available.
+
+Cluster@\A @i(cluster) is a mapping of @i(machines) to service
+locations.  In general, it corresponds to a group of machines in a
+room.  When a machine requests its @i(cluster) information, it gets
+the @i(cluster data) associated with each of the clusters it is a
+member of.  For example if a room has several vaxen and several rt's,
+then you might need 3 clusters: one that all of the vaxen belong to
+that lists the vax-specific services, another that all of the rt's
+belong to the lists the rt-specific services, and a third that all of
+the workstations in that room belong to that lists all of the common
+services (although you could do this with just two clusters,
+duplicating the common info in the vax & rt -specific clusters).  This
+information is publicly available.
+
+Cluster Data@\Each @i(machine) has a minimum set of services that it
+must be able to locate: @b(SYSLIB, USRLIB, LPR, ZEPHYR, HESIOD), and
+@b(KERBEROS).  These are identified by @b(type), i.e. the service it
+locates, the cluster @b(name), and the name of the specific @b(service
+instance).  This information is publicly available.
+
+Filesystem@\A @i(filesystem) is a reference to all or part of a
+physical filesystem.  There are two kinds of filesystems: @b(nfs) and
+@b(rvd).  An @b(rvd) filesystem exists on a particular @i(machine),
+and has a number of other parameters which are not significant to Moira.
+An @b(nfs) filesystem exists on a registered @i(NFS physical
+filesystem).  A single @i(filesystem) name may correspond to several
+different physical filesystems, ordered in a particular way.  Each
+filesystem has a name that makes sense to the server machine, a mount
+point the client needs, and an access mode.  It may be necessary for a
+structure to be created on the server, for this both an individual
+owner and group owning list are specified.  Each filesystem is of a
+particular type (such as @b(HOMEDIR), @b(PROJECT), or @b(SYSTEM)).
+This information is publicly available.
+
+Locker@\A @i(locker) is a special case of a @i(filesystem).  Its name
+is also a username.  It is of type @b(nfs), and has a mount point of
+"/mit/@i(name)", an owner of @i(name), an owning group of @i(name)'s
+@i(user group), and a locker-type of @b(HOMEDIR).  There is only one
+physical filesystem matching this filesystem.  There is a quota on the
+filesystem.
+
+NFS Physical Filesystem@\This names a disk partition that is exported
+for NFS use.  It is identified by the @i(machine) name and the device
+name of the partition.  It has a particular size and allocation.  It
+also has a status which indicates what types of filesystems may be
+placed on it.  The allocation is the sum of all of the quotas assigned
+to the partition.
+
+Quota@\A @i(quota) is the amount of storage a particular user is
+allowed on a particular filesystem.  If a user is granted quotas on
+two or more filesystems on the same physical filesystem, he will have
+the sum of those two quotas to split between the filesystems.  A user
+without an explicit quota on a filesystem will have a (very small)
+quota assigned.
+
+List@\A list is a collection of @i(users), @i(lists), and character
+strings.  A list has a name, a description, some attributes, and an
+owner in addition to its members.  The owner may be a user or a list.
+If the owner is a list, it may be the same list (self-referential), or
+another list.  The list attributes are @b(active, hidden, public,
+maillist), and @b(group).  If a list is @b(active), it will appear to
+the name servers and mail servers as appropriate, otherwise it cannot
+be used.  A @b(hidden) list's existence should not be known unless the
+person inquiring is an owner.  The list may still be visible from the
+mail server or name server, but the Service Management System will not
+disclose it.  A @b(public) list is one that anyone may add themselves
+to or remove themselves from.  A list may be a @b(maillist),
+indicating that it should be loaded onto the central mail hub so that
+the Athena mail server can use it.  A list may also be a @b(group) and
+have a @c(unix) UID associated with it.  With the exception of @b(public)
+lists, only the list owners may change the membership of a list.  The
+owners may also change the description and the attributes.  This
+information is publicly available.
+
+Maillist@\A maillist is a @i(list) with the @b(maillist) attribute
+set.  If the list is also @b(active), then it will be loaded onto the
+mail hub so that mail sent to the list name will be sent to each of
+the members of the list.  Because of this expansion, each member of
+the list must be a user, a string which is really an SMTP address, or
+another maillist.  So any list which is a member of a maillist must
+itself be a maillist.  @i(User groups) should not be on maillists,
+since a usergroup cannot be distinguished from a reference to the
+actual @i(user).
+
+Group@\A @i(group) is a @i(list) with the @b(group) attribute set and
+a GID assigned.  If the @b(active) attribute is also set, then it will
+be loaded into the hesiod nameserver so that it may be used as a @c(unix)
+user group.
+
+User Group@\A @i(user group) is a @i(list) which is also a @i(group),
+and its name is the same as a username.  Usually the only member is
+that user, and the user is also the owner.  Because there are many
+user groups, and most of them are never used except to feed the
+nameserver, their storage is optimized if they are not referenced by
+another list and do not have any other members.
+
+ACL@\Many entities in the database have @i(Access Control List)s
+associated with them: lists, services, filesystems, zephyr and queries.
+Each ACL has a type field and a name field.  The type may be @b(NONE),
+indicating that no access is to be allowed.  If may be @b(USER), and
+the name will be a login name, indicating that that user will have
+access.  Or it may be @b(LIST) and the name of a list, indicating that
+anyone on that list or any of its sub-lists will have access to the
+entity.
+
+Zephyr class@\A given @i(class) of zephyr message may need access
+control.  There are four different access control lists that are
+needed for each zephyr class: @b(xmt, sub, iws), and @b(iui).  The
+absence of an ACL is different from an empty ACL.
+
+Service@\A service is a software system that gets updated by Moira, for
+example @b(HESIOD) or @b(NFS).  There are many pieces of data
+necessary to keep track of the correct and efficient updating of these
+services.  There may be a few items that are service specific that
+need to be remembered for each instance of that service.
+
+Printer@\There are lots of things you might want to know about a
+printer, but we don't have a queuing system to make use of them.  So
+for now, Moira only manages printcap entries for the nameserver.
+
+Aliases@\Alternate names for @i(filesystems) and @i(services) are
+remembered as aliases.  When the nameserver is loaded, these aliases
+are loaded as additional names for these objects.
+
+@end(description)