11. Customizing your installation of Debian GNU/Linux

11.1 Every distribution seems to have a different boot-up method. Tell me about Debian's.

Like all Unices, Debian Linux boots up by executing the program init. The configuration file for init (which is /etc/inittab) specifies that the first script to be executed should be /etc/init.d/boot. This script checks and mounts file systems, loads modules, starts the network services (by calling the script /etc/init.d/network), sets the clock, performs other initialization, and then runs all of the scripts (except those with a '.' in the filename) in /etc/rc.boot. The latter script sets the default keyboard, recovers lost editor files, and configures the serial ports.

After completing the boot process, init executes all start scripts in a directory specified by the default runlevel (this runlevel is given by the entry for id in /etc/inittab). Like most System V compatible Unices, Linux has 6 runlevels: 0 (halt the system), 1 (single-user mode), 2 through 5 (various multi-user modes), and 6 (reboot the system). Debian Linux systems come with id=2, which indicates that the default runlevel will be '2' when the multi-user state is entered, and the scripts in /etc/rc2.d will be run.

In fact, the scripts in any of the directories, /etc/rcN.d are just symbolic links back to scripts in /etc/init.d. However, the names of the files in each of the /etc/rcN.d directories are selected to indicate the way the scripts in /etc/init.d will be run. Specifically, before entering any runlevel, all the scripts beginning with 'K' are run; these scripts kill services. Then all the scripts beginning with 'S' are run; these scripts start services. The two-digit number following the 'K' or 'S' indicates the order in which the script is run. Lower numbered scripts are executed first.

This approach works because the scripts in /etc/init.d all take an argument which can be either 'start', 'stop', or 'restart', and will then do the task indicated by the argument. For example, with the argument 'restart' the command /etc/init.d/sendmail restart restarts the sendmail daemon. These scripts can be used even after a system has been booted to control various processes.

11.2 It looks as if Debian doesn't use rc.local to customize the boot process; what facilities are provided?

Suppose a system needs to execute script foo on start-up, or on entry to a particular (System V) runlevel. Then the system administrator should:

• Enter the script foo into the directory /etc/init.d/.
• Run the Debian command update-rc.d with appropriate arguments, to set up links between the (command-line-specified) directories rc?.d and /etc/init.d/foo. Here, '?' is a number from 0 through 6 and corresponds to each of the System V runlevels.
• Reboot the system.

The command update-rc.d will set up links between files in the directories rc?.d and the script in /etc/init.d/. Each link will begin with a 'S' or a 'K', followed by a number, followed by the name of the script. Scripts beginning with 'S' in /etc/rcN.d/ are executed when runlevel N is entered. Scripts beginning with a 'K' are executed when leaving runlevel N.

One might, for example, cause the script foo to execute at bootup, by putting it in /etc/init.d/ and installing the links with update-rc.d foo defaults 19. The argument 'defaults' refers to the default runlevels, which are 2 through 5. The argument '19' ensures that foo is called before any scripts containing numbers 20 or larger. the appropriate time.

11.3 How does the package management system deal with packages that contain configuration files for other packages?

Some users wish to create, for example, a new server by installing a group of Debian packages and a locally generated package consisting of configuration files. This is not generally a good idea, because dpkg won't know about those configuration files if they're in a different package, and may write conflicting configurations when one of the initial "group" of packages is upgraded.

Instead, create a local package that modifies the config files of the "group" of Debian packages of interest. Then dpkg and the rest of the package management system will see that the files have been modified by the local "sysadmin" and will not try to overwrite them when those packages are upgraded.

11.4 How do I override a file installed by a package so that a different version can be used instead?

Suppose a sysadmin or local user wishes to use a program "login-local" rather than the program "login" provided by the Debian login package. Do not:

• Overwrite /bin/login with bin/login-local.

Rather, do

• Execute dpkg-override --divert /bin/login.debian /bin/login in order to cause all future installations of the Debian login packages to write the file /bin/login to /bin/login.debin/ instead.
• Then execute cp login-local /bin/login to move your own locally-built program into place.

11.5 How can I have my locally-built package included in the list of available packages that the package management system knows about?

You can do this in either of two ways:

• Use dselect, and select the option "Update list of available packages". Then execute the command dpkg --avail foo.deb, where foo.deb is the name of your locally-built Debian archive file.
• Execute the command dpkg-scanpackages BIN_DIR OVERRIDE_FILE [PATHPREFIX] > Packages.new where:
  • BIN-DIR is a directory where Debian archive files (which usually have an extension of ".deb") are stored.
  • OVERRIDE_FILE is a file that's edited by the distribution maintainers and is usually stored on a Debian FTP archive at indices/override.main.gz for the Debian packages in the "main" distribution.
  • PATHPREFIX is an optional string that can be prepended to the Packages.new file being produced.
  Once you've built the file Packages.new, tell the package management system about it by using the command dpkg --update-avail Packages.new.

11.6 Some users like mawk, others like gawk; some like vim, others like elvis; some like trn, others like tin; how does Debian support diversity?

There are several cases where two packages provide two different versions of a program, both of which provide the same core functionality. Users might prefer one over another out of habit, or because the user interface of one package is somehow more pleasing than the interface of another. Other users on the same system might make a different choice.

Debian uses a "virtual" package system to allow system administrators to choose (or let users choose) their favorite tools when there are two or more that provide the same basic functionality, yet satisfy package dependency requirements without specifying a particular package.

For example, there might exist two different versions of newsreaders on a system. The news server package might 'recommend' that there exist some news reader on the system, but the choice of tin or trn is left up to the individual user. This is satisfied by having both the tin and trn packages provide the virtual package news-reader. Which program is invoked is determined by a link pointing from a file with the virtual package name /etc/alternatives/news-reader to the selected file, e.g., /usr/bin/trn.

A single link is insufficient to support full use of an alternate program; normally, manual pages, and possibly other supporting files must be selected as well. The Perl script update-alternatives provides a way of ensuring that all the files associated with a specified package are selected as a system default.