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

Upgradeanleitung: 3.9 auf 4.0

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

Ü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 4.0-Kernel anwenden kannst.

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 Quelltext-basierten Upgrade sehr ähnlich ist:

Lege die Installationsdateien in einem »guten« Verzeichnis ab. Stelle sicher, dass du genügend freien Platz hast!
Deaktiviere 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.9-Kernel angepasst hast. Wenn das der Fall ist, dann wirst du sehr wahrscheinlich das gleiche mit dem 4.0-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 4.0-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 genauso gut 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ünstiger Zeit eintreten.
Installiere neue /etc/firmware-Dateien: Einige hochgeladene »firmware«-Blobs wurden eventuell aktualisiert. Falls du davon betroffen bist, musst du Dateien in deinem /etc/firmware-Verzeichnis aktualisieren. Dies betrifft jedoch nur Benutzer von ein paar Geräten - andere Benutzer können diesen Schritt ohne weiterer Beeinträchtigung ausführen können. Um die Firmwaredateien aus base40.tgz zu entpacken, verwende das Folgende als root vor dem nächsten Schritt:
```
cd /
tar xzpf ${RELEASEPATH}/base40.tgz "*etc/firmware/*"
```
Hinweis: wenn du den iwi(4)-Treiber für deinen Drahtlosadapter verwendest, musst du auf die Version 3.0 deiner Firmware-Dateien upgraden. Aufgrund der Lizenzprobleme wird die Firmware momentan nicht mit OpenBSD ausgeliefert. Die Firmware kann mit den pkg-Werkzeugen installiert werden: http://damien.bergamini.free.fr/iwifw/OpenBSD/iwi-firmware-3.0.tgz
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 etc40.tgz und xetc40.tgz, da sie deine aktuellen Konfigurationsdateien überschreiben würden!
```
export RELEASEPATH=/yourpath
cd /
tar xzpf ${RELEASEPATH}/base40.tgz
tar xzpf ${RELEASEPATH}/comp40.tgz
tar xzpf ${RELEASEPATH}/game40.tgz
tar xzpf ${RELEASEPATH}/man40.tgz
tar xzpf ${RELEASEPATH}/misc40.tgz
tar xzpf ${RELEASEPATH}/xbase40.tgz
tar xzpf ${RELEASEPATH}/xfont40.tgz
tar xzpf ${RELEASEPATH}/xserv40.tgz
tar xzpf ${RELEASEPATH}/xshare40.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 etc40.tgz und xetc40.tgz an dieser Stelle NICHT entpackt werden.
Upgrade /dev. Die neue MAKEDEV-Datei wird durch die Installation von base40.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

Es wurde mit einem Ersatz von mrouted(8) begonnen. Um diesen neuen Daemon benutzen zu können, werden ein neuer Benutzer und eine neue Gruppe benötigt. Füge als root mit us eradd(8) den folgenden Benutzer und die folgende Gruppe hinzu:
```
# useradd -u87 -g=uid -c"DVMRP Daemon" -d/var/empty -s/sbin/nologin _dvmrpd
```
Mit diesem Schritt werden sowohl der neuer Benutzer als auch die zu ihm gehörende Gruppe angelegt. Deine Systemeinrichtung wird es vermutlich ermöglichen, dass du diesen Befehl einfach kopieren und einfügen kannst.

1.2. Funktionsänderungen

IPsec wird nun mittels ipsecctl(8) konfiguriert
IPsec-Konfiguration wird nun vollständig von ipsecctl(8) unterstützt. Das nun überholte ipsecadm(8)-Werkzeug wurde entfernt. Wirf einen Blick auf die ipsec.conf(5)-Handbuchseite, wenn du Konfigurationsbeispiele sehen möchtest.
wicontrol(8) wurde entfernt
Drahtloskonfiguration für wi(4) wird nun vollständig von ifconfig(8) unterstützt. Das nun überflüssige wicontrol(8)-Werkzeug wurde entfernt.
spppcontrol(8) wurde entfernt
Die Konfiguration vom In-Kernel-PPP wird nun vollständig von ifconfig(8) unterstützt. Das überholte Werkzeug spppcontrol(8) wurde entfernt. Wirf einen Blick auf die beiden Handbuchseiten sppp(4) und pppoe(4) wenn du Konfigurationsbeispiele sehen möchtest.
Bisher sah die /etc/hostname.pppoe0-Datei wie folgt aus:
```
pppoedev ne0
!/sbin/ifconfig ne0 up
!/usr/sbin/spppcontrol \$if myauthproto=pap myauthname=testcaller \
        myauthkey=donttell
