Hide Forgot
The user had configured RHSM to run via a proxy. However, yum was not configured to use the same proxy. This causes issues with becomeing compliant in the gui but not in the cli.
Can you elaborate briefly on the issues between GUI and CLI? Not sure why they would behave differently. It looks like yum has both a global proxy configuration setting, but can also specify on a per-repo basis. Would you expect this change in RHSM to be placed in global yum.conf, or just in our repo definitions in /etc/yum.repos.d/redhat.repo? It feels a little risky to start playing with the global yum.conf, but adding the proxy setting to each entry in redhat.repo feels much more reasonable to me.
Devan, I tested putting the proxy line in global config, but using rhsm custom repos would be smarter just to avoid messing up with other configurations. On my tests, using GUI was able to register system but not to subscribe it (after setting proxy on gui option). Using cli using proxy option I was able to get registered and subscribed fine. After tweaking yum.conf for inclusion of proxy line, it even worked on GUI. I can redeploy the machine to retest if you want me to. Regards Pablo
Thanks Pablo, just a few more questions from you, I'm still not sure why either of these operations would invoke yum, if the issue was yum proxy settings I think it would only surface when you went to start installing software. First of all though, am I correct that you were essentially trying to register with auto-subscribe in both cases? Or was this a manual subscribe? Did you manually invoke yum or use packagekit after registration/entitlement? When running the GUI, did you try once without proxy settings, see it fail, then set the proxy settings and try again? (just trying to establish if there could be a bad cached connection involved, the difference in behavior is making me wonder) Were any visible error messages printed out? Thanks.
Sorry for the delay Devan, >First of all though, am I correct that you were essentially trying to register >with auto-subscribe in both cases? Or was this a manual subscribe? First try was manual two-step subscribing on GUI, second was autosubscribe On commandline only autosubscribe was tried. I used yum to invoke upgrade. In the gui I first configured proxy, then tried. I'll redeploy this machine next week and capture any information provided (screenshots, messages, etc). Regards Pablo
I couldn't resist... On this second try: Installed EL6 on VM. After finishing (install was made in text mode), I define a new repo for CDROM and then groupinstall X window and Gnome desktop Change runlevel to 5 last setup steps appear in graphical mode (firstboot) Enter my session Setup network manager to auto connect to eth0 Launch subscription manager gui from the tray icon. The remaining steps are on zipped screenshots by ascending filename. Regards Pablo
Screenshoots: http://dl.dropbox.com/u/3893782/screenshoot.tar.gz PD: Let me know when I can delete them
Ok I have them, feel free to delete. Thanks. So you selected the subscription in the compliance assistant, hit subscribe, and then immediately got the network error within RHSM? This is the error that triggered this original bug report? Do you have the output from rhsm.log the error message talks about? Did your system actually get an entitlement? (you would be able to see this in the GUI on the My Subscriptions tab) I am still unclear why this bug mentioned yum, I've checked with the team and none of us can think of how yum would even be invoked within RHSM and cause this error. Any more insight on why yum was suspected to be the problem here? Sorry for all the questions just trying to figure out what is going on. Thanks. :)
Devan: - On first capture, I hit Become compliant (bigger button) it asked me to register first - Before registering, I configured proxy (2nd screenshoot) - Enter registration data (3rd) - Tried to become compliant and all products got listed and then click on 'Subscribe' (pantallazo-3) - Then the network error appeared (pantallazo-4) - Clicked again on become compliant but only product appeared, not subscriptions (pantallazo-5). On a terminal, I've tried to yum upgrade but nothing worked (that's why asked on irc and this BZ was opened). System now appears as 'compliant' Full logs are in: http://dl.dropbox.com/u/3893782/rhsmcertd.log http://dl.dropbox.com/u/3893782/rhsm.log And well, yum (PackageKit) still complains about not contacting source so it's disabling them. The first vm I've created and configured yum manually today downloaded two updates. And please, keep going on with questions :)
Ok excellent description, thanks. So we have two separate issues, it appears a bad connection is being cached or proxy settings are not being respected. Some of RHSM's requests are making it through to the server, but somewhere in compliance assistant after hitting subscribe it looks like they may not be getting used. Trying to reproduce but haven't found a way yet, it may be a very specific path through the screens. 2011-02-18 19:52:19,769 [INFO] _request() @connection.py:147 - loading ca pem certificates from: /etc/rhsm/ca/ 2011-02-18 19:52:19,770 [INFO] _load_ca_certificates() @connection.py:134 - loading ca certificate '/etc/rhsm/ca/redhat-uep.pem' 2011-02-18 19:52:19,771 [INFO] _request() @connection.py:149 - work in insecure mode ?:False 2011-02-18 19:52:19,772 [INFO] _request() @connection.py:156 - using proxy 192.168.122.1:8118 2011-02-18 19:52:19,772 [INFO] _request() @connection.py:163 - handler: https://subscription.rhn.redhat.com:443/subscription/consumers/2b3fd7a2-4b9b-4e7c-9af1-9d42c2e504a3/entitlements?pool=8a85f98 12e264610012e2d8f6334184c 2011-02-18 19:52:29,387 [INFO] _request() @connection.py:177 - status code: 200 2011-02-18 19:52:29,393 [INFO] _request() @connection.py:147 - loading ca pem certificates from: /etc/rhsm/ca/ 2011-02-18 19:52:29,393 [INFO] _load_ca_certificates() @connection.py:134 - loading ca certificate '/etc/rhsm/ca/redhat-uep.pem' 2011-02-18 19:52:29,394 [INFO] _request() @connection.py:149 - work in insecure mode ?:False 2011-02-18 19:52:29,402 [ERROR] fetch_certificates() @managergui.py:181 - Socket error: [Errno -2] Nombre o servicio desconocido Nombre o servicio desconocido 2011-02-18 19:52:29,403 [ERROR] handle_gui_exception() @utils.py:43 - [Errno -2] Nombre o servicio desconocido Traceback (most recent call last): File "/usr/share/rhsm/gui/managergui.py", line 175, in fetch_certificates result = backend.certlib.update() File "/usr/share/rhsm/certlib.py", line 60, in update return action.perform() File "/usr/share/rhsm/certlib.py", line 132, in perform expected = self.getExpected(report) File "/usr/share/rhsm/certlib.py", line 189, in getExpected exp = self.getCertificateSerialsList() File "/usr/share/rhsm/certlib.py", line 182, in getCertificateSerialsList reply = self.uep.getCertificateSerials(self._getConsumerId()) File "/usr/lib/python2.6/site-packages/rhsm/connection.py", line 365, in getCertificateSerials return self.conn.request_get(method) File "/usr/lib/python2.6/site-packages/rhsm/connection.py", line 200, in request_get return self._request("GET", method) File "/usr/lib/python2.6/site-packages/rhsm/connection.py", line 169, in _request headers=self.headers) File "/usr/lib64/python2.6/httplib.py", line 910, in request self._send_request(method, url, body, headers) File "/usr/lib64/python2.6/httplib.py", line 947, in _send_request self.endheaders() File "/usr/lib64/python2.6/httplib.py", line 904, in endheaders self._send_output() File "/usr/lib64/python2.6/httplib.py", line 776, in _send_output self.send(msg) File "/usr/lib64/python2.6/httplib.py", line 735, in send self.connect() File "/usr/lib64/python2.6/site-packages/M2Crypto/httpslib.py", line 50, in connect self.sock.connect((self.host, self.port)) File "/usr/lib64/python2.6/site-packages/M2Crypto/SSL/Connection.py", line 181, in connect self.socket.connect(addr) File "<string>", line 1, in connect gaierror: [Errno -2] Nombre o servicio desconocido 2011-02-18 19:52:37,614 [DEBUG] _reload_screen() @compliance.py:203 - reloading screen 2011-02-18 19:52:37,615 [DEBUG] _reload_screen() @compliance.py:209 - using noncompliance date: 2011-02-18 19:52:37-01:00 Second issue, we need to add proxy settings to the yum repos we generate in redhat.repo. We also need to make sure these get updated when proxy settings are changed, even if nothing else has changed with the underlying entitlement certificates.
Thanks Devan! Pablo
Fix bad cached connection in: master: 75a9d72eed65c7940d560c13801c5b8b7144723e RHEL6: 6bbd83a454ca51d5f3a75dc17a89e7dbe489d1f9 Write proxy info for yum repositories: master: 10ab449a0df40c544a9526a4155321dbb9ed3d5d RHEL6: 38fececd0c31f68db021a361ade992c038570eb3 These fixes should appear in: master: subscription-manager-0.96.2-1 RHEL6: subscription-manager-0.95.3-1
Devan and Pablo, I'd like to get this bugzilla VERIFIED, but the re-create path is not clear. 1. Pablo, were you able to verify that Devan's fixes fixed your original problem? If yes, then can you move this bugzilla to VERIFIED? 2. Devan, we have a basic auth and no-auth proxy server running in our test environment. If you can lay out a scenario (cli and/or gui) to follow, then jmolet and I can use it to verify this bug and possibly create an automated regression test for this bug. Thanks, John Sefler
Tough one, trying to remember best I can, apologies for not clearly noting it originally. For the cached connection problem, I think you need a proxy setup and configured, but it needs to be the only way you can reach the Candlepin server from the system where RHSM is being run, i.e. request without using proxy settings must fail. If you have this environment setup you would: - Start RHSM GUI (unregistered) - Setup proxy in advanced config. - Register. - Open Compliance Assistant (be sure *not* to restart GUI between this) The bug here was the connection was not getting refreshed to use the proxy settings. Registration would work, but Compliance Assistant still had a reference to an old connection. For the second part of the bug, I think you just need to verify that having setup proxy options in RHSM, your yum repos in /etc/yum.repod.d/redhat.repo have proxy info associated with each of them.
@John: I would need to recreate the system and get the upgrade from the errata installed before doing the test. ¿There's a new iso to reinstall from from or just install from the old one then manually upgrade those packages and retest?
Pablo: You should be able to use hte RHEL 6.1 beta. Subscription Manager is in there.
Hi After downloading the new iso and installing a system, I was able to perform the steps described in comment #17 and the system become compliant. Doing yum upgrade on command line allowed me to check /etc/yum.repos.d/redhat.repo with the corresponding "proxy=" line for my proxy setup. System was able to upgrade flawlesly and become compliant without any issue. subscription-manager version tested: subscription-manager-0.95.6-1.el6.x86_64 Regards Pablo
snip of .repo file: [rhel-lb-for-rhel-6-server-rpms] name = Red Hat Enterprise Linux Load Balancer (for RHEL 6 Server) (RPMs) baseurl = https://cdn.redhat.com/content/dist/rhel/server/6/$releasever/$basearch/loadbalancer/os enabled = 1 gpgcheck = 1 gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release sslverify = 1 sslcacert = /etc/rhsm/ca/redhat-uep.pem sslclientkey = /etc/pki/entitlement/key.pem sslclientcert = /etc/pki/entitlement/8543658780534923708.pem proxy = http://192.168.122.1:8118 [rhel-lb-for-rhel-6-server-debug-rpms] name = Red Hat Enterprise Linux Load Balancer (for RHEL 6 Server) (Debug RPMs) baseurl = https://cdn.redhat.com/content/dist/rhel/server/6/$releasever/$basearch/loadbalancer/debug enabled = 0 gpgcheck = 1 gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release sslverify = 1 sslcacert = /etc/rhsm/ca/redhat-uep.pem sslclientkey = /etc/pki/entitlement/key.pem sslclientcert = /etc/pki/entitlement/8543658780534923708.pem proxy = http://192.168.122.1:8118 [rhel-rs-for-rhel-6-server-debug-rpms] name = Red Hat Enterprise Linux Resilient Storage (for RHEL 6 Server) (Debug RPMs) baseurl = https://cdn.redhat.com/content/dist/rhel/server/6/$releasever/$basearch/resilientstorage/debug enabled = 0 gpgcheck = 1 gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release sslverify = 1 sslcacert = /etc/rhsm/ca/redhat-uep.pem sslclientkey = /etc/pki/entitlement/key.pem sslclientcert = /etc/pki/entitlement/8543658780534923708.pem proxy = http://192.168.122.1:8118 [rhel-6-server-supplementary-src] name = Red Hat Enterprise Linux 6 Server - Supplementary (Source RPMs) baseurl = https://cdn.redhat.com/content/dist/rhel/server/6/6Server/$basearch/supplementary/source/SRPMS enabled = 0 gpgcheck = 1 gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release sslverify = 1 sslcacert = /etc/rhsm/ca/redhat-uep.pem sslclientkey = /etc/pki/entitlement/key.pem sslclientcert = /etc/pki/entitlement/8543658780534923708.pem metadata_expire = 86400 proxy = http://192.168.122.1:8118
Moving bug to VERIFIED as a result of successful testing with Pablo reported in comment 24 and comment 25.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHEA-2011-0611.html