<!-- retain these comments for translator revision tracking -->
<!-- Original version: $Revision: 1.14 $ -->
<chapt id="customizing">Customizing your &debian; system

<sect id="papersize">How can I ensure that all programs use the same
  paper size?

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

<p>Users can override the paper size setting using the <tt>PAPERSIZE</tt>
environment variable. For details, see the manual page
<manref name="papersize" section="5">.

<sect id="hardwareaccess">How can I provide access to hardware peripherals,
  without compromising security?

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

<p>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:
  <example>adduser user group</example>
This way you won't have to change the file permissions on the device.

<p>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 <tt>groups</tt>.

<p>Notice that, since the introduction of <tt>udev</tt> 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 <tt>/etc/udev</tt>.

<sect id="consolefont">How do I load a console font on startup the Debian way?

<p>The <package/kbd/ package supports this,
edit the <tt>/etc/kbd/config</tt> file.

<sect id="appdefaults">How can I configure an X11 program's application
  defaults?

<p>Debian's X programs will install their application resource data in the
<tt>/etc/X11/app-defaults/</tt> 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.

<sect id="booting">Every distribution seems to have a different boot-up
  method.  Tell me about Debian's.

<p>Like all Unices, Debian boots up by executing the program <tt>init</tt>
<footnote>As of this writing, the unstable release for Debian GNU/Linux is
replacing sysvinit with <prgn/systemd/, a system and service manager for Linux. For
more information see <url id="https://wiki.debian.org/systemd">.</footnote>.
The configuration file for <tt>init</tt> (which is <tt>/etc/inittab</tt>)
specifies that the first script to be executed should be
<tt>/etc/init.d/rcS</tt>.  This script runs all of the scripts in
<tt>/etc/rcS.d/</tt> 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.  

<p>After completing the boot process, <tt>init</tt> executes all start
scripts in a directory specified by the default runlevel (this runlevel
is given by the entry for <tt>id</tt> in <tt>/etc/inittab</tt>).
Like most <!-- all? SGK --> System V compatible Unices, Linux has 7 runlevels:
<list>
  <item>0 (halt the system),
  <item>1 (single-user mode),
  <item>2 through 5 (various multi-user modes), and
  <item>6 (reboot the system).
</list>
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 <tt>/etc/rc2.d/</tt> will be run.

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

<p>The scripts in any of the directories, <tt>/etc/rcN.d/</tt>
are just symbolic links back to scripts in <tt>/etc/init.d/</tt>.  However,
the <em>names</em> of the files in each of the <tt>/etc/rcN.d/</tt>
directories are selected to indicate the <em>way</em> the scripts in
<tt>/etc/init.d/</tt> 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.

<p>This approach works because the scripts in <tt>/etc/init.d/</tt> 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.

<p>For example, with the argument `reload' the command
  <example>/etc/init.d/sendmail reload</example>
sends the sendmail daemon a signal to reread its configuration file.  

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

<sect id="custombootscripts">What other facilities are provided
  to customize the boot process besides
  <tt>rc.local</tt>?

<p>The <tt>rc.local</tt> script is executed at the end of each multiuser
runlevel. In Debian it is configured to do nothing. This provides
customisation of the boot process, but might not be sufficient
for all situations.

<p>Suppose a system needs to execute script <tt>foo</tt> on start-up,
or on entry to a particular (System V) runlevel.  Then the system
administrator should:
<list>
  <item>Enter the script <tt>foo</tt> into the directory <tt>/etc/init.d/</tt>.
  <item>Run the Debian command <tt>update-rc.d</tt> with appropriate
  arguments, to specify which runlevels should start the service, and which
  runlevels should stop the service.
  <item>Consider rebooting the system to check that the service starts 
  correctly (assuming that you've asked for it to be started in the
  default runlevel).  Otherwise, manually start it by running
  `<tt>/etc/init.d/foo start</tt>'.
</list>

