Bug#537223: tinydns-run: review and details

[".coder" <dotcoder@gmail.com>]

Hello,

On Thu, Sep 17, 2009 at 8:47 PM, Daniel Kahn Gillmor
<dkg@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