--On Thursday, July 26, 2018 6:02 PM -0700 admin(a)genome.arizona.edu wrote:
Quanah Gibson-Mount wrote on 07/26/2018 01:54 PM:
> a) Do you have a unique olcServerID set in cn=config for both masters?
Yes I thought I set that according to the guide. Actually just noticed
in the guide that both ldifs use "olcServerID: 1" so perhaps that is a
mistake? If I search for that variable on node1, I can see it in the
I ran a transaction on node2 to set it to 2, and now it is showing up on
on node2 there is no setting for olcServerID, am just using 'grep
olcServerID *' in the /etc/openldap/slapd.d directory
Are you replicating cn=config? If you are, the olcServerID value has to
include a URI and be multi-valued. For MMR to function, it is mandatory
that each have a unique olcServerID configured.
> b) Have you made sure there is no olcUpdateRef attribute set?
It does not appear to be set on either node, am just using grep again in
the /etc/openldap/slapd.d directory
> c) What version of OpenLDAP are you running?
slapd 2.4.40 on both nodes.
That release is particularly old and known to have many replication related
issues. I would strongly advise upgrading to the current release.
> d) I would note that back-bdb is deprecated. You may want to
> investigate migrating to back-mdb.
Actually I'm about the 4th system admin to take over these machines and
sadly have little knowledge of LDAP... so please bear with me... our
config is maybe very messy! the "database is not a shadow" error, does
it mean back-bdb does not support replication? If so, how do migrate
everything to back-mdb?
Both backends support replication and the issue you're having is not
related to this.
Unfortunately, without having a better idea of what your configuration is
or what it's trying to achieve, it's difficult to help you further.
Packaged, certified, and supported LDAP solutions powered by OpenLDAP: