• On 11/16/2017 07:41 AM, Ulrich Sibiller wrote:

Fine! Now that we debugged this with ~60 mails we finally have a working system. But to me it is still unclear what was causing the NIS problems!?

There wasn't a NIS issue to begin with.

What we learned is that X authorization is a fragile construct and easy to get wrong.

Within x2gostartagent, we create an X authorization cookie and add it to the newly spawned nxagent instance - once with the hostname (for TCP connections) and another time with the hostname and a /unix postfix (for UNIX socket connections).

Historically, we've been doing that by relying on bash's HOSTNAME variable, which is (normally) automatically set to the system's hostname. It turned out that relying on that is not a good idea, though, since it can easily be overridden.

Example: bash -c 'echo $HOSTNAME'; env HOSTNAME=outofluck bash -c 'echo $HOSTNAME' japsand outofluck

And of course, there's no way to get the original value back, since it's only set once at process startup IFF such a variable does not exist in the environment yet:

env HOSTNAME=outofluck bash -c 'echo $HOSTNAME; unset HOSTNAME; echo $HOSTNAME' outofluck

Thus, I looked for a more reliable way to get the hostname, and of course there is: the hostname program.

In a previous bug report, a user with tcsh as its default logging shell reported problems starting sessions. This was tracked down to a system startup script exporting HOSTNAME to the environment with a FQDN (because tcsh and csh do not define HOSTNAME as a standard variable that is set by the shell by default, but a lot of scripts nevertheless seem to use it, so the distro decided to be smart and provide it globally using this way), overriding bash's autodetected value of HOSTNAME. Since using a FQDN failed in his case, I (wrongly) inferred, that X authorization always needs a short host name to work, not a FQDN.

This proved be to be wrong, but to be working *sometimes*, which made the matter worse.

Hostname: F.Q.D.N DNS/hosts file: shortname mapping to 127.0.0.1 xauth: cookie added via using shortname

=> works!

Hostname: F.Q.D.N DNS/hosts file: shortname mapping to a public IPv4 address (non-loopback!) xauth: cookie added via shortname

=> fails

Hostname: F.Q.D.N DNS/hosts file: doesn't matter xauth: cookie added via F.Q.D.N

=> works!

Hostname: shortname DNS/hosts file: doesn't matter xauth: cookie added via shortname

=> works

The gist is that we should always add the X authorization cookie with the actual system host name, instead of using a shortname or the FQDN explicitly. Otherwise, X authorization might or might not work depending on other factors, but in most cases it will fail.

The second issue was due mixing old nx-libs packages with the newer Arctica version. Using x2goserver-x2goagent is very important with nx-libs 3.5.99.x+, since this package also implicitly disables the ld preloading hack we've been using for Xinerama support in the past. Using the ld preloading hack with nx-libs 3.5.99.x+ leads to such odd errors when applications try to utilize libX11.

Mihai