openldap-devel

openldap-devel@openldap.org

1443 discussions

moduleload <statically linked module>
by Hallvard B Furuseth 25 Nov '08

25 Nov '08

Could we make "moduleload <statically linked module>" valid if the module name contains no "." or directory separator? Or introduce a new "module" keyword which works that way? That would simplify slapd.conf scripting, and documentation examples could simply include moduleload and would be correct without any caveats about whether the modules are statically linked. Also, moduleload seems to take an undocumented argument list which is passed to the module init routine. See module.c:module_load(). That ought to work whether or not the module is dynamically loaded. I don't think it does now. -- Hallvard

2 1

OpenLDAP 2.4.x: change of shared library version every release
by Xin LI 24 Nov '08

24 Nov '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I just noticed that 2.4.12 and 2.4.13 both bumped the shared library version. Did we actually changed the API that makes the version bump necessary? Cheers, - -- Xin LI <delphij(a)delphij.net> http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkkrL8EACgkQi+vbBBjt66A08gCfT6uIMZA4x9C+depPBG9NJBhp f4YAn3ilz2KxAZSTZgWnEcwAtPHCZMnr =XmW4 -----END PGP SIGNATURE-----

2 1

OpenLDAP 3.0 Roadmap
by Gavin Henry 24 Nov '08

24 Nov '08

To start the new thread. Thanks. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Leak in syncprov_matchops()?
by Pierangelo Masarati 23 Nov '08

23 Nov '08

==30484== 1,371 bytes in 43 blocks are definitely lost in loss record 12 of 13 ==30484== at 0x40053C0: malloc (vg_replace_malloc.c:149) ==30484== by 0x8258EFB: ber_memalloc_x (memory.c:226) ==30484== by 0x80A743C: ch_malloc (ch_malloc.c:54) ==30484== by 0x81747E5: bdb_entry_get (id2entry.c:421) ==30484== by 0x8104832: overlay_entry_get_ov (backover.c:365) ==30484== by 0x81FF53A: syncprov_matchops (syncprov.c:1151) ==30484== by 0x820175E: syncprov_op_mod (syncprov.c:1870) ==30484== by 0x8104F47: overlay_op_walk (backover.c:660) ==30484== by 0x810517C: over_op_func (backover.c:722) ==30484== by 0x81052AA: over_op_delete (backover.c:774) ==30484== by 0x80FA708: syncrepl_entry (syncrepl.c:2283) ==30484== by 0x80F5AC5: do_syncrep2 (syncrepl.c:877) ==30484== by 0x80F72C2: do_syncrepl (syncrepl.c:1301) ==30484== by 0x8086439: connection_read_thread (connection.c:1218) ==30484== by 0x8222E50: ldap_int_thread_pool_wrapper (tpool.c:663) ==30484== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==30484== by 0x423FDBD: clone (in /lib/libc-2.5.so) This was the result of a concurrency test while testing MMR. Not sure about how to reproduce it, but I've seen lots of deadlock resolutions, so probably there's some exception we're not handling fine with respect to memory allocation (HEAD as of today). p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

2 3

valgrind complains about use of uninitialized var
by Pierangelo Masarati 22 Nov '08

22 Nov '08

==30484== Conditional jump or move depends on uninitialised value(s) ==30484== at 0x81740C2: bdb_entry_release (id2entry.c:271) Apparently, boi_flags is not initialized. Where should it be initialized, and how, is still obscure to me (HEAD as of today). p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

2 1

Strange issue with contextCSN
by Pierangelo Masarati 22 Nov '08

22 Nov '08

I'm running concurrency tests of MMR, and I see some strange issues: 1) loss of sync after multi-concurrent load (multiple concurrent ops on each server, and modifications to the same data subset on all servers, in order to trigger conflicts). I'm still trying to see if there is any pattern or clue about what failed (like finding some explanation in the logs). This happens once in a while after many operations. I don't expect this to be necessarily a bug; it might be the consequence of conflicts. Of course, it would be nice if slapd allows to clearly identify where the conflict occurred, to support manual resolution. 2) loss of sync after single-concurrent load (multiple concurrent ops on a single server). This is really inesplicable (to me), as there should be no conflict. The only possible explanation I see (but need to investigate further) is that an entry is added on a server, sync'd to another one and, in the meanwhile, deleted on the first one before its own sync gets back. This happens very seldom. 3) whay puzzled me a bit is that when I load a single server, I'd expect to end up with a single contextCSN containing the SID of that server. This is correct for the server I load, but the others, even when they get correctly sync'd, contain a contextCSN for each server in the MMR pool, and the contextCSN with the other SIDs don't get propagated to the server that was loaded. It's not clear why those CSNs are generated, and how they get into the loop and propagate between servers that do not receive direct modifications. 4) another thing that puzzled me a bit is that in some cases, when all servers are loaded, and the contextCSNs are one for each SID and the same in all of the servers, they are sorted randomly, and differently; for example: bash-3.2$ diff -u testrun/server2.out testrun/server3.out --- testrun/server2.out 2008-11-22 17:17:28.000000000 +0100 +++ testrun/server3.out 2008-11-22 17:17:28.000000000 +0100 @@ -2497,8 +2497,8 @@ associatedDomain: example.com entryCSN: 20081122161630.753152Z#000000#001#000000 contextCSN: 20081122161708.935242Z#000000#001#000000 -contextCSN: 20081122161658.195350Z#000000#002#000000 contextCSN: 20081122161658.193983Z#000000#003#000000 +contextCSN: 20081122161658.195350Z#000000#002#000000 Not a big deal (except for the need to sort values to compare them), but I'd expect them to be exactly in the same order... I'm going to pack my suite of tests and put them on ftp.openldap.org (and eventually add them to OpenLDAP's test suite, specifically meant to test MMR), but first I need to polish them a little bit and enucleate those that present issues, in order to open specific ITSes. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

LDAP_OPT_X_SASL_NOCANON breaks the tests
by Hallvard B Furuseth 20 Nov '08

20 Nov '08

e.g. test000-rootdse: "... Waiting 5 seconds for slapd to start... Could not set LDAP_OPT_X_SASL_NOCANON off" -- Hallvard

2 1

GCC 4.4
by Quanah Gibson-Mount 20 Nov '08

20 Nov '08

Debian has a bug (505421) about OpenLDAP not building with the upcoming gcc 4.4. We may want to take a look at resolving that. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

2 2

Re: commit: ldap/servers/slapd schema_check.c
by Hallvard B Furuseth 19 Nov '08

19 Nov '08

ando(a)OpenLDAP.org writes: > schema_check.c 1.114 -> 1.115 > clear rc if value must be added (ITS#5819) Looking at that code, I don't think textbuf should be filled either when rc is set to LDAP_SUCCESS. -- Hallvard

2 1

test049, test050, test053 in HEAD now fail
by Hallvard B Furuseth 18 Nov '08

18 Nov '08

test049 fails with invalid DN "cn=Ursula Hampster,ou=Alumni Association,ou=People,dc=example,dc=com" in the consumer because core.schema with 'ou' and 'dc' is not loaded. test050 similarly fails on "dc=example,dc=com". test053 also fails, i have not checked why. Like test050 it keeps waiting for syncrepl to receive changes, then gives up. If it makes a difference, my configuration is ./configure --enable-dynamic --enable-modules --enable-dynamic --enable-dynacl --enable-aci --enable-crypt --enable-lmpasswd --enable-modules --enable-spasswd --enable-rlookups --enable-slapi --enable-backends=mod --disable-ndb --disable-sql --enable-overlays=mod -- Hallvard

6 16

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel