Mika Havela wrote:
> I'm looking into acf-tinydns. I'm starting to get a picture on what is what.
> But because there are so many options, I would like to hear your
> opinion on how you see things.
Tinydns' author (D.J. Bernstein) is a genius, but, like many geniuses,
he has "a better way to do it" than the standard Unix way. So to
install any of his software the way he wants it installed means
installing a completely different way of starting/stopping programs, log
management, configuration files, etc.
The /etc/init.d/tinydns script is a hack to make tinydns 'play nice"
with the way we normally do things.
Here's how tinydns wants to work:
tinydns needs to read a binary file called data.cdb. That contains all
the DNS info it serves. If you make any change to your dns records,
you need to run the tinydns-data program to recompile data.cdb.
tinydns-data is hardcoded to compile a file called "data"
So the process is roughly:
data ("human" readable) -> [tinydns-data] -> data.cdb -> [tinydns]
That works perfectly if you have only one domain you are managing, or if
your number of dns entries is small... but what if you have 4 or five
domains... or 100 domains?
There's various solutions out there of how people have done it, but
basically, it involves concatenating all the files into one big "data'
file, and then using tinydns-data on the "data" file.
That's the approach we are using with alpinelinux. (Actually, we use both)
If there is a file named /etc/tinydns/data, then /etc/init.d/tinydns
uses it. If there is not /etc/tinynds/data file, then
/etc/init.d/tinydns copies /etc/tinydns/* to /var/cache/tinydns/data
In either case, the tinydns-program still has to run on a file named
"data", and tinydns needs to read a file named "data.cdb" :-(
The /etc/init.d/tinydns reload will recompile data into data.cdb if
So, if you are asking how I see it, I see the /etc/tinydns/* files as
the authoritative source, and /var/cache/tinydns/data as being a
temporary file. We should not use /var/cache/tinydns/data for anything
> If you could specify a information layout, then I would be really grateful.
> This layout would help me to know how to display information, and how
> I could design a configuration page. (I will give a example later on
> in this mail)
> For the moment, I'm reading all config-files in /etc/tinydns (and it's
> I found out that /var/cache/tinydns/data holds the information that
> tinydns is using at the moment... So for informational purpose, I
> think it would be best to display the data on what tinydns knows at
> the moment (that is... we present data from /var/cache/tinydns/data).
> But when letting the user do it's configuration, then this information
> should be based on the config-files in /etc/tinydns/ (and its
> (Correct me if I'm wrong).
See above. I think you want to use /etc/tinydns only.
> But the config-files in /etc/tinydns and the /var/cache/tinydns/data
> holds information similar to each other... so by creating functions
> for one config-file, will be useful for each config-file and for the
> /var/cache/tinydns/data. (Just some info that I found out while
As above, /var/cache/tinydns/data should be the sum of all the
/etc/tinynds/* text files
> Just displaying rows (row by row) from the config-files would not help
> the user to get a clear understanding on what is configured.
> So if we put the information in different groups (and subgroups), then
> it might be more understandable.
> My thought is... At the "information" page, you display information
> grouped like follows:
> (This suggestion will clearly show my limited knowledge in tinydns
> configuration - But that's where I hope your suggestions will
> enlighten me.)
> First we group things in the Location definition (ex,in,??).
> Everything else is sectioned under one of these groups.
> Next we group in Type of config ('.', '%', '+', '=',...)
> Under each group "Type" we present the different objects and their
> options (tts,IP,whatever)
> I don't know in which order we should sort the different groups and
> the items in the groups.
> But I guess that the objects (the configuration) should be ordered per
> domain-name and ordered most specific first, and less specific last.
> (see next example)
> tmp.wiki.alpinelinux.org = 111.222.333.444
> dev.alpinelinux.org = 220.127.116.11
> alpinelinux.org = 18.104.22.168
> foo.bar.temp.net = 111.222.333.444
> bar.temp.net = 111.222.333.444
> temp.net = 111.222.333.444
> Until now we only have mentioned how to "show" current configuration
> in a understandable way.
From my experience, the the reason for separate files in /etc/tinydns
is beause I want to see "alpinelinux.org" *OR* "temp.net" - but not both
at the same time.
I would think sorting by domain first would be preferable. (or even a
dropdown to select the domain to work on)
Location information isn't of sorting information to me... other than
showing that both "wiki.alpinelinux.org:internal" and
"wiki.alpinelinux.org:external" are defined....
As far as sorting, sort by alpha name is probably fine. or sort by IP
address.. Not sure it really matters.
> Next we need to figure out how we could help the users to
> 1) Edit a existing configuration
> 2) Add new configuration (from scratch)
> 3) Delete a existing configuration
> These above mentioned steps needs to be sectioned/displayed in a
> understandable way.
> But maybe if we find a good way of presenting the information (what we
> talked about earlier), then maybe we just could add buttons like
> [Edit] [Delete] next to each configuration object.
> Then we could add a [Add object] next to each "Type of config" heading
> (or something like that).
> Any suggestions and ideas are welcome!
> In the svn-tree you find the current status. There is a 'Status' tab,
> showing information from the config - files (I know... I should fetch
> this information from /var/cache/tinydns/data instead).
> The output is limited (still waiting for your suggestions).
> Next we have a 'Config' tab. The options there are also limited.
> I'm working on the different functions that should handle/modify the
> different configurations so we could display things in a
> understandable way.
Mmm... Yes, this probably needs to be storyboarded first...
> acf mailing list
Received on Mon Feb 18 2008 - 08:17:08 GMT