- openldap-bugs - openldap.org

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 01 Sep '07

01 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 01 Sep '07

01 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 01 Sep '07

01 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 01 Sep '07

01 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 31 Aug '07

31 Aug '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 31 Aug '07

31 Aug '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 31 Aug '07

31 Aug '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 30 Aug '07

30 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 30 Aug '07

30 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs