[Dnsmasq-discuss] patch proposal: getent support for ethers

Gabriel Winckler winckler at campogeral.com.br
Sat Jun 27 18:58:59 BST 2009


Hi,

>  While your method should work, it definitely won't be efficient.  Since DHCP is a
> polling protocol, requests have to be more frequent than updates
> almost by definition

I'm using a LDAP backend to keep all information in one place. We have
a small team to deal with many hosts, including remote sites. The goal
is to keep all data in a single structure. I'm sure that this
information won't change offen.

The LDAP was designed to handle a large number of querys. Every ls -l,
for example, generates many requests about UID and GID.

>
> I accomplished this by making /etc/ethers a pipe connected to a perl
> script which reads all assignments from the database.

Using a named pipe is really a smart move, but (If I understand
correctly) you have a daemon or a trigger process to send HUP signal
to dnsmasq, right? Why not use this process to recreate the
/etc/ethers and than give the signal?

> I think you could set up something similar for your environment.

Sure, that's my plan B.

> I guess if the number of assignments in the database is far larger
> than the number of simultaneously connected clients then querying the
> database per-request might be better than transferring the entire
> database after each change.

Yes, the number is larger, and that exactly my point. To avoid
recreate a file with every entry all the time.

I think dnsmasq should provide a way of query a information when
needed, instead of always store the table itself.
We could use a generic external program call, but the getent/libnss is
more efficient, has designed for that and is already available.
It also features NSCD, a cache mechanism to speed up the process.

You could try this method to query SQL DBs. There are nss libs for
MySQL, Postgress and sqllite.

> I don't know if the dbus interface would allow updating individual assignments.

I don't know much about dbus, but you also have to consider that the
LDAP server may not be in the same machine of the dnsmasq.


Thanks and sorry for the late replay,

Winckler



More information about the Dnsmasq-discuss mailing list