523 lines
15 KiB
HTML
523 lines
15 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
|
|
|
|
<html>
|
|
|
|
<head>
|
|
|
|
<meta http-equiv="content-type" content="text/html; charset=iso-8859-1">
|
|
|
|
<title>The Debian GNU/Linux FAQ - Customizing your installation of Debian GNU/Linux</title>
|
|
|
|
</head>
|
|
|
|
<body>
|
|
|
|
<p><a name="ch-customizing"></a></p>
|
|
<hr>
|
|
|
|
<p>
|
|
[ <a href="ch-kernel.en.html">previous</a> ]
|
|
[ <a href="index.en.html#contents">Contents</a> ]
|
|
[ <a href="ch-basic_defs.en.html">1</a> ]
|
|
[ <a href="ch-getting.en.html">2</a> ]
|
|
[ <a href="ch-compat.en.html">3</a> ]
|
|
[ <a href="ch-software.en.html">4</a> ]
|
|
[ <a href="ch-ftparchives.en.html">5</a> ]
|
|
[ <a href="ch-pkg_basics.en.html">6</a> ]
|
|
[ <a href="ch-pkgtools.en.html">7</a> ]
|
|
[ <a href="ch-uptodate.en.html">8</a> ]
|
|
[ <a href="ch-kernel.en.html">9</a> ]
|
|
[ 10 ]
|
|
[ <a href="ch-support.en.html">11</a> ]
|
|
[ <a href="ch-contributing.en.html">12</a> ]
|
|
[ <a href="ch-redistrib.en.html">13</a> ]
|
|
[ <a href="ch-nexttime.en.html">14</a> ]
|
|
[ <a href="ch-faqinfo.en.html">15</a> ]
|
|
[ <a href="ch-support.en.html">next</a> ]
|
|
</p>
|
|
|
|
<hr>
|
|
|
|
<h1>
|
|
The Debian GNU/Linux FAQ
|
|
<br>Chapter 10 - Customizing your installation of Debian GNU/Linux
|
|
</h1>
|
|
|
|
<hr>
|
|
|
|
<h2><a name="s-papersize"></a>10.1 How can I ensure that all programs use the same paper size?</h2>
|
|
|
|
<p>
|
|
Install the <code>libpaper1</code> package, and it will ask you for a
|
|
system-wide default paper size. This setting will be kept in the file
|
|
<samp>/etc/papersize</samp>.
|
|
</p>
|
|
|
|
<p>
|
|
Users can override the paper size setting using the <samp>PAPERSIZE</samp>
|
|
environment variable. For details, see the manual page
|
|
<code>papersize(5)</code>.
|
|
</p>
|
|
|
|
<hr>
|
|
|
|
<h2><a name="s-hardwareaccess"></a>10.2 How can I provide access to hardware peripherals, without compromising security?</h2>
|
|
|
|
<p>
|
|
Many device files in the <samp>/dev</samp> directory belong to some predefined
|
|
groups. For example, <samp>/dev/fd0</samp> belongs to the <samp>floppy</samp>
|
|
group, and <samp>/dev/dsp</samp> belongs to the <samp>audio</samp> group.
|
|
</p>
|
|
|
|
<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:
|
|
</p>
|
|
|
|
<pre>
|
|
adduser user group
|
|
</pre>
|
|
|
|
<p>
|
|
This way you won't have to change the file permissions on the device.
|
|
</p>
|
|
|
|
<hr>
|
|
|
|
<h2><a name="s-consolefont"></a>10.3 How do I load a console font on startup the Debian way?</h2>
|
|
|
|
<p>
|
|
The <code>kbd</code> and <code>console-tools</code> packages support this, edit
|
|
<samp>/etc/kbd/config</samp> or <samp>/etc/console-tools/config</samp> files.
|
|
</p>
|
|
|
|
<hr>
|
|
|
|
<h2><a name="s-appdefaults"></a>10.4 How can I configure an X11 program's application defaults?</h2>
|
|
|
|
<p>
|
|
Debian's X programs will install their application resource data in the
|
|
<samp>/etc/X11/app-defaults/</samp> 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.
|
|
</p>
|
|
|
|
<hr>
|
|
|
|
<h2><a name="s-booting"></a>10.5 Every distribution seems to have a different boot-up method. Tell me about Debian's.</h2>
|
|
|
|
<p>
|
|
Like all Unices, Debian boots up by executing the program <samp>init</samp>.
|
|
The configuration file for <samp>init</samp> (which is
|
|
<samp>/etc/inittab</samp>) specifies that the first script to be executed
|
|
should be <samp>/etc/init.d/rcS</samp>. This script runs all of the scripts in
|
|
<samp>/etc/rcS.d/</samp> by sourcing or forking subprocess depending on their
|
|
file extension 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. Then, for compatibility, it runs the files
|
|
(except those with a `.'in the filename) in <samp>/etc/rc.boot/</samp> too.
|
|
Any scripts in the latter directory are usually reserved for system
|
|
administrator use, and using them in packages is deprecated.
|
|
</p>
|
|
|
|
<p>
|
|
After completing the boot process, <samp>init</samp> executes all start scripts
|
|
in a directory specified by the default runlevel (this runlevel is given by the
|
|
entry for <samp>id</samp> in <samp>/etc/inittab</samp>). Like most System V
|
|
compatible Unices, Linux has 7 runlevels:
|
|
</p>
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
0 (halt the system),
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
1 (single-user mode),
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
2 through 5 (various multi-user modes), and
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
6 (reboot the system).
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>
|
|
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
|
|
<samp>/etc/rc2.d/</samp> will be run.
|
|
</p>
|
|
|
|
<p>
|
|
In fact, the scripts in any of the directories, <samp>/etc/rcN.d/</samp> are
|
|
just symbolic links back to scripts in <samp>/etc/init.d/</samp>. However, the
|
|
<em>names</em> of the files in each of the <samp>/etc/rcN.d/</samp> directories
|
|
are selected to indicate the <em>way</em> the scripts in
|
|
<samp>/etc/init.d/</samp> 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>
|
|
|
|
<p>
|
|
This approach works because the scripts in <samp>/etc/init.d/</samp> 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>
|
|
|
|
<p>
|
|
For example, with the argument `reload' the command
|
|
</p>
|
|
|
|
<pre>
|
|
/etc/init.d/sendmail reload
|
|
</pre>
|
|
|
|
<p>
|
|
sends the sendmail daemon a signal to reread its configuration file. (BTW,
|
|
Debian supplies <code>invoke-rc.d</code> as a wrapper for invoking the scripts
|
|
in <samp>/etc/init.d/</samp>.)
|
|
</p>
|
|
|
|
<hr>
|
|
|
|
<h2><a name="s-custombootscripts"></a>10.6 It looks as if Debian does not use <samp>rc.local</samp> to customize the boot process; what facilities are provided?</h2>
|
|
|
|
<p>
|
|
Suppose a system needs to execute script <samp>foo</samp> on start-up, or on
|
|
entry to a particular (System V) runlevel. Then the system administrator
|
|
should:
|
|
</p>
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
Enter the script <samp>foo</samp> into the directory <samp>/etc/init.d/</samp>.
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
Run the Debian command <samp>update-rc.d</samp> with appropriate arguments, to
|
|
set up links between the (command-line-specified) directories rc?.d and
|
|
<samp>/etc/init.d/foo</samp>. Here, '?' is a number from 0 through 6 and
|
|
corresponds to each of the System V runlevels.
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
Reboot the system.
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>
|
|
The command <samp>update-rc.d</samp> will set up links between files in the
|
|
directories rc?.d and the script in <samp>/etc/init.d/</samp>. 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 <samp>/etc/rcN.d/</samp> are executed
|
|
when runlevel <samp>N</samp> is entered. Scripts beginning with a 'K' are
|
|
executed when leaving runlevel <samp>N</samp>.
|
|
</p>
|
|
|
|
<p>
|
|
One might, for example, cause the script <samp>foo</samp> to execute at
|
|
boot-up, by putting it in <samp>/etc/init.d/</samp> and installing the links
|
|
with <samp>update-rc.d foo defaults 19</samp>. The argument 'defaults' refers
|
|
to the default runlevels, which are 2 through 5. The argument '19' ensures
|
|
that <samp>foo</samp> is called before any scripts containing numbers 20 or
|
|
larger.
|
|
</p>
|
|
|
|
<hr>
|
|
|
|
<h2><a name="s-interconffiles"></a>10.7 How does the package management system deal with packages that contain configuration files for other packages?</h2>
|
|
|
|
<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 <code>dpkg</code> 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>
|
|
|
|
<p>
|
|
Instead, create a local package that modifies the configuration files of the
|
|
"group" of Debian packages of interest. Then <code>dpkg</code> 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.
|
|
</p>
|
|
|
|
<hr>
|
|
|
|
<h2><a name="s-divert"></a>10.8 How do I override a file installed by a package, so that a different version can be used instead?</h2>
|
|
|
|
<p>
|
|
Suppose a sysadmin or local user wishes to use a program
|
|
"login-local" rather than the program "login" provided by
|
|
the Debian <code>login</code> package.
|
|
</p>
|
|
|
|
<p>
|
|
Do <strong>not</strong>:
|
|
</p>
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
Overwrite <samp>/bin/login</samp> with <samp>login-local</samp>.
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>
|
|
The package management system will not know about this change, and will simply
|
|
overwrite your custom <samp>/bin/login</samp> whenever <samp>login</samp> (or
|
|
any package that provides <samp>/bin/login</samp>) is installed or updated.
|
|
</p>
|
|
|
|
<p>
|
|
Rather, do
|
|
</p>
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
Execute:
|
|
</p>
|
|
|
|
<pre>
|
|
dpkg-divert --divert /bin/login.debian /bin/login
|
|
</pre>
|
|
|
|
<p>
|
|
in order to cause all future installations of the Debian <code>login</code>
|
|
package to write the file <samp>/bin/login</samp> to
|
|
<samp>/bin/login.debian</samp> instead.
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
Then execute:
|
|
</p>
|
|
|
|
<pre>
|
|
cp login-local /bin/login
|
|
</pre>
|
|
|
|
<p>
|
|
to move your own locally-built program into place.
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>
|
|
Details are given in the manual page <code>dpkg-divert(8)</code>.
|
|
</p>
|
|
|
|
<hr>
|
|
|
|
<h2><a name="s-localpackages"></a>10.9 How can I have my locally-built package included in the list of available packages that the package management system knows about?</h2>
|
|
|
|
<p>
|
|
Execute the command:
|
|
</p>
|
|
|
|
<pre>
|
|
dpkg-scanpackages BIN_DIR OVERRIDE_FILE [PATHPREFIX] > my_Packages
|
|
</pre>
|
|
|
|
<p>
|
|
where:
|
|
</p>
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
BIN-DIR is a directory where Debian archive files (which usually have an
|
|
extension of ".deb") are stored.
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
OVERRIDE_FILE is a file that is edited by the distribution maintainers and is
|
|
usually stored on a Debian FTP archive at <samp>indices/override.main.gz</samp>
|
|
for the Debian packages in the "main" distribution. You can ignore
|
|
this for local packages.
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
PATHPREFIX is an <em>optional</em> string that can be prepended to the
|
|
<samp>my_Packages</samp> file being produced.
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>
|
|
Once you have built the file <samp>my_Packages</samp>, tell the package
|
|
management system about it by using the command:
|
|
</p>
|
|
|
|
<pre>
|
|
dpkg --merge-avail my_Packages
|
|
</pre>
|
|
|
|
<p>
|
|
If you are using APT, you can add the local repository to your
|
|
<code>sources.list(5)</code> file, too.
|
|
</p>
|
|
|
|
<hr>
|
|
|
|
<h2><a name="s-diverse"></a>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?</h2>
|
|
|
|
<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>
|
|
|
|
<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>
|
|
|
|
<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 <samp>tin</samp> or
|
|
<samp>trn</samp> is left up to the individual user. This is satisfied by
|
|
having both the <code>tin</code> and <code>trn</code> packages provide the
|
|
virtual package <code>news-reader</code>. <em>Which</em> program is invoked is
|
|
determined by a link pointing from a file with the virtual package name
|
|
<samp>/etc/alternatives/news-reader</samp> to the selected file, e.g.,
|
|
<samp>/usr/bin/trn</samp>.
|
|
</p>
|
|
|
|
<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 <samp>update-alternatives</samp> provides a way of
|
|
ensuring that all the files associated with a specified package are selected as
|
|
a system default.
|
|
</p>
|
|
|
|
<p>
|
|
For example, to check what executables provide `x-window-manager', run:
|
|
</p>
|
|
|
|
<pre>
|
|
update-alternatives --display x-window-manager
|
|
</pre>
|
|
|
|
<p>
|
|
If you want to change it, run:
|
|
</p>
|
|
|
|
<pre>
|
|
update-alternatives --config x-window-manager
|
|
</pre>
|
|
|
|
<p>
|
|
And follow the instructions on the screen (basically, press the number next to
|
|
the entry you'd like better).
|
|
</p>
|
|
|
|
<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:
|
|
</p>
|
|
|
|
<pre>
|
|
update-alternatives --install /usr/bin/x-window-manager \
|
|
x-window-manager /usr/local/bin/wmaker-cvs 50
|
|
</pre>
|
|
|
|
<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>
|
|
|
|
<p>
|
|
To remove an alternative you added, simply run:
|
|
</p>
|
|
|
|
<pre>
|
|
update-alternatives --remove x-window-manager /usr/local/bin/wmaker-cvs
|
|
</pre>
|
|
|
|
<hr>
|
|
|
|
<p>
|
|
[ <a href="ch-kernel.en.html">previous</a> ]
|
|
[ <a href="index.en.html#contents">Contents</a> ]
|
|
[ <a href="ch-basic_defs.en.html">1</a> ]
|
|
[ <a href="ch-getting.en.html">2</a> ]
|
|
[ <a href="ch-compat.en.html">3</a> ]
|
|
[ <a href="ch-software.en.html">4</a> ]
|
|
[ <a href="ch-ftparchives.en.html">5</a> ]
|
|
[ <a href="ch-pkg_basics.en.html">6</a> ]
|
|
[ <a href="ch-pkgtools.en.html">7</a> ]
|
|
[ <a href="ch-uptodate.en.html">8</a> ]
|
|
[ <a href="ch-kernel.en.html">9</a> ]
|
|
[ 10 ]
|
|
[ <a href="ch-support.en.html">11</a> ]
|
|
[ <a href="ch-contributing.en.html">12</a> ]
|
|
[ <a href="ch-redistrib.en.html">13</a> ]
|
|
[ <a href="ch-nexttime.en.html">14</a> ]
|
|
[ <a href="ch-faqinfo.en.html">15</a> ]
|
|
[ <a href="ch-support.en.html">next</a> ]
|
|
</p>
|
|
|
|
<hr>
|
|
|
|
<p>
|
|
The Debian GNU/Linux FAQ
|
|
</p>
|
|
|
|
<address>
|
|
version 3.1.5, 17 January 2007<br>
|
|
<br>
|
|
Authors are listed at <a href="ch-faqinfo.en.html#s-authors">Debian FAQ Authors</a><br>
|
|
<br>
|
|
</address>
|
|
<hr>
|
|
|
|
</body>
|
|
|
|
</html>
|
|
|