- openldap-bugs - openldap.org

Re: (ITS#6200) slapd crashes under load w/ syncrepl
by richton＠rci.rutgers.edu 24 Aug '09

24 Aug '09

What does this look with top and/or in dmesg over the run time? Is it a simple out-of-memory? Definitely a bit of a gross method, but what's ls -lh core show for size? (If so, is it warranted given your load or is there a leak, etc etc...and of course make sure you're up to date on the surrounding packages, OpenLDAP isn't the only thing that can leak.)

1 0

Re: (ITS#6270) Conflict between ppolicy (pwdReset flag) and unique overlays
by michael＠stroeder.com 24 Aug '09

24 Aug '09

michael(a)stroeder.com wrote: > clem.oudot(a)gmail.com wrote: >> I have a rootdn. An extract of my slapd.conf is : >> >> --- >> database bdb >> suffix dc=3Dexample,dc=3Dcom >> rootdn cn=3Dmanager,dc=3Dexample,dc=3Dcom >> rootpw secret >> directory /var/lib/ldap >> >> overlay ppolicy >> ppolicy_use_lockout >> ppolicy_hash_cleartext >> >> overlay unique >> unique_uri ldap:///ou=3Dusers,dc=3Dexample,dc=3Dcom?uid?sub?(objectClass=3D= >> inetOrgPerson) > > Could you please repost this without the broken quoted printables? Especially > the filter part of the value for 'unique_uri'. I suspect the ITS software messed this up because the direct Cc:-ed messages to me did not contain the messed up quoted printables. So here's what Clément orginally sent as excerpt of his config: --- database bdb suffix dc=example,dc=com rootdn cn=manager,dc=example,dc=com rootpw secret directory /var/lib/ldap overlay ppolicy ppolicy_use_lockout ppolicy_hash_cleartext overlay unique unique_uri ldap:///ou=users,dc=example,dc=com?uid?sub?(objectClass=inetOrgPerson) --- Ciao, Michael.

1 0

Re: (ITS#6270) Conflict between ppolicy (pwdReset flag) and unique overlays
by michael＠stroeder.com 24 Aug '09

24 Aug '09

clem.oudot(a)gmail.com wrote: > I have a rootdn. An extract of my slapd.conf is : > > --- > database bdb > suffix dc=3Dexample,dc=3Dcom > rootdn cn=3Dmanager,dc=3Dexample,dc=3Dcom > rootpw secret > directory /var/lib/ldap > > overlay ppolicy > ppolicy_use_lockout > ppolicy_hash_cleartext > > overlay unique > unique_uri ldap:///ou=3Dusers,dc=3Dexample,dc=3Dcom?uid?sub?(objectClass=3D= > inetOrgPerson) Could you please repost this without the broken quoted printables? Especially the filter part of the value for 'unique_uri'. Ciao, Michael.

1 0

(ITS#6273) NSS overlay (nssov) fails to load
by battery＠writeme.com 24 Aug '09

24 Aug '09

Full_Name: Matt Kassawara Version: 2.4.17 OS: Ubuntu 9.10 (Karmic) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (8.7.94.151) Loading the nssov module using 'ldapadd' reports an olcModuleLoad handler error... # ldapadd -H ldapi:/// -Y external SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 dn: cn=module{2},cn=config objectclass: olcmodulelist cn: module{2} olcmoduleload: {0}nssov olcmodulepath: /usr/lib/ldap adding new entry "cn=module{2},cn=config" ldap_add: Other (e.g., implementation specific) error (80) additional info: <olcModuleLoad> handler exited with 1 Output from 'slapd' in debug level 7 (incorrectly) reports file not found... oc_check_required entry (cn=module{2},cn=config), objectClass "olcModuleList" oc_check_allowed type "objectClass" oc_check_allowed type "cn" oc_check_allowed type "olcModuleLoad" oc_check_allowed type "olcModulePath" oc_check_allowed type "structuralObjectClass" lt_dlopenext failed: (nssov) file not found Output from 'LD_DEBUG' reveals undefined symbol 'ber_bvmatch' in nssov.so.0... 18016: /usr/lib/ldap/nssov.so.0: error: symbol lookup error: undefined symbol: ber_bvmatch (fatal) 18016: 18016: file=/usr/lib/ldap/nssov.so.0 [0]; destroying link map

1 0

(ITS#6272) test045 freed memory access
by richton＠nbcs.rutgers.edu 24 Aug '09

24 Aug '09

Full_Name: Aaron Richton Version: RE24 OS: Solaris 9 URL: https://www.nbcs.rutgers.edu/~richton/richton-bt-200908221228.txt Submission from: (NULL) (128.6.31.135) t@5 (l@5) terminated by signal SEGV (no mapping at the fault address) Current function is connection_abandon 729 op.orn_msgid = o->o_msgid; (dbx) where current thread: t@5 =>[1] connection_abandon(c = 0x106df088), line 729 in "connection.c" [2] connection_closing(c = 0x106df088, why = 0x2859e0 "connection lost"), line 777 in "connection.c" [3] connection_read(s = 11, cri = 0xfd3ffd64), line 1427 in "connection.c" [4] connection_read_thread(ctx = 0xfd3ffe0c, argv = 0xb), line 1245 in "connection.c" [5] ldap_int_thread_pool_wrapper(xpool = 0x10491f08), line 685 in "tpool.c" (dbx) print o->o_hdr o->o_hdr = 0xdeadbeef Full backtrace in ITS link. testrun directory: https://www.nbcs.rutgers.edu/~richton/richton-testrun-200908221228.tar.bz2

1 0

Re: (ITS#6271) syncprov use of freed mutex
by masarati＠aero.polimi.it 24 Aug '09

24 Aug '09

richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: RE24 > OS: Solaris 9 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.6.31.135) > > > Sol9+libumem+RE24 (current). I have five core files all with an aborting thread > showing: > > current thread: t@8 > [1] __lwp_kill(0x0, 0x6, 0x0, 0xfffffff8, 0x0, 0xfb3feec1), at 0xff31feb0 > [2] Abort(0xfb3fef18, 0xfb3fef18, 0x3a, 0x39, 0x81010100, 0xff00), at > 0xff056f9c > [3] panic(0xff065e34, 0x0, 0x0, 0x1, 0x0, 0xfb3ff139), at 0xff057094 > [4] _ceil_prio_inherit(0xef, 0x0, 0x10807258, 0xff078000, 0xff0613bc, 0x0), at > 0xff05ff10 > [5] mutex_lock_internal(0xad, 0x0, 0xff040e00, 0x23, 0x7, 0x10fed159), at > 0xff0614bc > =>[6] ldap_pvt_thread_mutex_lock(mutex = 0x10807258), line 296 in "thr_posix.c" > [7] syncprov_op_mod(op = 0xfb3ff8e8, rs = 0xfb3ff5a0), line 1965 in > "syncprov.c" > [8] overlay_op_walk(op = 0xfb3ff8e8, rs = 0xfb3ff5a0, which = op_modify, oi = > 0x1083b088, on = 0x1083ad88), line 659 in "backover.c" > [9] over_op_func(op = 0xfb3ff8e8, rs = 0xfb3ff5a0, which = op_modify), line > 721 in "backover.c" > [10] over_op_modify(op = 0xfb3ff8e8, rs = 0xfb3ff5a0), line 755 in > "backover.c" > [11] syncrepl_updateCookie(si = 0x10417a88, op = 0xfb3ff8e8, pdn = 0x10845b68, > syncCookie = 0xfb3ff710), line 3045 in "syncrepl.c" > [12] do_syncrep2(op = 0xfb3ff8e8, si = 0x10417a88), line 1177 in "syncrepl.c" > [13] do_syncrepl(ctx = 0xfb3ffe0c, arg = 0x10807d08), line 1358 in > "syncrepl.c" > [14] connection_read_thread(ctx = 0xfb3ffe0c, argv = 0x1c), line 1254 in > "connection.c" > [15] ldap_int_thread_pool_wrapper(xpool = 0x10491f08), line 685 in "tpool.c" > > In Frame 7, mt->mt_mods = 0xdeadbeef. Looks like libumem caught a post-free() > access. Looks like someone else got to the end of the modifications list and destroyed everything... p.

1 0

(ITS#6271) syncprov use of freed mutex
by richton＠nbcs.rutgers.edu 24 Aug '09

24 Aug '09

Full_Name: Aaron Richton Version: RE24 OS: Solaris 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.6.31.135) Sol9+libumem+RE24 (current). I have five core files all with an aborting thread showing: current thread: t@8 [1] __lwp_kill(0x0, 0x6, 0x0, 0xfffffff8, 0x0, 0xfb3feec1), at 0xff31feb0 [2] Abort(0xfb3fef18, 0xfb3fef18, 0x3a, 0x39, 0x81010100, 0xff00), at 0xff056f9c [3] panic(0xff065e34, 0x0, 0x0, 0x1, 0x0, 0xfb3ff139), at 0xff057094 [4] _ceil_prio_inherit(0xef, 0x0, 0x10807258, 0xff078000, 0xff0613bc, 0x0), at 0xff05ff10 [5] mutex_lock_internal(0xad, 0x0, 0xff040e00, 0x23, 0x7, 0x10fed159), at 0xff0614bc =>[6] ldap_pvt_thread_mutex_lock(mutex = 0x10807258), line 296 in "thr_posix.c" [7] syncprov_op_mod(op = 0xfb3ff8e8, rs = 0xfb3ff5a0), line 1965 in "syncprov.c" [8] overlay_op_walk(op = 0xfb3ff8e8, rs = 0xfb3ff5a0, which = op_modify, oi = 0x1083b088, on = 0x1083ad88), line 659 in "backover.c" [9] over_op_func(op = 0xfb3ff8e8, rs = 0xfb3ff5a0, which = op_modify), line 721 in "backover.c" [10] over_op_modify(op = 0xfb3ff8e8, rs = 0xfb3ff5a0), line 755 in "backover.c" [11] syncrepl_updateCookie(si = 0x10417a88, op = 0xfb3ff8e8, pdn = 0x10845b68, syncCookie = 0xfb3ff710), line 3045 in "syncrepl.c" [12] do_syncrep2(op = 0xfb3ff8e8, si = 0x10417a88), line 1177 in "syncrepl.c" [13] do_syncrepl(ctx = 0xfb3ffe0c, arg = 0x10807d08), line 1358 in "syncrepl.c" [14] connection_read_thread(ctx = 0xfb3ffe0c, argv = 0x1c), line 1254 in "connection.c" [15] ldap_int_thread_pool_wrapper(xpool = 0x10491f08), line 685 in "tpool.c" In Frame 7, mt->mt_mods = 0xdeadbeef. Looks like libumem caught a post-free() access.

1 0

Re: (ITS#6270) Conflict between ppolicy (pwdReset flag) and unique overlays
by clem.oudot＠gmail.com 24 Aug '09

24 Aug '09

2009/8/24 <michael(a)stroeder.com>: > clem.oudot(a)gmail.com wrote: >> Full_Name: Clement OUDOT >> Version: 2.4.16 >> OS: RHEL 5.2 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (83.145.72.122) >> >> I use both ppolicy and unique overlays. >> >> I try to modify the password of an account whose pwdReset attribute is s= et to >> TRUE. I get this LDAP error: >> >> ldap_modify: Insufficient access (50) >> =A0 =A0 =A0 =A0 additional info: unique_search failed > > Without seeing your configuration one cannot determine wheter you're hitt= ing > ITS#6108: "unique overlay and rootdn". > > http://www.openldap.org/its/index.cgi/Documentation?id=3D6108;selectid=3D= 6108 > > Ciao, Michael. Hello, I have a rootdn. An extract of my slapd.conf is : --- database bdb suffix dc=3Dexample,dc=3Dcom rootdn cn=3Dmanager,dc=3Dexample,dc=3Dcom rootpw secret directory /var/lib/ldap overlay ppolicy ppolicy_use_lockout ppolicy_hash_cleartext overlay unique unique_uri ldap:///ou=3Dusers,dc=3Dexample,dc=3Dcom?uid?sub?(objectClass=3D= inetOrgPerson) --- Cl=E9ment.

1 0

Re: (ITS#6270) Conflict between ppolicy (pwdReset flag) and unique overlays
by michael＠stroeder.com 24 Aug '09

24 Aug '09

clem.oudot(a)gmail.com wrote: > Full_Name: Clement OUDOT > Version: 2.4.16 > OS: RHEL 5.2 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (83.145.72.122) > > I use both ppolicy and unique overlays. > > I try to modify the password of an account whose pwdReset attribute is set to > TRUE. I get this LDAP error: > > ldap_modify: Insufficient access (50) > additional info: unique_search failed Without seeing your configuration one cannot determine wheter you're hitting ITS#6108: "unique overlay and rootdn". http://www.openldap.org/its/index.cgi/Documentation?id=6108;selectid=6108 Ciao, Michael.

1 0

(ITS#6270) Conflict between ppolicy (pwdReset flag) and unique overlays
by clem.oudot＠gmail.com 24 Aug '09

24 Aug '09

Full_Name: Clement OUDOT Version: 2.4.16 OS: RHEL 5.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.145.72.122) Hello, I use both ppolicy and unique overlays. I try to modify the password of an account whose pwdReset attribute is set to TRUE. I get this LDAP error: ldap_modify: Insufficient access (50) additional info: unique_search failed In OpenLDAP logs, we can see: connection restricted to password changing only send_ldap_result: conn=20 op=2 p=3 send_ldap_result: err=50 matched="" text="Operations are restricted to bind/unbind/abandon/StartTLS/modify password" send_ldap_result: conn=20 op=2 p=3 send_ldap_result: err=50 matched="" text="unique_search failed" send_ldap_response: msgid=3 tag=103 err=50 So it seems the unique overlay cannot do a search because the connection is restricted by the ppolicy overlay.

1 0

Re: (ITS#6266) uninitialized var in overlays/dynlist.c:dl_cfgen()
by masarati＠aero.polimi.it 23 Aug '09

23 Aug '09

> hyc(a)symas.com writes: >> In the actual code, dlm is initialized to NULL. Therefore, dlml will get >> initialized to NULL > > Only initialized when dml is NULL, but the test > 'if ( dlml != NULL )' below is unconditional. Then dlml goes > out of scope, it doesn't keep the value between iterations. Should be fixed now, thanks. Please test. p.

1 0

Re: (ITS#6267) test030-relay fails with back-meta: line 79: kill: (23804) - No such process
by masarati＠aero.polimi.it 23 Aug '09

23 Aug '09

> masarati(a)aero.polimi.it wrote: >> Can't reproduce. > > Also happens with new checkout. See testrun/ available here: > > http://www.stroeder.com/temp/openldap-its6267-testrun-test030.tar.gz OK, that's about building as modules (back-meta needs back-ldap, should have tested straight ahead). Fixing... p.

1 0

Re: (ITS#6267) test030-relay fails with back-meta: line 79: kill: (23804) - No such process
by michael＠stroeder.com 22 Aug '09

22 Aug '09

masarati(a)aero.polimi.it wrote: > Can't reproduce. Also happens with new checkout. See testrun/ available here: http://www.stroeder.com/temp/openldap-its6267-testrun-test030.tar.gz > Did you start from a fresh checkout? Is your working directory in sync with what's available through anon CVS? Ciao, Michael.

1 0

(ITS#6269) Fails to include inter-library dependencies on QNX
by mkraai＠beckman.com 21 Aug '09

21 Aug '09

Full_Name: Matt Kraai Version: 2.4.17 OS: QNX 6.4.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (134.217.96.252) When built on QNX 6.4.1, libldap.so doesn't include inter-library dependency information. When an application tries to link against it, it fails because the symbols provided by the libraries that libldap.so should depend on aren't defined. Upgrading to a more recent version of libtool (e.g., 2.2.6) fixes this problem, since it knows how to handle inter-library dependencies on QNX. This can be done by installing libtool 2.2.6 and running the following commands in openldap's top-level source directory: aclocal libtoolize autoconf

1 0

Re: (ITS#6268) multi-master sync replication ldap_add error code 68 bug
by hyc＠symas.com 20 Aug '09

20 Aug '09

bcolston(a)xtec.com wrote: > Full_Name: Barry Colston > Version: 2.4.17 > OS: Fedora 10 > URL: > Submission from: (NULL) (209.255.208.219) > > > While testing sync replication, I encountered a situation in which a previously > deleted DN cannot be added again because the ldapadd command receives a 68 error > code. If I perform an ldapsearch command for the DN, the DN is not found. If I > try to add the DN, the add fails with a 68 error code. If I perform a slapcat > command for that DN, slapcat displays the record. This sounds like it's related to ITS#6097. -- -- Howard Chu CTO, 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#6257) libldap: getopt flag to return the SASL username
by masarati＠aero.polimi.it 20 Aug '09

20 Aug '09

> masarati(a)aero.polimi.it wrote: > I'd appreciate it very much if it would be exactly behave in the same way > like > all other string-valued options. On a somewhat related issue, I note that LDAP_OPT_X_SASL_MECHLIST returns a pointer to an array of chars that apparently cannot be mucked with. Assuming my understanding is correct, I wonder if this behavior is desirable or not, given the fact that if another mech is added, e.g. by adding a dynamic module, I expect this list to change. p.

1 0

(ITS#6268) multi-master sync replication ldap_add error code 68 bug
by bcolston＠xtec.com 20 Aug '09

20 Aug '09

Full_Name: Barry Colston Version: 2.4.17 OS: Fedora 10 URL: Submission from: (NULL) (209.255.208.219) While testing sync replication, I encountered a situation in which a previously deleted DN cannot be added again because the ldapadd command receives a 68 error code. If I perform an ldapsearch command for the DN, the DN is not found. If I try to add the DN, the add fails with a 68 error code. If I perform a slapcat command for that DN, slapcat displays the record. I have 3 multi-master servers in my configuration; all 3 are executing on the same physical server, listening on different ports and with separate copies of BDB databases. Each server is replicating to the other 2 servers (e.g., server 1 replicates to server 2 and server 3, server 2 replicates to server 1 and server 3, and server 3 replicates to server 1 and server 2) using the refreshAndPersist mode. I execute 3 shell scripts simultaneously, each of which adds a set of parent/child records using the ldapadd command and ldif files, then deletes the records using the ldapdelete command (each shell scripts adds and deletes about 267 records and each shell script operates on a separate set of DNs). The 3 shell scripts issue the ldapadd and ldapdelete commands against server 1 and repeat the add/delete cycle 10 times before exiting. After all 3 shell scripts finish, I compare the server 1 records against the server 2 records and compare the server 1 records against the server 3 records listing any differences. The method I normally execute the shell scripts results in 800 records being added then deleted 10 times, for a total of 8000 adds/deletes occurring. After executing the above 3 shell scripts multiple times (without bringing down slapd between executes), some records will fail to be added by the ldapadd command because the ldapadd command returns an error code of 68. After this occurs, I execute an ldapsearch command for the DN of the record that received the 68 error; the ldapsearch command fails to find the record (which is correct because the record was deleted). If I perform a slapcat command for the DN against server 1's BDB files, slapcat finds the record, but it is listed with an objectClass and structuralObjectClass of "glue" (which are different than when the record was added.) Slapcat performed against the 2 other master servers (server 2 and server 3) do not display a record. When this error occurs, there are usually multiple records that fail to add with an error code of 68. I have removed all BDB index files and rerun the slapindex command, but the DN is still not found with the ldapsearch command and fails to be added because of a 68 error code. This condition is not repeatable on demand, but if I run my scripts doing ldapadd/ldapdelete multiple times, it will eventually occur. This error appears to be related to the value specified in my slapd.conf file for "syncprov-sessionlog". I have changed the value of "syncprov-sessionlog", with the following results: syncprov-sessionlog 5000 - usually execution 3 or 4 results in the ldapadd 68 error (e.g., the first 2 executions of 8000 adds/deletes work OK) syncprov-sessionlog 50000 - usually execution 6 or 7 results in the ldapadd 68 error (e.g., the first 5 executions of 8000 adds/deletes work OK) syncprov-sessionlog 200 - usually execution 2 or 3 results in the ldapadd 68 error (e.g., the first execution of 8000 adds/deletes works OK) syncprov-sessionlog not specified - usually execution 2 or 3 results in 1 of the slapd servers crashing with a segmentation fault (usually server 1, but sometimes the other servers) (example of crash output is *** glibc detected *** /tmp/reptest/openldap/openldap-2.4.17/libexec/slapd: malloc(): memory corruption (fast): 0x9e61f860 ***) I am using BDB 4.6.21 and have tested with the 4 BDB patches applied and not applied (the 68 error occurs using BDB without the patches and BDB with the patches).

1 0

Re: (ITS#6152) proxycache enhancements
by hyc＠symas.com 20 Aug '09

20 Aug '09

hyc(a)symas.com wrote: > hyc(a)symas.com wrote: >> The TTR feature is now available for testing in HEAD. (As well as the offline >> mode switch.) > Bind caching is now working in HEAD as well. manpage is up to date, test020 > needs some new tests still. Working on that... And passwordModify will now update the cached Bind info. So that's it for the code changes, I'm just looking at the test020 script and config files to decide how to add tests for refresh, expiration, bind, and pwdMod. -- -- Howard Chu CTO, 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#6152) proxycache enhancements
by masarati＠aero.polimi.it 20 Aug '09

20 Aug '09

> masarati(a)aero.polimi.it wrote: >> I wonder, in the spirit of further improving pcache: > > I think this should be a separate ITS. Well, based on your response, it seems not to deserve an ITS at all :) >> - support compare, in case a cached query has the entry to be compared, >> and the asserted attr is in the corresponding attrset? > > Right now we have no convenient way to map a DN to a cached query. We have: a cached entry contains the pcacheQueryID, which solves the problem. > I guess > we > could answer if the entry was already retrieved by some other query, but > we > can't tell what the queryID is without first retrieving the entry. Correct. > If the > entry doesn't exist locally, we have no way to map the request to a query > template, so we can't cache that result at all. I was not concerned with *caching* the result of compare, but with exploiting cached entries to answer compares without contacting the remote server. > It seems to me that apps > that > do Compares on a set of entries do that to avoid Searching and retrieving > the > entire entry, so in practice the intersection of (entries cached by > searching) > and (entries we want to compare on) will be empty. :) >> - exploit modifications to invalidate queries whose results are altered? >> It'd be easy for deletes (check if present, and eventually remove the >> entry). An easy shortcut for modify/rename would be to just invalidate >> queries affecting the modified entry (I'd prefer this to mimic >> modifications to local data, which would also guarantee that remote >> server >> ACLs have been applied). Adds would be a little bit tricky (try all >> cached queries on the new entry (base, scope, filter; in case of match, >> invalidate them, so that the remote server can apply ACLs). > >> This may be a moot point, as usually cached proxies are essentially >> read-only, but in case... > > So far no one has asked for this functionality, thankfully. > > We can retrieve an entry and read its queryID but we don't currently have > an > easy way to look up the ID to get the CachedQuery info. This is all already in place as the PCACHE_EXOP_QUERY_DELETE. > (I guess we can > put > them all into an AVL tree for the purpose.) That would make Deletes easy > enough I guess. For Modify/Rename, if you invalidate a query do you then > delete all of the cached entries for that query? That could result in a > lot of > write traffic for a single change. pcache is probably based on the assumption that clients only perform search (and now, bind) operations, so it's a moot point anyway. > Or do you just leave the cached entries > alone, and destroy the CachedQuery structures? Then the entries will > simply > have queryIDs that reference nonexistent queries. > > Yeah, Adds could result in a lot of invalidations too, with the same > question > about dangling queryIDs. Codewise, it's a matter of just calling pcache_remove_entry_queries_from_cache() for the request DN, if the modification succeeds. Performance and load-wise, it might not be worth, I concur. p.

1 0

Re: (ITS#6152) proxycache enhancements
by hyc＠symas.com 20 Aug '09

20 Aug '09

masarati(a)aero.polimi.it wrote: > I wonder, in the spirit of further improving pcache: I think this should be a separate ITS. > - support compare, in case a cached query has the entry to be compared, > and the asserted attr is in the corresponding attrset? Right now we have no convenient way to map a DN to a cached query. I guess we could answer if the entry was already retrieved by some other query, but we can't tell what the queryID is without first retrieving the entry. If the entry doesn't exist locally, we have no way to map the request to a query template, so we can't cache that result at all. It seems to me that apps that do Compares on a set of entries do that to avoid Searching and retrieving the entire entry, so in practice the intersection of (entries cached by searching) and (entries we want to compare on) will be empty. > - exploit modifications to invalidate queries whose results are altered? > It'd be easy for deletes (check if present, and eventually remove the > entry). An easy shortcut for modify/rename would be to just invalidate > queries affecting the modified entry (I'd prefer this to mimic > modifications to local data, which would also guarantee that remote server > ACLs have been applied). Adds would be a little bit tricky (try all > cached queries on the new entry (base, scope, filter; in case of match, > invalidate them, so that the remote server can apply ACLs). > This may be a moot point, as usually cached proxies are essentially > read-only, but in case... So far no one has asked for this functionality, thankfully. We can retrieve an entry and read its queryID but we don't currently have an easy way to look up the ID to get the CachedQuery info. (I guess we can put them all into an AVL tree for the purpose.) That would make Deletes easy enough I guess. For Modify/Rename, if you invalidate a query do you then delete all of the cached entries for that query? That could result in a lot of write traffic for a single change. Or do you just leave the cached entries alone, and destroy the CachedQuery structures? Then the entries will simply have queryIDs that reference nonexistent queries. Yeah, Adds could result in a lot of invalidations too, with the same question about dangling queryIDs. -- -- Howard Chu CTO, 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#6267) test030-relay fails with back-meta: line 79: kill: (23804) - No such process
by masarati＠aero.polimi.it 20 Aug '09

20 Aug '09

> Full_Name: Michael Ströder > Version: HEAD > OS: openSUSE Linux 11.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.163.75.199) > > > No core dump. > >>>>>> waiting for things to exit > > Using meta backend... > > Starting slapd on TCP/IP port 9011... > Using ldapsearch to check that slapd is running... > Using ldapadd to populate the database... > Searching base="dc=example,dc=com"... > Searching base="o=Example,c=US"... > Search failed (255)! > ./scripts/relay: line 79: kill: (23804) - No such process >>>>>> ./scripts/test030-relay failed for bdb (exit 255) > make[2]: *** [bdb-mod] Error 255 > make[2]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' > make[1]: *** [test] Error 2 > make[1]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' > make: *** [test] Error 2 > michael@nb2:/usr/src/michael/openldap/HEAD/openldap> cd > /usr/src/michael/openldap/HEAD/openldap/;cvs up -Rd . Can't reproduce. I've refactored that code a little bit, yesterday. I haven't tested building backends as modules, FWIW. Did you start from a fresh checkout? p.

1 0

Re: (ITS#6152) proxycache enhancements
by masarati＠aero.polimi.it 20 Aug '09

20 Aug '09

I wonder, in the spirit of further improving pcache: - support compare, in case a cached query has the entry to be compared, and the asserted attr is in the corresponding attrset? - exploit modifications to invalidate queries whose results are altered? It'd be easy for deletes (check if present, and eventually remove the entry). An easy shortcut for modify/rename would be to just invalidate queries affecting the modified entry (I'd prefer this to mimic modifications to local data, which would also guarantee that remote server ACLs have been applied). Adds would be a little bit tricky (try all cached queries on the new entry (base, scope, filter; in case of match, invalidate them, so that the remote server can apply ACLs). This may be a moot point, as usually cached proxies are essentially read-only, but in case... p.

1 0

(ITS#6267) test030-relay fails with back-meta: line 79: kill: (23804) - No such process
by michael＠stroeder.com 20 Aug '09

20 Aug '09

Full_Name: Michael Ströder Version: HEAD OS: openSUSE Linux 11.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.75.199) No core dump. >>>>> waiting for things to exit Using meta backend... Starting slapd on TCP/IP port 9011... Using ldapsearch to check that slapd is running... Using ldapadd to populate the database... Searching base="dc=example,dc=com"... Searching base="o=Example,c=US"... Search failed (255)! ./scripts/relay: line 79: kill: (23804) - No such process >>>>> ./scripts/test030-relay failed for bdb (exit 255) make[2]: *** [bdb-mod] Error 255 make[2]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' make: *** [test] Error 2 michael@nb2:/usr/src/michael/openldap/HEAD/openldap> cd /usr/src/michael/openldap/HEAD/openldap/;cvs up -Rd .

1 0

Re: (ITS#6266) uninitialized var in overlays/dynlist.c:dl_cfgen()
by h.b.furuseth＠usit.uio.no 19 Aug '09

19 Aug '09

hyc(a)symas.com writes: > In the actual code, dlm is initialized to NULL. Therefore, dlml will get > initialized to NULL Only initialized when dml is NULL, but the test 'if ( dlml != NULL )' below is unconditional. Then dlml goes out of scope, it doesn't keep the value between iterations. -- Hallvard

1 0

Re: (ITS#6247)
by hyc＠symas.com 19 Aug '09

19 Aug '09

daniel(a)pluta.biz wrote: > Michael Ströder schrieb: >> daniel(a)pluta.biz wrote: >>> Even with the above described limited scope there seem to be plenty of >>> open questions before thinking about "office-hours" and so on. Just two >>> examples regarding the current implementation of now: >>> - The server's timezone vs. the client's timezone (that's more or less >>> obvious - in my opinion it's sufficient to store UTC times). Yes, time is always stored in UTC in the server. >>> - Replication of "now" attributes' values between slapds that are >>> located in different timezones and client's that communicate with these >>> server's... >> IMHO the client has to convert all user input to GMT and convert all server >> results to local timezone for presentation to the user. The server internally >> processes everything as GMT. Maybe I got you wrong though. Other server >> implementations do it this way when checking logon hours. > The server internally compares the (once set) attributes' values against > its current time (whether locale or utc, does not really matter here > essentially it's always used the same - utc or local time) but the > server does not know (IMHO it cannot reliably determine) from which > timezone a client currently is connecting. Imagine a business trip to > Japan (GMT+10) login would not work during the original specified > (European) office hours, even when asking a local replica server in Japan... Right. Which is a good argument against centralized enforcement of general logon hours, since only the client knows what timezone is relevant. Of course, a company with offices in many timezones, and standardized working policies, might use such a mechanism to control the electronic door locks in all of their buildings. In that case it would make sense for the client software to treat the in-directory times as zoneless, or localtime... But I agree, a discussion of how to manipulate timezone information is outside the scope of this ITS. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs