OpenBSD 6.6 erschienen

[foxit]

Hallo BSDForen.de,

Das OpenBSD Projekt hat Version 6.6 seines BSD-basierten Betriebssystems veröffentlicht, welches für seinen Sicherheitsfokus bekannt ist.

Auf der Liste der Verbesserungen befinden sich dieses mal zahlreiche Einträge. Die Unterstützung für AMD64 Maschinen mit mehr als 1023GB RAM wurde repariert. GCC wurde auf "armv7" und "i386" aus dem Basissystem entfern. Weiter gab es bei der SMP Unterstützung Verbesserungen. Dies betraf unter anderem die Syscalls für "read(2)" und "write(2)". Für AMD Fans gibt es jetzt Unterstützung für "amdgpu(4)", sowie für die Temperatursensoren bei AMD Zen CPUs. Im "IEEE802.11" Wireless Stack funktioniert das Tool "nwflag" wieder wie gewohnt. Dies war seit der Version OpenBSD 6.4 defekt. Allgemein gab es viele Verbesserungen am Netzwerk Stack wie z.B. die Unterstützung von SFP, SFP+ im Kommando "ifconfig". Im "arm64" Umfeld kann die Cortex-A65 CPU jetzt genutzt werden. Als vielleicht wichtigste Neuerung wurde "sysupgrade(8)" eingeführt, mit dem OpenBSD unbeaufsichtigt aktualisiert werden kann.

OpenBSD 6.6 kommt unter anderem mit neuen Version von OpenSSH 8.1, LibreSSL 3.0.2, OpenSMTPD 6.6 daher.

Die kompletten Änderungen findet ihr wie immer in den Release Notes: [1] oder detaillierter im Changelog [2].
Für ein Update von OpenBSD 6.5 gibt es, wie immer einen Upgrade Guide [3].

Viel Spass mit OpenBSD 6.6

[1] https://www.openbsd.org/66.html
[2] https://www.openbsd.org/plus66.html
[3] https://www.openbsd.org/faq/upgrade66.html

 

[Columbo0815]

Hier hat sysupgrade sehr gut funktioniert. Allerdings frage ich mich, warum sysupgrade (derzeit?) nicht die Möglichkeit bietet, dass auch die nicht mehr erforderlichen Dateien automatisch gelöscht werden...

 

[CommanderZed]

Habs auch schon auf meinen vorkriegs-zweitnotebook getestet, ist wunderbar durchgelaufen.
(Allerdings hab ich da noch einen Grafikbug seit dem Update, da mach ich u.U. nochmal nen Thread auf.)

Das mit den löschen der Dateien hätte ich allerdings auch nett gefunden, villeicht wollte man ja noch luft nach oben für ein Update lassen

 

[double-p]

Das nicht-loeschen ermoeglicht, dass gerade ports/packages auch nach dem reboot noch laufen.

 

[Columbo0815]

Das nicht-loeschen ermoeglicht, dass gerade ports/packages auch nach dem reboot noch laufen.

Deswegen die Idee, dass die Möglichkeit angeboten wird. Nachdem ich sysupgrade ausgeführt habe, meine Packages auf die neue Version hochgezogen habe, führe ich ein "sysupgrade delete-old" bzw. "sysupgrade delete-old-libs" aus.

 

[SierraX]

Deswegen die Idee, dass die Möglichkeit angeboten wird. Nachdem ich sysupgrade ausgeführt habe, meine Packages auf die neue Version hochgezogen habe, führe ich ein "sysupgrade delete-old" bzw. "sysupgrade delete-old-libs" aus.