!/sbin/ifconfig \$if inet 0.0.0.0 0.0.0.1 netmask 0xffffffff
!/sbin/route add default 0.0.0.1
up
```
Diese Datei sollte basierend auf dem folgenden Beispiel ersetzt werden:
```
inet 0.0.0.0 255.255.255.255 0.0.0.1 pppoedev ne0 \
        authproto pap authname testcaller authkey donttell up
!/sbin/route add default 0.0.0.1
```
Das physikalische Interface muss ebenfalls auf UP gesetzt werden:
```
# echo "up" > /etc/hostname.ne0
```

1.3. `/etc`-Dateiänderungen

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

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

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

chio.conf
dvmrpd.conf
netstart
pf.os
rc
security
services
mail/helpfile
mail/localhost.cf
mail/sendmail.cf
mail/submit.cf
mtree/*
ppp/ppp.conf.sample

Bedenke, dass es möglich IST, all diese Dateien lokal zu modifizieren. Solltest du sie also modifiziert haben, musst du sie manuell anpassen. Achte besonders auf mail/sendmail.cf, wenn du eine angepasste Sendmail(8)-Konfiguration verwendest. Hier sind Copy&Paste-Zeilen, um diese Dateien zu kopieren, angenommen, dass du etc40.tgz in dem zuvor empfohlenen Verzeichnis abgelegt hast:

cd /tmp/etc
cp chio.conf dvmrpd.conf netstart pf.os rc security services /etc
cp mail/helpfile mail/localhost.cf mail/submit.cf /etc/mail
cp ppp/ppp.conf.sample /etc/ppp
cp mtree/* /etc/mtree/
cp mail/sendmail.cf /etc/mail    # sei hier besonders vorsichtig!!

Ein paar Seiten für die Dokumentation des httpd(8)s wurden verändert:

/var/www/htdocs/manual/mod/core.html
/var/www/htdocs/manual/mod/mod_proxy.html

Diese können bei Bedarf wie folgt kopiert werden:

cd /tmp/var/www/htdocs/manual/mod/
cp core.html mod_proxy.html /var/www/htdocs/manual/mod

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
ftpusers
mail/aliases
rc.conf
ssh/ssh_config
ssh/sshd_config

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

cd /
patch -C -p0 < upgrade40.patch

Hiermit wird geprüft, wie gut die Korrektur 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 Schnappschuss von 3.9 aus upgradest, diese Korrektur 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
ipsec.conf
rc.local
sensorsd.conf
spamd.conf

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.9 einen angepassten Kernel verwendet hast, wirst du das gleiche vermutlich auch unter 4.0 machen wollen. Dabei kann es sich um so einfache Dinge wie eine Änderung eines bestimmtes Devices mittels config(8) handeln, doch könnte es genauso gut 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. Pakete upgraden

Wenn du irgendwelche Pakete auf deinem System installiert hattest, solltest du sie aktualisieren, nachdem du das Basissystem erfolgreich upgegradet hast. Mit den Paketwerkzeugen kann man direkt mittels pkg_add -u aktualisieren. Um zum Beispiel alle deine Pakete zu aktualisieren, stelle sicher, dass PKG_PATH auf das Verzeichnis deiner CD oder eines FTP-Spiegelservers zeigt, in dem sich die 4.0-Pakete 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)-Handbuchseite und das Kapitel Verwaltung der Pakete der FAQ für weitere Informationen.