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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ x2go-user mailing list x2go-user@lists.x2go.org https://lists.x2go.org/listinfo/x2go-user
