I guess "got empty syncUUID" is the problem. >>> "Borresen, John - 0442 - MITLL" <[email protected]> schrieb am 11.02.2014 um 22:18 in Nachricht <[email protected]>: > 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: [email protected] > [mailto:[email protected]] 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; > [email protected] > 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: [email protected] > [[email protected]] On Behalf Of Borresen, John - 0442 > - MITLL [[email protected]] > Sent: Tuesday, February 11, 2014 2:41 PM > To: Quanah Gibson-Mount; Michael Ströder; [email protected] > 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: [email protected] > [[email protected]] On Behalf Of Borresen, John - 0442 > - MITLL [[email protected]] > Sent: Tuesday, February 11, 2014 1:34 PM > To: Quanah Gibson-Mount; Michael Ströder; [email protected] > 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:[email protected]] > Sent: Monday, February 10, 2014 6:42 PM > To: Borresen, John - 0442 - MITLL; Michael Ströder; > [email protected] > Subject: RE: Simple way to check that MMR is in sync? > > --On Monday, February 10, 2014 5:23 PM -0500 "Borresen, John - 0442 - MITLL" > <[email protected]> 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 >> >> 1) 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
