#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 )
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)
Change History (16)
comment:1 Changed 5 years ago by
Description: | modified (diff) |
---|---|
Milestone: | future → 1.0 |
Status: | new → assigned |
Changed 5 years ago by
Attachment: | IANA-port-number-registration-request.txt added |
---|
automated response
Changed 5 years ago by
Attachment: | iana-port.patch added |
---|
when we get assigned a port, add this to make specifying the port number optional
comment:3 Changed 5 years ago by
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 5 years ago by
Owner: | changed from Antoine Martin to alas |
---|---|
Status: | assigned → new |
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 5 years ago by
Owner: | changed from alas to Antoine Martin |
---|
Does this also mean I can stop using --mdns=no
flag?
comment:6 Changed 5 years ago by
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
comment:7 Changed 4 years ago by
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 4 years ago by
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 4 years ago by
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 4 years ago by
Attachment: | ticket731_d-mdns-network-output.txt added |
---|
full server startup output with -d mdns,network
comment:10 Changed 4 years ago by
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 to127.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 4 years ago by
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 4 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
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!
comment:13 Changed 3 months ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/731
avahi is down, maybe we should use: http://www.iana.org/form/ports-services.