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

Guide de Mise à niveau : 3.8 vers 3.9

Remarque : Les mises à niveau ne sont supportées que d'une release à la suivante. Ne sautez pas les releases.

Il est hautement recommandé de lire entièrement la présente page et de bien comprendre la procédure de mise à jour avant de l'appliquer. Si vous comptez mettre à jour une machine critique ou physiquement distante, il est recommandé d'essayer la procédure ci-après sur un système local d'abord afin d'en vérifier le succès.

La mise à niveau est un moyen commode afin d'avoir votre système à jour avec la version la plus récente. Cependant, les résultats escomptés ne sont pas censés être précisément ceux d'une installation de zéro. Les fichiers d'anciennes bibliothèques en particulier ne sont pas supprimés lors du processus de mise à niveau, car ils pourraient être requis par de plus anciennes applications pouvant être ou non mises à jour à ce moment précis. Si vous voulez vraiment vous débarrasser de ces anciens fichiers, vous feriez probablement mieux de réinstaller complètement votre système.

Table des matières :

Avant de mettre à jour
Procédure de mise à jour
Etapes finales

Avant de mettre à jour

Si votre machine possède une carte réseau PCI utilisant le pilote le(4), celui-ci a probablement été remplacé par le pilote pcn(4). AVANT de procéder à la mise à jour, copiez vos fichiers /etc/hostname.le* vers les fichiers /etc/hostname.pcn* correspondants, sinon votre réseau ne sera pas fonctionnel pendant et après la mise à niveau.

A cause de l'ajout de symboles de débogage ("debugging symbols"), la taille des bibliothèques a très largement augmentée. Ainsi sur la plate-forme i386, la taille utilisée par le répertoire /usr/lib est passée de 47.7MB en 3.8 à 209MB en 3.9. Soyez bien certain d'avoir suffisamment d'espace disponible avant de lancer la mise à jour.

Vérifiez si vous avez effectué des modifications à votre noyau. Par exemple vous pourriez avoir modifié un périphérique réseau afin que celui-ci utilise un paramètre non standard en utilisant config(8). Notez vos changements afin d'être en mesure de les reproduire sur le noyau 3.9.

pfsync(4) a changé de format et ne peut donc pas sauvegarder les états entre une machine 3.8 et 3.9. Les systèmes dont la version est différente perdront toutes les connexions actuelles lorsque vous changerez le "maître" car les états ne seront pas transférés entre les machines. Vous pouvez en minimiser l'impact en commençant la mise à jour par les machines "esclaves" afin qu'il n'y ait qu'une seule perte des états actifs.

Les utilisateurs de carp(4) avec plus d'une adresse sur une seule interface carp(4) risquent de rencontrer un autre problème lors de la mise à jour : à présent les interfaces sont triées par adresse, donc avoir les aliases dans le même ordre exact n'est pas aussi critique que dans le passé. Cependant, cela signifie qu'il peut y avoir certains problèmes entre anciens et nouveaux systèmes. Vous pouvez trier les aliases manuellement sur les anciens systèmes afin de contourner le problème.

ftp-proxy(8) a changé comme exliqué ci-dessous et il est possible que votre fichier pf.conf(5) doive être modifié.

ancontrol(8) a été remplacé par l'ajout de fonctionnalités dans ifconfig(8). Cela peut impacter la façon dont vous configurez vos interfaces sans-fil.

Procédure de mise à jour

Mise à niveau avec media d'installation

La manière la plus facile et la plus sûre pour effectuer une mise à jour à partir de fichiers binaires consiste à démarrer depuis un média d'installation et de suivre les étapes de mise à jour; étapes fortement similaires à celles décrites dans la procédure d'installation. Ensuite, terminez la mise à jour en suivant les étapes finales ci-dessous.

Mise à niveau sans media d'installation

Ce n'est pas la solution recommandée. Utilisez le media d'installation le plus souvent possible !

On a parfois besoin de mettre à niveau une machine mais on ne peut pas utiliser le processus classique de mise à niveau. On peut alors réaliser une mise à niveau depuis les sources :

