[ zurück ] [ Inhalt ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ 16 ] [ weiter ]


Die Debian GNU/Linux-FAQ
Kapitel 11 - Anpassen Ihrer Debian GNU/Linux-Installation


11.1 Wie kann ich sicherstellen, dass alle Programme die selbe 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 siehe die Handbuchseite papersize(5).


11.2 Wie kann kann ich Zugang zu Peripheriegeräten zur Verfügung stellen ohne die Sicherheit zu kompromittieren?

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

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

     adduser user group

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

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

Beachten Sie, dass seit der Einführung von udev 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 /etc/udev anpassen müssen.


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

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


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

Die Debian-X-Programme installieren ihre Anwendungs-Ressource-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 Jede Distribution scheint eine andere boot-up-Methode zu haben. Beschreiben Sie jene von Debian.

Wie alle Unices bootet Debian durch das Ausführen des Programms init. Die Konfigurationsdatei für init (sie heißt /etc/inittab) spezifiziert, dass das erste auszuführende Skript /etc/init.d/rcS sein sollte. Dieses Skript führt alle Skripte im /etc/rcS.d/-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 /etc/rc.boot/ (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.

Nachdem der Boot-Prozess abgeschlossen ist, führt init alle Start-Skripte in einem durch den Standard-Runlevel (dieser Runlevel wird durch den Eintrag id in /etc/inittab festgelegt) spezifizierten Verzeichnis aus. Wie alle zu System V kompatiblen Unices hat Linux 7 Runlevel:

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 /etc/rc2.d/ ausgeführt werden.

Tatsächlich sind die Skripte in jedem der Verzeichnisse /etc/rcN.d/ nur symbolische Verweise zurück auf Skripte in /etc/init.d/. Wie auch immer, die Namen der Dateien in jedem der /etc/rcN.d/-Verzeichnisse sind so gewählt, dass sie darauf hinweisen, 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 dem »K« oder dem »S« folgt, bestimmt die Reihenfolge, in welcher die Skripte ausgeführt werden. Jene mit kleinerer Nummer werden zuerst ausgeführt.

Diese Methode funktioniert, weil die Skripte in /etc/init.d/ 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.

Zum Beispiel sendet das Argument »reload« im Befehl

     /etc/init.d/sendmail reload

dem sendmail-Daemon ein Signal, seine Konfigurationsdatei neu einzulesen. (Übrigens stellt Debian mit invoke-rc.d einen Wrapper zum Aufruf der Skripte in /etc/init.d/ zur Verfügung.)


11.6 Es scheint so, als ob Debian rc.local nicht zum Anpassen des Bootprozesses verwendet; welche Einrichtungen gibt es?

Nehmen Sie an, ein System solle beim Hochfahren das Skript foo ausführen oder einen bestimmten (System-V-) Runlevel aktivieren. Dann sollte der Systemadministrator:

Man könnte zum Beispiel das Skript foo beim Systemstart ausführen lassen, indem man es nach /etc/init.d/ kopiert und die Verweise mit update-rc.d foo defaults 19 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 foo haben Vorrang, wenn die sysv-rc-Version von update-rc.d verwendet wird, werden aber von der aktuellen (v0.8.10) file-rc-Version von update-rc.d ignoriert.) Das Argument »19« führt dazu, dass foo vor allen Skripten mit Nummer 20 oder höher aufgerufen wird.


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

Daher ist es besser, ein lokales Paket zu erstellen, das die Konfigurationsdateien der »Gruppe« der jeweiligen Debian-Pakete modifiziert. Dann sieht 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.


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

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

Sie sollten nicht:

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

Tun Sie besser Folgendes:

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

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


11.9 Wie kann ich meine lokal erstellten Pakete in die Liste der verfügbaren Pakete, von denen das Paketmanagementsystem weiß, aufnehmen?

Führen Sie folgenden Befehl aus:

     dpkg-scanpackges BIN_DIR OVERRIDE_FILE [PATHPREFIX] > meine_Pakete

Dabei ist

Wenn Sie die Datei meine_Pakete einmal erstellt haben, teilen Sie dies dem Paketverwaltungssystem mit, indem Sie folgenden Befehl benutzen:

     dpkg --merge-avail meine_Pakete

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


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

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.

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

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 update-alternatives stellt einen Weg bereit sicherzustellen, dass alle Dateien, die mit einem bestimmten Paket in Verbindung stehen, als ein systemweiter Standard gewählt 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 wollen, führen Sie diesen Befehl aus:

     update-alternatives --config x-window-manager

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

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 /usr/local/-Verzeichnis verwenden, werden die Auswahlmöglichkeiten auf dem Bildschirm Ihren bevorzugten Eintrag nicht enthalten. Sie können den Verweis ü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 ist 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

[ zurück ] [ Inhalt ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ 16 ] [ weiter ]


Die Debian GNU/Linux-FAQ

Version 4.0.4+nmu1ubuntu1, 16 April 2010

Die Autoren der Debian-FAQ