Quaanh,
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 > load_cust.log
We have a very large custom schema and three databases, so we are still using slapd.conf instead of cn=config. The schema dates back to the 1990s.
The database is "bdb" on all three schemas.
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 the servers.
Also, for replication the config for each dn is:
type=refreshAndPersist interval=00:00:5:00 retry="5 5 300 +" searchbase="o=myco,c=us" filter="(objectclass=*)" attrs="*,+" scope=sub schemachecking=off bindmethod=simple
--On Thursday, January 25, 2018 9:02 AM -0500 Scott Bickford bic1ster@gmail.com wrote:
Quaanh,
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 > load_cust.log
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 still using slapd.conf instead of cn=config. The schema dates back to the 1990s.
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 the servers.
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 (https://ltb-project.org/download#openldap). 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.
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
openldap-technical@openldap.org
-
Quanah Gibson-Mount -
Scott Bickford