The Real Differences Between Ubuntu and Red Hat Enterprise Linux in 2026 Source

May 12, 2026 Markdown source

1---
2title: "The Real Differences Between Ubuntu and Red Hat Enterprise Linux in 2026"
3date: "2026-05-12"
4published: true
5tags: ["linux", "ubuntu", "red-hat", "rhel", "enterprise-linux", "satellite", "landscape", "ansible", "selinux", "apparmor", "kickstart", "autoinstall"]
6author: "Gavin Jackson"
7excerpt: "A practical enterprise-level comparison of Ubuntu and Red Hat Enterprise Linux in 2026, focused on the things that matter when moving from an Ubuntu estate to a Red Hat one: management tooling, package lifecycle, services, SELinux, Ansible, and automated installs."
8hero: "ubuntu-rhel-vs"
9---
10
11# The Real Differences Between Ubuntu and Red Hat Enterprise Linux in 2026
12
13Moving from an Ubuntu shop to a Red Hat shop is not really a move from "Linux" to "Linux".
14
15At the shell, plenty of things feel familiar. You still have systemd, SSH, journald, OpenSSL, OpenSSH, Python, containers, cron, sudo, rsyslog, and all the usual small tools that make Linux feel like Linux. Most operational instincts still transfer.
16
17The real shift is the enterprise operating model around the distribution.
18
19Ubuntu and Red Hat Enterprise Linux both solve the same broad problem: provide a supported, secure, stable Linux platform for production workloads. But they make different tradeoffs around packaging, support boundaries, fleet management, security controls, automated installation, and lifecycle discipline.
20
21In 2026, that difference matters more than the old "apt vs yum" muscle memory.
22
23The current Ubuntu baseline is [Ubuntu 26.04 LTS](https://documentation.ubuntu.com/release-notes/26.04/), released on 23 April 2026 and supported as an LTS release for five years, with extended coverage available through Ubuntu Pro. The current Red Hat baseline is [Red Hat Enterprise Linux 10](https://www.redhat.com/en/about/press-releases/red-hat-introduces-rhel-10), released in May 2025, with the usual long enterprise lifecycle model behind it.
24
25This is the practical comparison I would want in front of me before moving from Ubuntu to RHEL.
26
27## The short version
28
29If you already manage Ubuntu well, you are not starting again.
30
31But you do need to re-learn a few habits:
32
33- Landscape becomes Satellite, or at least Red Hat Satellite plus Red Hat Hybrid Cloud Console and Lightspeed.
34- `apt` and `dpkg` become `dnf` and `rpm`.
35- Ubuntu repository categories become RHEL repositories such as BaseOS, AppStream, CodeReady Linux Builder, Supplementary, and add-on repositories.
36- AppArmor muscle memory becomes SELinux muscle memory.
37- Ubuntu Autoinstall becomes Kickstart.
38- `ufw` often becomes `firewalld`.
39- Netplan habits often become NetworkManager profile habits.
40- Package names change, service names change, and some old assumptions about packages starting services need to be checked.
41- Ansible still works very well, but the supported Red Hat automation story is more explicitly tied to Red Hat Ansible Automation Platform, RHEL system roles, Satellite, and certified collections.
42
43That last point is the key theme. Red Hat is not just a distro. It is an ecosystem built around entitlement, content lifecycle, compliance, supportability, and automation at scale.
44
45Ubuntu can absolutely be enterprise-grade, especially with Ubuntu Pro and Landscape. But Red Hat expects you to manage the operating system as part of a more formal content and compliance pipeline.
46
47## Baseline assumptions in 2026
48
49For Ubuntu, the enterprise comparison should mostly mean Ubuntu LTS, not interim releases. Ubuntu interim releases are useful for newer kernels and toolchains, but production fleets normally standardise on LTS releases.
50
51Ubuntu's [release cycle documentation](https://ubuntu.com/about/release-cycle) describes the model clearly: LTS releases arrive every two years and receive five years of standard security maintenance. Ubuntu Pro extends security coverage and adds enterprise features such as ESM, Livepatch, Landscape, FIPS packages, and compliance tooling.
52
53For Red Hat, the comparison is RHEL 9 and RHEL 10, but if you are planning a new environment in 2026, RHEL 10 is the obvious strategic baseline unless an application certification matrix says otherwise. Red Hat's [RHEL lifecycle policy](https://access.redhat.com/support/policy/updates/errata/) says RHEL 8, 9, and 10 have a ten-year lifecycle across Full Support and Maintenance Support phases, followed by an Extended Life Phase.
54
55The high-level difference:
56
57| Area | Ubuntu LTS | Red Hat Enterprise Linux |
58|---|---|---|
59| Current enterprise baseline | Ubuntu 26.04 LTS | RHEL 10 |
60| Commercial vendor | Canonical | Red Hat |
61| Primary package format | `.deb` | `.rpm` |
62| Primary package tool | `apt` | `dnf` |
63| Fleet management | Landscape | Satellite, Hybrid Cloud Console, Lightspeed |
64| Default MAC system | AppArmor | SELinux |
65| Automated install | Subiquity Autoinstall | Anaconda Kickstart |
66| Firewall habit | `ufw`, raw nftables/iptables where needed | `firewalld`, nftables where needed |
67| Networking habit | Netplan rendering to NetworkManager or systemd-networkd | NetworkManager |
68| Automation story | Ansible, cloud-init, Landscape scripts, MAAS | Ansible Automation Platform, RHEL system roles, Satellite remote execution |
69
70The important part is not that one column is "better". It is that the operational centre of gravity moves.
71
72> ## Old Enough to Remember When Red Hat Came in a Box
73>
74> One reason this comparison feels interesting to me is that I am old enough to remember Red Hat before "Enterprise Linux" was the default association.
75>
76> When I was at university, Red Hat Linux 5.2 was a normal Linux distribution you could install, break, reinstall, and learn from. Red Hat's own [1998 release announcement](https://www.redhat.com/ko/about/press-releases/press-redhatlinux52) described Red Hat Linux 5.2 as a boxed operating system with three CDs, an installation manual, 90 days of installation support, Apache 1.3, GIMP 1.0, and a retail price of US$49.95. That was a very different world. It was Linux as a thing you bought, borrowed, copied, installed on spare hardware, and gradually turned into a career.
77>
78> Then Linux grew up.
79>
80> Red Hat created what became Red Hat Enterprise Linux in 2002 for customers who wanted a stable, supported, certified operating system. The first RHEL 2.1 general availability date listed by Red Hat is [23 March 2002](https://access.redhat.com/articles/red-hat-enterprise-linux-release-dates). By late 2003, Red Hat had also introduced the Fedora Project as the community and early-technology track, while RHEL became the stable commercial platform. Red Hat's own explanation of the split is pretty blunt: one product could no longer meet the conflicting needs of hobbyists, developers, and enterprise customers.
81>
82> Ubuntu arrived just after that moment. Ubuntu 4.10, "Warty Warthog", was announced on [20 October 2004](https://lists.ubuntu.com/archives/ubuntu-announce/2004-October/000003.html) as the first Ubuntu release, with the now almost mythic offer to ship CDs at no cost. It was not officially "the anti-RHEL", and it would be too neat to pretend the history was that simple. But for a lot of Linux users, Ubuntu landed at exactly the right time: after the old Red Hat Linux line had given way to Fedora and RHEL, and when there was a real appetite for a polished, freely available, community-friendly Linux distribution that did not feel like it was asking for a procurement conversation before you could start learning.
83>
84> That history still echoes in 2026.
85>
86> IBM completed its acquisition of Red Hat in [July 2019](https://www.ibm.com/investor/news/ibm-completes-acquisition-of-red-hat), and RHEL is now firmly part of a much larger enterprise software business. On sticker price alone, the comparison can look stark. As of May 2026, Red Hat lists RHEL Server at US$383.90 for self-support, US$878.90 for standard support, and US$1,428.90 for premium support, with Satellite bundles and other add-ons priced separately. Canonical lists Ubuntu Pro at US$500 per server per year, with 24/7 support tiers at US$1,775 for infrastructure support and US$3,400 for full support.
87>
88> Those numbers should not be compared too lazily. Red Hat's self-support tier is not intended for production, the products are packaged differently, the support models are different, and the real enterprise bill depends on architecture, virtualisation density, public cloud consumption, support level, management tooling, discounts, and procurement agreements.
89>
90> But the emotional shape of the comparison is hard to miss. Ubuntu still carries some of that "just let me run Linux" energy, even when wrapped in Ubuntu Pro, Landscape, FIPS, Livepatch, and compliance tooling. Red Hat still carries the weight of the platform that large enterprises trust when they need certification, lifecycle discipline, vendor accountability, Satellite-driven content management, and a very mature operating model at scale.
91>
92> That is why I would not reduce this to price. Ubuntu Pro can be very compelling commercially, especially for broad fleets and teams already comfortable with Ubuntu. Red Hat is harder to beat when the question becomes: how do we run thousands of systems through a controlled content lifecycle, with certified applications, formal support paths, mature policy tooling, and a management model that auditors and operations teams can both understand?
93>
94> In a strange way, the old Red Hat Linux 5.2 box and the modern RHEL subscription are part of the same story. Linux went from something we installed because it was exciting to something organisations run because it is boring in exactly the right ways.
95
96## Landscape vs Satellite
97
98This is probably the biggest enterprise difference.
99
100If you manage Ubuntu at scale, you may already use [Landscape](https://documentation.ubuntu.com/pro/landscape/), Canonical's systems management tool for Ubuntu machines. In 2026, Landscape is available as SaaS, self-hosted Landscape, and Managed Landscape. Canonical's own comparison is useful: SaaS gives inventory, security, compliance, hardening, and reporting, but self-hosted and managed options are where you get repository management and offline-friendly patterns.
101
102That matters because "Landscape" is not one identical thing in every deployment. If you are used to Landscape SaaS and you move to RHEL, do not assume the Red Hat equivalent is just "a web console that shows machines". Satellite is more opinionated about content lifecycle.
103
104[Red Hat Satellite 6.17](https://docs.redhat.com/en/documentation/red_hat_satellite/6.17/) is the classic Red Hat estate management tool. It handles host registration, content management, lifecycle environments, content views, repository synchronization, patching, provisioning, remote execution, host groups, Capsule servers, activation keys, Ansible integration, and compliance workflows.
105
106The concepts to learn are:
107
108- **Organization and location**: Satellite partitions management across business and infrastructure boundaries.
109- **Content views**: curated sets of repositories and packages that can be promoted through lifecycle environments.
110- **Lifecycle environments**: dev, test, prod, or whatever promotion path you define.
111- **Activation keys**: registration profiles used to attach hosts to subscriptions, content views, environments, repository sets, and system purpose.
112- **Capsule servers**: distributed Satellite components for content, provisioning, DNS, DHCP, TFTP, and remote execution closer to hosts.
113- **Host groups**: repeatable host configuration and provisioning templates.
114- **Remote execution**: run jobs against hosts from Satellite.
115- **Ansible integration**: run roles and playbooks as part of host management.
116
117The most important mental model is this:
118
119**Landscape often feels like Ubuntu fleet management. Satellite feels like a content supply chain.**
120
121Satellite wants you to think about which exact repository content a machine is entitled to see, which lifecycle stage that content is in, and how content moves from sync to test to production. Red Hat's Satellite docs describe [activation keys](https://docs.redhat.com/en/documentation/red_hat_satellite/6.17/html-single/managing_content/index#chap-Managing_Content-Managing_Activation_Keys) as a way to automate registration and associate systems with environments and content views. That is not just a convenience feature. In a real RHEL estate, activation keys become part of how you encode server purpose.
122
123If you are coming from Ubuntu, this is where I would spend time first. Package commands can be learned in an afternoon. A bad content lifecycle design can annoy you for years.
124
125## Package management: apt to dnf
126
127At the daily command level, the translation is simple enough:
128
129| Ubuntu | RHEL |
130|---|---|
131| `apt update` | `dnf check-update` or let `dnf` refresh metadata as needed |
132| `apt install nginx` | `dnf install nginx` |
133| `apt remove nginx` | `dnf remove nginx` |
134| `apt purge nginx` | no direct habit match; remove package and clean config deliberately |
135| `apt search nginx` | `dnf search nginx` |
136| `apt show nginx` | `dnf info nginx` |
137| `dpkg -l` | `rpm -qa` |
138| `dpkg -S /path/file` | `rpm -qf /path/file` |
139| `apt-file search /path/file` | `dnf provides /path/file` |
140| `apt-mark hold package` | `dnf versionlock package` if the plugin is installed |
141| `/etc/apt/sources.list.d/*.sources` | `/etc/yum.repos.d/*.repo` |
142
143But again, the command syntax is the easy part.
144
145Ubuntu's package model is Debian-based. The main supported base is in Main and Restricted, with Universe and Multiverse adding a large body of community-maintained software. The [Ubuntu Server package management documentation](https://documentation.ubuntu.com/server/how-to/software/package-management/) notes that Ubuntu 24.04 and later use deb822 repository files such as `/etc/apt/sources.list.d/ubuntu.sources` by default. It also points out a support boundary that matters in enterprise environments: Universe and Multiverse are not supported in the same way as the base repositories unless you have the relevant Ubuntu Pro coverage.
146
147RHEL's package model is RPM-based. In RHEL 10, Red Hat documents the main content repositories as [BaseOS, AppStream, CodeReady Linux Builder, Supplementary, and add-on repositories](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html-single/managing_software_with_the_dnf_tool/index). BaseOS is the core operating system. AppStream contains user-space applications, runtimes, languages, and databases. CodeReady Linux Builder is available with subscriptions, but Red Hat explicitly says packages in that repository are not supported.
148
149That is a trap for Ubuntu admins.
150
151On Ubuntu, enabling Universe is normal. On RHEL, enabling CodeReady Linux Builder may be necessary for build dependencies or certain developer workflows, but it should not be treated as equivalent to a fully supported application source. In regulated or tightly supported environments, that distinction matters.
152
153RHEL also has Application Streams. These provide newer or alternate user-space components while keeping the core platform stable. Red Hat's RHEL 10 docs note that Application Streams can have their own lifecycle, sometimes shorter than the RHEL major release. Before you standardise on a language runtime or database from AppStream, check its lifecycle rather than assuming it lives for the full OS lifecycle.
154
155The other package habit to re-learn is errata.
156
157Ubuntu admins often think in terms of package upgrades and Ubuntu Security Notices. RHEL admins think in terms of package updates, RHSA security advisories, RHBA bug advisories, RHEA enhancements, CVE severity, and whether content has been promoted into the right Satellite content view. In practice, that means your patch reporting and compliance dashboards need to change vocabulary.
158
159## Automatic updates and patching
160
161Ubuntu Server commonly uses unattended upgrades for security updates. The Ubuntu package management docs say the default for Ubuntu Server is to automatically apply security updates.
162
163RHEL can automate updates too, but the habit is different. Red Hat documents [DNF Automatic](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/managing_software_with_the_dnf_tool/index) for automated software updates, including systemd timer units. In a larger Red Hat environment, however, you will often coordinate patching through Satellite, maintenance windows, content views, and job templates rather than letting every server independently pull whatever is current.
164
165That is not just bureaucracy. It is how Red Hat environments avoid drift.
166
167If you are moving from Ubuntu to RHEL, decide early:
168
169- Are hosts allowed to update directly from Red Hat CDN?
170- Are hosts registered to Satellite and pinned to lifecycle environments?
171- Do dev, test, and prod see different content views?
172- Who promotes errata into production?
173- Are security updates automatically applied, automatically staged, or manually approved?
174- How do you handle kernel updates and reboots?
175- What is the exception path for emergency CVEs?
176
177These questions exist on Ubuntu too, but Satellite makes them more explicit.
178
179## Services and startup behaviour
180
181Both Ubuntu and RHEL use systemd. That part is familiar.
182
183The commands are the same:
184
185```bash
186systemctl status ssh
187systemctl enable --now nginx
188systemctl disable --now nginx
189journalctl -u nginx
190systemctl list-unit-files
191```
192
193The differences are in naming, packaging policy, defaults, and surrounding security controls.
194
195Common service name changes include:
196
197| Ubuntu habit | RHEL habit |
198|---|---|
199| `apache2` | `httpd` |
200| `ssh` | `sshd` |
201| `cron` | `crond` |
202| `rsyslog` | `rsyslog` |
203| `ufw` | `firewalld` |
204| `apparmor` | `selinux` tooling rather than an equivalent service |
205
206The first practical rule is to stop assuming package names and service names match your Ubuntu notes. Sometimes they do. Often they do not.
207
208The second rule is to be explicit in automation. If a service should run, say so:
209
210```yaml
211- name: Install Apache on RHEL
212  ansible.builtin.dnf:
213    name: httpd
214    state: present
215
216- name: Enable and start Apache
217  ansible.builtin.systemd:
218    name: httpd
219    enabled: true
220    state: started
221```
222
223Do not rely on a package install side effect.
224
225On Debian and Ubuntu systems, packages that provide services commonly arrange for those services to start through maintainer scripts and init integration. Debian policy says packages providing system services should arrange for those services to be automatically started and stopped by the init system or service manager. In automation, Ansible's `apt` module even has a `policy_rc_d` option for cases where you want to prevent services from starting during package installation.
226
227On RHEL-like systems, service enablement is more tied to systemd presets and explicit service management. You should still check the specific package, but as an operational pattern, RHEL automation should install, configure, open firewall policy, set SELinux context where needed, and then enable/start the service deliberately.
228
229One more wrinkle: Ubuntu 26.04 release notes say it is the last Ubuntu release that supports System V service script compatibility in systemd. That is a useful reminder that both ecosystems are continuing to push old init assumptions out of the way. If your internal apps still ship ancient init scripts, now is a good time to turn them into proper unit files.
230
231## AppArmor vs SELinux
232
233This is the difference that will hurt most if you ignore it.
234
235Ubuntu uses AppArmor by default. Canonical's [Ubuntu Server AppArmor documentation](https://documentation.ubuntu.com/server/how-to/security/apparmor/) describes AppArmor as a Mandatory Access Control system that restricts application capabilities with per-program profiles. It is installed and loaded by default on Ubuntu, profiles live in `/etc/apparmor.d/`, and profiles can run in complain or enforce mode.
236
237RHEL uses SELinux by default. Red Hat's [RHEL 10 SELinux documentation](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html-single/using_selinux/index) describes SELinux as a Mandatory Access Control implementation where policy defines how users and processes interact with files and devices. RHEL installs with SELinux in enforcing mode by default.
238
239The practical difference:
240
241- AppArmor is profile and path oriented.
242- SELinux is label, type, role, and policy oriented.
243
244That difference changes troubleshooting.
245
246On Ubuntu, if an application cannot read `/srv/app/config.yaml`, you might inspect AppArmor logs and adjust the application profile to allow that path.
247
248On RHEL, if `httpd` cannot read `/srv/app/index.html`, the Unix permissions may be correct and the process may still be denied because the file has the wrong SELinux context. The fix is not `chmod 777`. The fix is more likely:
249
250```bash
251semanage fcontext -a -t httpd_sys_content_t '/srv/app(/.*)?'
252restorecon -Rv /srv/app
253```
254
255Or if you move a service to a non-standard port:
256
257```bash
258semanage port -a -t http_port_t -p tcp 8080
259```
260
261The mindset shift is this:
262
263**On RHEL, "root can read it" does not mean "the service domain can read it".**
264
265That is a good thing. It is also the source of many bad first weeks for Ubuntu admins new to RHEL.
266
267Useful commands to learn early:
268
269```bash
270getenforce
271sestatus
272ls -Z
273ps -eZ
274ausearch -m AVC,USER_AVC -ts recent
275sealert -a /var/log/audit/audit.log
276semanage fcontext -l
277restorecon -Rv /some/path
278setsebool -P httpd_can_network_connect on
279```
280
281The worst possible migration pattern is disabling SELinux because it blocked a workload during testing. That usually means the test found a real policy mismatch, mislabeled file, unsupported application layout, or missing boolean. Fix that before production.
282
283AppArmor can be simpler to reason about for application-specific path access. SELinux can be harder at first, but it is deeply integrated into the RHEL security model, service policy, container story, and compliance expectations. In Red Hat environments, SELinux is not an optional hardening extra. Treat it as part of the platform.
284
285## Ansible support and automation
286
287Ansible remains one of the easiest bridges between Ubuntu and RHEL.
288
289The same control node can manage both families. The same inventory can group both. The same playbook can branch on facts:
290
291```yaml
292- name: Install web server package
293  ansible.builtin.package:
294    name: "{{ 'apache2' if ansible_os_family == 'Debian' else 'httpd' }}"
295    state: present
296```
297
298For truly generic work, `ansible.builtin.package`, `ansible.builtin.service`, `ansible.builtin.systemd`, `ansible.builtin.copy`, and `ansible.builtin.template` keep your playbooks portable.
299
300But enterprise automation usually needs OS-family-specific roles. Package names differ, config paths differ, SELinux exists on one side, AppArmor on the other, firewall tooling differs, and repository management is completely different.
301
302The Red Hat-specific automation story is strong. RHEL 10 includes `ansible-core` 2.16, and Red Hat documents [RHEL system roles](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/automating_system_administration_by_using_rhel_system_roles/index/) as a supported way to automate repeatable administration tasks. These roles cover areas such as networking, storage, SELinux, firewalld, crypto policies, journald, SSH, timesync, Podman, kernel settings, and systemd.
303
304That is worth using.
305
306If you are migrating from Ubuntu, do not immediately port every internal role line-for-line. First check whether RHEL system roles already cover the boring-but-dangerous base configuration. Boring infrastructure should be boring on purpose.
307
308Satellite also integrates with Ansible. Red Hat Satellite 6.17 documentation includes [Ansible integration](https://docs.redhat.com/en/documentation/red_hat_satellite/6.17/html/managing_configurations_by_using_ansible_integration/Getting_Started_with_Ansible_in_satellite_ansible), and Satellite can run roles during registration and remote execution workflows.
309
310The practical migration pattern I like is:
311
3121. Keep application deployment roles mostly portable.
3132. Split OS baseline roles by family.
3143. Use RHEL system roles for RHEL platform configuration where possible.
3154. Use Satellite for registration, content lifecycle, host groups, remote jobs, and compliance visibility.
3165. Use Ansible Automation Platform if you need enterprise workflow, RBAC, controller features, certified content, and support.
317
318The anti-pattern is pretending RHEL is "Ubuntu with dnf". That leads to fragile roles full of conditionals and small exceptions.
319
320## Autoinstall vs Kickstart
321
322Ubuntu's automated installer is Subiquity Autoinstall. Red Hat's automated installer is Kickstart.
323
324They solve the same problem: install the OS without clicking through screens.
325
326They do not feel the same.
327
328Ubuntu Autoinstall uses YAML. The [Autoinstall reference](https://canonical-subiquity.readthedocs-hosted.com/en/latest/reference/autoinstall-reference.html) uses a top-level `autoinstall` key, currently with `version: 1`. It can configure identity, locale, keyboard, networking, proxy, apt mirrors, storage, snaps, packages, SSH, drivers, user-data, early commands, late commands, and interactive sections.
329
330A tiny Ubuntu example looks like this:
331
332```yaml
333#cloud-config
334autoinstall:
335  version: 1
336  identity:
337    hostname: ubuntu-server
338    username: ubuntu
339    password: "$6$..."
340  ssh:
341    install-server: true
342  storage:
343    layout:
344      name: lvm
345  apt:
346    mirror-selection:
347      primary:
348        - uri: "http://mirror.internal/ubuntu"
349```
350
351Subiquity can consume this through cloud-init style delivery such as NoCloud. The [quick start](https://canonical-subiquity.readthedocs-hosted.com/en/latest/howto/autoinstall-quickstart.html) shows the familiar `autoinstall ds=nocloud-net;s=http://.../` boot parameter pattern.
352
353Red Hat Kickstart is older, more established in enterprise bare-metal provisioning, and tightly associated with Anaconda and Satellite. Red Hat's [RHEL 10 automatic installation documentation](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/automatically_installing_rhel/index) describes Kickstart as a way to deploy RHEL from a predefined configuration. Kickstart files contain commands and sections such as `%packages`, `%pre`, `%post`, repository definitions, network configuration, storage layout, timezone, users, firewall, SELinux, and service enablement.
354
355A tiny RHEL example looks more like this:
356
357```kickstart
358lang en_US.UTF-8
359keyboard us
360timezone Australia/Sydney --utc
361network --bootproto=dhcp --device=link --activate
362rootpw --iscrypted $6$...
363selinux --enforcing
364firewall --enabled --service=ssh
365services --enabled=sshd,chronyd
366url --url=http://mirror.internal/rhel/10/BaseOS/x86_64/os/
367
368%packages
369@^minimal-environment
370chrony
371%end
372
373%post
374subscription-manager register --activationkey=rhel-prod --org=my-org
375%end
376```
377
378With Satellite, Kickstart becomes part of a larger provisioning model. Satellite host groups, provisioning templates, activation keys, content views, lifecycle environments, DNS, DHCP, TFTP, HTTP boot, and Capsule placement can all become part of the install path. Red Hat's Satellite content docs note that Kickstart provisioning templates can register hosts with activation keys.
379
380There is also an interesting Ubuntu development here. Canonical documents that [Landscape server 25.10 and later can serve Autoinstall files](https://documentation.ubuntu.com/landscape/how-to-guides/ubuntu-installer/set-up-autoinstall-provisioning/) to the Ubuntu installer for Ubuntu 26.04 and later, but only for self-hosted deployments and with OIDC requirements. That brings Landscape closer to the provisioning workflow, but Satellite is still the more mature all-in-one RHEL provisioning control plane.
381
382When migrating, do not try to mechanically convert Autoinstall YAML to Kickstart. Re-design the install pipeline:
383
384- How will systems boot: ISO, PXE, UEFI HTTP boot, virtual media, cloud image, image builder?
385- Where does install media come from: Red Hat CDN, Satellite, local mirror, custom ISO?
386- How will systems register: subscription-manager, activation key, Satellite global registration?
387- Which repositories are available at install time?
388- Which content view does the host land in?
389- How is storage expressed?
390- What happens in `%post`, and what should move into Ansible instead?
391- How are secrets passed safely?
392
393Kickstart is powerful, but `%post` can become a junk drawer. Keep the installer responsible for installing and registering the machine. Let Ansible or Satellite handle the rest.
394
395## Firewalls and networking
396
397This is not always the first thing people ask about, but it is one of the first things they trip over.
398
399Ubuntu Server documentation describes [Netplan](https://documentation.ubuntu.com/server/explanation/networking/about-netplan) as the way network configuration is handled on Ubuntu. Netplan gives you YAML, then renders to NetworkManager or systemd-networkd depending on the system.
400
401RHEL uses NetworkManager directly as the normal server networking layer. The modern command-line habit is `nmcli`, NetworkManager connection profiles, and keyfile-backed configuration. If your Ubuntu automation writes Netplan YAML, that code does not move across directly.
402
403Firewall defaults also differ.
404
405Ubuntu's server docs describe [ufw](https://documentation.ubuntu.com/server/how-to/security/firewalls/) as the default firewall configuration tool for Ubuntu. It is simple and friendly for host-based rules, though many enterprises still manage nftables, cloud security groups, or external firewalls directly.
406
407RHEL's firewall documentation focuses on [firewalld and nftables](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html-single/configuring_firewalls_and_packet_filters/index). `firewalld` uses zones, services, runtime configuration, and permanent configuration. That runtime/permanent split is worth learning immediately:
408
409```bash
410firewall-cmd --add-service=http
411firewall-cmd --add-service=http --permanent
412firewall-cmd --reload
413```
414
415If you only make a runtime change, it disappears later. If you only make a permanent change and do not reload, it may not affect the current running firewall. That is an easy mistake to make when you are used to `ufw allow 80`.
416
417Also remember that on RHEL, a service can be installed, configured, and running, while still blocked by firewalld and/or SELinux. Troubleshooting needs to check all layers:
418
419```bash
420systemctl status httpd
421ss -ltnp
422firewall-cmd --list-all
423getenforce
424ausearch -m AVC -ts recent
425```
426
427## Security and compliance posture
428
429Both vendors have serious enterprise security stories, but they package the experience differently.
430
431Ubuntu Pro adds ESM, Livepatch, FIPS packages, compliance profiles, Landscape, and support options. Ubuntu 26.04 also has a noticeable security push around memory-safe system components, TPM-backed full-disk encryption, and improved application permission prompting.
432
433RHEL's security story is built around SELinux, crypto policies, FIPS workflows, OpenSCAP, system roles, Satellite compliance, Insights or Lightspeed recommendations, certified content, Common Criteria and government/compliance expectations, and a very formal support boundary.
434
435For an Ubuntu-to-RHEL migration, the highest-impact differences are:
436
437- **SELinux is expected to stay enforcing.**
438- **System-wide crypto policies matter.**
439- **FIPS enablement needs to be planned before workloads are deployed.**
440- **Compliance content is often tied into Satellite, OpenSCAP, and Red Hat tooling.**
441- **Third-party repositories are a bigger governance issue than they may have been in an Ubuntu estate.**
442- **Supportability depends heavily on staying inside Red Hat's packaging and configuration boundaries.**
443
444In other words, RHEL rewards discipline. It can feel slower at first, but the point is repeatability, auditability, and vendor-supported state.
445
446## Things that will catch Ubuntu admins
447
448Here is the checklist I would pin near the terminal for the first month.
449
450### Package and repository traps
451
452- `yum` is mostly muscle memory now. Use `dnf`.
453- Do not treat CodeReady Linux Builder like Ubuntu Universe.
454- Check AppStream lifecycle before standardising on runtimes.
455- Learn `rpm -qf`, `dnf provides`, `dnf history`, and `dnf repoquery`.
456- Expect `/etc/yum.repos.d/redhat.repo` to be managed through subscription/Satellite tooling.
457- Do not casually add random `.repo` files to production servers.
458
459### Service traps
460
461- `apache2` is `httpd`.
462- `ssh` is usually `sshd`.
463- `cron` is usually `crond`.
464- Be explicit with `systemctl enable --now`.
465- Check firewalld if a service is listening but unreachable.
466- Check SELinux if permissions look correct but the app still cannot access something.
467
468### Security traps
469
470- Do not disable SELinux to "fix" an app.
471- Learn `ls -Z` as early as you learned `ls -l`.
472- File labels matter as much as file modes.
473- Ports have SELinux types too.
474- Container bind mounts may need SELinux relabel options.
475
476### Automation traps
477
478- Split Debian-family and Red Hat-family baseline roles.
479- Use `ansible_os_family` carefully.
480- Prefer RHEL system roles where they fit.
481- Replace `ufw` tasks with `firewalld` tasks.
482- Replace Netplan rendering with NetworkManager profile management.
483- Keep Kickstart small and move application configuration into Ansible.
484
485### Management traps
486
487- Satellite content views are not just folders.
488- Activation keys are not just registration tokens.
489- Lifecycle environments should match your patch promotion model.
490- Capsule placement matters for remote sites and disconnected environments.
491- Decide whether Red Hat CDN access is allowed directly or only through Satellite.
492
493## A sensible migration approach
494
495I would not start by converting every server.
496
497I would start by building a small RHEL operating model:
498
4991. Pick the supported RHEL major and minor strategy.
5002. Define how hosts register: Red Hat CDN, Satellite, activation keys, or cloud marketplace entitlement.
5013. Build content views and lifecycle environments before production hosts exist.
5024. Create a minimal Kickstart that installs, registers, and hands off to automation.
5035. Create RHEL baseline Ansible roles for users, SSH, time sync, logging, firewall, SELinux, monitoring, and backup agents.
5046. Port one low-risk application.
5057. Keep SELinux enforcing and fix every denial properly.
5068. Document package and service name translations.
5079. Add patch reporting and errata reporting before the first production maintenance window.
50810. Train the team on `dnf`, `rpm`, `subscription-manager`, `firewall-cmd`, `semanage`, `restorecon`, `ausearch`, and Satellite basics.
509
510The goal is not to make RHEL behave like Ubuntu. The goal is to understand the Red Hat way well enough that the platform becomes boring.
511
512That is where RHEL shines. It is not exciting because `dnf install` is more interesting than `apt install`. It is useful because the management, content, security, and support model can become very predictable when you lean into it.
513
514## Final thoughts
515
516Ubuntu and Red Hat Enterprise Linux are both excellent enterprise Linux platforms.
517
518Ubuntu often feels faster to get moving with. The package universe is huge, the community is broad, cloud images are everywhere, and the Debian-style workflow is familiar to a lot of infrastructure teams.
519
520RHEL often feels more deliberate. The supported content boundaries are clearer, SELinux is central, Satellite gives you a strong content lifecycle model, and Red Hat's ecosystem is built for organisations that care deeply about vendor support, compliance, and repeatable operations.
521
522If you are switching from Ubuntu to RHEL, the hard part is not the shell. It is the operating model.
523
524Learn Satellite properly. Respect SELinux. Treat repositories as a governed supply chain. Rewrite your installer automation instead of translating it line by line. Use Ansible, but do not pretend OS families are identical. Be explicit about services, firewall policy, content lifecycle, and support boundaries.
525
526Once those pieces click, RHEL starts to feel less like a different distro and more like a different contract with production.
527
528That is the real migration.
529
530## Further reading
531
532- [Ubuntu 26.04 LTS release notes](https://documentation.ubuntu.com/release-notes/26.04/)
533- [Ubuntu release cycle](https://ubuntu.com/about/release-cycle)
534- [Ubuntu Server package management](https://documentation.ubuntu.com/server/how-to/software/package-management/)
535- [Ubuntu AppArmor documentation](https://documentation.ubuntu.com/server/how-to/security/apparmor/)
536- [Ubuntu Autoinstall reference](https://canonical-subiquity.readthedocs-hosted.com/en/latest/reference/autoinstall-reference.html)
537- [Landscape documentation](https://documentation.ubuntu.com/pro/landscape/)
538- [Red Hat Enterprise Linux 10 announcement](https://www.redhat.com/en/about/press-releases/red-hat-introduces-rhel-10)
539- [Red Hat Enterprise Linux lifecycle](https://access.redhat.com/support/policy/updates/errata/)
540- [RHEL 10 DNF documentation](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html-single/managing_software_with_the_dnf_tool/index)
541- [RHEL 10 SELinux documentation](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html-single/using_selinux/index)
542- [RHEL 10 Kickstart documentation](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/automatically_installing_rhel/index)
543- [Red Hat Satellite 6.17 documentation](https://docs.redhat.com/en/documentation/red_hat_satellite/6.17/)
544- [RHEL system roles documentation](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/automating_system_administration_by_using_rhel_system_roles/index/)
545

---
title: "The Real Differences Between Ubuntu and Red Hat Enterprise Linux in 2026"
date: "2026-05-12"
published: true
tags: ["linux", "ubuntu", "red-hat", "rhel", "enterprise-linux", "satellite", "landscape", "ansible", "selinux", "apparmor", "kickstart", "autoinstall"]
author: "Gavin Jackson"
excerpt: "A practical enterprise-level comparison of Ubuntu and Red Hat Enterprise Linux in 2026, focused on the things that matter when moving from an Ubuntu estate to a Red Hat one: management tooling, package lifecycle, services, SELinux, Ansible, and automated installs."
hero: "ubuntu-rhel-vs"
---

# The Real Differences Between Ubuntu and Red Hat Enterprise Linux in 2026

Moving from an Ubuntu shop to a Red Hat shop is not really a move from "Linux" to "Linux".

At the shell, plenty of things feel familiar. You still have systemd, SSH, journald, OpenSSL, OpenSSH, Python, containers, cron, sudo, rsyslog, and all the usual small tools that make Linux feel like Linux. Most operational instincts still transfer.

The real shift is the enterprise operating model around the distribution.

Ubuntu and Red Hat Enterprise Linux both solve the same broad problem: provide a supported, secure, stable Linux platform for production workloads. But they make different tradeoffs around packaging, support boundaries, fleet management, security controls, automated installation, and lifecycle discipline.

In 2026, that difference matters more than the old "apt vs yum" muscle memory.

The current Ubuntu baseline is [Ubuntu 26.04 LTS](https://documentation.ubuntu.com/release-notes/26.04/), released on 23 April 2026 and supported as an LTS release for five years, with extended coverage available through Ubuntu Pro. The current Red Hat baseline is [Red Hat Enterprise Linux 10](https://www.redhat.com/en/about/press-releases/red-hat-introduces-rhel-10), released in May 2025, with the usual long enterprise lifecycle model behind it.

This is the practical comparison I would want in front of me before moving from Ubuntu to RHEL.

## The short version

If you already manage Ubuntu well, you are not starting again.

But you do need to re-learn a few habits:

- Landscape becomes Satellite, or at least Red Hat Satellite plus Red Hat Hybrid Cloud Console and Lightspeed.
- `apt` and `dpkg` become `dnf` and `rpm`.
- Ubuntu repository categories become RHEL repositories such as BaseOS, AppStream, CodeReady Linux Builder, Supplementary, and add-on repositories.
- AppArmor muscle memory becomes SELinux muscle memory.
- Ubuntu Autoinstall becomes Kickstart.
- `ufw` often becomes `firewalld`.
- Netplan habits often become NetworkManager profile habits.
- Package names change, service names change, and some old assumptions about packages starting services need to be checked.
- Ansible still works very well, but the supported Red Hat automation story is more explicitly tied to Red Hat Ansible Automation Platform, RHEL system roles, Satellite, and certified collections.

That last point is the key theme. Red Hat is not just a distro. It is an ecosystem built around entitlement, content lifecycle, compliance, supportability, and automation at scale.

Ubuntu can absolutely be enterprise-grade, especially with Ubuntu Pro and Landscape. But Red Hat expects you to manage the operating system as part of a more formal content and compliance pipeline.

## Baseline assumptions in 2026

For Ubuntu, the enterprise comparison should mostly mean Ubuntu LTS, not interim releases. Ubuntu interim releases are useful for newer kernels and toolchains, but production fleets normally standardise on LTS releases.

Ubuntu's [release cycle documentation](https://ubuntu.com/about/release-cycle) describes the model clearly: LTS releases arrive every two years and receive five years of standard security maintenance. Ubuntu Pro extends security coverage and adds enterprise features such as ESM, Livepatch, Landscape, FIPS packages, and compliance tooling.

For Red Hat, the comparison is RHEL 9 and RHEL 10, but if you are planning a new environment in 2026, RHEL 10 is the obvious strategic baseline unless an application certification matrix says otherwise. Red Hat's [RHEL lifecycle policy](https://access.redhat.com/support/policy/updates/errata/) says RHEL 8, 9, and 10 have a ten-year lifecycle across Full Support and Maintenance Support phases, followed by an Extended Life Phase.

The high-level difference:

| Area | Ubuntu LTS | Red Hat Enterprise Linux |
|---|---|---|
| Current enterprise baseline | Ubuntu 26.04 LTS | RHEL 10 |
| Commercial vendor | Canonical | Red Hat |
| Primary package format | `.deb` | `.rpm` |
| Primary package tool | `apt` | `dnf` |
| Fleet management | Landscape | Satellite, Hybrid Cloud Console, Lightspeed |
| Default MAC system | AppArmor | SELinux |
| Automated install | Subiquity Autoinstall | Anaconda Kickstart |
| Firewall habit | `ufw`, raw nftables/iptables where needed | `firewalld`, nftables where needed |
| Networking habit | Netplan rendering to NetworkManager or systemd-networkd | NetworkManager |
| Automation story | Ansible, cloud-init, Landscape scripts, MAAS | Ansible Automation Platform, RHEL system roles, Satellite remote execution |

The important part is not that one column is "better". It is that the operational centre of gravity moves.

> ## Old Enough to Remember When Red Hat Came in a Box
>
> One reason this comparison feels interesting to me is that I am old enough to remember Red Hat before "Enterprise Linux" was the default association.
>
> When I was at university, Red Hat Linux 5.2 was a normal Linux distribution you could install, break, reinstall, and learn from. Red Hat's own [1998 release announcement](https://www.redhat.com/ko/about/press-releases/press-redhatlinux52) described Red Hat Linux 5.2 as a boxed operating system with three CDs, an installation manual, 90 days of installation support, Apache 1.3, GIMP 1.0, and a retail price of US$49.95. That was a very different world. It was Linux as a thing you bought, borrowed, copied, installed on spare hardware, and gradually turned into a career.
>
> Then Linux grew up.
>
> Red Hat created what became Red Hat Enterprise Linux in 2002 for customers who wanted a stable, supported, certified operating system. The first RHEL 2.1 general availability date listed by Red Hat is [23 March 2002](https://access.redhat.com/articles/red-hat-enterprise-linux-release-dates). By late 2003, Red Hat had also introduced the Fedora Project as the community and early-technology track, while RHEL became the stable commercial platform. Red Hat's own explanation of the split is pretty blunt: one product could no longer meet the conflicting needs of hobbyists, developers, and enterprise customers.
>
> Ubuntu arrived just after that moment. Ubuntu 4.10, "Warty Warthog", was announced on [20 October 2004](https://lists.ubuntu.com/archives/ubuntu-announce/2004-October/000003.html) as the first Ubuntu release, with the now almost mythic offer to ship CDs at no cost. It was not officially "the anti-RHEL", and it would be too neat to pretend the history was that simple. But for a lot of Linux users, Ubuntu landed at exactly the right time: after the old Red Hat Linux line had given way to Fedora and RHEL, and when there was a real appetite for a polished, freely available, community-friendly Linux distribution that did not feel like it was asking for a procurement conversation before you could start learning.
>
> That history still echoes in 2026.
>
> IBM completed its acquisition of Red Hat in [July 2019](https://www.ibm.com/investor/news/ibm-completes-acquisition-of-red-hat), and RHEL is now firmly part of a much larger enterprise software business. On sticker price alone, the comparison can look stark. As of May 2026, Red Hat lists RHEL Server at US$383.90 for self-support, US$878.90 for standard support, and US$1,428.90 for premium support, with Satellite bundles and other add-ons priced separately. Canonical lists Ubuntu Pro at US$500 per server per year, with 24/7 support tiers at US$1,775 for infrastructure support and US$3,400 for full support.
>
> Those numbers should not be compared too lazily. Red Hat's self-support tier is not intended for production, the products are packaged differently, the support models are different, and the real enterprise bill depends on architecture, virtualisation density, public cloud consumption, support level, management tooling, discounts, and procurement agreements.
>
> But the emotional shape of the comparison is hard to miss. Ubuntu still carries some of that "just let me run Linux" energy, even when wrapped in Ubuntu Pro, Landscape, FIPS, Livepatch, and compliance tooling. Red Hat still carries the weight of the platform that large enterprises trust when they need certification, lifecycle discipline, vendor accountability, Satellite-driven content management, and a very mature operating model at scale.
>
> That is why I would not reduce this to price. Ubuntu Pro can be very compelling commercially, especially for broad fleets and teams already comfortable with Ubuntu. Red Hat is harder to beat when the question becomes: how do we run thousands of systems through a controlled content lifecycle, with certified applications, formal support paths, mature policy tooling, and a management model that auditors and operations teams can both understand?
>
> In a strange way, the old Red Hat Linux 5.2 box and the modern RHEL subscription are part of the same story. Linux went from something we installed because it was exciting to something organisations run because it is boring in exactly the right ways.

## Landscape vs Satellite

This is probably the biggest enterprise difference.

If you manage Ubuntu at scale, you may already use [Landscape](https://documentation.ubuntu.com/pro/landscape/), Canonical's systems management tool for Ubuntu machines. In 2026, Landscape is available as SaaS, self-hosted Landscape, and Managed Landscape. Canonical's own comparison is useful: SaaS gives inventory, security, compliance, hardening, and reporting, but self-hosted and managed options are where you get repository management and offline-friendly patterns.

That matters because "Landscape" is not one identical thing in every deployment. If you are used to Landscape SaaS and you move to RHEL, do not assume the Red Hat equivalent is just "a web console that shows machines". Satellite is more opinionated about content lifecycle.

[Red Hat Satellite 6.17](https://docs.redhat.com/en/documentation/red_hat_satellite/6.17/) is the classic Red Hat estate management tool. It handles host registration, content management, lifecycle environments, content views, repository synchronization, patching, provisioning, remote execution, host groups, Capsule servers, activation keys, Ansible integration, and compliance workflows.

The concepts to learn are:

- **Organization and location**: Satellite partitions management across business and infrastructure boundaries.
- **Content views**: curated sets of repositories and packages that can be promoted through lifecycle environments.
- **Lifecycle environments**: dev, test, prod, or whatever promotion path you define.
- **Activation keys**: registration profiles used to attach hosts to subscriptions, content views, environments, repository sets, and system purpose.
- **Capsule servers**: distributed Satellite components for content, provisioning, DNS, DHCP, TFTP, and remote execution closer to hosts.
- **Host groups**: repeatable host configuration and provisioning templates.
- **Remote execution**: run jobs against hosts from Satellite.
- **Ansible integration**: run roles and playbooks as part of host management.

The most important mental model is this:

**Landscape often feels like Ubuntu fleet management. Satellite feels like a content supply chain.**

Satellite wants you to think about which exact repository content a machine is entitled to see, which lifecycle stage that content is in, and how content moves from sync to test to production. Red Hat's Satellite docs describe [activation keys](https://docs.redhat.com/en/documentation/red_hat_satellite/6.17/html-single/managing_content/index#chap-Managing_Content-Managing_Activation_Keys) as a way to automate registration and associate systems with environments and content views. That is not just a convenience feature. In a real RHEL estate, activation keys become part of how you encode server purpose.

If you are coming from Ubuntu, this is where I would spend time first. Package commands can be learned in an afternoon. A bad content lifecycle design can annoy you for years.

## Package management: apt to dnf

At the daily command level, the translation is simple enough:

| Ubuntu | RHEL |
|---|---|
| `apt update` | `dnf check-update` or let `dnf` refresh metadata as needed |
| `apt install nginx` | `dnf install nginx` |
| `apt remove nginx` | `dnf remove nginx` |
| `apt purge nginx` | no direct habit match; remove package and clean config deliberately |
| `apt search nginx` | `dnf search nginx` |
| `apt show nginx` | `dnf info nginx` |
| `dpkg -l` | `rpm -qa` |
| `dpkg -S /path/file` | `rpm -qf /path/file` |
| `apt-file search /path/file` | `dnf provides /path/file` |
| `apt-mark hold package` | `dnf versionlock package` if the plugin is installed |
| `/etc/apt/sources.list.d/*.sources` | `/etc/yum.repos.d/*.repo` |

But again, the command syntax is the easy part.

Ubuntu's package model is Debian-based. The main supported base is in Main and Restricted, with Universe and Multiverse adding a large body of community-maintained software. The [Ubuntu Server package management documentation](https://documentation.ubuntu.com/server/how-to/software/package-management/) notes that Ubuntu 24.04 and later use deb822 repository files such as `/etc/apt/sources.list.d/ubuntu.sources` by default. It also points out a support boundary that matters in enterprise environments: Universe and Multiverse are not supported in the same way as the base repositories unless you have the relevant Ubuntu Pro coverage.

RHEL's package model is RPM-based. In RHEL 10, Red Hat documents the main content repositories as [BaseOS, AppStream, CodeReady Linux Builder, Supplementary, and add-on repositories](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html-single/managing_software_with_the_dnf_tool/index). BaseOS is the core operating system. AppStream contains user-space applications, runtimes, languages, and databases. CodeReady Linux Builder is available with subscriptions, but Red Hat explicitly says packages in that repository are not supported.

That is a trap for Ubuntu admins.

On Ubuntu, enabling Universe is normal. On RHEL, enabling CodeReady Linux Builder may be necessary for build dependencies or certain developer workflows, but it should not be treated as equivalent to a fully supported application source. In regulated or tightly supported environments, that distinction matters.

RHEL also has Application Streams. These provide newer or alternate user-space components while keeping the core platform stable. Red Hat's RHEL 10 docs note that Application Streams can have their own lifecycle, sometimes shorter than the RHEL major release. Before you standardise on a language runtime or database from AppStream, check its lifecycle rather than assuming it lives for the full OS lifecycle.

The other package habit to re-learn is errata.

Ubuntu admins often think in terms of package upgrades and Ubuntu Security Notices. RHEL admins think in terms of package updates, RHSA security advisories, RHBA bug advisories, RHEA enhancements, CVE severity, and whether content has been promoted into the right Satellite content view. In practice, that means your patch reporting and compliance dashboards need to change vocabulary.

## Automatic updates and patching

Ubuntu Server commonly uses unattended upgrades for security updates. The Ubuntu package management docs say the default for Ubuntu Server is to automatically apply security updates.

RHEL can automate updates too, but the habit is different. Red Hat documents [DNF Automatic](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/managing_software_with_the_dnf_tool/index) for automated software updates, including systemd timer units. In a larger Red Hat environment, however, you will often coordinate patching through Satellite, maintenance windows, content views, and job templates rather than letting every server independently pull whatever is current.

That is not just bureaucracy. It is how Red Hat environments avoid drift.

If you are moving from Ubuntu to RHEL, decide early:

- Are hosts allowed to update directly from Red Hat CDN?
- Are hosts registered to Satellite and pinned to lifecycle environments?
- Do dev, test, and prod see different content views?
- Who promotes errata into production?
- Are security updates automatically applied, automatically staged, or manually approved?
- How do you handle kernel updates and reboots?
- What is the exception path for emergency CVEs?

These questions exist on Ubuntu too, but Satellite makes them more explicit.

## Services and startup behaviour

Both Ubuntu and RHEL use systemd. That part is familiar.

The commands are the same:

```bash
systemctl status ssh
systemctl enable --now nginx
systemctl disable --now nginx
journalctl -u nginx
systemctl list-unit-files
```

The differences are in naming, packaging policy, defaults, and surrounding security controls.

Common service name changes include:

| Ubuntu habit | RHEL habit |
|---|---|
| `apache2` | `httpd` |
| `ssh` | `sshd` |
| `cron` | `crond` |
| `rsyslog` | `rsyslog` |
| `ufw` | `firewalld` |
| `apparmor` | `selinux` tooling rather than an equivalent service |

The first practical rule is to stop assuming package names and service names match your Ubuntu notes. Sometimes they do. Often they do not.

The second rule is to be explicit in automation. If a service should run, say so:

```yaml
- name: Install Apache on RHEL
  ansible.builtin.dnf:
    name: httpd
    state: present

- name: Enable and start Apache
  ansible.builtin.systemd:
    name: httpd
    enabled: true
    state: started
```

Do not rely on a package install side effect.

On Debian and Ubuntu systems, packages that provide services commonly arrange for those services to start through maintainer scripts and init integration. Debian policy says packages providing system services should arrange for those services to be automatically started and stopped by the init system or service manager. In automation, Ansible's `apt` module even has a `policy_rc_d` option for cases where you want to prevent services from starting during package installation.

On RHEL-like systems, service enablement is more tied to systemd presets and explicit service management. You should still check the specific package, but as an operational pattern, RHEL automation should install, configure, open firewall policy, set SELinux context where needed, and then enable/start the service deliberately.

One more wrinkle: Ubuntu 26.04 release notes say it is the last Ubuntu release that supports System V service script compatibility in systemd. That is a useful reminder that both ecosystems are continuing to push old init assumptions out of the way. If your internal apps still ship ancient init scripts, now is a good time to turn them into proper unit files.

## AppArmor vs SELinux

This is the difference that will hurt most if you ignore it.

Ubuntu uses AppArmor by default. Canonical's [Ubuntu Server AppArmor documentation](https://documentation.ubuntu.com/server/how-to/security/apparmor/) describes AppArmor as a Mandatory Access Control system that restricts application capabilities with per-program profiles. It is installed and loaded by default on Ubuntu, profiles live in `/etc/apparmor.d/`, and profiles can run in complain or enforce mode.

RHEL uses SELinux by default. Red Hat's [RHEL 10 SELinux documentation](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html-single/using_selinux/index) describes SELinux as a Mandatory Access Control implementation where policy defines how users and processes interact with files and devices. RHEL installs with SELinux in enforcing mode by default.

The practical difference:

- AppArmor is profile and path oriented.
- SELinux is label, type, role, and policy oriented.

That difference changes troubleshooting.

On Ubuntu, if an application cannot read `/srv/app/config.yaml`, you might inspect AppArmor logs and adjust the application profile to allow that path.

On RHEL, if `httpd` cannot read `/srv/app/index.html`, the Unix permissions may be correct and the process may still be denied because the file has the wrong SELinux context. The fix is not `chmod 777`. The fix is more likely:

```bash
semanage fcontext -a -t httpd_sys_content_t '/srv/app(/.*)?'
restorecon -Rv /srv/app
```

Or if you move a service to a non-standard port:

```bash
semanage port -a -t http_port_t -p tcp 8080
```

The mindset shift is this:

**On RHEL, "root can read it" does not mean "the service domain can read it".**

That is a good thing. It is also the source of many bad first weeks for Ubuntu admins new to RHEL.

Useful commands to learn early:

```bash
getenforce
sestatus
ls -Z
ps -eZ
ausearch -m AVC,USER_AVC -ts recent
sealert -a /var/log/audit/audit.log
semanage fcontext -l
restorecon -Rv /some/path
setsebool -P httpd_can_network_connect on
```

The worst possible migration pattern is disabling SELinux because it blocked a workload during testing. That usually means the test found a real policy mismatch, mislabeled file, unsupported application layout, or missing boolean. Fix that before production.

AppArmor can be simpler to reason about for application-specific path access. SELinux can be harder at first, but it is deeply integrated into the RHEL security model, service policy, container story, and compliance expectations. In Red Hat environments, SELinux is not an optional hardening extra. Treat it as part of the platform.

## Ansible support and automation

Ansible remains one of the easiest bridges between Ubuntu and RHEL.

The same control node can manage both families. The same inventory can group both. The same playbook can branch on facts:

```yaml
- name: Install web server package
  ansible.builtin.package:
    name: "{{ 'apache2' if ansible_os_family == 'Debian' else 'httpd' }}"
    state: present
```

For truly generic work, `ansible.builtin.package`, `ansible.builtin.service`, `ansible.builtin.systemd`, `ansible.builtin.copy`, and `ansible.builtin.template` keep your playbooks portable.

But enterprise automation usually needs OS-family-specific roles. Package names differ, config paths differ, SELinux exists on one side, AppArmor on the other, firewall tooling differs, and repository management is completely different.

The Red Hat-specific automation story is strong. RHEL 10 includes `ansible-core` 2.16, and Red Hat documents [RHEL system roles](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/automating_system_administration_by_using_rhel_system_roles/index/) as a supported way to automate repeatable administration tasks. These roles cover areas such as networking, storage, SELinux, firewalld, crypto policies, journald, SSH, timesync, Podman, kernel settings, and systemd.

That is worth using.

If you are migrating from Ubuntu, do not immediately port every internal role line-for-line. First check whether RHEL system roles already cover the boring-but-dangerous base configuration. Boring infrastructure should be boring on purpose.

Satellite also integrates with Ansible. Red Hat Satellite 6.17 documentation includes [Ansible integration](https://docs.redhat.com/en/documentation/red_hat_satellite/6.17/html/managing_configurations_by_using_ansible_integration/Getting_Started_with_Ansible_in_satellite_ansible), and Satellite can run roles during registration and remote execution workflows.

The practical migration pattern I like is:

1. Keep application deployment roles mostly portable.
2. Split OS baseline roles by family.
3. Use RHEL system roles for RHEL platform configuration where possible.
4. Use Satellite for registration, content lifecycle, host groups, remote jobs, and compliance visibility.
5. Use Ansible Automation Platform if you need enterprise workflow, RBAC, controller features, certified content, and support.

The anti-pattern is pretending RHEL is "Ubuntu with dnf". That leads to fragile roles full of conditionals and small exceptions.

## Autoinstall vs Kickstart

Ubuntu's automated installer is Subiquity Autoinstall. Red Hat's automated installer is Kickstart.

They solve the same problem: install the OS without clicking through screens.

They do not feel the same.

Ubuntu Autoinstall uses YAML. The [Autoinstall reference](https://canonical-subiquity.readthedocs-hosted.com/en/latest/reference/autoinstall-reference.html) uses a top-level `autoinstall` key, currently with `version: 1`. It can configure identity, locale, keyboard, networking, proxy, apt mirrors, storage, snaps, packages, SSH, drivers, user-data, early commands, late commands, and interactive sections.

A tiny Ubuntu example looks like this:

```yaml
#cloud-config
autoinstall:
  version: 1
  identity:
    hostname: ubuntu-server
    username: ubuntu
    password: "$6$..."
  ssh:
    install-server: true
  storage:
    layout:
      name: lvm
  apt:
    mirror-selection:
      primary:
        - uri: "http://mirror.internal/ubuntu"
```

Subiquity can consume this through cloud-init style delivery such as NoCloud. The [quick start](https://canonical-subiquity.readthedocs-hosted.com/en/latest/howto/autoinstall-quickstart.html) shows the familiar `autoinstall ds=nocloud-net;s=http://.../` boot parameter pattern.

Red Hat Kickstart is older, more established in enterprise bare-metal provisioning, and tightly associated with Anaconda and Satellite. Red Hat's [RHEL 10 automatic installation documentation](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/automatically_installing_rhel/index) describes Kickstart as a way to deploy RHEL from a predefined configuration. Kickstart files contain commands and sections such as `%packages`, `%pre`, `%post`, repository definitions, network configuration, storage layout, timezone, users, firewall, SELinux, and service enablement.

A tiny RHEL example looks more like this:

```kickstart
lang en_US.UTF-8
keyboard us
timezone Australia/Sydney --utc
network --bootproto=dhcp --device=link --activate
rootpw --iscrypted $6$...
selinux --enforcing
firewall --enabled --service=ssh
services --enabled=sshd,chronyd
url --url=http://mirror.internal/rhel/10/BaseOS/x86_64/os/

%packages
@^minimal-environment
chrony
%end

%post
subscription-manager register --activationkey=rhel-prod --org=my-org
%end
```

With Satellite, Kickstart becomes part of a larger provisioning model. Satellite host groups, provisioning templates, activation keys, content views, lifecycle environments, DNS, DHCP, TFTP, HTTP boot, and Capsule placement can all become part of the install path. Red Hat's Satellite content docs note that Kickstart provisioning templates can register hosts with activation keys.

There is also an interesting Ubuntu development here. Canonical documents that [Landscape server 25.10 and later can serve Autoinstall files](https://documentation.ubuntu.com/landscape/how-to-guides/ubuntu-installer/set-up-autoinstall-provisioning/) to the Ubuntu installer for Ubuntu 26.04 and later, but only for self-hosted deployments and with OIDC requirements. That brings Landscape closer to the provisioning workflow, but Satellite is still the more mature all-in-one RHEL provisioning control plane.

When migrating, do not try to mechanically convert Autoinstall YAML to Kickstart. Re-design the install pipeline:

- How will systems boot: ISO, PXE, UEFI HTTP boot, virtual media, cloud image, image builder?
- Where does install media come from: Red Hat CDN, Satellite, local mirror, custom ISO?
- How will systems register: subscription-manager, activation key, Satellite global registration?
- Which repositories are available at install time?
- Which content view does the host land in?
- How is storage expressed?
- What happens in `%post`, and what should move into Ansible instead?
- How are secrets passed safely?

Kickstart is powerful, but `%post` can become a junk drawer. Keep the installer responsible for installing and registering the machine. Let Ansible or Satellite handle the rest.

## Firewalls and networking

This is not always the first thing people ask about, but it is one of the first things they trip over.

Ubuntu Server documentation describes [Netplan](https://documentation.ubuntu.com/server/explanation/networking/about-netplan) as the way network configuration is handled on Ubuntu. Netplan gives you YAML, then renders to NetworkManager or systemd-networkd depending on the system.

RHEL uses NetworkManager directly as the normal server networking layer. The modern command-line habit is `nmcli`, NetworkManager connection profiles, and keyfile-backed configuration. If your Ubuntu automation writes Netplan YAML, that code does not move across directly.

Firewall defaults also differ.

Ubuntu's server docs describe [ufw](https://documentation.ubuntu.com/server/how-to/security/firewalls/) as the default firewall configuration tool for Ubuntu. It is simple and friendly for host-based rules, though many enterprises still manage nftables, cloud security groups, or external firewalls directly.

RHEL's firewall documentation focuses on [firewalld and nftables](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html-single/configuring_firewalls_and_packet_filters/index). `firewalld` uses zones, services, runtime configuration, and permanent configuration. That runtime/permanent split is worth learning immediately:

```bash
firewall-cmd --add-service=http
firewall-cmd --add-service=http --permanent
firewall-cmd --reload
```

If you only make a runtime change, it disappears later. If you only make a permanent change and do not reload, it may not affect the current running firewall. That is an easy mistake to make when you are used to `ufw allow 80`.

Also remember that on RHEL, a service can be installed, configured, and running, while still blocked by firewalld and/or SELinux. Troubleshooting needs to check all layers:

```bash
systemctl status httpd
ss -ltnp
firewall-cmd --list-all
getenforce
ausearch -m AVC -ts recent
```

## Security and compliance posture

Both vendors have serious enterprise security stories, but they package the experience differently.

Ubuntu Pro adds ESM, Livepatch, FIPS packages, compliance profiles, Landscape, and support options. Ubuntu 26.04 also has a noticeable security push around memory-safe system components, TPM-backed full-disk encryption, and improved application permission prompting.

RHEL's security story is built around SELinux, crypto policies, FIPS workflows, OpenSCAP, system roles, Satellite compliance, Insights or Lightspeed recommendations, certified content, Common Criteria and government/compliance expectations, and a very formal support boundary.

For an Ubuntu-to-RHEL migration, the highest-impact differences are:

- **SELinux is expected to stay enforcing.**
- **System-wide crypto policies matter.**
- **FIPS enablement needs to be planned before workloads are deployed.**
- **Compliance content is often tied into Satellite, OpenSCAP, and Red Hat tooling.**
- **Third-party repositories are a bigger governance issue than they may have been in an Ubuntu estate.**
- **Supportability depends heavily on staying inside Red Hat's packaging and configuration boundaries.**

In other words, RHEL rewards discipline. It can feel slower at first, but the point is repeatability, auditability, and vendor-supported state.

## Things that will catch Ubuntu admins

Here is the checklist I would pin near the terminal for the first month.

### Package and repository traps

- `yum` is mostly muscle memory now. Use `dnf`.
- Do not treat CodeReady Linux Builder like Ubuntu Universe.
- Check AppStream lifecycle before standardising on runtimes.
- Learn `rpm -qf`, `dnf provides`, `dnf history`, and `dnf repoquery`.
- Expect `/etc/yum.repos.d/redhat.repo` to be managed through subscription/Satellite tooling.
- Do not casually add random `.repo` files to production servers.

### Service traps

- `apache2` is `httpd`.
- `ssh` is usually `sshd`.
- `cron` is usually `crond`.
- Be explicit with `systemctl enable --now`.
- Check firewalld if a service is listening but unreachable.
- Check SELinux if permissions look correct but the app still cannot access something.

### Security traps

- Do not disable SELinux to "fix" an app.
- Learn `ls -Z` as early as you learned `ls -l`.
- File labels matter as much as file modes.
- Ports have SELinux types too.
- Container bind mounts may need SELinux relabel options.

### Automation traps

- Split Debian-family and Red Hat-family baseline roles.
- Use `ansible_os_family` carefully.
- Prefer RHEL system roles where they fit.
- Replace `ufw` tasks with `firewalld` tasks.
- Replace Netplan rendering with NetworkManager profile management.
- Keep Kickstart small and move application configuration into Ansible.

### Management traps

- Satellite content views are not just folders.
- Activation keys are not just registration tokens.
- Lifecycle environments should match your patch promotion model.
- Capsule placement matters for remote sites and disconnected environments.
- Decide whether Red Hat CDN access is allowed directly or only through Satellite.

## A sensible migration approach

I would not start by converting every server.

I would start by building a small RHEL operating model:

1. Pick the supported RHEL major and minor strategy.
2. Define how hosts register: Red Hat CDN, Satellite, activation keys, or cloud marketplace entitlement.
3. Build content views and lifecycle environments before production hosts exist.
4. Create a minimal Kickstart that installs, registers, and hands off to automation.
5. Create RHEL baseline Ansible roles for users, SSH, time sync, logging, firewall, SELinux, monitoring, and backup agents.
6. Port one low-risk application.
7. Keep SELinux enforcing and fix every denial properly.
8. Document package and service name translations.
9. Add patch reporting and errata reporting before the first production maintenance window.
10. Train the team on `dnf`, `rpm`, `subscription-manager`, `firewall-cmd`, `semanage`, `restorecon`, `ausearch`, and Satellite basics.

The goal is not to make RHEL behave like Ubuntu. The goal is to understand the Red Hat way well enough that the platform becomes boring.

That is where RHEL shines. It is not exciting because `dnf install` is more interesting than `apt install`. It is useful because the management, content, security, and support model can become very predictable when you lean into it.

## Final thoughts

Ubuntu and Red Hat Enterprise Linux are both excellent enterprise Linux platforms.

Ubuntu often feels faster to get moving with. The package universe is huge, the community is broad, cloud images are everywhere, and the Debian-style workflow is familiar to a lot of infrastructure teams.

RHEL often feels more deliberate. The supported content boundaries are clearer, SELinux is central, Satellite gives you a strong content lifecycle model, and Red Hat's ecosystem is built for organisations that care deeply about vendor support, compliance, and repeatable operations.

If you are switching from Ubuntu to RHEL, the hard part is not the shell. It is the operating model.

Learn Satellite properly. Respect SELinux. Treat repositories as a governed supply chain. Rewrite your installer automation instead of translating it line by line. Use Ansible, but do not pretend OS families are identical. Be explicit about services, firewall policy, content lifecycle, and support boundaries.

Once those pieces click, RHEL starts to feel less like a different distro and more like a different contract with production.

That is the real migration.

## Further reading

- [Ubuntu 26.04 LTS release notes](https://documentation.ubuntu.com/release-notes/26.04/)
- [Ubuntu release cycle](https://ubuntu.com/about/release-cycle)
- [Ubuntu Server package management](https://documentation.ubuntu.com/server/how-to/software/package-management/)
- [Ubuntu AppArmor documentation](https://documentation.ubuntu.com/server/how-to/security/apparmor/)
- [Ubuntu Autoinstall reference](https://canonical-subiquity.readthedocs-hosted.com/en/latest/reference/autoinstall-reference.html)
- [Landscape documentation](https://documentation.ubuntu.com/pro/landscape/)
- [Red Hat Enterprise Linux 10 announcement](https://www.redhat.com/en/about/press-releases/red-hat-introduces-rhel-10)
- [Red Hat Enterprise Linux lifecycle](https://access.redhat.com/support/policy/updates/errata/)
- [RHEL 10 DNF documentation](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html-single/managing_software_with_the_dnf_tool/index)
- [RHEL 10 SELinux documentation](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html-single/using_selinux/index)
- [RHEL 10 Kickstart documentation](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/automatically_installing_rhel/index)
- [Red Hat Satellite 6.17 documentation](https://docs.redhat.com/en/documentation/red_hat_satellite/6.17/)
- [RHEL system roles documentation](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/automating_system_administration_by_using_rhel_system_roles/index/)