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

Alexander Innes senni at necurity.co.uk
Tue Jan 27 12:45:07 UTC 2015 

Just to make sure im not thinking of the wrong feture are you trying to use
to remote commands?
Systems -> System -> somethin -> remote command (or a different one so i
can test in our environment :) )

from that output its not seeing anything as you said :o

On 27 January 2015 at 12:16, Paulo Silva <paulojjs at gmail.com> wrote:

> I'm having the same issue, running rhn_check does this:
>
> # rhn_check -vvv
> D: opening  db environment /var/lib/rpm cdb:mpool:joinenv
> D: opening  db index       /var/lib/rpm/Packages rdonly mode=0x0
> D: locked   db index       /var/lib/rpm/Packages
> D: loading keyring from pubkeys in /var/lib/rpm/pubkeys/*.key
> D: couldn't find any keys in /var/lib/rpm/pubkeys/*.key
> D: loading keyring from rpmdb
> D: opening  db index       /var/lib/rpm/Name rdonly mode=0x0
> D: added key gpg-pubkey-c105b9de-4e0fd3a3 to keyring
> D: added key gpg-pubkey-b5c61460-41667588 to keyring
> D: added key gpg-pubkey-6b8d79e6-3f49313d to keyring
> D: added key gpg-pubkey-0608b895-4bd22942 to keyring
> D: added key gpg-pubkey-863a853d-4f55f54d to keyring
> D: Using legacy gpg-pubkey(s) from rpmdb
> D: opening  db index       /var/lib/rpm/Providename rdonly mode=0x0
> D: do_call packages.checkNeedUpdate('rhnsd=1',){}
> D: opening  db environment /var/lib/rpm cdb:mpool:joinenv
> D: opening  db index       /var/lib/rpm/Packages rdonly mode=0x0
> D: loading keyring from pubkeys in /var/lib/rpm/pubkeys/*.key
> D: couldn't find any keys in /var/lib/rpm/pubkeys/*.key
> D: loading keyring from rpmdb
> D: opening  db index       /var/lib/rpm/Name rdonly mode=0x0
> D: added key gpg-pubkey-c105b9de-4e0fd3a3 to keyring
> D: added key gpg-pubkey-b5c61460-41667588 to keyring
> D: added key gpg-pubkey-6b8d79e6-3f49313d to keyring
> D: added key gpg-pubkey-0608b895-4bd22942 to keyring
> D: added key gpg-pubkey-863a853d-4f55f54d to keyring
> D: Using legacy gpg-pubkey(s) from rpmdb
> D: opening  db index       /var/lib/rpm/Providename rdonly mode=0x0
> D: closed   db index       /var/lib/rpm/Providename
> D: closed   db index       /var/lib/rpm/Name
> D: closed   db index       /var/lib/rpm/Packages
> D: closed   db environment /var/lib/rpm
> Loaded plugins: etckeeper, fastestmirror, rhnplugin
> Config time: 0.073
> D: login(forceUpdate=False) invoked
> D: readCachedLogin invoked
> D: Checking pickled loginInfo, currentTime=1422360920.07,
> createTime=1422360336.74, expire-offset=3600.0
> D: readCachedLogin(): using pickled loginInfo set to expire at
> 1422363936.74
> D: rpcServer: Calling XMLRPC up2date.listChannels
> This system is receiving updates from RHN Classic or Red Hat Satellite.
> rpmdb time: 0.000
> Loading mirror speeds from cached hostfile
> repo time: 0.002
> Setting up Package Sacks
> pkgsack time: 0.253
> D: local action status: (0, 'rpm database not modified since last update
> (or package list recently updated)', {})
> D: rpcServer: Calling XMLRPC registration.welcome_message
> D: closed   db index       /var/lib/rpm/Providename
> D: closed   db index       /var/lib/rpm/Name
> D: closed   db index       /var/lib/rpm/Packages
> D: closed   db environment /var/lib/rpm
>
>
> 2015-01-27 10:53 GMT+00:00 Alexander Innes <senni at necurity.co.uk>:
>
>> 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
>>>
>>
>>
>> _______________________________________________
>> Spacewalk-list mailing list
>> Spacewalk-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/spacewalk-list
>>
>
>
>
> --
> Paulo Silva <paulojjs at gmail.com>
>
> _______________________________________________
> 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/febaef41/attachment.htm>

More information about the Spacewalk-list mailing list