Good thing: There's a working HTML5 RDP client: http://searchvirtualdesktop.techtarget.com/tip/How-long-can-Ericoms-HTML-5-client-dominance-last Demos available at: http://www.cloudinternetexplorer.com http://demo.ericomaccessnow.com Bad thing: The demo does not work neither with FF 3.6 on Linux, nor with IE 8 on XP. Not on the EEE Pad with standard browser. This is likely due to the spotty Websockets support: http://en.wikipedia.org/wiki/Websockets Works with FF on EEE Pad, with FF 9 on XP. Performance is OK.
Status of Websockets support: http://caniuse.com/#search=websockets I'd say that the Android browser is the only major problem. The fact that you can install other browsers on Android helps somewhat though.
Another commercial client: http://www.remotespark.com/html5.html
Full screen support might be possible, at least on Safari: http://stackoverflow.com/questions/3024434/ipad-webapp-full-screen-in-safari
(In reply to comment #7) Multiple solutions has been discussed. The consensus is that we should leave SSH out of the picture. Only TLS should be used. Also, I think the architecture should mimic the one used with the Java client and also native clients: that is, have one daemon on every agent, which the client connects to. Thus, the "websocketserver" service would basically have the same purpose as "sshd". For the implementation, we could consider reusing parts of the "websockify" server and/or websocket.py. The license is LGPLv3; good for us.
VMwares stuff: http://www.youtube.com/watch?v=QBxm5CBPeG8
NoMachine are also developing a web client: http://www.nomachine.com/web-player.php
According to http://code.google.com/p/android/issues/detail?id=25221: "It seems Google Chrome for Android is now an official (bundled) browser on Android 4.2+ and it supports WebSockets (verified)."
We need to decide what should be the Websocket server, and which ports we should use: 1) If we select port 443, we need to find a solution to co-exist with Apache. -In practice, co-existing with Apache will probably mean that we must ship either https://github.com/disconnect/apache-websocket or http://code.google.com/p/pywebsocket/, and then integrate the distro Apache with it. -Our code would initially execute as the Apache user. If we need to do things as root, that means we need to spawn a setuid binary. -Depending on Apache 2) If we select some other port, we need to/can use our own daemon. -The default port for encrypted Websocket is port 443, ie the same as TLS. We would use something non-standard. -Since we are not using 443, there's a higher risk that we will not get through firewalls etc. +The daemon can run as root, just like sshd. I've checked some other implementations: * Novnc uses 6080 by default. * Nomachine does not use Websockets, but rather AJAX calls it seems. Uses port 4080. * The Ericom Accessnow server uses port 8080 by default, it seems.
iOS has some problems with encrypted Websockets, see: https://github.com/kanaka/noVNC/issues/124
When it comes to browser support, we are requiring full WebSocket support, as per RFC 6455. This means: Internet Explorer 10 or newer Firefox 11 or newer (all platforms, including Android) Google Chrome 16 or newer (all platforms, including Android) Safari 6 or newer (all platforms, including iOS 6) Opera 12.1 or newer (all platforms) Please note that the "Android Browser" does not work. This list has been compiled using the following resources: http://code.google.com/p/android/issues/detail?id=25221 http://caniuse.com/#search=websockets http://en.wikipedia.org/wiki/WebSocket#Browser_support https://github.com/kanaka/noVNC/wiki/Browser-support
The HTML5 will be included in ThinLinc 4.1 as a "Technology Preview" feature.
An initial version of the ThinLinc HTML5 Client is now finished.
When having a html5 session open (own tlstunnel process) then stopping tlwebaccess service one cant start tlwebacces due to bind failure: 2013-05-02 14:05:35 INFO tlwebaccess[10582]: ThinLinc Web Access version 4.0.0post build 3932 starting... 2013-05-02 14:05:35 INFO tlwebaccess[10582]: ThinLinc Web Access running as PID 10582 on port 300. 2013-05-02 14:05:35 ERROR tlwebaccess[10583]: bind: Address already in use 2013-05-02 14:05:36 ERROR tlwebaccess[10582]: tlstunnel has terminated unexpectedly. Exiting...
(In reply to comment #36) > When having a html5 session open (own tlstunnel process) then stopping > tlwebaccess service one cant start tlwebacces due to bind failure: > > 2013-05-02 14:05:35 INFO tlwebaccess[10582]: ThinLinc Web Access version > 4.0.0post build 3932 starting... > 2013-05-02 14:05:35 INFO tlwebaccess[10582]: ThinLinc Web Access running as PID > 10582 on port 300. > 2013-05-02 14:05:35 ERROR tlwebaccess[10583]: bind: Address already in use > 2013-05-02 14:05:36 ERROR tlwebaccess[10582]: tlstunnel has terminated > unexpectedly. Exiting... Fixed in 27293.
Upgrading of ThinLinc with active session works, but reconnecting to old sessions fails does to binary Xvnc update.
(In reply to comment #38) > Upgrading of ThinLinc with active session works, but reconnecting to old > sessions fails does to binary Xvnc update. Fixed in 27308.
Just a note, i have tested the server parts (build 3973) on Ubuntu 12.04, CentOS 6 (selinux) and SLED 11 Sp2 and it does work out of the box, when opening port 300 and starting the service.
Need to test: Cluster setup with Chrome browser.
Brief test with a Chromebook (with Chrome 26) shows satisfactory results - nothing obviously broken. (this comment was written with the html5 client from the demo system).
(In reply to comment #41) > Need to test: Cluster setup with Chrome browser. At a customers site which running RHEL 6 (2 masters and 2 agents) in their cluster there is a problem using chrome browser which fails to connect with: Failed to connect to server (code: 1008, reason: Missing session key) On ThinLinc side, everything is ok, session is created etc.
(In reply to comment #43) > (In reply to comment #41) > > Need to test: Cluster setup with Chrome browser. > > At a customers site which running RHEL 6 (2 masters and 2 agents) in their > cluster there is a problem using chrome browser which fails to connect with: > Failed to connect to server (code: 1008, reason: Missing session key) > > On ThinLinc side, everything is ok, session is created etc. This seems to affect firefox too, now when testing it from office, however firefox worked when i tested it on site.. :/
(In reply to comment #44) > (In reply to comment #43) > > (In reply to comment #41) > > > Need to test: Cluster setup with Chrome browser. > > > > At a customers site which running RHEL 6 (2 masters and 2 agents) in their > > cluster there is a problem using chrome browser which fails to connect with: > > Failed to connect to server (code: 1008, reason: Missing session key) > > > > On ThinLinc side, everything is ok, session is created etc. > > This seems to affect firefox too, now when testing it from office, however > firefox worked when i tested it on site.. :/ This was due to eraseCookie() was commented out at customers site and both browsers had old cookies.
When entering wrong password, there are 2 error messages displayed which clutters the ui and probably will confuse some users: - No response from PAM subsystem - Authentication failure The last one should be good enough.
(In reply to comment #46) > When entering wrong password, there are 2 error messages displayed which > clutters the ui and probably will confuse some users: > > - No response from PAM subsystem > > - Authentication failure > > The last one should be good enough. Fixed in 27417.
I have now tested the HTML5 client build 3960 using iPad. Setting config key /vsmagent/default_geometry to 1024x680 make the view fit the display perfectly on iPad, no need to pan around on desktop. I created a cert for my server name and downloaded cert for installation without any problems. Created a desktop link to the Html5 client WebApp and logged on without any problems. Tested the toolbar buttons and the clipboard functionlity which works as expected. When disconnecting while in WebApp mode I think one might want to get back to iOS desktop instead of showing a vnc disconnected message.
There is a strange error message when writing the wrong password, could this be a little more end-user friendly? "Failure setting user credentials"
I left a browser window with an active session open over the weekend, and it works as expected after 2.5 days, not hangs nor disconnect.
(In reply to comment #50) > There is a strange error message when writing the wrong password, could this be > a little more end-user friendly? > > "Failure setting user credentials" Fixed in 27448.
I have tested the html5 client in both single master/agent and clustered thinlinc setups and it works good with several authentication mechanisms, local, active directory and one time password without any problems. A lot of issues has been noticed, fixed or postponed into corresponding bugs. It does work well except several issues with keyboard inputs depending on browers/platforms but there is an upcoming rewrite of keyboard handling upstream so those issue are ignored for now.
It is possible to have both native client and html5 client connecting and viewing the same session without using shadowing. Reproducable by: Login and create a session with html5 client while logged on, start a native client and log in.
(In reply to comment #54) > It is possible to have both native client and html5 client connecting and > viewing the same session without using shadowing. > > Reproducable by: > > Login and create a session with html5 client while logged on, start a native > client and log in. This issue is related to bug #2251 due to there are no resources redirections available in the HTML5 client.
The current code does not handle Cookie headers with multiple cookies separated by semicolon. From http://tools.ietf.org/html/rfc6265#section-4.2.1: 4.2.1. Syntax cookie-header = "Cookie:" OWS cookie-string OWS cookie-string = cookie-pair *( ";" SP cookie-pair ) Currently, we are only parsing the first cookie-pair.
(In reply to comment #56) > The current code does not handle Cookie headers with multiple cookies separated > by semicolon. From http://tools.ietf.org/html/rfc6265#section-4.2.1: > > 4.2.1. Syntax > > cookie-header = "Cookie:" OWS cookie-string OWS > cookie-string = cookie-pair *( ";" SP cookie-pair ) > > Currently, we are only parsing the first cookie-pair. Fixed in 27497.
Installation fails on Solaris: 2013-06-10 14:45:21,238: Packages to upgrade: CENDthinlinctlmisc-4.1.0-3977-sparc, CENDthinlinctlmisclibs-4.1.0-3977-sparc, CENDthinlincvsm-4.1.0-3977-sparc, CENDthinlincvncserver-4.1.0-3977-sparc, CENDthinlincr desktop-4.1.0-3977-sparc, CENDthinlinctladm-4.1.0-3977-sparc, CENDthinlinctlprinter-4.1.0-3977-noarch, CENDthinlincwebaccess-4.1.0-3977-noarch 2013-06-10 14:45:28,304: Removing installed package(s): CENDthinlinctlmisc, CENDthinlinctlmisclibs, CENDthinlincvsm, CENDthinlincvncserver, CENDthinlincrdesktop, CENDthinlinctladm, CENDthinlinctlprinter, CENDthi nlincwebaccess 2013-06-10 14:46:15,335: Installing package(s): CENDthinlinctlmisc-4.1.0-3977-sparc, CENDthinlinctlmisclibs-4.1.0-3977-sparc, CENDthinlincvsm-4.1.0-3977-sparc, CENDthinlincvncserver-4.1.0-3977-sparc, CENDthinlin crdesktop-4.1.0-3977-sparc, CENDthinlinctladm-4.1.0-3977-sparc, CENDthinlinctlprinter-4.1.0-3977-noarch, CENDthinlincwebaccess-4.1.0-3977-noarch 2013-06-10 14:46:25,686: Installation of package failed: 2013-06-10 14:46:25,687: /var/sadm/pkg/CENDthinlincwebaccess/install/postinstall: PATH=/sbin:/usr/sbin:/usr/bin:/usr/sadm/install/bin:/opt/thinlinc/share/xdg-utils: is not an identifier 2013-06-10 14:46:25,688: pkgadd: ERROR: postinstall script did not complete successfully 2013-06-10 14:46:25,688: 2013-06-10 14:46:25,688: Installation of <CENDthinlincwebaccess> failed.
(In reply to comment #58) > Installation fails on Solaris: Should be fixed in r27506.
The move of Cheetah from tladm to tlmisc in r26470 breaks upgrades, at least on .deb systems. 2013-06-12 04:24:04,898: Warning during installation of '/home/aaron/tl-4.1.0-server/serverkit-linux/thinlinc-tlmisc_4.1.0-3974_i386.deb': " trying to overwrite '/opt/thinlinc/modules/Cheetah/convertTmplPathToModuleName.py', which is also in package thinlinc-tladm 4.0.0-3717" This leaves the packages in a strange state, where everything else is upgraded but tlmisc remains at v4.0.0.
Fixed in r27516.
(In reply to comment #60) > The move of Cheetah from tladm to tlmisc in r26470 breaks upgrades, at least on > .deb systems. > > 2013-06-12 04:24:04,898: Warning during installation of > '/home/aaron/tl-4.1.0-server/serverkit-linux/thinlinc-tlmisc_4.1.0-3974_i386.deb': > " trying to overwrite > '/opt/thinlinc/modules/Cheetah/convertTmplPathToModuleName.py', which is also > in package thinlinc-tladm 4.0.0-3717" > > This leaves the packages in a strange state, where everything else is upgraded > but tlmisc remains at v4.0.0. This was verified on bug #4443 comment #5
