OBSD4* : wiki

Version de traduction basée sur la 6.4 officielle (v1.10 : 29/10/2018)


Guide de migration : 6.3 vers 6.4

Les mises à jour ne sont seulement supportées que d'une version qui suit la précédente immédiatement. Veuillez lire et bien comprendre ce processus avant de l'essayer. Concernant les machines critiques ou physiquement distantes, testez-la à l'identique sur un système local 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.4 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. 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-64-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 requièrent une planification avant la mise à jour, les plus notables sont bgpd.conf(5), pf.conf(5) et smtpd.conf(5). De plus, rtadvd(8) a été remplacé par le nouveau rad(8).

_rad réutilise les uid/gid de _bt. Le nouvel utilisateur _rad recycle les identifiants utilisateur et groupe de l'utilisateur “Bluetooth Daemon” (_btd) qui a été supprimé en 2013. Si vous avez mis à niveau votre système depuis et que vous n'avez jamais supprimé l'utilisateur, supprimez les :

# userdel _btd
# groupdel _btd 

Si vous ne le faites pas avant la mise à jour, sysmerge(8) échouera et vous aurez besoin de l'exécuter à nouveau manuellement après leur suppression.

Changement de configuration et de syntaxe

  • enregistrement audio. Du fait des problématiques de confidentialité, l'enregistrement audio a été désactivé par défaut. Il peut être ré-activé par :
    # sysctl kern.audio.record=1 # enable at runtime
    # echo kern.audio.record=1 >> /etc/sysctl.conf # set at boot


    Des contrôles plus fins sont disponibles par l'usage de mixerctl(1) : pour chaque périphérique mixer, record.enable peut être paramétré sur off (toujours éteint), on (toujours actif), ou sysctl (par défaut : suit l'état du paramètre kern.audio.record de sysctl).

  • bgpd.conf(5) : Sans une politique de configuration explicite, bgpd(8) refusera l'entrée et la sortie d' UPDATES. Lisez la RFC 8212 pour plus d'informations.
    Les directives de configuration suivantes sont dépréciées (mais seront acceptées pour raison de rétro-compatibilité) : announce all, announce none, et announce default-route. Toutefois, la directive announce self a été supprimée. L'utilisation explicite d' announce self aura pour résultat une annonce d'erreur de syntaxe empêchant bgpd(8) de démarrer. Les utilisateurs seront avertis de revoir et mettre à jour /etc/bgpd.conf avant la mise à niveau.
    Il est possible d'écrire des fichiers de configuration qui soient valides et fonctionnels avant et après la mise à niveau.
    • Avant la mise à jour :
      1. Mimez le nouveau comportement du bpgd(8) mise à jour en ajoutant deny from et deny to any au début du jeu de règles de filtrage. (Après la mise à niveau ces règles sont implicitement ajoutées au filtrage).
      2. Remplacez toutes les instances de announce self par announce all.
      3. Assurez-vous que seul le jeu de règles de filtrage permet correctement les annonces de et vers les voisins EBGP en spécifiant explicitement les préfixes à être importer depuis et à exporter vers les voisins EBGP en utilisant prefix-set et large-community (ou community).
      4. Ajoutez announce all vers tous les proches pour lesquels ni announce none ni announce default-route n'est spécifié (la valeur implicite par défaut pour les pairs EBGP était announce self). Vous pouvez confirmer que vous n'en avez pas manqué par :
        # bgpd -nvf /etc/bgpd.conf | grep -B4 'announce self' 


        La configuration résultante devrait maintenant être prête pour la mise à jour. Il est recommandé de revoir /etc/examples/bgpd.conf pour les exemples sur comment les communautés BGP et prefix-set peuvent être utilisées dans une conception de réseau simple.

    • Après la mise à jour :
      1. Supprimez toutes les directives announce all de la configuration
      2. Les règles deny from et deny to any en début du jeu de règles de filtrage sont redondantes après la mise à niveau (et en tant que telles peuvent être supprimées), mais les laisser peut améliorer la lisibilité de la configuration.
  • hostname.if(5) et wpakey : l'utilitaire ifconfig(8) encourage les utilisateurs du mot-clé wpakey à l'utiliser sur la même ligne que tout mot-clé any join ou nwid. En particulier, le fichier hostname.if(5) devrait être ajusté ainsi :
    nwid mynwid wpakey mywpakey 
  • httpd.conf(5) : le sens de listen on * port 80 a changé. La signification de listen on * port 80 changed a changé de sens, de “listen on all IPv4 addresses” vers “listen on all IPv4 and all IPv6 addresses”. Si listen on * port 80 est présent, listen on :: port 80 doit être supprimé. Par exemple :
      listen on * port 80
      listen on :: port 80

    doit être changé par :

     listen on * port 80 
  • httpd.conf(5) : l'option root strip est renommée. Pour être sémantiquement correct, l'option root strip a été renommée en request strip. Par exemple, le bloc de configuration suivant est nécessaire pour acme-client(1) :
      location "/.well-known/acme-challenge/*" {
    	root "/acme"
    	request strip 2
      }
  • installurl(5) : OpenBSD a un nouveau CDN pour les paquets, syspatches, et les autres téléchargements. Si vous voulez l'utiliser, remplacez votre fichier installurl(5) actuel de telle manière :
      # echo "https://cdn.openbsd.org/pub/OpenBSD" > /etc/installurl 
  • nsd(8) : le contrôle des sockets est passé de TCP/IP vers les sockets unix domain. Si nsd(8) est démarré avec l'ancien fichier de configuration et que le fichier de configuration est modifié pour utiliser les sockets unix domain, rc(8) et rcctl(8) ne peuvent pas redémarrer nsd puisqu'ils essayent de communiquer sur les sokets unix domain alors que nsd(8) continue d'utiliser TCP/IP. Dans ce cas, tuez nsd(8) et démarrez-le à nouveau. Une manière de mettre fin à cette situation est lorsque sysmerge a besoin d'être exécuté à la main.
  • pf.conf(5) : erreur sur les définitions de queue invalides. Les queues PF peuvent seulement référer une seule interface, et non pas un groupe d'interface. Précédemment, l'analyseur de pf.conf(5) acceptait les définitions de queue invalide (soit pour un groupe d'interface, ou pour une interface non existante), et ignorer la plupart d'entre elles, bien que restituant une erreur lors de l'affichage des queues. Elles sont maintenant rejetées, le résultat étant que le jeu de règles entier échoue à se charger.
    Avant de mettre à niveau, utilisez pfctl -s queue. Si vous n'avez pas de sortie ou de listes de queues, vous ne devriez pas être affecté par cela. Si vous voyez l'erreur suivante, ajustez votre pf.conf(5) en accord avec :
      # pfctl -s queue
      pfctl: DIOCGETQSTATS: Bad file descriptor 


    Normalement, vous pouvez juste spécifier le nom de l'interface en question, mais si vous essayez d'utiliser des groupes d'interface pour permettre l'usage du même fichier pf.conf sur de multiples systèmes qui ont des types d'interfaces différentes, vous voudrez peut-être définir des macros dans un fichier séparé qui peut être différent sur chacun des systèmes (partageant un pf.conf commun) :

      $ cat /etc/pf.conf.local
      egress_if = ix0
    
      $ cat /etc/pf.conf
      include "/etc/pf.conf.local"
      queue rootq on $egress_if bandwidth 1G default
    
      [...] 
  • relayd.conf(5) : nouvelles options de log. Les options de log updates et log all dans relayd.conf(5) ont été remplacées par ces trois nouvelles options :
      log state changes
      log host checks
      log connection [errors] 


    Les deux premières paramètrent l'enregistrement des contrôles d'hôtes, soit sur les changements de l'état de l'hôte seulement ou sur les résultats de toutes les vérifications, et remplace log updates et log all. La troisième option contrôle l'enregistrement des connexions aux relais qui, jusqu'à maintenant, était un effet secondaire des mises à jour de l'enregistrement des journaux. Les erreurs secondaires causeront seulement la perte des connexions qui devraient être journalisées.
    L'utilisation des anciennes options aura pour résultat un message d'alerte et elles seront supprimées dans OpenBSD 6.5.

  • route(8) : erreur sur le mauvais usage de -netmask ou -prefixlen. Si vous spécifiez ces options avant l'adressage dans hostname.if(5) ou dans certains scripts, route(8) affichera maintenant un message d'erreur et s'arrêtera. Assurez-vous de changer :
      route add -inet6 -prefixlen 56 2001:db8:: ::1 -blackhole 

    en

      route add -inet6 2001:db8:: -prefixlen 56 ::1 -blackhole 

    ou, mieux, utilisez la notation CIDR :

      route add -inet6 2001:db8::/56 ::1 -blackhole 


    Précédemment, une route pour 2001:db8::/64 aurait été installée car la chaîne d'adressage est la dernière pour laquelle la longueur du préfixe 64 par défaut était implicite.

  • route(8) : longueur implicite du préfixe supprimée. À moins que -prefixlen ou la notation CIDR ne soit utilisée, route(8) n'interprète plus une adresse IPv6 comme sous réseau /64.
    Précédemment, une route avec le préfixe /64 devait être installé :
      # route add 2001:db8:: ::1
      add net 2001:db8::: gateway ::1
      # route show -inet6 | grep 2001:db8
      2001:db8::/64      localhost          UGS        0        0 32768     8 lo0 


    Ce comportement a été déprécié en 2003 par la RFC 3587. L'utilitaire route(8) prend l'adresse de l'hôte telle quelle :

      2001:db8::         localhost          UGHS       0        0 32768     8 lo0 
  • route(8) : syntaxe réseau plus stricte. Le support dans route(8) pour deviner le masque réseau de l'ancien style d'écriture des classes A, B, C à partir de la notation en par points des adresses IPv4 en comptant les octets de fin à zéro a été supprimé, et l'analyse des options relatives est maintenant plus stricte. Pour spécifier un réseau de destination, utilisez une des syntaxes suivantes :
      route add [-net] 192.0.2.0/24 ...
      route add [-net] 192.0.2.0 -netmask 255.255.255.0 ...
      route add -inet [-net] 192.0.2.0 -prefixlen 24 ... 


    Si ni -net, ni -netmask ou ni -prefixlen n'est renseigné, -host est maintenant assumé.

  • rtadvd(8) supprimé ; remplacé par rad(8). rtadvd(8) a été supprimé du système de base. Si vous exécuté rtadvd(8) pour les annonces d'avertissements IPv6 de routeur, veuillez basculer vers rad(8). En premier, créez un fichier de configuration /etc/rad.conf. Par exemple, si avez rtadvd_flags=em0 dans votre /etc/rc.conf.local, /etc/rad.conf devrait contenir :
      interface em0 


    Pour des configurations plus avancées, consultez rad.conf(5). Avec le fichier /etc/rad.conf en place, vous pouvez arrêter rtadvd(8) et démarrer rad(8) :

      # rcctl stop rtadvd
      # rcctl disable rtadvd
      # rcctl enable rad
      # rcctl start rad 
  • smtpd.conf(5): set et limit supprimés des mots clés pricipaux. La grammaire permet la configuration des options de composants avec le mot clé set :
      set queue compression
      set mta max-deferred 100 


    Le mot clé n'a apporté aucune valeur et a été supprimé en faveur de l'espace de noms des composants :

      queue compression
      mta max-deferred 100 


    En plus, l'option limit qui pouvait être utilisée avec mta :

      limit mta session-transaction-delay 0 

    est maintenant une option dans l'espace de nom mta :

      mta limit session-transaction-delay 0 
  • smtpd.conf(5) : la syntaxe du relais hôte a changé. La syntaxe de la chaîne smarthost dans les règles de relais a été mise à niveau. Elle est documentée dans smtpd.conf(5). Les changements sont les suivants :
    • l'option spécifique +auth a été supprimée : il est impliqué par la présence d'un label auth dans le reste de la chaîne.
    • secure:// a été supprimé : utilisez explicitement smtp+tls:// ou smtps://.
    • tls:// a été remplacé par smtp+tls://.
    • smtp:// devient SMTP avec l'opportuniste STARTTLS : utilisez smtp+notls:// pour désactiver TLS.
    • smtp+tls:// devient SMTP avec le mandataire STARTTLS : utilisez smtp:// pour l'opportuniste STARTTLS.
      Exécuter smtpd(8) sans mettre à jour la configuration aura pour conséquence que les mails restent stockés dans la queue si la chaîne smarthost n'est pas reconnue, ou ils seront relayés par TLS au lieu de texte, pour les relais smtp:// et smtp+tls:// non mis à niveau.
  • sndio(7) : le chemin des cookies de session a changé. Le nouveau chemin des cookies de session de sndio(7) est ~/.sndio/cookie. Si vous autorisez l'accès à votre matériel audio/MIDI à d'autres utilisateurs ou systèmes à distance, vous voudrez peut-être déplacer votre cookie d'autorisation vers le nouvel emplacement :
      $ mkdir -p ~/.sndio
      $ mv ~/.aucat_cookie ~/.sndio/cookie 


    C'est probablement plus simple que supprimer l'ancien cookie, en générer un nouveau et l'installer dans tous les endroits appropriés.

Fichiers à supprimer

  • Supprimer /dev/audio et /dev/audioctl. Les liens symboliques /dev/audio et /dev/audioctl ne sont plus du tout utilisés et peuvent être supprimés :
      rm /dev/audio /dev/audioctl 
  • Supprimer rtadvd(8) :
      rm /etc/rc.d/rtadvd /usr/sbin/rtadvd /usr/share/man/man5/rtadvd.conf.5 /usr/share/man/man8/rtadvd.8 
  • Supprimez le groupe et l'utilisateur _rtadvd :
      userdel _rtadvd
      groupdel _rtadvd 
  • Dans le cadre de la mise à jour de xcb 1.13, les deux composants obsolètes de la libxcb (xevie et xprint) ont été supprimés. Les fichiers correspondants peuvent être supprimés :
      rm /usr/X11R6/lib/libxcb-xevie.*
      rm /usr/X11R6/lib/libxcb-xprint.*
      rm /usr/X11R6/lib/pkgconfig/xcb-xevie.pc
      rm /usr/X11R6/lib/pkgconfig/xcb-xprint.pc 

Paquets spécifiques

  • buildbot/buildslave. buildbot et buildbot-worker utilisent maintenant tous les deux python3.
    Il y a quelques temps, buildslave a été renommé en amont en buildbot-worker. En accord, le script rc buildslave a été renommé en buildbot_worker. Vous avez besoin d'ajuster la liste des services :
      # rcctl disable buildslave
      # rcctl enable buildbot_worker 


    Assurez vous d'arrêter toutes les instances buildslave en fonctionnement avant la mise à niveau, autrement rc.d(8) perdra la trace des processus.

  • La version PHP par défaut a changée. À quelques exceptions près, la plupart des paquets utilisant PHP ont basculés vers l'usage des dépendances pour PHP 7.0, par défaut. Parce que les modules d'extension (incluant maintenant les modules PECL) sont mis en paquets pour les multiples versions de PHP, la plupart des programmes PHP existants fonctionneront, mais pour éviter la confusion et bénéficier des améliorations de PHP, vous devriez basculer votre système :
    1. Fusionnez les changements locaux de configuration de /etc/php-5.6.ini vers /etc/php-7.0.ini. Il peut être utile d'utiliser diff(1) sur le fichier original dans /usr/local/share/examples/php-5.6/php.ini-production.
    2. Créez de nouveaux liens symboliques pour les modules d'extensions tel que décrit dans la section extension modules de /usr/local/share/doc/pkg-readmes/php-7.0*.
    3. Basculez sur l'exécution la nouvelle version. Si vous utilisez php-fpm :
          # rcctl disable php56_fpm; rcctl enable php70_fpm
          # rcctl stop php56_fpm; rcctl start php70_fpm 


      Si vous utilisez le module pour httpd d'Apache, mettez à jour le lien symbolique de /var/www/conf/modules/php.conf tel que montré dans le pkg-readme.

  • Changement des paquets PHP. Le module PHP pour httpd d'Apache a été supprimé du paquet principal de PHP vers un paquet “php-apache” séparé, et les extensions PHP pour SQLite ont été déplacés dans les paquets php-sqlite3 et php-pd_sqlite. Si vous les utilisez, installez la version en question (par exemple, pkg_add php-apache%7.0, pkg_add php-sqlite3%7.0, pkg_add php-pdo_sqlite%7.0, ou les versions similaires pour 5.6). Pour les extensions SQLite, créez des liens symboliques pour activer les modules tels que montrés dans le pkg-readme. FPM et CLI restent dans le paquet principal de PHP.
  • Le format de stockage de security/kc change. Le format de stockage des porte-clés ont changés de manière à être incompatible avec un retour en arrière. Sauvegardez tous vos porte-clés en XML avant la mise à niveau :
      $ kc -k ~/.kc/default.kcd
      Password:
      <example_chain% > dump kcdump
      Dump OK
      <example_chain% > quit 


    Après la mise à niveau, suivez les instructions dans /usr/local/share/doc/kc/Changelog.

  • Le client SMTP a été supprimé dans sysutils/apcupsd. La ${PREFIX}/sbin/smtp a été supprimée du paquet apcupsd en faveur de smtp(1). Les programmes n'ont pas d'options compatibles, ainsi tous les scripts utilisant une commande smtp requièrent des ajustements.

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

cp /sbin/reboot /sbin/oreboot
tar -C / -xzphf xshare64.tgz
tar -C / -xzphf xserv64.tgz
tar -C / -xzphf xfont64.tgz
tar -C / -xzphf xbase64.tgz
tar -C / -xzphf man64.tgz
tar -C / -xzphf game64.tgz
tar -C / -xzphf comp64.tgz
tar -C / -xzphf base64.tgz    # Installez en dernier !
/sbin/oreboot

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

cp /sbin/reboot /sbin/oreboot
for _f in [!b]*64.tgz base64.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.3 to 6.4” 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.