ToSCA: Repositories

ROOT-Repos
SW-Repositories
CFENGINE-Repos
SCRIPT-Repos
LOG-Repos

Für jede BS-Familie existiert ein autonomes ToSCA-Environment, d. h. eine individuelle Hierarchie von Verzeichnissen (Repositories) für

Prototypen von Konfigurationsfiles (ROOT-Repos)
Cfengine-Daten und -Scripts (CFENGINE-Repos)
Software (SW-Repos)
ToSCA-Scripte (SCRIPT-Repos)
Log-Files und Host-Informationen (LOG-Repos)

Repositories befinden sich im AFS, für berechtigte Nutzer ist der Lese- bzw. Schreibzugriff möglich. Wenn ein Host ToSCA-Tools, z. B. Cfengine ausführt, dann werden entsprechend seiner Klassenzugehörigkeit die „richtigen“ Repositories ausgewählt.

ROOT-Repos

ROOT-Repos enthalten Prototypen von (Konfigurations-)Files. Diese werden mittels Cfengine in das Systemfilesystem eines Hosts kopiert, wenn

der Host zur Klasse des betreffenden Repos gehört
sich Quell- und Ziel-File unterscheiden (MD5).

Die Grundidee besteht darin, für jede

BS-Klasse
AI-SP-Klasse
Major-SP-Klasse und
Minor-SP-Klasse

Verzeichnishierarchien im AFS für die definierten

FU-Klasse
CFU-Klasse
AT-Klasse
Host-Klassen sowie
die Klasse any

aufzuspannen, die der Hierarchie des Systemfilesystems der betreffenden BS-Familie entspricht.

Die Abbildung verdeutlicht das Prinzip:

Angenommen, ein Host mit dem Namen magog hat die Funktion eines Referenz-Servers (FU-Klasse FU_REFERENZ_SERVER, CFU-Klasse CFU_SERVER) für die Systemplattform Scientific Linux 6.5 (64 Bit).
Dann sind für magog folgende ROOT-Repos definiert:

   .../ToSCA/ROOTS/LINUX/ROOT4ANY/
   .../ToSCA/ROOTS/LINUX/CFU_SERVER/
   .../ToSCA/ROOTS/LINUX/FU_REFERENZ_SERVER/

   .../ToSCA/ROOTS/SL_6/ROOT4ANY/
   .../ToSCA/ROOTS/SL_6/CFU_SERVER
   .../ToSCA/ROOTS/SL_6/FU_REFERENZ_SERVER/

   .../ToSCA/ROOTS/SL_6_x86_64/ROOT4ANY/
   .../ToSCA/ROOTS/SL_6_x86_64/CFU_SERVER/
   .../ToSCA/ROOTS/SL_6_x86_64/FU_REFERENZ_SERVER/

   .../ToSCA/ROOTS/SL_6.5_x86_64/ROOT4ANY/
   .../ToSCA/ROOTS/SL_6.5_x86_64/CFU_SERVER/
   .../ToSCA/ROOTS/SL_6.5_x86_64/FU_REFERENZ_SERVER/
   .../ToSCA/ROOTS/SL_6.5_x86_64/magog/

Es ist also z.B. möglich, alle Systeme der BS-Familie LINUX identisch zu konfigurieren, indem die betreffenden Prototyp-Files unter .../ToSCA/ROOTS/LINUX/ROOT4ANY/ eingeordnet werden. Andererseits kann man den Host magog individuell konfigurieren, indem man die Prototyp-Files in dem Repo des betreffenden Hosts, d.h. .../ToSCA/ROOTS/SL_5.1_X86/magog/ ablegt. Die "Kunst" besteht letztlich darin, für einen bestimmten Konfigurationsaspekt das geeignete Repo auszuwählen.
Für jeden Prototyp gilt:

finde die allgemeingültigste Klasse
vermeide identische Prototypen

Während eines Cfengine -Laufes wird ein Ziel-File nur einmal durch Kopieren verändert.

Eine Überlagerung (Interferenz) von Prototyp-Files muss unbedingt vermieden werden, da andernfalls unbestimmt ist, welcher der Prototypen letztlich durch Cfengine auf einem Host gespeichert wird.

