xpra agent for osx - ssh start support

[totaam]

Follow up from #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.

[totaam]

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.

Caveats:

• xpra must be installed using the PKG (OSX .pkg creation scrips #641) so that the launch agent file [/browser/xpra/trunk/osx/org.xpra.Agent.plist] is installed correctly
• two dock icons appear - not sure which process causes that (should be fixed, meh)
• the dock uses generic icons rather than the xpra one (not sure that can be fixed, this is due to the limited access we have from the agent process context)
• disconnection causes an error when ssh closes (meh)

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

[totaam]

2016-05-20 00:04:18: afarr commented

---

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.

[totaam]

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 #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.

[totaam]

2016-07-01 20:35:00: maxmylyn commented

---

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

• Shadow server seems to start okay - complains about importing the webp encoder, but otherwise no errors.

• Unable to connect, the connection gets refused, and adding ssh:$mac_IP just fails saying connection refused on the server

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.

[totaam]

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

[totaam]

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.

[totaam]

2016-09-30 20:44:40: afarr commented

---

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 13937 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.

[totaam]

• there is no "bind-ssh" and this ticket is not related to ssl at all (native ssl support #1252)
• the "can only concatenate.." error was caused by a recent change: r13798 (for allow the proxy to start new sessions #1319), fixed in r13944
• also found another problem during re-testing: on some versions of OSX (10.10 for sure), the agent file is not world accessible, r13946 ignores this access denied problem and tries to continue anyway
• the point of this ticket is that you should not need to run "xpra shadow" on the server, running "xpra shadow ssh:HOST" from any client should be enough to remotely start the shadow server on OSX and connect to it (that's already the case for other posix servers)
• you should not need to specify the ssh port number either (but a bug introduced in r13896 for register the xpra mdns service type #731 had broken that, fixed in r13945): this should be enough: ssh/username@HOST/ - if connecting to a Linux server as a different user with multiple displays (and you want DISPLAY=":1") running on a non-standard ssh port (say 2222), then you can use: ssh://username:password@HOST:2222/1

[totaam]

2016-10-03 18:36:25: afarr commented

---

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.

[totaam]

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:

• it's a bit intrusive
• shadow start using the agent are no longer supported in newer osx versions (we can't add launch agents)

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