Procedure

1. Ensure your system has been successfully registered to the Red Hat Content Delivery Network (CDN) or Red Hat Satellite by using the Red Hat Subscription Manager.
2. If you have registered your system to Satellite Server, complete the steps in Preparing a Satellite-registered system for the upgrade to ensure that your system meets the requirements for the upgrade.

3. Verify that the system is subscribed using subscription-manager:

   1. If your system is registered by using an account with Simple Content Access (SCA) enabled, verify that the Content Access Mode is set to Simple Content Access message appears:

      # subscription-manager status
      +-------------------------------------------+
         System Status Details
      +-------------------------------------------+
      Overall Status: Disabled
      Content Access Mode is set to Simple Content Access. This host has access to content, regardless of subscription status.
      System Purpose Status: Disabled

   2. If your system is registered by using an account with SCA disabled, verify that the Red Hat Linux Server subscription is attached, the product name is Server, and the status is Subscribed. For example:

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

4. Ensure you have appropriate repositories enabled. The following command enables the Base and AppStream repositories for the 64-bit Intel architecture; for other architectures, see RHEL 8 repositories.

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

   Note

   Optionally, you can enable the CodeReady Linux Builder (also known as Optional) or Supplementary repositories. For more information about repository IDs, see RHEL 8 repositories. For more information about the content of these repositories, see the Package manifest.

5. Set the system release version:

   1. For systems subscribed using RHSM, lock the system to the desired source OS version:

      # subscription-manager release --set <source_os_version>

   2. If you are upgrading by using Red Hat Update Infrastructure (RHUI) on a public cloud, set the expected system release version manually:

      # rhui-release-set --set <source_os_version>

      Important

      If the rhui-release-set command is not available on your system, you can set the expected system release version by updating the /etc/dnf/vars/release file:

      # echo "<source_os_version>" > /etc/dnf/vars/releasever

      Replace source_os_version with the source OS version, for example 8.8.

6. Optional: To use custom repositories, see the Configuring custom repositories Knowledgebase article.

7. If you use the dnf versionlock plugin to lock packages to a specific version, clear the lock by running:

   # dnf versionlock clear

   See How to restrict dnf to install or upgrade a package to a fixed specific package version? for more information.

8. If you are upgrading by using Red Hat Update Infrastructure (RHUI) on a public cloud, enable required RHUI repositories and install required RHUI packages to ensure your system is ready for upgrade:

   1. For AWS:

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

   2. For Microsoft Azure:

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

   3. For Google Cloud Platform, follow the Leapp RHUI packages for Google Cloud Platform (GCP) Knowledgebase article.

9. Update all packages to the latest RHEL 8 version:

   # dnf update

10. Reboot the system:

    # reboot

11. Install the Leapp utility:

    # dnf install leapp-upgrade

    Note that currently you need version 0.15.1 or later of the leapp package and version 0.18.0 or later of the leapp-repository package, which contains the leapp-upgrade-el8toel9 RPM package.

    Note

    If your system does not have internet access, download the following packages from the Red Hat Customer Portal:

    • leapp
    • leapp-deps
    • python3-leapp
    • leapp-upgrade-el8toel9
    • leapp-upgrade-el8toel9-deps
12. The latest release of the leapp-upgrade-el8toel9 package contains all required data files. If you have replaced these data files with older versions, remove all JSON files in the /etc/leapp/files directory and reinstall the leapp-upgrade-el8toel9 package to ensure your data files are up-to-date.
13. Temporarily disable antivirus software to prevent the upgrade from failing.

14. Ensure that any configuration management system does not interfere with the in-place upgrade process:

    • If you use a configuration management system with a client-server architecture, such as Puppet, Salt, or Chef, disable the system before running the leapp preupgrade command. Do not enable the configuration management system until after the upgrade is complete to prevent issues during the upgrade.

    • If you use a configuration management system with agentless architecture, such as Ansible, do not execute the configuration and deployment file, such as an Ansible playbook, during the in-place upgrade as described in Performing the upgrade from RHEL 8 to RHEL 9.

      Automation of the pre-upgrade and upgrade process by using a configuration management system is not supported by Red Hat. For more information, see Using configuration management systems to automate parts of the Leapp pre-upgrade and upgrade process on Red Hat Enterprise Linux.

15. Ensure your system does not use more than one Network Interface Card (NIC) with a name based on the prefix used by the kernel (eth). For instructions on how to migrate to another naming scheme before an in-place upgrade to RHEL 9, see How to perform an in-place upgrade to RHEL 8 when using kernel NIC names on RHEL 7. The process for migrating naming schemes is the same for both the RHEL 7 to RHEL 8 upgrade and the RHEL 8 to RHEL 9 upgrade.
16. If your NSS database was created in RHEL 7 or earlier, verify that the database has been converted from the DBM database format to SQLite. For more information, see Updating NSS databases from DBM to SQLite.
17. RHEL 9 does not support the legacy network-scripts package, which was deprecated in RHEL 8. Before upgrading, move your custom network scripts and write a NetworkManager dispatcher script that executes your existing custom scripts. For more information, see Migrating custom network scripts to NetworkManager dispatcher scripts.
18. If you are upgrading using an ISO image, verify that the ISO image contains the target OS version, for example, RHEL 9.0, and is saved to a persistent local mount point to ensure that the Leapp utility can access the image throughout the upgrade process.
19. Ensure you have a full system backup or a virtual machine snapshot. You should be able to get your system to the pre-upgrade state if you follow standard disaster recovery procedures within your environment. For example, you can use the Relax-and-Recover (ReaR) utility. For more information, see the ReaR documentation and What is Relax and Recover (ReaR) and how can I use it for disaster recovery?. Alternatively, you can use LVM snapshots, or RAID splitting. In case of upgrading a virtual machine, you can create a snapshot of the whole VM.

Procedure

1. Verify that Satellite is on a version in full or maintenance support. For more information, see Red Hat Satellite Product Life Cycle.
2. Import a subscription manifest with RHEL 9 repositories into Satellite Server. For more information, see the Managing Red Hat Subscriptions chapter in the Managing Content Guide for the particular version of Red Hat Satellite, for example, for version 6.12.

3. Enable and synchronize all required RHEL 8 and RHEL 9 repositories on the Satellite Server with the latest updates for the source and target OS versions. Required repositories must be available in the Content View and enabled in the associated activation key.

   Note

   For RHEL 9 repositories, enable the target OS version, for example, RHEL 9.0, of each repository. If you enable only the RHEL 9 version of the repositories, the in-place upgrade is inhibited.

   For example, for the Intel architecture without an Extended Update Support (EUS) subscription, enable at minimum the following repositories:

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

     rhel-8-for-x86_64-appstream-rpms

     x86_64 8 or <source_os_version>

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

     rhel-8-for-x86_64-baseos-rpms

     x86_64 8 or <source_os_version>

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

     rhel-9-for-x86_64-appstream-rpms

     x86_64 <target_os_version>

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

     rhel-9-for-x86_64-baseos-rpms

     x86_64 <target_os_version>

     Replace <source_os_version> and <target_os_version> with the source OS version and target OS version respectively, for example, 8.6 and 9.0.

     For other architectures, see RHEL 8 repositories and RHEL 9 repositories.

     For more information, see the Importing Content chapter in the Managing Content Guide for the particular version of Red Hat Satellite, for example, for version 6.12.

4. Attach the content host to a Content View containing the required RHEL 8 and RHEL 9 repositories.

   For more information, see the Managing Content Views chapter in the Managing Content Guide for the particular version of Red Hat Satellite, for example, for version 6.12.

Verification

1. Verify that the correct RHEL 8 and RHEL 9 repositories have been added to the correct Content View on Satellite Server.

   1. In the Satellite web UI, navigate to Content > Lifecycle > Content Views and click the name of the Content View.

   2. Click the Repositories tab and verify that the repositories appear as expected.

      Note

      You can also verify that the repositories have been added to the Content View using the following commands:

      # 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>

      Replace <content_view_name> with the name of the Content View, <organization> with the organization, and <lifecycle_environement> with the name of the lifecycle environment..

