Hi x2go-folks,
here is another question to the developers...
When talking to school teachers here in Kiel, there was a very central
demand to thin client work stations: run application on the thin
client hardware.
in schools this is needed for:
o accessing USB-devices like LEGO mind storm robots etc. o starting development environments on the thin client CPU (e.g. eclipse) so that programming of ROBOT devices can be tested locally o play media (DVD, AVI on CD or USB-Stick) on the thin client o start firefox locally (but with the user's profile), esp. because of flash media, but also animations on websites
As I know, in LTSP there is a solution for that (a weird bash script
called ltsp-localapp or so).
My question: is there also an idea or an approach for x2go how local
CPU usage of thin clients could be implemented? I suppose, there is no
implementation yet, is it?
My basic idea of how it could be done:
o mount $HOME of the x2goserver on the client via sshfs, this mount
should be
tunneled through the main SSH connection (I know this is the other way
round compared to x2goprint spool dir and shared folders... this
might need
some work and ideas before we go into deatails)
o issue a script call on the thin client
o set some environment variables on the thin client from within this script
($HOME, $USER etc.)
o let the x2goclient start the local app (like firefox, vlc,
mplayer, eclipse)
As this is probably the most needed feature herearound I'd love to go
into detail with this issue sometime in August/September.
Plz let me know what you think, Mike
--
DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419
eMail-LeseSchreibStunde: wochentags 8h-10h mail: m.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
On Fri, 2010-07-02 at 15:20 +0200, Mike Gabriel wrote:
Hi x2go-folks,
here is another question to the developers...
When talking to school teachers here in Kiel, there was a very central
demand to thin client work stations: run application on the thin
client hardware.in schools this is needed for:
o accessing USB-devices like LEGO mind storm robots etc. o starting development environments on the thin client CPU (e.g. eclipse) so that programming of ROBOT devices can be tested locally o play media (DVD, AVI on CD or USB-Stick) on the thin client o start firefox locally (but with the user's profile), esp. because of flash media, but also animations on websites
As I know, in LTSP there is a solution for that (a weird bash script
called ltsp-localapp or so).My question: is there also an idea or an approach for x2go how local
CPU usage of thin clients could be implemented? I suppose, there is no
implementation yet, is it?My basic idea of how it could be done:
o mount $HOME of the x2goserver on the client via sshfs, this mount
should be tunneled through the main SSH connection (I know this is the other way round compared to x2goprint spool dir and shared folders... this
might need some work and ideas before we go into deatails) o issue a script call on the thin client o set some environment variables on the thin client from within this script ($HOME, $USER etc.) o let the x2goclient start the local app (like firefox, vlc,
mplayer, eclipse)As this is probably the most needed feature herearound I'd love to go
into detail with this issue sometime in August/September.Plz let me know what you think, Mike
I could see a great use for this with multimedia/video files - John
Hello Mike,
Am 02.07.2010 15:20, schrieb Mike Gabriel:
Hi x2go-folks,
here is another question to the developers...
When talking to school teachers here in Kiel, there was a very central demand to thin client work stations: run application on the thin client hardware.
o start firefox locally (but with the user's profile), esp. because of flash media, but also animations on websites As I know, in LTSP there is a solution for that
LTSP is using (so far as I know) the local X-server on the Thin Client as native display. X2go is using x2goagent als natvive display so the window manager is running on another display (number). So there is the question how the local apps window should be managed, for example how it should be placed behind other applications, get the focus. There are further questions like: "what is happening on session suspend, concurring audio input, a different client cpu architecture,... This is not a "not possible" answer, we sure will add this feature to the whislist. But it is not a easy task and maybe some other ideas will help to archive the same result.
My question: is there also an idea or an approach for x2go how local CPU usage of thin clients could be implemented? I suppose, there is no implementation yet, is it?
The local machine is used for input device handling, as print server and the local X-Server is responsible for the display response user experience.
As this is probably the most needed feature herearound I'd love to go into detail with this issue sometime in August/September.
Plz let me know what you think, Mike
I think it is a very difficult task and if you don't want to offer it to all target devices available it might be possible for LAN usage. But it is sure a lot of work.
best regards,
Heinz
Hi Heinz,
On Fr 02 Jul 2010 20:33:19 CEST "Heinz-M. Graesing" wrote:
Hello Mike,
Am 02.07.2010 15:20, schrieb Mike Gabriel:
Hi x2go-folks,
here is another question to the developers...
When talking to school teachers here in Kiel, there was a very central demand to thin client work stations: run application on the thin client hardware.
o start firefox locally (but with the user's profile), esp. because of flash media, but also animations on websites As I know, in LTSP there is a solution for that
LTSP is using (so far as I know) the local X-server on the Thin Client as native display. X2go is using x2goagent als natvive display so the window manager is running on another display (number). So there is the question how the local apps window should be managed, for example how it should be placed behind other applications, get the focus.
As I understand x2go the x2goclient and also the x2go session window
(if not fullscreen) are running on one X display (x2goclienthost:0.0).
Within the x2go session window encapsulated there is the x2goagent
session that provides an X display applications running on the
x2goserver (e.g. appserver:50.0).
=> different hosts, different displays... this must be faced, good
point indeed!!
I have recently looked at an eagle TC more closely. An alternative
approach for x2go thin clients could be to provide a simple desktop
(e.g. cream desktop environment) on the thin client (I am talking
about Linux only for now... the approach should work on mixed setups
i386/amd64/ppc).
On these thin clients x2goclient does not run in full screen mode, it
rather runs as one of many client apps.
To provide local apps on the TC there are two possibilities:
- provide local apps on the thin client that use the TC's default
user profile:
disadvantage:
- thin client users work anonymously with these applications
- no individual user profiles are available
advantage:
- offered applications have pre-configured standard profiles
- sensible for multimedia software
- internet blockage can be an option (iptables/SELinux
on the thin client)2. login to an x2go session: the session login will add desktop icons/startmenu entries to the thin client and provide further local applications, that can now be run with user privileges
- the user's home dir will be mounted on the thin client through
x2go (reverse sshfs)
- thus, the user profile will be available on the TC
- local apps can with use privs can be started by clicking a desktop
icon on the cream desktop
- the local CPU resources are available to these applications
- also is the local hardware available
- users are indentifiable on the network (e.g. for firefox/dansguardian)
Consequently, using such a thin client would be like this:
o turn on TC o boot the TC image from the net (NBD rather than NFS???) o optional: boot a TC image that also installs a thin client image on the local -> netbooks with wireless network could be used as TCs o the user is offered a cream desktop with an x2goclient, mplayer, ... o the user starts x2goclient o and initiate an x2go client session (LDAP based, x2gocluster auto-assignment) o x2go now does in the background: - pulseaudio: server -> client - cupsprinting: server -> client (actually this is filesharing: client -> server) - filesharing: client -> server - homesharing: server -> client (sshfs) - x2go extends thin client cream desktop: icons, startmenu entries
o you now can choose while you work: 1. run apps within the x2go session (windows within a window) 2. run anonymous local apps (app windows, x2goclient main window and # x2go session window share one desktop) 3. run other local apps under your server uid
There are further questions like: "what is happening on session suspend,
o speakout a warning... o kill local TC apps that run under the user's server uid o disconnect home dir (reverse sshfs unmount) o disconnect everything else (pulse, fileshares, ...)
concurring audio input,
What exactly do you mean by this?
a different client cpu architecture,...
Thinclient arch and server arch can differ. Of course your thinclients
and the provided thinclient images must match in architecture... (i386
mostly).
This is not a "not possible" answer, we sure will add this feature to the whislist. But it is not a easy task and maybe some other ideas will help to archive the same result.
The above differs from my original idea as I had not taken the window
management of local apps that much into account. Thus, it got a bit
complexer now, blown up by a cream desktop.
If you have other ideas to make local CPU resources accessible let me know.
My question: is there also an idea or an approach for x2go how local CPU usage of thin clients could be implemented? I suppose, there is no implementation yet, is it?
The local machine is used for input device handling, as print server and the local X-Server is responsible for the display response user experience.
The great advantage of this approach is clarity!!! One machine is the
server, the other machine is the client. The approach is very valuable
but also has its limits when it comes to
o running CPU intensive processes (yukky Flashplayer e.g.) o accessing local hardware in schools' computer labs o playing movies from local devices
As this is probably the most needed feature herearound I'd love to go into detail with this issue sometime in August/September.
Plz let me know what you think, Mike
I think it is a very difficult task and if you don't want to offer it to all target devices available it might be possible for LAN usage. But it is sure a lot of work.
LAN usage should definitely be the first target.
Next could be a backgrounded thinclient image installer for Netbook
Thinclients:o all LAN-clients receive a thinclient only image o but now you plugin one of the schools netbooks that also shall be able to use Wireless LAN o these netbooks that get recognized by its mac address retrieve the thinclient+background-installer image o while the session is running, a local thinclient image is installed to the hard or solidstate disk of the netbook o shutdown o unplug LAN o boot netbook from disk o thinclient starts from disk with WiFi support o upgrade your netbook TC image: plugin on LAN again, boot from the net...
Difficult on Windows Systems (Home dir useless, sucking registry ...).
It might be possible to find solutions for individual applications
(e.g. firefox).MacOS is a Unix derivative... But I have not played with Macs that
often. Magic like this should be possible on Macs rather than on
windows clients
One demand probably is that software versions on thinclients and on
the terminalserver should not differ too much, if you want to use the
user profiled local application thing. For admins this will mean that
they have to keep their thinclient images rather up-to-date (i.e. run
same distroversion as the servers). Thin clients then also need
security updates regularly...
best regards,
Heinz
Thanks for your input!!! Mike
--
DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419
eMail-LeseSchreibStunde: wochentags 8h-10h mail: m.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
-
Heinz-M. Graesing -
John A. Sullivan III -
Mike Gabriel