[Dnsmasq-discuss] Automatic DHCP client naming
wferi at niif.hu
Mon Apr 19 17:32:44 BST 2010
Simon Kelley <simon at thekelleys.org.uk> writes:
> Ferenc Wagner wrote:
>> I can recall reading some warnings about long-running dhcp-scripts, that
>> they block dnsmasq. Did this change?
> It has never been the case, dnsmasq will continue to function even if
> the a dhcp never completes. The rules go like this: at most one instance
> of the script is ever running (dnsmasq waits for the script to exit
> before running the next). Changes to the lease database are which
> require the script to be invoked are queued waiting running of the
> script. The only time that a slow script can have any affect is if
> multiple state-changes occur to a single lease before the script can be
> run. In that case earlier states are discarded and the current state is
> refelected when the script runs.
This paragraph really desires a prominent place in the manual. Thanks
for the clarification!
>> Anyway, wouldn't synchronous scripts be a worthy option, especially if
>> given the possibility to communicate data back to dnsmasq? It's also
>> easy to fork off an async worker from a sync helper, if needed.
> Strict asynchronous (ie block the daemon completely until the script
> returns) would be a very bad idea since it would stop DNS requests as
> well as DHCP. It's very difficult to write a script and be sure that it
> never does DNS resolution, so deadlock would be an ever-present
> possibility. Being a bit more clever and just blocking DHCP would be
> possible, but still opens up the possibility of strange effects if a
> script blocks. Making the DHCP server multi-task will turn dnsmasq into
> ISC dhcpd: a biggish program with a much bigger memory footprint and
> make it much less useful on hardware-limited platforms.
Yes, a timeout should be forced in all cases.
>> A built-in solution (maybe in dhcp-generate-names) would be safer and
>> more efficient, but somewhat cumbersome, because one may want to use the
>> hardware address, the IP address, the client ID, the client provided
>> hostname etc. as a source.
> It's also the case that of the members of that list, _only_ the IP
> address is guaranteed always to be available. (though a proxy for the
> MAC address is always around too.
> For my purposes, something like
>> would be enough, and dnsmasq already has some regex machinery included,
>> but I'm not sure this scheme is general enough, or whether the extra
>> safety and efficiency is worth it. Just brainstorming...
> There's no regex machinery available.
Then I was misled by
> something like
> would be OK, both prefix and tags being optional.
I'd certainly appreciate something like this. Given some instructions,
I'd even try implementing it, if it's easy enough. Is there a public
source control repo for dnsmasq?
More information about the Dnsmasq-discuss