On Mon, Jan 07, 2019 at 11:27:52PM +0000, Stuart Henderson wrote: > Thought I'd give an update on this since I just updated openldap. > Sorry not what you wanted but worth writing a few words: > > On 2018/05/22 12:46, Paul B. Henson wrote: > > Okay, how about: > > > > "The openldap port has been updated to use dynamically loaded modules > > rather than compile everything statically into a monolithic binary. To > > accommodate this change, you will need to update your configuration to > > include "modulepath /usr/local/libexec/openldap" as well as a moduleload > > for each module your configuration avails of. For example, if your > > configuration includes "database mdb", you will need to add a "moduleload > > back_mdb.so", or "moduleload back_bdb.so" for "database bdb", etc. if you > > are using replication, you will need "moduleload syncprov.so" and possibly > > "moduleload accesslog.so". Please see the documentation at > > http://www.openldap.org/doc/admin24/for additional details on configuring > > openldap." > > > > > The file is installed to ${PREFIX}/share/examples/openldap/slapd.conf, > > > that's the file where I'd add as an example. > > > > Actually, that file already includes: > > > > # Load dynamic backend modules: > > # modulepath /usr/local/libexec/openldap > > # moduleload back_mdb.la > > # moduleload back_ldap.la > > > > which the current port wouldn't even work with… Do you think that's > > sufficient, or that it needs a tuneup? > > > > > It might be worth @sample'ing > > > this file into ${SYSCONFDIR}/openldap as well, I think it was just an > > > oversight that this wasn't done before.. > > I remembered what this was about; it wasn't an oversight, rather upstream > strongly hinted that people should use OLC so it was deliberately removed to > nudge people in that direction. > > However...updating an OLC-based config when the daemon won't start is > quite the pain. > > I looked at switching the less used / less useful features into loadable > modules (and leaving the most common parts in the main binary), but even > then I didn't manage to get my production server starting up successfully > with the modular config. > > So I think at this point I will drop the diff unless a future update > means people will have to dump and redo config anyway - I think the amount > of pain for users to get through the update is sufficient that there would > have to be big advantages for it to be worthwhile, and I don't see that > there really are.
Iirc there were procedures to migrate from a slapd.conf to cn=config, i'll try to dig out what i had to do for $work. Migrating to modules has its advantages (not running unused code, etc..) Landry