Hinweise

Bei Windows-Systemen existieren keine AI- bzw. Major-SP-Klassen. Demzufolge existieren auch keine ROOT-Repo-Hierarchien.

ROOT-Repos für Hostklasse existieren nur für die betreffende Minor-SP-Klasse.

Repos für AT-Klassen werden nur für die BS-Klasse aufgespannt.

SW-Repositories

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

Software-Repositories
Konfigurationsfiles, die den Paket-Bestand eines Hosts definieren
Prozeduren zur automatischen Installation bzw. Update von SW-Paketen

Für jede unterstützte Systemplattform existieren Software-Repositories für:

vom Hersteller/Distributor gelieferte SW-Updates (DIS-Update-Repos)
(verifizierte) Software-Updates (URZ-Update-Repos)
darüber hinaus beigesteuerte SW-Pakete, die von den Verantwortlichen für die betreffenden Sachgebiete betreut werden (URZ_CONTRIB-Repos)

Die 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 Hosts. Hierarchie der SW-Repos

Konfiguation des Paket-Bestandes

Spezielle Konfigurationsfiles legen bezogen auf die Funktionsklasse fest, welche SW-Pakete auf Hosts dieser Funktionsklasse zu installieren sind. Die Konfigurationsfiles enthalten nur Paketnamen und Paket-Architektur. Welche konkrete Version eines Paketes installiert werden soll, wird durch die Repos (URZ-Update-Repo bzw. URZ_CONTRIB-Repo) bestimmt. Dabei gilt der Grundsatz, dass sich von jedem SW-Paket nur die jeweils aktuelle Version in einem der Repositories befindet. Korrigierte SW-Pakete (z.B. nach Beseitigung von Sicherheitslücken) werden in das betreffende Update-Repository abgelegt und gleichzeitig die alte Version entfernt.

Automatische Installation und Update

Der Austausch der SW-Komponente auf einem Host erfolgt, wenn die Prozeduren zum automatischen SW-Update auf diesem Host ausgeführt werden. Im Regelfall passiert das einmal täglich. Die Neuinstallation eines (oder mehrerer) SW-Pakete wird 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 ).

URZ_CONTRIB-Repos

Private SW-Repositories dienen dazu, SW-Pakete zur Nutzung bereit zustellen

die nicht zum vom Hersteller gelieferten SW-Paket-Umfang gehören bzw.
die vom Hersteller-Umfang gehören, aber an spezifische Nutzungsbedingungen angepasst werden müssen.

Das trifft sowohl für die Linux-Distributionen als auch für die Windows-Systeme und demzufolge auch für die unterschiedlichen Paketierungsformate (RPM, MSI, ...) zu.

Für jedes SW-Paket ist genau eine Person "verantwortlich", sei es, weil sie die SW selbst entwickelt oder angepasst hat oder weil sie inhaltlich für die SW zuständig ist.

Jedem "Contributor" wird ein Set privater SW-Repositories bereitgestellt:

bei Linux-Distributionen je ein Repos für die BS-Familie (LINUX), für jede Major-Version und Minor-Version
bei Windows je ein Repository für die BS-Familie (NT, VISTA) und für jedes einzelne Windows-BS

Dort kann er für verschiedene Systemplattformen selbst "gebaute" oder adaptierte SW-Pakete ablegen, möglicherweise in unterschiedlichen Versionen/Releases. Er übernimmt für die betreffende SW die Pflege-Verantwortung, er testet neue Versionen und bereitet diese für die Verteilung auf die Hosts vor.

Vermieden werden soll, dass verschiedene Personen die gleiche SW pflegen und in ihren SW-Repositories ablegen.

DIS-Update-Repos

In diese Repos werden vom Hersteller bereitgestellte SW-Updates gespeichert. Dies erfolgt einmal pro Nacht per rsync.

Aus diesen Repos werden keinen SW-Pakete direkt installiert.

DIS-Update-Repos existieren pro Minor-SP-Klasse, z.B.

   .../ToSCA/SW/DIS_UPDATES/FE_18_X86
   .../ToSCA/SW/DIS_UPDATES/FE_18_x86_64
   .../ToSCA/SW/DIS_UPDATES/SL_6.5_X86
   .../ToSCA/SW/DIS_UPDATES/SL_6.5_x86_64

