From: Petter Reinholdtsen Date: Fri, 16 Jul 2010 22:33:15 +0000 (+0000) Subject: More text. X-Git-Url: http://pere.pagekite.me/gitweb/homepage.git/commitdiff_plain/2de4cd240330f36b5d1404353c56f17c49b51716 More text. --- diff --git a/blog/draft/2010-07-03-ldap-searches.txt b/blog/draft/2010-07-03-ldap-searches.txt index 7e33251be1..b924372e54 100644 --- a/blog/draft/2010-07-03-ldap-searches.txt +++ b/blog/draft/2010-07-03-ldap-searches.txt @@ -73,7 +73,9 @@ hinforecord, mxrecord, txtrecord, rprecord, aaaarecord, locrecord, srvrecord, naptrrecord and modifytimestamp. For reverse entires it also do a subtree scoped search bug this time the filter is "(arecord=10.0.2.2)" and request the attributes associateddomain, -dnsttl and modifytimestamp.

+dnsttl and modifytimestamp. In short, in strict mode the objects with +ptrrecord go away, and the arecord attribute in the forward object is +used instead.

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: +
 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
+
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=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
+
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, +

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))