https://bugs.openldap.org/show_bug.cgi?id=10284
Issue ID: 10284
Summary: RFE: retain subordinate entries to
cn=connections,cn=monitor branch for a configurable
duration
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: chris.paul(a)rexconsulting.net
Target Milestone: ---
Please consider an enhancement to retain entries under the
cn=connections,cn=monitor branch for a configurable duration. This would enable
monitoring of short-lived connections that currently disappear between polling
intervals, significantly increasing the utility of this metric for connection
tracking.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10106
Issue ID: 10106
Summary: Add organization to web list of OpenLDAP support
providers
Product: website
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: website
Assignee: bugs(a)openldap.org
Reporter: sudo(a)migrateq.io
Target Milestone: ---
Hello! This request is being opened as suggested by Quanah Gibson-Mount.
Could you please add Migrateq to your OpenLDAP Support page on
https://openldap.org/support
Company: Migrateq Inc.
Website: https://migrateq.io/support/tech/openldap
Migrateq provides migrations, integrations and advanced 24/7/365 technical
support for OpenLDAP and most Linux and Open Source Software.
Thank you =)
Richard
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10281
Issue ID: 10281
Summary: Update organization on web list of OpenLDAP support
providers
Product: website
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: website
Assignee: bugs(a)openldap.org
Reporter: sudo(a)migrateq.io
Target Milestone: ---
Hello, this OpenLDAP support provider on the OpenLDAP support page, Migrateq,
has recently changed their name to "Linux Pro", and kindly request an update:
Company: Linux Pro
Website: https://linux.pro/support/tech/openldap
Linux Pro provides migrations, integrations and advanced 24/7/365 technical
support for OpenLDAP and most Linux and Open Source Software.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10141
Issue ID: 10141
Summary: 100% CPU consumption with ldap_int_tls_connect
Product: OpenLDAP
Version: 2.6.3
Hardware: Other
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: vivekanand754(a)gmail.com
Target Milestone: ---
While doing secure ldap connection, i'm seeing that connection is getting stuck
in read block in case it is unable to connect active directory sometime:
~ # strace -p 15049
strace: Process 15049 attached
read(3, 0x55ef720bda53, 5) = -1 EAGAIN (Resource temporarily
unavailable)
read(3, 0x55ef720bda53, 5) = -1 EAGAIN (Resource temporarily
unavailable)
.. ..
.. ..
After putting some logs, I can see that "ldap_int_tls_start" function of
"openldap-2.6.3/libraries/libldap/tls2.c" calls "ldap_int_tls_connect" in while
loop.
It seems to be blocking call, as it try to connect continuously until it get
connected(ti_session_connect returns 0) and thus consumes 100% CPU during that
time.
Is there any known issue ?
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8047
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |vivekanand.devworks(a)gmail.c
| |om
--- Comment #16 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
*** Issue 10141 has been marked as a duplicate of this issue. ***
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8047
--- Comment #15 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
RE26:
• 5645e370
by Ondřej Kuzník at 2024-11-12T17:55:56+00:00
ITS#8047 Fix TLS connection timeout handling
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10155
Issue ID: 10155
Summary: Invalid [aka FUZZ] -F and -T options can core dump
ldapsearch
Product: OpenLDAP
Version: 2.6.6
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: client tools
Assignee: bugs(a)openldap.org
Reporter: doug.leavitt(a)oracle.com
Target Milestone: ---
A customer reported core dumps in ldapsearch which has been tracked
to the the improper use of the -F and -T options.
The customer confirmed removing the invalid -F and -T options
from their script eliminated the core dumps.
The CLI arguments of the failing ldapsearch look like:
ldapsearch <good CLI args> -F , -T u <good filter and attr args>
The good CLI args include proper uses of -H... -x -D ... -w ... -b ... -s ...
The good filter and attrs are also valid CLI inputs.
The "bad" args are <sp>-F<sp><COMMA><sp>-T<sp>-u<sp>
The -u is also valid but it is consumed as a directory name of -T
From man page and code review the the -F argument is supposed to be
a valid URL. and the -T argument is supposed to be a valid directory
The core file output indicates that main calls free
after the search takes place. The location is believed to be
here:
1658 if ( urlpre != NULL ) {
1659 if ( def_urlpre != urlpre )
1660 free( def_urlpre ); <---------
1661 free( urlpre );
1662 }
...
1672 tool_exit( ld, rc );
...
This is the first example of the use of -F we have seen
so it is unclear how this should be fixed.
But code review of ldapsearch.c and common.c exposed a few
weaknesses that could help in addressing the issue.
Observed weaknesses:
The getopt processing code for -T does not check that the arg is
actually a directory and fail/error when bad input is provided.
Perhaps at least an access(2) check should be performed?
It is unclear if -F should only accept file:// URLs. The existing code
does not sufficiently check any URL format instead it processes the
argument by looking for the first '/' [no error checking] and determine
the remainder to be a tmpdir location similar to the -T argument.
So, Fuzz input of <COMMA> seems to eventually lead to the core files.
It is unclear if -F and -T should be mutually exclusive or not.
It seems like the fix to this issue is to add better error
checking and to fail on FUZZ inputs. I defer a solution
to upstream as it probably requires project direction I lack.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10263
Issue ID: 10263
Summary: ldapmodify error messages should be more helpful when
dealing with trailing whitespace
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: client tools
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
Often when copy-pasting, a trailing whitespace can sneak in to a modify LDIF
(e.g. "delete: attribute \nattribute: ..."), ldapmodify should emit a different
message than: "ldapmodify: wrong attributeType at line x" because that is just
not helpful.
First off, the line number refers to the one that's usually correct. Emitting
an "expecting '%s'" would be a start. Maybe we should even warn/error when an
attribute name in a change record contains whitespace, because it's not valid
as RFC 2849 grammar only allows ALPHA/DIGIT/'-'/'.'/';' anyway.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10264
Issue ID: 10264
Summary: libpdap leaks dummy_lr data on NoD processing
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
When a NoD unsolicited response is being processed in try_read1msg, we use the
dummy_lr on stack, but data copied onto it is never freed, so we leak it as we
return.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8047
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|IN_PROGRESS |RESOLVED
--- Comment #14 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
head:
• d143f7a2
by Ondřej Kuzník at 2024-10-26T20:51:35+00:00
ITS#8047 Fix TLS connection timeout handling
--
You are receiving this mail because:
You are on the CC list for the issue.