Eine Shell lässt sich aufrufen als:

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

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

Daneben verwendet die Bash-Shell einige weitere Dateien:

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.

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

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

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" "" ""

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

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 http://www.cyberciti.biz/nixcraft/linux/docs/uniqlinuxfeatures/lsst/ch03sec02.html.

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

Wenn Sie als normaler Benutzer angemeldet sind, können Sie alle Befehle als root ausführen, indem Sie sudo vor den Befehl setzen. Eine Eingabeaufforderung für das root-Passwort erscheint und bei erfolgreicher Authentifizierung wird 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

Tipp: E/A-Umleitung

Die E/A-Umleitung funktioniert nicht so, wie Sie es wahrscheinlich erwarten:

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

Nur die echo-/cat-Binärdatei wird mit erhöhten Berechtigungen ausgeführt. Die Umleitung erfolgt über die Shell des Benutzers mit Benutzerberechtigungen. Sie können entweder eine Shell starten, wie in Abschnitt 2.1.2, „Starten einer Shell“ beschrieben, oder stattdessen das Dienstprogramm dd verwenden:

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

Es kann mühselig sein, jedem Befehl sudo voranstellen zu müssen. Sie könnten eine Shell als sudo bash-Kommando angeben. Es wird jedoch empfohlen, einen der integrierten Mechanismen zum Starten einer Shell zu verwenden:

Standardmäßig gibt sudo keine Umgebungsvariablen weiter:

tux > ENVVAR=test env | grep ENVVAR
ENVVAR=test
tux > ENVVAR=test sudo env | grep ENVVAR
root's password:
1
tux > 

Dieses Verhalten kann mit der Option env_reset geändert werden. Siehe Tabelle 2.1, „Hilfreiche Flags und Optionen“.

Die Hauptkonfigurationsdatei mit den Richtlinien für sudo ist /etc/sudoers. Da es möglich ist, sich selbst aus dem System auszusperren, wenn in dieser Datei Fehler enthalten sind, wird dringend empfohlen, visudo zum Bearbeiten zu verwenden. Gleichzeitige Änderungen an der geöffneten Datei werden so verhindert und es wird vor dem Speichern der Änderungen auf Syntaxfehler geprüft.

Trotz des Namens können Sie andere Editoren als „vi“ verwenden, indem Sie die Umgebungsvariable EDITOR festlegen. Beispiel:

sudo EDITOR=/usr/bin/nano visudo

Die Datei /etc/sudoers selbst hingegen wird von den Systempaketen bereitgestellt und Änderungen können bei Aktualisierungen verloren gehen. Daher wird empfohlen, benutzerdefinierte Konfigurationen in Dateien im Verzeichnis /etc/sudoers.d/ abzulegen. Jede Datei in diesem Verzeichnis ist automatisch eingeschlossen. Um eine Datei in diesem Unterverzeichnis zu erstellen oder zu bearbeiten, führen Sie das folgende Kommando aus:

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

Alternativ mit einem anderen Editor (beispielsweise nano):

sudo EDITOR=/usr/bin/nano visudo -f /etc/sudoers.d/NAME

Anmerkung: Ignorierte Dateien in /etc/sudoers.d

Das Kommando #includedir in /etc/sudoers, das für /etc/sudoers.d verwendet wird, ignoriert Dateien, die mit einer Tilde (~) enden oder einen Punkt (.) enthalten.

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

In den sudoers-Konfigurationsdateien gibt es zwei Optionstypen: Strings und Flags. Strings 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 a # gets 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

Defaults targetpw # Turn targetpw flag ON

Defaults !rootpw # Turn rootpw flag OFF

Defaults env_reset # Turn env_reset flag ON

# 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

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

Die Regeln in der sudoers-Konfiguration können sehr komplex sein. In diesem Abschnitt werden daher nur die Grundlagen abgedeckt. Jede Regel befolgt ein Basisschema ([] markiert optionale Teile):

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

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: Gefährliche Konstrukte

Konstrukte des Typs

