Second corruption in one day. Trying to add module using ldif

dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModulePath: /usr/lib64/openldap/
olcModuleLoad: slapd-sha2.so

As it was not working correctly I tried to remove this module. This is not implemented!!! You can delete a module once it is added.

I created a backup file of this config file. When manual edit failed, I moved the backup file back in. This is the result
[user@server cn=config]# service slapd configtest
Checking configuration files for slapd:                    [FAILED]
54758693 ldif_read_file: Permission denied for "/etc/openldap/slapd.d/cn=config/cn=module{0}.ldif"
slaptest: bad configuration file!

This happened after I already did complete remove and install of OpenLDAP. 

So OpenLDAP does perform world class checking of manual edits rendering instances useless when config files are changed. It is a lot more permissive accepting config changes through the official interface even accepting changes that corrupt the instance. 

I know I can use other directory servers. But I also think that the OpenLDAP community should not claim to offer good encryption of password when out-of-the-bot you get NO encryption and you have to first become an OpenLDAP core developer to get this good encryption.  






On Wed, Nov 26, 2014 at 6:43 AM, Onno van der Straaten <onno.van.der.straaten@gmail.com> wrote:
What was created with OpenLDAP is incredible. Truly.

Experienced with open source but never seen before a system that is so archaic. Amazing. The way that configuration works is something that has to be seen and experienced to be believed.

There must be strong commercial interest served here to create a system that works in this manner. It allows for configuration changes that corrupt the installation but will now allow manual correction of the configuration. 

Chicken and egg. To correct the configuration you have start OpenLDAP and ldapmodify the config files. But.... OpenLDAP will not start because the configuration is not correct. Really funny. And if you try to manually undo your changes, OpenLDAP will completely refuse to put itself into something that resembles a working configuration.

It is fairly easy to make configuration changes that corrupt the database. Documentation is often incorrect or non-existing. For example try to add sha2 support. Accidentally add non existing hash method will create a corrupt configuration. If you slapd restart it will fail to start. To correct the configuration you need to start slapd. To start slapd you need correct configuration. It is the end of your efforts.

I'm not doing this on a production system of course, I am trying to create a production system where OpenLDAP is on of the many components. So far most of the effort is OpenLDAP effort. It is consuming most of the project budget. A project of a couple of days turns into a project for a couple of weeks.

We just need a LDAP user directory. OpenLDAP is not it.