[PATCH] Zeroconf/Bonjour support on Linux

TurboGears Avahi support

I've written some documentation here.

10:23 jupiter:../TurboGears/1.0 > rpm -qf /usr/bin/dns-sd mDNSResponder-107.5-12 10:23 jupiter:../TurboGears/1.0 > rpm -qi mDNSResponder-107.5-12 Name : mDNSResponder Relocations: (not relocatable) Version : 107.5 Vendor: SUSE LINUX Products GmbH, Nuernberg, Germany Release : 12 Build Date: Sáb 22 Abr 2006 22:50:19 BRT Install Date: Sex 12 Mai 2006 18:55:21 BRT Build Host: blacher.suse.de Group : Productivity/Networking/Other Source RPM: mDNSResponder-107.5-12.src.rpm Size : 844114 License: Other License(s), see package, BSD Signature : DSA/SHA1, Sáb 22 Abr 2006 22:56:07 BRT, Key ID a84edae89c800aca Packager : http://bugs.opensuse.org URL : http://developer.apple.com/macosx/rendezvous/ Summary : Multicast DNS Services (Apple Rendezvous) Description : Network service registration and discovery service.

Authors:

---

Apple Computer, Inc.

Distribution: SUSE LINUX 10.1 (i586) 10:24 jupiter:../TurboGears/1.0 >

I'm closing this as a "worksforme" since it really works out of the box on Linux if you have the correct packages installed.

I think it's worth supporting Avahi, the major Linux distribution are going to ship it (or are already shipping it) by default while that's not true for Apple's own implementation (mDSNResponder) .

I can't find the link now, but Gnome uses Avahi almost everywhere.

http://0pointer.de/blog/projects/bonjour-apache-license

I'm reopening the ticket for the reason that it works for you but still doesn't work for me... :) Ubuntu Dapper doesn't have the mdnsresponder package available (you can try searching for yourself) and, as Michele said, support for mDNS is being deprecated in many distributions in favour of Avahi.

Just documenting that the patch was tested on a Mac and it still works there.

patch seems good, now do we need this on all distro's I'm certain this will never reach windows :)

lets decide if this goes or not

I can't teste avahi support -- I don't run it since it breaks some things and isn't standard for KDE -- but I can test if the mDNSResponder still works. I'll do that right now...

One thing that I noticed: if you have both services installed but only the second running, then you won't get your service advertised. Checking for the binary availability might not be enough.

With that change -- checking what service is running instead of just installed -- this would be much better.

If I remove the unused installation of Avahi, then this works.

The thing is now what problem we want to cause users (and users are the ones that will have both things installed without knowing it...). I'll apply the patch to get support for Avahi in, but this should be fixed in the future. If you want to close this ticket and open a new one this is nice to me. I'll add a note inside the code as well.

Applied in r1913 and r1914.

since the code is there but there is still a problem if both are used I'm moving this to the future.

Jorge, the simplest thing to do for now would be to just remove the break statement at the end. That way, if both programs were installed, both would be run, ensuring the service announcement.

There are several simple things to do to run both commands. Which one is the best or what should really be done is a different beast. I don't believe we need to call the publisher for a stopped daemon, for example. If it throws an error, how should we catch it? What should happen when both daemons are running (is this possible? I haven't tried...)? Etc.

Fixing it requires a bit more thought. For the simple things I could have changed the code as I did to add the notice there. But then, again, I didn't think this was the correct solution.

I really think that we should see which daemon is running and only publishes to that daemon. If both are running, then publish to both -- again, I don't know what happens in that case.

If for some reason the avahi daemon is not running or inaccessible, an error Failed to create client object: Daemon not running is displayed at application startup, nosetests, etc. Before making connection with avahi, this behavior was reported as #1214, and not reproducible on all systems.

Adding the -f --no-fail option will silence this output, although it may be ignoring an important error condition, depending on what your avahi functionality is expected to handle.

The following is the avahi behavior, and the effect of the one-line patch to startup.py. Applies to both trunk and branches/1.0 r2339.

Are dbus or avahi services set to run automatically? (Not avahi, only dbus)

# rc-update show | egrep 'dbus|avahi'
                dbus |      default

$ nosetests
.Failed to create client object: Daemon not running
...........
----------------------------------------------------------------------
Ran 12 tests in 29.785s

OK

Start avahi-daemon

# /etc/init.d/avahi-daemon start
  * Starting avahi-daemon ...        [ ok ]

$ nosetests
.Got SIGTERM, quitting.
...........
----------------------------------------------------------------------
Ran 12 tests in 17.160s

OK

Start avahi-dnsconfd

# /etc/init.d/avahi-dnsconfd start
  * Starting avahi-dnsconfd ...      [ ok ]
$ nosetests
Got SIGTERM, quitting.
............
----------------------------------------------------------------------
Ran 12 tests in 3.165s

OK

Add -f option to avahi-publish-service (use a better args syntax than I did here, putting an item "-f" in the list before "-H" didn't work)

$ svn diff turbogears/startup.py
Index: turbogears/startup.py
===================================================================
--- turbogears/startup.py       (revision 2339)
+++ turbogears/startup.py       (working copy)
@@ -94,7 +94,7 @@
     name = package + ": " + env
     type = "_http._tcp"

-    cmds = [['/usr/bin/avahi-publish-service', ["-H", host, name, type, port]],
+    cmds = [['/usr/bin/avahi-publish-service -f ', ["-H", host, name, type, port]],
             ['/usr/bin/dns-sd', ['-R', name, type, "."+host, port, "path=/"]]]

     for cmd, args in cmds:

Something still isn't right on this system, but the avahi error should be handled more gracefully if possible. As a workaround, with the -f --no-fail option, nosetest output is left undisturbed by avahi daemon errors.

$ nosetests
............
----------------------------------------------------------------------
Ran 12 tests in 2.448s

OK

(can't attach files to trac at the moment)

Batch moved into unclassified from 1.1 to properly track progress on the later