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.
* Previously, after enabling a proxy for a SPICE connection opened through the spice-xpi plug-in, the only way the user could unset the proxy was to close or reopen the web page. This update modifies spice-xpi to unset the SPICE_PROXY environment variable when the proxy is unset. As a result, unsetting a proxy for a SPICE connection works as expected. (BZ#1049475)
Description of problem:
RHEVM sends to XPI SPICE plugin always SPICE proxy even one unchecks this options in Console Options.
# engine-config -g SpiceProxyDefault
SpiceProxyDefault: http://10.34.63.76:3128/ version: general
$ sudo tcpdump -i eth0 -tttt -nn dst port 3128
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
2014-01-07 15:53:49.352756 IP 10.34.131.48.49193 > 10.34.63.76.3128: Flags [S], seq 1570298935, win 14600, options [mss 1460,sackOK,TS val 63395998 ecr 0,nop,wscale 7], length 0o
$ sudo sed -n '/Jan 7 15:53:45/,$p' /var/log/messages | grep -i proxy
Jan 7 15:53:45 localhost spice: SPICE_PROXY=http://10.34.63.76:3128/
Jan 7 15:53:49 localhost spice: (remote-viewer:22936): GSpice-DEBUG: spice-session.c:1815 (with proxy http://10.34.63.76:3128)
Jan 7 15:53:49 localhost spice: (remote-viewer:22936): GSpice-DEBUG: spice-session.c:1760 proxy lookup ready
$ sed -n '/2014-01-07 15:53:45,940/,$p' .spicec/spice-xpi.log | grep -i proxy
$ sed -n '/2014-01-07 15:53:45,940/,$p' .spicec/spice-xpi.log | grep -i 3128
In attachment there is: engine.log, spice-xpi.log, messages having DEBUG from spice xpi/remote-viewer and screenshots...
Version-Release number of selected component (if applicable):
rhevm-3.2.5-0.49.el6ev.noarch
How reproducible:
100%
Steps to Reproduce:
1. define spice proxy with engine-config and restart
2. VM - console options: plugin/uncheck spice proxy and open console
3.
Actual results:
it tries to use proxy
Expected results:
should not use proxy
Additional info:
I found the reproducer is a little bit trickier:
1. Launch browser and log into User Portal.
2. Open VM Console options, uncheck the SPICE proxy & save.
3. Open VM console -> VM console is opened this time!
4. Open VM Console options, check the SPICE proxy, save and try to open VM console again -> error "Unable to connect to the graphic server (null)".
5. Repeat steps 2 and 3. -> from this time the error is always returned.
I can still reproduce, proxy is not "reset" if it is unchecked in Console Options for browser plugin (xpi).
ovirt-engine-backend-3.5.0-0.0.master.20140804172041.git23b558e.el6.noarch
ovirt-engine-webadmin-portal-3.5.0-0.0.master.20140804172041.git23b558e.el6.noarch
You should probably ask GSS who uses proxy and let them check.
OK, finally reproduced and it seems as an issue in spice-xpi.
@Christophe:
Hi, it seems that when enabling the spice proxy in spice-xpi there is no way to disable it again - only restarting the browser.
It reproduces on:
spice-xpi-2.7-25.el6.x86_64
virt-viewer-0.6.0-11.el6.x86_64
firefox-31.1.0-5.el6_5.x86_64
all are the default versions on RHEL 6.6
please note it does not reproduce on Fedora 20 (spice-xpi-2.8.90-1.fc20.x86_64, virt-viewer-0.6.0-1.fc20.x86_64)
I was able to reproduce it both using oVirt and using the test page available here: https://teuf.fedorapeople.org/plugins/test.html
The steps for test page:
- fill in the host/port
- connect
- it will work
- enable spice proxy and enter an incorrect value
- connect
- it will fail to connect since the proxy is not correct
- disable the spice proxy again and connect
- it will fail with the same error as when the proxy is enabled
after restarting the browser the spice proxy is disabled again and it is possible to connect again.
Is this a know issue? Since it seems to be fixed in more recent versions.
Thanx
Comment 10Christophe Fergeau
2015-03-16 17:02:27 UTC
Created attachment 1002406[details]
Unset SPICE_PROXY env var when proxy is not set
This does not seem to be fixed upstream, but is working because upstream no longer looks at the SPICE_PROXY environment variable (?)
This patch fixes the issue for me (RHEL6 scratch build at https://brewweb.devel.redhat.com/taskinfo?taskID=8855582 ), I'll need to send a proper patch upstream
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/RHBA-2015-1393.html