All,
On mm-server1, I modified the cn=role2,ou=sudoers,dc=example,dc=ldap, by adding four more "sudoUsers":
# ldapmodify -H ldap://mm-server1.example.ldap -d 256 -x -D cn=ldapadmin,dc=example,dc=ldap -x -W Enter LDAP Password: dn: cn=role2,ou=sudoers,dc=example,dc=ldap changetype: modify add: sudoUser sudoUser: jdoe3
modifying entry "cn=role2,ou=sudoers,dc=example,dc=ldap"
dn: cn=role2,ou=sudoers,dc=example,dc=ldap changetype: modify add: sudoUser sudoUser: jdoe4
modifying entry "cn=role2,ou=sudoers,dc=example,dc=ldap"
dn: cn=role2,ou=sudoers,dc=example,dc=ldap changetype: modify add: sudoUser sudoUser: jdoe5
modifying entry "cn=role2,ou=sudoers,dc=example,dc=ldap"
dn: cn=role2,ou=sudoers,dc=example,dc=ldap changetype: modify add: sudoUser sudoUser: jdoe6
modifying entry "cn=role2,ou=sudoers,dc=example,dc=ldap"
In the accesslog on mm-server1: # ldapsearch -W -x -b cn=accesslog -v -D uid=replicator,ou=Admins,dc=example,dc=ldap reqStart ldap_initialize( <DEFAULT> ) Enter LDAP Password: filter: (objectclass=*) requesting: reqStart # extended LDIF # # LDAPv3 # base <cn=accesslog> with scope subtree # filter: (objectclass=*) # requesting: reqStart #
# accesslog dn: cn=accesslog
# 20140211203708.000000Z, accesslog dn: reqStart=20140211203708.000000Z,cn=accesslog reqStart: 20140211203708.000000Z
# 20140211203748.000000Z, accesslog dn: reqStart=20140211203748.000000Z,cn=accesslog reqStart: 20140211203748.000000Z
# 20140211203819.000000Z, accesslog dn: reqStart=20140211203819.000000Z,cn=accesslog reqStart: 20140211203819.000000Z
# 20140211203851.000000Z, accesslog dn: reqStart=20140211203851.000000Z,cn=accesslog reqStart: 20140211203851.000000Z
# search result search: 2 result: 0 Success
# numResponses: 6 # numEntries: 5
On mm-server2 nothing is updating but am seeing this in the logs: (rid=001 is mm-server1) 52fa9043 send_ldap_result: err=0 matched="" text="" ldap_build_search_req ATTRS: reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN 52fa9066 do_syncrep2: rid=001 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog) 52fa9066 do_syncrepl: rid=001 rc -1 retrying ldap_build_search_req ATTRS: reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN 52fa90a2 do_syncrep2: rid=001 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog) 52fa90a2 do_syncrepl: rid=001 rc -1 retrying 52fa90d1 connection_get(76) ldap_build_search_req ATTRS: reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN 52fa90de do_syncrep2: rid=001 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog) 52fa90de do_syncrepl: rid=001 rc -1 retrying ldap_build_search_req ATTRS: reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN 52fa911a do_syncrep2: rid=001 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog) 52fa911a do_syncrepl: rid=001 rc -1 retrying ldap_build_search_req ATTRS: reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN 52fa9156 do_syncrep2: rid=001 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog) 52fa9156 do_syncrepl: rid=001 rc -1 retrying ldap_build_search_req ATTRS: reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN 52fa9192 do_syncrep2: rid=001 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog) 52fa9192 do_syncrepl: rid=001 rc -1 retrying ldap_build_search_req ATTRS: reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN 52fa91ce do_syncrep2: rid=001 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog) 52fa91ce do_syncrepl: rid=001 rc -1 retrying ldap_build_search_req ATTRS: reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN 52fa920a do_syncrep2: rid=001 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog) 52fa920a do_syncrepl: rid=001 rc -1 retrying ldap_build_search_req ATTRS: reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN 52fa9246 do_syncrep2: rid=001 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog) 52fa9246 do_syncrepl: rid=001 rc -1 retrying
The "interval" is set to the default (01:00:00:00), type refreshAndPersist. Yes, after reading the admin guide:
The LDAP Content Synchronization protocol has two operation types: refreshOnly and refreshAndPersist. The operation type is specified by the type parameter. In the refreshOnly operation, the next synchronization search operation is periodically rescheduled at an interval time after each synchronization operation finishes. The interval is specified by the interval parameter. It is set to one day by default. In the refreshAndPersist operation, a synchronization search remains persistent in the provider slapd instance. Further updates to the master replica will generate searchResultEntry to the consumer slapd as the search responses to the persistent synchronization search.
1) is the interval really only used if the type is set to "refreshOnly"?
I am guessing by the "got empty syncUUID"...and "rid=001 rc -1 retrying"...that my MMR configuration is not working -- it's trying but not working. I am not sure what else to look for to get things working.
Thanks in advance
John
-----Original Message----- From: openldap-technical-bounces@OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Borresen, John - 0442 - MITLL Sent: Tuesday, February 11, 2014 2:57 PM To: Borresen, John - 0442 - MITLL; Quanah Gibson-Mount; Michael Ströder; openldap-technical@openldap.org Subject: RE: Simple way to check that MMR is in sync?
Ok,
Looking back at old board messages, I was able to get slapd started. Even after chown -R ldap:ldap both the accesslog and openldap-data directories (and -u ldap in the slapd command-line), most of the files became owned by root:root. But, after the failure, re-chowned and it worked.
But, still concerned about the "...access granted by manage..."
Thanks, John ________________________________________ From: openldap-technical-bounces@OpenLDAP.org [openldap-technical-bounces@OpenLDAP.org] On Behalf Of Borresen, John - 0442 - MITLL [John.Borresen@ll.mit.edu] Sent: Tuesday, February 11, 2014 2:41 PM To: Quanah Gibson-Mount; Michael Ströder; openldap-technical@openldap.org Subject: RE: Simple way to check that MMR is in sync?
All,
I attempted to slapadd the main dbase to the mm-server2 in an attempt to sync things up. Thought it was going well (no errors when doing the slapadd) but when attempting to start slapd, it failed. Here is the tail end of the start up:
237 52fa74d3 => test_filter 238 52fa74d3 GE 239 52fa74d3 => access_allowed: search access to "olcOverlay={0}syncprov,olcDatabase={0}config,cn=config" "entryCSN" requested 240 52fa74d3 <= root access granted 241 52fa74d3 => access_allowed: search access granted by manage(=mwrscxd) 242 52fa74d3 <= test_filter 5 243 52fa74d3 => test_filter 244 52fa74d3 GE 245 52fa74d3 => access_allowed: search access to "olcDatabase={1}bdb,cn=config" "entryCSN" requested 246 52fa74d3 <= root access granted 247 52fa74d3 => access_allowed: search access granted by manage(=mwrscxd) 248 52fa74d3 <= test_filter 6 249 52fa74d3 => test_filter 250 52fa74d3 GE 251 52fa74d3 => access_allowed: search access to "olcOverlay={0}accesslog,olcDatabase={1}bdb,cn=config" "entryCSN" requested 252 52fa74d3 <= root access granted 253 52fa74d3 => access_allowed: search access granted by manage(=mwrscxd) 254 52fa74d3 <= test_filter 5 255 52fa74d3 => test_filter 256 52fa74d3 GE 257 52fa74d3 => access_allowed: search access to "olcOverlay={1}syncprov,olcDatabase={1}bdb,cn=config" "entryCSN" requested 258 52fa74d3 <= root access granted 259 52fa74d3 => access_allowed: search access granted by manage(=mwrscxd) 260 52fa74d3 <= test_filter 5 261 52fa74d3 => test_filter 262 52fa74d3 GE 263 52fa74d3 => access_allowed: search access to "olcDatabase={2}bdb,cn=config" "entryCSN" requested 264 52fa74d3 <= root access granted 265 52fa74d3 => access_allowed: search access granted by manage(=mwrscxd) 266 52fa74d3 <= test_filter 5 267 52fa74d3 => test_filter 268 52fa74d3 GE 269 52fa74d3 => access_allowed: search access to "olcOverlay={0}syncprov,olcDatabase={2}bdb,cn=config" "entryCSN" requested 270 52fa74d3 <= root access granted 271 52fa74d3 => access_allowed: search access granted by manage(=mwrscxd) 272 52fa74d3 <= test_filter 5 273 52fa74d3 => test_filter 274 52fa74d3 GE 275 52fa74d3 => access_allowed: search access to "olcDatabase={3}monitor,cn=config" "entryCSN" requested 276 52fa74d3 <= root access granted 277 52fa74d3 => access_allowed: search access granted by manage(=mwrscxd) 278 52fa74d3 <= test_filter 5 279 52fa74d3 send_ldap_result: conn=-1 op=0 p=0 280 52fa74d3 send_ldap_result: err=0 matched="" text="" 281 52fa74d3 backend_startup_one: starting "dc=example,dc=ldap" 282 52fa74d3 bdb_db_open: "dc=example,dc=ldap" 283 52fa74d3 bdb_db_open: database "dc=example,dc=ldap": alock package is unstable. 284 52fa74d3 backend_startup_one (type=bdb, suffix="dc=example,dc=ldap"): bi_db_open failed! (-1) 285 52fa74d3 slapd shutdown: initiated 286 52fa74d3 ====> bdb_cache_release_all 287 52fa74d3 ====> bdb_cache_release_all 288 52fa74d3 slapd destroy: freeing system resources. 289 52fa74d3 syncinfo_free: rid=001 290 52fa74d3 slapd stopped.
1) I don't understand the "...access granted by manage...", as I've looked and looked and compared side by side the olcAccess, etc and no one has manage privs.
2) I noticed the "alock package is unstable" then on the next line "bi_db_open failed!" nasty gram.
Thanks in advance
John ________________________________________ From: openldap-technical-bounces@OpenLDAP.org [openldap-technical-bounces@OpenLDAP.org] On Behalf Of Borresen, John - 0442 - MITLL [John.Borresen@ll.mit.edu] Sent: Tuesday, February 11, 2014 1:34 PM To: Quanah Gibson-Mount; Michael Ströder; openldap-technical@openldap.org Subject: RE: Simple way to check that MMR is in sync?
Thanks Quanah;
I take it that your advice from a while back still stands, slapadd the main dbase from mm-server1 to mm-server2 (this time I won't do a slapindex -- honest)?
Thanks in advance John
-----Original Message----- From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] Sent: Monday, February 10, 2014 6:42 PM To: Borresen, John - 0442 - MITLL; Michael Ströder; openldap-technical@openldap.org Subject: RE: Simple way to check that MMR is in sync?
--On Monday, February 10, 2014 5:23 PM -0500 "Borresen, John - 0442 - MITLL" John.Borresen@ll.mit.edu wrote:
All,
I've been reading this string...
Comparing the entryCSNs & contextCSNs on both of my test servers at the base DN (dc=example,dc=ldap):
mm-server1: entryCSN: 20140121153301.911487Z#000000#003#000000 contextCSN: 20140203183831.751838Z#000000#001#000000 contextCSN: 20140204143957.937393Z#000000#002#000000
mm-server2: entryCSN: 20140121153301.911487Z#000000#003#000000 contextCSN: 20140129140325.443822Z#000000#000#000000 contextCSN: 20140203183831.751838Z#000000#001#000000 contextCSN: 20140129183014.073734Z#000000#002#000000 contextCSN: 20140121153301.911487Z#000000#003#000000
- What is this information telling me? (I want to be sure that I
know) 2) Should I be concerned that there are more on mm-server2?
a) Ignore entryCSN
b) This means that mm-server2 has knowledge of 3 masters (1, 2, 3) mm-server1 only has knowledge of 2 masters (1, 2). This would imply that there is something broken in your setup.
--Quanah
--
Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration