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:
1.
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.
1.
LAN usage should definitely be the first target.
2.
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...
3.
Difficult on Windows Systems (Home dir useless, sucking registry ...).
It might be possible to find solutions for individual applications
(e.g. firefox).
4.
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: [email protected], http://das-netzwerkteam.de
freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb
_______________________________________________
X2go-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/x2go-dev
