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."
8---
9
10# The Real Differences Between Ubuntu and Red Hat Enterprise Linux in 2026
11
12Moving from an Ubuntu shop to a Red Hat shop is not really a move from "Linux" to "Linux".
13
14At 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.
15
16The real shift is the enterprise operating model around the distribution.
17
18Ubuntu 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.
19
20In 2026, that difference matters more than the old "apt vs yum" muscle memory.
21
22The 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.
23
24This is the practical comparison I would want in front of me before moving from Ubuntu to RHEL.
25
26## The short version
27
28If you already manage Ubuntu well, you are not starting again.
29
30But you do need to re-learn a few habits:
31
32- Landscape becomes Satellite, or at least Red Hat Satellite plus Red Hat Hybrid Cloud Console and Lightspeed.
33- `apt` and `dpkg` become `dnf` and `rpm`.
34- Ubuntu repository categories become RHEL repositories such as BaseOS, AppStream, CodeReady Linux Builder, Supplementary, and add-on repositories.
35- AppArmor muscle memory becomes SELinux muscle memory.
36- Ubuntu Autoinstall becomes Kickstart.
37- `ufw` often becomes `firewalld`.
38- Netplan habits often become NetworkManager profile habits.
39- Package names change, service names change, and some old assumptions about packages starting services need to be checked.
40- 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.
41
42That 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.
43
44Ubuntu 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.
45
46## Baseline assumptions in 2026
47
48For 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.
49
50Ubuntu'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.
51
52For 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.
53
54The high-level difference:
55
56| Area | Ubuntu LTS | Red Hat Enterprise Linux |
57|---|---|---|
58| Current enterprise baseline | Ubuntu 26.04 LTS | RHEL 10 |
59| Commercial vendor | Canonical | Red Hat |
60| Primary package format | `.deb` | `.rpm` |
61| Primary package tool | `apt` | `dnf` |
62| Fleet management | Landscape | Satellite, Hybrid Cloud Console, Lightspeed |
63| Default MAC system | AppArmor | SELinux |
64| Automated install | Subiquity Autoinstall | Anaconda Kickstart |
65| Firewall habit | `ufw`, raw nftables/iptables where needed | `firewalld`, nftables where needed |
66| Networking habit | Netplan rendering to NetworkManager or systemd-networkd | NetworkManager |
67| Automation story | Ansible, cloud-init, Landscape scripts, MAAS | Ansible Automation Platform, RHEL system roles, Satellite remote execution |
68
69The important part is not that one column is "better". It is that the operational centre of gravity moves.
70
71## Landscape vs Satellite
72
73This is probably the biggest enterprise difference.
74
75If 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.
76
77That 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.
78
79[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.
80
81The concepts to learn are:
82
83- **Organization and location**: Satellite partitions management across business and infrastructure boundaries.
84- **Content views**: curated sets of repositories and packages that can be promoted through lifecycle environments.
85- **Lifecycle environments**: dev, test, prod, or whatever promotion path you define.
86- **Activation keys**: registration profiles used to attach hosts to subscriptions, content views, environments, repository sets, and system purpose.
87- **Capsule servers**: distributed Satellite components for content, provisioning, DNS, DHCP, TFTP, and remote execution closer to hosts.
88- **Host groups**: repeatable host configuration and provisioning templates.
89- **Remote execution**: run jobs against hosts from Satellite.
90- **Ansible integration**: run roles and playbooks as part of host management.
91
92The most important mental model is this:
93
94**Landscape often feels like Ubuntu fleet management. Satellite feels like a content supply chain.**
95
96Satellite 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.
97
98If 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.
99
100## Package management: apt to dnf
101
102At the daily command level, the translation is simple enough:
103
104| Ubuntu | RHEL |
105|---|---|
106| `apt update` | `dnf check-update` or let `dnf` refresh metadata as needed |
107| `apt install nginx` | `dnf install nginx` |
108| `apt remove nginx` | `dnf remove nginx` |
109| `apt purge nginx` | no direct habit match; remove package and clean config deliberately |
110| `apt search nginx` | `dnf search nginx` |
111| `apt show nginx` | `dnf info nginx` |
112| `dpkg -l` | `rpm -qa` |
113| `dpkg -S /path/file` | `rpm -qf /path/file` |
114| `apt-file search /path/file` | `dnf provides /path/file` |
115| `apt-mark hold package` | `dnf versionlock package` if the plugin is installed |
116| `/etc/apt/sources.list.d/*.sources` | `/etc/yum.repos.d/*.repo` |
117
118But again, the command syntax is the easy part.
119
120Ubuntu'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.
121
122RHEL'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.
123
124That is a trap for Ubuntu admins.
125
126On 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.
127
128RHEL 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.
129
130The other package habit to re-learn is errata.
131
132Ubuntu 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.
133
134## Automatic updates and patching
135
136Ubuntu 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.
137
138RHEL 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.
139
140That is not just bureaucracy. It is how Red Hat environments avoid drift.
141
142If you are moving from Ubuntu to RHEL, decide early:
143
144- Are hosts allowed to update directly from Red Hat CDN?
145- Are hosts registered to Satellite and pinned to lifecycle environments?
146- Do dev, test, and prod see different content views?
147- Who promotes errata into production?
148- Are security updates automatically applied, automatically staged, or manually approved?
149- How do you handle kernel updates and reboots?
150- What is the exception path for emergency CVEs?
151
152These questions exist on Ubuntu too, but Satellite makes them more explicit.
153
154## Services and startup behaviour
155
156Both Ubuntu and RHEL use systemd. That part is familiar.
157
158The commands are the same:
159
160```bash
161systemctl status ssh
162systemctl enable --now nginx
163systemctl disable --now nginx
164journalctl -u nginx
165systemctl list-unit-files
166```
167
168The differences are in naming, packaging policy, defaults, and surrounding security controls.
169
170Common service name changes include:
171
172| Ubuntu habit | RHEL habit |
173|---|---|
174| `apache2` | `httpd` |
175| `ssh` | `sshd` |
176| `cron` | `crond` |
177| `rsyslog` | `rsyslog` |
178| `ufw` | `firewalld` |
179| `apparmor` | `selinux` tooling rather than an equivalent service |
180
181The first practical rule is to stop assuming package names and service names match your Ubuntu notes. Sometimes they do. Often they do not.
182
183The second rule is to be explicit in automation. If a service should run, say so:
184
185```yaml
186- name: Install Apache on RHEL
187  ansible.builtin.dnf:
188    name: httpd
189    state: present
190
191- name: Enable and start Apache
192  ansible.builtin.systemd:
193    name: httpd
194    enabled: true
195    state: started
196```
197
198Do not rely on a package install side effect.
199
200On 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.
201
202On 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.
203
204One 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.
205
206## AppArmor vs SELinux
207
208This is the difference that will hurt most if you ignore it.
209
210Ubuntu 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.
211
212RHEL 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.
213
214The practical difference:
215
216- AppArmor is profile and path oriented.
217- SELinux is label, type, role, and policy oriented.
218
219That difference changes troubleshooting.
220
221On Ubuntu, if an application cannot read `/srv/app/config.yaml`, you might inspect AppArmor logs and adjust the application profile to allow that path.
222
223On 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:
224
225```bash
226semanage fcontext -a -t httpd_sys_content_t '/srv/app(/.*)?'
227restorecon -Rv /srv/app
228```
229
230Or if you move a service to a non-standard port:
231
232```bash
233semanage port -a -t http_port_t -p tcp 8080
234```
235
236The mindset shift is this:
237
238**On RHEL, "root can read it" does not mean "the service domain can read it".**
239
240That is a good thing. It is also the source of many bad first weeks for Ubuntu admins new to RHEL.
241
242Useful commands to learn early:
243
244```bash
245getenforce
246sestatus
247ls -Z
248ps -eZ
249ausearch -m AVC,USER_AVC -ts recent
250sealert -a /var/log/audit/audit.log
251semanage fcontext -l
252restorecon -Rv /some/path
253setsebool -P httpd_can_network_connect on
254```
255
256The 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.
257
258AppArmor 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.
259
260## Ansible support and automation
261
262Ansible remains one of the easiest bridges between Ubuntu and RHEL.
263
264The same control node can manage both families. The same inventory can group both. The same playbook can branch on facts:
265
266```yaml
267- name: Install web server package
268  ansible.builtin.package:
269    name: "{{ 'apache2' if ansible_os_family == 'Debian' else 'httpd' }}"
270    state: present
271```
272
273For truly generic work, `ansible.builtin.package`, `ansible.builtin.service`, `ansible.builtin.systemd`, `ansible.builtin.copy`, and `ansible.builtin.template` keep your playbooks portable.
274
275But 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.
276
277The 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.
278
279That is worth using.
280
281If 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.
282
283Satellite 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.
284
285The practical migration pattern I like is:
286
2871. Keep application deployment roles mostly portable.
2882. Split OS baseline roles by family.
2893. Use RHEL system roles for RHEL platform configuration where possible.
2904. Use Satellite for registration, content lifecycle, host groups, remote jobs, and compliance visibility.
2915. Use Ansible Automation Platform if you need enterprise workflow, RBAC, controller features, certified content, and support.
292
293The anti-pattern is pretending RHEL is "Ubuntu with dnf". That leads to fragile roles full of conditionals and small exceptions.
294
295## Autoinstall vs Kickstart
296
297Ubuntu's automated installer is Subiquity Autoinstall. Red Hat's automated installer is Kickstart.
298
299They solve the same problem: install the OS without clicking through screens.
300
301They do not feel the same.
302
303Ubuntu 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.
304
305A tiny Ubuntu example looks like this:
306
307```yaml
308#cloud-config
309autoinstall:
310  version: 1
311  identity:
312    hostname: ubuntu-server
313    username: ubuntu
314    password: "$6$..."
315  ssh:
316    install-server: true
317  storage:
318    layout:
319      name: lvm
320  apt:
321    mirror-selection:
322      primary:
323        - uri: "http://mirror.internal/ubuntu"
324```
325
326Subiquity 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.
327
328Red 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.
329
330A tiny RHEL example looks more like this:
331
332```kickstart
333lang en_US.UTF-8
334keyboard us
335timezone Australia/Sydney --utc
336network --bootproto=dhcp --device=link --activate
337rootpw --iscrypted $6$...
338selinux --enforcing
339firewall --enabled --service=ssh
340services --enabled=sshd,chronyd
341url --url=http://mirror.internal/rhel/10/BaseOS/x86_64/os/
342
343%packages
344@^minimal-environment
345chrony
346%end
347
348%post
349subscription-manager register --activationkey=rhel-prod --org=my-org
350%end
351```
352
353With 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.
354
355There 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.
356
357When migrating, do not try to mechanically convert Autoinstall YAML to Kickstart. Re-design the install pipeline:
358
359- How will systems boot: ISO, PXE, UEFI HTTP boot, virtual media, cloud image, image builder?
360- Where does install media come from: Red Hat CDN, Satellite, local mirror, custom ISO?
361- How will systems register: subscription-manager, activation key, Satellite global registration?
362- Which repositories are available at install time?
363- Which content view does the host land in?
364- How is storage expressed?
365- What happens in `%post`, and what should move into Ansible instead?
366- How are secrets passed safely?
367
368Kickstart 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.
369
370## Firewalls and networking
371
372This is not always the first thing people ask about, but it is one of the first things they trip over.
373
374Ubuntu 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.
375
376RHEL 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.
377
378Firewall defaults also differ.
379
380Ubuntu'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.
381
382RHEL'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:
383
384```bash
385firewall-cmd --add-service=http
386firewall-cmd --add-service=http --permanent
387firewall-cmd --reload
388```
389
390If 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`.
391
392Also 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:
393
394```bash
395systemctl status httpd
396ss -ltnp
397firewall-cmd --list-all
398getenforce
399ausearch -m AVC -ts recent
400```
401
402## Security and compliance posture
403
404Both vendors have serious enterprise security stories, but they package the experience differently.
405
406Ubuntu 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.
407
408RHEL'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.
409
410For an Ubuntu-to-RHEL migration, the highest-impact differences are:
411
412- **SELinux is expected to stay enforcing.**
413- **System-wide crypto policies matter.**
414- **FIPS enablement needs to be planned before workloads are deployed.**
415- **Compliance content is often tied into Satellite, OpenSCAP, and Red Hat tooling.**
416- **Third-party repositories are a bigger governance issue than they may have been in an Ubuntu estate.**
417- **Supportability depends heavily on staying inside Red Hat's packaging and configuration boundaries.**
418
419In other words, RHEL rewards discipline. It can feel slower at first, but the point is repeatability, auditability, and vendor-supported state.
420
421## Things that will catch Ubuntu admins
422
423Here is the checklist I would pin near the terminal for the first month.
424
425### Package and repository traps
426
427- `yum` is mostly muscle memory now. Use `dnf`.
428- Do not treat CodeReady Linux Builder like Ubuntu Universe.
429- Check AppStream lifecycle before standardising on runtimes.
430- Learn `rpm -qf`, `dnf provides`, `dnf history`, and `dnf repoquery`.
431- Expect `/etc/yum.repos.d/redhat.repo` to be managed through subscription/Satellite tooling.
432- Do not casually add random `.repo` files to production servers.
433
434### Service traps
435
436- `apache2` is `httpd`.
437- `ssh` is usually `sshd`.
438- `cron` is usually `crond`.
439- Be explicit with `systemctl enable --now`.
440- Check firewalld if a service is listening but unreachable.
441- Check SELinux if permissions look correct but the app still cannot access something.
442
443### Security traps
444
445- Do not disable SELinux to "fix" an app.
446- Learn `ls -Z` as early as you learned `ls -l`.
447- File labels matter as much as file modes.
448- Ports have SELinux types too.
449- Container bind mounts may need SELinux relabel options.
450
451### Automation traps
452
453- Split Debian-family and Red Hat-family baseline roles.
454- Use `ansible_os_family` carefully.
455- Prefer RHEL system roles where they fit.
456- Replace `ufw` tasks with `firewalld` tasks.
457- Replace Netplan rendering with NetworkManager profile management.
458- Keep Kickstart small and move application configuration into Ansible.
459
460### Management traps
461
462- Satellite content views are not just folders.
463- Activation keys are not just registration tokens.
464- Lifecycle environments should match your patch promotion model.
465- Capsule placement matters for remote sites and disconnected environments.
466- Decide whether Red Hat CDN access is allowed directly or only through Satellite.
467
468## A sensible migration approach
469
470I would not start by converting every server.
471
472I would start by building a small RHEL operating model:
473
4741. Pick the supported RHEL major and minor strategy.
4752. Define how hosts register: Red Hat CDN, Satellite, activation keys, or cloud marketplace entitlement.
4763. Build content views and lifecycle environments before production hosts exist.
4774. Create a minimal Kickstart that installs, registers, and hands off to automation.
4785. Create RHEL baseline Ansible roles for users, SSH, time sync, logging, firewall, SELinux, monitoring, and backup agents.
4796. Port one low-risk application.
4807. Keep SELinux enforcing and fix every denial properly.
4818. Document package and service name translations.
4829. Add patch reporting and errata reporting before the first production maintenance window.
48310. Train the team on `dnf`, `rpm`, `subscription-manager`, `firewall-cmd`, `semanage`, `restorecon`, `ausearch`, and Satellite basics.
484
485The 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.
486
487That 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.
488
489## Final thoughts
490
491Ubuntu and Red Hat Enterprise Linux are both excellent enterprise Linux platforms.
492
493Ubuntu 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.
494
495RHEL 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.
496
497If you are switching from Ubuntu to RHEL, the hard part is not the shell. It is the operating model.
498
499Learn 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.
500
501Once those pieces click, RHEL starts to feel less like a different distro and more like a different contract with production.
502
503That is the real migration.
504
505## Further reading
506
507- [Ubuntu 26.04 LTS release notes](https://documentation.ubuntu.com/release-notes/26.04/)
508- [Ubuntu release cycle](https://ubuntu.com/about/release-cycle)
509- [Ubuntu Server package management](https://documentation.ubuntu.com/server/how-to/software/package-management/)
510- [Ubuntu AppArmor documentation](https://documentation.ubuntu.com/server/how-to/security/apparmor/)
511- [Ubuntu Autoinstall reference](https://canonical-subiquity.readthedocs-hosted.com/en/latest/reference/autoinstall-reference.html)
512- [Landscape documentation](https://documentation.ubuntu.com/pro/landscape/)
513- [Red Hat Enterprise Linux 10 announcement](https://www.redhat.com/en/about/press-releases/red-hat-introduces-rhel-10)
514- [Red Hat Enterprise Linux lifecycle](https://access.redhat.com/support/policy/updates/errata/)
515- [RHEL 10 DNF documentation](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html-single/managing_software_with_the_dnf_tool/index)
516- [RHEL 10 SELinux documentation](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html-single/using_selinux/index)
517- [RHEL 10 Kickstart documentation](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/automatically_installing_rhel/index)
518- [Red Hat Satellite 6.17 documentation](https://docs.redhat.com/en/documentation/red_hat_satellite/6.17/)
519- [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/)
520

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

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

## 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/)