openldap-bugs December 2021

openldap-bugs@openldap.org

1 participants
121 discussions

[Issue 9647] New: Glue entry creation doesn't replicate properly
by openldap-its＠openldap.org 20 Jan '22

20 Jan '22

https://bugs.openldap.org/show_bug.cgi?id=9647 Issue ID: 9647 Summary: Glue entry creation doesn't replicate properly Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- In plain syncrepl, when an entry is turned into glue (to remove it when it still has children), it won't replicate correctly to its consumers - a NEW_COOKIE intermediate message is sent instead. Scenario: - 4 servers (A, B, C, D) and a tree with two entries - cn=parent,cn=suffix and its parent, the database suffix - D replicates from C, C replicates from A and B, no other links set up for this Now: 1. add an entry "cn=child,cn=parent,cn=suffix" on A 2. remove "cn=parent,cn=suffix" from B As things settle, cn=parent,cn=suffix is retained on D while being deleted from C. -- You are receiving this mail because: You are on the CC list for the issue.

1 12

[Issue 9758] New: slapd-sock cn=config issues
by openldap-its＠openldap.org 20 Jan '22

20 Jan '22

https://bugs.openldap.org/show_bug.cgi?id=9758 Issue ID: 9758 Summary: slapd-sock cn=config issues Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- This module has multiple issues with cn=config processing: - empty/missing sockdnpat can trigger an assert - adding multiple olcDbSocketExtensions/olcOvSocketOps/olcOvSocketResps does not work as expected, deletes are also broken -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9740] New: olcPPolicyCheckModule not working in 2.6.0
by openldap-its＠openldap.org 20 Jan '22

20 Jan '22

https://bugs.openldap.org/show_bug.cgi?id=9740 Issue ID: 9740 Summary: olcPPolicyCheckModule not working in 2.6.0 Product: OpenLDAP Version: 2.6.0 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: david.coutadeur(a)gmail.com Target Milestone: --- Following: https://bugs.openldap.org/show_bug.cgi?id=9666, we must now use the olcPPolicyCheckModule directive in the overlay configuration, instead of the pwdCheckModule in the password policy. I have 3 remarks: 1/ it's a pity we can't define the chosen module in the corresponding ppolicy. It prevents having multiple extension to password policies (one for each policy) 2/ it does not seem to work. (ie the extended module is not launched). See below for my config and data. 3/ the slapo-ppolicy is quite unclear about the configuration. For example, I can read: ( 1.3.6.1.4.1.4754.2.99.1 NAME 'pwdPolicyChecker' AUXILIARY SUP top MAY ( pwdCheckModule $ pwdCheckModuleArg $ pwdUseCheckModule ) ) Does pwdCheckModule and pwdUseCheckModule still have sense? Here is my configuration: dn: olcOverlay={0}ppolicy,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcPPolicyConfig olcOverlay: {0}ppolicy olcPPolicyDefault: cn=default,ou=ppolicies,dc=my-domain,dc=com olcPPolicyHashCleartext: TRUE olcPPolicyUseLockout: FALSE olcPPolicyForwardUpdates: FALSE olcPPolicyDisableWrite: FALSE olcPPolicySendNetscapeControls: FALSE olcPPolicyCheckModule: /usr/local/openldap/libexec/openldap/ppm.so Here are my data: dn: cn=default,ou=ppolicies,dc=my-domain,dc=com objectClass: pwdPolicy objectClass: pwdPolicyChecker objectClass: organizationalRole cn: default pwdAttribute: userPassword pwdCheckQuality: 2 pwdMaxAge: 7776000 pwdInHistory: 5 pwdLockout: TRUE pwdMaxFailure: 5 pwdFailureCountInterval: 86400 pwdMinLength: 8 pwdMaxLength: 30 pwdExpireWarning: 432000 pwdMustChange: TRUE pwdAllowUserChange: TRUE pwdMaxIdle: 31536000 pwdCheckModuleArg: bWluUXVhbGl0eSAzCmNoZWNrUkROIDAKZm9yYmlkZGVuQ2hhcnMKbWF4Q29uc2VjdXRpdmVQZXJDbGFzcyAwCnVzZUNyYWNrbGliIDAKY3JhY2tsaWJEaWN0IC92YXIvY2FjaGUvY3JhY2tsaWIvY3JhY2tsaWJfZGljdApjbGFzcy11cHBlckNhc2UgQUJDREVGR0hJSktMTU5PUFFSU1RVVldYWVogMCAxCmNsYXNzLWxvd2VyQ2FzZSBhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3h5eiAwIDEKY2xhc3MtZGlnaXQgMDEyMzQ1Njc4OSAwIDEKY2xhc3Mtc3BlY2lhbCA8Piw/Oy46LyHCp8O5JSrCtV7CqCTCo8KyJsOpfiIjJ3soWy18w6hgX1zDp17DoEApXcKwPX0rIDAgMQ== dn: uid=jack.oneill,ou=people,dc=my-domain,dc=com objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person objectClass: top cn: Jack O Neill givenName: Jack mail: jack.oneill(a)my-example.com sn: O Neill uid: jack.oneill userPassword: {ARGON2}$argon2id$v=19$m=65536,t=2,p=1$LiSaGIqce9o2C6T8d2BOfg$BpPpokTfKY9/X7/jkvG1SXBcsNnm95UbTGSstc2aHKk -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 9743] New: LDAP_OPT_SOCKET_BIND_ADDRESSES - sin_port is not initialized
by openldap-its＠openldap.org 20 Jan '22

20 Jan '22

https://bugs.openldap.org/show_bug.cgi?id=9743 Issue ID: 9743 Summary: LDAP_OPT_SOCKET_BIND_ADDRESSES - sin_port is not initialized Product: OpenLDAP Version: 2.5.6 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: dg0319q(a)gmail.com Target Milestone: --- When LDAP_OPT_SOCKET_BIND_ADDRESSES is set, and ldap_search_s is being called, valgrind detects uninitialised value (ip4addr.sin_port). Valgrind log: =52721== Syscall param socketcall.bind(my_addr.sin_port) points to uninitialised byte(s) ==52721== at 0x54C7F2B: bind (syscall-template.S:120) ==52721== by 0x52434A5: ldap_connect_to_host (in /usr/lib/x86_64-linux-gnu/libldap-2.5.so.0.1.1) ==52721== by 0x52352CD: ldap_int_open_connection (in /usr/lib/x86_64-linux-gnu/libldap-2.5.so.0.1.1) ==52721== by 0x524875B: ldap_new_connection (in /usr/lib/x86_64-linux-gnu/libldap-2.5.so.0.1.1) ==52721== by 0x523494D: ldap_open_defconn (in /usr/lib/x86_64-linux-gnu/libldap-2.5.so.0.1.1) ==52721== by 0x52493F7: ldap_send_initial_request (in /usr/lib/x86_64-linux-gnu/libldap-2.5.so.0.1.1) ==52721== by 0x52387E7: ldap_search (in /usr/lib/x86_64-linux-gnu/libldap-2.5.so.0.1.1) ==52721== by 0x52388AD: ldap_search_s (in /usr/lib/x86_64-linux-gnu/libldap-2.5.so.0.1.1) ==52721== by 0x28565F: check_ldap (simple.c:83) ==52721== Address 0x1ffeff6122 is on thread 1's stack ==52721== in frame #1, created by ldap_connect_to_host (???:) ==52721== Uninitialised value was created by a stack allocation ==52721== at 0x5242DE0: ldap_connect_to_host (in /usr/lib/x86_64-linux-gnu/libldap-2.5.so.0.1.1) Looks like, the ip4addr.sin_port should be set to 0 in ldap_connect_to_host. It works, but it looks like it is a bug, and may fail under other circumstances. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9728] New: For lastbind-precision, note it is important in busy replicated environments
by openldap-its＠openldap.org 20 Jan '22

20 Jan '22

https://bugs.openldap.org/show_bug.cgi?id=9728 Issue ID: 9728 Summary: For lastbind-precision, note it is important in busy replicated environments Product: OpenLDAP Version: 2.6.0 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- It would be good to note in the slapd.conf(5)/slapd-config(5) man pages that the lastbind-precision setting can be very important to set in busy, replicated environments. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9727] New: slapd-watcher fails to start if any slapd instance is down
by openldap-its＠openldap.org 20 Jan '22

20 Jan '22

