pd.if.org Git - startuptools/blob - scripts/README

   1 These scripts are intended to handle both boot time and run-time management of
   2 system services and general configuration.
   3
   4 In general, the philosophy is to be as simple as possible.  The admin who has
   5 to debug a boottime or service start up script that he hasn't looked at in a
   6 year and a half and that was set up by his predecessor anyway doesn't want
   7 something that can't be understood with a basic knowledge of init, the shell,
   8 and a couple of man pages.
   9
  10 A system administrators accumulated knowledge should also be respected as far
  11 as possible.  There is no point in throwing away years of experience merely for
  12 the sake of being different.  Further, the system should follow, as much as
  13 possible the principle of least surprise.
  14
  15 Where possible, configuration scripts should be simple /bin/sh compatible files
  16 that do nothing other than set variables and do not call any programs.  This
  17 allows other scripts to simply source them without any complicated parsing.
  18
  19 However, where existing tools use configuration files that don't adhere to that
  20 principle, those files and tools should continue to be used unchanged.  As
  21 examples, /etc/fstab, /etc/sysctl.conf.
  22
  23 In keeping with the above, these scripts work as follows:
  24
  25 Run-levels are little used, and so they will be kept to doing
  26 as little as possible.  This system uses the following:
  27
  28 Run Level S: single user mode
  29 Run Level 1: also single user mode
  30 Run Level 2: multi user mode, but with as little running as might be needed for
  31 maintaining the box.  Typically this will be networking and sshd, but nothing
  32 else.  For some systems even these may not be needed.
  33
  34 Run Level 3: This is the normal "everything running" level.
  35 Run Level 6: System shutdown
  36
  37 No other run levels are used, though a system admin could set them up if
  38 needed.
  39
  40 System Scripts
  41 --------------
  42
  43 These scripts live in /etc
  44
  45 fstab: lists filesystems, this file is not changed from it's usual format, and
  46 is used as such
  47
  48 rc.sysinit: done once at start time.  responsible for performing any necessary
  49 early system initialization.  This reads rc.conf for some of its actions
  50
  51 * do any boot time /tmp cleanup or similar
  52 * fsck and mount filesystems
  53 * load any kernel modules needed
  54 * set the host name
  55 * set up /dev (via udev on modern linux systems)
  56 * sysctl
  57 * do any utmp/wtmp initialization needed
  58 * configure the console
  59 * set timezone and clock
  60
  61 Since all of this has to be done before we do anything else, and the order
  62 won't generally change, this can and should be a single script.
  63
  64 rc.multi: brings up the system into multi user mode.  reads rc.conf
  65
  66 * start any startup scripts listed in DAEMONS
  67
  68 rc.conf:
  69
  70 responsible for setting variables used by other scripts.  this script will be
  71 sourced by several other scripts and thus shouldn't actually perform any
  72 actions of its own.  It can call other programs if needed to set variables, but
  73 this should be minimized (e.g. it could cat /etc/hostname to set the HOSTNAME
  74 variable, but shouldn't actually set the hostname, and it would be better to
  75 just set the hostname directly)
  76
  77 DAEMONS: a set of scripts from /etc/rc.d/init.d to run.  These will
  78 be run in the order listed.
  79
  80 HOSTNAME: the system hostname to set.
  81
  82 TZ: the system time zone
  83
  84 Robustness
  85 ----------
  86
  87 Each daemon start-up script should register somehow the fact that it is running
  88 and started.  A monitoring daemon then should be run *out of init* to check
  89 these daemons and restart them if they crash.  If the monitor is not run from
  90 init, it could itself crash.  This should perhaps be run level 4 for this
  91 daemon.  Ideally, nothing would be run as a daemon and init could handle the
  92 monitoring itself, but this would be a major change to the usual practice.