openldap-bugs November 2021

openldap-bugs@openldap.org

1 participants
113 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 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 9751] New: Delta-MPR resolution too eager to drop attribute deletes
by openldap-its＠openldap.org 20 Jan '22

20 Jan '22

https://bugs.openldap.org/show_bug.cgi?id=9751 Issue ID: 9751 Summary: Delta-MPR resolution too eager to drop attribute deletes Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review, replication Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- syncrepl_resolve_cb will completely drop an attribute delete (or the delete part of replace) if there's a "newer" (timestamp-wise) op touching the same attribute. This way servers processing the "out of order" write end up keeping values that should have been removed (and have been on those that received it in the natural order). -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9756] New: syncprov_play_accesslog doesn't check minCSN properly
by openldap-its＠openldap.org 20 Jan '22

20 Jan '22

https://bugs.openldap.org/show_bug.cgi?id=9756 Issue ID: 9756 Summary: syncprov_play_accesslog doesn't check minCSN properly 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: --- When asked to replay the accesslog database for a refresh delete, syncprov doesn't interpret the minCSN data correctly, resulting in: - an inaccurate refresh if a purge removed some important data in the meantime - potentially a very expensive query when consumer is actually up to date w.r.t. to some sids in our contextCSN -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9752] New: Improperly normalized minCSN values in accesslog
by openldap-its＠openldap.org 20 Jan '22

20 Jan '22

https://bugs.openldap.org/show_bug.cgi?id=9752 Issue ID: 9752 Summary: Improperly normalized minCSN values in accesslog Product: OpenLDAP Version: 2.5.9 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- The CSN matching rules require normalized values to be provided. When normalized values are provided to attr_merge they must be distinct from the regular values. accesslog.c:1982 is providing the same berval in both regular and normalized value, which triggers an assert failure for this consistency check. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs November 2021