[ zurück ] [ Inhalt ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ 16 ] [ weiter ]
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)
.
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.
Das Paket kbd
lässt sich entsprechend konfigurieren. Editieren
Sie dazu die Datei /etc/kbd/config.
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.
Wie alle Unix-Systeme bootet Debian durch das Ausführen des Programms init [5]. /etc/inittab, die Konfigurationsdatei für init, legt fest, 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
.
Das rc.local-Skript wird als letztes in jedem Mehrbenutzer-Runlevel ausgeführt. In Debian bewirkt es standardmäßig nichts. Dies gestattet es, den Boot-Prozess an eigene Anforderungen anzupassen, wobei man damit unter Umständen nicht jeder Situation gerecht wird.
Nehmen wir an, ein System soll beim Hochfahren oder bei Aktivierung eines bestimmten (System-V-) Runlevels das Skript foo ausführen. Dann sollte der Systemadministrator:
Das Skript foo ins Verzeichnis /etc/init.d/ einfügen.
Den Debian-Befehl update-rc.d mit den passenden Argumenten ausführen, um anzugeben, welche Runlevel den Dienst starten und welche ihn stoppen sollen.
Das System am besten neu starten, um zu überprüfen, ob der Dienst richtig startet (vorausgesetzt, dass der Dienst in einem der Standard-Runlevel starten soll). Andernfalls starten Sie den Dienst über »/etc/init.d/foo start«.
Man könnte zum Beispiel das Skript foo beim Systemstart ausführen lassen, indem man es in /etc/init.d/ einfügt und update-rc.d foo defaults 19 aufruft. Das Argument »defaults« bezieht sich auf die Standard-Runlevel, also 2 bis 5. 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 Default-Start«- und »LSB Default-Stop«-Anweisungen in foo haben Vorrang, wenn die sysv-rc-Version von update-rc.d verwendet wird, sie werden aber von der file-rc-Variante von update-rc.d (v0.8.10 und höher) ignoriert.) Das Argument »19« führt dazu, dass foo aufgerufen wird, sobald alle Skripte mit Nummern kleiner 19 beendet wurden und vor allen Skripten mit Nummer 20 oder höher.
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.
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)
.
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-FTP-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.
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
[ 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 8.1ubuntu1, 2 January 2017