Bug 385161 - trailing ";" with sslCACert causes up2date breakage on failover setup
trailing ";" with sslCACert causes up2date breakage on failover setup
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: up2date (Show other bugs)
4.6
All Linux
urgent Severity urgent
: rc
: ---
Assigned To: Pradeep Kilambi
Jan Hutař
GSSApproved ResolvedBy=12/31/2007
: ZStream
Depends On:
Blocks: 404871
  Show dependency treegraph
 
Reported: 2007-11-15 13:14 EST by daryl herzmann
Modified: 2010-10-22 16:29 EDT (History)
4 users (show)

See Also:
Fixed In Version: RHBA-2008-0771
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-07-24 16:05:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
my hotfix suggestion (808 bytes, text/plain)
2007-11-16 11:00 EST, daryl herzmann
no flags Details

  None (edit)
Description daryl herzmann 2007-11-15 13:14:35 EST
The up2date released in RHEL4.6 broke our failover setup.  Poking at the code,
the failure results when there is a trailing ";" at the end of noSSLServerURL,
serverURL, and sslCACert

For example, with a trailing ";" on sslCACert, up2date bombs out with:

# up2date -l
ERROR: can not find RHNS CA file:: 

printing out what it gets from the config file we see:

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

Removing the trailing ";" will at least allow up2date to work.
Comment 1 daryl herzmann 2007-11-15 13:56:45 EST
This is with the up2date released with RHEL4.6 , which is up2date-4.6.2-7.el4 I
believe.
Comment 2 daryl herzmann 2007-11-15 14:06:43 EST
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
Comment 3 daryl herzmann 2007-11-15 14:14:13 EST
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', '']
Comment 5 Clifford Perry 2007-11-15 17:40:52 EST
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@redhat.com>
 #       Adrian Likins   <alikins@redhat.com>
 #
-# $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. 
Comment 7 RHEL Product and Program Management 2007-11-15 18:34:23 EST
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.
Comment 9 daryl herzmann 2007-11-16 09:48:27 EST
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.
Comment 11 Clifford Perry 2007-11-16 10:21:16 EST
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. 
Comment 12 John T. Rose 2007-11-16 10:31:04 EST
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
Comment 13 Clifford Perry 2007-11-16 10:44:52 EST
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. 
Comment 14 daryl herzmann 2007-11-16 11:00:39 EST
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.
Comment 15 Clifford Perry 2007-11-16 12:42:44 EST
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. 
Comment 16 daryl herzmann 2007-11-16 12:49:11 EST
Hi Cliff,

Thanks for your help.  That works here.

daryl
Comment 18 RHEL Product and Program Management 2007-11-19 14:45:26 EST
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.
Comment 24 daryl herzmann 2007-11-27 14:54:53 EST
With this bz in regression status, can we expect an errata anytime soon?  thanks
Comment 35 errata-xmlrpc 2008-07-24 16:05:26 EDT
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

Note You need to log in before you can comment on or make changes to this bug.