\makeindex
\documentclass{book}
\usepackage{fancyheadings}
\usepackage{psbox}
%timrom
\marginparwidth 0pt
\oddsidemargin  .5in
\evensidemargin  0pt
\marginparsep 0pt
\topmargin   0pt
\textwidth   6in
\textheight  8in
\pagestyle{fancy}
\begin{document}
\newcommand{\athena}{\PSbox{tech-plan/owl.PS hscale=0.1 vscale=0.1}{7pt}{7pt}}
%\newcommand{\athena}{\fbox{\footnotesize Athena}}
\title{Moira User's Manual}
\author{Mark Rosenstein}

\begin{titlepage}
\vspace{1 in}
\PSbox{tech-plan/owl.PS}{1in}{1in} \hfill
\raisebox{30pt}{\begin{tabular}{r}
{\large \sc MIT Distributed Computing and Network Services}\\[.1in]
{\large \sc The Athena Computing Environment}\\
\end{tabular}}

\vspace*{2.5in}
\hfill {\Huge \bf Moira User's and\\[.25in]
\hspace*{\fill} Administrator's Manual}\\

\vspace*{2in}
{\LARGE \hfill Mark Rosenstein\\[.25in] 
\hspace*{\fill} \today\\}
\end{titlepage}
\cfoot{}
\setlength{\headrulewidth}{0pt}
\setcounter{page}{2}
\renewcommand{\thepage}{\roman{page}}

\vspace*{3in}
\copyright\ Copyright 1991, 1993 by the Massachusetts Institute of Technology

Permission to use, copy, modify, and distribute this
software and its documentation for any purpose and without
fee is hereby granted, provided that the above copyright
notice appear in all copies and that both that copyright
notice and this permission notice appear in supporting
documentation, and that the name of M.I.T. not be used in
advertising or publicity pertaining to distribution of the
software without specific, written prior permission.
M.I.T. makes no representations about the suitability of
this software for any purpose.  It is provided ``as is''
without express or implied warranty.

Project Athena, Athena, Athena MUSE, Discuss, Hesiod, Kerberos, Moira,
and Zephyr are registered trademarks of the Massachusetts Institute of
Technology (MIT).  No commercial use of these trademarks may be made
without prior written permission of MIT.

\newpage
\rhead{Page \thepage}
\setlength{\headrulewidth}{0.4pt}
\lfoot{Moira User's Manual}
\cfoot{}
\rfoot{\today}
\tableofcontents
\newpage

\vspace{2 in}
{\Large \hfill Moira User's Manual}

{\large \hfill Mark Rosenstein\\

\hfill \today\\}

\vspace{1 in}
\addcontentsline{toc}{chapter}{Introduction}
\markboth{Introduction}{Introduction}
This is a user's and operator's manual for moira.  It is primarily
targeted for administrators who use moira to manage a distributed
computing environment, although there are sections of interest to
regular users as well.  There are separate manuals to describe
compiling the system, making local modifications, and the design
decisions behind it.

This manual attempts to document both what moira is capable of and the
conventions that we use here at MIT with the Athena Computing
Environment.  Sections describing these local conventions are marked
with a \athena\ symbol and may be done differently at other sites.

\chapter{Moira Overview}
\renewcommand{\thepage}{\arabic{page}}
\setcounter{page}{1}

Moira is the Project Athena Service Management System.  It manages the
configuration of all of the Athena network services.  It consists of a
large relational database, and front end software to control access to
that information and automatically update system servers from that
information.  Moira was developed at MIT's Project Athena, and has
been in daily use here since 1988.  It is freely available via
anonymous FTP from athena-dist.mit.edu, with a copyright similar to
that on the X Window System.

Moira depends on the Kerberos authentication system, and will make use
of the Hesiod nameservice and Zephyr notification services if they are
present in your system.

There are a number of client programs available, which can be run on
any workstation.  These include:
\begin{itemize}
\item moira (listmaint, usermaint, and dcmmaint are part of this)
\item mmoira
\item mrcheck
\item mrtest
\item blanche
\item chfn
\item chpobox
\item mailmaint
\item adduser
\end{itemize}
The text in this document assumes that you are using the {\bf moira}
client program unless otherwise indicated.  References are also made
at various points to the actual moira queries.  These are listed in a
separate document, {\em Moira Queries}.  Queries may be used directly
with the {\bf mrtest} program.

Moira can be used by everyone on the system, but some operations
require specific privileges.  Different parts of moira
are of interest to different users.  Regular users will probably not
be aware of what moira is, yet will use it when they run {\bf chfn} or
{\bf mailmaint}.  More experienced users may do more list manipulation,
using {\bf listmaint} and {\bf blanche}.  Only users with privileges will
be able to use much more than that.

\athena\ Here, we have three kinds of advanced moira users: the user
accounts consultants, the operations staff, and the moira manager.
The user accounts consultants handle problems and questions from users
about their accounts, and are the people who do most of the
manipulation of accounts and lists.  The operations staff handle
configuration of machines, addresses, subnets, clusters, printers, and
fileservers.  Finally, there is one person designated as the moira
system manager who sees that the system runs smoothly and has
occasional maintenance to do.

\section{Moira Objects}

There are several kinds of first-class objects in moira: users, lists,
machines, subnets, clusters, and filesystems.  Other objects in the
database are not as flexible.  These first-class objects share some
characteristics.

\index{names}
Each of these objects has a name, and while all names of a given type
are unique (for example: no two users have the same login name), two different
kinds of object may have the same name (a user may have the same name
as a list).  Names must consist of printable characters excluding
double quotes, asterisk, question mark, backslash, and square brackets
( " * ? \ [ ] ).

\index{references}
These objects are often referenced by other objects in the database.
These references are done in such a way that if you change a user's
login name, all references to that user will now show the new name.
Beware that some other objects in the database do not share this
characteristic: printers, DCM services, and zephyr ACLs.

\index{modification}
Both the first-class objects and many other objects in moira all record
last modification info.  This includes the date and time it was
modified, the user responsible for the modification, and the program
that was used.  Some changes affect the modification info on related
objects.  For example: changing the information associated with a
cluster will update the cluster modification time as well.

\chapter{Regular Users}

Regular users only have permission to examine their own account,
change some of their account information, and manipulate public
mailing lists and lists that they own.  There are a few more
operations that anyone may perform, but most users will not find too
useful.

\section{Name, Address, Phone Number}

\index{chfn}\index{address}\index{phone number}\index{name}\index{finger}
The {\bf chfn} program is used to set how your full name looks to
other users, and your address and phone number as seen by {\bf finger}
and on outgoing mail.  When started, {\bf chfn} will tell you when
your info was last changed and by whom.  If you just press {\em
return}, {\bf chfn} will reuse the old value in that question.  To
make an answer empty, type ``none'' (without the quote marks).  Note
that you cannot have a colon ``:'' or a comma ``,'' in any of your
answers.

Your full name can be whatever you want it to read.  The operations
staff has a separate record of who you really are, so you cannot hide
from them.  Your address and phone number will be accessible to people
who finger you if you enter them here.  You can also keep them blank.

When you change this information, the changes will not take effect
until the next update.  \athena\ This will happen by the next morning
at the latest.  If you are a system administrator, you can change
other people's finger info by running ``chfn {\em username}''.  {\bf Chfn}
uses the queries {\tt get$\_$finger$\_$by$\_$login} and {\tt update$\_$finger$\_$by$\_$login}.

\section{Receiving Mail}

\index{chpobox}\index{mail forwarding}\index{post office box}\label{pobox}

\athena\ Most people receive their email in a post office box, or
pobox, which refers to a special server machine that Athena uses.  If
you want email sent to your account to go somewhere else, you can use
the {\bf chpobox} program to change this.  Note that at a site using POP
servers like Athena, a {\em .forward} file in your home directory will
have no effect.

To see your current pobox, type
\begin{quotation}\tt
chpobox
\end{quotation}
To forward your mail to to another site, use
\begin{quotation}\tt
chpobox -s user@host.domain
\end{quotation}
To undo the above forwarding and receive your mail locally in the same
pobox you used before, type
\begin{quotation}\tt
chpobox -p
\end{quotation}
Note that any change requested by {\bf chpobox} will not take effect for a
while, \athena\ but should be in place by the following morning at
the latest.

Note that moira will canonicalize the hostname if you request mail
forwarding.  In most cases this is correct, but you may want to
override this.  For example, you may want to forward your mail to
``user@LCS.MIT.EDU'', where LCS.MIT.EDU is an alias for the machine
PTT.LCS.MIT.EDU.  In this case you may not want the name LCS.MIT.EDU
to be canonicalized, since in the future the alias may point
somewhere else.  In this case, you could use the command
\begin{quotation}\tt
chpobox -s user@$\backslash$"lcs.mit.edu$\backslash$"
\end{quotation}
to avoid having the hostname canonicalized.  Only the double-quotes
are necessary for the {\bf chpobox} program; the backslashes are there to
get the quotes past the shell.

Sometimes a user really wants mail to go more than one place
without using a mailing list.  This is not recommended, but can be
done by setting the pobox to an external address which is actually a
comma separated list, like this:
\begin{quotation}\tt
\noindent chpobox -s "user@host1, user@host2"
\end{quotation}
\athena\ Note that if one of the destinations is a regular pobox, you
cannot just address it to the user as ``user@ATHENA.MIT.EDU'', you
must instead use an address like ``user@ATHENA-PO-1.LOCAL'' when
specifying multiple poboxes.  The user will also have to set the
environment variable MAILHOST to the name of their POP server if they
do this, since moira no longer recognizes that they have a POP box.

Each of the above commands also takes an additional argument ``-u
{\em username}'' that an administrator can use to modify someone else's
mail forwarding.  There is also a menu choice in the {\bf moira} program
for manipulating poboxes.  The queries pertaining to poboxes are
{\tt get$\_$pobox, set$\_$pobox, set$\_$pobox$\_$pop,} and {\tt delete$\_$pobox}.

\section{Mailing Lists}

\index{mailing lists}
This section gives a brief description of manipulating lists.  For a
more complete treatment of creating lists, their attributes, and other
options on them see section \ref{lists}.

\index{mailmaint}
Any user may add or delete their own usernames from public mailing lists.
This is easiest done with the {\bf mailmaint} program.  {\bf Mailmaint}
presents you with a menu containing the following items:
\begin{enumerate}
\item Show all public mailing lists.
\item Get all members of a mailing list.
\item Display lists of which you are a member.
\item Show description of list.
\item Add yourself to a mailing list.
\item Delete yourself from a mailing list.
\end{enumerate}
\index{public mailing lists}
The first choice will list all of the public, visible mailing lists,
but not private ones.  This may take a while, as there are liable to
be many mailing lists to choose from.

Choice two will display all of the members of a list.  You will only
be able to do this for lists which are visible (i.e.\ not {\em hidden})
unless you are an administrator of the list or you have privileges
within moira.  Lists can contain several kinds of members.  Those you
are most likely to see are users, which name users of the local
system, and strings, which are external mail addresses.  Another list
may be a member of a list as well, in which case every member of that
sub-list is also a member of the first list.

To find out which lists you belong to, you can use choice three.  Note
that you may be a member of some groups in addition to mailing lists,
and these will be displayed at the same time.  To find out more about
any list, you can select option four.

Finally, choices five and six allow you to put your username on a list
or take yourself off.  Note that you can only add yourself to lists
that are public or that you administer, so you may get a ``permission
denied'' error.  In this case, you will have to ask either the
administrator of that specific list, or a user accounts consultant to
make the change.  You can always remove yourself from a list, even if
you did not have access to add yourself.

\subsection{For More Sophisticated Users}

If you manage a list, or want to do more than the {\bf mailmaint}
program allows, there are two other programs that you may find useful.
\index{listmaint} {\bf Listmaint} is a section of {\bf moira}, and will
allow you to change the attributes of a list, change the membership of
a list (one member at a time), and find out more about lists.
\index{blanche} {\bf Blanche} is a program that is faster for quick
checks of a list or making many membership changes to a list.  See
section \ref{listmembership} for more information.

\chapter{User Accounts Administrator}

\athena\ The accounts administrators are primarily responsible for
user accounts, poboxes and mailing lists, and adjusting user quotas.
Quotas will be covered later along with other aspects of filesystems.

\section{User Accounts}
Moira stores a lot of information about users in its database.  It
should have information about every potential user in your community,
whether or not they actually have an account.  For each user, moira
knows:
\begin{description}\index{user accounts}
\index{login name}
\item[login] Their login name if they have one.  This may be up to 8
characters long.  For someone with status 0
or status 4 (not registered or not registerable), it is usually a
hash-mark followed by a number (i.e.\ \#17822), but the value at this
point really doesn't matter.  Moira will not let two accounts have the
same login name.  A login name may be set to the string ``create
unique login ID'' in which case moira will set the login name to
something guaranteed to be unique (a hash sign followed by a unique
number).
\index{UID}
\item[UID] Their {\sc unix} user's ID.  These are stored as 16-bit signed
integers.  This may be set to a numeric value, or the UID may also be
set to the string ``create unique UID'' in which case moira will
assign one automatically that is not already in use within moira.  The
software that assigns them automatically will put them in the range
100-32000.
\item[shell] Their login shell.  To moira this is just a string, up to 32
characters long.  It is used to construct the password entry.
\index{name}
\item[name] Their real first, middle, and last names where they can't be
changed by the user.  Each part may be up to 16 characters long.
\index{status}
\item[status] Their account status.  See the chart below.
\index{class}
\item[class] Their class.  To moira this is just a string, up to 8
characters long and case insensitive.  \athena\ At Athena we
use it to store the reason this account exists.  See the following
table for a list of classes in use at Athena.
\index{ID number}
\item[ID number] This is the user's school or organization ID
number.  The code expects the ID number to be 9 digits.
\item[comment] This is a field for recording whatever additional
information you want about a user.
\index{signature}
\item[signature] This is a cryptographic signature of the login name
and ID number generated with the GDSS (Generic Data Signature Service)
library.  It guarantees the mapping between ID number and login name,
which is used to match up electronic requests with real world
consequences (such as requisitioning supplies or modifying enrollment
records).
\end{description}

\athena\ The classes in use at Athena are:
\label{accountclass}\index{class}
\begin{description}
\item[1992, 1993, etc.] An undergraduate, indicating the expected year of
graduation.  We will not turn off an account before June of the
indicated year.
\item[G] A grad student.  They are here for varying lengths of time, and
take leaves-of-absences as well.  We use the latest records from the
registrar to determine who is eligible.
\item[STAFF] These are Information Systems staff working with Athena.
This classification is now obsolete.
\item[MITS] MIT Staff other than those working with Athena.
\item[FACULTY] MIT Faculty members.  This includes anyone involved in the
teaching of a course who will need access to Athena.
\item[PROJECT] Special accounts for use by projects.  We are trying to phase
these out.
\item[SYSTEM] Special accounts for use by system software.  This includes
the obvious ones like ``root'', ``daemon'' and ``uucp'', and ones needed by
software packages like ``rtingres''.
\item[FALL90, SPRING91, etc] Special students and others needing an account
for just a short while.  The name lets us know when we can turn off
these accounts.
\item[GUEST] Guest accounts.  We are phasing this out, in favor of
the dated fields described above.
\item[TEST] Accounts used for testing either workstations or moira and the
registration process.  Most of these may be deleted at any time.
\item[COURSE] Like project accounts, we are trying to phase these out.
\item[OTHER] Accounts that don't fall into any other category.
\item[Special groups: SIPB, ESP, CAES, KNIGHT, HST, WHOI, etc] These
groups have people who aren't officially part of the MIT community who
have Athena accounts.  These are also being phased out in favor of
dated accounts.
\end{description}

\index{status} The account status field identifies if an account is
active, among other things.  \athena\ At Athena, we have two ways an
account might be active: as a full Athena account with access to
Athena resources, and simply as a user in the campus namespace.
\index{techmail} These namespace users are often referred to as
``techmail'' accounts, since many of them are used by people to setup
mailboxes for use with {\bf techmail}.  A user of the campus namespace
may be on mailing lists, get mail forwarded through the mailhub, and
have a kerberos principal whose name is unique among Athena login
names, but may not actually use Athena workstations.
\index{register}\index{enroll} We use the verb ``register'' to refer
to getting a real Athena account, and ``enroll'' to being entered in
the campus namespace.  The integer values in the status field for a
user mean:

\label{accountstatus}
\begin{description}
\item[0 - Registerable] This is the way students, faculty, and others
eligible for accounts are first entered in the database.
\item[1 - Active] This is a completely active, normal account.
\item[2 - Halfway registered] This is an intermediate step between states 0
and 1 used by the {\bf reg\_svr} program.
\item[3 - Marked for deletion] This account was once active, but has been
turned off.  It will really be deleted at some point in the future.
While it is in this state, no network services will know about it.
\item[4 - Not allowed to register] This is how people are added to the
database who are part of the community but not eligible for accounts.
\item[5 - Enrolled in campus namespace] This is someone who has enrolled in
the campus namespace, and is still eligible to register for an account
as well.
\item[6 - Enrolled, not allowed to register] This is someone who has
enrolled, and is not allowed to register for an account.
\item[7 - Half enrolled in campus namespace] This is an intermediate step
between states 4 and 6 used by the {\bf reg\_svr} program.
\end{description}

\subsection{Looking Up Users}

There are several ways to look up existing users.  Using the {\bf moira}
client, users may be retrieved by login name, real name, ID, or class.
When looking someone up by their name, try to enter their entire first
name or last name.  If you use wildcards in both parts of their name,
the lookup will be much less efficient.  Beware of doing a lookup by
class, and this may return many records.  Queries that return more
than a couple hundred records will cause the server to hang for a
while processing that query.

\subsection{Adding New Users}
When users are added by hand, three items are necessary: the person's
real name, their ID number, and their class.  Most of the time, the
login name, UID, shell, and status should be allowed to default to
``create unique login ID'', ``create unique UID'', ``/bin/csh'', and 0
respectively.  The moira client will also look up the name in the
database to see if that user already appears there.

\index{name}
The name must be correct for accountability.  It generally appears
exactly as the person is known by the school administration, which may
be somewhat different from the way the person likes to print their
name.  There is another field where the user can specify how they want
their name to appear to other users.

\label{namecaps}
Moira is case-sensitive on names.  \athena\ The school administration sends
them to us in all uppercase from their mainframes, but in an effort to
have them look better, we apply the following algorithm: the first
letter of the name and any letter following whitespace or punctuation
will be capitalized, the rest being lowercase.  This works correctly
for names like ``O'Connor'', but will be wrong for names like ``McIntosh''
or ``van Buren''.  Names entered by hand should be entered capitalized
according to this algorithm or the user will not be able to user the
register program.  Moira also strips off any suffixes like ``Jr'', or
``III''.

\index{ID number}
An ID number must be entered.  If one is made up, rather than entering
the correct ID number, then a second entry will be made for this
person if we receive information about them on a tape from the
registrar or personnel office.  If this person is a guest or someone
who will not appear on one of these tapes, make up a number for them.
It must be 9 digits long.

\index{class}
The class must be entered correctly to allow us to treat the account
properly.  It determines when the account is no longer needed and how
we deal with problems with the account.  Do not create new classes
on-the-fly without considering if it is really necessary.  Each new
type of account must be treated separately when it comes time to
cleanup the database.

\index{adduser}
If it is necessary to add a number of users to the database at one
time, you may find it easier to use the {\bf adduser} program.  This
reads a flat file of names and ID numbers, and adds all of the users
at once.

\subsection{Making a User Account}

Once a user is in the database, they may claim an account by running
the register program, or by an administrator registering them using
the register option of the user menu in {\bf moira}.  Even if an
administrator is going to create the account, we suggest first
entering them as above and then registering the account, rather than
entering them as an active account to begin with.  This makes sure
that no part of the account is forgotten.  If you are creating a
system account and want to do it by hand, enter the fields as follows.

The login name must be unique among all login names known to moira.
The UID may be left as ``create unique UID'', or specified as any 16-bit
number.  It may duplicate an existing UID.  The shell should be set to
whatever value you want appearing in the /etc/passwd file for the
user's shell.  The status may be immediately set to 1.  This will
create an account without a filesystem, pobox, group list, quota, or
kerberos principal.

\index{kerberos}\index{krbmap}
If a user account is owned by someone who often works in a different
kerberos realm, it is possible to store kerberos mappings in moira so
that a foreign kerberos principal (or another instance in the local
realm) may have the privileges of a user in moira.  This is done in
the {\em krbmap} sub-menu.  Each kerberos principal must map to exactly
one user.  The principal is specified in a case-sensitive string like
``user.instance@REALM'' or ``user@REALM'' if the instance is null.
Note that any periods in the username or at-signs before the realm
name must be escaped by a backslash.

\subsection{Changing User Information}

Any of the user information may be changed.  If the login name is
changed, the new name must be unique among all login names known to
moira.  All references to that user within moira will now refer to the
new login name.  However, it is still necessary to change the
filesystem name and group name to change all of the information
associated with the user.

\index{class}
\athena\ The class field will be automatically changed by the programs that
process tapes of information from the registrar and personnel offices
if that user's status with the school changes.

\subsection{Removing Users}

In general, users are only deactivated by changing their status to 3.
They are not actually deleted in the course of day-to-day maintenance
by the accounts consultants.  These deletions occur in batch once or
twice a year, see section \ref{deletingusers}.  In fact, the
{\bf moira} client will refuse to delete any account that is not in
status 0.

If you really do want to delete a record of a user account, you may do
so if it has never been registered (i.e.\ still in state 0) or if you
first change it to state 0.  Any quotas the user has assigned or
kerberos mappings will automatically be deleted.  The user record must
not be in use in any of the following ways:
\begin{itemize}
\item must not be a member of any lists
\item must not be the owner of any lists, filesystems, machines,
subnets, or services
\item must not be on a hostaccess list
\end{itemize}
The {\bf moira} client will prompt you to delete an existing filesystem
with the same name as the user assuming that it is the user's home
directory.  It will also prompt you to delete a list with the same
name as the user's group, and to remove the user from any lists that
the user may be a member of.


\section{Lists}
\label{lists}

Lists in moira serve three purposes: they can be mailing lists,
{\sc unix} groups, or access control lists.  Any list can have any
combination of these uses.  Lists may contain users, other lists,
character strings (i.e.\ foreign mail addresses), or kerberos
principals.  When a list contains another list, it is as though all of
the members of the sub-list are also members of the parent list, and
this is handled recursively for as many levels as necessary.  There is
a limit within the current implementation of the server where the tree
structure used to compute intermediate list memberships cannot have
more than 1000 entries, but this is a constant that can be raised by
recompiling and has not proven to be a problem in practice.

We somewhat haphazardly use the terms list administrator, list owner,
list ACL, and list ACE to all mean the same thing.  The correct term
is ACE \index{ACE}\index{Access Control Entity} for Access Control
Entity, although administrator is preferred for readability.

Lists have the following attributes:
\begin{description}\index{list}
\item[name] This can be up to 32 characters.  To avoid mail
problems with the names of mailing lists we recommend that the names
be all lowercase and do not start with a numeral or contain spaces or
other punctuation characters such as comma, period, at-sign, semicolon,
parenthesis, or angle brackets ( , . @ ; \{ \} $<\ >$ ).  List names must
also be unique within the moira database.
\index{active list}\index{inactive list}
\item[active/inactive] This is a flag indicating whether this list should be
present in updates to the system services.  When a list is made
inactive, it is as though it does not exist, except that it is easy to
reinstate by just toggling this flag again.  This is how we make
groups disappear that belong to accounts that are marked for deletion.
\index{public list}\index{private list}
\item[public/private] This flag indicates if a list is public, meaning than
anyone can add their own username to the list or delete their username
from it.  On the other hand, if a list is private only an
administrator of the list or a moira administrator can change it.
\index{visible list}\index{hidden list}
\item[visible/hidden] This flag indicates if a list is visible, in which
case anyone can see the list attributes and membership.  When a list
is hidden, moira will only let the list administrator or moira
administrator see the list attributes or membership.  Note that even
if a list is hidden, the mailhub will tell people the list membership.
\index{mailing list}
\item[maillist] This is a flag that indicates if this list should be treated
as a mailing list and downloaded to the mailhub.  Some lists may
appear on the mailhub that are not specifically marked as maillists,
since any list that is itself a member of another list which is a
maillist will be treated as a maillist.  Also, if a list is an
administrator of a maillist, it will be treated as a maillist (so that
mailer errors pertaining to the list can be sent to the administrators).
\index{group}\index{GID}
\item[group and GID] Group is a flag indicating if this list should be
treated as a {\sc unix} group or not.  If group is true, then GID must
be a unique 16-bit number.  The GID may be entered as a number, or
set to the string ``create unique GID'' in which case moira will
assign one automatically that is not already in use within the
database.  The software that assigns them automatically will put them
in the range 100-32000.
\item[description] This is a simple description of the list, and may be up
to 255 characters long and may contain whatever you want.
\index{ACE}
\item[ACE] ACE stands for Access Control Entity.  This is like an access
control list, except that it is not necessarily a list.  It consists
of two parts: a type, and a name.  The type is one of USER, LIST,
KERBEROS, or NONE.  If the type is USER, the name is a login name
known to moira.  If the type is LIST, the name is a list name known to
moira, and may be self-referential (i.e.\ the list is its own
administrator).  \index{kerberos} If the type is KERBEROS, the name is
a kerberos principal which is case-sensitive in the form
``user.instance@REALM'' or ``user@REALM''.  If the type is NONE,
then any value may be passed as the name and it will be ignored.
\end{description}

\subsection{Creating and Modifying Lists}

Lists may be created with {\bf moira} or {\bf listmaint}.  You will be
asked for each item described above.  If the list is not to be a
group, then the GID is automatically set to ``create unique GID''.

\index{administrator}
\athena\ When a list is created to contain just a few users to be the
administrator of another list, the convention is to call it
{\em list}-request, which is the Internet-wide convention for contacting
mailing list administrators.  If you must create both a list and its
administering list, remember to create the administering list first,
since moira will not let you specify the name of a not-yet-created
list as owner.  Most administrator lists are self-administering, so
that any administrator can grant or revoke that privilege to other
administrators. 

The administrators of a list can change any of its attributes except
the GID, which can only be changed by moira administrators.

A list may be deleted unless it
\begin{itemize}
\item has any members
\item is itself a member of any lists
\item has a group quota
\item is an owner of a filesystem, list, machine, or subnet
\item is in use as an ACL on a query, service, zephyr class, or
hostaccess record
\end{itemize}
The {\bf moira} client will attempt to remove the members of a list and
remove the list as a member of any other lists while deleting a list.
It will display how else the list is in use if it still cannot delete
the list.

\subsection{Membership}
\label{listmembership}

\index{member} List members may be of type USER, LIST, STRING, or
KERBEROS.  A member of type USER is identified by login name, and must
be an account known to moira.  If the account's login name is changed,
this change will automatically be reflected in the list membership.
If a user is a member of a maillist, then mail will be sent to the
user's pobox.  \index{pobox}  A user member of a group simply
puts that user in the group.  A user member of a moira access control
list means that someone authenticating to that user or a kerberos
principal mapped to that user has the privileges granted by the access
control list.

A member of type LIST is identified by the list name, and must name a
list known to moira.  If the list's name is changed, this change will
automatically be reflected in the list membership.  \index{mailing list}
When a list is a member of a maillist, the sub-list will also be
treated as a maillist and mail sent to that maillist will also be sent
to all members of the sub-list.  When a list is a member of a group,
all members of that sub-list are also members of the group.

\index{string} A member of type STRING is identified by the string
itself.  \index{wildcards} Strings may contain spaces and other
punctuation, but beware of asterisk, question mark and square braces (
* ? [ ] ) which are special characters within the database.  You may
store them normally, but to retrieve based on a string containing those
characters, you must precede them by backslashes to avoid their taking
on pattern-matching meanings.  A string member of a group or access
control list is ignored.  A string member of a mailing list is assumed
to be an external mail address.

\index{kerberos} A member of type KERBEROS is identified by a
text-representation of the principal-instance-realm triple.  The
principal is specified in a case-sensitive string like
``user.instance@REALM'' or ``user@REALM'' if the instance is null.
Kerberos members of maillists are ignored.  \index{AFS} Kerberos
members of groups are ignored for NFS servers and {\sc unix} groups, but
propagated to the AFS protection database.  KERBEROS members on moira
internal access control lists apply to users who authenticate as that
kerberos principal and do not map to a user.

List membership may be changed with {\bf mailmaint}, {\bf listmaint}
({\bf moira}), or {\bf blanche}.  {\bf Mailmaint} is intended for naive
users.  {\bf Listmaint} is the {\bf list} menu of {\bf moira} and is the
most complete tool for manipulating lists.  However, it can be tedious
to use {\bf listmaint} to make a lot of membership changes, in which
case {\bf blanche} is a good choice.  {\bf Blanche} will allow you to read
a list of users from a file and put them on a list, or take a number
of changes from the {\sc unix} command line.

\section{Mail Forwarding}

The user accounts consultants will also have to deal with mail
forwarding.  Setting poboxes is covered in section \ref{pobox},
although the {\em pobox} menu of {\bf moira} may be used as well.

There are two possible problems to note, both of which depend on bugs
and features of sendmail (these are in sendmail version 5.61, but have
been there for a while).  If there is at least one bad address on a
mailing list, which includes putting a user on a mailing list who
doesn't have a pobox, then sendmail will just give an error for the
entire list without delivering it to anyone.  \index{pobox} If a user
has a pobox and there is a mailing list with the same name, the user's
pobox will take precedence over the mailing list.  Moira outputs both
in the aliases file, and sendmail only pays attention to the latest
definition of an address.

\chapter{Operations Staff}

\athena\ The operations staff is responsible for workstations,
servers, managing disk space (with the help of the accounts
administrators), printers, and the network.  The following sections
cover how moira interacts with these.

\section{The Host Table}

Moira maintains the internet hosttable for the environment.  This
means keeping track of the names, addresses types, and alias names of
all of the hosts in that administrative domain.

\subsection{Machines}
\index{machine}\index{host}
For each machine (host), moira knows the name, address, hardware type,
and a lot of other information. Specifically:
\begin{description}
\item[name] The name is the fully qualified domain name.  For
instance, ``ATHENA.MIT.EDU'' is a valid name, but ``ATHENA'' is not.
\index{hostname} Machine names are {\em not} case sensitive as they
are all converted to uppercase when the moira server gets them.
\item[vendor, model, os] These fields are for information only.  They
are stored in the host table.  They are case insensitive, always being
stored in uppercase.
\item[location] The on-campus room number where the host can be found.
\item[contact] Who is responsible for the workstation and should be
contacted in the event of problems or questions.  This is just a
character string.
\item[use] This integer records what type of use the workstation gets,
for determining accessibility to third-party software.  The field is
not yet in use, so actual values have not been defined.
\item[status] This integer records the status of the hosttable entry.
See the table following this one.
\item[statuschange] This is the date that the {\em status} field for
this host last changed.
\item[subnet] This identifies which subnet the workstation is
connected to.  It may name an actual subnet, or be the value ``none''.
\item[address] This is the internet address assigned to this
workstation, in dotted decimal notation.  Besides the actual address,
it may be ``unassigned'', or the special value ``unique'' may be
stored here which causes a new address to be assigned on the named
subnet.
\item[owner] The owner is an access control entity and may be a user,
list, kerberos principal, or ``none''.  The owner of a machine is
allowed to change certain characteristics of that machine, such as the
name, type, and location.
\item[administrative comment] This is a comment field for use by the
network help desk or other administrators.
\item[operational comment] This is a comment field for use by the
people maintaining the campus network.
\item[created] This records when the entry was first added to the
database, and who made the entry.
\item[last known use] This records when the host was last known to be
in use on the network.
\end{description}

Note that the {\bf moira} user interface automatically canonicalizes
any hostnames typed using the domain name system.  If you want to
enter a name and not have it canonicalized, enter the name surrounded
by double-quotes (").  

\index{cname}\index{host alias}
Each host can also have alias names, or CNAMEs.  The owner of a
workstation can add up to two aliases for that workstation.  Database
administrators can add any number of aliases.  These are stored in a
separate table, and accessed with the {\tt get$\_$hostalias,
add$\_$hostalias}, and {\tt delete$\_$hostalias} queries.

\index{AFS cell} 
We also have entries in the machines table for each AFS cell.  These
entries are used in the filesystems table.

These are the machine status values currently in use:
\index{machine status}
\begin{description}
\item[0] Reserved: This hostname and/or address is not actually in
use, but it is being reserved so that no one else may use it.
\item[1] Active: This is a normal, active entry.
\item[2] Unknown: This value should not appear in the database.  It
may occasionally show up as a placeholder when the correct value is
unknown.
\item[3] Marked for Deletion: This host is no longer in use, and will
soon be deleted from the database.
\end{description}

\subsection{Subnets}

\index{subnet}
Information about subnets is also stored in the database.  This
information is necessary to be able to assign internet addresses, and
control access to groups of hosts.  For each subnet, moira knows:
\begin{description}
\item[name] The name of the subnet can be any string that is easy for
the operators to remember.  It is not seen outside of moira.
\item[description] This text field is available for whatever the
operators want to store here, generally a description of the location
of the subnet.
\item[address, mask] This is the internet address and subnet mask to
be used on the subnet.
\item[low, high] These two addresses define the range in which moira
may assign addresses to hosts on this subnet.
\item[owner] The owner is an access control entity and may be a user,
list, kerberos principal, or ``none''.  The owner of a subnet may add
new hosts to that subnet, and manipulate the address, status,
and administrative comment fields, as well as those fields that the
owner of the host can modify.
\item[prefix] This text string is used to create unique hostnames for
machine automatically created on this subnet.
\end{description}
The subnet information is not ever exported from Moira.  It is just
here to organize other information in the database.

\subsection{Adding a Machine}

Is this really a new machine, or are you really trying to rename or
otherwise change an existing machine?  If this is a rename, see
section \ref{hostrename} below.

Determine the machine architecture, location, and other pertinent
information and enter that.  You must know what subnet the machine
will be connected to.  You may then let moira chose a name and address
by entering ``unique'' for each of these fields, or you may enter your
own values.

Next you will need to add the machine to one or more clusters.
Determine the appropriate cluster(s) based on location and
architecture, and add the machine.  See below for information about
clusters.

\subsection{Changing Machine Information}
If a workstation is replaced by another of a different architecture,
all that is required is to update the vendor, model and os fields in
the database.  Following an architecture change or moving a
workstation is moved from one place to another, it will probably need
to be removed from one cluster and added to another.

\label{hostrename}\index{rename}
If the name of a workstation is to be changed, change it in the
database first.  Then change the name on the workstation itself after
it is activated and before the next moira update.  If the workstation
is allowed to deactivate now, it will fail to activate until the next
moira update.  It is probably a good idea to list the old name as an
alias for the machine following a rename.

\subsection{Deleting a Machine}
You cannot delete a machine that is in use in any way other than
having a cluster assignment.  If the machine is in a cluster,
{\bf moira} will prompt you to remove it.  If the machine is in use in
any of these ways:
\begin{itemize}
\item has poboxes assigned to it
\item receives moira updates
\item has any NFS physical partitions
\item spools for any printers
\item spools for any palladium printers
\item is a printer quotaserver
\item has filesystems on it
\end{itemize}
you will not be allowed to delete it.


\section{Managing Workstation Information}

Moira also manages configuration information for workstations besides
the hosttable.  This is done through groupings called clusters.

\subsection{Clusters}
\index{cluster}
A cluster is a grouping of machines with their assigned resources such
as file servers, printers, etc.  Each cluster has a name, a
description, and a location.  The location is actually just an
additional description field for the users' convenience.  \athena\ We
use the cluster naming convention
\begin{quotation}\tt
\noindent [building name][optional designation]-[architecture]
\end{quotation}
For example, m11-vs, e40test-rt, w20a-vs (the ``a'' designation because
there are multiple vax clusters in building W20), m66priv-rt (this has
{\em priv}ate workstations only in it).

\index{cluster information}
Each cluster has information associated with it.  Cluster information
consists of a label and a text string.  \athena\ Labels in use at
Athena include ``syslib'' and a filesystem name for the system pack
containing OS binaries, ``lpr'' and a printer name to be the default
printer for the workstation, ``zephyr'' and a hostname to specify the
preferred zephyr server for the workstation.  \athena\ The Athena
convention for system pack names is that each pack or filesystem has
only one name, and if several clusters in adjacent buildings all use
one pack, each refers to this one pack by its name.  This is clearer
than having multiple filesystem names that point to the same actual
bits on disk.

Each workstation may be in any number of clusters.  If a workstation
is not in any clusters, it will have no cluster information.  If it is
in one cluster, its info is that cluster's info.  If a workstation is
in more than one cluster, its cluster info is the union of the info
for each of the clusters it is in.  This is useful as you may have
workstations of two different architectures in one room; the machines
of each architecture need different system packs, but the same default
printer.  You can use 3 clusters: two each identifying system packs for
the two architectures, and one identifying the printer for both.  This
is better than putting the printer information in with the
architecture specific cluster since there is only one place to change
if the printer configuration is changed.

\subsection{Adding a New Cluster}
When adding a new cluster, first check to see that a new cluster is
really needed.  Machines in a new building that will use existing
fileservers in another building may be put in the other building's
cluster, although creating a separate cluster may be clearer and will
be required if a different printer is needed.  Be sure to write
something informative into the description and location fields if they
are not obvious from the name.

Next you will need to add the appropriate information for the cluster.
At a minimum this would be the syslib information, and may require
usrlib as well.  If there is one printer that is obviously closest to
machines to be placed in this cluster, then add an lpr entry for the
printer as well.  

\subsection{Changing Cluster Information}
The cluster name, location or description can easily be changed.  If
the name is changed, it will automatically be updated in the machine
to cluster mappings as well.  The cluster information may be changed
by adding or deleting cluster information.  It is possible for the
same label to appear more than once in a cluster's info.

\subsection{Deleting a Cluster}
You cannot delete a cluster if it has any associated cluster
information.   First delete the cluster info, using wildcards for the
label.  You may then delete the cluster.  If there are any machines
still assigned to the cluster, moira will prompt you to delete them.

\section{Managing Filesystem Information}

\index{filesystem}\index{locker}
A filesystem in Moira is an abstraction that can refer to an NFS
mountpoint, an RVD pack, an AFS volume, an error indication, or a
combination of these.  Filesystems are often referred to as lockers so
that they are not confused with the partitions that NFS lockers reside
on.

Moira manages the NFS partitions as well, keeping track of quota
allocation and actually creating the base directory of a locker when
necessary.  Moira also manages quotas that apply to both NFS and AFS
lockers.

\subsection{Lockers}

Moira has the following fields for each filesystem:
\begin{description}
\item[name] This is a label for the filesystem, up to 32 characters long,
same restrictions as list names.  Each filesystem name must be unique.
\item[type] The is the protocol type of the filesystem: AFS, NFS, RVD, ERR,
FSGROUP, or MUL.  AFS, NFS, and RVD refer to actual filesystems.  ERR
just refers to an error string.  FSGROUP is a filesystem group, a list
of filesystems in prioritized order which should be tried until one
works.  MUL is a multiple filesystem, where each of the filesystems
listed should be attached at the same time, in the order listed.
\item[machine] This is the server that the filesystem resides on.  This
machine must be entered in moira.  This only actually names a machine
for NFS and RVD lockers.  For AFS lockers, it names the AFS cell.  For
other types, it must be present, but the value ``[NONE]'' is usually used.
\item[packname] The name of the filesystem relative to the server.  For NFS,
it is the path on the server to the root of the locker.  For RVD, it
is the pack name.  For AFS, it is the path to the root of the locker
in the AFS cell.  It is ignored for ERR, FSGROUP, and MUL types.
\index{packname}
\item[default access] This is the mode that is used when the locker is
attached.  Typical values are ``w'' for read/write, ``r'' for read-only,
``n'' for read-only without authentication, and ``x'' for exclusive.
\index{access}
\item[default mountpoint] This is where the locker is attached to the client
workstation.  \athena\ This is usually /mit/{\em lockername}.
\item[comments] Any descriptive comments up to 64 characters.  For type ERR
filesystems, this is the error message.
\item[ownership] These two fields called ``owner'' and ``owners'' identify
the user and group ownership of the locker.  The owner must be a user
known to moira.  The owners group must be a list known to moira.  When
the locker is created, this ownership will be used for the directory.
\index{owner}
\item[auto create] This flag indicates that moira should attempt to create
the specified locker on a fileserver.  When attributes of a locker are
changed in moira, some of them will also be changed on the fileserver
if this flag is on.  Clearing the autocreate flag for existing NFS
lockers makes the NFS updates run slightly faster.  Note that
autocreate only has meaning for NFS and AFS filesystems.  \index{auto
create}
\item[locker type] This field indicates what the locker is used for.  This
is just a string to moira.  \athena\ Values in use are HOMEDIR for
user home directories, SYSTEM for system software delivery, PROJECT
for development project lockers, COURSE for educational course
software, ACTIVITY for student activities, EXTERN for pointers to
filesystems outside of Athena, and OTHER for whatever doesn't fall
into these categories.  \index{locker type}
\end{description}

\subsection{NFS Partitions}

\label{nfspartitions}\index{partition}\index{NFS}
Moira keeps information about the actual disk partitions that NFS
servers put the NFS lockers on.  For these the following info is kept:
\begin{description}
\item[machine] This is the host that the partition resides on, and must be
known to moira.
\item[device] The is the device name for the partition, such as ``/dev/ra3e''.
\item[directory] This is the mountpoint of the partition.  \athena\  We
sometimes make this a subdirectory of the partition if we really want
all lockers on that partition to be in that subdirectory.  For
instance, on a partition called ``/u1'' we might store the directory
in moira as ``/u1/lockers'' so that all lockers would be created under
that point.
\item[status] This field actually bit-encodes two things: the intended usage
of the partition and whether group quotas are in use.  There are use
bits for: student, faculty, staff, and miscellaneous.  These use bits
are simply informational except for the student bit: this bit must be
set on any partition that the \index{registration} registration server
will automatically put home directories on.  \index{group quotas} The
group quotas bit indicates what kind of quota extract should be done
for this partition.
\item[allocated] This field contains the total of all of the quotas of
lockers on this partition.  It is automatically maintained by moira
when quotas are changed.
\item[size] This should be the size of the partition in 1K blocks, although
in practice this number is often changed to adjust allocations.  The
registration server uses this number to decide where to allocate home
directories. 
\end{description}

NFS partitions may be created on any machine known to moira, even a
machine which is not receiving NFS updates.  If it is not receiving
updates, the directories will not get automatically created and quotas
will not get set by moira.

\subsection{Adding a Filesystem}

A filesystem may be added by entering the information described above.
When creating a filesystem, don't forget to assign any necessary quotas.

\index{NFS filesystems}
For type NFS filesystems, all of the fields are used.  The {\em machine}
must be known to moira.  The {\em packname} must exist on a known NFS
partition.  The {\bf moira} client will prompt you to create the NFS
physical partition if it does not already exist, then retry the
addition of the filesystem.  The {\em ownership} will be used when
creating the directory, if the {\em autocreate} flag is set.

\index{RVD filesystems}
For type RVD filesystems, the only requirements are that the {\em machine}
the pack is on must be known to moira.  All fields except {\em ownership}
and {\em autocreate} will be used.  Moira does not actually update RVD
servers, so this information only feeds the nameservice.

\index{AFS filesystems}
For type AFS filesystems, all fields are used as well.  It is
important that the proper cell be entered into the machine field.

\index{ERR filesystems}
For type ERR filesystems, only the {\em name, type}, and {\em description} are
used.  The remainder of the fields will be ignored.  Since often the ERR
type is used to temporarily deny access to a filesystem, you can
change the {\em type} to ERR and the {\em description} to why access is being
denied, and easily change it back later without losing the rest of the
information. 

\index{fsgroup}\index{File system groups}
File system groups are used to associate several filesystems with one
name.  Usually these are redundant copies of the same data for the
sake of reliability, or because not all clients support all filesystem
types.  The filesystems that make up the group are sorted in a known
order, and {\bf attach} will try them in that order until one is
successful.  Multiple filesystems are treated exactly like filesystem
groups except for how they are attached.

In the main entry for an FSGROUP, only the {\em name, type}, and
{\em description} are used.  Each of the member filesystems must have
different names from each other and the FSGROUP.  \athena\ A useful
convention is to have fsgroup {\em foo} containing {\em foo}-primary and
{\em foo}-secondary if the group is for redundancy, or {\em foo}-afs and
{\em foo}-nfs if the group is for handling multiple protocol types.

Moira also has the concept of filesystem aliases.  \index{filesystem
alias}  An alias just associates another name with an existing
filesystem.  Because they can be confusing, their use is discouraged.
\athena\ We use them primarily for developers' and testers' system
packs.


\subsection{Changing a Filesystem}

If you change the name of a filesystem, references such as its
membership in an FSGROUP or quota assignments will follow the new
name.  If the change involves moving the files, moira will not do all
of the work.  This includes moving from one partition to another,
moving from one server type to another, or even just changing the
packname on the server.

For NFS lockers, the easiest way to deal with this is to rename the
existing filesystem to {\em foo}-old, and create a new filesystem {\em
foo} where you want the files to end up.  Then you can attach both
filesystems, copy the files, and delete the old files and filesystem
entry when you are sure the new one is stable.  For faster turnaround
on filesystem moves, you can move the files and update moira at the
same time, in which case answers from the nameserver will be
inconsistent with the fileservers until the next moira update.

For AFS lockers, if autocreate is set to true, Moira will rename the
volume and mountpoint as you change the locker specification.  If you
change something that moira does not know how to change in the
filesystem, a critical error will be logged stating this.

When a filesystem is moved between like servers, the quotas will
automatically move with it.  If it is moved from an NFS server with
user quotas to AFS, an AFS quota will be assigned which is the sum of
all of the user quotas assigned to the locker.  Note that if it is
moved to or from an NFS partition with group quotas that the quotas
will not automatically follow.  Old quotas are left in the system, so
if a filesystem is later returned, the old quotas will be used again.

Access may be temporarily denied to a filesystem by changing its
{\em type} to ERR, and putting a helpful message in the {\em description}
field.  Nothing else needs to be changed, so it is easy to restore
access by restoring the {\em type} to its previous value.

\subsection{Deleting a Filesystem}

When deleting a filesystem, any quotas assigned to it will
automatically be deleted.  Do not forget to make an archival tape of
the contents of the locker, then actually delete the files on the
fileserver as well, since moira will not do this for you.

\subsection{Quotas}

Moira keeps track of disk quotas for multiple types of entities (users
and groups) and for multiple types of filesystems (NFS and AFS).  The
filesystem info is:
\begin{description}
\item[filesystem] Which filesystem this quota applies to.
\item[type] Type of entity this quotas applies to, currently USER, GROUP, or
ANY. 
\item[name] Name of entity.  This is a login name for type USER quotas, a
list name for GROUP quotas, and ignored for ANY quotas.
\item[quota] The quota value in 1K disk blocks.
\end{description}

\index{AFS} If the named filesystem is of type AFS, only quotas of
type ANY will be used and others will be ignored.  \index{NFS} If the
named filesystem is of type NFS, the type may be either USER or GROUP.
Moira determines which NFS physical partition the filesystem resides
on, and the flag in the NFS physical information will indicate if this
partition is a user or group quota partition.  Any quotas of the wrong
type will be ignored.  Moira will sum up all quotas pertaining to a
user on a partition and tell the server the total for each partition.

When filesystems are moved, the quota information moves with them.  If
a filesystem is changed from type NFS to type AFS, and a quota of type
ANY does not exist for that filesystem, moira will create such a quota
containing the sum of all of the USER quotas on that filesystem.

\section{Managing Printer Information}

Moira manages printcap information as well.  For each printer, moira
records:
\begin{description}
\item[name] up to 16 characters long.
\item[spooling machine] This must name a machine known to moira.  For the
``rm'' printcap field.
\item[spool directory] Any text string (up to 32 characters) as far as moira
is concerned, it will be put in the ``sd'' printcap field.  This
directory is typically /usr/spool/printer/{\em name}.
\item[remote printer name] Name of the printer relative to the spooling
machine, for the ``rp'' printcap field.  It is usually the same as the
printer name. 
\item[quota server] This must name a machine known to moira.  This is for an
Athena addition to lpr for authenticated printing.  It is put in the
``rq'' printcap field.
\item[authorization] This flag indicates if kerberos authorization is
required for this printer.  It goes in the ``ka'' printcap field.
\item[price per page] Price in cents per page printed on this printer, to
appear in the ``pc'' printcap field.
\item[comments] Up to 64 characters of comments
\end{description}

Since printers are not referred to by other parts of moira, they may
be added, changed, and deleted at will.  Note that moira does not
support an atomic action to change a printer, so it is possible under
some circumstances for a printer to accidently be deleted if an error
occurs while changing it.


\chapter{Moira System Manager}

\athena\ The Moira System Manager handles the regular maintenance of
the Moira server itself, along with some cleanup of the contents of
the database.

\section{The Server Process}

\index{moirad}
The heart of Moira is the process {\bf moirad}.  This must be running
for Moira to be up and working.  A {\tt ps} command on the server will
show both the {\bf moirad} and it's parent process, {\bf startmoira}.
As the {\bf moirad} runs, it writes to three log files: {\it
/moira/moira.log, /moira/journal}, and {\it /moira/critical.log}.  It
is not a good idea to modify or move these files while the server is
running.

\subsection{Starting {\bf Moirad}}

\index{ingres}
Before starting moira, Ingres must already be running.  This is
normally done by the system {\tt rc} files.  You can check to see if
Ingres is running by doing a {\tt ps}, and look for processes {\tt
iigcn, iigcc, dmfrcp, dmfacp}, and {\tt iidbms}.  If Ingres is not
running, be sure to check the log files in {\it /usr/ingres} and {\it
/usr/ingres/files} before trying to start it again, because your next
attempt to start it will erase the logs containing the original error.
Ingres is started by running {\tt /usr/ingres/utility/iistartup}.

\index{dbck}
If the machine crashed, or you are unsure of the state of the
database, it is a good idea to run the database consistency checker,
{\bf dbck}.  It takes arguments similar to {\bf fsck}, and is usually
run as:
\begin{quotation}\tt
/moira/bin/dbck -p -f -d 10 $>$\& dbck.log
\end{quotation}
This check will take about an hour, and will generate many lines of
warnings.  Most of this is very normal.  The log should be examined
for any errors that may be important.

{\bf Moirad} is normally started using {\bf startmoira}.
\index{startmoira}  It is not necessary to do this, it is a
convenience program to avoid having to always have the proper
environment to start the moira server.  {\bf Startmoira} will change to
the root directory, then run {\bf moirad} capturing the logging
information, timestamping it, and writing it to {\em /moira/moira.log}.

Remember to re-enable {\bf} DCM updates, both by removing {\em
/etc/nodcm} and by setting to 1 the {\bf Enable} flag in the database.

\subsection{Shutting Down the Server}

There are several different ways to shutdown moira.  You can close the
database to the server and leave it running, or you can actually bring
down the server.

If you will be doing database maintenance, you can close the database
and leave the server running.  This way people will get a friendly
message when they attempt to access the database.  Just create the
file {\em /etc/smsdown} on the server, and the next time the server
has no active connections it will close the database.  Thereafter, if
anyone starts a moira client, the contents of this file will be
displayed as the moira ``message of the day''.  If you later remove
the file, the next time a client connects to the server it will reopen
the database.  If you are in a hurry to close or open the database,
you can send it a signal USR1 (i.e.\ {\tt kill -USR1 {\em pid}}) to
make it close as soon as the current query is finished processing, or
a signal USR2 (i.e.\ {\tt kill -USR2 {\em pid}}) to make it open
immediately.  Note that a side effect of closing and reopening the
database is to flush all cached information such as query access
control lists or name to ID mappings.
\index{cache}

To actually kill the server, simply send it a HUP or TERM signal
(i.e.\ {\tt kill {\em pid}}).  It will then exit as soon as the
current query finishes processing.  If you want to shutdown more
gracefully, either wait until no clients are connected to the server
(by monitoring {\em /moira/moira.log} or using the {\tt
$\_$list$\_$users} query) and then kill the server or first close the
database as specified above, then kill the server once the database
has closed.  Note that the server may not exit right away since it
will attempt to finish up any query currently being processed and
drain the incremental update work queue as well.  Beware of forcing
the server to exit with a {\tt kill -9}.  While this will make the
server exit, the Ingres backend will continue working on the current
query.  If the query was a retrieve, things are probably OK, although
you may lose some items from the incremental queue.  If the active
query was attempting to modify the database, it is particularly bad to
force the server to exit.

\section{Accounts}

There are a number of things the system manager must do to keep user
account management running smoothly.  These include loading new users
into the database, deleting old accounts, and performing some general cleanup.

\subsection{User Account Tapes}

\index{students}\index{employee}\index{regtape}\index{User accounts}
Much of the general cleanup and maintenance of user accounts is done
via the {\bf students} and {\bf employee} programs.  These programs
each process ``tapes'' (actually regular files) of information
obtained from the registrar and personnel offices.  Operation of each
program is the same, although the format of the two tapes is slightly
different.

These programs process records one at a time.  They take the input
records and parses them, then use the ID as a key to lookup the user.
If the user is not already in the database, he is added.  If he is
already there, the class, status, and address fields are checked and
updated if necessary.

The status field will be set depending on the class.  Students and
faculty are eligible for accounts and are created in state 0
(registerable).  Others are created in state 4 (not enrolled).

Whenever a user is touched, either because they were found on the tape
or because they are added as a new user, these programs set the
{\em ugdefault} field to 1.  This way if these fields are all cleared
before loading tapes, afterwards you have a record of who was on the
latest tape.  It is generally safe to delete users in states 0 or 4
(unregistered or unenrolled) who are not on the latest tapes.  And
since these users never touched their entries, there are no other
references to them in the database to clean up.

There is one option to these programs that is generally used:
{\bf -n} causes moira to fill in the finger information for users who
currently have those fields blank.

\athena\ We receive student tapes every other week, and staff tapes
once a month.  Email messages are automatically generated when the
tapes are received.  The data is placed in {\t /moira/tapes} (actually
a symlink to {\it /afs/net.mit.edu/project/directory/data}).  The
tapes are generally loaded as soon as they are received, as the load
takes less than an hour and has minimal impact on the database while
it is being processed.

\subsection{Register}

\index{register}
There are three components used in registration: the {\bf reg\_svr}
daemon running on the moira server machine, the {\bf userreg} client
program, and a shell script necessary to get {\bf userreg} started
correctly under different circumstances. 

\index{reg\_svr}
The registration server is another server process that runs on the
moira server machine.  Similarly to {\bf moirad} and {\bf startmoira,
reg\_svr} is started by the {\bf startreg} program.  It also writes to
three log files: {\it /moira/reg\_svr.log, /moira/journal.reg}, and
{\it /moira/critical.log}.

\index{userreg}
\athena\ The {\bf userreg} client is started in several different
ways.  For instance, one can login for a tty-based session as user
``register'', password ``athena'' and the user will be prompted for a
terminal type, then dropped into {\bf userreg}.  Or they may press the
``Click here to register for an account'' button on our current login
screen, which runs a script to start {\bf userreg} in an xterm.  In a
previous configuration clicking on that button logged the user in as
register for a workstation session instead of a tty-based session,
requiring another script.  These will have to be customized for your
workstation configuration.

\index{disabled.times}
When {\bf userreg} is started, it checks a file called
{\em disabled.times} to determine if anyone is allowed to register right
now.  This file contains {\em crontab}-style lines specifying times when
registration is not allowed and the appropriate message to display at
those times.  For example, the file:
\begin{quotation}\tt
\noindent * 23 * * *	nightly database propagation is in progress.\\
0-29 0 * * *	nightly database propagation is in progress.\\
* 4 * * 7	weekly database maintenance is in progress.
\end{quotation}
would disallow registration from 11:00pm to 12:29am each evening, and
from 4:00am to 4:59am on Sunday mornings.  Do not put in a line with
all asterisks to match all times, as this will confuse the algorithm
{\bf userreg} uses to tell the user when the next time is that
registration will be allowed.  It is a good idea to disable
registration this way whenever taking down the {\bf reg\_svr} since
otherwise users will not get an informative message as to why they
cannot register (they will simply be told that ``part of the computer
system is down'' after a delay of several minutes).

The {\bf userreg} program enforces the same capitalization rules as
the bulk load programs (described in section \ref{namecaps}).  Even
though the name may occasionally not look right on the screen, that
should be the way it is recorded on the database.  The first name,
last name, and ID number must all match what is in the database before
the user will be found.

\index{login name}
The suggested username is a concatenation of the first initial, middle
initial, and first six characters of the last name.  However, users
are free to choose any username that begins with a lowercase letter, is
followed by lowercase letters, numerals, or underscore, and is from
three to eight characters long.  {\bf Userreg} first checks to see if
the proposed username is in use in kerberos before querying moira
(since the kerberos lookup is much faster).  If you have kerberos
principals without corresponding accounts in moira, those usernames
will still be reserved in moira.

Setting the username in the database is the heart of the registration
process, as all other resources for the account are set at the same
time.  The {\bf reg\_svr} simply executes a {\em register\_user} query and
reserves the principal in kerberos.  This query takes the following
actions:
\begin{enumerate}
\item The user must exist and have a status of 0 (not registered), or 6
(enrolled but not registered).
\item The new login name must not be in use as a login name, list name, or
filesystem name.
\item A location is chosen for the user's pobox, and this pobox is assigned.
\item A ``group'' list is created with the same name as the user, which is
an active, private, visible group with a unique GID.  The
administrator is the user and it has one member who is also the user.
\item An AFS locker is created with the same name as the user, owned
by the user, with locker type ``HOMEDIR''.
\item The default quota is assigned for the user on the locker.
\item The user is left in state 2 (half-registered).
\end{enumerate}
Only if all of these steps are successful will the new username be
allowed.

\index{pobox}
The pobox is placed on the POP server with the most free space.  This
is found by scanning the server-host tuples for each of the hosts
supporting service POP.  {\em Value1} for a POP server indicates how
many poboxes are assigned to this server, and is maintained
automatically by moira.  {\em Value2} is the maximum number of poboxes
allowed on this server.  The POP server is chosen which has the
largest difference between the maximum and the current usage.

\index{home directory}
The home directories are allocated in a different manner.  Moira
creates a type ``AFS'' locker in the ``ATHENA.MIT.EDU'' cell, then
assigns it a quota, obtaining the value from the value of
``def\_quota'' stored in the moira values table.  But moira has no
knowledge of where the locker actually ends up.  The incremental
update program for AFS keeps track of the allocation on each
partition, and it chooses a partition to create the locker on.

When this step is completed, the user is half-registered.  They still
have to choose a password.  When they enter their password, {\em
reg\_svr} will set it in kerberos and update their status to 1
(active).  Their account is now complete, and will be usable the next
time moira updates the system services.

\subsection{Signatures}

\index{signatures}
Every active user account must be signed to be properly authenticated.
Whenever someone modifies an account through one of the moira clients,
a signature is generated using that user's Kerberos tickets.  But
accounts created by the {\bf reg\_svr} cannot be signed, because there
are no Kerberos tickets available then, and it would defeat the
purpose to have them automatically signed.

So about once a month, these accounts are signed.  First a security
audit of the Moira server is performed.  Once convinced that no one
has broken into the server recently, all newly created accounts are
signed in bulk.  This is done by running the {\bf sign} program.
Start with an encrypted net connection, since {\bf sign} will ask for
a password.  Then run
\index{sign}
\begin{quotation}\tt
/moira/bin/sign
\end{quotation}
(no arguments are necessary).  It will prompt for the password for
``moira.extra''.  Once this is entered, it will generate a signature
for any unsigned active user account.

\index{verify}
If you are having trouble with signatures, there is a program {\bf
verify} which will check signatures in the database.  Given the
argument of a username, it will verify just that account.  Otherwise,
it will verify all user accounts.  A message will be printed for any
signatures that fail verification.  If the argument {\tt -fix} is
given, it will fix any bad signatures as it goes (after prompting for
the Kerberos password for ``moira.extra''.

\subsection{General Cleanup}

It is good to periodically check the database to see that things are
in order.  Things to check for include: users without poboxes,
duplicates, users without filesystems, obscure classes, etc.  Most of
this is done directly in SQL.  Some things, like deleting users who
never registered for their accounts and are no longer eligible, are
easy and should be done monthly when new tapes are loaded.  Other
cleanup only needs to be done once a term or once a year.

\label{deletingusers}
To delete a mass of users, simply use the interactive SQL commands to
delete the desired columns from the {\em users} table.  Then run
{\bf dbck} to catch and remove any dangling references.  You will
probably want to delete any filesystems and lists with the same name
as the deleted users.

\athena\ The procedure for deactivating accounts here at Athena is as
follows:
\begin{enumerate}
\item Wait until the second month of the semester.  Then make a list
of everyone no longer eligible for an account.  This generally
includes those in the class that just graduated, and graduate students
and staff who have not appeared on a tape in several months.  The {\em
xmodtime} field in the users relation lists the time the last tape was
loaded that they appeared on.
\item Circulate the proposed deactivation list.  First to I/S staff,
then a couple weeks later, make it available to all users.  Publicize
this through the message-of-the-day and other places.  During this
time, anyone who convinces the User Accounts Consultants that their
account should be kept is removed from the list.
\item A couple of days before the scheduled deactivation date, the
list is frozen.  It is loaded back into the database, and the {\bf
flag} field in the users relation is used to mark which accounts will
be deactivated.
\item The evening before the deactivation is to take place, the status
on each marked user account is set to 3, ``marked for deletion''.
Also, any lists with names the same as users being deactivated have
their status set to ``inactive''.  Finally, any filesystems with name
the same as users being deactivated have their type set to ``ERR'',
and their comment set to ``Locker deactivated; call x3-1325 for info''.
Any AFS lockers deactivated this way also need to have their mount
points removed and volumes renamed.
\item In the following days, User Accounts will receive calls from
people who were accidentally deactivated.  They can reinstate an
account just by setting the user's state, enabling the list and
filesystem.
\item After a couple of months, the files corresponding to deactivated
lockers are archived to tape, and the entries are removed from moira.
\item The following summer, the deactivated records are removed from
the database so that the names and ID numbers can be reused.  These
are removed in bulk operations, then {\bf dbck} is run to patch up any
broken pointers.
\item The following summer, we really delete them.  By waiting most of a
year, we reserve the username and UID for that period of time to avoid
confusion in email or file ownership.  At deletion time, we use raw
SQL to delete any user record in state 3 that has been unmodified for
more than 6 months.  The lists and filesystems are similarly cleaned
up.  The moira database consistency checker is run to catch any
dangling references to these now-deleted accounts.
\end{enumerate}

\section{Server Updates}

\index{updates}\index{dcm}\index{data control manager}
Keeping tabs on the regular moira updates of system servers is one of
the daily duties of the moira system administrator.  Normally,
everything works without any intervention.  However, when errors do
occur, the system will not attempt any more updates for the failed
service until the error is manually reset.

Updates are attempted whenever the data control manager, or {\bf dcm},
is run.  The {\bf dcm} is normally invoked by {\bf cron}.  You may
configure it to run regularly, perhaps as often as every 15 minutes,
or only run {\bf dcm}s at certain times of the day.  \athena\ Because
the database is read-locked for the duration of a service update, we
only run updates at night.  This means that changes made during the
day are not visible until the following day.  We currently invoke
several {\bf dcm} processes near 12:30am, then one more hourly until
4:30am.  Invoking it many times gives parallelism for updates that
take a long time and guarantees retries in the case of transient
failures.

{\bf Cron} actually runs {\bf startdcm}\index{startdcm}, which is a
program that launches the dcm after connecting to the root directory
and setting up the debugging and logging correctly.  It is
{\bf startdcm} which puts the timestamp on each line logged to
{\em /moira/dcm.log}.  It is not necessary to use {\bf startdcm}; it is a
convenience program to avoid having to always have the proper
environment to start the {\bf dcm}.

\subsection{Services to be updated}

\index{service}
For each service moira supports, the following information is kept:
\begin{description}
\item[name] Up to 16 characters long, case insensitive.
\item[update interval] The minimum amount of time between updates of this
service.  Displayed as hh:mm:ss, but new values are input in minutes
only.  Setting the interval to 0 prevents {\bf dcm} updates.
\item[target file] Where on each server to put the file generated.
\item[script] Name of the script file on the moira server to be sent over to
the server and executed during the server update.  \athena\ This is
usually /moira/bin/{\em service}.sh.
\item[When last generated] This read-only field shows when data files for
this service were last generated.
\item[When last checked] This read-only field shows when the {\bf dcm} last
checked this service to see if it needed updating.
\item[type] Service type, used to determine how to deal with concurrency and
errors during the update.  \athena\ Types are UNIQUE and REPLICATED.
\item[enable/disable] This flag indicates if the {\bf dcm} should attempt
updates of this service.
\item[idle/inprogress] This read-only flag indicates if the {\bf dcm} is
currently generating data files for this service. 
\item[hard error/no error] This flag indicates that this service had an
error the last time an update was attempted.  It is set by the
{\bf dcm}, and may only be cleared by the user.
\item[error message] This field will contain the error if the {\em hard error}
flag is set.
\item[access control] This field consists of a type and a name.  If the type
is USER, the name must be a login name.  If the type is LIST, the name
must name a list.  The type may be NONE, in which case the name is
ignored.  A user on the access control list may reset service errors
and manipulate hosts supporting the service.
\end{description}

When the {\bf dcm} runs, it scans the services, finding those which are
enabled and do not have hard errors, and more than update interval
minutes have passed since the time data files were last generated for
this service.  For each of these services, it will set the time last
checked to now, then run the generator for that service.  The
generator for service {\em foo} is /moira/bin/{\em foo}.gen.  The
generator may be successful, in which case it leaves behind
/moira/dcm/{\em foo}.out and sets the time last generated.  It may
decide that the database is unchanged and not regenerate the
data files.  It may get a soft error, meaning that if the {\bf dcm} tries
again it may succeed.  It will record the soft error in the error
message field, but not set the hard error flag.  It may get a hard
error, in which case it sets the hard error flag and records the error
message.  While the {\bf dcm} is working on a service, it obtains an
exclusive lock on that service so that another {\bf dcm} running will
not also attempt to work on the same service.

Errors that occur during service updates are often caused by the
machine the moira server is running on running out of some resource,
such as swap space or maximum number of database locks.  These are not
always caught and marked as soft errors because they often cause the
generator program to exit with an unexpected status.  Also note that
the error message recorded with a failure may not be correct as only
the 8 least significant bits are passed from the generator to the
{\bf dcm}, which must guess as to what range that code was supposed to
fall into.  If the cause of an error is not immediately apparent,
check the log file /moira/dcm.log.

\subsection{Hosts to be updated}

For each host that supports a given service, moira contains the
following information:
\begin{description}
\item[service] Name of service this host is supporting.  This field is case
insensitive.
\item[host] Name of machine, which must already be known to moira.
\item[success/failure] This read-only flag indicates if the last attempted update was
successful or not.
\item[enable/disable] This flag indicates if updates should be attempted for
this host.
\item[override/normal] This indicates a priority on the next update.
Setting the override flag causes a {\bf dcm} to be started immediately,
and this service/host will be updated even if the service interval has
not yet passed.  This flag may be set by the user, but is only cleared
by the {\bf dcm}.
\item[inprogress/idle] This read-only flag indicates that an update is in
progress to this host.
\item[hard error/no error] This flag indicates that this host had an error
the last time an update was attempted.  It is set by the {\bf dcm}, and
may only be cleared by the user.
\item[error message] This field will contain the error if the {\em hard error}
flag is set.
\item[last time tried] This read-only field shows when the last update was
attempted.
\item[last time successful] This read-only field shows when the last
successful update was.
\item[value1] This integer field has a service-dependent value.
\item[value2] This integer field has a service-dependent value.
\item[value3] This 32 character string field has a service-dependent value.
\end{description}

As the {\bf dcm} scans the services, it will also scan the hosts
supporting each service that is enabled.  Before starting the host
scan, if the service is of type REPLICATED it gets a an exclusive lock
on that service and if it is of type UNIQUE it gets a shared lock.
After obtaining locks, it will check each host supporting that service
which is enabled, doesn't have a hard error, and hasn't been updated
since the last time the data files were generated for this service.
If the {\em override} flag is set, it will attempt the host even if it
has been updated since the data files were generated.  The {\bf dcm}
gets an exclusive lock on that host, then attempts the update.

The update consists of sending over the file /moira/dcm/{\em
service}.out from the moira server machine to the {\em target}
filename on the host, then sending over the {\em script} to a
temporary file and then executing the script.  If a soft error occurs,
the error message will be recorded and everything else left so that
the next {\bf dcm} pass will try again.  If a hard error occurs, the
hard error flag will be set as well.  If the service is of type
REPLICATED, the service will be marked with a hard error as well so
that no further updates will be attempted of the replicated service.
When debugging an update that fails for no apparent reason, the {\bf
test\_update} tool is often useful.\index{test\_update}

\index{mrcheck}
{\bf Mrcheck} will report on the status of updates.  If you purposely
disable a service or host, you will have to clear the state to get
{\bf mrcheck} to quit reminding you that this entry has been disabled.
Common errors to be on the watch for include network failures, the
hosts being down, and the hosts running out of disk space to accept
the update.  The error message may explain what went wrong, but when
in doubt check /moira/dcm.log on the moira server machine.

\index{sloc}\index{service location}
In addition to controlling updates, hosts supporting services are also
loaded into the nameserver with type {\em sloc}.  Thus querying hesiod
for (nfs, sloc) will return a list of the machines moira sends NFS
updates to.  If you want to put an {\em sloc} entry into the nameserver
without actually doing updates for that service, make an entry for the
service which is disabled, then entries for each of the hosts which
are enabled.  Most of the information will be ignored during updates,
and the nameservice will get the correct info.


\section{Database Maintenance}

\index{backups}
Backups are a part of regular database maintenance.  If your system
changes regularly, you should be doing daily backups of the moira
database.  You may do {\sc unix} backups of the database partition, DBMS
backups of the database, or use the programs provided with moira.  The
advantage to using the moira programs {\bf mrbackup} and {\bf mrrestore}
is that they save the database in an ASCII format which is easy to
work with and independent of the DBMS.  They also guarantee
consistency of the dump through the use of database transactions.

\index{mrbackup}
{\bf Mrbackup} is simple to run, taking only one argument indicating a
directory to put the backup in.   It will produce a file for each
table in the database.  These files contain a line for each record,
the lines consisting of vertical bar-separated fields.  \athena\ At
Athena, we run {\bf mrbackup} to another partition on the moira server,
and copy that backup over the net to two other machines.  The backups
are not regularly copied to tape, partly because the privacy-sensitive
information in the database would require keeping closer control on
those tapes than the regular user file backups.

\index{mrrestore}
In the event you ever need to restore a database, here are some
instructions on how to do that.
\begin{enumerate}
\item Login as root on the moira server.
\item Create an empty database named {\em moira}.
\item Run the {\em db/schema} script to create all of the tables in the
database.
\item Run {\bf mrrestore}, giving it an argument of the directory name
containing the backup.
\item Run the {\em db/dbopt} script to create all of the indexes on the
tables.
\item Skim the journal file and enter any changes needed between the time of
the last backup and when the database was lost.
\end{enumerate}

\subsection{Granting Privileges}
\index{privileges}

Each of the 130 queries has an access control list associated with it.
These lists are references to regular moira lists which may be
manipulated with the regular moira list tools (e.g. {\bf listmaint},
{\bf blanche}, etc).  If a user is on the ACL for a query, he can
perform that query on any data in the database.  Many queries also
have conditional ACLs based on the object of the query.  For example,
being on the ACL for {\tt get$\_$members$\_$of$\_$list} will allow you
to get the membership of any list, whereas without being on that ACL
you can still get the membership of any list of which you are an
administrator, or any list which is not hidden.

Some thought needs to be put into how you assign the query ACLs.  The
{\bf newmoira} program sets all of them to be the list {\em dbadmin} which
it sets up to contain each of the privileged users you name.  This
gives the users on this list all privileges, and denies any privilege
to other users.  Some queries are safe to be executed by anyone, and
there is a way to specify that: any list containing the user
``default'' is considered to have everyone as a member for the
purposes of checking query ACLs.  \athena\ They queries we have set
up this way are:
\begin{itemize}
\item get\_alias
\item get\_list\_is\_group
\item get\_list\_is\_maillist
\item get\_server\_host\_info
\item get\_server\_info
\item get\_server\_locations
\item get\_value
\item qualified\_get\_server\_host
\item qualified\_get\_server
\end{itemize}

Many queries you may want to set up with a larger ACL than just the
database administrators, but without everybody.  Because these are a
little difficult to change, have a rational plan in mind for setting
up ACLs rather than just assigning them as they are needed.  If you
want to continue having the people on {\em dbadmin} have full
privileges, then you will have to make sure that LIST dbadmin is a
member of each ACL that you change.

To set a query ACL:
\begin{enumerate}
\item Create a list to be the ACL, or choose an existing list.  For example,
``user-accts''.
\item Go into {\bf sql} on the moira server
\begin{quotation}\tt
\noindent sql moira
\end{quotation}
\item Find the {\em list\_id} of the list:
\begin{quotation}\tt
\noindent select list$\_$id from list where name='user-accts'$\backslash$g
\end{quotation}
\item Update the ACL for the desired query:
\begin{quotation}\tt
\noindent update capacls set list$\_$id$=${\it 1837} \\
where capability='get$\_$user$\_$by$\_$login'$\backslash$g
\end{quotation}
\item Send the {\bf moirad} a SIGUSR1 followed by a SIGUSR2 to make it
dump its cache and re-read the access information.
\end{enumerate}

\subsection{ID Number Allocation}

\index{ID Number}
Moira handles a number of different kinds of ID numbers, both for its
own use internally and externally visible ones like UIDs and GIDs.
There are entries in the {\em numvalues} table for each ID number
indicating the next number to be allocated.  When moira needs another
number, it reads the current value out of the numvalues table, and
checks to see if that ID is in use.  If not, it increments the value
stored in the numvalues table and uses the old value.  If that value
was already in use, it increments the value and checks the next one.
For the UID and GID, each time it increments the value, it compares it
with the maximum ID, 32765.  If it has reached this, it sets the value
to 100 and continues from there.  Other internal ID numbers have no
set upper limit.

This is usually fast to assign ID numbers.  However, if the assignment
value has wrapped and it must do many unsuccessful checks before it
finds a number to use, this may take a while.  You may set the value
in the numvalues table if you want to change the range that ID numbers
are being assigned in.

\subsection{Type Allocation}

\index{Types}
A number of the fields in the database are type-checked against a list
of legal values also stored in the database.  These are stored in the
alias table as aliases of type TYPE.  The {\bf moira} client will
automatically assign new values if the user insists that he really
wants to add a new legal value.  The database administrator may
occasionally want to clean up the values and delete ones no longer in
use.  This is done by scanning the output of the query
\begin{quotation}\tt
get$\_$alias * TYPE *
\end{quotation}
and deleting any aliases that shouldn't be there.

\theindex
\addcontentsline{toc}{chapter}{Index}
\input{index.sort}

\end{document}
