Inhaltsverzeichnis
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.
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.
Like all Unices, Debian boots up by executing the program
init
. Like most Linux distributions, a default Debian
system uses systemd
as the implementation of
init
. Traditional System-V style init and other methods
are also supported. [6]
To control the order in which services are started, traditional System-V style Unix systems use runlevels. These are replaced by targets under systemd. To display the default target to which systemd will bring the system, run the command
systemctl get-default
During boot-up, systemd starts the services or other targets listed in the
default target file /lib/systemd/system/default.target
.
The files for these services and targets are installed and the service is
enabled during Debian package installation. If you
specifically wish not to start a service during boot-up, instead of removing
the corresponding package, you can run the command
systemctl disable service
.service
using the name of the service file installed in
/lib/systemd/system
(usually based on the name of the
package).
The service file
/lib/systemd/rc.local.service
provides an easy way to run
customized scripts in the file /etc/rc.local
after
boot-up, similar to what's offered on Debian systems running System-V style
init. Beware: this script will fail if it tries to interact with the
console such as asking for a user password or trying to clear the screen.
You can check the status of any service by the command
service Paketname
status
. To start or stop a service, run
service Paketname
start
and
service Paketname
stop
. The service
command works with any init system
supported on a Debian system, not just with systemd. If you however prefer
to use the same command on any systemd-supported Linux system, for checking
the status run
systemctl status Paketname
.service
to get the same information.
For more information on systemd for Debian, see https://wiki.debian.org/systemd.
Debian supports booting using traditional System V init, via the
sysvinit-core package. The configuration file for System V
init
(which is /etc/inittab
) specifies
that the first script to be executed should be
/etc/init.d/rcS
. This script runs all of the scripts in
/etc/rcS.d/
by forking subprocesses to perform
initialization such as to check and to mount file systems, to load modules,
to start the network services, to set the clock, and to perform other
initialization.
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.
If you do like System V init, but don't like the /etc/rc?.d/* links, you
could install the file-rc
package.
That will convert the links into one single configuration file
/etc/runlevel.conf instead.
If you like neither System V nor systemd, you might like openrc
or runit
or daemontools
.
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/
zeigt, wobei NAME
NAME
das zweite Argument ist. Das
dritte Argument ist das Programm, auf welches
/etc/alternatives/
zeigen soll, und das vierte Argument die Priorität (ein größerer Wert
bedeutet, dass diese Alternative wahrscheinlicher automatisch ausgewählt
wird).
NAME
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, Debian changed its default init system from System V init to systemd. Debian 8 "jessie" in April 2015 was the first release to ship with systemd as default init. Four decisions of the Debian Technical Committee were involved: Bug #727708 2014-02-11: "The committee decided that the default init system for Linux architectures in jessie should be systemd." Bug #746715 2014-08-01: "The technical committee expects maintainers to continue to support the multiple available init systems", and merge reasonable contributions. Bug #746578 2014-11-15: "The committee decided that systemd-shim should be the first listed alternative dependency of libpam-systemd instead of systemd-sysv." This decision made it easier to keep running a non-systemd Debian system. Bug #7621942017-11-04: "On automatic init system switching on upgrade"