Ticket #1099 (reopened enhancement)

Opened 2 years ago

Last modified 1 year ago

[PATCH] Zeroconf/Bonjour support on Linux

Reported by: hdiogenes Assigned to: anonymous
Priority: normal Milestone: __unclassified__
Component: TurboGears Version:
Severity: normal Keywords:
Cc:

Description

Bonjour support currently requires a "/usr/bin/dns-sd" binary, which I believe is available only on Macs.

I'm sending a patch for startup.py that publishes the TurboGears service through Avahi, which is a LGPL Zeroconf implementation for Linux.

Note for Ubuntu users: apt-get install avahi-daemon (and optionally service-discovery-applet) to try it.

Attachments

turbogears-avahi-support.patch (2.7 kB) - added by hdiogenes on 08/30/06 22:29:57.
TurboGears Avahi support

Change History

08/30/06 22:29:57 changed by hdiogenes

  • attachment turbogears-avahi-support.patch added.

TurboGears Avahi support

09/02/06 21:04:59 changed by hdiogenes

I've written some documentation here.

09/03/06 08:47:15 changed by godoy

  • status changed from new to closed.
  • resolution set to worksforme.

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.

09/03/06 18:50:02 changed by michele

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

09/03/06 22:28:30 changed by hdiogenes

  • status changed from closed to reopened.
  • resolution deleted.

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.

09/05/06 19:21:49 changed by hdiogenes

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

09/23/06 20:16:00 changed by jorge.vargas

  • milestone set to 1.0.

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

09/23/06 23:15:18 changed by jorge.vargas

  • milestone changed from 1.0 to 1.0b2.

lets decide if this goes or not

09/24/06 07:11:54 changed by godoy

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

09/24/06 07:27:05 changed by godoy

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.

09/24/06 07:32:31 changed by godoy

Applied in r1913 and r1914.

09/25/06 19:35:18 changed by jorge.vargas

  • version deleted.
  • milestone changed from 1.0b2 to 1.0b4.

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

09/26/06 00:28:17 changed by hdiogenes

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.

09/26/06 05:31:42 changed by godoy

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.

01/04/07 22:30:16 changed by jeffk

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)

01/11/07 14:53:47 changed by alberto

  • milestone changed from 1.0b4 to 1.1.

03/28/07 12:42:15 changed by alberto

  • milestone changed from 1.1 to __unclassified__.

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