Nerdkrams
Ein Monat mit OmniOS: Andere sind schon mit BSD überfordert.

Wer hier regel­mä­ßig mit­liest, der hat even­tu­ell mit­be­kom­men, dass mei­ne 2012 ent­fach­te und spä­ter gele­gent­lich wie­der the­ma­ti­sier­te Begeisterung für das Betriebssystem FreeBSD im Februar 2018 ein jähes Ende fand.

In einem selbst für mich über­ra­schen­den Anflug von Folgerichtigkeit stell­te ich mit Erscheinen des letzt­ver­link­ten Artikels jede Arbeit an FreeBSD-Unterstützung für jedes mei­ner Programme ein und begab mich auf die Suche nach einem geeig­ne­ten Ersatz für mei­nen Webserver. Geplant hat­te ich wenig­stens die Miete neu­er Hardware schon seit län­ge­rer Zeit, nur dem Wunsch nach einem Wechsel des Betriebssystems hat­te ich wenig­stens bis 2017 wider­stan­den. Aus didak­ti­schen Gründen sei ange­merkt, dass die beschrie­be­nen Ereignisse nicht der Grund, son­dern nur der Auslöser für mei­ne Abkehr waren. Über Monate hin­weg hat­te FreeBSD bei mir immer mal wie­der Probleme beim Update ver­ur­sacht. Das mag zum Teil mein Verschulden sein, zum Teil liegt es aber auch dar­an, dass am Portsystem von FreeBSD qua­si pau­sen­los gear­bei­tet wird und es manch­mal schein­bar von der Tagesform oder der Mondphase abhängt, ob ein bestimm­ter Port mit einer bestimm­ten Konfiguration kom­pi­liert und gestar­tet wer­den kann oder nicht. Das Einführen von Flavors im Vorjahr hat die Situation dies­be­züg­lich nicht unbe­dingt ver­bes­sert. FreeBSD als sta­bi­les und zuver­läs­si­ges Gesamtsystem bleibt inter­es­sant, falls man mit der Standardkonfiguration zufrie­den ist und zum Beispiel nur Binärpakete nutzt, was ver­mut­lich der Regelfall ist. Je mehr man aber anpas­sen möch­te, desto wahr­schein­li­cher kommt es zu Problemen. Ein ste­ti­ges Beispiel für klei­ne Änderungen, die gro­ßen Ärger mit sich brin­gen kön­nen, ist LibreSSL, das man unter FreeBSD zwar statt OpenSSL auto­ma­tisch in alle Ports hin­ein­kom­pi­lie­ren kann (hier­für DEFAULT_VERSIONS+= ssl=libressl in der Datei /etc/make.conf ein­tra­gen), aber dann fliegt einem eher frü­her als spä­ter irgend­was um die Ohren.

Auf Laptops hat­te ich schon vor Jahren lie­ber zu OpenBSD, das ein­fach funk­tio­nier­te, oder ande­ren Konkurrenzsystemen gegrif­fen und habe der­zeit also kei­nen sol­chen mit FreeBSD mehr im Einsatz. Zwar stell­te mich FreeBSD als Nutzer und Entwickler nicht mehr zufrie­den, aber die dort gepark­ten Dienste wol­len ja durch­aus immer noch wei­ter betrie­ben wer­den. Die offen­sicht­li­che Alternative OpenBSD war vor­erst nicht ganz oben auf mei­ner Liste: Zwar treibt sie einen ande­ren mei­ner Server recht zuver­läs­sig an, aber ich bin inzwi­schen, fürch­te ich, ein wenig faul gewor­den und wür­de die ver­gleichs­wei­se arbeits­in­ten­si­ven halb­jähr­li­chen Updates ungern mehr als ein­mal machen müssen.

Ärger mit der Libelle

Das erste Ziel war also wie­der ein­mal DragonFly BSD, ein Fork einer alten FreeBSD-Version mit enor­men Verbesserungen des Dateisystems, jedoch auch einer weit­ge­hen­den Kompatibilität mit FreeBSD, was die Ports angeht. DragonFly BSD funk­tio­nier­te bei der Ersteinrichtung recht gut, jedoch bemerk­te ich schnell, dass auch eine Kehrseite von FreeBSD kom­pa­ti­bel mit ihm ist: Der Port von SBCL, einer durch­aus nicht unwich­ti­gen Komponente, funk­tio­nier­te nicht wie erwar­tet. Zwar konn­te ich die­ses Problem mit Ravenports, einem alter­na­ti­ven Portsystem eines DragonFly-BSD-Entwicklers, augen­schein­lich lösen, aber in Summe war der Weg dort­hin mir deut­lich zu steinig.

Weil ich den Server, wie bereits geschrie­ben, pro­duk­tiv ein­set­zen woll­te, nutz­te ich die­se Gelegenheit auch nicht, um wil­de Experimente zu wagen; 9front, die GNU Hurd oder gar das skur­ri­le Frickelsystem Linux kamen hier also nicht in Frage. (Dass ich mich gera­de aus ande­ren Gründen mit dem 9front-Texteditor Acme beschäf­ti­ge, ist viel­leicht eines Tages eine län­ge­re Abhandlung wert.) Das soll natür­lich nicht bedeu­ten, dass mich Popularität bei der Auswahl inter­es­sier­te, nur ver­nünf­tig lau­fen soll­te es schon. Und wel­ches System hat seit Jahrzehnten den Ruf, so ver­nünf­tig zu lau­fen, dass es sogar kon­ser­va­ti­ve Unternehmen für viel Geld benut­zen wol­len? Na, Solaris natürlich!

Solawas?

Solaris - die Älteren erin­nern sich viel­leicht - wur­de Anfang der 1980er unter Mitwirkung von Bill Joy, dem Entwickler von ex, vi, Distributor von BSD UNIX und spä­ter lei­der auch Mitschuldigen an der Existenz von Java, als SunOS erst­mals ver­öf­fent­licht, seit der Umstellung von der BSD- auf die AT&T gehö­ren­de UNIX-System-V-Codebasis etwa zehn Jahre spä­ter trägt es sei­nen heu­ti­gen Namen. Von 2008 bis 2010 stand ein Großteil des Systems als OpenSolaris frei zur Verfügung, womit die­ses das erste freie System-V-UNIX war, denn die eben­falls Anfang der 1990er ent­stan­de­nen frei­en BSD-Derivate durf­ten kei­nen AT&T-lizenzierten Code mehr ver­wen­den, ohne Lizenzgebühren zu zahlen.

Als der US-ame­ri­ka­ni­sche Datenbank- und Heuschreckenkonzern Oracle, der eigent­lich nur die Konkurrenz MySQL unter Kontrolle bekom­men woll­te, im Jahr 2010 aus Versehen auch den gan­zen Rest von Sun Microsystems mit­kauf­te, gehör­te das Brandroden des Portfolios zu sei­nen näch­sten Schritten, auch Solaris und die her­vor­ra­gen­den SPARC-Prozessoren muss­ten seit­dem Federn las­sen. OpenSolaris wur­de nach kur­zer Zeit ein­ge­stellt und die bis dahin erhal­te­nen Codebeiträge von ande­ren Entwicklern in das wie­der­um kom­mer­zi­el­le Solaris 11 inte­griert. Das mach­te vie­le Menschen sehr ungehalten.

Der kur­zen Zeit, in der es ein frei­es Solaris gab, ist es aber zu ver­dan­ken, dass bald unab­hän­gi­ge Nachfolgeprojekte auf Grundlage des OpenSolaris-Forks illu­mos ent­stan­den waren, die oft von ent­täusch­ten ehe­ma­li­gen Sun-Entwicklern vor­an­ge­trie­ben wur­den. Von den bis dahin ent­stan­de­nen tech­ni­schen Innovationen von Solaris, dar­un­ter das Dateisystem ZFS, das Initsystem Service Management Facility (SMF), DTrace und die Containertechnik „Zones“ - mit etli­chen Jahren Verspätung und weni­ger Funktionen in der Linuxwelt als „Docker“ nach­ge­baut - pro­fi­tier­ten auch die­se neu­en Projekte, allen vor­an OpenIndiana, das unter den illu­mos-Distributionen wegen sei­nes ver­gleichs­wei­se ein­fach zu instal­lie­ren­den Desktops die bekann­te­ste ist.

Distributionsdurcheinander

