Gecko [ ifk.uw.edu.pl ]

Name	Size	Permission
ch-basic_defs.en.html	34.93 KB	-rw-r--r--
ch-basic_defs.html	34.93 KB	-rw-r--r--
ch-choosing.en.html	44.66 KB	-rw-r--r--
ch-choosing.html	44.66 KB	-rw-r--r--
ch-compat.en.html	33.45 KB	-rw-r--r--
ch-compat.html	33.45 KB	-rw-r--r--
ch-contributing.en.html	27.15 KB	-rw-r--r--
ch-contributing.html	27.15 KB	-rw-r--r--
ch-customizing.en.html	37.07 KB	-rw-r--r--
ch-customizing.html	37.07 KB	-rw-r--r--
ch-faqinfo.en.html	26.29 KB	-rw-r--r--
ch-faqinfo.html	26.29 KB	-rw-r--r--
ch-ftparchives.en.html	39.02 KB	-rw-r--r--
ch-ftparchives.html	39.02 KB	-rw-r--r--
ch-getting.en.html	28.45 KB	-rw-r--r--
ch-getting.html	28.45 KB	-rw-r--r--
ch-kernel.en.html	25.53 KB	-rw-r--r--
ch-kernel.html	25.53 KB	-rw-r--r--
ch-nexttime.en.html	27.64 KB	-rw-r--r--
ch-nexttime.html	27.64 KB	-rw-r--r--
ch-pkg_basics.en.html	48.23 KB	-rw-r--r--
ch-pkg_basics.html	48.23 KB	-rw-r--r--
ch-pkgtools.en.html	41.75 KB	-rw-r--r--
ch-pkgtools.html	41.75 KB	-rw-r--r--
ch-redistrib.en.html	25.88 KB	-rw-r--r--
ch-redistrib.html	25.88 KB	-rw-r--r--
ch-software.en.html	34.18 KB	-rw-r--r--
ch-software.html	34.18 KB	-rw-r--r--
ch-support.en.html	34.63 KB	-rw-r--r--
ch-support.html	34.63 KB	-rw-r--r--
ch-uptodate.en.html	32.38 KB	-rw-r--r--
ch-uptodate.html	32.38 KB	-rw-r--r--
debian-faq.en.pdf.gz	300.34 KB	-rw-r--r--
debian-faq.en.ps.gz	245.87 KB	-rw-r--r--
debian-faq.en.txt.gz	58.04 KB	-rw-r--r--
debian-faq.pdf.gz	300.34 KB	-rw-r--r--
debian-faq.ps.gz	245.87 KB	-rw-r--r--
debian-faq.txt.gz	58.04 KB	-rw-r--r--
footnotes.en.html	25.56 KB	-rw-r--r--
footnotes.html	25.56 KB	-rw-r--r--
index.en.html	42.78 KB	-rw-r--r--
index.html	42.78 KB	-rw-r--r--

Code Editor : ch-customizing.en.html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">

<html>

<head>

<title>The Debian GNU/Linux FAQ - Customizing your Debian GNU/Linux system</title>

</head>

<body>

