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 1483438 - A RHEL-7.4 client host cannot be registered to the Satellite server through a proxy server using bootstrap script.
Summary: A RHEL-7.4 client host cannot be registered to the Satellite server through a...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: python
Version: 7.4
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: pre-dev-freeze
: ---
Assignee: Tomas Orsava
QA Contact: Mirek Długosz
Petr Bokoc
URL:
Whiteboard:
Depends On:
Blocks: 1545295
TreeView+ depends on / blocked
 
Reported: 2017-08-21 06:45 UTC by Jayant Bhatia
Modified: 2021-06-10 12:51 UTC (History)
20 users (show)

Fixed In Version: python-2.7.5-68.el7
Doc Type: Bug Fix
Doc Text:
Python scripts can now correctly connect to HTTPS servers through a proxy, while explicitly setting the port The Python standard library provided in Red Hat Enterprise Linux was previously updated to enable certificate verification by default. However, a bug prevented Python scripts using the standard library from connecting to HTTPS servers using a proxy when explicitly setting the port to connect to. The same bug also prevented users from using the bootstrap script for registration with Red Hat Satellite 6 through a proxy. This bug is now fixed, and scripts can now connect to HTTPS servers and register using Red Hat Satellite as expected.
Clone Of:
Environment:
Last Closed: 2018-04-10 15:00:08 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Patch for python 2.7 httplib when using proxies. (2.04 KB, patch)
2017-10-18 21:56 UTC, Jason Smith 		no flags Details | Diff
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1546351 0 unspecified CLOSED A RHEL-7.5 client host cannot rhnreg_ks to a Satellite 5 server through a proxy 2021-02-22 00:41:40 UTC
Red Hat Product Errata RHBA-2018:0833 0 None None None 2018-04-10 15:00:55 UTC

Internal Links: 1546351

Description Jayant Bhatia 2017-08-21 06:45:16 UTC 
Description of problem:

Registering a RHEL-7.4 client host to the Satellite server through a proxy server, using the katello-client-bootstrap python script fails with following error:

FATAL Error - hostname 'xyz.example.com:443' doesn't match 'xyz.example.com'

How reproducible: (Always)

Steps To Reproduce.

1) Install and configure a fresh RHEL-7.4 machine to be registered with the Satellite server.

2) Configure a proxy server through which the client will be registered with the Satellite.

3) Register the client with the Satellite through a proxy server using the katello-client-bootstrap python script.
 
# bootstrap.py -v -l <login> -p <password> -s <server_fqdn> -o <oranization> -L 'Default Location' -g <host_group> -a <activation_key> -O <operating_system> -P --add-domain --force

Actual results:

The following error is encountered and the client is not registered with the Satellite server.

FATAL Error - hostname 'xyz.example.com:443' doesn't match 'xyz.example.com'

Expected results:

The RHEL 7.4 client should be successfully registered with the Satellite server.
Comment 3 Gary Lamb 2017-10-17 19:34:57 UTC 
Passing along concern/ escalation from customer here - 

"Request Management Escalation: We are starting to install and update more of our servers to RHEL 7.4, and since all of the RHEL satellite tools are written in python they are affected by this proxy tunnelling bug. Also, more and more of our servers on a private 10./8 network which requires a proxy server to reach our Satellite server. I understand not many of your customers are noticing this yet since it only affects software written in python, running on RHEL 7.4, and making http requests through a proxy, but this is starting to become a larger problem for us. I don't understand why this continues to be ignored almost 2 months after the initial report, especially since I found the upstream python bug report that explain this exact problem, that also contained a patch, and even quickly tested a modified version of the patch and attached it to the support case. Can you please run the patch through your QA process, clean it up or modify it as you see fit, and release a patched python package? I hope this can be done soon, especially before 7.5 comes out, so we can register fresh builds of 7.5 to the satellite server. Right now we can't register 7.4 and have to install 7.3 to successfully register."

Hi Bryan - is this on the radar for progression or is there something I can advise the customer? 

