Bug 1163613

I have a theory about why this occurs:

From URLgrabber's definition of the 'proxies' keyword argument:

proxies = None
 
    a dictionary that maps protocol schemes to proxy hosts. For
    example, to use a proxy server on host "foo" port 3128 for http
    and https URLs:
      proxies={ 'http' : 'http://foo:3128', 'https' : 'http://foo:3128' }
    note that proxy authentication information may be provided using
    normal URL constructs:
      proxies={ 'http' : 'http://user:host@foo:3128' }
    Lastly, if proxies is None, the default environment settings will
    be used.

The code in rhnplugin.py contains this fragment:

    proxy_dict = {}
    try:
        proxy_url = get_proxy_url(up2date_cfg)
        if proxy_url:
            proxy_url = proxy_url.encode(locale.getpreferredencoding())
            if up2date_cfg['useNoSSLForPackages']:
                proxy_dict = {'http' : proxy_url}
            else:
                proxy_dict = {'https' : proxy_url}

Passing an empty dictionary is not treated as 'None' - so instead of 'the default environment settings [being] used', we get 'use no proxies at all and go directly'.

This would explain why the problem occurs even if the proxy is set in the environment.

Still examining the code to test this hypothesis.

I'm not so sure of the above hypothesis, but my research continues.  The two main methods of getting information for this are:

strace -e trace=connect yum install ${package}

env URLGRABBER_DEBUG=1 yum install ${package} 2> /tmp/urlgrabber.log

OK, I've got a bit of progress.

On the non-working systems, the 'proxies' dict in the URLgrabber structure has the proxy recorded under the 'HTTPS' key.  No idea why that's upper case, except maybe:

spacewalk/client/rhel/yum-rhn-plugin/rhnplugin.py:83:
            proxy_url = proxy_url.encode(locale.getpreferredencoding())

On my test RHEL 7 system that isn't using the RHN plugin, the proxies dict gets the proxy information in the 'http', 'https', and 'ftp' keys.

I'm currently testing commenting out the proxy information in the /etc/sysconfig/rhn/up2date file, putting the proxy information in the /etc/yum.conf file, and seeing if that fixes things.

Hope this helps,

Paul

Customer posted:

"[root@extlin7 ~]# export http_proxy=1.10.100.1
[root@extlin7 ~]# env | grep -i proxy
http_proxy=1.10.100.1
[root@extlin7 ~]# strace -o /tmp/strace.yum -s 99999  yum upgrade
Plugin "product-id" can't be imported
Loaded plugins: langpacks, rhnplugin
There was an error communicating with RHN.
Red Hat Satellite or RHN Classic support will be disabled.
Error communicating with server. The message was:
Unable to connect to the host and port specified
There are no enabled repos.
 Run "yum repolist all" to see the repos you have.
 You can enable repos with yum-config-manager --enable <repo>
[root@extlin7 ~]# grep 1\.10\.100\.1 /tmp/strace.yum 
[root@extlin7 ~]#


I also tried a fresh install of RHEL7... and run into the same problem..."

Thanks for that Peter.

I'm not sure what the intended behaviour of yum is with a proxy set in the environment but not in the /etc/yum.conf.

Situations we've tested so far:

A) setting proxy in /etc/yum.conf and /etc/sysconfig/rhn/up2date
B) setting proxy in /etc/yum.conf, /etc/sysconfig/rhn/up2date and environment
C) setting proxy only in /etc/yum.conf
D) setting proxy only in environment

All of these fail to go through the proxy for some critical requests.  A and B seem to use the proxy for some requests but not others.

In situation B we see the proxy dict with one entry: 'HTTPS': 'proxy.dns.name:port'.  When running on a working system we see three entries in the proxy dict: 'http', 'https' and 'ftp' all referring to the same host and port.  Because urlgrabber looks for the 'http' and 'https' entries and the matching is case sensitive, it doesn't work when only 'HTTPS' is set.

urlgrabber is able to pick up proxy information in the environment if it's not already set, but this behaviour is being overridden from within yum-rhn-plugin.

Hope this helps,

Paul

please use more recent version of yum-rhn-plugin

(In reply to Paul Wayper from comment #0)
> Version-Release number of selected component (if applicable):
> 
> yum-rhn-plugin-2.0.1-4.el7.noarch
> yum-3.4.3-118.el7.noarch
>

*** This bug has been marked as a duplicate of bug 1115516 ***