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