From: Petter Reinholdtsen
The forward and reverse searches can be simulated using ldapsearch like this:
@@ -180,6 +182,7 @@ Config,dc=skole,dc=skolelinux,dc=no" and filter "(&(objectClass=dhcpService)(|(dhcpPrimaryDN=cn=dhcp,dc=skole,dc=skolelinux,dc=no)(dhcpSecondaryDN=cn=dhcp,dc=skole,dc=skolelinux,dc=no)))". The search result is this entry: +Next, the entire subtree is searched for, one level at the time. When all the DHCP configuration is loaded, it is ready to receive requests. @@ -206,23 +210,33 @@ When a DHCP request come in, LDAP is searched for the MAC address of the client (00:00:00:00:00:00 in this example), using a subtree scoped search with "cn=DHCP Config,dc=skole,dc=skolelinux,dc=no" as the base and "(&(objectClass=dhcpHost)(dhcpHWAddress=ethernet -00:00:00:00:00:00))" as the filter. +00:00:00:00:00:00))" as the filter. This is what a host object look +like: + +dn: cn=DHCP Config,dc=skole,dc=skolelinux,dc=no cn: DHCP Config objectClass: top @@ -191,6 +194,7 @@ dhcpStatements: authoritative dhcpOption: smtp-server code 69 = array of ip-address dhcpOption: www-server code 72 = array of ip-address dhcpOption: wpad-url code 252 = text +
Conclusion ========== -The PowerDNS implementation seem to be very flexible when it come to -which LDAP schemas to use. Its "tree" mode is rigid when it come to -the the LDAP structure, while its "strict" mode is very flexible, ++dn: cn=hostname,cn=group1,cn=THINCLIENTS,cn=DHCP Config,dc=skole,dc=skolelinux,dc=no +cn: hostname +objectClass: top +objectClass: dhcpHost +dhcpHWAddress: ethernet 00:00:00:00:00:00 +dhcpStatements: fixed-address hostname +
The PowerDNS implementation seem to be very flexible when it come +to which LDAP schemas to use. While its "tree" mode is rigid when it +come to the the LDAP structure, the "strict" mode is very flexible, allowing DNS objects to be stored anywhere under the base cn specified -in the configuration. +in the configuration.
-The DHCP implementation on the other hand is very inflexible, both +The DHCP implementation on the other hand is very inflexible, both regarding which LDAP schemas to use and which LDAP structure to use. I guess one could implement ones own schema, as long as the objectclasses and attributes have the names used, but this do not really help when the DHCP subtree need to have a fairly fixed -structure. +structure.
SRCH "dc=skole,dc=skolelinux,dc=no" 2 0 0 0 0 filter: (&(objectClass=dhcpServer)(cn=dhcp))