<!-- Subversion revision of original English document "5263" -->

<chapt id="customizing">Anpassen Ihrer &debian;-Installation

<sect id="papersize">Wie kann ich sicherstellen, dass alle Programme
die selbe Papiergröße verwenden?

<p>Installieren Sie das Paket <package/libpaper1/ und es wird nach einer
systemweiten Standardpapiergröße fragen. Diese Einstellung wird in der 
Datei <file>/etc/papersize</file> gespeichert.</p>

<p>Benutzer können sich über die Papiergrößen-Einstellung hinwegsetzen,
indem sie die <tt>PAPERSIZE</tt>-Umgebungsvariable verwenden. Für Details
siehe die Handbuchseite <manref name="papersize" section="5">.</p>

<sect id="hardwareaccess">Wie kann kann ich Zugang zu Peripheriegeräten
zur Verfügung stellen ohne die Sicherheit zu kompromittieren?

<p>Viele Gerätedateien im <file>/dev/</file>-Verzeichnis gehören zu einer
vordefinierten Gruppe. Zum Beispiel gehört <file>/dev/fd0</file> zu der
<tt>floppy</tt>-Gruppe und <file>/dev/dsp</file> gehört zur <tt>audio</tt>-Gruppe.</p>

<p>Wenn Sie einem bestimmten Benutzer Zugriff auf eines dieser Geräte geben
wollen, fügen Sie ihn zu der Gruppe hinzu, zu der das Gerät gehört, also z.B.:
  <example>adduser user group</example>
Auf diese Art müssen Sie die Dateiberechtigungen des Gerätes nicht ändern.</p>

<p>Wenn Sie diese Änderung von der Shell eines Benutzers oder einer grafischen 
Benutzerumgebung aus vornehmen, müssen Sie sich anschließend einmal abmelden 
und dann wieder anmelden. Nur so werden die Änderungen wirksam. Um 
herauszufinden, welchen Gruppen Sie angehören, verwenden Sie den Befehl 
<tt>groups</tt>.

<p>Beachten Sie, dass seit der Einführung von <tt>udev</tt> möglicherweise 
einige Berechtigungen von Peripheriegeräten, die Sie geändert haben, beim 
Systemstart wieder zurückgesetzt werden. Wenn das bei einem der Geräte 
passiert, an denen Sie interessiert sind, werden Sie die Regeln in 
<tt>/etc/udev</tt> anpassen müssen.

<sect id="consolefont">Wie kann ich eine Konsolen-Schriftart auf Debian-Art
beim Systemstart laden?

<p>Die Pakete <package/kbd/ und <package/console-tools/ unterstützen dies. 
Editieren Sie dazu die Datei <file>/etc/kbd/config</file> oder 
<file>/etc/console-tools/config</file>.</p>

<sect id="appdefaults">Wie kann ich die Standardeinstellung eines
X11-Programms konfigurieren?

<p>Die Debian-X-Programme installieren ihre Anwendungs-Ressource-Daten
im Verzeichnis <file>/etc/X11/app-defaults/</file>. Wenn Sie eine X-Anwendung
global anpassen wollen, schreiben Sie Ihre Anpassungen in diese Dateien.
Sie sind als Konfigurationsdateien markiert, so dass ihre Inhalte bei 
einem Upgrade erhalten bleiben.</p>

<sect id="booting">Jede Distribution scheint eine andere boot-up-Methode
zu haben. Beschreiben Sie jene von Debian.

<p>Wie alle Unices bootet Debian durch das Ausführen des Programms
<prgn>init</prgn>. Die Konfigurationsdatei für <prgn>init</prgn> (sie heißt
<file>/etc/inittab</file>) spezifiziert, dass das erste auszuführende Skript
<file>/etc/init.d/rcS</file> sein sollte. Dieses Skript führt alle Skripte im 
<file>/etc/rcS.d/</file>-Verzeichnis aus, indem es die Unterprozesse abhängig von
ihrer Dateinamenerweiterung entweder auslagert oder forkt, um Initialisierungen
durchzuführen, wie zum Beispiel Dateisysteme zu prüfen und einzuhängen, Module zu laden,
Netzwerkdienste zu starten, die Uhr zu stellen und weitere Initialisierungen 
auszuführen. Danach, aus Kompatibilitätsgründen, führt es auch die Dateien in
<file>/etc/rc.boot/</file> (außer jene mit einem ».« im Dateinamen) aus. Alle
Skripte in diesem Verzeichnis sind üblicherweise für den Systemadministrator
reserviert, sie in Paketen zu verwenden wird abgelehnt.</p>

<p>Nachdem der Boot-Prozess abgeschlossen ist, führt <prgn>init</prgn> alle
Start-Skripte in einem durch den Standard-Runlevel (dieser Runlevel wird
durch den Eintrag <tt>id</tt> in <file>/etc/inittab</file> festgelegt) spezifizierten
Verzeichnis aus. Wie alle zu System V kompatiblen Unices hat Linux 7 Runlevel:
<list>
	<item>0 (das System anhalten),
	<item>1 (Einzel-Benutzer-Modus),
	<item>2 bis 5 (verschiedene Mehr-Benutzer-Modi) und
	<item>6 (das System neu starten).
</list>
Debian-Systeme kommen mit id=2, was bedeutet, dass der Standard-Runlevel »2«
ist, wenn der Mehrbenutzer-Zustand gestartet wird, und dass die Skripte in
<tt>/etc/rc2.d/</tt> ausgeführt werden.</p>

<p>Tatsächlich sind die Skripte in jedem der Verzeichnisse <file>/etc/rc<var>N</var>.d/</file>
nur symbolische Verweise zurück auf Skripte in <file>/etc/init.d/</file>. Wie auch
immer, die <em>Namen</em> der Dateien in jedem der <file>/etc/rc<var>N</var>.d/</file>-Verzeichnisse
sind so gewählt, dass sie darauf hinweisen, <em>wie</em> die Skripte in 
<tt>/etc/init.d/</tt> ausgeführt werden. Konkret werden vor dem Aktivieren
eines Runlevels alle Skripte, die mit einem »K« beginnen, ausgeführt; diese 
Skripte beenden Dienste. Danach werden alle Skripte, die mit einem »S« beginnen,
ausgeführt; diese Skripte starten Dienste. Die zweistellige Zahl, die dem »K« oder 
dem »S« folgt, bestimmt die Reihenfolge, in welcher die Skripte ausgeführt werden. 
Jene mit kleinerer Nummer werden zuerst ausgeführt.</p>

<p>Diese Methode funktioniert, weil die Skripte in <file>/etc/init.d/</file>
alle ein Argument akzeptieren, welches entweder »start«, »stop«, »reload«,
»restart« oder »force-reload« sein kann, und danach das dem Argument
entsprechende tun. Diese Skripte könne auch noch nach dem Starten des Systems
benutzt werden um verschiedene Prozesse zu kontrollieren.</p>

<p>Zum Beispiel sendet das Argument »reload« im Befehl
  <example>/etc/init.d/sendmail reload</example>
dem sendmail-Daemon ein Signal, seine Konfigurationsdatei neu einzulesen. (Übrigens
stellt Debian mit <prgn/invoke-rc.d/ einen Wrapper zum Aufruf der Skripte in
<file>/etc/init.d/</file> zur Verfügung.)</p>

<sect id="custombootscripts">Es scheint so, als ob Debian <file>rc.local</file> nicht 
zum Anpassen des Bootprozesses verwendet; welche Einrichtungen gibt es?

<p>Nehmen Sie an, ein System solle beim Hochfahren das Skript <prgn>foo</prgn> 
ausführen oder einen bestimmten (System-V-) Runlevel aktivieren. Dann sollte
der Systemadministrator:
<list>
  <item>Das Skript <prgn>foo</prgn> ins Verzeichnis <file>/etc/init.d/</file>
  verschieben.
  <item>Den Debian-Befehl <prgn>update-rc.d</prgn> mit den passenden Argumenten
  ausführen, um anzugeben, welche Runlevel den Dienst starten und welche ihn stoppen sollen.
  <item>In Betracht ziehen, das System neu zu starten, um zu überprüfen,
  ob der Dienst richtig startet (hier wird vorausgesetzt, dass der Dienst in
  einem der Standard-Runlevel starten soll). Ansonsten starten Sie den
  Dienst, indem Sie »<tt>/etc/init.d/foo start</tt>« eingeben.
</list></p>

<p>Man könnte zum Beispiel das Skript <prgn>foo</prgn> beim Systemstart
ausführen lassen, indem man es nach <file>/etc/init.d/</file> kopiert und die
Verweise mit <tt>update-rc.d foo defaults 19</tt> einrichtet. Das Argument
»defaults« bezieht sich auf die Standard-Runlevel, welche 2 bis 5 sind. 
Solange es keinen LSB-Kommentar-Block gibt, der dem widerspricht, führt das 
dazu, dass der Dienst in den Runleveln 2 bis 5 gestartet und in den Runleveln 
0, 1 und 6 gestoppt wird. (Sämtliche LSB-Standard-Start- und 
Standard-Stopp-Anweisungen in <tt>foo</tt> haben Vorrang, wenn die 
sysv-rc-Version von <prgn>update-rc.d</prgn> verwendet wird, werden aber von der aktuellen 
(v0.8.10) file-rc-Version von <prgn>update-rc.d</prgn> ignoriert.)
Das Argument »19« führt dazu, dass <tt>foo</tt> vor allen Skripten mit Nummer 
20 oder höher aufgerufen wird.</p>

