Hello, On Thu, Sep 17, 2009 at 8:47 PM, Daniel Kahn Gillmor <d...@fifthhorseman.net> wrote: > 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
It should! > 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?) How about taking approaches other authoritative nameserver packages do? > 3) run tinydns-conf to set up the servicedir It should! > 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. I think, this should be left to the administrator. A main purpose of the package is to prepare some prerequisites for the administrator, like creating necessary user and group, setting a service directory. > > > 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? As I mentioned before, in my opinion, a package should provide some prerequisites and ready-to-use skeleton to the administrator, so he is left to his own dns tasks. > > --dkg > > Thanks for reply! :) -- My Intellect is the Power -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
