As a bit of a self taught sysadmin who only touches Ubuntu/Debian based systems due there ubiquity, could someone explain the benefits of using RHEL?
As an example, I wanted to set up kerberos. Red Hat had a guide on setting up IdM, covering every step in the process, often with two alternates depending on desired final state and having an intro paragraph to choose between them, full command line docs for every command ran, steps to test this was ran correctly, and troubleshooting steps for commonly-encountered errors. In contrast, the Ubuntu docs for setting up a IdM client were a wiki, half of which was for the old version, and a detailed stackoverflow response. Server and client setups took the same amount of time; the client should have been much faster.
I would at least say it is more consistent, without having a split between the man and info commands.
2. First-class support for systemd. Well, I'm not sure that's a fair point.. But with Debian I'm always seeing some messages about sysv scripts, even when I'm using systemctl. It feels like some scripts were not fully ported to systemd or something like that. Some people don't like systemd, but I, personally, think that it's a good solution. AFAIK systemd development is sponsored by Redhat and its support is very good, all services are shipped with proper systemd units.
3. First-class support for NetworkManager, Firewalld. I think that those packages are available for Debian, but it's nice to have them installed and configured from the start, they're very convenient to use.
4. Documentation. Most of that documentation is hidden behind loginwall, but http://access.redhat.com/ contains plenty of information.
There are some drawbacks of RHEL. The major one for me is limited software selection. You need to enable EPEL even for some basic software like Strongswan, Certbot or OpenDKIM. And EPEL is not RHEL (although it's quite good).
For anyone who might be interested in Fedora-family, namely systemd, SELinux, and firewalld bits I am writing a book now about deploying with Fedora and CentOS Stream[0] and I am almost finished. With this announcement I might add RHEL support directly - the difference is just in running a subscription manager.
Also, if you are using Vagrant, you can use RHEL with a vagrant-registration plugin that automatically subscribe you (disclaimer: I made the plugin when working for Red Hat and packaging Vagrant for Fedora).
This is changing with CentOS Stream. Bugs can be filed against CentOS Stream in the Red Hat Bugzilla and they will do something with that bug report. Additionally, if you know what to backport to fix it, you can submit pull requests on any package in CentOS Stream to have it reviewed and merged to fix your issue. The fix would then be built and released within days of merging your fix.
From my perspective, that's pretty golden for an Enterprise Linux platform. The only other that's like that is openSUSE Leap/SUSE Linux Enterprise.
To summarize, the RHEL model of releasing an OS every 5 years with these staggered upstreams is really not that great. It creates immense inertia and pain down the road. RedHat itself hasn't been able to port its own offerings like Satellite to RHEL 8. I would rather have the Ubuntu cadence of LTS releases every 2 years so that you are at most 2 years away from any fixes you need.
Matthew Miller (@mattdm) tweeted out the "Fedora->RHEL formula": https://twitter.com/mattdm/status/1349037318200561665
Last workplace had a storage array. Tested on Red Hat, supported on Red Hat. The same is true for lots of other things. Enterprise databases, drivers for hardware, CAD software, that sort of stuff.
Once you have it in place, you are guaranteed not to have to change it a decade. All security fixes is backported. They also vet upstream changes to minimize nasty surprises. You do pay handsomely for the privilege.
Additionally the length of support, Ubuntu LTS gets close but RHEL will sell you support FOREVER.
A question is whether that is truly positive. A long cycle means that each update becomes a project in itself disrupting whatever else you are doing. (After 10 years so many things changed everywhere, that you need to bring so many things together ...) With frequent updates it is part of the ongoing process.
(And yes, there are cases for which one can make an argument)
Looking at Red Hat's customer list, most of them are based in finance, transportation, retail, hotel, and other such sectors.
Looking at Debian's statistics of use per sector, the plurality is companies that develop computer software, though retail comes second, but after that it's i.t. again.
This is primarily the difference and the gap that RHEL attempts to bridge through it's extensive inclusive support, which is what one is really paying for. The target of RHEL has never been i.t. companies.
- Installing a package on RH is always non-interactive. To install packages reliably on Ubuntu, we had to set three separate "Please just install the package, don't try to ask questions" options for different layers of the stack, and still occasionally ran into buggy packages that would hang the installation waiting for a nonexistent user to type something.
- On RH, when I try to install or upgrade an RPM that's missing dependencies, it gives me an error and refuses to break my system unless I specify --force. With debian, there's no way to query "Are the dependencies for this .deb satisfied" that I could ever find, and "dpkg -i foo.deb" will instead leave it "half-installed", and your package database is broken until you manually fix it.
- I really missed an equivalent of `rpm -V` (list files in an installed RPM that have been modified since installation). Asking Google now, I see that there's `debsums` which can handle some of this; I don't recall whether I failed to find that before, or if there was some other reason I didn't use it at the time.
- On RH, automated installation with kickstart is fantastic and comprehensive. It's well-documented, and has just worked for every configuration I've thrown at it. Debian's preseed is severely under-documented, and many combinations of features are just unimplemented and silently didn't work. For example, you can reserve unallocated disk space from a raw partition, but that's ignored for LVM, so to keep space free for snapshots in my volume group, I had to configure a "delete_me" volume, and then later delete it.
- Red Hat's SELinux support is fantastic. Ubuntu's choice of apparmor and deficient SELinux support has been annoying.
- I've personally found Red Hat's packages to be higher-quality. The biggest defect I remember finding in Ubuntu's repos was a service whose init script was literally copied from Red Hat, which didn't work, as it tried to source a file of init script utility functions which doesn't exist on Ubuntu, among other issues.
- Red Hat's documentation is fantastic. Ubuntu's documentation is, uh... sometimes present.
- I've found building RPMs to be much simpler and much-better-documented than the process of building debian packages. I vaguely remember being repeatedly frustrated at debian packaging that felt like "this magic thing just interferes and does special stuff when this case is detected", vs RPM's "it just does what the spec file says to do", but I can't remember any details or examples.
- I've had a much easier time building yum repositories than building debian repositories. Just dump a bunch of RPMs in a directory, run createrepo, serve over HTTP. I failed to find something similarly-simple for apt repos.
- Red Hat family had systemd way earlier, and with way better support and integration, than Debian family. While I do agree that there are some implementation issues with systemd, it's been a huge usability and quality-of-life improvement for me professionally.
To me, Debian has always felt like it's designed for someone administering a small number of long-lived pets with a variety of special circumstances, which really isn't what I want professionally. Red Hat has felt like it's engineered for use-cases I care about.