<sect id="interconffiles">Wie geht das Paketverwaltungssystem mit Paketen um,
die Konfigurationsdateien für andere Pakete enthalten?

<p>Manche Benutzer möchten zum Beispiel einen neuen Server einrichten, indem
sie eine Gruppe von Debian-Paketen installieren und ein lokal generiertes 
Paket, welches aus Konfigurationsdateien besteht. Dies ist grundsätzlich keine
gute Idee, weil <prgn/dpkg/ nichts über diese Konfigurationsdateien weiß, wenn
sie in einem anderen Paket sind und daher Konfigurationen schreiben könnte, die 
zu Konflikten führen, wenn eines der Pakete in der ursprünglichen »Gruppe« 
ein Upgrade durchführt.</p>

<p>Daher ist es besser, ein lokales Paket zu erstellen, das die Konfigurationsdateien
der »Gruppe« der jeweiligen Debian-Pakete modifiziert. Dann sieht <prgn/dpkg/
und der Rest des Paketverwaltungssystems, dass die Dateien durch den lokalen
Systemverwalter modifiziert worden sind und versucht nicht, sie zu 
überschreiben, wenn diese Pakete aktualisiert werden.</p>

<!-- check against dpkg-divert description -->
<sect id="divert">Wie kann ich eine durch ein Paket installierte Datei
außer Kraft setzen, so dass stattdessen eine andere Version verwendet 
werden kann?

<p>Nehmen Sie an, dass ein Systemadministrator oder ein lokaler Benutzer lieber
ein Programm »<prgn>login-local</prgn>« anstatt das vom Debian-Paket <package/login/
zur Verfügung gestellte Programm »<prgn>login</prgn>« verwenden möchte.</p>

<p>Sie sollten <strong/nicht/:
<list>
  <item><file>/bin/login</file> mit <file>login-local</file> überschreiben.
</list>
Das Paketverwaltungssystem weiß nichts über diese Veränderung und wird
einfach Ihr angepasstes <file>/bin/login</file> jedes mal überschreiben, wenn <prgn>login</prgn>
(oder jedes andere Paket, welches <file>/bin/login</file> bereitstellt) installiert
oder aktualisiert wird.</p>

<p>Tun Sie besser Folgendes:
<list>
  <item>Führen Sie folgenden Befehl aus:
    <example>dpkg-divert --divert /bin/login.debian /bin/login</example> Dies
    führt dazu, dass bei allen zukünftigen Installationen des Debian-Pakets
    <package/login/ die Datei <file>/bin/login</file> nach <file>/bin/login.debian</file>
    geschrieben wird.
  <item>Und dann folgenden:
   <example>cp login-local /bin/login</example> Dadurch wird Ihr eigenes lokal
   erstelltes Programm an den richtigen Ort kopiert.
</list></p>

<p>Führen Sie <tt>dpkg-divert --list</tt> aus, um zu sehen, welche Umleitungen 
auf Ihrem System aktiv sind.

<p>Details dazu finden Sie in der Handbuchseite <manref name="dpkg-divert" section="8">.</p>

<sect id="localpackages">Wie kann ich meine lokal erstellten Pakete in die Liste
der verfügbaren Pakete, von denen das Paketmanagementsystem weiß, aufnehmen?

<p>Führen Sie folgenden Befehl aus:
<example>dpkg-scanpackges BIN_DIR OVERRIDE_FILE [PATHPREFIX] > meine_Pakete</example></p>

<p>Dabei ist
<list>
  <item>BIN_DIR ein Verzeichnis, in welches Debian-Archiv-Dateien (welche üblicherweise
  die Endung ».deb« haben) gespeichert sind.
  <item>OVERRIDE_FILE eine Datei, die von den Betreuern der Distribution editiert
  worden ist und üblicherweise in einem Debian-FTP-Archiv in 
  <file>indices/override.main.gz</file> gespeichert ist für Debian-Pakete in der 
  »Main«-Distribution. Sie können dies für lokale Pakete ignorieren.
  <item>PATHPREFIX eine <em>optionale</em> Zeichenkette, die der zu erstellenden
  <file>meine_Pakete</file>-Datei vorangestellt werden kann.
</list></p>

<p>Wenn Sie die Datei <file>meine_Pakete</file> einmal erstellt haben, teilen Sie 
dies dem Paketverwaltungssystem mit, indem Sie folgenden Befehl benutzen:
<example>dpkg --merge-avail meine_Pakete</example></p>

