OpenLDAP dynamic configuration prefomance issue
by Dmitry Korotkov
Dear OpenLDAP team,
I made some OpenLDAP stress tests on our use cases and realized that
time of registering new objectClass using OpenLDAP dynamic configuration
grows linearly. It looks like slapd completely rewrites contents of
cn=config folder on any configuration change.
This issue makes OpenLDAP schema to be a bottleneck in our large
scalable application. Do you plan to store OpenLDAP configuration in bdb
or hdb database? Or another solution of this issue is planned?
WBR, Dmitry V. Korotkov
14 years, 6 months
(ITS#6156) Translucent overlay not working correctly when not asking for attributes included in search filter
by isaac＠ebox-platform.com
Full_Name: Isaac Clerencia
Version: 2.4.15
OS: Ubuntu
URL:
Submission from: (NULL) (88.26.177.14)
The translucent overlay doesn't return entries if any of the attributes included
in the search filter is remote and is not requested.
The easiest way to reproduce this is modifying slightly test034-translucent. The
ldapsearch in line 786 looks originally like this:
$LDAPSEARCH -H $URI2 -b "o=translucent"
"(|(employeeType=foo)(carlicense=right))" > $SEARCHOUT 2>&1
The original test works correctly because it requests all the attributes,
including carLicense.
If we change it to request a specific attribute such as preferredLanguage:
$LDAPSEARCH -H $URI2 -b "o=translucent"
"(|(employeeType=foo)(carlicense=right))" preferredLanguage > $SEARCHOUT 2>&1
the test fails.
If we just ask for the carLicense attribute, the test passes:
$LDAPSEARCH -H $URI2 -b "o=translucent"
"(|(employeeType=foo)(carlicense=right))" carLicense > $SEARCHOUT 2>&1
As long as carLicense is included in the request attributes the test will pass,
otherwise it will fail.
14 years, 6 months
(ITS#6155) Segfault during Heimdal's kadmin -l init Realm
by dewayne_freebsd＠yahoo.com
Full_Name: Dewayne Geraghty
Version: 2.4.16
OS: FreeBSD 7.2R
URL: http://www.consciuminternational.com.au/ldap
Submission from: (NULL) (58.172.112.108)
FreeBSD version 7.2; Heimdal V1.2.1; OpenLDAP 2.4.16
Heimdal and OpenLDAP are built for heimdal to use OpenLDAP as backend.
Segmentation fault during
kadmin -l
init HS
slapd and heimdal work correctly, independently.
slapd is running at debug 1019, logs are at enclosed URL along with the full gdb
trace, and configuration files. If I can assist please advise.
This is a single Pentium CPU, and gcc flags
CFLAGS= -pipe -g3 -ggdb3 -O0 -march=pentium4 -mtune=pentium4 -DDO_KRB5
-DDO_SAMBA -DHAVE_OPENSSL
#0 0x286447b6 in memmove () from /lib/libc.so.7
#1 0x282a10e8 in ber_write () from /usr/local/lib/liblber-2.4.so.6
#2 0x2829ebf7 in ber_put_ostring () from /usr/local/lib/liblber-2.4.so.6
#3 0x2829ed14 in ber_put_berval () from /usr/local/lib/liblber-2.4.so.6
#4 0x2829faca in ber_printf () from /usr/local/lib/liblber-2.4.so.6
#5 0x2821a0ee in ldap_add_ext () from /usr/local/lib/libldap-2.4.so.6
#6 0x2821a378 in ldap_add_ext_s () from /usr/local/lib/libldap-2.4.so.6
#7 0x280ad493 in LDAP_store (context=0x287050b0, db=0x2870e040, flags=0,
entry=0xbfbfe790) at hdb-ldap.c:1600
#8 0x2809875b in kadm5_s_create_principal (server_handle=0x2871b0c0,
princ=0xbfbfea3c, mask=17, password=0xbfbfe830 "bQdxg9drKf")
at create_s.c:182
#9 0x2808da1c in kadm5_create_principal (server_handle=0x2871b0c0,
princ=0xbfbfea3c, mask=17, password=0xbfbfe830 "bQdxg9drKf")
at common_glue.c:64
#10 0x0804e496 in ?? ()
#11 0x2871b0c0 in ?? ()
#12 0xbfbfea3c in ?? ()
#13 0x00000011 in ?? ()
#14 0xbfbfe830 in ?? ()
#15 0x28084000 in ?? ()
#16 0x28084200 in ?? ()
#17 0x28084400 in ?? ()
#18 0x285b3c8d in _pthread_mutex_init_calloc_cb () from /lib/libc.so.7
#19 0x0804e8c9 in ?? ()
#20 0x2870c0e0 in ?? ()
#21 0x00000000 in ?? ()
#22 0x00000000 in ?? ()
#23 0x00000000 in ?? ()
#24 0x2870c085 in ?? ()
#25 0x00000000 in ?? ()
#26 0x28650030 in ?? () from /lib/libc.so.7
I have spent weeks trying to get this to work. (Because I'm using and modifing
the FreeBSD ports system to build and use the latest version of LDAP and
Heimdal.)
14 years, 6 months
(ITS#6154) response/cleanup callback mismatch
by h.b.furuseth＠usit.uio.no
Full_Name: Hallvard B Furuseth
Version: HEAD, RE24
OS:
URL:
Submission from: (NULL) (129.240.6.233)
Submitted by: hallvard
result.c:slap_send_search_entry() calls slap_cleanup_play() without
having called slap_response_play() if backend_operational() failed.
This breaks back-relay's cleanup handler relay_back_swap_bd() - or
rather, I suppose it makes that handler break cleanup handlers
called after it. It restores op->o_bd from o_callback->sc_private,
which was supposedly set by the o_callback->sc_response call.
14 years, 6 months
Re: (ITS#6152) proxycache enhancements
by hyc＠symas.com
Pierangelo Masarati wrote:
> hyc(a)OpenLDAP.org wrote:
>
>> Some ideas that came out of discussions at the Ubuntu Developer Summit this
>> week...
>>
>> It would be nice for pcache to detect when connectivity to the remote server has
>> been lost. In that case, cache expiration should be stopped, and the cache
>> contents should remain intact until connectivity is restored.
>
> Sounds fair.
>
>> Also, when connectivity is restored, pcache should explicitly refresh all the
>> entries it currently holds, rather than allowing them to be immediately expired.
>
> Sounds an overkill?
Perhaps. It is certainly likely that any entries in the cache will be stale;
when connectivity is restored and expiration is re-enabled the cached entries
will probably be immediately removed. While it will be no problem to retrieve
the entries again since the network is available, the concern is that only a
subset of the originally cached entries will be retrieved through normal user
activity, but the entire set needs to be preserved in anticipation of the next
disconnect event.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
14 years, 6 months
Re: (ITS#6152) proxycache enhancements
by masarati＠aero.polimi.it
hyc(a)OpenLDAP.org wrote:
> Some ideas that came out of discussions at the Ubuntu Developer Summit this
> week...
>
> It would be nice for pcache to detect when connectivity to the remote server has
> been lost. In that case, cache expiration should be stopped, and the cache
> contents should remain intact until connectivity is restored.
Sounds fair.
> Also, when connectivity is restored, pcache should explicitly refresh all the
> entries it currently holds, rather than allowing them to be immediately expired.
Sounds an overkill?
Cheers, p.
14 years, 6 months
Re: (ITS#6152) proxycache enhancements
by rhafer＠suse.de
Am Donnerstag 28 Mai 2009 18:29:55 schrieb hyc(a)openldap.org:
> Full_Name: Howard Chu
> Version: 2.4.16
> OS: Linux
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (80.67.104.102)
> Submitted by: hyc
>
>
> Some ideas that came out of discussions at the Ubuntu Developer Summit this
> week...
>
> It would be nice for pcache to detect when connectivity to the remote
> server has been lost. In that case, cache expiration should be stopped, and
> the cache contents should remain intact until connectivity is restored.
Yes that sound reasonable. It's probably also worth to think about a mechanism
to explicitly set pcache to "offline" mode. That way on a client machine a
hook could be provided for e.g. NetworkManager to bring pcache to offline mode
immediately when the network goes offline.
That mechanism could either be offered through back-config (back-monitor as
for readonly?) and/or through the nssov Socket as that would most probably be
the main user of this disconnected pcache mode.
> Also, when connectivity is restored, pcache should explicitly refresh all
> the entries it currently holds, rather than allowing them to be immediately
> expired.
--
Ralf
14 years, 6 months
(ITS#6153) Segfault during Heimdal's kadmin -l init Realm
by dewayne_freebsd＠yahoo.com
Full_Name: Dewayne Geraghty
Version: 2.4.16
OS: FreeBSD 7.2R
URL: http://www.consciuminternational.com.au/ldap
Submission from: (NULL) (58.172.112.108)
FreeBSD version 7.2; Heimdal V1.2.1; OpenLDAP 2.4.16
Heimdal and OpenLDAP are built for heimdal to use OpenLDAP as backend.
Segmentation fault during
kadmin -l
init HS
slapd and heimdal work correctly, independently.
slapd is running at debug 1019, logs are at enclosed URL along with the full gdb
trace, and configuration files. If I can assist please advise.
This is a single Pentium CPU, and gcc flags
CFLAGS= -pipe -g3 -ggdb3 -O0 -march=pentium4 -mtune=pentium4 -DDO_KRB5
-DDO_SAMBA -DHAVE_OPENSSL
#0 0x286447b6 in memmove () from /lib/libc.so.7
#1 0x282a10e8 in ber_write () from /usr/local/lib/liblber-2.4.so.6
#2 0x2829ebf7 in ber_put_ostring () from /usr/local/lib/liblber-2.4.so.6
#3 0x2829ed14 in ber_put_berval () from /usr/local/lib/liblber-2.4.so.6
#4 0x2829faca in ber_printf () from /usr/local/lib/liblber-2.4.so.6
#5 0x2821a0ee in ldap_add_ext () from /usr/local/lib/libldap-2.4.so.6
#6 0x2821a378 in ldap_add_ext_s () from /usr/local/lib/libldap-2.4.so.6
#7 0x280ad493 in LDAP_store (context=0x287050b0, db=0x2870e040, flags=0,
entry=0xbfbfe790) at hdb-ldap.c:1600
#8 0x2809875b in kadm5_s_create_principal (server_handle=0x2871b0c0,
princ=0xbfbfea3c, mask=17, password=0xbfbfe830 "bQdxg9drKf")
at create_s.c:182
#9 0x2808da1c in kadm5_create_principal (server_handle=0x2871b0c0,
princ=0xbfbfea3c, mask=17, password=0xbfbfe830 "bQdxg9drKf")
at common_glue.c:64
#10 0x0804e496 in ?? ()
#11 0x2871b0c0 in ?? ()
#12 0xbfbfea3c in ?? ()
#13 0x00000011 in ?? ()
#14 0xbfbfe830 in ?? ()
#15 0x28084000 in ?? ()
#16 0x28084200 in ?? ()
#17 0x28084400 in ?? ()
#18 0x285b3c8d in _pthread_mutex_init_calloc_cb () from /lib/libc.so.7
#19 0x0804e8c9 in ?? ()
#20 0x2870c0e0 in ?? ()
#21 0x00000000 in ?? ()
#22 0x00000000 in ?? ()
#23 0x00000000 in ?? ()
#24 0x2870c085 in ?? ()
#25 0x00000000 in ?? ()
#26 0x28650030 in ?? () from /lib/libc.so.7
I have spent weeks trying to get this to work. (Because I'm using and modifing
the FreeBSD ports system to build and use the latest version of LDAP and
Heimdal.)
14 years, 6 months
