Kapitel 11. Anpassen Ihres Debian GNU/Linux-Systems

# Kapitel 11. Anpassen Ihres Debian GNU/Linux-Systems

## 11.1. Wie kann ich sicherstellen, dass alle Programme dieselbe Papiergröße verwenden?

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

Benutzer können sich über die Papiergrößen-Einstellung hinwegsetzen, indem sie die `PAPERSIZE`-Umgebungsvariable verwenden. Für Details lesen Sie die Handbuchseite papersize(5).

## 11.2. Wie lassen sich ohne Abstriche bei der Sicherheit Peripheriegeräte zur Verfügung stellen?

Viele Gerätedateien im `/dev/`-Verzeichnis gehören zu einer vordefinierten Gruppe. Zum Beispiel gehört `/dev/sr0` zu der Gruppe `cdrom`.

Um einem bestimmten Benutzer Zugriff auf eines dieser Geräte einzuräumen, fügen Sie ihn zu der Gruppe hinzu, der das Gerät gehört, also z.B.:

    adduser user group

Auf diese Art müssen Sie die Dateiberechtigungen des Gerätes nicht ändern.

Wenn Sie diese Änderung auf der Shell eines Benutzers oder einer grafischen Benutzerumgebung vornehmen, müssen Sie sich anschließend einmal abmelden und wieder neu anmelden, damit die Änderungen wirksam werden. Um herauszufinden, welchen Gruppen Sie angehören, verwenden Sie den Befehl `groups`.

Hinweis: Seit der Einführung von `udev` kann es vorkommen, dass Ihrerseits geänderte Berechtigungen für Peripheriegeräte nach einem Systemstart wieder zurückgesetzt sind. Falls für Sie relevante Geräte davon betroffen sind, müssen Sie die Regeln in `/etc/udev` anpassen.

## 11.3. Wie kann ich eine Konsolen-Schriftart auf Debian-Art beim Systemstart laden?

Das Paket `kbd` lässt sich entsprechend konfigurieren. Editieren Sie dazu die Datei `/etc/kbd/config`.

## 11.4. Wie kann ich die Standardeinstellung eines X11-Programms konfigurieren?

Die Debian-X-Programme installieren ihre Anwendungs-Ressourcen-Daten im Verzeichnis `/etc/X11/app-defaults/`. 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.

## 11.5. Wie wird ein Debian-System hochgefahren?

Wie alle Unix-Systeme wird Debian durch das Ausführen des Programms `init` gebootet. Wie die meisten Linux-Distributionen verwendet ein Standard-Debian-System `systemd` als `init`-Implementierung. Traditionelle Init-Systeme im Stil von System-V und weitere Methoden werden aber ebenfalls unterstützt. [6]

Um die Reihenfolge zu steuern, nach der Dienste gestartet werden, nutzen traditionelle System-V-artige Unix-Systeme das Konzept der Runlevels. Diese wurden in systemd durch die Targets ersetzt. Um den Standard-Target anzuzeigen, in welchen systemd das System beim Starten bringt, führen Sie folgenden Befehl aus:

    systemctl get-default

Während des Bootens startet systemd die Dienste oder auch weitere Targets, die in der Standard-Target-Datei `/lib/systemd/system/default.target` eingetragen sind. Die Dateien für diese Dienste und Targets werden während der Installation des entsprechenden Debian-Pakets installiert und aktiviert. Wenn Sie einen bestimmten Dienst während des Bootens nicht gestartet haben möchten, können Sie (statt das zugehörige Paket zu entfernen) auch folgendes ausführen:

    systemctl disable service.service

Nutzen Sie dabei den Namen der service-Datei, welche in `/lib/systemd/system` zu finden ist (üblicherweise entspricht oder ähnelt diese dem Namen des Pakets).

Die service-Datei `/lib/systemd/system/rc-local.service` bietet eine einfache Möglichkeit, um eigene Skripte in der Datei `/etc/rc.local` beim Booten auszuführen, ähnlich der Technik, die von Debian-Systemen mit System-V-artigem Init bekannt ist. Beachten Sie aber: dieses Skript wird fehlschlagen, wenn es versucht, mit der Konsole zu interagieren, z.B. um das Passwort eines Benutzers abzufragen oder zu versuchen, den Bildschirm zu leeren.

Den Status eines Dienstes können Sie abfragen mit dem Befehl

    service Paketname status

Um einen Dienst zu starten oder zu stoppen, führen Sie dies aus:

    service Paketname start

bzw.

    service Paketname stop

Der `service`-Befehl funktioniert mit jeder Init-Implementierung, die auf Debian-Systemen unterstützt wird, nicht nur mit systemd. Falls Sie es jedoch bevorzugen, auf allen systemd-unterstützten Linux-Systemen den gleichen Befehl zu verwenden, um den Status abzufragen, nutzen Sie dies:

    systemctl status Paketname.service

Sie erhalten damit die gleichen Informationen.

Weitere Informationen über systemd für Debian finden Sie auf https://wiki.debian.org/systemd.

## 11.6. Und wie ist es mit Debian und dem traditionellen System V init?

Debian unterstützt das Hochfahren mit Hilfe des traditionellen »System V init«, das vom Paket sysvinit-core bereitgestellt wird. Die Konfigurationsdatei für System V `init` ist `/etc/inittab`. Darin wird festgelegt, dass `/etc/init.d/rcS` als erstes Skript ausgeführt werden soll. Dieses Skript startet alle Skripte im `/etc/rcS.d/`-Verzeichnis, indem es sie als eigene Unterprozesse laufen lässt; dabei werden Initialisierungen durchgeführt, wie zum Beispiel Dateisysteme prüfen und einbinden, Module laden, Netzwerkdienste starten, die Uhr stellen und weitere.

Nachdem der Boot-Prozess abgeschlossen ist, führt `init` alle Start-Skripte in dem zum Standard-Runlevel gehörenden Verzeichnis aus. Dieses Runlevel wird durch den Eintrag `id` in `/etc/inittab` festgelegt. Wie alle zu System V kompatiblen Unix-Systeme hat Linux 7 Runlevel:

- 0 (das System anhalten),

- 1 (Einzelbenutzer-Modus),

- 2 bis 5 (verschiedene Mehrbenutzer-Modi) und

- 6 (das System neu starten).

Debian-Systeme haben »id=2« als Standardeinstellung, was bedeutet, dass der Standard-Runlevel »2« ist, wenn das Mehrbenutzer-Level gestartet wird, und dass die Skripte in `/etc/rc2.d/` ausgeführt werden.

Debian verwendet abhängigkeits-basierte Boot-Reihenfolgen durch Nutzung von insserv; dafür werden die LSB-Header in jedem Skript unterhalb von `/etc/init.d/` verwendet. Außerdem setzt Debian parallele (gleichzeitig laufende) Boot-Prozesse mittels startpar ein, um den Boot-Vorgang zu beschleunigen.

Letzten Endes sind die Skripte in jedem der Verzeichnisse `/etc/rcN.d/` nur symbolische Verweise zurück auf Skripte in `/etc/init.d/`. Allerdings geben die Namen dieser Dateien an, wie die Skripte in `/etc/init.d/` 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 hinter dem »K« bzw. »S« folgt, bestimmt die Reihenfolge, in welcher die Skripte ausgeführt werden. Jene mit kleinerer Nummer werden zuerst ausgeführt.

Die Methode beruht darauf, dass jedes der Skripte in `/etc/init.d/` eines von fünf möglichen Argumenten, nämlich »start«, »stop«, »reload«, »restart« oder »force-reload« erwartet und den jeweiligen Dienst dann entsprechend steuert. Diese Skripte können auch nach dem Starten des Systems noch benutzt werden, um verschiedene Prozesse zu kontrollieren.

Folgender Befehl mit dem Argument »reload«

    /etc/init.d/sendmail reload

sendet dem sendmail-Daemon ein Signal, seine Konfigurationsdatei neu einzulesen.

Beachten Sie, dass invoke-rc.d nicht benutzt werden sollte, um die Skripte in `/etc/init.d/` aufzurufen; verwenden Sie stattdessen service.

## 11.7. Und gibt es noch weitere Möglichkeiten, ein Debian-System zu booten?

