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

Guide de Mise à niveau : 4.3 vers 4.4

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 d'abord la procédure ci-après sur un système local 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 de OpenBSD. 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 : Les éléments à savoir et dont il faut être conscient

Ceci n'est pas une liste complète des modifications qui ont été effectuées depuis la version 4.3 jusqu'à la version 4.4, mais plutôt un ensemble des éléments importants qui devraient concerner un grand nombre d'utilisateurs durant le processus de mise à jour. Pour une liste plus exhaustive de ces modifications, veuillez prendre connaissance de plus44.html et des journaux des modifications CVS.

Nouvel utilitaire sysmerge(8) :
OpenBSD 4.4 inclut le nouvel utilitaire sysmerge(8) , qui aidera les administrateurs à mettre à jour les fichiers de configuration aprés la mise à jour de leur systéme. Sysmerge(8) compare les fichiers courants de votre système avec les fichiers qui vont être installés avec le nouveau systéme, et vous donne la possibilité de garder les anciens fichiers, installer les nouveaux ou vous assister dans la fusion des anciens et des nouveaux fichiers, sdiff. Pour les mises à jour précédentes, nous avons fourni une liste de fichiers qui sont normalement copiés "tels quels", une liste de fichiers qui doivent être modifiés et un fichier de correctif qui applique ces changements qui doivent être effectués sur votre systéme. Pour la mises à jour de 4.3 vers 4.4, à la place d'utiliser un fichier de patch, vous pouvez prendre l'option d'utiliser sysmerge pour faire vos changements.
Qui doit utiliser sysmerge(8) :
Les personnes utilisant des systémes trés modifiés ou qui ne demarrent pas avec une version précédente (par exemple, un snapshot entre deux versions), qui ont mis à jour vers un snapshot ou qui n'ont pas bien mis à jour leur systéme dans le passé trouveront l'utilisation de sysmerge trés supérieure à l'utilisation des patchs, car il fonctionne avec ce qu'il y a actuellement sur votre systéme, à la place de ce nous aimerions trouver sur votre systéme. Il vous donnera aussi un bien plus grand contrôle sur votre processus de mise à jour, et vous y serez bien plus intégré.
Qui NE doit pas utiliser sysmerge(8) :
Les personnes qui possédent un parc de machines à mettre à jour dans une configuration simple et qui utilise la derniére version stable préféreront plutot utiliser l'ancien systéme de correctif qui est plus simple.
Bien que sysmerge peut prendre en compte TOUS les changements de /etc, /dev, /root et /var, nous recommandons vivement de faire certains changements manuellement avant, cela vous fera gagner du temps et réduira la possibilité d'erreurs humaines. En particulier, il est hautement recommandé de ne pas utiliser sysmerge pour mettre à jour les comptes utilisateurs et les groupes, comme il est trés simple de choisir la mauvaise option entrainant l'effacement complet de vos comptes utilisateurs et configurer le mot de passe root à une valeur nulle, en prévision de connexions distantes qui pourraient corriger le probléme.
dhcpd.interfaces n'est plus utilisé :
Le fichier /etc/dhcpd.interfaces n'est plus utilisé pour selectionner l'interface sur laquelle dhcpd écoute. Cela peut maintenant être spécifié dans la configuration dhcpd_flags du fichier /etc/rc.conf.local. La plupart des utilisateurs peut probablement juste laisser dhcpd(8) sélectionner sur quelle interface il peut écouter en fonction des informations du fichier dhcpd.conf.
Nouveaux pilotes X Le pilote xf86-video-openchrome a été ajouté à Xenocara pour les chipsets VIA à la place du vieillissant pilote "via". Si vous utilisez un chipset VIA dans votre configuration, remplacez le Driver "via" par Driver "openchrome" dans /etc/X11/xorg.conf pour utiliser le nouveau pilote. Regardez la page de manuel openchrome(4) pour plus d'options de configuration.
Le pilote ati(4) a été mis à jour. Cette mise à jour de xf86-video-ati apporte des changements importants.
- Plus de MergedFB: Le support du mode MergedFB a été supprimé en faveur de xrandr(1).
- L'option Quirk pour Macbooks a changé: Les utilisateurs avec un Macs ou un Macbooks qui utilise l'option suivante Option "iBookHacks" "on" doivent lire la page de manuel radeon(4) , plus spécifiquement la section "MacModel", si il y a des problémes.
  Dans cette version, l'option a été supprimée.
pfsync :
A cause de changements dans la table d'état pf(4), le numéro de version de protocole a été incrementé; les pare-feu avec un numéro de version différente seront incapables de synchroniser leur table d'état et les connexions existantes se termineront sur le redondant.
rc.conf :
Contrairement aux versions antérieures de ce processus, depuis la 4.1 il est convenu que /etc/rc.conf n'est pas un fichier qui doit être modifié par l'utilisateur. Si vous avez fait des changements dans votre fichier /etc/rc.conf, fusionnez ces changements dans /etc/rc.conf.local. Si vous NE possédez PAS de /etc/rc.conf.local, copiez simplement votre fichier /etc/rc.conf existant vers /etc/rc.conf.local et supprimez la derniére ligne de votre script! Sinon, insérez votre rc.conf existant dans le haut de votre fichier rc.conf.local existant et supprimez la derniére ligne avant de continuer la suite du processus.
Noyau modifié :
Vérifiez si vous avez apporté des modifications à votre noyau. Par exemple, vous avez pu modifier votre périphérique réseau pour utiliser un paramètrage différent du paramétrage par défaut à l'aide de config(8). Notez vos modifications afin que vous puissiez les reproduire avec le nouveau noyau 4.4.

Procédure de mise à jour

Mise à niveau avec un noyau d'installation

Si vous avez accès à la console système, 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 ou depuis le noyau bsd.rd 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.

Une solution simple pour démarrer sur le noyau d'installation est de mettre le noyau bsd.rd de la version 4.4 à la racine de votre lecteur de démarrage et de dire au chargeur de démarrage d'utiliser ce nouveau fichier bsd.rd. Sur amd64 et i386, vous pouvez entrer "boot bsd.rd" à l'invite de commandes boot>.

Mise à niveau sans noyau d'installation

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

De temps à autre, on peut avoir besoin de faire la mise à jour d'une machine sans pouvoir utiliser le processus de mise à jour classique. Le cas le plus courant est celui d'une machine distante dont on ne peut accéder à la console système. On peut alors réaliser une mise à niveau en faisant attention suivant cette procédure :

Placez les fichiers d'installation dans un "bon" endroit. Assurez-vous d'avoir la place suffisante !
Stoppez toutes les applications "insécurisées" lancées lors du démarrage : Il y aura un moment où 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 dépendante 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érifiez le noyau : Bien que la plupart des gens puissent sauter cette étape, si vous aviez un noyau modifié en 4.3, il est probable que vous devrez modifier le noyau 4.4 de base. Surtout si vous effectuez une mise à jour à distance, c'est maintenant 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 4.4 local. Cela peut être aussi simple que de modifier un périphérique spécifique avec config(8), mais il peut aussi être 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=/usr/rel   #  où mettre les fichiers
cd ${RELEASEPATH}
rm /obsd ; ln /bsd /obsd && cp bsd /nbsd && mv /nbsd /bsd
cp bsd.rd bsd.mp /
```
(si vous utilisez un noyau multiprocesseurs, utilisez
rm /obsd ; ln /bsd /obsd && cp bsd.mp /nbsd && mv /nbsd /bsd
à la place)
Remarquez les étapes additionnelles pour copier par dessus un premier noyau : celles-ci sont réalisées afin de s'assurer qu'il existe toujours une copie valide du noyau sur le disque et que le système puisse redémarrer en cas de coupure électrique ou de panne.
Installez les nouveaux fichiers /etc/firmware et l'utilitaire /sbin/ifconfig : Parce que certains "firmwares" ont pu être mis à jour, il est possible que vous deviez mettre à jour le dossier /etc/firmware. Ceci concerne les utilisateurs de certains périphériques, bien que tout utilisateur devrait considérer cette étape. Pour être sur que le réseau est complétement fonctionnel au redémarrage, le nouveau noyau a besoin d'une mise à jour des utilitaires ifconfig et pfctl pour être configuré proprement aprés le reboot dans la prochaine étape. Encore un fois, c'est une chose que tous les utilisateurs peuvent faire sans peur, mais si vous effectuez un mise à jour à distance à travers une connexion pppoe(4) cette étape peut-être cruciale. Afin d'extraire les fichiers firmware et utilitaires de base44.tgz, tapez en étant root les commandes suivantes :
```
tar -C / -xzphf ${RELEASEPATH}/base44.tgz ./etc/firmware ./sbin/ifconfig ./sbin/pfctl
```
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 (telles 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 etc44.tgz et xetc44.tgz maintenant, parce que cela écraserait vos fichiers de configuration actuels !
```
export RELEASEPATH=/usr/rel
cd ${RELEASEPATH}
tar -C / -xzphf base44.tgz
tar -C / -xzphf comp44.tgz
tar -C / -xzphf game44.tgz
tar -C / -xzphf man44.tgz
tar -C / -xzphf misc44.tgz
tar -C / -xzphf xbase44.tgz
tar -C / -xzphf xfont44.tgz
tar -C / -xzphf xserv44.tgz
tar -C / -xzphf xshare44.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.
Note: les fichiers dans /etc sont gérés séparément, donc etc44.tgz et xetc44.tgz NE sont pas ouvert maintenant.
Mise à jour de /dev. Le nouveau fichier MAKEDEV sera copié dans /dev par l'installation de base44.tgz, donc vous avez simplement à faire :
```
cd /dev
./MAKEDEV all
```
Mise à jour de /etc comme ci-dessous.
Redemarrez

