[3.4 -> 3.5] | [3.5 -> 3.6] | [3.6 -> 3.7] | [3.7 -> 3.8] | [3.9 -> 4.0] | [FAQ-Index]

Upgradeanleitung: 3.8 auf 3.9

Hinweis: Upgrades werden nur von einem Release zum direkt darauf folgenden Release unterstützt. Überspringe keine Releases.

Es wird dringend dazu geraten, diesen Prozess zu lesen und voll und ganz zu verstehen, bevor du ihn durchführst. Wenn du das hier beschriebene auf einer wichtigen oder physikalisch entfernten Maschine machst, solltest du diesen Prozess erst auf einer identischen lokalen Maschinen versuchen, um sicherzustellen, dass alles funktioniert, bevor du dich an die wichtige oder entfernte Maschine wagst.

Upgrading ist ein bequemer Weg, um dein OpenBSD-System auf die aktuellste Version zu bringen. Jedoch sind die Ergebnisse nicht beabsichtigt, genau so zu sein wie eine Installation, bei der alles gelöscht und wieder aufgespielt wird. Insbesondere alte Bibliotheksdateien werden beim Upgradeprozess nicht deinstalliert, da sie von alten Applikationen, die vielleicht später noch aktualisiert werden, noch benötigt werden könnten. Wenn du WIRKLICH all diese alten Dateien loswerden möchtest, wärst du mit einer völligen Neuinstallation vermutlich besser dran.

Inhaltsverzeichnis:

Vor dem Upgrade
Der Upgradeprozess
Letzte Schritte

Vor dem Upgrade

Wenn sich in deiner Maschine eine PCI-Netzwerkkarte befindet, die den le(4)-Treiber benötigt, wird sie nun sehr wahrscheinlich vom pcn(4)-Treiber verwaltet. Kopiere VOR dem Upgrade deine /etc/hostname.le*-Datei(en) mit dem jeweils passenden /etc/hostname.pcn*-Namen, da du sonst während und nach dem Upgradeprozess kein funktionierendes Netzwerk haben wirst.

Aufgrund zusätzlicher Debuggingsymbole sind die Bibliotheksdateien erheblich größer geworden. Auf der i386-Plattform zum Beispiel nahm der benötigte Platz des /usr/lib-Verzeichnisses von 47,7 MB (3.8) auf 209 MB (3.9) zu. Stelle sicher, dass du genügend freien Speicher hast, bevor du mit dem Upgrade beginnst.

Überprüfe, ob du irgendwelche Modifikationen an deinem Kernel vorgenommen hast. Zum Beispiel könntest du dein Netzwerkdevice mittels config(8) geändert haben, um eine nicht standardmäßige Einstellung verwenden zu können. Schreib die Änderungen auf, sodass du sie ebenfalls auf den neuen 3.9-Kernel anwenden kannst.

pfsync(4) verwendet nun ein neues Format - »keep state« funktioniert zwischen 3.8- und 3.9-Systemen nicht. Alle Verbindungen von nicht zutreffenden Systemen werden beendet, wenn du den Master umstellst, da States zwischen den Systemen nicht ausgetauscht werden. Du kannst die Auswirkung hiervon minimieren, indem du erst deine Backupsysteme upgradest, sodass nur ein einziges Mal aktive States verloren gehen.

Benutzer von carp(4), die einem einzelnen carp(4)-Interface mehr als eine Adresse zugewiesen haben, werden ein weiteres Problem während dem Upgrade feststellen: Interfaces werden nun nach Adresse sortiert, sodass es nicht mehr so wichtig wie bisher ist, Aliases in der exakt gleichen Reihenfolge zu haben. Das heißt jedoch, dass es eventuell Probleme zwischen alten und neuen Systemen geben wird. Du kannst die Aliases auf den alten Systemen notfalls manuell sortieren, wenn du dieses mögliche Problem auf jeden Fall umgehen willst.

ftp-proxy(8) wurde geändert (mehr Details weiter unten), deine pf.conf(5)-Datei muss eventuell aktualisiert werden.

ancontrol(8) wurde mit einer weiteren Funktion in ifconfig(8) ersetzt. Dies könnte Auswirkungen darauf haben, wie du deine Drahtlosinterfaces konfigurierst.

Der Upgradeprozess

Mit Installationsmedium upgraden

Der einfachste und sicherste Weg, um von Binärdateien aus upzugraden, ist von einem Installationsmedium zu booten und den Upgradeschritten zu folgen, welche sich dem Installationprozess sehr ähneln. Schließe danach das Upgrade ab, indem du die letzten Schritte ausführst, die weiter unten beschrieben werden.

