https://bugs.openldap.org/show_bug.cgi?id=9584
Issue ID: 9584
Summary: cn=config replication ops/refresh should pause server
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: ---
Looking into this crash: https://git.openldap.org/openldap/openldap/-/jobs/7286
The thread in question is running a plain syncrepl refresh while another thread
seems to have done the same. This thread fetched the entryUUID attribute of the
'cn=config' entry as 'a' and in the meantime, that entry has been rewritten,
with 'a' presumably cleaned up and returned to the pool, so addressing
a->a_nvals[0] is a NULL-dereference now.
This might or might not be related to the fix in ITS#8102.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9620
Issue ID: 9620
Summary: back-monitor: search can access a persistent entry
freed in the meantime
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
With ITS#9600 there is now code that adds and removes "persistent" monitor
entries outside a server pause. A concurrent cn=monitor search lists all
children first and sends them later - monitor is happy to free some of them in
the meantime.
It seems to me that the monitor cache should be protected by a rw mutex
instead, which would be held for reading while a search is happening.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9497
Issue ID: 9497
Summary: back-ldif: test022-ppolicy failure
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: hamano(a)osstech.co.jp
Target Milestone: ---
The test022-ppolicy with back-ldif fail for two issue.
1. too short pwdMaxAge
~~~
$ ./run -b ldif test022-ppolicy
(snip)
Testing password expiration
Waiting seconds for password to expire...
sleep: missing operand
Try 'sleep --help' for more information.
Password expiration test failed
~~~
The script tries test for lockout and then a test for password expiration.
It will fail if the password has expired(pwdMaxAge: 30) by the time it starts
the password expiration test.
This is a timing issue and not directly caused by back-ldif.
However, the issue is reproduced only with back-ldif in my environment.
This test passed in my environment by extending pwdMaxAge by 5 seconds, but
there may be a better way.
2. duplicate ldap control response
~~~
Reconfiguring policy to remove grace logins...
Clearing forced reset...
expr: syntax error: unexpected argument '15'
Testing password expiration
Waiting seconds for password to expire...
sleep: missing operand
Try 'sleep --help' for more information.
~~~
This is back-ldif issue.
back-ldif responds duplicate ldap control response.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9256
Bug ID: 9256
Summary: The ACLs required for SASL binding are not fully
documented
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: documentation
Assignee: bugs(a)openldap.org
Reporter: kop(a)karlpinc.com
Target Milestone: ---
Created attachment 727
--> https://bugs.openldap.org/attachment.cgi?id=727&action=edit
Patch massaging the SASL binding requirement docs
While some ACL requirements for SASL binding are documented, some are not.
E.g, that olcAuthzRegexp requires =x on objectClass when direct DN mapping is
not documented. Other requirements can be reasoned out based on the existing
documentation, but this can be very difficult when unfamiliar with all the
moving parts and the places they are documented. E.g. knowing that
(objectClass=*) is the default filter, and that there's _always_ _some_ filter,
and connecting this with ACLs required to do search-based SASL mapping.
The attached patch brings all the SASL binding requirements together in one
place in the docs and makes everything explicit. The word "SASL" is included,
for those searching for that keyword.
I, Karl O. Pinc, hereby place the following modifications to OpenLDAP Software
(and only these modifications) into the public domain. Hence, these
modifications may be freely used and/or redistributed for any purpose with or
without attribution and/or other notice.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9502
Issue ID: 9502
Summary: Implement TCP_USER_TIMEOUT in meta and asyncmeta
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: nivanova(a)symas.com
Target Milestone: ---
Implement TCP_USER_TIMEOUT as an option to libldap and as a configuration
option in back-meta and back-asyncmeta
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9189
Bug ID: 9189
Summary: Add GSSAPI channel-bindings support
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: iboukris(a)gmail.com
Target Milestone: ---
Recently MS has announce they plan to enforce channel-bindings for LDAP over
TLS (ADV190023).
To support it on client side, we need to pass "tls-endpoint" bindings (RFC
5929) to the SASL plugin, and make use of that in GSSAPI.
See also:
https://github.com/cyrusimap/cyrus-sasl/pull/601
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9350
Issue ID: 9350
Summary: Expand test suite for null base
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Currently we have no tests that use the empty suffix (null base).
This is an entirely valid configuration setup, and there are unique challenges
and bugs that crop up with this usage.
We need to ensure we're covering this use case, particularly with syncrepl and
delta-syncrepl configurations.
--
You are receiving this mail because:
You are on the CC list for the issue.
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.
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.
https://bugs.openldap.org/show_bug.cgi?id=9707
Issue ID: 9707
Summary: Documentation synchronisation ODSEE --> openldap
Product: OpenLDAP
Version: 2.5.4
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: documentation
Assignee: bugs(a)openldap.org
Reporter: laurent.revillion(a)icloud.com
Target Milestone: ---
There is no documentation about the synchronisation between ODSEE and Openldap
2.5.
Will there be one?
--
You are receiving this mail because:
You are on the CC list for the issue.