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@swr.de swr.de Von: Bernd Helber <bernd@helber-it-services.com> An: spacewalk-list@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@redhat.com <hr noshade> <tt>-----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 </tt><a href=http://download.opensuse.org/repositories/systemsmanagement:/spacewalk:/><tt>http://download.opensuse.org/repositories/systemsmanagement:/spacewalk:/</tt></a><tt> 2.2/SLE_11_SP3/ </tt><a href="https://www.redhat.com/archives/spacewalk-list/2015-August/msg00077.html"><tt>https://www.redhat.com/archives/spacewalk-list/2015-August/msg00077.html</tt></a><tt> 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@redhat.com > </tt><a href="https://www.redhat.com/mailman/listinfo/spacewalk-list"><tt>https://www.redhat.com/mailman/listinfo/spacewalk-list</tt></a><tt> > -----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@redhat.com </tt><a href="https://www.redhat.com/mailman/listinfo/spacewalk-list"><tt>https://www.redhat.com/mailman/listinfo/spacewalk-list</tt></a><tt> </tt>