summaryrefslogtreecommitdiff
path: root/templates/common/doc/FAQ/html/ch-customizing.en.html
diff options
context:
space:
mode:
Diffstat (limited to 'templates/common/doc/FAQ/html/ch-customizing.en.html')
-rw-r--r--templates/common/doc/FAQ/html/ch-customizing.en.html522
1 files changed, 522 insertions, 0 deletions
diff --git a/templates/common/doc/FAQ/html/ch-customizing.en.html b/templates/common/doc/FAQ/html/ch-customizing.en.html
new file mode 100644
index 0000000..fb89888
--- /dev/null
+++ b/templates/common/doc/FAQ/html/ch-customizing.en.html
@@ -0,0 +1,522 @@
+<!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 &quot;group&quot;
+of packages is upgraded.
+</p>
+
+<p>
+Instead, create a local package that modifies the configuration files of the
+&quot;group&quot; 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 &quot;sysadmin&quot; 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
+&quot;login-local&quot; rather than the program &quot;login&quot; 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] &gt; my_Packages
+</pre>
+
+<p>
+where:
+</p>
+<ul>
+<li>
+<p>
+BIN-DIR is a directory where Debian archive files (which usually have an
+extension of &quot;.deb&quot;) 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 &quot;main&quot; 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 &quot;virtual&quot; 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.3, 25 April 2006<br>
+<br>
+Authors are listed at <a href="ch-faqinfo.en.html#s-authors">Debian FAQ Authors</a><br>
+<br>
+</address>
+<hr>
+
+</body>
+
+</html>
+