Outils pour utilisateurs

Outils du site


openbsd.org:faq:upgrade67

OpenBSD Upgrade Guide: 6.6 to 6.7 : (v1.9 : 20/05/2020)


[ FAQ Index ] | [ 6.5 -> 6.6 ] ~ Traduction française du Guide de Migration OpenBSD : 6.6 vers 6.7


Guide de migration : 6.6 vers 6.7

Les mises à jour sont seulement supportées d'une version à celle qui la suit immédiatement.

Veuillez lire et bien comprendre ce processus avant de l'essayer. Concernant les machines critiques ou physiquement distantes, testez-la sur un système local identique d'abord.

Commencez par effectuer les étapes de préparation de la mise à jour. Ensuite, démarrez depuis le noyau d'installation 'bsd.rd' : utilisez un media d'installation de démarrage, ou placez la version 6.7 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 (U)pgrade et suivez les instructions.

Une méthode de mise à niveau sans assistance introduite dans la version 6.6 fournit une méthode simple pour assurer cette mise à jour. Le programme sysupgrade(8) téléchargera tous les ensembles d'installations, vérifiera leurs signatures, et redémarrera pour faire la mise à niveau. L'utilisation de cette méthode signifie que sysupgrade s'occupe du téléchargement et de la vérification de bsd.rd à votre place.

Une autre option est d'utiliser le processus manuel de mise à jour (qui toutefois n'est pas recommandé et est la méthode la plus susceptible d'entrainer des erreurs).

Après la mise à niveau des ensembles d'installation, appliquez les changements de configuration et supprimer les vieux fichiers. Terminez par la mise à jour des paquets : pkg_add -u.

Vous pouvez vérifier la page d'errata pour obtenir tous les correctifs post-installation.

Avant d'utiliser une méthode de mise à niveau

  • Vérifiez l'espace disque de /usr. Vérifiez que la partition /usr a au moins 1.1 Go. Avec moins d'espace la mise à niveau peut échouer, vous devriez considérer de réinstaller le système complètement à la place.
  • rpki-client(8). Le nouvel utilisateur _rpki-client réutilise les identifiants utilisateur et groupe de l'utilisateur du démon “named” (named, uid/gid 70) qui a été supprimé en 2014. Si vous avez continué à mettre à jour votre système depuis lors et n'avez jamais supprimé l'utilisateur et le groupe, supprimez-les ainsi que le répertoire /var/named :
    # userdel named
    # groupdel named
    # rm -rf /var/named  # sauvegardez les données si c'est encore nécessaire


    Si vous ne les avez pas supprimés avant la mise à niveau, sysmerge(8) échouera et aura besoin d'être à nouveau exécuté après leur suppression manuelle.


Avant de redémarrer vers le noyau d'installation

* 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. (Cette étape peut être sautée si vous utilisez sysupgrade(8) puisqu'il vérifie les fichiers téléchargés).

Vérifiez les en utilisant signify(1) :

$ signify -C -p /etc/signify/openbsd-67-base.pub -x SHA256.sig bsd.rd
  Signature Verified
  bsd.rd: OK
  • Lire les changements de configuration et de syntaxe. Il y a de nombreux changements de configuration qui peuvent requérir une planification avant de démarrer la mise à jour.

Changement de configuration et de syntaxe

  • audio(4)/midi(4). Les utilisateurs réguliers ne peuvent plus accéder aux dispositifs /dev/audio* et /dev/rmidi*. Les utilisateurs réguliers doivent utiliser l'utilitaire sndioctl(1) à la place de mixerctl(1) pour ajuster le volume, par exemple :
    $ sndioctl output.level=0.5 


    Comme l'accès aux dispositifs MIDI est maintenant fourni par sndiod(8), les programmes doivent utiliser midi/N au lieu de rmidi/N comme noms de port MIDI.

    Notez que les dispositifs audio continuent d'être configurés avec mixerctl(1) puisque sndioctl(1) n'expose pas tous les contrôles de dispositifs audio. De plus, sndioctl(1) n'est pas conçu pour être exécuté en tant que root.

    En conséquence, les dispositifs /dev/mixer* ne sont plus utilisés.

  • iked(8). iked(8) ne bloque plus automatiquement les paquets IPv6 sortants non chiffrés. Cette fonctionnalité était intentionnelle pour éviter des fuites accidentelles, mais dans la pratique, elle s'est avérée être une source de mauvaise configuration. À la place, si vous voulez explicitement bloquer de tels paquets, ajoutez la ligne suivante à /etc/ipsec.conf (et non pas iked.conf) :
    flow esp out from ::/0 to ::/0 type deny

    puis activez son chargement ainsi :

    # rcctl enable ipsec           # pour chargement au démarrage
    # ipsecctl -f /etc/ipsec.conf  # pour chargement immédiat


    Si vous utilisiez précédemment le drapeau -6 d'iked(8) pour désactiver cette fonctionnalité, cela n'est plus nécessaire et devrait être supprimé de /etc/rc.conf.local s'il était utilisé.

  • iked(8)/isakmpd(8). Le type de flux ipsec(4) entrant installé par iked(8) ou isakmpd(8) a été modifié de “use” par “require”. Cela signifie que le trafic non chiffré correspondant à ce flux ne sera plus accepté. Les flux de type “use” peuvent encore être paramétrés manuellement dans ipsec.conf(5).
  • ip(4)/ip6(4). Les paquets à destination d'une adresse ne correspondant pas avec l'adresse IP de l'interface d'entrée seront maintenant supprimés à moins que la redirection d'IP soit activée. La redirection d'IP peut être activée via sysctl.conf(5) :
    net.inet.ip.forwarding=1
    net.inet6.ip6.forwarding=1 


    Notez que lorsque la redirection est activée, toutes les adresses IP locales peuvent être atteintes à moins d'être explicitement filtrées avec pf(4).

  • man.conf(5). La directive _whatdb de man.conf(5) n'est plus supportée. Si vous l'avez dans le fichier /etc/man.conf, changez les lignes de la forme :
    _whatdb /usr/share/man/whatis.db

    vers cete forme :

    manpath /usr/share/man


    La directive _whatdb est dépréciée depuis 2015.

  • npppd(8). Le support pour utiliser tun(4) en tant que concentrateur d'accès avec npppd(8) a été supprimé. Cette fonctionnalité a été déplacée dans le pilote dédié d'interface réseau pppac(4). Pour migrer vers ce nouveau pilote, remplacez l'utilisation des interfaces tun dans npppd.conf(5) par pppac.
  • rebound(8). rebound(8) a été supprimé. Il est conseillé aux utilisateurs de considérer des alternatives telle qu'unwind(8).
  • unwind(8). asr a été renommé en stub dans unwind.conf(5).
    unwind(8) n'utilisera plus http pour détecter les portails captifs. Les sections captive portal existantes doivent être supprimées dans unwind.conf(5).
  • usb(4)/uhid(4). Les permissions par défaut des nœuds de dispositifs usb(4) et uhid(4) ont été changées pour un accès restreint en lecture-écriture à l'utilisateur root.

    L'accès aux clés de sécurité FIDO/U2F est maintenant fourni par le pilote fido(4) à la place d'uhid(4). Les programmes doivent utiliser /dev/fido/N au lieu de /dev/uhidN pour U2F/FIDO.
  • weekly(8). TMPDIR ne sera plus propagé pour locate.updatedb dans weekly(8). Les valeurs personnalisées de TMPDIR pour paramètrer locate.updatedb dans la crontab de root ou dans /etc/weekly.local devraient être déplacées dans /etc/locate.rc.

Fichiers à supprimer

  • Supprimez les fichiers qui ne sont plus inclus dans la version “current” de perl(1) :
    # rm -rf /usr/libdata/perl5/*/Storable \
           /usr/libdata/perl5/*/arybase.pm \
           /usr/libdata/perl5/*/auto/arybase \
           /usr/libdata/perl5/B/Debug.pm \
           /usr/libdata/perl5/Locale/{Codes,Country,Currency,Language,Script}* \
           /usr/libdata/perl5/Math/BigInt/CalcEmu.pm \
           /usr/libdata/perl5/unicore/To/_PerlWB.pl \
           /usr/libdata/perl5/unicore/lib/GCB/EB.pl \
           /usr/libdata/perl5/unicore/lib/GCB/GAZ.pl \
           /usr/share/man/man3p/B::Debug.3p \
           /usr/share/man/man3p/Locale::{Codes*,Country,Currency,Language,Script}.3p \
           /usr/share/man/man3p/Math::BigInt::CalcEmu.3p \
           /usr/share/man/man3p/arybase.3p
  • dig(1), host(1), et nslookup(1) ont été déplacés vers /usr/bin alors les anciens binaires devraient être supprimés.
    # rm -f /usr/sbin/{dig,host,nslookup}

Paquets spécifiques

  • databases/postgresql. Il y a une mise à jour majeure vers PostgreSQL 12.1. Utilisez pg_upgrade tel que décrit dans le fichier pkg-readme ou faites un dump/restore.
  • databases/redis. Redis a été mis à jour vers 5.0.9. Les utilisateurs devraient ne pas avoir de problème de migration depuis 4.0 vers 5.0. Une liste de changements rétroactifs incompatibles est à la fin des notes de version détaillées. Veuillez noter que la base de données est automatiquement mise à niveau à la première exécution et ne peut être lue par d'anciennes versions - prenez soin de faire une sauvegarde préalable si vous êtes concerné par la compatibilité.
  • devel/ipython. Le support de Python 2 a été retiré. /usr/local/bin/ipython-3 a été renommé en /usr/local/bin/ipython.
  • net/isc-bind. Les versions actuelles de BIND insiste sur le fait qu'un répertoire de travail “working directory” soit disponible. Un simple correctif pour mettre à jour les utilisateurs est d'ajouter directory “/tmp” à la section des options dans named.conf. Si vous utilisez des chemins relatifs dans votre configuration, ils auront aussi besoin d'être mis à jour en tant que répertoire “directory” à utiliser de base. Tous les chemins dans named.conf sont relatif au répertoire de chroot, /var/named.
  • net/powerdns. La mise à niveau de PowerDNS Authoritative Server 4.3.0 requiert un changement de schéma de DB. Pour les détails, lisez les notes de mise à jour et /usr/local/share/doc/pdns.
  • www/jupyter-notebook. Jupyter-notebook a été mis à niveau vers 6.0.3, ce qui a supprimé le support de Python 2. Les notebooks existants devraient être vérifiés pour fonctionner avec Python 3. Veuillez noter que les outils fournis par ce paquet ont été renommés, e.g. jupyter-notebook-3 a été renommé en jupyter-notebook.
  • www/mozilla-firefox. Précédement, désactiver pledge était effectué en modifiant une entrée dans about:config mais maintenant cela est fait en utilisant les fichiers dans /etc/firefox, tel qu'expliqué dans le fichier pkg-readme, /usr/local/share/doc/pkg-readmes/firefox. Unveil a été ajouté à firefox pour restreindre ses accès au système de fichier par défaut. Pour garantir des accès à des chemins additionnels ou pour désactiver unveil, lisez le fichier pkg-readme.

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 les 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ésolution 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 effectivement fait à la fin de chaque mise à niveau. Si cela a été négligé, alors le fait de ne pas le faire maintenant pourrait rendre non-fonctionnels la console série ou d'autres choses, selon votre plate-forme. Utilisez installboot(8), en supposant que sd0 soit 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 une alerte inoffensive

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 archives tar, puis redémarrez. Installez base67.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 noyau. Soit, vous décompressez les jeux de fichiers nécessaires manuellement :

cp /sbin/reboot /sbin/oreboot
tar -C / -xzphf xshare67.tgz
tar -C / -xzphf xserv67.tgz
tar -C / -xzphf xfont67.tgz
tar -C / -xzphf xbase67.tgz
tar -C / -xzphf man67.tgz
tar -C / -xzphf game67.tgz
tar -C / -xzphf comp67.tgz
tar -C / -xzphf base67.tgz    # Installez en dernier !
/sbin/oreboot

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

cp /sbin/reboot /sbin/oreboot
for _f in [!b]*67.tgz base67.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. Exécutez 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 configuration système. Exécutez 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 console 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.

[ FAQ Index ] | [ 6.5 -> 6.6 ]


Cette page est la traduction officieuse de la page “Upgrade Guide: 6.6 to 6.7” 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.


openbsd.org/faq/upgrade67.txt · Dernière modification: 2020/05/21 12:11 de pengouinpdt