[Dnsmasq-discuss] patch proposal: getent support for ethers
winckler at campogeral.com.br
Mon Jun 29 16:16:06 BST 2009
> It needs some clean-up, but something like this has some attractions. The
> main drawback I can see is that the get_() library calls can all block for
> arbitrary lengths of time, which leaves the network with no DNS and no DHCP
> and no TFTP. Worse: gethostbyname() and gethostbyaddr() can possibly attempt
> to use DNS to get the host info, routing the queries through dnsmasq, which
> is blocked in the gethost*() call, leading to deadlock.
Yes, it can lead to a deadlock. As many configurations on libNSS and
PAM. But sysadmins are used to deal with this issues.
You can configure timeouts, and you can (must) use the LDAP to resolve
hostnames (hosts) before DNS, so you don't have the deadlock.
> A solution which pulls all the host info from the LDAP database and pushes
> it into a file which is read by dnsmasq (or the named-pipe variant of this)
> avoids that pain.
Sure it does. But the problem of when trigger a HUP signal to dnsmasq remains.
> Maybe something like "--read-ethers=nss" to switch on read-ethers semantics,
> but via the nss, would be good, if this solution is adopted?
Sure. I think a switch is required, and the nss should not be the default.
But, only to be clear, the NSS for ether doesn't support enumeration,
so you can't extract all information during initialisation. It must
query "on demand".
We also may need compilations flags, because not all architectures
support gettent (I think).
More information about the Dnsmasq-discuss