[ 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 siehe die
Handbuchseite papersize(5)
.
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.
Die Pakete kbd
und console-tools
unterstützen dies.
Editieren Sie dazu die Datei /etc/kbd/config
oder
/etc/console-tools/config
.
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.
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:
0 (das System anhalten),
1 (Einzel-Benutzer-Modus),
2 bis 5 (verschiedene Mehr-Benutzer-Modi) und
6 (das System neu starten).
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.)
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:
Das Skript foo
ins Verzeichnis /etc/init.d/
verschieben.
Den Debian-Befehl update-rc.d
mit den passenden Argumenten
ausführen, um anzugeben, welche Runlevel den Dienst starten und welche ihn
stoppen sollen.
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 »/etc/init.d/foo start« eingeben.
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.
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.
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:
/bin/login
mit login-local
überschreiben.
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 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 folgenden:
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 in der Handbuchseite dpkg-divert(8)
.
Führen Sie folgenden Befehl aus:
dpkg-scanpackges BIN_DIR OVERRIDE_FILE [PATHPREFIX] > meine_Pakete
Dabei ist
BIN_DIR ein Verzeichnis, in welches Debian-Archiv-Dateien (welche üblicherweise die Endung ».deb« haben) gespeichert sind.
OVERRIDE_FILE eine Datei, die von den Betreuern der Distribution editiert
worden ist und üblicherweise in einem Debian-FTP-Archiv in
indices/override.main.gz
gespeichert ist für Debian-Pakete in der
»Main«-Distribution. Sie können dies für lokale Pakete ignorieren.
PATHPREFIX eine optionale Zeichenkette, die der zu erstellenden
meine_Pakete
-Datei vorangestellt werden kann.
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.
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+nmu1, 3 January 2010