<p>Wenn Sie APT verwenden, können Sie auch das lokale Paketdepot zu Ihrer
<manref name="sources.list" section="5">-Datei hinzufügen.</p>

<sect id="diverse">Einige Benutzer mögen mawk, andere gawk; einige mögen vim,
andere elvis; einige trn, wieder andere tin; wie unterstützt Debian die Vielfalt?

<!-- FIXME: Sind «mawk» etc. nicht Paketnamen und müssten entsprechend ausgezeichnet
werden? -->

<p>Es gibt verschiedene Fälle, in denen zwei Pakete zwei verschiedene Versionen
eines Programms zur Verfügung stellen, wovon beide die selben Grundfunktionen
beherrschen. Benutzer mögen eines dem anderen aus Gewohnheit vorziehen, oder weil
die Benutzerschnittstelle des einen Pakets auf irgendeine Art attraktiver ist als
jene eines anderen. Andere Benutzer auf dem selben System könnten eine andere 
Wahl treffen.</p>

<p>Debian verwendet ein »virtuelles« Paketsystem um den Systemadministratoren
zu erlauben, ihre (oder jene der Benutzer) favorisierten Werkzeuge zu wählen,
wenn es zwei oder mehr gibt, die die selben Basisfunktionen haben und dennoch
den Anforderungen der Paketabhängigkeiten genügen, ohne ein bestimmtes Paket zu
spezifizieren.</p>

<p>Zum Beispiel könnten zwei verschiedene Versionen eines Newsreaders auf einem
System existieren. Das Newsserver-Paket könnte »empfehlen«, dass es 
<em>überhaupt einen</em> Newsreader auf dem System gibt, aber die Wahl von
<tt>tin</tt> oder <tt>trn</tt> ist dem einzelnen Benutzer überlassen. Dies wird
dadurch erreicht, dass beide Pakete <package/tin/ und <package/trn/ das virtuelle
Paket <package/news-reader/ bereitstellen. <em>Welches</em> der Programme
tatsächlich aufgerufen wird, wird durch einen Verweis, der von einer Datei mit
dem Namen des virtuellen Pakets <file>/etc/alternatives/news-reader</file> auf die
ausgewählte Datei zeigt, z.B. <file>/usr/bin/trn</file>, bestimmt.</p>

<p>Ein einzelner Verweis reicht nicht aus, um die volle Verwendung eines
alternativen Programms zu unterstützen; normalerweise müssen Handbuchseiten 
und möglicherweise andere Unterstützungsdateien ebenfalls ausgewählt werden.
Das Perl-Skript <prgn>update-alternatives</prgn> stellt einen Weg bereit 
sicherzustellen, dass alle Dateien, die mit einem bestimmten Paket in 
Verbindung stehen, als ein systemweiter Standard gewählt werden.</p>

<p>Um zum Beispiel zu kontrollieren, welche ausführbaren Dateien 
»x-window-manager« bereitstellen, führen Sie folgenden Befehl aus:
<example>update-alternatives --display x-window-manager</example>
Wenn Sie dies ändern wollen, führen Sie diesen Befehl aus:
<example>update-alternatives --config x-window-manager</example> und folgen
Sie den Anweisungen auf dem Bildschirm (einfach gesagt: drücken Sie die Zahl,
welche neben dem Eintrag, den Sie am besten mögen, steht).</p>

<p>Wenn ein Paket sich selbst aus irgend einem Grund nicht als Fenstermanager
registriert (senden Sie einen Fehlerbericht, wenn es ein Fehler ist), oder
wenn Sie einen Fenstermanager aus dem <file>/usr/local/</file>-Verzeichnis 
verwenden, werden die Auswahlmöglichkeiten auf dem Bildschirm Ihren bevorzugten
Eintrag nicht enthalten. Sie können den Verweis über Befehlszeilen-Optionen 
aktualisieren:
<example>update-alternatives --install /usr/bin/x-window-manager \
x-window-manager /usr/local/bin/wmaker-cvs 50</example></p>

<p>Das erste Argument für die »<tt>--install</tt>«-Option ist der symbolische
Verweis, der auf <file>/etc/alternatives/<var>NAME</var></file> zeigt, wobei 
<var>NAME</var> das zweite Argument ist. Das dritte Argument ist das Programm,
auf welches <file>/etc/alternatives/<var>NAME</var></file> zeigen soll, und das vierte Argument
ist die Priorität (ein größerer Wert bedeutet, dass diese Alternative
wahrscheinlicher automatisch ausgewählt wird).</p>

<p>Um eine Alternative, die Sie hinzugefügt haben, wieder zu entfernen, führen
Sie einfach folgenden Befehl aus:
<example>update-alternatives --remove x-window-manager \
/usr/local/bin/wmaker-cvs</example></p>
