More text.

diff --git a/blog/draft/2010-07-03-ldap-searches.txt b/blog/draft/2010-07-03-ldap-searches.txt
index 7e33251be17577fffececc2021e4918050478e96..b924372e54a1b85d26c9b6f19c5bd6d1863d29e2 100644 (file)
--- 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,
 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.</p>
+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.</p>

 
 <p>The forward and reverse searches can be simulated using ldapsearch
 like this:</p>
 
 <p>The forward and reverse searches can be simulated using ldapsearch
 like this:</p>


@@ -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:
 
 "(&(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:
 

+<blockquote><pre>

 dn: cn=DHCP Config,dc=skole,dc=skolelinux,dc=no
 cn: DHCP Config
 objectClass: top
 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
 dhcpOption: smtp-server code 69 = array of ip-address
 dhcpOption: www-server code 72 = array of ip-address
 dhcpOption: wpad-url code 252 = text

+</pre></blockquote>

 
 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.
 
 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
 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:
+
+<blockquote><pre>
+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
+</pre></blockquote>

 
 Conclusion
 ==========
 
 
 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,
+<p>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
 allowing DNS objects to be stored anywhere under the base cn specified

-in the configuration.
+in the configuration.</p>

 
 

-The DHCP implementation on the other hand is very inflexible, both
+<p>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
 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.</p>

 
 SRCH "dc=skole,dc=skolelinux,dc=no" 2 0    0 0 0
     filter: (&(objectClass=dhcpServer)(cn=dhcp))
 
 SRCH "dc=skole,dc=skolelinux,dc=no" 2 0    0 0 0
     filter: (&(objectClass=dhcpServer)(cn=dhcp))