X-Git-Url: https://pere.pagekite.me/gitweb/homepage.git/blobdiff_plain/2c7e6dbb7cb348e14cc31b640e20b06e962ee4a7..fdfb9c799694f76a85fd72974be752d18b1f123c:/blog/index.rss diff --git a/blog/index.rss b/blog/index.rss index bcb8a035c6..88171b0599 100644 --- a/blog/index.rss +++ b/blog/index.rss @@ -6,6 +6,326 @@ http://people.skolelinux.org/pere/blog/ + + What are they searching for - PowerDNS and ISC DHCP in LDAP + http://people.skolelinux.org/pere/blog/What_are_they_searching_for___PowerDNS_and_ISC_DHCP_in_LDAP.html + http://people.skolelinux.org/pere/blog/What_are_they_searching_for___PowerDNS_and_ISC_DHCP_in_LDAP.html + Sat, 17 Jul 2010 21:00:00 +0200 + +<p>This is a +<a href="http://people.skolelinux.org/pere/blog/Time_for_new__LDAP_schemas_replacing_RFC_2307_.html">followup</a> +on my +<a href="http://people.skolelinux.org/pere/blog/Idea_for_a_change_to_LDAP_schemas_allowing_DNS_and_DHCP_info_to_be_combined_into_one_object.html">previous +work</a> on +<a href="http://people.skolelinux.org/pere/blog/Combining_PowerDNS_and_ISC_DHCP_LDAP_objects.html">merging +all</a> the computer related LDAP objects in Debian Edu.</p> + +<p>As a step to try to see if it possible to merge the DNS and DHCP +LDAP objects, I have had a look at how the packages pdns-backend-ldap +and dhcp3-server-ldap in Debian use the LDAP server. The two +implementations are quite different in how they use LDAP.</p> + +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. + +<p><strong>powerdns</strong></p> + +<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. +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 +based on the DNS names, as in tjener.intern and +2.2.0.10.in-addr.arpa.</p> + +<p>In tree mode, the server is set up to use a LDAP subtree as its +base, and uses a "base" scoped search for the DNS name by adding +"dc=tjener,dc=intern," to the base with a filter for +"(associateddomain=tjener.intern)" for the forward entry and +"dc=2,dc=2,dc=0,dc=10,dc=in-addr,dc=arpa," with a filter for +"(associateddomain=2.2.0.10.in-addr.arpa)" for the reverse entry. For +forward entries, it is looking for attributes named dnsttl, arecord, +nsrecord, cnamerecord, soarecord, ptrrecord, hinforecord, mxrecord, +txtrecord, rprecord, afsdbrecord, keyrecord, aaaarecord, locrecord, +srvrecord, naptrrecord, kxrecord, certrecord, dsrecord, sshfprecord, +ipseckeyrecord, rrsigrecord, nsecrecord, dnskeyrecord, dhcidrecord, +spfrecord and modifytimestamp. For reverse entries it is looking for +the attributes dnsttl, arecord, nsrecord, cnamerecord, soarecord, +ptrrecord, hinforecord, mxrecord, txtrecord, rprecord, aaaarecord, +locrecord, srvrecord, naptrrecord and modifytimestamp. The equivalent +ldapsearch commands could look like this:</p> + +<blockquote><pre> +ldapsearch -h ldap \ + -b dc=tjener,dc=intern,ou=hosts,dc=skole,dc=skolelinux,dc=no \ + -s base -x '(associateddomain=tjener.intern)' dNSTTL aRecord nSRecord \ + cNAMERecord sOARecord pTRRecord hInfoRecord mXRecord tXTRecord \ + rPRecord aFSDBRecord KeyRecord aAAARecord lOCRecord sRVRecord \ + nAPTRRecord kXRecord certRecord dSRecord sSHFPRecord iPSecKeyRecord \ + rRSIGRecord nSECRecord dNSKeyRecord dHCIDRecord sPFRecord modifyTimestamp + +ldapsearch -h ldap \ + -b dc=2,dc=2,dc=0,dc=10,dc=in-addr,dc=arpa,ou=hosts,dc=skole,dc=skolelinux,dc=no \ + -s base -x '(associateddomain=2.2.0.10.in-addr.arpa)' + dnsttl, arecord, nsrecord, cnamerecord soarecord ptrrecord \ + hinforecord mxrecord txtrecord rprecord aaaarecord locrecord \ + srvrecord naptrrecord modifytimestamp +</pre></blockquote> + +<p>In Debian Edu/Lenny, the PowerDNS tree mode is used with +ou=hosts,dc=skole,dc=skolelinux,dc=no as the base, and these are 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> + +<blockquote><pre> +dn: dc=tjener,dc=intern,ou=hosts,dc=skole,dc=skolelinux,dc=no +objectclass: top +objectclass: dnsdomain +objectclass: domainrelatedobject +dc: tjener +arecord: 10.0.2.2 +associateddomain: tjener.intern + +dn: dc=2,dc=2,dc=0,dc=10,dc=in-addr,dc=arpa,ou=hosts,dc=skole,dc=skolelinux,dc=no +objectclass: top +objectclass: dnsdomain2 +objectclass: domainrelatedobject +dc: 2 +ptrrecord: tjener.intern +associateddomain: 2.2.0.10.in-addr.arpa +</pre></blockquote> + +<p>In strict mode, the server behaves differently. When looking for +forward DNS entries, it is doing a "subtree" scoped search with the +same base as in the tree mode for a object with filter +"(associateddomain=tjener.intern)" and requests the attributes dnsttl, +arecord, nsrecord, cnamerecord, soarecord, ptrrecord, hinforecord, +mxrecord, txtrecord, rprecord, aaaarecord, locrecord, srvrecord, +naptrrecord and modifytimestamp. For reverse entires it also do a +subtree scoped search but this time the filter is "(arecord=10.0.2.2)" +and the requested attributes are associateddomain, 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> + +<blockquote><pre> +ldapsearch -h ldap -b ou=hosts,dc=skole,dc=skolelinux,dc=no -s sub -x \ + '(associateddomain=tjener.intern)' dNSTTL aRecord nSRecord \ + cNAMERecord sOARecord pTRRecord hInfoRecord mXRecord tXTRecord \ + rPRecord aFSDBRecord KeyRecord aAAARecord lOCRecord sRVRecord \ + nAPTRRecord kXRecord certRecord dSRecord sSHFPRecord iPSecKeyRecord \ + rRSIGRecord nSECRecord dNSKeyRecord dHCIDRecord sPFRecord modifyTimestamp + +ldapsearch -h ldap -b ou=hosts,dc=skole,dc=skolelinux,dc=no -s sub -x \ + '(arecord=10.0.2.2)' associateddomain dnsttl modifytimestamp +</pre></blockquote> + +<p>In addition to the forward and reverse searches , there is also a +search for SOA records, which behave similar to the forward and +reverse lookups.</p> + +<p>A thing 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> + +<p>The attributes are normally provided in the cosine (RFC 1274) and +dnsdomain2 schemas. The latter is used for reverse entries like +ptrrecord and recent DNS additions like aaaarecord and srvrecord.</p> + +<p>In Debian Edu, we have created DNS objects using the object classes +dcobject (for dc), dnsdomain or dnsdomain2 (structural, for the DNS +attributes) and domainrelatedobject (for associatedDomain). The use +of structural object classes make it impossible to combine these +classes with the object classes used by DHCP.</p> + +<p>There are other schemas that could be used too, for example the +dnszone structural object class used by Gosa and bind-sdb for the DNS +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> + +<p>My proposal for Debian Edu 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 create a auxiliary object class +defined something like this (using the attributes defined for +dnsdomain and dnsdomain2 or dnszone):</p> + +<blockquote><pre> +objectclass ( some-oid NAME 'dnsDomainAux' + SUP top + AUXILIARY + MAY ( ARecord $ MDRecord $ MXRecord $ NSRecord $ SOARecord $ CNAMERecord $ + DNSTTL $ DNSClass $ PTRRecord $ HINFORecord $ MINFORecord $ + TXTRecord $ SIGRecord $ KEYRecord $ AAAARecord $ LOCRecord $ + NXTRecord $ SRVRecord $ NAPTRRecord $ KXRecord $ CERTRecord $ + A6Record $ DNAMERecord + )) +</pre></blockquote> + +<p>This will allow any object to become a DNS entry when combined with +the domainrelatedobject object class, and allow any entity to include +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 such schema with PowerDNS, and I hope my +message will be accepted into their mailing list soon.</p> + +<p><strong>ISC dhcp</strong></p> + +<p>The DHCP server searches for specific objectclass and requests all +the object attributes, and then uses the attributes it want. This +make it harder to figure out exactly what attributes are used, but +thanks to the working example in Debian Edu I can at least get an idea +what is needed without having to read the source code.</p> + +<p>In the DHCP server configuration, the LDAP base to use and the +search filter to use to locate the correct dhcpServer entity is +stored. These are the relevant entries from +/etc/dhcp3/dhcpd.conf:</p> + +<blockquote><pre> +ldap-base-dn "dc=skole,dc=skolelinux,dc=no"; +ldap-dhcp-server-cn "dhcp"; +</pre></blockquote> + +<p>The DHCP server uses this information to nest all the DHCP +configuration it need. The cn "dhcp" is located using the given LDAP +base and the filter "(&(objectClass=dhcpServer)(cn=dhcp))". The +search result is this entry:</p> + +<blockquote><pre> +dn: cn=dhcp,dc=skole,dc=skolelinux,dc=no +cn: dhcp +objectClass: top +objectClass: dhcpServer +dhcpServiceDN: cn=DHCP Config,dc=skole,dc=skolelinux,dc=no +</pre></blockquote> + +<p>The content of the dhcpServiceDN attribute is next used to locate the +subtree with DHCP configuration. The DHCP configuration subtree base +is located using a base scope search with base "cn=DHCP +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:</p> + +<blockquote><pre> +dn: cn=DHCP Config,dc=skole,dc=skolelinux,dc=no +cn: DHCP Config +objectClass: top +objectClass: dhcpService +objectClass: dhcpOptions +dhcpPrimaryDN: cn=dhcp, dc=skole,dc=skolelinux,dc=no +dhcpStatements: ddns-update-style none +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 +</pre></blockquote> + +<p>Next, the entire subtree is processed, one level at the time. When +all the DHCP configuration is loaded, it is ready to receive requests. +The subtree in Debian Edu contain objects with object classes +top/dhcpService/dhcpOptions, top/dhcpSharedNetwork/dhcpOptions, +top/dhcpSubnet, top/dhcpGroup and top/dhcpHost. These provide options +and information about netmasks, dynamic range etc. Leaving out the +details here because it is not relevant for the focus of my +investigation, which is to see if it is possible to merge dns and dhcp +related computer objects.</p> + +<p>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. This is what a host object look +like:</p> + +<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> + +<p>There is less flexiblity in the way LDAP searches are done here. +The object classes need to have fixed names, and the configuration +need to be stored in a fairly specific LDAP structure. On the +positive side, the invidiual dhcpHost entires can be anywhere without +the DN pointed to by the dhcpServer entries. The latter should make +it possible to group all host entries in a subtree next to the +configuration entries, and this subtree can also be shared with the +DNS server if the schema proposed above is combined with the dhcpHost +structural object class. + +<p><strong>Conclusion</strong></p> + +<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 +in the configuration.</p> + +<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 +structure.</p> + +<p>Based on the observed behaviour, I suspect a LDAP structure like +this might work for Debian Edu:</p> + +<blockquote><pre> +ou=services + cn=machine-info (dhcpService) - dhcpServiceDN points here + cn=dhcp (dhcpServer) + cn=dhcp-internal (dhcpSharedNetwork/dhcpOptions) + cn=10.0.2.0 (dhcpSubnet) + cn=group1 (dhcpGroup/dhcpOptions) + cn=dhcp-thinclients (dhcpSharedNetwork/dhcpOptions) + cn=192.168.0.0 (dhcpSubnet) + cn=group1 (dhcpGroup/dhcpOptions) + ou=machines - PowerDNS base points here + cn=hostname (dhcpHost/domainrelatedobject/dnsDomainAux) +</pre></blockquote> + +<P>This is not tested yet. If the DHCP server require the dhcpHost +entries to be in the dhcpGroup subtrees, the entries can be stored +there instead of a common machines subtree, and the PowerDNS base +would have to be moved one level up to the machine-info subtree.</p> + +<p>The combined object under the machines subtree would look something +like this:</p> + +<blockquote><pre> +dn: dc=hostname,ou=machines,cn=machine-info,dc=skole,dc=skolelinux,dc=no +dc: hostname +objectClass: top +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.intern +</pre></blockquote> + +</p>One could even add the LTSP configuration associated with a given +machine, as long as the required attributes are available in a +auxiliary object class.</p> + + + Combining PowerDNS and ISC DHCP LDAP objects http://people.skolelinux.org/pere/blog/Combining_PowerDNS_and_ISC_DHCP_LDAP_objects.html @@ -648,48 +968,5 @@ like this.</p> - - Vinmonopolet bryter loven åpenlyst - og flere planlegger å gjøre det samme - http://people.skolelinux.org/pere/blog/Vinmonopolet_bryter_loven___penlyst___og_flere_planlegger____gj__re_det_samme.html - http://people.skolelinux.org/pere/blog/Vinmonopolet_bryter_loven___penlyst___og_flere_planlegger____gj__re_det_samme.html - Wed, 16 Jun 2010 11:00:00 +0200 - -<p><a href="http://www.dagbladet.no/2010/06/16/nyheter/innenriks/streik/arbeidsliv/12157858/">Dagbladet -melder</a> at Vinmonopolet med bakgrunn i vekterstreiken som pågår i -Norge for tiden, har bestemt seg for med vitende og vilje å bryte -sentralbanklovens paragraf 14 ved å nekte folk å betale med -kontanter, og at flere butikker planlegger å følge deres eksempel. -Jeg synes det er hårreisende hvis de slipper unna med et slikt -soleklart lovbrudd, og lurer på hva slags muligheter jeg vil ha hvis -jeg blir nektet å handle med kontanter. Jeg handler i hovedsak med -kontanter selv, da jeg anser det som en borgerrett å kunne handle -anonymt uten at det blir registrert. For meg er det et angrep på mitt -personvern å nekte å ta imot kontant betaling.</p> - -<p><a href="http://www.lovdata.no/all/tl-19850524-028-003.html#14">Paragrafen -i sentralbankloven</a> lyder:</p> - -<blockquote> -<p>§ 14. Tvungent betalingsmiddel</p> - -<p>Bankens sedler og mynter er tvungent betalingsmiddel i Norge. Ingen -er pliktig til i én betaling å ta imot mer enn femogtyve mynter av -hver enhet.</p> - -<p>Sterkt skadde sedler og mynter er ikke tvungent -betalingsmiddel. Banken gir nærmere forskrifter om erstatning for -bortkomne, brente eller skadde sedler og mynter.</p> - -<p>Selv om en avtale inneholder klausul om betaling av en -pengeforpliktelse i gullverdi, kan skyldneren frigjøre seg med tvungne -betalingsmidler uten hensyn til denne klausul.</p> -</blockquote> - -<p>Det er med bakgrunn i denne lovet ikke tillatt å nekte å ta imot -kontakt betaling. Det er en lov jeg har sans for, og som jeg mener må -håndheves strengt.</p> - - -