.SH DESCRIPTION
The
.B dcm
-must be run periodically on the Moira server. It is usually run every
-15 minutes by the
-.I cron
-daemon. Rather than invoke
+must be run periodically on the Moira server. Rather than invoke
.B dcm
-directly, cron runs
+directly, one generally runs
.B startdcm,
which starts the dcm running in the proper working directory and
captures logging messages.
.I /etc/nodcm
or by setting the value of
.I dcm_enable
-to zero in the Moira database. Debug mode may be enabled in the dcm by
-specifying an integer on the command line or by setting the
-environment variable
-.B DEBUG.
-The command line value will override the environment variable. Three
-bits are currently defined in the debug value: DBG_PLAIN = 01,
-DBG_VERBOSE = 02, DBG_TRACE = 04. Logging is done to standard output.
+to zero in the Moira database. Logging is done to standard output.
If critical errors are detected, they are logged to
-.B /u1/sms/critical.log
+.B /moira/critical.log
and in a zephyrgram to class
.B Moira
instance
.B DCM
in addition to standard output.
-For the
-.B dcm
-to function properly,
-.I root
-must both be authorized to access each of the tables by RTI Ingres,
-and on the query acls for each of the queries the
-.B dcm
-will execute.
.PP
For the actual generation of config files, the
.B dcm
will fork off generator programs of the form
-.B /u1/sms/bin/\fIservice\fB.gen.
+.B /moira/bin/\fIservice\fB.gen.
Each generator takes as an argument the name of the output file to
produce. Many of them also require working directories in
-.B /u1/sms/dcm/\fIservice\fB.
+.B /moira/dcm/\fIservice\fB.
A generator exits with a status code defined in
.I <mr_et.h>.
In particular,
.B startdcm
sets its working directory to the root, disconnects from the terminal
and puts itself in the background. It then starts
-.B /u1/sms/bin/dcm,
+.B /moira/bin/dcm,
and will capture lines the dcm writes to standard output and log them
in
-.B /u1/sms/dcm.log
+.B /moira/dcm.log
along with a timestamp.
.B startdcm
will also log the exit status of the
.B dcm
if it is non-zero.
.SH FILES
-/u1/sms/dcm.log
+/moira/dcm.log
.br
-/u1/sms/critical.log
+/moira/critical.log
.br
-/u1/sms/dcm/locks/* \- empty files will be created here for advisory locks.
+/moira/dcm/locks/* \- empty files will be created here for advisory locks.
.br
-/u1/sms/bin/*.gen \- service file generators will be searched for
+/moira/bin/*.gen \- service file generators will be searched for
here.
.br
/tmp/tkt_dcm \- temporary Kerberos ticket storage.
.br
-/etc/srvtab \- The dcm must be able to get Kerberos tickets for "sms"
+/etc/athena/srvtab \- The dcm must be able to get Kerberos tickets for "sms"
(null instance).
.SH "SEE ALSO"
The Project Athena Technical Plan section on Moira.
which is compiled into the file
.I mr_srvdata.c.
If critical errors are detected, they are logged to
-.B /u1/sms/critical.log
+.B /moira/critical.log
and in a zephyrgram to class
.B MOIRA
instance
.B MOIRA
in addition to standard output.
Also, a journal file is kept in
-.B /u1/sms/journal
+.B /moira/journal
logging every successful change of the database in a format that can
be replayed by
.I mrtest(8).
For the server to be able to function properly, if must be run as root
-and root must have access to the tables through RTI Ingres.
+and root must have access to the tables in the DBMS.
.PP
It is possible to shutdown the database side of the server when it is
necessary to lock out clients. In this state the server will only
file are returned as the Moira motd.
.PP
.B startmoira
-sets its working directory to the root, disconnects from the terminal
+sets its working directory to /, disconnects from the terminal
and puts itself in the background. It then starts
-.B /u1/sms/bin/moirad,
+.B /moira/bin/moirad,
and will capture lines the server writes to standard output and log them
in
-.B /u1/sms/moira.log
+.B /moira/moira.log
along with a timestamp.
.B startmoira
will also log the exit status of the
.B moirad
if it is non-zero.
.SH FILES
-/u1/sms/moira.log
+/moira/moira.log
.br
-/u1/sms/critical.log
+/moira/critical.log
.br
-/u1/sms/journal
+/moira/journal
.br
/etc/smsdown
.br
-/etc/srvtab \- The server must be able to get Kerberos tickets for
+/etc/athena/srvtab \- The server must be able to get Kerberos tickets for
"moira.[servername]".
.SH "SEE ALSO"
The Project Athena Technical Plan section on Moira.
.PP
Logging is done to standard output.
If critical errors are detected, they are logged to
-.B /u1/sms/critical.log
+.B /moira/critical.log
and in a zephyrgram to class
.B MOIRA
instance
.B REG_SVR
in addition to standard output.
Also, a journal file is kept in
-.B /u1/sms/journal.reg
+.B /moira/journal.reg
logging every successful change of the database in a format that can
be replayed by
.I mrtest(8).
For the server to be able to function properly, if must be run as root
-and root must have access to the tables through RTI Ingres. Also,
+and root must have access to the tables in the DBMS. Also,
Kerberos principal "moira.[servername]" must be on the Kerberos admin
server ACL to create new principals and set their passwords.
.PP
.B startreg
sets its working directory to the root, disconnects from the terminal
and puts itself in the background. It then starts
-.B /u1/sms/bin/reg_svr,
+.B /moira/bin/reg_svr,
and will capture lines the server writes to standard output and log them
in
-.B /u1/sms/reg_svr.log
+.B /moira/reg_svr.log
along with a timestamp.
.B startreg
will also log the exit status of the
.B reg_svr
if it is non-zero.
.SH FILES
-/u1/sms/reg_svr.log
+/moira/reg_svr.log
.br
-/u1/sms/critical.log
+/moira/critical.log
.br
-/u1/sms/journal.reg
+/moira/journal.reg
.br
.br
/tmp/tkt_ureg \- temporary Kerberos ticket storage.
.br
-/etc/srvtab \- The dcm must be able to get Kerberos tickets for
+/etc/athena/srvtab \- The dcm must be able to get Kerberos tickets for
"moira.[hostname]".
.SH AUTHORS
Jay Berkenbilt, Bill Sommerfeld
andersk / moira.git / commitdiff
