Is anyone using katello to patch Oracle Linux 6 and 7 machines? I setup a few test servers following the suggestions in this discussion Bug #11712: Katello agent can not be installed on Oracle Linux 7.x - Katello - Foreman. This works, but the subscription-manager version is pretty old. Is there any newer information about patching Oracle Linux clients with katello that I’m missing? Are OL katello clients even supported? Will there be a subscription-manager for OL8 when it comes out?
I’m nearing the end of evaluating Spacewalk vs Katello for patching, and OL support is important to us.
My katello server is running CentOS 7 with katello-3.11.
we are using Katello for patching of few OL 7 servers. Due to lack of other options, we are using the same method as described in that issue. It’s no beautiful solution, but at least it works for now. Oracle explicitly obsoleting subscription-manager in their rhn builds is quite a pain though to get it working initially.
If you needs some tips, I’ll gladly help out once I’m back in office on tuesday.
In the current situation, whether there will be subscription-manager for OL8 is probably up to dgoodwin (unless someone here takes up the task).
We’ve been patching both 6.x and 7.x for a few years now.
My solution for 7.x was to simply exclude rhn* as a yum content filter in my content view. This works perfectly.
I also then include the standard foreman clients and katello-agents in the same content view.
Side note: If you want Oracle Linux 7 to be what Oracle claims it to be (100% RHEL compatible) then you should exclude their force fed MySQL packages and UEK repos in addition to the RHN* package exclusion. Doing all of this makes OL7 behave the way you would expect an EL7 rebuild to work and eliminates almost all of the silly issues that OL team introduces with their shenanigans.
That’s what I suspected with the OL8 subscription-manager – ie just wait and see.
Your comment about excluding the UEK kernel made me think of another question about repositories. What repositories are you syncing from? I have an OL6 and OL7 product, and each one only uses the –latest repo listed below. We always end up booting off of the EL kernel so I don’t think we need the UEK kernel repo synced. Did the recent modular OL yum repo configuration changes change which repos you sync from? I’m sorry if that is more of an OL question vs Katello!
Those are the publicly visible repositories. Oracle has another series of customized repositories that require an Oracle support contract, and those can be directly accessed by Spacewalk (and I assume RHSat5.) I’m not aware (at least I haven’t found it yet…) of any way to directly access these repos from Katello/TheForeman. I may have to devolve down to syncing to a local structure, then syncing up into K/TFm.
I haven’t set up the OL8 stuff in Spacewalk yet, I have a couple of hundred OL[567] hosts maintained at my client. As I’m trying to get to a Katello based system, I do greatly appreciate the heads-up about client subscription issues.
I’m going to follow on here with a related question, on provisioning Oracle Linux 7.
The RPMs in Oracle distribution media seem to be problematic in that the rhn*rpm files want to obsolete TFM/Katello agent RPMs. I’ve gotten around this by extracting the contents of the ISO, removing rhnrpm, and regenerating the repository data. This structure is what the operating system entry in TFM/Katello points to, and I can now successfully install OL7.
Does this appear to be a reasonable course of action? Or am I missing something? Removing the RPMs per Tony’s suggestion above works for updates, but the provisioning process itself builds out from release media which by default contains the problem children.
Tony, I have to ask as well… for OL6, what repositories are you using for the foreman clients and katello agents? I must be brain dead, I’m not finding anything recent.
This is probably your best option - as painful as it is.
OL7 public yum repo intentionally doesn’t include Kickstart trees. So you can’t simply provision from synched content like you can with a civilized distro. You either need to hand build you tree (as you have done) or build from synchronized installation media.
I, thankfully, don’t have to provision OL7. But if I did, I would probably take the same approach you did - with a little scripting glue to keep it up to date.
I don’t use katello-agent - I’m using remote execution on all of my clients (so no goferd installed).
For OL6, I use the standard EL6 repos. Same ones that I use for C 6 - these are in the client install documentation but these are the 2 that I actually use.
I’m most interested [at the moment] in getting subscription-manager available. The subscription-manager in the repository you’ve noted appears to be over 3 years old.
It sounds to me like I’m going backwards from how you’ve got your stuff configured. Must be a better way to do this.
You can certainly run a newer build but that is the official build at this point per the documentation.
Red Hat is supporting 1.20.10 on EL6 - the source RPM is on their ftp server and you can download and rebuild it yourself if it’s worth your time. There is also already an existing COPR build of that SRC rpm available here.
I did rebuild all of the EL5 source RPMS for 32-bits as the Katello team was only shipping 64 bit packages. It was worth it for me when I had still had quite a few EL5 32 bit systems deployed and it required very little effort to rebuild.
For me personally, there are no missing features in the Katello supplied dgoodwin COPR 1.17 build. EL6 doesn’t have much supported time left. We’re rapidly decommissioning workloads on those platforms already so there is no way I’d spend time futzing with it at this point unless there was a serious security issue.
Bringing this back around for OL8…fully patched Katello & TFM.
The ‘rhn*’ filter appears to be working gracefully for OL[567] content views, but for OL8, this filter looks like it’s removing about half of the RPMs, rather than the rather small number I’d expect. Additionally, when looking at the filter rules in the browser GUI, selecting the “show matching content” button shows no matching content.
Yes, they’re on extended life support.