Bug 1483438

Summary: A RHEL-7.4 client host cannot be registered to the Satellite server through a proxy server using bootstrap script.
Product: Red Hat Enterprise Linux 7 Reporter: Jayant Bhatia <jbhatia>
Component: pythonAssignee: Tomas Orsava <torsava>
Status: CLOSED ERRATA QA Contact: Mirek Długosz <mzalewsk>
Severity: medium Docs Contact: Petr Bokoc <pbokoc>
Priority: medium    
Version: 7.4CC: annette.fanto, bbuckingham, bkearney, cstratak, dkutalek, egolov, glamb, herrold, hhorak, jbhatia, jkejda, johan.bergstrom, jreznik, jsefler, lmiksik, mzalewsk, ovasik, pviktori, smithj4, torsava
Target Milestone: pre-dev-freezeKeywords: Patch, Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
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.
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-04-10 15:00:08 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1545295    
Attachments:
Description Flags
Patch for python 2.7 httplib when using proxies. none

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