Contents:

A) What you need

B) The default install locations and its defense

C) Default installation

D) Using DESTDIR

E) What to do after installation

F) Configuration of the installation

G) A sample configuration


A) What you need
================

To use this package, you need the following packages

-- daemontools >= 0.76. Get it from

   http://cr.yp.to/daemontools.html

-- runlevelconf >= 0.07.  Get the tarball from

   ftp://moni.csi.hu/pub/run/

If you want to install the qmail run scripts, you need 

-- qmail.  Get it from

   http://cr.yp.to/qmail.html

-- bash (I think POSIX compatible sh should work---it does on
   GNU/Linux) Please see the notes on the configuration item "MYSHELL"
   in section F), "Configuration of the installation"


B) The default install locations and its defense 
================================================

First, let me defend my choice of the default locations of the
package.  Dan Bernstein's recent packages (publicfile, dnscache) come
with a configuration program that installs the programs's config and
log directories under the same directory.  Rather than making all
kinds of symlinks to satisfy the local file system requirements for
log directories and config files, I decided to go along with Dan's
design. 

So this package uses the following main locations

1) A service's run and log run files are placed (or expected to be) in 

   /var/service/`service'/

   and

   /var/service/`service'/log
   
   respectively. The "main" log directory for multilog is

   /var/service/`service'/log/main

   If you have a service set up in a different location, you need to
   make a symlink in /var/service/.  So, for example, if you
   configured publicfile with a `public' directory, /public, so you
   have

   /public/httpd/
   /public/ftpd/

   then you need to make the symlinks

   ln -s /public/httpd /var/service
   ln -s /public/ftpd /var/service

2) `svscan's service directory is /service.

3) The run file of svscan (since svscan is "supervised") is put in 

   /var/service/svscan/

4) This packages's initscripts and the related config and sh function
   files go to

   /var/service/dt-run/

5) While multilog's configuration is pretty easy, two features 
   --namely, log filesize and number--- can be configured in files
   placed in

   /var/service/multilog/

6) Executables are placed in 

   /package/admin/dt-run-11.07/command

   and linked in /command.

C) Default installation
========================

First, I have to say this, because it may not be clear to many people:
if you already have svscan running in the /service directory, you need
to stop it, and clear this directory.  

First, unpack the tarball with 

gunzip dt-run-11.07.tar.gz
tar -xvf dt-run-11.07.tar

or, with GNU tar, just

tar zxvf dt-run-11.07.tar.gz

Then go to the top directory, `dt-run-11.07'.

You can install the  various components of the package as follows:

1) to install the basic components of the package, do

   make ibase

   This is a mandatory step, and it installs the init files
   dt-svscan.init and dt-runlevel.init in

   /var/service/dt-run/

   along with some shell function and config files.
   Also, the directory 

   /service/
   
   is created if it does not  yet exist.  

   By the way, the directory /var/service/ probably already exist on
   your system, since you installed the runlevelconf package...

   Finally, two programs, add-service.sh and remove-service.sh, are
   placed in

   /package/admin/dt-run-11.07/command

   and linked in /command.


3) To install the run scripts for the qmail services including
   rblsmtpd, do

   make iqmail

   This command will fail, if you do not have qmail installed, or at
   least the qmail loguser, qmaill.
 
   The command also sets up the directory

   /var/service/qmail/defaultdelivery/

   with the files containing various defaultdelivery instructions in
   them.  The file,

   /var/service/qmail/defaultdelivery/rc

   contains the defauldelivery the qmail run file uses to tell qmail
   the default mailbox location.

4) To install the run scripts for some other services, such as rlogin,
   telnetd, wuftpd, proftpd, rsync, etc., first you need to add the
   loguser, dtlog:

   useradd -r dtlog

   or whatever works on your system.  Then run
		    
   make ibase

   For example, this sets up

   /var/service/telnetd/run
   /var/service/telnetd/log/run
   /var/service/telnetd/log/main/

   
If you are happy with the default installation, you can go and read
the section `What to do after installation' and then MANUAL for usage
info.


D) Using DESTDIR
================

If you first want to install the package in a temporary location to
check out where things get installed without worrying about your
running system, just do, for example,

echo /tmp/dt-run-root > config/DESTDIR

This sets the DESTDIR variable for the install.sh script. After this
step, any of

make ibase
make iui
make iqmail
make iother

will install as if `/' was /tmp/dt-run-root/.

