Warning: Can't synchronize with repository "(default)" (Unsupported version control system "svn": No module named svn). Look in the Trac log for more information.

Ticket #1099 (closed enhancement: wontfix)

Opened 13 years ago

Last modified 10 years ago

[PATCH] Zeroconf/Bonjour support on Linux

Reported by: hdiogenes Owned by: anonymous
Priority: normal Milestone: 1.x
Component: TurboGears Version:
Severity: normal Keywords:


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.


turbogears-avahi-support.patch Download (2.7 KB) - added by hdiogenes 13 years ago.
TurboGears Avahi support

Change History

Changed 13 years ago by hdiogenes

TurboGears Avahi support

comment:1 Changed 13 years ago by hdiogenes

I've written some documentation here.

comment:2 Changed 13 years ago 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.


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.

comment:3 Changed 13 years ago 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.


comment:4 Changed 13 years ago by hdiogenes

  • Status changed from closed to reopened
  • Resolution worksforme 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.

comment:5 Changed 13 years ago by hdiogenes

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

comment:6 Changed 13 years ago 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 :)

comment:7 Changed 13 years ago by jorge.vargas

  • Milestone changed from 1.0 to 1.0b2

lets decide if this goes or not

comment:8 Changed 13 years ago 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...

comment:9 Changed 13 years ago 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.

comment:10 Changed 13 years ago by godoy

Applied in r1913 and r1914.

comment:11 Changed 13 years ago by jorge.vargas

  • Version 0.9a6 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.

comment:12 Changed 13 years ago 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.

comment:13 Changed 13 years ago 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.

comment:14 Changed 12 years ago 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


Start avahi-daemon

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

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


Start avahi-dnsconfd

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


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


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

comment:15 Changed 12 years ago by alberto

  • Milestone changed from 1.0b4 to 1.1

comment:16 Changed 12 years ago by alberto

  • Milestone changed from 1.1 to __unclassified__

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

comment:17 Changed 10 years ago by jorge.vargas

  • Milestone changed from __unclassified__ to 1.x

comment:18 Changed 10 years ago by Chris Arndt

  • Status changed from reopened to closed
  • Resolution set to wontfix

Cruft ticket. I think the whole idea of adding zeroconf support to the TurboGears core was not a good one. Or at least registering the app automatically at server startup. If somebody wants this, it would be easy to add an appropriate function for the target platform to the startup items. To try to solve this in a platform independant way is IMHO not TG's responsability.

Closing this ticket as wontfix.

Note: See TracTickets for help on using tickets.