(Verzeichnisstruktur für Windows-Plattformen existiert, wird aber nicht genutzt da der Hersteller andere Verfahren für Softwareupdates vorgibt.)

URZ-Update-Repos

In diese Repos werden SW-Pakete aus den /URZ-Update-Repos kopiert. Vorher erfolgt eine Verifikation der Pakete durch die SW-Verantwortlichen, um zu sichern, dass durch das Einpielen der SW-Pakete keine Probleme bei der Nutzung auftreten. Die Verifikation schließt die Testung ein, wenn es sich um SW-Pakete handelt, welche Dienste auf Produktionsservern realisieren.
Als Beispiele seien httpd, mysql und php genannt.

Wenn SW-Updates einmal in diese Repos kopiert worden sind, dann erfolgt die Installation auf den betroffenen Hosts automatisch. Im Regelfall passiert das einmal pro Tag bzw. Nacht. Man kann das Update aber auch gezielt zu anderen Zeitpunkten anstoßen.

URZ-Update-Repos existieren pro Minor-SP-Klasse, z.B.

   .../ToSCA/SW/URZ_UPDATES/FE_18_X86
   .../ToSCA/SW/URZ_UPDATES/FE_18_x86_64
   .../ToSCA/SW/URZ_UPDATES/SL_6.5_X86
   .../ToSCA/SW/URZ_UPDATES/SL_6.5_x86_64
   .../ToSCA/SW/URZ_UPDATES/W7_6.1_X86
   .../ToSCA/SW/URZ_UPDATES/W7_6.1_x86_64
   .../ToSCA/SW/URZ_UPDATES/W2008_6.1_x86_64

CFENGINE-Repos

CFENGINE-Repos existieren nur für Betriebssystem-Familien (z. B. LINUX, WIN7) sowie ein zentrales Repository für globale Konfigurationsdaten und Prototypen (ALL_CFSCRIPTS).

Diese Verzeichnisstruktur enthält alle Konfigurationsdateien, welche für den Betrieb der Software cfengine erforderlich sind sowie Konfigurationsdaten zur Klassenstruktur (classes.cf).

SCRIPT-Repos

Im SCRIPT-Repository sind Skripte hinterlegt, welche den Ablauf der Systemwartung initiieren und steuern. Außerdem werden hier Werkzeuge (Skripte) zum Verwalten der Management-Infrastruktur sowie zum Verwalten der Systemplattformen und Endsysteme hinterlegt.

Die Strukturierung erfolgt auch hier wieder nach Betriebssystem-Familien, Betriebssystem-Versionen und globalen, betriebssystemunabhängigen Skripten.

LOG-Repos

Für jede Minor-SP-Klasse wird pro Host ein LOG-Repo eingerichtet, in dem bestimmte Host-spezifische Daten abgespeichert werden. Die allgemeine Struktur zeigt die Abbildung. Hierarchie der LOG-Repos Der Verzeichnis-Pfad lautet:

   .../ToSCA/LOGS/<minor-systemplattform>/<hostname>

Demzufolge ergibt sich z.B. für den Host magog im Scientific Linux 6.5 (64 Bit) das LOG-Repo

   .../ToSCA/LOGS/SL_6.5_x86_64/magog

Zu den gespeicherten Informationen gehören u.a.:

Informationen über die Hardware-Konfiguration (einschließlich Änderungs-Protokolle)
Informationen über das Betriebssystem
der aktuelle SW-Bestand
Kopien rotierter Log-Files bestimmter Betriebssystem-Komponenten
Protokolle von Cfengine-Läufen

Diese Daten werden automatisch und regelmäßig (cron-Scripte) durch entsprechende SW-Tools erzeugt und abgespeichert, es handelt sich praktisch um Selbstauskünfte des Systems. Da diese Daten im Netzwerkfilesystem liegen, sind sie zu jedem Zeitpunkt verfügbar und auswertbar, z.B. zur Untersuchung von Fehlern und für Zusammenstellung von Übersichten.

Ein Teil der im LOG-Repo gespeicherten Daten werden über den Montoring-Server dargestellt.