Ohne Installationsmedium upgraden

Diese Vorgehensweise wird NICHT empfohlen. Verwende die Installationsmedium-Methode, wenn es irgendwie möglich ist!

Manchmal muss man ein Upgrade einer Maschine durchführen, wenn man nicht auf einfache Weise den normalen Upgradeprozess durchführen kann. Man kann dies normalerweise durchführen, indem man vorsichtig einen Prozess befolgt, der einem source-basierten Upgrade sehr ähnlich ist:

Lege die Installationsdateien in einem »guten« Verzeichnis ab. Stelle sicher, dass du genügend freien Platz hast!
Deaktivere das Starten aller »unsicheren« Applikationen beim Booten: Es wird Momente während der Installation geben, in denen zwar PF nicht geladen werden kann, deine Applikationen aber eventuell normal gestartet und ausgeführt werden. Jede Applikation, deren Sicherheit von PF abhängig ist, sollte daher zuvor deaktiviert werden; sie sollte auch erst erneut aktiviert werden, wenn die Funktionsweise von PF nach dem Upgrade sichergestellt worden ist. Es mag weitere Applikationen geben, die du während dem Upgradeprozess nicht ausführen möchtest - beende und deaktiviere sie ebenfalls.
Überprüfe den Kernel: Obwohl die meisten Leute diesen Schritt überspringen können, kann es sein, dass du den 3.8-Kernel angepasst hast. Wenn das der Fall ist, dann wirst du sehr wahrscheinlich das gleiche mit dem 3.9-Kernel machen müssen. Insbesondere wenn du ein Upgrade mit einem Remotesystem durchführst, ist jetzt der richtige Zeitpunkt gekommen, um sicherzustellen, dass der neue Kernel geladen werden kann, wenn du das System neustartest. Falls irgendwelche Änderungen am Kernel gemacht werden müssen, ist es am sichersten, das ganze auf einem lokalen 3.9-System zu machen. Dabei kann es sich um so einfache Dinge wie eine Änderung eines bestimmtes Devices mittels config(8) handeln, doch könnte es genausogut bedeuten, dass du den Kernel neuerzeugen musst, da sich eine von dir benötigte Option nicht im GENERIC-Kernel befindet. Lies bitte FAQ 5 - Das System aus dem Quelltext erzeugen, bevor du in Erwägung ziehst, deinen Kernel neu zu erzeugen.
Installiere neue(n) Kernel
export RELEASEPATH=/DeinPfad cd ${RELEASEPATH} rm /obsd ; ln /bsd /obsd && cp bsd /nbsd && mv /nbsd /bsd cp bsd.rd bsd.mp /
Achte auf die zusätzlichen Schritte, um den primären Kernel zu kopieren: Diese werden durchgeführt, um zu gewährleisten, dass immer eine funktionsfähige Kopie des Kernels auf der Platte ist, sodass das System booten kann, falls ein Stromausfall oder ein Systemabsturz zu sehr ungüstiger Zeit eintreten.
Installiere neue /etc/firmware-Dateien: Aus der Tatsache heraus, dass einige hochgeladene »firmware«-Teile vom Kernel in Dateien verschoben wurden, die sich im /etc/firmware-Verzeichnis befinden, könnten einige wenige Treiber nicht korrekt geladen werden, wenn keine hochgeladene Firmwaredatei zur Verfügung steht, wenn der neue Kernel bootet. Dies wird nur Benutzer einiger weniger Geräte betreffen, obwohl alle Benutzer diesen Schritt ohne weiterer Beeinträchtigung ausführen können. Um die Firmwaredateien aus base39.tgz zu entpacken, verwende das Folgende als root vor dem nächsten Schritt:
cd / tar xzpf ${RELEASEPATH}/base39.tgz "*etc/firmware/*"
Starte mit dem neuen Kernel neu: Es mag verführerisch sein, diesen Schritt zu überspringen, aber er sollte nun durchgeführt werden, da - wie üblich - der neue Kernel die alten Userlandapplikationen ausführen wird (wie zum Beispiel den bald wichtigen reboot!), ein neues Userland aber häufig NICHT mit einem alten Kernel zusammen funktioniert.
Installiere neue Userlandapplikationen Installiere noch NICHT etc39.tgz und xetc39.tgz, da sie deine aktuellen Konfigurationsdateien überschreiben würden!
export RELEASEPATH=/yourpath cd / tar xzpf ${RELEASEPATH}/base39.tgz tar xzpf ${RELEASEPATH}/comp39.tgz tar xzpf ${RELEASEPATH}/game39.tgz tar xzpf ${RELEASEPATH}/man39.tgz tar xzpf ${RELEASEPATH}/misc39.tgz tar xzpf ${RELEASEPATH}/xbase39.tgz tar xzpf ${RELEASEPATH}/xfont39.tgz tar xzpf ${RELEASEPATH}/xserv39.tgz tar xzpf ${RELEASEPATH}/xshare39.tgz
Hinweis: Nicht alle Dateisets müssen für alle Einsatzgebiete installiert werden, wenn du jedoch ein Dateiset ursprünglich installiert hast, solltest du es jetzt doch mit einem neuen Dateiset upgraden.
Hinweis: Die Dateien in /etc werden weiter unten getrennt behandelt, sodass etc39.tgz und xetc39.tgz an dieser Stelle NICHT entpackt werden.
Upgrade /dev. Die neue MAKEDEV-Datei wird durch die Installation von base39.tgz nach /dev kopiert, sodass du einfach nur Folgendes machen musst:
cd /dev ./MAKEDEV all
Upgrade /etc wie unten beschrieben.
Starte neu

