Crossed Wires

test

Well I think “pointless” is a bit harsh…

Yes LDAP is a directory, but it has to be written to sometime! A network with 2000 hosts that renew their lease every hour would result in, on average, an update only every one to two seconds. Probably more than your average telephone directory LDAP server might expect, but would it really be that difficult for a decent enterprise-grade LDAP configuration to bear? I should think that even OpenLDAP would be able to support an additional database (with a different suffix) with database tuning that was less aggressively tuned in favour of read… I suppose the read optimisation of LDAP is more fundamental than what you stick in a DB_CONFIG file though.

Maybe it’s the intangible benefit. I can’t guarantee that doing DHCP using LDAP would be that much better than using the existing methods (like the failover capability of ISC DHCP), but it seems like it should be worth it…

Thanks for the comment!

Vic I think you hit one something very important with your ideas which we at the Apache Directory Project have been trying to bring to life. ApacheDS is a misnomer, it’s a multiprotocol server that contains in process machinery to handle LDAP name space operations across various kinds of backing stores for entries called Partitions. Just like FS partitions you can attach a partition to a specific place in the LDAP namespace to expose entries. Also ApacheDS has protocol server plugins that need to access LDAP data and expose those entries via another protocol like for example the DNS server plugin module. It accesses the various DNS records stored in ADS and exposes them via DNS in the same process space making things fast and secure without the additional hop between a DNS server and it’s LDAP server backing.

Although the DNS server is much more functional we also have a partially implemented DHCP server module. Once we have support for multicast in our Apache MINA based network layer we intend to finish this module. It can store lease information in an area that is mapped to a partition optimized for writes. This can be a simple flat file keeping the leases info in LDIF format. But it can be fast at reads and writes. The ability to mount a partition using a heterogeneous mixture of partition implementations inside the same LDAP directory information tree (DIT) makes it so you and the Russian fellow can have your cake and eat it too.

Now with MMR between ApacheDS nodes that means all the protocol services ApacheDS supports including DNS, DHCP, Kerberos, LDAP, LDAPS and others are automatically replicated. Furthermore we manage and store the configuration information for these protocol service modules inside the LDAP tree in a configuration area. ApacheDS has the ability to snapshot and rollback configuration state across partitions and all entries in the server are versioned making it an idea LDAP server for configuration management. Having all theses services that must be coordinated (orchestrated) to operate together at times under a single configuration node that is versionable and revertable makes life for the admin a heck of a lot easier. Oh and plus with some low level integration tier constructs like  (some implemented and some not) triggers, views, and stored procedures, disaster recovery scenarios with downed sites and DNS fail over becomes trivial to manage. Geo-locality based on source can also be used to handle some minimal content delivery maters using triggers and SP as well. There’s a lot we can do … only our imagination limits us.

The Apache Directory Project can use more volunteers to make this shared vision of ours a reality. Our goal is to build a highly available LDAP server that can make these HA dreams a cakewalk. In the future we would like to see an all-in-one LDAP, NOS, and IdM server without all the moving parts that make infrastructures brittle.