Chapter 11. Customizing your Debian GNU/Linux system

Install the libpaper1 package, and it will ask you for a system-wide default paper size. This setting will be kept in the file /etc/papersize.

Users can override the paper size setting using the PAPERSIZE environment variable. For details, see the manual page papersize(5).

Many device files in the /dev directory belong to some predefined groups. For example, /dev/sr0 belongs to the cdrom group.

If you want a certain user to have access to one of these devices, just add the user to the group the device belongs to, i.e. do:

adduser user group

This way you won't have to change the file permissions on the device.

If you do this from within a user's shell or a GUI environment you have to logout and login again to become an effective member of that group. To check which groups you belong to run groups.

Notice that, since the introduction of udev if you change the permissions of a hardware peripheral, they might be adjusted for some devices when the system starts; if this happens to the hardware peripherals you are interested in, you will have to adjust the rules at /etc/udev.

The kbd package supports this, edit the /etc/kbd/config file.

Debian's X programs will install their application resource data in the /etc/X11/app-defaults/ directory. If you want to customize X applications globally, put your customizations in those files. They are marked as configuration files, so their contents will be preserved during upgrades.

Like all Unices, Debian boots up by executing the program init. Like most Linux distributions, a default Debian system uses systemd as the implementation of init. Traditional System-V style init and other methods are also supported. ^[6]

To control the order in which services are started, traditional System-V style Unix systems use runlevels. These are replaced by targets under systemd. To display the default target to which systemd will bring the system, run the command

systemctl get-default

During boot-up, systemd starts the services or other targets listed in the default target file /lib/systemd/system/default.target. The files for these services and targets are installed and the service is enabled during Debian package installation. If you specifically wish not to start a service during boot-up, instead of removing the corresponding package, you can run the command

systemctl disable service.service

using the name of the service file installed in /lib/systemd/system (usually based on the name of the package).

The service file /lib/systemd/rc.local.service provides an easy way to run customized scripts in the file /etc/rc.local after boot-up, similar to what's offered on Debian systems running System-V style init. Beware: this script will fail if it tries to interact with the console such as asking for a user password or trying to clear the screen.

You can check the status of any service by the command

service package status

. To start or stop a service, run

service package start

and

service package stop

. The service command works with any init system supported on a Debian system, not just with systemd. If you however prefer to use the same command on any systemd-supported Linux system, for checking the status run

systemctl status package.service

to get the same information.

For more information on systemd for Debian, see https://wiki.debian.org/systemd.

Debian supports booting using traditional System V init, via the sysvinit-core package. The configuration file for System V init (which is /etc/inittab) specifies that the first script to be executed should be /etc/init.d/rcS. This script runs all of the scripts in /etc/rcS.d/ by forking subprocesses to perform initialization such as to check and to mount file systems, to load modules, to start the network services, to set the clock, and to perform other initialization.

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 7 runlevels:

Debian 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.

Debian uses dependency-based boot ordering through insserv, using the LSB headers in each script under /etc/init.d/, as well as parallel concurrent booting through the use of startpar to speed up the boot process.

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', `reload', `restart' or `force-reload' and will then do the task indicated by the argument. These scripts can be used even after a system has been booted, to control various processes.

For example, with the argument `reload' the command

/etc/init.d/sendmail reload

sends the sendmail daemon a signal to reread its configuration file.

Note that invoke-rc.d should not be used to call the /etc/init.d/ scripts, service should be used instead.

If you do like System V init, but don't like the /etc/rc?.d/* links, you could install the file-rc package. That will convert the links into one single configuration file /etc/runlevel.conf instead.

If you like neither System V nor systemd, you might like openrc or runit or daemontools.

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 will not know about those configuration files if they are 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 configuration 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.

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:

The package management system will not know about this change, and will simply overwrite your custom /bin/login whenever login (or any package that provides /bin/login) is installed or updated.

Rather, do

Run dpkg-divert --list to see which diversions are currently active on your system.

Details are given in the manual page dpkg-divert(8).

Execute the command:

dpkg-scanpackages BIN_DIR OVERRIDE_FILE [PATHPREFIX] > my_Packages

where:

Once you have built the file my_Packages, tell the package management system about it by using the command:

dpkg --merge-avail my_Packages

If you are using APT, you can add the local repository to your sources.list(5) file, too.

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.

For example, to check what executables provide `x-window-manager', run:

update-alternatives --display x-window-manager

If you want to change it, run:

update-alternatives --config x-window-manager

And follow the instructions on the screen (basically, press the number next to the entry you'd like better).

If a package doesn't register itself as a window manager for some reason (file a bug if it's in error), or if you use a window manager from /usr/local directory, the selections on screen won't contain your preferred entry. You can update the link through command line options, like this:

update-alternatives --install /usr/bin/x-window-manager \
  x-window-manager /usr/local/bin/wmaker-cvs 50

The first argument to `--install' option is the symlink that points to /etc/alternatives/NAME, where NAME is the second argument. The third argument is the program to which /etc/alternatives/NAME should point to, and the fourth argument is the priority (larger value means the alternative will more probably get picked automatically).

To remove an alternative you added, simply run:

update-alternatives --remove x-window-manager /usr/local/bin/wmaker-cvs