starting an xpra session manually and then remotely connecting to it with the winswitch cleint for Windows results in change of xpra session to use --bind-tcp=0.0.0.0:<port>, which is a "major security risk" (xpra(1)).

Reproduction steps:

In the remote host run

$ ps aux | grep winswitch # no winswitch_server running
$ ps aux | grep xpra # no xpra running
$ xpra start :666
$ ps aux | grep xpra # see the command line and PID
1000     18905  2.5  0.2 188412 21976 ?        S    21:26   0:00 /usr/bin/python /usr/bin/xpra start :666

Now run the Window Switch client for Windows and connect to that remote host using ssh tunneling. It will show an "unknown" session. You won´t even need to resume it via the tray icon, the damage is already done:

On the remote host again:

$ ps aux | grep xpra
1000     19549  0.1  0.2 213020 23404 ?        S    21:32   0:00 /usr/bin/python /usr/bin/xpra --bind-tcp=0.0.0.0:15061 --password-file=/home/ocm-admin/.winswitch/server/sessions/666/session.pass --no-daemon --no-pulseaudio --session-name=unknown start :666 --use-display

$ ps aux | grep winsw
1000     19479  0.1  0.1 101708 15536 ?        Ss   21:31   0:00 /usr/bin/python /usr/bin/winswitch_stdio_socket
1000     19485  0.2  0.0      0     0 ?        Z    21:32   0:00 [winswitch_serve] <defunct>
1000     19533  0.2  0.3 323548 29688 ?        S    21:32   0:00 /usr/bin/python /usr/bin/winswitch_server --daemon
1000     19549  0.1  0.2 213020 23404 ?        S    21:32   0:00 /usr/bin/python /usr/bin/xpra --bind-tcp=0.0.0.0:15061 --password-file=/home/ocm-admin/.winswitch/server/sessions/666/session.pass --no-daemon --no-pulseaudio --session-name=unknown start :666 --use-display

$ netstat --inet -nlp 2>/dev/null | grep 19549
tcp        0      0 0.0.0.0:15061           0.0.0.0:*               LISTEN      19549/python

So there you are, apparently winswitch_server restarted xpra, see the different PIDs, and now it is listening on all IPs. Found no documentation about this, just stumbled upon it. No obvious way to change it in any config files. Plus this should never be the default behaviour!

For some more info, I am using Debian squeeze/stable and have installed from the official winswitch.org repository.

$ cat /etc/debian_version
6.0.5
$ apt-cache policy winswitch xpra
winswitch:
  Installiert: 0.12.14-1
  Kandidat:    0.12.14-1
  Versionstabelle:
 *** 0.12.14-1 0
        990 http://winswitch.org/ squeeze/main amd64 Packages
        100 /var/lib/dpkg/status
xpra:
  Installiert: 0.3.2-2
  Kandidat:    0.3.2-2
  Versionstabelle:
 *** 0.3.2-2 0
        990 http://winswitch.org/ squeeze/main amd64 Packages
        100 /var/lib/dpkg/status
$ winswitch_server --version
winswitch version 0.12.14
Release Build
Built on winswitch.org by root on the 2012-06-04
SVN revision unknown with unknown local modifications
$ xpra --version
xpra v0.3.2

I did not change any config files on the remote host.

The windows client version is: Window Switch 0.12.14 Built on xp-pro by XP_Pro. 2012-06-04 (release build) (svn revision 4908 with 0 local changes)

if the client version matters at all, this should clearly be changed on the server.

I just installed xpra 0.4.0, and, to get my session upgraded in-place, did a kill of the winswitch_daemon, and reconnected.

winswitch tried to restart xpra, I believe:

26717 ?        S     22:55 /usr/bin/python /usr/bin/xpra --xvfb=/usr/bin/
26718 ?        S      4:55  \_ /usr/bin/Xvfb-for-Xpra-:67 +extension Comp
26786 ?        S      0:00 python /usr/lib/winswitch/delayed_start /home/
26787 ?        S      0:00  \_ /bin/sh -c xchat
26788 ?        Sl    35:13      \_ xchat
13327 ?        S      0:00 /usr/bin/python /usr/bin/winswitch_server --da
13371 ?        D      0:00 /usr/bin/python /usr/bin/xpra --bind-tcp=0.0.0

But something went wrong, and the new session was killed - *including* Xvfb and my active xchat.

The logfile has these entries:

[II] 2012/23/06 22:53:33 XpraServerUtil.start_daemon(ServerSession(:67 - xpra - available),
[II] 2012/23/06 22:53:34 virt_server_daemonizer.grab_daemon_pid(['/.../virt_server_daemonizer', ...
 '--', '/usr/bin/xpra', ... 'start', ':67', '--use-display'
[II] 2012/23/06 22:53:34 XpraServerUtil.session_process_started(13371,ServerSession(:67 - xpra - available))
[II] 2012/23/06 22:53:34 XpraServerUtil.do_watch_session_log(...
[II] 2012/23/06 22:53:34 WinSwitchServer.publish() mDNS_publish=True
[II] 2012/23/06 22:53:34 AvahiPublisher.__init__(Window Switch for ...
[EE] 2012/23/06 22:53:34 AvahiPublishers.start() error on publisher AvahiPublisher(Window Switch for ...
[ee] 2012/23/06 22:53:35 Traceback (most recent call last):
[ee] 2012/23/06 22:53:35   File "/usr/lib/pymodules/python2.7/winswitch/net/avahi_publisher.py", line 64, in start
[ee] 2012/23/06 22:53:35     publisher.start()
[ee] 2012/23/06 22:53:35   File "/usr/lib/pymodules/python2.7/winswitch/net/avahi_publisher.py", line 105, in start
[ee] 2012/23/06 22:53:35     bus = dbus.SystemBus()
[ee] 2012/23/06 22:53:35   File "/usr/lib/python2.7/dist-packages/dbus/_dbus.py", line 194, in __new__
[ee] 2012/23/06 22:53:35     private=private)
[ee] 2012/23/06 22:53:35   File "/usr/lib/python2.7/dist-packages/dbus/_dbus.py", line 100, in __new__
[ee] 2012/23/06 22:53:35     bus = BusConnection.__new__(subclass, bus_type, mainloop=mainloop)
[ee] 2012/23/06 22:53:35   File "/usr/lib/python2.7/dist-packages/dbus/bus.py", line 122, in __new__
[ee] 2012/23/06 22:53:35     bus = cls._new_for_bus(address_or_type, mainloop=mainloop)
[ee] 2012/23/06 22:53:35 DBusException: org.freedesktop.DBus.Error.NoServer:
  Failed to connect to socket /var/run/dbus/system_bus_socket: Connection refused
[II] 2012/23/06 22:53:36 XpraServerUtil.detect_sessions() found: [('DEAD', ':67')]
[II] 2012/23/06 22:53:36 ServerSession.close() self=ServerSession(:67 - xpra - closed), killing ...

Perhaps there's a way to get the new xpra running on a different port, and only grab the Xvfb and kill the old xpra when everything else is ready?

I've got a remote tunnel, via

ssh -L 8022:host1:22

and connect to host2 via winswitch and the localhost:8022 tunnel.

Now, if I stop that outer SSH session (eg. via the "\n\n~." escape sequence) winswitch sees that the connection is severed, and displays "reconnect" in the servers menu.

But this doesn't work; on the first "reconnect" winswitch says that it couldn't connect, and only on the second try it really reconnects.

So it seems like there's some old state that is not being updated when a connection breaks.