diff options
Diffstat (limited to 'templates/common/doc/FAQ/html/ch-customizing.en.html')
| -rw-r--r-- | templates/common/doc/FAQ/html/ch-customizing.en.html | 522 |
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 "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.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> + |