System Updates auf Gentoo und Funtoo

Wer Gentoo oder Funtoo im größeren Stil einsetzt, der kennt das leidliche Thema der Systemupdates. Im Gegensatz zu Binärpaket-Distributionen wie Ubuntu können sich die Systemupdates zeitlich ziemlich ziehen. Außerdem besteht ein Systemupdate leider nicht nur aus den zwei Befehlen des Repository Updates und dem Einspielen der Aktualisierungen. Unter Gentoo / Funtoo ist im Idealfall eine ganze Reihe von Updateschritten zu beachten.

Um den Updateprozess deutlich zu beschleunigen und die Updates konsistent und leicht einspielbar zu machen, empfiehlt es sich einen oder mehrere Portage Buildserver / Binhosts zu haben, die aus den im Portage Tree vorhandenen Source Paketen die gewünschten Binärpakete bauen. Im Sonderfall können immer noch einzelne Pakete auf den Satelliten Servern kompiliert und eingespielt werden.

Ein weiteres Problem bei Gentoo und Funtoo ist das Verteilen eines bereits vorkompilierten Linux Kernels, hier gibt es leider keine Boardmittel, die einem die Arbeit abnehmen. So bleibt einem nichts anderes übrig, als entweder auf jedem Host den Kernel kompilieren zu lassen, oder selber einen Workflow zum Verteilen von Kernel Binärpaketen zu etablieren.

Um das ganze jetzt in die Praxis umzusetzen, benötigt man einen Host, der die Binärpakete und Kernel vorkompiliert und über einen Webserver den anderen Hosts zur Verfügung stellt. Hierfür sind folgende Settings in der make.conf auf dem Buildserver empfohlen:

Wenn jetzt ein Paket emerged wird, wird automatisch in dem Verzeichnis „/usr/portage/packages“ eine .tbz2 Datei erstellt, die die vorkompilierte Software enthält. Das Flag –usepkg-exclude=\“*\“ führt dazu, dass in jedem Fall die Pakete kompiliert werden, auch wenn sich bereits ein vorkompiliertes Paket gleicher Versionsnummer auf dem Host befindet. Um anderen Systemen diese Dateien zur Verfügung zu stellen, installiert man einen Webserver seiner Wahl, und stellt das Verzeichnis „/usr/portage/packages“ über eine Domain oder IP-Adresse wie zum Beispiel „http://example.com/packages“ zur Verfügung.

Das ganze muss jetzt noch auf den Client Hosts eingerichtet werden, dafür konfiguriert man folgende Einstellungen in der make.conf:

Auch hier kann man Wahlweise in den EMERGE_DEFAULT_OPTS das Flag –usepkg-exclude setzen, um für bestimmte Pakete die Binärpakete zu ignorieren. Das Flag –binpkg-respect-use=y führt dazu, dass Pakete, die lokal andere USE Flags als auf dem Buildserver gesetzt haben, das Binärpaket ignoriert wird.

Nun fehlen einem noch die Skripte um alle Updateschritte mit einem Befehl durchzuführen, das erleichtert ebenfalls die Einbindung in automatisierte Updateprozesse, die per Puppet, Jennkins und anderen Tools angesteuert werden können.

Zu diesem Zweck habe ich drei kleine Skripte geschrieben, die das Einspielen von Systemupdates, das Bauen von einem neuen binären Kernel und das Einspielen des Kernels übernehmen. Zu finden sind die Skripte in meinen Github Repository. Ich verwende ausschließlich den „sys-kernel/gentoo-sources“ mit dem Setting CONFIG_LOCALVERSION=“-mfc“ und baue daraus die binären Kernel. Wenn Ihr einen anderen Kernel verwendet, müsst Ihr das Skript entsprechend anpassen. Alle Skripte verfügen über die Option „-y“, damit können diese non-interactive ausgeführt werden.

Ich empfehle vor dem Einsatz sich nochmals genau mit den Abhängigkeiten der einzelnen Pakete auf seinen Systemen auseinander zu setzen und vorher eine homogene Softwarelandschaft zu schaffen. Ansonsten droht einem die Gefahr, dass man schnell in Abhängigkeitsprobleme läuft, welche sich unter Umständen zu spät zeigen. In mittleren bis großen IT Landschaften empfiehlt es sich Preproduction- oder Staging-Systeme einzusetzen, auf denen man Systemupdates aus Binärpaketen automatisiert einspielen und testen kann.

 

TwitterGoogle+Facebook