xpra icon
Bug tracker and wiki

Opened 20 months ago

Closed 14 months ago

Last modified 10 months ago

#1169 closed enhancement (fixed)

xpra agent for osx - ssh start support

Reported by: Antoine Martin Owned by: J. Max Mena
Priority: major Milestone: 1.0
Component: platforms Version: trunk
Keywords: osx ssh shadow Cc:

Description

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.

Change History (11)

comment:1 Changed 19 months ago by Antoine Martin

Owner: changed from Antoine Martin to alas

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

Last edited 18 months ago by Antoine Martin (previous) (diff)

comment:2 Changed 18 months ago by alas

Owner: changed from alas to Antoine Martin

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.

Last edited 18 months ago by Antoine Martin (previous) (diff)

comment:3 Changed 18 months ago by Antoine Martin

Owner: changed from Antoine Martin to alas

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.

Last edited 18 months ago by Antoine Martin (previous) (diff)

comment:4 Changed 17 months ago by J. Max Mena

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.

Last edited 17 months ago by J. Max Mena (previous) (diff)

comment:5 Changed 17 months ago by Antoine Martin

Milestone: 0.181.0

Milestone renamed

comment:6 Changed 15 months ago by Antoine Martin

Owner: changed from alas to Antoine Martin
Status: newassigned

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

comment:7 Changed 15 months ago by Antoine Martin

Owner: changed from Antoine Martin to J. Max Mena
Status: assignednew

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.

comment:8 Changed 14 months ago by alas

Owner: changed from J. Max Mena to Antoine Martin

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.

comment:9 Changed 14 months ago by Antoine Martin

Owner: changed from Antoine Martin to J. Max Mena
  • there is no "bind-ssh" and this ticket is not related to ssl at all (#1252)
  • the "can only concatenate.." error was caused by a recent change: r13798 (for #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 #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
Last edited 14 months ago by Antoine Martin (previous) (diff)

comment:10 Changed 14 months ago by alas

Resolution: fixed
Status: newclosed

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.

comment:11 Changed 10 months ago by 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:

  • 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

Last edited 10 months ago by Antoine Martin (previous) (diff)
Note: See TracTickets for help on using tickets.