Managing Fedora at Scale - Spacewalk is discontinued? What else?

Hi forum,

TLDR: I’m after an opensource package management tool for fedora so I can host content without internet access. Simpler the better. Anyone have any advice on this?

Long Question:

I am thinking about using fedora at work to try and work around the continual tiresome budgeting headaches with using fully supported software. I’m not that bothered about support given my intended use case, as for some reason often end up fixing things myself and doing things on my own anyway.

Providing I can manage it centrally, with automation (which I acknowledge will take effort itself to develop and maintain), I am willing to put the graft in and try it out to see how viable it is.

So for management, spacewalk sprang to mind - I appreciate this is probably old news, but this is discontinued; Uyumi looked interesting but seems very very very suse orientated. Don’t get me wrong but: if the management becomes a management headache then I worry I’ll lose focus of my goal: package management.

Anyone got any tips for package management as a starter (for dnf install and update) - something simple to start with?

This topic seems a bit of a minefield - foreman seems a bit of a cottage industry - I’d be grateful for any pointers. I am expecting to have to undertake very focused learning on so having the right target goal is more important to me than knowing how to do it at this point.

Thanks very much, in advance, for any advice on this.

1 Like

We used foreman plus puppet at my last job to manage 1000’s of physical servers and VMs. You could consider foreman.
I, personally, did not like puppet and given a free hand would go for ansible.

Uyuni itself is a fork of Spacewalk, and there is a contributor that works on making it run on CentOS if you would prefer to avoid an openSUSE based deployment. But it is more than capable of managing Fedora systems.

That said, Foreman with Pulp and Ansible would do what you want as well.

Use pulp and ansible.

Capturing provisioning and configuration as code works wonders. In my last workplace I personally deployed a satellite 6 environment in 2014 which revolutionized how IT worked. The upstream project is the foreman and there is plenty of info on how to use it with centos and the like.

The foreman is probably overkill. It serves as an external node classifier to puppet though much has been replaced by ansible. It can automate aspects of the management of ipa, dns, dhcp and pxe boot servers. It also can manage software subscriptions and deploy virtual machines, support different geographical locations with data locality and …

The foreman uses pulp and katello to manage yum repos and other software repos. These can be versioned and filtered and provide a lot of flexibility.

A simpler option is to just use pulp on it’s own for a software repository. Then use a local git repository to host your own set of ansible playbooks. This is a great simplification over the foreman.

Moving from a distribution with lengthier lifecycle to fedora is a bold move. Alma Linux, Oracle Linux, Rocky Linux, CentOS stream options have 5 years of primary support whereas fedora is basically 1 year. The stream10 would be a nice one if the timing of it’s release and your project coinside if you choose to go this way. Timing a change to optimize lifecycle has benefits.

Frankly I think you hit the nail on the head there - for me anyway. I did wonder about foreman being a bit overkill. Perhaps that become useful as time passes and I can justify the additional complexity. Most headaches I have are ones related to dependency hell caused by content views in satellite (there are reasons why I am seeking an alternative), I’ll build templates from this in packer with an ansible configuration build step . I’ll give your suggestion a go and I thank you and the others who have pitched in with suggestions. Much appreciated.

I experience is that Fedora works better then then LTS versions for two important reasons.

  1. Technical: You are working with up to date software. Its easier to find expertise when things need working on. We where forever back porting current versions of software to Centos 6, such a waste of time.

  2. Tech-Debit: Updating to a new Fedora every 6 months means that you can amortize keeping your solution maintained. I have the unenviable task of updating from Centos 6 to Oracle Linux 8, jumping 10 years of tech-debit in one hope was very costly.

1 Like

I’m with you and only use fedora nowadays. Updating in-place is never optimal and I frown upon doing it. With everything captured in a provisioning/config mgmt system with backups, keeping current is pretty easy in my view. It would be nice to have all packages in fedora all use only the most current versions of dependency packages. I can only dream.

The times when I have to support an application that requires one of the ELs, stuffing it into a VM is common. Still there are technically demanding apps that benefit from bare metal. Pushing the app vendors to keep up even with the ELs has never gone anywhere so sometimes I’m stuck. With FLOSS exclusively things are much better.