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.
avahi is down, maybe we should use: http://www.iana.org/form/ports-services.
Sent request to IANA, should hear back within 14 days.
when we get assigned a port, add this to make specifying the port number optional
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.
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]
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:
@afarr: this means that:
xpra attach tcp:127.0.0.1
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
Does this also mean I can stop using
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
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
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
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?
python -c "import socket;print(socket.gethostname())"
Just noticed that we don't handle IPV6 yet: #1345.
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
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).
-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)
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.
full server startup output with -d mdns,network
Connection refusedusually 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.1for 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.
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
--start-child=google-chromeflag 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?
systemd-tmpfiles --create xpra.conf
Ok, tried some more with a 1.0 r14304 fedora 23 server and 1.0 r14155 osx client.
--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).
systemd-tmpfiles --create xpra.conf.
--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.
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!
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/731