xpra icon
Bug tracker and wiki

Opened 3 years ago

Closed 11 months ago

#731 closed task (fixed)

register the xpra mdns service type

Reported by: Antoine Martin Owned by: Antoine Martin
Priority: trivial Milestone: 1.0
Component: packaging Version: trunk
Keywords: Cc:

Description (last modified by 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.

Attachments (3)

IANA-port-number-registration-request.txt (4.3 KB) - added by Antoine Martin 12 months ago.
automated response
iana-port.patch (5.1 KB) - added by Antoine Martin 12 months ago.
when we get assigned a port, add this to make specifying the port number optional
ticket731_d-mdns-network-output.txt (13.8 KB) - added by alas 11 months ago.
full server startup output with -d mdns,network

Download all attachments as: .zip

Change History (15)

comment:1 Changed 13 months ago by Antoine Martin

Description: modified (diff)
Milestone: future1.0
Status: newassigned

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

comment:2 Changed 12 months ago by Antoine Martin

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

Changed 12 months ago by Antoine Martin

automated response

Changed 12 months ago by Antoine Martin

Attachment: iana-port.patch added

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

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

comment:4 Changed 12 months ago by Antoine Martin

Owner: changed from Antoine Martin to alas
Status: assignednew

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

comment:5 Changed 12 months ago by alas

Owner: changed from alas to Antoine Martin

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

comment:6 Changed 12 months ago by Antoine Martin

Owner: changed from Antoine Martin to alas

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

Last edited 12 months ago by Antoine Martin (previous) (diff)

comment:7 Changed 11 months ago by J. Max Mena

Owner: changed from alas to Antoine Martin

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

comment:8 Changed 11 months ago by Antoine Martin

Owner: changed from Antoine Martin to alas

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.

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

Changed 11 months ago by alas

full server startup output with -d mdns,network

comment:10 Changed 11 months ago by 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".

comment:11 Changed 11 months ago by alas

Owner: changed from alas to Antoine Martin

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.

comment:12 Changed 11 months ago by Antoine Martin

Resolution: fixed
Status: newclosed

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!

Note: See TracTickets for help on using tickets.