[Spacewalk-list] Antwort: Re: Upgrading SLES 11 SP3 to SP4 results in broken systemid-Files

Tue Dec 1 12:40:50 UTC 2015

So...my test is just running.

But this must be an error between the different spacewalk agent versions 
while updating.

I deployed a new server with SLES11-SP4 (and the new spacewalk agent from 
SLES11-SP4), which works without a problem.

So the errors seems to be in the change from md5 to sha1 and that maybe 
the wrong "string" is stored either within the db or within the systemid 
file.

Will report as soon my upgrade is through....

Regards,
Robert

Mit freundlichen Grüßen

Robert Paschedag
Netlution GmbH
Landteilstr. 33
68163 Mannheim

im Auftrag des
SWR
Südwestrundfunk
Informations- und Kommunikationssysteme
Neckarstraße 230
70190 Stuttgart

Telefon +49 (0)711 /929-12654 oder
Telefon +49 (0)711 /929-13714
paschedag.netlution at swr.de

swr.de

Von:    Bernd Helber <bernd at helber-it-services.com>
An:     spacewalk-list at redhat.com
Datum:  01.12.2015 07:56
Betreff:        Re: [Spacewalk-list] Upgrading SLES 11 SP3 to SP4 results 
in broken systemid-Files
Gesendet von:   spacewalk-list-bounces at redhat.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Good Morning,

we upgraded roundabout 50 SlES11 sp1/sp2/sp3 Boxes to SP4.

What we've seen so far, it works with Spacewalk 2.2 and 2.3
flawlessly, if you do not upgrade you Spacewalk Agent!

If you have your Spacewalk Agent in a own Softwarechannel/Repository
do yourself an favor. Disable the Softwarechannel for the Upgrade Proces
s

Stick to the Spacewalk Agent Version 2.2
http://download.opensuse.org/repositories/systemsmanagement:/spacewalk:/
2.2/SLE_11_SP3/

https://www.redhat.com/archives/spacewalk-list/2015-August/msg00077.html

We've seen issues to if you dont stick to the 2.2 Agent, we've noticed
also that the Spacewalk Packages built for SP3 are running on SP1 SP2
as well.

So, dont hurdle around with different Client Versions.

Good luck and kind regards.

Bernd Helber

Am 30.11.15 um 13:08 schrieb Lichtinger, Bernhard:
> Hello,
> 
> Upgrading our SLES 11 SP3 Machines to SP4 we stumbled over an
> annoying bug:
> 
> We have spacewalk-2.3 on CentOS6 and our SLES clients use the
> client packages from suse open build service.
> 
> To upgrade a Machine, we change in SW the base-channel and
> child-channels from SP3 to SP4, then run "zypper up zypper; zypper
> dup", which works fine. But then the next time we call zypper or
> rhn_check or some other tool, which talks to the SW-Server it fails
> to do so, because the client certificate is wrong.
> 
> What happens: Everytime the rhn-client-tools talk to the SW server
> the function "maybeUpdateVersion" in up2date_client/up2dateAuth.py
> checks if the system's os-release is newer than the os-releas which
> is recorded in the client certificate
> (/etc/sysconfig/rhn/systemid). On SLES os-release changes with
> every service pack. Therefore "maybeUpdateVersion" requests a new
> certificate from the SW server. The old systemid-File is copied to
> systemid.save and the new certificate is stored as systemid. But
> now the client tries to use this new certificate, but it does not
> work, because the checksum within the certificate does not match
> the checksum the SW server is expecting:
> 
> rhn_server_xmlrpc.log: 2015/11/27 15:29:43 +02:00 27113 CLIENT_IP:
> xmlrpc/up2date.listChannels(1000010119,) 2015/11/27 15:29:44 +02:00
> 21394 CLIENT_IP: xmlrpc/up2date.listChannels(1000010119,) 
> 2015/11/27 15:29:44 +02:00 21413 CLIENT_IP:
> xmlrpc/registration.upgrade_version(1000010119, '11.4') 2015/11/27
> 15:29:44 +02:00 21387 CLIENT_IP: xmlrpc/up2date.login(1000010119,) 
> 2015/11/27 15:29:44 +02:00 21411 CLIENT_IP:
> rhnServer/server_certificate.__validate_checksum('ERROR', 'Checksum
> check failed: 47401415cf887beab0e590ad07fbb6ae !=
> 6abe16dcad7c7fe65b75a053cfade1de905832d74f0342d3f8132c41a25f63cc'
> [...]
> 
> On the client a diff between old and new certificate shows: diff
> systemid.old systemid.new 22c22 <
> <value><string>3902bcae3cabf243bd50afb108ee58a0</string></value> 
> ---
>> <value><string>6abe16dcad7c7fe65b75a053cfade1de905832d74f0342d3f8132c
41a25f63cc</string></value>
>
>> 
34c34
> < <value><string>x86_64</string></value> ---
>> <value><string>x86_64-redhat-linux</string></value>
> 38c38 < <value><string>11.3</string></value> ---
>> <value><string>11.4</string></value>
> 
> The strange thing is, the server expects neither the old checksum
> nor the new checksum.
> 
> When I revert the client certificate to the old version, it starts
> over again: For one time e.g. a "zypper lr" works, and then the
> client requests again a new certificate and it is broken again.
> 
> My workaround is to generate a reactivationkey after the SP upgrade
> and to reregister the client machine with it. (rhnreg_ks --force
> --activationkey=...)
> 
> I suspect there is a bug on the server side: One hint is the fact,
> that the server still expects a md5 checksum instead of a sha-256
> checksum. And I think it must be in the area of migrating from md5
> to sha256 checksums, called by
> "spacewalk/backend/server/handlers/xmlrpc/registration.py":
> upgrade_version() Before the introduction of sha256 checksums it
> worked. I found an older SLES client, which was upgraded from 11.2
> to 11.3 in Q3/2013, here everything was still working well
> (everything with md5): diff systemid systemid.save 22c22 <
> <value><string>513e830b5aa37f50d0f1c3fdc6312415</string></value> 
> ---
>> <value><string>6c4bebef36330a62466c00bcaf994be7</string></value>
> 34c34 < <value><string>x86_64-redhat-linux</string></value> ---
>> <value><string>x86_64</string></value>
> 38c38 < <value><string>11.3</string></value> ---
>> <value><string>11.2</string></value>
> 
> 
> Regards, Bernhard
> 
> 
> 
> _______________________________________________ Spacewalk-list
> mailing list Spacewalk-list at redhat.com 
> https://www.redhat.com/mailman/listinfo/spacewalk-list
> 

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJWXT/eAAoJEHxIkeoL34IfsqIH/ROsPkjJEb92p9D+cD0L2QH1
jkKJT9zFnEzhRT2trzdwDPHO33XrYfI9gmMyIKR7OXIvU1d1pwzHFM5OAc69lhjz
7dRI2JpFG6QAUIm8ghq73Ez3on7wJz0xWwTme5dmOtIWlbBhPcpl+DQalSoIXt1G
oQ+LqqUMMKMCdhFha4ItCYG9+uICYg3b3+vODqe/ZAqRyo2cANovePdrYbD2eyx3
5RTUd6gBCqOmpX0A1lTUL7llILSf88Os0ieh1m4jBp/+1pHiGzwJFMfxWwvL/1D8
2hGAqOUCVJckzWnbLb3Xd1V7Wv8RdmDwTUAlxWEHcfo1iTBGA6O12FxzgRpwVnQ=
=XQqZ
-----END PGP SIGNATURE-----

_______________________________________________
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/20151201/43c7ba2b/attachment.htm>