Hi Quanah, On Tue, Mar 15, 2005 at 01:07:29PM -0800, Quanah Gibson-Mount wrote: > 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. Whew! > I have some comments on your upgrade plans listed here... ;) Great, fire! :) > 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. Talk about stating the obvious ;) > 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). Yes, I accidently built it with BDB 4.2 and it worked. But - what is the problem with 4.3? And what patches will be needed for 4.2.52 - it's not like I can go and change the libdb4.2 packages, I'll have to ask the maintainer for that favour. > 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. Surely. For simple installations it might work without that though and not every slapd package is installed to run the Stanford directory server. :) > 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. Erm, the upgrading process is already really complex, and I fear I don't feel like implementing this in maintainer scripts. Which options are you thinking of, BTW? And the documentation for DB_CONFIG is really lacking as well, let's hope somebody wakes up the sleepy cats ;) I wonder why the OpenLDAP server can not tune most of the BDB parameters itself during runtime. It has by far more information at its hands than the Debian maintainer scripts have. > 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. Where is the difference to bdb? ;-) > 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. That's what I am working on. > 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. That's for sure but I want to be able to do automatic upgrades for the simple cases. And at least help the admin by dumping the directory before starting the upgrade and taking care of the old database files in case he decides to downgrade again later :) Thanks for your comments Torsten
Attachment:
signature.asc
Description: Digital signature