Erfahrungen mit OmniOS aus BSDler-Sicht

C

CrimsonKing

Guest
Code:
$ ping bsdforen.de
bsdforen.de is alive

:confused:

Der Ersatz für meinen FreeBSD-Webserver - ich kündigte diesen anderswo ja bereits an - läuft aktuell unter OmniOS in der aktuellen Version r151024, einer der unzähligen auf Solaris 11 basierenden illumos-Distributionen und damit einem "richtigen UNIX" (i.e. SysV, abgesehen natürlich von den Paketen, denn mit Solaris 11 wurden SVR4- weitgehend durch IPS-Pakete ersetzt), und es sieht so aus, als bliebe ich dabei. Zwar ist es ein aus sowohl BSD- als auch Linuxsicht völlig anderes System, das zu lernen schon deshalb Umgewöhnung voraussetzt, weil es weder strikten GNU- noch strikten BSD-Vorgaben wirklich folgt, aber die Situation ist auf Servern, wo WLANs und Desktops nicht viel bedeuten, eine etwas andere.

Zumal die Entwickler von OmniOS fleißig bemüht sind, den Wildwuchs an GNU-Werkzeugen etwas einzudämmen: Erst vor wenigen Monaten wurde grub durch den FreeBSD-Loader ersetzt, statt der bash findet der Benutzer die ksh93 als Standardshell vor. Einer der Entwickler formulierte es in einem Gespräch vorhin so:

OmniOS tends towards tools inherited from OpenSolaris or those imported from the BSD world, but there are a bunch of GNU utilities. Most are available if you need them with a prefix of g, so gsed, ggrep etc.

Grundsätzlich ist der Weg von FreeBSD also nicht ganz so weit wie der von GNU/Linux, auch wenn einige FreeBSD-ismen inzwischen weichen mussten: Hatte OmniOS noch vor einem Jahr einen FreeBSD und Slackware nicht unähnlichen Installationsvorgang mit bizarren TUI-"Dialogen", so hat inzwischen ein Installer, der Kayak Interactive Installer heißt und mit seinem Frage-Antwort-Konzept merklich OpenBSD ähnelt, diesen ersetzt. Für die für Mai geplante nächste OmniOS-Version soll er wohl nochmals vereinfacht werden - jedoch werde ich davon wahrscheinlich nichts merken: Das Upgrade auf eine neuere Version von OmniOS funktioniert ganz ohne ihn. Dass die Installation beim ersten Mal (ich klagte mein Leid im IRC) fehlschlug, weil ich meinen sshd nicht von außen erreichen konnte, war allein mein Fehler: Ohne DHCP kein Netz. Zum Glück bietet "Kayak" am Ende der Installation eine erfrischend einfache Möglichkeit, das Netzwerk von der Voreinstellung "static" auf "DHCP" umzustellen und der Rest geht dann automatisch. Nimm dies, NetBSD! :rolleyes:

Die Paketauswahl ist absichtlich schmal gehalten: Das offizielle "Repository" hält nur die essenziellen Systemkomponenten bereit, wobei das schon viele sind. Wer mehr haben möchte, der wird darum gebeten, eigene Repositorys bereitzustellen, die dann anscheinend so ähnlich wie Gentoos "Overlays" funktionieren. Als bekennender Faulpelz habe ich mir die Arbeit aber einfacher gemacht und Joyents pkgsrc installiert, wo ich erwartungsgemäß alles gefunden habe, was ich brauchte. Ob es auch ein offizielles Portssystem gibt, habe ich allerdings noch nicht herausgefunden. Warum auch? Binärpakete - obwohl OmniOS' pkg ziemlich geschwätzig ist - funktionieren anstandslos und pkgin ohnehin. pkg scheint übrigens auch Unterpakete und Flavors zu unterstützen. Mal gucken, was FreeBSD als nächsten Schritt vollzieht. Zusätzlich zu pfexec bietet OmniOS standardmäßig auch sudo an und trägt neu angelegte Benutzer auf Wunsch automatisch dort ein. Ich finde das sehr entgegenkommend; jedenfalls, bis ich pfexec verstanden habe.

Und sonst: ZFS als einziges unterstütztes Dateisystem, DTrace, LX Branded Zones, SMF als Initsystem und inzwischen auch Abwehr gegen Meltdown - technisch gesehen ist OmniOS ein spannendes Dingsbums. Über die Vor- und Nachteile von SMF kann man sicherlich ausgiebig diskutieren, mir ist vor allem aufgefallen, dass es beim Start immer ein wenig Bedenkzeit braucht. Danach läuft das System aber ziemlich rund und ein schnell aufgesetzter nginx ist erfreulich reaktionsschnell.

Ich vermute, es wird noch eine Weile dauern, bis ich den Umzug vollständig hinter mich gebracht habe, weil ich in meiner nie enden wollenden Weisheit sehr viele Dienste hinter sehr wenigen Domains geparkt habe und natürlich gern möglichst wenig Ausfallzeit erreichen möchte. Bislang nicht übel für ein sterbendes System.

Könnte ja sein, dass das irgendwen interessiert. :o
 
darktrym hat nicht völlig Unrecht: OmniOS ist - wie alle illumösse - ja quasi trotz vieler ins Land gegangener Jahre und Arbeit seitens des FreeBSD-Teams (beziehungsweise Apple) immer noch eine Art "FreeBSD-Upstream". Aber das war tatsächlich nicht mein wesentlicher Beweggrund.

Man muss da unterscheiden zwischen "weg von FreeBSD" und "hin zu etwas anderem". Dass ich FreeBSD wegen verschiedener Ärgernisse hinter mir lassen will, jedenfalls für meine eigenen Server (die, die ich für andere Leute pflege, sind mir technisch weitgehend egal - die kriegen, womit sie klarkommen, und FreeBSD reicht ihnen), war mir lange klar, nur habe ich noch gewartet. Ich bin ja ein bisschen faul. Erst gingen mir dauernd Ports beim Update kaputt und ich musste an irgendwelchen Einstellungen herumfingern, manche bauten auch überhaupt nicht mehr, weil mein Server zu schwachbrüstig wurde (das laste ich dem System aber nicht an), dann diese Sache mit dem bescheuerten Code of Conduct - technisch und moralisch war FreeBSD in letzter Zeit eigentlich nur noch ein Ärgernis für mich. Weil ich sowieso mehr RAM und damit einen neuen Server brauchte (wie eben angedeutet), habe ich noch mal über meine Optionen nachgedacht. Ein neuer Server ist ja wie ein neues Leben.

OpenBSD, das ich als Arbeitstier zu schätzen gelernt habe, habe ich als Ausweg noch im Kopf, aber ich finde das allsemestrige Update über den "unterstützten" Weg immer unnötig Zeit raubend. Vorher ausprobiert habe ich auch DragonFly BSD, aber da kriege ich sbcl partout nicht zum Laufen. pkg scheint Pfade nicht einzutragen - wie blöd ist das denn? Spontan hat sich auch sein Port geweigert, gebaut zu werden, und das wollte ich mir nicht noch mal geben. Das verzweifelt installierte Ravenports löst das Problem zwar, aber ich mag die Bedienung nicht: das Ding kennt anscheinend nur einen interaktiven Modus mit viel Bunt. Nö, da doch lieber was anderes.

OmniOS scheint das einzige Server-illumos zu sein, das man ohne GUI installieren kann, und ich wollte illumos zumindest mal benutzt haben. Ich kenne Leute, die sehr zufrieden damit wirken, und auf dem Papier liest es sich ja auch nicht schlecht. Auf dem Laptop konnte es leider (ich berichtete andernorts) nicht mit dem WLAN umgehen. Auf dem Server läuft es weitgehend anstandslos. Ein paar kleine Macken bügelt das Team gerade aus, sagt es. Ich freue mich darauf.
 
darktrym hat nicht völlig Unrecht: OmniOS ist - wie alle illumösse - ja quasi trotz vieler ins Land gegangener Jahre und Arbeit seitens des FreeBSD-Teams (beziehungsweise Apple) immer noch eine Art "FreeBSD-Upstream". Aber das war tatsächlich nicht mein wesentlicher Beweggrund.


OmniOS scheint das einzige Server-illumos zu sein, das man ohne GUI installieren kann, und ich wollte illumos zumindest mal benutzt haben. Ich kenne Leute, die sehr zufrieden damit wirken, und auf dem Papier liest es sich ja auch nicht schlecht. Auf dem Laptop konnte es leider (ich berichtete andernorts) nicht mit dem WLAN umgehen. Auf dem Server läuft es weitgehend anstandslos. Ein paar kleine Macken bügelt das Team gerade aus, sagt es. Ich freue mich darauf.

Geht bei Open Indiana auch.... gibt dort ja die Textinstall Medien. ;)
Prinzipiell ist das aber wurscht, ob mit GUI, oder ohne GUI allen "Solarisen" ist ja gemein das die Standardeinstellung Netservices limited out of the Box voreingestellt sind. Welches der "Solarise" man nimmt ist ja fast schon egal. Die LX Branded Zones sind natürlich ne schicke Sache, die man seinerzeit beim Orakel wieder beerdigte weil der Kunde das "angeblich" nicht haben wolllte..

Bei den Illumosen hab ich leider die Befürchtung, würde mich aber mehr als freuen wenn ich mich irren würde... das die ganze Geschichte irgendwann einschläft, es gibt zu wenig Entwickler und die bezahlten Entwickler knüppeln in erster Linie, für Nexenta, Delphix und Co.

So sehr ich es mir wünschen würde das Solaris weiter lebt... die kritische Masse in der Breite fehlt leider noch. Wobei ich meine Backupjodlerserver bei diversen Webhostern auch mit Open Indiana und Borg betreibe :-)
 
Schöne, wenn auch späte Erkenntnis: OmniOS zwingt einen quasi dazu, sich aktiv mit ZFS auseinanderzusetzen: Ein Update erzeugt per default ein neues "Boot-Environment" und damit auch ein neues "/" - was keinen eigenen ZFS-Container hat, ist dann halt weg.

Vorteil für mich: Ich habe endlich mal einen Grund, ZFS mehr als bloß theoretisch verstehen zu wollen.
 
Liegt dann in der alten Bootumgebung rum, ist also nicht (physikalisch) weg, sondern woanders. Das ist sehr nervig, wenn man nicht damit rechnet.

Wobei ich mir letztens ohnehin durch pures Nichtlesen von Handbüchern :rolleyes: schon mal ein Ei gelegt habe. Standardmäßig wird /home per automount gemountet, d.h. wenn man versehentlich den Originalordner vernichtet, ist nach dem nächsten Neustart kein /home mehr da. Also schon "noch da", aber über das (manuell eingerichtete) /home wird dann ein (automatisches) /home drübergemountet. Eigentlich eine ziemlich praktische Funktion - wenn man weiß, dass sie da ist...

svcadm disable automount beendet den Spuk. Oder halt die Finger von Ordnern lassen, die man nicht kapiert. (Hier bitte Kopf-Wand-Emoticon einfügen.)

TL;DR: FreeBSD-Gewohnheiten sind am Eingang abzulegen.
 
svcadm disable automount beendet den Spuk. Oder halt die Finger von Ordnern lassen, die man nicht kapiert. (Hier bitte Kopf-Wand-Emoticon einfügen.)
banghead.gif


ZFS hat so die ein oder andere Überraschung in der Hand ... und ja, ich lese die Anleitungen auch manchmal zu spät.
 
Ironischerweise bestätigt dein pampiger und ziemlich unnötiger Beitrag zum Thema meine Entscheidung, von diesem Projekt ganz weit weg sein zu wollen.

Nö, FreeBSD wird dadurch kein schlechteres System, aber offensichtlich sind System (Portprobleme) und Community (CoC) gleichermaßen kaputt. Bei strcat (dem Blogger) las ich dieser Tage ähnliche Beobachtungen, was die Ports betrifft.
 
Ich finde den CoC inhaltlich auch nicht besonders gelungen. Andererseits habe ich kein Problem damit, mich an die genannten Regeln zu halten, bzw. habe ich es aus gesundem Menschenverstand schon vorher gemacht. Insofern ist es mir vollkommen egal, was da genau drinsteht, ich muss mein Verhalten als Committer überhaupt nicht Ändern.
Warum sich Benutzer von FreeBSD an dem CoC so sehr stören, dass sie das Betriebssystem nicht mehr benutzen wollen / können, ist mir vollkommen unverständlich. FreeBSD bleibt FreeBSD.
Wenn du mit dem Portssystem ein Problem hast, ist das ne andere Geschichte, da kann ich das nachvollziehen.
 
Mal wieder was zum Thema: Ein neues OmniOS ist da, mit dem DragonFly-MTA statt sendmail sowie einem bunten (aber optionalen) Menüinstaller für Freunde von Regenbogenterminals.

Das Update funktionierte wie beschrieben:

Code:
# beadm create omnios-r151024
# pkg set-publisher -O https://pkg.omniosce.org/r151026/core omnios
# pkg update -f -r --be-name=r151026
# reboot

Zonen, die nicht "global" heißen, habe ich gerade nicht, das hat mir ein bisschen Arbeit gespart.

Das ganze Update war schneller erledigt als eine Tasse Tee durchziehen konnte und alle Dienste aus pkgsrc waren auch noch da und liefen auch noch. Ich mag das.
 
Zonen, die nicht "global" heißen, habe ich gerade nicht, das hat mir ein bisschen Arbeit gespart.
Huhu,

wie meinst Du das? Solaris 11.x patcht doch Zonen automatisch mit, im Gegensatz zu Solaris 10 hatte ich dabei mit Solaris 11 noch nie Probleme. OmniOS sollte doch ebenfalls wie Solaris 11 auf OpenSolaris basieren?

Gruß
marmorkuchen
 
Die CoC-Diskussion hatten wir schon an anderer Stelle und brachte nicht viel. Ich denke auch hier wird uns die Diskussion darum nicht weiter bringen. Also bitte lasst es einfach
 
Was die Updates von Zonen betrifft: laut Anleitung, die ich bis auf Weiteres noch brauche, benötigen lipkg-gebrandete Zonen, was immer das jetzt wieder ist, jeweils noch Handarbeit. Vielleicht verstehe ich das ja bis zum nächsten Update. :)

Nachtrag: Die hier.
https://omnios.omniti.com/wiki.php/linked_images
 
Ist denn dein OmniOS hinreichend schnell als *AMP-Server einsetzbar oder ist das ein ewiges Gefrickel und die Kiste kann vor allem ZFS?
 
Ich habe darauf ja gerade "nur" ein nginx, ein SQLite und ein Lisp regelmäßig laufen - der Server krault sich quasi die Eier. Ich habe da 6 GB RAM draufgeworfen, das gibt ihm anscheinend genug Ressourcen.

Gefrickel war da bisher nichts. Nur für einen FTPd müsste ich einen Service schreiben.
 
Zurück
Oben