Xpra: Ticket #1503: SSH xpra start on remote host

you are right, let's attack this issue at another ticket. This problem has nothing to do with balancing and let me to make all my comments more structured :-)

So just a simple test (py script in the attach file) which will explain better the situation. 1)Paramico module should be installed before (in the comments inside the script how do that for Centos) 2) inside the script command string for "xpra start..) ip_server, user name and login of Linux for the user under whom the script should be performed

First test. It needs to start in Terminal.

python session.py 1

The session is created and then

python session.py 2

Port is open as well and everything is fine

Second test Firstly the session from previos test should be killed

killall xpra

then

python session.py 3

Session is open but port is closed!!! The idea is that if and session creation and connection are done from the same script (Python process or session - don't know how to say better) Proxy can't connect the client to back-end session



Fri, 21 Apr 2017 08:59:59 GMT - Antoine Martin: owner changed

That's one fugly script.

Please remove the xpra copyright and my name from this script and upload a better version, I do not want to be associated with it in any way. it will be removed from this ticket.

Finally, you aren't waiting for the server to startup before polling the TCP socket. The paramiko code probably returns as soon as the xpra server daemonizes, which happens before the sockets are in listening state. You should wait for the xpra server to startup, polling the socket with a timeout.


Fri, 21 Apr 2017 09:34:36 GMT - Denis01:

Hello, The script was just to explain better the problem. Please remove it. Server i will kill - it' s just for playing purpuses. Oppps....yesterday was completly out of mind and i didn't tried with sleep() here (it works). But tried with main sql_auth get.session() and there the proxy doesn't wait and restarts auth processes. So there are 3 ways: 1) find a way to get the proper answer from Paramiko (tried with couple of examples but anyway it returns nothing). But i'll continuer to figuer out how it is possible 2) is there any command of xpra (which returns to terminal the answer) to check if session is properly started on this port (tried with xpra list but that disn't work but probably i did smth wrong)? 3) to increase the proxy waiting time without restart the attempt to connect. Don't think it is a good way as target hosts may be quite loaded and time of session start might vary significantly. But it can help if 2 points above can't be done. Where the waiting time should be set up?


Fri, 21 Apr 2017 09:48:47 GMT - Antoine Martin: attachment set

fixed up test script


Fri, 21 Apr 2017 10:25:21 GMT - Denis01:

Ok, thanks. And for waiting time above (3 point). Probably it should be some waiting time of sql_auth module for the get_sessions() answer instead of Proxy


Fri, 21 Apr 2017 10:54:19 GMT - Antoine Martin:

find a way to get the proper answer from Paramiko

No. The server daemonizes before the socket is ready. Paramiko is not the problem.

is there any command of xpra (which returns to terminal the answer) to check if session is properly started on this port

xpra version :100

Or

xpra version tcp/HOST:PORT/

Will return 0 if successful.

I'm still not entirely sure why you're using paramiko for all this. Xpra can start a remote session reliably with:

xpra start ssh/username:password@HOST:SSHPORT/DISPLAY --start=xterm --attach=no

(the attach flag is new in 2.1) As of r15691, we correctly return zero only when the remote session was successfully started, AND is available for connecting to it.

Probably it should be some waiting time of sql_auth module for the get_sessions() answer instead of Proxy

No. The code used above is in run_remote_server function I mentioned before, this should be fired from the proxy's "start new session" code.

I will probably close this ticket as invalid, as there's nothing at all wrong with xpra here.


Sat, 22 Apr 2017 13:18:20 GMT - Denis01:

Hello,

xpra start ssh/username:password@HOST:SSHPORT/DISPLAY --start=xterm --attach=no

doesn't allow (at least I haven't found in wiki) to create a session on needed port at targethost.

And "sleep(3)" seems to solve the prb. But to have everything up-to-date installed the new version - xpra proxy version 2.1-r15692 64-bit So having: (From terminal)

xpra proxy :100 --bind-tcp=151.248.112.232:443 --auth=sql -d auth -d proxy

Then in PY script(by Paramiko)

xpra start --bind-tcp=151.248.112.232:10000 --start-child=/bin/gedit --exit-with-children

then

sleep(3)
xpra version tcp/....

which returns 2.1 - so everything is fine for now then define the session data

self.uid=int(1003)
self.gid=int(1003)
disp_string="tcp:151.248.112.232:10000"
self.displays=[disp_string]
self.env_options={}
self.session_options={}
self.sessions = self.uid, self.gid, self.displays, self.env_options, self.session_options
return self.sessions

Log shows:

2017-04-22 06:58:13,268 start_proxy(Protocol(None), {..}, None) found sessions: (1003, 1003, ['tcp:151.248.112.232:10000'], {}, {})
2017-04-22 06:58:13,271 start_proxy: displays=['tcp:151.248.112.232:10000'], start-new-session=False
2017-04-22 06:58:13,271 start_proxy: proxy-virtual-display=:100 (ignored), user specified display=None, found displays=['tcp:151.248.112.232:10000']
2017-04-22 06:58:13,271 start_proxy(Protocol(None), {..}, None) using server display at: tcp:151.248.112.232:10000
2017-04-22 06:58:13,271 display description(tcp:151.248.112.232:10000) = {'display_name': 'tcp:151.248.112.232:10000', 'uid': 1003, 'local': False, 'host': '151.248.112.232', 'gid': 1003, 'type': 'tcp', 'port': 10000}
2017-04-22 06:58:13,272 server connection=tcp socket: 151.248.112.232:42680 <- 151.248.112.232:10000

seems to work but then

2017-04-22 06:58:13,272 server error processing new connection from Protocol(None): cannot steal a closed connection
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/xpra/server/server_core.py", line 944, in _process_hello
    self.hello_oked(proto, packet, c, auth_caps)
  File "/usr/lib64/python2.7/site-packages/xpra/server/proxy/proxy_server.py", line 178, in hello_oked
    self.start_proxy(proto, c, auth_caps)
  File "/usr/lib64/python2.7/site-packages/xpra/server/proxy/proxy_server.py", line 320, in start_proxy
    client_conn = client_proto.steal_connection(unexpected_packet)
  File "/usr/lib64/python2.7/site-packages/xpra/net/protocol.py", line 993, in steal_connection
    assert not self._closed, "cannot steal a closed connection"
AssertionError: cannot steal a closed connection

Log file of the Test with multifile (with static pre-loaded "xpra start..." at target_host)gives the line with Prococol data instead of "None"

2017-04-22 06:58:13,271 start_proxy(Protocol(tcp websocket: 151....etc....), {..}, None) using server display at: tcp:151.248.112.232:10000

Sun, 23 Apr 2017 06:59:42 GMT - Denis01:

As the scheme with session creation already worked i have made a test - reinstall everything (server, xpra, etc) With version 2.0.2 - no problems with sockets.


Sun, 23 Apr 2017 10:58:37 GMT - Denis01: status changed; resolution set

No issues with SSH itself - works fine (Paramiko or other means).


Sun, 23 Apr 2017 11:50:33 GMT - Antoine Martin:

doesn't allow (at least I haven't found in wiki) to create a session on needed port at targethost

I can only guess that you are talking about bind-tcp=0.0.0.0:10000 not being forwarded to the remote start command? If that's the case, r15693 fixes that.

And "sleep(3)" seems to solve the prb.

Using a single sleep with a fixed value is not the correct way to solve the problem: you should loop with a small sleep value, so you can return more quickly if possible, and wait longer if needed.

As the scheme with session creation already worked i have made a test - reinstall everything (server, xpra, etc) With version 2.0.2 - no problems with sockets.

I don't understand what any of this means.


Sat, 23 Jan 2021 05:26:04 GMT - migration script:

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