Wenn Sie das System-V-Init mögen, aber nicht die Vorgehensweise der Links wie /etc/rc?.d/*, können Sie das Paket `file-rc` installieren. Es konvertiert die Links stattdessen in eine einzige Konfigurationsdatei /etc/runlevel.conf.

Falls Sie weder System-V noch systemd mögen, können Sie vielleicht mit`openrc`, `runit` oder `daemontools` glücklich werden.

## 11.8. Wie geht das Paketverwaltungssystem mit Paketen um, die Konfigurationsdateien für andere Pakete enthalten?

Manche Benutzer möchten zum Beispiel einen neuen Server einrichten, indem sie eine Gruppe von Debian-Paketen installieren sowie ein lokal generiertes Paket, welches aus Konfigurationsdateien besteht. Dies ist grundsätzlich keine gute Idee, weil dpkg nichts über diese Konfigurationsdateien weiß, wenn sie in einem anderen Paket enthalten sind. dpkg könnte daher unpassende Konfigurationen schreiben, wenn eines der ursprünglichen Pakete aktualisiert wird.

Deshalb ist es besser, ein lokales Paket zu erstellen, das die Konfigurationsdateien einer »Gruppe« von Debian-Paketen modifiziert. Dann registriert dpkg und der Rest des Paketverwaltungssystems, dass diese Dateien durch den lokalen Systemverwalter modifiziert worden sind und versucht nicht, sie bei einer Paketaktualisierung zu überschreiben.

## 11.9. Wie kann ich eine durch ein Paket installierte Datei außer Kraft setzen, so dass stattdessen eine andere Version verwendet werden kann?

Nehmen wir an, dass ein Systemadministrator oder ein lokaler Benutzer lieber ein Programm namens login-local anstatt dem vom Debian-Paket `login` zur Verfügung gestellten Programm `login` verwenden möchte.

Sie sollten nicht:

- `/bin/login` mit `login-local` überschreiben.

Das Paketverwaltungssystem weiß nichts über diese Veränderung und wird einfach Ihr angepasstes `/bin/login` überschreiben, wann immer login (oder jedes andere Paket, welches `/bin/login` bereitstellt) installiert oder aktualisiert wird.

Tun Sie besser Folgendes:

- Führen Sie folgenden Befehl aus:

      dpkg-divert --divert /bin/login.debian /bin/login

  Dies führt dazu, dass bei allen zukünftigen Installationen des Debian-Pakets `login` die Datei `/bin/login` nach `/bin/login.debian` geschrieben wird.

- Und dann:

      cp login-local /bin/login

  Dadurch wird Ihr eigenes lokal erstelltes Programm an den richtigen Ort kopiert.

Führen Sie `dpkg-divert --list` aus, um zu sehen, welche Umleitungen auf Ihrem System aktiv sind.

Details dazu finden Sie auf der Handbuchseite dpkg-divert(8).

## 11.10. Wie kann ich meine lokal erstellten Pakete in die Liste der verfügbaren Pakete, die dem Paketmanagementsystem bekannt sind, aufnehmen?

Führen Sie folgenden Befehl aus:

    dpkg-scanpackages BIN_DIR OVERRIDE_FILE [PATHPREFIX] > meine_Pakete

Dabei ist:

- BIN_DIR ein Verzeichnis, in welchem Debian-Archiv-Dateien (üblicherweise mit der Endung ».deb«) gespeichert sind.

- OVERRIDE_FILE eine Datei, die von den Betreuern der Distribution editiert worden ist und für Debian-Pakete aus der »Main«-Distribution normalerweise im Debian-Archiv unter `indices/override.main.gz` liegt. Für lokale Pakete entfällt dieses Argument.

- PATHPREFIX eine optionale Zeichenkette, die der zu erstellenden Datei `meine_Pakete` vorangestellt werden kann.

Wenn Sie die Datei `meine_Pakete` erstellt haben, teilen Sie dies dem Paketverwaltungssystem über folgenden Befehl mit:

    dpkg --merge-avail meine_Pakete

Wenn Sie APT verwenden, können Sie das lokale Paketdepot auch zu Ihrer sources.list(5)-Datei hinzufügen.

## 11.11. Einige Benutzer mögen mawk, andere gawk; einige mögen vim, andere elvis; einige trn, wieder andere tin; wie unterstützt Debian die Vielfalt?

Es gibt verschiedene Fälle, in denen zwei Pakete zwei verschiedene Versionen eines Programms zur Verfügung stellen, wobei beide dieselben 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 demselben System könnten eine andere Wahl treffen.

Wenn zwei oder mehr Hilfsprogramme dieselben Grundfunktionen aufweisen und eine generell formulierte Paketabhängigkeit erfüllen, ermöglicht es Debian Systemadministratoren oder Benutzern, durch ein »virtuelles« Paketystem festzulegen, welches vorgezogen wird.

Zum Beispiel könnten zwei verschiedene Versionen eines Newsreaders auf einem System existieren. Das Newsserver-Paket könnte »empfehlen«, dass überhaupt ein Newsreader auf dem System installiert ist, aber die Wahl von `tin` oder `trn` ist dem jeweiligen Benutzer überlassen. Dies wird erreicht, indem die beiden Pakete `tin` und `trn` das virtuelle Paket `news-reader` bereitstellen. Welches der Programme tatsächlich aufgerufen wird, wird durch einen Verweis von `/etc/alternatives/news-reader` (dem Namen des virtuellen Pakets) auf die Binärdatei des ausgewählten Programms (z.B. `/usr/bin/trn`) bestimmt.

Für die Nutzung alternativer Programme reicht eine einzelne symbolische Verknüpfung nicht aus. Der Auswahlmechanismus muss auch Handbuchseiten und sonstige zugehörige Dateien berücksichtigen. Das Perl-Skript `update-alternatives` stellt sicher, dass alle zu einem ausgewählten Paket gehörenden Dateien systemweit als Standard herangezogen werden.

Um zum Beispiel zu kontrollieren, welche ausführbaren Dateien »x-window-manager« bereitstellen, führen Sie folgenden Befehl aus:

    update-alternatives --display x-window-manager

Wenn Sie dies ändern möchten, verwenden Sie

    update-alternatives --config x-window-manager

und folgen den Anweisungen auf dem Bildschirm (einfach gesagt: geben Sie Sie die Zahl für den Eintrag ein, den Sie bevorzugen).

Wenn ein Paket sich selbst aus irgend einem Grund nicht als Fenstermanager registriert (senden Sie einen Fehlerbericht, falls es ein Fehler ist), oder wenn Sie einen Fenstermanager aus dem `/usr/local/`-Verzeichnis verwenden, werden die Auswahlmöglichkeiten auf dem Bildschirm Ihren bevorzugten Eintrag nicht enthalten. Sie können den Verweis aber über Befehlszeilen-Optionen aktualisieren:

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

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

Um eine Alternative, die Sie hinzugefügt haben, wieder zu entfernen, führen Sie einfach folgenden Befehl aus:

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

[6] In 2014 änderte Debian sein Standard-Init-System von System-V-Init zu systemd. Debian 8 "Jessie" im April 2015 war die erste Veröffentlichung, die mit systemd als standardmäßiges Init-System ausgeliefert wurde. Vier Entscheidungen von Debians Technischem Ausschuss waren hierbei involviert: Fehlerbericht #727708 2014-02-11: "Der Ausschuss entschied, dass das Standard-init-System für Linux-Architekturen in Jessie systemd sein sollte." Fehlerbericht #746715 2014-08-01: "Der Technische Ausschuss erwartet von den Betreuern, dass sie weiterhin die verschiedenen verfügbaren Init-Systeme unterstützen", und begründete Änderungen dazu implementieren. Fehlerbericht #746578 2014-11-15: "Der Ausschuss entschied, dass systemd-shim die erste aufgelistete alternative Abhängigkeit von libpam-systemd sein soll statt systemd-sysv." Diese Entscheidung machte es einfacher, ein Debian-System mit nicht-systemd-Init weiter zu betreiben. Fehlerbericht #7621942017-11-04: "Zu automatischer Init-System-Umstellung bei System-Upgrade".

Kapitel 10. Debian und der Kernel |  | Kapitel 12. Unterstützung für Debian GNU/Linux erhalten