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

[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>6abe16dcad7c7fe65b75a053cfade1de905832d74f0342d3f8132c41a25f63cc</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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5031 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20151130/fece068e/attachment.p7s>