Proposed enhancement for ltsp-localapps

[Georg Klimm]

17,22d16
< if [ -z "$LTSP_CLIENT" ]
< then
< $CMD $ARGS
< exit 0
< fi
<

This allows one unique menuentry for LSTP-clients and other (i.e. X2Go-Clients) on the same server

[Vagrant Cascadian (vagrantc)]

Could you elaborate on this? Are you saying to remove the check for the LTSP_CLIENT variable?

I would be surprised if localapps work in environments outside of LTSP, though if someone can demonstrate it works, it's worth considering...

[David Schramm (daschr)]

@vagrantc I think he's talking about adding an additional check whether ltsp-localapps is executed with an ltsp client connected or not (which means that $LTSP_CLIENT would be unset).

Obviously, in case that no ltsp client exists, the command will be executed on the host ltsp_localapps is run from, e.g the server.

It allows us to use a DE without making any difference between the client type.

For example:

[David Schramm (daschr)]

... On IceWM:
              -we've got a toolbar entry for firefox, since firefox is also installed an the client image, we naturally want to run it with ltsp_localapps
              -when an ltsp client connects, $LTSP_CLIENT is set, so on ltsp_localapps runs normally
              -when an x2go client connects, $LTSP_CLIENT is unset, so on ltsp_localapps executes the command (firefox) on the server and logically firefox is run for the connected x2go client

[Launchpad Janitor (janitor)]

[Expired for LTSP because there has been no activity for 60 days.]