Bug 843410

Summary:	PRD32 - Allow non plugin automatic invocation of console session (basic - no cd, disconnect reason, etc.)
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Alon Bar-Lev <alonbl>
Component:	ovirt-engine-webadmin-portal	Assignee:	Frantisek Kobzik <fkobzik>
Status:	CLOSED ERRATA	QA Contact:	Jiri Belka <jbelka>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	unspecified	CC:	acathrow, agajania, bsanford, cfergeau, dblechte, desktop-qa-list, djasa, dyasny, ecohen, iheim, jbrooks, marcandre.lureau, mgoldboi, michal.skrivanek, ofrenkel, pep, Rhev-m-bugs, tcarlin, vfeenstr, ykaul
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	3.2.0
Hardware:	Unspecified
OS:	Unspecified
URL:	http://www.ovirt.org/Features/Non_plugin_console_invocation
Whiteboard:	virt
Fixed In Version:	sf13.1	Doc Type:	Enhancement
Doc Text:	Users can now invoke a virtual machine console without requiring an installed browser plugin. Instead of using the plugin, the engine provides a file containing connection information that can be registered and opened by a console client application installed on the client's system. This feature can be configured using the ClientConsoleMode option set by engine-config: * If the option is set to Plugin (the default option), the browser plugin is used. * If the option is set to Native, the invocation via a browser plugin is disabled. * If the option is set to Auto, the browser plugin is used if it is installed, otherwise the console client application is used.	Story Points:	---
Clone Of:
Clones:	918890 (view as bug list)		Environment:
Last Closed:	2013-06-10 21:08:20 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	843397, 908805, 977289, 1029376
Bug Blocks:	918890, 947966, 948448

Description Alon Bar-Lev 2012-07-26 09:00:37 UTC

This extends bug#843397 to be able to automatically activate vnc/spice session at client side without any plugin installed at browser.

PROBLEM

1. oVirt does not support activating console session without plugin installed.

2. oVirt Supports Spice only session activation within specific browsers Internet Explorer and Firefox only if appropriate plugin is installed.

3. If user does not has plugin or use unsupported browser, he cannot activate Spice session.

4. Installing native browser plugin as in the Spice case may expose the client computer to malformed sites.

SOLUTION

Use browser capability of mime type to program registration, so that upon reception of specific mime type content it execute a program and provide the content as a parameter.

Using this method, [almost] any browser can be supported as long as Spice/Vnc clients are installed on client.

User can assign mime type to program relation manually, or we can later adjust the spice offering with this embedded, it should be trivial to do so for all browser and operating systems.

This solution does not remove the plugin interaction if detected.

DESIGN

When Spice/Vnc session is requested, and appropriate plugin is not detected, present optional message and produce HTTP request/HTTP response with the following fields:

---
Content-Type: application/x-spice-configuration
Content-Disposition: attachment; filename="console.spice"
Cache-Control: no-cache, must-revalidate
Expires: Sat, 26 Jul 1997 05:00:00 GMT

# Spice configuration file
Host: <host>
Port: <port>
Password: <password>
CA: <Base64 encodeded CA>
---

* for Vnc connection, replace spice with vnc.

Provided GWT does not support producing a new HTTP request with specific content, this task can be accomplished using a simple echo servlet.

Echo servlet will receive query string as follows:
header_content-type=<type>&header_filename=<name>&content=line&content=line...

The servlet will iterate the query string and build HTTP response.

Calling the servlet at client side can be done by using window.open(), or href, for example:
---
window.open("echo?header_content-type=application/x-spice-configuration&header_filename=console.spice&content=Host%3a%20host1&content=Port%3a%20123&content=Password%3a%20pass");
---

At client side the following simple script can be used to run spicy once registered as application/x-spice-configuration mime type within browser:
---
#!/bin/sh
get_var() {
        local var="$1"
        echo "${CONFIG}" | sed -n -e 's/'"${var}"': *\(.*\)/\1/p'
}

CONFIG="$1"
if [ -z "${CONFIG}" ]; then
        ecCalling the servlet at client side can be done by using window.open(), or href, for example:ho "usage $0 config_file" >&2
        exit 1
fi

CONFIG="$(cat "${CONFIG}" | sed -e 's/[^ \t0-9a-zA-Z.:!@#$%^&*()]/?/g' -e 's/#.*//')"

host="$(get_var Host)"
port="$(get_var Port)"
pass="$(get_var Password)"

exec spicy -h "${host}" -p "${port}" -w "${pass}"
---