<p>One might, for example, cause the script <tt>foo</tt> to execute at
boot-up, by putting it in <tt>/etc/init.d/</tt> and running
<tt>update-rc.d foo defaults 19</tt>.  The argument `<tt>defaults</tt>' refers
to the default runlevels, which means (at least in absence of any LSB comment
block to the contrary) to start the service in runlevels 2 through 5,
and to stop the service in runlevels 0, 1 and 6.
(Any LSB Default-Start and Default-Stop directives in <tt>foo</tt> take
precedence when using the sysv-rc version of update-rc.d, but are
ignored by file-rc's variant (v0.8.10 and higher) of update-rc.d.)
The argument `<tt>19</tt>' ensures that <tt>foo</tt> is called after all
scripts whose number is less than 19 have completed, and before all scripts
whose number is 20 or greater.

<sect id="interconffiles">How does the package management system deal with
  packages that contain configuration files for other packages?

<p>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 <prgn/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.

<p>Instead, create a local package that modifies the configuration files
of the "group" of Debian packages of interest.  Then <prgn/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.

<!-- check against dpkg-divert description -->
<sect id="divert">How do I override a file installed by a package, so that
  a different version can be used instead?

<p>Suppose a sysadmin or local user wishes to use a program "login-local"
rather than the program "login" provided by the Debian <package/login/
package.

<p>Do <strong/not/:
<list>
  <item>Overwrite <tt>/bin/login</tt> with <tt>login-local</tt>.
</list>
The package management system will not know about this change, and will simply
overwrite your custom <tt>/bin/login</tt> whenever <tt>login</tt> (or any
package that provides <tt>/bin/login</tt>) is installed or updated.

<p>Rather, do
<list>
  <item>Execute:
    <example>dpkg-divert --divert /bin/login.debian /bin/login</example>
  in order to cause all future installations of the Debian <package/login/
  package to write the file <tt>/bin/login</tt> to <tt>/bin/login.debian</tt>
  instead.
  <item>Then execute:
    <example>cp login-local /bin/login</example>
  to move your own locally-built program into place.
</list>

<p>Run <tt>dpkg-divert --list</tt> to see which diversions are currently active
on your system.

<p>Details are given in the manual page <manref name="dpkg-divert" section="8">.

<sect id="localpackages">How can I have my locally-built package included in
  the list of available packages that the package management system knows
  about?

<p>Execute the command:

<example>
dpkg-scanpackages BIN_DIR OVERRIDE_FILE [PATHPREFIX] > my_Packages
</example>

<p>where:
  <list>
    <item>BIN-DIR is a directory where Debian archive files (which usually
    have an extension of ".deb") are stored.
    <item>OVERRIDE_FILE is a file that is edited by the distribution
    maintainers and is usually stored on a Debian FTP archive at
    <tt>indices/override.main.gz</tt> for the Debian packages in
    the "main" distribution. You can ignore this for local packages.
    <item>PATHPREFIX is an <em>optional</em> string that can be prepended
    to the <tt>my_Packages</tt> file being produced.
  </list>

<p>Once you have built the file <tt>my_Packages</tt>, tell the package
management system about it by using the command:

<example>
dpkg --merge-avail my_Packages
</example>

<p>If you are using APT, you can add the local repository to your
<manref name="sources.list" section="5"> file, too.

<sect id="diverse">Some users like mawk, others like gawk; some like vim,
  others like elvis; some like trn, others like tin; how does Debian
  support diversity?

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

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

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

<p>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 <tt>update-alternatives</tt>
provides a way of ensuring that all the files associated with a specified
package are selected as a system default.

<p>For example, to check what executables provide `x-window-manager', run:
  <example>update-alternatives --display x-window-manager</example>
If you want to change it, run:
  <example>update-alternatives --config x-window-manager</example>
And follow the instructions on the screen (basically, press the number
next to the entry you'd like better).

<p>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:
  <example>update-alternatives --install /usr/bin/x-window-manager \
  x-window-manager /usr/local/bin/wmaker-cvs 50</example>

<p>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).

<p>To remove an alternative you added, simply run:
  <example>update-alternatives --remove x-window-manager /usr/local/bin/wmaker-cvs</example>
