Red Hat Bugzilla – Bug 589132
File scheme breaks with proxy environment vars set
Last modified: 2014-01-21 01:17:33 EST
Description of problem:
Import of GPG keys fail with the first yum call if certain proxy environment vars are set.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Make sure you are using http scheme in your repos (RHEL6 defaults to ftp), like
2. Set proxy vars:
3. yum clean all
4. rpm -e gpg-pubkey-f21541eb-4a5233e7
5. rpm -e xterm
6. yum install xterm
GPG key retrieval failed: [Errno 14] Unknown Error: URL=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-beta-2 , scheme=file
The GPG key should install as well as the xterm package
Calling "yum install xterm" a second time makes it install without error.
It's also seems that it only happens with more than one environment var. We set a number of vars for a number of different tools and that's where yum has a problem. If only http_proxy is set then it works.
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release. Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release. This request is not yet committed for
I'm going to move this to curl, as IIRC yum and urlgrabber don't do anything with the env. vars.
Please provide a (lib)curl based minimal example. I have really no idea what '[Errno 14] Unknown Error' means and how to debug yum. I've been playing with that variables using curl(1) and they seemed to work as documented:
if you want to get debug output from urlgrabber (which is what yum uses) then just set URLGRABBER_DEBUG=1
on the shell and run the command, you'll get detailed results.
Also - if you want the error codes from urlgrabber to be better then I'd ask you to improve those in pycurl.
Simon, please run yum with the environment variable URLGRABBER_DEBUG set to 1 as Seth suggests and attach the verbose output to this bug. I'll have a look. Thanks!
(In reply to comment #5)
> Also - if you want the error codes from urlgrabber to be better then I'd ask
> you to improve those in pycurl.
You're probably asking at wrong place. I've never used the python binding myself and can't speak python. I can imagine some people which would do this job better than me ;-)
Kamil, could you try to reproduce this on a machine in your environment? Would be really nice because I don't have the box anymore where I have made the RHEL6 beta installation and I can't just do it again for now.
Simon, if you're not able to reproduce it, I doubt anybody else is. The steps to reproduce are a bit vague. I can of course give it a try, but need at least some more info from you:
1. NVR of libcurl
2. What exactly did you change in yum's configuration?
3. Is "http://proxy:8080" a working proxy? If so, where is it placed? What software is running in there?
Kamil, you should be able to reproduce it without problems. I have spent hours [ yes really :) ] to find out how exactly it fails. Because usually when something fails that way you just try it again - and in this case it works then - and forget about it.
All versions of the software are the packages from RHEL6 beta1.
For your questions:
1) This libcurl was used
2) I don't have the yum config anymore but I know I have only changed the repo file of the base repo to use http instead of ftp scheme, like so
no other changes have been made to yum config. Also no proxy has been set on yum.conf because we have all our proxy settings in env vars.
3) That's correct, "http://proxy:8080" is our inhouse working proxy (which is why the name is not FQDN). It's placed in one of our internal RFC918 networks, clients do not have any direct internet connection, they can only use the proxy. The proxy is running squid on EL4 in a quite standard configuration.
The problem doesn't show up with downloading rpm packages or yum metadata but only with the initial import of the GPG key which happens automatically.
I think you should be able to reproduce the issue even with no running proxy available by just doing the steps 1 to 6 as described in the how to reproduce section.
Indeed, I can reproduce it independently on yum:
$ all_proxy="http://proxy:8080" curl file:///etc/yum.conf
curl: (5) Couldn't resolve proxy 'proxy'
It's a bug, which was fixed in libcurl-7.20.0:
I'll prepare a backport...
Created attachment 424720 [details]
backport of upstream commit 3111701c38ee4d15df8e
still not perfect, test1101 is broken by the patch:
Created attachment 424777 [details]
backport of upstream commit 7603a29fc3db05d354b5
With both patches applied, the test-suite runs fine, including the new test-case 1106. The test from comment #10 still works.
curl-7.19.7-11.fc12 has been submitted as an update for Fedora 12.
built as curl-7.19.7-15.el6
Red Hat Enterprise Linux Beta 2 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.
curl-7.20.1-3.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
curl-7.19.7-12.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.