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.
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.
I though I clearly expressed my opinion with liking the post above 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 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.
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.
@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.
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 https://build.opensuse.org/ and then copied over. As you can imagine, this doesn’t scale well. With more automation, this would be easier to maintain.
Yeah I think we discussed that somewhere already and were waiting on this repo to exist. It’s only RPM package living at 