Red Hat Enterprise Linux 9.0 Beta Released

[rmnscnce]

[USER="83794"]rmnscnce The workstation build doesn't install the redhat-backgrounds package as the art hasn't been produced. I don't recall previous RHEL versions auto-installing gnome-backgrounds, but I could be mistaken. GNOME Shell will have feature/fix backports from future GNOME releases, however the userspace applications can be rebased as desired to the actual upstream versions. If you look at RHEL 8 you'll see the same situation depending on the application.

The kernel situation isn't a weird tradition, it's just timing. The development freeze happened before 5.15 was released or even in RC phase; things have deadlines for the beta and other processes. And when it comes to the kernel, it really doesn't matter in RHEL's case as the kernel team will backport whatever they need from upstream (and shut off whatever they don't). A RHEL 5.14 kernel is not a 5.14 kernel for very long...

Cheers,
Mike

I see now. Thanks for the clarification.

[ZebCarnell]

I see now. Thanks for the clarification.

Hey are you the same rmnscnce who maintains the Copr XanMod and Liquorix kernels for Fedora?
Shot dude, love those packages.

[kylew77]

GraysonPeddie Take a look through the release notes doc to see what is deprecated and what is new. Overall, it's not a big change at all. One example of a change is in the networking stack, you can't use network-scripts anymore (e.g. ifcfg-<name>). You need to know how to configure things with NetworkManager and how it handles things in /etc/NetworkManager.
Cheers,
Mike

I have no idea how to do that. I work for a CentOS 6 and 7 shop and we do all the IP config from /etc/sysconfig/network-scripts/ifcfg-em1

[mroche]

I have no idea how to do that. I work for a CentOS 6 and 7 shop and we do all the IP config from /etc/sysconfig/network-scripts/ifcfg-em1

https://access.redhat.com/documentat...tworking/index

I can't speak for 6, but unless you explicitly disabled NetworkManager in 7 and tell the network-scripts to not be NM managed, you've been using NetworkManager under the hood (NM would generate and read ifcfg files for legacy compatbility). The RHEL docs should be a decent primer in getting started with NetworkManager, nmcli, and other tooling. Just note the beta docs are probably going to change a fair amount as noted on the second page, so you can use previous RHEL versions (like 8). Otherwise, just discount any reference to network-scripts.

NetworkManager is actually pretty easy to use in my experience, but like anything you need to see how your use case is affected by it. You can still technically use tools like ip to manage interfaces, but they operate independently of NM and you can't rely on NM tooling to report things correctly at that point.

Cheers,
Mike

[Delgarde]

Cgroupv2 enabled by default... that'll be nice. A lot of the container / Kubernetes tooling is starting to require V2, but while theoretically supported on RHEL8, it's not the default and doesn't work particularly well if enabled.

[abu_shawarib]

I've passed RHCSA8 and it already had NetworkManager in the main study materials. In the exam I used nmtui cause I'm too lazy to waste time checking syntax on a one time config.

Also look at this quote in the Red Hat page:

RHEL 9 Beta is something of a departure from previous major releases of RHEL. While it contains many improvements and enhancements customers have asked for, it has fewer changes that require admins and IT Ops to learn new ways of doing things. Familiar with RHEL 8? Then RHEL 9 Beta will help you feel right at home but with some welcome improvements and new features.

[mroche]

kylew77 I should make an amendment to my statement earlier. From the docs:

NetworkManager stores new network configurations to /etc/NetworkManager/system-connections/ in a keyfile format
Previously, NetworkManager stored new network configurations to /etc/sysconfig/network-scripts/ in the ifcfg format. Starting with RHEL 9.0, RHEL stores new network configurations at /etc/NetworkManager/system-connections/ in a keyfile format. The connections for which the configurations are stored to /etc/sysconfig/network-scripts/ in the old format still work uninterrupted. Modifications in existing profiles continue updating the older files.

(BZ#1894877)

My understanding of this statement is that if you upgrade (through leapp) to RHEL 9, you won't need to make any modifications to your current workflow. However if you were to reprovision, I'm not sure it would bother reading those config files. I can try and dig up some extra information on this if desired.

Cheers,
Mike

[pegasus]

How are various config managers (ansible, puppet, etc) happy with this transition to NM only? From what I've seen most of them have been writing out ifcfg style files and relying on OS to pick them up.

[Shiver1976]

I've passed RHCSA8 and it already had NetworkManager in the main study materials. In the exam I used nmtui cause I'm too lazy to waste time checking syntax on a one time config.

Also look at this quote in the Red Hat page:

Way back when RHCE/RHCSA 7 was out, nmtui was seriously broken when i had to do the exam. Honestly prefer just editing the files but if not given the choice, nmcli works way better. (but has also undergone a lot of changes)

[Chousuke]

How are various config managers (ansible, puppet, etc) happy with this transition to NM only? From what I've seen most of them have been writing out ifcfg style files and relying on OS to pick them up.

The ifcfg-* configuration files will continue to work. Even RHEL 8 already works without the network-scripts package (and it isn't installed by default). All this means is that in RHEL9, unlike RHEL8, you won't even have the *option* to install the legacy scripts in case you had something that required them. This is a *good* thing; the old script mess was all kinds of awful, and whatever you may think of NetworkManager, it's *fine* nowadays. I haven't missed having the old scripts on my RHEL8 hosts even once even though I still use the ifcfg-style configuration because it's easier to manage.

NetworkManager handles parsing the old ifcfg format and has bidirectional support (ie. you can edit connections with nmcli without issues). Technically speaking, it's not 100% backwards compatible because in RHEL6 and RHEL7 you could do crazy things like include shell code in the files, but I am not sad to see that particular functionality go.