RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 652424 - useNoSSLForPackages fails
Summary: useNoSSLForPackages fails
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: yum-rhn-plugin
Version: 6.0
Hardware: Unspecified
OS: Unspecified
low
medium
Target Milestone: rc
: ---
Assignee: Miroslav Suchý
QA Contact: Martin Minar
URL:
Whiteboard:
Depends On:
Blocks: 745615
TreeView+ depends on / blocked
 
Reported: 2010-11-11 20:22 UTC by Chris Adams
Modified: 2016-07-04 00:55 UTC (History)
7 users (show)

Fixed In Version: rhn-client-tools-1.0.0-42 yum-rhn-plugin-0.9.1-9
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 745615 (view as bug list)
Environment:
Last Closed: 2011-05-19 13:05:21 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:0565 0 normal SHIPPED_LIVE rhn-client-tools and yum-rhn-plugin bug fix and ehnancement update 2011-05-18 17:57:10 UTC

Description Chris Adams 2010-11-11 20:22:17 UTC
Setting useNoSSLForPackages=1 in /etc/sysconfig/rhn/up2date fails (as in a setup with a proxy that will cache packages to save bandwidth and speed up updates).  Something is apparently still trying to valid an SSL cert:

[root@rhel6 rhn]# yum clean all
Loaded plugins: rhnplugin
Cleaning up Everything
[root@rhel6 rhn]# yum list updates
Loaded plugins: rhnplugin
rhel-x86_64-server-6                                     | 1.8 kB     00:00     
Error: failed to retrieve repodata/6faecb305efb123bd886342dd108b407fc2b14ace71b46e66a675209e97da51a-primary.xml.gz from rhel-x86_64-server-6
error was [Errno 14] Peer cert cannot be verified or peer cert invalid

Comment 2 Tomas Hoger 2010-11-16 17:15:58 UTC
Can you clarify your configuration a bit?  Is that http or https proxy, configured as httpProxy?

Comment 3 Chris Adams 2010-11-16 17:24:51 UTC
I'm using an HTTP proxy like:

enableProxy=1
enableProxyAuth=1
httpProxy=http://serverfqdn:3128
proxyUser=foo
proxyPassword=bar

However, I reproduced the useNoSSLForPackages=1 problem without a proxy set at all as well.

Comment 4 Jan Pazdziora 2010-11-23 13:29:29 UTC
When I run yum list updates on RHEL 6 system registered to RHN, with no proxy, with

rhn-client-tools-1.0.0-38.el6.noarch
yum-rhn-plugin-0.9.1-5.el6.noarch

I get traceback

# yum list updates
Loaded plugins: rhnplugin
Traceback (most recent call last):
  File "/usr/bin/yum", line 29, in <module>
    yummain.user_main(sys.argv[1:], exit_code=True)
  File "/usr/share/yum-cli/yummain.py", line 254, in user_main
    errcode = main(args)
  File "/usr/share/yum-cli/yummain.py", line 88, in main
    base.getOptionsConfig(args)
  File "/usr/share/yum-cli/cli.py", line 192, in getOptionsConfig
    self.conf
  File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 778, in <lambda>
    conf = property(fget=lambda self: self._getConfig(),
  File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 311, in _getConfig
    self.plugins.run('init')
  File "/usr/lib/python2.6/site-packages/yum/plugins.py", line 179, in run
    func(conduitcls(self, self.base, conf, **kwargs))
  File "/usr/share/yum-plugins/rhnplugin.py", line 117, in init_hook
    login_info = up2dateAuth.getLoginInfo()
  File "/usr/share/rhn/up2date_client/up2dateAuth.py", line 219, in getLoginInfo
    login()
  File "/usr/share/rhn/up2date_client/up2dateAuth.py", line 186, in login
    li = server.up2date.login(systemId)
  File "/usr/share/rhn/up2date_client/rhnserver.py", line 64, in __call__
    raise up2dateErrors.SSLCertificateVerifyFailedError()
up2date_client.up2dateErrors.SSLCertificateVerifyFailedError: The SSL certificate failed verification.

Comment 5 Jan Pazdziora 2010-11-23 13:30:28 UTC
When I however have correct certificate and set the option

useNoSSLForPackages=1

I can see what OP reported:

# yum clean all
Loaded plugins: rhnplugin
Cleaning up Everything
# yum list updates
Loaded plugins: rhnplugin
rhel-i386-server-6                                       | 1.8 kB     00:00     
Error: failed to retrieve repodata/08277a7eb7d631565a722898328acc33bbb86f4dcd7af3c0e7d6fca0f5d2be41-primary.xml.gz from rhel-i386-server-6
error was [Errno 14] Peer cert cannot be verified or peer cert invalid
#

Comment 6 Jan Pazdziora 2010-11-23 13:31:24 UTC
Looking at tcpdump, I suspect the problem happens somewhere around the redirect to Akamai when (after a series of http communications) there's https again.

Setting devel_ack.

Comment 7 Tomas Hoger 2010-11-23 14:49:45 UTC
Is useNoSSLForPackages option supposed to force https -> http change for repository meta data downloads?

Comment 8 Jan Pazdziora 2010-11-23 15:14:16 UTC
Setting devel ack back.

Comment 9 Jan Pazdziora 2010-11-23 15:15:43 UTC
(In reply to comment #7)
> Is useNoSSLForPackages option supposed to force https -> http change for
> repository meta data downloads?

We have no manual entry for that option but grep shows

   dont use ssl to download packages

and

   Use the noSSLServerURL for package, package list, and header fetching

as descriptions of the feature.

Comment 10 Jan Pazdziora 2010-11-23 15:17:29 UTC
(In reply to comment #9)
> 
> and
> 
>    Use the noSSLServerURL for package, package list, and header fetching
> 
> as descriptions of the feature.

And the truth is, I did not have noSSLServerURL set at all when I've tried this.

Comment 11 Tomas Hoger 2010-11-23 17:19:31 UTC
With the lacking documentation, I guessed its intended purpose too.  My guess was it's supposed to avoid SSL / encryption overhead on transfers of data that is cryptographically protected already (GPG signed RPM packages).  Hence I assumed it's not intended to un-https repository meta data downloads.

Comment 12 Chris Adams 2010-11-23 19:30:50 UTC
Hm, I've only used useNoSSLForPackages, not noSSLServerURL.  On my RHEL 4 servers, noSSLServerURL is automatically set, but I don't see it in my RHEL 5 or RHEL 6 /etc/sysconfig/rhn/up2date configs.  I did try setting it to http://xmlrpc.rhn.redhat.com/XMLRPC (e.g. the normal URL with http instead of https), and I still got an error.

Okay, if I turn off "Supports Location-Aware update access" in RHN for this system, useNoSSLForPackages=1 (without noSSLServerURL set) works.  With that enabled, the redirect to Akamai comes back as https.  The RHN plugin tries it, but then goes back and asks the regular RHN server for the same thing again on HTTP (and fails after several tries).  I guess something gets confused about the http->https redirect.

With that RHN setting turned off, it never gets redirected, downloads something (metadata?) over HTTPS from xmlrpc.rhn.redhat.com, and seems to work.

I tried fetching the ...-primary.xml.gz from the Akamai server without HTTP, and that gives a 404 (so they separate HTTP and HTTPS I guess).

Weird; I wonder how this is working on RHEL 5.

Comment 18 Tomas Hoger 2010-12-09 11:48:17 UTC
Chris, what is your motivation for using useNoSSLForPackages?  As noted above, RHN redirects to CDN URL is always https currently and CDN host will not provide the content if that URL is changed to http.  So even if this yum-rhn-plugin bug is fixed to handle http->https redirect correctly, package downloads are going to use https, which may not be what you expect.  What are your fix expectations?

Comment 19 Tomas Hoger 2010-12-09 11:50:14 UTC
Mirek, while looking into this, can you check if it metadata downloads can easily be exclude from useNoSSLForPackages https stripping as discussed above?  Thank you!

Comment 20 Chris Adams 2010-12-09 14:58:39 UTC
I was using useNoSSLForPackages, along with proxy settings pointing at a Squid server, to cache the main downloads from RHN.  This did several things:

- sped up updates of multiple similar servers when RHN was under load (like right after a RHEL update); this should be a non-issue with RHN Akamaized (although it doesn't come through my local Akamai server set)

- saved a little local bandwidth (not really an issue for my servers)

- allowed me to manage bandwidth for colocated customer servers I managed (some of them pay for only a little bandwidth, but I could exempt the proxy server from the bandwidth controls so downloading updates didn't take a long time)

I guess all of those could also be addressed with a satellite server, but I don't really have enough servers to justify the additional cost at this time.

I didn't realize that when RHN was Akamaized, useNoSSLForPackages stopped with the yum plugin already (if you have the default RHN setting to allow Akamai).  It looks like on RHEL 5, useNoSSLForPackages just gets ignored (it still fetches the package from Akamai via https).

I guess I need to re-think my setup.  Maybe the solution for the yum plugin is to just ignore useNoSSLForPackages (or punt it out as an error).

Comment 21 Jan Hutař 2010-12-11 20:16:00 UTC
So can we interpret this as:

With Akamai (Location aware) enabled on RHN: useNoSSLForPackages=1 should work as expected.

With Akamai disabled: useNoSSLForPackages=1 should be ignored and/or warning should be printed.

Am I right?

Thanks for answers.

Comment 22 Tomas Hoger 2010-12-13 09:46:01 UTC
(In reply to comment #21)
> With Akamai (Location aware) enabled on RHN: useNoSSLForPackages=1 should work
> as expected.
> 
> With Akamai disabled: useNoSSLForPackages=1 should be ignored and/or warning
> should be printed.
> 
> Am I right?

Those two cases are mixed up.  Akamai does not serve content over http now.  So in the akamai + useNoSSLForPackages=1 case, rhn-plugin can either handle http -> https redirect correctly and (silently?) download packages over https, or ignore useNoSSLForPackages=1 with a warning (if it has a way to check if location aware downloads are enabled on RHN).

Let me know if I should file separate bug for "exclude meta data downloads from useNoSSLForPackages" issue.

Comment 23 Chris Adams 2010-12-13 14:47:29 UTC
(In reply to comment #21)

You have it backwards:

> With Akamai (Location aware) enabled on RHN: useNoSSLForPackages=1 should work
> as expected.

useNoSSLForPackages can't work with Akamai, because Akamai doesn't serve the packages over HTTP.  The only way for this to work would be one of the following:

- have the client "know" the Akamai URLs and either de-Akamaize them (and then use HTTP) or ignore the useNoSSLForPackages setting
- have the useNoSSLForPackages setting sent by the client to RHN somehow (and then RHN automatically disable Akamai for package requests)
- RHN Akamai config set to allow HTTP for .rpm requests

> With Akamai disabled: useNoSSLForPackages=1 should be ignored and/or warning
> should be printed.

useNoSSLForPackages works today with Akamai disabled on RHN; there no need for any change in that case.

Comment 24 Jan Hutař 2010-12-14 13:42:32 UTC
Sorry, you are right, I have mixed the cases, it should be:

> With Akamai (Location aware) enabled on RHN: useNoSSLForPackages=1 should
>   be ignored and/or warning should be printed.
>
> With Akamai disabled: useNoSSLForPackages=1 should work as expected.

I'm just trying to understand what should be fixed in this bug.

Regards,
Jan

Comment 25 Jan Hutař 2010-12-14 13:44:49 UTC
Comment #23 specifies objective of this bug.

Comment 26 Miroslav Suchý 2011-01-12 13:43:46 UTC
The options useNoSSLForPackages has been removed from /etc/sysconfig/rhn/up2date in:
https://bugzilla.redhat.com/show_bug.cgi?id=212020
in svn revision:
105110

This was little premature. It was ok to remove  noSSLServerURL, but no useNoSSLForPackages as we still use it in our code.

I returned this option back. And since Akamai does not support https protocol I forced to switch of use "Location aware updates" when you set useNoSSLForPackages option.

Commited to spacewalk.git as commits:
fd0fe381ea19c06948ab1989175ce6c82d898338
1f270bb46160bcada7d34c4d03ef6c80f100bb50
4d1256d24e4c8e4648d1b2431706325c14f8c8b8

Comment 27 Miroslav Suchý 2011-01-12 13:45:34 UTC
cherrypicked to satellite.git as commits:
9798d6e4b300878958bf6ca6366bbc2b027ccc87
2e0a6bcff01e7e509dd63e996882efafe0156d9f
13c60ceb481bd4bb4c4273dd27d16277e9b91647

Comment 28 Tomas Hoger 2011-01-12 13:57:36 UTC
With these changes, are repository metadata downloads still performed over http when useNoSSLForPackages=1?

Comment 29 Miroslav Suchý 2011-01-12 14:08:48 UTC
Yes. Repository metadata download are downloaded over http when useNoSSLForPackages=1

Comment 31 Martin Minar 2011-02-22 15:33:41 UTC
Verified with rhn-client-tools-1.0.0-48.el6.noarch and yum-rhn-plugin-0.9.1-15.el6.noarch.

Comment 32 errata-xmlrpc 2011-05-19 13:05:21 UTC
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-2011-0565.html


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