OpenBSD als Work Laptop

jayjay

New Member
Hallo liebe BDS Community,

ich bin der Jakob und seit mehr als 10 Jahre aktiver und mal mehr mal weniger begeisterter Linux User und Server Admin. Seit einigen Jahren befinde ich mich auf einer Reise in Richtung eines möglichst minimalistischen OS Setups mit möglichst 100% FOSS Software sowie möglichst wenig Paketen und Moving-Parts. Aus diesem Grund und aus Gründen der Sicherheit, möchte ich nun nach langem zögern den Sprung zu BSD, genauer OpenBSD, wagen.

Die Philosophie dahinter gefällt mir unfassbar gut und mir kribbelt es in den Fingern, OBSD auf mein Thinkpad zu packen. Allerdings gibt es ein paar Punkte, die mich aktuell noch zögern lassen. Diesbezüglich bin ich sehr interessiert an Erfahrungsberichten der hier versammelten OBSD Veteranen :belehren::)

Ich selber arbeite als beratender Softwareentwickler mit dem Schwerpunkt der Infrastruktur-Automatisierung, dadurch komme ich in meinem Arbeitsalltag an vielen unterschiedlichen Soft- und Hardwareprojekten vorbei mit den unterschiedlichsten Setups und Sprachen.

Nun zu der Fragen:

Wie gesagt, ich nutze in vielen verschiedenen Projekten sehr unterschiedliche Technologien, sowohl Scriptsprachen und Programmiersprachen als auch Linux-Spezifische Stacks wie z.B. Docker oder das Testen von systemd units. Daher ist es für mich sehr wichtig, dass sich mit wenigen Mitteln ein virtuelles Linux betreiben lässt. Ich habe immer wieder an verschiedenen Stellen gelesen, dass OBSD dem Thema der Virtualisierung kritisch gegenübersteht, andererseits existieren ja Projekte wie z.B. vmd. Habt Ihr Erfahrungen mit letzterem für Linux Hosts? Wie ist da die Performance?

Idealerweise würde ich für jedes Kundenprojekt eine eigene VM aufsetzen mit dem OS das sinnvollerweise zu dem Techstack passt. So halte ich auch mein Kernsystem sauber von dem Wust an Abhängigkeiten die so manche Software mit sich bringt.

Bin sehr interessiert an eurer Meinung!

Mit den besten Grüßen
Jakob
 
Vorweg: ich kenne OpenBSD nicht.

Bevor ich irgendwas in Richtung Kunde mit einem OS mache, lerne ich es kennen. Über mehrere Versionen, unterschiedliche Probleme, unterschiedliche Hardware. Sowas braucht einfach seine Zeit.

Ansonsten einfach mal ne Testkiste zum Spielen aufziehen und loslegen. :)
 
Ich habe einige Erfahrungen mit OpenBSD machen dürfen, aber nicht als Server, sondern mit verschiedenen Desktop Systemen. Als Server dürfte es wohl wahrscheinlich die wenigsten Probleme geben.
OpenBSD ist wohl sehr wählerisch, was die Hardware angeht. Nvidia Karten gehen gar nicht, Intel und AMD gehen mal, mal wieder nicht. Leider war jede neue Version von OpenBSD wie eine Wundertüte und eine Verläßlichkeit im Desktop Betrieb nicht gegeben. Kunden empfehlen würde ich das nur, wenn ich es mit der Hardware vorher ausgiebig getestet hätte. Ich poste hier nur meine Erfahrungen, andere Communitymitglieder können andere Erfahrungen gemacht haben. Wenn sich hier keiner der OpenBSD Experten zu Worte meldet, spricht das wohl schon für sich. Ich würde das persönlich so interpretieren, das sich keiner aus dem Fenster lehnen will. Die besten Ergebnisse hatte ich nur durch ausprobieren, Versuch und Irrtum. Wenn es dann einmal rund läuft, dann läuft es. Ob es für die nächste Version dann auch so ist, da habe ich leider keine guten Erfahrungen gemacht.
 
Für's Kennenlernen erstmal Nomad BSD. Ist zwar FreeBSD, aber läuft als System vom Stick. Ich honoriere den Anspruch von OpenBSD aber bei FreeBSD sehe ich aufgrund der größeren Verbreitung eher die Möglichkeit, daß jemand helfen kann. Zum Thema Virtualisierung unter verschiedenen BSD sollten die Experten was sagen. Auf den T Laptops läuft FreeBSD jedenfalls "zackig"

Serie300
 
Ich selber arbeite als beratender Softwareentwickler mit dem Schwerpunkt der Infrastruktur-Automatisierung, dadurch komme ich in meinem Arbeitsalltag an vielen unterschiedlichen Soft- und Hardwareprojekten vorbei mit den unterschiedlichsten Setups und Sprachen.

Ich bin ganz ähnlich unterwegs und habe bzw. hatte das gleiche Problem als Developer mit reichlich Operations-Erfahrung in den unterschiedlichen "DevOps-Rollen". Momentan ist bei mir meistens Terraform und Ansible gefragt, Docker sowieso.

Ich habe immer wieder an verschiedenen Stellen gelesen, dass OBSD dem Thema der Virtualisierung kritisch gegenübersteht, andererseits existieren ja Projekte wie z.B. vmd. Habt Ihr Erfahrungen mit letzterem für Linux Hosts? Wie ist da die Performance?

Virtualisierung unter OpenBSD ist leider noch weit von der Produktionsreife entfernt. Es wird aktuell keine grafische Ausgabe unterstützt, d.h. man muss die VM immer über die virtuelle serielle Konsole ansprechen (vgl. OpenBSD-Doku).

Wenn und solange es mal läuft, ist die Performance in Ordnung. Die Limitation auf eine vCPU beim Gast ist verschmerzbar, im Gegensatz zu den häufigen Abstürzen der Gast-VMs. :(

Idealerweise würde ich für jedes Kundenprojekt eine eigene VM aufsetzen mit dem OS das sinnvollerweise zu dem Techstack passt.

Dafür nutzt man lokal idealerweise (sofern die Aufgabenstellung es ermöglicht) Docker, wenn man für Kunde x Datenbank y in Version z braucht. Mit docker-compose lässt sich das trivial pflegen. Für VMs landet man recht schnell bei VirtualBox oder KVM, wobei die Pflege von vielen unterschiedlichen VM-Setups selbst automatisiert immer ziemlich nervig ist.

Beides lässt sich mit dem Hashicorp-Stack (Vagrant, Packer & Co.) perfekt bedienen.

So halte ich auch mein Kernsystem sauber von dem Wust an Abhängigkeiten die so manche Software mit sich bringt.

Auch diese Infrastruktur würde ich automatisieren - ich habe mein Rechner-Setup mit Ansible provisioniert. So kann ich auch auf meinem Laptop immer einen sauberen und reproduzierbaren Zustand herstellen.


Fazit: OpenBSD ist leider für deine Anforderungen momentan noch völlig unbrauchbar, erst recht wenn du damit dein täglich Brot verdienen willst.
 
Mal so ne Frage in die illustre Runde... Ok VMM als Kernel Based Virtualisierung ist noch nicht so weit... wie schaut's aber bei OpenBSD mit Qemu aus? Kann das nicht was gesucht wird?
 
Mal so ne Frage in die illustre Runde... Ok VMM als Kernel Based Virtualisierung ist noch nicht so weit... wie schaut's aber bei OpenBSD mit Qemu aus? Kann das nicht was gesucht wird?

Qemu unter OpenBSD hat keine Hardwarebeschleunigung und ist somit um Faktor ~10-20 langsamer als z.B. Qemu mit KVM oder der native Betrieb. Wenn du für einen Test in einer VM statt 1 Minute gesalzene 15 Minuten auf dein Ergebnis warten musst, ist die Freude eher verhalten.
 
Ich würde für VM Geschichten nicht auf OpenBSD wechseln, höchstens du möchtest das Grundsystem nicht mit 3rd Party belasten, Hintergrund:

- im stable werden keine Binaryupdates durchgeführt (mtier's openup wäre auch ne Lösung, jedoch nicht im repo vorhanden)
- current würde ich trotz guter Erfahrung nicht als Produktivsystem für Kunden nutzen

Habe keine Erfahrungen mit linux auf vmd
 
Meine Erfahrungen mit Linux unter VMM sind auch bescheiden. Debian stable und testing liefen gar nicht. Debian 8 lief eine Zeit lang ganz ok. Seit einigen Monaten laeuft auch dieses "bei mir" nicht mehr unter OpenBSD -current und schmiert beim booten mit einem kernel panic ab. Die Synchronisation der Zeit funktionierte damals gar nicht. Andere Linux Distributionen habe ich auch nicht zum Laufen bekommen. Evtl. liegt das auch an meiner Hardware. OpenBSD als VMM-Guest laeuft allerdings sehr gut unter OpenBSD als VMM-Host. ;-)
 
Hm, ok, wenn Virtualisierung auf OpenBSD (noch?) nicht besonders gut unterstützt wird und das aber eine harte Anforderung ist -- warum dann nicht FreeBSD? Kann hier natürlich auch nur meine eigenen Erfahrungen wiedergeben: Mit FreeBSD's bhyve laufen bei mir diverse VMs, Windows und Linux Systeme, alles problemlos, und mit dem vm-bhyve Paket gut zu managen.
 
Hm, ok, wenn Virtualisierung auf OpenBSD (noch?) nicht besonders gut unterstützt wird und das aber eine harte Anforderung ist -- warum dann nicht FreeBSD? Kann hier natürlich auch nur meine eigenen Erfahrungen wiedergeben: Mit FreeBSD's bhyve laufen bei mir diverse VMs, Windows und Linux Systeme, alles problemlos, und mit dem vm-bhyve Paket gut zu managen.

Weil jayjays Anwendungsfall wohl stark von Docker profitieren würde und Docker unter FreeBSD auch nach mehr als 6 Jahren immer noch nicht funktioniert.

Ferner geht der Trend momentan auf breiter Front weg von Virtualisierung hin zu Containern, was sich auch mit 10-20€ netto mehr beim Stundensatz niederschlägt. Solange jayjay sein Geld damit verdient, ist er gut beraten, sein Setup möglichst produktiv zu halten. Mit nativem Linux plus Containern arbeitet es sich effizienter und effektiver als mit nativem FreeBSD plus Linux-VM plus Containern.
 
Weil jayjays Anwendungsfall wohl stark von Docker profitieren würde und Docker unter FreeBSD auch nach mehr als 6 Jahren immer noch nicht funktioniert.
[...]
Mit nativem Linux plus Containern arbeitet es sich effizienter und effektiver als mit nativem FreeBSD plus Linux-VM plus Containern.
Genau das wollte er laut Eingangsposting aber doch mit OpenBSD tun? Also vielleicht lässt du ihn selbst antworten...

Nur am Rande sei angemerkt, dass eine Formulierung, die nahelegt, FreeBSD könne keine Container, recht absurd ist wenn man sich das Alter der Jails anschaut. Auch gibt es erste Anzeichen, dass Docker wieder (zugunsten anderer Lösungen) zurückgehen könnte. Nützt keinem was, der hier und heute genau auf Docker gesetzt hat, sollte in dem Kontext aber trotzdem beides mal erwähnt sein.
 
Genau das wollte er laut Eingangsposting aber doch mit OpenBSD tun? Also vielleicht lässt du ihn selbst antworten...

Er ist ja nicht der erste, der in dem Bereich alles per VM erschlagen möchte - (nicht nur) ich wollte es ja für meine Kundenprojekte genauso machen. Auch er wird die Erfahrung machen, das die VM-Zwischenschicht anstelle des direkten Container-Einsatzes im Alltag viele Nachteile bringt. VMs würde ich auf die Stellen beschränken, an denen es absolut notwendig ist.

Nur am Rande sei angemerkt, dass eine Formulierung, die nahelegt, FreeBSD könne keine Container, recht absurd ist wenn man sich das Alter der Jails anschaut.

Jails sind kein adäquater Ersatz für Container. Weder sind sie so leicht zu benutzen noch so flexibel, vom Ökosystem ganz zu schweigen. Von einem Äquivalent zu Kubernetes o.ä. mit jails habe ich auch noch nichts gesehen - aber korrigiere mich, wenn ich mich täusche. :)

Wenn man sein Geld mit Infrastruktur-Automatisierung verdienen möchte, der Markt für Jails ist extrem klein und lausig bezahlt.

Auch gibt es erste Anzeichen, dass Docker wieder (zugunsten anderer Lösungen) zurückgehen könnte. Nützt keinem was, der hier und heute genau auf Docker gesetzt hat, sollte in dem Kontext aber trotzdem beides mal erwähnt sein.

Du meinst Lösungen wie podman, ein Drop-In-Replacement für Docker, dass bis auf die Kommandozeilenparameter auf Kompatibiltät mit Docker achtet?

Oder die Open Containers Initiative, zu der Docker auch kompatibel ist?

Welche Lösung siehst du am Horizont, die jegliches Investment an Know-How & Co. in Docker schlagartig wertlos machen könnte?
 
Er ist ja nicht der erste, der in dem Bereich alles per VM erschlagen möchte - (nicht nur) ich wollte es ja für meine Kundenprojekte genauso machen. Auch er wird die Erfahrung machen, das die VM-Zwischenschicht anstelle des direkten Container-Einsatzes im Alltag viele Nachteile bringt. VMs würde ich auf die Stellen beschränken, an denen es absolut notwendig ist.
Das mag stimmen, hängt aber sowohl von den konkreten Anforderungen als auch von der eingesetzten Hardware ab. Ausgangspunkt war, dass der OP gerne virtualisieren *will*, und es liest sich für mich nicht so, als sollte grundsätzlich Docker oder ähnliches zum Einsatz kommen. Wie gesagt, es wäre hier sicher besser, würde er selbst antworten.

Jails sind kein adäquater Ersatz für Container. Weder sind sie so leicht zu benutzen noch so flexibel, vom Ökosystem ganz zu schweigen. [..]
Jails sind Container, es sei denn man möchte die Bedeutung nach Docker neu definieren. Natürlich bietet Docker mehr, allerdings nicht viel, was man nicht auf Basis von Jails (zusammen mit ZFS) implementieren könnte, wenn man denn wollte.

Wenn man sein Geld mit Infrastruktur-Automatisierung verdienen möchte, der Markt für Jails ist extrem klein und lausig bezahlt.
Darauf wollte ich auch nicht hinaus, lediglich auf die Formulierung, die sich so liest, als könne man auf FreeBSD keine Container haben. Kann man eben doch, und das schon sehr viel länger als anderswo... die Aussage hatte also keinen Bezug zu dem, was der OP so plant.

Du meinst Lösungen wie podman, ein Drop-In-Replacement für Docker, [...]
Zum Beispiel, bzw die Tatsache, dass Kubernetes bewusst keine direkte Abhängigkeit zu Docker eingeht.
Related: https://technodrone.blogspot.com/2019/02/goodbye-docker-and-thanks-for-all-fish.html -- außerdem Ideen wie Unikernel usw...

Welche Lösung siehst du am Horizont, die jegliches Investment an Know-How & Co. in Docker schlagartig wertlos machen könnte?
Auch das war ja wirklich nicht meine Aussage. Und "zurückgehen" ist auch alles andere als "schlagartig" ...
 
Da der TE ja eher aus ideologischen Gründen einen Wechsel möchte und nicht aus praktischen wäre vielleicht ein Blick Richtung GNU/Linux-Libre einen Versuch wert.
 
VMs würde ich auf die Stellen beschränken, an denen es absolut notwendig ist.
Also die, wo man Kunden tatsächlich trennen will?

Container sind ein glorifiziertes Paketsystem und sollte nicht eingesetzt werden, wenn man auch nur den Hauch einer Anforderung nach sicherer Trennung hat.
 
Container sind ein glorifiziertes Paketsystem und sollte nicht eingesetzt werden, wenn man auch nur den Hauch einer Anforderung nach sicherer Trennung hat.
Das kann man so aber auch nicht ganz stehen lassen. Container sind definitiv etwas völlig anderes als Softwarepakete. "Klassische" Container nutzen den Host-Kernel (ja, Docker kann auch andere Sachen, virtualisierte Linux-Container auf Windows-Host und sowas ...), daher ist in der Tat die potentielle Angriffsfläche ein wenig größer als bei einem Hypervisor. Insofern passt deine Aussage, je nachdem was genau man nun unter "sicher" versteht.

Trotzdem kommst du aus beiden ohne entsprechende Schwachstelle (sei es Software oder, [*hust*, intel] Hardware, oder auch schlichter Konfigurationsfehler) nicht raus.
 
Docker, oder andere Managementtools im gleichen Ökosystem wie z.b. Podman (was ich nur sehr empfehlen kann!), sind auch für was anderes entworfen worden. Das verwende ich wenn ich Fehlertoleranz will, wenn ich Skalierbarkeit will, wenn ich Ressources flexibel zuteilen möchte. Für die Sicherheit sorgen andere Systeme drum herum, bzw. ein ein allgemein durchdachtes Konzept.
Selbst stelle ich Dockercontainer bereit als Service für Kunden, die es aus eben genannten Gründen nutzen wollen, oder aber tatsächlich als besserer Paketersatz weil ich nicht für 10 Kunden mit unterschiedlichen Systemen Installer liefern möchte.

Aber ja, ich habs auch schon als Notersatz für eine VM genommen, einfach weil kein Geld für ein größeres System bereit stand und alles ist besser als nichts.
 
Ich mache ähnliche Sachen und nutze dann immer Linux, damit kommt man gut klar. Ich könnte mir aber vorstellen, dass es schon an anderer Stelle hapern könnte - Kommunikation!

Welche Tools verwendest du dort? Ich habe lernen müssen, dass nur Google Chrome so richtig mit einigen Webanwendungen unter Linux klar kommt, z. B. einige Sachen für Videotelefonie und so.
 
OpenBSD ist wohl sehr wählerisch, was die Hardware angeht. Nvidia Karten gehen gar nicht, Intel und AMD gehen mal, mal wieder nicht. Leider war jede neue Version von OpenBSD wie eine Wundertüte und eine Verläßlichkeit im Desktop Betrieb nicht gegeben.
das löscht total ab, wollte nämlich OpenBSD für den Desktop verwenden (nicht professionel) und frage mich, ob mir der "Ausflug" von Linux (archlinux-> debian-stable -> void-linux -> wohl wieder debian stable oder manjaro) etwas bringen würde (Sicherheit, Stabilität...)
off-topic Derzeit ist void-linux installiert. Nach einem update konnte ich von lxde aus nicht mehr herunterfahren (Rechteproblem). Lösungs(versuche) für andere Linux-Versionen hatten nichts gefruchtet, daher habe ich lxde meta Paket entfernt und testweise lxqt installiert, da hatte ich dann wieder die Rechte. Lxqt wieder 'runter, lxde wieder d'rauf: wieder kein shut-down möglich. Leider ist inzwischen das Forum quasi nicht mehr existent, weil die domain void-linux.eu inzwischen jemand anders gehört und ich kann keine Fragen mehr stellen.... Daher bin ich am Überlegen, auf openbsd oder netbsd umzusteigen, mit lxde lxqt oder evtl. mate als Desktop (sandy bridge intel i7 und intel hd 3000).
 
https://sogubsys.com/openbsd-is-now-my-workstation-operating-system/

Gerade auf Twitter angezeigt bekommen. Forwarded by Peter N.M. Hansteen

Der Autor hat seinen Artikel aktualisiert und schreibt, dass er OpenBSD wieder durch Linux ersetzt hat. :o

das löscht total ab, wollte nämlich OpenBSD für den Desktop verwenden (nicht professionel) und frage mich, ob mir der "Ausflug" von Linux (archlinux-> debian-stable -> void-linux -> wohl wieder debian stable oder manjaro) etwas bringen würde (Sicherheit, Stabilität...)

Was ist dein Anwendungsprofil auf dem Desktop? Die Usability von OpenBSD lässt dort sehr zu wünschen übrig, speziell bei grafikintensiven Anwendungen. :ugly:

Für technisch versierte Nutzer fehlen unter OpenBSD ferner noch essentielle Dinge wie eine brauchbare Virtualisierung oder Container-Support.

Welche Probleme hattest du in Sachen Stabilität auf dem Desktop? Ich lande dort immer wieder bei Arch Linux, weil die Desktop-Stabilität besser ist als bei den von mir getesteten BSDs. Speziell mit Intel-iGPU (oder inzwischen auch AMD-GPUs) funktioniert es wunderbar.
 
Der Autor hat seinen Artikel aktualisiert und schreibt, dass er OpenBSD wieder durch Linux ersetzt hat. :o
Aber auch das er nach seiner OSCP Zertifizierung zu OpenBSD zurück kehren wird. Und wer schon einmal eine IT Bezogene Zertifizierung gemacht hat , weiss das man dafür die Systeme zum Lernen so nah wie möglich an den Lehrmitteln hält.
 
Aber auch das er nach seiner OSCP Zertifizierung zu OpenBSD zurück kehren wird. Und wer schon einmal eine IT Bezogene Zertifizierung gemacht hat , weiss das man dafür die Systeme zum Lernen so nah wie möglich an den Lehrmitteln hält.

Du beschreibst damit schon eines der vielen Probleme an OpenBSD auf dem Desktop: Normalerweise würde der Autor dafür einfach eine virtuelle Maschine starten - das geht aber mit OpenBSD nicht. So wird aus einer trivialen Aufgabe ein unlösbares Problem.
 
Zurück
Oben