ALL ALL = ALL

dürfen nicht ohne Defaults targetpw verwendet werden, sonst kann jeder Kommandos als root ausführen.

In Anwendungsfällen mit besonderen Einschränkungen („Benutzer X kann Kommando Y nur als root“ ausführen) ist dies nicht möglich. In anderen Fällen ist es weiterhin vorteilhaft, eine Art Trennung zu haben. Grundsätzlich können Mitglieder der Gruppe wheel alle Kommandos mit sudo als „root“ ausführen.

Wenn Sie Grafikanwendungen mit sudo starten, stoßen Sie auf den folgenden Fehler:

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

YaST wählt die ncurses-Schnittstelle und nicht die grafische Schnittstelle.

Um X.Org in Anwendungen zu verwenden, die mit sudo gestartet werden, müssen die Umgebungsvariablen DISPLAY und XAUTHORITY übertragen werden. Um dies zu konfigurieren, erstellen Sie die Datei /etc/sudoers.d/xorg (siehe Abschnitt 2.2.1, „Bearbeiten der Konfigurationsdateien“) und fügen Sie die folgende Zeile hinzu:

Defaults env_keep += "DISPLAY XAUTHORITY"

Wenn die Variable XAUTHORITY nicht bereits entsprechend festgelegt ist, legen Sie sie wie folgt fest:

export XAUTHORITY=~/.Xauthority

Jetzt können X.Org-Anwendungen wie üblich ausgeführt werden:

sudo yast2

Um Zeit zu sparen können die einzelnen YaST-Module direkt gestartet werden. Um ein Modul zu starten, geben Sie Folgendes ein:

yast <module_name>

Eine Liste aller auf Ihrem System verfügbaren Modulnamen können Sie mit yast -l oder yast --list anzeigen. Das Netzwerkmodul beispielsweise wird mit yast lan gestartet.

Wenn Sie den Namen eines Pakets kennen und das Paket von einer Ihrer aktiven Installations-Repositorys bereitgestellt wird, können Sie das Paket mithilfe der Kommandozeilenoption -i installieren.

yast -i <package_name>

oder

yast --install <package_name>

PACKAGE_NAME kann ein einzelner kurzer Paketname sein (beispielsweise gvim), solche Pakete werden mit Abhängigkeitsüberprüfung installiert, oder der vollständige Pfad zu einem RPM-Paket, das ohne Abhängigkeitsüberprüfung installiert wird.

Wenn Sie ein kommandozeilenbasiertes Softwareverwaltungs-Dienstprogramm mit Funktionen benötigen, die über die von YaST hinausgehen, sollten Sie möglicherweise Zypper verwenden. Dieses Dienstprogramm verwendet die Softwareverwaltungsbibliothek, die auch die Grundlage des YaST-Paket-Managers bildet. Die grundlegende Verwendung von Zypper wird in Abschnitt 6.1, „Verwenden von zypper“ erläutert.

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. Um die verfügbaren Optionen eines Moduls anzuzeigen, geben Sie Folgendes ein:

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.

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.

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

tux > sudo zypper -v install --from factory aspell-de aspell-fr

Mit der Option --from bleiben alle Repositorys aktiviert (damit alle Abhängigkeiten aufgelöst werden können), wenn das Paket aus dem angegebenen Repository abrufen wird.

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

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

tux > sudo zypper install PACKAGE_NAME
sudo zypper remove PACKAGE_NAME

Warnung: Entfernen Sie keine obligatorischen Systempakete

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

tux > sudo zypper install emacs -vim

tux > sudo zypper remove emacs +vim

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

tux > sudo zypper rm PACKAGE_NAME --clean-deps

tux > sudo zypper --non-interactive install PACKAGE_NAME

tux > zypper source-install PACKAGE_NAME

tux > sudo zypper source-install -D PACKAGE_NAME

tux > sudo zypper source-install -d PACKAGE_NAME

tux > zypper search -t srcpackage

tux > zypper source-download

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

tux > zypper verify

