Mailinglist Archive: opensuse (929 mails)

< Previous Next >
[opensuse] Re: getting and preserving Display & Session when remotely logging in
Anton Aylward wrote:
Maybe socat could do the job?
There's this example: <quote> socat UNIX-LISTEN:/tmp/.X11-unix/X1,fork

The problem is not in establishing a normal X11 based session w/o

There are various levels of problems some of which I have workarounds

The first and easiest is "simple X (& no GLX ) --

That one I just need the name of the remote system.

The solution with socat would also need the remote system name.

That is made available to pam during authentication by ssh. After that
it is no longer available. the "pam_env" module can translate that
remote host into an ENV var (aka "REMOTE_HOST") via the config file in
/etc/security/pam_env.conf. with the line: REMOTEHOST DEFAULT=""
OVERRIDE=@{PAM_RHOST} (or alternatively:) REMOTEHOST DEFAULT=localhost

This is only available when 'ssh' make contact with the system. The
problem her, is that OpenSuse's "pam" maintainer arrogated the usage of
pam_env from it's previous once/system-auth role to using it as a lazy
way to re-initialize per-session state. Unfortunately, in that it
doesn't save the previous REMOTEHOST or DISPLAY, it fails preserve what
is necessary for the new session to be useful. AFAIK, the only value
saved between sessions is the antiquated, but still useful 'TERM'

The intent, clearly is to preserve display settings, but this isn't an
option in the su program (though it is configurable in the 'sudo'
program). Any other program that starts a new session in Suse, will, by
default clear your DISPLAY and REMOTEHOST settings.

The workaround there, is to undo inserting pam_env into the /etc/pam.d
session files and have it only in the 'auth' section. But that's now,
a non-standard configuration in OpenSuse (though standard in the rest of
the world).


The *second* main problem which is the focus of my current problems, is
that GLX also needs to run remotely. It has the ability to do so, but
is not doing so.

The *third* main problem is that with the implementation of using
"session" based settings, vs. "home-directory" based settings, all
settings are based on a local system DBUS connection -- which again --
doesn't exist if you are logged in remotely.

*EVEN* if you have a local dbus (are running under Cygwin, for example,
under windows), DBUS wasn't designed for remote usage and I have yet to
come up with a config that will allow the remote system to use my
LOCAL dbus -- something that would often be more useful: Example:
remote application wants to open a URL: Would be far preferable for
it to be opened via my local browser, rather than trying to run the same
browser via 'X' on the remote system.

Without the DBUS connection, settings in applications are not saved
between invocations. Saving state in wireshark -- no longer works.
Saving options in firefox -- no longer works. They are all looking to
store info on the session DBUS connection. which doesn't work remotely.

linux systems which used to have stellar options to work on remotely, are
slowly having their abilities eroded which will make it much harder to use
in mixed platform environments (like most of the world).

To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse+owner@xxxxxxxxxxxx

< Previous Next >