Feel free ...
Sysupgrade macht nicht viel anderes als das, was man auch selbst bei einem manuellen Upgrade ohne install kernel durchführt:
tar's entpacken... tar löscht grundsätzlich auch nichts sondern überschreibt und fügt hinzu...
Und ich halte die Hürde für zu niedrig, wenn das was unter Files to remove steht einfach durch ein Script ersetzen würde... Ich halte es für wahrscheinlicher das etwas Kaputt geht wenn sysupgrade einfach libs löschen würde weil sie vom Grundsystem nicht mehr benötigt werden und dann irgend ein obskures Programm das man in irgendeinem kritischen Shellscript verarbeitet hat auf einmal nicht mehr tut.
Das war oder ist ja schon bei Linux absoluter Mist... Wenn irgendwelchen Depends deinstalliert werden, bloss weil man aus seinem Küchentisch Programm kein Paket gemacht und in den Paketmanager gepackt hat.

 

[medV2]

Ich verwende OpenBSD nicht produtiv allerdings hab ich mi das mal angesehen, den manuellen Updateprozess bei OpenBSD fand ich immer sehr abschreckend (vorallem in Verbindung mit dem kurzen Supportzeitraum).
Was mir aufgefallen ist, dass leider immer alle Sets installiert werden, nicht nur jene, die vorhanden sind. Somit habe ich nach dem Upgrade Müll auf dem Server, den ich nicht brauche wie x* oder games. Soweit ich das gesehen habe wird man das nur händisch los, wenn man die Files aus den entsprechenden .txzs manuell löscht.

 

[CommanderZed]

Das entfernen von teilen des Basissystem wird explizit vom OpenBSD Team nicht empfohlen.

Da das Basisystem an sich auch recht wenig Plattenplatz braucht gibts da auch kaum einen grund zu.

Der "vorherige" Updateprozess war ja auch schon recht einfach ... bsd.neue.version.rd runterladen und booten, einige male enter Drücken, reboot.

Das "anschließende" ist ja geblieben, pkg_add -u und die update-notes durchgehen, meist ein bisschen copy-n-pasten um veraltete Dateien zu löschen -> Fertig. Je nach Rechner ist das in deutlich unter 10 Minuten erledigt, selbst auf meinem alten Thinkpad X31 (Pentium 4 mit pata-hdd),

 

[Columbo0815]

Feel free ...

Aktuell wird mir die Möglichkeit nicht geboten.

Sysupgrade macht nicht viel anderes als das, was man auch selbst bei einem manuellen Upgrade ohne install kernel durchführt:
tar's entpacken... tar löscht grundsätzlich auch nichts sondern überschreibt und fügt hinzu...

Absolut. Findest du nicht, dass sysupgrade deutlich bequemer ist?

Und ich halte die Hürde für zu niedrig, wenn das was unter Files to remove steht einfach durch ein Script ersetzen würde...

Wenn ich dich richtig verstehe, meinst du damit "für zu niedrig, als das man das in sysupgrade einbaut"? Fände ich schade. Denn es erleichtert mE die Arbeit eines Admins deutlich. Gerade weil sie niedrig ist, fände ich es nett, wenn OpenBSD sagt "sysupgrade delete-old" bieten wir an. Darf (aber muss nicht) genutzt werden.

Ich halte es für wahrscheinlicher das etwas Kaputt geht wenn sysupgrade einfach libs löschen würde weil sie vom Grundsystem nicht mehr benötigt werden und dann irgend ein obskures Programm das man in irgendeinem kritischen Shellscript verarbeitet hat auf einmal nicht mehr tut.

Bin ich bei dir. Deswegen muss so etwas optional angeboten werden.

Ich glaube aber, dass das jetzt zu sehr OT wird. Ich finde es interessant, deswegen gerne weiter per PN.

 

[Azazyel]

Ich halte es für wahrscheinlicher das etwas Kaputt geht wenn sysupgrade einfach libs löschen würde weil sie vom Grundsystem nicht mehr benötigt werden und dann irgend ein obskures Programm das man in irgendeinem kritischen Shellscript verarbeitet hat auf einmal nicht mehr tut.

Für kritische Shellscripte stellt man auch per Configuration Management sicher, dass alle Voraussetzungen vorhanden sind. Ansonsten ist das Shellscript entweder nicht kritisch oder der Admin braucht noch etwas Nachhilfe.

Das war oder ist ja schon bei Linux absoluter Mist... Wenn irgendwelchen Depends deinstalliert werden, bloss weil man aus seinem Küchentisch Programm kein Paket gemacht und in den Paketmanager gepackt hat.

Die andere Variante - man lässt einfach alle obsoleten Dependencies installiert - finde ich als Voreinstellung persönlich schlimmer. Zumal man bei allen mir vertrauten Linux-Paketmanager per --nodeps o.ä. Parametern die Entfernung der Dependencies unterbinden kann.

Ansonsten gibt es unter Linux mit Flatpak, Containern und Konsorten schon ausreichend Distro-unabhängige Lösungen für das Problem.

Wenn ich dich richtig verstehe, meinst du damit "für zu niedrig, als das man das in sysupgrade einbaut"? Fände ich schade. Denn es erleichtert mE die Arbeit eines Admins deutlich. Gerade weil sie niedrig ist, fände ich es nett, wenn OpenBSD sagt "sysupgrade delete-old" bieten wir an. Darf (aber muss nicht) genutzt werden.

Geduld. OpenBSD strotzt nicht gerade vor Manpower, das kommt bestimmt in einer der nächsten Versionen...

 

[double-p]

eben.. sysupgrade ist sehr neu und natuerlich kann man das "toller" machen. Wie lange wurde nach den unterschiedlichen update/patch Pfaden geschrien .. jetzt gibt es ein paar und zack.. "nicht gut genug fuer meinen spielplatz"

 

[berni51]

Installation und Upgrades fand ich bei OpenBSD schon lange sehr gut - einfach, nachvollziehbar, sicher. Jetzt mit sysupgrade ist es nochmal etwas netter geworden. Hat auch bei mir auf 4 Maschinen einwandfrei funktioniert. Nur auf dem letzten 32bit-Rechner gabs Probleme. Da wurde schon beim letzten syspatch kein sysupgrade installiert, obwohl das eigentlich passieren sollte. Also wie gewohnt über die bsd.rd upgraden - und dabei gab es wohl ein bisschen missmatch. Jedenfalls ist der Prozess mehrfach hängen geblieben. Hat mich einen halben Tag gekostet, alles wieder zu richten. Jetzt hat er jedenfalls auch 6.6 mit sysupgrade.

 

[SierraX]

@medV2 als das in die Snapshots gekommen ist hatte ich mal vorsichtig wegen einem Configfile nachgefragt... man glaubt nicht wie ich deswegen niedergeschrien wurde...

Aktuell wird mir die Möglichkeit nicht geboten.
Absolut. Findest du nicht, dass sysupgrade deutlich bequemer ist?

Das war nicht mein Punkt... sondern das es aus den Tarfiles garkein deletefile generieren kann ... selbst wenn es das wollte.

Wenn ich dich richtig verstehe, meinst du damit "für zu niedrig, als das man das in sysupgrade einbaut"? Fände ich schade. Denn es erleichtert mE die Arbeit eines Admins deutlich. Gerade weil sie niedrig ist, fände ich es nett, wenn OpenBSD sagt "sysupgrade delete-old" bieten wir an. Darf (aber muss nicht) genutzt werden.

Nein mit zu niedrig meine ich dass der User/Admin zu wenig nachdenken muss (und wird) ob er sich ggf über die Delete-vorgabe hinwegsetzt und dann in den Mailinglisten rumheult dass was verschwunden ist, was er noch gebraucht hätte.

 

[medV2]

Das entfernen von teilen des Basissystem wird explizit vom OpenBSD Team nicht empfohlen.

Da das Basisystem an sich auch recht wenig Plattenplatz braucht gibts da auch kaum einen grund zu.

Der "vorherige" Updateprozess war ja auch schon recht einfach ... bsd.neue.version.rd runterladen und booten, einige male enter Drücken, reboot.

Das "anschließende" ist ja geblieben, pkg_add -u und die update-notes durchgehen, meist ein bisschen copy-n-pasten um veraltete Dateien zu löschen -> Fertig. Je nach Rechner ist das in deutlich unter 10 Minuten erledigt, selbst auf meinem alten Thinkpad X31 (Pentium 4 mit pata-hdd),

Es geht um dinge wie X11 oder Games, für mich ist das bei einem ServerOS nicht "basis". Vorallem in einer Zeit in der der Trend zu immer schlankeren Images geht. Zudem kann ich bei einer Neuinstallation ja auch auswählen, welche Teile vom System ich installieren will und was nicht. Wäre doch sicher kein aufwand diese Einstellung auf den Updateprozess zu übertragen.

Was den alten Updateprozess betrifft - es ging mir nicht um die komplexität sondern die Umständlichkeit. Ich muss viel manuel machen und hab dabei lange kein laufendes System. Man stelle sich das mal in ner Umgebung mit 50+ Servern vor. Und dass alle 6 Monate ..

 

[Columbo0815]

Das entfernen von teilen des Basissystem wird explizit vom OpenBSD Team nicht empfohlen.

Ist das noch aktuell? Im Ugpradeleitfaden ist davon nichts zu lesen.

Das "anschließende" ist ja geblieben, pkg_add -u und die update-notes durchgehen, meist ein bisschen copy-n-pasten um veraltete Dateien zu löschen -> Fertig. Je nach Rechner ist das in deutlich unter 10 Minuten erledigt, selbst auf meinem alten Thinkpad X31 (Pentium 4 mit pata-hdd),

Genau darum geht es mir. @medV2 trifft es auch ziemlich, was ich sagen will. Copy & paste ist umständlich. Das OpenBSD-Team stellt ja die Schritte ohnehin zusammen (nur die können es auch wissen). Das kann ich nun in eine Dokumentation einbauen (wie es getan wird) oder/und in ein Script, das tausenden Admins die Arbeit erleichtert. @double-p hat aber ein nachvollziehbares Argument geliefert. Die Manpower.

Das war nicht mein Punkt... sondern das es aus den Tarfiles garkein deletefile generieren kann ... selbst wenn es das wollte.

Das ist klar. Ich habe unterstellt, dass das manuell gemacht wird.

Kurzum: Ich freue mich über sysupgrade. Es ist wie syspatch eine geniale Erweiterung. Ich bin gespannt, was noch alles kommt.

 

[Azazyel]

Was den alten Updateprozess betrifft - es ging mir nicht um die komplexität sondern die Umständlichkeit. Ich muss viel manuel machen und hab dabei lange kein laufendes System. Man stelle sich das mal in ner Umgebung mit 50+ Servern vor. Und dass alle 6 Monate ..

Bei 50+ Servern aktualisiert niemand mehr von Hand.

Ein neues OS-Release heißt: Konfiguration in Git anpassen und via Packer o.ä. alle VM-Images neu bauen. Die Konfiguration ist sowieso in Ansible o.ä. hinterlegt und läuft automatisch ab.

Nach etwaigen Konfigurationsanpassungen und erfolgreichem Test aktualisiert man per Rolling Release nach und nach alle virtuellen Maschinen, bis nichts mehr mit der alten OS-Version läuft.

Bei der Bestückung physikalischer Server ist das Prinzip ähnlich, nur mit streckenweise anderen Tools.

 

[medV2]

Bei 50+ Servern aktualisiert niemand mehr von Hand.

Ein neues OS-Release heißt: Konfiguration in Git anpassen und via Packer o.ä. alle VM-Images neu bauen. Die Konfiguration ist sowieso in Ansible o.ä. hinterlegt und läuft automatisch ab.

Nach etwaigen Konfigurationsanpassungen und erfolgreichem Test aktualisiert man per Rolling Release nach und nach alle virtuellen Maschinen, bis nichts mehr mit der alten OS-Version läuft.

Bei der Bestückung physikalischer Server ist das Prinzip ähnlich, nur mit streckenweise anderen Tools.

Und mach genau diesen Workflow einmal im halben Jahr bei OpenBSD und vergleiche den Aufwand mit allen 5 Jahren bei FreeBSD oder einer beliebigen Linuxdistri.
Ich weiß bei Ansible und Co funktioniert immer alles ganz automatisch, aber in der Praxis muss man halt doch oft Hand anlegen bei den Playbooks und sonstigen Stellschrauben.

Zudem hat man das nicht immer in der Hand, wir haben viele Kunden die halt auch gern selbst was herumpfuschen auf den Servern, erklärt mal dem 50 Jähren IT Leiter der in der großen Firma auf seine Rente wartet was von Ansible und Co.

Praksis ist halt was andres als Theorie in schönen Whitepapers der Toolverkäufer.

 

[Azazyel]

Und mach genau diesen Workflow einmal im halben Jahr bei OpenBSD und vergleiche den Aufwand mit allen 5 Jahren bei FreeBSD oder einer beliebigen Linuxdistri.

Kommt auf den Automatisierungsgrad der Tests an. OpenBSD hat für den Produktionseinsatz schon (zu) kurze Supportzyklen.

Ich weiß bei Ansible und Co funktioniert immer alles ganz automatisch, aber in der Praxis muss man halt doch oft Hand anlegen bei den Playbooks und sonstigen Stellschrauben.

Das lässt sich natürlich bei Änderungen des Unterbaus in Form von neuen OS-Releases nicht (immer) vermeiden.

Zudem hat man das nicht immer in der Hand, wir haben viele Kunden die halt auch gern selbst was herumpfuschen auf den Servern, erklärt mal dem 50 Jähren IT Leiter der in der großen Firma auf seine Rente wartet was von Ansible und Co.

Wenn man es den Kunden voll in Rechnung stellen kann, dann immer her mit den manuellen Upgrades im 6-Monatstakt. Die Lizenz zum Gelddrucken.

Gegen ungewünschte manuelle Änderungen hilft im Zweifelsfalle ein automatisches Recycling der VMs nach SSH-Login oder nächtliches Überbügeln der Konfiguration. Lernen durch Schmerzen.

Praksis ist halt was andres als Theorie in schönen Whitepapers der Toolverkäufer.

Ich habe mehr als einen Kunden, der das beschriebene Verfahren so in Produktion fährt.

Ansonsten gilt: love it, change it or leave it. Admins mit einem Faible für Automatisierung werden aktuell mit Jobangeboten überhäuft.

 

[SierraX]

Und mach genau diesen Workflow einmal im halben Jahr bei OpenBSD und vergleiche den Aufwand mit allen 5 Jahren bei FreeBSD oder einer beliebigen Linuxdistri.
Ich weiß bei Ansible und Co funktioniert immer alles ganz automatisch, aber in der Praxis muss man halt doch oft Hand anlegen bei den Playbooks und sonstigen Stellschrauben.

Zudem hat man das nicht immer in der Hand, wir haben viele Kunden die halt auch gern selbst was herumpfuschen auf den Servern, erklärt mal dem 50 Jähren IT Leiter der in der großen Firma auf seine Rente wartet was von Ansible und Co.

Praksis ist halt was andres als Theorie in schönen Whitepapers der Toolverkäufer.

Ganz Automatisch funktioniert es nicht das ist schon klar... sonst bräuchte man ja gleich garkeine Admins mehr... Ansible und Co sollen und können aber trotzdem eine vereinfachung sein...
Automatisiert werden rein die wiederkehrenden Aufgaben. Dabei ist es unerheblich, ob sie wiederkehrend wegen Zeit oder wegen Anzahl ist.

