OBSD4* : wiki

Version de traduction basée sur la 6.3 officielle


Guide de migration : 6.2 vers 6.3

Les mises-à-jour sont seulement supportées entre deux versions qui se suivent immédiatement. Veuillez lire et bien comprendre le processus avant de l'essayer. Concernant les machines critiques ou physiquement distantes, testez-le sur un système local identique d'abord.

Commencez par effectuer les étapes de pré-mise-à-jour. Ensuite, démarrez votre machine depuis le noyau d'installation 'bsd.rd' : utilisez un media d'installation démarrable, ou placez la version 6.3 de bsd.rd à la racine de votre système de fichiers et ordonnez au chargeur de démarrage de démarrer ce noyau. Une fois que le noyau est démarré, choisissez l'option de mise-à-jour (U)pgrade et suivez les instructions. Appliquez les changements de configuration et finissez par la mise-à-jour des paquets : pkg_add -u.

Alternativement, vous pouvez utiliser le processus manuel de mise-à-jour.

Vous pouvez vérifier la page d'errata ou mettre-à-jour la branche stable pour obtenir tous les correctifs post-installation.


Avant de redémarrer vers le nouveau noyau

Obtenez et vérifiez bsd.rd. Téléchargez le noyau ramdisk et le fichier de sommes de contrôle signé cryptographiquement pour votre architecture.

Vérifiez les en utilisant signify(1) :

$ signify -C -p /etc/signify/openbsd-63-base.pub -x SHA256.sig bsd.rd
  Signature Verified
  bsd.rd: OK

Faites le “ménage de printemps” dans /usr/share. Supprimez tous les manuels obsolètes. De plus, la reliaison des bibliothèques et des noyaux au démarrage doit maintenant se faire dans /usr/share/relink. L'ancien répertoire de reliaison n'est plus supporté et peut être supprimé.

# rm -r /usr/share/man
# rm -r /usr/share/compile

Les adresses IPv6 de style RFC 7217 sont activées par défaut. L'auto-configuration des adresses sans état et les adresses IPv6 de lien local étaient historiquement incorporées dans l'adresse (mac ethernet) de la couche 2, dans les 64 bits inférieurs de l'adresse IPv6. Ceci a divers inconvénients et la RFC 7217 spécifie un schéma alternatif dans la manière de gérer l'auto-configuration des adresses, qui sont stables entre les redémarrages. Cela est activé par défaut et les adresses IPv6 de lien local changeront si IPv6 est activé pour l'interface. De plus, les adresses IPv6 sans état changeront si l'auto-configuration est activée sur l'interface.

Si vous avez besoin de l'ancien style des adresses sans état calculé depuis l'adressage de la couche 2 (c-à-d, les adresses mac ethernet), mettez -soii dans le fichier /etc/hostname.if.

Changement de configuration et de syntaxe

L'option ifconfig <if> deletetunnel est obsolète. L'option deletetunnel d'ifconfig(8) a été remplacée par -tunnel. Ajustez la configuration de votre hostname.if(5) et de vos scripts, en accord avec cela.

iked(8) and isakmpd(8): incompatibilité du groupe ECP. Dans la dernière RFC 5903, le calcul du secret partagé de la DH a changé. Les programmes iked(8) et isakmpd(8) ont été modifiés en suivant la RFC. Ces changements ne sont pas rétro-compatibles, ainsi si vous utilisez des groupes ECP, veuillez vous assurer des mettre à niveau tous les pairs en même temps.

Nouvelle configuration par défaut pour les pavés tactiles (les touchpads). X sélectionne maintenant ws(4) en tant que pilote par défaut pour les pavés tactiles. Du fait de la configuration de ws, le traitement des entrées spécifiques du pavé tactile est fait par wsmouse(4). Les paramètres de configuration du pavé tactile sont rendus disponibles dans wsconsctl(8). Utiliser le pilote d'entrée synaptics(4) est toujours possible avec un fichier xorg.conf personnalisé.

vmd(8): changement de configuration. vmd(8) ne crée plus automatiquement l'interface de pont sous-jacente aux commutateurs virtuels définis dans vm.conf(5). Cela requiert que les utilisateurs créent leurs ponts en amont, par ex. en utilisant /etc/hostname.bridge0. Cela requiert aussi des utilisateurs qu'ils modifient leur fichier vm.conf(5) pour ajouter une ligne d'interface à la définition du commutateur, par exemple :

switch "uplink" {
    interface bridge0
}

Fichiers à supprimer

Supprimez libpthread-stubs. Avec l'intégration des fonctions pthread stub dans libc, libpthread-stubs n'est plus nécessaire dans xenocara. Après la mise à niveau de la base et des packages, les utilisateurs devraient supprimer l'ancienne bibliothèque installée, soit via le package sysclean, soit en exécutant les commandes suivantes :

# cd /usr/X11R6/lib
# rm libpthread-stubs.a \
     libpthread-stubs.so.2.0 \
     pkgconfig/pthread-stubs.pc

Packages spécifiques

Mise à jour majeure de Buildbot. Mise à jour majeure vers Buildbot 0.9. Alors que le répertoire de travail buildslave (renommé en buildworker) est compatible entre la version 0.8 et la 0.9, ce n'est pas le cas pour le buildmaster. En plus de cela, le buildworker de la 0.9 ne fonctionne pas avec le buildmaster de la 0.8.

Référez-vous aux informations du guide de mise à jour pour savoir comment migrer votre configuration. Si vous voulez continuer à exécuter le buildmaster de la 0.8 pour garder l'accès à vos anciens journaux et historiques de compilation, il est conseillé d'installer la branche 0.8 depuis pip et de l'exécuter en dehors des paquets.

memcached par défaut en local seulement. La documentation de memcached dit : “vous ne devez pas exposer memcached directement sur internet, ou autrement ne faîtes pas confiance aux utilisateurs”. Afin de fournir un environnement par défaut sain, la ligne de commande normale du script rc de memcached a été changée pour n'écouter seulement que localhost. Lisez le fichier pkg-readme pour plus d'information sur comment changer cela si l'écoute du trafic réseau externe est requis.

Le binaire neomutt est renommé. Dans les versions de neomutt depuis le 13/10/2017, les binaires et les autres fichiers ont été renommés ainsi ils peuvent coexister avec mutt. Les utilisateurs peuvent souhaiter ajouter un alias shell ou un lien symbolique pour mutt → neomutt.

newsbeuter remplacé par newsboat. Mettre à jour newsbeuter en utilisant pkg_add aura pour résultat que newsboat soit installé. Lors de la première exécution de newsboat, il vous sera demandé s'il doit importer une configuration existante de newsbeuter.

Mise à jour majeure de PostgreSQL. Mise à jour majeure vers PostgreSQL 10.1. Utilisez pg_upgrade tel que décrit dans le pkg-readme de postgresql-server ou faites une sauvegarde/restauration.


Mise-à-jour sans le noyau d'installation

Ceci N'EST PAS le processus recommandé. Utilisez la méthode d'installation du noyau autant que possible!

Parfois, vous avez besoin de faire une mise-à-jour d'une machine pour laquelle le processus normal de mise-à-jour n'est pas possible. Le cas le plus courant est une machine distante où l'accès à la console système n'est pas aisé.

Préparation

Placez les fichiers d'installation au bon endroit. Assurez-vous d'avoir assez d'espace disque ! Exécuter une mise à jour à distance sans l'espace nécessaire pourrait être… catastrophique. Notez que l'usage de softdeps peut amplifier la situation car les fichiers supprimés ou réécrits ne restitueraient pas leur espace immédiatement. Envisagez le fait de désactiver l'option de montage softdep dans /etc/fstab et redémarrer avant de prendre le contrôle pour une mise-à-jour manuelle. Il est recommandé d'avoir au moins 500 Mo d'espace libre sur /usr.

Être root. Bien que l'usage de doas(1) avant chaque commande soit généralement une bonne pratique, la commande serait probablement interrompue par les dernières étapes, ainsi vous devriez passer root avant de démarrer le processus. C'est une bonne chose de vérifier votre accès administrateur en utilisant une des autres méthodes que doas, c'est à dire, par une connexion directe ou en utilisant su(1).

Arrêtez et/ou désactivez toutes applications appropriées. Durant ce processus, toutes les applications dans l'espace utilisateur seront remplacées mais peuvent ne pas fonctionner, et des dysfonctionnements peuvent arriver. Vous pouvez également avoir des problèmes avec la résolutions DNS lors du premier redémarrage, en effet les règles PF et les montages NFS dépendants des résolutions DNS peuvent causer des problèmes de démarrage. Il peut y avoir d'autres applications que vous souhaitez empêcher de fonctionner immédiatement après la mise à jour, arrêtez-les et désactivez-les aussi.

Installation des nouveaux blocs de démarrage. Cela devrait être actuellement fait à la fin de chaque mise à niveau. Si cela a été négligé, alors le fait de ne pas le faire immédiatement pourraient rendre non-fonctionnel la console série ou d'autres choses, selon votre plate-forme. Utilisez installboot(8), en assumant que sd0 est votre disque de démarrage :

      installboot sd0

Mise-à-jour manuelle

Installer les nouveaux noyaux. Les étapes supplémentaires de copie sur le noyau primaire sont faites pour s'assurer qu'il y a toujours un noyau valide sur votre disque.

Si vous utilisez un noyau pour multi-processeurs :

cd /usr/rel    # où vous placez les fichiers de version
ln -f /bsd /obsd && cp bsd.mp /nbsd && mv /nbsd /bsd
cp bsd.rd /
cp bsd /bsd.sp

Si vous utilisez un noyau pour un seul processeur :

cd /usr/rel    # où vous placez les fichiers de version
ln -f /bsd /obsd && cp bsd /nbsd && mv /nbsd /bsd
cp bsd.rd bsd.mp /    # peut lever un avertissement inoffensif

Activer KARL. Enregistrez la somme de contrôle du noyau :

sha256 -h /var/db/kernel.SHA256 /bsd

Installer le nouvel espace utilisateur. Sauvegardez une copie de reboot(8), décompressez et installez les paquets tar, puis redémarrez. Installez base63.tgz en dernier, car le nouveau système de base, en particulier tar(1), gzip(1) et reboot(8) ne fonctionnent pas avec l'ancien noyaux. Décompressez l'un ou l'autre des jeux de fichiers manuellement :

cp /sbin/reboot /sbin/oreboot
tar -C / -xzphf xshare63.tgz
tar -C / -xzphf xserv63.tgz
tar -C / -xzphf xfont63.tgz
tar -C / -xzphf xbase63.tgz
tar -C / -xzphf man63.tgz
tar -C / -xzphf game63.tgz
tar -C / -xzphf comp63.tgz
tar -C / -xzphf base63.tgz    # Installez en dernier !
/sbin/oreboot

ou, si vous utilisez ksh(1), vous pouvez faire :

cp /sbin/reboot /sbin/oreboot
for _f in [!b]*63.tgz base63.tgz; do tar -C / -xzphf "$_f" || break; done
/sbin/oreboot

Notez que tar(1) ne peut décompresser qu'une seule archive par invocation, donc un simple glob ne fonctionnera pas.

Après le redémarrage, mettre à jour /dev. Utilisez MAKEDEV(8) :

cd /dev
./MAKEDEV all

Mettre à jour le chargeur de démarrage. Toujours en supposant que sd0 soit votre disque de démarrage :

installboot sd0

Mettre à jour les fichiers de configurations systèmes. Utilisez sysmerge(8) :

sysmerge

Mettre à jour les micrologiciels. Il peut y avoir de nouveaux micrologiciels pour votre système. Mettez-les à jour avec fw_update(1) :

fw_update

Pour terminer : Examinez les sorties de consoles post démarrage (en utilisant dmesg -s) et corrigez toute défaillance si nécessaire. Toutes les étapes concernant les changements de configuration ci-dessus s'appliquent également aux mises à jour manuelles. Enfin, supprimez /sbin/oreboot et mettez à jour vos paquets : pkg_add -u. Redémarrez une fois que vous êtes sûr du bon fonctionnement de votre propre noyau généré par KARL.


Cette page est la traduction officieuse de la page “Upgrade Guide: 6.2 to 6.3” de la FAQ officielle d'OpenBSD.
En cas de doute, merci de vous y référer !

Si vous voulez participer à l'effort de traduction, merci de lire ce topic.