[Spacewalk-list] Spacewalk 2.2 Osad - action-deploy - strangenesses?
Ryan Clough
ryan.clough at dsic.com
Thu Sep 4 16:19:02 UTC 2014
Jonathan,
I ran into this problem again today and it was much closer to your
scenario. It only happened to one system and it was the only system that
had been originally registered using the 2.1 client and then subsequently
upgraded to 2.2. All other clients had been originally registered with the
2.2 client.
Here were the errors that I was seeing in the log:
jabber_lib._orig_dispatch: <error><conflict xmlns =
'urn:ietf:params:xml:ns:xmpp-streams' /></error>
Error caught:
Traceback (most recent call last):
File "/usr/share/rhn/osad/jabber_lib.py", line 121, in main
self.process_forever(c)
File "/usr/share/rhn/osad/jabber_lib.py", line 179, in process_forever
self.process_once(client)
File "/usr/share/rhn/osad/osad.py", line 250, in process_once
client.process(timeout=180)
File "/usr/share/rhn/osad/jabber_lib.py", line 1055, in process
data = self._read(self.BLOCK_SIZE)
SSLError: ('OpenSSL error; will retry', "(-1, 'Unexpected EOF')")
These are the steps that I took to fix the issue:
On the client:
service osad stop
rm /etc/sysconfig/rhn/osad-auth.conf
rm /etc/sysconfig/rhn/systemid*
On the server in the web GUI:
Systems -> [affected-system] -> delete system
Click "Delete Profile" button
Back on the client:
rhnreg_ks --serverUrl=http://[spacewalk-server-hostname]/XMLRPC
--activationkey=[activation-key]
service osad start && chkconfig osad on
Back on the server in the web GUI:
Schedule something to test. I scheduled a configuration files
comparison and it was picked up immediately.
After doing the steps above, the system is now picking up actions from the
server. I'm not sure that this is a feasible solution for you because I do
not know how many clients systems you have but thought I would pass this
along. Maybe someone who knows more about what could have caused this has
an easier way of doing this other than re-registering all your clients.
HTH
Ryan Clough
Information Systems
Decision Sciences International Corporation
<http://www.decisionsciencescorp.com/>
<http://www.decisionsciencescorp.com/>
On Wed, Sep 3, 2014 at 11:31 PM, Jonathan Hoser <
jonathan.hoser at helmholtz-muenchen.de> wrote:
> Thank you, Dmitri,
> thanks Ryan;
>
> Summary: Still no solution for me...
>
> @Ryan
> so I checked my rhn-actions-control settings, and they were already set,
> I disabled and reset them,
> just to make sure. Did not solve my problem at hand.
>
> @Dimitri
> I had pretty much done all steps you mentioned for osad,
> except the clearing of osad-auth. Did that, the client reauth'ed
> pings are working, still actions are not picked up.
> To check the Certs (I was pretty sure *that* was still ok),
> I did two things: change the servername from FQDN to ip,
> which made the osad complain about not being able to connect;
> Changing that back, the osad connect just fine, pings,
> but won't pick up actions.
>
> Just for the sake of it, I put the previous version of my Cert on the
> client,
> and got the same results as above: Old cert -> no Jabber connection
> Current Cert -> ping works, actions don't.
>
> Thanks anyway guys!
>
> On 09/03/2014 09:32 PM, Dimitri Yioulos wrote:
> > On Wed, 3 Sep 2014 09:41:56 +0200, Jonathan Hoser wrote
> >> Dear all,
> >>
> >> once again I'm puzzled and would like to fish for input:
> >>
> >> After having (successfully) upgraded to 2.2, (client 2.2 also deployed
> >> everywhere),
> >> I have the puzzling situation with OSAD, that the clients connect,
> >> and respond to pings (the usual way to test OSAD),
> >> but is not send any action (package deploys/config compares/conf
> >> deploys) - or doesn't see any.
> >>
> >> So far I have tried:
> >> -clearing the jabber-db
> >> -restarting client-side OSAD (very-verbose)
> >> -clearing all pending actions
> >>
> >> What I can tell:
> >> I see the ping-request, and the clients answer,
> >> and the webgui updates accordingly.
> >> But the client never sees (or gets) any of the scheduled actions (even
> >> when running rhn_check manually).
> >>
> >> The latter might be a second issue, or might be tightly connected to the
> >> first,
> >> as a yum update does the trick - as far as package-deploys/-updates go.
> >>
> >> I'm was slightly reminded of Daniel Thielkings issue from a few weeks
> >> ago where a command
> >> wouldn't be picked up, but I haven't seen a solution to that yet...
> >>
> >> Any hints, comments, suggestions or solutions are highly appreciated.
> >>
> >> Best
> >> -Jonathan
> >>
> >> --
> >> Jonathan Hoser, M.Sc.
> >> Institute of Bioinformatics and System Biology
> >>
> >> WWW: http://mips.helmholtz-muenchen.de
> >>
> >> Helmholtz Zentrum München
> >> Deutsches Forschungszentrum für Gesundheit und Umwelt (GmbH)
> >> Ingolstädter Landstr. 1
> >> 85764 Neuherberg
> >> www.helmholtz-muenchen.de
> >> Aufsichtsratsvorsitzende: MinDir´in Bärbel Brumme-Bothe
> >> Geschäftsführer: Prof. Dr. Günther Wess, Dr. Nikolaus Blum, Dr. Alfons
> Enhsen
> >> Registergericht: Amtsgericht München HRB 6466
> >> USt-IdNr: DE 129521671
> >>
> >> _______________________________________________
> >> Spacewalk-list mailing list
> >> Spacewalk-list at redhat.com
> >> https://www.redhat.com/mailman/listinfo/spacewalk-list
> >>
> > Jonathan,
> >
> > I don't know if my fix is necessarily right for you because of how the
> problem was
> > probably created, but I'll share it with you anyway. I, too, had
> upgraded to version
> > 2.2, and client actions would queue, but never complete.
> >
> > First, some background into my situation. I had run out of disk space
> on my Spacewalk
> > server (yes, poor planning, but I had no idea in advance of how much
> space I'd need.
> > There, I copped out :-) ). I should simply have used Gparted to add
> disk space, and I
> > might have been all set. Anyway, I blew away all of my repos first.
> Then, I
> > re-initialized the Spacewalk server. Then, I rebuilt the repos. All
> this was a real
> > pita, but the silver lining was that I re-trained myself. So far, so
> good. But now, my
> > clients weren't responding to actions, as I had mentioned. I posted my
> problem to the
> > list, and got a couple of nice responses from Matt (hey, Matt). I first
> tried clearing
> > the jabberdb, as he suggested. No joy. I also looked at
> > /var/log/rhn/osa_dispatcher.log on my Spacewalk server. I suspected it
> had something to
> > do with SSL, but that was just a guess. Having nowhere else to go, I
> ran the following
> > command on the Spacewalk server:
> >
> > /usr/bin/rhn-ssl-tool --gen-ca --set-country="US" --set-state="MA"
> --set-city="Anytown"
> > --set-org="My Corporation" --set-org-unit="spacewalk.mycompany.com"
> > --set-common-name="spacewalk.mycompany.com" --set-email="
> administrator at mycompany.com"
> > --force
> >
> > as I may have screwed up the cert when I first re-initialized the
> Spacewalk server.
> > Then, I DL'd the cert to, and re-registered, the clients. It worked! I
> could update
> > packages, run remote commands, etc. I could see rhn_check running on
> the clients via
> > top, where I couldn't previously.
> >
> > Well, I was almost good - one client still wouldn't work. Matt had, in
> the meantime,
> > posted a second response, suggesting to stop osad, "rm
> > /etc/sysconfig/rhn/osad-auth.conf", and restart osad, on the client.
> That also worked,
> > and I'm back to all-good. Maybe doing this first might work in your
> case.
> >
> > Hope my long-windedness is worth something to you.
> >
> > Dimitri
> >
> >
> >
>
>
> --
> Jonathan Hoser, M.Sc.
> Institute of Bioinformatics and System Biology
> Phone: +49-89-3187-4556
> Fax: +49-89-3187-3585
> Email: jonathan.hoser at helmholtz-muenchen.de
> WWW: http://mips.helmholtz-muenchen.de
>
>
>
> Helmholtz Zentrum München
> Deutsches Forschungszentrum für Gesundheit und Umwelt (GmbH)
> Ingolstädter Landstr. 1
> 85764 Neuherberg
> www.helmholtz-muenchen.de
> Aufsichtsratsvorsitzende: MinDir´in Bärbel Brumme-Bothe
> Geschäftsführer: Prof. Dr. Günther Wess, Dr. Nikolaus Blum, Dr. Alfons
> Enhsen
> Registergericht: Amtsgericht München HRB 6466
> USt-IdNr: DE 129521671
>
> _______________________________________________
> Spacewalk-list mailing list
> Spacewalk-list at redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list
>
--
This communication is intended only for the person(s) to whom it is
addressed and may contain confidential and/or privileged information. Any
review, re-transmission, dissemination, copying or other use of, or taking
of any action in reliance upon, this information by persons or entities
other than the intended recipient(s) is prohibited. If you received this
communication in error, please report the error to the sender by return
email and delete this communication from your records.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20140904/0e30030c/attachment.htm>
More information about the Spacewalk-list
mailing list