/usr/share/doc/debian-handbook/html/unix-services.html is in debian-handbook 7.20140126.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 | <?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 9. Unix Services</title><link rel="stylesheet" type="text/css" href="Common_Content/css/default.css" /><link rel="stylesheet" media="print" href="Common_Content/css/print.css" type="text/css" /><meta name="generator" content="publican 3.2.1" /><meta name="package" content="Debian-debian-handbook-7-en-US-1.0-1" /><meta name="keywords" content="System boot, Initscripts, SSH, Telnet, Rights, Permissions, Supervision, Inetd, Cron, Backup, Hotplug, PCMCIA, APM, ACPI" /><link rel="home" href="index.html" title="The Debian Administrator's Handbook" /><link rel="up" href="index.html" title="The Debian Administrator's Handbook" /><link rel="prev" href="sect.kernel-installation.html" title="8.11. Installing a Kernel" /><link rel="next" href="sect.remote-login.html" title="9.2. Remote Login" /></head><body><p id="title"><a class="left" href="http://www.debian.org"><img alt="Product Site" src="Common_Content/images//image_left.png" /></a><a class="right" href="http://debian-handbook.info"><img alt="Documentation Site" src="Common_Content/images//image_right.png" /></a></p><ul class="docnav top"><li class="previous"><a accesskey="p" href="sect.kernel-installation.html"><strong>Prev</strong></a></li><li class="home">The Debian Administrator's Handbook</li><li class="next"><a accesskey="n" href="sect.remote-login.html"><strong>Next</strong></a></li></ul><div class="chapter"><div class="titlepage"><div><div><h1 class="title"><a xmlns="" id="unix-services"></a>Chapter 9. Unix Services</h1></div></div></div><div class="toc"><dl class="toc"><dt><span class="section"><a href="unix-services.html#sect.system-boot">9.1. System Boot</a></span></dt><dt><span class="section"><a href="sect.remote-login.html">9.2. Remote Login</a></span></dt><dd><dl><dt><span class="section"><a href="sect.remote-login.html#sect.ssh">9.2.1. Secure Remote Login: SSH</a></span></dt><dt><span class="section"><a href="sect.remote-login.html#sect.remote-desktops">9.2.2. Using Remote Graphical Desktops</a></span></dt></dl></dd><dt><span class="section"><a href="sect.rights-management.html">9.3. Managing Rights</a></span></dt><dt><span class="section"><a href="sect.administration-interfaces.html">9.4. Administration Interfaces</a></span></dt><dd><dl><dt><span class="section"><a href="sect.administration-interfaces.html#sect.webmin">9.4.1. Administrating on a Web Interface: <code class="command">webmin</code></a></span></dt><dt><span class="section"><a href="sect.administration-interfaces.html#sect.debconf">9.4.2. Configuring Packages: <code class="command">debconf</code></a></span></dt></dl></dd><dt><span class="section"><a href="sect.syslog.html">9.5. <code class="command">syslog</code> System Events</a></span></dt><dd><dl><dt><span class="section"><a href="sect.syslog.html#sect.syslog-principe">9.5.1. Principle and Mechanism</a></span></dt><dt><span class="section"><a href="sect.syslog.html#sect.syslog-config">9.5.2. The Configuration File</a></span></dt></dl></dd><dt><span class="section"><a href="sect.inetd.html">9.6. The <code class="command">inetd</code> Super-Server</a></span></dt><dt><span class="section"><a href="sect.task-scheduling-cron-atd.html">9.7. Scheduling Tasks with <code class="command">cron</code> and <code class="command">atd</code></a></span></dt><dd><dl><dt><span class="section"><a href="sect.task-scheduling-cron-atd.html#sect.format-crontab">9.7.1. Format of a <code class="filename">crontab</code> File</a></span></dt><dt><span class="section"><a href="sect.task-scheduling-cron-atd.html#sect.at-command">9.7.2. Using the <code class="command">at</code> Command</a></span></dt></dl></dd><dt><span class="section"><a href="sect.asynchronous-task-scheduling-anacron.html">9.8. Scheduling Asynchronous Tasks: <code class="command">anacron</code></a></span></dt><dt><span class="section"><a href="sect.quotas.html">9.9. Quotas</a></span></dt><dt><span class="section"><a href="sect.backup.html">9.10. Backup</a></span></dt><dd><dl><dt><span class="section"><a href="sect.backup.html#idm1225907612">9.10.1. Backing Up with <code class="command">rsync</code></a></span></dt><dt><span class="section"><a href="sect.backup.html#idm1225882844">9.10.2. Restoring Machines without Backups</a></span></dt></dl></dd><dt><span class="section"><a href="sect.hotplug.html">9.11. Hot Plugging: <span class="emphasis"><em>hotplug</em></span></a></span></dt><dd><dl><dt><span class="section"><a href="sect.hotplug.html#idm1225871804">9.11.1. Introduction</a></span></dt><dt><span class="section"><a href="sect.hotplug.html#idm1225866236">9.11.2. The Naming Problem</a></span></dt><dt><span class="section"><a href="sect.hotplug.html#idm1225857724">9.11.3. How <span class="emphasis"><em>udev</em></span> Works</a></span></dt><dt><span class="section"><a href="sect.hotplug.html#idm1225825428">9.11.4. A concrete example</a></span></dt></dl></dd><dt><span class="section"><a href="sect.power-management.html">9.12. Power Management: Advanced Configuration and Power Interface (ACPI)</a></span></dt></dl></div><div class="highlights"><div class="para">
This chapter covers a number of basic services that are common to many Unix systems. All administrators should be familiar with them.
</div></div><div class="section"><div class="titlepage"><div><div><h2 class="title"><a xmlns="" id="sect.system-boot"></a>9.1. System Boot</h2></div></div></div><a id="idm1233392676" class="indexterm"></a><div class="para">
When you boot the computer, the many messages scrolling by on the console display many automatic initializations and configurations that are being executed. Sometimes you may wish to slightly alter how this stage works, which means that you need to understand it well. That is the purpose of this section.
</div><div class="para">
First, the BIOS takes control of the computer, detects the disks, loads the <span class="emphasis"><em>Master Boot Record</em></span>, and executes the bootloader. The bootloader takes over, finds the kernel on the disk, loads and executes it. The kernel is then initialized, and starts to search for and mount the partition containing the root filesystem, and finally executes the first program — <code class="command">init</code>. Frequently, this “root partition” and this <code class="command">init</code> are, in fact, located in a virtual filesystem that only exists in RAM (hence its name, “initramfs”, formerly called “initrd” for “initialization RAM disk”). This filesystem is loaded in memory by the bootloader, often from a file on a hard drive or from the network. It contains the bare minimum required by the kernel to load the “true” root filesystem: this may be driver modules for the hard drive, or other devices without which the system can not boot, or, more frequently, initialization scripts and modules for assembling RAID arrays, opening encrypted partitions, activating LVM volumes, etc. Once the root partition is mounted, the initramfs hands over control to the real init, and the machine goes back to the standard boot process.
</div><div class="para">
The “real init” is currently provided by <span class="pkg pkg">sysv-rc</span> (“System V”) and this section documents this init system.
</div><div class="sidebar"><div class="titlepage"><div><div><p class="title"><strong><span class="emphasis"><em>SPECIFIC CASE</em></span> Booting from the network</strong></p></div></div></div><div class="para">
In some configurations, the BIOS may be configured not to execute the MBR, but to seek its equivalent on the network, making it possible to build computers without a hard drive, or which are completely reinstalled on each boot. This option is not available on all hardware and it generally requires an appropriate combination of BIOS and network card.
</div><div class="para">
Booting from the network can be used to launch the <code class="command">debian-installer</code> or FAI (see <a class="xref" href="installation.html#sect.installation-methods">Section 4.1, “Installation Methods”</a>).
</div></div><div class="sidebar"><div class="titlepage"><div><div><p class="title"><strong><span class="emphasis"><em>BACK TO BASICS</em></span> The process, a program instance</strong></p></div></div></div><a id="idm1232927084" class="indexterm"></a><div class="para">
A process is the representation in memory of a running program. It includes all of the information necessary for the proper execution of the software (the code itself, but also the data that it has in memory, the list of files that it has opened, the network connections it has established, etc.). A single program may be instantiated into several processes, not necessarily running under different user IDs.
</div></div><div class="para">
Init executes several processes, following instructions from the <code class="filename">/etc/inittab</code> file. The first program that is executed (which corresponds to the <span class="emphasis"><em>sysinit</em></span> step) is <code class="command">/etc/init.d/rcS</code>, a script that executes all of the programs in the <code class="filename">/etc/rcS.d/</code> directory. <a id="idm1232924628" class="indexterm"></a> <a id="idm1232924244" class="indexterm"></a> <a id="idm1232923844" class="indexterm"></a> <a id="idm1232923460" class="indexterm"></a>
</div><div class="para">
Among these, you will find successively programs in charge of:
</div><div class="itemizedlist"><ul><li class="listitem"><div class="para">
configuring the console's keyboard;
</div></li><li class="listitem"><div class="para">
loading drivers: most of the kernel modules are loaded by the kernel itself as the hardware is detected; extra drivers are then loaded automatically when the corresponding modules are listed in <code class="filename">/etc/modules</code>;
</div></li><li class="listitem"><div class="para">
checking the integrity of filesystems;
</div></li><li class="listitem"><div class="para">
mounting local partitions;
</div></li><li class="listitem"><div class="para">
configuring the network;
</div></li><li class="listitem"><div class="para">
mounting network filesystems (NFS).
</div></li></ul></div><div class="sidebar"><div class="titlepage"><div><div><p class="title"><strong><span class="emphasis"><em>SECURITY</em></span> Using a shell as <code class="command">init</code> to gain root rights</strong></p></div></div></div><div class="para">
By convention, the first process that is booted is the <code class="command">init</code> program. However, it is possible to pass an <code class="literal">init</code> option to the kernel indicating a different program.
</div><a id="idm1233842348" class="indexterm"></a><div class="para">
Any person who is able to access the computer can press the <span class="keycap"><strong>Reset</strong></span> button, and thus reboot it. Then, at the bootloader's prompt, it is possible to pass the <code class="literal">init=/bin/sh</code> option to the kernel to gain root access without knowing the administrator's password.
</div><div class="para">
To prevent this, you can protect the bootloader itself with a password. You might also think about protecting access to the BIOS (a password protection mechanism is almost always available), without which a malicious intruder could still boot the machine on a removable media containing its own Linux system, which they could then use to access data on the computer's hard drives.
</div><div class="para">
Finally, be aware that most BIOS have a generic password available. Initially intended for troubleshooting for those who have forgotten their password, these passwords are now public and available on the Internet (see for yourself by searching for “generic BIOS passwords” in a search engine). All of these protections will thus impede unauthorized access to the machine without being able to completely prevent it. There's no reliable way to protect a computer if the attacker can physically access it; they could dismount the hard drives to connect them to a computer under their own control anyway, or even steal the entire machine, or erase the BIOS memory to reset the password…
</div></div><div class="sidebar"><div class="titlepage"><div><div><p class="title"><strong><span class="emphasis"><em>BACK TO BASICS</em></span> Kernel modules and options</strong></p></div></div></div><a id="idm1224462820" class="indexterm"></a><div class="para">
Kernel modules also have options that can be configured by putting some files in <code class="filename">/etc/modprobe.d/</code>. These options are defined with directives like this: <code class="literal">options <em class="replaceable"><code>module-name</code></em> <em class="replaceable"><code>option-name</code></em>=<em class="replaceable"><code>option-value</code></em></code>. Several options can be specified with a single directive if necessary.
</div><div class="para">
These configuration files are intended for <code class="command">modprobe</code> — the program that loads a kernel module with its dependencies (modules can indeed call other modules). This program is provided by the <span class="pkg pkg">kmod</span> package.
</div><a id="idm1224459684" class="indexterm"></a><a id="idm1224459124" class="indexterm"></a></div><div class="para">
After this stage, <code class="command">init</code> takes over and starts the programs enabled in the default runlevel (which is usually runlevel 2). It executes <code class="command">/etc/init.d/rc 2</code>, a script that starts all services which are listed in <code class="filename">/etc/rc2.d/</code> and whose name start with the “S” letter. The two-figures number that follows had historically been used to define the order in which services had to be started, but nowadays the default boot system uses <code class="command">insserv</code>, which schedules everything automatically based on the scripts' dependencies. Each boot script thus declares the conditions that must be met to start or stop the service (for example, if it must start before or after another service); <code class="command">init</code> then launches them in the order that meets these conditions. The static numbering of scripts is therefore no longer taken into consideration (but they must always have a name beginning with “S” followed by two digits and the actual name of the script used for the dependencies). Generally, base services (such as logging with <code class="command">rsyslog</code>, or port assignment with <code class="command">portmap</code>) are started first, followed by standard services and the graphical interface (<code class="command">gdm</code>).
</div><div class="para">
This dependency-based boot system makes it possible to automate re-numbering, which could be rather tedious if it had to be done manually, and it limits the risks of human error, since scheduling is conducted according to the parameters that are indicated. Another benefit is that services can be started in parallel when they are independent from one another, which can accelerate the boot process.
</div><div class="sidebar"><div class="titlepage"><div><div><p class="title"><strong><span class="emphasis"><em>ALTERNATIVE</em></span> Other boot systems</strong></p></div></div></div><div class="para">
This book describes the boot system used by default in Debian (as implemented by the <span class="pkg pkg">sysvinit</span> package), which is derived and inherited from <span class="emphasis"><em>System V</em></span> Unix systems, but there are others. <span class="distribution distribution">Jessie</span> will likely come with another init system by default since the current one is no longer suited to the dynamic nature of computing.
</div><div class="para">
<span class="pkg pkg">file-rc</span> is a boot system with a very simple process. It keeps the principle of runlevels, but replaces the directories and symbolic links with a configuration file, which indicates to <code class="command">init</code> the processes that must be started and their launch order.
</div><div class="para">
The <code class="command">upstart</code> system is still not perfectly tested on Debian. It is event based: init scripts are no longer executed in a sequential order but in response to events such as the completion of another script upon which they are dependent. This system, started by Ubuntu, is present in Debian <span class="distribution distribution">Wheezy</span>, but is not the default; it comes, in fact, as a replacement for <span class="pkg pkg">sysvinit</span>, and one of the tasks launched by <code class="command">upstart</code> is to launch the scripts written for traditional systems, especially those from the <span class="pkg pkg">sysv-rc</span> package.
</div><div class="para">
Another new option that is gaining a lot of traction is <code class="command">systemd</code>. Its approach is opposite to the previous systems; instead of preemptively launching all services, and having to deal with the question of scheduling, <code class="command">systemd</code> chooses to start services on demand, somewhat along the principle of <code class="command">inetd</code>. But this means that the boot system must be able to know how services are made available (it could be through a socket, a filesystem, or others), and thus requires small modifications of those services. It also provides backwards compatibility to System V init scripts.
</div><div class="para">
There are also other systems and other operating modes, such as <code class="command">runit</code>, <code class="command">minit</code>, or <code class="command">initng</code>, but they are relatively specialized and not widespread.
</div></div><a id="idm1223104484" class="indexterm"></a><a id="idm1223104004" class="indexterm"></a><div class="para">
<code class="command">init</code> distinguishes several runlevels, so it can switch from one to another with the <code class="command">telinit <em class="replaceable"><code>new-level</code></em></code> command. Immediately, <code class="command">init</code> executes <code class="command">/etc/init.d/rc</code> again with the new runlevel. This script will then start the missing services and stop those that are no longer desired. To do this, it refers to the content of the <code class="filename">/etc/rc<em class="replaceable"><code>X</code></em>.d</code> (where <em class="replaceable"><code>X</code></em> represents the new runlevel). Scripts starting with “S” (as in “Start”) are services to be started; those starting with “K” (as in “Kill”) are the services to be stopped. The script does not start any service that was already active in the previous runlevel.
</div><div class="para">
By default, Debian uses four different runlevels:
</div><div class="itemizedlist"><ul><li class="listitem"><div class="para">
Level 0 is only used temporarily, while the computer is powering down. As such, it only contains many “K” scripts.
</div></li><li class="listitem"><div class="para">
Level 1, also known as single-user mode, corresponds to the system in degraded mode; it includes only basic services, and is intended for maintenance operations where interactions with ordinary users are not desired.
</div></li><li class="listitem"><div class="para">
Level 2 is the level for normal operation, which includes networking services, a graphical interface, user logins, etc.
</div></li><li class="listitem"><div class="para">
Level 6 is similar to level 0, except that it is used during the shutdown phase that precedes a reboot.
</div></li></ul></div><div class="para">
Other levels exist, especially 3 to 5. By default they are configured to operate the same way as level 2, but the administrator can modify them (by adding or deleting scripts in the corresponding <code class="filename">/etc/rc<em class="replaceable"><code>X</code></em>.d</code> directories) to adapt them to particular needs.
</div><div class="figure"><a xmlns="" id="figure.boot-process"></a><div class="figure-contents"><div class="mediaobject"><img src="images/startup.png" alt="Boot sequence of a computer running Linux" /></div></div><p class="title"><strong>Figure 9.1. Boot sequence of a computer running Linux</strong></p></div><br class="figure-break" /><a id="idm1223095380" class="indexterm"></a><div class="para">
All the scripts contained in the various <code class="filename">/etc/rc<em class="replaceable"><code>X</code></em>.d</code> directories are really only symbolic links — created upon package installation by the <code class="command">update-rc.d</code> program — pointing to the actual scripts which are stored in <code class="filename">/etc/init.d/</code>. The administrator can fine tune the services available in each runlevel by re-running <code class="command">update-rc.d</code> with adjusted parameters. The <span class="citerefentry"><span class="refentrytitle">update-rc.d</span>(1)</span> manual page describes the syntax in detail. Please note that removing all symbolic links (with the <code class="literal">remove</code> parameter) is not a good method to disable a service. Instead you should simply configure it to not start in the desired runlevel (while preserving the corresponding calls to stop it in the event that the service runs in the previous runlevel). Since <code class="command">update-rc.d</code> has a somewhat convoluted interface, you may prefer using <code class="command">rcconf</code> (from the <span class="pkg pkg">rcconf</span> package) which provides a more user-friendly interface.
</div><a id="idm1223091172" class="indexterm"></a><div class="sidebar"><div class="titlepage"><div><div><p class="title"><strong><span class="emphasis"><em>DEBIAN POLICY</em></span> Restarting services</strong></p></div></div></div><a id="idm1223090084" class="indexterm"></a><a id="idm1222246948" class="indexterm"></a><a id="idm1222246228" class="indexterm"></a><div class="para">
The maintainer scripts for Debian packages will sometimes restart certain services to ensure their availability or get them to take certain options into account. The command that controls a service — <code class="command">/etc/init.d/<em class="replaceable"><code>service</code></em> <em class="replaceable"><code>operation</code></em></code> — doesn't take runlevel into consideration, assumes (wrongly) that the service is currently being used, and may thus initiate incorrect operations (starting a service that was deliberately stopped, or stopping a service that is already stopped, etc.). Debian therefore introduced the <code class="command">invoke-rc.d</code> program: this program must be used by maintainer scripts to run services initialization scripts and it will only execute the necessary commands. Note that, contrary to common usage, the <code class="filename">.d</code> suffix is used here in a program name, and not in a directory.
</div></div><div class="para">
Finally, <code class="command">init</code> starts control programs for various virtual consoles (<code class="command">getty</code>). It displays a prompt, waiting for a username, then executes <code class="command">login <em class="replaceable"><code>user</code></em></code> to initiate a session.
</div><a id="idm1222242436" class="indexterm"></a><div class="sidebar"><div class="titlepage"><div><div><p class="title"><strong><span class="emphasis"><em>VOCABULARY</em></span> Console and terminal</strong></p></div></div></div><div class="para">
The first computers were usually separated into several, very large parts: the storage enclosure and the central processing unit were separate from the peripheral devices used by the operators to control them. These were part of a separate furniture, the “console”. This term was retained, but its meaning has changed. It has become more or less synonymous with “terminal”, being a keyboard and a screen.
</div><div class="para">
With the development of computers, operating systems have offered several virtual consoles to allow for several independent sessions at the same time, even if there is only one keyboard and screen. Most GNU/Linux systems offer six virtual consoles (in text mode), accessible by typing the key combinations <span class="keycap"><strong>Control</strong></span>+<span class="keycap"><strong>Alt</strong></span>+<span class="keycap"><strong>F1</strong></span> through <span class="keycap"><strong>Control</strong></span>+<span class="keycap"><strong>Alt</strong></span>+<span class="keycap"><strong>F6</strong></span>.
</div><div class="para">
By extension, the terms “console” and “terminal” can also refer to a terminal emulator in a graphical X11 session (such as <code class="command">xterm</code>, <code class="command">gnome-terminal</code> or <code class="command">konsole</code>).
</div></div></div></div><ul class="docnav"><li class="previous"><a accesskey="p" href="sect.kernel-installation.html"><strong>Prev</strong>8.11. Installing a Kernel</a></li><li class="up"><a accesskey="u" href="#"><strong>Up</strong></a></li><li class="home"><a accesskey="h" href="index.html"><strong>Home</strong></a></li><li class="next"><a accesskey="n" href="sect.remote-login.html"><strong>Next</strong>9.2. Remote Login</a></li></ul></body></html>
|