--On Monday, November 23, 2015 7:12 PM -0500 Betsy Schwartz betsy.schwartz@gmail.com wrote:

...

On Sat, Nov 21, 2015 at 2:00 PM, Quanah Gibson-Mount quanah@zimbra.com wrote:

I would suggest using slapcat to export the config database and clean up the invalid attribute values that were incorrectly added to the bdb database.

Thank you very much! I have made progress but am now in an entertaining new place (having *overwritten* my database with my overlay files). But I'm going to go RTFM and see if I can't dig myself out of that one.

Well, generally you would want to do something like:

slapcat -F /path/to/config/db -n 0 -l config.ldif mv /path/to/config/db somwhere else mkdir -p /path/to/config/db

modify config.ldif to be correct slapadd -F /path/to/config/db -n 0 -l config.ldif

That should reload your config db in full, minus what you fixed.

...

a) Upgrading to a current openldap release b) Switching to back-mdb, assuming a 64-bit OS.

Thank you! Sigh, 2.4.40 seems to be the latest in the Oracle repo (we are using Oracle's version of RHEL6).  It looks like there have been some good bug fixes and I'll make the case for going outside the repo. Sometime in the next couple months these two new servers will become the primary production servers and then we'll be able to do what we want with them.

It is extremely ill advised to ever use distro builds. They are not supported by the OpenLDAP project, and issues with distro builds need to be taken to the distro provider. I would note that RHEL builds are particularly bad, as they link to a known insecure and problematic crypto library that is not supported by the OpenLDAP project.

I also suggest reading over http://www.openldap.org/faq/data/cache/1456.html. It was written some time ago, but is still completely relevant.

If building OpenLDAP yourself isn't something you really want to get into, then the LTB project builds (http://ltb-project.org/wiki/download#openldap) are a great starting point if you don't require support. If you require builds backed by support, I strongly recommend Symas (http://www.symas.com).

The  two old servers, current production, are running 2.4.39 and 2.4.23 (and not syncing with each other!) . I've been hoping that I could sync data between at least these two new servers and the 2.4.39 server, is that possible or a foolish hope?  Again, once these new ones become primary I'll be able to keep them identical to each other, but I don't really 'own' the old ones and don't want to break them. I'm still working through the manual and the configuration settings.

It's possible, but probably unrealisitc to expect it will work well, given the significant replication bugs fixed since 2.4.23 in particular.

One more question - still trying to understand what was done on these old servers - on these servers the config database is 0, the monitor database is 1 and the bdb database is 2. I can't slapcat the monitor database, is that normal? I get slapcat -n 1 slapcat: database doesn't support necessary operations.

This is normal, the monitor database isn't an actual on disk DB. There is no real configuration for it beyond instantiating it. This is how the export for it looks from my config DB:

dn: olcDatabase={1}monitor objectClass: olcDatabaseConfig olcDatabase: {1}monitor olcAccess: {0}to dn.children="cn=monitor" by dn.children="cn=admins,cn=zimbra " read olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=config olcMonitoring: FALSE

--Quanah

--

Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration