Openldap configuration does not allow to start daemon

[Pierre Labastie]

From ​http://lists.linuxfromscratch.org/pipermail/blfs-dev/2016-January/031480.html:

I tried to test the configuration for openldap as per the book, but the 
server fails to start. The reason was that the default configuration 
file (slapd.conf) defines mdb for the backend, but as the build was 
configured with modules (--enable-modules), a «moduleload back_mdb» 
statement should also be specified in this file.

There is a commented line #moduleload back_bdb in the default config 
file. Uncommenting this line and changing back_bdb to back_mdb does the 
job. The LDAP server starts and the given testing command succeeds.

[Pierre Labastie]

The proposed modification worked for me.

[Fernando de Oliveira]

For me too. Problem is that whoever did the page assumed that the configuration would be done by the user, because who needs openldap should know. That was what I did: learned after some research, because for me it is was necessary to update the book. So, I cannot understand that as a problem. But if you want to do that, go ahead. Whoever needs a different module surely will know how to do it.

[Fernando de Oliveira]

Interesting that the user who complained found the right configuration himself.

[Pierre Labastie]

There are a lot of pages where we give a basic configuration for a package. For openldap, we don't, but we give a test instruction, which does not work, because the configuration is not done yet. So there are two choices:

• remove the test instruction, and expect the user to find a configuration and test it
• keep the test instruction, and give enough information so that it works. It seems to me that any command written in the book should just work

I do not think that "who needs openldap should know". It is rather "who needs openldap should be able to learn". Nobody can know without learning. And the whole purpose of this book is to help learning... Sure, we are able to find the right configurations by consulting docs, and with some trials and errors: that's our "job" as book editors. Don't we do that just for saving people from reproducing the same steps?

[bdubbs@…]

I agree that we should have instructions that work. In some cases in the book we give some fairly extensive instructions, many times just embedded into scripts.

Many of the packages in the book have entire books written about them. Looking at my bookshelf I have (from LFS) bash, sed and awk, perl, vim, make, autotools, c++, and c.

from BLFS: Postfix, Apache, Sendmail, XSL, gimp, TeX, emacs, mysql, docbook, git, mercurial, ssh, bind, nfs, python, java, javascript, and ldap (plus others).

My point is that we can't really do justice to a package in one page. We can only do a sanity check that a complex package works in simple cases.

[Pierre Labastie]

Learning (slowly, I am rather busy with other stuff) about this package, I realize that the modern way of configuring openldap is not through splad.conf, but through slapd-config. See ​http://www.openldap.org/doc/admin24/slapdconf2.html It seems that the slapd.diff file shipped by default has the same problem as the default slapd.conf: mismatch between loaded module and used database. The first thing I have to do is to check whether it is fixed in 2.4.4. I think also it would be better not to copy the default slapd.conf.

[Pierre Labastie]

I understand now that the slapd.conf file is modified by the patch. So it is easy to rediff against a working version (as suggested in the post above). Also 2.4.44 has actually a working version using mdb, provided module loading is commented out. OTOH, the slapd.ldif file has to be patched (when using slapd-config), which is not done in the current patch. So I'll rediff and add this file. But I have to test first that it works. I still have some doubt about slapd-config.

[Pierre Labastie]

One thing I am not sure about: the default configuration file shipped with the package sets a password for user "Manager", which is commented out by the patch. The result of the patch is that nobody is allowed to connect to the ldap server. OTOH, if you are on a test machine, there is no security threat if the password is left uncommented, because external connexions are impossible with the default configuration. PHP and libreoffice tests rely on the default password. So I am inclined to leave the password as set by upstream, and add a few comments in the "Configuration" section.

[Pierre Labastie]

Fixed at r17013