Re: [RFC] OpenLDAP automatic upgrade
Torsten Landschoff <firstname.lastname@example.org> writes:
> Hi there,
First to introduce myself:
I currently maintain Stanford University's directory service, which is
based on OpenLDAP. I also am a member of the OpenLDAP core team, and I
hold down another job with Symas Corporation doing a variety of tasks, but
most relevantly benchmarking their OpenLDAP based product and teaching
classes on running and configuring OpenLDAP based directory services.
I have some comments on your upgrade plans listed here... ;)
> ad d) fix_ldif is a script that tries to fix some errors in the LDAP
> data that are not noticed by OpenLDAP 2.0 but get detected by newer
> OpenLDAP breaking the slapadd. Problem is: It reads the LDIF into
> memory. Try that with 1GB of data...
Going from OpenLDAP 2.0 to 2.1 was non-trivial. Going from 2.0 to 2.2 is
very complex. Going from 2.1 to 2.2 is also non-trivial.
Some issues to consider for the 2.1 to 2.2 process:
1) OpenLDAP 2.1 generally used BDB 4.1. OpenLDAP 2.2 should only be used
with BDB 4.2.52+patches when using bdb or hdb as the backend (Ignore the
documentation with OpenLDAP 2.2.23 stating it requires BDB 4.3, that
statement is incorrect).
2) Several changes were made to how ACL's were handled between OpenLDAP
2.1 and OpenLDAP 2.2. You cannot simply upgrade the database and expect
everything to work. The ACL's must also be reviewed and correctly
3) OpenLDAP bdb/hdb based databases are highly dependent on a well
configured DB_CONFIG file for the particular database in question. Simply
doing a slapcat/slapadd is really not sufficient for ensuring that the
resulting directory server will run well. A poorly configured
DB_CONFIG file can lead to the slapadd process taking hours or days. In
addition, there are two flags that should be set in the DB_CONFIG file
before the slapadd takes place, that should then be commented out once the
add is completed.
4) If someone is using ldbm as their backend database, I'd throw a warning
noting that bdb/hdb are the preferred backends of OpenLDAP. ldbm is rife
with issues such as not catching data inconsistencies, leading to poor
directory performance and potential data loss.
5) I don't know what version of OpenLDAP 2.2 that debian is considering
for inclusion, but I wouldn't go with anything less than OpenLDAP 2.2.23
based on my experiences.
Essentially, the process of upgrading a directory service to OpenLDAP 2.2
is generally something that should be done by the person who runs the
service. There are a host of issues that must be addressed to properly
Principal Software Developer
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html