Migrating some of the main services configuration from plain text files to a LDAP backend.

(This is a skeleton to get some initial ideas and resources. Much work and decissions have to be done)

Configs that might be moved:


There are two real possible aproaches:

Implementing dhcp3-server-ldap

These steps supposse that:

At the dhcp server:

  1. Install the package dhcp3-server-ldap from Debian lenny or sid.
  2. To get the ldif with the dhcp information:
    •  dhcpd-conf-to-ldap.pl  --basedn "dc=instituto,dc=extremadura,dc=es" \
       --dhcpdn "cn=DHCP Config, dc=instituto,dc=extremadura,dc=es" \
       --conf "/etc/dhcp3/dhcpd.conf" >dhcpd.ldif  
  3. Change dhcpd configuration, so the /etc/dhcp3/dhcpd.conf file should be like this:
    • ldap-server "";
      ldap-port 389;
      ldap-base-dn  "dc=instituto,dc=extremadura,dc=es";
      ldap-debug-file "/var/log/dhcp-ldap-startup.log";
      ldap-dhcp-server-cn "aula1-pro";
      ldap-method dynamic;
      ddns-update-style none;


At the ldap server:

  1. Bring from the dhcp server the dhcpd.ldif file from the step 1 above and the file /usr/share/doc/dhcp3-server-ldap/dhcp.schema.gz
  2. Gunzip dhcp.schema.gz and copy it to /etc/ldap/schema/
  3. Edit /etc/ldap/ldap.conf and add these lines:
    • include         /etc/ldap/schema/dhcp.schema
      index           dhcpHWAddress   eq
      index           dhcpClassData   eq
  4. Import dhcpd.ldif into ldap tree using your favourite application (gq, phpldapadmin, ldapadd, etc.)
  5. Reindex and restart ldap server:
    •  slapindex & /etc/init.d/slapd restart  

Now restart dhcpd server and take a look at "/var/log/dhcp-ldap-startup.log". If everything goes fine, the old dhcpd.config file should be there, but extracted from ldap, and dhcp should be working.


Alternatives: powerdns(pdns-backend-ldap) ldapdns ldap2dns ldap2zone


a tool that generates zone files out of ldap data, contains it's own schema called dns.schema


The currently most advanced aproximation is using PowerDNS with a ldap backend. Packages are available in Debian to implement it.

powerdns's best advantage is that it uses ldap directly. That means that there is no need for cronjobs and scripts to convert ldap data into config files, before reloading services.

schema requirements. the standard cosine.schema (allready in our config) implements most dns requirements. The exception beeing PTR records that are needed for revers lookups. In order to support the PTR record, one must add the dnsdomain2.schema included in the pdns-backend-ldap package.

implementing powerdns

In order to test powerdns on your own installation you can follow these instructions.

  1. backup your bind configuration
    •  tar -czvf /skole/backup/bind.tgz /etc/bind  /var/cache/bind 

  2. install the powerdns packages.
    •  aptitude  install pdns-backend-ldap pdns-doc pdns-recursor pdns-server 

  3. Write the powerdns configuration
    • Add this as the file  etc/powerdns/pdns.d/pdns-debian-edu.conf 

      # LDAP server configuration
      # Do not use a hostname here, unless you also add that name to the /etc/hosts file.
      #start the ldap backend on boot.
      #ACL that allow recursion from this server, and the network.
      #Only recurse if question cannot be answered locally
      #IP Addresses of recursive nameservers, eg your ISP's servers. This example uses the pdns-recursor running localy on a custom port.
  4. Configure pdns-recursor to run on a custom port.
    • Edit the file  /etc/powerdns/recursor.conf  and edit so it contains the line  local-port=1553 

  5. add a needed ldap schema to your openLDAP configuration.
    • Add the line
      include         /etc/ldap/schema/dnsdomain2.schema

      in the file  /etc/ldap/slapd.conf  under # Schema and objectClass definitions

  6. restart slapd
  7. create ldif files from bind configuration. Take notice that this creates a identical copy of your dns setting from your bind config. One of the reasons one might want to keep configurations in ldap is to reduce clutter, And only have the hosts one actualy needs, in the zone. I imagine that the new default zone file would be empty , except for the services aliases. And that the zone would be populated when one starts to add hosts in the admin tool.
    •  zone2ldap --basedn=ou=hosts,dc=skole,dc=skolelinux,dc=no --layout=tree  --zone-file=/etc/bind/debian-edu/db.intern  --zone-name=intern > dns-intern.ldif 

