From RootForum Community » Wiki

Einleitung

Bei der Verwaltung von Unix-Systemen dreht sich (fast) alles um Konfigurationsdateien. Mit ihnen wird das Verhalten des Betriebssystems und nahezu aller darauf laufenden Dienste und Anwendungen gesteuert. Wer mehr als nur ein System administriert, kennt die lästige Aufgabe, ähnlich geartete Änderungen auf mehreren Systemen einpflegen zu müssen – und dabei den Überblick nicht zu verlieren, auf welchem System welche Konfiguration hinterlegt und aktiv ist. Noch gemeiner sind Umzüge; in Zeiten virtualisierter Systeme ein ständiger Begleiter, der nach Pflege und Aufmerksamkeit für die sorgsam gehegten Konfigurationsdateien schreit.

Konfigurationen müssen geklont und nur in Details angepasst werden, gleiche Änderungen müssen in viele Systemkonfigurationen hinein-„gemerged“ werden, bei Fehlern muss ein Roll-Back auf den alten Stand erfolgen, auch wenn mehrere Kollegen an den Dateien schrauben, muss die Konsistenz gewährleistet bleiben – doch halt, solche Begriffe kennen wir doch aus der Software-Entwicklung. Dort haben Entwickler mit ihrem Quellcode ähnliche Probleme zu bewältigen. Anders als in der Systemadministration ist es dort jedoch selbstverständlich, ausgefeilte Werkzeuge zu diesem Zweck einzusetzen: Die Rede ist von sogenannten VCS[1]- oder SCM[2]-Systemen.

In diesem Artikel wird dargelegt, wie man sich die Fähigkeiten dieser Werkzeuge auch in der Verwaltung von System- und sonstigen Konfigurationsdateien zu eigen machen kann, und wie ein entsprechendes Setup in der Praxis aussehen könnte.

Anforderungen an ein Verwaltungssystem

Ziel eines Setups mit verwalteter Konfiguration soll es sein, jederzeit einen genauen Überblick darüber zu haben, wie die verschiedenen Systeme und Dienste konfiguriert sind. Außerdem soll auch bei mehreren Administratoren stets gewährleistet sein, dass jeder Zugriff auf den aktuellen Stand hat und Änderungen nicht zu Konflikten mit der Arbeit eines Kollegen führen. Dieser Prozess soll personenunabhängig gewährleistet sein, also ohne zentralen Maintainer oder Konfigurations-Wächter.

Aus diesen Anforderungen leiten sich folgende Problemstellungen ab:

• Versionssichere Speicherung der Konfigurationsdateien
• Konfliktresistente parallele Bearbeitung von Konfigurationsdateien
• Verteilung der Konfigurationsdateien auf die Zielsysteme

Die ersten beiden Punkte können durch ein zentrales Versionsverwaltungssystem wie CVS oder Subversion gewährleistet werden. Ein dezentrales SCM wie git oder Mercurial hingegen sind für dieses Szenario weniger geeignet, da insbesondere der zweite Punkt nur gewährleistet werden könnte, wenn ein zentraler Maintainer die Änderungen der Kollegen in Form von Patches in das Master-Repository einarbeitet, auf das die anderen keinen Zugriff haben. Der dritte Punkt kann nur teilweise von einem SCM-Client geleistet werden; hier müssen noch zusätzliche Werkzeuge ins Spiel gebracht werden.

Aufbau eines Verwaltungssystems

Ich habe mich in diesem Setup für Subversion als zentrale Versionsverwaltungskomponente entschieden. Insbesondere bei der Verteilung der Konfigurationsdateien punktet Subversion: der Transfer kann über mehrere Protokolle erfolgen (HTTP(S), svn und SSH). So kommt man an fast jeder Firewall vorbei. Außerdem bieten HTTPS und SSH einen sehr guten Schutz bei der Übertragung der Konfigurationsdateien vor Manipulation durch dritte.

Für jedes System wird ein eigenes Repository angelegt, in dem die Konfigurationsdateien in der klassischen trunk – branches – tags Struktur abgelegt werden. Administratoren erhalten auf diesem Repository Commit-Rechte. Falls erforderlich, kann man die Schreibberechtigung für das tags-Verzeichnis noch weiter einschränken. Für die Übertragung der Dateien existiert ein weiterer User, der jedoch lediglich Leserechte auf dem tags-Verzeichnis besitzt. So wird gewährleistet, dass nur freigegebene Konfigurationsstände (genau dazu dient das tags-Verzeichnis) auf das Zielsystem übertragen werden.

Für das Deployment der Konfigurationsdateien auf dem Zielsystem kommt das Werkzeug cdeploy aus der root-tools Werkzeugsammlung zum Einsatz.

Einrichten eines Subversion-Servers

