Torsten Landschoff <[EMAIL PROTECTED]> writes: > Hi there,
Hi Torsten, 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 updated. 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 upgrade. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITSS/Shared Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]