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 <
[email protected]> 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.
>
>
>
>
