--On Thursday, January 25, 2018 9:02 AM -0500 Scott Bickford
I did not use -q on slapadd.
Essentially I do a slapadd -f /etc/openldap/slapd.conf -b o=myco,c=us,
-v -w > load_myco.log
We have three databases, so there are three slapadd above with -b
o=myapps,c=us -v -w > load_apps.log and a -b o=mycust,c=us -v -w >
If you are simply reloading a database you exported using slapcat, then you
should be using -q and should not be using -w.
We have a very large custom schema and three databases, so we are
using slapd.conf instead of cn=config. The schema dates back to the
Neither of those things is material to whether or not one chooses to use
slapd.conf vs cn=config.
The database is "bdb" on all three schemas.
It would be wise to upgrade to a current OpenLDAP release, and switch to
using back-mdb, as it consumers fewer resources than back-bdb and is
significantly faster for both reads and write operations.
The three production subscribers are load balanced and just one
publisher, which is not load balanced. It is used by some java
applications (which are also clustered) for updates. I am hoping that
we can replace subscribers over the course of several weeks since there
is quite a bit involved and have them up and running in production with
the publisher still on 2.4.40 and the subscribers on 2.4.44.
I am working with a VMWare person on planning how we are going to rename
Again, it would be wise to upgrade to a current OpenLDAP release, which you
will never obtain from RedHat. If you are not comfortable building
OpenLDAP on your own, then the LTB project has builds for free
>). Another alternative, if
your company wants support for the OpenLDAP product, are the Gold edition
builds from Symas (my employer) which are available with a support contract.
Packaged, certified, and supported LDAP solutions powered by OpenLDAP: