Source
r/redhat•
bishopolis

RHEL without Smart Management

Hey folks. While renewing licenses, I saw that the Smart Management add-on adds a surprising tax to the license cost; for the smaller subscriptions, it's quite a lot.

Is there a supported patch and subscription replacement for RHSat that avoids that cost (say, with Uyuni, SuSE's fork of their Spacewalk fork) ? How much, on a dollar-offset basis, does that suck?

To be clear: I'm really looking to ditch Foreman. Saving money is easier to pitch up the chain, but I can maybe sell a "stop Bishy hulk-pounding keyboards in rage" deal with the same subscription cost and features, and that'll ensure my reps (Hi Kevin, Ted and Paul) will still think I'm worth the constant hassle.

Posted Jul 6, 2022, 4:54 PM UTC

1921
MariognarlyRed Hat Employee•

At MSRP list pricing, Smart Management will add approx $350 to a RHEL subscription. It may be less depending on your particular Red Hat agreement.

The option without Smart Management / Satellite is to connect directly to Red Hat Customer Portal / CDN and pull content directly. Or through a proxy to this same source. You won't get any of the advanced content management, provisioning, subscription management functions of Satellite going this way, but it is an option. The biggest drawback here IMO is no content staging and versioning, so you won't be able to patch Production exactly like you did Development or Test/QA unless you're patching all these environments at the same time, which really prevents you from doing any kind of soak period or regression testing that you may want to do.

The only supported tool for this for RHEL is Satellite. Spacewalk is for Satellite 5 which is way over EOL. Foreman is one of the upstream projects for Satellite 6, but there's 5 others integrated with it that make up the Satellite product, so it's not a like-for-like tool.

Have you looked at enumerating the costs of the other scenarios? I don't mean to sound combatitive, but if management is concerned about the costs of SM, are they also aware of the costs associated with the other options?

  • What are the costs of manually building and integrating pieces into Foreman, and supporting that through a lifecycle? How many FTE equivalents are needed?
  • What are the potential impact or downtime costs for having to patch Prod at the same time as Dev?
  • What are the costs/benefits of immediately being able to apply a staged content critical security patch with Satellite vs not doing the patch at all, or doing the patch but with other DIY tooling that may need some TLC/investigative work done that may work but likely adds delay?
  • Are there other support costs or constraints/concerns from other groups that rely on the RHEL environment such as Applications or Database teams? Ex. needing to maintain a particular Java version (or some other library)?
14
bishopolisOPRed Hat Certified Engineer•

Yeah, $350 sounds about right. That's how much of a cut of the self, standard, and premium sub? Percentages are everything!

Honestly: We barely use Satellite with Foreman:

  • setup was fraught with strange bugs in whatever release we used.

  • patching, after spacewalk, doesn't compare well.

  • various things dying or slow virt-who killing deployments, auto-publishing CVs stomping over one another, all required some work-arounds and locks. Because this enterprise product was so glitchy I looked for LP's initials on it.

  • and it's slow. And answering "which CVs is this repo in" took three support days and is a cmdline db query, which is baffling.

  • work-arounds required GNU parallel from moreutils in EPEL, and tier1 support actually wasn't going to continue with our client subscription ticket one day, until such 'risky' software was removed.

It all means we don't add anything to it, so IBM won't have a reason to ghost us, and so that means we only use it for its purpose, however minimal that is. It's like the chipped china inheritance that you only bring out when THAT aunt comes by and never otherwise.

So, bare minimum:

  • no, we don't provision out of it, as it's a one-OS solution anyway.

  • we outgrew ansible very early-on, and the only thing it offers is vendor lock-in, and that's not a feature for us (don't buy ice cream from a steak house or steak from an ice cream shop).

  • we still need to use cobbler because pulp is super surprising with its behaviour around some repos (gitlab, rocky) and can't be trusted.

  • so we have to have another box for repos anyway.

The only supported tool for this for RHEL is Satellite

So it's vendor demands, and that's why we're stuck on it, I guess.

That answers my question - we have no functional alternative and are forced to use this app; but we'll continue keeping its workload light and hoping for the best.

But the first RPM distro to come by that's free of the fridge art like systemd and networkmangler, and is certified by SAP, will provoke some serious internal discussions.

Thanks for your time and the answers.

https://i.imgflip.com/6m00ms.jpg

1
KingStannis2020•

we still need to use cobbler because pulp is super surprising with its behaviour around some repos (gitlab, rocky) and can't be trusted.

What problem do you have with Rocky repos? I know there are some problems around Alma Linux repos that boil down to doing really surprising (probably incorrect) things with their repository metadata https://bugs.almalinux.org/view.php?id=262

But I can see why you might want to just turn off all the validation & processing and just "put this repo in this directory" and ignore the inconsistencies as DNF would.

1
redditusertk421•

Just sync redhat's content to an entitled server and run your local yum repo.

4
spaghetti_taco•

Exactly what we do. Update the servers with an ansible playbook. Check ansible galaxy for a good one.

1
eraser215•

How are you controlling which versions of any individual package are made available to a particular set of hosts? e.g. If you patch your dev servers today the set of packages is different to what will be available when you want to patch your prod servers in a month's time. So how do you avoid putting untested software into your prod environment?

1
spaghetti_taco•

We sync the repo once before updating dev/staging which guarantees the same patches are applied a week later in prod. We sync the rhel repos locally if that’s wasn’t clear. We aren’t updating our internal repo every day. Just once a month before patching dev.

1
eraser215•

Understood. So you are moving to whatever the latest software you make available in your repo at any given time. Quite interesting! If you see a critical RHSA like the Pwnkit vulnerability do you just pull that errata into your mirrored repo so that your hosts can consume it?

1
crono782•

Use pulp for this.

1
eraser215•

ie part of Satellite.

1
igouj•

We're heading this direction right now. Local synchronization happens regularly into individual directories, we pick the "point in time" based on the dates on those subdirectories.

1
spaghetti_taco•

That’s interesting our method is a lot simpler. We sync our internal repos once a month right before we update dev. We update prod a week later which guarantees the same updates are applied to prod. Then we update the repos the next month right before patching dev and repeat the process.

2
igouj•

We leverage these repo syncs for our devops world as well as our more traditional "pet" systems, so we like to have those as fresh as possible.

1
yet-another-username•

Yup this. Satellite is just overkill. Redhat has taken something simple (local repo server) and turned it into a money making machine.

Patch management can be as simple as local repo + cron job + Ansible,puppet,chef whatever solution you want.

We

  1. Sync repos monthly
  2. Use puppet to generate a patch report for review
  3. Push cron job to update dev
  4. Wait
  5. Push cron job to update prod
1
redditusertk421•

I wouldn't say its overkill. In order for Red Hat to satisfy the needs of customers in highly regulated industries with large scale deployments they have made something that is overkill/too complicated for smaller customers.

2
[deleted]•

[deleted]

1
[deleted]•

[deleted]

1
ClementJirina•

Are all your “smaller” subs on physical machines?

If mainly on vm’s, have a look at the “virtual datacenter” subs.

1
bishopolisOPRed Hat Certified Engineer•

Yeah, it's about 97% VMs. Most of the prods are on a dozen-plus vsphere machines; but we found SUCH problems with virt-who that I don't know I'd go that route again.

1
thomascameron•

Just use katello. Then follow the instructions in my video at https://youtu.be/tUNo3nddISo to set it up. Super simple, works great, doesn't require management subs.

1
crono782•

I've used both foreman for free and paid satellite with paid rhel and CentOS mix previously (thousands of nodes). One quirk I found is that if you do not carry any smart management, you cannot create manifests to import into foreman/katello/satellite, thereby rendering it useless for content management.

If you are looking purely at yum content management, then just roll your own yum mirror and manage/version it with pulp. Has an API and all. Then you can use awx for managed Ansible to get a semi decent replacement for the config mgmt aspect.

1