Problem:
I’ve got a freshly installed foreman/katello setup, which looks like it’s working nicely with one el7, one el8 and one el9 client.
I have just installed updates on all clients and the EL8 & EL9 client info has updated, and the available errata has cleared, and last boot time has been updated.
But the EL7 client info is all outdated:
it shows errata as installable, but i installed them 2 hours ago, and rebooted.
it shows last boot time as 11 days ago, but client was rebooted 2 hours ago.
i’ve gone to the host’s content tab, and clicked “Recalculate”, but that appears to have done nothing.
the host page says the last checkin was 1 hour ago, which is after i installed OS updates & reboot, so it appears to be checking in - the last boot time, and installed/available package lists do not seem to have updated.
I am not using the katello agent, i’m using just remote execution - and I can’t seem to find any info on how these clients actually checkin if not using katello agent. How do i force the client to do a fresh checkin witgh no katello agent? How do i force the client to update its info like boot time, and recalculate applicable errata, if the “Recalculate” button has done nothing?
Expected outcome:
The host should show updated correct value for last boot time, and available packages & errata should now be clear.
The Host->Content->Recalculate option should actually collect fresh list of installed packages and actually recalculate the applicable errata/available packages.
Foreman and Proxy versions:
Foreman 3.6.1 and Katello 4.8.0 fresh install.
Foreman and Proxy plugin versions:
Distribution and version:
Foreman server on RHEL8, testing with clients on RHEL7,8,9
I have now done a “yum check-update”, and that did update the 'Last check-in" time for the host, so that now says 5 mins ago.
But the last boot time, and installable errata is still showing 13 packages which have already been installed… I have even done the “Recalculate” again, and that still does not seem to have helped.
Why are last boot time and available/installable errata not being updated?
Hmm. Ok i noticed i still had susemanager yum plugin installed, as client used to be registered to Suse Manager. After deleting last remnants of that plugin, and re-doing “yum check-update” and subscription-manager refresh, it looks like the available/installable errata lists have updated, hooray!
The last boot time still shows as 11 days ago though so that is still a bit of a concern.
Hmm, ok i’ve gone out to lunch and come back, and the last boot time has been updated.
It looks like the thing that did it was rhsmcertd, I know it runs every four hours on a timer, but i stopped and restarted it, expecting that would get it to checkin, but looks like it did not. I had to wait until the 4 hr timer triggered again. Now, after it has triggered and run, i see this in logs:
“v2023-04-30 05:49:32,245 [INFO] rhsmcertd-worker:31891:MainThread @factlib.py:100 - Facts have been updated.”
And i think that is what has updated the last boot time. Huzzah!
So, to force an immediate checkin via rhsmcertd, it looks like i should have run “rhsmcertd --now”, and that would have done the job.
I think all is good, just need to run “rhsmcertd --now” if i need facts updated in future.
Will close ticket now if i can figure out how.
Just one final tip if anyone with similar issue comes across this post.
Because this rhsmcertd is a Red Hat thing, it is a clunky piece of garbage.
If you run “rhsmcertd --now”, while the daemon is running/sleeping, your “rhsmcertd --now” will fail to get a lock. So you need to stop the daemon before you run “rhsmcertd --now”.
So then, after you run “rhsmcertd --now”, does it just run once and exit, as you might expect, so you can then restart the daemon without it hitting lock issues? No. The “rhsmcertd --now” continues to run, so, you’ll need to kill it before you restart the daemon.
So you basically need to do something like this: “systemctl stop rhsmcertd ; rhsmcertd --now ; sleep 300 ; killall -TERM rhsmcertd ; systemctl start rhsmcertd”
Maybe you should not use redhat software if you are so quick with your opinion?
I don’t why you are messing about with your system. I don’t think any of that is necessary if you constantly try to break things.
Usually, you’ll install katello-host-tools which will install a yum plugin which will update package lists after each run.
katello-agent has absolutely nothing to do with that. katello-agent was the agent to allow katello to execute commands on the client which has now been replaced with remote-execution.
Your advice to install katello host-tools is outdated - while it may still be available, it does not do anything now that isn’t done elsewhere, eg package profiles are now uploaded by subscription-manager.
So this is typical of the problems with open source and in particular, many of the projects associated with Red Hat. Endless, pointless and undocumented changes, any documentation more than 6 months old is outdated, and so therefore nobody bothers documenting anything - because there is little point, when it will be outdated in less than 6 months.
And if there is still a use for katello-host-tools, and i should go and get it, well, thanks very much for the poor integration and poor documentation that has misled me into thinking its not needed anymore.
Ive re-read the katello doc to refresh my memory re the client setup.
It says " The katello-host-tools package reports errata & package profile information, but does not allow you to run remote actions on the clients."
Given that subscription-manager is supposed to report package profile info if you have “package_profile_on_trans = 1” and “report_package_profile = 1”, it doesn’t look like katello-host-tools does a hell of a lot anymore.
What is the point of katello-host-tools now?
If it does still have some purpose, well, it woudl be nice if that was actually described clearly, because it’s easy to get the idea it is not required at all, given that it seems to provide no functionality, is poorly documented and is easily conflated with katello-agent which is described as deprecated in the same section of the doco.
Yes, you are correct, katello-host-tools is still there in the repos although i can’t see why, because it doesn’t seem to do much.
I’ve just installed katello-host-tools on el9 client, to take a look at it, and it does not install any yum/dnf plugin on el9 - it would seem that functionality is taken care of now by the subscription-manager plugin, as it should be, and i was doing fine without it. The issue i had earlier, which prompted me to post here, was caused by leftover susemanager yum plugin - once that was cleaned up, the subscription-manager plugin began uploading package info correctly.
