Bug 1176219
| Summary: | subscription-manager repos --list with bad proxy options is silently using cache | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | John Sefler <jsefler> | ||||
| Component: | subscription-manager | Assignee: | Kevin Howell <khowell> | ||||
| Status: | CLOSED ERRATA | QA Contact: | John Sefler <jsefler> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | low | ||||||
| Version: | 6.7 | CC: | alikins, bcourt, crog, csnyder, dgoodwin, khowell, skallesh, vrjain | ||||
| Target Milestone: | rc | ||||||
| Target Release: | 6.9 | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | |||||||
| : | 1306005 (view as bug list) | Environment: | |||||
| Last Closed: | 2017-03-21 10:53:27 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: | |||||||
| Bug Depends On: | 1298327 | ||||||
| Bug Blocks: | 1209535, 1306005 | ||||||
| Attachments: |
|
||||||
What should the gui do in this case? (user won't see stderr console output...) How do we handle multiple disconnected requests? I think my preference would be to warn once when we are "disconnected". For cli, one line of warning to stderr[1], and for gui, pop up one warning dialog. For gui, it would be better ui to have some sort of "offline indicator", but not sure it's worth the effort. However, for this particular case... we sort of know that it was a Proxy error and not a generic network error. At least, we get a generic socket.error with a message that currently claims "Proxy connection failed". We could check for it in python-rhsm where we know we are attempting to connect to the proxy. But then again, if that was a bogus --serverurl, that would be more difficult to handle. Deferring to RHEL 6.7 cycle Command line is now printing an error. This needs to be addressed in the GUI. Both the gui and the command line throw an error for me when following the reproduction steps. Related commit in master that ensures the cli fails when there are bad proxy options used:
commit 7ce6801fc1cc38edcdeb75dfb5f0d1f8a6398c68
Author: William Poteat <wpoteat>
Date: Tue Mar 1 13:30:41 2016 -0500
1301215: Test proxy connection before making call
1176219: Stop before cache is returned when using bad proxy options
Uses socket connect as test for viability of proxy. Only checks when proxy
settings are on the command line.
The fix in 7ce6801fc1cc38edcdeb75dfb5f0d1f8a6398c68 simply logs a line in rhsm.log like "Attempted bad proxy: ...", and continues to respond with cached information. This is usually lost in the logs, as evidenced in bug 1353821 . We need to ignore cached information whenever proxy connection information is provided as command arguments. Added another PR (1493) to fix a bug I introduced w/ the PR for this BZ (1486). [root@dhcp35-71 ~]# subscription-manager version
server type: Red Hat Subscription Management
subscription management server: 0.9.51.20-1
subscription management rules: 5.15.1
subscription-manager: 1.18.3-1.el6
python-rhsm: 1.18.4-1.el6
[root@dhcp35-71 ~]# subscription-manager repos --list
+----------------------------------------------------------+
Available Repositories in /etc/yum.repos.d/redhat.repo
+----------------------------------------------------------+
Repo ID: rhel-lb-for-rhel-6-server-eus-rpms
Repo Name: Red Hat Enterprise Linux Load Balancer (for RHEL 6 Server) - Extended Update Support (RPMs)
Repo URL: https://cdn.redhat.com/content/eus/rhel/server/6/$releasever/$basearch/loadbalancer/os
Enabled: 1
Repo ID: rhel-6-server-rhs-client-1-source-rpms
Repo Name: Red Hat Storage Native Client for RHEL 6 (Source RPMs)
Repo URL: https://cdn.redhat.com/content/dist/rhel/server/6/$releasever/$basearch/rhs-client/source/SRPMS
Enabled: 0
Repo ID: rhs-big-data-3-for-rhel-6-server-source-rpms
Repo Name: Red Hat Storage 3 Server Big Data (Source RPMs)
Repo URL: https://cdn.redhat.com/content/dist/rhel/server/6/$releasever/$basearch/rhs-server-bigdata/3/source/SRPMS
Enabled: 0
Proxy coonection failed error is being thrown now
[root@dhcp35-71 ~]# subscription-manager repos --list --proxy=auto-services.usersys.redhat.com:3128 --proxyuser=bad-username --proxypassword=bad-password
Proxy connection failed, please check your settings.
GUI verification : Error dialog says "Unable to load repository data" , but doesnot convey that its due to the invalid proxy connection. Moving the bug back to new, would like the error message to be something like "Proxy connection failed,Unable to load repository data" Please refer the attachment for the Actual error dialog Created attachment 1217421 [details]
Unable to load repository
Shwetha, Please reopen comment 14 as a new bug. Please proceed with verifying this bug which is for the command line only. Marking this bug as verified , opened a new bug for GUI 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://rhn.redhat.com/errata/RHSA-2017-0698.html |
Description of problem: Prior to subscription-manager commit 69d62fce716fb30709acc6b67346029aeb85c302 calls to subscription-manager list --repos with bad proxy options whould fail with stderr "Network error, unable to connect to server. Please see /var/log/rhsm/rhsm.log for more information." and an exitCode of 70 EX_SOFTWARE, Now an explicit call with a bad proxy and/or bad credentials will appear successful since it is now using cache, but the user does not know it. I believe this is deceptive when the user supplies erroneous proxy options. See my suggestion below. Version-Release number of selected component (if applicable): [root@jsefler-os7 ~]# subscription-manager version server type: Red Hat Subscription Management subscription management server: 0.9.37-1 subscription management rules: 5.13 subscription-manager: 1.13.12-1.el7 python-rhsm: 1.13.8-1.el7 How reproducible: Steps to Reproduce: After successfully registering and attaching a subscription that provides repos... [root@jsefler-os7 ~]# subscription-manager repos --list --proxy=auto-services.usersys.redhat.com:3128 --proxyuser=bad-username --proxypassword=bad-password +----------------------------------------------------------+ Available Repositories in /etc/yum.repos.d/redhat.repo +----------------------------------------------------------+ Repo ID: awesomeos-x86_64 Repo Name: awesomeos-x86_64 Repo URL: https://cdn.redhat.com/path/to/awesomeos/x86_64 Enabled: 0 [root@jsefler-os7 ~]# echo $? 0 It is not obvious to me why that succeed despite the erroneous proxy values I supplied. Actual results: Prior to subscription-manager-1.13.12-1, the result was "Network error, unable to connect to server. Please see /var/log/rhsm/rhsm.log for more information.". The problem with the new results is that the user (knowingly or unintentionally) passed bad proxy options but got a successful reply for unknown reasons. The rhsm.log contains... 2014-12-19 12:16:30,320 [ERROR] subscription-manager @cache.py:212 - Proxy connection failed: 407 2014-12-19 12:16:30,320 [WARNING] subscription-manager @cache.py:218 - Unable to reach server, using cached status. Hence I see that cache is being used to report the results. Expected results: I think a better response would be to also report "Unable to reach server, using cached status." in the stderr as well as a non-zero exitCode in addition to the cached repos list. Something like this... # subscription-manager repos --list --proxy=auto-services.usersys.redhat.com:3128 --proxyuser=bad-username --proxypassword=bad-password Unable to reach server, using cached status. +----------------------------------------------------------+ Available Repositories in /etc/yum.repos.d/redhat.repo +----------------------------------------------------------+ Repo ID: awesomeos-x86_64 Repo Name: awesomeos-x86_64 Repo URL: https://cdn.redhat.com/path/to/awesomeos/x86_64 Enabled: 0 # echo $? 70