https://bugs.openldap.org/show_bug.cgi?id=10414
Issue ID: 10414
Summary: slapadd/modify adding a new entry to cn=config tries
to re-add frontend
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: ---
The tool API does not know that the frontend entry was already present so it
tries and fails to add it.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10413
Issue ID: 10413
Summary: Consumer prepares cookie too early
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: ---
A consumer prepares its cookie at the moment its task is started (in
do_syncrep1), then calls ldap_sync_search, but this is where we can figure out
if there's another refresh running already and suspend the task. When that
other refresh finishes and tells another one to resume, we just call
ldap_sync_search so keep the old cookie rather than update it to match what we
now know.
This doesn't affect correctness but forces the other provider(s) to reiterate
something the consumer already knows, this can be very expensive for both.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10258
Issue ID: 10258
Summary: test050 failure: connection_close race?
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: ---
Created attachment 1032
--> https://bugs.openldap.org/attachment.cgi?id=1032&action=edit
tail of slapd log
Running test050 repeatedly, the slapd managed to get itself into an apparent
inconsistency in the connections structure. The logs suggest that there might
be a race closing the connection. Unfortunately the sanitiser didn't initiate a
core dump in this case.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10307
Issue ID: 10307
Summary: Regression when searching for nonexistent entries and
no access to DB
Product: OpenLDAP
Version: 2.5.17
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: ---
Patch incoming
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9244
Bug ID: 9244
Summary: API calls blocking after async connect
Product: OpenLDAP
Version: 2.4.49
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: ryan(a)openldap.org
Target Milestone: ---
Created attachment 721
--> https://bugs.openldap.org/attachment.cgi?id=721&action=edit
async connect test without TLS
My understanding of LDAP_OPT_CONNECT_ASYNC is that the attached program should
not block. If the connection does not establish fast enough, the bind call is
supposed to return LDAP_X_CONNECTING.
(At least that's how I understand it, based on the original behaviour (circa
2.4.23 up to 2.4.40) as well as the bind loop in back-meta. On the other hand,
the man page does "Subsequent calls to library routines will poll for
completion of the connect before performing further operations" which might be
interpreted as meaning they would block...)
In current releases it does block, as demonstrated by strace on Linux (latency
added using 'tc qdisc'):
[...]
connect(3, {sa_family=AF_INET, sin_port=htons(389),
sin_addr=inet_addr("192.168.1.204")}, 16) = -1 EINPROGRESS (Operation now in
progress)
write(3, "0\f\2\1\1`\7\2\1\3\4\0\200\0", 14) = -1 EAGAIN (Resource temporarily
unavailable)
poll([{fd=3, events=POLLOUT|POLLERR|POLLHUP}], 1, -1) = 1 ([{fd=3,
revents=POLLOUT}])
write(3, "0\f\2\1\1`\7\2\1\3\4\0\200\0", 14) = 14
poll([{fd=3, events=POLLIN|POLLPRI}], 1, -1) = 1 ([{fd=3, revents=POLLIN}])
read(3, "0\f\2\1\1a\7\n", 8) = 8
read(3, "\1\0\4\0\4\0", 6) = 6
write(2, "OK: ldap_simple_bind_returned 0 "..., 42OK: ldap_simple_bind_returned
0 (Success)
) = 42
[...]
As discussed in IRC, I believe I bisected this down to commit ae6347bac, from
bug 8022. The reasoning is sound, but ldap_int_open_connection does not
actually return -2, only -1 or 0.
The patch is simple enough, but I'm also looking at some later commits that
were probably done to work around this, and might not be needed now (bug 8957,
bug 8968, bug 8980). Also need to test all setups thoroughly (ldap, ldaps,
STARTTLS, not to mention back-meta/asyncmeta).
I also notice that LDAP_OPT_CONNECT_ASYNC is not effective unless
LDAP_OPT_NETWORK_TIMEOUT is also set. It might be intentional, but the man page
doesn't mention this specifically, and I don't see why it would be necessary...
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9886
Issue ID: 9886
Summary: At "sync" logging, nothing shows how long a write op
took on consumers
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
If sync logging is enabled on a consumer, there's no etime logged which means
it is not possible to see how long a write op took on that consumer. This can
be useful information to see how the node is performing, particularly if it is
a read only node where there will be no general MOD timing logged.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10293
Issue ID: 10293
Summary: Log operations generated by syncrepl at STATS level
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: nivanova(a)symas.com
Target Milestone: ---
Similarly to how incoming operations are logged, operations created by syncrepl
should be logged as well.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10368
Issue ID: 10368
Summary: Must revert ITS#9849 license changes
Product: website
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: major
Priority: ---
Component: website
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
The changes related to license.wml made for ITS#9849 must be reverted. There is
only one OpenLDAP Public License and it applies to all OpenLDAP software. There
are not two different licenses for release/LTS. No single person has the right
to alter the existing license.
Currently the website is broken, as
https://openldap.org/software/release/license.html is an empty file.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10364
Issue ID: 10364
Summary: back-asyncmeta should process a notice-of-disconnect
and close the target connection
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: nivanova(a)symas.com
Target Milestone: ---
At present, back-asyncmeta discards all unsolicited messages, received on the
target connections. It should instead process Notice-of-Disconnection messages
and close the connections on which they were received.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10337
Issue ID: 10337
Summary: Global TLS options not inherited in context
Product: OpenLDAP
Version: 2.6.9
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: remi(a)fedoraproject.org
Target Milestone: ---
During ldap_create, global options are copied
See
https://github.com/openldap/openldap/blob/OPENLDAP_REL_ENG_2_6_9/libraries/…
/* copy the global options */
AC_MEMCPY(&ld->ld_options, gopts, sizeof(ld->ld_options));
But not the TLS string options
See
https://github.com/openldap/openldap/blob/OPENLDAP_REL_ENG_2_6_9/libraries/…
/* We explicitly inherit the SSL_CTX, don't need the names/paths. Leave
* them empty to allow new SSL_CTX's to be created from scratch.
*/
memset( &ld->ld_options.ldo_tls_info, 0,
sizeof( ld->ld_options.ldo_tls_info ));
ld->ld_options.ldo_tls_ctx = NULL;
Which create inconsistency when trying to generate a newctx
For the context
See
* https://github.com/php/php-src/issues/17776 => why tls_newctx is needed
* https://github.com/php/php-src/issues/18529 => regression
On PHP side a possible workaround is to do the copyu manually
* https://github.com/php/php-src/pull/18547
But should probably be handled at openldap library
--
You are receiving this mail because:
You are on the CC list for the issue.