The file /etc/papersize contains the name of the system-wide
default paper size (i.e. letter or A4). It can be overwritten using
the PAPERSIZE environment variable. For details see the
manual page papersize(5).
Debian's X11 installation expects you to leave the files in
/usr/X11R6/lib/X11/app-defaults/ unchanged. If you want to
customise X applications globally, put your customizations in
/etc/X11/Xresources. This file is marked as a configuration
file, so its contents will be preserved during upgrades.
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/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 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', or 'reload',
and will then do the task indicated by the argument.
For example, with the argument 'reload' the command
/etc/init.d/sendmail reload sends the sendmail daemon a
signal to reread its configuration file.
These scripts can be used even after a system
has been booted to control various processes.
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:
foo into the directory /etc/init.d/.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. 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.
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:
/bin/login with login-local. /bin/login whenever login (or any
package that provides /bin/login) is installed or updated.
Rather, do
dpkg-divert --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.debian
instead. cp login-local /bin/login to move your own
locally-built program into place.Some details are given in the usage statement for dpkg-divert
(which can be viewed using the command dpkg-divert --help).
Additional details are given in the
Debian programmer's manual.
You can do this in either of two ways:
dselect, and reselect the access method. You will be
asked for a directory where your local packages reside. dpkg-scanpackages BIN_DIR OVERRIDE_FILE [PATHPREFIX] > Packages.new
where:
indices/override.main.gz for the Debian packages in
the "main" distribution.Packages.new, tell the package
management system about it by using the command
dpkg --update-avail Packages.new.
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.