GNOME Bugzilla – Bug 572470
vino uses the wrong host name when advertising via mDNS/avahi
Last modified: 2009-09-08 18:32:53 UTC
Please describe the problem: Vino advertises the *server name* as "%u's remote desktop on %s", when the server name should be left to whatever the default is Avahi thinks that machine is. Steps to reproduce: 1. Click on an Ubuntu box's listing in the Shared Servers list in Finder on a Mac Actual results: There is no "Share Screen" button in the toolbar for that server listing, because vino isn't actually using the server's name to advertise. Expected results: "Share Screen" should appear in the toolbar when I have the actual server name selected, and I shouldn't have a separate entry in the browser for another server (but it's really the same one?) called "%u's remote desktop on %h" Does this happen every time? Yes. Other information: I have Macs in my house. The network browser on the Macs in the Finder shows the list of servers that advertise via mDNS. If you click on a server in the Finder, the right hand side of the window shows a list of available file shares in the window (and a "Connect as..." button in the toolbar) if samba or netatalk or nfs are running and advertised, and a "Share Screen" button in the toolbar if VNC is advertised. For the entries of my Ubuntu boxes, there is no "Share Screen" button. Because vino gets listed as a separate server in the browseable servers list. It's really much nicer to have all of the services advertised from the same machine actually show up as the same machine in the network browser. As an alternative, I'd be quite happy if bug 561123 were implemented, because then I could just drop my own .service file for VNC into /etc/avahi/services and disable the built-in advertising in vino.
Hello. There's something weird here, as vino does *not* set server name in avahi. We just set the service name and the port, and let server name to avahi. Here is the code: ret = avahi_entry_group_add_service (mdns_entry_group, iface, AVAHI_PROTO_UNSPEC, 0, vino_mdns_get_service_name (), type, NULL, NULL, port, NULL); See the documentation for avahi (host argument): http://avahi.org/download/doxygen/publish_8h.html#cb05a7d3d23a3b825ca77cb1c7d00ce4 So, I'm closing this as not_gnome, feel free to reopen if you are sure that's a vino issue.
I think it actually is the Service Name that's the question here rather than the host name. Terminology confusion. Regardless of whether you're setting the hostname or not, the string in question is coming from vino. server/vino-mdns.c:71: mdns_service_name = g_strdup_printf (_("%s's remote desktop on %s"),
Sure that string comes from vino. My understand is that vino is doing the right thing, using the avahi API. When I closed the bug as not_gnome I meant that the issue is somewhere else, in avahi or mac os, I don't know. I don't have a mac os nearby to try it out, so, this bug will likely remain open during a loooog time...
The service file I put in /etc/avahi/services (with disable-user-service-publishing=yes) to get it to show up correctly on the Macs is: <?xml version="1.0" standalone='no'?><!--*-nxml-*--> <!DOCTYPE service-group SYSTEM "avahi-service.dtd"> <service-group> <name replace-wildcards="yes">%h</name> <service> <type>_rfb._tcp</type> <port>5900</port> </service> </service-group>
They show up in avahi-browse like this: vino's: + eth0 IPv4 mythfe's remote desktop on basementhtpc VNC Remote Access local my service file: + eth0 IPv4 BasementHTPC VNC Remote Access local that middle column is the same thing that shows in the Finder sidebar on the Macs.
That said, the way avahi advertises is useful if you have more than one desktop and they're owned by different users and both are running a vnc server on different ports. Bug 561123 is probably a better fix.
So, you're basically requesting that we change our service name from: "%username's remote desktop on %machine" to: "%machine" That's right, if two users are running two gnome sessions (two vino servers), it's useful to publish the username in avahi as well the hostname (see for instance bug 461773). So, let's close this one and work on bug 561123 for vino 2.30 (next cycle).