Bug 1184164 - HTML5 Spice Proxy (Tech Preview) Not Able to be Configured
Summary: HTML5 Spice Proxy (Tech Preview) Not Able to be Configured
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 3.4.4
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: ovirt-3.6.0-rc
: 3.6.0
Assignee: Michal Skrivanek
QA Contact: Ilanit Stein
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-01-20 17:25 UTC by Robert McSwain
Modified: 2019-08-15 04:13 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
With this update websocket proxy configuration values are now validated to prevent misconfigureation.
Clone Of:
Environment:
Last Closed: 2016-03-09 20:54:45 UTC
oVirt Team: Virt


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2016:0376 normal SHIPPED_LIVE Red Hat Enterprise Virtualization Manager 3.6.0 2016-03-10 01:20:52 UTC
oVirt gerrit 37498 master MERGED tools: Validate WebSocketProxy config value Never

Description Robert McSwain 2015-01-20 17:25:19 UTC
Description of problem:
	If I select a VM, right click to go to Console Options and
	select Spice HTML5 browser client (Tech preview), and try
	to hit OK button - nothing happens.  The button depresses but
	does not activate and the Console Options popup is not dismissed.
	No errors are generated.   This behavior is the same regardless
	of which browser is attempted - FF 34 or Chrome.   I see this
	behavior on RHEL6 as well as Ubuntu and Windows browsers.

	Previously, the interface would popup a new window and it would
	show a Spice html5 label in grey and just sit there.  No errors
	were generated anywhere that I could see.   Now, that doesn't
	even happen.

Version-Release number of selected component (if applicable):
rhevm-3.4.4-2.2.el6ev.noarch
spice-html5-0.1.4-1.el6.noarch

How reproducible:
100%

Steps to Reproduce:
See Description

Actual results:
No pop-up occurs. 

Expected results:
Popup occurs and the proxy can be configured properly.

Comment 2 Robert McSwain 2015-01-21 17:48:21 UTC
The customer wanted to note that he's able to test anything that we'd like to attempt to get this working in the UI. Currently rather than not working as expected the feature is not working at all so some direction as to what could be the problem for not allowing configuration in the first place.

Comment 3 Frantisek Kobzik 2015-01-29 11:04:14 UTC
I'm not sure I fully understand. This is what I get from the description:
 - previously (before update?) 'spice-html5' radio button was greyed-out.
 - now it's enabled, but after selecting and clicking nothing happens (i.e. 'Console options' dialog doesn't disappear). Selecting other implementations 'Native' or 'Plugin' works fine.
Is that right?

Can I ask whether the WebSocketProxy option is configured in the engine? You can find out using engine-config like this:
$ engine-config -g WebSocketProxy

Also, it's quite probable this is a frontend issue. Logs would be really helpful.
In firefox, open javascript console (usually menu->web developer->web console), then try to reproduce the bug and watch the console for any errors/warnings. Pasting all error text (as private) here would be great.

Cheers!
Franta.

Comment 4 Robert McSwain 2015-01-29 20:34:35 UTC
Hi! Here's the requested information:

 - previously (before update?) 'spice-html5' radio button was greyed-out.
 - now it's enabled, but after selecting and clicking nothing happens (i.e.
'Console options' dialog doesn't disappear). Selecting other implementations
'Native' or 'Plugin' works fine.
Is that right?

    </snip>

    Not quite.  The radio button was always 'active' ie; not insensitive.
    It used to popup a new window with a grey rectangle and a smaller
    grey rectangle at the bottom.

    Now what it does is that it allows me to select html5 as a console
    type but I cannot dismiss the Console Options dialog.  The Ok button
    appears to activate but does nothing.  I can only select another
    type of console - auto, native, or plugin or hit cancel.  The other
    spice options, map control-alt delete, enable usb auto share open in
    full screen and enable spice proxy are all able to be set, but have
    no effect.  In other words, selection of html5 console apparently
    overrides ability to select ok.

    <snip>

Can I ask whether the WebSocketProxy option is configured in the engine? You can
find out using engine-config like this:
$ engine-config -g WebSocketProxy
    </snip>

[root@bl280g6-tux16v1 ~]# engine-config -g WebSocketProxy
WebSocketProxy: 5000 version: general

    <snip>

Also, it's quite probable this is a frontend issue. Logs would be really
helpful.
In firefox, open javascript console (usually menu->web developer->web console),
then try to reproduce the bug and watch the console for any errors/warnings.
Pasting all error text (as private) here would be great.
    </snip>

If I turn on the Firefox console logging and set it to 'Log' I get the following
when I click on the OK button with HTML5 selected:

"Thu Jan 29 15:04:42 GMT-500 2015 com.google.gwt.logging.client.LogConfiguration
SEVERE: Exception caught: Config value must be in following form: host:port
com.google.gwt.event.shared.UmbrellaException: Exception caught: Config value
must be in following form: host:port
        at Unknown.Jp(Unknown Source)
        at Unknown.Qp(Unknown Source)
        at Unknown.KQ(Unknown Source)
        at Unknown.NQ(Unknown Source)
        at Unknown.YP(Unknown Source)
        at Unknown.ULd(Unknown Source)
        at Unknown.cMd(Unknown Source)
        at Unknown.LL(Unknown Source)
        at Unknown.WLd(Unknown Source)
        at Unknown.x3d(Unknown Source)
        at Unknown.pMd(Unknown Source)
        at Unknown.qWd(Unknown Source)
        at Unknown.VXd/PXd<(Unknown Source)
        at Unknown.lr(Unknown Source)
        at Unknown.or(Unknown Source)
        at Unknown.nr/<(Unknown Source)
        at Unknown.Uu(Unknown Source)
        at Unknown.c3d(Unknown Source)
        at Unknown.psi(Unknown Source)
        at Unknown.x3d(Unknown Source)
        at Unknown.pMd(Unknown Source)
        at Unknown.qWd(Unknown Source)
        at Unknown.VXd/NXd<(Unknown Source)
        at Unknown.lr(Unknown Source)
        at Unknown.or(Unknown Source)
        at Unknown.nr/<(Unknown Source)
        at Unknown.anonymous(Unknown Source)
Caused by: java.lang.IllegalArgumentException: Config value must be in
following form: host:port
        at Unknown.Ip(Unknown Source)
        at Unknown.Np(Unknown Source)
        at Unknown.Pp(Unknown Source)
        at Unknown.RCe(Unknown Source)
        at Unknown.t5h(Unknown Source)
        at Unknown.q4h(Unknown Source)
        at Unknown.c5h(Unknown Source)
        at Unknown.vek(Unknown Source)
        at Unknown.Hrm(Unknown Source)
        at Unknown.dci(Unknown Source)
        at Unknown.Rbi(Unknown Source)
        at Unknown.d$h(Unknown Source)
        at Unknown.KXh(Unknown Source)
        at Unknown.eM(Unknown Source)
        at Unknown.gQ(Unknown Source)
        at Unknown.YP(Unknown Source)
        at Unknown.ULd(Unknown Source)
        at Unknown.cMd(Unknown Source)
        at Unknown.LL(Unknown Source)
        at Unknown.WLd(Unknown Source)
        at Unknown.x3d(Unknown Source)
        at Unknown.pMd(Unknown Source)
        at Unknown.qWd(Unknown Source)
        at Unknown.VXd/PXd<(Unknown Source)
        at Unknown.lr(Unknown Source)
        at Unknown.or(Unknown Source)
        at Unknown.nr/<(Unknown Source)
        at Unknown.Uu(Unknown Source)
        at Unknown.c3d(Unknown Source)
        at Unknown.psi(Unknown Source)
        at Unknown.x3d(Unknown Source)
        at Unknown.pMd(Unknown Source)
        at Unknown.qWd(Unknown Source)
        at Unknown.VXd/NXd<(Unknown Source)
        at Unknown.lr(Unknown Source)
        at Unknown.or(Unknown Source)
        at Unknown.nr/<(Unknown Source)
        at Unknown.anonymous(Unknown Source)"
730FB6A1EE8850B9282ACA97E522C456.cache.html:17783

Comment 5 Frantisek Kobzik 2015-01-30 06:24:31 UTC
Thanks for a fast and detailed response!

It looks like the WebSocketProxy option is malformed. The option has 3 possible forms:
1, Off - websocket proxy is turned off (neither spice-html5 nor noVNC are enabled)
2, Engine:<port> (e.g. Engine:5000), websocket proxy is configured on the same machine as the engine (this is common when websocket proxy infrastructure is configured by engine-setup)
3, Host:<port> (e.g. Host:6100) denotes multiple instances of websocket proxy deployed on every host (non trivial setup, better load-balancing),
4, <fqdn>:<port> (e.g. myengine.com:6100) - websocket proxy runs on given fqdn, in this example myengine.com.

