openldap-bugs

openldap-bugs@openldap.org

1 participants
20966 discussions

Re: (ITS#5092) page size value of 1.2.840.113556.1.4.319 control
by ando＠sys-net.it 15 Aug '07

15 Aug '07

> 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… >> >> 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. > > I suggest you file bug reports with Microsoft and IBM to fix their broken > implementations then. RFC4511 clearly defines maxInt to be 2^31-1. That > value > has not changed since RFC2251 either. Or, fix your clients so that they don't use pagedResults when not necessary. 2**31-1 is a pretty large number. 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#4627) back-ldif issues
by h.b.furuseth＠usit.uio.no 15 Aug '07

15 Aug '07

Howard Chu writes: >h.b.furuseth(a)usit.uio.no wrote: >> Not there yet... you create it in the current directory instead >> of in the ldif directory. >> >> Possibly it's best to create it in the top directory of the ldif >> database. That way, if a temp file is somehow created and not >> cleaned away, it's (a) in the easiest place to see and (b) won't >> prevent rmdir() if one tries to delete that database or whatever. > > I would use "rm -rf" to delete the DB, in which case (b) is a moot point. Sorry, I meant if one uses LDAP operations to delete a non-leaf entry. (I was thinking of a "cn=config/olcDatabase=.../" subtree.) >>> (...) >>>> .inum should be signed, or should be read with strtoul instead of >>>> strtol. >>> strtoul(3) used > > I think strtoul() here is a mistake, and we've fixed/refixed this point a > couple times already. Remember that frontendDB has an index of {-1} in the > config tree. Time to re-fix again and add a comment about that this time... Hm. It is read with strto(u)l but is int and not long. Maybe that's what I was talking about with what its type should be. -- Regards, Hallvard

1 0

Re: (ITS#4627) back-ldif issues
by hyc＠symas.com 15 Aug '07

15 Aug '07

h.b.furuseth(a)usit.uio.no wrote: > Possibly it's best to create it in the top directory of the ldif > database. That way, if a temp file is somehow created and not > cleaned away, it's (a) in the easiest place to see and (b) won't > prevent rmdir() if one tries to delete that database or whatever. > > I don't know if there are non-Unix OSes which need special system calls > to move file between directories though. Or for that matter, if they > allow rename() to replace an existing file, maybe unlink is needed > first. The code looks very Unixy already, so I assume a Unix emulation > is needed to run it anyway. I don't know how those work. For that matter, I think the temp file must be created in the same directory as the existing file. It's always possible that someone will mount a new filesystem somewhere in the hierarchy, and you cannot rename() across mountpoints. -- -- 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#4627) back-ldif issues
by hyc＠symas.com 15 Aug '07

15 Aug '07

h.b.furuseth(a)usit.uio.no wrote: > Pierangelo Masarati writes: >>> Error handling: >>> >>> ldif_tool_entry_first() cannot return NOID. >> Dunno (untouched) > > Howard fixed. One remaining issue: ldif_tool_entry_next() increments > li->li_tool_current even when it returns NOID. Should it do that? Harmless, but stupid. Fixed now. > >> (...) >>> 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. > > Not there yet... you create it in the current directory instead > of in the ldif directory. > > Possibly it's best to create it in the top directory of the ldif > database. That way, if a temp file is somehow created and not > cleaned away, it's (a) in the easiest place to see and (b) won't > prevent rmdir() if one tries to delete that database or whatever. I would use "rm -rf" to delete the DB, in which case (b) is a moot point. > I don't know if there are non-Unix OSes which need special system calls > to move file between directories though. Or for that matter, if they > allow rename() to replace an existing file, maybe unlink is needed > first. The code looks very Unixy already, so I assume a Unix emulation > is needed to run it anyway. I don't know how those work. Yes, we require POSIX semantics here. rename() unlinks the target atomically; it would be a mistake to code this in a different manner. > Also there were some spew_entry() coding errors, rev 1.70 fixes them. > >> (...) >>> .inum should be signed, or should be read with strtoul instead of >>> strtol. >> strtoul(3) used I think strtoul() here is a mistake, and we've fixed/refixed this point a couple times already. Remember that frontendDB has an index of {-1} in the config tree. >>> 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. > > I don't remember. Maybe the number can end up being sent over the > protocol, and it's possible to create a filename with a long > max > ber_int_t so the wrong number will be sent? > -- -- 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#4627) back-ldif issues
by h.b.furuseth＠usit.uio.no 15 Aug '07

15 Aug '07

Pierangelo Masarati writes: >> Error handling: >> >> ldif_tool_entry_first() cannot return NOID. > > Dunno (untouched) Howard fixed. One remaining issue: ldif_tool_entry_next() increments li->li_tool_current even when it returns NOID. Should it do that? > (...) >> 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. Not there yet... you create it in the current directory instead of in the ldif directory. Possibly it's best to create it in the top directory of the ldif database. That way, if a temp file is somehow created and not cleaned away, it's (a) in the easiest place to see and (b) won't prevent rmdir() if one tries to delete that database or whatever. I don't know if there are non-Unix OSes which need special system calls to move file between directories though. Or for that matter, if they allow rename() to replace an existing file, maybe unlink is needed first. The code looks very Unixy already, so I assume a Unix emulation is needed to run it anyway. I don't know how those work. Also there were some spew_entry() coding errors, rev 1.70 fixes them. > (...) >> .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. I don't remember. Maybe the number can end up being sent over the protocol, and it's possible to create a filename with a long > max ber_int_t so the wrong number will be sent? -- Hallvard

1 0

Re: (ITS#5092) page size value of 1.2.840.113556.1.4.319 control
by hyc＠symas.com 15 Aug '07

15 Aug '07

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… > > 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. I suggest you file bug reports with Microsoft and IBM to fix their broken implementations then. RFC4511 clearly defines maxInt to be 2^31-1. That value has not changed since RFC2251 either. -- -- 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#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

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