Die Mühen der Praxis

Soweit die Theorie. In der Praxis begegnet mir oft das Problem unterschiedlicher »USE« -Flags. Baut ein Server ohne grafische Umgebung die Pakete, passen diese nicht zu einer Desktopmaschine, da die Buildmaschine ohne die »USE« -Flags »X« sowie »gtk« oder »kde« gearbeitet hat. Das Problem trifft nicht nur Desktop-Anwendungen, sondern auch »gcc« oder »openssh« : Erstelle ich die Pakete mit dem »USE« -Flag und installiere sie auf einem Server, holt der sich das komplette X-Window und GTK+ herein.

Das gleiche Problem ergibt sich bei unterschiedlichen CPUs. Gegen solche ungewollten Abhängigkeiten hilft die Option »--binpkg-respect-use y« , die prüft, ob die »USE« -Flags des Binärsystems zum lokalen passen.

Ein Weg, mit Gentoo-Bordmitteln verteilt im Netz Binärpakete zu bauen (Abbildung 1) und sie für mehrere Clients bereitzustellen, sieht so aus: Das »/usr/portage« -Verzeichnis wird auf einem Server synchron gehalten und per NFS read-only bereitgestellt. Pro CPU-Typ gibt es einen Buildhost, der Binärpakete erstellt und bereitstellt. Letzteres erfolgt in einem lokalen Verzeichnis, das nicht im read-only gemounteten »/usr/portage« liegt. Per Webserver stellt diese Maschine das Package-Verzeichnis bereit. Gibt es mehrere verschiedene »USE« -Flag-Typen (Desktops, Webserver), machen diese das Gleiche pro CPU-Typ.

© © testfight, photocase.comAbbildung 1: Mit Gentoo lassen sich Binärpakete bauen.

Alle weiteren Hosts eines CPU-Typs haben in der »PORTAGE_BINHOST« -Variablen die URL-Liste der Buildhosts mit Leerzeichen getrennt und fahren Updates oder Installs immer mit den Optionen »-kg --binpkg-respect-use y« . Das führt zum Abklappern aller URLs in der Variablen nach passenden Paketen. Nur wenn keines passt, wird selber kompiliert.

Sind bei den CPU-Typen altersschwache dabei, kann ein schneller Host das Bauen übernehmen, indem er die Pakete mittels »ebuild /usr/portage/...buildfile« erzeugt und ich die Variablen »CHOST,CXXHOST« und »USE« passend zum schwächeren Zielsystem setze. Auch »PKGDIR« muss auf ein eigenes Verzeichnis zeigen, die URL in der Variablen »PORTAGE_BINHOST« passe ich auf dem schwächeren System an. Die Lizenzen einiger Pakete verbieten die binäre Bereitstellung. Diese Pakete verwenden das Flag »bindist« , das der Admin aktivieren sollte.

Das gezeigte effizienzsteigernde Vorgehen entbindet den Admin nicht davon, auf allen verwalteten Systemen regelmäßig Updates durchzuführen und danach mittels »etc-update« die Konfigurationsdateien zu aktualisieren. Werkzeuge wie Cluster-SSH helfen dabei, solche wiederkehrenden Arbeiten zu optimieren. Grundlegende Pakete wie die Glibc bedingen, dass nach der Installation andere Dienste (etwa »vixie-cron« ) neu zu starten sind. Zudem lasse ich ab und zu das Tool Eclean aus dem Gentoolkit laufen, um veraltete Pakete mit »eclean packages« auf den Buildhosts zu löschen.

Konstantin Agouros

iLDAP-Sicherung mit Versionierung

Ein Open-LDAP-Verzeichnis lässt sich mit dem Befehl »slapcat« sehr einfach sichern. Ein täglicher Cronjob erledigt das bei mir automatisch. Möchte ich aber Änderungen im Verzeichnis nachvollziehen können, wird es schon etwas komplizierter. Zwar lassen sich die einzelnen Sicherungen miteinander vergleichen, aber das ist Aufgabe eines Versionierungssystems. Folgender Cronjob implementiert dies mit Hilfe von »rcs« :

45 23 * * * root umask 077 && cd/var/backups && /usr/sbin/slapcat>dump.ldif && (rcsdiff -q dump.ldif;ci -q -l -d -mcron -t-cron dump.ldif)

Der Eintrag »umask« stellt sicher, dass die später angelegte Datei »dump.ldif« nur für Root zugänglich ist. Der Aufruf von »rcsdiff« ist optional und führt dazu, dass ich Änderungen per Mail zugestellt bekomme. Das »ci« schließlich sichert die neue Revision.

Thilo Uttendorfer