Durant cette étape, sendmail(8) peut produire des messages d'erreurs comme celui-ci :

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

Ces messages peuvent être ignorés sans crainte pour le moment, ou vous pouvez souhaiter arréter sendmail(8) pendant cette étape de la mise à jour. Il est à noter que sendmail ne fonctionne pas proprement à ce stade, et a besoin d'être redemarré (durant le reboot) avant que les messages puissent être traités correctement.

Etapes finales

Que vous mettiez à jour à partir d'un noyau d'installation et en utilisant le processus de mise à jour formel, ou en faisant une mise à jour binaire "sur place", vous aurez besoin d'effectuer un certain nombre d'étapes manuelles.

1. Ajout des Utilisateurs et des Groupes

De nouveaux utilisateurs sont nécessaires pour rtadvd, et l'arrivant ypldap(8). Créez les utilisateurs et groupes en utilisant useradd(8)

useradd -u92 -g=uid -c"IPv6 Router Advertisement Daemon" -d/var/empty -s/sbin/nologin _rtadvd
useradd -u93 -g=uid -c"YP to LDAP Daemon" -d/var/empty -s/sbin/nologin _ypldap

2. Mise à jour de `/etc`

Vous aurez besoin d'extraire les fichiers etc44.tgz dans un endroit temporaire :

tar -C /tmp -xzphf ${RELEASEPATH}/etc44.tgz

Les fichiers suivants peuvent être probablement copiés "tels quels" à partir de etc44.tgz :

etc/magic
etc/netstart
etc/rc
etc/rc.conf
etc/security
etc/services
etc/mail/localhost.cf
etc/mail/sendmail.cf
etc/mail/submit.cf
etc/mtree/4.4BSD.dist

Remarquez qu'il EST possible de modifier localement ces fichiers. Si vous l'avez fait, NE pas copier sur ces fichiers, et utilisez sysmerge(8) à la place. Veuillez prêter une attention particulière à mail/* si vous utilisez autre chose que la configuration Sendmail(8) par défaut. Voici des lignes à copier/coller pour copier ces fichiers, en supposant que vous avez extrait etc44.tgz à l'endroit précité :

cd /tmp/etc
cp magic netstart rc rc.conf security services /etc
cp mtree/* /etc/mtree
cp mail/*.cf /etc/mail # Attention avec celui-ci !!

3a. Fusionner localement les changements de fichiers via une fichier de correctif

Utilisez soit ce fichier de patch OU le processus sysmerge ci-dessous, mais pas les deux.

Les fichiers suivants ont probablement été modifiés localement, mais ils doivent être mis à jour pour 4.4. SI vous n'avez pas modifié ces fichiers, vous pouvez copier directement la nouvelle version, sinon vous devez fusionner les modifications avec vos fichiers :

etc/changelist
etc/ftpusers
etc/hosts.lpd
etc/man.conf
etc/sudoers
etc/mail/aliases
etc/ssh/ssh_config
etc/ssh/sshd_config

Les modifications apportées à ces fichiers se trouvent dans ce fichier correctif. Vous pouvez tenter de l'utiliser en exécutant les commandes suivantes sous l'identité root :

cd /
patch -C -p0 < upgrade44.patch

Ceci aura pour effet de tester le correctif afin de voir s'il va bien s'appliquer à VOTRE système. Si vous voulez l'appliquer, il suffit d'omettre l'option "-C". Il est probable que, si vous avez adapté ces fichiers à vos besoins ou si vous ne les avez pas maintenus à jour de manière stricte, ou si vous avez mis à jour à partir d'un snapshot de 4.3, le correctif ne se passera pas de manière satisfaisante. Dans ces cas, vous devrez appliquer manuellement les modifications. Veuillez tester ce processus avant de vous y fier, notamment pour une machine à laquelle vous ne pouvez pas accéder facilement.

Les fichiers suivants comportent des modifications dont vous devez prendre connaissance, mais il est peu probable qu'ils puissent être directement copiés ou fusionnés (i.e. si vous utilisez pf.conf, prenez connaissance de la stratégie de mise à jour suggérée, et décidez si oui ou non elle est appropriée dans votre cas).

etc/dhclient.conf
etc/pf.conf
var/www/conf/httpd.conf

Il y a un fichier qui peut être effacé car il n'est plus utilisé dans la 4.4:

rm /etc/dhcpd.interfaces

Finalement, utilisez newaliases(8) pour mettre à jour la base des aliases, mtree(8) créera tout nouveau répertoire :

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

3b. Fusionner localement les changements via sysmerge(8)

Utilisez soit le processus sysmerge(8), OU le processus correctif ci-dessus, pas les deux.

Le nouvel utilitaire sysmerge(8) comparera les fichiers qui sont actuellement sur votre système avec ceux qui devront être installés pendant la nouvelle installation, et vous assister dans la fusion des changements sur votre système. Il est à noter que contrairement au fichier correctif, il n'y a pas d'hypothèses faites sur ce qui est effectivement sur votre système, donc vous pouvez utiliser sysmerge(8) pour changer de facon arbitraire entre différentes saveurs du processus de développement, comme d'une ancienne version -current vers la 4.4-release ou d'une -current vers la derniére.

Il est conseillé de lire la page de manuel sysmerge(8) avant de l'utiliser sur votre système. Il serait aussi avisé de lire les pages de manuel suivantes diff(1), sdiff(1) et même revoir more(1) avant de continuer.

En supposant que les fichiers etc44.tgz et xetc44.tgz existent dans votre $RELEASEPATH, l'executer avec :

# sudo sysmerge -as $RELEASEPATH/etc44.tgz -x $RELEASEPATH/xetc44.tgz

Sysmerge(8) va vous présenter un diff(1), unifié à travers votre $PAGER favori (i.e., more(1)) et va vous demander, pour la plupart des changements de fichiers, si vous souhaitez :

  Use 'd' to delete the temporary ./var/www/htdocs/index.html
  Use 'i' to install the temporary ./var/www/htdocs/index.html
  Use 'm' to merge the temporary and installed versions
  Use 'v' to view the diff results again

  Default is to leave the temporary file to deal with by hand

Si vous souhaitez garder vos fichiers existants, supprimez le fichier temporaire, si vous souhaitez remplacer votre fichier existant par la nouvelle version, installez le fichier temporaire. Si vous souhaitez fusionner les deux ensemble, choississez 'm' qui va vous mettre sous sdiff(1), ou vous pourrez manuellement fusionner le fichier. La valeur par défaut est de revenir et de traiter le fichier plus tard, manuellement.

Tant qu'il peut travailler, nous ne vous recommandons pas d'utiliser sysmerge à intégrer de nouveaux utilisateurs dans le système, mais plutôt d'utiliser la ligne useradd(8) plus haut. Nous pensons qu'il est beaucoup moins sensibles aux erreurs. (conseil: ne pas installer le fichier temporaire master.passwd sur votre existant !).

Sysmerge(8) sauvegardera tous vos fichiers remplacés dans un répertoire temporaire, similaire à /var/tmp/sysmerge.24959/backups, donc si vous avez accidentellement supprimé quelque chose, ce qui n'était probablement pas une bonne idée, vous avez une chance de le récupérer. Il est à noter que daily(8) effacera les anciens fichiers de ce répertoire.

4. Vérification du noyau

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

Si vous avez suivi les instructions de mise à niveau sans noyau d'installation, vous avez déjà accompli cette étape. En revanche, si vous utilisez le média d'installation et si vous aviez un noyau modifié en 4.3, il est probable que vous devrez modifier le noyau 4.4 de base. Cela peut être aussi simple que de modifier un périphérique spécifique avec config(8), mais il peut aussi être 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.

5. Mise à jour des paquetages

Si vous avez installé des paquetages sur votre machine vous devriez les mettre à jour après la mise à niveau de votre système de base. Attention cependant car de nombreux paquetages nécessiteront une manipulation supplémentaire avant et/ou après avoir été mis à jour. Référez-vous au guide de mise à niveau de l'application pour de plus amples informations.

Les paquetages suivants sont connus pour avoir des interrogations sur la mise à jour qui aura un impact sur un grand nombre d'utilisateurs. Le fait qu'un paquetage n'est pas sur cette liste ne signifie pas qu'il aura une mise à jour triviale. Vous devez faire des travaux personnels sur les applications que VOUS utilisez.

ejabberd: Quand vous mettez à jour ejabberd de la version 1.x vers la 2.x, il est nécessaire d'exporter et de restaurer la base de données comme décrit dans http://www.ejabberd.im/migrate-host.

Les utilitaires de gestion des paquetages supportent la mise à jour avec la commande pkg_add -u. Par exemple, pour mettre à jour tous vos paquetages, soyez certains que PKG_PATH pointe bien vers le répertoire contenant les paquetages 4.4 sur votre CD ou un miroir FTP proche et utilisez une commande du type

# pkg_add -ui -F update -F updatedepends

où -u indique le mode mise à jour et -i le mode interactif, 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.