Eine wichtige Frage für den Admin größerer Netzwerke ist, wie er effizient neue Software installieren und alte auffrischen oder deinstallieren kann. Linux – hier gezeigt anhand von Debian-Systemen – bietet dazu unterschiedliche Möglichkeiten.

Das Verwalten vieler Linux-Büroarbeitsplätze und/oder vieler Linux-Server stellt den Administrator vor besondere Aufgaben. Denn die Dynamik, mit der Linux-Software entwickelt wird, macht Updates fast zur täglichen Aufgabe. Die zwingend einzuspielenden Sicherheitspatches tun ein Übriges. Mit einer CD durch die Büros und Serverräume zu laufen, ist nicht zumutbar und zudem fehlerträchtig.

Zentral gepflegte Images sind zu kompliziert

Eine Möglichkeit zur Vereinfachung bieten vollständig zentral gepflegte System-Images, die alle Rechner des Pools bei ihrem Start vom Server laden. Diese Technik ist jedoch recht anspruchsvoll in der Verwaltung: Nicht nur, dass es zusätzlicher Servertechnik bedarf, ein oder mehrere Images sind auch komplizierter zu pflegen als ein laufendes System. Ein weiterer Nachteil ist deren erhebliche Größe. Wer relativ schmalbandige LAN-Leitungen besitzt oder von Haus aus mit viel Netzwerkverkehr zu kämpfen hat, müsste dann aufwändige Differenztechniken einsetzen.

Wer ohne ein zentrales Image auskommen will, muss andere, zentral organisierte Wege finden, um die Software effizient auf allen Rechnern zu installieren, zu deinstallieren und zu konfigurieren. Softwareverteilungs-Programme versprechen hier Abhilfe. Proprietäre Programme dieses Genres sind jedoch für kleine bis mittelgroße Netze zum einen zu mächtig und zum anderen nicht eben billig (siehe Beitrag ab Seite 34).

Es liegt nahe, eine vergleichbare Funktionalität mit freier Software zu verwirklichen. Dieser Artikel beschreibt eine praktikable Lösung für diese Aufgabenstellung. Der beschriebene Ansatz hat seine Feuertaufe schon in Desktop-Projekten bestanden, die der Autor dieses Beitrags realisiert hat. Als Basis dient grundsätzlich das freie Debian GNU/Linux [1]. Ein Beispiel eines derart verwalteten Desktops zeigt Abbildung 1.

Zwei Aufgaben sind zu lösen

Der Administrator hat es mit zwei Aufgabenblöcken zu tun, wobei immer die zentral steuerbare Administrierbarkeit im Vordergrund steht: Als erste Aufgabe muss er neue Rechner installieren. Das klingt zunächst sehr einfach. Wer einen neuen Linux-Rechnerpool – ob Desktop-PCs oder Server – aufzubauen hat, wird alle Rechner so weit wie möglich gleich installieren und konfigurieren.

Aber: Unterschiedliche Hardware verlangt nach differenzierten Konfigurationen. Eine solche Umgebung verliert mit ihrer Nutzung in aller Regel ihren uniformen Charakter. Immer wieder kommen neue Rechner hinzu, weil alte kaputtgehen oder neue Mitarbeiter ausgerüstet werden wollen. Ab jetzt ist die Sachlage dann nicht mehr simpel.

Beim klassischen Ansatz eines Installations-Image, das einmal erstellt und auf allen Rechnern installiert wird, bekämen diese neuen Rechner allerdings zunächst eine alte Version des Firmendesktops verpasst und müssten anschließend auf den neuesten Stand gebracht werden – was alles andere als effizient ist. Viel besser ist es, wenn ein neues System immer sofort nach dem aktuellen Stand eingerichtet wird.

Die zweite Aufgabe ist, nach erfolgter Inbetriebnahme des Rechnerpools alle Systeme aktuell zu halten. Hierbei geht es nicht nur um die Installation neuer Versionen bereits vorhandener Software, weil neue Features gebraucht werden oder Sicherheitslücken zu beheben sind. Es geht auch um die Installation und Deinstallation ganzer Softwarepakete. Gerade der Deinstallation wird zu Unrecht wenig Beachtung geschenkt, obwohl sie in der Praxis oft nötig ist.

Der Master-Arbeitsplatz

Der Kristallisationspunkt einer Verteilungsstrategie ist der Master-Arbeitsplatz, also eine Installation, die der Administrator in Eigenregie verwaltet und einstellt. Die Master-Installation wird vom zuständigen Administrator als Vorlage für alle anderen Arbeitsplätze erstellt und verbleibt beim ihm, sodass er hier auch alle Arbeiten wie Updates und so weiter durchführen kann. Insbesondere hat der Master-Arbeitsplatz genau jene Softwarepakete installiert und vorkonfiguriert, die auf allen Arbeitsplätzen vorhanden sein sollen.

Vorbereiten der Installation

Im nächsten Schritt fertigt der Administrator eine Installations-CD oder ein Installations-Image, mit dem er vom Netzwerk booten kann. Das Image enthält nur einen Kernel, eine Hardware-Erkennung und eine Installationsroutine. Es wird anschließend von einem neu zu installierenden Rechner gebootet. Nachdem die Hardware erkannt und ein Basissystem gestartet ist, übernimmt die Installationsroutine ihre Tätigkeit. Sie installiert ein Basis-Debian-System, das man direkt von einem Spiegel des Debian-Archivs laden kann.

Vielleicht muss der Administrator noch das eine oder andere Paket zusätzlich installieren, das kein Bestandteil des Basissystems ist oder ausschließlich lokale Konfigurationen enthält. Wer ohne Netzwerkverkehr installieren möchte, wird die Pakete auf eine CD brennen. Das hat aber den Nachteil, dass der Admin öfter eine neue CD bauen muss, um die gerade aktuellen Pakete für die Installation parat zu haben.

Anschließend installiert man vom Master-Arbeitsplatz aus die Paketliste und die Konfiguration auf dem neu einzurichtenden Client. Das ist über eine spezielle URL im lokalen Netzwerk, über eine eingebundene Filesystem-Freigabe oder aber per SSH realisierbar. Eine Kopieroperation ist daher nicht zwingend notwendig, da die Debconf-Datenbank auch per NFS gemountet oder in einem LDAP-Server verwaltet werden kann. Insbesondere LDAP bietet dem Administrator vielfältige Möglichkeiten.

Am Schluss setzt der Verantwortliche die Paketliste für das lokale System. Damit besitzt das System genug Informationen für die restliche Installation, sodass das Absolvieren eines normalen System- updates ausreicht.

01 sudo dpkg --get-selections *| dsh -aci --  sudo dpkg --set-selection
02 dsh -a -c -- sudo apt-get update && apt-get -y  dist-upgrade

01 ssh <user@master> sudo dpkg --get-selections *|  sudo dpkg --set-selection
02 sudo apt-get update && apt-get -y dist-upgrade

Update vorhandener Rechner

Für bereits installierte Rechner funktioniert ein Update nahezu analog: Der Admin spielt auf dem Master-Arbeitsplatz Änderungen ein, führt Sicherheitsupdates durch, ändert Konfigurationen und entfernt überflüssige Software. Hierbei unterscheidet man zwischen einem Push-Update, bei dem der Administrator zentral das Update für alle Maschinen startet, und dem Pull-Update, bei dem sich jeder einzelne Rechner seine Änderungen abholt.

Nachdem die Paketliste erstellt wurde, wird sie, eventuell zusammen mit der Konfigurationsdatenbank, auf alle Arbeitsplätze verteilt, dann startet der netzwerkweite Update-Prozess. Wie von Martin Loschwitz in[2] beschrieben, bietet es sich hierfür an, Dancers Distributed Shell[3] einzusetzen, sodass ein Kommando den Updateprozess auf allen Rechnern startet. Listing 1 zeigt ein geeignetes Push-Update-Skript.

Der Push-Betrieb ist einem Pull-Betrieb vorzuziehen. Es kann jedoch sein, dass der Pull-Betrieb trotzdem eingerichtet werden muss, beispielsweise für Notebooks, die nur temporär im LAN sind. Die Rechner können sich ihre Daten selber aus dem Intranet holen und den Updateprozess anstoßen. Das sollte regelmäßig passieren, besonders aber nach jeder längeren Abwesenheit.

Hierzu trägt man den Skriptaufruf in die Anacron-Tabelle ein. Anacron[4] funktioniert ganz ähnlich wie das bekannte Cron, setzt jedoch nicht voraus, dass das System immer läuft. Mit Hilfe von Anacron kann man die Kommandos in einem Zeitintervall ausführen, das dem anvisierten möglichst nahe kommt (siehe Listing 2).

Etwas aufwändiger wird die Verwaltung, wenn verschiedene Client-Varianten gepflegt werden wollen. Typisch dafür ist, dass einzelne Softwarepakete nur auf manchen Rechnern installiert sein sollen und auf den anderen nicht. Zum Glück benötigt man hierfür nicht zwingend weitere Master-Arbeitsplätze. Denn der Admin darf Installationen nicht nur auf verschiedenen Partitionen vornehmen, er kann auch die Auswahl der zu installierenden Software beschränken. Hierzu ist nicht mehr erforderlich, als die Paketliste geeignet zu filtern.

Sollten einige Konfigurationswerte unterschiedlich zu setzen sein, erstellt man eine zweite Debconf-Datenbank, die die Änderungen zum Standard enthält und die das System priorisiert liest (siehe Kasten “Debians Paketverwaltung”). Das nutzen alle neueren Debian-System aus, um die normalen Konfigurationsdaten von Passwortdaten zu trennen.

Abbildung 1: Die Debian-Software dieses Desktops wird von einem Server gesteuert verteilt.

Abbildung 2: Gerade findet ein gleichzeitiges Upgrade auf den Rechnern »newton«, »einstein« und »zuse« statt. Wie zu sehen ist, hatte »einstein« eine alte Version des Pakets »watchdog« installiert, die das Upgrade durch eine neue ersetzt. »newton« und »zuse« waren bereits aktuell.

Live-Update SuSE Linux

Die Nürnberger Mainstream-Distribution besitzt seit Version 7.1 eine Online-Update-Funktion. Das zugehörige Tool You (Yast Online Update) ist eine Eigenentwicklung von SuSE und grafikbasiert. Die neuen SuSE-RPMs sind signiert, damit böswillige, Internet-technisch versierte Zeitgenossen den gutgläubigen SuSE-Nutzern nicht so einfach selbst gefertigte Fake-Pakete unterschieben. Um die Signatur zu prüfen, sind die Pakete wie folgt zu behandeln: rpm -v --checksig Datei.rpm Da es sich bei You nicht um freie Software handelt, entstand in der Community ein Ersatz names Fou4s (Fast Online Update for SuSE)[7]. Alternativ existiert ein Apt-get für SuSE [8]. Ein Vergleich dieser drei Update-Werkzeuge ist unter [9] zu finden. Abbildung 3: You von SuSE ist ein grafisches Tool zum automatischen Einspielen neuerer RPM-Pakete.

Software-Archive

Der Pool der verfügbaren Software ist direkt aus dem Internet[5] beziehbar, kann auf einem lokalen Mirror liegen oder auf einer oder mehreren CDs. Alle Quellen sind kombinierbar. So kann der Administrator zum Beispiel Pakete mit lokalen Anpassungen auf einen Mirror legen, sicherheitsrelevante Updates direkt von [security.debian.org] laden und bei einem kompletten Wechsel auf eine neue Release die Software dann per CD verteilen.

Bekanntermaßen sind die Release-Zy- klen bei Debian länger als bei anderen Distributionen. Das führt dazu, dass die aktuelle Version zwar sehr stabil und arm an Fehlern ist, aber nicht immer die neuste Software zur Verfügung stellt. Andererseits benötigen viele Benutzer die neuere Versionen der einen oder anderen Software, ohne gleich das gesamte Basissystem auf einen neuen Stand bringen zu wollen.

Darum machen es sich immer wieder einzelne Entwickler zur Aufgabe, Pakete aus der gerade im Test befindlichen Version (Unstable) auf die aktuelle Release zurückzuportieren und als Archiv ins Internet zu stellen[6]. Diese Archive kann der Systemverantwortliche in den Update-Zyklus einbinden, er sollte sich jedoch zuvor vergewissern, dass er dabei keine Fakes von Hackern erwischt. Nicht vertrauenswürdige Quellen also unbedingt meiden!

Einen offiziellen Debian-Mirror vortäuschen ist für einen zwielichtigen Zeitgenossen weitaus schwieriger, denn dort sind alle Sourcepakete mit dem GPG-Schlüssel des jeweiligen Maintainers signiert – eine Fälschung ist also relativ leicht erkennbar: Um sicher zu sein, dass Binärpakete in Ordnung sind, kompiliert man die Sourcen selbst. Das geht bei Bedarf auch vollautomatisch.

Zusätzlich besteht natürlich die Möglichkeit, die Inhalte eines Mirrors mit denen eines anderen oder sogar denen des Master-FTP-Servers zu vergleichen oder einen Satz von CDs zu kaufen, die wiederum alle Pakete enthalten. Um diese Kontrolle zu vereinfachen, arbeitet das Debian-Team gegenwärtig daran, die Paketlisten mit einem Release-Schlüssel zu signieren. Da die Paketlisten wiederum MD5-Summen beinhalten, wird die Kontrolle jedes einzelnen Binärpakets möglich.

