Es ist der Horror, wenn nach einem Update alle Rechner in der Firma streiken. Wer dafür keine Nerven hat, sollte die Grundfunktionen vor jedem Paketupdate testen – nach Möglichkeit automatisch. Wie das gehen kann, und wer die Packages auf die Zielrechner beamt und wann, das erklärt dieser Schwerpunkt.

Keine Firewall und kein IDS kann die Sicherheit für Linux-Server und -Desktops so wirksam schützen, wie das regelmäßige Updates tun. Darum informieren Linuxe ihre Anwender, wenn Paketupdates anstehen, wenn sie diese nicht sogar automatisch einspielen. Diese auch für Admins erfreuliche Tatsache bürdet ihnen aber auch eine mit jedem Update wiederkehrende Frage auf: Funktioniert danach noch alles auf den Systemen?

Quantitativ betrachtet lautet die Antwort: Meistens ja. Denn zumindest die Distributionen mit viel Manpower wie Debian, Fedora, Open Suse, Ubuntu und einige mehr testen ihre Software recht umfänglich, bevor sie sie auf hunderttausende Rechner loslassen. Enterprise-Distributionen rechtfertigen ihre Subskriptionspreise zum guten Teil mit der Zusicherung, dass ihre Maintenance funktions- und schnittstellenneutral abläuft.

Doch Fehler lassen sich im Einzelfall nicht vermeiden. Mehr noch: Viele Firmen haben Spezialsoftware auf ihren Rechnern installiert, die sie nicht aus den Repositories der benutzen Distribution beziehen. Ob die sich mit einem sich alle paar Tage quasi selbstmodifizierenden System verträgt, überprüft kein Mensch. Dem seiner Verantwortung für die Funktion der IT sich bewussten Admin bereitet das Bauchschmerzen. Was tun, wenn eines morgens eine Anwendung nicht mehr (richtig) funktioniert, die fast alle Mitarbeiter benutzen? Oder wenn keiner mehr drucken oder auf Samba-Shares zugreifen kann? Oder die grafischen Tablets in der Konstruktionsabteilung streiken? Die Antwort auf solche Fragen darf man ruhig als “geschäftskritisch” bezeichnen.

Was tun?

Jeder IT-Verantwortliche sollte das gedanklich mal durchgespielt haben und überlegen, wie er in diesem Fall konkret organisatorisch und technisch reagieren würde. Firmen, die eine Softwareverteilung [1] wie Ansible, Puppet oder Chef benutzen, würden wahrscheinlich alle Rechner auf den Stand von vor dem Update zurückrollen. Das löst das Problem zwar nicht nachhaltig, der Geschäftsbetrieb wird aber nach vielleicht einer Stunde wieder anlaufen. Die internen Kosten einen solchen Vorfalls sind trotzdem immens und dem Standing der IT-Abteilung nicht zuträglich.

Und bei Weitem nicht jeder hat ein Softwareverteil-System am Laufen, denn der Einrichtungs- und Pflegeaufwand lohnt meist nur, wenn man genug ähnliche Systeme unter der Obhut hat. Letztlich wird jeder Operations-Verantwortliche besser schlafen, wenn er die Funktionstests nicht den Angestellten in der Firma ohne dessen Wissen durchführen lässt, sondern zumindest die zwei, drei, vier Hauptanwendungen vorab testet. Sinnvollerweise automatisiert der Admin das Anschieben der Tests, die Tests selber und deren Auswertung weitgehend. Firmen, die eine eigene Entwicklungsabteilung haben, werden sich hierbei auf Continuous-Integration-Systeme stützen (siehe Kasten “Interview”).

Interview: Qualitätssicherung bei Univention

Michel Smidt gehört zum Professional Service Team bei der Bremer Linux-Firma Univention. Deren Hauptprodukt, die Distribution Univention Corporate Server (UCS), fußt auf Debian Linux.

Linux-Magazin: Ihre zahlenden Kunden verlassen sich darauf, dass die Software, die Sie ausliefern, funktioniert. Womit testen Sie das?

Michel Smidt: Weil es sich beim UCS um ein sehr komplexes und vielschichtiges Produkt handelt, sind kontinuierliche, automatisierte Tests für uns ein sehr hilfreicher früher Indikator für Integrationsprobleme. Wir nutzen dafür Jenkins mit einer Reihe von Plugins und bauen dazu nachts zahlreiche verschiedene Umgebungen mit dazugehörigen automatisierten Tests auf. Das reicht von einfachen Installation bis hin zu komplexen Multiserverumgebungen mit mehreren Serverrollen und Active-Directory-Anbindungen.

Unser Jenkins führt pro Konfiguration ein so genanntes Shell Build aus. Das beginnt mit einem Checkout der speziellen Buildkonfiguration aus dem Git. Die Buildkonfiguration selbst ist ein Skript, in dem wir die Instanzen (Anzahl, Rolle, Instanzengröße, Hostserver, UCS-Profile) definieren. Wenn nötig, definieren wir hier auch Schritte zur Ausführung (Domänenjoins, Installation von Spezialpaketen). Viel davon haben wir in Libraries ausgelagert.

Dann starten die wirklichen Tests mit Produkt- oder Kundentestpaketen. Manchmal legen wir sie auch in die Kundenpakete selbst hinein. Die Tests sind in Python geschrieben und verwenden entweder das Python-eigene Unittest-Framework [5] oder Pytest [6]. Von uns selbst stammen Testhelper, beispielsweise um das UCS-LDAP leer zu räumen oder um ein Nutzerobjekt anzulegen, welches der Test erwartet.

Linux-Magazin: Wonach wählen Sie die Testszenarien aus?

Michel Smidt: Wir versuchen für jede Codeänderung mindestens einen Test zu haben. Das kann ein Unit-, ein Integrationstest oder ein anderer Check sein. Wir haben sogar viele als »expected to fail« -markierte Tests: Anhand der vorgegebenen Eingabe erwarten wir, dass das getestete System einen Fehler meldet. Sollte der nicht kommen, wäre das ein echter Fehler.

Linux-Magazin: Wo bleiben die Resultate?

Michel Smidt: Jenkins holt die auf den Testinstanzen entstehenden XML-Resultate ab, zeigt übersichtliche Diagramme an und versendet auch Mails. Ein Entwickler erfährt also, dass ein ihn betreffender Test fehlgeschlagen ist. Bei Entwickler-Branches muss der Mitarbeiter den Code selbst fixen, andernfalls wird der Branch nicht in den Hauptzweig gemerged. Sobald alles sauber erscheint, gehen die Änderungen in einen Release-Hauptzweig ein. Schlagen jetzt trotzdem wieder Tests fehl, macht der für die Komponente Zuständige ein Bugticket auf.

Etwas direkter läuft bei unseren Kundenprojekten, weil deren Testzyklen kürzer als bei regulären Produkten ausfallen: Sobald unsere Entwickler eine Änderung in Git einpflegen, baut ein Buildserver neue Pakete, und es starten automatisch UCS-Umgebungen mit den Tests. Anschließend erhält der Entwickler Meldungen, ob seine Änderungen unerwünschte Seiteneffekte in anderen Softwarekomponenten erzeugt haben. In den Kundenprojekte versuchen wir so nah wie möglich an dem späteren Zustand der Produktivumgebung zu bleiben. Teilweise schreiben wir extra Mock-Services, welche die Interaktion mit Fremdsystemen simulieren.

Selbst ist der Admin

Eine normale Anwenderfirma muss die Tests selbst entwerfen. Das klingt schwieriger als es ist, da schon wenige mit gutem Ausgang absolvierte Basistests ausreichen, um die Wahrscheinlichkeit, dass niemand mehr arbeiten kann, signifikant zu verringern. So braucht man beim Standard-Webbrowser nicht zwingend automatisch zu testen, ob nach einem Update die deutsche Rechtschreibhilfe in Formularen noch funktioniert. Normale Anwender werden ein paar Stunden auch ohne klarkommen. Geht aber firmenweit die Druckfunktion nicht mehr, dann ist das kritisch. Der Schwerpunkt dieses Linux-Magazins beschreibt mit mehreren Ansätzen beispielhaft, wie jeder solche Tests selbst implementieren kann.

Die Funktionstests bekommen nur einen Sinn, wenn sie vorab auf einem dafür reservierten echten oder virtuellen System laufen. Das bezieht seine Pakete direkt aus den Repositories der Distribution. Wer wie oben flächendeckend eine Softwareverteilung einsetzt, tut sich nun recht leicht: Laufen die Tests auf dem separaten System, spielt er die Updatepakete in die Softwareverteilung ein.

Wer kein solches System hat, muss auf andere Weise die Pakete zurückhalten. Sind alle Systeme gemanagt, könnte der Systemverantwortliche das Linux-Paketmanagement so modifizieren, dass es erst auf einen externen Befehl hin seine Updates holt und installiert. Das prinzipbedingte Problem hierbei: Erscheinen zwischen Test und Ausrollen weitere Updates Upstream, bleiben die ungetestet.

Eigenes Repository

Darum erscheint es besser, einen anderen Weg zu gehen. Der ist auch zwingend, wenn normale Mitarbeiter weitergehende Zugriffsrechte auf ihren Rechnern besitzen. Die Idee ist, ein eigenes Repository zu betreiben, bei dem sich alle Systeme bedienen. Der Admin spielt dann erst nach erfolgten Tests die anstehenden Pakete ein (also ein verzögertes Mirror-Update) und kann sicher sein, dass nun nichts mehr durchrutscht.

Distributionen wie Debian unterstützen das Ansinnen. Hier ist zuerst Reprepro [2] zu nennen, das einen Repository-Server sehr fein zu steuern in der Lage ist; Dokumente [3] erklären, wie das geht. Mit »checkupdate« und »checkpull« lassen sich zudem Erkundigungen einholen, ob es Änderungen am Quell-Repository gegeben hat. Debian stellt mit Lintian [4] sogar einen Paket-Checker bereit.