Gerade der Manuelle Upgrade Prozess war aber mal SOWAS von geeignet mit Ansible zu automatisieren...
Es wird seit Jahren der Kernel immer gleich ausgetauscht... reboot immer gleich umbenannt ... die TAR-Balls immer in der gleichen Reihenfolge entpackt und nur Base muss am Schluss sein. Es wird immer ein reboot gemacht ... immer ein Makedevice ausgeführt...
Sysmerge ist ein fall für sich wird aber wenn man die anderen Deploys automatisiert auch garnicht benötigt.
Die Sache ist nur ... es muss halt jemand was schreiben dafür... und jetzt ist's dafür eigentlich zu spät... so ein sysupgrade ist einfacher... aber auch einfacher über Ansible anzusteuern.
Ausserdem... wen der Kunde sagt Upgrade... bleibt es doch wohl trotzdem einem selbst überlassen ob und wie man sich die Arbeit vereinfacht... Scripte, Shortcuts, xdotool, Orchestration (solange man an den laufenden Systemen nichts schwerwiegendes verändern muss)... wer sich die Arbeit nicht leichter macht ist selbst schuld und hat ggf. den Beruf verfehlt.

 

[SierraX]

Ansonsten gilt: love it, change it or leave it. Admins mit einem Faible für Automatisierung werden aktuell mit Jobangeboten überhäuft.

Ich hatte vor etwas mehr als 6 Jahren ein Jobinterview bei Avira, in dem relativ schnell klar wurde, dass die mehr wollten als ich damals bieten konnte... Auf meine Frage womit ich mich beschäftigen solle um mich für andere Firmen attraktiver zu machen fielen als erstes die Begriffe: Puppet, Chef und Salt

 

[berni51]

Ich möchte noch mal mein Problem mit 6.6 (i386) ansprechen:
- syspatch hatte kein sysupgrade eingespielt, daher wie gewohnt manuell von 6.5 auf 6.6 upgegraded
- packages wurden geholt und installiert, nodes erstellt, aber beim "Relinking to create unique kernel" hing die Maschine fest: Der Prozess wurde nie abgeschlossen, es gab aber auch keine Fehlermeldung. Nach zig Stunden hab ich dann die Notbremse gezogen.
- danach hat die Maschine gebootet und ist gelaufen. Allerdings wird jetzt die LAN Schnittstelle zwar erkannt, sie funktioniert aber nicht: no carrier. Der D-Link wlan stick dagegen tuts.
- beim shutdown kommt nun jedes mal die Meldung "reorder kernel: failed". Ein Blick in die relink.log sagt mir:
Parse error in /usr/share/relink/kernel/GENERIC: Need an operator in '^A' (Makefile: 2649)
Parse error: Need an operator in ' ' (Makefile: 2649)
Parse error: Need an operator in 'o' (Makefile: 2649)

In Zeile 2649 des Makefile steht:
lm78_i2c.o: $S/dev/i2c/lm78_i2c.c

Naja, und damit kann ich leider überhaupt nix anfangen.
Die Maschinen mit 6.6 (amd64) dagegen machen keine Probleme, da klappt alles.
Hat jemand einen Tipp für mich?

Hab jetzt 4 mal die manuelle Installation wiederholt, aber das Problem beim Relink tritt jedes mal auf, absolut reproduzierbar.
Die Partitionen sind auch nicht voll, sondern nur mit 2 ... maximal 13% genutzt.
Mit 6.5 ist die Maschine vorher einwandfrei gelaufen.

Ratlos im Vogelsberg
Berni

 

[mark05]

hi

mal manuel ein sha256 -h /var/db/kernel.SHA256 /bsd

gemacht , und dann rebootet ?


holger

 

[berni51]

Ja, hab ich schon gemacht, hat aber nichts bewirkt.

Berni