Ich benutze FreeBSD seit ungefähr 5 Jahren - Server / Desktop - und habe dazu tendiert, alle Gewohnheiten meines Apt-Get / Yum-Upgrades mitzunehmen (ich verwalte auch Debian / RHEL / Cent-Boxen - ich weiß, ich wissen ... sollte unabhängig von der Plattform anspruchsvoller sein). Es ist also normalerweise ein:

portsnap fetch
portsnap update
portmanager -u

Für die Häfen

Manchmal gefolgt von einem:

freebsd-update fetch
freebsd-update install

Für das System ... etc. Bereinigen Sie anschließend alle Unreinheiten ... falls sie auftreten.

Mir ist klar, dass dies eine ziemlich exzessive Art und Weise ist, Dinge ohne BSD zu tun. Was ist Ihre Philosophie für Ihre BSD-Boxen? Führen Sie ein Portaudit / eine Portversion durch - überprüfen Sie die Ausgabe und aktualisieren Sie sie (deinstallieren Sie sie ... usw.) nach sorgfältiger Überlegung?

Ich bin ziemlich neu in OpenBSD, gestehe ich. Ich sehe mich darin, den Ports-Baum zu unterstützen, das Skript "Veraltet" auszuführen und dann nur kritische Ports zu aktualisieren - aber den Kernel / die Binärdateien in Ruhe zu lassen und nur alle sechs Monate zu aktualisieren. Patchen / kompilieren / erstellen Sie den Kernel, die Binärdateien neu --- warum?

Was ist ein konservativer Ansatz für kritische Dienste (einigermaßen kritisch - das ist keine Bank oder kein Krankenhaus) an BSD-Boxen? Verwenden Sie einen ähnlichen Ansatz für Ihre Linux-Boxen? Normalerweise berühre ich den Kernel auf keinem Server, es sei denn, eine Sicherheitswarnung hat Schrecken in meine Seele geweckt.

Ja, es gibt jede Menge Dokumente und Bücher - was machen die Leute eigentlich? Vorausgesetzt, wir kennen die Grundlagen - was ist die Weisheit? Anwendungsfälle / -umgebungen und -szenarien variieren, ebenso wie die Einsätze / Interessengruppen / Benutzer. In Büchern und Manpages werden Tools und Verwendungen behandelt, es fehlt jedoch die praktische Anwendung. Empfehlen Sie ein Buch, wenn Sie eines kennen, das es behandelt!

Danke fürs Lesen!

Bubnoff

Schlussfolgerungen ~ Vielen Dank an alle, die sich die Zeit genommen haben, diesen Beitrag zu beantworten. Meine Strategie ist es nun, den Mailinglisten für beide BSDs zu folgen und die Aktualisierung selektiver und kritischer zu gestalten als in der Vergangenheit.

FreeBSD ~ Portaudit ist eine gute Antwort. Mit den Mailinglisten und sorgfältigen Audits, denke ich, wird dies hier gut funktionieren. Interessant ist die unterschiedliche Betonung der Ports zwischen OpenBSD und FreeBSD.

OpenBSD ~ folgt der Mailingliste und verwendet die Paket-Tools (pkg_info und pkg_add -u), wenn dies als kritisch erachtet wird. Upgrades: Sieht so aus, als müssten Sie mindestens einmal im Jahr ein Upgrade durchführen. Sie unterstützen das neueste Release plus eins zurück - im Moment sind es also 4.8 und 4.7.

Danke noch einmal.

Stellen Sie sicher, dass Sie Ihre installierten Ports von Zeit zu Zeit auf gefährdete Pakete prüfen: portaudit -Fda

Ich bin mir nicht sicher, ob es einen bestimmten "BSD-Weg" gibt, um solche Dinge zu tun. Es kommt darauf an zu wissen, was aktualisiert und getestet wird - generisches Sysadmin-Zeug. Glücklicherweise machen freebsd-update und portsnap das "Wissen was" ziemlich trivial.

Aber seitdem Sie nach Einzelheiten gefragt haben, waren sie alle Knoten in einem Cluster, als ich eine große Anzahl von FreeBSD-Maschinen hütete. Standalone-Maschinen würden sich nicht allzu sehr davon unterscheiden, aber ich vermute, Sie könnten diese vage "Entwicklung" für Ihre Produktionsdienstleistungen durchführen. Am Ende ist es immer eine gute Idee, separate Test- und Produktionsumgebungen zu haben.

In der Clustersituation:

• Jede Maschine hat / usr / src , / usr / obj und / usr / ports über NFS gemountet.
• Abhängig von Ihrem Budget können Sie entweder über einen Staging- / Build-Computer verfügen oder einen Clusterknoten als Staging- / Build-Knoten festlegen.
• Der Staging-Knoten hatte eine andere Kopie von / usr / ports
• Der Staging-Knoten aktualisiert src-all und ports-all jede Nacht über cvsup
• Im Falle eines notwendigen Updates würde der Staging-Knoten aus der Rotation genommen und Buildworld , Installworld und Portupgrade würden ausgeführt.
• Der Staging-Knoten würde gründlich getestet.
• / usr / ports würden auf dem NFS-Host ausgetauscht
• Jeder Clusterknoten wird unter installworld und portupgrade herausgedreht , getestet und dann wieder hineingedreht .

Dies war natürlich sowohl bei einem System- als auch bei einem Port-Update der Fall, aber die Vorgehensweise war ähnlich genug, um nur Pakete oder Systeme zu aktualisieren.

Wenn dies mit zwei Maschinen durchgeführt wird, können Sie jede als Produktion oder Bereitstellung abwechseln oder einfach die Produktion von der Bereitstellung aktualisieren.

Sie können Änderungen in den cvs-Protokollen nachverfolgen und prüfen, ob Sie bestimmte Aktualisierungen in / usr / src / UPDATING und / usr / ports / UPDATING erhalten haben , die beide automatisch von cvsup aktualisiert werden .

Wenn Sie cvsup nicht verwenden (und heutzutage gibt es dafür weniger Gründe), müssen Sie nur einen anderen Weg finden, um zu verfolgen, welche Updates Sie möchten. Sie können eine Liste der Änderungen senden, die freebsd-update an sich selbst vornehmen möchte, und die Seite mit den Sicherheitseratas im Auge behalten.

OpenBSD Update-Philosophie

Dies ist mein Ansatz zur Aktualisierung von OpenBSD

Bleiben Sie auf dem Laufenden über Sicherheitsupdates / Patches für:

• BASE (dh das Zeug, das das OpenBSD-Entwicklerteam in seinem Source-Tree pflegt)
• Pakete / Ports (dh Softwareanwendungen, die auf BASE installiert sind)

Aktualisierungsverfahren:

• Gleiche Betriebssystemversion
• Neue Betriebssystemversion

BASE

ein. Befolgen Sie die entsprechenden Mailinglisten - ich schaue mir die täglichen Zusammenfassungen von squish.net sowie die allgemeinen Anweisungen auf den Tech- und Misc-Mailinglisten an.

b. Befolgen Sie die Sicherheitsankündigungen für Unix-Websites / Mailinglisten.

c. Verwalten Sie eine lokale CVS-Kopie von cvsync

d. Erstellen Sie STABLE-Releases aus den oben genannten

Wenn Sicherheitsupdates veröffentlicht werden, bewerten wir das tatsächliche Sicherheitsproblem mit dem Profil der Computer mit dieser Version des Betriebssystems / der Sicherheitsanfälligkeit. Wenn die Sicherheitsanfälligkeit relevant ist, durchlaufen wir das "gleiche Versions-Upgrade-Verfahren".

Pakete / Ports

Es ist schwieriger, Sicherheitsupdates für Ports / Pakete im Auge zu behalten, aber wenn es kritisch genug ist, um in unserer Infrastruktur zu sein, ist es wichtig genug, um den Überblick zu behalten, ähnlich wie bei BASE.

• Nehmen Sie an der Mailingliste für die jeweilige Anwendung teil (es liegt in unserer Verantwortung, die vorgelagerten Änderungen unabhängig vom OpenBSD-Projekt im Auge zu behalten.)

