[Spacewalk-list] Spacewalk 2.8 clients not checking in

Paul-Andre Panon paul-andre.panon at avigilon.com
Fri Jul 27 01:28:21 UTC 2018


It seems to be related to this SELinux issue.
https://bugzilla.redhat.com/show_bug.cgi?id=1584255

I changed the file context of /sbin/rhn_check-2.7 and
/usr/sbin/rhn_check-2.7 as suggested in vinzenz.meier's June 6 entry and
that "fixed" it for me.

----
On Tuesday, July 24, 2018 4:36 PM, I wrote:
I'll chime in and add to Jason Lewis and Nicholas Penner's observations.
We run a mix of CentOS and various LTS releases of Ubuntu on our Spacewalk
environment. Last week I figured out that the CentOS Spacewalk clients
weren't being updated because the channel/repo I had setup was only for
the Spacewalk backend. I therefore set up a new channel/repo for the
Spacewalk 2.8 client and added all our CentOS servers to it so they would
get upgraded. That's what happened last weekend and since all our CentOS
servers now fail to check in.

1) because our Ubuntu clients don't support OSAD or config deployments, I
never bothered to get OSAD/jabber stable for the smaller number of CentOS
servers
2) the CentOS clients were checking in fine with the original 2.6 and 2.7
clients but stopped working when upgraded to 2.8
3) all our Ubuntu clients still check in regularly

So the issue appears to be with the CentOS rhnsd service scheduling
rhn_checks, not the backend.
rhnsd is not a script, it's an executable, so "fixing the script" isn't
really an option.

Presumably, for people successfully using OSAD, checks still happen as a
result of OSAD, and so the failure of rhnsd to check in isn't being
noticed. Alternatively (I didn't look into the code) perhaps the scheduled
task (through taskomatic or does rhnsd use its own scheduler?) somehow
tries to do an OSAD check (or something else that fails) before running
rhn_check, and when the OSAD check fails then aborts silently prior to
actually running rhn_check?

Anyways, this is a regression with the Centos 2.8 client that's a
departure from 2.7 behaviour and, since this mechanism appears to be a
failsafe for OSAD failures or lack of implementation, it's no longer
working as designed.

What changes were made to rhnsd in 2.8 that might cause this regression?




More information about the Spacewalk-list mailing list