- openldap-bugs - openldap.org

Re: (ITS#5113) pcache returns incomplete results
by rhafer＠suse.de 06 Sep '07

06 Sep '07

On Mittwoch, 29. August 2007, Howard Chu wrote: > rhafer(a)suse.de wrote: > > Full_Name: Ralf Haferkamp > > Version: HEAD > > OS: > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (89.166.180.39) > > > > > > While the results of a query are being cached, slapo-pcache will answer > > queries that match the same template from the cache that is currently > > being populated. This means that subsequent queries will get incomplete > > results until the original query is completely cached. > > I don't see how that is possible. The query-in-progress isn't added to the > cache until the final result is received. Until then, query_containment > should not know anything is there to answer with. Hm, current HEAD first calls add_query, which adds the CachedQuery to the cache and after that calls cache_entries to add the entries of that Query to the cache. That means that query_containment already know about the Query before its result is completely cached. In RE23 it is just the other way arround (first cache_entries() then add_query()). I see two possible solution: 1. Switch back to the old behaviour. But I guess the change was made for a reason. I don't know that yet. Seems the change happend between r1.95 and r1.96 of pcache.c (log message: "Fix concurrency issues"). 2. Protect the cached query with an rw_lock. Writelock it while cache_entries() is executing and readlock it during searches. This would give us the behaviour that Ando suggested in the discussion of ITS#5112. (pcache would not try to cache the same search request mulitple times, but block the second request until the first one is cached and then answer it from the cache) -- Ralf

1 0

(ITS#5124) segfault on modify operation by slurpd with rwm overlay
by jclarke＠linagora.com 05 Sep '07

05 Sep '07

Full_Name: Jonathan Clarke Version: 2.3.37 OS: Debian Etch URL: ftp://ftp.openldap.org/incoming/jclarke-slurpd-rwm-modify-bug.tar.gz Submission from: (NULL) (134.157.159.100) Hello guys, With a simple master/slave setup, and the rwm overlay activated for the bindDN context, any modify operation made on the master, replicated with slurpd causes the slave to crash. You will find below a backtrace of the slave when it crashes, and the configuration files we're using on the master, the slave, an LDIF of the contents of the directory are in the archive on ftp.openldap.org indicated in the ITS. We are using 2.3.37 for both master and slave, and have confirmed that disactivating the rwm overlay in slapd.conf avoids the problem. Thanks in advance for your help ! Jon ***** BACKTRACE ****** conn=0 fd=14 ACCEPT from IP=127.0.0.1:57752 (IP=0.0.0.0:392) [New Thread 32771 (LWP 21187)] conn=0 op=0 BIND dn="uid=replicator,dc=linagora,dc=org" method=128 conn=0 op=0 BIND dn="uid=replicator,dc=linagora,dc=org" mech=SIMPLE ssf=0 conn=0 op=0 RESULT tag=97 err=0 text= conn=0 op=1 MOD dn="dc=linagora,dc=org" conn=0 op=1 MOD attr=description entryCSN modifiersName modifyTimestamp conn=0 op=1 RESULT tag=103 err=0 text= Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 32771 (LWP 21187)] 0x4035dafb in free () from /lib/libc.so.6 (gdb) bt #0 0x4035dafb in free () from /lib/libc.so.6 #1 0x4035f805 in malloc () from /lib/libc.so.6 #2 0x0813e70f in ber_memalloc_x (s=1, ctx=0x40412660) at memory.c:226 #3 0x08079fa8 in ch_malloc (size=16) at ch_malloc.c:54 #4 0x08101567 in rwm_op_modify (op=0x8246fc0, rs=0x6301dce4) at rwm.c:590 #5 0x080b6c5e in overlay_op_walk (op=0x8246fc0, rs=0x6301dce4, which=op_modify, oi=0x81e9688, on=0x81e9778) at backover.c:639 #6 0x080b70ce in over_op_func (op=0x8246fc0, rs=0x6301dce4, which=op_modify) at backover.c:701 #7 0x08077e00 in do_modify (op=0x8246fc0, rs=0x6301dce4) at modify.c:200 #8 0x080609bb in connection_operation (ctx=0x6301dd58, arg_v=0x8246fc0) at connection.c:1133 #9 0x0811a8b4 in ldap_int_thread_pool_wrapper (xpool=0x81d0000) at tpool.c:478 #10 0x402adc51 in pthread_start_thread () from /lib/libpthread.so.0 #11 0x402addb4 in pthread_start_thread_event () from /lib/libpthread.so.0 #12 0x403b438a in clone () from /lib/libc.so.6 ***** End of backtrace *****

1 0

Re: (ITS#5123) slaptest is not checking spelling of keyword access
by ando＠sys-net.it 05 Sep '07

05 Sep '07

lwartha(a)gmail.com wrote: > I made stupid typo and use word acces instead of access in slapd.confl. > Unforutnately slaptest -u does not display any notice about it and display > config file testing succeeded. Because up to 2.3 OpenLDAP didn't care about unrecognized statements. If you run staptest with -dconfig you'll notice warnings (if you're debugging slapd.conf you should; it is not the default because in most cases people are only interested in a yes/no question; ITS#4930 was filed to even remove the "success string"). > > This of cause takes lot of investigation to find it. > > Thanks for fixing it in the future. It's been changed in 2.4 ever since. Now all errors, including unrecognized statements, cause a bailout. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#5123) slaptest is not checking spelling of keyword access
by lwartha＠gmail.com 05 Sep '07

05 Sep '07

Full_Name: Ladislav Wartha Version: 2.3.27-4 OS: Fedora Core release 6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.122.198.222) Hi, I made stupid typo and use word acces instead of access in slapd.confl. Unforutnately slaptest -u does not display any notice about it and display config file testing succeeded. This of cause takes lot of investigation to find it. Thanks for fixing it in the future. Best regards, Ladislav

1 0

Re: (ITS#5120) slapadd -q makes database logs unusable
by ando＠sys-net.it 04 Sep '07

04 Sep '07

hyc(a)symas.com wrote: > ando(a)sys-net.it wrote: >> When slapadd'ing -q, existing database log files seem to become unusable. If >> this is correct, as it seems to be, slapadd could refuse to start with -q if log >> files are present, or, for example, remove the logs if -qq. > > I guess we could add that check. The docs already say that if an error occurs, > the entire database will be unusable. As such, you should only use it for > initially populating a database, not for adding to an existing one. The story is that I placed logs in a separate directory and I forgot to clean them up when regenerating the DB after removing the database files :) 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5120) slapadd -q makes database logs unusable
by hyc＠symas.com 04 Sep '07

04 Sep '07

ando(a)sys-net.it wrote: > When slapadd'ing -q, existing database log files seem to become unusable. If > this is correct, as it seems to be, slapadd could refuse to start with -q if log > files are present, or, for example, remove the logs if -qq. I guess we could add that check. The docs already say that if an error occurs, the entire database will be unusable. As such, you should only use it for initially populating a database, not for adding to an existing one. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5121) IDL cache issue
by ando＠sys-net.it 04 Sep '07

04 Sep '07

To reproduce: - set idlcache - search one entry, so that the idl gets cached - delete that entry, so that the idl gets cleared - but head/tail don't - search another entry so that it gets cached - head/tail are corrupted I've a fix for this about to come (affects 2.4.5 as well, sigh; not sure about re23). 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#5122) back-bdb occasionally allows bogus numeric values
by ando＠sys-net.it 04 Sep '07

04 Sep '07

Full_Name: Pierangelo Masarati Version: since back-config OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.203.230.29) Submitted by: ando Setting a negative number for cachesize causes an assertion in ch_calloc(); for idlcachesize is just accepted; same for most remaining numeric data. A neat solution would be to define ARG_UINT/ARG_ULONG, redefine types as appropriate (now they're ints, but the negative value has no meaning or causes crash). There seems to be room for 8 more types in the type mask. Not a showstopper, though.

1 0

Re: (ITS#5121) IDL cache issue
by ando＠sys-net.it 04 Sep '07

04 Sep '07

I noticed that I was intermixing overlay and database configuration statements, but this should be allowed in HEAD. Anyway, I now put configuration statements in the right order, but I've been able to reproduce the problem (not all times, and no devel tools on the maching where I could produce it, except gdb and an unstripped slapd build).... 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#5121) IDL cache issue
by ando＠sys-net.it 04 Sep '07

04 Sep '07

Full_Name: Pierangelo Masarati Version: HEAD OS: Linux RH AS 4.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.203.230.29) Submitted by: ando I ran into an issue running HEAD code. I got the following core dump: #0 0x08103390 in bdb_idl_cache_put (bdb=0xa3e1110, db=0x3550c800, key=0x35f988a0, ids=0x34afc008, rc=0) at ../../../../servers/slapd/back-bdb/idl.c:354 #1 0x08104318 in bdb_idl_fetch_key (be=0x36058ec0, db=0x3550c800, locker=0, key=0x35f988a0, ids=0x34afc008, saved_cursor=0x0, get_flag=0) at ../../../../servers/slapd/back-bdb/idl.c:665 #2 0x081084a1 in bdb_key_read (be=0x36058ec0, db=0x3550c800, locker=100, k=0x352ff2d4, ids=0x34afc008, saved_cursor=0x0, get_flag=0) at ../../../../servers/slapd/back-bdb/key.c:50 #3 0x081013ab in bdb_filter_candidates (op=0xa46b3f8, locker=100, f=0x352ff2c4, ids=0x34bfc008, tmp=0x34afc008, stack=0x34c7c008) at ../../../../servers/slapd/back-bdb/filterindex.c:770 #4 0x081020e9 in list_candidates (op=0xa46b3f8, locker=100, flist=0x35f98dd0, ftype=161, ids=0x34b7c008, tmp=0x34afc008, save=0x34bfc008) at ../../../../servers/slapd/back-bdb/filterindex.c:580 #5 0x08100458 in bdb_filter_candidates (op=0xa46b3f8, locker=100, f=0x35f98dc0, ids=0x34b7c008, tmp=0x34afc008, stack=0x34bfc008) at ../../../../servers/slapd/back-bdb/filterindex.c:204 #6 0x081020e9 in list_candidates (op=0xa46b3f8, locker=100, flist=0x35f98db0, ftype=160, ids=0x35fd8e30, tmp=0x34afc008, save=0x34b7c008) at ../../../../servers/slapd/back-bdb/filterindex.c:580 #7 0x08100458 in bdb_filter_candidates (op=0xa46b3f8, locker=100, f=0x35f98de0, ids=0x35fd8e30, tmp=0x34afc008, stack=0x34b7c008) #8 0x081109b5 in bdb_search (op=0xa46b3f8, rs=0x3605a0f0) at ../../../../servers/slapd/back-bdb/search.c:1111 #9 0x080ee601 in overlay_op_walk (op=0xa46b3f8, rs=0x3605a0f0, which=op_search, oi=0xa3e21e0, on=0xa3e2740) at ../../../servers/slapd/backover.c:652 #10 0x080ee72f in over_op_func (op=0xa46b3f8, rs=0x3605a0f0, which=op_bind) at ../../../servers/slapd/backover.c:704 #11 0x0808a051 in fe_op_search (op=0xa46b3f8, rs=0x3605a0f0) at ../../../servers/slapd/search.c:368 #12 0x080894f7 in do_search (op=0xa46b3f8, rs=0x3605a0f0) at ../../../servers/slapd/search.c:217 #13 0x080875c3 in connection_operation (ctx=0x3605a210, arg_v=0xa46b3f8) at ../../../servers/slapd/connection.c:1145 #14 0x0808801b in connection_read_thread (ctx=0x3605a210, argv=0x14) at ../../../servers/slapd/connection.c:1271 #15 0x081afa01 in ldap_int_thread_pool_wrapper (xpool=0xa304fa8) at ../../../libraries/libldap_r/tpool.c:614 #16 0x008ad3cc in start_thread () from /lib/tls/libpthread.so.0 #17 0x00736c3e in clone () from /lib/tls/libc.so.6 where (gdb) p bdb->bi_idl_cache_max_size $27 = 30000 (gdb) p bdb->bi_idl_lru_head $28 = (bdb_idl_cache_entry_t *) 0x3550cd28 (gdb) p bdb->bi_idl_lru_tail $29 = (bdb_idl_cache_entry_t *) 0x3550cd28 (gdb) p bdb->bi_idl_lru_tail[0] $30 = {kstr = {bv_len = 3, bv_val = 0x3550ebd8 "top"}, idl = 0x6, db = 0x3550ebe8, idl_flags = 0, idl_lru_prev = 0x0, idl_lru_next = 0x0} The latter seems quite odd: obviously the head/tail is corrupted, but either bdb->bi_idl_lru_tail and bdb->bi_idl_lru_head should be null, or their idl_lru_prev and idl_lru_next members should be valid. There seems to be something odd in how entries are cleaned up from the cache: in fact, if the whole LRU is destroyed, then eprev would remain dangling, but this should never occur. p.

1 0

Re: (ITS#5120) slapadd -q makes database logs unusable
by ando＠sys-net.it 04 Sep '07

04 Sep '07

BTW, I'm currently using Berkeley 4.2.52 w/ patches w/ HEAD code, if it matters. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#5120) slapadd -q makes database logs unusable
by ando＠sys-net.it 04 Sep '07

04 Sep '07

Full_Name: Pierangelo Masarati Version: all supporting -q OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.203.230.29) Submitted by: ando When slapadd'ing -q, existing database log files seem to become unusable. If this is correct, as it seems to be, slapadd could refuse to start with -q if log files are present, or, for example, remove the logs if -qq. p.

1 0

ITS#3636 more flexible file: URLs in LDIFs
by hyc＠symas.com 04 Sep '07

04 Sep '07

Some notes... Most of the forms in the original request have been supported in 2.3/2.4/HEAD for a long time, I just didn't remember this ITS existed. It has some bearing on #5117 as well. Specifically file:/absolute/path file:relative/path file:simple.name are allowed (but deprecated) by RFC 3986 and are supported. (RFC1808 and 3986 expect relative URLs to have no scheme specifier at all. We don't handle that case. We also don't handle file://localhost/absolute/path and probably should.) file://simple.name violates RFC3986 and is rejected. The latest draft spec for FILE URIs has died, and it looks like it was plagued with too many strange behaviors to formulate a coherent spec. http://tools.ietf.org/html/draft-hoffman-file-uri-03 http://offset.skew.org/wiki/URI/File_scheme/Plan_of_action In the meantime, the libcurl API is a lot more complicated than libfetch. Might be nice to have, but it will not be as straightforward... -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5119) double free in slapd
by hyc＠symas.com 04 Sep '07

04 Sep '07

quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.3.38/RE23 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (71.202.148.128) > > > There is apparently a bug in attribute normalization of objectClasses that can > result in a double free in slapd, causing it to crash. My mistake, not a double-free. Fixed in HEAD/RE23/RE24. > Please see: > <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=440632> > > This behavior still exists in current RE23. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5119) double free in slapd
by quanah＠zimbra.com 04 Sep '07

04 Sep '07

Full_Name: Quanah Gibson-Mount Version: 2.3.38/RE23 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (71.202.148.128) There is apparently a bug in attribute normalization of objectClasses that can result in a double free in slapd, causing it to crash. Please see: <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=440632> This behavior still exists in current RE23. --Quanah

1 0

Re: (ITS#5114) pcache cache results for searches that hit size/timelimit
by rhafer＠suse.de 03 Sep '07

03 Sep '07

On Saturday 01 September 2007 17:35, ando(a)sys-net.it wrote: > ando(a)sys-net.it wrote: > > Ralf, > > This patch should now work as expected. > > <http://www.sys-net.it/~ando/Download/pcache_sizelimit.patch> > > Does it harmonize with your improvements? Your changes to the response and cleanup handles interfere a bit with my changes (I move much of the _response code to _cleanup) but it should be easy to sort that out once we have either of the two patches in HEAD. But as 2.4.5 is not tagged yet we should probably wait until that happened. > Or, if you prefer, first > commit your changes, and I'll harmonize the rest. That doesn't really matter to me. I have the felling that it is easier the other way around :) -- Ralf

1 0

(ITS#5118) DB_CONFIG missing from converted config
by hyc＠OpenLDAP.org 02 Sep '07

02 Sep '07

Full_Name: Howard Chu Version: 2.3/2.4 OS: URL: Submission from: (NULL) (76.168.84.21) Submitted by: hyc The back-bdb config code was only parsing the DB_CONFIG file in server mode, but it needs to be parsed in all modes so that slaptest -f slapd.conf -F slapd.d can see it when converting. Already fixed in HEAD

1 0

Re: (ITS#4848) Another slapd startup segfault
by hyc＠symas.com 02 Sep '07

02 Sep '07

ando(a)sys-net.it wrote: > Your problem is related > to the fact that you intermixed overlay and database configuration > statements, so the idletimeout statement after the accesslog overlay > instantiation was causing invalid memory write (beyond the private data > of the accesslog overlay instead of in the private data of the bdb > database) resulting in heap corruption. The fix in HEAD has been backported to RE23 now. (The fix for ITS#5082 needed part of this fix.) -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: ITS#5082
by hyc＠symas.com 02 Sep '07

02 Sep '07

Howard Chu wrote: > ando(a)sys-net.it wrote: >> See also discussion in thread >> <http://www.openldap.org/lists/openldap-software/200708/msg00063.html> > > The fix currently in CVS HEAD is to remove the olcPasswordHash attribute from > the olcGlobal entry and move it to the frontendDB entry. For better backward compatibility, olcPasswordHash is allowed in both the olcGlobal entry and the frontendDB entry. The preferred location for this setting is now in the frontendDB entry. When generating a slapd.d from a slapd.conf file, only the frontendDB entry will carry the attribute. Existing slapd.d configs with the attribute in the global entry should continue to work but they should be manually updated to use only the frontendDB entry. This fix is now in RE23 as well as RE24. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5070) Issues in X.509 certificate parsing
by hyc＠symas.com 02 Sep '07

02 Sep '07

ando(a)sys-net.it wrote: > ando(a)sys-net.it wrote: > >> I've an issue with X.509 certificate parsing in HEAD/re24. The certificate, >> according to OpenSSL, has a SerialNumber c8:5b:9a:dd:ea:bf:f9:fa and HEAD fails >> to parse it because it is an integer with length equal to 9, which is larger >> than sizeof(ber_int_t), as tested in ber_getnint() at decode.c:254. The DER >> encoded value is: 2 9 0 200 91 154 221 234 191 249 250. Seems to be time >> to get past the sizeof(ber_int_t) limitation... > > ... which would violate RFC 4511 where it states that INTEGER means from > 0 up to 2^31-1... I have a simple solution for this problem, at the > cost of partially violating rfc 4523: if an integer is larger than > 2^31-1, it could be represented in the certificateExactMatch > normalization in hexadecimal form, much like OpenSSL does. This would > increase interoperability with OpenSSL and be at least self-consistent, > since all serialNumbers that large would be consistently expanded that > way. Another solution, preserving the decimal representation, would > probably require some arbitrary precision support from external > libraries. If there's consensus, I'd post my simple patch. I would go with the hex representation. IMO LDAP/X.500 has long needed a hex integer syntax (or at least some other binary base, but hex is probably best), since we can parse/validate them bytewise without any word size limitations or expensive conversions. And IMO GSER is a giant leap backward in network protocol efficiency. If it were merely a UI format, like LDIF, that would have been ok, but over the wire, that's ridiculous. (But that's a separate discussion entirely...) -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5117) test049/test050 failures
by hyc＠symas.com 02 Sep '07

02 Sep '07

hyc(a)symas.com wrote: > hyc(a)symas.com wrote: >> I see the same result on FreeBSD 6.2. It appears to be because libfetch was >> detected by configure and used here, and libfetch failed to open the FILE URLs >> that load the necessary schema. > > The test script uses relative URLs (RFC1808) which our liblutil stuff supports, > but apparently libfetch only knows how to parse absolute URLs (RFC1738) - see > their CVS > http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libfetch/fetch.c?rev=1.38 > > Seems to me to be a deficiency in libfetch, but I guess we can rework the > scripts to use absolute FILE URLs here. Dunno if it's worth reporting this upstream, but libfetch accepts relative paths like this file://./foo/bar -> "./foo/bar" which violates both RFC1738 and RFC1808 (and RFC2396). I.e., when the "//" authority-spec is present the path must be absolute. Probably, since libfetch provides no mechanism for defining a base URI, it should just never accept relative paths. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5117) test049/test050 failures
by hyc＠symas.com 02 Sep '07

02 Sep '07

hyc(a)symas.com wrote: > I see the same result on FreeBSD 6.2. It appears to be because libfetch was > detected by configure and used here, and libfetch failed to open the FILE URLs > that load the necessary schema. The test script uses relative URLs (RFC1808) which our liblutil stuff supports, but apparently libfetch only knows how to parse absolute URLs (RFC1738) - see their CVS http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libfetch/fetch.c?rev=1.38 Seems to me to be a deficiency in libfetch, but I guess we can rework the scripts to use absolute FILE URLs here. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5117) test049/test050 failures
by hyc＠symas.com 02 Sep '07

02 Sep '07

kurt(a)OpenLDAP.org wrote: > Full_Name: Kurt Zeilenga > Version: HEAD > OS: MacoSX 10.4.8/FreeBSD 6.2 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (24.180.46.200) > Submitted by: kurt > > > On both MacOS X and FreeBSD, I see test047 fail trying to configure the server > via cn=config. Both built using ./configure --enable-backends > --enable-overlays, nothing fancy. > > Cleaning up test run directory leftover from previous run. > Running ./scripts/test049-sync-config... > running defines.sh > Starting producer slapd on TCP/IP port 9011... > Using ldapsearch to check that producer slapd is running... > Inserting syncprov overlay on producer... > Starting consumer slapd on TCP/IP port 9012... > Using ldapsearch to check that consumer slapd is running... > Configuring syncrepl on consumer... > Waiting 10 seconds for syncrepl to receive changes... > Using ldapsearch to check that syncrepl received config changes... > Adding schema and databases on producer... I see the same result on FreeBSD 6.2. It appears to be because libfetch was detected by configure and used here, and libfetch failed to open the FILE URLs that load the necessary schema. > ldapadd failed for database config (21)! > > where test.out contains: > ldap_add: Invalid syntax (21) > additional info: olcSuffix: value #0 invalid per syntax > > and the LDIF was: > dn: olcDatabase={1}bdb,cn=config > objectClass: olcDatabaseConfig > objectClass: olcbdbConfig > olcDatabase: {1}bdb > olcSuffix: dc=example,dc=com > olcDbDirectory: ./db > olcRootDN: cn=Manager,dc=example,dc=com > olcRootPW: secret > olcSyncRepl: rid=002 provider=ldap://localhost:9011/ > binddn="cn=Manager,dc=example,dc=com" bindmethod=simple > credentials=secret searchbase="dc=example,dc=com" type=refreshOnly > interval=00:00:00:10 > olcUpdateRef: ldap://localhost:9011/ > > dn: olcOverlay=syncprov,olcDatabase={1}bdb,cn=config > changetype: add > objectClass: olcOverlayConfig > objectClass: olcSyncProvConfig > olcOverlay: syncprov > > > > -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5117) test049/test050 failures
by kurt＠OpenLDAP.org 02 Sep '07

02 Sep '07

Full_Name: Kurt Zeilenga Version: HEAD OS: MacoSX 10.4.8/FreeBSD 6.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.180.46.200) Submitted by: kurt On both MacOS X and FreeBSD, I see test047 fail trying to configure the server via cn=config. Both built using ./configure --enable-backends --enable-overlays, nothing fancy. Cleaning up test run directory leftover from previous run. Running ./scripts/test049-sync-config... running defines.sh Starting producer slapd on TCP/IP port 9011... Using ldapsearch to check that producer slapd is running... Inserting syncprov overlay on producer... Starting consumer slapd on TCP/IP port 9012... Using ldapsearch to check that consumer slapd is running... Configuring syncrepl on consumer... Waiting 10 seconds for syncrepl to receive changes... Using ldapsearch to check that syncrepl received config changes... Adding schema and databases on producer... ldapadd failed for database config (21)! where test.out contains: ldap_add: Invalid syntax (21) additional info: olcSuffix: value #0 invalid per syntax and the LDIF was: dn: olcDatabase={1}bdb,cn=config objectClass: olcDatabaseConfig objectClass: olcbdbConfig olcDatabase: {1}bdb olcSuffix: dc=example,dc=com olcDbDirectory: ./db olcRootDN: cn=Manager,dc=example,dc=com olcRootPW: secret olcSyncRepl: rid=002 provider=ldap://localhost:9011/ binddn="cn=Manager,dc=example,dc=com" bindmethod=simple credentials=secret searchbase="dc=example,dc=com" type=refreshOnly interval=00:00:00:10 olcUpdateRef: ldap://localhost:9011/ dn: olcOverlay=syncprov,olcDatabase={1}bdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov

1 0

Re: (ITS#5114) pcache cache results for searches that hit size/timelimit
by ando＠sys-net.it 01 Sep '07

01 Sep '07

ando(a)sys-net.it wrote: Ralf, This patch should now work as expected. <http://www.sys-net.it/~ando/Download/pcache_sizelimit.patch> Does it harmonize with your improvements? Or, if you prefer, first commit your changes, and I'll harmonize the rest. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5114) pcache cache results for searches that hit size/timelimit
by ando＠sys-net.it 01 Sep '07

01 Sep '07

Howard Chu wrote: > If the client provides a sizelimit, save that away. Forward the request > with no sizelimit, so the cache can see everything. > > If the forwarded request hits a sizelimit, I think we can still use the > result. While there's no guarantee that repeated attempts to search the > remote server would return the exact same set of entries, there's also > no harm done if the cache does so. > > But if the result exceeds the cache's sizelimit, the result set must be > uncached, same as now. Well, I don't quite agree about this. In fact, if we know in advance that the cache can only cache up to <entry_limit>, removing the client requested size limit might lead to waste of resources, because a search could then potentially return much many entries than <entry_limit>, which wouldn't be cached nor returned to the client, thus defeating the purpose of caching. So if the client requests a sizelimit <client_sl>, we should: if <client_sl> > <entry_limit>, leave it in place. If less than <entry_limit> entries result, fine; if less than <client_sl> entries result, fine but don't cache; otherwise, return LDAP_SIZELIMIT_EXCEEDED. if <client_sl> < <entry_limit>, set size limit to <entry_limit>. If less than <client_sl> entries result, fine; if less than <entry_limit> entries result, return LDAP_SIZE_LIMIT, but keep caching; otherwise, don't cache at all. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5114) pcache cache results for searches that hit size/timelimit
by ando＠sys-net.it 01 Sep '07

01 Sep '07

hyc(a)symas.com wrote: > Can you spell out again what behavior you're aiming for? > > I think what makes sense so far is: > If the client provides a sizelimit, save that away. Forward the request with no > sizelimit, so the cache can see everything. OK. > If the forwarded request hits a sizelimit, I think we can still use the result. In principle, yes. But not with current query containment, because if the sizelimit is hit, say, with mail=*(a)example.com, then current query containment would indicate that mail=foo(a)example.com is contained in the sizelimit-hit query, but if mail=foo(a)example.com exists but is not contained in the subset of mail=*(a)example.com that is cached, nothing would be returned. > While there's no guarantee that repeated attempts to search the remote server > would return the exact same set of entries, there's also no harm done if the > cache does so. > > But if the result exceeds the cache's sizelimit, the result set must be > uncached, same as now. Yes, but the query would be cached (as failing), and this would make query containment behave as above. I think I'm missing where query containment can be modified to not check whether a query is contained in that failing because sizelimit. p. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5114) pcache cache results for searches that hit size/timelimit
by hyc＠symas.com 01 Sep '07

01 Sep '07

ando(a)sys-net.it wrote: > ando(a)sys-net.it wrote: > >> Please disregard; there's still a couple of issues that I wasn't aware >> and that need to be dealt with. Actually, caching those results may >> make further requests that look compatible with this to erroneously use >> that dataset. > > The issue here is that a search exceeding sizelimit, if not cached, > would destroy cacheability of all searches contained in it. Since a > search that could exceed sizelimit is likely to include substrings or > so, things like (mail=*domain.com) exceeding sizelimit would make all > searches for (mail=foo(a)domain.com) non cacheable. I fear there's little > to do about this, unless we want to heavily rework query containment > stuff (and I don't feel like, as I'm having hard times in understanding > what that code does). So I have now a bottomline fix that handles > sizelimit correctly, but makes all cacheable queries contained in the > offending one no longer answerable. Can you spell out again what behavior you're aiming for? I think what makes sense so far is: If the client provides a sizelimit, save that away. Forward the request with no sizelimit, so the cache can see everything. If the forwarded request hits a sizelimit, I think we can still use the result. While there's no guarantee that repeated attempts to search the remote server would return the exact same set of entries, there's also no harm done if the cache does so. But if the result exceeds the cache's sizelimit, the result set must be uncached, same as now. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5114) pcache cache results for searches that hit size/timelimit
by ando＠sys-net.it 01 Sep '07

01 Sep '07

ando(a)sys-net.it wrote: > Please disregard; there's still a couple of issues that I wasn't aware > and that need to be dealt with. Actually, caching those results may > make further requests that look compatible with this to erroneously use > that dataset. The issue here is that a search exceeding sizelimit, if not cached, would destroy cacheability of all searches contained in it. Since a search that could exceed sizelimit is likely to include substrings or so, things like (mail=*domain.com) exceeding sizelimit would make all searches for (mail=foo(a)domain.com) non cacheable. I fear there's little to do about this, unless we want to heavily rework query containment stuff (and I don't feel like, as I'm having hard times in understanding what that code does). So I have now a bottomline fix that handles sizelimit correctly, but makes all cacheable queries contained in the offending one no longer answerable. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5114) pcache cache results for searches that hit size/timelimit
by ando＠sys-net.it 01 Sep '07

01 Sep '07

ando(a)sys-net.it wrote: > here's a patch that implements the above. > > <http://www.sys-net.it/~ando/Download/pcache_sizelimit.patch> Please disregard; there's still a couple of issues that I wasn't aware and that need to be dealt with. Actually, caching those results may make further requests that look compatible with this to erroneously use that dataset. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5114) pcache cache results for searches that hit size/timelimit
by ando＠sys-net.it 01 Sep '07

01 Sep '07

ando(a)sys-net.it wrote: > I'm getting inclined towards handling this case like a regular search, > only replacing LDAP_SUCCESS with LDAP_SIZELIMIT_EXCEEDED. In fact, it > would be more appropriate to make this request not cacheable, because > there's no guarantee the server would return the same entries for > repeated searches, but for caching purposes this shouldn't really matter. Ralf, here's a patch that implements the above. <http://www.sys-net.it/~ando/Download/pcache_sizelimit.patch> Does it harmonize with your improvements? Cheers, 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5114) pcache cache results for searches that hit size/timelimit
by ando＠sys-net.it 01 Sep '07

01 Sep '07

Howard Chu wrote: >> Right. Well, I understand if no limit was hit the request would become >> cacheable. In this case, the approach you suggest would be fine. > > Of course the result size has to also fit within the cache's configured > size limit. We may want to add another type of negative caching record > here for this case "we already know the result set is too large, ignore > the cache DB"... I'm getting inclined towards handling this case like a regular search, only replacing LDAP_SUCCESS with LDAP_SIZELIMIT_EXCEEDED. In fact, it would be more appropriate to make this request not cacheable, because there's no guarantee the server would return the same entries for repeated searches, but for caching purposes this shouldn't really matter. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5102) back-perl build issues
by ando＠sys-net.it 01 Sep '07

01 Sep '07

hyc(a)symas.com wrote: > quanah(a)zimbra.com wrote: >> In the name of getting 2.4.5 released, I've updated to Kurt's suggestion >> until such a time as this can be acted upon otherwise. > > That's fine. > > But I think renaming config.h to slapconf.h is a good idea anyway. > > Another thing that has nagged me ever since we unified the slap tools into > slapd - should have renamed slapadd.c -> tooladd.c etc... Personally, not. Only, slap* makes them quite personal, while tool* sounds quite generic. It's like calling them db*: could be any type of db (no pun with Berkeley intended :). 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5102) back-perl build issues
by hyc＠symas.com 01 Sep '07

01 Sep '07

quanah(a)zimbra.com wrote: > In the name of getting 2.4.5 released, I've updated to Kurt's suggestion > until such a time as this can be acted upon otherwise. That's fine. But I think renaming config.h to slapconf.h is a good idea anyway. Another thing that has nagged me ever since we unified the slap tools into slapd - should have renamed slapadd.c -> tooladd.c etc... Any objections? -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5102) back-perl build issues
by quanah＠zimbra.com 01 Sep '07

01 Sep '07

--On August 25, 2007 7:34:22 AM +0000 ando(a)sys-net.it wrote: > Kurt Zeilenga wrote: > >>> ConfigReply is declared in slapd/config.h; could it be another, >>> system-related config.h is present in an earlier include path? >>> >>> Even though, I see in the above cc command-line -I .. is present... >> >> Personally, I think have -I., -I.., etc. is really bad. This causes >> # include "config.h" >> and >> # include <config.h> >> >> to be equivalent. However, there could be both a local config.h and a >> config.h somewhere in the system include directory. >> >> I would be better if slapd/config.h was included here by: >> # include "../config.h" >> >> and -I.. not be added to the include path. It possible -I.. is causing >> a system header to be eclipsed by the local header. > > -I.. is needed to include slap.h, proto-slap.h, ... > > I'd rather rename config.h, which is quite generic, into slapconf.h or so. In the name of getting 2.4.5 released, I've updated to Kurt's suggestion until such a time as this can be acted upon otherwise. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: ITS#5112 -> 4
by rhafer＠suse.de 31 Aug '07

31 Aug '07

On Thursday 30 August 2007 20:34, Pierangelo Masarati wrote: > Ralf, > > are you working at ITS#5112-4? Yes. I have a fix for #5112 (the memory leak) mostly ready. As you/Howard suggested I just moved the cache populating code into the cleanup handler, seems to work quite well and has the advantage that final result is send to the client a lot earlier when caching large results (as you already noted). I am currently looking into fixing #5113. Haven't worked on #5114 yet, but the basic fix should be fairly easy. Changing the code to handle the limits inside pcache might be a bit harder though. > I might work on them during the weekend, > if you don't. It is my intention to avoid interfering with the release > of 2.4.5, though. Yes, that's what I intend as well. That's why I didn't submit anything yet. -- Ralf

1 0

Re: (ITS#5116) registeredAddress cannot be deleted
by binoy＠cordys.com 31 Aug '07

31 Aug '07

Hi, Please ignore the earlier message. It was a mistake. >Quanah Gibson-Mount [quanah(a)zimbra.com] wrote >This isn't a bug. Fix the way you delete the attribute. I use LDAPModification mdfn = new LDAPModification(LDAPModification.DELETE, entry.getAttribute("registeredAddress")); connection.modify(entry.getDN(), mdfn); Any suggestion on how should I correct this? Thanks and Regards, Binoy Joseph *********************************************************************** The information in this message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, or distribution of the message, or any action or omission taken by you in reliance on it is prohibited and may be unlawful. Please immediately contact the sender if you have received this message in error. This email does not constitute any commitment from Cordys Holding BV or any of its subsidiaries except when expressly agreed in a written agreement between the intended recipient and Cordys Holding BV or its subsidiaries. ***********************************************************************

1 0

ITS#5112 -> 4
by ando＠sys-net.it 30 Aug '07

30 Aug '07

Ralf, are you working at ITS#5112-4? I might work on them during the weekend, if you don't. It is my intention to avoid interfering with the release of 2.4.5, though. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5116) registeredAddress cannot be deleted
by quanah＠zimbra.com 30 Aug '07

30 Aug '07

--On Thursday, August 30, 2007 9:28 AM +0000 binoy(a)cordys.com wrote: > Full_Name: Binoy > Version: 2.2.26 > OS: Windows > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (210.210.79.19) > > > The attribute registeredAddress of an authenticationUser, once entered; > cannot be deleted. The error says, no equality matching rule. This isn't a bug. Fix the way you delete the attribute. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5116) registeredAddress cannot be deleted
by binoy＠cordys.com 30 Aug '07

30 Aug '07

Full_Name: Binoy Version: 2.2.26 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (210.210.79.19) The attribute registeredAddress of an authenticationUser, once entered; cannot be deleted. The error says, no equality matching rule.

1 0

Re: (ITS#5115) SASL authentication for AD
by quanah＠zimbra.com 30 Aug '07

30 Aug '07

--On Wednesday, August 29, 2007 6:25 PM +0000 rbeckett(a)exelixis.com wrote: > Any help would be appreciated. The ITS system is for bugs, not for issues you have building OpenLDAP. I suggest reading the OpenLDAP FAQ entries on linking, and becoming generally familiar with how to build software in non-standard paths. The FAQ entry can be found at: <http://www.openldap.org/faq/data/cache/1113.html> My OpenSSL build looked like: %configure env CC=/usr/local/bin/gcc CFLAGS='-g -O2' CXXFLAGS='-g -O2' \ PERL=/usr/bin/perl LD_RUN_PATH=/usr/local/lib \ ./Configure --prefix=/usr/local --openssldir=/usr/local/openssl \ shared linux-x86_64 -g -O2 %build env LD_RUN_PATH="/usr/local/lib" make %install env LD_LIBRARY_PATH="/usr/local/lib" \ LD_RUN_PATH="/usr/local/lib" \ make install INSTALL_PREFIX=%package% Note the use of LD_RUN_PATH. My OpenLDAP build looked like: %configure LD_LIBRARY_PATH="/usr/local/lib" CC=/usr/local/bin/gcc CXX=/usr/local/bin/g++ CFLAGS='-g -O2 -DSLAP_LIGHTWEIGHT_DISPATCHER' CXXFLAGS='-g -O2' sh configure --datadir='${prefix}/lib' --libexecdir='${prefix}/lib' --sharedstatedir='${prefix}/lib' \ --prefix=/usr/local \ --disable-ipv6 \ --with-cyrus-sasl \ --with-tls \ --enable-dynamic \ --enable-slapd \ --enable-modules \ --enable-spasswd \ --enable-rewrite \ --enable-rlookups \ --enable-wrappers \ --enable-backends=mod \ --disable-shell \ --disable-sql \ --enable-overlays=mod \ --enable-slurpd=yes \ --enable-slapi=yes make depend %build make -j3 %check make test %install make install DESTDIR=%package% STRIP="" I'll also note that the error you are receiving from the SASL bind has nothing to do with SSL specifically. All it notes is that the AD server has no SASL mechanisms presented that match the SASL mechanisms available to OpenLDAP. If you are wanting to support SASL/EXTERNAL, you'll definitely need to fix your build with OpenSSL support. I've compiled OpenSSL into /usr/local on many occassions without problem, but I use the correct flags to gcc, too, which I don't see indicated in your build. You do not indicate whether or not you link OpenLDAP against cyrus-sasl, but that will be necessary for support of some of the other SASL mechanisms. If you plan on doing SASL/GSSAPI binds to AD, you'll also need to build a Kerberos distribution for its libraries (I suggest Heimdal), and link cyrus-sasl against that before building OpenLDAP linked against cyrus-sasl. You may also want to read: <http://www.stanford.edu/services/directory/openldap/configuration/> --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5115) SASL authentication for AD
by rbeckett＠exelixis.com 29 Aug '07

29 Aug '07

Full_Name: Richard Beckett Version: 2.3.38 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (65.209.203.254) I have posted this before but still have not resolved the problem. I am building OpenLDAP 2.3.38. on a RHEL ES v4 host When I make it without having first built TLS/SSL (openssl-0.9.8e) it builds and runs fine. However I need the SSL and SASL to authenticate to an Active Directory server. When I build SSL as follows: ./configure shared --openssldir=/usr/local make make install and then try to make OpenLDAP I ge the following: cc -g -O2 -o apitest apitest.o ./.libs/libldap.a /usr/local/src/LDAP/openldap-2.3.38/libraries/liblber/.libs/liblber.a -L/usr/kerberos/lib -L/lib -L/usr/lib/mysql ../../libraries/liblber/.libs/liblber.a ../../libraries/liblutil/liblutil.a /usr/lib/libsasl2.so -ldl -lcrypt -lssl -lcrypto -lresolv ./.libs/libldap.a(os-ip.o)(.text+0x606): In function `ldap_connect_to_host': /usr/local/src/LDAP/openldap-2.3.38/libraries/libldap/os-ip.c:205: warning: `sys_errlist' is deprecated; use `strerror' or `strerror_r' instead ./.libs/libldap.a(os-ip.o)(.text+0x5fd):/usr/local/src/LDAP/openldap-2.3.38/libraries/libldap/os-ip.c:205: warning: `sys_nerr' is deprecated; use `strerror' or `strerror_r' instead ./.libs/libldap.a(tls.o)(.text+0x593): In function `sb_tls_bio_read': /usr/local/src/LDAP/openldap-2.3.38/libraries/libldap/tls.c:676: undefined reference to `BIO_clear_flags' ./.libs/libldap.a(tls.o)(.text+0x5b8):/usr/local/src/LDAP/openldap-2.3.38/libraries/libldap/tls.c:680: undefined reference to `BIO_set_flags' ./.libs/libldap.a(tls.o)(.text+0x60b): In function `sb_tls_bio_write': /usr/local/src/LDAP/openldap-2.3.38/libraries/libldap/tls.c:703: undefined reference to `BIO_clear_flags' ./.libs/libldap.a(tls.o)(.text+0x630):/usr/local/src/LDAP/openldap-2.3.38/libraries/libldap/tls.c:707: undefined reference to `BIO_set_flags' ./.libs/libldap.a(tls.o)(.text+0x19f0): In function `ldap_pvt_tls_init_def_ctx': /usr/local/src/LDAP/openldap-2.3.38/libraries/libldap/tls.c:374: undefined reference to `SSL_CTX_set_info_callback' collect2: ld returned 1 exit status make[2]: *** [apitest] Error 1 make[2]: Leaving directory `/usr/local/src/LDAP/openldap-2.3.38/libraries/libldap' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/usr/local/src/LDAP/openldap-2.3.38/libraries' make: *** [all-common] Error 1 My environment is: HOSTNAME=ldaplx01.exelixis.com TERM=xterm SHELL=/bin/bash HISTSIZE=1000 SSH_CLIENT=::ffff:172.29.4.19 51159 22 OLDPWD=/usr/local/lib SSH_TTY=/dev/pts/1 USER=root LD_LIBRARY_PATH=/usr/local/lib LS_COLORS=no=00:fi=00:di=00;34:ln=00;36:pi=40;33:so=00;35:bd=40;33;01:cd=40;33;01:or=01;05;37;41:mi=01;05;37;41:ex=00;32:*.cmd=00;32:*.exe=00;32:*.com=00;32:*.btm=00;32:*.bat=00;32:*.sh=00;32:*.csh=00;32:*.tar=00;31:*.tgz=00;31:*.arj=00;31:*.taz=00;31:*.lzh=00;31:*.zip=00;31:*.z=00;31:*.Z=00;31:*.gz=00;31:*.bz2=00;31:*.bz=00;31:*.tz=00;31:*.rpm=00;31:*.cpio=00;31:*.jpg=00;35:*.gif=00;35:*.bmp=00;35:*.xbm=00;35:*.xpm=00;35:*.png=00;35:*.tif=00;35: MAIL=/var/spool/mail/root PATH=/opt/quest/bin:/opt/quest/sbin:/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin:/root/bin INPUTRC=/etc/inputrc PWD=/usr/local/src/LDAP/openldap-2.3.38 LANG=en_US.UTF-8 SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass SHLVL=1 HOME=/root LOGNAME=root SSH_CONNECTION=::ffff:172.29.4.19 51159 ::ffff:172.29.24.108 22 LESSOPEN=|/usr/bin/lesspipe.sh %s G_BROKEN_FILENAMES=1 _=/bin/env Without SSL I am unable to authenticate to the Active Directory server. I get the following message: SASL/EXTERNAL authentication started ldap_perror ldap_sasl_interactive_bind_s: Unknown authentication method (-6) additional info: SASL(-4): no mechanism available: I have ssl yes set in /etc/ldap.conf and I assume (always dangerous) that the problem lies with the fact that I am unable to build ldap with SSL. Any help would be appreciated. Richard-Beckett-070829

1 0

Re: (ITS#5114) pcache cache results for searches that hit size/timelimit
by hyc＠symas.com 29 Aug '07

29 Aug '07

ando(a)sys-net.it wrote: > rhafer(a)suse.de wrote: >> On Wednesday 29 August 2007 18:48, ando(a)sys-net.it wrote: >>> rhafer(a)suse.de wrote: >>>> But a malicous client can then just send requests with sizelimit 1. Those >>>> query will get cached and the database is of no real use anymore (IMO). >>> Well, in this case, the proxycache should either change the sizelimit >>> (and the timelimit) to unlimited, and deal with client-requested limits >>> locally, >> This seems like the nicest approach to solve the problem. But seems to be a >> bit more effort. > > I'd go this way, yes. > >> My suggest for a quick fix for this issue would be to just not cache queries >> that return one off the _LIMIT_EXCEEDED error codes. Probably with checking >> if it was a client-requested limit or a limit of the server side (in which >> case we could probably cache the results). > > Then please make a clear statement in the code that it's a temporary > workaround, so it is easier to spot and remove, eventually. > >>> or consider uncacheable those requests that specify a time or a >>> size limit. >> Well that would cause even those queries being uncachable that would not hit >> the requested limit. If I understand you correctly. > > Right. Well, I understand if no limit was hit the request would become > cacheable. In this case, the approach you suggest would be fine. Of course the result size has to also fit within the cache's configured size limit. We may want to add another type of negative caching record here for this case "we already know the result set is too large, ignore the cache DB"... -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5114) pcache cache results for searches that hit size/timelimit
by ando＠sys-net.it 29 Aug '07

29 Aug '07

rhafer(a)suse.de wrote: > On Wednesday 29 August 2007 18:48, ando(a)sys-net.it wrote: >> rhafer(a)suse.de wrote: >>> But a malicous client can then just send requests with sizelimit 1. Those >>> query will get cached and the database is of no real use anymore (IMO). >> Well, in this case, the proxycache should either change the sizelimit >> (and the timelimit) to unlimited, and deal with client-requested limits >> locally, > This seems like the nicest approach to solve the problem. But seems to be a > bit more effort. I'd go this way, yes. > My suggest for a quick fix for this issue would be to just not cache queries > that return one off the _LIMIT_EXCEEDED error codes. Probably with checking > if it was a client-requested limit or a limit of the server side (in which > case we could probably cache the results). Then please make a clear statement in the code that it's a temporary workaround, so it is easier to spot and remove, eventually. >> or consider uncacheable those requests that specify a time or a >> size limit. > Well that would cause even those queries being uncachable that would not hit > the requested limit. If I understand you correctly. Right. Well, I understand if no limit was hit the request would become cacheable. In this case, the approach you suggest would be fine. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5114) pcache cache results for searches that hit size/timelimit
by rhafer＠suse.de 29 Aug '07

29 Aug '07

On Wednesday 29 August 2007 18:48, ando(a)sys-net.it wrote: > rhafer(a)suse.de wrote: > > But a malicous client can then just send requests with sizelimit 1. Those > > query will get cached and the database is of no real use anymore (IMO). > > Well, in this case, the proxycache should either change the sizelimit > (and the timelimit) to unlimited, and deal with client-requested limits > locally, This seems like the nicest approach to solve the problem. But seems to be a bit more effort. My suggest for a quick fix for this issue would be to just not cache queries that return one off the _LIMIT_EXCEEDED error codes. Probably with checking if it was a client-requested limit or a limit of the server side (in which case we could probably cache the results). > or consider uncacheable those requests that specify a time or a > size limit. Well that would cause even those queries being uncachable that would not hit the requested limit. If I understand you correctly. > On the contrary, they should be considered answerable if a > corresponding request is cached, and the limits should be checked locally. -- Ralf

1 0

Re: (ITS#5112) memory leak in pcache overlay
by hyc＠symas.com 29 Aug '07

29 Aug '07

Pierangelo Masarati wrote: > hyc(a)symas.com wrote: > >> Ah yes, that's correct. I misspoke - the DB is written when the cache has >> received an LDAP_RESULT from the remote server. The client gets this result >> when the cache has finished writing. We could move the DB write to a separate >> cleanup handler instead of running it in the response handler, which would free >> up the client sooner. > > I also noticed that > <http://www.openldap.org/lists/openldap-devel/200708/msg00033.html>, and > I wanted to do something similar, but considering Ralf's observations, > multiple clients concurrently running the same search request would > cause it to be cached multiple times, because until the first one is not > cached the others will not find it. OTOH, letting the others know it's > being cached, and making them wait until caching is done would imply > some delay, which could be long based on how many entries are being > cached. However, given the purpose of a proxy cache, and considering > that so many identical searches are not likely to occur simultaneously, > I'd prefer to queue requests that are being cached. Agreed. Even with a delay it ought to be faster than making the remote search again. But this is probably not worth changing at this moment. Let's get 2.4.5 out first. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5112) memory leak in pcache overlay
by ando＠sys-net.it 29 Aug '07

29 Aug '07

hyc(a)symas.com wrote: > Ah yes, that's correct. I misspoke - the DB is written when the cache has > received an LDAP_RESULT from the remote server. The client gets this result > when the cache has finished writing. We could move the DB write to a separate > cleanup handler instead of running it in the response handler, which would free > up the client sooner. I also noticed that <http://www.openldap.org/lists/openldap-devel/200708/msg00033.html>, and I wanted to do something similar, but considering Ralf's observations, multiple clients concurrently running the same search request would cause it to be cached multiple times, because until the first one is not cached the others will not find it. OTOH, letting the others know it's being cached, and making them wait until caching is done would imply some delay, which could be long based on how many entries are being cached. However, given the purpose of a proxy cache, and considering that so many identical searches are not likely to occur simultaneously, I'd prefer to queue requests that are being cached. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5112) memory leak in pcache overlay
by hyc＠symas.com 29 Aug '07

29 Aug '07

rhafer(a)suse.de wrote: > On Wednesday 29 August 2007 18:10, Howard Chu wrote: >> Ralf Haferkamp wrote: >>> On Wednesday 29 August 2007 17:36, Howard Chu wrote: >>>> rhafer(a)suse.de wrote: >>>>> Full_Name: Ralf Haferkamp >>>>> Version: RE23, HEAD >>>>> >>>>> Valgrind gives me the log pasted below when I abort an ldapsearch >>>>> command (CTRL-C) that is running against a back-ldap database that uses >>>>> the pcache overlay. >>>> Makes sense. We need to use the cleanup handler and free the saved query >>>> info if op->o_abandon is set. Do you want to code this up? >>> I am still working on that, but checking for op->o_abandon doesn't seem >>> to be enough. E.g. if I abort the ldapsearch while slapd is updating its >>> cache (all entries have been returned, but the final LDAP_RESULT to the >>> client is still missing) a filter_free in the cleanup handler will >>> invalidly free the filter. >>> >>> We somehow need to make sure that the query is only free'd if nothing has >>> been written to the cache database. >> I don't understand the problem. Nothing can get written to the DB until the >> LDAP_RESULT has been sent. I.e., rs->sr_result == REP_RESULT. > Hm, but the ldapsearch command only returns after the complete query result > has been written to the cache (at least here it behaves so), which can take > quite a while. So it seems to me that the client has not received the > LDAP_RESULT. Ah yes, that's correct. I misspoke - the DB is written when the cache has received an LDAP_RESULT from the remote server. The client gets this result when the cache has finished writing. We could move the DB write to a separate cleanup handler instead of running it in the response handler, which would free up the client sooner. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5114) pcache cache results for searches that hit size/timelimit
by ando＠sys-net.it 29 Aug '07

29 Aug '07

rhafer(a)suse.de wrote: > But a malicous client can then just send requests with sizelimit 1. Those > query will get cached and the database is of no real use anymore (IMO). Well, in this case, the proxycache should either change the sizelimit (and the timelimit) to unlimited, and deal with client-requested limits locally, or consider uncacheable those requests that specify a time or a size limit. On the contrary, they should be considered answerable if a corresponding request is cached, and the limits should be checked locally. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5114) pcache cache results for searches that hit size/timelimit
by rhafer＠suse.de 29 Aug '07

29 Aug '07

On Wednesday 29 August 2007 18:36, Pierangelo Masarati wrote: > hyc(a)symas.com wrote: > >> pcache currently cache the results of search that hit server- or > >> clientside size- or timelimits. That means that subsequent search will > >> get the (incomplete) results from the cache. I guess pcache should only > >> cache operations that returned LDAP_SUCCESS. > > > > Makes sense... > > Well, I agree for timelimit, but sizelimit might be questionable. In > fact, the only reason not to cache searches ending in sizelimit exceeded > is that the size limit may depend on the client's identity. But this is > true in general also for access to entries and to entry data, but we > don't cache based on the identity of the client, so data cached with one > identity (set A) might differ from data that would be returned by > another identity for the very same search (set B), and both the relative > complement of A in B and of B in A may be not empty. So, if we accept > this for ACLs (no differences between the results returned for requests > with different identities) I don't see why we should differentiate with > respect to the size limit. But a malicous client can then just send requests with sizelimit 1. Those query will get cached and the database is of no real use anymore (IMO). -- Ralf

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs