the code can be restructured to make sure the variables are passed on.
I expect that can be solved with some testing. :)</p>
+<p>If you want to help out with implementing this for Debian Edu,
+please contact us on debian-edu@lists.debian.org.</p>
+</description>
+ </item>
+
+ <item>
+ <title>Combining PowerDNS and ISC DHCP LDAP objects</title>
+ <link>http://people.skolelinux.org/pere/blog/Combining_PowerDNS_and_ISC_DHCP_LDAP_objects.html</link>
+ <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Combining_PowerDNS_and_ISC_DHCP_LDAP_objects.html</guid>
+ <pubDate>Wed, 14 Jul 2010 23:45:00 +0200</pubDate>
+ <description>
+<p>For a while now, I have wanted to find a way to change the DNS and
+DHCP services in Debian Edu to use the same LDAP objects for a given
+computer, to avoid the possibility of having a inconsistent state for
+a computer in LDAP (as in DHCP but no DNS entry or the other way
+around) and make it easier to add computers to LDAP.</p>
+
+<p>I've looked at how powerdns and dhcpd is using LDAP, and using this
+information finally found a solution that seem to work.</p>
+
+<p>The old setup required three LDAP objects for a given computer.
+One forward DNS entry, one reverse DNS entry and one DHCP entry. If
+we switch powerdns to use its strict LDAP method (ldap-method=strict
+in pdns-debian-edu.conf), the forward and reverse DNS entries are
+merged into one while making it impossible to transfer the reverse map
+to a slave DNS server.</p>
+
+<p>If we also replace the object class used to get the DNS related
+attributes to one allowing these attributes to be combined with the
+dhcphost object class, we can merge the DNS and DHCP entries into one.
+I've written such object class in the dnsdomainaux.schema file (need
+proper OIDs, but that is a minor issue), and tested the setup. It
+seem to work.</p>
+
+<p>With this test setup in place, we can get away with one LDAP object
+for both DNS and DHCP, and even the LTSP configuration I suggested in
+an earlier email. The combined LDAP object will look something like
+this:</p>
+
+<blockquote><pre>
+ dn: cn=hostname,cn=group1,cn=THINCLIENTS,cn=DHCP Config,dc=skole,dc=skolelinux,dc=no
+ cn: hostname
+ objectClass: dhcphost
+ objectclass: domainrelatedobject
+ objectclass: dnsdomainaux
+ associateddomain: hostname.intern
+ arecord: 10.11.12.13
+ dhcphwaddress: ethernet 00:00:00:00:00:00
+ dhcpstatements: fixed-address hostname
+ ldapconfigsound: Y
+</pre></blockquote>
+
+<p>The DNS server uses the associateddomain and arecord entries, while
+the DHCP server uses the dhcphwaddress and dhcpstatements entries
+before asking DNS to resolve the fixed-adddress. LTSP will use
+dhcphwaddress or associateddomain and the ldapconfig* attributes.</p>
+
+<p>I am not yet sure if I can get the DHCP server to look for its
+dhcphost in a different location, to allow us to put the objects
+outside the "DHCP Config" subtree, but hope to figure out a way to do
+that. If I can't figure out a way to do that, we can still get rid of
+the hosts subtree and move all its content into the DHCP Config tree
+(which probably should be renamed to be more related to the new
+content. I suspect cn=dnsdhcp,ou=services or something like that
+might be a good place to put it.</p>
+
<p>If you want to help out with implementing this for Debian Edu,
please contact us on debian-edu@lists.debian.org.</p>
</description>
projects / homepage.git / blobdiff