... FIXME: add more about migration ...

  1. add the ldif's to the openldap server using  ldapadd -c -Z -f your-ldif-file-here.ldif -x -D 'cn=admin,ou=People,dc=skole,dc=skolelinux,dc=no'  -W -h 

    • FIXME: You may (or may not) have to create the ou=hosts container first.
  2. restart the pdns-recursor, and verify it's running on port 1553.
  3. restart pdns

For cd-lenny-test-dvd/debian-edu-amd64-i386-DVD-1.iso Build 2009-04-13T11:44 powerdns is installed but I must additional add the public ldap key with:

cd /etc/ldap/ssl/
openssl req -new -x509 -days 3650 -key slapd.pem -out ldap-server-pubkey.pem  

Start of ldif files made by hand for skolelinux with powerdns.

dn: ou=hosts,dc=skole,dc=skolelinux,dc=no
objectClass: organizationalUnit
objectClass: domainRelatedObject
ou: hosts
associatedDomain: intern

dn: dc=intern,ou=hosts,dc=skole,dc=skolelinux,dc=no
objectclass: top
objectclass: dcobject
objectclass: dnsdomain
objectclass: domainrelatedobject
dc: intern
soarecord: ns.intern root@intern 1 1800 3600 86400 7200
nsrecord: ns.intern
mxrecord: 10 mail.intern
associateddomain: intern

dn: dc=tjener,dc=intern,ou=hosts,dc=skole,dc=skolelinux,dc=no
objectclass: top
objectclass: dnsdomain
objectclass: domainrelatedobject
dc: tjener
associateddomain: tjener.intern

dn: dc=gateway,dc=intern,ou=hosts,dc=skole,dc=skolelinux,dc=no
objectclass: top
objectclass: dnsdomain
objectclass: domainrelatedobject
dc: gateway
associateddomain: gateway.intern

dn: dc=ldap,dc=intern,ou=hosts,dc=skole,dc=skolelinux,dc=no
objectclass: top
objectclass: dnsdomain
objectclass: domainrelatedobject
dc: ldap
cnamerecord: tjener.intern
associateddomain: ldap.intern

dn: dc=www,dc=intern,ou=hosts,dc=skole,dc=skolelinux,dc=no
objectclass: top
objectclass: dnsdomain
objectclass: domainrelatedobject
dc: www

And the reverse file:

dn: dc=arpa,ou=hosts,dc=skole,dc=skolelinux,dc=no
objectclass: top
objectclass: dnsdomain2
objectclass: domainrelatedobject
dc: arpa
associateddomain: arpa

dn: dc=in-addr,dc=arpa,ou=hosts,dc=skole,dc=skolelinux,dc=no
objectclass: top
objectclass: dnsdomain2
objectclass: domainrelatedobject
dc: in-addr
associateddomain: in-addr.arpa

dn: dc=10,dc=in-addr,dc=arpa,ou=hosts,dc=skole,dc=skolelinux,dc=no
objectclass: top
objectclass: dnsdomain2
objectclass: domainrelatedobject
dc: 10
associateddomain: 10.in-addr.arpa

dn: dc=0,dc=10,dc=in-addr,dc=arpa,ou=hosts,dc=skole,dc=skolelinux,dc=no
objectclass: top
objectclass: dnsdomain2
objectclass: domainrelatedobject
dc: 0
associateddomain: 0.10.in-addr.arpa

dn: 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
associateddomain: 2.0.10.in-addr.arpa

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

dn: dc=1,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: 1
ptrrecord: gateway.intern


Fetching LTSP client config from ldap. allows for LTSP server clusters. There are some vague ideas and old implementations available:

motivation / why?

Why are you doing this ? LDAP makes sense for user-accounts - I agree. But why did you put dhcpd.conf into LDAP ? One thing I love about UNIX & Linux are the plaintext configuration files: easy to read and easy to edit. LDAP is like the Windows registry: a binary database, you need tools to edit it. Changing settings becomes very hard. With SSL/TS even more harder. :-(

To permit to be able create web interfaces to delegate to non technical peoples do some tasks. To improve availability and maintenance, because data will be stored in centered way.