Xpra: Ticket #1169: xpra agent for osx - ssh start support

Follow up from ticket:391#comment:11: in order to support things like shadowing over ssh in one command, ie: xpra shadow ssh:OSXHOST, we need to start a per-user agent instance which will just sit there and wait for the ssh process to request it to run.

Sun, 15 May 2016 09:16:59 GMT - Antoine Martin: owner changed

Mostly working as of r12589.

OSX now supports the same feature already available on all the other posix systems:

xpra shadow ssh:$MACIP

To clone the display to your local machine.


@afarr: this is a FYI, may be useful to know about. Feel free to just close.

Thu, 19 May 2016 23:04:18 GMT - alas: owner changed

Hmm... spent a while actually trying to get some handle on shadow servers... but when I launch an osx 0.18.0 r12587 (the .pkg from your /beta repo) with ./xpra shadow ssh:MY-IP... while I get the desktop dimensions outputting on the osx server - I can't seem to find any sign of a server successfully launching with a xpra list & when I try to connect with a windows client (which works, but not very well, using --bind-tcp=) I fail with the following error client-side:

2016-05-19 16:00:46,101 xpra initialization error:
2016-05-19 16:00:46,102  cannot find any live servers to connect to
2016-05-19 16:00:46,10

Using -d all on both sides doesn't seem to expose any further details.

I did see something in the :0.log file saying to try from a GUI launcher, but I don't see any shadow options from the GUI launched from /Applications.

With all those caveats... I'll hand this back to you (I guess I know now) to close or, if there's anything you'd like me to try further, pass it back.

Sat, 21 May 2016 05:33:04 GMT - Antoine Martin: owner changed

Maybe you misunderstand what "xpra shadow ssh" does, you run this command from a client (which does not have to be an osx system at all) and you use it to connect to a OSX (or Linux) server with an existing desktop session already running.

The fact that you are showing the command as ./xpra tells me that you are probably running from an OSX system, connecting to itself? What does which works, but not very well mean?

You can also start a shadow server and connect to it later via tcp or ssh.

I did find a bug which can cause connections to drop (fixed in r12620), but that's only after the connection has been established and after you see the full desktop shown as window on the client. And some keyboard mapping issues have been fixed, see ticket:1171#comment:1. I also saw one crash with "Bus error 11", which seems to be cause by webp and should be fixed in trunk as of r12631.

Fri, 01 Jul 2016 19:35:00 GMT - J. Max Mena:

Attempting to run the shadow server with 18.X r12856:

Perhaps I'm missing something? I made sure to install it via the .pkg - when I don't feed it the SSH IP it works fine and sits there ready to go - even creating the icon up in the....system tray? By the clock - that'll let me stop the server.

Tue, 12 Jul 2016 16:52:22 GMT - Antoine Martin: milestone changed

Milestone renamed

Sun, 21 Aug 2016 05:32:30 GMT - Antoine Martin: owner, status changed

Disabled in r13412 because the PKG would break on OSX 10.11.x, see ticket:641#comment:31 for details.

Sun, 21 Aug 2016 06:52:10 GMT - Antoine Martin: owner, status changed

The launch agent is restored on OSX < 10.11.x using a postinstall script to install it after checking for SIP. (will backport to v0.17.x) On OSX 10.11.x onwards, not sure what we're supposed to do. The documentation: Creating Launch Daemons and Agents says nothing about security or SIP. So we can't support it.

Fri, 30 Sep 2016 19:44:39 GMT - alas: owner changed

Well, since it happens I have a 10.9.5 osx machine, I guess I'm testing this now (with a windows 8.1 client).

Read the documentation and finally figured out what a shadow server is supposed to do. Was able to connect to a 1.0 r13937 osx shadow server using tcp (rather than ssh), with a 1.0 r13888 win32 client.

Launching the shadow server with xpra shadow --no-daemon --bind-tcp={IP}:{port} -d all and then trying to connect with xpra_cmd.exe shadow ssh:{IP}:{port} -d all the server seems to start without any problems, but when I try to connect the client, I get the following error:

2016-09-30 12:15:29,055 failed to connect
Traceback (most recent call last):
  File "xpra\scripts\main.pyc", line 1513, in connect_or_fail
  File "xpra\scripts\main.pyc", line 1559, in connect_to
TypeError: can only concatenate list (not "str") to list
2016-09-30 12:15:29,056 run_mode error
Traceback (most recent call last):
  File "xpra\scripts\main.pyc", line 132, in main
  File "xpra\scripts\main.pyc", line 1156, in run_mode
  File "xpra\scripts\main.pyc", line 2133, in run_remote_server
  File "xpra\scripts\main.pyc", line 1520, in connect_or_fail
InitException: connection failed: can only concatenate list (not "str") to list
xpra initialization error:
 connection failed: can only concatenate list (not "str") to list

In case the error was the result of using --bind-tcp=, I also tried using --bind-ssh= when launching the osx shadow server. (The steps for the self generated certs listed in your SSL wiki worked for osx as well, to all appearances, when also adding --ssl-server-verify-mode=none.)

I wound up with exactly the same error client-side with --bind-ssl=.

I guess I'll pass this back to you.

Sat, 01 Oct 2016 03:29:13 GMT - Antoine Martin: owner changed

Mon, 03 Oct 2016 17:36:25 GMT - alas: status changed; resolution set

Connect without starting a server? Didn't realize that was an option to even consider - oops.

Tried again with 1.0 r13977 win32 client against a 1.0 r13977 osx client (on osx 10.9.5), and connected quite successfully.

Comparing the mouse movements from the client vs. the server though, it was pretty apparent that there was a pretty notable discrepancy, and the various windows on the server desktop were rendering partially over and partially under each other - but that seems like an issue for another ticket.

I'll go ahead and close this for maxmylyn - though if you want more work/testing for 10.10, 10.11, and the new 10.12, you'll want to re-open or make a new ticket.

Wed, 01 Feb 2017 09:44:40 GMT - Antoine Martin:

This has been broken by the changes in #1366 or #1340, r14923 and r14942 fix most of that. The problem is that we now only install the symlinks into "/usr/local/bin" and not "/usr/bin" (a new "security" constraint in later OSX versions), and when we ssh in only the latter one is on the $PATH.. and so we can't find the "Xpra" binary and the "proxy shadow start" now fails. r14943 adds "/usr/local/bin/xpra" to the list of scripts we try to run.

Probably not going to backport any of this since:

Temporary workaround for version <=1.0: xpra shadow ssh:OSXHOST --remote-xpra=/usr/local/bin/xpra

Sat, 23 Jan 2021 05:16:51 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1169