Thanks,
Gary
Comment 4 Bryan Kearney 2017-10-17 19:46:27 UTC 
Gary, can you point me at the patch the customer looked at? This appears to be a pyhon library issue which can be controlled at the environment layer.
Comment 6 Jason Smith 2017-10-18 21:56:05 UTC 
Created attachment 1340400 [details]
Patch for python 2.7 httplib when using proxies.

I initially reported this in Support Case 01910999. To summarize, the RHEL 7.4 update to the python package to fix CVE-2014-9365:

https://bugzilla.redhat.com/show_bug.cgi?id=1173041

enabled certificate verification:

https://access.redhat.com/errata/RHSA-2017:1868

I believe this change exposed this old python 2.7 bug when going through a proxy server:

https://bugs.python.org/issue24311

I took the patch in the above python bug report and quickly hacked/modified it so it would apply against the RHEL 7.4 python package, see attached, and tested it. It does appear to fix the problem without having to disable cert verification which the update enabled to fix the CVE.

As I explained before, since the satellite tools are written in python, and we have a lot of RHEL hosts that are on a private 10./8 network, we need to go through a proxy server that we setup in order to reach our satellite server. After we upgraded systems to 7.4, or if we try to install a new 7.4 system, we are unable to run the bootstrap script:

https://github.com/Katello/katello-client-bootstrap

to register our systems to our satellite server. I hope this helps. Let me know if you need anymore information.

Thanks,
~Jason
Comment 7 Johan Bergström 2018-01-09 09:59:44 UTC 
I've also hit this bug, the bug/problem is not in katello-bootstrap but in the python libs, please re-direct this bz to the proper team and fix it.
Comment 18 annette.fanto 2018-02-08 20:52:30 UTC 
We have issues with this bug, problem is not in katello-bootstrap but in the python libs, please advice when fixed.
Comment 22 Mirek Długosz 2018-02-14 13:14:01 UTC 
It seems that fix for this bug introduces one regression - using IP address (instead of domain name) in `pip --proxy` raises exception in ssl.py.

That was found during execution of existing Python test set:
Before fix: http://beaker-archive.app.eng.bos.redhat.com/beaker-logs/2018/02/23009/2300933/4790486/67760520/TESTOUT.log
After fix: http://beaker-archive.app.eng.bos.redhat.com/beaker-logs/2018/02/23009/2300929/4790469/67759764/TESTOUT.log

Additionally, I get inconsistent results on 1minutetip machine. It did fail yesterday, but I was not able to reproduce the issue today (meaning `pip --proxy` worked as expected for both IP address and domain name).

We will be investigating what is the real scope of this issue and then decide what next steps regarding this bug report we will take.

Please add any information that might help defining scope of the problem (how often proxies without hostname are used, results of your tests of package after fix etc.) as comment to this bug report.
Thank you.
Comment 24 Johan Bergström 2018-02-14 15:42:11 UTC 
Just a comment on hostname vs ip.

Proxies without hostnames are used very frequently in internal environments where you are running Private networks NAT'ed/proxied to outside without DNS in my infrastructure. 

Forcing the use of DNS on internal networks just to make this work is a bad idea.
Comment 30 Petr Viktorin (pviktori) 2018-02-16 15:53:19 UTC 
I believe this was solved in the python-virtualenv package, which upgrades pip from 1.4.1 (RHEL 7.4) to 9.0.1 (RHEL 7.5).

Will leave this open for Harris to comment when he gets back from PTO on Thursday. But, I don't think we need to do anything here -- except possibly add a Conflicts: to prevent issues on misconfigured "mixed" systems.

But thanks for raising the issue, Mirosław!
Comment 31 John Sefler 2018-02-16 21:02:17 UTC 
Please revisit the fix for this bug since it appears to have introduced a regression shown in bug 1546351
Comment 32 Tomas Orsava 2018-02-19 15:38:30 UTC 
That regression is being dealt with in the abovementioned bug 1546351.

And I'm adding the Conflicts tag with old version of virtualenv (< 15.1.0-1) to avoid problems discovered by Mirosław.
Comment 40 errata-xmlrpc 2018-04-10 15:00:08 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:0833
Note You need to log in before you can comment on or make changes to this bug.