Note that you can run the commands

make ibase
make iqmail
make iother

in any order you want, so you can see what the installation does for
each separately.

When you are ready to install permanently, do 

make destdir  # removes $DESTDIR
rm config/DESTDIR
make ibase [iui] [qmail] [other]

Please note that while you can install under DESTDIR as nonroot, but
you must be root to install the programs in their final location.


E) What to do after installation
================================

If you want to use qmail, I am assuming you already set up the
links[s] to qmail's sendmail, and set up the three basic qmail
aliases.  This means, on GNU/Linux systems, you need to do

ln -s /var/qmail/bin/sendmail /usr/lib/sendmail
ln -s /var/qmail/bin/sendmail /usr/sbin/sendmail

( 
cd ~alias/
for i in .qmail-postmaster .qmail-mailer-daemon .qmail-root; do
   touch $i
   chmod 644 $i
   chown alias.nofiles $i
done
)
 
Now let us start svscan.  While this can be done by hand with 

/var/service/dt-run/dt-svscan.init start

eventually, the above is run from inittab, so unless you are in single
user mode, let us get over with editing inittab.  

####Remark: I have no root access to any other system but RH
####GNU/Linux, so I welcome any info on how to edit inittab on various
####systems to make the package work.  For example, it seems to me
####that on Solaris, one cannot even have comment lines in
####inittab---only in the command section can one include a little
####comment. Also, I see some complicated redirections to /dev/console
####of the output of the /sbin/rc? scripts.

Find the lines in inittab which start the rc file at the various
runlevels.  On RH Linux, you have

l0:0:wait:/etc/rc.d/rc 0
l1:1:wait:/etc/rc.d/rc 1
l2:2:wait:/etc/rc.d/rc 2
l3:3:wait:/etc/rc.d/rc 3
l4:4:wait:/etc/rc.d/rc 4
l5:5:wait:/etc/rc.d/rc 5
l6:6:wait:/etc/rc.d/rc 6

Now put the lines

### stop dt-run
rK:016:wait:/var/service/dt-run/dt-runlevel.init stop
sK:016:wait:/var/service/dt-run/dt-svscan.init stop
### End stop dt-run

*before* the "rc" lines, and put the lines

### start dt-run 
sS:2345:wait:/var/service/dt-run/dt-svscan.init start
r2:2:wait:/var/service/dt-run/dt-runlevel.init start
r3:3:wait:/var/service/dt-run/dt-runlevel.init start
r4:4:wait:/var/service/dt-run/dt-runlevel.init start
r5:5:wait:/var/service/dt-run/dt-runlevel.init start
### End start dt-run

*after* the `rc' lines.  Of course, you would have to change the
runlevels to suit your system.  The point is that in `single user
mode' (1 above), `halt mode' (0 above) and `reboot mode' (6 above),
the dt init scripts should be stopped, and started on the other
runlevels (2, 3, 4, 5 above).

So, now you have something similar to 

### stop dt-run
rK:016:wait:/var/service/dt-run/dt-runlevel.init stop
sK:016:wait:/var/service/dt-run/dt-svscan.init stop
### End stop dt-run

l0:0:wait:/etc/rc.d/rc 0
l1:1:wait:/etc/rc.d/rc 1
l2:2:wait:/etc/rc.d/rc 2
l3:3:wait:/etc/rc.d/rc 3
l4:4:wait:/etc/rc.d/rc 4
l5:5:wait:/etc/rc.d/rc 5
l6:6:wait:/etc/rc.d/rc 6

### start dt-run 
sS:2345:wait:/var/service/dt-run/dt-svscan.init start
r2:2:wait:/var/service/dt-run/dt-runlevel.init start
r3:3:wait:/var/service/dt-run/dt-runlevel.init start
r4:4:wait:/var/service/dt-run/dt-runlevel.init start
r5:5:wait:/var/service/dt-run/dt-runlevel.init start
### End start dt-run

If you now run

telinit q

or 

init q

you should have svscan running.  You can check by running

/var/service/dt-run/dt-svscan.init status

and you should get svstat's output

/var/service/svscan: up (pid 6361) 38 seconds, normally down

Now decide which services you want to run under svscan.  For some of
the services, it is appropriate to set up tcprules files.  Keep in
mind, that the run files of the default installation expects the
`.cdb' files to be

/var/service/`service'/tcprules.cdb

so, for example,

/var/service/rblsmtpd/tcprules.cdb

There are three kinds of services to be run under svscan:

First kind: the dt-run package installed run files for it.

Second kind: you will install run files for it, and the add-service.sh
	     script knows about the service.

Third kind: you will install run files for it, and you will tell the
	    add-service.sh script about the service.

You can find out which services add-service.sh knows about by doing

add-service.sh list

Presently, the output is

axfrdns
dnscache
fingerd
ftpd     # intended for publicfile's
httpd    # intended for publicfile's
proftpd
rlogind
rshd
rsync
qmail
qmail-pop3d
qmail-smtpd
qmail-qmtpd
qmail-qmqpd
pickdns
rbldns
rblsmtpd
telnetd
tinydns
walldns
wuftpd

Of these,

fingerd
ftpd     # intended for publicfile's
httpd	 # intended for publicfile's
proftpd
rlogind
rshd
rsync
qmail
qmail-pop3d
qmail-smtpd
qmail-qmtpd
qmail-qmqpd
rblsmtpd
telnetd
wuftpd

are of the first kind.

For a service of the first kind, you can do the following.  Suppose
you want to run qmail, qmail-smtpd and telnetd.  Then you do (assuming
add-service.sh is in your $PATH) 

add-service.sh qmail qmail-smtpd telnetd

No later than 5 seconds, all the supervises for these services should
start. If the current runlevel is such that a service should run at
it, then the service will also be started.  For example, with the
default configuration of add-service.sh, if the present runlevel is 2,
then only qmail will be started.  If the current runlevel is 3, all
three services will be started.

You can check if the services are running using `service.init status
'; for example at runlevel 2, I see

qmail.init status
/service/qmail: up (pid 7099) 168 seconds

qmail-smtpd.init status
/service/qmail-smtpd: down 171 seconds

telnetd.init status    
/service/telnetd: down 182 seconds

You can do many other things with `service.init'; among others, you
can stop/start `service'.  (Often, it is more convenient to use `svc'
than `service.init', but for some functions, like start and stop, you
get nice dressing in `service.init')

For a service of the second kind, you need to set up the run files for
the service and its log.  Make sure that the run files are

/var/service/`service'/run
/var/service/`service'/log/run

For example, to set up the run files for dnscache, you would run
something like

dnscache-config dnscache dtlog /var/service/dnscache

If the run files are already set up at a different location, you need
to make a link in /var/service.  For example, 
  
ln -s /public/httpd /var/service

Once the run files are in the correct location, just run
add-service.sh as above.

For a service of the third kind, say linuxconf (I have no idea if you can
run linuxconf from a run file), once you set up the runfiles, you put an
entry of the form

linuxconf:2,3,4,5:

in the file /var/service/dt-run/dt-list.  This says, 

-- the service's name is `linuxconf'; 

-- linuxconf should be run at runlevels 2, 3, 4,5

-- linuxconf does not depend on other services for startup (this is
   why you do not see anything after the last colon `:').

Now you can run add-service.sh.

WARNING: add-service.sh and remove-service.sh do not enable/disable
	 services for inetd anymore; you have to do this by hand.
	 This is because many Linuces support xinetd, and I am not
	 sure at this point if I can reliably deal with inetd/xinetd
	 anymore.

Configuration of the installation
=================================

The configuration of the installation is done in the files
config/*. The first line is the only line of a config file which is
read (by myenvdir.sh), and in most files you see comments on what the
contents of the first line is used for.  You can easily change a
configuration without even opening the appropriate config file.  For
example, you can do

echo /etc/multilog > config/DLOGCONFDIR

if you want to put the multilog's filesize and fileno files in
/etc/multilog/. 

The original configuration files are in original-config/.

Here are the major configuration items:

MYSHELL=/bin/bash: The shell to be used in all the scripts.  I am
		   interested in how to make other shells work.  At
		   this point, I specify bash, but I thought the only
		   non-POSIX operator I am using is $[a+b]---which is
		   OK with zsh.
		   
		   In general, /bin/sh should work if linked to bash.

		   On Linux:
		 - zsh-3.0.7-2 did not work for me even if I link it
		   to sh. It seems to have problems with sourcing with
		   `.' from a file that is already sourced.
		 - pdksh-5.2.14-1 does not work even if I link it to
		   sh. I think because pdksh cannot source files using
		   the syntax `. file' -- but could be just this version.  

		 Does  "standard" (commercial) ksh work.

RUNLEVEL=$(/sbin/runlevel | cut -d' ' -f2): the command between `$('
			  and `)' should give the current runlevel.
			  The proper output is absolutely essential
			  for the proper function of the runlevel
			  changer, dt-runlevel.init.

RUNLEVELCONF_BIN=/command: the executables from the runlevelconf
			   package should be available in this
			   directory.

RUNLEVELCONF=/var/service/runlevelconf: this must be the same as
					RUNLEVELCONF was when you
					installed the runlevelconf
					package. 

VARSERVICEROOT=/var/service: this is where services's directories with
			     the run files in them are expected.

PATH=/command:/bin:/usr/bin:/usr/sbin : we expect basic system
					utilities, such as `awk'
					`grep' to be found here.
					Also, we expect basic daemons,
					such as telnetd, to be found
					here.  This latter path
					component is only needed if
					you want to install the
					"other" services's run files.

UCSPI_TCP_BIN=/usr/local/bin: this is where tcpserver is located.

QMAIL_BIN=/var/qmail/bin: qmail's binaries are here.

SLOGMAIN=main: multilog's main directory.  If it does not start with
	       `/', then it is relative to

	       $VARSERVICEROOT/$SERVICE/log

	       so, for example, it would be 

	       /var/service/qmail/log/main 

	       with the default configuration.  If you put

	       /var/log/$SERVICE/main

	       then you'd get 

	       /var/log/qmail/main
	       

In the files in config/ with no capitals in their name, with the
exception of checkpassword, you can configure what command starts a
given service in its run file.  For example, wuftpd's default run file
is

#! CONFMYSHELL
exec 2>&1

CDB="/var/service/wuftpd/tcprules.cdb"
PORT="ftp"
USER="root"
PATH=/usr/local/bin:/bin:/usr/bin:/usr/sbin; export PATH
COMMAND="in.ftpd -l -a"

exec envuidgid $USER \
tcpserver -v -c40 -UX -x$CDB \
0 $PORT $COMMAND

In config/wuftpd, the first line is

in.ftpd -l -a:ftp

Now if you do

echo '/usr/local/sbin/in.ftpd -a:1010' > config/wuftpd

and, for illustration, you also do

echo '/etc/$SERVICE.cdb' > config/CDB

then wuftpd's run file will be

#! CONFMYSHELL
exec 2>&1

CDB="/etc/wuftpd.cdb"
PORT="1010"
USER="root"
PATH=/usr/local/bin:/bin:/usr/bin:/usr/sbin; export PATH
COMMAND="/usr/local/sbin/in.ftpd -a"

exec envuidgid $USER \
tcpserver -v -c40 -UX -x$CDB \
0 $PORT $COMMAND

Of course, you can always change a run file after installation...

The files starting with `q' are the config files for the qmail
services, but the actual service name is changed by replacing `qmail-'
by `q'; so `qsmtpd' is, in fact, qmail-smtpd's file (reason: all the
filenames in config are env variables...).

G) Sample configurations

GNU/Linux
*********

If you want to do an installation that conforms to the Linux FSS, more
or less you would do

echo /etc                       > config/VARSERVICEROOT
echo /etc/multilog              > config/DLOGCONFDIR
echo /usr/dt-run                > config/DTRUNCONF
echo /var/lib/runlevelconf      > config/RUNLEVELCONF # also installing
                                                      # runlevelconf!
echo '/var/log/$SERVICE/main'   > config/SLOGMAIN
echo /etc/svscan                > config/SVSCANCONF

This is not perfect, since some of the stuff in $RUNLEVELCONF and
$DTRUNCONF should go to /usr/lib, /usr/share, /etc...

I see the point in using autoconf, and I see why djb puts stuff in one
place. 

Solaris:
********

...

Suggestions?  Please test thoroughly; I have limited (meaning: no
root) access to a Solaris box, and I have no access to anything else.
So your suggestions will be written down here verbatim.