An die Existenz die­ser Systeme hat­te mich bereits im September 2017 der ehe­ma­li­ge Piratenaktivist Ali Utlu erin­nert, was mir schon damals ein Auslöser dafür war, mich mit den gän­gi­gen Varianten zu befas­sen. OpenIndiana haf­te­te der Ruf an, nicht unbe­dingt das kom­pak­te­ste und schnell­ste System zu sein, im Web wur­de ich jedoch auf einen Blogartikel auf­merk­sam, der Tribblix, eine auf einen ver­gleichs­wei­se schlich­ten Desktop aus­ge­rich­te­te Distribution, deren anschei­nend ein­zi­ger Entwickler bewusst zu kon­ser­va­ti­ven Lösungen wie den in älte­ren Solarisversionen ver­wen­de­ten SVR4-Paketen neigt, emp­fahl. Auf YouTube wirk­te das System auch nicht unsym­pa­thisch, aber mein als Testsystem genutz­ter Laptop bekam kei­ne WLAN-Verbindung - die BSDs und illu­mos, die sich die Hardwareunterstützung gern ein­mal tei­len, unter­stütz­ten mei­nen Adapter noch nicht. Damit war das Kapitel illu­mos für mich erst ein­mal wie­der beendet.

Der neue Webserver aller­dings, nahm ich an, wür­de die­ses Problem nicht haben, denn Server sind sel­ten kabel­los ange­bun­den. Die illu­mos-Welt war unter der wesent­li­chen Federführung des inzwi­schen zu Samsung gehö­ren­den Unternehmens Joyent, das sei­ner­seits die Distribution SmartOS in sei­nem Portfolio führt, nicht ste­hen geblie­ben, bei­na­he regel­mä­ßi­ge Neuigkeiten blie­ben mir nicht ver­bor­gen. Ich ent­schied mich dafür, es ein­mal mit dem auf den Serverbetrieb spe­zia­li­sier­ten OmniOS „Community Edition“ zu ver­su­chen, das im Sommer 2017 als Nachfolgesystem des ein­ge­stell­ten OmniOS von OmniTI vor­ge­stellt wor­den war und des­sen Entwicklung von einer eigens gegrün­de­ten Schweizer Stiftung finan­ziert wird. Mal sehen, wie lan­ge das gut geht.

OmniOS ja, nein?

Das stän­dig im Fluss befind­li­che OmniOS, das (wohl auch aus recht­li­chen Gründen) man­che Anwendungen aus FreeBSD über­nom­men hat, dar­un­ter inzwi­schen auch den Bootloader sowie Teile des Userlands, ist trotz­dem von Anfang an als ein Betriebssystem mit ganz eige­nen Wurzeln zu erken­nen. Das beginnt beim Installationsprogramm, das bis gestern „Kayak“ hieß und mit sei­nem Frage-Antwort-Konzept der Installation von OpenBSD sehr ähnel­te, jedoch waren alle mög­li­chen Antworten bereits vor­ge­ge­ben und man wähl­te ein­fach die Zahl aus, die zu der jeweils pas­sen­den Antwort gehört. Das galt auch für Ja-Nein-Fragen, was nur zu Beginn ein Umdenken erfor­der­te. - Mit der vor weni­gen Stunden ver­öf­fent­lich­ten OmniOS-Version r151026 wur­de die­ses Installationsprogramm durch eines ersetzt, das sich wie­der mit Menüs bedie­nen lässt, jedoch kann, wer (wie ich) bun­te Textwüsten nur mäßig inter­es­sant fin­det, per Druck auf „T“ bei Beginn der Installation die vor­he­ri­ge Version wei­ter­hin benutzen.

Nach der anson­sten brauch­bar doku­men­tier­ten Installation hat man ein System vor sich, das mög­li­cher­wei­se funk­tio­niert. Schnell merkt man aber trotz der Standardshell ksh93, dass in ande­ren Systemen erar­bei­te­tes Wissen hier auf­grund des immer noch haupt­säch­lich von Sun ent­wor­fe­nen Userlands kaum anwend­bar ist:

$ ping tuxproject.de
tuxproject.de is alive

Immerhin: Das Netzwerk funk­tio­niert anschei­nend, auch wenn die Meldung, die dies signa­li­siert, anders aus­sieht als gewohnt. Ich gebe gern zu, dass mir die­se Darstellung sogar noch ein biss­chen bes­ser gefällt als die sonst übli­che; ich per­sön­lich benut­ze ping in der Regel tat­säch­lich nur, um die Erreichbarkeit von irgend­wel­chen Servern (sel­ten: die Verfügbarkeit der Internetverbindung) zu ermit­teln. Apropos anders: Bei der Installation wur­de ich dar­auf hin­ge­wie­sen, dass sudo hin­ter pfe­xec nur eine unter­ge­ord­ne­te Rolle spielt und ob ich mit mei­nem eben­dort ein­ge­rich­te­ten Benutzerkonto trotz­dem sudo ver­wen­den möch­te. Ich habe das zwar bejaht, aber wer­de im Folgenden trotz­dem pfe­xec benut­zen. Es fühlt sich viel rich­ti­ger an.

Paketdienste und mehr

Zwar kommt OmniOS ab Werk mit einer nen­nens­wer­ten Sammlung an nicht völ­lig unin­ter­es­san­ter Software, aber wenn etwas fehlt, dann ist es nicht gera­de offen­sicht­lich, woher man es neh­men könn­te. Die haus­ei­ge­ne Paketverwaltung pkg, die FreeBSDs pkgng (inzwi­schen eben­falls als pkg bekannt) augen­schein­lich ähnelt, aber wesent­lich gesprä­chi­ger ist und auch mehr Dinge zu tun scheint, die sich mir noch nicht in jedem Fall ganz erschlos­sen haben, besticht nicht gera­de durch ein reich­hal­ti­ges Angebot:

$ pfexec pkg search nginx
$

Die offi­zi­ell emp­foh­le­ne Vorgehensweise ist es, die Paketverzeichnisse von Freiwilligen ein­zu­bin­den. Ich stand nun vor der schwie­ri­gen Entscheidung, vie­le zwei­fel­haf­te Quellen in mein nor­ma­les pkg ein­zu­bin­den oder die offen­sicht­li­che Alternative, den von Joyent (und damit einem Unternehmen, das es sich nicht lei­sten kann, Murks zu ent­wickeln) bereit­ge­stell­ten Fork von pkgsrc, zu nut­zen. Ich ent­schied mich für letz­te­re Variante, wohl wis­send, dass ich dann eigent­lich auch bei DragonFly BSD hät­te blei­ben kön­nen. Tja - zu spät!

pkgsrc funk­tio­niert wie aus ande­ren 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ät­te ich hier auch die Möglichkeit, statt­des­sen Ports selbst zu kom­pi­lie­ren, aber in die­se Tiefen woll­te ich noch nicht wie­der vor­drin­gen. 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 gele­gent­lich dar­auf hin, wie man - falls vor­han­den - ihren Systemdienst in SMF inte­griert. Grundsätzlich scheint mir die­ser super­vi­sor, wenn­gleich nicht unbe­dingt der schnell­ste, doch ein ziem­lich durch­dach­ter zu sein: Per svcadm enable/disable [Dienst] star­tet man einen Dienst oder hält ihn an, wenn dabei etwas schief­läuft und er zum Beispiel auf­grund von Konfigurationsfehlern nicht wie­der star­tet, zeigt svcs ihn im „Wartungsmodus“ (main­ten­an­ce) an. Sind die Fehler gefun­den und beho­ben, setzt svcadm clear [Dienst] sei­ne Arbeit fort. Die Reihenfolge der Parameter unter­schei­det sich hier von der aus FreeBSD gewohn­ten (ser­vice [Dienst] [Befehl]), aber die­ser Umstand macht sich beim Vertippen in der Regel von allein bemerkbar.

Als ich nach einer Weile her­aus­fin­den woll­te, wie res­sour­cen­hung­rig mein neu­er Server wohl sein mag, fiel mir aber­mals eine Besonderheit von Solaris-Systemen sozu­sa­gen auf die Füße: top exi­stiert hier nur als exter­nes Paket. Eine Tabelle im Wiki von SmartOS ließ mich her­aus­fin­den, dass es unter illu­mos statt­des­sen eine gan­ze Horde an Befehlen gibt, die auf „stat“ enden und prin­zi­pi­ell alles sta­ti­stisch abbil­den kön­nen, was man bei der Arbeit mit dem System so braucht. top am näch­sten kommt hier wahr­schein­lich prstat, was für „Prozessstatistik“ zu ste­hen scheint.

Virtualisier mich am Arsch

