register the xpra mdns service type

[Antoine Martin]

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.

[Antoine Martin]

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

[Antoine Martin]

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

[Antoine Martin]

automated response

[Antoine Martin]

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

[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.

[Antoine Martin]

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:

• you don't need to specify a port when starting a server, ie:

  xpra --bind-tcp=0.0.0.0:
  

  xpra --bind-tcp=:
  

• if a server is running on the designated port (14500), then you don't need to specify the port when connecting either:

  xpra attach tcp:127.0.0.1
  

• you can also run a proxy on that port:

  xpra proxy --bind-tcp=0.0.0.0: --tcp-auth=none
  

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

xpra start tcp:127.0.0.1 --start=xterm

etc..

[alas]

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

[Antoine Martin]

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

[J. Max Mena]

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

[Antoine Martin]

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:

• the full command line used
• the output of python -c "import socket;print(socket.gethostname())"
• the output of "hostname"
• the "-d mdns,network" output of the server startup (I have added debug logging in r14276 + r14277)

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

[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)

• Now on to the questions posed.

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.

[alas]

full server startup output with -d mdns,network

[Antoine Martin]

• Connection refused usually means that you're trying to connect to a port that does not have a server on it or that it is blocked by the firewall, or that you are using the syntax --bind-tcp=: which defaults to 127.0.0.1 for the host, making the tcp server socket inaccessible to remote hosts (and since your client is macos, I'm pretty sure that's a remote host) - that's not a bug.
• didn't seem to get pulled in when building the r14282? - the new dependency is for the RPM packages, we cannot install new RPM system dependencies during the python build
• TypeError: server_state_changed() takes exactly 2 arguments (3 given) - this is odd: I'm definitely not seeing this, and all the API documentation for "StateChanged?" only have 2 arguments, nevertheless r14283 adds compatibility for the extra argument if we ever get it
• 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.. - I don't see why starting google-chrome from start-child would be silly? What was the error?
• First, probably because I've mishandled adding my user to "xpra" group: ... - your user does seem to be a member of the xpra group... maybe you need to logout and login again? (or the permissions on the "/var/run/xpra" directory are wrong, those will now be shown in case of error as of r14284). Or the tmpfiles.d we install isn't taken into account yet. I believe an RPM installation will create tmpfiles using an automatic trigger (it's not clear at all from the documentation: ​Packaging tmpfiles.d), otherwise this will do it manually: systemd-tmpfiles --create xpra.conf
• so, your hostname is "jimador.plata" but we're trying to resolve "localhost" to a fully qualified domain name to use with mdns (since ":" defaults to "localhost:14500") and somehow on your system we get "localhost" (I get "localhost.localdomain"), r14288 makes us try harder to find a fully qualified domain name to use. Please try again with "-d mdns".

[alas]

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

• No longer seeing the TypeError.

• Don't recall what specific strange errors I was getting from launching with --start-child=google-chrome, but I'm currently getting the "usual" errors of:

  [22926:22926:1101/180207:ERROR:gl_surface_glx.cc(406)] glxQueryVersion failed
  [22926:22926:1101/180207:ERROR:gl_initializer_x11.cc(130)] GLSurfaceGLX::InitializeOneOff failed.
  [22926:22926:1101/180207:ERROR:gpu_child_thread.cc(328)] Exiting GPU process due to errors during initialization
  [22765:22813:1101/180207:ERROR:browser_gpu_channel_host_factory.cc(113)] Failed to launch GPU process.
  

... 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).

• You may've been right about the logout and login... when I re-connected to the vm and launched, the error was gone - without any need to use the manual systemd-tmpfiles --create xpra.conf.

• Even using the "expected to fail" --bind-tcp=: for a non-local client, I'm no longer seeing any hostname issues... just the expected [Errno 61].

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

[Antoine Martin]

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!

[migration script]

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