[Olsr-dev] Reloading DNS server hosts file from nameserver plugin

Hannes Gredler (spam-protected)
Tue May 6 22:27:56 CEST 2008


hi andres,

both of your patches look good. may i ask you in addition
to tweak also the README_NAMESERVICE file and
document your parameters and also include the rationale
(as per your email below) in the file.

perhaps a commented sample configuration for dnsmasq
would be even better and for sure increase adoption.

tx,

/hannes

On Tue, May 06, 2008 at 03:47:17PM -0300, Andr??s Ambrois wrote:
| On Saturday 05 April 2008 10:26:42 Andr??s Ambrois wrote:
| > Hello people!
| >
| >   I'm a member of the Development Group of MontevideoLibre [0], a project
| > dedicated to the construction of a city-wide free (as in freedom) wi-fi
| > network in Montevideo, the capital city of Uruguay.
| >   We have decided to use OLSR as our routing algorithm (yay!), at least for
| > the early stages of the project. We have found the nameservice plugin to be
| > a great solution to many of our problems (dns and service information
| > flooding), and hope to contribute a bit to its development.
| >   The first problem we faced was to provide DNS to nodes not running OLSR
| > (temporal "clients" of the network), which is solved by running a DNS
| > server on "edge" nodes who provide connectivity. However, dnsmasq (and I
| > believe bind too, but I'm not sure) only read the hosts file at startup,
| > and are oblivious to changes in the file.
| >   We found that a SIGHUP signal would cause dnsmasq to re-read the hosts
| > file (see NOTES section in its manfile), and named (the bind dns server) to
| > reload (see the SIGNALS section in its manfile). In order to acomplish this
| > from the nameservice plugin we wrote two patches: The first one sends a
| > sighup directly to a process (specified by its pidfile in the plugin
| > parameters) right after the hosts file is written. The second executes a
| > script when the hosts file is written, and, optionally, another one when
| > the services file is written. Of course, the first has the advantage of
| > being much more efficient, and the second of having many more applications.
| >   It would make us very happy to see this included in a future release of
| > olsrd, so we can give back something.
| >   I take the liberty of attaching the patches to this email. Please let me
| > know if there's a better way to get this commited.
| >   Thanks in advance!





More information about the Olsr-dev mailing list