Re: FAQ -- Kapitel 10 -- customizing.sgml
Hallo Jonas,
On Mon, Apr 17, 2006 at 08:16:28PM +0200, Jonas E. Huber wrote:
> Ich habe «mein» zweites FAQ-Kapitel übersetzt und sende nun den
> Patch gegen das (eng. Original) ebenfalls mit der Bitte um
> Kritik/Korrekturen sowie Einchecken an die Liste!
ah, prima.
Ich habe es eingecheckt und schnell korekturgelesen.
Einige Bemerkungen:
* Der Patch war gegen die englische Version, nicht die in de/.
* Da du die komplette Datei übersetzt hast, wäre die Übersetzung
vielleicht besser als ein Patch, zumindest kleiner und lesbarer :-).
* Als Anführungszeichen bitte »...« nicht «...» verwenden.
Anbei die aktuelle korrekturgelesene Datei.
Jens
<!-- CVS revision of original english document "1.13" -->
<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>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">.
<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>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.
<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>.
<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.
<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 gabelt, um Initialisationen
durchzuführen, wie zum Beispiel Dateisysteme zu prüfen und mounten, 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>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>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>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>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.)
<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 die Verweise zwischen den (in der Befehlszeile spezifizierten)
Verzeichnissen <file>rc?.d</file> und <file>/etc/init.d/foo</file> (das »?« ist eine
Nummer zwischen 0 und 6, die je einem der System-V-Runlevel entspricht)
einzurichten,
<item>das System neu starten.
</list>
<p>Der Befehl <prgn>update-rc.d</prgn> richtet Verweise zwischen den Dateien
in den <file>rc?.d</file>-Verzeichnissen und dem Skript in <file>/etc/init.d/</file>
ein. Jeder Verweis beginnt entweder mit einem »S« oder einem »K«, gefolgt
von einer Nummer, der wiederum der Name des Skripts folgt. Skripte in
<file>/etc/rc<var>N</var>.d/</file>, die mit einem »S« beginnen, werden ausgeführt,
wenn in den Runlevel <var>N</var> gewechselt wird. Skripte, die mit einem
»K« beginnen, werden beim Verlassen des Runlevels <var>N</var> ausgeführt.
<p>Man könnte also 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. Das
Argument »19« führt dazu, dass <tt>foo</tt> vor allen Skripte mit Nummer 20
oder höher aufgerufen wird.
<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«
aktualisiert wird.
<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.
<!-- 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>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.
<!-- XXX dpkg-divert: is this correct ? -->
<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>Details dazu finden Sie in der Handbuchseite <manref name="dpkg-divert" section="8">.
<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>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>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>Wenn Sie APT verwenden, können Sie auch das lokale Paketdepot zu Ihrer
<manref name="sources.list" section="5">-Datei hinzufügen.
<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>Debian verwendet ein »virtuelles« Paketsystem um den Systemadministratoren
zu erlauben, ihre favorisierten (oder jene der Benutzer) 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>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>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>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>Wenn ein Paket sich selbst aus irgend einem Grund nicht als Fenstermanager
(senden Sie einen Fehlerbericht, wenn es ein Fehler ist) registriert, 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>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>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>
Reply to: