Fedora & RHEL — A Fast-But-Tested Middle Ground

Comparative Linux Distributions

Chapter 3 · Fedora & RHEL — A Fast-But-Tested Middle Ground

Chapter 2 covered Debian feeding a slower, stable identity into a faster downstream (Ubuntu). Fedora and RHEL run the relationship in reverse — and that reversal is the single most important thing to understand about this family before anything else.

The Direction Runs the Opposite Way From Debian/Ubuntu

Upstream is the fast one here, not the stable one

In Chapter 2, Debian — the stable, conservative project — is upstream, and Ubuntu adds its own faster cadence on top of Debian's own packages. Fedora and RHEL invert that entirely: Fedora is the fast-moving upstream, sponsored by Red Hat as a genuine proving ground for new features, and RHEL is the slow, enterprise-stable downstream — taking a mature snapshot of accumulated Fedora features and supporting it for a decade. The same general "fast feeds slow" pattern, running in the opposite direction.

This isn't just organizational trivia — systemd itself, now the near-universal default across this entire course (Chapter 1), was first adopted as Fedora's own default init system in 2011, years before most other major distributions followed. Fedora's own explicit identity is built around shipping new upstream technology quickly, specifically so it can be battle-tested before RHEL ever touches it.

Fedora's Own Cadence

A new Fedora release roughly every six months, each version maintained for about 13 months total (giving a brief overlap window between consecutive releases) — genuinely fast by this course's own standards, though still meaningfully more conservative than Arch's continuous model, covered next in Chapter 4.

RHEL & CentOS Stream — the Enterprise Side

RHEL releases major versions roughly every three years, each supported for a full decade through a subscription-based commercial support model — Red Hat's own business, covered further in Chapter 9's governance material. CentOS Stream — worth knowing about specifically because its role changed in a widely discussed 2020 shift — used to be a free, downstream rebuild of finished RHEL releases; today it sits instead as a public "midstream" between Fedora and RHEL, previewing what the next RHEL minor version will actually contain rather than rebuilding what's already shipped.

	Role	Cadence	Support window
Fedora	Fast-moving upstream, community-driven	~Every 6 months	~13 months per release
CentOS Stream	Public midstream, previewing RHEL's next minor version	Rolling, tracking RHEL development	Tied to the RHEL major version it feeds
RHEL	Enterprise-stable downstream, commercially supported	~Every 3 years (major)	10 years

dnf & rpm — the Same Pairing Pattern as Chapter 2

.rpm (Red Hat Package Manager) is the package format; dnf is the modern high-level tool (successor to the older yum) — the exact same low-level-format/high-level-manager relationship Chapter 2 established for .deb and apt, just with different names.

# dnf: resolves dependencies, fetches from repositories sudo dnf install somepackage

SELinux — Enabled and Enforcing by Default

SELinux (Security-Enhanced Linux) is a mandatory access control system, enabled and set to Enforcing by default on Fedora and RHEL — a genuinely different, more restrictive security model than Debian/Ubuntu's own default use of AppArmor. This is a real, common source of confusion: a service can have entirely correct standard Unix file permissions and still be denied access, because SELinux enforces an additional, separate policy layer on top of ordinary permissions.

"Permission denied" on Fedora/RHEL is often SELinux, not Unix permissions

A service failing with what looks like a permissions error, despite chmod/chown already being correct, is a classic Fedora/RHEL troubleshooting trap — the real cause is very often an SELinux policy denial, checked via sestatus and the audit log, not a file-permission problem at all. Disabling SELinux entirely to make the error go away is a real, meaningful security regression, not a fix — the correct response is adjusting the SELinux policy (or the file's own security context) to permit the specific access actually needed.

Checking for an SELinux denial directly

sestatus confirms whether SELinux is active and in Enforcing or Permissive mode; ausearch -m avc -ts recent searches the audit log directly for recent denials — a faster, more targeted first step than assuming a standard permissions problem when something "should just work."

Hands-On Exercises

Exercise 1

Explain why describing Fedora and RHEL's relationship as "just like Debian and Ubuntu, but faster" would actually get the underlying structure backwards, using this chapter's own finding-box.

📄 View solution

Exercise 2

A service on a RHEL machine fails with what looks like a permissions error, even though file ownership and mode bits are already correct. Using this chapter's own warn-box, explain the likely real cause and why disabling SELinux isn't the right fix.

📄 View solution

Exercise 3

Explain what CentOS Stream's real role is today, and why calling it "just CentOS, like before 2020" would be inaccurate.

📄 View solution

Chapter 3 Quick Reference

Fedora is the fast upstream; RHEL is the stable downstream — the reverse direction from Debian (stable upstream) feeding Ubuntu (faster downstream)
systemd itself debuted as Fedora's own default years before most other distros adopted it
CentOS Stream — since 2020, a public midstream previewing RHEL's next minor version, not a rebuild of finished RHEL
rpm/dnf mirrors Chapter 2's own dpkg/apt low-level/high-level pairing
SELinux is enabled and Enforcing by default — a real, separate policy layer beyond ordinary Unix permissions, and a common troubleshooting trap
Next chapter: Arch — Rolling Release & DIY