I’m having a bit of an infrastructure redesign here at the Crossed Wires campus. Each time I have an outage (the last one was caused by a power failure) I learn a little more about the holes in my current setup and what I can do better.
I’m implementing a router box on an old low(-ish)-power PC that will be backed up by a virtual machine on my main virt-box. I’ve already done most of the preparation of using keepalived to implement VRRP, and a colleague has given me some pointers in using the Linux-HA tools like Heartbeat and DRBD to make services like e-mail and Samba redundant.
I’ve had a soft spot for LDAP for ages; I’ve always thought that putting as much backend data into LDAP as you can would be a really good way to get failover and redundancy. Instead of having to deal with every single server’s different way of doing replication and failover, just bung everything into LDAP and get that replicating. Sounds good in theory, but in a nutshell it’s not working out that way for the two least-celebrated but most important components of my (arguably any) network: DNS and DHCP.
There are a number of LDAP-backed DNS projects out there. If I’m willing to go to the bleeding edge with BIND on my Gentoo build I can get access to the two most talked-about ones (bind9-sdb-ldap and the BIND DLZ LDAP driver), and other solutions like PowerDNS and ldapdns are available. But none of them offer integration with DHCP, and I’m currently using dhcpd’s “interim DDNS update method” to make sure that hostnames are seen in my DNS when a lease is granted (okay, there’s a Perl daemon that goes with bind9-sdb-ldap, but it seems like a sort-of clunky afterthought).
Speaking of DHCP, LDAP backends for it are virtually non-existent. The only LDAP-enablement I’ve found for ISC DHCP involves putting the config file into LDAP, not the leases… I actually used that for a few days a while ago and pulled it out because it was actually more work to do it that way (and for no benefit in failover).
It seems to me it would be a project ripe for the picking: take an integrated DNS/DHCP server like dnsmasq and make it write into LDAP instead of to a file. If I had more free time I’d probably have a go at it, except for the fact that no-one really seems to be that interested in storing DNS and DHCP in LDAP: that it hasn’t been done says to me that there’s no demand for it, and it’d end up being a big waste of time and effort.
Over to you, lazyweb… Is this a yawning chasm of unfulfilled networking dreams, or a case of me trying to make something more complex than it needs to be? After all, the rest of the world gets by with DNS master-slave and DHCP failover, they should be good enough for me too, right? 😉
Crossed Wires 
test commento
LikeLike
test
LikeLike
ldap is directory (optimized for read not for write access), in such it is pointless to write every dhcp lease in it. imagine large scale network with 2000 and more hosts
LikeLike
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!
LikeLike
For years i’ve used LDAP as DHCP source, i’m now trying to also get the DNS use the same data as backend.
The package, at least in debian is called dhcp3-server-ldap, and works so simple by defining an LDAP source in the config files; then using some dhcp schema in your ldap that provides you a couple of attributes defining needed things.
LikeLike
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.
LikeLike