Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1651316

Summary: dnf not using proxy settings
Product: Red Hat Enterprise Linux 8 Reporter: Francisco Lloreda <flloreda>
Component: subscription-managerAssignee: candlepin-bugs
Status: CLOSED DUPLICATE QA Contact: Red Hat subscription-manager QE Team <rhsm-qe>
Severity: unspecified Docs Contact:
Priority: high    
Version: 8.0CC: csnyder, dmach, james.antill, mblaha, mkolaja, mwhitehe, wouter.hummelink
Target Milestone: rcKeywords: Triaged
Target Release: 8.0   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-01-07 21:28:06 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:

Description Francisco Lloreda 2018-11-19 16:41:41 UTC
Description of problem:

dnf seems to ignore proxy settings on /etc/dnf/dnf.conf


Version-Release number of selected component (if applicable):
[root@rhel8-beta-kvm dnf]# rpm -qi dnf
Name        : dnf
Version     : 4.0.4
Release     : 1.el8


How reproducible:


Steps to Reproduce:
1. Configure dnf setting proxy use 
[root@rhel8-beta-kvm dnf]# cat /etc/dnf/dnf.conf 
[main]
gpgcheck=1
installonly_limit=3
clean_requirements_on_remove=True
proxy=http://192.168.100.1:28118

2. Try to use dnf
[root@rhel8-beta-kvm dnf]# LANG=ENG dnf makecache
Failed to set locale, defaulting to C
Updating Subscription Management repositories.
Updating Subscription Management repositories.
Red Hat Enterprise Linux 8 for x86_64 - BaseOS Beta (RPMs)                                                                    0.0  B/s |   0  B     00:29    
Failed to synchronize cache for repo 'rhel-8-for-x86_64-baseos-beta-rpms', ignoring this repo.
Metadata cache created.

Actual results:
dnf program unable to access repos using proxy 

Expected results:
dnf to be able to use proxy config to access repos

Additional info:

Comment 1 Wouter Hummelink 2018-11-21 13:39:09 UTC
I'm experiencing similar problems behind the corporate proxy of my customer. 
I've dove in a little further and in strace I can see that dnf does in fact try to connect to the proxy, but drops the connection again.

I've tried both using the proxy directly and through CNTLM (to prevent storing my password in plaintext), but results are the same. CNTLM does not log the connection as a CONNECT request.

I see that DNF sends some binary data to the proxy right after reading the cert bundle, so it somehow appears it's trying to talk tls at the proxy.

The same setup works flawlessly on F29 (although that's not RH CDN)

Comment 2 Matthew Whitehead 2018-12-12 18:40:00 UTC
My financial services industry customer believes that they are also experiencing symptoms of this bug.

Comment 4 Marek Blaha 2018-12-14 11:20:06 UTC
I've tried to reproduce the bug and after setting http proxy in /etd/dnf/dnf.conf, all dnf traffic (according to tcpdump) went through this proxy and dnf cache was build without ignoring repositories.

Please, can you check whether there are some proxy settings in subscription manager (/etc/rhsm/rhsm.conf) config file? If that is the case, you probably have proxy setting from dnf.conf overridden in repository configuration file /etc/yum.repos.d/redhat.repo (generated by dnf-plugin-subscription-manager). Are settings in dnf.conf and redhat.repo the same? There might be a change in the protocol (http in dnf.conf, https in redhat.repo, which could explain tls talk to proxy from comment#1). In case you found this difference in configs, can you please try following?

1. comment out proxy settings in redhat.repo file
# sed -i 's/^proxy =/#proxy =/' /etc/yum.repos.d/redhat.repo

2. run dnf makecache again, with disabled subscription-manager plugin. (If you didn't disable it, it would overwrite the redhat.repo file again)
# dnf --disableplugin=subscription-manager makecache


See also similar (this bug might even be a duplicate) bug https://bugzilla.redhat.com/show_bug.cgi?id=1654531

Comment 5 Wouter Hummelink 2018-12-14 14:45:05 UTC
I can confirm that I can create the metadata if I manually edit /etc/yum.repos.d/redhat.repo. It indeed included https in the proxy setting.

I went a little further and in /usr/lib64/python3.6/site-packages/subscription-manager/repolib.py I edited line 834 which had https:// hardcoded and altered it to http:// and did a full refresh, the proxy settings are now still correct. Thanks for pointing me in the right direction to work around the issue.

Comment 6 Marek Blaha 2018-12-17 15:10:52 UTC
Reassigning to subscription manager (based on comment#5).