Da meine Server in verschiedenen Rechenzentren verteilt stehen und sämtliche Kommunikation über das Internet erfolgt, ist eine sichere Datenübertragung das A und O eines solchen Setups. Daher wird hier die Einrichtung von Subversion via WebDAV mit SSL-Verschlüsselung beschrieben. Ich verwende zu diesem Zweck einen kleinen VServer, der mit CentOS[3] 5.3 bestückt ist.

Installation der benötigten Pakete

So werden die benötigten Pakete installiert:

yum install mod_dav_svn mod_ssl subversion

Repository-Infrastruktur einrichten

mkdir /var/svn
mkdir /var/svn/{repos,access,skel}
mkdir /var/svn/skel/{trunk,branches,skel}
chown -R apache:apache /var/svn/*
chmod 0700 /var/svn/access
chmod -R 0750 /var/svn/{repos,skel}
touch /var/svn/access/{svn-acl,svn-users}
chown apache:apache /var/svn/access/*
chmod 0400 /var/svn/access/*

Ein Admin-User wird beispielhaft gleich mit angelegt:

htpasswd -m /var/svn/access/svn-users admin

Apache konfigurieren

cat >> /etc/httpd/conf.d/subversion.conf << EOF
<Location /svn>
	DAV svn
	SVNParentPath /var/svn/repos
 
	AuthzSVNAccessFile /var/svn/access/svn-acl
 
	Satisfy Any
	Require valid-user
 
	AuthType Basic
	AuthName "My Configuration Service"
	AuthUserFile /var/svn/access/svn-users
</Location>
EOF
 
service httpd start
chkconfig httpd on

Natürlich können auch noch andere Dinge angepasst werden, etwa die SSL-Konfiguration, Logging, etc – allerdings läuft der mit dem o. a. yum-Befehl installierte Apache out-of-the-box, so dass diese Änderungen falls gewünscht Ihrer eigenen Phantasie überlassen bleiben.

Ein Beispiel-Repository anlegen

Das Repository ist für das fiktive Beispiel-System namens fluppy gedacht.

svnadmin create /var/svn/repos/fluppy
svn import /var/svn/skel file:///var/svn/repos/fluppy -m "Initial Import"
chown -R apache:apache /var/svn/repos/fluppy
chmod -R o-rwx /var/svn/repos/fluppy

Nun bedarf es noch eines Users, unter dem der Ziel-Host lesend auf das Repository zugreifen darf. Der Einfachheit halber heißt er genauso wie das zu verwaltende System:

htpasswd -m /var/svn/access/svn-users fluppy

Zu guter letzt müssen nun noch die Regeln für den Zugriff auf das Repository festgelegt werden. Dazu werden folgende ACLs eingetragen:

cat >> /var/svn/access/svn-acl << EOF
[fluppy:/]
admin = rw
 
[fluppy:/tags]
fluppy = r
EOF

Das war es eigentlich auch schon; spätestens nach einem reload oder restart des Apache sollten Sie nun über Ihren Browser mit dem admin-User auf das Repository unter der URL https://myhost.mydomain.tld/svn/fluppy zugreifen können.

Einrichten des Zielsystems

Nun steht zwar mit dem Subversion-Server das Herz des geplanten Setups bereits zur Verfügung – noch interessiert den zu verwaltenden Server aber reichlich wenig, was mit diesem Repository geschieht. Dies gilt es nun zu ändern.

Benötigte Software installieren

Installieren Sie Subversion über das Paketverwaltungssystem ihres Betriebssystems. Achten Sie darauf, dass der Subversion-Client mit WebDAV-Unterstützung kompiliert wurde (benötigt neon[4] als Abhängigkeit) – oder wird, falls sie eine Source-basierte Paketverwaltung wie Gentoo Portage oder FreeBSD Ports einsetzen.

Darüber hinaus benötigen Sie das Werkzeug cdeploy. Unter FreeBSD kann die Installation aus den Ports erfolgen (sysutils/cdeploy). Auf den meisten anderen Betriebssystemen heißt es jedoch: manuell installieren. Da der Download von den Sourceforge-Servern von der Kommandozeile aus recht beschwerlich ist, habe ich das Quellarchiv an einer leichter zugänglichen Stelle abgelegt:

su -
cd ~
 
wget http://files.my-universe.com/mirror/root-tools/cdeploy-0.2.1.tar.bz2
 
tar -xjvf cdeploy-0.2.1.tar.bz2
cd cdeploy-0.2.1
make install

Repository-Zugang einrichten

cd ~
svn co --username fluppy https://myhost.mydomain.tld/svn/fluppy/tags configuration

Arbeiten mit dem Versionsverwaltungssystem

Nun ist eigentlich alles vorbereitet. Jetzt gilt es nur noch, sich mit der Benutzung des Systems vertraut zu machen.

Eine Datei unter Versionsverwaltung stellen

Dazu muss vorübergehend mit dem Admin-Zugang vom Server aus auf das Repository zugegriffen werden:

cd ~
svn co --username admin https://myhost.mydomain.tld/svn/fluppy/trunk confwork

Als Beispiel wird hier demonstriert, wie man die Datei /etc/fstab unter Versionsverwaltung stellt. Im Repository müssen die Dateien in exakt derselben Struktur abgelegt sein wie im „richtigen“ System, damit sie später problemlos deployed werden können.

cd ~/confwork
svn mkdir etc
cp /etc/fstab etc/
svn add etc/fstab
svn ci -m "etc/fstab hinzugefügt"

Auf Ihrem Arbeitsplatzrechner können Sie nun das Repository ebenfalls auschecken (oder updaten, falls Sie es bereits ausgecheckt haben) und die hinzugefügten Konfigurationsdateien bearbeiten.

Ein Set für das Deployment vorbereiten

Wenn Sie im trunk Ihres Repositories einen Stand erreicht haben, den Sie auf dem verwalteten System scharfschalten möchten, müssen Sie zunächst den Stand in einem tag einfrieren. Dazu ist es am einfachsten, das komplette Repository auszuchecken. Dieser Schritt sollte immer auf Ihrem lokalen Arbeitsplatzrechner durchgeführt werden (zur Not geht auch der Server, aber ich rate davon ab, damit es nicht zu Verwirrungen kommt).

cd ~
mkdir conf
cd conf
svn co --username admin https://myhost.mydomain.tld/svn/fluppy fluppy
cd ~/conf/fluppy
svn cp trunk tags/fluppy-1.0
svn ci -m "Konfigurationsversion 1.0 erstellt"

Deployment eines Sets

Die folgenden Schritte müssen logischerweise wieder auf dem Zielsystem ausgeführt werden.

cd ~/configuration
svn update
cd fluppy-1.0
 
# testen, ob alles zufriedenstellend aussieht
cdeploy -S
 
# falls keine fail-Meldungen vorliegen:
cdeploy

cdeploy ersetzt die Konfigurationsdateien im System mit denen aus dem Repository. Es kümmert sich dabei automatisch darum, dass Owner und Berechtigungen der originalen Konfigurationsdateien übernommen werden. Außerdem erstellt es unter ~/.cdeploy/<datum>/ ein Backup aller ersetzten Dateien. Das Backup-Verzeichnis ist dabei so aufgebaut, dass ein erneuter Aufruf von cdeploy innerhalb des Backup-Verzeichnisses die gesicherten Versionen wieder herstellt. Unter FreeBSD prüft cdeploy übrigens sogar automatisch, ob nach dem Deployment einer Konfigurationsdatei cap_mkdb für diese Datei aufgerufen werden muss.

Alternatives Repository-Layout

Das vorgestellte Layout hat sich als praktisch erwiesen, wenn viele unterschiedliche Systeme verwaltet werden müssen. Sollen jedoch viele gleichartige Systeme (wie z. B. die Nodes eines Webserver-Clusters) verwaltet werden, bei denen nur geringfügige Unterschiede in der Konfiguration bestehen, ergibt sich ein gravierender Nachteil: Durch die Aufteilung auf ein Repository je Host ist es recht mühsam, Massenänderungen über alle Systeme an der Konfiguration vorzunehmen.

Für diesen Fall ist es günstiger, in trunk ein Grundgerüst der Konfiguration bereitzustellen, die dann in branches für jeden Host ausgeprägt wird. Änderungen in trunk lassen sich verhältnismäßig leicht und oft ohne allzu viel Interaktion in die einzelnen Branches mergen, aus denen dann die Tags für das Deployment erstellt werden können. Natürlich gäbe es noch eine Vielzahl weiterer Möglichkeiten, da die Aufteilung eines Repository in trunk, tags und branches lediglich eine Konvention darstellt und keine Vorgabe von Subversion ist.

Troubeshooting

• Wenn Subversion einmal nicht wie erwartet arbeitet, sollte man sich zunächst vergewissern, dass man den Befehl auch korrekt abgesetzt hat. Bei korrekt gesetzter Locale liefert svn help <Befehl> eine ausführliche Hilfe in der eingestellten Sprache.
• Wenn die Online-Hilfe nicht mehr weiterreicht, gibt es mit Version Control with Subversion ein gutes, kostenlos nutzbares Nachschlagewerk.
• Sollte cdeploy -S für einige Dateien failed liefern, so kann man die Ursache hierfür sehen, wenn man cdeploy im Debug-Modus startet: cdeploy -S -l DEBUG verrät meist recht eindeutig, wo das Problem liegt (meistens fehlende Berechtigungen o. ä.)

Und zu guter letzt: wenn Doku und Debug-Ausgaben nicht mehr weiterhelfen, tut es vielleicht ein Posting im RootForum…