[ <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-choosing.en.html">3</a> ]
[ <a href="ch-compat.en.html">4</a> ]
[ <a href="ch-software.en.html">5</a> ]
[ <a href="ch-ftparchives.en.html">6</a> ]
[ <a href="ch-pkg_basics.en.html">7</a> ]
[ <a href="ch-pkgtools.en.html">8</a> ]
[ <a href="ch-uptodate.en.html">9</a> ]
[ <a href="ch-kernel.en.html">10</a> ]
[ 11 ]
[ <a href="ch-support.en.html">12</a> ]
[ <a href="ch-contributing.en.html">13</a> ]
[ <a href="ch-redistrib.en.html">14</a> ]
[ <a href="ch-nexttime.en.html">15</a> ]
[ <a href="ch-faqinfo.en.html">16</a> ]
[ <a href="ch-support.en.html">next</a> ]

<hr>

<h1>
The Debian GNU/Linux FAQ
 Chapter 11 - Customizing your Debian GNU/Linux system
</h1>

<hr>

<h2 id="s-papersize">11.1 How can I ensure that all programs use the same paper size?</h2>

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

Users can override the paper size setting using the <samp>PAPERSIZE</samp>
environment variable. For details, see the manual page
<code>papersize(5)</code>.

<hr>

<h2 id="s-hardwareaccess">11.2 How can I provide access to hardware peripherals, without compromising security?</h2>

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

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:

<pre>
 adduser user group
</pre>

This way you won't have to change the file permissions on the device.

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 <samp>groups</samp>.

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

<hr>

<h2 id="s-consolefont">11.3 How do I load a console font on startup the Debian way?</h2>

The <code>kbd</code> package supports this, edit the
<samp>/etc/kbd/config</samp> file.

<hr>

<h2 id="s-appdefaults">11.4 How can I configure an X11 program's application defaults?</h2>

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.

<hr>

<h2 id="s-booting">11.5 How does a Debian system boot?</h2>

Like all Unices, Debian boots up by executing the program <samp>init</samp>.
Like most Linux distributions, a default Debian system uses
<samp>systemd</samp> as the implementation of <samp>init</samp>. Traditional
System-V style init and other methods are also supported. [<a
href="footnotes.en.html#f6" name="fr6">6</a>]

To control the order in which services are started, traditional System-V style
Unix systems use runlevels. These are replaced by targets
under systemd. To display the default target to which systemd will bring the
system, run the command

<pre>
 systemctl get-default
</pre>

During boot-up, systemd starts the services or other targets listed in the
default target file <samp>/lib/systemd/system/default.target</samp>. The files
for these services and targets are installed and the service is
enabled during Debian package installation. If you specifically wish
not to start a service during boot-up, instead of removing the corresponding
package, you can run the command

<pre>
 systemctl disable <var>service</var>.service
</pre>

using the name of the service file installed in
<samp>/lib/systemd/system</samp> (usually based on the name of the package).

The service file <samp>/lib/systemd/rc.local.service</samp> provides
an easy way to run customized scripts in the file <samp>/etc/rc.local</samp>
after boot-up, similar to what's offered on Debian systems running System-V
style init. Beware: this script will fail if it tries to interact with the
console such as asking for a user password or trying to clear the screen.

You can check the status of any service by the command

<pre>
 service <var>package</var> status
</pre>

. To start or stop a service, run

<pre>
 service <var>package</var> start
</pre>

and

<pre>
 service <var>package</var> stop
</pre>

. The <samp>service</samp> command works with any init system supported on a
Debian system, not just with systemd. If you however prefer to use the same
command on any systemd-supported Linux system, for checking the status run

<pre>
 systemctl status <var>package</var>.service
</pre>

to get the same information.

For more information on systemd for Debian, see <code><a
href="https://wiki.debian.org/systemd">https://wiki.debian.org/systemd</a></code>.

<hr>

<h2 id="s-sysvinit">11.6 And how about Debian and traditional System V init?</h2>

Debian supports booting using traditional System V init, via the sysvinit-core
package. The configuration file for System V <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 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.

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:

<ul>
<li>

0 (halt the system),

</li>
</ul>
<ul>
<li>

1 (single-user mode),

</li>
</ul>
<ul>
<li>

2 through 5 (various multi-user modes), and

</li>
</ul>
<ul>
<li>

6 (reboot the system).

</li>
</ul>

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.

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

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
names of the files in each of the <samp>/etc/rcN.d/</samp> directories
are selected to indicate the way 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.

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.

For example, with the argument `reload' the command

<pre>
 /etc/init.d/sendmail reload
</pre>

sends the sendmail daemon a signal to reread its configuration file.

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

<hr>

<h2 id="s-altboot">11.7 And are there yet other ways of booting a Debian system?</h2>

If you do like System V init, but don't like the /etc/rc?.d/* links, you could
install the <code>file-rc</code> package. That will convert the links into one
single configuration file /etc/runlevel.conf instead.

If you like neither System V nor systemd, you might like <code>openrc</code> or
<code>runit</code> or <code>daemontools</code>.

<hr>

<h2 id="s-interconffiles">11.8 How does the package management system deal with packages that contain configuration files for other packages?</h2>

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.

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.

<hr>

<h2 id="s-divert">11.9 How do I override a file installed by a package, so that a different version can be used instead?</h2>

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.

Do not:

<ul>
<li>

Overwrite <samp>/bin/login</samp> with <samp>login-local</samp>.

</li>
</ul>

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.

Rather, do

<ul>
<li>

Execute:

<pre>
 dpkg-divert --divert /bin/login.debian /bin/login
</pre>

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.

</li>
</ul>
<ul>
<li>

Then execute:

<pre>
 cp login-local /bin/login
</pre>

to move your own locally-built program into place.

</li>
</ul>

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

Details are given in the manual page <code>dpkg-divert(8)</code>.

<hr>

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

Execute the command:

<pre>
 dpkg-scanpackages BIN_DIR OVERRIDE_FILE [PATHPREFIX] &gt; my_Packages
</pre>

where:

<ul>
<li>

BIN-DIR is a directory where Debian archive files (which usually have an
extension of &quot;.deb&quot;) are stored.

</li>
</ul>
<ul>
<li>

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.

</li>
</ul>
<ul>
<li>

PATHPREFIX is an optional string that can be prepended to the
<samp>my_Packages</samp> file being produced.

</li>
</ul>

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

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

If you are using APT, you can add the local repository to your
<code>sources.list(5)</code> file, too.

<hr>

<h2 id="s-diverse">11.11 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>

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

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

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.

For example, to check what executables provide `x-window-manager', run:

<pre>
 update-alternatives --display x-window-manager
</pre>

If you want to change it, run:

<pre>
 update-alternatives --config x-window-manager
</pre>

And follow the instructions on the screen (basically, press the number next to
the entry you'd like better).

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:

<pre>
 update-alternatives --install /usr/bin/x-window-manager \
 x-window-manager /usr/local/bin/wmaker-cvs 50
</pre>

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

To remove an alternative you added, simply run:

<pre>
 update-alternatives --remove x-window-manager /usr/local/bin/wmaker-cvs
</pre>

<hr>

The Debian GNU/Linux FAQ

<address>
version 9.0, 17 November 2018 
 
Authors are listed at <a href="ch-faqinfo.en.html#s-authors">Debian FAQ Authors</a> 
 
</address>
<hr>

</body>

</html>

${this.title}

Code Editor : ch-customizing.en.html