Tester please?

Joel Newkirk freerunner at newkirk.us
Fri Aug 22 01:20:49 CEST 2008


It's a pain, and I suspect massaging it into an external build framework
would be more trouble than it's worth.  DJB has some frankly weird build
and install procedures for some of his software.  I've built Qmail server
and djbdns&co many times in the past for servers, so was able to work my
way through it, having at various times on various platforms coerced it
into building.

The packages and original build instructions are at
http://cr.yp.to/djbdns.html, but they're expecting to be in the destination
server environment, and the build doesn't accommodate cross-compiling.  I
ended up working up a script that builds the full djbdns, tcpserver, and
daemontools packages.  Most of daemontools (well, obviously not the source
and scripts) and the merest fraction of djbdns (just the dnscache binary,
actually, plus the svcscan control structure created during install) are
all that are needed, tcpserver is only needed for a true DNS server, since
localhost recursive lookups will always utilize UDP. (TCP is only used for
DNS when the response is too large for a single UDP packet, which is pretty
rare outside of zone transfers between DNS servers) The script I wrote to
build them is at http://newkirk.us/om/mokodnscache.sh - commented somewhat,
it presumes that http://cr.yp.to/djbdns/djbdns-1.05.tar.gz and
http://cr.yp.to/daemontools/daemontools-0.76.tar.gz are in the same
directory as the script.  (http://cr.yp.to/ucspi-tcp/ucspi-tcp-0.88.tar.gz
as well, if you uncomment that section to build tcpserver as well)

The result of the build will be a crapload of binaries you don't need, a
handful you need, and install scripts.  The install scripts /will/ work on
the Freerunner, but will install everything of djbdns with symbolic links
everywhere, while daemontools' installer creates links all over the place
and leaves the binaries inside the build directory.  The ipk I posted
contains just dnscache and the necessary support, and as much as possible
places everything under /usr/local, whereas the 'standard' install scripts
require three root folders (/service, /commands, /admin) to contain
everything, with more symbolic links than lines of code.  (it creates links
to links to the binaries!)

http://newkirk.us/om/mokodnscache.sh is not elegant, isn't proper, but
produces working binaries, which was my sole goal.  (nevertheless, it's
fairly thoroughly commented to explain what's going on when it
short-circuits one of the build-time tests or alters a config file)  The
second half of the job I set out on is still only half finished, as I need
to test the ipk and work on eliminating a few more unneeded hunks.  (I
think that by disabling logging of queries, I can cut the size in half by
eliminating all the special DJB logging and timestamp support binaries -
he's very careful in his code, required his own logging and timestamp
support because he found syslog lacking, and wanted IIRC
microsecond-accurate timestamps)

When all is said and done, I suspect the better solution will be a
standalone single-binary dns cache, but I looked at dnsmasq and decided to
stick with what I was familiar with to start, and it turned out to be less
resource-hungry than I'd feared so I may just stick with it if I can pare
it down and polish it a bit further.

j


On Thu, 21 Aug 2008 16:25:42 +0930, Rod Whitby <rod at whitby.id.au> wrote:
> Timo Juhani Lindfors wrote:
>> Joel Newkirk <freerunner at newkirk.us> writes:
>>> http://newkirk.us/om/dnscache_2.1.5_armv4t.ipk and let me know of any
>>
>> Hmm, how do I build this from source?
> 
> Indeed - I'd be happy to test bitbake recipes for these ...
> 
> -- Rod
> 
> _______________________________________________
> Openmoko community mailing list
> community at lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community





More information about the community mailing list