After done spice package can optionally provide the wrapper and automatic registration within browser MIME database.

Comment 1 David Jaša 2012-07-31 14:01:30 UTC

It would be nice for this to work in portal like (pseudocode):

if(plugin_present && supported_browser):
    console_plugin 
else:
    try:
        console_mime
    except(mime_not_handled):
        console_manual

> # Spice configuration file
> Host: <host>
> Port: <port>
> Password: <password>
> CA: <Base64 encodeded CA>

beware of host-subject thingie, see:
http://wiki.ovirt.org/wiki/Features/One_certificate-key_pair_per_NIC
and comments to bug 807384 for reference.

Comment 2 Michal Skrivanek 2012-09-25 12:33:14 UTC

*** Bug 843397 has been marked as a duplicate of this bug. ***

Comment 3 Andrew Cathrow 2012-10-17 19:53:43 UTC

Would this approach cover the wealth of other options we need to pass to the client - eg. passing usb filter strings, etc.

Also today we 'know' when the client is connected so we don't let you launch a client again against your existing session, won't we lose that ability?

Comment 4 Alon Bar-Lev 2012-10-17 20:03:26 UTC

(In reply to comment #3)
> Would this approach cover the wealth of other options we need to pass to the
> client - eg. passing usb filter strings, etc.

Basically you download a file, and register a program that handles this file MIME type. Just like you open PDF file, libreoffice document or a movie.

The content of the file can be anything... the program that is executed can read its content and do everything required. So as long as the spice client support these options via cmdline we are good. 

> Also today we 'know' when the client is connected so we don't let you launch
> a client again against your existing session, won't we lose that ability?

This 'know' is invalid, as you know in one browser but not in another browser (another user). I believe the mechanism should be moved to server side. Acquiring the status from vdsm.

Comment 5 Marc-Andre Lureau 2012-10-17 20:28:29 UTC

(In reply to comment #4)
> > Also today we 'know' when the client is connected so we don't let you launch
> > a client again against your existing session, won't we lose that ability?
> 
> This 'know' is invalid, as you know in one browser but not in another
> browser (another user). I believe the mechanism should be moved to server
> side. Acquiring the status from vdsm.

I agree with Alon, and if that client side hint is required, we can still evaluate possible solutions (advertize VM UUID somehow, on the bus or in the introspectable process details list)

Comment 6 Itamar Heim 2012-10-17 23:59:28 UTC

what about the flow in which the browser gets events from the activex / polls the xpi for connection status?

Comment 7 Alon Bar-Lev 2012-10-18 08:14:16 UTC

(In reply to comment #6)
> what about the flow in which the browser gets events from the activex /
> polls the xpi for connection status?

This what we discussed in comment#4, comment#5, the status should be acquired from the VM not from the client, as you also would like to support lock between users.

BTW: I really like the spice feature of simultaneous multiple users. For the admin interface it is a good feature to have. In this mode, we should not manage any lock, maybe just warn.

Comment 8 Itamar Heim 2012-10-18 21:46:26 UTC

einav - thoughts on comment 7?
my main concern is that detecting client was disconnected from the VM is racy.
any other considerations?

Comment 9 Michal Skrivanek 2012-10-26 07:17:58 UTC

I think we also have to consider current issue with GWT vs IE8 and expedite this faster. Better than waiting forever for a proper Windows xpi. And then still get complaints it doesn't work in Opera/Safari/whatever.
Moreover it can be used for smoother VNC integration for unsupported client OSes.

Regarding comment #7, we should do it anyway (e.g. 868297; or we cannot prevent user is logged in via some other way but spice)

Comment 15 Marc-Andre Lureau 2013-01-04 23:51:17 UTC

Open a connection by file as landed in virt-viewer upstream a few weeks ago. The associated mime type will be "application/x-virt-viewer". RHEVM / portal will need to generate the file when needed (when active/xpi disabled), and set correct mime for the browser to open the right application.

The file format is described in the source file: http://git.fedorahosted.org/cgit/virt-viewer.git/tree/src/virt-viewer-file.c Most of the keys are based on the Spice controller values and should be easy to translate from RHEVM side. If in doubt, feel free to ask.

Comment 16 Michal Skrivanek 2013-01-15 12:02:39 UTC

would it be possible we get that for VNC as well? One of the points to implement this in RHEV-M was to allow for easier VNC client invocation too. Seems like it doesn't really work for VNC at the moment?

Comment 17 Marc-Andre Lureau 2013-01-16 12:33:49 UTC

(In reply to comment #16)
> would it be possible we get that for VNC as well? One of the points to
> implement this in RHEV-M was to allow for easier VNC client invocation too.
> Seems like it doesn't really work for VNC at the moment?

Yes, I just sent a patch to virt-tools-list.

Btw, make sure the filename/location generated by RHEVM as the extension .vv : I couldn't find a way to register the mime without extension. If the extension is missing, IE will ask which application to open.

Comment 18 Frantisek Kobzik 2013-01-16 12:42:08 UTC

OK. Thank you.

Comment 19 Alon Bar-Lev 2013-02-05 07:28:32 UTC

Frantisek Kobzik: This is a public stable interface, please publish the structure of the file.

Comment 25 Michal Skrivanek 2013-04-12 09:37:37 UTC

*** Bug 947966 has been marked as a duplicate of this bug. ***

Comment 26 Jiri Belka 2013-05-03 09:54:23 UTC

OK, sf15. Plugin forces plugin installation, Native forces providing config file to download which type should be associated with native client, Auto detects plugin existence and if one is found it uses it otherwise it behaves like Native. RHEL6 virt-viewer does not support config file yet (BZ908805). I'm opening also new BZ for silly popup with test "This webpage wants to run the following add-on: 'Control name is not available' from 'Not Available'." which appears when Auto mode is used.

Comment 27 Alon Bar-Lev 2013-05-03 10:17:41 UTC

Hi Jiri,

Please specify which browsers were tested.

Thanks!

Comment 28 Jiri Belka 2013-05-03 13:25:10 UTC

w2k12 ie10 - auto -> ok, mime
w2k12 ie10 - plugin -> ok, plugin


w8 x64 ie10 - auto -> ok, mime
w8 x64 ie10 - plugin -> ok, plugin with signature warning

w2k8r2 ie10 - auto -> ok,  mime
w2k8r2 ie10 - plugin -> ok, plugin
w2k8 x64 ie9 - auto -> ok, mime
w2k8 x64 ie9 - plugin -> installes ok, does not open console (x86 cab)
w2k8 ie9 - auto - silly popup, mime
w2k8 ie9 - plugin - silly popup, plugin

w7 x64 ie10 - auto -> ok, mime
w7 x64 ie10 - plugin -> ok, plugin
w7 ie10 - auto -> silly popup, mime
w7 ie10 - plugin -> silly popup, plugin
w7 x64 ie9 - auto -> silly popup, mime
w7 x64 ie9 - plugin -> silly popup, plugin
w7 ie9 - auto -> ok, mime
w7 ie9 - plugin -> ok, plugin

w2k3r2 ie8 - auto -> ok, mime
w2k3r2 ie8 - plugin -> ok, plugin
w2k3 ie8 - auto -> ok, mime
w2k3 ie8 - plugin -> ok, plugin

wxp ie8 - auto -> silly popup, mime
wxp ie8 - plugin -> silly popup, plugin

Comment 29 Jiri Belka 2013-05-03 13:26:19 UTC

and ff17.

Comment 30 Alon Bar-Lev 2013-05-03 14:20:37 UTC

Thanks!

What above chrome?

Comment 31 Vinzenz Feenstra [evilissimo] 2013-05-03 14:23:20 UTC

(In reply to comment #30)
> Thanks!
> 
> What above chrome?

Chrome is not a supported browser, is it?

Comment 32 Jiri Belka 2013-05-03 14:28:14 UTC

RHEVM does not support Chrome :)

Comment 33 Alon Bar-Lev 2013-05-03 14:33:27 UTC

(In reply to comment #32)
> RHEVM does not support Chrome :)

Oh... I did not know that? does not support means it does not work, or work partially? If work partially, it will be good to verify that this mechanism is working, so when we do support chrome we do not have much regressions.

Comment 35 David Jaša 2013-05-06 13:41:36 UTC

Note that chrome users will run into this issue (and if you look at the time it was reported, you can guess when that will get fixed...).

https://code.google.com/p/chromium/issues/detail?id=333

Comment 36 Marc-Andre Lureau 2013-05-06 14:38:18 UTC

Jiri, what client version did you test againt?

(latest virt-viewer-x86-0.5.6.msi release should register mime support automatically, but hasn't been tested thoroughly)

Comment 37 Jiri Belka 2013-05-06 14:59:04 UTC

I was just testing RHEVM part, testing virt-viewer is not case in this BZ.

Comment 38 errata-xmlrpc 2013-06-10 21:08:20 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.

http://rhn.redhat.com/errata/RHSA-2013-0888.html