I second this...  Actually, I'd just like it to advertise properly.  Right now it 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.  I can get the proper advertising by dumping a .service file into /etc/avahi/services/ for _rfb._tcp, but that doesn't stop the improper advertising, which this bug would allow.  See also bug 572470.

Workaround: Add

disable-user-service-publishing=yes

to the [publish] section of /etc/avahi/avahi-daemon.conf and restart avahi-daemon.

This will disable *all* services from being published unless they're defined in a .service file in /etc/avahi/services/

/etc/avahi/services/vnc.service (to replace the VNC entry) looks like this:

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

Created attachment 162783 [details] [review]
Patch to add gconf variables for enabling zeroconf enable and broadcast name

I'm unfamiliar with Gnome programming, but this seems to work.  I intend to clean it up a little more, and revert the whitespace churn.  Let me know if there are any newbie pitfalls going on here.

With the patch in #4, I can toggle zeroconf or manually specify the name in gconf-editor (on Ubunutu 10.4 desktop), and instantly see the change in Chicken-of-the-VNC on OSX laptop.

Is there any way to use the /etc/dbus-1/system.d/avahi-dbus.conf configuration file as a workaround?
I noticed that there are various <deny> rules that can be used in controlling what information is sent to Avahi through DBus. Is there a way of blocking just the signal from Vino rather than completely switching off DBus-Avahi communication?

This may not be the right place to suggest it, but I'm really struggling with the DBus documentation!

This is indeed VERY troublesome.

Two years without any updates on this, even after a proposed patch.

The problem is that Mac OS X clients *want* the VNC server to use the same service name (hostname) as the actual AFP share, in order to roll them into a single item in the Finder sidebar.

As it is now, Mac users see at least TWO items for their Linux boxes on the network; one that only supports file sharing, and one that only supports VNC.

The solution: Allow us to use a gconf setting to tell Vino to always export as HOSTNAME.

The temporary workaround that worked for me: Name the user account the same as the hostname, and set Vino to export as hostname (see earlier messages in thread).

Anyway, this really should be in gconf. Please, can anyone implement this easy-to-fix 2 year old issue?

This is how it would look if Vino had an option to properly expose its VNC service named after the hostname:

http://www.maclife.com/files/u129772/7-logon_full.jpg

As you see, Mac clients will then roll the AFP and VNC services into a single sidebar entry with both features in one item.

Please implement this easy fix.

Created attachment 215481 [details] [review]
Makes Vino always use hostname as service name

Comment on attachment 215481 [details] [review]
Makes Vino always use hostname as service name

In the meantime, I wrote a small patch which hardcodes the service name to be whatever the machine's hostname is.

To apply it? Well that's a VERY long story; you MUST get the same Vino version as your distro, all the build-dependencies for your distro's version, the EXACT same configure-parameters, any patches your distro applied, etc.

If you have all that, then by all means apply my patch and build it.

This is JUST for people that know what they're doing!

My results: http://i.imgur.com/RkgM6.png

The fileserver and screen sharing now shows up as one cleanly combined item in Finder, which is how Vino should be behaving - or at least have an option for it! Only one user can be logged into a graphical desktop at a time, so there is only "THE" machine, so I don't get all this Vino "username's desktop on HostName" nonsense. At least add the option to always export by hostname and give us gconf choices for username, username on hostname, or hostname!

Ah, I just understood why you want to have the username in the default service announcement; if multiple users run the gnome desktop you can have multiple VNC servers on the same host.

Okay then, the solution is to provide an option to disable Avahi registration in Vino so that power users can disable it and manually create an Avahi service file with any service name we desire.

Either way, I've now bumped this bug sufficiently and hope that somebody takes notice; it's been buried for 2 years.

 Just had a great idea!

So the issue:
* Naming the service after the hostname means that only one AVAHI service can be published; the next desktop would try to register with the same service name and be denied by AVAHI due to name clash.
* This is why username-based service naming was made the norm.
* The reason for "username's remote desktop on hostname" naming was to prevent a separate issue where multiple machines all with the same username would get confusing on a network since a VNC browser would see a bunch of duplicate entries.

Okay so those were the justifications for the current system, but here's a better idea (for an alternative hostname-based gconf option):
* Premise: Most people will only ever be logged into one graphical shell at a time, hence only one Vino server. Moreover, naming the VNC service after the hostname is - at its CORE - a much better thing than to name it by username (there's a preference in services to either name them %h or "My Service @ %h".
* So how can we achieve that without name clashes? Elementary, Dear Watson! Provide an alternative config option to do hostname-based naming, then do it as follows:
* 1st Service Registration: hostname
* 2nd: hostname (username)
...
* 10th: hostname (username)

This avoids multi-gnome session service name clashing and allows registration of them all using nique names, while ensuring that most people will only ever see hostname exported since they'll only have one user running an actual Gnome shell (almost nobody has the situation where multiple graphical shells are running at once, unless they're running X client somewhere and exporting the deskop to another connecting machine, which is super rare, but I digress).

However, there is an issue with my idea, picturing hostname is Grasshopper):
* Bob logs in and "Grasshopper" VNC service is published.
* Lisa logs in and creates a Gnome desktop, "Grasshopper (Lisa)" is published.
* Bob logs out, and now only "Grasshopper (Lisa)" exists until someone else logs in and creates a desktop whereby the name will be free for registration again. Bad!

Here's the slightly more involved but fantastic solution that's robust enough that it would allow the hostname option to become a first-class citizen on the network:
* When a Gnome shell is launched, check what output DISPLAY is being used. If it's a PHYSICAL display connected to that machine, name the service "Grasshopper" to represent the ACTUAL physical desktop of that machine.
* If the Gnome shell is NOT outputting to the local physical display, name the service "Grasshopper (Lisa)" or better yet "Grasshopper (Lisa's Remote Desktop)" to distinguish that it's NOT the actual physical comouter deskrop that's being shared.
* When Lisa logs out, unregister her "Grasshopper (Lisa's Remote Desktop)" service to clear that name from the network.
* When whoever was at the physical desktop logs out, unregister the "Grasshopper" service from the network.
* If Lisa was now to physically log on to the comouter using the locally connected display, name her service "Grasshopper".
* If Bob now connected over the network, name his desktop service "Grasshopper (Bob's Remote Desktop)"

This would be quite easy to implement, as all you'd have to do is have the service name-decision code check whether the user is on a physical display. No need for any housekeeping code of any kind.

Gain from this setup:
* Most people only ever have one desktop and will see a cleaner service, in particular Mac clients will love rolling two hostname entries (file sharing snd remote desktop) into one combined entry.

Minor issue caused by it: (Which is why this should be OPTIONAL and not the default)
* You don't know the name of the user on the actual remote desktop without being at the machine, so you don't know which user's VNC password to use, however, anyone benefitting from this option would most likely be the person that is logged in and know what password to use. (It'd be worth exploring if the DNS-SD service format for remote desktop has some optional txt-record field for metadata/notes where logged in username can be put)

Now, can anyone see any other possible issues or is this good enough to proceed to implementation?

My apologies if what I'm saying is wrong, but I agree with Vincent. I have some of my Ubuntu systems configured to allow screen sharing with my Mac (that is, controlling them from my mac), but it is quite annoying having two network devices show up for each computer - one for the actual computer, and one for "username's remote connection on computer name".  It would be the best to have them combined into one, which I think is what you are talking about, right?

You can have multiple users on console simultaneously, thanks to fast user switching.

Just for comparison, here's how Apple deals with this in Mac OS X when you have screen sharing enabled:

There is one VNC server listening, no matter how many users are logged into desktops.

When a remote user connects to the VNC server using actual VNC (rather then their extended protocal that includes a username and password) you get a login screen that lets you log into that computer as a local user.  If you log in as a user who's already logged into a desktop, you get to share their desktop.  If you log in as a different user, you get an additional prompt that asks if you want to request of one of the logged in users to share their screen or to start a virtual desktop with your own login.

Dave Miller: Ah yes I forgot that Linux can have multiple people running the shell even though only one may be at the physical console.

Well, the fix is a bit more complex in that case but still easy:

1) Announce whoever is at the PHYSICAL console as MACHINENAME.
2) Announce anyone else as MACHINENAME (USER's Remote Desktop).

To implement this, Vino would have to de-announce and re-announce Avahi services as gnome shells are spawned/killed, to switch them over to their proper names whenever needed.

I don't have the time nor Vino expertise to implement this, however, and am using my hardcoded "patch" instead. It's enough for me and gets the VNC + File Sharing AVAHI services properly merged into the same entry in the Finder sidebar, which is what this issue is all about in the first place.

http://i.imgur.com/RkgM6.png

As you can see, a single entry in the left sidebar, and that entry in turn has separate buttons for File Sharing and Screen Sharing ("Share Screen..."), all thanks to my rough patch that forces the Vino service name to reflect the machine name.

It would be nice if there were any takers for this feature addition, as it would mean Vino was playing along better with Mac OS X.

Vino is not under active development anymore and unmaintained.

Please use gnome-remote-desktop instead.

Closing this report as WONTFIX to reflect reality.