Bug 1040679 - http_proxy setting stops virt-viewer from connecting
Summary: http_proxy setting stops virt-viewer from connecting
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: spice-gtk
Version: 21
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Marc-Andre Lureau
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: 1182252
TreeView+ depends on / blocked
 
Reported: 2013-12-11 21:43 UTC by Richard W.M. Jones
Modified: 2015-06-29 23:39 UTC (History)
10 users (show)

(edit)
Clone Of:
: 1182252 (view as bug list)
(edit)
Last Closed: 2015-06-29 23:39:52 UTC


Attachments (Terms of Use)
Guest XML (5.25 KB, text/plain)
2013-12-11 21:44 UTC, Richard W.M. Jones
no flags Details
spice debugging with http_proxy set (2.63 KB, text/plain)
2013-12-12 10:54 UTC, Richard W.M. Jones
no flags Details
spice debugging with http_proxy NOT set (21.22 KB, text/plain)
2013-12-12 10:54 UTC, Richard W.M. Jones
no flags Details

Description Richard W.M. Jones 2013-12-11 21:43:31 UTC
Description of problem:

I have a (working) http_proxy.  However it seems to confuse
virt-viewer.

When run with the http_proxy environment variable set, it prints out:

$ virt-viewer rhel7betax64 -c qemu:///system

** (virt-viewer:20957): WARNING **: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-AFW8Zs1Bmc: Connection refused

(virt-viewer:20957): GSpice-WARNING **: HTTP proxy connection failed: 403 Forbidden

and a dialog box appears saying:

"Unable to connect to the graphic server 127.0.0.1:5900"

If I unset http_proxy then virt-viewer works fine.  ie. This
command is OK:

$ http_proxy= virt-viewer rhel7betax64 -c qemu:///system

** (virt-viewer:20935): WARNING **: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-AFW8Zs1Bmc: Connection refused

(virt-viewer:20935): GSpice-WARNING **: Warning no automount-inhibiting implementation available


Version-Release number of selected component (if applicable):

virt-viewer-0.5.7-1.fc20.x86_64

How reproducible:

100%

Steps to Reproduce:
1. Set http_proxy to point to a proxy.
2. Run virt-viewer.

Actual results:

Fails unless http_proxy is unset.

Comment 1 Richard W.M. Jones 2013-12-11 21:44:24 UTC
Created attachment 835480 [details]
Guest XML

Comment 2 Richard W.M. Jones 2013-12-11 21:46:15 UTC
$ echo $http_proxy 
http://cache.home.annexia.org:3128/

Comment 3 Christophe Fergeau 2013-12-12 10:20:42 UTC
Could you attach the output of G_MESSAGES_DEBUG=all SPICE_DEBUG=1 virt-viewer --spice-debug rhel7betax64 -c qemu:///system
when http_proxy is set?

Comment 4 Richard W.M. Jones 2013-12-12 10:54:05 UTC
Created attachment 835731 [details]
spice debugging with http_proxy set

(This is the one which fails)

Comment 5 Richard W.M. Jones 2013-12-12 10:54:35 UTC
Created attachment 835732 [details]
spice debugging with http_proxy NOT set

Comment 6 Christophe Fergeau 2013-12-12 11:11:01 UTC
Could it be a bug similar to rhbz#1021550? The connection is to 127.0.0.1:5900, I assume we should not be trying to use the proxy in this case?

Comment 7 Richard W.M. Jones 2013-12-12 11:14:59 UTC
If it's trying to connect to 127.0.0.1:5900 through the proxy, then
that will fail.  Why's it trying to use an HTTP proxy in any case?

Comment 8 Christophe Fergeau 2013-12-12 11:26:24 UTC
This was added in http://lists.freedesktop.org/archives/spice-devel/2012-August/010606.html which does not really explain the 'why'.
The use case is so that RHEV-like scenarios can proxy all SPICE connection to internal hosts through a single machine.

Comment 9 Richard W.M. Jones 2014-07-31 21:02:26 UTC
Still happens.

Also this breaks the console button in RHEV-M.  The tedious
work-around is to download the console.vv file, then in a
terminal, unset http_proxy & https_proxy and run:
  remote-viewer console.vv
every single time .....

Comment 11 Marc-Andre Lureau 2015-01-14 17:57:51 UTC
Doesn't look directly like a spice issue to me, since we don't use http_proxy variable.

I don't get this behaviour on f21, could you try to break on getenv() condition name == "http_proxy" ?

Comment 12 Richard W.M. Jones 2015-01-19 13:38:36 UTC
I don't have any spice-using guests right now.  Will need to
try this later.

Comment 13 Christophe Fergeau 2015-01-19 13:49:01 UTC
It's probably $libdir/gio/modules/libgiolibproxy.so from glib-networking which looks at the http_proxy env variable. It should be safe to temporarily move it some place else for a quick test when you get around to trying this again.

Comment 14 Richard W.M. Jones 2015-03-12 09:01:46 UTC
I set up a guest with spice:

    <video>
      <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1'/>
      <alias name='video0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </video>

I'm using virt-viewer-1.0-2.fc21.x86_64,
atk 2.14.0-1.fc21
cairo 1.13.1-0.4.git337ab1f.fc21
gdk-pixbuf2 2.31.1-1.fc21
glib2 2.42.1-1.fc21
gtk-vnc 0.5.3-6.fc21
libgovirt 0.3.2-1.fc21
libsoup 2.48.1-1.fc21
pango 1.36.8-1.fc21
rest 0.7.92-5.fc21
spice-gtk 0.27-3.fc21

I used the following break condition:

(gdb) break getenv if strcmp($rdi,"http_proxy")==0 || strcmp($rdi,"https_proxy")==0

The following is the only stack trace where it hits this breakpoint:

#0  0x00007ffff351bb00 in __GI_getenv (name=0x7fffd1413cc1 "http_proxy")
    at getenv.c:35
#1  0x00007fffd140fcb4 in envvar_config_extension::get_config(libproxy::url const&) () at /lib64/libproxy.so.1
#2  0x00007fffd1404886 in libproxy::proxy_factory::get_config(libproxy::url&, std::vector<libproxy::url, std::allocator<libproxy::url> >&, std::string&) ()
    at /lib64/libproxy.so.1
#3  0x00007fffd14056ab in libproxy::proxy_factory::get_proxies(std::string) ()
    at /lib64/libproxy.so.1
#4  0x00007fffd1405c9f in px_proxy_factory_get_proxies ()
    at /lib64/libproxy.so.1
#5  0x00007fffd16523bd in get_libproxy_proxies ()
    at /usr/lib64/gio/modules/libgiolibproxy.so
#6  0x00007ffff43e9bc5 in g_task_thread_pool_thread (thread_data=0x85e690, pool_data=<optimized out>) at gtask.c:1215
#7  0x00007ffff3e4e148 in g_thread_pool_thread_proxy (data=<optimized out>)
    at gthreadpool.c:307
#8  0x00007ffff3e4d7b5 in g_thread_proxy (data=0x9a2230) at gthread.c:764
#9  0x00007ffff38a752a in start_thread (arg=0x7fffd0bff700)
    at pthread_create.c:310
#10 0x00007ffff35e379d in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Comment 15 Marc-Andre Lureau 2015-04-22 15:59:07 UTC
sent a patch:
http://lists.freedesktop.org/archives/spice-devel/2015-April/019577.html

Comment 16 Richard W.M. Jones 2015-04-23 12:26:45 UTC
Thanks.  I tested this by applying the patch in comment 15
to the Fedora Rawhide spice-gtk package (spice-gtk3-0.28-2.fc23).

I created a virtual machine with a spice graphical console:

$ virt-builder rhel-7.1
$ virt-install --import --name=tmp-spice --ram=4096 --os-type=linux --os-variant=rhel7 --disk=rhel-7.1.img,format=raw

Before installing the updated spice-gtk package, virt-viewer
would fail with the http error outlined in this bug.

After installing the updated spice-gtk package, virt-viewer
was able to access the spice console, even though http_proxy
and https_proxy environment variables were set.

Therefore as a result of my testing I would say the patch
fixes this bug.

Comment 17 Marc-Andre Lureau 2015-06-29 23:39:52 UTC
f22 should have spice-gtk 0.29 with the fixes now


Note You need to log in before you can comment on or make changes to this bug.