Placez les fichiers d'installation dans un "bon" endroit. Assurez vous d'avoir la place suffisante !
Stopper toutes les applications "insécurisées" de démarrage au boot : Il y aura un moment ou PF ne sera pas le bienvenu pendant le processus de mise à jour, mais vos applications continueront de démarrer et de s'arrêter correctement. Toute application dependante de PF pour la sécurité devrait être désactivée avant qu'un problème ne se produise, et ne devrait pas être réactivée avant que le fonctionnement de PF après la mise à jour ait été vérifié. Il pourrait également y avoir d'autres applications que vous devriez suspendre lors de la mise à jour, arrêtez et désactivez les de la même manière.
Vérification du noyau : Bien que la plupart des gens peuvent sauter cette étape, si vous aviez un noyau modifié en 3.8 il est probable que vous devrez modifier le noyau 3.9 de base. Surtout si vous effectuez une mise à jour à distance, maintenant est le bon moment pour vérifier que le nouveau noyau fonctionnera après le redémarrage de la machine. Si une modification du noyau doit être effectuée, la façon la plus sûre est de l'effectuer sur un système 3.9 local. Cela peut être aussi simple que de modifier un périphérique spécifique avec config(8) ou il peut est nécessaire de recompiler le noyau si l'option que vous souhaitez n'est pas incluse dans le noyau GENERIC. Consultez la section FAQ 5 - Construire le Système à partir des Sources avant d'envisager une recompilation de votre noyau.
Installez le(s) nouveau(x) noyau(x)
export RELEASEPATH=/yourpath cd ${RELEASEPATH} rm /obsd ; ln /bsd /obsd && cp bsd /nbsd && mv /nbsd /bsd cp bsd.rd bsd.mp /
Notez les étapes additionnelles pour copier par dessus un premier noyau : celles-ci sont réalisées afin de s'assurer qu'il y ai toujours une copie valide du noyau sur le disque et que le système puisse booter en cas de coupure électrique ou de panne du système.
Installez les nouveaux fichiers /etc/firmware : A cause du fait que certains "firmwares" ajoutés ont été déplacés du noyau vers des fichiers dans le répertoire /etc/firmware, il y a quelques drivers qui seront inutilisables s'il n'y a pas de fichier firmware pouvant être chargé lorsque le nouveau noyau démarre. Ceci concerne les utilisateurs de certains périphériques, bien que tout utilisateur devrait considérer cette étape. Afin d'extraire les fichiers firmware de base39.tgz, tapez en étant root les commandes suivantes :
cd / tar xzpf ${RELEASEPATH}/base39.tgz "*etc/firmware/*"
Redémarrez votre système avec le nouveau noyau Il peut être tentant de sauter cette étape, mais ceci devrait être fait dès à présent, le nouveau noyau lancera d'anciennes applications utilisateur (tel que la commande reboot ! qui sera importante pour la suite) mais souvent un nouveau "userland" ne fonctionnera PAS sur un ancien noyau.
Installez les nouvelles applications du userland Ne PAS installer etc39.tgz ni xetc39.tgz maintenant, car cela écrasera vos fichiers de configuration actuels !
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
Remarque : tous les jeux de fichiers ne devront pas être installés pour toutes les applications, cependant, si vous aviez installé originalement un jeu de fichiers, vous devrez certainement le mettre à niveau avec le nouveau jeu de fichiers.
Remarque : les fichiers appartenant à /etc sont gérés séparément. C'est pourquoi les archives etc39.tgz et xetc39.tgz ne sont PAS ouvertes à cette étape.
Mettre à jour /dev. Le nouveau fichier MAKEDEV sera copié dans /dev par l'installation de base39.tgz, vous n'avez ainsi qu'à faire ce qui suit :
cd /dev ./MAKEDEV all
Mise à niveau de /etc comme ci-dessous.
Redémarrez

Pendant ce processus, sendmail(8) pourrait produire des messages d'erreur comme :


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

Ces messages peuvent être ignorés sans risque, mais vous pourriez vouloir arrêter sendmail(8) pendant la mise à niveau.

Etapes finales

1. Mise à Jour de `/etc`

Si vous mettez à niveau en utilisant un media d'installation et faites une "mise à niveau" formelle, ou faites une mise à niveau binaire "sur place", il y a certaines étapes manuelles qui doivent être réalisées.

1.1. Nouveaux utilisateurs et groupes

pas de nouveaux utilisateurs ni groupes

1.2. Applications du Userland

ftp-proxy ftp-proxy(8) a été remplacé par ce qui était anciennement appelé pftpx. Le nouveau ftp-proxy est démarré directement et non via inetd.conf(5) comme c'était le cas. Vous devrez éditer /etc/inetd.conf afin qu'il n'invoque plus ftp-proxy(8) et mettre à jour /etc/rc.conf et /etc/rc afin de lancer le nouveau. Editez rc.conf ou rc.conf.local afin de lancer le nouveau programme, par exemple :
echo 'ftpproxy_flags=""' >> /etc/rc.conf.local

Le nouveau proxy utilise des ancres ("anchors") afin de permettre les connexions de données ce qui signifie que votre /etc/pf.conf existant doit être adapté. Dans la section NAT, vous aurez besoin de :
nat-anchor "ftp-proxy/*" rdr-anchor "ftp-proxy/*"
Ces lignes sont obligatoires même si vous n'utilisez pas NAT par ailleurs. La règle suivante, à priori déja présente pour l'ancien ftp-proxy, doit rester :
rdr pass on $int_if proto tcp from $lan to any port 21 -> \ 127.0.0.1 port 8021
Dans la section des règles la ligne suivante est nécessaire :
anchor "ftp-proxy/*"
Les règles permettant au proxy d'effectuer les connexions de contrôle FTP (port de destination 21/tcp) doivent rester. Les règles permettant les connexions de données ne sont plus nécessaires. Ces règles contiennent probablement "user proxy" ou "to port > 49151". Un soin particulier a été prit afin de conserver la même syntaxe mais certaines options diffèrent. Référez-vous à la page de manuel de ftp-proxy(8).
Un cas particulier requière votre attention : si vous avez de vieux clients dont les connexions de données utilisent le port source 20/tcp, vous aurez besoin de l'option '-r' (avec l'ancien proxy vous utilisiez l'option "-u root").
Lancez ftp-proxy avec l'option "-d -D7" si vous rencontrez des problèmes et souhaitez effectuer un diagnostic.

1.3. Changement de fichiers dans `/etc`

Il vous faut extraire etc39.tgz dans un répertoire temporaire :

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

Fichiers pouvant probablement être copiés de etc39.tgz "en l'état" :

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

Notez qu'il EST possible de modifier ces fichiers localement, si ceci a été fait, une fusion manuelle pourrait être nécessaire. Voici les lignes copiées/collées pour copier ces fichiers, à la condition que vous ayez extrait etc39.tgz dans le répertoire conseillé ci-dessus :

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

Fichiers devant être fusionnés manuellement, en respectant tout changement local effectué sur ceux-ci s'ils ont été modifiés par rapport à la configuration par défaut ; sinon, copiez-les simplement :

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

Les modifications effectuées sur ces fichiers se trouvent dans le fichier "patch". Vous pouvez essayer de l'utiliser en exécutant la commande suivante avec les privilèges root :

cd / patch -C -p0 < upgrade39.patch

Ceci aura pour effet de tester le "patch" pour voir s'il s'applique bien à VOTRE système. Pour l'appliquer, supprimer l'option "-C" de la commande précédente. Si vous avez effectué des modifications locales sur ces fichiers ou si vous ne les avez pas gardées aussi à jour que possible par rapport aux versions officielles, ou si vous effectuez la mise à jour depuis un snapshot de la version 3.8, il se peut que le "patch" ne passe pas correctement. Vous devriez alors intervenir manuellement. Merci de bien vouloir tester ce procédé avant de vous y fier pour une machine à laquelle vous ne pouvez avoir accès facilement.

Les fichiers suivants contiennent des modifications à considérer. Cependant, une copie ou une comparaison sont peu probables (dans le cas de pf.conf par exemple, considérez les changements de stratégie s'il y a lieu et déterminez si ces changements sont adaptés à votre utilisation).

hostapd.conf pf.conf spamd.conf

Supprimez les fichiers libresolv qui ne sont plus utilisés :

rm /usr/lib/libresolv*

Enfin, utilisez mtree(8) pour créer les nouveaux répertoires :

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

2. Vérification du noyau

Remarque : la plupart des gens peuvent sauter cette étape !

Si vous avez suivi les instructions de mise à niveau sans media d'installation vous aurez déja accompli cette étape. En revanche, si vous utilisez le media d'installation et si vous aviez un noyau modifié en 3.8 il est probable que vous devriez modifier le noyau 3.9 de base. Cela peut être aussi simple que de modifier un périphérique spécifique abev config(8) ou il peut est nécessaire de recompiler le noyau si l'option que vous souhaitez n'est pas incluse dans le noyau GENERIC. Consultez la section FAQ 5 - Construire le Système à partir des Sources avant d'envisager une recompilation de votre noyau.

3. Mise à jour des paquetages

Si vous avez installé des paquetages sur votre machine vous allez pouvoir les mettre à jour après la mise à niveau de votre système de base. Avec OpenBSD 3.9 les utilitaires de gestion des paquetages ("pkg tools") supportent la mise à jour en place avec la commande pkg_add -u. Cela a été testé avec succès pour la plupart des paquetages spécialement ceux présents sur le CD de la version 3.8. Par exemple, pour mettre à jour tous vos paquetages, soyez certains que PKG_PATH pointe bien vers le répertoire contenant les paquetages 3.9 sur votre CD ou un proche miroir FTP et utilisez une commande du type

# pkg_add -ui -F update -F updatedepends

où -u indique le mode mise à jour et -i le mode intéractif, ainsi pkg_add vous demandera ce que vous souhaitez faire lorsque celui-ci rencontrera une ambiguïté. Lisez le manuel de pkg_add(1) et le chapitre de la FAQ sur la gestion des paquetages pour de plus amples informations.