RFC: Deprecating Katello Bootstrap Client Tools

RFC: Deprecating Katello Bootstrap Client Tools

Related RFCs:

This RFC aims to follow on previous RFCs that targeted changes to Katello’s client tooling and registration workflows towards deprecating and eventually removing some of our client tools. This RFC specifically targets tools involved with registration workflows. The current set of tools/flows we have are:

  • katello-consumer-rpm: Handles configuration of subscription-manager and CA certificate placement
  • katello-client-bootstrap: Used for migrating existing hosts into Foreman/Katello, EL focused as it uses yum/rpm/subscription-mananager under the hood
  • global registration: New method for registration that is API and template based, built for use in core Foreman as well as plugins (including Katello)


Officially deprecate katello-consumer-rpm and katello-client-bootstrap in Katello 4.3 and aim to drop support of both in Katello 4.5. All client registration workflow support would move to global registration and remote execution.




  • Simple workflow for users
    • Install RPM
    • subscription-manager register
  • An RPM per foreman-proxy configured to point at that proxy


  • Inherently insecure
    • Served over HTTP
    • Contains the CA certificate in the RPM
  • Support is limited to RPM clients
  • Changes to custom CA certificates, ports, hostname all required rebuilding the RPM
  • The RPM is built on the install platform but targeted at multiple OS versions which makes it hard to keep compatible across clients
  • Requires switching out RPMs on the system if switching registered proxy
  • Does not support immutable operating systems such as OSTree where RPMs cannot be installed

katello-client-bootstrap aka bootstrap.py


  • Single python script served in /pub that users can access


  • Primarily EL focused
  • Given single python script, have to ensure it works across available Python versions on every client

Benefits of Global Registration

The original RFC for global registration (RFC: Simple & automatic host registration WF) lays out the benefits of that approach. The highlights for replacing these tools is that it’s a single API, usable in Foreman and Katello use cases. The API is inherently more secure than the bootstrap RPM. Further, global registration allows control of the registration workflow, the items being configured at a template level allowing for more programmatic behavior and user customized behavior. Addtionally, this does not require building any platform specific tools (i.e. no RPMs) and can be generated for any smart-proxy from data reported by that proxy.


Thanks @ehelms for creating this RFC.

I’ll start by saying that I think Global Registration is an outstanding feature and I am excited for its future, particularly so for the powerful automation it can enable for sophisticated users. My primary concern that I will lay out here is that I do not think there is a single registration feature that is right for all end users.

I have seen a lot Katello environments where the users span not only separate teams or separate divisions, but even separate companies altogether (i.e. vendor/customer relationship). In these environments, it is common that the sysadmins responsible for the registered host machines are not experienced Katello users; many times they do not have their own login, do not interact with Katello in any direct way outside of registration and patching, do not use the Katello WebUI at all and may not be confident with REST APIs in general, and in some cases may not even know that Katello exists (only that their repositories are coming from “somewhere”). They may not use a great deal of automation and the systems which they administer can be quite heterogeneous.

Global Registration is an amazing feature in general, but for users like these it may not be the right fit for a few reasons:

  • They do not have prior familiarity with the WebUI, which would be the easier way to use Global Registration
  • They do not have prior familiarity with a variety of concepts and specific fields they will be asked to populate to generate the registration commands
  • They are not confident using APIs directly
  • They need a login or access token
  • Global registration is highly efficient (in terms of person-hours) at large scale in highly homogeneous and automated environments, but it is slower in more heterogeneous environments when servers may be registered one at a time or in an ad-hoc fashion

By contrast, these users may have a simpler experience registering with the bootstrap RPM:

  • They describe their content needs to the vendor or Katello admins, who create for them a content lifecycle complete with activation keys
  • The Katello admins provide them with a list of activation keys to use per server type and two basic commands using simple and familiar tools:
  • rpm -Uvh http://someproxy.example.com/pub/katello-ca-consumer-latest.noarch.rpm
  • subscription-manager register --activationkey=key1,key2,key3

My proposal is that we should not completely remove the Bootstrap RPM and existing registration workflow. Instead, with the installer it would be extremely easy to default this feature to off for new installs with the option to enable it when the Katello admins judge that it serves the needs of their users and the advantages outweigh the drawbacks. NOTE: In this proposal, bootstrap.py would still be deprecated as it mostly used at scale by somewhat more experienced users, and can therefore be fully supplanted by the Global Registration feature. The advantages of this approach would be:

  • Serve the needs of a wider cross section of end users with a more targeted experience for their use case
  • Offer choice to Katello admins whether they prefer to enable Bootstrap RPM in addition
  • Bootstrap RPM requires far less developer maintenance (perhaps EL9 is looming? I am not familiar with challenges that may pose) than bootstrap.py , so we still reap the benefits of deprecating bootstrap.py with very little overhead.

A final comment/question – @ehelms could you kindly elaborate a bit on the security concerns with the bootstrap RPM? My understanding is that making the CA private key available would compromise its security, but sharing the CA certificate is not only relatively safe but also necessary in order for hosts to have trusted communication with the Katello infrastructure.

Thanks for reading – I’m looking forward to hearing anyone’s further thoughts on this topic.

As @Marek_Hulan points out to me often, users do not have to use the Web UI or the API to figure out a registration URL. An organization admin could create a ‘service user’, generate a command with a token and activation key(s) and then hand that out to users that they can then use to register their machines with. One thing I did not mention here is we are looking into a CLI tool that would provide a single command to run to re-configure, register and ensure the host is configured with all the right bits. Global registration also offers methods to revoke or expire access where activation keys are blind access and the only way to revoke access is to delete the activation key.

The user is in theory blindingly downloading an RPM from some place and trusting that it has a CA in it that the host should trust, that said host is getting configured to talk to the right Foreman and subscribing to valid repositories from a trusted source. There is nothing inherently in the current process that verifies the CA in the RPM against a hash the user knows is valid for that CA or the user is not acquiring said CA on their own ahead of time. Global registration has a similar gap at present, in part due to curl’s support for this feature being in newer curl versions IIRC; however, global registration has a path to solve this. I do not see a good way for the RPM based version to support this.

I appreciate continuing to think about the different personas and use cases especially around “anonymous” user access to content that is used. This deprecation proposal is aimed at reducing our tooling overhead, leveling the playing field across different client operating systems and increasing security.

1 Like

One disadvantage of the current model as mentioned is the “one rpm/CA PER smartproxy”.

I would like to someday have a way we can loadbalance among smartproxies and scale them horizontally for thing like katello content services.

The one rpm/CA per smartproxy makes that difficult.

1 Like