On 10/09/2017 12:44 PM, Frank Steiner wrote:

I was able to solve this. When I looked into the code, I saw that you already to use "bash -c '...'" for all commands, so quoting shouldn't be an issue.

I really think it can get problematic easily, for instance with nested single quotes, that require special handling that differs from shell to shell - same thing for double quotes.

Looks like you weren't hit by that issue, though. :)

But as the error message for tcsh was about Warning: Protocol mismatch or no X authentication data. I started looking at xauth and found an interesting difference between bash and tcsh as login shell.

For bash, these entries are added by x2gostartagent:

myhost/unix:59 MIT-MAGIC-COOKIE-1 e938deb788659f0bf8c99069d199aff6 myhost.ifi.lmu.de:59 MIT-MAGIC-COOKIE-1 e938deb788659f0bf8c99069d199aff6 myhost.ifi.lmu.de:59 MIT-MAGIC-COOKIE-1 e938deb788659f0bf8c99069d199aff6

I knew that we're adding two entries, but it didn't come across that this might be the issue. Great debugging! Thanks.

What feels odd is that there are three entries, two of which are equal. I'm not sure where the third one is coming from - in a quick test, I only see two entries on one of my sessions. Might be related to nxproxy adding another entry via xauth as well, but it still feels odd.

Especially given that the two xauth calls in x2gostartagent both use ${HOSTNAME}, if ${HOSTNAME} is only "myhost", there should only be entries for myhost/unix:DISPLAY and myhost:DISPLAY.

For tcsh, I got those: myhost.ifi.lmu.de/unix:58 MIT-MAGIC-COOKIE-1 7212fb8aa466de75ea0224a4d010f5e4 myhost.ifi.lmu.de:58 MIT-MAGIC-COOKIE-1 7212fb8aa466de75ea0224a4d010f5e4 myhost.ifi.lmu.de:58 MIT-MAGIC-COOKIE-1 7212fb8aa466de75ea0224a4d010f5e4

And that's the point! For some reason, x2go needs the cookie for display "myhost/unix" at some point and "myhost.ifi.lmu.de/unix" doesn't suffice.

Indeed, when I wrote a little bash script

#!/bin/bash echo $HOSTNAME

and called it with "ssh myhost bash -c './testscript'", it echoed "myhost" with login shell bash, and "myhost.ifi.lmu.de" with login shell tcsh.

That's very interesting. bash seems to automatically populate HOSTNAME according to its man page, but the tcsh man page doesn't mention HOSTNAME at all -- only HOST, which is populated automatically by the gethostname() libc call and (on my system) returns the short hostname.

I guess HOST and HOSTNAME might be the shell equivalents.

It gets worse, though. I tested this on OS X, which is a BSD-like system. On this system, tcsh's HOST and bash's HOSTNAME values were the same again, BUT both included the domain name (and, incidentally, the 'hostname' program's default behavior is to print the FQDN hostname, which corresponds to the hostname returned by gethostname().)

This may not sound interesting at first, because OS X is not an X2Go Server target, but according to the hostname man pages on FreeBSD, this matches this system's behavior (and it would be nice to eventually support *BSD as well at some point in time, even though that's not possible currently.)

Luckily, all of them support the -s flag to hostname, so I'll just make use of it.

I'm not yet sure where this difference comes from, if it's deep inside bash and tcsh or in some server-wide login scripts from SuSE (it was not in the users dotfiles, we even removed them all).

Whatever sets it, it's not tcsh itself. Likely some global startup script. Care to grep -R HOSTNAME /etc?

The problem at hand really is that something sets and exports HOSTNAME. Since this variable is then defined in the environment, bash won't touch it. Clearly x2gostartagent uses bash (even if called from a tcsh shell) - but it inherits the exported HOSTNAME value and stuff goes boom. In my opinion, that's a bug that the distro should take care of. IMHO, the global startup scripts can set HOSTNAME, but shouldn't export this variable to the environment.

Anwyay, I added "setenv HOSTNAME uname -n" to my .cshrc and: x2go works :-)

Better use hostname -s.

To make that work for all our users I added HOSTNAME=${HOSTNAME%%.*} into x2gostartagent which doesn't harm if HOSTNAME is already without the domain. So maybe you could add this to the next release to help people running into the same issue.

I'll fix up the server script.

Mihai