1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
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>
|
