The "cn=replicator,cn=accesslog" was the olcRootDN for the accesslog.
Rather that was my intent.
Rereading documentation...and the script you shared with me a few weeks back.
Currently, my set up is:
1) The rootDN for the cn=config is cn=admin (cn=admin,cn=config)
2) the rootDN for my primary dbase is cn=ldapadmin (cn=ldapadmin,dc=example,dc=ldap)
3) the rootDN for the accesslog, as mentioned above, is/was cn=replicator
My ou=Users,dc=example,dc=ldap has all the End-Users uids for logins.
Noticed you have a cn=admins,cn=zimbra.
Bear with the stupid question, this is more of a sanity check for me (getting pressure
from my side to get this project done -- so very rushed).
I could/should create an "ou=Admins,dc=example,dc=ldap", on both MM-Servers
In that ou create/move the replicator that I wrongfully created in cn=accesslog:
That will get this user in the dbase.
Modify, the olcSyncrepl, olcAccess, etc on both MM-Servers.
Is that basically, correct?
From: Quanah Gibson-Mount [mailto:email@example.com]
Sent: Monday, February 03, 2014 11:57 AM
To: Borresen, John - 0442 - MITLL; openldap-technical(a)openldap.org
Subject: RE: Syncrepl and mmr
--On Monday, February 03, 2014 9:57 AM -0500 "Borresen, John - 0442 - MITLL"
I turned off TLS on both MMR machines, so I could more easily
troubleshoot Syncrepl/MMR configuration. Once over this hurdle, I'll
The following is a snippet of the SLAPD output-log file:
52efa558 => bdb_dn2id("cn=replicator,cn=accesslog")
52efa558 <= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data
pair found (-30989) 52efa558 send_ldap_result: conn=5226 op=0 p=3
52efa558 send_ldap_result: err=49 matched="" text=""
What is cn=replicator,cn=accesslog? Whatever it is, it doesn't exist in your DB.
Architect - Server
Zimbra :: the leader in open source messaging and collaboration