• Holen Sie sich auf die Verteilerlisten von Sicherheitssitzen wie CERT, die Erkenntnisse über Schwachstellen in Apps usw. veröffentlichen.

Die Upgrade-Prozeduren

Erstellen und testen Sie Ihre Installationsprozedur offensichtlich auf separater Hardware (oder VM), bevor Sie sie auf Ihren Produktionsmaschinen ausführen. Zum Glück haben wir für viele Dinge redundante Hosts und können daher mit minimalen Ausfallzeiten von Diensten ausrollen. Da OpenBSD eine breite Palette von Hardware unterstützt, können wir Server-Geräte für unsere primären Maschinen und Desktops der unteren Preisklasse als redundante Hosts bereitstellen (oder wir erstellen nur eine temporäre Box, die während des Aktualisierungszyklus für die Hauptmaschine ausgefüllt wird).

Unsere Aktualisierungsverfahren hängen stark von der Verwendung des Ports / Packages-Systems für Nicht-BASE-Software ab. Die beiden Hosts, auf denen wir Software von der Quelle installieren, sind ein Problem bei der Aktualisierung zwischen den Versionsaktualisierungen des Betriebssystems.

Gleiches Betriebssystem-Update

Für das BASE-Betriebssystem haben wir weiterhin Erfolg damit, nur die neuen Binärdateien über die alten zu installieren. Vorzugsweise sichern wir alle Konfigurations- / Datendateien des Betriebssystems und der Anwendung, formatieren das gepatchte Betriebssystem und installieren die Pakete neu (wobei die ursprünglichen Daten erhalten bleiben).

In unseren implementierten OpenBSD-Hosts (30+) und unserer Erfahrung ist es nicht schwierig, die Konfiguration und die Daten zu sichern. Bei unseren Firewalls befinden sich alle Daten in den Konfigurations- und Protokolldateien.

Für Ports / Pakete - wo die Änderungen einfach sind, modifizieren wir unseren eigenen Port und bauen das Paket daraus. Ein aktualisierter Port vereinfacht den obigen Vorgang.

Neues Betriebssystem-Update

Zwischen den Betriebssystemversionen installieren wir alles von der Skizze.

Ich bin mir sicher, dass es genügend Dokumentation für diesen Prozess gibt, aber im Wesentlichen bauen wir eine Referenzmaschine mit der gleichen Konfiguration wie das System, das "ersetzt" werden soll. Führen Sie dieselben erforderlichen Tests durch, bevor Sie den Host bereitstellen.

Wir sichern die Konfiguration vom Referenzhost und installieren OpenBSD auf dem Produktionshost, wobei wir die "überprüfte" Konfiguration darauf wiederherstellen (und danach wieder dieselben Validierungstests ausführen).

Für OpenBSD mindestens:

• Pakete sind das Endprodukt des Ports-Systems; es sollte wenig geben, wenn es nötig ist, mit Ports herumzulaufen.
• -release und -stable sind (meistens) in der Zeit eingefroren, mit einigen Aktualisierungen von Zeit zu Zeit.
• -Current wird regelmäßig aktualisiert. Wenn Sie wirklich aktuelle Pakete benötigen, ist dies der richtige Weg.
• Bleiben Sie konsistent: -release / -stable-Systeme bleiben bei -release / -stable-Paketen ...- aktuelle Systeme führen -aktuelle Pakete aus

FAQ 15, alles über Ports und Pakete

Wenn es keine Sicherheitsprobleme oder Fehler gibt, die die Funktionalität beeinträchtigen, lassen Sie es in Ruhe. Suchen Sie alle 3-6 Monate nach Updates, damit Sie nicht zu weit zurückbleiben, aber lassen Sie die Dinge ansonsten in Ruhe.

Wenn es nicht kaputt ist, reparieren Sie es nicht.

Ich bevorzuge die portupgradeAktualisierung von Ports und tue dies nur, wenn dies unbedingt erforderlich ist , z. B. wenn eine Sicherheitslücke im Port gefunden wird oder neue Funktionen erforderlich sind.

Was das Upgrade des Systems angeht, baue ich normalerweise aus Quellen mit make buildworld. Ich hatte nie Probleme mit diesem Ansatz.