[Issue 9343] New: Expand ppolicy policy configuration to allow URL filter
by openldap-its@openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9343
Issue ID: 9343
Summary: Expand ppolicy policy configuration to allow URL
filter
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Currently, ppolicy only supports a single global default policy, and past that
any policies must be manually added to a given user entry if they are supposed
to have something other than the default policy.
Also, some sites want no default policy, and only a specific subset to have a
policy applied to them.
For both of these cases, it would be helpful if it were possible to configure a
policy to apply to a set of users via a URL similar to the way we handle
creating groups of users in dynlist
--
You are receiving this mail because:
You are on the CC list for the issue.
2 months, 2 weeks
[Issue 9365] New: Mem leaks with Æ-DIR providers
by openldap-its@openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9365
Issue ID: 9365
Summary: Mem leaks with Æ-DIR providers
Product: OpenLDAP
Version: 2.4.53
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: michael(a)stroeder.com
Target Milestone: ---
Created attachment 772
--> https://bugs.openldap.org/attachment.cgi?id=772&action=edit
valgrind output on openSUSE Tumbleweed x86_64
An Æ-DIR installation with self-compiled OpenLDAP 2.4.53 on Debian (now
buster) has memory leak issues on the Æ-DIR providers. The read-only
consumers do not have this issue. The provider config is more complex
with more overlays and more ACLs.
In this production deployment slapd is automatically restarted (by monit) when
memory consumption reaches 80%. Thus monitoring clearly shows a frequent saw
tooth pattern.
I've also tested on openSUSE Tumbleweed x86_64 with a RE24 build [1] by running
slapd under control of valgrind for a couple of minutes continously sending
simple bind operations (additional to the monitoring and other back-ground jobs
running).
Find valgrind output of my first attempt attached.
Does that make sense at all?
--
You are receiving this mail because:
You are on the CC list for the issue.
5 months, 3 weeks
[Issue 9339] New: Add syncrepl status in cn=monitor
by openldap-its@openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9339
Issue ID: 9339
Summary: Add syncrepl status in cn=monitor
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
Patch coming to expose some consumer state in cn=monitor
Sample entry:
# Consumer 001, database 2, databases, monitor
dn: cn=Consumer 001,cn=database 2,cn=databases,cn=monitor
objectClass: olmSyncReplInstance
structuralObjectClass: olmSyncReplInstance
cn: Consumer 001
creatorsName:
modifiersName:
createTimestamp: 20200906160447Z
modifyTimestamp: 20200906160447Z
olmSRProviderURIList: ldap://localhost:9011/
olmSRIsConnected: TRUE
olmSRSyncPhase: Persist
olmSRLastConnect: 20200906160448Z
olmSRLastContact: 20200906160453Z
olmSRLastCookieRcvd: rid=001,sid=001,csn=20200906160453.039573Z#000000#001#000
000
olmSRLastCookieSent: rid=001,sid=002,csn=20200906160447.723677Z#000000#001#000
000
entryDN: cn=Consumer 001,cn=database 2,cn=databases,cn=monitor
subschemaSubentry: cn=Subschema
hasSubordinates: FALSE
--
You are receiving this mail because:
You are on the CC list for the issue.
6 months, 2 weeks
[Issue 9358] New: back-mdb may return accesslog entries out of order
by openldap-its@openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9358
Issue ID: 9358
Summary: back-mdb may return accesslog entries out of order
Product: OpenLDAP
Version: 2.4.53
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
back-mdb will usually return search entries in entryID order, but may do a dn
traversal instead if the count of children is smaller than the count of search
filter candidates. The RDNs are sorted in length order, not lexical order. For
accesslog, all RDNs are of equal length but if they have trailing zeroes, the
generalizedTime normalizer truncates them. Changing their lengths causes
accesslog's timestamp-based RDNs to sort in the wrong order.
The least intrusive fix is to override the syntax/normalizer for reqStart and
reqEnd attributes to not truncate trailing zeroes.
--
You are receiving this mail because:
You are on the CC list for the issue.
6 months, 3 weeks
[Issue 9385] New: Opening an env with MDB_NOSUBDIR with no existing file returns error
by openldap-its@openldap.org
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.
10 months, 2 weeks
[Issue 9403] New: add option to completely disable syslog logging
by openldap-its@openldap.org
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.
10 months, 2 weeks
[Bug 9256] New: The ACLs required for SASL binding are not fully documented
by openldap-its@openldap.org
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.
1 year
[Bug 9189] New: Add GSSAPI channel-bindings support
by openldap-its@openldap.org
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.
1 year, 1 month
[Issue 9350] New: Expand test suite for null base
by openldap-its@openldap.org
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.
1 year, 1 month
[Issue 9282] New: Syncrepl re-creates deleted entry
by openldap-its@openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9282
Issue ID: 9282
Summary: Syncrepl re-creates deleted entry
Product: OpenLDAP
Version: 2.4.50
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Scenario:
2 node Multi-provider replication
Add database to provider A
ensure database replicates to provider B
Stop provider A
delete entry on provider B
Start provider A
Wait for provider B to reconnect to provider A
Deleted entry re-appears
--
You are receiving this mail because:
You are on the CC list for the issue.
1 year, 3 months