This is a -followup -on my -previous -work on -merging -all the computer related LDAP objects in Debian Edu.
- -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.
- -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. - -powerdns
- -Clues -on how to set up PowerDNS to use a LDAP backend is available on -the web. - -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.
- -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:
- -- --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 -
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.
- -- --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 -
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.
- -The forward and reverse searches can be simulated using ldapsearch -like this:
- -- --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 -
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.
- -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.
- -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.
- -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.
- -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).
- -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):
- -- --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 - )) -
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.
- -ISC dhcp
- -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.
- -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:
- -- --ldap-base-dn "dc=skole,dc=skolelinux,dc=no"; -ldap-dhcp-server-cn "dhcp"; -
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:
- -- --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 -
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:
- -- --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 -
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.
- -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:
- -- --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 -
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. - -
Conclusion
- -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.
- -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.
- -Based on the observed behaviour, I suspect a LDAP structure like -this might work for Debian Edu:
- -- --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) -
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.
- -The combined object under the machines subtree would look something -like this:
- -- -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. +-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 -
For ca. et og et halvt år siden +startet +jeg på et kart over overvåkningskamera i Norge, i regi av +personvernforeningen. Det har +blitt oppdatert regelmessing, og jeg oppdaterte det nettopp. Fra den +spede start med 22 kamera registrert er det nå registrert 54 kamera. +Det er bare en brøkdel av de kamera som finnes i Norge, men det går +sakte men sikkert i riktig retning.
+ +Informasjonen registreres fortsatt direkte inn i +OpenStreetmap, og hentes +automatisk over i + +når jeg kjører et script for å filtrere ut overvåkningskamera fra +OSM-dumpen for Norge.