DHCP server reload on own event

DHCP server reload on own event

Shachar Shemesh shachar at shemesh.biz
Tue Dec 27 11:08:28 IST 2011


On 12/27/2011 10:35 AM, Robert Wallner wrote:
> I thought about that, but, if the dhcp server looses the leases file
> (/var/lib/dhcp/dhcpd.leases), everything will be out of sync.
> The only authority should be the list in the database.
Then, by all means, generate a static allocation file from the database,
just don't bother with reloading the server. If the lease file is lost
(how, exactly?) then that would, within reason, be accompanied by a
server restart.

As long as your server does not have an uptime of over 28 years, you're
gold.

Shachar
>
> On Tue, Dec 27, 2011 at 10:20 AM, shimi <linux-il at shimi.net> wrote:
>> On Tue, Dec 27, 2011 at 9:56 AM, Robert Wallner <kodixos at gmail.com> wrote:
>>> In a DHCP server setup, I have 2 requirements:
>>>
>>> 1. Each client's mac address must be recorded in a database together
>>> with the IP address assigned.
>>> 2. Every new assigned IP address must be given from now on to the same
>>> mac address only, and to nobody else.
>>>
>>> The first one is easy, I use the on-submit event handler to run an
>>> external program to insert the mac address in the database.
>>> I have problems with the second one. The same external program scans
>>> the database, and generates a config file for the DHCP server that is
>>> included from the main config file, and contains "fixed-address"
>>> entries for all the mac addresses. The problem is how I make the
>>> server reload it's configuration files, from it's own "on-submit"
>>> event handler??
>>>
>>> Or am I completely in the wrong direction?
>>>
>>
>> Couldn't both requirements be solved[*] by using:
>>
>> default-lease-time infinite;
>> max-lease-time infinite;
>> min-lease-time infinite;
>>
>> in dhcpd.conf ?
>>
>> -- Shimi
>>
>> [*] I tried answering myself, and found [1] which claims the lease will hold
>> for 914M seconds [per a sniffer]. From some reason he believes that would be
>> 14.4 years. My Kcalc said 914M/(86400*365) is actually 28.98 years...
>> Wouldn't we have to worry about Bug 2038 first?
>>
>> [1] https://lists.isc.org/pipermail/dhcp-users/2009-February/008040.html
>
>


-- 
Shachar Shemesh
Lingnu Open Source Consulting Ltd.
http://www.lingnu.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20111227/2504c2b7/attachment.html>


More information about the Linux-il mailing list