© Alterfalter, Fotolia.com

Manuelle Software-Updates begleiten Admins durch den Tag. Dabei versprechen die Paketmanager diese Arbeit zu automatisieren. Der Artikel vergleicht die großen Distributionen und testet, wie viel Reinheit die mit den Systemen gelieferten Tools wirklich bringen – und welche Gefahren dabei entstehen.

In einem unterscheiden sich proprietäre oder offene Betriebssysteme kaum – egal ob der Anwender Windows, Mac OS oder das freie Linux einsetzt, stets ist er mit immer mehr Updates und Patches in immer kürzeren Abständen konfrontiert. Ob Bugfixes zu installieren, Sicherheitslöcher zu stopfen sind oder die mit einer neuen Programmversion lange erwartete Funktion endlich kommt: In schöner Regelmäßigkeit müssen Anwender und Admins Updates einspielen, in vielen Fällen sogar täglich.

Verführerische Versprechen

Einladend glänzen moderne Linux-Distributionen mit Schaltflächen, die wie Waschmaschinen eine Vollautomatik versprechen und den Anwender glauben lassen, der Rechner sei danach auf dem neuesten Stand, er kümmere sich ganz alleine darum, brauche keine Hilfe und sei durchaus in der Lage, mit heiklen Softwarepaketen umzugehen.

Doch ganz so einfach funktionieren Unattended Updates und Upgrades in der Praxis selten, vor allem wenn eigene oder exotische Software im Spiel ist. Aber nicht nur dann ist es immer noch keine gute Idee, ein Produktivsystem, einen Server oder gar eine ganze Rechnerfarm alleine, unbeaufsichtigt und vollautomatisch updaten oder upgraden zu lassen. An einem Desktop, mit dem der Benutzer Fehlermeldungen erhält und eingreifen oder den Admin anrufen kann, mag das anders aussehen.

Immer wieder tauchen Abhängigkeiten auf, die das Update scheitern lassen und so schlimmstenfalls für Produktionsausfälle sorgen – nicht nur bei selbst geschriebenen Applikationen. Um eine Testumgebung kommt der verantwortungsbewusste Admin nicht herum, doch kann die dank Virtualisierung heutzutage in Form von virtuellen Maschinen auch auf seinem Laptop laufen.

Noch besser ist es jedoch, angesichts von Kernelpatches und eventuellen proprietären Treibern, die Testsysteme aus identischer Hardware aufzubauen wie die produktiven Maschinen – sonst könnte es passieren, dass zwar alle Updates sauber durchlaufen, der Paketmanager keine Fehler meldet, aber das System einfach nicht mehr booten kann.

Hardware in Gefahr

Das kann allerdings auch andere Gründe haben, so wie 2004, als Suse schlicht beim Kernelupdate den XFS-Treiber fehlerhaft verbaut hatte [1], oder vor wenigen Wochen, als ein Bug in den Updates von Systemd und Journald Fedora-19- und -20-Systeme an den Rand eines Kollapses brachte [2].

Dabei geriet sogar Hardware in Gefahr: Im Systemprotokoll landeten Unmengen an alten Einträgen. So schnell es CPU und I/O des Systems eben hergaben, schrieben die Daemons Vierzeiler ins Log – und trieben Festplatten- und CPU-Last an die Grenzen. Auf unüberwachten, lüfterlosen Geräten war da schnell die Hardware an Grenzen. Abhilfe schaffte nur ein manuelles »yum downgrade rsyslog« , ein Eintrag in die Blacklist (damit nicht das nächste Update wieder den gleichen Fehler verursacht) – und dann warten, bis die Community den Bug behob.

Auf baugleicher Hardware und mit identischen Setups kann der Admin solche Fehler weitgehend ausschließen. Herstellerpatches lassen sich ausprobieren, ohne dass sie Schaden anrichten, bevor der Admin sie zum Ausrollen freigibt.

Automatik erst nach Tests

Dann ergibt ein Auto-Update auch mehr Sinn: Das Umbiegen der Repositories für Patches ist schließlich bei allen geprüften Distributionen möglich. Der Admin legt die von ihm getesteten und verifizierten Updates auf einem eigenen Updateserver ab und geht so auf Nummer sicher.

Erfahrene Linux-Administratoren greifen gern zum Cronjob, doch gibt es bei allen Distributionen Spezialtools, die zwar letzten Endes auch nur Einträge in einer Crontab oder im »cron.daily« -Verzeichnis anlegen. Doch diese Werkzeuge bieten einfache Oberflächen und viele Funktionen rund um das periodische »aptitude -y upgrade« (Listing 1) beziehungsweise »yum -y upgrade« (Listing 2).

01 Treffer http://de.archive.ubuntu.com raring Release.gpg
02 Holen: 1 http://de.archive.ubuntu.com raring-updates Release.gpg [933 B]
03 [...]
04 100% [28 Packages bzip2] [Warten auf Kopfzeilen] [Warten
05 Ign http://security.ubuntu.com raring-security/restricted Translation-de_DE
06 Treffer http://de.archive.ubuntu.com raring-updates/restricted Translation-en
07 Ign http://de.archive.ubuntu.com raring-backports/restricted Translation-de
08 [...]
09 889 kB wurden in 7 s heruntergeladen (116 kB/s)
10
11 Auflösen der Abhängigkeiten ...
12 Die folgenden NEUEN Pakete werden zusätzlich installiert:
13   linux-headers-3.8.0-26{a}
14   linux-headers-3.8.0-26-generic{a}
15   linux-image-3.8.0-26-generic{a}
16   linux-image-extra-3.8.0-26-generic{a}
17 Die folgenden Pakete werden aktualisiert:
18   libdrm-intel1 libdrm-nouveau2 libdrm-radeon1
19   libdrm2 libkms1 linux-generic
20   linux-headers-generic linux-image-generic
21 8 Pakete aktualisiert, 4 zusätzlich installiert, 0 werden entfernt und 1 nicht aktualisiert.
22 56,6 MB an Archiven müssen heruntergeladen werden. Nach dem Entpacken werden 235 MB zusätzlich belegt sein.
23 Holen: 1 http://de.archive.ubuntu.com/ubuntu/ raring-updates/main libdrm2 amd64 2.4.43-0ubuntu1.1 [26,3 kB]
24 [...]
25 Holen: 12 http://de.archive.ubuntu.com/ubuntu/ raring-updates/main linux-headers-generic amd64 3.8.0.26.44 [2.398 B]
26 56,6 MB wurden in 10 s heruntergeladen (5.538 kB/s)
27 [...]
28 Vormals nicht ausgewähltes Paket linux-image-3.8.0-26-generic wird gewählt.
29 Entpacken von linux-image-3.8.0-26-generic (aus .../linux-image-3.8.0-26-generic_3.8.0-26.38_amd64.deb) ...
30 Vormals nicht ausgewähltes Paket linux-image-extra-3.8.0-26-generic wird gewählt.
31 [...]
32 linux-image-3.8.0-26-generic (3.8.0-26.38) wird eingerichtet ...
33 Running depmod.
34 update-initramfs: deferring update (hook will be called later)
35 Examining /etc/kernel/postinst.d.
36 run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 3.8.0-26-generic /boot/vmlinuz-3.8.0-26-generic
37 run-parts: executing /etc/kernel/postinst.d/initramfs-tools 3.8.0-26-generic /boot/vmlinuz-3.8.0-26-generic
38 update-initramfs: Generating /boot/initrd.img-3.8.0-26-generic
39 run-parts: executing /etc/kernel/postinst.d/pm-utils 3.8.0-26-generic /boot/vmlinuz-3.8.0-26-generic
40 run-parts: executing /etc/kernel/postinst.d/update-notifier 3.8.0-26-generic /boot/vmlinuz-3.8.0-26-generic
41 run-parts: executing /etc/kernel/postinst.d/zz-update-grub 3.8.0-26-generic /boot/vmlinuz-3.8.0-26-generic
42 grub.cfg wird erstellt ...
43 [...]
44 linux-image-extra-3.8.0-26-generic (3.8.0-26.38) wird eingerichtet ...
45 Running depmod.
46 update-initramfs: deferring update (hook will be called later)
47 Examining /etc/kernel/postinst.d.
48 run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 3.8.0-26-generic /boot/vmlinuz-3.8.0-26-generic
49 run-parts: executing /etc/kernel/postinst.d/initramfs-tools 3.8.0-26-generic /boot/vmlinuz-3.8.0-26-generic
50 update-initramfs: Generating /boot/initrd.img-3.8.0-26-generic
51 run-parts: executing /etc/kernel/postinst.d/pm-utils 3.8.0-26-generic /boot/vmlinuz-3.8.0-26-generic
52 run-parts: executing /etc/kernel/postinst.d/update-notifier 3.8.0-26-generic /boot/vmlinuz-3.8.0-26-generic
53 run-parts: executing /etc/kernel/postinst.d/zz-update-grub 3.8.0-26-generic /boot/vmlinuz-3.8.0-26-generic
54 grub.cfg wird erstellt ...
55 [...]
56 linux-image-generic (3.8.0.26.44) wird eingerichtet ...
57 linux-headers-3.8.0-26 (3.8.0-26.38) wird eingerichtet ...
58 linux-headers-3.8.0-26-generic (3.8.0-26.38) wird eingerichtet ...
59 linux-headers-generic (3.8.0.26.44) wird eingerichtet ...
60 linux-generic (3.8.0.26.44) wird eingerichtet ...
61 Trigger für libc-bin werden verarbeitet ...
62 ldconfig deferred processing now taking place
63
64 Aktueller Status: 1 aktualisierbares Paket [-8].

01 Geladene Plugins: langpacks, refresh-packagekit
02 Abhängigkeiten werden aufgelöst
03 --> Transaktionsprüfung wird ausgeführt
04 ---> Paket OpenImageIO.x86_64 0:1.1.10-2.fc19 markiert, um aktualisiert zu werden
05 [...]
06 ---> Paket kernel.x86_64 0:3.9.9-301.fc19 markiert, um installiert zu werden
07 ---> Paket kernel-devel.x86_64 0:3.9.9-301.fc19 markiert, um installiert zu werden
08 ---> Paket kernel-headers.x86_64 0:3.9.8-300.fc19 markiert, um aktualisiert zu werden
09 ---> Paket kernel-headers.x86_64 0:3.9.9-301.fc19 markiert, um eine Aktualisierung zu werden
10 [...]
11 ---> Paket xorg-x11-server-common.x86_64 0:1.14.2-1.fc19 markiert, um eine Aktualisierung zu werden
12 --> Abhängigkeitsauflösung beendet
13 --> Transaktionsprüfung wird ausgeführt
14 ---> Paket kernel.x86_64 0:3.9.2-301.fc19 markiert, um gelöscht zu werden
15 ---> Paket kernel-devel.x86_64 0:3.9.2-301.fc19 markiert, um gelöscht zu werden
16 --> Abhängigkeitsauflösung beendet
17
18 Abhängigkeiten aufgelöst
19
20 ==============================
21  Package  Arch  Version         Paketquelle       Größe
22 ==============================
23 Installieren:
24  kernel x86_64  3.9.9-301.fc19   updates-testing  29 M
25  kernel-devel    x86_64  3.9.9-301.fc19   updates-testing   8.1 M
26 Aktualisieren:
27  OpenImageIO     x86_64  1.1.13-1.fc19    updates-testing   1.1 M
28  fedorautils     noarch  3.0.8-4.2        fedorautils        61 k
29 [...]
30  selinux-policy  noarch  3.12.1-59.fc19   updates-testing   271 k
31  xorg-x11-server-common  x86_64  1.14.2-1.fc19  updates-testing  43 k
32
33 Transaktionsübersicht
34 ==============================
35 Installieren    2 Pakete
36 Aktualisieren  16 Pakete (+7 Abhängige Pakete)
37 Entfernen       2 Pakete
38
39 Gesamte Downloadgröße: 54 M
40 Downloading packages:
41 No Presto metadata available for fedorautils
42 updates-testing/19/x86_64/prestodelta              | 661 kB  00:00:00
43 Delta RPMs reduced 7.3 M of updates to 1.6 M (77% saved)
44 (1/25): gpm-libs-1.20.6-31.fc19_1.20.6-33.fc19.x86_64.drpm  |  23 kB  00:00:00
45 [...]
46 (18/25): kernel-headers-3.9.9-301.fc19.x86_64.rpm  | 854 kB  00:00:01
47 (19/25): kernel-devel-3.9.9-301.fc19.x86_64.rpm    | 8.1 MB  00:00:02
48 [...]
49 (25/25): kernel-3.9.9-301.fc19.x86_64.rpm          |  29 MB  00:00:11
50 -------------------------------------------------------------------
51 Gesamt  3.7 MB/s |  48 MB     00:13
52 Running transaction check
53 Running transaction test
54 Transaction test succeeded
55 Running transaction
56   Aktualisieren    : selinux-policy-3.12.1-59.fc19.noarch            1/50
57 [...]
58   Aktualisieren    : fedorautils-3.0.8-4.2.noarch                   22/50
59   Installieren     : kernel-devel-3.9.9-301.fc19.x86_64             23/50
60   Aktualisieren    : ibus-typing-booster-1.2.1-1.fc19.noarch        24/50
61   Installieren     : kernel-3.9.9-301.fc19.x86_64                   25/50
62 [...]
63   Aufräumen        : kernel-3.9.2-301.fc19.x86_64                   34/50
64   Aufräumen        : kernel-headers-3.9.8-300.fc19.x86_64           35/50
65 [...]
66   Überprüfung läuft: selinux-policy-targeted-3.12.1-59.fc19.noarch  12/50
67   Überprüfung läuft: kernel-3.9.9-301.fc19.x86_64                   13/50
68 [...]
69 Entfernt:
70   kernel.x86_64 0:3.9.2-301.fc19 kernel-devel.x86_64 0:3.9.2-301.fc19
71
72 Installiert:
73   kernel.x86_64 0:3.9.9-301.fc19 kernel-devel.x86_64 0:3.9.9-301.fc19
74
75 Aktualisiert:
76   OpenImageIO.x86_64 0:1.1.13-1.fc19
77  [...]
78   kernel-headers.x86_64 0:3.9.9-301.fc19
79 [...]
80   xorg-x11-server-Xorg.x86_64 0:1.14.2-1.fc19
81 Abhängigkeit aktualisiert:
82   libdrm.x86_64 0:2.4.46-1.fc19
83   [...]
84   selinux-policy.noarch 0:3.12.1-59.fc19
85   xorg-x11-server-common.x86_64 0:1.14.2-1.fc19
86
87 Komplett!

Die beiden Listings zeigen einen automatischen Durchlauf durch ein reguläres Update inklusive eines Upgrade des Linux-Kernels. Die Ubuntu-Variante bekommt dabei Kernel 3.8.0-26 verpasst, Fedora 19 schnappt sich 3.9.9.

Die Unterschiede zwischen den Paketmanagern und ihren Tools liegen mittlerweile eher im Detail. Da kann Yum beispielsweise automatisch einen geeigneteren Repository-Server finden, während Apt standardmäßig nur seine eigene Liste verwendet. Yum setzt dafür auf Metadaten-Pakete und Delta-RPMs, dafür gibt’s bei Ubuntu beispielsweise ein simples Repository für Wagemutige, die die neuesten Kernel ausprobieren wollen (»kernel-ppa/mainline« ). Dort finden sich auch paketierte Release Candidates der nächsten Entwicklerkernel.

Sieben Distributionen

Dem folgenden Vergleich stellen mussten sich Centos, Debian, Fedora, Open Suse, RHEL, SLES und Ubuntu. Auch andere Distributionen bieten Auto-Update-Funktionen an, warnen aber wie Arch Linux in der Regel davor, sie anzuwenden [3]. Alle getesteten Distributionen kennen die Möglichkeit, Pakete von Upgrade oder Installation auszunehmen, etwa wenn Abhängigkeiten aufzulösen sind.

Debian und Ubuntu fallen im Vergleich positiv auf, weil sich bei ihnen (fast) alles explizit und dediziert für die automatischen Upgrades konfigurieren lässt. So kann der Admin bei einem automatischen »apt-get update« alles upgraden, aber zugleich verhindern, dass das System kritische Pakete ohne manuelles Eingreifen aktualisiert, die beispielsweise Neustarts von eigenen Diensten erfordern oder mit denen der Admin schlechte Erfahrungen gemacht hat. Die anderen Distributionen, abgesehen von RHEL, bieten derlei über Einstellungen in der Yum- oder Zypper-Konfiguration.

Der Admin kann das eingangs beschrieben Vorgehen einer Staging-Umgebung und die daraus freigegebenen Patches bei allen Kandidaten mit den unbeaufsichtigten Techniken kombinieren, indem er die Patches, die die Tests bestanden haben, auf einen lokalen Server legt und allen Systemen mit automatischem Modus nur diesen Server als Repository-Master zuweist. Alternativ kann er natürlich auch Software wie Pulp [4] verwenden, um die Upgrades zentral anzustoßen, statt sie dezentral einsammeln zu lassen.

Centos

Wer seine Centos-Installation mit automatischen Updates versehen will, muss das Paket »yum-cron« installieren. Es besteht aus Konfigurationsdateien und einem Shellskript, das die dort konfigurierten Updates nach den Vorgaben des Admin einspielt. Als etwas eigentümlich dabei erweist sich, dass der Admin das Ganze über Initskripte und Services (de-)aktivieren muss. Die Startfunktion des Initskripts legt lediglich eine Lock-Datei an, und Cron ruft das eigentliche Skript auf. Das verrichtet seinen Dienst nur, wenn die Lock-Datei existiert.

Die Konfiguration des Dienstes erfolgt über die Datei »/etc/subsys/yum-cron« . Hier kann der Admin einstellen, dass Centos nur prüft, ob es neue Pakete gibt, ob die Server erreichbar sind und ob das System neue Pakete nur herunterladen, aber nicht installieren soll – oder aber beides.

Außerdem finden sich in dieser Datei noch Parameter für Fehler-E-Mails und die Einstellungen, an welchen Tagen das Update laufen soll. Standardmäßig aktualisiert es alle Pakete, sollte ein Reboot notwendig sein, beispielsweise bei Kernelupdates, dann erfährt dies der Administrator nur, wenn er die Logdatei oder Statusmail liest und nachsieht, welche Updates eingespielt wurden.

Debian

Debian-Systeme haben die wohl komplexeste Variante für unbeaufsichtigte Updates. Zunächst muss auch hier der Administrator ein Paket installieren, bei Debian heißt es »unattended-upgrades« . Die Konfiguration erledigt er in mehreren Dateien im Verzeichnis »/etc/apt/apt.conf.d« , nachträglich aktivieren kann er es mit »dpkg-reconfigure –plow unattended-upgrades« . In der Datei »50unattended-uprades« stellt er außerdem noch ein, aus welchen Quellen (dabei werden Patterns verwendet) Pakete stammen müssen, damit das Unattended-Paket sie verarbeitet.

In der Standardeinstellung akzeptiert das Tool nur Debian-Pakete aus dem Stable-Bereich mit Label »Debian-Security« – wohl eine sehr weise Entscheidung. In dieser Datei lassen sich kritische Pakete auch auf eine Blacklist setzen, was das automatische Update verhindert.

Wie bei Centos kann der Administrator hier eine E-Mail-Adresse eintragen. Auch die riskanten automatischen Neustarts oder Updates beim Shutdown statt im Hintergrund des laufenden Betriebs und viele andere nützliche Settings darf er hier konfigurieren.

Ob die Einstellung, Updates beim Herunterfahren einzuspielen, sinnvoll ist, muss jeder Admin selbst entscheiden. Microsoft-Anwendern ist das vertraut, doch nicht jedem liegt die Vorstellung, beim unter Linux doch deutlich selteneren Reboot erst minutenlang warten zu müssen. In der Regel klappen die Updates jedoch deutlich schneller als bei Windows 7, wo sich schwachbrüstige PCs bei umfangreichen Aktualisierungen schon mal eine halbe Stunde für den Neustart genehmigen.

Der zweite Teil der Konfiguration steckt im selben Verzeichnis in der Datei »02periodic« . Dort stellt der Administrator ein, ob überhaupt automatische Updates durchzuführen sind, wann das System die Paketlisten aktualisiert, ob es die Pakete nur herunterladen oder auch gleich installieren soll und wann es alte Pakete aus dem Cache löscht.

Die Funktionsweise der Auto-Updates unter Debian ist simpel: Alle Parameter dienen dem Shellskript »/etc/cron.daily/apt« dazu, einmal täglich (getriggert von Cron) gemäß den Einstellungen die anstehenden Aufgaben zu absolvieren. Im Verzeichnis »/var/log/unattended-upgrades« findet sich die Datei »unattended-upgrades.log« , die den Statusbericht der täglichen Abläufe enthält. Installiert das Skript tatsächlich Upgrades, so legt es Extradateien an, die detaillierte Ausgaben der Installation aufnehmen.

Fedora

Fedora verwendet optional das Python-Skript »yum-updatesd« . Dessen Konfiguration wird in der Datei »/etc/yum/yum-updatesd.conf« festgelegt. Listing 3 zeigt die Konfiguration für automatische Updates. Wahlweise verteilt das Skript Update-Benachrichtigungen übers Dbus-System oder via Syslog und stellt sie natürlich auch per E-Mail zur Verfügung, wobei der Administrator beim E-Mail-Verfahren die Sende- und Empfangsadresse sowie den Mailserver direkt angeben kann. Bei Syslog darf er Facility und Level spezifizieren.

01 [main]
02 # how often to check for new updates (in seconds)
03 run_interval = 3600
04
05 # how often to allow checking on request (in seconds)
06 updaterefresh = 600
07
08 # how to send notifications (valid: dbus, email, syslog)
09 emit_via = dbus
10 # should we listen via dbus to give out update
11 # information/check for new updates
12 dbus_listener = yes
13
14 # automatically install updates
15 do_update = yes
16 # automatically download updates
17 do_download = yes
18 # automatically download deps of updates
19 do_download_deps = yes

Wurde der Yum-updatesd-Dienst gestartet, dann heißt es warten, bis das Intervall vorbei ist. Je nach gewählter Benachrichtigungsart bekommt der Administrator eine Email oder findet die Informationen über die Updates im Syslogfile. Und wer das Desktop-Red-Hat am Arbeitsplatz einsetzt, konfiguriert die Updates über Apper (Abbildungen 1 und 2).

Abbildung 1: GUI-Konfiguration des Paketmanagements unter KDE auf Fedora 19: Apper integriert sich in die Systemsteuerungen …

Abbildung 2: … steht dem Admin aber auch als Stand-alone-Applikation zur Seite, wenn er sie von der Kommandozeile aus startet.

Open Suse und SLES

Offene und kommerzielle Variante der beiden Suse-Distributionen unterscheiden sich bekanntlich nur in der Registrierung, die bei SLES erforderlich wird und die den Anspruch auf offiziellen Support aktiviert. Wie beim Chamäleon üblich, konfiguriert der Admin automatische Updates in Yast: Im Modul »Software | Online Update Configuration« (Abbildungen 3 und 4) kann er die folgenden, vergleichsweise bescheidenen Parameter eingestellen:

Abbildung 3: Online-Updates unter Suse konfigurieren kann der Anwender auch am Desktop – dank Yast.

Abbildung 4: Yast bietet deutlich weniger Parameter als Debian-Systeme, dafür ein schickes GUI. Die Einstellungen landen unter »/etc/sysconfig«.

• Automatische Updates überhaupt aktivieren?
• Wie häufig soll geprüft werden (täglich, wöchentlich, monatlich)?
• Interaktive Patches auch einspielen?
• Soll das System allen Lizenzbestimmungen zustimmen?
• Sollen auch empfohlene Patches eingespielt werden?

Schließlich kann der Administrator noch aus einer Liste von Kategorien (Security, Empfohlen, …) auswählen, sodass nur Pakete, die einer diesen Kategorien entsprechen, beim automatischen Update zum Zuge kommen.

Mit wenigen Mausklicks ist die Konfiguration abgeschlossen und der Administrator kann in »/var/log/zypp/history« nachprüfen, was das System wann installiert hat. Wer lieber Textdateien editiert, findet die Parameter in dem Verzeichnis »/etc/sysconfig« .

Red Hat Enterprise Linux

RHEL besitzt schon lange sein eigenes Modell, mit dem Admins ihre Systeme dazu anweisen, automatische Updates herunterzuladen und zu installieren. Die Rothüte haben Yum um ein Plugin für das Red Hat Network (RHN) erweitert, von dem jeder Server profitiert, der über eine gültige Subskription und einen Account verfügt. Damit kann der Administrator über die Weboberfläche Installationen oder Upgrades anstoßen. Auf den Systemen arbeitet anschließend der »rhn« -Daemon die Aufgaben ab. Dabei schickt das RHN E-Mails an die Admins, wenn Updates anstehen.

Der Rhnsd prüft in Intervallen (einstellbar in »/etc/sysconfig/rhn/rhnsd« ), ob es für ihn etwas zu tun gibt. Auf den Weboberflächen der Systeme kann der Admin konfigurieren, ob Updates automatisch und ohne Bestätigung einzuspielen sind, dabei lässt sich das GUI aber leider nicht näher darüber aus, was “relevant” bedeutet.

Über den Status der durchgeführten Upgrades informiert das RHN den Administrator ebenfalls per E-Mail. Mehr Details zu den Enterprise-Distributionen und den verbundenen Implikationen bietet ein eigener Artikel in diesem Schwerpunkt.

Ubuntu

Wie Debian setzt auch Ubuntu auf das Paket »unattended-upgrades« . Das System verhält sich genau so, wie im Debian-Abschnitt oben beschrieben, bringt aber eigene GUIs mit (Abbildung 5). Out of the Box kommt auch der »update-notifer-common« auf die Platte, der ebenfalls unter »/etc/apt/apt.conf.d« eine Datei »10periodic« anlegt (Listing 4).

01 APT::Periodic::Update-Package-Lists "1";
02 APT::Periodic::Download-Upgradeable-Packages "1";
03 APT::Periodic::AutocleanInterval "7";

Abbildung 5: Unter »Software & Aktualisierungen« konfiguriert der Anwender am Ubuntu-Desktop Updates. Das schaut unter KDE und Gnome/Unity gleich aus und integriert sich in die Systemsteuerungen, hier KDE.

Abbildung 6: Am Desktop kein Problem: So wie hier Fedora informieren alle Systeme den Benutzer.

Diese versteht im Prinzip die gleichen Parameter wie die ebenfalls oben schon beschriebene »02periodic« bei »unattended-upgrades« , allerdings funktionieren die Parameter, beispielsweise »APT::Periodic::Unattended-Upgrade« , etwas anders, hier hilft aber der Blick in die Manpage weiter.

Es empfiehlt sich, nur eine der beiden Varianten aktiv zu halten, damit das System weniger oft die Updateserver abfragt und die beiden Prozesse nicht beim Download miteinander konkurrieren. Bei der Installation kümmert sich Apt ja um den Zugriff auf die Paketdatenbank. Ubuntu meldet übrigens über die Datei »/etc/issue« , wenn nach automatischen Updates beispielsweise ein neuer Kernel einen Reboot verlangt (Listing 5).

01 # ssh root@ubuntu1304
02 Welcome to Ubuntu 13.04 (GNU/Linux 3.9.4-030904-generic x86_64)
03
04  * Documentation:  https://help.ubuntu.com/
05
06 *** Neustart des Systems erforderlich ***
07 Last login: Mon Jul  1 15:56:30 2013 from 95-91-235-245-dynip.superkabel.de
08 # reboot

Nie ohne Testumgebung

Tabelle 1 fasst die Ergebnisse des Tests zusammen. Die höchste Flexibilität bietet definitiv Debians Paketmanagement. Durch die Möglichkeit, automatische und manuelle Updates getrennt zu behandeln, kann der Administrator hier auch Pakete, die er als gefahrlos einstuft, automatisch aktualisieren lassen, während er problematischere Software gesondert behandelt.

Bei den anderen Distributionen muss er dieses Verhalten mit den entsprechenden Optionen der Paketwerkzeuge erzwingen, was aber in der Regel den Nachteil mit sich bringt, dass bei einem manuellen Upgrade die allgemeingültigen Ausnahmen überschrieben werden. Trotzdem sollte ein sicherheitsbewusster Admin bei produktiven Systemen lieber auf eine Download-only-Strategie setzen, zumindest wenn er keine Testumgebung vorhalten will. So muss er beim Upgrade nicht lange warten, hat aber trotzdem noch alle Fäden in der Hand, falls etwas schiefläuft.

Der Autor

Konstantin Agouros arbeitet bei der N.runs AG als Berater für Netzwerksicherheit. Dabei liegt sein Schwerpunkt im Bereich Telekommunikationsanbieter und SIEM Technologien. Sein Buch “DNS/DHCP” ist bei Open Source Press erschienen.