[Spacewalk-list] Clients not picking up requested changes, period

Alexander Innes senni at necurity.co.uk
Tue Jan 27 10:53:19 UTC 2015


Schedual the action then on the server do rhn-chck -vvv. It will tell you
what the client's doing, my gut feeling is either SSL errors OR permsions
(rhn-actions-control is it?)

On 26 January 2015 at 23:16, Chris Swingler <chris at chrisswingler.com> wrote:

> Hey Spacewalk-list!
>
> I have quite a few systems (I haven't dug into seeing if there is any
> consistency in CentOS versions or the RHN tools) that just plain do not
> seem to get tasks back from the Spacewalk server.  We're running Spacewalk
> 2.2 on CentOS release 6.5 (Final).
>
> I can create a simple task in Spacewalk, like just print the output of
> "date", and an rhn_check never seems to execute it.  It shows up under
> Events > Pending, the SystemIDs match, but it never moves.
>
> Running a packet capture to watch the transaction, it looks like Spacewalk
> itself isn't even sending the task to the remote system. Spacewalk happily
> replies with an HTTP 200 and an empty payload.
>
> HTTP/1.1 200 OK
> Date: Mon, 26 Jan 2015 22:47:55 GMT
> Server: Apache
> Content-Length: 126
> X-RHN-Server-Capability: registration.finish_message(1)=1
> X-RHN-Server-Capability: registration.remaining_subscriptions(1)=1
> X-RHN-Server-Capability: abrt(1)=1
> X-RHN-Server-Capability: registration.update_contact_info(1)=1
> X-RHN-Server-Capability: staging_content(1)=1
> X-RHN-Server-Capability: applet.has_base_channel(1)=1
> X-RHN-Server-Capability: registration.smbios(1)=1
> X-RHN-Server-Capability: registration.extended_update_support(1)=1
> X-RHN-Server-Capability: rhncfg.filetype.directory(1)=1
> X-RHN-Server-Capability: registration.update_systemid(1)=1
> X-RHN-Server-Capability: registration.register_osad(1)=1
> X-RHN-Server-Capability: registration.delta_packages(1)=1
> X-RHN-Server-Capability: cpu_sockets(1)=1
> X-RHN-Server-Capability: ipv6(1)=1
> X-RHN-Server-Capability: rhncfg.content.base64_decode(1)=1
> X-RHN-Server-Capability: xmlrpc.packages.extended_profile(1-2)=1
> X-RHN-Server-Capability: xmlrpc.errata.patch_names(1)=1
> X-RHN-Server-Capability: xmlrpc.packages.checksums(1)=1
> X-RHN-Server-Capability: xmlrpc.login.extra_data(1)=1
> X-RHN-Proxy-Version: 0
> X-Transport-Info: Extended Capabilities Transport (C) Red Hat, Inc (version 2.5.72-1.el6)
> X-RHN-Client-Version: 1
> Connection: close
> Content-Type: text/xml
>
> <?xml version='1.0'?>
> <methodResponse>
> <params>
> <param>
> <value><string></string></value>
> </param>
> </params>
> </methodResponse>
>
>
> Full transaction at
>
> https://gist.github.com/cswingler/f718abcb9ce290adec29
>
> rhn_server_xmlrpc.log simply shows:
>
> 2015/01/26 16:52:07 -05:00 30997 172.29.7.14:
> xmlrpc/queue.get(1000015056, 2, 'checkins enabled')
> 2015/01/26 16:52:07 -05:00 30998 172.29.7.14:
> xmlrpc/up2date.listChannels(1000015056,)
> 2015/01/26 16:52:08 -05:00 30995 172.29.7.14:
> xmlrpc/registration.welcome_message('lang: None',)
>
> Any basic things I should be checking? I've tried updating the
> spacewalk/rhn tools on the agent, restarting Spacewalk itself, and nothing
> seems to make a change. This issue, as far as I can recall, did not seem to
> appear until after we upgraded to 2.2.
>
> Some systems seem just fine, and I can't seem to find a consistent reason
> why some succeed and others fail.
>
> Thanks!
>
> _______________________________________________
> Spacewalk-list mailing list
> Spacewalk-list at redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20150127/b4486797/attachment.htm>


More information about the Spacewalk-list mailing list