I’m a new Foreman/Katello user and I’m testing it for the first time. I want to use it for patching and installing errata on CentOS 6 and 7, and Oracle Linux 6 and 7 servers. So far I’ve only tested with CentOS 7 clients, and I have a few questions and problems that I would like advice on.
My server is running foreman 1.19.0 with katello 3.8 on CentOS 7.
My client is CentOS 7 running the katello-agent-3.3.2-3 and katello-host-tools-3.3.2-3 (per the katello 3.8 client install documentation).
First, I would like to ask if my methodology/understanding of using content views is correct. I have a centos7 product created with the “os x86_64” and “updates x86_64” repos. I have a content view for centos7, that I promoted to my dev7 and prod7 lifecycle environments (for cv version1). I also have activation keys for centos7 dev7 and prod7. Then I used the errata_import.pl script from https://github.com/rdrgmnzs/pulp_centos_errata_import to import the centos errata to my centos7 “os x86_64” and “updates x86_64” base repos. After importing the errata and syncing the repositories (with “mirror on sync” to no), I published and promoted the content view to the dev7 lifecycle, and then eventually to prod7 lifecycle (to make cv version2) Is this method correct? Then when I want to install the next batch of errata, I would repeat this process and promote to cv version3? Should each operating system have its own lifecycle environment (centos6, oracle linux 7, etc)?
Is the “installable updates” column supposed to be automatically updated with the errata in Hosts – Content Hosts? I see applicable errata if I drill down into the Errata tab for the host. Goferd is running on the clients, and I started the rhsmcertd process so they are checking in. If I do a “recalculate” in the errata tab, the “installable updates” column is updated, but it seems like it should automatically update when the client checks in.
When I try to update all of the packages via Hosts – Content Hosts – select host – Packages – Applicable – Update All Packages, I get the error “init() takes at least 2 arguments (1 given)”. References from the website Bug #24353: Update all packages action on host shows __init__() takes at least 2 arguments (1 given) - Katello - Foreman suggest this is fixed in katello-host-tools-3.3.4-1. Should I be using a different version of the katello-agent than the katello client documentation reference? If so, where do I get it?
When updating all packages via Hosts – Hosts Collections – select host collection – Package Installation,Update, Removal – Update all packages – via katello agent, a message pops up saying it was successful, yet no task is created, and none of the packages get updated on the clients. Is there a fix to this?
No, typically users have a ‘staging’ and ‘production’ lifecycle environment. You can do whatever you’d like, of course, but users often test content changes on test systems first before promoting a content view version to the production lifecycle environment and having the updates visible to their production systems.
Yes, with every yum action you perform on the client, the “package profile” should be uploaded to Katello and applicability is recalculated if there is a package change. You should see some log on the client for this under /var/log/rhsm/rhsm.log.
Thank you for your reply. For anyone else with the same problems, I ended up updating my server to foreman 1.20 and katello 3.9.1, and one of my CentOS7 clients to katello-agent 3.3.5. The katello-agent 3.3.5 solved the problems I had with the “init() takes at least two arguments (1 given)” errors when updating via content hosts, as well as updating all the packages via host collection.
So I actually have to manually run yum, or perform a “recalculate” of the errata for the “installable updates” column to be updated? I expected it to automatically update on its own after importing/publishing/promoting the errata. That way I could look at the list of content hosts and see what needs updating. Does rhsmcertd need to be running on the clients?
Are you saying that you promote all of your content views (in my case centos6 and centos7) thru the same “development” and “production” lifecycle environments? Rather than having two dev/prod lifecycle environments, one for each OS?
I’m not sure if errata calculation happens periodically. It’d probably be a good idea to have an option to recalculate on content view publish/promote. Maybe someone else from @katello would know.
Yes, that’s correct. Lifecycle environments aren’t OS-specific. Also note that there’s a default ‘Library’ lifecycle environment that is used when you sync any repo or publish a content view version. You can read more about lifecycle environments and the special Library environment in the Katello documentation.
