I am installing Foreman with Katello on RHEL7 for patch management for RHEL7 servers. I have one available entitlement for this new server. Below is my understanding of what I need to do. Can someone please confirm or correct? Thanks.
- Install RHEL7 and subscribe the system using the 1 available entitlement.
- Install and configure Katello/Foreman
- Unsubscribe the system to free up the entitlement.
- Unsubscribe the other systems to free up their respective entitlements.
- Create and import the manifest.
- Add the foreman server as a content host and attach the 1 available entitlement from the manifest.
- Add the other servers as content hosts and attach the respective entitlements from the manifest.
Saurabh
Hi Saurabh,
You have got the right general idea, though I believe you will want to skip the steps #3 and #6.
Whether the self-registered deployment still works or is supported (I believe the answer is “no”, or at least “this is not the recommended approach”, though someone may correct me if I am wrong) you will likely have an much easier experience with Katello that is registered to RHSM and has the operating system patched directly from the Red Hat CDN.
At least one obstacle to making the self-registered deployment a good experience was difficulty in getting the katello-agent to work reliably on Katello server itself. There is a plan to replace katello-agent with a REX pull provider (RFC: REX pull provider) but it’s possible there are other issues with a self-registered setup as I don’t think it’s something that we test much or at all.
If your use case absolutely requires an offline/air-gapped environment where Katello doesn’t have access to the RHSM and the Red Hat CDN, then in theory you could still use the offline registration method (https://access.redhat.com/solutions/3121571) and one of the recommended (by Red Hat) offline patching methods (https://access.redhat.com/solutions/29269) for Katello server. Syncing repositories in this use case is a much more complicated process which involves using a 2nd online Katello instance for syncing, exporting the synced data to ISOs, and transferring the exported ISO across the air gap to the disconnected environment, and configuring the offline Katello instance to sync from those mounted ISOs. I have not personally tried this process with upstream Katello and I’m not aware if there would be any differences to the process vs. downstream Satellite.
Kind regards,
William
1 Like
William,
Thank you for the detailed explanation. I am, in fact, looking for best practices.
-
So, if I understand correctly, it is not recommended to add the Katello server as a content host. The reason I was looking to add it as a content host was so that I can use content views to maintain the same patches across all my servers, including the Katello server. It is not an absolute requirement, just a preference. Is there any simple way to achieve this?
-
The second reason I wanted to do this was to be able to manage all subscriptions in a single location (Katello). Again, not a requirement, just a preference. From your response, this is not the recommended approach and will just cause issues. Correct?
So, assuming there is no simple way to achieve 1) above, the recommended approach would be to not add the Katello server as a content host and subscribe it directly with RHSM. For all other servers, use Katello for subscription and content management. Is my understanding correct?
Saurabh
Hi Saurabh,
That’s correct – when installing on RHEL, the best practice is to register the Katello server to RHSM for RHEL subscription and OS updates, perform a full update of the OS with the latest OS packages available from Red Hat CDN prior to installing Katello[1], and when upgrading to perform a full update of the OS each time with the latest available packages[2] prior to changing Katello repositories to the next release and performing the application upgrade.
While it is in theory possible to do what you described and register Katello to itself as a content host, it’s not something that we document, support, or most importantly test. For that reason, you may find some features do not work in this scenario (likely katello-agent, possibly others) and as this is free software you can determine whether that is a deal breaker for you.
An additional consideration is that the value-add you get from using a content view which has only a single server is likely low relative to the extra effort of publishing and promoting content, because much of the benefit of the content views feature lies in the ability to use a content view version in one lifecycle environment (e.g. devel or test) for a while, before promoting it to the next lifecycle environment in the path (e.g. qa-perf or production). You could of course use the same CV for the RHEL repositories on the Katello server as on the other RHEL machines, but in my opinion this also somewhat defeats the purpose as the use-case for RHEL (running Katello) is different on that machine vs. on your other RHEL machines (running whatever other applications), so you would face different and in rare cases possibly even conflicting OS vs. application compatibility concerns within that content view.
By all means, if you do understand the risks and want to attempt this kind of deployment regardless, please do report back with your experience as I am curious to know if you face any difficulties or whether the benefit you achieve is higher than my expectation.
[1] See Installation Guide under heading “Installation”
[2] Step 2 in the Upgrade Guide
Kind regards,
William
1 Like
William,
Thanks again for the detailed explanation.
I do not have any experience with Foreman. So, I’ll just go with the recommended approach to avoid any potential issues.
Saurabh
