xpra icon
Bug tracker and wiki

Opened 6 months ago

Closed 6 months ago

Last modified 6 months ago

#1503 closed defect (fixed)

SSH xpra start on remote host

Reported by: Denis01 Owned by: Denis01
Priority: major Milestone:
Component: core Version: trunk
Keywords: Cc:

Description

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

Attachments (1)

session.py (1.3 KB) - added by Antoine Martin 6 months ago.
fixed up test script

Download all attachments as: .zip

Change History (9)

comment:1 Changed 6 months ago by Antoine Martin

Owner: changed from Antoine Martin to Denis01

That's one fugly script.

  • missing select import - won't run without it
  • you're using strings instead of booleans - yuk
  • defines IP and port, but then duplicates the values in other strings - yuk
  • you're exposing your server's IP and port, and clearly not using password authentication - that's asking for trouble

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.

comment:2 Changed 6 months ago by 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?

Last edited 6 months ago by Denis01 (previous) (diff)

Changed 6 months ago by Antoine Martin

Attachment: session.py added

fixed up test script

comment:3 Changed 6 months ago by 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

comment:4 Changed 6 months ago by 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.

comment:5 Changed 6 months ago by 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

comment:6 Changed 6 months ago by 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.

comment:7 Changed 6 months ago by Denis01

Resolution: fixed
Status: newclosed

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

comment:8 Changed 6 months ago by 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.

Note: See TracTickets for help on using tickets.