Hide Forgot
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.
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
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.
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
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.
We have issues with this bug, problem is not in katello-bootstrap but in the python libs, please advice when fixed.
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.
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.
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!
Please revisit the fix for this bug since it appears to have introduced a regression shown in bug 1546351
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.
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