Procedure

1. If you previously performed an in-place upgrade from RHEL 7 to RHEL 8, remove the /root/tmp_leapp_py3 directory if it is present on your system:

   # rm -rf /root/tmp_leapp_py3

   Important

   If the /root/tmp_leapp_py3 directory is present on your system when you perform the upgrade, the system might break following the upgrade.

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

4. Verify that you have the Red Hat Enterprise Linux Server subscription attached. For example:

   # 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

5. 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

   You can also have the CodeReady Linux Builder or Supplementary repositories enabled; see their list in RHEL 8 repositories. In such a case, Leapp enables the RHEL 8 CodeReady Linux Builder or the RHEL 8 Supplementary repositories, respectively. For more information, see the Package manifest.

6. For systems subscribed using RHSM, lock the system to RHEL 8.6:

   # subscription-manager release --set 8.6

7. Optional: If you want to use custom repositories, configure them per instructions in Configuring custom repositories.

8. If you use the dnf versionlock plug-in 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.

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

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

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

    # dnf update

11. Reboot the system:

    # reboot

12. Install the Leapp utility:

    # dnf install leapp-upgrade

    Note that currently you need version 0.14.0 or later of the leapp package and version 0.16.0 or later of the leapp-repository package.

    Note

    If your system does not have internet access, you can download the Preupgrade Assistant and Red Hat Upgrade Tool from the Red Hat Customer Portal.

13. Ensure you have access to the latest version of additional required data files, including RPM package changes, RPM repository mapping, and unsupported drivers and devices.

    1. If you are using RHSM for the upgrade, the system has access to cloud.redhat.com, and you have not downloaded an earlier version of the required data files, no further action is required from you. The data files are automatically downloaded from cloud.redhat.com. This also applies to developer subscriptions.

    2. Download the data files attached to the Knowledgebase article Leapp utility metadata in-place upgrades of RHEL for disconnected upgrades and place them in the /etc/leapp/files/ directory. Note that currently you need data files from the leapp-data17.tar.gz archive or later. This is necessary for a successful upgrade in the following scenarios:

       1. You are upgrading on a public cloud using RHUI. If you do not have a Red Hat subscription or Red Hat Customer Portal account, create a no-cost RHEL developer subscription so that you can access the Knowledgebase article and download required data packages. For more information, see How do I get a no-cost Red Hat Enterprise Linux Developer Subscription or renew it?
       2. Your system does not have internet access.
       3. You are using RHSM for the upgrade and you previously downloaded an older version of the required data files but did not perform the upgrade, for example to create automated scripts. You can also delete your older version of the data files to initiate the automatic download of the latest file version.
14. Temporarily disable antivirus software to prevent the upgrade from failing.

15. 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 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.

16. 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.
17. 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.
18. RHEL 9 does not support the legacy network-scripts package that was deprecated in RHEL 8. Before you can upgrade, 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.
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 Subscriptions chapter in the Content Management Guide for the particular version of Red Hat Satellite, for example, for version 6.10.

3. Enable and synchronize all required RHEL 8 and RHEL 9 repositories with the latest updates for RHEL 8.6 and RHEL 9.0.

   Note

   For RHEL 9 repositories, make sure to enable version 9.0 of each repository. If you have enabled 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 9.0

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

     rhel-8-for-x86_64-baseos-rpms

     x86_64 9.0

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

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

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 Content Management Guide for the particular version of Red Hat Satellite, for example, for version 6.10.

Procedure

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

   # leapp preupgrade --target 9.0

   • If you are going to use 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 going to upgrade 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, for example eus, aus, or e4s.

2. Provide answers to each question required by Leapp by either of the following methods:

   • Execute the leapp answer command, 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 there no VDO devices on the system?, execute the following command:

     # leapp answer --section check_vdo.no_vdo_devices=True

   • Manually edit the /var/log/leapp/answerfile file, uncomment the last line of the file by deleting the # symbol, and confirm your answer as True or False; see Leapp answerfile.
3. Examine the report in the /var/log/leapp/leapp-report.txt file, and manually resolve all the reported problems before proceeding with the in-place upgrade.

Procedure

1. Install the cockpit-leapp plug-in:

   # dnf install cockpit-leapp

2. Navigate to the web console in your browser and log in as root or as a user configured in the /etc/sudoers file. 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 --target 9.0

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

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

   • If you are going to upgrade 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, for example eus, aus, or e4s.

4. In the web console, select In-place Upgrade Report from the left menu.

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

   

   The report table provides an overview of the problems found, their risk assessment, and remediations (if available).

   • Risk factor:

     • 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
   • Inhibitor - will inhibit (hard stop) the upgrade process, otherwise the system could become unbootable, inaccessible, or dysfunctional

   • Remediation - an actionable solution to a reported problem:

     • Remediation command - can be executed directly through the web console
     • Remediation hint - instructions on how to resolve the problem manually

5. Examine the content of the report. You can sort the table by clicking a header. To open a detail pane, click a selected row.

   Figure 4.2. Detail pane

   

   The detail pane displays the following additional information:

   • Summary of the problem and links to Knowledgebase articles describing the problem in more detail
   • Remediations - you can run or schedule an automated remediation (if available), and see its results when applied
   • Affected system resources: packages, repositories, files (configuration, data), disks, volumes

6. Optionally filter the results. Click the Filters button in the top left corner above the report and apply a filter based on your preferences. Filter categories are applied in conjunction with one another.

   Figure 4.3. Filters

   

7. Select issues for which you want to apply an automated remediation. You have two options:

   1. Choose individual items by clicking the Add to Remediation Plan button in the detail pane. Alternatively, you can execute individual remediations directly by clicking Run Remediation in the detail pane.
   2. Select all items for which a remediation is available by clicking the Add all remediations to plan button in the top right corner above the report.

8. Review and answer questions required by Leapp in the web console. Each unanswered question appears as a Missing required answers in the answer file title in the Upgrade Report. Select a title to answer the question:

   1. To confirm the default True answer, select Add to Remediation Plan to execute the remediation later or Run Remediation to execute the remediation immediately.

   2. To select the non-default answer instead, perform either of the following:

      1. Execute the leapp answer command, 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 there no VDO devices on the system?, execute the following command:

         # leapp answer --section check_vdo.no_vdo_devices=True

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

         Figure 4.4. Missing unanswered Leapp question

         

9. Open the remediation plan by clicking the Remediation plan link in the top right corner above the report. The remediation plan provides a list of all executed or scheduled remediations.

   Figure 4.5. Remediation plan

   

10. Process all scheduled remediations by clicking Execute Remediation Plan. The following information is displayed for each remediation entry:

    • A unique ID of the remediation
    • Exit status of the command
    • Elapsed time of the executed remediation
    • Standard output
    • Standard error
11. After executing selected remediations, generate the pre-upgrade report again by using the leapp preupgrade command, examine the new report, and take additional remediation steps if needed.

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/