Hello,

I want to synchronize the data in my ODSEE directory with the new Openldap directory.

I have ODSEE

[slapd 64-bit] Oracle Corporation. Sun-Directory-Server/11.1.1.7.3 B2015.0429.2115 64-bit ns-slapd : 11.1.1.7.3 B2015.0429.2115 ZIP Slapd Library : 11.1.1.7.3 B2015.0429.2115 Front-End Library : 11.1.1.7.3 B2015.0429.2115

end

Openldap 2.5.X

I did exactly what is indicated in the tests:

openldap / tests / scripts / test072-dsee-sync openldap / tests / scripts / test075-dsee-persist

The ODSEE directory starts correctly.

When I start the Openldap instance with the indicated replication

data / slapd-dsee-consumer1.conf data / slapd-dsee-consumer2.conf

IN Openldap start i have (with -d -1 option)

61926439.1a909db2 0x7f7e26799880 slapd starting 61926439.1b711895 0x7f7e1e406700 daemon: added 4r listener=(nil) 61926439.1b718582 0x7f7e1e406700 daemon: added 7r listener=0x563d9bd87c10 61926439.1b71aee4 0x7f7e1e406700 daemon: added 8r listener=0x563d9bd87d00 61926439.1b728f00 0x7f7e1e406700 daemon: epoll: listen=7 active_threads=0 tvp=zero 61926439.1b729cbf 0x7f7e1e406700 daemon: epoll: listen=8 active_threads=0 tvp=zero 61926439.1b72aaf3 0x7f7e1e406700 daemon: activity on 1 descriptor 61926439.1b72b304 0x7f7e1e406700 daemon: activity on:61926439.1b72bbba 0x7f7e1e406700 61926439.1b72cd95 0x7f7e1e406700 daemon: epoll: listen=7 active_threads=0 tvp=zero 61926439.1b72d667 0x7f7e1e406700 daemon: epoll: listen=8 active_threads=0 tvp=zero 61926439.1c6896b8 0x7f7e1dc05700 >>> dnNormalize: <cn=Consumer 002> 61926439.1c691535 0x7f7e1dc05700 <<< dnNormalize: <cn=consumer 002> 61926439.1c69b3df 0x7f7e1dc05700 =>do_syncrepl rid=002 61926439.1c69eaae 0x7f7e1dc05700 ldap_create 61926439.1c6a1e25 0x7f7e1dc05700 ldap_url_parse_ext(ldap://127.0.0.1:3389) 61926439.1c6a3c1d 0x7f7e1dc05700 ldap_sasl_bind_s 61926439.1c6a4b7a 0x7f7e1dc05700 ldap_sasl_bind 61926439.1c6a8303 0x7f7e1dc05700 ldap_send_initial_request 61926439.1c6a9831 0x7f7e1dc05700 ldap_new_connection 1 1 0 61926439.1c6aa2a5 0x7f7e1dc05700 ldap_int_open_connection 61926439.1c6ab2ef 0x7f7e1dc05700 ldap_connect_to_host: TCP 127.0.0.1:3389 61926439.1c6aea76 0x7f7e1dc05700 ldap_new_socket: 12 61926439.1c6afeb6 0x7f7e1dc05700 ldap_prepare_socket: 12 61926439.1c6b1f47 0x7f7e1dc05700 ldap_connect_to_host: Trying 127.0.0.1:3389 61926439.1c6b2888 0x7f7e1dc05700 ldap_pvt_connect: fd: 12 tm: -1 async: 0 61926439.1c6b2fd3 0x7f7e1dc05700 attempting to connect: 61926439.1c6dd2fe 0x7f7e1dc05700 connect success 61926439.1c6e01eb 0x7f7e1dc05700 ldap_open_defconn: successful 61926439.1c6e0de0 0x7f7e1dc05700 ldap_send_server_request 61926439.1c6e1c57 0x7f7e1dc05700 ber_scanf fmt ({it) ber: 61926439.1c6e2774 0x7f7e1dc05700 ber_dump: buf=0x7f7e10001bb0 ptr=0x7f7e10001bb0 end=0x7f7e10001bda len=42 61926439.1c6e3112 0x7f7e1dc05700 0000: 30 28 02 01 01 60 23 02 01 03 04 14 63 6e 3d 64 0(...`#.....cn=d 61926439.1c6e3916 0x7f7e1dc05700 0010: 69 72 65 63 74 6f 72 79 20 6d 61 6e 61 67 65 72 irectory manager 61926439.1c6e40a5 0x7f7e1dc05700 0020: 80 08 70 61 73 73 77 6f 72 64 ..password 61926439.1c6e4fb6 0x7f7e1dc05700 ber_scanf fmt ({i) ber: 61926439.1c6e5814 0x7f7e1dc05700 ber_dump: buf=0x7f7e10001bb0 ptr=0x7f7e10001bb5 end=0x7f7e10001bda len=37 61926439.1c6e5fe9 0x7f7e1dc05700 0000: 60 23 02 01 03 04 14 63 6e 3d 64 69 72 65 63 74 `#.....cn=direct 61926439.1c6e6776 0x7f7e1dc05700 0010: 6f 72 79 20 6d 61 6e 61 67 65 72 80 08 70 61 73 ory manager..pas 61926439.1c6e6f8f 0x7f7e1dc05700 0020: 73 77 6f 72 64 sword 61926439.1c6e8145 0x7f7e1dc05700 ber_flush2: 42 bytes to sd 12 61926439.1c6e8afb 0x7f7e1dc05700 0000: 30 28 02 01 01 60 23 02 01 03 04 14 63 6e 3d 64 0(...`#.....cn=d 61926439.1c6e9274 0x7f7e1dc05700 0010: 69 72 65 63 74 6f 72 79 20 6d 61 6e 61 67 65 72 irectory manager 61926439.1c6e99ea 0x7f7e1dc05700 0020: 80 08 70 61 73 73 77 6f 72 64 ..password 61926439.1c6eec1c 0x7f7e1dc05700 ldap_write: want=42, written=42 61926439.1c6ef60f 0x7f7e1dc05700 0000: 30 28 02 01 01 60 23 02 01 03 04 14 63 6e 3d 64 0(...`#.....cn=d 61926439.1c6efd8d 0x7f7e1dc05700 0010: 69 72 65 63 74 6f 72 79 20 6d 61 6e 61 67 65 72 irectory manager 61926439.1c6f05c4 0x7f7e1dc05700 0020: 80 08 70 61 73 73 77 6f 72 64 ..password 61926439.1c6f2277 0x7f7e1dc05700 ldap_result ld 0x7f7e10000920 msgid 1 61926439.1c6f2c34 0x7f7e1dc05700 wait4msg ld 0x7f7e10000920 msgid 1 (infinite timeout) 61926439.1c6f34b0 0x7f7e1dc05700 wait4msg continue ld 0x7f7e10000920 msgid 1 all 1 61926439.1c6f3e6c 0x7f7e1dc05700 ** ld 0x7f7e10000920 Connections: 61926439.1c6f52a0 0x7f7e1dc05700 * host: 127.0.0.1 port: 3389 (default) 61926439.1c6f6877 0x7f7e1dc05700 * from: IP=127.0.0.1:56180 61926439.1c6f70a2 0x7f7e1dc05700 refcnt: 2 status: Connected 61926439.1c6f8693 0x7f7e1dc05700 last used: Mon Nov 15 14:44:25 2021

61926439.1c6f8f52 0x7f7e1dc05700 61926439.1c6f98a4 0x7f7e1dc05700 ** ld 0x7f7e10000920 Outstanding Requests: 61926439.1c6fa2a6 0x7f7e1dc05700 * msgid 1, origid 1, status InProgress 61926439.1c6fab71 0x7f7e1dc05700 outstanding referrals 0, parent count 0 61926439.1c6fb4ca 0x7f7e1dc05700 ld 0x7f7e10000920 request count 1 (abandoned 0) 61926439.1c6fbc72 0x7f7e1dc05700 ** ld 0x7f7e10000920 Response Queue: 61926439.1c6fc3fa 0x7f7e1dc05700 Empty 61926439.1c6fcb6c 0x7f7e1dc05700 ld 0x7f7e10000920 response count 0 61926439.1c6fd389 0x7f7e1dc05700 ldap_chkResponseList ld 0x7f7e10000920 msgid 1 all 1 61926439.1c6fdb88 0x7f7e1dc05700 ldap_chkResponseList returns ld 0x7f7e10000920 NULL 61926439.1c6fe4a8 0x7f7e1dc05700 ldap_int_select 61926439.1c728a2b 0x7f7e1dc05700 read1msg: ld 0x7f7e10000920 msgid 1 all 1 61926439.1c72a729 0x7f7e1dc05700 ber_get_next 61926439.1c72bcf8 0x7f7e1dc05700 ldap_read: want=8, got=8 61926439.1c72c592 0x7f7e1dc05700 0000: 30 0c 02 01 01 61 07 0a 0....a.. 61926439.1c72ddfd 0x7f7e1dc05700 ldap_read: want=6, got=6 61926439.1c72e594 0x7f7e1dc05700 0000: 01 00 04 00 04 00 ...... 61926439.1c72ef09 0x7f7e1dc05700 ber_get_next: tag 0x30 len 12 contents: 61926439.1c72f810 0x7f7e1dc05700 ber_dump: buf=0x7f7e100011c0 ptr=0x7f7e100011c0 end=0x7f7e100011cc len=12 61926439.1c73000c 0x7f7e1dc05700 0000: 02 01 01 61 07 0a 01 00 04 00 04 00 ...a........ 61926439.1c73242e 0x7f7e1dc05700 ldap_find_request_by_msgid: msgid 1, lr 0x7f7e100010a0 lr->lr_refcnt = 1 61926439.1c7331b9 0x7f7e1dc05700 read1msg: ld 0x7f7e10000920 msgid 1 message type bind 61926439.1c733b07 0x7f7e1dc05700 ber_scanf fmt ({eAA) ber: 61926439.1c73431c 0x7f7e1dc05700 ber_dump: buf=0x7f7e100011c0 ptr=0x7f7e100011c3 end=0x7f7e100011cc len=9 61926439.1c734ad7 0x7f7e1dc05700 0000: 61 07 0a 01 00 04 00 04 00 a........ 61926439.1c7357b8 0x7f7e1dc05700 read1msg: ld 0x7f7e10000920 0 new referrals 61926439.1c736002 0x7f7e1dc05700 read1msg: mark request completed, ld 0x7f7e10000920 msgid 1 61926439.1c736829 0x7f7e1dc05700 request done: ld 0x7f7e10000920 msgid 1 61926439.1c73709e 0x7f7e1dc05700 res_errno: 0, res_error: <>, res_matched: <> 61926439.1c737a4d 0x7f7e1dc05700 ldap_return_request: lrx 0x7f7e100010a0, lr 0x7f7e100010a0 61926439.1c738307 0x7f7e1dc05700 ldap_return_request: lrx->lr_msgid 1, lrx->lr_refcnt is now 0, lr is still present 61926439.1c738cab 0x7f7e1dc05700 ldap_free_request (origid 1, msgid 1) 61926439.1c739a8c 0x7f7e1dc05700 ldap_free_request_int: lr 0x7f7e100010a0 msgid 1 removed 61926439.1c73a4cd 0x7f7e1dc05700 ldap_do_free_request: asked to free lr 0x7f7e100010a0 msgid 1 refcnt 0 61926439.1c73bb4b 0x7f7e1dc05700 ldap_parse_result 61926439.1c73c76f 0x7f7e1dc05700 ber_scanf fmt ({iAA) ber: 61926439.1c73cf85 0x7f7e1dc05700 ber_dump: buf=0x7f7e100011c0 ptr=0x7f7e100011c3 end=0x7f7e100011cc len=9 61926439.1c73d701 0x7f7e1dc05700 0000: 61 07 0a 01 00 04 00 04 00 a........ 61926439.1c73e2d4 0x7f7e1dc05700 ber_scanf fmt (}) ber: 61926439.1c73eac1 0x7f7e1dc05700 ber_dump: buf=0x7f7e100011c0 ptr=0x7f7e100011cc end=0x7f7e100011cc len=0 61926439.1c73f201 0x7f7e1dc05700 61926439.1c73fad8 0x7f7e1dc05700 ldap_msgfree 61926439.1c746e58 0x7f7e1dc05700 => mdb_entry_get: ndn: "dc=ici,dc=fr" 61926439.1c74789d 0x7f7e1dc05700 => mdb_entry_get: oc: "(null)", at: "lastChangeNumber" 61926439.1c74ce52 0x7f7e1dc05700 mdb_dn2entry("dc=ici,dc=fr") 61926439.1c76894c 0x7f7e1dc05700 => mdb_dn2id("dc=ici,dc=fr") 61926439.1c76a201 0x7f7e1dc05700 <= mdb_dn2id: got id=0x1 61926439.1c76c985 0x7f7e1dc05700 => mdb_entry_decode: 61926439.1c76e088 0x7f7e1dc05700 <= mdb_entry_decode 61926439.1c76ec57 0x7f7e1dc05700 => mdb_entry_get: found entry: "dc=ici,dc=fr" 61926439.1c76f8d5 0x7f7e1dc05700 <= mdb_entry_get: failed to find attribute lastChangeNumber 61926439.1c770d36 0x7f7e1dc05700 mdb_entry_get: rc=16 61926439.1c7717f9 0x7f7e1dc05700 do_syncrep1: rid=002 starting refresh (sending cookie=(null)) slapd: memory.c:705: ber_bvreplace_x: Assertion `!((src)->bv_val == ((void *)0))' failed. ./start-consumer1.sh : ligne 4 : 15293 Abandon /opt/symas/lib/slapd -d -1 -u ldap -g ldap -h "ldap://:5389/" -f /opt/symas/config/static-test/slapd-dsee-consumer1.conf

IN access log ODSEE i have :

[15/Nov/2021:14:44:25 +0100] conn=18 op=0 msgId=1 - BIND dn="cn=directory manager" method=128 version=3 [15/Nov/2021:14:44:25 +0100] conn=18 op=0 msgId=1 - RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager" [15/Nov/2021:14:44:25 +0100] conn=18 op=1 msgId=0 - RESULT err=80 tag=120 nentries=0 etime=0 [15/Nov/2021:14:44:25 +0100] conn=18 op=-1 msgId=-1 - closing from 127.0.0.1:56180 - A1 - Client aborted connection - [15/Nov/2021:14:44:25 +0100] conn=18 op=-1 msgId=-1 - closed.

I do not understand why ODSEE systematically gives an error 80 following the BIND of the consumer Openldap.

Can you help me ?

Thanks