[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