[Spacewalk-list] Spacewalk 2.8 clients not checking in

[Wilkinson, Matthew]

So I've been following this and after Tomas referred it over to https://bugzilla.redhat.com/show_bug.cgi?id=1596499 the bug seems to have been fixed but only for Fedora 29...

Does anyone know if this will be fixed in RHEL?

Thanks,

Matthew Wilkinson

-----Original Message-----
From: spacewalk-list-bounces at redhat.com [mailto:spacewalk-list-bounces at redhat.com] On Behalf Of Paul-Andre Panon
Sent: Thursday, July 26, 2018 20:28
To: spacewalk-list at redhat.com
Subject: Re: [Spacewalk-list] Spacewalk 2.8 clients not checking in

[This is an external email. Be cautious with links, attachments and responses.]

**********************************************************************
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?

_______________________________________________
Spacewalk-list mailing list
Spacewalk-list at redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list