Zum Inhalt springen
documentation.suse.com / Verwaltungshandbuch
SUSE Linux Enterprise Server 15 SP3

Verwaltungshandbuch

 

Dieses Handbuch behandelt Systemverwaltungsaufgaben wie Wartung, Überwachung und Anpassung eines neu installierten Systems.

Veröffentlicht: 29. September 2024
Abbildungsverzeichnis
Tabellenverzeichnis
Liste der Beispiele

Copyright © 2006–2024 SUSE LLC und Mitwirkende. Alle Rechte vorbehalten.

Es wird die Genehmigung erteilt, dieses Dokument unter den Bedingungen der GNU Free Documentation License, Version 1.2 oder (optional) Version 1.3 zu vervielfältigen, zu verbreiten und/oder zu verändern; die unveränderlichen Abschnitte hierbei sind der Urheberrechtshinweis und die Lizenzbedingungen. Eine Kopie dieser Lizenz (Version 1.2) finden Sie im Abschnitt „GNU Free Documentation License“.

Die SUSE-Marken finden Sie unter https://www.suse.com/company/legal/. Alle anderen Marken von Drittanbietern sind Besitz ihrer jeweiligen Eigentümer. Markensymbole (®, ™ usw.) kennzeichnen Marken von SUSE und der Tochtergesellschaften. Sternchen (*) kennzeichnen Marken von Drittanbietern.

Alle Informationen in diesem Buch wurden mit größter Sorgfalt zusammengestellt. Doch auch dadurch kann hundertprozentige Richtigkeit nicht gewährleistet werden. Weder SUSE LLC noch ihre Tochtergesellschaften noch die Autoren noch die Übersetzer können für mögliche Fehler und deren Folgen haftbar gemacht werden.

Vorwort

 

1 Verfügbare Dokumentation

 
Online-Dokumentation

Die Online-Dokumentation zu diesem Produkt ist unter https://documentation.suse.com/#sles verfügbar. Durchsuchen Sie die Dokumentation oder laden Sie sie in verschiedenen Formaten herunter.

Die Online-Dokumentation für andere Produkte finden Sie unter https://documentation.suse.com/.

Anmerkung
Anmerkung: Neueste Aktualisierungen

Die neuesten Aktualisierungen der Dokumentation sind normalerweise in der englischen Version der Dokumentation verfügbar.

Versionshinweise

Die Versionshinweise finden Sie unter https://www.suse.com/releasenotes/.

In Ihrem System

Für die Offline-Nutzung finden Sie die Dokumentation in Ihrem installierten System unter /usr/share/doc. Viele Kommandos sind auch detailliert auf den Handbuchseiten beschrieben. Führen Sie zu deren Anzeige man gefolgt von einem bestimmten Kommandonamen aus. Sollte das man-Kommando nicht auf Ihrem System installiert sein, müssen Sie es mit sudo zypper install man installieren.

2 Verbessern der Dokumentation

 

Ihr Feedback und Beiträge zu dieser Dokumentation sind willkommen. Mehrere Kanäle stehen zur Verfügung:

Serviceanforderungen und Support

Informationen zu Diensten und Support-Optionen, die für Ihr Produkt verfügbar sind, finden Sie unter https://www.suse.com/support/.

Zum Öffnen einer Service-Anforderung benötigen Sie ein Abonnement beim SUSE Customer Center. Gehen Sie zu https://scc.suse.com/support/requests, melden Sie sich an und klicken Sie auf Neu erstellen.

Fehlerberichte

Melden Sie Probleme mit der Dokumentation unter https://bugzilla.suse.com/. Zur Vereinfachung dieses Vorgangs können Sie die Links Report Documentation Bug (Fehler in der Dokumentation melden) neben den Überschriften in der HTML-Version dieses Dokuments verwenden. Dadurch wird das richtige Produkt und die Kategorie in Bugzilla vorab ausgewählt und ein Link zum aktuellen Abschnitt hinzugefügt. Sie können somit sofort mit der Eingabe Ihres Berichts beginnen. Ein Bugzilla-Konto ist erforderlich.

Beiträge

Verwenden Sie für einen Beitrag zu dieser Dokumentation die Links Edit Source (Quelle bearbeiten) neben den Überschriften in der HTML-Version dieses Dokuments. Sie führen Sie zum Quellcode auf GitHub, wo Sie eine Pull-Anforderung öffnen können. Ein GitHub-Konto ist erforderlich.

Weitere Informationen zur Dokumentationsumgebung für diese Dokumentation finden Sie in der README des Repositorys.

Email

Alternativ können Sie Emails mit Fehlerberichten und Feedback zur Dokumentation an <> senden. Geben Sie auf jeden Fall auch den Titel der Dokumentation, die Produktversion und das Datum der Veröffentlichung der Dokumentation an. Beziehen Sie sich auf die entsprechende Abschnittsnummer und den Titel (oder geben Sie die URL an) und fügen Sie eine kurze Beschreibung des Problems hinzu.

3 Konventionen in der Dokumentation

 

In der vorliegenden Dokumentation werden die folgenden Hinweise und typografischen Konventionen verwendet:

  • /etc/passwd: Verzeichnis- und Dateinamen

  • PLATZHALTER: Ersetzen Sie PLATZHALTER durch den tatsächlichen Wert.

  • PATH: die Umgebungsvariable PATH

  • ls, --help: Kommandos, Optionen und Parameter

  • Benutzer: Benutzer oder Gruppen

  • Paketname: Name eines Pakets

  • Alt, Alt–F1: Eine Taste oder Tastenkombination. Tastennamen werden wie auf der Tastatur in Großbuchstaben dargestellt.

  • Datei, Datei › Speichern unter: Menüelemente, Schaltflächen

  • AMD/Intel Dieser Absatz ist nur für die AMD64-/Intel-64-Architektur relevant. Die Pfeile kennzeichnen den Anfang und das Ende des Textblocks.

    IBM Z, POWER Dieser Absatz ist nur für die Architekturen IBM Z und POWER relevant. Die Pfeile kennzeichnen den Anfang und das Ende des Textblocks.

  • Tanzende Pinguine (Kapitel Pinguine, ↑Zusätzliches Handbuch): Dies ist ein Verweis auf ein Kapitel in einem anderen Handbuch.

  • Kommandos, die mit root-Privilegien ausgeführt werden müssen. Diesen Kommandos kann zur Ausführung als nicht privilegierter Benutzer auch häufig das Präfix sudo vorangestellt sein. 

    root # command
tux > sudo command

  • Kommandos, die von Benutzern ohne Privilegien ausgeführt werden können. 

    tux > command

  • Hinweise

    Warnung
    Warnung: Warnhinweis

    Wichtige Informationen, die Sie kennen müssen, bevor Sie fortfahren. Warnt vor Sicherheitsrisiken, potenziellen Datenverlusten, Beschädigung der Hardware oder physischen Gefahren.

    Wichtig
    Wichtig: Wichtiger Hinweis

    Wichtige Informationen, die Sie beachten sollten, bevor Sie den Vorgang fortsetzen.

    Anmerkung
    Anmerkung: Anmerkung

    Ergänzende Informationen, beispielsweise zu unterschiedlichen Softwareversionen.

    Tipp
    Tipp: Tipp

    Hilfreiche Informationen, etwa als Richtlinie oder praktische Empfehlung.

4 Support

 

Im Folgenden finden Sie die Supportbestimmung für SUSE Linux Enterprise Server sowie allgemeine Informationen über Technologievorschauen. Details über den Produktlebenszyklus finden Sie im Book “Upgradehandbuch”, Chapter 2 “Lebenszyklus und Support”.

Wenn Sie Anspruch auf Support haben, finden Sie Details zum Sammeln von Informationen für ein Support-Ticket im Kapitel 39, Erfassen der Systeminformationen für den Support.

4.1 Supportbestimmung für SUSE Linux Enterprise Server

 

Sie benötigen ein entsprechendes Abonnement bei SUSE, um Support zu erhalten. Gehen Sie zur Anzeige der für Sie verfügbaren spezifischen Support-Angebote zu https://www.suse.com/support/ und wählen Sie das betreffende Produkt aus.

Die Support-Stufen sind folgendermaßen definiert:

L1

Problemermittlung: Technischer Support mit Informationen zur Kompatibilität, Nutzungs-Support, kontinuierliche Wartung, Informationssammlung und einfache Problembehandlung anhand der verfügbaren Dokumentation.

L2

Problemisolierung: Technischer Support zur Datenanalyse, Reproduktion von Kundenproblemen, Isolierung von Problembereichen und Lösung für Probleme, die in Stufe 1 nicht gelöst wurden sowie Vorbereitung für Stufe 3.

L3

Problembehebung: Technischer Support zur Lösung von Problemen durch technische Maßnahmen zur Behebung von Produktfehlern, die durch den Support der Stufe 2 erkannt wurden.

Vertragskunden und Partner erhalten SUSE Linux Enterprise Server mit L3-Support für alle Pakete, ausgenommen:

  • Technologievorschauen

  • Audio, Grafik, Schriftarten und Artwork

  • Pakete, für die ein zusätzlicher Kundenvertrag erforderlich ist

  • Einige Pakete, die im Lieferumfang von Modul Workstation Extension enthalten sind, erhalten nur L2-Support.

  • Pakete mit Namen endend auf -devel (die Header-Dateien und ähnliche Entwicklerressourcen enthalten) werden nur zusammen mit den entsprechenden Hauptpaketen unterstützt.

SUSE unterstützt nur die Nutzung von Originalpaketen. Also unveränderte und nicht kompilierte Pakete.

4.2 Technologievorschauen

 

Mit Technologievorschauen sind Pakete, Stacks oder Funktionen gemeint, die SUSE bereitstellt, um einen kurzen Einblick in bevorstehende Innovationen zu geben. Durch die Vorschauen haben Sie die Möglichkeit, neue Technologien in Ihrer Umgebung zu testen. Über Ihr Feedback würden wir uns sehr freuen. Wenn Sie eine Technologievorschau testen, kontaktieren Sie Ihre Ansprechpartner bei SUSE und teilen Sie ihnen Ihre Erfahrungen und Anwendungsfälle mit. Ihr Input ist für zukünftige Entwicklungen sehr hilfreich.

Technologievorschauen haben jedoch die folgenden Einschränkungen:

  • Technologievorschauen befinden sich noch in Entwicklung. Daher sind die Funktionen möglicherweise unvollständig oder auf andere Weise nicht für die Produktionsnutzung geeignet.

  • Technologievorschauen werden nicht unterstützt.

  • Technologievorschauen sind möglicherweise nur für bestimmte Hardwarearchitekturen verfügbar.

  • Details und Funktionen von Technologievorschauen sind Änderungen unterworfen. Upgrades auf Folgeversionen sind demnach nicht möglich und erfordern eine Neuinstallation.

  • Technologievorschauen können jederzeit verworfen werden. Zum Beispiel wenn SUSE erkennt, dass eine Vorschau nicht den Kunden- oder Marktanforderungen entspricht oder nachweislich nicht den Unternehmensstandards entspricht. SUSE ist nicht verpflichtet, eine unterstützte Version dieser Technologie in der Zukunft bereitzustellen.

Eine Übersicht der Technologievorschauen, die im Lieferumfang Ihres Produkts enthalten sind, finden Sie in den Versionshinweisen unter https://www.suse.com/releasenotes/.

Teil I Häufige Tasks

 
  • 1 Bash-Shell und Bash-Skripte

    • Heutzutage werden zunehmend Computer mit einer grafischen Bedienoberfläche (GUI) wie GNOME verwendet. GUIs bieten zwar viele Funktionen, kommen jedoch an ihre Grenzen, wenn automatische Aufgaben ausgeführt werden sollen. Shells sind eine gute Ergänzung für GUIs. In diesem Kapitel erhalten Sie einen Überblick über einige Aspekte von Shells, in diesem Fall Bash-Shells.

  • 2 Grundlegende Infos zu sudo

    • Für bestimmte Kommandos sind root-Berechtigungen erforderlich. Die Anmeldung als root ist aus Sicherheitsgründen und zur Vermeidung von Fehlern jedoch nicht zu empfehlen. Es ist sicherer, sich als normaler Benutzer anzumelden und dann mit sudo Kommandos mit höheren Rechten auszuführen.

  • 3 YaST

    • YaST ist ein SUSE Linux Enterprise Server-Tool mit einer grafischen Oberfläche für alle wesentlichen Installations- und Systemkonfigurationsaufgaben. Ob Sie Pakete aktualisieren, einen Drucker konfigurieren, Firewall-Einstellungen bearbeiten, einen FTP-Server einrichten oder eine Festplatte partitio…

  • 4 YaST im Textmodus

    • Die ncurses-basierte pseudo-grafische YaST-Oberfläche sollte vor allem Systemadministratoren bei der Verwaltung von Systemen ohne X-Server unterstützen. Die Oberfläche bietet einige Vorteile im Vergleich zu herkömmlichen grafischen Benutzeroberflächen. Die Navigation auf der ncurses-Oberfläche erfol…

  • 5 YaST-Online-Aktualisierung

    • SUSE stellt fortlaufend Sicherheitsaktualisierungen für Ihr Softwareprodukt bereit. Standardmäßig stellt das Miniprogramm für die Aktualisierung sicher, dass Ihr System stets auf dem neuesten Stand ist. Weitere Informationen zu diesem Miniprogramm finden Sie im Book “Bereitstellungshandbuch”, Chapte…

  • 6 Verwalten von Software mit Kommandozeilenwerkzeugen

    • Dieses Kapitel behandelt zypper und RPM, zwei Kommandozeilen-Tools zum Verwalten von Software. Eine Definition der in diesem Kontext verwendeten Terminologie (beispielsweise Repository, Patch oder Update) finden Sie unter Book “Bereitstellungshandbuch”, Chapter 21 “Installieren bzw. Entfernen von Software”, Section 21.1 “Definition der Begriffe”.

  • 7 Systemwiederherstellung und Snapshot-Verwaltung mit Snapper

    • Mit Snapper werden Dateisystem-Snapshots erstellt und verwaltet. Durch Dateisystem-Snapshots kann eine Kopie des Zustands eines Dateisystems zu einem bestimmten Zeitpunkt beibehalten werden. Die Standardeinrichtung von Snapper lässt ein Rollback von Systemänderungen zu. Sie können es jedoch auch zum Erstellen von Sicherungen der Benutzerdaten auf Wechseldatenträgern verwenden. Als Basis für diese Funktion verwendet Snapper das Btrfs-Dateisystem oder LVM-Volumes mit Thin Provisioning mit einem XFS- oder Ext4-Dateisystem.

  • 8 Live-Kernel-Patching mit KLP

    • In diesem Dokument werden die Grundlagen der Kernel Live Patching-Technologie (KLP) erläutert und Sie finden hier Richtlinien für den SLE Live Patching-Dienst.

  • 9 Transaktionsaktualisierungen

    • Transaktionsaktualisierungen sind in SUSE Linux Enterprise Server als Technologievorschau für die Aktualisierung von SLES verfügbar, wenn das root-Dateisystem schreibgeschützt ist. Transaktionsaktualisierungen sind atomar (alle Aktualisierungen werden nur angewendet, wenn alle Aktualisierungen erfolgreich sind) und unterstützen Rollbacks. Es ist kein laufendes System betroffen, da Änderungen erst aktiviert werden, nachdem das System neu gebootet wurde. Da Reboots eine Störung darstellen, muss der Administrator entscheiden, ob ein Reboot kostspieliger ist als die Störung laufender Services. Wenn Reboots zu kostspielig sind, sollten Sie keine Transaktionsaktualisierungen verwenden.

    Transaktionsaktualisierungen werden täglich vom Skript transactional-update ausgeführt. Das Skript prüft auf verfügbare Aktualisierungen. Falls Aktualisierungen vorhanden sind, erstellt es im Hintergrund einen neuen Snapshot des root-Dateisystems. Danach ruft es die Aktualisierungen von den Versionskanälen ab. Sobald der neue Snapshot vollständig aktualisiert ist, wird er als aktiv gekennzeichnet und wird nach dem nächsten Reboot des Systems zum neuen standardmäßigen root-Dateisystem. Wenn transactional-update automatisch ausgeführt wird (das Standardverhalten), wird das System auch neu gebootet. Sowohl die Zeitdauer für den Aktualisierungsvorgang als auch das Wartungsfenster für den Reboot sind konfigurierbar.

    Es können nur Pakete aktualisiert werden, die Teil des Snapshots des root-Dateisystems sind. Sollten die Pakete Dateien enthalten, die nicht Teil des Snapshots sind, dann könnte die Aktualisierung fehlschlagen oder das System beschädigen.

    RPMs, die eine Lizenz benötigen, um akzeptiert zu werden, können nicht aktualisiert werden.

  • 10 Remote-Grafiksitzungen mit VNC

    • Über VNC (Virtual Network Computing) haben Sie über einen Grafik-Desktop Zugriff auf einen Remote-Rechner und können Remote-Grafikanwendungen ausführen. VNC ist plattformunabhängig und greift auf den Remote-Rechner über ein beliebiges Betriebssystem zu. In diesem Kapitel wird beschrieben, wie mit den Desktop-Clients vncviewer und Remmina eine Verbindung zu einem VNC-Server hergestellt und wie ein VNC-Server betrieben wird.

    SUSE Linux Enterprise Server unterstützt zwei verschiedene Arten von VNC-Sitzungen: einmalige Sitzungen, die so lange „aktiv“ sind, wie die VNC-Verbindung zum Client besteht, und permanente Sitzungen, die so lange „aktiv“ sind, bis sie explizit beendet werden.

    Ein VNC-Server kann beide Sitzungen gleichzeitig auf verschiedenen Ports bieten, eine geöffnete Sitzung kann jedoch nicht von einem Typ in den anderen konvertiert werden.

  • 11 Kopieren von Dateien mit RSync

    • Viele moderne Benutzer arbeiten heutzutage gleich mit mehreren Computern: Computer daheim und am Arbeitsplatz, Laptop, Smartphone oder Tablet. Damit wird die Synchronisierung von Dateien und Dokumenten über mehrere Geräte wichtiger als je zuvor.

1 Bash-Shell und Bash-Skripte

 

Heutzutage werden zunehmend Computer mit einer grafischen Bedienoberfläche (GUI) wie GNOME verwendet. GUIs bieten zwar viele Funktionen, kommen jedoch an ihre Grenzen, wenn automatische Aufgaben ausgeführt werden sollen. Shells sind eine gute Ergänzung für GUIs. In diesem Kapitel erhalten Sie einen Überblick über einige Aspekte von Shells, in diesem Fall Bash-Shells.

1.1 Was ist „die Shell“?

 

Traditionell handelt es sich bei der Linux-Shell um Bash (Bourne again Shell). Wenn in diesem Kapitel die Rede von „der Shell“ ist, ist die Bash-Shell gemeint. Außer Bash sind noch weitere Shells verfügbar (ash, csh, ksh, zsh und viele mehr), von denen jede unterschiedliche Funktionen und Merkmale aufweist. Wenn Sie weitere Informationen über andere Shells wünschen, suchen Sie in YaST nach shell.

1.1.1 Bash-Konfigurationsdateien

 

Eine Shell lässt sich aufrufen als:

  1. Interaktive Login-Shell.  Diese wird zum Anmelden bei einem Computer durch den Aufruf von Bash mit der Option --login verwendet oder beim Anmelden an einem entfernten Computer mit SSH.

  2. „Gewöhnliche“ interaktive Shell.  Dies ist normalerweise beim Starten von xterm, konsole, gnome-terminal oder ähnlichen Kommandozeilenschnittstellen-Tools (CLI-Tools) der Fall.

  3. Nicht interaktive Shell.  Dies wird beim Aufrufen eines Shell-Skripts in der Kommandozeile verwendet.

Abhängig vom verwendeten Shell-Typ werden unterschiedliche Konfigurationsdateien gelesen. Die folgenden Tabellen zeigen die Login- und Nicht-Login-Shell-Konfigurationsdateien.

Tabelle 1.1: Bash-Konfigurationsdateien für Login-Shells
 

Datei

Beschreibung

/etc/profile

Bearbeiten Sie diese Datei nicht, andernfalls werden Ihre Änderungen beim nächsten Update möglicherweise zerstört.

/etc/profile.local

Verwenden Sie diese Datei, wenn Sie /etc/profile erweitern.

/etc/profile.d/

Enthält systemweite Konfigurationsdateien für bestimmte Programme

~/.profile

Fügen Sie hier benutzerspezifische Konfigurationsdaten für Login-Shells ein.

Die Login-Shell greift außerdem auf die unter Tabelle 1.2, „Bash-Konfigurationsdateien für Nicht-Login-Shells“ aufgeführten Konfigurationsdateien zu.

Tabelle 1.2: Bash-Konfigurationsdateien für Nicht-Login-Shells
 

/etc/bash.bashrc

Bearbeiten Sie diese Datei nicht, andernfalls werden Ihre Änderungen beim nächsten Update möglicherweise zerstört.

/etc/bash.bashrc.local

Verwenden Sie diese Datei, um Ihre systemweiten Änderungen nur für die Bash-Shell einzufügen.

~/.bashrc

Fügen Sie hier benutzerspezifische Konfigurationsdaten ein.

Daneben verwendet die Bash-Shell einige weitere Dateien:

Tabelle 1.3: Besondere Dateien für die Bash-Shell
 

Datei

Beschreibung

~/.bash_history

Enthält eine Liste aller Kommandos, die Sie eingegeben haben.

~/.bash_logout

Wird beim Abmelden ausgeführt.

~/.alias

Benutzerdefinierte Aliase für häufig verwendete Kommandos. Weitere Details zum Definieren von Aliasen finden Sie unter man 1 alias.

Shells zur Verhinderung der Anmeldung

Bestimmte Shells verhindern die Anmeldung von Benutzern im System: /bin/false und /sbin/nologin. Beide geben bei Anmeldeversuchen von Benutzern im System automatisch einen Fehler aus. Diese Methode war als Sicherheitsmaßnahme für Systembenutzer gedacht. Moderne Linux-Betriebssysteme kontrollieren den Systemzugriff jedoch inzwischen mit effektiveren Tools wie PAM und AppArmor.

Standardmäßig ist bei SUSE Linux Enterprise Server die Shell /bin/bash menschlichen Benutzern zugewiesen und die Shell /bin/false oder /sbin/nologin Systembenutzern. Dem Benutzer Niemand ist aus historischen Gründen /bin/bash zugewiesen. Es handelt sich dabei um einen Benutzer mit minimalen Rechten, der standardmäßig als Systembenutzer verwendet wurde. Jegliche Sicherheit, die durch den Benutzer Niemand erreicht wird, geht jedoch verloren, wenn er von mehreren Systembenutzern verwendet wird. Es sollte möglich sein, ihn in /sbin/nologin zu ändern. Am schnellsten lässt sich dies testen, wenn Sie die Änderung vornehmen und sehen, ob dadurch Dienste oder Anwendungen beschädigt werden.

Mit folgendem Kommando wird unter /etc/passwdaufgelistet, welche Shells allen Benutzern, Systembenutzern und menschlichen Benutzern zugewiesen sind. Die Ausgabe unterscheidet sich je nach Services und Benutzer in Ihrem System: 

tux > sort -t: -k 7 /etc/passwd | awk -F: '{print $1"\t" $7}' | column -t
tux               /bin/bash
nobody            /bin/bash
root              /bin/bash
avahi             /bin/false
chrony            /bin/false
dhcpd             /bin/false
dnsmasq           /bin/false
ftpsecure         /bin/false
lightdm           /bin/false
mysql             /bin/false
postfix           /bin/false
rtkit             /bin/false
sshd              /bin/false
tftp              /bin/false
unbound           /bin/false
bin               /sbin/nologin
daemon            /sbin/nologin
ftp               /sbin/nologin
lp                /sbin/nologin
mail              /sbin/nologin
man               /sbin/nologin
nscd              /sbin/nologin
polkitd           /sbin/nologin
pulse             /sbin/nologin
qemu              /sbin/nologin
radvd             /sbin/nologin
rpc               /sbin/nologin
statd             /sbin/nologin
svn               /sbin/nologin
systemd-coredump  /sbin/nologin
systemd-network   /sbin/nologin
systemd-timesync  /sbin/nologin
usbmux            /sbin/nologin
vnc               /sbin/nologin
wwwrun            /sbin/nologin
messagebus        /usr/bin/false
scard             /usr/sbin/nologin

1.1.2 Die Verzeichnisstruktur

 

Die folgende Tabelle bietet eine kurze Übersicht über die wichtigsten Verzeichnisse der höheren Ebene auf einem Linux-System. Ausführlichere Informationen über die Verzeichnisse und wichtige Unterverzeichnisse erhalten Sie in der folgenden Liste.

Tabelle 1.4: Überblick über eine Standardverzeichnisstruktur
 

Verzeichnis

Inhalt

/

root-Verzeichnis – Startpunkt der Verzeichnisstruktur.

/bin

Grundlegende binäre Dateien, z. B. Kommandos, die der Systemadministrator und normale Benutzer brauchen. Enthält gewöhnlich auch die Shells, z. B. Bash.

/boot

Statische Dateien des Bootloaders.

/dev

Erforderliche Dateien für den Zugriff auf Host-spezifische Geräte.

/etc

Host-spezifische Systemkonfigurationsdateien.

/home

Enthält die Home-Verzeichnisse aller Benutzer mit einem Konto im System. Das Home-Verzeichnis von root befindet sich jedoch nicht unter /home, sondern unter /root.

/lib

Grundlegende freigegebene Bibliotheken und Kernel-Module.

/media

Einhängepunkte für Wechselmedien.

/mnt

Einhängepunkt für das temporäre Einhängen eines Dateisystems.

/opt

Add-On-Anwendungssoftwarepakete.

/root

Home-Verzeichnis für den Superuser root.

/sbin

Grundlegende Systembinärdateien.

/srv

Daten für Dienste, die das System bereitstellt.

/tmp

Temporäre Dateien.

/usr

Sekundäre Hierarchie mit Nur-Lese-Daten.

/var

Variable Daten wie Protokolldateien.

/windows

Nur verfügbar, wenn sowohl Microsoft Windows* als auch Linux auf Ihrem System installiert ist. Enthält die Windows-Daten.

Die folgende Liste bietet detailliertere Informationen und einige Beispiele für die Dateien und Unterverzeichnisse, die in den Verzeichnissen verfügbar sind:

/bin

Enthält die grundlegenden Shell-Befehle, die root und andere Benutzer verwenden können. Zu diesen Kommandos gehören ls, mkdir, cp, mv, rm und rmdir. /bin umfasst außerdem Bash, die Standard-Shell in SUSE Linux Enterprise Server.

/boot

Enthält Daten, die zum Booten erforderlich sind, wie zum Beispiel den Bootloader, den Kernel und andere Daten, die verwendet werden, bevor der Kernel mit der Ausführung von Programmen im Benutzermodus beginnt.

/dev

Enthält Gerätedateien, die Hardware-Komponenten darstellen.

/etc

Enthält lokale Konfigurationsdateien, die den Betrieb von Programmen wie das X Window System steuern können. Das Unterverzeichnis /etc/init.d enthält LSB-init-Skripte, die während des Bootvorgangs ausgeführt werden können.

/home/BENUTZERNAME

Enthält die privaten Daten aller Benutzer, die ein Konto auf dem System haben. Die Dateien, die hier gespeichert sind, können nur durch den Besitzer oder den Systemadministrator geändert werden. Standardmäßig befinden sich hier Ihr Email-Verzeichnis und Ihre persönliche Desktopkonfiguration in Form von verborgenen Dateien und Verzeichnissen, z. B. .gconf/ und .config.

Anmerkung
Anmerkung: Home-Verzeichnis in einer Netzwerkumgebung

Wenn Sie in einer Netzwerkumgebung arbeiten, kann Ihr Home-Verzeichnis einem von /home abweichenden Verzeichnis zugeordnet sein.

/lib

Enthält die grundlegenden freigegebenen Bibliotheken, die zum Booten des Systems und zur Ausführung der Kommandos im root-Dateisystem erforderlich sind. Freigegebene Bibliotheken entsprechen in Windows DLL-Dateien.

/media

Enthält Einhängepunkte für Wechselmedien, z. B. CD-ROMs, Flash-Laufwerke und Digitalkameras (sofern sie USB verwenden). Unter /media sind beliebige Laufwerktypen gespeichert, mit Ausnahme der Festplatte Ihres Systems. Wenn Ihr Wechselmedium eingelegt bzw. mit dem System verbunden und eingehängt wurde, können Sie von hier darauf zugreifen.

/mnt

Dieses Verzeichnis bietet einen Einhängepunkt für ein vorübergehend eingehängtes Dateisystem. root kann hier Dateisysteme einhängen.

/opt

Reserviert für die Installation von Drittanbieter-Software. Hier finden Sie optionale Softwareprogramme und größere Add-On-Programmpakete.

/root

Home-Verzeichnis für den Benutzer root. Hier befinden sich die persönlichen Daten von root.

/run

Ein tmpfs-Verzeichnis, das von systemd und verschiedenen Komponenten genutzt wird. /var/run stellt einen symbolischen Link zu /run dar.

/sbin

Wie durch das s angegeben, enthält dieses Verzeichnis Dienstprogramme für den Superuser. /sbin enthält die Binärdateien, die zusätzlich zu den Binärdateien in /bin zum Booten und Wiederherstellen des Systems unbedingt erforderlich sind.

/srv

Enhält Daten für Dienste, die das System bereitstellt, z. B. FTP und HTTP.

/tmp

Dieses Verzeichnis wird von Programmen benutzt, die eine temporäre Speicherung von Dateien verlangen.

Wichtig
Wichtig: Bereinigen des temporären Verzeichnisses /tmp bei Systemstart

Im Verzeichnis /tmp gespeicherte Daten werden nicht zwingend bei einem Neustart des Systems beibehalten. Dies ist beispielsweise von den Einstellungen in /etc/tmpfiles.d/tmp.conf abhängig.

/usr

/usr hat nichts mit Benutzern („user“) zu tun, sondern ist das Akronym für UNIX-Systemressourcen. Die Daten in /usr sind statische, schreibgeschützte Daten, die auf verschiedenen Hosts freigegeben sein können, die den Filesystem Hierarchy Standard (FHS) einhalten. Dieses Verzeichnis enthält alle Anwendungsprogramme (auch die grafischen Desktops wie GNOME) und bildet eine zweite Hierarchie im Dateisystem. /usr enthält mehrere Unterverzeichnisse, z. B. /usr/bin, /usr/sbin, /usr/local und /usr/share/doc.

/usr/bin

Enthält Programme, die für den allgemeinen Zugriff verfügbar sind.

/usr/sbin

Enthält Programme, die für den Systemadministrator reserviert sind, z. B. Reparaturfunktionen.

/usr/local

In diesem Verzeichnis kann der Systemadministrator lokale, verteilungsunabhängige Erweiterungen installieren.

/usr/share/doc

Enthält verschiedene Dokumentationsdateien und die Versionshinweise für Ihr System. Im Unterverzeichnis Handbuch befindet sich eine Online-Version dieses Handbuchs. Wenn mehrere Sprachen installiert sind, kann dieses Verzeichnis die Handbücher für verschiedene Sprachen enthalten.

Im Verzeichnis packages finden Sie die Dokumentation zu den auf Ihrem System installierten Software-Paketen. Für jedes Paket wird ein Unterverzeichnis /usr/share/doc/packages/PAKETNAME angelegt, das häufig README-Dateien für das Paket und manchmal Beispiele, Konfigurationsdateien oder zusätzliche Skripten umfasst.

Wenn HOWTOs (Verfahrensbeschreibungen) auf Ihrem System installiert sind, enhält /usr/share/doc auch das Unterverzeichnis howto mit zusätzlicher Dokumentation zu vielen Aufgaben im Zusammenhang mit der Einrichtung und Ausführung von Linux-Software.

/var

Während /usr statische, schreibgeschützte Daten enthält, ist /var für Daten, die während des Systembetriebs geschrieben werden und daher variabel sind, z. B. Protokolldateien oder Spooling-Daten. Eine Übersicht über die wichtigsten Protokolldateien finden Sie unter /var/log/. Weitere Informationen stehen unter Tabelle 40.1, „Protokolldateien“ zur Verfügung.

1.2 Schreiben von Shell-Skripten

 

Shell-Skripte bieten eine bequeme Möglichkeit, die verschiedensten Aufgaben zu erledigen: Erfassen von Daten, Suche nach einem Wort oder Begriff in einem Text und andere nützliche Dinge. Das folgende Beispiel zeigt ein kleines Shell-Skript, das einen Text druckt:

Beispiel 1.1: Ein Shell-Skript, das einen Text druckt
 
#!/bin/sh 1
# Output the following line: 2
echo "Hello World" 3

1

Die erste Zeile beginnt mit den Shebang-Zeichen (#!), die angeben, dass diese Datei ein Skript ist. Der Interpreter, der nach dem Shebang angegeben wird, führt das Skript aus. In diesem Fall ist /bin/sh der angegebene Interpreter.

2

Die zweite Zeile ist ein Kommentar, der mit dem Hash-Zeichen beginnt. Wir empfehlen Ihnen, schwierige Zeilen zu kommentieren. Richtiges Kommentieren erinnert Sie an den Zweck und die Funktion der Zeile. Ihr Skript wird zudem hoffentlich auch von anderen Lesern verstanden. Das Kommentieren wird in der Entwickler-Community als gute Vorgehensweise angesehen.

3

Die dritte Zeile verwendet das integrierte Kommando echo, um den entsprechenden Text zu drucken.

Vor Ausführung dieses Skripts sind einige Voraussetzungen zu erfüllen:

  1. Jedes Skript muss eine Shebang-Zeile enthalten (wie im obigen Beispiel). Falls die Zeile fehlt, müssen Sie den Interpreter manuell aufrufen.

  2. Sie können das Skript an beliebiger Stelle speichern. Jedoch empfiehlt es sich, es in einem Verzeichnis zu speichern, in dem die Shell es finden kann. Der Suchpfad in einer Shell wird durch die Umgebungsvariable PATH bestimmt. In der Regel verfügt ein normaler Benutzer über keinen Schreibzugriff auf /usr/bin. Daher sollten Sie Ihre Skripten im Benutzerverzeichnis ~/bin/ speichern. Das obige Beispiel erhält den Namen hello.sh.

  3. Das Skript muss zum Ausführen von Dateien berechtigt sein. Stellen Sie die Berechtigungen mit dem folgenden Kommando ein: 

    tux > chmod +x ~/bin/hello.sh

Wenn Sie alle oben genannten Voraussetzungen erfüllt haben, können Sie das Skript mithilfe der folgenden Methoden ausführen:

  1. Als absoluten Pfad.  Das Skript kann mit einem absoluten Pfad ausgeführt werden. In unserem Fall lautet er ~/bin/hello.sh.

  2. Überall.  Wenn die Umgebungsvariable PATH das Verzeichnis enthält, in dem sich das Skript befindet, können Sie das Skript mit hello.sh ausführen.

1.3 Umlenken von Kommandoereignissen

 

Jedes Kommando kann drei Kanäle für Eingabe oder Ausgabe verwenden:

  • Standardausgabe.  Dies ist der Standardausgabe-Kanal. Immer wenn ein Kommando eine Ausgabe erzeugt, verwendet es den Standardausgabe-Kanal.

  • Standardeingabe.  Wenn ein Kommando Eingaben von Benutzern oder anderen Kommandos benötigt, verwendet es diesen Kanal.

  • Standardfehler.  Kommandos verwenden diesen Kanal zum Melden von Fehlern.

Zum Umlenken dieser Kanäle bestehen folgende Möglichkeiten:

Kommando > Datei

Speichert die Ausgabe des Kommandos in eine Datei; eine etwaige bestehende Datei wird gelöscht. Beispielsweise schreibt das Kommando ls seine Ausgabe in die Datei listing.txt: 

tux > ls > listing.txt
Kommando >> Datei

Hängt die Ausgabe des Kommandos an eine Datei an. Beispielsweise hängt das Kommando ls seine Ausgabe an die Datei listing.txt an: 

tux > ls >> listing.txt
Kommando < Datei

Liest die Datei als Eingabe für das angegebene Kommando. Beispielsweise liest das Kommando read den Inhalt der Datei in die Variable ein: 

tux > read a < foo
Kommando1 | Kommando2

Leitet die Ausgabe des linken Kommandos als Eingabe für das rechte Kommando um. Beispiel: Das Kommando cat gibt den Inhalt der Datei /proc/cpuinfo aus. Diese Ausgabe wird von grep verwendet, um nur diejenigen Zeilen herauszufiltern, die cpu enthalten: 

tux > cat /proc/cpuinfo | grep cpu

Jeder Kanal verfügt über einen Dateideskriptor: 0 (Null) für Standardeingabe, 1 für Standardausgabe und 2 für Standardfehler. Es ist zulässig, diesen Dateideskriptor vor einem <- oder >-Zeichen einzufügen. Beispielsweise sucht die folgende Zeile nach einer Datei, die mit foo beginnt, aber seine Fehlermeldungen durch Umlenkung zu /dev/null unterdrückt: 

tux > find / -name "foo*" 2>/dev/null

1.4 Verwenden von Aliassen

 

Ein Alias ist ein Definitionskürzel für einen oder mehrere Kommandos. Die Syntax für einen Alias lautet: 

alias NAME=DEFINITION

Beispielsweise definiert die folgende Zeile den Alias lt, der eine lange Liste ausgibt (Option -l), sie nach Änderungszeit sortiert (-t) und sie in umgekehrter Reihenfolge sortiert ausgibt (-r): 

tux > alias lt='ls -ltr'

Zur Anzeige aller Aliasdefinitionen verwenden Sie alias. Entfernen Sie den Alias mit unalias und dem entsprechenden Aliasnamen.

1.5 Verwenden von Variablen in der Bash-Shell

 

Eine Shell-Variable kann global oder lokal sein. Auf globale Variablen, z. B. Umgebungsvariablen, kann in allen Shells zugegriffen werden. Lokale Variablen sind hingegen nur in der aktuellen Shell sichtbar.

Verwenden Sie zur Anzeige von allen Umgebungsvariablen das Kommando printenv. Wenn Sie den Wert einer Variable kennen müssen, fügen Sie den Namen Ihrer Variablen als ein Argument ein: 

tux > printenv PATH

Eine Variable (global oder lokal) kann auch mit echo angezeigt werden: 

tux > echo $PATH

Verwenden Sie zum Festlegen einer lokalen Variablen einen Variablennamen, gefolgt vom Gleichheitszeichen und dem Wert für den Namen: 

tux > PROJECT="SLED"

Geben Sie keine Leerzeichen um das Gleichheitszeichen ein, sonst erhalten Sie einen Fehler. Verwenden Sie zum Setzen einer Umgebungsvariablen export: 

tux > export NAME="tux"

Zum Entfernen einer Variable verwenden Sie unset: 

tux > unset NAME

Die folgende Tabelle enthält einige häufige Umgebungsvariablen, die Sie in Ihren Shell-Skripten verwenden können:

Tabelle 1.5: Nützliche Umgebungsvariablen
 

HOME

Home-Verzeichnis des aktuellen Benutzers

HOST

Aktueller Hostname

LANG

Wenn ein Werkzeug lokalisiert wird, verwendet es die Sprache aus dieser Umgebungsvariablen. Englisch kann auch auf C gesetzt werden

PFAD

Suchpfad der Shell, eine Liste von Verzeichnissen, die durch Doppelpunkte getrennt sind

PS1

Gibt die normale Eingabeaufforderung an, die vor jedem Kommando angezeigt wird

PS2

Gibt die sekundäre Eingabeaufforderung an, die beim Ausführen eines mehrzeiligen Kommandos angezeigt wird

PWD

Aktuelles Arbeitsverzeichnis

USER

Aktueller Benutzer

1.5.1 Verwenden von Argumentvariablen

 

Wenn Sie beispielsweise über das Skript foo.sh verfügen, können Sie es wie folgt ausführen: 

tux > foo.sh "Tux Penguin" 2000

Für den Zugriff auf alle Argumente, die an Ihr Skript übergeben werden, benötigen Sie Positionsparameter. Diese sind $1 für das erste Argument, $2 für das zweite usw. Sie können bis zu neun Parameter verwenden. Verwenden Sie $0 zum Abrufen des Skriptnamens.

Das folgende Skript foo.sh gibt alle Argumente von 1 bis 4 aus: 

#!/bin/sh
echo \"$1\" \"$2\" \"$3\" \"$4\"

Wenn Sie das Skript mit den obigen Argumenten ausführen, erhalten Sie Folgendes: 

"Tux Penguin" "2000" "" ""

1.5.2 Verwenden der Variablenersetzung

 

Variablenersetzungen wenden beginnend von links oder rechts ein Schema auf den Inhalt einer Variable an. Die folgende Liste enthält die möglichen Syntaxformen:

${VAR#schema}

entfernt die kürzeste mögliche Übereinstimmung von links: 

tux > file=/home/tux/book/book.tar.bz2
tux > echo ${file#*/}
home/tux/book/book.tar.bz2
${VAR##schema}

entfernt die längste mögliche Übereinstimmung von links: 

tux > file=/home/tux/book/book.tar.bz2
tux > echo ${file##*/}
book.tar.bz2
${VAR%schema}

entfernt die kürzeste mögliche Übereinstimmung von rechts: 

tux > file=/home/tux/book/book.tar.bz2
tux > echo ${file%.*}
/home/tux/book/book.tar
${VAR%%schema}

entfernt die längste mögliche Übereinstimmung von rechts: 

tux > file=/home/tux/book/book.tar.bz2
tux > echo ${file%%.*}
/home/tux/book/book
${VAR/pattern_1/pattern_2}

ersetzt den Inhalt von VAR von PATTERN_1 durch PATTERN_2: 

tux > file=/home/tux/book/book.tar.bz2
tux > echo ${file/tux/wilber}
/home/wilber/book/book.tar.bz2

1.6 Gruppieren und Kombinieren von Kommandos

 

In Shells können Sie Kommandos für die bedingte Ausführung verketten und gruppieren. Jedes Kommando übergibt einen Endcode, der den Erfolg oder Misserfolg seiner Ausführung bestimmt. Wenn er 0 (Null) lautet, war das Kommando erfolgreich, alle anderen Codes bezeichnen einen Fehler, der spezifisch für das Kommando ist.

Die folgende Liste zeigt, wie sich Kommandos gruppieren lassen:

Kommando1 ; Kommando2

führt die Kommandos in sequenzieller Reihenfolge aus. Der Endcode wird nicht geprüft. Die folgende Zeile zeigt den Inhalt der Datei mit cat an und gibt deren Dateieigenschaften unabhängig von deren Endcodes mit ls aus: 

tux > cat filelist.txt ; ls -l filelist.txt
Kommando1 && Kommando2

führt das rechte Kommando aus, wenn das linke Kommando erfolgreich war (logisches UND). Die folgende Zeile zeigt den Inahlt der Datei an und gibt deren Dateieigenschaften nur aus, wenn das vorherige Kommando erfolgreich war (vgl. mit dem vorherigen Eintrag in dieser Liste): 

tux > cat filelist.txt && ls -l filelist.txt
Kommando1 || Kommando2

führt das rechte Kommando aus, wenn das linke Kommando fehlgeschlagen ist (logisches ODER). Die folgende Zeile legt nur ein Verzeichnis in /home/wilber/bar an, wenn die Erstellung des Verzeichnisses in /home/tux/foo fehlgeschlagen ist: 

tux > mkdir /home/tux/foo || mkdir /home/wilber/bar
funcname(){ ... }

erstellt eine Shell-Funktion. Sie können mithilfe der Positionsparameter auf ihre Argumente zugreifen. Die folgende Zeile definiert die Funktion hello für die Ausgabe einer kurzen Meldung: 

tux > hello() { echo "Hello $1"; }

Sie können diese Funktion wie folgt aufrufen: 

tux > hello Tux

Die Ausgabe sieht wie folgt aus: 

Hello Tux

1.7 Arbeiten mit häufigen Ablaufkonstrukten

 

Zur Steuerung des Ablaufs Ihres Skripts verfügt eine Shell über while-, if-, for- und case-Konstrukte.

1.7.1 Das Steuerungskommando „if“

 

Das Kommando if wird verwendet, um Ausdrücke zu prüfen. Beispielsweise testet der folgende Code, ob es sich beim aktuellen Benutzer um Tux handelt: 

if test $USER = "tux"; then
  echo "Hello Tux."
else
  echo "You are not Tux."
fi

Der Testausdruck kann so komplex oder einfach wie möglich sein. Der folgende Ausdruck prüft, ob die Datei foo.txt existiert: 

if test -e /tmp/foo.txt ; then
  echo "Found foo.txt"
fi

Der Testausdruck kann auch in eckigen Klammern abgekürzt werden: 

if [ -e /tmp/foo.txt ] ; then
  echo "Found foo.txt"
fi

Weitere nützliche Ausdrücke finden Sie unter https://bash.cyberciti.biz/guide/If..else..fi.

1.7.2 Erstellen von Schleifen mit dem Kommando for

 

Mithilfe der for-Schleife können Sie Kommandos an einer Liste von Einträgen ausführen. Beispielsweise gibt der folgende Code einige Informationen über PNG-Dateien im aktuellen Verzeichnis aus: 

for i in *.png; do
 ls -l $i
done

1.8 Weitere Informationen

 

Wichtige Informationen über die Bash-Shell finden Sie auf den man-Seiten zu man bash. Für weitere Informationen zu diesem Thema siehe die folgende Liste:

2 Grundlegende Infos zu sudo

 

Für bestimmte Kommandos sind root-Berechtigungen erforderlich. Die Anmeldung als root ist aus Sicherheitsgründen und zur Vermeidung von Fehlern jedoch nicht zu empfehlen. Es ist sicherer, sich als normaler Benutzer anzumelden und dann mit sudo Kommandos mit höheren Rechten auszuführen.

Auf SUSE Linux Enterprise Server ist sudo standardmäßig auf eine ähnliche Funktionsweise wie su konfiguriert. sudo ist jedoch eine flexible Methode, mit der Benutzer Kommandos mit den Rechten eines beliebigen anderen Benutzers ausführen können. Dies kann dazu genutzt werden, Rollen mit bestimmten Berechtigungen bestimmten Benutzern und Gruppen zuzuweisen. Es ist beispielsweise möglich, Mitgliedern der Gruppe Benutzer das Ausführen eines Kommandos mit den Berechtigungen des Benutzers wilber zu erlauben. Der Zugriff auf das Kommando wird weiter eingeschränkt, wenn Kommandooptionen nicht zugelassen werden. Während „su“ immer das root-Passwort für die Authentifizierung mit PAM erfordert, kann sudo für die Authentifizierung mit Ihren eigenen Berechtigungsnachweisen konfiguriert werden. Benutzer müssen folglich ihr root-Passwort nicht bekanntgeben, was die Sicherheit erhöht.

2.1 Grundlegende Verwendung von sudo

 

Im folgenden Kapitel wird die grundlegende Verwendung von sudo vorgestellt.

2.1.1 Ausführung eines einzelnen Kommandos

 

Als normaler Benutzer können Sie alle Kommandos als root ausführen, indem Sie sudo vor das Kommando setzen. Dadurch werden Sie aufgefordert, das root-Passwort anzugeben. Bei erfolgreicher Authentifizierung wird daraufhin das Kommando als root ausgeführt: 

tux > id -un1
tux
tux > sudo id -un
root's password:2
root
tux > id -un
tux3
tux > sudo id -un
4
root

1

Das Kommando id -un druckt den Anmeldenamen des aktuellen Benutzers.

2

Das Passwort wird bei der Eingabe weder als Klartext noch durch maskierende Zeichen angezeigt.

3

Nur Kommandos, die mit sudo beginnen, werden mit höheren Rechten ausgeführt.

4

Die erhöhten Rechte bleiben für bestimmte Zeit erhalten, sodass Sie das root-Passwort nicht erneut eingeben müssen. erneut angeben müssen.

Tipp
Tipp: E/A-Umleitung

Die E/A-Umleitung funktioniert nicht mit sudo: 

tux > sudo echo s > /proc/sysrq-trigger
bash: /proc/sysrq-trigger: Permission denied
tux > sudo cat < /proc/1/maps
bash: /proc/1/maps: Permission denied

Im oben genannten Beispiel werden nur die Kommandos echo und cat mit erhöhten Rechten ausgeführt. Die Umleitung wird von der Shell des Benutzers mit Benutzerrechten ausgeführt. Für eine Umleitung mit erhöhten Rechten müssen Sie eine Shell starten wie in Abschnitt 2.1.2, „Starten einer Shell“ beschrieben oder das dd-Dienstprogramm verwenden: 

echo s | sudo dd of=/proc/sysrq-trigger
sudo dd if=/proc/1/maps | cat

2.1.2 Starten einer Shell

 

Es ist nicht immer praktisch, sudo jedes mal zur Ausführung eines Kommandos mit erhöhten Rechten zu verwenden. Sie können zwar das Kommando sudo bash verwenden, doch zum Starten einer Shell empfiehlt sich die Verwendung einer der integrierten Methoden:

sudo -s (<Kommando>)

Startet eine von der UmgebungsvariablenSHELL angegebene Shell oder die Standard-Shell des Zielbenutzers. Falls ein Kommando angegeben ist, wird es (mit der Option -c) an die Shell übergeben. Andernfalls wird die Shell im interaktiven Modus ausgeführt. 

tux:~ > sudo -s
root's password:
root:/home/tux # exit
tux:~ >
sudo -i (<Kommando>)

Ähnlich wie -s, doch die Shell wird als Anmeldungs-Shell gestartet. Dies bedeutet, dass die Startdateien der Shell (.profile usw.) verarbeitet werden und das aktuelle Arbeitsverzeichnis als Basisverzeichnis des Zielbenutzers festgelegt wird. 

tux:~ > sudo -i
root's password:
root:~ # exit
tux:~ >
Tipp
Tipp: Umgebungsvariablen

Standardmäßig gibt sudo keine Umgebungsvariablen weiter. Dieses Verhalten kann mit der Option env_reset geändert werden (weitere Informationen finden Sie unter Hilfreiche Flags und Optionen).

2.2 Konfigurieren von sudo

 

sudo umfasst eine breite Palette an konfigurierbaren Optionen.

Anmerkung
Anmerkung: Versehentliches Aussperren aus sudo

Wenn Sie sich versehentlich aus sudo ausgesperrt haben, starten Sie mit su - und dem root-Passwort eine root-Shell. Beheben Sie den Fehler mit visudo.

2.2.1 Bearbeiten der Konfigurationsdateien

 

Die Hauptkonfigurationsdatei mit den Richtlinien für sudo ist /etc/sudoers. Da es möglich ist, sich selbst aus dem System auszusperren, wenn die Datei nicht gut erstellt ist, wird dringend empfohlen, visudo zum Bearbeiten zu verwenden. Es verhindert Bearbeitungskonflikte und prüft auf Syntaxfehler, bevor die Änderungen gespeichert werden.

Sie können statt visudo auch einen anderen Editor verwenden. Legen Sie dazu die Umgebungsvariable EDITOR fest, wie zum Beispiel: 

sudo EDITOR=/usr/bin/nano visudo

Denken Sie daran, dass die Datei /etc/sudoers von den Systempaketen bereitgestellt wird und direkt in der Datei vorgenommene Änderungen möglicherweise Aktualisierungen beschädigen. Daher wird empfohlen, benutzerdefinierte Konfigurationen in Dateien im Verzeichnis /etc/sudoers.d/ abzulegen. Erstellen oder bearbeiten Sie eine Datei mit folgendem Kommando: 

sudo visudo -f /etc/sudoers.d/NAME

Mit folgendem Kommando wird die Datei geöffnet und ein anderer Editor verwendet (in diesem Fall nano): 

sudo EDITOR=/usr/bin/nano visudo -f /etc/sudoers.d/NAME
Anmerkung
Anmerkung: Ignorierte Dateien in /etc/sudoers.d

Die Anweisung #includedir in /etc/sudoers ignoriert Dateien, die auf das Zeichen ~ (Tilde) enden oder das Zeichen . (Punkt) enthalten.

Führen Sie man 8 visudo aus, um weitere Informationen zum Kommando visudo zu erhalten.

2.2.2 Basiskonfigurationssyntax von sudoers

 

Die sudoers-Konfigurationsdateien enthalten zwei Optionstypen: Zeichenketten und Flags. Zeichenketten können beliebige Werte enthalten, Flags hingegen können nur aktiviert (ON) oder deaktiviert (OFF) werden. Die wichtigsten Syntaxkonstrukte für sudoers-Konfigurationsdateien sind: 

# Everything on a line after # is ignored 1
Defaults !insults # Disable the insults flag 2
Defaults env_keep += "DISPLAY HOME" # Add DISPLAY and HOME to env_keep
tux ALL = NOPASSWD: /usr/bin/frobnicate, PASSWD: /usr/bin/journalctl 3

1

Es gibt zwei Ausnahmen: #include und #includedir sind normale Kommandos.

2

Entfernen Sie das Ausrufezeichen (!, um das gewünschte Flag zu aktivieren (ON).

3

Siehe Abschnitt 2.2.3, „Grundlegende sudoers-Regeln“.

Hilfreiche Flags und Optionen
 
targetpw

Dieses Flag steuert, ob der aufrufende Benutzer das Passwort des Zielbenutzers (ON) (beispielsweise root) oder des aufrufenden Benutzers (OFF) eingeben muss. 

Defaults targetpw # Turn targetpw flag ON
rootpw

Bei diesem Flag fordert sudo zur Eingabe des root-Passworts auf. Die Standardeinstellung ist “OFF”. 

Defaults !rootpw # Turn rootpw flag OFF
env_reset

Bei diesem Flag konstruiert sudo eine minimale Umgebung mit TERM, PATH, HOME, MAIL, SHELL, LOGNAME, USER, USERNAME und SUDO_*. Zusätzlich werden Variablen, die in env_keep aufgelistet sind, aus der aufrufenden Umgebung importiert. Standardmäßig ist ON festgelegt. 

Defaults env_reset # Turn env_reset flag ON
env_keep

Eine Liste der Umgebungsvariablen, die beizubehalten sind, wenn für das Flag env_reset ON festgelegt ist. 

# Set env_keep to contain EDITOR and PROMPT
Defaults env_keep = "EDITOR PROMPT"
Defaults env_keep += "JRE_HOME" # Add JRE_HOME
Defaults env_keep -= "JRE_HOME" # Remove JRE_HOME
env_delete

Eine Liste der Umgebungsvariablen, die zu löschen sind, wenn für das Flag env_reset OFF festgelegt ist. 

# Set env_delete to contain EDITOR and PROMPT
Defaults env_delete = "EDITOR PROMPT"
Defaults env_delete += "JRE_HOME" # Add JRE_HOME
Defaults env_delete -= "JRE_HOME" # Remove JRE_HOME

Das Token Defaults kann auch zum Erstellen von Aliassen für eine Sammlung von Benutzern, Hosts oder Kommandos verwendet werden. Außerdem ist es möglich, eine Option anzuwenden, die nur für eine bestimmte Reihe von Benutzern gültig ist.

Genauere Informationen zur Konfigurationsdatei /etc/sudoers erhalten Sie mit dem Kommando man 5 sudoers.

2.2.3 Grundlegende sudoers-Regeln

 

Jede Regel befolgt folgendes Schema ([] markiert optionale Teile): 

#Who      Where         As whom      Tag                What
User_List Host_List = [(User_List)] [NOPASSWD:|PASSWD:] Cmnd_List
sudoers-Regelsyntax
 
User_List

Eine oder mehrere (durch Komma getrennte) Kennungen: Entweder ein Benutzername, eine Gruppe im Format %GROUPNAME oder eine Benutzer-ID im Format #UID. Eine Negierung wird mit dem Präfix ! Präfix.

Host_List

Eine oder mehrere (durch Komma getrennte) Kennungen: Entweder ein (vollständig qualifizierter) Hostname oder eine IP-Adresse. Eine Negierung wird mit dem Präfix ! Präfix. ALL ist eine häufige Wahl für Host_List.

NOPASSWD:|PASSWD:

Der Benutzer wird nicht aufgefordert, ein Passwort einzugeben, wenn Kommandos ausgeführt werden, die Cmd_List nach NOPASSWD: entsprechen.

PASSWD ist der Standard. Es muss nur angegeben werden, wenn sich sowohl PASSWD als auch NOPASSWD auf derselben Zeile befinden: 

tux ALL = PASSWD: /usr/bin/foo, NOPASSWD: /usr/bin/bar
Cmnd_List

Einer oder mehrere (durch Komma getrennte) Bezeichner: Ein Pfad zu einer ausführbaren Datei, gefolgt von einem optionalen zulässigen Argument. 

/usr/bin/foo     # Anything allowed
/usr/bin/foo bar # Only "/usr/bin/foo bar" allowed
/usr/bin/foo ""  # No arguments allowed

ALL kann als User_List, Host_List und Cmnd_List verwendet werden.

Eine Regel, die es tux erlaubt, alle Kommandos als „root“ ohne Eingabe des Passworts auszuführen: 

tux ALL = NOPASSWD: ALL

Eine Regel, die es tux erlaubt, systemctl restart apache2 auszuführen: 

tux ALL = /usr/bin/systemctl restart apache2

Eine Regel, die es tux erlaubt, wall als admin ohne Argumente auszuführen: 

tux ALL = (admin) /usr/bin/wall ""
Warnung
Warnung: Unsichere Regeln

Verwenden Sie keine Regeln wie ALL ALL = ALL ohne Defaults targetpw. Andernfalls kann jeder Benutzer Kommandos als root ausführen.

2.3 sudo-Anwendungsfälle

 

Die Standardkonfiguration funktioniert bei standardmäßigen Verwendungsszenarien, lässt sich jedoch für spezifische Bedürfnisse anpassen.

2.3.1 Verwenden von sudo ohne root-Passwort

 

Grundsätzlich können Mitglieder der Gruppe wheel alle Kommandos mit sudo als „root“ ausführen. In der folgenden Vorgehensweise wird erklärt, wie ein Benutzerkonto zur Gruppe wheel hinzugefügt wird.

  1. Fügen Sie Ihr Benutzerkonto zur Gruppe wheel hinzu.

    Falls Ihr Benutzerkonto nicht bereits Mitglied der Gruppe wheel ist, fügen Sie es mit dem Kommando sudo usermod -a -G wheel USERNAME hinzu. Melden Sie sich ab und wieder an, um die Änderung zu aktivieren. Überprüfen Sie, ob die Änderung erfolgreich war, indem Sie das Kommando groups BENUTZERNAME ausführen.

  2. Authentifizieren Sie sich mit dem normalen Passwort des Benutzerkontos.

    Erstellen Sie die Datei /etc/sudoers.d/userpw mit dem Kommando visudo (siehe Abschnitt 2.2.1, „Bearbeiten der Konfigurationsdateien“) und fügen Sie Folgendes hinzu: 

    Defaults !targetpw

  3. Wählen Sie eine neue Standardregel aus.

    Falls Sie möchten, dass Benutzer ihre Passwörter erneut eingeben oder nicht, entfernen Sie das Kommentarzeichen in der entsprechenden Zeile in /etc/sudoers und kommentieren Sie die Standardregel aus. 

    ## Uncomment to allow members of group wheel to execute any command
# %wheel ALL=(ALL) ALL

## Same thing without a password
# %wheel ALL=(ALL) NOPASSWD: ALL

  4. Gestalten Sie die Standardregel restriktiver.

    Kommentieren Sie die Regel, die alles erlaubt, in /etc/sudoers aus oder löschen Sie sie: 

    ALL     ALL=(ALL) ALL   # WARNING! Only use this together with 'Defaults targetpw'!
    Warnung
    Warnung: Gefährliche Regel in sudoers

    Überspringen Sie diesen Schritt nicht. Andernfalls kann jeder beliebige Benutzer jedes beliebige Kommando als root ausführen.

  5. Testen Sie die Konfiguration.

    Führen Sie sudo als Mitglied und Nicht-Mitglied von wheel aus. 

    tux:~ > groups
users wheel
tux:~ > sudo id -un
tux's password:
root
wilber:~ > groups
users
wilber:~ > sudo id -un
wilber is not in the sudoers file.  This incident will be reported.

2.3.2 Verwenden von sudo mit X.Org-Anwendungen

 

Werden grafische Anwendungen mit sudo gestartet, führt dies normalerweise zu folgendem Fehler: 

tux > sudo xterm
xterm: Xt error: Can't open display: %s
xterm: DISPLAY is not set

Eine einfache Behelfslösung ist xhost. Damit wird dem root-Benutzer vorübergehend der Zugriff auf die X-Sitzung des lokalen Benutzers gestattet. Dies erfolgt mit folgendem Kommando: 

xhost si:localuser:root

Folgendes Kommando entfernt den gewährten Zugriff: 

xhost -si:localuser:root
Warnung
Warnung: Potenzielles Sicherheitsproblem

Die Ausführung grafischer Anwendungen mit root-Rechten beeinträchtigt die Sicherheit. Es wird empfohlen, den root-Zugriff für eine grafische Anwendung nur in Ausnahmefällen zu aktivieren. Außerdem sollte der gewährte root-Zugriff sofort nach Schließen der grafischen Anwendung entzogen werden.

2.4 Weitere Informationen

 

Das Kommando sudo --help gibt einen kurzen Überblick über die verfügbaren Kommandozeilenoptionen und das Kommando man sudoers detaillierte Informationen über sudoers und dessen Konfiguration.

3 YaST

 

YaST ist ein SUSE Linux Enterprise Server-Tool mit einer grafischen Oberfläche für alle wesentlichen Installations- und Systemkonfigurationsaufgaben. Ob Sie Pakete aktualisieren, einen Drucker konfigurieren, Firewall-Einstellungen bearbeiten, einen FTP-Server einrichten oder eine Festplatte partitionieren müssen – mit YaST ist dies alles möglich. YaST ist in Ruby geschrieben und weist eine erweiterbare Architektur auf, die es ermöglicht, neue Funktionen über Module hinzuzufügen.

Weitere Informationen zu YaST sind auf der offiziellen Website des Projekts verfügbar unter https://yast.opensuse.org/.

3.1 YaST-Themen

 

Detaillierte Informationen zur Verwendung spezifischer YaST-Module und Funktionen finden Sie in der gesamten Dokumentation.

 
Verwaltungshandbuch
Implementierungsleitfaden

  • Kapitel 25: „Ändern der Sprach- und Ländereinstellungen mit YaST“

  • Abschnitt 20.3: „Einrichten eines Druckers“

  • Abschnitt 20.2: „Einrichten von Soundkarten“

  • Kapitel 22: „Installieren von Modulen, Erweiterungen und Add-on-Produkten von Drittanbietern“

  • Abschnitt 21.4: „Verwalten von Software-Repositorys und -Diensten“

  • Kapitel 21: „Installieren bzw. Entfernen von Software“

  • Kapitel 24: „Verwalten von Benutzern mit YaST“

  • Kapitel 20: „Einrichten von Hardwarekomponenten mit YaST“

  • Abschnitt 20.1: „Einrichten der Systemtastaturbelegung“

Sicherheitshandbuch

  • Chapter 36: “Building and managing profiles with YaST”

  • Section 24.4: “Setting up a VPN server or client using YaST”

  • Chapter 17: “Configuring security settings with YaST”

3.2 YaST-Oberfläche im Überblick

 

YaST verfügt über zwei grafische Oberflächen. Die eine wird für grafische Desktop-Umgebungen wie KDE und GNOME verwendet. Die andere ist eine ncurses-basierte pseudo-grafische Oberfläche für Systeme ohne X-Server (weitere Informationen hierzu finden Sie in Kapitel 4, YaST im Textmodus).

In der grafischen Version von YaST sind alle Module in YaST nach Kategorie gruppiert. Über die Navigationsleiste erhalten Sie schnell Zugriff auf die Module in der gewünschten Kategorie. Im Suchfeld am oberen Rand lassen sich Module nach Namen suchen. Geben Sie zur Suche nach einem bestimmten Modul dessen Namen im Suchfeld ein. Danach sollten Sie beim Tippen die Module sehen, die der eingegebenen Zeichenfolge entsprechen.

3.3 Nützliche Tastenkombinationen

 

Die grafische Version von YaST unterstützt Tastenkombinationen.

Bildschirminhalt drucken

Erstellt und speichert ein Bildschirmfoto. In bestimmten Desktop-Umgebungen funktioniert diese Kombination womöglich nicht.

Umschalttaste–F4

Aktiviert und deaktiviert die Farbpalette für Benutzer mit Sehbehinderungen.

Umschalttaste–F7

Aktiviert/Deaktiviert die Protokollierung von Fehlermeldungen (Debugging).

Umschalttaste–F8

Öffnet einen Dateidialog, über den Sie die Protokolldateien in einem benutzerdefinierten Speicherort speichern können.

Strg–Umschalttaste–Alt–D

Sendet ein Fehlerereignis (Debugging). YaST-Module können darauf mit der Ausführung spezieller Debugging-Aktionen reagieren. Das Ergebnis ist abhängig vom jeweiligen YaST-Modul.

Strg–Umschalttaste–Alt–M

Startet und stoppt den Makro-Rekorder.

Strg–Umschalttaste–Alt–P

Gibt ein Makro wieder.

Strg–Umschalttaste–Alt–S

Öffnet den Layoutdatei-Editor.

Strg–Umschalttaste–Alt–T

Speichert den Miniprogramm-Baum in der Protokolldatei.

Strg–Umschalttaste–Alt–X

Öffnet ein Konsolenfenster (xterm). Nützlich für VNC-Installationen.

Strg–Umschalttaste–Alt–Y

Öffnet den Miniprogramm-Baum-Browser.

4 YaST im Textmodus

 

Die ncurses-basierte pseudo-grafische YaST-Oberfläche sollte vor allem Systemadministratoren bei der Verwaltung von Systemen ohne X-Server unterstützen. Die Oberfläche bietet einige Vorteile im Vergleich zu herkömmlichen grafischen Benutzeroberflächen. Die Navigation auf der ncurses-Oberfläche erfolgt über die Tastatur. Für praktisch alle Oberflächenelemente stehen Tastenkombinationen zur Verfügung. Die ncurses-Oberfläche benötigt nur wenige Ressourcen und wird selbst auf langsamer Hardware schnell ausgeführt. Die ncurses-basierte Version von YaST lässt sich über eine SSH-Verbindung ausführen, damit Sie Remote-Systeme verwalten können. Denken Sie daran, dass die minimale unterstützte Größe des Terminal-Emulators, in dem Sie YaST ausführen, 80 x 25 Zeichen beträgt.

Hauptfenster von YaST im Textmodus
Abbildung 4.1: Hauptfenster von YaST im Textmodus
 

Öffnen Sie zum Starten der ncurses-basierten Version von YaST das Terminal und führen Sie das Kommando sudo yast2 aus. Navigieren Sie anhand der Tabulator- oder Pfeiltasten durch die Oberflächenelemente wie Menüelemente, Felder und Schaltflächen. Auf alle Menüelemente und Schaltflächen in YaST wird über die entsprechenden Funktionstasten oder Tastenkombinationen zugegriffen. Beispielsweise brechen Sie den aktuellen Vorgang durch Drücken der F9-Taste ab. Mit der F10-Taste übernehmen Sie Änderungen. Bei jedem Menüelement und jeder Schaltfläche auf der ncurses-basierten Oberfläche von YaST ist in der Bezeichnung ein Buchstabe hervorgehoben. Dieser Buchstabe ist Teil der Tastenkombination, die dem Oberflächenelement zugewiesen wurde. Beispielsweise ist der Buchstabe B auf der Schaltfläche Beenden hervorgehoben. Das bedeutet, dass Sie die Schaltfläche durch Drücken von Alt–Alt+B aktivieren können.

Tipp
Tipp: Neuladen von YaST-Dialogfeldern

Wenn ein YaST-Dialogfeld verzerrt oder unleserlich wird (z. B. beim Ändern der Fenstergröße), drücken Sie Strg–L. Damit wird das Fenster aktualisiert, und der Fensterinhalt wird wiederhergestellt.

4.1 Navigation in Modulen

 

Bei der folgenden Beschreibung der Steuerelemente in den YaST-Modulen wird davon ausgegangen, dass alle Kombinationen aus Funktionstasten und Alt-Taste funktionieren und nicht anderen globalen Funktionen zugewiesen sind. In Abschnitt 4.3, „Einschränkung der Tastenkombinationen“ finden Sie Informationen zu möglichen Ausnahmen.

Wechseln zwischen Schaltflächen und Auswahllisten

Navigieren Sie zwischen den Schaltflächen und Einzelbildern mit den Auswahllisten mit →|. Mit den Tastenkombinationen Alt–→| oder Umschalttaste–→| navigieren Sie in der umgekehrten Richtung.

Navigieren in Auswahllisten

Mit den Pfeiltasten (↑ und ↓) können Sie sich zwischen den einzelnen Elementen in einem aktiven Rahmen, der eine Auswahlliste enthält, bewegen. Wenn einzelne Einträge länger sind als die Breite des Rahmens, verwenden Sie Umschalttaste–→ oder Umschalttaste–← für den horizontalen Bildlauf. Wenn über die Pfeiltaste die Auswahl zu einem anderen Rahmen übergeht, verwenden Sie stattdessen Strg–E oder Strg–A.

Arbeiten mit Schaltflächen, Optionsschaltflächen und Kontrollkästchen

Drücken Sie Leertaste oder Eingabetaste, um Schaltflächen mit leeren eckigen Klammern (Kontrollkästchen) oder leeren runden Klammern (Optionsschaltflächen) auszuwählen. Alternativ können Optionsschaltflächen und Kontrollkästchen unmittelbar mit Alt–markierter_Buchstabe ausgewählt werden. In diesem Fall brauchen Sie die Auswahl nicht mit Eingabetaste zu bestätigen. Wenn Sie mit →| zu einem Element wechseln, können Sie mit Eingabetaste die ausgewählte Aktion ausführen bzw. das betreffende Menüelement aktivieren.

Funktionstasten

Die Funktionstasten ( F1 bis F12 ) bieten schnellen Zugriff auf die verschiedenen Schaltflächen. In der untersten Zeile im YaST-Bildschirm werden verfügbare Tastenkombinationen (Fx) angezeigt. Welche Funktionstasten welchen Schaltflächen zugeordnet sind, hängt vom aktiven YaST-Modul ab, da die verschiedenen Module unterschiedliche Schaltflächen aufweisen (Details, Info, Hinzufügen, Löschen usw.). F10 wird für Übernehmen, OK, Weiter und Beenden verwendet. Drücken Sie F1, um Zugriff auf die YaST-Hilfe zu erhalten.

Verwenden der Navigationsstruktur

Einige YaST-Module bieten im linken Fensterbereich eine Navigationsstruktur, in der Konfigurationsdialogfenster ausgewählt werden können. Verwenden Sie die Pfeiltasten (↑ und ↓), um in der Baumstruktur zu navigieren. Drücken Sie Leertaste, um Elemente der Struktur zu öffnen oder zu schließen. Im ncurses-Modus muss nach der Auswahl in der Navigationsstruktur die Taste Eingabetaste gedrückt werden, um das ausgewählte Dialogfeld anzuzeigen. Dieses beabsichtigte Verhalten erspart zeitraubende Bildaufbauvorgänge beim Blättern durch die Navigationsstruktur.

Auswählen von Software im Software-Installationsmodul

Verwenden Sie die Filter auf der linken Seite, um Pakete aufzulisten, die der angegebenen Zeichenkette entsprechen. Installierte Pakete sind mit dem Buchstaben i gekennzeichnet. Mit der Leertaste oder der Eingabetaste ändern Sie den Status eines Pakets. Alternativ wählen Sie den gewünschten neuen Modus (Installieren, Löschen, Aktualisieren, Tabu oder Sperre) über das Menü Aktionen.

Das Software-Installationsmodul
Abbildung 4.2: Das Software-Installationsmodul
 

4.2 Erweiterte Tastenkombinationen

 

Die ncurses-basierte Version von YaST bietet einige erweiterte Tastenkombinationen.

Umschalttaste–F1

Zeigt eine Liste der erweiterten Tastenfunktionen.

Umschalttaste–F4

Ändert das Farbschema.

Strg–

Beendet die Anwendung.

Strg–L

Aktualisiert den Bildschirm.

Strg–DF1

Zeigt eine Liste der erweiterten Tastenfunktionen.

Strg–DUmschalttaste– D

Speichert das Dialogfeld als Bildschirmfoto in der Protokolldatei.

Strg–DUmschalttaste–Y

Öffnet YDialogSpy mit der Widget-Hierarchie.

4.3 Einschränkung der Tastenkombinationen

 

Wenn der Fenster-Manager globale Alt-Kombinationen verwendet, funktionieren die Alt-Kombinationen in YaST möglicherweise nicht. Tasten wie Alt oder Umschalttaste können auch durch die Einstellungen des Terminals belegt sein.

Verwenden von Alt statt Esc

Tastenkombinationen mit Alt können auch mit Esc anstelle von Alt ausgeführt werden. Esc–H beispielsweise ersetzt Alt–H. (Drücken Sie Esc, und drücken Sie dann H.)

Navigation vor und zurück mit Strg– F und Strg– B

Wenn die Kombinationen mit Alt und Umschalttaste vom Fenster-Manager oder dem Terminal belegt sind, verwenden Sie stattdessen die Kombinationen Strg–F (forward=vor) und Strg–B (backward=zurück).

Einschränkung der Funktionstasten

Die Funktionstasten (F1 bis F12) werden auch für Funktionen herangezogen. Bestimmte Funktionstasten können vom Terminal übernommen werden und stehen eventuell für YaST nicht zur Verfügung. Auf einer reinen Textkonsole sollten die Tastenkombinationen mit Alt und die Funktionstasten jedoch stets vollständig zur Verfügung stehen.

4.4 YaST-Kommandozeilenoptionen

 

Neben der Schnittstelle im Textmodus bietet YaST auch eine Kommandozeilenschnittstelle. Rufen Sie eine Liste der YaST-Kommandozeilenoptionen mit folgendem Kommando ab: 

tux > sudo yast -h

4.4.1 Installieren von Paketen über die Kommandozeile

 

Wenn Sie den Namen des Pakets kennen und das Paket von einem aktiven Installations-Repository bereitgestellt wird, können Sie das Paket mithilfe der Kommandozeilenoption -i installieren: 

tux > sudo yast -i package_name

oder 

tux > sudo yast --install -i package_name

package_name kann aus einem einfachen, kurzen Namen eines Pakets bestehen (z. B. gvim), das mit Abhängigkeitsprüfung installiert wurde, oder auch den vollständigen Pfad eines RPM-Pakets enthalten, das ohne Abhängigkeitsprüfung installiert wurde.

YaST bietet grundlegende Funktionen zur Verwaltung von Software von der Kommandozeile aus. Für anspruchsvollere Paketverwaltungsaufgaben sollten Sie Zypper verwenden. Weitere Informationen zu Zypper finden Sie in Abschnitt 6.1, „Verwenden von zypper“

4.4.2 Arbeiten mit einzelnen Modulen

 

Um Zeit zu sparen, können Sie einzelne YaST-Module mit folgendem Kommando starten: 

tux > sudo yast module_name

Eine Liste aller auf Ihrem System verfügbaren Module können Sie mit yast -l oder yast --list anzeigen.

4.4.3 Kommandozeilenparameter der YaST-Module

 

Um die Verwendung von YaST-Funktionen in Skripts zu ermöglichen, bietet YaST Kommandozeilenunterstützung für einzelne Module. Die Kommandozeilenunterstützung steht jedoch nicht für alle Module zur Verfügung. Die verfügbaren Optionen eines Moduls zeigen Sie mit folgendem Kommando an: 

tux > sudo yast module_name help

Wenn ein Modul keine Kommandozeilenunterstützung bietet, wird es im Textmodus gestartet und es wird folgende Meldung angezeigt: 

This YaST module does not support the command line interface.

In den nachfolgenden Abschnitten werden alle YaST-Module mit Kommandozeilenunterstützung beschrieben, und es werden alle zugehörigen Kommandos und die verfügbaren Optionen kurz erläutert.

4.4.3.1 Häufige Kommandos in YaST-Modulen

 

Alle YaST-Module unterstützen die folgenden Kommandos:

help

Zeigt eine Liste der unterstützten Kommandos des Moduls mit einer Beschreibung an: 

tux > sudo yast lan help
longhelp

Wie help, zeigt jedoch zusätzlich eine detaillierte Liste der Optionen aller Kommandos mit einer Beschreibung an: 

tux > sudo yast lan longhelp
xmlhelp

Wie longhelp; die Ausgabe ist jedoch als XML-Dokument strukturiert und wird in eine Datei umgeleitet: 

tux > sudo yast lan xmlhelp xmlfile=/tmp/yast_lan.xml
interactive

Gibt den Modus Interaktiv ein. Damit führen Sie die Kommandos des Moduls aus, ohne das Präfix sudo yast angeben zu müssen. Mit Beenden verlassen Sie den Interaktiv-Modus.

4.4.3.2 yast add-on

 

Fügt ein neues Add-on-Produkt aus dem angegebenen Pfad ein: 

 tux > sudo yast add-on http://server.name/directory/Lang-AddOn-CD1/

Sie können den Quellpfad mit den folgenden Protokollen angeben: http:// ftp:// nfs:// disk:// cd:// oder dvd://.

4.4.3.3 yast audit-laf

 

Öffnet und konfiguriert das Linux Audit Framework. Weitere Informationen finden Sie im Book “Security and Hardening Guide”. yast audit-laf akzeptiert die folgenden Kommandos:

set

Legt eine Option fest: 

tux > sudo yast audit-laf set log_file=/tmp/audit.log

Mit yast audit-laf set help erhalten Sie eine vollständige Liste der Optionen.

show

Zeigt die Einstellungen für eine Option an: 

tux > sudo yast audit-laf show diskspace
space_left: 75
space_left_action: SYSLOG
admin_space_left: 50
admin_space_left_action: SUSPEND
action_mail_acct: root
disk_full_action: SUSPEND
disk_error_action: SUSPEND

Mit yast audit-laf show help erhalten Sie eine vollständige Liste der Optionen.

4.4.3.4 yast dhcp-server

 

Verwaltet den DHCP-Server und konfiguriert dessen Einstellung. yast dhcp-server akzeptiert die folgenden Kommandos:

Deaktivieren

Deaktiviert den DHCP-Serverdienst.

enable

Aktiviert den DHCP-Serverdienst.

Host

Konfiguriert Einstellungen für einzelne Hosts.

interface

Gibt an, welche Netzwerkschnittstelle überwacht werden soll: 

tux > sudo yast dhcp-server interface current
Selected Interfaces: eth0
Other Interfaces: bond0, pbu, eth1

Mit yast dhcp-server interface help erhalten Sie eine vollständige Liste der Optionen.

Optionen

Verwaltet globale DHCP-Optionen. Mit yast dhcp-server options help erhalten Sie eine vollständige Liste der Optionen.

status

Gibt den Status des DHCP-Dienstes aus.

subnet

Verwaltet die DHCP-Subnetzoptionen. Mit yast dhcp-server subnet help erhalten Sie eine vollständige Liste der Optionen.

4.4.3.5 yast dns-server

 

Verwaltet die DNS-Serverkonfiguration. yast dns-server akzeptiert die folgenden Kommandos:

acls

Zeigt die Einstellungen für die Zugriffssteuerungsliste an: 

 tux > sudo yast dns-server acls show
 ACLs:
 -----
  Name       Type        Value
  ----------------------------
  any        Predefined
  localips   Predefined
  localnets  Predefined
  none       Predefined
dnsrecord

Konfiguriert Zonenressourcen-Datensätze: 

tux > sudo yast dnsrecord add zone=example.org query=office.example.org type=NS value=ns3

Mit yast dns-server dnsrecord help erhalten Sie eine vollständige Liste der Optionen.

forwarders

Konfiguriert DNS-Forwarder: 

tux > sudo yast dns-server forwarders add ip=10.0.0.100
tux > sudo yast dns-server forwarders show
[...]
Forwarder IP
------------
10.0.0.100

Mit yast dns-server forwarders help erhalten Sie eine vollständige Liste der Optionen.

Host

Verarbeitet gleichzeitig „A“ und den zugehörigen „PTR“-Eintrag: 

tux > sudo yast dns-server host show zone=example.org

Mit yast dns-server host help erhalten Sie eine vollständige Liste der Optionen.

logging

Konfiguriert die Protokollierungseinstellungen: 

tux > sudo yast dns-server logging set updates=no transfers=yes

Mit yast dns-server logging help erhalten Sie eine vollständige Liste der Optionen.

mailserver

Konfiguriert die Zonen-Mailserver: 

tux > sudo yast dns-server mailserver add zone=example.org mx=mx1 priority=100

Mit yast dns-server mailserver help erhalten Sie eine vollständige Liste der Optionen.

nameserver

Konfiguriert die Zonen-Nameserver: 

tux > sudo yast dns-server nameserver add zone=example.com ns=ns1

Mit yast dns-server nameserver help erhalten Sie eine vollständige Liste der Optionen.

soa

Konfiguriert den SOA-Datensatz (Start of Authority): 

tux > sudo yast dns-server soa set zone=example.org serial=2006081623 ttl=2D3H20S

Mit yast dns-server soa help erhalten Sie eine vollständige Liste der Optionen.

startup

Verwaltet den DNS-Serverdienst: 

tux > sudo yast dns-server startup atboot

Mit yast dns-server startup help erhalten Sie eine vollständige Liste der Optionen.

transport

Konfiguriert die Regeln für den Zonentransport. Mit yast dns-server transport help erhalten Sie eine vollständige Liste der Optionen.

zones

Verwaltet die DNS-Zonen: 

tux > sudo yast dns-server zones add name=example.org zonetype=master

Mit yast dns-server zones help erhalten Sie eine vollständige Liste der Optionen.

4.4.3.6 yast disk

 

Gibt Informationen zu allen Festplatten oder Partitionen aus. Hier wird ausschließlich das Kommando list mit einer der folgenden Optionen unterstützt:

disks

Zeigt eine Liste aller konfigurierten Festplatten im System an: 

tux > sudo yast disk list disks
Device   | Size       | FS Type | Mount Point | Label | Model
---------+------------+---------+-------------+-------+-------------
/dev/sda | 119.24 GiB |         |             |       | SSD 840
/dev/sdb |  60.84 GiB |         |             |       | WD1003FBYX-0
Partitionen

Zeigt eine Liste aller Partitionen im System an: 

tux > sudo yast disk list partitions
Device         | Size       | FS Type | Mount Point | Label | Model
---------------+------------+---------+-------------+-------+------
/dev/sda1      |   1.00 GiB | Ext2    | /boot       |       |
/dev/sdb1      |   1.00 GiB | Swap    | swap        |       |
/dev/sdc1      | 698.64 GiB | XFS     | /mnt/extra  |       |
/dev/vg00/home | 580.50 GiB | Ext3    | /home       |       |
/dev/vg00/root | 100.00 GiB | Ext3    | /           |       |
[...]

4.4.3.7 yast ftp-server

 

Konfiguriert die Einstellungen für den FTP-Server. yast ftp-server akzeptiert die folgenden Optionen:

SSL, TLS

Steuert sichere Verbindungen über SSL und TLS. SSL-Optionen gelten ausschließlich für vsftpd. 

tux > sudo yast ftp-server SSL enable
tux > sudo yast ftp-server TLS disable
Zugriff

Konfiguriert die Zugriffsberechtigungen: 

tux > sudo yast ftp-server access authen_only

Mit yast ftp-server access help erhalten Sie eine vollständige Liste der Optionen.

anon_access

Konfiguriert die Zugriffsberechtigungen für anonyme Benutzer: 

tux > sudo yast ftp-server anon_access can_upload

Mit yast ftp-server anon_access help erhalten Sie eine vollständige Liste der Optionen.

anon_dir

Gibt das Verzeichnis für anonyme Benutzer an. Das Verzeichnis muss bereits auf dem Server vorhanden sein: 

tux > sudo yast ftp-server anon_dir set_anon_dir=/srv/ftp

Mit yast ftp-server anon_dir help erhalten Sie eine vollständige Liste der Optionen.

chroot

Steuert die change root-Umgebung (chroot): 

tux > sudo yast ftp-server chroot enable
tux > sudo yast ftp-server chroot disable
idle-time

Legt den maximal zulässigen Leerlaufzeitraum (in Minuten) fest, nach dem der FTP-Server die aktuelle Verbindung beendet: 

tux > sudo yast ftp-server idle-time set_idle_time=15
logging

Gibt an, ob die Protokollmeldungen in einer Protokolldatei gespeichert werden sollen: 

tux > sudo yast ftp-server logging enable
tux > sudo yast ftp-server logging disable
max_clients

Gibt die maximal zulässige Anzahl der gleichzeitig verbundenen Clients an: 

tux > sudo yast ftp-server max_clients set_max_clients=1500
max_clients_ip

Gibt die maximal zulässige Anzahl der gleichzeitig über IP verbundenen Clients an: 

tux > sudo yast ftp-server max_clients_ip set_max_clients=20
max_rate_anon

Gibt die maximal zulässige Datenübertragungsrate für anonyme Clients an (KB/s): 

tux > sudo yast ftp-server max_rate_anon set_max_rate=10000
max_rate_authen

Gibt die maximal zulässige Datenübertragungsrate für lokal authentifizierte Benutzer an (KB/s): 

tux > sudo yast ftp-server max_rate_authen set_max_rate=10000
port_range

Gibt den Portbereich für passive Verbindungsantworten an: 

tux > sudo yast ftp-server port_range set_min_port=20000 set_max_port=30000

Mit yast ftp-server port_range help erhalten Sie eine vollständige Liste der Optionen.

show

Zeigt die Einstellungen für den FTP-Server an.

startup

Steuert die FTP-Startmethode: 

tux > sudo yast ftp-server startup atboot

Mit yast ftp-server startup help erhalten Sie eine vollständige Liste der Optionen.

umask

Gibt die Datei-umask für authenticated:anonymous-Benutzer an: 

tux > sudo yast ftp-server umask set_umask=177:077
welcome_message

Gibt den Text an, der angezeigt werden soll, wenn ein Benutzer eine Verbindung zum FTP-Server herstellt: 

tux > sudo yast ftp-server welcome_message set_message="hello everybody"

4.4.3.8 yast http-server

 

Konfiguriert den HTTP-Server (Apache2). yast http-server akzeptiert die folgenden Kommandos:

configure

Konfiguriert die Host-Einstellungen für den HTTP-Server: 

tux > sudo yast http-server configure host=main servername=www.example.com \
 serveradmin=admin@example.com

Mit yast http-server configure help erhalten Sie eine vollständige Liste der Optionen.

hosts

Konfiguriert virtuelle Hosts: 

tux > sudo yast http-server hosts create servername=www.example.com \
 serveradmin=admin@example.com documentroot=/var/www

Mit yast http-server hosts help erhalten Sie eine vollständige Liste der Optionen.

listen

Gibt die Ports und Netzwerkadressen an, die der HTTP-Server überwachen soll: 

tux > sudo yast http-server listen add=81
tux > sudo yast http-server listen list
Listen Statements:
==================
:80
:81
tux > sudo yast http-server delete=80

Mit yast http-server listen help erhalten Sie eine vollständige Liste der Optionen.

Gruppenmodus

Aktiviert oder deaktiviert den Assistenten-Modus: 

tux > sudo yast http-server mode wizard=on
modules

Steuert die Apache2-Servermodule: 

tux > sudo yast http-server modules enable=php5,rewrite
tux > sudo yast http-server modules disable=ssl
tux > sudo http-server modules list
[...]
Enabled rewrite
Disabled ssl
Enabled php5
[...]

4.4.3.9 yast kdump

 

Konfiguriert die kdump-Einstellungen. Weitere Informationen zu kdump finden Sie im Book “System Analysis and Tuning Guide”, Chapter 20 “Kexec and Kdump”, Section 20.7 “Basic Kdump configuration”. yast kdump akzeptiert die folgenden Kommandos:

copykernel

Kopiert den Kernel in das Dump-Verzeichnis.

customkernel

Gibt den Bestandteil kernel_string im Namen des benutzerdefinierten Kernels an. Das Namensschema lautet: /boot/vmlinu[zx]-Kernel_Zeichenkette[.gz]. 

tux > sudo yast kdump customkernel kernel=kdump

Mit yast kdump customkernel help erhalten Sie eine vollständige Liste der Optionen.

dumpformat

Gibt das (Komprimierungs-)Format für das Dump-Kernel-Image an. Die verfügbaren Formate lauten „none“, „ELF“, „compressed“ oder „lzo“: 

tux > sudo yast kdump dumpformat dump_format=ELF
dumplevel

Gibt die Nummer für den Dump-Filterungsgrad an (0 bis 31): 

tux > sudo yast kdump dumplevel dump_level=24
dumptarget

Gibt das Ziel zum Speichern von Dump-Images an: 

tux > sudo kdump dumptarget taget=ssh server=name_server port=22 \
 dir=/var/log/dump user=user_name

Mit yast kdump dumptarget help erhalten Sie eine vollständige Liste der Optionen.

immediatereboot

Gibt an, ob das System nach dem Speichern des Core im kdump-Kernel sofort neu gestartet werden soll: 

tux > sudo yast kdump immediatereboot enable
tux > sudo yast kdump immediatereboot disable
keepolddumps

Gibt die Anzahl der aufzubewahrenden bisherigen Dump-Images an. Mit dem Wert 0 werden alle Images aufbewahrt: 

tux > sudo yast kdump keepolddumps no=5
kernelcommandline

Gibt die Kommandozeile an, die an den kdump-Kernel übergeben werden muss: 

tux > sudo yast kdump kernelcommandline command="ro root=LABEL=/"
kernelcommandlineappend

Gibt die Kommandozeile an, die an die standardmäßige Zeichenkette für die Kommandozeile angehängt werden muss: 

tux > sudo yast kdump kernelcommandlineappend command="ro root=LABEL=/"
notificationcc

Gibt eine Email-Adresse an, an die eine Kopie der Benachrichtigungen gesendet werden soll: 

tux > sudo yast kdump notificationcc email="user1@example.com user2@example.com"
notificationto

Gibt eine Email-Adresse an, an die die Benachrichtigungen gesendet werden sollen: 

tux > sudo yast kdump notificationto email="user1@example.com user2@example.com"
show

Zeigt die kdump-Einstellungen an: 

tux > sudo yast kdump show
Kdump is disabled
Dump Level: 31
Dump Format: compressed
Dump Target Settings
target: file
file directory: /var/crash
Kdump immediate reboots: Enabled
Numbers of old dumps: 5
smtppass

Gibt die Datei an, die das SMTP-Passwort (in Klartext) für das Senden von Benachrichtigungen enthält: 

tux > sudo yast kdump smtppass pass=/path/to/file
smtpserver

Gibt den Hostnamen des SMTP-Servers an, über den die Benachrichtigungen gesendet werden sollen: 

tux > sudo yast kdump smtpserver server=smtp.server.com
smtpuser

Gibt den SMTP-Benutzernamen an, über den die Benachrichtigungen gesendet werden sollen: 

tux > sudo yast kdump smtpuser user=smtp_user
startup

Aktiviert oder deaktiviert die Startoptionen: 

tux > sudo yast kdump startup enable alloc_mem=128,256
tux > sudo yast kdump startup disable

4.4.3.10 yast keyboard

 

Konfiguriert die Systemtastatur für virtuelle Konsolen. Dies wirkt sich nicht auf die Tastatureinstellungen in grafischen Benutzerumgebungen wie GNOME oder KDE aus. yast keyboard akzeptiert die folgenden Kommandos:

list

Zeigt eine Liste aller verfügbaren Tastaturbelegungen an.

set

Aktiviert eine neue Einstellung für die Tastaturbelegung: 

tux > sudo yast keyboard set layout=czech
Zusammenfassung

Zeigt die aktuelle Tastaturkonfiguration an.

4.4.3.11 yast lan

 

Konfiguriert die Netzwerkkarten. yast lan akzeptiert die folgenden Kommandos:

add

Konfiguriert eine neue Netzwerkkarte: 

tux > sudo yast lan add name=vlan50 ethdevice=eth0 bootproto=dhcp

Mit yast lan add help erhalten Sie eine vollständige Liste der Optionen.

Löschen

Löscht eine vorhandene Netzwerkkarte: 

tux > sudo yast lan delete id=0
Bearbeiten

Ändert die Konfiguration einer vorhandenen Netzwerkkarte: 

tux > sudo yast lan edit id=0 bootproto=dhcp
list

Zeigt eine Zusammenfassung der Netzwerkkartenkonfiguration an: 

tux > sudo yast lan list
id name,           bootproto
0 Ethernet Card 0, NONE
1 Network Bridge,  DHCP

4.4.3.12 yast language

 

Konfiguriert die Systemsprachen. yast language akzeptiert die folgenden Kommandos:

list

Zeigt eine Liste aller verfügbaren Sprachen an.

set

Gibt die Hauptsystemsprachen und sekundären Sprachen an: 

tux > sudo yast language set lang=cs_CZ languages=en_US,es_ES no_packages

4.4.3.13 yast mail

 

Zeigt die Konfiguration des Mailsystems an: 

tux > sudo yast mail summary

4.4.3.14 yast nfs

 

Steuert den NFS-Client. yast nfs akzeptiert die folgenden Kommandos:

add

Fügt eine neue NFS-Einhängung ein: 

tux > sudo yast nfs add spec=remote_host:/path/to/nfs/share file=/local/mount/point

Mit yast nfs add help erhalten Sie eine vollständige Liste der Optionen.

Löschen

Löscht eine vorhandene NFS-Einhängung: 

tux > sudo yast nfs delete spec=remote_host:/path/to/nfs/share file=/local/mount/point

Mit yast nfs delete help erhalten Sie eine vollständige Liste der Optionen.

Bearbeiten

Ändert eine vorhandene NFS-Einhängung: 

tux > sudo yast nfs edit spec=remote_host:/path/to/nfs/share \
 file=/local/mount/point type=nfs4

Mit yast nfs edit help erhalten Sie eine vollständige Liste der Optionen.

list

Zeigt eine Liste der vorhandenen NFS-Einhängungen an: 

tux > sudo yast nfs list
Server            Remote File System    Mount Point    Options
----------------------------------------------------------------
nfs.example.com   /mnt                  /nfs/mnt       nfs
nfs.example.com   /home/tux/nfs_share   /nfs/tux       nfs

4.4.3.15 yast nfs-server

 

Konfiguriert den NFS-Server. yast nfs-server akzeptiert die folgenden Kommandos:

add

Fügt ein Verzeichnis zum Exportieren ein: 

tux > sudo yast nfs-server add mountpoint=/nfs/export hosts=*.allowed_hosts.com

Mit yast nfs-server add help erhalten Sie eine vollständige Liste der Optionen.

Löschen

Löscht ein Verzeichnis aus dem NFS-Export: 

 tux > sudo yast nfs-server delete mountpoint=/nfs/export
set

Gibt zusätzliche Parameter für den NFS-Server an: 

tux > sudo yast nfs-server set enablev4=yes security=yes

Mit yast nfs-server set help erhalten Sie eine vollständige Liste der Optionen.

start

Startet den NFS-Serverdienst: 

tux > sudo yast nfs-server start
stop

Hält den NFS-Serverdienst an: 

tux > sudo yast nfs-server stop
Zusammenfassung

Zeigt eine Zusammenfassung der NFS-Serverkonfiguration an: 

tux > sudo yast nfs-server summary
NFS server is enabled
NFS Exports
* /mnt
* /home

NFSv4 support is enabled.
The NFSv4 domain for idmapping is localdomain.
NFS Security using GSS is enabled.

4.4.3.16 yast nis

 

Konfiguriert den NIS-Client. yast nis akzeptiert die folgenden Kommandos:

configure

Ändert globale Einstellungen für einen NIS-Client: 

tux > sudo yast nis configure server=nis.example.com broadcast=yes

Mit yast nis configure help erhalten Sie eine vollständige Liste der Optionen.

Deaktivieren

Deaktiviert den NIS-Client: 

tux > sudo yast nis disable
enable

Aktiviert den Computer als NIS-Client: 

tux > sudo yast nis enable server=nis.example.com broadcast=yes automounter=yes

Mit yast nis enable help erhalten Sie eine vollständige Liste der Optionen.

Suche

Zeigt die verfügbaren NIS-Server für eine bestimmte Domäne an: 

tux > sudo yast nis find domain=nisdomain.com
Zusammenfassung

Zeigt eine Konfigurationszusammenfassung für einen NIS-Client an.

4.4.3.17 yast nis-server

 

Konfiguriert einen NIS-Server. yast nis-server akzeptiert die folgenden Kommandos:

master

Konfiguriert einen NIS-Master-Server: 

tux > sudo yast nis-server master domain=nisdomain.com yppasswd=yes

Mit yast nis-server master help erhalten Sie eine vollständige Liste der Optionen.

slave

Konfiguriert einen NIS-Slave-Server: 

tux > sudo yast nis-server slave domain=nisdomain.com master_ip=10.100.51.65

Mit yast nis-server slave help erhalten Sie eine vollständige Liste der Optionen.

stop

Hält einen NIS-Server an: 

tux > sudo yast nis-server stop
Zusammenfassung

Zeigt eine Konfigurationszusammenfassung für einen NIS-Server an: 

tux > sudo yast nis-server summary

4.4.3.18 yast proxy

 

Konfiguriert Proxy-Einstellungen. yast proxy akzeptiert die folgenden Kommandos:

Authentifizierung

Gibt die Authentifizierungsoptionen für den Proxy an: 

tux > sudo yast proxy authentication username=tux password=secret

Mit yast proxy authentication help erhalten Sie eine vollständige Liste der Optionen.

enable, disable

Aktiviert oder deaktiviert die Proxy-Einstellungen.

set

Ändert die aktuellen Proxy-Einstellungen: 

tux > sudo yast proxy set https=proxy.example.com

Mit yast proxy set help erhalten Sie eine vollständige Liste der Optionen.

Zusammenfassung

Zeigt die Proxy-Einstellungen an.

4.4.3.19 yast rdp

 

Steuert die Remote-Desktop-Einstellungen. yast rdp akzeptiert die folgenden Kommandos:

allow

Gestattet den Remote-Zugriff auf den Desktop des Servers: 

tux > sudo yast rdp allow set=yes
list

Zeigt die Konfigurationszusammenfassung für den Remote-Desktop an.

4.4.3.20 yast samba-client

 

Konfiguriert die Samba-Client-Einstellungen. yast samba-client akzeptiert die folgenden Kommandos:

configure

Ändert globale Einstellungen für Samba: 

tux > sudo yast samba-client configure workgroup=FAMILY
isdomainmember

Überprüft, ob der Rechner Mitglied einer Domäne ist: 

tux > sudo yast samba-client isdomainmember domain=SMB_DOMAIN
joindomain

Nimmt den Computer als Mitglied in eine Domäne auf: 

tux > sudo yast samba-client joindomain domain=SMB_DOMAIN user=username password=pwd
winbind

Aktiviert oder deaktiviert die Winbind-Services (den winbindd-Daemon): 

tux > sudo yast samba-client winbind enable
tux > sudo yast samba-client winbind disable

4.4.3.21 yast samba-server

 

Konfiguriert die Einstellungen für den Samba-Server. yast samba-server akzeptiert die folgenden Kommandos:

Backend

Gibt das Back-End zum Speichern der Benutzerdaten an: 

tux > sudo yast samba-server backend smbpasswd

Mit yast samba-server backend help erhalten Sie eine vollständige Liste der Optionen.

configure

Konfiguriert globale Einstellungen für den Samba-Server: 

tux > sudo yast samba-server configure workgroup=FAMILY description='Home server'

Mit yast samba-server configure help erhalten Sie eine vollständige Liste der Optionen.

list

Zeigt eine Liste der verfügbaren Freigaben an: 

tux > sudo yast samba-server list
Status     Type Name
==============================
Disabled   Disk profiles
Enabled    Disk print$
Enabled    Disk homes
Disabled   Disk groups
Enabled    Disk movies
Enabled    Printer printers
role

Gibt die Funktion des Samba-Servers an: 

tux > sudo yast samba-server role standalone

Mit yast samba-server role help erhalten Sie eine vollständige Liste der Optionen.

service

Aktiviert oder deaktiviert die Samba-Dienste (smb und nmb): 

tux > sudo yast samba-server service enable
tux > sudo yast samba-server service disable
Freigeben

Manipuliert eine einzelne Samba-Freigabe: 

tux > sudo yast samba-server share name=movies browseable=yes guest_ok=yes

Mit yast samba-server share help erhalten Sie eine vollständige Liste der Optionen.

4.4.3.22 yast security

 

Steuert die Sicherheitsstufe des Hosts. yast security akzeptiert die folgenden Kommandos:

Stufe

Gibt die Sicherheitsstufe des Hosts an: 

tux > sudo yast security level server

Mit yast security level help erhalten Sie eine vollständige Liste der Optionen.

set

Legt den Wert einer bestimmten Option fest: 

tux > sudo yast security set passwd=sha512 crack=yes

Mit yast security set help erhalten Sie eine vollständige Liste der Optionen.

summary

Zeigt eine Zusammenfassung der aktuellen Sicherheitskonfiguration an: 

sudoyast security summary

4.4.3.23 yast sound

 

Konfiguriert die Einstellungen für die Soundkarte. yast sound akzeptiert die folgenden Kommandos:

add

Konfiguriert eine neue Soundkarte. Falls keine Parameter angegeben sind, fügt das Kommando die erste erkannte Soundkarte hinzu. 

tux > sudo yast sound add card=0 volume=75

Mit yast sound add help erhalten Sie eine vollständige Liste der Optionen.

channels

Zeigt eine Liste der verfügbaren Lautstärkekanäle einer Soundkarte an: 

tux > sudo yast sound channels card=0
Master 75
PCM 100
modules

Zeigt eine Liste aller verfügbaren Sound-Kernel-Module an: 

tux > sudo yast sound modules
snd-atiixp ATI IXP AC97 controller (snd-atiixp)
snd-atiixp-modem ATI IXP MC97 controller (snd-atiixp-modem)
snd-virtuoso Asus Virtuoso driver (snd-virtuoso)
[...]
playtest

Spielt einen Testsound über eine Soundkarte ab: 

tux > sudo yast sound playtest card=0
Entfernen

Entfernt eine konfigurierte Soundkarte: 

tux > sudo yast sound remove card=0
tux > sudo yast sound remove all
set

Gibt neue Werte für eine Soundkarte an: 

tux > sudo yast sound set card=0 volume=80
show

Zeigt ausführliche Informationen zu einer Soundkarte an: 

tux > sudo yast sound show card=0
Parameters of card 'ThinkPad X240' (using module snd-hda-intel):

align_buffer_size
 Force buffer and period sizes to be multiple of 128 bytes.
bdl_pos_adj
 BDL position adjustment offset.
beep_mode
 Select HDA Beep registration mode (0=off, 1=on) (default=1).
 Default Value: 0
enable_msi
 Enable Message Signaled Interrupt (MSI)
[...]
summary

Gibt eine Konfigurationszusammenfassung für alle Soundkarten im System aus: 

tux > sudo yast sound summary
volume

Gibt die Lautstärke einer Soundkarte an: 

sudoyast sound volume card=0 play

4.4.3.24 yast sysconfig

 

Steuert die Variablen in den Dateien unter /etc/sysconfig. yast sysconfig akzeptiert die folgenden Kommandos:

Löschen

Legt eine leeren Wert für eine Variable fest: 

tux > sudo yast sysconfig clear=POSTFIX_LISTEN
Tipp
Tipp: Variable in mehreren Dateien

Falls sich die Variable in mehreren Dateien befindet, gilt die Syntax VARIABLENNAME$DATEINAME: 

tux > sudo yast sysconfig clear=CONFIG_TYPE$/etc/sysconfig/mail
Details

Zeigt ausführliche Informationen zu einer Variable an: 

tux > sudo yast sysconfig details variable=POSTFIX_LISTEN
Description:
Value:
File: /etc/sysconfig/postfix
Possible Values: Any value
Default Value:
Configuration Script: postfix
Description:
 Comma separated list of IP's
 NOTE: If not set, LISTEN on all interfaces
list

Zeigt eine Zusammenfassung der geänderten Variablen an. Mit all werden alle Variablen und ihre zugehörigen Werte angezeigt: 

tux > sudo yast sysconfig list all
AOU_AUTO_AGREE_WITH_LICENSES="false"
AOU_ENABLE_CRONJOB="true"
AOU_INCLUDE_RECOMMENDS="false"
[...]
set

Legt einen Wert für eine Variable fest: 

tux > sudo yast sysconfig set DISPLAYMANAGER=gdm
Tipp
Tipp: Variable in mehreren Dateien

Falls sich die Variable in mehreren Dateien befindet, gilt die Syntax VARIABLENNAME$DATEINAME: 

tux > sudo yast sysconfig set CONFIG_TYPE$/etc/sysconfig/mail=advanced

4.4.3.25 yast tftp-server

 

Konfiguriert einen TFTP-Server. yast tftp-server akzeptiert die folgenden Kommandos:

Verzeichnis

Gibt das Verzeichnis für den TFTP-Server an: 

tux > sudo yast tftp-server directory path=/srv/tftp
tux > sudo yast tftp-server directory list
Directory Path: /srv/tftp
status

Steuert den Status des TFTP-Serverdienstes: 

tux > sudo yast tftp-server status disable
tux > sudo yast tftp-server status show
Service Status: false
tux > sudo yast tftp-server status enable

4.4.3.26 yast timezone

 

Konfiguriert die Zeitzone. yast timezone akzeptiert die folgenden Kommandos:

list

Zeigt eine Liste aller verfügbaren Zeitzonen an, gruppiert nach Region: 

tux > sudo yast timezone list
Region: Africa
Africa/Abidjan (Abidjan)
Africa/Accra (Accra)
Africa/Addis_Ababa (Addis Ababa)
[...]
set

Gibt neue Werte für die Zeitzonenkonfiguration an: 

tux > sudo yast timezone set timezone=Europe/Prague hwclock=local
Zusammenfassung

Zeigt eine Zusammenfassung der Zeitzonenkonfiguration an: 

tux > sudo yast timezone summary
Current Time Zone: Europe/Prague
Hardware Clock Set To: Local time
Current Time and Date: Mon 12. March 2018, 11:36:21 CET

4.4.3.27 yast users

 

Verwaltet die Benutzerkonten. yast users akzeptiert die folgenden Kommandos:

add

Fügt einen neuen Benutzer hinzu: 

tux > sudo yast users add username=user1 password=secret home=/home/user1

Mit yast users add help erhalten Sie eine vollständige Liste der Optionen.

Löschen

Löscht ein vorhandenes Benutzerkonto: 

tux > sudo yast users delete username=user1 delete_home

Mit yast users delete help erhalten Sie eine vollständige Liste der Optionen.

Bearbeiten

Ändert ein vorhandenes Benutzerkonto: 

tux > sudo yast users edit username=user1 password=new_secret

Mit yast users edit help erhalten Sie eine vollständige Liste der Optionen.

list

Zeigt eine Liste der vorhandenen Benutzer an, gefiltert nach dem Benutzertyp: 

tux > sudo yast users list system

Mit yast users list help erhalten Sie eine vollständige Liste der Optionen.

show

Zeigt Details zu einem Benutzer an: 

tux > sudo yast users show username=wwwrun
Full Name: WWW daemon apache
List of Groups: www
Default Group: wwwrun
Home Directory: /var/lib/wwwrun
Login Shell: /sbin/nologin
Login Name: wwwrun
UID: 456

Mit yast users show help erhalten Sie eine vollständige Liste der Optionen.

5 YaST-Online-Aktualisierung

 

SUSE stellt fortlaufend Sicherheitsaktualisierungen für Ihr Softwareprodukt bereit. Standardmäßig stellt das Miniprogramm für die Aktualisierung sicher, dass Ihr System stets auf dem neuesten Stand ist. Weitere Informationen zu diesem Miniprogramm finden Sie im Book “Bereitstellungshandbuch”, Chapter 21 “Installieren bzw. Entfernen von Software”, Section 21.5 “Der GNOME Package Updater”. Dieses Kapitel behandelt das alternative Tool für die Aktualisierung von Software-Paketen: die YaST-Online-Aktualisierung.

Die aktuellen Patches für SUSE® Linux Enterprise Server sind über ein Software-Aktualisierungs-Repository verfügbar. Wenn Sie Ihr Produkt während der Installation registriert haben, ist das Aktualisierungs-Repository bereits konfiguriert. Falls Sie SUSE Linux Enterprise Server noch nicht registriert haben, starten Sie die Produktkonfiguration in YaST. Alternativ können Sie ein Aktualisierungs-Repository manuell von einer verbürgten Quelle hinzufügen. Starten Sie zum Hinzufügen oder Entfernen von Repositorys den Repository-Manager über Software › Software-Repositorys in YaST. Weitere Informationen zum Repository Manager finden Sie im Book “Bereitstellungshandbuch”, Chapter 21 “Installieren bzw. Entfernen von Software”, Section 21.4 “Verwalten von Software-Repositorys und -Diensten”.

Anmerkung
Anmerkung: Fehler beim Zugriff auf den Aktualisierungskatalog

Wenn Sie keinen Zugriff auf den Aktualisierungskatalog erhalten, liegt das eventuell daran, dass Ihr Abo abgelaufen ist. In der Regel umfasst SUSE Linux Enterprise Server ein einjähriges oder dreijähriges Abo, mit dem Sie Zugriff auf den Aktualisierungskatalog erhalten. Dieser Zugriff wird verweigert, sobald das Abo beendet ist.

Falls der Zugriff zum Aktualisierungskatalog verweigert wird, wird eine Warnmeldung angezeigt, mit der Sie aufgefordert werden, das SUSE Customer Center aufzurufen und Ihr Abo zu überprüfen. Das SUSE Customer Center erreichen Sie unter https://scc.suse.com//.

SUSE bietet Aktualisierungen mit verschiedenen Relevanzstufen:

Sicherheitsaktualisierungen

Beseitigen ernsthafte Sicherheitsrisiken und sollten stets installiert werden.

Empfohlene Aktualisierungen

Beseitigen Probleme, die Ihrem Rechner schaden können.

Optionale Aktualisierungen

Beseitigen nicht sicherheitsrelevante Probleme oder bieten Verbesserungen.

5.1 Das Dialogfeld „Online-Aktualisierung“

 

Zum Öffnen des Dialogfelds Online-Aktualisierung starten Sie YaST, und wählen Sie Software  › Online-Aktualisierung. Stattdessen können Sie es auch von der Kommandozeile aus mit dem Kommando yast2 online_update starten.

Das Fenster Online-Update ist in vier Abschnitte unterteilt.

YaST-Online-Aktualisierung
Abbildung 5.1: YaST-Online-Aktualisierung
 

Unter Zusammenfassung im linken Bereich werden die verfügbaren Patches für SUSE Linux Enterprise Server aufgeführt. Die Patches werden nach Sicherheitsrelevanz (Sicherheit, Empfohlen und Optional) sortiert. Sie können die Ansicht des Abschnitts Zusammenfassung ändern, indem Sie eine der folgenden Optionen unter Patch-Kategorie anzeigen auswählen:

Erforderliche Patches (Standardansicht)

Nicht installierte Patches für Pakete, die auf Ihrem System installiert sind.

Nicht erforderliche Patches

Patches für Pakete, die nicht auf Ihrem System installiert sind, oder Patches, die nicht mehr erforderlich sind (weil die relevanten Pakete bereits von einer anderen Quelle aktualisiert wurden).

Alle Patches

Alle verfügbaren Patches für SUSE Linux Enterprise Server.

Jeder Listeneintrag im Abschnitt Zusammenfassung besteht aus einem Symbol und dem Patch-Namen. Eine Übersicht der möglichen Symbole und deren Bedeutung erhalten Sie, wenn Sie die Taste Umschalttaste–F1 drücken. Die erforderlichen Aktionen für Patches der Kategorie Sicherheit und Empfohlen sind automatisch voreingestellt. Möglich sind die Aktionen Automatisch installieren, Automatisch aktualisieren und Automatisch löschen.

Wenn Sie ein aktuelles Paket aus einem anderen als dem Aktualisierungs-Repository installieren, können die Anforderungen eines Patches für dieses Paket mit dieser Installation erfüllt sein. In diesem Fall wird ein Häkchen vor der Patchzusammenfassung angezeigt. Das Patch wird in der Liste angezeigt, bis Sie es für die Installation kennzeichnen. Dadurch wird nicht das Patch installiert (da das Paket bereits aktuell ist), sondern das Patch als installiert gekennzeichnet.

Wählen Sie einen Eintrag im Abschnitt Zusammenfassung aus, um eine kurze Patch-Beschreibung unten links im Dialogfeld anzuzeigen. Im Abschnitt oben rechts werden die Pakete aufgeführt, die im ausgewählten Patch enthalten sind (ein Patch kann aus mehreren Paketen bestehen). Klicken Sie im Abschnitt oben rechts auf einen Eintrag, um Details zu dem entsprechenden Paket, das im Patch enthalten ist, anzuzeigen.

5.2 Installieren von Patches

 

Im Dialogfeld der YaST-Online-Aktualisierung können Sie wahlweise alle verfügbaren Patches gleichzeitig installieren oder die gewünschten Patches manuell auswählen. Außerdem können Sie Patches, die auf das System angewendet wurden, zurücksetzen.

Standardmäßig sind alle neuen Patches (außer den optionalen), die derzeit für Ihr System verfügbar sind, bereits zur Installation markiert. Sie werden automatisch angewendet, sobald Sie auf Übernehmen oder Anwenden klicken. Falls das System bei einem oder mehreren Patches neu gebootet werden muss, werden Sie hierüber informiert, bevor die Patch-Installation beginnt. Sie können dann die Installation der ausgewählten Patches fortsetzen, die Installation aller Patches, für die das System neu gebootet werden muss, überspringen und die restlichen Patches installieren oder auch zur manuellen Patch-Auswahl zurückkehren.

Vorgehen 5.1: Anwenden von Patches mit der YaST-Online-Aktualisierung
 

  1. Starten Sie YaST, und wählen Sie Software › Online-Aktualisierung.

  2. Sollen alle neuen Patches (ausgenommen die optionalen Patches), die derzeit für Ihr System verfügbar sind, automatisch angewendet werden, klicken Sie auf Anwenden oder Übernehmen.

  3. Ändern Sie zunächst die Auswahl der Patches, die Sie anwenden möchten:

    1. Verwenden Sie die verfügbaren Filter und Ansichten der Schnittstelle. Detaillierte Informationen finden Sie in Abschnitt 5.1, „Das Dialogfeld „Online-Aktualisierung““.

    2. Wählen Sie die Patches gemäß Ihren Anforderungen aus (bzw. heben Sie die Auswahl der Patches wieder auf), und wählen Sie die entsprechende Aktion im Kontextmenü.

      Wichtig
      Wichtig: Anwenden von Sicherheitsaktualisierungen ohne Ausnahme

      Heben Sie die Auswahl der sicherheitsrelevanten Patches nicht ohne stichhaltigen Grund auf. Diese Patches beseitigen ernsthafte Sicherheitsrisiken und schützen Ihr System vor Angriffen.

    3. Die meisten Patches umfassen Aktualisierungen für mehrere Pakete. Wenn Sie Aktionen für einzelne Pakete ändern möchten, klicken Sie mit der rechten Maustaste auf ein Paket in der Paketansicht und wählen Sie eine Aktion.

    4. Bestätigen Sie Ihre Auswahl, und wenden Sie die ausgewählten Patches mit Anwenden oder Übernehmen an.

  4. Klicken Sie nach abgeschlossener Installation auf Beenden, um das YaST-Dialogfeld Online-Aktualisierung zu verlassen. Ihr System ist nun auf dem neuesten Stand.

5.3 Automatische Online-Aktualisierungen

 

Bei YaST können Sie automatische Aktualisierungen mit täglichem, wöchentlichem oder monatlichem Zeitplan konfigurieren. Installieren Sie das yast2-online-update-configuration-Paket.

Standardmäßig werden die Aktualisierungen als Delta-RPMs heruntergeladen. Das Neuaufbauen von RPM-Paketen aus Delta-RPMs bewirkt eine hohe Belastung des Arbeitsspeichers und des Prozessors. Aus Leistungsgründen müssen Sie daher bei bestimmten Einrichtungen oder Hardware-Konfigurationen die Verwendung von Delta-RPMs deaktivieren.

Einige Patches, z. B. Kernel-Updates oder Pakete mit Lizenzvereinbarungen, erfordern Benutzerinteraktion, wodurch der automatische Aktualisierungsprozess angehalten würde. Sie können konfigurieren, dass Patches, für die ein Eingreifen des Benutzers erforderlich ist, übersprungen werden sollen.

Auf dem Karteireiter Patches im YaST-Software-Modul finden Sie die verfügbaren und installierten Patches, einschließlich der Verweise auf Fehlerberichte und CVE-Bulletins.

Vorgehen 5.2: Konfigurieren der automatischen Online-Aktualisierung
 

  1. Nach der Installation starten Sie YaST und wählen Sie Software › Online-Aktualisierung aus. Wählen Sie Konfiguration › Online-Aktualisierung. Wenn yast2-online-update-configuration nicht installiert ist, werden Sie dazu aufgefordert.

    Konfiguration der YaST-Online-Aktualisierung
    Abbildung 5.2: Konfiguration der YaST-Online-Aktualisierung
     

    Sie können das Modul auch mit dem Kommando yast2 online_update_configuration von der Kommandozeile aus starten.

  2. Legen Sie das Aktualisierungsintervall fest: Täglich, Wöchentlich oder Monatlich.

  3. Bei manchen Patches ist möglicherweise das Eingreifen des Administrators erforderlich, beispielsweise wenn wichtige Services neu gestartet werden. Es könnte zum Beispiel eine Aktualisierung für Docker Open Source Engine sein, bei der alle Container neu gestartet werden müssen. Vor der Installation dieser Patches wird der Benutzer über die Konsequenzen informiert und aufgefordert, die Installation des Patchs zu bestätigen. Derartige Patches werden als „Interaktive Patches“ bezeichnet.

    Bei der automatischen Installation von Patches wird angenommen, dass Sie die Installation von interaktiven Patches akzeptiert haben. Wenn Sie diese Patches vor der Installation lieber prüfen möchten, aktivieren Sie das Kontrollkästchen für Interaktive Patches überspringen. In diesem Fall werden interaktive Patches beim automatischen Patching übersprungen. Stellen Sie sicher, dass Sie regelmäßig eine manuelle Online-Aktualisierung ausführen, um zu prüfen, ob interaktive Patches zur Installation bereitstehen.

  4. Damit Lizenzvereinbarungen automatisch akzeptiert werden, aktivieren Sie die Option Lizenzen zustimmen.

  5. Sollen alle Pakete automatisch installiert werden, die durch die aktualisierten Pakete empfohlen werden, aktivieren Sie Empfohlene Pakete einbeziehen.

  6. Soll die Verwendung von Delta-RPMs (aus Leistungsgründen) deaktiviert werden, deaktivieren Sie Delta-RPMs verwenden.

  7. Sollen die Patches nach Kategorie gefiltert werden (z. B. Sicherheits-Patches oder empfohlene Patches), aktivieren Sie das Kontrollkästchen für Nach Kategorie filtern, und fügen Sie die entsprechenden Patch-Kategorien aus der Liste hinzu. Es werden nur Patches aus den ausgewählten Kategorien installiert. Es hat sich bewährt, nur automatische Sicherheit-Aktualisierungen zu aktiveren und alle anderen manuell zu prüfen. Patches sind normalerweise zuverlässig, doch Sie sollten Nicht-Sicherheit-Patches testen und ein Rollback durchführen, wenn dabei Probleme auftreten.

    • In der Kategorie Paketverwaltung und YaST werden Patches für die Paketverwaltung sowie YaST-Funktionen und -Module zur Verfügung gestellt.

    • Patches der Kategorie Sicherheit enthalten wichtige Aktualisierungen und Fehlerkorrekturen.

    • Patches der Kategorie Empfohlen sind optionale Fehlerkorrekturen und Verbesserungen.

    • Die Kategorie Optional enthält neue Pakete.

    • Die Kategorie Sonstige entspricht der Kategorie „Verschiedenes“.

    • Die Kategorie Dokument wird nicht genutzt.

  8. Bestätigen Sie Ihre Konfiguration durch Klicken auf OK.

Die automatische Online-Aktualisierung startet das System im Anschluss nicht automatisch neu. Sind Paketaktualisierungen vorhanden, die einen System-Reboot erfordern, müssen Sie dies manuell durchführen.

6 Verwalten von Software mit Kommandozeilenwerkzeugen

 

Dieses Kapitel behandelt zypper und RPM, zwei Kommandozeilen-Tools zum Verwalten von Software. Eine Definition der in diesem Kontext verwendeten Terminologie (beispielsweise Repository, Patch oder Update) finden Sie unter Book “Bereitstellungshandbuch”, Chapter 21 “Installieren bzw. Entfernen von Software”, Section 21.1 “Definition der Begriffe”.

6.1 Verwenden von zypper

 

Über den Kommandozeilen-Paketmanager Zypper können Sie Pakete installieren, aktualisieren und entfernen. Auch Repositorys werden hiermit verwaltet. Damit können Sie Software per Fernzugriff oder mithilfe von Shell-Skripten verwalten.

6.1.1 Allgemeine Verwendung

 

Die allgemeine Syntax von Zypper sieht wie folgt aus: 

zypper [--global-options] COMMAND  [--command-options] [arguments]

Die Komponenten in Klammern sind nicht erforderlich. Eine Liste der allgemeinen Optionen und aller Befehle erhalten Sie mit zypper help. Wenn Sie Hilfe zu einem bestimmten Befehl abrufen möchten, geben Sie zypper help BEFEHL ein.

Zypper-Kommandos

Am einfachsten führen Sie Zypper aus, indem Sie seinen Namen gefolgt von einem Kommando eingeben. Geben Sie z. B. für das Anwenden aller erforderlichen Patches auf das System Folgendes ein: 

tux > sudo zypper patch
Globale Optionen

Zusätzlich können Sie aus einer oder mehreren globalen Optionen wählen, indem Sie sie direkt vor dem Kommando eingeben: 

tux > sudo zypper --non-interactive patch

Im Beispiel oben bedeutet die Option --non-interactive, dass das Kommando ausgeführt wird, ohne nach Informationen zu fragen (die Standardantworten werden automatisch angewendet).

Kommandospezifische Optionen

Um die spezifischen Optionen für ein bestimmtes Kommando zu verwenden, geben Sie sie direkt nach dem Kommando ein. 

tux > sudo zypper patch --auto-agree-with-licenses

Im Beispiel oben wird --auto-agree-with-licenses verwendet, um alle erforderlichen Patches auf ein System anzuwenden, ohne dass Sie aufgefordert werden, Lizenzen zu bestätigen. Stattdessen wird die Lizenz automatisch akzeptiert.

Argumente

Einige Kommandos erfordern ein oder mehrere Argumente. Wird beispielsweise das Kommando install verwendet, müssen Sie angeben, welches Paket oder welche Pakete Sie installieren möchten: 

tux > sudo zypper install mplayer

Manche Optionen erfordern auch ein einzelnes Argument. Das folgende Kommando listet alle bekannten Muster auf: 

tux > zypper search -t pattern

Sie können alle obigen Optionen kombinieren. Beispielsweise werden durch das folgende Kommando die Pakete mc und vim aus dem factory-Repository im Verbose-Modus installiert: 

tux > sudo zypper -v install --from factory mc vim

Mit der Option --from bleiben alle Repositorys aktiviert (damit alle Abhängigkeiten aufgelöst werden können), wenn das Paket aus dem angegebenen Repository abgerufen wird. --repo ist ein Alias für --from. Sie können beide verwenden.

Die meisten Zypper-Kommandos besitzen eine dry-run-Option, die eine Simulation des angegebenen Kommandos ausführt. Sie kann für Tests verwendet werden. 

tux > sudo zypper remove --dry-run MozillaFirefox

Zypper unterstützt die globale Option --userdata ZEICHENKETTE. Bei dieser Option können Sie eine Zeichenkette angeben, die dann in die Protokolle und Plugins von Zypper geschrieben wird (z. B. in das Btrfs-Plugin). Hiermit können Sie Transaktionen in Protokolldateien kennzeichnen. 

tux > sudo zypper --userdata STRING patch

6.1.2 Verwenden von Zypper-Unterkommandos

 

Zypper-Unterkommandos sind ausführbare Dateien, die im zypper_execdir unter /usr/lib/zypper/commands gespeichert sind. Wenn ein Unterkommando nicht im zypper_execdir zu finden ist, durchsucht Zypper automatisch den Rest des $PATH danach. Dadurch können Sie eigene lokale Erweiterungen schreiben und sie im Benutzerbereich speichern.

Die Ausführung von Unterkommandos in der Zypper-Shell sowie die Verwendung globaler Zypper-Optionen wird nicht unterstützt.

Listen Sie die verfügbaren Unterkommandos auf: 

tux > zypper help subcommand
[...]
Available zypper subcommands in '/usr/lib/zypper/commands'

  appstream-cache
  lifecycle
  migration
  search-packages

Zypper subcommands available from elsewhere on your $PATH

  <none>

Zeigen Sie die Hilfe-Bildschirm für ein Unterkommando an: 

tux > zypper help appstream-cache

6.1.3 Installieren und Entfernen von Software mit Zypper

 

Verwenden Sie zur Installation oder Löschung von Paketen die folgenden Kommandos: 

tux > sudo zypper install PACKAGE_NAME
tux > sudo zypper remove PACKAGE_NAME
Warnung
Warnung: Entfernen Sie keine obligatorischen Systempakete

Entfernen Sie keine obligatorischen Systempakete, wie glibc , zypper , kernel . Werden diese Pakete entfernt, kann das System instabil werden oder aufhören zu funktionieren.

6.1.3.1 Auswählen, welche Pakete zu installieren oder zu entfernen sind

 

Es gibt verschiedene Methoden, Pakete mit den Kommandos zypper install und zypper remove zu adressieren.

Nach dem genauen Paketnamen
tux > sudo zypper install MozillaFirefox
Nach dem genauen Namen und der Versionsnummer des Pakets
tux > sudo zypper install MozillaFirefox-52.2
Nach dem Repository-Alias und dem Paketnamen
tux > sudo zypper install mozilla:MozillaFirefox

Dabei ist mozilla der Alias des Repositorys, aus dem installiert werden soll.

Nach dem Paketnamen mit Wildcards

Sie können alle Pakete mit Namen auswählen, die mit einer bestimmten Zeichenfolge anfangen oder enden. Verwenden Sie Platzhalter mit äußerster Umsicht, vor allem beim Entfernen von Paketen. Das folgende Kommando installiert alle Pakete, deren Name mit „Moz“ beginnt: 

tux > sudo zypper install 'Moz*'
Tipp
Tipp: Entfernen aller -debuginfo-Pakete

Beim Debuggen eines Problems müssen Sie unter Umständen zahlreiche -debuginfo-Pakete temporär installieren, mit denen Sie weitere Informationen zu den ausgeführten Prozessen erhalten. Nach Abschluss der Debugging-Sitzung bereinigen Sie die Umgebung wie folgt: 

tux > sudo zypper remove '*-debuginfo'
Nach Funktion

Wenn Sie beispielsweise ein Paket installieren möchten, ohne dessen Namen zu kennen, sind die Funktionen von Nutzen. Das folgende Kommando startet die Installation des Pakets MozillaFirefox: 

tux > sudo zypper install firefox
Nach Funktion, Hardware-Architektur oder Version

Zusammen mit einer Funktion können Sie eine Hardware-Architektur und eine Version angeben:

  • Der Name der gewünschten Hardware-Architektur wird nach einem Punkt an die Funktion angefügt. Um beispielsweise die AMD64-/Intel-64-Architekturen anzugeben (die in Zypper x86_64 heißen), verwenden Sie Folgendes: 

    tux > sudo zypper install 'firefox.x86_64'

  • Versionen müssen am Ende der Zeile angefügt werden und ein Operator muss vorangestellt sein: < (kleiner als), <= (kleiner oder gleich), = (gleich), >= (größer oder gleich), > (größer als). 

    tux > sudo zypper install 'firefox>=74.2'

  • Sie können auch eine Hardware-Architektur und eine Versionsanforderung kombinieren: 

    tux > sudo zypper install 'firefox.x86_64>=74.2'
Nach dem Pfad der RPM-Datei

Sie können einen lokalen oder entfernten Pfad zu einem Paket angeben: 

tux > sudo zypper install /tmp/install/MozillaFirefox.rpm
tux > sudo zypper install http://download.example.com/MozillaFirefox.rpm

6.1.3.2 Kombinieren der Installation und der Entfernung von Paketen

 

Zum gleichzeitigen Installieren und Entfernen von Paketen verwenden Sie die Modifikatoren +/-. Um emacs zu installieren und gleichzeitig vim zu entfernen, verwenden Sie Folgendes: 

tux > sudo zypper install emacs -vim

Um emacs zu entfernen und gleichzeitig vim zu installieren, verwenden Sie Folgendes: 

tux > sudo zypper remove emacs +vim

Um zu vermeiden, dass der mit - beginnende Paketname als Kommandooption interpretiert wird, verwenden Sie ihn stets als das zweite Argument. Falls dies nicht möglich ist, stellen Sie ihm -- voran: 

tux > sudo zypper install -emacs +vim       # Wrong
tux > sudo zypper install vim -emacs        # Correct
tux > sudo zypper install -- -emacs +vim    # Correct
tux > sudo zypper remove emacs +vim         # Correct

6.1.3.3 Bereinigen von Abhängigkeiten entfernter Pakete

 

Wenn (zusammen mit einem bestimmten Paket) automatisch alle Pakete entfernt werden sollen, die nach dem Entfernen dieses Pakets nicht mehr erforderlich sind, verwenden Sie die Option --clean-deps: 

tux > sudo zypper rm --clean-deps PACKAGE_NAME

6.1.3.4 Verwenden von Zypper in Skripten

 

Standardmäßig verlangt Zypper eine Bestätigung, bevor ein ausgewähltes Paket installiert oder entfernt wird oder wenn ein Problem auftritt. Mit der Option --non-interactive können Sie dieses Verhalten deaktivieren. Die Option muss jedoch vor dem tatsächlich auszuführenden Kommando (install, remove oder patch) angegeben werden, wie im Folgenden erkennbar: 

tux > sudo zypper --non-interactive install PACKAGE_NAME

Mit dieser Option kann Zypper auch in Skripten und Cron-Aufträgen verwendet werden.

6.1.3.5 Installieren oder Herunterladen von Quellpaketen

 

Wenn Sie das entsprechende Quellpaket eines Pakets installieren möchten, verwenden Sie: 

tux > zypper source-install PACKAGE_NAME

Wird das Kommando als root ausgeführt, ist der Standardspeicherort der Quellpakete /usr/src/packages/ und ~/rpmbuild, wenn es als Benutzer ausgeführt wird. Diese Werte können in Ihrer lokalen rpm-Konfiguration geändert werden.

Dieses Kommando installiert auch die Build-Abhängigkeiten des angegebenen Pakets. Wenn Sie dies nicht wünschen, fügen Sie den Schalter -D hinzu: 

tux > sudo zypper source-install -D PACKAGE_NAME

Um nur die Build-Abhängigkeiten zu installieren, verwenden Sie -d. 

tux > sudo zypper source-install -d PACKAGE_NAME

Natürlich gelingt dies nur, wenn das Repository mit den Quellpaketen in Ihrer Repository-Liste aktiviert ist (es wird standardmäßig hinzugefügt, aber nicht aktiviert). Details zur Repository-Verwaltung finden Sie unter Abschnitt 6.1.6, „Verwalten von Repositorys mit Zypper“.

Eine Liste aller Quellpakete, die in Ihren Repositorys verfügbar sind, können Sie wie folgt abrufen: 

tux > zypper search -t srcpackage

Wenn Sie möchten, können Sie die Quellpakete für alle installierten Pakete in ein lokales Verzeichnis herunterladen. Zum Herunterladen von Quellpaketen verwenden Sie: 

tux > zypper source-download

Das Standardverzeichnis für heruntergeladene Dateien lautet /var/cache/zypper/source-download. Mit der Option --directory können Sie dieses Verzeichnis ändern. Sollen nur fehlende oder überzählige Pakete angezeigt werden, ohne Pakete herunterzuladen oder zu löschen, verwenden Sie die Option --status. Zum Löschen überzähliger Pakete verwenden Sie die Option --delete. Soll das Löschen deaktiviert werden, verwenden Sie die Option --no-delete.

6.1.3.6 Installieren von Paketen aus deaktivierten Repositorys

 

In der Regel können Sie nur Pakete aus aktivierten Repositorys installieren oder aktualisieren. Mit der Option --plus-content TAG können Sie bestimmte Repositorys aktualisieren, temporär während der aktuellen Zypper-Sitzung aktivieren und nach Abschluss der Sitzung wieder deaktivieren.

Sollen beispielsweise Repositorys mit zusätzlichen -debuginfo- oder -debugsource-Paketen aktiviert werden, geben Sie --plus-content debug ein. Diese Option kann mehrfach angegeben werden.

Sollen diese „Debug“-Repositorys vorübergehend aktiviert werden, damit Sie ein bestimmtes -debuginfo-Paket installieren können, geben Sie die Option wie folgt an: 

tux > sudo zypper --plus-content debug \
   install "debuginfo(build-id)=eb844a5c20c70a59fc693cd1061f851fb7d046f4"

Die Zeichenkette build-id wird von gdb für fehlende debuginfo-Pakete zurückgegeben.

Anmerkung
Anmerkung: Deaktivierte Installationsmedien

Repositoys von den Installationsmedien von SUSE Linux Enterprise Server werden weiterhin konfiguriert, doch nach der erfolgreichen Installation deaktiviert. Sie können anstelle der Online-Repositorys die Option --plus-content verwenden, um Pakete von den Installationsmedien zu installieren. Stellen Sie vor dem Aufruf von zypper sicher, dass das Installationsmedium verfügbar ist. Legen Sie dazu beispielsweise die DVD im Laufwerk des Rechners ein.

6.1.3.7 Dienstprogramme

 

Wenn Sie prüfen möchten, ob alle Abhängigkeiten noch erfüllt sind, und fehlende Abhängigkeiten reparieren möchten, verwenden Sie: 

tux > zypper verify

Zusätzlich zu Abhängigkeiten, die erfüllt sein müssen, „empfehlen“ einige Pakete andere Pakete. Diese empfohlenen Pakete werden installiert, wenn sie aktuell verfügbar und installierbar sind. Falls empfohlene Pakete erst nach der Installation des empfehlenden Pakets (durch Hinzufügen zusätzlicher Pakete oder zusätzlicher Hardware) zur Verfügung steht, verwenden Sie das folgende Kommando: 

tux > sudo zypper install-new-recommends

Dieses Kommando ist nach dem Anschließen einer Webcam oder eines WLAN-Geräts äußerst nützlich. Hiermit werden Treiber für das Gerät und die zugehörige Software installiert, sofern verfügbar. Die Treiber und die zugehörige Software sind nur dann installierbar, wenn bestimmte Hardware-Abhängigkeiten erfüllt sind.

6.1.4 Aktualisieren von Software mit Zypper

 

Es gibt drei verschiedene Möglichkeiten, Software mithilfe von Zypper zu installieren: durch Installation von Patches, durch Installation einer neuen Version eines Pakets oder durch Aktualisieren der kompletten Distribution. Letzteres wird mit zypper dist-upgrade erreicht. Durchführen von Upgrades von SUSE Linux Enterprise Server wird im Book “Upgradehandbuch”, Chapter 1 “Upgrade-Pfade und -Methoden” erläutert.

6.1.4.1 Installieren aller erforderlichen Patches

 

Um alle offiziell herausgegebenen Patches für Ihr System zu installieren, führen Sie Folgendes aus: 

tux > sudo zypper patch

Alle verfügbaren Patches aus den auf Ihrem Computer konfigurierten Repositorys werden auf Relevanz für Ihre Installation überprüft. Sind sie relevant (und nicht als optional oder feature klassifiziert), werden sie sofort installiert. Beachten Sie, dass das offizielle Aktualisierungs-Repository erst verfügbar ist, nachdem Sie Ihre SUSE Linux Enterprise Server-Installation registriert haben.

Umfasst ein zu installierendes Patch Änderungen, die einen System-Reboot erfordern, werden Sie zuvor benachrichtigt.

Mit dem einfachen Befehl zypper patch werden keine Patches aus Drittanbieter-Repositorys angewendet. Sollen auch die Drittanbieter-Repositorys aktualisiert werden, geben Sie die Befehlsoption with-update wie folgt an: 

tux > sudo zypper patch --with-update

Um auch optionale Patches zu installieren, verwenden Sie Folgendes: 

tux > sudo zypper patch --with-optional

Um alle Patches zu installieren, die zu einem bestimmten Bugzilla-Problem gehören, verwenden Sie Folgendes: 

tux > sudo zypper patch --bugzilla=NUMBER

Um alle Patches zu installieren, die zu einem bestimmten CVE-Datenbankeintrag gehören, verwenden Sie Folgendes: 

tux > sudo zypper patch --cve=NUMBER

Zum Installieren eines Sicherheits-Patches mit der CVE-Nummer CVE-2010-2713 führen Sie beispielsweise Folgendes aus: 

tux > sudo zypper patch --cve=CVE-2010-2713

Um nur Patches zu installieren, die Auswirkungen auf Zypper und die Paketverwaltung an sich haben, verwenden Sie Folgendes: 

tux > sudo zypper patch --updatestack-only

Denken Sie daran, dass andere Befehlsoptionen, mit denen auch andere Repositorys aktualisiert würden, außer Acht gelassen werden, wenn Sie die Befehlsoption updatestack-only angeben.

6.1.4.2 Auflisten von Patches

 

Um herauszufinden, ob Patches verfügbar sind, erlaubt Zypper das Anzeigen der folgenden Informationen:

Anzahl der erforderlichen Patches

Um die Anzahl der erforderlichen Patches aufzulisten (Patches, die für Ihr System gelten, aber noch nicht installiert sind), verwenden Sie patch-check: 

tux > zypper patch-check
Loading repository data...
Reading installed packages...
5 patches needed (1 security patch)

Dieses Kommando kann mit der Option --updatestack-only kombiniert werden, um nur Patches aufzulisten, die Auswirkungen auf Zypper und die Paketverwaltung an sich haben.

Liste der erforderlichen Patches

Um alle erforderlichen Patches aufzulisten (Patches, die für Ihr System gelten, aber noch nicht installiert sind), verwenden Sie zypper list-patches.

Liste aller Patches

Um alle für SUSE Linux Enterprise Server verfügbaren Patches aufzulisten, unabhängig davon, ob sie bereits installiert sind oder für Ihre Installation gelten, verwenden Sie zypper patches.

Sie können auch Patches für bestimmte Probleme auflisten und installieren. Dazu geben Sie das Kommando zypper list-patches mit den folgenden Optionen ein:

Nach Bugzilla-Problemen

Um alle Patches mit Bezug zu Bugzilla-Problemen aufzulisten, verwenden Sie die Option --bugzilla.

Um Patches für einen bestimmten Fehler aufzulisten, können Sie auch eine Fehlernummer angeben: --bugzilla=NUMMER. Fügen Sie Kommas zwischen den Fehlernummern hinzu, um nach Patches mit Bezug zu mehreren Bugzilla-Problemen zu suchen, z. B.: 

tux > zypper list-patches --bugzilla=972197,956917
Nach CVE-Nummer

Um alle erforderlichen Patches aufzulisten, die Bezug zu einem Eintrag in der CVE-Datenbank (Common Vulnerabilities and Exposures) haben, verwenden Sie die Option --cve.

Um Patches für einen bestimmten CVE-Datenbankeintrag aufzulisten, können Sie auch eine CVE-Nummer angeben: --cve=NUMMER. Fügen Sie Kommas zwischen den CVE-Nummern hinzu, um nach Patches mit Bezug zu mehreren CVE-Datenbankeinträgen zu suchen, z. B.: 

tux > zypper list-patches --bugzilla=CVE-2016-2315,CVE-2016-2324

Um alle Patches aufzulisten, unabhängig davon, ob sie erforderlich sind, verwenden Sie zusätzlich die Option --all. Um beispielsweise alle Patches aufzulisten, denen eine CVE-Nummer zugewiesen ist, verwenden Sie Folgendes: 

tux > zypper list-patches --all --cve
Issue | No.           | Patch             | Category    | Severity  | Status
------+---------------+-------------------+-------------+-----------+----------
cve   | CVE-2019-0287 | SUSE-SLE-Module.. | recommended | moderate  | needed
cve   | CVE-2019-3566 | SUSE-SLE-SERVER.. | recommended | moderate  | not needed
[...]

6.1.4.3 Installieren neuer Paketversionen

 

Wenn ein Repository neue Pakete enthält, aber keine Patches zur Verfügung stellt, zeigt zypper patch keinerlei Wirkung. Zum Aktualisieren aller installierten Pakete mit verfügbaren neuen Versionen (unter Beibehaltung der Systemintegrität) verwenden Sie Folgendes: 

tux > sudo zypper update

Zum Aktualisieren einzelner Pakete geben Sie das Paket mit dem Aktualisierungs- oder Aktualisierungskommando an: 

tux > sudo zypper update PACKAGE_NAME
tux > sudo zypper install PACKAGE_NAME

Mit dem Kommando kann eine Liste mit allen neuen installierbaren Paketen abgerufen werden. 

tux > zypper list-updates

Dieses Kommando listet ausschließlich Pakete auf, die die folgenden Kriterien erfüllen:

  • stammt von demselben Hersteller wie das bereits installierte Paket,

  • umfasst Repositorys mit mindestens derselben Priorität wie das bereits installierte Paket,

  • ist installierbar (alle Abhängigkeiten wurden erfüllt).

Eine Liste aller neuen verfügbaren Pakete (unabhängig davon, ob diese Pakete installierbar sind oder nicht) erhalten Sie mit Folgendem: 

tux > sudo zypper list-updates --all

Um festzustellen, warum ein neues Paket nicht installiert werden kann, verwenden Sie das Kommando zypper install oder zypper update, wie oben beschrieben.

6.1.4.4 Ermitteln verwaister Pakete

 

Immer, wenn Sie ein Repository aus Zypper entfernen oder Ihr System aktualisieren, erhalten manche Pakete den Status „Verwaist“. Diese verwaisten Pakete gehören zu keinem aktiven Repository mehr. Mit dem folgenden Kommando erhalten Sie eine entsprechende Liste: 

tux > sudo zypper packages --orphaned

Anhand dieser Liste können Sie entscheiden, ob ein Paket noch benötigt wird oder sicher entfernt werden kann.

6.1.5 Ermitteln von Prozessen und Diensten, die gelöschte Dateien verwenden

 

Beim Anwenden von Patches, beim Aktualisieren oder beim Entfernen von Paketen können auf dem System Prozesse aktiv sein, die weiterhin Dateien verwenden, die durch die Aktualisierung oder das Entfernen gelöscht wurden. Verwenden Sie zypper ps, um Prozesse aufzulisten, die gelöschte Dateien verwenden. Falls der Prozess zu einem bekannten Dienst gehört, wird der Dienstname aufgelistet und der Dienst kann leicht neu gestartet werden. Standardmäßig zeigt zypper ps eine Tabelle an: 

tux > zypper ps
PID   | PPID | UID | User  | Command      | Service      | Files
------+------+-----+-------+--------------+--------------+-------------------
814   | 1    | 481 | avahi | avahi-daemon | avahi-daemon | /lib64/ld-2.19.s->
      |      |     |       |              |              | /lib64/libdl-2.1->
      |      |     |       |              |              | /lib64/libpthrea->
      |      |     |       |              |              | /lib64/libc-2.19->
[...]
PID: ID des Prozesses
PPID: ID des übergeordneten Prozesses
UID: ID des Benutzers, der den Prozess ausführt
Login: Anmeldename des Benutzers, der den Prozess ausführt
Command: Kommando, mit dem der Prozess ausgeführt wurde
Service: Dienstname (nur wenn das Kommando einem Systemdienst zugeordnet ist)
Files: Liste der gelöschten Dateien

Das Ausgabeformat von zypper ps kann wie folgt gesteuert werden:

zypper ps-s

Kurze Tabelle ohne gelöschte Dateien erstellen. 

tux > zypper ps -s
PID   | PPID | UID  | User    | Command      | Service
------+------+------+---------+--------------+--------------
814   | 1    | 481  | avahi   | avahi-daemon | avahi-daemon
817   | 1    | 0    | root    | irqbalance   | irqbalance
1567  | 1    | 0    | root    | sshd         | sshd
1761  | 1    | 0    | root    | master       | postfix
1764  | 1761 | 51   | postfix | pickup       | postfix
1765  | 1761 | 51   | postfix | qmgr         | postfix
2031  | 2027 | 1000 | tux     | bash         |
zypper ps-ss

Nur Prozesse anzeigen, die einem Systemdienst zugewiesen sind. 

PID   | PPID | UID  | User    | Command      | Service
------+------+------+---------+--------------+--------------
814   | 1    | 481  | avahi   | avahi-daemon | avahi-daemon
817   | 1    | 0    | root    | irqbalance   | irqbalance
1567  | 1    | 0    | root    | sshd         | sshd
1761  | 1    | 0    | root    | master       | postfix
1764  | 1761 | 51   | postfix | pickup       | postfix
1765  | 1761 | 51   | postfix | qmgr         | postfix
zypper ps-sss

Nur Systemdienste anzeigen, die gelöschte Dateien verwenden. 

avahi-daemon
irqbalance
postfix
sshd
zypper ps--print "systemctl status %s"

Kommandos zum Abrufen von Statusinformationen für Dienste anzeigen, die einen Neustart erfordern könnten. 

systemctl status avahi-daemon
systemctl status irqbalance
systemctl status postfix
systemctl status sshd

Weitere Informationen zum Handhaben von Diensten finden Sie unter Kapitel 15, Der Daemon systemd.

6.1.6 Verwalten von Repositorys mit Zypper

 

Sämtliche Installations- und Patch-Kommandos von Zypper sind von der Liste der bekannten Repositorys abhängig. Um alle dem System bekannten Repositorys aufzulisten, verwenden Sie das Kommando: 

tux > zypper repos

Das Ergebnis ist der folgenden Ausgabe ähnlich:

Beispiel 6.1: Zypper – Liste der bekannten Repositorys
 
tux > zypper repos
# | Alias        | Name          | Enabled | Refresh
--+--------------+---------------+---------+--------
1 | SLEHA-15-GEO | SLEHA-15-GEO  | Yes     | No
2 | SLEHA-15     | SLEHA-15      | Yes     | No
3 | SLES15       | SLES15        | Yes     | No

Bei der Angabe von Repositorys kann in verschiedenen Kommandos ein Alias, URI oder eine Repository-Nummber aus der Ausgabe des Kommandos zypper repos verwendet werden. Ein Repository-Alias ist eine Kurzform des Repository-Namens, der in Repository-Kommandos verwendet wird. Beachten Sie dabei, dass sich die Repository-Nummern nach dem Bearbeiten der Repository-Liste ändern können. Der Alias ändert sich nie von alleine.

Standardmäßig werden Details wie URI oder Priorität des Repositorys nicht angezeigt. Verwenden Sie das folgende Kommando, um alle Details aufzulisten: 

tux > zypper repos -d

6.1.6.1 Hinzufügen von Repositorys

 

Zum Hinzufügen eines Repository, führen Sie Folgendes aus: 

tux > sudo zypper addrepo URI ALIAS

URI kann ein Internet-Repository, eine Netzwerkressource, ein Verzeichnis oder eine CD oder DVD sein (für Details siehe https://en.opensuse.org/openSUSE:Libzypp_URIs). Der ALIAS ist ein Kürzel und eine eindeutige Kennung für das Repository. Sie können ihn frei wählen, vorausgesetzt, er ist eindeutig. Zypper gibt eine Warnung aus, wenn Sie einen Alias angeben, der bereits verwendet wird.

6.1.6.2 Aktualisieren von Repositorys

 

Mit Zypper können Sie Änderungen in Paketen aus konfigurierten Repositorys abrufen. Rufen Sie die Änderungen wie folgt ab: 

tux > sudo zypper refresh
Anmerkung
Anmerkung: Standardverhalten von zypper

Standardmäßig führen bestimmte Befehle refresh automatisch aus, sodass dieser Befehl nicht explizit aufgerufen werden muss.

Mit der Option --plus-content für refresh können Sie Änderungen auch in deaktivierten Repositorys abrufen: 

tux > sudo zypper --plus-content refresh

Diese Option ruft Änderungen in Repositorys ab und behält dabei den Zustand der deaktivierten Repositorys unverändert bei – also deaktiviert.

6.1.6.3 Entfernen von Repositorys

 

Wenn ein Repository von der Liste entfernt werden soll, verwenden Sie das Kommando zypper removerepo zusammen mit dem Alias oder der Nummer des zu löschenden Repositorys. Um beispielsweise das Repository SLEHA-12-GEO aus Beispiel 6.1, „Zypper – Liste der bekannten Repositorys“ zu entfernen, verwenden Sie eines der folgenden Kommandos: 

tux > sudo zypper removerepo 1
tux > sudo zypper removerepo "SLEHA-12-GEO"

6.1.6.4 Ändern von Repositorys

 

Aktivieren oder deaktivieren von Repositorys mit zypper modifyrepo. Mit diesem Kommando können Sie auch die Eigenschaften des Repositorys (z. B. Aktualisierungsverhalten, Name oder Priorität) ändern. Das folgende Kommando aktiviert das Repository mit dem Namen updates, aktiviert die automatische Aktualisierung und stellt seine Priorität auf 20 ein: 

tux > sudo zypper modifyrepo -er -p 20 'updates'

Das Ändern von Repositorys ist nicht auf ein einziges Repository beschränkt – Sie können auch Gruppen bearbeiten:

-a: alle Repositorys
-l: lokale Repositorys
-t: entfernte Repositorys
-m TYPE: Repositorys eines bestimmten Typs (wobei TYPE einer der folgenden sein kann: http, https, ftp, cd, dvd, dir, file, cifs, smb, nfs, hd, iso)

Zum Umbenennen eines Repository-Alias verwenden Sie das Kommando renamerepo. Das folgende Beispiel ändert den Alias von Mozilla Firefox in firefox: 

tux > sudo zypper renamerepo 'Mozilla Firefox' firefox

6.1.7 Abfragen von Repositorys und Paketen mit Zypper

 

Zypper bietet zahlreiche Methoden zur Abfrage von Repositorys oder Paketen. Verwenden Sie die folgenden Kommandos, um eine Liste aller verfügbaren Produkte, Muster, Pakete oder Patches zu erhalten: 

tux > zypper products
tux > zypper patterns
tux > zypper packages
tux > zypper patches

Zur Abfrage aller Repositorys auf bestimmte Pakete verwenden Sie search. Mit dem Befehl info erhalten Sie Informationen zu bestimmten Paketen.

6.1.7.2 Suchen nach Paketen in allen SLE-Modulen

 

Mit dem Unterkommando search-packages suchen Sie Pakete innerhalb und außerhalb der aktuell aktivierten SLE-Module. Mit diesem Kommando wird das SUSE Customer Center kontaktiert und alle Module werden nach passenden Paketen durchsucht, wie zum Beispiel: 

tux > zypper search-packages package1 package2

zypper search-packages bietet folgende Optionen:

  • Suchen nach einer genauen Übereinstimmung mit der Suchzeichenkette: -x, --match-exact

  • Gruppieren der Ergebnisse nach Modul (Standard: Nach Paket gruppieren): -g, --group-by-module

  • Anzeigen detaillierterer Informationen zu Paketen: -d, --details

  • Ausgeben von Suchergebnissen in XML: --xmlout

6.1.7.3 Suchen nach bestimmten Funktionen

 

Verwenden Sie zur Suche nach Paketen, die eine spezielle Funktion bieten, das Kommando what-provides. Wenn Sie beispielsweise wissen möchten, welches Paket das Perl-Modul SVN::Core bereitstellt, verwenden Sie das folgende Kommando: 

tux > zypper what-provides 'perl(SVN::Core)'

what-provides -PAKETNAME ähnelt dem Befehl rpm -q --whatprovides PAKETNAME; RPM kann jedoch nur Abfragen für die RPM-Datenbank (Datenbank mit allen installierten Paketen) durchführen. zypper informiert Sie auf der anderen Seite über Anbieter der Möglichkeit von einem beliebigen Repository, nicht nur von denen, die installiert sind.

6.1.7.4 Anzeigen von Paketinformationen

 

Um einzelne Pakete abzufragen, verwenden Sie info mit einem exakten Paketnamen als Argument. Hiermit werden detaillierte Informationen zu einem Paket angezeigt. Falls der Paketname nicht mit einem Paketnamen aus den Repositorys übereinstimmt, gibt der Befehl ausführliche Informationen zu den fehlenden Pakettreffern aus. Wenn Sie einen bestimmten Typ festlegen (mit der Option -t) und dieser Typ nicht vorhanden ist, gibt der Befehl andere verfügbare Treffer aus, jedoch ohne ausführliche Informationen.

Wenn Sie ein Quellpaket angeben, zeigt der Befehl die aus dem Quellpaket aufgebauten Binärpakete. Wenn Sie ein Binärpaket angeben, gibt der Befehl die Quellpakete aus, aus denen das Binärpaket aufgebaut wurde.

Um auch die Elemente abzurufen, die für das Paket erforderlich/empfohlen sind, verwenden Sie die Optionen --requires und --recommends: 

tux > zypper info --requires MozillaFirefox

6.1.8 Anzeigen von Paketinformationen

 

SUSE-Produkte werden im Allgemeinen 10 Jahre lang unterstützt. Häufig können Sie diesen standardmäßigen Lebenszyklus anhand der erweiterten Supportangebote von SUSE verlängern und drei Jahre Support erhalten. Den genauen Support-Lebenszyklus für Ihr Produkt finden Sie unter https://www.suse.com/lifecycle.

Mit dem Kommando zypper lifecycle ermitteln Sie den Lebenszyklus Ihres Produkts und des unterstützten Pakets (siehe unten): 

root # zypper lifecycle
    Product end of support
Codestream: SUSE Linux Enterprise Server 15             2028-07-31
    Product: SUSE Linux Enterprise Server 15 SP3        n/a*

Module end of support
Basesystem Module                                       n/a*
Desktop Applications Module                             n/a*
Server Applications Module                              n/a*

Package end of support if different from product:
autofs                                   Now, installed 5.1.3-7.3.1, update available 5.1.3-7.6.1

6.1.9 Konfigurieren von Zypper

 

Zypper ist nunmehr mit einer Konfigurationsdatei ausgestattet, in der Sie die Arbeitsweise von Zypper dauerhaft verändern können (wahlweise systemweit oder benutzerspezifisch). Für systemweite Änderungen bearbeiten Sie /etc/zypp/zypper.conf. Für benutzerspezifische Änderungen bearbeiten Sie ~/.zypper.conf. Falls ~/.zypper.conf noch nicht vorhanden ist, können Sie /etc/zypp/zypper.conf als Schablone verwenden. Kopieren Sie diese Datei in ~/.zypper.conf, und passen Sie sie nach Ihren Anforderungen an. Weitere Informationen zu den verfügbaren Optionen finden Sie in den Kommentaren in der Datei.

6.1.10 Fehlersuche

 

Falls Sie aus konfigurierten Repositorys heraus nicht problemlos auf Pakete zugreifen können (Zypper kann beispielsweise ein bestimmtes Paket nicht finden, obwohl Sie wissen, dass sich dieses Paket in einem der Repositorys befindet), aktualisieren Sie probeweise die Repositorys: 

tux > sudo zypper refresh

Falls das nicht wirkt, probieren Sie Folgendes: 

tux > sudo zypper refresh -fdb

Damit wird eine vollständige Aktualisierung und ein kompletter Neuaufbau der Datenbank erzwungen, außerdem ein erzwungener Download von Roh-Metadaten.

6.1.11 Zypper-Rollback-Funktion im Btrfs-Dateisystem

 

Wenn das Btrfs-Dateisystem in der Stammpartition verwendet wird und installiert ist, ruft Zypper automatisch Snapper auf, wenn an das Dateisystem Änderungen übermittelt werden, um entsprechende Dateisystem-Snapshots zu erstellen. Diese Snapshots können verwendet werden, um alle durch Zypper vorgenommenen Änderungen rückgängig zu machen. Weitere Informationen zu diesem Thema finden Sie unter dem Stichwort Kapitel 7, Systemwiederherstellung und Snapshot-Verwaltung mit Snapper.

6.1.12 Weitere Informationen

 

Wenn Sie weitere Informationen zur Verwaltung von Software benötigen, geben Sie den Befehl zypper help, zypper help BEFEHL in die Befehlszeile ein oder rufen Sie die man-Seite zypper(8) auf. Eine ausführliche Kommandoreferenz mit Tricks zu den wichtigsten Kommandos sowie Informationen zur Verwendung von Zypper in Skripten und Anwendungen finden Sie unter https://en.opensuse.org/SDB:Zypper_usage. Eine Liste der Software-Änderungen in der aktuellen SUSE Linux Enterprise Server-Version finden Sie unter https://en.opensuse.org/openSUSE:Zypper_versions.

6.2 RPM – der Paket-Manager

 

RPM (RPM Package Manager) wird für die Verwaltung von Softwarepaketen verwendet. Seine Hauptbefehle lauten rpm und rpmbuild. In der leistungsstarken RPM-Datenbank können Benutzer, Systemadministratoren und Paketersteller ausführliche Informationen zur installierten Software abfragen.

rpm hat fünf Modi: Installieren/Deinstallieren (oder Aktualisieren) von Software-Paketen, Neuaufbauen der RPM-Datenbank, Abfragen der RPM-Basis oder individuellen RPM-Archive, Integritätsprüfung der Pakete und Signieren von Paketen. rpmbuild ermöglicht das Aufbauen installierbarer Pakete von Pristine-Quellen.

Installierbare RPM-Archive sind in einem speziellen binären Format gepackt. Diese Archive bestehen aus den zu installierenden Programmdateien und aus verschiedenen Metadaten, die bei der Installation von rpm benutzt werden, um das jeweilige Softwarepaket zu konfigurieren, oder die zu Dokumentationszwecken in der RPM-Datenbank gespeichert werden. RPM-Archive haben für gewöhnlich die Dateinamenserweiterung .rpm.

Tipp
Tipp: Pakete zur Software-Entwicklung

Für mehrere Pakete wurden die erforderlichen Komponenten für die Software-Entwicklung (Bibliotheken, Header, Include-Dateien usw.) in separate Pakete verpackt. Diese Entwicklungspakete werden nur benötigt, wenn Sie Software selbst kompilieren möchten (beispielsweise die neuesten GNOME-Pakete). Solche Pakete sind am Namenszusatz -devel zu erkennen, z. B. die Pakete alsa-devel und gimp-devel.

6.2.1 Prüfen der Authentizität eines Pakets

 

RPM-Pakete sind mit GPG signiert. Verwenden Sie zum Verifizieren der Signatur eines RPM-Pakets das Kommando rpm --checksig  PACKAGE-1.2.3.rpm. So können Sie feststellen, ob das Paket von SUSE oder einer anderen verbürgten Einrichtung stammt. Dies ist insbesondere bei Update-Paketen aus dem Internet zu empfehlen.

Zum Beheben von Problemen im Betriebssystem müssen Sie ggf. einen PTF (Problem Temporary Fix, temporäre Fehlerbehebung) in einem Produktionssystem installieren. Die Pakete von SUSE sind mit einem besonderen PTF-Schlüssel signiert. Im Gegensatz zu SUSE Linux Enterprise 11 wird dieser Schlüssel jedoch nicht standardmäßig von SUSE Linux Enterprise 12-Systemen importiert. Importieren Sie den Schlüssel mit dem folgenden Befehl: 

tux > sudo rpm --import \
/usr/share/doc/packages/suse-build-key/suse_ptf_key.asc

Nach dem Importieren des Schlüssels können Sie PTF-Pakete auf dem System installieren.

6.2.2 Verwalten von Paketen: Installieren, Aktualisieren und Deinstallieren

 

In der Regel kann ein RPM-Archiv einfach installiert werden: rpm -i PACKAGE.rpm. Mit diesem Kommando wird das Paket aber nur dann installiert, wenn seine Abhängigkeiten erfüllt sind und keine Konflikte mit anderen Paketen bestehen. rpmfordert per Fehlermeldung die Pakete an, die zum Erfüllen der Abhängigkeiten installiert werden müssen. Im Hintergrund wacht die RPM-Datenbank darüber, dass keine Konflikte entstehen: Eine spezifische Datei darf nur zu einem Paket gehören. Durch die Wahl anderer Optionen können Sie rpm zwingen, diese Standards zu ignorieren, jedoch ist dies nur für Spezialisten gedacht. Andernfalls wird damit die Integrität des Systems gefährdet und möglicherweise die Update-Fähigkeit aufs Spiel gesetzt.

Die Optionen -U oder --upgrade und -F oder --freshen können für das Update eines Pakets benutzt werden (z. B.: rpm -F PAKET.rpm). Dieser Befehl entfernt die Dateien der alten Version und installiert sofort die neuen Dateien. Der Unterschied zwischen den beiden Versionen besteht darin, dass mit -U auch Pakete installiert werden, die vorher nicht im System vorhanden waren, wohingegen mit -F nur zuvor installierte Pakete aktualisiert werden. Bei einem Update verwendet rpm zur sorgfältigen Aktualisierung der Konfigurationsdateien die folgende Strategie:

  • Falls eine Konfigurationsdatei vom Systemadministrator nicht geändert wurde, installiert rpm die neue Version der entsprechenden Datei. Es sind keine Eingriffe seitens des Administrators nötig.

  • Wenn der Systemadministrator eine Konfigurationsdatei vor der Aktualisierung geändert hatte, speichert rpm die geänderte Datei mit der Dateinamenerweiterung .rpmorig oder .rpmsave (Sicherungsdatei) und installiert die Version des neuen Pakets. Dies gilt nur dann, wenn die ursprünglich installierte Datei und die neuere Version nicht identisch sind. Vergleichen Sie in diesem Fall die Sicherungsdatei (.rpmorig oder .rpmsave) mit der neu installierten Datei und nehmen Sie Ihre Änderungen erneut in der neuen Datei vor. Löschen Sie anschließend alle .rpmorig- und .rpmsave-Dateien, um Probleme mit zukünftigen Updates zu vermeiden.

  • .rpmnew-Dateien erscheinen immer dann, wenn die Konfigurationsdatei bereits existiert und wenn die Kennung noreplace mit der .spec-Datei angegeben wurde.

Im Anschluss an ein Update sollten alle .rpmsave- und .rpmnew-Dateien nach einem Abgleich entfernt werden, damit sie bei zukünftigen Updates nicht stören. Die Erweiterung .rpmorig wird zugewiesen, wenn die Datei zuvor nicht von der RPM-Datenbank erkannt wurde.

Andernfalls wird .rpmsave verwendet. Mit anderen Worten: .rpmorig entsteht bei einem Update von einem Fremdformat auf RPM. .rpmsave entsteht bei einem Update aus einem älteren RPM auf einen neueren RPM. .rpmnew informiert nicht darüber, ob der Systemadministrator die Konfigurationsdatei geändert hat. Eine Liste all dieser Dateien ist in /var/adm/rpmconfigcheck verfügbar. Einige Konfigurationsdateien (wie /etc/httpd/httpd.conf) werden nicht überschrieben, um den weiteren Betrieb zu ermöglichen.

Der Schalter -U ist nicht einfach gleichbedeutend mit der Deinstallation mit der Option -e und der Installation mit der Option -i. Verwenden Sie -U, wann immer möglich.

Zum Entfernen eines Pakets geben Sie rpm -e PAKET ein. Dieses Kommando löscht das Paket nur, wenn keine ungelösten Abhängigkeiten vorhanden sind. Theoretisch ist es unmöglich, beispielsweise Tcl/Tk zu löschen, solange eine andere Anwendung Tcl/Tk noch benötigt. Auch in diesem Fall nutzt RPM die Datenbank zur Unterstützung. Falls in einem Ausnahmefall ein solcher Löschvorgang nicht möglich ist (selbst wenn keine Abhängigkeiten mehr bestehen), kann es nützlich sein, die RPM-Datenbank mit der Option --rebuilddb neu aufzubauen.

6.2.3 Delta-RPM-Pakete

 

Delta-RPM-Pakete enthalten die Unterschiede zwischen einer alten und einer neuen Version eines RPM-Pakets. Wenn Sie ein Delta-RPM auf ein altes RPM anwenden, ergibt dies ein ganz neues RPM. Es ist nicht erforderlich, dass eine Kopie des alten RPM vorhanden ist, da ein Delta-RPM auch mit einem installierten RPM arbeiten kann. Die Delta-RPM-Pakete sind sogar kleiner als Patch-RPMs, was beim Übertragen von Update-Paketen über das Internet von Vorteil ist. Der Nachteil ist, dass Update-Vorgänge mit Delta-RPMs erheblich mehr CPU-Zyklen beanspruchen als normale oder Patch-RPMs.

Die Binärdateien makedeltarpm und applydelta sind Teil der Delta-RPM-Suite (Paket deltarpm) und helfen Ihnen beim Erstellen und Anwenden von Delta-RPM-Paketen. Mit den folgenden Befehlen erstellen Sie ein Delta-RPM mit dem Namen new.delta.rpm. Der folgende Befehl setzt voraus, dass old.rpm und new.rpm vorhanden sind: 

tux > sudo makedeltarpm old.rpm new.rpm new.delta.rpm

Mit applydeltarpm können Sie den neuen RPM aus dem Dateisystem rekonstruieren, wenn das alte Paket bereits installiert ist: 

tux > sudo applydeltarpm new.delta.rpm new.rpm

Um es aus dem alten RPM abzuleiten, ohne auf das Dateisystem zuzugreifen, verwenden Sie die Option -r: 

tux > sudo applydeltarpm -r old.rpm new.delta.rpm new.rpm

Technische Details finden Sie in /usr/share/doc/packages/deltarpm/README.

6.2.4 RPM Abfragen

 

Mit der Option -q initiiert rpm Abfragen und ermöglicht es, ein RPM-Archiv zu prüfen (durch Hinzufügen der Option -p) und die RPM-Datenbank nach installierten Paketen abzufragen. Zur Angabe der benötigten Informationsart stehen mehrere Schalter zur Verfügung. Siehe Tabelle 6.1, „Wichtige Optionen für RPM-Abfragen“.

Tabelle 6.1: Wichtige Optionen für RPM-Abfragen
 

-i

Paketinformation

-l

Dateiliste

-f FILE

Abfrage nach Paket, das die Datei FILE enthält. (FILE muss mit dem vollständigen Pfad angegeben werden.)

-s

Dateiliste mit Statusinformation (impliziert -l)

-d

Nur Dokumentationsdateien auflisten (impliziert -l)

-c

Nur Konfigurationsdateien auflisten (impliziert -l)

--dump

Dateiliste mit vollständigen Details (mit -l, -c oder -d benutzen)

--provides

Funktionen des Pakets auflisten, die ein anderes Paket mit --requires anfordern kann

--requires, -R

Fähigkeiten, die das Paket benötigt

--Skripten

Installationsskripten (preinstall, postinstall, uninstall)

Beispielsweise gibt der Befehl rpm -q -i wget die in Beispiel 6.2, „rpm -q -i wget“ gezeigte Information aus.

Beispiel 6.2: rpm -q -i wget
 
Name        : wget
Version     : 1.14
Release     : 17.1
Architecture: x86_64
Install Date: Mon 30 Jan 2017 14:01:29 CET
Group       : Productivity/Networking/Web/Utilities
Size        : 2046483
License     : GPL-3.0+
Signature   : RSA/SHA256, Thu 08 Dec 2016 07:48:44 CET, Key ID 70af9e8139db7c82
Source RPM  : wget-1.14-17.1.src.rpm
Build Date  : Thu 08 Dec 2016 07:48:34 CET
Build Host  : sheep09
Relocations : (not relocatable)
Packager    : https://www.suse.com/
Vendor      : SUSE LLC <https://www.suse.com/>
URL         : http://www.gnu.org/software/wget/
Summary     : A Tool for Mirroring FTP and HTTP Servers
Description :
Wget enables you to retrieve WWW documents or FTP files from a server.
This can be done in script files or via the command line.
Distribution: SUSE Linux Enterprise 15

Die Option -f funktioniert nur, wenn Sie den kompletten Dateinamen mit dem vollständigen Pfad angeben. Sie können beliebig viele Dateinamen angeben. Beispiel: 

tux > rpm -q -f /bin/rpm /usr/bin/wget
rpm-4.14.1-lp151.13.10.x86_64
wget-1.19.5-lp151.4.1.x86_64

Wenn nur ein Teil des Dateinamens bekannt ist, verwenden Sie ein Shell-Skript, wie in Beispiel 6.3, „Skript für die Suche nach Paketen“ gezeigt. Übergeben Sie den partiellen Dateinamen als Parameter beim Aufruf des Skripts.

Der Befehl rpm -q --changelog PAKET zeigt eine detaillierte Liste der Änderungsinformation zu einem bestimmten Paket nach Datum sortiert.

Mit der installierten RPM-Datenbank sind Überprüfungen möglich. Initiieren Sie sie mit -V oder --verify. Mit dieser Option zeigt rpm alle Dateien in einem Paket, die seit der Installation geändert wurden. rpm weist mithilfe von acht Zeichensymbolen auf folgende Änderungen hin:

Tabelle 6.2: RPM-Überprüfungsoptionen
 

5

MD5-Prüfsumme

S

Dateigröße

L

Symbolischer Link

T

Änderungszeit

D

Major- und Minor-Gerätenummern

U

Besitzer

G

Gruppe

M

Modus (Berechtigungen und Dateityp)

Bei Konfigurationsdateien wird der Buchstabe c ausgegeben. Beispielsweise für Änderungen an /etc/wgetrc (wget-Paket): 

tux > rpm -V wget
S.5....T c /etc/wgetrc

Die Dateien der RPM-Datenbank werden in /var/lib/rpm abgelegt. Wenn die Partition /usr eine Größe von 1 GB aufweist, kann diese Datenbank beinahe 30 MB belegen, insbesondere nach einem kompletten Update. Wenn die Datenbank viel größer ist als erwartet, kann es nützlich sein, die Datenbank mit der Option --rebuilddb neu zu erstellen. Legen Sie zuvor eine Sicherungskopie der alten Datenbank an. Das cron-Skript cron.daily legt täglich (mit gzip gepackte) Kopien der Datenbank an und speichert diese unter /var/adm/backup/rpmdb. Die Anzahl der Kopien wird durch die Variable MAX_RPMDB_BACKUPS (Standard: 5) in /etc/sysconfig/backup gesteuert. Die Größe einer einzelnen Sicherungskopie beträgt ungefähr 1 MB für 1 GB in /usr.

6.2.5 Installieren und Kompilieren von Quellpaketen

 

Alle Quellpakete haben die Erweiterung .src.rpm (Source-RPM).

Anmerkung
Anmerkung: Installierte Quellpakete

Quellpakete können vom Installationsmedium auf die Festplatte kopiert und mit YaST entpackt werden. Sie werden im Paket-Manager jedoch nicht als installiert ([i]) gekennzeichnet. Das liegt daran, dass die Quellpakete nicht in der RPM-Datenbank eingetragen sind. Nur installierte Betriebssystemsoftware wird in der RPM-Datenbank aufgeführt. Wenn Sie ein Quellpaket „installieren“, wird dem System nur der Quellcode hinzugefügt.

Die folgenden Verzeichnisse müssen für rpm und rpmbuild in /usr/src/packages vorhanden sein (es sei denn, Sie haben spezielle Einstellungen in einer Datei, wie /etc/rpmrc, festgelegt):

SOURCES

für die Originalquellen (.tar.bz2- oder .tar.gz-Dateien usw.) und für distributionsspezifische Dokumente (hauptsächlich .diff- oder .patch-Dateien)

SPECS

für die .spec-Dateien, die ähnlich wie Meta-Makefiles den build-Prozess steuern

BUILD

Alle Quellen in diesem Verzeichnis werden entpackt, gepatcht und kompiliert.

RPMS

Speicherort der fertigen Binärpakete

SRPMS

Speicherort der Quell-RPMs

Wenn Sie ein Quellpaket mit YaST installieren, werden alle notwendigen Komponenten in /usr/src/packages installiert: die Quellen und Anpassungen in SOURCES und die relevanten .spec-Dateien in SPECS.

Warnung
Warnung: Systemintegrität

Experimentieren Sie nicht mit Systemkomponenten (glibc, rpm usw.), da Sie damit die Stabilität Ihres Systems riskieren.

Das folgende Beispiel verwendet das wget.src.rpm-Paket. Nach der Installation des Quellpakets sollten Dateien wie in der folgenden Liste vorhanden sein: 

/usr/src/packages/SOURCES/wget-1.19.5.tar.bz2
/usr/src/packages/SOURCES/wgetrc.patch
/usr/src/packages/SPECS/wget.spec

Mit rpmbuild -bX /usr/src/packages/SPECS/wget.spec wird die Kompilierung gestartet. X ist ein Platzhalter für verschiedene Stufen des build-Prozesses (Einzelheiten siehe in --help oder der RPM-Dokumentation). Nachfolgend wird nur eine kurze Erläuterung gegeben:

-bp

Bereiten Sie Quellen in /usr/src/packages/BUILD vor: entpacken und patchen.

-bc

Wie -bp, jedoch zusätzlich kompilieren.

-bi

Wie -bp, jedoch zusätzlich die erstellte Software installieren. Vorsicht: Wenn das Paket die Funktion Buildroot nicht unterstützt, ist es möglich, dass Konfigurationsdateien überschrieben werden.

-bb

Wie -bi, jedoch zusätzlich das Binärpaket erstellen. Nach erfolgreicher Kompilierung sollte das Binärpaket in /usr/src/packages/RPMS sein.

-ba

Wie -bb, jedoch zusätzlich den Quell-RPM erstellen. Nach erfolgreicher Kompilierung sollte dieses in /usr/src/packages/RPMS liegen.

--short-circuit

Einige Schritte überspringen.

Der erstellte Binär-RPM kann nun mit rpm -i oder vorzugsweise mit rpm -U erstellt werden. Durch die Installation mit rpm wird er in die RPM-Datenbank aufgenommen.

Denken Sie daran, dass die Buildroot-Direktive in der spec-Datei nicht mehr verwendet wird. Benötigen Sie die Funktion weiterhin, verwenden Sie die Option --buildroot als Alternative.

6.2.6 Kompilieren von RPM-Pakten mit „build“

 

Bei vielen Paketen besteht die Gefahr, dass während der Erstellung ungewollt Dateien in das laufende System kopiert werden. Um dies zu vermeiden, können Sie build verwenden, das eine definierte Umgebung herstellt, in der das Paket erstellt wird. Zum Aufbau dieser chroot-Umgebung muss dem build-Skript ein kompletter Paketbaum zur Verfügung stehen. Dieser kann auf Festplatte, über NFS oder auch von DVD bereitgestellt werden. Legen Sie die Position mit build --rpms VERZEICHNIS fest. Im Unterschied zu rpm sucht das Kommando build die -spec-Datei im Quellverzeichnis. Wenn Sie, wie im obigen Beispiel, wget neu erstellen möchten und die DVD unter /media/dvd im System eingehängt ist, verwenden Sie als Benutzer root folgende Kommandos: 

root # cd /usr/src/packages/SOURCES/
root # mv ../SPECS/wget.spec .
root # build --rpms /media/dvd/suse/ wget.spec

Anschließend wird in /var/tmp/build-root eine minimale Umgebung eingerichtet. Das Paket wird in dieser Umgebung erstellt. Danach befinden sich die resultierenden Pakete in /var/tmp/build-root/usr/src/packages/RPMS.

Das Skript build bietet mehrere zusätzliche Optionen. Beispielsweise können Sie das Skript veranlassen, Ihre eigenen RPMs bevorzugt zu verwenden, die Initialisierung der build-Umgebung auszulassen oder das Kommando rpm auf eine der oben erwähnten Stufen zu beschränken. Weitere Informationen erhalten Sie über build --help oder die man-Seite build.

6.2.7 Werkzeuge für RPM-Archive und die RPM-Datenbank

 

Midnight Commander (mc) kann den Inhalt von RPM-Archiven anzeigen und Teile daraus kopieren. Archive werden als virtuelle Dateisysteme dargestellt und bieten alle üblichen Menüoptionen von Midnight Commander. Zeigen Sie den HEADER mit F3 an. Zeigen Sie die Archivstruktur mit den Cursortasten und der Eingabetaste an. Kopieren Sie Archivkomponenten mit F5.

Ein Paket-Manager mit allen Funktionen ist als YaST-Modul verfügbar. Weitere Informationen finden Sie unter Book “Bereitstellungshandbuch”, Chapter 21 “Installieren bzw. Entfernen von Software”.

7 Systemwiederherstellung und Snapshot-Verwaltung mit Snapper

 

Mit Snapper werden Dateisystem-Snapshots erstellt und verwaltet. Durch Dateisystem-Snapshots kann eine Kopie des Zustands eines Dateisystems zu einem bestimmten Zeitpunkt beibehalten werden. Die Standardeinrichtung von Snapper lässt ein Rollback von Systemänderungen zu. Sie können es jedoch auch zum Erstellen von Sicherungen der Benutzerdaten auf Wechseldatenträgern verwenden. Als Basis für diese Funktion verwendet Snapper das Btrfs-Dateisystem oder LVM-Volumes mit Thin Provisioning mit einem XFS- oder Ext4-Dateisystem.

Snapper verfügt über eine Kommandozeilen-Schnittstelle und eine YaST-Schnittstelle. Mit Snapper können Sie Dateisystem-Snapshots zu den folgenden Dateisystemtypen erstellen und verwalten:

  • Btrfs, ein Kopie-beim-Schreiben-Betriebssystem für Linux, das nativ Dateisystem-Snapshots von Subvolumes unterstützt. (Subvolumes sind separat einhängbare Dateisysteme in einer physischen Partition.)

    Sie können auch von Btrfs-Snapshots booten. Weitere Informationen finden Sie im Abschnitt 7.3, „System-Rollback durch Booten aus Snapshots“.

  • LVM-Volumes mit Thin Provisioning formatiert mit XFS oder Ext4.

Mit Snapper können die folgenden Aufgaben ausgeführt werden:

7.1 Standardeinrichtung

 

Snapper unter SUSE Linux Enterprise Server wird als Werkzeug zum Rückgängigmachen und Wiederherstellen von Systemänderungen eingerichtet. Standardmäßig ist die Root-Partition (/) von SUSE Linux Enterprise Server mit Btrfs formatiert. Das Erstellen von Snapshots wird automatisch aktiviert, wenn die Root-Partition (/) groß genug ist (mehr als ca. 16 GB). Snapshots auf anderen Partitionen als / werden standardmäßig deaktiviert.

Tipp
Tipp: Aktivieren von Snapper im installierten System

Wenn Sie Snapper während der Installation deaktiviert haben, können Sie dieses Werkzeug später jederzeit wieder aktivieren. Erstellen Sie hierzu eine Snapper-Standardkonfiguration für das root-Dateisystem mit: 

tux > sudo snapper -c root create-config /

Aktivieren Sie dann die verschiedenen Snapshot-Typen gemäß den Anweisungen unter Abschnitt 7.1.4.1, „Deaktivieren/Aktivieren von Snapshots“.

Bei einem Btrfs-root-Dateisystem muss für Snapshots ein Dateisystem mit Subvolumes eingerichtet sein, wie vom Installationsprogramm vorgeschlagen. Die Partition muss zudem mindestens 16 GB groß sein.

Beim Erstellen eines Snapshots verweisen sowohl der Snapshot als auch das Original auf dieselben Blöcke im Dateisystem. Zunächst belegt ein Snapshot also keinen zusätzlichen Speicherplatz auf der Festplatte. Werden Daten im Original-Dateisystem bearbeitet, so werden die geänderten Datenblöcke kopiert, und die alten Datenblöcke werden im Snapshot beibehalten. Der Snapshot belegt daher dieselbe Speicherplatzmenge wie die geänderten Daten. Im Lauf der Zeit wächst der Speicherplatzbedarf eines Snapshots somit an. Wenn Sie also Dateien aus einem Btrfs-Dateisystem löschen, auf dem sich Snapshots befinden, wird unter Umständen kein Speicherplatz freigegeben!

Anmerkung
Anmerkung: Position der Snapshots

Snapshots befinden sich stets auf der Partition oder dem Subvolume, auf dem der Snapshot aufgenommen wurde. Es ist nicht möglich, einen Snapshot auf einer anderen Partition oder einem anderen Subvolume zu speichern.

Folglich müssen Partitionen mit Snapshots größer sein als Partitionen ohne Snapshots. Die genaue Speichermenge ist dabei stark abhängig von der Anzahl der Snapshots und vom Umfang der Änderungen an den Daten. Als Faustregel sollten Sie für diese Partitionen doppelt so viel Speicherplatz vorsehen wie normalerweise. Um zu verhindern, dass es zu wenig Speicherplatz gibt, werden alte Snapshots automatisch bereinigt. Weitere Informationen finden Sie unter Abschnitt 7.1.4.4, „Steuern der Snapshot-Archivierung“.

7.1.1 Standardeinstellungen

 
Festplatten größer als 16 GB

  • Konfigurationsdatei: /etc/snapper/configs/root

  • USE_SNAPPER=yes

  • TIMELINE_CREATE=no

Festplatten kleiner als 16 GB

  • Konfigurationsdatei: nicht erstellt

  • USE_SNAPPER=no

  • TIMELINE_CREATE=yes

7.1.2 Typen von Snapshots

 

Die Snapshots an sich unterscheiden sich streng genommen nicht voneinander, werden allerdings dennoch gemäß den Ereignissen, die sie ausgelöst haben, in drei Snapshot-Typen gegliedert:

Zeitleisten-Snapshots

In Abständen von einer Stunde wird ein einzelner Snapshot erstellt. Alte Snapshots werden automatisch gelöscht. Standardmäßig wird der erste Snapshot der letzten zehn Tage, Monate und Jahre beibehalten. Zeitleisten-Snapshots sind standardmäßig deaktiviert.

Installations-Snapshots

Wenn Sie ein oder mehrere Pakete mit YaST oder zypper installieren, wird ein Snapshot-Paar erstellt: ein Snapshot vor Beginn der Installation („Pre“) und ein zweiter Snapshot nach Abschluss der Installation („Post“). Wird eine wichtige Systemkomponente installiert (z. B. der Kernel), wird das Snapshot-Paar als wichtig gekennzeichnet (important=yes). Alte Snapshots werden automatisch gelöscht. Standardmäßig werden die letzten zehn wichtigen Snapshots und die letzten zehn „normalen“ Snapshots (auch Verwaltungs-Snapshots) beibehalten. Installations-Snapshots sind standardmäßig aktiviert.

Verwaltungs-Snapshots

Wenn Sie die Verwaltung eines Systems mit YaST vornehmen, wird ein Snapshot-Paar erstellt: ein Snapshot beim Starten eines YaST-Moduls („Pre“) und ein zweiter Snapshot beim Schließen des Moduls („Post“). Alte Snapshots werden automatisch gelöscht. Standardmäßig werden die letzten zehn wichtigen Snapshots und die letzten zehn „normalen“ Snapshots (auch Installations-Snapshots) beibehalten. Verwaltungs-Snapshots sind standardmäßig aktiviert.

7.1.3 Verzeichnisse, die aus Snapshots ausgenommen sind

 

Bestimmte Verzeichnisse müssen aus verschiedenen Gründen aus den Snapshots ausgenommen werden. Die folgende Liste zeigt alle ausgeschlossenen Verzeichnisse:

/boot/grub2/i386-pc, /boot/grub2/x86_64-efi, /boot/grub2/powerpc-ieee1275, /boot/grub2/s390x-emu

Ein Rollback der Bootloader-Konfiguration wird nicht unterstützt. Die obigen Verzeichnisse sind abhängig von der Architektur. Die ersten beiden Verzeichnisse gelten für AMD64-/Intel 64-Computer und die letzten beiden Verzeichnisse für IBM POWER bzw. für IBM Z.

/home

Wenn /home sich nicht auf einer separaten Partition befindet, wird dieses Verzeichnis ausgeschlossen, damit bei einem Rollback kein Datenverlust eintritt.

/opt

Produkte von Drittanbietern werden in der Regel in /opt installiert. Dieses Verzeichnis wird ausgeschlossen, damit die betreffenden Anwendungen bei einem Rollback nicht deinstalliert werden.

/srv

Enthält Daten für Web- und FTP-Server. Ausgeschlossen, damit bei einem Rollback kein Datenverlust eintritt.

/tmp

Alle Verzeichnisse, die temporäre Dateien und Caches enthalten, werden aus den Snapshots ausgeschlossen.

/usr/local

Dieses Verzeichnis wird bei der manuellen Installation von Software verwendet. Dieses Verzeichnis wird ausgeschlossen, damit die betreffenden Installationen bei einem Rollback nicht deinstalliert werden.

/var

Dieses Verzeichnis enthält viele Variablendateien, einschließlich Protokolle, temporäre Caches und Drittanbieterprodukte in /var/opt. Es ist der Standardspeicherort für Images und Datenbanken von virtuellen Maschinen. Daher wird dieses Subvolume so erstellt, dass alle Variablendaten von Snapshots ausgeschlossen werden und „Kopie beim Schreiben“ deaktiviert ist.

7.1.4 Anpassen der Einrichtung

 

Die Standardeinrichtung von SUSE Linux Enterprise Server deckt die meisten Anwendungsfälle ab. Sie haben jedoch die Möglichkeit, alle Aspekte beim Anfertigen und Beibehalten der Snapshots ganz nach Ihren Anforderungen zu konfigurieren.

7.1.4.1 Deaktivieren/Aktivieren von Snapshots

 

Die drei Snapshot-Typen (Zeitleiste, Installation, Administration) können unabhängig voneinander einzeln aktiviert oder deaktiviert werden.

Deaktivieren/Aktivieren von Zeitleisten-Snapshots

Aktivieren von.  snapper -c root set-config "TIMELINE_CREATE=yes"

Deaktivieren.  snapper -c root set-config "TIMELINE_CREATE=no"

Mit Ausnahme der root-Partition sind Zeitleisten-Snapshots standardmäßig aktiviert.

Deaktivieren/Aktivieren von Installations-Snapshots

Aktivieren: Installieren Sie das Paket snapper-zypp-plugin.

Deaktivieren: Deinstallieren Sie das Paket snapper-zypp-plugin

Installations-Snapshots sind standardmäßig aktiviert.

Deaktivieren/Aktivieren von Administrations-Snapshots

Aktivieren: Stellen Sie USE_SNAPPER in /etc/sysconfig/yast2 auf yes ein.

Deaktivieren: Stellen Sie USE_SNAPPER in /etc/sysconfig/yast2 auf no ein.

Administrations-Snapshots sind standardmäßig aktiviert.

7.1.4.2 Steuern von Installations-Snapshots

 

Das Anfertigen von Snapshot-Paaren beim Installieren von Paketen mit YaST oder Zypper erfolgt mit snapper-zypp-plugin. Die XML-Konfigurationsdatei /etc/snapper/zypp-plugin.conf definiert den Zeitpunkt, an dem die Snapshots erstellt werden sollen. Standardmäßig sieht die Datei folgendermaßen aus: 

 1 <?xml version="1.0" encoding="utf-8"?>
 2 <snapper-zypp-plugin-conf>
 3  <solvables>
 4   <solvable match="w"1 important="true"2>kernel-*3</solvable>
 5   <solvable match="w" important="true">dracut</solvable>
 6   <solvable match="w" important="true">glibc</solvable>
 7   <solvable match="w" important="true">systemd*</solvable>
 8   <solvable match="w" important="true">udev</solvable>
 9   <solvable match="w">*</solvable>4
10  </solvables>
11 </snapper-zypp-plugin-conf>

1

Das Übereinstimmungsattribut definiert, ob das Schema eine Wildcard im Unix-Shell-Format (w) oder ein regulärer Python-Ausdruck (re) ist.

2

Wenn für das angegebene Schema eine Übereinstimmung vorliegt und das entsprechende Paket als wichtig gekennzeichnet ist (z. B. Kernel-Pakete), wird der Snapshot ebenfalls als wichtig gekennzeichnet.

3

Schema, das mit einem Paketnamen abgeglichen werden soll. Gemäß der Einstellung für das Attribut match werden Sonderzeichen entweder als Shell-Wildcards oder als reguläre Ausdrücke interpretiert. Dieses Schema stimmt mit allen Paketnamen überein, die mit kernel- beginnen.

4

Mit dieser Zeile werden alle Pakete als übereinstimmend eingestuft.

Bei dieser Konfiguration werden Snapshot-Paare angefertigt, sobald ein Paket installiert wird (Zeile 9). Wenn Kernel-, dracut-, glibc-, systemd- oder udev-Pakete installiert werden, die als wichtig gekennzeichnet sind, wird auch das Snapshot-Paar als wichtig gekennzeichnet (Zeile 4 bis 8). Alle Regeln werden ausgewertet.

Zum Deaktivieren einer Regel können Sie die betreffende Regel löschen oder mithilfe von XML-Kommentaren deaktivieren. Wenn das System beispielsweise keine Snapshot-Paare für alle Paketinstallationen anfertigen soll, kommentieren Sie Zeile 9 aus: 

 1 <?xml version="1.0" encoding="utf-8"?>
 2 <snapper-zypp-plugin-conf>
 3  <solvables>
 4   <solvable match="w" important="true">kernel-*</solvable>
 5   <solvable match="w" important="true">dracut</solvable>
 6   <solvable match="w" important="true">glibc</solvable>
 7   <solvable match="w" important="true">systemd*</solvable>
 8   <solvable match="w" important="true">udev</solvable>
 9   <!-- <solvable match="w">*</solvable> -->
10  </solvables>
11 </snapper-zypp-plugin-conf>

7.1.4.3 Erstellen und Einhängen neuer Subvolumes

 

Das Erstellen eines neuen Subvolumes unter der /-Hierarchie und das dauerhafte Einhängen dieses Subvolumes werden unterstützt. Ein solches Subvolume wird in den Snapshots nicht berücksichtigt. Das Subvolume darf nicht in einem vorhandenen Snapshot angelegt werden, da Sie dann nach einem Rollback keine Snapshots mehr löschen könnten.

SUSE Linux Enterprise Server ist mit dem Subvolume /@/ konfiguriert, das als unabhängiger Root für dauerhafte Subvolumes wie /opt, /srv oder /home fungiert. Alle erstellten und dauerhaft eingehängten Subvolumes müssen in diesem anfänglichen root-Dateisystem erstellt werden.

Führen Sie hierzu die nachfolgenden Befehle aus. In diesem Beispiel wird das neue Subvolume /usr/important aus /dev/sda2 erstellt. 

tux > sudo mount /dev/sda2 -o subvol=@ /mnt
tux > sudo btrfs subvolume create /mnt/usr/important
tux > sudo umount /mnt

Der zugehörige Eintrag in /etc/fstab muss dabei wie folgt lauten (Beispiel): 

/dev/sda2 /usr/important btrfs subvol=@/usr/important 0 0
Tipp
Tipp: Deaktivieren des Copy-on-write-Verfahrens (COW)

Ein Subvolume kann Dateien enthalten, die sich fortwährend ändern, z. B. virtualisierte Festplatten-Images, Datenbankdateien oder Protokolldateien. Wenn dies der Fall ist, sollten Sie die Copy-on-Write-Funktion für dieses Volume deaktivieren, damit die Festplattenblöcke nicht dupliziert werden. Geben Sie hierzu die Einhängeoption nodatacow in /etc/fstab an: 

/dev/sda2 /usr/important btrfs nodatacow,subvol=@/usr/important 0 0

Mit dem Befehl chattr +C PATH können Sie das Copy-on-Write-Verfahren alternativ für einzelne Dateien oder Verzeichnisse deaktivieren.

7.1.4.4 Steuern der Snapshot-Archivierung

 

Snapshots belegen Speicherplatz auf der Festplatte. Damit keine Systemfehler wegen mangelnden Festplattenspeichers auftreten, werden alte Snapshots automatisch gelöscht. Standardmäßig werden zehn wichtige Installations- und Verwaltungs-Snapshots und bis zu zehn normale Installations- und Verwaltungs-Snapshots beibehalten. Wenn diese Snapshots mehr als 50 % des root-Dateisystems einnehmen, werden zusätzliche Snapshots gelöscht. Mindestens vier wichtige und zwei normale Snapshots werden immer beibehalten.

Anweisungen zum Ändern dieser Werte finden Sie in Abschnitt 7.5.1, „Verwalten vorhandener Konfigurationen“.

7.1.4.5 Verwenden von Snapper auf LVM-Volumes mit Thin Provisioning

 

Neben Snapshots auf Btrfs-Dateisystemen unterstützt Snapper auch das Erstellen von Snapshots auf LVM-Volumes mit Thin Provisioning (Snapshots auf normalen LVM-Volumes werden nicht unterstützt), die mit XFS, Ext4 oder Ext3 formatiert sind. Weitere Informationen zu LVM-Volumes sowie Anweisungen zum Einrichten dieser Volumes finden Sie im Book “Bereitstellungshandbuch”, Chapter 10 “Festplatte vorbereiten: Expertenmodus”, Section 10.2 “LVM-Konfiguration”.

Um Snapper auf einem LVM-Volume mit Thin Provisioning zu nutzen, müssen Sie eine Snapper-Konfiguration für dieses Volume erstellen. Auf LVM muss das Dateisystem mit --fstype=lvm(FILESYSTEM) angegeben werden. Zulässige Werte für FILESYSTEM sind ext3, etx4 und xfs. Beispiel: 

tux > sudo snapper -c lvm create-config --fstype="lvm(xfs)" /thin_lvm

Sie können diese Konfiguration gemäß den Anweisungen unter Abschnitt 7.5.1, „Verwalten vorhandener Konfigurationen“ an Ihre Anforderungen anpassen.

7.2 Rückgängigmachen von Änderungen mit Snapper

 

Snapper unter SUSE Linux Enterprise Server ist als Werkzeug vorkonfiguriert, mit dem Sie die Änderungen rückgängig machen, die von zypper und YaST vorgenommen werden. Hierzu ist Snapper so konfiguriert, dass vor und nach jeder Ausführung von zypper bzw. YaST ein Snapshot-Paar erstellt wird. Mit Snapper können Sie außerdem Systemdateien wiederherstellen, die versehentlich gelöscht oder geändert wurden. Zeitleisten-Snapshots für die root-Partition müssen für diesen Zweck aktiviert werden. Weitere Detailinformationen finden Sie unter Abschnitt 7.1.4.1, „Deaktivieren/Aktivieren von Snapshots“.

Standardmäßig werden automatische Snapshots (wie oben beschrieben) für die root-Partition und deren Subvolumes konfiguriert. Sollen Snapshots auch für andere Partitionen zur Verfügung stehen, beispielsweise für /home, können Sie benutzerdefinierte Konfigurationen anlegen.

Wichtig
Wichtig: Rückgängigmachen von Änderungen im Vergleich zu Rollback

Beim Wiederherstellen von Daten mithilfe von Snapshots ist zu beachten, dass Snapper zwei grundlegend verschiedene Szenarien bearbeiten kann:

Rückgängigmachen von Änderungen

Beim Rückgängigmachen von Änderungen gemäß den nachfolgenden Anweisungen werden zwei Snapshots miteinander verglichen, und die Änderungen zwischen diesen beiden Snapshots werden rückgängig gemacht. Bei diesem Verfahren können Sie zudem die wiederherzustellenden Dateien explizit auswählen.

Rollback

Beim Rollback gemäß den Anweisungen in Abschnitt 7.3, „System-Rollback durch Booten aus Snapshots“ wird das System in den Zustand zurückversetzt, der beim Anfertigen des Snapshots vorlag.

Beim Rückgängigmachen von Änderungen können Sie außerdem einen Snapshot mit dem aktuellen System vergleichen. Das Wiederherstellen aller Dateien aus einem solchen Vergleich liefert dasselbe Ergebnis wie ein Rollback. Für ein Rollback ist jedoch das in Abschnitt 7.3, „System-Rollback durch Booten aus Snapshots“ beschriebene Verfahren vorzuziehen, da es schneller ist und Sie das System vor dem Ausführen des Rollbacks prüfen können.

Warnung
Warnung: Datenkonsistenz

Es gibt keinen Mechanismus, mit dem die Datenkonsistenz beim Erstellen von Snapshots gewährleistet werden kann. Wenn eine Datei (z. B. eine Datenbank) zur selben Zeit geschrieben wird, während der Snapshot erstellt wird, so wird diese Datei beschädigt oder nur teilweise geschrieben. Beim Wiederherstellen dieser Datei treten Probleme auf. Darüber hinaus dürfen bestimmte Systemdateien wie /etc/mtab unter keinen Umständen wiederhergestellt werden. Es wird daher dringend empfohlen, die Liste der geänderten Dateien und ihrer Unterschiede (Diffs) in jedem Fall sorgfältig zu prüfen. Stellen Sie nur solche Dateien wieder her, die tatsächlich zu der zurückzunehmenden Aktion gehören.

7.2.1 Rückgängigmachen von Änderungen durch YaST oder Zypper

 

Wenn Sie die Stammpartition während der Installation mit Btrfs einrichten, wird Snapper (für Rollbacks von Änderungen durch YaST oder Zypper vorkonfiguriert) automatisch installiert. Bei jedem Starten eines YaST-Moduls und bei jeder Zypper-Transaktion werden zwei Snapshots erstellt: ein „Pre-Snapshot“ mit dem Zustand des Dateisystems vor dem Start des Moduls und ein „Post-Snapshot“ nach Beendigung des Moduls.

Mit dem YaST-Snapper-Modul oder mit dem snapper-Kommandozeilenwerkzeug können Sie Dateien aus dem „Pre-Snapshot“ wiederherstellen und so die Änderungen durch YaST/Zypper rückgängig machen. Durch den Vergleich der beiden Snapshots mit diesen Werkzeugen erkennen Sie außerdem, welche Dateien geändert wurden. Darüber hinaus können Sie die Unterschiede (Diff) zwischen zwei Versionen einer Datei abrufen.

Vorgehen 7.1: Rückgängigmachen von Änderungen mit dem Snapper-Modul in YaST
 

  1. Starten Sie das Snapper-Modul im Abschnitt Verschiedenes in YaST, oder geben Sie yast2 snapper ein.

  2. Unter Aktuelle Konfiguration muss die Option root eingestellt sein. Dies ist im Prinzip immer der Fall, sofern Sie nicht eigene Snapper-Konfigurationen manuell hinzugefügt haben.

  3. Wählen Sie ein Pre-/Post-Snapshot-Paar aus der Liste aus. Sowohl die YaST als auch die Zypper-Snapshot-Paare sind vom Typ Pre & Post. Für YaST-Snapshots wird die Bezeichnung zyyp(y2base) in der Spalte „Beschreibung“ angezeigt, für zypper-Snapshots die Bezeichnung zypp(zypper).

    Image

  4. Klicken Sie auf Änderungen anzeigen. Die Liste der Dateien, bei denen Unterschiede zwischen den beiden Snapshots bestehen, wird geöffnet.

    Image

  5. Prüfen Sie die Dateiliste. Zum Anzeigen der Unterschiede („Diff“) zwischen der Pre- und der Post-Version einer Datei wählen Sie die Datei aus der Liste aus.

    Image

  6. Zum Wiederherstellen von einer oder mehreren Dateien aktivieren Sie das entsprechende Kontrollkästchen für die gewünschten Dateien oder Verzeichnisse. Klicken Sie auf Auswahl wiederherstellen, und bestätigen Sie den Vorgang mit Ja.

    Image

    Zum Wiederherstellen einer einzelnen Datei klicken Sie auf den Namen dieser Datei. Die Diff-Ansicht der Datei wird aktiviert. Klicken Sie auf Vom ersten wiederherstellen, und bestätigen Sie mit Ja.

Vorgehen 7.2: Rückgängigmachen von Änderungen mit dem Kommando snapper
 

  1. Mit dem Kommando snapper list -t pre-post erhalten Sie eine Liste der YaST- und Zypper-Snapshots. Für YaST-Snapshots wird die Bezeichnung yast MODULNAME in der Spalte „Beschreibung“ angezeigt, für zypper-Snapshots die Bezeichnung zypp(zypper). 

    tux > sudo snapper list -t pre-post
Pre # | Post # | Pre Date                      | Post Date                     | Description
------+--------+-------------------------------+-------------------------------+--------------
311   | 312    | Tue 06 May 2018 14:05:46 CEST | Tue 06 May 2018 14:05:52 CEST | zypp(y2base)
340   | 341    | Wed 07 May 2018 16:15:10 CEST | Wed 07 May 2018 16:15:16 CEST | zypp(zypper)
342   | 343    | Wed 07 May 2018 16:20:38 CEST | Wed 07 May 2018 16:20:42 CEST | zypp(y2base)
344   | 345    | Wed 07 May 2018 16:21:23 CEST | Wed 07 May 2018 16:21:24 CEST | zypp(zypper)
346   | 347    | Wed 07 May 2018 16:41:06 CEST | Wed 07 May 2018 16:41:10 CEST | zypp(y2base)
348   | 349    | Wed 07 May 2018 16:44:50 CEST | Wed 07 May 2018 16:44:53 CEST | zypp(y2base)
350   | 351    | Wed 07 May 2018 16:46:27 CEST | Wed 07 May 2018 16:46:38 CEST | zypp(y2base)

  2. Mit dem Kommando snapper status PRE erhalten Sie eine Liste der geänderten Dateien für ein Snapshot-Paar.POST. Dateien, deren Inhalt geändert wurde, sind mit c gekennzeichnet, hinzugefügte Dateien mit + und gelöschte Dateien mit -. 

    tux > sudo snapper status 350..351
+..... /usr/share/doc/packages/mikachan-fonts
+..... /usr/share/doc/packages/mikachan-fonts/COPYING
+..... /usr/share/doc/packages/mikachan-fonts/dl.html
c..... /usr/share/fonts/truetype/fonts.dir
c..... /usr/share/fonts/truetype/fonts.scale
+..... /usr/share/fonts/truetype/みかちゃん-p.ttf
+..... /usr/share/fonts/truetype/みかちゃん-pb.ttf
+..... /usr/share/fonts/truetype/みかちゃん-ps.ttf
+..... /usr/share/fonts/truetype/みかちゃん.ttf
c..... /var/cache/fontconfig/7ef2298fde41cc6eeb7af42e48b7d293-x86_64.cache-4
c..... /var/lib/rpm/Basenames
c..... /var/lib/rpm/Dirnames
c..... /var/lib/rpm/Group
c..... /var/lib/rpm/Installtid
c..... /var/lib/rpm/Name
c..... /var/lib/rpm/Packages
c..... /var/lib/rpm/Providename
c..... /var/lib/rpm/Requirename
c..... /var/lib/rpm/Sha1header
c..... /var/lib/rpm/Sigmd5

  3. Zum Anzeigen der Unterschiede (Diff) für eine bestimmte Datei führen Sie snapper diff PRE aus.POST FILENAME. Wenn Sie FILENAME nicht angeben, wird die Diff-Ansicht für alle Dateien angezeigt. 

    tux > sudo snapper diff 350..351 /usr/share/fonts/truetype/fonts.scale
--- /.snapshots/350/snapshot/usr/share/fonts/truetype/fonts.scale       2014-04-23 15:58:57.000000000 +0200
+++ /.snapshots/351/snapshot/usr/share/fonts/truetype/fonts.scale       2014-05-07 16:46:31.000000000 +0200
@@ -1,4 +1,4 @@
-1174
+1486
 ds=y:ai=0.2:luximr.ttf -b&h-luxi mono-bold-i-normal--0-0-0-0-c-0-iso10646-1
 ds=y:ai=0.2:luximr.ttf -b&h-luxi mono-bold-i-normal--0-0-0-0-c-0-iso8859-1
[...]

  4. Zum Wiederherstellen einer oder mehrerer Dateien führen Sie snapper -v undochange PRE aus.POST FILENAMES. Wenn Sie FILENAMES nicht angeben, werden alle geänderten Dateien wiederhergestellt. 

    tux > sudo snapper -v undochange 350..351
     create:0 modify:13 delete:7
     undoing change...
     deleting /usr/share/doc/packages/mikachan-fonts
     deleting /usr/share/doc/packages/mikachan-fonts/COPYING
     deleting /usr/share/doc/packages/mikachan-fonts/dl.html
     deleting /usr/share/fonts/truetype/みかちゃん-p.ttf
     deleting /usr/share/fonts/truetype/みかちゃん-pb.ttf
     deleting /usr/share/fonts/truetype/みかちゃん-ps.ttf
     deleting /usr/share/fonts/truetype/みかちゃん.ttf
     modifying /usr/share/fonts/truetype/fonts.dir
     modifying /usr/share/fonts/truetype/fonts.scale
     modifying /var/cache/fontconfig/7ef2298fde41cc6eeb7af42e48b7d293-x86_64.cache-4
     modifying /var/lib/rpm/Basenames
     modifying /var/lib/rpm/Dirnames
     modifying /var/lib/rpm/Group
     modifying /var/lib/rpm/Installtid
     modifying /var/lib/rpm/Name
     modifying /var/lib/rpm/Packages
     modifying /var/lib/rpm/Providename
     modifying /var/lib/rpm/Requirename
     modifying /var/lib/rpm/Sha1header
     modifying /var/lib/rpm/Sigmd5
     undoing change done
Warnung
Warnung: Rückgängigmachen des Hinzufügens von Benutzern

Es wird nicht empfohlen, das Hinzufügen von Benutzern durch Rückgängigmachen von Änderungen zurückzunehmen. Einige Dateien, die zu diesen Benutzern gehören, verbleiben im System, da bestimmte Verzeichnisse von den Snapshots ausgeschlossen sind. Wenn ein Benutzer mit derselben Benutzer-ID wie ein gelöschter Benutzer erstellt wird, würde dieser neue Benutzer die zurückgebliebenen Dateien erben. Für das Entfernen von Benutzern wird daher dringend das YaST-Werkzeug Benutzer- und Gruppenverwaltung empfohlen.

7.2.2 Wiederherstellen von Dateien mit Snapper

 

Neben den Installations- und Verwaltungs-Snapshots werden auch Zeitleisten-Snapshots in Snapper angefertigt. Mithilfe dieser Sicherungs-Snapshots können Sie Dateien wiederherstellen, die versehentlich gelöscht wurden, oder eine frühere Version einer Datei wiederherstellen. Mit der Diff-Funktion in Snapper können Sie außerdem feststellen, welche Änderungen zu einem bestimmten Zeitpunkt vorgenommen wurden.

Das Wiederherstellen von Daten ist besonders für Daten interessant, die sich in Subvolumes oder Partitionen befinden, für die standardmäßig keine Snapshots erstellt werden. Damit Sie beispielsweise Dateien aus einem home-Verzeichnis wiederherstellen können, legen Sie eine separate Snapper-Konfiguration für /home an, mit der automatische Zeitleisten-Snapshots angefertigt werden. Eine Anleitung dazu finden Sie unter Abschnitt 7.5, „Erstellen und Bearbeiten von Snapper-Konfigurationen“.

Warnung
Warnung: Wiederherstellen von Dateien im Vergleich zu Rollback

Anhand der Snapshots für das root-Dateisystem (in der root-Konfiguration von Snapper definiert) können Sie ein Rollback des Systems vornehmen. Hierzu wird empfohlen, aus dem Snapshot zu booten und dann das Rollback auszuführen. Ausführliche Informationen finden Sie unter Abschnitt 7.3, „System-Rollback durch Booten aus Snapshots“.

Zum Ausführen eines Rollbacks können Sie alternativ alle Dateien aus einem root-Dateisystem gemäß den nachfolgenden Anweisungen wiederherstellen. Diese Methode wird jedoch nicht empfohlen. Sie können durchaus einzelne Dateien wiederherstellen, beispielsweise eine Konfigurationsdatei im Verzeichnis /etc, nicht jedoch die gesamte Liste aller Dateien im Snapshot.

Diese Beschränkung gilt nur für Snapshots, die für das root-Dateisystem angefertigt wurden.

Vorgehen 7.3: Wiederherstellen von Dateien mit dem Snapper-Modul in YaST
 

  1. Starten Sie das Snapper-Modul im Abschnitt Verschiedenes in YaST, oder geben Sie yast2 snapper ein.

  2. Wählen Sie die Aktuelle Konfiguration aus, von der ein Snapshot ausgewählt werden soll.

  3. Wählen Sie einen Zeitleisten-Snapshot aus, aus dem eine Datei wiederhergestellt werden soll, und wählen Sie Änderungen anzeigen. Zeitleisten-Snapshots weisen den Typ Einzeln und den Beschreibungswert timeline (Zeitachse) auf.

  4. Wählen Sie eine Datei im Textfeld aus; klicken Sie hierzu auf den Dateinamen. Die Unterschiede zwischen der Snapshot-Version und dem aktuellen System werden angezeigt. Aktivieren Sie das Kontrollkästchen für die wiederherzustellende Datei. Wiederholen Sie dies für alle wiederherzustellenden Dateien.

  5. Klicken Sie auf Auswahl wiederherstellen, und bestätigen Sie den Vorgang mit Ja.

Vorgehen 7.4: Wiederherstellen von Dateien mit dem Kommando snapper
 

  1. Mit dem folgenden Kommando erhalten Sie eine Liste der Zeitleisten-Snapshots für eine bestimmte Konfiguration: 

    tux > sudo snapper -c CONFIG list -t single | grep timeline

    Ersetzen Sie CONFIG durch eine vorhandene Snapper-Konfiguration. Mit snapper list-configs rufen Sie eine Liste ab.

  2. Mit dem folgenden Kommando erhalten Sie eine Liste der geänderten Dateien in einem bestimmten Snapshot: 

    tux > sudo snapper -c CONFIG status SNAPSHOT_ID..0

    Ersetzen Sie SNAPSHOT_ID durch die ID des Snapshots, aus dem die Datei(en) wiederhergestellt werden sollen.

  3. Rufen Sie optional mit dem folgenden Kommando eine Liste der Unterschiede zwischen der aktuellen Dateiversion und der Dateiversion im Snapshot ab: 

    tux > sudo snapper -c CONFIG diff SNAPSHOT_ID..0 FILE NAME

    Wenn Sie keinen Dateinamen (<FILE NAME>) angeben, werden die Unterschiede für alle Dateien angezeigt.

  4. Zum Wiederherstellen einer oder mehrerer Dateien führen Sie Folgendes aus: 

    tux > sudo snapper -c CONFIG -v undochange SNAPSHOT_ID..0 FILENAME1 FILENAME2

    Wenn Sie keine Dateinamen angeben, werden alle geänderten Dateien wiederhergestellt.

7.3 System-Rollback durch Booten aus Snapshots

 

Mit der GRUB 2-Version in SUSE Linux Enterprise Server können Sie aus Btrfs-Snapshots booten. Zusammen mit der Rollback-Funktion in Snapper sind Sie so in der Lage, ein falsch konfiguriertes System wiederherzustellen. Nur Snapshots, die für die Snapper-Standardkonfiguration (root) erstellt wurden, sind bootfähig.

Wichtig
Wichtig: Unterstützte Konfiguration

Ab SUSE Linux Enterprise Server 15 SP3 werden System-Rollbacks nur unterstützt, wenn die Konfiguration des Standard-Subvolumes der Root-Partition nicht geändert wurde.

Beim Booten eines Snapshots werden die Teile des Dateisystems, die sich im Snapshot befinden, schreibgeschützt eingehängt. Alle anderen Dateisysteme und Teile, die aus Snapshots ausgeschlossen sind, werden schreibfähig eingehängt und können bearbeitet werden.

Wichtig
Wichtig: Rückgängigmachen von Änderungen im Vergleich zu Rollback

Beim Wiederherstellen von Daten mithilfe von Snapshots ist zu beachten, dass Snapper zwei grundlegend verschiedene Szenarien bearbeiten kann:

Rückgängigmachen von Änderungen

Beim Rückgängigmachen von Änderungen gemäß den Anweisungen in Abschnitt 7.2, „Rückgängigmachen von Änderungen mit Snapper“ werden zwei Snapshots miteinander verglichen, und die Änderungen zwischen diesen beiden Snapshots werden rückgängig gemacht. Bei diesem Verfahren können Sie zudem die Dateien, die von der Wiederherstellung ausgeschlossen werden sollen, explizit auswählen.

Rollback

Beim Rollback gemäß den folgenden Anweisungen wird das System in den Zustand zurückversetzt, der beim Anfertigen des Snapshots vorlag.

Zum Ausführen eines Rollbacks aus einem bootfähigen Snapshot müssen die nachfolgenden Anforderungen erfüllt sein. Bei einer Standardinstallation wird das System entsprechend eingerichtet.

Anforderungen für ein Rollback aus einem bootfähigen Snapshot
 

  • Das root-Dateisystem muss Btrfs sein. Das Booten aus Snapshots für LVM-Volumes wird nicht unterstützt.

  • Das root-Dateisystem muss sich auf einem einzelnen Gerät, in einer einzelnen Partition und auf einem einzelnen Subvolume befinden. Verzeichnisse, die aus Snapshots ausgeschlossen sind, beispielsweise /srv (vollständige Liste siehe Abschnitt 7.1.3, „Verzeichnisse, die aus Snapshots ausgenommen sind“), können sich auf separaten Partitionen befinden.

  • Das System muss über den installierten Bootlader bootfähig sein.

So führen Sie ein Rollback aus einem bootfähigen Snapshot aus:

  1. Booten Sie das System. Wählen Sie im Bootmenü den Eintrag Bootable snapshots (Bootfähige Snapshots), und wählen Sie den zu bootenden Snapshot aus. Die Snapshots sind nach Datum geordnet, wobei der jüngste Snapshot an oberster Stelle steht.

  2. Melden Sie sich beim System an. Prüfen Sie sorgfältig, ob alle Funktionen wie erwartet arbeiten. Beachten Sie, dass Sie in kein Verzeichnis schreiben können, das Teil des Snapshots ist. Daten, die Sie in andere Verzeichnisse schreiben, gehen nicht verloren, unabhängig von Ihrem nächsten Schritt.

  3. Wählen Sie den nächsten Schritt abhängig davon aus, ob das Rollback ausgeführt werden soll oder nicht:

    1. Wenn sich das System in einem Status befindet, in dem kein Rollback ausgeführt werden soll, booten Sie erneut in den aktuellen Systemstatus. Sie können dann einen anderen Snapshot auswählen oder das Rettungssystem starten.

    2. Zum Ausführen des Rollbacks führen Sie Folgendes aus: 

      tux > sudo snapper rollback

      Führen Sie anschließend einen Reboot aus. Wählen Sie im Bootbildschirm den Standard-Booteintrag. Das neu eingesetzte System wird erneut gebootet. Ein Snapshot mit dem Zustand des Dateisystems, bevor das Rollback erstellt wird. Das Standard-Subvolume für root wird durch einen frischen Schreib-Lese-Snapshot ersetzt. Weitere Informationen finden Sie unter Abschnitt 7.3.1, „Snapshots nach dem Rollback“.

      Mit der Option -d geben Sie eine Beschreibung für den Snapshot an. Beispiel: 

      New file system root since rollback on DATE TIME
Tipp
Tipp: Rollback zu einem bestimmten Installationszustand

Wenn die Snapshots bei der Installation nicht deaktiviert werden, wird am Ende der ursprünglichen Systeminstallation ein anfänglicher bootfähiger Snapshot angelegt. Diesen Zustand können Sie jederzeit wiederherstellen; booten Sie hierzu diesen Snapshot. Der Snapshot ist an der Beschreibung Nach der Installation erkennbar.

Auch beim Starten eines Systemupgrades auf ein Service Pack oder eine neue Hauptversion wird ein bootfähiger Snapshot erstellt (sofern die Snapshots nicht deaktiviert sind).

7.3.1 Snapshots nach dem Rollback

 

Vor dem Ausführen eines Rollbacks wird ein Snapshot des laufenden Dateisystems erstellt. Die Beschreibung verweist auf die ID des Snapshots, der mit dem Rollback wiederhergestellt wurde.

Die mit Rollbacks erstellten Snapshots erhalten den Wert number für das Attribut Cleanup. Die Rollback-Snapshots werden daher automatisch gelöscht, sobald die angegebene Anzahl von Snapshots erreicht ist. Weitere Informationen finden Sie unter Abschnitt 7.7, „Automatisches Bereinigen von Snapshots“. Wenn der Snapshot wichtige Daten enthält, extrahieren Sie die Daten aus dem Snapshot, bevor er entfernt wird.

7.3.1.1 Beispiel für einen Rollback-Snapshot

 

Nach einer Neuinstallation liegen beispielsweise die folgenden Snapshots auf dem System vor: 

root # snapper --iso list
Type   | # |     | Cleanup | Description           | Userdata
-------+---+ ... +---------+-----------------------+--------------
single | 0 |     |         | current               |
single | 1 |     |         | first root filesystem |
single | 2 |     | number  | after installation    | important=yes

Nach dem Ausführen von sudo snapper rollback wird der Snapshot 3 erstellt. Dieser Snapshot enthält den Zustand des Systems vor Beginn des Rollbacks. Snapshot 4 ist das neue Btrfs-Standard-Subvolume und damit das neue System nach dem Neustart. 

root # snapper --iso list
Type   | # |     | Cleanup | Description           | Userdata
-------+---+ ... +---------+-----------------------+--------------
single | 0 |     |         | current               |
single | 1 |     | number  | first root filesystem |
single | 2 |     | number  | after installation    | important=yes
single | 3 |     | number  | rollback backup of #1 | important=yes
single | 4 |     |         |                       |

7.3.2 Abrufen und Erkennen von Snapshot-Booteinträgen

 

Zum Booten aus einem Snapshot booten Sie den Computer neu und wählen Sie Start Bootloader from a read-only snapshot (Bootloader aus einem schreibgeschützten Snapshot starten). Ein Bildschirm mit allen bootfähigen Snapshots wird geöffnet. Der jüngste Snapshot steht an erster Stelle in der Liste, der älteste entsprechend an letzter Stelle. Navigieren Sie mit den Tasten ↓ und ↑ zum gewünschten Snapshot und aktivieren Sie ihn mit Eingabetaste. Wenn Sie einen Snapshot aus dem Bootmenü heraus aktivieren, wird der Computer nicht sofort neu gestartet; stattdessen wird der Bootloader des ausgewählten Snapshots geöffnet.

Bootloader: Snapshots
Abbildung 7.1: Bootloader: Snapshots
 

Die einzelnen Snapshot-Einträge im Bootloader sind an ihrem Namensschema leicht erkennbar: 

[*]1OS2 (KERNEL3,DATE4TTIME5,DESCRIPTION6)

1

Wenn der Snapshot als wichtig markiert wurde, ist der Eintrag mit einem Sternchen (*) gekennzeichnet.

2

Bezeichnung des Betriebssystems.

4

Datum im Format JJJJ-MM-TT.

5

Uhrzeit im Format HH:MM.

6

Dieses Feld enthält eine Beschreibung des Snapshots. Bei einem manuell erstellten Snapshot ist dies die Zeichenkette, die mit der Option --description erstellt wurde, oder eine benutzerdefinierte Zeichenkette (siehe Tipp: Festlegen einer benutzerdefinierten Beschreibung für Snapshot-Einträge im Bootloader). Bei einem automatisch erstellten Snapshot ist dies das aufgerufene Werkzeug, beispielsweise zypp(zypper) oder yast_sw_single. Wenn der Platz im Boot-Bildschirm nicht ausreicht, werden zu lange Beschreibungen ggf. gekürzt.

Tipp
Tipp: Festlegen einer benutzerdefinierten Beschreibung für Snapshot-Einträge im Bootloader

Sie können die standardmäßige Zeichenkette im Beschreibungsfeld eines Snapshots durch eine benutzerdefinierte Zeichenkette ersetzen. Dies empfiehlt sich beispielsweise, wenn eine automatisch erstellte Beschreibung nicht ausreicht oder eine benutzerdefinierte Beschreibung zu lang ist. Mit dem folgenden Befehl legen Sie eine benutzerdefinierte Zeichenkette STRING für den Snapshot NUMBER fest: 

tux > sudo snapper modify --userdata "bootloader=STRING" NUMBER

Die Beschreibung sollte nicht mehr als 25 Zeichen haben. Längere Beschreibungen sind auf dem Bootbildschirm nicht lesbar.

7.3.3 Nutzungsbeschränkungen

 

Ein vollständiges System-Rollback, bei dem der exakte Zustand des gesamten Systems zum Zeitpunkt eines Snapshots wiederhergestellt wird, ist nicht möglich.

7.3.3.1 Verzeichnisse, die aus Snapshots ausgenommen sind

 

Snapshots des root-Dateisystems enthalten nicht alle Verzeichnisse. Weitere Informationen und Begründungen finden Sie unter Abschnitt 7.1.3, „Verzeichnisse, die aus Snapshots ausgenommen sind“. Als allgemeine Folge werden Daten in diesen Verzeichnissen nicht wiederhergestellt, was zu den nachfolgenden Beschränkungen führt.

Add-ons und Software von Drittanbietern sind nach einem Rollback u. U. nicht nutzbar

Anwendungen und Add-ons, mit denen Daten in Subvolumes installiert werden, die vom Snapshot ausgeschlossen sind (z. B. /opt), sind nach einem Rollback möglicherweise nicht funktionsfähig, wenn andere Teile der Anwendungsdaten auf Subvolumes installiert wurden, die im Snapshot berücksichtigt wurden. Zum Beheben dieses Problems installieren Sie die Anwendung oder das Add-on neu.

Probleme beim Dateizugriff

Wenn bei einer Anwendung die Berechtigungen und/oder das Eigentum für Dateien zwischen dem Anfertigen des Snapshots und dem aktuellen Zustand des Systems geändert wurden, kann diese Anwendung möglicherweise nicht mehr auf diese Dateien zugreifen. Setzen Sie die Berechtigungen und/oder das Eigentum für die betreffenden Dateien nach dem Rollback zurück.

Inkompatible Datenformate

Wenn ein Service oder eine Anwendung ein neues Datenformat zwischen dem Anfertigen des Snapshots und dem aktuellen Zustand des Systems festgelegt hat, kann die Anwendung die betreffenden Datendateien nach einem Rollback möglicherweise nicht mehr lesen.

Subvolumes mit einer Mischung aus Code und Daten

Subvolumes wie /srv können eine Mischung aus Code und Daten enthalten. Bei einem Rollback entsteht dabei möglicherweise nicht funktionsfähiger Code. Ein Downgrade der PHP-Version kann beispielsweise zu fehlerhaften PHP-Skripten für den Webserver führen.

Benutzerdaten

Wenn bei einem Rollback bestimmte Benutzer aus dem System entfernt werden, so werden die Daten im Eigentum dieser Benutzer in Verzeichnissen, die vom Snapshot ausgeschlossen sind, nicht entfernt. Wenn ein Benutzer mit derselben Benutzer-ID erstellt wird, würde dieser neue Benutzer die Dateien erben. Suchen und entfernen Sie bezuglose (verwaiste) Dateien mit einem Werkzeug wie find.

7.3.3.2 Kein Rollback der Bootloader-Daten

 

Ein Rollback des Bootloaders ist nicht möglich, da alle „Stufen“ des Bootloaders zusammenpassen müssen. Dies kann bei einem Rollback von /boot nicht gewährleistet werden.

7.4 Aktivieren von Snapper in Benutzer-Startverzeichnissen

 

Sie können Snapshots für das Verzeichnis /home der Benutzer aktivieren, womit eine Reihe von Anwendungsfällen unterstützt werden:

  • Verwaltung der jeweils eigenen Snapshots und Rollbacks durch die einzelnen Benutzer

  • Systembenutzer, z. B. Datenbank-, System- und Netzwerkadministratoren, die Kopien der Konfigurationsdateien, Dokumentation usw. nachverfolgen möchten

  • Samba-Freigaben mit Startverzeichnissen und dem Btrfs-Back-End

Die einzelnen Benutzerverzeichnisse sind jeweils ein Btrfs-Subvolume von /home. Dies kann manuell eingerichtet werden (siehe Abschnitt 7.4.3, „Manuelles Aktivieren von Snapshots in Startverzeichnissen“). pam_snapper bietet jedoch eine komfortablere Alternative. Mit dem Paket pam_snapper package werden das Modul pam_snapper.so und die Hilfsskripte installiert, mit denen die Benutzererstellung und die Snapper-Konfiguration automatisiert werden.

pam_snapper sorgt für die Integration in den Befehl useradd, in PAM (Pluggable Authentication Modules) und in Snapper. Snapshots werden standardmäßig beim An- und Abmelden eines Benutzers und zusätzlich in bestimmten Abständen erstellt, wenn Benutzer längere Zeit angemeldet bleiben. Sie können die Standardeinstellungen mit den gewohnten Snapper-Befehlen und Konfigurationsdateien ändern.

7.4.1 Installieren von pam_snapper und Erstellen von Benutzern

 

Der einfachste Einstieg gelingt mit einem neuen /home-Verzeichnis, das mit Btrfs formatiert ist, und ganz ohne Benutzer. Installieren Sie pam_snapper: 

root # zypper in pam_snapper

Fügen Sie diese Zeile in /etc/pam.d/common-session ein: 

session optional pam_snapper.so

Erstellen Sie mit dem Skript /usr/lib/pam_snapper/pam_snapper_useradd.sh einen neuen Benutzer und ein Startverzeichnis. Standardmäßig führt das Skript einen Probelauf aus. Ersetzen Sie DRYRUN=1 im Skript durch DRYRUN=0. Nun können Sie einen neuen Benutzer erstellen: 

root # /usr/lib/pam_snapper/pam_snapper_useradd.sh \
username group passwd=password
Create subvolume '/home/username'
useradd: warning: the home directory already exists.
Not copying any file from skel directory into it.

Die Dateien aus /etc/skel werden beim ersten Anmelden des Benutzers in sein Startverzeichnis kopiert. Rufen Sie Ihre Snapper-Konfigurationen ab und prüfen Sie, ob die Konfiguration des Benutzers erstellt wurde: 

root # snapper list --all
Config: home_username, subvolume: /home/username
Type   | # | Pre # | Date | User | Cleanup | Description | Userdata
-------+---+-------+------+------+---------+-------------+---------
single | 0 |       |      | root |         | current     |

Im Lauf der Zeit umfasst diese Ausgabe eine Liste der Snapshots, die der Benutzer mit den standardmäßigen Snapper-Befehlen verwalten kann.

7.4.2 Entfernen von Benutzern

 

Entfernen Sie Benutzer mit dem Skript /usr/lib/pam_snapper/pam_snapper_userdel.sh. Standardmäßig führt das Skript einen Probelauf aus. Ersetzen Sie DRYRUN=1 im Skript daher durch DRYRUN=0. Damit werden der Benutzer, das Start-Subvolume des Benutzers und die Snapper-Konfiguration entfernt und alle Snapshots gelöscht. 

root # /usr/lib/pam_snapper/pam_snapper_userdel.sh username

7.4.3 Manuelles Aktivieren von Snapshots in Startverzeichnissen

 

Mit diesen Schritten richten Sie die Startverzeichnisse der Benutzer manuell für Snapper ein. /home muss mit Btrfs formatiert sein und die Benutzer dürfen noch nicht erstellt worden sein. 

root # btrfs subvol create /home/username
root # snapper -c home_username create-config /home/username
root # sed -i -e "s/ALLOW_USERS=\"\"/ALLOW_USERS=\"username\"/g" \
/etc/snapper/configs/home_username
root # yast users add username=username home=/home/username password=password
root # chown username.group /home/username
root # chmod 755 /home/username/.snapshots

7.5 Erstellen und Bearbeiten von Snapper-Konfigurationen

 

Das Verhalten von Snapper ist in je einer Konfigurationsdatei pro Partition und Btrfs-Subvolume definiert. Diese Konfigurationsdateien sind unter /etc/snapper/configs/ gespeichert.

Falls das root-Dateisystem groß genug ist (etwa 12 GB), werden bei der Installation Snapshots automatisch für das root-Dateisystem / aktiviert. Die entsprechende Standardkonfiguration hat den Namen root. Mit ihr werden die YaST- und Zypper-Snapshots erstellt und verwaltet. Eine Liste der Standardwerte finden Sie im Abschnitt 7.5.1.1, „Konfigurationsdaten“.

Anmerkung
Anmerkung: Erforderliche Mindestgröße des root-Dateisystems für Snapshots

Wie unter Abschnitt 7.1, „Standardeinrichtung“ erläutert, belegen Snapshots zusätzlichen freien Speicherplatz im root-Dateisystem. Die tatsächliche Menge ist abhängig von der Anzahl der installierten Pakete und der Anzahl der Änderungen am Volume, das in den Snapshots berücksichtigt wird. Auch die Snapshot-Häufigkeit und die Anzahl der archivierten Snapshots spielen eine Rolle.

Es ist eine bestimmte Mindestgröße des Dateisystems erforderlich, damit Snapshots während der Installation automatisch aktiviert werden können. Die Größe beträgt aktuell etwa 12 GB. Dieser Wert kann sich in Zukunft durchaus ändern, je nach der Architektur und der Größe des Basissystems. Dieser Wert ist abhängig vom Wert der folgenden Tags in der Datei /control.xml auf den Installationsmedien: 

<root_base_size>
<btrfs_increase_percentage>

Die Berechnung erfolgt nach der folgenden Formel: ROOT_BASISGRÖSSE * (1 + PROZENTSATZ_FÜR_BTRFS_ZUWACHS/100)

Denken Sie daran, dass dieser Wert lediglich die Mindestgröße angibt. Stellen Sie ggf. mehr Speicherplatz für das root-Dateisystem bereit. Als Faustregel sollten Sie die Größe, die ohne aktivierte Snapshots gelten würde, verdoppeln.

Sie können eigene Konfigurationen für andere, mit Btrfs formatierte Partitionen sowie für vorhandene Subvolumes auf einer Btrfs-Partition erstellen. Im nachfolgenden Beispiel wird eine Snapper-Konfiguration zum Sichern der Webserverdaten eingerichtet, die sich auf einer separaten, mit Btrfs formatierten, unter /srv/www eingehängten Partition befinden.

Nach dem Erstellen einer Konfiguration können Sie Dateien aus diesen Snapshots wahlweise mit snapper selbst oder mit dem Snapper-Modul in YaST wiederherstellen. In YaST wählen Sie die Aktuelle Konfiguration aus, wobei Sie die Konfiguration für snapper mit dem globalen Schalter -c angeben (z. B. snapper -c myconfig list).

Zum Erstellen einer neuen Snapper-Konfiguration führen Sie snapper create-config aus: 

tux > sudo snapper -c www-data1 create-config /srv/www2

1

Der Name der Konfigurationsdatei.

2

Einhängepunkt der Partition oder des Btrfs-Subvolumes, für das die Snapshots angefertigt werden sollen.

Mit diesem Kommando erstellen Sie eine neue Konfigurationdsdatei /etc/snapper/configs/www-data mit geeigneten Standardwerten (aus /etc/snapper/config-templates/default übernommen). Anweisungen zum Anpassen dieser Standardwerte finden Sie in Abschnitt 7.5.1, „Verwalten vorhandener Konfigurationen“.

Tipp
Tipp: Standardwerte für die Konfiguration

Die Standardwerte für eine neue Konfiguration werden aus /etc/snapper/config-templates/default übernommen. Sollen eigene Standardwerte verwendet werden, erstellen Sie eine Kopie dieser Datei in demselben Verzeichnis, und passen Sie diese Kopie gemäß Ihren Anforderungen an. Geben Sie dann die Option -t option für das Kommando create-config an: 

tux > sudo snapper -c www-data create-config -t MY_DEFAULTS /srv/www

7.5.1 Verwalten vorhandener Konfigurationen

 

Das Kommando snapper bietet verschiedene Unterkommandos für die Verwaltung von vorhandenen Konfigurationen. Sie können sie auflisten, anzeigen, löschen und bearbeiten:

Auflisten von Konfigurationen

Mit dem Unterkommando snapper list-configs rufen Sie alle vorhandenen Konfigurationen ab: 

tux > sudo snapper list-configs
Config | Subvolume
-------+----------
root   | /
usr    | /usr
local  | /local
Anzeigen einer Konfiguration

Mit dem Subkommando snapper -c KONFIG get-config zeigen Sie die angegebene Konfiguration an. Ersetzen Sie CONFIG durch einen der Konfigurationsnamen in snapper list-configs. Weitere Informationen zu den Konfigurationsoptionen finden Sie in Abschnitt 7.5.1.1, „Konfigurationsdaten“.

Zum Anzeigen der Standardkonfiguration führen Sie das folgende Kommando aus: 

tux > sudo snapper -c root get-config
Bearbeiten einer Konfiguration

Mit dem Subkommando snapper -c KONFIG set-config OPTION=WERT bearbeiten Sie eine Option in der angegebenen Konfiguration. Ersetzen Sie CONFIG durch einen der Konfigurationsnamen in snapper list-configs. Eine Liste der möglichen Werte für OPTION and WERT finden Sie in Abschnitt 7.5.1.1, „Konfigurationsdaten“.

Löschen einer Konfiguration

Mit dem Subkommando snapper -c KONFIG delete-config löschen Sie eine Konfiguration. Ersetzen Sie CONFIG durch einen der Konfigurationsnamen in snapper list-configs.

7.5.1.1 Konfigurationsdaten

 

Jede Konfiguration enthält eine Liste von Optionen, die über die Kommandozeile bearbeitet werden können. Die folgende Liste zeigt weitere Details zu den einzelnen Optionen. Um einen Wert zu ändern, führen Sie das Kommando snapper -c KONFIG set-config "SCHLÜSSEL=WERT" aus.

ALLOW_GROUPS, ALLOW_USERS

Erteilt regulären Benutzern die erforderlichen Berechtigungen zum Verwenden von Snapshots. Weitere Informationen zu diesem Thema finden Sie unter dem Stichwort Abschnitt 7.5.1.2, „Verwenden von Snapper als normaler Benutzer“.

Der Standardwert ist "".

BACKGROUND_COMPARISON

Legt fest, ob Pre- und Post-Snapshots nach dem Erstellen im Hintergrund miteinander verglichen werden sollen.

Der Standardwert lautet "yes".

EMPTY_*

Definiert den Bereinigungsalgorithmus für Snapshot-Paare mit identischen Pre- und Post-Snapshots. Ausführliche Informationen finden Sie unter Abschnitt 7.7.3, „Bereinigen von Snapshot-Paaren, die sich nicht unterscheiden“.

FSTYPE

Dateisystemtyp der Partition. Bearbeiten Sie diese Datei nicht.

Der Standardwert lautet „btrfs“.

NUMBER_*

Definiert den Bereinigungsalgorithmus für Installations- und Verwaltungs-Snapshots. Ausführliche Informationen finden Sie unter Abschnitt 7.7.1, „Bereinigen von nummerierten Snapshots“.

QGROUP / SPACE_LIMIT

Fügt Quotenunterstützung zu Bereinigungs-Algorithmen hinzu. Ausführliche Informationen finden Sie unter Abschnitt 7.7.5, „Hinzufügen von Festplattenquotenunterstützung“.

SUBVOLUME

Einhängepunkt für die Partition oder das Subvolume am Snapshot. Bearbeiten Sie diese Datei nicht.

Der Standardwert ist "/".

SYNC_ACL

Wenn Snapper von regulären Benutzern verwendet wird (siehe Abschnitt 7.5.1.2, „Verwenden von Snapper als normaler Benutzer“), müssen die Benutzer auf die Verzeichnisse .snapshot zugreifen und Dateien in diesen Verzeichnissen lesen können. Wenn SYNC_ACL auf yes (ja) gesetzt ist, macht Snapper die betreffenden Verzeichnisse automatisch mithilfe von ACLs für die Benutzer und Gruppen zugänglich, die in den Einträgen ALLOW_USERS oder ALLOW_GROUPS angegeben sind.

Der Standardwert lautet „no“ (nein).

TIMELINE_CREATE

Bei yes (ja) werden stündliche Snapshots erstellt. Gültige Werte: yes, no.

Der Standardwert lautet „no“ (nein).

TIMELINE_CLEANUP / TIMELINE_LIMIT_*

Definiert den Bereinigungsalgorithmus für Zeitleisten-Snapshots. Ausführliche Informationen finden Sie unter Abschnitt 7.7.2, „Bereinigen von Zeitleisten-Snapshots“.

7.5.1.2 Verwenden von Snapper als normaler Benutzer

 

Standardmäßig kann Snapper nur von root verwendet werden. Unter Umständen müssen jedoch bestimmte Gruppen oder Benutzer in der Lage sein, Snapshots zu erstellen oder Änderungen durch Wiederherstellen eines Snapshots rückgängig zu machen:

  • Website-Administratoren, die Snapshots von /srv/www anfertigen möchten

  • Benutzer, die einen Snapshot von ihrem Home-Verzeichnis anfertigen möchten

Für diesen Zweck erstellen Sie Konfigurationen, die Berechtigungen für Benutzer und/oder Gruppen gewähren. Die Benutzer müssen in der Lage sein, das zugehörige Verzeichnis .snapshots zu lesen und darauf zuzugreifen. Am einfachsten erreichen Sie dies, wenn Sie die Option SYNC_ACL auf yes (ja) einstellen.

Vorgehen 7.5: Ermöglichen der Verwendung von Snapper für normale Benutzer
 

Beachten Sie, dass alle Schritte in diesem Verfahren von root ausgeführt werden müssen.

  1. Falls noch keine Snapper-Konfiguration vorhanden ist, erstellen Sie eine Konfiguration für die Partition oder das Subvolume, in der/dem der Benutzer Snapper verwenden soll. Weitere Anweisungen finden Sie unter Abschnitt 7.5, „Erstellen und Bearbeiten von Snapper-Konfigurationen“. Beispiel: 

    tux > sudo snapper --config web_data create /srv/www

  2. Die Konfigurationsdatei wird unter /etc/snapper/configs/CONFIG angelegt, wobei CONFIG dem Wert entspricht, den Sie im vorherigen Schritt mit -c/--config angegeben haben (beispielsweise /etc/snapper/configs/webdaten). Passen Sie die Datei entsprechend Ihrer Anforderungen an. Weitere Informationen finden Sie im Abschnitt 7.5.1, „Verwalten vorhandener Konfigurationen“.

  3. Legen Sie Werte für ALLOW_USERS und/oder ALLOW_GROUPS fest. Damit gewähren Sie bestimmten Benutzern bzw. Gruppen die Berechtigungen. Mehrere Einträge müssen mit Leertaste getrennt werden. Um beispielsweise dem Benutzer www_admin Berechtigungen zu gewähren, führen Sie Folgendes aus: 

    tux > sudo snapper -c web_data set-config "ALLOW_USERS=www_admin" SYNC_ACL="yes"

  4. Die vorhandene Snapper-Konfiguration kann nunmehr durch den oder die angegebenen Benutzer und/oder Gruppen verwendet werden. Testen Sie dies beispielsweise mit dem Kommando list: 

    www_admin:~ > snapper -c web_data list

7.6 Manuelles Erstellen und Verwalten von Snapshots

 

Snapper ist nicht auf das automatische Erstellen und Verwalten von Snapshots über eine Konfiguration beschränkt. Mit dem Kommandozeilenwerkzeug oder dem YaST-Modul können Sie auch selbst Snapshot-Paare („vorher/nachher“) oder einzelne Snapshots manuell erstellen.

Alle Snapper-Vorgänge werden für eine vorhandene Konfiguration ausgeführt (weitere Details finden Sie unter Abschnitt 7.5, „Erstellen und Bearbeiten von Snapper-Konfigurationen“). Sie können Snapshots nur für Partitionen oder Volumes erstellen, für die eine Konfiguration vorhanden ist. Standardmäßig wird die Systemkonfiguration (root) verwendet. Sollen Snapshots für Ihre eigene Konfiguration erstellt oder verwaltet werden, müssen Sie diese Konfiguration explizit auswählen. Verwenden Sie das Dropdown-Feld Aktuelle Konfiguration in YaST oder geben Sie den Schalter -c in der Kommandozeile an (snapper -c MEINE_KONF KOMMANDO).

7.6.1 Snapshot-Metadaten

 

Ein Snapshot besteht jeweils aus dem Snapshot selbst und aus einigen Metadaten. Beim Erstellen eines Snapshots müssen Sie auch die Metadaten angeben. Wenn Sie einen Snapshot bearbeiten, so ändern Sie die Metadaten – der Inhalt selbst kann nicht bearbeitet werden. Verwenden Sie das Kommando snapper list, um die vorhandenen Snapshots und ihre Metadaten anzuzeigen:

snapper --config home list

Listet Snapshots für die Konfiguration home auf. Um Snapshots für die Standardkonfiguration (root) aufzulisten, verwenden Sie snapper -c root list oder snapper list.

snapper list -a

Listet Snapshots für alle vorhandenen Konfigurationen auf.

snapper list -t pre-post

Listet alle Pre- und Post-Snapshot-Paare für die Standardkonfiguration (root) auf.

snapper list -t single

Listet alle Snapshots des Typs single für die Standardkonfiguration (root) auf.

Die folgenden Metadaten sind für jeden Snapshot verfügbar:

  • Typ: Snapshot-Typ; Details siehe Abschnitt 7.6.1.1, „Snapshot-Typen“. Diese Daten können nicht geändert werden.

  • Nummer: Eindeutige Nummer des Snapshots. Diese Daten können nicht geändert werden.

  • Pre Number (Pre-Nummer): Nummer des zugehörigen Pre-Snapshots. Nur für Snapshots vom Post-Typ. Diese Daten können nicht geändert werden.

  • Beschreibung: Beschreibung des Snapshots.

  • Benutzerdaten: Erweiterte Beschreibung, in der Sie benutzerdefinierte Daten als kommagetrennte Liste im Format Schlüssel=Wert angeben können, beispielsweise reason=testing, project=foo. Mit diesem Feld wird außerdem ein Snapshot als wichtig gekennzeichnet (important=yes), und der Benutzer, der den Snapshot erstellt hat, wird hier aufgeführt (user=tux).

  • Bereinigungsalgorithmus: Bereinigungsalgorithmus für den Snapshot; Details siehe Abschnitt 7.7, „Automatisches Bereinigen von Snapshots“.

7.6.1.1 Snapshot-Typen

 

In Snapper gibt es drei Typen von Snapshots: pre, post und einzeln. Physisch unterscheiden sie sich nicht, sie werden jedoch in Snapper unterschiedlich behandelt.

Pre

Snapshot eines Dateisystems vor einer Änderung. Jeder Vorher-Snapshot (pre) entspricht einem Nachher-Snapshot (post). Dies wird beispielsweise für automatische YaST/Zypper-Snapshots verwendet.

Post

Snapshot eines Dateisystems nach einer Änderung. Jeder Nachher-Snapshot (post) entspricht einem Vorher-Snapshot (pre). Dies wird beispielsweise für automatische YaST/Zypper-Snapshots verwendet.

Einzeln

Eigenständiger Snapshot. Dies wird beispielsweise für automatische stündliche Snapshots verwendet. Dies ist der Standardtyp beim Erstellen von Snapshots.

7.6.1.2 Bereinigungsalgorithmen

 

Snapper bietet drei Algorithmen zum Bereinigen alter Snapshots. Die Algorithmen werden im Rahmen eines täglichen cron-Auftrags ausgeführt. Sie können die Anzahl der verschiedenen Typen von Snapshots definieren, die in der Snapper-Konfiguration aufbewahrt werden sollen (siehe Abschnitt 7.5.1, „Verwalten vorhandener Konfigurationen“).

Zahl

Löscht alte Snapshots, sobald eine bestimmte Anzahl von Snapshots erreicht wird.

timeline (Zeitleiste)

Löscht Snapshots, die ein bestimmtes Alter erreicht haben; hierbei werden allerdings mehrere stündliche, tägliche, monatliche und jährliche Snapshots beibehalten.

empty-pre-post (Leer-Pre-Post)

Löscht Pre-/Post-Snapshot-Paare, zwischen denen keine Unterschiede (Diffs) bestehen.

7.6.2 Erstellen von Snapshots

 

Führen Sie zum Erstellen eines Snapshots das Kommando snapper create aus oder klicken Sie im YaST-Modul Snappper auf Erstellen. In den nachfolgenden Beispielen wird erläutert, wie Sie Snapshots über die Kommandozeile erstellen. Die YaST-Schnittstelle für Snapper wird hier nicht explizit beschrieben, bietet jedoch die gleiche Funktionalität.

Tipp
Tipp: Snapshot-Beschreibung

Geben Sie stets eine aussagekräftige Beschreibung an, mit der der Zweck des Snapshots auch später noch eindeutig erkennbar ist. Mit der Option --userdata können Sie auch weitere Informationen angeben.

snapper create --from 17 --description "with package2"

Erstellt aus einem bestehenden Snapshot einen eigenständigen Snapshot (Typ „Einzeln“). Er wird durch die Zahl des Snapshots von snapper list angegeben. (Dies gilt für Snapper Version 0.8.4 und neuere Versionen.)

snapper create --description "Snapshot für Woche 2 2014"

Erstellt einen eigenständigen Snapshot (Einzeltyp) für die Standardkonfiguration (root) mit einer Beschreibung. Da kein Bereinigungsalgorithmus angegeben ist, wird der Snapshot nicht automatisch gelöscht.

snapper --config home create --description "Bereinigung in ~tux"

Erstellt einen eigenständigen Snapshot (Einzeltyp) für die benutzerdefinierte Konfiguration (home) mit einer Beschreibung. Da kein Bereinigungsalgorithmus angegeben ist, wird der Snapshot nicht automatisch gelöscht.

snapper --config home create --description "Tägliche Datensicherung" --cleanup-algorithm timeline>

Erstellt einen eigenständigen Snapshot (Einzeltyp) für die benutzerdefinierte Konfiguration (home) mit einer Beschreibung. Der Snapshot wird automatisch gelöscht, sobald die Kriterien für den Zeitleisten-Bereinigungsalgorithmus in der Konfiguration erfüllt sind.

snapper create --type pre--print-number--description "Vor Apache-Konfigurationsbereinigung"--userdata "important=yes"

Erstellt einen Snapshot vom Pre-Typ und gibt die Snapshot-Nummer aus. Erstes Kommando zum Erstellen eines Snapshot-Paars, mit dem der „Vorher“-/„Nachher“-Zustand festgehalten wird. Der Snapshot wird als wichtig gekennzeichnet.

snapper create --type post--pre-number 30--description "Nach der Apache-Konfigurationsbereinigung"--userdata "important=yes"

Erstellt einen Snapshot vom Post-Typ, gepaart mit der Pre-Snapshot-Nummer 30. Zweites Kommando zum Erstellen eines Snapshot-Paars, mit dem der „Vorher“-/„Nachher“-Zustand festgehalten wird. Der Snapshot wird als wichtig gekennzeichnet.

snapper create --command KOMMANDO--description "Vor und nach KOMMANDO"

Erstellt automatisch ein Snapshot-Paar vor und nach dem Ausführen von KOMMANDO. Diese Option ist nur verfügbar, wenn Snapper in der Kommandozeile verwendet wird.

7.6.3 Bearbeiten von Snapshot-Metadaten

 

Bei Snapper können Sie die Beschreibung, den Bereinigungsalgorithmus und die Benutzerdaten eines Snapshots bearbeiten. Alle anderen Metadaten können nicht geändert werden. In den nachfolgenden Beispielen wird erläutert, wie Sie Snapshots über die Kommandozeile bearbeiten. Die Anpassung ist über die YaST-Oberfläche ganz einfach.

Um einen Snapshot in der Kommandozeile zu bearbeiten, müssen Sie seine Nummer kennen. Mit snapper list rufen Sie alle Snapshots mit den dazugehörigen Nummern ab.

Im Snapper-Modul in YaST werden bereits alle Snapshots aufgelistet. Wählen Sie einen Eintrag in der Liste, und klicken Sie auf Bearbeiten.

snapper modify --cleanup-algorithm "timeline" 10

Bearbeitet die Metadaten von Snapshot 10 für die Standardkonfiguration (root). Der Bereinigungsalgorithmus ist mit Zeitleiste festgelegt.

snapper --config home modify --description "Tägliche Sicherung" -cleanup-algorithm "timeline" 120

Bearbeitet die Metadaten von Snapshot 120 für die benutzerdefinierte Konfiguration home. Eine neue Beschreibung wird festgelegt, und der Bereinigungsalgorithmus wird aufgehoben.

7.6.4 Löschen von Snapshots

 

Zum Löschen eines Snapshots mit dem Snapper-Modul in YaST wählen Sie den gewünschten Snapshot in der Liste aus, und klicken Sie auf Löschen.

Um einen Snapshot mit dem Kommandozeilenwerkzeug zu löschen, müssen Sie seine Nummer kennen. Führen Sie hierzu snapper list aus. Zum Löschen eines Snapshots führen Sie snapper delete NUMBER aus.

Der Snapshot des aktuellen Standard-Subvolumes darf nicht gelöscht werden.

Wenn Sie Snapshots mit Snapper löschen, wird der freigegebene Speicherplatz von einem Btrfs-Prozess in Anspruch genommen, der im Hintergrund ausgeführt wird. Der freie Speicherplatz wird daher erst mit Verzögerung sichtbar und verfügbar. Wenn der Speicherplatz, der durch Löschen eines Snapshots freigegeben wurde, sofort zur Verfügung stehen soll, ergänzen Sie den Löschbefehl mit der Option --sync.

Tipp
Tipp: Löschen von Snapshot-Paaren

Wenn Sie einen Pre-Snapshot löschen, müssen Sie auch den zugehörigen Post-Snapshot löschen (und umgekehrt).

snapper delete 65

Löscht Snapshot 65 für die Standardkonfiguration (root).

snapper -c home delete 89 90

Löscht Snapshots 89 und 90 für die benutzerdefinierte Konfiguration home.

snapper delete --sync 23

Löscht Snapshot 23 für die Standardkonfiguration (root) und stellt den freigegebenen Speicherplatz sofort zur Verfügung.

Tipp
Tipp: Nicht referenzierte Snapshots löschen

In bestimmten Fällen ist zwar der Btrfs-Snapshot vorhanden, die XML-Datei mit den Metadaten für Snapper fehlt jedoch. Der Snapshot ist daher nicht für Snapper sichtbar, muss also manuell gelöscht werden: 

btrfs subvolume delete /.snapshots/SNAPSHOTNUMBER/snapshot
rm -rf /.snapshots/SNAPSHOTNUMBER
Tipp
Tipp: Alte Snapshots belegen mehr Speicherplatz

Wenn Sie Snapshots löschen, um Speicherplatz auf der Festplatte freizugeben, löschen Sie zuerst die älteren Snapshots. Je älter ein Snapshot ist, desto mehr Speicherplatz belegt er.

Snapshots werden außerdem im Rahmen eines täglichen CRON-Auftrags automatisch gelöscht. Weitere Informationen finden Sie unter Abschnitt 7.6.1.2, „Bereinigungsalgorithmen“.

7.7 Automatisches Bereinigen von Snapshots

 

Snapshots belegen Speicherplatz und mit der Zeit kann der von Snapshots belegte Speicherplatz groß werden. Damit Festplatten nicht zu wenig Speicherplatz haben, bietet Snapper einen Algorithmus, mit dem alte Snapshots automatisch gelöscht werden. Diese Algorithmen unterscheiden zwischen Zeitleisten-Snapshots und nummerierten Snapshots (Verwaltungs- plus Installations-Snapshot-Paare). Sie können die Anzahl der Snapshots angeben, die für jeden Typ beibehalten werden soll.

Zusätzlich dazu können Sie optional eine Speicherplatzquote angeben, mit der die maximale Größe des Speicherplatzes festgelegt wird, die Snapshots belegen können. Es ist auch möglich, Pre- und Post-Snapshot-Paare, die sich nicht unterscheiden, automatisch zu löschen.

Ein Bereinigungsalgorithmus ist immer an eine einzelne Snapper-Konfiguration gebunden, daher müssen Sie Algorithmen für jede Konfiguration festlegen. Weitere Informationen, wie das versehentliche Löschen bestimmter Snapshots verhindert wird, finden Sie unter Kann ein Snapshot geschützt werden, sodass er nicht gelöscht wird? .

Die Standardeinrichtung (root) ist so konfiguriert, dass nummerierte Snapshots und leere Pre- und Post-Snapshot-Paare bereinigt werden. Die Quotenunterstützung ist aktiviert. Snapshots dürfen nicht mehr als 50 % des verfügbaren Speicherplatzes der root-Partition belegen. Zeitleisten-Snapshots sind standardmäßig deaktiviert. Daher ist der Bereinigungsalgorithmus auch deaktiviert.

7.7.1 Bereinigen von nummerierten Snapshots

 

Das Bereinigen nummerierter Snapshots – Verwaltungs- plus Installations-Snapshot-Paare – wird von den nachfolgenden Parametern einer Snapper-Konfiguration gesteuert.

NUMBER_CLEANUP

Aktiviert oder deaktiviert die Bereinigung von Installations- und Verwaltungs-Snapshot-Paaren. Ist die Option aktiviert, werden Snapshot-Paare gelöscht, wenn die Gesamtzahl der Snapshots eine Zahl überschreitet, die mit NUMBER_LIMIT und/oder NUMBER_LIMIT_IMPORTANT festgelegt ist, und wenn sie ein Alter überschreiten, das mit NUMBER_MIN_AGE definiert ist. Gültige Werte: yes (aktivieren), no (deaktivieren).

Der Standardwert lautet "yes".

Beispielkommando zum Ändern oder Festlegen: 

tux > sudo snapper -c CONFIG set-config "NUMBER_CLEANUP=no"
NUMBER_LIMIT / NUMBER_LIMIT_IMPORTANT

Definiert, wie viele normale und/oder wichtige Installations- und Administrations-Snapshot-Paare beibehalten werden sollen. Wird ignoriert, wenn für NUMBER_CLEANUP der Wert "no" festgelegt ist.

Der Standardwert ist "2-10" für NUMBER_LIMIT und "4-10" für NUMBER_LIMIT_IMPORTANT. Die Bereinigungsalgorithmen löschen Snapshots, die den angegebenen Höchstwert überschreiten, ohne den Snapshot und den Speicherplatz im Dateisystem zu berücksichtigen. Die Algorithmen löschen außerdem Snapshots, die den Mindestwert überschreiten, bis die Grenzwerte für den Snapshot und das Dateisystem erreicht sind.

Beispielkommando zum Ändern oder Festlegen: 

tux > sudo snapper -c CONFIG set-config "NUMBER_LIMIT=10"
Wichtig
Wichtig: Bereichswerte im Vergleich zu Fixwerten

Falls die Quotenunterstützung aktiviert ist (siehe Abschnitt 7.7.5, „Hinzufügen von Festplattenquotenunterstützung“), muss der Grenzwert als Minimum-Maximum-Bereich angegeben sein, z. B. 2-10. Wenn die Quotenunterstützung deaktiviert ist, muss ein Fixwert, z. B. 10, angegeben werden, sonst schlägt das Bereinigen fehl.

NUMBER_MIN_AGE

Definiert das Mindestalter in Sekunden, das ein Snapshot aufweisen soll, bevor er automatisch gelöscht werden kann. Snapshots, die jünger als der hier angegebene Wert sind, werden, unabhängig davon, wie viele vorhanden sind, nicht gelöscht.

Der Standardwert lautet "1800".

Beispielkommando zum Ändern oder Festlegen: 

tux > sudo snapper -c CONFIG set-config "NUMBER_MIN_AGE=864000"
Anmerkung
Anmerkung: Grenzwert und Alter

NUMBER_LIMIT, NUMBER_LIMIT_IMPORTANT und NUMBER_MIN_AGE werden stets ausgewertet. Die Snapshots werden nur dann gelöscht, wenn alle Bedingungen erfüllt sind.

Wenn Sie immer die mit NUMBER_LIMIT* festgelegte Anzahl an Snapshots beibehalten möchten, unabhängig von ihrem Alter, legen Sie für NUMBER_MIN_AGE den Wert 0 fest.

Das folgende Beispiel zeigt eine Konfiguration, mit der die letzten zehn wichtigen und regulären Snapshots unabhängig vom Alter beibehalten werden: 

NUMBER_CLEANUP=yes
NUMBER_LIMIT_IMPORTANT=10
NUMBER_LIMIT=10
NUMBER_MIN_AGE=0

Wenn Sie andererseits keine Snapshots beibehalten möchten, die ein bestimmtes Alter überschreiten, legen Sie für NUMBER_LIMIT* den Wert 0 fest und geben Sie das Alter mit NUMBER_MIN_AGE an.

Das folgende Beispiel zeigt eine Konfiguration, in der lediglich Snapshots beibehalten werden, die jünger als zehn Tage sind: 

NUMBER_CLEANUP=yes
NUMBER_LIMIT_IMPORTANT=0
NUMBER_LIMIT=0
NUMBER_MIN_AGE=864000

7.7.2 Bereinigen von Zeitleisten-Snapshots

 

Das Bereinigen von Zeitleisten-Snapshots wird von den nachfolgenden Parametern einer Snapper-Konfiguration gesteuert.

TIMELINE_CLEANUP

Aktiviert oder deaktiviert die Bereinigung von Zeitleisten-Snapshots. Ist der Parameter aktiviert, werden Snapshots gelöscht, wenn die Gesamtanzahl der Snapshots eine mit TIMELINE_LIMIT_* angegebene Zahl und ein mit TIMELINE_MIN_AGE angegebenes Alter überschreiten. Gültige Werte: yes, no.

Der Standardwert lautet "yes".

Beispielkommando zum Ändern oder Festlegen: 

tux > sudo snapper -c CONFIG set-config "TIMELINE_CLEANUP=yes"
TIMELINE_LIMIT_DAILY, TIMELINE_LIMIT_HOURLY, TIMELINE_LIMIT_MONTHLY, TIMELINE_LIMIT_WEEKLY, TIMELINE_LIMIT_YEARLY

Anzahl der Snapshots, die pro Stunde, Tag, Monat, Woche und Jahr beibehalten werden sollen.

Der Standardwert für jeden Eintrag ist "10", außer für TIMELINE_LIMIT_WEEKLY, hier ist der Standardwert "0".

TIMELINE_MIN_AGE

Definiert das Mindestalter in Sekunden, das ein Snapshot aufweisen soll, bevor er automatisch gelöscht werden kann.

Der Standardwert lautet „1800“.

Beispiel 7.1: Beispiel für eine Zeitleisten-Konfiguration
 
TIMELINE_CLEANUP="yes"
TIMELINE_CREATE="yes"
TIMELINE_LIMIT_DAILY="7"
TIMELINE_LIMIT_HOURLY="24"
TIMELINE_LIMIT_MONTHLY="12"
TIMELINE_LIMIT_WEEKLY="4"
TIMELINE_LIMIT_YEARLY="2"
TIMELINE_MIN_AGE="1800"

In dieser Beispielkonfiguration werden stündliche Snapshots vorgenommen, die automatisch bereinigt werden. TIMELINE_MIN_AGE und TIMELINE_LIMIT_* werden stets gemeinsam ausgewertet. In diesem Beispiel ist das Mindestalter eines Snapshots, ab dem er gelöscht werden kann, auf 30 Minuten (1800 Sekunden) eingestellt. Durch die stündliche Erstellung der Snapshots werden nur die jeweils neuesten Snapshots beibehalten. Wenn TIMELINE_LIMIT_DAILY auf einen Wert ungleich null gesetzt ist, wid auch der erste Snapshot des Tages beibehalten.

Beizubehaltende Snapshots
 

  • Stündlich: Die letzten 24 angefertigten Snapshots.

  • Täglich: Jeweils der erste Snapshot, der zu Tagesbeginn angefertigt wurde, für die letzten sieben Tage.

  • Monatlich: Jeweils der erste Snapshot, der am letzten Tag des Monats angefertigt wurde, für die letzten zwölf Monate.

  • Wöchentlich: Jeweils der erste Snapshot, der am letzten Tag der Woche angefertigt wurde, für die letzten vier Wochen.

  • Jährlich: Jeweils der erste Snapshot, der am letzten Tag des Jahres angefertigt wurde, für die letzten zwei Jahre.

7.7.3 Bereinigen von Snapshot-Paaren, die sich nicht unterscheiden

 

Wie in Abschnitt 7.1.2, „Typen von Snapshots“ erklärt, wird immer beim Ausführen eines YaST-Moduls oder beim Ausführen von Zypper ein Pre-Snapshot beim Starten erstellt und ein Post-Snapshot beim Beenden. Falls Sie keine Änderungen vorgenommen haben, gibt es zwischen dem Pre- und Post-Snapshot keinen Unterschied. Solche „leeren“ Snapshot-Paare können automatisch gelöscht werden, indem die folgenden Parameter in einer Snapper-Konfiguration festgelegt werden:

EMPTY_PRE_POST_CLEANUP

Bei yes (ja) werden Snapshot-Paare mit identischem Pre- und Post-Snapshot gelöscht.

Der Standardwert lautet „yes“ (ja).

EMPTY_PRE_POST_MIN_AGE

Definiert das Mindestalter in Sekunden, das ein Snapshot-Paar mit identischem Pre- und Post-Snapshot aufweisen soll, bevor es automatisch gelöscht werden kann.

Der Standardwert lautet „1800“.

7.7.4 Bereinigen manuell erstellter Snapshots

 

Snapper bietet keine benutzerdefinierten Bereinigungsalgorithmen für manuell erstellte Snapshots. Sie können jedoch den Nummern- oder Zeitleisten-Bereinigungsalgorithmus einem manuell erstellten Snapshot zuweisen. Wenn Sie dies tun, reiht sich der Snapshot in der „Bereinigungswarteschlange“ für den angegebenen Algorithmus ein. Sie können einen Bereinigungsalgorithmus angeben, wenn Sie einen Snapshot erstellen oder indem Sie einen vorhandenen Snapshot bearbeiten:

snapper create --description "Test" --cleanup-algorithm number

Erstellt einen eigenständigen Snapshot (Typ: „single“) für die Standardkonfiguration (root) und weist den Bereinigungsalgorithmus number zu.

snapper modify --cleanup-algorithm "timeline" 25

Ändert den Snapshot mit der Nummer 25 und weist den Bereinigungsalgorithmus timeline zu.

7.7.5 Hinzufügen von Festplattenquotenunterstützung

 

Zusätzlich zu den oben beschriebenen Nummern- und/oder Zeitleisten-Bereinigungsalgorithmen unterstützt Snapper Quoten. Sie können festlegen, welchen prozentualen Anteil des verfügbaren Speicherplatzes Snapshots belegen dürfen. Dieser Prozentwert gilt immer für das Btrfs-Subvolume, das in der entsprechenden Snapper-Konfiguration definiert ist.

Btrfs-Quotas werden Subvolumes zugewiesen, nicht Benutzern. Zusätzlich zur Verwendung von Btrfs-Quotas können Sie Quotas für Festplattenspeicherplatz zu Benutzern und Gruppen zuweisen (beispielsweise mit dem Kommando quota).

Wenn Snapper bei der Installation aktiviert wurde, wird die Quotenunterstützung automatisch aktiviert. Falls Sie Snapper zu einem späteren Zeitpunkt manuell aktivieren, können Sie die Quotenunterstützung aktivieren, indem Sie snapper setup-quota ausführen. Dies erfordert eine gültige Konfiguration (weitere Informationen finden Sie in Abschnitt 7.5, „Erstellen und Bearbeiten von Snapper-Konfigurationen“).

Die Quotenunterstützung wird von den folgenden Parametern der Snapper-Konfiguration gesteuert.

QGROUP

Die Btrfs-Quotengruppe, die von Snapper verwendet wird. Ist dies nicht festgelegt, führen Sie snapper setup-quota aus. Ist dies bereits festgelegt, nehmen Sie nur Änderungen vor, wenn Sie die man-Seite man 8 btrfs-qgroup kennen. Dieser Wert wird mit snapper setup-quota festgelegt und sollte nicht geändert werden.

SPACE_LIMIT

Grenzwert für den Speicherplatz, den Snapshots belegen dürfen, in Bruchteilen von 1 (1 = 100 %). Gültig sind Werte zwischen 0 und 1 (0.1 = 10 %, 0.2 = 20 % ...).

Es gelten die folgenden Einschränkungen und Richtlinien:

  • Quoten werden nur zusätzlich zu einem vorhandenen Nummern- und/oder Zeitleisten-Bereinigungsalgorithmus aktiviert. Ist kein Bereinigungsalgorithmus aktiviert, werden keine Quoteneinschränkungen angewendet.

  • Ist die Quotenunterstützung aktiviert, führt Snapper bei Bedarf zwei Bereinigungsläufe durch. Im ersten Lauf werden die Regeln angewendet, die für Nummern- und Zeitleisten-Snapshots angegeben sind. Nur, wenn die Quote nach diesem Lauf überschritten wird, werden die quotenspezifischen Regeln in einem zweiten Lauf angewendet.

  • Selbst wenn die Quotenunterstützung aktiviert ist, wird die Anzahl der Snapshots, die mit den Werten NUMBER_LIMIT* und TIMELINE_LIMIT* angegeben ist, von Snapper beibehalten, auch wenn die Quote überschritten wird. Daher wird empfohlen, die Bereichswerte (MIN.-MAX.) für NUMBER_LIMIT* und TIMELINE_LIMIT* anzugeben, um sicherzustellen, dass die Quote angewendet werden kann.

    Wenn beispielsweise NUMBER_LIMIT=5-20 festgelegt ist, führt Snapper einen ersten Bereinigungslauf durch und reduziert die Anzahl normaler Nummern-Snapshots auf 20. Falls diese 20 Snapshots die Quote überschreiten, löscht Snapper die ältesten Snapshots in einem zweiten Lauf, bis die Quote eingehalten wird. Mindestens fünf Snapshots werden immer beibehalten, unabhängig davon, wie viel Speicherplatz sie belegen.

7.8 Anzeigen von exklusiv für Snapshots verwendetem Festplattenspeicherplatz

 

Snapshots geben Daten frei, um den Speicherplatz effizient zu nutzen. Daher wird mit üblichen Kommandos wie du und df der belegte Speicherplatz nicht genau gemessen. Wenn Sie in Btrfs mit aktivierten Quotas Speicherplatz freigeben möchten, müssen Sie wissen, wie viel exklusiver Speicherplatz von jedem Snapshot belegt wird, im Gegensatz zum gemeinsamen Speicherplatz. Snapper ab Version 0.6 gibt den belegten Festplattenspeicherplatz für jeden Snapshot in der Spalte Verwendeter Platz an: 

root # snapper--iso list
  # | Type   | Pre # | Date                | User | Used Space | Cleanup | Description           | Userdata     
----+--------+-------+---------------------+------+------------+---------+-----------------------+--------------
 0  | single |       |                     | root |            |         | current               |              
 1* | single |       | 2019-07-22 13:08:38 | root |  16.00 KiB |         | first root filesystem |              
 2  | single |       | 2019-07-22 14:21:05 | root |  14.23 MiB | number  | after installation    | important=yes
 3  | pre    |       | 2019-07-22 14:26:03 | root | 144.00 KiB | number  | zypp(zypper)          | important=no 
 4  | post   |     3 | 2019-07-22 14:26:04 | root | 112.00 KiB | number  |                       | important=no 
 5  | pre    |       | 2019-07-23 08:19:36 | root | 128.00 KiB | number  | zypp(zypper)          | important=no 
 6  | post   |     5 | 2019-07-23 08:19:43 | root |  80.00 KiB | number  |                       | important=no 
 7  | pre    |       | 2019-07-23 08:20:50 | root | 256.00 KiB | number  | yast sw_single        |              
 8  | pre    |       | 2019-07-23 08:23:22 | root | 112.00 KiB | number  | zypp(ruby.ruby2.5)    | important=no 
 9  | post   |     8 | 2019-07-23 08:23:35 | root |  64.00 KiB | number  |                       | important=no 
10  | post   |     7 | 2019-07-23 08:24:05 | root |  16.00 KiB | number  |                       |

Mit dem Kommando btrfs wird der von Snapshots belegte Speicherplatz anders angezeigt: 

root # btrfs qgroup show -p /
qgroupid         rfer         excl parent  
--------         ----         ---- ------  
0/5          16.00KiB     16.00KiB ---     
[...]    
0/272         3.09GiB     14.23MiB 1/0     
0/273         3.11GiB    144.00KiB 1/0     
0/274         3.11GiB    112.00KiB 1/0     
0/275         3.11GiB    128.00KiB 1/0     
0/276         3.11GiB     80.00KiB 1/0     
0/277         3.11GiB    256.00KiB 1/0     
0/278         3.11GiB    112.00KiB 1/0     
0/279         3.12GiB     64.00KiB 1/0     
0/280         3.12GiB     16.00KiB 1/0     
1/0           3.33GiB    222.95MiB ---

In der Spalte qgroupid wird die Kennung für jedes Subvolume angezeigt und eine Kombination aus qgroup-Ebene und ID zugewiesen.

In der Spalte rfer wird die Gesamtanzahl der Daten angezeigt, auf die im Subvolume verwiesen wird.

In der Spalte excl werden die exklusiven Daten in jedem Subvolume angezeigt.

In der Spalte parent wird die übergeordnete qgroup der Subvolumes angezeigt.

Im letzten Element 1/0 wird die Gesamtanzahl für die übergeordnete qgroup angezeigt. Im obigen Beispiel werden 222,95 MiB freigegeben, wenn alle Subvolumes entfernt werden. Führen Sie folgendes Kommando aus, um zu sehen, welche Snapshots den einzelnen Subvolumes zugeordnet sind: 

root # btrfs subvolume list -st /
ID	gen	top level	path	
--	---	---------	----	
267	298	266		@/.snapshots/1/snapshot
272	159	266		@/.snapshots/2/snapshot
273	170	266		@/.snapshots/3/snapshot
274	171	266		@/.snapshots/4/snapshot
275	287	266		@/.snapshots/5/snapshot
276	288	266		@/.snapshots/6/snapshot
277	292	266		@/.snapshots/7/snapshot
278	296	266		@/.snapshots/8/snapshot
279	297	266		@/.snapshots/9/snapshot
280	298	266		@/.snapshots/10/snapshot

Ein Upgrade von einem Service Pack auf das nächste führt zu Snapshots, die viel Festplattenspeicherplatz in den System-Subvolumes belegen. Es wird daher empfohlen, diese Snapshots manuell zu löschen, sobald Sie sie nicht mehr benötigen. Ausführliche Informationen finden Sie unter Abschnitt 7.6.4, „Löschen von Snapshots“.

7.9 Häufig gestellte Fragen

 
F: Warum zeigt Snapper niemals Änderungen in /var/log, /tmp und anderen Verzeichnissen an?

Einige Verzeichnisse werden aus Snapshots ausgeschlossen. Weitere Informationen und Begründungen finden Sie unter Abschnitt 7.1.3, „Verzeichnisse, die aus Snapshots ausgenommen sind“. Sollen für einen Pfad keine Snapshots angefertigt werden, legen Sie ein Subvolume für diesen Pfad an.

F: Kann ich einen Snapshot über den Bootloader booten?

Ja. Weitere Informationen finden Sie in Abschnitt 7.3, „System-Rollback durch Booten aus Snapshots“.

F: Kann ein Snapshot geschützt werden, sodass er nicht gelöscht wird?

Derzeit bietet Snapper keine Möglichkeit, zu verhindern, dass ein Snapshot manuell gelöscht wird. Jedoch können Sie verhindern, dass Snapshots automatisch durch Bereinigungsalgorithmen gelöscht werden. Manuell erstellten Snapshots (siehe Abschnitt 7.6.2, „Erstellen von Snapshots“) ist kein Bereinigungsalgorithmus zugewiesen, es sei denn, Sie geben einen mit --cleanup-algorithm an. Automatisch erstellten Snapshots ist immer entweder der number- oder timeline-Algorithmus zugewiesen. Um auf diese Weise eine Zuweisung für einen oder mehrere Snapshots zu entfernen, gehen Sie wie folgt vor:

  1. Auflisten aller verfügbaren Snapshots: 

    tux > sudo snapper list -a

  2. Merken Sie sich die Zahl der Snapshots, deren Löschung Sie verhindern möchten.

  3. Führen Sie das folgende Kommando aus und ersetzen Sie die Zahlenplatzhalter durch die Zahl(en), die Sie sich gemerkt haben: 

    tux > sudo snapper modify --cleanup-algorithm "" #1 #2 #n

  4. Überprüfen Sie das Ergebnis, indem Sie erneut snapper list -a ausführen. Der Eintrag in der Spalte Cleanup sollte nun für die bearbeiteten Snapshots leer sein.

F: Wo finde ich weitere Informationen zu Snapper?

Besuchen Sie die Snapper-Homepage unter http://snapper.io/.

8 Live-Kernel-Patching mit KLP

 

In diesem Dokument werden die Grundlagen der Kernel Live Patching-Technologie (KLP) erläutert und Sie finden hier Richtlinien für den SLE Live Patching-Dienst.

Mit KLP können die neuesten Sicherheitsaktualisierungen ohne Neustart auf Linux-Kernel angewendet werden. So erzielen Sie die maximale Betriebszeit und Verfügbarkeit des Systems, was insbesondere bei unternehmenswichtigen Systemen von Bedeutung ist.

Die Angaben in diesem Dokument gelten für die AMD64/Intel 64-, POWER- und IBM Z-Architekturen. KLP wird auf dem Xen-Hypervisor unterstützt.

8.1 Vorteile des Kernel Live Patching

 

KLP bietet mehrere Vorteile.

  • Wenn Unternehmen bestimmte Compliance-Zertifizierungen beantragen oder beibehalten möchten, sind sie darauf angewiesen, eine große Anzahl an Servern automatisch auf dem neuesten Stand zu halten. KLP kann dazu beitragen, die Compliance zu erzielen und gleichzeitig den Bedarf an kostspieligen Wartungsfenstern zu senken.

  • Unternehmen, die mit SLA-Verträgen arbeiten, müssen eine definierte Verfügbarkeit und Betriebszeit garantieren. Mit Live Patching ist es möglich, Systeme ohne Ausfallzeiten zu patchen.

  • KLP ist Teil des standardmäßigen Systemaktualisierungsmechanismus, sodass keine besondere Schulung oder Einführung komplizierter Wartungsroutinen anfällt.

8.2 Überblick über Kernel Live Patching

 

Kernel-Live-Patches werden in Form von Paketen mit modifiziertem Code bereitgestellt, die vom Kernel-Hauptpaket getrennt sind. Die Live-Patches sind kumulativ; der jeweils neueste Patch enthält also alle Fehlerbehebungen aus den vorhergehenden Patches für das Kernel-Paket. Jedes Kernel-Live-Paket ist an die genaue Kernel-Version gebunden, für die es ausgegeben wird. Die Versionsnummer des Live-Patch-Pakets erhöht sich bei jedem Hinzufügen von Fehlerbehebungen.

Wichtig
Wichtig: Live-Patches im Vergleich zu Kernel-Aktualisierungen

Live-Patches enthalten lediglich kritische Fehlerbehebungen und ersetzen nicht die regulären Kernel-Aktualisierungen, für die ein Neustart erforderlich ist. Live-Patches sind quasi vorübergehende Maßnahmen zum Schutz des Kernels, bis eine ordnungsgemäße Kernel-Aktualisierung und ein Neustart durchgeführt werden.

Das nachfolgende Diagramm zeigt die Beziehungen zwischen Live-Patches und Kernel-Aktualisierungen. Die Liste der CVEs und Fehlerberichte, die im derzeit aktiven Live-Patch behandelt werden, wird mit dem Kommando klp -v patches abgerufen.

Image

Es ist möglich, mehrere Versionen des Kernel-Pakets zusammen mit den jeweiligen Live-Patches zu installieren. Diese Pakete lösen keine Konflikte aus. Sie können aktualisierte Kernel-Paket zusammen mit Live-Patches für den ausgeführten Kernel installieren. In diesem Fall werden Sie möglicherweise aufgefordert, das System neu zu starten. Benutzer mit SLE Live Patching-Abonnements haben Anspruch auf technischen Support, solange Live-Patch-Aktualisierungen für den ausgeführten Kernel vorliegen (siehe Abschnitt 8.5.1, „Prüfen des Ablaufdatums des Live-Patches“).

Wenn KLP aktiviert ist, umfasst jede Kernel-Aktualisierung auch ein Live-Patch-Paket. Dieser Live-Patch enthält keine Fehlerbehebungen, sondern dient als Grundlage für künftige Live-Patches für den entsprechenden Kernel. Diese leeren, grundlegenden Patches werden als ursprüngliche Patches bezeichnet.

8.2.1 Umfang des Kernel Live Patching

 

SLE Live Patching umfasst Fehlerbehebungen für Sicherheitsrisiken ab Stufe 7 des SUSE Common Vulnerability Scoring-Systems (CVSS; SUSE CVSS beruht auf dem CVSS-3.0-System) sowie Fehlerkorrekturen im Hinblick auf die Systemstabilität oder auf beschädigte Daten. Es ist jedoch nicht in jedem Fall technisch praktikabel, Live-Patches für alle Fehlerbehebungen in den angegebenen Kategorien zu erstellen. SUSE behält sich daher das Recht vor, Fehlerbehebungen in Situationen zu überspringen, in denen ein Kernel-Live-Patch aus technischen Gründen nicht möglich ist. Derzeit werden mehr als 95 % der geeigneten Fehlerbehebungen als Live-Patches bereitgestellt. Weitere Informationen zum CVSS (der Grundlage für die SUSE-CVSS-Einstufung) finden Sie unter Common Vulnerability Scoring System SIG.

8.2.2 Einschränkungen des Kernel Live Patching

 

Das KLP umfasst den Austausch von Funktionen und die behutsame Ersetzung von Funktionssätzen, die voneinander abhängig sind. Hierbei werden Aufrufe von älterem Code an aktualisierten Code weitergeleitet, der sich an einem anderen Speicherort befindet. Veränderungen in den Datenstrukturen erschweren die Situation, da die Daten am bisherigen Ort verbleiben und nicht erweitert oder neu interpretiert werden können. Es gibt zwar einige Methoden für die indirekte Veränderung von Datenstrukturen, doch einige Fehlerbehebungen können nicht in Live-Patches umgesetzt werden. In dieser Situation ist ein Neustart des Systems die einzige Möglichkeit, die Fehlerbehebungen anzuwenden.

8.3 Aktivieren von Kernel Live Patching mit YaST

 

Für die Aktivierung von Kernel Live Patching benötigen Sie aktive Abonnements für SLES und SLE Live Patching. Prüfen Sie im SUSE Customer Center den Status Ihrer Abonnements und rufen Sie einen Registrierungscode für das SLE Live Patching-Abonnement ab.

So aktivieren Sie Kernel Live Patching auf dem System:

  1. Führen Sie das Kommando yast2 registration aus und klicken Sie auf Erweiterungen auswählen.

  2. Wählen Sie in der Liste der verfügbaren Erweiterungen den Eintrag SUSE Linux Enterprise Live Patching 15 und klicken Sie auf Weiter.

  3. Bestätigen Sie die Lizenzvereinbarung und klicken Sie auf Weiter.

  4. Geben Sie Ihren Registrierungscode für SLE Live Patching ein und klicken Sie auf Weiter.

  5. Prüfen Sie die Installationszusammenfassung und die ausgewählten Schemata. Die Schemata Live Patching und SLE Live Patching Lifecycle Data sollten automatisch zur Installation ausgewählt werden, ebenso wie weitere Pakete, die Abhängigkeiten berücksichtigen.

  6. Schließen Sie die Installation mit Akzeptieren ab. Dadurch werden auf Ihrem System die Basiskomponenten von Kernel Live Patching sowie der ursprüngliche Live-Patch und die erforderlichen Abhängigkeiten installiert.

8.4 Aktivieren von Kernel Live Patching über die Kommandozeile

 

Für die Aktivierung von Kernel Live Patching benötigen Sie aktive Abonnements für SLES und SLES Live Patching. Prüfen Sie im SUSE Customer Center den Status Ihrer Abonnements und rufen Sie einen Registrierungscode für das SLES Live Patching-Abonnement ab.

  1. Führen Sie das Kommando sudo SUSEConnect --list-extensions aus. Beachten Sie das genaue Aktivierungskommando für SLES Live Patching. Beispielausgabe des Kommandos (gekürzt): 

    $ SUSEConnect --list-extensions
...
SUSE Linux Enterprise Live Patching 15 SP3 x86_64
Activate with: SUSEConnect -p sle-module-live-patching/15.3/x86_64 \
  -r ADDITIONAL REGCODE

  2. Aktivieren Sie SLES Live Patching mit dem abgerufenen Kommando, gefolgt von -r LIVE_PATCHING_REGISTRIERUNGSCODE, beispielsweise: 

    SUSEConnect -p sle-module-live-patching/15.3/x86_64 \
  -r LIVE_PATCHING_REGISTRATION_CODE

  3. Installieren Sie die erforderlichen Pakete und Abhängigkeiten mit dem Kommando zypper install -t pattern lp_sles

Zu diesem Zeitpunkt sind die Live-Patches für das System bereits angewendet.

So läuft der Prozess hinter den Kulissen ab: Wenn das Paketinstallationssystem erkennt, dass ein Live-Patch für einen installierten Kernel angewendet werden kann und dass ein Live-Patch für diesen Kernel im Software-Kanal vorliegt, wählt das System den Live-Patch zur Installation aus. Der Kernel erhält dann die Live-Patch-Fehlerbehebungen als Teil der Paketinstallation. Der Live-Patch für den Kernel wird noch vor Abschluss der Produktinstallation durchgeführt.

8.5 Durchführen von Kernel Live Patching

 

Kernel-Live-Patches werden im Rahmen von regulären Systemaktualisierungen installiert. Es sind jedoch einige Dinge zu beachten.

  • Der Live-Patch für den Kernel wird durchgeführt, wenn ein Paket kernel-livepatch-* für den ausgeführten Kernel installiert wurde. Mit dem Kommando zypper se --details kernel-livepatch-* können Sie prüfen, welche Kernel-Live-Patch-Pakete auf Ihrem System installiert sind.

  • Wenn das Paket Kernel-Standard installiert ist, fordert der Update-Manager Sie auf, das System neu zu starten. Damit diese Meldung nicht angezeigt wird, können Sie Kernel-Aktualisierungen aus dem Patching-Vorgang herausfiltern. Hierzu können Sie Paketsperren mit Zypper hinzufügen. Mit SUSE Manager ist es auch möglich, Kanalinhalte zu filtern (siehe Live-Patching mit SUSE Manager).

  • Sie können den Patching-Status mit dem Kommando klp status prüfen. Zur Untersuchung installierter Patches führen Sie das Kommando klp -v patches aus.

  • Denken Sie daran: Es können zwar mehrere Kernel-Pakete auf dem System installiert sein, doch es kann immer nur eines dieser Pakete ausgeführt werden, nicht mehrere Pakete gleichzeitig. Ebenso können mehrere Live-Patch-Pakete installiert sein, doch es wird immer nur ein Live-Patch in den Kernel geladen.

  • Der aktive Live-Patch ist in der initrd enthalten. Bei einem unvorhergesehenen Neustart fährt das System also mit den angewendeten Live-Patches hoch, sodass Sie das Patching nicht wiederholen müssen.

8.5.1 Prüfen des Ablaufdatums des Live-Patches

 

Vergewissern Sie sich, dass lifecycle-data-sle-module-live-patching installiert ist, und führen Sie das Kommando zypper lifecycle aus. Im Abschnitt Ende des Paket-Supports, falls abweichend vom Produkt der Ausgabe, werden Angaben zum Ablaufdatum der Live-Patches angezeigt.

Jeder Live-Patch wird ein Jahr ab Veröffentlichung des zugrunde liegenden Kernel-Pakets aktualisiert. Auf der Seite Verwaltete Kernels, Patch-Aktualisierungen und Lebenszyklus können Sie das Ablaufdatum anhand der ausgeführten Kernel-Version prüfen, ohne die Produkterweiterung zu installieren.

8.6 Fehlerbehebung bei Kernel Live Patching-Problemen

 

8.6.1 Manuelles Patch-Downgrade

 

Wenn der neueste Live-Patch Probleme verursacht, können Sie ein Downgrade des aktuell installierten Live-Patches auf die vorhergehende Version durchführen. Es wird empfohlen, das Patch-Downgrade vorzunehmen, bevor das System erste Probleme zeigt. Denken Sie daran, dass ein System mit Kernel-Warnungen oder Kernel-Fehlerspuren im Systemprotokoll unter Umständen nicht für das Patch-Downgrade-Verfahren geeignet ist. Wenn Sie nicht sicher sind, ob das System die Anforderungen für ein Patch-Downgrade erfüllt, fragen Sie den technischen Support von SUSE.

Vorgehen 8.1: Manuelles Patch-Downgrade
 

  1. Ermitteln Sie den automatischen Live-Patch mit dem Kommando klp -v patches. Der aktuell ausgeführte Patch befindet sich in der Zeile, die mit RPM: beginnt. Beispiel: 

    RPM: kernel-livepatch-5_3_18-24_29-default-2-2.1.x86_64

    5_3_18-24_29-default im Beispiel oben bezeichnet die genaue ausgeführte Kernel-Version.

  2. Suchen Sie mit dem Kommando zypper search -s kernel-livepatch-VERSION_DES_AUSGEFÜHRTEN_KERNELS-defaultnach früheren Versionen des Patches. Das Kommando gibt eine Liste der verfügbaren Paketversionen zurück. Denken Sie daran, dass die Versionsnummer bei jeder Veröffentlichung eines neuen Live-Patch-Pakets um eins erhöht wird. Wählen Sie die Versionsnummer aus, die um eine Veröffentlichung niedriger ist als die aktuelle Version.

  3. Installieren Sie die gewünschte Version mit dem Kommando zypper in --oldpackage kernel-livepatch-VERSION_DES_AUSGEFÜHRTEN_KERNELS-default=GEWÜNSCHTE_VERSION.

9 Transaktionsaktualisierungen

 

Transaktionsaktualisierungen sind in SUSE Linux Enterprise Server als Technologievorschau für die Aktualisierung von SLES verfügbar, wenn das root-Dateisystem schreibgeschützt ist. Transaktionsaktualisierungen sind atomar (alle Aktualisierungen werden nur angewendet, wenn alle Aktualisierungen erfolgreich sind) und unterstützen Rollbacks. Es ist kein laufendes System betroffen, da Änderungen erst aktiviert werden, nachdem das System neu gebootet wurde. Da Reboots eine Störung darstellen, muss der Administrator entscheiden, ob ein Reboot kostspieliger ist als die Störung laufender Services. Wenn Reboots zu kostspielig sind, sollten Sie keine Transaktionsaktualisierungen verwenden.

Transaktionsaktualisierungen werden täglich vom Skript transactional-update ausgeführt. Das Skript prüft auf verfügbare Aktualisierungen. Falls Aktualisierungen vorhanden sind, erstellt es im Hintergrund einen neuen Snapshot des root-Dateisystems. Danach ruft es die Aktualisierungen von den Versionskanälen ab. Sobald der neue Snapshot vollständig aktualisiert ist, wird er als aktiv gekennzeichnet und wird nach dem nächsten Reboot des Systems zum neuen standardmäßigen root-Dateisystem. Wenn transactional-update automatisch ausgeführt wird (das Standardverhalten), wird das System auch neu gebootet. Sowohl die Zeitdauer für den Aktualisierungsvorgang als auch das Wartungsfenster für den Reboot sind konfigurierbar.

Es können nur Pakete aktualisiert werden, die Teil des Snapshots des root-Dateisystems sind. Sollten die Pakete Dateien enthalten, die nicht Teil des Snapshots sind, dann könnte die Aktualisierung fehlschlagen oder das System beschädigen.

RPMs, die eine Lizenz benötigen, um akzeptiert zu werden, können nicht aktualisiert werden.

9.1 Einschränkungen bei Technologievorschauen

 

Technologievorschauen weisen bestimmte Einschränkungen in der Funktionalität auf. Die folgenden Pakete funktionieren nicht bei transactional-update:

  • Die Variable Die standardmäßige nginx- Standardseite index.html ist möglicherweise nicht verfügbar.

  • tomcat-webapps und tomcat-admin-webapps

  • phpMyAdmin

  • sca-appliance-*

  • mpi-selector

  • emacs funktioniert mit Ausnahme von Emacs-Spielen

  • bind und bind-chrootenv

  • docbook*

  • sblim-sfcb*

  • texlive*

  • iso_ent

  • openjade

  • opensp

  • pcp

  • plymouth

  • postgresql-server-10

  • pulseaudio-gdm-hooks

  • smartmontools

Die Aktualisierungskomponente des Systeminstallationsprogramms funktioniert nicht bei einem schreibgeschützten Dateisystem, weil es Transaktionsaktualisierungen nicht unterstützt.

Weitere Überlegungen:

  • Im Allgemeinen ist es sinnvoll, den Zeitraum zwischen der Aktualisierung des Systems und dem Reboot des Rechners so kurz wie möglich zu halten.

  • Es kann immer nur eine Aktualisierung angewendet werden. Nach jeder Aktualisierung und nach dem Anwenden der nächsten Aktualisierung muss ein Reboot erfolgen.

  • update-alternatives sollte nach einer Transaktionsaktualisierung erst nach dem Reboot des Rechners ausgeführt werden.

  • Erstellen Sie nach einer Transaktionsaktualisierung neue Systembenutzer oder Systemgruppen erst nach einem Reboot. Normale Benutzer und Gruppen (UID > 1000, GID > 1000) können jedoch erstellt werden.

  • YaST ist noch nicht mit Transaktionsaktualisierungen vertraut. Es funktioniert nicht, wenn ein YaST-Modul zusätzliche Pakete installieren muss. Normale Systemvorgänge, bei denen nur Konfigurationsdateien in /etc bearbeitet werden, funktionieren.

  • Für php7-fastcgimüssen Sie manuell einen symlink erstellen (/srv/www/cgi-bin/php), der auf /usr/bin/php-cgi zeigt.

  • ntpist Teil des Legacy-Moduls für die Migration von älteren SLES-Versionen. Es wird nicht auf einer neueren Installation von SUSE Linux Enterprise Server unterstützt und wurde ersetzt durch chrony. Wenn Sie weiterhin ntpverwenden, muss eine neue Installation vorgenommen werden, damit Transaktionsaktualisierungen funktionieren.

  • sblim-sfcb: Das gesamte sblim-Ökosystem ist mit Transaktionsaktualisierungen kompatibel.

  • btrfs-defrag aus dem Paket btrfsmaintenance funktioniert nicht bei einem schreibgeschützten root-Dateisystem.

  • Für btrfs-balance muss die Variable BTRFS_BALANCE_MOUNTPOINTS in /etc/sysconfig/btrfsmaintenance von / in /.snapshots geändert werden.

  • Für btrfs-scrub muss die Variable BTRFS_SCRUB_MOUNTPOINTS in /etc/sysconfig/btrfsmaintenance von / in /.snapshots geändert werden.

9.2 Aktivieren von transactional-update

 

Sie müssen das Transaktionsserver-Modul bei der Systeminstallation aktivieren und dann die Transaktionsserver-Rolle auswählen. Die spätere Installation von Paketen vom Transaktionsserver-Modul in einem laufenden System wird NICHT unterstützt und könnte das System beschädigen.

Beachten Sie, dass Änderungen am Subvolume-Layout der root-Partition oder Platzierung von Unterverzeichnissen oder Subvolumes der root-Partition in eigene Partitionen (ausgenommen /home, /var, /srv und /opt) nicht unterstützt werden und höchstwahrscheinlich das System beschädigen.

9.3 Verwalten von automatischen Aktualisierungen

 

Automatische Aktualisierungen werden von einem systemd.timer gesteuert, der einmal pro Tag ausgeführt wird. Damit werden alle Aktualisierungen angewendet und rebootmgrd wird informiert, dass der Rechner neu gebootet werden muss. Die Uhrzeit für die Ausführung der Aktualisierung kann angepasst werden. Weitere Informationen hierzu finden Sie unter systemd.timer(5). Informationen zum Anpassen des Wartungsfensters, in dem festgelegt wird, wann rebootmgrd das System neu bootet, finden Sie unter rebootmgrd(8).

Automatische Transaktionsaktualisierungen werden deaktiviert mit dem Kommando: 

root # systemctl --now disable transactional-update.timer

9.4 Das Kommando transactional-update

 

Mit dem Kommando transactional-update ist eine atomare Installation oder das Entfernen von Aktualisierungen möglich. Aktualisierungen werden dann nur angewendet, wenn alle erfolgreich installiert werden können. Mit transactional-update wird ein Snapshot von Ihrem System vor Anwenden der Aktualisierung erstellt. Dieser Snapshot kann wiederhergestellt werden. Alle Änderungen werden erst nach dem Reboot aktiv.

--continue

Mit der Option --continue werden mehrere Änderungen an einem bestehenden Snapshot vorgenommen, ohne dass neu gebootet werden muss.

Das standardmäßige Verhalten von transactional-update besteht darin, einen neuen Snapshot vom aktuellen root-Dateisystem zu erstellen. Wenn Sie etwas vergessen, etwa die Installation eines neuen Pakets, müssen Sie einen Reboot ausführen, um die früheren Änderungen anzuwenden. Danach muss das Kommandotransactional-update erneut ausgeführt werden, um das vergessene Paket zu installieren, und es muss erneut ein Reboot erfolgen. Sie können das Kommando transactional-update nicht mehrmals ohne Reboot zum Hinzufügen weiterer Änderungen zum Snapshot ausführen. Dadurch würden separate unabhängige Snapshots erstellt werden, die nicht die Änderungen der früheren Snapshots enthalten.

Mit der Option --continue können Sie jedoch so viele Änderungen vornehmen, wie Sie möchten, ohne neu booten zu müssen. Es wird jedes Mal ein neuer Snapshot erstellt, der jeweils alle Änderungen der früheren Snapshots sowie die neuen Änderungen enthält. Wiederholen Sie diesen Vorgang beliebig oft und booten Sie das System neu, sobald der letzte Snapshot alle gewünschten Änderungen enthält. Der letzte Snapshot wird dann das neue root-Dateisystem.

Als weitere nützliche Funktion der Option --continue können Sie jeden beliebigen vorhandenen Snapshot als Basis für Ihren neuen Snapshot auswählen. Im folgenden Beispiel wird gezeigt, wie transactional-update ausgeführt wird, um ein neues Paket in einem Snapshot basierend auf Snapshot 13 zu installieren. Danach wird es erneut ausgeführt, um ein weiteres Paket zu installieren: 

root # transactional-update pkg install package_1
root # transactional-update --continue 13 pkg install package_2

Die Option --continue [num] ruft snapper create --from auf. Weitere Informationen hierzu finden Sie in Abschnitt 7.6.2, „Erstellen von Snapshots“.

cleanup

Wenn das aktuelle root-Dateisystem mit dem aktiven root-Dateisystem identisch ist (nach einem Reboot, bevor transactional-update einen neuen Snapshot mit Aktualisierungen erstellt), wird für alle alten Snapshots ohne Bereinigungsalgorithmus ein Bereinigungsalgorithmus festgelegt. Dadurch wird sichergestellt, dass alte Snapshots von Snapper gelöscht werden. (Weitere Informationen finden Sie im Abschnitt zu Bereinigungsalgorithmen in Snapper (8).) Damit werden auch alle /etc-Overlay-Verzeichnisse ohne Verweis (und somit nicht verwendet) in /var/lib/overlay entfernt: 

root # transactional-update cleanup
pkg in/install

Installiert einzelne Paket aus den verfügbaren Kanälen mit dem Kommando zypper install. Mit diesem Kommando werden auch PTF(Program Temporary Fix)-RPM-Dateien installiert. 

root # transactional-update pkg install package_name

oder 

root # transactional-update pkg install rpm1 rpm2
pkg rm/remove

Entfernt einzelne Pakete vom aktiven Snapshot mit dem Kommando zypper remove. Mit diesem Kommando werden auch PTF-RPM-Dateien entfernt. 

root # transactional-update pkg remove package_name
pkg up/update

Aktualisiert einzelne Pakete vom aktiven Snapshot mit dem Kommando zypper update. Es können nur Pakete aktualisiert werden, die Teil des Snapshots des Basisdateisystems sind. 

root # transactional-update pkg remove package_name
up/update

Wenn neue Aktualisierungen verfügbar sind, wird ein neuer Snapshot erstellt und mit zypper up/update der Snapshot aktualisiert. 

root # transactional-update up
dup

Wenn neue Aktualisierungen verfügbar sind, wird ein neuer Snapshot erstellt und mit zypper dup –no-allow-vendor-change der Snapshot aktualisiert. Der Snapshot wird anschließend aktiviert und wird nach einem Reboot zum neuen root-Dateisystem. 

root # transactional-update dup
patch

Wenn neue Aktualisierungen verfügbar sind, wird ein neuer Snapshot erstellt und mit zypper patch der Snapshot aktualisiert. 

root # transactional-update patch
rollback

Damit wird das Standard-Subvolume festgelegt. In Systemen mit einem Schreiben-Lesen-Dateisystem wird snapper rollback aufgerufen. In einem Nur-Lesen-Dateisystem ohne Argument wird das aktuelle System als neues standardmäßiges root-Dateisystem festgelegt. Wenn Sie eine Zahl angeben, wird dieser Snapshot als das standardmäßige root-Dateisystem verwendet. In einem Nur-Lesen-Dateisystem werden keine zusätzlichen Snapshots erstellt. 

root # transactional-update rollback snapshot_number
grub.cfg

Damit wird eine neue GRUB2-Konfiguration erstellt. Manchmal muss die Boot-Konfiguration angepasst werden, beispielsweise durch Hinzufügen zusätzlicher Kernel-Parameter. Bearbeiten Sie /etc/default/grub, führen Sie transactional-update grub.cfg aus und booten Sie dann neu, um die Änderung zu aktivieren. Sie müssen sofort einen Reboot ausführen, da ansonsten die neue GRUB2-Konfiguration bei der nächsten Transaktionsaktualisierung mit dem Standardwert überschrieben wird. 

root # transactional-update grub.cfg
reboot

Dieser Parameter löst nach dem Abschluss der Aktion einen Reboot aus. 

root # transactional-update dup reboot
--help

Damit wird ein Hilfe-Bildschirm mit Optionen und Unterkommandos gedruckt. 

root # transactional-update --help

9.5 Fehlersuche

 

Führen Sie bei einem fehlerhaften Upgrade supportconfig aus, um Protokolldaten zu erfassen. Übermitteln Sie die resultierenden Dateien einschließlich /var/log/transactional-update.log an den SUSE Support.

10 Remote-Grafiksitzungen mit VNC

 

Über VNC (Virtual Network Computing) haben Sie über einen Grafik-Desktop Zugriff auf einen Remote-Rechner und können Remote-Grafikanwendungen ausführen. VNC ist plattformunabhängig und greift auf den Remote-Rechner über ein beliebiges Betriebssystem zu. In diesem Kapitel wird beschrieben, wie mit den Desktop-Clients vncviewer und Remmina eine Verbindung zu einem VNC-Server hergestellt und wie ein VNC-Server betrieben wird.

SUSE Linux Enterprise Server unterstützt zwei verschiedene Arten von VNC-Sitzungen: einmalige Sitzungen, die so lange „aktiv“ sind, wie die VNC-Verbindung zum Client besteht, und permanente Sitzungen, die so lange „aktiv“ sind, bis sie explizit beendet werden.

Ein VNC-Server kann beide Sitzungen gleichzeitig auf verschiedenen Ports bieten, eine geöffnete Sitzung kann jedoch nicht von einem Typ in den anderen konvertiert werden.

10.1 Der vncviewer-Client

 

Um eine Verbindung zu einem VNC-Dienst herzustellen, der von einem Server bereitgestellt wird, ist ein Client erforderlich. Der Standard-Client in SUSE Linux Enterprise Server ist vncviewer, der im Paket tigervnc bereitgestellt wird.

10.1.1 Verbinden mithilfe der vncviewer-CLI

 

Mit folgendem Kommando können Sie den VNC-Viewer starten und eine Sitzung mit dem Server initiieren: 

tux > vncviewer jupiter.example.com:1

Anstelle der VNC-Anmeldenummer können Sie auch die Portnummer mit zwei Doppelpunkten angeben: 

tux > vncviewer jupiter.example.com::5901
Anmerkung
Anmerkung: Anzeige- und Portnummer

Die im VNC-Client angegebene Anzeige- oder Portnummer muss mit der Anzeige- oder Portnummer übereinstimmen, die durch den Befehl vncserver auf dem Zielcomputer ausgewählt wird. Weitere Informationen finden Sie unter Abschnitt 10.4, „Konfigurieren von permanenten VNC-Serversitzungen“.

10.1.2 Verbinden mithilfe der vncviewer-GUI

 

Wenn vncviewer ausgeführt wird, ohne --listen oder einen Host für die Verbindung anzugeben, wird ein Fenster zur Eingabe von Verbindungsinformationen angezeigt. Geben Sie den Host in das Feld VNC server (VNC-Server) wie in Abschnitt 10.1.1, „Verbinden mithilfe der vncviewer-CLI“ ein und klicken Sie auf Connect (Verbinden).

vncviewer fordert die Angabe von Verbindungsinformationen
Abbildung 10.1: vncviewer
 

10.1.3 Benachrichtigungen zu unverschlüsselten Verbindungen

 

Das VNC-Protokoll unterstützt verschiedene Arten von verschlüsselten Verbindungen, nicht zu verwechseln mit Passwortauthentifizierung. Wenn eine Verbindung kein TLS verwendet, wird der Text „(Connection not encrypted!)“ (Verbindung nicht verschlüsselt!) im Fenstertitel des VNC-Viewers angezeigt.

10.2 Remmina: Remote-Desktop-Client

 

Der moderne Remote-Desktop-Client Remmina bietet einen großen Funktionsumfang. Es werden mehrere Zugriffsmethoden unterstützt, z. B. VNC, SSH, RDP oder Spice.

10.2.1 Installation

 

Wenn Sie mit Remmina arbeiten möchten, prüfen Sie, ob das Paket remmina auf dem System installiert ist, und holen Sie die Installation ggf. nach. Denken Sie daran, auch das VNC-Plugin für Remmina zu installieren: 

root # zypper in remmina remmina-plugin-vnc

10.2.2 Hauptfenster

 

Starten Sie Remmina mit dem Befehl remmina.

Hauptfenster von Remmina
Abbildung 10.2: Hauptfenster von Remmina
 

Das Hauptanwendungsfenster enthält eine Liste der gespeicherten Remote-Sitzungen. Hier können Sie eine neue Remote-Sitzung hinzufügen und speichern, eine neue Sitzung per Schnellstart beginnen (also ohne zu speichern), eine zuvor gespeicherte Sitzung starten oder die globalen Einstellungen für Remmina festlegen.

10.2.3 Hinzufügen von Remote-Sitzungen

 

Mit Add new session oben links im Hauptfenster können Sie eine neue Remote-Sitzung hinzufügen und speichern. Das Fenster Remote Desktop Preference wird geöffnet.

Remote Desktop Preference
Abbildung 10.3: Remote Desktop Preference
 

Füllen Sie die Felder für das soeben hinzugefügte Remote-Sitzungsprofil aus. Die wichtigsten sind:

Name

Name des Profils. Wird im Hauptfenster angezeigt.

Protokoll

Protokoll für die Verbindung zur Remote-Sitzung, z. B. VNC.

Server

IP- oder DNS-Adresse und Anzeigenummer des Remote-Servers.

Benutzername, Benutzerpasswort

Berechtigungsnachweis für die Remote-Authentifizierung. Soll keine Authentifizierung erfolgen, geben Sie hier nichts ein.

Farbtiefe, Qualität

Wählen Sie die optimalen Optionen für Ihre Verbindungsgeschwindigkeit und -qualität.

Auf der Registerkarte Advanced finden Sie weitere Einstellungen.

Tipp
Tipp: Verschlüsselung deaktivieren

Wenn die Kommunikation zwischen dem Client und dem Remote-Server nicht verschlüsselt ist, aktivieren Sie die Option Disable encryption. Ansonsten kommt es zu Verbindungsfehlern.

Auf der Registerkarte SSH finden Sie erweiterte Optionen für SSH-Tunneling und Authentifizierung.

Bestätigen Sie die Eingabe mit Speichern. Das neue Profil wird im Hauptfenster angezeigt.

10.2.4 Starten von Remote-Sitzungen

 

Sie können entweder eine zuvor gespeicherte Sitzung starten oder eine Remote-Sitzung per Schnellstart beginnen (also ohne die Verbindungsdetails zu speichern).

10.2.4.1 Schnellstart von Remote-Sitzungen

 

Mit dem Dropdown-Feld und dem Textfeld oben im Hauptfenster können Sie eine Remote-Sitzung per Schnellstart beginnen, ohne die Verbindungsdetails anzugeben und zu speichern.

Schnellstart
Abbildung 10.4: Schnellstart
 

Wählen Sie das Kommunikationsprotokoll im Dropdown-Feld aus (z. B. „VNC“). Geben Sie dann die DNS-oder IP-Adresse des VNC-Servers ein, gefolgt von einem Doppelpunkt und einer Anzeigenummer, und bestätigen Sie mit Eingabetaste.

10.2.4.2 Öffnen von gespeicherten Remote-Sitzungen

 

Zum Öffnen einer bestimmten Remote-Sitzung doppelklicken Sie in der Sitzungsliste auf diese Sitzung.

10.2.4.3 Fenster der Remote-Sitzungen

 

Die Remote-Sitzungen werden in Registerkarten eines separaten Fensters geöffnet. Jede Registerkarte enthält eine Sitzung. Über die Symbolleiste links im Fenster können Sie die Fenster/Sitzungen verwalten, zum Beispiel den Vollbildmodus aktivieren/deaktivieren, die Fenstergröße an die Anzeigegröße der Sitzung anpassen, bestimmte Tastatureingaben an die Sitzung senden, Bildschirmfotos der Sitzung aufnehmen oder die Bildqualität festlegen.

Remmina-Remote-Sitzung mit Anzeige
Abbildung 10.5: Remmina-Remote-Sitzung mit Anzeige
 

10.2.5 Bearbeiten, Kopieren und Löschen gespeicherter Sitzungen

 

Zum Bearbeiten einer gespeicherten Remote-Sitzung klicken Sie mit der rechten Maustaste im Hauptfenster von Remmina auf den Namen der Sitzung und wählen Sie Edit. Eine Beschreibung der relevanten Felder finden Sie unter Abschnitt 10.2.3, „Hinzufügen von Remote-Sitzungen“.

Zum Kopieren einer gespeicherten Remote-Sitzung klicken Sie mit der rechten Maustaste im Hauptfenster von Remmina auf den Namen der Sitzung und wählen Sie Copy. Ändern Sie im Fenster Remote Desktop Preference den Name des Profils, passen Sie optional die relevanten Optionen an und bestätigen Sie mit Save.

Zum Löschen einer gespeicherten Remote-Sitzung klicken Sie mit der rechten Maustaste im Hauptfenster von Remmina auf den Namen der Sitzung und wählen Sie Delete. Bestätigen Sie das nächste Dialogfeld mit Yes.

10.2.6 Ausführen von Remote-Sitzungen über die Befehlszeile

 

Mit der folgenden Syntax öffnen Sie eine Remote-Sitzung über die Befehlszeile oder aus einer Stapeldatei heraus, ohne zunächst das Hauptanwendungsfenster zu öffnen: 

 tux > remmina -c profile_name.remmina

Die Profildateien von Remmina werden im Verzeichnis .local/share/remmina/ in Ihrem Benutzerverzeichnis gespeichert. Zum Ermitteln der Profildatei für die zu öffnende Sitzung starten Sie Remmina und klicken Sie im Hauptfenster auf den Sitzungsnamen. Der Pfad zur Profildatei wird in der Statuszeile unten im Fenster angezeigt.

Pfad zur Profildatei
Abbildung 10.6: Pfad zur Profildatei
 

Wenn Remmina nicht ausgeführt wird, können Sie den Namen der Profildatei durch einen aussagekräftigeren Dateinamen ersetzen (z. B. sle15.remmina). Sie können sogar die Profildatei in Ihr Benutzerverzeichnis kopieren und mit dem Befehl remmina -c direkt aus diesem Verzeichnis heraus ausführen.

10.3 Konfigurieren von einmaligen Sitzungen am VNC-Server

 

Eine einmalige Sitzung wird vom Remote-Client initiiert. Sie startet einen grafischen Anmeldebildschirm auf dem Server. Auf diese Weise können Sie den Benutzer auswählen, der die Sitzung starten soll sowie, sofern vom Anmeldungsmanager unterstützt, die Desktop-Umgebung. Wenn Sie die Client-Verbindung, beispielsweise eine VNC-Sitzung, beenden, werden auch alle während der Sitzung gestarteten Anwendungen beendet. Einmalige VNC-Sitzungen können nicht freigegeben werden, Sie können jedoch mehrere Sitzungen gleichzeitig auf demselben Host ausführen.

Vorgehen 10.1: Aktivieren von einmaligen VNC-Sitzungen
 

  1. Starten Sie YaST › Netzwerkdienste › Verwaltung von entfernten Rechnern aus (remote) (VNC).

  2. Aktivieren Sie die Option Allow Remote Administration Without Session Management (Verwaltung von entfernten Rechnern aus (remote) ohne Sitzungsverwaltung zulassen).

  3. Aktivieren Sie die Option Enable access using a web browser (Zugriff über Webbrowser aktivieren), wenn der Zugriff auf die VNC-Sitzung über einen Webbrowser-Fenster erfolgen soll.

  4. Aktivieren Sie bei Bedarf Firewall-Port öffnen (wenn Ihre Netzwerkschnittstelle z. B. so konfiguriert ist, dass sie in der externen Zone liegt). Wenn Sie mehrere Netzwerkschnittstellen haben, beschränken Sie das Öffnen der Firewall-Ports über Firewall-Details auf eine bestimmte Schnittstelle.

  5. Bestätigen Sie die Einstellungen mit Weiter.

  6. Falls zu dem Zeitpunkt noch nicht alle erforderlichen Pakete verfügbar sind, müssen Sie der Installation der fehlenden Pakete zustimmen.

    Tipp
    Tipp: Neustart des Anzeigemanagers

    YaST nimmt Änderungen an den Einstellungen des Anzeigemanagers vor. Diese Änderungen treten erst dann in Kraft, wenn Sie sich aus der aktuellen grafischen Sitzung abmelden und den Anzeigemanager neu starten.

Fernverwaltung
Abbildung 10.7: Fernverwaltung
 

10.3.1 Verfügbare Konfigurationen

 

Die Standardkonfiguration von SUSE Linux Enterprise Server stellt Sitzungen mit einer Auflösung von 1024 x 768 Pixeln und einer Farbtiefe von 16 Bit bereit. Die Sitzungen sind an Port 5901 für „reguläre“ VNC-Viewer (entspricht VNC-Display 1) und an Port 5801 für Webbrowser verfügbar.

Weitere Konfigurationen können an anderen Ports verfügbar gemacht werden, siehe Abschnitt 10.3.3, „Konfigurieren einmaliger VNC-Sitzungen“

VNC-Anzeigenummern und X-Anzeigenummern sind bei einmaligen Sitzungen unabhängig. Eine VNC-Anzeigenummer wird manuell jeder Konfiguration zugewiesen, die vom Server unterstützt wird (:1 im obigen Beispiel). Immer, wenn eine VNC-Sitzung mit einer der Konfigurationen initiiert wird, erhält sie automatisch eine freie X-Display-Nummer.

Standardmäßig versuchen sowohl der VNC-Client als auch der Server, über ein selbstsigniertes SSL-Zertifikat sicher zu kommunizieren, das nach der Installation erzeugt wird. Verwenden Sie wahlweise das Standardzertifikat oder ersetzen Sie es durch Ihr eigenes Zertifikat. Wenn Sie das selbstsignierte Zertifikat verwenden, müssen Sie vor dem ersten Herstellen einer Verbindung die Signatur bestätigen – sowohl im VNC-Viewer als auch im Webbrowser.

10.3.2 Initiieren einer einmaligen VNC-Sitzung

 

Um eine Verbindung zu einer einmaligen VNC-Sitzung herzustellen, muss ein VNC-Viewer installiert sein, lesen Sie hierzu auch Abschnitt 10.1, „Der vncviewer-Client“. Alternativ können Sie einen JavaScript-fähigen Webbrowser verwenden, um die VNC-Sitzung anzuzeigen. Geben Sie hierzu folgende URL ein: http://jupiter.example.com:5801.

10.3.3 Konfigurieren einmaliger VNC-Sitzungen

 

Sie können diesen Abschnitt überspringen, wenn Sie die Standardkonfiguration nicht ändern müssen bzw. möchten.

Einmalige VNC-Sitzungen werden über den systemd-Socket xvnc.socket gestartet. Standardmäßig bietet sie sechs Konfigurationsblöcke: drei für VNC-Viewer (vnc1 bis vnc3) und drei für einen JavaScript-Client (vnchttpd1 bis vnchttpd3). Standardmäßig sind nur vnc1 und vnchttpd1 aktiv.

Mit dem folgenden Befehl aktivieren Sie den VNC-Server-Socket beim Booten: 

tux > sudo  systemctl enable xvnc.socket

Mit dem folgenden Befehl starten Sie den Socket sofort: 

tux > sudo  systemctl start xvnc.socket

Der Xvnc-Server kann mit der Option server_args konfiguriert werden. Eine Liste der Optionen finden Sie unter Xvnc --help.

Achten Sie beim Hinzufügen benutzerdefinierter Konfigurationen darauf, keine Ports zu verwenden, die bereits von anderen Konfigurationen, anderen Services oder bestehenden permanenten VNC-Sitzungen auf demselben Host verwendet werden.

Aktivieren Sie Konfigurationsänderungen mit folgendem Kommando: 

tux > sudo systemctl reload xvnc.socket
Wichtig
Wichtig: Firewall und VNC-Ports

Wenn Sie die entfernte Verwaltung wie in Prozedur 10.1, „Aktivieren von einmaligen VNC-Sitzungen“ beschrieben aktivieren, werden die Ports 5801 und 5901 in der Firewall geöffnet. Wenn die Netzwerkschnittstelle, über die die VNC-Sitzung bereitgestellt wird, durch eine Firewall geschützt wird, müssen Sie die entsprechenden Ports manuell öffnen, wenn Sie zusätzliche Ports für VNC-Sitzungen aktivieren. Eine Anleitung dazu finden Sie unter Book “Security and Hardening Guide”, Chapter 23 “Masquerading and firewalls”.

10.4 Konfigurieren von permanenten VNC-Serversitzungen

 

Auf eine permanente Sitzung kann gleichzeitig von mehreren Clients zugegriffen werden. Dies eignet sich ideal für Demozwecke, bei denen ein Client den vollen Zugriff und alle anderen einen reinen Anzeigezugriff haben. Weiter eignet sich dies für Schulungssitzungen, bei denen der Schulungsleiter einen Zugriff auf den Desktop des Teilnehmers benötigt.

Tipp
Tipp: Verbindung zu einer permanenten VNC-Sitzung herstellen

Um eine Verbindung zu einer permanenten VNC-Sitzung herzustellen, muss ein VNC-Viewer installiert sein. Weitere Informationen finden Sie im Abschnitt 10.1, „Der vncviewer-Client“. Alternativ können Sie einen JavaScript-fähigen Webbrowser verwenden, um die VNC-Sitzung anzuzeigen. Geben Sie hierzu folgende URL ein: http://jupiter.example.com:5801.

Es gibt zwei Arten von permanenten VNC-Sitzungen:

10.4.1 Mit vncserver initiierte VNC-Sitzung

 

Diese Art einer permanenten VNC-Sitzung wird auf dem Server initiiert. Die Sitzung und sämtliche in dieser Sitzungsausführung gestarteten Anwendungen werden ungeachtet der Client-Verbindungen so lange ausgeführt, bis die Sitzung beendet wird. Der Zugriff auf permanente Sitzungen wird durch zwei mögliche Arten von Passwörtern geschützt:

  • ein reguläres Passwort, das den vollen Zugriff ermöglicht, oder

  • ein optionales Passwort, das keinen interaktiven Zugriff ermöglicht und nur eine Anzeige liefert.

Eine Sitzung kann mehrere Client-Verbindungen beider Arten gleichzeitig haben.

Vorgehen 10.2: Starten einer permanenten VNC-Sitzung mit vncserver
 

  1. Öffnen Sie eine Shell uns stellen Sie sicher, dass Sie als der Benutzer angemeldet sind, der Eigentümer der VNC-Sitzung sein soll.

  2. Wenn die Netzwerkschnittstelle, über die die VNC-Sitzung bereitgestellt wird, durch eine Firewall geschützt wird, müssen Sie die von Ihrer Sitzung verwendeten Ports manuell in der Firewall öffnen. Wenn Sie mehrere Sitzungen starten, können Sie alternativ einen Portbereich öffnen. Details zur Konfiguration der Firewall finden Sie im Book “Security and Hardening Guide”, Chapter 23 “Masquerading and firewalls”.

    vncserver verwendet die Port 5901 für Display :1, 5902 für Display :2 usw. Bei permanenten Sitzungen haben das VNC-Display und das X-Display normalerweise dieselbe Nummer.

  3. Geben Sie folgendes Kommando ein, um eine Sitzung mit einer Auflösung von 1024x768 Pixel und einer Farbtiefe von 16 Bit zu starten: 

    vncserver -alwaysshared -geometry 1024x768 -depth 16

    Das Kommando vncserver verwendet, sofern keine Display-Nummer angegeben ist, eine freie Display-Nummer und gibt seine Auswahl aus. Weitere Optionen finden Sie mit man 1 vncserver.

Bei der erstmaligen Ausführung von vncserver wird nach einem Passwort für den vollständigen Zugriff auf die Sitzung gefragt. Geben Sie gegebenenfalls auch ein Passwort für den reinen Anzeigezugriff auf die Sitzung ein.

Die hier angegebenen Passwörter werden auch für zukünftige Sitzungen verwendet, die durch denselben Benutzer gestartet werden. Sie können mit dem Kommando vncpasswd geändert werden.

Wichtig
Wichtig: Sicherheitsüberlegungen

Achten Sie darauf, dass Ihre Passwörter sicher und ausreichend lang sind (mindestens acht Zeichen). Teilen Sie diese Passwörter niemandem mit.

Beenden Sie, um die Sitzung zu beenden, die Desktopumgebung, die innerhalb der VNC-Sitzung ausgeführt wird über den VNC-Viewer so, wie Sie eine normale lokale X-Sitzung beenden würden.

Wenn Sie eine Sitzung lieber manuell beenden, öffnen Sie eine Shell auf dem VNC-Server und vergewissern Sie sich, dass Sie als der Benutzer angemeldet ist, der der Eigentümer der zu beendenden VNC-Sitzung ist. Führen Sie das folgende Kommando aus, um die Sitzung zu beenden, die auf Display :1: vncserver -kill :1 ausgeführt wird.

10.4.1.1 Konfigurieren von permanenten VNC-Sitzungen

 

Permanente VNC-Sitzungen können durch Bearbeiten von $HOME/.vnc/xstartup konfiguriert werden. Standardmäßig startet dieses Shell-Skript dieselbe GUI bzw. denselben Fenstermanager, aus dem es gestartet wurde. In SUSE Linux Enterprise Server ist dies entweder GNOME oder IceWM. Wenn Sie beim Starten Ihrer Sitzung einen bestimmten Fenstermanager verwenden möchten, legen Sie die Variable WINDOWMANAGER fest: 

WINDOWMANAGER=gnome vncserver -geometry 1024x768
WINDOWMANAGER=icewm vncserver -geometry 1024x768
Anmerkung
Anmerkung: Eine Konfiguration pro Benutzer

Permanente VNC-Sitzungen werden jeweils nur einmal pro Benutzer konfiguriert. Mehrere von demselben Benutzer gestartete Sitzungen verwenden alle dieselben Start- und Passwortdateien.

10.4.2 Mit vncmanager initiierte VNC-Sitzung

 
Vorgehen 10.3: Aktivieren von permanenten VNC-Sitzungen
 

  1. Starten Sie YaST › Netzwerkdienste › Verwaltung von entfernten Rechnern aus (remote) (VNC).

  2. Aktivieren Sie die Option Allow Remote Administration With Session Management (Verwaltung von entfernten Rechnern aus (remote) mit Sitzungsverwaltung zulassen).

  3. Aktivieren Sie die Option Enable access using a web browser (Zugriff über Webbrowser aktivieren), wenn der Zugriff auf die VNC-Sitzung über ein Webbrowser-Fenster erfolgen soll.

  4. Aktivieren Sie bei Bedarf Firewall-Port öffnen (wenn Ihre Netzwerkschnittstelle z. B. so konfiguriert ist, dass sie in der externen Zone liegt). Wenn Sie mehrere Netzwerkschnittstellen haben, beschränken Sie das Öffnen der Firewall-Ports über Firewall-Details auf eine bestimmte Schnittstelle.

  5. Bestätigen Sie die Einstellungen mit Weiter.

  6. Falls zu dem Zeitpunkt noch nicht alle erforderlichen Pakete verfügbar sind, müssen Sie der Installation der fehlenden Pakete zustimmen.

    Tipp
    Tipp: Neustart des Anzeigemanagers

    YaST nimmt Änderungen an den Einstellungen des Anzeigemanagers vor. Diese Änderungen treten erst dann in Kraft, wenn Sie sich aus der aktuellen grafischen Sitzung abmelden und den Anzeigemanager neu starten.

10.4.2.1 Konfigurieren von permanenten VNC-Sitzungen

 

Sobald Sie die VNC-Sitzungsverwaltung gemäß Prozedur 10.3, „Aktivieren von permanenten VNC-Sitzungen“ aktiviert haben, können Sie wie gewohnt eine Verbindung zur Remote-Sitzung über den VNC-Viewer herstellen, z. B. vncviewer oder Remmina. Der Anmeldebildschirm wird geöffnet. Nach erfolgter Anmeldung wird das VNC-Symbol in der Taskleiste der Desktop-Umgebung angezeigt. Zum Öffnen des Fensters VNC-Sitzung klicken Sie auf das Symbol. Falls das Fenster nicht geöffnet wird oder Ihre Desktop-Umgebung keine Symbole in der Task-Leiste unterstützt, führen Sie vncmanager-controller manuell aus.

VNC-Sitzungseinstellungen
Abbildung 10.8: VNC-Sitzungseinstellungen
 

Verschiedene Einstellungen beeinflussen das Verhalten der VNC-Sitzung:

Nicht persistent, privat

Dies entspricht einer einmaligen Sitzung. Diese ist für andere nicht sichtbar und wird beendet, sobald Sie die Verbindung zur Sitzung trennen. Weitere Informationen finden Sie unter Abschnitt 10.3, „Konfigurieren von einmaligen Sitzungen am VNC-Server“.

Permanent, sichtbar

Die Sitzung ist für andere Benutzer sichtbar und wird weiter ausgeführt, auch wenn Sie die Verbindung zur Sitzung trennen.

Name der Sitzung

Geben Sie den Namen der permanenten Sitzung an, sodass sie beim Wiederherstellen der Verbindung eindeutig erkennbar ist.

Kein Passwort erforderlich

Die Sitzung ist frei zugänglich, ohne dass die Benutzer sich mit ihrem Berechtigungsnachweis anmelden müssen.

Benutzeranmeldung erforderlich

Zum Zugriff auf die Sitzung müssen Sie sich mit einem gültigen Benutzernamen und Passwort anmelden. Die gültigen Benutzernamen werden im Textfeld Zulässige Benutzer angezeigt.

Nur jeweils einen Client zulassen

Mehrere Benutzer können nicht gleichzeitig der permanenten Sitzung beitreten.

Mehrere Clients gleichzeitig zulassen

Mehrere Benutzer können gleichzeitig der permanenten Sitzung beitreten. Nützlich für Remote-Präsentationen oder Schulungssitzungen.

Bestätigen Sie Ihre Auswahl mit OK.

10.4.2.2 Beitreten zu permanenten VNC-Sitzungen

 

Sobald Sie eine permanente VPC-Sitzung gemäß Abschnitt 10.4.2.1, „Konfigurieren von permanenten VNC-Sitzungen“ eingerichtet haben, können Sie dieser Sitzung über den VNC-Viewer beitreten. Nachdem der VNC-Client eine Verbindung zum Server aufgebaut hat, werden Sie gefragt, ob Sie eine neue Sitzung erstellen oder der bestehenden Sitzung beitreten möchten:

Beitreten zu einer permanenten VNC-Sitzung
Abbildung 10.9: Beitreten zu einer permanenten VNC-Sitzung
 

Wenn Sie auf den Namen der bestehenden Sitzung klicken, werden Sie ggf. aufgefordert, Ihren Berechtigungsnachweis anzugeben, abhängig von den Einstellungen für die dauerhafte Sitzung.

10.5 Konfigurieren der Verschlüsselung am VNC-Server

 

Wenn der VNC-Server ordnungsgemäß eingerichtet ist, wird die gesamte Kommunikation zwischen dem VNC-Server und dem Client verschlüsselt. Die Authentifizierung wird zu Beginn der Sitzung vorgenommen. Die eigentliche Datenübertragung beginnt erst danach.

Die Sicherheitsoptionen für einmalige und für permanente VNC-Sitzungen werden mit dem Parameter -securitytypes des Befehls /usr/bin/Xvnc in der Zeile server_args konfiguriert. Der Parameter -securitytypes bestimmt sowohl die Authentifizierungsmethode als auch die Verschlüsselung. Hier stehen die folgenden Optionen zur Auswahl:

Authentifizierungen
 
None, TLSNone, x509None

Keine Authentifizierung.

VncAuth, TLSVnc, x509Vnc

Authentifizierung mit benutzerdefiniertem Passwort.

Plain, TLSPlain, x509Plain

Authentifizierung mit Überprüfung des Benutzerpassworts mit PAM.

Verschlüsselungen
 
None, vncAuth, Plain

Keine Verschlüsselung.

TLSNone, TLSVnc, TLSPlain

Anonyme TLS-Verschlüsselung. Alle Angaben werden verschlüsselt; auf dem Remote-Host erfolgt jedoch keine Überprüfung. Damit sind Sie gegen passive Angreifer geschützt, nicht jedoch gegen Man-in-the-Middle-Angreifer.

x509None, x509Vnc, x509Plain

TLS-Verschlüsselung mit Zertifikat. Wenn Sie ein selbstsigniertes Zertifikat heranziehen, werden Sie bei der ersten Verbindung aufgefordert, dieses Zertifikat zu bestätigen. Bei weiteren Verbindungen erhalten Sie nur dann eine Warnung, wenn das Zertifikat geändert wurde. So sind Sie gegen alle Angreifer geschützt, ausgenommen Man-in-the-Middle-Angreifer bei der ersten Verbindung (ähnlich wie bei der typischen SSH-Verwendung). Wenn Sie ein Zertifikat heranziehen, das von einer Zertifizierungsstelle signiert wurde und das mit dem Computernamen übereinstimmt, erzielen Sie praktisch uneingeschränkte Sicherheit (ähnlich wie bei der typischen HTTPS-Verwendung).

Tipp
Tipp: Pfad zum Zertifikat und zum Schlüssel

Bei der X509-gestützten Verschlüsselung müssen Sie den Pfad zum X509-Zertifikat/-Schlüssel mit den Optionen -X509Cert und -X509Key angeben.

Wenn Sie mehrere Sicherheitstypen angeben (jeweils durch Komma getrennt), wird der erste Typ herangezogen, der sowohl vom Client als auch vom Server unterstützt wird. So können Sie die opportunistische Verschlüsselung auf dem Server konfigurieren. Dies ist von Nutzen, wenn VNC-Clients unterstützt werden sollen, die ihrerseits keine Verschlüsselung unterstützen.

Auf dem Client können Sie außerdem die zulässigen Sicherheitstypen angeben, sodass ein Downgrade-Angriff vermieden wird, wenn Sie eine Verbindung zu einem Server herstellen, auf dem bekanntermaßen die Verschlüsselung aktiviert ist. (Der VNC-Viewer zeigt in diesem Fall allerdings die Meldung „Verbindung nicht verschlüsselt!“ ).

11 Kopieren von Dateien mit RSync

 

Viele moderne Benutzer arbeiten heutzutage gleich mit mehreren Computern: Computer daheim und am Arbeitsplatz, Laptop, Smartphone oder Tablet. Damit wird die Synchronisierung von Dateien und Dokumenten über mehrere Geräte wichtiger als je zuvor.

Warnung
Warnung: Risiko des Datenverlusts

Bevor Sie ein Synchronisierungstool starten, machen Sie sich mit dessen Funktionen und Optionen vertraut. Sichern Sie in jedem Fall wichtige Dateien.

11.1 Konzeptübersicht

 

Sollen große Datenmengen über eine langsame Netzwerkverbindung synchronisiert werden, bietet Rsync eine zuverlässige Methode, mit der ausschließlich die Änderungen in den Dateien übermittelt werden. Dies betrifft nicht nur Textdateien, sondern auch binäre Dateien. Um die Unterschiede zwischen Dateien zu erkennen, teilt rsync die Dateien in Blöcke auf und berechnet Prüfsummen zu diesen Blöcken.

Zum Erkennen der Änderungen ist eine gewisse Rechenleistung erforderlich. Die Computer auf beiden Seiten müssen daher ausreichende Ressourcen aufweisen (auch ausreichend RAM).

Rsync ist insbesondere dann von Nutzen, wenn große Datenmengen mit kleinen Änderungen in regelmäßigen Abständen übermittelt werden sollen. Dies ist häufig bei Sicherungskopien der Fall. Rsync eignet sich auch zum Spiegeln von Staging-Servern, mit denen komplette Verzeichnisbaumstrukturen von Webservern auf einem Webserver in einer DMZ gespeichert werden.

Trotz seines Namens ist Rsync kein Synchronisierungswerkzeug. Rsync ist ein Werkzeug, das Daten jeweils nur in eine einzige Richtung kopiert, nicht in beide Richtungen. Etwas anderes ist damit nicht möglich. Wenn Sie ein bidirektionales Werkzeug benötigen, mit dem Quelle und Ziel synchronisiert werden, verwenden Sie Csync.

11.2 Einfache Syntax

 

Für das Befehlszeilenwerkzeug Rsync gilt die folgende grundlegende Syntax: 

rsync [OPTION] SOURCE [SOURCE]... DEST

Sie können Rsync auf jedem lokalen Computer oder Remote-Computer verwenden, sofern Sie die erforderlichen Zugriffs- und Schreibrechte besitzen. Es können mehrere SOURCE-Einträge vorliegen. Die Platzhalter SOURCE und DEST können durch Pfade und/oder durch URLs ersetzt werden.

Die folgenden Rsync-Optionen werden am häufigsten verwendet:

-v

Gibt einen ausführlicheren Text zurück

-a

Archivmodus; kopiert Dateien rekursiv und behält die Zeitstempel, das Benutzer-/Gruppeneigentum, die Dateiberechtigungen und die symbolischen Links bei

-z

Komprimiert die übermittelten Daten

Anmerkung
Anmerkung: Anzahl der nachgestellten Schrägstriche

Beim Arbeiten mit Rsync sind die nachgestellten Schrägstriche besonders zu beachten. Ein nachgestellter Schrägstrich nach dem Verzeichnis bezeichnet den Inhalt des Verzeichnisses. Die Angabe ohne nachgestellten Schrägstrich bezeichnet das Verzeichnis selbst.

11.3 Lokales Kopieren von Dateien und Verzeichnissen

 

In der nachfolgenden Beschreibung wird vorausgesetzt, dass der aktuelle Benutzer Schreibrechte für das Verzeichnis /var/backup besitzt. Mit dem folgenden Befehl kopieren Sie eine einzelne Datei aus einem Verzeichnis auf dem Computer in einen anderen Pfad: 

tux > rsync -avz backup.tar.xz /var/backup/

Die Datei backup.tar.xz wird in das Verzeichnis /var/backup/ kopiert; der absolute Pfad lautet /var/backup/backup.tar.xz.

Denken Sie daran, den nachgestellten Schrägstrich nach dem Verzeichnis /var/backup/ anzugeben! Wenn Sie den Schrägstrich nicht einfügen, wird die Datei backup.tar.xz in /var/backup kopiert (also in eine Datei), nicht in das Verzeichnis /var/backup/!

Verzeichnisse werden auf ähnliche Weise kopiert wie einzelne Dateien. Im folgenden Beispiel wird das Verzeichnis tux/ mit dessen Inhalt in das Verzeichnis /var/backup/ kopiert: 

tux > rsync -avz tux /var/backup/

Die Kopie befindet sich im absoluten Pfad /var/backup/tux/.

11.4 Remote-Kopieren von Dateien und Verzeichnissen

 

Das Rsync-Werkzeug muss auf beiden Computern vorhanden sein. Zum Kopieren von Dateien aus Remote-Verzeichnissen oder in diese benötigen Sie eine IP-Adresse oder einen Domänennamen. Ein Benutzername ist optional, wenn die aktuellen Benutzernamen auf dem lokalen Computer und dem Remote-Computer identisch sind.

Mit dem folgenden Befehl kopieren Sie die Datei file.tar.xz vom lokalen Host auf den Remote-Host 192.168.1.1 mit identischen Benutzern (lokal und remote): 

tux > rsync -avz file.tar.xz  tux@192.168.1.1:

Alternativ sind auch die folgenden Befehle möglich und äquivalent: 

tux > rsync -avz file.tar.xz 192.168.1.1:~
tux > rsync -avz file.tar.xz 192.168.1.1:/home/tux

In allen Fällen mit Standardkonfiguration werden Sie aufgefordert, den Passwortsatz des Remote-Benutzers einzugeben. Mit diesem Befehl wird file.tar.xz in das Benutzerverzeichnis des Benutzers tux kopiert (in der Regel /home/tux).

Verzeichnisse werden im Remote-Verfahren auf ähnliche Weise kopiert wie lokal. Im folgenden Beispiel wird das Verzeichnis tux/ mit dessen Inhalt in das Remote-Verzeichnis /var/backup/ auf dem Host 192.168.1.1 kopiert: 

tux > rsync -avz tux 192.168.1.1:/var/backup/

Unter der Voraussetzung, dass Sie Schreibrechte auf dem Host 192.168.1.1 besitzen, befindet sich die Kopie im absoluten Pfad /var/backup/tux.

11.5 Konfigurieren und Verwenden eines Rsync-Servers

 

Rsync kann als Daemon (rsyncd) ausgeführt werden, der den Standardport 873 auf eingehende Verbindungen überwacht. Dieser Daemon kann „Kopierziele“ empfangen.

Mit den nachfolgenden Anweisungen erstellen Sie einen Rsync-Server auf jupiter mit einem backup-Ziel. In diesem Ziel können Sie Ihre Sicherungskopien speichern. So erstellen Sie einen Rsync-Server:

Vorgehen 11.1: Einrichten eines Rsync-Servers
 

  1. Erstellen Sie auf jupiter ein Verzeichnis, in dem alle Sicherungskopien gespeichert werden sollen. In diesem Beispiel wird das Verzeichnis /var/backup verwendet: 

    root # mkdir /var/backup

  2. Legen Sie das Eigentum fest. In diesem Fall ist der Benutzer tux in der Gruppe users der Eigentümer des Verzeichnisses: 

    root # chown tux.users /var/backup

  3. Konfigurieren Sie den rsyncd-Daemon.

    Die Konfigurationsdatei wird in eine Hauptdatei und einige „Module“ aufgeteilt, in denen sich das Sicherungsziel befindet. So können zusätzliche Module später einfacher eingefügt werden. Die globalen Werte können in den Dateien /etc/rsyncd.d/*.inc gespeichert werden, die Module dagegen in den Dateien /etc/rsyncd.d/*.conf:

    1. Erstellen Sie das Verzeichnis /etc/rsyncd.d/: 

      root # mkdir /etc/rsyncd.d/

    2. Tragen Sie die folgenden Zeilen in die Hauptkonfigurationsdatei /etc/rsyncd.conf ein: 

      # rsyncd.conf main configuration file
log file = /var/log/rsync.log
pid file = /var/lock/rsync.lock

&merge /etc/rsyncd.d 1
&include /etc/rsyncd.d 2

      1

      Führt die globalen Werte aus den Dateien /etc/rsyncd.d/*.inc in der Hauptkonfigurationsdatei zusammen.

      2

      Lädt die Module (oder Ziele) aus den Dateien/etc/rsyncd.d/*.conf. Diese Dateien dürfen keine Verweise auf die globalen Werte enthalten.

    3. Legen Sie das Modul (das Sicherungsziel) mit den folgenden Zeilen in der Datei /etc/rsyncd.d/backup.conf an: 

      # backup.conf: backup module
[backup] 1
   uid = tux 2
   gid = users 2
   path = /var/backup 3
   auth users = tux  4
   secrets file = /etc/rsyncd.secrets 5
   comment = Our backup target

      1

      Das backup-Ziel. Geben Sie einen beliebigen Namen ein. Benennen Sie das Ziel nach Möglichkeit entsprechend seinem Zweck und verwenden Sie denselben Namen in der *.conf-Datei.

      2

      Gibt den Benutzer- oder Gruppennamen an, der für die Dateiübertragung herangezogen werden soll.

      3

      Definiert den Pfad, in dem die Sicherungskopien gespeichert werden sollen (aus Schritt 1).

      4

      Gibt eine durch Komma getrennte Liste der zulässigen Benutzer an. In der einfachsten Form enthält diese Liste die Namen der Benutzer, die berechtigt sind, eine Verbindung zu diesem Modul herzustellen. In diesem Fall ist lediglich der Benutzer tux zulässig.

      5

      Gibt den Pfad einer Datei an, die Zeilen mit Benutzernamen und einfachen Passwörtern enthält.

    4. Erstellen Sie die Datei /etc/rsyncd.secrets mit dem folgenden Inhalt und ersetzen Sie PASSPHRASE: 

      # user:passwd
tux:PASSPHRASE

    5. Die Datei darf nur von root gelesen werden können: 

      root # chmod 0600 /etc/rsyncd.secrets

  4. Starten und aktivieren Sie den rsyncd-Daemon: 

    root # systemctl enable rsyncd
root # systemctl start rsyncd

  5. Testen Sie den Zugriff auf den Rsync-Server: 

    tux > rsync jupiter::

    Beispiel für eine Antwort: 

    backup          Our backup target

    Ansonsten prüfen Sie die Konfigurationsdatei-, Firewall- und Netzwerkeinstellungen.

Mit den obigen Schritten wird ein Rsync-Server erstellt, auf dem Sie nun Sicherungskopien speichern können. Im obigen Beispiel wird auch eine Protokolldatei über alle Verbindungen angelegt. Diese Datei wird unter /var/log/rsyncd.log abgelegt. Diese Funktion ist besonders beim Debuggen der Datenübertragungen hilfreich.

Mit dem folgenden Befehl listen Sie den Inhalt des Sicherungsziels auf: 

tux > rsync -avz jupiter::backup

Dieser Befehl listet alle Dateien auf, die auf dem Server im Verzeichnis /var/backup liegen. Diese Anfrage wird auch in der Protokolldatei unter /var/log/rsyncd.log aufgezeichnet. Um die Übertragung tatsächlich zu starten, geben Sie ein Quellverzeichnis an. Verwenden Sie . für das aktuelle Verzeichnis. Mit dem folgenden Befehl wird beispielsweise das aktuelle Verzeichnis auf den Rsync-Sicherungsserver kopiert: 

tux > rsync -avz . jupiter::backup

Standardmäßig werden beim Ausführen von Rsync keine Dateien und Verzeichnisse gelöscht. Soll die Löschung aktiviert werden, müssen Sie die zusätzliche Option --delete angeben. Um sicherzustellen, dass keine neueren Dateien überschrieben werden, kann stattdessen die Option --update angegeben werden. Dadurch entstehende Konflikte müssen manuell aufgelöst werden.

11.6 Weitere Informationen

 
Csync

Bidirektionales Dateisynchronisierungswerkzeug, siehe https://csync.org/.

RSnapshot

Erstellt inkrementelle Sicherungen, siehe https://rsnapshot.org.

Unison

Bidirektionales Dateisynchronisierungswerkzeug – ähnlich wie CSync, jedoch mit grafischer Benutzeroberfläche, siehe https://www.seas.upenn.edu/~bcpierce/unison/.

Rear

Ein Framework für Disaster Recovery. Weitere Informationen hierzu finden Sie im Verwaltungshandbuch der SUSE Linux Enterprise High Availability Extension in Kapitel Disaster Recovery mit Rear (Relax-and-Recover).

Teil II Booten eines Linux-Systems

 
  • 12 Einführung in den Bootvorgang

    • Das Booten eines Linux-Systems umfasst verschiedene Komponenten und Tasks. Nach der Firmware- und Hardware-Initialisierung, die von der Computerarchitektur abhängt, wird der Kernel mithilfe des Bootloaders GRUB 2 gestartet. Anschließend wird der Bootvorgang vollständig vom Betriebssystem gesteuert und über systemd abgewickelt. systemd bietet eine Reihe von „Zielen“, mit denen Konfigurationen für den normalen Gebrauch, für Wartungsarbeiten oder für Notfälle gebootet werden.

  • 13 UEFI (Unified Extensible Firmware Interface)

    • Die UEFI (Unified Extensible Firmware Interface) bildet die Schnittstelle zwischen der Firmware, die sich auf der Systemhardware befindet, allen Hardware-Komponenten des Systems und dem Betriebssystem.

  • 14 Der Bootloader GRUB 2

    • In diesem Kapitel wird die Konfiguration von GRUB 2, dem unter SUSE Linux Enterprise Server verwendeten Bootloader, beschrieben. Diese Anwendung ist der Nachfolger des bisherigen Bootloaders GRUB (nunmehr als „GRUB Legacy“ bezeichnet). GRUB 2 ist seit Version 12 als standardmäßiger Bootloader in SUSE® Linux Enterprise Server eingebunden. Für die Konfiguration der wichtigsten Einstellungen steht ein YaST-Modul bereit. Eine Übersicht über den Bootvorgang finden Sie in Kapitel 12, Einführung in den Bootvorgang. Weitere Informationen zur Unterstützung von Secure Boot finden Sie in Kapitel 13, UEFI (Unified Extensible Firmware Interface).

  • 15 Der Daemon systemd

    • systemd ist für die Initialisierung des Systems verantwortlich und trägt die Prozess-ID 1. systemd wird direkt vom Kernel gestartet und widersteht dem Signal 9, das in der Regel Prozesse beendet. Alle anderen Programme werden entweder direkt von systemd oder von einem seiner untergeordneten Prozesse…

12 Einführung in den Bootvorgang

 

Das Booten eines Linux-Systems umfasst verschiedene Komponenten und Tasks. Nach der Firmware- und Hardware-Initialisierung, die von der Computerarchitektur abhängt, wird der Kernel mithilfe des Bootloaders GRUB 2 gestartet. Anschließend wird der Bootvorgang vollständig vom Betriebssystem gesteuert und über systemd abgewickelt. systemd bietet eine Reihe von „Zielen“, mit denen Konfigurationen für den normalen Gebrauch, für Wartungsarbeiten oder für Notfälle gebootet werden.

12.1 Terminologie

 

In diesem Kapitel werden Begriffe verwendet, die unter Umständen nicht eindeutig sind. Aus diesem Grund stellen wir im Folgenden einige Definitionen bereit:

init

Derzeit gibt es zwei unterschiedliche Prozesse mit dem Namen „init“:

  • den initramfs-Vorgang, mit dem das root-Dateisystem eingehängt wird

  • den Betriebssystemprozess, mit dem alle anderen Prozesse gestartet werden und der über das echte root-Dateisystem ausgeführt wird

In beiden Fällen wird die jeweilige Aufgabe vom Programm systemd ausgeführt. Zunächst wird sie aus dem initramfs ausgeführt, sodass das root-Dateisystem eingehängt wird. Wurde dieser Vorgang erfolgreich abgeschlossen, wird der Vorgang als ursprünglicher Prozess erneut ausgeführt, diesmal aus dem root-Dateisystem. Damit keine Verwirrung entsteht, welcher der beiden systemd-Prozesse gemeint ist, bezeichnen wir den ersten als init auf initramfs und den zweiten als systemd.

initrd/initramfs

Eine initrd (ursprüngliche RAM-Festplatte) ist eine Imagedatei, die ein Image des root-Dateisystems enthält, das vom Kernel geladen und über /dev/ram als temporäres root-Dateisystem eingehängt wird. Für das Einhängen dieses Dateisystems ist ein Dateisystemtreiber erforderlich.

Ab Kernel 2.6.13 wurde initrd durch initramfs (ursprüngliches RAM-Dateisystem) ersetzt, für das kein Dateisystemtreiber eingehängt werden muss. SUSE Linux Enterprise Server nutzt ausschließlich initramfs. Da initramfs jedoch als /boot/initrd gespeichert ist, wird es auch häufig als „initrd“ bezeichnet. In diesem Kapitel verwenden wir ausschließlich den Begriff initramfs.

12.2 Der Linux-Bootvorgang

 

Der Linux-Bootvorgang besteht aus mehreren Phasen, von denen jede einer anderen Komponente entspricht:

  1. Abschnitt 12.2.1, „Initialisierungs- und Bootloader-Phase“

  2. Abschnitt 12.2.2, „Die Kernel-Phase“

  3. Abschnitt 12.2.3, „Die Phase init auf initramfs“

  4. Abschnitt 12.2.4, „Die systemd-Phase“

12.2.1 Initialisierungs- und Bootloader-Phase

 

Während der Initialisierungsphase wird die Computerhardware eingerichtet und die Geräte werden vorbereitet. Dieser Prozess verläuft, abhängig von der Hardwarearchitektur, bei jedem Gerät anders.

SUSE Linux Enterprise Server nutzt für alle Architekturen den Bootloader GRUB 2. Abhängig von Architektur und Firmware ist das Starten des Bootloaders GRUB 2 unter Umständen ein Prozess mit mehreren Schritten. Zweck des Bootloaders ist es, den Kernel und das ursprüngliche RAM-basierte Dateisystem (initramfs) zu laden. Weitere Informationen zu GRUB 2 finden Sie in Kapitel 14, Der Bootloader GRUB 2.

12.2.1.1 Initialisierungs- und Bootloader-Phase auf AArch64 und AMD64/Intel 64

 

Nach dem Einschalten des Computers initialisiert das BIOS oder das UEFI den Bildschirm und die Tastatur und testet den Hauptspeicher. Bis zu dieser Phase greift der Computer nicht auf Massenspeichergeräte zu. Anschließend werden Informationen zum aktuellen Datum, zur aktuellen Uhrzeit und zu den wichtigsten Peripheriegeräten aus den CMOS-Werten geladen. Wenn die Boot-Medien und deren Geometrie erkannt wurden, geht die Systemkontrolle vom BIOS/UEFI an den Bootloader über.

Auf einem mit traditionellem BIOS ausgestatteten Computer kann nur Code des ersten physischen 512-Byte-Datensektors (Master-Boot-Datensatz, MBR) der Boot-Festplatte geladen werden. Nur die minimalistische Version von GRUB 2 passt in den MBR. Seine einzige Aufgabe besteht darin, ein Core-Image von GRUB 2 zu laden, das die Dateisystemtreiber aus der Lücke zwischen MBR und erster Partition (MBR-Partitionstabelle) oder der BIOS-Boot-Partition (GPT-Partitionstabelle) enthält. Dieses Image enthält Dateisystemtreiber und ist somit in der Lage, auf /boot im root-Dateisystem zuzugreifen. /boot enthält zusätzliche Module für den Core von GRUB 2 sowie den Kernel und das initramfs-Image. Sobald GRUB 2 Zugriff auf diese Partition hat, lädt es den Kernel und das initramfs-Image in den Speicher und übergibt die Steuerung an den Kernel.

Wird ein BIOS-System aus einem verschlüsselten Dateisystem gebootet, das über eine verschlüsselte /boot-Partition verfügt, müssen Sie das Entschlüsselungspasswort zweimal eingeben. Zunächst benötigt es GRUB 2, um /boot zu entschlüsseln, die zweite Eingabe ermöglicht es systemd, die verschlüsselten Volumes einzuhängen.

Auf UEFI-Computern verläuft der Boot-Vorgang sehr viel einfacher als auf Computern mit herkömmlichem BIOS. Die Firmware kann eine FAT-formatierte Systempartition von Festplatten mit GPT-Partitionstabelle lesen. Diese EFI-Systempartition (im laufenden System eingehängt als/boot/efi) bietet ausreichend Platz für eine komplette GRUB 2-Anwendung, die unmittelbar von der Firmware geladen und ausgeführt wird.

Wenn das BIOS/UEFI Netzwerk-Booting unterstützt, ist es auch möglich, einen Boot-Server zu konfigurieren, der den Bootloader bereitstellt. Das System kann dann über PXE gebootet werden. Das BIOS/UEFI dient als Bootloader. Es erhält das Boot-Image vom Boot-Server und startet das System. Dieser Vorgang ist vollständig unabhängig von den lokalen Festplatten.

12.2.1.2 Initialisierungs- und Bootloader-Phase auf IBM Z

 

Bei IBM Z muss der Boot-Vorgang durch einen Bootloader namens zipl (ursprüngliches z-Programmladen) initialisiert werden. Obwohl zipl das Lesen unterschiedlicher Dateisysteme unterstützt, unterstützt es nicht das SLE-Standarddateisystem (Btrfs) oder das Booten aus Snapshots. SUSE Linux Enterprise Server nutzt somit einen zweistufigen Boot-Vorgang, der gewährleistet, dass Btrfs zum Boot-Zeitpunkt vollständig unterstützt wird:

  1. zipl bootet aus der Partition /boot/zipl, die mit dem Datensystem Ext2, Ext3, Ext4 oder XFS formatiert werden kann. Diese Partition enthält einen minimalistischen Kernel sowie ein initramfs, die in den Speicher geladen werden. Das initramfs enthält (unter anderem) einen Btrfs-Treiber und den Bootloader GRUB 2. Der Kernel wird mit dem Parameter initgrub gestartet, der ihm befiehlt, GRUB 2 zu starten.

  2. Der Kernel hängt das root-Dateisystem ein, sodass auf /boot zugegriffen werden kann. Jetzt wird GRUB 2 über initramfs gestartet. Die Anwendung liest ihre Konfiguration aus /boot/grub2/grub.cfg aus und lädt den letzten Kernel und das initramfs aus /boot. Der neue Kernel wird nun über Kexec geladen.

12.2.2 Die Kernel-Phase

 

Sobald der Bootloader die Systemsteuerung übergeben hat, läuft der Boot-Vorgang auf allen Architekturen gleich ab. Der Bootloader lädt sowohl den Kernel als auch ein ursprüngliches RAM-basiertes Dateisystem (initramfs) in den Speicher und der Kernel übernimmt die Steuerung.

Nachdem der Kernel die Speicherverwaltung eingerichtet und CPU-Typ und -Eigenschaften erkannt hat, wird die Hardware initialisiert und das temporäre root-Dateisystem aus dem Speicher eingehängt, der mit initramfs geladen wurde.

12.2.2.1 Die initramfs-Datei

 

initramfs (ursprüngliches RAM-Dateisystem) ist ein kleines cpio-Archiv, das der Kernel auf einen RAM-Datenträger laden kann. Zu finden ist es unter /boot/initrd. Es lässt sich mit einem Tool namens dracut erstellen – weitere Hinweise finden Sie unter man 8 dracut.

initramfs stellt eine minimale Linux-Umgebung bereit, die das Ausführen von Programmen ermöglicht, bevor das eigentliche root-Dateisystem eingehängt wird. Diese minimale Linux-Umgebung wird durch eine BIOS- oder UEFI-Routine in den Arbeitsspeicher geladen, wobei lediglich ausreichend Arbeitsspeicher zur Verfügung stehen muss; ansonsten gelten keine besonderen Anforderungen. Das initramfs-Archiv must stets eine ausführbare Datei mit der Bezeichnung init umfassen, die den systemd-Daemon auf dem root-Dateisystem ausführt, so dass der Bootvorgang fortgesetzt werden kann.

Bevor das root-Dateisystem eingehängt und das Betriebssystem gestartet werden kann, ist es für den Kernel erforderlich, dass die entsprechenden Treiber auf das Gerät zugreifen, auf dem sich das root-Dateisystem befindet. Diese Treiber können spezielle Treiber für bestimmte Arten von Festplatten oder sogar Netzwerktreiber für den Zugriff auf ein Netzwerk-Dateisystem umfassen. Die erforderlichen Module für das root-Dateisystem werden mithilfe von init oder initramfs geladen. Nachdem die Module geladen wurden, stellt udev das initramfs mit den erforderlichen Geräten bereit. Später im Boot-Vorgang, nach dem Ändern des root-Dateisystems, müssen die Geräte regeneriert werden. Dies geschieht über die systemd-Einheit systemd-udev-trigger.service.

12.2.2.1.1 Erneutes Generieren von initramfs
 

Da initramfs Treiber enthält, muss es aktualisiert werden, sobald neue Versionen der darin gespeicherten Treiber verfügbar sind. Dies geschieht automatisch bei der Installation des Pakets, das die Treiberaktualisierung enthält. YaST oder zypper informieren Sie über diesen Umstand, indem Sie den Output des Befehls anzeigen, mit dem initramfs generiert wird. Es gibt jedoch einige Situationen, in denen Sie initramfs manuell neu erzeugen müssen:

Hinzufügen von Treibern aufgrund von Änderungen an der Hardware

Wenn Hardwarekomponenten (z. B. Festplatten) ausgetauscht werden müssen und diese Hardware zur Bootzeit andere Treiber im Kernel erfordert, müssen Sie die Datei initramfs aktualisieren.

Öffnen oder erstellen Sie /etc/dracut.conf.d/10-DRIVER.conf und fügen Sie die folgende Zeile hinzu (achten Sie auf das führende Leerzeichen): 

force_drivers+=" DRIVER1"

Ersetzen Sie dabei DRIVER1 durch den Modulnamen des Treibers. Sie können auch mehrere Treiber hinzufügen. In diesem Fall geben Sie eine durch Leerzeichen getrennte Liste der Modulnamen ein: 

force_drivers+=" DRIVER1 DRIVER2"

Fahren Sie mit Prozedur 12.1, „Generieren eines initramfs“ fort.

Verschieben von Systemverzeichnissen auf RAID oder LVM

Wann immer Sie Auslagerungsdateien oder Systemverzeichnisse wie /usr in einem laufenden System auf RAID oder ein logisches Volume verschieben, müssen Sie ein initramfs erstellen, das Softwaretreiber für RAID oder LVM unterstützt.

Hierzu müssen Sie die entsprechenden Einträge in /etc/fstab erstellen und die neuen Einträge (beispielsweise mit mount -a und/oder swapon -a) einhängen.

Fahren Sie mit Prozedur 12.1, „Generieren eines initramfs“ fort.

Hinzufügen von Festplatten zu einer LVM-Gruppe/einem Btrfs-RAID mit root-Dateisystem

Wann immer Sie eine Festplatte zu einer logischen Volumegruppe oder einem Btrfs-RAID, die oder das das root-Dateisystem enthält, hinzufügen (oder daraus entfernen), müssen Sie ein initramfs erstellen, das das größere Volume unterstützt. Befolgen Sie die Anweisungen unter Prozedur 12.1, „Generieren eines initramfs“.

Fahren Sie mit Prozedur 12.1, „Generieren eines initramfs“ fort.

Ändern der Kernel-Variablen

Wenn Sie die Werte von Kernel-Variablen über die sysctl-Benutzeroberfläche ändern und dabei die zugehörigen Dateien ändern (/etc/sysctl.conf oder /etc/sysctl.d/*.conf), geht die Änderung beim nächsten Neubooten des Systems verloren. Die Änderungen werden selbst dann nicht in der initramfs-Datei gespeichert, wenn Sie die Werte zur Laufzeit mit sysctl --system laden. Aktualisieren Sie es, in dem Sie wie in Prozedur 12.1, „Generieren eines initramfs“ beschrieben vorgehen.

Vorgehen 12.1: Generieren eines initramfs
 

Beachten Sie, dass alle Befehle des folgenden Verfahrens unter dem Benutzer root ausgeführt werden müssen.

  1. Generieren Sie eine neue initramfs-Datei, indem Sie Folgendes ausführen: 

    dracut MY_INITRAMFS

    Ersetzen Sie MY_INITRAMFS durch einen Dateinamen Ihrer Wahl. Das neue initramfs wird als /boot/MY_INITRAMFS erstellt.

    Alternativ können Sie dracut -f ausführen. Somit wird die aktuell verwendete, bereits vorhandene Datei überschrieben.

  2. (Überspringen Sie diesen Schritt, wenn Sie im vorangegangenen Schritt dracut -f ausgeführt haben.) Erstellen Sie einen Link zur initramfs-Datei, die Sie im vorangegangenen Schritt erstellt haben: 

    (cd /boot && ln -sf MY_INITRAMFS initrd)

  3. Unter der Architektur IBM z müssen Sie zudem grub2-install ausführen.

12.2.3 Die Phase init auf initramfs

 

Das temporäre root-Dateisystem, das vom Kernel aus initramfs eingehängt wird, enthält die ausführbare Datei systemd (die wir im Folgenden als init auf initramfs bezeichnen, siehe auch Abschnitt 12.1, „Terminologie“). Dieses Programm führt alle erforderlichen Aktionen aus, mit denen das eigentliche root-Dateisystem eingehängt wird. Es bietet Kernel-Funktionen für das benötigte Dateisystem sowie Gerätetreiber für Massenspeicher-Controller mit udev.

Der Hauptzweck von init unter initramfs ist es, das Einhängen des eigentlichen root-Dateisystems sowie die Vorbereitung des Zugriffs darauf. Je nach aktueller Systemkonfiguration ist init unter initramfs für die folgenden Tasks verantwortlich.

Laden der Kernelmodule

Je nach Hardware-Konfiguration sind für den Zugriff auf die Hardware-Komponenten des Computers (vor allem auf die Festplatte) spezielle Treiber erforderlich. Für den Zugriff auf das eigentliche root-Dateisystem muss der Kernel die entsprechenden Dateisystemtreiber laden.

Bereitstellen von speziellen Blockdateien

Der Kernel generiert, abhängig von den geladenen Modulen, Geräteereignisse. udev verarbeitet diese Ereignisse und generiert die erforderlichen blockspezifischen Dateien auf einem RAM-Dateisystem im Verzeichnis /dev. Ohne diese speziellen Dateien wäre ein Zugriff auf das Dateisystem und andere Geräte nicht möglich.

Verwalten von RAID- und LVM-Setups

Wenn Ihr System so konfiguriert ist, dass das root-Dateisystem sich unter RAID oder LVM befindet, richtet init unter initramfs LVM oder RAID so ein, dass der Zugriff auf das root-Dateisystem zu einem späteren Zeitpunkt erfolgt.

Verwalten der Netzwerkkonfiguration

Wenn Ihr System für die Verwendung eines Netzwerk-eingehängten root-Dateisystems (über NFS eingehängt) konfiguriert ist, muss init sicherstellen, dass die entsprechenden Netzwerktreiber geladen und für den Zugriff auf das root-Dateisystem eingerichtet werden.

Wenn sich das Dateisystem auf einem Netzwerkblockgerät wie iSCSI oder SAN befindet, wird die Verbindung zum Speicherserver ebenfalls von init unter initramfs eingerichtet. SUSE Linux Enterprise Server unterstützt das Booten von einem sekundären iSCSI-Ziel, wenn das primäre Ziel nicht verfügbar ist. Weitere Details zur Konfiguration des Boot-iSCSI-Ziels finden Sie im Book “Storage Administration Guide”, Chapter 15 “Mass storage over IP networks: iSCSI”, Section 15.3.1 “Using YaST for the iSCSI initiator configuration”.

Anmerkung
Anmerkung: Umgang mit Einhängefehlern

Wenn beim Einhängen des root-Dateisystems in der Bootumgebung ein Fehler auftritt, muss es überprüft und repariert werden, bevor das Booten fortgesetzt werden kann. Die Dateisystemprüfung wird für Ext3- und Ext4-Dateisysteme automatisch gestartet. Der Reparaturvorgang findet für XFS- und Btrfs-Dateisysteme nicht automatisch statt und dem Benutzer werden Informationen angezeigt, die die verfügbaren Optionen zur Reparatur des Dateisystems beschreiben. Wenn das Dateisystem erfolgreich repariert wurde, versucht das System nach dem Beenden der Bootumgebung erneut, das root-Dateisystem einzuhängen. Falls dieser Vorgang erfolgreich ist, wird der Bootvorgang wie gewohnt fortgesetzt.

12.2.3.1 Die Phase init auf initramfs während des Installationsvorgangs

 

Wenn init unter initramfs im Rahmen des Installationsvorgangs während des anfänglichen Boot-Vorgangs aufgerufen wird, unterscheiden sich seine Tasks von den oben beschriebenen. Beachten Sie, dass das Installationssystem auch systemd aus initramfs nicht startet – diese Aufgaben werden von linuxrc übernommen.

Suchen des Installationsmediums

Beim Starten des Installationsvorgangs lädt der Rechner einen Installations-Kernel und eine besondere init mit dem YaST-Installationsprogramm. Das YaST-Installationsprogramm wird in einem RAM-Dateisystem ausgeführt und benötigt Daten über den Speicherort des Installationsmediums, um auf dieses zugreifen und das Betriebssystem installieren zu können.

Initiieren der Hardware-Erkennung und Laden der entsprechenden Kernelmodule

Wie bereits in Abschnitt 12.2.2.1, „Die initramfs-Datei“ erwähnt, beginnt der Boot-Vorgang mit einem Mindestsatz an Treibern, die für die meisten Hardware-Konfigurationen verwendet werden können. Bei Rechnern mit AArch64, POWER und AMD64/Intel 64 löst linuxrc zunächst eine Hardwareabfrage aus, durch die die Treiber ermittelt werden, die sich für Ihre Hardwarekonfiguration eignen. Unter IBM Z muss beispielsweise über linuxrc oder parmfile eine Liste der Treiber und deren Parameter bereitgestellt werden.

Diese Treiber werden zur Erstellung der zum Booten des Systems benötigten, benutzerdefinierten initramfs-Datei verwendet. Falls die Module nicht für „boot“, sondern für „coldplug“ benötigt werden, können sie mit systemd geladen werden. Weitere Informationen finden Sie unter Abschnitt 15.6.4, „Laden der Kernelmodule“.

Laden des Installationssystems

Wenn die Hardware ordnungsgemäß erkannt wurde, werden die entsprechenden Treiber geladen. Das udev-Programm erstellt die speziellen Gerätedateien und linuxrc startet das Installationssystem mit dem YaST-Installationsprogramm.

Starten von YaST

linuxrc startet schließlich YaST, das wiederum die Paketinstallation und die Systemkonfiguration startet.

12.2.4 Die systemd-Phase

 

Nachdem das „echte“ root-Dateisystem gefunden wurde, wird es auf Fehler geprüft und eingehängt. Wenn dieser Vorgang erfolgreich ist, wird das initramfs bereinigt, und der systemd-Daemon wird für das root-Dateisystem ausgeführt. systemd ist der System- und Servicemanager von Linux. Es handelt sich dabei um den übergeordneten Prozess, der als PID 1 gestartet wird und wie ein init-System agiert, das die Benutzerraumdienste startet und betreibt. Ausführliche Informationen finden Sie unter Kapitel 15, Der Daemon systemd.

13 UEFI (Unified Extensible Firmware Interface)

 

Die UEFI (Unified Extensible Firmware Interface) bildet die Schnittstelle zwischen der Firmware, die sich auf der Systemhardware befindet, allen Hardware-Komponenten des Systems und dem Betriebssystem.

UEFI wird auf PC-Systemen immer stärker verbreitet und ersetzt allmählich das bisherige PC-BIOS. UEFI bietet beispielsweise echte Unterstützung für 64-Bit-Systeme und ermöglicht das sichere Booten („Secure Boot“, Firmware-Version 2.3.1c oder höher erforderlich), eine der zentralen Funktionen dieser Schnittstelle. Nicht zuletzt stellt UEFI auf allen x86-Plattformen eine Standard-Firmware bereit.

UEFI eröffnet außerdem die folgenden Vorteile:

  • Booten von großen Festplatten (mehr als 2 TiB) mithilfe einer GUID-Partitionstabelle (GPT).

  • CPU-unabhängige Architektur und Treiber.

  • Flexible Vor-OS-Umgebung mit Netzwerkfunktionen.

  • CSM (Compatibility Support Module) zur Unterstützung des Bootens älterer Betriebssysteme über eine PC-BIOS-ähnliche Emulation.

Weitere Informationen finden Sie im http://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface. Die nachfolgenden Abschnitte sollen keinen allgemeinen Überblick über UEFI liefern, sondern sie weisen lediglich darauf hin, wie bestimmte Funktionen in SUSE Linux Enterprise Server implementiert sind.

13.1 Secure Boot

 

Bei UEFI bedeutet die Absicherung des Bootstrapping-Prozesses, dass eine Vertrauenskette aufgebaut wird. Die „Plattform“ ist die Grundlage dieser Vertrauenskette; im SUSE Linux Enterprise Server-Kontext bilden die Hauptplatine und die On-Board-Firmware diese „Plattform“. Anders gesagt ist dies der Hardware-Hersteller, und die Vertrauenskette erstreckt sich von diesem Hardware-Hersteller zu den Komponentenherstellern, den Betriebssystemherstellern usw.

Das Vertrauen wird durch die Verschlüsselung mit öffentlichen Schlüsseln ausgedrückt. Der Hardware-Hersteller integriert einen sogenannten Plattformschlüssel (Platform Key, PK) in die Firmware, der die Grundlage für das Vertrauen legt. Das Vertrauensverhältnis zu Betriebssystemherstellern und anderen Dritten wird dadurch dokumentiert, dass ihre Schlüssel mit dem PK signiert werden.

Zum Gewährleisten der Sicherheit wird schließlich verlangt, dass die Firmware erst dann einen Code ausführt, wenn dieser Code mit einem dieser „verbürgten“ Schlüssel signiert ist – ein OS-Bootloader, ein Treiber im Flash-Speicher einer PCI-Express-Karte oder auf der Festplatte oder auch eine Aktualisierung der Firmware selbst.

Um Secure Boot nutzen zu können, muss der OS-Loader also mit einem Schlüssel signiert sein, der für die Firmware als verbürgt gilt, und der OS-Loader muss überprüfen, ob der zu ladende Kernel ebenfalls verbürgt ist.

In die UEFI-Schlüsseldatenbank können KEKs (Key Exchange Keys) aufgenommen werden. Auf diese Weise können Sie auch andere Zertifikate nutzen, sofern diese mit dem privaten Teil des PK signiert sind.

13.1.1 Implementierung auf SUSE Linux Enterprise Server

 

Standardmäßig wird der KEK (Key Exchange Key) von Microsoft installiert.

Anmerkung
Anmerkung: GUID-Partitionstabelle (GPT) erforderlich

Die Secure Boot-Funktion ist in UEFI/x86_64-Installationen standardmäßig aktiviert. Die Option Secure Boot-Unterstützung aktivieren finden Sie auf der Registerkarte Bootcode-Optionen im Dialogfeld Bootloader-Einstellungen. Diese Option unterstützt das Booten, wenn Secure Boot in der Firmware aktiviert ist, wobei Sie auch dann booten können, wenn diese Funktion deaktiviert ist.

Secure Boot-Unterstützung
Abbildung 13.1: Secure Boot-Unterstützung
 

Für die Secure Boot-Funktion ist eine GUID-Partitionstabelle (GPT) erforderlich, die die bisherige Partitionierung per MBR (Master Boot Record) ersetzt. Wenn YaST während der Installation den EFI-Modus feststellt, wird versucht, eine GPT-Partition zu erstellen. UEFI erwartet die EFI-Programme auf einer FAT-formatierten ESP (EFI-Systempartition).

Zur Unterstützung von UEFI Secure Boot ist ein Bootloader mit einer digitalen Signatur erforderlich, den die Firmware als verbürgten Schlüssel erkennt. Die Firmware vertraut diesem Schlüssel a priori und ohne manuelle Intervention.

Hierzu gibt es zwei Möglichkeiten. Die erste Möglichkeit ist die Zusammenarbeit mit Hardware-Herstellern, sodass diese einen SUSE-Schlüssel zulassen, mit dem dann der Bootloader signiert wird. Die zweite Möglichkeit besteht darin, das Windows Logo Certification-Programm von Microsoft zu durchlaufen, damit der Bootloader zertifiziert wird und Microsoft den SUSE-Signierschlüssel anerkennt (also mit dem KEK von Microsoft signiert). Bislang wurde der Loader für SUSE vom UEFI Signing Service (in diesem Fall von Microsoft) signiert.

UEFI: Secure Boot-Vorgang
Abbildung 13.2: UEFI: Secure Boot-Vorgang
 

Auf der Implementierungsschicht nutzt SUSE den shim-Loader, der standardmäßig installiert wird. Durch diese elegante Lösung werden rechtliche Probleme vermieden und der Zertifizierungs- und Signierungsschritt wird erheblich vereinfacht. Der shim-Loader lädt einen Bootloader wie GRUB 2 und überprüft diesen Loader; der Bootloader wiederum lädt ausschließlich Kernels, die mit einem SUSE-Schlüssel signiert sind. SUSE bietet diese Funktion ab SLE11 SP3 in Neuinstallationen, in denen UEFI Secure Boot aktiviert ist.

Es gibt zwei Typen von verbürgten Benutzern.

  • Erstens: Benutzer, die die Schlüssel besitzen. Der PK (Platform Key) ermöglicht nahezu alle Aktionen. Der KEK (Key Exchange Key) ermöglicht dieselben Aktionen wie ein PK, mit der Ausnahme, dass der PK hiermit nicht geändert werden kann.

  • Zweitens: Benutzer mit physischem Zugang zum Computer. Ein Benutzer mit physischem Zugang kann den Computer neu booten und UEFI konfigurieren.

UEFI bietet zwei Arten von Variablen für die Anforderungen dieser Benutzer:

  • Der erste Variablentyp sind die sogenannten „authentifizierten Variablen“, die sowohl aus dem Bootprozess (der sogenannten Boot-Dienstumgebung) und dem laufenden Betriebssystem heraus aktualisiert werden können. Dies ist nur dann möglich, wenn der neue Wert der Variable mit demselben Schlüssel signiert ist wie der bisherige Wert der Variable. Zudem können diese Variablen nur an einen Wert mit einer höheren Seriennummer angehängt oder in einen Wert mit einer höheren Seriennummer geändert werden.

  • Die zweiten Variablen sind die sogenannten „Boot Services Only Variables“ (Variablen für Boot-Services). Diese Variablen stehen jedem Code zur Verfügung, der während des Bootvorgangs ausgeführt wird. Nach Abschluss des Bootvorgangs und vor dem Starten des Betriebssystems muss der Bootloader den Aufruf ExitBootServices auslösen. Anschließend sind diese Variablen nicht mehr zugänglich, und das Betriebssystem kann nicht mehr darauf zugreifen.

Die verschiedenen UEFI-Schlüssellisten sind vom ersten Typ, da es damit möglich ist, die Schlüssel, Treiber und Firmware-Fingerabdrücke online zu aktualisieren, hinzuzufügen und in Schwarze Listen einzutragen. Der zweite Variablentyp, also die „Boot Services Only Variables“, unterstützt die Implementierung von Secure Boot auf sichere, Open Source-freundliche und damit GPLv3-kompatible Weise.

SUSE wird mit shim gestartet, einem kleinen, einfachen EFI-Bootloader, der von SUSE und Microsoft signiert ist.

Damit kann shim geladen und ausgeführt werden.

Anschließend überprüft shim, ob der zu ladende Bootloader verbürgt ist. In der Standardsituation verwendet shim ein unabhängiges SUSE-Zertifikat, das in diesen Loader integriert ist. Darüber hinaus ermöglicht shim das „Registrieren“ weiterer Schlüssel, die Vorrag vor dem SUSE-Standardschlüssel erhalten. Im Folgenden werden diese Schlüssel als MOKs („Machine Owner Keys“) bezeichnet.

Danach überprüft und bootet der Bootloader den Kernel, und der Kernel überprüft und bootet seinerseits die Module.

13.1.2 MOK (Machine Owner Key)

 

Wenn bestimmte Kernel, Treiber oder andere Komponenten im Startprozess ersetzt werden sollen, müssen Sie Machine Owner Keys (MOKs) verwenden. Das Werkzeug mokutil unterstützt Sie bei der Verwaltung der MOKs.

Sie können mit mokutil eine MOK-Registrierungsanforderung erstellen. Die Anforderung wird in der UEFI-Laufzeit(RT)-Variablen MokNew gespeichert. Beim nächsten Starten erkennt der shim-Bootloader die Variable MokNew und lädt den MokManager, in dem Sie mehrere Optionen erhalten. Mit den Optionen Schlüssel von Festplatte registrieren und Hash von Festplatte registrieren nehmen Sie den Schlüssel in die MokList auf. Mit der Option MOK registrieren kopieren Sie einen Schlüssel aus der MokNew-Variablen.

Im Normalfall wird ein Schlüssel von der Festplatte registriert, wenn Shim grub2 nicht laden kann und ein Fallback auf das Laden des MokManagers durchführt. Da MokNew noch nicht vorhanden ist, haben Sie die Möglichkeit, den Schlüssel in der UEFI-Partition zu suchen.

13.1.3 Booten eines benutzerdefinierten Kernels

 

Die folgenden Ausführungen beruhen auf https://en.opensuse.org/openSUSE:UEFI#Booting_a_custom_kernel.

Secure Boot verhindert nicht die Nutzung eines selbst kompilierten Kernels. Sie müssen den Kernel mit Ihrem eigenen Zertifikat signieren und dieses Zertifikat für die Firmware oder den MOK bekanntgeben.

  1. Erstellen Sie einen benutzerdefinierten X.509-Schlüssel und ein entsprechendes Zertifikat für die Signierung: 

    openssl req -new -x509 -newkey rsa:2048 -keyout key.asc \
  -out cert.pem -nodes -days 666 -subj "/CN=$USER/"

    Weitere Informationen zum Erstellen von Zertifikaten finden Sie unter https://en.opensuse.org/openSUSE:UEFI_Image_File_Sign_Tools#Create_Your_Own_Certificate.

  2. Verpacken Sie den Schlüssel und das Zertifikat als PKCS#12-Struktur: 

    tux > openssl pkcs12 -export -inkey key.asc -in cert.pem \
  -name kernel_cert -out cert.p12

  3. Generieren Sie eine NSS-Datenbank für pesign: 

    tux > certutil -d . -N

  4. Importieren Sie den Schlüssel und das Zertifikat aus PKCS#12 in die NSS-Datenbank: 

    tux > pk12util -d . -i cert.p12

  5. „Authentifizieren“ Sie den Kernel mit der neuen Signatur mithilfe von pesign: 

    tux > pesign -n . -c kernel_cert -i arch/x86/boot/bzImage \
  -o vmlinuz.signed -s

  6. Listen Sie die Signaturen im Kernel-Image auf: 

    tux > pesign -n . -S -i vmlinuz.signed

    Zu diesem Zeitpunkt können Sie den Kernel wie gewohnt in /boot installieren. Der Kernel besitzt nun eine benutzerdefinierte Signatur, sodass das Zertifikat zum Signieren in die UEFI-Firmware oder in den MOK importiert werden muss.

  7. Konvertieren Sie das Zertifikat zum Importieren in die Firmware oder den MOK in das DER-Format: 

    tux > openssl x509 -in cert.pem -outform der -out cert.der

  8. Kopieren Sie das Zertifikat aus Gründen des einfacheren Zugriffs in die ESP: 

    tux > sudo cp cert.der /boot/efi/

  9. Mit mokutil wird die MOK-Liste automatisch gestartet.

      1. Importieren Sie das Zertifikat in MOK: 

        tux > mokutil --root-pw --import cert.der

        Mit der Option --root-pw kann der root-Benutzer direkt verwendet werden.

      2. Prüfen Sie die Liste der Zertifikate, die für die Registrierung vorbereitet werden: 

        tux > mokutil --list-new

      3. Booten Sie das System neu; mit shim sollte MokManager gestartet werden. Um den Import des Zertifikats in die MOK-Liste zu bestätigen, müssen Sie das root-Passwort eingeben.

      4. Prüfen Sie, ob der soeben importierte Schlüssel registriert wurde: 

        tux > mokutil --list-enrolled

      1. Zum manuellen Starten des MOK gehen Sie alternativ wie folgt vor:

        Booten Sie den Computer neu

      2. Drücken Sie im GRUB 2-Menü die Taste „c“.

      3. Typ: 

        chainloader $efibootdir/MokManager.efi
boot

      4. Wählen Sie Enroll key from disk (Schlüssel von Festplatte registrieren).

      5. Navigieren Sie zur Datei cert.der, und drücken Sie Eingabetaste.

      6. Registrieren Sie den Schlüssel gemäß den Anweisungen. In der Regel drücken Sie hierzu „0“ und dann zum Bestätigen „j“.

        Alternativ können Sie einen neuen Schlüssel über das Firmware-Menü in die Signaturdatenbank aufnehmen.

13.1.4 Verwenden von Nicht-Inbox-Treibern

 

Das Hinzufügen von Nicht-Inbox-Treibern (also Treibern, die nicht in SUSE Linux Enterprise Server inbegriffen sind) wird bei der Installation mit aktiviertem Secure Boot nicht unterstützt. Der Signierschlüssel für SolidDriver/PLDP gilt standardmäßig nicht als vertrauenswürdig.

Es ist mit zwei Methoden möglich, Treiber von Drittanbietern bei der Installation mit aktiviertem Secure Boot zu nutzen. In beiden Fällen gilt:

  • Fügen Sie die erforderlichen Schlüssel vor der Installation mithilfe von Firmware-/Systemverwaltungswerkzeugen in die Firmware-Datenbank ein. Diese Option ist von der jeweils verwendeten Hardware abhängig. Weitere Informationen erhalten Sie bei Ihrem Hardware-Händler.

  • Verwenden Sie ein bootfähiges Treiber-ISO-Image von https://drivers.suse.com/ oder von Ihrem Hardware-Händler, mit dem die erforderlichen Schlüssel beim ersten Starten in die MOK-Liste eingetragen werden.

So tragen Sie die Treiberschlüssel mit dem bootfähigen Treiber-ISO-Image in die MOK-Liste ein:

  1. Brennen Sie das obige ISO-Image auf eine leere CD/DVD.

  2. Starten Sie die Installation von der neuen CD/DVD und halten Sie dabei die standardmäßigen Installationsmedien bzw. die URL zu einem Netzwerkinstallationsserver bereit.

    Wenn Sie eine Netzwerkinstallation vornehmen, geben Sie die URL der Netzwerkinstallationsquelle mit der Option install= in die Bootbefehlszeile ein.

    Bei einer Installation von optischen Speichermedien bootet das Installationsprogramm zunächst vom Treiber-Kit; anschließend werden Sie aufgefordert, den ersten Installationsdatenträger für das Produkt einzulegen.

  3. Bei der Installation wird ein initrd mit aktualisierten Treibern herangezogen.

Weitere Informationen finden Sie im https://drivers.suse.com/doc/Usage/Secure_Boot_Certificate.html.

13.1.5 Funktionen und Einschränkungen

 

Beim Booten im Secure Boot-Modus stehen die folgenden Funktionen zur Verfügung:

  • Installation in den Speicherort des UEFI-Standard-Bootloaders (Mechanismus zum Beibehalten oder Wiederherstellen des EFI-Booteintrags).

  • Neubooten über UEFI.

  • Der Xen-Hypervisor wird mit UEFI gebootet, wenn kein Legacy-BIOS für das Fallback vorhanden ist.

  • Unterstützung für das PXE-Booten mit UEFI IPv6.

  • Unterstützung für den UEFI-Videomodus; der Kernel kann den Videomodus aus UEFI abrufen und den KMS-Modus mit denselben Parametern konfigurieren.

  • Unterstützung für das UEFI-Booten von USB-Geräten.

Beim Booten im Secure Boot-Modus gelten die folgenden Einschränkungen:

  • Um zu gewährleisten, dass Secure Boot nicht einfach umgangen werden kann, sind einige Kernelfunktionen beim Ausführen unter Secure Boot deaktiviert.

  • Der Bootloader, der Kernel und die Kernelmodule müssen signiert sein.

  • Kexec und Kdump sind deaktiviert.

  • Der Ruhezustand (Suspend on Disk) ist deaktiviert.

  • Der Zugriff auf /dev/kmem und /dev/mem ist nicht möglich, auch nicht als root-Benutzer.

  • Der Zugriff auf den E/A-Anschluss ist nicht möglich, auch nicht als root-Benutzer. Alle X11-Grafiktreiber müssen einen Kerneltreiber verwenden.

  • Der PCI-BAR-Zugriff über sysfs ist nicht möglich.

  • custom_method in ACPI ist nicht verfügbar.

  • debugfs für das Modul asus-wmi ist nicht verfügbar.

  • Der Parameter acpi_rsdp hat keine Auswirkungen auf den Kernel.

13.2 Weitere Informationen

 

14 Der Bootloader GRUB 2

 

In diesem Kapitel wird die Konfiguration von GRUB 2, dem unter SUSE Linux Enterprise Server verwendeten Bootloader, beschrieben. Diese Anwendung ist der Nachfolger des bisherigen Bootloaders GRUB (nunmehr als „GRUB Legacy“ bezeichnet). GRUB 2 ist seit Version 12 als standardmäßiger Bootloader in SUSE® Linux Enterprise Server eingebunden. Für die Konfiguration der wichtigsten Einstellungen steht ein YaST-Modul bereit. Eine Übersicht über den Bootvorgang finden Sie in Kapitel 12, Einführung in den Bootvorgang. Weitere Informationen zur Unterstützung von Secure Boot finden Sie in Kapitel 13, UEFI (Unified Extensible Firmware Interface).

14.1 Hauptunterschiede zwischen GRUB Legacy und GRUB 2

 

  • Die Konfiguration wird in unterschiedlichen Dateien gespeichert.

  • Es werden mehr Dateisysteme unterstützt (z. B. Btrfs).

  • Dateien auf LVM- oder RAID-Geräten können direkt gelesen werden.

  • Die Benutzeroberfläche kann übersetzt und mit Themen gestaltet werden.

  • Es steht ein Mechanismus zum Laden von Modulen bereit, die weitere Funktionen (z. B. Dateisysteme) unterstützen.

  • Es werden automatisch Boot-Einträge für andere Kernel und Betriebssysteme (z. B. Windows) gesucht und erzeugt.

  • Eine minimale Konsole (ähnlich wie Bash aufgebaut) steht zur Verfügung.

14.2 Konfigurationsdateistruktur

 

Die Konfiguration von GRUB 2 umfasst die folgenden Dateien:

/boot/grub2/grub.cfg

Diese Datei enthält die Konfiguration der Menüpunkte in GRUB 2. Die Datei ersetzt die Datei menu.lst in GRUB Legacy. grub.cfg sollte nicht bearbeitet werden. Die Datei wird automatisch durch das Kommando grub2-mkconfig -o /boot/grub2/grub.cfg generiert.

/boot/grub2/custom.cfg

Diese optionale Datei wird beim Booten direkt aus grub.cfg erzeugt. Hiermit können Sie benutzerdefinierte Einträge in das Bootmenü aufnehmen. Ab SUSE Linux Enterprise Server 12 SP2 werden diese Einträge auch geparst, wenn grub-once verwendet wird.

/etc/default/grub

Diese Datei steuert die Benutzereinstellungen für GRUB 2 und enthält in der Regel zusätzliche Umgebungseinstellungen, beispielsweise Hintergründe und Themen.

Skripte unter /etc/grub.d/

Die Skripte in diesem Verzeichnis werden bei Ausführung des Kommandos grub2-mkconfig -o /boot/grub2/grub.cfg gelesen. Die zugehörigen Anweisungen werden in die Hauptkonfigurationsdatei /boot/grub/grub.cfg integriert.

/etc/sysconfig/bootloader

Diese Konfigurationsdatei enthält einige Grundeinstellungen wie den Bootloader-Typ und ob die UEFI Secure Boot-Unterstützung aktiviert werden soll.

/boot/grub2/x86_64-efi, /boot/grub2/power-ieee1275, /boot/grub2/s390x

Diese Konfigurationsdateien enthalten architekturspezifische Optionen.

GRUB 2 kann auf mehrere Weisen gesteuert werden. Booteinträge aus einer vorhandenen Konfiguration können im grafischen Menü (Eröffnungsbildschirm) ausgewählt werden. Die Konfiguration wird aus der Datei /boot/grub2/grub.cfg geladen, die aus anderen Konfigurationsdateien kompiliert wird (siehe unten). Alle GRUB 2-Konfigurationsdateien gelten als Systemdateien und Sie benötigen root-Berechtigungen, um sie bearbeiten zu können.

Anmerkung
Anmerkung: Aktivieren von Konfigurationsänderungen

Nach der manuellen Bearbeitung der GRUB 2-Konfigurationsdateien müssen Sie grub2-mkconfig -o /boot/grub2/grub.cfg ausführen, um die Änderungen zu aktivieren. Sollten Sie die Konfiguration jedoch mit YaST geändert haben, ist dies nicht nötig, da YaST dieses Kommando automatisch ausführt.

14.2.1 Die Datei /boot/grub2/grub.cfg

 

Hinter dem grafischen Eröffnungsbildschirm mit dem Bootmenü steht die GRUB 2-Konfigurationsdatei /boot/grub2/grub.cfg, die alle Informationen zu allen Partitionen oder Betriebssystemen enthält, die über das Menü gebootet werden können.

GRUB 2 liest bei jedem Systemstart die Menüdatei direkt vom Dateisystem neu ein. Es besteht also kein Bedarf, GRUB 2 nach jeder Änderung an der Konfigurationsdatei neu zu installieren. Beim Installieren oder Entfernen von Kernels wird grub.cfg automatisch neu aufgebaut.

grub.cfg wird aus der Datei /etc/default/grub und Skripten im /etc/grub.d/-Verzeichnis kompiliert, wenn das Kommando grub2-mkconfig -o /boot/grub2/grub.cfg ausgeführt wird. Ändern Sie die Datei daher in keinem Fall manuell. Bearbeiten Sie stattdessen die zugehörigen Ursprungsdateien, oder bearbeiten Sie die Konfiguration mit dem YaST-Bootloader-Modul (siehe Abschnitt 14.3, „Konfigurieren des Bootloaders mit YaST“).

14.2.2 Die Datei /etc/default/grub

 

Hier finden Sie allgemeinere Optionen für GRUB 2, beispielsweise den Zeitraum, über den das Menü angezeigt wird, oder das standardmäßig zu bootende Betriebssystem. Mit dem folgenden Kommando erhalten Sie eine Liste aller verfügbaren Optionen: 

tux > grep "export GRUB_DEFAULT" -A50 /usr/sbin/grub2-mkconfig | grep GRUB_

Neben den bereits definierten Variablen kann der Benutzer eigene Variablen festlegen und später in den Skripten im Verzeichnis /etc/grub.d verwenden.

Aktualisieren Sie nach der Bearbeitung von /etc/default/grub die Hauptkonfigurationsdatei mit grub2-mkconfig -o /boot/grub2/grub.cfg.

Anmerkung
Anmerkung: Bereich

Alle in dieser Datei festgelegten Optionen sind allgemeine Optionen, die für alle Booteinträge gelten. Mit den Konfigurationsoptionen GRUB_*_XEN_* legen Sie besondere Optionen für Xen-Kernel oder den Xen-Hypervisor fest. Weitere Informationen finden Sie unten.

GRUB_DEFAULT

Hiermit legen Sie den Bootmenüeintrag fest, der standardmäßig gebootet werden soll. Als Wert ist eine Zahl, der vollständige Name eines Menüeintrags oder der Eintrag „saved“ (Gespeichert) zulässig.

Mit GRUB_DEFAULT=2 wird der dritte Bootmenüeintrag gebootet (gezählt ab 0).

Mit GRUB_DEFAULT="2>0" wird der erste Untermenüeintrag im dritten übergeordneten Menüeintrag gebootet.

Mit GRUB_DEFAULT="Beispiel für Bootmenüeintrag" wird der Menüeintrag mit dem Titel „Beispiel für Bootmenüeintrag“ gebootet.

Mit GRUB_DEFAULT=saved wird der Eintrag gebootet, der mit dem Kommando grub2-once oder grub2-set-default angegeben wurde. Während mit grub2-reboot der Standard-Booteintrag nur für das nächste Neubooten festgelegt wird, bestimmt grub2-set-default den Standard-Booteintrag bis zur nächsten Änderung. grub2-editenv list zeigt den nächsten Booteintrag an.

GRUB_HIDDEN_TIMEOUT

Hiermit wird ein bestimmter Zeitraum (in Sekunden) abgewartet, bis der Benutzer eine Taste drückt. Während dieses Zeitraums wird erst dann ein Menü angezeigt, wenn der Benutzer eine Taste drückt. Wird während des angegebenen Zeitraums keine Taste gedrückt, so wird die Steuerung an GRUB_TIMEOUT übergeben. GRUB_HIDDEN_TIMEOUT=0 prüft zunächst, ob Umschalttaste gedrückt wurde. Falls ja, wird das Bootmenü angezeigt; ansonsten wird sofort der Standard-Menüeintrag gebootet. Dies ist die Standardeinstellung, wenn GRUB 2 nur ein bootfähiges Betriebssystem erkennt.

GRUB_HIDDEN_TIMEOUT_QUIET

Bei false wird ein Countdown-Zähler auf einem leeren Bildschirm angezeigt, wenn die Funktion GRUB_HIDDEN_TIMEOUT aktiv ist.

GRUB_TIMEOUT

Dies ist der Zeitraum (in Sekunden), über den das Bootmenü angezeigt wird, bevor der Standard-Booteintrag automatisch gebootet wird. Sobald Sie eine Taste drücken, wird die Zeitbegrenzung aufgehoben und GRUB 2 wartet darauf, dass Sie manuell die gewünschte Auswahl treffen. Mit GRUB_TIMEOUT=-1 wird das Menü so lange angezeigt, bis Sie den gewünschten Booteintrag manuell auswählen.

GRUB_CMDLINE_LINUX

Die Einträge in dieser Zeile werden an die Booteinträge für den normalen Modus und den Wiederherstellungsmodus angehängt. Hiermit können Sie zusätzliche Kernel-Parameter im Booteintrag angeben.

GRUB_CMDLINE_LINUX_DEFAULT

Dieser Eintrag entspricht GRUB_CMDLINE_LINUX, jedoch mit dem Unterschied, dass die Einträge nur im normalen Modus angehängt werden.

GRUB_CMDLINE_LINUX_RECOVERY

Dieser Eintrag entspricht GRUB_CMDLINE_LINUX, jedoch mit dem Unterschied, dass die Einträge nur im Wiederherstellungsmodus angehängt werden.

GRUB_CMDLINE_LINUX_XEN_REPLACE

Dieser Eintrag ersetzt sämtliche GRUB_CMDLINE_LINUX-Parameter für alle Xen-Booteinträge.

GRUB_CMDLINE_LINUX_XEN_REPLACE_DEFAULT

Dieser Eintrag entspricht GRUB_CMDLINE_LINUX_XEN_REPLACE, jedoch mit dem Unterschied, dass nur Parameter für GRUB_CMDLINE_LINUX_DEFAULT ersetzt werden.

GRUB_CMDLINE_XEN

Mit diesem Eintrag werden die Kernel-Parameter ausschließlich für den Xen-Gastkernel bestimmt; die Funktionsweise entspricht GRUB_CMDLINE_LINUX.

GRUB_CMDLINE_XEN_DEFAULT

Dieser Eintrag entspricht GRUB_CMDLINE_XEN; die Funktionsweise entspricht GRUB_CMDLINE_LINUX_DEFAULT.

GRUB_TERMINAL

Hiermit wird ein Eingabe-/Ausgabe-Terminal-Geräte angegeben und aktiviert. Mögliche Werte sind console (PC-BIOS- und EFI-Konsolen), serial (serielle Terminals), ofconsole (Open-Firmware-Konsolen) sowie der Standardwert gfxterm (Ausgabe im Grafikmodus). Sollen mehrere Geräte aktiviert werden, setzen Sie die Optionen in Anführungszeichen, beispielsweise GRUB_TERMINAL="console serial".

GRUB_GFXMODE

Dies ist die Auflösung für das grafische Terminal gfxterm. Hierbei sind ausschließlich die Modi verfügbar, die von Ihrer Grafikkarte (VBE) unterstützt werden. Die Standardeinstellung lautet „auto“; hiermit wird nach Möglichkeit eine bevorzugte Auflösung ausgewählt. Mit dem Kommando videoinfo in der GRUB 2-Kommandozeile werden die verfügbaren Bildschirmauflösungen für GRUB 2 angezeigt. Zum Öffnen der Kommandozeile drücken Sie C, wenn der GRUB 2-Bootmenübildschirm angezeigt wird.

Außerdem können Sie eine Farbtiefe an die Einstellung für die Auflösung anhängen, z. B. GRUB_GFXMODE=1280x1024x24.

GRUB_BACKGROUND

Hiermit legen Sie ein Hintergrundbild für das grafische Terminal gfxterm fest. Das Bild muss in einer Datei gespeichert sein, die GRUB 2 beim Booten lesen kann, und die Dateinamenerweiterung muss .png, .tga, .jpg oder .jpeg lauten. Falls erforderlich, wird das Bild auf die Bildschirmgröße skaliert.

GRUB_DISABLE_OS_PROBER

Bei true wird die automatische Suche nach anderen Betriebssystemen deaktiviert. Nur die Kernel-Images in /boot/ und die Optionen aus Ihren eigenen Skripten in /etc/grub.d/ werden erkannt.

SUSE_BTRFS_SNAPSHOT_BOOTING

Bei true kann GRUB 2 direkt in Snapper-Snapshots booten. Weitere Informationen finden Sie im Abschnitt 7.3, „System-Rollback durch Booten aus Snapshots“.

Eine vollständige Liste der Optionen finden Sie im Handbuch zu GNU GRUB.

14.2.3 Skripte in /etc/grub.d

 

Die Skripte in diesem Verzeichnis werden bei Ausführung des Kommandos grub2-mkconfig -o /boot/grub2/grub.cfg gelesen. Deren Anweisungen sind in /boot/grub2/grub.cfg integriert. Die Reihenfolge der Menüpunkte in grub.cfg ergibt sich aus der Reihenfolge, in der die Dateien in diesem Verzeichnis ausgeführt werden. Dateien mit einer Zahl am Anfang des Dateinamens werden zuerst ausgeführt, beginnend mit der niedrigsten Zahl. 00_header wird beispielsweise vor 10_linux ausgeführt, das wiederum vor 40_custom ausgeführt wird. Dateien mit einem Buchstaben an der ersten Stelle im Dateinamen werden nach den Dateien mit Zahlen am Anfang ausgeführt. Nur ausführbare Dateien erzeugen beim Ausführen von grub2-mkconfig eine Ausgabe in grub.cfg. Standardmäßig sind alle Dateien im Verzeichnis /etc/grub.d ausführbar.

Tipp
Tipp: Permanenter benutzerdefinierter Inhalt in grub.cfg

/boot/grub2/grub.cfg wird bei jedem Ausführen von grub2-mkconfig neu kompiliert, sodass benutzerdefinierte Inhalte verloren gehen. Wenn die Zeilen direkt in /boot/grub2/grub.cfg eingefügt werden, damit sie nach dem Ausführen von grub2-mkconfig nicht verloren gehen, fügen Sie sie zwischen den folgenden Stellen ein: 

### BEGIN /etc/grub.d/90_persistent ###

und 

### END /etc/grub.d/90_persistent ###

Das Skript 90_persistent sorgt dafür, dass diese Inhalte erhalten bleiben.

Hier finden Sie eine Liste der wichtigsten Skripten:

00_header

Hiermit werden Umgebungsvariablen festgelegt, beispielsweise der Speicherort von Systemdateien, Anzeigeeinstellungen, Themen und zuvor gespeicherte Einträge. Außerdem werden die Voreinstellungen aus der Datei /etc/default/grub importiert. In der Regel sind keine Änderungen an dieser Datei notwendig.

10_linux

Hiermit werden Linux-Kernel im root-Gerät erkannt und relevante Menüeinträge erstellt. Hierbei wird auch die zugehörige Option für den Wiederherstellungsmodus berücksichtigt (sofern aktiviert). Auf der Hauptmenüseite wird nur der jüngste Kernel angezeigt; weitere Kernel werden in einem Untermenü aufgeführt.

30_os-prober

Bei diesem Skript werden Linux und andere Betriebssysteme mithilfe von os-prober gesucht und die Ergebnisse werden in das GRUB 2-Menü eingetragen. Das Skript bietet Abschnitte für die Erkennung bestimmter anderer Betriebssysteme (z. B. Windows oder macOS).

40_custom

Mit dieser Datei können Sie schnell und einfach benutzerdefinierte Booteinträge in grub.cfg einbinden. Der Bestandteil exec tail -n +3 $0 am Anfang darf dabei nicht geändert werden.

Die Verarbeitungsreihenfolge ergibt sich aus den Zahlen am Anfang des Skriptnamens, wobei das Skript mit der niedrigsten Zahl zuerst ausgeführt wird. Wenn mehrere Skripte mit derselben Zahl beginnen, entscheidet die alphabetische Sortierung des vollständigen Namens über die endgültige Reihenfolge.

Tipp
Tipp: /boot/grub2/custom.cfg

Wenn Sie /boot/grub2/custom.cfg erstellen und benutzerdefinierte Inhalte eintragen, werden diese Inhalte beim Booten automatisch gleich nach 40_custom in /boot/grub40/grub.cfg aufgenommen.

14.2.4 Zuordnung von BIOS-Laufwerken und Linux-Geräten

 

In GRUB Legacy wurden die Linux-Geräte mithilfe der Konfigurationsdatei device.mapaus den Nummern der BIOS-Laufwerke abgeleitet. Die Zuordnung von BIOS-Laufwerken und Linux-Geräten ist jedoch nicht in jedem Fall fehlerfrei erkennbar. Wenn Sie beispielsweise die Reihenfolge der IDE- und SCSI-Laufwerke in der BIOS-Konfiguration vertauschen, entsteht in GRUB Legacy eine falsche Reihenfolge.

In GRUB 2 werden beim Erzeugen der Datei grub.cfg dagegen Geräte-ID-Zeichenfolgen (UUIDs) oder Dateisystemkennungen erzeugt, damit dieses Problem vermieden wird. In GRUB 2 wird eine interaktive temporäre Gerätezuordnung genutzt, die in der Regel ausreicht, insbesondere bei Systemen mit nur einer Festplatte.

Falls die automatische Zuordnung in GRUB 2 außer Kraft gesetzt werden soll, legen Sie eine benutzerdefinierte Zuordnungsdatei mit dem Dateinamen /boot/grub2/device.map an. Im nachfolgenden Beispiel wird die Zuordnung so geändert, dass DISK 3 das Bootlaufwerk ist. Beachten Sie, dass die GRUB 2-Partitionsnummern mit 1 beginnen, nicht mit 0 wie in GRUB Legacy. 

(hd1)  /dev/disk-by-id/DISK3 ID
(hd2)  /dev/disk-by-id/DISK1 ID
(hd3)  /dev/disk-by-id/DISK2 ID

14.2.5 Ändern von Menüeinträgen während des Bootvorgangs

 

Das direkte Bearbeiten von Menüeinträgen eröffnet einen Ausweg, wenn das System aufgrund einer fehlerhaften Konfiguration nicht mehr gebootet werden kann. Hiermit können Sie außerdem neue Einstellungen testen, ohne die bestehende Systemkonfiguration ändern zu müssen.

  1. Wählen Sie im grafischen Bootmenü den zu bearbeitenden Eintrag mit den Pfeiltasten aus.

  2. Drücken Sie E. Der Texteditor wird geöffnet.

  3. Wechseln Sie mit den Pfeiltasten zur Zeile, die bearbeitet werden soll.

    Booteditor in GRUB 2
    Abbildung 14.1: Booteditor in GRUB 2
     

    Anschließend haben Sie zwei Möglichkeiten:

    1. Zum Bearbeiten der Kernel-Parameter fügen Sie die gewünschten Parameter (jeweils durch ein Leerzeichen getrennt) am Ende der Zeile an, die mit linux oder linuxefi beginnt. Unter https://en.opensuse.org/Linuxrc finden Sie eine vollständige Liste der Parameter.

    2. Alternativ bearbeiten Sie die zu ändernden Optionen, z. B. die Kernelversion. Mit der Taste →| erhalten Sie die möglichen Vervollständigungsoptionen.

  4. Mit F10 booten Sie das System mit den vorgenommenen Änderungen, mit Esc verwerfen Sie Ihre Änderungen und kehren zum GRUB 2-Menü zurück.

Auf diese Weise vorgenommene Änderungen gelten nur für den aktuellen Bootvorgang und werden nicht dauerhaft gespeichert.

Wichtig
Wichtig: Tastaturbelegung während des Bootvorgangs

Beim Bootvorgang ist nur die amerikanische Tastaturbelegung verfügbar. Siehe Book “Bereitstellungshandbuch”, Chapter 12 “Fehlerbehebung”, Section 12.3 “Vom Installationsmedium kann nicht gebootet werden”, US-Tastaturbelegung.

Anmerkung
Anmerkung: Bootloader auf den Installationsmedien

Die Installationsmedien für Systeme mit herkömmlichen BIOS enthalten nach wie vor GRUB Legacy als Bootloader. Zum Hinzufügen von Bootparametern wählen Sie einen Eintrag aus und beginnen Sie mit der Eingabe. Die Ergänzungen des Installations-Booteintrags werden dauerhaft im installierten System gespeichert.

Anmerkung
Anmerkung: Bearbeiten von GRUB 2-Menüeinträgen auf IBM Z

Für IBM Z gelten andere Cursorbewegungen und andere Bearbeitungskommandos. Weitere Informationen finden Sie unter Abschnitt 14.4, „Unterschiede bei der Terminalnutzung auf IBM Z“.

14.2.6 Festlegen eines Bootpassworts

 

GRUB 2 unterstützt schon vor dem Booten des Betriebssystems den Zugriff auf Dateisysteme. Dies bedeutet, dass Benutzer ohne root-Berechtigungen auf Dateien des Linux-Systems zugreifen können, auf die sie nach dem Booten keinen Zugriff haben. Um diese Zugriffe oder das Booten bestimmter Menüeinträge zu verhindern, können Sie ein Bootpasswort festlegen.

Wichtig
Wichtig: Booten erfordert ein Passwort

Das Bootpasswort muss dann bei jedem Booten eingegeben werden; das System wird also nicht automatisch gebootet.

Legen Sie das Bootpasswort gemäß den nachfolgenden Anweisungen fest. Alternativ verwenden Sie YaST (Bootloader durch Passwort schützen ).

  1. Verschlüsseln Sie das Passwort mit grub2-mkpasswd-pbkdf2: 

    tux > sudo grub2-mkpasswd-pbkdf2
Password: ****
Reenter password: ****
PBKDF2 hash of your password is grub.pbkdf2.sha512.10000.9CA4611006FE96BC77A...

  2. Fügen Sie die resultierende Zeichenfolge zusammen mit dem Kommando set superusers in die Datei /etc/grub.d/40_custom ein. 

    set superusers="root"
password_pbkdf2 root grub.pbkdf2.sha512.10000.9CA4611006FE96BC77A...

  3. Führen Sie zum Importieren der Änderungen in der Hauptkonfigurationsdatei Folgendes aus: 

    tux > sudo grub2-mkconfig -o /boot/grub2/grub.cfg

Nach dem Neubooten werden Sie aufgefordert, einen Benutzernamen und ein Passwort einzugeben, sobald Sie versuchen, einen Menüeintrag zu booten. Geben Sie root und das Passwort ein, das Sie mit dem Kommando grub2-mkpasswd-pbkdf2 erstellt haben. Wenn der Berechtigungsnachweis fehlerfrei ist, bootet das System den angegebenen Booteintrag.

Weitere Informationen finden Sie im https://www.gnu.org/software/grub/manual/grub.html#Security.

14.3 Konfigurieren des Bootloaders mit YaST

 

Mit dem YaST-Modul ist die Konfiguration des Bootloaders auf Ihrem SUSE Linux Enterprise-Server am einfachsten. Wählen Sie im YaST-Kontrollzentrum die Option System › Bootloader. Das Modul zeigt die aktuelle Bootloader-Konfiguration des Systems und ermöglicht Ihnen, Änderungen vorzunehmen.

Verwenden Sie den Karteireiter Boot-Code-Optionen, um die Einstellungen in Bezug auf Typ, Speicherort und erweiterte Bootloader-Einstellungen anzuzeigen und zu ändern. Sie können festlegen, ob GRUB 2 im Standardmodus oder im EFI-Modus verwendet werden soll.

Bootcode-Optionen
Abbildung 14.2: Bootcode-Optionen
 
Wichtig
Wichtig: GRUB2-EFI für EFI-Systeme erforderlich

Bei einem EFI-System können Sie nur GRUB2-EFI installieren, da das System ansonsten nicht mehr bootfähig ist.

Wichtig
Wichtig: Neuinstallation des Bootloaders

Um den Bootloader neu zu installieren, muss eine Einstellung in YaST geändert und wieder zurückgesetzt werden. Um beispielsweise GRUB2-EFI neu zu installieren, wählen Sie zuerst GRUB2 aus und wechseln Sie sofort wieder zurück zu GRUB2-EFI.

Ansonsten wird der Bootloader möglicherweise nur zum Teil neu installiert.

Anmerkung
Anmerkung: Benutzerdefinierter Bootloader

Wenn Sie einen anderen Bootloader außer den aufgeführten Bootloadern verwenden möchten, wählen Sie Keinen Bootloader installieren. Lesen Sie die Dokumentation Ihres Bootloaders sorgfältig durch, bevor Sie diese Option auswählen.

14.3.1 Speicherort des Bootloaders und Boot-Code-Optionen

 

Der Standardspeicherort des Bootloaders ist abhängig von der Partitionseinrichtung – es handelt sich entweder um den Master Boot Record (MBR) oder den Bootsektor der Partition /. Um den Speicherort des Bootloaders zu ändern, gehen Sie wie folgt vor:

Vorgehen 14.1: Speicherort des Bootloaders ändern
 

  1. Wählen Sie den Karteireiter Boot-Code-Optionen und anschließend eine der folgenden Optionen für Speicherort des Bootloaders:

    Booten vom Master Boot Record

    Hiermit wird der Bootloader in den MBR der Festplatte installiert, auf der sich das Verzeichnis /boot befindet. In der Regel ist dies die Festplatte, die in / eingehängt ist. Falls /boot in einer anderen Partition auf einer anderen Festplatte eingehängt ist, wird entsprechend der MBR der anderen Festplatte herangezogen.

    Booten von der root-Partition

    Der Bootloader wird in den Bootsektor der Partition / installiert.

    Benutzerdefinierte root-Partition

    Mit dieser Option können Sie den Speicherort des Bootloaders manuell angeben.

  2. Klicken Sie auf OK, um die Änderungen zu übernehmen.

Code-Optionen
Abbildung 14.3: Code-Optionen
 

Die Registerkarte Boot-Code-Optionen enthält die folgenden zusätzlichen Optionen:

Aktives Flag in Partitionstabelle für Bootpartition festlegen

Aktiviert die Partition, die das Verzeichnis /boot enthält. Bei POWER-Systemen wird die PReP-Partition aktiviert. Verwenden Sie diese Option auf Systemen mit älterem BIOS und/oder älteren Betriebssystemen, da diese Systeme unter Umständen nicht von einer nicht aktiven Partition gebootet werden können. Diese Option kann problemlos aktiviert bleiben.

Generischen Bootcode in MBR schreiben

Wenn der MBR einen benutzerdefinierten „Nicht-GRUB-Code“ enthält, ersetzt diese Option diesen Code durch einen generischen, betriebssystemunabhängigen Code. Wenn Sie diese Option deaktivieren, ist das System eventuell nicht mehr bootfähig.

Unterstützung für Trusted Boot aktivieren

Startet TrustedGRUB2, womit die Funktion für Trusted Computing (Trusted Platform Module (TPM)) unterstützt wird. Weitere Informationen finden Sie unter https://github.com/Sirrix-AG/TrustedGRUB2.

Der Abschnitt Flag für geschützten MBR enthält folgende Optionen:

set

Diese Option eignet sich für das herkömmliche Booten mit Legacy-BIOS.

entfernen

Diese Option eignet sich für das UEFI-Booten.

nicht ändern

Dies ist in der Regel die beste Option, wenn bereits ein funktionsfähiges System vorliegt.

In den meisten Fällen verwendet YaST standardmäßig die jeweils richtige Option.

14.3.2 Anpassen der Festplattenreihenfolge

 

Wenn der Rechner mit mehreren Festplatten ausgestattet ist, können Sie die Bootreihenfolge für die Festplatten festlegen. GRUB 2 wird auf der ersten Festplatte in der Liste installiert, wenn vom MBR gebootet wird. Auf dieser Festplatte wird SUSE Linux Enterprise Server standardmäßig installiert. Die restlichen Einträge in der Liste bilden Hinweise für den Geräte-Mapper von GRUB 2 (siehe Abschnitt 14.2.4, „Zuordnung von BIOS-Laufwerken und Linux-Geräten“).

Warnung
Warnung: Nicht bootfähiges System

Der Standardwert gilt in der Regel für nahezu alle Bereitstellungen. Wenn Sie die Bootreihenfolge der Festplatten falsch ändern, ist das System beim nächsten Booten unter Umständen nicht mehr bootfähig. Dies ist beispielsweise der Fall, wenn die erste Festplatte in der Liste nicht in der BIOS-Bootreihenfolge aufgeführt und der MBR der anderen Festplatten in der Liste leer ist.

Vorgehen 14.2: Festlegen der Festplattenreihenfolge
 

  1. Öffnen Sie den Karteireiter Boot-Code-Optionen.

  2. Klicken Sie auf Festplatten-Bootreihenfolge bearbeiten.

  3. Ändern Sie bei mehreren aufgeführten Festplatten deren Reihenfolge mit einem Klick auf Auf oder Ab.

  4. Klicken Sie zweimal auf OK, um die Änderungen zu speichern.

14.3.3 Konfigurieren der erweiterten Optionen

 

Erweiterte Bootparameter lassen sich über die Registerkarte Bootloader-Optionen konfigurieren.

14.3.3.1 Registerkarte Bootloader-Optionen

 
Bootloader-Optionen
Abbildung 14.4: Bootloader-Optionen
 
Zeitlimit des Bootloaders

Zum Ändern des Werts für Zeitüberschreitung in Sekunden geben Sie einen neuen Wert ein, und klicken Sie mit der Maus auf die entsprechenden Pfeilschaltfläche.

Fremdes OS testen

Mit dieser Option sucht der Bootloader nach anderen Systemen, z. B. Windows oder andere Linux-Installationen.

Menü beim Booten verbergen

Blendet das Bootmenü aus und bootet den Standardeintrag.

Anpassen des Standard-Boot-Eintrags

Wählen Sie den gewünschten Eintrag in der Liste „Standard-Bootabschnitt“ aus. Beachten Sie, dass das Zeichen „>“ im Namen des Booteintrags den Bootabschnitt und den zugehörigen Unterabschnitt begrenzt.

Bootloader durch Passwort schützen

Schützt den Bootloader und das System mit einem zusätzlichen Passwort. Details zur manuellen Konfiguration finden Sie in Abschnitt 14.2.6, „Festlegen eines Bootpassworts“. Das Bootpasswort muss bei jedem Booten eingegeben werden, wenn diese Option aktiviert ist. Das System wird also nicht automatisch gebootet. Wenn Sie jedoch das Verhalten von GRUB 1 bevorzugen, aktivieren Sie zusätzlich Nur Eintragsänderungen schützen. Bei dieser Einstellung darf jeder eine Boot-Eingabe auswählen und das System booten. Das Passwort für den GRUB 2 root-Benutzer ist jedoch nur zum Ändern der Boot-Einträge erforderlich.

14.3.3.2 Registerkarte Kernel-Parameter

 
Kernel-Parameter
Abbildung 14.5: Kernel-Parameter
 
Optionaler Kernel-Kommandozeilenparameter

Geben Sie hier optionale Kernel-Parameter an, um Systemfunktionen zu aktivieren/deaktivieren, Treiber hinzuzufügen usw.

CPU-Mitigationen

SUSE hat mindestens einen Kernel-Boot-Befehlszeilenparameter für alle Software-Mitigationen veröffentlicht, die zur Vorbeugung von CPU-Seitenkanalangriffen bereitgestellt wurden. Einige Parameter führen unter Umständen zu Leistungseinbußen. Bringen Sie die Sicherheit und Leistung je nach Ihrer Situation mit einer der folgenden Optionen ins Gleichgewicht:

Automatisch.  Aktiviert alle erforderlichen Mitigationen für Ihr CPU-Modell, schützt jedoch nicht vor CPU-übergreifenden Thread-Angriffen. Diese Einstellung kann die Leistung in gewissem Maße einschränken, je nach Auslastung.

Auto + kein SMT.  Aktiviert alle verfügbaren Sicherheitsmitigationen. Aktiviert alle erforderlichen Mitigationen für Ihr CPU-Modell. Darüber hinaus wird Simultaneous Multithreading (SMT) deaktiviert, sodass Seitenkanalangriffe über mehrere CPU-Threads unterbunden werden. Diese Einstellung kann die Leistung weiter einschränken, je nach Auslastung.

Aus.  Deaktiviert alle Mitigationen. Es sind Seitenkanalangriffe gegen die CPU möglich, je nach CPU-Modell. Diese Einstellung wirkt sich nicht auf die Leistung aus.

Manuell.  Gibt keine Mitigationsstufe vor. Legen Sie die CPU-Mitigationen manuell über die Kernel-Befehlszeilenoptionen fest.

Grafik-Konsole benutzen

Wenn diese Option aktiviert ist, wird das Bootmenü nicht im Textmodus dargestellt, sondern in einem grafischen Begrüßungsbildschirm. Die Auflösung des Bootbildschirms wird standardmäßig automatisch festgelegt, doch Sie können diese manuell über Konsolenauflösung festlegen. Die Datei mit der Definition des Grafikthemas wird mit der Konsolenthema-Dateiauswahl angegeben. Ändern Sie diese Einstellung nur, wenn Sie ein eigenes benutzerdefiniertes Thema anwenden möchten.

Serielle Konsole verwenden

Wenn Ihr Computer über eine serielle Konsole gesteuert wird, aktivieren Sie diese Option und geben Sie an, welcher COM-Port in welcher Geschwindigkeit verwendet werden soll. Siehe info grub oder http://www.gnu.org/software/grub/manual/grub.html#Serial-terminal.

14.4 Unterschiede bei der Terminalnutzung auf IBM Z

 

Auf 3215- und 3270-Terminals gelten bestimmte Unterschiede und Einschränkungen beim Bewegen des Cursors und beim Verwenden von Bearbeitungskommandos in GRUB 2.

14.4.1 Nutzungsbeschränkungen

 
Interaktivität

Die Interaktivität wird dringend empfohlen. Bei der Eingabe erfolgt häufig keine visuelle Rückmeldung. Zum Ermitteln der Cursorposition geben Sie einen Unterstrich (_) ein.

Anmerkung
Anmerkung: 3270 im Vergleich zu 3215

Das 3270-Terminal bietet eine bessere Darstellung und Bildschirmaktualisierung als das 3215-Terminal.

Cursorbewegung

Die „herkömmliche“ Cursorbewegung ist nicht möglich. Alt, Meta, Strg und die Cursortasten sind nicht funktionsfähig. Bewegen Sie den Cursor mit den Tastenkombinationen in Abschnitt 14.4.2, „Tastenkombinationen“.

Caret

Das Caret ^ dient als Steuerzeichen. Zur Eingabe eines Buchstabens mit Caret ^ geben Sie Folgendes ein: ^, ^, BUCHSTABE.

Geben Sie ein:

Die Eingabetaste-Taste ist nicht funktionsfähig; drücken Sie stattdessen ^–J.

14.4.2 Tastenkombinationen

 

Häufig ersetzt durch:

^–J

Erfassen („Eingabetaste“)

^–L

Abbrechen, zum letzten „Status“ zurückkehren

^–I

Karteireiter ausfüllen (im Bearbeitungs- und Shell-Modus)

Verfügbare Tasten im Menümodus:

^–A

Erster Eintrag

^–E

Letzter Eintrag

^–P

Vorheriger Eintrag

^–N

Nächster Eintrag

^–G

Vorherige Seite

^–C

Nächste Seite

^–F

Ausgewählten Eintrag booten oder Untermenü öffnen (entspricht ^–J)

E

Ausgewählten Eintrag bearbeiten

C

GRUB-Shell öffnen

Verfügbare Tasten im Bearbeitungsmodus:

^–P

Vorherige Zeile

^–N

Nächste Zeile

^–B

Ein Zeichen zurück

^–F

Ein Zeichen weiter

^–A

Zeilenanfang

^–E

Zeilenende

^–H

Rücktaste

^–D

Löschen

^–K

Zeile schließen

^–Y

Kopieren

^–O

Zeile öffnen

^–L

Bildschirm aktualisieren

^–X

Eintrag booten

^–C

GRUB-Shell öffnen

Verfügbare Tasten im Kommandozeilenmodus:

^–P

Vorheriges Kommando

^–N

Nächstes Kommando im Verlauf

^–A

Zeilenanfang

^–E

Zeilenende

^–B

Ein Zeichen zurück

^–F

Ein Zeichen weiter

^–H

Rücktaste

^–D

Löschen

^–K

Zeile schließen

^–U

Zeile verwerfen

^–Y

Kopieren

14.5 Nützliche Kommandos in GRUB 2

 
grub2-mkconfig

Hiermit wird eine neue Datei /boot/grub2/grub.cfg auf der Grundlage von /etc/default/grub und der Skripten in /etc/grub.d/ erzeugt.

Beispiel 14.1: Verwendung von grub2-mkconfig
 
grub2-mkconfig -o /boot/grub2/grub.cfg
Tipp
Tipp: Syntaxprüfung

Wenn Sie grub2-mkconfig ohne Parameter ausführen, wird die Konfiguration an STDOUT ausgegeben und kann dort abgerufen werden. Zur Syntaxprüfung führen Sie grub2-script-check aus, sobald die Datei /boot/grub2/grub.cfg geschrieben wurde.

Wichtig
Wichtig: Mit grub2-mkconfig können UEFI Secure-Boottabellen nicht repariert werden

Wenn Sie UEFI Secure Boot verwenden und Ihr System GRUB 2 nicht mehr ordnungsgemäß erreichen kann, müssen Sie möglicherweise zusätzlich Shim neu installieren und die UEFI-Boottabelle regenerieren. Verwenden Sie hierzu das folgende Kommando: 

root # shim-install --config-file=/boot/grub2/grub.cfg
grub2-mkrescue

Hiermit wird ein bootfähiges Rettungs-Image der installierten GRUB 2-Konfiguration erstellt.

Beispiel 14.2: Verwendung von grub2-mkrescue
 
grub2-mkrescue -o save_path/name.iso iso
grub2-script-check

Hiermit prüfen Sie die angegebene Datei auf Syntaxfehler.

Beispiel 14.3: Verwendung von grub2-script-check
 
grub2-script-check /boot/grub2/grub.cfg
grub2-once

Hiermit legen Sie den Standard-Booteintrag für den nächsten Bootvorgang fest (dies wird nicht dauerhaft gespeichert). Mit der Option --list erhalten Sie eine Liste der verfügbaren Booteinträge.

Beispiel 14.4: Verwendung von grub2-once
 
grub2-once number_of_the_boot_entry
Tipp
Tipp: grub2-once-Hilfe

Wenn Sie das Programm ohne Angabe von Optionen aufrufen, erhalten Sie eine vollständige Liste der zulässigen Optionen.

14.6 Weitere Informationen

 

Umfassende Informationen zu GRUB 2 finden Sie unter https://www.gnu.org/software/grub/. Ausführliche Informationen finden Sie auch auf der Infoseite für das Kommando grub. Weitere Informationen zu bestimmten Themen erhalten Sie auch, wenn Sie „GRUB 2“ in der Suchfunktion für technische Informationen unter https://www.suse.com/support als Suchwort eingeben.

15 Der Daemon systemd

 

systemd ist für die Initialisierung des Systems verantwortlich und trägt die Prozess-ID 1. systemd wird direkt vom Kernel gestartet und widersteht dem Signal 9, das in der Regel Prozesse beendet. Alle anderen Programme werden entweder direkt von systemd oder von einem seiner untergeordneten Prozesse gestartet. systemd ersetzt den System-V-init-Daemon und ist (durch die Unterstützung von init-Skripten) uneingeschränkt mit System-V-init kompatibel.

Der wichtigste Vorteil von systemd ist der erheblich schnellere Systemstart durch die Parallelisierung der Dienststarts. Darüber hinaus startet systemd einen Dienst nur dann, wenn er tatsächlich benötigt wird. Deamons werden nicht in jedem Fall beim Booten gestartet, sondern erst dann, wenn sie erstmalig benötigt werden. systemd unterstützt außerdem Kernel-Steuergruppen (cgroups), das Erstellen von Snapshots und das Wiederherstellen des Systemstatus. Weitere Einzelheiten finden Sie unter http://www.freedesktop.org/wiki/Software/systemd/.

15.1 Das Konzept von systemd

 

Im folgenden Abschnitt wird das Konzept hinter systemd erläutert.

systemd ist ein System- und Sitzungsmanager für Linux und ist mit System V- und LSB-init-Skripts kompatibel. Die wichtigsten Funktionen von systemd:

  • Parallelisierungsfunktionen

  • Socket- und D-Bus-Aktivierung zum Starten von Diensten

  • Starten der Daemons bei Bedarf

  • Verfolgen von Prozessen mithilfe von Linux-cgroups

  • Erstellen von Snapshots und Wiederherstellen des Systemstatus

  • Einhängepunkte und Automount-Punkte

  • Ausgereifte Dienststeuerlogik auf der Basis der Transaktionsabhängigkeiten

15.1.1 Unit-Datei

 

Eine Unit-Konfigurationsdatei enthält Informationen zu einem Dienst, Socket, Gerät, Einhängepunkt, Automount-Punkt, einer Auslagerungsdatei oder Partition, einem Startziel, einem überwachten Dateisystempfad, einem von systemd gesteuerten und überwachten Zeitgeber, einem Snapshot eines temporären Systemstatus, einem Ressourcenverwaltungs-Slice oder einer Gruppe extern erstellter Prozesse.

„Unit-Datei“ ist in systemd ein generischer Term für Folgendes:

  • Dienst.  Informationen zu einem Prozess (z. B. Ausführung eines Daemon); Datei endet auf .service

  • Zielgruppen.  Fassen Units zu Gruppen zusammen bzw. fungieren als Synchronisierungspunkte beim Starten; Datei endet auf .target

  • Sockets.  Informationen zu einem IPC- oder Netzwerk-Socket oder einem Dateisystem-FIFO, für die socketbasierte Aktivierung (wie inetd); Datei endet auf .socket

  • Path.  Dient als Auslöser von anderen Units (z. B. Ausführen eines Dienstes, wenn Dateien geändert werden); Datei endet auf .path

  • Zeitgeber.  Informationen zu einem gesteuerten Zeitgeber für die zeitgeberbasierte Aktivierung; Datei endet auf .timer

  • Einhängepunkt.  In der Regel automatisch durch den fstab-Generator erzeugt; Datei endet auf .mount

  • Automount-Punkt.  Informationen zu einem Dateisystem-Automount-Punkt; Datei endet auf .automount

  • Swap.  Informationen zu einem Auslagerungsgerät oder einer Auslagerungsdatei für das Arbeitsspeicher-Paging; Datei endet auf .swap

  • Gerät.  Informationen zu einer Geräte-Unit in der Geräte-Baumstruktur sysfs/udev(7); Datei endet auf .device

  • Bereich/Slice.  Konzept für die hierarchische Verwaltung von Ressourcen einer Prozessgruppe; Datei endet auf .scope/.slice

Weitere Informationen zu systemd-Unit-Dateien finden Sie in http://www.freedesktop.org/software/systemd/man/systemd.unit.html

15.2 Grundlegende Verwendung

 

Im System V-init-System werden Dienste mit mehreren Kommandos verarbeitet – mit init-Skripten, insserv, telinit und anderen. systemd erleichtert die Dienstverwaltung, da ein einziges Kommando die meisten Dienstverarbeitungsaufgaben abdeckt: systemctl. Hierbei gilt die Syntax „Kommando plus Subkommando“ wie bei git oder zypper: 

systemctl GENERAL OPTIONS SUBCOMMAND SUBCOMMAND OPTIONS

Vollständige Anweisungen finden Sie in man 1 systemctl.

Tipp
Tipp: Terminalausgabe und Bash-Vervollständigung

Wenn die Ausgabe an ein Terminal geht (und nicht an eine Pipe oder Datei usw.), senden die systemd-Kommandos standardmäßig eine ausführliche Ausgabe an einen Pager. Mit der Option --no-pager deaktivieren Sie den Paging-Modus.

systemd unterstützt außerdem die Bash-Vervollständigung. Hierbei geben Sie die ersten Buchstaben eines Subkommandos ein und drücken dann →|. Diese Funktion ist nur in der Bash-Shell verfügbar und das Paket bash-completion muss installiert sein.

15.2.1 Verwalten von Diensten auf einem laufenden System

 

Die Subkommandos zum Verwalten der Dienste sind mit den entsprechenden Kommandos in System V-init identisch (start, stop usw.). Die allgemeine Syntax für Dienstverwaltungskommandos lautet wie folgt:

systemd
systemctl reload|restart|start|status|stop|... MY_SERVICE(S)
System V-init
rcMY_SERVICE(S) reload|restart|start|status|stop|...

Mit systemd können Sie mehrere Dienste gleichzeitig verwalten. Im Gegensatz zu System V-init, bei dem die init-Skripts einzeln nacheinander ausgeführt werden, führen Sie ein einziges Kommando aus, beispielsweise: 

tux > sudo systemctl start MY_1ST_SERVICE MY_2ND_SERVICE

So rufen Sie eine Liste aller auf dem System verfügbaren Dienste ab: 

tux > sudo systemctl list-unit-files --type=service

Die folgende Tabelle zeigt die wichtigsten Dienstverwaltungskommandos für systemd und System V-init:

Tabelle 15.1: Kommandos zur Dienstverwaltung
 

Aufgabe

systemd-Kommando

System V-init-Kommando

Starten. 

 
start
 
start

Stoppen. 

 
stop
 
stop

Neu starten.  Fährt Dienste herunter und startet sie dann neu. Wenn ein Dienst noch nicht ausgeführt wird, wird er gestartet. 

restart
 
restart

Bedingt neu starten.  Startet Dienste neu, wenn sie derzeit ausgeführt werden. Keine Auswirkung bei Diensten, die nicht ausgeführt werden. 

try-restart
 
try-restart

Neu laden.  Weist die Dienste an, die Konfigurationsdateien neu zu laden ohne die laufenden Vorgänge zu unterbrechen. Anwendungsbeispiel: Weisen Sie Apache an, eine bearbeitete Konfigurationsdatei httpd.conf neu zu laden. Nicht alle Dienste unterstützen das Neuladen. 

reload
 
reload

Neu laden oder neu starten.  Lädt Dienste neu, wenn das Neuladen unterstützt wird; ansonsten werden die Dienste neu gestartet. Wenn ein Dienst noch nicht ausgeführt wird, wird er gestartet. 

reload-or-restart
 
n/a

Bedingt neu laden oder neu starten.  Lädt Dienste neu, wenn das Neuladen unterstützt wird; ansonsten werden die Dienste neu gestartet, wenn sie derzeit ausgeführt werden. Keine Auswirkung bei Diensten, die nicht ausgeführt werden. 

reload-or-try-restart
 
n/a

Ausführliche Statusinformationen abrufen.  Zeigt Informationen zum Dienststatus. Das Kommando systemd bietet Details wie Beschreibung, ausführbare Datei, Status, cgroup und zuletzt durch den Dienst ausgegebene Meldungen (siehe Abschnitt 15.6.9, „Fehlersuche für Dienste“). Die Detailtiefe bei System V-init ist von Dienst zu Dienst unterschiedlich. 

status
 
status

Kurze Statusinformationen abrufen.  Gibt an, ob Dienste aktiv sind oder nicht. 

is-active
 
status

15.2.2 Dienste dauerhaft aktivieren/deaktivieren

 

Mit den Dienstverwaltungskommandos im vorangegangenen Abschnitt können Sie die Dienste für die aktuelle Sitzung bearbeiten. Mit systemd können Sie Dienste außerdem dauerhaft aktivieren oder deaktivieren, so dass sie entweder automatisch bei Bedarf gestartet werden oder gar nicht verfügbar sind. Sie können dies mithilfe von YaST oder über die Kommandozeile tun.

15.2.2.1 Aktivieren/Deaktivieren von Diensten über die Kommandozeile

 

Die folgende Tabelle zeigt die wichtigsten Aktivierungs- und Deaktivierungskommandos für systemd und System V-init:

Wichtig
Wichtig: Dienststart

Wenn ein Dienst über die Kommandozeile aktiviert wird, wird er nicht automatisch gestartet. Der Dienst wird beim nächsten Systemstart oder bei der nächsten Änderung des Runlevels/Ziels gestartet. Soll ein Dienst nach dem Aktivieren sofort gestartet werden, führen Sie explizit systemctl start MEIN_DIENST oder rc MEIN_DIENST start aus.

Tabelle 15.2: Kommandos zum Aktivieren und Deaktivieren von Diensten
 

Aufgabe

systemd-Kommando

System V-init-Kommando

Aktivieren. 

systemctl enable MEIN(E)_DIENST(E)

insserv MEIN(E)_DIENST(E), chkconfig -a MEIN(E)_DIENST(E)

Deaktivieren. 

systemctl disable MEIN(E)_DIENST(E).service

insserv -r MEIN(E)_DIENST(E), chkconfig -d MEIN(E)_DIENST(E)

Überprüfen.  Zeigt an, ob ein Dienst aktiviert ist oder nicht.

systemctl is-enabled MEIN_DIENST

chkconfig MEIN_DIENST

Erneut aktivieren.  Ähnlich wie beim Neustarten eines Diensts, deaktiviert dieses Kommando einen Dienst und aktiviert ihn dann wieder. Nützlich, wenn ein Dienst mit den Standardeinstellungen erneut aktiviert werden soll.

systemctl reenable MEIN_DIENST

n/v

Maskierung.  Nach dem „Deaktivieren“ eines Dienstes kann er weiterhin manuell aktiviert werden. Soll ein Dienst vollständig deaktiviert werden, maskieren Sie ihn. Mit Vorsicht verwenden.

systemctl mask MEIN_DIENST

n/v

Demaskieren.  Ein maskierter Dienst kann erst dann wieder genutzt werden, wenn er demaskiert wurde.

systemctl unmask MEIN_DIENST

n/v

15.3 Systemstart und Zielverwaltung

 

Der gesamte Vorgang des Startens und Herunterfahrens des Systems wird von systemd verwaltet. Von diesem Gesichtspunkt aus kann der Kernel als Hintergrundprozess betrachtet werden, der alle anderen Prozesse verwaltet und die CPU-Zeit sowie den Hardwarezugriff entsprechend den Anforderungen anderer Programme anpasst.

15.3.1 Ziele im Vergleich zu Runlevels

 

Bei System V-init wurde das System in ein sogenanntes „Runlevel“ gebootet. Ein Runlevel definiert, wie das System gestartet wird und welche Dienste im laufenden System verfügbar sind. Die Runlevels sind numeriert. Die bekanntesten Runlevels sind 0 (System herunterfahren), 3 (Mehrbenutzermodus mit Netzwerk) und 5 (Mehrbenutzermodus mit Netzwerk und Anzeigemanager).

systemd führt mit den sogenannten „Ziel-Units ein neues Konzept ein“. Dennoch bleibt die Kompatibilität mit dem Runlevel-Konzept uneingeschränkt erhalten. Die Ziel-Units tragen Namen statt Zahlen und erfüllen bestimmte Zwecke. Mit den Zielen local-fs.target und swap.target werden beispielsweise lokale Dateisysteme und Auslagerungsbereiche eingehängt.

Das Ziel graphical.target stellt ein Mehrbenutzersystem mit Netzwerk sowie Anzeigemanager-Funktionen bereit und entspricht Runlevel 5. Komplexe Ziele wie graphical.target fungieren als „Metaziele“, in denen eine Teilmenge anderer Ziele vereint ist. Mit systemd können Sie problemlos vorhandene Ziele kombinieren und so benutzerdefinierte Ziele bilden. Damit bietet dieses Kommando eine hohe Flexibilität.

Die nachfolgende Liste zeigt die wichtigsten systemd-Ziel-Units. Eine vollständige Liste finden Sie in man 7 systemd.special.

Ausgewählte systemd-Ziel-Units
 
default.target

Das Ziel, das standardmäßig gebootet wird. Kein „reales“ Ziel, sondern ein symbolischer Link zu einem anderen Ziel wie graphic.target. Kann über YaST dauerhaft geändert werden (siehe Abschnitt 15.4, „Verwalten von Diensten mit YaST“). Soll das Ziel für eine einzige Sitzung geändert werden, geben Sie den Kernel-Parameter systemd.unit=MEIN_ZIEL.target am Bootprompt ein.

emergency.target

Startet eine Notfall-Shell über die Konsole. Dieses Kommando darf nur an der Boot-Eingabeaufforderung im Format systemd.unit=emergency.target verwendet werden.

graphical.target

Startet ein System mit Netzwerk, Mehrbenutzerunterstützung und Anzeigemanager.

halt.target

Fährt das System herunter.

mail-transfer-agent.target

Startet alle Dienste, die zum Senden und Empfangen von Mails erforderlich sind.

multi-user.target

Startet ein Mehrbenutzersystem mit Netzwerk.

reboot.target

Bootet das System neu.

rescue.target

Startet ein Einzelbenutzersystem ohne Netzwerk.

Damit die Kompatibilität mit dem Runlevel-System von System V-init gewährleistet bleibt, bietet systemd besondere Ziele mit der Bezeichnung runlevelX.target, denen die entsprechenden, mit X nummerierten Runlevels zugeordnet sind.

Mit dem Kommando systemctl get-default ermitteln Sie das aktuelle Ziel.

Tabelle 15.3: System V-Runlevels und systemd-Ziel-Units
 

System V-Runlevel

systemd-Ziel

Beschreibung

0

runlevel0.target, halt.target, poweroff.target

System herunterfahren

1, S

runlevel1.target, rescue.target,

Einzelbenutzermodus

2

runlevel2.target, multi-user.target,

Lokaler Mehrbenutzermodus ohne entferntes Netzwerk

3

runlevel3.target, multi-user.target,

Mehrbenutzer-Vollmodus mit Netzwerk

4

runlevel4.target

Nicht verwendet/benutzerdefiniert

5

runlevel5.target, graphical.target,

Mehrbenutzer-Vollmodus mit Netzwerk und Anzeige-Manager

6

runlevel6.target, reboot.target,

Systemneustart

Wichtig
Wichtig: systemd ignoriert /etc/inittab

Die Runlevels in einem System V-init-System werden in /etc/inittab konfiguriert. Bei systemd wird diese Konfiguration nicht verwendet. Weitere Anweisungen zum Erstellen eines bootfähigen Ziels finden Sie unter Abschnitt 15.5.4, „Erstellen von benutzerdefinierten Zielen“.

15.3.1.1 Kommandos zum Ändern von Zielen

 

Mit den folgenden Kommandos arbeiten Sie mit den Ziel-Units:

Aufgabe

systemd-Kommando

System V-init-Kommando

Aktuelles Ziel/Runlevel ändern

systemctl isolate MEIN_ZIEL.target

telinit X

Zum standardmäßigen Ziel/Runlevel wechseln

systemctl default

n/v

Aktuelles Ziel/Runlevel abrufen

systemctl list-units --type=target

Bei systemd sind in der Regel mehrere Ziele aktiv. Mit diesem Kommando werden alle derzeit aktiven Ziele aufgelistet.

who -r

oder

runlevel

Standard-Runlevel dauerhaft ändern

Verwenden Sie die Dienste-Verwaltung, oder führen Sie das folgende Kommando aus:

ln -sf /usr/lib/systemd/system/ MEIN_ZIEL.target /etc/systemd/system/default.target

Verwenden Sie die Dienste-Verwaltung, oder ändern Sie die Zeile

id: X:initdefault:

in /etc/inittab

Standard-Runlevel für den aktuellen Bootprozess ändern

Geben Sie an der Boot-Eingabeaufforderung die folgende Option ein:

systemd.unit= MEIN_ZIEL.target

Geben Sie an der Boot-Eingabeaufforderung die gewünschte Runlevel-Nummer ein.

Abhängigkeiten für ein Ziel/Runlevel anzeigen

systemctl show -p "Requires" MEIN_ZIEL.target

systemctl show -p "Wants" MEIN_ZIEL.target

„Requires“ (Benötigt) zeigt eine Liste der harten Abhängigkeiten (die in jedem Fall aufgelöst werden müssen), „Wants“ (Erwünscht) dagegen eine Liste der weichen Abhängigkeiten (die nach Möglichkeit aufgelöst werden).

n/v

15.3.2 Fehlersuche beim Systemstart

 

systemd bietet eine Möglichkeit, den Systemstartvorgang zu analysieren. Sie können die Liste der Services mit dem jeweiligen Status prüfen (ohne durch /var/log/ blättern zu müssen). Mit systemd können Sie zudem den Startvorgang scannen und so ermitteln, wie lang das Starten der einzelnen Dienste dauert.

15.3.2.1 Prüfen des Startvorgangs der Dienste

 

Mit dem Kommando systemctl erzeugen Sie eine Liste aller Dienste, die seit dem Booten des Systems gestartet wurden. Hier werden alle aktiven Dienste wie im nachstehenden (gekürzten) Beispiel aufgeführt. Mit systemctl status MEIN_DIENST erhalten Sie weitere Informationen zu einem bestimmten Dienst.

Beispiel 15.1: Liste der aktiven Dienste
 
root # systemctl
UNIT                        LOAD   ACTIVE SUB       JOB DESCRIPTION
[...]
iscsi.service               loaded active exited    Login and scanning of iSC+
kmod-static-nodes.service   loaded active exited    Create list of required s+
libvirtd.service            loaded active running   Virtualization daemon
nscd.service                loaded active running   Name Service Cache Daemon
chronyd.service             loaded active running   NTP Server Daemon
polkit.service              loaded active running   Authorization Manager
postfix.service             loaded active running   Postfix Mail Transport Ag+
rc-local.service            loaded active exited    /etc/init.d/boot.local Co+
rsyslog.service             loaded active running   System Logging Service
[...]
LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

161 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.

Soll die Ausgabe auf Dienste beschränkt werden, die nicht gestartet werden konnten, geben Sie die Option --failed an:

Beispiel 15.2: Liste der fehlerhaften Dienste
 
root # systemctl --failed
UNIT                   LOAD   ACTIVE SUB    JOB DESCRIPTION
apache2.service        loaded failed failed     apache
NetworkManager.service loaded failed failed     Network Manager
plymouth-start.service loaded failed failed     Show Plymouth Boot Screen

[...]

15.3.2.2 Fehlersuche für die Startzeit

 

Mit dem Kommando systemd-analyze führen Sie die Fehlersuche für die Startzeit durch. Hiermit werden der Gesamtzeitaufwand für den Startvorgang sowie eine Liste der beim Starten angeforderten Dienste angezeigt. Auf Wunsch kann auch eine SVG-Grafik erstellt werden, aus der hervorgeht, wie lange der Start der Dienste im Vergleich zu den anderen Diensten dauerte.

Auflisten der Startzeit des Systems
root # systemd-analyze
Startup finished in 2666ms (kernel) + 21961ms (userspace) = 24628ms
Auflisten der Startzeit der Dienste
root # systemd-analyze blame
    15.000s backup-rpmdb.service
    14.879s mandb.service
     7.646s backup-sysconfig.service
     4.940s postfix.service
     4.921s logrotate.service
     4.640s libvirtd.service
     4.519s display-manager.service
     3.921s btrfsmaintenance-refresh.service
     3.466s lvm2-monitor.service
     2.774s plymouth-quit-wait.service
     2.591s firewalld.service
     2.137s initrd-switch-root.service
     1.954s ModemManager.service
     1.528s rsyslog.service
     1.378s apparmor.service
    [...]
Grafische Darstellung der Startzeit der Dienste
root # systemd-analyze plot > jupiter.example.com-startup.svg
Image

15.3.2.3 Prüfen des gesamten Startvorgangs

 

Mit den obigen Kommandos werden die gestarteten Dienste und ihre Startzeiten aufgelistet. Eine detailliertere Übersicht erhalten Sie, wenn Sie folgende Parameter an der Boot-Eingabeaufforderung angeben, damit systemd ein ausführliches Protokoll des gesamten Startvorgangs erstellt. 

systemd.log_level=debug systemd.log_target=kmsg

systemd schreibt die Protokollmeldungen nunmehr in den Kernel-Ringpuffer. Diesen Puffer zeigen Sie mit dmesg an: 

tux > dmesg -T | less

15.3.3 System V-Kompatibilität

 

systemd ist mit System V kompatibel, sodass Sie vorhandene System V-init-Skripte weiterhin nutzen können. Es gibt allerdings mindestens ein bekanntes Problem, bei dem ein System V-init-Skript nicht ohne Weiteres mit systemd zusammenarbeitet: Wenn Sie einen Dienst als ein anderer Benutzer über su oder sudo in init-Skripten starten, tritt der Fehler „Access denied“ (Zugriff verweigert) auf.

Wenn Sie den Benutzer mit su oder sudo ändern, wird eine PAM-Sitzung gestartet. Diese Sitzung wird beendet, sobald das init-Skript abgeschlossen ist. Als Folge wird auch der Service, der durch das init-Skript gestartet wurde, beendet. Als Workaround für diesen Fehler gehen Sie wie folgt vor:

  1. Erstellen Sie einen Service-Datei-Wrapper mit demselben Namen wie das init-Skript und der Dateinamenerweiterung .service: 

    [Unit]
Description=DESCRIPTION
After=network.target

[Service]
User=USER
Type=forking1
PIDFile=PATH TO PID FILE1
ExecStart=PATH TO INIT SCRIPT start
ExecStop=PATH TO INIT SCRIPT stop
ExecStopPost=/usr/bin/rm -f PATH TO PID FILE1

[Install]
WantedBy=multi-user.target2

    Ersetzen Sie alle Werte in GROSSBUCHSTABEN durch die entsprechenden Werte.

    1

    Optional; nur zu verwenden, wenn mit dem init-Skript ein Daemon gestartet wird.

    2

    multi-user.target startet ebenfalls das init-Skript, wenn Sie in graphical.target booten. Falls der Start nur beim Booten in den Display-Manager erfolgen soll, verwenden Sie hier graphical.target.

  2. Starten Sie den Daemon mit systemctl start ANWENDUNG.

15.4 Verwalten von Diensten mit YaST

 

Grundlegende Aufgaben können auch mit dem YaST-Modul Dienste-Verwaltung ausgeführt werden. Hiermit werden das Starten, Stoppen, Aktivieren und Deaktivieren von Diensten unterstützt. Darüber hinaus können Sie den Status eines Dienstes abrufen und das Standardziel ändern. Starten Sie das YaST-Modul mit YaST › System › Dienste-Verwaltung.

Services Manager
Abbildung 15.1: Services Manager
 
Ändern des Standard-Systemziels

Zum Ändern des Ziels, in das das System gebootet wird, wählen Sie ein Ziel in der Dropdown-Liste Default System Target aus. Die häufigsten Ziele sind Graphical Interface (Grafische Oberfläche; öffnet einen grafischen Anmeldebildschirm) und Multi-User (Mehrbenutzer; startet das System im Kommandozeilenmodus).

Starten oder Stoppen eines Dienstes

Wählen Sie einen Dienst in der Tabelle aus. Die Spalte Aktiv zeigt, ob er derzeit ausgeführt wird (Aktiv) oder nicht (Inaktiv). Mit Starten bzw. Stoppen schalten Sie den Status um.

Durch das Starten und Stoppen eines Dienstes wird sein Status für die aktuelle Sitzung geändert. Soll der Status beim Neubooten geändert werden, müssen Sie den Dienst aktivieren oder deaktivieren.

Definieren des Verhaltens beim Starten von Diensten

Dienste können entweder automatisch bei Booten oder manuell gestartet werden. Wählen Sie einen Dienst in der Tabelle aus. Die Spalte Start zeigt, ob er derzeit gestartet ist Manuell oder Beim Booten. Mit Startmodus schalten Sie den Status um.

Um den Status eines Dienstes in der aktuellen Sitzung zu ändern, müssen Sie ihn wie oben beschrieben starten oder stoppen.

Anzeigen von Statusmeldungen

Zum Anzeigen der Statusmeldungen für einen Dienst wählen Sie den gewünschten Dienst in der Liste aus und wählen Sie Details anzeigen. Die Ausgabe ist mit der Ausgabe des Befehls systemctl -l status MEIN_DIENST identisch.

15.5 Anpassen von systemd

 

In den folgenden Abschnitten finden Sie einige Beispiele, wie Sie systemd individuell anpassen.

Warnung
Warnung: Verhindern des Überschreibens Ihrer Anpassung

Wenn Sie systemd anpassen, verwenden Sie stets das Verzeichnis /etc/systemd/, nie das Verzeichnis /usr/lib/systemd/. Ansonsten werden Ihre Änderungen bei der nächsten Aktualisierung von systemd überschrieben.

15.5.1 Anpassen von Unit-Dateien

 

Zum Anpassen von Unit-Dateien wird das Kommando systemctl edit DIENST empfohlen. Dieses Kommando startet den Standardtexteditor und erstellt ein Verzeichnis mit der Datei override.conf file unter /etc/systemd/system/NAME.service.d/. Das Kommando benachrichtigt außerdem den laufenden systemd-Vorgang über die Änderungen.

Alternativ können Sie mit dem Kommando systemctl edit --full DIENST eine Kopie der Originaldatei zum Bearbeiten anstelle einer leeren Datei öffnen. Achten Sie beim Bearbeiten der Datei darauf, alle vorhandenen Abschnitte beizubehalten.

Ändern Sie als Übung den Zeitraum, den das System auf den Start von MariaDB warten soll. Führen Sie als root das Kommando systemctl edit --full mariadb.service aus. Die geöffnete Datei ist in etwa wie folgt aufgebaut: 

[Unit]
Description=MySQL server
Wants=basic.target
Conflicts=mariadb.target
After=basic.target network.target

[Install]
WantedBy=multi-user.target
Alias=mysql.service

[Service]
Restart=on-abort
Type=notify
ExecStartPre=/usr/lib/mysql/mysql-systemd-helper  install
ExecStartPre=/usr/lib/mysql/mysql-systemd-helper  upgrade
ExecStart=/usr/lib/mysql/mysql-systemd-helper     start

# Configures the time to wait for start-up/stop
TimeoutSec=300

# Prevent writes to /usr, /boot, and /etc
ProtectSystem=full

# Prevent accessing /home, /root and /run/user
ProtectHome=true

UMask=007

Passen Sie den Wert für TimeoutSec an und speichern Sie die Änderungen. Zum Aktivieren der Änderungen führen Sie als root das Kommando systemctl daemon-reload aus.

Weitere Informationen finden Sie auf den man-Seiten, die Sie mit dem Kommando man 1 systemctl aufrufen können.

15.5.2 Erstellen von Drop-in-Dateien

 

Bei kleineren Änderungen an einer Konfigurationsdatei verwenden Sie sogenannte Drop-in-Dateien. Mit den Drop-in-Dateien erweitern Sie die Konfiguration von Unit-Dateien, ohne die Unit-Dateien selbst bearbeiten oder überschreiben zu müssen.

Um beispielsweise einen einzigen Wert für den Dienst foobar in /usr/lib/systemd/system/ foobar.service zu ändern, gehen Sie wie folgt vor:

  1. Erstellen Sie ein Verzeichnis mit dem Namen /etc/systemd/system/FOOBAR.service.d/.

    Beachten Sie das Suffix .d. Ansonsten muss der Name des Verzeichnisses mit dem Namen des Dienstes übereinstimmen, der mit der Drop-in-Datei gepatcht werden soll.

  2. Erstellen Sie in diesem Verzeichnis eine Datei mit dem Namen your_modification.conf.

    Diese Datei darf nur eine Zeile mit dem zu ändernden Wert enthalten.

  3. Speichern Sie Ihre Änderungen in die Datei.

Anmerkung
Anmerkung: Vermeiden von Namenskonflikten

Um Namenskonflikte zwischen Ihren Drop-in-Dateien und den von SUSE bereitgestellten Dateien zu vermeiden, wird empfohlen, allen Drop-in-Dateinamen eine zweistellige Zahl und einen Bindestrich voranzustellen, beispielsweise 80-override.conf.

Die folgenden Bereiche sind reserviert:

  • 0-19 ist für systemd-Upstream reserviert

  • 20-25 ist für systemd reserviert (von SUSE bereitgestellt)

  • 26-29 ist für SUSE-Pakete reserviert (außer systemd)

  • 50 ist für Drop-in-Dateien reserviert, die mit systemctl set-property erstellt werden.

Geben Sie eine zweistellige Zahl oberhalb dieses Bereichs an, damit die von SUSE bereitgestellten Drop-in-Dateien Ihre eigenen Drop-in-Dateien nicht überschreiben.

Mit systemctl cat $UNIT können Sie die Dateien auflisten und überprüfen, die in der Unit-Konfiguration berücksichtigt werden.

15.5.3 Konvertieren von xinetd-Diensten in systemd

 

Seit der Version SUSE Linux Enterprise Server 15 wurde die xinetd-Infrastruktur entfernt. In diesem Abschnitt wird beschrieben, wie Sie vorhandene benutzerdefinierte xinetd-Dienstdateien in systemd-Sockets konvertieren.

Für jede xinetd-Dienstdatei benötigen Sie mindestens zwei systemd-Unit-Dateien: die Socket-Datei (*.socket) und eine zugehörige Dienstdatei (*.service). Die Socket-Datei weist systemd an, welcher Socket erstellt werden soll, und die Dienstdatei weist systemd an, welche ausführbare Datei gestartet werden soll.

Betrachten Sie das folgende Beispiel für eine xinetd-Dienstdatei: 

root # cat /etc/xinetd.d/example
service example
{
  socket_type = stream
  protocol = tcp
  port = 10085
  wait = no
  user = user
  group = users
  groups = yes
  server = /usr/libexec/example/exampled
  server_args = -auth=bsdtcp exampledump
  disable = no
}

Zum Konvertieren in systemd benötigen Sie die folgenden beiden Dateien: 

root # cat /usr/lib/systemd/system/example.socket
[Socket]
ListenStream=0.0.0.0:10085
Accept=false

[Install]
WantedBy=sockets.target
root # cat /usr/lib/systemd/system/example.service
[Unit]
Description=example

[Service]
ExecStart=/usr/libexec/example/exampled -auth=bsdtcp exampledump
User=user
Group=users
StandardInput=socket

Eine vollständige Liste der Socket- und Dienstdateioptionen für systemd finden Sie auf den man-Seiten zu systemd.socket und systemd.service (man 5 systemd.socket, man 5 systemd.service).

15.5.4 Erstellen von benutzerdefinierten Zielen

 

Auf SUSE-Systemen mit System V-init wird Runlevel 4 nicht genutzt, so dass die Administratoren eine eigene Runlevel-Konfiguration erstellen können. Mit systemd können Sie beliebig viele benutzerdefinierte Ziele erstellen. Zum Einstieg sollten Sie ein vorhandenes Ziel anpassen, beispielsweise graphical.target.

  1. Kopieren Sie die Konfigurationsdatei /usr/lib/systemd/system/graphical.target in /etc/systemd/system/MEIN_ZIEL.target und passen Sie sie nach Bedarf an.

  2. Die im vorangegangenen Schritt kopierte Konfigurationsdatei enthält bereits die erforderlichen („harten“) Abhängigkeiten für das Ziel. Um auch die erwünschten („weichen“) Abhängigkeiten abzudecken, erstellen Sie ein Verzeichnis mit dem Namen /etc/systemd/system/MEIN_ZIEL.target.wants.

  3. Legen Sie für jeden erwünschten Dienst einen symbolischen Link von /usr/lib/systemd/system in /etc/systemd/system/MEIN_ZIEL.target.wants an.

  4. Sobald Sie alle Einstellungen für das Ziel festgelegt haben, laden Sie die systemd-Konfiguration neu. Damit wird das neue Ziel verfügbar: 

    tux > sudo systemctl daemon-reload

15.6 Erweiterte Nutzung

 

In den nachfolgenden Abschnitten finden Sie weiterführende Themen für Systemadministratoren. Eine noch eingehendere Dokumentation finden Sie in der Serie von Lennart Pöttering zu systemd für Administratoren unter http://0pointer.de/blog/projects.

15.6.1 Bereinigen von temporären Verzeichnissen

 

systemd unterstützt das regelmäßige Bereinigen der temporären Verzeichnisse. Die Konfiguration aus der bisherigen Systemversion wird automatisch migriert und ist aktiv. tmpfiles.d (verwaltet temporäre Dateien) liest die Konfiguration aus den Dateien /etc/tmpfiles.d/*.conf, /run/tmpfiles.d/*.conf und /usr/lib/tmpfiles.d/*.conf aus. Die Konfiguration in /etc/tmpfiles.d/*.conf hat Vorrang vor ähnlichen Konfigurationen in den anderen beiden Verzeichnissen. (In /usr/lib/tmpfiles.d/*.conf speichern die Pakete die Konfigurationsdateien.)

Im Konfigurationsformat ist eine Zeile pro Pfad vorgeschrieben, wobei diese Zeile die Aktion und den Pfad enthalten muss und optional Felder für Modus, Eigentümer, Alter und Argument (je nach Aktion) enthalten kann. Im folgenden Beispiel wird die Verknüpfung der X11-Sperrdateien aufgehoben: 

Type Path               Mode UID  GID  Age Argument
r    /tmp/.X[0-9]*-lock

So rufen Sie den Status aus dem tmpfile-Zeitgeber ab: 

tux > sudo systemctl status systemd-tmpfiles-clean.timer
systemd-tmpfiles-clean.timer - Daily Cleanup of Temporary Directories
 Loaded: loaded (/usr/lib/systemd/system/systemd-tmpfiles-clean.timer; static)
 Active: active (waiting) since Tue 2018-04-09 15:30:36 CEST; 1 weeks 6 days ago
   Docs: man:tmpfiles.d(5)
         man:systemd-tmpfiles(8)

Apr 09 15:30:36 jupiter systemd[1]: Starting Daily Cleanup of Temporary Directories.
Apr 09 15:30:36 jupiter systemd[1]: Started Daily Cleanup of Temporary Directories.

Weitere Informationen zum Arbeiten mit temporären Dateien finden Sie unter man 5 tmpfiles.d.

15.6.2 Systemprotokoll

 

In Abschnitt 15.6.9, „Fehlersuche für Dienste“ wird erläutert, wie Sie Protokollmeldungen für einen bestimmten Dienst anzeigen. Die Anzeige von Protokollmeldungen ist allerdings nicht auf Dienstprotokolle beschränkt. Sie können auch auf das gesamte von systemd geschriebene Protokoll (das sogenannte „Journal“) zugreifen und Abfragen darauf ausführen. Mit dem Befehl journalctl zeigen Sie das gesamte Protokoll an, beginnend mit den ältesten Einträgen. Informationen zu weiteren Optionen, beispielsweise zum Anwenden von Filtern oder zum Ändern des Ausgabeformats, finden Sie unter man 1 journalctl.

15.6.3 Aufnahmen

 

Mit dem Subkommando isolate können Sie den aktuellen Status von systemd als benannten Snapshot speichern und später wiederherstellen. Dies ist beim Testen von Diensten oder benutzerdefinierten Zielen hilfreich, weil Sie jederzeit zu einem definierten Status zurückkehren können. Ein Snapshot ist nur in der aktuellen Sitzung verfügbar; beim Neubooten wird er automatisch gelöscht. Der Snapshot-Name muss auf .snapshot enden.

Erstellen eines Snapshots
tux > sudo systemctl snapshot MY_SNAPSHOT.snapshot
Löschen eines Snapshots
tux > sudo systemctl delete MY_SNAPSHOT.snapshot
Anzeigen eines Snapshots
tux > sudo systemctl show MY_SNAPSHOT.snapshot
Aktivieren eines Snapshots
tux > sudo systemctl isolate MY_SNAPSHOT.snapshot

15.6.4 Laden der Kernelmodule

 

Mit systemd können Kernel-Module automatisch zum Bootzeitpunkt geladen werden, und zwar über die Konfigurationsdatei in /etc/modules-load.d. Die Datei sollte den Namen MODUL.conf haben und den folgenden Inhalt aufweisen: 

# load module MODULE at boot time
MODULE

Falls ein Paket eine Konfigurationsdatei zum Laden eines Kernel-Moduls installiert, wird diese Datei unter /usr/lib/modules-load.d installiert. Wenn zwei Konfigurationsdateien mit demselben Namen vorhanden sind, hat die Datei unter /etc/modules-load.d Vorrang.

Weitere Informationen finden Sie auf der man-Seite modules-load.d(5).

15.6.5 Ausführen von Aktionen vor dem Laden eines Dienstes

 

Bei System V mussten init-Aktionen, die vor dem Laden eines Diensts ausgeführt werden müssen, in /etc/init.d/before.local festgelegt werden. Dieses Verfahren wird in systemd nicht mehr unterstützt. Wenn Aktionen vor dem Starten von Diensten ausgeführt werden müssen, gehen Sie wie folgt vor:

Laden der Kernelmodule

Erstellen Sie eine Drop-in-Datei im Verzeichnis /etc/modules-load.d (Syntax siehe man modules-load.d).

Erstellen von Dateien oder Verzeichnissen, Bereinigen von Verzeichnissen, Ändern des Eigentümers

Erstellen Sie eine Drop-in-Datei in /etc/tmpfiles.d (Syntax siehe man tmpfiles.d).

Weitere Aufgaben

Erstellen Sie eine Systemdienstdatei (beispielsweise /etc/systemd/system/before.service) anhand der folgenden Schablone: 

[Unit]
Before=NAME OF THE SERVICE YOU WANT THIS SERVICE TO BE STARTED BEFORE
[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=YOUR_COMMAND
# beware, executable is run directly, not through a shell, check the man pages
# systemd.service and systemd.unit for full syntax
[Install]
# target in which to start the service
WantedBy=multi-user.target
#WantedBy=graphical.target

Sobald die Dienstdatei erstellt ist, führen Sie die folgenden Kommandos aus (als root): 

tux > sudo systemctl daemon-reload
tux > sudo systemctl enable before

Bei jedem Bearbeiten der Dienstdatei müssen Sie Folgendes ausführen: 

tux > sudo systemctl daemon-reload

15.6.6 Kernel-Steuergruppen (cgroups)

 

Auf einem traditionellen System-V-init-System kann ein Prozess nicht immer eindeutig dem Dienst zugeordnet werden, durch den er erzeugt wurde. Einige Dienste (z. B. Apache) erzeugen zahlreiche externe Prozesse (z. B. CGI- oder Java-Prozesse), die wiederum weitere Prozesse erzeugen. Eindeutige Zuweisungen sind damit schwierig oder völlig unmöglich. Wenn ein Dienst nicht ordnungsgemäß beendet wird, bleiben zudem ggf. einige untergeordnete Dienste weiterhin aktiv.

Bei systemd wird jeder Dienst in eine eigene cgroup aufgenommen, womit dieses Problem gelöst ist. cgroups sind eine Kernel-Funktion, mit der die Prozesse mit allen ihren untergeordneten Prozessen in hierarchisch strukturierten Gruppen zusammengefasst werden. Die cgroups werden dabei nach dem jeweiligen Dienst benannt. Da ein nicht privilegierter Dienst seine cgroup nicht „verlassen“ darf, ist es damit möglich, alle von einem Dienst erzeugten Prozesse mit dem Namen dieses Dienstes zu versehen.

Mit dem Kommando systemd-cgls erhalten Sie eine Liste aller Prozesse, die zu einem Dienst gehören. (Gekürztes) Beispiel für die Ausgabe:

Beispiel 15.3: Auflisten aller Prozesse, die zu einem Dienst gehören
 
root # systemd-cgls --no-pager
├─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 20
├─user.slice
│ └─user-1000.slice
│   ├─session-102.scope
│   │ ├─12426 gdm-session-worker [pam/gdm-password]
│   │ ├─15831 gdm-session-worker [pam/gdm-password]
│   │ ├─15839 gdm-session-worker [pam/gdm-password]
│   │ ├─15858 /usr/lib/gnome-terminal-server

[...]

└─system.slice
  ├─systemd-hostnamed.service
  │ └─17616 /usr/lib/systemd/systemd-hostnamed
  ├─cron.service
  │ └─1689 /usr/sbin/cron -n
  ├─postfix.service
  │ ├─ 1676 /usr/lib/postfix/master -w
  │ ├─ 1679 qmgr -l -t fifo -u
  │ └─15590 pickup -l -t fifo -u
  ├─sshd.service
  │ └─1436 /usr/sbin/sshd -D

[...]

Weitere Informationen zu cpgroups finden Sie im Book “System Analysis and Tuning Guide”, Chapter 10 “Kernel control groups”.

15.6.7 Beenden von Diensten (Senden von Signalen)

 

Wie in Abschnitt 15.6.6, „Kernel-Steuergruppen (cgroups)“ erläutert, kann ein Prozess in einem System-V-init-System nicht immer eindeutig seinem übergeordneten Dienstprozess zugeordnet werden. Das erschwert das Beenden eines Dienstes und seiner untergeordneten Dienste. Untergeordnete Prozesse, die nicht ordnungsgemäß beendet wurden, bleiben als "Zombie-Prozess" zurück.

Durch das Konzept von systemd, mit dem jeder Dienst in einer eigenen cgroup abgegrenzt wird, können alle untergeordneten Prozesse eines Dienstes eindeutig erkannt werden, sodass Sie ein Signal zu diesen Prozessen senden können. Mit Use systemctl kill senden Sie die Signale an die Dienste. Eine Liste der verfügbaren Signale finden Sie in man 7 signals.

Senden von SIGTERM an einen Dienst

SIGTERM ist das standardmäßig gesendete Signal. 

tux > sudo systemctl kill MY_SERVICE
Senden von SIGNAL an einen Dienst

Mit der Option -s legen Sie das zu sendende Signal fest. 

tux > sudo systemctl kill -s SIGNAL MY_SERVICE
Auswählen von Prozessen

Standardmäßig sendet das Kommando kill das Signal an alle Prozesse der angegebenen cgroup. Sie können dies jedoch auf den Prozess control oder main beschränken. Damit können Sie beispielsweise das Neuladen der Konfiguration eines Dienstes mit dem Signal SIGHUP erzwingen: 

tux > sudo systemctl kill -s SIGHUP --kill-who=main MY_SERVICE

15.6.8 Wichtige Hinweise zum D-Bus-Dienst

 

Der D-Bus-Dienst fungiert als Meldungsbus für die Kommunikation zwischen den systemd-Clients und dem systemd-Manager, der als PID 1 ausgeführt wird. dbus ist zwar ein eigenständiger Dämon, bildet jedoch auch einen wesentlichen Bestandteil der init-Infrastruktur.

Das Beenden von dbus oder das Neustarten im laufenden System entspricht dem Versuch, PID 1 zu beenden oder neu zu starten. Hiermit wird die systemd-Client/Server-Kommunikation unterbrochen, sodass die meisten systemd-Funktionen unbrauchbar werden.

Das Beenden oder Neustarten von dbus wird daher weder empfohlen noch unterstützt.

Nach einer Aktualisierung von dbus oder dbus-Paketen fällt ein Neustart an. Wenn Sie sich nicht sicher sind, ob ein Neustart erforderlich ist, führen Sie den Befehl sudo zypper ps -s aus. Ist dbus unter den aufgelisteten Diensten zu finden, müssen Sie das System neu starten.

Beachten Sie, dass dbus selbst dann aktualisiert wird, wenn in der Konfiguration der automatischen Aktualisierungen festgelegt ist, dass die Pakete, die einen Neustart erfordern, übersprungen werden sollen.

15.6.9 Fehlersuche für Dienste

 

Standardmäßig ist die Ausgabe von systemd auf ein Minimum beschränkt. Wenn ein Dienst ordnungsgemäß gestartet wurde, erfolgt keine Ausgabe. Bei einem Fehler wird eine kurze Fehlermeldung angezeigt. Mit systemctl status können Sie jedoch die Fehlersuche für den Start und die Ausführung eines Dienstes vornehmen.

systemd umfasst einen Protokollierungsmechanismus („Journal“), mit dem die Systemmeldungen protokolliert werden. Auf diese Weise können Sie die Dienstmeldungen zusammen mit den Statusmeldungen abrufen. Das Kommando status hat eine ähnliche Funktion wie tail und kann zudem die Protokollmeldungen in verschiedenen Formaten anzeigen, ist also ein wirksames Hilfsmittel für die Fehlersuche.

Anzeigen von Fehlern beim Starten von Diensten

Wenn ein Dienst nicht gestartet wird, erhalten Sie mit systemctl status MEIN_DIENST eine ausführliche Fehlermeldung: 

root # systemctl start apache2
Job failed. See system journal and 'systemctl status' for details.
root # systemctl status apache2
   Loaded: loaded (/usr/lib/systemd/system/apache2.service; disabled)
   Active: failed (Result: exit-code) since Mon, 04 Apr 2018 16:52:26 +0200; 29s ago
   Process: 3088 ExecStart=/usr/sbin/start_apache2 -D SYSTEMD -k start (code=exited, status=1/FAILURE)
   CGroup: name=systemd:/system/apache2.service

Apr 04 16:52:26 g144 start_apache2[3088]: httpd2-prefork: Syntax error on line
205 of /etc/apache2/httpd.conf: Syntax error on li...alHost>
Anzeigen der letzten n Dienstmeldungen

Standardmäßig zeigt das Subkommando status die letzten zehn Meldungen an, die ein Dienst ausgegeben hat. Mit dem Parameter --lines=n legen Sie eine andere Anzahl fest: 

tux > sudo systemctl status chronyd
tux > sudo systemctl --lines=20 status chronyd
Anzeigen von Dienstmeldungen im Anhängemodus

Mit der Option „--follow“ erhalten Sie einen Live-Stream mit Dienstmeldungen; diese Option entspricht tail -f: 

tux > sudo systemctl --follow status chronyd
Ausgabeformat der Meldungen

Mit dem Parameter --output=mode legen Sie das Ausgabeformat für die Dienstmeldungen fest. Die wichtigsten Modi sind:

short

Das Standardformat. Zeigt die Protokollmeldungen mit einem Zeitstempel in Klartext an.

verbose

Vollständige Ausgabe mit sämtlichen Feldern.

cat

Kurze Ausgabe ohne Zeitstempel.

15.7 systemd-Zeitgeber-Units

 

Ähnlich wie Cron bieten systemd-Zeitgeber-Units einen Mechanismus für die Planung von Aufträgen unter Linux. Die systemd-Zeitgeber-Units dienen zwar demselben Zweck wie Cron, eröffnen allerdings mehrere Vorteile.

  • Aufträge, die mit einer Zeitgeber-Unit geplant werden, können von anderen systemd-Diensten abhängig sein.

  • Zeitgeber-Units werden wie normale systemd-Dienste behandelt und können daher mit systemctl verwaltet werden.

  • Die Zeitgeber können in Echtzeit und monoton sein.

  • Die Zeit-Units werden im systemd-Journal protokolliert, wodurch ihre Verwaltung und Fehlerbehebung vereinfacht werden.

systemd-Zeitgeber-Units sind mit der Dateinamenerweiterung .timer gekennzeichnet.

15.7.1 systemd-Zeitgebertypen

 

Zeitgeber-Units können monotone Zeitgeber und Echtzeit-Zeitgeber nutzen.

  • Ähnlich wie Cronjobs werden Echtzeit-Zeitgeber durch Kalenderereignisse ausgelöst. Echtzeit-Zeitgeber werden mit der Option OnCalendar definiert.

  • Monotone Zeitgeber werden ausgelöst, sobald ein angegebener Zeitraum nach einem bestimmten Startpunkt vergangen ist. Dies ist beispielsweise ein Systemstart-Ereignis oder ein System-Unit-Aktivierungsereignis. Für die Definition von monotonen Zeitgebern stehen mehrere Optionen zur Auswahl, u. a. OnBootSec, OnUnitActiveSec und OnTypeSec. Monotone Zeitgeber sind nicht permanent und werden nach jedem Neustart zurückgesetzt.

15.7.2 systemd-Zeitgeber und Dienst-Units

 

Für jede Zeitgeber-Unit muss eine entsprechende systemd-Unit-Datei vorliegen, die durch die Zeitgeber-Unit gesteuert wird. Anders gesagt, eine .timer-Datei aktiviert und verwaltet die zugehörige .service-Datei. Wird eine .service-Datei mit einem Zeitgeber verwendet, muss die Datei keinen Abschnitt [Install] enthalten, da der Dienst durch den Zeitgeber verwaltet wird.

15.7.3 Beispiel aus der Praxis

 

Zur Veranschaulichung der Grundlagen von systemd-Zeitgeber-Units soll ein Zeitgeber eingerichtet werden, der das Shell-Skript foo.sh auslöst.

Im ersten Schritt erstellen Sie eine systemd-Dienst-Unit, die das Shell-Skript steuert. Öffnen Sie hierzu eine neue Textdatei zum Bearbeiten und fügen Sie folgende Dienst-Unit-Definition hinzu: 

[Unit]
Description="Foo shell script"

[Service]
ExecStart=/usr/local/bin/foo.sh

Speichern Sie die Datei unter dem Namen foo.service im Verzeichnis /etc/systemd/system/.

Öffnen Sie dann eine neue Textdatei zum Bearbeiten und fügen Sie folgende Zeitgeberdefinition hinzu: 

[Unit]
Description="Run foo shell script"

[Timer]
OnBootSec=5min
OnUnitActiveSec=24h
Unit=foo.service

[Install]
WantedBy=multi-user.target

Der Abschnitt [Timer] im obigen Beispiel gibt an, welcher Dienst (foo.service) zu welchem Zeitpunkt ausgelöst werden soll. In diesem Fall gibt die Option OnBootSec einen monotonen Zeitgeber an, der den Dienst fünf Minuten nach Systemstart auslöst, während die Option OnUnitActiveSec den Dienst 24 Stunden nach Aktivierung des Dienstes auslöst (der Zeitgeber löst den Dienst also einmal täglich aus). Die Option WantedBy gibt schließlich an, dass der Zeitgeber gestartet werden soll, sobald das System das Mehrbenutzerziel erreicht hat.

Anstelle eines monotonen Zeitgebers können Sie mit der Option OnCalendar einen Echtzeit-Zeitgeber angeben. Die folgende Echtzeit-Zeitgeberdefinition löst die zugehörige Dienst-Unit einmal wöchentlich aus, beginnend am Montag um 12:00 Uhr. 

[Timer]
OnCalendar=weekly
Persistent=true

Die Option Persistent=true gibt an, dass der Dienst sofort nach Aktivierung des Zeitgebers ausgelöst wird, falls der Zeitgeber die letzte Startzeit versäumt hat (z. B. weil das System ausgeschaltet war).

Mit der Option OnCalendar können außerdem bestimmte Zeitpunkte (Datum und Uhrzeit) für die Auslösung eines Dienstes im folgenden Format definiert werden: Wochentag Jahr-Monat-Tag Stunde:Minute:Sekunde. Im folgenden Beispiel wird ein Dienst täglich um 5:00 Uhr gestartet: 

OnCalendar=*-*-* 5:00:00

Ein Sternchen bezeichnet einen beliebigen Wert und mögliche Werte können durch Komma getrennt aufgelistet werden. Zwei Werte, die durch zwei Punkte (..) getrennt sind, geben einen zusammenhängenden Bereich an. Im folgenden Beispiel wird ein Dienst an jedem Freitag im Monat um 18:00 Uhr gestartet: 

OnCalendar=Fri *-*-1..7 18:00:00

Soll ein Dienst zu verschiedenen Zeiten ausgelöst werden, können Sie mehrere OnCalendar-Einträge angeben: 

OnCalendar=Mon..Fri 10:00
OnCalendar=Sat,Sun 22:00

Im obigen Beispiel wird ein Dienst an Wochentagen um 10:00 Uhr und am Wochenende um 22:00 Uhr ausgelöst.

Wenn Sie die Zeitgeber-Unit-Datei bearbeitet haben, speichern Sie sie unter dem Namen foo.timer im Verzeichnis /etc/systemd/system/. Prüfen Sie die erstellten Unit-Dateien mit folgendem Kommando: 

tux > sudo  systemd-analyze verify /etc/systemd/system/foo.*

Wenn das Kommando keine Ausgabe zurückgibt, haben die Dateien die Überprüfung erfolgreich bestanden.

Starten Sie den Zeitgeber mit dem Kommando sudo systemctl start foo.timer. Soll der Zeitgeber beim Starten aktiviert werden, führen Sie das Kommando sudo systemctl enable foo.timer aus.

15.7.4 Verwalten von systemd-Zeitgebern

 

Da Zeitgeber wie normale systemd-Units behandelt werden, können Sie sie mit systemctl verwalten. Sie können einen Zeitgeber mit systemctl start starten, mit systemctl enable aktivieren usw. Außerdem können Sie mit dem Kommando systemctl list-timers alle aktiven Zeitgeber auflisten. Mit dem Kommando systemctl list-timers --all werden alle Zeitgeber aufgelistet, auch wenn sie inaktiv sind.

15.8 Weitere Informationen

 

Weitere Informationen zu systemd finden Sie in folgenden Online-Quellen:

Startseite

http://www.freedesktop.org/wiki/Software/systemd

systemd für Administratoren

Lennart Pöttering, einer der systemd-Autoren, hat eine Serie von Blogeinträgen verfasst. (Zum Zeitpunkt, als dieses Kapitel verfasst wurde, standen bereits 13 Einträge zur Verfügung.) Diese sind unter http://0pointer.de/blog/projects zu finden.

Teil III System

 
  • 16 32-Bit- und 64-Bit-Anwendungen in einer 64-Bit-Systemumgebung

    • SUSE® Linux Enterprise Server ist für verschiedene 64-Bit-Plattformen verfügbar. Die Entwickler haben nicht alle 32-Bit-Anwendungen auf 64-Bit-Systeme portiert. Dieses Kapitel bietet einen kurzen Überblick darüber, wie die 32-Bit-Unterstützung auf SUSE Linux Enterprise Server-64-Bit-Plattformen impl…

  • 17 journalctl: Abfragen des systemd-Journals

    • systemd umfasst ein eigenes Protokollierungssystem, das als Journal bezeichnet wird. Alle Systemereignisse werden in das Journal geschrieben, so dass Sie keinen syslog-basierten Service ausführen müssen.

  • 18 update-alternatives: Verwalten mehrerer Kommando- und Dateiversionen

    • Häufig sind gleich mehrere Versionen eines Werkzeugs auf einem System installiert. Mit dem Alternativen-System lassen sich diese Versionen konsistent verwalten. So können die Administratoren eine Auswahl treffen und es ist möglich, verschiedene Versionen nebeneinander zu installieren und zu nutzen.

  • 19 Grundlegendes zu Netzwerken

    • Linux stellt die erforderlichen Netzwerkwerkzeuge und -funktionen für die Integration in alle Arten von Netzwerkstrukturen zur Verfügung. Der Netzwerkzugriff über eine Netzwerkkarte kann mit YaST konfiguriert werden. Die manuelle Konfiguration ist ebenfalls möglich. In diesem Kapitel werden nur die grundlegenden Mechanismen und die relevanten Netzwerkkonfigurationsdateien behandelt.

  • 20 Druckerbetrieb

    • SUSE® Linux Enterprise Server unterstützt zahlreiche Druckermodelle (auch entfernte Netzwerkdrucker). Drucker können manuell oder mit YaST konfiguriert werden. Anleitungen zur Konfiguration finden Sie im Book “Bereitstellungshandbuch”, Chapter 20 “Einrichten von Hardwarekomponenten mit YaST”, Sectio…

  • 21 Über die grafische Benutzeroberfläche

    • SUSE Linux Enterprise Server umfasst den X.org-Server und den GNOME-Desktop. In diesem Kapitel wird die Konfiguration der grafischen Benutzeroberfläche für alle Benutzer beschrieben.

  • 22 Zugriff auf Dateisysteme mit FUSE

    • FUSE ist das Akronym für File System in User Space (Dateisystem im Userspace). Das bedeutet, Sie können ein Dateisystem als nicht privilegierter Benutzer konfigurieren und einhängen. Normalerweise müssen Sie für diese Aufgabe als root angemeldet sein. FUSE alleine ist ein Kernel-Modul. In Kombination mit Plug-Ins kann FUSE auf nahezu alle Dateisysteme wie SSH-Fernverbindungen, ISO-Images und mehr erweitert werden.

  • 23 Verwalten von Kernelmodulen

    • Linux ist als monolithischer Kernel ausgelegt, kann jedoch mithilfe von Kernelmodulen erweitert werden. Diese besonderen Objekte lassen sich je nach Bedarf in den Kernel einfügen und wieder entfernen. Mit Kernelmodulen können also Treiber und Schnittstellen, die nicht im Kernel selbst enthalten sind…

  • 24 Gerätemanagement über dynamischen Kernel mithilfe von udev

    • Der Kernel kann fast jedes Gerät in einem laufenden System hinzufügen oder entfernen. Änderungen des Gerätestatus (ob ein Gerät angeschlossen oder entfernt wird) müssen an den userspace weitergegeben werden. Geräte müssen konfiguriert werden, sobald sie angeschlossen und erkannt wurden. Die Benutzer…

  • 25 Spezielle Systemfunktionen

    • In diesem Kapitel erhalten Sie zunächst Informationen zu den verschiedenen Softwarepaketen, zu den virtuellen Konsolen und zur Tastaturbelegung. Hier finden Sie Hinweise zu Software-Komponenten, wie bash, cron und logrotate, da diese im Laufe der letzten Veröffentlichungszyklen geändert oder verbessert wurden. Selbst wenn sie nur klein sind oder als nicht besonders wichtig eingestuft werden, sollten die Benutzer ihr Standardverhalten ändern, da diese Komponenten häufig eng mit dem System verbunden sind. Das Kapitel endet mit einem Abschnitt mit sprach- und landesspezifischen Einstellungen (I18N und L10N).

  • 26 Verwendung von NetworkManager

    • NetworkManager ist die ideale Lösung für Notebooks und andere portable Computer. Es unterstützt die neuesten Verschlüsselungstypen und Standards für Netzwerkverbindungen, einschließlich Verbindungen zu Netzwerken, die nach 802.1X geschützt sind. 802.1X ist die „anschlussbasierte Netzwerkzugriffssteu…

  • 27 Energieverwaltung

    • Die in diesem Kapitel beschriebenen Funktionen und Hardware-Elemente sind auf IBM Z-Plattformen nicht vorhanden. Das Kapitel ist für diese Plattformen daher irrelevant.

  • 28 Permanenter Speicher

    • Dieses Kapitel enthält weitere Informationen zur Verwendung von SUSE Linux Enterprise mit nicht-flüchtigem Hauptspeicher, auch als permanenter Speicher bekannt, der aus einem oder mehreren NVDIMMs besteht.

16 32-Bit- und 64-Bit-Anwendungen in einer 64-Bit-Systemumgebung

 

SUSE® Linux Enterprise Server ist für verschiedene 64-Bit-Plattformen verfügbar. Die Entwickler haben nicht alle 32-Bit-Anwendungen auf 64-Bit-Systeme portiert. Dieses Kapitel bietet einen kurzen Überblick darüber, wie die 32-Bit-Unterstützung auf SUSE Linux Enterprise Server-64-Bit-Plattformen implementiert wird.

SUSE Linux Enterprise Server für die 64-Bit-Plattformen POWER, IBM Z und AMD64/Intel 64 ist so ausgelegt, dass vorhandene 32-Bit-Anwendungen „ohne Änderungen in der 64-Bit-Umgebung ausführbar sind.“ Die entsprechenden 32-Bit-Plattformen sind POWER für POWER sowie x86 für AMD64/Intel 64. Diese Unterstützung bedeutet, dass Sie weiterhin Ihre bevorzugten 32-Bit-Anwendungen verwenden können und nicht warten müssen, bis ein entsprechender 64-Bit-Port verfügbar ist. Das aktuelle POWER-System führt die meisten Anwendungen im 32-Bit-Modus aus, es können aber auch 64-Bit-Anwendungen ausgeführt werden.

Anmerkung
Anmerkung: Keine Unterstützung für die Erstellung von 32-Bit-Anwendungen

SUSE Linux Enterprise Server unterstützt nicht die Kompilierung von 32-Bit-Anwendungen. Laufzeitunterstützung wird nur für 32-Bit-Binärdateien angeboten.

16.1 Laufzeitunterstützung

 
Wichtig
Wichtig: Konflikte zwischen Anwendungsversionen

Sollte eine Anwendung sowohl für 32-Bit-Umgebungen als auch für 64-Bit-Umgebungen verfügbar sein, verursacht die Installation von beiden Versionen möglicherweise Probleme. Entscheiden Sie sich in diesem Fall für die Installation einer Version, um potenzielle Laufzeitprobleme zu vermeiden.

Eine Ausnahme von dieser Regel ist PAM (Pluggable Authentication Modules). Während des Authentifizierungsprozesses verwendet SUSE Linux Enterprise Server PAM (austauschbare Authentifizierungsmodule) als Schicht für die Vermittlung zwischen Benutzer und Anwendung. Installieren Sie immer beide PAM-Versionen auf 64-Bit-Betriebssystemen, die auch 32-Bit-Anwendungen ausführen.

Für die korrekte Ausführung benötigt jede Anwendung eine Reihe von Bibliotheken. Leider sind die Namen für die 32-Bit- und 64-Bit-Versionen dieser Bibliotheken identisch. Sie müssen auf andere Weise voneinander unterschieden werden.

32-Bit- und 64-Bit-Bibliotheken sind am selben Standort gespeichert, um die Kompatibilität mit 32-Bit-Versionen aufrechtzuerhalten. Die 32-Bit-Version von libc.so.6 befindet sich sowohl in der 32-Bit- als auch in der 64-Bit-Umgebung unter /lib/libc.so.6.

Alle 64-Bit-Bibliotheken und Objektdateien befinden sich in Verzeichnissen mit dem Namen lib64. Die 64-Bit-Objektdateien, die sich in der Regel unter /lib und /usr/lib befinden, werden nun unter /lib64 und /usr/lib64 gespeichert. Unter /lib und /usr/lib ist also Platz für die 32-Bit-Bibliotheken, sodass der Dateiname für beide Versionen unverändert bleiben kann.

Wenn Dateninhalte von 32-Bit-Unterverzeichnissen unter /lib nicht von der Wortgröße abhängig sind, werden sie nicht verschoben. Das Schema entspricht LSB (Linux Standards Base) und FHS (File System Hierarchy Standard).

16.2 Kernel-Spezifikationen

 

Die 64-Bit-Kernel für AMD64/Intel 64, POWER und IBM Z bieten sowohl eine 64-Bit- als auch eine 32-Bit-Kernel-ABI (binäre Anwendungsschnittstelle). Letztere ist mit der ABI für den entsprechenden 32-Bit-Kernel identisch. Dies bedeutet, dass die Kommunikation zwischen 32-Bit- und 64-Bit-Anwendungen mit 64-Bit-Kernel identisch ist.

Die 32-Bit-Systemaufrufemulation für 64-Bit-Kernel unterstützt nicht alle APIs, die von Systemprogrammen verwendet werden. Dies hängt von der Plattform ab. Aus diesem Grund müssen einige wenige Anwendungen, wie beispielsweise lspci, auf Nicht-POWER-Plattformen als 64-Bit-Programme kompiliert werden, damit sie ordnungsgemäß funktionieren. Bei IBM Z sind nicht alle ioctls in der 32-Bit-Kernel-ABI verfügbar.

Ein 64-Bit-Kernel kann nur 64-Bit-Kernel-Module laden. 64-Bit-Module müssen speziell für 64-Bit-Kernel kompiliert werden. Es ist nicht möglich, 32-Bit-Kernel-Module mit 64-Bit-Kernels zu verwenden.

Tipp
Tipp: Kernel-ladbare Module

Für einige Anwendungen sind separate, Kernel-ladbare Module erforderlich. Sollten Sie eine 32-Bit-Anwendung in einer 64-Bit-Systemumgebung verwenden wollen, kontaktieren Sie den Anwendungsanbieter und SUSE. Stellen Sie sicher, dass die 64-Bit-Version des Kernel-ladbaren Moduls und die kompilierte 32-Bit-Version der Kernel-API für dieses Modul verfügbar sind.

17 journalctl: Abfragen des systemd-Journals

 

systemd umfasst ein eigenes Protokollierungssystem, das als Journal bezeichnet wird. Alle Systemereignisse werden in das Journal geschrieben, so dass Sie keinen syslog-basierten Service ausführen müssen.

Das Journal selbst ist ein Systemservice und wird mit systemd verwaltet. Die vollständige Bezeichnung des Service lautet systemd-journald.service. Hier werden Protokolldaten in strukturierten, indizierten Journalen erfasst und gespeichert. Die Daten basieren dabei auf den Protokollinformationen aus dem Kernel, von den Benutzerprozessen, aus der Standardeingabe und aus den Fehlern von Systemdiensten. Der Dienst systemd-journald ist standardmäßig aktiviert: 

tux > sudo systemctl status systemd-journald
systemd-journald.service - Journal Service
   Loaded: loaded (/usr/lib/systemd/system/systemd-journald.service; static)
   Active: active (running) since Mon 2014-05-26 08:36:59 EDT; 3 days ago
     Docs: man:systemd-journald.service(8)
           man:journald.conf(5)
 Main PID: 413 (systemd-journal)
   Status: "Processing requests..."
   CGroup: /system.slice/systemd-journald.service
           └─413 /usr/lib/systemd/systemd-journald
[...]

17.1 Festlegen des Journals als permanent

 

Das Journal speichert die Protokolldaten standardmäßig in /run/log/journal/. Das Verzeichnis /run/ ist naturgemäß flüchtig, weshalb die Protokolldaten beim Neubooten verloren gehen. Um permanente Protokolldaten zu erzielen, muss das Verzeichnis /var/log/journal/ mit den entsprechenden Angaben zu Eigentümer und Berechtigungen vorhanden sein, damit der systemd-journald-Service die Daten dort speichern kann. So können Sie das Verzeichnis mit systemd erstellen und die persistente Protokollierung aktivieren:

  1. Öffnen Sie die Datei /etc/systemd/journald.conf als root zum Bearbeiten. 

    root # vi /etc/systemd/journald.conf

  2. Heben Sie die Auskommentierung der Zeile auf, die mit Storage= beginnt, und ändern Sie sie wie folgt: 

    [...]
[Journal]
Storage=persistent
#Compress=yes
[...]

  3. Speichern Sie die Datei, und starten Sie systemd-journald neu: 

    root # systemctl restart systemd-journald

17.2 journalctl:: Nützliche Schalter

 

In diesem Abschnitt finden Sie einige häufig verwendete, nützliche Optionen, mit denen Sie das Standardverhalten von journalctl optimieren. Alle Schalter sind auf der man-Seite zu journalctl (man 1 journalctl) beschrieben.

Tipp
Tipp: Meldungen für eine bestimmte ausführbare Datei

Sollen alle Journaleinträge für eine bestimmte ausführbare Datei angezeigt werden, geben Sie den vollständigen Pfad zu dieser Datei an: 

tux > sudo journalctl /usr/lib/systemd/systemd
-f

Zeigt lediglich die jüngsten Protokollmeldungen an und gibt neue Protokolleinträge aus, sobald sie zum Journal hinzugefügt werden.

Gibt die Meldungen aus und springt an das Ende des Journals, so dass im Pager die aktuellen Einträge sichtbar sind.

-r

Gibt die Meldungen des Journals in umgekehrter Reihenfolge aus (die jüngsten Einträge zuerst).

-k

Zeigt nur Kernel-Meldungen an. Dies entspricht der Feldzuordnung _TRANSPORT=kernel (siehe Abschnitt 17.3.3, „Filtern nach Feldern“).

-u

Zeigt nur Meldungen für die angegebene systemd-Einheit an. Dies entspricht der Feldzuordnung _SYSTEMD_UNIT=UNIT (siehe Abschnitt 17.3.3, „Filtern nach Feldern“). 

tux > sudo journalctl -u apache2
[...]
Jun 03 10:07:11 pinkiepie systemd[1]: Starting The Apache Webserver...
Jun 03 10:07:12 pinkiepie systemd[1]: Started The Apache Webserver.

17.3 Filtern der Journalausgabe

 

Wenn Sie journalctl ohne Schalter aufrufen, wird der gesamte Inhalt des Journals angezeigt (die ältesten Einträge an erster Stelle). Die Ausgabe kann mit bestimmten Schaltern und Feldern gefiltert werden.

17.3.1 Filtern nach Bootnummer

 

journalctl kann die Meldungen nach einem bestimmten System-Bootvorgang filtern. Zum Anzeigen einer Liste mit allen verfügbaren Bootvorgängen führen Sie Folgendes aus: 

tux > sudo journalctl --list-boots
-1 097ed2cd99124a2391d2cffab1b566f0 Mon 2014-05-26 08:36:56 EDT—Fri 2014-05-30 05:33:44 EDT
 0 156019a44a774a0bb0148a92df4af81b Fri 2014-05-30 05:34:09 EDT—Fri 2014-05-30 06:15:01 EDT

Die erste Spalte enthält den Boot-Offset: 0 für den aktuellen Bootvorgang, -1 für den vorangegangenen Bootvorgang, -2 für den davor erfolgten Bootvorgang usw. Die zweite Spalte zeigt die Boot-ID, gefolgt von den Zeitstempeln für Beginn und Ende des Zeitraums, über den das System nach dem Bootvorgang aktiv war.

Alle Meldungen für den aktuellen Bootvorgang anzeigen: 

tux > sudo journalctl -b

Wenn Sie die Journalmeldungen für den vorangegangenen Bootvorgang abrufen möchten, hängen Sie einen Offset-Parameter an. Im folgenden Beispiel werden die Meldungen für den vorangegangenen Bootvorgang ausgegeben: 

tux > sudo journalctl -b -1

Alternativ können Sie die Bootmeldungen nach der Boot-ID auflisten. Verwenden Sie hierzu das Feld _BOOT_ID: 

tux > sudo journalctl _BOOT_ID=156019a44a774a0bb0148a92df4af81b

17.3.2 Filtern nach Zeitraum

 

Sie können die Ausgabe von journalctl durch Angabe des Start- oder Enddatums filtern. Für Datumsangaben gilt das Format „2014-06-30 9:17:16“. Wenn Sie keine Uhrzeit angeben, wird Mitternacht (0:00 Uhr) angenommen. Wenn die Sekundenangabe fehlt, wird „:00“ angenommen. Wenn Sie kein Datum angeben, wird das aktuelle Datum angenommen. Statt eines numerischen Ausdrucks können Sie die Schlüsselwörter „gestern“, „heute“ oder „morgen“ angeben. Diese Wörter bezeichnen Mitternacht am Tag vor dem aktuellen Tag, am aktuellen Tag bzw. am Tag nach dem aktuellen Tag. Das Schlüsselwort „now“ (jetzt) verweist auf die aktuelle Uhrzeit am heutigen Tag. Auch relative Zeitangaben mit dem Präfix - oder + sind möglich. Diese Zeitangaben verweisen dann entsprechend auf eine Uhrzeit vor oder nach der aktuellen Uhrzeit.

Nur neue Meldungen ab jetzt anzeigen und Ausgabe entsprechend aktualisieren: 

tux > sudo journalctl --since "now" -f

Alle Meldungen ab der letzten Mitternacht bis 3:20 Uhr anzeigen: 

tux > sudo journalctl --since "today" --until "3:20"

17.3.3 Filtern nach Feldern

 

Sie können die Ausgabe des Journals nach bestimmten Feldern filtern. Die Syntax für ein abzugleichendes Feld lautet FELDNAME=FILTERKRITERIUM, beispielsweise _SYSTEMD_UNIT=httpd.service. Wenn Sie mehrere Filterkriterien in einer einzigen Abfrage angeben, werden die Ausgabemeldungen noch stärker gefiltert. Eine Liste der Standardfelder finden Sie auf der man-Seite man 7 systemd.journal-fields.

Meldungen anzeigen, die von einer bestimmten Prozess-ID erzeugt wurden: 

tux > sudo journalctl _PID=1039

Meldungen anzeigen, die zu einer bestimmten Benutzer-ID gehören: 

# journalctl _UID=1000

Meldungen aus dem Kernel-Ring-Puffer anzeigen (entspricht der Ausgabe von dmesg): 

tux > sudo journalctl _TRANSPORT=kernel

Meldungen aus der Standard- oder Fehlerausgabe des Services anzeigen: 

tux > sudo journalctl _TRANSPORT=stdout

Nur Meldungen anzeigen, die von einem bestimmten Service erzeugt wurden: 

tux > sudo journalctl _SYSTEMD_UNIT=avahi-daemon.service

Wenn Sie zwei verschiedene Felder angeben, werden nur solche Einträge zurückgegeben, die beide Ausdrücke gleichzeitig erfüllen: 

tux > sudo journalctl _SYSTEMD_UNIT=avahi-daemon.service _PID=1488

Wenn Sie zwei Kriterien für dasselbe Feld angeben, werden alle Einträge zurückgegeben, die einen dieser Ausdrücke erfüllen: 

tux > sudo journalctl _SYSTEMD_UNIT=avahi-daemon.service _SYSTEMD_UNIT=dbus.service

Mit dem Begrenzungszeichen „+“ verbinden Sie zwei Ausdrücke mit einem logischen „OR“. Im folgenden Beispiel werden alle Meldungen aus dem Avahi-Service mit der Prozess-ID 1480 zusammen mit allen Meldungen vom D-Bus-Service gezeigt: 

tux > sudo journalctl _SYSTEMD_UNIT=avahi-daemon.service _PID=1480 + _SYSTEMD_UNIT=dbus.service

17.4 Untersuchen von systemd-Fehlern

 

In diesem Abschnitt wird an einem einfachen Beispiel erläutert, wie Sie die Fehler auffinden und beheben, die systemd beim Starten von apache2 meldet.

  1. Versuchen Sie, den apache2-Service zu starten: 

    # systemctl start apache2
Job for apache2.service failed. See 'systemctl status apache2' and 'journalctl -xn' for details.

  2. Prüfen Sie den Status dieses Service: 

    tux > sudo systemctl status apache2
apache2.service - The Apache Webserver
   Loaded: loaded (/usr/lib/systemd/system/apache2.service; disabled)
   Active: failed (Result: exit-code) since Tue 2014-06-03 11:08:13 CEST; 7min ago
  Process: 11026 ExecStop=/usr/sbin/start_apache2 -D SYSTEMD -DFOREGROUND \
           -k graceful-stop (code=exited, status=1/FAILURE)

    Die ID des Prozesses, der den Fehler verursacht, lautet 11026.

  3. Rufen Sie die ausführliche Version der Meldungen zur Prozess-ID 11026 ab: 

    tux > sudo journalctl -o verbose _PID=11026
[...]
MESSAGE=AH00526: Syntax error on line 6 of /etc/apache2/default-server.conf:
[...]
MESSAGE=Invalid command 'DocumenttRoot', perhaps misspelled or defined by a module
[...]

  4. Korrigieren Sie den Schreibfehler in /etc/apache2/default-server.conf, starten Sie den apache2-Service, und lassen Sie den Status ausgeben: 

    tux > sudo systemctl start apache2 && systemctl status apache2
apache2.service - The Apache Webserver
   Loaded: loaded (/usr/lib/systemd/system/apache2.service; disabled)
   Active: active (running) since Tue 2014-06-03 11:26:24 CEST; 4ms ago
  Process: 11026 ExecStop=/usr/sbin/start_apache2 -D SYSTEMD -DFOREGROUND
           -k graceful-stop (code=exited, status=1/FAILURE)
 Main PID: 11263 (httpd2-prefork)
   Status: "Processing requests..."
   CGroup: /system.slice/apache2.service
           ├─11263 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -D [...]
           ├─11280 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -D [...]
           ├─11281 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -D [...]
           ├─11282 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -D [...]
           ├─11283 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -D [...]
           └─11285 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -D [...]

17.5 Konfiguration von journald

 

Das Verhalten des systemd-journald-Service lässt sich in /etc/systemd/journald.conf festlegen. In diesem Abschnitt werden lediglich die grundlegenden Optionseinstellungen vorgestellt. Eine vollständige Beschreibung der Datei finden Sie auf der man-Seite man 5 journald.conf. Damit die Änderungen in Kraft treten, müssen Sie das Journal wie folgt neu starten: 

tux > sudo systemctl restart systemd-journald

17.5.1 Ändern der Größenbeschränkung für das Journal

 

Wenn die Journalprotokolldaten an einem persistenten Speicherort gespeichert werden (siehe Abschnitt 17.1, „Festlegen des Journals als permanent“), belegen sie bis zu 10 % des Dateisystems, auf dem sich /var/log/journal befindet. Ist /var/log/journal beispielsweise auf einer /var-Partition mit einer Kapazität von 30 GB gespeichert, so kann das Journal bis zu 3 GB des Festplattenspeichers belegen. Zum Bearbeiten dieser Größenbeschränkung ändern Sie die Option SystemMaxUse (und heben Sie die Auskommentierung dieser Option auf): 

SystemMaxUse=50M

17.5.2 Weiterleiten des Journals an /dev/ttyX

 

Sie können das Journal an ein Terminalgerät weiterleiten, so dass Sie an einem bevorzugten Terminalbildschirm (beispielsweise /dev/tty12) über Systemmeldungen informiert werden. Ändern Sie die folgenden journald-Optionen: 

ForwardToConsole=yes
TTYPath=/dev/tty12

17.5.3 Weiterleiten des Journals an die Syslog-Funktion

 

journald ist abwärtskompatibel zu herkömmlichen syslog-Implementierungen wie rsyslog. Prüfen Sie Folgendes:

  • rsyslog ist installiert. 

    tux > sudo rpm -q rsyslog
rsyslog-7.4.8-2.16.x86_64

  • Der rsyslog-Service ist aktiviert. 

    tux > sudo systemctl is-enabled rsyslog
enabled

  • Die Weiterleitung an syslog wird in /etc/systemd/journald.conf aktiviert. 

    ForwardToSyslog=yes

17.6 Filtern des systemd-Journals mit YaST

 

Mit dem YaST-Journalmodul filtern Sie das systemd-Journal schnell und einfach (ohne die journalctl-Syntax verwenden zu müssen). Installieren Sie das Modul mit sudo zypper in yast2-journal und starten Sie es dann in YaST mit System ›  systemd Journal. Alternativ starten Sie das Modul von der Befehlszeile aus mit dem Befehl sudo yast2 journal.

YaST-systemd-Journal
Abbildung 17.1: YaST-systemd-Journal
 

Das Modul zeigt die Protokolleinträge in einer Tabelle. Im Suchfeld oben suchen Sie nach Einträgen, die bestimmte Zeichen enthalten, ähnlich wie mit grep. Zum Filtern der Einträge nach Datum/Uhrzeit, Einheit, Datei oder Priorität klicken Sie auf Change filters (Filter ändern) und legen Sie die jeweiligen Optionen fest.

17.7 Abrufen von Protokollen in GNOME

 

Sie können das Journal mit den GNOME-Protokollen abrufen. Starten Sie dieses Kommando über das Anwendungsmenü. Zum Abrufen von Systemprotokollmeldungen muss dieses Kommando als root ausgeführt werden, beispielsweise mit xdg-su gnome-logs. Dieses Kommando kann mit Alt–F2 ausgeführt werden.

18 update-alternatives: Verwalten mehrerer Kommando- und Dateiversionen

 

Häufig sind gleich mehrere Versionen eines Werkzeugs auf einem System installiert. Mit dem Alternativen-System lassen sich diese Versionen konsistent verwalten. So können die Administratoren eine Auswahl treffen und es ist möglich, verschiedene Versionen nebeneinander zu installieren und zu nutzen.

18.1 Übersicht

 

Auf SUSE Linux Enterprise Server übernehmen einige Programme identische oder ähnliche Aufgaben. Wenn beispielsweise sowohl Java 1.7 als auch Java 1.8 auf einem System installiert sind, wird das Skript des Alternativen-Systems (update-alternatives) aus dem RPM-Paket heraus aufgerufen. Standardmäßig verweist das Alternativen-System auf Version 1.8: Höhere Versionen besitzen auch eine höhere Priorität. Der Administrator kann jedoch die Standardeinstellung ändern, sodass der generische Name auf Version 1.7 verweist.

In diesem Kapitel gilt die folgende Terminologie:

Terminologie
 
Administrationsverzeichnis

Das Standardverzeichnis /var/lib/rpm/alternatives enthält Informationen zum aktuellen Status der Alternativen.

Alternative

Name einer bestimmten Datei im Dateisystem. Der Zugriff auf diese Datei erfolgt anhand eines generischen Namens über das Alternativen-System.

Alternativen-Verzeichnis

Standardverzeichnis /etc/alternatives mit symbolischen Links.

Generischer Name

Name (z. B. /usr/bin/edit), der auf eine von mehreren über das Alternativen-System verfügbaren Dateien verweist.

Link-Gruppe

Gruppe zusammengehöriger symbolischer Links, die als Gruppe aktualisiert werden können.

Master-Link

Link in Link-Gruppe, der bestimmt, wie die anderen Links in der Gruppe konfiguriert werden.

Slave-Link

Link in einer Link-Gruppe, der durch den Master-Link gesteuert wird.

Symbolischer Link (Symlink)

Datei, die auf eine andere Datei in demselben Dateisystem verweist. Das Alternativen-System schaltet über symbolische Links im Alternativen-Verzeichnis zwischen den verschiedenen Versionen einer Datei um.

Der Administrator kann die symbolischen Links im Alternativen-Verzeichnis mit dem Befehl update-alternatives bearbeiten.

Mit dem Befehl update-alternatives im Alternativen-System lassen sich symbolische Links erstellen, entfernen und pflegen sowie Informationen zu diesen Links abrufen. Diese symbolischen Links verweisen in der Regel auf Befehle, können allerdings auch auf JAR-Archive, man-Seiten und andere Dateien verweisen. Die Beispiele in diesem Kapitel zeigen Befehle und man-Seiten, gelten jedoch auch für andere Dateitypen.

Im Alternativen-Verzeichnis legt das Alternativen-System die Links zu möglichen Alternativen ab. Wenn ein neues Paket mit einer Alternative installiert wird, wird die neue Alternative in das System aufgenommen. Die Entscheidung, ob die Alternative des neuen Pakets als Standard festgelegt werden soll, ist abhängig von der Priorität des Pakets und vom ausgewählten Modus. In der Regel besitzen Pakete mit einer höheren Version auch eine höhere Priorität. Das Alternativen-System bietet zwei Modi:

  • Automatischer Modus.  In diesem Modus sorgt das Alternativen-System dafür, dass die Links in der Gruppe auf die geeigneten Alternativen mit der höchsten Priorität für die Gruppe verweisen.

  • Manueller Modus.  In diesem Modus nimmt das Alternativen-System keine Änderungen an den Einstellungen des Systemadministrators vor.

Für den Befehl java gilt beispielsweise die folgende Link-Hierarchie im Alternativen-System:

Beispiel 18.1: Alternativen-System für den Befehl java
 
/usr/bin/java 1
 -> /etc/alternatives/java 2
     -> /usr/lib64/jvm/jre-10-openjdk/bin/java 3

1

Generischer Name.

2

Symbolischer Link im Alternativen-Verzeichnis.

3

Eine der Alternativen.

18.2 Einsatzbereiche

 

Standardmäßig wird das Skript update-alternatives aus einem RPM-Paket heraus aufgerufen. Wenn ein Paket installiert oder entfernt wird, bearbeitet das Skript alle zugehörigen symbolischen Links. Sie können das Skript jedoch auch manuell über die Befehlszeile ausführen und so:

  • die aktuellen Alternativen für einen generischen Namen abrufen.

  • die Standardeinstellungen für eine Alternative ändern.

  • eine Gruppe zusammengehöriger Dateien für eine Alternative erstellen.

18.3 Überblick über Alternativen

 

Die Namen aller konfigurierten Alternativen erhalten Sie mit: 

tux > ls /var/lib/alternatives

Einen Überblick über alle konfigurierten Alternativen und deren Werte erhalten Sie mit 

tux > sudo update-alternatives --get-selections
asadmin                        auto     /usr/bin/asadmin-2.7
awk                            auto     /usr/bin/gawk
chardetect                     auto     /usr/bin/chardetect-3.6
dbus-launch                    auto     /usr/bin/dbus-launch.x11
default-displaymanager         auto     /usr/lib/X11/displaymanagers/gdm
[...]

18.4 Anzeigen von Details zu spezifischen Alternativen

 

Am einfachsten überprüfen Sie die Alternativen, wenn Sie den symbolischen Links des Befehls folgen. Wenn Sie beispielsweise erfahren möchten, worauf der Befehl java verweist, geben Sie den folgenden Befehl ein: 

tux > readlink --canonicalize /usr/bin/java
/usr/lib64/jvm/jre-10-openjdk/bin/java

Falls jeweils derselbe Pfad angezeigt wird (in diesem Beispiel /usr/bin/java), stehen keine Alternativen für diesen Befehl zur Auswahl.

Mit der Option --display rufen Sie sämtliche Alternativen (mit Slaves) ab: 

tux > sudo update-alternatives --display java
java - auto mode
  link best version is /usr/lib64/jvm/jre-1.8.0-openjdk/bin/java
  link currently points to /usr/lib64/jvm/jre-1.8.0-openjdk/bin/java
  link java is /usr/bin/java
  slave java.1.gz is /usr/share/man/man1/java.1.gz
  slave jre is /usr/lib64/jvm/jre
  slave jre_exports is /usr/lib64/jvm-exports/jre
  slave keytool is /usr/bin/keytool
  slave keytool.1.gz is /usr/share/man/man1/keytool.1.gz
  slave orbd is /usr/bin/orbd
  slave orbd.1.gz is /usr/share/man/man1/orbd.1.gz
[...]

18.5 Festlegen der Standardversion von Alternativen

 

Standardmäßig verweisen die Befehle unter /usr/bin auf das Alternativen-Verzeichnis mit der höchsten Priorität. Der Befehl java gibt beispielsweise standardmäßig die folgende Versionsnummer zurück: 

tux > java -version
openjdk version "10.0.1" 2018-04-17
OpenJDK Runtime Environment (build 10.0.1+10-suse-lp150.1.11-x8664)
OpenJDK 64-Bit Server VM (build 10.0.1+10-suse-lp150.1.11-x8664, mixed mode)

Ändern Sie die Standardeinstellung, sodass der Befehl java auf eine frühere Version verweist, mit dem folgenden Befehl: 

tux > sudo update-alternatives --config java
root's password:
There are 2 choices for the alternative java (providing /usr/bin/java).

  Selection    Path                                       Priority   Status
------------------------------------------------------------
* 0            /usr/lib64/jvm/jre-10-openjdk/bin/java      2005      auto mode
  1            /usr/lib64/jvm/jre-1.8.0-openjdk/bin/java   1805      manual mode
  2            /usr/lib64/jvm/jre-10-openjdk/bin/java      2005      manual mode
  3            /usr/lib64/jvm/jre-11-openjdk/bin/java      0         manual mode

Press <enter> to keep the current choice[*], or type selection number:

Die genaue Java-Versionsnummer ist dabei abhängig von Ihrem System und von den installierten Versionen. Wenn Sie 1 auswählen, zeigt java die folgende Versionsnummer an: 

tux > java -version
java version "1.8.0_171"
OpenJDK Runtime Environment (IcedTea 3.8.0) (build 1.8.0_171-b11 suse-lp150.2.3.1-x86_64)
OpenJDK 64-Bit Server VM (build 25.171-b11, mixed mode)

Beachten Sie auch die folgenden Punkte:

  • Wenn Sie im manuellen Modus arbeiten und eine andere Java-Version installieren, behält das Alternativen-System sowohl die Links als auch den generischen Namen unverändert bei.

  • Wenn Sie im automatischen Modus arbeiten und eine andere Java-Version installieren, ändert das Alternativen-System den Java-Master-Link und alle Slave-Links (siehe Abschnitt 18.4, „Anzeigen von Details zu spezifischen Alternativen“). Prüfen Sie die Master-Slave-Beziehungen mit dem folgenden Befehl: 

    tux > sudo update-alternatives --display java

18.6 Installieren von benutzerdefinierten Alternativen

 

In diesem Abschnitt erfahren Sie, wie Sie benutzerdefinierte Alternativen in einem System einrichten. Für das Beispiel gelten die folgenden Annahmen:

  • Es gibt zwei Skripte (foo-2 und foo-3) mit einem ähnlichen Funktionsumfang.

  • Die Skripte sind im Verzeichnis /usr/local/bin gespeichert, sodass keine Konflikte mit den System-Tools unter /usr/bin entstehen.

  • Der Master-Link foo verweist entweder auf foo-2 oder auf foo-3.

So richten Sie Alternativen im System ein:

  1. Kopieren Sie die Skripte in das Verzeichnis /usr/local/bin.

  2. Machen Sie die Skripte ausführbar: 

    tux > sudo chmod +x /usr/local/bin/foo-{2,3}

  3. Führen Sie update-alternatives für beide Skripte aus: 

    tux > sudo update-alternatives --install \
   /usr/local/bin/foo 1\
   foo 2\
   /usr/local/bin/foo-2 3\
   200 4
tux > sudo update-alternatives --install \
   /usr/local/bin/foo 1\
   foo 2\
   /usr/local/bin/foo-3 3\
   300 4

    Die Optionen nach --install bedeuten:

    1

    Generischer Name. Zur Bedeutung: Dies ist in der Regel der Skriptname ohne Versionsnummern.

    2

    Name des Master-Links. Muss identisch sein.

    3

    Pfad zu dem oder den Originalskripten unter /usr/local/bin.

    4

    Die Priorität. foo-2 erhält eine niedrigere Priorität als foo-3. Die Prioritäten sollten nach Möglichkeit deutlich unterschiedliche Zahlen erhalten. Beispiel: Priorität 200 für foo-2 und 300 für foo-3.

  4. Prüfen Sie den Master-Link: 

    tux > sudo update-alternatives --display foo
foo - auto mode
  link best version is /usr/local/bin/foo-3
  link currently points to /usr/local/bin/foo-3
  link foo is /usr/local/bin/foo
/usr/local/bin/foo-2 - priority 200
/usr/local/bin/foo-3 - priority 300

Sobald Sie die angegebenen Schritte erledigt haben, können Sie den Master-Link /usr/local/bin/foo verwenden.

Bei Bedarf können Sie weitere Alternativen installieren. Mit dem folgenden Befehl entfernen Sie eine Alternative: 

tux > sudo update-alternatives --remove foo /usr/local/bin/foo-2

Sobald dieses Skript entfernt wurde, sieht das Alternativen-System für die foo-Gruppe wie folgt aus: 

tux > sudo update-alternatives --display foo
foo - auto mode
  link best version is /usr/local/bin/foo-3
  link currently points to /usr/local/bin/foo-3
  link foo is /usr/local/bin/foo
/usr/local/bin/foo-3 - priority 300

18.7 Definieren von abhängigen Alternativen

 

Wenn Sie mit Alternativen arbeiten, reicht das Skript allein nicht aus. Die meisten Befehle sind nicht völlig eigenständig, sondern umfassen in der Regel zusätzliche Dateien wie Erweiterungen, Konfigurationen oder man-Seiten. Mit Slave-Alternativen erstellen Sie Alternativen, die von einem Master-Link abhängig sind.

Angenommen, das Beispiel in Abschnitt 18.6, „Installieren von benutzerdefinierten Alternativen“ soll mit man-Seiten und Konfigurationsdateien erweitert werden:

  • Zwei man-Seiten (foo-2.1.gz und foo-3.1.gz) im Verzeichnis /usr/local/man/man1.

  • Zwei Konfigurationsdateien (foo-2.conf und foo-3.conf) unter /etc.

So nehmen Sie die zusätzlichen Dateien in Ihre Alternativen auf:

  1. Kopieren Sie die Konfigurationsdateien in /etc: 

    tux > sudo cp foo-{2,3}.conf /etc

  2. Kopieren Sie die man-Seiten in das Verzeichnis /usr/local/man/man1: 

    tux > sudo cp foo-{2,3}.1.gz /usr/local/man/man1/

  3. Tragen Sie die Slave-Links mit der Option --slave in die Hauptskripte ein: 

    tux > sudo update-alternatives --install \
   /usr/local/bin/foo foo /usr/local/bin/foo-2 200 \
   --slave /usr/local/man/man1/foo.1.gz \
   foo.1.gz \
   /usr/local/man/man1/foo-2.1.gz \
   --slave /etc/foo.conf \
   foo.conf \
   /etc/foo-2.conf
tux > sudo update-alternatives --install \
   /usr/local/bin/foo foo /usr/local/bin/foo-3 300 \
   --slave /usr/local/man/man1/foo.1.gz \
   foo.1.gz \
   /usr/local/man/man1/foo-3.1.gz \
   --slave /etc/foo.conf \
   foo.conf \
   /etc/foo-3.conf

  4. Prüfen Sie den Master-Link:

    foo - auto mode
  link best version is /usr/local/bin/foo-3
  link currently points to /usr/local/bin/foo-3
  link foo is /usr/local/bin/foo
  slave foo.1.gz is /usr/local/man/man1/foo.1.gz
  slave foo.conf is /etc/foo.conf
/usr/local/bin/foo-2 - priority 200
  slave foo.1.gz: /usr/local/man/man1/foo-2.1.gz
  slave foo.conf: /etc/foo-2.conf
/usr/local/bin/foo-3 - priority 300
  slave foo.1.gz: /usr/local/man/man1/foo-3.1.gz
  slave foo.conf: /etc/foo-3.conf

Wenn Sie die Links mit update-alternatives --config foo in foo-2ändern, werden auch alle Slave-Links geändert.

19 Grundlegendes zu Netzwerken

 

Linux stellt die erforderlichen Netzwerkwerkzeuge und -funktionen für die Integration in alle Arten von Netzwerkstrukturen zur Verfügung. Der Netzwerkzugriff über eine Netzwerkkarte kann mit YaST konfiguriert werden. Die manuelle Konfiguration ist ebenfalls möglich. In diesem Kapitel werden nur die grundlegenden Mechanismen und die relevanten Netzwerkkonfigurationsdateien behandelt.

Linux und andere Unix-Betriebssysteme verwenden das TCP/IP-Protokoll. Hierbei handelt es sich nicht um ein einzelnes Netzwerkprotokoll, sondern um eine Familie von Netzwerkprotokollen, die unterschiedliche Dienste zur Verfügung stellen. Die in Verschiedene Protokolle aus der TCP/IP-Familie aufgelisteten Protokolle dienen dem Datenaustausch zwischen zwei Computern über TCP/IP. Über TCP/IP verbundene Netzwerke bilden zusammen ein weltweites Netzwerk, das auch als „das Internet“ bezeichnet wird.

RFC ist das Akronym für Request for Comments. RFCs sind Dokumente, die unterschiedliche Internetprotokolle und Implementierungsverfahren für das Betriebssystem und seine Anwendungen beschreiben. Die RFC-Dokumente beschreiben das Einrichten der Internetprotokolle. Weitere Informationen zu RFCs finden Sie unter http://www.ietf.org/rfc.html.

Verschiedene Protokolle aus der TCP/IP-Familie
 
TCP

Transmission Control Protocol: Ein verbindungsorientiertes sicheres Protokoll. Die zu übertragenden Daten werden zuerst von der Anwendung als Datenstrom gesendet und vom Betriebssystem in das passende Format konvertiert. Die entsprechende Anwendung auf dem Zielhost empfängt die Daten im ursprünglichen Datenstromformat, in dem sie anfänglich gesendet wurden. TCP ermittelt, ob Daten bei der Übertragung verloren gegangen sind oder beschädigt wurden. TCP wird immer dann implementiert, wenn die Datensequenz eine Rolle spielt.

UDP

User Datagram Protocol: Ein verbindungsloses, nicht sicheres Protokoll. Die zu übertragenden Daten werden in Form von anwendungsseitig generierten Paketen gesendet. Es ist nicht garantiert, in welcher Reihenfolge die Daten beim Empfänger eingehen, und ein Datenverlust ist immer möglich. UDP ist geeignet für datensatzorientierte Anwendungen. Es verfügt über eine kürzere Latenzzeit als TCP.

ICMP

Internet Control Message Protocol: Dies ist kein Protokoll für den Endbenutzer, sondern ein spezielles Steuerungsprotokoll, das Fehlerberichte ausgibt und das Verhalten von Computern, die am TCP/IP-Datentransfer teilnehmen, steuern kann. Außerdem bietet es einen speziellen Echomodus, der mit dem Programm „ping“ angezeigt werden kann.

IGMP

Internet Group Management Protocol: Dieses Protokoll steuert das Verhalten des Computers beim Implementieren von IP Multicast.

Der Datenaustausch findet wie in Abbildung 19.1, „Vereinfachtes Schichtmodell für TCP/IP“ dargestellt in unterschiedlichen Schichten statt. Die eigentliche Netzwerkschicht ist der unsichere Datentransfer über IP (Internet Protocol). Oberhalb von IP gewährleistet TCP (Transmission Control Protocol) bis zu einem gewissen Grad die Sicherheit des Datentransfers. Die IP-Schicht wird vom zugrunde liegenden hardwareabhängigen Protokoll, z. B. Ethernet, unterstützt.

Vereinfachtes Schichtmodell für TCP/IP
Abbildung 19.1: Vereinfachtes Schichtmodell für TCP/IP
 

Dieses Diagramm bietet für jede Schicht ein oder zwei Beispiele. Die Schichten sind nach Abstraktionsstufen sortiert. Die unterste Schicht ist sehr Hardware-nah. Die oberste Schicht ist beinahe vollständig von der Hardware losgelöst. Jede Schicht hat ihre eigene spezielle Funktion. Die speziellen Funktionen der einzelnen Schichten gehen bereits aus ihrer Bezeichnung hervor. Die Datenverbindungs- und die physische Schicht repräsentieren das verwendete physische Netzwerk, z. B. das Ethernet.

Fast alle Hardwareprotokolle arbeiten auf einer paketorientierten Basis. Die zu übertragenden Daten werden in Paketen gesammelt (sie können nicht alle auf einmal gesendet werden). Die maximale Größe eines TCP/IP-Pakets beträgt ca. 64 KB. Die Pakete sind in der Regel jedoch sehr viel kleiner, da die Netzwerkhardware ein einschränkender Faktor sein kann. Die maximale Größe eines Datenpakets in einem Ethernet beträgt ca. 1500 Byte. Die Größe eines TCP/IP-Pakets ist auf diesen Wert begrenzt, wenn die Daten über ein Ethernet gesendet werden. Wenn mehr Daten übertragen werden, müssen vom Betriebssystem mehr Datenpakete gesendet werden.

Damit die Schichten ihre vorgesehenen Funktionen erfüllen können, müssen im Datenpaket zusätzliche Informationen über die einzelnen Schichten gespeichert sein. Diese Informationen werden im Header des Pakets gespeichert. Jede Schicht stellt jedem ausgehenden Paket einen kleinen Datenblock voran, den so genannten Protokoll-Header. Ein Beispiel für ein TCP/IP-Datenpaket, das über ein Ethernetkabel gesendet wird, ist in Abbildung 19.2, „TCP/IP-Ethernet-Paket“ dargestellt. Die Prüfsumme befindet sich am Ende des Pakets, nicht am Anfang. Dies erleichtert die Arbeit für die Netzwerkhardware.

TCP/IP-Ethernet-Paket
Abbildung 19.2: TCP/IP-Ethernet-Paket
 

Wenn eine Anwendung Daten über das Netzwerk sendet, werden diese Daten durch alle Schichten geleitet, die mit Ausnahme der physischen Schicht alle im Linux-Kernel implementiert sind. Jede Schicht ist für das Vorbereiten der Daten zur Weitergabe an die nächste Schicht verantwortlich. Die unterste Schicht ist letztendlich für das Senden der Daten verantwortlich. Bei eingehenden Daten erfolgt die gesamte Prozedur in umgekehrter Reihenfolge. Die Protokoll-Header werden von den transportierten Daten in den einzelnen Schichten wie die Schalen einer Zwiebel entfernt. Die Transportschicht ist schließlich dafür verantwortlich, die Daten den Anwendungen am Ziel zur Verfügung zu stellen. Auf diese Weise kommuniziert eine Schicht nur mit der direkt darüber bzw. darunter liegenden Schicht. Für Anwendungen spielt es keine Rolle, ob Daten über eine drahtlose oder drahtgebundene Verbindung übertragen werden. Ähnlich spielt es für die Datenverbindung keine Rolle, welche Art von Daten übertragen wird, solange die Pakete das richtige Format haben.

19.1 IP-Adressen und Routing

 

Die in diesem Abschnitt enthaltenen Informationen beziehen sich nur auf IPv4-Netzwerke. Informationen zum IPv6-Protokoll, dem Nachfolger von IPv4, finden Sie in Abschnitt 19.2, „IPv6 – das Internet der nächsten Generation“.

19.1.1 IP-Adressen

 

Jeder Computer im Internet verfügt über eine eindeutige 32-Bit-Adresse. Diese 32 Bit (oder 4 Byte) werden in der Regel wie in der zweiten Zeile in Beispiel 19.1, „IP-Adressen schreiben“ dargestellt geschrieben.

Beispiel 19.1: IP-Adressen schreiben
 
IP Address (binary):  11000000 10101000 00000000 00010100
IP Address (decimal):      192.     168.       0.      20

Im Dezimalformat werden die vier Byte in Dezimalzahlen geschrieben und durch Punkte getrennt. Die IP-Adresse wird einem Host oder einer Netzwerkschnittstelle zugewiesen. Sie kann weltweit nur einmal verwendet werden. Es gibt zwar Ausnahmen zu dieser Regel, diese sind jedoch für die folgenden Abschnitte nicht relevant.

Die Punkte in IP-Adressen geben das hierarchische System an. Bis in die 1990er-Jahre wurden IP-Adressen strikt in Klassen organisiert. Dieses System erwies sich jedoch als zu wenig flexibel und wurde eingestellt. Heute wird das klassenlose Routing (CIDR, Classless Interdomain Routing) verwendet.

19.1.2 Netzmasken und Routing

 

Mit Netzmasken werden die Adressräume eines Subnetzes definiert. Wenn sich in einem Subnetz zwei Hosts befinden, können diese direkt aufeinander zugreifen. Wenn sie sich nicht im selben Subnetz befinden, benötigen sie die Adresse eines Gateways, das den gesamten Verkehr für das Subnetz verarbeitet. Um zu prüfen, ob sich zwei IP-Adressen im selben Subnetz befinden, wird jede Adresse bitweise mit der Netzmaske „UND“-verknüpft. Sind die Ergebnisse identisch, befinden sich beide IP-Adressen im selben lokalen Netzwerk. Wenn unterschiedliche Ergebnisse ausgegeben werden, kann die entfernte IP-Adresse, und somit die entfernte Schnittstelle, nur über ein Gateway erreicht werden.

Weitere Informationen zur Funktionsweise von Netzmasken finden Sie in Beispiel 19.2, „Verknüpfung von IP-Adressen mit der Netzmaske“. Die Netzmaske besteht aus 32 Bit, die festlegen, welcher Teil einer IP-Adresse zum Netzwerk gehört. Alle Bits mit dem Wert 1 kennzeichnen das entsprechende Bit in der IP-Adresse als zum Netzwerk gehörend. Alle Bits mit dem Wert 0 kennzeichnen Bits innerhalb des Subnetzes. Je mehr Bits den Wert 1 haben, desto kleiner ist also das Netzwerk. Da die Netzmaske immer aus mehreren aufeinander folgenden Bits mit dem Wert 1 besteht, ist es auch möglich, die Anzahl der Bits in der Netzmaske zu zählen. In Beispiel 19.2, „Verknüpfung von IP-Adressen mit der Netzmaske“ könnte das erste Netz mit 24 Bit auch als 192.168.0.0/24 geschrieben werden.

Beispiel 19.2: Verknüpfung von IP-Adressen mit der Netzmaske
 
IP address (192.168.0.20):  11000000 10101000 00000000 00010100
Netmask   (255.255.255.0):  11111111 11111111 11111111 00000000
---------------------------------------------------------------
Result of the link:         11000000 10101000 00000000 00000000
In the decimal system:           192.     168.       0.       0

IP address (213.95.15.200): 11010101 10111111 00001111 11001000
Netmask    (255.255.255.0): 11111111 11111111 11111111 00000000
---------------------------------------------------------------
Result of the link:         11010101 10111111 00001111 00000000
In the decimal system:           213.      95.      15.       0

Ein weiteres Beispiel: Alle Computer, die über dasselbe Ethernetkabel angeschlossen sind, befinden sich in der Regel im selben Subnetz und sind direkt zugreifbar. Selbst wenn das Subnetz physisch durch Switches oder Bridges unterteilt ist, können diese Hosts weiter direkt erreicht werden.

IP-Adressen außerhalb des lokalen Subnetzes können nur erreicht werden, wenn für das Zielnetzwerk ein Gateway konfiguriert ist. In den meisten Fällen wird der gesamte externe Verkehr über lediglich ein Gateway gehandhabt. Es ist jedoch auch möglich, für unterschiedliche Subnetze mehrere Gateways zu konfigurieren.

Wenn ein Gateway konfiguriert wurde, werden alle externen IP-Pakete an das entsprechende Gateway gesendet. Dieses Gateway versucht anschließend, die Pakete auf dieselbe Weise – von Host zu Host – weiterzuleiten, bis sie den Zielhost erreichen oder ihre TTL-Zeit (Time to Live) abgelaufen ist.

Spezifische Adressen
 
Netzwerkbasisadresse

Dies ist die Netzmaske, die durch UND mit einer Netzwerkadresse verknüpft ist, wie in Beispiel 19.2, „Verknüpfung von IP-Adressen mit der Netzmaske“ unter Result dargestellt. Diese Adresse kann keinem Host zugewiesen werden.

Rundrufadresse

Dies lässt sich auch wie folgt beschreiben: „Zugriff auf alle Hosts in diesem Subnetz.“ Um die Broadcast-Adresse zu generieren, wird die Netzmaske in die binäre Form invertiert und mit einem logischen ODER mit der Netzwerkbasisadresse verknüpft. Das obige Beispiel ergibt daher die Adresse 192.168.0.255. Diese Adresse kann keinem Host zugeordnet werden.

Lokaler Host

Die Adresse 127.0.0.1 ist auf jedem Host dem „Loopback-Device“ zugewiesen. Mit dieser Adresse und mit allen Adressen des vollständigen 127.0.0.0/8-Loopback-Netzwerks (wie bei IPv4 beschrieben) kann eine Verbindung zu Ihrem Computer eingerichtet werden. Bei IPv6 gibt es nur eine Loopback-Adresse (::1).

Da IP-Adressen weltweit eindeutig sein müssen, können Sie keine Adresse nach dem Zufallsprinzip wählen. Zum Einrichten eines privaten IP-basierten Netzwerks stehen drei Adressdomänen zur Verfügung. Diese können keine Verbindung zum Internet herstellen, da sie nicht über das Internet übertragen werden können. Diese Adressdomänen sind in RFC 1597 festgelegt und werden in Tabelle 19.1, „Private IP-Adressdomänen“ aufgelistet.

Tabelle 19.1: Private IP-Adressdomänen
 

Netzwerk/Netzmaske

Domäne

10.0.0.0/255.0.0.0

10.x.x.x

172.16.0.0/255.240.0.0

172.16.x.x – 172.31.x.x

192.168.0.0/255.255.0.0

192.168.x.x

19.2 IPv6 – das Internet der nächsten Generation

 
Wichtig
Wichtig: IBM Z: Unterstützung für IPv6

IPv6 wird von den CTC- und IUCV-Netzwerkverbindungen der IBM Z-Hardware nicht unterstützt.

Aufgrund der Entstehung des WWW (World Wide Web) hat das Internet in den letzten 15 Jahren ein explosives Wachstum mit einer immer größer werdenden Anzahl von Computern erfahren, die über TCP/IP kommunizieren. Seit Tim Berners-Lee bei CERN (http://public.web.cern.ch) 1990 das WWW erfunden hat, ist die Anzahl der Internethosts von ein paar tausend auf ca. 100 Millionen angewachsen.

Wie bereits erwähnt, besteht eine IPv4-Adresse nur aus 32 Bit. Außerdem gehen zahlreiche IP-Adressen verloren, da sie aufgrund der organisatorischen Bedingtheit der Netzwerke nicht verwendet werden können. Die Anzahl der in Ihrem Subnetz verfügbaren Adressen ist zwei hoch der Anzahl der Bits minus zwei. Ein Subnetz verfügt also beispielsweise über 2, 6 oder 14 Adressen. Um beispielsweise 128 Hosts mit dem Internet zu verbinden, benötigen Sie ein Subnetz mit 256 IP-Adressen, von denen nur 254 verwendbar sind, da zwei IP-Adressen für die Struktur des Subnetzes selbst benötigt werden: die Broadcast- und die Basisnetzwerkadresse.

Unter dem aktuellen IPv4-Protokoll sind DHCP oder NAT (Network Address Translation) die typischen Mechanismen, um einem potenziellen Adressmangel vorzubeugen. Kombiniert mit der Konvention, private und öffentliche Adressräume getrennt zu halten, können diese Methoden den Adressmangel sicherlich mäßigen. Das Problem liegt in der Konfiguration der Adressen, die schwierig einzurichten und zu verwalten ist. Um einen Host in einem IPv4-Netzwerk einzurichten, benötigen Sie mehrere Adressen, z. B. die IP-Adresse des Hosts, die Subnetzmaske, die Gateway-Adresse und möglicherweise die Adresse des Nameservers. Alle diese Einträge müssen bekannt sein und können nicht von anderer Stelle her abgeleitet werden.

Mit IPv6 gehören sowohl der Adressmangel als auch die komplizierte Konfiguration der Vergangenheit an. Die folgenden Abschnitte enthalten weitere Informationen zu den Verbesserungen und Vorteilen von IPv6 sowie zum Übergang vom alten zum neuen Protokoll.

19.2.1 Vorteile

 

Die wichtigste und augenfälligste Verbesserung durch das neuere Protokoll ist der enorme Zuwachs des verfügbaren Adressraums. Eine IPv6-Adresse besteht aus 128-Bit-Werten und nicht aus den herkömmlichen 32 Bit. Dies ermöglicht mehrere Billiarden IP-Adressen.

IPv6-Adressen unterscheiden sich nicht nur hinsichtlich ihrer Länge gänzlich von ihren Vorgängern. Sie verfügen auch über eine andere interne Struktur, die spezifischere Informationen zu den Systemen und Netzwerken enthalten kann, zu denen sie gehören. Weitere Informationen hierzu finden Sie in Abschnitt 19.2.2, „Adresstypen und -struktur“.

In der folgenden Liste werden andere Vorteile des neueren Protokolls aufgeführt:

Automatische Konfiguration

IPv6 macht das Netzwerk „Plug-and-Play“-fähig, d. h., ein neu eingerichtetes System wird ohne jegliche manuelle Konfiguration in das (lokale) Netzwerk integriert. Der neue Host verwendet die automatischen Konfigurationsmechanismen, um seine eigene Adresse aus den Informationen abzuleiten, die von den benachbarten Routern zur Verfügung gestellt werden. Dabei nutzt er ein Protokoll, das als ND-Protokoll (Neighbor Discovery) bezeichnet wird. Diese Methode erfordert kein Eingreifen des Administrators und für die Adresszuordnung muss kein zentraler Server verfügbar sein. Dies ist ein weiterer Vorteil gegenüber IPv4, bei dem für die automatische Adresszuordnung ein DHCP-Server erforderlich ist.

Wenn ein Router mit einem Switch verbunden ist, sollte der Router jedoch trotzdem periodische Anzeigen mit Flags senden, die den Hosts eines Netzwerks mitteilen, wie sie miteinander interagieren sollen. Weitere Informationen finden Sie im Artikel RFC 2462, auf der man-Seite radvd.conf(5) und im Artikel RFC 3315.

Mobilität

IPv6 ermöglicht es, einer Netzwerkschnittstelle gleichzeitig mehrere Adressen zuzuordnen. Dadurch können Benutzer problemlos auf mehrere Netzwerke zugreifen, was beispielsweise mit den von Mobilfunkunternehmen angebotenen internationalen Roaming-Diensten vergleichbar ist. Wenn Sie Ihr Mobiltelefon mit ins Ausland nehmen, meldet sich das Telefon automatisch bei dem fremden Dienst an, sobald Sie dessen Bereich betreten, sodass Sie überall unter Ihrer Rufnummer erreichbar sind und Anrufe genauso wie in Ihrem Heimatland tätigen können.

Sichere Kommunikation

Bei IPv4 ist die Netzwerksicherheit eine Add-on-Funktion. IPv6 umfasst IPSec als eine seiner Kernfunktionen und ermöglicht es Systemen, über einen sicheren Tunnel zu kommunizieren, um das Ausspionieren durch Außenstehende über das Internet zu verhindern.

Abwärtskompatibilität

Realistisch gesehen, ist es unmöglich, das gesamte Internet auf einmal von IPv4 auf IPv6 umzustellen. Daher ist es wichtig, dass beide Protokolle nicht nur im Internet, sondern auf einem System koexistieren können. Dies wird durch kompatible Adressen (IPv4-Adressen können problemlos in IPv6-Adressen konvertiert werden) und die Verwendung von Tunnels gewährleistet. Weitere Informationen hierzu finden Sie im Abschnitt 19.2.3, „Koexistenz von IPv4 und IPv6“. Außerdem können Systeme eine Dual-Stack-IP-Technik verwenden, um beide Protokolle gleichzeitig unterstützen zu können. Dies bedeutet, dass sie über zwei Netzwerk-Stacks verfügen, die vollständig unabhängig voneinander sind, sodass zwischen den beiden Protokollversionen keine Konflikte auftreten.

Bedarfsgerechte Dienste über Multicasting

Mit IPv4 müssen einige Dienste, z. B. SMB, ihre Pakete via Broadcast an alle Hosts im lokalen Netzwerk verteilen. Bei IPv6 ist dagegen eine deutlich feinere Vorgehensweise möglich: Die Server können die Hosts per Multicasting adressieren, also mehrere Hosts als Teil einer Gruppe. Dies unterscheidet sich vom Broadcasting, bei dem alle Hosts gleichzeitig adressiert werden, und vom Unicasting, bei dem jeder Host einzeln adressiert werden muss. Welche Hosts als Gruppe adressiert werden, kann je nach Anwendung unterschiedlich sein. Es gibt einige vordefinierte Gruppen, mit der beispielsweise alle Namenserver (die Multicast-Gruppe „all name servers“) oder alle Router (die Multicast-Gruppe „all routers“) angesprochen werden können.

19.2.2 Adresstypen und -struktur

 

Wie bereits erwähnt, hat das aktuelle IP-Protokoll zwei wichtige Einschränkungen: Es stehen zunehmend weniger IP-Adressen zur Verfügung und das Konfigurieren des Netzwerks und Verwalten der Routing-Tabellen wird komplexer und aufwändiger. IPv6 löst das erste Problem durch die Erweiterung des Adressraums auf 128 Bit. Das zweite Problem wird durch die Einführung einer hierarchischen Adressstruktur gemildert, die mit weiteren hoch entwickelten Techniken zum Zuordnen von Netzwerkadressen sowie mit dem Multihoming (der Fähigkeit, einem Gerät mehrere Adressen zuzuordnen und so den Zugriff auf mehrere Netzwerke zu ermöglichen) kombiniert wird.

Bei der Arbeit mit IPv6 ist es hilfreich, die drei unterschiedlichen Adresstypen zu kennen:

Unicast

Adressen dieses Typs werden genau einer Netzwerkschnittstelle zugeordnet. Pakete mit derartigen Adressen werden nur einem Ziel zugestellt. Unicast-Adressen werden dementsprechend zum Übertragen von Paketen an einzelne Hosts im lokalen Netzwerk oder im Internet verwendet.

Multicast

Adressen dieses Typs beziehen sich auf eine Gruppe von Netzwerkschnittstellen. Pakete mit derartigen Adressen werden an alle Ziele zugestellt, die dieser Gruppe angehören. Multicast-Adressen werden hauptsächlich von bestimmten Netzwerkdiensten für die Kommunikation mit bestimmten Hostgruppen verwendet, wobei diese gezielt adressiert werden.

Anycast

Adressen dieses Typs beziehen sich auf eine Gruppe von Schnittstellen. Pakete mit einer derartigen Adresse werden gemäß den Prinzipien des zugrunde liegenden Routing-Protokolls dem Mitglied der Gruppe gesendet, das dem Absender am nächsten ist. Anycast-Adressen werden verwendet, damit Hosts Informationen zu Servern schneller abrufen können, die im angegebenen Netzwerkbereich bestimmte Dienste anbieten. Sämtliche Server desselben Typs verfügen über dieselbe Anycast-Adresse. Wann immer ein Host einen Dienst anfordert, erhält er eine Antwort von dem vom Routing-Protokoll ermittelten nächstgelegenen Server. Wenn dieser Server aus irgendeinem Grund nicht erreichbar ist, wählt das Protokoll automatisch den zweitnächsten Server, dann den dritten usw. aus.

Eine IPv6-Adresse besteht aus acht vierstelligen Feldern, wobei jedes 16 Bit repräsentiert, und wird in hexadezimaler Notation geschrieben. Sie werden durch Doppelpunkte (:) getrennt. Alle führenden Null-Byte innerhalb eines bestimmten Felds können ausgelassen werden, alle anderen Nullen jedoch nicht. Eine weitere Konvention ist, dass mehr als vier aufeinander folgenden Null-Byte mit einem doppelten Doppelpunkt zusammengefasst werden können. Jedoch ist pro Adresse nur ein solcher doppelter Doppelpunkt (::) zulässig. Diese Art der Kurznotation wird in Beispiel 19.3, „Beispiel einer IPv6-Adresse“ dargestellt, in dem alle drei Zeilen derselben Adresse entsprechen.

Beispiel 19.3: Beispiel einer IPv6-Adresse
 
fe80 : 0000 : 0000 : 0000 : 0000 : 10 : 1000 : 1a4
fe80 :    0 :    0 :    0 :    0 : 10 : 1000 : 1a4
fe80 :                           : 10 : 1000 : 1a4

Jeder Teil einer IPv6-Adresse hat eine festgelegte Funktion. Die ersten Byte bilden das Präfix und geben den Typ der Adresse an. Der mittlere Teil ist der Netzwerkteil der Adresse, der möglicherweise nicht verwendet wird. Das Ende der Adresse bildet der Hostteil. Bei IPv6 wird die Netzmaske definiert, indem die Länge des Präfixes nach einem Schrägstrich am Ende der Adresse angegeben wird. Adressen wie in Beispiel 19.4, „IPv6-Adressen mit Angabe der Präfix-Länge“ enthalten Informationen zum Netzwerk (die ersten 64 Bit) und zum Hostteil (die letzten 64 Bit). Die 64 bedeutet, dass die Netzmaske mit 64 1-Bit-Werten von links gefüllt wird. Wie bei IPv4 wird die IP-Adresse mit den Werten aus der Netzmaske durch UND verknüpft, um zu ermitteln, ob sich der Host im selben oder einem anderen Subnetz befindet.

Beispiel 19.4: IPv6-Adressen mit Angabe der Präfix-Länge
 
fe80::10:1000:1a4/64

IPv6 kennt mehrere vordefinierte Präfixtypen. Einige sind unter Unterschiedliche IPv6-Präfixe aufgeführt.

Unterschiedliche IPv6-Präfixe
 
00

IPv4-über-IPv6-Kompatibilitätsadressen. Diese werden zur Erhaltung der Kompatibilität mit IPv4 verwendet. Für diesen Adresstyp wird ein Router benötigt, der IPv6-Pakete in IPv4-Pakete konvertieren kann. Mehrere spezielle Adressen, z. B. die für das Loopback-Device, verfügen ebenfalls über dieses Präfix.

2 oder 3 als erste Stelle

Aggregierbare globale Unicast-Adressen. Wie bei IPv4 kann eine Schnittstelle zugewiesen werden, um einen Teil eines bestimmten Subnetzes zu bilden. Aktuell stehen die folgenden Adressräume zur Verfügung: 2001::/16 (Adressraum Produktionsqualität) und 2002::/16 (6to4-Adressraum).

fe80::/10

Link-local-Adressen. Adressen mit diesem Präfix dürfen nicht geroutet werden und können daher nur im gleichen Subnetz erreicht werden.

fec0::/10

Site-local-Adressen. Diese Adressen dürfen zwar geroutet werden, aber nur innerhalb des Organisationsnetzwerks, dem sie angehören. Damit entsprechen diese Adressen den bisherigen privaten Netzen (beispielsweise 10.x.x.x).

ff

Dies sind Multicast-Adressen.

Eine Unicast-Adresse besteht aus drei grundlegenden Komponenten:

Öffentliche Topologie

Der erste Teil, der unter anderem auch eines der oben erwähnten Präfixe enthält, dient dem Routing des Pakets im öffentlichen Internet. Hier sind Informationen zum Provider oder der Institution kodiert, die den Netzwerkzugang bereitstellen.

Site-Topologie

Der zweite Teil enthält Routing-Informationen zu dem Subnetz, in dem das Paket zugestellt werden soll.

Schnittstellen-ID

Der dritte Teil identifiziert eindeutig die Schnittstelle, an die das Paket gerichtet ist. Dies erlaubt, die MAC-Adresse als Adressbestandteil zu verwenden. Da diese weltweit nur einmal vorhanden und zugleich vom Hardwarehersteller fest vorgegeben ist, vereinfacht sich die Konfiguration auf diese Weise sehr. Die ersten 64 Bit werden zu einem so genannten EUI-64-Token zusammengefasst. Dabei werden die letzten 48 Bit der MAC-Adresse entnommen und die restlichen 24 Bit enthalten spezielle Informationen, die etwas über den Typ des Tokens aussagen. Das ermöglicht dann auch, Geräten ohne MAC-Adresse (z. B. PPP-Verbindungen) ein EUI-64-Token zuzuweisen.

Abgeleitet aus diesem Grundaufbau werden bei IPv6 fünf verschiedene Typen von Unicast-Adressen unterschieden:

:: (nicht spezifiziert)

Ein Host verwendet diese Adresse als Quelladresse, wenn seine Netzwerkschnittstelle zum ersten Mal initialisiert wird (wobei die Adresse zu diesm Zeitpunkt noch nicht anderweitig ermittelt werden kann).

::1 (Loopback)

Adresse des Loopback-Device.

IPv4-kompatible Adressen

Die IPv6-Adresse setzt sich aus der IPv4-Adresse und einem Präfix von 96 0-Bits zusammen. Dieser Typ der Kompatibilitätsadresse wird beim Tunneling verwendet (siehe Abschnitt 19.2.3, „Koexistenz von IPv4 und IPv6“). IPv4/IPv6-Hosts können so mit anderen kommunizieren, die sich in einer reinen IPv4-Umgebung befinden.

IPv6-gemappte IPv4-Adressen

Dieser Adresstyp gibt die Adresse in IPv6-Notation an.

Lokale Adressen

Es gibt zwei Typen von Adressen zum rein lokalen Gebrauch:

link-local

Dieser Adresstyp ist ausschließlich für den Gebrauch im lokalen Subnetz bestimmt. Router dürfen Pakete mit einer solchen Ziel- oder Quelladresse nicht an das Internet oder andere Subnetze weiterreichen. Diese Adressen zeichnen sich durch ein spezielles Präfix (fe80::/10) und die Schnittstellen-ID der Netzwerkkarte aus. Der Mittelteil der Adresse besteht aus Null-Bytes. Diese Art Adresse wird von den Autokonfigurationsmethoden verwendet, um Hosts im selben Subnetz anzusprechen.

site-local

Pakete mit diesem Adresstyp dürfen zwischen einzelnen Subnetzen geroutet werden, aber nicht außerhalb einer Organisation ins Internet gelangen. Solche Adressen werden für Intranets eingesetzt und sind ein Äquivalent zu den privaten IPv4-Adressen. Sie bestehen aus einem besonderen Präfix (fec0::/10), der Schnittstellen-ID und einem 16-Bit-Feld mit der Subnetz-ID. Die restlichen Stellen werden wieder mit Null-Bytes gefüllt.

Zusätzlich gibt es in IPv6 eine grundsätzlich neue Funktion: Einer Netzwerkschnittstelle werden in der Regel mehrere IP-Adressen zugewiesen. Das hat den Vorteil, dass mehrere verschiedene Netzwerke zur Verfügung stehen. Eines dieser Netzwerke kann mit der MAC-Adresse und einem bekannten Präfix vollautomatisch konfiguriert werden, sodass nach der Aktivierung von IPv6 alle Hosts im lokalen Netz über Link-local-Adressen erreichbar sind. Durch die MAC-Adresse als Bestandteil der IP-Adresse ist jede dieser Adressen global eindeutig. Einzig die Teile der Site-Topologie und der öffentlichen Topologie können variieren, je nachdem in welchem Netz dieser Host aktuell zu erreichen ist.

Bewegt sich ein Host zwischen mehreren Netzen hin und her, braucht er mindestens zwei Adressen. Die eine, seine Home-Adresse, beinhaltet neben der Schnittstellen-ID die Informationen zu dem Heimatnetz, in dem der Computer normalerweise betrieben wird, und das entsprechende Präfix. Die Home-Adresse ist statisch und wird in der Regel nicht verändert. Alle Pakete, die für diesen Host bestimmt sind, werden ihm sowohl im eigenen als auch in fremden Netzen zugestellt. Möglich wird die Zustellung im Fremdnetz über wesentliche Neuerungen des IPv6-Protokolls, z. B. Stateless Autoconfiguration und Neighbor Discovery. Der mobile Rechner hat neben seiner Home-Adresse eine oder mehrere weitere Adressen, die zu den fremden Netzen gehören, in denen er sich bewegt. Diese Adressen heißen Care-of-Adressen. Im Heimatnetz des mobilen Rechners muss eine Instanz vorhanden sein, die an seine Home-Adresse gerichtete Pakete nachsendet, sollte er sich in einem anderen Netz befinden. Diese Funktion wird in einer IPv6-Umgebung vom Home-Agenten übernommen. Er stellt alle Pakete, die an die Home-Adresse des mobilen Rechners gerichtet sind, über einen Tunnel zu. Pakete, die als Zieladresse die Care-of-Adresse tragen, können ohne Umweg über den Home-Agenten zugestellt werden.

19.2.3 Koexistenz von IPv4 und IPv6

 

Die Migration aller mit dem Internet verbundenen Hosts von IPv4 auf IPv6 wird nicht auf einen Schlag geschehen. Vielmehr werden das alte und das neue Protokoll noch eine ganze Weile nebeneinanderher existieren. Die Koexistenz auf einem Rechner ist dann möglich, wenn beide Protokolle im Dual Stack-Verfahren implementiert sind. Es bleibt aber die Frage, wie IPv6-Rechner mit IPv4-Rechnern kommunizieren können und wie IPv6-Pakete über die momentan noch vorherrschenden IPv4-Netze transportiert werden sollen. Tunneling und die Verwendung von Kompatibilitätsadressen (siehe Abschnitt 19.2.2, „Adresstypen und -struktur“) sind hier die besten Lösungen.

IPv6-Hosts, die im (weltweiten) IPv4-Netzwerk mehr oder weniger isoliert sind, können über Tunnel kommunizieren: IPv6-Pakete werden als IPv4-Pakete gekapselt und so durch ein ein IPv4-Netzwerk übertragen. Ein Tunnel ist definiert als die Verbindung zwischen zwei IPv4-Endpunkten. Hierbei müssen die Pakete die IPv6-Zieladresse (oder das entsprechende Präfix) und die IPv4-Adresse des entfernten Hosts am Tunnelendpunkt enthalten. Einfache Tunnel können von den Administratoren zwischen ihren Netzwerken manuell und nach Absprache konfiguriert werden. Ein solches Tunneling wird statisches Tunneling genannt.

Trotzdem reicht manuelles Tunneling oft nicht aus, um die Menge der zum täglichen vernetzten Arbeiten nötigen Tunnel aufzubauen und zu verwalten. Aus diesem Grund wurden für IPv6 drei verschiedene Verfahren entwickelt, die das dynamische Tunneling erlauben:

6over4

IPv6-Pakete werden automatisch in IPv4-Pakete verpackt und über ein IPv4-Netzwerk versandt, in dem Multicasting aktiviert ist. IPv6 wird vorgespiegelt, das gesamte Netzwerk (Internet) sei ein einziges, riesiges LAN (Local Area Network). So wird der IPv4-Endpunkt des Tunnel automatisch ermittelt. Nachteile dieser Methode sind die schlechte Skalierbarkeit und die Tatsache, dass IP-Multicasting keineswegs im gesamten Internet verfügbar ist. Diese Lösung eignet sich für kleinere Netzwerke, die die Möglichkeit von IP-Multicasting bieten. Die zugrunde liegenden Spezifikationen sind in RFC 2529 enthalten.

6to4

Bei dieser Methode werden automatisch IPv4-Adressen aus IPv6-Adressen generiert. So können isolierte IPv6-Hosts über ein IPv4-Netz miteinander kommunizieren. Allerdings gibt es einige Probleme, die die Kommunikation zwischen den isolierten IPv6-Hosts und dem Internet betreffen. Diese Methode wird in RFC 3056 beschrieben.

IPv6 Tunnel Broker

Dieser Ansatz sieht spezielle Server vor, die für IPv6 automatisch dedizierte Tunnel anlegen. Diese Methode wird in RFC 3053 beschrieben.

19.2.4 IPv6 konfigurieren

 

Um IPv6 zu konfigurieren, müssen Sie auf den einzelnen Arbeitsstationen in der Regel keine Änderungen vornehmen. IPv6 ist standardmäßig aktiviert. Um IPv6 auf einem installierten System zu deaktivieren oder zu aktivieren, verwenden Sie das Modul YaST-Netzwerkeinstellungen. Aktivieren oder deaktivieren Sie auf dem Karteireiter Globale Optionen die Option IPv6 aktivieren, falls nötig. Zum vorübergehenden Aktivieren bis zum nächsten Neustart geben Sie modprobe  -i ipv6 als root ein. Nach dem Laden des IPv6-Moduls kann es nicht mehr entladen werden.

Aufgrund des Konzepts der automatischen Konfiguration von IPv6 wird der Netzwerkkarte eine Adresse im Link-local-Netzwerk zugewiesen. In der Regel werden Routing-Tabellen nicht auf Arbeitsstationen verwaltet. Bei Netzwerkroutern kann von der Arbeitsstation unter Verwendung des Router-Advertisement-Protokolls abgefragt werden, welches Präfix und welche Gateways implementiert werden sollen. Zum Einrichten eines IPv6-Routers kann das radvd-Programm verwendet werden. Dieses Programm informiert die Arbeitsstationen darüber, welches Präfix und welche Router für die IPv6-Adressen verwendet werden sollen. Alternativ können Sie die Adressen und das Routing auch mit zebra/quagga automatisch konfigurieren.

Weitere Informationen zum Einrichten verschiedneer Tunnel mit den Dateien in /etc/sysconfig/network finden Sie auf der man-Seite zu ifcfg-tunnel (man ifcfg-tunnel).

19.2.5 Weitere Informationen

 

Das komplexe IPv6-Konzept wird im obigen Überblick nicht vollständig abgedeckt. Weitere ausführliche Informationen zu dem neueren Protokoll finden Sie in den folgenden Online-Dokumentationen und -Büchern:

http://www.ipv6.org/

Alles rund um IPv6.

http://www.ipv6day.org

Alle Informationen, die Sie benötigen, um Ihr eigenes IPv6-Netzwerk zu starten.

http://www.ipv6-to-standard.org/

Die Liste der IPv6-fähigen Produkte.

http://www.bieringer.de/linux/IPv6/

Hier finden Sie den Beitrag „Linux IPv6 HOWTO“ und viele verwandte Links zum Thema.

RFC 2460

Die grundlegenden IPv6-Spezifikationen.

IPv6 Essentials

Ein Buch, in dem alle wichtigen Aspekte zum Thema enthalten sind, ist IPv6 Essentials von Silvia Hagen (ISBN 0-596-00125-8).

19.3 Namensauflösung

 

Mithilfe von DNS kann eine IP-Adresse einem oder sogar mehreren Namen zugeordnet werden und umgekehrt auch ein Name einer IP-Adresse. Unter Linux erfolgt diese Umwandlung üblicherweise durch eine spezielle Software namens bind. Der Computer, der diese Umwandlung dann erledigt, nennt sich Namenserver. Dabei bilden die Namen wieder ein hierarchisches System, in dem die einzelnen Namensbestandteile durch Punkte getrennt sind. Die Namenshierarchie ist aber unabhängig von der oben beschriebenen Hierarchie der IP-Adressen.

Ein Beispiel für einen vollständigen Namen wäre jupiter.example.com, geschrieben im Format Hostname.Domäne. Ein vollständiger Name, der als Fully Qualified Domain Name oder kurz als FQDN bezeichnet wird, besteht aus einem Host- und einem Domänennamen (example.com). Ein Bestandteil des Domänennamens ist die Top Level Domain oder TLD (com).

Aus historischen Gründen ist die Zuteilung der TLDs etwas verwirrend. So werden in den USA traditionell dreibuchstabige TLDs verwendet, woanders aber immer die aus zwei Buchstaben bestehenden ISO-Länderbezeichnungen. Seit 2000 stehen zusätzliche TLDs für spezielle Sachgebiete mit zum Teil mehr als drei Buchstaben zur Verfügung (z. B. .info, .name, .museum).

In der Frühzeit des Internets (vor 1990) gab es die Datei/etc/hosts, in der die Namen aller im Internet vertretenen Rechner gespeichert waren. Dies erwies sich bei der schnell wachsenden Menge der mit dem Internet verbundenen Computer als unpraktikabel. Deshalb wurde eine dezentralisierte Datenbank entworfen, die die Hostnamen verteilt speichern kann. Diese Datenbank, eben jener oben erwähnte Namenserver, hält also nicht die Daten aller Computer im Internet vorrätig, sondern kann Anfragen an ihm nachgeschaltete, andere Namenserver weiterdelegieren.

An der Spitze der Hierarchie befinden sich die root-Namenserver. Die root-Namenserver verwalten die Domänen der obersten Ebene (Top Level Domains) und werden vom Network Information Center (NIC) verwaltet. Der root-Namenserver kennt die jeweils für eine Top Level Domain zuständigen Namenserver. Weitere Informationen zu TLD-NICs finden Sie unter http://www.internic.net.

Der DNS bietet viel mehr Möglichkeiten als die bloße Namensauflösung. Der Namenserver weiß auch, welcher Host für eine ganze Domäne Emails annimmt, der so genannte Mail Exchanger (MX).

Damit auch Ihr Computer einen Namen in eine IP-Adresse auflösen kann, muss ihm mindestens ein Nameserver mit einer IP-Adresse bekannt sein. Ein Namensserver kann einfach mithilfe von YaST angegeben werden. Die Konfiguration des Nameserverzugriffs unter SUSE® Linux Enterprise Server ist in Abschnitt 19.4.1.4, „Konfigurieren des Hostnamens und des DNS“ beschrieben. Eine Beschreibung zum Einrichten Ihres Nameservers finden Sie in Kapitel 31, Domain Name System (DNS).

Eng verwandt mit DNS ist das Protokoll whois. Mit dem gleichnamigen Programm können Sie schnell ermitteln, wer für eine bestimmte Domäne verantwortlich ist.

Anmerkung
Anmerkung: MDNS- und .local-Domänennamen

Die Domäne .local der obersten Stufe wird vom Resolver als link-local-Domäne behandelt. DNS-Anforderungen werden als Multicast-DNS-Anforderungen anstelle von normalen DNS-Anforderungen gesendet. Wenn Sie in Ihrer Nameserver-Konfiguration die Domäne .local verwenden, müssen Sie diese Option in /etc/host.conf ausschalten. Weitere Informationen finden Sie auf der man-Seite host.conf.

Soll MDNS während der Installation ausgeschaltet werden, verwenden Sie nomdns=1 als Bootparameter.

Weitere Informationen zum Multicast-DNS finden Sie unter http://www.multicastdns.org.

19.4 Konfigurieren von Netzwerkverbindungen mit YaST

 

Unter Linux gibt es viele unterstützte Netzwerktypen. Die meisten verwenden unterschiedliche Gerätenamen und die Konfigurationsdateien sind im Dateisystem an unterschiedlichen Speicherorten verteilt. Einen detaillierten Überblick über die Aspekte der manuellen Netzwerkkonfiguration finden Sie in Abschnitt 19.5, „Manuelle Netzwerkkonfiguration“.

Alle Netzwerkschnittstellen mit aktivierter Verbindung (also mit angeschlossenem Netzwerkkabel) werden automatisch konfiguriert. Zusätzliche Hardware kann jederzeit nach Abschluss der Installation auf dem installierten System konfiguriert werden. In den folgenden Abschnitten wird die Netzwerkkonfiguration für alle von SUSE Linux Enterprise Server unterstützten Netzwerkverbindungen beschrieben.

Tipp
Tipp: IBM Z: Hotplug-fähige Netzwerkkarten

Auf den IBM Z-Plattformen werden Hotplug-fähige Netzwerkkarten unterstützt, aber nicht deren automatische Netzwerkintegration über DHCP (wie beim PC). Nachdem diese erkannt wurden, müssen Sie die Schnittstelle manuell konfigurieren.

19.4.1 Konfigurieren der Netzwerkkarte mit YaST

 

Zur Konfiguration verkabelter oder drahtloser Netzwerkkarten in YaST wählen Sie System › Netzwerkeinstellungen. Nach dem Öffnen des Moduls zeigt YaST das Dialogfeld Netzwerkeinstellungen mit den vier Karteireitern Globale Optionen, Übersicht, Hostname/DNS und Routing an.

Auf dem Karteireiter Globale Optionen können allgemeine Netzwerkoptionen wie die Netzwerkeinrichtungsmethode, IPv6 und allgemeine DHCP-Optionen festgelegt werden. Weitere Informationen finden Sie im Abschnitt 19.4.1.1, „Konfigurieren globaler Netzwerkoptionen“.

Der Karteireiter Übersicht enthält Informationen über installierte Netzwerkschnittstellen und -konfigurationen. Jede korrekt erkannte Netzwerkkarte wird dort mit ihrem Namen aufgelistet. In diesem Dialogfeld können Sie Karten manuell konfigurieren, entfernen oder ihre Konfiguration ändern. Informationen zum manuellen Konfigurieren von Karten, die nicht automatisch erkannt wurden, finden Sie unter Abschnitt 19.4.1.3, „Konfigurieren einer unerkannten Netzwerkkarte“. Informationen zum Ändern der Konfiguration einer bereits konfigurierten Karte finden Sie unter Abschnitt 19.4.1.2, „Ändern der Konfiguration einer Netzwerkkarte“.

Auf dem Karteireiter Hostname/DNS können der Hostname des Computers sowie die zu verwendenden Nameserver festgelegt werden. Weitere Informationen finden Sie im Abschnitt 19.4.1.4, „Konfigurieren des Hostnamens und des DNS“.

Der Karteireiter Routing wird zur Konfiguration des Routings verwendet. Weitere Informationen zu diesem Thema finden Sie unter dem Stichwort Abschnitt 19.4.1.5, „Konfigurieren des Routings“.

Konfigurieren der Netzwerkeinstellungen
Abbildung 19.3: Konfigurieren der Netzwerkeinstellungen
 

19.4.1.1 Konfigurieren globaler Netzwerkoptionen

 

Auf dem Karteireiter Globale Optionen des YaST-Moduls Netzwerkeinstellungen können wichtige globale Netzwerkoptionen wie die Verwendung der Optionen NetworkManager, IPv6 und DHCP-Client festgelegt werden. Diese Einstellungen sind für alle Netzwerkschnittstellen anwendbar.

Anmerkung
Anmerkung: NetworkManager von der Arbeitsplatzrechnererweiterung bereitgestellt

NetworkManager wird nun von der SUSE Linux Enterprise-Arbeitsplatzrechner-Erweiterung bereitgestellt. Aktivieren Sie zur Installation von NetworkManager das Repository für die Arbeitsplatzrechnererweiterung und wählen Sie die NetworkManager-Pakete aus.

Unter Netzwerkeinrichtungsmethode wählen Sie die Methode aus, mit der Netzwerkverbindungen verwaltet werden sollen. Wenn die Verbindungen für alle Schnittstellen über das Desktop-Applet NetworkManager verwaltet werden sollen, wählen Sie NetworkManager-Dienst aus. NetworkManager eignet sich besonders für den Wechsel zwischen verschiedenen verkabelten und drahtlosen Netzwerken. Wenn Sie keine Desktop-Umgebung ausführen oder wenn Ihr Rechner ein Xen-Server oder ein virtuelles System ist oder Netzwerkdienste wie DHCP oder DNS in Ihrem Netzwerk zur Verfügung stellt, verwenden Sie die Methode Wicked-Dienst. Beim Einsatz von NetworkManager sollte nm-applet verwendet werden, um Netzwerkoptionen zu konfigurieren. Die Karteireiter Übersicht, Hostname/DNS und Routing des Moduls Netzwerkeinstellungen sind dann deaktiviert. Weitere Informationen zu NetworkManager finden Sie in der Dokumentation für SUSE Linux Enterprise Desktop.

Geben Sie unter IPv6-Protokoll-Einstellungen an, ob Sie das IPv6-Protokoll verwenden möchten. IPv6 kann parallel zu IPv4 verwendet werden. IPv6 ist standardmäßig aktiviert. In Netzwerken, die das IPv6-Protokoll nicht verwenden, können die Antwortzeiten jedoch schneller sein, wenn dieses Protokoll deaktiviert ist. Zum Deaktivieren von IPv6 deaktivieren Sie die Option IPv6 aktivieren. Wenn IPv6 deaktiviert ist, lädt der Kernel das IPv6-Modul nicht mehr automatisch. Diese Einstellung wird nach einem Neustart übernommen.

Unter Optionen für DHCP-Client konfigurieren Sie die Optionen für den DHCP-Client. Die Kennung für DHCP-Client muss innerhalb eines Netzwerks für jeden DHCP-Client eindeutig sein. Wenn dieses Feld leer bleibt, wird standardmäßig die Hardware-Adresse der Netzwerkschnittstelle als Kennung übernommen. Falls Sie allerdings mehrere virtuelle Computer mit der gleichen Netzwerkschnittstelle und damit der gleichen Hardware-Adresse ausführen, sollten Sie hier eine eindeutige Kennung in beliebigem Format eingeben.

Unter Zu sendender Hostname wird eine Zeichenkette angegeben, die für das Optionsfeld „Hostname“ verwendet wird, wenn der DHCP-Client Nachrichten an den DHCP-Server sendet. Einige DHCP-Server aktualisieren Nameserver-Zonen gemäß diesem Hostnamen (dynamischer DNS). Bei einigen DHCP-Servern muss das Optionsfeld Zu sendender Hostname in den DHCP-Nachrichten der Clients zudem eine bestimmte Zeichenkette enthalten. Übernehmen Sie die Einstellung AUTO, um den aktuellen Hostnamen zu senden (d. h. der aktuelle in /etc/HOSTNAME festgelegte Hostname). Soll kein Hostname gesendet werden, leeren Sie dieses Feld.

Wenn die Standardroute nicht gemäß den Informationen von DHCP geändert werden soll, deaktivieren Sie Standardroute über DHCP ändern.

19.4.1.2 Ändern der Konfiguration einer Netzwerkkarte

 

Wenn Sie die Konfiguration einer Netzwerkkarte ändern möchten, wählen Sie die Karte aus der Liste der erkannten Karten unter Netzwerkeinstellungen › Übersicht in YaST aus, und klicken Sie auf Bearbeiten. Das Dialogfeld Netzwerkkarten-Setup wird angezeigt. Hier können Sie die Kartenkonfiguration auf den Karteireitern Allgemein, Adresse und Hardware anpassen.

19.4.1.2.1 IP-Adressen konfigurieren
 

Die IP-Adresse der Netzwerkkarte oder die Art der Festlegung dieser IP-Adresse kann auf dem Karteireiter Adresse im Dialogfeld Einrichten der Netzwerkkarte festgelegt werden. Die Adressen IPv4 und IPv6 werden unterstützt. Für die Netzwerkkarte können die Einstellungen Keine IP-Adresse (nützlich für eingebundene Geräte), Statisch zugewiesene IP-Adresse (IPv4 oder IPv6) oder Dynamische Adresse über DHCP und/oder Zeroconf zugewiesen werden.

Wenn Sie Dynamische Adresse verwenden, wählen Sie, ob Nue DHCP-Version 4 (für IPv4), Nur DHCP-Version 6 (für IPv6) oder DHCP-Version 4 und 6 verwendet werden soll.

Wenn möglich wird die erste Netzwerkkarte mit einer Verbindung, die bei der Installation verfügbar ist, automatisch zur Verwendung der automatischen Adressenkonfiguration mit DHCP konfiguriert.

Anmerkung
Anmerkung: IBM Z und DHCP

Auf IBM Z-Plattformen wird die DHCP-basierte Adressenkonfiguration nur mit Netzwerkkarten unterstützt, die über eine MAC-Adresse verfügen. Das ist nur der Fall bei OSA- und OSA Express-Karten.

DHCP sollten Sie auch verwenden, wenn Sie eine DSL-Leitung verwenden, Ihr ISP (Internet Service Provider) Ihnen aber keine statische IP-Adresse zugewiesen hat. Wenn Sie DHCP verwenden möchten, konfigurieren Sie dessen Einstellungen im Dialogfeld Netzwerkeinstellungen des YaST-Konfigurationsmoduls für Netzwerkkarten auf dem Karteireiter Globale Optionen unter Optionen für DHCP-Client. In einer virtuellen Hostumgebung, in der mehrere Hosts über dieselbe Schnittstelle kommunizieren, müssen diese anhand der Kennung für DHCP-Client unterschieden werden.

DHCP eignet sich gut zur Client-Konfiguration, aber zur Server-Konfiguration ist es nicht ideal. Wenn Sie eine statische IP-Adresse festlegen möchten, gehen Sie wie folgt vor:

  1. Wählen Sie im YaST-Konfigurationsmodul für Netzwerkkarten auf dem Karteireiter Übersicht in der Liste der erkannten Karten eine Netzwerkkarte aus, und klicken Sie auf Bearbeiten.

  2. Wählen Sie auf dem Karteireiter Adresse die Option Statisch zugewiesene IP-Adresse aus.

  3. Geben Sie die IP-Adresse ein. Es können beide Adressen, IPv4 und IPv6, verwendet werden. Geben Sie die Netzwerkmaske in Teilnetzmaske ein. Wenn die IPv6-Adresse verwendet wird, benutzen Sie Teilnetzmaske für die Präfixlänge im Format /64.

    Optional kann ein voll qualifizierter Hostname für diese Adresse eingegeben werden, der in die Konfigurationsdatei /etc/hosts geschrieben wird.

  4. Klicken Sie auf Weiter.

  5. Klicken Sie auf OK, um die Konfiguration zu aktivieren.

Anmerkung
Anmerkung: Schnittstellenaktivierung und Linkerkennung

Bei der Aktivierung einer Netzwerkschnittstelle sucht wicked nach einem Träger und die IP-Konfiguration wird erst dann angewendet, wenn ein Link erkannt wurde. Wenn die Konfiguration unabhängig vom Link-Status angewendet werden soll (etwa wenn Sie einen Dienst testen, der eine bestimmte Adresse überwacht), können Sie die Link-Verbindung überspringen. Hängen Sie hierzu die Variable LINK_REQUIRED=no an die Konfigurationsdatei der Schnittstelle unter /etc/sysconfig/network/ifcfg an.

Darüber hinaus können Sie mit der Variablen LINK_READY_WAIT=5 die Zeitüberschreitung (in Sekunden) für das Erkennen eines Links festlegen.

Weitere Informationen zu den ifcfg-*-Konfigurationsdateien finden Sie unter Abschnitt 19.5.2.5, „/etc/sysconfig/network/ifcfg-*“ und man 5 ifcfg.

Wenn Sie die statische Adresse verwenden, werden die Namenserver und das Standard-Gateway nicht automatisch konfiguriert. Informationen zur Konfiguration von Namenservern finden Sie unter Abschnitt 19.4.1.4, „Konfigurieren des Hostnamens und des DNS“. Informationen zur Konfiguration eines Gateways finden Sie unter Abschnitt 19.4.1.5, „Konfigurieren des Routings“.

19.4.1.2.2 Konfigurieren mehrerer Adressen
 

Ein Netzwerkgerät kann mehrere IP-Adressen haben.

Anmerkung
Anmerkung: Aliasse stellen eine Kompatibilitätsfunktion dar

Diese sogenannten Aliasse oder Kennungen sind nur mit IPv4 verwendbar. Bei IPv6 werden sie ignoriert. Bei der Verwendung von iproute2-Netzwerkschnittstellen können eine oder mehrere Adressen vorhanden sein.

Gehen Sie folgendermaßen vor, wenn Sie weitere Adressen für Ihre Netzwerkkarte mithilfe von YaST einrichten möchten:

  1. Wählen Sie im YaST-Dialogfeld Netzwerkeinstellungen auf dem Karteireiter Übersicht in der Liste der erkannten Karten eine Netzwerkkarte aus, und klicken Sie auf Bearbeiten.

  2. Klicken Sie auf dem Karteireiter Adresse › Zusätzliche Adressen auf Hinzufügen.

  3. Geben Sie die IPv4-Adresskennung, die IP-Adresse und die Netzmaske ein. Nehmen Sie den Schnittstellennamen nicht in den Aliasnamen auf.

  4. Zum Aktivieren der Konfiguration bestätigen Sie die Einstellungen.

19.4.1.2.3 Ändern des Gerätenamens und der Udev-Regeln
 

Der Gerätename der Netzwerkkarte kann während des laufenden Betriebs geändert werden. Es kann auch festgelegt werden, ob udev die Netzwerkkarte über die Hardware-Adresse (MAC) oder die Bus-ID erkennen soll. Die zweite Option ist bei großen Servern vorzuziehen, um den Hotplug-Austausch der Karten zu erleichtern. Mit YaST legen Sie diese Optionen wie folgt fest:

  1. Wählen Sie im YaST-Dialogfeld Netzwerkeinstellungen auf dem Karteireiter Übersicht in der Liste der erkannten Karten eine Netzwerkkarte aus, und klicken Sie auf Bearbeiten.

  2. Öffnen Sie den Karteireiter Allgemein. Der aktuelle Gerätename wird unter Udev-Regeln angezeigt. Klicken Sie auf Ändern.

  3. Wählen Sie aus, ob udev die Karte über die MAC-Adresse oder die Bus-ID erkennen soll. Die aktuelle MAC-Adresse und Bus-ID der Karte werden im Dialogfeld angezeigt.

  4. Aktivieren Sie zum Ändern des Gerätenamens die Option Gerätenamen ändern und bearbeiten Sie den Namen.

  5. Zum Aktivieren der Konfiguration bestätigen Sie die Einstellungen.

19.4.1.2.4 Ändern des Kernel-Treibers für Netzwerkkarten
 

Für einige Netzwerkkarten sind eventuell verschiedene Kernel-Treiber verfügbar. Wenn die Karte bereits konfiguriert ist, ermöglicht YaST die Auswahl eines zu verwendenden Kernel-Treibers in einer Liste verfügbarer Treiber. Es ist auch möglich, Optionen für den Kernel-Treiber anzugeben. Mit YaST legen Sie diese Optionen wie folgt fest:

  1. Wählen Sie im YaST-Modul Netzwerkeinstellungen auf dem Karteireiter Übersicht in der Liste der erkannten Karten eine Netzwerkkarte aus, und klicken Sie auf Bearbeiten.

  2. Öffnen Sie den Karteireiter Hardware.

  3. Wählen Sie den zu verwendenden Kernel-Treiber unter Modulname aus. Geben Sie die entsprechenden Optionen für den ausgewählten Treiber unter Optionen im Format = =WERT ein. Wenn mehrere Optionen verwendet werden, sollten sie durch Leerzeichen getrennt sein.

  4. Zum Aktivieren der Konfiguration bestätigen Sie die Einstellungen.

19.4.1.2.5 Aktivieren des Netzwerkgeräts
 

Wenn Sie die Methode mit wicked verwenden, können Sie Ihr Gerät so konfigurieren, dass es wahlweise beim Systemstart, beim Anschließen des Kabels, beim Erkennen der Karte, manuell oder nie startet. Wenn Sie den Gerätestart ändern möchten, gehen Sie wie folgt vor:

  1. Wählen Sie in YaST unter System › Netzwerkeinstellungen in der Liste der erkannten Karten eine Netzwerkkarte aus und klicken Sie auf Bearbeiten.

  2. In der Karteireiter Allgemein wählen Sie den gewünschten Eintrag unter Geräte-Aktivierung.

    Wählen Sie Beim Systemstart, um das Gerät beim Booten des Systems zu starten. Wenn Bei Kabelanschluss aktiviert ist, wird die Schnittstelle auf physikalische Netzwerkverbindungen überwacht. Wenn Falls hot-plugged aktiviert ist, wird die Schnittstelle festgelegt, wenn sie verfügbar ist. Dies gleicht der Option Bei Systemstart, führt jedoch nicht zu einem Fehler beim Systemstart, wenn die Schnittstelle nicht vorhanden ist. Wählen Sie Manuell, wenn Sie die Schnittstelle manuell mit ifup steuern möchten. Wählen Sie Nie, wenn das Gerät nicht gestartet werden soll. Bei NFSroot verhält sich ähnlich wie Beim Systemstart, allerdings fährt der Befehl systemctl stop network die Schnittstelle bei dieser Einstellung nicht herunter; der network-Dienst wirkt sich auch auf den wicked-Dienst aus, sofern wicked aktiv ist. Diese Einstellung empfiehlt sich bei einem NFS- oder iSCSI-root-Dateisystem.

  3. Zum Aktivieren der Konfiguration bestätigen Sie die Einstellungen.

Tipp
Tipp: NFS als root-Dateisystem

Auf (festplattenlosen) Systemen, in denen die Stammpartition über das Netzwerk als NFS-Freigabe eingehängt ist, müssen Sie beim Konfigurieren des Netzwerkgeräts, über das die NFS-Freigabe erreichbar ist, besonders vorsichtig vorgehen.

Wenn Sie das System herunterfahren oder neu booten, werden in der standardmäßigen Reihenfolge zunächst die Netzwerkverbindungen deaktiviert und anschließend die Stammpartition ausgehängt. Bei einem NFS-root kann dies zu Problemen führen: Die Stammpartition kann nicht fehlerfrei ausgehängt werden, da die Netzwerkverbindung zur NFS-Freigabe schon nicht mehr aktiviert ist. Damit das System nicht das relevante Netzwerkgerät deaktiviert, öffnen Sie die Registerkarte gemäß Abschnitt 19.4.1.2.5, „Aktivieren des Netzwerkgeräts“ und wählen Sie unter Geräteaktivierung die Option Bei NFSroot.

19.4.1.2.6 Einrichten der Größe der maximalen Transfereinheit
 

Sie können eine maximale Transfereinheit (MTU) für die Schnittstelle festlegen. MTU bezieht sich auf die größte zulässige Paketgröße in Byte. Eine größere MTU bringt eine höhere Bandbreiteneffizienz. Große Pakete können jedoch eine langsame Schnittstelle für einige Zeit belegen und die Verzögerung für nachfolgende Pakete vergrößern.

  1. Wählen Sie in YaST unter System › Netzwerkeinstellungen in der Liste der erkannten Karten eine Netzwerkkarte aus und klicken Sie auf Bearbeiten.

  2. Wählen Sie im Karteireiter Allgemein den gewünschten Eintrag aus der Liste Set MTU (MTU festlegen).

  3. Zum Aktivieren der Konfiguration bestätigen Sie die Einstellungen.

19.4.1.2.7 Multifunktionale PCIe-Geräte
 

Multifunktionale Geräte, die LAN, iSCSI und FCoE unterstützen, werden unterstützt. Mit dem YaST FCoE-Client (yast2 fcoe-client) werden die privaten Flags in zusätzlichen Spalten angezeigt, um dem Benutzer zu erlauben, das für FCoE vorgesehene Gerät auszuwählen. Mit dem YaST-Netzwerkmodul (yast2 lan) werden „Geräte, die nur als Speicher dienen“, von der Netzwerkkonfiguration ausgeschlossen.

Weitere Informationen zu FCoE erhalten Sie im Book “Storage Administration Guide”, Chapter 16 “Fibre Channel storage over Ethernet networks: FCoE”, Section 16.3 “Managing FCoE services with YaST”.

19.4.1.2.8 InfiniBand-Konfiguration für IPoIB (IP-over-InfiniBand)
 

  1. Wählen Sie in YaST unter System › Netzwerkeinstellungen das InfiniBand-Gerät aus und klicken Sie auf Bearbeiten.

  2. Wählen Sie auf dem Karteireiter Allgemein einen der IPoIB-Modi (IP-over-InfiniBand) aus: Verbunden (Standard) oder Datagramm.

  3. Zum Aktivieren der Konfiguration bestätigen Sie die Einstellungen.

Weitere Informationen zu InfiniBand finden Sie in der Datei /usr/src/linux/Documentation/infiniband/ipoib.txt.

19.4.1.2.9 Konfigurieren der Firewall
 

Sie müssen nicht die genaue Firewall-Konfiguration durchführen, wie im Book “Security and Hardening Guide”, Chapter 23 “Masquerading and firewalls”, Section 23.4 “firewalld” beschrieben. Sie können die grundlegende Firewall-Konfiguration für Ihr Gerät als Teil der Gerätekonfiguration festlegen. Führen Sie dazu die folgenden Schritte aus:

  1. Öffnen Sie das YaST-Modul System › Netzwerkeinstellungen. Wählen Sie im Karteireiter Übersicht eine Karte aus der Liste erkannter Karten und klicken Sie auf Bearbeiten.

  2. Öffnen Sie den Karteireiter Allgemein des Dialogfelds Netzwerkeinstellungen.

  3. Legen Sie die Firewall-Zone fest, der Ihre Schnittstelle zugewiesen werden soll. Folgende Optionen sind verfügbar:

    Firewall deaktiviert

    Diese Option ist nur verfügbar, wenn die Firewall deaktiviert ist und nicht ausgeführt wird. Verwenden Sie diese Option nur, wenn Ihr Computer Teil eines größeren Netzwerks ist, das von einer äußeren Firewall geschützt wird.

    Automatisches Zuweisen von Zonen

    Diese Option ist nur verfügbar, wenn die Firewall aktiviert ist. Die Firewall wird ausgeführt und die Schnittstelle wird automatisch einer Firewall-Zone zugewiesen. Die Zone, die das Stichwort Beliebig enthält, oder die externe Zone wird für solch eine Schnittstelle verwendet.

    Interne Zone (ungeschützt)

    Die Firewall wird ausgeführt, aber es gibt keine Regeln, die diese Schnittstelle schützen. Verwenden Sie diese Option, wenn Ihr Computer Teil eines größeren Netzwerks ist, das von einer äußeren Firewall geschützt wird. Sie ist auch nützlich für die Schnittstellen, die mit dem internen Netzwerk verbunden sind,wenn der Computer über mehrere Netzwerkschnittstellen verfügt.

    Demilitarisierte Zone

    Eine demilitarisierte Zone ist eine zusätzliche Verteidigungslinie zwischen einem internen Netzwerk und dem (feindlichen) Internet. Die dieser Zone zugewiesenen Hosts können vom internen Netzwerk und vom Internet erreicht werden, können jedoch nicht auf das interne Netzwerk zugreifen.

    Externe Zone

    Die Firewall wird an dieser Schnittstelle ausgeführt und schützt sie vollständig vor anderem (möglicherweise feindlichem) Netzwerkverkehr. Dies ist die Standardoption.

  4. Zum Aktivieren der Konfiguration bestätigen Sie die Einstellungen.

19.4.1.3 Konfigurieren einer unerkannten Netzwerkkarte

 

Wenn eine Netzwerkkarte nicht ordnungsgemäß erkannt wird, so wird diese Karte nicht in der Liste der erkannten Karten aufgeführt. Wenn Sie sich nicht sicher sind, ob Ihr System über einen Treiber für die Karte verfügt, können Sie sie manuell konfigurieren. Sie können auch spezielle Netzwerkgerätetypen konfigurieren, z. B. Bridge, Bond, TUN oder TAP. So konfigurieren Sie eine nicht erkannte Netzwerkkarte (oder ein spezielles Gerät):

  1. Klicken Sie im Dialogfeld System › Netzwerkeinstellungen ›  Übersicht in YaST auf Hinzufügen.

  2. Legen Sie den Gerätetyp der Schnittstelle im Dialogfeld Hardware mit Hilfe der verfügbaren Optionen fest und geben Sie einen Konfigurationsnamen ein. Wenn es sich bei der Netzwerkkarte um ein USB-Gerät handelt, aktivieren Sie das entsprechende Kontrollkästchen und schließen Sie das Dialogfeld durch Klicken auf Weiter. Ansonsten können Sie den Kernel Modulname definieren, der für die Karte verwendet wird, sowie gegebenenfalls dessen Optionen.

    Unter Ethtool-Optionen können Sie die von ifup für die Schnittstelle verwendeten Ethtool-Optionen einstellen. Weitere Informationen zu den verfügbaren Optionen finden Sie auf der man-Seite ethtool.

    Wenn die Optionszeichenkette mit einem - beginnt (z. B. -K SCHNITTSTELLENNAME rx on), wird das zweite Wort der Zeichenkette durch den aktuellen Schnittstellennamen ersetzt. In allen andern Fällen (z. B. autoneg off speed 10) setzt ifup dem Eintrag die Zeichenfolge -s SCHNITTSTELLENNAME voran.

  3. Klicken Sie auf Weiter.

  4. Konfigurieren Sie die benötigten Optionen wie die IP-Adresse, die Geräteaktivierung oder die Firewall-Zone für die Schnittstelle auf den Karteireitern Allgemein, Adresse und Hardware. Weitere Informationen zu den Konfigurationsoptionen finden Sie in Abschnitt 19.4.1.2, „Ändern der Konfiguration einer Netzwerkkarte“.

  5. Wenn Sie für den Gerätetyp der Schnittstelle die Option Drahtlos gewählt haben, konfigurieren Sie im nächsten Dialogfeld die drahtlose Verbindung.

  6. Zum Aktivieren der neuen Netzwerkkonfiguration bestätigen Sie die Einstellungen.

19.4.1.4 Konfigurieren des Hostnamens und des DNS

 

Wenn Sie die Netzwerkkonfiguration während der Installation noch nicht geändert haben und die Ethernet-Karte bereits verfügbar war, wurde automatisch ein Hostname für Ihren Rechner erstellt, und DHCP wurde aktiviert. Dasselbe gilt für die Namensservicedaten, die Ihr Host für die Integration in eine Netzwerkumgebung benötigt. Wenn DHCP für eine Konfiguration der Netzwerkadresse verwendet wird, wird die Liste der Domain Name Server automatisch mit den entsprechenden Daten versorgt. Falls eine statische Konfiguration vorgezogen wird, legen Sie diese Werte manuell fest.

Wenn Sie den Namen Ihres Computers und die Namenserver-Suchliste ändern möchten, gehen Sie wie folgt vor:

  1. Wechseln Sie zum Karteireiter Netzwerkeinstellungen ›  Hostname/DNS im Modul System in YaST.

  2. Geben Sie den Hostnamen ein. Der Hostname ist global und gilt für alle eingerichteten Netzwerkschnittstellen.

    Wenn Sie zum Abrufen einer IP-Adresse DHCP verwenden, wird der Hostname Ihres Computers automatisch durch den DHCP-Server festgelegt. Sie sollten dieses Verhalten deaktivieren, wenn Sie Verbindungen zu verschiedenen Netzwerken aufbauen, da Sie verschiedene Hostnamen zuweisen können und das Ändern des Hostnamens beim Ausführen den grafischen Desktop verwirren kann. Zum Deaktivieren von DHCP, damit Sie eine IP-Adresse erhalten, deaktivieren Sie Hostnamen über DHCP ändern.

  3. Legen Sie unter DNS-Konfiguration ändern fest, wie die DNS-Konfiguration (Nameserver, Suchliste, Inhalt der Datei /run/netconfig/resolv.conf) geändert wird.

    Wenn die Option Standardrichtlinie verwenden ausgewählt ist, wird die Konfiguration vom Skript netconfig verwaltet, das die statisch definierten Daten (mit YaST oder in den Konfigurationsdateien) mit dynamisch bezogenen Daten (vom DHCP-Client oder NetworkManager) zusammenführt. Diese Standardrichtlinie ist in der Regel ausreichend.

    Wenn die Option Nur manuell ausgewählt ist, darf netconfig die Datei /run/netconfig/resolv.conf nicht ändern. Jedoch kann diese Datei manuell bearbeitet werden.

    Wenn die Option Benutzerdefinierte Richtlinie ausgewählt ist, muss eine Zeichenkette für die benutzerdefinierte Richtlinienregel angegeben werden, welche die Zusammenführungsrichtlinie definiert. Die Zeichenkette besteht aus einer durch Kommas getrennten Liste mit Schnittstellennamen, die als gültige Quelle für Einstellungen betrachtet werden. Mit Ausnahme vollständiger Schnittstellennamen sind auch grundlegende Platzhalter zulässig, die mit mehreren Schnittstellen übereinstimmen. Beispiel: eth* ppp? richtet sich zuerst an alle eth- und dann an alle ppp0-ppp9-Schnittstellen. Es gibt zwei spezielle Richtlinienwerte, die angeben, wie die statischen Einstellungen angewendet werden, die in der Datei /etc/sysconfig/network/config definiert sind:

    STATIC

    Die statischen Einstellungen müssen mit den dynamischen Einstellungen zusammengeführt werden.

    STATIC_FALLBACK

    Die statischen Einstellungen werden nur verwendet, wenn keine dynamische Konfiguration verfügbar ist.

    Weitere Informationen finden Sie auf der man-Seite zu netconfig(8) (man 8 netconfig).

  4. Geben Sie die Namenserver ein und füllen Sie die Domänensuchliste aus. Nameserver müssen in der IP-Adresse angegeben werden (z. B. 192.168.1.116), nicht im Hostnamen. Namen, die im Karteireiter Domänensuche angegeben werden, sind Namen zum Auflösen von Hostnamen ohne angegebene Domäne. Wenn mehr als eine Suchdomäne verwendet wird, müssen die Domänen durch Kommas oder Leerzeichen getrennt werden.

  5. Zum Aktivieren der Konfiguration bestätigen Sie die Einstellungen.

Der Hostname kann auch mit YaST über die Kommandozeile bearbeitet werden. Die Änderungen in YaST treten sofort in Kraft (im Gegensatz zur manuellen Bearbeitung der Datei /etc/HOSTNAME). Zum Ändern des Hostnamens führen Sie das folgende Kommando aus: 

root # yast dns edit hostname=HOSTNAME

Zum Ändern der Namenserver führen Sie die folgenden Kommandos aus: 

root # yast dns edit nameserver1=192.168.1.116
root # yast dns edit nameserver2=192.168.1.117
root # yast dns edit nameserver3=192.168.1.118

19.4.1.5 Konfigurieren des Routings

 

Damit Ihre Maschine mit anderen Maschinen und Netzwerken kommuniziert, müssen Routing-Daten festgelegt werden. Dann nimmt der Netzwerkverkehr den korrekten Weg. Wird DHCP verwendet, werden diese Daten automatisch angegeben. Wird eine statische Konfiguration verwendet, müssen Sie die Daten manuell angeben.

  1. Navigieren Sie in YaST zu Netzwerkeinstellungen ›  Routing.

  2. Geben Sie die IP-Adresse für das Standard-Gateway ein (gegebenenfalls IPv4 und IPv6). Das Standard-Gateway stimmt mit jedem möglichen Ziel überein. Falls jedoch ein Eintrag in der Routingtabelle vorliegt, der mit der angegebenen Adresse übereinstimmt, wird dieser Eintrag anstelle der Standardroute über das Standard-Gateway verwendet.

  3. In der Routing-Tabelle können weitere Einträge vorgenommen werden. Geben Sie die IP-Adresse für das Ziel-Netzwerk, die IP-Adresse des Gateways und die Netzmaske ein. Wählen Sie das Gerät aus, durch das der Datenverkehr zum definierten Netzwerk geroutet wird (das Minuszeichen steht für ein beliebiges Gerät). Verwenden Sie das Minuszeichen -, um diese Werte frei zu lassen. Verwenden Sie default im Feld Ziel, um in der Tabelle ein Standard-Gateway einzugeben.

    Anmerkung
    Anmerkung: Priorisieren einer Route

    Wenn mehrere Standardrouten verwendet werden, kann die Metrik-Option verwendet werden, um festzulegen, welche Route eine höhere Priorität hat. Geben Sie zur Angabe der Metrik-Option - Metrik NUMMER unter Optionen ein. Die Route mit der höchsten Metrik wird als Standard verwendet. Wenn das Netzwerkgerät getrennt wird, wird seine Route entfernt und die nächste verwendet.

  4. Wenn das System ein Router ist, aktivieren Sie bei Bedarf die Optionen IPv4-Weiterleitung und IPv6-Weiterleitung in den Netzwerkeinstellungen.

  5. Zum Aktivieren der Konfiguration bestätigen Sie die Einstellungen.

19.4.2 IBM Z: Konfigurieren von Netzwerkgeräten

 

SUSE Linux Enterprise Server für IBM Z unterstützt mehrere Typen von Netzwerkschnittstellen. YaST kann zur Konfiguration dieser Schnittstellen verwendet werden.

19.4.2.1 Das qeth-hsi-Gerät

 

Wenn dem installierten System eine qeth-hsi-Schnittstelle (Hipersockets) hinzugefügt werden soll, starten Sie in YaST das Modul System › Netzwerkeinstellungen. Wählen Sie eines der Geräte mit der Bezeichnung Hipersocket aus, um es als READ-Geräteadresse zu verwenden, und klicken Sie auf Bearbeiten. Geben Sie die Gerätenummern für den Lese-, den Schreib- und den Steuerkanal ein (Beispiel für Gerätenummernformat: 0.0.0800). Klicken Sie anschließend auf „Weiter“. Im Dialogfeld Konfiguration der Netzwerkadresse geben Sie die IP-Adresse und die Netzmaske für die neue Schnittstelle an. Klicken Sie danach auf Weiter und OK, um die Netzwerkkonfiguration zu beenden.

19.4.2.2 Das qeth-ethernet-Gerät

 

Wenn Sie dem installierten System eine qeth-ethernet-Schnittstelle (IBM OSA Express Ethernet Card) hinzufügen möchten, starten Sie in YaST das Modul System › Netzwerkeinstellungen. Wählen Sie eines der Geräte mit der Bezeichnung IBM OSA Express Ethernet Card aus, um es als READ-Geräteadresse zu verwenden, und klicken Sie auf Bearbeiten. Geben Sie eine Gerätenummer für den Lese-, den Schreib- und den Steuerkanal ein (Beispiel für Gerätenummernformat: 0.0.0700). Geben Sie den erforderlichen Portnamen, die Portnummer (falls zutreffend) und einige weitere Optionen, Ihre IP-Adresse sowie eine geeignete Netzmaske ein. Beenden Sie die Netzwerkkonfiguration mit Weiter und OK.

19.4.2.3 Das ctc-Gerät

 

Wenn Sie dem installierten System eine ctc-Schnittstelle (IBM Parallel CTC Adapter) hinzufügen möchten, starten Sie in YaST das Modul System › Netzwerkeinstellungen. Wählen Sie eines der Geräte mit der Bezeichnung IBM Parallel CTC Adapter aus, um es als Lesekanal zu verwenden und klicken Sie auf Konfigurieren. Wählen Sie die Geräteeinstellungen für Ihre Geräte aus (gewöhnlich ist das Kompatibilitätsmodus). Geben Sie Ihre IP-Adresse und die IP-Adresse des entfernten Partners ein. Passen Sie gegebenenfalls die MTU-Größe mit Erweitert › Besondere Einstellungen an. Beenden Sie die Netzwerkkonfiguration mit Weiter und OK.

Warnung
Warnung: Ende der CTC-Unterstützung

Die Nutzung dieser Schnittstelle ist veraltet. Diese Schnittstelle wird in künftigen Versionen von SUSE Linux Enterprise Server nicht mehr unterstützt.

19.4.2.4 Das lcs-Gerät

 

Wenn Sie dem installierten System eine lcs-Schnittstelle (IBM OSA-2 Adapter) hinzufügen möchten, starten Sie in YaST das Modul System › Netzwerkeinstellungen. Wählen Sie eines der Geräte mit der Bezeichnung IBM OSA-2 Adapter und klicken Sie auf Konfigurieren. Geben Sie die erforderliche Portnummer, einige weitere Optionen, Ihre IP-Adresse sowie eine geeignete Netzmaske ein. Beenden Sie die Netzwerkkonfiguration mit Weiter und OK.

19.4.2.5 Das IUCV-Gerät

 

Wenn Sie dem installierten System eine iucv-Schnittstelle (IUCV) hinzufügen möchten, starten Sie in YaST das Modul System › Netzwerkeinstellungen. Wählen Sie eines der Geräte mit der Bezeichnung IUCV und klicken Sie auf Bearbeiten. YaST fordert Sie auf, den Namen Ihres IUCV-Partners (Peer) einzugeben. Geben Sie den Namen ein (beachten Sie die Groß-/Kleinschreibung) und wählen Sie Weiter. Geben Sie sowohl Ihre IP-Adresse als auch die Entfernte IP-Adresse Ihres Partners ein. Stellen Sie bei Bedarf die MTU-Größe über die Option MTU festlegen im Karteireiter Allgemein ein. Beenden Sie die Netzwerkkonfiguration mit Weiter und OK.

Warnung
Warnung: Ende der IUCV-Unterstützung

Die Nutzung dieser Schnittstelle ist veraltet. Diese Schnittstelle wird in künftigen Versionen von SUSE Linux Enterprise Server nicht mehr unterstützt.

19.5 Manuelle Netzwerkkonfiguration

 

Die manuelle Konfiguration der Netzwerksoftware sollte die letzte Alternative sein. Wir empfehlen, YaST zu benutzen. Die folgenden Hintergrundinformationen zur Netzwerkkonfiguration können Ihnen jedoch auch bei der Arbeit mit YaST behilflich sein.

19.5.1 Die wicked-Netzwerkkonfiguration

 

Das Werkzeug und die Bibilothek mit der Bezeichnung wicked bilden ein neues Framework für die Netzwerkkonfiguration.

Eine der Herausforderungen der traditionellen Netzwerkschnittstellenverwaltung liegt darin, dass verschiedene Netzwerkverwaltungsschichten in einem einzigen Skript oder maximal zwei Skripten vermischt werden. Diese Skripte interagieren auf nicht eindeutig definierte Weise miteinander. So entstehen unvorhersehbare Probleme, undurchsichtige Einschränkungen und Konventionen und vieles mehr. Verschiedene Schichten mit speziellen Kniffen für unterschiedliche Szenarien machen die Wartungsarbeit nicht gerade leichter. Die verwendeten Adresskonfigurationsprotokolle werden über Daemons wie dhcpcd implementiert, die eher notdürftig mit der restlichen Infrastruktur zusammenarbeiten. Die Schnittstellennamen werden anhand von merkwürdigen Schemata, die eine erhebliche udev-Unterstützung erfordern, dauerhaft identifiziert.

wicked verfolgt einen anderen Ansatz, bei dem das Problem nach mehreren Gesichtspunkten zerlegt wird. Die einzelnen Verfahren dabei sind nicht völlig neuartig, doch eröffnen die Ideen und Konzepte aus anderen Projekten unterm Strich eine bessere Gesamtlösung.

Ein mögliches Verfahren ist das Client/Server-Modell. wicked ist hiermit in der Lage, standardisierte Funktionen für Bereiche wie die Adresskonfiguration zu definieren, die gut in das Framework als Ganzes eingebunden sind. Über eine bestimmte Adresskonfiguration kann der Administrator beispielsweise festlegen, dass eine Schnittstelle mit DHCP oder IPv4 zeroconf konfiguriert werden soll. In diesem Fall holt der Adresskonfigurationsdienst lediglich das Lease vom Server ein und übergibt es an den wicked-Serverprozess, mit dem die Anforderungen Adressen und Routen installiert werden.

Das zweite Verfahren zur Problemzerlegung ist die Erzwingung der Schichten. Für alle Arten von Netzwerkschnittstellen kann ein dbus-Service definiert werden, mit dem die Geräteschicht der Netzwerkschnittstelle konfiguriert wird – ein VLAN, eine Bridge, ein Bonding oder ein paravirtualisiertes Gerät. Häufig verwendete Funktionen, z. B. die Adresskonfiguration, wird über gemeinsame Services implementiert, die sich in einer Schicht oberhalb dieser gerätespezifischen Services befinden, ohne dass sie eigens implementiert werden müssen.

Im wicked-Framework werden diese beiden Aspekte durch eine Vielzahl von dbus-Services zusammengeführt, die den Netzwerkschnittstellen je nach ihrem Typ zugeordnet werden. Im Folgenden finden Sie einen kurzen Überblick über die aktuelle Objekthierarchie in wicked.

Die Netzwerkschnittstelle wird jeweils als untergeordnetes Objekt von /org/opensuse/Network/Interfaces dargestellt. Die Bezeichnung des untergeordneten Objekts ergibt sich aus dem zugehörigen Wert für ifindex. Die Loopback-Schnittstelle (in der Regel ifindex 1) ist beispielsweise /org/opensuse/Network/Interfaces/1, und die erste registrierte Ethernet-Schnittstelle ist /org/opensuse/Network/Interfaces/2.

Jede Netzwerkschnittstelle ist mit einer „Klasse“ verknüpft, mit der die unterstützten dbus-Schnittstellen ausgewählt werden. Standardmäßig gehören alle Netzwerkschnittstellen zur Klasse netif, und wicked ordnet automatisch alle Schnittstellen zu, die mit dieser Klasse kompatibel sind. In der aktuellen Implementierung gilt dies für die folgenden Schnittstellen:

org.opensuse.Network.Interface

Allgemeine Funktionen für Netzwerkschnittstellen, z. B. Herstellen oder Beenden der Verbindung, Zuweisen einer MTU und vieles mehr.

org.opensuse.Network.Addrconf.ipv4.dhcp, org.opensuse.Network.Addrconf.ipv6.dhcp, org.opensuse.Network.Addrconf.ipv4.auto

Adresskonfigurationsservices für DHCP, IPv4 zeroconf usw.

Darüber hinaus können die Netzwerkschnittstellen bestimmte Konfigurationsmechanismen erfordern oder anbieten. Bei einem Ethernet-Gerät benötigen Sie beispielsweise Funktionen zum Steuern der Verbindungsgeschwindigkeit, zum Abgeben der Prüfsummenberechnung usw. Ethernet-Geräte gehören daher zu einer eigenen Klasse (netif-ethernet), die wiederum eine Subklasse von netif ist. Aus diesem Grund umfassen die dbus-Schnittstellen, die mit einer Ethernet-Schnittstelle verknüpft sind, alle oben aufgeführten Services und zusätzlich den Service org.opensuse.Network.Ethernet, der ausschließlich für Objekte der Klasse netif-ethernet verfügbar ist.

Ebenso bestehen Klassen für Schnittstellentypen wie Bridges, VLANs, Bonds oder InfiniBands.

Wie interagieren Sie mit einer Schnittstelle wie VLAN (die im Grunde genommen eine virtuelle Netzwerkschnittstelle über einem Ethernet-Gerät bildet), die erst noch erstellt werden muss? Hierfür werden Factory-Schnittstellen in wicked definiert, beispielsweise org.opensuse.Network.VLAN.Factory. Diese Factory-Schnittstellen bieten nur eine einzige Funktion, mit der Sie eine Schnittstelle mit dem gewünschten Typ erstellen. Die Factory-Schnittstellen sind dem Listenknoten /org/opensuse/Network/Interfaces zugeordnet.

19.5.1.1 wicked-Architektur und -Funktionen

 

Der wicked-Dienst umfasst mehrere Teile, wie in Abbildung 19.4, „wicked-Architektur“ dargestellt.

wicked-Architektur
Abbildung 19.4: wicked-Architektur
 

wicked unterstützt derzeit Folgendes:

  • Konfigurationsdatei-Back-Ends zum Analysieren von /etc/sysconfig/network-Dateien im SUSE-Format.

  • Internes Konfigurationsdatei-Back-End zur Darstellung der Netzwerkschnittstellenkonfiguration in XML.

  • Hoch- und Herunterfahren für „normale“ Netzwerkschnittstellen wie Ethernet oder InfiniBand, außerdem für VLAN-, Bridge-, Bonds-, TUN-, TAP-, Dummy-, MacVLan-, MacVTap-, HSI-, QETH- und IUCV-Geräte sowie für drahtlose Geräte (derzeit auf nur ein WPA-PSK-/EAP-Netzwerk beschränkt).

  • Integrierter DHCPv4-Client und integrierter DHCPv6-Client.

  • Der nanny-Daemon (standardmäßig aktiviert) fährt konfigurierte Schnittstellen automatisch hoch, wenn das Gerät verfügbar ist (Schnittstellen-Hotplugging), und richtet die IP-Konfiguration ein, wenn eine Verbindung (Träger) erkannt wird. Weitere Informationen zu diesem Thema finden Sie unter dem Stichwort Abschnitt 19.5.1.3, „Nanny“.

  • wicked wurde als eine Gruppe von DBus-Diensten implementiert, die mit systemd integriert sind. Daher sind die üblichen systemctl-Kommandos auch für wicked gültig.

19.5.1.2 Verwendung von wicked

 

Bei SUSE Linux Enterprise wird wicked standardmäßig ausgeführt. Mit dem folgenden Befehl stellen Sie fest, welche Elemente derzeit aktiviert sind und ob sie ausgeführt werden: 

systemctl status network

Wenn wicked aktiviert ist, erhalten Sie die folgende Ausgabe (Beispiel): 

wicked.service - wicked managed network interfaces
    Loaded: loaded (/usr/lib/systemd/system/wicked.service; enabled)
    ...

Falls andere Elemente ausgeführt werden (z. B. NetworkManager) und Sie zu wicked wechseln möchten, halten Sie zunächst die ausgeführten Elemente an und aktivieren Sie dann wicked: 

systemctl is-active network && \
systemctl stop      network
systemctl enable --force wicked

Beim nächsten Booten werden damit die wicked-Services aktiviert, die Alias-Verknüpfung von network.service und wicked.service wird erstellt, und das Netzwerk wird gestartet.

Starten des Serverprozesses: 

systemctl start wickedd

Hiermit werden sowohl wicked (der Hauptserver) und die zugehörigen Supplicants gestartet: 

/usr/lib/wicked/bin/wickedd-auto4 --systemd --foreground
/usr/lib/wicked/bin/wickedd-dhcp4 --systemd --foreground
/usr/lib/wicked/bin/wickedd-dhcp6 --systemd --foreground
/usr/sbin/wickedd --systemd --foreground
/usr/sbin/wickedd-nanny --systemd --foreground

Fahren Sie dann das Netzwerk hoch: 

systemctl start wicked

Alternativ verwenden Sie das network-Alias: 

systemctl start network

Bei diesen Kommandos werden die standardmäßigen oder die systemeigenen Konfigurationsquellen verwendet, die in /etc/wicked/client.xml definiert sind.

Zum Aktivieren der Fehlersuche legen Sie WICKED_DEBUG_ in /etc/sysconfig/network/config fest, beispielsweise: 

WICKED_DEBUG="all"

Sollen einige Aspekte ausgelassen werden: 

WICKED_DEBUG="all,-dbus,-objectmodel,-xpath,-xml"

Mit dem Clientprogramm rufen Sie die Schnittstellendaten für alle Schnittstellen bzw. für die mit IFNAME angegebenen Schnittstellen ab: 

wicked show all
wicked show IFNAME

Als XML-Ausgabe: 

wicked show-xml all
wicked show-xml IFNAME

Starten einer bestimmten Schnittstelle: 

wicked ifup eth0
wicked ifup wlan0
...

Da keine Konfigurationsquelle angegeben ist, prüft der wicked-Client die Standard-Konfigurationsquellen, die in /etc/wicked/client.xml definiert sind:

  1. firmware: iSCSI Boot Firmware Table (iBFT)

  2. compat: ifcfg-Dateien; aus Kompatibilitätsgründen implementiert

Alle Informationen, die wicked aus diesen Quellen für eine bestimmte Schnittstelle erhält, werden übernommen und angewendet. Die geplante Reihenfolge lautet firmware, dann compat. Diese Reihenfolge wird unter Umständen demnächst geändert.

Weitere Informationen finden Sie auf der man-Seite zu wicked.

19.5.1.3 Nanny

 

Der ereignis- und richtliniengestützte Daemon nanny ist für asynchrone oder unverlangte Szenarien zuständig, beispielsweise für das Hotplugging von Geräten. Der nanny-Daemon hilft also dabei, verzögerte oder vorübergehend ausgefallene Dienste zu starten oder neu zu starten. Nanny überwacht Veränderungen an den Geräten und Verknüpfungen und bindet neue Geräte gemäß dem aktuellen Richtliniensatz ein. Nanny fährt aufgrund von angegebenen Einschränkungen zur Zeitüberschreitung mit dem Einrichten fort, auch wenn ifup bereits beendet ist.

Standardmäßig ist der nanny-Daemon im System aktiv. Er wird in der Konfigurationsdatei /etc/wicked/common.xml aktiviert: 

<config>
  ...
  <use-nanny>true</use-nanny>
</config>

Durch diese Einstellung wenden ifup und ifreload eine Richtlinie mit der effektiven Konfiguration auf den Daemon an; anschließend führt nanny die Konfiguration von wicked aus und sorgt so für die Hotplug-Unterstützung. Der Daemon wartet im Hintergrund auf Ereignisse oder Änderungen (beispielsweise auf neue Geräte oder auf die Erkennung eines Trägers).

19.5.1.4 Starten von mehreren Schnittstellen

 

Bei Bonds und Bridges ist es unter Umständen sinnvoll, die gesamte Gerätetopologie in einer einzigen Datei zu definieren (ifcfg-bondX) und alle Geräte in einem Arbeitsgang hochzufahren. Mit wicked können Sie dann die Schnittstellennamen der obersten Ebene (für den Bridge oder den Bond) angeben und so die gesamte Konfiguration hochfahren: 

wicked ifup br0

Dieser Befehl richtet automatisch die Bridge und ihre Abhängigkeiten in der richtigen Reihenfolge ein, ohne dass die Abhängigkeiten (Ports usw.) getrennt aufgeführt werden müssten.

So fahren Sie mehrere Schnittstellen mit einem einzigen Befehl hoch: 

wicked ifup bond0 br0 br1 br2

Oder auch alle Schnittstellen: 

wicked ifup all

19.5.1.5 Verwenden von Tunneln mit Wicked

 

Wenn Sie Tunnels mit Wicked verwenden müssen, wird TUNNEL_DEVICE hierfür verwendet. Die Option erlaubt es, einen optionalen Gerätenamen anzugeben, um den Tunnel an das Gerät zu binden. Die getunnelten Pakete werden nur über dieses Gerät geleitet.

Weitere Informationen erhalten Sie mit dem Kommando man 5 ifcfg-tunnel.

19.5.1.6 Einarbeiten von inkrementellen Änderungen

 

Bei wicked müssen Sie eine Schnittstelle zum Neukonfigurieren nicht vollständig herunterfahren (sofern dies nicht durch den Kernel erforderlich ist). Wenn Sie beispielsweise eine weitere IP-Adresse oder Route für eine statisch konfigurierte Netzwerkschnittstelle hinzufügen möchten, tragen Sie die IP-Adresse in die Schnittstellendefinition ein und führen Sie den „ifup“-Vorgang erneut aus. Der Server aktualisiert lediglich die geänderten Einstellungen. Dies gilt für Optionen auf Verbindungsebene (z. B. die MTU oder die MAC-Adresse des Geräts) sowie auf Netzwerkebene, beispielsweise die Adressen, Routen oder gar der Adresskonfigurationsmodus (z. B. bei der Umstellung einer statischen Konfiguration auf DHCP).

Bei virtuellen Schnittstellen, in denen mehrere physische Geräte miteinander verbunden werden (z. B. Bridges oder Bonds), ist die Vorgehensweise naturgemäß komplizierter. Bei Bond-Geräten können bestimmte Parameter nicht geändert werden, wenn das Gerät eingeschaltet ist. Ansonsten würde ein Fehler auftreten.

Als Alternative können Sie stattdessen untergeordnete Geräte des Bonds oder der Bridge hinzufügen oder entfernen oder auch die primäre Schnittstelle eines Bonds festlegen.

19.5.1.7 wicked-Erweiterungen: Adresskonfiguration

 

wicked lässt sich mithilfe von Shell-Skripten erweitern. Diese Erweiterungen können in der Datei config.xml definiert werden.

Derzeit werden mehrere Erweiterungsklassen unterstützt:

  • Verbindungskonfiguration: Skripte zum Einrichten der Verbindungsschicht eines Geräts gemäß der Konfiguration, die vom Client bereitgestellt wurde, sowie zum Entfernen dieser Schicht.

  • Adresskonfiguration: Skripte zum Verwalten der Konfiguration einer Geräteadresse. Die Adresskonfiguration und DHCP werden in der Regel von wicked selbst verwaltet, können jedoch auch in Form von Erweiterungen implementiert werden.

  • Firewall-Erweiterung: Mit diesen Skripten werden Firewall-Regeln angewendet.

Erweiterungen umfassen im Normalfall ein Start- und Stopp-Kommando, eine optionale „pid-Datei“ sowie eine Reihe von Umgebungsvariablen, die an das Skript übergeben werden.

In etc/server.xml finden Sie ein Beispiel für eine Firewall-Erweiterung: 

<dbus-service interface="org.opensuse.Network.Firewall">
 <action name="firewallUp"   command="/etc/wicked/extensions/firewall up"/>
 <action name="firewallDown" command="/etc/wicked/extensions/firewall down"/>

 <!-- default environment for all calls to this extension script -->
 <putenv name="WICKED_OBJECT_PATH" value="$object-path"/>
 <putenv name="WICKED_INTERFACE_NAME" value="$property:name"/>
 <putenv name="WICKED_INTERFACE_INDEX" value="$property:index"/>
</dbus-service>

Die Erweiterung wird an den Tag <dbus-service> angehängt und definiert auszuführende Kommandos für die Aktionen dieser Schnittstelle. In der Deklaration können außerdem Umgebungsvariablen, die an die Aktion übergeben werden sollen, definiert und initialisiert werden.

19.5.1.8 Wicked-Erweiterungen: Konfigurationsdateien

 

Auch die Arbeit mit Konfigurationsdateien kann mithilfe von Skripten erweitert werden. DNS-Aktualisierungen über Leases werden beispielsweise letztlich von dem Skript extensions/resolver verarbeitet, dessen Verhalten in server.xml konfiguriert ist: 

<system-updater name="resolver">
 <action name="backup" command="/etc/wicked/extensions/resolver backup"/>
 <action name="restore" command="/etc/wicked/extensions/resolver restore"/>
 <action name="install" command="/etc/wicked/extensions/resolver install"/>
 <action name="remove" command="/etc/wicked/extensions/resolver remove"/>
</system-updater>

Sobald eine Aktualisierung in wicked eingeht, wird das Lease durch die Systemaktualisierungsroutinen analysiert, und die entsprechenden Kommandos (backup, install usw.) im Auflöserskript werden aufgerufen. Hiermit werden wiederum die DNS-Einstellungen über /sbin/netconfig konfiguriert; als Fallback muss die Datei /run/netconfig/resolv.conf manuell geschrieben werden.

19.5.2 Konfigurationsdateien

 

Dieser Abschnitt bietet einen Überblick über die Netzwerkkonfigurationsdateien und erklärt ihren Zweck sowie das verwendete Format.

19.5.2.1 /etc/wicked/common.xml

 

Die Datei /etc/wicked/common.xml enthält allgemeine Definitionen, die von allen Anwendungen verwendet werden sollten. Sie wird von den anderen Konfigurationsdateien in diesem Verzeichnis als Quelle verwendet/eingeschlossen. Obwohl Sie diese Datei zum Aktivieren der Fehlerbehebung für alle wicked-Komponenten verwenden können, empfehlen wir, hierfür die Datei /etc/wicked/local.xml zu verwenden. Nach dem Anwenden von Wartungsaktualisierungen können Ihre Änderungen verloren gehen, da die Datei /etc/wicked/common.xml möglicherweise überschrieben wird. Die Datei /etc/wicked/common.xml enthält /etc/wicked/local.xml in der Standardinstallation, daher müssen Sie in der Regel /etc/wicked/common.xml nicht bearbeiten.

Falls Sie nanny deaktivieren möchten, indem Sie für <use-nanny> den Wert false festlegen, starten Sie den Dienst wickedd.service neu und führen Sie anschließend das folgende Kommando aus, um alle Konfigurationen und Richtlinien anzuwenden: 

tux > sudo wicked ifup all
Anmerkung
Anmerkung: Konfigurationsdateien

Die Programme wickedd, wicked oder nanny versuchen, die Datei /etc/wicked/common.xml zu lesen, wenn sie über keine eigene Konfigurationsdatei verfügen.

19.5.2.2 /etc/wicked/server.xml

 

Die Datei /etc/wicked/server.xml wird vom Serverprozess wickedd beim Starten gelesen. Die Datei speichert Erweiterungen zu der Datei /etc/wicked/common.xml. Zusätzlich konfiguriert diese Datei die Handhabung von Resolvern und den Empfang von Informationen von addrconf-Supplicants, z. B. DHCP.

Es wird empfohlen, erforderliche Änderungen an dieser Datei der separaten Datei /etc/wicked/server-local.xml hinzuzufügen. Diese wird von /etc/wicked/server.xml eingeschlossen. Durch Verwenden einer separaten Datei vermeiden Sie das Überschrieben Ihrer Änderungen bei Wartungsaktualisierungen.

19.5.2.3 /etc/wicked/client.xml

 

Die Datei /etc/wicked/client.xml wird vom Kommando wicked verwendet. Die Datei gibt den Speicherort eines Skripts an, der beim Ermitteln von Geräten, die von ibft verwaltet werden, verwendet wird. Außerdem konfiguriert die Datei die Speicherpositionen der Konfigurationen von Netzwerkschnittstellen.

Es wird empfohlen, erforderliche Änderungen an dieser Datei in der separaten Datei /etc/wicked/client-local.xml hinzuzufügen. Diese wird von /etc/wicked/server.xml eingeschlossen. Durch Verwenden einer separaten Datei vermeiden Sie das Überschrieben Ihrer Änderungen bei Wartungsaktualisierungen.

19.5.2.4 /etc/wicked/nanny.xml

 

Die Datei /etc/wicked/nanny.xml konfiguriert die Typen der Verbindungsschichten. Es wird empfohlen, spezielle Konfigurationen der separaten Datei /etc/wicked/nanny-local.xml hinzuzufügen, um den Verlust der Änderungen bei Wartungsaktualisierungen zu vermeiden.

19.5.2.5 /etc/sysconfig/network/ifcfg-*

 

Diese Dateien enthalten die herkömmlichen Konfigurationsdaten für Netzwerkschnittstellen.

Anmerkung
Anmerkung: wicked und ifcfg-*-Dateien

wicked liest diese Dateien, wenn Sie das Präfix compat: angeben. Gemäß der Standardkonfiguration von SUSE Linux Enterprise Server in /etc/wicked/client.xml berücksichtigt wicked diese Dateien noch vor den XML-Konfigurationsdateien in /etc/wicked/ifconfig.

Der Schalter --ifconfig wird überwiegend zu Testzwecken verwendet. Wenn dieser Schalter angegeben ist, werden die in /etc/wicked/ifconfig definierten standardmäßigen Konfigurationsquellen nicht angewendet.

Die ifcfg-*-Dateien enthalten Informationen wie den Startmodus und die IP-Adresse. Mögliche Parameter sind auf der man-Seite für den Befehl ifup beschrieben. Wenn eine allgemeine Einstellung nur für eine bestimmte Bedienoberfläche verwendet werden soll, können außerdem alle Variablen aus den Dateien dhcp und wireless in den ifcfg-*-Dateien verwendet werden. Jedoch sind die meisten /etc/sysconfig/network/config-Variablen global und lassen sich in ifcfg-Dateien nicht überschreiben. Beispielsweise sind die Variablen NETCONFIG_* global.

Weitere Informationen zum Konfigurieren der macvlan- und der macvtab-Schnittstelle finden Sie auf den man-Seiten zu ifcfg-macvlan und ifcfg-macvtap. Für eine macvlan-Schnittstelle benötigen Sie beispielsweise eine ifcfg-macvlan0-Datei mit den folgenden Einstellungen: 

STARTMODE='auto'
MACVLAN_DEVICE='eth0'
#MACVLAN_MODE='vepa'
#LLADDR=02:03:04:05:06:aa

Informationen zu ifcfg.template finden Sie unter Abschnitt 19.5.2.6, „/etc/sysconfig/network/config, /etc/sysconfig/network/dhcp und /etc/sysconfig/network/wireless“.

IBM Z IBM Z unterstützt USB nicht. Die Namen der Schnittstellendateien und Netzwerkaliasse enthalten IBM Z-spezifische Elemente wie qeth.

19.5.2.6 /etc/sysconfig/network/config, /etc/sysconfig/network/dhcp und /etc/sysconfig/network/wireless

 

Die Datei config enthält allgemeine Einstellungen für das Verhalten von ifup, ifdown und ifstatus. dhcp enthält Einstellungen für DHCP und wireless für WLAN-Karten. Die Variablen in allen drei Konfigurationsdateien sind kommentiert. Einige der Variablen von /etc/sysconfig/network/config können auch in ifcfg-*-Dateien verwendet werden, wo sie eine höhere Priorität erhalten. Die Datei /etc/sysconfig/network/ifcfg.template listet Variablen auf, die mit einer Reichweite pro Schnittstelle angegeben werden können. Jedoch sind die meisten /etc/sysconfig/network/config-Variablen global und lassen sich in ifcfg-Dateien nicht überschreiben. Beispielsweise sind die Variablen NETWORKMANAGER oder NETCONFIG_* global.

Anmerkung
Anmerkung: Verwenden von DHCPv6

In SUSE Linux Enterprise 11 konnte DHCPv6 selbst auf Netzwerken genutzt werden, deren IPv6-RAs (Router Advertisements) nicht fehlerfrei konfiguriert waren. Ab SUSE Linux Enterprise 12 verlangt DHCPv6, dass mindestens ein Router im Netzwerk RAs aussendet, aus denen hervorgeht, dass das Netzwerk über DHCPv6 verwaltet wird.

In Netzwerken, in denen der Router nicht ordnungsgemäß konfiguriert werden kann, können Sie dieses Verhalten mit einer ifcfg-Option außer Kraft setzen. Geben Sie hierzu DHCLIENT6_MODE='managed' in der ifcfg-Datei an. Alternativ wenden Sie diese Behelfslösung mit einem Bootparameter im Installationssystem an: 

ifcfg=eth0=dhcp6,DHCLIENT6_MODE=managed

19.5.2.7 /etc/sysconfig/network/routes und /etc/sysconfig/network/ifroute-*

 

Das statische Routing von TCP/IP-Paketen wird mit den Dateien /etc/sysconfig/network/routes und /etc/sysconfig/network/ifroute-* bestimmt. Alle statischen Routen, die für verschiedene Systemaufgaben benötigt werden, können in /etc/sysconfig/network/routes angegeben werden: Routen zu einem Host, Routen zu einem Host über Gateways und Routen zu einem Netzwerk. Definieren Sie für jede Schnittstelle, die individuelles Routing benötigt, eine zusätzliche Konfigurationsdatei: /etc/sysconfig/network/ifroute-*. Ersetzen Sie das Platzhalterzeichen (*) durch den Namen der Schnittstelle. Die Einträge in der Routing-Konfigurationsdatei sehen wie folgt aus: 

# Destination     Gateway           Netmask            Interface  Options

Das Routenziel steht in der ersten Spalte. Diese Spalte kann die IP-Adresse eines Netzwerks oder Hosts bzw. (im Fall von erreichbaren Nameservern) den voll qualifizierten Netzwerk- oder Hostnamen enthalten. Die Netzwerkadresse muss in der CIDR-Notation (Adresse mit entsprechender Routing-Präfixlänge) angegeben werden, z. B. 10.10.0.0/16 für IPv4-Routen oder fc00::/7 für IPv6-Routen. Das Schlüsselwort default gibt an, dass die Route des Standard-Gateways in derselben Adressfamilie wie der Gateway ist. Bei Geräten ohne Gateway verwenden Sie die expliziten Ziele 0.0.0.0/0 oder ::/0.

Die zweite Spalte enthält das Standard-Gateway oder ein Gateway, über das der Zugriff auf einen Host oder ein Netzwerk erfolgt.

Die dritte Spalte wird nicht mehr verwendet; hier wurde bislang die IPv4-Netzmaske des Ziels angegeben. Für IPv6-Routen, für die Standardroute oder bei Verwendung einer Präfixlänge (CIDR-Notation) in der ersten Spalte tragen Sie hier einen Strich (-) ein.

Die vierte Spalte enthält den Namen der Schnittstelle. Wenn Sie in dieser Spalte nur einen Strich (-) statt eines Namens angeben, kann dies zu unerwünschtem Verhalten in /etc/sysconfig/network/routes führen. Weitere Informationen finden Sie auf der man-Seite zu routes.

In einer (optionalen) fünften Spalte können Sie besondere Optionen angeben. Weitere Informationen finden Sie auf der man-Seite zu routes.

Beispiel 19.5: Gebräuchliche Netzwerkschnittstellen und Beispiele für statische Routen
 
# --- IPv4 routes in CIDR prefix notation:
# Destination     [Gateway]         -                  Interface
127.0.0.0/8       -                 -                  lo
204.127.235.0/24  -                 -                  eth0
default           204.127.235.41    -                  eth0
207.68.156.51/32  207.68.145.45     -                  eth1
192.168.0.0/16    207.68.156.51     -                  eth1

# --- IPv4 routes in deprecated netmask notation"
# Destination     [Dummy/Gateway]   Netmask            Interface
#
127.0.0.0         0.0.0.0           255.255.255.0      lo
204.127.235.0     0.0.0.0           255.255.255.0      eth0
default           204.127.235.41    0.0.0.0            eth0
207.68.156.51     207.68.145.45     255.255.255.255    eth1
192.168.0.0       207.68.156.51     255.255.0.0        eth1

# --- IPv6 routes are always using CIDR notation:
# Destination     [Gateway]                -           Interface
2001:DB8:100::/64 -                        -           eth0
2001:DB8:100::/32 fe80::216:3eff:fe6d:c042 -           eth0

19.5.2.8 /var/run/netconfig/resolv.conf

 

In /var/run/netconfig/resolv.conf wird die Domäne angegeben, zu der der Host gehört (Schlüsselwort search). Mit der Option search können Sie bis zu sechs Domänen mit insgesamt 256 Zeichen angeben. Bei der Auflösung eines Namens, der nicht voll qualifiziert ist, wird versucht, einen solchen zu generieren, indem die einzelnen search-Einträge angehängt werden. Mit der Option nameserver können Sie bis zu drei Nameserver angeben (jeweils in einer eigenen Zeile). Kommentare sind mit einer Raute (#) oder einem Semikolon (;) gekennzeichnet. Ein Beispiel finden Sie in Beispiel 19.6, „/var/run/netconfig/resolv.conf“.

Jedoch sollte /etc/resolv.conf nicht manuell bearbeitet werden. Es wird vom Skript netconfig generiert und stellt einen symbolischen Link zu /run/netconfig/resolv.conf dar. Um die statische DNS-Konfiguration ohne YaST zu definieren, bearbeiten Sie die entsprechenden Variablen in der Datei /etc/sysconfig/network/config manuell:

NETCONFIG_DNS_STATIC_SEARCHLIST

Liste der DNS-Domänennamen, die für die Suche nach Hostname verwendet wird

NETCONFIG_DNS_STATIC_SERVERS

Liste der IP-Adressen des Nameservers, die für die Suche nach Hostname verwendet wird

NETCONFIG_DNS_FORWARDER

Name des zu konfigurierenden DNS-Forwarders, beispielsweise bind oder resolver

NETCONFIG_DNS_RESOLVER_OPTIONS

Beliebige Optionen, die in /var/run/netconfig/resolv.conf geschrieben werden, beispielsweise: 

debug attempts:1 timeout:10

Weitere Informationen finden Sie auf der man-Seite zu resolv.conf.

NETCONFIG_DNS_RESOLVER_SORTLIST

Liste mit bis zu 10 Einträgen, beispielsweise: 

130.155.160.0/255.255.240.0 130.155.0.0

Weitere Informationen finden Sie auf der man-Seite zu resolv.conf.

Zum Deaktivieren der DNS-Konfiguration mit netconfig setzen Sie NETCONFIG_DNS_POLICY=''. Weitere Informationen zu netconfig finden Sie auf der man-Seite zu netconfig(8) (man 8 netconfig).

Beispiel 19.6: /var/run/netconfig/resolv.conf
 
# Our domain
search example.com
#
# We use dns.example.com (192.168.1.116) as nameserver
nameserver 192.168.1.116

19.5.2.9 /sbin/netconfig

 

netconfig ist ein modulares Tool zum Verwalten zusätzlicher Netzwerkkonfigurationseinstellungen. Es führt statisch definierte Einstellungen mit Einstellungen zusammen, die von automatischen Konfigurationsmechanismen wie DHCP oder PPP gemäß einer vordefinierten Richtlinie bereitgestellt wurden. Die erforderlichen Änderungen werden dem System zugewiesen, indem die netconfig-Module aufgerufen werden, die für das Ändern einer Konfigurationsdatei und den Neustart eines Service oder eine ähnliche Aktion verantwortlich sind.

netconfig erkennt drei Hauptaktionen. Die Kommandos netconfig modify und netconfig remove werden von Daemons wie DHCP oder PPP verwendet, um Einstellungen für netconfig hinzuzufügen oder zu entfernen. Nur das Kommando netconfig update steht dem Benutzer zur Verfügung:

modify

Das Kommando netconfig modify ändert die aktuelle Schnittstellen- und Service-spezifischen dynamischen Einstellungen und aktualisiert die Netzwerkkonfiguration. Netconfig liest Einstellungen aus der Standardeingabe oder einer Datei, die mit der Option --lease-file DATEINAME angegeben wurde, und speichert sie intern bis zu einem System-Reboot oder der nächsten Änderungs- oder Löschaktion). Bereits vorhandene Einstellungen für dieselbe Schnittstellen- und Service-Kombination werden überschrieben. Die Schnittstelle wird durch den Parameter -i SCHNITTSTELLENNAME angegeben. Der Service wird durch den Parameter -s SERVICENAME angegeben.

Entfernen

Das Kommando netconfig remove entfernt die dynamischen Einstellungen, die von einer Bearbeitungsaktion für die angegebene Schnittstellen- und Service-Kombination bereitgestellt wurden, und aktualisiert die Netzwerkkonfiguration. Die Schnittstelle wird durch den Parameter -i SCHNITTSTELLENNAME angegeben. Der Service wird durch den Parameter -s SERVICENAME angegeben.

Aktualisieren

Das Kommando netconfig update aktualisiert die Netzwerkkonfiguration mit den aktuellen Einstellungen. Dies ist nützlich, wenn sich die Richtlinie oder die statische Konfiguration geändert hat. Verwenden Sie den Parameter -m MODULTYP, wenn nur ein angegebener Dienst aktualisiert werden soll (dns,nis oder ntp).

Die Einstellungen für die netconfig-Richtlinie und die statische Konfiguration werden entweder manuell oder mithilfe von YaST in der Datei /etc/sysconfig/network/config definiert. Die dynamischen Konfigurationseinstellungen von Tools zur automatischen Konfiguration wie DHCP oder PPP werden von diesen Tools mit den Aktionen netconfig modify und netconfig remove direkt bereitgestellt. Wenn NetworkManager aktiviert ist, verwendet netconfig (im Richtlinienmodus auto) nur NetworkManager-Einstellungen und ignoriert Einstellungen von allen anderen Schnittstellen, die mit der traditionellen ifup-Methode konfiguriert wurden. Wenn NetworkManager keine Einstellung liefert, werden als Fallback statische Einstellungen verwendet. Eine gemischte Verwendung von NetworkManager und der wicked-Methode wird nicht unterstützt.

Weitere Informationen über netconfig finden Sie auf man 8 netconfig.

19.5.2.10 /etc/hosts

 

In dieser Datei werden, wie in Beispiel 19.7, „/etc/hosts“ gezeigt, IP-Adressen zu Hostnamen zugewiesen. Wenn kein Namenserver implementiert ist, müssen alle Hosts, für die IP-Verbindungen eingerichtet werden sollen, hier aufgeführt sein. Geben Sie für jeden Host in die Datei eine Zeile ein, die aus der IP-Adresse, dem voll qualifizierten Hostnamen und dem Hostnamen besteht. Die IP-Adresse muss am Anfang der Zeile stehen und die Einträge müssen durch Leerzeichen und Tabulatoren getrennt werden. Kommentaren wird immer das #-Zeichen vorangestellt.

Beispiel 19.7: /etc/hosts
 
127.0.0.1 localhost
192.168.2.100 jupiter.example.com jupiter
192.168.2.101 venus.example.com venus

19.5.2.11 /etc/networks

 

Hier werden Netzwerknamen in Netzwerkadressen umgesetzt. Das Format ähnelt dem der hosts-Datei, jedoch stehen hier die Netzwerknamen vor den Adressen. Siehe Beispiel 19.8, „/etc/networks“.

Beispiel 19.8: /etc/networks
 
loopback     127.0.0.0
localnet     192.168.0.0

19.5.2.12 /etc/host.conf

 

Das Auflösen von Namen, d. h. das Übersetzen von Host- bzw. Netzwerknamen über die resolver-Bibliothek, wird durch diese Datei gesteuert. Diese Datei wird nur für Programme verwendet, die mit libc4 oder libc5 gelinkt sind. Weitere Informationen zu aktuellen glibc-Programmen finden Sie in den Einstellungen in /etc/nsswitch.conf. Jeder Parameter muss immer auf einer separaten Zeile eingegeben werden. Kommentaren wird ein #-Zeichen vorangestellt. Tabelle 19.2, „Parameter für /etc/host.conf“ zeigt die verfügbaren Parameter. Ein Beispiel für /etc/host.conf wird in Beispiel 19.9, „/etc/host.conf“ gezeigt.

Tabelle 19.2: Parameter für /etc/host.conf
 

order hosts, bind

Legt fest, in welcher Reihenfolge die Dienste zum Auflösen eines Namens angesprochen werden sollen. Mögliche Argumente (getrennt durch Leerzeichen oder Kommas):

Hosts: Sucht die /etc/hosts-Datei

bind: Greift auf einen Namenserver zu

nis: Verwendet NIS

multi on/off

Legt fest, ob ein in /etc/hosts eingegebener Host mehrere IP-Adressen haben kann.

nospoof on spoofalert on/off

Diese Parameter beeinflussen das spoofing des Namenservers, haben aber keinen Einfluss auf die Netzwerkkonfiguration.

trim Domänenname

Der angegebene Domänenname wird vor dem Auflösen des Hostnamens von diesem abgeschnitten (insofern der Hostname diesen Domänennamen enthält). Diese Option ist nur dann von Nutzen, wenn in der Datei /etc/hosts nur Namen aus der lokalen Domäne stehen, diese aber auch mit angehängtem Domänennamen erkannt werden sollen.

Beispiel 19.9: /etc/host.conf
 
# We have named running
order hosts bind
# Allow multiple address
multi on

19.5.2.13 /etc/nsswitch.conf

 

Mit der GNU C Library 2.0 wurde Name Service Switch (NSS) eingeführt. Weitere Informationen hierzu finden Sie auf der man-Seite für nsswitch.conf(5) und im Dokument The GNU C Library Reference Manual.

In der Datei /etc/nsswitch.conf wird festgelegt, in welcher Reihenfolge bestimmte Informationen abgefragt werden. Ein Beispiel für nsswitch.conf ist in Beispiel 19.10, „/etc/nsswitch.conf“ dargestellt. Kommentaren werden #-Zeichen vorangestellt. Der Eintrag unter der hosts-Datenbank bedeutet, dass Anfragen über DNS an /etc/hosts (files) gehen (siehe Kapitel 31, Domain Name System (DNS)).

Beispiel 19.10: /etc/nsswitch.conf
 
passwd:     compat
group:      compat

hosts:      files dns
networks:   files dns

services:   db files
protocols:  db files
rpc:        files
ethers:     files
netmasks:   files
netgroup:   files nis
publickey:  files

bootparams: files
automount:  files nis
aliases:    files nis
shadow:     compat

Die über NSS verfügbaren „Datenbanken“ sind in Tabelle 19.3, „Über /etc/nsswitch.conf verfügbare Datenbanken“ aufgelistet. Die Konfigurationsoptionen für NSS-Datenbanken sind in Tabelle 19.4, „Konfigurationsoptionen für NSS-„Datenbanken““ aufgelistet.

Tabelle 19.3: Über /etc/nsswitch.conf verfügbare Datenbanken
 

aliases

Mail-Aliasse, die von sendmail implementiert werden. Siehe man5 aliases.

ethers

Ethernet-Adressen

Netzmasken

Liste von Netzwerken und ihrer Teilnetzmasken. Wird nur benötigt, wenn Sie Subnetting nutzen.

Gruppe

Benutzergruppen, die von getgrent verwendet werden. Weitere Informationen hierzu finden Sie auch auf der man-Seite für den Befehl group.

hosts

Hostnamen und IP-Adressen, die von gethostbyname und ähnlichen Funktionen verwendet werden.

netgroup

Im Netzwerk gültige Host- und Benutzerlisten zum Steuern von Zugriffsberechtigungen. Weitere Informationen hierzu finden Sie auf der man-Seite für netgroup(5).

networks

Netzwerknamen und -adressen, die von getnetent verwendet werden.

publickey

Öffentliche und geheime Schlüssel für Secure_RPC, verwendet durch NFS and NIS+.

passwd

Benutzerpasswörter, die von getpwent verwendet werden. Weitere Informationen hierzu finden Sie auf der man-Seite passwd(5).

protocols

Netzwerkprotokolle, die von getprotoent verwendet werden. Weitere Informationen hierzu finden Sie auf der man-Seite für protocols(5).

rpc

Remote Procedure Call-Namen und -Adressen, die von getrpcbyname und ähnlichen Funktionen verwendet werden.

services

Netzwerkdienste, die von getservent verwendet werden.

shadow

Shadow-Passwörter der Benutzer, die von getspnam verwendet werden. Weitere Informationen hierzu finden Sie auf der man-Seite für shadow(5).

Tabelle 19.4: Konfigurationsoptionen für NSS-„Datenbanken“
 

Dateien

Direkter Dateizugriff, z. B. /etc/aliases

db

Zugriff über eine Datenbank

nis, nisplus

NIS, siehe auch Book “Security and Hardening Guide”, Chapter 3 “Using NIS”

dns

Nur bei hosts und networks als Erweiterung verwendbar

compat

Nur bei passwd, shadow und group als Erweiterung verwendbar

19.5.2.14 /etc/nscd.conf

 

Mit dieser Datei wird nscd (Name Service Cache Daemon) konfiguriert. Weitere Informationen hierzu finden Sie auf den man-Seiten nscd(8) und nscd.conf(5). Standardmäßig werden die Systemeinträge von passwd, groups und hosts von nscd gecacht. Dies ist für die Leistung von Verzeichnisdiensten wie NIS and LDAP wichtig, denn andernfalls muss für jeden Zugriff auf Namen, Gruppen oder Hosts die Netzwerkverbindung verwendet werden.

Wenn das Caching für passwd aktiviert wird, dauert es in der Regel 15 Sekunden, bis ein neu angelegter lokaler Benutzer dem System bekannt ist. Zum Verkürzen dieser Wartezeit starten Sie nscd wie folgt neu: 

tux > sudo systemctl restart nscd

19.5.2.15 /etc/HOSTNAME

 

/etc/HOSTNAME enthält den vollständigen Hostnamen (FQHN). Der vollständige Hostname besteht aus dem eigentlichen Hostnamen und der Domäne. Die Datei darf nur eine einzige Zeile enthalten (in der der Hostname angegeben ist). Diese Angabe wird beim Booten des Rechners gelesen.

19.5.3 Testen Sie die Konfiguration.

 

Bevor Sie Ihre Konfiguration in den Konfigurationsdateien speichern, können Sie sie testen. Zum Einrichten einer Testkonfiguration verwenden Sie den Befehl ip. Zum Testen der Verbindung verwenden Sie den Befehl ping.

Das Kommando ip ändert die Netzwerkkonfiguration direkt, ohne sie in der Konfigurationsdatei zu speichern. Wenn Sie die Konfiguration nicht in die korrekten Konfigurationsdateien eingeben, geht die geänderte Netzwerkkonfiguration nach dem Neustart verloren.

Anmerkung
Anmerkung: ifconfig und route sind veraltet

Die Werkzeuge ifconfig und route sind veraltet. Verwenden Sie stattdessen ip. Bei ifconfig sind die Schnittstellennamen beispielsweise auf 9 Zeichen begrenzt.

19.5.3.1 Konfigurieren einer Netzwerkschnittstelle mit ip

 

ip ist ein Werkzeug zum Anzeigen und Konfigurieren von Netzwerkgeräten, Richtlinien-Routing und Tunneln.

ip ist ein sehr komplexes Werkzeug. Seine allgemeine Syntax ist ip OPTIONS OBJECT COMMAND. Sie können mit folgenden Objekten arbeiten:

Verbindung

Dieses Objekt stellt ein Netzwerkgerät dar.

Adresse

Dieses Objekt stellt die IP-Adresse des Geräts dar.

Nachbar

Dieses Objekt stellt einen ARP- oder NDISC-Cache-Eintrag dar.

route

Dieses Objekt stellt den Routing-Tabelleneintrag dar.

Regel

Dieses Objekt stellt eine Regel in der Routing-Richtlinien-Datenbank dar.

maddress

Dieses Objekt stellt eine Multicast-Adresse dar.

mroute

Dieses Objekt stellt einen Multicast-Routing-Cache-Eintrag dar.

tunnel

Dieses Objekt stellt einen Tunnel über IP dar.

Wird kein Kommando angegeben, wird das Standardkommando verwendet (normalerweise list).

Ändern Sie den Gerätestatus mit dem Befehl: 

tux > sudo ip link set DEV_NAME

Wenn Sie beispielsweise das Gerät eth0 deaktivieren möchten, geben Sie Folgendes ein: 

tux > sudo ip link set eth0 down

Zur erneuten Aktivierung verwenden Sie 

tux > sudo ip link set eth0 up
Tipp
Tipp: Trennen des NIC-Geräts

Wenn Sie ein Gerät mit 

tux > sudo ip link set DEV_NAME down

deaktivieren, wird die Netzwerkschnittstelle auf einer Softwareebene deaktiviert.

Wenn Sie simulieren möchten, dass die Verbindung getrennt wird, so als ob ein Ethernetkabel gezogen oder der Verbindungsschalter ausgeschaltet wird, führen Sie folgendes Kommando aus: 

tux > sudo ip link set DEV_NAME carrier off

Beispiel: Mit ip link set DEV_NAME down werden alle Routen mit DEV_NAME verlassen, bei ip link set DEV carrier off ist dies nicht der Fall. Beachten Sie, dass carrier off vom Netzwerkgerätetreiber unterstützt werden muss.

Führen Sie zur erneuten Verbindung mit dem physischen Netzwerk folgendes Kommando aus: 

tux > sudo ip link set DEV_NAME carrier on

Nach dem Aktivieren eines Geräts können Sie es konfigurieren. Die IP-Adresse legen Sie fest mit 

tux > sudo ip addr add IP_ADDRESS + dev DEV_NAME

Wenn Sie beispielsweise die Adresse der Schnittstelle eth0 auf 192.168.12.154/30 mit standardmäßigem Broadcast (Option brd) setzen möchten, geben Sie Folgendes ein: 

tux > sudo ip addr add 192.168.12.154/30 brd + dev eth0

Damit die Verbindung funktioniert, müssen Sie außerdem das Standard-Gateway konfigurieren. Geben Sie zum Festlegen eines Gateways für Ihr System Folgendes ein: 

tux > sudo ip route add default via gateway_ip_address

Zum Anzeigen aller Geräte verwenden Sie 

tux > sudo ip link ls

Wenn Sie nur die aktiven Schnittstellen abrufen möchten, verwenden Sie 

tux > sudo ip link ls up

Zum Drucken von Schnittstellenstatistiken für ein Gerät geben Sie Folgendes ein: 

tux > sudo ip -s link ls DEV_NAME

Zum Anzeigen weiterer nützlicher Informationen, insbesondere über virtuelle Netzwerkgeräte, geben Sie Folgendes ein: 

tux > sudo ip -d link ls DEV_NAME

Zur Anzeige der Adressen der Netzwerkschicht (IPv4, IPv6) Ihrer Geräte geben Sie Folgendes ein: 

tux > sudo ip addr

In der Ausgabe finden Sie Informationen über die MAC-Adressen Ihrer Geräte. Wenn Sie alle Routen anzeigen möchten, wählen Sie 

tux > sudo ip route show

Weitere Informationen zur Verwendung von ip erhalten Sie, indem Sie iphelp eingeben oder die man-Seite man 8 ip aufrufen. Die Option help ist zudem für alle ip-Unterkommandos verfügbar, wie: 

tux > sudo ip addr help

Suchen Sie die ip-Manualpage in der Datei /usr/share/doc/packages/iproute2/ip-cref.pdf.

19.5.3.2 Testen einer Verbindung mit „ping“

 

Der ping-Befehl ist das Standardwerkzeug zum Testen, ob eine TCP/IP-Verbindung funktioniert. Er verwendet das ICMP-Protokoll, um ein kleines Datenpaket, das ECHO_REQUEST-Datagram, an den Ziel-Host zu senden. Dabei wird eine sofortige Antwort angefordert. Wenn dies funktioniert, zeigt ping eine entsprechende Meldung an. Dies weist darauf hin, dass die Netzwerkverbindung ordnungsgemäß arbeitet.

ping testet nicht nur die Funktion der Verbindung zwischen zwei Computern, es bietet darüber hinaus grundlegende Informationen zur Qualität der Verbindung. In Beispiel 19.11, „Ausgabe des ping-Befehls“ sehen Sie ein Beispiel der ping-Ausgabe. Die vorletzte Zeile enthält Informationen zur Anzahl der übertragenen Pakete, der verlorenen Pakete und der Gesamtlaufzeit von ping.

Als Ziel können Sie einen Hostnamen oder eine IP-Adresse verwenden, z. B. ping example.com oder ping 192.168.3.100. Das Programm sendet Pakete, bis Sie Strg–C drücken.

Wenn Sie nur die Funktion der Verbindung überprüfen möchten, können Sie die Anzahl der Pakete durch die Option -c beschränken. Wenn Sie die Anzahl beispielsweise auf drei Pakete beschränken möchten, geben Sie ping -c 3 example.com ein.

Beispiel 19.11: Ausgabe des ping-Befehls
 
ping -c 3 example.com
PING example.com (192.168.3.100) 56(84) bytes of data.
64 bytes from example.com (192.168.3.100): icmp_seq=1 ttl=49 time=188 ms
64 bytes from example.com (192.168.3.100): icmp_seq=2 ttl=49 time=184 ms
64 bytes from example.com (192.168.3.100): icmp_seq=3 ttl=49 time=183 ms
--- example.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2007ms
rtt min/avg/max/mdev = 183.417/185.447/188.259/2.052 ms

Das Standardintervall zwischen zwei Paketen beträgt eine Sekunde. Zum Ändern des Intervalls bietet das ping-Kommando die Option -i. Wenn beispielsweise das Ping-Intervall auf zehn Sekunden erhöht werden soll, geben Sie ping -i 10 example.com ein.

In einem System mit mehreren Netzwerkgeräten ist es manchmal nützlich, wenn der ping-Befehl über eine spezifische Schnittstellenadresse gesendet wird. Verwenden Sie hierfür die Option -I mit dem Namen des ausgewählten Geräts. Beispiel: ping -I wlan1 example.com.

Weitere Optionen und Informationen zur Verwendung von ping erhalten Sie, indem Sie ping-h eingeben oder die man-Seite ping (8) aufrufen.

Tipp
Tipp: Ping-Ermittlung für IPv6-Adressen

Verwenden Sie für IPv6-Adressen das Kommando ping6. Hinweis: Zur Ping-Ermittlung für Link-Local-Adressen müssen Sie die Schnittstelle mit -I angeben. Das folgende Kommando funktioniert, wenn die Adresse über eth1 erreichbar ist: 

ping6 -I eth1 fe80::117:21ff:feda:a425

19.5.4 Unit-Dateien und Startskripte

 

Neben den beschriebenen Konfigurationsdateien gibt es noch systemd-Unit-Dateien und verschiedene Skripte, die beim Booten des Computers die Netzwerkdienste laden. Diese werden gestartet, wenn das System auf das Ziel multi-user.target umgestellt wird. Eine Beschreibung für einige Unit-Dateien und Skripte finden Sie unter Einige Unit-Dateien und Startskripte für Netzwerkprogramme. Weitere Informationen zu systemd finden Sie unter Kapitel 15, Der Daemon systemd; weitere Informationen zu den systemd-Zielen finden Sie auf der man-Seite zu systemd.special (man systemd.special).

Einige Unit-Dateien und Startskripte für Netzwerkprogramme
 
network.target

network.target ist das systemd-Ziel für das Netzwerk, es ist jedoch abhängig von den Einstellungen, die der Systemadministrator angegeben hat.

Weitere Informationen finden Sie im http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/.

multi-user.target

multi-user.target ist das systemd-Ziel für ein Mehrbenutzersystem mit allen erforderlichen Netzwerkdiensten.

rpcbind

Startet das rpcbind-Dienstprogramm, das RPC-Programmnummern in universelle Adressen konvertiert. Es ist für RPC-Dienste wie NFS-Server erforderlich.

ypserv

Startet den NIS-Server.

ypbind

Startet den NIS-Client.

/etc/init.d/nfsserver

Startet den NFS-Server.

/etc/init.d/postfix

Steuert den postfix-Prozess.

19.6 Grundlegende Routereinrichtung

 

Ein Router ist ein Netzwerkgerät, das Daten hin und zurück an mehr als ein Netzwerk zustellt und von diesen empfängt (Netzwerkpakete). Ein Router wird häufig zum Verbinden Ihres lokalen Netzwerks mit dem Remote-Netzwerk (Internet) oder zum Verbinden lokaler Netzwerksegmente verwendet. Mit SUSE Linux Enterprise Server können Sie einen Router mit Funktionen wie Network Address Translation (NAT) oder erweiterten Firewalls erstellen.

Im Folgenden sind grundlegende Schritte beschrieben, mit denen Sie SUSE Linux Enterprise Server in einen Router umfunktionieren können.

  1. Aktivieren Sie die Weiterleitung, beispielsweise in der Datei /etc/sysctl.d/50-router.conf aktivieren 

    net.ipv4.conf.all.forwarding = 1
net.ipv6.conf.all.forwarding = 1

    Stellen Sie dann ein statisches IPv4- und IPv6-IP-Setup für die Schnittstellen bereit. Durch das Aktivieren der Weiterleitung werden mehrere Mechanismen deaktiviert. Beispielsweise akzeptiert IPv6 keine IPv6-RAs (Router Advertisements) mehr, wodurch ebenfalls die Erstellung einer Standardroute vermieden wird.

  2. In vielen Situationen, beispielsweise wenn Sie über mehr als eine Schnittstelle auf das gleiche Netzwerk zugreifen können oder wenn in der Regel VPN verwendet wird (und sich bereits auf „normalen Multihome-Hosts“ befindet), müssen Sie den Reverse-Path-Filter für IPv4 deaktivieren (diese Funktion ist derzeit für IPv6 nicht vorhanden): 

    net.ipv4.conf.all.rp_filter = 0

    Stattdessen ist auch das Filtern mit Firewall-Einstellungen möglich.

  3. Um ein IPv6-RA zu akzeptieren (vom Router auf eine externe, Uplink- oder ISP-Schnittstelle) und wieder eine IPv6-Standardroute (oder auch eine speziellere Route) zu erstellen, legen Sie Folgendes fest: 

    net.ipv6.conf.${ifname}.accept_ra = 2
net.ipv6.conf.${ifname}.autoconf = 0

    (Hinweis: „eth0.42“ muss in einem durch Punkte getrennten sysfs-Pfad als eth0/42 angegeben werden.)

Weitere Beschreibungen zum Routerverhalten und zu Weiterleitungsabhängigkeiten sind unter https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt zu finden.

Um IPv6 auf Ihren internen (DMZ-)Schnittstellen bereitzustellen und den eigenen Router als IPv6-Router bekanntzugeben sowie „autoconf“ der Netzwerke für die Clients auszuführen, installieren und konfigurieren Sie radvd in der Datei /etc/radvd.conf. Beispiel: 

interface eth0
{
    IgnoreIfMissing on;         # do not fail if interface missed

    AdvSendAdvert on;           # enable sending RAs
    AdvManagedFlag on;          # IPv6 addresses managed via DHCPv6
    AdvOtherConfigFlag on;      # DNS, NTP... only via DHCPv6

    AdvDefaultLifetime 3600;    # client default route lifetime of 1 hour

    prefix 2001:db8:0:1::/64    # (/64 is default and required for autoconf)
    {
        AdvAutonomous off;         # Disable address autoconf (DHCPv6 only)

        AdvValidLifetime 3600;     # prefix (autoconf addr) is valid 1 h
        AdvPreferredLifetime 1800; # prefix (autoconf addr) is prefered 1/2 h
    }
}

Konfigurieren Sie die Firewall so, dass Datenverkehr aus dem LAN in das WAN mit NAT maskiert („Masquerading“) und eingehender Datenverkehr auf der WAN-Schnittstelle blockiert wird: 

tux > sudo firewall-cmd --permanent --zone=external --change-interface=WAN_INTERFACE
tux > sudo firewall-cmd --permanent --zone=external --add-masquerade
tux > sudo firewall-cmd --permanent --zone=internal --change-interface=LAN_INTERFACE
tux > sudo firewall-cmd --reload

19.7 Einrichten von Bonding-Geräten

 

Für bestimmte Systeme sind Netzwerkverbindungen erforderlich, die die normalen Anforderungen an die Datensicherheit oder Verfügbarkeit von typischen Ethernet-Geräten übertreffen. In diesen Fällen lassen sich mehrere Ethernet-Geräte zu einem einzigen Bonding-Gerät zusammenschließen.

Die Konfiguration des Bonding-Geräts erfolgt dabei über die Bonding-Moduloptionen. Das Verhalten ergibt sich im wesentlichen aus dem Modus des Bonding-Geräts. Standardmäßig gilt active-backup; wenn das aktive Slave-Gerät ausfällt, wird also ein anderes Slave-Gerät aktiviert. Die folgenden Bonding-Modi sind verfügbar:

0 (balance-rr)

Die Pakete werden per Round-Robin von der ersten bis zur letzten verfügbaren Schnittstelle übertragen. Bietet Fehlertoleranz und Lastausgleich.

1 (active-backup)

Nur eine Netzwerkschnittstelle ist aktiv. Wenn diese Schnittstelle ausfällt, wird eine andere Schnittstelle aktiv. Dies ist die Standardeinstellung für SUSE Linux Enterprise Server. Bietet Fehlertoleranz.

2 (balance-xor)

Der Datenverkehr wird gemäß der folgenden Richtlinie auf alle verfügbaren Schnittstellen aufgeteilt: [(Quell-MAC-Adresse mit XOR mit Ziel-MAC-Adresse XOR Pakettyp-ID) Modulo-Slave-Anzahl] Erfordert Unterstützung durch den Switch. Bietet Fehlertoleranz und Lastausgleich.

3 (broadcast)

Der gesamte Datenverkehr wird per Broadcast an alle Schnittstellen übertragen. Erfordert Unterstützung durch den Switch. Bietet Fehlertoleranz.

4 (802.3ad)

Aggregiert mehrere Schnittstellen zu einer Gruppe, in der dieselben Geschwindigkeits- und Duplexeinstellungen gelten. Erfordert ethtool-Unterstützung durch die Schnittstellentreiber sowie einen Switch, der die dynamische Link-Aggregation nach IEEE 802.3ad unterstützt und entsprechend konfiguriert ist. Bietet Fehlertoleranz und Lastausgleich.

5 (balance-tlb)

Adaptiver Übertragungslastausgleich. Erfordert ethtool-Unterstützung durch die Schnittstellentreiber, jedoch keine Unterstützung durch den Switch. Bietet Fehlertoleranz und Lastausgleich.

6 (balance-alb)

Adaptiver Lastausgleich. Erfordert ethtool-Unterstützung durch die Schnittstellentreiber, jedoch keine Unterstützung durch den Switch. Bietet Fehlertoleranz und Lastausgleich.

Eine ausführlichere Beschreibung der Modi finden Sie unter https://www.kernel.org/doc/Documentation/networking/bonding.txt.

Tipp
Tipp: Bonding und Xen

Der Einsatz von Bonding-Geräten empfiehlt sich nur für Computer, in denen mehrere physische Netzwerkkarten eingebaut sind. Bei den meisten Konstellationen sollten Sie die Bonding-Konfiguration daher lediglich in Dom0 verwenden. Die Bond-Einrichtung in einem VM-Gast-System ist dabei nur dann sinnvoll, wenn dem VM-Gast mehrere Netzwerkkarten zugewiesen sind.

Anmerkung
Anmerkung: IBM POWER: Bonding-Modi 5 und 6 (balance-tlb / balance-alb) werden von ibmveth nicht mehr unterstützt

Es besteht ein Konflikt zwischen der tlb/alb-Bonding-Konfiguration und der Power-Firmware. Kurz gesagt, der Bonding-Treiber im tlb/alb-Modus sendet Ethernet-Loopback-Pakete mit den Ursprungs- und Ziel-MAC-Adressen, die als virtuelle Ethernet-MAC-Adressen aufgelistet sind. Diese Pakete werden von der Power-Firmware nicht unterstützt. Daher werden die Bonding-Modi 5 und 6 von ibmveth nicht mehr unterstützt.

Zum Konfigurieren eines Bonding-Geräts gehen Sie wie folgt vor:

  1. Führen Sie YaST › System › Netzwerkeinstellungen aus.

  2. Wählen Sie Hinzufügen und ändern Sie die Einstellung unter Gerätetyp in Bond. Fahren Sie mit Weiter fort.

    Image

  3. Geben Sie an, wie dem Bonding-Gerät eine IP-Adresse zugewiesen werden soll. Hierfür stehen drei Methoden zur Auswahl:

    • No IP Address (Keine IP-Adresse)

    • Dynamic Address (with DHCP or Zeroconf) (Dynamische Adresse (mit DHCP oder Zeroconf))

    • Statisch zugewiesene IP-Adresse

    Wählen Sie die passende Methode für Ihre Umgebung aus.

  4. Wählen Sie auf dem Karteireiter Bond-Slaves die Ethernet-Geräte aus, die in den Bond aufgenommen werden sollen. Aktivieren Sie hierzu die entsprechenden Kontrollkästchen.

  5. Bearbeiten Sie die Bond-Treiberoptionen und wählen Sie einen Bonding-Modus aus.

  6. Der Parameter miimon=100 muss unter Bond-Treiberoptionen angegeben werden. Ohne diesen Parameter wird die Datenintegrität nicht regelmäßig überprüft.

  7. Klicken Sie auf Weiter, und beenden Sie YaST mit OK. Das Gerät wird erstellt.

19.7.1 Hot-Plugging von Bonding-Slaves

 

In bestimmten Netzwerkumgebungen (z. B. High Availability) muss eine Bonding-Slave-Schnittstelle durch eine andere Schnittstelle ersetzt werden. Dieser Fall tritt beispielsweise ein, wenn ein Netzwerkgerät wiederholt ausfällt. Die Lösung ist hier das Hot-Plugging der Bonding-Slaves.

Der Bond wird wie gewohnt konfiguriert (gemäß man 5 ifcfg-bonding), beispielsweise: 

ifcfg-bond0
          STARTMODE='auto' # or 'onboot'
          BOOTPROTO='static'
          IPADDR='192.168.0.1/24'
          BONDING_MASTER='yes'
          BONDING_SLAVE_0='eth0'
          BONDING_SLAVE_1='eth1'
          BONDING_MODULE_OPTS='mode=active-backup miimon=100'

Die Slaves werden mit STARTMODE=hotplug und BOOTPROTO=none angegeben: 

ifcfg-eth0
          STARTMODE='hotplug'
          BOOTPROTO='none'

ifcfg-eth1
          STARTMODE='hotplug'
          BOOTPROTO='none'

Bei BOOTPROTO=none werden die ethtool-Optionen herangezogen (sofern bereitgestellt), es wird jedoch kein Link zu ifup eth0 eingerichtet. Dies ist darin begründet, dass die Slave-Schnittstelle durch den Bond-Master gesteuert wird.

Bei STARTMODE=hotplug wird die Slave-Schnittstelle dem Bond automatisch zugefügt, wenn diese verfügbar ist.

Die udev-Regeln in /etc/udev/rules.d/70-persistent-net.rules müssen so angepasst werden, dass der Abgleich mit dem Gerät über die Bus-ID (das udev-Schlüsselwort KERNELS entspricht „SysFS BusID“, wie in hwinfo --netcard dargestellt) statt über die MAC-Adresse erfolgt. So ist es möglich, defekte Hardware auszutauschen (eine Netzwerkkarte in demselben Steckplatz, jedoch mit einer anderen MAC), und es treten keine Verwechselungen auf, wenn der Bond die MAC-Adresse aller Slaves ändert.

Beispiel: 

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
KERNELS=="0000:00:19.0", ATTR{dev_id}=="0x0", ATTR{type}=="1",
KERNEL=="eth*", NAME="eth0"

Beim Booten wartet der systemd-Service network.service nicht darauf, dass die Hot-Plug-Slaves einsatzbereit sind, sondern es wird die Bereitschaft des gesamten Bonds abgewartet, wofür mindestens ein verfügbarer Slave erforderlich ist. Wenn eine Slave-Schnittstelle aus dem System entfernt wird (durch Aufheben der Bindung an den NIC-Treiber, durch rmmod des NIC-Treibers oder durch normales PCI-Hot-Plug-Entfernen), so entfernt der Kernel die betreffende Schnittstelle automatisch aus dem Bond. Wird eine neue Karte in das System eingebaut (Austausch der Hardware im Steckplatz), benennt udev diese Karte anhand der Regel für busgestützte permanente Namen in den Namen des Slaves um und ruft ifup für die Karte auf. Mit dem ifup-Aufruf tritt die Karte automatisch in den Bond ein.

19.8 Einrichten von Team-Geräten für Netzwerk-Teaming

 

Der Begriff „Link-Aggregation“ ist der allgemeine Begriff zum Beschreiben der Kombination (oder Aggregation) einer Netzwerkverbindung zum Bereitstellen einer logischen Ebene. Manchmal stoßen Sie auf Begriffe wie „Channel-Teaming“, „Ethernet-Bonding“, „Port Truncating“ usw. Dies sind Synonyme des Begriffs und bezeichnen dasselbe Konzept.

Dieses Konzept ist allgemein bekannt als „Bonding“ und wurde ursprünglich in den Linux-Kernel integriert (Informationen zur ursprünglichen Implementierung finden Sie in Abschnitt 19.7, „Einrichten von Bonding-Geräten“). Der Begriff Netzwerk-Teaming wird zum Bezeichnen der neuen Implementierung dieses Konzepts verwendet.

Der Hauptunterschied zwischen Bonding und Netzwerk-Teaming ist der, dass das Teaming eine Reihe an kleinen Kernel-Modulen bereitstellt, die für die Bereitstellung einer Schnittstelle für die teamd-Instanzen verantwortlich sind. Alles andere wird im Userspace verarbeitet. Dies unterscheidet sich von der ursprünglichen Bondings-Implementierung, die alle ihre Funktionen ausschließlich im Kernel enthält. Einen Vergleich finden Sie unter Tabelle 19.5, „Funktionsvergleich zwischen Bonding und Team“.

Tabelle 19.5: Funktionsvergleich zwischen Bonding und Team
 
FunktionBondingTeam
Broadcast, Round-Robin-TX-RichtlinieJaJa
Active-Backup-TX-RichtlinieJaJa
LACP-Unterstützung (802.3ad)JaJa
Hashbasierte TX-RichtlinieJaJa
Benutzer kann Hashfunktion festlegenNeinJa
TX-LastenausgleichsunterstützungJaJa
TX-Lastenausgleichsunterstützung für LACPNeinJa
Ethtool-Link-ÜberwachungJaJa
ARP-Link-ÜberwachungJaJa
NS/NA-Link-Überwachung (IPv6)NeinJa
RCU-Sperre in TX-/RX-PfadenNeinJa
Portpriorität und StickinessNeinJa
Separate Einrichtung der Link-Überwachung nach PortNeinJa
Einrichtung der Link-Überwachung für mehrere PortsbegrenztJa
VLAN-UnterstützungJaJa
Stapeln mehrerer GeräteJaJa
Quelle: http://libteam.org/files/teamdev.pp.pdf

Beide Implementierungen, Bonding und Netzwerk-Teaming, können parallel verwendet werden. Netzwerk-Teaming ist eine Alternative zur bestehenden Bondings-Implementierung. Es ersetzt das Bonding nicht.

Netzwerk-Teaming kann für verschiedene Anwendungsfälle verwendet werden. Die beiden wichtigsten Anwendungsfälle werden später erläutert und umfassen:

  • Lastausgleich zwischen Netzwerkgeräten.

  • Failover von einem Netzwerkgerät zu einem anderen, falls eines der Geräte einen Fehler aufweist.

Zurzeit ist kein YaST-Modul vorhanden, dass das Erstellen eines Teaming-Geräts unterstützt. Sie müssen Netzwerk-Teaming manuell konfigurieren. Das allgemeine Verfahren ist unten dargestellt und kann auf alle Netzwerk-Teaming-Konfigurationen angewendet werden:

Vorgehen 19.1: Allgemeines Verfahren
 

  1. Stellen Sie sicher, dass alle erforderlichen Pakete installiert sind. Installieren Sie die Pakete libteam-tools, libteamdctl0, und python-libteam.

  2. Erstellen Sie eine Konfigurationsdatei unter /etc/sysconfig/network/. In der Regel ist dies ifcfg-team0. Benötigen Sie mehr als ein Netzwerk-Teaming-Gerät, teilen Sie ihnen aufsteigende Nummern zu.

    Diese Konfigurationsdatei enthält mehrere Variablen, die auf den man-Seiten erläutert werden (siehe man ifcfg und man ifcfg-team). Eine Beispielkonfiguration finden Sie im System in der Datei /etc/sysconfig/network/ifcfg.template.

  3. Entfernen Sie die Konfigurationsdatei der Schnittstellen, die für das Teaming-Gerät verwendet werden (in der Regel ifcfg-eth0 und ifcfg-eth1).

    Es wird empfohlen, eine Sicherung zu erstellen und beide Dateien zu löschen. Wicked legt die Konfigurationsdateien mit den erforderlichen Parametern für Teaming neu an.

  4. Optional können Sie überprüfen, ob alle Angeben in der Konfigurationsdatei von Wicked enthalten sind: 

    tux > sudo wicked show-config

  5. Starten Sie das Netzwerk-Teaming-Gerät team0: 

    tux > sudo wicked ifup all team0

    Falls Sie zusätzliche Informationen zur Fehlersuche benötigen, verwenden Sie die Option --debug all nach dem Subkommando all.

  6. Überprüfen Sie den Status des Netzwerk-Teaming-Geräts. Führen Sie hierzu die folgenden Kommandos aus:

    • Status der teamd-Instanz von Wicked abrufen: 

      tux > sudo wicked ifstatus --verbose team0

    • Status der gesamten Instanz abrufen: 

      tux > sudo teamdctl team0 state

    • systemd-Status der teamd-Instanz abrufen: 

      tux > sudo systemctl status teamd@team0

    Jedes Kommando zeigt eine etwas andere Ansicht abhängig von Ihren Anforderungen an.

  7. Falls Sie nachträglich Änderungen in der Datei ifcfg-team0 vornehmen müssen, laden Sie die Konfiguration der Datei mit folgendem Kommando neu: 

    tux > sudo wicked ifreload team0

Verwenden Sie nicht systemctl zum Starten oder Stoppen des Teaming-Geräts! Verwenden Sie stattdessen das Kommando wicked, wie oben gezeigt.

So entfernen Sie das Teaming-Gerät vollständig:

Vorgehen 19.2: Entfernen eines Teamgeräts
 

  1. Halten Sie das Netzwerk-Teaming-Gerät team0 an: 

    tux > sudo wicked ifdown team0

  2. Benennen Sie die Datei /etc/sysconfig/network/ifcfg-team0 in /etc/sysconfig/network/.ifcfg-team0 um. Wenn ein Punkt vor dem Dateinamen steht, ist er für Wicked „unsichtbar“. Falls Sie die Konfiguration tatsächlich nicht mehr benötigen, können Sie die Datei auch entfernen.

  3. Laden Sie die Konfiguration neu:

    tux > sudo wicked ifreload all

19.8.1 Anwendungsfall: Lastausgleich bei Netzwerk-Teaming

 

Der Lastausgleich erhöht die Bandbreite. Verwenden Sie die folgende Konfigurationsdatei zum Erstellen eines Netzwerk-Teaming-Geräts mit Funktionen für den Lastenausgleich. Fahren Sie mit Prozedur 19.1, „Allgemeines Verfahren“ fort, um das Gerät einzurichten. Überprüfen Sie die Ausgabe mit teamdctl.

Beispiel 19.12: Konfiguration für Lastausgleich bei Netzwerk-Teaming
 
STARTMODE=auto 1
BOOTPROTO=static 2
IPADDRESS="192.168.1.1/24" 2
IPADDR6="fd00:deca:fbad:50::1/64" 2

TEAM_RUNNER="loadbalance" 3
TEAM_LB_TX_HASH="ipv4,ipv6,eth,vlan"
TEAM_LB_TX_BALANCER_NAME="basic"
TEAM_LB_TX_BALANCER_INTERVAL="100"

TEAM_PORT_DEVICE_0="eth0" 4
TEAM_PORT_DEVICE_1="eth1" 4

TEAM_LW_NAME="ethtool" 5
TEAM_LW_ETHTOOL_DELAY_UP="10" 6
TEAM_LW_ETHTOOL_DELAY_DOWN="10" 6

1

Steuert das Starten des Teaming-Geräts. Der Wert auto bedeutet, dass die Schnittstelle eingerichtet wird, wenn der Netzwerkdienst verfügbar ist und bei jedem Reboot automatisch gestartet wird.

Falls Sie das Gerät selbst steuern müssen (und das automatische Starten vermeiden möchten) legen Sie manual für STARTMODE fest.

2

Legt eine statische IP-Adresse fest (hier 192.168.1.1 für IPv4 und fd00:deca:fbad:50::1 für IPv6).

Wenn das Netzwerk-Teaming-Gerät eine dynamische IP-Adresse verwenden soll, legen Sie BOOTPROTO="dhcp" fest und entfernen (oder kommentieren) Sie die Zeile mit IPADDRESS und IPADDR6.

3

Stellt TEAM_RUNNER auf loadbalance ein und aktiviert damit den Lastausgleichsmodus.

4

Gibt ein oder mehrere Geräte an, die aggregiert werden sollen, um das Netzwerk-Teaming-Gerät zu bilden.

5

Definiert eine Verbindungsüberwachung, die den Status der untergeordneten Geräte überwacht. Mit dem Standardwert ethtool wird nur überprüft, ob das Gerät aktiv und erreichbar ist. Hierdurch erfolgt die Überprüfung recht schnell. Jedoch wird nicht überprüft, ob das Gerät wirklich Pakete senden und empfangen kann.

Wenn Sie wirklich sicher sein müssen, dass die Verbindung einwandfrei funktioniert, verwenden Sie die Option arp_ping. Damit werden Ping-Signale an einen beliebigen Host gesendet (in der Variablen TEAM_LW_ARP_PING_TARGET_HOST konfiguriert). Das Netzwerk-Teaming-Gerät gilt nur dann als funktionsfähig, wenn Antworten empfangen werden.

6

Definiert die Verzögerung in Millisekunden zwischen dem Verbindungsaufbau (oder -abbau) und der Benachrichtigung des Runner.

19.8.2 Anwendungsfall: Failover bei Netzwerk-Teaming

 

Failover wird verwendet, um eine hohe Verfügbarkeit kritischer Netzwerk-Teaming-Geräte sicherzustellen, indem ein paralleles Sicherungsnetzwerkgerät verwendet wird. Das Sicherungsnetzwerkgerät ist ständig aktiv und übernimmt die Funktionen, wenn das Hauptgerät ausfällt.

Verwenden Sie die folgende Konfigurationsdatei zum Erstellen eines Netzwerk-Teaming-Geräts mit Failover-Funktionen. Fahren Sie mit Prozedur 19.1, „Allgemeines Verfahren“ fort, um das Gerät einzurichten. Überprüfen Sie die Ausgabe mit teamdctl.

Beispiel 19.13: Konfiguration für DHCP-Netzwerk-Teaming-Gerät
 
STARTMODE=auto 1
BOOTPROTO=static 2
IPADDR="192.168.1.2/24" 2
IPADDR6="fd00:deca:fbad:50::2/64" 2

TEAM_RUNNER=activebackup 3
TEAM_PORT_DEVICE_0="eth0" 4
TEAM_PORT_DEVICE_1="eth1" 4

TEAM_LW_NAME=ethtool 5
TEAM_LW_ETHTOOL_DELAY_UP="10" 6
TEAM_LW_ETHTOOL_DELAY_DOWN="10" 6

1

Steuert das Starten des Teaming-Geräts. Wert auto bedeutet, dass die Schnittstelle eingerichtet wird, wenn der Netzwerkdienst verfügbar ist, und bei jedem Reboot automatisch gestartet wird.

Falls Sie das Gerät selbst steuern müssen (und das automatische Starten vermeiden möchten) legen Sie manual für STARTMODE fest.

2

Legt eine statische IP-Adresse fest (hier 192.168.1.2 für IPv4 und fd00:deca:fbad:50::2 für IPv6).

Wenn das Netzwerk-Teaming-Gerät eine dynamische IP-Adresse verwenden soll, legen Sie BOOTPROTO="dhcp" fest und entfernen (oder kommentieren) Sie die Zeile mit IPADDRESS und IPADDR6.

3

Stellt TEAM_RUNNER auf activebackup ein und aktiviert damit den Failover-Modus.

4

Gibt ein oder mehrere Geräte an, die aggregiert werden sollen, um das Netzwerk-Teaming-Gerät zu bilden.

5

Definiert eine Verbindungsüberwachung, die den Status der untergeordneten Geräte überwacht. Mit dem Standardwert ethtool wird nur überprüft, ob das Gerät aktiv und erreichbar ist. Hierdurch erfolgt die Überprüfung recht schnell. Jedoch wird nicht überprüft, ob das Gerät wirklich Pakete senden und empfangen kann.

Wenn Sie wirklich sicher sein müssen, dass die Verbindung einwandfrei funktioniert, verwenden Sie die Option arp_ping. Damit werden Ping-Signale an einen beliebigen Host gesendet (in der Variablen TEAM_LW_ARP_PING_TARGET_HOST konfiguriert). Nur, wenn die Antworten empfangen werden, wird das Netzwerk-Teaming-Gerät als aktiv betrachtet.

6

Definiert die Verzögerung in Millisekunden zwischen dem Verbindungsaufbau (oder -abbau) und der Benachrichtigung des Runner.

19.8.3 Anwendungsfall: VLAN zusätzlich zu Teamgerät

 

VLAN ist eine Abkürzung für Virtual Local Area Network (virtuelles lokales Netzwerk). Es ermöglicht die Ausführung mehrerer logischer (virtueller) Ethernets über ein einzelnes physisches Ethernet. Es teilt das Netzwerk in verschiedene Broadcast-Domänen auf, sodass Pakete nur zwischen den Ports, die für dasselbe VLAN bestimmt sind, umgeschaltet werden müssen.

Im nachfolgenden Anwendungsfall werden zwei statische VLANs zusätzlich zu einem Teamgerät angelegt:

  • vlan0, an die IP-Adresse 192.168.10.1 gebunden

  • vlan1, an die IP-Adresse 192.168.20.1 gebunden

Führen Sie dazu die folgenden Schritte aus:

  1. Aktivieren Sie die VLAN-Tags am Switch. Soll der Lastausgleich für das Teaming-Gerät vorgenommen werden, muss der Switch das LACP (Link Aggregation Control Protocol) (802.3ad) unterstützen. Weitere Informationen finden Sie im Hardware-Handbuch.

  2. Legen Sie fest, ob ein Lastausgleich oder ein Failover für das Teamgerät verwendet werden soll. Richten Sie das Teamgerät gemäß den Anweisungen unter Abschnitt 19.8.1, „Anwendungsfall: Lastausgleich bei Netzwerk-Teaming“ oder Abschnitt 19.8.2, „Anwendungsfall: Failover bei Netzwerk-Teaming“ ein.

  3. Erstellen Sie unter /etc/sysconfig/network die Datei ifcfg-vlan0 mit folgendem Inhalt: 

    STARTMODE="auto"
BOOTPROTO="static" 1
IPADDR='192.168.10.1/24' 2
ETHERDEVICE="team0" 3
VLAN_ID="0" 4
VLAN='yes'

    1

    Definiert eine feste IP-Adresse, angegeben in IPADDR.

    2

    Definiert die IP-Adresse, hier mit der Netzmaske.

    3

    Enthält die eigentliche Schnittstelle für die VLAN-Schnittstelle, hier das Teamgerät (team0).

    4

    Gibt eine eindeutige ID für das VLAN an. Vorzugsweise entsprechen der Dateiname und die VLAN_ID dem Namen ifcfg-vlanVLAN_ID. In diesem Fall ist VLAN_ID gleich 0, sodass der Dateiname ifcfg-vlan0 entsteht.

  4. Kopieren Sie die Datei /etc/sysconfig/network/ifcfg-vlan0 in /etc/sysconfig/network/ifcfg-vlan1 und ändern Sie die folgenden Werte:

    • IPADDR von 192.168.10.1/24 zu 192.168.20.1/24.

    • VLAN_ID von 0 zu 1.

  5. Starten Sie die beiden VLANs: 

    root # wicked ifup vlan0 vlan1

  6. Prüfen Sie die Ausgabe von ifconfig: 

    root # ifconfig -a
[...]
vlan0     Link encap:Ethernet  HWaddr 08:00:27:DC:43:98
          inet addr:192.168.10.1 Bcast:192.168.10.255 Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fedc:4398/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 b)  TX bytes:816 (816.0 b)

vlan1     Link encap:Ethernet  HWaddr 08:00:27:DC:43:98
          inet addr:192.168.20.1 Bcast:192.168.20.255 Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fedc:4398/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 b)  TX bytes:816 (816.0 b)

19.9 Softwaredefiniertes Networking mit Open vSwitch

 

Softwaredefiniertes Networking (SDN) bedeutet eine Trennung des Systems, das steuert, wohin der Datenverkehrs gesendet wird (die Steuerebene), vom zugrunde liegenden System, das den Datenverkehr zum ausgewählten Ziel weiterleitet (die Datenebene, auch Weiterleitungsebene genannt). Dies bedeutet, dass die Funktionen, die zuvor von einem einzelnen, in der Regel nicht flexiblen, Switch erbracht wurden, jetzt zwischen einem Switch (Datenebene) und seinem Controller (Steuerebene) aufgeteilt werden können. In diesem Modell ist der Controller programmierbar und funktioniert sehr flexibel und passt sich schnell an sich ändernde Netzwerkbedingungen an.

Open vSwitch ist eine Software, die einen verteilten Switch mit mehreren Ebenen implementiert, der mit dem OpenFlow-Protokoll kompatibel ist. OpenFlow erlaubt es einer Controller-Anwendung, die Konfiguration eines Switch zu bearbeiten. OpenFlow baut als Ebene auf dem TCP-Protokoll auf und wird in einer Reihe von Hardware und Software implementiert. Ein einzelner Controller kann daher mehrere, sehr unterschiedliche Switches unterstützen.

19.9.1 Vorteile von Open vSwitch

 

Softwaredefiniertes Networking mit Open vSwitch bietet einige Vorteile, vor allem wenn es gemeinsam mit virtuellen Computern verwendet wird:

  • Networking-Zustände können einfach identifiziert werden.

  • Netzwerke und ihre Live-Zustände können von einem Host auf einen anderen übertragen werden.

  • Netzwerkdynamiken sind nachverfolgbar und externe Software kann dafür konfiguriert werden, auf diese zu antworten.

  • Sie können Tags in Netzwerkpaketen anwenden und so einstellen, dass sie identifizieren, von welchem bzw. an welchen Computer sie gesendet werden, und andere Netzwerkkontexte verwalten. Zuweisungsregeln für Tags können konfiguriert und migriert werden.

  • Open vSwitch implementiert das GRE-Protokoll (Generic Routing Encapsulation). Dies erlaubt es Ihnen beispielsweise, private Netzwerke virtueller Computer miteinander zu verbinden.

  • Open vSwitch kann eigenständig verwendet werden, ist jedoch für die Integration mit Networking-Hardware konzipiert und kann Hardware-Switches steuern.

19.9.2 Installieren von Open vSwitch

 

  1. Installieren Sie Open vSwitch und ergänzende Pakete: 

    root # zypper install openvswitch openvswitch-switch

    Wenn Sie Open vSwitch zusammen mit dem KVM-Hypervisor verwenden möchten, installieren Sie zusätzlich tunctl . Wenn Sie Open vSwitch zusammen mit dem Xen-Hypervisor verwenden möchten, installieren Sie zusätzlich openvswitch-kmp-xen .

  2. Aktivieren Sie den Open vSwitch-Dienst: 

    root # systemctl enable openvswitch

  3. Starten Sie entweder den Computer neu oder verwenden Sie systemctl, um den Open vSwitch-Dienst sofort zu starten: 

    root # systemctl start openvswitch

  4. Um zu überprüfen, ob Open vSwitch richtig aktiviert wurde, verwenden Sie das Kommando: 

    root # systemctl status openvswitch

19.9.3 Überblick über Open vSwitch-Daemons und -Dienstprogramme

 

Open vSwitch besteht aus mehreren Komponenten. Hierzu gehören ein Kernel-Modul und verschiedenste Userspace-Komponenten. Das Kernel-Modul wird zur Beschleunigung des Datenpfads verwendet, ist für eine Minimalinstallation von Open vSwitch jedoch nicht erforderlich.

19.9.3.1 Daemons

 

Die zentralen ausführbaren Dateien von Open vSwitch sind die zugehörigen zwei Daemons. Wenn Sie den openvswitch-Dienst starten, starten Sie die Daemons indirekt.

Der Haupt-Daemon (ovs-vswitchd) von Open vSwitch stellt die Implementierung eines Switch bereit. Der Datenbank-Daemon (ovsdb-server) von Open vSwitch dient der Datenbank, in der die Konfiguration und der Zustand von Open vSwitch gespeichert werden.

19.9.3.2 Dienstprogramme

 

Open vSwitch wird außerdem mit mehreren Dienstprogrammen bereitgestellt, die die Arbeit damit vereinfachen. Die folgende Liste ist nicht vollständig, es werden nur die wichtigsten Kommandos beschrieben.

ovsdb-tool

Open vSwitch-Datenbanken erstellen, upgraden, komprimieren und abfragen. Transaktionen auf Open vSwitch-Datenbanken durchführen.

ovs-appctl

Einen aktiven ovs-vswitchd- oder ovsdb-server-Daemon konfigurieren.

ovs-dpctl, ovs-dpctl-top

Datenpfade erstellen, bearbeiten, visualisieren und löschen. Die Verwendung dieses Werkzeugs kann zu einem Konflikt mit ovs-vswitchd führen, wenn dieser auch Datenpfade verwaltet. Daher wird es oft nur zu Diagnostikzwecken verwendet.

ovs-dpctl-top erstellt eine Visualisierung ähnlich wie top- für Datenpfade.

ovs-ofctl

Alle Switches verwalten, die dem OpenFlow-Protokoll unterliegen. ovs-ofctl ist nicht auf die Interaktion mit Open vSwitch beschränkt.

ovs-vsctl

Bietet eine Schnittstelle auf höchster Ebene für die Konfigurationsdatenbank. Sie kann zum Abfragen und Bearbeiten der Datenbank verwendet werden. Konkret zeigt sie den Zustand von ovs-vswitchd und kann zur Konfiguration verwendet werden.

19.9.4 Erstellen einer Bridge mit Open vSwitch

 

In der folgenden Beispielkonfiguration wird der Wicked-Netzwerkdienst standardmäßig auf SUSE Linux Enterprise Server verwendet. Weitere Informationen zu Wicked finden Sie unter Abschnitt 19.5, „Manuelle Netzwerkkonfiguration“.

Wenn Sie Open vSwitch installiert und gestartet haben, gehen Sie wie folgt vor:

  1. Um eine Bridge zur Verwendung durch Ihren virtuellen Computer zu konfigurieren, erstellen Sie eine Datei mit folgendem Inhalt: 

    STARTMODE='auto'1
BOOTPROTO='dhcp'2
OVS_BRIDGE='yes'3
OVS_BRIDGE_PORT_DEVICE_1='eth0'4

    1

    Richten Sie die Bridge automatisch ein, wenn der Netzwerkdienst gestartet wird.

    2

    Das zu verwendende Protokoll für die Konfiguration der IP-Adresse.

    3

    Kennzeichnen Sie die Konfiguration als Open vSwitch-Bridge.

    4

    Wählen Sie aus, welche(s) Gerät(e) zur Bridge hinzugefügt werden soll(en). Um mehr Geräte hinzuzufügen, fügen Sie zusätzliche Zeilen für jedes der Geräte in der Datei hinzu: 

    OVS_BRIDGE_PORT_DEVICE_SUFFIX='DEVICE'

    Das SUFFIX kann eine beliebige alphanummerische Zeichenfolge darstellen. Stellen Sie jedoch sicher, dass das SUFFIX für jedes Gerät eindeutig ist, um das Überschreiben einer vorherigen Definition zu vermeiden.

    Speichern Sie die Datei im Verzeichnis /etc/sysconfig/network mit dem Namen ifcfg-br0. Anstelle von br0 können Sie jeden beliebigen Namen verwenden. Jedoch muss der Dateiname mit ifcfg- beginnen.

    Informationen zu weiteren Optionen finden Sie auf den man-Seiten von ifcfg (man 5 ifcfg) und ifcfg-ovs-bridge (man 5 ifcfg-ovs-bridge).

  2. Starten Sie nun die Bridge: 

    root # wicked ifup br0

    Wenn Wicked fertig ist, sollte es den Namen der Bridge und daneben den Zustand up ausgeben.

19.9.5 Verwenden von Open vSwitch direkt mit KVM

 

Nach dem Erstellen der Bridge (wie in Abschnitt 19.9.4, „Erstellen einer Bridge mit Open vSwitch“ beschrieben) können Sie Open vSwitch zum Verwalten des Netzwerkzugriffs auf virtuelle Computer verwenden, die mit KVM/QEMU erstellt wurden.

  1. Um die Möglichkeiten von Wicked am besten nutzen zu können, führen Sie weitere Änderungen an der zuvor konfigurierten Bridge durch. Öffnen Sie die zuvor erstellte Datei /etc/sysconfig/network/ifcfg-br0 und fügen Sie eine Zeile für ein weiteres Port-Gerät hinzu: 

    OVS_BRIDGE_PORT_DEVICE_2='tap0'

    Legen Sie zusätzlich für BOOTPROTO den Wert none fest. Die Datei sollte nun wie folgt aussehen: 

    STARTMODE='auto'
BOOTPROTO='none'
OVS_BRIDGE='yes'
OVS_BRIDGE_PORT_DEVICE_1='eth0'
OVS_BRIDGE_PORT_DEVICE_2='tap0'

    Das neue Port-Gerät tap0 wird im nächsten Schritt konfiguriert.

  2. Fügen Sie nun eine Konfigurationsdatei für das Gerät tap0 hinzu: 

    STARTMODE='auto'
BOOTPROTO='none'
TUNNEL='tap'

    Speichern Sie die Datei im Verzeichnis /etc/sysconfig/network mit dem Namen ifcfg-tap0.

    Tipp
    Tipp: Anderen Benutzern den Zugriff auf das Tap-Gerät erlauben

    Um dieses Tap-Gerät über einen virtuellen Computer verwenden zu können, der als Benutzer ohne root-Berechtigungen gestartet wurde, fügen Sie Folgendes hinzu: 

    TUNNEL_SET_OWNER=USER_NAME

    Um den Zugriff für eine ganze Gruppe zu erlauben, fügen Sie Folgendes hinzu: 

    TUNNEL_SET_GROUP=GROUP_NAME

  3. Öffnen Sie schließlich die Konfiguration für das Gerät, das als das erste OVS_BRIDGE_PORT_DEVICE-Gerät definiert ist. Wenn Sie den Namen nicht geändert haben, sollte dies eth0 sein. Öffnen Sie daher /etc/sysconfig/network/ifcfg-eth0 und stellen Sie sicher, dass die folgenden Optionen festgelegt sind: 

    STARTMODE='auto'
BOOTPROTO='none'

    Wenn die Datei noch nicht vorhanden ist, erstellen Sie sie.

  4. Starten Sie die Bridge-Schnittstelle mithilfe von Wicked neu: 

    root # wicked ifreload br0

    Dies löst auch das erneute Laden der neu definierten Bridge-Port-Geräte aus.

  5. Verwenden Sie zum Starten eines virtuellen Computers beispielsweise: 

    root # qemu-kvm \
-drive file=/PATH/TO/DISK-IMAGE1 \
-m 512 -net nic,vlan=0,macaddr=00:11:22:EE:EE:EE \
-net tap,ifname=tap0,script=no,downscript=no2

    1

    Pfad zum QEMU-Laufwerksabbild, das Sie starten möchten.

    2

    Verwenden Sie das zuvor erstellte Tap-Gerät (tap0).

    Weitere Informationen zur Verwendung von KVM/QEMU finden Sie im Book “Virtualization Guide”.

19.9.6 Verwenden von Open vSwitch mit libvirt

 

Nach Erstellen der Bridge, wie zuvor in Abschnitt 19.9.4, „Erstellen einer Bridge mit Open vSwitch“ beschrieben, können Sie die Bridge zu einem vorhandenen virtuellen Computer hinzufügen, der mit libvirt verwaltet wird. Da libvirt Open vSwitch-Bridges bereits teilweise unterstützt, können Sie die in Abschnitt 19.9.4, „Erstellen einer Bridge mit Open vSwitch“ erstellte Bridge ohne weitere Änderungen an der Networking-Konfiguration verwenden.

  1. Öffnen Sie die Domänen-XML-Datei für den gewünschten virtuellen Computer: 

    root # virsh edit VM_NAME

    Ersetzen Sie VM-NAME durch den Namen des gewünschten virtuellen Computers. Hiermit wird Ihr Standardtexteditor geöffnet.

  2. Suchen Sie nach einem Abschnitt, der mit <interface type="..."> beginnt und mit </interface> endet, um den Networking-Abschnitt des Dokuments zu finden.

    Ersetzen Sie den vorhandenen Abschnitt durch einen Networking-Abschnitt, der etwa so aussieht: 

    <interface type='bridge'>
  <source bridge='br0'/>
  <virtualport type='openvswitch'/>
</interface>
    Wichtig
    Wichtig: Kompatibilität von virsh iface-* und Virtual Machine Manager mit Open vSwitch

    Zurzeit wird die Open vSwitch-Kompatibilität von libvirt nicht über die virsh iface-*-Werkzeuge und Virtual Machine Manager verfügbar gemacht. Wenn Sie eines dieser Werkzeuge verwenden, kann die Konfiguration beschädigt werden.

  3. Sie können die virtuellen Computer nun wie üblich starten oder neu starten.

Weitere Informationen zur Verwendung von libvirt finden Sie im Book “Virtualization Guide”.

19.9.7 Weitere Informationen

 
https://docs.openvswitch.org/en/latest/#documentation

Dokumentationsabschnitt der Open vSwitch-Projekt-Website

https://www.opennetworking.org/images/stories/downloads/sdn-resources/white-papers/wp-sdn-newnorm.pdf

Whitepaper der Open Networking Foundation zum softwaredefinierten Networking und zum OpenFlow-Protokoll

20 Druckerbetrieb

 

SUSE® Linux Enterprise Server unterstützt zahlreiche Druckermodelle (auch entfernte Netzwerkdrucker). Drucker können manuell oder mit YaST konfiguriert werden. Anleitungen zur Konfiguration finden Sie im Book “Bereitstellungshandbuch”, Chapter 20 “Einrichten von Hardwarekomponenten mit YaST”, Section 20.3 “Einrichten eines Druckers”. Grafische Dienstprogramme und Dienstprogramme an der Kommandozeile sind verfügbar, um Druckaufträge zu starten und zu verwalten. Wenn Ihr Drucker nicht wie erwartet verwendet werden kann, lesen Sie die Informationen unter Abschnitt 20.8, „Fehlersuche“.

Das Standarddrucksystem in SUSE Linux Enterprise Server ist CUPS (Common Unix Printing System).

Drucker können nach Schnittstelle, z. B. USB oder Netzwerk, und nach Druckersprache unterschieden werden. Stellen Sie beim Kauf eines Druckers sicher, dass dieser über eine von der Hardware unterstützte Schnittstelle (USB, Ethernet oder WLAN) und über eine geeignete Druckersprache verfügt. Drucker können basierend auf den folgenden drei Klassen von Druckersprachen kategorisiert werden:

PostScript-Drucker

PostScript ist die Druckersprache, in der die meisten Druckaufträge unter Linux und Unix vom internen Drucksystem generiert und verarbeitet werden. Wenn PostScript-Dokumente direkt vom Drucker verarbeitet und im Drucksystem nicht in weiteren Phasen konvertiert werden müssen, reduziert sich die Anzahl der möglichen Fehlerquellen.

Derzeit wird PostScript von PDF als Standardformat für Druckaufträge abgelöst. PostScript+PDF-Drucker, die PDF-Dateien (neben PostScript-Dateien) direkt drucken können, sind bereits am Markt erhältlich. Bei herkömmlichen PostScript-Druckern müssen PDF-Dateien während des Druck-Workflows in PostScript konvertiert werden.

Standarddrucker (Sprachen wie PCL und ESC/P)

Bei den bekannten Druckersprachen kann das Drucksystem PostScript-Druckaufträge mit Ghostscript in die entsprechende Druckersprache konvertieren. Diese Verarbeitungsphase wird als "Interpretieren" bezeichnet. Die gängigsten Sprachen sind PCL (die am häufigsten auf HP-Druckern und ihren Klonen zum Einsatz kommt) und ESC/P (die bei Epson-Druckern verwendet wird). Diese Druckersprachen werden in der Regel von Linux unterstützt und liefern ein adäquates Druckergebnis. Linux ist unter Umständen nicht in der Lage, einige spezielle Druckerfunktionen anzusprechen. Mit Ausnahme von HP und Epson gibt es derzeit keinen Druckerhersteller, der Linux-Treiber entwickeln und sie den Linux-Distributoren unter einer Open-Source-Lizenz zur Verfügung stellen würde.

Proprietäre Drucker (auch GDI-Drucker genannt)

Diese Drucker unterstützen keine der gängigen Druckersprachen. Sie verwenden eigene, undokumentierte Druckersprachen, die geändert werden können, wenn neue Versionen eines Modells auf den Markt gebracht werden. Für diese Drucker sind in der Regel nur Windows-Treiber verfügbar. Weitere Informationen zu diesem Thema finden Sie unter dem Stichwort Abschnitt 20.8.1, „Drucker ohne Unterstützung für eine Standard-Druckersprache“.

Vor dem Kauf eines neuen Druckers sollten Sie anhand der folgenden Quellen prüfen, wie gut der Drucker, den Sie zu kaufen beabsichtigen, unterstützt wird:

http://www.openprinting.org/printers

Die OpenPrinting-Homepage mit der Druckerdatenbank. In der Online-Datenbank wird der neueste Linux-Supportstatus angezeigt. Eine Linux-Distribution kann jedoch immer nur die zur Produktionszeit verfügbaren Treiber enthalten. Demnach ist es möglich, dass ein Drucker, der aktuell als „vollständig unterstützt“ eingestuft wird, diesen Status bei der Veröffentlichung der neuesten SUSE Linux Enterprise Server-Version nicht aufgewiesen hat. Die Datenbank gibt daher nicht notwendigerweise den richtigen Status, sondern nur eine Annäherung an diesen an.

http://pages.cs.wisc.edu/~ghost/

Die Ghostscript-Website

/usr/share/doc/packages/ghostscript/catalog.devices

Liste inbegriffener Ghostscript-Treiber.

20.1 Der CUPS-Workflow

 

Der Benutzer erstellt einen Druckauftrag. Der Druckauftrag besteht aus den zu druckenden Daten plus Informationen für den Spooler. Hierzu gehören der Name des Druckers oder der Druckerwarteschlange sowie (optional) Angaben für den Filter, z. B. druckerspezifische Optionen.

Mindestens eine zugeordnete Druckerwarteschlange ist für jeden Drucker vorhanden. Der Spooler hält den Druckauftrag in der Warteschlange, bis der gewünschte Drucker bereit ist, Daten zu empfangen. Wenn der Drucker druckbereit ist, sendet der Spooler die Daten über den Filter und das Backend an den Drucker.

Der Filter konvertiert die von der druckenden Anwendung generierten Daten (in der Regel PostScript oder PDF, aber auch ASCII, JPEG usw.) in druckerspezifische Daten (PostScript, PCL, ESC/P usw.). Die Funktionen des Druckers sind in den PPD-Dateien beschrieben. Eine PPD-Datei enthält druckspezifische Optionen mit den Parametern, die erforderlich sind, um die Optionen auf dem Drucker zu aktivieren. Das Filtersystem stellt sicher, dass die vom Benutzer ausgewählten Optionen aktiviert werden.

Wenn Sie einen PostScript-Drucker verwenden, konvertiert das Filtersystem die Daten in druckerspezifische PostScript-Daten. Hierzu ist kein Druckertreiber erforderlich. Wenn Sie einen Nicht-PostScript-Drucker verwenden, konvertiert das Filtersystem die Daten in druckerspezifische Daten. Hierzu ist ein für den Drucker geeigneter Druckertreiber erforderlich. Das Back-End empfängt die druckerspezifischen Daten vom Filter und leitet sie an den Drucker weiter.

20.2 Methoden und Protokolle zum Anschließen von Druckern

 

Es gibt mehrere Möglichkeiten, einen Drucker an das System anzuschließen. Die Konfiguration von CUPS unterscheidet nicht zwischen einem lokalen Drucker und einem Drucker, der über das Netzwerk an das System angeschlossen ist. Weitere Informationen zum Anschließen von Druckern finden Sie im Beitrag CUPS in aller Kürze unter https://en.opensuse.org/SDB:CUPS_in_a_Nutshell.

IBM Z Von der z/VM bereitgestellte Drucker und ähnliche Geräte, die lokal an IBM Z-Mainframes angeschlossen werden, werden von CUPS nicht unterstützt. Auf diesen Plattformen ist das Drucken nur über das Netzwerk möglich. Die Kabel für Netzwerkdrucker müssen gemäß den Anleitungen des Druckerherstellers angeschlossen werden.

Warnung
Warnung: Ändern der Anschlüsse bei einem laufenden System

Vergessen Sie beim Anschließen des Druckers an den Computer nicht, dass während des Betriebs nur USB-Geräte angeschlossen werden können. Um Ihr System oder Ihren Drucker vor Schaden zu bewahren, fahren Sie das System herunter, wenn Sie Verbindungen ändern müssen, die keine USB-Verbindungen sind.

20.3 Installation der Software

 

PPD (PostScript Printer Description, PostScript-Druckerbeschreibung) ist die Computersprache, die die Eigenschaften, z. B. die Auflösung und Optionen wie die Verfügbarkeit einer Duplexeinheit, beschreibt. Diese Beschreibungen sind für die Verwendung der unterschiedlichen Druckeroptionen in CUPS erforderlich. Ohne eine PPD-Datei würden die Druckdaten in einem „rohen“ Zustand an den Drucker weitergeleitet werden, was in der Regel nicht erwünscht ist.

Um einen PostScript-Drucker zu konfigurieren, sollten Sie sich zunächst eine geeignete PPD-Datei beschaffen. Die Pakete manufacturer-PPDs und OpenPrintingPPDs-postscript enthalten zahlreiche PPD-Dateien. Weitere Informationen hierzu finden Sie unter Abschnitt 20.7.3, „PPD-Dateien in unterschiedlichen Paketen“ und Abschnitt 20.8.2, „Für einen PostScript-Drucker ist keine geeignete PPD-Datei verfügbar“.

Neue PPD-Dateien können im Verzeichnis /usr/share/cups/model/ gespeichert oder dem Drucksystem mit YaST hinzugefügt werden (siehe Book “Bereitstellungshandbuch”, Chapter 20 “Einrichten von Hardwarekomponenten mit YaST”, Section 20.3.1.1 “Hinzufügen von Treibern mit YaST”). Die PPD-Dateien lassen sich anschließend während der Druckereinrichtung auswählen.

Seien Sie vorsichtig, wenn Sie gleich ein ganzes Software-Paket eines Druckerherstellers installieren sollen. Durch eine solche Installation entfällt die Unterstützung durch SUSE Linux Enterprise Server. Außerdem funktionieren die Druckerkommandos unter Umständen anders und das System kann möglicherweise keine Geräte anderer Hersteller mehr adressieren. Aus diesem Grund wird das Installieren von Herstellersoftware nicht empfohlen.

20.4 Netzwerkdrucker

 

Ein Netzwerkdrucker kann unterschiedliche Protokolle unterstützen - einige sogar gleichzeitig. Die meisten unterstützten Protokolle sind standardisiert, und doch versuchen einige Hersteller, diesen Standard abzuändern. Treiber werden meist nur für einige wenige Betriebsssysteme angeboten. Linux-Treiber werden leider nur sehr selten zur Verfügung gestellt. Gegenwärtig können Sie nicht davon ausgehen, dass alle Protokolle problemlos mit Linux funktionieren. Um dennoch eine funktionale Konfiguration zu erhalten, müssen Sie daher möglicherweise mit den verschiedenen Optionen experimentieren.

CUPS unterstützt die Protokolle socket, LPD, IPP und smb.

socket

Socket bezeichnet eine Verbindung, über die die einfachen Druckdaten direkt an einen TCP-Socket gesendet werden. Einige der am häufigsten verwendeten Socket-Ports sind 9100 oder 35. Die Syntax der Geräte-URI (Uniform Resource Identifier) lautet: socket://IP.FÜR.DEN.DRUCKER:Port, beispielsweise: socket://192.168.2.202:9100/.

LPD (Line Printer Daemon)

Das LDP-Protokoll wird in RFC 1179 beschrieben. Bei diesem Protokoll werden bestimmte auftragsspezifische Daten (z. B. die ID der Druckerwarteschlange) vor den eigentlichen Druckdaten gesendet. Beim Konfigurieren des LDP-Protokolls muss daher eine Druckerwarteschlange angegeben werden. Die Implementierungen diverser Druckerhersteller sind flexibel genug, um beliebige Namen als Druckwarteschlange zu akzeptieren. Der zu verwendende Name müsste ggf. im Druckerhandbuch angegeben sein. Es werden häufig Bezeichnungen wie LPT, LPT1, LP1 o. ä. verwendet. Die Portnummer für einen LPD-Dienst lautet 515. Ein Beispiel für einen Gerät-URI ist lpd://192.168.2.202/LPT1.

IPP (Internet Printing Protocol)

IPP basiert auf dem HTTP-Protokoll. Mit IPP können mehr druckauftragsbezogene Daten übertragen werden als mit den anderen Protokollen. CUPS verwendet IPP für die interne Datenübertragung. Um IPP ordnungsgemäß konfigurieren zu können, ist der Name der Druckwarteschlange erforderlich. Die Portnummer für IPP lautet 631. Beispiele für Geräte-URIs sind ipp://192.168.2.202/ps und ipp://192.168.2.202/printers/ps.

SMB (Windows-Freigabe)

CUPS unterstützt auch das Drucken auf freigegebenen Druckern unter Windows. Das für diesen Zweck verwendete Protokoll ist SMB. SMB verwendet die Portnummern 137, 138 und 139. Beispiele für Geräte-URIs sind smb://Benutzer:Passwort@Arbeitsgruppe/smb.example.com/Drucker, smb://Benutzer:Passwort@smb.example.com/Drucker und smb://smb.example.com/Drucker.

Das vom Drucker unterstützte Protokoll muss vor der Konfiguration ermittelt werden. Wenn der Hersteller die erforderlichen Informationen nicht zur Verfügung stellt, können Sie das Protokoll mit dem Kommando nmap ermitteln, das Bestandteil des Pakets nmap ist. nmap überprüft einen Host auf offene Ports. Beispiel: 

tux > nmap -p 35,137-139,515,631,9100-10000 IP.OF.THE.PRINTER

20.5 Konfigurieren von CUPS mit Kommandozeilenwerkzeugen

 

CUPS kann mit Kommandozeilenwerkzeugen kofiguriert werden, beispielsweise lpinfo, lpadmin oder lpoptions. Sie benötigen einen Geräte-URI, der aus einem Back-End (z. B. USB) und Parametern besteht. Zum Bestimmen von gültigen Geräte- URIs auf Ihrem System verwenden Sie das Kommando lpinfo -v | grep „:/“: 

tux > sudo lpinfo -v | grep ":/"
direct usb://ACME/FunPrinter%20XL
network socket://192.168.2.253

Mit lpadmin kann der CUPS-Serveradministrator Druckerwarteschlangen hinzufügen, entfernen und verwalten. Verwenden Sie die folgende Syntax, um eine Druckwarteschlange hinzuzufügen: 

tux > sudo lpadmin -p QUEUE -v DEVICE-URI -P PPD-FILE -E

Das Gerät (-v) ist anschließend als WARTESCHLANGE (-p) verfügbar und verwendet die angegebene PPD-Datei (-P). Das bedeutet, dass Sie die PPD-Datei und das Geräte-URI kennen müssen, wenn Sie den Drucker manuell konfigurieren möchten.

Verwenden Sie nicht -E als erste Option. Für alle CUPS-Befehle legt die Option -E als erstes Argument die Verwendung einer verschlüsselten Verbindung fest. Zur Aktivierung des Druckers muss die Option -E wie im folgenden Beispiel dargestellt verwendet werden: 

tux > sudo lpadmin -p ps -v usb://ACME/FunPrinter%20XL -P \
/usr/share/cups/model/Postscript.ppd.gz -E

Im folgenden Beispiel wird ein Netzwerkdrucker konfiguriert: 

tux > sudo lpadmin -p ps -v socket://192.168.2.202:9100/ -P \
/usr/share/cups/model/Postscript-level1.ppd.gz -E

Weitere Optionen von lpadmin finden Sie auf der man-Seiten von lpadmin(8).

Während der Druckerkonfiguration werden bestimmte Optionen standardmäßig gesetzt. Diese Optionen können (je nach Druckwerkzeug) für jeden Druckauftrag geändert werden. Es ist auch möglich, diese Standardoptionen mit YaST zu ändern. Legen Sie die Standardoptionen mithilfe der Kommandozeilenwerkzeuge wie folgt fest:

  1. Zeigen Sie zunächst alle Optionen an: 

    tux > sudo lpoptions -p QUEUE -l

    Beispiel: 

    Resolution/Output Resolution: 150dpi *300dpi 600dpi

    Die aktivierte Standardoption wird durch einen vorangestellten Stern (*) gekennzeichnet.

  2. Ändern Sie die Option mit lpadmin: 

    tux > sudo lpadmin -p QUEUE -o Resolution=600dpi

  3. Prüfen Sie die neue Einstellung: 

    tux > sudo lpoptions -p QUEUE -l

Resolution/Output Resolution: 150dpi 300dpi *600dpi

Wenn ein normaler Benutzer lpoptions ausführt, werden die Einstellungen in ~/.cups/lpoptions geschrieben. Jedoch werden die root-Einstellungen in to /etc/cups/lpoptions geschrieben.

20.6 Drucken über die Kommandozeile

 

Um den Druckvorgang über die Kommandozeile zu starten, geben Sie lp -d NAME_DER WARTESCHLANGE DATEINAME ein und ersetzen Sie die entsprechenden Namen für NAME_DER_WARTESCHLANGE und DATEINAME.

Einige Anwendungen erfordern für den Druckvorgang den Befehl lp. Geben Sie in diesem Fall den richtigen Befehl in das Druckdialogfeld der Anwendung ohne Angabe des DATEINAMENS ein, z. B. lp -d NAME_DER_WARTESCHLANGE.

20.7 Besondere Funktionen in SUSE Linux Enterprise Server

 

Mehrere CUPS-Funktionen wurden für SUSE Linux Enterprise Server angepasst. Im Folgenden werden einige der wichtigsten Änderungen beschrieben.

20.7.1 CUPS und Firewall

 

Nach einer Standardinstallation von SUSE Linux Enterprise Server ist firewalld aktiv und die Netzwerkschnittstellen werden so konfiguriert, dass sie sich in der öffentlichen Zone befinden, die eingehenden Datenverkehr blockiert.

Wenn firewalld aktiv ist, müssen Sie sie möglicherweise konfigurieren, damit Clients die Netzwerkdrucker durchsuchen können. Aktivieren Sie dazu mdns und ipp über die interne Netzwerkzone. Die öffentliche Zone sollte niemals Druckerwarteschlangen offenlegen.

(Weitere Informationen zur firewalld-Konfiguration finden Sie im Book “Security and Hardening Guide”, Chapter 23 “Masquerading and firewalls”, Section 23.4 “firewalld” und https://en.opensuse.org/SDB:CUPS_and_SANE_Firewall_settings.)

20.7.1.1 CUPS-Client

 

Normalerweise wird der CUPS-Client auf einem normalen Arbeitsplatzrechner ausgeführt, die sich in einer verbürgten Netzwerkumgebung hinter einer Firewall befindet. In diesem Fall empfiehlt es sich, die Netzwerkschnittstelle in der internen Zone zu konfigurieren, damit der Arbeitsplatzrechner innerhalb des Netzwerks erreichbar ist.

20.7.1.2 CUPS-Server

 

Wenn der CUPS-Server Teil der durch eine Firewall geschützten verbürgten Netzwerkumgebung ist, sollte die Netzwerkschnittstelle in der internen Zone der Firewall konfiguriert sein. Es ist nicht empfehlenswert, einen CUPS-Server in einer nicht verbürgten Netzwerkumgebung einzurichten, es sei denn, Sie sorgen dafür, dass er durch besondere Firewall-Regeln und Sicherheitseinstellungen in der CUPS-Konfiguration geschützt wird.

20.7.2 Durchsuchen nach Netzwerkdruckern

 

CUPS-Server geben regelmäßig die Verfügbarkeit und die Statusinformationen von freigegebenen Druckern im Netzwerk bekannt. Die Clients können auf diese Informationen zugreifen und beispielsweise in Druckdialogfeldern eine Liste der verfügbaren Drucker anzeigen. Dies wird als „Browsing“ (Durchsuchen) bezeichnet.

Die CUPS-Server geben ihre Druckerwarteschlangen entweder über das herkömmliche CUPS-Browsing-Protokoll oder über Bonjour/DND-SD im Netzwerk bekannt. Um Netzwerkdruckerwarteschlangen zu aktivieren, muss der Dienst cups-browsed auf allen Clients ausgeführt werden, die über CUPS-Server drucken. cups-browsed wird standardmäßig nicht gestartet. Zum Starten für die aktuelle Sitzung führen Sie den Befehl sudo systemctl start cups-browsed aus. Damit der Dienst nach dem Booten automatisch gestartet wird, aktivieren Sie ihn mit dem Befehl sudo systemctl enable cups-browsed auf allen Clients.

Falls das Durchsuchen nach dem Starten von cups-browsed nicht funktioniert, geben der oder die CUPS-Server die Netzwerkdrucker-Warteschlangen vermutlich über Bonjour/DND-SD bekannt. In diesem Fall müssen Sie zusätzlich das Paket avahi installieren und den zugehörigen Dienst mit sudo systemctl start avahi-daemon auf allen Clients starten.

In Abschnitt 20.7.1, „CUPS und Firewall“ finden Sie Informationen, wie das Durchsuchen von Druckern über firewalld zugelassen wird.

20.7.3 PPD-Dateien in unterschiedlichen Paketen

 

Die YaST-Druckerkonfiguration richtet die Warteschlangen für CUPS auf dem System mit den in /usr/share/cups/model/ installierten PPD-Dateien ein. Um die geeigneten PPD-Dateien für das Druckermodell zu finden, vergleicht YaST während der Hardware-Erkennung den Hersteller und das Modell mit den Herstellern und Modellen, die in den PPD-Dateien enthalten sind. Zu diesem Zweck generiert die YaST-Druckerkonfiguration eine Datenbank mit den Hersteller- und Modelldaten, die aus den PPD-Dateien extrahiert werden.

Die Konfiguration, die nur PPD-Dateien und keine weiteren Informationsquellen verwendet, hat den Vorteil, dass die PPD-Dateien in /usr/share/cups/model/ beliebig geändert werden können. Wenn Sie beispielsweise PostScript-Drucker nutzen, können die PPD-Dateien direkt in /usr/share/cups/model/ kopiert werden (wenn sie nicht bereits im Paket manufacturer-PPDs oder OpenPrintingPPDs-postscript vorhanden sind), um eine optimale Konfiguration der Drucker zu erzielen.

Weitere PPD-Dateien erhalten Sie mit den folgenden Paketen:

  • gutenprint:: der Gutenprint-Treiber und zugehörige PPDs

  • splix:: der Splix-Treiber und zugehörige PPDs

  • OpenPrintingPPDs-ghostscript: PPDs für integrierte Ghostscript-Treiber

  • OpenPrintingPPDs-hpijs: PPDs für den HPIJS-Treiber für Drucker, die nicht von HP stammen

20.8 Fehlersuche

 

In den folgenden Abschnitten werden einige der am häufigsten auftretenden Probleme mit der Druckerhardware und -software sowie deren Lösungen oder Umgehung beschrieben. Unter anderem werden die Themen GDI-Drucker, PPD-Dateien und Port-Konfiguration behandelt. Darüber hinaus werden gängige Probleme mit Netzwerkdruckern, fehlerhafte Ausdrucke und die Bearbeitung der Warteschlange erläutert.

20.8.1 Drucker ohne Unterstützung für eine Standard-Druckersprache

 

Diese Drucker unterstützen keine der geläufigen Druckersprachen und können nur mit proprietären Steuersequenzen adressiert werden. Daher funktionieren sie nur mit den Betriebssystemversionen, für die der Hersteller einen Treiber zur Verfügung stellt. GDI ist eine von Microsoft für Grafikgeräte entwickelte Programmierschnittstelle. In der Regel liefert der Hersteller nur Treiber für Windows, und da Windows-Treiber die GDI-Schnittstelle verwenden, werden diese Drucker auch GDI-Drucker genannt. Das eigentliche Problem ist nicht die Programmierschnittstelle, sondern die Tatsache, dass diese Drucker nur mit der proprietären Druckersprache des jeweiligen Druckermodells adressiert werden können.

Der Betrieb einiger GDI-Drucker kann sowohl im GDI-Modus als auch in einer der Standard-Druckersprachen ausgeführt werden. Sehen Sie im Druckerhandbuch nach, ob dies möglich ist. Einige Modelle benötigen für diese Umstellung eine spezielle Windows-Software. (Beachten Sie, dass der Windows-Druckertreiber den Drucker immer zurück in den GDI-Modus schalten kann, wenn von Windows aus gedruckt wird). Für andere GDI-Drucker sind Erweiterungsmodule für eine Standarddruckersprache erhältlich.

Einige Hersteller stellen für ihre Drucker proprietäre Treiber zur Verfügung. Der Nachteil proprietärer Druckertreiber ist, dass es keine Garantie gibt, dass diese mit dem installierten Drucksystem funktionieren oder für die unterschiedlichen Hardwareplattformen geeignet sind. Im Gegensatz dazu sind Drucker, die eine Standard-Druckersprache unterstützen, nicht abhängig von einer speziellen Drucksystemversion oder einer bestimmten Hardwareplattform.

Anstatt viel Zeit darauf aufzuwenden, einen herstellerspezifischen Linux-Treiber in Gang zu bringen, ist es unter Umständen kostengünstiger, einen Drucker zu erwerben, der eine Standarddruckersprache unterstützt (vorzugsweise PostScript). Dadurch wäre das Treiberproblem ein für alle Mal aus der Welt geschafft und es wäre nicht mehr erforderlich, spezielle Treibersoftware zu installieren und zu konfigurieren oder Treiber-Updates zu beschaffen, die aufgrund neuer Entwicklungen im Drucksystem benötigt würden.

20.8.2 Für einen PostScript-Drucker ist keine geeignete PPD-Datei verfügbar

 

Wenn das Paket manufacturer-PPDs oder OpenPrintingPPDs-postscript für einen PostScript-Drucker keine geeignete PPD-Datei enthält, sollte es möglich sein, die PPD-Datei von der Treiber-CD des Druckerherstellers zu verwenden oder eine geeignete PPD-Datei von der Webseite des Druckerherstellers herunterzuladen.

Wenn die PPD-Datei als Zip-Archiv (.zip) oder als selbstextrahierendes Zip-Archiv <?dbsbr?>(.exe) zur Verfügung gestellt wird, entpacken Sie sie mit unzip. Lesen Sie zunächst die Lizenzvereinbarung für die PPD-Datei. Prüfen Sie dann mit dem Dienstprogramm cupstestppd, ob die PPD-Datei den Spezifikationen „Adobe PostScript Printer Description File Format Specification, Version 4.3.“ entspricht. Wenn das Dienstprogramm „FAIL“ zurückgibt, sind die Fehler in den PPD-Dateien schwerwiegend und werden sehr wahrscheinlich größere Probleme verursachen. Die von cupstestppd protokollierten Problempunkte müssen behoben werden. Fordern Sie beim Druckerhersteller ggf. eine geeignete PPD-Datei an.

20.8.3 Netzwerkdrucker-Verbindungen

 
Netzwerkprobleme identifizieren

Schließen Sie den Drucker direkt an den Computer an. Konfigurieren Sie den Drucker zu Testzwecken als lokalen Drucker. Wenn dies funktioniert, werden die Probleme netzwerkseitig verursacht.

TCP/IP-Netzwerk prüfen

Das TCP/IP-Netzwerk und die Namensauflösung müssen funktionieren.

Entfernten lpd prüfen

Geben Sie den folgenden Befehl ein, um zu testen, ob zu lpd (Port 515) auf HOST eine TCP-Verbindung hergestellt werden kann: 

tux > netcat -z HOST 515 && echo ok || echo failed

Wenn die Verbindung zu lpd nicht hergestellt werden kann, ist lpd entweder nicht aktiv oder es liegen grundlegende Netzwerkprobleme vor.

Vorausgesetzt, dass lpd aktiv ist und der Host Abfragen akzeptiert, rufen Sie mit dem folgenden Befehl (als root) einen Statusbericht für WARTESCHLANGE auf dem Remote-HOST ab: 

root # echo -e "\004queue" \
| netcat -w 2 -p 722 HOST 515

Wenn lpd nicht antwortet, ist er entweder nicht aktiv oder es liegen grundlegende Netzwerkprobleme vor. Wenn lpd reagiert, sollte die Antwort zeigen, warum das Drucken in der queue auf host nicht möglich ist. Wenn Sie eine Antwort erhalten wie in Beispiel 20.1, „Fehlermeldung von lpd“ gezeigt, wird das Problem durch den entfernten lpd verursacht.

Beispiel 20.1: Fehlermeldung von lpd
 
lpd: your host does not have line printer access
lpd: queue does not exist
printer: spooling disabled
printer: printing disabled
Entfernten cupsd prüfen

Ein CUPS-Netzwerkserver kann die Warteschlangen standardmäßig alle 30 Sekunden per Broadcast über den UDP-Port 631 senden. Demzufolge kann mit dem folgenden Kommando getestet werden, ob im Netzwerk ein CUPS-Netzwerkserver mit aktivem Broadcast vorhanden ist. Stoppen Sie unbedingt Ihren lokalen CUPS-Daemon, bevor Sie das Kommando ausführen. 

tux > netcat -u -l -p 631 & PID=$! ; sleep 40 ; kill $PID

Wenn ein CUPS-Netzwerkserver vorhanden ist, der Informationen über Broadcasting sendet, erscheint die Ausgabe wie in Beispiel 20.2, „Broadcast vom CUPS-Netzwerkserver“ dargestellt.

Beispiel 20.2: Broadcast vom CUPS-Netzwerkserver
 
ipp://192.168.2.202:631/printers/queue

IBM Z Berücksichtigen Sie, dass IBM Z-Ethernetgeräte standardmäßig keine Broadcasts empfangen.

Mit dem folgenden Befehl können Sie testen, ob mit cupsd (Port 631) auf HOST eine TCP-Verbindung hergestellt werden kann: 

tux > netcat -z HOST 631 && echo ok || echo failed

Wenn die Verbindung zu cupsd nicht hergestellt werden kann, ist cupsd entweder nicht aktiv oder es liegen grundlegende Netzwerkprobleme vor. lpstat -h HOST -l -t gibt einen (möglicherweise sehr langen) Statusbericht für alle Warteschlangen auf dem HOST zurück, vorausgesetzt, dass cupsd aktiv ist und der Host Abfragen akzeptiert.

Mit dem nächsten Befehl können Sie testen, ob die WARTESCHLANGE auf HOST einen Druckauftrag akzeptiert, der aus einem einzigen CR-Zeichen (Carriage-Return) besteht. In diesem Fall sollte nichts gedruckt werden. Möglicherweise wird eine leere Seite ausgegeben. 

tux > echo -en "\r" \
| lp -d queue -h HOST
Fehlerbehebung für einen Netzwerkdrucker oder eine Print Server Machine

Spooler, die in einer Print Server Machine ausgeführt werden, verursachen gelegentlich Probleme, wenn sie mehrere Druckaufträge bearbeiten müssen. Da dies durch den Spooler in der Print Server Machine verursacht wird, gibt es keine Möglichkeit, dieses Problem zu beheben. Sie haben jedoch die Möglichkeit, den Spooler in der Print Server Machine zu umgehen, indem Sie den an die Print Server Machine angeschlossenen Drucker über den TCP-Socket direkt kontaktieren. Siehe Abschnitt 20.4, „Netzwerkdrucker“.

Auf diese Weise wird die Print Server Machine auf einen Konvertierer zwischen den unterschiedlichen Formen der Datenübertragung (TCP/IP-Netzwerk und lokale Druckerverbindung) reduziert. Um diese Methode verwenden zu können, müssen Sie den TCP-Port der Print Server Machine kennen. Wenn der Drucker eingeschaltet und an die Print Server Machine angeschlossen ist, kann dieser TCP-Port in der Regel mit dem Dienstprogramm nmap aus dem Paket nmap ermittelt werden, wenn die Print Server Machine einige Zeit eingeschaltet ist. Beispiel: nmap  IP-Adresse gibt die folgende Ausgabe für eine Print Server Machine zurück: 

Port       State       Service
23/tcp     open        telnet
80/tcp     open        http
515/tcp    open        printer
631/tcp    open        cups
9100/tcp   open        jetdirect

Diese Ausgabe gibt an, dass der an die Print Server Machine angeschlossenen Drucker über TCP-Socket an Port 9100 angesprochen werden kann. nmap prüft standardmäßig nur einige allgemein bekannte Ports, die in /usr/share/nmap/nmap-services aufgeführt sind. Um alle möglichen Ports zu überprüfen, verwenden Sie den Befehl nmap -p AUSGANGS-PORT-ZIEL-PORT IP-ADRESSE. Dies kann einige Zeit dauern. Weitere Informationen finden Sie auf der man-Seite zu ypbind.

Geben Sie einen Befehl ein wie 

tux > echo -en "\rHello\r\f" | netcat -w 1 IP-address port
cat file | netcat -w 1 IP-address port

um Zeichenketten oder Dateien direkt an den entsprechenden Port zu senden, um zu testen, ob der Drucker auf diesem Port angesprochen werden kann.

20.8.4 Fehlerhafte Ausdrucke ohne Fehlermeldung

 

Für das Drucksystem ist der Druckauftrag abgeschlossen, wenn das CUPS-Back-End die Datenübertragung an den Empfänger (Drucker) abgeschlossen hat. Wenn die weitere Verarbeitung auf dem Empfänger nicht erfolgt (z. B. wenn der Drucker die druckerspezifischen Daten nicht drucken kann), wird dies vom Drucksystem nicht erkannt. Wenn der Drucker die druckerspezifischen Daten nicht drucken kann, wählen Sie eine PPD-Datei, die für den Drucker besser geeignet ist.

20.8.5 Deaktivierte Warteschlangen

 

Wenn die Datenübertragung zum Empfänger auch nach mehreren Versuchen nicht erfolgreich ist, meldet das CUPS-Back-End, z. B. USB oder socket, dem Drucksystem (an cupsd) einen Fehler. Das Backend bestimmt, wie viele erfolglose Versuche angemessen sind, bis die Datenübertragung als unmöglich gemeldet wird. Da weitere Versuche vergeblich wären, deaktiviert cupsd das Drucken für die entsprechende Warteschlange. Nachdem der Systemadministrator das Problem behoben hat, muss er das Drucken mit dem Kommando cupsenable wieder aktivieren.

20.8.6 CUPS-Browsing: Löschen von Druckaufträgen

 

Wenn ein CUPS-Netzwerkserver seine Warteschlangen den Client-Hosts via Browsing bekannt macht und auf den Host-Clients ein geeigneter lokaler cupsd aktiv ist, akzeptiert der Client-cupsd Druckaufträge von Anwendungen und leitet sie an den cupsd auf dem Server weiter. Wenn cupsd auf dem Server einen Druckauftrag akzeptiert, wird diesem eine neue Auftragsnummer zugewiesen. Daher unterscheidet sich die Auftragsnummer auf dem Client-Host von der auf dem Server. Da ein Druckauftrag in der Regel sofort weitergeleitet wird, kann er mit der Auftragsnummer auf dem Client-Host nicht gelöscht werden. Dies liegt daran, dass der Client-cupsd den Druckauftrag als abgeschlossen betrachtet, wenn dieser an den Server-cupsd weitergeleitet wurde.

Soll der Druckauftrag auf dem Server gelöscht werden, ermitteln Sie die Auftragsnummer auf dem Server mit einem Kommando wie lpstat -h cups.example.com -o. Hierbei wird vorausgesetzt, dass der Server den Druckauftrag noch nicht erledigt (also noch nicht vollständig an den Drucker gesendet) hat. So löschen Sie den Druckauftrag anhand der abgerufenen Auftragsnummer auf dem Server: 

tux > cancel -h cups.example.com QUEUE-JOBNUMBER

20.8.7 Fehlerhafte Druckaufträge und Fehler bei der Datenübertragung

 

Wenn Sie während des Druckvorgangs den Drucker oder den Computer abschalten, bleiben Druckaufträge in der Warteschlange. Der Druckvorgang wird wieder aufgenommen, sobald der Computer (bzw. der Drucker) wieder eingeschaltet wird. Fehlerhafte Druckaufträge müssen mit cancel aus der Warteschlange entfernt werden.

Wenn ein Druckauftrag beschädigt ist oder ein Fehler bei der Datenübertragung zwischen Host und Drucker auftritt, kann der Drucker die Daten nicht ordnungsgemäß verarbeiten und es werden unzählige Blätter mit unlesbaren Zeichen bedruckt. So reparieren Sie dieses Problem:

  1. Um den Druckvorgang zu beenden, entfernen Sie das Papier aus Tintenstrahldruckern oder öffnen Sie die Papierzufuhr bei Laserdruckern. Qualitativ hochwertige Drucker sind mit einer Taste zum Abbrechen des aktuellen Druckauftrags ausgestattet.

  2. Der Druckauftrag befindet sich möglicherweise noch in der Warteschlange, da die Aufträge erst dann entfernt werden, wenn sie vollständig an den Drucker übertragen wurden. Geben Sie lpstat -o oder lpstat -h cups.example.com -o ein, um zu prüfen, über welche Warteschlange aktuell gedruckt wird. Löschen Sie den Druckauftrag mit cancel WARTESCHLANGE-AUFTRAGSNUMMER oder cancel -h cups.example.com WARTESCHLANGE-AUFTRAGSNUMMER.

  3. Auch wenn der Druckauftrag aus der Warteschlange gelöscht wurde, werden einige Daten weiter an den Drucker gesendet. Prüfen Sie, ob ein CUPS-Backend-Prozess für die entsprechende Warteschlange ausgeführt wird und wenn ja, beenden Sie ihn.

  4. Setzen Sie den Drucker vollständig zurück, indem Sie ihn für einige Zeit ausschalten. Legen Sie anschließend Papier ein und schalten Sie den Drucker wieder ein.

20.8.8 Fehlersuche für CUPS

 

Suchen Sie Probleme in CUPS mithilfe des folgenden generischen Verfahrens:

  1. Setzen Sie LogLevel debug in /etc/cups/cupsd.conf.

  2. Stoppen Sie cupsd.

  3. Entfernen Sie /var/log/cups/error_log*, um das Durchsuchen sehr großer Protokolldateien zu vermeiden.

  4. Starten Sie cupsd.

  5. Wiederholen Sie die Aktion, die zu dem Problem geführt hat.

  6. Lesen Sie die Meldungen in /var/log/cups/error_log*, um die Ursache des Problems zu identifizieren.

20.8.9 Weitere Informationen

 

Ausführliche Informationen zum Drucken unter SUSE Linux Enterprise Server finden Sie in der openSUSE-Supportdatenbank unter https://en.opensuse.org/Portal:Printing. Lösungen zu vielen spezifischen Problemen finden Sie in der SUSE Knowledgebase (https://www.suse.com/support/). Die relevanten Themen finden Sie am schnellsten mittels einer Textsuche nach CUPS.

21 Über die grafische Benutzeroberfläche

 

SUSE Linux Enterprise Server umfasst den X.org-Server und den GNOME-Desktop. In diesem Kapitel wird die Konfiguration der grafischen Benutzeroberfläche für alle Benutzer beschrieben.

21.1 X Window System

 

Der X.org-Server ist die allgemeine Norm für die Implementierung des X11-Protokolls. X ist netzwerkbasiert und ermöglicht es, auf einem Host gestartete Anwendungen auf einem anderen, über eine beliebige Art von Netzwerk (LAN oder Internet) verbundenen Host anzuzeigen.

In der Regel muss das X Window System nicht konfiguriert werden. Die Hardware wird beim Starten von X dynamisch erkannt. Die Nutzung von xorg.conf ist daher überholt. Wenn Sie die Funktionsweise von X dennoch mit benutzerdefinierten Optionen ändern möchten, können Sie die Konfigurationsdateien unter /etc/X11/xorg.conf.d/ entsprechend bearbeiten.

Tipp
Tipp: IBM Z: Konfigurieren der grafischen Benutzeroberfläche

IBM Z verfügt nicht über Eingabe- oder Ausgabegeräte, die von X.Org unterstützt werden, daher gelten keine der in diesem Abschnitt beschriebenen Vorgehensweisen für diese Systeme. Weitere relevante Informationen für IBM Z finden Sie im Book “Bereitstellungshandbuch”, Chapter 5 “Installation unter IBM Z und LinuxONE”.

Installieren Sie das xorg-docs-Paket, um detailliertere Informationen zu X11 zu erhalten. Auf der man-Seite man 5 xorg.conf finden Sie weitere Informationen zum Format der manuellen Konfiguration (falls erforderlich). Weitere Informationen zur X11-Entwicklung finden Sie auf der Startseite des Projekts unter http://www.x.org.

Die Treiber befinden sich in xf86-video-*-Paketen, beispielsweise xf86-video-ati. Viele der Treiber, die mit diesen Paketen geliefert werden, sind ausführlich in der zugehörigen man-Seite beschrieben. Wenn Sie beispielsweise den ati-Treiber verwenden, erhalten Sie weitere Informationen auf der man-Seite man 4 ati.

Informationen über Treiber von anderen Herstellern stehen in /usr/share/doc/packages/<paketname> zur Verfügung. Beispielsweise ist die Dokumentation von x11-video-nvidiaG04 nach der Installation des Pakets in /usr/share/doc/packages/x11-video-nvidiaG03 verfügbar.

21.2 Installation und Konfiguration von Schriften

 

Schriften in Linux lassen sich in zwei Gruppen gliedern:

Outline- oder Vektorschriften

Enthält eine mathematische Beschreibung als Informationen zum Zeichnen der Form einer Glyphe. Die Glyphen können dabei auf eine beliebige Größe skaliert werden, ohne dass die Qualität darunter leidet. Bevor Sie eine solche Schrift (oder Glyphe) verwenden können, müssen die mathematischen Beschreibungen in ein Raster überführt werden. Dieser Vorgang wird als Schriftrasterung bezeichnet. Beim Schrift-Hinting (in der Schrift eingebettet) wird das Rendering-Ergebnis für eine bestimmte Größe optimiert. Die Rasterung und das Hinting erfolgen mit der FreeType-Bibliothek.

Unter Linux werden häufig die Formate PostScript Typ 1 und Typ 2, TrueType und OpenType verwendet.

Bitmap- oder Rasterschriften

Besteht aus einer Pixelmatrix, die auf eine bestimmte Schriftgröße abgestimmt ist. Bitmap-Schriften lassen sich äußerst schnell und einfach rendern. Im Gegensatz zu Vektorschriften können Bitmap-Schriften jedoch nicht ohne Qualitätseinbußen skaliert werden. Diese Schriften werden daher meist in unterschiedlichen Größen bereitgestellt. Selbst heute noch werden Bitmap-Schriften in der Linux-Konsole und teils auch auf Terminals verwendet.

Unter Linux sind das Portable Compiled Format (PCF) und das Glyph Bitmap Distribution Format (BDF) die häufigsten Formate.

Das Erscheinungsbild dieser Schriften wird durch zwei wichtige Faktoren beeinflusst:

  • Auswählen einer geeigneten Schriftfamilie

  • Rendern der Schrift mit einem Algorithmus, der optisch ansprechende Ergebnisse bewirkt.

Der letzte Punkt ist nur für Vektorschriften relevant. Die beiden obigen Punkte sind stark subjektiv; dennoch müssen einige Standardvorgaben festgelegt werden.

Linux-Schriftrenderingsysteme bestehen aus mehreren Bibliotheken mit unterschiedlichen Beziehungen. Die grundlegende Schriftrenderingbibilothek FreeType konvertiert die Schriftglyphen von unterstützten Formaten in optimierte Bitmap-Glyphen. Der Renderingvorgang wird durch einen Algorithmus und die zugehörigen Parameter gesteuert (unter Umständen patentrechtlich geschützt).

Alle Programme und Bibliotheken, die mit FreeType arbeiten, sollten auf die Fontconfig-Bibliothek zurückgreifen. In dieser Bibliothek werden die Schriftkonfigurationen von Benutzern und vom System gesammelt. Wenn ein Benutzer die Fontconfig-Einstellung ergänzt, entstehen durch diese Änderung Fontconfig-fähige Anwendungen.

Ein eingehenderes OpenType-Shaping für Skripte wie Arabic, Han oder Phags-Pa und andere höhere Textverarbeitung erfolgt mit Harfbuzz oder Pango.

21.2.1 Anzeigen der installierten Schriften

 

Mit dem Kommando rpm oder fc-list erhalten Sie einen Überblick über die Schriften, die auf dem System installiert sind. Beide Kommandos liefern eine aussagekräftige Antwort, geben dabei jedoch (je nach System- und Benutzerkonfiguration) ggf. unterschiedliche Listen zurück:

rpm

rpm zeigt die auf dem System installierten Software-Pakete an, in denen sich Schriften befinden: 

tux > rpm -qa '*fonts*'

Alle Schriftpakete sollten mit diesem Ausdruck aufgefunden werden. Unter Umständen gibt das Kommando jedoch einige falsch positive Einträge zurück, beispielsweise fonts-config (dies ist weder eine Schrift noch sind hier Schriften enthalten).

fc-list

Mit fc-list erhalten Sie einen Überblick darüber, welche Schriftfamilien verfügbar sind und ob diese auf dem System oder in Ihrem Benutzerverzeichnis installiert sind: 

tux > fc-list ':' family
Anmerkung
Anmerkung: Kommando fc-list

Das Kommando fc-list ist eine Erweiterung zur Fontconfig-Bibliothek. Aus Fontconfig – oder genauer gesagt, aus dem Cache – lassen sich zahlreiche interessante Informationen ermitteln. Unter man 1 fc-list finden Sie weitere Einzelheiten.

21.2.2 Anzeigen von Schriften

 

Mit dem Kommando ftview (Paket ft2demos) sowie unter http://fontinfo.opensuse.org/ sehen Sie, wie eine installierte Schriftfamilie dargestellt wird. Soll beispielsweise die Schrift FreeMono in 14 Punkt angezeigt werden, verwenden Sie ftview wie folgt: 

tux > ftview 14 /usr/share/fonts/truetype/FreeMono.ttf

Unter http://fontinfo.opensuse.org/ erfahren Sie, welche Schriftschnitte (normal, fett, kursiv etc.) und welche Sprachen unterstützt werden.

21.2.3 Abfragen von Schriften

 

Mit dem Kommando fc-match fragen Sie ab, welche Schrift für ein angegebenes Muster verwendet wird.

Wenn das Muster beispielsweise eine bereits installierte Schrift enthält, gibt fc-match den Dateinamen, die Schriftfamilie und den Schriftschnitt zurück: 

tux > fc-match 'Liberation Serif'
LiberationSerif-Regular.ttf: "Liberation Serif" "Regular"

Ist die gewünschte Schrift nicht auf dem System vorhanden, greifen die Ähnlichkeitsregeln von Fontconfig und es werden verfügbare Schriften mit der größtmöglichen Ähnlichkeit gesucht. Ihre Anforderung wird also ersetzt: 

tux > fc-match 'Foo Family'
DejaVuSans.ttf: "DejaVu Sans" "Book"

Fontconfig unterstützt Aliase: Ein Name wird durch den Namen einer anderen Schriftfamilie ersetzt. Ein typisches Beispiel sind generische Namen wie „sans-serif“, „serif“ und „monospace“. Diese Alias-Namen können durch echte Familiennamen und sogar durch eine Präferenzliste mit Familiennamen ersetzt werden: 

tux > for font in serif sans mono; do fc-match "$font" ; done
DejaVuSerif.ttf: "DejaVu Serif" "Book"
DejaVuSans.ttf: "DejaVu Sans" "Book"
DejaVuSansMono.ttf: "DejaVu Sans Mono" "Book"

Das Ergebnis auf Ihrem System kann abweichen, abhängig davon, welche Schriften derzeit installiert sind.

Anmerkung
Anmerkung: Ähnlichkeitsregeln in Fontconfig

Fontconfig gibt immer eine reale Schriftfamilie (sofern mindestens eine Familie installiert ist) für die angegebene Anforderung zurück, die so ähnlich ist wie möglich. Die „Ähnlichkeit“ ist abhängig von den internen Metriken von Fontconfig sowie von den Fontconfig-Einstellungen des Benutzers oder Administrators.

21.2.4 Installieren von Schriften

 

Zum Installieren einer neuen Schrift stehen die folgenden wichtigsten Verfahren zur Auswahl:

  1. Installieren Sie die Schriftdateien (z. B. *.ttf oder *.otf) manuell in ein bekanntes Schriftverzeichnis. Wenn die Schriften systemweit verfügbar sein sollen, verwenden Sie das Standardverzeichnis /usr/share/fonts. Für die Installation in Ihrem Benutzerverzeichnis verwenden Sie ~/.config/fonts.

    Falls Sie nicht die standardmäßigen Verzeichnisse verwenden möchten, können Sie in Fontconfig ein anderes Verzeichnis auswählen. Hierzu geben Sie das Element <dir> an. Weitere Informationen finden Sie in Abschnitt 21.2.5.2, „Kurzer Einblick in Fontconfig-XML“.

  2. Installieren Sie die Schriften mit zypper. Zahlreiche Schriften sind bereits als Paket verfügbar, beispielsweise in der SUSE-Distribution oder im Repository M17N:fonts. Fügen Sie das Repository mit dem nachfolgenden Kommando in die Liste ein. So fügen Sie beispielsweise ein Repository für SUSE Linux Enterprise Server 15 SP3 hinzu: 

    tux > sudo zypper ar
     https://download.opensuse.org/repositories/M17N:/fonts/SLE_15/

    FONT_FAMILY_NAME ermitteln Sie mit dem folgenden Kommando: 

    tux > zypper se 'FONT_FAMILY_NAME*fonts'

21.2.5 Konfigurieren der Darstellung von Schriften

 

Je nach Renderingmedium und Schriftgröße entstehen womöglich keine zufriedenstellenden Ergebnisse. Ein durchschnittlicher Monitor hat beispielsweise eine Auflösung von 100dpi. Bei dieser Auflösung sind die Pixel zu groß und die Glyphen wirken plump und unförmig.

Für niedrigere Auflösungen stehen mehrere Algorithmen bereit, z. B. Anti-Aliasing (Graustufenglättung), Hinting (Anpassen an das Raster) oder Subpixel-Rendering (Verdreifachen der Auflösung in eine Richtung). Diese Algorithmen können dabei von Schriftformat zu Schriftformat unterschiedlich sein.

Wichtig
Wichtig: Patentprobleme beim Subpixel-Rendering

Das Subpixel-Rendering kommt in SUSE-Distributionen nicht zum Einsatz. FreeType2 unterstützt zwar diesen Algorithmus, allerdings unterliegt er mehreren Patenten, die Ende 2019 auslaufen. Die eingestellten Optionen für das Subpixel-Rendering in Fontconfig wirken sich daher nur dann aus, wenn das System eine FreeType2-Bibilothek enthält, in der das Subpixel-Rendering kompiliert ist.

Mit Fontconfig können Sie den Rendering-Algorithmus für einzelne Schriften oder auch für eine Gruppe von Schriften gleichzeitig auswählen.

21.2.5.1 Konfigurieren von Schriften mit sysconfig

 

SUSE Linux Enterprise Server umfasst eine sysconfig-Schicht oberhalb von Fontconfig. Dies ist ein guter Ausgangspunkt, um mit der Schriftkonfiguration zu experimentieren. Zum Ändern der Standardeinstellungen bearbeiten Sie die Konfigurationsdatei /etc/sysconfig/fonts-config. (Alternativ verwenden Sie das YaST-Modul sysconfig.) Führen nach dem Bearbeiten der Datei fonts-config aus: 

tux > sudo /usr/sbin/fonts-config

Starten Sie die Anwendung neu, damit der Effekt sichtbar wird. Beachten Sie Folgendes:

  • Einige Anwendungen müssen nicht neu gestartet werden. Firefox liest die Fontconfig-Konfiguration beispielsweise in regelmäßigen Abständen aus. Auf soeben erstellten oder neu geladenen Registerkarten werden die Schriftkonfigurationen erst später sichtbar.

  • Nach jedem Installieren oder Entfernen eines Pakets wird automatisch das Skript fonts-config aufgerufen. (Ist dies nicht der Fall, so ist das Schriften-Software-Paket fehlerhaft.)

  • Jede sysconfig-Variable kann vorübergehend mit der Kommandozeilenoption fonts-config überschrieben werden. Weitere Informationen finden Sie in fonts-config --help.

Es können verschiedene sysconfig-Variablen geändert werden. Weitere Informationen finden Sie auf der man-Seite man 1 fonts-config oder auf der Hilfeseite des YaST-Moduls sysconfig. Beispiele für Variablen:

Verwendung der Rendering-Algorithmen

Nutzen Sie ggf. FORCE_HINTSTYLE, FORCE_AUTOHINT, FORCE_BW, FORCE_BW_MONOSPACE, USE_EMBEDDED_BITMAPS und EMBEDDED_BITMAP_LANGAGES

Präferenzliste generischer Aliase

Verwenden Sie PREFER_SANS_FAMILIES, PREFER_SERIF_FAMILIES, PREFER_MONO_FAMILIES und SEARCH_METRIC_COMPATIBLE

In der nachfolgenden Liste finden Sie einige Konfigurationsbeispiele, sortiert von den „am leichtesten lesbaren“ Schriften (stärkerer Kontrast) zu den „ansprechendsten“ Schriften (stärker geglättet).

Bitmap-Schriften

Mit den Variablen PREFER_*_FAMILIES können Sie Bitmap-Schriften den Vorzug geben. Beachten Sie das Beispiel im Hilfeabschnitt zu diesen Variablen. Bitmap-Schriften werden schwarzweiß dargestellt und nicht geglättet und sie stehen nur in bestimmten Größen zur Verfügung. Nutzen Sie ggf. 

SEARCH_METRIC_COMPATIBLE="no"

zum Deaktivieren der Ersetzungen der Familienname auf Basis der Metrikkompatibilität.

Skalierbare, schwarzweiß dargestellte Schriften

Skalierbare Schriften, die ohne Antialiasing gerendert werden, können ähnliche Ergebnisse liefern wie Bitmap-Schriften, wobei die Schriften weiterhin skalierbar bleiben. Verwenden Sie Schriften mit gutem Hinting, beispielsweise die Liberation-Schriftfamilien. Bislang sind leider nur wenige Schriften mit gutem Hinting erhältlich. Mit der folgenden Variablen erzwingen Sie diese Methode: 

FORCE_BW="yes"
Nichtproportionale schwarzweiß dargestellte Schriften

Nichtproportionale Schriften werden nur ohne Antialiasing gerendert; ansonsten verwenden Sie die Standardeinstellungen: 

FORCE_BW_MONOSPACE="yes"
Standardeinstellungen

Alle Schriften werden mit Antialiasing gerendert. Schriften mit gutem Hinting werden mit dem Byte-Code-Interpreter) gerendert, die übrigen Schriften mit Autohinter (hintstyle=hintslight). Behalten Sie die Standardeinstellungen für alle relevanten sysconfig-Variablen bei.

CFF-Schriften

Die Schriften werden im CFF-Format verwendet. Im Hinblick auf die aktuellen Verbesserungen in FreeType2 sind diese Schriften im Allgemeinen leichter lesbar als die standardmäßigen TrueType-Schriften. Probieren Sie sie aus, indem Sie das Beispiel PREFER_*_FAMILIES verwenden. Auf Wunsch können Sie sie wie folgt dunkler und fetter darstellen: 

SEARCH_METRIC_COMPATIBLE="no"

Standardmäßig werden sie mit hintstyle=hintslight gerendert. Eine weitere Möglichkeit: 

SEARCH_METRIC_COMPATIBLE="no"
Nur Autohinter

Auch für Schriften mit gutem Hinter wird Autohinter aus FreeType2 verwendet. Dies kann zu fetteren, manchmal unscharfen Buchstaben mit niedrigerem Kontrast führen. Mit der folgenden Variablen aktivieren Sie dies: 

FORCE_AUTOHINTER="yes"

Mit FORCE_HINTSTYLE steuern Sie den Hinting-Grad.

21.2.5.2 Kurzer Einblick in Fontconfig-XML

 

Bei Fontconfig wird das Konfigurationsformat eXtensible Markup Language (XML) genutzt. Diese wenigen Beispiele sollen keine erschöpfende Referenz darstellen, sondern lediglich einen kurzen Überblick bieten. Weitere Informationen und Anregungen finden Sie in man 5 fonts-conf oder /etc/fonts/conf.d/.

Die zentrale Fontconfig-Konfigurationsdatei ist /etc/fonts/fonts.conf und umfasst unter anderem das gesamte Verzeichnis /etc/fonts/conf.d/. Änderungen an Fontconfig können an zwei Stellen vorgenommen werden:

Fontconfig-Konfigurationsdateien
 

  1. Systemweite Änderungen.  Bearbeiten Sie die Datei /etc/fonts/local.conf. (Standardmäßig enthält diese Datei ein leeres fontconfig-Element.)

  2. Benutzerspezifische Änderungen.  Bearbeiten Sie die Datei ~/.config/fontconfig/fonts.conf. Speichern Sie die Fontconfig-Konfigurationsdateien in das Verzeichnis ~/.config/fontconfig/conf.d/.

Benutzerspezifische Änderungen überschreiben die systemweiten Einstellungen.

Anmerkung
Anmerkung: Veraltete Benutzerkonfigurationsdatei

Die Datei ~/.fonts.conf ist als veraltet gekennzeichnet und darf nicht mehr verwendet werden. Verwenden Sie stattdessen die Datei ~/.config/fontconfig/fonts.conf.

Jede Konfigurationsdatei muss ein fontconfig-Element enthalten. Die minimale Datei sieht daher wie folgt aus: 

<?xml version="1.0"?>
   <!DOCTYPE fontconfig SYSTEM "fonts.dtd">
   <fontconfig>
   <!-- Insert your changes here -->
   </fontconfig>

Falls die Standardverzeichnisse nicht ausreichen, fügen Sie das dir-Element mit dem gewünschten Verzeichnis ein: 

<dir>/usr/share/fonts2</dir>

Fontconfig sucht rekursiv nach den Schriften.

Mit dem folgenden Fontconfig-Snippet können Sie die Algorithmen für das Schriftrendering auswählen (siehe Beispiel 21.1, „Festlegen von Rendering-Algorithmen“):

Beispiel 21.1: Festlegen von Rendering-Algorithmen
 
<match target="font">
 <test name="family">
  <string>FAMILY_NAME</string>
 </test>
 <edit name="antialias" mode="assign">
  <bool>true</bool>
 </edit>
 <edit name="hinting" mode="assign">
  <bool>true</bool>
 </edit>
 <edit name="autohint" mode="assign">
  <bool>false</bool>
 </edit>
 <edit name="hintstyle" mode="assign">
  <const>hintfull</const>
 </edit>
</match>

Sie können verschiedene Eigenschaften der Schriften zunächst ausprobieren. Mit dem <test>-Element können Sie beispielsweise die Schriftfamilie (siehe Beispiel), das Größenintervall, den Zeichenabstand, das Schriftformat und andere Eigenschaften testen. Wenn Sie <test> vollständig löschen, werden alle <edit>-Elemente auf sämtliche Schriften angewendet (globale Änderung).

Beispiel 21.2: Aliasse und Ersetzungen von Familiennamen
 
Regel 1
<alias>
 <family>Alegreya SC</family>
 <default>
  <family>serif</family>
 </default>
</alias>
Regel 2
<alias>
 <family>serif</family>
 <prefer>
  <family>Droid Serif</family>
 </prefer>
</alias>
Regel 3
<alias>
 <family>serif</family>
 <accept>
  <family>STIXGeneral</family>
 </accept>
</alias>

Mit den Regeln in Beispiel 21.2, „Aliasse und Ersetzungen von Familiennamen“ wird eine priorisierte Familienliste (PFL) erzeugt. Je nach Element werden verschiedene Aktionen ausgeführt:

<default> in Regel 1

Mit dieser Regel wird ein serif-Familienname an das Ende der PFL angehängt.

<prefer> in Regel 2

Mit dieser Regel wird „Droid Serif“ direkt vor dem ersten Auftreten von serif in der PFL eingefügt, wenn Alegreya SC in der PFL vorliegt.

<accept> in Regel 3

Mit dieser Regel wird ein „STIXGeneral“-Familienname direkt nach dem ersten Auftreten des serif-Familiennamens in die PFL eingefügt.

Wenn alle Snippets in der Reihenfolge Regel 1 - Regel 2 - Regel 3 ausgeführt werden und der Benutzer „Alegreya SC“ anfordert, wird die PFL wie in Tabelle 21.1, „Erzeugen einer PFL aus Fontconfig-Regeln“ dargestellt erzeugt.

Tabelle 21.1: Erzeugen einer PFL aus Fontconfig-Regeln
 

Reihenfolge

Aktuelle PFL

Anforderung

Alegreya SC

Regel 1

Alegreya SC, serif

Regel 2

Alegreya SC, Droid Serif, serif

Regel 3

Alegreya SC, Droid Serif, serif, STIXGeneral

In den Fontconfig-Metriken hat der Familienname die höchste Priorität vor anderen Mustern wie Schriftschnitt, Größe usw. Fontconfig prüft, welche Familie derzeit auf dem System installiert ist. Wenn „Alegreya SC“ installiert ist, gibt Fontconfig diese Schrift zurück. Ansonsten wird „Droid Serif“ angefordert usw.

Gehen Sie vorsichtig vor. Wenn die Reihenfolge der Fontconfig-Snippets geändert wird, gibt Fontconfig unter Umständen andere Ergebnisse zurück (siehe Tabelle 21.2, „Ergebnisse beim Erzeugen der PFL aus Fontconfig-Regeln mit anderer Reihenfolge“).

Tabelle 21.2: Ergebnisse beim Erzeugen der PFL aus Fontconfig-Regeln mit anderer Reihenfolge
 

Reihenfolge

Aktuelle PFL

Hinweis

Anforderung

Alegreya SC

Dieselbe Anforderung wie oben.

Regel 2

Alegreya SC

serif nicht in PFL, kein Ersatz

Regel 3

Alegreya SC

serif nicht in PFL, kein Ersatz

Regel 1

Alegreya SC, serif

Alegreya SC in PFL vorhanden, Ersatz vorgenommen

Anmerkung
Anmerkung: Implikation

Betrachten Sie das Alias <default> als Klassifizierung oder Einbeziehung dieser Gruppe (sofern nicht installiert). Wie das Beispiel zeigt, muss <default> stets vor den Aliasen <prefer> und <accept> dieser Gruppe stehen.

Die Klassifizierung <default> ist nicht auf die generischen Aliase serif, sans-serif und monospace beschränkt. Ein ausführlicheres Beispiel finden Sie in /usr/share/fontconfig/conf.avail/30-metric-aliases.conf.

Mit dem nachfolgenden Fontconfig-Snippet in Beispiel 21.3, „Aliase und Ersetzungen von Familiennamen“ wird eine serif-Gruppe erstellt. Jede Familie in dieser Gruppe kann andere Familien ersetzen, wenn eine vorangehende Schrift nicht installiert ist.

Beispiel 21.3: Aliase und Ersetzungen von Familiennamen
 
<alias>
 <family>Alegreya SC</family>
 <default>
  <family>serif</family>
 </default>
</alias>
<alias>
 <family>Droid Serif</family>
 <default>
  <family>serif</family>
 </default>
</alias>
<alias>
 <family>STIXGeneral</family>
 <default>
  <family>serif</family>
 </default>
</alias>
<alias>
 <family>serif</family>
 <accept>
  <family>Droid Serif</family>
  <family>STIXGeneral</family>
  <family>Alegreya SC</family>
 </accept>
</alias>

Die Priorität ergibt sich aus der Reihenfolge im Alias <accept>. Ebenso können stärkere Aliase <prefer> verwendet werden.

Beispiel 21.2, „Aliasse und Ersetzungen von Familiennamen“ wird durch Beispiel 21.4, „Aliasse und Ersetzungen von Familiennamen“ ergänzt.

Beispiel 21.4: Aliasse und Ersetzungen von Familiennamen
 
Regel 4
<alias>
 <family>serif</family>
 <accept>
  <family>Liberation Serif</family>
 </accept>
</alias>
Regel 5
<alias>
 <family>serif</family>
 <prefer>
  <family>DejaVu Serif</family>
 </prefer>
</alias>

Die erweiterte Konfiguration aus Beispiel 21.4, „Aliasse und Ersetzungen von Familiennamen“ würde die folgende PFL-Entwicklung bewirken:

Tabelle 21.3: Ergebnisse beim Erzeugen einer PFL aus Fontconfig-Regeln
 

Reihenfolge

Aktuelle PFL

Anforderung

Alegreya SC

Regel 1

Alegreya SC, serif

Regel 2

Alegreya SC, Droid Serif, serif

Regel 3

Alegreya SC, Droid Serif, serif, STIXGeneral

Regel 4

Alegreya SC, Droid Serif, serif, Liberation Serif, STIXGeneral

Regel 5

Alegreya SC, Droid Serif, DejaVu Serif, serif, Liberation Serif, STIXGeneral

Anmerkung
Anmerkung: Auswirkungen.

  • Wenn mehrere <accept>-Deklarationen für denselben generischen Namen vorhanden sind, hat die zuletzt geparste Deklaration „Vorrang“. Beim Erstellen einer systemweiten Konfiguration sollten Sie <accept> nach Möglichkeit nicht nach dem Benutzer(/etc/fonts/conf.d/*-user.conf) angeben.

  • Wenn mehrere <prefer>-Deklarationen für denselben generischen Namen vorhanden sind, hat die zuletzt geparste Deklaration „Vorrang“. In der systemweiten Konfiguration sollten Sie <prefer> nicht vor dem Benutzer angeben.

  • Jede <prefer>-Deklaration überschreibt die <accept>-Deklarationen für denselben generischen Namen. Wenn der Administrator dem Benutzer die Möglichkeit geben möchte, <accept> zu verwenden (nicht nur <prefer>), sollte der Administrator <prefer> nicht in der systemweiten Konfiguration angeben. Die meisten Benutzer beschränken sich jedoch lediglich auf <prefer>, sodass dies keine negativen Auswirkungen haben sollte. <prefer> kommt auch in systemweiten Konfigurationen zum Einsatz.

21.3 GNOME-Konfiguration für Administratoren

 

21.3.1 Das dconf-System

 

Die Konfiguration des GNOME-Desktops wird mit dconf verwaltet. Dabei handelt es sich um eine hierarchisch strukturierte Datenbank oder eine Registrierung, über die Benutzer persönliche Einstellungen bearbeiten können. Administratoren können darüber standardmäßige oder obligatorische Werte für alle Benutzer festlegen. dconf ersetzt das gconf-System von GNOME 2.

Mit dconf-editor werden die dconf-Optionen in einer grafischen Benutzeroberfläche angezeigt. Mit dconf können Sie über die Kommandozeile auf die Konfigurationsoptionen zugreifen und diese Optionen bearbeiten.

Das GNOME-Tool Tweaks bietet eine unkomplizierte Benutzeroberfläche mit zusätzlichen Konfigurationsoptionen, die über die normale GNOME-Konfiguration hinausgehen. Das Werkzeug lässt sich wahlweise über das GNOME-Anwendungsmenü oder auch über die Befehlszeile mit dem Befehl gnome-tweak-tool starten.

21.3.2 Systemweite Konfiguration

 

Im Verzeichnis /etc/dconf/db/ können globale dconf-Konfigurationsparameter festgelegt werden. Hierzu gehört beispielsweise die Konfiguration für GDM oder das Sperren bestimmter Konfigurationsoptionen für die Benutzer.

So erstellen Sie eine systemweite Konfiguration (Beispiel):

  1. Erstellen Sie unter /etc/dconf/db/ ein neues Verzeichnis, das auf .d endet. Dieses Verzeichnis kann beliebig viele Textdateien mit Konfigurationsoptionen enthalten. Für dieses Beispiel erstellen Sie die Datei /etc/dconf/db/network/00-proxy mit dem folgenden Inhalt: 

    # This is a comment
[system/proxy/http]
host='10.0.0.1'
enabled=true

  2. Parsen Sie die neuen Konfigurationsdirektiven in das dconf-Datenbankformat: 

    tux > sudo dconf update

  3. Tragen Sie die neue network-Konfigurationsdatenbank in das Standard-Benutzerprofil ein. Erstellen Sie hierzu die Datei /etc/dconf/profiles/user. Fügen Sie dann den folgenden Inhalt ein: 

    system-db:network

    Die Datei /etc/dconf/profiles/user fungiert als GNOME-Standard. Andere Profile können in der Umgebungsvariablen DCONF_PROFILE definiert werden.

  4. Optional: Wenn die Proxy-Konfiguration für die Benutzer gesperrt werden soll, erstellen Sie die Datei /etc/dconf/db/network/locks/proxy. Fügen Sie dann eine Zeile mit den Schlüsseln, die nicht geändert werden dürfen, in diese Datei ein: 

    /system/proxy/http/host
/system/proxy/http/enabled

Mit dem grafischen dconf-editor können Sie ein Profil mit einem einzelnen Benutzer erstellen und dann mit dconf dump / eine Liste aller Konfigurationsoptionen abrufen. Die Konfigurationsoptionen können dann in einem globalen Profil gespeichert werden.

Eine ausführliche Beschreibung der globalen Konfiguration finden Sie unter https://wiki.gnome.org/Projects/dconf/SystemAdministrators

21.3.3 Weitere Informationen

 

Weitere Informationen finden Sie im http://help.gnome.org/admin/.

21.4 Umschalten zwischen Intel- und NVIDIA Optimus-GPUs mit SUSE Prime

 

SUSE Prime ist ein Werkzeug zum Umschalten zwischen Intel-On-Board-Grafikprozessoren (GPUs) und NVIDIA-GPUs mit der Optimus-Technologie von NVIDIA für „umschaltbare Grafik“. Optimus bietet einen Mechanismus für das einfache Umschalten zwischen einer On-Board-Intel-GPU und einer separaten NVIDIA-GPU. Damit kann ein Laptop wahlweise im Energiesparmodus oder mit maximaler Leistung genutzt werden: Die Intel-GPU spart Strom, die NVIDIA-GPU erweckt 3D-Anwendungen zum Leben.

SUSE Prime ist nur auf Systemen mit X11 nutzbar, nicht auf Systemen mit Wayland. Wenn auf Ihrem System Wayland ausgeführt wird, müssen Sie Wayland deaktivieren und ein Fallback auf X11 vornehmen, wenn Sie SUSE Prime nutzen möchten (siehe Abschnitt 21.4.1, „Voraussetzungen“).

21.4.1 Voraussetzungen

 

Es dürfen keine Datei /etc/X11/xorg.conf und keine Konfigurationsdateien mit aktiven Abschnitten „ServerLayout“, „Device“ oder „Screen“ im Verzeichnis /etc/X11/xorg.conf.d vorhanden sein.

SUSE Prime ist nur unter X11 nutzbar. Prüfen Sie mit dem Kommando loginctl, ob Ihr System X11 oder Wayland verwendet: 

tux > loginctl
   SESSION        UID USER             SEAT             TTY             
         2       1000 tux             seat0               
tux > loginctl show-session 2|grep Type
Type=x11

Wenn Ihr System Wayland verwendet, deaktivieren Sie Wayland. Bearbeiten Sie hierzu die Datei /etc/gdm/custom.conf und entfernen Sie den Kommentar WaylandEnable=false. Starten Sie dann neu.

21.4.2 Installieren und Verwenden von SUSE Prime

 

Ihre NVIDIA-Grafikkarte sollte bereits installiert und funktionsfähig sein. Andernfalls finden Sie weitere Informationen hierzu unter Abschnitt 21.4.3, „Installieren von NVIDIA-Treibern“.

Installieren Sie das Paket suse-prime : 

tux > sudo zypper install suse-prime

Zum Umschalten Ihrer GPU führen Sie einen der folgenden Kommandos aus; melden Sie sich dann ab und wieder an: 

tux > sudo prime-select intel
tux > sudo prime-select intel2
tux > sudo prime-select nvidia

Verwenden Sie den intel-Treiber, wenn dies der Modesetting-Treiber ist. intel2 ist für Systeme mit dem Treiber xf86-video-intel vorgesehen. Diese Informationen erhalten Sie durch Installieren und Ausführen von inxi: 

tux > inxi -G
Graphics: Device-1: Intel Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller
          Display Server: x11(X.org 1.20.1 ) drivers: modesetting (unloaded: fbdev, vesa)
          Resolution: 1920x1080@60.00hz
          OpenGL: renderer: Mesa DRI Intel Haswell Desktop version: 4.5 Mesa 18.2.8

Welche GPU ist derzeit aktiv? 

tux > sudo /usr/sbin/prime-select get-current
Driver configured: intel

21.4.3 Installieren von NVIDIA-Treibern

 

Wenn Sie Ihre NVIDIA-Karte identifizieren müssen, damit Sie den zu verwendenden Treiber ermitteln können, führen Sie folgendes Kommando aus: 

tux > /sbin/lspci | grep VGA

Installieren Sie die Treiber anhand dieser Schritte mit Zypper.

Listen Sie die verfügbaren Treiberpakete auf: 

tux > sudo zypper se nvidia

Installieren Sie dann die Treiber für Ihre NVIDIA-Grafikkarte: 

tux > sudo zypper se packagename

22 Zugriff auf Dateisysteme mit FUSE

 

FUSE ist das Akronym für File System in User Space (Dateisystem im Userspace). Das bedeutet, Sie können ein Dateisystem als nicht privilegierter Benutzer konfigurieren und einhängen. Normalerweise müssen Sie für diese Aufgabe als root angemeldet sein. FUSE alleine ist ein Kernel-Modul. In Kombination mit Plug-Ins kann FUSE auf nahezu alle Dateisysteme wie SSH-Fernverbindungen, ISO-Images und mehr erweitert werden.

22.1 Konfigurieren von FUSE

 

Bevor Sie FUSE installieren können, müssen Sie das Paket fuse installieren. Abhängig vom gewünschten Dateisystem benötigen Sie zusätzliche Plugins, die in verschiedenen Paketen verfügbar sind.

In der Regel muss FUSE nicht konfiguriert werden. Jedoch empfiehlt es sich, ein Verzeichnis anzulegen, in dem Sie alle Ihre Einhängepunkte speichern. Sie können beispielsweise das Verzeichnis ~/mounts anlegen und dort Ihre Unterverzeichnisse für die verschiedenen Dateisysteme einfügen.

22.2 Einhängen einer NTFS-Partition

 

NTFS (New Technology File System) ist das Standard-Dateisystem von Windows. Unter normalen Umständen ist ein nicht privilegierter Benutzer nicht in der Lage, NTFS-Blockgeräte über die externe FUSE-Bibliothek einzuhängen. Für das nachfolgende Verfahren zum Einhängen einer Windows-Partition sind daher Root-Berechtigungen erforderlich.

  1. Melden Sie sich als root an und installieren Sie das Paket ntfs-3g. Dies finden Sie in SUSE Linux Enterprise Workstation Extension.

  2. Erstellen Sie ein Verzeichnis, das als Einhängepunkt genutzt werden soll, z. B. ~/mounts/windows.

  3. Finden Sie heraus, welche Windows-Partition Sie brauchen. Starten Sie das Partitionierungsmodul von YaST und ermitteln Sie die Partition, die zu Windows gehört; nehmen Sie jedoch keine Änderungen vor. Alternativ können Sie sich als root anmelden und /sbin/fdisk -l ausführen. Suchen Sie Partitionen mit dem Partitionstyp HPFS/NTFS.

  4. Hängen Sie die Partition im Schreib-Lese-Modus ein. Ersetzen Sie den Platzhalter DEVICE durch Ihre entsprechende Windows-Partition: 

    tux > ntfs-3g /dev/DEVICE MOUNT POINT

    Um die Windows-Partition im schreibgeschützten Modus zu verwenden, hängen Sie -o ro an: 

    tux > ntfs-3g /dev/DEVICE MOUNT POINT -o ro

    Der Befehl ntfs-3g hängt das angegebene Gerät mit der aktuellen Benutzer- (UID) und Gruppen-ID (GID) ein. Sollen die Schreibberechtigungen auf einen anderen Benutzer eingestellt werden, rufen Sie mit dem Befehl id USER die Ausgabe der UID- und GID-Werte ab. Legen Sie ihn fest mit: 

    root # id tux
uid=1000(tux) gid=100(users) groups=100(users),16(dialout),33(video)
ntfs-3g /dev/DEVICE MOUNT POINT -o uid=1000,gid=100

    Weitere Optionen finden Sie auf der man-Seite.

Zum Aushängen der Ressource starten Sie fusermount -u MOUNT POINT.

22.3 Weitere Informationen

 

Weitere Informationen finden Sie auf der Homepage von FUSE unter https://github.com/libfuse/libfuse.

23 Verwalten von Kernelmodulen

 

Linux ist als monolithischer Kernel ausgelegt, kann jedoch mithilfe von Kernelmodulen erweitert werden. Diese besonderen Objekte lassen sich je nach Bedarf in den Kernel einfügen und wieder entfernen. Mit Kernelmodulen können also Treiber und Schnittstellen, die nicht im Kernel selbst enthalten sind, eingefügt und entfernt werden. Linux bietet einige Befehle zum Verwalten der Kernelmodule.

23.1 Auflisten der geladenen Module mit lsmod und modinfo

 

Der Befehl lsmod zeigt die derzeit geladenen Kernelmodule. Dieser Befehl liefert beispielsweise die folgende Ausgabe: 

tux > lsmod
Module                  Size  Used by
snd_usb_audio         188416  2
snd_usbmidi_lib        36864  1 snd_usb_audio
hid_plantronics        16384  0
snd_rawmidi            36864  1 snd_usbmidi_lib
snd_seq_device         16384  1 snd_rawmidi
fuse                  106496  3
nfsv3                  45056  1
nfs_acl                16384  1 nfsv3

Die Ausgabe ist in drei Spalten gegliedert. Die Spalte Modul enthält den Namen der geladenen Module, die Spalte Größe entsprechend die Größe der einzelnen Module. Aus der Spalte Verwendet von gehen die Anzahl und der Name der verweisenden Module hervor. Diese Liste ist unter Umständen nicht vollständig.

Ausführliche Informationen zu einem bestimmten Kernelmodul erhalten Sie mit dem Befehl modinfo MODULNAME, wobei MODULNAME für den Namen des gewünschten Kernelmoduls steht. Die modinfo-Binärdatei befindet sich im Verzeichnis /sbin, die nicht zur PATH-Umgebungsvariable des Benutzers gehört. Wenn Sie den Befehl modinfo als normaler Benutzer ausführen, müssen Sie daher den vollständigen Pfad zur Binärdatei angeben: 

tux > /sbin/modinfo kvm
filename:       /lib/modules/5.3.18-57-default/kernel/arch/x86/kvm/kvm.ko.xz
license:        GPL
author:         Qumranet
suserelease:    SLE15-SP3
srcversion:     3D8FBA9060D4537359A06FC
depends:        irqbypass
supported:      yes
retpoline:      Y
intree:         Y
name:           kvm
vermagic:       5.3.18-57-default SMP mod_unload modversions

23.2 Einfügen und Entfernen von Kernelmodulen

 

Kernelmodule können durchaus mit den Befehlen insmod und rmmod eingefügt und entfernt werden; allerdings wird das Werkzeugmodprobe empfohlen. modprobe bietet mehrere wichtige Vorteile, beispielsweise die automatische Auflösung von Abhängigkeiten und Einträge in schwarze Listen.

Wenn Sie keine Parameter angeben, wird mit dem Befehl modprobe ein angegebenes Kernelmodul installiert. modprobe muss mit root-Berechtigungen ausgeführt werden: 

tux > sudo modprobe acpi

Zum Entfernen eines Kernelmoduls geben Sie den Parameter -r an: 

tux > sudo modprobe -r acpi

23.2.1 Automatisches Laden von Kernelmodulen beim Booten

 

Statt die Kernelmodule manuell zu laden, können Sie sie mit dem Dienst system-modules-load.service automatisch beim Booten laden lassen. Zum Aktivieren eines Kernelmoduls fügen Sie eine .conf-Datei in das Verzeichnis /etc/modules-load.d/ ein. Die Konfigurationsdatei sollte dabei denselben Namen erhalten wie das Modul selbst, beispielsweise:

/etc/modules-load.d/rt2800usb.conf

Die Konfigurationsdatei muss den Namen des Kernelmoduls enthalten (z. B. rt2800usb).

Mit dem beschriebenen Verfahren laden Sie Kernelmodule ohne Parameter. Falls Sie ein Kernelmodul mit bestimmten Optionen laden möchten, fügen Sie stattdessen eine Konfigurationsdatei in das Verzeichnis /etc/modprobe.d/ ein. Die Datei muss die Dateinamenerweiterung .conf haben. Für den Dateinamen gilt die folgende Namenskonvention: priority-modulename.conf, beispielsweise 50-thinkfan.conf. Die Konfigurationsdatei muss den Namen des Kernelmoduls und die gewünschten Parameter enthalten. Mit dem folgenden Beispielbefehl erstellen Sie eine Konfigurationsdatei mit dem Namen des Kernelmoduls und den zugehörigen Parametern:

tux > echo "options thinkpad_acpi fan_control=1" | sudo tee /etc/modprobe.d/thinkfan.conf
Anmerkung
Anmerkung: Laden der Kernelmodule

Die meisten Kernelmodule werden automatisch durch das System geladen, sobald ein Gerät erkannt wird oder ein Userspace bestimmte Funktionen angefordert. Sie müssen die Module daher nur in seltenen Fällen manuell in /etc/modules-load.d/ aufnehmen.

23.2.2 Eintragen von Kernelmodulen in schwarze Listen mit modprobe

 

Wenn ein Kernelmodul in eine schwarze Liste eingetragen wird, kann es beim Booten nicht mehr geladen werden. Dies ist von Nutzen, wenn Sie ein Modul deaktivieren möchten, das vermutlich Probleme auf dem System verursacht. Mit dem Werkzeug insmod oder modprobe können Sie Kernelmodule, die auf einer schwarzen Liste stehen, dennoch manuell laden.

Zum Eintragen eines Moduls in eine schwarze Liste tragen Sie die Zeile blacklist MODULNAME in die Datei /etc/modprobe.d/50-blacklist.conf ein. Beispiel: 

blacklist nouveau

Erzeugen Sie mit dem Befehl mkinitrd (als root) ein neues initrd-Image und booten Sie den Computer neu. Diese Schritte können mit dem folgenden Befehl ausgeführt werden: 

tux > su
echo "blacklist nouveau" >> /etc/modprobe.d/50-blacklist.conf && mkinitrd && reboot

Soll ein Kernel-Modul nur vorübergehend deaktiviert werden, tragen Sie es direkt beim Booten in die Blacklist ein. Drücken Sie hierzu im Bootbildschirm die Taste E. Sie gelangen zu einem minimalen Editor, in dem Sie die Bootparameter bearbeiten können. Wechseln Sie zur Zeile, die wie folgt aufgebaut ist: 

linux /boot/vmlinuz...splash= silent quiet showopts

Hängen Sie den Befehl modprobe.blacklist=MODULNAME an das Ende der Zeile an. Beispiel: 

linux /boot/vmlinuz...splash= silent quiet showopts modprobe.blacklist=nouveau

Drücken Sie die Taste F10 oder Strg–X. Der Computer wird mit der angegebenen Konfiguration gebootet.

Soll ein Kernelmodul dauerhaft über GRUB in eine Schwarze Liste eingetragen werden, öffnen Sie die Datei /etc/default/grub zum Bearbeiten und hängen Sie die Option modprobe.blacklist=MODULNAME an den Befehl GRUB_CMD_LINUX an. Führen Sie dann den Befehl sudo grub2-mkconfig -o /boot/grub2/grub.cfg aus, damit die Änderungen in Kraft treten.

24 Gerätemanagement über dynamischen Kernel mithilfe von udev

 

Der Kernel kann fast jedes Gerät in einem laufenden System hinzufügen oder entfernen. Änderungen des Gerätestatus (ob ein Gerät angeschlossen oder entfernt wird) müssen an den userspace weitergegeben werden. Geräte müssen konfiguriert werden, sobald sie angeschlossen und erkannt wurden. Die Benutzer eines bestimmten Geräts müssen über Änderungen im erkannten Status dieses Geräts informiert werden. udev bietet die erforderliche Infrastruktur, um die Geräteknotendateien und symbolischen Links im /dev-Verzeichnis dynamisch zu warten. udev-Regeln bieten eine Methode, um externe Werkzeuge an die Ereignisverarbeitung des Kernelgeräts anzuschließen. Auf diese Weise können Sie die udev-Gerätebehandlung anpassen, indem Sie bestimmte Skripte hinzufügen, die als Teil der Kernel-Gerätebehandlung ausgeführt werden, oder indem Sie zusätzliche Daten zur Auswertung bei der Gerätebehandlung anfordern und importieren.

24.1 Das /dev-Verzeichnis

 

Die Geräteknoten im /dev-Verzeichnis ermöglichen den Zugriff auf die entsprechenden Kernel-Geräte. Mithilfe von udev spiegelt das /dev-Verzeichnis den aktuellen Status des Kernels wieder. Jedes Kernel-Gerät verfügt über eine entsprechende Gerätedatei. Falls ein Gerät vom System getrennt wird, wird der Geräteknoten entfernt.

Der Inhalt des /dev-Verzeichnisses wird auf einem temporären Dateisystem gespeichert und alle Dateien werden bei jedem Systemstart gerendert. Manuell erstellte oder bearbeitete Dateien sind nicht dazu ausgelegt, einen Neustart zu überstehen. Statische Dateien und Verzeichnisse, die unabhängig vom Status des entsprechenden Kernel-Geräts immer im /dev-Verzeichnis vorhanden sein sollten, können mit systemd-tmpfiles erstellt werden. Die Konfigurationsdateien finden Sie in /usr/lib/tmpfiles.d/ und /etc/tmpfiles.d/. Weitere Informationen finden Sie auf der man-Seite systemd-tmpfiles(8).

24.2 Kernel-uevents und udev

 

Die erforderlichen Geräteinformationen werden vom sysfs-Dateisystem exportiert. Für jedes Gerät, das der Kernel erkannt und initialisiert hat, wird ein Verzeichnis mit dem Gerätenamen erstellt. Es enthält Attributdateien mit gerätespezifischen Eigenschaften.

Jedes Mal, wenn ein Gerät hinzugefügt oder entfernt wird, sendet der Kernel ein uevent, um udev über die Änderung zu informieren. Der udev-Dämon liest und parst beim Start alle Regeln aus den Dateien /usr/lib/udev/rules.d/*.rules und /etc/udev/rules.d/*.rules und lädt sie dauerhaft in den Speicher. Wenn Regeldateien geändert, hinzugefügt oder entfernt werden, kann der Dämon ihre Arbeitsspeicherrepräsentation mithilfe des Befehls udevadm control --reload wieder laden. Weitere Informationen zu den udev-Regeln und deren Syntax finden Sie unter Abschnitt 24.6, „Einflussnahme auf die Behandlung von Geräteereignissen durch den Kernel mithilfe von udev-Regeln“.

Jedes empfangene Ereignis wird mit dem Satz der angegebenen Regeln abgeglichen. Die Regeln können Ereignisergebnisschlüssel hinzufügen oder ändern, einen bestimmten Namen für den zu erstellenden Geräteknoten anfordern, auf den Knoten verweisende symbolische Links hinzufügen oder Programme hinzufügen, die ausgeführt werden sollen, nachdem der Geräteknoten erstellt wurde. Die Treiber-Core-uevents werden von einem Kernel-Netlink-Socket empfangen.

24.3 Treiber, Kernel-Module und Geräte

 

Die Kernel-Bus-Treiber prüfen, ob Geräte vorhanden sind. Für jedes erkannte Gerät erstellt der Kernel eine interne Gerätestruktur, während der Treiber-Core ein uevent an den udev-Dämon sendet. Bus-Geräte identifizieren sich mithilfe einer speziell formatierten ID, die Auskunft über die Art des Geräts gibt. Normalerweise bestehen diese IDs aus einer Hersteller- und einer Produkt-ID und anderen das Subsystem betreffenden Werten. Jeder Bus weist ein eigenes Schema für diese IDs auf, das so genannte MODALIAS-Schema. Der Kernel bedient sich der Geräteinformationen, verfasst daraus eine MODALIAS-ID-Zeichenkette und sendet diese Zeichenkette zusammen mit dem Ereignis. Beispiel für eine USB-Maus: 

MODALIAS=usb:v046DpC03Ed2000dc00dsc00dp00ic03isc01ip02

Jeder Gerätetreiber verfügt über eine Liste bekannter Aliasse für Geräte, die er behandeln kann. Die Liste ist in der Kernel-Moduldatei selbst enthalten. Das Programm depmod liest die ID-Listen und erstellt die Datei modules.alias im Verzeichnis /lib/modules des Kernel für alle zurzeit verfügbaren Module. Bei dieser Infrastruktur ist das Laden des Moduls ein ebenso müheloser Vorgang, wie das Aufrufen von modprobe für jedes Ereignis, das über einen MODALIAS-Schlüssel verfügt. Falls modprobe $MODALIAS aufgerufen wird, gleicht es den für das Gerät verfassten Geräte-Alias mit den Aliassen von den Modulen ab. Falls ein übereinstimmender Eintrag gefunden wird, wird das entsprechende Modul geladen. Dies alles wird automatisch von udev ausgelöst.

24.4 Booten und erstes Einrichten des Geräts

 

Alle Geräteereignisse, die während des Bootvorgangs stattfinden, bevor der udev-Daemon ausgeführt wird, gehen verloren. Dies liegt daran, dass die Infrastruktur für die Behandlung dieser Ereignisse sich auf dem root-Dateisystem befindet und zu diesem Zeitpunkt nicht verfügbar ist. Diesen Verlust fängt der Kernel mit der Datei uevent ab, die sich im Geräteverzeichnis jedes Geräts im sysfs-Dateisystem befindet. Durch das Schreiben von add in die entsprechende Datei sendet der Kernel dasselbe Ereignis, das während des Bootvorgangs verloren gegangen ist, neu. Eine einfache Schleife über alle uevent-Dateien in /sys löst alle Ereignisse erneut aus, um die Geräteknoten zu erstellen und die Geräteeinrichtung durchzuführen.

Beispielsweise kann eine USB-Maus, die während des Bootvorgangs vorhanden ist, nicht durch die frühe Bootlogik initialisiert werden, da der Treiber zum entsprechenden Zeitpunkt nicht verfügbar ist. Das Ereignis für die Geräteerkennung ist verloren gegangen und konnte kein Kernel-Modul für das Gerät finden. Anstatt manuell nach angeschlossenen Geräten zu suchen, fordert udev alle Geräteereignisse aus dem Kernel an, wenn das root-Dateisystem verfügbar ist. Das Ereignis für die USB-Maus wird also erneut ausgeführt. Jetzt wird das Kernel-Modul auf dem eingehängten root-Dateisystem gefunden und die USB-Maus kann initialisiert werden.

Vom userspace aus gibt es keinen erkennbaren Unterschied zwischen einer coldplug-Gerätesequenz und einer Geräteerkennung während der Laufzeit. In beiden Fällen werden dieselben Regeln für den Abgleich verwendet und dieselben konfigurierten Programme ausgeführt.

24.5 Überwachen des aktiven udev-Daemons

 

Das Programm udevadm monitor kann verwendet werden, um die Treiber-Core-Ereignisse und das Timing der udev-Ereignisprozesse zu visualisieren. 

UEVENT[1185238505.276660] add   /devices/pci0000:00/0000:00:1d.2/usb3/3-1 (usb)
UDEV  [1185238505.279198] add   /devices/pci0000:00/0000:00:1d.2/usb3/3-1 (usb)
UEVENT[1185238505.279527] add   /devices/pci0000:00/0000:00:1d.2/usb3/3-1/3-1:1.0 (usb)
UDEV  [1185238505.285573] add   /devices/pci0000:00/0000:00:1d.2/usb3/3-1/3-1:1.0 (usb)
UEVENT[1185238505.298878] add   /devices/pci0000:00/0000:00:1d.2/usb3/3-1/3-1:1.0/input/input10 (input)
UDEV  [1185238505.305026] add   /devices/pci0000:00/0000:00:1d.2/usb3/3-1/3-1:1.0/input/input10 (input)
UEVENT[1185238505.305442] add   /devices/pci0000:00/0000:00:1d.2/usb3/3-1/3-1:1.0/input/input10/mouse2 (input)
UEVENT[1185238505.306440] add   /devices/pci0000:00/0000:00:1d.2/usb3/3-1/3-1:1.0/input/input10/event4 (input)
UDEV  [1185238505.325384] add   /devices/pci0000:00/0000:00:1d.2/usb3/3-1/3-1:1.0/input/input10/event4 (input)
UDEV  [1185238505.342257] add   /devices/pci0000:00/0000:00:1d.2/usb3/3-1/3-1:1.0/input/input10/mouse2 (input)

Die UEVENT-Zeilen zeigen die Ereignisse an, die der Kernel an Netlink gesendet hat. Die UDEV-Zeilen zeigen die fertig gestellten udev-Ereignisbehandlungsroutinen an. Das Timing wird in Mikrosekunden angegeben. Die Zeit zwischen UEVENT und UDEV ist die Zeit, die udev benötigt hat, um dieses Ereignis zu verarbeiten oder der udev-Daemon hat eine Verzögerung bei der Ausführung der Synchronisierung dieses Ereignisses mit zugehörigen und bereits ausgeführten Ereignissen erfahren. Beispielsweise warten Ereignisse für Festplattenpartitionen immer, bis das Ereignis für den primären Datenträger fertig gestellt ist, da die Partitionsereignisse möglicherweise auf die Daten angewiesen sind, die das Ereignis für den primären Datenträger von der Hardware angefordert hat.

udevadm monitor --env zeigt die vollständige Ereignisumgebung an: 

ACTION=add
DEVPATH=/devices/pci0000:00/0000:00:1d.2/usb3/3-1/3-1:1.0/input/input10
SUBSYSTEM=input
SEQNUM=1181
NAME="Logitech USB-PS/2 Optical Mouse"
PHYS="usb-0000:00:1d.2-1/input0"
UNIQ=""
EV=7
KEY=70000 0 0 0 0
REL=103
MODALIAS=input:b0003v046DpC03Ee0110-e0,1,2,k110,111,112,r0,1,8,amlsfw

udev sendet auch Meldungen an syslog. Die Standard-syslog-Priorität, die steuert, welche Meldungen an syslog gesendet werden, wird in der udev-Konfigurationsdatei /etc/udev/udev.conf angegeben. Die Protokollpriorität des ausgeführten Dämons kann mit udevadm control --log_priority=LEVEL/NUMBER geändert werden.

24.6 Einflussnahme auf die Behandlung von Geräteereignissen durch den Kernel mithilfe von udev-Regeln

 

Eine udev-Regel kann mit einer beliebigen Eigenschaft abgeglichen werden, die der Kernel der Ereignisliste hinzufügt oder mit beliebigen Informationen, die der Kernel in sysfs exportiert. Die Regel kann auch zusätzliche Informationen aus externen Programmen anfordern. Ereignisse werden mit allen Regeln abgeglichen, die in den Verzeichnissen /usr/lib/udev/rules.d/ (Standardregeln) und /etc/udev/rules.d (systemspezifische Konfiguration) enthalten sind.

Jede Zeile in der Regeldatei enthält mindestens ein Schlüsselwertepaar. Es gibt zwei Arten von Schlüsseln: die Übereinstimmungsschlüssel und Zuweisungsschlüssel. Wenn alle Übereinstimmungsschlüssel mit ihren Werten übereinstimmen, wird diese Regel angewendet und der angegebene Wert wird den Zuweisungsschlüsseln zugewiesen. Eine übereinstimmende Regel kann den Namen des Geräteknotens angeben, auf den Knoten verweisende symbolische Links hinzufügen oder ein bestimmtes Programm als Teil der Ereignisbehandlung ausführen. Falls keine übereinstimmende Regel gefunden wird, wird der standardmäßige Geräteknotenname verwendet, um den Geräteknoten zu erstellen. Ausführliche Informationen zur Regelsyntax und den bereitgestellten Schlüsseln zum Abgleichen oder Importieren von Daten werden auf der man-Seite von udev beschrieben. Nachfolgend finden Sie einige Beispielregeln, die Sie in die grundlegende Regelsyntax von udev einführen. Sämtliche Beispielregeln stammen aus dem udev-Standardregelsatz, der sich in /usr/lib/udev/rules.d/50-udev-default.rules befindet.

Beispiel 24.1: udev-Beispielregeln
 
# console
KERNEL=="console", MODE="0600", OPTIONS="last_rule"

# serial devices
KERNEL=="ttyUSB*", ATTRS{product}=="[Pp]alm*Handheld*", SYMLINK+="pilot"

# printer
SUBSYSTEM=="usb", KERNEL=="lp*", NAME="usb/%k", SYMLINK+="usb%k", GROUP="lp"

# kernel firmware loader
SUBSYSTEM=="firmware", ACTION=="add", RUN+="firmware.sh"

Die Regel Konsole besteht aus drei Schlüsseln: einem Übereinstimmungsschlüssel (KERNEL) und zwei Zuweisungsschlüsseln (MODE, OPTIONS). Der Übereinstimmungsschlüssel KERNEL durchsucht die Geräteliste nach Elementen des Typs console. Nur exakte Übereinstimmungen sind gültig und lösen die Ausführung dieser Regel aus. Der Zuweisungsschlüssel MODE weist dem Geräteknoten spezielle Berechtigungen zu, in diesem Fall Lese- und Schreibberechtigung nur für den Eigentümer des Geräts. Der Schlüssel OPTIONS bewirkt, dass diese Regel auf Geräte dieses Typs als letzte Regel angewendet wird. Alle nachfolgenden Regeln, die mit diesem Gerätetyp übereinstimmen, werden nicht mehr angewendet.

Die Regel serial devices steht in 50-udev-default.rules nicht mehr zur Verfügung; es lohnt sich jedoch, sie sich dennoch anzusehen. Sie besteht aus zwei Übereinstimmungsschlüsseln (KERNEL und ATTRS) und einem Zuweisungsschlüssel (SYMLINK). Der Übereinstimmungsschlüssel KERNEL sucht nach allen Geräten des Typs ttyUSB. Durch den Platzhalter * trifft dieser Schlüssel auf mehrere dieser Geräte zu. Der zweite Übereinstimmungsschlüssel (ATTRS) überprüft, ob die Attributdatei product in sysfs der jeweiligen ttyUSB-Geräte eine bestimmte Zeichenkette enthält. Der Zuweisungsschlüssel SYMLINK bewirkt, dass dem Gerät unter /dev/pilot ein symbolischer Link hinzugefügt wird. Der Operator dieses Schlüssels (+=) weist udev an, diese Aktion auch dann auszuführen, wenn dem Gerät bereits durch frühere (oder auch erst durch spätere) Regeln andere symbolische Links hinzugefügt wurden. Die Regel wird nur angewendet, wenn die Bedingungen beider Übereinstimmungsschlüssel erfüllt sind.

Die Regel printer gilt nur für USB-Drucker. Sie enthält zwei Übereinstimmungsschlüssel (SUBSYSTEM und KERNEL), die beide zutreffen müssen, damit die Regel angewendet wird. Die drei Zuweisungsschlüssel legen den Namen dieses Gerätetyps fest (NAME), die Erstellung symbolischer Gerätelinks (SYMLINK) sowie die Gruppenmitgliedschaft dieses Gerätetyps (GROUP). Durch den Platzhalter * im Schlüssel KERNEL trifft diese Regel auf mehrere lp-Druckergeräte zu. Sowohl der Schlüssel NAME als auch der Schlüssel SYMLINK verwenden Ersetzungen, durch die der Zeichenkette der interne Gerätename hinzugefügt wird. Der symbolische Link für den ersten lp-USB-Drucker würde zum Beispiel /dev/usblp0 lauten.

Die Regel kernel firmware loader weist udev an, während der Laufzeit weitere Firmware mittels eines externen Hilfsskripts zu laden. Der Übereinstimmungsschlüssel SUBSYSTEM sucht nach dem Subsystem firmware. Der Schlüssel ACTION überprüft, ob bereits Geräte des Subsystems firmware hinzugefügt wurden. Der Schlüssel RUN+= löst die Ausführung des Skripts firmware.sh aus, das die noch zu ladende Firmware lokalisiert.

Die folgenden allgemeinen Eigenschaften treffen auf alle Regeln zu:

  • Jede Regel besteht aus einem oder mehreren, durch Kommas getrennten Schlüssel-/Wertepaaren.

  • Die Aktion eines Schlüssels wird durch seinen Operator festgelegt. udev-Regeln unterstützen verschiedene Operatoren.

  • Jeder angegebene Wert muss in Anführungszeichen eingeschlossen sein.

  • Jede Zeile der Regeldatei stellt eine Regel dar. Falls eine Regel länger als eine Zeile ist, verbinden Sie die Zeilen wie bei jeder anderen Shell-Syntax mit \.

  • udev-Regeln unterstützen Shell-typische Übereinstimmungsregeln für die Schemata *, ? und [].

  • udev-Regeln unterstützen Ersetzungen.

24.6.1 Verwenden von Operatoren in udev-Regeln

 

Bei der Erstellung von Schlüsseln stehen Ihnen je nach gewünschtem Schlüsseltyp mehrere Operatoren zur Auswahl. Übereinstimmungsschlüssel werden in der Regel zum Auffinden eines Wertes verwendet, der entweder mit dem Suchwert übereinstimmt oder explizit nicht mit dem gesuchten Wert übereinstimmt. Übereinstimmungsschlüssel enthalten einen der folgenden Operatoren:

==

Suche nach übereinstimmendem Wert. Wenn der Schlüssel ein Suchschema enthält, sind alle Ergebnisse gültig, die mit diesem Schema übereinstimmen.

!=

Suche nach nicht übereinstimmendem Wert. Wenn der Schlüssel ein Suchschema enthält, sind alle Ergebnisse gültig, die mit diesem Schema übereinstimmen.

Folgende Operatoren können für Zuweisungsschlüssel verwendet werden:

=

Weist einem Schlüssel einen Wert zu. Wenn der Schlüssel zuvor aus einer Liste mit mehreren Werten bestand, wird der Schlüssel durch diesen Operator auf diesen Einzelwert zurückgesetzt.

+=

Fügt einem Schlüssel, der eine Liste mehrerer Einträge enthält, einen Wert hinzu.

:=

Weist einen endgültigen Wert zu. Eine spätere Änderung durch nachfolgende Regeln ist nicht möglich.

24.6.2 Verwenden von Ersetzungen in udev-Regeln

 

udev-Regeln unterstützen sowohl Platzhalter als auch Ersetzungen. Diese setzen Sie genauso ein wie in anderen Skripten. Folgende Ersetzungen können in udev-Regeln verwendet werden:

%r, $root

Standardmäßig das Geräteverzeichnis /dev.

%p, $devpath

Der Wert von DEVPATH.

%k, $kernel

Der Wert von KERNEL oder der interne Gerätename.

%n, $number

Die Gerätenummer.

%N, $tempnode

Der temporäre Name der Gerätedatei.

%M, $major

Die höchste Nummer des Geräts.

%m, $minor

Die niedrigste Nummer des Geräts.

%s{ATTRIBUTE}, $attr{ATTRIBUTE}

Der Wert eines sysfs-Attributs (das durch ATTRIBUTE festgelegt ist).

%E{VARIABLE}, $env{VARIABLE}

Der Wert einer Umgebungsvariablen (die durch VARIABLE festgelegt ist).

%c, $result

Die Ausgabe von PROGRAM.

%%

Das %-Zeichen.

$$

Das $-Zeichen.

24.6.3 Verwenden von udev-Übereinstimmungsschlüsseln

 

Übereinstimmungsschlüssel legen Bedingungen fest, die erfüllt sein müssen, damit eine udev-Regel angewendet werden kann. Folgende Übereinstimmungsschlüssel sind verfügbar:

ACTION

Der Name der Ereignisaktion, z. B. add oder remove beim Hinzufügen oder Entfernen eines Geräts.

DEVPATH

Der Gerätepfad des Ereignisgeräts, zum Beispiel DEVPATH=/bus/pci/drivers/ipw3945 für die Suche nach allen Ereignissen in Zusammenhang mit dem Treiber ipw3945.

KERNEL

Der interne Name (Kernel-Name) des Ereignisgeräts.

SUBSYSTEM

Das Subsystem des Ereignisgeräts, zum Beispiel SUBSYSTEM=usb für alle Ereignisse in Zusammenhang mit USB-Geräten.

ATTR{DATEINAME}

sysfs-Attribute des Ereignisgeräts. Für die Suche nach einer Zeichenkette im Attributdateinamen vendor können Sie beispielsweise ATTR{vendor}==„On[sS]tream“ verwenden.

KERNELS

Weist udev an, den Gerätepfad aufwärts nach einem übereinstimmenden Gerätenamen zu durchsuchen.

SUBSYSTEMS

Weist udev an, den Gerätepfad aufwärts nach einem übereinstimmenden Geräte-Subsystemnamen zu durchsuchen.

DRIVERS

Weist udev an, den Gerätepfad aufwärts nach einem übereinstimmenden Gerätetreibernamen zu durchsuchen.

ATTRS{DATEINAME}

Weist udev an, den Gerätepfad aufwärts nach einem Gerät mit übereinstimmenden sysfs-Attributwerten zu durchsuchen.

ENV{SCHLÜSSEL}

Der Wert einer Umgebungsvariablen, zum Beispiel ENV{ID_BUS}=„ieee1394 für die Suche nach allen Ereignissen in Zusammenhang mit der FireWire-Bus-ID.

PROGRAM

Weist udev an, ein externes Programm auszuführen. Damit es erfolgreich ist, muss das Programm mit Beendigungscode Null abschließen. Die Programmausgabe wird in STDOUT geschrieben und steht dem Schlüssel RESULT zur Verfügung.

RESULT

Überprüft die Rückgabezeichenkette des letzten PROGRAM-Aufrufs. Diesen Schlüssel können Sie entweder sofort der Regel mit dem PROGRAM-Schlüssel hinzufügen oder erst einer nachfolgenden Regel.

24.6.4 Verwenden von udev-Zuweisungsschlüsseln

 

Im Gegensatz zu den oben beschriebenen Übereinstimmungsschlüsseln beschreiben Zuweisungsschlüssel keine Bedingungen, die erfüllt werden müssen. Sie weisen den Geräteknoten, die von udev gewartet werden, Werte, Namen und Aktionen zu.

NAME

Der Name des zu erstellenden Geräteknotens. Nachdem der Knotenname durch eine Regel festgelegt wurde, werden alle anderen Regeln mit dem Schlüssel NAME, die auf diesen Knoten zutreffen, ignoriert.

SYMLINK

Der Name eines symbolischen Links, der dem zu erstellenden Knoten hinzugefügt werden soll. Einem Geräteknoten können mittels mehrerer Zuweisungsregeln symbolische Links hinzugefügt werden. Ebenso können Sie aber mehrere symbolische Links für einen Knoten auch in einer Regel angeben. Die Namen der einzelnen symbolischen Links müssen in diesem Fall jeweils durch ein Leerzeichen getrennt sein.

OWNER, GROUP, MODE

Die Berechtigungen für den neuen Geräteknoten. Die hier angegebenen Werte überschreiben sämtliche kompilierten Werte.

ATTR{SCHLÜSSEL}

Gibt einen Wert an, der in ein sysfs-Attribut des Ereignisgeräts geschrieben werden soll. Wenn der Operator == verwendet wird, überprüft dieser Schlüssel, ob der Wert eines sysfs-Attributs mit dem angegebenen Wert übereinstimmt.

ENV{SCHLÜSSEL}

Weist udev an, eine Umgebungsvariable zu exportieren. Wenn der Operator == verwendet wird, überprüft dieser Schlüssel, ob der Wert einer Umgebungsvariable mit dem angegebenen Wert übereinstimmt.

RUN

Weist udev an, der Liste der für dieses Gerät auszuführenden Programme ein Programm hinzuzufügen. Sie sollten hier nur sehr kurze Aufgaben angeben. Anderenfalls laufen Sie Gefahr, dass weitere Ereignisse für dieses Gerät blockiert werden.

LABEL

Fügt der Regel eine Bezeichnung hinzu, zu der ein GOTO direkt wechseln kann.

GOTO

Weist udev an, mehrere Regeln auszulassen und direkt mit der Regel fortzufahren, die die von GOTO angegebene Bezeichnung enthält.

IMPORT{TYP}

Lädt Variablen in die Ereignisumgebung, beispielsweise die Ausgabe eines externen Programms. udev kann verschiedene Variablentypen importieren. Wenn kein Typ angegeben ist, versucht udev den Typ anhand des ausführbaren Teils der Dateiberechtigungen selbst zu ermitteln.

  • program weist udev an, ein externes Programm auszuführen und dessen Ausgabe zu importieren.

  • file weist udev an, eine Textdatei zu importieren.

  • parent weist udev an, die gespeicherten Schlüssel des übergeordneten Geräts zu importieren.

WAIT_FOR_SYSFS

Weist udev an, auf die Erstellung der angegebenen sysfs-Datei für ein bestimmtes Gerät zu warten. Mit WAIT_FOR_SYSFS="ioerr_cnt" soll udev beispielsweise abwarten, bis die Datei ioerr_cnt erstellt wurde.

OPTIONEN

Der Schlüssel OPTION kann mehrere Werte haben:

  • last_rule weist udev an, alle nachfolgenden Regeln zu ignorieren.

  • ignore_device weist udev an, dieses Ereignis komplett zu ignorieren.

  • ignore_remove weist udev an, alle späteren Entfernungsereignisse für dieses Gerät zu ignorieren.

  • all_partitions weist udev an, für alle vorhandenen Partitionen eines Blockgeräts Geräteknoten zu erstellen.

24.7 Dauerhafte Benennung von Geräten

 

Das dynamische Geräteverzeichnis und die Infrastruktur für die udev-Regeln ermöglichen die Bereitstellung von stabilen Namen für alle Laufwerke unabhängig von ihrer Erkennungsreihenfolge oder der für das Gerät verwendeten Verbindung. Jedes geeignete Blockgerät, das der Kernel erstellt, wird von Werkzeugen mit speziellen Kenntnissen über bestimmte Busse, Laufwerktypen oder Dateisysteme untersucht. Gemeinsam mit dem vom dynamischen Kernel bereitgestellten Geräteknotennamen unterhält udev Klassen permanenter symbolischer Links, die auf das Gerät verweisen: 

/dev/disk
|-- by-id
|   |-- scsi-SATA_HTS726060M9AT00_MRH453M4HWHG7B -> ../../sda
|   |-- scsi-SATA_HTS726060M9AT00_MRH453M4HWHG7B-part1 -> ../../sda1
|   |-- scsi-SATA_HTS726060M9AT00_MRH453M4HWHG7B-part6 -> ../../sda6
|   |-- scsi-SATA_HTS726060M9AT00_MRH453M4HWHG7B-part7 -> ../../sda7
|   |-- usb-Generic_STORAGE_DEVICE_02773 -> ../../sdd
|   `-- usb-Generic_STORAGE_DEVICE_02773-part1 -> ../../sdd1
|-- by-label
|   |-- Photos -> ../../sdd1
|   |-- SUSE10 -> ../../sda7
|   `-- devel -> ../../sda6
|-- by-path
|   |-- pci-0000:00:1f.2-scsi-0:0:0:0 -> ../../sda
|   |-- pci-0000:00:1f.2-scsi-0:0:0:0-part1 -> ../../sda1
|   |-- pci-0000:00:1f.2-scsi-0:0:0:0-part6 -> ../../sda6
|   |-- pci-0000:00:1f.2-scsi-0:0:0:0-part7 -> ../../sda7
|   |-- pci-0000:00:1f.2-scsi-1:0:0:0 -> ../../sr0
|   |-- usb-02773:0:0:2 -> ../../sdd
|   |-- usb-02773:0:0:2-part1 -> ../../sdd1
`-- by-uuid
    |-- 159a47a4-e6e6-40be-a757-a629991479ae -> ../../sda7
    |-- 3e999973-00c9-4917-9442-b7633bd95b9e -> ../../sda6
    `-- 4210-8F8C -> ../../sdd1

24.8 Von udev verwendete Dateien

 
/sys/*

Virtuelles, vom Linux-Kernel bereitgestelltes Dateisystem, das alle zur Zeit bekannten Geräte exportiert. Diese Informationen werden von udev zur Erstellung von Geräteknoten in /dev verwendet.

/dev/*

Dynamisch erstellte Geräteknoten und mit systemd-tmpfiles erstellte statische Inhalte. Weitere Informationen finden Sie auf der man-Seite systemd-tmpfiles(8).

Die folgenden Dateien und Verzeichnisse enthalten die entscheidenden Elemente der udev-Infrastruktur:

/etc/udev/udev.conf

Wichtigste udev-Konfigurationsdatei.

/etc/udev/rules.d/*

Systemspezifische udev-Ereigniszuordnungsregeln. Hier können Sie benutzerdefinierte Regeln hinzufügen, um die Standardregeln aus /usr/lib/udev/rules.d/* zu bearbeiten oder zu überschreiben.

Dateien werden in alphanumerischer Reihenfolge geparst. Regeln aus Dateien mit höherer Priorität modifizieren oder überschreiben Regeln mit niedrigerer Priorität. Je niedriger die Zahl, desto höher die Priorität.

/usr/lib/udev/rules.d/*

Standard-udev-Ereigniszuordnungsregeln. Die Dateien in diesem Verzeichnis gehören zu Paketen und werden durch Aktualisierungen überschrieben. Hier keinesfalls Dateien hinzufügen, entfernen oder bearbeiten; verwenden Sie stattdessen /etc/udev/rules.d.

/usr/lib/udev/*

Von den udev-Regeln aufgerufene Helferprogramme.

/usr/lib/tmpfiles.d/ and /etc/tmpfiles.d/

Verantwortlich für statische /dev-Inhalte.

24.9 Weitere Informationen

 

Weitere Informationen zur udev-Infrastruktur finden Sie auf den folgenden Manualpages:

udev

Allgemeine Informationen zu udev, Schlüsseln, Regeln und anderen wichtigen Konfigurationsbelangen.

udevadm

udevadm kann dazu verwendet werden, das Laufzeitverhalten von udev zu kontrollieren, Kernel-Ereignisse abzurufen, die Ereigniswarteschlange zu verwalten und einfache Methoden zur Fehlersuche bereitzustellen.

udevd

Informationen zum udev-Ereignisverwaltungs-Daemon.

25 Spezielle Systemfunktionen

 

In diesem Kapitel erhalten Sie zunächst Informationen zu den verschiedenen Softwarepaketen, zu den virtuellen Konsolen und zur Tastaturbelegung. Hier finden Sie Hinweise zu Software-Komponenten, wie bash, cron und logrotate, da diese im Laufe der letzten Veröffentlichungszyklen geändert oder verbessert wurden. Selbst wenn sie nur klein sind oder als nicht besonders wichtig eingestuft werden, sollten die Benutzer ihr Standardverhalten ändern, da diese Komponenten häufig eng mit dem System verbunden sind. Das Kapitel endet mit einem Abschnitt mit sprach- und landesspezifischen Einstellungen (I18N und L10N).

25.1 Informationen zu speziellen Softwarepaketen

 

Im folgenden Kapitel finden Sie grundlegende Informationen zu den folgenden Tools: bash, cron, logrotate, locate, ulimit und free.

25.1.1 Das Paket bash und /etc/profile

 

Bash ist die Standard-System-Shell. Wenn sie als Anmelde-Shell verwendet wird, werden mehrere Initialisierungsdateien gelesen. Bash verarbeitet die entsprechenden Informationen in der Reihenfolge dieser Liste:

  1. /etc/profile

  2. ~/.profile

  3. /etc/bash.bashrc

  4. ~/.bashrc

Nehmen Sie benutzerdefinierte Einstellungen in ~/.profile oder ~/.bashrc vor. Um die richtige Verarbeitung der Dateien zu gewährleisten, müssen die Grundeinstellungen aus /etc/skel/.profile oder /etc/skel/.bashrc in das Home-Verzeichnis des Benutzers kopiert werden. Es empfiehlt sich, die Einstellungen aus /etc/skel nach einer Aktualisierung zu kopieren. Führen Sie die folgenden Shell-Befehle aus, um den Verlust persönlicher Einstellungen zu vermeiden: 

tux > mv ~/.bashrc ~/.bashrc.old
tux > cp /etc/skel/.bashrc ~/.bashrc
tux > mv ~/.profile ~/.profile.old
tux > cp /etc/skel/.profile ~/.profile

Kopieren Sie anschließend die persönlichen Einstellungen erneut aus den *.old-Dateien.

25.1.2 Das cron-Paket

 

Mit Cron lassen Sie automatisch Kommandos im Hintergrund zu bestimmten Zeitpunkten ausführen. cron greift auf speziell formatierte Zeittabellen zu, wobei bereits mehrere standardmäßige Tabellen in diesem Werkzeug enthalten sind. Bei Bedarf können die Benutzer auch benutzerdefinierte Tabellen angeben.

Die cron-Tabellen befinden sich im Verzeichnis /var/spool/cron/tabs. /etc/crontab dient als systemübergreifende cron-Tabelle. Geben Sie den Benutzernamen zur Ausführung des Befehls unmittelbar nach der Zeittabelle und noch vor dem Befehl ein. In Beispiel 25.1, „Eintrag in /etc/crontab“, wird root eingegeben. Die paketspezifischen Tabellen in /etc/cron.d weisen alle dasselbe Format auf. Informationen hierzu finden Sie auf der man-Seite zu cron (man cron).

Beispiel 25.1: Eintrag in /etc/crontab
 
1-59/5 * * * *   root   test -x /usr/sbin/atrun && /usr/sbin/atrun

Sie können /etc/crontab nicht bearbeiten, indem Sie den Befehl crontab -e bearbeiten. Die Datei muss direkt in einem Editor geladen, geändert und dann gespeichert werden.

Mehrere Pakte installieren Shell-Skripten in die Verzeichnisse /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly und /etc/cron.monthly, deren Ausführung durch /usr/lib/cron/run-crons gesteuert wird. /usr/lib/cron/run-crons wird alle 15 Minuten von der Haupttabelle (/etc/crontab) ausgeführt. Hiermit wird gewährleistet, dass vernachlässigte Prozesse zum richtigen Zeitpunkt ausgeführt werden können.

Um die Skripten hourly, daily oder andere Skripten für regelmäßige Wartungsarbeiten zu benutzerdefinierten Zeiten auszuführen, entfernen Sie regelmäßig die Zeitstempeldateien mit /etc/crontab-Einträgen (siehe Beispiel 25.2, „/etc/crontab: Entfernen der Zeitstempeldateien“ – u. a. wird hourly vor jeder vollen Stunde und daily einmal täglich um 2:14 Uhr entfernt).

Beispiel 25.2: /etc/crontab: Entfernen der Zeitstempeldateien
 
59 *  * * *     root  rm -f /var/spool/cron/lastrun/cron.hourly
14 2  * * *     root  rm -f /var/spool/cron/lastrun/cron.daily
29 2  * * 6     root  rm -f /var/spool/cron/lastrun/cron.weekly
44 2  1 * *     root  rm -f /var/spool/cron/lastrun/cron.monthly

Sie können auch DAILY_TIME in /etc/sysconfig/cron auf die Zeit einstellen, zu der cron.daily gestartet werden soll. Mit MAX_NOT_RUN stellen Sie sicher, dass die täglichen Aufgaben auch dann ausgeführt werden, wenn der Computer zur angegebenen DAILY_TIME und auch eine längere Zeit danach nicht eingeschaltet ist. Die maximale Einstellung von MAX_NOT_RUN sind 14 Tage.

Die täglichen Systemwartungsaufträge werden zum Zwecke der Übersichtlichkeit auf mehrere Skripts verteilt. Sie sind im Paket aaa_base enthalten. /etc/cron.daily enthält beispielsweise die Komponenten suse.de-backup-rpmdb, suse.de-clean-tmp oder suse.de-cron-local.

25.1.3 Stoppen der Cron-Statusmeldungen

 

Um die Email-Flut einzudämmen, die durch die Cron-Statusmeldungen entsteht, wird der Standardwert für SEND_MAIL_ON_NO_ERROR in /etc/sysconfig/cron bei neuen Installationen auf „no“ (nein) eingestellt. Selbst mit der Einstellung "no" (nein) wird die Cron-Datenausgabe weiterhin an die MAILTO-Adresse gesendet, wie auf der man-Seite zu Cron beschrieben.

Bei einer Aktualisierung wird empfohlen, diese Werte gemäß Ihren Anforderungen einzustellen.

25.1.4 Protokolldateien: Paket logrotate

 

Mehrere Systemdienste ( Daemons) zeichnen zusammen mit dem Kernel selbst regelmäßig den Systemstatus und spezielle Ereignisse in Protokolldateien auf. Auf diese Weise kann der Administrator den Status des Systems zu einem bestimmten Zeitpunkt regelmäßig überprüfen, Fehler oder Fehlfunktionen erkennen und die Fehler mit Präzision beheben. Die Protokolldateien werden in der Regel, wie von FHS angegeben, unter /var/log gespeichert und werden täglich umfangreicher. Mit dem Paket logrotate kann der Umfang der Dateien gesteuert werden. Weitere Einzelheiten finden Sie im Book “System Analysis and Tuning Guide”, Chapter 3 “System log files”, Section 3.3 “Managing log files with logrotate”.

25.1.5 Der Befehl locate

 

locate, ein Kommando zum schnellen Suchen von Dateien, ist nicht im Standardumfang der installierten Software enthalten. Falls gewünscht, können Sie das Paket mlocate, den Nachfolger des Pakets findutils-locate, installieren. Der Prozess updatedb wird jeden Abend bzw. etwa 15 Minuten nach dem Booten des Systems gestartet.

25.1.6 Der Befehl ulimit

 

Mit dem Kommando ulimit (user limits) ist es möglich, Begrenzungen für die Verwendung von Systemressourcen festzulegen und anzuzeigen. ulimit ist besonders nützlich für die Begrenzung des verfügbaren Arbeitsspeichers für Anwendungen. Damit kann eine Anwendung daran gehindert werden, zu viele Systemressourcen zu reservieren und damit das Betriebssystem zu verlangsamen oder sogar aufzuhängen.

ulimit kann mit verschiedenen Optionen verwendet werden. Verwenden Sie zum Begrenzen der Speicherauslastung die in Tabelle 25.1, „ulimit: Einstellen von Ressourcen für Benutzer“ aufgeführten Optionen.

Tabelle 25.1: ulimit: Einstellen von Ressourcen für Benutzer
 

-m

Die maximale nicht auslagerbare festgelegte Größe

-v

Die maximale Größe des virtuellen Arbeitsspeichers, der der Shell zur Verfügung steht

-s

Die maximale Größe des Stapels

-c

Die maximale Größe der erstellten Kerndateien

-a

Alle aktuellen Grenzwerte werden gemeldet

Systemweite Standardeinträge werden unter /etc/profile festgelegt. Die direkte Bearbeitung dieser Datei wird nicht empfohlen, da die Änderungen bei einem Systemupgrade überschrieben werden. Mit /etc/profile.local können Sie die systemweiten Profileinstellungen anpassen. Benutzerspezifische Einstellungen sind unter ~USER/.profile vorzunehmen.

Beispiel 25.3: ulimit: Einstellungen in ~/.bashrc
 
# Limits maximum resident set size (physical memory):
ulimit -m 98304

# Limits of virtual memory:
ulimit -v 98304

Die Speicherzuteilungen müssen in KB erfolgen. Weitere Informationen erhalten Sie mit man bash.

Wichtig
Wichtig: Unterstützung für ulimit

ulimit-Direktiven werden nicht von allen Shells unterstützt. PAM (z. B. pam_limits) bietet umfassende Anpassungsfunktionen als Alternative zu ulimit.

25.1.7 Der Befehl free

 

Das Kommando free zeigt die Größe des insgesamt vorhandenen freien und verwendeten physischen Arbeitsspeichers und Auslagerungsspeichers im System sowie die vom Kernel verwendeten Puffer und den verwendeten Cache an. Das Konzept des verfügbaren Arbeitsspeichers geht auf Zeiten vor der einheitlichen Speicherverwaltung zurück. Bei Linux gilt der Grundsatz freier Arbeitsspeicher ist schlechter Arbeitsspeicher. Daher wurde bei Linux immer darauf geachtet, die Caches auszugleichen, ohne freien oder nicht verwendeten Arbeitsspeicher zuzulassen.

Der Kernel verfügt nicht direkt über Anwendungs- oder Benutzerdaten. Stattdessen verwaltet er Anwendungen und Benutzerdaten in einem Seiten-Cache. Falls nicht mehr genügend Arbeitsspeicher vorhanden ist, werden Teile auf der Swap-Partition oder in Dateien gespeichert, von wo aus sie mit dem Befehl mmap abgerufen werden können. (siehe man mmap).

Der Kernel enthält zusätzlich andere Caches, wie beispielsweise den slab-Cache, in dem die für den Netzwerkzugriff verwendeten Caches gespeichert werden. Dies erklärt die Unterschiede zwischen den Zählern in /proc/meminfo. Die meisten, jedoch nicht alle dieser Zähler, können über /proc/slabinfo aufgerufen werden.

Wenn Sie jedoch herausfinden möchten, wie viel RAM gerade verwendet wird, dann finden Sie diese Information in /proc/meminfo.

25.1.8 man-Seiten und Info-Seiten

 

Für einige GNU-Anwendungen (wie beispielsweise tar) sind keine man-Seiten mehr vorhanden. Verwenden Sie für diese Befehle die Option --help, um eine kurze Übersicht über die info-Seiten zu erhalten, in der Sie detailliertere Anweisungen erhalten. Die Info-Seiten befinden sich im Hypertextsystem von GNU. Eine Einführung in dieses System erhalten Sie, wenn Sie info info eingeben. Info-Seiten können mit Emacs angezeigt werden, wenn Sie emacs -f info eingeben oder mit info direkt in einer Konsole angezeigt werden. Sie können auch tkinfo, xinfo oder das Hilfesystem zum Anzeigen von info-Seiten verwenden.

25.1.9 Auswählen von man-Seiten über das Kommando man

 

Geben Sie man MAN-SEITE ein, um eine man-Seite zu lesen. Wenn bereits eine man-Seite mit demselben Namen in anderen Abschnitten vorhanden ist, werden alle vorhandenen Seiten mit den zugehörigen Abschnittsnummern aufgeführt. Wählen Sie die aus, die Sie anzeigen möchten. Wenn Sie innerhalb einiger Sekunden keine Abschnittsnummer eingeben, wird die erste man-Seite angezeigt.

Zur Rückkehr zum standardmäßigen Systemverhalten legen Sie MAN_POSIXLY_CORRECT=1 in einer Shell-Initialisierungsdatei wie ~/.bashrc fest.

25.1.10 Einstellungen für GNU Emacs

 

GNU Emacs ist eine komplexe Arbeitsumgebung. In den folgenden Abschnitten werden die beim Starten von GNU Emacs verarbeiteten Dateien beschrieben. Weitere Informationen hierzu erhalten Sie online unter http://www.gnu.org/software/emacs/.

Beim Starten liest Emacs mehrere Dateien, in denen die Einstellungen für den Benutzer, den Systemadministrator und den Distributor zur Anpassung oder Vorkonfiguration enthalten sind. Die Initialisierungsdatei ~/.emacs ist in den Home-Verzeichnissen der einzelnen Benutzer von /etc/skel installiert. .emacs wiederum liest die Datei /etc/skel/.gnu-emacs. Zum Anpassen des Programms kopieren Sie .gnu-emacs in das Home-Verzeichnis (mit cp /etc/skel/.gnu-emacs ~/.gnu-emacs) und nehmen Sie dort die gewünschten Einstellungen vor.

.gnu-emacs definiert die Datei ~/.gnu-emacs-custom als custom-file. Wenn Benutzer in Emacs Einstellungen mit den customize-Optionen vornehmen, werden die Einstellungen in ~/.gnu-emacs-custom gespeichert.

Bei SUSE Linux Enterprise Server wird mit dem emacs-Paket die Datei site-start.el im Verzeichnis /usr/share/emacs/site-lisp installiert. Die Datei site-start.el wird vor der Initialisierungsdatei ~/.emacs geladen. Mit site-start.el wird unter anderem sichergestellt, dass spezielle Konfigurationsdateien mit Emacs-Add-on-Paketen, wie psgml, automatisch geladen werden. Konfigurationsdateien dieses Typs sind ebenfalls unter /usr/share/emacs/site-lisp gespeichert und beginnen immer mit suse-start-. Der lokale Systemadministrator kann systemweite Einstellungen in default.el festlegen.

Weitere Informationen zu diesen Dateien finden Sie in der Info-Datei zu Emacs unter Init File: info:/emacs/InitFile. Informationen zum Deaktivieren des Ladens dieser Dateien (sofern erforderlich) stehen dort ebenfalls zur Verfügung.

Die Komponenten von Emacs sind in mehrere Pakete unterteilt:

  • Das Basispaket emacs.

  • emacs-x11 (in der Regel installiert): das Programm mit X11-Support.

  • emacs-nox: das Programm ohne X11-Support.

  • emacs-info: Online-Dokumentation im info-Format.

  • emacs-el: die nicht kompilierten Bibliotheksdateien in Emacs Lisp. Sie sind während der Laufzeit nicht erforderlich.

  • Verschiedene Add-On-Pakete können bei Bedarf installiert werden: emacs-auctex (LaTeX), psgml (SGML und XML), gnuserv (Client- und Server-Vorgänge) und andere.

25.2 Virtuelle Konsolen

 

Linux ist ein Multitasking-System für den Mehrbenutzerbetrieb. Die Vorteile dieser Funktionen können auch auf einem eigenständigen PC-System genutzt werden. Im Textmodus stehen sechs virtuelle Konsolen zur Verfügung. Mit den Tastenkombinationen Alt–F1 bis Alt–F6 können Sie zwischen den Konsolen umschalten. Die siebte Konsole ist für X und reserviert und in der zehnten Konsole werden Kernel-Meldungen angezeigt.

Wenn Sie von X ohne Herunterfahren zu einer anderen Konsole wechseln möchten, verwenden Sie die Tasten Strg–Alt–F1 bis Strg–Alt–F6. Mit Alt–F7 kehren Sie zu X zurück.

25.3 Tastaturbelegung

 

Um die Tastaturzuordnung der Programme zu standardisieren, wurden Änderungen an folgenden Dateien vorgenommen: 

/etc/inputrc
/etc/X11/Xmodmap
/etc/skel/.emacs
/etc/skel/.gnu-emacs
/etc/skel/.vimrc
/etc/csh.cshrc
/etc/termcap
/usr/share/terminfo/x/xterm
/usr/share/X11/app-defaults/XTerm
/usr/share/emacs/VERSION/site-lisp/term/*.el

Diese Änderungen betreffen nur Anwendungen, die terminfo-Einträge verwenden oder deren Konfigurationsdateien direkt geändert werden (vi, emacs usw.). Anwendungen, die nicht im Lieferumfang des Systems enthalten sind, sollten an diese Standards angepasst werden.

Unter X kann die Compose-Taste (Multi-Key) gemäß /etc/X11/Xmodmap aktiviert werden.

Weitere Einstellungen sind möglich mit der X-Tastaturerweiterung (XKB)

Tipp
Tipp: Weitere Informationen

Informationen zu XKB finden Sie in den Dokumenten, die unter /usr/share/doc/packages/xkeyboard-config (Teil des Pakets xkeyboard-config) aufgelistet sind.

25.4 Sprach- und länderspezifische Einstellungen

 

Das System wurde zu einem großen Teil internationalisiert und kann an lokale Gegebenheiten angepasst werden. Die Internationalisierung (I18N) ermöglicht eine spezielle Lokalisierung (L10N). Die Abkürzungen I18N und L10N wurden von den ersten und letzten Buchstaben der englischsprachigen Begriffe und der Anzahl der dazwischen stehenden ausgelassenen Buchstaben abgeleitet.

Die Einstellungen werden mit LC_-Variablen vorgenommen, die in der Datei /etc/sysconfig/language definiert sind. Dies bezieht sich nicht nur auf die native Sprachunterstützung, sondern auch auf die Kategorien Meldungen (Sprache) Zeichensatz, Sortierreihenfolge, Uhrzeit und Datum, Zahlen und Währung. Diese Kategorien können direkt über eine eigene Variable oder indirekt mit einer Master-Variable in der Datei language festgelegt werden (weitere Informationen erhalten Sie auf der man-Seite zu locale).

Liste der Variablen
 
RC_LC_MESSAGES, RC_LC_CTYPE, RC_LC_COLLATE, RC_LC_TIME, RC_LC_NUMERIC, RC_LC_MONETARY

Diese Variablen werden ohne das Präfix RC_ an die Shell weitergegeben und stehen für die aufgelisteten Kategorien. Die betreffenden Shell-Profile werden unten aufgeführt. Die aktuelle Einstellung lässt sich mit dem Befehl locale anzeigen.

RC_LC_ALL

Sofern diese Variable festgelegt ist, setzt Sie die Werte der bereits erwähnten Variablen außer Kraft.

RC_LANG

Falls keine der zuvor genannten Variablen festgelegt ist, ist dies das Fallback. Standardmäßig wird nur RC_LANG festgelegt. Dadurch wird es für die Benutzer einfacher, eigene Werte einzugeben.

ROOT_USES_LANG

Diese Variable kann auf yes oder ctype (Standardwert) festgelegt werden. Wenn sie auf yes festgelegt ist, verwendet root Spracheinstellungen und länderspezifische Einstellungen. Andernfalls arbeitet der Systemadministrator immer in einer POSIX-Umgebung.

Die Variablen können über den sysconfig-Editor von YaST festgelegt werden. Der Wert einer solchen Variable enthält den Sprachcode, den Ländercode, die Codierung und einen Modifier. Die einzelnen Komponenten werden durch Sonderzeichen verbunden: 

LANG=<language>[[_<COUNTRY>].<Encoding>[@<Modifier>]]

25.4.1 Systemweite Locale-Einstellungen

 

systemd liest /etc/locale.conf im frühen Bootvorgang aus. Die in dieser Datei konfigurierten Locale-Einstellungen werden von jedem Service oder Benutzer übernommen, falls keine individuellen Einstellungen vorgenommen wurden.

Anmerkung
Anmerkung: Verhalten älterer Konfigurationsdateien unter SUSE Linux Enterprise Server SUSE Linux Enterprise Server

In früheren Versionen las SUSE Linux Enterprise Server die Einstellungen aus den Dateien /etc/sysconfig/language, /etc/sysconfig/keyboard und /etc/sysconfig/console. Ab SUSE Linux Enterprise Server 15 GA gelten diese Dateien als veraltet. systemd liest aus diesen Dateien keine Einstellungen mehr. systemd liest stattdessen /etc/locale.conf.

Die in /etc/sysconfig/language definierten Variablen werden jedoch weiterhin verwendet, um die systemweite Locale zu überschreiben, und können dazu verwendet werden, um andere Locale-Einstellungen für Benutzer-Shells zu definieren (Informationen hierzu finden Sie in Abschnitt 25.4.2, „Einige Beispiele“).

Zum Festlegen der systemweiten Locale gehen Sie folgendermaßen vor:

  • Schreiben Sie die Einstellungen in /etc/locale.conf. Jede Zeile ist eine umgebungsartige Variablenzuweisung (eine Liste von Variablen finden Sie in man 5 locale.conf): 

    LANG=de_DE.UTF-8

    Zur Feinabstimmung der Einstellungen können Sie weitere Variablen hinzufügen, jeweils eine Variable pro Zeile.

  • Verwenden Sie das Kommando localectl: 

    root # localectl set-locale LANG=de_DE.UTF-8

    Auch hier können Sie nach dem Kommando localectl set-locale weitere Variablen angeben.

Zum Zweck der Rückwärtskompatibilität mit älteren Systemen bei der Aktualisierung des systemd-Pakets werden alle genannten Variablen von sysconfig zu den endgültigen Zielen migriert, falls sie dort nicht bereits definiert sind.

25.4.2 Einige Beispiele

 

Sprach- und Ländercode sollten immer gleichzeitig eingestellt werden. Die Spracheinstellungen entsprechen der Norm ISO 639, die unter http://www.evertype.com/standards/iso639/iso639-en.html und http://www.loc.gov/standards/iso639-2/ verfügbar ist. Die Ländercodes sind in ISO 3166 aufgeführt (siehe http://en.wikipedia.org/wiki/ISO_3166).

Es ist nur sinnvoll, Werte festzulegen, für die verwendbare Beschreibungsdateien unter /usr/lib/locale zu finden sind. Anhand der Dateien in /usr/share/i18n können mit dem Befehl localedef zusätzliche Beschreibungsdateien erstellt werden. Die Beschreibungsdateien sind Bestandteil des Pakets glibc-i18ndata. Eine Beschreibungsdatei für en_US.UTF-8 (für Englisch und USA) kann beispielsweise wie folgt erstellt werden: 

localedef -i en_US -f UTF-8 en_US.UTF-8
LANG=en_US.UTF-8

Dies ist die Standardeinstellung, wenn während der Installation US-Englisch ausgewählt wurde. Wenn Sie eine andere Sprache ausgewählt haben, wird diese Sprache ebenfalls mit der Zeichencodierung UTF-8 aktiviert.

LANG=en_US.ISO-8859-1

Hiermit wird als Sprache Englisch, als Land die USA und als Zeichensatz ISO-8859-1 festgelegt. In diesem Zeichensatz wird das Eurozeichen nicht unterstützt, es kann jedoch gelegentlich in Programmen nützlich sein, die nicht für die UTF-8-Unterstützung aktualisiert wurden. Die Zeichenkette, mit der der Zeichensatz definiert wird (in diesem Fall ISO-8859-1), wird anschließend von Programmen, wie Emacs, ausgewertet.

LANG=en_IE@euro

Im oben genannten Beispiel wird das Eurozeichen explizit in die Spracheinstellung aufgenommen. Diese Einstellung ist nun überflüssig, da UTF-8 auch das Eurosymbol enthält. Sie ist nur nützlich, wenn eine Anwendung ISO-8859-15 anstelle von UTF-8 unterstützt.

Änderungen an /etc/sysconfig/language werden mit der folgenden Prozesskette aktiviert:

  • Für die Bash: /etc/profile liest /etc/profile.d/lang.sh, die ihrerseits /etc/sysconfig/language analysiert.

  • Für tcsh: /etc/profile liest /etc/profile.d/lang.csh, die ihrerseits /etc/sysconfig/language analysiert.

So wird sichergestellt, dass sämtliche Änderungen an /etc/sysconfig/language bei der nächsten Anmeldung in der entsprechenden Shell verfügbar sind, ohne dass sie manuell aktiviert werden müssen.

Die Benutzer können die Standardeinstellungen des Systems außer Kraft setzen, indem Sie die Datei ~/.bashrc entsprechend bearbeiten. Wenn Sie die systemübergreifende Einstellung en_US für Programmmeldungen beispielsweise nicht verwenden möchten, nehmen Sie z. B. LC_MESSAGES=es_ES auf, damit die Meldungen stattdessen auf Spanisch angezeigt werden.

25.4.3 Locale-Einstellungen in ~/.i18n

 

Wenn Sie mit den Locale-Systemstandardwerten nicht zufrieden sind, können Sie die Einstellungen in ~/.i18n ändern. Achten Sie dabei jedoch auf die Einhaltung der Bash-Scripting-Syntax. Die Einträge in ~/.i18n setzen die Systemstandardwerte aus /etc/sysconfig/language außer Kraft. Verwenden Sie dieselben Variablennamen, jedoch ohne das Namespace-Präfix RC_. Nutzen Sie beispielsweise LANG anstatt RC_LANG: 

LANG=cs_CZ.UTF-8
LC_COLLATE=C

25.4.4 Einstellungen für die Sprachunterstützung

 

Die Dateien in der Kategorie Meldungen werden generell im entsprechenden Sprachverzeichnis (wie beispielsweise en) gespeichert, damit ein Fallback vorhanden ist. Wenn Sie für LANG den Wert en_US festlegen und in /usr/share/locale/en_US/LC_MESSAGES keine Meldungsdatei vorhanden ist, wird ein Fallback auf /usr/share/locale/en/LC_MESSAGES ausgeführt.

Darüber hinaus kann eine Fallback-Kette definiert werden, beispielsweise für Bretonisch zu Französisch oder für Galizisch zu Spanisch oder Portugiesisch:

LANGUAGE=„br_FR:fr_Fr“

LANGUAGE=„gl_ES:es_ES:pt_PT“

Wenn Sie möchten, können Sie die norwegischen Varianten Nynorsk und Bokmål (mit zusätzlichem Fallback auf no) verwenden:

LANG=„nn_NO“

LANGUAGE=„nn_NO:nb_NO:no“

oder

LANG=„nb_NO“

LANGUAGE=„nb_NO:nn_NO:no“

Beachten Sie, das bei Norwegisch auch LC_TIME anders behandelt wird.

Ein mögliches Problem ist, dass ein Trennzeichen, das zum Trennen von Zifferngruppen verwendet wird, nicht richtig erkannt wird. Dies passiert, wenn LANG auf einen aus zwei Buchstaben bestehenden Sprachcode wie de eingestellt ist, die Definitionsdatei, die glibc verwendet, jedoch in /usr/share/lib/de_DE/LC_NUMERIC gespeichert ist. Daher muss LC_NUMERIC auf de_DE gesetzt sein, damit das System die Trennzeichendefinition erkennen kann.

25.4.5 Weitere Informationen

 

  • The GNU C Library Reference Manual, Kapitel „Locales and Internationalization“. Es befindet sich im Paket glibc-info.

  • Markus Kuhn, UTF-8 and Unicode FAQ for Unix/Linux, momentan verfügbar unter https://www.cl.cam.ac.uk/~mgk25/unicode.html.

26 Verwendung von NetworkManager

 

NetworkManager ist die ideale Lösung für Notebooks und andere portable Computer. Es unterstützt die neuesten Verschlüsselungstypen und Standards für Netzwerkverbindungen, einschließlich Verbindungen zu Netzwerken, die nach 802.1X geschützt sind. 802.1X ist die „anschlussbasierte Netzwerkzugriffssteuerung des IEEE-Standards für lokale und innerstädtische Netzwerke“. Wenn Sie viel unterwegs sind und NetworkManager verwenden, brauchen Sie keine Gedanken mehr an die Konfiguration von Netzwerkschnittstellen und den Wechsel zwischen verkabelten und drahtlosen Netzwerken zu verschwenden. NetworkManager kann automatisch eine Verbindung zu bekannten drahtlosen Netzwerken aufbauen oder mehrere Netzwerkverbindungen parallel verwalten – die schnellste Verbindung wird in diesem Fall als Standard verwendet. Darüber hinaus können Sie zwischen verfügbaren Netzwerken manuell wechseln und Ihre Netzwerkverbindung über ein Miniprogramm im Systemabschnitt der Kontrollleiste verwalten.

Anstelle nur einer Verbindung können mehrere Verbindungen gleichzeitig aktiv sein. Dies ermöglicht Ihnen, Ihr Notebook von einem Ethernet zu trennen und drahtlos verbunden zu bleiben.

Wichtig
Wichtig:

NetworkManager wird von SUSE nur für Desktop-Arbeitslasten mit SLED oder der Arbeitsplatzrechner-Erweiterung unterstützt. Alle Serverzertifizierungen werden mit wicked als Netzwerkkonfigurationswerkzeug vorgenommen und die Verwendung von NetworkManager kann die Zertifizierungen unter Umständen ungültig machen. NetworkManager wird von SUSE nicht für Server-Arbeitslasten unterstützt.

26.1 Anwendungsfälle für den NetworkManager

 

NetworkManager enthält eine ausgereifte und intuitive Bedienoberfläche, über die Benutzer mühelos zwischen Netzwerkumgebungen wechseln können. In den folgenden Fällen ist der NetworkManager jedoch ungeeignet:

  • Ihr Computer stellt Netzwerkdienste für andere Computer in Ihrem Netzwerk bereit (es handelt sich zum Beispiel um einen DHCP- oder DNS-Server)

  • Ihr Computer ist ein Xen-Server oder Ihr System ein virtuelles System innerhalb von Xen.

26.2 Aktivieren oder Deaktivieren von NetworkManager

 

Auf Notebook-Computern ist NetworkManager standardmäßig aktiviert. Es lässt sich jedoch jederzeit im YaST-Modul „Netzwerkeinstellungen“ aktivieren oder deaktivieren.

  1. Starten Sie YaST und gehen Sie zu System › Netzwerkeinstellungen.

  2. Das Dialogfeld Netzwerkeinstellungen wird geöffnet. Klicken Sie auf den Karteireiter Globale Optionen.

  3. Zum Konfigurieren und Verwalten der Netzwerkverbindungen mit NetworkManager gehen Sie wie folgt vor:

    1. Wählen Sie im Feld Netzwerkeinrichtungsmethode die Option Benutzergesteuert mithilfe von NetworkManager.

    2. Klicken Sie auf OK, und schließen Sie YaST.

    3. Konfigurieren Sie die Netzwerkverbindungen mit NetworkManager gemäß den Anweisungen in Abschnitt 26.3, „Konfigurieren von Netzwerkverbindungen“.

  4. Zum Deaktivieren von NetworkManager und Steuern des Netzwerks mit Ihrer eigenen Konfiguration gehen Sie wie folgt vor:

    1. Wählen Sie im Feld Netzwerkeinrichtungsmethode die Option Controlled by wicked (Steuerung mit wicked).

    2. Klicken Sie auf OK.

    3. Richten Sie Ihre Netzwerkkarte mit YaST mithilfe der automatischen Konfiguration durch DHCP oder mithilfe einer statischen IP-Adresse ein.

      Eine ausführliche Beschreibung der Netzwerkkonfiguration mit YaST finden Sie in Abschnitt 19.4, „Konfigurieren von Netzwerkverbindungen mit YaST“.

26.3 Konfigurieren von Netzwerkverbindungen

 

Konfigurieren Sie nach der Aktivierung von NetworkManager in YaST Ihre Netzwerkverbindungen mit dem NetworkManager-Frontend, das in GNOME verfügbar ist. Hier sehen Sie Registerkarten für alle Arten von Netzwerkverbindungen, z. B. verkabelte, drahtlose, mobile Breitband-, DSL- und VPN-Verbindungen.

Tipp
Tipp: NetworkManager-Verbindungs-Editor

In früheren Versionen von SUSE Linux Enterprise Server wurden Netzwerkverbindungen mit der Anwendung NetworkManager-Verbindungs-Editor konfiguriert. Diese Anwendung wird standardmäßig nicht mehr installiert, da das GNOME-Kontrollzentrum ihre Konfigurationsfunktionen vollständig ersetzt.

Wenn Sie Netzwerkverbindungen weiterhin mit dem NetworkManager-Verbindungs-Editor konfigurieren möchten, installieren Sie das Paket NetworkManager-connection-editor manuell: 

tux > sudo zypper install NetworkManager-connection-editor

Zum Öffnen des Dialogfelds für die Netzwerkkonfiguration in GNOME öffnen Sie aus dem Statusmenü das Einstellungsmenü, und klicken Sie dort auf den Eintrag Netzwerk.

Anmerkung
Anmerkung: Verfügbarkeit von Optionen

Abhängig von Ihrer Systemeinrichtung dürfen Sie möglicherweise keine Verbindungen konfigurieren. In einer abgesicherten Umgebung sind eventuell einige Optionen gesperrt oder erfordern eine root-Berechtigung. Erfragen Sie Einzelheiten bei Ihrem Systemadministrator.

Dialogfeld „Netzwerkverbindungen“ in GNOME
Abbildung 26.1: Dialogfeld „Netzwerkverbindungen“ in GNOME
 
Vorgehen 26.1: Hinzufügen und Bearbeiten von Verbindungen
 

  1. Öffnen Sie das Dialogfeld „NetworkManager-Konfiguration“.

  2. So fügen Sie eine Verbindung hinzu:

    1. Klicken Sie links unten auf das +-Symbol.

    2. Wählen Sie den von Ihnen bevorzugten Verbindungstyp aus, und folgen Sie den Anweisungen.

    3. Wenn Sie fertig sind, klicken Sie auf Hinzufügen.

    4. Nach Bestätigen der Änderungen wird die neu konfigurierte Netzwerkverbindung in der Liste der verfügbaren Netzwerke im Statusmenü angezeigt.

  3. So bearbeiten Sie eine Verbindung:

    1. Wählen Sie den zu bearbeitenden Eintrag aus.

    2. Klicken Sie auf das Zahnradsymbol, um das Dialogfeld Verbindungseinstellungen zu öffnen.

    3. Nehmen Sie die gewünschten Änderungen vor und klicken Sie auf Anwenden, um diese zu speichern.

    4. Wenn die Verbindung als Systemverbindung zur Verfügung stehen soll, wechseln Sie zur Registerkarte Identität und aktivieren Sie dort das Kontrollkästchen Anderen Benutzern zur Verfügung stellen. Weitere Informationen zu Benutzer- und Systemverbindungen finden Sie unter Abschnitt 26.4.1, „Benutzer- und Systemverbindungen“.

26.3.1 Verwalten von kabelgebundenen Netzwerkverbindungen

 

Wenn Ihr Computer mit einem kabelgebundenen Netzwerk verbunden ist, verwenden Sie NetworkManager zur Verwaltung der Verbindung.

  1. Öffnen Sie das Statusmenü und klicken Sie auf Verkabelt, um die Verbindungsdetails zu ändern oder die Verbindung zu deaktivieren.

  2. Zum Ändern der Einstellungen klicken Sie auf Einstellungen für kabelgebundenes Netzwerk und danach auf das Zahnradsymbol.

  3. Zum Deaktivieren aller Netzwerkverbindungen aktivieren Sie den Flugzeugmodus.

26.3.2 Verwalten von drahtlosen Netzwerkverbindungen

 

Die sichtbaren drahtlosen Netzwerke werden im Menü des GNOME NetworkManager-Miniprogramms unter Drahtlose Netzwerke aufgeführt. Die Signalstärke der einzelnen Netzwerke wird ebenfalls im Menü angezeigt. Verschlüsselte drahtlose Netzwerke sind mit einem blauen Schildsymbol gekennzeichnet.

Vorgehen 26.2: Verbinden mit einem sichtbaren drahtlosen Netzwerk
 

  1. Zum Verbinden mit einem sichtbaren drahtlosen Netzwerk öffnen Sie das Statusmenü, und klicken Sie auf WLAN.

  2. Klicken Sie auf Aktivieren.

  3. Klicken Sie auf Netzwerk auswählen, wählen Sie Ihr drahtloses Netzwerk aus, und klicken Sie auf Verbinden.

  4. Wenn das Netzwerk verschlüsselt ist, öffnet sich ein Konfigurationsdialogfeld. Es gibt den Verschlüsselungstyp des Netzwerks an und enthält Textfelder für die Eingabe der Anmeldedaten.

Vorgehen 26.3: Verbinden mit einem nicht sichtbaren drahtlosen Netzwerk
 

  1. Zum Verbinden mit einem Netzwerk, das seine Dienstkennung (SSID oder ESSID) nicht aussendet und daher nicht automatisch erkannt werden kann, öffnen Sie das Statusmenü und klicken Sie auf WLAN.

  2. Klicken Sie auf WLAN-Einstellungen, um das detaillierte Einstellungsmenü zu öffnen.

  3. Stellen Sie sicher, dass Ihr drahtloses Netzwerk aktiviert ist, und klicken Sie dann auf Mit verborgenem Netzwerk verbinden.

  4. Geben Sie im daraufhin angezeigten Dialogfeld unter Netzwerkname die SSID oder ESSID ein und legen Sie gegebenenfalls die Verschlüsselungsparameter fest.

Die Verbindung zu einem drahtlosen Netzwerk, das explizit gewählt wurde, wird so lange wie möglich aufrecht erhalten. Wenn dabei ein Netzwerkkabel angeschlossen ist, werden alle Verbindungen, für die Stay connected when possible (Nach Möglichkeit verbunden bleiben) festgelegt wurde, hergestellt, während die drahtlose Verbindung bestehen bleibt.

26.3.3 Konfigurieren der WLAN-/Bluetooth-Karte als Zugriffspunkt

 

Wenn Ihre WLAN-/Bluetooth-Karte den Zugriffspunktmodus unterstützt, können Sie NetworkManager zur Konfiguration verwenden.

  1. Öffnen Sie das Statusmenü, und klicken Sie auf WLAN.

  2. Klicken Sie auf WLAN-Einstellungen, um das detaillierte Einstellungsmenü zu öffnen.

  3. Klicken Sie auf Als Hotspot verwenden und folgen Sie den Anweisungen.

  4. Verwenden Sie zur Verbindung mit dem Hotspot von einem Remote-Computer die im Dialogfeld angezeigten Anmeldedaten.

26.3.4 NetworkManager und VPN

 

NetworkManager unterstützt verschiedene Technologien für virtuelle private Netzwerke (VPN). Für jede Technologie bietet SUSE Linux Enterprise Server ein Basispaket mit generischer Unterstützung für NetworkManager. Zusätzlich müssen Sie auch das entsprechende Desktop-spezifische Paket für Ihr Miniprogramm installieren.

OpenVPN

Installieren Sie zur Verwendung dieser VPN-Technik:

  • NetworkManager-openvpn

  • NetworkManager-openvpn-gnome

OpenConnect

Installieren Sie zur Verwendung dieser VPN-Technik:

  • NetworkManager-openconnect

  • NetworkManager-openconnect-gnome

PPTP (Point-to-Point-Tunneling-Protokoll)

Installieren Sie zur Verwendung dieser VPN-Technik:

  • NetworkManager-pptp

  • NetworkManager-pptp-gnome

Im folgenden Verfahren wird beschrieben, wie Sie Ihren Computer mithilfe von NetworkManager als OpenVPN-Client einrichten können. Das Einrichten anderer VPN-Typen funktioniert auf die gleiche Weise.

Stellen Sie sicher, dass das Paket NetworkManager-openvpn-gnome installiert ist und alle Abhängigkeiten aufgelöst wurden, bevor Sie starten.

Vorgehen 26.4: Einrichten von OpenVPN mit NetworkManager
 

  1. Öffnen Sie die Einstellungen der Anwendung, indem Sie auf die Statussymbole am rechten Ende der Kontrollleiste und anschließend auf das Symbol mit dem Schraubenschlüssel und dem Schraubendreher klicken. Wählen Sie im Fenster All Settings (Alle Einstellungen) die Option Network (Netzwerk).

  2. Klicken Sie auf das Symbol +.

  3. Wählen Sie VPN und anschließend OpenVPN aus.

  4. Wählen Sie bei Authentication den Authentifizierungstyp. Wählen Sie entsprechend der Konfiguration Ihres OpenVPN-Servers, Certificates (TLS) (Zertifikate (TLS) oder Password with Certificates (TLS) (Passwort mit Zertifikaten (TLS)).

  5. Geben Sie die erforderlichen Werte in die entsprechenden Textfelder ein. In unserem Beispiel sind dies:

    Gateway

    Der Remote-Endpunkt des VPN-Servers

    User name (Benutzername)

    Der Benutzer (nur verfügbar, wenn Sie Password with Certificates (TLS) ausgewählt haben)

    Password (Passwort)

    Das Passwort für den Benutzer (nur verfügbar, wenn Sie Password with Certificates (TLS) ausgewählt haben)

    User Certificate (Benutzerzertifikat)

    /etc/openvpn/client1.crt

    CA Certificate (CA-Zertifikat)

    /etc/openvpn/ca.crt

    Private Key (Privater Schlüssel)

    /etc/openvpn/client1.key

  6. Schließen Sie die Konfiguration ab, indem Sie auf Add (Hinzufügen) klicken.

  7. Um die Verbindung zu aktivieren, klicken Sie in der Kontrollleiste Netzwerk der Anwendung Einstellungen auf den Umschalter. Alternativ können Sie auf die Statussymbole am rechten Ende der Kontrollleiste klicken. Klicken Sie auf den Namen Ihres VPN und dann auf Verbinden.

26.4 NetworkManager und Sicherheit

 

Der NetworkManager unterscheidet zwischen zwei Typen von drahtlosen Verbindungen: verbürgte und unverbürgte Verbindungen. Eine verbürgte Verbindung ist jedes Netzwerk, das Sie in der Vergangenheit explizit ausgewählt haben. Alle anderen sind unverbürgt. Verbürgte Verbindungen werden anhand des Namens und der MAC-Adresse des Zugriffspunkts identifiziert. Durch Verwendung der MAC-Adresse wird sichergestellt, dass Sie keinen anderen Zugriffspunkt mit dem Namen Ihrer verbürgten Verbindung verwenden können.

NetworkManager scannt in regelmäßigen Abständen nach verfügbaren drahtlosen Netzwerken. Wenn mehrere verbürgte Netzwerke gefunden werden, wird automatisch das zuletzt verwendete ausgewählt. Wenn keines der Netzwerke vertrauenswürdig ist, wartet NetworkManager auf Ihre Auswahl.

Wenn die Verschlüsselungseinstellung geändert wird, aber Name und MAC-Adresse gleich bleiben, versucht NetworkManager, eine Verbindung herzustellen. Zuvor werden Sie jedoch aufgefordert, die neuen Verschlüsselungseinstellungen zu bestätigen und Aktualisierungen, z. B. einen neuen Schlüssel, bereitzustellen.

Wenn Sie von der Verwendung einer drahtlosen Verbindung in den Offline-Modus wechseln, blendet NetworkManager die SSID oder ESSID aus. So wird sichergestellt, dass die Karte nicht mehr verwendet wird.

26.4.1 Benutzer- und Systemverbindungen

 

NetworkManager kennt zwei Verbindungsarten: Benutzer- und System-Verbindungen.

Für Benutzerverbindungen müssen alle Benutzer im NetworkManager authentifiziert werden. Darin werden die Berechtigungsnachweise der Benutzer in deren lokalen GNOME-Schlüsselbunden gespeichert. Benutzer müssen Sie daher nicht mehr erneut eingeben, wenn Sie sich verbinden.

Systemverbindungen sind automatisch für alle Benutzer verfügbar. Der erste Benutzer, der die Verbindung herstellt, gibt die erforderliche Berechtigung ein. Danach haben alle anderen Benutzer Zugriff, ohne die Berechtigung kennen zu müssen. Die Konfiguration einer Benutzerverbindung unterscheidet sich von der Konfiguration einer Systemverbindung nur durch ein Kontrollkästchen: Anderen Benutzern zur Verfügung stellen. Informationen zum Konfigurieren von Benutzer- oder Systemverbindungen mit NetworkManager finden Sie unter Abschnitt 26.3, „Konfigurieren von Netzwerkverbindungen“.

26.4.2 Speichern von Passwörtern und Berechtigungsnachweisen

 

Wenn Sie Ihre Berechtigungsnachweise nicht bei jedem Verbindungsversuch mit einem verschlüsselten Netzwerk erneut eingeben wollen, können Sie den GNOME Keyring Manager verwenden, um Ihre Berechtigungsnachweise verschlüsselt und durch Master-Passwort geschützt auf der Festplatte zu speichern.

26.4.3 Firewall-Zonen

 
firewalld-Zonen in NetworkManager
Abbildung 26.2: firewalld-Zonen in NetworkManager
 

Die Firewall-Zonen legen allgemeine Regeln zu den zulässigen Netzwerkverbindungen fest. Zum Konfigurieren der firewalld-Zone für eine verkabelte Verbindung öffnen Sie die Registerkarte Identität der Verbindungseinstellungen. Zum Konfigurieren der firewalld-Zone für eine WLAN-Verbindung öffnen Sie die Registerkarte Sicherheit der Verbindungseinstellungen.

Wenn Sie sich in Ihrem Heimatnetz befinden, verwenden Sie die private Zone. Bei öffentlichen kabellosen Netzwerken wechseln Sie zur öffentlichen Zone. Wenn Sie sich in einer sicheren Umgebung befinden und alle Verbindungen zulassen möchten, verwenden Sie die verbürgte Zone.

Details zu firewalld finden Sie im Book “Security and Hardening Guide”, Chapter 23 “Masquerading and firewalls”, Section 23.4 “firewalld”.

26.5 Häufig gestellte Fragen

 

Nachfolgend finden Sie einige häufig gestellte Fragen zum Konfigurieren spezieller Netzwerkoptionen mit NetworkManager.

1. Wie kann eine Verbindung an ein bestimmtes Gerät gebunden werden?

Standardmäßig sind Verbindungen in NetworkManager gerätetypspezifisch: Sie gelten für alle physischen Geräte desselben Typs. Wenn mehrere physische Geräte pro Verbindungsart verfügbar sind (z. B. wenn Ihr Gerät mit zwei Ethernet-Karten ausgestattet ist), können Sie eine Verbindung an ein bestimmtes Gerät binden.

Schlagen Sie dafür in GNOME zunächst die MAC-Adresse Ihres Geräts in der Verbindungsinformation nach, die über das Miniprogramm zur Verfügung steht, oder verwenden Sie die Ausgabe von Kommandozeilenwerkzeugen wie nm-tool oder wicked show all. Starten Sie dann das Dialogfeld zur Konfiguration von Netzwerkverbindungen und wählen Sie die Verbindung aus, die Sie ändern möchten. Geben Sie auf der Registerkarte Verkabelt oder Drahtlos die MAC-Adresse des Geräts ein und bestätigen Sie Ihre Änderungen.

2. Wie wird ein bestimmter Zugriffspunkt angegeben, wenn mehrere Zugriffspunkte mit derselben ESSID erkannt werden?

Wenn mehrere Zugriffspunkte mit unterschiedlichen Funkfrequenzbereichen (a/b/g/n) verfügbar sind, wird standardmäßig der Zugriffspunkt mit dem stärksten Signal automatisch gewählt. Um diesen Vorgang außer Kraft zu setzen, verwenden Sie das Feld BSSID beim Konfigurieren Ihrer drahtlosen Verbindungen.

Der Basic Service Set Identifier (BSSID) identifiziert jedes Basic Service Set eindeutig. In einem Basic Service Set der Infrastruktur entspricht die BSSID der MAC-Adresse des drahtlosen Zugriffspunkts. In einem unabhängigen (Ad-hoc) Basic Service Set entspricht die BSSID einer lokal verwalteten MAC-Adresse, die aus einer 46-Bit-Zufallszahl generiert wird.

Starten Sie den Dialog die die Konfiguration von Netzwerkverbindungen wie in Abschnitt 26.3, „Konfigurieren von Netzwerkverbindungen“ beschrieben. Wählen Sie die drahtlose Verbindung, die Sie ändern möchten, und klicken Sie auf Bearbeiten. Geben Sie im Karteireiter Drahtlos die BSSID ein.

3. Wie werden Netzwerkverbindungen mit anderen Computern freigegeben?

Das primäre Gerät (das Gerät, das mit dem Internet verbunden ist) benötigt keine spezielle Konfiguration. Jedoch müssen Sie das Gerät, das mit dem lokalen Hub oder Computer verbunden ist, wie folgt konfigurieren:

  1. Starten Sie den Dialog düe die Konfiguration von Netzwerkverbindungen wie in Abschnitt 26.3, „Konfigurieren von Netzwerkverbindungen“ beschrieben. Wählen Sie die Verbindung, die Sie ändern möchten, und klicken Sie auf Bearbeiten. Wechseln Sie zum Karteireiter IPv4-Einstellungen und aktivieren Sie im Dropdown-Feld Methode die Option Shared to other computers (Für andere Computer freigegeben). Damit ist die Weiterleitung von IP-Netzwerkverkehr möglich und ein DHCP-Server wird auf dem Gerät ausgeführt. Bestätigen Sie Ihre Änderungen in NetworkManager.

  2. Da der DCHP-Server den Port 67 verwendet, stellen Sie sicher, dass dieser nicht durch die Firewall blockiert ist: Starten Sie YaST auf dem Computer, der die Verbindungen nutzen möchte, und wählen Sie Sicherheit und Benutzer › Firewall. Wechseln Sie zur Kategorie Erlaubte Dienste. Wenn DCHP-Server nicht bereits als Erlaubter Dienst angezeigt ist, wählen Sie DCHP-Server aus Services to Allow (Erlaubte Dienste) und klicken Sie auf Hinzufügen. Bestätigen Sie Ihre Änderungen in YaST.

4. Wie kann statische DNS-Information mit automatischen (DHCP-, PPP-, VPN-) Adressen bereitgestellt werden?

Falls ein DHCP-Server ungültige DNS-Informationen (und/oder Routen) liefert, können Sie diese überschreiben. Starten Sie den Dialog düe die Konfiguration von Netzwerkverbindungen wie in Abschnitt 26.3, „Konfigurieren von Netzwerkverbindungen“ beschrieben. Wählen Sie die Verbindung, die Sie ändern möchten, und klicken Sie auf Bearbeiten. Öffnen Sie den Karteireiter IPv4-Einstellungen und aktivieren Sie im Dropdown-Feld Methode die Option Automatic (DHCP) addresses only (Nur automatische (DHCP-)Adressen). Geben Sie die DNS-Information in die Felder DNS-Server und Suchdomänen ein. Sollen automatisch abgerufene Routen ignoriert werden, klicken Sie auf Routes (Routen) und aktivieren Sie das Kontrollkästchen Ignore automatically obtained routes (Automatisch abgerufene Routen ignorieren). Bestätigen Sie Ihre Änderungen.

5. Wie kann NetworkManager dazu veranlasst werden, eine Verbindung zu passwortgeschützten Netzwerken aufzubauen, bevor sich ein Benutzer anmeldet?

Definieren Sie eine Systemverbindung, die für solche Zwecke verwendet werden kann. Weitere Informationen hierzu finden Sie im Abschnitt 26.4.1, „Benutzer- und Systemverbindungen“.

26.6 Fehlersuche

 

Es können Verbindungsprobleme auftreten. Bei NetworkManager sind unter anderem die Probleme bekannt, dass das Miniprogramm nicht startet oder eine VPN-Option fehlt. Die Methoden zum Lösen und Verhindern dieser Probleme hängen vom verwendeten Werkzeug ab.

NetworkManager-Desktop-Applet wird nicht gestartet

Das Miniprogramm wird automatisch gestartet, wenn das Netzwerk für die NetworkManager-Steuerung eingerichtet ist. Wenn das Miniprogramm/Widget nicht gestartet wird, überprüfen Sie, ob NetworkManager in YaST aktiviert ist (siehe Abschnitt 26.2, „Aktivieren oder Deaktivieren von NetworkManager“). Überprüfen Sie dann, ob das NetworkManager-gnome-Paket installiert ist.

Wenn das Desktop-Miniprogramm installiert ist, aber nicht ausgeführt wird, starten Sie es manuell über das Kommando nm-applet.

Das NetworkManager-Applet beinhaltet keine VPN-Option

Die Unterstützung für NetworkManager-Miniprogramme sowie VPN für NetworkManager wird in Form separater Pakete verteilt. Wenn Ihr NetworkManager-Applet keine VPN-Option enthält, überprüfen Sie, ob die Pakete mit der NetworkManager-Unterstützung für Ihre VPN-Technologie installiert sind. Weitere Informationen finden Sie im Abschnitt 26.3.4, „NetworkManager und VPN“.

Keine Netzwerkverbindung verfügbar

Wenn Sie Ihre Netzwerkverbindung korrekt konfiguriert haben und alle anderen Komponenten für die Netzwerkverbindung (Router etc.) auch gestartet sind und ausgeführt werden, ist es manchmal hilfreich, die Netzwerkschnittstellen auf Ihrem Computer erneut zu starten. Melden Sie sich dazu bei einer Befehlszeile als root an und führen Sie den Befehl systemctl restart wicked aus.

26.7 Weitere Informationen

 

Weitere Informationen zu NetworkManager finden Sie auf den folgenden Websites und in folgenden Verzeichnissen:

Projektseite des NetworkManagers

https://gitlab.freedesktop.org/NetworkManager/NetworkManager

Dokumentation zu den einzelnen Paketen

Sehen Sie sich auch die neuesten Informationen zu NetworkManager und dem GNOME-Miniprogramm in den folgenden Verzeichnissen an:

  • /usr/share/doc/packages/NetworkManager/,

  • /usr/share/doc/packages/NetworkManager-gnome/.

27 Energieverwaltung

 

IBM Z Die in diesem Kapitel beschriebenen Funktionen und Hardware-Elemente sind auf IBM Z-Plattformen nicht vorhanden. Das Kapitel ist für diese Plattformen daher irrelevant.

Die Energieverwaltung ist insbesondere bei Notebook-Computern von großer Wichtigkeit, sie ist jedoch auch für andere Systeme sinnvoll. ACPI (Advanced Configuration & Power Interface) ist auf allen modernen Computern (Laptops, Desktops, Server) verfügbar. Für Energieverwaltungstechnologien sind geeignete Hardware- und BIOS-Routinen erforderlich. Die meisten Notebooks und modernen Desktops und Server erfüllen diese Anforderungen. Es ist außerdem möglich, die CPU-Frequenzskalierung zu steuern, um Energie zu sparen oder den Geräuschpegel zu senken.

27.1 Energiesparfunktionen

 

Energiesparfunktionen sind nicht nur für die mobile Verwendung von Notebooks von Bedeutung, sondern auch für Desktop-Systeme. Die Hauptfunktionen und ihre Verwendung im ACPI sind:

Standby

Nicht unterstützt.

Suspend (in Arbeitsspeicher)

In diesem Modus wird der gesamte Systemstatus in den RAM geschrieben. Anschließend wird das gesamte System mit Ausnahme des RAM in den Ruhezustand versetzt. In diesem Zustand verbraucht der Computer sehr wenig Energie. Der Vorteil dieses Zustands besteht darin, dass innerhalb weniger Sekunden die Arbeit nahtlos wieder aufgenommen werden kann, ohne dass ein Booten des Systems oder ein Neustart der Anwendungen erforderlich ist. Diese Funktion entspricht ACPI-Zustand S3.

Tiefschlaf (Suspend to Disk)

In diesem Betriebsmodus wird der gesamte Systemstatus auf die Festplatte geschrieben und das System wird von der Energieversorgung getrennt. Es muss eine Swap-Partition vorhanden sein, die mindestens die Größe des RAM hat, damit alle aktiven Daten geschrieben werden können. Die Reaktivierung von diesem Zustand dauert ungefähr 30 bis 90 Sekunden. Der Zustand vor dem Suspend-Vorgang wird wiederhergestellt. Einige Hersteller bieten Hybridvarianten dieses Modus an, beispielsweise RediSafe bei IBM Thinkpads. Der entsprechende ACPI-Zustand ist S4. In Linux wird „suspend to disk“ über Kernel-Routinen durchgeführt, die von ACPI unabhängig sind.

Anmerkung
Anmerkung: Geänderte UUID für Swap-Partitionen bei Formatierung über mkswap

Falls möglich, sollten bestehende Swap-Partitionen nicht mit mkswap neu formatiert werden. Durch die Neuformatierung mit mkswap ändert sich der UUID-Wert der Swap-Partition. Führen Sie die Neuformatierung entweder über YaST aus (/etc/fstab wird dabei aktualisiert) oder passen Sie /etc/fstab manuell an.

Akkuüberwachung

ACPI überprüft den Akkuladestatus und stellt entsprechende Informationen bereit. Außerdem koordiniert es die Aktionen, die beim Erreichen eines kritischen Ladestatus durchzuführen sind.

Automatisches Ausschalten

Nach dem Herunterfahren wird der Computer ausgeschaltet. Dies ist besonders wichtig, wenn der Computer automatisch heruntergefahren wird, kurz bevor der Akku leer ist.

Steuerung der Prozessorgeschwindigkeit

In Verbindung mit der CPU gibt es drei Möglichkeiten, Energie zu sparen: Frequenz- und Spannungsskalierung (auch PowerNow! oder Speedstep), Drosselung und Versetzen des Prozessors in den Ruhezustand (C-Status). Je nach Betriebsmodus des Computers können diese Methoden auch kombiniert werden.

27.2 Advanced Configuration & Power Interface (ACPI)

 

Die ACPI (erweiterte Konfigurations- und Energieschnittstelle) wurde entwickelt, um dem Betriebssystem die Einrichtung und Steuerung der einzelnen Hardware-Komponenten zu ermöglichen. ACPI löst sowohl Power-Management Plug and Play (PnP) als auch Advanced Power Management (APM) ab. Diese Schnittstelle bietet Informationen zu Akku, Netzteil, Temperatur, Ventilator und Systemereignissen wie „Deckel schließen“ oder „Akku-Ladezustand niedrig“.

Das BIOS bietet Tabellen mit Informationen zu den einzelnen Komponenten und Hardware-Zugriffsmethoden. Das Betriebssystem verwendet diese Informationen für Aufgaben wie das Zuweisen von Interrupts oder das Aktivieren bzw. Deaktivieren von Komponenten. Da das Betriebssystem die in BIOS gespeicherten Befehle ausführt, hängt die Funktionalität von der BIOS-Implementierung ab. Die Tabellen, die ACPI erkennen und laden kann, werden in journald gemeldet. Weitere Informationen zum Abrufen der Protokollmeldungen im Journal finden Sie unter Kapitel 17, journalctl: Abfragen des systemd-Journals. Weitere Informationen zur Fehlersuche bei ACPI-Problemen finden Sie in Abschnitt 27.2.2, „Fehlersuche“.

27.2.1 Steuern der CPU-Leistung

 

Mit der CPU sind Energieeinsparungen auf drei verschiedene Weisen möglich:

  • Frequenz- und Spannungsskalierung

  • Drosseln der Taktfrequenz (T-Status)

  • Versetzen des Prozessors in den Ruhezustand (C-Status)

Je nach Betriebsmodus des Computers können diese Methoden auch kombiniert werden. Energiesparen bedeutet auch, dass sich das System weniger erhitzt und die Ventilatoren seltener in Betrieb sind.

Frequenzskalierung und Drosselung sind nur relevant, wenn der Prozessor belegt ist, da der sparsamste C-Zustand ohnehin gilt, wenn sich der Prozessor im Wartezustand befindet. Wenn die CPU belegt ist, ist die Frequenzskalierung die empfohlene Energiesparmethode. Häufig arbeitet der Prozessor nur im Teillast-Betrieb. In diesem Fall kann er mit einer niedrigeren Frequenz betrieben werden. Im Allgemeinen empfiehlt sich die dynamische Frequenzskalierung mit Steuerung durch den On-Demand-Governor im Kernel.

Drosselung sollte nur als letzter Ausweg verwendet werden, um die Betriebsdauer des Akkus trotz hoher Systemlast zu verlängern. Einige Systeme arbeiten bei zu hoher Drosselung jedoch nicht reibungslos. Außerdem hat die CPU-Drosselung keinen Sinn, wenn die CPU kaum ausgelastet ist.

Detaillierte Informationen hierzu finden Sie im Book “System Analysis and Tuning Guide”, Chapter 12 “Power management”.

27.2.2 Fehlersuche

 

Es gibt zwei verschiedene Arten von Problemen. Einerseits kann der ACPI-Code des Kernel Fehler enthalten, die nicht rechtzeitig erkannt wurden. In diesem Fall wird eine Lösung zum Herunterladen bereitgestellt. Häufiger werden die Probleme vom BIOS verursacht. Manchmal werden Abweichungen von der ACPI-Spezifikation absichtlich in das BIOS integriert, um Fehler in der ACPI-Implementierung in anderen weit verbreiteten Betriebssystemen zu umgehen. Hardware-Komponenten, die ernsthafte Fehler in der ACPI-Implementierung aufweisen, sind in einer Blacklist festgehalten, die verhindert, dass der Linux-Kernel ACPI für die betreffenden Komponenten verwendet.

Der erste Schritt, der bei Problemen unternommen werden sollte, ist die Aktualisierung des BIOS. Wenn der Computer sich nicht booten lässt, kann eventuell einer der folgenden Bootparameter Abhilfe schaffen:

pci=noacpi

ACPI nicht zum Konfigurieren der PCI-Geräte verwenden.

acpi=ht

Nur eine einfache Ressourcenkonfiguration durchführen. ACPI nicht für andere Zwecke verwenden.

acpi=off

ACPI deaktivieren.

Warnung
Warnung: Probleme beim Booten ohne ACPI

Einige neuere Computer (insbesondere SMP- und AMD64-Systeme) benötigen ACPI zur korrekten Konfiguration der Hardware. Bei diesen Computern kann die Deaktivierung von ACPI zu Problemen führen.

Manchmal ist der Computer durch Hardware gestört, die über USB oder FireWire angeschlossen ist. Wenn ein Computer nicht hochfährt, stecken Sie nicht benötigte Hardware aus und versuchen Sie es erneut.

Überwachen Sie nach dem Booten die Bootmeldungen des Systems mit dem Befehl dmesg -T | grep -2i acpi (oder überwachen Sie alle Meldungen, da das Problem möglicherweise nicht durch ACPI verursacht wurde). Wenn bei der Analyse einer ACPI-Tabelle ein Fehler auftritt, kann die wichtigste Tabelle – die DSDT (Differentiated System Description Table) – durch eine verbesserte Version ersetzt werden. In diesem Fall wird die fehlerhafte DSDT des BIOS ignoriert. Das Verfahren wird in Abschnitt 27.4, „Fehlerbehebung“ erläutert.

In der Kernel-Konfiguration gibt es einen Schalter zur Aktivierung der ACPI-Fehlersuchmeldungen. Wenn ein Kernel mit ACPI-Fehlersuche kompiliert und installiert ist, werden detaillierte Informationen angezeigt.

Wenn Sie Probleme mit dem BIOS oder der Hardware feststellen, sollten Sie stets Kontakt mit den betreffenden Herstellern aufweisen. Insbesondere Hersteller, die nicht immer Hilfe für Linux anbieten, sollten mit den Problemen konfrontiert werden. Die Hersteller nehmen das Problem nur dann ernst, wenn sie feststellen, dass eine nennenswerte Zahl ihrer Kunden Linux verwendet.

27.2.2.1 Weitere Informationen

 

27.3 Ruhezustand für Festplatte

 

In Linux kann die Festplatte vollständig ausgeschaltet werden, wenn sie nicht benötigt wird, oder sie kann in einem energiesparenderen oder ruhigeren Modus betrieben werden. Bei modernen Notebooks müssen die Festplatten nicht manuell ausgeschaltet werden, da sie automatisch in einen Sparbetriebsmodus geschaltet werden, wenn sie nicht benötigt werden. Um die Energieeinsparungen zu maximieren, sollten Sie jedoch einige der folgenden Verfahren mit dem Kommando hdparm ausprobieren.

Hiermit können verschiedene Festplatteneinstellungen bearbeitet werden. Die Option -y schaltet die Festplatte sofort in den Stand-by-Modus. -Y versetzt sie in den Ruhezustand. hdparm -S X führt dazu, dass die Festplatte nach einem bestimmten Inaktivitätszeitraum abgeschaltet wird. Ersetzen Sie X wie folgt: 0 deaktiviert diesen Mechanismus, sodass die Festplatte kontinuierlich ausgeführt wird. Werte von 1 bis 240 werden mit 5 Sekunden multipliziert. Werte von 241 bis 251 entsprechen 1- bis 11-mal 30 Minuten.

Die internen Energiesparoptionen der Festplatte lassen sich über die Option -B steuern. Wählen Sie einen Wert 0 (maximale Energieeinsparung) bis 255 (maximaler Durchsatz). Das Ergebnis hängt von der verwendeten Festplatte ab und ist schwer einzuschätzen. Die Geräuschentwicklung einer Festplatte können Sie mit der Option -M reduzieren. Wählen Sie einen Wert von 128 (ruhig) bis 254 (schnell).

Häufig ist es nicht so einfach, die Festplatte in den Ruhezustand zu versetzen. Bei Linux führen zahlreiche Prozesse Schreibvorgänge auf der Festplatte durch, wodurch diese wiederholt aus dem Ruhezustand reaktiviert wird. Daher sollten Sie unbedingt verstehen, wie Linux mit Daten umgeht, die auf die Festplatte geschrieben werden müssen. Zunächst werden alle Daten im RAM-Puffer gespeichert. Dieser Puffer wird vom pdflush-Daemon überwacht. Wenn die Daten ein bestimmtes Alter erreichen oder wenn der Puffer bis zu einem bestimmten Grad gefüllt ist, wird der Pufferinhalt auf die Festplatte übertragen. Die Puffergröße ist dynamisch und hängt von der Größe des Arbeitsspeichers und von der Systemlast ab. Standardmäßig werden für pdflush kurze Intervalle festgelegt, um maximale Datenintegrität zu erreichen. Das Programm überprüft den Puffer alle fünf Sekunden und schreibt die Daten auf die Festplatte. Die folgenden Variablen sind interessant:

/proc/sys/vm/dirty_writeback_centisecs

Enthält die Verzögerung bis zur Reaktivierung eines pdflush-Threads (in Hundertstelsekunden).

/proc/sys/vm/dirty_expire_centisecs

Definiert, nach welchem Zeitabschnitt eine schlechte Seite spätestens geschrieben werden sollte. Der Standardwert ist 3000, was 30 Sekunden bedeutet.

/proc/sys/vm/dirty_background_ratio

Maximaler Prozentsatz an schlechten Seiten, bis pdflush damit beginnt, sie zu schreiben. Die Standardeinstellung ist 5 %.

/proc/sys/vm/dirty_ratio

Wenn die schlechten Seiten diesen Prozentsatz des gesamten Arbeitsspeichers überschreiten, werden Prozesse gezwungen, während ihres Zeitabschnitts Puffer mit schlechten Seiten anstelle von weiteren Daten zu schreiben.

Warnung
Warnung: Datenintegritätsrisiko

Änderungen an den Einstellungen für den pdflush-Aktualisierungs-Daemon können die Datenintegrität beeinträchtigen.

Abgesehen von diesen Prozessen schreiben protokollierende Journaling-Dateisysteme, wie Btrfs, Ext3, Ext4 und andere ihre Metadaten unabhängig von pdflush, was ebenfalls das Abschalten der Festplatte verhindert.

Ein weiterer wichtiger Faktor ist die Art und Weise, wie sich die Programme verhalten. Gute Editoren beispielsweise schreiben regelmäßig verborgene Sicherungskopien der aktuell bearbeiteten Datei auf die Festplatte, wodurch die Festplatte wieder aktiviert wird. Derartige Funktionen können auf Kosten der Datenintegrität deaktiviert werden.

In dieser Verbindung verwendet der Mail-Daemon postfix die Variable POSTFIX_LAPTOP. Wenn diese Variable auf ja gesetzt wird, greift postfix wesentlich seltener auf die Festplatte zu.

27.4 Fehlerbehebung

 

Alle Fehler- und Alarmmeldungen werden im Systemjournal gespeichert, das Sie mit dem Kommando journalctl abrufen können (weitere Informationen siehe Kapitel 17, journalctl: Abfragen des systemd-Journals). In den folgenden Abschnitten werden die häufigsten Probleme behandelt.

27.4.1 CPU-Frequenzsteuerung funktioniert nicht

 

Rufen Sie die Kernel-Quellen auf, um festzustellen, ob der verwendete Prozessor unterstützt wird. Möglicherweise ist ein spezielles Kernel-Modul bzw. eine Moduloption erforderlich, um die CPU-Frequenzsteuerung zu aktivieren. Wenn das kernel-source-Paket installiert ist, finden Sie diese Informationen unter /usr/src/linux/Documentation/cpu-freq/*.

28 Permanenter Speicher

 

Dieses Kapitel enthält weitere Informationen zur Verwendung von SUSE Linux Enterprise mit nicht-flüchtigem Hauptspeicher, auch als permanenter Speicher bekannt, der aus einem oder mehreren NVDIMMs besteht.

28.1 Einführung

 

Ein permanenter Speicher ist eine neue Art von Speicherung am Rechner. Er kombiniert annähernd so hohe Geschwindigkeiten wie bei dynamischen RAMs (DRAMs) mit der Byte-für-Byte-Adressierbarkeit des RAM und der Permanenz von Solid-State Disks (SSDs).

SUSE unterstützt aktuell die Verwendung eines permanenten Speichers mit SUSE Linux Enterprise Server auf Rechnern mit AMD64/Intel 64- und POWER-Architekturen.

Wie bei herkömmlichen RAMs wird der permanente Speicher direkt am Speichersteckplatz der Hauptplatine installiert. Damit wird er im selben physischen Formfaktor bereitgestellt wie RAM – als DIMMs. Man nennt sie NVDIMMs: Non-Volatile Dual Inline Memory Modules.

Im Unterschied zu RAM ist ein permanenter Speicher in vielerlei Hinsicht Flash-basierten SSDs ähnlich. Beide basieren auf unterschiedliche Weise auf dem Stromkreis von Festkörperspeichern, bieten aber unabhängig davon einen nicht-flüchtigen Speicher. Dies bedeutet, dass ihre Inhalte beibehalten werden, wenn das System heruntergefahren oder neu gestartet wird. Bei beiden Varianten geht das Schreiben von Daten langsamer von statten als das Lesen und beide unterstützen eine begrenzte Anzahl von Neuschreibungszyklen. Wie bei SSDs ist der Zugriff auf Sektorebene des permanenten Speichers möglich, sollte dies für eine bestimmte Anwendung erforderlich sein.

Die unterschiedlichen Modelle verwenden verschiedene Arten von elektronischen Speichermedien, wie Intel 3D XPoint oder eine Kombination aus NAND-Flash und DRAM. Neue Arten von nicht-flüchtigen RAMs werden derzeit entwickelt. Verschiedene Anbieter und Modelle von NVDIMMs bieten unterschiedliche Eigenschaften für Leistung und Langlebigkeit.

Da sich die entsprechenden Speichertechnologien noch in der frühen Entwicklungsphase befinden, ist bei der Hardware verschiedener Anbieter möglicherweise mit unterschiedlichen Einschränkungen zu rechnen. Daher sind die folgenden Aussagen als Verallgemeinerungen zu betrachten.

Ein permanenter Speicher ist bis zu zehn mal langsamer als DRAM, doch in etwa tausend mal schneller als Flash-Speicher. Im Gegensatz zum Vorgang des Auslöschens und Neuschreibens des gesamten Sektors beim Flash-Speicher kann der permanente Speicher auf Byte-zu-Byte-Basis neu geschrieben werden. Da die Neuschreibungszyklen begrenzt sind, können permanente Speicher schließlich Millionen von Neuschreibungen verarbeiten, verglichen mit Tausenden von Zyklen des Flash-Speichers.

Das hat zwei erhebliche Folgen:

  • Beim aktuellen Stand der Technik ist es nicht möglich, ein System nur mit permanentem Speicher auszuführen und dadurch einen gänzlich nicht-flüchtigen Hauptspeicher zu erzielen. Sie müssen einen herkömmlichen RAM mit NVDIMMs kombinieren. Das Betriebssystem und die Anwendungen werden am herkömmlichen RAM ausgeführt und NVDIMMs bieten eine sehr schnelle ergänzende Speichermöglichkeit.

  • Aufgrund der Leistungsmerkmale der permanenten Speicher von verschiedenen Anbietern müssen Programmierer möglicherweise die Hardwarespezifikationen der NVDIMMs an einem bestimmten Server berücksichtigen, einschließlich deren Anzahl und belegten Speichersteckplätze. Dies wirkt sich offensichtlich auf die Verwendung des Hypervisors aus sowie auf die Migration von Software zwischen verschiedenen Host-Rechnern usw.

Dieses neue Speicher-Untersystem ist in Version 6 des ACPI-Standards definiert. libnvdimm unterstützt jedoch NVDIMMs, die den Standard noch nicht erfüllen, wodurch diese auf gleiche Weise verwendet werden können.

28.2 Begriffe

 
Region

Eine Region ist ein Block des permanenten Speichers, der in einen oder mehrere Namespaces unterteilt werden kann. Der Zugriff auf den permanenten Speicher einer Region ist erst nach dessen Zuordnung zu einem Namespace möglich.

Namespace

Ein einzelner zusammenhängend adressierter Bereich eines nicht-flüchtigen Speichers, vergleichbar mit NVM Express SSD-Namespaces oder SCSI Logical Units (LUNs). Namespaces werden im /dev-Verzeichnis des Servers als separate Blockgeräte angezeigt. Abhängig von der erforderlichen Zugriffsmethode können Namespaces entweder Speicherplatz von verschiedenen NVDIMMs in größere Volumes zusammenfassen oder dessen Partitionierung in kleinere Volumes zulassen.

Modus

Jeder Namespace weist auch einen Modus auf, der definiert, welche NVDIMM-Funktionen für diesen Namespace aktiviert sind. Gleichgeordnete Namespaces der selben übergeordneten Region sind im Typ immer gleich, werden jedoch möglicherweise mit verschiedenen Modi konfiguriert. Namespace-Modi:

devdax

Geräte-DAX-Modus. Erstellt eine Einzelzeichen-Gerätedatei ( /dev/daxX.Y ). Die Erstellung eines Dateisystems ist nicht erforderlich.

fsdax

Dateisystem-DAX-Modus. Standardmodus, falls kein anderer Modus angegeben wird. Erstellt ein Blockgerät (/dev/pmemX [.Y]), das DAX für ext4 oder XFS unterstützt.

sector

Für veraltete Dateisysteme, die keine Checksumme für Metadaten erstellen. Geeignet für kleine Boot-Volumes. Kompatibel mit anderen Betriebssystemen.

raw

Ein Speicherdatenträger ohne Kennung oder Metadaten. Keine Unterstützung von DAX. Kompatibel mit anderen Betriebssystemen.

Anmerkung
Anmerkung

Der raw-Modus wird von SUSE nicht unterstützt. Es ist nicht möglich, Dateisysteme auf raw-Namespaces einzuhängen.

Typ

Jeder Namespace und jede Region weist einen Typ auf, der definiert, auf welche Weise auf den permanenten Speicher, der mit diesem Namespace oder dieser Region verknüpft ist, zugegriffen wird. Ein Namespace hat immer denselben Typ wie dessen übergeordnete Region. Zwei verschiedene Typen stehen zur Verfügung: Permanenter Speicher, der auf zwei verschiedene Arten konfiguriert werden kann, sowie der veraltete Block-Modus.

Permanenter Speicher (PMEM)

Der PMEM-Speicher bietet Zugriff auf Byte-Ebene, genauso wie RAM. Mit PMEM kann ein einzelner Namespace mehrere überlappende NVDIMMs enthalten und alle können als Einzelgerät verwendet werden.

Ein PMEM-Namespace kann auf zwei Arten konfiguriert werden.

PMEM mit DAX

Ein für den Direktzugriff (DAX) konfigurierter Namespace bedeutet, dass beim Zugreifen auf den Arbeitsspeicher der Seiten-Cache des Kernels umgangen und direkt auf das Medium zugegriffen wird. Die Software kann jedes Byte des Namespace separat lesen oder schreiben.

PMEM mit BTT (Block Translation Table)

Wie bei einem herkömmlichen Festplattenlaufwerk wird auf einen für den Betrieb im BTT-Modus konfigurierten PMEM-Namespace Sektor für Sektor zugegriffen, im Unterschied zu dem eher RAM-ähnlichen Byte-adressierbaren Modell. Durch einen Übersetzungstabellen-Mechanismus werden die Zugriffe in Einheiten von Sektorgröße eingeteilt.

Der Vorteil von BTT ist der Datenschutz. Das Speicher-Untersystem sorgt dafür, dass jeder Sektor vollständig auf das zugrunde liegende Medium geschrieben wird. Wenn ein Sektor nicht vollständig geschrieben wird (also wenn der Schreibvorgang aus jeglichen Gründen fehlschlägt), wird ein Rollback des gesamten Sektors auf den ursprünglichen Status vorgenommen. Daher kann ein Sektor nicht teilweise geschrieben werden.

Der Zugriff auf BTT-Namespaces wird zudem vom Kernel im Cache gespeichert.

Der Nachteil ist, dass kein Direktzugriff auf BTT-Namespaces möglich ist.

Block-Modus (BLK)

Beim Speichern im Block-Modus wird jeder NVDIMM als separates Gerät adressiert. Dieser Modus ist inzwischen veraltet und wird nicht mehr unterstützt.

Abgesehen von devdax-Namespaces müssen alle anderen Typen mit einem Dateisystem formatiert werden, genau wie bei einem herkömmlichen Laufwerk. SUSE Linux Enterprise Server unterstützt dafür die Dateisysteme ext2, ext4 und XFS.

Direktzugriff (Direct Access, DAX)

Durch DAX kann ein permanenter Speicher direkt im Adressbereich eines Prozesses zugeordnet werden, beispielsweise über den Systemaufruf mmap.

Physikalische DIMM-Adresse (DPA)

Eine Speicheradresse als Offset in den Speicher eines einzelnen DIMMs, das heißt beginnend bei Null als niedrigstem adressierbaren Byte in diesem DIMM.

Kennung

Im NVDIMM gespeicherte Metadaten wie beispielsweise Namespace-Definitionen. Der Zugriff ist über DSM möglich.

Gerätespezifische Methode (Device-specific method, DSM)

ACPI-Methode für den Zugriff auf die Firmware eines NVDIMM.

28.3 Einsatzbereiche

 

28.3.1 PMEM mit DAX

 

Es ist wichtig zu wissen, dass diese Art von Speicherzugriff keine Transaktion ist. Im Fall eines Stromausfalls oder eines anderen Systemfehlers werden die Daten möglicherweise nicht vollständig in den Speicher geschrieben. Ein PMEM-Speicher ist nur für Anwendungen geeignet, die teilweise geschriebene Daten verarbeiten können.

28.3.1.1 Anwendungen, die von einem großen Byte-adressierbaren Speicher profitieren

 

Wenn am Server eine Anwendung gehostet wird, die direkt einen großen Teil eines schnellen Speichers Byte für Byte verwendet, kann der Programmierer mit dem Systemaufruf mmap Blöcke des permanenten Speichers direkt in den Adressbereich der Anwendung stellen, ohne auf zusätzlichen System-RAM zurückgreifen zu müssen.

28.3.1.2 Vermeiden des Kernel-Seiten-Caches

 

Vermeiden Sie den Kernel-Seiten-Cache, wenn Sie den RAM für den Seiten-Cache aufsparen und ihn stattdessen anderen Anwendungen zuweisen möchten. Dieser könnte beispielsweise zum Speichern von VM-Images vorgesehen werden. Diese Images würden nicht in den Cache gestellt werden, was die Cache-Auslastung am Host reduzieren und mehr VMs pro Host zulassen würde.

28.3.2 PMEM mit BTT

 

Diese Variante ist nützlich, wenn Sie den permanenten Speicher auf einigen NVDIMMs als einen Datenträger-ähnlichen Pool von sehr schnellen Speichern verwenden möchten. Wird beispielsweise das Dateisystemjournal auf PMEM mit BTT platziert, erhöht sich dadurch die Zuverlässigkeit der Dateisystemwiederherstellung nach Stromausfall oder sonstiger plötzlicher Unterbrechung (siehe Abschnitt 28.5.3, „Erstellen eines PMEM-Namespace mit BTT“).

Anwendungen halten diese Geräte für sehr schnelle SSDs, die wie jedes andere Speichergerät verwendet werden. LVM kann beispielsweise auf den permanenten Speicher aufgesetzt werden und funktioniert normal.

BTT hat den Vorteil, dass die Unteilbarkeit beim Schreiben in den Sektor gewährleistet ist. Somit bleiben sogar sehr anspruchsvolle und von Datenintegrität abhängige Anwendungen funktionsfähig. Die Erstellung von Fehlerberichten funktioniert über standardmäßige Kanäle zur Fehlerberichterstellung.

28.4 Tools zur Verwaltung eines permanenten Speichers

 

Zur Verwaltung eines permanenten Speichers muss das Paket ndctl installiert werden. Dadurch wird auch das Paket libndctl installiert. Es enthält einige Benutzerbereich-Bibliotheken zum Konfigurieren von NVDIMMs.

Diese Tools arbeiten mit der Bibliothek libnvdimm, die drei Typen von NVDIMM unterstützt:

  • PMEM

  • BLK

  • PMEM und BLK gleichzeitig

Das ndctl-Dienstprogramm enthält einige nützliche man-Seiten, auf die mit dem folgenden Kommando zugegriffen wird: 

tux > ndctl help subcommand

Eine Liste der verfügbaren Unterkommandos erhalten Sie mit: 

tux > ndctl --list-cmds

Folgende Unterkommandos stehen zur Verfügung:

version

Zeigt die aktuelle Version der NVDIMM-Unterstützungstools an.

enable-namespace

Stellt den angegebenen Namespace zur Verfügung.

disable-namespace

Verhindert die Verwendung des angegebenen Namespace.

create-namespace

Erstellt einen neuen Namespace aus den angegebenen Speichergeräten.

destroy-namespace

Entfernt den angegebenen Namespace.

enable-region

Stellt die angegebene Region zur Verfügung.

disable-region

Verhindert die Verwendung der angegebenen Region.

zero-labels

Löscht die Metadaten von einem Gerät.

read-labels

Ruft die Metadaten vom angegebenen Gerät ab.

list

Zeigt verfügbare Geräte an.

help

Zeigt Informationen zur Verwendung des Tools an.

28.5 Einrichten eines permanenten Speichers

 

28.5.1 Anzeigen des verfügbaren NVDIMM-Speichers

 

Mit dem Kommando ndctl list werden alle verfügbaren NVDIMMs in einem System aufgelistet.

Im folgenden Beispiel hat das System drei NVDIMMs, die sich in einem einzelnen, dreikanaligen überlappenden Set befinden. 

root # ndctl list --dimms

[
 {
  "dev":"nmem2",
  "id":"8089-00-0000-12325476"
 },
 {
  "dev":"nmem1",
  "id":"8089-00-0000-11325476"
 },
 {
  "dev":"nmem0",
  "id":"8089-00-0000-10325476"
 }
]

Mit einem anderen Parameter listet ndctl list auch die verfügbaren Regionen auf.

Anmerkung
Anmerkung

Regionen erscheinen möglicherweise nicht in numerischer Reihenfolge.

Beachten Sie, dass zwar nur drei NVDIMMs vorhanden sind, doch vier Regionen angezeigt werden. 

root # ndctl list --regions

[
 {
  "dev":"region1",
  "size":68182605824,
  "available_size":68182605824,
  "type":"blk"
 },
 {
  "dev":"region3",
  "size":202937204736,
  "available_size":202937204736,
  "type":"pmem",
  "iset_id":5903239628671731251
  },
  {
   "dev":"region0",
   "size":68182605824,
   "available_size":68182605824,
   "type":"blk"
  },
  {
   "dev":"region2",
   "size":68182605824,
   "available_size":68182605824,
   "type":"blk"
  }
]

Der Speicherplatz ist auf zwei verschiedene Arten verfügbar: entweder als drei separate 64 GB-Regionen vom Typ BLK oder als eine kombinierte 189 GB-Region vom Typ PMEM, die den gesamten Speicherplatz auf den drei überlappenden NVDIMMs als ein einziges Volume darstellt.

Beachten Sie, dass der angezeigte Wert für available_size identisch ist mit dem Wert für size. Dies bedeutet, dass noch kein Speicherplatz zugeordnet wurde.

28.5.2 Konfigurieren des Speichers als einzelnen PMEM-Namespace mit DAX

 

Im ersten Beispiel konfigurieren wir unsere drei NVDIMMs in einem einzelnen PMEM-Namespace mit Direktzugriff (DAX).

Im ersten Schritt erstellen wir einen neuen Namespace. 

root # ndctl create-namespace --type=pmem --mode=fsdax --map=memory
{
 "dev":"namespace3.0",
 "mode":"memory",
 "size":199764213760,
 "uuid":"dc8ebb84-c564-4248-9e8d-e18543c39b69",
 "blockdev":"pmem3"
}

Dadurch wird ein Blockgerät /dev/pmem3 erstellt, das DAX unterstützt. Die 3 im Gerätenamen wird von der Nummer der übergeordneten Region übernommen, in diesem Fall region3.

Die Option --map=memory reserviert einen Teil des PMEM-Speicherplatzes auf den NVDIMMs für die Zuordnung interner Kernel-Datenstrukturen namens struct pages. Dadurch kann der neue PMEM-Namespace mit Funktionen wie O_DIRECT I/O und RDMA verwendet werden.

Aufgrund der Reservierung eines Teils des permanenten Speichers für Kernel-Datenstrukturen hat der resultierende PMEM-Namespace eine geringere Kapazität als die übergeordnete PMEM-Region.

Als nächstes überprüfen wir, ob das neue Blockgerät für das Betriebssystem verfügbar ist: 

root # fdisk -l /dev/pmem3
Disk /dev/pmem3: 186 GiB, 199764213760 bytes, 390164480 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Bevor es verwendet werden kann, muss es wie jedes andere Gerät formatiert werden. In diesem Beispiel formatieren wir es mit XFS: 

root # mkfs.xfs /dev/pmem3
meta-data=/dev/pmem3      isize=256    agcount=4, agsize=12192640 blks
         =                sectsz=4096  attr=2, projid32bit=1
         =                crc=0        finobt=0, sparse=0
data     =                bsize=4096   blocks=48770560, imaxpct=25
         =                sunit=0      swidth=0 blks
naming   =version 2       bsize=4096   ascii-ci=0 ftype=1
log      =internal log    bsize=4096   blocks=23813, version=2
         =                sectsz=4096  sunit=1 blks, lazy-count=1
realtime =none            extsz=4096   blocks=0, rtextents=0

Danach können wir das neue Laufwerk in ein Verzeichnis einhängen: 

root # mount -o dax /dev/pmem3 /mnt/pmem3

Dann überprüfen wir, ob wir nun über ein DAX-fähiges Gerät verfügen: 

root # mount | grep dax
/dev/pmem3 on /mnt/pmem3 type xfs (rw,relatime,attr2,dax,inode64,noquota)

Das Ergebnis ist ein PMEM-Namespace, der mit dem XFS-Dateisystem formatiert und mit DAX eingehängt ist.

mmap()-Aufrufe von Dateien in diesem Dateisystem geben virtuelle Adressen zurück, die direkt dem permanenten Speicher auf unseren NVDIMMs zugeordnet werden. Der Seiten-Cache wird dabei voll umgangen.

fsync- oder msync-Aufrufe von Dateien in diesem Dateisystem stellen weiterhin sicher, dass geänderte Daten vollständig in die NVDIMMs geschrieben werden. Diese Aufrufe löschen die Zeilen des Prozessor-Cache, die mit Seiten verknüpft sind, die im Benutzerbereich über mmap-Zuordnungen geändert wurden.

28.5.2.1 Entfernen eines Namespace

 

Bevor wir einen anderen Volume-Typ erstellen, der den selben Speicher verwendet, müssen wir das PMEM-Volume aushängen und dann entfernen.

Hängen Sie es zunächst aus: 

root # umount /mnt/pmem3

Deaktivieren Sie dann den Namespace: 

root # ndctl disable-namespace namespace3.0
disabled 1 namespace

Löschen Sie es nun: 

root # ndctl destroy-namespace namespace3.0
destroyed 1 namespace

28.5.3 Erstellen eines PMEM-Namespace mit BTT

 

BTT sorgt für Unteilbarkeit beim Schreiben in den Sektor, was es zu einer guten Wahl macht, wenn Datenschutz erforderlich ist, zum Beispiel für Ext4- und XFS-Journale. Bei Stromausfall sind die Journale geschützt und sollten wiederherstellbar sein. Die folgenden Beispiele zeigen, wie ein PMEM-Namespace mit BTT im Sektormodus erstellt und wie das Dateisystemjournal in diesem Namespace platziert wird. 

root # ndctl create-namespace --type=pmem --mode=sector
{
 "dev":"namespace3.0",
 "mode":"sector",
 "uuid":"51ab652d-7f20-44ea-b51d-5670454f8b9b",
 "sector_size":4096,
 "blockdev":"pmem3s"
}

Überprüfen Sie als Nächstes, ob das Gerät vorhanden ist: 

root # fdisk -l /dev/pmem3s
Disk /dev/pmem3s: 188.8 GiB, 202738135040 bytes, 49496615 sectors
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Wie der vorher konfigurierte DAX-fähige PMEM-Namespace verbraucht dieser BTT-fähige Namespace den gesamten verfügbaren Speicherplatz auf den NVDIMMs.

Anmerkung
Anmerkung

Das angehängte s am Ende des Gerätenamens (/dev/pmem3s) steht für sector. Damit lassen sich Namespaces, die zur Verwendung von BTT konfiguriert wurden, leicht unterscheiden.

Das Volume wird wie im vorigen Beispiel formatiert und eingehängt.

Der hier gezeigte PMEM-Namespace kann DAX nicht verwenden. Stattdessen verwendet er BTT für die Unteilbarkeit beim Schreiben des Sektors. Bei jedem Schreiben des Sektors über den PMEM-Blocktreiber ordnet BTT einen neuen Sektor zu, um neue Daten zu empfangen. BTT aktualisiert ungeteilt die internen Zuordnungsstrukturen, nachdem alle neuen Daten vollständig geschrieben sind, sodass die neu geschriebenen Daten den Anwendungen zur Verfügung stehen. Wenn zu irgendeinem Zeitpunkt dieses Vorgangs der Strom ausfällt, sind alle geschriebenen Daten verloren und die Anwendung hat Zugriff auf die alten Daten, die noch intakt sind. Dadurch wird der Zustand der sogenannten „zerrissenen Sektoren“ verhindert.

Dieser BTT-fähige PMEM-Namespace wird wie ein Dateisystem formatiert und verwendet, genau wie jedes andere Standard-Blockgerät. Die Verwendung mit DAX ist nicht möglich. mmap-Zuordnungen für Dateien auf diesem Blockgerät verwenden jedoch den Seiten-Cache.

28.5.4 Platzieren des Dateisystemjournals auf PMEM/BTT

 

Wird das Dateisystemjournal auf einem separaten Gerät platziert, muss es dieselbe Dateisystem-Blockgröße wie das Dateisystem verwenden. Sie beträgt höchstwahrscheinlich 4096 und Sie finden die Blockgröße mit diesem Kommando: 

root # blockdev --getbsz /dev/sda3

Im folgenden Beispiel wird ein neues Ext4-Journal auf einem separaten NVDIMM-Gerät erstellt und das Dateisystem auf einem SATA-Gerät. Dann wird das neue Dateisystem an das Journal angehängt: 

root # mke2fs -b 4096 -O journal_dev /dev/pmem3s
root # mkfs.ext4 -J device=/dev/pmem3s /dev/sda3

Im folgenden Beispiel wird ein neues XFS-Dateisystem auf einem SATA-Laufwerk erstellt und das Journal auf einem separaten NVDIMM-Gerät: 

root # mkfs.xfs -l logdev=/dev/pmem3s  /dev/sda3

Detaillierte Informationen zu den Optionen finden Sie in man 8 mkfs.ext4 und man 8 mkfs.ext4.

28.6 Weitere Informationen

 

Für weitere Informationen zu diesem Thema siehe die folgende Liste:

  • Permanenter Speicher – Wiki

    Enthält Anweisungen zum Konfigurieren von NVDIMM-Systemen, Informationen zu Tests sowie Links zu Spezifikationen für die Aktivierung von NVDIMMs. Diese Site wird im Zuge der NVDIMM-Unterstützung in Linux entwickelt.

  • Permanenter Speicher – Programmierung

    Informationen zum Konfigurieren, Verwenden und Programmieren von Systemen mit nicht-flüchtigem Speicher unter Linux und anderen Betriebssystemen. Behandelt die NVM-Bibliothek (NVML), die nützliche APIs zum Programmieren mit permanentem Speicher im Benutzerbereich bereitstellt.

  • LIBNVDIMM: Nicht-flüchtige Geräte

    Für Kernel-Entwickler gedacht und Teil des Dokumentationsordners im aktuellen Linux-Kernel-Baum. Es beschreibt die verschiedenen Kernel-Module, die an der NVDIMM-Aktivierung beteiligt sind, gibt einige technische Details zur Kernel-Implementierung und erläutert die sysfs-Schnittstelle zum Kernel, die vom ndctl-Tool verwendet wird.

  • GitHub: pmem/ndctl

    Dienstprogramm-Bibliothek zur Verwaltung des libnvdimm-Untersystems im Linux-Kernel. Enthält zudem Benutzerbereich-Bibliotheken sowie Einheitentests und eine Dokumentation.

Teil IV Services

 
  • 29 Serviceverwaltung mit YaST

    • YaST umfasst einen Service-Manager zum Steuern des standardmäßigen Systemziels und der Services, zum Anzeigen des Servicestatus und Lesen der Protokolldatei. Neu in SUSE Linux Enterprise Server 15 SP3 ist die YaST-Unterstützung für die Aktivierung des Socket-basierten Service mit Systemd. Dadurch werden die Services so konfiguriert, dass Sie auf Abruf starten.

  • 30 Zeitsynchronisierung mit NTP

    • Der NTP-(Network Time Protocol-)Mechanismus ist ein Protokoll für die Synchronisierung der Systemzeit über das Netzwerk. Erstens kann ein Computer die Zeit von einem Server abrufen, der als zuverlässige Zeitquelle gilt. Zweitens kann ein Computer selbst für andere Computer im Netzwerk als Zeitquelle fungieren. Es gibt zwei Ziele – das Aufrechterhalten der absoluten Zeit und das Synchronisieren der Systemzeit aller Computer im Netzwerk.

  • 31 Domain Name System (DNS)

    • DNS (Domain Name System) ist zur Auflösung der Domänen- und Hostnamen in IP-Adressen erforderlich. So wird die IP-Adresse 192.168.2.100 beispielsweise dem Hostnamen jupiter zugewiesen. Bevor Sie Ihren eigenen Namenserver einrichten, sollten Sie die allgemeinen Informationen zu DNS in Abschnitt 19.3, „Namensauflösung“ lesen. Die folgenden Konfigurationsbeispiele gelten für BIND, den standardmäßigen DNS-Server.

  • 32 DHCP

    • DHCP (Dynamic Host Configuration Protocol) dient dazu, Einstellungen in einem Netzwerk zentral (von einem Server) aus zuzuweisen. Einstellungen müssen also nicht dezentral an einzelnen Arbeitsplatzcomputern konfiguriert werden. Ein für DHCP konfigurierter Host verfügt nicht über eine eigene statische Adresse. Er konfiguriert sich stattdessen vollständig und automatisch nach den Vorgaben des DHCP-Servers. Wenn Sie auf der Clientseite den NetworkManager verwenden, brauchen Sie den Client nicht zu konfigurieren. Das ist nützlich, wenn Sie in wechselnden Umgebungen arbeiten und nur jeweils eine Schnittstelle aktiv ist. Verwenden Sie den NetworkManager nie auf einem Computer, der einen DHCP-Server ausführt.

  • 33 SLP

    • Um einen Netzwerkclient konfigurieren zu können, benötigen Sie eingehende Kenntnisse zu den Diensten, die über das Netzwerk bereitgestellt werden (z. B. Drucken oder LDAP). Als Erleichterung der Konfiguration dieser Dienste auf einem Netzwerkclient wurde das SLP („service location protocol“) entwickelt. SLP teilt allen Clients im lokalen Netzwerk die Verfügbarkeit und die Konfigurationsdaten ausgewählter Dienste mit. Anwendungen mit SLP-Unterstützung können diese Informationen verarbeiten und damit automatisch konfiguriert werden.

  • 34 Der HTTP-Server Apache

    • Gemäß der Umfrage von http://www.netcraft.com/ ist der HTTP-Server Apache (oder kurz „Apache“) weltweit der meistgenutzte Webserver. Der von der Apache Software Foundation (http://www.apache.org/) entwickelte Apache-Server läuft auf fast allen Betriebssystemen. SUSE® Linux Enterprise Server umfasst Apache, Version 2.4. In diesem Kapitel erfahren Sie, wie Apache installiert, konfiguriert und eingerichtet wird. Sie lernen SSL, CGI und weitere Module kennen und erfahren, wie Sie bei Problemen mit dem Webserver vorgehen.

  • 35 Einrichten eines FTP-Servers mit YaST

    • Mithilfe des YaST-FTP-Server-Moduls können Sie Ihren Rechner für die Funktion als FTP (File Transfer Protocol)-Server konfigurieren. Anonyme bzw. authentifizierte Benutzer können mithilfe des FTP-Protokolls eine Verbindung zu Ihrem Rechner herstellen und Dateien herunterladen. Abhängig von der Konfiguration können sie auch Dateien auf den FTP-Server hochladen. YaST nutzt vsftpd (Very Secure FTP Daemon).

  • 36 Caching-Proxyserver Squid

    • Squid ist ein häufig verwendeter Caching-Proxyserver für Linux- und UNIX-Plattformen. Das bedeutet, dass er angeforderte Internetobjekte, wie beispielsweise Daten auf einem Web- oder FTP-Server, auf einem Computer speichert, der sich näher an der Arbeitsstation befindet, die die Anforderung ausgegeben hat, als der Server. Er kann in mehreren Hierarchien eingerichtet werden. So werden optimale Reaktionszeiten und die Nutzung einer niedrigen Bandbreite garantiert – auch bei Modi, die für den Endbenutzer transparent sind.

  • 37 Web Based Enterprise Management mit SFCB

29 Serviceverwaltung mit YaST

 

YaST umfasst einen Service-Manager zum Steuern des standardmäßigen Systemziels und der Services, zum Anzeigen des Servicestatus und Lesen der Protokolldatei. Neu in SUSE Linux Enterprise Server 15 SP3 ist die YaST-Unterstützung für die Aktivierung des Socket-basierten Service mit Systemd. Dadurch werden die Services so konfiguriert, dass Sie auf Abruf starten.

Systemd unterstützt das Starten von Services mit Socket-basierter Aktivierung auf Abruf. Diese Services weisen zwei Arten von Einheiten auf: Service und Socket. Beispielsweise wird CUPS mit cups.service und cups.socket gesteuert. YaST ermöglicht Ihnen die Auswahl des gewünschten Servicestarts.

In Abbildung 29.1, „YaST Service-Manager“ sehen Sie die Optionen im Dropdown-Menü Startmodus: Beim Booten, Auf Abruf und Manuell. Wählen Sie für die Socket-basierte Aktivierung die Option Auf Abruf aus. Damit wird ein Netzwerk-Socket zur Überwachung geöffnet und der Service startet nach einer Anforderung.

YaST Service-Manager
Abbildung 29.1: YaST Service-Manager
 

Die Option Auf Abruf ist nur für Services sichtbar, die diese Option unterstützen. Aktuell sind dies nur einige wenige Services wie CUPS, dbus, iscsid, iscsiuio, multipathd, pcscd, rpcbind, tftp, virtlockd, virtlogd. Detaillierte Informationen zur Funktionsweise der Socket-Aktivierung finden Sie in man 5 systemd.socket.

30 Zeitsynchronisierung mit NTP

 

Der NTP-(Network Time Protocol-)Mechanismus ist ein Protokoll für die Synchronisierung der Systemzeit über das Netzwerk. Erstens kann ein Computer die Zeit von einem Server abrufen, der als zuverlässige Zeitquelle gilt. Zweitens kann ein Computer selbst für andere Computer im Netzwerk als Zeitquelle fungieren. Es gibt zwei Ziele – das Aufrechterhalten der absoluten Zeit und das Synchronisieren der Systemzeit aller Computer im Netzwerk.

Das Aufrechterhalten der genauen Systemzeit ist in vielen Situationen wichtig. Die integrierte Hardware-Uhr erfüllt häufig nicht die Anforderungen bestimmter Anwendungen, beispielsweise Datenbanken oder Cluster. Die manuelle Korrektur der Systemzeit würde schwerwiegende Probleme nach sich ziehen; das Zurückstellen kann beispielsweise zu Fehlfunktionen wichtiger Anwendungen führen. Die Systemzeiten der in einem Netzwerk zusammengeschlossenen Computer müssen in der Regel synchronisiert werden. Es empfiehlt sich aber nicht, die Zeiten manuell anzugleichen. Vielmehr sollten Sie dazu NTP verwenden. Der NTP-Dienst passt die Systemzeit ständig anhand zuverlässiger Zeitserver im Netzwerk an. Zudem ermöglicht er die Verwaltung lokaler Referenzuhren, beispielsweise funkgesteuerter Uhren.

Ab SUSE Linux Enterprise Server 15 ist chrony Standardimplementation von NTP. chrony besteht aus zwei Teilen; der Daemonchronyd kann beim Booten gestartet werden und mit dem Kommandozeilenschnittstellenprogramm chronyc ist es möglich, die Leistung von chronyd zu überwachen und verschiedene Betriebsparameter zur Laufzeit zu ändern.

Ab SUSE Linux Enterprise Server 15.2 konfiguriert das YaST-Modul für die NTP-Client-Konfiguration den systemd-timer anstelle des cron daemon, um chrony auszuführen, wenn es nicht zur Ausführung als Daemon konfiguriert ist.

30.1 Konfigurieren eines NTP-Clients mit YaST

 

Der NTP-Daemon (chronyd) im chrony-Paket ist so voreingestellt, dass die Hardware-Uhr des lokalen Computers als Zeitreferenz verwendet wird. Die Präzision einer Hardware-Uhr ist stark von der Zeitquelle abhängig. Eine Atomuhr oder ein GPS-Empfänger ist beispielsweise eine sehr genaue Zeitquelle, ein normaler RTC-Chip ist dagegen keine zuverlässige Zeitquelle. YaST erleichtert die Konfiguration von NTP-Clients.

Im Fenster für die YaST-NTP-Client-Konfiguration (Netzwerkdienste › NTP-Konfiguration) können Sie den Zeitpunkt für den Start des NTP-Daemons sowie den Typ der Konfigurationsquelle angeben und benutzerdefinierte Zeitserver einfügen.

Fenster „NTP-Konfiguration“
Abbildung 30.1: Fenster „NTP-Konfiguration“
 

30.1.1 Start des NTP-Daemons

 

Zum Starten des NTP-Daemons stehen drei Optionen zur Auswahl:

Nur manuell

Wählen Sie Nur manuell, wenn der chrony-Daemon manuell gestartet werden soll.

Ohne Daemon synchronisieren

Wählen Sie Ohne Daemon synchronisieren aus, um die Systemzeit regelmäßig festzulegen, ohne dass chrony ständig ausgeführt wird. Sie können das Synchronisierungsintervall in Minuten festlegen.

Jetzt und beim Booten

Wählen Sie Jetzt und beim Booten, um chrony automatisch beim Booten des Systems zu starten. Diese Einstellung wird empfohlen.

30.1.2 Typ der Konfigurationsquelle

 

Wählen Sie im Dropdown-Feld Konfigurationsquelle entweder die Option Dynamisch oder Statisch. Verwenden Sie Statisch, wenn Ihr Server nur mit einer bestimmten Gruppe (öffentlicher) NTP-Server arbeitet, und Dynamisch, wenn Ihr internes Netzwerk NTP-Server über DHCP anbietet.

30.1.3 Konfigurieren von Zeitservern

 

Im unteren Bereich des Fensters NTP-Konfiguration werden die Zeitserver aufgelistet, die der Client abfragen kann. Bearbeiten Sie diese Liste nach Bedarf mithilfe der Optionen Hinzufügen, Bearbeiten und Löschen.

Klicken Sie auf Hinzufügen, um einen neuen Zeitserver hinzuzufügen:

Hinzufügen eines Zeitservers
Abbildung 30.2: Hinzufügen eines Zeitservers
 

  1. Geben Sie in das Feld Adresse die URL des Zeitservers oder des Zeitserver-Pools ein, mit dem die Computerzeit synchronisiert werden soll. Prüfen Sie mit Test, ob die eingegebene URL auf eine gültige Zeitquelle verweist.

  2. Mit Schnelle erste Synchronisierung wird eine größere Anzahl von Anfragen beim Start des chronyd-Daemons gesendet, sodass die Zeitsynchronisierung beschleunigt wird.

  3. Mit Offline starten beschleunigen Sie den Bootvorgang auf Systemen, auf denen der chronyd-Daemon automatisch gestartet wird und die beim Booten keine Internetverbindung besitzen. Diese Option eignet sich beispielsweise für Laptops, deren Netzwerkverbindungen über NetworkManager verwaltet werden.

  4. Bestätigen Sie Ihre Auswahl mit OK.

30.2 Manuelle Konfiguration von NTP im Netzwerk

 

chrony liest die Konfiguration aus der Datei /etc/chrony.conf aus. Damit die Computeruhr synchronisiert bleibt, müssen Sie die zu verwendenden Zeitserver in chrony festlegen. Hierbei können Sie spezielle Servernamen oder IP-Adressen angeben, beispielsweise: 

server 0.europe.pool.ntp.org
server 1.europe.pool.ntp.org
server 2.europe.pool.ntp.org

Sie können auch den Namen für einen Pool angeben. Der Poolname wird in mehrere IP-Adressen aufgelöst: 

pool pool.ntp.org
Tipp
Tipp: Computer im selben Netzwerk

Soll die Zeit auf mehreren Computern in demselben Netzwerk synchronisiert werden, sollten Sie nicht alle Computer mit einem externen Server synchronisieren. Ein bewährtes Verfahren besteht darin, einen Computer als Zeitserver, der mit einem externen Zeitserver synchronisiert wird, und die anderen Computer als die Clients dieses Computers festzulegen. Tragen Sie eine local-Directive in die Datei /etc/chrony.conf des Servers ein, sodass dieser Server von einem autoritativen Zeitserver unterschieden wird: 

local stratum 10

Starten Sie chrony mit dem folgenden Kommando: 

systemctl start chronyd.service

Nach der Initialisierung von chronyd dauert es eine gewisse Zeit, bis die Zeit sich stabilisiert und die Drift-Datei zum Korrigieren der lokalen Computeruhr erstellt wird. Mithilfe der Drift-Datei kann der systematische Fehler der Hardware-Uhr berechnet werden, wenn der Computer eingeschaltet wird. Die Korrektur kommt umgehend zum Einsatz und führt zu einer größeren Stabilität der Systemzeit.

Aktivieren Sie den Dienst, sodass chrony automatisch beim Booten gestartet wird, mit dem folgenden Kommando: 

systemctl enable chronyd.service

30.3 Konfigurieren von chronyd zur Laufzeit mit chronyc

 

Mit chronyc können Sie das Verhalten von chronyd zur Laufzeit verändern. Hiermit werden außerdem Statusberichte zum Betrieb von chronyd erzeugt.

Sie können chronyc wahlweise im interaktiven oder im nicht interaktiven Modus ausführen. Soll chronyc interaktiv ausgeführt werden, geben Sie chronyc in die Kommandozeile ein. Eine Eingabeaufforderung wird angezeigt und das System wartet auf Ihre Kommandoeingabe. Mit dem folgenden Kommando prüfen Sie beispielsweise, wie viele NTP-Quellen online oder offline sind: 

root # chronyc
chronyc> activity
200 OK
4 sources online
2 sources offline
1 sources doing burst (return to online)
1 sources doing burst (return to offline)
0 sources with unknown address

Mit quit oder exit schließen Sie die chronyc-Eingabeaufforderung.

Falls Sie keine interaktive Eingabeaufforderung benötigen, geben Sie das Kommando direkt ein: 

root # chronyc activity
Anmerkung
Anmerkung: Temporäre Änderungen

Die mit chronyc vorgenommenen Änderungen sind nicht dauerhaft. Sie gehen nach dem nächsten Neustart von chronyd verloren. Sollen dauerhafte Änderungen erfolgen, bearbeiten Sie /etc/chrony.conf.

Eine vollständige Liste der chronyc-Kommandos finden Sie auf der man-Seite (man 1 chronyc).

30.4 Dynamische Zeitsynchronisierung während der Laufzeit

 

chronyd wird zwar auf einem System, das ohne Netzwerkverbindung bootet, normal ausgeführt, kann jedoch nicht die DNS-Namen der in der Konfigurationsdatei angegebenen Zeitserver auflösen.

chronyd versucht in immer größeren Zeitabständen, die in den server-, pool- und peer-Direktiven angegebenen Zeitservernamen aufzulösen, bis die Auflösung erfolgreich ist.

Falls der Zeitserver beim Starten von chronyd nicht erreichbar sein wird, können Sie die Option offline angeben: 

server server_address offline

Hiermit ruft chronyd den Server erst nach Aktivierung mit dem folgenden Kommando ab: 

root # chronyc online server_address

Wenn die Option auto_offline eingestellt ist, nimmt chronyd an, dass der Zeitserver offline geschaltet wurde, sobald zwei Anfragen ohne Antwort gesendet wurden. Mit dieser Option müssen Sie nicht mehr das Kommando „offline“ über chronyc ausführen, wenn Sie die Netzwerkverbindung trennen.

30.5 Einrichten einer lokalen Referenzuhr

 

Das Software-Paket chrony greift auf andere Programme (z. B. gpsd) zurück, die die Zeitgebungsdaten über den SHM- oder SOCK-Treiber abrufen. Geben Sie mit der refclock-Direktive in der Datei /etc/chrony.conf eine Hardware-Referenzuhr als Zeitquelle an. Hierbei sind zwei Parameter obligatorisch, zum einen der Treibername und zum anderen ein treiberspezifischer Parameter. Nach den beiden Parameter können bei Bedarf noch refclock-Optionen angegeben werden. chronyd umfasst die folgenden Treiber:

  • PPS – Treiber für die Kernel-„Impuls pro Sekunde“-API. Beispiel: 

    refclock PPS /dev/pps0 lock NMEA refid GPS

  • SHM – Treiber für den gemeinsam genutzten NTP-Speicher. Beispiel: 

    refclock SHM 0 poll 3 refid GPS1
refclock SHM 1:perm=0644 refid GPS2

  • SOCK – Treiber für den Unix-Domänen-Socket. Beispiel: 

    refclock SOCK /var/run/chrony.ttyS0.sock

  • PHC – Treiber für die PTP-Hardware-Uhr. Beispiel: 

    refclock PHC /dev/ptp0 poll 0 dpoll -2 offset -37
refclock PHC /dev/ptp1:nocrossts poll 3 pps

Weitere Informationen zu den Optionen der einzelnen Treiber finden Sie auf der man-Seite man 8 chrony.conf.

30.6 Uhrensynchronisierung mit einer externen Zeitreferenz (ETR)

 

Unterstützung für Uhrensynchronisierung mit einer externen Zeitreferenz (ETR) ist verfügbar. Die externe Zeitreferenz sendet alle 2**20 (2 hoch 20) Millisekunden ein Oszillatorsignal und ein Synchronisierungssignal, um die Tageszeit-Uhren aller angeschlossenen Server synchron zu halten.

Zur Verfügbarkeit können zwei ETR-Einheiten an einen Computer angeschlossen werden. Wenn die Uhr um mehr als die Toleranz zum Prüfen der Synchronisierung abweicht, erhalten alle CPUs eine Rechnerprüfung, die darauf hinweist, dass die Uhr nicht synchronisiert ist. In diesem Fall werden sämtliche DASD-E/A an XRC-fähige Geräte gestoppt, bis die Uhr wieder synchron ist.

Die ETR-Unterstützung wird mithilfe von zwei sysfs-Attributen aktiviert; führen Sie die folgenden Kommandos als root aus: 

echo 1 > /sys/devices/system/etr/etr0/online
echo 1 > /sys/devices/system/etr/etr1/online

31 Domain Name System (DNS)

 

DNS (Domain Name System) ist zur Auflösung der Domänen- und Hostnamen in IP-Adressen erforderlich. So wird die IP-Adresse 192.168.2.100 beispielsweise dem Hostnamen jupiter zugewiesen. Bevor Sie Ihren eigenen Namenserver einrichten, sollten Sie die allgemeinen Informationen zu DNS in Abschnitt 19.3, „Namensauflösung“ lesen. Die folgenden Konfigurationsbeispiele gelten für BIND, den standardmäßigen DNS-Server.

31.1 DNS-Terminologie

 
Zone

Der Domänen-Namespace wird in Regionen, so genannte Zonen, unterteilt. So ist beispielsweise example.com der Bereich (oder die Zone) example der Domäne com.

DNS-Server

Der DNS-Server ist ein Server, auf dem der Name und die IP-Informationen für eine Domäne gespeichert sind. Sie können einen primären DNS-Server für die Masterzone, einen sekundären Server für die Slave-Zone oder einen Slave-Server ohne jede Zone für das Caching besitzen.

DNS-Server der Masterzone

Die Masterzone beinhaltet alle Hosts aus Ihrem Netzwerk und der DNS-Server der Masterzone speichert die aktuellen Einträge für alle Hosts in Ihrer Domäne.

DNS-Server der Slave-Zone

Eine Slave-Zone ist eine Kopie der Masterzone. Der DNS-Server der Slave-Zone erhält seine Zonendaten mithilfe von Zonentransfers von seinem Masterserver. Der DNS-Server der Slave-Zone antwortet autorisiert für die Zone, solange er über gültige (nicht abgelaufene) Zonendaten verfügt. Wenn der Slave keine neue Kopie der Zonendaten erhält, antwortet er nicht mehr für die Zone.

Forwarder

Forwarders sind DNS-Server, an die der DNS-Server Abfragen sendet, die er nicht bearbeiten kann. Zum Aktivieren verschiedener Konfigurationsquellen in einer Konfiguration wird netconfig verwendet (siehe auch man 8 netconfig).

Datensatz

Der Eintrag besteht aus Informationen zu Namen und IP-Adresse. Die unterstützten Einträge und ihre Syntax sind in der BIND-Dokumentation beschrieben. Einige spezielle Einträge sind beispielsweise:

NS-Eintrag

Ein NS-Eintrag informiert die Namenserver darüber, welche Computer für eine bestimmte Domänenzone zuständig sind.

MX-Eintrag

Die MX (Mailaustausch)-Einträge beschreiben die Computer, die für die Weiterleitung von Mail über das Internet kontaktiert werden sollen.

SOA-Eintrag

Der SOA (Start of Authority)-Eintrag ist der erste Eintrag in einer Zonendatei. Der SOA-Eintrag wird bei der Synchronisierung von Daten zwischen mehreren Computern über DNS verwendet.

31.2 Installation

 

Zur Installation eines DNS-Servers starten Sie YaST, und wählen Sie Software › Software installieren oder löschen. Wählen Sie Ansicht › Schemata und schließlich DHCP- und DNS-Server aus. Bestätigen Sie die Installation der abhängigen Pakete, um den Installationsvorgang abzuschließen.

Alternativ geben Sie den folgenden Befehl in der Befehlszeile ein: 

tux > sudo zypper in -t pattern dhcp_dns_server

31.3 Konfiguration mit YaST

 

Verwenden Sie das DNS-Modul von YaST, um einen DNS-Server für das lokale Netzwerk zu konfigurieren. Beim ersten Starten des Moduls werden Sie von einem Assistenten aufgefordert, einige grundlegende Entscheidungen hinsichtlich der Serveradministration zu treffen. Mit dieser Ersteinrichtung wird eine grundlegende Serverkonfiguration vorgenommen. Für erweiterte Konfigurationsaufgaben, beispielsweise zum Einrichten von ACLs, für Protokollaufgaben, TSIG-Schlüssel und andere Optionen, verwenden Sie den Expertenmodus.

31.3.1 Assistentenkonfiguration

 

Der Assistent besteht aus drei Schritten bzw. Dialogfeldern. An bestimmten Stellen im Dialogfeld können Sie in den Konfigurationsmodus für Experten wechseln.

  1. Wenn Sie das Modul zum ersten Mal starten, wird das Dialogfeld Forwarder-Einstellungen (siehe Abbildung 31.1, „DNS-Server-Installation: Forwarder-Einstellungen“) geöffnet. Die Richtlinie für lokale DNS-Auflösung bietet die folgenden Optionen:

    • Zusammenführen von Forwardern ist deaktiviert

    • Automatisches Zusammenführen

    • Zusammenführen von Forwardern ist aktiviert

    • Benutzerdefinierte Konfiguriation – Wenn die benutzerdefinierte Konfiguriation aktiviert ist, können Sie die benutzerdefinierte Richtlinie angeben. Standardmäßig (Option Automatisches Zusammenführen ist aktiviert) ist die benutzerdefinierte Richtlinie auf automatisch eingestellt; hier können Sie die Schnittstellennamen jedoch selbst festlegen oder aus den beiden besonderen Richtliniennamen STATIC und STATIC_FALLBACK wählen.

    Geben Sie unter Forwarder für lokale DNS-Auflösung den zu verwendenden Service an: System-Nameserver werden verwendet, Dieser Nameserver (Bind) oder Lokaler dnsmasq-Server.

    Weitere Informationen zu diesen Einstellungen finden Sie auf der man-Seite man 8 netconfig.

    DNS-Server-Installation: Forwarder-Einstellungen
    Abbildung 31.1: DNS-Server-Installation: Forwarder-Einstellungen
     

    Forwarders sind DNS-Server, an die der DNS-Server Abfragen sendet, die er nicht selbst bearbeiten kann. Geben Sie ihre IP-Adresse ein und klicken Sie auf Hinzufügen.

  2. Das Dialogfeld DNS-Zonen besteht aus mehreren Teilen und ist für die Verwaltung von Zonendateien zuständig, wie in Abschnitt 31.6, „Zonendateien“ beschrieben. Bei einer neuen müssen Sie unter Name der Zone einen Namen angeben. Um eine Reverse Zone hinzuzufügen, muss der Name auf .in-addr.arpa enden. Wählen Sie zum Schluss den Typ (Master, Slave oder Forward) aus. Weitere Informationen hierzu finden Sie im Abbildung 31.2, „DNS-Server-Installation: DNS-Zonen“. Klicken Sie auf Bearbeiten, um andere Einstellungen für eine bestehende Zone zu konfigurieren. Zum Entfernen einer klicken Sie auf Zone löschen.

    DNS-Server-Installation: DNS-Zonen
    Abbildung 31.2: DNS-Server-Installation: DNS-Zonen
     

  3. Im letzten Dialogfeld können Sie den DNS-Port in der Firewall öffnen, indem Sie auf Firewall-Port öffnen klicken. Legen Sie anschließend fest, ob der DNS-Server beim Booten gestartet werden soll (Ein oder Aus). Außerdem können Sie die LDAP-Unterstützung aktivieren. Siehe Abbildung 31.3, „DNS-Server-Installation: Wizard beenden“.

    DNS-Server-Installation: Wizard beenden
    Abbildung 31.3: DNS-Server-Installation: Wizard beenden
     

31.3.2 Konfiguration für Experten

 

Nach dem Starten des Moduls öffnet YaST ein Fenster, in dem mehrere Konfigurationsoptionen angezeigt werden. Nach Abschluss dieses Fensters steht eine DNS-Server-Konfiguration mit Grundfunktionen zur Verfügung:

31.3.2.1 Start

 

Legen Sie unter Start fest, ob der DNS-Server beim Booten des Systems oder manuell gestartet werden soll. Um den DNS-Server sofort zu starten, klicken Sie auf DNS-Server nun starten. Um den DNS-Server anzuhalten, klicken Sie auf DNS-Server nun anhalten. Zum Speichern der aktuellen Einstellungen wählen Sie Jetzt Einstellungen speichern und DNS-Server neu laden. Sie können den DNS-Anschluss in der Firewall mit Firewall-Port öffnen öffnen und die Firewall-Einstellungen mit Firewall-Details bearbeiten.

Wenn Sie LDAP-Unterstützung aktiv wählen, werden die Zone-Dateien von einer LDAP-Datenbank verwaltet. Alle Änderungen an Zonendaten, die in der LDAP-Datenbank gespeichert werden, werden vom DNS-Server erfasst, wenn er neu gestartet oder aufgefordert wird, seine Konfiguration neu zu laden.

31.3.2.2 Forwarder

 

Falls Ihr lokaler DNS-Server eine Anforderung nicht beantworten kann, versucht er, diese Anforderung an einen Forwarder weiterzuleiten, falls dies so konfiguriert wurde. Dieser Forwarder kann manuell zur Forwarder-Liste hinzugefügt werden. Wenn der Forwarder nicht wie bei Einwahlverbindungen statisch ist, wird die Konfiguration von netconfig verarbeitet. Weitere Informationen über netconfig finden Sie auf man 8 netconfig.

31.3.2.3 Grundlegende Optionen

 

In diesem Abschnitt werden grundlegende Serveroptionen festgelegt. Wählen Sie im Menü Option das gewünschte Element aus, und geben Sie dann den Wert im entsprechenden Textfeld an. Nehmen Sie den neuen Eintrag auf, indem Sie auf Hinzufügen klicken.

31.3.2.4 Protokollierung

 

Um festzulegen, was und wie der DNS-Server protokollieren soll, wählen Sie Protokollieren aus. Geben Sie unter Protokolltyp an, wohin der DNS-Server die Protokolldaten schreiben soll. Verwenden Sie das systemweite Protokoll durch Auswahl von Systemprotokoll, oder geben Sie durch Auswahl von Datei eine andere Datei an. In letzterem Fall müssen Sie außerdem einen Namen, die maximale Dateigröße in Megabyte und die Anzahl der zu speichernden Versionen von Protokolldateien angeben.

Weitere Optionen sind unter Zusätzliches Protokollieren verfügbar. Durch Aktivieren von Alle DNS-Abfragen protokollieren wird jede Abfrage protokolliert. In diesem Fall kann die Protokolldatei extrem groß werden. Daher sollte diese Option nur zur Fehlersuche aktiviert werden. Um den Datenverkehr zu protokollieren, der während Zonenaktualisierungen zwischen dem DHCP- und dem DNS-Server stattfindet, aktivieren Sie Zonen-Updates protokollieren. Um den Datenverkehr während eines Zonentransfers von Master zu Slave zu protokollieren, aktivieren Sie Zonen-Transfer protokollieren. Siehe Abbildung 31.4, „DNS-Server: Protokollieren“.

DNS-Server: Protokollieren
Abbildung 31.4: DNS-Server: Protokollieren
 

31.3.2.5 ACLs

 

In diesem Dialogfeld legen Sie ACLs (Access Control Lists = Zugriffssteuerungslisten) fest, mit denen Sie den Zugriff einschränken. Nach der Eingabe eines eindeutigen Namens unter Name geben Sie unter Wert eine IP-Adresse (mit oder ohne Netzmaske) wie folgt an: 

{ 192.168.1/24; }

Die Syntax der Konfigurationsdatei erfordert, dass die Adresse mit einem Strichpunkt endet und in geschwungenen Klammern steht.

31.3.2.6 TSIG-Schlüssel

 

Der Hauptzweck von TSIG-Schlüsseln (Transaction Signatures = Transaktionssignaturen) ist die Sicherung der Kommunikation zwischen DHCP- und DNS-Servern. Diese werden unter Abschnitt 31.8, „Sichere Transaktionen“ beschrieben.

Zum Erstellen eines TSIG-Schlüssels geben Sie einen eindeutigen Namen im Feld mit der Beschriftung Schlüssel-ID ein und geben die Datei an, in der der Schlüssel gespeichert werden soll (Dateiname). Bestätigen Sie Ihre Einstellung mit Erzeugen.

Wenn Sie einen vorher erstellten Schlüssel verwenden möchten, lassen Sie das Feld Schlüssel-ID leer und wählen die Datei, in der der gewünschte Schlüssel gespeichert wurde, unter Dateiname. Dann bestätigen Sie die Auswahl mit Hinzufügen.

31.3.2.7 DNS-Zonen (Hinzufügen einer Slave-Zone)

 

Wenn Sie eine Slave-Zone hinzufügen möchten, klicken Sie auf DNS-Zonen, wählen Sie den Zonentyp Slave aus, geben Sie den Namen der neuen Zone ein und klicken Sie auf Hinzufügen.

Geben Sie im Zonen-Editor unter IP des Master DNS-Servers den Master an, von dem der Slave die Daten abrufen soll. Um den Zugriff auf den Server zu beschränken, wählen Sie eine der ACLs aus der Liste aus.

31.3.2.8 DNS-Zonen (Hinzufügen einer Master-Zone)

 

Wenn Sie eine Masterzone hinzufügen möchten, klicken Sie auf DNS-Zonen, wählen Sie den Zonentyp Master aus, geben Sie den Namen der neuen Zone ein und klicken Sie auf Hinzufügen. Beim Hinzufügen einer Masterzone ist auch eine Reverse Zone erforderlich. Wenn Sie beispielsweise die Zone example.com hinzufügen, die auf Hosts in einem Subnetz 192.168.1.0/24 zeigt, sollten Sie auch eine Reverse Zone für den betreffenden IP-Adressbereich erstellen. Per Definition sollte dieser den Namen 1.168.192.in-addr.arpa erhalten.

31.3.2.9 DNS-Zonen (Bearbeiten einer Master-Zone)

 

Wenn Sie eine Masterzone bearbeiten möchten, klicken Sie auf DNS-Zonen, wählen Sie die Masterzone in der Tabelle aus und klicken Sie auf Bearbeiten. Dieses Dialogfeld besteht aus mehreren Seiten: Grundlagen (die zuerst geöffnete Seite), DNS-Einträge, MX-Einträge, SOA und Einträge.

Im grundlegenden Dialogfeld in Abbildung 31.5, „DNS-Server: Zonen-Editor (Grundlagen)“ können Sie die Einstellungen für das dynamische DNS festlegen und auf Optionen für Zonentransfers an Clients und Slave-Namenserver zugreifen. Zum Zulassen dynamischer Aktualisierungen von Zonen wählen Sie Dynamische Updates erlauben und den entsprechenden TSIG-Schlüssel. Der Schlüssel muss definiert werden, bevor die Aktualisierung startet. Zum Aktivieren der Zonentransfers wählen Sie die entsprechenden ACLs. ACLs müssen bereits definiert sein.

Wählen Sie im Dialogfeld Grundlagen aus, ob Zonen-Transfers aktiviert werden sollen. Verwenden Sie die aufgelisteten ACLs, um festzulegen, wer Zonen herunterladen kann.

DNS-Server: Zonen-Editor (Grundlagen)
Abbildung 31.5: DNS-Server: Zonen-Editor (Grundlagen)
 
Zonen-Editor (NS-Einträge)

Im Dialogfeld NS-Einträge können Sie alternative Nameserver für die angegebenen Zonen definieren. Vergewissern Sie sich, dass Ihr eigener Namenserver in der Liste enthalten ist. Um einen Eintrag hinzuzufügen, geben Sie seinen Namen unter Hinzuzufügender Namenserver ein und bestätigen Sie den Vorgang anschließend mit Hinzufügen. Siehe Abbildung 31.6, „DNS-Server: Zonen-Editor (NS-Einträge)“.

DNS-Server: Zonen-Editor (NS-Einträge)
Abbildung 31.6: DNS-Server: Zonen-Editor (NS-Einträge)
 
Zonen-Editor (MX-Einträge)

Um einen Mailserver für die aktuelle Zone zur bestehenden Liste hinzuzufügen, geben Sie die entsprechende Adresse und den entsprechenden Prioritätswert ein. Bestätigen Sie den Vorgang anschließend durch Auswahl von Hinzufügen. Siehe Abbildung 31.7, „DNS-Server: Zonen-Editor (MX-Einträge)“.

DNS-Server: Zonen-Editor (MX-Einträge)
Abbildung 31.7: DNS-Server: Zonen-Editor (MX-Einträge)
 
Zonen-Editor (SOA)

Auf dieser Seite können Sie SOA (Start of Authority)-Einträge erstellen. Eine Erklärung der einzelnen Optionen finden Sie in Beispiel 31.6, „Die Datei /var/lib/named/example.com.zone“. Das Ändern von SOA-Datensätzen wird für dynamischen Zonen, die über LDAP verwaltet werden, nicht unterstützt.

DNS-Server: Zonen-Editor (SOA)
Abbildung 31.8: DNS-Server: Zonen-Editor (SOA)
 
Zonen-Editor (Einträge)

In diesem Dialogfeld wird die Namenauflösung verwaltet. Geben Sie unter Eintragschlüssel den Hostnamen an, und wählen Sie anschließend den Typ aus. Der Typ A bezeichnet den Haupteintrag. Der Wert hierfür sollte eine IP-Adresse (IPv4) sein. Für IPv6-Adressen verwenden Sie AAAA. CNAME ist ein Alias. Verwenden Sie die Typen NS und MX für detaillierte oder partielle Einträge, mit denen die Informationen aus den Registerkarten NS-Einträge und MX-Einträge erweitert werden. Diese drei Typen werden in einen bestehenden A-Eintrag aufgelöst. PTR dient für Reverse Zones. Es handelt sich um das Gegenteil eines A-Eintrags, wie zum Beispiel: 

hostname.example.com. IN A 192.168.0.1
1.0.168.192.in-addr.arpa IN PTR hostname.example.com.
31.3.2.9.1 Hinzufügen von Reverse Zones
 

So fügen Sie eine Reverse Zone hinzu:

  1. Starten Sie YaST › DNS-Server › DNS-Zonen.

  2. Falls Sie noch keine Forward-Masterzone angelegt haben, holen Sie dies jetzt nach und bearbeiten Sie sie.

  3. Geben Sie auf der Registerkarte Einträge den entsprechenden Eintragsschlüssel und Eintragswert an. Legen Sie dann den Eintrag mit Hinzufügen an und bestätigen Sie den Vorgang mit OK. Wenn YaST eine Meldung ausgibt, dass ein Eintrag für einen Nameserver fehlt, geben Sie diesen Eintrag auf der Registerkarte DNS-Einträge an.

    Hinzufügen eines Eintrags für eine Master Zone
    Abbildung 31.9: Hinzufügen eines Eintrags für eine Master Zone
     

  4. Fügen Sie im Fenster DNS-Zonen eine Reverse-Masterzone hinzu.

    Hinzufügen einer Reverse Zone
    Abbildung 31.10: Hinzufügen einer Reverse Zone
     

  5. Bearbeiten Sie die Reverse Zone. Auf der Registerkarte Einträge wird der Eintragstyp PTR: Umgekehrte Übersetzung aufgeführt. Geben Sie den entsprechenden Eintragsschlüssel und Eintragswert an, klicken Sie auf Hinzufügen und bestätigen Sie den Vorgang mit OK.

    Hinzufügen eines Reverse-Eintrags
    Abbildung 31.11: Hinzufügen eines Reverse-Eintrags
     

    Fügen Sie bei Bedarf einen Nameserver-Eintrag hinzu.

Tipp
Tipp: Bearbeiten der Reverse Zone

Wechseln Sie nach dem Hinzufügen einer Forward Zone wieder in das Hauptmenü und wählen Sie die Reverse Zone zur Bearbeitung aus. Markieren Sie im Karteireiter Grundlagen das Kontrollkästchen Einträge automatisch generieren aus und wählen Sie Ihre Forward Zone aus. Auf diese Weise werden alle Änderungen an der Forward Zone automatisch in der Reverse Zone aktualisiert.

31.4 Starten des BIND-Nameservers

 

Bei SUSE® Linux Enterprise Server-Systemen ist der Namenserver BIND (Berkeley Internet Name Domain) vorkonfiguriert, sodass er problemlos unmittelbar nach der Installation gestartet werden kann. Wenn Sie bereits über eine funktionierende Internetverbindung verfügen und 127.0.0.1 als Namenserver-Adresse für localhost in /var/run/netconfig/resolv.conf eingegeben haben, verfügen Sie normalerweise bereits über eine funktionierende Namensauflösung, ohne dass Ihnen der DNS des Anbieters bekannt sein muss. BIND führt die Namenauflösung über den Root-Namenserver durch. Dies ist ein wesentlich langsamerer Prozess. Normalerweise sollte der DNS des Anbieters zusammen mit der zugehörigen IP-Adresse in die Konfigurationsdatei /etc/named.conf unter forwarders eingegeben werden, um eine effektive und sichere Namenauflösung zu gewährleisten. Wenn dies so weit funktioniert, wird der Namenserver als reiner Nur-Cache-Namenserver ausgeführt. Nur wenn Sie seine eigenen Zonen konfigurieren, wird er ein richtiger DNS. Ein einfaches Beispiel zur Veranschaulichung finden Sie unter /usr/share/doc/packages/bind/config.

Tipp
Tipp: Automatische Anpassung der Nameserverinformationen

Je nach Typ der Internet- bzw. Netzwerkverbindung können die Namenserverinformationen automatisch an die aktuellen Bedingungen angepasst werden. Legen Sie die Variable NETCONFIG_DNS_POLICY in der Datei /etc/sysconfig/network/config dazu auf auto fest.

Richten Sie jedoch erst eine offizielle Domäne ein, wenn Sie eine Domäne von der zuständigen Stelle zugewiesen bekommen. Selbst wenn Sie eine eigene Domäne besitzen und diese vom Anbieter verwaltet wird, sollten Sie sie besser nicht verwenden, da BIND ansonsten keine Anforderungen für diese Domäne weiterleitet. Beispielsweise könnte in diesem Fall für diese Domäne der Zugriff auf den Webserver beim Anbieter nicht möglich sein.

Starten Sie den Nameserver mit dem Befehl systemctl start named als root. Prüfen Sie mit systemctl status named, ob der Nameserverprozess „named“ ordnungsgemäß gestartet wurde. Testen Sie den Nameserver umgehend auf dem lokalen System mit den Programmen host oder dig. Sie sollten localhost als Standardserver mit der Adresse 127.0.0.1 zurückgeben. Ist dies nicht der Fall, enthält /var/run/netconfig/resolv.conf wahrscheinlich einen falschen Nameserver-Eintrag oder die Datei ist nicht vorhanden. Geben Sie beim ersten Test host 127.0.0.1 ein. Dieser Eintrag sollte immer funktionieren. Wenn Sie eine Fehlermeldung erhalten, überprüfen Sie mit systemctl status named, ob der Server tatsächlich ausgeführt wird. Wenn der Nameserver nicht startet oder sich ungewöhnlich verhält, prüfen Sie die Ausgabe von journalctl -e.

Um den Namenserver des Anbieters (oder einen bereits in Ihrem Netzwerk ausgeführten Server) als Forwarder zu verwenden, geben Sie die entsprechende IP-Adresse(n) im Abschnitt options unter forwarders ein. Bei den Adressen in Beispiel 31.1, „Weiterleitungsoptionen in named.conf“ handelt es sich lediglich um Beispiele. Passen Sie diese Einträge an Ihr eigenes Setup an.

Beispiel 31.1: Weiterleitungsoptionen in named.conf
 
options {
        directory "/var/lib/named";
        forwarders { 10.11.12.13; 10.11.12.14; };
        listen-on { 127.0.0.1; 192.168.1.116; };
        allow-query { 127/8; 192.168/16 };
        notify no;
};

Auf den Eintrag options folgen Einträge für die Zone, localhost und 0.0.127.in-addr.arpa. Der Eintrag type hint unter „.“ muss stets vorhanden sein. Die entsprechenden Dateien müssen nicht bearbeitet werden und sollten so funktionieren, wie sie sind. Achten Sie außerdem darauf, dass jeder Eintrag mit einem „;“ abgeschlossen ist und dass sich die geschweiften Klammern an der richtigen Position befinden. Nach dem Ändern der Konfigurationsdatei /etc/named.conf oder der Zonendateien müssen Sie BIND anweisen, diese Datei(en) erneut zu lesen. Führen Sie hierzu den Befehl systemctl reload named aus. Dieselbe Wirkung erzielen Sie, wenn Sie den Nameserver mit systemctl restart named anhalten und neu starten. Sie können den Server jederzeit mit systemctl stop named anhalten.

31.5 Die Konfigurationsdatei /etc/named.conf

 

Alle Einstellungen für den BIND-Namenserver selbst sind in der Datei /etc/named.conf gespeichert. Die Zonendaten für die zu bearbeitenden Domänen, die aus Hostnamen, IP-Adressen usw. bestehen, sind jedoch in gesonderten Dateien im Verzeichnis /var/lib/named gespeichert. Einzelheiten hierzu werden weiter unten beschrieben.

/etc/named.conf lässt sich grob in zwei Bereiche untergliedern. Der eine ist der Abschnitt options für allgemeine Einstellungen und der zweite besteht aus zone-Einträgen für die einzelnen Domänen. Der Abschnitt logging und die Einträge unter acl (access control list, Zugriffssteuerungsliste) sind optional. Kommentarzeilen beginnen mit # oder mit //. Eine Minimalversion von /etc/named.conf finden Sie in Beispiel 31.2, „Eine Grundversion von /etc/named.conf“.

Beispiel 31.2: Eine Grundversion von /etc/named.conf
 
options {
        directory "/var/lib/named";
        forwarders { 10.0.0.1; };
        notify no;
};

zone "localhost" in {
       type master;
       file "localhost.zone";
};

zone "0.0.127.in-addr.arpa" in {
        type master;
        file "127.0.0.zone";
};

zone "." in {
        type hint;
        file "root.hint";
};

31.5.1 Wichtige Konfigurationsoptionen

 
directory "DATEINAME";

Gibt das Verzeichnis an, in dem BIND die Dateien mit den Zonendaten finden kann. In der Regel ist dies /var/lib/named.

forwarders { IP-ADRESSE; };

Gibt die Namenserver (zumeist des Anbieters) an, an die DNS-Anforderungen weitergeleitet werden sollen, wenn sie nicht direkt aufgelöst werden können. Ersetzen Sie IP-ADRESSE durch eine IP-Adresse wie 192.168.1.116.

forward first;

Führt dazu, dass DNS-Anforderungen weitergeleitet werden, bevor versucht wird, sie über die Root-Namenserver aufzulösen. Anstatt forward first kann forward only verwendet werden. Damit werden alle Anforderungen weitergeleitet, ohne dass sie an die Root-Namenserver gesendet werden. Dies ist bei Firewall-Konfigurationen sinnvoll.

listen-on port 53 { 127.0.0.1; IP-ADRESSE; };

Informiert BIND darüber, an welchen Netzwerkschnittstellen und Ports Client-Abfragen akzeptiert werden sollen. port 53 muss nicht explizit angegeben werden, da 53 der Standardport ist. Geben Sie 127.0.0.1 ein, um Anforderungen vom lokalen Host zuzulassen. Wenn Sie diesen Eintrag ganz auslassen, werden standardmäßig alle Schnittstellen verwendet.

listen-on-v6 port 53 {any; };

Informiert BIND darüber, welcher Port auf IPv6-Client-Anforderungen überwacht werden soll. Die einzige Alternative zu any ist none. Bei IPv6 akzeptiert der Server nur Platzhalteradressen.

query-source address * port 53;

Dieser Eintrag ist erforderlich, wenn eine Firewall ausgehende DNS-Anforderungen blockiert. Dadurch wird BIND angewiesen, Anforderungen extern von Port 53 und nicht von einem der Ports mit den hohen Nummern über 1024 aufzugeben.

query-source-v6 address * port 53;

Informiert BIND darüber, welcher Port für IPv6-Abfragen verwendet werden soll.

allow-query \{ 127.0.0.1; NETZ; };

Definiert die Netzwerke, von denen aus Clients DNS-Anforderungen aufgeben können. Ersetzen Sie NETZ durch Adressinformationen wie 192.168.2.0/24. Der Wert /24 am Ende ist ein abgekürzter Ausdruck für die Netzmaske, hier 255.255.255.0).

allow-transfer ! *;;

Legt fest, welche Hosts Zonentransfers anfordern können. Im vorliegenden Beispiel werden solche Anforderungen mit ! * vollständig verweigert. Ohne diesen Eintrag können Zonentransfer ohne Einschränkungen von jedem beliebigen Ort aus angefordert werden.

statistics-interval 0;

Ohne diesen Eintrag generiert BIND im Systemjournal mehrere Zeilen mit statistischen Informationen pro Stunde. Setzen Sie diesen Wert auf „0“, um diese Statistiken vollständig zu unterdrücken, oder legen Sie ein Zeitintervall in Minuten fest.

cleaning-interval 720;

Diese Option legt fest, in welchen Zeitabständen BIND den Cache leert. Damit wird bei jedem Ausführen dieses Vorgangs ein Eintrag im Systemjournal ausgelöst. Die verwendete Einheit für die Zeitangabe ist Minuten. Der Standardwert ist 60 Minuten.

interface-interval 0;

BIND durchsucht die Netzwerkschnittstellen regelmäßig nach neuen oder nicht vorhandenen Schnittstellen. Wenn dieser Wert auf 0 gesetzt ist, wird dieser Vorgang nicht durchgeführt und BIND überwacht nur die beim Start erkannten Schnittstellen. Anderenfalls wird das Zeitintervall in Minuten angegeben. Der Standardwert ist 60 Minuten.

notify no;

no verhindert, dass anderen Namenserver informiert werden, wenn Änderungen an den Zonendaten vorgenommen werden oder wenn der Namenserver neu gestartet wird.

Eine Liste der verfügbaren Optionen finden Sie auf der man-Seite man 5 named.conf.

31.5.2 Protokollierung

 

Der Umfang, die Art und Weise und der Ort der Protokollierung kann in BIND extensiv konfiguriert werden. In der Regel dürften die Standardeinstellungen ausreichen. Beispiel 31.3, „Eintrag zur Deaktivierung der Protokollierung“ zeigt die einfachste Form eines solchen Eintrags und unterdrückt die Protokollierung vollständig.

Beispiel 31.3: Eintrag zur Deaktivierung der Protokollierung
 
logging {
        category default { null; };
};

31.5.3 Zoneneinträge

 
Beispiel 31.4: Zoneneintrag für „example.com“
 
zone "example.com" in {
      type master;
      file "example.com.zone";
      notify no;
};

Geben Sie nach zone den Namen der zu verwaltenden Domäne (example.com) an, gefolgt von in und einem Block relevanter Optionen in geschweiften Klammern, wie in Beispiel 31.4, „Zoneneintrag für „example.com““ gezeigt. Um eine Slave-Zone zu definieren, ändern Sie den Wert von type in slave und geben Sie einen Namenserver an, der diese Zone als master verwaltet (dieser kann wiederum ein Slave eines anderen Masters sein), wie in Beispiel 31.5, „Zoneneintrag für „example.net““ gezeigt.

Beispiel 31.5: Zoneneintrag für „example.net“
 
zone "example.net" in {
      type slave;
      file "slave/example.net.zone";
      masters { 10.0.0.1; }; 
};

Zonenoptionen:

type master;

Durch die Angabe master wird BIND darüber informiert, dass der lokale Namenserver für die Zone zuständig ist. Dies setzt voraus, dass eine Zonendatei im richtigen Format erstellt wurde.

type slave;

Diese Zone wird von einem anderen Namenserver übertragen. Sie muss zusammen mit masters verwendet werden.

type hint;

Die Zone . vom Typ hint wird verwendet, um den root-Namenserver festzulegen. Diese Zonendefinition kann unverändert beibehalten werden.

file example.com.zone or file „slave/example.net.zone“;

In diesem Eintrag wird die Datei angegeben, in der sich die Zonendaten für die Domäne befinden. Diese Datei ist für einen Slave nicht erforderlich, da die betreffenden Daten von einem anderen Namenserver abgerufen werden. Um zwischen Master- und Slave-Dateien zu unterscheiden, verwenden Sie das Verzeichnis slave für die Slave-Dateien.

importserver { SERVER_IP_ADRESSE; };

Dieser Eintrag ist nur für Slave-Zonen erforderlich. Er gibt an, von welchem Namenserver die Zonendatei übertragen werden soll.

allow-update {! *; };

Mit dieser Option wird der externe Schreibzugriff gesteuert, der Clients das Anlegen von DNS-Einträgen gestatten würde. Dies ist in der Regel aus Sicherheitsgründen nicht erstrebenswert. Ohne diesen Eintrag sind keine Zonenaktualisierungen zulässig. Der oben stehende Eintrag hat dieselbe Wirkung, da ! * solche Aktivitäten effektiv unterbindet.

31.6 Zonendateien

 

Zwei Arten von Zonendateien sind erforderlich. Eine Art ordnet IP-Adressen Hostnamen zu, die andere stellt Hostnamen für IP-Adressen bereit.

Tipp
Tipp: Verwenden des Punkts in Zonendateien

Im Verzeichnis “.“ hat eine wichtige Bedeutung in den Zonendateien. Bei Angabe von Hostnamen ohne abschließenden Punkt (.) wird die Zone angehängt. Vollständige Hostnamen mit vollständiger Domäne benötigen den abschließenden Punkt (.), damit die Domäne nicht erneut hinzugefügt wird. Ein fehlender oder falsch gesetzter Punkt („.“) ist wahrscheinlich die häufigste Ursache für Nameserver-Konfigurationsfehler.

Der erste zu betrachtende Fall ist die Zonendatei example.com.zone, die für die Domäne example.com zuständig ist (siehe Beispiel 31.6, „Die Datei /var/lib/named/example.com.zone“).

Beispiel 31.6: Die Datei /var/lib/named/example.com.zone
 
$TTL 2D 1
example.com. IN SOA      dns  root.example.com. ( 2
             2003072441  ; serial 3
             1D          ; refresh 4
             2H          ; retry 5
             1W          ; expiry 6
             2D )        ; minimum 7

             IN NS       dns 8
             IN MX       10 mail dns 9
gate         IN A        192.168.5.1 10
             IN A        10.0.0.1
dns          IN A        192.168.1.116
mail         IN A        192.168.3.108
jupiter      IN A        192.168.2.100
venus        IN A        192.168.2.101
saturn       IN A        192.168.2.102
mercury      IN A        192.168.2.103
ntp          IN CNAME    dns 11
dns6         IN A6  0    2002:c0a8:174::

1

$TTL legt die Standardlebensdauer fest, die für alle Einträge in dieser Datei gelten soll. In diesem Beispiel sind die Einträge zwei Tage lang gültig (2 D).

2

Hier beginnt der SOA (Start of Authority)-Steuereintrag:

  • Der Name der zu verwaltenden Domäne ist example.com an der ersten Stelle. Dieser Eintrag endet mit „.“, da andernfalls die Zone ein zweites Mal angefügt würde. Alternativ kann hier @ eingegeben werden. In diesem Fall wird die Zone aus dem entsprechenden Eintrag in /etc/named.conf extrahiert.

  • Nach IN SOA befindet sich der Name des Namenservers, der als Master für diese Zone fungiert. Der Name wird von dns zu dns.example.com erweitert, da er nicht mit „.“ endet.

  • Es folgt die Email-Adresse der für diesen Namenserver zuständigen Person. Da das Zeichen @ bereits eine besondere Bedeutung hat, wird hier „.“ eingegeben. Für root@example.com lautet der Eintrag root.example.com.. Im Verzeichnis „.“ muss angehängt werden, damit die Zone nicht hinzugefügt wird.

  • Durch ( werden alle Zeilen bis einschließlich ) in den SOA-Eintrag aufgenommen.

3

Die Seriennummer ist eine 10-stellige Zahl. Sie muss bei jeder Änderung der Datei ebenfalls geändert werden. Sie wird benötigt, um die sekundären Namenserver (Slave-Server) über Änderungen zu informieren. Dazu ist nun eine 10-stellige Zahl für das Datum und die Laufzeitnummer, geschrieben als YYYYMMDDNN, das übliche Format (YYYY = Jahr, MM = Monat und DD = Tag. NN ist eine Sequenznummer, falls sie an einem Tag mehr als einmal aktualisiert wird).

4

Die Aktualisierungsrate (refresh rate) gibt das Zeitintervall an, in dem die sekundären Namenserver die Seriennummer (serial) der Zone überprüfen. In diesem Fall beträgt dieses Intervall einen Tag.

5

Die Wiederholungsrate (retry) gibt das Zeitintervall an, nach dem ein sekundärer Namenserver bei einem Fehler erneut versucht, Kontakt zum primären Server herzustellen. In diesem Fall sind dies zwei Stunden.

6

Die Ablaufzeit (expiry) gibt den Zeitraum an, nach dem ein sekundärer Server die im Cache gespeicherten Daten verwirft, wenn er keinen erneuten Kontakt zum primären Server herstellen konnte. Hier eine Woche.

7

Die letzte Angabe im SOA-Eintrag gibt die negative Cache-Lebensdauer negative caching TTL an – die Zeitdauer, die Ergebnisse nicht aufgelter DNS-Abfragen von anderen Servern im Cache gespeichert werden knen.

8

IN NS gibt den für diese Domäne verantwortlichen Namenserver an. dns wird zu dns.example.com erweitert; der Eintrag endet nicht auf einen „.“. Es kann mehrere solche Zeilen geben – eine für den primären und jeweils eine für jeden sekundären Namenserver. Wenn notify in /etc/named.conf nicht auf no gesetzt ist, werden alle hier aufgeführten Namenserver über die Änderungen an den Zonendaten informiert.

9

Der MX-Eintrag gibt den Mailserver an, der Emails für die Domäne example.com annimmt, verarbeitet und weiterleitet. In diesem Beispiel ist dies der Host mail.example.com. Die Zahl vor dem Hostnamen ist der Präferenzwert. Wenn mehrere MX-Einträge vorliegen, wird zuerst der Mailserver mit dem kleinsten Wert herangezogen. Falls die Emails nicht an diesen Server zugestellt werden können, wird der Eintrag mit dem nächstkleineren Wert verwendet.

10

Diese und die folgenden Zeilen sind die eigentlichen Adresseinträge, in denen den Hostnamen eine oder mehrere IP-Adressen zugewiesen werden. Die Namen werden hier ohne „.“ aufgelistet, da sie ihre Domäne nicht enthalten. Daher wird ihnen allen example.com hinzugefügt. Dem Host gate werden zwei IP-Adressen zugewiesen, da er zwei Netzwerkkarten aufweist. Bei jeder traditionellen Hostadresse (IPv4) wird der Eintrag mit A gekennzeichnet. Wenn es sich um eine IPv6-Adresse handelt, wird der Eintrag mit AAAA gekennzeichnet.

Anmerkung
Anmerkung: IPv6-Syntax

Die Syntax des IPv6-Eintrags unterscheidet sich geringfügig von der Syntax von IPv4. Aufgrund der Möglichkeit einer Fragmentierung müssen Informationen zu fehlenden Bits vor der Adresse angegeben werden. Um die IPv6-Adresse mit dem erforderlichen Wert „0“ auszufüllen, fügen Sie an der korrekten Stelle in der Adresse zwei Doppelpunkte hinzu. 

pluto     AAAA 2345:00C1:CA11::1234:5678:9ABC:DEF0
pluto     AAAA 2345:00D2:DA11::1234:5678:9ABC:DEF0

11

Der Alias ntp kann zur Adressierung von dns (CNAME steht für canonical name (kanonischer Name)) verwendet werden.

Die Pseudodomäne in-addr.arpa wird für Reverse-Lookups zur Auflösung von IP-Adressen in Hostnamen verwendet. Sie wird in umgekehrter Notation an den Netzwerk-Teil der Adresse angehängt. 192.168 wird also in 168.192.in-addr.arpa aufgelöst. Siehe Beispiel 31.7, „Reverse-Lookup“.

Beispiel 31.7: Reverse-Lookup
 
$TTL 2D 1
168.192.in-addr.arpa.   IN SOA dns.example.com. root.example.com. ( 2
                        2003072441      ; serial
                        1D              ; refresh
                        2H              ; retry
                        1W              ; expiry
                        2D )            ; minimum

                        IN NS           dns.example.com. 3

1.5                     IN PTR          gate.example.com. 4
100.3                   IN PTR          www.example.com.
253.2                   IN PTR          cups.example.com.

1

$TTL definiert die Standard-TTL, die für alle Einträge hier gilt.

2

Die Konfigurationsdatei muss Reverse-Lookup für das Netzwerk 192.168 aktivieren. Wenn die Zone 168.192.in-addr.arpa heißt, sollte sie nicht zu den Hostnamen hinzugefügt werden. Alle Domänen werden daher in vollständiger Form eingegeben: mit ihrer Domäne und mit schließendem „.“.). Die restlichen Einträge entsprechen den im vorherigen Beispiel (example.com) beschriebenen Einträgen.

In Beispiel 31.6, „Die Datei /var/lib/named/example.com.zone“ finden Sie weitere Details zu den Einträgen in diesem Datensatz.

3

Diese Zeile gibt den für diese Zone verantwortlichen Nameserver an. Diesmal wird der Name allerdings in vollständiger Form mit Domäne und „.“ am Ende eingegeben.

4

Diese und die folgenden Zeilen sind die Zeiger-Datensätze, die auf die IP-Adressen an den entsprechenden Hosts hinweisen. Am Anfang der Zeile wird nur der letzte Teil der IP-Adresse eingegeben, ohne „.“ am Ende. Wenn daran die Zone angehängt wird (ohne .in-addr.arpa), ergibt sich die vollständige IP-Adresse in umgekehrter Reihenfolge.

Normalerweise sollten Zonentransfers zwischen verschiedenen Versionen von BIND problemlos möglich sein.

31.7 Dynamische Aktualisierung von Zonendaten

 

Der Ausdruck dynamische Aktualisierung bezieht sich auf Vorgänge, bei denen Einträge in den Zonendateien eines Masterservers hinzugefügt, geändert oder gelöscht werden. Dieser Mechanismus wird in RFC 2136 beschrieben. Die dynamische Aktualisierung wird einzeln für jeden Zoneneintrag konfiguriert; hierzu wird eine optionale Regel allow-update oder update-policy eingefügt. Dynamisch zu aktualisierende Zonen sollten nicht von Hand bearbeitet werden.

Die zu aktualisierenden Einträge werden mit dem Befehl nsupdate an den Server übermittelt. Die genaue Syntax dieses Befehls können Sie der man-Seite für nsupdate (man8 nsupdate) entnehmen. Aus Sicherheitsgründen sollten solche Aktualisierungen mithilfe von TSIG-Schlüsseln durchgeführt werden, wie in Abschnitt 31.8, „Sichere Transaktionen“ beschrieben.

31.8 Sichere Transaktionen

 

Sichere Transaktionen können mit Transaktionssignaturen (TSIGs) durchgeführt werden, die auf gemeinsam genutzten geheimen Schlüsseln (auch TSIG-Schlüssel genannt) beruhen. In diesem Abschnitt wird die Erstellung und Verwendung solcher Schlüssel beschrieben.

Sichere Transaktionen werden für die Kommunikation zwischen verschiedenen Servern und für die dynamische Aktualisierung von Zonendaten benötigt. Die Zugriffssteuerung von Schlüsseln abhängig zu machen, ist wesentlich sicherer, als sich lediglich auf IP-Adressen zu verlassen.

Erstellen Sie mit dem folgenden Befehl einen TSIG-Schlüssel (genauere Informationen finden Sie unter man tsig-keygen): 

tux > sudo tsig-keygen -a hmac-md5 host1-host2 > host1-host2.key

Hiermit wird eine Datei mit dem Namen host1-host2.key erstellt, deren Inhalt etwa wie folgt aussieht: 

key "host1-host2" {                       |
    algorithm hmac-md5;
    secret "oHpBLgtcZso6wxnRTWdJMA==";
};

Die Datei muss auf den Remote-Host übertragen werden, nach Möglichkeit auf sichere Weise (z. B. mit scp). Damit die sichere Kommunikation zwischen host1 und host2 gewährleistet ist, muss der Schlüssel sowohl auf dem lokalen Server als auch auf dem Remote-Server in die Datei /etc/named.conf aufgenommen werden. 

key host1-host2 {
 algorithm hmac-md5;
 secret "ejIkuCyyGJwwuN3xAteKgg==";
};
Warnung
Warnung: Dateiberechtigungen von /etc/named.conf

Vergewissern Sie sich, dass die Berechtigungen von /etc/named.conf ordnungsgemäß eingeschränkt sind. Der Standardwert für diese Datei lautet 0640, mit root als Eigentümer und named als Gruppe. Alternativ können Sie die Schlüssel in eine gesonderte Datei mit speziell eingeschränkten Berechtigungen verschieben, die dann aus /etc/named.conf eingefügt werden. Zum Einschließen einer externen Datei verwenden Sie: 

include  "filename"

Ersetzen Sie filename durch einen absoluten Pfad zu Ihrer Datei mit den Schlüsseln.

Damit Server host1 den Schlüssel für host2 verwenden kann (in diesem Beispiel mit der Adresse 10.1.2.3), muss die Datei /etc/named.conf des Servers folgende Regel enthalten: 

server 10.1.2.3 {
  keys { host1-host2. ;};
};

Analoge Einträge müssen in die Konfigurationsdateien von host2 aufgenommen werden.

Fügen Sie TSIG-Schlüssel für alle ACLs (Access Control Lists, Zugriffssteuerungslisten, nicht zu verwechseln mit Dateisystem-ACLs) hinzu, die für IP-Adressen und -Adressbereiche definiert sind, um Transaktionssicherheit zu gewährleisten. Der entsprechende Eintrag könnte wie folgt aussehen: 

allow-update { key host1-host2. ;};

Dieses Thema wird eingehender im Referenzhandbuch für BIND-Administratoren (unter update-policy) erörtert.

31.9 DNS-Sicherheit

 

DNSSEC, also die DNS-Sicherheit, wird in RFC 2535 beschrieben. Die verfügbaren Werkzeuge für DNSSEC werden im BIND-Handbuch erörtert.

Einer als sicher betrachteten Zone müssen ein oder mehrere Zonenschlüssel zugeordnet sein. Diese werden mit dnssec-keygen erstellt, genau wie die Host-Schlüssel. Zurzeit wird der DSA-Verschlüsselungsalgorithmus zum Erstellen dieser Schlüssel verwendet. Die generierten öffentlichen Schlüssel sollten mithilfe einer $INCLUDE-Regel in die entsprechende Zonendatei aufgenommen werden.

Mit dem Kommando dnssec-signzone können Sie Sets von generierten Schlüsseln (keyset-Dateien) erstellen, sie auf sichere Weise in die übergeordnete Zone übertragen und sie signieren. Auf diese Weise werden die Dateien generiert, die in die einzelnen Zonen in /etc/named.conf aufgenommen werden sollen.

31.10 Weitere Informationen

 

Weitere Informationen können Sie dem Referenzhandbuch für BIND-Administratoren im Paket bind-doc entnehmen, das unter /usr/share/doc/packages/bind/arm installiert ist. Außerdem könnten Sie die RFCs zurate ziehen, auf die im Handbuch verwiesen wird, sowie die in BIND enthaltenen man-Seiten. /usr/share/doc/packages/bind/README.SUSE enthält aktuelle Informationen zu BIND in SUSE Linux Enterprise Server.

32 DHCP

 

DHCP (Dynamic Host Configuration Protocol) dient dazu, Einstellungen in einem Netzwerk zentral (von einem Server) aus zuzuweisen. Einstellungen müssen also nicht dezentral an einzelnen Arbeitsplatzcomputern konfiguriert werden. Ein für DHCP konfigurierter Host verfügt nicht über eine eigene statische Adresse. Er konfiguriert sich stattdessen vollständig und automatisch nach den Vorgaben des DHCP-Servers. Wenn Sie auf der Clientseite den NetworkManager verwenden, brauchen Sie den Client nicht zu konfigurieren. Das ist nützlich, wenn Sie in wechselnden Umgebungen arbeiten und nur jeweils eine Schnittstelle aktiv ist. Verwenden Sie den NetworkManager nie auf einem Computer, der einen DHCP-Server ausführt.

Tipp
Tipp: IBM Z: Unterstützung für DHCP

Auf IBM Z-Plattformen funktioniert DHCP nur bei Schnittstellen, die die OSA- und OSA Express-Netzwerkkarten verwenden. Nur diese Karten verfügen über eine für die Autokonfigurationsfunktionen von DHCP erforderliche MAC-Adresse.

Zum einen kann ein DHCP-Server so konfiguriert werden, dass er jeden Client anhand der Hardware-Adresse seiner Netzwerkkarte (die in der Regel unveränderlich sein sollte) identifiziert und ständig mit denselben Einstellungen versorgt, sobald der Client eine Verbindung herstellt. Zum anderen kann DHCP aber auch so konfiguriert werden, dass der Server jedem relevanten Client eine Adresse aus einem dafür vorgesehenen Adresspool dynamisch zuweist. In diesem Fall versucht der DHCP-Server, dem Client bei jeder Anforderung dieselbe Adresse zuzuweisen – auch über einen längeren Zeitraum hinweg. Das ist nur möglich, wenn die Anzahl der Clients im Netzwerk nicht die Anzahl der Adressen übersteigt.

DHCP erleichtert Systemadministratoren das Leben. Alle (selbst umfangreiche) Änderungen der Netzwerkadressen oder der -konfiguration können zentral in der Konfigurationsdatei des DHCP-Servers vorgenommen werden. Dies ist sehr viel komfortabler als das Neukonfigurieren zahlreicher Arbeitsstationen. Außerdem können vor allem neue Computer sehr einfach in das Netzwerk integriert werden, indem sie aus dem Adresspool eine IP-Adresse zugewiesen bekommen. Das Abrufen der entsprechenden Netzwerkeinstellungen von einem DHCP-Server ist auch besonders interessant für Notebooks, die regelmäßig in unterschiedlichen Netzwerken verwendet werden.

In diesem Kapitel wird der DHCP-Server im gleichen Subnetz wie die Workstations (192.168.2.0/24) mit 192.168.2.1 als Gateway ausgeführt. Er hat die feste IP-Adresse 192.168.2.254 und bedient die beiden Adressbereiche 192.168.2.10 bis 192.168.2.20 und 192.168.2.100 bis 192.168.2.200.

Neben IP-Adresse und Netzmaske werden dem Client nicht nur der Computer- und Domänenname, sondern auch das zu verwendende Gateway und die Adressen der Nameserver mitgeteilt. Im Übrigen können auch mehrere Parameter zentral konfiguriert werden, z. B. ein Zeitserver, von dem die Clients die aktuelle Uhrzeit abrufen können, oder ein Druckserver.

32.1 Konfigurieren eines DHCP-Servers mit YaST

 

Zur Installation eines DNS-Servers starten Sie YaST, und wählen Sie Software › Software installieren oder löschen. Wählen Sie Filter › Schemata und schließlich DHCP- und DNS-Server aus. Bestätigen Sie die Installation der abhängigen Pakete, um den Installationsvorgang abzuschließen.

Wichtig
Wichtig: LDAP-Unterstützung

Das DHCP-Modul von YaST kann so eingestellt werden, dass die Serverkonfiguration lokal gespeichert wird (auf dem Host, der den DHCP-Server ausführt), oder so, dass die Konfigurationsdaten von einem LDAP-Server verwaltet werden. Soll LDAP verwendet werden, richten Sie die LDAP-Umgebung ein, bevor Sie den DHCP-Server konfigurieren.

Weitere Informationen zu LDAP finden Sie im Book “Security and Hardening Guide”, Chapter 5 “LDAP with 389 Directory Server”.

Das DHCP-Modul von YaST (yast2-dhcp-server) ermöglicht die Einrichtung Ihres eigenen DHCP-Servers für das lokale Netzwerk. Das Modul kann im Assistentenmodus oder im Expertenkonfigurationsmodus ausgeführt werden.

32.1.1 Anfängliche Konfiguration (Assistent)

 

Beim ersten Starten des Moduls werden Sie von einem Assistenten aufgefordert, einige grundlegende Entscheidungen hinsichtlich der Serveradministration zu treffen. Nach Abschluss der anfänglichen Konfiguration ist eine grundlegende Serverkonfiguration verfügbar, die für einfache Szenarien ausreichend ist. Komplexere Konfigurationsaufgaben können im Expertenmodus ausgeführt werden. Führen Sie dazu die folgenden Schritte aus:

  1. Wählen Sie in dieser Liste die Schnittstelle aus, die der DHCP-Server überwachen soll, klicken Sie auf Auswählen und anschließend auf Weiter. Siehe Abbildung 32.1, „DHCP-Server: Kartenauswahl“.

    Anmerkung
    Anmerkung: DHCP und firewalld

    Beachten Sie, dass die Option Firewall für ausgewählte Schnittstellen öffnen (noch) nicht firewalld in SUSE Linux Enterprise Server 15 SP3 unterstützt. Führen Sie folgendes Kommando aus, um den DHCP-Port manuell zu öffnen: 

           tux > sudo firewall-cmd --zone=public --permanent --add-service=dhcp
       tux > sudo firewall-cmd --reload
    DHCP-Server: Kartenauswahl
    Abbildung 32.1: DHCP-Server: Kartenauswahl
     

  2. Geben Sie anhand des Kontrollkästchens an, ob Ihre DHCP-Einstellungen automatisch von einem LDAP-Server gespeichert werden sollen. In den Textfeldern legen Sie die Netzwerkinformationen fest, die jeder von diesem DHCP-Server verwaltete Client erhalten soll. Diese sind: Domänenname, Adresse eines Zeitservers, Adressen der primären und sekundären Namenserver, Adressen eines Druck- und WINS-Servers (für gemischte Netzwerkumgebungen mit Windows- und Linux-Clients), Gateway-Adressen und Leasing-Zeit. Siehe Abbildung 32.2, „DHCP-Server: globale Einstellungen“.

    DHCP-Server: globale Einstellungen
    Abbildung 32.2: DHCP-Server: globale Einstellungen
     

  3. Konfigurieren Sie die Vergabe der dynamischen IP-Adressen an Clients. Hierzu legen Sie einen Bereich von IP-Adressen fest, in dem die zu vergebenden Adressen der DHCP-Clients liegen dürfen. Alle zu vergebenden Adressen müssen unter eine gemeinsame Netzmaske fallen. Legen Sie abschließend die Leasing-Zeit fest, für die ein Client seine IP-Adresse behalten darf, ohne eine Verlängerung der Leasing-Zeit beantragen zu müssen. Legen Sie optional auch die maximale Leasing-Zeit fest, für die eine bestimmte IP-Adresse auf dem Server für einen bestimmten Client reserviert bleibt. Siehe Abbildung 32.3, „DHCP-Server: dynamisches DHCP“.

    DHCP-Server: dynamisches DHCP
    Abbildung 32.3: DHCP-Server: dynamisches DHCP
     

  4. Geben Sie an, auf welche Weise der DHCP-Server gestartet werden soll. Legen Sie fest, ob der DHCP-Server automatisch beim Booten des Systems oder bei Bedarf manuell (z. B. zu Testzwecken) gestartet werden soll. Klicken Sie auf Verlassen, um die Konfiguration des Servers abzuschließen. Siehe Abbildung 32.4, „DHCP-Server: Start“.

    DHCP-Server: Start
    Abbildung 32.4: DHCP-Server: Start
     

  5. Statt der Verwendung des dynamischen DHCP, wie in den vorigen Schritten beschrieben, können Sie den Server auch so konfigurieren, dass Adressen in fast statischer Weise zugewiesen werden. Geben Sie in die Textfelder im unteren Teil eine Liste der in dieser Art zu verwaltenden Clients ein. Geben Sie vor allem Name und IP-Adresse für einen solchen Client an, die Hardware-Adresse und den Netzwerktyp (Token-Ring oder Ethernet). Ändern Sie die oben angezeigte Liste der Clients mit Hinzufügen, Bearbeiten und Löschen. Siehe Abbildung 32.5, „DHCP-Server: Host-Verwaltung“.

    DHCP-Server: Host-Verwaltung
    Abbildung 32.5: DHCP-Server: Host-Verwaltung
     

32.1.2 DHCP-Server-Konfiguration (Experten)

 

Zusätzlich zu den bisher erwähnten Konfigurationsmethoden gibt es einen Expertenkonfigurationsmodus, mit dem Sie die Einrichtung des DHCP-Servers detailgenau ändern können. Zum Starten der Expertenkonfiguration klicken Sie auf Expertenkonfiguration für DHCP-Server im Dialogfeld Start (siehe Abbildung 32.4, „DHCP-Server: Start“).

Chroot-Umgebung und Deklarationen

Im ersten Dialogfeld bearbeiten Sie die vorhandene Konfiguration, indem Sie DHCP-Server starten wählen. Eine wichtige Funktion des Verhaltens eines DHCP-Servers ist, dass er in einer Chroot-Umgebung (oder einem Chroot-Jail) ausgeführt werden kann und so den Server-Host schützt. Sollte der DHCP-Server durch einen Angriff von außen beeinträchtigt werden, bleibt der Angreifer im Chroot-Jail und kann auf den Rest des Systems nicht zugreifen. Im unteren Bereich des Dialogfelds sehen Sie eine Baumstruktur mit den bereits definierten Deklarationen. Diese verändern Sie mit Hinzufügen, Löschen und Bearbeiten. Wenn Sie Erweitert wählen, werden zusätzliche Experten-Dialogfelder angezeigt. Weitere Informationen hierzu finden Sie im Abbildung 32.6, „DHCP-Server: Chroot Jail und Deklarationen“. Wenn Sie Hinzufügen ausgewählt haben, definieren sie den Typ der hinzuzufügenden Deklaration. Mit Erweitert können Sie die Protokolldatei des Servers abrufen, die TSIG-Schlüsselverwaltung konfigurieren und die Konfiguration der Firewall gemäß der Einrichtung des DHCP-Servers anpassen.

DHCP-Server: Chroot Jail und Deklarationen
Abbildung 32.6: DHCP-Server: Chroot Jail und Deklarationen
 
Auswählen des Deklarationstyps

Die Globalen Optionen des DHCP-Servers bestehen aus mehreren Deklarationen. In diesem Dialogfeld legen Sie die Deklarationstypen Subnetz, Host, Gemeinsames Netzwerk, Gruppe, Adressen-Pool und Klasse fest. In diesem Beispiel sehen Sie die Auswahl eines neuen Subnetzes (siehe Abbildung 32.7, „DHCP-Server: Auswählen eines Deklarationstyps“).

DHCP-Server: Auswählen eines Deklarationstyps
Abbildung 32.7: DHCP-Server: Auswählen eines Deklarationstyps
 
Konfiguration des Subnetzes

In diesem Dialogfeld können Sie ein neues Subnetz mit seiner IP-Adresse und Netzmaske angeben. In der Mitte des Dialogfelds ändern Sie die Startoptionen des DHCP-Servers für das ausgewählte Subnetz mit den Optionen Hinzufügen, Bearbeiten und Löschen. Um einen dynamischen DNS für das Subnetz einzurichten, wählen Sie Dynamisches DNS.

DHCP-Server: Konfigurieren von Subnetzen
Abbildung 32.8: DHCP-Server: Konfigurieren von Subnetzen
 
TSIG-Schlüsselverwaltung

Wenn Sie im vorigen Dialogfeld die Konfiguration des dynamischen DNS vorgenommen haben, können Sie jetzt die Schlüsselverwaltung für einen sicheren Zonentransfer konfigurieren. Wenn Sie OK wählen, gelangen Sie zu einem weiteren Dialogfeld, in dem Sie die Schnittstelle für das dynamische DNS konfigurieren können (siehe Abbildung 32.10, „DHCP-Server: Schnittstellenkonfiguration für dynamisches DNS“).

DHCP-Server: TSIG-Konfiguration
Abbildung 32.9: DHCP-Server: TSIG-Konfiguration
 
Dynamisches DNS: Schnittstellenkonfiguration

Jetzt können Sie das dynamische DNS für das Subnetz aktivieren, indem Sie Dynamisches DNS für dieses Subnetz aktivieren wählen. Danach aktivieren Sie im Dropdown-Feld die TSIG-Schlüssel für Forward und Reverse Zones. Vergewissern Sie sich dabei, dass die Schlüssel für den DNS- und den DHCP-Server dieselben sind. Mit der Option Globale dynamische DNS-Einstellungen aktualisieren aktivieren Sie die automatische Aktualisierung und Einstellung der globalen DHCP-Servereinstellungen entsprechend der dynamischen DNS-Umgebung. Nun legen Sie fest, welche Forward und Reverse Zones über das dynamische DNS aktualisiert werden sollen. Dafür geben Sie den primären Namenserver für beide Zonen an. Wenn Sie OK wählen, gelangen Sie wieder zum Dialogfeld für die Subnetzkonfiguration (siehe Abbildung 32.8, „DHCP-Server: Konfigurieren von Subnetzen“). Wenn Sie noch einmal auf OK klicken, gelangen Sie wieder zum ursprünglichen Dialogfeld für die Expertenkonfiguration.

DHCP-Server: Schnittstellenkonfiguration für dynamisches DNS
Abbildung 32.10: DHCP-Server: Schnittstellenkonfiguration für dynamisches DNS
 
Anmerkung
Anmerkung: Option ignore client-updates

Wenn Sie dynamisches DNS für eine Zone aktivieren, fügt YaST automatisch die Option ignore client-updates hinzu, um die Client-Kompatibilität zu erhöhen. Die Option kann deaktiviert werden, wenn sie nicht benötigt wird.

Netzwerkschnittstellenkonfiguration

Wenn Sie die Schnittstellen festlegen möchten, die vom DHCP-Server überwacht werden sollen, und die Firewall-Konfiguration anpassen, wählen Sie im Dialogfeld für die Expertenkonfiguration Erweitert › Schnittstellenkonfiguration. In der Liste der angezeigten Schnittstellen wählen Sie die gewünschte(n) Schnittstelle(n) für den DHCP-Server aus. Falls Clients in allen Subnetzen mit dem Server kommunizieren müssen und der Server-Host durch eine Firewall geschützt ist, passen Sie die Einstellungen der Firewall entsprechend an.

Anmerkung
Anmerkung: DHCP und firewalld

Beachten Sie, dass die Option Firewall für ausgewählte Schnittstellen öffnen (noch) nicht firewalld in SUSE Linux Enterprise Server 15 SP3 unterstützt. Führen Sie folgendes Kommando aus, um den DHCP-Port manuell zu öffnen: 

        tux > sudo firewall-cmd --zone=public --permanent --add-service=dhcp
        tux > sudo firewall-cmd --reload
DHCP-Server: Netzwerkschnittstelle und Firewall
Abbildung 32.11: DHCP-Server: Netzwerkschnittstelle und Firewall
 

Nach Abschluss aller Konfigurationsschritte schließen Sie das Dialogfeld mit OK. Der Server wird jetzt mit seiner neuen Konfiguration gestartet.

32.2 DHCP-Softwarepakete

 

Sowohl der DHCP-Server als auch die DHCP-Clients stehen für SUSE Linux Enterprise Server zur Verfügung. Der vom Internet Systems Consortium (ISC) herausgegebene DHCP-Server dhcpd stellt die Serverfunktionalität zur Verfügung. Auf der Clientseite befinden sich dhcp-client (ebenfalls von ISC) sowie Werkzeuge aus dem wicked-Paket.

Standardmäßig werden die wicked-Werkzeuge mit den Diensten wicked-dhcp4 und wicked-dhcp6 installiert. Beide Services werden automatisch bei jedem Booten des Systems gestartet und übernehmen die Überwachung auf einem DHCP-Server. Sie kommen ohne eine Konfigurationsdatei aus und funktionieren im Normalfall ohne weitere Konfiguration. Für komplexere Situationen greifen Sie auf dhcp-client von ISC zurück, das sich über die Konfigurationsdateien /etc/dhclient.conf und /etc/dhclient6.conf steuern lässt.

32.3 Der DHCP-Server dhcpd

 

Das Kernstück des DHCP-Systems ist der dhcpd-Daemon. Dieser Server least Adressen und überwacht deren Nutzung gemäß den Vorgaben in der Konfigurationsdatei /etc/dhcpd.conf. Über die dort definierten Parameter und Werte stehen dem Systemadministrator eine Vielzahl von Möglichkeiten zur Verfügung, das Verhalten des Programms anforderungsgemäß zu beeinflussen. Sehen Sie sich die einfache Beispieldatei /etc/dhcpd.conf in Beispiel 32.1, „Die Konfigurationsdatei /etc/dhcpd.conf“ an.

Beispiel 32.1: Die Konfigurationsdatei /etc/dhcpd.conf
 
default-lease-time 600;         # 10 minutes
max-lease-time 7200;            # 2  hours

option domain-name "example.com";
option domain-name-servers 192.168.1.116;
option broadcast-address 192.168.2.255;
option routers 192.168.2.1;
option subnet-mask 255.255.255.0;

subnet 192.168.2.0 netmask 255.255.255.0
 {
  range 192.168.2.10 192.168.2.20;
  range 192.168.2.100 192.168.2.200;
 }

Diese einfache Konfigurationsdatei reicht bereits aus, damit der DHCP-Server im Netzwerk IP-Adressen zuweisen kann. Bitte achten Sie insbesondere auf die Semikolons am Ende jeder Zeile, ohne die dhcpd nicht startet.

Die Beispieldatei lässt sich in drei Abschnitte unterteilen. Im ersten Abschnitt wird definiert, wie viele Sekunden eine IP-Adresse standardmäßig an einen anfragenden Client geleast wird, bevor dieser eine Verlängerung anfordern sollte (default-lease-time). Hier wird auch festgelegt, wie lange ein Computer maximal eine vom DHCP-Server vergebene IP-Adresse behalten darf, ohne für diese eine Verlängerung anfordern zu müssen (max-lease-time).

Im zweiten Abschnitt werden einige grundsätzliche Netzwerkparameter global festgelegt:

  • Die Zeile option domain-name enthält die Standarddomäne des Netzwerks.

  • Mit dem Eintrag option domain-name-servers können Sie bis zu drei Werte für die DNS-Server angeben, die zur Auflösung von IP-Adressen in Hostnamen (und umgekehrt) verwendet werden sollen. Idealerweise sollten Sie vor dem Einrichten von DHCP einen Namenserver auf dem Computer oder im Netzwerk konfigurieren. Dieser Nameserver sollte für jede dynamische Adresse jeweils einen Hostnamen und umgekehrt bereithalten. Weitere Informationen zum Konfigurieren eines eigenen Namenservers finden Sie in Kapitel 31, Domain Name System (DNS).

  • Die Zeile option broadcast-address definiert die Broadcast-Adresse, die der anfragende Client verwenden soll.

  • Mit option routers wird festgelegt, wohin der Server Datenpakete schicken soll, die (aufgrund der Adresse von Quell- und Zielhost sowie der Subnetzmaske) nicht im lokalen Netzwerk zugestellt werden können. In der Regel ist gerade bei kleineren Netzwerken dieser Router auch meist mit dem Internet-Gateway identisch.

  • Mit option subnet-mask wird die den Clients zugewiesene Netzmaske angegeben.

Im letzten Abschnitt der Datei werden ein Netzwerk und eine Subnetzmaske angegeben. Abschließend muss noch ein Adressbereich gewählt werden, aus dem der DHCP-Daemon IP-Adressen an anfragende Clients vergeben darf. In Beispiel 32.1, „Die Konfigurationsdatei /etc/dhcpd.conf“ können Clients Adressen zwischen 192.168.2.10 und 192.168.2.20 oder 192.168.2.100 und 192.168.2.200 zugewiesen werden.

Nach dem Bearbeiten dieser wenigen Zeilen sollten Sie bereits in der Lage sein, den DHCP-Daemon mit dem Befehl systemctl start dhcpd zu aktivieren. Der DHCP-Daemon ist sofort einsatzbereit. Mit dem Befehl rcdhcpd check-syntax können Sie eine kurze Überprüfung der Konfigurationsdatei vornehmen. Sollte wider Erwarten ein Problem mit der Konfiguration auftreten (der Server wird beispielsweise mit einem Fehler beendet oder gibt beim Starten nicht done zurück), finden Sie in der zentralen Systemprotokolldatei, die mit dem Kommando journalctl abgefragt werden kann, weitere Informationen dazu (siehe Kapitel 17, journalctl: Abfragen des systemd-Journals).

Auf einem SUSE Linux Enterprise-Standardsystem wird der DHCP-Daemon aus Sicherheitsgründen in einer chroot-Umgebung gestartet. Damit der Daemon die Konfigurationsdateien finden kann, müssen diese in die chroot-Umgebung kopiert werden. In der Regel müssen Sie dazu nur den Befehl systemctl start dhcpd eingeben und die Dateien werden automatisch kopiert.

32.3.1 Clients mit statischen IP-Adressen

 

DHCP lässt sich auch verwenden, um einem bestimmten Client eine vordefinierte statische Adresse zuzuweisen. Solche expliziten Adresszuweisungen haben Vorrang vor dynamischen Adressen aus dem Pool. Im Unterschied zu den dynamischen verfallen die statischen Adressinformationen nie, z. B. wenn nicht mehr genügend freie Adressen zur Verfügung stehen und deshalb eine Neuverteilung unter den Clients erforderlich ist.

Zur Identifizierung eines mit einer statischen Adresse konfigurierten Clients verwendet dhcpd die Hardware-Adresse. Dies ist eine global eindeutige, fest definierte Zahl aus sechs Oktettpaaren, über die jedes Netzwerkgerät verfügt, z. B. 00:30:6E:08:EC:80. Werden die entsprechenden Zeilen, wie z. B. in Beispiel 32.2, „Ergänzungen zur Konfigurationsdatei“ zur Konfigurationsdatei von Beispiel 32.1, „Die Konfigurationsdatei /etc/dhcpd.conf“ hinzugefügt, weist der DHCP-Daemon dem entsprechenden Client immer dieselben Daten zu.

Beispiel 32.2: Ergänzungen zur Konfigurationsdatei
 
host jupiter {
hardware ethernet 00:30:6E:08:EC:80;
fixed-address 192.168.2.100;
}

Der Name des entsprechenden Clients (host HOSTNAME, hier jupiter) wird in die erste Zeile und die MAC-Adresse wird in die zweite Zeile eingegeben. Auf Linux-Hosts kann die MAC-Adresse mit dem Befehl ip link show gefolgt vom Netzwerkgerät (z. B. eth0) ermittelt werden. Die Ausgabe sollte in etwa wie folgt aussehen: 

link/ether 00:30:6E:08:EC:80

Im vorherigen Beispiel wird also dem Client, dessen Netzwerkkarte die MAC-Adresse 00:30:6E:08:EC:80 hat, automatisch die IP-Adresse 192.168.2.100 und der Hostname jupiter zugewiesen. Als Hardwaretyp kommt heutzutage in aller Regel ethernet zum Einsatz, wobei durchaus auch das vor allem bei IBM-Systemen häufig zu findende token-ring unterstützt wird.

32.3.2 Die Version von SUSE Linux Enterprise Server

 

Aus Sicherheitsgründen enthält bei SUSE Linux Enterprise Server der DHCP-Server von ISC den non-root/chroot-Patch von Ari Edelkind. Damit kann dhcpd mit der Benutzer-ID nobody und in einer chroot-Umgebung (/var/lib/dhcp) ausgeführt werden. Um dies zu ermöglichen, muss sich die Konfigurationsdatei dhcpd.conf im Verzeichnis /var/lib/dhcp/etc befinden. Sie wird vom Init-Skript beim Start automatisch dorthin kopiert.

Dieses Verhalten lässt sich über Einträge in der Datei /etc/sysconfig/dhcpd steuern. Um den dhcpd ohne chroot-Umgebung laufen zu lassen, setzen Sie die Variable DHCPD_RUN_CHROOTED in der Datei /etc/sysconfig/dhcpd auf „no“.

Damit der dhcpd auch in der chroot-Umgebung Hostnamen auflösen kann, müssen außerdem einige weitere Konfigurationsdateien kopiert werden:

  • /etc/localtime

  • /etc/host.conf

  • /etc/hosts

  • /var/run/netconfig/resolv.conf

Diese Dateien werden beim Starten des Init-Skripts in das Verzeichnis /var/lib/dhcp/etc/ kopiert. Berüchsichtigen Sie die Kopien bei Aktualisierungen, die benötigt werden, wenn sie durch ein Skript wie /etc/ppp/ip-up dynamisch modifiziert werden. Falls in der Konfigurationsdatei anstelle von Hostnamen nur IP-Adressen verwendet werden, sind jedoch keine Probleme zu erwarten.

Wenn in Ihrer Konfiguration weitere Dateien in die chroot-Umgebung kopiert werden müssen, können Sie diese mit der Variablen DHCPD_CONF_INCLUDE_FILES in der Datei /etc/sysconfig/dhcpd festlegen. Damit der dhcp-Daemon aus der chroot-Umgebung heraus auch nach einem Neustart des syslog-Daemons weiter protokollieren kann, befindet sich der zusätzliche Eintrag SYSLOGD_ADDITIONAL_SOCKET_DHCP in der Datei /etc/sysconfig/syslog.

32.4 Weitere Informationen

 

Weitere Informationen zu DHCP finden Sie auf der Website des Internet Systems Consortium (https://www.isc.org/dhcp/). Weitere Informationen finden Sie zudem auf den man-Seiten dhcpd, dhcpd.conf, dhcpd.leases und dhcp-options.

33 SLP

 

Um einen Netzwerkclient konfigurieren zu können, benötigen Sie eingehende Kenntnisse zu den Diensten, die über das Netzwerk bereitgestellt werden (z. B. Drucken oder LDAP). Als Erleichterung der Konfiguration dieser Dienste auf einem Netzwerkclient wurde das SLP („service location protocol“) entwickelt. SLP teilt allen Clients im lokalen Netzwerk die Verfügbarkeit und die Konfigurationsdaten ausgewählter Dienste mit. Anwendungen mit SLP-Unterstützung können diese Informationen verarbeiten und damit automatisch konfiguriert werden.

SUSE® Linux Enterprise Server unterstützt die Installation von per SLP bekannt gegebenen Installationsquellen und beinhaltet viele Systemdienste mit integrierter Unterstützung für SLP. Nutzen Sie SLP, um vernetzten Clients zentrale Funktionen wie Installationsserver, YOU-Server, Dateiserver oder Druckserver auf Ihrem System zur Verfügung zu stellen. Dienste mit SLP-Unterstützung sind beispielsweise login, ntp, openldap2-client, postfix, rpasswd, rsyncd, saned, sshd (über fish), vnc und ypserv.

Alle Pakete, die zur Verwendung von SLP-Diensten auf einem Netzwerkclient erforderlich sind, werden standardmäßig installiert. Falls Sie jedoch Dienste via SLP bereitstellen möchten, müssen Sie sicherstellen, dass auch das Paket openslp-server installiert wird.

33.1 Das SLP-Frontend slptool

 

Mit dem Kommandozeilenwerkzeug slptool werden SLP-Dienste abgefragt und registriert. Die Abfragefunktionen sind bei der Diagnose von Nutzen. Im Folgenden werden die wichtigsten Subkommandos von slptool aufgeführt. Mit slptool --help werden alle verfügbaren Optionen und Funktionen aufgelistet.

findsrvtypes

Zeigt eine Liste aller Dienste an, die im Netzwerk verfügbar sind. 

tux > slptool findsrvtypes
service:install.suse:nfs
service:install.suse:ftp
service:install.suse:http
service:install.suse:smb
service:ssh
service:fish
service:YaST.installation.suse:vnc
service:smtp
service:domain
service:management-software.IBM:hardware-management-console
service:rsync
service:ntp
service:ypserv
findsrvs DIENSTTYP

Zeigt eine Liste aller Server an, die den gewünschten DIENSTTYP bereitstellen. 

tux > slptool findsrvs service:ntp
service:ntp://ntp.example.com:123,57810
service:ntp://ntp2.example.com:123,57810
findattrs DIENSTTYPHOST

Zeigt eine Liste der Attribute für den DIENSTTYP auf dem HOST an. 

tux > slptool findattrs service:ntp://ntp.example.com
(owner=tux),(email=tux@example.com)
register DIENSTTYP//HOST:PORT "(ATTRIBUT=WERT),(ATTRIBUT=WERT)"

Registriert den DIENSTTYP auf dem HOST, wobei optional eine Liste mit Attributen angegeben werden kann. 

slptool register service:ntp://ntp.example.com:57810 \
"(owner=tux),(email=tux@example.com)"
deregister DIENSTTYP//HOST

Hebt die Registrierung des DIENSTTYPS auf dem HOST auf. 

slptool deregister service:ntp://ntp.example.com

Weitere Informationen erhalten Sie mit dem Kommando slptool --help.

33.2 Bereitstellen von Diensten über SLP

 

Zum Bereitstellen von SLP-Diensten muss der SLP-Daemon (slpd) ausgeführt werden. Wie die meisten Systemdienste unter SUSE Linux Enterprise Server wird der slpd-Daemon über ein separates Startskript gesteuert. Nach der Installation ist der Daemon standardmäßig inaktiv. Zum Aktivieren für die aktuelle Sitzung führen Sie den Befehl sudo systemctl start slpd aus. Wenn slpd beim Systemstart aktiviert werden soll, führen Sie den Befehl sudo systemctl enable slpd aus.

Viele Anwendungen unter SUSE Linux Enterprise Server verfügen durch die libslp-Bibliothek über eine integrierte SLP-Unterstützung. Falls ein Dienst ohne SLP-Unterstützung kompiliert wurde, können Sie ihn mit einer der folgenden Methoden per SLP verfügbar machen:

Statische Registrierung über /etc/slp.reg.d

Legen Sie für jeden neuen Dienst eine separate Registrierungsdatei an. Im folgenden Beispiel wird ein Scannerdienst registriert: 

## Register a saned service on this system
## en means english language
## 65535 disables the timeout, so the service registration does
## not need refreshes
service:scanner.sane://$HOSTNAME:6566,en,65535
watch-port-tcp=6566
description=SANE scanner daemon

Die wichtigste Zeile dieser Datei ist die Dienst-URL, die mit service: beginnt. Sie enthält den Diensttyp (scanner.sane) und die Adresse, unter der der Dienst auf dem Server verfügbar ist. $HOSTNAME wird automatisch durch den vollständigen Hostnamen ersetzt. Abgetrennt durch einen Doppelpunkt folgt nun der Name des TCP-Ports, auf dem der entsprechende Dienst gefunden werden kann. Geben Sie nun die Sprache an, in der der Dienst angekündigt werden soll, und die Gültigkeitsdauer der Registrierung in Sekunden. Diese Angaben müssen durch Kommas von der Dienst-URL getrennt werden. Wählen Sie für die Registrierungsdauer einen Wert zwischen 0 und 65535. 0 verhindert die Registrierung. Mit 65535 werden alle Einschränkungen aufgehoben.

Die Registrierungsdatei enthält außerdem die beiden Variablen watch-port-tcp und description. watch-port-tcp koppelt die SLP-Dienstankündigung daran, ob der entsprechende Dienst aktiv ist, indem slpd den Status des Diensts überprüft. Die zweite Variable enthält eine genauere Beschreibung des Diensts, die in den entsprechenden Browsern angezeigt wird.

Tipp
Tipp: YaST und SLP

Einige von YaST bereitgestellte Services, wie ein Installationsserver oder YOU-Server, führen diese Registrierung automatisch aus, wenn Sie SLP in den Modul-Dialogfeldern aktivieren. Dann erstellt YaST Registrierungsdateien für diese Dienste.

Statische Registrierung über /etc/slp.reg

Der einzige Unterschied zwischen dieser Methode und der Prozedur mit /etc/slp.reg.d besteht darin, dass alle Dienste in einer zentralen Datei gruppiert sind.

Dynamische Registrierung über slptool

Wenn ein Dienst dynamisch ohne Verwendung von Konfigurationsdateien registriert werden soll, verwenden Sie das Kommandozeilenprogramm slptool. Dasselbe Programm kann auch die Registrierung eines bestehenden Dienstangebots aufheben, ohne slpd neu zu starten. Ausführliche Informationen finden Sie unter Abschnitt 33.1, „Das SLP-Frontend slptool“.

33.2.1 Einrichten eines SLP-Installationsservers

 

Die Bereitstellung der Installationsdaten über SLP im Netzwerk erleichtert die Netzwerkinstallation deutlich, da die Installationsdaten (z. B. IP-Adresse des Servers oder Pfad zu den Installationsmedien) automatisch über eine SLP-Abfrage angefordert werden. Weitere Anweisungen finden Sie im Book “Bereitstellungshandbuch”, Chapter 16 “Einrichten einer Netzwerkinstallationsquelle”.

33.3 Weitere Informationen

 
RFC 2608, 2609, 2610

RFC 2608 befasst sich mit der Definition von SLP im Allgemeinen. RFC 2609 geht näher auf die Syntax der verwendeten Dienst-URLs ein und RFC 2610 thematisiert DHCP über SLP.

http://www.openslp.org

Die Homepage des OpenSLP-Projekts.

/usr/share/doc/packages/openslp

Dieses Verzeichnis enthält die Dokumentation für SLP, die im Lieferumfang des openslp-server-Pakets enthalten ist, z. B. eine README.SUSE-Datei mit den SUSE Linux Enterprise Server-Details, die RFCs und zwei einführende HTML-Dokumente. Programmierer, die an den SLP-Funktionen interessiert sind, finden weitere Informationen im Programmierhandbuch, das im Paket openslp-devel im SUSE-SDK (Software Development Kit) enthalten ist.

34 Der HTTP-Server Apache

 

Gemäß der Umfrage von http://www.netcraft.com/ ist der HTTP-Server Apache (oder kurz „Apache“) weltweit der meistgenutzte Webserver. Der von der Apache Software Foundation (http://www.apache.org/) entwickelte Apache-Server läuft auf fast allen Betriebssystemen. SUSE® Linux Enterprise Server umfasst Apache, Version 2.4. In diesem Kapitel erfahren Sie, wie Apache installiert, konfiguriert und eingerichtet wird. Sie lernen SSL, CGI und weitere Module kennen und erfahren, wie Sie bei Problemen mit dem Webserver vorgehen.

34.1 Schnelleinführung

 

In diesem Abschnitt finden Sie Informationen zum schnellen Einrichten und Starten von Apache. Zur Installation und Konfiguration von Apache müssen Sie root-Benutzer sein.

34.1.1 Anforderungen

 

Vergewissern Sie sich, dass folgende Voraussetzungen erfüllt sind, bevor Sie den Apache-Webserver einrichten:

  1. Das Netzwerk des Computers ist ordnungsgemäß konfiguriert. Weitere Informationen zu diesem Thema finden Sie unter Kapitel 19, Grundlegendes zu Netzwerken.

  2. Durch Synchronisierung mit einem Zeitserver ist sichergestellt, dass die Systemzeit des Computers genau ist. Die exakte Uhrzeit ist für Teile des HTTP-Protokolls nötig. Weitere Informationen zu diesem Thema finden Sie unter Kapitel 30, Zeitsynchronisierung mit NTP.

  3. Die neuesten Sicherheitsaktualisierungen sind installiert. Falls Sie sich nicht sicher sind, führen Sie YaST-Online-Update aus.

  4. In der Firewall ist der Standardport des Webservers ( 80) geöffnet. Konfigurieren Sie hierzu firewalld so, dass der Dienst http in der öffentlichen Zone zugelassen wird. Ausführliche Informationen finden Sie unter Book “Security and Hardening Guide”, Chapter 23 “Masquerading and firewalls”, Section 23.4.3 “Configuring the firewall on the command line”.

34.1.2 Installation

 

Apache ist in der Standardinstallation von SUSE Linux Enterprise Server nicht enthalten. Zum Installieren von Apache mit einer vordefinierten Standardkonfiguration „“ gehen Sie wie folgt vor:

Vorgehen 34.1: Installation von Apache mit der Standardkonfiguration
 

  1. Starten Sie YaST, und wählen Sie Software › Software installieren oder löschen.

  2. Wählen Sie Ansicht › Schemata und schließlich Web- und LAMP-Server.

  3. Bestätigen Sie die Installation der abhängigen Pakete, um den Installationsvorgang abzuschließen.

34.1.3 Start

 

Sie können Apache automatisch beim Booten oder manuell starten.

Um sicherzustellen, dass Apache beim Booten des Computers in den Zielen multi-user.target und graphical.target automatisch gestartet wird, führen Sie das folgende Kommando aus: 

tux > sudo systemctl enable apache2

Weitere Informationen zu den systemd-Zielen in SUSE Linux Enterprise Server sowie eine Beschreibung zu YaST Services Manager finden Sie unter Abschnitt 15.4, „Verwalten von Diensten mit YaST“.

Über die Shell starten Sie Apache manuell mit dem Kommando systemctl start apache2.

Vorgehen 34.2: Überprüfen, ob Apache ausgeführt wird
 

Werden beim Starten von Apache keine Fehlermeldungen angezeigt, bedeutet dies im Normalfall, dass der Webserver ausgeführt wird. So überprüfen Sie, ob Apache ausgeführt wird:

  1. Starten Sie einen Webbrowser und öffnen Sie http://localhost/.

    Wenn Apache ausgeführt wird, wird eine Testseite mit der Meldung „It works!“ angezeigt.

  2. Wenn diese Seite nicht angezeigt wird, lesen Sie den Abschnitt Abschnitt 34.9, „Fehlerbehebung“.

Nachdem der Webserver nun läuft, können Sie eigene Dokumente hinzufügen, die Konfiguration an Ihre Anforderungen anpassen und weitere Module mit den benötigten Funktionen installieren.

34.2 Konfigurieren von Apache

 

SUSE Linux Enterprise Server bietet zwei Konfigurationsoptionen:

Bei der manuellen Konfiguration können Sie mehr Details einstellen, allerdings müssen Sie ohne den Komfort der Bedienoberfläche von YaST zurechtkommen.

Wichtig
Wichtig: Neuladen oder -starten von Apache nach Konfigurationsänderungen

Damit Konfigurationsänderungen wirksam werden, ist in den meisten Fällen ein erneutes Laden (in einigen Fällen auch ein Neustart) von Apache erforderlich. Laden Sie Apache manuell mit systemctl reload apache2 neu oder verwenden Sie eine der in Abschnitt 34.3, „Starten und Beenden von Apache“ beschriebenen Neustartoptionen.

Wenn Sie Apache mit YaST konfigurieren, kann dieser Schritt automatisch ausgeführt werden. Stellen Sie dazu HTTP-Service auf Aktiviert ein, wie in Abschnitt 34.2.3.2, „HTTP-Server-Konfiguration“ beschrieben.

34.2.1 ApacheKonfigurationsdateien

 

Dieser Abschnitt enthält eine Übersicht über die Apache-Konfigurationsdateien. Wenn Sie die Konfiguration mit YaST vornehmen, müssen Sie diese Dateien nicht bearbeiten. Die Informationen können jedoch nützlich sein, wenn Sie später auf die manuelle Konfiguration umstellen.

Die Konfigurationsdateien von Apache befinden sich in zwei verschiedenen Verzeichnissen:

34.2.1.1 /etc/sysconfig/apache2

 

/etc/sysconfig/apache2 steuert einige globale Einstellungen von Apache, beispielsweise die zu ladenden Module, die einzuschließenden Konfigurationsdateien, die beim Serverstart zu verwendenden Flags sowie Flags, die der Kommandozeile hinzugefügt werden sollen. Die Konfigurationsoptionen dieser Datei sind hinreichend dokumentiert und werden daher an dieser Stelle nicht näher erläutert. Für die Konfigurationsanforderungen eines typischen Webservers dürften die Einstellungen der Datei /etc/sysconfig/apache2 ausreichen.

34.2.1.2 /etc/apache2/

 

/etc/apache2/ enthält alle Konfigurationsdateien für Apache. In diesem Abschnitt wird der Zweck jeder einzelnen Datei erklärt. Jede Datei enthält mehrere Konfigurationsoptionen (auch Direktiven genannt). Die Konfigurationsoptionen dieser Dateien sind hinreichend dokumentiert und werden daher an dieser Stelle nicht näher erläutert.

Die Apache-Konfigurationsdateien gliedern sich wie folgt: 

/etc/apache2/
     |
     |- charset.conv
     |- conf.d/
     |   |
     |   |- *.conf
     |
     |- default-server.conf
     |- errors.conf
     |- httpd.conf
     |- listen.conf
     |- magic
     |- mime.types
     |- mod_*.conf
     |- server-tuning.conf
     |- ssl.*
     |- ssl-global.conf
     |- sysconfig.d
     |   |
     |   |- global.conf
     |   |- include.conf
     |   |- loadmodule.conf . .
     |
     |- uid.conf
     |- vhosts.d
     |   |- *.conf
Apache-Konfigurationsdateien in /etc/apache2/
 
charset.conv

In dieser Datei ist festgelegt, welche Zeichensätze für die verschiedenen Sprachen verwendet werden. Bearbeiten Sie diese Datei nicht.

conf.d/*.conf

Dies sind Konfigurationsdateien anderer Module. Bei Bedarf können die Konfigurationsdateien in Ihre virtuellen Hostkonfigurationen eingeschlossen werden. Beispiele finden Sie in vhosts.d/vhost.template. Sie können damit unterschiedliche Modulsätze für verschiedene virtuelle Hosts bereitstellen.

default-server.conf

Diese Datei enthält eine globale Konfiguration für virtuelle Hosts mit vernünftigen Standardeinstellungen. Statt die Werte in dieser Datei zu ändern, sollten Sie sie in der virtuellen Hostkonfiguration überschreiben.

errors.conf

Diese Datei legt fest, wie Apache auf Fehler reagiert. Wenn Sie die Meldungen für alle virtuellen Hosts ändern möchten, können Sie diese Datei bearbeiten. Anderenfalls sollten Sie die entsprechenden Direktiven in den virtuellen Hostkonfigurationen überschreiben.

httpd.conf

Dies ist die Hauptkonfigurationsdatei des Apache-Servers. Diese Datei sollten Sie nicht bearbeiten. Sie enthält in erster Linie Include-Anweisungen und globale Einstellungen. Globale Einstellungen können Sie in den entsprechenden in diesem Abschnitt aufgelisteten Konfigurationsdateien ändern. Host-spezifische Einstellungen wie DocumentRoot (absoluter Pfad) ändern Sie in der virtuellen Hostkonfiguration.

listen.conf

Diese Datei bindet Apache an bestimmte IP-Adressen und Ports. Außerdem konfiguriert diese Datei das namensbasierte virtuelle Hosting. Weitere Informationen finden Sie unter Abschnitt 34.2.2.1.1, „Namensbasierte virtuelle Hosts“.

magic

Diese Datei enthält Daten für das Modul mime_magic, mit dessen Hilfe Apache den MIME-Typ unbekannter Dateien ermittelt. Ändern Sie diese Datei nicht.

mime.types

Diese Datei enthält die dem System bekannten MIME-Typen (genau genommen ist diese Datei eine Verknüpfung mit /etc/mime.types). Bearbeiten Sie diese Datei nicht. MIME-Typen, die hier nicht aufgelistet sind, sollten Sie der Datei mod_mime-defaults.conf hinzufügen.

mod_*.conf

Dies sind die Konfigurationsdateien der in der Standardinstallation enthaltenen Module. Weitere Informationen finden Sie unter Abschnitt 34.4, „Installieren, Aktivieren und Konfigurieren von Modulen“. Die Konfigurationsdateien optionaler Module befinden sich im Verzeichnis conf.d.

server-tuning.conf

Diese Datei enthält Konfigurationsdirektiven für verschiedene MPMs (siehe Abschnitt 34.4.4, „Multiprocessing-Module“) und allgemeine Konfigurationsoptionen, die sich auf die Leistung von Apache auswirken. Sie können diese Datei bearbeiten, sollten den Webserver anschließend aber gründlich testen.

ssl-global.conf und ssl.*

Diese Dateien enthalten die globale SSL-Konfiguration und die SSL-Zertifikatdaten. Weitere Informationen finden Sie unter Abschnitt 34.6, „Einrichten eines sicheren Webservers mit SSL“.

sysconfig.d/*.conf

Diese Konfigurationsdateien werden automatisch aus /etc/sysconfig/apache2 generiert. Ändern Sie diese Dateien nicht. Bearbeiten Sie stattdessen die Dateien unter /etc/sysconfig/apache2. Speichern Sie in diesem Verzeichnis keine anderen Konfigurationsdateien.

uid.conf

Diese Datei gibt die Benutzer- und Gruppen-ID an, unter der Apache läuft. Ändern Sie diese Datei nicht.

vhosts.d/*.conf

In diesem Verzeichnis wird die virtuelle Host-Konfiguration gespeichert. Das Verzeichnis enthält Vorlagendateien für virtuelle Hosts mit und ohne SSL. Alle Dateien in diesem Verzeichnis mit der Erweiterung .conf sind automatisch Bestandteil der Apache-Konfiguration. Weitere Informationen finden Sie unter Abschnitt 34.2.2.1, „Virtuelle Hostkonfiguration“.

34.2.2 Manuelle Konfiguration von Apache

 

Wenn Sie den Apache-Webserver manuell konfigurieren möchten, müssen Sie die Klartext-Konfigurationsdateien als root-Benutzer bearbeiten.

34.2.2.1 Virtuelle Hostkonfiguration

 

Virtueller Host bezieht sich auf die Fähigkeit von Apache, mehrere URI (Universal Resource Identifiers) vom gleichen physischen Computer aus bedienen zu können. In anderen Worten: Mehrere Domänen wie www.beispiel.com und www.beispiel.net können von einem einzigen Webserver auf einem physischen Computer ausgeführt werden.

Virtuelle Hosts werden häufig eingesetzt, um Verwaltungsaufwand (nur ein Webserver muss verwaltet werden) und Hardware-Kosten (für die einzelnen Domänen ist kein dedizierter Server erforderlich) zu sparen. Virtuelle Hosts können auf Namen, IP-Adressen oder Ports basieren.

Verwenden Sie zum Auflisten aller vorhandenen virtuellen Hosts das Kommando apache2ctl -S. Dadurch wird eine Liste mit dem Standardserver und allen virtuellen Hosts zusammen mit deren IP-Adressen und überwachenden Ports ausgegeben. Zusätzlich enthält die Liste einen Eintrag für jeden virtuellen Host mit dessen Speicherort in den Konfigurationsdateien.

Virtuelle Hosts können mit YaST (siehe Abschnitt 34.2.3.1.4, „Virtuelle Hosts“) oder manuell durch Bearbeitung einer Konfigurationsdatei konfiguriert werden. In SUSE Linux Enterprise Server ist Apache unter /etc/apache2/vhosts.d/ standardmäßig für eine Konfigurationsdatei pro virtuellen Host vorbereitet. Alle Dateien in diesem Verzeichnis mit der Erweiterung .conf sind automatisch Bestandteil der Konfiguration. Außerdem enthält dieses Verzeichnis eine grundlegende Vorlage für virtuelle Hosts (vhost.template bzw. vhost-ssl.template für einen virtuellen Host mit SSL-Unterstützung).

Tipp
Tipp: Erstellen Sie immer eine virtuelle Hostkonfiguration.

Es empfiehlt sich, immer eine virtuelle Hostkonfiguration zu erstellen, selbst dann, wenn der Webserver nur eine Domäne enthält. Dadurch fassen Sie nicht nur die gesamte domänenspezifische Konfiguration in einer einzigen Datei zusammen, sondern Sie können auch jederzeit auf eine funktionierende Basiskonfiguration zurückgreifen, indem Sie einfach die Konfigurationsdatei des virtuellen Hosts verschieben, löschen oder umbenennen. Aus dem gleichen Grund sollten Sie auch für jeden virtuellen Host eine eigene Konfigurationsdatei erstellen.

Bei der Verwendung von namenbasierten virtuellen Hosts empfiehlt es sich, eine Standardkonfiguration einzurichten, die verwendet wird, wenn ein Domänenname nicht mit einer virtuellen Hostkonfiguration übereinstimmt. Der virtuelle Standardhost ist der Host, dessen Konfiguration zuerst geladen wird. Da die Reihenfolge der Konfigurationsdateien durch den Dateinamen bestimmt wird, starten Sie den Dateinamen der Konfiguration des virtuellen Standardhosts mit einem Unterstrich _, um sicherzustellen, dass sie zuerst geladen wird (z. B. _default_vhost.conf).

Der <VirtualHost></VirtualHost>-Block enthält die Informationen zu einer bestimmten Domäne. Wenn Apache eine Client-Anforderung für einen definierten virtuellen Host empfängt, verwendet es die in diesem Block angegebenen Direktiven. Nahezu alle Direktiven können auch im Kontext eines virtuellen Hosts verwendet werden. Weitere Informationen zu den Konfigurationsdirektiven von Apache finden Sie unter http://httpd.apache.org/docs/2.4/mod/quickreference.html.

34.2.2.1.1 Namensbasierte virtuelle Hosts
 

Namensbasierte virtuelle Hosts können an jeder IP-Adresse mehrere Websites bedienen. Apache verwendet das Hostfeld in dem vom Client übersandten HTTP-Header, um die Anforderung mit einem übereinstimmenden ServerName-Eintrag der virtuellen Hostdeklarationen zu verbinden. Wird kein übereinstimmender ServerName gefunden, dann wird der erste angegebene virtuelle Host als Standard verwendet.

Erstellen Sie zunächst je einen <VirtualHost>-Block für die einzelnen zu bedienenden namensbasierten Hosts. Jeder <VirtualHost>-Block muss mindestens eine ServerName-Direktive enthalten, mit der die zu bedienenden Hosts zugewiesen werden, sowie eine DocumentRoot-Direktive, aus der der Speicherort im Dateisystem hervorgeht, an dem sich der Inhalt für diesen Host befindet.

Beispiel 34.1: Einfache Beispiele für namensbasierte VirtualHost-Einträge
 
<VirtualHost *:80>
# This first-listed virtual host is also the default for *:80
ServerName www.example.com
ServerAlias example.com
DocumentRoot /srv/www/htdocs/domain
</VirtualHost>

<VirtualHost *:80>
ServerName other.example.com
DocumentRoot /srv/www/htdocs/otherdomain
</VirtualHost>

In einer namensbasierten virtuellen Hostkonfiguration übernimmt das VirtualHost-Anfangstag die IP-Adresse (bzw. den vollständig qualifizierten Domänennamen) als Argument. Eine Portnummer-Direktive ist optional.

Anstelle der IP-Adresse wird auch ein Platzhalterzeichen (*) akzeptiert. IPv6-Adressen müssen in eckige Klammern eingeschlossen werden.

Beispiel 34.2: Namensbasierte VirtualHost-Direktiven
 
<VirtualHost 192.168.3.100:80>
  ...
</VirtualHost>

<VirtualHost 192.168.3.100>
  ...
</VirtualHost>

<VirtualHost *:80>
  ...
</VirtualHost>

<VirtualHost *>
  ...
</VirtualHost>

<VirtualHost [2002:c0a8:364::]>
  ...
</VirtualHost>
34.2.2.1.2 IP-basierte virtuelle Hosts
 

Bei dieser alternativen virtuellen Hostkonfiguration werden auf einem Computer mehrere IP-Adressen eingerichtet. Auf einer Apache-Instanz befinden sich mehrere Domänen, denen jeweils eine eigene IP zugewiesen ist.

Auf dem physischen Server muss für jeden IP-basierten virtuellen Host eine eigene IP-Adresse eingerichtet sein. Falls der Computer nicht über die entsprechende Anzahl an Netzwerkkarten verfügt, können auch virtuelle Netzwerkschnittstellen verwendet werden (IP-Aliasing).

Das folgende Beispiel zeigt Apache auf einem Computer mit der IP 192.168.3.100 , auf dem sich zwei Domänen mit den zusätzlichen IP-Adressen 192.168.3.101 und 192.168.3.102 befinden. Für jeden virtuellen Server wird ein eigener VirtualHost-Block benötigt.

Beispiel 34.3: IP-basierte VirtualHost-Direktiven
 
<VirtualHost 192.168.3.101>
  ...
</VirtualHost>

<VirtualHost 192.168.3.102>
  ...
</VirtualHost>

In diesem Beispiel sind nur für die beiden zusätzlichen IP-Adressen (also nicht für 192.168.3.100) VirtualHost-Direktiven angegeben. Sollte für 192.168.3.100 auch eine Listen-Direktive konfiguriert sein, müsste ein eigener IP-basierter Host für die HTTP-Anforderungen an diese Schnittstelle eingerichtet werden. Anderenfalls fänden die Direktiven aus der Standardserverkonfiguration (/etc/apache2/default-server.conf) Anwendung.

34.2.2.1.3 Basiskonfiguration eines virtuellen Hosts
 

Die Konfiguration eines virtuellen Hosts sollte mindestens die folgenden Direktiven enthalten, um den virtuellen Host einzurichten. Weitere Optionen finden Sie in /etc/apache2/vhosts.d/vhost.template.

ServerName

Der vollständig qualifizierte Domänenname, unter dem der Host angesprochen wird.

DocumentRoot

Der absolute Pfad des Verzeichnisses, aus dem Apache die Dateien für diesen Host bedient. Aus Sicherheitsgründen ist standardmäßig auf das gesamte Dateisystem kein Zugriff möglich. Sie müssen dieses Verzeichnis daher explizit innerhalb eines Directory-Containers entsperren.

ServerAdmin

Email-Adresse des Serveradministrators. Diese Adresse ist beispielsweise auf den von Apache erstellten Fehlerseiten angegeben.

ErrorLog

Das Fehlerprotokoll dieses virtuellen Hosts. Ein eigenes Fehlerprotokoll für jeden virtuellen Host ist zwar nicht zwingend erforderlich, jedoch durchaus üblich, da dies die Fehlersuche erleichtert. /var/log/apache2/ ist das Standardverzeichnis für die Protokolldateien von Apache.

CustomLog

Das Zugriffsprotokoll dieses virtuellen Hosts. Ein eigenes Zugriffsprotokoll für jeden virtuellen Host ist zwar nicht zwingend erforderlich, jedoch durchaus üblich, da dies die separate Analyse der Zugriffsdaten für jeden einzelnen Host ermöglicht. /var/log/apache2/ ist das Standardverzeichnis für die Protokolldateien von Apache.

Wie bereits erwähnt, ist standardmäßig auf das gesamte Dateisystem kein Zugriff möglich. Die Verzeichnisse, in die Sie die Dateien gestellt haben, mit denen Apache arbeiten soll – zum Beispiel das Verzeichnis DocumentRoot –, müssen daher explizit entsperrt werden: 

<Directory "/srv/www/www.example.com/htdocs">
  Require all granted
</Directory>
Anmerkung
Anmerkung: Require all granted

In vorherigen Versionen von Apache wurde die Anweisung Require all granted wie folgt ausgedrückt: 

Order allow,deny
Allow from all

Diese alte Syntax wird vom mod_access_compat-Modul nach wie vor unterstützt.

Die vollständige Basiskonfiguration eines virtuellen Hosts sieht wie folgt aus:

Beispiel 34.4: Basiskonfiguration eines virtuellen Hosts
 
<VirtualHost 192.168.3.100>
  ServerName www.example.com
  DocumentRoot /srv/www/www.example.com/htdocs
  ServerAdmin webmaster@example.com
  ErrorLog /var/log/apache2/www.example.com_log
  CustomLog /var/log/apache2/www.example.com-access_log common
  <Directory "/srv/www/www.example.com/htdocs">
  Require all granted
  </Directory>
</VirtualHost>

34.2.3 Konfigurieren von Apache mit YaST

 

Zur Konfiguration des Webservers mit YaST starten Sie YaST, und wählen Sie Netzwerkdienste › HTTP-Server. Wenn Sie dieses Modul zum ersten Mal starten, wird der HTTP-Server-Assistent geöffnet und sie werden aufgefordert, einige grundlegende Entscheidungen zur Verwaltung des Servers zu treffen. Nach Fertigstellung des Assistenten wird das Dialogfeld HTTP-Server-Konfiguration geöffnet, sobald Sie das HTTP-Server-Modul aufrufen. Weitere Informationen finden Sie im Abschnitt 34.2.3.2, „HTTP-Server-Konfiguration“.

34.2.3.1 HTTP-Server-Assistent

 

Der HTTP-Server-Assistent besteht aus fünf Schritten. Im letzten Schritt des Assistenten können Sie den Expertenkonfigurationsmodus aufrufen, in dem Sie weitere spezielle Einstellungen vornehmen können.

34.2.3.1.1 Netzwerkgeräteauswahl
 

Geben Sie hier die Netzwerkschnittstellen und -ports an, die von Apache auf eingehende Anfragen überwacht werden. Sie können eine beliebige Kombination aus bestehenden Netzwerkschnittstellen und zugehörigen IP-Adressen auswählen. Sie können Ports aus allen drei Bereichen (Well-Known-Ports, registrierte Ports und dynamische oder private Ports) verwenden, sofern diese nicht für andere Dienste reserviert sind. Die Standardeinstellung ist die Überwachung aller Netzwerkschnittstellen (IP-Adressen) an Port 80.

Aktivieren Sie Firewall-Port öffnen, um die vom Webserver überwachten Ports in der Firewall zu öffnen. Dies ist erforderlich, um den Webserver im Netzwerk (LAN, WAN oder Internet) verfügbar zu machen. Das Schließen des Ports ist nur in Testsituationen sinnvoll, in denen kein externer Zugriff auf den Webserver erforderlich ist. Wenn Sie über mehrere Netzwerkschnittstellen verfügen, klicken Sie auf Firewall-Details, um festzulegen, an welchen Schnittstellen die Ports geöffnet werden sollen.

Klicken Sie auf Weiter, um mit der Konfiguration fortzufahren.

34.2.3.1.2 Module
 

Mit der Konfigurationsoption Module aktivieren bzw. deaktivieren Sie die vom Webserver unterstützten Skriptsprachen. Informationen zur Aktivierung bzw. Deaktivierung anderer Module erhalten Sie unter Abschnitt 34.2.3.2.2, „Servermodule“. Klicken Sie auf Weiter, um das nächste Dialogfeld zu öffnen.

34.2.3.1.3 Standardhost
 

Diese Option betrifft den Standard-Webserver. Wie in Abschnitt 34.2.2.1, „Virtuelle Hostkonfiguration“ beschrieben, kann Apache von einem einzigen Computer mehrere virtuelle Hosts bedienen. Der erste in der Konfigurationsdatei deklarierte virtuelle Host wird im Allgemeinen als Standardhost bezeichnet. Alle nachfolgenden virtuellen Hosts übernehmen die Konfiguration des Standardhosts.

Wenn Sie die Hosteinstellungen (auch als Direktiven bezeichnet) bearbeiten möchten, wählen Sie den entsprechenden Eintrag in der Tabelle aus, und klicken Sie auf Bearbeiten. Zum Hinzufügen neuer Direktiven klicken Sie auf Hinzufügen. Zum Löschen einer Direktive wählen Sie die Direktive aus und klicken Sie auf Löschen.

HTTP-Server-Assistent: Standardhost
Abbildung 34.1: HTTP-Server-Assistent: Standardhost
 

Für den Server gelten folgende Standardeinstellungen:

Document-Root

Der absolute Pfad des Verzeichnisses, aus dem Apache die Dateien für diesen Host bedient. Dies ist standardmäßig /srv/www/htdocs.

Alias

Mit Alias-Direktiven können URLs zu Speicherorten in physischen Dateisystemen zugeordnet werden. Dies bedeutet, dass über eine URL sogar auf Pfade im Dateisystem außerhalb des Document Root zugegriffen werden kann, sofern die URL via Aliasing auf diesen Pfad verweist.

Der vorgegebene SUSE Linux Enterprise Server- Alias /icons für die in der Verzeichnisindex-Ansicht angezeigten Apache-Symbole verweist auf /usr/share/apache2/icons.

ScriptAlias

Ähnlich wie die Alias-Direktive ordnet die ScriptAlias-Direktive eine URL einem Speicherort im Dateisystem zu. Der Unterschied besteht darin, dass ScriptAlias als Zielverzeichnis einen CGI-Speicherort für die Ausführung von CGI-Skripten festlegt.

Verzeichnis

Unter den Verzeichnis-Einstellungen können Sie eine Gruppe von Konfigurationsoptionen zusammenfassen, die nur für das angegebene Verzeichnis gelten.

Hier werden auch die Zugriffs- und Anzeigeoptionen für die Verzeichnisse /srv/www/htdocs, /usr/share/apache2/icons und /srv/www/cgi-bin konfiguriert. Eine Änderung dieser Standardeinstellungen sollte nicht erforderlich sein.

Einbeziehen

Hier können weitere Konfigurationsdateien hinzugefügt werden. Zwei Include-Direktiven sind bereits vorkonfiguriert: /etc/apache2/conf.d/ ist das Verzeichnis für die Konfigurationsdateien externer Module. Durch diese Direktive werden alle Dateien in diesem Verzeichnis mit der Erweiterung .conf eingeschlossen. Durch die zweite Direktive, /etc/apache2/conf.d/apache2-manual.conf, wird die Konfigurationsdatei apache2-manual eingeschlossen.

Servername

Hier wird die Standard-URL festgelegt, über die Clients den Webserver kontaktieren. Verwenden Sie einen qualifizierten Domänennamen (FQDN), um den Webserver unter http://FQDN/ zu erreichen. Alternativ können Sie auch die IP-Adresse verwenden. Geben Sie hier keinen willkürlichen Namen ein – der Server muss unter diesem Namen „bekannt“ sein.

Email des Serveradministrators

Email-Adresse des Serveradministrators. Diese Adresse ist beispielsweise auf den von Apache erstellten Fehlerseiten angegeben.

Klicken Sie am Ende der Seite Standardhost auf Weiter, um mit der Konfiguration fortzufahren.

34.2.3.1.4 Virtuelle Hosts
 

In diesem Schritt zeigt der Assistent eine Liste der bereits konfigurierten virtuellen Hosts an (siehe Abschnitt 34.2.2.1, „Virtuelle Hostkonfiguration“). Wenn Sie vor dem Starten des YaST-HTTP-Assistenten keine manuellen Änderungen vorgenommen haben, ist kein virtueller Host vorhanden.

Zum Hinzufügen eines Hosts klicken Sie auf Hinzufügen, um ein Dialogfeld zu öffnen, in das Sie grundlegende Informationen über den Host eingeben, z. B. Servername, Übergeordnetes Verzeichnis der Server-Inhalte (DocumentRoot) und Administrator-Email. Unter Server-Auflösung legen Sie fest, wie der Host identifiziert wird (nach seinem Namen oder nach seiner IP-Adresse). Geben Sie den Namen oder die IP-Adresse unter Change Virtual Host ID (Virtuelle Host-ID ändern) an.

Klicken Sie auf Weiter, um mit dem zweiten Teil der virtuellen Hostkonfiguration fortzufahren.

Im zweiten Teil der virtuellen Hostkonfiguration legen Sie fest, ob CGI-Skripten zugelassen sind und welches Verzeichnis für diese Skripten verwendet wird. Dort können Sie auch SSL aktivieren. Wenn Sie SSL aktivieren, müssen Sie auch den Zertifikatpfad angeben. Informationen über SSL und Zertifikate finden Sie in Abschnitt 34.6.2, „Konfigurieren von Apache mit SSL“. Mit der Option Verzeichnisindex geben Sie an, welche Datei angezeigt wird, wenn der Client ein Verzeichnis anfordert (standardmäßig ist dies die Datei index.html). Statt der Standardeinstellung können Sie aber auch ein oder mehrere andere Dateinamen (jeweils getrennt durch ein Leerzeichen) angeben. Mit Public HTML aktivieren stellen Sie den Inhalt der öffentlichen Benutzerverzeichnisse (~USER/public_html/) auf dem Server unter http://www.example.com/~USER bereit.

Wichtig
Wichtig: Erstellen virtueller Hosts

Virtuelle Hosts können Sie nicht völlig willkürlich hinzufügen. Wenn Sie namensbasierte virtuelle Hosts hinzufügen möchten, müssen die Hostnamen im Netzwerk aufgelöst sein. Bei IP-basierten virtuellen Hosts darf jeder verfügbaren IP-Adresse nur ein Host zugewiesen sein.

34.2.3.1.5 Zusammenfassung
 

Dies ist der abschließende Schritt des Assistenten. Legen Sie hier fest, wie und wann der Apache-Server gestartet werden soll: beim Boot-Vorgang oder manuell. Außerdem erhalten Sie in diesem Schritt eine kurze Zusammenfassung Ihrer bisherigen Konfiguration. Wenn Sie mit den Einstellungen zufrieden sind, schließen Sie die Konfiguration mit Verlassen ab. Zum Ändern bestimmter Einstellungen klicken Sie so oft auf Zurück , bis das entsprechende Dialogfeld angezeigt wird. Über Expertenkonfiguration für HTTP-Server können Sie hier auch das in Abschnitt 34.2.3.2, „HTTP-Server-Konfiguration“ beschriebene Dialogfeld öffnen.

HTTP-Server-Assistent: Zusammenfassung
Abbildung 34.2: HTTP-Server-Assistent: Zusammenfassung
 

34.2.3.2 HTTP-Server-Konfiguration

 

Im Dialogfeld HTTP-Server-Konfiguration können Sie weitaus mehr Einstellungen vornehmen als im Assistenten (dieser wird ohnehin nur bei der Anfangskonfiguration des Webservers ausgeführt). Das Dialogfeld enthält vier Registerkarten, die nachfolgend beschrieben werden. Keine der in diesem Dialogfeld vorgenommenen Konfigurationsänderungen wird sofort wirksam. Dies geschieht erst, wenn Sie das Dialogfeld mit Beenden schließen. Klicken Sie hingegen auf Abbrechen, so verlassen Sie das Konfigurationsmodul und Ihre Konfigurationsänderungen werden verworfen.

34.2.3.2.1 Überwachen von Ports und Adressen
 

Geben Sie unter HTTP-Dienst an, ob Apache laufen soll (Aktiviert) oder beendet werden soll (Deaktiviert). Mit den Schaltflächen Hinzufügen, Bearbeiten und Löschen geben Sie unter Ports überwachen die Adressen und Ports an, die vom Server überwacht werden sollen. Standardmäßig werden alle Schnittstellen an Port 80 überwacht. Die Option Firewall-Port öffnen sollte immer aktiviert sein, weil ansonsten der Webserver von außen nicht erreichbar ist. Das Schließen des Ports ist nur in Testsituationen sinnvoll, in denen kein externer Zugriff auf den Webserver erforderlich ist. Wenn Sie über mehrere Netzwerkschnittstellen verfügen, klicken Sie auf Firewall-Details, um festzulegen, an welchen Schnittstellen die Ports geöffnet werden sollen.

Über die Schaltfläche Protokolldateien können Sie die Zugriffs- oder die Fehlerprotokolldatei überwachen. Diese Funktion ist besonders beim Testen der Konfiguration hilfreich. Die Protokolldatei wird in einem eigenen Fenster geöffnet, aus dem Sie den Webserver auch neu starten oder neu laden können. Weitere Informationen finden Sie unter Abschnitt 34.3, „Starten und Beenden von Apache“. Diese Kommandos sind sofort wirksam und ihre Protokollmeldungen werden auch sofort angezeigt.

Konfiguration des HTTP-Servers: Überwachen von Ports und Adressen
Abbildung 34.3: Konfiguration des HTTP-Servers: Überwachen von Ports und Adressen
 
34.2.3.2.2 Servermodule
 

Über Status wechseln können Sie Apache2-Module aktivieren und deaktivieren. Über Modul hinzufügen können Sie weitere Module hinzufügen, die zwar bereits installiert, aber noch nicht in dieser Liste aufgeführt sind. Weitere Informationen über Module finden Sie in Abschnitt 34.4, „Installieren, Aktivieren und Konfigurieren von Modulen“.

Konfiguration des HTTP-Servers: Server-Module
Abbildung 34.4: Konfiguration des HTTP-Servers: Server-Module
 
34.2.3.2.3 Haupthost oder Hosts
 

Diese Dialogfelder sind mit den bereits beschriebenen identisch. in Abschnitt 34.2.3.1.3, „Standardhost“ und Abschnitt 34.2.3.1.4, „Virtuelle Hosts“ beschriebenen Dialogfeldern.

34.3 Starten und Beenden von Apache

 

Bei Konfiguration mit YaST, wie in Abschnitt 34.2.3, „Konfigurieren von Apache mit YaST“ beschrieben, wird Apache beim Booten des Computers in multi-user.target und graphical.target gestartet. Diese Funktionsweise können Sie mit YaST Services Manager oder dem Kommandozeilenwerkzeug systemctl (systemctl enable oder systemctl disable) ändern.

Mit den Kommandos systemctl bzw. apachectl können Sie Apache auf einem laufenden System starten, stoppen und ändern.

Allgemeine Informationen zu systemctl-Kommandos finden Sie unter Abschnitt 15.2.1, „Verwalten von Diensten auf einem laufenden System“.

systemctl status apache2

Überprüft, ob Apache gestartet wurde.

systemctl start apache2

Startet Apache, sofern es noch nicht läuft.

systemctl stop apache2

Stoppt Apache durch Beenden des übergeordneten Prozesses.

systemctl restart apache2

Beendet Apache und startet es danach neu. Falls der Webserver noch nicht gelaufen ist, wird er nun gestartet.

systemctl try-restart apache2

Stoppt Apache und startet es erneut, vorausgesetzt, es wird bereits ausgeführt.

systemctl reload apache2

Beendet den Webserver erst, nachdem alle durch Forking erstellten Apache-Prozesse aufgefordert wurden, ihre Anforderungen vor dem Herunterfahren zu Ende zu führen. Anstelle der beendeten Prozesse werden neue Prozesse gestartet. Dies führt zu einem vollständigen „Neustart“ von Apache.

Tipp
Tipp: Neustart von Apache in Produktionsumgebungen

Mit diesem Kommando können Änderungen in der Apache-Konfiguration aktiviert werden, ohne dass die Verbindung unterbrochen wird.

systemctl stop apache2

Hält den Webserver nach einer Zeitdauer an, die mit GracefulShutdownTimeout konfiguriert wurde, um sicherzustellen, dass die bestehenden Anforderungen abgeschlossen werden können.

apachectl configtest

Überprüft die Syntax der Konfigurationsdateien, ohne den laufenden Webserver zu beeinträchtigen. Da dieser Test beim Starten, Neuladen oder Neustarten des Servers automatisch durchgeführt wird, ist eine explizite Ausführung des Tests in der Regel nicht notwendig. Bei einem Konfigurationsfehler wird der Webserver ohnehin nicht gestartet, neu geladen oder neu gestartet.

apachectl status und apachectl fullstatus

Erstellt einen Dump des kurzen oder vollständigen Statusfensters. Das Module mod_status muss aktiviert und ein Textbrowser (z. B. links oder w3m) muss installiert sein. Außerdem muss /etc/sysconfig/apache2 unter APACHE_SERVER_FLAGS das Flag STATUS enthalten.

Tipp
Tipp: Weitere Flags

Weitere Flags, die Sie mit den Kommandos angeben, werden direkt an den Webserver weitergeleitet.

34.4 Installieren, Aktivieren und Konfigurieren von Modulen

 

Die Apache-Software ist modular aufgebaut. Alle Funktionen außer einigen Kernaufgaben werden von Modulen durchgeführt Dies geht sogar so weit, dass selbst HTTP durch ein Modul verarbeitet wird (http_core).

Apache-Module können bei der Entwicklung in die Apache-Binaries kompiliert oder während der Laufzeit dynamisch geladen werden. Informationen zum dynamischen Laden von Modulen erhalten Sie unter Abschnitt 34.4.2, „Aktivieren und Deaktivieren von Modulen“.

Apache-Module lassen sich in vier Kategorien einteilen:

Basismodule

Basismodule sind standardmäßig in Apache enthalten. In Apache in SUSE Linux Enterprise Server sind nur mod_so (zum Laden anderer Module) und http_core kompiliert. Alle anderen Module sind als gemeinsam genutzte Objekte verfügbar: Sie sind nicht in der Server-Binärdatei enthalten, sondern können zur Laufzeit eingebunden werden.

Erweiterungsmodule

Im Allgemeinen sind Erweiterungsmodule im Apache-Softwarepaket enthalten, jedoch nicht statisch im Server kompiliert. In SUSE Linux Enterprise Server stehen diese Module als gemeinsame Objekte zur Verfügung, die während der Laufzeit in Apache geladen werden können.

Externe Module

Externe Module sind nicht in der offiziellen Apache-Distribution enthalten. SUSE Linux Enterprise Server umfasst jedoch mehrere Module.

Multiprocessing-Module (MPMs)

Multiprocessing-Module (MPMs) sind dafür verantwortlich, Anforderungen an den Webserver anzunehmen und zu verarbeiten, und stellen damit das Kernstück der Webserver-Software dar.

34.4.1 Installieren von Modulen

 

Wenn Sie die in Abschnitt 34.1.2, „Installation“ beschriebene Standardinstallation vorgenommen haben, sind folgende Module bereits installiert: alle Basis- und Erweiterungsmodule, das Multiprocessing-Modul Prefork MPM sowie das externe Modul mod_python.

In YaST können Sie weitere externe Module installieren. Starten Sie dazu YaST und wählen Sie Software › Software-Management. Wählen Sie danach Ansicht › Suche und suchen Sie nach apache. Die Ergebnisliste zeigt nun neben anderen Paketen alle verfügbaren externen Apache-Module an.

34.4.2 Aktivieren und Deaktivieren von Modulen

 

Sie können bestimmte Module entweder manuell oder mit YaST aktivieren oder deaktivieren. In YaST müssen die Skriptsprachmodule (PHP 5 und Python) mit der im Abschnitt Abschnitt 34.2.3.1, „HTTP-Server-Assistent“ beschriebenen Modulkonfiguration aktiviert oder deaktiviert werden. Alle anderen Module werden, wie im Abschnitt Abschnitt 34.2.3.2.2, „Servermodule“ beschrieben, aktiviert oder deaktiviert.

Mit den Kommandos a2enmod MODUL bzw. a2dismod MODUL können Sie die Module stattdessen manuell aktivieren oder deaktivieren. a2enmod -l gibt eine Liste aller derzeit aktiven Module aus.

Wichtig
Wichtig: Einschließen der Konfigurationsdateien externer Module

Wenn Sie externe Module manuell aktivieren, müssen Sie sicherstellen, dass auch ihre Konfigurationsdateien in allen virtuellen Hostkonfigurationen geladen werden. Die Konfigurationsdateien externer Module befinden sich unter /etc/apache2/conf.d/ und werden standardmäßig in /etc/apache2/default-server.conf geladen. Für eine feinere Steuerung können Sie die Einbeziehung in /etc/apache2/default-server.conf auskommentieren und sie nur zu bestimmten virtuellen Hosts hinzufügen. Beispiele hierzu finden Sie in der Datei /etc/apache2/vhosts.d/vhost.template.

34.4.3 Basis- und Erweiterungsmodule

 

Alle Basis- und Erweiterungsmodule werden ausführlich in der Apache-Dokumentation beschrieben. An dieser Stelle gehen wir daher nur kurz auf die wichtigsten Module ein. Informationen zu den einzelnen Modulen erhalten Sie auch unter http://httpd.apache.org/docs/2.4/mod/.

mod_actions

Bietet Methoden zur Ausführung eines Skripts, wenn ein bestimmter MIME-Typ (z. B. application/pdf), eine Datei mit einer bestimmten Erweiterung (z. B. .rpm) oder eine bestimmte Anforderungsmethode (z. B. GET) verlangt wird. Dieses Modul ist standardmäßig aktiviert.

mod_alias

Dieses Modul stellt die Direktiven Alias und Redirect bereit. Damit können Sie eine URI einem bestimmten Verzeichnis zuordnen (Alias) bzw. eine angeforderte URL umleiten. Dieses Modul ist standardmäßig aktiviert.

mod_auth*

Die Authentifizierungsmodule bieten verschiedene Methoden zur Authentifizierung: Basisauthentifizierung mit mod_auth_basic oder Digest-Authentifizierung mit mod_auth_digest.

mod_auth_basic und mod_auth_digest funktionieren nur gemeinsam mit dem Authentifizierungsanbietermodul mod_authn_* (z. B. mod_authn_file für die Authentifizierung auf Basis einer Textdatei) und mit dem Autorisierungsmodul mod_authz_* (z. B. mod_authz_user für die Benutzerautorisierung).

Weitere Informationen zu diesem Thema erhalten Sie im Artikel Gewusst wie: Authentifizierung unter http://httpd.apache.org/docs/2.4/howto/auth.html.

mod_auth_openidc

mod_auth_openidc ist die einzige zertifizierte Methode zur Verwendung von OpenID Connect mit dem Apache HTTP-Server. (Siehe https://openid.net/developers/certified/.)

mod_autoindex

Wenn keine Indexdatei vorhanden ist (z. B. index.html), generiert mod_autoindex Verzeichnislisten. Das Aussehen dieser Indizes kann konfiguriert werden. Dieses Modul ist standardmäßig aktiviert. Allerdings sind Verzeichnislisten durch die Options-Direktive standardmäßig deaktiviert – Sie müssen diese Einstellung daher in Ihrer virtuellen Hostkonfiguration ändern. Die Standardkonfigurationsdatei dieses Moduls befindet sich unter /etc/apache2/ und heißt mod_autoindex-defaults.conf.

mod_cgi

mod_cgi wird zur Ausführung von CGI-Skripten benötigt. Dieses Modul ist standardmäßig aktiviert.

mod_deflate

Mit diesem Modul kann Apache so konfiguriert werden, dass bestimmte Dateitypen automatisch vor der Bereitstellung komprimiert werden.

mod_dir

mod_dir stellt die DirectoryIndex-Direktive bereit, mit der Sie festlegen können, welche Dateien bei Anforderung eines Verzeichnisses automatisch zurückgegeben werden (standardmäßig index.html). Außerdem leitet dieses Modul automatisch zur korrekten URI um, wenn in einer Verzeichnisanforderung der nachgestellte Schrägstrich fehlt. Dieses Modul ist standardmäßig aktiviert.

mod_env

Steuert die Umgebungsvariablen, die an CGI-Skripten oder SSI-Seiten übergeben werden. Sie können Umgebungsvariablen festlegen oder aufheben oder von der Shell übergeben, die den httpd-Prozess aufgerufen hat. Dieses Modul ist standardmäßig aktiviert.

mod_expires

Mit mod_expires legen Sie fest, wie häufig Ihre Dokumente über Proxy- und Browser-Caches durch Zustellung eines Expires-Header aktualisiert werden. Dieses Modul ist standardmäßig aktiviert.

mod_http2

Dank mod_http2 unterstützt Apache das HTTP/2-Protokoll. Dies kann durch Angabe von Protocols h2 http/1.1 in einem VirtualHost aktiviert werden.

mod_include

mod_include ermöglicht die Verwendung von serverseitigen Includes (SSI), die die grundlegende Funktionalität für die dynamische Generierung von HTML-Seiten bereitstellen. Dieses Modul ist standardmäßig aktiviert.

mod_info

Dieses Modul stellt unter http://localhost/server-info/ eine umfassende Übersicht über die Serverkonfiguration bereit. Aus Sicherheitsgründen sollte der Zugriff auf diese URL generell eingeschränkt sein. Standardmäßig erhält nur localhost den Zugriff auf diese URL. mod_info wird unter /etc/apache2/mod_info.conf konfiguriert.

mod_log_config

Mit diesem Modul konfigurieren Sie den Aufbau der Apache-Protokolldateien. Dieses Modul ist standardmäßig aktiviert.

mod_mime

Das MIME-Modul sorgt dafür, dass eine Datei auf Basis seiner Dateinamenerweiterung mit dem korrekten MIME-Header bereitgestellt wird (z. B. text/html für HTML-Dokumente). Dieses Modul ist standardmäßig aktiviert.

mod_negotiation

Dieses Modul ist für die Inhaltsverhandlung erforderlich. Weitere Informationen erhalten Sie unter http://httpd.apache.org/docs/2.4/content-negotiation.html. Dieses Modul ist standardmäßig aktiviert.

mod_rewrite

Dieses Modul stellt die gleiche Funktionalität wie mod_alias bereit, bietet aber mehr Funktionen und ist somit flexibler. Mit mod_rewrite können Sie URLs auf Basis verschiedener Regeln umleiten, Header anfordern und einiges mehr.

mod_setenvif

Legt Umgebungsvariablen auf der Basis von Details aus der Client-Anforderung fest, z. B. die Browserzeichenfolge, die der Client sendet, oder die IP-Adresse des Clients. Dieses Modul ist standardmäßig aktiviert.

mod_spelling

mod_speling versucht, typografische Fehler in URLs, beispielsweise die Groß-/Kleinschreibung, automatisch zu korrigieren.

mod_ssl

Dieses Modul ermöglicht verschlüsselte Verbindungen zwischen dem Webserver und den Clients. Ausführliche Informationen finden Sie unter Abschnitt 34.6, „Einrichten eines sicheren Webservers mit SSL“. Dieses Modul ist standardmäßig aktiviert.

mod_status

Dieses Modul stellt unter http://localhost/server-status/ Informationen über die Aktivität und Leistung des Servers bereit. Aus Sicherheitsgründen sollte der Zugriff auf diese URL generell eingeschränkt sein. Standardmäßig erhält nur localhost den Zugriff auf diese URL. mod_info wird unter /etc/apache2/mod_info.conf konfiguriert.

mod_suexec

mod_suexec ermöglicht die Ausführung von CGI-Skripten unter einem anderen Benutzer oder einer anderen Gruppe. Dieses Modul ist standardmäßig aktiviert.

mod_userdir

Dieses Modul ermöglicht benutzerspezifische Verzeichnisse unter ~USER/. In der Konfiguration muss die UserDir-Direktive angegeben sein. Dieses Modul ist standardmäßig aktiviert.

34.4.4 Multiprocessing-Module

 

SUSE Linux Enterprise Server bietet zwei Multiprocessing-Module (MPMs) für Apache:

34.4.4.1 Prefork-MPM

 

Das Prefork-MPM implementiert einen Prefork-Webserver, der keine Threads verwendet. Mit diesem Modul verhält sich der Webserver, was die Handhabung von Anforderungen betrifft, ähnlich wie Apache Version 1.x: Er isoliert jede einzelne Anforderung und verarbeitet sie in einem separaten untergeordneten Prozess (Forking). Eine Beeinträchtigung aller Anforderungen durch wenige problematische Anforderungen und somit eine Sperre des Webservers lassen sich dadurch vermeiden.

Die prozessbasierte Vorgehensweise des Prefork-MPM bietet zwar Stabilität, konsumiert aber mehr Systemressourcen wie das Worker-MPM. Für UNIX-basierte Betriebssysteme gilt das Prefork-MPM als Standard-MPM.

Wichtig
Wichtig: MPMs in diesem Dokument

In diesem Dokument wird davon ausgegangen, dass Apache mit dem Prefork-MPM verwendet wird.

34.4.4.2 Worker-MPM

 

Das Worker-MPM implementiert einen Multithread-Webserver. Ein Thread ist die „Lightweight-Version“ eines Prozesses. Der Vorteil von Threads gegenüber Prozessen ist deren geringerer Ressourcenkonsum. Anstatt lediglich untergeordnete Prozesse zu erstellen (Forking), verarbeitet das Worker-MPM Anforderungen durch Threads mit Serverprozessen. Die untergeordneten Prefork-Prozesse sind auf mehrere Threads verteilt (Multithreading). Diese Ansatzweise macht den Apache-Server durch den geringeren Ressourcenkonsum leistungsfähiger als mit dem Prefork-MPM.

Ein Hauptnachteil ist die Instabilität des Worker-MPM: Ein fehlerhafter Thread kann sich auf alle Threads eines Prozesses auswirken. Im schlimmsten Fall fällt der Server dadurch aus. Besonders bei gleichzeitiger Verwendung des Common Gateway Interface (CGI) auf einem überlasteten Apache-Server kann es zu internen Serverfehlern kommen, da Threads in diesem Fall unter Umständen nicht in der Lage sind, mit den Systemressourcen zu kommunizieren. Gegen die Verwendung des Worker-MPM in Apache spricht auch die Tatsache, dass nicht alle verfügbaren Apache-Module Thread-sicher sind und daher nicht mit dem Worker-MPM eingesetzt werden können.

Warnung
Warnung: Verwendung von PHP-Modulen mit MPMs

Nicht alle verfügbaren PHP-Module sind Thread-sicher. Von einer Verwendung des Worker-MPM in Verbindung mit mod_php wird daher abgeraten.

34.4.5 Externe Module

 

Nachfolgend finden Sie eine Liste aller externen Module, die mit SUSE Linux Enterprise Server ausgeliefert werden. Die Dokumentation zu den einzelnen Modulen finden Sie in den jeweils genannten Verzeichnissen.

mod_apparmor

Unterstützt Apache bei der AppArmor-Einschränkung auf einzelne cgi-Skripte, die von Modulen wie mod_php5 benutzt werden.

Paketname: apache2-mod_apparmor
Weitere Informationen: Book “Security and Hardening Guide”
mod_php5

PHP ist eine serverseitige, plattformübergreifende, in HTML eingebettete Skriptsprache.

Paketname: apache2-mod_php5
Konfigurationsdatei: /etc/apache2/conf.d/php5.conf
Weitere Informationen: /usr/share/doc/packages/apache2-mod_php5
mod_python

mod_python bettet Python in den Apache-Webserver ein. Dies bringt Ihnen einen erheblichen Leistungsgewinn und zusätzliche Flexibilität bei der Entwicklung webbasierter Anwendungen.

Paketname: apache2-mod_python
Weitere Informationen: /usr/share/doc/packages/apache2-mod_python
mod_security

mod_security bietet eine Firewall zum Schutz von Webanwendungen vor verschiedenen Angriffen. Auch die Überwachung des HTTP-Datenverkehrs und die Echtzeitanalyse werden damit ermöglicht.

Paketname: apache2-mod_security2
Konfigurationsdatei: /etc/apache2/conf.d/mod_security2.conf
Weitere Informationen: /usr/share/doc/packages/apache2-mod_security2
Dokumentation: http://modsecurity.org/documentation/

34.4.6 Kompilieren von Modulen

 

Apache kann von erfahrenen Benutzern durch selbst entwickelte Module erweitert werden. Zum Entwickeln von Modulen für Apache oder zum Kompilieren von Drittanbietermodulen ist das Paket apache2-devel zusammen mit den entsprechenden Entwicklerwerkzeugen erforderlich. apache2-devel enthält außerdem die apxs2-Werkzeuge, die zum Kompilieren zusätzlicher Module für Apache erforderlich sind.

apxs2 ermöglicht die Kompilierung und Installation von Modulen aus dem Quellcode (einschließlich der erforderlichen Änderungen an den Konfigurationsdateien). Dadurch ergeben sich Dynamic Shared Objects (DSOs), die während der Laufzeit in Apache geladen werden können.

Die Binaries von apxs2 befinden sich unter /usr/sbin:

  • /usr/sbin/apxs2: Für die Entwicklung von Erweiterungsmodulen, die mit allen MPMs verwendbar sind. Das Installationsverzeichnis ist /usr/lib64/apache2.

  • /usr/sbin/apxs2-prefork: Für die Entwicklung von Prefork-MPM-Modulen. Das Installationsverzeichnis ist /usr/lib64/apache2-prefork.

  • /usr/sbin/apxs2-worker: Für die Entwicklung von Worker-MPM-Modulen. Das Installationsverzeichnis ist /usr/lib64/apache2-worker.

Mit den folgenden Kommandos installieren und aktivieren Sie ein Modul aus dem Quellcode: 

tux > sudo cd /path/to/module/source
tux > sudo apxs2 -cia MODULE.c

wobei das Modul mit -c kompiliert, mit -i installiert und mit -a aktiviert wird. Alle weiteren Optionen von apxs2 werden auf der man-Seite apxs2(1) beschrieben.

34.5 Aktivieren von CGI-Skripten

 

Die Common Gateway Interface (CGI) von Apache ermöglicht die Erstellung dynamischer Inhalte mit Programmen bzw. sogenannten CGI-Skripten. CGI-Skripten können in jeder beliebigen Programmiersprache geschrieben sein. In der Regel werden aber Skriptsprachen wie PHP verwendet.

Damit Apache in der Lage ist, die von CGI-Skripts erstellten Inhalte bereitzustellen, muss das Modul mod_cgi aktiviert sein. Außerdem ist mod_alias erforderlich. Beide Module sind standardmäßig aktiviert. Informationen zur Aktivierung von Modulen finden Sie unter Abschnitt 34.4.2, „Aktivieren und Deaktivieren von Modulen“.

Warnung
Warnung: CGI-Sicherheit

Die Zulassung der CGI-Skriptausführung auf dem Server ist ein Sicherheitsrisiko. Weitere Informationen finden Sie in Abschnitt 34.8, „Vermeiden von Sicherheitsproblemen“.

34.5.1 Konfiguration in Apache

 

In SUSE Linux Enterprise Server ist die Ausführung von CGI-Skripts nur im Verzeichnis /srv/www/cgi-bin/ erlaubt. Dieses Verzeichnis ist bereits für die Ausführung von CGI-Skripten konfiguriert. Wenn Sie eine virtuelle Hostkonfiguration erstellt haben (siehe Abschnitt 34.2.2.1, „Virtuelle Hostkonfiguration“) und Ihre CGI-Skripten in einem Host-spezifischen Verzeichnis ablegen möchten, müssen Sie das betreffende Verzeichnis entsperren und für CGI-Skripten konfigurieren.

Beispiel 34.5: CGI-Konfiguration für virtuelle Hosts
 
ScriptAlias /cgi-bin/ "/srv/www/www.example.com/cgi-bin/"1

<Directory "/srv/www/www.example.com/cgi-bin/">
 Options +ExecCGI2
 AddHandler cgi-script .cgi .pl3
 Require all granted4
</Directory>

1

Fordert Apache auf, alle Dateien in diesem Verzeichnis als CGI-Skripten zu behandeln

2

Aktiviert die Ausführung von CGI-Skripten

3

Fordert den Server auf, Dateien mit den Erweiterungen .pl und .cgi als CGI-Skripten zu behandeln. passen Sie diese Anweisung entsprechend Ihren Anforderungen an

4

Die Require-(Anfordern-)Direktive bestimmt den standardmäßigen Zugriffsstatus. In diesem Fall wird der uneingeschränkte Zugriff auf das angegebenene Verzeichnis erteilt. Weitere Informationen zur Authentifizierung und Autorisierung finden Sie in http://httpd.apache.org/docs/2.4/howto/auth.html.

34.5.2 Ausführen eines Beispielskripts

 

Die CGI-Programmierung unterscheidet sich von der herkömmlichen Programmierung insoweit, als CGI-Programmen und -Skripten ein MIME-Typ-Header wie Content-type: text/html vorangestellt werden muss. Dieser Header wird an den Client gesendet, damit er weiß, welchen Inhaltstyp er empfängt. Darüber hinaus muss die Skriptausgabe vom Client, in der Regel einem Webbrowser, verstanden werden – dies ist in der Regel HTML, aber auch Klartext, Bilder oder Ähnliches.

Unter /usr/share/doc/packages/apache2/test-cgi stellt Apache ein einfaches Testskript bereit. Dieses Skript gibt den Inhalt einiger Umgebungsvariablen als Klartext aus. Wenn Sie dieses Skript ausprobieren möchten, kopieren Sie es in das Verzeichnis /srv/www/cgi-bin/ bzw. in das Skriptverzeichnis Ihres virtuellen Hosts (/srv/www/www.example.com/cgi-bin/), und benennen Sie es in test.cgi um. Bearbeiten Sie die Datei so, dass sie #!/bin/sh als erste Zeile enthält.

Dateien, auf die der Webserver zugreifen kann, sollten im Besitz des root-Benutzers sein. Weitere Informationen hierzu finden Sie im Abschnitt Abschnitt 34.8, „Vermeiden von Sicherheitsproblemen“. Da der Webserver unter einem anderen Benutzer ausgeführt wird, müssen CGI-Skripten von jedermann ausgeführt und gelesen werden können. Wechseln Sie daher in das CGI-Verzeichnis und führen Sie den Befehl chmod 755 test.cgi aus, um die entsprechenden Berechtigungen einzurichten.

Rufen Sie danach http://localhost/cgi-bin/test.cgi oder http://example.com/cgi-bin/test.cgi auf. Nun sollte der „CGI/1.0-Testskriptbericht“ angezeigt werden.

34.5.3 CGI-Fehlerbehebung

 

Wenn Sie nach der Ausführung des CGI-Testskripten statt des Testskriptberichts eine Fehlermeldung erhalten, überprüfen Sie Folgendes:

CGI-Fehlerbehebung
 

  • Haben Sie den Server nach der Konfigurationsänderung neu geladen? Falls nicht, laden Sie ihn mit systemctl reload apache2 neu.

  • Falls Sie ein benutzerdefiniertes CGI-Verzeichnis eingerichtet haben, ist dieses richtig konfiguriert? Falls Sie sich nicht sicher sind, führen Sie das Skript im CGI-Standardverzeichnis /srv/www/cgi-bin/ aus. Rufen Sie das Skript dazu mit http://localhost/cgi-bin/test.cgi auf.

  • Wurden die richtigen Berechtigungen zugewiesen?Wechseln Sie in das CGI-Verzeichnis und führen Sie ls -l test.cgi aus. Die Befehlsausgabe sollte mit folgender Zeile beginnen: 

    -rwxr-xr-x  1 root root

  • Überprüfen Sie das Skript auf Programmierfehler. Wenn Sie die Datei test.cgi nicht bearbeitet haben, dürfte sie keine Programmierfehler enthalten. Falls Sie aber eigene Programme verwenden, sollten Sie diese immer auf Programmierfehler untersuchen.

34.6 Einrichten eines sicheren Webservers mit SSL

 

Wenn sensible Daten wie Kreditkarteninformationen zwischen Webserver und Client übertragen werden, ist eine sichere, verschlüsselte Verbindung mit Authentifizierung wünschenswert. mod_ssl bietet mittels der Protokolle Secure Sockets Layer (SSL) und Transport Layer Security (TLS) eine sichere Verschlüsselung für die HTTP-Kommunikation zwischen einem Client und dem Webserver. Wenn Sie TLS/SSL verwenden, wird zwischen dem Webserver und dem Client eine private Verbindung eingerichtet. Die Datenintegrität bleibt dadurch gewährleistet und Client und Server können sich gegenseitig authentifizieren.

Zu diesem Zweck sendet der Server vor der Beantwortung von Anforderungen an eine URL ein SSL-Zertifikat mit Informationen, die die Identität des Servers nachweisen. Dies garantiert, dass der Server eindeutig der richtige Endpunkt der Kommunikation ist. Außerdem wird durch das Zertifikat eine verschlüsselte Verbindung zwischen dem Client und dem Server hergestellt, die sicherstellt, dass Informationen ohne das Risiko der Freigabe sensitiver Klartextinhalte übertragen werden.

mod_ implementiert die TLS/SSL-Protokolle nicht selbst, sondern fungiert als Schnittstelle zwischen Apache und einer SSL-Bibliothek. In SUSE Linux Enterprise Server wird die OpenSSL-Bibliothek verwendet. OpenSSL wird bei der Installation von Apache automatisch installiert.

Die Verwendung von mod_ssl in Apache erkennen Sie in URLs am Präfix https:// (statt http://).

34.6.1 Erstellen eines SSL-Zertifikats

 

Wenn Sie TLS/SSL mit dem Webserver einsetzen möchten, müssen Sie ein SSL-Zertifikat erstellen. Dieses Zertifikat ist für die Autorisierung zwischen Webserver und Client erforderlich, damit beide Endpunkte jeweils die Identität des anderen Endpunkts überprüfen können. Zum Nachweis der Zertifikatintegrität muss das Zertifikat von einer Organisation signiert sein, der jeder der beteiligten Benutzer vertraut.

Sie können drei Zertifikatsarten erstellen: ein „Dummy“-Zertifikat, das nur zu Testzwecken verwendet wird, ein selbst signiertes Zertifikat für einen bestimmten Benutzerkreis, der Ihnen vertraut, und ein Zertifikat, das von einer unabhängigen, öffentlich bekannten Zertifizierungsstelle (CA) signiert wurde.

Die Zertifikaterstellung besteht aus zwei Schritten: Zunächst wird ein privater Schlüssel für die Zertifizierungsstelle generiert und danach wird das Serverzertifikat mit diesem Schlüssel signiert.

Tipp
Tipp: Weitere Informationen

Weitere Informationen über das Konzept von TLS/SSL und diesbezügliche Festlegungen finden Sie unter http://httpd.apache.org/docs/2.4/ssl/ssl_intro.html.

34.6.1.1 Erstellen eines „Dummy“-Zertifikats

 

Zum Erstellen eines Dummy-Zertifikats rufen Sie das Skript /usr/bin/gensslcert auf. Es erstellt oder überschreibt die unten aufgelisteten Dateien. Verwenden Sie die optionalen Schalter von gensslcert, um die Feineinstellungen für das Zertifikat vorzunehmen. Rufen Sie /usr/bin/gensslcert -h auf, um weitere Informationen zu erhalten.

  • /etc/apache2/ssl.crt/ca.crt

  • /etc/apache2/ssl.crt/server.crt

  • /etc/apache2/ssl.key/server.key

  • /etc/apache2/ssl.csr/server.csr

Außerdem wird eine Kopie der Datei ca.crt im Verzeichnis /srv/www/htdocs/CA.crt zum Herunterladen bereitgestellt.

Wichtig
Wichtig: Nur zu Testzwecken

Verwenden Sie Dummy-Zertifikate niemals in Produktionsumgebungen, sondern nur zum Testen.

34.6.1.2 Erstellen eines eigensignierten Zertifikats

 

Wenn Sie einen sicheren Webserver für Ihr Intranet oder einen bestimmten Benutzerkreis einrichten, reicht unter Umständen ein von Ihrer eigenen Zertifizierungsstelle (CA) signiertes Zertifikat aus. Die Besucher einer solchen Website erhalten eine Warnung wie „Diese Website ist nicht vertrauenswürdig“, da die Webbrowser keine eigensignierten Zertifikate erkennen.

Wichtig
Wichtig: Selbstsignierte Zertifikate

Verwenden Sie selbst signierte Zertifikate nur auf einem Webserver, auf den Benutzer zugreifen, denen Sie bekannt sind und die Ihnen als Zertifizierungsstelle vertrauen. Für einen öffentlichen Online-Versand wäre ein solches Zertifikat z. B. nicht geeignet.

Zunächst generieren Sie einen Antrag auf Ausstellung eines Zertifikats (CSR). Hierzu verwenden Sie openssl mit dem Zertifikatsformat PEM. In diesem Schritt werden Sie aufgefordert, einen Passwortsatz anzugeben und mehrere Fragen zu beantworten. Merken Sie sich diesen Passwortsatz; Sie werden ihn später benötigen. 

tux > sudo openssl req -new > new.cert.csr
Generating a 1024 bit RSA private key
..++++++
.........++++++
writing new private key to 'privkey.pem'
Enter PEM pass phrase:1
Verifying - Enter PEM pass phrase:2
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:3
State or Province Name (full name) [Some-State]:4
Locality Name (eg, city) []:5
Organization Name (eg, company) [Internet Widgits Pty Ltd]:6
Organizational Unit Name (eg, section) []:7
Common Name (for example server FQDN, or YOUR name) []:8
Email Address []:9

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:10
An optional company name []:11

1

Geben Sie Ihren Passwortsatz ein.

2

Wiederholen Sie die Eingabe (und merken Sie sie sich).

3

Geben Sie Ihren zwei Buchstaben umfassenden Ländercode ein, z. B. GB oder CZ.

4

Geben Sie den Namen des Bundeslands oder Kantons ein, in dem Sie leben.

5

Geben Sie den Namen des Ortes ein, z. B. Prag.

6

Geben Sie den Namen der Organisation ein, für die Sie arbeiten.

7

Geben Sie Ihre Organisationseinheit ein oder lassen Sie dieses Feld leer, wenn Sie keine Organisationseinheit besitzen.

8

Geben Sie den Domänennamen des Servers bzw. Ihren Vor- und Nachnamen ein.

9

Geben Sie Ihre geschäftliche Email-Adresse ein.

10

Lassen Sie das Challenge-Passwort leer; ansonsten müssen Sie es bei jedem Neustart des Apache-Webservers eingeben.

11

Geben Sie optional den Namen des Unternehmens ein oder lassen Sie dieses Feld leer.

Nun können Sie das Zertifikat generieren. Verwenden Sie openssl erneut und nutzen Sie wieder das standardmäßige PEM-Format für das Zertifikat.

Vorgehen 34.3: Generieren des Zertifikats
 

  1. Exportieren Sie den privaten Teil des Schlüssels in new.cert.key. Sie werden aufgefordert, den Passwortsatz einzugeben, den Sie beim Erstellen des Zertifizierungsantrags (CSR) festgelegt haben. 

    tux > sudo openssl rsa -in privkey.pem -out new.cert.key

  2. Generieren Sie den öffentlichen Teil des Zertifikats gemäß den Daten, die Sie im Ausstellungsantrag angegeben haben. Mit der Option -days geben Sie den Zeitraum (in Tagen) an, nach dem das Zertifikat abläuft. Sie können ein Zertifikat widerrufen oder vor Ablauf ersetzen. 

    tux > sudo openssl x509 -in new.cert.csr -out new.cert.cert -req \
-signkey new.cert.key -days 365

  3. Kopieren Sie die Zertifikatsdateien in die entsprechenden Verzeichnisse, so dass sie vom Apache-Server gelesen werden können. Achten Sie darauf, dass der private Schlüssel /etc/apache2/ssl.key/server.key nicht allgemein lesbar ist, das öffentliche PEM-Zertifikat /etc/apache2/ssl.crt/server.crt dagegen schon. 

    tux > sudo cp new.cert.cert /etc/apache2/ssl.crt/server.crt
tux > sudo cp new.cert.key /etc/apache2/ssl.key/server.key
Tipp
Tipp: Speicherort des öffentlichen Zertifikats

Der letzte Schritt besteht darin, die öffentliche Zertifikatdatei aus dem Verzeichnis /etc/apache2/ssl.crt/server.crt in ein Verzeichnis zu kopieren, in dem die Benutzer auf die Datei zugreifen können. Aus diesem Verzeichnis können die Benutzer sie in ihren Webbrowsern der Liste der bekannten und vertrauenswürdigen Zertifizierungsstellen hinzufügen. Wäre die Zertifizierungsstelle nicht in dieser Liste enthalten, würde der Browser melden, dass das Zertifikat von einer unbekannten Zertifizierungsstelle ausgegeben wurde.

34.6.1.3 Anfordern eines offiziell signierten Zertifikats

 

Es gibt mehrere offizielle Zertifizierungsstellen, die Ihre Zertifikate signieren. Zertifizierungsstellen sind vertrauenswürdige unabhängige Parteien. Einem Zertifikat, das durch eine solche Zertifizierungsstelle signiert wurde, kann daher voll und ganz vertraut werden. Sichere Webserver, deren Inhalte für die Öffentlichkeit bereitstehen, verfügen in der Regel über ein offiziell signiertes Zertifikat. Eine Liste der am häufigsten genutzten Zertifizierungsstellen finden Sie unter https://en.wikipedia.org/wiki/Certificate_authority#Providers.

Wenn Sie ein offiziell signiertes Zertifikat anfordern, senden Sie kein Zertifikat an die Zertifizierungsstelle, sondern eine CSR (Certificate Signing Request, Zertifikatsignierungsanforderung). Geben Sie zum Erstellen einer CSR den folgenden Befehl ein: 

tux > openssl req -new -newkey rsa:2048 -nodes -keyout newkey.pem -out newreq.pem

Sie werden aufgefordert, einen Distinguished Name (DN) einzugeben. Dazu müssen Sie einige Fragen, z. B. nach dem Land oder der Organisation, beantworten. Geben Sie an dieser Stelle nur gültige Daten ein. Schließlich wird alles, was Sie hier eingeben, überprüft und später im Zertifikat angezeigt. Sie müssen nicht alle Fragen beantworten. Wenn eine Frage nicht auf Sie zutrifft oder Sie eine Antwort offen lassen möchten, geben Sie „.“ ein. Unter Common Name (allgemeiner Name) müssen Sie den Namen der Zertifizierungsstelle eingeben. Geben Sie hier einen aussagekräftigen Namen ein, beispielsweise Zertifizierungsstelle von My company. Zum Schluss müssen Sie noch ein Challenge Passwort (zur Vernichtung des Zertifikats, falls der Schlüssel kompromittiert wird) und einen alternativen Unternehmensnamen eingeben.

Die CSR wird in dem Verzeichnis erstellt, aus dem Sie das Skript aufgerufen haben. Der Name der CSR-Datei lautet newreq.pem.

34.6.2 Konfigurieren von Apache mit SSL

 

Der Standard-Port für TLS/SSL-Anfragen auf der Seite des Webservers lautet 443. Es gibt keine Überschneidung zwischen einem „regulären“ Apache mit Überwachung des Ports 80 und einem TLS/SSL-fähigen Apache mit Überwachung des Ports 443. HTTP und HTTPS können sogar mit derselben Apache-Instanz ausgeführt werden. In der Regel verteilen separate virtuelle Hosts die Anforderungen für Port 80 und Port 443 an separate virtuelle Server.

Wichtig
Wichtig: Firewall-Konfiguration

Denken Sie daran, die Firewall für SSL-fähiges Apache an Port 443 zu öffnen. Verwenden Sie hierzu firewalld, wie im Book “Security and Hardening Guide”, Chapter 23 “Masquerading and firewalls”, Section 23.4.3 “Configuring the firewall on the command line” beschrieben.

Der SSL-Modus wird standardmäßig in der globalen Serverkonfiguration aktiviert. Falls er auf Ihrem Host deaktiviert wurde, aktivieren Sie ihn mithilfe des folgenden Kommandos: a2enmod ssl. Um SSL schließlich aktivieren zu können, muss der Server mit dem Flag „SSL“ gestartet werden. Rufen Sie dazu a2enflag SSL auf (Groß- und Kleinschreibung beachten!). Wenn Sie sich zuvor entschieden haben, Ihr Serverzertifikat durch ein Passwort zu verschlüsseln, sollten Sie auch den Wert von APACHE_TIMEOUT in /etc/sysconfig/apache2 heraufsetzen, damit Ihnen beim Start von Apache genügend Zeit für die Eingabe des Passworts bleibt. Starten Sie den Server anschließend neu, damit die Änderungen wirksam werden. Ein Neuladen des Servers reicht dazu nicht aus.

Das Verzeichnis der virtuellen Hostkonfiguration enthält die Vorlage /etc/apache2/vhosts.d/vhost-ssl.template. Diese enthält SSL-spezifische Direktiven, die bereits an anderer Stelle hinreichend dokumentiert sind. Informationen über die Basiskonfiguration eines virtuellen Hosts finden Sie unter Abschnitt 34.2.2.1, „Virtuelle Hostkonfiguration“.

Kopieren Sie zum Starten die Vorlage zu /etc/apache2/vhosts.d/MYSSL-HOST.conf und bearbeiten Sie diese. Es sollte ausreichen, die Werte für die folgenden Anweisungen anzupassen:

  • DocumentRoot

  • ServerName

  • ServerAdmin

  • ErrorLog

  • TransferLog

34.6.2.1 Namensbasierte virtuelle Hosts und SSL

 

Auf einem Server mit nur einer IP-Adresse können standardmäßig nicht mehrere SSL-aktivierte virtuelle Hosts laufen. Für ein namensbasiertes virtuelles Hosting muss Apache wissen, welcher Servername angefordert wurde. Das Problem ist dabei, dass SSL-Verbindungen erst gelesen werden können, nachdem die Verbindung (unter Verwendung des standardmäßigen virtuellen Hosts) bereits hergestellt wurde. Demzufolge erhalten Benutzer eine Warnmeldung, die besagt, dass das Zertifikat nicht mit dem Servernamen übereinstimmt.

SUSE Linux Enterprise Server bietet eine Erweiterung des SSL-Protokolls namens Server Name Indication (SNI), die dieses Problem behebt, indem der Name der virtuellen Domäne als Teil der SSL-Verhandlung gesendet wird. Dies ermöglicht dem Server ein frühes „Umschalten“ zur korrekten virtuellen Domäne, wodurch der Browser das richtige Zertifikat erhält.

SNI ist in SUSE Linux Enterprise Server standardmäßig aktiviert. Für die Aktivierung von namensbasierten virtuellen Hosts für SSL müssen Sie den Server wie in Abschnitt 34.2.2.1.1, „Namensbasierte virtuelle Hosts“ beschrieben konfigurieren. (Beachten Sie, dass für SSL Port 443 anstelle von Port 80 benötigt wird.)

Wichtig
Wichtig: SNI-Browserunterstützung

SNI muss auf der Client-Seite unterstützt werden. SNI wird allerdings von den meisten Browsern unterstützt, ausgenommen von bestimmten älteren Browsern. Weitere Informationen finden Sie im https://en.wikipedia.org/wiki/Server_Name_Indication#Support.

Mit der Direktive SSLStrictSNIVHostCheck konfigurieren Sie die Handhabung von Browsern ohne SNI-Fähigkeit. Wenn SNI in der Serverkonfiguration auf on gesetzt ist, werden Browser ohne SNI-Fähigkeit für alle virtuellen Hosts abgelehnt. Wenn für SNI on in einer VirtualHost-Direktive festgelegt ist, wird der Zugriff auf den konkreten virtuellen Host abgelehnt.

Wenn in der Serverkonfiguration off festgelegt ist, verhält sich der Server wie ohne SNI-Unterstützung. SSL-Anforderungen werden durch den ersten (für Port 443) definierten virtuellen Host bearbeitet.

34.7 Ausführen mehrerer Apache-Instanzen auf demselben Server

 

Das Ausführen mehrerer Apache-Instanzen auf demselben Server bietet mehrere Vorteile gegenüber dem Ausführen mehrerer virtueller Hosts (siehe Abschnitt 34.2.2.1, „Virtuelle Hostkonfiguration“):

  • Wenn ein virtueller Host zeitweise deaktiviert werden muss, müssen Sie die Webserver-Konfiguration ändern und den Webserver neu starten, damit die Änderung in Kraft tritt.

  • Wenn Probleme bei einem einzigen virtuellen Host auftreten, müssen alle virtuellen Hosts neu gestartet werden.

Sie können die standardmäßige Apache-Instanz wie gewohnt ausführen: 

tux > sudo systemctl start apache2

Hiermit wird die standardmäßige Datei /etc/sysconfig/apache2 gelesen. Falls die Variable APACHE_HTTPD_CONF in der Datei nicht festgelegt wurde oder die Datei ganz fehlt, wird stattdessen die Datei /etc/apache2/httpd.conf gelesen.

Zum Aktivieren einer anderen Apache-Instanz führen Sie Folgendes aus: 

tux > sudo systemctl start apache2@INSTANCE_NAME

Beispiel: 

tux > sudo systemctl start apache2@example_web.org

Standardmäßig verwendet die Instanz /etc/apache2@example_web.org/httpd.conf als Hauptkonfigurationsdatei. Diese kann durch Festlegen von APACHE_HTTPD_CONF in /etc/sysconfig/apache2@example_web.org überschrieben werden.

Das nachfolgende Beispiel zeigt, wie Sie eine weitere Instanz von Apache einrichten. Alle Befehle müssen dabei als root ausgeführt werden.

Vorgehen 34.4: Konfigurieren einer weiteren Apache-Instanz
 

  1. Erstellen Sie eine neue Konfiguration auf der Grundlage von /etc/sysconfig/apache2, beispielsweise /etc/sysconfig/apache2@example_web.org: 

    tux > sudo cp /etc/sysconfig/apache2 /etc/sysconfig/apache2@example_web.org

  2. Bearbeiten Sie die Datei /etc/sysconfig/apache2@example_web.org und ändern Sie die Zeile mit 

    APACHE_HTTPD_CONF

    zu 

    APACHE_HTTPD_CONF="/etc/apache2/httpd@example_web.org.conf"

  3. Erstellen Sie die Datei /etc/apache2/httpd@example_web.org.conf auf der Grundlage von /etc/apache2/httpd.conf. 

    tux > sudo cp /etc/apache2/httpd.conf /etc/apache2/httpd@example_web.org.conf

  4. Bearbeiten Sie die Datei /etc/apache2/httpd@example_web.org.conf und ändern Sie 

    Include /etc/apache2/listen.conf

    zu 

    Include /etc/apache2/listen@example_web.org.conf

    Prüfen Sie alle Direktiven und passen Sie sie an Ihre Anforderungen an. Ändern Sie bei Bedarf 

    Include /etc/apache2/global.conf

    und erstellen Sie für jede Instanz eine neue Datei global@example_web.org.conf. Es wird empfohlen, 

    ErrorLog /var/log/apache2/error_log

    zu 

    ErrorLog /var/log/apache2/error@example_web.org_log

    zu ändern, sodass separate Protokolle für die einzelnen Instanzen geführt werden.

  5. Erstellen Sie die Datei /etc/apache2/listen@example_web.org.conf auf der Grundlage von /etc/apache2/listen.conf. 

    tux > sudo cp /etc/apache2/listen.conf /etc/apache2/listen@example_web.org.conf

  6. Bearbeiten Sie die Datei /etc/apache2/listen@example_web.org.conf und ändern Sie 

    Listen 80

    in die Portnummer, an der die neue Instanz ausgeführt werden soll, beispielsweise 82: 

    Listen 82

    Wenn die neue Apache-Instanz über ein sicheres Protokoll ausgeführt werden soll (siehe Abschnitt 34.6, „Einrichten eines sicheren Webservers mit SSL“), ändern Sie außerdem die Zeile 

    Listen 443

    beispielsweise in 

    Listen 445

  7. Starten Sie die neue Apache-Instanz: 

    tux > sudo systemctl start apache2@example_web.org

  8. Prüfen Sie, ob der Server ausgeführt wird. Geben Sie hierzu http://Servername:82 in den Webbrowser ein. Falls Sie den Namen der Fehlerprotokolldatei für die neue Instanz geändert hatten, können Sie ihn prüfen: 

    tux > sudo tail -f /var/log/apache2/error@example_web.org_log

Beim Einrichten mehrerer Apache-Instanzen auf demselben Server sind mehrere Punkte zu beachten:

  • Die Datei /etc/sysconfig/apache2@INSTANZNAME kann dieselben Variablen wie /etc/sysconfig/apache2 enthalten, also auch Einstellungen für das Laden von Modulen und MPM-Einstellungen.

  • Die standardmäßige Apache-Instanz muss nicht ausgeführt werden, wenn andere Instanzen laufen.

  • Die Apache-Helper-Dienstprogramme a2enmod, a2dismod und apachectl werden für die standardmäßige Apache-Instanz ausgeführt, sofern in der Umgebungsvariable HTTPD_INSTANCE nicht anderweitig festgelegt. Im folgenden Beispiel 

    tux > sudo export HTTPD_INSTANCE=example_web.org
tux > sudo a2enmod access_compat
tux > sudo a2enmod status
tux > sudo apachectl start

    werden die Module access_compat und status in die Variable APACHE_MODULES in der Datei /etc/sysconfig/apache2@example_web.org eingefügt; anschließend wird die Instanz example_web.org gestartet.

34.8 Vermeiden von Sicherheitsproblemen

 

Ein dem öffentlichen Internet ausgesetzter Webserver erfordert ständige Wartungs- und Verwaltungsarbeiten. Sicherheitsprobleme, verursacht durch die Software wie auch durch versehentliche Fehlkonfigurationen, sind kaum zu vermeiden. Im Folgenden einige Tipps zur Verbesserung der Sicherheit.

34.8.1 Stets aktuelle Software

 

Bei Bekanntwerden von Sicherheitsrisiken in der Apache-Software veröffentlicht SUSE sofort einen entsprechenden Sicherheitshinweis. Dieser enthält Anleitungen zur Behebung der Risiken, die, sobald es möglich ist, ausgeführt werden sollten. Die Sicherheitsankündigungen von SUSE stehen unter folgenden Adressen zur Verfügung:

34.8.2 DocumentRoot-Berechtigungen

 

In SUSE Linux Enterprise Server sind das DocumentRoot-Verzeichnis /srv/www/htdocs und das CGI-Verzeichnis /srv/www/cgi-bin standardmäßig dem Benutzer bzw. der Gruppe root zugeordnet. Diese Berechtigungen sollten nicht geändert werden. Wenn diese Verzeichnisse für alle Benutzer modifizierbar sind, kann jeder Benutzer Dateien darin ablegen. Diese Dateien würden dann von Apache mit wwwrun-Berechtigungen ausgeführt werden, was wiederum dem Benutzer unbeabsichtigt Zugriff auf die Ressourcen des Dateisystems gewähren würde. Das DocumentRoot-Verzeichnis und die CGI-Verzeichnisse Ihrer virtuellen Hosts sollten Sie als Unterverzeichnisse im Verzeichnis /srv/www anlegen. Stellen Sie auch bei diesen Verzeichnissen sicher, dass die Verzeichnisse und die darin enthaltenen Dateien dem Benutzer bzw. der Gruppe root zugeordnet sind.

34.8.3 Zugriff auf das Dateisystem

 

Standardmäßig wird in /etc/apache2/httpd.conf der Zugriff auf das gesamte Dateisystem verweigert. Diese Direktiven sollten Sie nicht überschreiben. Aktivieren Sie stattdessen explizit den Zugriff auf die Verzeichnisse, die Apache lesen muss. Weitere Informationen finden Sie unter Abschnitt 34.2.2.1.3, „Basiskonfiguration eines virtuellen Hosts“. Achten Sie dabei darauf, dass keine unbefugten Personen auf kritische Dateien wie Passwort- oder Systemkonfigurationsdateien zugreifen können.

34.8.4 CGI-Skripten

 

Interaktive Skripts in PHP, SSI oder anderen Programmiersprachen können im Prinzip jeden beliebigen Befehl ausführen und stellen damit generell ein Sicherheitsrisiko dar. Skripts, die vom Server ausgeführt werden, sollten nur aus Quellen stammen, denen der Serveradministrator vertraut. Keine gute Idee ist es, den Benutzern die Ausführung ihrer eigenen Skripts zu erlauben. Zusätzlich empfiehlt es sich, die Sicherheit aller Skripten zu überprüfen.

Es ist durchaus üblich, sich die Skriptverwaltung durch eine Einschränkung der Skriptausführung zu vereinfachen. Dabei wird die Ausführung von CGI-Skripten auf bestimmte Verzeichnisse eingeschränkt, statt sie global zuzulassen. Die Direktiven ScriptAlias und Option ExecCGI werden zur Konfiguration verwendet. In der Standardkonfiguration von SUSE Linux Enterprise Server ist es generell nicht gestattet, CGI-Skripts von jedem beliebigen Ort aus auszuführen.

Alle CGI-Skripten werden unter dem gleichen Benutzer ausgeführt. Es kann daher zu Konflikten zwischen verschiedenen Skripten kommen. Abhilfe schafft hier das Modul suEXEC, das die Ausführung von CGI-Skripten unter einem anderen Benutzer oder einer anderen Gruppe ermöglicht.

34.8.5 Benutzerverzeichnisse

 

Bei der Aktivierung von Benutzerverzeichnissen (mit mod_userdir oder mod_rewrite) sollten Sie unbedingt darauf achten, keine .htaccess-Dateien zuzulassen. Durch diese Dateien wäre es den Benutzern möglich, die Sicherheitseinstellungen zu überschreiben. Zumindest sollten Sie die Möglichkeiten des Benutzers durch die Direktive AllowOverRide einschränken. In SUSE Linux Enterprise Server sind .htaccess-Dateien standardmäßig aktiviert. Benutzern ist es allerdings nicht erlaubt, Option-Direktiven mit mod_userdir zu überschreiben (siehe hierzu die Konfigurationsdatei /etc/apache2/mod_userdir.conf).

34.9 Fehlerbehebung

 

Wenn sich Apache nicht starten lässt, eine Webseite nicht angezeigt werden kann oder Benutzer keine Verbindung zum Webserver herstellen können, müssen Sie die Ursache des Problems herausfinden. Im Folgenden werden einige nützliche Ressourcen vorgestellt, die Ihnen bei der Fehlersuche behilflich sein können:

Ausgabe des Subkommandos apache2.service:

Statt den Webserver mit der Binärdatei /usr/sbin/apache2ctl zu starten und zu stoppen, verwenden Sie das Kommando systemctl (siehe Abschnitt 34.3, „Starten und Beenden von Apache“). systemctl status apache2 bietet umfassende Informationen über Fehler und stellt außerdem Tipps und Hinweise zur Behebung von Konfigurationsfehlern zur Verfügung.

Protokolldateien und Ausführlichkeitsgrad

Bei schwerwiegenden und nicht schwerwiegenden Fehlern finden Sie mögliche Ursachen in den Apache-Protokolldateien, insbesondere in der standardmäßig im Verzeichnis /var/log/apache2/error_log gespeicherten Fehlerprotokolldatei. Mit der Direktive LogLevel können Sie im Übrigen die Ausführlichkeit der protokollierten Meldungen einstellen. Dies ist z. B. nützlich, wenn Sie mehr Details benötigen.

Tipp
Tipp: Ein einfacher Test

Sie können die Apache-Protokollmeldungen mit dem Befehl tail -F /var/log/apache2/MY_ERROR_LOG überwachen. Führen Sie dann systemctl restart apache2 aus. Versuchen Sie anschließend eine Verbindung mit einem Browser herzustellen und überprüfen Sie dort die Ausgabe.

Firewall und Ports

Es wird häufig versäumt, die Ports für Apache in der Firewall-Konfiguration des Servers zu öffnen. YaST bietet bei der Konfiguration von Apache eine eigene Option, die sich dieses speziellen Themas annimmt (siehe Abschnitt 34.2.3, „Konfigurieren von Apache mit YaST“). Bei der manuellen Konfiguration von Apache können Sie die Ports für HTTP und HTTPS in der Firewall über das Firewall-Modul von YaST öffnen.

Falls sich Ihr Problem nicht mithilfe der vorgenannten Ressourcen beheben lässt, finden Sie weitere Informationen in der Apache-Fehlerdatenbank, die online unter http://httpd.apache.org/bug_report.html zur Verfügung steht. Sie können sich auch an die Apache-Benutzer-Community wenden, die Sie über eine Mailingliste unter http://httpd.apache.org/userslist.html erreichen.

34.10 Weitere Informationen

 

Das Paket apache2-doc, das an verschiedenen Orten bereitgestellt wird, enthält das vollständige Apache-Handbuch für die lokale Installation und Referenz. Das Handbuch ist nicht in der Standardinstallation enthalten. Am schnellsten installieren Sie es mit dem Befehl zypper in apache2-doc. Nach der Installation steht das Apache-Handbuch unter http://localhost/manual/ zur Verfügung. Unter http://httpd.apache.org/docs-2.4/ können Sie auch im Web darauf zugreifen. SUSE-spezifische Konfigurationstipps finden Sie im Verzeichnis /usr/share/doc/packages/apache2/README.*.

34.10.1 Apache 2.4

 

Eine Liste der neuen Funktionen in Apache 2.4 finden Sie unter http://httpd.apache.org/docs/2.4/new_features_2_4.html. Upgrade-Informationen von Version 2.2 auf Version 2.4 erhalten Sie unter http://httpd.apache.org/docs-2.4/upgrading.html.

34.10.2 Apache Module

 

Weitere Informationen zu externen Apache-Modulen, die kurz im Abschnitt Abschnitt 34.4.5, „Externe Module“ beschrieben werden, finden Sie an folgenden Orten:

mod_apparmor

https://en.opensuse.org/SDB:AppArmor

mod_php5

http://www.php.net/manual/en/install.unix.apache2.php

mod_python

http://www.modpython.org/

mod_security

http://modsecurity.org/

34.10.3 Entwicklung

 

Weitere Informationen zur Entwicklung von Apache-Modulen sowie zur Teilnahme am Apache-Webserver-Projekt finden Sie unter folgenden Adressen:

Informationen für Apache-Entwickler

http://httpd.apache.org/dev/

Dokumentation für Apache-Entwickler

http://httpd.apache.org/docs/2.4/developer/

34.10.4 Verschiedene Informationsquellen

 

Wenn Sie in SUSE Linux Enterprise Server Probleme mit Apache haben, werfen Sie einen Blick in die technische Informationssuche unter https://www.suse.com/support. Die Entstehungsgeschichte von Apache finden Sie unter https://httpd.apache.org/ABOUT_APACHE.html. Auf dieser Seite erfahren Sie auch, weshalb dieser Server Apache genannt wird.

35 Einrichten eines FTP-Servers mit YaST

 

Mithilfe des YaST-FTP-Server-Moduls können Sie Ihren Rechner für die Funktion als FTP (File Transfer Protocol)-Server konfigurieren. Anonyme bzw. authentifizierte Benutzer können mithilfe des FTP-Protokolls eine Verbindung zu Ihrem Rechner herstellen und Dateien herunterladen. Abhängig von der Konfiguration können sie auch Dateien auf den FTP-Server hochladen. YaST nutzt vsftpd (Very Secure FTP Daemon).

Wenn das YaST-FTP Server-Modul in Ihrem System nicht verfügbar ist, installieren Sie das Paket yast2-ftp-server. (Informationen zum Verwalten des FTP-Servers von der Kommandozeile aus finden Sie in Abschnitt 4.4.3.7, „yast ftp-server“.)

Führen Sie zum Konfigurieren des FTP-Servers mit YaST die folgenden Schritte aus:

  1. Öffnen Sie das YaST-Kontrollzentrum, und wählen Sie Netzwerkdienste › FTP-Server, oder führen Sie das Kommando yast2 ftp-server als root aus.

  2. Wenn auf Ihrem System kein FTP-Server installiert ist, werden Sie gefragt, welcher Server installiert werden soll, wenn das YaST-FTP-Server-Modul gestartet wird. Wählen Sie einen Server aus, und bestätigen Sie den Dialog.

  3. Konfigurieren Sie im Dialogfeld Start die Optionen für den Startvorgang des FTP-Servers. Weitere Informationen finden Sie im Abschnitt 35.1, „Starten des FTP-Servers“.

    Konfigurieren Sie im Dialogfeld Allgemein die FTP-Verzeichnisse, eine Begrüßung, die Masken zum Erstellen von Dateien sowie andere Parameter. Weitere Informationen finden Sie im Abschnitt 35.2, „Allgemeine FTP-Einstellungen“.

    Legen Sie im Dialogfeld Leistung die Parameter fest, die sich auf das Laden des FTP-Servers auswirken. Weitere Informationen finden Sie im Abschnitt 35.3, „FTP-Leistungseinstellungen“.

    Legen Sie im Dialogfeld Authentifizierung fest, ob der FTP-Server für anonyme und/oder authentifizierte Benutzer verfügbar sein soll. Weitere Informationen finden Sie im Abschnitt 35.4, „Authentifizierung “.

    Konfigurieren Sie im Dialogfeld Einstellungen für Expertenden Betriebsmodus des FTP-Servers, der SSL-Verbindungen sowie die Firewall-Einstellungen. Weitere Informationen finden Sie im Abschnitt 35.5, „Einstellungen für Experten“.

  4. Klicken Sie auf Beenden, um die Änderungen zu speichern.

35.1 Starten des FTP-Servers

 

Legen Sie im Bereich Dienststart des Dialogfelds FTP-Start die Art und Weise fest, in der der FTP-Server gestartet wird. Sie können den Server entweder automatisch während des Systemstarts oder manuell starten. Wenn der FTP-Server erst bei einer FTP-Verbindungsanfrage gestartet werden soll, wählen Sie Via socket aus.

Der aktuelle Status des FTP-Servers wird im Bereich An- und ausschalten im Dialogfeld FTP-Start angezeigt. Starten Sie den FTP-Server, indem Sie auf FTP-Server jetzt starten klicken. Um den Server zu stoppen, klicken Sie auf Stoppen FTP. Nachdem Sie die Servereinstellungen geändert haben, klicken Sie auf Einstellungen speichern und FTP jetzt neu starten. Ihre Konfigurationen werden gespeichert, wenn Sie das Konfigurationsmodul mit Beenden verlassen.

FTP-Serverkonfiguration – Start
Abbildung 35.1: FTP-Serverkonfiguration – Start
 

35.2 Allgemeine FTP-Einstellungen

 

Im Bereich Allgemeine Einstellungen des Dialogfelds Allgemeine FTP-Einstellungen können Sie die Willkommensnachricht festlegen, die nach der Verbindungsherstellung zum FTP-Server angezeigt wird.

Wenn Sie die Option Chroot Everyone (Alle platzieren) aktivieren, werden alle lokalen Benutzer nach der Anmeldung in einem Chroot Jail in ihrem Home-Verzeichnis platziert Diese Option hat Auswirkungen auf die Sicherheit, besonders wenn die Benutzer über Uploadberechtigungen oder Shellzugriff verfügen, daher sollten Sie beim Aktivieren dieser Option mit Bedacht vorgehen.

Wenn Sie die Option Ausführliche Protokollierung aktivieren, werden alle FTP-Anfragen und -Antworten protokolliert.

Sie können die Berechtigungen für Dateien, die von anonymen und/oder authentifizierten Benutzern erstellt wurden, mit umask einschränken. Legen Sie die Dateierstellungsmaske für anonyme Benutzer in Umask für anonyme Benutzer fest und die Dateierstellungsmaske für authentifizierte Benutzer in Umask für authentifizierte Benutzer. Die Masken sollten als Oktalzahlen mit führender Null eingegeben werden. Weitere Informationen zu umask finden Sie auf der man-Seite für umask (man 1p umask).

Legen Sie im Bereich FTP-Verzeichnisse die für anonyme und autorisierte Benutzer verwendeten Verzeichnisse fest. Wenn Sie auf Durchsuchen klicken, können Sie ein zu verwendendes Verzeichnis aus dem lokalen Dateisystem wählen. Das standardmäßige FTP-Verzeichnis für anonyme Benutzer ist /srv/ftp. Beachten Sie, dass vsftpd keine Verzeichnisschreibrechte für alle Benutzer erteilt. Stattdessen wird das Unterverzeichnis upload mit Schreibberechtigungen für anonyme Benutzer erstellt.

35.3 FTP-Leistungseinstellungen

 

Legen Sie im Dialogfeld Leistung die Parameter fest, die sich auf das Laden des FTP-Servers auswirken. Max. Lerrlaufzeit entspricht der Maximalzeit (in Minuten), die der Remote-Client zwischen FTP-Kommandos pausieren darf. Bei einer längeren Inaktivität wird die Verbindung zum Remote-Client getrennt. Max. Clients für eine IP bestimmt die maximale Clientanzahl, die von einer einzelnen IP-Adresse aus verbunden sein können. Max. Clients bestimmt die maximale Clientanzahl, die verbunden sein können. Alle zusätzlichen Clients erhalten eine Fehlermeldung.

Die maximale Datenübertragungsrate (in KB/s) wird in Lovale Max Rate (Lokale max. Rate) für lokale authentifizierte Benutzer und in Anonymous Max Rate (Anonyme max. Rate) für anonyme Benutzer festgelegt. Der Standardwert für diese Einstellung ist 0, was für eine unbegrenzte Datenübertragungsrate steht.

35.4 Authentifizierung

 

Im Bereich Anonyme und lokale Benutzer aktivieren/deaktivieren des Dialogfelds Authentifizierung können Sie festlegen, welche Benutzer auf Ihren FTP-Server zugreifen dürfen. Folgende Optionen stehen zur Verfügung: nur anonymen Benutzern, nur authentifizierten Benutzern oder beiden Benutzergruppen Zugriff erteilen.

Sollen die Benutzer in der Lage sein, Dateien auf den FTP-Server hochzuladen, aktivieren Sie die Option Hochladen aktivieren im Bereich Hochladen des Dialogfelds Authentifizierung. Hier können Sie das Hochladen und das Erstellen von Verzeichnissen sogar für anonyme Benutzer zulassen, indem Sie das entsprechende Kontrollkästchen aktivieren.

Anmerkung
Anmerkung: vsftp – Hochladen von Dateien für anonyme Benutzer zulassen

Wenn ein vsftpd-Server verwendet wird und anonyme Benutzer Dateien hochladen oder Verzeichnisse erstellen dürfen, muss ein Unterverzeichnis mit Schreibberechtigung für alle Benutzer im anonymen FTP-Verzeichnis erstellt werden.

35.5 Einstellungen für Experten

 

Ein FTP-Server kann im aktiven oder passiven Modus ausgeführt werden. Standardmäßig wird der Server im passiven Modus ausgeführt. Um in den aktiven Modus zu wechseln, deaktivieren Sie die Option Passiven Modus aktivieren im Dialogfeld Einstellungen für Experten. Sie können außerdem den Portbereich ändern, der auf dem Server für den Datenstrom verwendet wird, indem Sie die Optionen Min Port für Pas.-Modus und Max Port für Pas.-Modus bearbeiten.

Wenn die Kommunikation zwischen den Clients und dem Server verschlüsselt sein soll, können Sie SSL aktivieren. Wählen Sie dazu die Protokollversionen aus, die unterstützt werden sollen, und geben Sie das RSA-Zertifikat an, das für SSL-verschlüsselte Verbindungen verwendet werden soll.

Wenn Ihr System von einer Firewall geschützt wird, aktivieren Sie Port in Firewall öffnen, um eine Verbindung zum FTP-Server zu ermöglichen.

35.6 Weitere Informationen

 

Weitere Informationen zum FTP-Server finden Sie auf den man-Seiten zu vsftpd und vsftpd.conf.

36 Caching-Proxyserver Squid

 

Squid ist ein häufig verwendeter Caching-Proxyserver für Linux- und UNIX-Plattformen. Das bedeutet, dass er angeforderte Internetobjekte, wie beispielsweise Daten auf einem Web- oder FTP-Server, auf einem Computer speichert, der sich näher an der Arbeitsstation befindet, die die Anforderung ausgegeben hat, als der Server. Er kann in mehreren Hierarchien eingerichtet werden. So werden optimale Reaktionszeiten und die Nutzung einer niedrigen Bandbreite garantiert – auch bei Modi, die für den Endbenutzer transparent sind.

Squid fungiert als Caching-Proxyserver. Er leitet Objektanforderungen von Clients (in diesem Fall: von Webbrowsern) an den Server weiter. Wenn die angeforderten Objekte vom Server eintreffen, stellt er die Objekte dem Client zu und behält eine Kopie davon im Festplatten-Cache. Ein Vorteil des Cachings besteht darin, dass mehrere Clients, die dasselbe Objekt anfordern, aus dem Festplatten-Cache versorgt werden können. Dadurch können die Clients die Daten wesentlich schneller erhalten als aus dem Internet. Durch dieses Verfahren wird außerdem der Datenverkehr im Netzwerk reduziert.

Neben dem eigentlichen Caching bietet Squid eine breite Palette von Funktionen:

  • Verteilung der Last auf mehrere miteinander kommunizierende Hierarchien von Proxyservern

  • Definition strenger Zugriffssteuerungslisten für alle Clients, die auf den Proxyserver zugreifen

  • Zulassen oder Verweigern des Zugriffs auf bestimmte Webseiten mithilfe anderer Anwendungen

  • Erstellen von Statistiken zu häufig besuchten Webseiten zur Bewertung der Internetgewohnheiten des Benutzers

Squid ist kein generischer Proxyserver. Er fungiert normalerweise nur bei HTTP-Verbindungen als Proxy. Außerdem unterstützt er die Protokolle FTP, Gopher, SSL und WAIS, nicht jedoch andere Internetprotokolle, wie das News-Protokoll oder Video-Konferenzen-Protokolle. Da Squid nur das UDP-Protokoll für die Bereitstellung von Kommunikation zwischen verschiedenen Caches unterstützt, werden zahlreiche Multimedia-Programme nicht unterstützt.

36.1 Einige Tatsachen zu Proxyservern

 

Als Proxyserver für Caching-Aufgaben kann Squid auf verschiedene Weise verwendet werden. In Kombination mit einer Firewall kann er die Sicherheit unterstützen. Mehrere Proxies können gemeinsam verwendet werden. Außerdem kann er ermitteln, welche Objekttypen für wie lange im Cache gespeichert werden sollen.

36.1.1 Squid und Sicherheit

 

Squid kann zusammen mit einer Firewall verwendet werden, um interne Netzwerke gegen Zugriffe von außen zu schützen. Die Firewall verweigert allen Clients Zugriff auf externe Dienste mit Ausnahme von Squid. Alle Webverbindungen müssen vom Proxyserver erstellt werden. Bei dieser Konfiguration steuert Squid den gesamten Webzugriff.

Wenn die Firewall-Konfiguration eine entmilitarisierte Zone (demilitarized zone, DMZ) enthält, sollte der Proxyserver in dieser Zone betrieben werden. Unter Abschnitt 36.6, „Konfigurieren eines transparenten Proxys“ wird beschrieben, wie Sie einen transparenten Proxy implementieren. Dadurch wird die Konfiguration der Clients erleichtert, da sie in diesem Fall keine Informationen zum Proxyserver benötigen.

36.1.2 Mehrere Caches

 

Mehrere Instanzen von Squid können für den Austausch von Objekten konfiguriert werden. Dadurch verringert sich die Gesamtlast im System und die Wahrscheinlichkeit erhöht sich, ein Objekt aus dem lokalen Netzwerk abrufen zu können. Außerdem können Cache-Hierarchien konfiguriert werden, sodass ein Cache Objektanforderungen an gleichgeordnete Caches oder einen übergeordneten Cache weiterleiten kann, sodass er Objekte aus einem anderen Cache im lokalen Netzwerk oder direkt von der Quelle anfordern kann.

Die Auswahl einer geeigneten Topologie für die Cache-Hierarchie ist von entscheidender Bedeutung, da es nicht erstrebenswert ist, das Gesamtaufkommen an Datenverkehr im Netzwerk zu erhöhen. Bei sehr großen Netzwerken ist es sinnvoll, einen Proxyserver für jedes Subnetz zu konfigurieren und mit einem übergeordneten Proxyserver zu verbinden, der wiederum mit dem Caching-Proxyserver des ISP verbunden ist.

Diese gesamte Kommunikation wird über das ICP (Internet Cache Protocol) abgewickelt, das über dem UDP-Protokoll ausgeführt wird. Die Übertragungen zwischen den Caches erfolgen über HTTP (Hypertext Transmission Protocol) auf der Grundlage von TCP.

Um den geeignetsten Server zum Anfordern der Objekte zu finden, sendet ein Cache eine ICP-Anforderung an alle gleichgeordneten Proxys. Die gleichgeordneten Proxys beantworten diese Anforderungen über ICP-Antworten. Wenn das Objekt erkannt wurde, verwenden sie einen HIT-Code, wenn nicht, einen MISS-Code.

Wenn mehrere HIT-Antworten gefunden wurden, legt der Proxyserver fest, von welchem Server heruntergeladen werden soll. Diese Entscheidung ist unter anderem davon abhängig, welcher Cache die schnellste Antwort gesendet hat bzw. welcher näher ist. Wenn keine zufriedenstellenden Antworten eingehen, wird die Anforderung an den übergeordneten Cache gesendet.

Anmerkung
Anmerkung: Wie vermeidet Squid die Verdoppelung von Objekten?

Um eine Verdopplung der Objekte in verschiedenen Caches im Netzwerk zu vermeiden, werden andere ICP-Protokolle verwendet, wie beispielsweise CARP (Cache Array Routing Protocol) oder HTCP (Hypertext Cache Protocol). Je mehr Objekte sich im Netzwerk befinden, desto größer ist die Wahrscheinlichkeit, das gewünschte Objekt zu finden.

36.1.3 Caching von Internetobjekten

 

Viele im Netzwerk verfügbaren Objekte sind nicht statisch, wie beispielsweise dynamisch generierte Seiten und TLS/SSL-verschlüsselte Inhalte. Derartige Objekte werden nicht im Cache gespeichert, da sie sich bei jedem Zugriff ändern.

Um zu bestimmen, wie lange Objekte im Cache gespeichert werden sollen, wird Objekten einer von mehreren Status zugewiesen. Web- und Proxyserver ermitteln den Status eines Objekts, indem sie Header zu diesen Objekten hinzufügen, beispielsweise „Zuletzt geändert“ oder „Läuft ab“, und das entsprechende Datum. Andere Header, die angeben, dass Objekte nicht im Cache gespeichert werden dürfen, können ebenfalls verwendet werden.

Objekte im Cache werden in der Regel aufgrund mangelnden Speicherplatzes ersetzt. Dazu werden Algorithmen wie LRU (last recently used) verwendet. Dies bedeutet, dass der Proxy die Objekte löscht, die am längsten nicht mehr angefordert wurden.

36.2 Systemanforderungen

 

Die Systemanforderungen hängen weitgehend von der maximalen Netzwerkauslastung ab, die das System tragen muss. Prüfen Sie daher die Belastungsspitzen, da diese mehr als das Vierfache des Tagesdurchschnitts betragen können. Im Zweifelsfall ist es vorzuziehen, die Systemanforderungen zu hoch einzuschätzen. Wenn Squid an der Grenze seiner Leistungsfähigkeit arbeitet, kann es zu erheblichen Einbußen in der Qualität des Diensts führen. Die folgenden Abschnitte widmen sich den einzelnen Systemfaktoren in der Reihenfolge ihrer Wichtigkeit:

  1. RAM-Größe

  2. CPU-Geschwindigkeit/physische CPU-Cores

  3. Größe des Festplatten-Cache

  4. Festplatten/SSDs und ihre Architektur

36.2.1 RAM

 

Der von Squid benötigte Arbeitsspeicher (RAM) steht in direktem Verhältnis zur Anzahl der Objekte im Cache. RAM ist wesentlich schneller als eine Festplatte/SSD. Daher ist es sehr wichtig, dass genügend Arbeitsspeicher für den Squid-Vorgang zur Verfügung steht, da die Systemleistung erheblich eingeschränkt ist, wenn die Swap-Festplatte verwendet wird.

Außerdem speichert Squid Cache-Objekt-Bezüge und häufig angeforderte Objekte im Hauptspeicher, um das Abrufen dieser Daten zu beschleunigen. Außerdem gibt es andere Daten, die Squid im Arbeitsspeicher benötigt, beispielsweise eine Tabelle mit allen IP-Adressen, einen exakten Domänennamen-Cache, die am häufigsten angeforderten Objekte, Zugriffssteuerungslisten, Puffer usw.

36.2.2 Prozessor

 

Squid ist so eingestellt, dass es am besten mit niedrigeren Prozessor-Core-Zahlen arbeitet (4–8 physische Cores), wobei jeder höchste Leistung bietet. Technologien, die virtuelle Cores bereitstellen, wie Hyperthreading, können sich negativ auf die Leistung auswirken.

Um mehrere CPU-Cores am besten zu nutzen, ist es notwendig, mehrere Worker-Threads einzurichten, die in verschiedene Caching-Geräte schreiben. Standardmäßig ist die Unterstützung mehrerer Cores deaktiviert.

36.2.3 Größe des Festplatten-Cache

 

Bei einem kleinen Cache ist die Wahrscheinlichkeit eines HIT (Auffinden des angeforderten Objekts, das sich bereits dort befindet) gering, da der Cache schnell voll ist und die weniger häufig angeforderten Objekte durch neuere ersetzt werden. Wenn beispielsweise 1 GB für den Cache zur Verfügung steht und die Benutzer nur Datenverkehr im Umfang von 10 MB pro Tag in Anspruch nehmen, dauert es mehr als hundert Tage, um den Cache zu füllen.

Die einfachste Methode zur Ermittlung der benötigten Cache-Größe geht von der maximalen Übertragungsrate der Verbindung aus. Bei einer Verbindung mit 1 Mbit/s beträgt die maximale Übertragungsrate 128 KB/s. Wenn dieser Datenverkehr vollständig im Cache gespeichert wird, ergeben sich in einer Stunde 460 MB. Bei der Annahme, dass dieser Datenverkehr in nur 8 Arbeitsstunden generiert wird, würden 3,6 GB an einem einzigen Tag erreicht werden. Da in der Regel nicht das gesamte Volumen der Verbindung ausgeschöpft wird, kann angenommen werden, dass das Gesamtdatenvolumen, das auf den Cache zukommt, bei etwa 2 GB liegt. Daher sind bei diesem Beispiel 2 GB Festplattenspeicher erforderlich, damit Squid die durchsuchten Daten eines Tags im Cache speichern kann.

36.2.4 Festplatten-/SSD-Architektur

 

Da Geschwindigkeit beim Caching eine wichtige Rolle spielt, muss diesem Faktor besondere Aufmerksamkeit gewidmet werden. Bei Festplatten wird dieser Parameter als random seek time (Zufallszugriffszeit) oder random read performance (Zufallsleseleistung) beschrieben – gemessen in Millisekunden. Da die Datenblöcke, die Squid von der Festplatte/SSD liest oder auf die Festplatte/SSD schreibt, tendenziell eher klein sind, ist die Zugriffszeit/Leseleistung der Festplatte/SSD entscheidender als ihr Datendurchsatz.

Für die Verwendung als Proxyserver sind Festplatten mit hoher Rotationsgeschwindigkeit oder SSDs die beste Wahl. Bei der Verwendung von Festplatten kann es besser sein, mehrere kleinere Festplatten zu verwenden. Dabei sollte jede ein einzelnes Cache-Verzeichnis aufweisen, um übermäßige Lesezeiten zu vermeiden.

Die Verwendung von RAID-Systemen bietet eine erhöhte Zuverlässigkeit, bedeutet jedoch Einschränkungen bei der Geschwindigkeit. Vermeiden Sie jedoch aus Leistungsgründen (Software-)RAID5 und ähnliche Einstellungen.

Die Wahl des Dateisystems ist in der Regel nicht entscheidend. Jedoch kann mit der Einhängeoption noatime die Leistung verbessert werden. Squid stellt eigene Zeitstempel bereit und erfordert daher nicht, dass das Dateisystem die Zugriffszeiten überwacht.

36.3 Grundlegende Verwendung von Squid

 

Installieren Sie das Paket, falls es nicht bereits installiert ist squid . squid gehört nicht zu den Paketen, die standardmäßig auf SUSE Linux Enterprise Server installiert werden.

Squid ist in SUSE Linux Enterprise Server bereits vorkonfiguriert. Sie können das Programm unmittelbar nach der Installation starten. Um einen reibungslosen Start zu gewährleisten, sollte das Netzwerk so konfiguriert werden, dass mindestens ein Namenserver und das Internet erreicht werden können. Es können Probleme auftreten, wenn eine Einwahlverbindung zusammen mit einer dynamischen DNS-Konfiguration verwendet wird. In diesem Fall sollte zumindest der Nameserver angegeben werden, da Squid nicht startet, wenn kein DNS-Server in /var/run/netconfig/resolv.conf gefunden wird.

36.3.1 Starten von Squid

 

Verwenden Sie zum Starten von Squid Folgendes: 

tux > sudo systemctl start squid

Wenn Sie möchten, dass Squid beim Booten des Systems gestartet wird, aktivieren Sie den Dienst mit systemctl enable squid.

36.3.2 Überprüfen, ob Squid ausgeführt wird

 

Wählen Sie zum Überprüfen, ob Squid ausgeführt wird, eine der folgenden Optionen:

  • Mithilfe von systemctl: 

    tux > systemctl status squid

    Die Ausgabe dieses Kommandos sollte Folgendes für Squid anzeigen: loaded (geladen) und active (running) (aktiv (wird ausgeführt)).

  • Mithilfe von Squid: 

    tux > sudo squid -k check | echo $?

    Die Ausgabe dieses Befehls sollte 0 lauten, kann jedoch zusätzliche Warnungen oder Meldungen umfassen.

Um die Funktionsfähigkeit von Squid im lokalen System zu testen, wählen Sie eine der folgenden Optionen:

  • Zum Testen können Sie squidclient verwenden, ein Kommandozeilenwerkzeug, das die Antwort auf eine Webanforderung ausgeben kann, ähnlich wie wget oder curl.

    Anders als diese Werkzeuge verbindet squidclient sich automatisch mit dem Standard-Proxy-Setup von Squid, localhost:3128. Wenn Sie jedoch die Konfiguration von Squid geändert haben, müssen Sie squidclient mithilfe von Kommandozeilenoptionen so konfigurieren, dass es andere Einstellungen verwendet. Weitere Informationen erhalten Sie mit squidclient --help.

    Beispiel 36.1: Eine Anforderung mit squidclient
     
    tux > squidclient http://www.example.org
HTTP/1.1 200 OK
Cache-Control: max-age=604800
Content-Type: text/html
Date: Fri, 22 Jun 2016 12:00:00 GMT
Expires: Fri, 29 Jun 2016 12:00:00 GMT
Last-Modified: Fri, 09 Aug 2013 23:54:35 GMT
Server: ECS (iad/182A)
Vary: Accept-Encoding
X-Cache: HIT
x-ec-custom-error: 1
Content-Length: 1270
X-Cache: MISS from moon1
X-Cache-Lookup: MISS from moon:3128
Via: 1.1 moon (squid/3.5.16)2
Connection: close

<!doctype html>
<html>
<head>
    <title>Example domain</title>
[...]
</body>
</html>

    Die in Beispiel 36.1, „Eine Anforderung mit squidclient“ angezeigte Ausgabe kann in zwei Teile aufgeteilt werden:

    1. Die Protokoll-Header der Antwort: die Zeilen vor der leeren Zeile.

    2. Der eigentliche Inhalt der Antwort: die Zeilen nach der leeren Zeile.

    Um zu überprüfen, ob Squid verwendet wird, sehen Sie sich im Header die ausgewählten Zeilen an:

    1

    Der Wert X-Cache im Header gibt an, dass das angeforderte Dokument nicht im Squid-Cache (MISS) des Computers moon gespeichert war.

    Das Beispiel oben enthält zwei X-Cache-Zeilen. Sie können den ersten X-Cache-Header ignorieren. Er wird von der internen Caching-Software erstellt, die vom Webserver stammt.

    2

    Der Wert Via im Header gibt die HTTP-Version, den Namen des Computers und die verwendete Squid-Version an.

  • Mithilfe eines Browsers: Richten Sie localhost als Proxy und 3128 als Port ein. Sie können dann eine Seite laden und die Antwort-Header in der Kontrollleiste Netzwerk des Inspektors oder der Entwicklertools des Browsers überprüfen. Die Header sollten ähnlich wie in Beispiel 36.1, „Eine Anforderung mit squidclient“ reproduziert werden.

Um Benutzern aus dem lokalen System und anderen Systemen den Zugriff auf Squid und das Internet zu ermöglichen, müssen Sie den Eintrag in den Konfigurationsdateien /etc/squid/squid.conf von http_access deny all in http_access allow all ändern. Beachten Sie dabei jedoch, dass dadurch jedem der vollständige Zugriff auf Squid ermöglicht wird. Legen Sie daher ACLs (Access Control Lists = Zugriffssteuerungslisten) fest, die den Zugriff auf den Proxyserver steuern. Nach Bearbeiten der Konfigurationsdatei muss Squid neu geladen oder neu gestartet werden. Weitere Informationen zu ACLs finden Sie in Abschnitt 36.5.2, „Optionen für die Zugriffssteuerung“.

Wenn Squid nach kurzer Zeit nicht mehr funktioniert, obwohl das Programm erfolgreich gestartet wurde, überprüfen Sie, ob ein fehlerhafter Nameservereintrag vorliegt oder ob die Datei /var/run/netconfig/resolv.conf fehlt. Squid protokolliert die Ursache eines Startfehlers in der Datei /var/log/squid/cache.log.

36.3.3 Stoppen, Neuladen und Neustarten von Squid

 

Zum Neuladen von Squid stehen die folgenden Verfahren zur Auswahl:

  • Mithilfe von systemctl: 

    tux > sudo systemctl reload squid

    oder 

    tux > sudo systemctl restart squid

  • Verwenden von YaST:

    Klicken Sie im Squid-Modul auf die Schaltfläche Einstellungen jetzt speichern und Squid neu starten

Zum Anhalten von Squid stehen die folgenden Verfahren zur Auswahl:

  • Mithilfe von systemctl: 

    tux > sudo systemctl stop squid

  • Verwenden von YaST

    Klicken Sie im Squid-Modul auf die Schaltfläche Squid jetzt stoppen Schaltfläche.

Das Herunterfahren von Squid kann einige Zeit dauern, da Squid bis zu eine halbe Minute wartet, bis die Verbindungen zu den Clients unterbrochen und die Daten auf die Festplatte geschrieben werden (siehe Option shutdown_lifetime in /etc/squid/squid.conf),

Warnung
Warnung: Beenden von Squid

Das Beenden von Squid mit kill oder killall kann den Cache beschädigen. Damit Squid neu gestartet werden kann, müssen beschädigte Caches gelöscht werden.

36.3.4 Entfernen von Squid

 

Durch das Entfernen von Squid aus dem System werden die Cache-Hierarchie und die Protokolldateien nicht entfernt. Um diese zu entfernen, müssen Sie das Verzeichnis /var/cache/squid manuell löschen.

36.3.5 Lokaler DNS-Server

 

Die Einrichtung eines lokalen DNS-Servers ist sinnvoll, selbst wenn er nicht seine eigene Domäne verwaltet. Er fungiert dann einfach als Nur-Cache-Namenserver und kann außerdem DNS-Anforderungen über die Root-Namenserver auflösen, ohne dass irgendeine spezielle Konfiguration erforderlich ist (siehe Abschnitt 31.4, „Starten des BIND-Nameservers“). Wie dies durchgeführt werden kann, hängt davon ab, ob Sie bei der Konfiguration der Internetverbindung dynamisches DNS auswählen.

Dynamisches DNS

Normalerweise wird bei dynamischem DNS der DNS-Server während des Aufbaus der Internetverbindung vom Anbieter festgelegt und die lokale Datei /var/run/netconfig/resolv.conf wird automatisch angepasst. Dieses Verhalten wird in der Datei /etc/sysconfig/network/config mit der sysconfig-Variablen NETCONFIG_DNS_POLICY gesteuert. Legen Sie NETCONFIG_DNS_POLICY zu "" fest.

Fügen Sie anschließend den lokalen DNS-Server in der Datei /var/run/netconfig/resolv.conf hinzu. Verwenden Sie die IP-Adresse 127.0.0.1 für localhost. Auf diese Weise kann Squid immer den lokalen Nameserver finden, wenn er gestartet wird.

Um den Zugriff auf den Nameserver des Anbieters zu ermöglichen, geben Sie ihn zusammen mit seiner IP-Adresse in der Konfigurationsdatei /etc/named.conf unter forwarders an. Mit dynamischem DNS kann dies automatisch während des Verbindungsaufbaus erreicht werden. Setzen Sie hierzu die sysconfig-Variable NETCONFIG_DNS_POLICY zu auto.

Statisches DNS

Beim statischen DNS finden beim Verbindunsgsaufbau keine automatischen DNS-Anpassungen statt, sodass auch keine sysconfig-Variablen geändert werden müssen. Sie müssen jedoch den lokalen DNS-Server in der Datei /var/run/netconfig/resolv.conf, wie unter Dynamisches DNS beschrieben, angeben. Außerdem muss der statische Nameserver des Anbieters zusammen mit seiner IP-Adresse manuell in der Datei /etc/named.conf unter Forwarders angegeben werden.

Tipp
Tipp: DNS und Firewall

Wenn eine Firewall ausgeführt wird, müssen Sie sicherstellen, dass DNS-Anforderungen durchgelassen werden.

36.4 Das YaST-Squid-Modul

 

Das YaST-Squid-Modul enthält die folgenden Registerkarten:

Start

Gibt an, wie Squid gestartet wird und welcher Firewall-Port auf welchen Schnittstellen geöffnet ist.

HTTP-Ports

Definiert alle Ports, die Squid auf HTTP-Anforderungen von Clients überwacht.

Aktualisierungsschemata

Gibt an, wie Squid die Objekte im Cache behandelt.

Cache-Einstellungen

Definiert Einstellungen für den Cache-Speicher, die maximale und minimale Objektgröße und vieles mehr.

Cache-Verzeichnis

Definiert das übergeordnete Verzeichnis, in dem Squid alle Cache-Swap-Dateien speichert.

Zugriffssteuerung

Steuert den Zugriff auf den Squid-Server mithilfe von ACL-Gruppen.

Protokollierung und Zeitüberschreitung

Definiert die Pfade zu den Protokolldateien für Zugriff, Cache und Cache-Speicher sowie die Zeitüberschreitung für die Verbindungen und die Client-Lebensdauer.

Sonstige

Legt die Sprache und die Email-Adresse des Administrators fest.

36.5 Die Squid-Konfigurationsdatei

 

Alle Einstellungen für den Squid-Proxyserver werden in der Datei /etc/squid/squid.conf vorgenommen. Beim ersten Start von Squid sind keine Änderungen in dieser Datei erforderlich, externen Clients wird jedoch ursprünglich der Zugriff verweigert. Der Proxy ist für localhost verfügbar. Der Standardport ist 3128. Die vorinstallierte Konfigurationsdatei /etc/squid/squid.conf bietet detaillierte Informationen zu den Optionen sowie zahlreiche Beispiele.

Viele Einträge sind kommentiert und beginnen deshalb mit dem Kommentarzeichen #. Die relevanten Spezifikationen finden Sie am Ende der Zeile. Die angegebenen Werte entsprechen in der Regel den Standardwerten, daher hat das Entfernen der Kommentarzeichen ohne Ändern der Parameter in der Regel keine Auswirkungen. Lassen Sie die kommentierten Zeilen nach Möglichkeit unverändert und geben Sie die Optionen zusammen mit den geänderten Werten in der Zeile darunter ein. Auf diese Weise können die Standardwerte problemlos wiederhergestellt und mit den Änderungen verglichen werden.

Tipp
Tipp: Anpassen der Konfigurationsdatei nach einer Aktualisierung

Wenn Sie eine Aktualisierung einer früheren Squid-Version durchgeführt haben, sollten Sie die neue Datei /etc/squid/squid.conf bearbeiten und nur die in der vorherigen Datei vorgenommenen Änderungen übernehmen.

Manchmal werden Squid-Optionen hinzugefügt, entfernt oder geändert. Daher kann Squid möglicherweise aufhören, ordnungsgemäß zu funktionieren, wenn Sie die alte squid.conf-Datei verwenden.

36.5.1 Allgemeine Konfigurationsoptionen

 

Nachfolgend finden Sie eine Liste mit einer Auswahl an Konfigurationsoptionen für Squid. Die Liste ist nicht vollständig. Das Squid-Paket enthält eine vollständige Liste mit einfacher Veranschaulichung in der Datei /etc/squid/squid.conf.documented.

http_port PORT

Dies ist der Port, den Squid auf Client-Anforderungen überwacht. Der Standardport ist 3128, 8080 wird jedoch ebenfalls häufig verwendet.

cache_peer HOSTNAME TYP PROXY-PORT ICP-PORT

Mit dieser Option kann ein Netzwerk mit Caches erstellt werden, die zusammen arbeiten. Der Cache-Peer ist ein Computer, der auch ein Netzwerk-Cache hostet und in einer Beziehung zu Ihrem eigenen steht. Der Typ der Beziehung wird als TYP angegeben. Der Typ kann entweder parent oder sibling sein.

Geben Sie als HOSTNAME den Namen oder die IP-Adresse des verwendeten Proxyservers an. Geben Sie für PROXY-PORT die Portnummer zur Verwendung in einem Browser an (in der Regel 8080). Legen Sie für ICP-PORT den Wert 7 oder, wenn der ICP-Port des übergeordneten Proxy nicht bekannt ist und seine Verwendung für den Anbieter nicht wichtig ist, den Wert 0 fest.

Damit Squid sich wie ein Webbrowser verhält und nicht wie ein Proxyserver, unterbinden Sie die Verwendung des ICP-Protokolls. Hängen Sie dazu die Optionen default und no-query an.

cache_mem GRÖSSE

Diese Option legt fest, wie viel Arbeitsspeicher Squid für besonders beliebte Antworten verwenden kann. Der Standardwert ist 8 MB. Dieser Wert gibt nicht die Arbeitsspeichernutzung von Squid an und kann überschritten werden.

cache_dir SPEICHERTYP CACHE-VERZEICHNIS CACHE-GRÖSSE EBENE-1-VERZEICHNISSE EBENE-2-VERZEICHNISSE

Die Option cache_dir legt das Verzeichnis für den Festplatten-Cache fest. In der Standardkonfiguration auf SUSE Linux Enterprise Server erstellt Squid keinen Festplatten-Cache.

Der Platzhalter SPEICHERTYP kann einen der folgenden Werte haben:

  • Verzeichnisbasierte Speichertypen: ufs, aufs (Standard), diskd. Alle drei Typen sind Variationen des Speicherformats ufs. Dabei wird ufs als Teil des Squid-Core-Threads ausgeführt, aufs wird in einem separaten Thread ausgeführt und diskd verwendet einen separaten Prozess. Dies bedeutet, dass die letzten beiden Typen das Blockieren von Squid aufgrund von Datenträger-E/A vermeiden.

  • Datenbankbasierte Speichersysteme: rock. Dieses Speicherformat basiert auf einer einzelnen Datenbankdatei, in der jedes Objekt eine oder mehrere Arbeitsspeichereinheiten einer festen Größe („Slots“) einnimmt.

Im Folgenden werden nur die Parameter für Speichertypen beschrieben, die auf ufs basieren. rock weist etwas andere Parameter auf.

Der Parameter CACHE-VERZEICHNIS steht für das Verzeichnis des Festplatten-Cache. Standardmäßig lautet dieses /var/cache/squid. CACHE-GRÖSSE ist die maximale Größe dieses Verzeichnisses in Megabyte. Der festgelegte Standardwert ist 100 MB. Legen Sie eine Größe zwischen 50 % und maximal 80 % des verfügbaren Speicherplatzes fest.

Die letzten zwei Werte EBENE-1-VERZEICHNISSE und EBENE-2-VERZEICHNISSE geben an, wie viele Unterverzeichnisse im CACHE-VERZEICHNIS erstellt werden. Standardmäßig werden 16 Unterverzeichnisse auf der ersten Ebene unter CACHE-VERZEICHNIS und 256 jeweils innerhalb dieser Ebenen erstellt. Diese Werte sollten nur nach reiflicher Überlegung erhöht werden, da zu viele Verzeichnisse zu Leistungsproblemen führen können.

Wenn ein Cache von mehreren Datenträgern gemeinsam verwendet wird, müssen Sie mehrere cache_dir-Zeilen angeben.

cache_access_log PROTOKOLLDATEI, cache_log PROTOKOLLDATEI, cache_store_log PROTOKOLLDATEI

Diese drei Optionen geben die Pfade an, in denen Squid alle Aktionen protokolliert. In der Regel muss hier nichts geändert werden. Bei hoher Auslastung von Squid kann es sinnvoll sein, Cache und Protokolldateien auf mehrere Datenträger zu verteilen.

client_netmask NETZMASKE

Diese Option ermöglicht die Maskierung von IP-Adressen des Client in der Protokolldatei, indem eine Teilnetzmaske angewendet wird. Um beispielsweise für die letzte Zahl der IP-Adresse 0 festzulegen, geben Sie 255.255.255.0 an.

ftp_user E-MAIL

Diese Option ermöglicht die Einstellung des Passworts, das Squid für die anonyme FTP-Anmeldung verwenden soll. Geben Sie hier eine gültige Email-Adresse ein, da manche FTP-Server diese auf Gültigkeit überprüfen.

cache_mgr E-MAIL

Bei unerwartetem Absturz sendet Squid eine Nachricht an diese Email-Adresse. Der Standardwert ist webmaster.

logfile_rotate WERT

Wenn Sie squid -k rotate ausführen, kann Squid ein Rotationssystem für Protokolldateien einführen. Bei diesem Prozess werden die Dateien nummeriert und nach dem Erreichen des angegebenen Werts wird die älteste Datei überschrieben. Der Standardwert ist 10. Hierdurch werden Protokolldateien mit den Nummern 0 bis 9 rotiert.

Auf SUSE Linux Enterprise Server erfolgt die Rotation der Protokolldateien jedoch mithilfe von logrotate und der Konfigurationsdatei /etc/logrotate.d/squid automatisch.

append_domain DOMÄNE

Verwenden Sie append_domain, um anzugeben, welche Domäne automatisch angefügt wird, wenn keine angegeben wurde. In der Regel wird hier die eigene Domäne angegeben, sodass bei der Angabe von www im Browser ein Zugriff auf Ihren eigenen Webserver erfolgt.

forwarded_for STATUS

Ist für diese Option on festgelegt, wird eine Zeile wie die folgende zum Header hinzugefügt: 

X-Forwarded-For: 192.168.0.1

Wenn Sie für diese Option off festlegen, entfernt Squid die IP-Adresse und den Systemnamen des Client aus den HTTP-Anforderungen.

negative_ttl ZEIT, negative_dns_ttl ZEIT

Sind diese Optionen festgelegt, speichert Squid manche Fehlertypen im Cache, wie beispielsweise 404-Antworten. Squid lässt dann keine neuen Anforderungen mehr zu, selbst wenn die Ressource verfügbar wäre.

Standardmäßig sind für negative_ttl der Wert 0 und für negative_dns_ttl der Wert 1 minutes festgelegt. Dies bedeutet, dass negative Antworten auf Webanforderungen standardmäßig nicht im Cache gespeichert werden und negative Antworten auf DNS-Anforderungen für eine Minute im Cache gespeichert werden.

never_direct allow ACL-NAME

Um zu verhindern, dass Squid Anforderungen direkt aus dem Internet entgegennimmt, müssen Sie mit der Option never_direct die Verbindung mit einem anderen Proxyserver erzwingen. Dieser muss zuvor unter cache_peer angegeben worden sein. Wenn all als ACL-NAME angegeben ist, werden alle Anforderungen direkt an den übergeordneten Proxy (parent) weitergeleitet. Dies kann beispielsweise dann erforderlich sein, wenn Sie einen Anbieter verwenden, der die Verwendung der eigenen Proxys vorschreibt oder der durch seine Firewall direkten Internetzugriff verweigert.

36.5.2 Optionen für die Zugriffssteuerung

 

Squid bietet ein detailliertes System für die Steuerung des Zugriffs auf den Proxyserver. Diese ACLs (Access Control Lists = Zugriffssteuerungslisten) sind Listen mit Regeln, die nacheinander verarbeitet werden. Die ACLs müssen zuerst definiert werden, bevor sie verwendet werden können. Einige Standard-ACLs, wie beispielsweise all und localhost, sind bereits vorhanden. Die bloße Definition einer ACL bedeutet jedoch noch nicht, dass sie tatsächlich angewendet wird. Dies passiert nur dann, wenn eine entsprechende http_access-Regel vorhanden ist.

Die Syntax für die Option acl lautet: 

acl ACL_NAME TYPE DATA

Die Platzhalter innerhalb dieser Syntax stehen für Folgendes:

  • Der Name ACL-NAME kann frei gewählt werden.

  • Als TYP können Sie aus einer Vielzahl verschiedener Optionen wählen, die Sie im Abschnitt ACCESS CONTROLS in der Datei /etc/squid/squid.conf finden.

  • Die Angabe für DATA hängt vom jeweiligen ACL-Typ ab, beispielsweise Hostnamen, IP-Adressen oder URLs, und kann auch von einer Datei gelesen werden.

Sollen Regeln in das YaST-Squid-Modul eingefügt werden, öffnen Sie das Modul und klicken Sie auf die Registerkarte Zugriffssteuerung. Klicken Sie unter der Liste der ACL-Gruppen auf Hinzufügen und geben Sie den Namen Ihrer Regel, den Typ und die zugehörigen Parameter ein.

Weitere Informationen zu den Typen von ACL-Regeln finden Sie in der Squid-Dokumentation unter http://www.squid-cache.org/Versions/v3/3.5/cfgman/acl.html.

Beispiel 36.2: Definieren von ACL-Regeln
 
acl mysurfers srcdomain .example.com 1
acl teachers src 192.168.1.0/255.255.255.0 2
acl students src 192.168.7.0-192.168.9.0/255.255.255.0 3
acl lunch time MTWHF 12:00-15:00 4

1

Diese ACL definiert mysurfers als alle Benutzer, die von .example.com kommen (wie durch Reverse-Lookup für die IP bestimmt wurde).

2

Diese ACL definiert teachers als die Benutzer von Computern, deren IP-Adressen mit 192.168.1. beginnen.

3

Diese ACL definiert students als die Benutzer von Computern, deren IP-Adressen mit 192.168.7., 192.168.8. oder 192.168.9. beginnen.

4

Diese ACL definiert lunch als eine Uhrzeit an den Tagen Montag bis Freitag zwischen 12 und 15 Uhr.

http_access allow ACL-NAME

http_access definiert, wer den Proxyserver verwenden darf und wer auf welche Seiten im Internet zugreifen kann. Hierfür müssen ACLs festgelegt werden. localhost und all wurden bereits oben festgelegt. Sie können den Zugriff dafür verweigern oder erlauben mit deny bzw. allow. Eine Liste mit einer beliebigen Anzahl von http_access-Einträgen kann erstellt werden, die dann von oben nach unten verarbeitet wird. Je nachdem, welcher Eintrag zuerst auftritt, wird der Zugriff auf die entsprechende URL erlaubt oder verweigert. Der letzte Eintrag muss immer http_access deny all sein. Im folgenden Beispiel hat localhost freien Zugriff auf alle Elemente, während allen anderen Hosts der Zugriff vollständig verweigert wird: 

http_access allow localhost
http_access deny all

In einem anderen Beispiel, bei dem diese Regeln verwendet werden, hat die Gruppe teachers immer Zugriff auf das Internet. Die Gruppe students erhält nur montags bis freitags während der Mittagspause Zugriff: 

http_access deny localhost
http_access allow teachers
http_access allow students lunch time
http_access deny all

Geben Sie für eine bessere Lesbarkeit in der Konfigurationsdatei /etc/squid/squid.conf alle http_access-Optionen in einem Block an.

url_rewrite_program PFAD

Geben Sie mit dieser Optionen einen URL-Rewriter an.

auth_param basic program PFAD

Wenn Benutzer auf dem Proxyserver authentifiziert werden müssen, geben Sie ein geeignetes Programm an, beispielsweise /usr/sbin/pam_auth. Beim ersten Ausführen von pam_auth wird ein Anmeldefenster geöffnet, in dem der Benutzer den Benutzernamen und das Passwort eingeben muss. Außerdem ist eine ACL erforderlich, sodass nur Clients mit einer gültigen Anmeldung das Internet benutzen können: 

acl password proxy_auth REQUIRED

http_access allow password
http_access deny all

Wird in der Option acl proxy_auth der Wert REQUIRED verwendet, bedeutet dies, dass alle gültigen Benutzernamen akzeptiert werden. REQUIRED kann auch durch eine Liste mit erlaubten Benutzernamen ersetzt werden.

ident_lookup_access allow ACL-NAME

Lassen Sie damit eine ident-Anforderung für alle Clients, die mit einer ACL des Typs src festgelegt sind, ausführen, um die Identität der einzelnen Benutzer zu ermitteln. Alternativ dazu (verwenden Sie dies für alle Clients) können Sie die vordefinierte ACL all als ACL-NAME anwenden.

Auf allen Clients, die durch ident_lookup_access abgedeckt sind, muss ein ident-Daemon ausgeführt werden. Unter Linux können Sie pidentd (package pidentd ) als ident-Daemon verwenden. Für andere Betriebssysteme ist in der Regel kostenlose Software verfügbar. Um sicherzustellen, dass nur Clients mit einem erfolgreichen ident-Lookup zulässig sind, definieren Sie eine entsprechende ACL: 

acl identhosts ident REQUIRED

http_access allow identhosts
http_access deny all

Wird in der Option acl identhosts ident der Wert REQUIRED verwendet, bedeutet dies, dass alle gültigen Benutzernamen akzeptiert werden. REQUIRED kann auch durch eine Liste mit erlaubten Benutzernamen ersetzt werden.

Durch die Verwendung von ident kann die Zugriffszeit erheblich reduziert werden, da die ident-Lookups für jede Anforderung wiederholt werden.

36.6 Konfigurieren eines transparenten Proxys

 

Ein transparenter Proxy fängt die Anforderungen des Webbrowsers ab und beantwortet sie, sodass der Webbrowser die angeforderten Seiten erhält, ohne dass bekannt ist, woher sie kommen. Wie der Name bereits andeutet, verläuft der gesamte Prozess für den Benutzer transparent.

In der Regel arbeiten Sie folgendermaßen mit Proxyservern: Der Webbrowser sendet Anforderungen an einen bestimmten Port des Proxyservers und der Proxy liefert immer diese erforderlichen Objekte, unabhängig davon, ob sie sich im Cache befinden oder nicht. In manchen Fällen ist die Verwendung des transparenten Proxy-Modus von Squid empfehlenswert:

  • Wenn aus Sicherheitsgründen alle Clients einen Proxyserver für den Zugriff auf das Internet verwenden sollten.

  • Wenn alle Clients einen Proxyserver verwenden müssen, unabhängig davon, ob sie sich dessen bewusst sind.

  • Wenn der Proxyserver in einem Netzwerk verschoben wird, die vorhandenen Clients jedoch ihre alte Konfiguration beibehalten müssen.

Vorgehen 36.1: Squid als transparenter Proxyserver (Kommandozeile)
 

  1. Fügen Sie in der Datei /etc/squid/squid.conf in der Zeile mit der Option http_port den Parameter transparent hinzu. Damit sollten Sie zwei Zeilen erhalten: 

    http_port 3128
http_port 3128 transparent

  2. Starten Sie Squid neu: 

    tux > sudo systemctl restart squid

  3. Richten Sie die Firewall so ein, dass der HTTP-Datenverkehr an den unter http_proxy angegebenen Port umgeleitet wird. Im obigen Beispiel ist dies der Port 3128. Laden Sie dann die Firewall-Konfiguration neu. Hierbei wird vorausgesetzt, dass die Zone internal der LAN-Schnittstelle zugewiesen ist. 

    tux > sudo firewall-cmd --permanent --zone=internal \
    --add-forward-port=port=80:proto=tcp:toport=3128:toaddr=LAN_IP
tux > sudo firewall-cmd --permanent --zone=internal --add-port=3128/tcp
tux > sudo firewall-cmd --reload

    Ersetzen Sie LAN_IP durch die IP-Adresse Ihrer LAN-Schnittstelle oder der Schnittstelle, die durch Squid überwacht wird.

  4. Sehen Sie sich die Squid-Protokolle unter /var/log/squid/access.log an, um zu überprüfen, ob alles ordnungsgemäß funktioniert.

36.7 Verwenden der Cache-Manager-CGI von Squid (cachemgr.cgi)

 

Die Cache-Manager-CGI (Common Gateway Interface; cachemgr.cgi) ist ein CGI-Dienstprogramm für die Anzeige der Statistiken zur Arbeitsspeichernutzung eines laufenden Squid-Prozesses. Außerdem bietet er eine bequeme Methode zur Verwaltung des Cache und zur Anzeige der Statistiken ohne Anmeldung beim Server.

Vorgehen 36.2: Einrichten von cachemgr.cgi
 

  1. Stellen Sie sicher, dass der Apache-Webserver auf Ihrem System ausgeführt wird. Konfigurieren Sie Apache, wie in Kapitel 34, Der HTTP-Server Apache beschrieben. Lesen Sie insbesondere Abschnitt 34.5, „Aktivieren von CGI-Skripten“. Um zu überprüfen, ob Apache bereits ausgeführt wird, verwenden Sie: 

    tux > sudo systemctl status apache2

    Wenn inactive angezeigt wird, können Sie Apache mit den Standardeinstellungen von SUSE Linux Enterprise Server starten: 

    tux > sudo systemctl start apache2

  2. Aktivieren Sie nun cachemgr.cgi in Apache. Erstellen Sie hierzu eine Konfigurationsdatei für ein ScriptAlias.

    Erstellen Sie die Datei im Verzeichnis /etc/apache2/conf.d und nennen Sie sie cachemgr.conf. Fügen Sie Folgendes in der Datei hinzu: 

    ScriptAlias /squid/cgi-bin/ /usr/lib64/squid/

<Directory "/usr/lib64/squid/">
Options +ExecCGI
AddHandler cgi-script .cgi
Require host HOST_NAME
</Directory>

    Ersetzen Sie HOSTNAME durch den Hostnamen des Computers, über den Sie auf cachemgr.cgi zugreifen möchten. Dies erlaubt es nur Ihrem Computer, auf cachemgr.cgi zuzugreifen. Um den Zugriff von allen Computern zu erlauben, verwenden Sie stattdessen Require all granted.

    • Wenn Squid und Ihr Apache-Webserver auf demselben Computer ausgeführt werden, sollten keine Änderungen an /etc/squid/squid.conf notwendig sein. Überprüfen Sie jedoch, ob /etc/squid/squid.conf die folgenden Zeilen enthält: 

      http_access allow manager localhost
http_access deny manager

      Diese Zeilen erlauben Ihnen den Zugriff auf die Manager-Schnittstelle über Ihren eigenen Computer (localhost), jedoch nicht über andere Computer.

    • Wenn Squid und Ihr Apache-Webserver auf verschiedenen Computern ausgeführt werden, müssen Sie zusätzliche Regeln hinzufügen, um den Zugriff über das CGI-Skript auf Squid zu erlauben. Geben Sie eine ACL für Ihren Server an (ersetzen Sie WEBSERVER-IP durch die IP-Adresse Ihres Webservers): 

      acl webserver src WEB_SERVER_IP/255.255.255.255

      Stellen Sie sicher, dass die folgenden Regeln in der Konfigurationsdatei enthalten sind. Verglichen mit der Standardkonfiguration ist nur die Regel in der Mitte neu. Jedoch ist die Sequenz wichtig. 

      http_access allow manager localhost
http_access allow manager webserver
http_access deny manager

  4. (Optional) Optional können Sie ein oder mehrere Passwörter für cachemgr.cgi konfigurieren. Dies erlaubt auch den Zugriff auf weitere Aktionen, wie das Schließen des Cache per Fernzugriff oder das Anzeigen weiterer Informationen zum Cache. Konfigurieren Sie hierfür die Optionen cache_mgr und cachemgr_passwd mit einem oder mehreren Passwörtern für den Manager und einer Liste der erlaubten Aktionen.

    Beispiel: Verwenden Sie die folgende Konfiguration, um explizit das Anzeigen der Indexseite, des Menüs und des 60-minütigen Durchschnitts der Zähler ohne Authentifizierung zu aktivieren, das Umschalten des Offline-Modus mithilfe des Passworts secretpassword zu aktivieren und alles andere vollständig zu deaktivieren: 

    cache_mgr user
cachemgr_passwd none index menu 60min
cachemgr_passwd secretpassword offline_toggle
cachemgr_passwd disable all

    cache_mgr legt einen Benutzernamen fest. cache_mgr legt fest, welche Aktionen mit welchen Passwort erlaubt sind.

    Die Schlüsselwörter none und disable haben besondere Eigenschaften: none entfernt die Notwendigkeit eines Passworts, disable inaktiviert die Funktion vollständig.

    Die vollständige Liste der Aktionen finden Sie nach der Anmeldung bei cachemgr.cgi. Wie die Operation in der Konfigurationsdatei zu referenzieren ist, sehen Sie in der Zeichenkette nach &operation= in der URL der Aktionsseite. all ist ein besonderes Schlüsselwort und steht für alle Aktionen.

  5. Laden Sie Squid und Apache neu, nachdem die Konfigurationsdatei geändert wurde: 

    tux > sudo systemctl reload squid

  6. Um die Statistiken anzuzeigen, rufen Sie die Seite cachemgr.cgi auf, die Sie zuvor eingerichtet haben. Diese könnte beispielsweise http://webserver.example.org/squid/cgi-bin/cachemgr.cgi lauten.

    Wählen Sie den richtigen Server und geben Sie, falls dies festgelegt wurde, den Benutzernamen und das Passwort ein. Klicken Sie dann auf Fortsetzen und blättern Sie durch die verschiedenen Statistiken.

36.8 Erstellung von Cache-Berichten mit Calamaris

 

Calamaris ist ein Perl-Skript, mit dem Berichte über die Cache-Aktivität im ASCII- oder HTML-Format erstellt werden können. Es arbeitet mit nativen Squid-Zugriffsprotokolldateien. Die Calamaris-Homepage befindet sich unter http://cord.de/calamaris-english. Dieses Werkzeug gehört nicht zum standardmäßigen Installationsumfang von SUSE Linux Enterprise Server. Zum Verwenden installieren Sie das Paket calamaris.

Melden Sie sich als root an und geben Sie Folgendes ein: 

root # cat access1.log [access2.log access3.log] | calamaris OPTIONS > reportfile

Wenn Sie mehr als eine Protokolldatei verwenden, stellen Sie sicher, dass sie chronologisch geordnet sind, wobei ältere Dateien zuerst aufgelistet werden. Dies können Sie erreichen, indem Sie die Dateien eine nach der anderen wie im Beispiel oben auflisten oder indem Sie access{1..3}.log verwenden.

calamaris erfordert die folgenden Optionen:

-a

Ausgabe aller verfügbaren Berichte

-w

Ausgabe als HTML-Bericht

-l

Einschließen einer Meldung oder eines Logos in den Berichtsheader

Weitere Informationen zu den verschiedenen Optionen finden Sie auf der man-Seite des Programms (mancalamaris.

Typisches Beispiel: 

root # cat access.log.{10..1} access.log | calamaris -a -w \
> /usr/local/httpd/htdocs/Squid/squidreport.html

Dadurch wird der Bericht im Verzeichnis des Webservers gespeichert. Zur Anzeige des Berichts ist Apache erforderlich.

36.9 Weitere Informationen

 

Besuchen Sie die Squid-Homepage unter http://www.squid-cache.org/. Hier finden Sie das „Squid-Benutzerhandbuch“ und eine umfassende Sammlung mit FAQ zu Squid.

Außerdem sind Mailinglisten für Squid unter http://www.squid-cache.org/Support/mailing-lists.html verfügbar.

37 Web Based Enterprise Management mit SFCB

 

37.1 Einführung und grundlegendes Konzept

 

SUSE® Linux Enterprise Server (SLES) stellt eine Sammlung verschiedener, auf offenen Standards beruhender Werkzeuge für die einheitliche Verwaltung unterschiedlicher Computersysteme und -umgebungen bereit. In unseren Unternehmenslösungen sind die von der Distributed Management Task Force vorgeschlagenen Standards implementiert. Deren grundlegenden Komponenten werden in den folgenden Abschnitten beschrieben.

Die Distributed Management Task Force, Inc (DMTF) ist eine industrieführende Organisation, die sich maßgeblich mit der Entwicklung von Verwaltungsstandards für Unternehmens- und Internetumgebungen befasst. Ihr Ziel ist die Vereinheitlichung von Verwaltungsstandards und Verwaltungsinitiativen und damit die Ermöglichung von integrierten, kostengünstigen und auf verschiedenen Systemen einsetzbaren Lösungen. Die DMTF-Standards umfassen allgemeine Systemverwaltungskomponenten für die Steuerung und Kommunikation. Ihre Lösungen sind unabhängig von Plattformen und Technologien. Zu ihren Schlüsseltechnologien gehören unter anderem Web Based Enterprise Management und das Common Information Model.

Web Based Enterprise Management (WBEM) umfasst eine Reihe von Verwaltungs- und Internet-Standardtechnologien. WBEM wurde zur Vereinheitlichung der Verwaltung von Computerumgebungen in Unternehmen entwickelt. Dieser Standard bietet der Industrie die Möglichkeit, eine gut integrierte Sammlung von Verwaltungstools auf Basis von Web-Technologien bereitzustellen. WBEM besteht aus den folgenden Standards:

  • Ein Datenmodell: der Common Information Model-Standard (CIM-Standard)

  • Eine Kodierungsspezifikation: CIM-XML-Kodierungsspezifikation

  • Ein Transportmechanismus: CIM-Vorgänge über HTTP

Das Common Information Model ist ein konzeptuelles Informationsmodell, das die Systemverwaltung beschreibt. Es ist nicht an eine bestimmte Implementierung gebunden und ermöglicht den Austausch von Verwaltungsdaten zwischen Verwaltungssystemen, Netzwerken, Diensten und Anwendungen. CIM umfasst zwei Teile: die CIM-Spezifikation und das CIM-Schema.

  • Die CIM-Spezifikation beschreibt die Sprache, die Namenskonventionen und das Metaschema. Das Metaschema legt die formelle Definition des Modells fest. Es definiert die Begriffe zur Beschreibung des Modells sowie deren Verwendung und Semantik. Die Elemente des Metaschemas sind Klassen, Eigenschaften und Methoden. Das Metaschema unterstützt außerdem Bezeichnungen und Verknüpfungen als Klassentypen und Verweise als Eigenschaftstypen.

  • Das CIM-Schema enthält die eigentlichen Modellbeschreibungen. Es legt einen Klassensatz mit Eigenschaften und Verknüpfungen fest, die ein verständliches konzeptuelles Rahmenwerk bilden, innerhalb dem die verfügbaren Informationen zur verwalteten Umgebung organisiert werden können.

Der Common Information Model Object Manager (CIMOM) ist ein CIM-Objektmanager bzw. eine Anwendung, die Objekte entsprechend den CIM-Standards verwaltet. CIMOM verwaltet die Kommunikation zwischen CIMOM-Anbietern und dem CIM-Client, auf dem der Administrator das System verwaltet.

CIMOM-Anbieter sind Programme, die bestimmte, von den Clientanwendungen angeforderte Aufgaben innerhalb des CIMOM ausführen. Jeder Anbieter stellt ein oder mehrere Aspekte des CIMOM-Schemas bereit. Diese Anbieter interagieren direkt mit der Hardware.

Standards Based Linux Instrumentation for Manageability (SBLIM) ist eine Sammlung von Tools, die zur Unterstützung von Web-Based Enterprise Management (WBEM) entwickelt wurden. SUSE® Linux Enterprise Server nutzt den Open Source-CIMOM (bzw. CIM-Server) des SBLIM-Projekts, den Small Footprint CIM Broker.

Der Small Footprint CIM Broker ist ein CIM-Server für integrierte Umgebungen bzw. für Umgebungen mit eingeschränkten Ressourcen. Bei seiner Entwicklung wurde insbesondere auf einen modulartigen Charakter und eine Lightweight-Struktur geachtet. Er basiert auf offenen Standards und unterstützt CMPI-Anbieter, CIM-XML-Verschlüsselung und das Managed Object Format (MOF). Er lässt sich sehr genau konfigurieren und bietet selbst bei einem Ausfall des Anbieters Stabilität. Außerdem ist er problemlos zugänglich, da er verschiedene Übertragungsprotokolle wie HTTP, HTTPS, Unix Domain Sockets, Service Location Protocol (SLP) und Java Database Connectivity (JDBC) unterstützt.

37.2 Einrichten des SFCB

 

Zum Einrichten der Small Footprint CIM Broker (SFCB)-Umgebung muss in YaST während der Installation von SUSE Linux Enterprise Server das Schema Web-Based Enterprise Management aktiviert sein. Alternativ können Sie das Muster als Komponente auswählen, die auf einem bereits aktiven Server installiert wird. Stellen Sie sicher, dass auf Ihrem System die folgenden Pakete installiert sind:

cim-schema, Common Information Model-Schema (CIM)

Enthält das Common Information Model (CIM). CIM ist ein Modell für die Beschreibung der globalen Verwaltungsinformationen in einer Netzwerk- oder Unternehmensumgebung. CIM besteht aus einer Spezifikation und einem Schema. Die Spezifikation legt die Einzelheiten für die Integration mit anderen Verwaltungsmodellen fest. Das Schema stellt die eigentlichen Modellbeschreibungen bereit.

python2-pywbem

Enthält ein Python-Modul für den Aufruf von CIM-Operationen über das WBEM-Protokoll zur Abfrage und Aktualisierung verwalteter Objekte.

cmpi-provider-register, Dienstprogramm für die CIMOM-neutrale Anbieterregistrierung

Enthält ein Dienstprogramm, das die Registrierung von CMPI-Anbieterpaketen bei jedem auf dem System vorhandenen CIMOM zulässt.

sblim-sfcb, Small Footprint CIM Broker

Enthält den Small Footprint CIM Broker (SFCB). Dies ist ein CIM-Server, der CIM-Operationen über das HTTP-Protokoll unterstützt. Dieser robuste CIM-Server hat einen geringen Ressourcenbedarf und ist daher bestens für integrierte Umgebungen und für Umgebungen mit eingeschränkten Ressourcen geeignet. SFCB unterstützt Anbieter, die für das Common Manageability Programming Interface (CMPI) entwickelt wurden.

sblim-sfcc

Enthält Laufzeitbibliotheken für die Small Footprint CIM Client-Bibliothek.

sblim-wbemcli

Enthält eine WBEM-Kommandozeilenschnittstelle. Dieser eigenständige Kommandozeilen-WBEM-Client eignet sich besonders für grundlegende Systemverwaltungsaufgaben.

37.2.1 Starten und Stoppen von SFCB und Überprüfen des SFCB-Status

 

Der sfcbd-Daemon des CIM-Servers wird gemeinsam mit der Web-Based Enterprise Management-Software installiert und beim Systemstart automatisch gestartet. In folgender Tabelle wird beschrieben, wie der sfcbd-Daemon gestartet, beendet und sein Status überprüft wird.

Tabelle 37.1: Kommandos zur Verwaltung von sfcbd
 

Aufgabe

Linux-Befehl

Starten Sie sfcbd

Geben Sie in der Kommandozeile systemctl start sfcb als root ein.

sfcbd stoppen

Geben Sie in der Kommandozeile systemctl stop sfcb als root ein.

sfcbd-Status prüfen

Geben Sie in der Kommandozeile systemctl status sfcb als root ein.

37.2.2 Absichern des Zugriffs

 

Die Standardkonfiguration von SFCB ist ziemlich sicher. Sie sollten allerdings sicherstellen, dass auch der Zugriff auf die SFCB-Komponenten den Sicherheitsanforderungen Ihres Unternehmens entspricht.

37.2.2.1 Zertifikate

 

Für eine sichere Kommunikation via SSL (Secure Socket Layers) ist ein Zertifikat erforderlich. Bei der Installation von SFCB wird ein eigensigniertes Zertifikat generiert.

Den Pfad auf dieses Standardzertifikat können Sie durch den Pfad eines kommerziellen oder eines anderen eigensignierten Zertifikats ersetzen. Dazu müssen Sie die Einstellung sslCertificateFilePath: PFAD_DATEINAME in der Datei /etc/sfcb/sfcb.cfg ändern. Die Datei muss im PEM-Format vorliegen.

Standardmäßig erwartet SFCB ein Serverzertifikat im folgenden Verzeichnis: 

/etc/sfcb/server.pem

Zum Generieren eines neuen Zertifikats führen Sie folgendes Kommando aus: 

tux > sudo sh /usr/share/sfcb/genSslCert.sh
Generating SSL certificates in .
Generating a 2048 bit RSA private key
...................................................................+++
.+++
writing new private key to '/var/tmp/sfcb.0Bjt69/key.pem'
-----

Das Skript generiert die Zertifikate client.pem, file.pem und server.pem standardmäßig im aktuellen Arbeitsverzeichnis. Wenn die Zertifikate im Verzeichnis /etc/sfcb generiert werden sollen, müssen Sie den Pfad an das Kommando anfügen. Falls diese Dateien bereits vorhanden sind, wird eine Warnung angezeigt, da die alten Zertifikate nicht einfach überschrieben werden können. 

tux > sudo sh /usr/share/sfcb/genSslCert.sh /etc/sfcb
Generating SSL certificates in .
WARNING: server.pem SSL Certificate file already exists.
         old file will be kept intact.
WARNING: client.pem SSL Certificate trust store already exists.
         old file will be kept intact.

Sie müssen die alten Zertifikate aus dem Dateisystem entfernen und das Kommando erneut ausführen.

Weitere Informationen, wie Sie die Verwendung von Zertifikaten durch SFCB verändern, finden Sie unter Abschnitt 37.2.2.3, „Authentifizierung “.

37.2.2.2 Ports

 

Standardmäßig akzeptiert SFCB die gesamte Kommunikation über den sicheren Port 5989. Die folgenden Abschnitte befassen sich mit der Einrichtung des Kommunikationsports und der empfohlenen Konfiguration.

Port 5989 (sicher)

Der sichere Port, den SFCB für die Kommunikation via HTTPS-Dienste verwendet. Dies ist der Standard. Bei dieser Einstellung wird die gesamte Kommunikation zwischen dem CIMOM und den Clientanwendungen für die Internet-Übertragung zwischen Servern und Arbeitsstationen verschlüsselt. Damit Benutzer den SFCB-Server erreichen, müssen sie sich bei der Clientanwendung authentifizieren. Es wird empfohlen, diese Einstellung beizubehalten. In Routern und Firewalls (sofern zwischen Clientanwendung und überwachten Knoten eingerichtet) muss dieser Port offen sein, damit der SFCB CIMOM mit den erforderlichen Anwendungen kommunizieren kann.

Port 5988 (nicht sicher)

Der nicht sichere Port, den SFCB für die Kommunikation via HTTP-Dienste verwendet. Diese Einstellung ist standardmäßig deaktiviert. Bei dieser Einstellung steht die gesamte Kommunikation zwischen dem CIMOM und den Clientanwendungen während der Internet-Übertragung zwischen Servern und Arbeitsstationen jeder Person ohne Authentifizierung offen. Diese Einstellung wird nur für das Debuggen von Problemen mit dem CIMOM empfohlen. Nach der Behebung des Problems sollten Sie diese Portoption sofort wieder deaktivieren. In Routern und Firewalls zwischen Clientanwendung und überwachten Knoten muss dieser Port offen sein, damit der SFCB CIMOM mit Anwendungen, für die ein nicht sicherer Zugriff erforderlich ist, kommunizieren kann.

Weitere Informationen zum Ändern der standardmäßigen Portzuweisungen finden Sie unter Abschnitt 37.2.2.2, „Ports“.

37.2.2.3 Authentifizierung

 

SFCB unterstützt die HTTP-Basisauthentifizierung sowie die Authentifizierung mittels Clientzertifikaten (HTTP über SSL-Verbindungen). Die HTTP-Basisauthentifizierung wird in der SFCB-Konfigurationsdatei (standardmäßig /etc/sfcb/sfcb.cfg) durch Einstellung von doBasicAuth =true aktiviert. Die SUSE® Linux Enterprise Server-Installation von SFCB unterstützt PAM (Pluggable Authentication Modules); der lokale Root-Benutzer kann sich daher mit den lokalen Root-Benutzerberechtigungen beim SFCB CIMOM authentifizieren.

Wenn die Konfigurationseigenschaft sslClientCertificate auf accept oder require gesetzt ist, fordert der SFCB HTTP-Adapter bei einer Verbindung via HTTP über SSL (HTTPS) ein Zertifikat vom Client an. Wenn require eingestellt ist, muss der Client ein gültiges Zertifikat bereitstellen (gemäß dem in sslClientTrustStore angegebenen Trust Store des Clients). Falls der Client kein solches Zertifikat bereitstellt, wird die Verbindung vom CIM-Server abgelehnt.

Die Einstellung sslClientCertificate =accept legt keine eindeutige Authentifizierung fest. Sie ist aber sehr nützlich, wenn sowohl die Authentifizierung mittels Clientzertifikat als auch die Basisauthentifizierung erlaubt sind. Wenn der Client ein gültiges Zertifikat bereitstellen kann, wird eine HTTPS-Verbindung eingerichtet und es findet keine Basisauthentifizierung statt. Wird kein Zertifikat bereitgestellt oder kann dieses nicht verifiziert werden, findet stattdessen die HTTP-Basisauthentifizierung statt.

37.3 SFCB CIMOM-Konfiguration

 

SFCB ist eine Lightweight-Implementierung des CIM-Servers, die aber ebenfalls umfassend konfiguriert werden kann. Ihr Verhalten wird durch verschiedene Optionen gesteuert. Sie können den SFCB-Server mit drei Methoden steuern:

  • durch Einstellen der entsprechenden Umgebungsvariablen

  • mittels Kommandozeilenoptionen

  • durch Änderungen in seiner Konfigurationsdatei

37.3.1 Umgebungsvariablen

 

Verschiedene Umgebungsvariablen wirken sich direkt auf das Verhalten von SFCB aus. Zur Übernahme dieser Änderungen müssen Sie den SFCB-Daemon mit systemctl restart sfcb neu starten.

PFAD

Gibt den Pfad zum Daemon sfcbd und den Dienstprogrammen an.

LD_LIBRARY_PATH

Gibt den Pfad zu den sfcb-Laufzeitbibliotheken an. Alternativ können Sie diesen Pfad zur systemweiten Konfigurationsdatei des dynamischen Ladeprogramms /etc/ld.so.conf hinzufügen.

SFCB_PAUSE_PROVIDER

Gibt den Namen des Anbieters an. Der SFCB-Server wird nach dem erstmaligen Laden des Anbieters angehalten. Dies gibt Ihnen die Gelegenheit, an den Prozess des Anbieters einen Laufzeitdebugger für die Fehlersuche anzuhängen.

SFCB_PAUSE_CODEC

Gibt den Namen des SFCB-Codecs an (unterstützt aktuell nur http. Der SFCB-Server wird nach dem erstmaligen Laden des Codec angehalten. Dies gibt Ihnen die Gelegenheit, an den Prozess einen Laufzeitdebugger anzuhängen.

SFCB_TRACE

Legt die Stufe der Debug-Meldungen für SFCB fest. Gültige Werte sind 0 (keine Debug-Meldungen) bzw. 1 (wichtige Debug-Meldungen) bis 4 (alle Debug-Meldungen). Der Standardwert ist 1.

SFCB_TRACE_FILE

SFCB gibt seine Debug-Meldungen standardmäßig über die Standardfehlerausgabe (STDERR) aus. Mit dieser Variablen können Sie eine andere Datei für die Ausgabe der Debug-Meldungen einstellen.

SBLIM_TRACE

Legt die Stufe der Debug-Meldungen für SBLIM-Anbieter fest. Gültige Werte sind 0 (keine Debug-Meldungen) bzw. 1 (wichtige Debug-Meldungen) bis 4 (alle Debug-Meldungen).

SBLIM_TRACE_FILE

SBLIM-Anbieter geben ihre Debug-Meldungen standardmäßig über STDERR aus. Mit dieser Variablen können Sie eine andere Datei für die Ausgabe der Debug-Meldungen einstellen.

37.3.2 Befehlszeilenoptionen

 

sfcbd Der SFCB-Daemon sfcbd bietet verschiedene Kommandozeilenoptionen, mit denen bestimmte Laufzeitfunktionen ein- und ausgeschaltet werden können. Diese Optionen werden beim Start des SFCB-Daemons eingegeben.

-c, --config-file=DATEI

Beim Start des SFCB-Daemons liest der Daemon seine Konfiguration standardmäßig aus der Datei /etc/sfcb/sfcb.cfg ein. Mit dieser Option können Sie eine andere Konfigurationsdatei angeben.

-d, --daemon

Führt sfcbd und seine untergeordneten Prozesse im Hintergrund aus.

-s, --collect-stats

Aktiviert die Statistikerfassung während der Laufzeit. In diesem Fall werden während der Laufzeit verschiedene sfcbd-Statistiken in die Datei sfcbStat im aktuellen Arbeitsverzeichnis geschrieben. Standardmäßig werden keine Statistiken erfasst.

-l, --syslog-level=PROTOKOLLSTUFE

Bestimmt die Ausführlichkeit für die Systemprotokollierung. PROTOKOLLSTUFE kann LOG_INFO, LOG_DEBUG oder LOG_ERR (Standard) sein.

-k, --color-trace=LOGLEVEL

Druckt die Trace-Ausgabe in unterschiedlichen Farben, was das Debugging erleichtert.

-t, --trace-components=NUMMER

Aktiviert Trace-Meldungen auf Komponentenebene. NUMMER ist dabei ein mit dem logischen Operator OR gebildetes Bitmask-Integer, das festlegt, für welche Komponente ein Trace erstellt werden soll. Mit -t ? können Sie eine Liste sämtlicher Komponenten mit ihren Bitmask-Integern abrufen: 

tux > sfcbd -t ?
---   Traceable Components:     Int       Hex
---            providerMgr:          1  0x0000001
---            providerDrv:          2  0x0000002
---             cimxmlProc:          4  0x0000004
---             httpDaemon:          8  0x0000008
---                upCalls:         16  0x0000010
---               encCalls:         32  0x0000020
---        ProviderInstMgr:         64  0x0000040
---       providerAssocMgr:        128  0x0000080
---              providers:        256  0x0000100
---            indProvider:        512  0x0000200
---       internalProvider:       1024  0x0000400
---             objectImpl:       2048  0x0000800
---                  xmlIn:       4096  0x0001000
---                 xmlOut:       8192  0x0002000
---                sockets:      16384  0x0004000
---              memoryMgr:      32768  0x0008000
---               msgQueue:      65536  0x0010000
---             xmlParsing:     131072  0x0020000
---         responseTiming:     262144  0x0040000
---              dbpdaemon:     524288  0x0080000
---                    slp:    1048576  0x0100000

Ein nützlicher Wert, der Aufschluss über die internen Funktionen von sfcbd gibt, aber nicht zu viele Meldungen generiert, ist -t 2019.

37.3.3 SFCB-Konfigurationsdatei

 

SFCB liest seine Laufzeitkonfiguration nach dem Start aus der Konfigurationsdatei /etc/sfcb/sfcb.cfg ein. Dieses Verhalten kann beim Starten mit der Option -c überschrieben werden.

Die Konfigurationsdatei enthält pro Zeile ein Options-/Wertepaar (Option : WERT). Diese Datei können Sie in jedem Texteditor bearbeiten, der die Datei in einem von der Umgebung unterstützten Format speichert.

Jede Einstellung in dieser Datei, deren Optionen durch ein Nummernzeichen (#) auskommentiert sind, verwendet die Standardeinstellung.

Die folgende Liste enthält möglicherweise nicht alle Optionen. Die vollständige Liste finden Sie im Inhalt von /etc/sfcb/sfcb.cfg und /usr/share/doc/packages/sblim-sfcb/README.

37.3.3.1 httpPort

 

Beschreibung

Gibt die Nummer des lokalen Ports an, den SFCB auf nicht sichere HTTP-Anforderungen von CIM-Clients überwacht. Die Standardeinstellung ist 5988.

Syntax

httpPort: PORTNUMMER

37.3.3.2 enableHttp

 

Beschreibung

Legt fest, ob SFCB HTTP-Clientverbindungen akzeptiert. Die Standardeinstellung ist false.

Syntax

enableHttp: OPTION

Option

Beschreibung

true

Aktiviert HTTP-Verbindungen.

false

Deaktiviert HTTP-Verbindungen.

37.3.3.3 httpProcs

 

Beschreibung

Legt die maximale Anzahl gleichzeitiger HTTP-Clientverbindungen fest, ab der neu eingehende HTTP-Anforderungen blockiert werden. Die Standardeinstellung ist 8.

Syntax

httpProcs: MAX_ANZAHL_VERBINDUNGEN

37.3.3.4 httpUserSFCB, httpUser

 

Beschreibung

Diese Optionen legen fest, unter welchem Benutzer der HTTP- Server ausgeführt wird. Wenn httpUserSFCB auf true gesetzt ist, wird HTTP unter demselben Benutzer ausgeführt wie der SFCB-Hauptprozess. Bei false wird der für httpUser angegebene Benutzername verwendet. Diese Einstellung wird für HTTP- und HTTPS-Server verwendet. httpUser muss angegeben sein, wenn httpUserSFCB auf false gesetzt ist. Die Standardeinstellung ist true.

Syntax

httpUserSFCB: true

37.3.3.5 httpLocalOnly

 

Beschreibung

Gibt an, ob HTTP-Anforderungen auf localhost eingeschränkt werden. Die Standardeinstellung ist false.

Syntax

httpLocalOnly: false

37.3.3.6 httpsPort

 

Beschreibung

Gibt die Nummer des lokalen Ports an, den SFCB auf HTTPS-Anforderungen von CIM-Clients überwacht. Die Standardeinstellung ist 5989.

Syntax

httpsPort: portnummer

37.3.3.7 enableHttps

 

Beschreibung

Legt fest, ob SFCB HTTPS-Clientverbindungen akzeptiert. Die Standardeinstellung ist true .

Syntax

enableHttps: option

Option

Beschreibung

true

Aktiviert HTTPS-Verbindungen.

false

Deaktiviert HTTPS-Verbindungen.

37.3.3.8 httpsProcs

 

Beschreibung

Legt die maximale Anzahl gleichzeitiger HTTPS-Clientverbindungen fest, ab der neu eingehende HTTPS-Anforderungen blockiert werden. Die Standardeinstellung ist 8.

Syntax

httpsProcs: MAX_ANZAHL_VERBINDUNGEN

37.3.3.9 enableInterOp

 

Beschreibung

Legt fest, ob SFCB den interop-Namespace für die Unterstützung von Bezeichnungen bereitstellt. Die Standardeinstellung ist true .

Syntax

enableInterOp: OPTION

Option

Beschreibung

true

Aktiviert den interop-Namespace.

false

Deaktiviert den interop-Namespace.

37.3.3.10 provProcs

 

Beschreibung

Legt die maximale Anzahl gleichzeitiger Anbieterprozesse fest. Wenn nach Erreichen dieser Anzahl eine neu eingehende Anforderung das Laden eines neuen Anbieters erfordert, wird zunächst automatisch einer der vorhandenen Anbieter entladen. Die Standardeinstellung ist 32.

Syntax

provProcs: MAX_ANZAHL_PROZESSE

37.3.3.11 doBasicAuth

 

Beschreibung

Legt fest, ob vor dem Akzeptieren einer Anforderung eine Basisauthentifizierung an der Benutzer-ID des Clients durchgeführt wird. Die Standardeinstellung ist true, d. h. für den Client wird die Basisauthentifizierung durchgeführt.

Syntax

doBasicAuth: OPTION

Option

Beschreibung

true

Aktiviert die Basisauthentifizierung.

false

Deaktiviert die Basisauthentifizierung.

37.3.3.12 basicAuthLib

 

Beschreibung

Gibt den Namen der lokalen Bibliothek an. Der SFCB-Server lädt die Bibliothek zur Authentifizierung der Benutzer-ID des Clients. Die Standardeinstellung ist sfcBasicPAMAuthentication.

Syntax

provProcs: MAX_ANZAHL_PROZESSE

37.3.3.13 useChunking

 

Beschreibung

Diese Option aktiviert bzw. deaktiviert die Verwendung von HTTP/HTTPS-„Chunking“. Wenn aktiviert, gibt der Server große Mengen an Antwortdaten an den Client in kleineren „Chunks“ zurück, statt sie im Puffer zu sammeln und auf einmal zurückzusenden. Die Standardeinstellung ist true .

Syntax

useChunking: OPTION

Option

Beschreibung

true

Aktiviert HTTP/HTTPS-Daten-Chunking.

false

Deaktiviert HTTP/HTTPS-Daten-Chunking.

37.3.3.14 keepaliveTimeout

 

Beschreibung

Legt die maximale Zeit in Sekunden fest, die der SFCB-HTTP-Prozess innerhalb einer Verbindung auf die nächste Anforderung wartet, bevor er beendet wird. Bei der Einstellung 0 wird HTTP-Keep-Alive deaktiviert. Die Standardeinstellung ist 0.

Syntax

keepaliveTimeout: SEKUNDEN

37.3.3.15 keepaliveMaxRequest

 

Beschreibung

Legt die maximale Anzahl aufeinanderfolgender Anforderungen innerhalb einer Verbindung fest. Bei der Einstellung 0 wird HTTP-Keep-Alive deaktiviert. Die Standardeinstellung ist 10.

Syntax

keepaliveMaxRequest: ANZAHL_VERBINDUNGEN

37.3.3.16 registrationDir

 

Beschreibung

Gibt das Registrierungsverzeichnis an, das die Registrierungsdaten der Anbieter, den Staging-Bereich und das statische Repository enthält. Die Standardeinstellung ist /var/lib/sfcb/registration.

Syntax

registrationDir: VERZEICHNIS

37.3.3.17 providerDirs

 

Beschreibung

Gibt eine durch Leerzeichen getrennte Liste mit Verzeichnissen an, die SFCB nach Anbieterbibliotheken durchsucht. Die Standardeinstellung ist /usr/lib64 /usr/lib64 /usr/lib64/cmpi.

Syntax

providerDirs: VERZEICHNIS

37.3.3.18 providerSampleInterval

 

Beschreibung

Legt das Intervall in Sekunden fest, in dem der Anbietermanager nach unbeschäftigten Anbietern sucht. Die Standardeinstellung ist 30.

Syntax

providerSampleInterval: SEKUNDEN

37.3.3.19 providerTimeoutInterval

 

Beschreibung

Legt die Zeit in Sekunden fest, nach der ein unbeschäftigter Anbieter vom Anbietermanager entladen wird. Die Standardeinstellung ist 60.

Syntax

providerTimeoutInterval: SEKUNDEN

37.3.3.20 providerAutoGroup

 

Beschreibung

Sofern in der Registrierungsdatei des Anbieters keine andere Gruppe angegeben ist und diese Option auf true gesetzt ist, werden alle Anbieter der gleichen gemeinsam genutzten Bibliothek im gleichen Prozess ausgeführt.

Syntax

providerAutoGroup: OPTION

Option

Beschreibung

true

Aktiviert die Gruppierung von Anbietern.

false

Deaktiviert die Gruppierung von Anbietern.

37.3.3.21 sslCertificateFilePath

 

Beschreibung

Gibt den Namen der Datei an, die das Serverzertifikat enthält. Die Datei muss im PEM-Format vorliegen (Privacy Enhanced Mail, RFC 1421 und RFC 1424). Diese Datei ist nur erforderlich, wenn enableHttps auf true gesetzt ist. Die Standardeinstellung ist /etc/sfcb/server.pem.

Syntax

sslCertificateFilePath: PFAD

37.3.3.22 sslKeyFilePath

 

Beschreibung

Gibt den Namen der Datei an, die den privaten Schlüssel für das Serverzertifikat enthält. Die Datei muss im PEM-Format vorliegen und darf nicht durch einen Passwortsatz geschützt sein. Diese Datei wird nur benötigt, wenn enableHttps auf true gesetzt ist. Die Standardeinstellung ist /etc/sfcb/file.pem.

Syntax

sslKeyFilePath: PFAD

37.3.3.23 sslClientTrustStore

 

Beschreibung

Gibt den Namen der Datei an, die die von der Zertifizierungsstelle ausgegebenen oder eigensignierten Zertifikate der Clients enthält. Die Datei muss im PEM-Format vorliegen, ist aber nur erforderlich, wenn sslClientCertificate auf accept oder require gesetzt ist. Die Standardeinstellung ist /etc/sfcb/client.pem.

Syntax

sslClientTrustStore: PFAD

37.3.3.24 sslClientCertificate

 

Beschreibung

Legt fest, wie SFCB die Authentifizierung auf Basis von Clientzertifikaten handhabt. Bei ignore wird kein Zertifikat vom Client angefordert. Bei accept wird zwar ein Zertifikat vom Client angefordert, die Authentifizierung schlägt jedoch nicht fehl, wenn der Client keines bereitstellt. Bei require wird die Clientverbindung abgelehnt, wenn der Client kein gültiges Zertifikat bereitstellt. Die Standardeinstellung ist ignore.

Syntax

sslClientCertificate: OPTION

Option

Beschreibung

ignore

Deaktiviert die Anforderung eines Clientzertifikats.

Akzeptieren

Aktiviert die Anforderung eines Clientzertifikats.

Schlägt jedoch nicht fehl, wenn kein Zertifikat bereitgestellt wird.

require

Lehnt die Clientverbindung ab, wenn kein gültiges Zertifikat bereitgestellt wird.

37.3.3.25 certificateAuthLib

 

Beschreibung

Gibt den Namen der lokalen Bibliothek an, mit deren Hilfe die Benutzerauthentifizierung auf Basis des Clientzertifikats durchgeführt wird. Die Benutzerauthentifizierung findet nur statt, wenn sslClientCertificate nicht auf ignore gesetzt ist. Die Standardeinstellung ist sfcCertificateAuthentication.

Syntax

certificateAuthLib: DATEI

37.3.3.26 traceLevel

 

Beschreibung

Legt die Trace-Stufe für SFCB fest. Diese Einstellung kann durch die Umgebungsvariable SFCB_TRACE_LEVEL überschrieben werden. Die Standardeinstellung ist 0.

Syntax

traceLevel: NUMMER_DER_STUFE

37.3.3.27 traceMask

 

Beschreibung

Legt die Trace-Maske für SFCB fest. Diese Einstellung kann durch die Kommandozeilenoption --trace-components überschrieben werden. Die Standardeinstellung ist 0.

Syntax

traceMask: MASKE

37.3.3.28 traceFile

 

Beschreibung

Legt die Trace-Datei für SFCB fest. Diese Einstellung kann durch die Umgebungsvariable SFCB_TRACE_FILE überschrieben werden. Die Standardeinstellung ist stderr (Standardfehlerausgabe).

Syntax

traceFile: AUSGABE

37.4 Erweiterte SFCB-Tasks

 

In diesem Kapitel werden erweiterte Tasks in Verbindung mit SFCB behandelt. Zu deren Verständnis benötigen Sie grundlegende Kenntnisse des Linux-Dateisystems und Erfahrungen mit der Linux-Kommandozeile. In diesem Kapitel werden folgende Tasks beschrieben:

  • Installieren von CMPI-Anbietern

  • Testen von SFCB

  • Verwenden des CIM-Clients wbemcli

37.4.1 Installieren von CMPI-Anbietern

 

Zur Installation eines CMPI-Anbieters müssen Sie seine gemeinsam genutzte Bibliothek in eines der von der Konfigurationsoption providerDirs angegebenen Verzeichnisse kopieren (siehe Abschnitt 37.3.3.17, „providerDirs“). Außerdem muss der Anbieter korrekt mit den Kommandos sfcbstage und sfcbrepos registriert werden.

Das Anbieterpaket ist in der Regel für SFCB vorbereitet. Bei seiner Installation wird also darauf geachtet, dass der Anbieter korrekt registriert wird. Die meisten SBLIM-Anbieter sind für SFCB vorbereitet.

37.4.1.1 Klassenrepository

 

Das Klassenrepository ist der Ort, an dem SFCB Informationen über die CIM-Klassen speichert. Es besteht in der Regel aus einem Verzeichnisbaum mit Namespace-Komponenten. Typische CIM-Namespaces sind root/cimv2 oder root/interop, die in der Regel mit den entsprechenden Verzeichnispfaden des Klassenrepositorys im Dateisystem übereinstimmen:

/var/lib/sfcb/registration/repository/root/cimv2

und

/var/lib/sfcb/registration/repository/root/interop

Jedes Namespace-Verzeichnis enthält die Datei classSchemas. Die Datei enthält eine kompilierte binäre Darstellung aller CIM-Klassen, die unter diesem Namespace registriert sind. Außerdem enthält sie die erforderlichen Informationen über deren CIM-Unterklassen.

Darüber hinaus kann jedes Namespace-Verzeichnis eine Datei mit dem Namen qualifiers enthalten, die alle Qualifizierer des Namespace enthält. Beim Neustart von sfcbd untersucht der Klassenanbieter das Verzeichnis /var/lib/sfcb/registration/repository/ und seine Unterverzeichnisse, um festzustellen, welche Namespaces registriert sind. Danach werden die classSchemas-Dateien entschlüsselt und die Klassenhierarchien der einzelnen Namespaces erstellt.

37.4.1.2 Hinzufügen neuer Klassen

 

SFCB kann CIM-Klassen nicht online ändern. Zum Hinzufügen, Ändern oder Entfernen von Klassen müssen Sie offline sein und den SFCB-Dienst anschließend mit systemctl restart sfcb neu starten, damit die Änderungen registriert werden.

Zum Speichern der Klassen- und Registrierungsdaten der Anbieter verwendet SFCB einen Zwischenspeicher, den so genannten Staging-Bereich. Auf SUSE® Linux Enterprise Server-Systemen ist dies die Verzeichnisstruktur unter /var/lib/sfcb/stage/.

Zum Hinzufügen eines neuen Anbieters führen Sie die folgenden Schritte aus:

  • Kopieren Sie die Definitionsdateien mit den Anbieterklassen in das Unterverzeichnis ./mofs des Staging-Verzeichnisses (/var/lib/sfcb/stage/mofs).

  • Kopieren Sie die Registrierungsdatei mit den Namen der Klassen, dem Anbietertyp und dem Namen der ausführbaren Bibliotheksdatei in das Unterverzeichnis ./regs.

Das Staging-Verzeichnis enthält zwei Standard-„mof“-Dateien (Klassendefinitionen): indication.mof und interop.mof. Die MOF-Dateien unter dem Root-Staging-Verzeichnis /var/lib/sfcb/stage/mofs müssen nach der Ausführung des Kommandos sfcbrepos in jeden Namespace kopiert werden. Die Datei interop.mof muss nur in den interop-Namespace kompiliert werden.

Das Verzeichnislayout kann dann wie folgt aussehen: 

tux > ls /var/lib/sfcb/stage
default.reg  mofs  regs
tux > ls /var/lib/sfcb/stage/mofs
indication.mof  root
tux > ls /var/lib/sfcb/stage/mofs/root
cimv2  interop  suse  virt
tux > ls -1 /var/lib/sfcb/stage/mofs/root/cimv2 | less
Linux_ABIParameter.mof
Linux_BaseIndication.mof
Linux_Base.mof
Linux_DHCPElementConformsToProfile.mof
Linux_DHCPEntity.mof
[..]
OMC_StorageSettingWithHints.mof
OMC_StorageVolumeDevice.mof
OMC_StorageVolume.mof
OMC_StorageVolumeStorageSynchronized.mof
OMC_SystemStorageCapabilities.mof
tux > ls -1 /var/lib/sfcb/stage/mofs/root/interop
ComputerSystem.mof
ElementConformsToProfile.mof
HostSystem.mof
interop.mof
Linux_DHCPElementConformsToProfile.mof
[..]
OMC_SMIElementSoftwareIdentity.mof
OMC_SMISubProfileRequiresProfile.mof
OMC_SMIVolumeManagementSoftware.mof
ReferencedProfile.mof
RegisteredProfile.mof
tux > ls -1 /var/lib/sfcb/stage/regs
AllocationCapabilities.reg
Linux_ABIParameter.reg
Linux_BaseIndication.reg
Linux_DHCPGlobal.reg
Linux_DHCPRegisteredProfile.reg
[..]
OMC_Base.sfcb.reg
OMC_CopyServices.sfcb.reg
OMC_PowerManagement.sfcb.reg
OMC_Server.sfcb.reg
RegisteredProfile.reg
tux > cat /var/lib/sfcb/stage/regs/Linux_DHCPRegisteredProfile.reg
[Linux_DHCPRegisteredProfile]
   provider: Linux_DHCPRegisteredProfileProvider
   location: cmpiLinux_DHCPRegisteredProfile
   type: instance
   namespace: root/interop
#
[Linux_DHCPElementConformsToProfile]
   provider: Linux_DHCPElementConformsToProfileProvider
   location: cmpiLinux_DHCPElementConformsToProfile
   type: instance association
   namespace: root/cimv2
#
[Linux_DHCPElementConformsToProfile]
   provider: Linux_DHCPElementConformsToProfileProvider
   location: cmpiLinux_DHCPElementConformsToProfile
   type: instance association
   namespace: root/interop

SFCB verwendet für jeden Anbieter eine angepasste Anbieterregistrierungsdatei.

Anmerkung
Anmerkung: Registrierungsdateien von SBLIM-Anbietern

Alle SBLIM-Anbieter der SBLIM-Website enthalten bereits eine Registrierungsdatei, die zur Generierung der für SFCB benötigten .reg-Datei verwendet wird.

Das Format der SFCB-Registrierungsdatei sieht wie folgt aus: 

[<class-name>]
   provider: <provide-name>
   location: <library-name>
   type: [instance] [association] [method] [indication]
   group: <group-name>
   unload: never
   namespace: <namespace-for-class> ...

wobei:

<klassenname>

Der Name der CIM-Klasse (erforderlich)

<anbietername>

Der Name des CMPI-Anbieters (erforderlich)

<standortname>

Der Name der Anbieterbibliothek (erforderlich)

type

Der Typ des Anbieters (erforderlich). Hier kann es sich um jede Kombination der folgenden Typen handeln: Instanz, Verknüpfung, Methode oder Bezeichnung.

<gruppenname>

Zur Minimierung der benötigten Laufzeitressourcen können mehrere Anbieter zu Gruppen zusammengefasst und unter einem einzigen Prozess ausgeführt werden. Alle unter dem gleichen <gruppennamen> registrierten Anbieter werden unter dem gleichen Prozess ausgeführt. Standardmäßig wird jeder Anbieter als separater Prozess ausgeführt.

unload

Legt die Richtlinie zum Entladen des Anbieters fest. Zur Zeit wird nur die Option never (nie) unterstützt. Es wird also nicht überprüft, ob der Anbieter leerläuft, er wird daher auch nicht entladen. Standardmäßig wird ein Anbieter dann entladen, wenn er das in der Konfigurationsdatei angegebene Leerlaufzeitlimit überschreitet.

namespace

Eine Liste der Namespaces, für die dieser Anbieter ausgeführt werden kann. Die Liste ist erforderlich, auch wenn hier für die meisten Anbieter root/cimv2 angegeben werden kann.

Wenn sich alle Klassendefinitionen und Anbieterregistrierungsdateien im Staging-Bereich befinden, müssen Sie das SFCB-Klassenrepository mit dem Kommando sfcbrepos -f neu erstellen.

Auf diese Weise können Sie Klassen hinzufügen, ändern oder entfernen. Nach der Neuerstellung des Klassenrepositorys müssen Sie SFCB mit dem Kommando systemctl restart sfcb neu starten.

Als Alternative enthält das SFCB-Paket ein Dienstprogramm, mit dem die MOF-Klassen- und Registrierungsdateien der Anbieter in die richtigen Verzeichnisse des Staging-Bereichs kopiert werden können.

sfcbstage -r [anbieter.reg] [klasse1.mof] [klasse2.mof] ...

Auch nach Ausführung dieses Kommandos müssen Sie das Klassenrepository neu erstellen und den SFCB-Dienst neu starten.

37.4.2 Testen von SFCB

 

Das SFCB-Paket enthält die beiden Testskripte wbemcat und xmltest.

wbemcat sendet CIM-XML-Raw-Daten via HTTP-Protokoll an den angegebenen SFCB-Host (standardmäßig „localhost“), der Port 5988 überwacht. Danach zeigt es die zurückgegebenen Ergebnisse an. Die folgende Datei enthält die CIM-XML-Darstellung einer EnumerateClasses-Standardanforderung: 

<?xml version="1.0" encoding="utf-8"?>
<CIM CIMVERSION="2.0" DTDVERSION="2.0">
  <MESSAGE ID="4711" PROTOCOLVERSION="1.0">
    <SIMPLEREQ>
      <IMETHODCALL NAME="EnumerateClasses">
        <LOCALNAMESPACEPATH>
          <NAMESPACE NAME="root"/>
          <NAMESPACE NAME="cimv2"/>
        </LOCALNAMESPACEPATH>
        <IPARAMVALUE NAME="ClassName">
          <CLASSNAME NAME=""/>
        </IPARAMVALUE>
        <IPARAMVALUE NAME="DeepInheritance">
          <VALUE>TRUE</VALUE>
        </IPARAMVALUE>
        <IPARAMVALUE NAME="LocalOnly">
          <VALUE>FALSE</VALUE>
        </IPARAMVALUE>
        <IPARAMVALUE NAME="IncludeQualifiers">
          <VALUE>FALSE</VALUE>
        </IPARAMVALUE>
        <IPARAMVALUE NAME="IncludeClassOrigin">
          <VALUE>TRUE</VALUE>
        </IPARAMVALUE>
      </IMETHODCALL>
    </SIMPLEREQ>
  </MESSAGE>
</CIM>

Wenn diese Anforderung an den SFCB CIMOM gesendet wird, gibt sie eine Liste aller unterstützten Klassen zurück, für die Anbieter registriert sind. Sie speichern die Datei nun zum Beispiel unter dem Dateinamen cim_xml_test.xml. 

tux > wbemcat cim_xml_test.xml | less
HTTP/1.1 200 OK
Content-Type: application/xml; charset="utf-8"
Content-Length: 337565
Cache-Control: no-cache
CIMOperation: MethodResponse

<?xml version="1.0" encoding="utf-8" ?>
<CIM CIMVERSION="2.0" DTDVERSION="2.0">
<MESSAGE ID="4711" PROTOCOLVERSION="1.0">
<SIMPLERSP>
<IMETHODRESPONSE NAME="EnumerateClasses">
[..]
<CLASS NAME="Linux_DHCPParamsForEntity" SUPERCLASS="CIM_Component">
<PROPERTY.REFERENCE NAME="GroupComponent" REFERENCECLASS="Linux_DHCPEntity">
</PROPERTY.REFERENCE>
<PROPERTY.REFERENCE NAME="PartComponent" REFERENCECLASS="Linux_DHCPParams">
</PROPERTY.REFERENCE>
</CLASS>
</IRETURNVALUE>
</IMETHODRESPONSE>
</SIMPLERSP>
</MESSAGE>
</CIM>

Welche Klassen aufgelistet werden, richtet sich nach den auf Ihrem System installierten Anbietern.

Auch das zweite Skript xmltest sendet eine CIM-XML-Raw-Testdatei an den SFCB CIMOM. Danach vergleicht es die zurückgegebenen Ergebnisse mit einer zuvor gespeicherten „OK“-Ergebnisdatei. Falls noch keine passende „OK“-Datei vorhanden ist, wird diese für den späteren Gebrauch erstellt: 

tux > xmltest cim_xml_test.xml
Running test cim_xml_test.xml ... OK
        Saving response as cim_xml_test.OK
root # xmltest cim_xml_test.xml
Running test cim_xml_test.xml ... Passed

37.4.3 CIM-Kommandozeilenclient: wbemcli

 

Neben wbemcat und xmltest enthält das SBLIM-Projekt den erweiterten CIM-Kommandozeilenclient wbemcli. Der Client sendet CIM-Anforderungen an den SFCB-Server und zeigt die zurückgegebenen Ergebnisse an. Er ist unabhängig von der CIMOM-Bibliothek und kann mit allen WBEM-konformen Implementierungen verwendet werden.

Wenn Sie zum Beispiel alle von den auf Ihrem SFCB registrierten SBLIM-Anbietern implementierten Klassen auflisten wollen, senden Sie eine „EnumerateClasses“-Anforderung (siehe Beispiel) an den SFCB: 

tux > wbemcli -dx ec http://localhost/root/cimv2
To server: <?xml version="1.0" encoding="utf-8" ?>
<CIM CIMVERSION="2.0" DTDVERSION="2.0">
<MESSAGE ID="4711" PROTOCOLVERSION="1.0"><SIMPLEREQ><IMETHODCALL \
    NAME="EnumerateClasses"><LOCALNAMESPACEPATH><NAMESPACE NAME="root"> \
    </NAMESPACE><NAMESPACE NAME="cimv2"></NAMESPACE> \
    </LOCALNAMESPACEPATH>
<IPARAMVALUE NAME="DeepInheritance"><VALUE>TRUE</VALUE> \
    </IPARAMVALUE>
<IPARAMVALUE NAME="LocalOnly"><VALUE>FALSE</VALUE></IPARAMVALUE>
<IPARAMVALUE NAME="IncludeQualifiers"><VALUE>FALSE</VALUE> \
    </IPARAMVALUE>
<IPARAMVALUE NAME="IncludeClassOrigin"><VALUE>TRUE</VALUE> \
    </IPARAMVALUE>
</IMETHODCALL></SIMPLEREQ>
</MESSAGE></CIM>
From server: Content-Type: application/xml; charset="utf-8"
From server: Content-Length: 337565
From server: Cache-Control: no-cache
From server: CIMOperation: MethodResponse
From server: <?xml version="1.0" encoding="utf-8" ?>
<CIM CIMVERSION="2.0" DTDVERSION="2.0">
<MESSAGE ID="4711" PROTOCOLVERSION="1.0">
<SIMPLERSP>
<IMETHODRESPONSE NAME="EnumerateClasses">
<IRETURNVALUE>
<CLASS NAME="CIM_ResourcePool" SUPERCLASS="CIM_LogicalElement">
<PROPERTY NAME="Generation" TYPE="uint64">
</PROPERTY>
<PROPERTY NAME="ElementName" TYPE="string">
</PROPERTY>
<PROPERTY NAME="Description" TYPE="string">
</PROPERTY>
<PROPERTY NAME="Caption" TYPE="string">
</PROPERTY>
<PROPERTY NAME="InstallDate" TYPE="datetime">
</PROPERTY>
[..]
<CLASS NAME="Linux_Ext4FileSystem" SUPERCLASS="CIM_UnixLocalFileSystem">
<PROPERTY NAME="FSReservedCapacity" TYPE="uint64">
</PROPERTY>
<PROPERTY NAME="TotalInodes" TYPE="uint64">
</PROPERTY>
<PROPERTY NAME="FreeInodes" TYPE="uint64">
</PROPERTY>
<PROPERTY NAME="ResizeIncrement" TYPE="uint64">
<VALUE>0</VALUE>
</PROPERTY>
<PROPERTY NAME="IsFixedSize" TYPE="uint16">
<VALUE>0</VALUE>
</PROPERTY>
[..]

Die Option -dx zeigt den tatsächlichen XML-Text an, der von wbemcli an den SFCB gesendet wurde, und den tatsächlich zurückgegebenen XML-Text. Im oben gezeigten Beispiel wurde als erste von zahlreichen Klassen CIM_ResourcePool zurückgegeben, gefolgt von Linux_Ext4FileSystem. Ähnliche Einträge werden auch für alle anderen registrierten Klassen zurückgegeben.

Ohne die Option -dx zeigt wbemcli lediglich eine kompakte Darstellung der zurückgegebenen Daten an: 

tux > wbemcli ec http://localhost/root/cimv2
localhost:5988/root/cimv2:CIM_ResourcePool Generation=,ElementName=, \
    Description=,Caption=,InstallDate=,Name=,OperationalStatus=, \
    StatusDescriptions=,Status=,HealthState=,PrimaryStatus=, \
    DetailedStatus=,OperatingStatus=,CommunicationStatus=,InstanceID=, \
    PoolID=,Primordial=,Capacity=,Reserved=,ResourceType=, \
    OtherResourceType=,ResourceSubType=, \AllocationUnits=
localhost:5988/root/cimv2:Linux_Ext4FileSystem FSReservedCapacity=, \
    TotalInodes=,FreeInodes=,ResizeIncrement=,IsFixedSize=,NumberOfFiles=, \
    OtherPersistenceType=,PersistenceType=,FileSystemType=,ClusterSize=, \
    MaxFileNameLength=,CodeSet=,CasePreserved=,CaseSensitive=, \
    CompressionMethod=,EncryptionMethod=,ReadOnly=,AvailableSpace=, \
    FileSystemSize=,BlockSize=,Root=,Name=,CreationClassName=,CSName=, \
    CSCreationClassName=,Generation=,ElementName=,Description=,Caption=, \
    InstanceID=,InstallDate=,OperationalStatus=,StatusDescriptions=, \
    Status=,HealthState=,PrimaryStatus=,DetailedStatus=,OperatingStatus= \
    ,CommunicationStatus=,EnabledState=,OtherEnabledState=,RequestedState= \
    ,EnabledDefault=,TimeOfLastStateChange=,AvailableRequestedStates=, \
    TransitioningToState=,PercentageSpaceUse=
    [..]

37.5 Weitere Informationen

 
Weitere Informationen zu WBEM und SFCB finden Sie auf folgenden Websites:
 
https://www.dmtf.org

Website der Distributed Management Task Force

https://www.dmtf.org/standards/wbem/

Website zu Web-Based Enterprise Management (WBEM)

https://www.dmtf.org/standards/cim/

Website zu Common Information Model (CIM)

http://sblim.sourceforge.net/wiki/index.php/Main_Page

Website zu Standards Based Linux Instrumentation (SBLIM)

Teil V Fehlersuche

 
  • 38 Hilfe und Dokumentation

    • Im Lieferumfang von SUSE® Linux Enterprise Server sind verschiedene Informationen und Dokumentationen enthalten, viele davon bereits in Ihr installiertes System integriert.

  • 39 Erfassen der Systeminformationen für den Support

    • Das Paket hostinfo in SUSE Linux Enterprise Server ermöglicht einen raschen Überblick über alle relevanten Systeminformationen eines Computers. Hier können Systemadministratoren außerdem ermitteln, ob ein Computer unbrauchbare (nicht unterstützte) Kernels enthält oder ob Drittanbieterpakete installiert sind.

    Bei Problemen wird ein detaillierter Systembericht mit dem Kommandozeilenwerkzeug supportconfig oder mit dem YaST-Support-Modul erzeugt. Beide Werkzeuge sammeln Informationen zum System, etwa aktuelle Kernel-Version, Hardware, installierte Pakete, Partitionseinrichtung und einiges mehr. Hierbei wird ein TAR-Archiv mit Dateien ausgegeben. Wenn Sie eine Service-Anforderung öffnen, können Sie das TAR-Archiv für den globalen technischen Support heraufladen. Der Support hilft Ihnen, das gemeldete Problem zu lokalisieren und zu beheben.

    Darüber hinaus können Sie die supportconfig-Ausgabe auf bekannte Probleme hin analysieren und so die Fehlerbehebung noch beschleunigen. SUSE Linux Enterprise Server bietet hierzu eine Anwendung und ein Kommandozeilenwerkzeug für die supportconfig-Analyse (SCA).

  • 40 Häufige Probleme und deren Lösung

    • In diesem Kapitel werden mögliche Probleme und deren Lösungen beschrieben. Auch wenn Ihre Situation nicht genau auf die hier beschriebenen Probleme zutreffen mag, finden Sie vielleicht einen ähnlichen Fall, der Ihnen Hinweise zur Lösung Ihres Problems liefert.

38 Hilfe und Dokumentation

 

Im Lieferumfang von SUSE® Linux Enterprise Server sind verschiedene Informationen und Dokumentationen enthalten, viele davon bereits in Ihr installiertes System integriert.

Dokumentation unter /usr/share/doc

Dieses traditionelle Hilfe-Verzeichnis enthält verschiedene Dokumentationsdateien sowie die Hinweise zur Version Ihres Systems. Außerdem enthält es Informationen über die im Unterverzeichnis packages installierten Pakete. Weitere Informationen finden Sie unter Abschnitt 38.1, „Dokumentationsverzeichnis“.

man-Seiten und Infoseiten für Shell-Kommandos

Wenn Sie mit der Shell arbeiten, brauchen Sie die Optionen der Kommandos nicht auswendig zu kennen. Die Shell bietet normalerweise eine integrierte Hilfefunktion mit man-Seiten und Infoseiten. Weitere Informationen dazu finden Sie unter Abschnitt 38.2, „Man Pages“ und Abschnitt 38.3, „Infoseiten“.

Desktop-Hilfezentrum

Das Hilfezentrum des GNOME-Desktops (Hilfe) bietet zentralen Zugriff auf die wichtigsten Dokumentationsressourcen auf Ihrem System in durchsuchbarer Form. Zu diesen Ressourcen zählen die Online-Hilfe für installierte Anwendungen, man-Seiten, Infoseiten sowie die mit Ihrem Produkt gelieferten SUSE-Handbücher.

Separate Hilfepakete für einige Anwendungen

Beim Installieren von neuer Software mit YaST wird die Softwaredokumentation in der Regel automatisch installiert und in der Hilfe auf Ihrem Desktop angezeigt. Jedoch können einige Anwendungen, beispielsweise GIMP, über andere Online-Hilfepakete verfügen, die separat mit YaST installiert werden können und nicht in die Hilfe integriert werden.

38.1 Dokumentationsverzeichnis

 

Das traditionelle Verzeichnis zum Suchen von Dokumentationen in Ihrem installierten Linux-System finden Sie unter /usr/share/doc. Das Verzeichnis enthält normalerweise Informationen zu den auf Ihrem System installierten Paketen sowie Versionshinweise, Handbücher usw.

Anmerkung
Anmerkung: Inhalte abhängig von installierten Paketen

In der Linux-Welt stehen Handbücher und andere Dokumentationen in Form von Paketen zur Verfügung, ähnlich wie Software. Wie viele und welche Informationen Sie unter /usr/share/docs finden, hängt auch von den installierten (Dokumentations-) Paketen ab. Wenn Sie die hier genannten Unterverzeichnisse nicht finden können, prüfen Sie, ob die entsprechenden Pakete auf Ihrem System installiert sind, und fügen Sie sie gegebenenfalls mithilfe von YaST hinzu.

38.1.1 SUSE-Handbücher

 

Wir stellen Ihnen unsere Handbücher in verschiedenen Sprachen in den Formaten HTML und PDF zur Verfügung. Im Unterverzeichnis Handbuch finden Sie HTML-Versionen der meisten für Ihr Produkt verfügbaren SUSE-Handbücher. Eine Übersicht über sämtliche für Ihr Produkt verfügbare Dokumentation finden Sie im Vorwort der Handbücher.

Wenn mehr als eine Sprache installiert ist, enthält /usr/share/doc/manual möglicherweise verschiedene Sprachversionen der Handbücher. Die HTML-Versionen der SUSE-Handbücher stehen auch in der Hilfe an beiden Desktops zur Verfügung. Informationen zum Speicherort der PDF- und HTML-Versionen des Handbuchs auf Ihrem Installationsmedium finden Sie in den Versionshinweisen zu SUSE Linux Enterprise Server. Sie stehen auf Ihrem installierten System unter /usr/share/doc/release-notes/ oder online auf Ihrer produktspezifischen Webseite unter https://www.suse.com/releasenotes// zur Verfügung.

38.1.2 Dokumentation zu den einzelnen Paketen

 

Im Verzeichnis packages befindet sich die Dokumentation zu den auf Ihrem System installierten Software-Paketen. Für jedes Paket wird das entsprechende Unterverzeichnis /usr/share/doc/packages/Paketname erstellt. Es enthält README-Dateien für das Paket und manchmal Beispiele, Konfigurationsdateien und zusätzliche Skripten. In der folgenden Liste werden die typischen Dateien vorgestellt, die unter /usr/share/doc/packages zu finden sind. Diese Einträge sind nicht obligatorisch, und viele Pakete enthalten möglicherweise nur einige davon.

AUTOREN

Liste der wichtigsten Entwickler.

BUGS

Bekannte Programmfehler oder Fehlfunktionen. Enthält möglicherweise auch einen Link zur Bugzilla-Webseite, auf der alle Programmfehler aufgeführt sind.

CHANGES , ChangeLog

Diese Datei enthält eine Übersicht der in den einzelnen Versionen vorgenommenen Änderungen. Die Datei dürfte nur für Entwickler interessant sein, da sie sehr detailliert ist.

COPYING , LICENSE

Lizenzinformationen.

FAQ

Mailing-Listen und Newsgroups entnommene Fragen und Antworten.

INSTALL

So installieren Sie dieses Paket auf Ihrem System. Da das Paket bereits installiert ist, wenn Sie diese Datei lesen können, können Sie den Inhalt dieser Datei bedenkenlos ignorieren.

README, README.*

Allgemeine Informationen zur Software, z. B. Zweck und Verwendung.

TODO

Diese Datei beschreibt Funktionen, die in diesem Paket noch nicht implementiert, jedoch für spätere Versionen vorgesehen sind.

MANIFEST

Diese Datei enthält eine Übersicht über die im Paket enthaltenen Dateien.

NEWS

Beschreibung der Neuerungen in dieser Version.

38.2 Man Pages

 

man-Seiten sind ein wichtiger Teil des Linux-Hilfesystems. Sie erklären die Verwendung der einzelnen Befehle und deren Optionen und Parameter. Sie greifen auf man-Seiten mit dem Befehl man gefolgt vom Namen des jeweiligen Befehls zu, z. B. man ls.

Die man-Seiten werden direkt in der Shell angezeigt. Blättern Sie mit den Tasten Bild ↑ und Bild ↓ nach oben bzw. unten. Mit Pos 1 und Ende gelangen Sie an den Anfang bzw. das Ende eines Dokuments. und mit Q schließen Sie die man-Seiten. Weitere Informationen über den Befehl man erhalten Sie durch Eingabe von man man. man-Seiten sind in Kategorien unterteilt, wie in Tabelle 38.1, „man-Seiten – Kategorien und Beschreibungen“ gezeigt (diese Einteilung wurde direkt von der man-Seite für den Befehl „man“ übernommen).

Tabelle 38.1: man-Seiten – Kategorien und Beschreibungen
 

Nummer

Beschreibung

1

Ausführbare Programme oder Shell-Befehle

2

Systemaufrufe (vom Kernel bereitgestellte Funktionen)

3

Bibliotheksaufrufe (Funktionen in Programmbibliotheken)

4

Spezielle Dateien (gewöhnlich in /dev)

5

Dateiformate und Konventionen (/etc/fstab)

6

Spiele

7

Sonstiges (wie Makropakete und Konventionen), zum Beispiel man(7) oder groff(7)

8

Systemverwaltungsbefehle (in der Regel nur für root)

9

Nicht standardgemäße Kernel-Routinen

Jede man-Seite besteht aus den Abschnitten NAME, SYNOPSIS, DESCRIPTION, SEE ALSO, LICENSING und AUTHOR. Je nach Befehlstyp stehen möglicherweise auch weitere Abschnitte zur Verfügung.

38.3 Infoseiten

 

Eine weitere wichtige Informationsquelle sind Infoseiten. Diese sind im Allgemeinen ausführlicher als man-Seiten. Hier finden Sie nicht nur die Kommandozeilenoptionen, sondern manchmal sogar ganze Lernprogramme oder Referenzdokumentation. Die Infoseite für einen bestimmten Befehl zeigen Sie an, indem Sie info gefolgt vom Namen des Befehls eingeben, z. B. info ls. Infoseiten werden direkt in der Shell in einem Viewer angezeigt, in dem Sie zwischen den verschiedenen Abschnitten, so genannten „Knoten, navigieren können“. Mit Leertaste blättern Sie vorwärts und mit <— zurück. Innerhalb eines Knotens können Sie auch mit Bild ↑ und Bild ↓ navigieren, jedoch gelangen Sie nur mit Leertaste und <— zum vorherigen bzw. nächsten Knoten. Drücken Sie Q, um den Anzeigemodus zu beenden. Nicht für jedes Kommando gibt es eine Infoseite und umgekehrt.

38.4 Online-Ressourcen

 

Zusätzlich zu den Online-Versionen der SUSE-Handbücher, die unter /usr/share/doc installiert sind, können Sie auch auf die produktspezifischen Handbücher und Dokumentationen im Internet zugreifen. Eine Übersicht über alle Dokumentationen für SUSE Linux Enterprise Server erhalten Sie auf der produktspezifischen Dokumentations-Website unter https://documentation.suse.com/.

Wenn Sie zusätzliche produktbezogene Informationen suchen, können Sie auch die folgenden Websites besuchen:

Technischer Support von SUSE

Falls Sie Fragen haben oder Hilfe bei technischen Problemen benötigen, steht der technische Support von SUSE unter https://www.suse.com/support/ bereit.

SUSE-Foren

Es gibt verschiedene Foren, in denen Sie sich an Diskussionen über SUSE-Produkte beteiligen können. Eine Liste finden Sie in https://forums.suse.com/.

SUSE-Blog

Im SUSE-Blog finden Sie Artikel, Tipps sowie Fragen und Antworten: https://www.suse.com/c/blog/

GNOME-Dokumentation

Dokumentation für GNOME-Benutzer, -Administratoren und -Entwickler finden Sie unter https://library.gnome.org/.

Das Linux-Dokumentationsprojekt

Das Linux-Dokumentationsprojekt (TLDP) ist eine auf freiwilliger Mitarbeit beruhende Gemeinschaftsinitiative zur Erarbeitung von Linux-Dokumentationen und Veröffentlichungen zu verwandten Themen (siehe https://www.tldp.org). Dies ist die wahrscheinlich umfangreichste Dokumentationsressource für Linux. Sie finden dort durchaus Lernprogramme, die auch für Anfänger geeignet sind, doch hauptsächlich richten sich die Dokumente an erfahrene Benutzer, zum Beispiel an professionelle Systemadministratoren. Das Projekt veröffentlicht HOWTOs (Verfahrensbeschreibungen), FAQs (Antworten zu häufigen Fragen) sowie ausführliche Handbücher und stellt diese unter einer kostenlosen Lizenz zur Verfügung. Ein Teil der TLDP-Dokumentation ist auch unter SUSE Linux Enterprise Server verfügbar.

Sie können auch allgemeine Such-Engines ausprobieren. Sie können beispielsweise die Suchbegriffe Linux CD-RW Hilfe oder OpenOffice Dateikonvertierung eingeben, wenn Sie Probleme mit dem Brennen von CDs bzw. mit der LibreOffice-Dateikonvertierung haben.

39 Erfassen der Systeminformationen für den Support

 

Das Paket hostinfo in SUSE Linux Enterprise Server ermöglicht einen raschen Überblick über alle relevanten Systeminformationen eines Computers. Hier können Systemadministratoren außerdem ermitteln, ob ein Computer unbrauchbare (nicht unterstützte) Kernels enthält oder ob Drittanbieterpakete installiert sind.

Bei Problemen wird ein detaillierter Systembericht mit dem Kommandozeilenwerkzeug supportconfig oder mit dem YaST-Support-Modul erzeugt. Beide Werkzeuge sammeln Informationen zum System, etwa aktuelle Kernel-Version, Hardware, installierte Pakete, Partitionseinrichtung und einiges mehr. Hierbei wird ein TAR-Archiv mit Dateien ausgegeben. Wenn Sie eine Service-Anforderung öffnen, können Sie das TAR-Archiv für den globalen technischen Support heraufladen. Der Support hilft Ihnen, das gemeldete Problem zu lokalisieren und zu beheben.

Darüber hinaus können Sie die supportconfig-Ausgabe auf bekannte Probleme hin analysieren und so die Fehlerbehebung noch beschleunigen. SUSE Linux Enterprise Server bietet hierzu eine Anwendung und ein Kommandozeilenwerkzeug für die supportconfig-Analyse (SCA).

39.1 Anzeigen aktueller Systeminformationen

 

Mit dem Paket hostinfo erhalten Sie schnell und einfach eine Übersicht über alle relevanten Systeminformationen, sobald Sie sich bei einem Server anmelden. Nach der Installation auf einem Computer zeigt die Konsole die folgenden Informationen für jeden root-Benutzer an, der sich bei diesem Computer anmeldet:

Beispiel 39.1: Ausgabe von hostinfo beim Anmelden als root
 
Welcome to SUSE Linux Enterprise Server 15 SP2 Snapshot8 (x86_64) - Kernel \r (\l).


Distribution:             SUSE Linux Enterprise Server 15 SP2
Current As Of:            Wed 25 Mar 2020 12:09:20 PM PDT
Hostname:                 localhost
Kernel Version:           5.3.18-8-default
 Architecture:            x86_64
 Installed:               Thu 19 Mar 2020 11:25:13 AM PDT
 Status:                  Not Tainted
Last Installed Package:   Wed 25 Mar 2020 11:42:24 AM PDT
 Patches Needed:          0
 Security:                0
 3rd Party Packages:      219
Network Interfaces
 eth0:                    192.168.2/24 2002:c0a8:20a::/64
Memory
 Total/Free/Avail:        7.4Gi/6.4Gi/6.8Gi (91% Avail)
CPU Load Average:         7 (3%) with 2 CPUs

Wenn die Ausgabe auf einen unbrauchbaren Kernel-Status hinweist, finden Sie weitere Details in Abschnitt 39.6, „Unterstützung für Kernelmodule“.

39.2 Erfassen von Systeminformationen mit supportconfig

 

Ein TAR-Archiv mit ausführlichen Systeminformationen, die Sie an den globalen technischen Support übertragen können, erstellen Sie entweder:

  • mit dem Kommando supportconfig oder

  • mit dem YaST-Support-Modul.

Das Kommandozeilenwerkzeug wird im Paket supportutils bereitgestellt, das standardmäßig installiert ist. Das YaST-Support-Modul baut zudem auf dem Kommandozeilenwerkzeug auf.

Je nachdem, welche Pakete auf Ihrem System installiert sind, werden mit einem Teil dieser Pakete außerdem Supportconfig-Plugins integriert. Beim Ausführen von Supportconfig werden auch alle Plugins ausgeführt, wobei mindestens eine Ergebnisdatei für das Archiv erstellt wird. Dies hat den Vorteil, dass nur die Themen überprüft werden, die ein spezielles Plugin enthalten. Die Supportconfig-Plugins werden im Verzeichnis /usr/lib/supportconfig/plugins/ gespeichert.

39.2.1 Erstellen einer Serviceanforderungsnummer

 

supportconfig-Archive können jederzeit erzeugt werden. Wenn Sie die Supportconfig-Daten an den globalen technischen Support übertragen möchten, müssen Sie jedoch zunächst eine Service-Anforderungs-Nummer erstellen. Diese Nummer benötigen Sie, um das Archiv an den Support heraufladen zu können.

Zum Erstellen einer Service-Anforderung wechseln Sie zu https://scc.suse.com/support/requests, und befolgen Sie die Anweisungen auf dem Bildschirm. Notieren Sie die Serviceanforderungsnummer.

Anmerkung
Anmerkung: Datenschutzerklärung

SUSE behandelt Systemberichte als vertrauliche Daten. Weitere Informationen zum Datenschutz finden Sie unter https://www.suse.com/company/policies/privacy/.

39.2.2 Upload-Ziele

 

Sobald Sie eine Service-Anforderungs-Nummer erstellt haben, können Sie Ihre Supportconfig-Archive gemäß den Anweisungen in Prozedur 39.1, „Übertragen von Informationen an den Support mithilfe von YaST“ oder Prozedur 39.2, „Übertragen von Informationen an den Support über die Kommandozeile“ an den globalen technischen Support hochladen. Verwenden Sie eines der folgenden Upload-Ziele:

Alternativ können Sie das TAR-Archiv auch an Ihre Service-Anforderung anhängen und die URL für Service-Anforderungen verwenden: https://scc.suse.com/support/requests.

39.2.3 Erstellen eines supportconfig-Archivs mit YaST

 

Gehen Sie wie folgt vor, wenn Sie Ihre Systeminformationen mithilfe von YaST erfassen möchten:

  1. Starten Sie YaST, und öffnen Sie das Support-Modul.

    Image

  2. Klicken Sie auf Berichts-Tarball erstellen.

  3. Wählen Sie im nächsten Fenster eine der Supportconfig-Optionen in der Optionsliste aus. Die Option Benutzerdefinierte Einstellungen (für Experten) verwenden ist standardmäßig aktiviert. Wenn Sie die Berichtfunktion zuerst testen möchten, verwenden Sie Nur eine minimale Anzahl von Informationen sammeln. Zusätzliche Informationen zu den weiteren Optionen finden Sie auf der man-Seite zu supportconfig.

    Drücken Sie Weiter.

  4. Geben Sie Ihre Kontaktdaten ein. Sie sind in der Datei basic-environment.txt gespeichert und im erstellten Archiv enthalten.

  5. Geben Sie zum Senden das Archivs an den globalen technischen Support die erforderlichen Upload-Informationen an. YaST schlägt automatisch einen Upload-Server vor. Falls Sie einen anderen verwenden möchten, finden Sie detaillierte Informationen zu den verfügbaren Upload-Servern in Abschnitt 39.2.2, „Upload-Ziele“.

    Lassen Sie das Feld für Upload-Informationen leer, falls Sie das Archiv später senden möchten.

  6. Drücken Sie zum Starten des Vorgangs der Informationserfassung auf Weiter.

    Image

    Drücken Sie nach Ende des Vorgangs auf Weiter.

  7. Wählen Sie zum Prüfen der erfassten Daten die gewünschte Datei unter Dateiname aus, um den Inhalt in YaST anzuzeigen. Mit der Option Aus Daten entfernen entfernen Sie eine Datei aus dem TAR-Archiv, bevor Sie es an den Support senden. Drücken Sie Weiter.

  8. Speichern Sie das TAR-Archiv. Wenn Sie das YaST-Modul als root-Benutzer gestartet haben, fordert YaST standardmäßig dazu auf, das Archiv unter /var/log zu speichern (ansonsten in Ihrem Basisverzeichnis). Das Format des Dateinamens lautet scc_HOST_DATE_TIME.tbz.

  9. Zum Heraufladen des Archivs direkt an den Support muss die Option Protokolldatei-Tarball an URL hochladen aktiviert sein. Hier ist das Upload-Ziel angegeben, das YaST in Schritt 5 vorgeschlagen hat. Prüfen Sie in Abschnitt 39.2.2, „Upload-Ziele“, welche Upload-Server verfügbar sind, bevor Sie das Upload-Ziel ändern.

  10. Deaktivieren Sie die Option Protokolldatei-Tarball zu URL heraufladen, um den Upload zu überspringen.

  11. Bestätigen Sie die Änderungen, um das YaST-Modul zu schließen.

39.2.4 Erstellen eines supportconfig-Archivs über die Kommandozeile

 

Mit dem nachstehenden Verfahren erstellen Sie ein Supportconfig-Archiv, ohne das Archiv direkt an den Support zu übertragen. Zum Heraufladen müssen Sie das entsprechende Kommando mit den zugehörigen Optionen ausführen (siehe Prozedur 39.2, „Übertragen von Informationen an den Support über die Kommandozeile“).

  1. Öffnen Sie eine Shell und melden Sie sich als root an.

  2. Führen Sie supportconfig aus. In der Regel reicht es aus, dieses Tool ohne Optionen auszuführen. Die folgende Liste zeigt einige häufig verwendete Optionen:

    -E MAIL, -N NAME, -O UNTERNEHMEN, -P TELEFON

    Legt Ihre Kontaktangaben fest: Email-Adresse (-E), Unternehmensname (-O), Ihr Name (-N) und Ihre Telefonnummer (-P).

    -i SCHLÜSSELWÖRTER, -F

    Schränkt die zu überprüfenden Funktionen ein. Der Platzhalter SCHLÜSSELWÖRTER steht für eine Liste von Schlüsselwörtern, die jeweils durch Komma voneinander getrennt werden müssen und bei denen zwischen Groß- und Kleinschreibung unterschieden wird. Mit supportconfig -F erhalten Sie eine Liste aller Schlüsselwörter.

    -r SRNUMMER

    Definiert die Nummer Ihrer Service-Anforderung, wenn Sie das erzeugte TAR-Archiv hochladen.

  3. Warten Sie, bis das Tool den Vorgang beendet hat.

  4. Der Standardspeicherort für das Archiv befindet sich unter /var/log und hat das Dateinamenformat scc_HOST_DATE_TIME.tbz.

39.2.5 Informationen zur Ausgabe von supportconfig

 

supportconfig gibt eine Zusammenfassung der erledigten Aktionen zurück, unabhängig davon, ob Sie das Skript über YaST oder direkt ausführen. 

                     Support Utilities - Supportconfig
                          Script Version: 3.0-98 
                          Script Date: 2017 06 01
[...]
Gathering system information
  Data Directory:    /var/log/scc_d251_180201_1525 1

  Basic Server Health Check...                 Done 2
  RPM Database...                              Done 2
  Basic Environment...                         Done 2
  System Modules...                            Done 2
[...]
  File System List...                          Skipped 3
[...]
  Command History...                           Excluded 4
[...]
  Supportconfig Plugins:                       1 5
    Plugin: pstree...                          Done
[...]
Creating Tar Ball

==[ DONE ]===================================================================
  Log file tar ball: /var/log/scc_d251_180201_1525.txz 6
  Log file size:     732K
  Log file md5sum:   bf23e0e15e9382c49f92cbce46000d8b
=============================================================================

1

Das temporäre Verzeichnis, in dem die Ergebnisse gespeichert werden. Dieses Verzeichnis wird als tar-Datei archiviert (siehe 6).

2

Die Funktion wurde (standardmäßig oder manuell) aktiviert und wurde erfolgreich ausgeführt. Das Ergebnis wird in einer Datei gespeichert (siehe Tabelle 39.1, „Vergleich der Funktionen und Dateinamen im TAR-Archiv“).

3

Die Funktion wurde übersprungen, weil einige Dateien in mindestens einem RPM-Paket geändert wurden.

4

Die Funktion wurde ausgeschlossen, weil ihre Auswahl mit der Option -x aufgehoben wurde.

5

Das Skript hat ein Plugin gefunden und führt das Plugin pstree aus. Das Plugin wurde im Verzeichnis /usr/lib/supportconfig/plugins/ gefunden. Weitere Informationen hierzu finden Sie auf der man-Seite.

6

Der tar-Dateiname des Archivs, das standardmäßig mit xz komprimiert wird.

39.2.6 Allgemeine Optionen für Supportconfig

 

Das Dienstprogramm supportconfig wird in der Regel ohne Optionen aufgerufen. Zeigen Sie mit eine Liste aller Optionen für supportconfig mit -h an oder lesen Sie die man-Seite. Die folgende Liste enthält eine kurze Übersicht einiger gängiger Fälle:

Vermindern des Umfangs der erfassten Informationen

Verwenden Sie die Minimal-Option (-m): 

tux > sudo supportconfig -m
Begrenzen der Informationen auf ein bestimmtes Thema

Wenn Sie bereits ein Problem festgestellt haben, das auf einen bestimmten Bereich oder eine bestimmte Funktionsgruppe beschränkt ist, sollten Sie die erfassten Informationen beim nächsten Ausführen von supportconfig auf diesen Bereich begrenzen. Sie haben beispielsweise Probleme mit LVM festgestellt und möchten nun eine Änderung testen, die Sie kürzlich an der LVM-Konfiguration vorgenommen haben. In diesem Fall sollten Sie nur die mindestens erforderlichen Supportconfig-Informationen zu LVM zusammenstellen: 

tux > sudo supportconfig -i LVM

Zusätzliche Schlüsselwörter können jeweils durch Komma getrennt werden. Beispielsweise ein zusätzlicher Festplattentest: 

tux > sudo supportconfig -i LVM,DISK

Eine vollständige Liste der Funktionsschlüsselwörter, mit denen Sie die erfassten Informationen auf einen bestimmten Bereich begrenzen, erhalten Sie mit dem: 

tux > sudo supportconfig -F
Aufnehmen zusätzlicher Kontaktinformationen in die Ausgabe:
tux > sudo supportconfig -E tux@example.org -N "Tux Penguin" -O "Penguin Inc." ...

(alle in einer Zeile)

Sammeln von bereits rotierten Protokolldateien
tux > sudo supportconfig -l

Nützlich ist dies insbesondere in Umgebungen mit hohem Protokollierungsaufkommen sowie nach einem Kernel-Crash, wenn syslog die Protokolldateien nach dem Neustart rotiert.

39.2.7 Überblick über den Archivinhalt

 

Das TAR-Archiv enthält alle Ergebnisse der Funktionen. Die Anzahl der Dateien im Archiv ist abhängig von der ursprünglichen Auswahl (alles oder nur ein kleiner Teil). Der Funktionsset kann mit der Option -i eingeschränkt werden (siehe Abschnitt 39.2.6, „Allgemeine Optionen für Supportconfig“).

Mit dem folgenden tar-Kommando rufen Sie eine Liste des Archivinhalts ab: 

root # tar xf /var/log/scc_earth_180131_1545.tbz

Die folgenden Dateinamen sind stets im TAR-Archiv verfügbar:

Mindestens im Archiv enthaltene Dateien
 
basic-environment.txt

Datum, an dem dieses Skript ausgeführt wurde, sowie Systeminformationen wie die Version der Distribution, Hypervisor-Informationen und vieles mehr.

basic-health-check.txt

Grundlegende Integritätsprüfungen, z. B. Betriebszeit, Statistiken zum virtuellen Speicher, freier Arbeits- und Festplattenspeicher, Prüfungen auf „Zombie-Prozesse“ und vieles mehr.

hardware.txt

Grundlegende Hardware-Prüfungen, z. B. Informationen zur CPU-Active Directory, Liste der gesamten angeschlossenen Hardware, Interrupts, E/A-Ports, Kernel-Bootmeldungen und vieles mehr.

messages.txt

Enthält Protokollmeldungen vom Systemjournal.

rpm.txt

Liste aller installierten RPM-Pakete mit Name, Ursprung und Version.

summary.xml

Informationen im XML-Format, z. B. Distribution, Version und produktspezifische Fragmente.

supportconfig.txt

Informationen zum Skript supportconfig selbst.

y2log.txt

YaST-spezifische Informationen, z. B. spezielle Pakete, Konfigurationsdateien und Protokolldateien.

Tabelle 39.1, „Vergleich der Funktionen und Dateinamen im TAR-Archiv“ zeigt eine Liste aller verfügbaren Funktionen und ihrer Dateinamen. Weitere Service Packs und Plugins können die Liste noch erweitern.

Tabelle 39.1: Vergleich der Funktionen und Dateinamen im TAR-Archiv
 
FunktionDateiname
APPARMORsecurity-apparmor.txt
AUDITsecurity-audit.txt
AUTOFSfs-autofs.txt
BOOTboot.txt
BTRFSfs-btrfs.txt
DAEMONSsystemd.txt
CIMOMcimom.txt
CRASHcrash.txt
CRONcron.txt
DHCPdhcp.txt
DISKfs-diskio.txt
DNSdns.txt
DOCKERdocker.txt
DRBDdrbd.txt
ENVenv.txt
ETCetc.txt
HAha.txt
HAPROXYhaproxy.txt
HISTORYshell_history.txt
IBib.txt
IMANnovell-iman.txt
ISCSIfs-iscsi.txt
LDAPldap.txt
LIVEPATCHkernel-livepatch.txt
LVMlvm.txt
MEMmemory.txt
MODmodules.txt
MPIOmpio.txt
NETnetwork-*.txt
NFSnfs.txt
NTPntp.txt
NVMEnvme.txt
OCFS 2ocfs2.txt
OFILESopen-files.txt
PRINTprint.txt
PROCproc.txt
SARsar.txt
SLERTslert.txt
SLPslp.txt
SMTsmt.txt
SMARTfs-smartmon.txt
SMBsamba.txt
SRAIDfs-softraid.txt
SSHssh.txt
SSSDsssd.txt
SYSCONFIGsysconfig.txt
SYSFSsysfs.txt
TRANSACTIONALtransactional-update.txt
TUNEDtuned.txt
UDEVudev.txt
UFILESfs-files-additional.txt
UPupdates.txt
WEBweb.txt
Xx.txt

39.3 Übertragen von Informationen an den globalen technischen Support

 

Zum Übertragen der Systeminformationen an den globalen technischen Support verwenden Sie das YaST-Support-Modul oder das Befehlszeilenprogramm supportconfig. Falls Serverprobleme auftreten und Sie Hilfe benötigen, müssen Sie zunächst eine Serviceanforderung öffnen. Weitere Informationen finden Sie unter Abschnitt 39.2.1, „Erstellen einer Serviceanforderungsnummer“.

In den nachfolgenden Beispielen fungiert die Zahl 12345678901 als Platzhalter für die Service-Anforderungs-Nummer. Ersetzen Sie die Zahl 12345678901 durch die Service-Anforderungs-Nummer, die Sie in Abschnitt 39.2.1, „Erstellen einer Serviceanforderungsnummer“ erstellt haben.

Vorgehen 39.1: Übertragen von Informationen an den Support mithilfe von YaST
 

Im nachfolgenden Verfahren wird angenommen, dass Sie bereits ein Supportconfig-Archiv erstellt, jedoch noch nicht heraufgeladen haben. Nehmen Sie in jedem Fall Ihre Kontaktdaten in das Archiv auf (siehe Abschnitt 39.2.3, „Erstellen eines supportconfig-Archivs mit YaST“, Schritt 4). Weitere Anweisungen zum Erzeugen und Übertragen eines Supportconfig-Archivs in einem einzigen Arbeitsgang finden Sie in Abschnitt 39.2.3, „Erstellen eines supportconfig-Archivs mit YaST“.

  1. Starten Sie YaST, und öffnen Sie das Support-Modul.

  2. Klicken Sie auf Heraufladen.

  3. Geben Sie unter Paket mit Protokolldateien den Pfad zum vorhandenen Supportconfig-Archiv ein, oder klicken Sie auf Durchsuchen, und wechseln Sie zu dem Ordner, in dem sich das Archiv befindet.

  4. YaST schlägt automatisch einen Upload-Server vor. Wenn Sie diesen Server ändern möchten, erfahren Sie in Abschnitt 39.2.2, „Upload-Ziele“, welche Upload-Server verfügbar sind.

    Image

    Fahren Sie mit Weiter fort.

  5. Klicken Sie auf Finish (Fertig stellen).

Vorgehen 39.2: Übertragen von Informationen an den Support über die Kommandozeile
 

Im nachfolgenden Verfahren wird angenommen, dass Sie bereits ein Supportconfig-Archiv erstellt, jedoch noch nicht heraufgeladen haben. Weitere Anweisungen zum Erzeugen und Übertragen eines Supportconfig-Archivs in einem einzigen Arbeitsgang finden Sie in Abschnitt 39.2.3, „Erstellen eines supportconfig-Archivs mit YaST“.

  1. Server mit Internetkonnektivität:

    1. Führen Sie das folgende Kommando aus, um das Standard-Uploadziel zu verwenden: 

      tux > sudo supportconfig -ur 12345678901

    2. Verwenden Sie das folgende sichere Upload-Ziel: 

      tux > sudo supportconfig -ar 12345678901

  2. Server ohne Internetkonnektivität

    1. Führen Sie Folgendes aus: 

      tux > sudo supportconfig -r 12345678901

    2. Laden Sie das Archiv /var/log/scc_SR12345678901*tbz manuell auf einen unserer FTP-Server herauf. Der richtige Server ist abhängig von Ihrem Standort. Einen Überblick finden Sie unter Abschnitt 39.2.2, „Upload-Ziele“.

  3. Sobald das TAR-Archiv im Eingangsverzeichnis unseres FTP-Servers eingeht, wird es automatisch an Ihre Service-Anforderung angehängt.

39.4 Analysieren von Systeminformationen

 

Die mit supportconfig erstellten Systemberichte können auf bekannte Probleme hin analysiert werden, so dass die Fehlerbehebung noch beschleunigt wird. SUSE Linux Enterprise Server bietet hierzu eine Anwendung und ein Kommandozeilenwerkzeug für die supportconfig-Analyse (SCA). Die SCA-Appliance ist ein serverseitiges, nicht interaktives Werkzeug. Das SCA-Werkzeug (scatool wird vom Paket sca-server-reportbereitgestellt) wird auf Client-Seite von der Kommandozeile aus ausgeführt. Beide Werkzeuge analysieren die Supportconfig-Archive von betroffenen Servern. Die erste Serveranalyse erfolgt in der SCA-Appliance oder auf dem Arbeitsplatzrechner, auf dem scatool ausgeführt wird. Auf dem Produktionsserver werden keine Analysezyklen durchgeführt.

Sowohl für die Appliance als auch für das Kommandozeilenwerkzeug sind zusätzliche produktspezifische Schemata erforderlich, damit die Supportconfig-Ausgabe für die entsprechenden Produkte analysiert werden kann. Jedes Schema ist ein Skript, mit dem ein Supportconfig-Archiv auf genau ein bekanntes Problem hin analysiert und ausgewertet wird. Die Schemata stehen als RPM-Pakete zur Verfügung.

Sie können außerdem eigene Schemata entwickeln (kurze Beschreibung siehe Abschnitt 39.4.3, „Entwickeln von benutzerdefinierten Analyseschemata“).

39.4.1 SCA-Kommandozeilenwerkzeug

 

Mithilfe des SCA-Kommandozeilenwerkzeugs können Sie einen lokalen Rechner sowohl mit supportconfig als auch mit den auf dem lokalen Rechner installierten Analyseschemata analysieren. Das Werkzeug erstellt einen HTML-Bericht mit den Analyseergebnissen. Ein Beispiel finden Sie in Abbildung 39.1, „Mit dem SCA-Werkzeug erstellter HTML-Bericht“.

Mit dem SCA-Werkzeug erstellter HTML-Bericht
Abbildung 39.1: Mit dem SCA-Werkzeug erstellter HTML-Bericht
 

Das Kommando scatoolwird mit dem Paket sca-server-report Paket verfügbar ist. Die Installation erfolgt nicht standardmäßig. Außerdem benötigen Sie das Paket sca-patterns-base und die produktspezifischen Pakete sca-patterns-* für das Produkt, das auf dem Computer installiert ist, auf dem das Kommando scatool ausgeführt werden soll.

Führen Sie das Kommando scatool als root-Benutzer oder mit sudo aus. Beim Aufrufen des SCA-Werkzeugs können Sie wahlweise ein vorhandenes supportconfig-TAR-Archiv analysieren oder auch ein neues Archiv erzeugen und im gleichen Arbeitsgang analysieren. Das Werkzeug bietet außerdem eine interaktive Konsole zum Ausfüllen der Registerkarten. Sie können supportconfig auf einem externen Computer und die nachfolgende Analyse dann auf dem lokalen Computer ausführen.

Einige Kommandobeispiele:

sudo scatool -s

Ruft supportconfig auf und erzeugt ein neues Supportconfig-Archiv auf dem lokalen Rechner. Analysiert das Archiv auf bekannte Probleme mithilfe der passenden SCA-Analyseschemata für das installierte Produkt. Zeigt den Pfad zum HTML-Bericht an, der aus den Analyseergebnissen erzeugt wird. Der Bericht wird in der Regel in dasselbe Verzeichnis geschrieben wie das Supportconfig-Archiv.

sudo scatool -s -o /opt/sca/reports/ 

Wie sudo scatool -s, mit dem Unterschied, dass der HTML-Bericht in den mit der Option -o angegebenen Pfad geschrieben wird.

sudo scatool -a PFAD_ZU_TARBALL_ODER_VERZEICHNIS 

Analysiert die angegebene Supportconfig-Archivdatei (oder das angegebene Verzeichnis, in das das Supportconfig-Archiv extrahiert wurde). Der erzeugte HTML-Bericht wird an demselben Speicherort gespeichert wie das Supportconfig-Archiv oder -Verzeichnis.

sudo scatool -a SLES_SERVER.COMPANY.COM 

Stellt eine SSH-Verbindung zu einem externen Server SLES_SERVER.COMPANY.COM her und führt Supportconfig auf dem Server aus. Das Supportconfig-Archiv wird dann auf den lokalen Rechner zurückkopiert und dort analysiert. Der erzeugte HTML-Bericht wird standardmäßig in das Verzeichnis /var/log gespeichert. (Auf dem Server SLES_SERVER.COMPANY.COM wird ausschließlich das Supportconfig-Archiv erstellt.)

sudo scatool -c

Startet die interaktive Konsole für scatool. Zum Abrufen der verfügbaren Kommandos drücken Sie zweimal →|.

Weitere Optionen und Informationen erhalten Sie mit dem Kommando sudo scatool -h und auf der man-Seite zu scatool.

39.4.2 SCA-Appliance

 

Wenn Sie die Supportconfig-Archive mit der SCA-Appliance analysieren, konfigurieren Sie einen dedizierten Server (oder einen dedizierten virtuellen Computer) als SCA-Appliance-Server. Auf dem SCA-Appliance-Server können Sie dann Supportconfig-Archive von allen Rechnern im Unternehmen analysieren, auf denen SUSE Linux Enterprise Server oder SUSE Linux Enterprise Desktop ausgeführt wird. Zum Analysieren laden Sie die gewünschten Supportconfig-Archive einfach auf den Appliance-Server herauf. Ein weiterer Eingriff Ihrerseits ist nicht erforderlich. In einer MariaDB-Datenbank verfolgt die SCA-Appliance alle bereits analysierten Supportconfig-Archive. Sie können die SCA-Berichte direkt über die Webschnittstelle der Appliance lesen. Alternativ können Sie in der Appliance angeben, dass der HTML-Bericht per Email an einen verwaltungsbefugten Benutzer gesendet werden soll. Weitere Informationen finden Sie unter Abschnitt 39.4.2.5.4, „Senden von SCA-Berichten per Email“.

39.4.2.1 Installationsschnellanleitung

 

Zum raschen Installieren und Einrichten der SCA-Appliance über die Kommandozeile gehen Sie nach den folgenden Anweisungen vor. Das Verfahren richtet sich an fortgeschrittene Benutzer und umfasst lediglich die reinen Installations- und Einrichtungskommandos. Weitere Informationen finden Sie in der detaillierteren Beschreibung in Abschnitt 39.4.2.2, „Voraussetzungen“ bis Abschnitt 39.4.2.3, „Installation und grundlegende Einrichtung“.

Voraussetzungen
 

  • Web- und LAMP-Schema

  • Web- und Skripterstellungsmodul (zur Auswahl dieses Moduls muss der Rechner registriert sein).

Anmerkung
Anmerkung: Erforderliche root-Berechtigungen

Alle Befehle im folgenden Vorgang müssen als root ausgeführt werden.

Vorgehen 39.3: Installation mit Heraufladen über anonymen FTP-Zugang
 

Sobald die Appliance eingerichtet ist und ausgeführt wird, sind keine weiteren manuellen Eingriffe mehr erforderlich. Diese Methode zur Einrichtung der Appliance eignet sich daher ideal für das Erstellen und Heraufladen von Supportconfig-Archiven mithilfe von Cron-Aufträgen.

  1. Melden Sie sich auf dem Rechner, auf dem die Appliance installiert werden soll, bei einer Konsole an und führen Sie folgende Kommandos aus (akzeptieren Sie dabei auf jeden Fall die empfohlenen Pakete): 

    tux > sudo zypper install sca-appliance-* sca-patterns-* \
vsftpd yast2 yast2-ftp-server
tux > sudo systemctl enable apache2
tux > sudo systemctl start apache2
tux > sudo systemctl enable vsftpd
tux > sudo systemctl start vsftpd
tux > sudo yast ftp-server

  2. Wählen Sie im YaST-FTP-Server-Modul Folgendes: Authentifizierung › Heraufladen aktivieren › Anonyme Benutzer dürfen hochladen › Beenden › Ja. Der Ordner /srv/ftp/upload wird erstellt.

  3. Führen Sie folgende Befehle aus: 

    tux > sudo systemctl enable mysql
tux > sudo systemctl start mysql
tux > sudo mysql_secure_installation
tux > sudo setup-sca -f

    Bei der sicheren MySQL-Erstellung (mysql_secure_installation) wird ein root-Passwort für MariaDB erstellt.

Vorgehen 39.4: Installation mit Heraufladen über SCP/tmp
 

Bei dieser Methode zum Einrichten der Appliance ist ein manueller Eingriff erforderlich (das SSH-Passwort muss eingegeben werden).

  1. Melden Sie sich auf dem Rechner, auf dem die Appliance installiert werden soll, bei einer Konsole an:

  2. Führen Sie folgende Befehle aus: 

    tux > sudo zypper install sca-appliance-* sca-patterns-*
tux > sudo systemctl enable apache2
tux > sudo systemctl start apache2
tux > sudo sudo systemctl enable mysql
tux > sudo systemctl start mysql
tux > sudo mysql_secure_installation
tux > sudo setup-sca

39.4.2.2 Voraussetzungen

 

Zum Ausführen eines Appliance-Servers müssen folgende Voraussetzungen erfüllt sein:

  • Alle Pakete sca-appliance-*.

  • Paket sca-patterns-base. Zusätzlich alle produktspezifischen Pakete sca-patterns-* für den Typ der Supportconfig-Archive, die mit der Appliance analysiert werden sollen.

  • Apache

  • PHP

  • MariaDB

  • Anonymer FTP-Server (optional)

39.4.2.3 Installation und grundlegende Einrichtung

 

Wie in Abschnitt 39.4.2.2, „Voraussetzungen“ beschrieben, bestehen mehrere Abhängigkeiten der SCA-Appliance von anderen Paketen. Aus diesem Grund sind einige Vorbereitungsmaßnahmen erforderlich, bevor Sie den SCA-Appliance-Server installieren und einrichten können:

  1. Für Apache und MariaDB installieren Sie die Installationsschemata Web und LAMP.

  2. Richten Sie Apache und MariaDB ein (und optional einen anonymen FTP-Server). Weitere Informationen hierzu finden Sie unter Kapitel 34, Der HTTP-Server Apache und Kapitel 35, Einrichten eines FTP-Servers mit YaST.

  3. Konfigurieren Sie Apache und MariaDB für das Starten beim Systemstart: 

    tux > sudo systemctl enable apache2 mysql

  4. Starten Sie beide Services: 

    tux > sudo systemctl start apache2 mysql

Sie können nun die SCA-Appliance gemäß den Anweisungen in Prozedur 39.5, „Installieren und Konfigurieren der SCA-Appliance“ installieren und einrichten.

Vorgehen 39.5: Installieren und Konfigurieren der SCA-Appliance
 

Nach dem Installieren der Pakete nehmen Sie mit dem Skript setup-sca die grundlegende Konfiguration der MariaDB-Administrations-/Berichtdatenbank vor, die von der SCA-Appliance genutzt wird.

Hiermit können Sie die folgenden Optionen für das Heraufladen der Supportconfig-Archive von den Rechnern in die SCA-Appliance konfigurieren:

  • scp

  • Anonymer FTP-Server

  1. Installieren Sie die Appliance und die SCA-Basisschema-Bibliothek: 

    tux > sudo zypper install sca-appliance-* sca-patterns-base

  2. Installieren Sie außerdem die Schemapakete für die zu analysierenden Supportconfig-Archive. Wenn sich beispielsweise Server mit SUSE Linux Enterprise Server 12 und SUSE Linux Enterprise 15 in Ihrer Umgebung befinden, installieren Sie sowohl das Paket sca-patterns-sle12 als auch das Paket sca-patterns-sle15.

    So installieren Sie alle verfügbaren Pakete: 

    tux > sudo zypper install sca-patterns-*

  3. Nehmen Sie mit dem Skript setup-sca die grundlegende Einrichtung der SCA-Appliance vor. Der Aufruf dieses Skripts ist abhängig davon, ob die Supportconfig-Archive auf den SCA-Appliance-Server heraufgeladen werden sollen:

    • Wenn Sie einen anonymen FTP-Server konfiguriert haben, bei dem das Verzeichnis /srv/ftp/upload genutzt wird, führen Sie das Einrichtungsskript mit der Option -f aus. Befolgen Sie die Anweisungen auf dem Bildschirm: 

      tux > sudo setup-sca -f
      Anmerkung
      Anmerkung: FTP-Server mit anderem Verzeichnis

      Wenn der FTP-Server ein anderes Verzeichnis verwendet (also nicht das Verzeichnis /srv/ftp/upload), passen Sie zunächst die folgenden Konfigurationsdateien so an, dass sie auf das richtige Verzeichnis verweisen: /etc/sca/sdagent.conf und /etc/sca/sdbroker.conf.

    • Sollen Supportconfig-Dateien mit scp in das Verzeichnis /tmp des SCA-Appliance-Servers hochgeladen werden, rufen Sie das Einrichtungsskript ohne Parameter auf. Befolgen Sie die Anweisungen auf dem Bildschirm: 

      tux > sudo setup-sca

    Das Einrichtungsskript überprüft, ob die Voraussetzungen erfüllt sind, und konfiguriert die erforderlichen Komponenten. Sie werden zur Eingabe von zwei Passwörtern aufgefordert: das MySQL-root-Passwort für die eingerichtete MariaDB sowie ein Webbenutzer-Passwort, mit dem Sie sich bei der Webschnittstelle der SCA-Appliance anmelden.

  4. Geben Sie das vorhandene MariaDB-root-Passwort ein. Damit kann die SCA-Appliance eine Verbindung zur MariaDB herstellen.

  5. Definieren Sie ein Passwort für den Webbenutzer. Dieses Passwort wird in die Datei /srv/www/htdocs/sca/web-config.php geschrieben und als Passwort für den Benutzer scdiag eingerichtet. Sowohl der Benutzername als auch das Passwort können jederzeit geändert werden (siehe Abschnitt 39.4.2.5.1, „Passwort für die Webschnittstelle“).

Nach erfolgter Installation und Einrichtung ist die SCA-Appliance einsatzbereit (siehe Abschnitt 39.4.2.4, „Verwenden der SCA-Appliance“). Sie sollten jedoch bestimmte Optionen noch bearbeiten, beispielsweise das Passwort für die Webschnittstelle oder die Quelle für die SCA-Schemaaktualisierungen ändern, den Archivierungsmodus aktivieren oder Email-Benachrichtigungen konfigurieren. Weitere Informationen finden Sie in Abschnitt 39.4.2.5, „Anpassen der SCA-Appliance“.

Warnung
Warnung: Schutz der Daten

Die Berichte auf dem SCA-Appliance-Server enthalten sicherheitsrelevante Informationen, weshalb die Daten auf dem SCA-Appliance-Server vor unbefugtem Zugriff geschützt werden müssen.

39.4.2.4 Verwenden der SCA-Appliance

 

Sie können vorhandene Supportconfig-Archive manuell an die SCA-Appliance heraufladen oder neue Supportconfig-Archive erstellen und im gleichen Arbeitsgang analysieren an die SCA-Appliance heraufladen. Das Heraufladen kann über FTP oder SCP erfolgen. In beiden Fällen benötigen Sie die URL, unter der sich die SCA-Appliance befindet. Zum Heraufladen über FTP muss ein FTP-Server für die SCA-Appliance installiert sein (siehe Prozedur 39.5, „Installieren und Konfigurieren der SCA-Appliance“).

39.4.2.4.1 Hochladen von supportconfig-Archiven an die SCA-Appliance
 

  • So können Sie ein Supportconfig-Archiv erstellen und über einen (anonymen) FTP-Zugang hochladen: 

    tux > sudo supportconfig -U “ftp://SCA-APPLIANCE.COMPANY.COM/upload”

  • So können Sie ein Supportconfig-Archiv erstellen und über SCP hochladen: 

    tux > sudo supportconfig -U “scp://SCA-APPLIANCE.COMPANY.COM/tmp”

    Sie werden aufgefordert, das root-Benutzerpasswort für den Server einzugeben, auf dem die SCA-Appliance ausgeführt wird.

  • Zum manuellen Heraufladen von einem oder mehreren Archiven kopieren Sie die vorhandenen Archivdateien (in der Regel unter /var/log/scc_*.tbz) in die SCA-Appliance. Als Ziel verwenden Sie entweder das Verzeichnis /tmp oder das Verzeichnis /srv/ftp/upload des Appliance-Servers (wenn FTP für den SCA-Appliance-Server konfiguriert ist).

39.4.2.4.2 Anzeigen von SCA-Berichten
 

Die SCA-Berichte können auf jedem Rechner angezeigt werden, auf dem ein Browser installiert ist und der auf die Berichtindexseite der SCA-Appliance zugreifen kann.

  1. Starten Sie einen Webbrowser, und aktivieren Sie JavaScript und Cookies.

  2. Als URL geben Sie die Berichtindexseite der SCA-Appliance ein. 

    https://sca-appliance.company.com/sca

    Fragen Sie im Zweifelsfall Ihren Systemadministrator.

  3. Sie werden aufgefordert, einen Benutzernamen und ein Passwort für die Anmeldung einzugeben.

    Mit dem SCA-Werkzeug erstellter HTML-Bericht
    Abbildung 39.2: Mit dem SCA-Werkzeug erstellter HTML-Bericht
     

  4. Nach erfolgter Anmeldung klicken Sie auf das Datum des gewünschten Berichts.

  5. Klicken Sie zunächst auf die Kategorie Grundstatus.

  6. Klicken Sie in der Spalte Nachricht auf einen Eintrag. Der entsprechende Artikel in der SUSE Knowledgebase wird geöffnet. Lesen Sie die vorgeschlagene Lösung, und befolgen Sie die Anweisungen.

  7. Wenn die Spalte Lösungen im Supportconfig-Analysebericht weitere Einträge enthält, klicken Sie auf diese Einträge. Lesen Sie die vorgeschlagene Lösung, und befolgen Sie die Anweisungen.

  8. Suchen Sie in der SUSE Knowledgebase (https://www.suse.com/support/kb/) nach Ergebnissen, die direkt mit dem für SCA erkannten Problem zusammenhängen. Bearbeiten Sie die Probleme.

  9. Suchen Sie nach Ergebnissen, die proaktiv bearbeitet werden können, damit künftige Probleme vermieden werden.

39.4.2.5 Anpassen der SCA-Appliance

 

In den nachfolgenden Abschnitten erfahren Sie, wie Sie das Passwort für die Webschnittstelle und die Quelle für die SCA-Schemaaktualisierungen ändern, den Archivierungsmodus aktivieren und Email-Benachrichtigungen archivieren.

39.4.2.5.1 Passwort für die Webschnittstelle
 

Zur Anmeldung bei der Webschnittstelle der SCA-Appliance benötigen Sie einen Benutzernamen und ein Passwort. Der Standard-Benutzername lautet scdiag und das Standardpasswort ist linux (sofern nicht anders festgelegt, siehe Prozedur 39.5, „Installieren und Konfigurieren der SCA-Appliance“). Ändern Sie das Standard-Passwort so bald wie möglich in ein sicheres Passwort. Auch den Benutzernamen können Sie bearbeiten.

Vorgehen 39.6: Ändern des Benutzernamens oder des Passworts für die Webschnittstelle
 

  1. Melden Sie sich an der Systemkonsole des SCA-Appliance-Servers als root-Benutzer an.

  2. Öffnen Sie die Datei /srv/www/htdocs/sca/web-config.php in einem Editor.

  3. Ändern Sie die Werte für $username und $password.

  4. Speichern und schließen Sie die Datei.

39.4.2.5.2 Aktualisierungen der SCA-Schemata
 

Standardmäßig werden alle Pakete sca-patterns-* regelmäßig mit einem rootCron-Auftrag aktualisiert, mit dem jeden Abend das Skript sdagent-patterns ausgeführt wird, das wiederum zypper update sca-patterns-* startet. Bei einer normalen Systemaktualisierung werden alle SCA-Appliance- und Schemapakete aktualisiert. So aktualisieren Sie die SCA-Appliance und die Schemata manuell: 

tux > sudo zypper update sca-*

Die Aktualisierungen werden standardmäßig aus dem Aktualisierungs-Respository für SUSE Linux Enterprise 15 SP3 installiert. Bei Bedarf können Sie die Quelle der Aktualisierungen in einen RMT-Server ändern. Beim Ausführen von zypper update sca-patterns-* durch sdagent-patterns werden die Aktualisierungen über den derzeit konfigurierten Aktualisierungskanal abgerufen. Wenn sich dieser Kanal auf einem RMT-Server befindet, werden die Pakete von diesem Server abgerufen.

Vorgehen 39.7: Deaktivieren der automatischen Aktualisierung der SCA-Schemata
 

  1. Melden Sie sich an der Systemkonsole des SCA-Appliance-Servers als root-Benutzer an.

  2. Öffnen Sie die Datei /etc/sca/sdagent-patterns.conf in einem Editor.

  3. Ändern Sie den Eintrag 

    UPDATE_FROM_PATTERN_REPO=1

    zu 

    UPDATE_FROM_PATTERN_REPO=0

  4. Speichern und schließen Sie die Datei. Die Änderung tritt ohne Neustart des Rechners in Kraft.

39.4.2.5.3 Archivierungsmodus
 

Alle supportconfig-Archive werden aus der SCA-Appliance gelöscht, sobald sie analysiert und die zugehörigen Ergebnisse in der MariaDB-Datenbank gespeichert wurden. Wenn Sie Kopien der Supportconfig-Archive eines Rechners aufheben, kann dies allerdings ggf. eine spätere Fehlerbehebung erleichtern. Standardmäßig ist der Archivierungsmodus deaktiviert.

Vorgehen 39.8: Aktivieren des Archivierungsmodus in der SCA-Appliance
 

  1. Melden Sie sich an der Systemkonsole des SCA-Appliance-Servers als root-Benutzer an.

  2. Öffnen Sie die Datei /etc/sca/sdagent.conf in einem Editor.

  3. Ändern Sie den Eintrag 

    ARCHIVE_MODE=0

    zu 

    ARCHIVE_MODE=1

  4. Speichern und schließen Sie die Datei. Die Änderung tritt ohne Neustart des Rechners in Kraft.

Sobald der Archivierungsmodus aktiviert ist, werden die Supportconfig-Dateien nicht mehr von der SCA-Appliance gelöscht, sondern im Verzeichnis /var/log/archives/saved gespeichert.

39.4.2.5.4 Senden von SCA-Berichten per Email
 

Die SCA-Appliance kann für jede analysierte Supportconfig-Datei einen HTML-Bericht per Email schicken. Diese Funktion ist standardmäßig deaktiviert. Wenn Sie dies aktivieren, können Sie eine Liste der Email-Adressen definieren, an die die Berichte gesendet werden sollen. Definieren Sie die Statusebene, die das Senden von Berichten auslösen soll (STATUS_NOTIFY_LEVEL).

Mögliche Werte für STATUS_NOTIFY_LEVEL
 
$STATUS_OFF

Deaktiviert das Senden von HTML-Berichten.

$STATUS_CRITICAL

Sendet nur SCA-Berichte, die den Status CRITICAL enthalten.

$STATUS_WARNING

Sendet nur SCA-Berichte, die den Status WARNING oder CRITICAL enthalten.

$STATUS_RECOMMEND

Sendet nur SCA-Berichte, die den Status RECOMMEND, WARNING oder CRITICAL enthalten.

$STATUS_SUCCESS

Sendet SCA-Berichte, die den Status SUCCESS, RECOMMEND, WARNING oder CRITICAL enthalten.

Vorgehen 39.9: Konfigurieren von Email-Benachrichtigungen für SCA-Berichte
 

  1. Melden Sie sich an der Systemkonsole des SCA-Appliance-Servers als root-Benutzer an.

  2. Öffnen Sie die Datei /etc/sca/sdagent.conf in einem Editor.

  3. Wechseln Sie zum Eintrag STATUS_NOTIFY_LEVEL. Standardmäßig ist hier $STATUS_OFF festgelegt (Email-Benachrichtigungen sind deaktiviert).

  4. Zum Aktivieren der Email-Benachrichtigungen ändern Sie $STATUS_OFF in die Statusebene, ab der die Email-Berichte gesendet werden sollen, beispielsweise: 

    STATUS_NOTIFY_LEVEL=$STATUS_SUCCESS

    Weitere Informationen finden Sie unter Mögliche Werte für STATUS_NOTIFY_LEVEL.

  5. So definieren Sie die Liste der Empfänger, an die die Berichte gesendet werden sollen:

    1. Wechseln Sie zum Eintrag EMAIL_REPORT='root'.

    2. Ersetzen Sie root durch eine Liste der Email-Adressen, an die die SCA-Berichte gesendet werden sollen. Die Email-Adressen müssen jeweils durch ein Komma getrennt werden. Beispiel: 

      EMAIL_REPORT='tux@my.company.com wilber@your.company.com'

  6. Speichern und schließen Sie die Datei. Die Änderungen treten ohne Neustart des Rechners in Kraft. Alle künftigen SCA-Berichte werden an die angegebenen Adressen gesendet.

39.4.2.6 Sichern und Wiederherstellen der Datenbank

 

Mit dem Kommando scadb können Sie die MariaDB-Datenbank, in der die SCA-Berichte gespeichert werden, sichern und wiederherstellen. scadb wird vom Paket sca-appliance-broker.

Vorgehen 39.10: Sichern der Datenbank
 

  1. Melden Sie sich an der Systemkonsole des Servers, auf dem die SCA-Appliance ausgeführt wird, als root-Benutzer an.

  2. Versetzen Sie die Appliance mit dem folgenden Kommando in den Wartungsmodus: 

    root # scadb maint

  3. Starten Sie die Sicherung mit: 

    root # scadb backup

    Die Daten werden in einem TAR-Archiv gespeichert: sca-backup-*sql.gz.

  4. Wenn Sie mit der Schemaerstellungsdatenbank eigene Schemata entwickelt haben (siehe Abschnitt 39.4.3, „Entwickeln von benutzerdefinierten Analyseschemata“), sichern Sie diese Daten ebenfalls: 

    root # sdpdb backup

    Die Daten werden in einem TAR-Archiv gespeichert: sdp-backup-*sql.gz.

  5. Kopieren Sie die folgenden Daten auf einen anderen Rechner oder auf ein externes Speichermedium:

    • sca-backup-*sql.gz

    • sdp-backup-*sql.gz

    • /usr/lib/sca/patterns/local (nur wenn Sie benutzerdefinierte Schemata erstellt haben)

  6. Reaktivieren Sie die SCA-Appliance mit: 

    root # scadb reset agents
Vorgehen 39.11: Wiederherstellen der Datenbank
 

Zum Wiederherstellen der Datenbank aus der Sicherung gehen Sie wie folgt vor:

  1. Melden Sie sich an der Systemkonsole des Servers, auf dem die SCA-Appliance ausgeführt wird, als root-Benutzer an.

  2. Kopieren Sie die jüngsten TAR-Archive mit der Bezeichnung sca-backup-*sql.gz und sdp-backup-*sql.gz auf den SCA-Appliance-Server.

  3. Dekomprimieren Sie die Dateien mit: 

    root # gzip -d *-backup-*sql.gz

  4. Importieren Sie die Daten mit dem folgenden Kommando in die Datenbank: 

    root # scadb import sca-backup-*sql

  5. Wenn Sie mit der Schemaerstellungsdatenbank eigene Schemata entwickelt haben, importieren Sie außerdem die nachfolgenden Daten mit: 

    root # sdpdb import sdp-backup-*sql

  6. Wenn Sie benutzerdefinierte Schemata verwenden, stellen Sie außerdem die Datei /usr/lib/sca/patterns/local aus den Sicherungsdaten wieder her.

  7. Reaktivieren Sie die SCA-Appliance mit: 

    root # scadb reset agents

  8. Aktualisieren Sie die Schemamodule in der Datenbank mit: 

    root # sdagent-patterns -u

39.4.3 Entwickeln von benutzerdefinierten Analyseschemata

 

Die SCA-Appliance bietet eine umfangreiche Schemaentwicklungsumgebung (die SCA-Schemadatenbank), mit der Sie eigene, benutzerdefinierte Schemata erstellen können. Schemata können in jeder beliebigen Programmiersprache geschrieben sein. Damit sie für das Supportconfig-Analyseverfahren zur Verfügung stehen, müssen sie im Verzeichnis /usr/lib/sca/patterns/local gespeichert und ausführbar gemacht werden. Die benutzerdefinierten Schemata werden dann im Rahmen des Analyseberichts sowohl von der SCA-Appliance als auch vom SCA-Werkzeug für neue Supportconfig-Archive ausgeführt. Weitere Anweisungen zum Erstellen (und Testen) der benutzerdefinierten Schemata finden Sie unter https://www.suse.com/c/blog/sca-pattern-development/.

39.5 Sammeln von Informationen bei der Installation

 

Während der Installation ist supportconfig nicht verfügbar. Sie können Protokolldateien von YaST jedoch mithilfe von save_y2logs sammeln. Dieses Kommando erstellt ein .tar.xz-Archiv im Verzeichnis /tmp.

Wenn bereits früh Probleme bei der Installation auftreten, können Sie möglicherweise Informationen aus der durch linuxrc erstellten Protokolldatei sammeln. linuxrc ist ein kleines Kommando, das vor dem Start von YaST ausgeführt wird. Diese Protokolldatei finden Sie unter /var/log/linuxrc.log.

Wichtig
Wichtig: Installationsprotokolldateien sind im installierten System nicht verfügbar

Die während der Installation verfügbaren Protokolldateien sind im installierten System nicht mehr verfügbar. Speichern Sie die Installationsprotokolldateien ordnungsgemäß, während das Installationsprogramm noch ausgeführt wird.

39.6 Unterstützung für Kernelmodule

 

Eine wichtige Anforderung für jedes Enterprise-Betriebssystem ist der Grad der Unterstützung für die jeweilige Umgebung. Kernelmodule sind die wichtigsten Bindeglieder zwischen der Hardware („Controller“) und dem Betriebssystem. Die Kernelmodule in SUSE Linux Enterprise umfassen jeweils das Flag supported, das drei mögliche Werte annehmen kann:

  • „Ja“, daher supported

  • „Extern“, daher supported

  • „“ (leer, nicht festgelegt), daher unsupported

Es gelten die folgenden Regeln:

  • Alle Module eines selbst rückkompilierten Kernels sind standardmäßig als nicht unterstützt gekennzeichnet.

  • Kernelmodule, die von den SUSE-Partnern unterstützt und über das SUSE SolidDriver-Programm bereitgestellt, sind als „extern“ gekennzeichnet.

  • Wenn das Flag supported nicht gesetzt ist, wird der Kernel beim Laden dieses Moduls unbrauchbar. Unbrauchbare Kernel werden nicht unterstützt. Die nicht unterstützten Kernel-Module befinden sich in einem separaten RPM-Paket (kernel-FLAVOR-extra). Dieses Paket ist lediglich für SUSE Linux Enterprise Desktop und SUSE Linux Enterprise Workstation Extension verfügbar. Diese Kernel werden standardmäßig nicht geladen (FLAVOR=default|xen|...). Darüber hinaus sind diese nicht unterstützten Module im Installationsprogramm nicht verfügbar, und das Kernelpaket kernel-FLAVOR-extraist kein Bestandteil der SUSE Linux Enterprise-Medien.

  • Kernelmodule, die nicht unter einer zur Lizenz des Linux-Kernels kompatiblen Lizenz bereitgestellt werden, machen den Kernel ebenfalls unbrauchbar. Weitere Informationen finden Sie unter /usr/src/linux/Documentation/sysctl/kernel.txt und dem Status /proc/sys/kernel/tainted.

39.6.1 Technischer Hintergrund

 

  • Linux-Kernel: Der Standardwert für /proc/sys/kernel/unsupported bei SUSE Linux Enterprise 15 SP3 lautet 2 (do not warn in syslog when loading unsupported modules [keine Warnung im Syslog, wenn nicht unterstützte Module geladen werden]). Dieser Standardwert wird im Installationsprogramm und im installierten System verwendet. Weitere Informationen finden Sie unter /usr/src/linux/Documentation/sysctl/kernel.txt.

  • modprobe: Das Dienstprogramm modprobe zum Prüfen der Modulabhängigkeiten und zum Laden der Module prüft den Wert des Flags supported. Beim Wert „Ja“ oder „Extern“ wird das Modul geladen, ansonsten nicht. Weitere Informationen, wie Sie dieses Verhalten außer Kraft setzen, finden Sie in Abschnitt 39.6.2, „Arbeiten mit nicht unterstützten Modulen“.

    Anmerkung
    Anmerkung: Support

    SUSE bietet im Allgemeinen keine Unterstützung für das Entfernen von Speichermodulen mit modprobe -r.

39.6.2 Arbeiten mit nicht unterstützten Modulen

 

Die allgemeine Unterstützbarkeit ist wichtig, doch es gibt Situationen, in denen ein nicht unterstütztes Modul geladen werden muss, z. B. zu Testzwecken, zur Fehlersuche oder wenn Ihr Hardware-Hersteller einen Hotfix bereitstellt.

  • Zum Überschreiben des Standardwerts bearbeiten Sie die Datei /etc/modprobe.d/10-unsupported-modules.conf, und ändern Sie den Wert der Variablen allow_unsupported_modules zu 1. Falls in der initrd ein nicht unterstütztes Modul erforderlich ist, müssen Sie zur Aktualisierung der initrd auch dracut -f ausführen.

    Falls Sie nur einmalig versuchen möchten, ein Modul zu laden, verwenden Sie die Option --allow-unsupported-modules für modprobe. Weitere Informationen finden Sie auf der man-Seite zu modprobe.

  • Während der Installation werden nicht unterstützte Module u. U. über Treiberaktualisierungs-Datenträger hinzugefügt und entsprechend geladen. Soll das Laden von nicht unterstützten Modulen beim Booten und zu späteren Zeitpunkten erzwungen werden, verwenden Sie die Kernel-Befehlszeile oem-modules. Beim Installieren und Initialisieren des Pakets suse-module-tools wird das Kernel-Flag TAINT_NO_SUPPORT (/proc/sys/kernel/tainted) ausgewertet. Ist das Kernel bereits unbrauchbar, wird allow_unsupported_modules aktiviert. Damit wird verhindert, dass nicht unterstützte Module im zu installierenden System zu Fehlern führen. Wenn während der Installation keine nicht unterstützten Module vorhanden sind und die andere spezielle Kernel-Befehlszeilenoption (oem-modules=1) nicht verwendet wird, so werden nicht unterstützte Module dennoch standardmäßig nicht zugelassen.

Beachten Sie, dass der Kernel und das gesamte System nicht mehr durch SUSE unterstützt werden, sobald nicht unterstützte Module geladen und ausgeführt werden.

39.7 Weitere Informationen

 

40 Häufige Probleme und deren Lösung

 

In diesem Kapitel werden mögliche Probleme und deren Lösungen beschrieben. Auch wenn Ihre Situation nicht genau auf die hier beschriebenen Probleme zutreffen mag, finden Sie vielleicht einen ähnlichen Fall, der Ihnen Hinweise zur Lösung Ihres Problems liefert.

40.1 Suchen und Sammeln von Informationen

 

Linux gibt äußerst detailliert Aufschluss über die Vorgänge in Ihrem System. Es gibt mehrere Quellen, die Sie bei einem Problem mit Ihrem System zurate ziehen können. Die meisten davon beziehen sich auf Linux-Systeme im Allgemeinen doch einige sind speziell auf SUSE Linux Enterprise Server-Systeme ausgerichtet. Die meisten Protokolldateien können mit YaST angezeigt werden ( Verschiedenes ›  Startprotokoll anzeigen).

YaST bietet die Möglichkeit, alle erforderlichen Systeminformationen für das Supportteam zusammenzustellen. Wählen Sie Andere › Support und dann die Kategorie Ihres Problems aus. Wenn alle Informationen gesammelt wurden, können Sie diese an Ihre Support-Anfrage anhängen.

Nachfolgend finden Sie eine Liste der wichtigsten Protokolldateien mit einer Beschreibung ihrer typischen Einsatzbereiche. Eine Tilde (~) in einer Pfadangabe verweist auf das Home-Verzeichnis des aktuellen Benutzers.

Tabelle 40.1: Protokolldateien
 

Protokolldatei

Beschreibung

~/.xsession-errors

Meldungen von den zurzeit ausgeführten Desktop-Anwendungen.

/var/log/apparmor/

Protokolldateien von AppArmor (Detailinformationen finden Sie im Book “Security and Hardening Guide”).

/var/log/audit/audit.log

Protokolldatei von Audit, um Zugriffe auf Dateien, Verzeichnisse oder Ressourcen Ihres Systems sowie Systemaufrufe zu verfolgen. Ausführliche Informationen erhalten Sie im Book “Security and Hardening Guide”.

/var/log/mail.*

Meldungen vom Email-System.

/var/log/NetworkManager

NetworkManager-Protokolldatei zur Erfassung von Problemen hinsichtlich der Netzwerkkonnektivität

/var/log/samba/

Verzeichnis, das Protokollmeldungen vom Samba-Server und -Client enthält.

/var/log/warn

Alle Meldungen vom Kernel und dem Systemprotokoll-Daemon mit der Protokollstufe „Warnung“ oder höher.

/var/log/wtmp

Binärdatei mit Benutzeranmeldedatensätzen für die aktuelle Computersitzung. Die Anzeige erfolgt mit last.

/var/log/Xorg.*.Protokoll

Unterschiedliche Start- und Laufzeitprotokolldateien des X Window System. Hilfreich für die Fehlersuche bei Problemen beim Start von X.

/var/log/YaST2/

Verzeichnis, das die Aktionen von YAST und deren Ergebnissen enthält.

/var/log/zypper.log

Protokolldatei von Zypper.

Neben den Protokolldateien versorgt Ihr Computer Sie auch mit Informationen zum laufenden System. Siehe Tabelle 40.2: Systeminformationen mit dem /proc-Dateisystem

Tabelle 40.2: Systeminformationen mit dem /proc-Dateisystem
 

Datei

Beschreibung

/proc/cpuinfo

Enthält Prozessorinformationen wie Typ, Fabrikat, Modell und Leistung.

/proc/dma

Zeigt die aktuell verwendeten DMA-Kanäle an.

/proc/interrupts

Zeigt an, welche Interrupts verwendet werden und wie viele bisher verwendet wurden.

/proc/iomem

Zeigt den Status des E/A (Eingabe/Ausgabe)-Speichers an.

/proc/ioports

Zeigt an, welche E/A-Ports zurzeit verwendet werden.

/proc/meminfo

Zeigt den Speicherstatus an.

/proc/modules

Zeigt die einzelnen Module an.

/proc/mounts

Zeigt die zurzeit eingehängten Geräte an.

/proc/partitions

Zeigt die Partitionierung aller Festplatten an.

/proc/version

Zeigt die aktuelle Linux-Version an.

Abgesehen vom Dateisystem /proc exportiert der Linux-Kernel Informationen mit dem Modul sysfs, einem speicherinternen Dateisystem. Dieses Modul stellt Kernelobjekte, deren Attribute und Beziehungen dar. Weitere Informationen zu sysfs finden Sie im Kontext von udev im Abschnitt Kapitel 24, Gerätemanagement über dynamischen Kernel mithilfe von udev. Tabelle 40.3 enthält einen Überblick über die am häufigsten verwendeten Verzeichnisse unter /sys.

Tabelle 40.3: Systeminformationen mit dem /sys-Dateisystem
 

Datei

Beschreibung

/sys/block

Enthält Unterverzeichnisse für jedes im System ermittelte Blockgerät. Im Allgemeinen handelt es sich dabei meistens um Geräte vom Typ Datenträger.

/sys/bus

Enthält Unterverzeichnisse für jeden physischen Bustyp.

/sys/class

Enthält Unterverzeichnisse, die nach den Funktionstypen der Geräte (wie Grafik, Netz, Drucker usw.) gruppiert sind.

/sys/device

Enthält die globale Gerätehierarchie.

Linux bietet mehrere Werkzeuge für die Systemanalyse und -überwachung. Im Book “System Analysis and Tuning Guide”, Chapter 2 “System monitoring utilities” finden Sie eine Auswahl der wichtigsten, die zur Systemdiagnose eingesetzt werden.

Jedes der nachfolgenden Szenarien beginnt mit einem Header, in dem das Problem beschrieben wird, gefolgt von ein oder zwei Absätzen mit Lösungsvorschlägen, verfügbaren Referenzen für detailliertere Lösungen sowie Querverweisen auf andere Szenarien, die mit diesem Szenario in Zusammenhang stehen.

40.2 Probleme beim Booten

 

Probleme beim Booten sind Fälle, in denen Ihr System nicht vorschriftsmäßig gebootet wird, das Booten also nicht mit dem erwarteten Ziel und Anmeldebildschirm erfolgt.

40.2.1 GRUB 2-Bootloader wird nicht geladen

 

Wenn die Hardware vorschriftsmäßig funktioniert, ist möglicherweise der Bootloader beschädigt und Linux kann auf dem Computer nicht gestartet werden. In diesem Fall muss der Bootloader repariert werden. Dazu müssen Sie das Rettungssystem starten wie in Abschnitt 40.5.2, „Verwenden des Rettungssystems“ beschrieben und den Anweisungen in Abschnitt 40.5.2.4, „Bearbeiten und erneutes Installieren des Bootloaders“ folgen.

Alternativ können Sie den Bootloader mit dem Rettungssystem wie folgt reparieren. Booten Sie den Computer von den Installationsmedien. Wählen Sie im Bootbildschirm die Option Mehr › Linux-System booten. Wählen Sie die Festplatte aus, auf der sich das installierte System und der Kernel mit den Kernel-Standardoptionen befinden.

Wenn das System gebootet wird, starten Sie YaST und wechseln Sie zu System › Bootloader. Prüfen Sie, ob die Option Generischen Bootcode in MBR schreiben aktiviert ist, und klicken Sie auf OK. Ein beschädigte Bootloader wird überschrieben und damit repariert, ein fehlender Bootloader wird installiert.

Die Grunde dafür, dass der Computer nicht gebootet werden kann, stehen möglicherweise in Zusammenhang mit dem BIOS.

BIOS-Einstellungen

Überprüfen Sie Ihr BIOS auf Verweise auf Ihre Festplatte hin. GRUB 2 wird möglicherweise einfach deshalb nicht gestartet, weil die Festplatte mit den aktuellen BIOS-Einstellungen nicht gefunden wird.

BIOS-Bootreihenfolge

Überprüfen Sie, ob die Festplatte in der Bootreihenfolge Ihres Systems enthalten ist. Wenn die Festplatten-Option nicht aktiviert wurde, wird Ihr System möglicherweise vorschriftsmäßig installiert. Das Booten ist jedoch nicht möglich, wenn auf die Festplatte zugegriffen werden muss.

40.2.2 Keine grafische Anmeldung

 

Wenn der Computer hochfährt, jedoch der grafische Anmelde-Manager nicht gebootet wird, müssen Sie entweder hinsichtlich der Auswahl des standardmäßigen systemd-Ziels oder der Konfiguration des X-Window-Systems mit Problemen rechnen. Zum Prüfen des aktuellen systemd-Standardziels führen Sie das Kommando sudo systemctl get-default aus. Wenn nicht der Wert graphical.target zurückgegeben wird, führen Sie das Kommando sudo systemctl isolate graphical.target aus. Wird der grafische Anmeldebildschirm geöffnet, melden Sie sich an, starten Sie YaST ›  System ›  Dienste-Verwaltung, und legen Sie für Default System Target (Standard-Systemziel) den Wert Graphical Interface (Grafische Oberfläche) fest. Von nun an bootet das System in den grafischen Anmeldebildschirm.

Falls der grafische Anmeldebildschirm auch nicht nach dem Booten oder dem Wechsel zum grafischen Ziel gestartet wird, ist die Desktop- oder X Window-Software möglicherweise fehlerhaft konfiguriert oder beschädigt. Untersuchen Sie die Protokolldateien unter /var/log/Xorg.*.log auf detaillierte Meldungen vom X-Server beim Startversuch. Wenn beim Starten des Desktops ein Fehler auftritt, werden möglicherweise Fehlermeldungen im Systemjournal protokolliert, die Sie mit dem Kommando journalctl abfragen können (weitere Informationen finden Sie in Kapitel 17, journalctl: Abfragen des systemd-Journals). Wenn diese Fehlermeldungen auf ein Konfigurationsproblem mit dem X-Server hinweisen, versuchen Sie, diese Probleme zu beseitigen. Wenn das grafische System weiterhin nicht aktiviert wird, ziehen Sie die Neuinstallation des grafischen Desktop in Betracht.

40.2.3 Einhängen der Root-Btrfs-Partition nicht möglich

 

Wenn eine btrfs-root-Partition beschädigt wird, haben Sie folgende Möglichkeiten:

  • Hängen Sie die Partition mit der Option -o recovery ein.

  • Falls dies nicht funktioniert, führen Sie btrfs-zero-log auf der root-Partition aus.

40.2.4 Erzwingen der Prüfung von root-Partitionen

 

Wenn die root-Partition beschädigt wird, verwenden Sie den Parameter forcefsck am Bootprompt. Hierdurch wird die Option -f (force = zwingen) an das Kommando fsck übergeben.

40.2.5 Auslagerungsgerät zum Booten deaktivieren

 

Wenn kein Auslagerungsgerät verfügbar ist und das System es beim Booten nicht aktivieren kann, schlägt der Bootvorgang womöglich fehl. Versuchen Sie, alle Auslagerungsgeräte zu deaktivieren, indem Sie auf der Kernel-Kommandozeile die folgenden Optionen hinzufügen: 

systemd.device_wants_unit=off systemd.mask=swap.target

Sie können auch versuchen, bestimmte Auslagerungsgeräte zu deaktivieren: 

systemd.mask=dev-sda1.swap

40.2.6 Fehler bei GRUB 2 beim Neustarten auf einem Dual-Boot-System

 

Wenn bei GRUB 2 ein Fehler beim Neustarten auftritt, deaktivieren Sie die Einstellung Fast Boot (Schnelles Booten) im BIOS.

40.3 Probleme bei der Anmeldung

 

Probleme bei der Anmeldung sind Fälle, in denen Ihr Computer in den erwarteten Begrüßungsbildschirm bzw. die erwartete Anmelde-Eingabeaufforderung bootet, den Benutzernamen und das Passwort jedoch entweder nicht akzeptiert oder zunächst akzeptiert, sich dann aber nicht erwartungsgemäß verhält (der grafische Desktop wird nicht gestartet, es treten Fehler auf, es wird wieder eine Kommandozeile angezeigt usw.).

40.3.1 Fehler trotz gültiger Kombination aus Benutzername und Passwort

 

Dieser Fall tritt in der Regel ein, wenn das System zur Verwendung von Netzwerkauthentifizierung oder Verzeichnisdiensten konfiguriert wurde und aus unbekannten Gründen keine Ergebnisse von den zugehörigen konfigurierten Servern abrufen kann. Der root-Benutzer ist der einzige lokale Benutzer, der sich noch bei diesen Computern anmelden kann. Nachfolgend sind einige häufige Ursachen dafür aufgeführt, weshalb Anmeldungen nicht ordnungsgemäß verarbeitet werden können, obwohl der Computer funktionstüchtig zu sein scheint:

  • Es liegt ein Problem mit der Netzwerkfunktion vor. Weitere Anweisungen hierzu finden Sie in Abschnitt 40.4, „Probleme mit dem Netzwerk“.

  • DNS ist zurzeit nicht funktionsfähig (dadurch ist GNOME nicht funktionsfähig, und das System kann keine an sichere Server gerichteten bestätigten Anforderungen durchführen). Ein Hinweis, dass dies zutrifft, ist, dass der Computer auf sämtliche Aktionen ausgesprochen langsam reagiert. Weitere Informationen zu diesem Thema finden Sie in Abschnitt 40.4, „Probleme mit dem Netzwerk“.

  • Wenn das System für die Verwendung von Kerberos konfiguriert ist, hat die lokale Systemzeit möglicherweise die zulässige Abweichung zur Kerberos-Serverzeit (üblicherweise 300 Sekunden) überschritten. Wenn NTP (Network Time Protocol) nicht ordnungsgemäß funktioniert bzw. lokale NTP-Server nicht funktionieren, kann auch die Kerberos-Authentifizierung nicht mehr verwendet werden, da sie von der allgemeinen netzwerkübergreifenden Uhrsynchronisierung abhängt.

  • Die Authentifizierungskonfiguration des Systems ist fehlerhaft. Prüfen Sie die betroffenen PAM-Konfigurationsdateien auf Tippfehler oder falsche Anordnung von Direktiven hin. Zusätzliche Hintergrundinfomationen zu PAM (Password Authentification Module) und der Syntax der betroffenen Konfigurationsdateien finden Sie im Book “Security and Hardening Guide”, Chapter 2 “Authentication with PAM”.

  • Die Home-Partition ist verschlüsselt. Weitere Informationen zu diesem Thema finden Sie in Abschnitt 40.3.3, „Anmeldung bei verschlüsselter Home-Partition fehlgeschlagen“.

In allen Fällen, in denen keine externen Netzwerkprobleme vorliegen, besteht die Lösung darin, das System erneut im Einzelbenutzermodus zu booten und die Konfigurationsfehler zu beseitigen, bevor Sie erneut in den Betriebsmodus booten und erneut versuchen, sich anzumelden. So booten Sie in den Einzelbenutzerbetrieb:

  1. Booten Sie das System neu. Daraufhin wird der Bootbildschirm mit einer Eingabeaufforderung eingeblendet.

  2. Drücken Sie Esc. Der Eröffnungsbildschirm wird geschlossen und Sie gelangen zum textgestützten GRUB 2-Menü.

  3. Drücken Sie B. Der GRUB 2-Editor wird geöffnet.

  4. Fügen Sie den folgenden Parameter an die Zeile mit den Kernel-Parametern an: 

    systemd.unit=rescue.target

  5. Drücken Sie F10.

  6. Geben Sie Benutzername und Passwort für root ein.

  7. Nehmen Sie alle erforderlichen Änderungen vor.

  8. Booten Sie in den vollen Mehrbenutzer- und Netzwerkbetrieb, indem Sie systemctl isolate graphical.target an der Kommandozeile eingeben.

40.3.2 Keine Annahme einer gültigen Kombination aus Benutzername und Passwort

 

Dies ist das mit Abstand häufigste Problem, auf das Benutzer stoßen, da es hierfür zahlreiche Ursachen gibt. Je nachdem, ob Sie lokale Benutzerverwaltung und Authentifizierung oder Netzwerkauthentifizierung verwenden, treten Anmeldefehler aus verschiedenen Gründen auf.

Fehler bei der lokalen Benutzerverwaltung können aus folgenden Gründen auftreten:

  • Der Benutzer hat möglicherweise das falsche Passwort eingegeben.

  • Das Home-Verzeichnis des Benutzers, das die Desktopkonfigurationsdateien enthält, ist beschädigt oder schreibgeschützt.

  • Möglicherweise bestehen hinsichtlich der Authentifizierung dieses speziellen Benutzers durch das X Windows System Probleme, insbesondere, wenn das Home-Verzeichnis des Benutzers vor der Installation der aktuellen Distribution für andere Linux-Distributionen verwendet wurde.

Gehen Sie wie folgt vor, um den Grund für einen Fehler bei der lokalen Anmeldung ausfindig zu machen:

  1. Überprüfen Sie, ob der Benutzer sein Passwort richtig in Erinnerung hat, bevor Sie mit der Fehlersuche im gesamten Authentifizierungsmechanismus beginnen. Sollte sich der Benutzer nicht mehr an sein Passwort erinnern, können Sie es mithilfe des YaST-Moduls für die Benutzerverwaltung ändern. Achten Sie auf die Feststelltaste und deaktivieren Sie sie gegebenenfalls.

  2. Melden Sie sich als root an, und prüfen Sie das Systemjournal mit journalctl -e auf Fehlermeldungen aus dem Anmeldevorgang und von PAM.

  3. Versuchen Sie, sich von einer Konsole aus anzumelden (mit Strg–Alt–F1). Wenn dies gelingt, liegt der Fehler nicht bei PAM, da die Authentifizierung dieses Benutzers auf diesem Computer möglich ist. Versuchen Sie, mögliche Probleme mit dem X-Window-System oder dem GNOME-Desktop ausfindig zu machen. Weitere Informationen hierzu finden Sie im Abschnitt 40.3.4, „Probleme mit dem GNOME-Desktop“.

  4. Wenn das Home-Verzeichnis des Benutzers für eine andere Linux-Distribution verwendet wurde, entfernten Sie die Datei Xauthority aus dem Heimverzeichnis des Benutzers. Melden Sie sich mit Strg–Alt–F1 bei der Konsole an und führen Sie rm .Xauthority als dieser Benutzer aus. Auf diese Weise sollten die X-Authentifizierungsprobleme dieses Benutzers beseitigt werden. Versuchen Sie erneut, sich beim grafischen Desktop anzumelden.

  5. Wenn der Desktop aufgrund beschädigter Konfigurationsdateien nicht aufgerufen werden konnte, fahren Sie mit Abschnitt 40.3.4, „Probleme mit dem GNOME-Desktop“ fort.

Im Folgenden sind allgemeine Gründe aufgelistet, aus denen eine Netzwerkauthentifizierung für einen bestimmten Benutzer auf einem bestimmten Computer fehlschlagen könnte:

  • Der Benutzer hat möglicherweise das falsche Passwort eingegeben.

  • Der Benutzername ist in den lokalen Authentifizierungsdateien des Computers vorhanden und wird zudem von einem Netzwerkauthentifizierungssystem bereitgestellt, was zu Konflikten führt.

  • Das Home-Verzeichnis ist zwar vorhanden, ist jedoch beschädigt oder nicht verfügbar. Es ist möglicherweise schreibgeschützt oder befindet sich auf einem Server, auf den momentan nicht zugegriffen werden kann.

  • Der Benutzer ist nicht berechtigt, sich bei diesem Host im Authentifizierungssystem anzumelden.

  • Der Hostname des Computers hat sich geändert, und der Benutzer ist nicht zur Anmeldung bei diesem Host berechtigt.

  • Der Computer kann keine Verbindung mit dem Authentifizierungs- oder Verzeichnisserver herstellen, auf dem die Informationen dieses Benutzers gespeichert sind.

  • Möglicherweise bestehen hinsichtlich der Authentifizierung dieses speziellen Benutzers durch das X Window System Probleme, insbesondere, wenn das Home-Verzeichnis des Benutzers vor der Installation der aktuellen Distribution für andere Linux-Distributionen verwendet wurde.

Gehen Sie wie folgt vor, um die Ursache der Anmeldefehler bei der Netzwerkauthentifizierung zu ermitteln:

  1. Überprüfen Sie, ob der Benutzer sein Passwort richtig in Erinnerung hat, bevor Sie mit der Fehlersuche im gesamten Authentifizierungsmechanismus beginnen.

  2. Ermitteln Sie den Verzeichnisserver, den der Computer für die Authentifizierung verwendet, und vergewissern Sie sich, dass dieser ausgeführt wird und ordnungsgemäß mit den anderen Computern kommuniziert.

  3. Überprüfen Sie, ob der Benutzername und das Passwort des Benutzers auf anderen Computern funktionieren, um sicherzustellen, dass seine Authentifizierungsdaten vorhanden sind und ordnungsgemäß verteilt wurden.

  4. Finden Sie heraus, ob sich ein anderer Benutzer bei dem problembehafteten Computer anmelden kann. Wenn sich ein anderer Benutzer oder der root-Benutzer anmelden kann, melden Sie sich mit dessen Anmeldedaten an, und überprüfen Sie das Systemjournal mit journalctl -e > Datei. Suchen Sie nach dem Zeitstempel, der sich auf die Anmeldeversuche bezieht, und finden Sie heraus, ob von PAM Fehlermeldungen generiert wurden.

  5. Versuchen Sie, sich von einer Konsole aus anzumelden (mit Strg–Alt–F1). Wenn dies gelingt, liegt der Fehler nicht bei PAM oder dem Verzeichnisserver mit dem Home-Verzeichnis des Benutzers, da die Authentifizierung dieses Benutzers auf diesem Computer möglich ist. Versuchen Sie, mögliche Probleme mit dem X-Window-System oder dem GNOME-Desktop ausfindig zu machen. Weitere Informationen hierzu finden Sie im Abschnitt 40.3.4, „Probleme mit dem GNOME-Desktop“.

  6. Wenn das Home-Verzeichnis des Benutzers für eine andere Linux-Distribution verwendet wurde, entfernten Sie die Datei Xauthority aus dem Heimverzeichnis des Benutzers. Melden Sie sich mit Strg–Alt–F1 bei der Konsole an und führen Sie rm .Xauthority als dieser Benutzer aus. Auf diese Weise sollten die X-Authentifizierungsprobleme dieses Benutzers beseitigt werden. Versuchen Sie erneut, sich beim grafischen Desktop anzumelden.

  7. Wenn der Desktop aufgrund beschädigter Konfigurationsdateien nicht aufgerufen werden konnte, fahren Sie mit Abschnitt 40.3.4, „Probleme mit dem GNOME-Desktop“ fort.

40.3.3 Anmeldung bei verschlüsselter Home-Partition fehlgeschlagen

 

Bei Laptops ist es empfehlenswert, die Home-Partition zu verschlüsseln. Wenn Sie sich bei Ihrem Laptop nicht anmelden können, gibt es dafür normalerweise einen einfachen Grund: Ihre Partition konnte nicht entsperrt werden.

Beim Booten müssen Sie den Passwortsatz eingeben, damit Ihre verschlüsselte Partition entsperrt wird. Wenn Sie den Passwortsatz nicht eingeben, wird der Boot-Vorgang fortgesetzt und die Partition bleibt gesperrt.

Gehen Sie folgendermaßen vor, um die verschlüsselte Partition zu entsperren:

  1. Schalten Sie zur Textkonsole um, indem Sie auf Strg–Alt–F1 drücken.

  2. Melden Sie sich als root an.

  3. Starten Sie den Entsperrvorgang erneut mit: 

    root # systemctl restart home.mount

  4. Geben Sie Ihren Passwortsatz ein, um die verschlüsselte Partition zu entsperren.

  5. Beenden Sie die Textkonsole und wechseln Sie mit Alt–F7 zum Anmeldebildschirm.

  6. Melden Sie sich wie gewöhnlich an.

40.3.4 Probleme mit dem GNOME-Desktop

 

Wenn Probleme mit dem GNOME-Desktop auftreten, stehen mehrere Möglichkeiten zur Fehlerbehebung der problembehafteten grafischen Desktop-Umgebung zur Auswahl. Das unten beschriebene empfohlene Verfahren ist die sicherste Option zum Reparieren eines beschädigten GNOME-Desktops.

Vorgehen 40.1: Fehlerbehebung für GNOME
 

  1. Starten Sie YaST und wechseln Sie zu Sicherheit und Benutzer.

  2. Öffnen Sie das Dialogfeld Benutzer- und Gruppenverwaltung und klicken Sie auf Hinzufügen.

  3. Füllen Sie die Pflichtfelder aus und klicken Sie auf OK. Damit wird ein neuer Benutzer erstellt.

  4. Melden Sie sich ab und dann als der neue Benutzer wieder an. So erhalten Sie eine frische GNOME-Umgebung.

  5. Kopieren Sie einzelne Unterverzeichnisse aus den Verzeichnissen ~/.local/ und ~/.config/ des bisherigen Benutzerkontos in die entsprechenden Verzeichnisse des neuen Benutzerkontos.

    Melden Sie sich nach jedem Kopiervorgang ab und als der neue Benutzer wieder an und prüfen Sie, ob GNOME noch ordnungsgemäß funktioniert.

  6. Wiederholen Sie den letzten Schritt, bis Sie die Konfigurationsdatei finden, die den Fehler in GNOME verursacht hat.

  7. Melden Sie sich als der bisherige Benutzer an und verschieben Sie die problembehaftete Konfigurationsdatei an einen anderen Ort. Melden Sie sich ab und dann als der bisherige Benutzer wieder an.

  8. Löschen Sie den zuvor erstellten Benutzer.

40.4 Probleme mit dem Netzwerk

 

Zahlreiche Probleme Ihres Systems stehen möglicherweise mit dem Netzwerk in Verbindung, obwohl zunächst ein anderer Eindruck entsteht. So kann beispielsweise ein Netzwerkproblem die Ursache sein, wenn sich Benutzer bei einem System nicht anmelden können. In diesem Abschnitt finden Sie eine einfache Checkliste, anhand derer Sie die Ursache jeglicher Netzwerkprobleme ermitteln können.

Vorgehen 40.2: Erkennen von Netzwerkproblemen
 

Gehen Sie zur Überprüfung der Netzwerkverbindung Ihres Computers folgendermaßen vor:

  1. Wenn Sie eine Ethernet-Verbindung nutzen, überprüfen Sie zunächst die Hardware. Vergewissern Sie sich, dass das Netzwerkkabel ordnungsgemäß am Computer und Router (oder Hub etc.) angeschlossen ist. Die Kontrolllämpchen neben dem Ethernet-Anschluss sollten beide leuchten.

    Wenn keine Verbindung hergestellt werden kann, testen Sie, ob Ihr Netzwerkkabel funktionstüchtig ist, wenn es mit einem anderen Computer verbunden wird. Wenn dies der Fall ist, ist das Problem auf Ihre Netzwerkkarte zurückzuführen. Wenn Ihre Netzwerkeinrichtung Hubs oder Switches enthält, sind diese möglicherweise auch fehlerhaft.

  2. Bei einer drahtlosen Verbindung testen Sie, ob die drahtlose Verbindung von anderen Computern hergestellt werden kann. Ist dies nicht der Fall, sollten Sie das Problem an den Administrator des drahtlosen Netzwerks weiterleiten.

  3. Nachdem Sie die grundlegende Netzwerkkonnektivität sichergestellt haben, versuchen Sie zu ermitteln, welcher Dienst nicht reagiert. Tragen Sie die Adressinformationen aller Netzwerkserver zusammen, die Bestandteil Ihrer Einrichtung sind. Suchen Sie sie entweder im entsprechenden YaST-Modul oder wenden Sie sich an Ihren Systemadministrator. In der nachfolgenden Liste sind einige der typischen Netzwerkserver aufgeführt, die Bestandteil einer Einrichtung sind; außerdem finden Sie hier die Symptome eines Ausfalls.

    DNS (Namendienst)

    Ein Namendienst, der ausgefallen ist oder Fehlfunktionen aufweist, kann die Funktionalität des Netzwerks auf vielfältige Weise beeinträchtigen. Wenn die Authentifizierung für einen lokalen Rechner über einen oder mehrere Netzwerkserver erfolgt und diese Server aufgrund von Problemen bei der Namenauflösung nicht auffindbar sind, können sich die Benutzer noch nicht einmal anmelden. Die Rechner in einem Netzwerk, das von einem ausgefallenen Nameserver verwaltet wird, können einander nicht „sehen“ und nicht miteinander kommunizieren.

    NTP (Zeitdienst)

    Ein NTP-Dienst, der ausgefallen ist oder Fehlfunktionen aufweist, kann die Kerberos-Authentifizierung und die X-Server-Funktionalität beeinträchtigen.

    NFS (Dateidienst)

    Wenn eine Anwendung Daten benötigt, die in einem NFS-eingehängten Verzeichnis gespeichert sind, kann sie nicht aufgerufen werden bzw. weist Fehlfunktionen auf, wenn dieser Dienst ausgefallen oder falsch konfiguriert ist. Im schlimmsten Fall wird die persönliche Desktop-Konfiguration eines Benutzers nicht angezeigt, wenn sein Home-Verzeichnis mit dem .gconf-Unterverzeichnis nicht gefunden wird, weil der NFS-Server ausgefallen ist.

    Samba (Dateidienst)

    Wenn eine Anwendung Daten benötigt, die in einem Verzeichnis auf einem fehlerhaften Samba-Server gespeichert sind, kann sie nicht aufgerufen werden oder weist Fehlfunktionen auf.

    NIS (Benutzerverwaltung)

    Wenn Ihr SUSE Linux Enterprise Server-System hinsichtlich der Bereitstellung der Benutzerdaten von einem fehlerhaften NIS-Server abhängig ist, können sich Benutzer nicht bei diesem Computer anmelden.

    LDAP (Benutzerverwaltung)

    Wenn Ihr SUSE Linux Enterprise Server-System hinsichtlich der Bereitstellung der Benutzerdaten von einem fehlerhaften LDAP-Server abhängig ist, können sich Benutzer nicht bei diesem Computer anmelden.

    Kerberos (Authentifizierung)

    Die Authentifizierung funktioniert nicht und die Anmeldung bei den Computern schlägt fehl.

    CUPS (Netzwerkdruck)

    Die Benutzer können nicht drucken.

  4. Überprüfen Sie, ob die Netzwerkserver aktiv sind und ob Ihre Netzwerkeinrichtung das Herstellern einer Verbindung ermöglicht:

    Wichtig
    Wichtig: Nutzungsbeschränkungen

    Das unten beschriebene Fehlersuchverfahren gilt nur für ein einfaches Setup aus Netzwerkserver/-Client, das kein internes Routing beinhaltet. Es wird davon ausgegangen, dass sowohl Server als auch Client Mitglieder desselben Subnetzes sind, ohne dass die Notwendigkeit für weiteres Routing besteht.

    1. Mit ping IP-ADRESSE/HOSTNAME (ersetzen Sie IP-ADRESSE/HOSTNAME durch den Hostnamen oder die IP-Adresse des Servers) können Sie überprüfen, ob die einzelnen Server verfügbar sind und ob vom Netzwerk aus auf sie zugegriffen werden kann. Wenn dieses Kommando erfolgreich ist, besagt dies, dass der von Ihnen gesuchte Host aktiv ist und dass der Namendienst für Ihr Netzwerk vorschriftsmäßig konfiguriert ist.

      Wenn beim Ping-Versuch die Meldung destination host unreachable zurückgegeben wird, also nicht auf den Ziel-Host zugegriffen werden kann, ist entweder Ihr System oder der gewünschte Server nicht vorschriftsmäßig konfiguriert oder ausgefallen. Überprüfen Sie, ob Ihr System erreichbar ist, indem Sie ping IP-ADRESSE oder IHR_HOSTNAME von einem anderen Computer aus ausführen. Wenn Sie von einem anderen Computer aus auf Ihren Computer zugreifen können, ist der Server nicht aktiv oder nicht vorschriftsmäßig konfiguriert.

      Wenn beim Ping-Versuch die Meldung unknown host zurückgegeben wird, der Host also nicht bekannt ist, ist der Namendienst nicht vorschriftsmäßig konfiguriert, oder der verwendete Hostname ist falsch. Weitere Prüfungen dieser Arten finden Sie unter Schritt 4.b. Wenn der Ping-Versuch weiterhin erfolglos ist, ist entweder Ihre Netzwerkkarte nicht vorschriftsmäßig konfiguriert bzw. Ihre Netzwerk-Hardware ist fehlerhaft.

    2. Mit host HOSTNAME können Sie überprüfen, ob der Hostname des Servers, mit dem Sie eine Verbindung herstellen möchten, vorschriftsmäßig in eine IP-Adresse übersetzt wird (und umgekehrt). Wenn bei diesem Kommando die IP-Adresse dieses Host zurückgegeben wird, ist der Namendienst aktiv. Wenn es bei diesem host-Kommando zu einem Problem kommt, überprüfen Sie alle Netzwerkkonfigurationsdateien, die für die Namen- und Adressauflösung auf Ihrem Host relevant sind:

      /var/run/netconfig/resolv.conf

      Mithilfe dieser Datei wissen Sie stets, welchen Nameserver und welche Domäne Sie zurzeit verwenden. Sie ist ein symbolischer Link zu /run/netconfig/resolv.conf und wird in der Regel von YaST oder DHCP automatisch angepasst. Stellen Sie sicher, dass diese Datei die nachfolgend angegebene Struktur aufweist und dass alle Netzwerkadressen und Domänennamen richtig sind: 

      search FULLY_QUALIFIED_DOMAIN_NAME
nameserver IPADDRESS_OF_NAMESERVER

      Diese Datei kann die Adresse eines oder mehrerer Namenserver enthalten, mindestens einer davon muss aber richtig sein, um die Namenauflösung für Ihren Host bereitzustellen. Wenn nötig, können Sie diese Datei auf der Registerkarte „Hostname/DNS“ des YaST-Moduls „Netzwerkeinstellungen“ anpassen.

      Wenn die Netzwerkverbindung über DHCP erfolgt, aktivieren Sie DHCP, damit der Hostname und die Namensdienstinformationen geändert werden. Wählen Sie hierzu Hostname über DHCP festlegen (kann global für alle Schnittstellen oder auch separat für die einzelnen Schnittstellen eingestellt werden) und Nameserver und Suchliste über DHCP aktualisieren im YaST-Netzwerkeinstellungsmodul (Registerkarte „Hostname/DNS“).

      /etc/nsswitch.conf

      Aus dieser Datei geht hervor, wo Linux nach Namendienstinformationen suchen soll. Sie sollte folgendes Format aufweisen: 

       ...
hosts: files dns
networks: files dns
...

      Der Eintrag dns ist von großer Bedeutung. Hiermit wird Linux angewiesen, einen externen Namenserver zu verwenden. Normalerweise werden diese Einträge automatisch von YaST verwaltet, es empfiehlt sich jedoch, dies zu überprüfen.

      Wenn alle relevanten Einträge auf dem Host richtig sind, lassen Sie Ihren Systemadministrator die DNS-Serverkonfiguration auf die richtigen Zoneninformationen hin prüfen. Detaillierte Informationen zu DNS finden Sie in Kapitel 31, Domain Name System (DNS). Wenn Sie sichergestellt haben, dass die DNS-Konfiguration auf Ihrem Host und dem DNS-Server richtig ist, überprüfen Sie als Nächstes die Konfiguration Ihres Netzwerks und Netzwerkgeräts.

    3. Wenn von Ihrem System keine Verbindung mit dem Netzwerk hergestellt werden kann und Sie Probleme mit dem Namendienst mit Sicherheit als Ursache ausschließen können, überprüfen Sie die Konfiguration Ihrer Netzwerkkarte.

      Prüfen Sie mit dem Kommando ip addr show NETZWERKGERÄT, ob dieses Gerät ordnungsgemäß konfiguriert wurde. Prüfen Sie, ob die inet address mit der Netzmaske (/MASK) ordnungsgemäß konfiguriert ist. Wenn die IP-Adresse einen Fehler enthält oder die Netzwerkmaske unvollständig ist, kann Ihre Netzwerkkonfiguration nicht verwendet werden. Führen Sie diese Überprüfung im Bedarfsfall auch auf dem Server durch.

    4. Wenn der Namensdienst und die Netzwerk-Hardware ordnungsgemäß konfiguriert und aktiv/verfügbar sind, bei einigen externen Netzwerkverbindungen jedoch nach wie vor lange Zeitüberschreitungen auftreten bzw. der Verbindungsaufbau überhaupt nicht möglich ist, können Sie mit traceroute VOLLSTÄNDIGER_DOMÄNENNAME (Ausführung als root) die Netzwerkroute dieser Anforderungen überwachen. Mit diesem Kommando werden sämtliche Gateways (Sprünge) aufgelistet, die eine Anforderung von Ihrem Computer auf ihrem Weg zu ihrem Ziel passiert. Mit ihm wird die Antwortzeit der einzelnen Sprünge (Hops) aufgelistet und es wird ersichtlich, ob dieser Sprung erreichbar ist. Verwenden Sie eine Kombination von „traceroute“ und „ping“, um die Ursache des Problems ausfindig zu machen, und informieren Sie die Administratoren.

Nachdem Sie die Ursache Ihres Netzwerkproblems ermittelt haben, können Sie es selbst beheben (wenn es auf Ihrem Computer vorliegt) oder die Administratoren Ihres Netzwerks entsprechend informieren, damit sie die Dienste neu konfigurieren bzw. die betroffenen Systeme reparieren können.

40.4.1 Probleme mit NetworkManager

 

Grenzen Sie Probleme mit der Netzwerkkonnektivität wie unter Prozedur 40.2, „Erkennen von Netzwerkproblemen“ beschrieben ein. Wenn die Ursache bei NetworkManager zu liegen scheint, gehen Sie wie folgt vor, um Protokolle abzurufen, die Hinweise für den Grund der NetworkManager-Probleme enthalten:

  1. Öffnen Sie eine Shell und melden Sie sich als root an.

  2. Starten Sie NetworkManager neu. 

    tux > sudo systemctl restart NetworkManager

  3. Öffnen Sie eine Website, beispielsweise http://www.opensuse.org, als normaler Benutzer, um zu überprüfen, ob Sie eine Verbindung herstellen können.

  4. Erfassen Sie sämtliche Informationen zum Status von NetworkManager in /var/log/NetworkManager.

Weitere Informationen zu NetworkManager finden Sie unter Kapitel 26, Verwendung von NetworkManager.

40.5 Probleme mit Daten

 

Probleme mit Daten treten auf, wenn der Computer entweder ordnungsgemäß gebootet werden kann oder nicht, in jedem Fall jedoch offensichtlich ist, dass Daten auf dem System beschädigt wurden und das System wiederhergestellt werden muss. In dieser Situation muss eine Sicherung Ihrer kritischen Daten durchgeführt werden, damit Sie wieder zu dem Zustand zurückkehren können, in dem sich Ihr System befand, als das Problem auftrat.

40.5.1 Verwalten von Partitions-Images

 

In manchen Fällen müssen Sie eine Sicherung einer ganzen Partition oder sogar der gesamten Festplatte erstellen. Im Lieferumfang von Linux ist das Werkzeug dd enthalten, das eine exakte Kopie Ihrer Festplatte erstellen kann. In Kombination mit gzip wird dabei Speicherplatz gespart.

Vorgehen 40.3: Sichern und Wiederherstellen von Festplatten
 

  1. Starten Sie eine Shell als root-Benutzer.

  2. Wählen Sie das Quellgerät aus. Typischerweise lautet es wie /dev/sda (bezeichnet als SOURCE).

  3. Entscheiden Sie, wo das Image gespeichert werden soll (bezeichnet als BACKUP_PATH). Der Speicherort darf sich nicht auf dem Quellgerät befinden. Mit anderen Worten: Wenn Sie eine Sicherung von /dev/sda erstellen, muss das Image nicht unter /dev/sda gespeichert werden.

  4. Führen Sie die Kommandos zur Erstellung einer komprimierten Image-Datei aus: 

    root # dd if=/dev/SOURCE | gzip > /BACKUP_PATH/image.gz

  5. Stellen Sie die Festplatte mithilfe der folgenden Kommandos wieder her: 

    root # gzip -dc /BACKUP_PATH/image.gz | dd of=/dev/SOURCE

Wenn Sie eine Partition nur sichern müssen, ersetzen Sie den Platzhalter QUELLE durch Ihre entsprechende Partition. In diesem Fall kann sich Ihre Image-Datei auf derselben Festplatte befinden, allerdings in einer anderen Partition.

40.5.2 Verwenden des Rettungssystems

 

Ein System kann aus mehreren Gründen nicht aktiviert und ordnungsgemäß betrieben werden. Zu den häufigsten Gründen zählen ein beschädigtes Dateisystem nach einem Systemabsturz, beschädigte Konfigurationsdateien oder eine beschädigte Bootloader-Konfiguration.

Zum Beheben dieser Situationen bietet SUSE Linux Enterprise Server ein Rettungssystem, das Sie booten können. Das Rettungssystem ist ein kleines Linux-System, das auf einen RAM-Datenträger geladen und als root-Dateisystem eingehängt werden kann. Es ermöglicht Ihnen so den externen Zugriff auf Ihre Linux-Partitionen. Mithilfe des Rettungssystems kann jeder wichtige Aspekt Ihres Systems wiederhergestellt oder geändert werden.

  • Jede Art von Konfigurationsdatei kann bearbeitet werden.

  • Das Dateisystem kann auf Fehler hin überprüft und automatische Reparaturvorgänge können gestartet werden.

  • Der Zugriff auf das installierte System kann in einer „change-root“-Umgebung erfolgen.

  • Die Bootloader-Konfiguration kann überprüft, geändert und neu installiert werden.

  • Eine Wiederherstellung ab einem fehlerhaft installierten Gerätetreiber oder einem nicht verwendbaren Kernel kann durchgeführt werden.

  • Die Größe von Partitionen kann mithilfe des parted-Kommandos verändert werden. Weitere Informationen zu diesem Werkzeug finden Sie auf der Website von GNU Parted (http://www.gnu.org/software/parted/parted.html).

Das Rettungssystem kann aus verschiedenen Quellen und von verschiedenen Speicherorten geladen werden. Am einfachsten lässt sich das Rettungssystem vom Original-Installationsmedium booten.

Anmerkung
Anmerkung: IBM Z: Starten des Rettungssystems

Unter IBM Z kann das Installationssystem zur Rettung herangezogen werden. Zum Starten des Rettungssystems beachten Sie die Anweisungen in Abschnitt 40.6, „IBM Z: Verwenden von initrd als Rettungssystem“.

  1. Legen Sie das Installationsmedium in Ihr DVD-Laufwerk ein.

  2. Booten Sie das System neu.

  3. Drücken Sie im Boot-Fenster F4 und wählen Sie DVD-ROM. Wählen Sie dann im Hauptmenü die Option Rettungssystem.

  4. Geben Sie an der Eingabeaufforderung Rescue:root ein. Ein Passwort ist nicht erforderlich.

Wenn Ihnen kein DVD-Laufwerk zur Verfügung steht, können Sie das Rettungssystem von einer Netzwerkquelle booten. Das nachfolgende Beispiel bezieht sich auf das entfernte Booten – wenn Sie ein anderes Boot-Medium verwenden, beispielsweise eine DVD, ändern Sie die Datei info entsprechend, und führen Sie den Boot-Vorgang wie bei einer normalen Installation aus.

  1. Geben Sie die Konfiguration Ihres PXE-Boot-Setups ein und fügen Sie die Zeilen install=protocol://instsource und rescue=1 hinzu. Wenn das Reparatursystem gestartet werden soll, verwenden Sie stattdessen repair=1. Wie bei einer normalen Installation steht PROTOCOL für eines der unterstützten Netzwerkprotokolle (NFS, HTTP, FTP usw.) und INSTSOURCE für den Pfad zu Ihrer Netzwerkinstallationsquelle.

  2. Booten Sie das System mit „Wake on LAN“, wie im Book “Bereitstellungshandbuch”, Chapter 17 “Vorbereiten der Netzwerk-Boot-Umgebung”, Section 17.5 “Verwenden von Wake-on-LAN für Fernaktivierungen” erläutert.

  3. Geben Sie an der Eingabeaufforderung Rescue:root ein. Ein Passwort ist nicht erforderlich.

Sobald Sie sich im Rettungssystem befinden, können Sie die virtuellen Konsolen verwenden, die über die Tasten Alt–F1 bis Alt–F6 aufgerufen werden.

Eine Shell und viele andere hilfreiche Dienstprogramme, beispielsweise das mount-Programm, stehen im Verzeichnis /bin zur Verfügung. Das Verzeichnis /sbin enthält wichtige Datei- und Netzwerkdienstprogramme, mit denen das Dateisystem überprüft und repariert werden kann. In diesem Verzeichnis finden Sie auch die wichtigsten Binärdateien für die Systemwartung, beispielsweise fdisk, mkfs, mkswap, mount und shutdown, ip und ss für die Netzwerkwartung. Das Verzeichnis /usr/bin enthält den vi-Editor, find, less sowie SSH.

Die Systemmeldungen können über das Kommando dmesg angezeigt werden; mit journalctl rufen Sie das Systemprotokoll ab.

40.5.2.1 Überprüfen und Bearbeiten von Konfigurationsdateien

 

Als Beispiel für eine Konfiguration, die mithilfe des Rettungssystems repariert werden kann, soll eine beschädigte Konfigurationsdatei dienen, die das ordnungsgemäße Booten des Systems verhindert. Dieses Problem kann mit dem Rettungssystem behoben werden.

Gehen Sie zum Bearbeiten einer Konfigurationsdatei folgendermaßen vor:

  1. Starten Sie das Rettungssystem mithilfe einer der oben erläuterten Methoden.

  2. Verwenden Sie zum Einhängen eines root-Dateisystems unter /dev/sda6 in das Rettungssystem folgendes Kommando: 

    tux > sudo mount /dev/sda6 /mnt

    Sämtliche Verzeichnisse des Systems befinden sich nun unter /mnt

  3. Wechseln Sie in das eingehängte root -Dateisystem: 

    tux > sudo cd /mnt

  4. Öffnen Sie die fehlerhafte Konfigurationsdatei im vi-Editor. Passen Sie die Konfiguration an und speichern Sie sie.

  5. Hängen Sie das root-Dateisystem aus dem Rettungssystem aus: 

    tux > sudo umount /mnt

  6. Booten Sie den Computer neu.

40.5.2.2 Reparieren und Überprüfen von Dateisystemen

 

Generell ist das Reparieren von Dateisystemen auf einem zurzeit aktiven System nicht möglich. Bei ernsthaften Problemen ist möglicherweise nicht einmal das Einhängen Ihres root-Dateisystems möglich und das Booten des Systems endet unter Umständen mit einer so genannten „Kernel-Panic“. In diesem Fall ist nur die externe Reparatur des Systems möglich. Das System enthält die Dienstprogramme für die Überprüfung und Reparatur der Dateisysteme btrfs, ext2, ext3, ext4, xfs, dosfs und vfat. Nutzen Sie das Kommando fsck.DATEISYSTEM. Wenn Sie beispielsweise eine Dateisystemprüfung für btrfs ausführen möchten, verwenden Sie fsck.btrfs.

40.5.2.3 Zugriff auf das installierte System

 

Wenn Sie vom Rettungssystem aus auf das installierte System zugreifen müssen, ist dazu eine change-root-Umgebung erforderlich. Beispiele: Bearbeiten der Bootloader-Konfiguration oder Ausführen eines Dienstprogramms zur Hardwarekonfiguration.

Gehen Sie zur Einrichtung einer change-root-Umgebung, die auf dem installierten System basiert, folgendermaßen vor:

  1. Tipp
    Tipp: Importieren von LVM-Volume-Gruppen

    Wenn Sie ein LVM-Setup verwenden (allgemeinere Informationen siehe Book “Storage Administration Guide”), importieren Sie alle vorhandenen Volume-Gruppen, damit Sie das oder die Geräte auffinden und einhängen können: 

    rootvgimport -a

    Ermitteln Sie mit lsblk, welcher Knoten zur Stammpartition gehört. Im Beispiel ist dies /dev/sda2: 

    tux > lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda           8:0    0 149,1G  0 disk
├─sda1        8:1    0     2G  0 part  [SWAP]
├─sda2        8:2    0    20G  0 part  /
└─sda3        8:3    0   127G  0 part
  └─cr_home 254:0    0   127G  0 crypt /home

  2. Hängen Sie die Stammpartition vom installierten System aus ein: 

    tux > sudo mount /dev/sda2 /mnt

  3. Hängen Sie die Partitionen /proc, /dev und /sys ein: 

    tux > sudo mount -t proc none /mnt/proc
tux > sudo mount --rbind /dev /mnt/dev
tux > sudo mount --rbind /sys /mnt/sys

  4. Nun können Sie per „change root“ in die neue Umgebung wechseln und dabei die bash-Shell beibehalten: 

    tux > chroot /mnt /bin/bash

  5. Abschließend hängen Sie die restlichen Partitionen vom installierten System ein: 

    tux > mount -a

  6. Nun können Sie auf das installierte System zugreifen. Hängen Sie vor dem Reboot des Systems die Partitionen mit umount -a aus und verlassen Sie die „change-root“-Umgebung mit exit.

Warnung
Warnung: Nutzungsbeschränkungen

Obwohl Sie über uneingeschränkten Zugriff auf die Dateien und Anwendungen des installierten Systems verfügen, gibt es einige Beschränkungen. Der Kernel, der ausgeführt wird, ist der Kernel, der mit dem Rettungssystem gebootet wurde, nicht mit der change-root-Umgebung. Er unterstützt nur essenzielle Hardware und das Hinzufügen von Kernel-Modulen über das installierte System ist nur möglich, wenn die Kernel-Versionen genau übereinstimmen. Überprüfen Sie immer die Version des aktuell ausgeführten (Rettungssytem-) Kernels mit uname -r und stellen Sie fest, ob im Verzeichnis /lib/modules in der change-root-Umgebung passende Unterverzeichnisse vorhanden sind. Wenn dies der Fall ist, können Sie die installierten Module verwenden. Andernfalls müssen Sie diese in den richtigen Version von einem anderen Medium, z. B. einem Flash-Laufwerk, bereitstellen. In den meisten Fällen weicht die Kernel-Version des Rettungssystems von der des installierten ab – dann können Sie z. B. nicht einfach auf eine Soundkarte zugreifen. Der Aufruf einer grafischen Bedienoberfläche ist ebenfalls nicht möglich.

Beachten Sie außerdem, dass Sie die „change-root“-Umgebung verlassen, wenn Sie die Konsole mit Alt–F1 bis Alt–F6 umschalten.

40.5.2.4 Bearbeiten und erneutes Installieren des Bootloaders

 

In einigen Fällen kann ein System aufgrund einer beschädigten Bootloader-Konfiguration nicht gebootet werden. Die Start-Routinen sind beispielsweise nicht in der Lage, physische Geräte in die tatsächlichen Speicherorte im Linux-Dateisystem zu übersetzen, wenn der Bootloader nicht ordnungsgemäß funktioniert.

Gehen Sie wie folgt vor, um die Bootloader-Konfiguration zu überprüfen und den Bootloader neu zu installieren:

  1. Führen Sie die unter Abschnitt 40.5.2.3, „Zugriff auf das installierte System“ erläuterten erforderlichen Schritte für den Zugriff auf das installierte System aus.

  2. Prüfen Sie, ob der GRUB 2-Bootloader auf dem System installiert ist. Falls nicht, installieren Sie das Paket grub2 und führen Sie Folgendes aus: 

    tux > sudo grub2-install /dev/sda

  3. Prüfen Sie, ob die nachfolgend angegebenen Dateien gemäß den in Kapitel 14, Der Bootloader GRUB 2 erläuterten GRUB 2-Konfigurationsgrundlagen ordnungsgemäß konfiguriert sind, und wenden Sie gegebenenfalls die Fehlerbehebungen an.

    • /etc/default/grub

    • /boot/grub2/device.map (optionale Datei; nur vorhanden, wenn sie manuell erstellt wurde)

    • /boot/grub2/grub.cfg (diese Datei wird automatisch generiert; nicht bearbeiten)

    • /etc/sysconfig/bootloader

  4. Installieren Sie den Bootloader mit folgender Befehlssequenz neu: 

    tux > sudo grub2-mkconfig -o /boot/grub2/grub.cfg

  5. Hängen Sie die Partitionen aus, melden Sie sich von der „change-root“-Umgebung ab und führen Sie den Reboot des Systems durch: 

    tux > umount -a
exit
reboot

40.5.2.5 Korrektur der Kernel-Installation

 

Ein Kernel-Update kann einen neuen Fehler verursachen, der sich auf Ihr System auswirken kann. Es kann z. B. ein Treiber für eine Hardwarekomponente in Ihrem System falsch sein, weshalb Sie nicht auf die Komponente zugreifen und diese nicht verwenden können. Kehren Sie in diesem Fall zum letzten funktionierenden Kernel zurück (sofern er im System verfügbar ist) oder installieren Sie den Original-Kernel vom Installationsmedium.

Tipp
Tipp: So erhalten Sie die aktuellsten Kernels nach der Aktualisierung

Um Fehler beim Booten durch eine fehlerhaften Kernel-Aktualisierung zu vermeiden, können Sie die Multiversionsfunktion für Kernel nutzen und libzypp mitteilen, welche Kernel Sie nach der Aktualisierung erhalten möchten.

Damit z. B. immer die beiden letzten Kernels und der aktuell ausgeführte erhalten bleiben, fügen Sie 

multiversion.kernels = latest,latest-1,running

zur Datei /etc/zypp/zypp.conf hinzu. Weitere Informationen zu diesem Thema finden Sie unter dem Stichwort Book “Bereitstellungshandbuch”, Chapter 23 “Installieren von mehreren Kernel-Versionen”.

Ähnlich verhält es sich, wenn Sie einen defekten Treiber für ein nicht durch SUSE Linux Enterprise Server unterstütztes Gerät neu installieren oder aktualisieren müssen. Wenn z. B. ein Hardwarehersteller ein bestimmtes Gerät verwendet, wie einen Hardware-RAID-Controller, für den es erforderlich ist, dass ein Binärtreiber durch das Betriebssystem erkannt wird. Der Hersteller veröffentlicht in der Regel ein Treiberupdate (DUD) mit der korrigierten oder aktualisierten Version des benötigten Treibers.

In beiden Fällen müssen Sie im Rettungsmodus auf das installierte System zugreifen und das mit dem Kernel zusammenhängende Problem beheben, da das System andernfalls nicht korrekt booten wird:

  1. Booten Sie von den SUSE Linux Enterprise Server-Installationsmedien.

  2. Überspringen Sie diese Schritt, wenn Sie eine Wiederherstellung nach einer fehlerhaften Kernel-Aktualisierung durchführen. Wenn Sie eine Driver Update Disk (DUD) verwenden, drücken Sie F6, um die Treiberaktualisierung nach der Anzeige des Bootmenüs zu laden, wählen Sie den Pfad oder die URL für die Treiberaktualisierung aus und bestätigen Sie die Auswahl mit Ja.

  3. Wählen Sie im Bootmenü den Eintrag Rettungssystem, und drücken Sie Eingabetaste. Wenn Sie eine DUD verwenden, werden Sie aufgefordert, den Speicherplatz der Treiberaktualisierung anzugeben.

  4. Geben Sie an der Eingabeaufforderung Rescue:root ein. Ein Passwort ist nicht erforderlich.

  5. Hängen Sie das Zielsystem manuell ein und führen Sie „change root“ in die neue Umgebung durch. Weitere Informationen finden Sie im Abschnitt 40.5.2.3, „Zugriff auf das installierte System“.

  6. Wenn Sie eine DUD verwenden, installieren oder aktualisieren Sie das fehlerhafte Treiberpaket. Stellen Sie stets sicher, dass die installierte Kernel-Version exakt mit der Version des Treibers übereinstimmt, den Sie installieren möchten.

    Wenn Sie eine fehlerhafte Installation einer Treiberaktualisierung korrigieren, können Sie nach dem folgenden Verfahren den Originaltreiber vom Installationsmedium installieren.

    1. Identifizieren Sie Ihr DVD-Laufwerk mit hwinfo --cdrom und hängen Sie es mit mount /dev/sr0 /mnt ein.

    2. Navigieren Sie zum Verzeichnis, in dem Ihre Kernel-Dateien auf der DVD gespeichert sind, z. B. cd /mnt/suse/x86_64/.

    3. Installieren Sie die benötigten kernel-*-, kernel-*-base- und kernel-*-extra-Pakete mit dem Kommando rpm -i.

  7. Aktualisieren Sie Konfigurationsdateien und initialisieren Sie den Bootloader gegebenenfalls neu. Weitere Informationen finden Sie im Abschnitt 40.5.2.4, „Bearbeiten und erneutes Installieren des Bootloaders“.

  8. Entfernen Sie alle bootbaren Medien aus dem Systemlaufwerk und booten Sie neu.

40.6 IBM Z: Verwenden von initrd als Rettungssystem

 

Wenn der Kernel von SUSE® Linux Enterprise Server für IBM Z aktualisiert oder geändert wird, kann es zu einem versehentlichen Neustart des Systems in einem instabilen Zustand kommen, sodass Fehler bei Standardprozeduren von IPLing im installierten System auftreten. In diesem Fall können Sie das Installationssystem zur Rettung heranziehen.

Führen Sie den IPL-Vorgang für SUSE Linux Enterprise Server für das IBM Z-Installationssystem gemäß den Anweisungen im Book “Bereitstellungshandbuch”, Chapter 5 “Installation unter IBM Z und LinuxONE”, Section 5.3 “Vorbereitung der Installation” aus. Wählen Sie Start Installation (Installation starten), und geben Sie alle erforderlichen Parameter ein. Nach dem Laden des Installationssystems werden Sie aufgefordert, den Anzeigetyp für die Steuerung der Installation anzugeben. Wählen Sie SSH aus. Nun können Sie sich mit SSH als root ohne Passwort beim System anmelden.

Zu diesem Zeitpunkt sind noch keine Festplatten konfiguriert. Sie müssen Sie konfigurieren, um fortfahren zu können.

Vorgehen 40.4: Konfigurieren von DASDs
 

  1. Konfigurieren Sie DASDs mit folgendem Befehl: 

    dasd_configure 0.0.0150 1 0

    DASD wird an den Kanal 0.0.0150 angeschlossen. Mit 1 wird die Festplatte aktiviert (durch eine 0 an dieser Stelle würde die Festplatte deaktiviert). Die 0 steht für „kein DIAG-Modus“ für den Datenträger (mit einer 1 würde DAIG an dieser Stelle für den Zugriff auf die Festplatte aktiviert).

  2. Nun ist DASD online (dies kann mit dem Befehl cat /proc/partitions überprüft werden) und kann für nachfolgende Befehle verwendet werden.

Vorgehen 40.5: Konfigurieren einer zFCP-Festplatte
 

  1. Für die Konfiguration einer zFCP-Festplatte muss zunächst der zFCP-Adapter konfiguriert werden. Das geschieht mit folgendem Befehl: 

    zfcp_host_configure 0.0.4000 1

    0.0.4000 ist der Kanal, an den der Adapter angeschlossen ist. Die 1 steht für „aktivieren“ (mit einer 0 an dieser Stelle würde der Adapter deaktiviert).

  2. Nach dem Aktivieren des Adapters kann die Festplatte konfiguriert werden. Das geschieht mit folgendem Befehl: 

    zfcp_disk_configure 0.0.4000 1234567887654321 8765432100000000  1

    0.0.4000 ist die zuvor verwendete Kanal-ID, 1234567887654321 ist die WWPN (World wide Port Number) und 8765432100000000 die LUN (logical unit number). Mit 1 wird die Festplatte aktiviert (durch eine 0 an dieser Stelle würde die Festplatte deaktiviert).

  3. Nun ist die zFCP-Festplatte online (dies kann mit dem Befehl cat /proc/partitions überprüft werden) und kann für nachfolgende Befehle verwendet werden.

Damit ist das Rettungssystem vollständig eingerichtet, und Sie können mit der Reparatur des installierten Systems beginnen. Weitere Informationen zur Reparatur der häufigsten Probleme finden Sie in Abschnitt 40.5.2, „Verwenden des Rettungssystems“.

A Ein Beispielnetzwerk

 

Dieses Beispielnetzwerk wird in allen Kapiteln über das Netzwerk in der Dokumentation zu SUSE® Linux Enterprise Server herangezogen.

Image

B GNU licenses

 

This appendix contains the GNU Free Documentation License version 1.2.

GNU Free Documentation License

 

Copyright (C) 2000, 2001, 2002 Free Software Foundation, Inc. 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.

The purpose of this License is to make a manual, textbook, or other functional and useful document "free" in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or non-commercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others.

This License is a kind of "copyleft", which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software.

We have designed this License to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference.

This License applies to any manual or other work, in any medium, that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. Such a notice grants a world-wide, royalty-free license, unlimited in duration, to use that work under the conditions stated herein. The "Document", below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as "you". You accept the license if you copy, modify or distribute the work in a way requiring permission under copyright law.

A "Modified Version" of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language.

A "Secondary Section" is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them.

The "Invariant Sections" are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License. If a section does not fit the above definition of Secondary then it is not allowed to be designated as Invariant. The Document may contain zero Invariant Sections. If the Document does not identify any Invariant Sections then there are none.

The "Cover Texts" are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License. A Front-Cover Text may be at most 5 words, and a Back-Cover Text may be at most 25 words.

A "Transparent" copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, that is suitable for revising the document straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup, or absence of markup, has been arranged to thwart or discourage subsequent modification by readers is not Transparent. An image format is not Transparent if used for any substantial amount of text. A copy that is not "Transparent" is called "Opaque".

Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML, PostScript or PDF designed for human modification. Examples of transparent image formats include PNG, XCF and JPG. Opaque formats include proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML, PostScript or PDF produced by some word processors for output purposes only.

The "Title Page" means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, "Title Page" means the text near the most prominent appearance of the work's title, preceding the beginning of the body of the text.

A section "Entitled XYZ" means a named subunit of the Document whose title either is precisely XYZ or contains XYZ in parentheses following text that translates XYZ in another language. (Here XYZ stands for a specific section name mentioned below, such as "Acknowledgements", "Dedications", "Endorsements", or "History".) To "Preserve the Title" of such a section when you modify the Document means that it remains a section "Entitled XYZ" according to this definition.

The Document may include Warranty Disclaimers next to the notice which states that this License applies to the Document. These Warranty Disclaimers are considered to be included by reference in this License, but only as regards disclaiming warranties: any other implication that these Warranty Disclaimers may have is void and has no effect on the meaning of this License.

You may copy and distribute the Document in any medium, either commercially or non-commercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3.

You may also lend copies, under the same conditions stated above, and you may publicly display copies.

If you publish printed copies (or copies in media that commonly have printed covers) of the Document, numbering more than 100, and the Document's license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects.

If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages.

If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a computer-network location from which the general network-using public has access to download using public-standard network protocols a complete Transparent copy of the Document, free of added material. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public.

It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document.

You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version:

  1. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission.

  2. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least five of the principal authors of the Document (all of its principal authors, if it has fewer than five), unless they release you from this requirement.

  3. State on the Title page the name of the publisher of the Modified Version, as the publisher.

  4. Preserve all the copyright notices of the Document.

  5. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices.

  6. Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Version under the terms of this License, in the form shown in the Addendum below.

  7. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document's license notice.

  8. Include an unaltered copy of this License.

  9. Preserve the section Entitled "History", Preserve its Title, and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version as given on the Title Page. If there is no section Entitled "History" in the Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modified Version as stated in the previous sentence.

  10. Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the "History" section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission.

  11. For any section Entitled "Acknowledgements" or "Dedications", Preserve the Title of the section, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein.

  12. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles.

  13. Delete any section Entitled "Endorsements". Such a section may not be included in the Modified Version.

  14. Do not retitle any existing section to be Entitled "Endorsements" or to conflict in title with any Invariant Section.

  15. Preserve any Warranty Disclaimers.

If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version's license notice. These titles must be distinct from any other section titles.

You may add a section Entitled "Endorsements", provided it contains nothing but endorsements of your Modified Version by various parties--for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard.

You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one.

The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version.

You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice, and that you preserve all their Warranty Disclaimers.

The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work.

In the combination, you must combine any sections Entitled "History" in the various original documents, forming one section Entitled "History"; likewise combine any sections Entitled "Acknowledgements", and any sections Entitled "Dedications". You must delete all sections Entitled "Endorsements".

You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects.

You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document.

A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, is called an "aggregate" if the copyright resulting from the compilation is not used to limit the legal rights of the compilation's users beyond what the individual works permit. When the Document is included in an aggregate, this License does not apply to the other works in the aggregate which are not themselves derivative works of the Document.

If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one half of the entire aggregate, the Document's Cover Texts may be placed on covers that bracket the Document within the aggregate, or the electronic equivalent of covers if the Document is in electronic form. Otherwise they must appear on printed covers that bracket the whole aggregate.

Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License, and all the license notices in the Document, and any Warranty Disclaimers, provided that you also include the original English version of this License and the original versions of those notices and disclaimers. In case of a disagreement between the translation and the original version of this License or a notice or disclaimer, the original version will prevail.

If a section in the Document is Entitled "Acknowledgements", "Dedications", or "History", the requirement (section 4) to Preserve its Title (section 1) will typically require changing the actual title.

You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.

The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See https://www.gnu.org/copyleft/.

Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License "or any later version" applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation. 

Copyright (c) YEAR YOUR NAME.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.2
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
A copy of the license is included in the section entitled “GNU
Free Documentation License”.

If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, replace the “with...Texts.” line with this: 

with the Invariant Sections being LIST THEIR TITLES, with the
Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST.

If you have Invariant Sections without Cover Texts, or some other combination of the three, merge those two alternatives to suit the situation.

If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel under your choice of free software license, such as the GNU General Public License, to permit their use in free software.