https://bugs.openldap.org/show_bug.cgi?id=9727 Issue ID: 9727 Summary: slapd-watcher fails to start if any slapd instance is down Product: OpenLDAP Version: 2.6.0 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: gnoe(a)symas.com Target Milestone: --- When starting slapd-watcher and slapd isn't running on one of the monitored servers, slapd-watcher fails to start: Example w/host2 slapd not running: [user@host]# slapd-watcher -xD dc=example,dc=com -w secret -b dc=example,dc=com -s 1,2 ldap://host1/ ldap://host2/ slapd-watcher PID=11892: ldap_sasl_bind_s: Can't contact LDAP server (-1) I would expect that slapd-watcher would start up completely and indicate the host was down, like in the case where a host goes down while slapd-watcher is running. This would allow slapd-watcher to start when one or more replication node is down for maintenance. -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 9733] New: ppolicy.c:66:2: error: unknown type name ‘lt_dlhandle’
by openldap-its＠openldap.org 20 Jan '22

20 Jan '22

https://bugs.openldap.org/show_bug.cgi?id=9733 Issue ID: 9733 Summary: ppolicy.c:66:2: error: unknown type name ‘lt_dlhandle’ Product: OpenLDAP Version: 2.6.0 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: smillerdev(a)me.com Target Milestone: --- On both Linux and macOS in Homebrew, there is a failure trying to compile OpenLDAP 2.6.0: /bin/sh ../../../libtool --tag=disable-shared --mode=compile gcc-5 -g -O2 -I../../../include -I../../../include -I.. -I./.. -I./../slapi -c log.c ppolicy.c:66:2: error: unknown type name ‘lt_dlhandle’ lt_dlhandle pwdCheckHandle; /* handle from lt_dlopen */ ^ on macOS there is also an additional errror: ppolicy.c:458:4: error: initializer element is not a compile-time constant (void *)offsetof(pp_info,hash_passwords), ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ See https://github.com/Homebrew/homebrew-core/pull/88036 for the full output -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9691] New: Allow syncrepl persist sessions against empty DBs
by openldap-its＠openldap.org 20 Jan '22

20 Jan '22

https://bugs.openldap.org/show_bug.cgi?id=9691 Issue ID: 9691 Summary: Allow syncrepl persist sessions against empty DBs Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review, replication Severity: enhancement Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- One way to set up an environment is to start with a completely empty DB, configure all nodes and replication paths and then populate them. Right now, the syncrepl sessions get rejected with a 32 NO_SUCH_OBJECT, triggering the retry cascade. Both the consumer and provider have an empty cookie, so they are in sync and we could actually transition to a persist phase and let the session proceed. This way the environment would start replicating almost immediately after first entries are added. Mind that ITS#9584 still pushes concurrent refreshes into the retry logic adding a short delay before *all* configured links are set up. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9772] New: replication of cn=config for olcDatabase={2}mdb,cn=config not working
by openldap-its＠openldap.org 20 Jan '22

20 Jan '22

