DHCP combined with MySQL

Hi!

In our network we have a user base of approx. 150 PCs. All of them get
their configuration via DHCP. Our DHCP server assigns fixed IP addresses
depending on the MAC address. So, everybody gets 'his' IP address
automatically assigned (together with other data like router, dns, ...)
via DHCP.

We have a database with the users and their MAC addresses. Currently we
have to auto-modify the dhcpd.conf file whenever a MAC address changes or
an additional PC is added.

We want to have the DHCP server query our database with the MAC address to
get the fixed IP address for that host. Could you please give me some
hints where I can find an appropriate DHCP server (is ISC's extensible?).

Thanks
Hansi

On Tue, 09 Aug 2005 18:38:47 +0200, Johann Glaser <(E-Mail Removed)> wrote:
>
>We want to have the DHCP server query our database with the MAC address to
>get the fixed IP address for that host. Could you please give me some
>hints where I can find an appropriate DHCP server (is ISC's extensible?).

man ethers

Hooking basic system operation to a database seems overkill, unreliable,
not smell nice at all For a read many / write rarely database the
unix flat text file map is far better than relying on userspace DBMS.

Grant.

Hi!

> man ethers

Thanks, didn't know that. But it doesn't help me.

> Hooking basic system operation to a database seems overkill, unreliable,
> not smell nice at all For a read many / write rarely database the
> unix flat text file map is far better than relying on userspace DBMS.

You are right, but we have a database which is changed with a comfortable
web interface. It is ugly to need a background script which does the
changes on the system. And it is not network transparent, where a database
is.

Any ideas on a DHCP server which looks up MACs in a DBMS?

Bye
Hansi

In article <(E-Mail Removed)>,
Johann Glaser <(E-Mail Removed)> writes:
> Hi!
>
>> man ethers
>
> Thanks, didn't know that. But it doesn't help me.
>
>> Hooking basic system operation to a database seems overkill, unreliable,
>> not smell nice at all For a read many / write rarely database the
>> unix flat text file map is far better than relying on userspace DBMS.
>
> You are right, but we have a database which is changed with a comfortable
> web interface. It is ugly to need a background script which does the
> changes on the system. And it is not network transparent, where a database
> is.
>
> Any ideas on a DHCP server which looks up MACs in a DBMS?

This type of situation is something I've had to cope with before, but in
a slightly different area: that of users, mail aliases and the delivery
addresses for mail. The key problem was the same though. The data, which
was part of a much larger system with personnel data, was held in an
Oracle DBMS. The basic system operations which needed access to it
wanted flat text files.

The only answer is to satisfy both requirements. It is unreasonable and
impractical to redesign the DBMS to use flat text files, so that
stays as is. It is equally unreasonable to have basic systems operations
reliant on complex DBMS lookups, as others have pointed out. They need
to stay using flat text files.

The solution is then to have something extract the data from the DBMS
and write it into a flat file that the system uses, signalling the
system process to re-read its flat file when it has been done. It needs
to be small, single-purposed, and contain sufficient safety checks to
stop it outputting nonsense information in error situations. I used a
Perl script, which unfortunately could only run once a day because it
took so long (it was a number of years ago). You probably need something
that runs each time a MAC address is changed. I'm not sure precisely
how that would be done, but I believe that basic approach is the only
way to satisfy those two different requirements.

--
Tim Clark

Hi!

> This type of situation is something I've had to cope with before, but in
> a slightly different area: that of users, mail aliases and the delivery
> addresses for mail. The key problem was the same though. The data, which
> was part of a much larger system with personnel data, was held in an
> Oracle DBMS. The basic system operations which needed access to it
> wanted flat text files.
>
> The only answer is to satisfy both requirements. It is unreasonable and
> impractical to redesign the DBMS to use flat text files, so that
> stays as is. It is equally unreasonable to have basic systems operations
> reliant on complex DBMS lookups, as others have pointed out. They need
> to stay using flat text files.
>
> The solution is then to have something extract the data from the DBMS
> and write it into a flat file that the system uses, signalling the
> system process to re-read its flat file when it has been done. It needs
> to be small, single-purposed, and contain sufficient safety checks to
> stop it outputting nonsense information in error situations. I used a
> Perl script, which unfortunately could only run once a day because it
> took so long (it was a number of years ago). You probably need something
> that runs each time a MAC address is changed. I'm not sure precisely
> how that would be done, but I believe that basic approach is the only
> way to satisfy those two different requirements.

This is exactly what we are currently doing. The "ugly" things are to
recognize of anything has changed and then rewrite the config files. These
config files usually contain some more than just the things we have to
recreate - so do some trickery to replace a part of a file. And, there is
still the problem to find out when data has changed, and this across
several hosts which "should" be secure. :-)

PowerDNS offers DNS lookups in a DBMS, Postfix can lookup mail aliases in
a DBMS (and most probably do much more with DBMSes), Apache can lookup
authentication records in a DBMS, name service switch can lookup
user/group info in a DMBS, OpenLDAP can have a MySQL backend, Samba can
use MySQL for the password database. Currently we only have troubles with
DHCP.

But I don't want to argue now. I had a question and the answer seems to be
"you can't have". Thanks for your replies!

Bye
Hansi