Announcing New Foreman Client RPM Repositories

As of today, there are now dedicated RPM client repositories available. The initial repositories are essentially copies of the Katello client repositories (which have now been deprecated and removed in nightly). These repositories will be available as part of the 1.20 Foreman and Katello 3.9 releases. The initially supported distributions:

  • EL5
  • EL6
  • EL7
  • F27
  • F28
  • SLES 11
  • SLES 12

For Developers

If you are a developer who has created, or wants to create client tooling for the Foreman ecosystem you can now do so by including your RPM packages in the client repositories. If a package already existed in the plugins repository we can work to move it into the client repository. Feel free to ping myself or open an initial PR. As this will require some updates to both Koji and the configuration within the packaging repository itself. Note that a new client tool is not required to work across every supported distribution. This is up to the individual tool and maintainer to decide supported distributions.

Next Steps

For users and developers, what other client repositories would you like to see? The initial pass was heavily RPM focused as a way to migrate Katello’s client repositories, but an obvious choice would be to look at adding Debian client repositories for tooling. Please share ideas and we’ll start to iterate on them.


Thanks to bring this up,

It would be nice if packages related to the client part of the foreman openscap plugin move in this repo (on top of my head at least rubygem-foreman_scap_client package) because ATM we have to suscribe all client to foreman-plugins repo to use it.


Sounds like a good idea – @Ondrej_Prazak @Marek_Hulan any thoughts on this?

I though I clearly expressed my opinion with liking the post above :slight_smile: Yeah I think we discussed that somewhere already and were waiting on this repo to exist. It’s only RPM package living at plugin repo. We’d appreciate helping with the foreman-packaging repo, but could definitely provide help with testing.

I agree, the foreman_scap_client is a good fit for this.

We have already worked on a SLES15 client (like the provisioning template )

Can you please let me know how to work on the SLES 15 client packages? Would be happy to contribute.

I can help add this. Currently this is an EL7 only package due to the plugins repository being EL7, should this package remain that way or would you like to expand it’s footprint as part of the move?

I’ll have to refer you to @Justin_Sherrill and @stbenjam who did the SLES 11 and 12 packaging. As I understand things, this was not the easiest process given they had to use OBS. I think there is a document with the process used but I am blanking on where it is.

Do you still want to support EL5 as it is already EoL?

Adding Debian client repos as well as SLES would be a good idea.

We still get requests and questions about managing EL5 instances. We don’t provide full katello-agent services for EL5 but we at least can still currently provide errata reporting.

I know what you mean… Imho it is terrifying how many servers are still running EL5 and other outdated operating systems and I’m trying to do my best to push these guys a bit in the right direction because something is clearly wrong in their environment. So I’m avoiding support for this kind of environment as far as possible in my daily business.

I just added SLES15 to our OBS whitelisted repos and built them, there are some failures it looks like. I will have to investigate and see what needs to change to get these working. I filed Bug #25177: Package katello client tools for SLES15 - Packaging - Foreman to track this.


We are looking for the SLES15 package, is the package for SLES15 still under development? If you need a tester we would happy to support.

Hi there, we REALLY need some RPMs for SLES15 which is GA since one or two years now. We at agree to test and verify these RPMs, too :slight_smile:

@Justin_Sherrill @Jonathon_Turel handled this the last time, so I’m looking to them to weigh in on the effort required and where this could fit into the Roadmap for the Foreman 2.2/Katello 4.0 release.

Is there also a chance that these RPMs might be backported to Foreman 1.24?

1 Like

The reason at is that we want to get rid of “SUSE Manager” for our upcoming SLES15 VMs (which should be deployed from September this year).

The challenge is that we don’t have a build environment for it ourselves. For Red Hat/Fedora RPMs we have koji set up, but the SLES RPMs are built manually. IIRC this was done manually in and then copied over. As you can imagine, this doesn’t scale well. With more automation, this would be easier to maintain.

We build the SLES15SP1 RPMs with the help of our colleague succesfully with the Docker Image opensuse/leap:15.1 and some hints from

Which worked very well.