On 2019/01/08 08:05, Landry Breuil wrote: > 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..)
Migrating from slapd.conf to OLC (cn=config) is easy. The problem is if you already have a running system with OLC then update to a version that requires config changes to be made (i.e. enable modules) in order for slapd to even start, you can't use the usual tools to edit the config. The usual approach then seems to be to go poking in "AUTO-GENERATED FILE - DO NOT EDIT" files with a fragile format, regenerate CRCs and hope that it works successfully, I'm not too happy about forcing users (including myself ;) through this just to avoid loading some code that isn't even run unless configured. Search for slapd.d in http://www.zytrax.com/books/ldap/ch6/slapd-config.html, the text near most of these entries sums up my feelings about poking here ;) (If you made the OLC config by converting from an old slapd.conf which you have kept, and if you didn't make too many changes afterwards, then it's possible to apply the changes and redo the conversion, but there are too many "if"s for my liking..)
