https://bugs.openldap.org/show_bug.cgi?id=9642
Issue ID: 9642
Summary: Adding a task to runqueue doesn't wake the main thread
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: ---
If a connection adds a new syncrepl stanza, that is not started until the main
thread comes around to doing it. However if that thread is currently stuck in
SLAP_EVENT_WAIT() and nothing else happens (like an unbind over the connection
that modified the config), the task is never started. This can take a long
time.
No idea yet how to wake it up with/from ldap_pvt_runqueue_insert() given that
sits within libldap and not really something that should be calling
slap_wake_listener().
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9468
Issue ID: 9468
Summary: slapd-ldap does anonymous bind even if rebind-as-user
is set
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: tero.saarni(a)est.tech
Target Milestone: ---
When back-ldap retries bind operation after connection retry, it will do it as
anonymous even if rebind-as-user is set to yes.
Expected behavior is that (re)bind is done with user's credentials from the
initial bind operation.
I observed following (Warning: I might have understood details of the code
incorrectly):
When rebind-as-user is set and bind operation from client is processed, proxy
will copy the credentials to ldapconn_t representing the remote LDAP
connection. When remote LDAP connection is closed (e.g. by the proxy itself due
to timeout), the bind credentials information is lost when freeing the old
ldapconn_t. At this point, client still holds the connection to proxy and is
unaware of the remote connection being lost. Proxy then re-establishes the
connection and "synthetically" generates new bind itself, but since it does not
have the credentials stored in memory anymore, it sends anonymous bind on
behalf of the client.
As a side effect, slapd currently crashes if remote server does not allow
anonymous bind and responds with InvalidCredentials instead. The crash is due
to assert(), which is handled in separate issue
https://bugs.openldap.org/show_bug.cgi?id=9288
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9799
Issue ID: 9799
Summary: Clearing pending ops on Bind
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: ---
When slapd receives some operations before it has started processing a queued
bind, those get added into conn->c_ops_pending and c_n_pending_ops is updated
accordingly.
Bind then eventually invokes connection_abandon() which forgets to zero out
c_n_pending_ops and the connection remains unusable forever.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9385
Issue ID: 9385
Summary: Opening an env with MDB_NOSUBDIR with no existing file
returns error
Product: LMDB
Version: unspecified
Hardware: All
OS: Mac OS
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: kriszyp(a)gmail.com
Target Milestone: ---
Created attachment 776
--> https://bugs.openldap.org/attachment.cgi?id=776&action=edit
A fix to tolerate stat call on non-existing file
Calling mdb_env_open with a file path to a file that doesn't exist yet, with
MDB_NOSUBDIR on a non-Windows OS will return an error indicating that the file
doesn't exist. This is supposed to create a new file, and works properly on the
mdb.master branch, and still functions properly on Windows. The error is due to
the stat() call in mdb_env_open prior to the file existing.
I attached a patch that tolerates the absence of the file before checking if
the file is on a block device. I am not sure if this is the appropriate fix, or
if would be better to move this check later in mdb_env_open after the file is
created, or alternately, determining the parent directory and calling stat on
that.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9702
Issue ID: 9702
Summary: slapadd is missing -r chroot option
Product: OpenLDAP
Version: 2.5.7
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: dpa-openldap(a)aegee.org
Target Milestone: ---
I want to run slapd under chroot with the -r option. In order to initialize
the setup, I want to use `slapadd -n0 configuration.ldif`. The configuration
file contains mdb databases and these databases have `olcDbDirectory: ` paths.
Since slapd will load the databases from the chroot environment, the directory
names must be submitted to slapadd to be correct in the chroot environment.
This means, that outside the chroot environment the directory paths are not
correct.
When I call `slapadd -n0 ` I get the error
olcDbDirectory: value #0: invalid path: No such file or directory
slapadd: could not add entry dn="olcDatabase={1}mdb,cn=config" (line=909):
Closing DB...
which means, that slapadd cannot open (outside the chrooted environment) the
olcDbDirectory path. Thus slapadd shall first enter the chrooted environment,
but it lacks option for this. Probably slapcat will also need this option to
dump the databases.
The chrooted environment is created specially for openldap, so it contains no
tools.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9745
Issue ID: 9745
Summary: Local Logging - Timestamp Formatting
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: gnoe(a)symas.com
Target Milestone: ---
Timestamps for log lines in the 2.6+ local logging feature are saved
unformatted (ex: "618ae741.0f6eb63a"). This has the potential to break any log
aggregation/analysis program like splunk that expect timestamps in syslog
format.
These timestamps should configurable in various syslog formats.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9403
Issue ID: 9403
Summary: add option to completely disable syslog logging
Product: OpenLDAP
Version: 2.4.45
Hardware: All
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: cvuillemez(a)yahoo.fr
Target Milestone: ---
For auditing purpose, I need to enable "stats" loglevel.
So on heavy load, slapd send lots of events to local syslog socket /dev/log,
when compiled with LDAP_SYSLOG (on Debian / Ubuntu).
It worked fine on old systems with a simple syslog service.
But when upgrading on system with journald+syslog, CPU "overhead" becomes
totally crazy.
It would be great to have an option at run time to completely disable syslog
logging, or/and use a cutom socket, e.g. /run/systemd/journal/syslog to bypass
journald service.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9830
Issue ID: 9830
Summary: slapd using more memory on linux kernel 5.xx then
kernel 4.19
Product: OpenLDAP
Version: 2.4.59
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: pavel.mamonov(a)wildix.com
Target Milestone: ---
Hi, there
After upgrade a debian distro from 10 to 11 we are faced with consumption of
memory more then before. We testing on the same system with different kernels.
========================================
System with a kernel 4.19:
using of memory (slapd) ~ 100-120mb (max)
slapd 2.4.59
libc6:amd64 2.31-13+deb11u2
linux-image-4.19.0-14-cloud-amd64 4.19.171-2
========================================
System with a kernel 5.10:
using of memory (slapd) ~ 135-235mb (max)
slapd 2.4.59
libc6:amd64 2.31-13+deb11u2
linux-image-5.10.0-10-cloud-amd64 5.10.84-1
========================================
Also we tried to use other allocator of memory like "libtcmalloc-minimal4:amd64
2.8.1-1" - but, unfortunately, it does not help us.
Could you give advice what we can do for optimize memory and reduction using of
it ?
If need additional info please, let me know.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9675
Issue ID: 9675
Summary: Allow overwriting the default SLAPD_DEFAULT_CONFIGDIR
during ./configure
Product: OpenLDAP
Version: 2.5.7
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: dpa-openldap(a)aegee.org
Target Milestone: ---
Created attachment 839
--> https://bugs.openldap.org/attachment.cgi?id=839&action=edit
fix
I want to have different default for SLAPD_DEFAULT_CONFIGDIR in my slapd.
By calling
CPPFLAGS="-DSLAPD_DEFAULT_CONFIGDIR='\"/new/config/dir/\"'" ./configure
one can change the default configdir in slapd. Provided that the macro
SLAPD_DEFAULT_CONFIGDIR is not changed in the code, which is ensured by the
provided patch.
Macro SLAPD_DEFAULT_UCDATA is not used anywhere.
--
You are receiving this mail because:
You are on the CC list for the issue.