TU Chemmnitz

Universitätsrechenzentrum
TU Chemnitz > URZ > Zeitung > Ausgabe 4/2004

A Toolbox for System Configuration and Administration (ToSCA)

ToSCA ist das Kürzel für Toolbox for System Configuration and Administration. ToSCA ist ein System von Datenstrukturen, Verfahren und Methoden zur effektiven und skalierbaren Systemadministration von Rechnern unterschiedlicher Systemplattformen. Der Artikel erläutert die Notwendigkeit einer solchen Entwicklung und gibt einen Einblick in einige Konzepte und Komponenten.

Motivation

Wer einen Computer nutzt - für welche Zwecke auch immer - hat meist auch mit Fragen der System- und Netzwerkadministration zu tun. Bereits die Installation eines Betriebssystems auf einem Rechner gehört zu diesem Aufgabenkomplex. Die Anbindung des Rechners an das Internet, das Einspielen von Anwendungssoftware, die Beseitigung von Sicherheitslücken, all das sind typische - aber bei weitem nicht alle - Aufgaben der System- und Netzwerk-Administratoren (im folgenden SysAdmins genannt). Wenn ein Nutzer solche Arbeiten an "seinem" Rechner zu erledigen hat (vorausgesetzt er hat das erforderliche Know-How ;-), geschieht das im Regelfalle dadurch, dass er sich über grafische Oberflächen, Web- oder Menü-Schnittstellen "durchhangelt", die entsprechenden Knöpfe (Buttons) anklickt bzw. abgefragte Informationen über die Tastatur eintippt. Diese Vorgehensweise ist zeitaufwändig, wird jedoch meist ohne Klagen in Kauf genommen, wenn am "Ende" der Bemühungen ein funktionsfähiger Rechner bereitsteht. Besteht die Aufgabe darin, nicht nur einen, sondern mehrere Rechnersysteme (Pool, Cluster, Arbeitsgruppe) zu administrieren, spielt der Faktor Zeit schon eine größere Rolle. Vermutlich geht das Eintippen und Klicken wegen des Routineeffektes etwas schneller, aber insgesamt multipliziert sich der Zeitaufwand mit der Anzahl der zu betreuenden Rechnersysteme. Außerdem besteht die Gefahr, dass sich die Systeme im Detail unterscheiden, selbst wenn sie identisch konfiguriert sein sollten: wer ist schon in der Lage, die "per Hand" durchgeführten Aktionen exakt zu wiederholen?

Möglicherweise ist eine solche Vorgehensweise für einige wenige Rechnersysteme hinsichtlich Aufwand und Konsistenz noch akzeptabel. Wie aber sollte man vorgehen, wenn sehr viele Rechner betreut werden müssen? An der TU Chemnitz sind gegenwärtig annähernd 10000 (zehntausend) Rechnereinheiten im Einsatz, davon werden ca. 2000 durch MitarbeiterInnen des URZ administriert. Bei solchen Stückzahlen ist eine grundsätzlich andere Vorgehenweise als die oben skizzierte erforderlich - das Zauberwort heißt Automatisierung.

Tatsächlich drängt sich hierbei der Vergleich mit unterschiedlichen Modellen der Warenproduktion auf: einerseits der kostenintensiven (Hand-)Fertigung einer kleinen Anzahl eines bestimmten Produktes mit individuell ausgeprägten Eigenschaften, und andererseits der kostengünstigen Massenproduktion mit eher begrenzter Individualisierungsvielfalt. Möglicherweise ist das erste Modell für den Produzenten befriedigender (für den zahlungskräftigen Kunden sowieso). Die Notwendigkeit der Massenproduktion ergibt sich vornehmlich aus ökonomischen Gesichtspunkten, minimiert werden sollen die einschlägigen Kostenfaktoren, insbesondere die Personalaufwendungen.

Im Bereich der System- und Netzwerkadministration gibt es wenig SW-Lösungen, die sich solchen Zielstellungen verschreiben. Existierende SW-Produkte sind entweder nicht bezahlbar oder für die Anforderungen höherer Bildungseinrichtungen nicht geeignet (oder beides).

ToSCA ist eine Entwicklung des URZ mit der Zielstellung, die Betriebskosten von Rechnersystemen sowie den erforderlichen personellen Aufwand bei der systemseitigen Betreuung dieser Rechner zu reduzieren.

Wesentliche Entwurfsziele

Unterstützung unterschiedlicher Betriebssystemfamilien und Systemplattformen

Grundsätzlich ist der ToSCA-Ansatz offen für verschiedenste Betriebssystemfamilien, seien es die zur Familie Linux gehörenden relevanten Linux-Distributionen oder die aktuellen (und zukünftigen) Betriebssysteme von Microsoft (z.B. WXP, W2000, W2003). Das bedeutet nicht, dass SysAdmin-Dienste durch das URZ für alle Distributionen und BS-Versionen bereitgestellt werden. Im konkreten Fall ist das von einer Reihe von Aspekten abhängig, auf die hier nicht weiter eingegangen werden soll.

Unter Systemplattform versteht man die Kombination von HW-Architektur und Betriebssystem einer bestimmten Version. Beispiele für unterschiedliche Systemplattformen sind

Auch hier hilft zum Verständis eine Analogie aus der "realen Welt": Verschiedene Betriebssystemfamilien entsprechen unterschiedlichen Auto-Herstellern, während eine Systemplattform einem konkreten Modell eines bestimmten Herstellers entspricht. Es ist offensichtlich, dass sich für den Benutzer (Fahrer) vergleichsweise geringe Unterschiede ergeben, während SysAdmins (KFZ-Techniker) spezielle Fähigkeiten und Erfahrungen für jede Systemplattform (jedes zu reparierende Modell) benötigen. Hierbei gilt: die Details bestimmen Unterschied und Aufwand.

Insofern ist die Kategorisierung in Betriebssystemfamilien und Systemplattformen ein Ansatz, um die bei der Systemadministration existierenden Unterschiede/Abweichungen in geeigneter Weise abzubilden.

Skalierbarkeit hinsichtlich Anzahl der Rechner und der Einsatz-Vielfalt

Der Personalaufwand steigt mit jedem weiteren zu betreuenden Rechner. Insofern müssen die eingesetzten Verfahren skalieren, d.h. sie müssen weitgehend automatisiert und der Anteil der "Handarbeit" minimiert werden. Die funktionellen Besonderheiten der Rechnersysteme (dedizierte Serverfunktionalität, spezielle SW usw.) sind weitere Faktoren, die die Skalierbarkeit beeinflussen. Den vergleichsweise geringsten Betreuungsaufwand verursachen Pools oder Cluster mit gleicher Hardware- und SW-Konfiguration.

Die Automatisierung selbst muss einigen Anforderungen genügen. Die wichtigste besteht darin, dass die Verfahren hinreichend abstrakt und allgemeingültig sind und sich somit generisch auf konkrete Rechner oder Rechnerklassen anwenden lassen.

Unterstützung kooperativer Systemadministration

Außer den SysAdmins für die jeweiligen Betriebssystemfamilien sind noch eine Reihe von Personen an Admin-Aufgaben beteiligt. Einerseits sind das die "Spezialisten" für bestimmte Sachgebiete, z.B. Hinzu kommen die Verantwortlichen für spezielle Funktionen und Dienste, z.B. um nur einige zu nennen. Da sich die Verantwortungsbereiche der beteiligten Personen zumindest teilweise überlagern, besteht hierbei ein nicht zu unterschätzendes Konfliktpotenzial. Überschneidungen müssen ebenso vermieden werden wie "Verantwortungs-Lücken", d.h. Bereiche, wo sich keiner verantwortlich fühlt, sondern auf andere verlässt. Um kooperative SysAdmin erfolgreich zu gestalten, bedarf es bei den Beteiligten gewisser Voraussetzungen, üblicherweise mit dem Schlagwort "Teamfähigkeit" umschrieben. Andererseits sollten die zur Systemadministration eingesetzten Verfahren selbst kooperative Sysadmin unterstützen. Die ToSCA-Konzepte wurden speziell im Hinblick auf kooperative Systemadministration entworfen. Schließlich benötigt man für jene Bereiche - wo technische Verfahren nicht greifen - geeignete organisatorische Regelungen und Konventionen (Policies).

Prinzipien der Systemkonfiguration

Im Grunde kann der Zustand eines Rechnersystems über seine Systemkonfiguration beschrieben werden. Die Informationen über die Systemkonfiguration werden in Konfigurationsfiles abgespeichert. Änderungen der Systemkonfiguration werden direkt wirksam oder indirekt, d.h. nach einer bestimmten Aktion, z.B. der Ausführung eines speziellen Skriptes oder Programmes.

Die Konsistenz der Konfigurationsfiles ist letztlich für die korrekte Funktionsweise eines Rechners notwendig. Zwei Konzepte bilden die Grundlage der Systemkonfiguration mittels ToSCA

Klassen

Das Klassenkonzept ermöglicht es, Konfigurationsfiles sowie Aktionen für die zu betreuenden Rechnersysteme übersichtlich und korrekt zu adressieren. Zunächst gehört ein Rechner einer Systemplattform-Klasse an, bei Dual-Boot-Rechnern möglicherweise auch einer weiteren. Jedes Rechnersystem wird in genau eine Funktions-Klasse eingeordnet, die Funktions-Klassen sind zueinander disjunkt. Z.B. gehören alle Rechner des Ausbildungs-Pools in der Strasse der Nationen, Raum 066 zur Funktionsklasse FU_POOL_SN_066 

   FU_POOL_SN_066 = ( atair rigel deneb wega algol arktur capella prokyon 
                      pollux sirius castor regulus )

Um gemeinsame Eigenschaften besser abzubilden, können mehrere Funktionsklassen zu Verbund-Funktionsklassen zusammengefasst werden, z.B. alle Pools im Gebäudeteil Straße der Nationen 

  CFU_POOL_SN = ( FU_POOL_SN_066 FU_POOL_SN_207 FU_POOL_SN_203 )

Jeder Rechner bildet eine eigene Klasse, die sog. Host-Klasse. Damit können rechnerspezifische Konfigurationen realisiert werden. Außerdem gibt es noch die generische Klasse any, zu der alle Rechner (Hosts) gehören. Auf diese Weise ist es auf einfache und elegante Weise möglich, Aktionen zu definieren, die für alle Rechner zutreffen.

Repositories

Repositories im Sinne von ToSCA sind Filesystem-Bäume für Prototypen von Konfigurationsfiles. Repositories befinden sich in einem Netzwerkfilesystem und sind von allen aktiven Rechnersystemen lesbar. Für jede definierte Klasse wird ein Repository aufgespannt, es enthält genau jene Prototypen von Konfigurationsfiles, die diese Klasse von anderen Klassen unterscheiden. Dabei gilt für jeden Prototyp:

Der Pfadname eines Konfigurationsfiles in einem Repository ist dabei i.a. identisch zu dem Pfadnamen des Konfigurationsfiles im Systemfilesystem. Ein einfaches Beispiel soll das verdeutlichen. Im Repository für FU_POOL_SN_066 ist u.a. der Standard-Drucker für (Linux-)Rechner dieses Pools festgelegt. 

    .../FU_POOL_SN_066/etc/cups/lpoptions

Dementsprechend stehen diese Konfigurationsinformationen auf jedem Linux-Rechner des Pools unter 

    /etc/cups/lpoptions

Änderung der Systemkonfiguration

Änderungen der Prototypen von Konfigurationsfiles können zu einem beliebigen Zeitpunkt an irgendeinem Rechner vorgenommen werden, vorausgesetzt der betreffende SysAdmin hat die notwendigen Zugriffsrechte. Eine Änderung geschieht indirekt, d.h. sie wird auf einem Rechnersystem erst wirksam, nachdem das Prototyp-File auf den Rechner kopiert und evtl. eine zusätzlich erforderliche Aktion durchgeführt wurde (z.B. der Neustart der betroffenen Systemkomponente). Der Zeitpunkt für das Aktualisieren einer Systemkonfiguration kann nach den Erfordernissen bestimmt werden

cfengine

Der beschriebene Ansatz kann mit Hilfe der interpretativen Programmiersprache cfengine optimal umgesetzt werden. Ein cfengine-Programm beschreibt den Soll-Zustand eines oder mehrerer Rechnersysteme, festgestellte Unterschiede werden bei der interpretativen Abarbeitung des Progammes korrigiert. Eine wesentliche Stärke von cfengine besteht in der Möglichkeit, klassen-basierte Entscheidungsstrukturen im oben genannten Sinne zu formulieren. Cfengine-Sprachobjekte sind z.B. Rechner, Files, Programme, Skripten und Prozesse, entsprechende Operationen sind z.B. das Kopieren von Files oder File-Hierarchien, die Ausführung von Skripten und Programmen, das Senden von Signalen an Prozesse.

Bereitstellung und Pflege von System- und Anwendungs-Software

Im Wesentlichen basiert der Mechanismus der SW-Pflege in ToSCA auf drei Komponenten:

ToSCA stellt für jede unterstützte Systemplattform Software-Repositories zur Verfügung für

Diese Repositories sind die Basis sowohl für die (Erst-)Installation von System- und Anwendungssoftware als auch für die Propagierung von SW-Updates auf die jeweiligen Rechner.

Spezielle Konfigurationsfiles legen bezogen auf die Funktionsklasse fest, welche SW-Pakete auf Rechnern dieser Funktionsklasse zu installieren sind. Die Konfigurationsfiles enthalten nur die Paketnamen. Welche konkrete Version eines Paketes installiert werden soll, legen die SW-Repositories fest. Dabei gilt der Grundsatz, dass sich von jedem SW-Paket nur die jeweils aktuelle Version in einem der Repositories befindet. Korrigierte SW-Komponenten (z.B. nach Beseitigung von Sicherheitslücken) werden in das Update-Repository abgelegt und gleichzeitig die alte Version aus dem Repository entfernt. Der Austausch der SW-Komponente auf einem Rechner erfolgt, wenn die Prozeduren zum automatischen SW-Update auf diesem Rechner ausgeführt werden. Im Regelfall passiert das einmal täglich. In analoger Weise wird die Neuinstallation eines (oder mehrerer) SW-Pakete angefordert, indem die Namen der Pakete in das Konfigurationsfile eingetragen werden. Den "Rest" erledigen wiederum die o.g. Prozeduren. Diese basieren auf Verfahren, die abhängig von der jeweiligen Betriebsystemfamilie sind (z.B. im Linux: yum).

Unter diesen Voraussetzungen ist es notwendig, die Aktualität und Konsistenz der SW-Repositories zu jedem Zeitpunkt aufrecht zu erhalten. Aus diesem Grund wird das Verfahren zur SW-Pflege durch Technologien für den Bau von SW-Paketen, Konventionen zur Bereitstellung von contributed SW sowie Policies zur Qualitätssicherung gestützt.

Datenaufzeichnung und "Real World"-Informationen

Für jedes betreute Rechnersystem werden bestimmte Daten aufgezeichnet und in sog. LOG -Repositories für diesen Rechner abgespeichert. Dazu gehören u.a. Da diese Daten im Netzwerkfilesystem liegen, sind sie zu jedem Zeitpunkt verfügbar und auswertbar für Bestandsaufnahmen, Fehlersuche usw. Entscheidend ist, dass diese Daten automatisch durch entsprechende SW-Tools erzeugt und abgespeichert werden, es handelt sich praktisch um Selbstauskünfte des Systems.

Allerdings müssen einige spezifische Daten für jeden Rechner von Hand gepflegt werden. Solche Daten bezeichnet man in ToSCA "Real World"-Informationen. Sie können nicht automatisch erfasst und geändert werden, sondern müssen von den zuständigen SysAdmins festgelegt und per Hand in eine Datenbank eingegeben werden. Das erfolgt erstmalig mit der Integration eines Rechners in die ToSCA-Technologie und betrifft Daten, die auf Entscheidungen des SysAdmins bzw. des Betreibers basieren, z.B.

Der Pflegeaufwand ist nicht besonders hoch, selbst wenn man ins Kalkül zieht, dass es sich um eine sehr große Anzahl von Rechnersystemen handelt. Das Problem besteht allerdings darin, dass die Pflege solcher Daten von "unzuverlässigen Menschen" erfolgt, die allzu oft einfach vergessen, diese Daten zu aktualisieren. (Der Rechner selbst kann keine Auskunft darüber geben, dass sich z.B. der Ansprechpartner oder der Standort geändert haben.) Die Konzentration dieser Daten in einer Datenbank und die Buchführung über alle vorgenommen Änderungen (CVS) erleichtern es, die Daten konsistent zu halten. Zumindest können eventuelle Inkonsistenzen durch entsprechende Prüf-Skripte angezeigt werden.

SysAdmin-Autorisierung

Wie bereits erwähnt sind an der Systemadministration mehrere Personen mit unterschiedlichen Aufgaben und Verantwortungsbereichen beteiligt. Für diese Personen und Personengruppen müssen insbesondere folgende Fragen geklärt werden Die Grundlage für diese Entscheidungen bilden Datenbanken, in denen die verschiedenen Verantwortungsbereiche und die jeweils verantwortlichen Personen definiert sind. Daraus werden über entsprechende Skripte die Privilegien und Zugriffsrechte generiert. Dabei erfolgt eine Abbildung auf die von den Betriebssystemen bereitgestellten Mechanismen zur Ausführung privilegierter Aktionen. In Linux-Systemen steht z.B. der sudo -Mechanismus zur Verfügung, der über /etc/sudoers konfiguriert werden kann. Wie in ToSCA üblich, wird dieses Konfigurationsfile als Prototyp in den entsprechenden Repositories für die Host-Klassen erzeugt und in einem zweiten Schritt (per cfengine) auf den Rechner kopiert.

Ausblick

Die Betreuung von Rechnersystemen ist ein bewegliches Ziel: auf Grund der vielfältigen Anforderungen und der täglich neu zu lösenden Probleme muss ToSCA ständig weiter entwickelt und verbessert werden. Gegenwärtig wird ToSCA hauptsächlich für die Systemadministration von Linux-Rechnersystemen (Fedora Core, Scientific Linux, jeweils für die X86-Architektur) eingesetzt. Als eines der nächsten Projekte soll die Integration der Betriebssysteme WXP und W2003 realisiert werden. Die Erschließung weiterer Architekturen (x86_64, ia64) für Linux ist ebenso vorgesehen wie die Einbeziehung der automatischen Installationsverfahren (Kickstart, Imaging) in die ToSCA-Technologien. Aus diesen Entwicklungen sollen jeweils entsprechende ADMIN-Dienste abgeleitet werden, die von Angehörigen der TU Chemnitz in Anspruch genommen werden können. Grundsätzlich bestehen dabei zwei Möglichkeiten:

In die zweite Gruppe fallen die Dienste zur Rechner-Installation bzw. zum Software-Update.

Literaturhinweise


Matthias Clauß, Oktober 2004