Procédure

1. Assurez-vous que votre système a été enregistré avec succès auprès du Red Hat Content Delivery Network (CDN) ou de Red Hat Satellite à l'aide du Gestionnaire d'abonnement Red Hat.
2. Si vous avez enregistré votre système auprès du serveur Satellite, suivez les étapes de la section Préparation d'un système enregistré auprès du serveur Satellite pour la mise à niveau afin de vous assurer que votre système répond aux exigences de la mise à niveau.

3. Vérifiez que l'abonnement au serveur Red Hat Enterprise Linux est attaché. Par exemple :

   # subscription-manager list --installed
   +-------------------------------------------+
       	  Installed Product Status
   +-------------------------------------------+
   Product Name:  	Red Hat Enterprise Linux x86_64
   Product ID:     479
   Version:        8.6
   Arch:           x86_64
   Status:         Subscribed

4. Assurez-vous que les référentiels appropriés sont activés. La commande suivante active les dépôts Base et AppStream pour l'architecture Intel 64 bits ; pour les autres architectures, voir les dépôts RHEL 8.

   # subscription-manager repos --enable rhel-8-for-x86_64-baseos-rpms --enable rhel-8-for-x86_64-appstream-rpms

   Note

   En option, vous pouvez activer les référentiels CodeReady Linux Builder (également connu sous le nom d'Optional) ou Supplementary. Pour plus d'informations sur les ID de référentiel, voir Référentiels RHEL 8. Pour plus d'informations sur le contenu de ces référentiels, voir le manifeste des paquets.

5. Pour les systèmes abonnés à l'aide de RHSM, verrouillez le système sur la version du système d'exploitation source souhaitée :

   # subscription-manager release --set <source_os_version>

   Remplacez <source_os_version> par la version du système d'exploitation source, par exemple 8.6.

6. Facultatif : Pour utiliser des référentiels personnalisés, voir l'article de la base de connaissances Configurer les référentiels personnalisés.

7. Si vous utilisez le plugin dnf versionlock pour verrouiller les paquets à une version spécifique, effacez le verrou en exécutant la commande suivante

   # dnf versionlock clear

   Voir Comment restreindre dnf à l'installation ou à la mise à niveau d'un paquetage vers une version spécifique fixe ? pour plus d'informations.

8. Si vous effectuez une mise à niveau en utilisant Red Hat Update Infrastructure (RHUI) sur un cloud public, activez les dépôts RHUI requis et installez les paquets RHUI requis afin de vous assurer que votre système est prêt pour la mise à niveau :

   1. Pour AWS :

      # dnf config-manager --set-enabled rhui-client-config-server-8
      # dnf -y install rh-amazon-rhui-client-ha leapp-rhui-aws

   2. Pour Microsoft Azure :

      # dnf config-manager --set-enabled rhui-microsoft-azure-rhel8
      # dnf -y install rhui-azure-rhel8 leapp-rhui-azure

   3. Pour Google Cloud Platform, suivez l'article de la base de connaissances Leapp RHUI packages for Google Cloud Platform (GCP).

9. Mettre à jour tous les paquets vers la dernière version de RHEL 8 :

   # dnf update

10. Redémarrer le système :

    # reboot

11. Installez l'utilitaire Leapp:

    # dnf install leapp-upgrade

    Notez qu'actuellement vous avez besoin de la version 0.15.1 ou plus récente du paquet leapp et de la version 0.18.0 ou plus récente du paquet leapp-repository, qui contient le paquet RPM leapp-upgrade-el8toel9.

    Note

    Si votre système ne dispose pas d'un accès à Internet, téléchargez les paquets suivants à partir du portail client de Red Hat:

    • leapp
    • leapp-deps
    • python3-leapp
    • leapp-upgrade-el8toel9
    • leapp-upgrade-el8toel9-deps

12. Assurez-vous d'avoir accès à la dernière version des fichiers de données supplémentaires requis, y compris les modifications apportées aux paquets RPM, le mappage des dépôts RPM et les pilotes et périphériques non pris en charge.

    1. Si vous utilisez RHSM pour la mise à niveau, que le système a accès à cloud.redhat.com et que vous n'avez pas téléchargé une version antérieure des fichiers de données requis, aucune autre action n'est requise de votre part. Les fichiers de données sont automatiquement téléchargés depuis cloud.redhat.com.
    2. Si vous accédez à Red Hat CDN à l'aide d'un serveur proxy, définissez la variable d'environnement $LEAPP_PROXY_HOST afin d'accéder à la dernière version des fichiers de données requis.

    3. Si nécessaire, téléchargez les fichiers de données joints à l'article de la base de connaissances intitulé Leapp utility metadata in-place upgrades of RHEL for disconnected upgrades et placez-les dans le répertoire /etc/leapp/files/. Cette opération est nécessaire à la réussite de la mise à niveau dans les scénarios suivants :

       1. Vous effectuez une mise à niveau sur un nuage public en utilisant RHUI. Si vous ne disposez pas d'un abonnement Red Hat ou d'un compte Red Hat Customer Portal, créez un abonnement de développeur RHEL gratuit afin de pouvoir accéder à l'article de la base de connaissances et télécharger les paquets de données requis. Pour plus d'informations, voir Comment obtenir un abonnement gratuit de développeur Red Hat Enterprise Linux ou le renouveler ?
       2. Votre système n'a pas d'accès à l'internet.
       3. Vous utilisez RHSM pour la mise à niveau et vous avez précédemment téléchargé une ancienne version des fichiers de données requis, mais vous n'avez pas effectué la mise à niveau, par exemple pour créer des scripts automatisés. Vous pouvez également supprimer votre ancienne version des fichiers de données pour lancer le téléchargement automatique de la dernière version des fichiers.
13. Désactiver temporairement le logiciel antivirus pour éviter que la mise à niveau n'échoue.

14. Veiller à ce qu'aucun système de gestion de la configuration n'interfère avec le processus de mise à niveau en place :

    • Si vous utilisez un système de gestion de la configuration avec une architecture client-serveur, tel que Puppet, Salt, ou Chef, désactivez le système avant d'exécuter la commande leapp preupgrade. N'activez le système de gestion de la configuration qu'une fois la mise à niveau terminée afin d'éviter tout problème pendant la mise à niveau.

    • Si vous utilisez un système de gestion de la configuration avec une architecture sans agent, tel que Ansible, n'exécutez pas le fichier de configuration et de déploiement, tel qu'un playbook Ansible, pendant la mise à niveau en place, comme décrit dans Exécution de la mise à niveau de RHEL 8 vers RHEL 9.

      L'automatisation du processus de pré-mise à niveau et de mise à niveau à l'aide d'un système de gestion de la configuration n'est pas prise en charge par Red Hat. Pour plus d'informations, voir Utilisation de systèmes de gestion de configuration pour automatiser certaines parties du processus de pré-mise à niveau et de mise à niveau de Leapp sur Red Hat Enterprise Linux.

15. Assurez-vous que votre système n'utilise pas plus d'une carte d'interface réseau (NIC) avec un nom basé sur le préfixe utilisé par le noyau (eth). Pour savoir comment migrer vers un autre schéma de dénomination avant une mise à niveau sur place vers RHEL 9, voir Comment effectuer une mise à niveau sur place vers RHEL 8 lors de l'utilisation de noms de cartes d'interface réseau du noyau sur RHEL 7. Le processus de migration des schémas de nommage est le même pour la mise à niveau de RHEL 7 vers RHEL 8 et la mise à niveau de RHEL 8 vers RHEL 9.
16. Si votre base de données NSS a été créée sous RHEL 7 ou une version antérieure, vérifiez qu'elle a été convertie du format DBM au format SQLite. Pour plus d'informations, voir Mise à jour des bases de données NSS de DBM à SQLite.
17. RHEL 9 ne prend pas en charge l'ancien package network-scripts, qui a été supprimé dans RHEL 8. Avant la mise à niveau, déplacez vos scripts réseau personnalisés et écrivez un script de distribution NetworkManager qui exécute vos scripts personnalisés existants. Pour plus d'informations, voir Migration des scripts réseau personnalisés vers des scripts de distribution NetworkManager.
18. Si vous effectuez une mise à niveau à l'aide d'une image ISO, vérifiez que l'image ISO contient la version du système d'exploitation cible, par exemple RHEL 9.0, et qu'elle est enregistrée sur un point de montage local persistant afin de garantir que l'utilitaire Leapp puisse accéder à l'image tout au long du processus de mise à niveau.
19. Assurez-vous de disposer d'une sauvegarde complète du système ou d'un instantané de la machine virtuelle. Vous devriez pouvoir ramener votre système à l'état antérieur à la mise à niveau si vous suivez les procédures standard de reprise après sinistre dans votre environnement. Par exemple, vous pouvez utiliser l'utilitaire Relax-and-Recover (ReaR). Pour plus d'informations, consultez la documentation ReaR et la page Qu'est-ce que Relax and Recover (ReaR) et comment puis-je l'utiliser pour la reprise après sinistre ? Vous pouvez également utiliser des instantanés LVM ou le fractionnement RAID. En cas de mise à niveau d'une machine virtuelle, vous pouvez créer un instantané de l'ensemble de la machine virtuelle.

Procédure

1. Vérifiez que Satellite est sur une version avec un support complet ou de maintenance. Pour plus d'informations, consultez le cycle de vie du produit Red Hat Satellite.
2. Importez un manifeste d'abonnement avec des référentiels RHEL 9 dans le serveur Satellite. Pour plus d'informations, consultez le chapitre Gestion des abonnements Red Hat dans le Guide de gestion du contenu pour la version particulière de Red Hat Satellite, par exemple, pour la version 6.12.

3. Activez et synchronisez tous les référentiels RHEL 8 et RHEL 9 requis sur le serveur satellite avec les dernières mises à jour pour les versions du système d'exploitation source et cible. Les référentiels requis doivent être disponibles dans la vue de contenu et activés dans la clé d'activation associée.

   Note

   Pour les référentiels RHEL 9, activez la version du système d'exploitation cible, par exemple RHEL 9.0, de chaque référentiel. Si vous n'activez que la version RHEL 9 des référentiels, la mise à niveau en place est inhibée.

   Par exemple, pour l'architecture Intel sans abonnement Extended Update Support (EUS), activez au minimum les dépôts suivants :

   • Red Hat Enterprise Linux 8 pour x86_64 - AppStream (RPMs)

     rhel-8-for-x86_64-appstream-rpms

     x86_64 8 ou <source_os_version>

   • Red Hat Enterprise Linux 8 pour x86_64 - BaseOS (RPMs)

     rhel-8-for-x86_64-baseos-rpms

     x86_64 8 ou <source_os_version>

   • Red Hat Enterprise Linux 9 pour x86_64 - AppStream (RPMs)

     rhel-9-for-x86_64-appstream-rpms

     x86_64 <target_os_version>

   • Red Hat Enterprise Linux 9 pour x86_64 - BaseOS (RPMs)

     rhel-9-for-x86_64-baseos-rpms

     x86_64 <target_os_version>

     Remplacez <source_os_version> et <target_os_version> par la version du système d'exploitation source et la version du système d'exploitation cible, par exemple, 8.6 et 9.0.

     Pour les autres architectures, voir les référentiels RHEL 8 et RHEL 9.

     Pour plus d'informations, consultez le chapitre Importing Content dans le site Managing Content Guide pour la version particulière de Red Hat Satellite, par exemple, pour la version 6.12.

4. Attachez l'hôte de contenu à une vue de contenu contenant les référentiels RHEL 8 et RHEL 9 requis.

   Pour plus d'informations, consultez le chapitre Managing Content Views dans le site Managing Content Guide pour la version particulière de Red Hat Satellite, par exemple, pour la version 6.12.

Vérification

1. Vérifiez que les bons référentiels RHEL 8 et RHEL 9 ont été ajoutés à la bonne vue de contenu sur le serveur Satellite.

   1. Dans l'interface web de Satellite, naviguez jusqu'à Content > Lifecycle > Content Views et cliquez sur le nom de la vue de contenu.

   2. Cliquez sur l'onglet Repositories et vérifiez que les référentiels apparaissent comme prévu.

      Note

      Vous pouvez également vérifier que les référentiels ont été ajoutés à la vue Contenu à l'aide des commandes suivantes :

      # hammer repository list --search 'content_label ~ rhel-8' --content-view <content_view_name> --organization <organization> --lifecycle-environment <lifecycle_environment>
      # hammer repository list --search 'content_label ~ rhel-9' --content-view <content_view_name> --organization <organization> --lifecycle-environment <lifecycle_environment>

      Remplacer <content_view_name> par le nom de la vue de contenu, <organization> par l'organisation et <lifecycle_environement> par le nom de l'environnement du cycle de vie.

2. Vérifiez que les bons référentiels RHEL 9 sont activés dans la clé d'activation associée à la vue de contenu :

   1. Dans l'interface web de Satellite, naviguez vers Content > Lifecycle > Activation Keys et cliquez sur le nom de la clé d'activation.
   2. Cliquez sur l'onglet Repository Sets et vérifiez que les statuts des référentiels requis sont Enabled.

Procédure

1. Sur votre système RHEL 8, effectuez la phase de pré-mise à niveau :

   # leapp preupgrade

   • Si vous utilisez des référentiels personnalisés du répertoire /etc/yum.repos.d/ pour la mise à niveau, activez les référentiels sélectionnés comme suit :

     # leapp preupgrade --enablerepo <repository_id1> --enablerepo <repository_id2> ...

   • Si vous effectuez une mise à niveau sans RHSM ou en utilisant RHUI, ajoutez l'option --no-rhsm.
   • Si vous avez un abonnement Extended Upgrade Support (EUS), Advanced Update Support (AUS) ou Update Services for SAP Solutions (E4S), ajoutez l'option --channel <channel> option. Remplacez <channel> par le nom du canal, par exemple, eus, aus, ou e4s. Notez que les clients SAP HANA doivent effectuer la mise à niveau in situ en utilisant le guide Comment mettre à niveau in situ des environnements SAP de RHEL 8 à RHEL 9.

2. Examinez le rapport dans le fichier /var/log/leapp/leapp-report.txt et résolvez manuellement tous les problèmes signalés. Certains problèmes signalés contiennent des suggestions de remédiation. Inhibitor problèmes vous empêchent de procéder à la mise à niveau tant que vous ne les avez pas résolus.

   Le rapport contient les niveaux de facteurs de risque suivants :

   Haut

   Il est très probable que cela entraîne une détérioration de l'état du système.

   Moyen

   Peut avoir un impact à la fois sur le système et sur les applications.

   Faible

   Ne devrait pas avoir d'incidence sur le système, mais peut en avoir sur les applications.

   Info

   Information sans impact attendu sur le système ou les applications.

3. Dans certaines configurations du système, l'utilitaire Leapp génère des questions vraies ou fausses auxquelles vous devez répondre manuellement. Si le rapport de pré-mise à niveau contient un message Missing required answers in the answer file, procédez comme suit :

   1. Ouvrez le fichier /var/log/leapp/answerfile et passez en revue les questions vrai ou faux.

   2. Modifiez manuellement le fichier /var/log/leapp/answerfile file, décommentez la ligne de confirmation du fichier en supprimant le symbole #, et confirmez votre réponse en tant que True ou False. Pour plus d'informations, voir le fichier de réponse Leapp.

      Note

      Vous pouvez également répondre à la question "vrai ou faux" en exécutant la commande suivante :

      # leapp answer --section <question_section>.<field_name>=<answer>

      Par exemple, pour confirmer une réponse True à la question Are all VDO devices, if any, successfully converted to LVM management?, exécutez la commande suivante :

      # leapp answer --section check_vdo.confirm=True

4. Répétez les étapes précédentes pour réexécuter le rapport de pré-mise à niveau afin de vérifier que vous avez résolu tous les problèmes critiques.

Procédure

1. Installer le plug-in cockpit-leapp:

   # dnf install cockpit-leapp

2. Connectez-vous à la console web en tant que root ou en tant qu'utilisateur disposant d'autorisations pour entrer des commandes administratives avec sudo. Voir Gestion des systèmes à l'aide de la console web RHEL 8 pour plus d'informations sur la console web.

3. Sur votre système RHEL 8, effectuez la phase de pré-mise à niveau soit à partir de l'interface de ligne de commande, soit à partir du terminal de la console web :

   # leapp preupgrade

   • Si vous utilisez des référentiels personnalisés du répertoire /etc/yum.repos.d/ pour la mise à niveau, activez les référentiels sélectionnés comme suit :

     # leapp preupgrade --enablerepo <repository_id1> --enablerepo <repository_id2> ...

   • Si vous effectuez une mise à niveau sans RHSM ou en utilisant RHUI, ajoutez l'option --no-rhsm.
   • Si vous avez un abonnement Extended Upgrade Support (EUS), Advanced Update Support (AUS) ou Update Services for SAP Solutions (E4S), ajoutez l'option --channel <channel> option. Remplacez <channel> par le nom du canal, par exemple, eus, aus, ou e4s. Notez que les clients SAP HANA doivent effectuer la mise à niveau in situ en utilisant le guide Comment mettre à niveau in situ des environnements SAP de RHEL 8 à RHEL 9.

4. Dans la console web, sélectionnez Upgrade Report dans le menu de navigation pour passer en revue tous les problèmes signalés. Les problèmes Inhibitor vous empêchent de procéder à la mise à niveau tant que vous ne les avez pas résolus. Pour visualiser un problème en détail, sélectionnez la ligne pour ouvrir le volet Détails.

   Figure 4.1. Rapport de mise à jour sur place dans la console web

   

   Le rapport contient les niveaux de facteurs de risque suivants :

   Haut

   Il est très probable que cela entraîne une détérioration de l'état du système.

   Moyen

   Peut avoir un impact à la fois sur le système et sur les applications.

   Faible

   Ne devrait pas avoir d'incidence sur le système, mais peut en avoir sur les applications.

   Info

   Information sans impact attendu sur le système ou les applications.

5. Dans certaines configurations, l'utilitaire Leapp génère des questions vraies ou fausses auxquelles vous devez répondre manuellement. Si le rapport de mise à niveau contient une ligne Missing required answers in the answer file, procédez comme suit :

   1. Sélectionnez la ligne Missing required answers in the answer file pour ouvrir le volet Detail. La réponse par défaut est indiquée à la fin de la commande de remédiation.
   2. Pour confirmer la réponse par défaut, sélectionnez Add to Remediation Plan pour exécuter la remédiation ultérieurement ou Run Remediation pour exécuter la remédiation immédiatement.

   3. Pour sélectionner une réponse autre que celle par défaut, exécutez la commande leapp answer dans le terminal, en précisant la question à laquelle vous répondez et la réponse que vous avez confirmée.

      # leapp answer --section <question_section>.<field_name>=<answer>

      Par exemple, pour confirmer une réponse True à la question Are all VDO devices, if any, successfully converted to LVM management?, exécutez la commande suivante :

      # leapp answer --section check_vdo.confirm=True

      Note

      Vous pouvez également éditer manuellement le fichier /var/log/leapp/answerfile, décommenter la ligne de confirmation du fichier en supprimant le symbole # et confirmer votre réponse en tant que True ou False. Pour plus d'informations, voir l'exemple de fichier de réponse Leapp.

6. Certains problèmes ont des commandes de remédiation que vous pouvez exécuter pour résoudre automatiquement les problèmes. Vous pouvez exécuter les commandes de remédiation individuellement ou toutes ensemble dans la commande de remédiation.

   1. Pour exécuter une seule commande de remédiation, ouvrez le volet Detail pour le problème et cliquez sur Run Remediation.

   2. Pour ajouter une commande de remédiation au plan de remédiation, ouvrez le volet Detail pour le problème et cliquez sur Add to Remediation Plan.

      Figure 4.2. Volet de détail

      
   3. Pour exécuter le plan de remédiation contenant toutes les commandes de remédiation ajoutées, cliquez sur le lien Remediation plan dans le coin supérieur droit au-dessus du rapport. Cliquez sur Execute Remediation Plan pour exécuter toutes les commandes listées.
7. Après avoir examiné le rapport et résolu tous les problèmes signalés, répétez les étapes 3 à 7 pour réexécuter le rapport et vérifier que vous avez résolu tous les problèmes critiques.

Procédure

1. Assurez-vous qu'il n'y a pas de refus SELinux, par exemple en utilisant l'utilitaire ausearch:

   # ausearch -m AVC,USER_AVC -ts boot

   Notez que l'étape précédente ne couvre que le scénario le plus courant. Pour vérifier tous les refus SELinux possibles, voir la section Identifier les refus SELinux dans le titre Utiliser SELinux, qui fournit une procédure complète.

2. Ouvrez le fichier /etc/selinux/config dans un éditeur de texte de votre choix, par exemple :

   # vi /etc/selinux/config

3. Configurez l'option SELINUX=enforcing:

   # This file controls the state of SELinux on the system.
   # SELINUX= can take one of these three values:
   #       enforcing - SELinux security policy is enforced.
   #       permissive - SELinux prints warnings instead of enforcing.
   #       disabled - No SELinux policy is loaded.
   SELINUX=enforcing
   # SELINUXTYPE= can take one of these two values:
   #       targeted - Targeted processes are protected,
   #       mls - Multi Level Security protection.
   SELINUXTYPE=targeted

4. Enregistrez la modification et redémarrez le système :

   # reboot

Vérification

1. Après le redémarrage du système, confirmez que la commande getenforce renvoie Enforcing:

   $ getenforce
   Enforcing

Procédure

1. Trouvez le fichier de flux de données de conformité à la sécurité approprié .xml:

   $ ls /usr/share/xml/scap/ssg/content/
   ...
   ssg-rhel9-ds.xml
   ...

   Pour plus d'informations, voir la section Afficher les profils de conformité.

2. Remédier au système en fonction du profil sélectionné dans le flux de données approprié :

   # oscap xccdf eval --profile pci-dss --remediate /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

   Vous pouvez remplacer la valeur pci-dss dans l'argument --profile par l'ID du profil selon lequel vous souhaitez renforcer votre système. Pour une liste complète des profils pris en charge dans RHEL 9, voir Profils de sécurité SCAP pris en charge dans RHEL.

   Avertissement

   Si elle n'est pas utilisée avec précaution, l'exécution de l'évaluation du système avec l'option --remediate activée peut rendre le système non fonctionnel. Red Hat ne fournit aucune méthode automatisée pour annuler les changements effectués par les remédiations de renforcement de la sécurité. Les remédiations sont prises en charge sur les systèmes RHEL dans la configuration par défaut. Si votre système a été modifié après l'installation, l'exécution de la remédiation pourrait ne pas le rendre conforme au profil de sécurité requis.

3. Redémarrez votre système :

   # reboot

Vérification

1. Vérifiez que le système est conforme au profil et enregistrez les résultats dans un fichier HTML :

   $ oscap xccdf eval --report pcidss_report.html --profile pci-dss /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

Procédure

1. Sauvegardez vos fichiers *.conf stockés dans le répertoire /etc/usbguard/.
2. Utilisez le site usbguard generate-policy pour générer un nouveau fichier de règles. Notez que la commande génère des règles uniquement pour les périphériques USB actuellement présents.

3. Comparer les règles nouvellement générées avec les règles de la politique précédente :

   1. Si vous constatez des différences entre les règles applicables aux dispositifs présents lors de la création de la nouvelle politique et les règles applicables aux mêmes dispositifs avant la mise à niveau, modifiez les règles d'origine en conséquence, y compris pour les dispositifs susceptibles d'être insérés ultérieurement.
   2. S'il n'y a pas de différences entre les règles nouvellement générées et les règles antérieures à la mise à niveau, vous pouvez utiliser les fichiers de stratégie créés dans RHEL 8 sans aucune modification.

1. Arrêter le service :

   # systemctl stop fapolicyd

2. Supprimer la base de données :

   # fapolicyd-cli --delete-db

3. Start the service:

   # systemctl start fapolicyd

Procédure

1. Définissez NSS_DEFAULT_DB_TYPE sur sql dans le système :

   # export NSS_DEFAULT_DB_TYPE=sql

2. Utiliser la commande de conversion dans chaque répertoire^[1] rHEL contient des fichiers de base de données NSS au format DBM, par exemple :

   # certutil -K -X -d /etc/ipsec.d/

   Notez que vous devez fournir un mot de passe ou un chemin d'accès à un fichier de mots de passe comme valeur de l'option -f si votre fichier de base de données est protégé par un mot de passe, par exemple :

   # certutil -K -X -f /etc/ipsec.d/nsspassword -d /etc/ipsec.d/