Wer hier regelmäßig mitliest, der hat eventuell mitbekommen, dass meine 2012 entfachte und später gelegentlich wieder thematisierte Begeisterung für das Betriebssystem FreeBSD im Februar 2018 ein jähes Ende fand.

In einem selbst für mich überraschenden Anflug von Folgerichtigkeit stellte ich mit Erscheinen des letztverlinkten Artikels jede Arbeit an FreeBSD-Unterstützung für jedes meiner Programme ein und begab mich auf die Suche nach einem geeigneten Ersatz für meinen Webserver. Geplant hatte ich wenigstens die Miete neuer Hardware schon seit längerer Zeit, nur dem Wunsch nach einem Wechsel des Betriebssystems hatte ich wenigstens bis 2017 widerstanden. Aus didaktischen Gründen sei angemerkt, dass die beschriebenen Ereignisse nicht der Grund, sondern nur der Auslöser für meine Abkehr waren. Über Monate hinweg hatte FreeBSD bei mir immer mal wieder Probleme beim Update verursacht. Das mag zum Teil mein Verschulden sein, zum Teil liegt es aber auch daran, dass am Portsystem von FreeBSD quasi pausenlos gearbeitet wird und es manchmal scheinbar von der Tagesform oder der Mondphase abhängt, ob ein bestimmter Port mit einer bestimmten Konfiguration kompiliert und gestartet werden kann oder nicht. Das Einführen von Flavors im Vorjahr hat die Situation diesbezüglich nicht unbedingt verbessert. FreeBSD als stabiles und zuverlässiges Gesamtsystem bleibt interessant, falls man mit der Standardkonfiguration zufrieden ist und zum Beispiel nur Binärpakete nutzt, was vermutlich der Regelfall ist. Je mehr man aber anpassen möchte, desto wahrscheinlicher kommt es zu Problemen. Ein stetiges Beispiel für kleine Änderungen, die großen Ärger mit sich bringen können, ist LibreSSL, das man unter FreeBSD zwar statt OpenSSL automatisch in alle Ports hineinkompilieren kann (hierfür DEFAULT_VERSIONS+= ssl=libressl in der Datei /etc/make.conf eintragen), aber dann fliegt einem eher früher als später irgendwas um die Ohren.

Auf Laptops hatte ich schon vor Jahren lieber zu OpenBSD, das einfach funktionierte, oder anderen Konkurrenzsystemen gegriffen und habe derzeit also keinen solchen mit FreeBSD mehr im Einsatz. Zwar stellte mich FreeBSD als Nutzer und Entwickler nicht mehr zufrieden, aber die dort geparkten Dienste wollen ja durchaus immer noch weiter betrieben werden. Die offensichtliche Alternative OpenBSD war vorerst nicht ganz oben auf meiner Liste: Zwar treibt sie einen anderen meiner Server recht zuverlässig an, aber ich bin inzwischen, fürchte ich, ein wenig faul geworden und würde die vergleichsweise arbeitsintensiven halbjährlichen Updates ungern mehr als einmal machen müssen.

Ärger mit der Libelle

Das erste Ziel war also wieder einmal DragonFly BSD, ein Fork einer alten FreeBSD-Version mit enormen Verbesserungen des Dateisystems, jedoch auch einer weitgehenden Kompatibilität mit FreeBSD, was die Ports angeht. DragonFly BSD funktionierte bei der Ersteinrichtung recht gut, jedoch bemerkte ich schnell, dass auch eine Kehrseite von FreeBSD kompatibel mit ihm ist: Der Port von SBCL, einer durchaus nicht unwichtigen Komponente, funktionierte nicht wie erwartet. Zwar konnte ich dieses Problem mit Ravenports, einem alternativen Portsystem eines DragonFly-BSD-Entwicklers, augenscheinlich lösen, aber in Summe war der Weg dorthin mir deutlich zu steinig.

Weil ich den Server, wie bereits geschrieben, produktiv einsetzen wollte, nutzte ich diese Gelegenheit auch nicht, um wilde Experimente zu wagen; 9front, die GNU Hurd oder gar das skurrile Frickelsystem Linux kamen hier also nicht in Frage. (Dass ich mich gerade aus anderen Gründen mit dem 9front-Texteditor Acme beschäftige, ist vielleicht eines Tages eine längere Abhandlung wert.) Das soll natürlich nicht bedeuten, dass mich Popularität bei der Auswahl interessierte, nur vernünftig laufen sollte es schon. Und welches System hat seit Jahrzehnten den Ruf, so vernünftig zu laufen, dass es sogar konservative Unternehmen für viel Geld benutzen wollen? Na, Solaris natürlich!

Solawas?

Solaris – die Älteren erinnern sich vielleicht – wurde Anfang der 1980er unter Mitwirkung von Bill Joy, dem Entwickler von ex, vi, Distributor von BSD UNIX und später leider auch Mitschuldigen an der Existenz von Java, als SunOS erstmals veröffentlicht, seit der Umstellung von der BSD- auf die AT&T gehörende UNIX-System-V-Codebasis etwa zehn Jahre später trägt es seinen heutigen Namen. Von 2008 bis 2010 stand ein Großteil des Systems als OpenSolaris frei zur Verfügung, womit dieses das erste freie System-V-UNIX war, denn die ebenfalls Anfang der 1990er entstandenen freien BSD-Derivate durften keinen AT&T‑lizenzierten Code mehr verwenden, ohne Lizenzgebühren zu zahlen.

Als der US-amerikanische Datenbank- und Heuschreckenkonzern Oracle, der eigentlich nur die Konkurrenz MySQL unter Kontrolle bekommen wollte, im Jahr 2010 aus Versehen auch den ganzen Rest von Sun Microsystems mitkaufte, gehörte das Brandroden des Portfolios zu seinen nächsten Schritten, auch Solaris und die hervorragenden SPARC-Prozessoren mussten seitdem Federn lassen. OpenSolaris wurde nach kurzer Zeit eingestellt und die bis dahin erhaltenen Codebeiträge von anderen Entwicklern in das wiederum kommerzielle Solaris 11 integriert. Das machte viele Menschen sehr ungehalten.

Der kurzen Zeit, in der es ein freies Solaris gab, ist es aber zu verdanken, dass bald unabhängige Nachfolgeprojekte auf Grundlage des OpenSolaris-Forks illumos entstanden waren, die oft von enttäuschten ehemaligen Sun-Entwicklern vorangetrieben wurden. Von den bis dahin entstandenen technischen Innovationen von Solaris, darunter das Dateisystem ZFS, das Initsystem Service Management Facility (SMF), DTrace und die Containertechnik „Zones“ – mit etlichen Jahren Verspätung und weniger Funktionen in der Linuxwelt als „Docker“ nachgebaut – profitierten auch diese neuen Projekte, allen voran OpenIndiana, das unter den illumos-Distributionen wegen seines vergleichsweise einfach zu installierenden Desktops die bekannteste ist.

Distributionsdurcheinander

An die Existenz dieser Systeme hatte mich bereits im September 2017 der ehemalige Piratenaktivist Ali Utlu erinnert, was mir schon damals ein Auslöser dafür war, mich mit den gängigen Varianten zu befassen. OpenIndiana haftete der Ruf an, nicht unbedingt das kompakteste und schnellste System zu sein, im Web wurde ich jedoch auf einen Blogartikel aufmerksam, der Tribblix, eine auf einen vergleichsweise schlichten Desktop ausgerichtete Distribution, deren anscheinend einziger Entwickler bewusst zu konservativen Lösungen wie den in älteren Solarisversionen verwendeten SVR4-Paketen neigt, empfahl. Auf YouTube wirkte das System auch nicht unsympathisch, aber mein als Testsystem genutzter Laptop bekam keine WLAN-Verbindung – die BSDs und illumos, die sich die Hardwareunterstützung gern einmal teilen, unterstützten meinen Adapter noch nicht. Damit war das Kapitel illumos für mich erst einmal wieder beendet.

Der neue Webserver allerdings, nahm ich an, würde dieses Problem nicht haben, denn Server sind selten kabellos angebunden. Die illumos-Welt war unter der wesentlichen Federführung des inzwischen zu Samsung gehörenden Unternehmens Joyent, das seinerseits die Distribution SmartOS in seinem Portfolio führt, nicht stehen geblieben, beinahe regelmäßige Neuigkeiten blieben mir nicht verborgen. Ich entschied mich dafür, es einmal mit dem auf den Serverbetrieb spezialisierten OmniOS „Community Edition“ zu versuchen, das im Sommer 2017 als Nachfolgesystem des eingestellten OmniOS von OmniTI vorgestellt worden war und dessen Entwicklung von einer eigens gegründeten Schweizer Stiftung finanziert wird. Mal sehen, wie lange das gut geht.

OmniOS ja, nein?

Das ständig im Fluss befindliche OmniOS, das (wohl auch aus rechtlichen Gründen) manche Anwendungen aus FreeBSD übernommen hat, darunter inzwischen auch den Bootloader sowie Teile des Userlands, ist trotzdem von Anfang an als ein Betriebssystem mit ganz eigenen Wurzeln zu erkennen. Das beginnt beim Installationsprogramm, das bis gestern „Kayak“ hieß und mit seinem Frage-Antwort-Konzept der Installation von OpenBSD sehr ähnelte, jedoch waren alle möglichen Antworten bereits vorgegeben und man wählte einfach die Zahl aus, die zu der jeweils passenden Antwort gehört. Das galt auch für Ja-Nein-Fragen, was nur zu Beginn ein Umdenken erforderte. – Mit der vor wenigen Stunden veröffentlichten OmniOS-Version r151026 wurde dieses Installationsprogramm durch eines ersetzt, das sich wieder mit Menüs bedienen lässt, jedoch kann, wer (wie ich) bunte Textwüsten nur mäßig interessant findet, per Druck auf „T“ bei Beginn der Installation die vorherige Version weiterhin benutzen.

Nach der ansonsten brauchbar dokumentierten Installation hat man ein System vor sich, das möglicherweise funktioniert. Schnell merkt man aber trotz der Standardshell ksh93, dass in anderen Systemen erarbeitetes Wissen hier aufgrund des immer noch hauptsächlich von Sun entworfenen Userlands kaum anwendbar ist:

$ ping tuxproject.de
tuxproject.de is alive

Immerhin: Das Netzwerk funktioniert anscheinend, auch wenn die Meldung, die dies signalisiert, anders aussieht als gewohnt. Ich gebe gern zu, dass mir diese Darstellung sogar noch ein bisschen besser gefällt als die sonst übliche; ich persönlich benutze ping in der Regel tatsächlich nur, um die Erreichbarkeit von irgendwelchen Servern (selten: die Verfügbarkeit der Internetverbindung) zu ermitteln. Apropos anders: Bei der Installation wurde ich darauf hingewiesen, dass sudo hinter pfexec nur eine untergeordnete Rolle spielt und ob ich mit meinem ebendort eingerichteten Benutzerkonto trotzdem sudo verwenden möchte. Ich habe das zwar bejaht, aber werde im Folgenden trotzdem pfexec benutzen. Es fühlt sich viel richtiger an.

Paketdienste und mehr

Zwar kommt OmniOS ab Werk mit einer nennenswerten Sammlung an nicht völlig uninteressanter Software, aber wenn etwas fehlt, dann ist es nicht gerade offensichtlich, woher man es nehmen könnte. Die hauseigene Paketverwaltung pkg, die FreeBSDs pkgng (inzwischen ebenfalls als pkg bekannt) augenscheinlich ähnelt, aber wesentlich gesprächiger ist und auch mehr Dinge zu tun scheint, die sich mir noch nicht in jedem Fall ganz erschlossen haben, besticht nicht gerade durch ein reichhaltiges Angebot:

$ pfexec pkg search nginx
$

Die offiziell empfohlene Vorgehensweise ist es, die Paketverzeichnisse von Freiwilligen einzubinden. Ich stand nun vor der schwierigen Entscheidung, viele zweifelhafte Quellen in mein normales pkg einzubinden oder die offensichtliche Alternative, den von Joyent (und damit einem Unternehmen, das es sich nicht leisten kann, Murks zu entwickeln) bereitgestellten Fork von pkgsrc, zu nutzen. Ich entschied mich für letztere Variante, wohl wissend, dass ich dann eigentlich auch bei DragonFly BSD hätte bleiben können. Tja – zu spät!

pkgsrc funktioniert wie aus anderen Systemen bekannt:

$ pfexec pkgin search nginx
nginx-1.13.10 =      Lightweight HTTP server and mail proxy server
nginx-1.12.2nb1 >    Lightweight HTTP server and mail proxy server

=: package is installed and up-to-date
: package is installed but newer version is available
>: installed package has a greater version than available package

Über „Bootstrapping“ hätte ich hier auch die Möglichkeit, stattdessen Ports selbst zu kompilieren, aber in diese Tiefen wollte ich noch nicht wieder vordringen. Das Portsystem von FreeBSD liegt mir immer noch schwer im Magen.

Zu Diensten!

Bei der Installation von Paketen wie nginx weist pkgin auch unter OmniOS gelegentlich darauf hin, wie man – falls vorhanden – ihren Systemdienst in SMF integriert. Grundsätzlich scheint mir dieser supervisor, wenngleich nicht unbedingt der schnellste, doch ein ziemlich durchdachter zu sein: Per svcadm enable/disable [Dienst] startet man einen Dienst oder hält ihn an, wenn dabei etwas schiefläuft und er zum Beispiel aufgrund von Konfigurationsfehlern nicht wieder startet, zeigt svcs ihn im „Wartungsmodus“ (maintenance) an. Sind die Fehler gefunden und behoben, setzt svcadm clear [Dienst] seine Arbeit fort. Die Reihenfolge der Parameter unterscheidet sich hier von der aus FreeBSD gewohnten (service [Dienst] [Befehl]), aber dieser Umstand macht sich beim Vertippen in der Regel von allein bemerkbar.