2. Verify that the correct RHEL 9 repositories are enabled in the activation key associated with the Content View:

   1. In Satellite web UI navigate to Content > Lifecycle > Activation Keys and click the name of the activation key.
   2. Click the Repository Sets tab and verify that the statuses of the required repositories are Enabled.

3. . Verify that all expected RHEL 8 repositories are enabled in the host. For example:

   # subscription-manager repos --list-enabled | grep "^Repo ID"
   Repo ID:   rhel-8-for-x86_64-baseos-rpms
   Repo ID:   rhel-8-for-x86_64-appstream-rpms

Procedure

1. On your RHEL 8 system, perform the pre-upgrade phase:

   # leapp preupgrade

   • If you are using custom repositories from the /etc/yum.repos.d/ directory for the upgrade, enable the selected repositories as follows:

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

   • If you are upgrading without RHSM or using RHUI, add the --no-rhsm option.
   • If you have an Extended Upgrade Support (EUS), Advanced Update Support (AUS), or Update Services for SAP Solutions (E4S) subscription, add the --channel <channel> option. Replace <channel> with the channel name, for example, eus, aus, or e4s. Note that SAP HANA customers should perform the in-place upgrade using the How to in-place upgrade SAP environments from RHEL 8 to RHEL 9 guide.

2. Examine the report in the /var/log/leapp/leapp-report.txt file and manually resolve all the reported problems. Some reported problems contain remediation suggestions. Inhibitor problems prevent you from upgrading until you have resolved them.

   The report contains the following risk factor levels:

   High

   Very likely to result in a deteriorated system state.

   Medium

   Can impact both the system and applications.

   Low

   Should not impact the system but can have an impact on applications.

   Info

   Informational with no expected impact to the system or applications.

3. In certain system configurations, the Leapp utility generates true or false questions that you must answer manually. If the pre-upgrade report contains a Missing required answers in the answer file message, complete the following steps:

   1. Open the /var/log/leapp/answerfile file and review the true or false questions.

   2. Manually edit the /var/log/leapp/answerfile file, uncomment the confirm line of the file by deleting the # symbol, and confirm your answer as True or False. For more information, see the Leapp answerfile.

      Note

      Alternatively, you can answer the true or false question by running the following command:

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

      For example, to confirm a True response to the question Are all VDO devices, if any, successfully converted to LVM management?, execute the following command:

      # leapp answer --section check_vdo.confirm=True

4. Repeat the previous steps to rerun the pre-upgrade report to verify that you have resolved all critical issues.

Procedure

1. Install the cockpit-leapp plug-in:

   # dnf install cockpit-leapp

2. Log in to the web console as root or as a user that has permissions to enter administrative commands with sudo. See Managing systems using the RHEL 8 web console for more information about the web console.

3. On your RHEL 8 system, perform the pre-upgrade phase either from the command-line interface or from the web console terminal:

   # leapp preupgrade

   • If you are using custom repositories from the /etc/yum.repos.d/ directory for the upgrade, enable the selected repositories as follows:

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

   • If you are upgrading without RHSM or using RHUI, add the --no-rhsm option.
   • If you have an Extended Upgrade Support (EUS), Advanced Update Support (AUS), or Update Services for SAP Solutions (E4S) subscription, add the --channel <channel> option. Replace <channel> with the channel name, for example, eus, aus, or e4s. Note that SAP HANA customers should perform the in-place upgrade using the How to in-place upgrade SAP environments from RHEL 8 to RHEL 9 guide.

4. In the web console, select Upgrade Report from the navigation menu to review all reported problems. Inhibitor problems prevent you from upgrading until you have resolved them. To view a problem in detail, select the row to open the Detail pane.

   Figure 4.1. In-place upgrade report in the web console

   

   The report contains the following risk factor levels:

   High

   Very likely to result in a deteriorated system state.

   Medium

   Can impact both the system and applications.

   Low

   Should not impact the system but can have an impact on applications.

   Info

   Informational with no expected impact to the system or applications.

