Red Hat Enterprise Linux 9 Review
July 7, 2023, midnight
Last Updated: July 13, 2023, 3 a.m.
Red Hat Enterprise Linux is the leading Linux distribution used by enterprises. Red Hat, its developer, has built a very successful FOSS business using this core product, generating revenue from RHEL support subscriptions and other large scale technologies built with RHEL at their core.
In 2014, Red Hat took control of CentOS, a community developed clone of RHEL produced by recompiling Red Hat source. In 2020 it changed the CentOS development model and purpose from a binary compatible community supported clone of RHEL to an upstream development testbed for future RHEL releases, situated between RHEL and Fedora and renamed CentOS Stream. In the last month, as this article was nearing publication, Red Hat made another controversial decision: it has stopped publishing the source of Red Hat releases, preventing the clones -- the major ones being Alma Linux and Rocky Linux -- from easily rebuilding and distributing their RHEL compatible distributions.
These actions were controversial, disrupting many organizations relying on a free clone of RHEL. Despite these controversial and -- in the view of some Linux users -- unethical actions, around the same time it took over CentOS, Red Hat made another decision that was beneficial to individual developers by making RHEL available through its Individual Developer Subscription program, even for production use -- with some limitations.
This article reviews RHEL 9 obtained through this Individual Developer Subscription program in July of 2022. The initial installation has been upgraded through the two new minor versions in the 9 series released since the installation -- RHEL 9.1 and 9.2. This review is based on observations of RHEL from the initial installation with the "Server with GUI" software selection through the two minor version updates.
Introduction
When I purchased the Lenovo Legion 5i Pro, I removed the Samsung 970 Evo Plus with which I upgraded the storage on the Dell G5 and installed it in the second NVMe slot of the Lenovo Legion. Since then I replaced the 970 Evo Plus in the Lenovo Legion with a Samsung 980 Pro, making the 970 Evo Plus available again for the Dell G5 which -- while four years old and with an older NVIDIA GPU without the recent architectural changes that allow Runtime D3 Power Management -- is still a decent computer for serious long term experimentation, including someday Linux From Scratch and FreeBSD which I've used as a VM.
For now I am taking advantage of the Individual Developer Subscription and starting experimentation on the Dell G5 with RHEL, specifically RHEL 9, released in May of 2022. The subscription allows -- for no-cost -- download of the installation ISO, a license to install on up to 16 virtual or physical hosts, access to Red Hat repositories for update and installation of the additional Red Hat software technologies, and full access to online resources including documentation. The initial subscription is valid for one year and must be renewed yearly.
The subscription and its relationship to package management and updates, as well as the tools to manage it are described later in the article, but as an introduction to some of its aspects the following set of slides are presented, the first showing one of the pages of the Red Hat Customer Portal which allows subscribers to view and manage the subscription, the second and third showing the re-registration emails, and the last showing two agreements applicable to using RHEL with the Individual Developer Subscription and the dialog where the terms are accepted as part of registering.
`
Renewing the Individual Developer Subscription
The Individual Developer Subscription must be renewed each year, but oddly only after the expiration. Red Hat emails a reminder before and after expiration with a link to re-register in the second email.
Click on any of the thumbnails to view a slideshow of the images.
Click on any of the thumbnails to view a slideshow of the images.
As this installation is for experimentation, I chose some installation characteristics which I usually don't bother with on my primary laptop, or the Acer V15 Nitro Black Edition that is still performing usefully as my entertainment laptop. These novel (for me) installation characteristics include RAID1 mirroring for the / and /home partitions and LUKS2 encryption for the / and /home partition RAID set and the separate /var and /var/tmp partitions -- required to be on separate partitions due to the security profile (described below) chosen for the installed OS.
The storage setup of the installed system is shown in the following set of images of GNOME Disks displaying the disk configuration. The first image shows the first disk's partition layout; notable in this image is that there is a separate /boot partition recommended by the RHEL documentation, the / partition is a RAID member, the /home partition is a RAID member, /tmp is an ext4 LUKS encrypted partition, and /var/tmp is a LUKS encrypted partition. The second image displays the second disk's partition layout; notable in this image are that the second members of the / and /home RAID1 arrays. The third and fourth images are GNOME Disks display of the / amd /home RAID1 arrays, respectively. The Disks utility indicates that both of these RAID arrays are LUKS encrypted.
The Storage Setup of the Installed RHEL 9
The Anaconda installer, also used by Fedora, is very flexible in storage setup allowing RAID configuration and with encryption of the RAID array. I have not seen the ability to configure RAID in any other Linux GUI installer, with the exception of SUSE/openSUSE's YaST.
Click on any of the thumbnails to view a slideshow of the images.
Click on any of the thumbnails to view a slideshow of the images.
The storage setup as it appears in /etc/fstab is shown in the following image. The encrypted and RAID1 mirrored partitions that comprise the / and /home partition and the encrypted /tmp and /var/tmp partitions are logically accessible through Device Mapper and appear as devices at /dev/mapper/......
The /etc/fstab File
I added two external partitions for data after installation, an ext4 partition mounted at /home/brook/G5_DataEXT4 and NTFS partition mounted at /home/brook/G5_DataNTFS. As discussed more fully later in the article, the NTFS partition would not have been usable in RHEL without the ntfs-3g driver distributed by a semi-official repository.
With yearly renewals of the individual developer subscription, this installation will be fully supported through 2032 with minor version releases occurring every six months. The installation will also have available to it a set of important applications with a guaranteed life cycle equal to the 10 year RHEL 9 lifecycle. The lifecycles of the RHEL 8 and 9 series is shown in the following set of slides.
The RHEL 9 Lifecycle
With minor version releases every six months, RHEL 9 will be supported for ten years through 2032.
The seven year overlap in the supported life of the 8 series and the 9 series is a possible explanation for some of the negative aspects of my experience with RHEL 9. Read on for what I observed while using it on and off for almost a year, including my overall positive impression and why the support overlap may have contributed to deficiencies in RHEL 9.
Review
The largest impression I have formed in my first use of Red Hat Enterprise Linux is the extreme focus on security, as it should be for a Linux distribution that is used by extremely large organizations that include, not only large commercial enterprises but government entities with an interest in preserving data confidentiality. This focus is especially apparent when compared to the typical (community) Linux distributions which focus primarily on ease of use and apparently never consider security to the extent that RHEL does. I should qualify this impression with the observation that perhaps other distributions meet the security standards imposed by the certifications but do not go through the actual certification process.
The other major impression I had was with the focus on stability and reliability, achieved with the development, testing, and release sequence that begins with forking a previous Fedora release, which undergoes its own prerelease testing as beta releases. The Fedora base then becomes the basis of development for a CentOS Stream release with the same version number as a an eventual RHEL release. This multiple level of testing beginning with Fedora then continuing to CentOS Stream results in a well tested set of applications and system components. In the case of RHEL 9, this sequence began with the forking of Fedora 34 released in April of 2021 and continued development and testing as CentOS Stream 9, released in December of 2021.
Because of this development and testing timeline the software included is stable but as a result is somewhat older than what might be available in non-enterprise distributions. An important example of this is the Linux kernel, the version included in RHEL 9 being version 5.14.X, released almost a full year before RHEL 9. Stability is also maintained by only distributing a limited set of well supported software needed by enterprise customers in the official RHEL repositories. Further enhancing stability is RHEL is the focus of updates is only to provide bug-fixes and security patches, as exemplified by the fact that after updates through two minor version releases to 9.2 over the past year, the kernel is still at version 5.14, although the patch version has increased due to backpacking of bug and security fixes.
Other observations, further discussed later in the article, include:
- Third-party repositories are essential.
- As mentioned previously, in order to maintain stability, official Red Hat Enterprise Linux repositories distribute only a limited set of software and only software that is of interest to enterprise customers. Also, software that is not strictly FOSS is not distributed by Red Hat. This means that certain essential software, such as an NTFS filesystem driver (which is included in kernel versions newer than that available in RHEL 9), or desirable software for some users, such as the KDE Plasma desktop, and other software of smaller scope, such as the aria2 download manger are not distributed through Red Hat repositories. Fortunately, other semi-official and third-party repos are available to fill the need for software not distributed by Red Hat. These repositories include the EPEL maintained by the Fedora project, RPMFusion, a third-party repository that makes available multimedia codecs and proprietary drivers, community Copr repositories, and repositories provided by upstream developers.
- RHEL 9 is not LSB compliant.
- I found that Red Hat Enterprise Linux 9, months after release, was not LSB compliant. I learned this when attempting to install Epson multifunction printer drivers and management software from RPM packages downloaded from the EPSON support website. Installation of these packages required certain components of an LSB compliant system to be present in the installation target, but were not included in the RHEL installation.
- Version 9.0 seems to be essentially a beta release.
-
In my experience of using RHEL 9.0 since shortly after its release and through updates to RHEL 9.2, it seems to me to be effectively a beta release. Components are more current compared to the RHEL 8 series, which is still currently supported, but the secondary supporting resources do not seem to be ready. For example:
- documentation is not as complete and there isn't a one-to-one relationship between a document covering a certain topic applicable to RHEL 8 and a corresponding document covering the same topic applicable to RHEL 9
- repositories such as the EPEL, while unofficial are essential to RHEL, but packages which were available in RHEL 8 have yet to be built for RHEL 9
- only draft versions of security profiles are available for selection during installation
- Modularity or module streams has been -- in effect -- abandoned in RHEL 9.
- An innovation first developed in Fedora and introduced to RHEL with version 8, Modularity, as it is known in Fedora documentation, or module streams in RHEL documentation has been -- in effect -- abandoned in RHEL 9. This package management technology allows installation of a particular version of an important development or production application to be along with its specific version dependencies as a bundle. The same module streams could also be available in different release versions of RHEL allowing a a specific application version and bundled dependencies to be installed whether the target OS version is RHEL 8, 9, etc. The abandonment of this feature in RHEL 9, or that RHEL 9.0 is effectively a beta release, is evident when comparing the many available module streams in RHEL 8 for installing, for example, PostgreSQL, compared to the only one module stream available in RHEL 9.
Some of the aspects of RHEL 9 introduced above are discussed further in the following sections.
Security
The focus on security is evident in RHEL from the beginning even during installation where the Anaconda installer (familiar to Fedora users) allows specification of various security characteristics. This includes
- system-wide crypto policies and a centralized crypto policy management tool which ensure that recent and appropriately strong encryption algorithms are used as backends in whatever tool or utility requires cryptography
- compliance with various levels of FIPS standards
- compliance with one of various security profiles -- standards created by various organizations that specify system configuration that enhances OS security
Security Profiles
Security profiles which can be applied to the installed system are viewable and selectable in the installer from the Security Profile item in the installer's main hub (first image in following set). Selecting Security Profile advances to a screen in which security profiles are listed with descriptions, and can be selected to be applied to the installed system (second image in following set).
The Anaconda Installer's Navigation Hub Which Includes a Security Profile Navigation Item
Activating Security Profile leads to a screen from which the available security profiles can be viewed and applied to the installed system.
CIS Security Profile
I chose to apply the CIS Red Hat Enterprise Linux 9 Benchmark for Level 1 - Workstation security profile. CIS benchmarks are, according to CIS, the maintainer of the benchmarks,
are prescriptive configuration recommendations for more than 25+ vendor product families. They represent the consensus-based effort of cybersecurity experts globally to help you protect your systems against threats more confidently... The CIS Benchmarks are community-developed secure configuration recommendations for hardening organizations' technologies against cyber attacks. Mapped to the CIS Critical Security Controls (CIS Controls), the CIS Benchmarks elevate the security defenses for cloud provider platforms and cloud services, containers, databases, desktop software, server software, mobile devices, network devices, and operating systems. They also help organizations demonstrate compliance with components of various industry regulations and frameworks.
CIS offers benchmarks for various operating systems on both server and workstation platforms, and at two levels where generally, Level 1 offers security without inhibiting the utility or practicality of the OS past an acceptable point, and Level 2 extends the recommendations of Level 1 benchmarks for use in environments where security is paramount. The title of the benchmark reflects these characteristics. All profiles of CIS benchmarks for a certain operating system and version are documented in a single document, available for download from the CIS Benchmarks List page.
The RHEL 9 CIS Level 1 benchmark for workstations requires as part of the system configuration -- as shown in the secondary window of Anaconda's security profile selection screen -- the noexec and nosuid mount options for the mount point /tmp; nodev and noexec mount options for /var/tmp; and nodev mount option for /home (first image in following set). It also requires that certain packages must be installed, such as firewalld amd rsyslog, and that certain other packages must not be installed, such as telnet, openldap-clients, and xinetd.
The CIS Red Hat Enterprise Linux 9 Benchmark for Level 1 - Workstation as Listed in Anaconda with Other Available Security Profiles
Security Profiles based on standards published by various organizations apply certain security enhancing system configuration items on the installed system.
The list of configuration requirements to comply with the CIS benchmark is actually much, much more extensive than that shown in Anaconda, and covers many more components of the OS and associated supporting applications. Highlights from the RHEL 9 CIS benchmark standards document include:
- specifying separate partitions for various paths in the filesystem hierarchy, such as /var, /var/tmp, /home, and /var/log
- specifying the use of mount options for various mount points that enhance security
- requires mandatory access control, in the case of RHEL requiring the use of SELinux
- requires properly configured command line banners with warnings
- requires certain services to not be installed, such as
- requires hardened network configuration to include, among many others, packet forwarding and redirecting is disabled, broadcast ICMP requests are ignored, and firewall rules are appropriately set
- requires system auditing with auditd
- requires logging is appropriately confiugured
- requires that the SSH server is appropriately configured for security
- requires file permissions to be set configured appropriately
- requires file permissions to be set configured appropriately
Other Security Profiles
In addition to the CIS security profile, as mentioned above, other security profiles are available, some of which are visible as selection items in the secondary screen opened when selecting Anaconda's Security Profile main menu item (shown in images above). Some of these profiles are described below:
- Protection Profile for General Purpose Operating System [Draft]
-
This security profile is primarily based on the Protection Profile for General Purpose Operating Systems Version 4.2.1 published by the NIAP. This standard requires the OS[1] to be configured and have resources such that it is protected from certain threats defined by the standard such as, among others, network attacks, local attacks, and an improper user. These broad requirements are met by functional requirements that specify the type, level, and methods of cryptographic support available on the system. The standard relies on references to other standards in its specifications, for example, various FIPS publications. For more information on this standard see Protection Profile for General Purpose Operating Systems, Version 4.2.1; 2019-04-22.
The description of the profile also mentions that certain system configuration items are derived from the CNSS Instruction No. 1253.
The Configuration Annex to Protection Profile for General Purpose Operating Systems also applies, requiring certain configuration parameters, such as a minimum password length. The requiements of this standard are consistent with CNSS No. 1253.
- PCI-DSS v 3.2.1 Control Baseline for Red Hat Enterprise Linux 9
- DISA STIG for Red Hat Enterprise Linux 9
- DISA STIG for with GUI Red Hat Enterprise Linux 9
- Unclassified Information in Non-federal Information Systems and Organizations (NIST 800-171)
- CIS Red Hat Enterprise Linux for Level 1 Server
- CIS Red Hat Enterprise Linux for Level 2 Server
- CIS Red Hat Enterprise Linux for Level 2 Workstation
FIPS Mode
RHEL can operate in FIPS mode, a mode in which the cryptographic module self-checks required by the FIPS 140-3 standard are enabled. FIPS 140-3 is the latest in a series of standards published by the NIST and refers to a variety of other standards, primarily ISO/IEC 19790:2012(E), Information technology — Security techniques — Security requirements for cryptographic modules.
A kernel command line parameter, fips=1 is available to start the system in FIPS mode. This kernel parameter can also be used when starting the installer, which will enable FIPS mode in the installed system.
Commands are also available to start FIPS mode in a system in which it was not enabled at startup, as well as other commands to manage FIPS mode, the use of one of which -- fips-mode-setup -- is mentioned below.
Crypto Policies
RHEL implements a system to ensure that the cryptographic components are sufficiently current, and thus remain secure, and to ensure that the various applications which use cryptographic back-ends apply the current components consistently. The system includes pre-configured profiles that define allowed cryptographic components and versions: DEFAULT and FIPS. Setting the systemwide crypto policy to FIPS is another method of enabling FIPS mode.
The effectiveness of the system-wide crypto policy framework and that RHEL is more secure with regard to cryptographic components included in the OS compared to most other Linux distributions was evident the first time I attempted to connect to my home WiFi network. I had started the installer with the kernel parameter fips=1 so the installed system was operating in FIPS mode by default. The cryptographic components required by FIPS were not compatible with an old inexpensive Linksys Wi-Fi router from 2019. This required relaxation of the crypto policies, first by disabling FIPS mode with the command
fips-mode-setup --disable
which, in addition to disabling FIPS mode, sets the systemwide crypto policy to DEFAUT. Normally, modifying the systemwide crypto policy would be done with
update-crypto-policies --set DEFAULT
but if trying to set the system-wide crypto policy to the less stringent DEFAULT mode while FIPS mode is enabled, there will be an error stating that the operation can't be performed while FIPS mode is active.
I also saw the effectiveness of the systemwide crypto policy framework of ensuring consistent use of appropriately secure cryptographic components throughout the system in my attempt to modify SSH configuration. Comments in the SSH daemon's configuration indicate that changing parameters related to cryptography in the configuration file have no effect and may only be modified by changing the systemwide crypto policy.
# This system is following system-wide crypto policy. The changes to # crypto properties (Ciphers, MACs, ...) will not have any effect here. # They will be overridden by command-line options passed to the server # on command line. # Please, check manual pages for update-crypto-policies(8) and sshd_config(5).
Other Security Policies
Besides ensuring cryptographic algorithms of adequate strength and FIPS compliance, the overall environment is configured for enhanced security as required by the chosen security profile, at least compared to the many Linux distributions I have used that are not targeted at enterprise use.
One area where the security enhanced configuration is noticeable is the file permission policies reflected in umask, dmask, and fmask. After manually installing Firefox Beta and Firefox Developer Edition, I created .desktop files for these applications by copying the the installed Firefox's .desktop file using sudo to elevate privileges. As the following listing shows, the resulting files did not have read permission for other users whereas the Firefox .desktop file did. This permission setting behavior in RHEL is not the same as in Arch Linux, for example, where the the same operation would set read permission for other users.
[brook@G5-RHEL9 ~]$ ls -l /usr/share/applications/ | grep fire -rw-r-----. 1 root root 9350 Jul 7 01:28 firefox-beta.desktop -rw-r--r--. 1 root root 9288 Jun 23 09:34 firefox.desktop -rw-r-----. 1 root root 9522 Jul 7 01:22 firefox-developer-edition.desktop [brook@G5-RHEL9 ~]$ sudo chmod o+r /usr/share/applications/firefox-beta.desktop [sudo] password for brook: [brook@G5-RHEL9 ~]$ sudo chmod o+r /usr/share/applications/firefox-developer-edition.desktop [brook@G5-RHEL9 ~]$
The GNOME desktop environment is also configured for a high level of security. For example the login screen background includes a warning message "for authorized use only". Also paranoid is that the GNOME Terminal and Nautilus window close after a period of inactivity, something that might annoy some users.
Software and Package Management
The Server with GUI software selection in the installation medium includes the essential software for workstation use, installing GNOME and a standard, but limited set of applications that includes Firefox, Evince document viewer, and GEdit text editor. But the installation can be more than just a desktop OS judging by the "Role" field in the subscription information provided by the output of subscription-manager list --consumed (see second image below). The output lists the "Roles" for the subscribed product as
- Red Hat Enterprise Linux Server
- Red Hat Enterprise Linux Workstation
- Red Hat Enterprise Linux Compute Node
The Output of the subscription-manager list --consumed Command (in Konsole running on the Plasma DE) Showing the Roles of Installed Subscribed Productand the latter provides proprietary multimedia codecs,
Further package installations and updates require a registration of the installation with the Individual Developer Subscription credentials. Additional RHEL repositories besides those already enabled can be added for specialized software; some of these repositories are displayed in the output of subscription-manager list --consumed, shown in the above slides, before the "Roles" list.
The capability to install module streams also exists in order to allow installation of a specific version of important software and bundled dependencies. (However, as mentioned above and discussed more fully below, this capability is limited to the point of insignificance.) Some examples of software that might benefit users by installing as module streams are server and development software such as PostgreSQL and node.js. For this review I only considered installing the NVIDIA GPU driver as a module, however as discussed below, it was only available for the RHEL 8.X series and not for the 9.X series..
Some software that I like to have in my Linux desktop installations were not available in official repositories -- understandably, since this is a commercially supported distribution for enterprise use. This makes semi-official repositories such as the Extra Packages for Enterprise Linux (EPEL), maintained by the Fedora Project for RHEL and its clones -- Rocky Linux, Alma Linux, Scientific Linux, and others, and third-party repositories such as RPMFusion essential for comfortable and flexible use of RHEL on a desktop. The former provides, for example, applications such as KeePassXC and the Plasma desktop environment from KDE; and the latter provides proprietary multimedia codecs and plugins, and an alternative source for NVIDIA drivers as well as other proprietary firmware and software. The Fedora community package build and distribution service, Copr, similar to SUSE/openSUSE's OBS,[2] is also available to RHEL (and its clones), which was necessary for me to install the Starship terminal prompt.
Unfortunately, despite these numerous sources for software I still had to resort to building the KeePassXC package using the RPM build tool rpmbuild. This was necessary even though the EPEL normally distributes this package, as I could see it was available for RHEL 8.6 but not yet built for RHEL 9.0. This, like only draft versions of security profiles being available at installation, is one of the reflections of one of the -- minor -- negative aspects of RHEL in my experience: that some needed resources -- officially supported or unofficial and unsupported -- were not ready for the release.
These and other aspects of software and package management are further discussed below.
Installed Software
The default installation with the Anaconda installer software selection item set to Server with GUI provides a very limited set of software. The set includes
- GNOME Shell 40.9 or, simply, GNOME 40
- Firefox 91.8.0
- GDM 40.1
- GNOME Software 41.4
The following set of images shows the installed software as seen in GNOME shell's overview. Apparently applications added to Favorites are not shown in the grid, because Firefox, for example, installed by default, is not visible in the grid. The same is true for Files, Terminal, and Help. Extensions, shown in the grid was actually installed by me after the OS installation, not included by default.
GUI Software Installed by Default
All of the software shown in the GNOME Shell overview were installed by default except Extensions. Firefox, Files, Terminal, and Help are not visible in the grid, presumably because applications added to Favorites and/or are pinned to the dock are not shown in the overview.
The more system oriented software includes:
- Linux kernel 5.14.0
- CPP 11.2
- systemd 250
- Xorg 1.20.11
Package Management and the Individual Developer Subscription
Registering the Individual Developer Subscription in the installed system is necessary to associate the system to the subscription, enabling the RHEL installation to receive updates from the various Red Hat repositories and to install new software as long as the subscription is active. The About tab of GNOME Settings includes the non-standard item added by Red Hat, Subscription, (first image in following set) which opens a dialog that provides users one of the ways in which they can register the system (second image in following set).
Subscription Item in the About Tab of GNOME Settings and Registration Dialog
Selecting Subscription from the About tab in GNOME Settings opens a dialog in which the subscription credentials can be entered to register the system.
After registering the installation, selecting the item shows the registration status (fourth thumbnail in the following set) instead of the registration dialog. Registering the installation attaches it to the subscription and makes it viewable and manageable in the Red Hat Customer Portal (first - third images in following set).
`
The Subscription Enables Access to Red Hat Repositories for Package Installation and Updates and Access to Red Hat Online Resources
Registration of the installed system is required by accessing "Register" in GNOME Settings. A specialized CLI command is also required in certain operations.
Click on any of the thumbnails to view a slideshow of the images.
Click on any of the thumbnails to view a slideshow of the images.
Unfortunately this registration mechanism initially did have a minor issue: when I tried to perform the first update, the operation resulted in an error message, as shown below. The issue did ultimately resolve itself, maybe after some background communication between the RHEL instance and Red Hat's subscription management servers.
[brook@localhost ~]$ sudo dnf upgrade Updating Subscription Management repositories. This system is registered with an entitlement server, but is not receiving updates. You can use subscription-manager to assign subscriptions. Error: There are no enabled repositories in "/etc/yum.repos.d", "/etc/yum/repos.d", "/etc/distro.repos.d".
I then used the subscription-manager attach --auto command to remedy the problem, which then informed me that there was no problem, as shown below.
[brook@localhost ~]$ sudo subscription-manager attach --auto All installed products are covered by valid entitlements. No need to update subscriptions at this time. Installed Product Current Status: Product Name: Red Hat Enterprise Linux for x86_64 Status: Subscribed
Subscription Management
An important aspect of Red Hat Subscription Management was described above as part of the initial use of the system where the system was registered; here subscription management is described more fully. The Red Hat subscription service consists of three parts:
- the subscription which entitles a customer to certain products
- the products including RHEL and other Red Hat software products
- the physical and virtual systems that "consume" the products
An identity certificate is generated and installed on the system for each of these components for authentication.
Generally, subscription management associates subscriptions and products to which a subscription is entitled to systems which "consume" the products. One possible method of achieving this -- through GNOME settings -- was described above. (Using the GNOME Settings' Subscription item actually performs two of the major subscription management functions listed below.)
The subscription service infrastructure tracks products purchased or available to the subscription, tracks systems on which products are installed, and synchronizes the status of these elements between the systems and remote subscription management infrastructure. More formally, according to Red Hat documentation, Red Hat Subscription Management involves three major tasks:
- registering the system, which is the process which allows the subscription service infrastructure to manage the system
- "attaching" subscriptions to the systems, which associates or allocates a subscription to a particular system on which REHL is installed
- updating the identity certificates, a process which is required when the status of any part of the subscription service changes
Subscription management also involves other minor tasks, such as viewing available and "consumed" products for the subscription. (This was seen earlier in the article when subscription-manager list --consumed was used to show consumed subscriptions.)
Multiple Red Hat Subscription Management tools are available to perform the subscription management, each suitable to a certain type and scale of deployment and organizational needs. The locally installed tool is the Red Hat Subscription Manager which has two interfaces, a CLI activated with the command subscription-manager and a standalone GUI. The standalone GUI components are also built into the GNOME desktop environment, such as the part built into the GNOME Settings component, and the part built into GNOME Shell as actionable notification displayed upon first boot regarding registration status of the system. The use of the GNOME Settings component of the Subscription Manager GUI was described above. The CLI component was also mentioned above in describing a possible solution to an error. Other uses of the subscription-manager are also shown in some of the images of this article.
Although not as obvious, it seems some Subscription Manager functionality is also incorporated into the package management back ends. This is apparent in the initial output of any dnf command which states the status of the subscription. It is also apparent in that Red Hat repositories are shown in the package management GUIs and able to be added using these GUIs.
The other subscription management tool applicable to small scale deployments of RHEL is that which is incorporated into the Red Hat Customer Portal shown in the first image of this article and some other images below. Large scale deployments use Red Hat Sattelite to manage large fleets of servers from an on premises installation.
In my practical experience with RHEL, which included a typical use by a developer as described in Adding a Git Client Node in an Individual Developer Centralized Workflow, the major tasks of subscription management were simply and automatically performed after I intuitively activated the GNOME Settings Subscription item. This registered the system and attached the subscription to the system. The only other task for which the subscription manager tool was necessary was to add some of the optional repositories, where I used the CLI command subscription-manager repos --enable=< repo-name >. This particular task was also able to be performed with the package management GUI. (None of the additional repositories, while containing a lot of Red Hat software technologies, were not useful to me in my first experimental use of RHEL.)
Subscription and Minor Version Updates
As shown in the image of the RHEL 9 lifecycle, near the top of the article, minor versions of RHEL 9 are released every six months. Updates to the identity of the system, i.e whether the installed system is a RHEL 9.0, a RHEL 9.1, or a RHEL 9.2, etc. system, happen automatically depending on the minor version that is current at the time, and is controlled by communication to the Red Hat subscription management server. It does not matter whether the system has actually been updated or not. The actual updating of the software to new minor version releases does not require a special process other than normal package update transactions using the CLI dnf tool, GNOME Software, or even the Plasma desktop environment's Discover, which works well although not officially supported (see the section Plasma Experience, below).
Registration and Subscription Status After RHEL 9.2 Release Before Software Update
The Product Version is updated to the current released minor version even if the installed software is not updated to that available in the current release.
Red Hat Repositories
Red Hat software is primarily distributed through two main repositories enabled at installation, the BaseOS and the AppStream repositories. The non-default and unsupported CodeReady Linux Builder repository is also available to provide additional packages needed by developers. (As discussed later, adding this repository was necessary in order to enable the EPEL.) These repositories are listed in the output of dnf repolist shown in the third image of the following set of images. The enabled non-RHEL repositories, EPEL, RPMFusion, and a COPR repository -- mentioned above and further discussed below -- are also displayed in the output, as well as the single software RPM repositories provided by Google and Vivaldi to distribute their browsers.
Specialized Red Hat software is distributed through other specific repositories also available with the subscription. Some of these are displayed in the output of dnf repolist --all command, shown in the second image of the following set of images. GNOME Software's Software Repositories (first image in the follwing set) and Discover's Settings (fifth image in following set) screens also shows some of these additional official Red Hat repositories. Both of these package management GUIs can also be used to enable the repositories.
Red Hat Distributes Its Numerous Technologies Through Many Official Repositories Not Enabled by Default
The first image shows some of the repositories as visible in GNOME Software (note, the EPEL repository shown as enabled is a third-party repository, see below). The second image shows the same but in the output of sudo dnf repolist --all (in Konsole running on KDE's Plasma DE, installed from the EPEL, see below). The third shows the enabled repositories as listed in the output of sudo dnf repolist
Click on any of the thumbnails to view a slideshow of the images.
Click on any of the thumbnails to view a slideshow of the images.
Additional Red Hat repositories are enabled from GNOME Software, as mentioned above, or with the subscription-manager CLI program. For those who install the Plasma dekstop from the EPEL, KDE's Discover is also installed, which can also be used to enable additional Red Hat repositories. After a repository is added to the installation, it is visible in the Subscriptions status page accessed from GNOME Settings's About tab. The state of this screen after adding the Codeready Linux Builder repository is shown in the fourth image of the above set of images.
App Streams
App Streams are essentially regular versioned RPM packages of userland applications distributed from the repository. App Streams have specific supported life cycle periods that vary between different App Streams. Some have life cycles that coincide with the life cycle of the RHEL release, while others have a life cycle that is shorter. Shorter life cycle applications will be updated periodically as opposed to those whose life cycles coincide with the RHEL release.
Module Streams
When I reviewed Fedora 28 and 32, one of the largest impressions I had of the distribution was of the usefulness of the unique package management technology called Modularity in Fedora documentation. This package management innovation makes different versions of important software for production servers or development available to a system. The RPM packages of a particular application and its dependencies are logically bundled into a module. A module can have multiple versions, called streams or module streams where each module stream contains a particular version of an application and its dependencies. Each module can also have a module profile that defines the set of packages that will be installed as part of a module installation, useful, for example, for only installing the subset of packages in a module necessary for production or for production and development. Modules are distributed from the same repositories as regular unbundled RPMs.
Some of the important commands to manage modules are shown in the following table.
| Action | Command |
|---|---|
| List modules available from enabled repositories | dnf module list |
| List the available streams for a module | dnf module list < module-name > |
| List the details of a module | dnf module info < module-name > |
| Enable a module stream | dnf module enable < module-name:stream > |
| Install a module stream | dnf module install < module-name:stream > |
(For more information on Module Streams and important concepts, such as the interaction of module and non-module package dependencies, see the relevant references at the end of the article.)
Modularity, referred to as simply Modules or Module Streams in Red Hat documentation, was made available in RHEL beginning with the 8 series. It is still available in RHEL 9, however, according to a post in the CentOS forum titled No Modules on Centos 9 Stream, due to the reception of the technology in RHEL 8 the philosophy to its inclusion is evolving in RHEL 9.
The observation in the forum post was reflected in my experience with RHEL 9 beginning with the installed 9.0 and as updated through 9.1 and 9.2. While the underlying package management infrastructure -- i.e. the dnf commands to manage modules -- still exists in RHEL 9, it seems to have been abandoned to a certain extent in that the number of applications delivered as modules and the number of streams for available modules is extremely limited. To illustrate consider the following set of images showing the output of some dnf module commands. The first image shows the output of dnf module list, displaying the available modules by repository in RHEL 9. Only six applications are distributed as modules, seven if including the one module distributed from the Codeready Linux Builder repository, whereas in RHEL 8 over forty applications are distributed as modules, although a few of the modules only offer a single stream. (See REHL 8 Documentation >> Package manifest >> Chapter 2 The Appstream Repository >> The Appstream modules for the full list of applications distributed as streams in RHEL 8.)
Of the applications available as modules in RHEL 8, many have numerous streams available. In RHEL 9, however, of the seven applications that are available as modules, none have more than one stream, defeating Modularity's purpose of making multiple version of an application available bundled with its specific dependencies allowing users to chose the specific version to install according to their needs. This difference between RHELs 8 and 9 is evident when comparing the second image to the fourth image in the following set of images which show the streams available for the PostgreSQL module in RHEL 8 and RHEL 9, respectively. The top of the second image shows the output of dnf module list postgresql in RHEL 9 which lists the single stream available for PostgreSQL, namely version 15 of the application. The fourth image, taken from RHEL 8 documentation, shows the output of yum module list postgresql listing the five streams available for PostgreSQL in RHEL 8, each making a different version of the application available.
Click on any of the thumbnails to view a slideshow of the images.
I hope the commitment to Modularity in Fedora has not changed as I am planning to use its functionality in the near future. But in RHEL 9 my only need for Modularity was as the method documented by NVIDIA for installing a driver for RHEL (not necessarily for graphics in RHEL but for CUDA), as shown in the following image of an NVIDIA documentation webpage. According to the documentation, multiple streams are available, each for a different driver branch. Disappointingly, the NVIDIA documentation only applies to RHEL 8, and the corresponding module streams for RHEL 9 from RHEL 9 repositories are not available. Fortunately, as described below an alternative source is available for the NVIDIA driver for Fedora, RHEL and its clones from which I installed the driver.
iz
NVIDIA Documentation on Installing Driver as a Module Stream
Unfortunately as of July 6 2022, several weeks of release not only did the documentation only refer to RHEL 8, but the modules streams were not available.
Additional Repositories
As previously mentioned, software selection is very limited for desktop applications in official repositories, presumably a necessary tradeoff for the stability by only supporting a limited set of applications. Also, by policy KDE's Plasma desktop and non-KDE Qt applications, and other software, such as the NTFS driver, ntfs-3g are not available in regular RHEL repositories. (Newer kernels have a module available that can be used as an alternative to ntfs-3g, but this is apparently not available in the older kernel version used by RHEL.)
Fortunately, additional software repositories are available, such as the EPEL maintained by Fedora, the third-party RPMFusion repositories, one of the sources for proprietary NVIDIA GPU drivers, and various COPR repositories -- maintained by community members -- for miscellaneous software, such as the Starship command prompt.
EPEL
The EPEL repository, maintained by the Fedora Project, as its name suggests, is a source for extra packages for RHEL not included in the official repositories. Versions of the repository are also available for CentOS Stream and the RHEL clones, Alma Linux and Rocky Linux. In the Fedora project's words
Extra Packages for Enterprise Linux (or EPEL) is a Fedora Special Interest Group that creates, maintains, and manages a high quality set of additional packages for Enterprise Linux, including, but not limited to, Red Hat Enterprise Linux (RHEL), CentOS, Scientific Linux (SL), Oracle Linux (OL), AlmaLinux (AL) and Rocky Linux (RL).
EPEL packages are usually based on their Fedora counterparts and will never conflict with or replace packages in the base Enterprise Linux distributions. EPEL uses much of the same infrastructure as Fedora, including buildsystem, Bugzilla instance, updates manager, mirror manager and more.
In order to enable the EPEL, it is first necessary to enable the Codeready Builder for RHEL 9 repository, with
sudo subscription-manager repos --enable codeready-builder-for-rhel-9-$(arch)-rpms
as shown in the first image of the following set of images.
Then, it was necessary to add the repository by installing a package by URL that contains the repository metadata and signatures:
sudo dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm
The end of the output of this operation is shown in the second image of the following set.
-
-
-
-
qzzqz
Enabling the Extra Packages for Enterprise Linux Repository Maintained by the Fedora Project
Click on any of the thumbnails to view a slideshow of the images.
These steps would normally be enough to enable the EPEL, however, a fix was required to the actual repository configuration file installed by the second step, /etc/yum.repos.d/epel.repo. The necessary fixes are shown in the following image which shows two Konsole window panes with the original version of /etc/yum.repos.d/epel.repo in the bottom pane and the edited version in the top pane. The line that identifies the URI where the metalink definition for the repository had to be commented out as it did not work. The alternative was to uncomment the line that identifies the repository URL and replace the boilerplate domain download.example.com with the actual domain dl.fedoraproject.org.
Necessary Changes to the EPEL Repo File
The repository's metalink definition did not work and the http definition needed to have the boilerplate URL replaced with the actual URL.
The larger of the two disks on the Dell G5 has two partitions for data, one ext4 and one ntfs, both of which I added to /etc/fstab. Unfortunately, in RHEL 9, because the NTFS driver is proprietary, it can not be distributed by Red Hat. (NTFS support has been added in recent versions of the Linux kernel, but is not available in the version included in RHEL.) Fortunately, the EPEL does distribute the ntfs-3g package, previously used by all Linux distributions prior to the inclusion of NTFS support directly in the kernel.
The EPEL also distributes the KDE Plasma desktop environment and KDE applications (See Review >> Plasma Experience below.), as well as other applications not distributed officially through the RHEL repositories.
So the EPEL is necessary for those who prefer an alternative desktop environment, or other applications not distributed by Red Hat. Ii is essential for packages such as ntfs-3g, although other proprietary items must be installed from RPMFusion, discussed below. Unfortunately, as with many aspects of this .0 release, it was not ready at the time of release, with some packages -- KeepassXc and aria2, for example -- available for the 8.X series not yet built for RHEL 9, as evidenced by the following images. The first shows that another KeepassXC user is missing the availability of their favored password manager in the EPEL repository for RHEL 9. The second shows the Fedora build system's webpage for aria2 which indicates stable RPM builds for current and past Fedora versions and past RHEL versions are available, but not for RHEL 9.
(These unavailable packages illustrate that fmailiarity with a chosen dsitribution's default package building tool is useful. I built bouth locally using the PRM package building tool, rpmbuild discussed below as one aspect of software managment.)
I should note despite my complaining about these two packages, the Fedora Project providing this repository is a great service to Red Hat users for essential packages such as ntfs-3g and less essential like aria2. I especially appreciate the fact that this repository provides the KDE Plasma desktop environment and KDE applications.
Some EPEL Packages Are Not Yet Available for RHEL 9 Even Several Weeks After Release
RPMFusion
RPMFusion is a third-party repository that provides proprietary software such as multimedia codecs and drivers for Fedora, RHEL, and RHEL clones. It has been essential for me in order to enable these proprietary components, allowing all use cases of a desktop Linux fully functional. It is also essential for the same reasons for users who install RHEL 9 with a GUI for workstation use. Since NVIDIA drivers were not available as modules as they had been in RHEL 8, this was the only source for a precompiled NVIDIA driver distributed as an RPM package. Adding the repository to the RHEL system only required a single dnf command to install a package from a remote URL as shown in the following listing.
[brook@G5-RHEL9 ~]$ sudo dnf install --nogpgcheck https://mirrors.rpmfusion.org/free/el/rpmfusion-free-release-$(rpm -E %rhel).noarch.rpm https://mirrors.rpmfusion.org/nonfree/el/rpmfusion-nonfree-release-$(rpm -E %rhel).noarch.rpm
Enabling the RPMFusion Repository and Installing Additional Optional NVIDIA Related Packages
RPMFusion is enabled by installing a package directly from an RPMFusion URL using DNF.
COPR
Copr is an online package build system and a collection of user repositories distributing packages built with the build system. A dnf plugin exists (first image in the following set) that provides the dnf subcommand copr which is used to enable and disable Copr repositories.
Like the Arch User Repository, it is a way to obtain software not in official repositories that is shared by the user community, but unlike the AUR it incorporates an online build system, whereas the AUR only distributes the package building recipes -- PKGBUILD files -- and actual building of packages is done on locally the users machine. It is more similar to the openSUSE Build Service which also offers an online build service and user repositories of packages built with the build system. Unlike the OBS which provides the build and repository service to all distributions and many package formats, the Copr limits its build targets to Fedora and related distributions.
In the past, I used the Copr to install more recent versions of the Plasma desktop environment on Fedora. In the current test of RHEL 9, I used the Copr to install the Starship command prompt. The second image below shows the adding of the atim/starship Copr repository in a GNOME terminal window, as well as the project repository's page in Firefox. The third - fifth images show the installation of the starship package using DNF.
The Fedora Projects COPR Package Build and Distribution Service Is Available to Red Hat Enterprise Linux
This repository is available for installing packages not available in Red Hat repositories, the EPEL, or RPMFusion. These images show enabling a Copr repository containing a user built package -- the Starship command prompt -- and installing the package.
Click on any of the thumbnails to view a slideshow of the images.
Click on any of the thumbnails to view a slideshow of the images.
RPM Package Building
When some software is not available in a distribution's repositories or third-party repositories are not available, some Linux users resort to installing software manually, bypassing the system package manager, using the make and make install commands. For the less causal Linux use, familiarity with a distribution's native package building tool is useful for installing software in these situations without bypassing the package manager. And for a large number of Enterprise Linux users, I assume it might be a job requirement. It was useful to me in my use of RHEL to build packages for Aria2, the download manager, and KeePassXC the password manager, which were not available in any of the repositories -- official, semi-official, or third-party.
To use rpmbuild, the RPM package building tool, it was first necessary to install it and other development packages. I then used existing .spec -- the RPM package building recipe format -- for previous versions of these two packages in the EPEL as a guide.
Building the aria2 Package on RHEL 9
The rpmbuild tool is running in the GNOME terminal window (partially obscured by GNOME System Monitor in the imaage) to build RPM packages.
GNOME
The default graphical user interface in RHEL -- and the only one available in the official Red Hat repositories is GNOME. The desktop environment and a few applications were installed when using the "Server with GUI" software selection during installation. As with all software installed on RHEL, the version of GNOME is somewhat old, but is recent enough to include some of the significant improvements and feature additions to GNOME in recent years. In the early days of GNOME 3, soon after my return to Linux, GNOME was my desktop of choice, but since discovering Plasma and its richness of functionality, I abandoned GNOME for it and can't use any desktop environment other than Plasma for more than a few minutes. Despite my affinity for Plasma, I was impressed by these new the new additions, most notably a feature I haven't seen before in GNOME's file manager, Nautilus, but a feature I have regularly used in KDE's Dolphin for many years, the ability to open remote locations.
Also impressive, and what I liked about GNOME 3 in its early days, was the look of the environment, but only after the application of a suitable theme (or, as i was enthusiastic about GNOME, by editing the GNOME Shell .css files to modify existing themes). I think most users would prefer an alternative to the bland gray of the default Adwaita theme, highlighted in the following images in which the GNOME appearance is in its default state.
The Default State of GNOME Shell on Red Hat Enterprise Linux 9
The default desktop environment of RHEL 9 is GNOME 40 with the Adwaita theme.
Click on any of the thumbnails to view a slideshow of the images.
Click on any of the thumbnails to view a slideshow of the images.
Some of the other images throughout the article and the one below show the GNOME shell after the application of the Skeuos Red Dark GTK and GNOME Shell themes and the Tela Red dark variant icons.
The GNOME Shell with the Skeuos Red Dark GTK and GNOME Shell Themes Applied
GNOME Extensions
The ability to customize and extend GNOME Shell behavior is what makes the DE usable, in the opinion of some, including linus Torvalds himself. One such extension is the User Theme extension which allows custom themes to be used, without which I would not have been able to switch the theme to the above mentioned Skeuos GTK and GNOME Shell themes. This and about twenty more extensions are available in the official Red Hat repositories (first thumbnail image below). Other extensions are installable on a user level from Firefox through Firefox's own extension, GNOME Shell Integration (shown in the second and third thumbnails below). The Extensions application can be used to enable, disable, and configure extensions (thumbnails four - six in following set).
GNOME Shell Extensions
These images of the RHEL 9 GNOME desktop environment in its default appearance state show GNOME extensions support in RHEL 9. Common GNOME extensions are available from the AppStream Repository. Other extensions can be installed using the GNOME Shell Integration Firefox extension.
Click on any of the thumbnails to view a slideshow of the images.
Click on any of the thumbnails to view a slideshow of the images.
Plasma Desktop
For those using RHEL as a workstation, but prefer the power and flexibility of the Plasma desktop environment over the GNOME desktop environment, the Plasma desktop and KDE applications are available from the EPEL repository. The versions available are fairly recent as opposed to the officially supported DE, GNOME, which is at version 40 in RHEL, while the latest released version is 44. When I installed Plasma in July of 2022, the version available was 5.23.4, I believe a fairly recent version at that time. An update immediately after installation bumped it up to 5.24.5, and a recent update of the system in June of 2023 updated Plasma to version 5.27.4, almost at the same version of the Plasma 5.27.5 on the Arch installation on which I am writing this.
The installation of the entire desktop environment and a good selection of KDE applications was performed with a
sudo dnf group install 'KDE (K Desktop Environment)'
the output of which is shown in the following listing.
[brook@G5-RHEL9 SPECS]$ sudo dnf group install 'KDE (K Desktop Environment)' Updating Subscription Management repositories. Last metadata expiration check: 0:04:51 ago on Thu 07 Jul 2022 06:03:55 PM EDT. No match for group package "k3b-extras-freeworld" Dependencies resolved. ======================================================================================================================== Package Arch Version Repository Size ======================================================================================================================== Installing group/module packages: akregator x86_64 21.08.3-1.el9 epel 2.0 M bluedevil x86_64 5.23.4-1.el9 epel 352 k breeze-icon-theme noarch 5.90.0-1.el9 epel 4.1 M colord-kde x86_64 0.5.0-15.el9 epel 208 k dolphin x86_64 21.08.3-1.el9 epel 3.8 M firewall-config noarch 1.0.0-4.el9 rhel-9-for-x86_64-appstream-rpms 87 k gwenview x86_64 1:21.08.3-1.el9 epel 6.3 M initial-setup-gui x86_64 0.3.90.2-2.el9 rhel-9-for-x86_64-appstream-rpms 28 k kaddressbook x86_64 21.08.3-1.el9 epel 3.1 M kamera x86_64 21.04.2-2.el9 epel 205 k kate x86_64 21.08.3-1.el9 epel 6.9 M kcalc x86_64 21.04.3-1.el9 epel 612 k kcharselect x86_64 21.04.3-1.el9 epel 431 k kcolorchooser x86_64 21.04.2-2.el9 epel 48 k kde-gtk-config x86_64 5.23.5-1.el9 epel 100 k kde-partitionmanager x86_64 21.12.0-1.el9 epel 2.2 M kde-print-manager x86_64 21.04.3-1.el9 epel 359 k kde-settings-pulseaudio noarch 35.0-2.el9.1 epel 9.5 k kdegraphics-thumbnailers x86_64 21.04.2-2.el9 epel 61 k kdeplasma-addons x86_64 5.23.5-2.el9 epel 1.2 M kdialog x86_64 21.08.3-1.el9 epel 148 k kdnssd x86_64 21.04.3-1.el9 epel 82 k keditbookmarks x86_64 21.08.3-1.el9 epel 331 k kf5-akonadi-server x86_64 21.08.3-1.el9 epel 2.4 M kf5-akonadi-server-mysql x86_64 21.08.3-1.el9 epel 11 k kf5-baloo-file x86_64 5.90.0-1.el9 epel 125 k kf5-kipi-plugins x86_64 21.04.2-2.el9 epel 1.2 M kfind x86_64 21.08.3-1.el9 epel 461 k kgpg x86_64 21.04.3-1.el9 epel 3.1 M khelpcenter x86_64 1:21.08.3-1.el9 epel 4.8 M khotkeys x86_64 5.23.5-1.el9 epel 2.0 M kinfocenter x86_64 5.23.4-1.el9 epel 1.6 M kmag x86_64 21.04.3-1.el9 epel 820 k kmail x86_64 21.08.3-1.el9 epel 5.8 M kmenuedit x86_64 5.23.5-1.el9 epel 1.1 M kmousetool x86_64 21.04.3-1.el9 epel 244 k kmouth x86_64 21.04.3-1.el9 epel 1.9 M konsole5 x86_64 21.08.3-1.el9 epel 904 k kontact x86_64 21.08.3-1.el9 epel 745 k korganizer x86_64 21.08.3-1.el9 epel 1.9 M kruler x86_64 21.04.2-2.el9 epel 312 k kscreen x86_64 1:5.23.4-1.el9 epel 279 k kscreenlocker x86_64 5.23.4-1.el9 epel 226 k ksshaskpass x86_64 5.23.4-1.el9 epel 49 k kwalletmanager5 x86_64 21.04.3-1.el9 epel 992 k kwin x86_64 5.23.4-1.el9 epel 12 k kwrite x86_64 21.08.3-1.el9 epel 283 k okular x86_64 21.04.2-2.el9 epel 4.5 M pam-kwallet x86_64 5.23.4-1.el9 epel 23 k phonon-qt5-backend-gstreamer x86_64 2:4.10.0-6.el9 epel 163 k plasma-breeze x86_64 5.23.5-1.el9 epel 326 k plasma-desktop x86_64 5.23.5-1.el9 epel 13 M plasma-desktop-doc noarch 5.23.5-1.el9 epel 4.7 M plasma-discover x86_64 5.23.5-2.el9 epel 7.1 M plasma-discover-notifier x86_64 5.23.5-2.el9 epel 76 k plasma-drkonqi x86_64 5.23.4-1.el9 epel 872 k plasma-nm x86_64 5.23.5-1.el9 epel 950 k plasma-nm-l2tp x86_64 5.23.5-1.el9 epel 121 k plasma-nm-openconnect x86_64 5.23.5-1.el9 epel 113 k plasma-nm-openswan x86_64 5.23.5-1.el9 epel 50 k plasma-nm-openvpn x86_64 5.23.5-1.el9 epel 209 k plasma-nm-pptp x86_64 5.23.5-1.el9 epel 76 k plasma-pa x86_64 5.23.5-1.el9 epel 292 k plasma-systemmonitor x86_64 5.23.5-1.el9 epel 267 k plasma-thunderbolt x86_64 5.23.4-1.el9 epel 152 k plasma-workspace x86_64 5.23.5-2.el9 epel 7.0 M plasma-workspace-geolocation x86_64 5.23.5-2.el9 epel 53 k polkit-kde x86_64 5.23.4-1.el9 epel 91 k sddm x86_64 0.19.0-18.el9 epel 664 k sddm-breeze noarch 5.23.5-2.el9 epel 859 k sddm-kcm x86_64 5.23.4-1.el9 epel 133 k spectacle x86_64 21.04.2-2.el9 epel 1.3 M Installing dependencies: LibRaw x86_64 0.20.2-5.el9 rhel-9-for-x86_64-appstream-rpms 380 k NetworkManager-l2tp x86_64 1.20.4-1.el9 epel 187 k NetworkManager-libreswan x86_64 1.2.14-1.el9.3 rhel-9-for-x86_64-appstream-rpms 141 k NetworkManager-openconnect x86_64 1.2.6-9.el9 epel 440 k NetworkManager-openvpn x86_64 1:1.8.16-1.el9.1 epel 266 k NetworkManager-pptp x86_64 1:1.2.8-5.el9 epel 148 k PackageKit-Qt5 x86_64 1.0.2-3.el9 epel 98 k accounts-qml-module x86_64 0.7-6.el9 epel 83 k akonadi-import-wizard x86_64 21.08.3-1.el9 epel 749 k akregator-libs x86_64 21.08.3-1.el9 epel 539 k anaconda-core x86_64 34.25.0.29-1.el9_0 rhel-9-for-x86_64-appstream-rpms 2.6 M anaconda-gui x86_64 34.25.0.29-1.el9_0 rhel-9-for-x86_64-appstream-rpms 485 k anaconda-tui x86_64 34.25.0.29-1.el9_0 rhel-9-for-x86_64-appstream-rpms 197 k anaconda-user-help noarch 1:9.0.0-1.el9 rhel-9-for-x86_64-appstream-rpms 35 k anaconda-widgets x86_64 34.25.0.29-1.el9_0 rhel-9-for-x86_64-appstream-rpms 127 k appstream-qt x86_64 0.14.5-1.el9 codeready-builder-for-rhel-9-x86_64-rpms 80 k augeas-libs x86_64 1.13.0-1.el9 rhel-9-for-x86_64-appstream-rpms 459 k baloo-widgets x86_64 21.08.3-1.el9 epel 134 k blivet-data noarch 1:3.4.0-13.el9_0 rhel-9-for-x86_64-appstream-rpms 116 k breeze-cursor-theme noarch 5.23.5-1.el9 epel 329 k breeze-gtk-common noarch 5.23.5-1.el9 epel 243 k daxctl-libs x86_64 71.1-6.el9 rhel-9-for-x86_64-baseos-rpms 43 k dbus-x11 x86_64 1:1.12.20-5.el9 rhel-9-for-x86_64-appstream-rpms 27 k dbusmenu-qt5 x86_64 0.9.3-0.27.20160218.el9 epel 78 k desktop-backgrounds-compat noarch 35.0.0-1.el9 epel 8.9 k dolphin-libs x86_64 21.08.3-1.el9 epel 488 k f35-backgrounds-base noarch 35.0.1-4.el9 epel 20 M f35-backgrounds-kde noarch 35.0.1-4.el9 epel 12 k google-noto-sans-fonts noarch 20201206-3.el9 rhel-9-for-x86_64-appstream-rpms 7.6 M google-noto-serif-fonts noarch 20201206-3.el9 rhel-9-for-x86_64-appstream-rpms 8.5 M gpgmepp x86_64 1.15.1-6.el9 rhel-9-for-x86_64-appstream-rpms 124 k gpsd-libs x86_64 1:3.23.1-1.el9 epel 63 k grantlee-editor x86_64 21.08.3-1.el9 epel 282 k grantlee-editor-libs x86_64 21.08.3-1.el9 epel 44 k grantlee-qt5 x86_64 5.2.0-11.el9 epel 315 k gtk2-engines x86_64 2.20.2-24.el9 epel 300 k gwenview-libs x86_64 1:21.08.3-1.el9 epel 458 k iceauth x86_64 1.0.8-4.el9 epel 26 k imath x86_64 3.1.2-1.el9 rhel-9-for-x86_64-appstream-rpms 98 k initial-setup x86_64 0.3.90.2-2.el9 rhel-9-for-x86_64-appstream-rpms 141 k jasper-libs x86_64 2.0.28-3.el9 rhel-9-for-x86_64-appstream-rpms 154 k kaccounts-integration x86_64 21.04.3-1.el9 epel 156 k kactivitymanagerd x86_64 5.23.4-1.el9 epel 265 k kaddressbook-libs x86_64 21.08.3-1.el9 epel 228 k kcolorpicker x86_64 0.1.6-2.el9 epel 31 k kde-cli-tools x86_64 5.23.5-1.el9 epel 824 k kde-filesystem x86_64 4-66.el9 epel 43 k kde-print-manager-libs x86_64 21.04.3-1.el9 epel 158 k kde-settings noarch 35.0-2.el9.1 epel 33 k kde-settings-plasma noarch 35.0-2.el9.1 epel 13 k kdecoration x86_64 5.23.4-1.el9 epel 86 k kdegraphics-mobipocket x86_64 21.04.2-2.el9 epel 40 k kdepim-runtime x86_64 1:21.08.3-1.el9 epel 3.3 M kdepim-runtime-libs x86_64 1:21.08.3-1.el9 epel 398 k kdesu x86_64 1:5.23.5-1.el9 epel 231 k kdiagram x86_64 2.8.0-3.el9 epel 558 k kdsoap x86_64 2.0.0-2.el9 epel 145 k keditbookmarks-libs x86_64 21.08.3-1.el9 epel 46 k kernel-modules-extra x86_64 5.14.0-70.17.1.el9_0 rhel-9-for-x86_64-baseos-rpms 966 k keybinder3 x86_64 0.3.2-13.el9 rhel-9-for-x86_64-appstream-rpms 23 k kf5-akonadi-calendar x86_64 21.08.3-1.el9 epel 514 k kf5-akonadi-contacts x86_64 21.08.3-1.el9 epel 611 k kf5-akonadi-mime x86_64 21.08.3-1.el9 epel 204 k kf5-akonadi-notes x86_64 21.08.3-1.el9 epel 54 k kf5-akonadi-search x86_64 21.08.3-1.el9 epel 327 k kf5-attica x86_64 5.90.0-1.el9 epel 170 k kf5-baloo x86_64 5.90.0-1.el9 epel 236 k kf5-baloo-libs x86_64 5.90.0-1.el9 epel 229 k kf5-bluez-qt x86_64 5.90.0-1.el9 epel 238 k kf5-calendarsupport x86_64 21.08.3-1.el9 epel 603 k kf5-eventviews x86_64 21.08.3-1.el9 epel 667 k kf5-filesystem x86_64 5.90.0-1.el9 epel 11 k kf5-frameworkintegration x86_64 5.90.0-1.el9 epel 1.6 M kf5-frameworkintegration-libs x86_64 5.90.0-1.el9 epel 30 k kf5-grantleetheme x86_64 21.08.3-1.el9 epel 87 k kf5-incidenceeditor x86_64 21.08.3-1.el9 epel 595 k kf5-kactivities x86_64 5.90.0-1.el9 epel 138 k kf5-kactivities-stats x86_64 5.90.0-1.el9 epel 107 k kf5-kalarmcal x86_64 21.08.3-1.el9 epel 281 k kf5-karchive x86_64 5.90.0-1.el9 epel 106 k kf5-kauth x86_64 5.90.0-1.el9 epel 130 k kf5-kbookmarks x86_64 5.90.0-1.el9 epel 167 k kf5-kcalendarcore x86_64 1:5.90.0-1.el9 epel 282 k kf5-kcalendarutils x86_64 21.08.3-1.el9 epel 324 k kf5-kcmutils x86_64 5.90.0-1.el9 epel 239 k kf5-kcodecs x86_64 5.90.0-1.el9 epel 179 k kf5-kcompletion x86_64 5.90.0-1.el9 epel 136 k kf5-kconfig-core x86_64 5.90.0-1.el9 epel 317 k kf5-kconfig-gui x86_64 5.90.0-1.el9 epel 49 k kf5-kconfigwidgets x86_64 5.90.0-1.el9 epel 432 k kf5-kcontacts x86_64 1:5.90.0-1.el9 epel 269 k kf5-kcoreaddons x86_64 5.90.0-1.el9 epel 465 k kf5-kcrash x86_64 5.90.0-1.el9 epel 38 k kf5-kdav x86_64 1:5.90.0-1.el9 epel 113 k kf5-kdbusaddons x86_64 5.90.0-1.el9 epel 86 k kf5-kdeclarative x86_64 5.90.0-1.el9 epel 323 k kf5-kded x86_64 5.90.0-1.el9 epel 79 k kf5-kdelibs4support x86_64 5.90.0-1.el9 epel 2.1 M kf5-kdelibs4support-libs x86_64 5.90.0-1.el9 epel 788 k kf5-kdesu x86_64 5.90.0-1.el9 epel 99 k kf5-kdnssd x86_64 5.90.0-1.el9 epel 98 k kf5-kdoctools x86_64 5.90.0-1.el9 epel 627 k kf5-kfilemetadata x86_64 5.90.0-1.el9 epel 220 k kf5-kglobalaccel x86_64 5.90.0-1.el9 epel 66 k kf5-kglobalaccel-libs x86_64 5.90.0-1.el9 epel 105 k kf5-kguiaddons x86_64 5.90.0-1.el9 epel 104 k kf5-kholidays x86_64 1:5.90.0-1.el9 epel 274 k kf5-khtml x86_64 5.90.0-1.el9 epel 2.6 M kf5-ki18n x86_64 5.90.0-1.el9 epel 1.7 M kf5-kiconthemes x86_64 5.90.0-1.el9 epel 175 k kf5-kidentitymanagement x86_64 21.08.3-1.el9 epel 126 k kf5-kidletime x86_64 5.90.0-1.el9 epel 59 k kf5-kimap x86_64 21.08.3-1.el9 epel 227 k kf5-kinit x86_64 5.90.0-1.el9 epel 173 k kf5-kio-core x86_64 5.90.0-1.el9 epel 613 k kf5-kio-core-libs x86_64 5.90.0-1.el9 epel 464 k kf5-kio-doc noarch 5.90.0-1.el9 epel 2.5 M kf5-kio-file-widgets x86_64 5.90.0-1.el9 epel 303 k kf5-kio-gui x86_64 5.90.0-1.el9 epel 89 k kf5-kio-ntlm x86_64 5.90.0-1.el9 epel 21 k kf5-kio-widgets x86_64 5.90.0-1.el9 epel 255 k kf5-kio-widgets-libs x86_64 5.90.0-1.el9 epel 424 k kf5-kipi-plugins-libs x86_64 21.04.2-2.el9 epel 741 k kf5-kirigami2 x86_64 5.90.0-1.el9 epel 415 k kf5-kitemmodels x86_64 5.90.0-1.el9 epel 141 k kf5-kitemviews x86_64 5.90.0-1.el9 epel 130 k kf5-kitinerary x86_64 21.08.3-1.el9 epel 1.1 M kf5-kjobwidgets x86_64 5.90.0-1.el9 epel 129 k kf5-kjs x86_64 5.90.0-1.el9 epel 322 k kf5-kldap x86_64 21.08.3-1.el9 epel 233 k kf5-kmailtransport x86_64 21.08.3-1.el9 epel 246 k kf5-kmailtransport-akonadi x86_64 21.08.3-1.el9 epel 45 k kf5-kmbox x86_64 21.08.3-1.el9 epel 44 k kf5-kmime x86_64 21.08.3-1.el9 epel 170 k kf5-knewstuff x86_64 5.90.0-2.el9 epel 813 k kf5-knotifications x86_64 5.90.0-1.el9 epel 167 k kf5-knotifyconfig x86_64 5.90.0-1.el9 epel 113 k kf5-kontactinterface x86_64 21.08.3-1.el9 epel 73 k kf5-kpackage x86_64 5.90.0-1.el9 epel 211 k kf5-kparts x86_64 5.90.0-1.el9 epel 224 k kf5-kpeople x86_64 5.90.0-1.el9 epel 144 k kf5-kpimtextedit x86_64 21.08.3-1.el9 epel 386 k kf5-kpkpass x86_64 21.08.3-1.el9 epel 49 k kf5-kpty x86_64 5.90.0-1.el9 epel 76 k kf5-kquickcharts x86_64 5.90.0-1.el9 epel 149 k kf5-kross-core x86_64 5.90.0-1.el9 epel 307 k kf5-krunner x86_64 5.90.0-1.el9 epel 123 k kf5-kservice x86_64 5.90.0-1.el9 epel 346 k kf5-ksmtp x86_64 21.08.3-1.el9 epel 79 k kf5-ktexteditor x86_64 5.90.0-1.el9 epel 2.4 M kf5-ktextwidgets x86_64 5.90.0-1.el9 epel 323 k kf5-ktnef x86_64 21.08.3-1.el9 epel 144 k kf5-kunitconversion x86_64 5.90.0-1.el9 epel 916 k kf5-kwallet x86_64 5.90.0-1.el9 epel 309 k kf5-kwallet-libs x86_64 5.90.0-1.el9 epel 88 k kf5-kwayland x86_64 5.90.0-1.el9 epel 512 k kf5-kwidgetsaddons x86_64 5.90.0-1.el9 epel 1.6 M kf5-kwindowsystem x86_64 5.90.0-1.el9 epel 190 k kf5-kxmlgui x86_64 5.90.0-1.el9 epel 709 k kf5-kxmlrpcclient x86_64 5.90.0-1.el9 epel 74 k kf5-libgravatar x86_64 21.08.3-1.el9 epel 67 k kf5-libkdcraw x86_64 21.08.3-1.el9 epel 49 k kf5-libkdepim x86_64 21.08.3-1.el9 epel 110 k kf5-libkexiv2 x86_64 21.08.3-1.el9 epel 145 k kf5-libkipi x86_64 21.04.2-2.el9 epel 102 k kf5-libkleo x86_64 21.08.3-1.el9 epel 642 k kf5-libksieve x86_64 21.08.3-1.el9 epel 852 k kf5-mailcommon x86_64 21.08.3-1.el9 epel 857 k kf5-mailimporter x86_64 21.08.3-1.el9 epel 237 k kf5-mailimporter-akonadi x86_64 21.08.3-1.el9 epel 29 k kf5-messagelib x86_64 21.08.3-1.el9 epel 6.3 M kf5-modemmanager-qt x86_64 5.90.0-1.el9 epel 171 k kf5-networkmanager-qt x86_64 5.90.0-1.el9 epel 342 k kf5-pimcommon x86_64 21.08.3-1.el9 epel 382 k kf5-pimcommon-akonadi x86_64 21.08.3-1.el9 epel 225 k kf5-plasma x86_64 5.90.0-1.el9 epel 3.1 M kf5-prison x86_64 5.90.0-1.el9 epel 54 k kf5-purpose x86_64 5.90.0-1.el9 epel 448 k kf5-solid x86_64 5.90.0-1.el9 epel 387 k kf5-sonnet-core x86_64 5.90.0-1.el9 epel 184 k kf5-sonnet-ui x86_64 5.90.0-1.el9 epel 166 k kf5-syndication x86_64 1:5.90.0-1.el9 epel 190 k kf5-syntax-highlighting x86_64 5.90.0-1.el9 epel 1.6 M kf5-threadweaver x86_64 5.90.0-1.el9 epel 75 k kimageannotator x86_64 0.5.3-1.el9 epel 362 k kio-extras x86_64 21.04.3-2.el9 epel 1.4 M kmail-account-wizard x86_64 21.08.3-1.el9 epel 572 k kmail-libs x86_64 21.08.3-1.el9 epel 1.0 M konsole5-part x86_64 21.08.3-1.el9 epel 626 k kontact-libs x86_64 21.08.3-1.el9 epel 94 k korganizer-libs x86_64 21.08.3-1.el9 epel 832 k kpmcore x86_64 21.12.1-1.el9 epel 664 k ksystemstats x86_64 5.23.5-1.el9 epel 219 k kuserfeedback x86_64 1.0.0-8.el9 epel 200 k kwayland-integration x86_64 5.23.4-1.el9 epel 65 k kwayland-server x86_64 5.23.4-1.el9 epel 380 k kwin-common x86_64 5.23.4-1.el9 epel 2.5 M kwin-libs x86_64 5.23.4-1.el9 epel 1.5 M kwin-wayland x86_64 5.23.4-1.el9 epel 516 k kwrited x86_64 5.23.4-1.el9 epel 34 k langtable noarch 0.0.54-4.el9 rhel-9-for-x86_64-appstream-rpms 48 k layer-shell-qt x86_64 5.23.4-1.el9 epel 34 k ldns x86_64 1.7.1-10.el9 rhel-9-for-x86_64-appstream-rpms 163 k libXScrnSaver x86_64 1.2.3-10.el9 rhel-9-for-x86_64-appstream-rpms 27 k libaccounts-glib x86_64 1.25-7.el9 epel 84 k libaccounts-qt5 x86_64 1.16-4.el9 epel 61 k libchewing x86_64 0.5.1-22.el9 epel 1.8 M libdmtx x86_64 0.7.5-8.el9 epel 62 k libimobiledevice x86_64 1.3.0-5.el9 epel 75 k libkgapi x86_64 21.08.3-1.el9 epel 506 k libkolabxml x86_64 1.2.0-7.el9 epel 703 k libkscreen-qt5 x86_64 5.23.4-1.el9 epel 251 k libksysguard x86_64 5.23.5-1.el9 epel 1.1 M libksysguard-common x86_64 5.23.5-1.el9 epel 46 k libkworkspace5 x86_64 5.23.5-2.el9 epel 112 k libmarkdown x86_64 2.2.4-7.el9 epel 46 k libmng x86_64 2.0.3-17.el9 rhel-9-for-x86_64-appstream-rpms 190 k libpinyin x86_64 2.6.0-4.el9 rhel-9-for-x86_64-appstream-rpms 204 k libpinyin-data x86_64 2.6.0-4.el9 rhel-9-for-x86_64-appstream-rpms 13 M libplist x86_64 2.2.0-5.el9 epel 76 k libpskc x86_64 2.6.7-2.el9 epel 34 k libqalculate x86_64 3.22.0-1.el9 epel 1.9 M libraw1394 x86_64 2.1.2-14.el9 epel 65 k libreport x86_64 2.15.2-6.el9 rhel-9-for-x86_64-appstream-rpms 522 k libreport-anaconda x86_64 2.15.2-6.el9 rhel-9-for-x86_64-appstream-rpms 22 k libreport-cli x86_64 2.15.2-6.el9 rhel-9-for-x86_64-appstream-rpms 29 k libreport-gtk x86_64 2.15.2-6.el9 rhel-9-for-x86_64-appstream-rpms 80 k libreport-plugin-reportuploader x86_64 2.15.2-6.el9 rhel-9-for-x86_64-appstream-rpms 44 k libreport-web x86_64 2.15.2-6.el9 rhel-9-for-x86_64-appstream-rpms 34 k libreswan x86_64 4.6-3.el9 rhel-9-for-x86_64-appstream-rpms 1.3 M libtimezonemap x86_64 0.4.5.1-11.el9_0.1 rhel-9-for-x86_64-appstream-rpms 2.0 M libusbmuxd x86_64 2.0.2-5.el9 epel 38 k lm_sensors-libs x86_64 3.6.0-10.el9 rhel-9-for-x86_64-appstream-rpms 44 k maliit-framework x86_64 2.0.0-4.el9 epel 71 k maliit-framework-qt5 x86_64 2.0.0-4.el9 epel 309 k maliit-keyboard x86_64 2.0.0-4.el9 epel 577 k mariadb x86_64 3:10.5.13-2.el9 rhel-9-for-x86_64-appstream-rpms 1.6 M mariadb-common x86_64 3:10.5.13-2.el9 rhel-9-for-x86_64-appstream-rpms 39 k mariadb-connector-c x86_64 3.2.6-1.el9_0 rhel-9-for-x86_64-appstream-rpms 203 k mariadb-connector-c-config noarch 3.2.6-1.el9_0 rhel-9-for-x86_64-appstream-rpms 11 k mariadb-errmsg x86_64 3:10.5.13-2.el9 rhel-9-for-x86_64-appstream-rpms 199 k mariadb-server x86_64 3:10.5.13-2.el9 rhel-9-for-x86_64-appstream-rpms 9.4 M mesa-libGLU x86_64 9.0.1-6.el9 rhel-9-for-x86_64-appstream-rpms 149 k mysql-selinux noarch 1.0.4-2.el9 rhel-9-for-x86_64-appstream-rpms 37 k ndctl x86_64 71.1-6.el9 rhel-9-for-x86_64-baseos-rpms 193 k ndctl-libs x86_64 71.1-6.el9 rhel-9-for-x86_64-baseos-rpms 84 k nss-mdns x86_64 0.15.1-3.el9 epel 46 k okular-libs x86_64 21.04.2-2.el9 epel 363 k okular-part x86_64 21.04.2-2.el9 epel 1.7 M openal-soft x86_64 1.19.1-16.el9 rhel-9-for-x86_64-appstream-rpms 539 k openconnect x86_64 9.01-1.el9 epel 864 k openexr-libs x86_64 3.1.1-2.el9 rhel-9-for-x86_64-appstream-rpms 1.1 M openvpn x86_64 2.5.7-1.el9 epel 652 k oxygen-sound-theme noarch 5.23.4-1.el9 epel 1.8 M perl-DBD-MariaDB x86_64 1.21-16.el9_0 rhel-9-for-x86_64-appstream-rpms 156 k perl-Sys-Hostname x86_64 1.23-479.el9 rhel-9-for-x86_64-appstream-rpms 29 k phonon-qt5 x86_64 4.11.1-8.el9 epel 295 k pim-data-exporter x86_64 21.08.3-1.el9 epel 346 k pim-data-exporter-libs x86_64 21.08.3-1.el9 epel 167 k pim-sieve-editor x86_64 21.08.3-1.el9 epel 578 k pkcs11-helper x86_64 1.27.0-6.el9 epel 62 k plasma-breeze-common noarch 5.23.5-1.el9 epel 77 M plasma-discover-libs x86_64 5.23.5-2.el9 epel 474 k plasma-integration x86_64 5.23.4-1.el9 epel 207 k plasma-systemsettings x86_64 5.23.5-1.el9 epel 409 k plasma-workspace-common x86_64 5.23.5-2.el9 epel 40 k plasma-workspace-geolocation-libs x86_64 5.23.5-2.el9 epel 25 k plasma-workspace-libs x86_64 5.23.5-2.el9 epel 2.1 M plasma-workspace-wayland x86_64 5.23.5-2.el9 epel 33 k polkit-qt5-1 x86_64 0.114.0-2.el9 epel 85 k poppler-qt5 x86_64 21.01.0-12.el9 codeready-builder-for-rhel-9-x86_64-rpms 209 k powerdevil x86_64 5.23.5-1.el9 epel 962 k ppp x86_64 2.4.9-5.el9 rhel-9-for-x86_64-baseos-rpms 424 k pptp x86_64 1.10.0-14.el9 rhel-9-for-x86_64-appstream-rpms 74 k python3-blivet noarch 1:3.4.0-13.el9_0 rhel-9-for-x86_64-appstream-rpms 880 k python3-blockdev x86_64 2.25-11.el9 rhel-9-for-x86_64-appstream-rpms 33 k python3-bytesize x86_64 2.5-3.el9 rhel-9-for-x86_64-appstream-rpms 23 k python3-kickstart noarch 3.32.5-1.el9 rhel-9-for-x86_64-appstream-rpms 539 k python3-langtable noarch 0.0.54-4.el9 rhel-9-for-x86_64-appstream-rpms 1.2 M python3-libreport x86_64 2.15.2-6.el9 rhel-9-for-x86_64-appstream-rpms 59 k python3-meh noarch 0.50-4.el9 rhel-9-for-x86_64-appstream-rpms 134 k python3-meh-gui noarch 0.50-4.el9 rhel-9-for-x86_64-appstream-rpms 17 k python3-pid noarch 2.2.3-12.el9 rhel-9-for-x86_64-appstream-rpms 28 k python3-productmd noarch 1.31-3.el9 rhel-9-for-x86_64-appstream-rpms 83 k python3-pwquality x86_64 1.4.4-8.el9 rhel-9-for-x86_64-appstream-rpms 19 k python3-pyparted x86_64 1:3.11.7-4.el9 rhel-9-for-x86_64-appstream-rpms 114 k python3-pytz noarch 2021.1-4.el9 rhel-9-for-x86_64-appstream-rpms 56 k python3-pyudev noarch 0.22.0-6.el9 rhel-9-for-x86_64-baseos-rpms 94 k python3-requests-file noarch 1.5.1-4.el9 rhel-9-for-x86_64-appstream-rpms 18 k python3-requests-ftp noarch 0.3.1-23.el9 rhel-9-for-x86_64-appstream-rpms 27 k python3-simpleline noarch 1.8-3.el9 rhel-9-for-x86_64-appstream-rpms 143 k qca-qt5 x86_64 2.3.4-2.el9 epel 459 k qgpgme x86_64 1.15.1-6.el9 codeready-builder-for-rhel-9-x86_64-rpms 215 k qqc2-desktop-style x86_64 5.90.0-1.el9 epel 119 k qt5-qtbase-mysql x86_64 5.15.2-29.el9 rhel-9-for-x86_64-appstream-rpms 44 k qt5-qtfeedback x86_64 20180903gita14bd0b-2.el9 epel 71 k qt5-qtgraphicaleffects x86_64 5.15.2-6.el9 rhel-9-for-x86_64-appstream-rpms 125 k qt5-qtlocation x86_64 5.15.2-9.el9 rhel-9-for-x86_64-appstream-rpms 3.1 M qt5-qtmultimedia x86_64 5.15.2-7.el9 rhel-9-for-x86_64-appstream-rpms 824 k qt5-qtnetworkauth x86_64 5.15.2-4.el9 epel 81 k qt5-qtquickcontrols x86_64 5.15.2-6.el9 rhel-9-for-x86_64-appstream-rpms 1.1 M qt5-qtquickcontrols2 x86_64 5.15.2-7.el9 rhel-9-for-x86_64-appstream-rpms 1.7 M qt5-qtscript x86_64 5.15.2-6.el9 rhel-9-for-x86_64-appstream-rpms 1.0 M qt5-qtsensors x86_64 5.15.2-7.el9 rhel-9-for-x86_64-appstream-rpms 234 k qt5-qtspeech x86_64 5.15.2-4.el9 epel 44 k qt5-qtwayland x86_64 5.15.2-15.el9 rhel-9-for-x86_64-appstream-rpms 1.1 M qt5-qtwebchannel x86_64 5.15.2-6.el9 rhel-9-for-x86_64-appstream-rpms 104 k qt5-qtwebengine x86_64 5.15.8-3.el9.1 epel 59 M qt5-qtwebkit x86_64 5.212.0-0.60.alpha4.el9 epel 13 M qt5-qtxmlpatterns x86_64 5.15.2-7.el9 rhel-9-for-x86_64-appstream-rpms 1.0 M qtkeychain-qt5 x86_64 0.11.1-3.el9 epel 63 k satyr x86_64 0.38-3.el9 rhel-9-for-x86_64-appstream-rpms 117 k signon x86_64 8.60-9.el9 epel 323 k signon-plugin-oauth2 x86_64 0.24-3.el9 epel 79 k signon-ui x86_64 0.15-16.el9 epel 111 k socat x86_64 1.7.4.1-5.el9 rhel-9-for-x86_64-appstream-rpms 309 k stoken-libs x86_64 0.92-6.el9 epel 46 k tigervnc-license noarch 1.11.0-21.el9 rhel-9-for-x86_64-appstream-rpms 17 k tigervnc-server-minimal x86_64 1.11.0-21.el9 rhel-9-for-x86_64-appstream-rpms 1.1 M trousers-lib x86_64 0.3.15-5.el9 epel 165 k vpnc-script noarch 20220404-1.git40a8c62c.el9 epel 17 k xapian-core-libs x86_64 1.4.18-5.el9 rhel-9-for-x86_64-appstream-rpms 745 k xcb-util-cursor x86_64 0.1.3-13.el9 epel 19 k xerces-c x86_64 3.2.3-5.el9 epel 963 k xl2tpd x86_64 1.3.16-4.el9 epel 94 k xmessage x86_64 1.0.5-4.el9 epel 21 k xmlrpc-c x86_64 1.51.0-16.el9_0 rhel-9-for-x86_64-appstream-rpms 148 k xmlrpc-c-client x86_64 1.51.0-16.el9_0 rhel-9-for-x86_64-appstream-rpms 32 k Installing weak dependencies: breeze-gtk-gtk2 noarch 5.23.5-1.el9 epel 19 k breeze-gtk-gtk3 noarch 5.23.5-1.el9 epel 28 k breeze-gtk-gtk4 noarch 5.23.5-1.el9 epel 27 k cyrus-sasl-md5 x86_64 2.1.27-20.el9 rhel-9-for-x86_64-appstream-rpms 46 k dolphin-plugins x86_64 21.08.3-1.el9 epel 441 k exfatprogs x86_64 1.1.2-2.el9 rhel-9-for-x86_64-baseos-rpms 68 k google-noto-sans-mono-fonts noarch 20201206-3.el9 rhel-9-for-x86_64-appstream-rpms 3.4 M kaccounts-providers x86_64 21.04.3-1.el9 epel 109 k kate-plugins x86_64 21.08.3-1.el9 epel 1.6 M kdepim-addons x86_64 21.08.3-1.el9 epel 1.9 M kf5-kimageformats x86_64 5.90.0-1.el9 epel 165 k kwin-x11 x86_64 5.23.4-1.el9 epel 143 k libblockdev-dm x86_64 2.25-11.el9 rhel-9-for-x86_64-appstream-rpms 22 k libblockdev-kbd x86_64 2.25-11.el9 rhel-9-for-x86_64-appstream-rpms 29 k libblockdev-mpath x86_64 2.25-11.el9 rhel-9-for-x86_64-appstream-rpms 24 k libblockdev-nvdimm x86_64 2.25-11.el9 rhel-9-for-x86_64-appstream-rpms 24 k mariadb-backup x86_64 3:10.5.13-2.el9 rhel-9-for-x86_64-appstream-rpms 6.4 M mariadb-gssapi-server x86_64 3:10.5.13-2.el9 rhel-9-for-x86_64-appstream-rpms 22 k mariadb-server-utils x86_64 3:10.5.13-2.el9 rhel-9-for-x86_64-appstream-rpms 219 k media-player-info noarch 23-9.el9 epel 65 k plasma-browser-integration x86_64 5.23.5-1.el9 epel 230 k plasma-discover-flatpak x86_64 5.23.5-2.el9 epel 109 k plasma-discover-packagekit x86_64 5.23.5-2.el9 epel 143 k plasma-milou x86_64 5.23.4-1.el9 epel 95 k plasma-workspace-x11 x86_64 5.23.5-2.el9 epel 46 k qca-qt5-ossl x86_64 2.3.4-2.el9 epel 114 k qt5-qtimageformats x86_64 5.15.2-6.el9 rhel-9-for-x86_64-appstream-rpms 109 k qt5-qtspeech-speechd x86_64 5.15.2-4.el9 epel 24 k qt5-qtvirtualkeyboard x86_64 5.15.2-4.el9 epel 2.3 M samba-client x86_64 4.15.5-108.el9_0 rhel-9-for-x86_64-appstream-rpms 677 k udftools x86_64 2.2-5.el9 rhel-9-for-x86_64-appstream-rpms 153 k xdg-desktop-portal-kde x86_64 5.23.4-1.el9 epel 231 k xsettingsd x86_64 1.0.2-2.el9 epel 39 k Installing Groups: KDE (K Desktop Environment) Transaction Summary ======================================================================================================================== Install 433 Packages Total download size: 463 M Installed size: 1.3 G Is this ok [y/N]:
The resulting Plasma experience was usable, but not the best. Before the update to Plasma 5.27, everything generally worked fine; even switching the display manager to SDDM from the default GDM had presented no issues. The only issue was that if the system went to sleep, it was not possoble to unlock the system through the screen locker (the greeter for the screen locker, not the greeter managed by SDDM), requiring a reboot. This problem never occured with GNOME shell when the system went to sleep, its screen locker accepted credentials and resumed the system immediately.
The Plasma Desktop Environment on Red Hat Enterprise Linux 9 Installed from the EPEL Repository
Plasma as installed on RHEL 9 from the EPEL is usable, but not without issues. There were no issues in Alma Linux 9.1 -- which also uses the EPEL for KDE packages -- installed from the KDE edition live ISO and updated to 9.2.
Click on any of the thumbnails to view a slideshow of the images.
Click on any of the thumbnails to view a slideshow of the images.
After the update to Plasma 5.27, the experinece of using Plasma became much worse. GDM was able to start Plasma, however, unlike before the update when it was working as expected, plasmashell, if it was in fact excecutde, did not have a background or panels. I had to use KRunner, activated through the keyboard shortcut, to execute plasmashell --replace in order to get a working desktop. The situation was worse with SDDM which did not even present a greeter. Fortunately, installing sddm-wayland-plasma, which caused the removal of sddm-x11, resolved the issue. While the issue was resolved, the behavior of the greeter was different in that there were some duplicates in the desktop session type selection dropdown, as shown in the following image.
Installing sddm-wayland-plasma Caused Duplicates of the Available Session Types in the SDDM Greeter Selection Dropdown
Installing sddm-wayland-plasma fixed the problem of no greeter being displayed by SDDM after the update to Plasma 5.27.
Interestingly, none of these issues were apparent in AlmaLinux 9.2, which I installed this month using the distribution's KDE live ISO on my old Acer V15 Nitro.
NVIDIA Driver
Before the Lenovo Legion 5 Pro replaced the Dell G5 as my primary computer and before I started using a second external screen, on the Dell I would generally block Nouveau, the FOSS NVIDIA driver, from loading and install Bumblebee and bbswitch, the former providing a daemon that would provide NVIDIA graphics on-demand and the latter performing the actual power management of the GPU. With this graphics configuration the integrated Intel GPU would be used with the Intel driver by default, with the option to use the NVIDIA GPU and the proprietary NVIDIA driver on demand and per application. This configuration became unusable with an external screen because the HDMI and USB-C/DisplayPort/Thunderbolt connector is wired to the NVIDIA GPU requiring it to be always available. I then discovered the tools provided by distributions to switch between the discrete graphics and integrated graphics modes, allowing me to use the NVIDIA GPU with the NVIDIA driver system-wide instead of the Nouveau driver and the integrated GPU with the Intel driver when on battery. (See The Best Distributions for Problematic Nvidia Optimus Hybrid Graphics.)
When I reviewed Fedora 32, I found that the Nouveau driver worked so much better than it had in the past, didn't require switching, provided excellent battery life, and because it powered the NVIDIA GPU, I could use an external screen without having to log out, so I stayed with the Nouveau driver. The only drawback was that the Nouveau driver would not use the dedicated GPUs memory.
The situation is the same in RHEL 9 as it was in Fedora 32, with everything working well with the default FOSS Nouveau driver. However, in order to take full advantage of the Dell G5's capability and test RHEL 9 fully, I wanted to install the proprietary NVIDIA GPU driver. As mentioned previously, I could not install the driver using a module stream as I desired because, unlike in RHEL 8, the NVIDIA drivers are not available as module streams. Fortunately, RPMFusion is not only available to Fedora users, but to users of RHEL and its clones as well, providing an alternative to the unavailable module streams for prebuilt NVIDIA drivers. The installation process, which essentially only required installing the kmod-nvidia package, causing dependencies to be installed, is described below in the section NVIDIA Driver Installation.
The NVIDIA driver as installed from RPMFusion enabled the full capability of the GPU including the GPU dedicated memory. The following image of the output of nvidia-smi, which was provided by the optional package install xorg-x11-drv-nvidia-cuda, shows the statistics of the GPU at the time, including the amount of dedicated GPU memory in use (341MB in this case) and an enumeration of memory usage by process.
The Output of nvidia-smi Running on RHEL 9 with NVIDIA Driver Installed from RPMFusion
Unfortunately, Optimus management on Fedora and RHEL is not as robust as those available for Ubuntu, Arch, and to a lesser extent openSUSE. On all of these distributions, the Optimus management utilities allow switching between discrete graphics, hybrid graphics, and integrated graphics modes for pre-Turing microarchitecture generation NVIDIA GPUs with power management of the GPU performed by external tools such as bbswitch; and between discrete and hybrid graphics modes for post-Turing microarchitecture generation NVIDIA GPUs with power management handled by the NVIDIA driver itself. Ubuntu's solution even integrates into the NVIDIA Settings as well as providing a CLI to switching between graphics modes. (For the reason as to the difference between the available graphics modes for Optimus laptops with pre and post-Turing generation NVIDIA GPUs, and other details, see Nvidia Optimus on Linux.)
All that is possible in Fedora nd RHEL, according to the RPMFusion documentation, is to choose whether the NVIDIA or the Nouveau driver kernel modules are loaded at boot based on the values of certain kernel commandline parameters (see NVIDIA Driver Installation, below). For pre-Turing Optimus laptops, where integrated mode is available in addition to hybrid and discrete modes, there does not seem to be a way to chose integrated mode using only the Intel driver. Also, there does not seem to be any mechanism to manage the actual power state of the NVIDIA GPU for pre-Turing Optimus laptops which require either an external utility, such as bbswitch or, manual methods. And for post-Turing NVIDIA GPUs, whose power states can be managed by the NVIDIA driver when the laptop is set to hybrid graphics, no mechanism is provided to switch between the discrete and hybrid graphics modes as can be done with Optimus Manager on Arch, NVIDIA Prime on Ubuntu, and SUSEPrime on openSUSE. For a discussion of these issues see Nvidia Optimus on Linux.
Despite these limitations, there is no practical issue on the Dell G5 with an older GPU, if choosing the NVIDIA driver when on external power and the Nouveau module when on battery power; the performance of the NVIDIA driver, as well as the dedicated GPU memory, is available when power conservation is not an issue and the power saving of the Nouveau driver is available when on battery. On a newer laptop such as the Lenovo Legion 5i Pro with a post-Turing GPU (Ampere), usage would be limited to using only the NVIDIA mode as Nouveau performance is typically not as good as the proprietary driver for newer GPUs.
The following images show RHEL 9 in use with the NVIDIA driver loaded at boot.
Red Hat Enterprise Linux 9 Using the NVIDIA Proprietary Driver
The default GNOME desktop environment running on a Dell G5 using the proprietary NVIDIA driver. The last two images show a screen capture with a connected external 4K display.
Click on any of the thumbnails to view a slideshow of the images.
Click on any of the thumbnails to view a slideshow of the images.
NVIDIA Driver Installation
One difference between the installation of NVIDIA drivers in Fedora and in RHEL is that the documentation states that RHEL and CentOS users can install the kmod-nvidia meta package instead of akmod-nvidia, the difference -- according to a Fedora Forum thread -- being that the former causes prebuilt NVIDIA modules to be installed, whereas the latter will cause the prebuilt module to be installed, if available, and if not, cause it to be built from included sources and installed. In this case installing kmod-nvidia causes akmod-nvidia to be installed as well.
A basic installation and configuration process that works on the Dell G5 and its pre-Turing NVIDIA GPU is summarized below. For details see the RPMFusion Optimus Howto.
-
Install the NVIDIA kernel module meta package kmod-nvidia. This causes all necessary components to be installed including xorg-x11-drv-nvidia-power which is installed separately in RPMFusion documentation.
sudo dnf install kmod-nvidia
-
Optionally install the CUDA driver.
sudo dnf install xorg-x11-drv-nvidia-cuda
-
Enable the necessary systemd services.
sudo systemctl enable nvidia-{suspend,resume,hibernate} -
Copy the configuration file distributed by the package to the local system-wide configuration directory.
[brook@G5-RHEL9 ~]$ sudo cp -p /usr/share/X11/xorg.conf.d/nvidia.conf /etc/X11/xorg.conf.d/nvidia.conf
-
Edit /etc/X11/xorg.conf.d/nvidia.conf and add Option "PrimaryGPU" "yes" so that the contents look like:
Section "OutputClass" Indentifier "nvidia" MatchDriver "nvidia-drm" Driver "nvidia" Option "PrimaryGPU" "yes" EndSection
Optimus management on Fedora is not as feature rich as those available for Ubuntu, Arch, and to a lesser extent openSUSE (see Nvidia Optimus on Linux). All that is possible is to choose whether the FOSS or proprietary drivers are loaded at boot using a different set of kernel command line options. For NVIDIA drivers use
- rd.driver.blacklist=nouveau
- modprobe.blacklist=nouveau
- nvidia-drm.modeset=1
And for the FOSS Nouveau driver, use
- rd.driver.blacklist=nvidia,nvidia_drm,nvidia_modeset
- modprobe.blacklist=nvidia,nvidia_drm,nvidia_modesetd
- nvidia-drm.modeset=0
No mechanism to manage the actual power state of the NVIDIA GPU is provided for pre-Turing Optimus laptops, which require either an external utility such as bbswitch or manual methods. And for post-Turing NVIDIA GPUs, whose power states can be managed by the driver when the laptop is set to hybrid graphics, no mechanism is provided to switch between the discrete and hybrid graphics modes as can be done with Optimus Manager on Arch, NVIDIA Prime on Ubuntu, and SUSEPrime on openSUSE. For a discussion of these issues see Nvidia Optimus on Linux.
Despite these limitations -- which is not an issue if using the laptop on an external power -- it is possible to make sure that the proprietary NVIDIA driver is used to benefit from it. The following image shows the output of nvidia-smi, showing that the GPUs memory is used.
The Output of nvidia-smi Running on RHEL 9 with NVIDIA Driver Installed from RPMFusion
Issues
RHEL 9 with the Server with GUI software selection for use as a workstation is polished and stable, and -- most impressively -- secure. I did experience some disappontment with the distribution, however.
Not LSB Compliant
Not Ready for Release
Modularity Abandoned
Conclusion
After a year of intermittently using Red Hat Enterprise Linux, installed as a 9.0 and updated through release 9.2, I have a generally favorable view of the distribution used as a workstation. I was especially impressed with the enterprise level security certified to multiple standards. The only officially supported desktop environment, GNOME, works without any issue, although I imagine many users will install extensions and custom themes.
Software is not the latest, but distributing older, thus well tested software, is one of the ways Red Hat can ensure a stable OS. Software is also limited in official repositories, but unofficial and third-party repositories are available as alternative sources of software, including additional desktop environments, proprietary drivers, and multimedia codecs.
Despite the overall positive impression I have developed, there were some characterisitcs of RHEL that I found disappointing. First, the distribution is not LSB compliant, as I learned when trying to install Epson multifunction printer drivers and management software downloaded as RPM packages directly from EPSON. Second, one of the most innovative features, introduced first in Fedora and appearing in RHEL for the first time in version 8, Modularity seems to be abandoned in RHEL 9.
More generally, the distribution was not ready for release, not necessarily in its functionality, but in various areas that support the distribution. In addition to modular streams essentially not being available, perhaps because the RHEL 8 series is still currently supported where module streams are plentiful, packages in the semi-official EPEL are not yet available for RHEL 9, while they are available for RHEL 8; some security profile standards are in unofficial draft status; and documentation for RHEL 9 is not as complete as for RHEL 8.
The controversy regarding Red Hat's actions to limit clones notwithstanding, the Individual Developer Subscriotion provides those with an interest in pursuing a career that involves RHEL and Red Hat software technologies a way to use the OS with access to all of the other Red Hat technologies and resources. It also provies others without any interest in pursuing a career that involves Red Hat products, a very secure and stable OS for non-commercial use.
with an interest in pursuing careers involving Red Hat Enterprise Linux and associated software technologies, and others, a very secure andReferences
- i Fedora Project Doc: Fedora and Red Hat Enterprise Linux
- Wikipedia Article: Fedora Linux release history
- Wikipedia Article: CentOS Stream
- Protection Profile for General Purpose Operating Systems, Version 4.2.1; 2019-04-22
- Security Categorization and Control Selection for National Security Systems
- Fedora Project Documentation; Extra Packages for Enterprise Linux (EPEL)
- Red hat Knowledge Base; How to use Extra Packages for Enterprise Linux (EPEL)?
- Red Hat Knowledge Base; How to enable NTFS support in Red Hat Enterprise Linux?
- NVIDIA Developer Blog; Streamlining NVIDIA Driver Deployment on RHEL 8 with Modularity Streams
- Rocky Linux Forum; Module in rhel 9
- NVIDIA Datacenter Documentation
- NVIDIA CUDA Documentation (Installing NVIDIA Driver from a Module Stream)
- RPMFusion; Configuration Howto
- Red Hat Enterprise Linux 9 Security Hardening; Chapter 2, Installing the system in FIPS mode
- CentOS Forum; No Modules on CentOS 9 Stream
- Fedora Project Documentation; Modularity
- Fedora Project Documentation; Modularity >> Core Concepts >> Module Stream
- Fedora Copr Documentation: User Documentation
- Fedora Copr Portal
- Red Hat Support Web Page; Red Hat Enterprise Linux Life Cycle
- RHEL 9 Documentation >> Managing software with the DNF tool >> Chapter 11. Managing versions of application stream content
- RHEL 8 Documentation >> Chapter 6 Managing Versions of Application Stream Content
- Fedora Forum; kmod, akmod, dkms ??
- No-cost Red Hat Enterprise Linux Individual Developer Subscription: FAQs
- Red Hat Documentation: Introduction to Red Hat Subscription Management Workflows
Notes:
- [1]
Other certified OSes include SUSE Enterprise Linux and Windows Server.
↩