Quanah;
I can see the consumer attempting to connect to the Provider: ldap_write: want=254, written=254 0000: 30 81 fb 02 01 03 63 7a 04 0c 63 6e 3d 61 63 63 0.....cz..cn=acc
0010: 65 73 73 6c 6f 67 0a 01 02 0a 01 00 02 01 00 02 esslog..........
0020: 01 00 01 01 00 87 0b 6f 62 6a 65 63 74 63 6c 61 .......objectcla
0030: 73 73 30 4e 04 05 72 65 71 44 4e 04 07 72 65 71 ss0N..reqDN..req
0040: 54 79 70 65 04 06 72 65 71 4d 6f 64 04 09 72 65 Type..reqMod..re
0050: 71 4e 65 77 52 44 4e 04 0f 72 65 71 44 65 6c 65 qNewRDN..reqDele
0060: 74 65 4f 6c 64 52 44 4e 04 0e 72 65 71 4e 65 77 teOldRDN..reqNew
0070: 53 75 70 65 72 69 6f 72 04 08 65 6e 74 72 79 43 Superior..entryC
0080: 53 4e a0 7a 30 5a 04 18 31 2e 33 2e 36 2e 31 2e SN.z0Z..1.3.6.1.
0090: 34 2e 31 2e 34 32 30 33 2e 31 2e 39 2e 31 2e 31 4.1.4203.1.9.1.1
00a0: 04 3e 30 3c 0a 01 01 04 34 72 69 64 3d 30 30 31 .>0<....4rid=001
00b0: 2c 63 73 6e 3d 32 30 31 32 30 33 30 31 31 36 32 ,csn=20120301162
00c0: 30 33 33 2e 31 33 32 35 39 35 5a 23 30 30 30 30 033.132595Z#0000
00d0: 30 30 23 30 30 30 23 30 30 30 30 30 30 01 01 00 00#000#000000...
00e0: 30 1c 04 17 32 2e 31 36 2e 38 34 30 2e 31 2e 31 0...2.16.840.1.1
00f0: 31 33 37 33 30 2e 33 2e 34 2e 32 01 01 ff 13730.3.4.2...
=>do_syncrep2 rid=001 ldap_result ld 0x9f90550 msgid 3 wait4msg ld 0x9f90550 msgid 3 (infinite timeout) wait4msg continue ld 0x9f90550 msgid 3 all 0 ** ld 0x9f90550 Connections: * host: gp42-admin2.group42.ldap port: 636 (default) refcnt: 2 status: Connected last used: Wed Mar 14 14:24:45 2012
** ld 0x9f90550 Outstanding Requests: * msgid 3, origid 3, status InProgress outstanding referrals 0, parent count 0 ld 0x9f90550 request count 1 (abandoned 0) ** ld 0x9f90550 Response Queue: Empty ld 0x9f90550 response count 0 ldap_chkResponseList ld 0x9f90550 msgid 3 all 0 ldap_chkResponseList returns ld 0x9f90550 NULL ldap_int_select read1msg: ld 0x9f90550 msgid 3 all 0 ber_get_next tls_read: want=5, got=5 0000: 17 03 01 00 20 ....
tls_read: want=32, got=32 0000: 64 2f 3c f8 72 3d be 40 7d 9b c6 c4 12 ee 48 9b d/<.r=.@}.....H.
0010: 72 f1 b8 9a f0 8d 36 08 1c ac b0 2c 63 f3 24 43 r.....6....,c.$C
tls_read: want=5, got=5 0000: 17 03 01 00 d0 .....
tls_read: want=208, got=208 0000: b4 24 ca 72 60 56 91 05 c8 12 2c 8f 69 7a 2d f4 .$.r`V....,.iz-.
0010: 34 a6 59 60 00 9f 8d e8 02 29 1e 1f fe 7c 10 a1 4.Y`.....)...|..
0020: 21 fb d4 5f 03 e7 0e a3 e5 8b e9 4c 5f 69 1a 91 !.._.......L_i..
0030: e9 89 aa da 62 c1 89 94 39 00 db 4f c6 65 c6 4c ....b...9..O.e.L
0040: fc 8d 05 e8 0f 72 90 c6 3a b0 11 6c 26 4d 5d aa .....r..:..l&M].
0050: 10 49 fb a2 10 7f eb 9b fe 71 23 3c 31 98 aa 9f .I.......q#<1...
0060: 24 f4 ad ec 1b b9 45 d1 5d 14 60 80 8f ac f5 44 $.....E.].`....D
0070: c5 10 4d 76 52 04 c9 d4 ac 15 51 ea b7 3b 54 89 ..MvR.....Q..;T.
0080: 9c 2a 3c 15 91 3c f1 61 92 83 10 87 d3 94 8e 52 .*<..<.a.......R
0090: 9b f1 06 e8 20 eb 78 ff 2f 48 4e 6d ce 41 2d 02 .... .x./HNm.A-.
00a0: cb 03 8b 16 d6 b9 02 41 ff 1c 94 9a 9d f3 ca 13 .......A........
00b0: d9 fa 26 c2 f2 94 3d 1d f2 ce b1 ce 9e a1 39 b5 ..&...=.......9.
00c0: 2b 3c ea 98 b8 02 9e e8 e1 ce 7d 6a a1 5a 27 5f +<........}j.Z'_
ldap_read: want=8, got=8 0000: 30 81 b2 02 01 03 64 48 0.....dH
ldap_read: want=173, got=173 0000: 04 0c 63 6e 3d 61 63 63 65 73 73 6c 6f 67 30 38 ..cn=accesslog08
0010: 30 36 04 08 65 6e 74 72 79 43 53 4e 31 2a 04 28 06..entryCSN1*.(
0020: 32 30 31 32 30 33 30 37 31 35 33 39 31 33 2e 33 20120307153913.3
0030: 33 36 33 34 30 5a 23 30 30 30 30 30 30 23 30 30 36340Z#000000#00
0040: 30 23 30 30 30 30 30 30 a0 63 30 61 04 18 31 2e 0#000000.c0a..1.
0050: 33 2e 36 2e 31 2e 34 2e 31 2e 34 32 30 33 2e 31 3.6.1.4.1.4203.1
0060: 2e 39 2e 31 2e 32 04 45 30 43 0a 01 01 04 00 04 .9.1.2.E0C......
0070: 3c 72 69 64 3d 30 30 31 2c 73 69 64 3d 30 30 31 <rid=001,sid=001
0080: 2c 63 73 6e 3d 32 30 31 32 30 33 30 37 31 35 33 ,csn=20120307153
0090: 39 31 33 2e 33 33 36 33 34 30 5a 23 30 30 30 30 913.336340Z#0000
00a0: 30 30 23 30 30 30 23 30 30 30 30 30 30 00#000#000000
ber_get_next: tag 0x30 len 178 contents: read1msg: ld 0x9f90550 msgid 3 message type search-entry ber_scanf fmt ({xx) ber: ber_scanf fmt ({a) ber: ber_scanf fmt (o) ber: ber_scanf fmt ({em) ber: do_syncrep2: rid=001 got empty syncUUID with LDAP_SYNC_ADD ldap_msgfree ldap_free_request (origid 3, msgid 3) ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 16 ... do_syncrepl: rid=001 rc -1 retrying
############## Over on the Provider, I see the following: connection_get(61) connection_get(61) And the TLS/SSL output from the Consumer requesting "cn=accesslog", etc.
--- But, still not getting the two systems sync'd up. I am wondering if my indexes are not set correct or my ACLs. I've found some many varying setups via Google, etc.
David Borresen ph: 781-981-2954 email: john.d.borresen@ll.mit.edu
-----Original Message----- From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] Sent: Tuesday, March 13, 2012 6:40 PM To: Borresen, John - 0442 - MITLL Cc: openldap-technical@openldap.org Subject: RE: OPENLDAP SYNCREPL
--On Tuesday, March 13, 2012 4:10 PM -0400 "Borresen, John - 0442 - MITLL" john.borresen@ll.mit.edu wrote:
My apologies for sounding stupid...but, I really don't see it. Out of utter frustration, I have tried to run it on nearly all the dn's that I can find all with the same "objectClass: value #1 invalid syntax error".
I look at my overlay=syncprov and compare it to what you sent me they look identical. I'm not trying to sound stupid...
What you list as "MINE" is the one for the primary DB, *not* the accesslog DB. As I said, you need to ADD an additional syncprov overlay setting TO the accesslog DB. Since your accesslog DB is your SECOND BDB database, it would be along the lines of:
dn: olcOverlay={0}syncprov,olcDatabase={2}bdb,cn=config changetype:add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpNoPresent: TRUE olcSpReloadHint: TRUE
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration