Xpra: Ticket #731: register the xpra mdns service type

This ticket is just a tracker for the avahi upstream ticket: http://avahi.org/ticket/368#ticket

An email has also been fired to http://dns-sd.org.



Sat, 13 Aug 2016 10:28:25 GMT - Antoine Martin: status, description, milestone changed

avahi is down, maybe we should use: http://www.iana.org/form/ports-services.


Tue, 13 Sep 2016 12:11:16 GMT - Antoine Martin:

Sent request to IANA, should hear back within 14 days.


Tue, 13 Sep 2016 14:51:12 GMT - Antoine Martin: attachment set

automated response


Sun, 25 Sep 2016 12:24:51 GMT - Antoine Martin: attachment set

when we get assigned a port, add this to make specifying the port number optional


Wed, 28 Sep 2016 04:54:34 GMT - Antoine Martin:

Looks like this IANA process could take a while, so r13896 uses 14500 as default port for now. We can change it later and I will request that the port number request is updated to use this port.


Wed, 05 Oct 2016 17:54:52 GMT - Antoine Martin: owner, status changed

That port is ours!

Your request has been processed. We have assigned the following registered port number with you as the point of contact:

xpra	14500	tcp	xpra network protocol	[Xpra]	[Antoine_Martin]

See: http://www.iana.org/assignments/service-names-port-numbers

The expert review for this request was completed by: Wes Eddy

Please notify us if there is any change in contact information by completing the following template:

http://www.iana.org/cgi-bin/mod_portno.pl


@afarr: this means that:

then start new sessions on demand with a very short command line:

xpra start tcp:127.0.0.1 --start=xterm

etc..


Wed, 05 Oct 2016 23:00:36 GMT - alas: owner changed

Does this also mean I can stop using --mdns=no flag?


Thu, 06 Oct 2016 04:22:42 GMT - Antoine Martin: owner changed

Does this also mean I can stop using --mdns=no flag?


I don't even know why you're disabling it in the first place!

This is only distantly related: mdns is used to advertise sessions on the network, the fact that there is a default port does not really change this. Also, the sessions can be available through other means (ie: ssh), the port can be different (only one server can claim that port, new sessions started by the proxy will use a different connection method), and mdns advertises which hosts the service runs on.

See also #1335


Mon, 24 Oct 2016 16:55:53 GMT - J. Max Mena: owner changed

Note: in order to get the mdns working, one must both have avahi installed, and the python-avahi package...for the python bindings.

Anyways, with a Fedora 24 (yay, upgraded! It went surprisingly well, kudos to the Fedora dev team) trunk r14271 server:

I get the following error when starting with --bind-tcp=::

2016-10-24 09:48:57,362 Warning: failed to start Avahi publisher for Vorfuehreffekt.spikes.eng :11 localhost:14500 interface 1
2016-10-24 09:48:57,362  org.freedesktop.Avahi.InvalidHostNameError
2016-10-24 09:48:57,362   Invalid host name

However starting with --bind-tcp=0.0.0.0: works perfectly fine. And, the autoconnect without specifying a port works as well.

Passing back to you


Tue, 25 Oct 2016 03:38:28 GMT - Antoine Martin: owner changed

The python bindings used to be in a package that was far too big to pull in, with far too many dependencies - but that's now fixed: https://bugzilla.redhat.com/show_bug.cgi?id=1260432 so r14272 adds the "python-avahi" package dependency to the Fedora RPM (centos does not have the split package yet).

As for the InvalidHostNameError, that's a weird one: I assume your command line doesn't have that hostname in it, which means that we're querying the hostname, which then fails to resolve itself? Please post:

Just noticed that we don't handle IPV6 yet: #1345.


Tue, 25 Oct 2016 22:20:20 GMT - alas:

Testing myself with a 1.0 r14271 without using the --mdns=no flag, I now recall why I was using it in the first place...

2016-10-25 14:12:58,007 Warning: failed to load the mdns avahi publisher:
2016-10-25 14:12:58,008  No module named avahi
2016-10-25 14:12:58,008  either fix your installation or use the 'mdns=no' option

Nevertheless, I also have success with --bind-tcp=0.0.0.0:.

Without avahi or python-avahi installed, however (for the benefit of anyone who later does a search on this) when I try --bind-tcp=:, I get no error message server side, but client-side I fail to connect ([Errno 61] Connection refused).

With a -d all client-side I get a traceback (which may be useless, but I'll include it).

2016-10-25 14:20:11,388 failed to connect
Traceback (most recent call last):
  File "/Users/Schadenfreude/Desktop/xpra-catalog/xpra-ant-1-14155/Xpra.app/Contents/Resources/lib/python/xpra/scripts/main.py", line 1529, in _socket_connect
    sock.connect(endpoint)
  File "socket.pyc", line 228, in meth
error: [Errno 61] Connection refused

Building a 1.0 r14282 fedora 23 server I get the same error.

Installing (per maxmylyn's dictum) avahi and python-avahi (didn't seem to get pulled in when building the r14282?)... I was seeing a different error initially, but that seemed to be the result of trying to have a --start-child=google-chrome flag on the command line (once I stopped that silliness, I began getting the same error as maxmylyn).

With the google-chrome on the command line: xpra --no-daemon --bind-tcp=: --start-child=xterm --start-child=google-chrome --start-new-commands=yes start :13, I'm seeing part of the avahi warning, but not all (??), as well as a D-bus traceback:

2016-10-25 14:38:53,889 xpra X11 version 1.0-r14282 64-bit
2016-10-25 14:38:53,889  uid=1001, gid=1001
2016-10-25 14:38:53,889  running with pid 533 on Linux Fedora 23 TwentyThree
2016-10-25 14:38:53,889  connected to X11 display :13
xterm: cannot load font '-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1'
2016-10-25 14:38:53,997  to avoid this warning, disable mdns support
2016-10-25 14:38:53,997  using the 'mdns=no' option
2016-10-25 14:38:53,998 printer forwarding enabled using postscript and pdf
2016-10-25 14:38:54,000 2.0GB of system memory
2016-10-25 14:38:54,008  to avoid this warning, disable mdns support
2016-10-25 14:38:54,008  using the 'mdns=no' option
2016-10-25 14:38:54,008 xpra is ready.
…
2016-10-25 14:38:54,858 Exception in handler for D-Bus signal:
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/dbus/connection.py", line 230, in maybe_handle_message
    self._handler(*args, **kwargs)
TypeError: server_state_changed() takes exactly 2 arguments (3 given)
2016-10-25 14:38:54,862 Exception in handler for D-Bus signal:
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/dbus/connection.py", line 230, in maybe_handle_message
    self._handler(*args, **kwargs)
TypeError: server_state_changed() takes exactly 2 arguments (3 given)

Command line: xpra --no-daemon --bind-tcp=: --start-child=xterm --start-new-commands=yes start :13.

python -c "import socket;print(socket.gethostname())" (& "hostname") = jimador.plata

I'll attach the output in a file for neatness, but I will post a couple of tracebacks here.

First, probably because I've mishandled adding my user to "xpra" group:

2016-10-25 15:03:44,013 socket creation error
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/xpra/scripts/server.py", line 572, in setup_local_sockets
    sock, cleanup_socket = create_unix_domain_socket(sockpath, mmap_group, socket_permissions)
  File "/usr/lib64/python2.7/site-packages/xpra/scripts/server.py", line 382, in create_unix_domain_socket
    listener.bind(sockpath)
  File "/usr/lib64/python2.7/socket.py", line 228, in meth
    return getattr(self._sock,name)(*args)
error: [Errno 13] Permission denied
2016-10-25 15:03:44,014 Warning: cannot create socket '/var/run/xpra/jimador.plata-13'
2016-10-25 15:03:44,014  [Errno 13] Permission denied
2016-10-25 15:03:44,015  user 'jimador' is a member of groups: sys, wheel, xpra

And second, and obviously much more pertinent:

Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/xpra/net/mdns/avahi_publisher.py", line 157, in add_service
    self.group.AddService(*args)
  File "/usr/lib64/python2.7/site-packages/dbus/proxies.py", line 70, in __call__
    return self._proxy_method(*args, **keywords)
  File "/usr/lib64/python2.7/site-packages/dbus/proxies.py", line 145, in __call__
    **keywords)
  File "/usr/lib64/python2.7/site-packages/dbus/connection.py", line 651, in call_blocking
    message, timeout)
DBusException: org.freedesktop.Avahi.InvalidHostNameError: Invalid host name
2016-10-25 15:03:45,192 Warning: failed to start Avahi publisher for jimador.plata :13 localhost:14500 interface 1
2016-10-25 15:03:45,192  org.freedesktop.Avahi.InvalidHostNameError
2016-10-25 15:03:45,192   Invalid host name

Passing this back.


Tue, 25 Oct 2016 22:21:01 GMT - alas: attachment set

full server startup output with -d mdns,network


Wed, 26 Oct 2016 05:47:13 GMT - Antoine Martin:


Wed, 02 Nov 2016 01:13:51 GMT - alas: owner changed

Ok, tried some more with a 1.0 r14304 fedora 23 server and 1.0 r14155 osx client.

... I'd guess that google-chrome is trying to use the video card on the vm I'm using as a server, and failing. Since it doesn't seem to be having any impact now, I'll forego rolling client and server back and double checking, unless you're really curious (and I think it was an issue with confusion of error messages while trying with --bind-tcp=:, which isn't expected to work with a non-local client anyway).

Looks to me like this is ready to close. I'll pass it back to you to glance through and do the honors.


Wed, 02 Nov 2016 02:32:39 GMT - Antoine Martin: status changed; resolution set

Closing!

FYI: google-chrome wants to use a GPU, try to run it through vglrun if you have a real display on that system - otherwise.. not much we can do about it!


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

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