Während des Prozesses könnte sendmail(8) viele Fehlermeldungen wie diese erzeugen:


    Nov 1 12:47:05 puffy sm-mta[16733]: filesys_update failed: No such file or dire
    ctory, fs=., avail=-1, blocksize=380204

Diese Nachrichten können unbesorgt ignoriert werden, du könntest aber auch sendmail(8) während dem Upgradeprozess beenden.

Letzte Schritte

1. `/etc` upgraden

Falls du nun unter Verwendung eines Installationsmediums (und dadurch einen formalen Upgradeprozess) oder aber ein Binärupdate im laufenden System, gibt es einige Schritte, die manuell durchgeführt werden müssen.

1.1. Neue Benutzer und Gruppen

keine neuen Benutzer oder Gruppen

1.2. Funktionsänderungen

ftp-proxy ftp-proxy(8) wurde mit dem zuvor pftpx genannten Proxy ausgetauscht. Der neue ftp-proxy läuft als Daemon und wird daher nicht von inetd.conf(5) aus aufgerufen, wie es bisher der Fall war. Du musst sowohl /etc/inetd.conf anpassen, damit ftp-proxy(8) nicht länger aufgerufen wird, als auch /etc/rc.conf und /etc/rc, damit der neue Proxy gestartet wird. Ändere rc.conf oder rc.conf.local zum Beispiel wie folgt, um das neue Programm aufzurufen:
echo 'ftpproxy_flags=""' >> /etc/rc.conf.local

Der neue Proxy verwendet Anker, um Datenverbindungen zuzulassen. Das bedeutet, dass deine bestehende /etc/pf.conf dementsprechend angepasst werden muss. In der NAT-Sektion musst du Folgendes einfügen:
nat-anchor "ftp-proxy/*" rdr-anchor "ftp-proxy/*"
Diese Einträge sind zwingend, selbst wenn du sonst kein NAT verwendest. Die folgende Regel, die vermutlich schon für den alten ftp-proxy angelegt wurde, muss bleiben:
rdr pass on $int_if proto tcp from $lan to any port 21 -> \ 127.0.0.1 port 8021
In der Regelsektion wird Folgendes benötigt:
anchor "ftp-proxy/*"
Regeln, die FTP-Kontrollverbindungen (Zielport 21/tcp) für den Proxy durchlassen, müssen bleiben. Regeln, die FTP-Datenverbindungen durchlassen, werden nicht länger benötigt. Diese Regeln könnten »user proxy« oder »to port > 49151« enthalten. Es wurde darauf geachtet, dass die Kommandozeilenoptionen so ähnlich wie möglich blieben, doch einige unterscheiden sich. Wirf einen Blick auf die ftp-proxy(8)-Manualseite.
Ein Spezialfall sollte noch erwähnt werden: Wenn du alte Clients hast, die auf Datenverbindungen im aktiven Modus angewiesen sind (diese verwenden 20/tcp als Quellport), musst du die Option »-r« verwenden (beim alten Proxy »-u root«).
Führe ftp-proxy mit »-d -D7« aus, wenn du Probleme feststellst und herausfinden möchtest, wo der Fehler liegt.

1.3. `/etc`-Dateiänderungen

Du solltest die etc39.tgz-Dateien in ein temporäres Verzeichnis entpacken:

cd /tmp tar xzpf ${RELEASEPATH}/etc39.tgz

