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

Antw: RE: Simple way to check that MMR is in sync?

To: "John - 0442 - MITLL Borresen" <John.Borresen@ll.mit.edu>, "openldap-technical@openldap.org" <openldap-technical@openldap.org>, <michael@stroeder.com>, "Quanah Gibson-Mount" <quanah@zimbra.com>
Subject: Antw: RE: Simple way to check that MMR is in sync?
From: "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de>
Date: Wed, 12 Feb 2014 08:38:05 +0100
Content-disposition: inline
In-reply-to: <201402112118.s1BLIY8Z075659@boole.openldap.org>
References: <CAKTSSTgpWhVHLfLR7rH5pj=-Be=U8Oy-36EmaFQry9CZBsVrUg@mail.gmail.com> <52F4EA9F020000A100014475@gwsmtp1.uni-regensburg.de> <52F52FD4.9020704@stroeder.com> <201402102224.s1AMO8ig090244@boole.openldap.org> <FDFF08CECEB46CE5C7C10982@[192.168.1.2]>, <201402111834.s1BIYjI0065907@boole.openldap.org>, <201402111942.s1BJgFY4069786@boole.openldap.org> <201402111959.s1BJxlSA070842@boole.openldap.org> <201402112118.s1BLIY8Z075659@boole.openldap.org>

I guess "got empty syncUUID" is the problem.

>>> "Borresen, John - 0442 - MITLL" <John.Borresen@ll.mit.edu> schrieb am
11.02.2014 um 22:18 in Nachricht
<201402112118.s1BLIY8Z075659@boole.openldap.org>:
> 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
>>
>> 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

References:
- Simple way to check that MMR is in sync?
  - From: Philip Colmer <philip.colmer@linaro.org>
- Antw: Simple way to check that MMR is in sync?
  - From: "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de>
- Re: Simple way to check that MMR is in sync?
  - From: Michael Ströder <michael@stroeder.com>
- RE: Simple way to check that MMR is in sync?
  - From: "Borresen, John - 0442 - MITLL" <John.Borresen@ll.mit.edu>
- RE: Simple way to check that MMR is in sync?
  - From: Quanah Gibson-Mount <quanah@zimbra.com>
- RE: Simple way to check that MMR is in sync?
  - From: "Borresen, John - 0442 - MITLL" <John.Borresen@ll.mit.edu>
- RE: Simple way to check that MMR is in sync?
  - From: "Borresen, John - 0442 - MITLL" <John.Borresen@ll.mit.edu>
- RE: Simple way to check that MMR is in sync?
  - From: "Borresen, John - 0442 - MITLL" <John.Borresen@ll.mit.edu>
- RE: Simple way to check that MMR is in sync?
  - From: "Borresen, John - 0442 - MITLL" <John.Borresen@ll.mit.edu>

Prev by Date: Re: slapo-accesslog
Next by Date: Re: replication delay problem
Index(es):
- Chronological
- Thread