So, in the customer case something is wrong - the option only contains value '5000' and must be reconfigured based on their setup to match one of beforementioned cases using engine-config.

(if the proxy runs on engine, then it should be simple as this:

$ engine-config -s WebSocketProxy=Engine:5000

, although I'm little affraid that customer doesn't typical deployment done by engine-setup)

I hope this helps.
Cheers,
Franta.

Comment 6 Robert McSwain 2015-01-30 20:46:29 UTC
Franta,

I also appreciate the really quick turnaround from engineering! Here's what I've been able to find out:

	Is the websocket proxy supposed to point to an
	*existing* proxy, like squid, in the way that SpiceServerProxy
	is setup?   Or is it supposed to be independent?

	For Spice server to work,  the customer has squid setup on port
	2301.  This works.

	He tried setting the websocket proxy to use this same
	port and got an error when trying to start the service:


Starting oVirt Engine websockets proxy:                    [  OK  ]
[root@bl280g6-tux16v1 ~]# WebSocket server settings:
  - Listen on *:2301
  - Flash security policy server
  - SSL/TLS support
  - Recording to '/tmp/websocket-trace.*'
ovirt-websocket-proxy[2317] ERROR run:532 Error: [Errno 98] Address already in use

	This makes us wonder if the websocket proxy is something
	completely different than what Spice server is and it needs
	completely different management and can't share the same
	proxy as SpiceServer.

	Is this a correct understanding?

Regards,
Robert McSwain

Comment 7 Frantisek Kobzik 2015-02-02 12:40:04 UTC
Hi Robert,

correct - Spice proxy and Websocket proxy are two different things. And they actually don't work together.

1, The purpose of SPICE proxy is to redirect SPICE traffic through the proxy. It applies for 'Native' and 'Plugin' client (SPICE only).

2, Websocket proxy is needed for SPICE-HTML5 and noVNC clients. These clients use web sockets for talking with spice/vnc server. Since our spice/vnc server don't support web sockets directly, we use websocket proxy to do the conversion.

Anyway: If customer has already spice proxy (e.g. squid), they should configure SPICE proxy on cluster (Cluster->Edit->Console->Override spice->fill in address/fqdn:port of their proxy [like 10.20.30.40:2301]). After this, they should select spice 'Native' or 'Plugin' option in 'Console option' for a VM and check spice proxy checkbox in the very same dialog. Then the spice traffic should flow through the proxy.

(I believe the documentation on this topic needs improvements...)

Comment 8 Frantisek Kobzik 2015-02-03 16:43:47 UTC
I created a patch that should prevent such incorrect configuration.

Comment 10 Ilanit Stein 2015-10-18 11:52:10 UTC
Verified on rhevm 3.6.0-15

Checked the added WebSocketProxy config value validation is working as expected.
This validation prevents the situation in this bug, by blocking defining WebSocketProxy: 5000 version: general   : 

[root@istein-rhevm36 ~]# engine-config -s WebSocketProxy=5000
Cannot set value 5000 to key WebSocketProxy. Correct values are: Off (proxy is not deployed), Engine:<port> (Engine is reserved keyword meaning proxy is deployed on the same machine as the engine (on given port)), Host:<port> (Host is reserved keyword meaning proxy is deployed on each host on given port (if the deployment has more hosts, proxy must be deployed on each of them)), <hostname>:<port> (proxy is deployed on a machine identified by given hostname or ip and port).

Here are some more trials to test the validation:
1.
[root@istein-rhevm36 ~]# engine-config -s WebSocketProxy=
Cannot set value  to key WebSocketProxy. The WebSocketProxy can't be empty.
2.
[root@istein-rhevm36 ~]# engine-config -s WebSocketProxy=Engine:
Cannot set value Engine: to key WebSocketProxy. Correct values are: Off (proxy is not deployed), Engine:<port> (Engine is reserved keyword meaning proxy is deployed on the same machine as the engine (on given port)), Host:<port> (Host is reserved keyword meaning proxy is deployed on each host on given port (if the deployment has more hosts, proxy must be deployed on each of them)), <hostname>:<port> (proxy is deployed on a machine identified by given hostname or ip and port).

Comment 13 errata-xmlrpc 2016-03-09 20:54:45 UTC
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/RHEA-2016-0376.html


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