https://bugs.openldap.org/show_bug.cgi?id=9772 Issue ID: 9772 Summary: replication of cn=config for olcDatabase={2}mdb,cn=config not working Product: OpenLDAP Version: 2.6.0 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: stefan(a)kania-online.de Target Milestone: --- My setup is a mmr for cn=config. The configuration of all servers is: --------------- dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov dn: olcDatabase={0}config,cn=config changetype: modify replace: olcSyncRepl olcSyncRepl: rid=1 provider=ldap://ldap01.example.net binddn="cn=admin,cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 20" timeout=1 starttls=yes tls_reqcert=allow olcSyncRepl: rid=2 provider=ldap://ldap02.example.net binddn="cn=admin,cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 20" timeout=1 starttls=yes tls_reqcert=allow olcSyncRepl: rid=3 provider=ldap://ldap03.example.net binddn="cn=admin,cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 20" timeout=1 starttls=yes tls_reqcert=allow olcSyncRepl: rid=4 provider=ldap://ldap04.example.net binddn="cn=admin,cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 20" timeout=1 starttls=yes tls_reqcert=allow - add: olcMultiprovider olcMultiprovider: TRUE ------------- Replication is working for dn: olcDatabase={-1}frontend,cn=config but not for the configuration of the main DB dn: olcDatabase={2}mdb,cn=config When I do a change I got the following messages: ----------------- messages on provider Dez 15 10:37:56 ldap04 slapd[6319]: conn=1013 fd=18 ACCEPT from IP=192.168.56.46:57844 (IP=0.0.0.0:389) Dez 15 10:37:56 ldap04 slapd[6319]: conn=1013 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Dez 15 10:37:56 ldap04 slapd[6319]: conn=1013 op=0 STARTTLS Dez 15 10:37:56 ldap04 slapd[6319]: conn=1013 op=0 RESULT oid= err=0 qtime=0.000023 etime=0.000176 text= Dez 15 10:37:56 ldap04 slapd[6319]: conn=1013 fd=18 TLS established tls_ssf=256 ssf=256 tls_proto=TLSv1.3 tls_cipher=TLS_AES_256_GCM_SHA384 Dez 15 10:37:56 ldap04 slapd[6319]: conn=1013 op=1 BIND dn="cn=admin,cn=config" method=128 Dez 15 10:37:56 ldap04 slapd[6319]: conn=1013 op=1 BIND dn="cn=admin,cn=config" mech=SIMPLE bind_ssf=0 ssf=256 Dez 15 10:37:56 ldap04 slapd[6319]: conn=1013 op=1 RESULT tag=97 err=0 qtime=0.000027 etime=0.020422 text= Dez 15 10:37:56 ldap04 slapd[6319]: conn=1013 op=2 SRCH base="cn=config" scope=2 deref=0 filter="(objectClass=*)" Dez 15 10:37:56 ldap04 slapd[6319]: conn=1013 op=2 SRCH attr=* + Dez 15 10:37:56 ldap04 slapd[6319]: conn=1013 op=2 syncprov_op_search: got a persistent search with a cookie=rid=004,sid=002,csn=20211215092402.061636Z#000000#002#000000 Dez 15 10:37:56 ldap04 slapd[6319]: conn=1013 op=2 syncprov_findbase: searching Dez 15 10:37:56 ldap04 slapd[6319]: conn=1013 op=2 syncprov_op_search: registered persistent search Dez 15 10:37:56 ldap04 slapd[6319]: conn=1013 op=2 syncprov_op_search: consumer cookie is missing a csn we track Dez 15 10:37:56 ldap04 slapd[6319]: conn=1013 op=2 syncprov_search_response: cookie=rid=004,sid=004,csn=20211215092401.968707Z#000000#001#000000;20211215092402.061636Z#000000#002#000000;20211215092402.073013Z#000000#003#000000;20211215092402.084067Z#000000#004#000000 Dez 15 10:37:56 ldap04 slapd[6319]: conn=1013 op=2 syncprov_sendinfo: refreshPresent cookie=rid=004,sid=004,csn=20211215092401.968707Z#000000#001#000000;20211215092402.061636Z#000000#002#000000;20211215092402.073013Z#000000#003#000000;20211215092402.084067Z#000000#004#000000 Dez 15 10:37:56 ldap04 slapd[6319]: conn=1013 op=2 syncprov_search_response: detaching op Dez 15 10:37:56 ldap04 slapd[6319]: conn=1013 op=3 UNBIND Dez 15 10:37:56 ldap04 slapd[6319]: conn=1013 fd=18 closed messages on consumer Dez 15 10:37:56 ldap02 slapd[6271]: do_syncrep1: rid=004 starting refresh (sending cookie=rid=004,sid=002,csn=20211215092402.061636Z#000000#002#000000) Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_message_to_entry: rid=004 DN: cn=config, UUID: 5d4870f0-f1d0-103b-92fc-1b7679847168 Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) csn=(none) tid 0x7f0589699700 Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 inserted UUID 5d4870f0-f1d0-103b-92fc-1b7679847168 Dez 15 10:37:56 ldap02 slapd[6271]: dn_callback : entries have identical CSN cn=config 20211215085439.318447Z#000000#004#000000 Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 be_search (0) Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 cn=config Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 entry unchanged, ignored (cn=config) Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_message_to_entry: rid=004 DN: cn=module{0},cn=config, UUID: 5d487b22-f1d0-103b-92fe-1b7679847168 Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) csn=(none) tid 0x7f0589699700 Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 inserted UUID 5d487b22-f1d0-103b-92fe-1b7679847168 Dez 15 10:37:56 ldap02 slapd[6271]: dn_callback : entries have identical CSN cn=module{0},cn=config 20211215085432.145148Z#000000#000#000000 Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 be_search (0) Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 cn=module{0},cn=config Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 entry unchanged, ignored (cn=module{0},cn=config) Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_message_to_entry: rid=004 DN: cn=schema,cn=config, UUID: 5d4877bc-f1d0-103b-92fd-1b7679847168 Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) csn=(none) tid 0x7f0589699700 Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 inserted UUID 5d4877bc-f1d0-103b-92fd-1b7679847168 Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 be_search (0) Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 cn=schema,cn=config Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 be_add cn=schema,cn=config (0) Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_message_to_entry: rid=004 DN: cn={0}core,cn=schema,cn=config, UUID: 5d48abc4-f1d0-103b-92ff-1b7679847168 Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) csn=(none) tid 0x7f0589699700 Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 inserted UUID 5d48abc4-f1d0-103b-92ff-1b7679847168 Dez 15 10:37:56 ldap02 slapd[6271]: dn_callback : entries have identical CSN cn={0}core,cn=schema,cn=config 20211215085432.146392Z#000000#000#000000 Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 be_search (0) Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 cn={0}core,cn=schema,cn=config Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 entry unchanged, ignored (cn={0}core,cn=schema,cn=config) Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_message_to_entry: rid=004 DN: cn={1}cosine,cn=schema,cn=config, UUID: 5d48c23a-f1d0-103b-9300-1b7679847168 Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) csn=(none) tid 0x7f0589699700 Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 inserted UUID 5d48c23a-f1d0-103b-9300-1b7679847168 Dez 15 10:37:56 ldap02 slapd[6271]: dn_callback : entries have identical CSN cn={1}cosine,cn=schema,cn=config 20211215085432.146967Z#000000#000#000000 Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 be_search (0) Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 cn={1}cosine,cn=schema,cn=config Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 entry unchanged, ignored (cn={1}cosine,cn=schema,cn=config) Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_message_to_entry: rid=004 DN: cn={2}nis,cn=schema,cn=config, UUID: 5d48d1b2-f1d0-103b-9301-1b7679847168 Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) csn=(none) tid 0x7f0589699700 Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 inserted UUID 5d48d1b2-f1d0-103b-9301-1b7679847168 Dez 15 10:37:56 ldap02 slapd[6271]: dn_callback : entries have identical CSN cn={2}nis,cn=schema,cn=config 20211215085432.147363Z#000000#000#000000 Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 be_search (0) Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 cn={2}nis,cn=schema,cn=config Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 entry unchanged, ignored (cn={2}nis,cn=schema,cn=config) Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_message_to_entry: rid=004 DN: cn={3}inetorgperson,cn=schema,cn=config, UUID: 5d48dbc6-f1d0-103b-9302-1b7679847168 Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) csn=(none) tid 0x7f0589699700 Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 inserted UUID 5d48dbc6-f1d0-103b-9302-1b7679847168 Dez 15 10:37:56 ldap02 slapd[6271]: dn_callback : entries have identical CSN cn={3}inetorgperson,cn=schema,cn=config 20211215085432.147621Z#000000#000#000000 Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 be_search (0) Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 cn={3}inetorgperson,cn=schema,cn=config Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 entry unchanged, ignored (cn={3}inetorgperson,cn=schema,cn=config) Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_message_to_entry: rid=004 DN: cn={4}dyngroup,cn=schema,cn=config, UUID: 5d48e152-f1d0-103b-9303-1b7679847168 Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) csn=(none) tid 0x7f0589699700 Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 inserted UUID 5d48e152-f1d0-103b-9303-1b7679847168 Dez 15 10:37:56 ldap02 slapd[6271]: dn_callback : entries have identical CSN cn={4}dyngroup,cn=schema,cn=config 20211215085432.147763Z#000000#000#000000 Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 be_search (0) Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 cn={4}dyngroup,cn=schema,cn=config Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 entry unchanged, ignored (cn={4}dyngroup,cn=schema,cn=config) Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_message_to_entry: rid=004 DN: cn={5}kerberos,cn=schema,cn=config, UUID: 5d48e79c-f1d0-103b-9304-1b7679847168 Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) csn=(none) tid 0x7f0589699700 Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 inserted UUID 5d48e79c-f1d0-103b-9304-1b7679847168 Dez 15 10:37:56 ldap02 slapd[6271]: dn_callback : entries have identical CSN cn={5}kerberos,cn=schema,cn=config 20211215085432.147924Z#000000#000#000000 Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 be_search (0) Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 cn={5}kerberos,cn=schema,cn=config Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 entry unchanged, ignored (cn={5}kerberos,cn=schema,cn=config) Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_message_to_entry: rid=004 DN: olcDatabase={-1}frontend,cn=config, UUID: 5d48f458-f1d0-103b-9305-1b7679847168 Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) csn=(none) tid 0x7f0589699700 Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 inserted UUID 5d48f458-f1d0-103b-9305-1b7679847168 Dez 15 10:37:56 ldap02 slapd[6271]: dn_callback : entries have identical CSN olcDatabase={-1}frontend,cn=config 20211215085432.148251Z#000000#000#000000 Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 be_search (0) Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 olcDatabase={-1}frontend,cn=config Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 entry unchanged, ignored (olcDatabase={-1}frontend,cn=config) Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_message_to_entry: rid=004 DN: olcDatabase={0}config,cn=config, UUID: 5d48f7aa-f1d0-103b-9306-1b7679847168 Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) csn=(none) tid 0x7f0589699700 Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 inserted UUID 5d48f7aa-f1d0-103b-9306-1b7679847168 Dez 15 10:37:56 ldap02 slapd[6271]: dn_callback : entries have identical CSN olcDatabase={0}config,cn=config 20211215092402.084067Z#000000#004#000000 Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 be_search (0) Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 olcDatabase={0}config,cn=config Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 entry unchanged, ignored (olcDatabase={0}config,cn=config) Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_message_to_entry: rid=004 DN: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config, UUID: 7c3fa65a-f1d4-103b-983d-81584f1425b7 Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) csn=(none) tid 0x7f0589699700 Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 inserted UUID 7c3fa65a-f1d4-103b-983d-81584f1425b7 Dez 15 10:37:56 ldap02 slapd[6271]: dn_callback : entries have identical CSN olcOverlay={0}syncprov,olcDatabase={0}config,cn=config 20211215092402.083542Z#000000#004#000000 Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 be_search (0) Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 olcOverlay={0}syncprov,olcDatabase={0}config,cn=config Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 entry unchanged, ignored (olcOverlay={0}syncprov,olcDatabase={0}config,cn=config) Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_message_to_entry: rid=004 DN: olcDatabase={1}monitor,cn=config, UUID: 5d48fa48-f1d0-103b-9307-1b7679847168 Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) csn=(none) tid 0x7f0589699700 Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 inserted UUID 5d48fa48-f1d0-103b-9307-1b7679847168 Dez 15 10:37:56 ldap02 slapd[6271]: dn_callback : entries have identical CSN olcDatabase={1}monitor,cn=config 20211215085432.148402Z#000000#000#000000 Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 be_search (0) Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 olcDatabase={1}monitor,cn=config Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 entry unchanged, ignored (olcDatabase={1}monitor,cn=config) Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_message_to_entry: rid=004 DN: olcDatabase={2}mdb,cn=config, UUID: 5d48fd0e-f1d0-103b-9308-1b7679847168 Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) csn=(none) tid 0x7f0589699700 Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 inserted UUID 5d48fd0e-f1d0-103b-9308-1b7679847168 Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 be_search (0) Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 olcDatabase={2}mdb,cn=config Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 be_add olcDatabase={2}mdb,cn=config (68) Dez 15 10:37:56 ldap02 slapd[6271]: conn=-1 op=0 syncprov_matchops: recording uuid for dn=olcDatabase={2}mdb,cn=config on opc=0x7ef1740062c0 Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_null_callback : error code 0x35 Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 be_modify olcDatabase={2}mdb,cn=config (53) Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 be_modify failed (53) Dez 15 10:37:56 ldap02 slapd[6271]: do_syncrepl: rid=004 rc 53 retrying (18 retries left) ----------------- A change with ldapmodify is only changing the cn=config on the server I did the ldapmodify. All other servers do not see anything, no message in the log. All systems are Debian 11 with symas packages 2.6.0-5. -- You are receiving this mail because: You are on the CC list for the issue.

1 24

[Issue 9761] New: Inserting olcSyncrepl into a given index inserts at the end
by openldap-its＠openldap.org 20 Jan '22

20 Jan '22

https://bugs.openldap.org/show_bug.cgi?id=9761 Issue ID: 9761 Summary: Inserting olcSyncrepl into a given index inserts at the end Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- olcSyncrepl is marked "X-ORDERED 'VALUES'" but add_syncrepl() always adds the new value at the end of the list. This breaks value deletes. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

← Newer
1
...
6
7
8
9
10
11
12
13
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs December 2021