openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

Re: (ITS#5092) page size value of 1.2.840.113556.1.4.319 control
by kurt＠OpenLDAP.org 15 Aug '07

15 Aug '07

On Aug 15, 2007, at 2:21 PM, randolf.werner(a)sap.com wrote: > Full_Name: Randolf Werner > Version: 2.3.35 > OS: Windows XP > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (155.56.68.221) > > > Hi, > i just have found the following compatibilty issue when using the > 1.2.840.113556.1.4.319 control (http://www.ietf.org/rfc/ > rfc2696.txt) supported > by slapd. According to Microsoft and IBM LDAP API > ldap_create_page_control > > http://msdn2.microsoft.com/en-us/library/aa366547.aspx > http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp? > topic=/apis/ldap_create_page_control.htm > > the page size parameter should be an 32 Bit unsigned integer, > however the RFC > specifies it as "(INTEGER (0..maxInt)". Therefore our LDAP client > uses 2**32-1 > as default page size value. This works fine with Microsoft Active > Directroy for > many years but fails with "Protocol Error" (Error 2) when using > slapd. Our > workaround is to use 2**31-1 as default value in our client. I am > not sure which > implementation is correct, anyway it is a compatibility issue for > ldap clients > and might be "fixed" to improve compatibility. Given maxInt is defined in RFC 4511 as: maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) -- this doesn't appear to be a bug in OpenLDAP Software. -- Kurt

1 0

(ITS#5092) page size value of 1.2.840.113556.1.4.319 control
by randolf.werner＠sap.com 15 Aug '07

15 Aug '07

Full_Name: Randolf Werner Version: 2.3.35 OS: Windows XP URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (155.56.68.221) Hi, i just have found the following compatibilty issue when using the 1.2.840.113556.1.4.319 control (http://www.ietf.org/rfc/rfc2696.txt) supported by slapd. According to Microsoft and IBM LDAP API ldap_create_page_control http://msdn2.microsoft.com/en-us/library/aa366547.aspx http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=/apis… the page size parameter should be an 32 Bit unsigned integer, however the RFC specifies it as "(INTEGER (0..maxInt)". Therefore our LDAP client uses 2**32-1 as default page size value. This works fine with Microsoft Active Directroy for many years but fails with "Protocol Error" (Error 2) when using slapd. Our workaround is to use 2**31-1 as default value in our client. I am not sure which implementation is correct, anyway it is a compatibility issue for ldap clients and might be "fixed" to improve compatibility. Best regards Randolf

1 0

Re: (ITS#5078) slapd high cpu usage
by bgmilne＠staff.telkomsa.net 15 Aug '07

15 Aug '07

On Tuesday 14 August 2007 20:43:36 Babu.Suresh(a)pacificlife.com wrote: > Hello, > > Can we index uniquemember in openldap-2.3.32 & BDB 4.5.20? > > index uniquemember eq,pres I think you can in 2.3.x, but if you can't, you could always fix this on the client side, and tell nss_ldap to map uniqueMember to member (which ends up being a bit more useful anyway IMHO). Regards, Buchan

1 0

RE: (ITS#5078) slapd high cpu usage
by ghenry＠suretecsystems.com 14 Aug '07

14 Aug '07

<quote who="Suresh, Babu"> > Iam getting this.. > > conn=7 op=2 SRCH base="ou=xxx,ou=yyyy,o=zzzzz" scope=1 deref=0 > filter="(&(uniqueMember=cn=aaa,ou=bbb,ou=ccc,o=dddd)(objectClass=groupOf > UniqueNames))" > conn=7 op=2 SRCH attr=cn > <= bdb_equality_candidates: (uniqueMember) index_param failed (18) And did you stop slapd, run slapdindex and restart slapd? Thank you > > Thank you > > -----Original Message----- > From: Gavin Henry [mailto:ghenry@suretecsystems.com] > Sent: Tuesday, August 14, 2007 12:37 PM > To: Suresh, Babu > Cc: openldap-its(a)openldap.org > Subject: Re: (ITS#5078) slapd high cpu usage > > Babu.Suresh(a)pacificlife.com wrote: >> Hello, >> >> Can we index uniquemember in openldap-2.3.32 & BDB 4.5.20? >> >> index uniquemember eq,pres >> >> Thank you >> > > Try it ;-) > > > ------------------------------------------------------------------------------ > The information in this e-mail and any attachments are for the sole use of > the intended recipient and may contain privileged and confidential > information. If you are not the intended recipient, any use, disclosure, > copying or distribution of this message or attachment is strictly > prohibited. If you believe that you have received this e-mail in error, > please contact the sender immediately and delete the e-mail and all of its > attachments. > ============================================================================== > >

1 0

Re: (ITS#5078) slapd high cpu usage
by ghenry＠suretecsystems.com 14 Aug '07

14 Aug '07

Babu.Suresh(a)pacificlife.com wrote: > Hello, > > Can we index uniquemember in openldap-2.3.32 & BDB 4.5.20? > > index uniquemember eq,pres > > Thank you > Try it ;-)

1 0

Re: (ITS#4962) inconsistent Bind(rootdn) behavior
by ghenry＠suretecsystems.com 14 Aug '07

14 Aug '07

ando(a)sys-net.it wrote: > h.b.furuseth(a)usit.uio.no wrote: > >> Backends are quite inconsistent about how Bind treats rootdn/rootpw. >> After a quick browse of the HEAD code, it looks like this - I'll >> investigate closer if needed: >> >> rootpw supported: >> Yes: config, bdb, meta, monitor, ldif, HEAD:null, sql, overlay retcode. >> No: dnssrv, ldap?, RE23:null, perl, relay, shell. > > back-ldap doesn't care about rootdn/rootpw; back-meta does mostly for > historical reasons (could be removed with some work). > >> (Bind not supported: passwd). >> >> Rootpw vs. normal Bind as rootdn (typically when rootdn names an entry): >> config, bdb, null, sql, overlay retcode (I think): >> Try rootpw first, then if failure try normal Bind (even if >> rootpw exists but the Bind password does not match it). >> ldif: >> Do not try rootpw if rootdn names an existing entry. >> meta: >> Fail if rootpw is missing or does not match, more complicated >> otherwise. >> monitor: >> Fine - there are no entries with passwords. > > (yet :) > > I discovered that back-monitor may benefit from having a rootdn because > this provides a means to easily workaround any ACLs. The availability > of rootpw is also important because I ran into few cases where no other > means to authenticate were available, and all in all this feature (I > mean: rootdn w/ rootpw comes for free from the database infrastructure). Don't you do this in test043: "# HACK: use the RootDN of the monitor database as UpdateDN so ACLs apply"

1 0

RE: (ITS#5078) slapd high cpu usage
by Babu.Suresh＠pacificlife.com 14 Aug '07

14 Aug '07

Hello, Can we index uniquemember in openldap-2.3.32 & BDB 4.5.20? index uniquemember eq,pres Thank you -----Original Message----- From: Christian Marg [mailto:marg@rz.tu-clausthal.de] Sent: Wednesday, August 08, 2007 12:15 AM To: Suresh, Babu; openldap-its(a)openldap.org Subject: Re: (ITS#5078) slapd high cpu usage Hello, Babu.Suresh(a)pacificlife.com wrote: > bdb_db_open: Warning - No DB_CONFIG file found in directory=20 Expect > poor performance for suffix o=3Dpacificlife.com. Well, slapd even gives you hints for better performance... > <=3D bdb_equality_candidates: (uid) index_param failed (18) <=3D > bdb_equality_candidates: (cn) index_param failed (18) <=3D > bdb_equality_candidates: (uniqueMember) index_param failed (18) Obviously there are some indices missing in the Database. First add configuration for indices cn, uniquemember then re-index/rebuild database. bye Christian -- Christian Marg mail : mailto:marg@rz.tu-clausthal.de Dezernat 2 TU Clausthal web : http://www.tu-clausthal.de D-38678 Clausthal-Zellerfeld fon : 05323/72-2107 Germany jabber: ifcma(a)jabber.tu-clausthal.de ------------------------------------------------------------------------------ The information in this e-mail and any attachments are for the sole use of the intended recipient and may contain privileged and confidential information. If you are not the intended recipient, any use, disclosure, copying or distribution of this message or attachment is strictly prohibited. If you believe that you have received this e-mail in error, please contact the sender immediately and delete the e-mail and all of its attachments. ==============================================================================

1 0

Re: (ITS#4627) back-ldif issues
by ando＠sys-net.it 14 Aug '07

14 Aug '07

h.b.furuseth(a)usit.uio.no wrote: > Error handling: > > ldif_tool_entry_first() cannot return NOID. Dunno (untouched) > ldif_back_<add,modify,delete,modrdn> always return success (0). > Maybe some of this is a requirement of back-config? If so I > suggest that back-config sets a ldif_info.li_optimism flag and > that back-ldif otherwise treats errors as errors. Don't think so: now they return rs->sr_err and everything keeps working. > If rmdir() in ldif_back_delete() fails with errno != ENOENT, > rs->sr_err is set to LDAP_NOT_ALLOWED_ON_NONLEAF - but is then > immediately overwritten with LDAP_UNWILLING_TO_PERFORM. Fixed > ldif_tool_entry_put() sets 'res' to various LDAP result codes, but > only uses it as a boolean. Are the codes supposed to be logged? Dunno (untouched) > Files: > > back-ldif overwrites files instead writing to a temp file and > renaming when complete. The current way corrupts entries if a > write fails halfway through, e.g. due to a full disk. Also the > file can be left truncated if internal slapd operations fail. > If the OS supports it, back-ldif should make a new file in the > same directory and rename to the old filename when complete. Fixed; now mkstemp(3) is used, and rename(2) only in case of success. > > Locks: > > The global entry2str_mutex is locked around spew_entry() instead > of inside it, so it spans more file operations than necessary. > Should be held more briefly, I think. Though it does make kind of > sense now: It is locked before the file is truncated so that the > file won't be in truncated state for long while slapd waits for > the mutex. But that's not quite how I'd go about solving that > problem; see above. (I have not checked if the mutex doubles as a > mutex to synchronize internal back-ldif operations. So I don't > know if lock/unlock can just be moved inside spew_entry().) Moved as close as possible to entry2str() whenever not used also to serialize backend-specific operations (like in ldif_back_modrdn) > > struct bvlist quirks: > > .num holds an unnecessarily duplicated string. It only needs to a > bechar, holding the character being overwritten with a '\0'. (And > replace the AC_MEMCPY in r_enum_tree() which restores it.) > > For that matter, .num is not needed at all if the '\0' can replace > the IX_FSL (usually '{') instead of the character following it. > (And decrement .off with 1.) Then r_enum_tree() can just put back > an IS_FSL. It would affect the sort order of values prefixed with > '{num}' compared to unprefixed values of the same type. untouched (too cumbersome for summer holidays...) > .inum should be signed, or should be read with strtoul instead of > strtol. strtoul(3) used > I suppose it and cmp in the function should be ber_int_t, > since LDAP integers are typically 32-bit. Not sure what you mean. > Also, for reading .inum and syntax checking: Maybe you should use > strtol() without first doing strchr(,IX_FSR), and then check that > the character after the integer is IX_FSR. Slower though. I think in this case the code is safe as is, because there's no guarantee of itmp.bv_val being nul-terminated, so better check before using strto[u]l, which expects nul-terminated strings. > Other quirks: > > ldif.c uses "struct ldif_info *ni" = be->be_private. Maybe it > used back-null as a template, where "ni" stands for null_info? s/ni/li/g > Return values from get_entry() and spew_entry() are pointlessly > cast to the same type as the functions already return. Fixed. 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#4962) inconsistent Bind(rootdn) behavior
by ando＠sys-net.it 14 Aug '07

14 Aug '07

h.b.furuseth(a)usit.uio.no wrote: > Backends are quite inconsistent about how Bind treats rootdn/rootpw. > After a quick browse of the HEAD code, it looks like this - I'll > investigate closer if needed: > > rootpw supported: > Yes: config, bdb, meta, monitor, ldif, HEAD:null, sql, overlay retcode. > No: dnssrv, ldap?, RE23:null, perl, relay, shell. back-ldap doesn't care about rootdn/rootpw; back-meta does mostly for historical reasons (could be removed with some work). > (Bind not supported: passwd). > > Rootpw vs. normal Bind as rootdn (typically when rootdn names an entry): > config, bdb, null, sql, overlay retcode (I think): > Try rootpw first, then if failure try normal Bind (even if > rootpw exists but the Bind password does not match it). > ldif: > Do not try rootpw if rootdn names an existing entry. > meta: > Fail if rootpw is missing or does not match, more complicated > otherwise. > monitor: > Fine - there are no entries with passwords. (yet :) I discovered that back-monitor may benefit from having a rootdn because this provides a means to easily workaround any ACLs. The availability of rootpw is also important because I ran into few cases where no other means to authenticate were available, and all in all this feature (I mean: rootdn w/ rootpw comes for free from the database infrastructure). > The manpage is (fortunately:-) unclear on what happens in this case. }-) > Check if op->orb_method == LDAP_AUTH_SIMPLE: > Yes: config, bdb, meta, monitor. > No: ldif, null, sql, overlay retcode. I don't think we can get to calling bi_op_bind() otherwise... could even be an assertion. > Set op->orb_edn (op->oq_bind.rb_edn) from be_root_dn() on success: > config, bdb, monitor, sql. > > Set op->orb_edn on failure: > bdb: Sometimes, from &e->e_name. > sql: Always, from op->o_req_ndn. Not sure what does this mean: op->orb_edn should only be set in case of success, AFAIK. > Set rs->sr_err = LDAP_SUCCESS on success: > ldif, meta For consistency, I presume. The caller will just check the response code. > Reset rs->sr_text: > meta > > Which behavior is right? I'm wondering if Bind should fail if rootpw > exists but the Bind password does not match it. > > In any case, methinks we need a be_rootpw_bind(op, rs) function which > takes care of this consistently, so bi_op_bind in most cases can just do > if (be_rootpw_bind(op, rs)) return rs->sr_err; > If needed it could accept rs==NULL to just check the password - like > be_isroot_pw() but with more return codes to distinguish different > cases. At this point, it might be worth moving this check outside bi_op_bind(). Wait a moment: we need to do something else at least in back-meta if rootdn bind succeeds... but I think that could be changed. 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#5086) back-bdb bug when add is used with snapshot isolation
by hyc＠symas.com 14 Aug '07

14 Aug '07

We tested with snapshot isolation before and found no performance benefit. As such, there's no point in undertaking the effort to fix this issue. It's worth noting that with a properly configured cache, most read operations are satisfied by the slapd entry cache, so the main point of lock contention that snapshot isolation tries to solve never even occurs. stelios.xx.grigoriadis(a)ericsson.com wrote: > Full_Name: Stelios Grigoriadis > Version: 2.3.32 > OS: Linux, (SLES 10) > URL: http://ninikos.freehostia.com/bdb_idl_cache_bug.tar.gz > Submission from: (NULL) (194.237.142.7) > > > When using slapd with the snapshot isolation level in DB (version 4.5.20) > it is possible that added entries don't appear in subsequent searches. > > Scenario: A client is adding new information while at the same time another > is initiating an LDAP search with the same searchbase as the "parent" of > the added information. > If the search is executed after the add operation has cleared the IDL-cache > but before the changes has been committed, the added entries will not appear > in any subsequent searches unless slapd is restarted. > > The problem is that, in the bdb_idl_insert_key-function, the key is deleted > from the IDL-cache but the newly added keys in the database are not yet > committed, so clients that re-read the information will not have those updated > keys. > > The solution would be to clear the relevant IDL-cache entries after the > changes has been committed. > > This behaviour is demonstrated by the program cache_test_fork.c which is > supplied > in bdb_idl_cache_bug.tar.gz along with the slapd configuration. > > I am currently working on the solution but would greatly appreciate any help > from you as I am not nearly as familiar with the code as you are. > > > . > -- -- 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

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