Red Hat Bugzilla – Bug 1011972
proxy host setting ignored
Last modified: 2013-10-09 16:52:37 EDT
Description of problem:
When using the new 2.2 style proxy settings, no proxy seems to be used by the sync task. The rpm create repo functions correct, but the sync run keeps downloading - hanging forever. While the pulp.log shows a python stack-trace.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. pulp-admin rpm repo create \
2. pulp-admin rpm repo sync run --repo-id=repo123
2013-09-25 14:59:11,346 nectar.downloaders.threaded:ERROR: Unhandled Exception in Worker Thread 
Traceback (most recent call last):
File "/usr/lib/python2.6/site-packages/nectar/downloaders/threaded.py", line 92, in worker
session = build_session(self.config)
File "/usr/lib/python2.6/site-packages/nectar/downloaders/threaded.py", line 281, in build_session
File "/usr/lib/python2.6/site-packages/nectar/downloaders/threaded.py", line 310, in _add_proxy
url = ':'.join((host, str(config.proxy_port)))
TypeError: sequence item 0: expected string, NoneType found
transfer of (any) repository to this pulp repo.
The same repo-sync command (with 2.1 command style) is working fine.
The bug is a semantic one, the --proxy-host requires the scheme (ie http:// or https://)
True, the documentation also mentions to include the scheme. But, when specifying the proxy with the scheme the results are somewhat the same:\
# Adding a repo:
pulp-admin rpm repo create \
--repo-id=rhel-6-server --retain-old-count=1 \
--serve-http=true --serve-https=false \
--proxy-host=http://www-proxy.dev.example.com --proxy-port=8082 \
# Results of running a sync in pulp.log
2013-09-24 10:02:47,181 nectar.downloaders.threaded:ERROR: [Errno -2] Name or service not known
Traceback (most recent call last):
File "/usr/lib/python2.6/site-packages/nectar/downloaders/threaded.py", line 160, in _fetch
response = session.get(request.url, headers=headers)
File "/usr/lib/python2.6/site-packages/requests/sessions.py", line 310, in get
return self.request('GET', url, **kwargs)
File "/usr/lib/python2.6/site-packages/requests/sessions.py", line 279, in request
resp = self.send(prep, stream=stream, timeout=timeout, verify=verify, cert=cert, proxies=proxies)
File "/usr/lib/python2.6/site-packages/requests/sessions.py", line 374, in send
r = adapter.send(request, **kwargs)
File "/usr/lib/python2.6/site-packages/requests/adapters.py", line 206, in send
ConnectionError: [Errno -2] Name or service not known
Maybe it is worth to mention that no DNS resolving of Internet-hosts can be done on the local network. Only the proxyhost can. Eg., "cdn.redhat.com" cannot be resolved by the pulp node, but can be resolved (and reached) by the proxyhost.
A similar host on the same network running pulp 2.1 works as supposed, with the difference that on pulp 2.1 the switch --proxy-url is used (changed with pulp2.2).
I suggest the severity and priority can be upped with information from the previous comment?
bumping this to high priority on 2.3 so we can at least try reproducing it locally.
Did another setup with pulp 2.2 and a squid http-proxy. Proxy support seems definitely broken in pulp 2.2.
I got it to work by patching 'threaded.py' with the patch below. This makes it possible to use a proxy-host (/w scheme suffix) .. downside is that it only works with feeds over http. Feeds over https respond with a "bad request".
--- threaded.py 2013-09-27 19:58:37.922115101 +0000
+++ threaded.py.me 2013-09-27 21:05:49.889114884 +0000
@@ -314,7 +314,7 @@
auth = config.proxy_username + password_part
url = '@'.join((auth, url))
- session.proxies[protocol] = url
+ session.proxies['http'] = '://'.join((protocol, url))
# -- thread-safe generator queue -----------------------------------------------
Hope this is of any help.
This issue was fixed in nectar, but that fix is not available in the 2.2 repository. We are going to update python-nectar in the 2.2 repo, which should take care of this.
Rebuilt to include nectar-1.1.2-1 in: http://repos.fedorapeople.org/repos/pulp/pulp/beta/2.2/
*** This bug has been marked as a duplicate of bug 1014368 ***