[Dnsmasq-discuss] dyndns-style addition of names
simon at thekelleys.org.uk
Sat Apr 14 17:18:52 BST 2007
richardvoigt at gmail.com wrote:
> If you return a lease with a far future expiration, would that not
> effectively reserve the address? Would dnsmasq report that long
> timeout to the client next time it renews, or use the configured lease
> time? I guess that then when the renewal expired, before the
> expiration reported by the script, the lease could be reassigned, so
> that's no good.
It would probably work, but there are plenty of things which might break it.
> It would be extremely useful to be able to report address reservations
> via the external script. The script accepts a parameter indicating
> startup vs. new lease vs. lease expiration, right? Then a new command
> could be added for enumerating reservations, which should be ignored
> by existing scripts and hence backward compatible.
I think you might have a wrong idea about exactly how the script can be
used to maintain the lease database. Information about existing leases
flows into dnsmasq exactly once, when dnsmasq starts up. After that,
changes in the lease database flow out, so that the external view of the
database is kept up-to-date, but dnsmasq uses an internal copy, so the
script cannot be used to push information into dnsmasq. The external
database (or dnsmasq.leases) is only used to store the lease database
whilst dnsmasq is stopped, or over a reboot.
> Seems like that is necessary for managing reservations in an external
> database (well, you could update /etc/ethers from a trigger procedure
> I suppose).
> Does SIGHUP also re-read /etc/ethers? I don't see that mentioned in
> the man page, but I skimmed it rather quickly.
It does: the man page is deficient about this, but the next release
> Just that /etc/ethers
> is treated as if it were commands in the config file, and the config
> file isn't reread. I guess there would be trouble with reservations
> accumulating each time /etc/ethers was read, but not being able to
> remove unlisted ones due to the fact that they could have been taken
> from the config file (store a flag indicating the source of the
> reservation? config file vs /etc/ethers?)
All that is done: it works fine to keep the reservations in /etc/ethers
and send SIGHUP whenever it changes.
More information about the Dnsmasq-discuss