X-Git-Url: https://pd.if.org/git/?a=blobdiff_plain;f=scripts%2FREADME;fp=scripts%2FREADME;h=d5a3d63083f686da4227f3031be5a71ab3096d64;hb=9ea1bff7b049ce152767460c68bb61f6aa500cef;hp=0000000000000000000000000000000000000000;hpb=f0735327127a921d3ee96f51b84f23208bc6f445;p=startuptools

diff --git a/scripts/README b/scripts/README
new file mode 100644
index 0000000..d5a3d63
--- /dev/null
+++ b/scripts/README
@@ -0,0 +1,99 @@
+These scripts are intended to handle both boot time and
+run-time management of system services and general configuration.
+
+In general, the philosophy is to be as simple as possible.  The
+admin who has to debug a boottime or service start up script
+that he hasn't looked at in a year and a half and that was set
+up by his predecessor anyway doesn't want something that can't
+be understood with a basic knowledge of init, the shell, and
+a couple of man pages.
+
+A system administrators accumulated knowledge should also be
+respected as far as possible.  There is no point in throwing
+away years of experience merely for the sake of being different.
+Further, the system should follow, as much as possible the
+principle of least surprise.
+
+Where possible, configuration scripts should be simple /bin/sh
+compatible files that do nothing other than set variables
+and do not call any programs.  This allows other scripts
+to simply source them without any complicated parsing.
+
+However, where existing tools use configuration files that don't adhere
+to that principle, those files and tools should continue to be used
+unchanged.  As examples, /etc/fstab, /etc/sysctl.conf.
+
+In keeping with the above, these scripts work as follows:
+
+Run-levels are little used, and so they will be kept to doing
+as little as possible.  This system uses the following:
+
+Run Level S: single user mode
+Run Level 1: also single user mode
+Run Level 2: multi user mode, but with as little running as
+might be needed for maintaining the box.  Typically this
+will be networking and sshd, but nothing else.  For some
+systems even these may not be needed.
+
+Run Level 3: This is the normal "everything running" level.
+Run Level 6: System shutdown
+
+No other run levels are used, though a system admin could
+set them up if needed.
+
+System Scripts
+--------------
+
+These scripts live in /etc
+
+fstab: lists filesystems, this file is not changed from it's usual
+format, and is used as such
+
+rc.sysinit: done once at start time.  responsible for performing any
+necessary early system initialization.  This reads rc.conf for some
+of its actions
+
+* do any boot time /tmp cleanup or similar
+* fsck and mount filesystems
+* load any kernel modules needed
+* set the host name
+* set up /dev (via udev on modern linux systems)
+* sysctl
+* do any utmp/wtmp initialization needed
+* configure the console
+* set timezone and clock
+
+Since all of this has to be done before we do anything else,
+and the order won't generally change, this can and should be
+a single script.
+
+rc.multi: brings up the system into multi user mode.  reads rc.conf
+
+* start any startup scripts listed in DAEMONS
+
+rc.conf:
+
+responsible for setting variables used by other scripts.  this script will
+be sourced by several other scripts and thus shouldn't actually perform
+any actions of its own.  It can call other programs if needed to set variables,
+but this should be minimized (e.g. it could cat /etc/hostname to set the HOSTNAME
+variable, but shouldn't actually set the hostname, and it would be better to just
+set the hostname directly)
+
+DAEMONS: a set of scripts from /etc/rc.d/init.d to run.  These will
+be run in the order listed.
+
+HOSTNAME: the system hostname to set.
+
+TZ: the system time zone
+
+Robustness
+----------
+
+Each daemon start-up script should register somehow the fact that it
+is running and started.  A monitoring daemon then should be run *out of init*
+to check these daemons and restart them if they crash.  If the monitor
+is not run from init, it could itself crash.  This should perhaps be
+run level 4 for this daemon.  Ideally, nothing would be run as a daemon
+and init could handle the monitoring itself, but this would be a major
+change to the usual practice.