[Bug 9222] New: Fix presence list to use a btree instead of an AVL tree
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9222
Bug ID: 9222
Summary: Fix presence list to use a btree instead of an AVL
tree
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
[23:34] <hyc> ok, so far heap profile shows that memory use during refresh is
normal
[23:35] <hyc> not wonderful, but normal. mem usage grows because we're
recording the present list while receiving entries in the refresh
[23:36] <hyc> I'm seeing for 1.2GB of data about 235MB of presentlist
[23:36] <hyc> which is pretty awful, considering presentlist is just a list of
UUIDs
[23:36] <hyc> being stored in an avl tree
[23:37] <hyc> a btree would have been better here, and we could just use an
unsorted segmented array
[23:42] <hyc> for the accumulation phase anyway. we need to be able to lookup
records during the delete pphase
[00:05] <hyc> this stuff seriously needs a rewrite
[01:13] <hyc> 2.8M records x 16 bytes per uuid so this should be no more than
48MB of overhead
[01:13] <hyc> and instead it's 3-400MB
--
You are receiving this mail because:
You are on the CC list for the bug.
1 day, 21 hours
[Bug 9250] New: librewrite only supports up to 9 submatches
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9250
Bug ID: 9250
Summary: librewrite only supports up to 9 submatches
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: ---
libraries/librewrite$ cat nine.conf
rewriteEngine on
rewriteContext default
rewriteRule "(.)(.)(.)(.)(.)(.)(.)(.)(.)" "$9$8$7$6$5$4$3$2$1" :
libraries/librewrite$ ./rewrite -f nine.conf abcdefghijklmnop
abcdefghijklmnop -> ihgfedcba [0:ok]
libraries/librewrite$ cat eleven.conf
rewriteEngine on
rewriteContext default
rewriteRule "(.)(.)(.)(.)(.)(.)(.)(.)(.)(.)(.)" "$11$10$9$8$7$6$5$4$3$2$1" :
libraries/librewrite$ ./rewrite -f eleven.conf abcdefghijklmnop
abcdefghijklmnop -> a1a0ihgfedcba [0:ok]
I guess no one has needed that many yet... :)
--
You are receiving this mail because:
You are on the CC list for the bug.
1 week, 1 day
[Bug 9185] New: glue entry
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9185
Bug ID: 9185
Summary: glue entry
Product: OpenLDAP
Version: 2.4.48
Hardware: All
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: client tools
Assignee: bugs(a)openldap.org
Reporter: gnoe(a)symas.com
Target Milestone: ---
--
You are receiving this mail because:
You are watching someone on the CC list of the bug.
1 week, 1 day
[Bug 9221] New: Move all replication consumer code into its own overlay
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9221
Bug ID: 9221
Summary: Move all replication consumer code into its own
overlay
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: ---
(In relation to a discussion about slapo-chain)
<hyc> anyway, the nicer ting to fix would be in 2.5, push all of the repl
consumer code into its own overlay
<hyc> in that case, updateref would be processed wherever the overlay was
configured
<hyc> so no longer tied to the frontend
<hyc> it would also make it more feasible to have multiple different consumer
configs in a single DB, each with their own provider URL (and thus their own
updateref)
<hyc> I would think we can get rid of the update ref directive entirely, just
point all writes to that consumer's provider.
--
You are receiving this mail because:
You are on the CC list for the bug.
2 weeks, 2 days
[Bug 9205] New: Openldap 2.4.49 with overlays syncrepl+ppolicy+chain+ldap
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9205
Bug ID: 9205
Summary: Openldap 2.4.49 with overlays
syncrepl+ppolicy+chain+ldap
Product: OpenLDAP
Version: 2.4.49
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: frederic.poisson(a)admin.gmessaging.net
Target Milestone: ---
Created attachment 700
--> https://bugs.openldap.org/attachment.cgi?id=700&action=edit
test script copied from test022-ppolicy and modified to show the trouble
Hello,
I'm doing a OpenLDAP test with a master/slave replication configuration
including ppolicy overlay. I would like to enable password change from the
slave replica with chain overlay, in order to validate the ppolicy
olcPPolicyForwardUpdates attribute to TRUE. I'm using LDAPS from slave to
master with SASL External authentication with client certificate. The client
certificate correspond to a user DN entry with "manage" rights on the master
server (the same used for the replication). This user DN has authzTo attribute
in order to match the correct PROXYAUTHZ request from its dn to user DN.
All of this configuration works on replica when i do first a failed
authentication (err=49) on replica. The pwdFailureTime value is updated on the
DN entry from replica to slave normally. I'm also able to do after some self
entry update on some attribute such as password or others from replica to
master.
But the weird behavior is that i need to run first an failed authentication,
otherwise if i try to change attribute on the slave server, it respond an
err=80 "Error: ldap_back_is_proxy_authz returned 0, misconfigured URI?". The
only way to retrieve correct behavior is to restart slapd, and redo one failed
authentication first. It seems that the chain overlay do not connect the master
server at startup.
I've done a modification of test script test022-ppolicy to test022-policy-chain
which use the same LDIF source and show the problem of modification on the
consumer not "relayed" to the supplier if a fail operation is not done before.
Regards
--
You are receiving this mail because:
You are on the CC list for the bug.
2 weeks, 3 days
[Bug 9209] New: test072/test075 fail on Solaris due to buggy test script
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9209
Bug ID: 9209
Summary: test072/test075 fail on Solaris due to buggy test
script
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Both test072 and test075 have this logic:
if test -z `which dsadm`; then
echo "DSEE dsadm not in path, test skipped"
exit 0
fi
This works fine on Linux, however it does not work on Solaris causing the test
to execute (and then fail).
--
You are receiving this mail because:
You are on the CC list for the bug.
3 weeks
[Bug 9201] New: LDAP_THREAD_DEBUG doesn't compile
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9201
Bug ID: 9201
Summary: LDAP_THREAD_DEBUG doesn't compile
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: ryan(a)openldap.org
Target Milestone: ---
on master @ 4ac88b219d:
./configure CPPFLAGS="-DLDAP_THREAD_DEBUG" && make
make[2]: Entering directory '/home/ryan/tmp/openldap/libraries/libldap_r'
/bin/sh ../../libtool --mode=compile cc -g -O2 -I../../include
-I../../include -DLDAP_R_COMPILE -I./../libldap -DLDAP_THREAD_DEBUG
-DLDAP_LIBRARY -c threads.c
cc -g -O2 -I../../include -I../../include -DLDAP_R_COMPILE -I./../libldap
-DLDAP_THREAD_DEBUG -DLDAP_LIBRARY -c threads.c -fPIC -DPIC -o .libs/threads.o
In file included from ldap_thr_debug.h:129,
from threads.c:73:
../../include/ldap_pvt_thread.h:114:1: error: conflicting types for
'ldap_pvt_thread_mutex_recursive_init'
ldap_pvt_thread_mutex_recursive_init LDAP_P(( ldap_pvt_thread_mutex_t *mutex
));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ldap_thr_debug.h:129,
from threads.c:26:
../../include/ldap_pvt_thread.h:114:1: note: previous declaration of
'ldap_pvt_thread_mutex_recursive_init' was here
ldap_pvt_thread_mutex_recursive_init LDAP_P(( ldap_pvt_thread_mutex_t *mutex
));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
make[2]: *** [Makefile:420: threads.lo] Error 1
--
You are receiving this mail because:
You are on the CC list for the bug.
3 weeks, 1 day
[Bug 9228] New: libldap depends on liblutil (lutil_memcmp) when cross compiling
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9228
Bug ID: 9228
Summary: libldap depends on liblutil (lutil_memcmp) when cross
compiling
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: ryan(a)openldap.org
Target Milestone: ---
cross-compiling for Unix:
./configure --host=arm-linux-gnueabihf CC=arm-linux-gnueabihf-gcc
--with-yielding-select && make
...
libtool: link: arm-linux-gnueabihf-gcc -g -O2 -o ldapurl ldapurl.o lduversion.o
../../libraries/liblutil/liblutil.a ../../libraries/libldap/.libs/libldap.a
/home/ryan/tmp/openldap/libraries/liblber/.libs/liblber.a
../../libraries/liblber/.libs/liblber.a -lresolv
/usr/lib/gcc-cross/arm-linux-gnueabihf/8/../../../../arm-linux-gnueabihf/bin/ld:
../../libraries/libldap/.libs/libldap.a(os-ip.o): in function
`ldap_pvt_is_socket_ready':
/home/ryan/tmp/openldap/libraries/libldap/os-ip.c:248: warning: `sys_errlist'
is deprecated; use `strerror' or `strerror_r' instead
/usr/lib/gcc-cross/arm-linux-gnueabihf/8/../../../../arm-linux-gnueabihf/bin/ld:
/home/ryan/tmp/openldap/libraries/libldap/os-ip.c:248: warning: `sys_nerr' is
deprecated; use `strerror' or `strerror_r' instead
/usr/lib/gcc-cross/arm-linux-gnueabihf/8/../../../../arm-linux-gnueabihf/bin/ld:
../../libraries/libldap/.libs/libldap.a(result.o): in function `try_read1msg':
/home/ryan/tmp/openldap/libraries/libldap/result.c:935: undefined reference to
`lutil_memcmp'
cross-compiling for Windows:
./configure --host=x86_64-w64-mingw32 CC=x86_64-w64-mingw32-gcc && make
...
libtool: link: x86_64-w64-mingw32-gcc -shared .libs/bind.o .libs/open.o
.libs/result.o .libs/error.o .libs/compare.o .libs/search.o .libs/controls.o
.libs/messages.o .libs/references.o .libs/extended.o .libs/cyrus.o
.libs/modify.o .libs/add.o .libs/modrdn.o .libs/delete.o .libs/abandon.o
.libs/sasl.o .libs/sbind.o .libs/unbind.o .libs/cancel.o .libs/filter.o
.libs/free.o .libs/sort.o .libs/passwd.o .libs/whoami.o .libs/vc.o
.libs/getdn.o .libs/getentry.o .libs/getattr.o .libs/getvalues.o
.libs/addentry.o .libs/request.o .libs/os-ip.o .libs/url.o .libs/pagectrl.o
.libs/sortctrl.o .libs/vlvctrl.o .libs/init.o .libs/options.o .libs/print.o
.libs/string.o .libs/util-int.o .libs/schema.o .libs/charray.o .libs/os-local.o
.libs/dnssrv.o .libs/utf-8.o .libs/utf-8-conv.o .libs/tls2.o .libs/tls_o.o
.libs/tls_g.o .libs/tls_m.o .libs/turn.o .libs/ppolicy.o .libs/dds.o
.libs/txn.o .libs/ldap_sync.o .libs/stctrl.o .libs/assertion.o .libs/deref.o
.libs/ldifutil.o .libs/ldif.o .libs/fetch.o .libs/lbase64.o .libs/msctrl.o
.libs/psearchctrl.o .libs/version.o
../../libraries/liblber/.libs/liblber.dll.a -lregex -lws2_32 -g -O2 -o
.libs/libldap.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker
.libs/libldap.dll.a
/usr/bin/x86_64-w64-mingw32-ld: .libs/result.o: in function `try_read1msg':
/home/ryan/tmp/openldap/libraries/libldap/result.c:935: undefined reference to
`lutil_memcmp'
/usr/bin/x86_64-w64-mingw32-ld: .libs/dnssrv.o: in function `ldap_dn2domain':
/home/ryan/tmp/openldap/libraries/libldap/dnssrv.c:72: undefined reference to
`lutil_memcmp'
/usr/bin/x86_64-w64-mingw32-ld: .libs/ldif.o: in function
`ldif_must_b64_encode':
/home/ryan/tmp/openldap/libraries/libldap/ldif.c:426: undefined reference to
`lutil_memcmp'
collect2: error: ld returned 1 exit status
More similar issues occur with --enable-dynamic.
Workaround: configure with ac_cv_func_memcmp_working=yes
--
You are receiving this mail because:
You are on the CC list for the bug.
4 weeks
[Bug 9249] New: A dollar sign ($) at the end of the 2nd argument of olcAuthzRegexp crashes slapd
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9249
Bug ID: 9249
Summary: A dollar sign ($) at the end of the 2nd argument of
olcAuthzRegexp crashes slapd
Product: OpenLDAP
Version: 2.4.47
Hardware: All
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: kop(a)karlpinc.com
Target Milestone: ---
The following ldif, fed to ldapmodify, crashes slapd.
dn: cn=config
changetype: modify
replace: olcAuthzRegexp
olcAuthzRegexp: "^([^,]+),cn=PLAIN,cn=auth" "$1,ou=People,dc=example,dc=com$"
Happens on Debian 10 with openldap 2.4.47 and RHEL 8 with openldap 2.4.46.
Doing ldapmodify -d -1 seems to crash only 1 out of 3 times, but it always
crashes without the -d -1.
--
You are receiving this mail because:
You are on the CC list for the bug.
4 weeks