Storing leases in LDAP

[Shawn Routhier]

> On Mar 10, 2015, at 11:34 AM, /dev/rob0 <rob0 at gmx.co.uk> wrote:
> 
> On Tue, Mar 10, 2015 at 11:50:25AM +0000, Simon Hobson wrote:
>> Ben Humpert <ben at an3k.de> wrote:
>> 
>>> Is any version capable of maintaining the list of DHCP leases in 
>>> LDAP instead of the dhcpd.leases file?
>> 
>> I suspect the answer is going to be no, and no it's not likely to 
>> happen.
> 
> The main reason this is so: ISC DHCP is slated to be replaced by the 
> new ISC Kea project,
> 
> http://kea.isc.org/wiki
> 
> We're unlikely to see any major new features here.  But I would 
> encourage the interested posters here to check out Kea and ask on 
> Kea's mailing list.  Things are not yet set in stone, but Kea's 
> presently in beta and reasonably functional.
> -- 
>  http://rob0.nodns4.us/
>  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users



We are working on Kea (as mentioned above).  One of the features of
Kea is to allow the lease database to be in an actual database.  While
we have written code for some specific DBs (and a local memfile) we
have attempted to build an API for use with the DBs to allow somebody
to replace the ones we happen to use with their own favorite one.

Somebody asked how Kea is doing.  It is doing well, we are working on
the final release of an early version (so not quite 1.0 yet).  It is an open source
project and people are encouraged to visit the various pages for it and help
contribute either code or comments (or suggestions for features) as they wish.

Note that there is a high availability option for DHCPv4 in the current ISC 
DHCP offering - see the failover options.  This provides a protocol for two 
failover peers to cooperate in serving a range.  It also provides some redundancy 
in the lease files (one on each failover peer and the partner can be rebuilt from the peer).

The last mail in the chain asks why a new server instead of simply updating
the current code.  There are several reasons for this but one of the largest
is to try and bring better order to a code base that has been growing for 18+ years.
As mentioned above Kea is being built to be more modular so that you can
add your favorite DB backend instead of hoping that we decide to add it. As
well we plan to have various hooks available within the server to allow somebody
to customize the code by adding a routine that will get called during processing
rather than editing the code or trying to fit a complex task into the configuration
language.

regards,
Shawn Routhier
ISC DHCP