Als ich nach einer Weile herausfinden wollte, wie ressourcenhungrig mein neuer Server wohl sein mag, fiel mir abermals eine Besonderheit von Solaris-Systemen sozusagen auf die Füße: top existiert hier nur als externes Paket. Eine Tabelle im Wiki von SmartOS ließ mich herausfinden, dass es unter illumos stattdessen eine ganze Horde an Befehlen gibt, die auf „stat“ enden und prinzipiell alles statistisch abbilden können, was man bei der Arbeit mit dem System so braucht. top am nächsten kommt hier wahrscheinlich prstat, was für „Prozessstatistik“ zu stehen scheint.

Virtualisier mich am Arsch

Ich erwähnte oben „Zones“, also illumos‘ eingebautes Docker-Vorbild. Diese können nicht nur für den Betrieb von virtuellen Maschinen genutzt werden, sondern sind zusammen mit den Containerfunktionen von ZFS so tief in das System integriert, dass auch das Dateisystem selbst in der Standardausführung völlig anders funktioniert als etwa ZFS unter FreeBSD. Das beginnt bereits beim Update des Systems: Die vorherige Version des Betriebssystems wird in eine neue Bootumgebung kopiert, die man im Fehlerfall dann wieder starten kann. Diese Bootumgebung umfasst alles unterhalb des Wurzelverzeichnisses /, was keinen eigenen Bereich im ZFS reserviert bekommen hat. Auch das hat mich überrascht, denn nach meinem ersten OmniOS-Upgrade auf die Version r151024 war plötzlich mein /opt-Verzeichnis verschwunden und mit ihm pkgsrc mit allen bis dahin installierten Paketen.

Das Anlegen eines Verzeichnisses, das auch eine neue Bootumgebung übersteht, funktioniert direkt auf Dateisystemebene. Wenn der bei der Installation angelegte ZFS-Pool (wie standardmäßig) rpool heißt, geht das so:

$ pfexec zfs create rpool/opt
$ pfexec zfs set mountpoint=/opt rpool/opt

Eine Überprüfung via zfs list sollte /opt jetzt außerhalb der „ROOT“ genannten Bootumgebung anzeigen. Ich empfehle außerdem, die Standardbelegung des /home-Verzeichnisses nicht anzurühren, denn auch dieses funktioniert, falls nicht geändert, nicht so wie man es erwarten sollte.

Unter den Diensten, die ein jungfräuliches OmniOS zu starten pflegt, befindet sich auch automount, das über die Datei /etc/auto_master gesteuert wird und von dort aus über die Datei /etc/auto_home das Benutzerverzeichnis automatisch aus dem ZFS-Pool mountet, standardmäßig anscheinend aus rpool/export/home/. Das ist praktisch, wenn man weiß, dass es da ist, und verwirrend, wenn man es nicht weiß. Ich habe mich dazu entschieden, lieber auf die althergebrachte Methode zurückzugreifen, die auf nicht virtualisierten Servern keinen offensichtlichen Nachteil mit sich bringt:

$ pfexec svcadm disable automount
$ pfexec mkdir /home/benutzer
$ pfexec chown -R benutzer /home/benutzer

Ein eigener ZFS-Bereich wurde wie oben beschrieben ebenfalls reserviert. Damit war der Spuk vorbei. Die vor Veröffentlichung dieses Artikels durchgeführte Aktualisierung des Systems dauerte ungefähr drei Minuten und nach dem fälligen Neustart war alles – einschließlich der installierten Dienste – noch an seinem Platz. Es ist etwas schade, dass das anderen Systemen manchmal so schwer fällt.

Frühjahrsputz

Als ich den alten Server 2010 erstmals eingerichtet habe, habe ich auf eine Trennung zwischen einzelnen Diensten nur sehr wenig geachtet: Sehr wenige Domains teilen sich sehr viele Dienste. Der alte Server ist also, um es angemessen formlos auszudrücken, scheiße konfiguriert. Der Wechsel zu einer völlig neuen Umgebung wird also selbst unter der Annahme, dass OmniOS als System nicht noch acht Jahre überleben wird, zumindest den Vorteil haben, dass ich jetzt endlich eine vernünftige Gelegenheit habe, eine Inventur vorzunehmen und das Vorhandene unter Zuhilfenahme von Subdomains etwas sinnvoller aufzuteilen als bisher.

Für einen Umzug einzelner Dienste, deren Domain nicht einfach geändert werden kann, ohne mehr Arbeit nach sich zu ziehen, scheint HAProxy sich zu eignen. Ich werde sehen, ob ich es bereuen werde, diesen Schritt gegangen zu sein.

Bislang sieht es nicht so aus.