tux > sudo zypper install-new-recommends

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 “Bereitstellungshandbuch”, Chapter 19 “Upgraden von SUSE Linux Enterprise” erläutert.

tux > sudo zypper patch

tux > sudo zypper patch --with update

tux > sudo zypper patch --with-optional

tux > sudo zypper patch --bugzilla=NUMBER

tux > sudo zypper patch --cve=NUMBER

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

tux > sudo zypper patch --updatestack-only

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

tux > sudo zypper update

tux > sudo zypper update PACKAGE_NAME
sudo zypper install PACKAGE_NAME

tux > zypper list-updates

tux > sudo zypper list-updates --all

tux > sudo zypper packages --orphaned

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->
[...]

Das Ausgabeformat von zypper ps kann wie folgt gesteuert werden:

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

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:

tux > zypper repos
# | Alias        | Name          | Enabled | Refresh
--+--------------+---------------+---------+--------
1 | SLEHA-12-GEO | SLEHA-12-GEO  | Yes     | No
2 | SLEHA-12     | SLEHA-12      | Yes     | No
3 | SLES12       | SLES12        | 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

tux > sudo zypper addrepo URI ALIAS

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

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

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

tux > sudo zypper renamerepo 'Mozilla Firefox' firefox

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.

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

tux > zypper info --requires MozillaFirefox

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.

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.

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 finden Sie in Kapitel 7, Systemwiederherstellung und Snapshot-Verwaltung mit Snapper.

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 http://en.opensuse.org/SDB:Zypper_usage. Eine Liste der Software-Änderungen in der aktuellen SUSE Linux Enterprise Server-Version finden Sie unter http://en.opensuse.org/openSUSE:Zypper versions.

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.

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:

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.

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.

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. Weitere Informationen hierzu finden Sie unter Tabelle 6.1, „Die wichtigsten RPM-Abfrageoptionen“.

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

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 12

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.11.2-15.1.x86_64
wget-1.14-17.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.

#! /bin/sh
for i in $(rpm -q -a -l | grep $1); do
    echo "\"$i\" is in package:"
    rpm -q -f $i
    echo ""
done

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 an, die seit der Installation geändert wurden. rpm verwendet acht verschiedene Zeichen als Hinweis auf die folgenden Änderungen:

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.

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

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

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

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

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 seit SUSE Linux Enterprise Server 12 nicht mehr verwendet wird. Benötigen Sie die Funktion weiterhin, verwenden Sie die Option --buildroot als Alternative. Detailliertere Hintergrundinformationen finden Sie in der Support-Datenbank unter https://www.suse.com/support/kb/doc?id=7017104.

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.

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 13 “Installieren bzw. Entfernen von Software”.

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:

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

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.

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

tux > sudo snapper -c lvm create-config --fstype="lvm(xfs)" /thin_lvm

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.

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.

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 in Abschnitt 7.5, „Erstellen und Bearbeiten von Snapper-Konfigurationen“.

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. Weitere Informationen finden Sie in 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.

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 hierzu erhalten 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.

root # snapper --iso list
Type   | # |     | Cleanup | Description           | Userdata
-------+---+ ... +---------+-----------------------+--------------
single | 0 |     |         | current               |
single | 1 |     |         | first root filesystem |
single | 2 |     | number  | after installation    | important=yes

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

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.

Abbildung 7.1: Bootloader: Snapshots #

 

Die einzelnen Snapshot-Einträge im Bootloader sind an ihrem Namensschema leicht erkennbar:

[*]1OS2 (KERNEL3,DATE4TTIME5,DESCRIPTION6)

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.

Ein vollständiges System-Rollback, bei dem der exakte Zustand des gesamten Systems zum Zeitpunkt eines Snapshots wiederhergestellt wird, ist nicht möglich.

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.

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

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

Das Kommando snapper bietet verschiedene Subkommandos für die Verwaltung von vorhandenen Konfigurationen. Sie können sie auflisten, anzeigen, löschen und bearbeiten: