[Pkg-utopia-maintainers] Bug#686294: /var/run/avahi-services: easy way to announce running services

[chrysn]

Package: avahi-daemon
Version: 0.6.31-1
Severity: wishlist

in this bug report, i'd like to propose a way for other packages to
announce their services in an easy way, without being prone to the
problems of installing to /etc/avahi/services/.

existing solutions
==================

so far, packages can announce their services either by

* depositing a description in /etc/avahi/services

  this has the disadvantage of the service being announced independently
  of whether the process is just running. if a daemon gets configured
  not to start, the file has to be removed manually, and in theory, it
  should even be disabled when the daemon is stopped. it's worse even
  when different packages are involved (#622336).

* integrating the avahi library

  some upstream software does this, but authors are often reluctant to
  pull in additional dependencies (eg [transmission]).

* using the dbus api

  didn't investigate into how this works precisely, but for most server
  processes, this would mean an additional dependency as well (this was
  pondered in [transmission]).

proposal
========

it is suggested to create a new directory /var/run/avahi-services, which
should be treated as equivalent to /etc/avahi/services by the daemon, ie
should be watched for file changes and published.

packages could then easily add a `cp /etc/my_daemon/my_daemon.service
/var/run/avahi-services/` line to their start routine, and remove the
file when the daemon gets stopped. on an unclean shutdown, /var/run gets
cleaned at bootup anyway afaik.

in cases like ssh, on which serices like ssh-udisks likely want to
piggy-back (cf #622336), the openssh-server package could keep an
/etc/ssh/avahi-services/ directory and copy all the files there to
/var/run/avahi-services at startup; udisks would just need to drop its
service description in /etc/ssh/avahi-services/udisks.service and be
done with it.

if the file monitoring of avahi-daemon is flexible enough, it would be a
good idea to recursively watch /var/run/avahi-services; not only would
that ease the task of ssh-like packages.

init scripts that configure their daemons via command line args loaded
from /etc/default (eg hddtemp) can, because they already have explicit
knowledge of ports etc, also use serice templates like this:

sed "s/__PORT__/${PORT}/g" /etc/my_daemon/avahiservice.in > /var/run/avahi-services/my_daemon.service

implementation
==============

current avahi-daemon can't be configured to watch two service
repositories; it would need minor patching around occurrences of
AVAHI_SERVICE_DIR in the source code.

outlook
=======

if this proposal makes it upstream, daemons could use
/var/run/avahi-services/ themselves without relying on init scripts.
that would give them good control over the details they publish
(including configured service names, different services being run at the
same time etc) without the need for a library.

related issues
==============

just to give some context, these other bugs would be either directly
affected by solving this or at least are topically near:

* announce ssh: #375685, #389338
* udisks atop ssh: #622336
* another proposal in a similar vein: #483675
* discussion about whether or not to publish something: #616310

[transmission] https://trac.transmissionbt.com/ticket/1968


please consider this proposal; if it helps, i can assemble a patch.

best regards
chrysn

-- 
Es ist nicht deine Schuld, dass die Welt ist, wie sie ist -- es wär' nur deine
Schuld, wenn sie so bleibt.
(You're only to blame for the state of things if you allow it to persist.)
  -- Die Ärzte
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-utopia-maintainers/attachments/20120831/c0660ac2/attachment.pgp>