https://bugs.openldap.org/show_bug.cgi?id=9718
Issue ID: 9718
Summary: test022 can fail on expiry
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
>>>>> Starting test022-ppolicy for mdb...
running defines.sh
Starting slapd on TCP/IP port 9011...
Using ldapsearch to check that slapd is running...
Testing redundant ppolicy instance...
Using ldapadd to populate the database...
Testing account lockout...
Waiting 13 seconds for lockout to reset...
Testing password expiration
Waiting seconds for password to expire...
sleep: missing operand
Try 'sleep --help' for more information.
Password expiration test failed
>>>>> test022-ppolicy failed for mdb after 43 seconds
(exit 1)
The issue here is apparently that line 122-123 failed to populate the DELAY
variable.
121
122 DELAY=`$LDAPSEARCH -D "$MANAGERDN" -H $URI1 -w $PASSWD \
123 -b "$USER" -E accountUsability 1.1 | sed -n -e
's/.*expire=\(\d*\)/\1/p'`
124
125 echo "Testing password expiration"
126 echo "Waiting $DELAY seconds for password to expire..."
127 sleep $DELAY
128 sleep 1
--
You are receiving this mail because:
You are on the CC list for the issue.
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.
https://bugs.openldap.org/show_bug.cgi?id=9600
Issue ID: 9600
Summary: Rework lloadd's cn=monitor interface (connections)
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: lloadd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
At the moment, most of the lloadd's monitor entries are generated on demand for
the search. To support management of the server and its connections, an entry
should be created when a connection is set up and torn down accordingly.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9916
Issue ID: 9916
Summary: slapd crashes due to unaligned access in mdb.c on
Linux SPARC
Product: OpenLDAP
Version: 2.6.3
Hardware: Other
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: glaubitz(a)physik.fu-berlin.de
Target Milestone: ---
The testsuite of the openldap package in Debian unstable fails on sparc64 with
a "bus error" which indicates an unaligned access [1]:
>>>>> Test succeeded
>>>>> 00:00:02 Finished test000-rootdse for mdb after 1 seconds.
>>>>> 00:00:02 Starting test001-slapadd for mdb...
running defines.sh
Running slapadd to build slapd database...
Bus error
slapadd failed (138)!
>>>>> 00:00:03 Failed test001-slapadd for mdb after 1 seconds
(exit 138)
Building openldap from git and running the affected test with GDB results in
the following backtrace:
(gdb) bt
#0 0x00000100000cc36c in mdb_node_add (mc=0x100004316e8, indx=<optimized out>,
key=0x7feffffe570, data=0x7feffffe560, pgno=0, flags=0)
at ./../../../libraries/liblmdb/mdb.c:7358
#1 0x00000100000d0894 in mdb_cursor_put (mc=0x100004316e8, key=0x7feffffe570,
data=0x7feffffe560, flags=16) at ./../../../libraries/liblmdb/mdb.c:6960
#2 0x00000100000d1224 in mdb_cursor_put (mc=0x10000431560, key=0x7feffffe6b0,
data=0x7feffffe6c0, flags=36) at ./../../../libraries/liblmdb/mdb.c:7007
#3 0x00000100000f0d24 in mdb_dn2id_add (op=0x7feffffea28, mcp=0x10000431560,
mcd=0x100004267a0, pid=<optimized out>, nsubs=<optimized out>,
upsub=<optimized out>, e=0x1000044c6b8) at dn2id.c:141
#4 0x00000100000dd79c in mdb_tool_next_id (op=0x7feffffea28, tid=<optimized
out>, e=0x1000044c6b8, text=0x7feffffec78, hole=<optimized out>)
at tools.c:519
#5 0x00000100000de67c in mdb_tool_entry_put (be=0x100003d9080,
e=0x1000044c6b8, text=0x7feffffec78) at tools.c:731
#6 0x00000100000b72f4 in slapadd (argc=<optimized out>, argv=<optimized out>)
at slapadd.c:453
#7 0x0000010000016858 in main (argc=<optimized out>, argv=0x7fefffff438) at
main.c:540
(gdb)
This was reproduced with:
$ gdb --args /home/glaubitz/openldap/servers/slapd/slapd -Ta -d 0 -f
/home/glaubitz/openldap/tests/testrun/slapadd.conf -l
./testdata/test-ordered.ldif
On the machine gcc202 running Debian on sparc64 in the GCC compile farm. Access
to the machines in the GCC compile farm can be obtained by any developer [2].
> [1] https://buildd.debian.org/status/fetch.php?pkg=openldap&arch=sparc64&ver=2.…
> [2] https://gcc.gnu.org/wiki/CompileFarm
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9806
Issue ID: 9806
Summary: MDB_PAGE_FULL on mdb_put
Product: LMDB
Version: unspecified
Hardware: Other
OS: Mac OS
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: casey(a)rodarmor.com
Target Milestone: ---
I'm using the using latest lmdb from OpenLDAP, commit
e8813b12b6188d5ba5f174ff8726c438c8ca4bfd.
I'm getting an MDB_PAGE_FULL error after calling `mdb_put`. If I delete the
database and perform the same sequence of inserts, I get the same error in on
the same mdb_put.
If there's any information I can provide to help debug this, 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=9919
Issue ID: 9919
Summary: The use of a separate section for cold code can cause
linking issues on macOS
Product: LMDB
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: mh-bcrayqnc(a)glandium.org
Target Milestone: ---
See e.g. https://github.com/llvm/llvm-project/issues/52767
--
You are receiving this mail because:
You are on the CC list for the issue.
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.
https://bugs.openldap.org/show_bug.cgi?id=9923
Issue ID: 9923
Summary: extensible match ignored
Product: OpenLDAP
Version: 2.6.3
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: francois(a)rcdevs.com
Target Milestone: ---
Hi,
I'm trying to use a matching rule with slapd as a proxy in front of Active
Directory with back-ldap
The request is something similar to
'(memberOf:1.2.840.113556.1.4.1941:=cn=gp1,o=Root)'
It works if I use it directly on AD.
Unfortunately, the request is ignored by slapd and not forwarded, I receive a
"success" but the result is empty.
The request is forwarded if I use something like this:
'(memberOf=cn=gp1,o=Root)'
Could it be possible to forward the request to the backend? slapd doesn't need
to understand the meaning of the OID.
slapd with matching rule:
[2022-09-28 11:07:39] begin get_filter
[2022-09-28 11:07:39] EXTENSIBLE
[2022-09-28 11:07:39] daemon: activity on 1 descriptor
[2022-09-28 11:07:39] end get_filter 0
[2022-09-28 11:07:39] filter: (?=undefined)
[2022-09-28 11:07:39] attrs: dn
[2022-09-28 11:07:39] conn=1000 op=1 SRCH base="o=root" scope=2 deref=0
filter="(?=undefined)"
slapd without matching rule:
[2022-09-28 11:07:47] begin get_filter
[2022-09-28 11:07:47] EQUALITY
[2022-09-28 11:07:47] get_ava: unknown attributeType memberOf
[2022-09-28 11:07:47]
[2022-09-28 11:07:47] end get_filter 0
[2022-09-28 11:07:47] daemon: epoll: listen=7 active_threads=0 tvp=NULL
[2022-09-28 11:07:47] daemon: epoll: listen=8 active_threads=0 tvp=NULL
[2022-09-28 11:07:47] filter: (?memberOf=cn=gp1,o=Root)
[2022-09-28 11:07:47] attrs: dn
[2022-09-28 11:07:47] conn=1001 op=1 SRCH base="o=root" scope=2 deref=0
filter="(?memberOf=cn=gp1,o=Root)"
searchrequest dump:
0000 30 56 02 01 02 63 51 04 06 6f 3d 72 6f 6f 74 0a 0V...cQ..o=root.
0010 01 02 0a 01 00 02 01 00 02 01 00 01 01 00 a9 32 ...............2
0020 81 17 31 2e 32 2e 38 34 30 2e 31 31 33 35 35 36 ..1.2.840.113556
0030 2e 31 2e 34 2e 31 39 34 31 82 08 6d 65 6d 62 65 .1.4.1941..membe
0040 72 4f 66 83 0d 63 6e 3d 67 70 31 2c 6f 3d 52 6f rOf..cn=gp1,o=Ro
0050 6f 74 30 04 04 02 64 6e ot0...dn
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9878
Issue ID: 9878
Summary: test043 failures in 2.5/2.6
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: ---
With test043 update for ITS#9823, we manage to introduce a scenario where the
server is completely idle except for a runqueue change.
This is partly identical with ITS#9642 and a similar approach would work.
Except that changes our module facing ABI so might not be something we can
backport. For the streams we can't, we might have to change the test to make
the server not idle.
--
You are receiving this mail because:
You are on the CC list for the issue.
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.