openldap-bugs February 2009

openldap-bugs@openldap.org

47 participants
298 discussions

Re: (ITS#5929) 'make test' uses installed libldap_r/liblber
by hyc＠symas.com 08 Feb '09

08 Feb '09

Hallvard B Furuseth wrote: > hyc(a)symas.com writes: >>> "make test" uses installed instead of newly built libraries, >>> with ./configure --enable-dynamic LDFLAGS=<installed lib>. >> Don't do that. > > Then what do I do? Some libraries OpenLDAP needs are there, including > DB 4.4. Without LDFLAGS and corresponding CPPFLAGS I get the system's > DB 4.3, so configure doesn't magically look in<--prefix>/lib/ on its > own. Or with CPPFLAGS but without LDFLAGS I get DB version mismatch. > > I don't want to require $LD_LIBRARY_PATH to be set before running > OpenLDAP programs, nor to mess with /etc/ld.so.conf. Note that scripts/defines.sh already explicitly sets LD_LIBRARY_PATH to point at the newly built libraries. What else do you expect us to do? -- -- 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#5927) assertion error when using pcache
by ando＠sys-net.it 08 Feb '09

08 Feb '09

mhardin(a)symas.com wrote: >> mhardin(a)symas.com wrote: >>> On Feb 7, 2009, at 9:21 AM, ando(a)sys-net.it wrote: >>>> mhardin(a)symas.com wrote: >>>>> Sorry for the out-of-sequence reply. I'll test and let you know >>>>> what I >>>>> find. >>>> No problem. Note that if this is the cause of this issue, and, in >>>> any >>>> case, if you have some "range" attributes in your response, you >>>> still >>>> have an issue with those values. >>> Yes. I'm not sure what to do about them in the medium term. Not >>> having slapd crash is a good first step, though :P >> Are you confirming that the original issue is fixed? > > Unfortunately not. The morning I tested the fix you checked into HEAD > and still got an assertion error in pcache at the same point when > caching group objects that contain range specifiers. I have core files > and would be happy to provide additional information if you need it. As I wrote, I only simulated receiving that type of response by modifying the name of the attribute after it was extracted by back-meta and before it was resolved. It would be interesting to see what happens when the actual response of AD is received by back-meta. In any case, since you have the core files, it would be interesting to see the attribute structure, and specifically of the a_desc member (the AttributeDescription structure). 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5927) assertion error when using pcache
by mhardin＠symas.com 08 Feb '09

08 Feb '09

On Feb 8, 2009, at 1:26 PM, Pierangelo Masarati wrote: > mhardin(a)symas.com wrote: >> On Feb 7, 2009, at 9:21 AM, ando(a)sys-net.it wrote: >>> mhardin(a)symas.com wrote: >>>> Sorry for the out-of-sequence reply. I'll test and let you know >>>> what I >>>> find. >>> No problem. Note that if this is the cause of this issue, and, in >>> any >>> case, if you have some "range" attributes in your response, you >>> still >>> have an issue with those values. >> Yes. I'm not sure what to do about them in the medium term. Not >> having slapd crash is a good first step, though :P > > Are you confirming that the original issue is fixed? Unfortunately not. The morning I tested the fix you checked into HEAD and still got an assertion error in pcache at the same point when caching group objects that contain range specifiers. I have core files and would be happy to provide additional information if you need it. > > >>> It seems that, in the spirit of >>> OpenLDAP software, we could be relatively liberal in accepting those >>> values provided we are able to consolidate them in a single entry >>> with >>> no ranges. Apparently, what the proxies could do is: >>> >>> - whenever a range is obtained in a response >>> - iteratively query the server again for the same entry, >>> - requesting only that attribute for the next block of vals >>> - incrementally build the set of values >>> - return the consolidated entry >>> >>> This MUST be configurable, and documented as a nasty, expensive and >>> unnecessary hack. >>> >> I had thought it might be possible to craft this functionality as >> an overlay (we could call it "derange" :P), but I think you're >> right- it is more appropriate that it be something configurable in >> back-meta and back-ldap. > > You can't handle that with an overlay, since the message containing > this type of response is received by the proxy backends and would > fail parsing unless handled there :). So I've learned :) > > >> This functionality is particularly interesting when one considers >> using Howard's nss_ov in conjunction with pcache and back- ldap >> communicating with directory servers that were never intended to >> handle the high loads that Unix/Linux name services can place on a >> directory server ;-) >> The high cost of the iterative searches might be mitigated through >> use of pcache. I'm thinking the searches to consolidate the >> ranged attributes would happen anyway, so better to do them in the >> proxy and cache the results than make each individual client have >> to do them. > > Yes. Another possible issue is that we'd probably need to work a > symmetric solution in those cases where a request needs values to be > broken in ranges in order to be accepted by AD. Ugh. I suppose so, although my interest in that is relatively low at this point. > > > p. > > -Matt > 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 > Fax: +39 0382 476497 > Email: ando(a)sys-net.it > ----------------------------------- >

1 0

Re: (ITS#5927) assertion error when using pcache
by ando＠sys-net.it 08 Feb '09

08 Feb '09

mhardin(a)symas.com wrote: > On Feb 7, 2009, at 9:21 AM, ando(a)sys-net.it wrote: > >> mhardin(a)symas.com wrote: >>> Sorry for the out-of-sequence reply. I'll test and let you know >>> what I >>> find. >> No problem. Note that if this is the cause of this issue, and, in any >> case, if you have some "range" attributes in your response, you still >> have an issue with those values. > > Yes. I'm not sure what to do about them in the medium term. Not having > slapd crash is a good first step, though :P Are you confirming that the original issue is fixed? >> It seems that, in the spirit of >> OpenLDAP software, we could be relatively liberal in accepting those >> values provided we are able to consolidate them in a single entry with >> no ranges. Apparently, what the proxies could do is: >> >> - whenever a range is obtained in a response >> - iteratively query the server again for the same entry, >> - requesting only that attribute for the next block of vals >> - incrementally build the set of values >> - return the consolidated entry >> >> This MUST be configurable, and documented as a nasty, expensive and >> unnecessary hack. >> > > I had thought it might be possible to craft this functionality as an > overlay (we could call it "derange" :P), but I think you're right- it > is more appropriate that it be something configurable in back-meta and > back-ldap. You can't handle that with an overlay, since the message containing this type of response is received by the proxy backends and would fail parsing unless handled there :). > This functionality is particularly interesting when one > considers using Howard's nss_ov in conjunction with pcache and back- > ldap communicating with directory servers that were never intended to > handle the high loads that Unix/Linux name services can place on a > directory server ;-) > > The high cost of the iterative searches might be mitigated through use > of pcache. I'm thinking the searches to consolidate the ranged > attributes would happen anyway, so better to do them in the proxy and > cache the results than make each individual client have to do them. Yes. Another possible issue is that we'd probably need to work a symmetric solution in those cases where a request needs values to be broken in ranges in order to be accepted by AD. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5929) 'make test' uses installed libldap_r/liblber
by h.b.furuseth＠usit.uio.no 08 Feb '09

08 Feb '09

hyc(a)symas.com writes: >> "make test" uses installed instead of newly built libraries, >> with ./configure --enable-dynamic LDFLAGS=<installed lib>. > > Don't do that. Then what do I do? Some libraries OpenLDAP needs are there, including DB 4.4. Without LDFLAGS and corresponding CPPFLAGS I get the system's DB 4.3, so configure doesn't magically look in <--prefix>/lib/ on its own. Or with CPPFLAGS but without LDFLAGS I get DB version mismatch. I don't want to require $LD_LIBRARY_PATH to be set before running OpenLDAP programs, nor to mess with /etc/ld.so.conf. -- Hallvard

1 0

Re: (ITS#5927) assertion error when using pcache
by hyc＠symas.com 07 Feb '09

07 Feb '09

ando(a)sys-net.it wrote: > mhardin(a)symas.com wrote: >> Sorry for the out-of-sequence reply. I'll test and let you know what I >> find. > > No problem. Note that if this is the cause of this issue, and, in any > case, if you have some "range" attributes in your response, you still > have an issue with those values. It seems that, in the spirit of > OpenLDAP software, we could be relatively liberal in accepting those > values provided we are able to consolidate them in a single entry with > no ranges. Apparently, what the proxies could do is: > > - whenever a range is obtained in a response > - iteratively query the server again for the same entry, > - requesting only that attribute for the next block of vals > - incrementally build the set of values > - return the consolidated entry > > This MUST be configurable, and documented as a nasty, expensive and > unnecessary hack. Even the thought of writing such an ugly hack is ... ugh... As an alternative, I suggest modifying slapd/ad.c to treat "=" the same as "-" in an option definition. Then simply adding attributeoption range= to slapd.conf will allow the values to be recognized. (With the constraint that '=' must be the final character in the option definition...) Let the client decide if they want to go thru the trouble of retrieving all the values or not. Certainly, for slapd to do it implicitly will overburden the (pathetically broken) AD server (otherwise they wouldn't need to break the value up into ranges in the first place). Indeed, doing this implicitly would amount to a DOS attack on the AD server. -- -- 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#5929) 'make test' uses installed libldap_r/liblber
by hyc＠symas.com 07 Feb '09

07 Feb '09

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: RedHat Linux x86_64 > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > "make test" uses installed instead of newly built libraries, > with ./configure --enable-dynamic LDFLAGS=<installed lib>. Don't do that. -- -- 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#5927) assertion error when using pcache
by mhardin＠symas.com 07 Feb '09

07 Feb '09

On Feb 7, 2009, at 9:21 AM, ando(a)sys-net.it wrote: > mhardin(a)symas.com wrote: >> Sorry for the out-of-sequence reply. I'll test and let you know >> what I >> find. > > No problem. Note that if this is the cause of this issue, and, in any > case, if you have some "range" attributes in your response, you still > have an issue with those values. Yes. I'm not sure what to do about them in the medium term. Not having slapd crash is a good first step, though :P > It seems that, in the spirit of > OpenLDAP software, we could be relatively liberal in accepting those > values provided we are able to consolidate them in a single entry with > no ranges. Apparently, what the proxies could do is: > > - whenever a range is obtained in a response > - iteratively query the server again for the same entry, > - requesting only that attribute for the next block of vals > - incrementally build the set of values > - return the consolidated entry > > This MUST be configurable, and documented as a nasty, expensive and > unnecessary hack. > I had thought it might be possible to craft this functionality as an overlay (we could call it "derange" :P), but I think you're right- it is more appropriate that it be something configurable in back-meta and back-ldap. This functionality is particularly interesting when one considers using Howard's nss_ov in conjunction with pcache and back- ldap communicating with directory servers that were never intended to handle the high loads that Unix/Linux name services can place on a directory server ;-) The high cost of the iterative searches might be mitigated through use of pcache. I'm thinking the searches to consolidate the ranged attributes would happen anyway, so better to do them in the proxy and cache the results than make each individual client have to do them. Cheers, -Matt > 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 > Fax: +39 0382 476497 > Email: ando(a)sys-net.it > ----------------------------------- > >

1 0

Re: (ITS#5927) assertion error when using pcache
by ando＠sys-net.it 07 Feb '09

07 Feb '09

mhardin(a)symas.com wrote: > Sorry for the out-of-sequence reply. I'll test and let you know what I > find. No problem. Note that if this is the cause of this issue, and, in any case, if you have some "range" attributes in your response, you still have an issue with those values. It seems that, in the spirit of OpenLDAP software, we could be relatively liberal in accepting those values provided we are able to consolidate them in a single entry with no ranges. Apparently, what the proxies could do is: - whenever a range is obtained in a response - iteratively query the server again for the same entry, - requesting only that attribute for the next block of vals - incrementally build the set of values - return the consolidated entry This MUST be configurable, and documented as a nasty, expensive and unnecessary hack. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5927) assertion error when using pcache
by mhardin＠symas.com 07 Feb '09

07 Feb '09

Sorry for the out-of-sequence reply. I'll test and let you know what I find. Cheers, -Matt On Feb 7, 2009, at 8:53 AM, mhardin(a)symas.com wrote: > On Feb 7, 2009, at 3:24 AM, Pierangelo Masarati wrote: > >> mhardin(a)symas.com wrote: >>> Some additional information: >>> Some objects being returned from AD have very large multi-valued >>> attributes (for example, member). AD is returning them in the >>> ";range" format, but they are not getting past back-meta. For >>> example, a direct search for the object in AD will return stuff >>> like this: >>> member;range=0-1499: CN=Alice Bar,OU=My-Company-Accounts,OU=User >>> Accounts,OU=Common,DC=my-company,DC=com >>> but doing the same search through slapd/back-meta using the same >>> credentials, the member attribute is not displayed at all. There >>> are no attribute maps in place that would cause this. >> >> If this is the cause, then back-meta should try to register the >> attribute name as a "proxied" attribute type, and slapd should be >> unable to correctly decode it because it contains a "=". Back-meta >> in the end should just ignore the whole attribute. >> > > Thanks, Pierangelo. That led me to ITS#5472 and several other postings > about the same issue. In particular: > >> [Petter Reinholdtsen said] >>> This notation is not handled by ldap_get_values(), and it return >>> NULL, resulting in a group with zero members. > >> [Kurt Zielenga replied] >> This is proper and well-intended behavior. You asked for values of >> returned under the attribute description "member", not the (invalid) >> attribute description "member;range=0-1499". Two attribute >> descriptions which share the same attribute type do not necessarily >> refer to the same attribute. > > This clearly explains the assertion pcache is reporting. Well-intended > behavior or not, there is a problem here because pcache takes down the > server whenever it encounters attribute values of this form. Given > Kurt's later comments about the provenance and ancestry of this > "standard", it seems to me the right thing for back-meta (and back- > ldap, for that matter) to do might be to just make the attribute > completely disappear. Appropriate messages output in debug mode or at > a particular log level might announce the fact that the attribute is > being disappeared. The pcache overlay, for its part, instead of > asserting, might instead log a warning and refuse to cache the object. > > Sound reasonable? > > -Matt > > >> 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 >> Fax: +39 0382 476497 >> Email: ando(a)sys-net.it >> ----------------------------------- >> > >

1 0

← Newer
1
...
20
21
22
23
24
25
26
...
30
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs February 2009