Creating root suffixes with 389org

Creating a simple root suffix with 389org consist in 3 passages:

  1. create a backend database where to save our data;
  2. create a root suffix pointing to the new db;
  3. create the ldap entry associated to the root suffix.

These steps are executed by the following ldif.


# create an LDBM database named AddressbookDb
# eventually setting cache to 2G
dn: cn=AddressbookDb,cn=ldbm database,cn=plugins,cn=config
objectclass: extensibleObject
objectclass: nsBackendInstance
nsslapd-cachememsize: 2048576000
nsslapd-suffix: o=db8

# associate the database with an ldap entry
dn: cn="o=db8",cn=mapping tree,cn=config
objectclass: top
objectclass: extensibleObject
objectclass: nsMappingTree
nsslapd-state: backend
nsslapd-backend: Addressbookdb8
cn: "o=db8"

# create the ldap entry
dn: o=db8
objectclass: top
objectclass: organization
o: db8

now you can issue a successful
# ldapsearch -x -b “o=db8” -s base -LLL

You can even create a local database which refers to other servers
for update

# replace state: backend -> state: referral on update
# and point to your referrals
dn: cn="o=db7",cn=mapping tree,cn=config
objectclass: top
objectclass: extensibleObject
objectclass: nsMappingTree
nsslapd-state: referral on update
nsslapd-backend: Addressbookdb7
nsslapd-referral: ldap://ab1.example.com:389/o%3Ddb7
nsslapd-referral: ldap://ab2.example.com:389/o%3Ddb7

389org on Sabayon

Babel sponsored a Fedora DS release for Sabayon/Gentoo. The work has been done by the Sabayon maintainer lxnay with my support: we involved richm aka Mr. Fedora DS.

This work lead us to discover some issues on the server:

1. the AdminServer – using mod_cgi – plays the dup2/close game to close stdfd: this caused an error on Sabayon but not on Fedora.

  • We discovered that, even if Admin Server requires Apache2 mpm  (multithread), the Fedora  mod_cgi was build using prefork (single-threaded)
  • On Sabayon, like Gentoo,  you have to compile from scratch all packages, so you’re not supposed to mix prefork/mpm, and the mod_cgi was compiled in a multithread environment.
  • obviousily the dup2/close game won’t fit on multithread environment, because will close the fds of the main process (and not the child’s one)
  • further info on http://www.spinics.net/lists/fedora-directory/msg11697.html
2. the 389org schema files dropped the ldap aliases: we filed a bug and now they’re recovering them.