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.
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:
@afarr: this is a FYI, may be useful to know about. Feel free to just close.
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.
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.
Attempting to run the shadow server with 18.X r12856:
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.
Milestone renamed
Disabled in r13412 because the PKG would break on OSX 10.11.x, see ticket:641#comment:31 for details.
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.
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.
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
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.
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
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1169