Bug 385161

This is with the up2date released with RHEL4.6 , which is up2date-4.6.2-7.el4 I
believe.

Please keep in mind the severity of this bug.  Once a sytem installs up2date, it
will cause any subsequent actions to fail and thus prevent the system from
updating.  This is a major regression

On the RHEL4.5 up2date, config.py gets this from the conf file with a trailing ";"

['/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT', '/usr/share/rhn/RHNS-CA-CERT']

That is up2date 4.5.5-7.el4

On the RHEL4.6 up2date, you get:

['/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT', '/usr/share/rhn/RHNS-CA-CERT', '']

from up2date.log file:

[Thu Nov 15 17:05:59 2007] up2date updating login info
[Thu Nov 15 17:05:59 2007] up2date ERROR: can not find RHNS CA file::

so no traceback generated. I am able to replicate this using:

up2date-4.6.2-7.el4

prior version - up2date-4.5.5-7.el4 - did not error out with a ';' added to the
end of the sslCACert config option:

# grep CACert= /etc/sysconfig/rhn/up2date
sslCACert=/usr/share/rhn/RHNS-CA-CERT;
# 

This is the following code that 'broke' this. Manually changing this back to old
version my up2date was then able to work:

--- 45/usr/share/rhn/up2date_client/config.py   2007-11-15 16:56:05.000000000 -0500
+++ 46/usr/share/rhn/up2date_client/config.py   2007-11-15 16:56:15.000000000 -0500
@@ -7,7 +7,7 @@
 #       Cristian Gafton <gafton>
 #       Adrian Likins   <alikins>
 #
-# $Id: config.py 87080 2005-11-04 20:49:52Z alikins $
+# $Id: config.py 119562 2007-08-21 15:32:24Z pkilambi $
 """
 This module includes the Config and Up2date Config classes use by the
 up2date agent to hold config info.
@@ -162,7 +162,7 @@
                elif values[0] == "":
                     value = []
                else:
-                    value = values[:-1]
+                    value = values[:]


Not sure why this was changed, but this is the change that is causing this issue. 

Cliff. 

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

Thanks cliff and Red Hat!

I would hope that Red Hat would consider an immediate errata for this serious
regression to a supported configuration.  This bug causes any system that
applies it (with failover configured) to stop checking into RHN.

Daryl, as per comment #7 - a hotfix has been requested for this issue to address
a specific customers needs, and not a request for Errata. 

The Satellite Engineering team are currently evaluating and developing a hotfix
package to provide to the customer a fixed up2date package to this customer who
requested it. 

Cliff. 

Cliff,

Can we deliver such a package to our customers in a way that makes it available
to the general public? Specifically, I mean in /pub on our proxy server? We
really don't have any direct way to make it available to them otherwise.

Thanks,
John

If the customer is using a RHN Proxy <-> Hosted environment, *and* they have a
commonly deployed GPG key in their environment, then yes. 

Once the hotfix package is provided to the customer, they would test the package
themselves, and once happy, sign it with their GPG key and then use the
rhn-package-manager command for RHN Proxy to upload the hotfix into their RHN
Proxy and associate it within Hosted within their RHN account to a common custom
child channel for their systems. 

Of course, if you already have broken clients, those up2date clients will not be
able to run up2date to pull down the new up2date package, so instructions will
have to be given on how to manually download the package (from say a pub dir) to
install the newer version to get up2date working again. 

Cliff. 

Created attachment 261391 [details]
my hotfix suggestion

Thanks for the help Cliff.  Here is my idea for a HOTFIX package.  I don't
think we can easily place a package in /pub without distributing it to the
world.

Hi - the patch suggested is just going back to the old code behavior, which had
a bug within it - see bugzilla 208442. 

The below code:

[root@rlx-1-12 up2date]# !diff
diff -u 46/usr/share/rhn/up2date_client/config.py
/usr/share/rhn/up2date_client/config.py
--- 46/usr/share/rhn/up2date_client/config.py   2007-11-15 16:56:15.000000000 -0500
+++ /usr/share/rhn/up2date_client/config.py     2007-11-16 12:31:20.000000000 -0500
@@ -161,6 +161,8 @@
                        pass
                elif values[0] == "":
                     value = []
+                elif values[-1] == "":
+                    value = values[:-1]
                else:
                     value = values[:]
 
[root@rlx-1-12 up2date]# 

I have tested seems to run without any obvious errors and addresses both this
bug and bug 208442.

The bug we was fixing was to allow for white space between config values:

serverURL=https://xmlrpc.rhn.redhat.com/XMLRPC; https://wibble.redhat.com/XMLRPC

the old code though correctly chop off the empty value created by the split over
';'. The above change looks to see if the last value is empty, and if so remove it. 

Can you test and see if this works for you? I am not certain is server fail over
works with multiple sslCACerts, but it no longer throws an error with a ';' at
the end of a single entry and both URLs listed within serverURL and
noSSLServerURL get parsed correctly and passed along in the code for future usage. 

Cliff. 

Thanks,
Cliff. 

Hi Cliff,

Thanks for your help.  That works here.

daryl

This bugzilla has Keywords: Regression.  

Since no regressions are allowed between releases, 
it is also being proposed as a blocker for this release.  

Please resolve ASAP.

With this bz in regression status, can we expect an errata anytime soon?  thanks

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2008-0771.html