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

2015-11-30 Thread Robert Paschedag 
I'm pretty sure, I already tried to upgrade from SP3 to SP4 without a problem 
and I'm also pretty sure, that I was able to do further installations after 
that.

But that was on spacewalk 2.2. I'll test this tomorrow with my new spacewalk 
2.4 server.

Regards
Robert
Am 30.11.2015 1:08 nachm. 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(110119,) 
> 2015/11/27 15:29:44 +02:00 21394 CLIENT_IP: 
> xmlrpc/up2date.listChannels(110119,) 
> 2015/11/27 15:29:44 +02:00 21413 CLIENT_IP: 
> xmlrpc/registration.upgrade_version(110119, '11.4') 
> 2015/11/27 15:29:44 +02:00 21387 CLIENT_IP: xmlrpc/up2date.login(110119,) 
> 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 
> < 3902bcae3cabf243bd50afb108ee58a0 
> --- 
> > 6abe16dcad7c7fe65b75a053cfade1de905832d74f0342d3f8132c41a25f63cc
> >  
> 34c34 
> < x86_64 
> --- 
> > x86_64-redhat-linux 
> 38c38 
> < 11.3 
> --- 
> > 11.4 
>
> 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 
> < 513e830b5aa37f50d0f1c3fdc6312415 
> --- 
> > 6c4bebef36330a62466c00bcaf994be7 
> 34c34 
> < x86_64-redhat-linux 
> --- 
> > x86_64 
> 38c38 
> < 11.3 
> --- 
> > 11.2 
>
>
> Regards, 
> Bernhard
> ___ 
> Spacewalk-list mailing list 
> Spacewalk-list@redhat.com 
> https://www.redhat.com/mailman/listinfo/spacewalk-list

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

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

2015-11-30 Thread Bernd Helber 
-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(110119,) 2015/11/27 15:29:44 +02:00
> 21394 CLIENT_IP: xmlrpc/up2date.listChannels(110119,) 
> 2015/11/27 15:29:44 +02:00 21413 CLIENT_IP:
> xmlrpc/registration.upgrade_version(110119, '11.4') 2015/11/27
> 15:29:44 +02:00 21387 CLIENT_IP: xmlrpc/up2date.login(110119,) 
> 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 <
> 3902bcae3cabf243bd50afb108ee58a0 
> ---
>> 6abe16dcad7c7fe65b75a053cfade1de905832d74f0342d3f8132c
41a25f63cc
>
>> 
34c34
> < x86_64 ---
>> x86_64-redhat-linux
> 38c38 < 11.3 ---
>> 11.4
> 
> 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 <
> 513e830b5aa37f50d0f1c3fdc6312415 
> ---
>> 6c4bebef36330a62466c00bcaf994be7
> 34c34 < x86_64-redhat-linux ---
>> x86_64
> 38c38 < 11.3 ---
>> 11.2
> 
> 
> Regards, Bernhard
> 
> 
> 
> ___ Spacewalk-list
> mailing list Spacewalk-list@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@redhat.com

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

2015-11-30 Thread 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(110119,)
2015/11/27 15:29:44 +02:00 21394 CLIENT_IP: 
xmlrpc/up2date.listChannels(110119,)
2015/11/27 15:29:44 +02:00 21413 CLIENT_IP: 
xmlrpc/registration.upgrade_version(110119, '11.4')
2015/11/27 15:29:44 +02:00 21387 CLIENT_IP: xmlrpc/up2date.login(110119,)
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
< 3902bcae3cabf243bd50afb108ee58a0
---
> 6abe16dcad7c7fe65b75a053cfade1de905832d74f0342d3f8132c41a25f63cc
34c34
< x86_64
---
> x86_64-redhat-linux
38c38
< 11.3
---
> 11.4

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
< 513e830b5aa37f50d0f1c3fdc6312415
---
> 6c4bebef36330a62466c00bcaf994be7
34c34
< x86_64-redhat-linux
---
> x86_64
38c38
< 11.3
---
> 11.2


Regards,
Bernhard

smime.p7s
Description: S/MIME cryptographic signature
___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list