Traditionally we have maintained a large stack of values in dse.ldif. This led to the creation of perl scripts for upgrades to be able to change these values. We also maintain many values in libglobs.c, and slap.h for the default configuration.
Overtime these have moved around a bit and have become inconsistent. There have been some odd behaviours.
The biggest challenge, is after you deploy an instance, how do you know what values came with DS? And what did I the admin change? This affects the ability to migrate servers easily, and means a large investment of time to analyse configs to determine what has been changed. Addtionally, it was hard for an admin to know if a value was default or not, and there was no way to reset to the default.
The goal is:
It turns out all the pieces to achieve the above are already in place in directory server. We could already delete values from cn=config if they were in the nsslapd-allowed-to-delete-attrs attribute. These values would come with a default value in libglobs.c, and it would be set when the MOD_DELETE took place. Most of the values in dse.ldif were just copied straight out of libglobs.c and slap.h.
All the values in libglobs.c and slap.h were centralised into slap.h.
Everything that came with a default, was corrected to have a default correctly setup with slapdFrontendConfig_t and config_get_and_set in libglobs.c.
A large number of values were identified that should not be allowed to be deleted or reset. These are marked with a default of NULL in libglobs.c.
Every value that was duplicated from slap.h to template-dse.ldif was removed from template-dse.ldif. This way the value in “slap.h” is used, and dse.ldif only contains site specific information.
Finally, remove the reliance on the nsslapd-allowed-to-delete attribute. If a value defines a proper default, it can be deleted.
Add a guide into libglobs.c about the details of the process, and how to add and manage configurations.
Test that deleting everysingle value in cn=config works, and the server can restart. This is now automated into the lib389 testing suite.
Look in dse.ldif
cn=config
...
nsslapd-maxthreads: 2
Start the server, and delete the value, and check it again.
cn=config
...
It’s missing from dse.ldif. Do an ldapsearch of cn=config while the server is running.
cn=config
...
nsslapd-maxthreads: 30
We have the default value from slap.h.
Provided that the value is not in dse.ldif we can now upgrade. Consider:
version 1.3.6: nunc-stans-enabled: on
So we ship with nunc-stans-enabled in this version. Say we find a bug in nunc-stans. When we push an update to directory server, we can change this:
version 1.3.6-1: nunc-stans-enabled: off
This would now disable nunc-stans for all instances, provided they have not explicitly enabled it.
Then for 1.3.7 we decide to enable nunc-stans again.
So the admin does a yum upgrade. This would result in:
version 1.3.7: nunc-stans-enabled: on
The admin isn’t happy, so they yum downgrade:
version 1.3.6-1: nunc-stans-enabled: off
No scripts or other intervention was needed to roll the setting back between the two versions.
These configurations include the default password storage scheme for the system password policy. We have chosen the scheme to be the most widely avaliable on all currently supported versions of Directory Server. This scheme will be upgraded like any other configuration as server requirements change, and older versions EOL. We hope to continually improve our password storage scheme through this function, without need for administrator intervention.
So to be explicit, as of 2017-02-15 we use SSHA512 for 1.3.x and 1.2.x as the “strongest hash on all supported platforms”. This way we do NOT introduce replication issues.
In a future date, if we find that 1.3.6 is the lowest supported version, we can lift this to PBKDF2.
wibrown at redhat.com