OpenBSD 5.5 erschienen

hades

the unseen one
Puenktlich zum 01. Mai hat Philip Guenther ueber announce@ bekannt gegeben, dass OpenBSD 5.5 mit dem Titel "Wrap in Time" offiziell als neues OpenBSD-Release herausgegeben wurde.

Die Ankündigung kann in ihrer vollen Länge hier nachgelesen werden:
http://marc.info/?l=openbsd-announce&m=139895819502063&w=2

Wesentliche Neuerungen sind:
  • ein verbesserter Installer
  • Verbesserungen an pf
  • die Unterstuetzung weiterer Architekturen
  • OpenSMTPD 5.4.2
  • OpenSSH 6.6
  • ...
OpenBSD 5.5 ist bereits auf einigen der Mirrors verfügbar.

Wie immer können die Details unter http://www.openbsd.org/plus55.html nachgelesen werden. Ebenfalls wird die, wie gewohnt ausführliche, Upgrade-Anleitung unter http://openbsd.org/faq/upgrade55.html bereitgestellt.

Bei OpenBSD handelt es sich um ein freies, unixoides Betriebssystem, welches auf 4.4BSD basiert. 1994/95 wurde OpenBSD durch Theo de Raadt vom NetBSD-Projekt abgetrennt. OpenBSD wird für eine große Anzahl verschiedener Systemarchitekturen angeboten, die Schwerpunkte des System sind auf Sicherheit und Kryptographie gelegt. Anwendersoftware kann entweder über das Paketverwaltungssystem oder über ein Ports-System installiert werden.

Seit der ersten Veröffentlichung von OpenBSD, damals in Version 1.2, erscheint alle sechs Monate eine neue Version des Betriebssystems. Das System kann entweder als 3-CD-Set gekauft werden oder von einem der verschiedenen Mirrors heruntergeladen werden.

OpenBSD eignet sich aufgrund der genannten Schwerpunkte für den Einsatz als Firewalls, Gateways, etc. Hierbei kommt auch der Paketfilter (pf), der fest im System verankert ist, zum Tragen.
 
  • Like
Reaktionen: CW
Vielen Dank für die Info.

Zum Update sag ich mal so... "Des wird a Gaudi!". Respekt, dass sie in der Version 5.6 Apache und Sendmail entfernen! :)

Achtung: Bei OpenBSD 5.5 gibt es schon etliche Patches zum einspielen [1] Also aufpassen, wer die Release Version verwendet.

[1] http://www.openbsd.org/errata55.html
 
Der Release-Prozess erscheint mir immer noch obskur. Zum Release gleich mal wochenalte Fixes nachpatchen, das Release selber ist 2 Monate alt.

Dank VMs und ZFS Snapshots hab ich mir mittlerweile eine schöne Umgebung gebastelt, die mir konsistent Releases und passende Packages ausspuckt, von daher für mich verkraftbar, auch wenn das Bauen und Netbooten reinste Steinzeit sind.

Ansonsten good job wie immer!
 
Schon klar. Das erklärt mir immer noch nicht, warum der Patch für eine wochenalte Lücke nicht irgendwie noch in das Release geschummelt werden kann und stattdessen ein Release mit einer bekannten Lücke veröffentlicht wird.
 
Schon klar. Das erklärt mir immer noch nicht, warum der Patch für eine wochenalte Lücke nicht irgendwie noch in das Release geschummelt werden kann und stattdessen ein Release mit einer bekannten Lücke veröffentlicht wird.
Weil die CDs lange vorher gepresst wurden und somit RELEASE abgeschlossen ist. Sicherheitfixes gehen in -STABLE ein, dass zum Releasetag zur Verfügung steht. Es bleibt auch jedem selber überlassen, ggf. Snapshots zu installieren, falls man nicht selber bauen mag, in denen diese Dinge natürlich gefixt sind.
 
Ich glaube jetzt auch nicht, dass das Alter einer Lücke so viel ausmacht. Du willst sowieso schauen, dass alle Patches im System sind, nachdem du es installiert hast. Das ist ja ohnehin eine Gewohnheit. In den allermeisten Fällen setzt du ja dein System auch nicht genau am Tag des Release auf.

Kann verstehen, dass das Reinschummeln nicht so toll ist und oft führt das auch etwas zu Verwirrung. Klar, wenn es was ist, was es dir nicht erlaubt das System zu installieren, zu patchen oder extrem viel Aufwand auf Seiten des Admins braucht macht es wohl Sinn daran zu denken, aber wenn es eine simple Update-Prozedur ist denke ich dass so Quickfixes vielleicht eher Probleme machen und unnötig Zeit kosten. Dann müssen ja auch die Mirrors syncen, neue CDs rauskommen, etc.

Ich glaube in dem Vortrag wird auch deutlich gemacht, dass du das Release aus der Sicht des Entwicklers kurzhalten willst bzw. fast musst.

Vor ein paar Tagen machte ein Artikel die Runde, dass Google und Facebook all ihren Code in einem großen (dutzende Gigabyte) Repository hat und branches quasi verboten sind. Für mich wenig erfahrenen Entwickler brach da eine Welt zusammen, aber ich kann's verstehen. Bei so großen Projekten noch zusätzlich von jeder API verschiedene Versionen zu haben und alles abstimmen, testen und maintainen zu müssen ist wohl eine enorme Bremse. Da kann ich schon verstehen, dass vor allem wenn das Projekt groß sowohl was den Code, als auch das Team angeht, damit bestimmte Verhaltensweisen erzwingen kann und Entwickler zum Testen zwingen kann, etc. Auch wenn die Vorgangsweise eine andere ist, scheinen sich die Ziel davon grundsätzlich zu überschneiden.
 
Ärgerlich ist dabei halt nur, dass man die Patches von Hand reinpacken muss und die ganze Chose dann compilieren wenn man release/stable folgen will
 
Zurück
Oben