the argument to have a tinydns-run package appears to be made by analogy with the dnscache-run package. however, i'm not convinced that the analogy holds. dnscache-run defines a specific, commonly-used instantiation of dnscache: a resolving nameserver for the local host running on the loopback interface. Such a setup has a default configuration and demands no interaction from the local administrator to set up. As an authoritative nameserver, tinydns has no such explict default configuration. The administrator needs to know (at least): * what IP address the nameserver should listen on * what domains should be served * what records should be included in those domains This is a non-trivial amount of configuration -- so much so that it seems unlikely to be useful to prompt for all of it via debconf, in which case the server would not be well-configured anyway. So, what would such a package look like? The most heavyweight package i can imagine would presumably: 0) create a tinydns user and a dnslog user, if they do not already exist 1) guess at the preferred IP address to listen on (choose from the non-loopback IP addresses on the host somehow? maybe prompt via debconf for the IP address) 2) ask the user what domains to be served? (would this be debconf abuse?) 3) run tinydns-conf to set up the servicedir 4) make a root/data file, (either empty or containing the ns records gathered in stage 2) and compile it to root/data.cdb 5) link the servicedir into the running daemontools or runit supervision suite. The administrator would be left with the task of updating root/data as needed. If you still think such a package would be useful, do you have any proposals for how to gather reasonable defaults for steps 1 and 2? --dkg
Attachment:
signature.asc
Description: OpenPGP digital signature