5. In certain configurations, the Leapp utility generates true or false questions that you must answer manually. If the Upgrade Report contains a Missing required answers in the answer file row, complete the following steps:

   1. Select the Missing required answers in the answer file row to open the Detail pane. The default answer is stated at the end of the remediation command.
   2. To confirm the default answer, select Add to Remediation Plan to execute the remediation later or Run Remediation to execute the remediation immediately.

   3. To select the non-default answer instead, execute the leapp answer command in the terminal, specifying the question you are responding to and your confirmed answer.

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

      For example, to confirm a True response to the question Are all VDO devices, if any, successfully converted to LVM management?, execute the following command:

      # leapp answer --section check_vdo.confirm=True

      Note

      You can also manually edit the /var/log/leapp/answerfile file, uncomment the confirm line of the file by deleting the # symbol, and confirm your answer as True or False. For more information, see the Leapp answerfile example.

6. Some problems have remediation commands that you can run to automatically resolve the problems. You can run remediation commands individually or all together in the remediation command.

   1. To run a single remediation command, open the Detail pane for the problem and click Run Remediation.

   2. To add a remediation command to the remediation plan, open the Detail pane for the problem and click Add to Remediation Plan.

      Figure 4.2. Detail pane

      
   3. To run the remediation plan containing all added remediation commands, click the Remediation plan link in the top right corner above the report. Click Execute Remediation Plan to execute all listed commands.
7. After reviewing the report and resolving all reported problems, repeat steps 3-7 to rerun the report to verify that you have resolved all critical issues.

Procedure

1. Ensure that there are no SELinux denials, for example, by using the ausearch utility:

   # ausearch -m AVC,USER_AVC -ts boot

   Note that the previous step covers only the most common scenario. To check for all possible SELinux denials, see the Identifying SELinux denials section in the Using SELinux title, which provides a complete procedure.

2. Open the /etc/selinux/config file in a text editor of your choice, for example:

   # vi /etc/selinux/config

3. Configure the SELINUX=enforcing option:

   # 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. Save the change, and restart the system:

   # reboot

Verification

1. After the system restarts, confirm that the getenforce command returns Enforcing:

   $ getenforce
   Enforcing

Procedure

1. Find the appropriate security compliance data stream .xml file:

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

   See the Viewing compliance profiles section for more information.

2. Remediate the system according to the selected profile from the appropriate data stream:

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

   You can replace the pci-dss value in the --profile argument with the ID of the profile according to which you want to harden your system. For a full list of profiles supported in RHEL 9, see SCAP security profiles supported in RHEL.

   Warning

   If not used carefully, running the system evaluation with the --remediate option enabled might render the system non-functional. Red Hat does not provide any automated method to revert changes made by security-hardening remediations. Remediations are supported on RHEL systems in the default configuration. If your system has been altered after the installation, running remediation might not make it compliant with the required security profile.

3. Restart your system:

   # reboot

Verification

1. Verify that the system is compliant with the profile, and save the results in an HTML file:

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

Procedure

1. Back up your *.conf files stored in the /etc/usbguard/ directory.
2. Use the usbguard generate-policy to generate a new policy file. Note that the command generates rules for the currently present USB devices only.

3. Compare the newly generated rules against the rules in the previous policy:

   1. If you identify differences in the rules for the devices that were present when you generated the new policy and the pre-upgrade rules for the same devices, modify the original rules correspondingly also for devices that might be inserted later.
   2. If there are no differences between the newly generated and the pre-upgrade rules, you can use the policy files created in RHEL 8 without any modification.

1. Stop the service:

   # systemctl stop fapolicyd

2. Delete the database:

   # fapolicyd-cli --delete-db

3. Start the service:

   # systemctl start fapolicyd

Procedure

1. Set NSS_DEFAULT_DB_TYPE to sql on the system:

   # export NSS_DEFAULT_DB_TYPE=sql

2. Use the conversion command in every directory^[1] that contains NSS database files in the DBM format, for example:

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

   Note that you have to provide a password or a path to a password file as a value of the -f option if your database file is password-protected, for example:

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