Dateien, die ordnungsgemäß von etc39.tgz »so wie sie sind« kopiert werden können:

daily ipsec.conf magic monthly netstart rc security services weekly mtree/*

Bedenke, dass es möglich IST, all diese Dateien lokal zu modifizieren. Solltest du sie also modifiziert haben, musst du sie manuell anpassen. Hier sind Copy&Paste-Zeilen, um diese Dateien zu kopieren, angenommen, dass du etc39.tgz in dem zuvor empfohlenen Verzeichnis abgelegt hast:

cd /tmp/etc cp daily ipsec.conf magic monthly netstart rc security services weekly /etc cp mtree/* /etc/mtree/

Dateien, die per Hand angepasst werden müssen, sodass alle lokalen Änderungen beibehalten werden (falls sie vom Original abweichen) - ansonsten kannst du sie auch einfach kopieren:

changelist inetd.conf lynx.cfg rc.conf ssh/ssh_config ssh/sshd_config sysctl.conf

Die Änderungen dieser Dateien befinden sich in dieser Patchdatei. Du kannst versuchen, sie zu verwenden, indem du das Folgende als root ausführst:

cd / patch -C -p0 < upgrade39.patch

Hiermit wird geprüft, wie gut der Patch sich in DEIN System einbinden lässt. Um ihn tatsächlich einzubinden, lass die Option -C weg. Beachte, dass es sehr wahrscheinlich ist, dass wenn du diese Dateien modifiziert, nicht immer auf dem aktuellsten Stand gehalten hast oder von einem Snapshot von 3.8 aus upgradest, dieser Patch nicht richtig angewandt werden kann. In diesen Fällen musst du die Änderungen manuell vornehmen. Teste diesen Prozess bitte, bevor du dich darauf verlässt, dass alles funktioniert, wenn du ihn an einem schwer zu erreichenden System anwendest.

Die folgenden Dateien haben Änderungen erfahren, die du dir genauer ansehen solltest, da sie sehr wahrscheinlich nicht direkt kopiert oder eingepflegt werden können (d. h. wenn du pf.conf verwendest, dann solltest du dir die empfohlene Änderung der Sicherheitsrichtlinie angucken und für dich selbst entscheiden, ob sie für deine Anwendungen eingesetzt werden kann):

hostapd.conf pf.conf spamd.conf

Lösche die libresolv-Dateien, da sie nicht länger benötigt werden:

rm /usr/lib/libresolv*

Verwende schlussendlich mtree(8), um alle neuen Verzeichnisse zu erstellen:

mtree -qdef /etc/mtree/4.4BSD.dist -p / -u

2. Überprüfe den Kernel

Hinweis: Die meisten Leute können diesen Schritt überspringen!

Wenn du den Anweisungen gefolgt bist, wie man einen Upgradeprozess ohne Installationsmedien durchführt, hast du diesen Schritt bereits absolviert. Wenn du jedoch Installationsmedien und unter 3.8 einen angepassten Kernel verwendet hast, wirst du das gleiche vermutlich auch unter 3.9 machen wollen. Dabei kann es sich um so einfache Dinge wie eine Änderung eines bestimmtes Devices mittels config(8) handeln, doch könnte es genausogut bedeuten, dass du den Kernel neuerzeugen musst, da sich eine von dir benötigte Option nicht im GENERIC-Kernel befindet. Lies bitte FAQ 5 - Das System aus dem Quelltext erzeugen, bevor du in Erwägung ziehst, deinen Kernel neu zu erzeugen.

3. Packages upgraden

Wenn du irgendwelche Packages auf deinem System installiert hattest, solltest du sie aktualisieren, nachdem du das Basissystem erfolgreich upgegradet hast. Unter OpenBSD 3.9 können die pkg-Werkzeuge nun Packages direkt mittels pkg_add -u aktualisieren. Dies wurde mit den meisten Packages getestet (insbesondere mit den Packages auf der 3.8-CD). Um zum Beispiel alle deine Packages zu aktualisieren, stelle sicher, dass PKG_PATH auf das Verzeichnis deiner CD oder eines FTP-Mirrors zeigt, in dem sich die 3.9-Packages befinden. Verwende dann Folgendes:

# pkg_add -ui -F update -F updatedepends

Dabei gibt -u den Updatemodus an und -i den interaktiven Modus, sodass pkg_add dich um Rat bittet, sollten Probleme auftreten. Lies die pkg_add(1)-Manualseite und das Kapitel Verwaltung der Packages der FAQ für weitere Informationen.