[Date Prev][Date Next] [Chronological] [Thread] [Top]

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
>
> 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