6.2    Pakete im Eigenbau

Neben der Vielzahl an Software, die über die Repositorys bezogen werden kann, gibt es auch Software, die lediglich als Quellcode zur Verfügung steht. Um solche Programme auf Ihrem System betreiben zu können, müssen Sie sie kompilieren. Hierfür verwenden Sie den Ihnen vermutlich bereits bekannten Dreisprung:

daniel@example:/usr/local/packet# ./configure
daniel@example:/usr/local/packet# make
daniel@example:/usr/local/packet# sudo make install

Listing 6.5    Kompilierung im Dreisprung

Dies ist natürlich eine adäquate Möglichkeit, Software auf »einem« System zu verwenden. Wenn Sie aber mehrere Systeme der gleichen Architektur mit dem gleichen Betriebssystem verwenden, können Sie den Quellcode auch in ein Paket schnüren, um so die Software einfach zu verteilen, eine Update-Sicherheit zu erzeugen oder auch Patches effektiv zu verteilen. In diesem Abschnitt erfahren Sie alles zu Paketen: wie Sie diese aus einem tarball[ 8 ] erzeugen, wie Sie Patches einspielen und wie Sie Update-Pakete erstellen.

6.2.1    Vorbereitungen

Damit Sie Pakete erzeugen können, müssen einige Pakete auf Ihrem System vorhanden sein, die zur Erstellung notwendig sind: die sogenannte Build-Umgebung. Keine Sorge, Sie müssen die benötigten Pakete nicht einzeln identifizieren und separat installieren. In den Paketquellen sind Metapakete oder Gruppen vorhanden, die alle benötigten Pakete enthalten.

Auf Debian/Ubuntu müssen Sie das Metapaket aus Listing 6.6 installieren:

root@ubuntu:~$ apt install build-essential   ### bei Ubuntu zusätzlich: debhelper

Listing 6.6    Build-Umgebung installieren unter Debian/Ubuntu

Auf einem CentOS-System müssen Sie die Gruppe aus Listing 6.7 installieren:

[root@centos ~]# yum -y groupinstall Development\ Tools

Listing 6.7    Build-Umgebung installieren unter CentOS

Auf einem openSUSE-leap-System wiederum können Sie die benötigten Pakete über Muster (engl. pattern) installieren lassen:

leap:~> sudo zypper install -t pattern devel_C_C++ devel_basis devel_rpm_build

Listing 6.8    Build-Umgebung installieren unter openSUSE Leap

6.2.2    Am Anfang war das Makefile

Software, die nicht in den Repositorys zur Verfügung steht, wird in der Regel von den Entwicklern als tgz- oder auch tar.gz-Datei zur Verfügung gestellt. Aus dieser Datei entpacken Sie den Quellcode und kompilieren dann das Programm. Um selbst geschriebene Software so zur Verfügung zu stellen, muss diese erst mal in die richtige Form gebracht werden. Dazu dient das Makefile, auf das das configure-Skript zugreift, das das Programm entsprechend Ihrem System verarbeitet.

Im Grunde genommen sind Makefiles nichts weiter als Textdateien, in denen der Übersetzungsprozess von Programmen formalisiert enthalten ist. Darüber hinaus stellt das Makefile eine Intelligenz zur Verfügung, die bereits vorhandene und kompilierte Abhängigkeiten (oder bei Updates auch eigenen Code) erkennt und diese nicht erneut kompiliert.

Das Erstellen eines solchen Makefiles von Hand kann bei größeren Projekten mit vielen Abhängigkeiten schnell in unüberschaubare Arbeit ausarten. Um effizient Makefiles zu erstellen, gibt es die »GNU autotools«, die Ihnen die Arbeit zu einem Großteil abnehmen. Folgende Arbeitsschritte müssen Sie durchlaufen, um ein eigenes tgz zu erstellen:

  1. Quellcode erstellen

  2. Makefile.am erstellen

  3. autoscan – configure.scan in configure.in umwandeln

  4. aclocal – Anpassung für die Sprachumgebung

  5. autoconf – Verarbeitung von Konfigurationsdateien

  6. autoheader – Verarbeitung von zusätzlichem Quellcode

  7. automake – Erzeugen des Makefiles

