From 7e9c0286fb67a9b158a75463450f8d3e1bf898dd Mon Sep 17 00:00:00 2001 From: Nathan Wagner Date: Fri, 26 Apr 2013 09:55:53 +0000 Subject: [PATCH] reformatting for 80 column width --- scripts/README | 95 +++++++++++++++++++++++--------------------------- 1 file changed, 44 insertions(+), 51 deletions(-) diff --git a/scripts/README b/scripts/README index d5a3d63..6e6e05d 100644 --- a/scripts/README +++ b/scripts/README @@ -1,27 +1,24 @@ -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. +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: @@ -30,28 +27,26 @@ 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 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. +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 +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 +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 @@ -63,9 +58,8 @@ of its actions * 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. +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 @@ -73,12 +67,12 @@ rc.multi: brings up the system into multi user mode. reads rc.conf 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) +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. @@ -90,10 +84,9 @@ 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. +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. -- 2.40.0