Matthew Rubenstein
2018-02-06 19:08:13 UTC
Package: x2goclient, x2gostartagent
Version: 4.0.5.1
Severity: wishlist
Hello. x2goclient and x2gostartagent (and the rest of X2Go) use
libssh, but do not use either the local ssh ~/.ssh/environment or the
remote sshd ~/.ssh/rc . Neither does X2Go use its own corresponding
config files for the remote environment. X2Go will use the remote
~/.bashrc when X2Go starts the remote bash shell, but if that .bashrc
quits upon detecting a non-interactive bash session (such as the ones
X2Go creates) then those .bashrc configs aren't applied to the X2Go
session. That non-interactive=quit logic is standard practice, and
indeed Ubuntu's /etc/skel/.bashrc includes it (among many other
distros).
This lack of X2Go session configuration can cause remote client
applications to fail. Especially where the X2Go 'Session type' =
'Single application', where the environment X2Go is using was set per-
user at (interactive) login prior to using X2Go. The hackaround is to
create a per-user wrapper that sets the environment (but can't just
source ~/.bashrc for the non-interactive session). This is unmanageable
especially for multiple users and multiple local/remote hosts, and
makes setting the remote environment complex and time consuming
(compared to the basic X2Go invocation configuration). It also requires
the user have access to the remote filesystem, probably to a remote
shell, and to use it to write freeform wrappers.
The best support for setting the environment would use a local
~/.x2gorc that can set the remote environment with bash syntax,
overridden by a GUI in x2goclient, overridden by a remote ~/.x2gorc ,
with perhaps system defaults local and remote in /etc/x2go/.x2gorc .
The X2Go config files/GUI could include an option to use their
ssh(d)equivalents, ie. [. ~/.ssh/environment].
Version: 4.0.5.1
Severity: wishlist
Hello. x2goclient and x2gostartagent (and the rest of X2Go) use
libssh, but do not use either the local ssh ~/.ssh/environment or the
remote sshd ~/.ssh/rc . Neither does X2Go use its own corresponding
config files for the remote environment. X2Go will use the remote
~/.bashrc when X2Go starts the remote bash shell, but if that .bashrc
quits upon detecting a non-interactive bash session (such as the ones
X2Go creates) then those .bashrc configs aren't applied to the X2Go
session. That non-interactive=quit logic is standard practice, and
indeed Ubuntu's /etc/skel/.bashrc includes it (among many other
distros).
This lack of X2Go session configuration can cause remote client
applications to fail. Especially where the X2Go 'Session type' =
'Single application', where the environment X2Go is using was set per-
user at (interactive) login prior to using X2Go. The hackaround is to
create a per-user wrapper that sets the environment (but can't just
source ~/.bashrc for the non-interactive session). This is unmanageable
especially for multiple users and multiple local/remote hosts, and
makes setting the remote environment complex and time consuming
(compared to the basic X2Go invocation configuration). It also requires
the user have access to the remote filesystem, probably to a remote
shell, and to use it to write freeform wrappers.
The best support for setting the environment would use a local
~/.x2gorc that can set the remote environment with bash syntax,
overridden by a GUI in x2goclient, overridden by a remote ~/.x2gorc ,
with perhaps system defaults local and remote in /etc/x2go/.x2gorc .
The X2Go config files/GUI could include an option to use their
ssh(d)equivalents, ie. [. ~/.ssh/environment].