[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: Simple way to check that MMR is in sync?
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