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.