Ich erwähn­te oben „Zones“, also illu­mos‘ ein­ge­bau­tes Docker-Vorbild. Diese kön­nen nicht nur für den Betrieb von vir­tu­el­len Maschinen genutzt wer­den, son­dern sind zusam­men mit den Containerfunktionen von ZFS so tief in das System inte­griert, dass auch das Dateisystem selbst in der Standardausführung völ­lig anders funk­tio­niert als etwa ZFS unter FreeBSD. Das beginnt bereits beim Update des Systems: Die vor­he­ri­ge Version des Betriebssystems wird in eine neue Bootumgebung kopiert, die man im Fehlerfall dann wie­der star­ten kann. Diese Bootumgebung umfasst alles unter­halb des Wurzelverzeichnisses /, was kei­nen eige­nen Bereich im ZFS reser­viert bekom­men hat. Auch das hat mich über­rascht, denn nach mei­nem ersten OmniOS-Upgrade auf die Version r151024 war plötz­lich mein /opt-Verzeichnis ver­schwun­den und mit ihm pkgsrc mit allen bis dahin instal­lier­ten Paketen.

Das Anlegen eines Verzeichnisses, das auch eine neue Bootumgebung über­steht, funk­tio­niert direkt auf Dateisystemebene. Wenn der bei der Installation ange­leg­te ZFS-Pool (wie stan­dard­mä­ß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 soll­te /opt jetzt außer­halb der „ROOT“ genann­ten Bootumgebung anzei­gen. Ich emp­feh­le außer­dem, die Standardbelegung des /home-Verzeichnisses nicht anzu­rüh­ren, denn auch die­ses funk­tio­niert, falls nicht geän­dert, nicht so wie man es erwar­ten sollte.

Unter den Diensten, die ein jung­fräu­li­ches OmniOS zu star­ten pflegt, befin­det sich auch auto­mount, das über die Datei /etc/auto_master gesteu­ert wird und von dort aus über die Datei /etc/auto_home das Benutzerverzeichnis auto­ma­tisch aus dem ZFS-Pool moun­tet, stan­dard­mä­ßig anschei­nend aus rpool/export/home/. Das ist prak­tisch, wenn man weiß, dass es da ist, und ver­wir­rend, wenn man es nicht weiß. Ich habe mich dazu ent­schie­den, lie­ber auf die alt­her­ge­brach­te Methode zurück­zu­grei­fen, die auf nicht vir­tua­li­sier­ten Servern kei­nen offen­sicht­li­chen Nachteil mit sich bringt:

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

Ein eige­ner ZFS-Bereich wur­de wie oben beschrie­ben eben­falls reser­viert. Damit war der Spuk vor­bei. Die vor Veröffentlichung die­ses Artikels durch­ge­führ­te Aktualisierung des Systems dau­er­te unge­fähr drei Minuten und nach dem fäl­li­gen Neustart war alles - ein­schließ­lich der instal­lier­ten Dienste - noch an sei­nem Platz. Es ist etwas scha­de, dass das ande­ren Systemen manch­mal so schwer fällt.

Frühjahrsputz

Als ich den alten Server 2010 erst­mals ein­ge­rich­tet habe, habe ich auf eine Trennung zwi­schen ein­zel­nen Diensten nur sehr wenig geach­tet: Sehr weni­ge Domains tei­len sich sehr vie­le Dienste. Der alte Server ist also, um es ange­mes­sen form­los aus­zu­drücken, schei­ße kon­fi­gu­riert. Der Wechsel zu einer völ­lig neu­en Umgebung wird also selbst unter der Annahme, dass OmniOS als System nicht noch acht Jahre über­le­ben wird, zumin­dest den Vorteil haben, dass ich jetzt end­lich eine ver­nünf­ti­ge Gelegenheit habe, eine Inventur vor­zu­neh­men und das Vorhandene unter Zuhilfenahme von Subdomains etwas sinn­vol­ler auf­zu­tei­len als bisher.

Für einen Umzug ein­zel­ner Dienste, deren Domain nicht ein­fach geän­dert wer­den kann, ohne mehr Arbeit nach sich zu zie­hen, scheint HAProxy sich zu eig­nen. Ich wer­de sehen, ob ich es bereu­en wer­de, die­sen Schritt gegan­gen zu sein.

Bislang sieht es nicht so aus.

Senfecke:

  1. Uiuiui, da muss aber jemand frickeln. Man gut, dass du als Linux-Verweigerer noch nicht aus der Übung gekom­men bist ;)

Comments are closed.

:) 
:D 
:( 
:o 
8O 
:? 
8) 
:lol: 
:x 
:aufsmaul: 
mehr...
 

Erlaubte Tags:
<strong> <em> <pre> <code> <a href="" title=""> <img src="" title="" alt=""> <blockquote> <q> <b> <i> <del> <span style=""> <strike>

Datenschutzhinweis: Ihre IP-Adresse wird nicht gespeichert. Details finden Sie hier.