In diesem Abschnitt zeigen wir Ihnen, wie Sie das allseits beliebte Programm »helloworld« von seinem C-Code-Dasein befreien und als tgz-Datei zur Verfügung stellen.

[+] Wenn noch nicht vorhanden, installieren Sie das Paket autoconf aus den Paketquellen (in der Regel ist das Paket aber Bestandteil der Build-Umgebung).

Erstellen Sie zunächst ein Verzeichnis hello-1.0 in Ihrem Homeverzeichnis. In diesem Verzeichnis erstellen Sie das helloworld.c-Programm mit folgendem Quellcode:

/* Simple  "Hello World!" program in C */
#include <stdio.h>
main()
{
 printf("Hello world! Once again... \n");
}

Listing 6.9    »helloworld.c«

[ ! ]  Erstellung als Benutzer

Die Erstellung von Paketen (tgz, rpm oder deb) sollte immer als normaler Benutzer ausgeführt werden. Da root Vollzugriff auf alle Dateien hat, könnten während der Installation eines von ihm erstellten Pakets Dateien überschrieben oder gelöscht werden, die auf dem System benötigt werden.

Die Installation des gepackten Programms selbst muss hingegen von root durchgeführt werden, da Benutzern die entsprechenden Rechte fehlen.

Das soeben erstellte Programm dient als zu verpackende Basis. Erstellen Sie nun die Datei Makefile.am mit folgendem Inhalt:

bin_PROGRAMS = helloworld
helloworld_SOURCES = helloworld.c

Listing 6.10    »Makefile.am«

Die Datei Makefile.am wird von den autotools ausgewertet. In ihr werden der Name des Programms (bin _PROGRAMS) und dessen Quellcode (helloworld_SOURCES) deklariert. Bei größeren Projekten werden hier alle programmrelevanten Dateien aufgeführt und auch alle Bibliotheken. Führen Sie nun autoscan aus. Dieses Programm analysiert die Makefile.am und ihren Quellcode. Es erstellt die Datei configure.scan, die als Basis zur Erstellung der configure.ac dient (siehe Listing 6.11):

#                                               -*- Autoconf -*-
# Process this file with autoconf to produce a configure script.

AC_PREREQ([2.69])
AC_INIT([FULL-PACKAGE-NAME], [VERSION], [BUG-REPORT-ADDRESS])
AC_CONFIG_SRCDIR([helloworld.c])
AC_CONFIG_HEADERS([config.h])

# Checks for programs.
AC_PROG_CC

# Checks for libraries.

# Checks for header files.

# Checks for typedefs, structures, and compiler characteristics.

# Checks for library functions.

AC_CONFIG_FILES([Makefile])
AC_OUTPUT

Listing 6.11    »configure.scan«

Benennen Sie die Datei entsprechend um, und passen Sie die Parameter dem helloworld.c-Programm an:

AC_PREREQ([2.69])
AC_INIT([helloworld], [1.0], [bugs@example.com])
AC_CONFIG_SRCDIR([helloworld.c])
AM_INIT_AUTOMAKE([1.9 foreign])
AC_PROG_CC
AC_CONFIG_FILES([Makefile])
AC_OUTPUT

Listing 6.12    »configure.ac«

Achten Sie darauf, die Zeile AC_CONFIG_HEADERS([config.h]) zu entfernen, da unser Programm keine Header-Datei besitzt. Da Sie weiter mit den autotools arbeiten, müssen Sie die vierte Zeile hinzufügen, die von autoscan nicht erstellt wurde. Führen Sie anschließend die Befehle aclocal und autoconf aus. Diese ergänzen und erweitern die Struktur des tgz. Führen Sie nun autoheader aus, das mit einer Fehlermeldung endet (siehe Listing 6.13):

daniel@example:/home/daniel/hello-1.0# autoheader
autoheader: error: AC_CONFIG_HEADERS not found in configure.ac

