More text.

[homepage.git] / blog / draft / 2010-07-03-ldap-searches.txt

diff --git a/blog/draft/2010-07-03-ldap-searches.txt b/blog/draft/2010-07-03-ldap-searches.txt
index 7e33251be17577fffececc2021e4918050478e96..aa43381c919ae768cce7db373d1455597721e72c 100644 (file)
--- a/blog/draft/2010-07-03-ldap-searches.txt
+++ b/blog/draft/2010-07-03-ldap-searches.txt
@@ -12,12 +12,13 @@ To get this information, I started slapd with debugging enabled and
 dumped the debug output to a file to get the LDAP searches performed
 on a Debian Edu main-server.  Here is a summary.
 
 dumped the debug output to a file to get the LDAP searches performed
 on a Debian Edu main-server.  Here is a summary.
 

-powerdns
-========
+<p><strong>powerdns</strong></p>

 
 

-http://www.linuxnetworks.de/doc/index.php/PowerDNS_LDAP_Backend
+<a href="http://www.linuxnetworks.de/doc/index.php/PowerDNS_LDAP_Backend">Clues
+on how to</a> set up PowerDNS to use a LDAP backend is available on
+the web.

 
 

-<p>PowerDNs have two modes of operation using LDAP as its backend.
+<p>PowerDNS have two modes of operation using LDAP as its backend.

 One "strict" mode where the forward and reverse DNS lookups are done
 using the same LDAP objects, and a "tree" mode where the forward and
 reverse entries are in two different subtrees in LDAP with a structure
 One "strict" mode where the forward and reverse DNS lookups are done
 using the same LDAP objects, and a "tree" mode where the forward and
 reverse entries are in two different subtrees in LDAP with a structure


@@ -41,7 +42,7 @@ cnamerecord, soarecord, ptrrecord, hinforecord, mxrecord, txtrecord,
 rprecord, aaaarecord, locrecord, srvrecord, naptrrecord and
 modifytimestamp.</p>
 
 rprecord, aaaarecord, locrecord, srvrecord, naptrrecord and
 modifytimestamp.</p>
 

-<p>In Debian Edu/Lenny, the powerdns tree mode is used, and this is
+<p>In Debian Edu/Lenny, the PowerDNS tree mode is used, and this is

 two example LDAP objects used there.  In addition to these objects,
 the parent objects all th way up to
 ou=hosts,dc=skole,dc=skolelinux,dc=no also exist.</p>
 two example LDAP objects used there.  In addition to these objects,
 the parent objects all th way up to
 ou=hosts,dc=skole,dc=skolelinux,dc=no also exist.</p>


@@ -73,7 +74,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>


@@ -94,7 +97,7 @@ ldapsearch -h ldap -b dc=skole,dc=skolelinux,dc=no -s sub -x \
 search for SOA records, which behave similar to the forward and
 reverse lookups.</p>
 
 search for SOA records, which behave similar to the forward and
 reverse lookups.</p>
 

-<p>Things to note with the powerdns behaviour is that it do not
+<p>Things to note with the PowerDNS behaviour is that it do not

 specify any objectclass names, and instead look for the attributes it
 need to generate a DNS reply.  This make it able to work with any
 objectclass that provide the needed attributes.</p>
 specify any objectclass names, and instead look for the attributes it
 need to generate a DNS reply.  This make it able to work with any
 objectclass that provide the needed attributes.</p>


@@ -115,7 +118,7 @@ attributes combined with the domainrelatedobject object class, but in
 this case some unused attributes would have to be included as well
 (zonename and relativedomainname).</p>
 
 this case some unused attributes would have to be included as well
 (zonename and relativedomainname).</p>
 

-<p>My proposal would be to switch powerdns to strict mode and not use
+<p>My proposal would be to switch PowerDNS to strict mode and not use

 any of the existing objectclasses (dnsdomain, dnsdomain2 and dnszone)
 when one want to combine the DNS information with DHCP information,
 and instead use a auxiliary object class defined something like this
 any of the existing objectclasses (dnsdomain, dnsdomain2 and dnszone)
 when one want to combine the DNS information with DHCP information,
 and instead use a auxiliary object class defined something like this


@@ -135,11 +138,12 @@ objectclass ( some-oid NAME 'dnsDomainAux'
 </pre></blockquote>
 
 <p>This will allow any object to become a DNS entry when combined with
 </pre></blockquote>
 
 <p>This will allow any object to become a DNS entry when combined with

-the domainrelatedobject object class to get all the attributes
-powerdns wants.  I am not sure the 'SUP top' part is needed.</p>
+the domainrelatedobject object class, and allow any object to get all
+the attributes PowerDNS wants.  I've sent an email to the PowerDNS
+developers asking for their view on this schema and if they are
+interested in providing it with poewrdns.</p>

 
 

-ISC dhcp
-========
+<p><strong>ISC dhcp</strong></p>

 
 The DHCP server searches for specific objectclass and requests all the
 object attributes, and then uses the attributes it want.  This make it
 
 The DHCP server searches for specific objectclass and requests all the
 object attributes, and then uses the attributes it want.  This make it


@@ -180,6 +184,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 +196,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 +212,32 @@ 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
-==========
+<p><strong>Conclusion</strong></p>

 
 

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