xpra icon
Bug tracker and wiki

#597 closed defect (fixed)

"initenv" connection error when using nested ssh - regression in 0.13.4

Reported by: onlyjob Owned by: nomnomnom
Priority: blocker Milestone: 0.14
Component: client Version: 0.13.x
Keywords: Cc:

Description

I connect to my session remotely using the following (sample) command:

xpra attach --ssh="ssh -A -t user@my.gateway.com ssh -A" ssh:localserver:33

Upgrading client from 0.13.3 to 0.13.4 broke this functionality -- now Xpra just prints usage information and the following error

xpra: error: invalid mode 'initenv'

Server is running 0.13.3.

Change History (27)

comment:1 Changed 15 months ago by totaam

  • Owner changed from antoine to onlyjob

xpra initenv was added to ensure we can use xpra start ssh:HOST:DISPLAY, it creates the environment if it doesn't exist already.

So, upgrading your server to 0.13.4 should get rid of the warning about "initenv" being missing.
It doesn't explain the failure though. Do you only get the failure when using --ssh=...?

comment:2 Changed 15 months ago by totaam

Maybe this helps:

Index: xpra/scripts/main.py
===================================================================
--- xpra/scripts/main.py	(revision 6710)
+++ xpra/scripts/main.py	(working copy)
@@ -833,7 +833,7 @@
     if dtype == "ssh":
         cmd = display_desc["full_ssh"]
         proxy_cmd = display_desc["remote_xpra"] + display_desc["proxy_command"] + display_desc["display_as_args"]
-        cmd += ["xpra initenv;"+(" ".join(proxy_cmd))]
+        cmd += ["xpra initenv 2>& /dev/null;"+(" ".join(proxy_cmd))]
         try:
             kwargs = {}
             kwargs["stderr"] = sys.stderr

This will show you what ssh command line ends up being used:

Index: xpra/scripts/main.py
===================================================================
--- xpra/scripts/main.py	(revision 6710)
+++ xpra/scripts/main.py	(working copy)
@@ -849,7 +849,7 @@
                 kwargs["stderr"] = PIPE
             if debug_cb:
                 debug_cb("starting %s tunnel" % str(cmd[0]))
-                #debug_cb("starting ssh: %s with kwargs=%s" % (str(cmd), kwargs))
+            print("starting ssh: %s with kwargs=%s" % (str(cmd), kwargs))
             child = Popen(cmd, stdin=PIPE, stdout=PIPE, **kwargs)
         except OSError, e:
             raise Exception("Error running ssh program '%s': %s" % (cmd, e))

comment:3 Changed 15 months ago by onlyjob

Thanks for quick response. Yes problem is only with "--ssh" (apparently introduced in r6696).
Patch did not fix this problem -- now error is

bash: /dev/null: ambiguous redirect

"starting ssh" printed the following:

starting ssh: ['ssh', '-A', '-t', 'user@my.gateway.com', 'ssh', '-A', '-T', 'localserver', 'xpra initenv 2>& /dev/null;.xpra/run-xpra _proxy :22'] with kwargs={'stderr': <open file '<stderr>', mode 'w' at 0x7f6f871ca1e0>}

comment:4 Changed 15 months ago by totaam

That ssh does look malformed.

Can please you post what the command should look like, by applying the print patch to an older version?

comment:5 Changed 15 months ago by onlyjob

Here you go:

starting ssh: ['ssh', '-A', '-t', 'user@my.gateway.com', 'ssh', '-A', '-T', 'localserver', '.xpra/run-xpra', '_proxy', ':22'] with kwargs={'stderr': <open file '<stderr>', mode 'w' at 0x7f9a6b6541e0>}

comment:6 Changed 15 months ago by totaam

Ah, it isn't malformed. I think that what is happening is that the ";" is being caught by the outer ssh and not the inner one.
Not sure how to deal with this.. ideas? Maybe adding quotes around would help?
As in:

"xpra initenv 2>& /dev/null;.xpra/run-xpra _proxy :22"

(we want this to be executed as a unit)

comment:7 Changed 15 months ago by totaam

I believe r6746 fixes this.

Please confirm so I can backport.

comment:8 Changed 15 months ago by onlyjob

In a way it does fix it but incorrectly:

starting ssh: ['ssh', '-A', '-t', 'user@my.gateway.com', 'ssh', '-A', '-T', 'localserver', "'xpra initenv;.xpra/run-xpra _proxy :22'"] with kwargs={'stderr': <open file '<stderr>', mode 'w' at 0x7f99320ac1e0>}
Pseudo-terminal will not be allocated because stdin is not a terminal.
2014-06-12 18:47:01,446 detected keyboard: rules=evdev, model=pc104, layout=us,ru
2014-06-12 18:47:01,446 desktop size is 3600x1080 with 1 screen(s):
2014-06-12 18:47:01,447   ':0.0' (949x284 mm) workarea: 3600x1038 at 0x42
2014-06-12 18:47:01,447     VGA1 1920x1080 (510x287 mm)
2014-06-12 18:47:01,447     LVDS1 1680x1050 at 1920x0 (331x207 mm)
Usage: 
        xpra start DISPLAY
        xpra stop [DISPLAY]
        xpra exit [DISPLAY]
        xpra list
        xpra upgrade DISPLAY
        xpra attach [DISPLAY]
        xpra detach [DISPLAY]
        xpra screenshot filename [DISPLAY]
        xpra info [DISPLAY]
        xpra control DISPLAY command [arg1] [arg2]..
        xpra version [DISPLAY]
        xpra shadow [DISPLAY]


xpra: error: invalid mode 'initenv'
2014-06-12 18:47:02,628 server: Linux debian 7.5 , Xpra version 0.13.3 (r6658)
2014-06-12 18:47:02,630 Attached to ssh:localserver:22 (press Control-C to detach)

Here is a better way:

@@ -826,9 +826,9 @@
     conn = None
     if dtype == "ssh":
         cmd = display_desc["full_ssh"]
         proxy_cmd = display_desc["remote_xpra"] + display_desc["proxy_command"] + display_desc["display_as_args"]
-        cmd += ["xpra initenv;"+(" ".join(proxy_cmd))]
+        cmd += ["sh -c 'xpra initenv 2>&1 >>/dev/null; "+(" ".join(proxy_cmd))+"'"]
         try:
             kwargs = {}
             kwargs["stderr"] = sys.stderr
             if not display_desc.get("exit_ssh", False) and os.name=="posix" and not sys.platform.startswith("darwin"):

which works as follows:

starting ssh: ['ssh', '-A', '-t', 'user@my.gateway.com', 'ssh', '-A', '-T', 'localserver', "sh -c 'xpra initenv 2>&1 >>/dev/null; .xpra/run-xpra _proxy :22'"] with kwargs={'stderr': <open file '<stderr>', mode 'w' at 0x7f278b9a61e0>}

comment:9 Changed 15 months ago by totaam

"incorrectly"? How so?
The only difference is the redirection of the error (which is optional really).

I don't understand why we would also need the sh -c?

comment:10 Changed 15 months ago by onlyjob

Please look at the output which still prints xpra: error: invalid mode 'initenv' and shows usage info. How can I possibly demonstrate it any better?

With "sh -c" wrapping everything works smooth. I'm not sure how to explain but that's the way it work when tested.

comment:11 Changed 15 months ago by onlyjob

By the way redirection of error is not optional.

comment:12 Changed 15 months ago by totaam

How can I possibly demonstrate it any better?


We are talking about different things.

The warning message is a different issue from the connection failure.

I am interested in the minimal fix to backport. Adding shell redirection, etc, can wait.

comment:13 Changed 15 months ago by onlyjob

Shell and redirection seems to be a minimal fix that takes care of warnings too. Shell without redirection produces connection error...

comment:14 Changed 15 months ago by onlyjob

cmd += ["'xpra initenv 2>&1 >> /dev/null;"+(" ".join(proxy_cmd))+"'"] in r6748 breaks it again:

starting ssh: ['ssh', '-A', '-t', 'user@my.gateway.com', 'ssh', '-A', '-T', 'localserver', "'xpra initenv 2>&1 >> /dev/null;.xpra/run-xpra _proxy :22'"] with kwargs={'stderr': <open file '<stderr>', mode 'w' at 0x7f176d4cf1e0>}
Pseudo-terminal will not be allocated because stdin is not a terminal.
2014-06-12 19:23:13,181 detected keyboard: rules=evdev, model=pc104, layout=us,ru
2014-06-12 19:23:13,181 desktop size is 3600x1080 with 1 screen(s):
2014-06-12 19:23:13,181   ':0.0' (949x284 mm) workarea: 3600x1038 at 0x42
2014-06-12 19:23:13,181     VGA1 1920x1080 (510x287 mm)
2014-06-12 19:23:13,182     LVDS1 1680x1050 at 1920x0 (331x207 mm)
2014-06-12 19:23:14,169 Received uninterpretable nonsense: "Usage: \n\txpra start DISPLAY\n\txpra stop [DISPLAY]\n\txpra exit [DISPLAY]\n\txpra list\n\txpra upgrade DISPLAY\n\txpra attach [DISPLAY]\n\txpra detach [DISPLAY]\n\txpra screenshot filename [DISPLAY]\n\txpra info [DISPLAY]\n\txpra control DISPLAY command [arg1] [arg2]..\n\txpra version [DISPLAY]\n\txpra shadow [DISPLAY]\n\n\nxpra: error: invalid mode 'initenv'\n"
2014-06-12 19:23:14,374 Connection lost

Please believe me, sh -c is required and necessary. Command from my patch works the best, I tested it. Thanks.

comment:15 Changed 15 months ago by totaam

Hah, you're right. Applied in r6749 (will backport). Even though the command is run in a shell, the redirection strings are passed to the xpra command instead.

I must have tested it wrong. Bear with me, I'm doing 20 things at a time today.

BTW, for reference, here's the easiest way I found of testing for this bug:

  • temporarily disable initenv in local installation:
    --- xpra/scripts/main.py	(revision 6750)
    +++ xpra/scripts/main.py	(working copy)
    @@ -643,7 +643,7 @@
             elif mode in ("_proxy", "_proxy_start", "_shadow_start") and (supports_server or supports_shadow):
                 nox()
                 return run_proxy(parser, options, script_file, args, mode)
    -        elif mode == "initenv":
    +        elif mode == "initenv-disabled!":
                 from xpra.scripts.server import xpra_runner_shell_script, write_runner_shell_script
                 script = xpra_runner_shell_script(script_file, os.getcwd(), options.socket_dir)
                 dotxpra = DotXpra(options.socket_dir)
    
  • make a session:
    xpra start :10
    
  • connect to it via nested local ssh:
    xpra attach --ssh="ssh -A -t localhost ssh -A" ssh:localhost:10
    

comment:16 Changed 15 months ago by onlyjob

Awesome, thank you. :)

comment:17 follow-up: Changed 15 months ago by totaam

  • Resolution set to fixed
  • Status changed from new to closed

Backport to v0.13.x done in r6751. Closing, thanks!

Note: this code will break if the proxy command specified has single quotes in it. I don't think I want to care about that and write yet more code, this could be endless!

PS: saw that your screen resolution was not in the default xorg.conf we ship, so r6752 added it.

comment:18 Changed 15 months ago by totaam

  • Summary changed from 0.13.4: regression from 0.13.3 to "initenv" connection error when using nested ssh - regression in 0.13.4

(editing bug title to make it easier to find what this is about)

comment:19 in reply to: ↑ 17 Changed 15 months ago by onlyjob

Replying to totaam:

PS: saw that your screen resolution was not in the default xorg.conf we ship, so r6752 added it.


Thank you very much for this. I know that wasn't the first time you've added my new resolution. :)
It reminded me about an idea: could you please include commented command that you use to generate new mode lines to "/etc/xpra/xorg.conf"? This way when new modeline is needed it can be easily generated using provided sample command. Thanks.

comment:20 follow-up: Changed 15 months ago by totaam

I've added more info:

comment:21 in reply to: ↑ 20 Changed 15 months ago by onlyjob

Replying to totaam:

I've added more info:


That's nice, thanks. But I've mentioned sample command because you are using a particular refresh rate to generate your Modelines. Without knowing your preferred refresh rate I can't generate Modelines same as yours.

Besides gtf and cvt commands are provided by package xserver-xorg-core on Debian so they should be already available on most systems.

comment:22 Changed 15 months ago by totaam

I don't have a preferred refresh rate, any will do. I don't think it makes any difference whatsoever since it isn't exposed to client applications. I've added yet more information: wiki/Xdummy

comment:23 Changed 14 months ago by nomnomnom

I just got this issue after upgrading my client on Debian to v0.13.5. It seems that the client is getting the usage message from the server (v0.12.3 in my case) when it doesn't support the initenv subcommand. The current fix (2>&1 >> /dev/null) doesn't seem to fix it. The usage message comes out of stderr and this command redirects stderr to stdout so it still comes back across ssh. It should be "> /dev/null 2>&1". Ie, redirect stderr after redirecting stdout (I assume you want to send both streams to /dev/null). If you redirect to stderr to stdout before redirecting stdout stderr will end up pointing to whatever stdout was pointing to at the time you redirected it, which was the pty.

See here for more on the ordering for redirections: http://wiki.bash-hackers.org/syntax/redirection#multiple_redirections

comment:24 Changed 14 months ago by totaam

  • Resolution fixed deleted
  • Status changed from closed to reopened

Applied in r6864.

Despite the fact that the link is to a bash site, I assume that the fix works equally well for other shells?

Does that work for you? onlyjob?

Last edited 14 months ago by totaam (previous) (diff)

comment:25 Changed 14 months ago by totaam

  • Owner changed from onlyjob to nomnomnom
  • Status changed from reopened to new

Not heard back from onlyjob, nomnomnom?

comment:26 Changed 14 months ago by onlyjob

Thanks, r6864 works as expected. I think it also fixes https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752500

Works for me, should work in other shells too. Thanks.

comment:27 Changed 14 months ago by totaam

  • Resolution set to fixed
  • Status changed from new to closed

Backported in r6886. Closing.

Note: See TracTickets for help on using tickets.