openldap-bugs August 2009

openldap-bugs@openldap.org

35 participants
225 discussions

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 … [View More]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). [View Less]

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, … [View More]

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, … [View More]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. [View Less]

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 … [View More]

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=… [View More]

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 … [View More]

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) - … [View More]

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 … [View More]

1 0

← Newer
1
2
3
4
5
6
7
8
...
23
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs August 2009