Sobald sich ein sicherheitsrelevanter Fehler in der Distribution findet, wird das betroffene Paket vom Debian-Sicherheitsteam unter die Lupe genommen und bereinigt. Um laufende Systeme so wenig wie möglich zu beeinflussen, baut der Paket-Maintainer nur den Bugfix ein, nicht jedoch in der Zwischenzeit eventuell neu hinzugekommene Features. Nach ausführlichen Tests wird ein gefixtes Paket als Sicherheitsupdate zur Verfügung gestellt. Das Paket wird über entsprechende Kanäle per signierter E-Mail angekündigt. Sie beinhaltet neben der Beschreibung des Fixes auch eine MD5-Summe des Pakets, sodass der Anwender die Möglichkeit hat, die Identität des Pakets zu kontrollieren.

Wenn nach einiger Zeit mehrere gefixte Pakete zusammenkommen und es möglicherweise noch weitere neue Pakete für die stabile Distribution gibt, die zwar unangenehme, aber nicht sicherheitsrelevante Fehler beseitigen, prüft der Release-Manager, ob er eine neue Point-Release, also zum Beispiel 3.0r2, zusammenstellt.

Live-Update von Mandrake

Der mit seinen Distributionen recht weit verbreitete, aber wirtschaftlich am Boden liegende französische Hersteller Mandrakesoft besitzt seit Version 8.0 eine automatisierte Online-Update-Funktion. Der Mandrake-Besitzer startet den Updateprozess in der Regel im grafische Mandrake-Kontrollzentrum. Im Hintergrund startet dabei das Perl-Skript »/usr/sbin/MandrakeUpdate«, hinter dem sich das »rpmdrake«-Skript verbirgt. Das Live-Update bezieht seine RPMs normalerweise von Mandrake-Mirrors wie [ftp://ftp.tu-clausthal.de/pub/linux/mandrake/updates/ Version/RPMS]. An gleicher Stelle liegt die nicht eben kleine Datei »base/hdlist.cz«, die das Perl-Skript »/usr/sbin/urpmi.update« per Wget abholt – sofern das Mandrake-System keine aktuelle Version davon vorrätig hat. Das Gzip-gepackte File enthält eine Mandrake-spezifische Datenbank, die alle relevanten Informationen zur den neuen Paketen auf dem Mirror vorhält. Der Update-Mechanismus gleicht diese Informationen mit der URPM-Datenbank des laufenden Systems ab und präsentiert dem Benutzer eine Liste der zu aktualisierenden Pakete. Soweit der Benutzer auf die Vorschläge eingeht, holt das Skript per Wget die neuen RPM-Pakete ab und installiert sie. Um Missbrauch vorzubeugen, signiert das “Mandra-ke Linux Security Team” alle frischen RPMs mit einem GPG-Schlüssel. Abbildung 4: Der Update-Mechanismus von Mandrake gleicht die Online- Informationen mit der RPM-Datenbank des laufenden Systems ab und präsentiert dem Benutzer eine Liste der zu aktualisierenden Pakete.

Fazit

Debian GNU/Linux verteilt, konfiguriert und entfernt über seine Bordmittel einfach und effektiv Software im Netzwerk. Vorteil: Der Administrator eines Linux-Netzwerks – ob mit Desktop-PCs oder Servern – muss darum für den laufenden Betrieb keine zusätzlichen Kosten einplanen. Das gezeigte Vorgehen ist zum großen Teil auch auf andere Distributionen übertragbar. (jk)

Live-Update Red Hat

Der amerikanische Marktführer bietet einen Update-Dienst names Up2date an. Mit dem gleichnamigen Tool »up2date« ist ein skriptgesteuertes Updaten der Rechner möglich. Zusätzlich gibt es auch die Möglichkeit, über eine Webseite Pakete zur Installation oder Deinstallation vorzusehen. Der Dienst ist zwar vorläufig kostenlos, verlangt aber gelegentlich ein Meinungsbild seiner angemeldeten Benutzer. Auch Red-Hat-RPMs sind signiert, um Crackern das Leben etwas schwerer zu machen. Um die Signatur zu prüfen, sind die Pakete wie folgt zu behandeln: »rpm -K Datei.rpm«. Zuvor muss der Red-Hat-Key dem System bekannt gemacht werden, was mit rpm --import /usr/U share/rhn/RPM-GPG-KEY funktioniert. Abtrünnige Debianer aufgepasst: Auch für Red Hat gibt es wie für SuSE Linux eine Apt-get-Version, die im Gegensatz zu Up2date keine Informationen über den Rechner nach außen gibt[10]. Einen Vergleich der Ansätze findet man zum Beispiel unter[11]. Abbildung 5: Bei Red Hat muss sich anmelden, wer in den Genuss aktualisierter Pakete kommen will.