[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ next ]

# The Debian GNU/Linux FAQ
Chapter 10 - Customizing your installation of Debian GNU/Linux

## 10.1 How can I ensure that all programs use the same paper size?

Install the `libpaperg` 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)`.

## 10.2 How can I provide access to hardware peripherals, without compromising security?

Many device files in the `/dev` directory belong to some predefined groups. For example, `/dev/fd0` belongs to the `floppy` group, and `/dev/dsp` belongs to the `audio` 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 chmod the device file.

## 10.3 How do I load a console font on startup the Debian way?

The `kbd` and `console-tools` packages support this, edit `/etc/kbd/config` or `/etc/console-tools/config` files.

## 10.4 How can I configure an X11 program's application defaults?

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.

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

Like all Unices, Debian 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/rcS`. This script checks and mounts file systems, loads modules, starts the network services, sets the clock, performs other initialization, and then runs all of the scripts (except those with a `.' in the filename) in `/etc/rc.boot/`. Any scripts in the latter directory are usually reserved for system administrator use, and using them in packages is deprecated.

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:

- 0 (halt the system),

- 1 (single-user mode),

- 2 through 5 (various multi-user modes), and

- 6 (reboot the system).

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.

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', `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.

## 10.6 It looks as if Debian does not 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 boot-up, 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.

## 10.7 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` 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.

## 10.8 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 `login-local`.

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

- Execute:

           dpkg-divert --divert /bin/login.debian /bin/login

  in order to cause all future installations of the Debian `login` package to write the file `/bin/login` to `/bin/login.debian` instead.

- Then execute:

           cp login-local /bin/login

  to move your own locally-built program into place.

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

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

Execute the command:

         dpkg-scanpackages BIN_DIR OVERRIDE_FILE [PATHPREFIX] > my_Packages

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 is 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. You can ignore this for local packages.

- PATHPREFIX is an optional string that can be prepended to the `my_Packages` file being produced.

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.

## 10.10 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.

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

[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ next ]

The Debian GNU/Linux FAQ