openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 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 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

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