There are seven runlevels numbered 0 through 6, five of which have fairly well-defined uses:
On our system, runlevels 3 and 5 are identical and runlevel 2 does not include networking or gpm. Runlevel 4 will be used to run servers later in the course (and for experimentation below).
The services which are run for each runlevel are specified in directories /etc/rc.d/rc#.d/, where "#" is the runlevel. The "files" in the runlevel directory are symbolic links to scripts in /etc/rc.d/init.d. The names are of the form "Snndaemon" or "Knndaemon", where S means start this daemon in this runlevel, and K means kill this daemon before starting this runlevel, and nn is a number used to order the kills and starts. When a runlevel is started, the kill scripts are run in alphabetical order, and then the start scripts are run, also in alphabetical order.
When booting, init first runs the scripts in /etc/rc.d/rcS.d. For our system, these:
init then runs the scripts for the specific runlevel as described above. For instance, in runlevel 3, they:
The above init strategy makes it particularly easy to restart services: one simply re-runs the script. For example, to change the IP address, the system administrator need only modify the correct configuration files and run /etc/rc.d/init.d/network restart. Rebooting should never be necessary, except if a different kernel needs to be run, an extremely rare kernel panic occurs, or a power failure occurs.
A limited ability to tailor the startup of Windows is available through the msconfig command.Note that some of the startup scripts log to /var/log/boot.log and not to /var/log/sys.log.
System administrators often put all of their local modifications in a single script, which is usually run just before init starts the agetty processes. To do this, one could create the script /etc/rc.d/init.d/local and then link it to the appropriate run level directories using, for instance, ln -s /etc/rc.d/init.d/local /etc/rc.d/rc3.d/S99local.
Windows uses the "registry" to hold configuration information, but it is nearly impossible to modify it in a "safe" way other than through control panels which do much to hide the workings of the system from the curious. Registry failure is generally a catastrophic event, while text file failure only affects the particular file involved.
When booting from the DVD-ROM, our distribution interactively prompted you to configure the following files (from /etc/rc.d/init.d/netconfigure):
(your host's IP address) (your host's full domain name) (your host's alias)
nameserver (your DNS server's IP address)
HOSTNAME=(your host's name)Notice that the contents of this file (as well as the one following and many other configuration files in a UNIX environment) resemble shell commands used to set environment variables; that is exactly what they are (they are included in startup scripts at run time); in Windows, the SET command is used to create environment variables;
The name of the NIC is modified at startup according to its physical hardware address, so that the same IP address is assigned to the same NIC on each boot.Minimal contents of the ifconfig.xyz file are:
IFACE=xyzThis is a good place to remind you that UNIX is case-sensitive!
IP=(the IP address for xyz)
PREFIX=(the number of bits in the network portion of the IP address for xyz)
GATEWAY=(your gateway's IP address)
BROADCAST=(the broadcast address for xyz)
A common technique is to use symbolic links for devices for increased flexibility. For instance, you could link /dev/flash to /dev/sdc1 with ln -s /dev/sdc1 /dev/flash and change the /media/usbstg line's device entry from /dev/sdc1 to /dev/flash. By using a symbolic link in fstab instead of a specific device, changes in hardware configuration will not require another change in fstab (or in any scripts); simply delete the old /dev/flash link and make a new one as appropriate. Other common links are /dev/cdrom and /dev/dvd.
Do all of your telinits at the command line, while X-windows is not running. Otherwise, you will not see everything you are supposed to see.Examine your path, the working directory and the processes currently running. Submit your results to the instructor (include only non-kernel processes).
An easy way to save the results of your investigations is to append them to a text file using the syntaxcommand >> file.txtIf file.txt does not exist, it will be created, and each subsequent command used this way will append its output to the file.
Telinit to runlevel 4.
Writing a script is easier than you might think. Open emacs and type #!/bin/sh and push the Enter key. This tells the system that you want to use bash to process this script. If you know Perl or Ruby or Python, you could write a script in those languages as well, and the sh-bang line would be "#!/usr/bin/perl", or etc.Finally, link it to the startup directory using the command ln -s /etc/rc.d/init.d/local /etc/rc.d/rc3.d/S99local. When you telinit 3 from runlevel 4, or during startup, your script should execute automatically.
Next open an xterm window and test the first command you want in your script. In this case it might be an "echo" command to display some text output (Windows also supports echo). When it does what you want it to, copy and paste the final version of the command into the emacs window and press Enter again.
Continue in this way until your script is complete. Save the script, in this case as /etc/rc.d/init.d/local, and then enter the command chmod 744 /etc/rc.d/init.d/local to allow the shell to execute it as a script. (More about this next week.)
You can now test the script by typing its name (/etc/rc.d/init.d/local) at the command prompt.This process should also work in Windows, except that the sh-bang and chmod are not necessary. The sh-bang is really not necessary in Linux, as long as you want bash to run the script.
When you do that, do you notice anything odd?
©2015, Kenneth R. Koehler. All Rights Reserved. This document may be freely reproduced provided that this copyright notice is included.
Please send comments or suggestions to the author.