Bug 678003

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