Listing 6.13    Fehlermeldung: »autoheader«

Obwohl der Befehl eine Fehlermeldung ausgibt, nimmt er wichtige Konfigurationen vor. Anschließend beenden Sie die Verarbeitung mit automake, das neben dem configure-Skript das passende Makefile erzeugt:

daniel@example:/home/daniel/hello-1.0# automake --add-missing

Listing 6.14    Fehlende Dateien ergänzen

Der Parameter --add-missing gibt an, dass automake fehlende Standarddateien hinzufügen soll. Jetzt stehen Ihnen alle benötigten Dateien zur Verfügung. Packen Sie diese mittels tar in ein Archiv, das Sie auf jedem System entpacken und kompilieren können:

daniel@example:/home/daniel/# tar -cavhf hello-1.0.tar.gz hello-1.0/

Listing 6.15    Ein »tar«-Archiv erstellen

Nach dem bekannten Dreisprung können Sie das Programm einfach über den Befehl helloworld aufrufen und erhalten die erwartete Ausgabe: »Hello World! Once again ...«. Beachten Sie, dass der Befehl make install immer als root ausgeführt werden muss!

6.2.3    Vom Fellknäuel zum Paket

Eine noch elegantere Variante, um das Programm helloworld zur Verfügung zu stellen, besteht darin, es in ein rpm- oder deb-Paket zu hüllen. In diesem Abschnitt zeigen wir Ihnen die minimalen Anforderungen, um ein Paket erzeugen zu können. Bitte beachten Sie, dass noch weitere Konfigurationen notwendig sind, wenn Sie Pakete in die Paketverwaltung Ihrer Distribution hochladen wollen. (Lesen Sie dafür die Guidelines der Distribution.)

DEB-Pakete erzeugen: »dpkg-buildpackage«

Zum Erzeugen von DEB-Paketen wird eine gewisse Verzeichnisstruktur vorausgesetzt. Erzeugen Sie daher die benötigten Verzeichnisse:

daniel@ubuntu:~$ mkdir -p build/hello-1.0/debian

Listing 6.16    Build-Umgebung erzeugen

Legen Sie nun die Datei control im Verzeichnis debian an. Diese enthält wichtige Informationen zum Paket. In Listing 6.17 sehen Sie die Werte, die mindestens gesetzt sein müssen:

Source: hello
Build-Depends: debhelper (>= 9)
Maintainer: Daniel van Soest <daniel@example.com>
Standards-Version: 3.9.5

Package: hello
Architecture: any
Description: Easy to use "helloworld" Program written in C.
 Need some sunshine? Just go and run this nifty little program.

Listing 6.17    Inhalt von »debian/control«

Bitte passen Sie den Maintainer[ 9 ] mit gültigen Werten an (in Fettschrift dargestellt). Beachten Sie, dass die erste Zeile der Direktive Description die Kurzbeschreibung darstellt. Die folgenden Zeilen beginnen stets mit einem Leerzeichen – all diese Zeilen werden als ausführliche Beschreibung ausgewertet. Eine weitere Datei, die im Verzeichnis debian zwingend vorhanden sein muss, ist changelog. Erstellen Sie diese mit dem Inhalt aus Listing 6.18:

hello (1.0-1) unstable; urgency=low

  * Initial release

 -- Daniel van Soest <daniel@example.com>  Sat, 21 May 2018 07:10:08 +0200

Listing 6.18    Inhalt von »debian/changelog«

Auch hier müssen Sie in der letzten Zeile den Maintainer korrigieren und das Datum und die Uhrzeit anpassen. Zusätzlich werden noch weitere Dateien benötigt, die wir in einem Schwung mit den Befehlen aus Listing 6.19 erzeugen:

daniel@ubuntu:~/build/hello-1.0$ echo '9' > debian/compat
daniel@ubuntu:~/build/hello-1.0$ echo 'helloworld /usr/bin/' > debian/hello.install
daniel@ubuntu:~/build/hello-1.0$ echo -e '%:\n\tdh $@' > debian/rules

Listing 6.19    Weitere Dateien anlegen und befüllen

Zu guter Letzt müssen Sie noch die bereits kompilierte Version des Programms mit cp /usr/local/bin/helloworld ~/build/hello-1.0 ins Stammverzeichnis der Build-Umgebung kopieren.

Damit sind alle benötigten Dateien vorhanden, und Sie können das DEB-Paket mit dem Befehl aus Listing 6.20 erzeugen:

daniel@ubuntu:~/build/hello-1.0$ dpkg-buildpackage -rfakeroot
[…]
daniel@ubuntu:~/build/hello-1.0$ ls -lha ../
insgesamt 28K
drwxrwxr-x 3 daniel daniel 4,0K Mai 21 08:03 .
drwxr-xr-x 8 daniel daniel 4,0K Mai 21 08:02 ..
drwxrwxr-x 3 daniel daniel 4,0K Mai 21 08:03 hello-1.0
-rw-rw-r-- 1 daniel daniel 1,1K Mai 21 08:03 hello_1.0-1_amd64.changes
-rw-r--r-- 1 daniel daniel 2,4K Mai 21 08:03 hello_1.0-1_amd64.deb
-rw-rw-r-- 1 daniel daniel  485 Mai 21 08:03 hello_1.0-1.dsc
-rw-rw-r-- 1 daniel daniel 2,2K Mai 21 08:03 hello_1.0-1.tar.gz

Listing 6.20    DEB-Paket erzeugen mit »dpkg-buildpackage«

RPM-Pakete erzeugen: »rpmbuild«

Um ein RPM-Paket aus dem Programm helloworld zu erzeugen, müssen Sie zunächst eine Build-Umgebung erstellen. Führen Sie dafür die Befehle aus Listing 6.21 aus:

[daniel@centos ~]$ mkdir -p ~/rpmbuild/{BUILD,RPMS,SOURCES,SPECS,SRPMS}
[daniel@centos ~]$ echo '%_topdir %(echo $HOME)/rpmbuild' > ~/.rpmmacros

Listing 6.21    Build-Umgebung erstellen: »CentOS«

Mit diesen Befehlen erzeugen Sie alle benötigten Unterverzeichnisse und erstellen eine Makro-Datei, damit das rpmbuild auch weiß, was zu tun ist. Bei openSUSE Leap ist diese Datei eigentlich bereits unter /usr/src/packages vorhanden – Sie können aber auch eine neue erstellen, so wie in Listing 6.21 gezeigt.

Kopieren Sie anschließend die gepackten Quellen in den erzeugten Ordner SOURCES. Für das Beispielprogramm helloworld genügt der Befehl aus Listing 6.22:

[daniel@centos rpmbuild]$ cp ../hello-1.0.tar.gz SOURCES/

Listing 6.22    Quellen kopieren nach »SOURCES«

Zum Erzeugen eines RPM-Pakets wird stets eine sogenannte spec-Datei benötigt. Diese enthält alle Informationen zum Paket und spezifiziert, wie das Paket erzeugt werden soll.

Öffnen Sie nun die Datei SPECS/hello.spec mit einem Editor. Da die Build-Umgebung erzeugt wurde, wird im Editor direkt die passende Template-Datei geöffnet. Diese unterscheidet sich von Distribution zu Distribution. In dieser Datei müssen aber immer mindestens folgende Zeilen angepasst werden:

Name:           hello
Version:        1.0
Release:        1
Summary:        Easy to use "helloworld" Program written in C.
License:        GPLv2
Group:          Development/Tools
Source:         %name-%version.tar.gz
[…]
%files
%doc
/usr/bin/helloworld

Listing 6.23    Erforderliche Anpassungen in »SPECS/hello.spec«

Falls in Ihrem Paket die Standarddokumentation, wie zum Beispiel README oder COPYING, vorhanden ist, müssen Sie diese unter doc mit Leerzeichen getrennt angeben: %doc <FILE1> <FILE2> <...>. Ebenso sollten Sie eine ausführliche Beschreibung unter %description angeben. Falls Sie Aktualisierungen herausbringen, sollten die Änderungen unter %changelog erläutert werden. Dies alles gehört zu einem guten Stil und ist ein »Muss«.

Wenn Sie alle Angaben eingetragen haben, können Sie nun mit dem Programm rpmbuild das Paket so erzeugen, wie in Listing 6.24 dargestellt:

[daniel@centos rpmbuild]$ rpmbuild -ba SPECS/hello.spec
[…]
[daniel@centos rpmbuild]$ find ./ -name '*.rpm'
./RPMS/x86_64/hello-1.0-1.el7.centos.x86_64.rpm
./RPMS/x86_64/hello-debuginfo-1.0-1.el7.centos.x86_64.rpm
./SRPMS/hello-1.0-1.el7.centos.src.rpm

Listing 6.24    Erstellung des Pakets

Wie Sie in Listing 6.24 sehen, war die Erstellung des Pakets erfolgreich. Dieses befindet sich dann, je nach Architektur, unterhalb von RPMS/<ARCH>/.

6.2.4    Patchen mit »patch« und »diff«

Das klassische Patchen von Software, das Sicherheitslücken oder Bugs behebt, findet heutzutage kaum noch Anwendung. In den meisten Fällen werden Updates binnen kürzester Zeit als Paket angeboten und in die Repositorys übernommen.

Dennoch gibt es Patches, die eventuelle Verbesserungen mit sich bringen oder sogar in Paketen enthalten sind. Letzteres tritt oft ein, wenn der Maintainer nicht das ganze Paket neu erstellt, sondern lediglich das Update in Form eines Patches hinzugefügt hat.

Ein Patch besteht aus einer diff-Datei. Das Programm diff erstellt eine Übersicht über die Unterschiede zweier Dateien. Diese wird in einer speziellen Syntax dargestellt, sodass hinzugefügte, gelöschte oder veränderte Zeilen separat dargestellt werden.

Für ein einfaches Beispiel erstellen Sie zwei Textdateien, wie sie in Tabelle 6.3 gezeigt werden.

datei01.txt datei02.txt
Ein einfaches Beispiel,
das die Funktionsweise von
'diff' darstellen soll. 		Ein einfaches BEISPIEl,
das die Funktionsweise
des gut funktionierenden Programms
'diff' darstellen soll.

Tabelle 6.3    Ausgangsdateien

Erstellen Sie einen diff der Dateien über den nachstehenden Befehl:

daniel@example:~# diff -Naur datei01.txt datei02.txt > datei01.patch

Listing 6.25    »diff«-Erzeugung

Die Schalter -Naur weisen diff an, die Unterschiede der datei01.txt zur datei02.txt vollständig zu ermitteln und im C-Format darzustellen. Die Ausgabe wird in die Datei datei01.patch geschrieben, die folgenden Inhalt hat:

daniel@example:~# cat datei01.patch
--- datei01.txt	2018-08-31 16:52:51.284364815 +0200
+++ datei02.txt	2018-08-31 16:53:04.668178142 +0200
@@ -1,3 +1,4 @@
-Ein einfaches Beispiel,
-das die Funktionsweise von
+Ein einfaches BEISPIEl,
+das die Funktionsweise
+des gut funktionierenden Programms
 'diff' darstellen soll.

Listing 6.26    »diff« der »datei01.txt« zu »datei02.txt«

In den ersten beiden Zeilen werden die Ursprungsdateien definiert. Durch die dreifachen Plus- und Minuszeichen wird angegeben, von welcher zu welcher Datei der diff erstellt wurde. Die dritte Zeile, die von At-Zeichen (@) umgeben ist, zeigt an, wo sich der entsprechende Block in beiden Dateien befindet und, durch ein Komma getrennt, wie lang er in der jeweiligen Datei ist. Anschließend folgen die Zeilen, die durch Symbole kategorisiert sind. Das Programm diff kennt drei Kategorien:

In einer diff-Datei können auch mehrere Dateien und deren Veränderungen aufgelistet sein. In ihr wird nie der gesamte Inhalt einer Datei aufgelistet, sondern lediglich die Veränderungen und deren direkte Umgebung. Daher kann die dritte Zeile des Beispiels auch mehrfach vorkommen und somit mehrere geänderte Blöcke einer Datei referenzieren.

Diese Dateien bilden die Grundlage eines Patches. Das Programm patch wird angewandt, um diese Veränderungen einzuspielen. Der Standardaufruf von patch lautet:

root@example:~# patch -Np0 -i datei01.patch

Listing 6.27    Patch einspielen

Das Programm spielt nun die Änderungen aus der Datei datei01.patch ein. Der Schalter -N gibt dabei an, dass die Richtung aus der diff-Datei verwendet werden soll. Der Schalter p0 weist patch an, die Verzeichnisstruktur ab dem Level »0« anzuwenden, und der Schalter -i verlangt die Patch-Datei.

Software-Patches werden meist mit einer Verzeichnisstruktur erzeugt. Erstellen Sie folgende Verzeichnisstruktur:

build/
|-- orig
|   `-- datei.txt
`-- orig.patch
    `-- datei.txt

Listing 6.28    Patch-Verzeichnisstruktur

Kopieren Sie anschließend die datei01.txt nach build/orig/datei.txt und die Datei datei02.txt nach build/orig.patch/datei.txt, und stellen Sie deren ursprünglichen Inhalt wieder her. Erstellen Sie nun den neuen diff mit folgendem Befehl:

daniel@example:~# diff -Naur build/orig/datei.txt \
build/orig.patch/datei.txt > datei.patch

Listing 6.29    Neue Patch-Datei erstellen

Spielen Sie den angelegten Patch ein:

daniel@example:~# patch -Np0 -i datei.patch
patching file build/orig/datei.txt

Listing 6.30    Patch-Datei einspielen

Die Datei orig/datei.txt entspricht jetzt der Datei orig.patch/datei.txt. Die Besonderheit des Parameters p0 wird im nächsten Beispiel deutlich. Hier wird der gleiche Patch erneut eingespielt, diesmal aber von einer tieferen Verzeichnisebene aus:

daniel@example:~/build# patch -Np1 -i ../datei.patch
patching file orig/datei.txt

Listing 6.31    Patch-Datei aus tieferer Verzeichnisebene einspielen

Da sich die Verzeichnisstruktur fest in der Patch-Datei befindet, muss patch über den Parameter 1 angewiesen werden, den Pfad um den ersten Teil der Verzeichnisstruktur zu kürzen, damit die Dateien auch gefunden werden.

[ ! ]  Länge der Pfade

Das Programm patch prüft vor jedem Durchlauf, ob bereits ein Patch eingespielt wurde. Dies kann Ihnen zum Verhängnis werden, wenn der Pfad zur »neuen« Datei nicht länger ist als der zur »alten«. Beachten Sie dies nicht, wird der erstellte diff nicht von patch eingespielt.

6.2.5    Updates sicher konfigurieren

Zu den Nachteilen einer Paketverwaltung gehört, dass sie als root ausgeführt wird und somit Vollzugriff auf alle Dateien hat. So kann es vorkommen, dass beim Aktualisieren von Paketen vorhandene Konfigurationsdateien überschrieben werden. Ein weiterer Nachteil besteht darin, dass Abhängigkeiten von den Paketverwaltungen nur so weit verarbeitet werden können, wie diese von den Maintainern gepflegt wurden. Diese Umstände führen teilweise zu Störungen, deren Ursache nicht leicht auffindbar ist. In diesem Abschnitt erfahren Sie, wie Sie den GAU vermeiden können.

Der »hold«-Status

Leider kommt es immer wieder vor, dass die Weiterentwicklung von Software länger dauert als geplant. Dies kann zu Konflikten führen.

[»] Die Entwicklung der Software Alpha steht still. Hingegen wird die Software Beta, von der Alpha abhängt, stetig weiterentwickelt. Wenn nun »alte« Funktionen aus der Software Beta nicht weiter in die »neuen« Versionen übernommen werden, kann die Software Alpha nicht mehr ordnungsgemäß arbeiten.

Eine Paketverwaltung löst solche Probleme meist auf und unterbindet das weitere Einspielen von Updates für die entsprechende Software. Leider kommt es vor, dass Entwickler keine Versionsangaben für abhängige Software einpflegen. Dann kommt es zum GAU. Um diesen zu verhindern, haben Sie die Möglichkeit, einzelne Pakete aus den Updates herauszulösen, sodass die von Ihnen benötigte Software zwar im veralteten, aber dafür lauffähigen Zustand bleibt. Hierfür wurde in den deb-Paketverwaltungen der hold-Status und unter der rpm-Paketverwaltung der lock-Status implementiert.

Debian/Ubuntu

Unter deb-basierten Distributionen können Sie den Status von Paketen mittels dpkg und dem Parameter --set-selections ändern. So setzen Sie das Paket vsftpd auf hold:

root@debian:~# echo "vsftpd hold" | dpkg --set-selections

Listing 6.32    »deb«-Paket auf »hold« setzen

openSUSE Leap

Den Status eines rpm-Pakets können Sie mit zypper addlock <PAKET> sperren.

CentOS

Unter CentOS müssen Sie zunächst das Paket yum-plugin-versionlock installieren. Anschließend können Sie mit dem Befehl yum versionlock <PAKET> ein Paket sperren.

Übersicht der gesperrten Pakete

Eine Übersicht der in deb-Systemen auf hold gesetzten Pakete erhalten Sie über den folgenden Befehl:

root@debian:~# dpkg --get-selections | grep hold
vsftpd                                          hold

Listing 6.33    Übersicht gesperrter »deb«-Pakete

Ebenso können Sie sich auf rpm-Systemen die als gesperrt markierten Pakete anzeigen lassen. Verwenden Sie dafür zypper auf openSUSE Leap und yum auf CentOS:

### openSUSE Leap
daniel@leap:~> zypper locks
# | Name   | Typ     | Repository
--+--------+---------+-----------
1 | vsftpd | package | (beliebig)

### CentOS
[daniel@centos ~]$ yum versionlock
Geladene Plugins: fastestmirror, versionlock
0:vsftpd-3.0.2-11.el7_2.*
versionlock list done

Listing 6.34    Übersicht gesperrter »rpm«-Pakete

Konfigurationsdateien

Prüfen Sie die aktuellen Paketverwaltungen, ob Veränderungen an vorhandenen Konfigurationsdateien vorgenommen wurden, und legen Sie entsprechend Sicherungskopien an, sodass bei einem Update Ihre »alte« Konfiguration nicht blind überschrieben wird.

»rpm«

Bei der Installation untersucht rpm, ob es Änderungen an der Konfigurationsdatei gibt. Je nachdem, wie das Paket erstellt wurde, wird Ihre aktuelle Konfigurationsdatei ersetzt und eine Sicherheitskopie erzeugt (Suffix: .rpmsave oder .rpmorig), oder Ihre Konfigurationsdatei bleibt bestehen, und die »neue« Konfigurationsdatei wird mit dem Suffix .rpmnew angelegt.

[+]  ».rpmsave«, ».rpmorig« und ».rpmnew«

Kontrollieren Sie nach »großen« Updates, ob diese Dateien existieren, und passen Sie gegebenenfalls Ihre Konfiguration an!

»deb«

Bei »deb«-basierten Systemen wird ein anderer Ansatz verfolgt. Hier wird ebenfalls geprüft, ob eine lokale Konfigurationsdatei existiert.

Wird mit dem »neuen« Paket eine Konfigurationsdatei ausgeliefert, wird Ihnen die Wahl gelassen:

Auswahl zur Änderung der Konfigurationsdatei »samba«

Abbildung 6.1    Auswahl zur Änderung der Konfigurationsdatei »samba«