Hi Daniel,
On Fr 29 Jul 2011 07:24:40 CEST Daniel Lindgren wrote:
[...]
I've been trying to think of some way to make x2go automatically only use free ports, but since there are possibly several clients and servers involved in multiple incoming and outgoing sessions, the only safe way I've come up with would be to register used ports (or reserve port ranges) on a shared resource somewhere, which would make all x2go clients and servers dependent on that one resource.
What you have been describing above is the old, well known
NXServer/NXClient problem.
To my experience it does not exist with X2go (at least not with
pyhoca-gui ;-) ).
The connecting stuff is a bit tricky...
x2goclient connects via SSH and launches either x2gostartagent or x2goresume-session
x2gostartagent will try to detect a free server-side port >30000. This port is put into the session database table. (Make sure you do not have other server-side stuff running that claims ports between 30000 and 30000++.
x2goresume-session will pick the formerly detected port from the session database table (i.e. SQLite or postgres) and presume it is still unused (as it should be, unless unused by X2go -> x2gostartagent avoids claiming ports that are in the database marked with S (suspended) or R (running) state
say we detect a free server-side port: 30015: x2gostartagent will
launch the XNest-like x2goagent XServer, listening for incoming connections on port localhost:300015.x2goclient now tries to set up a forwarding tunnel from client to server (-L 30000:localhost:30015)
if the local port 30000 (the first one in the above expression) is already in use, it simply selects another port. Each selected port is
probed before usage. That is done by x2goclient.say we end up with -L 30028:localhost:30015
The problem you observe: ”the remote proxy closed the connection while
negotiating …” to my point of view stems from uncleanly closed SSH
connections. Try to restart the SSH daemon when this error occurs and
you should be able to connect again. This error can also be caused by
the sound/sshfs tunnels. Here the same cause applies: unclean shutdown
of SSH connections.
Reasons may be:
o unclean x2goclient/pyhoca-gui code o line failures (so the clients do not get the chance to cancel the port forwarding requests...)
You may do the following to debug:
o try if the problem occurs in the same way when you use pyhoca-gui/-cli o pyhoca-gui (i.e. python-x2go) tries to restore the mal-closure of SSH port forwardings... You may try to resume a session twice, the second time you should get a session window
The addressed issue was a big problem for Python X2go before version
0.1.0.0. It took me quite some sleepness nights to get rid of it by
90%+.
Greets, Mike
--
DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419
GnuPG Key ID 0xB588399B mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...