- openldap-bugs - openldap.org

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

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

07 Feb '09

mhardin(a)symas.com wrote: > 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. No longer :) > 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? See latest commit. If this fixes your problem, a message like conn=X op=Y meta_send_entry("cn=smtg"): slap_bv2undef_ad("member;range=Z-W"): ... Maybe you're not seeing it because slapd dies before logging? I could recreate the issue by entering slapd with gdb, let it get the attribute name, modify it by putting a "=" in between, and letting things go through. What happened is that slapd does not recognizes the attribute and continues the cycle. The subsequent attribute is not recognized as well because it is actually the first value! This should now be handled correctly. Please test. 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

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

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

07 Feb '09

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. Apparently, that was it: back-meta (and back-ldap) was ignoring attribute names that cannot be parsed, but it was not discarding their values. Should be fixed now in HEAD. Please test. BTW, it seems that proxy backends could try to exploit this in order to intercept value ranges returned by AD and consolidate them in a single, LDAP compliant entry. Not something I'm too excited about, 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 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: > 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. 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

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

06 Feb '09

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>. It works if either --enable-dynamic or LDFLAGS is omitted. Minimal test: p=/site/ldap/install # ...or wherever OpenLDAP is installed ./configure --quiet --prefix=$p --enable-dynamic \ --disable-databases --disable-overlays --enable-ldap \ CPPFLAGS="-I$p/include" LDFLAGS="-L$p/lib -Wl,-rpath,$p/lib" make -s depend all Edit servers/slapd/slapd (a wrapper script from libtool): Insert echo "" ldd "$progdir/$program" | grep libl >&2 printenv | egrep '^(GCC|[A-Z_0-9]*PATH).*/' >&2 before exec "$progdir/$program" ${1+"$@"} cd tests ./run -b ldif test029-ldapglue Now "./run -b ldif test029-ldapglue" shows libldap_r-2-devel.so.0 => /site/ldap/install/lib/libldap_r-2-devel.so.0 liblber-2-devel.so.0 => /site/ldap/install/lib/liblber-2-devel.so.0 LD_LIBRARY_PATH=/usit/bombur/site/ldap/HEAD-commit/tests/../libraries:/usit/bombur/site/ldap/HEAD-commit/tests/../libraries: slapd#2 crashes unless the installed OpenLDAP is from February, otherwise testrun/slapd.2.log says symbol ldap_pvt_search is missing.

1 0

(ITS#5928) build without SSL fails
by quanah＠OpenLDAP.org 06 Feb '09

06 Feb '09

Full_Name: Quanah Gibson-Mount Version: HEAD/RE24 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) If you build OpenLDAP with --without-tls and --without-cyrus-sasl, the build fails: Entering subdirectory libldap make[3]: Entering directory `/home/build/p4/main/ThirdParty/openldap/openldap-2.4.14.2z/libraries/libldap' /bin/sh ../../libtool --mode=compile cc -g -O0 -I../../include -I../../include -I/opt/zimbra/bdb-4.7.25.3/include -I/opt/zimbra/libtool-2.2.6a/include -DLDAP_LIBRARY -c tls2.c cc -g -O0 -I../../include -I../../include -I/opt/zimbra/bdb-4.7.25.3/include -I/opt/zimbra/libtool-2.2.6a/include -DLDAP_LIBRARY -c tls2.c -fPIC -DPIC -o .libs/tls2.o tls2.c: In function `ldap_pvt_tls_ctx_free': tls2.c:81: error: `tls_imp' undeclared (first use in this function) tls2.c:81: error: (Each undeclared identifier is reported only once tls2.c:81: error: for each function it appears in.) tls2.c: At top level: tls2.c:85: error: syntax error before '*' token tls2.c: In function `tls_ctx_ref': tls2.c:87: error: `ctx' undeclared (first use in this function) tls2.c:89: error: `tls_imp' undeclared (first use in this function) tls2.c: In function `ldap_int_tls_destroy': tls2.c:102: error: structure has no member named `ldo_tls_ctx' tls2.c:103: error: structure has no member named `ldo_tls_ctx' tls2.c:104: error: structure has no member named `ldo_tls_ctx' tls2.c:107: error: structure has no member named `ldo_tls_certfile' tls2.c:108: error: structure has no member named `ldo_tls_certfile' tls2.c:109: error: structure has no member named `ldo_tls_certfile' tls2.c:111: error: structure has no member named `ldo_tls_keyfile' tls2.c:112: error: structure has no member named `ldo_tls_keyfile' tls2.c:113: error: structure has no member named `ldo_tls_keyfile' tls2.c:115: error: structure has no member named `ldo_tls_dhfile' tls2.c:116: error: structure has no member named `ldo_tls_dhfile' tls2.c:117: error: structure has no member named `ldo_tls_dhfile' tls2.c:119: error: structure has no member named `ldo_tls_cacertfile' tls2.c:120: error: structure has no member named `ldo_tls_cacertfile' tls2.c:121: error: structure has no member named `ldo_tls_cacertfile' tls2.c:123: error: structure has no member named `ldo_tls_cacertdir' tls2.c:124: error: structure has no member named `ldo_tls_cacertdir' tls2.c:125: error: structure has no member named `ldo_tls_cacertdir' tls2.c:127: error: structure has no member named `ldo_tls_ciphersuite' tls2.c:128: error: structure has no member named `ldo_tls_ciphersuite' tls2.c:129: error: structure has no member named `ldo_tls_ciphersuite' tls2.c:131: error: structure has no member named `ldo_tls_crlfile' tls2.c:132: error: structure has no member named `ldo_tls_crlfile' tls2.c:133: error: structure has no member named `ldo_tls_crlfile' tls2.c: In function `ldap_pvt_tls_destroy': tls2.c:148: error: `tls_imp' undeclared (first use in this function) tls2.c: At top level: tls2.c:156: error: syntax error before '*' token tls2.c: In function `tls_init': tls2.c:166: error: `impl' undeclared (first use in this function) tls2.c: In function `ldap_pvt_tls_init': tls2.c:182: error: `tls_imp' undeclared (first use in this function) tls2.c: In function `ldap_int_tls_init_ctx': tls2.c:192: error: `tls_impl' undeclared (first use in this function) tls2.c:192: error: `ti' undeclared (first use in this function) tls2.c:192: error: `tls_imp' undeclared (first use in this function) tls2.c:193: error: variable `lts' has initializer but incomplete type tls2.c:193: error: structure has no member named `ldo_tls_info' tls2.c:193: error: storage size of 'lts' isn't known tls2.c:195: error: structure has no member named `ldo_tls_ctx' tls2.c:237: error: structure has no member named `ldo_tls_ctx' tls2.c:238: error: structure has no member named `ldo_tls_ctx' tls2.c:249: error: structure has no member named `ldo_tls_ctx' tls2.c:250: error: structure has no member named `ldo_tls_ctx' tls2.c:251: error: structure has no member named `ldo_tls_ctx' tls2.c: At top level: tls2.c:283: error: syntax error before '*' token tls2.c: In function `alloc_handle': tls2.c:286: error: `tls_ctx' undeclared (first use in this function) tls2.c:286: error: `ctx' undeclared (first use in this function) tls2.c:287: error: `tls_session' undeclared (first use in this function) tls2.c:287: error: `ssl' undeclared (first use in this function) tls2.c:294: error: structure has no member named `ldo_tls_ctx' tls2.c:297: error: `tls_imp' undeclared (first use in this function) tls2.c: At top level: tls2.c:306: error: syntax error before "tls_session" tls2.c: In function `update_flags': tls2.c:308: error: `sb' undeclared (first use in this function) tls2.c:311: error: `tls_imp' undeclared (first use in this function) tls2.c:311: error: `ssl' undeclared (first use in this function) tls2.c:311: error: `rc' undeclared (first use in this function) tls2.c: In function `ldap_int_tls_connect': tls2.c:332: error: `tls_session' undeclared (first use in this function) tls2.c:332: error: `ssl' undeclared (first use in this function) tls2.c:338: error: `tls_ctx' undeclared (first use in this function) tls2.c:338: error: `ctx' undeclared (first use in this function) tls2.c:340: error: structure has no member named `ldo_tls_ctx' tls2.c:350: error: `tls_imp' undeclared (first use in this function) tls2.c:355: error: structure has no member named `ldo_tls_ctx' tls2.c:356: error: structure has no member named `ldo_tls_ctx' tls2.c:359: error: structure has no member named `ldo_tls_connect_cb' tls2.c:360: error: structure has no member named `ldo_tls_connect_cb' tls2.c:361: error: structure has no member named `ldo_tls_connect_arg' tls2.c:362: error: structure has no member named `ldo_tls_connect_cb' tls2.c:362: error: structure has no member named `ldo_tls_connect_cb' tls2.c:363: error: structure has no member named `ldo_tls_connect_cb' tls2.c:364: error: structure has no member named `ldo_tls_connect_cb' tls2.c:364: error: structure has no member named `ldo_tls_connect_arg' tls2.c: In function `ldap_pvt_tls_accept': tls2.c:414: error: `tls_session' undeclared (first use in this function) tls2.c:414: error: `ssl' undeclared (first use in this function) tls2.c:426: error: `tls_imp' undeclared (first use in this function) tls2.c: In function `ldap_pvt_tls_get_peer_dn': tls2.c:483: error: `tls_session' undeclared (first use in this function) tls2.c:483: error: `session' undeclared (first use in this function) tls2.c:487: error: `tls_imp' undeclared (first use in this function) tls2.c: In function `ldap_pvt_tls_check_hostname': tls2.c:498: error: `tls_session' undeclared (first use in this function) tls2.c:498: error: `session' undeclared (first use in this function) tls2.c:500: error: `tls_imp' undeclared (first use in this function) tls2.c: In function `ldap_pvt_tls_get_option': tls2.c:604: error: structure has no member named `ldo_tls_mode' tls2.c:607: error: structure has no member named `ldo_tls_ctx' tls2.c:608: error: structure has no member named `ldo_tls_ctx' tls2.c:609: error: structure has no member named `ldo_tls_ctx' tls2.c:613: error: structure has no member named `ldo_tls_cacertfile' tls2.c:614: error: structure has no member named `ldo_tls_cacertfile' tls2.c:617: error: structure has no member named `ldo_tls_cacertdir' tls2.c:618: error: structure has no member named `ldo_tls_cacertdir' tls2.c:621: error: structure has no member named `ldo_tls_certfile' tls2.c:622: error: structure has no member named `ldo_tls_certfile' tls2.c:625: error: structure has no member named `ldo_tls_keyfile' tls2.c:626: error: structure has no member named `ldo_tls_keyfile' tls2.c:629: error: structure has no member named `ldo_tls_dhfile' tls2.c:630: error: structure has no member named `ldo_tls_dhfile' tls2.c:633: error: structure has no member named `ldo_tls_crlfile' tls2.c:634: error: structure has no member named `ldo_tls_crlfile' tls2.c:637: error: structure has no member named `ldo_tls_require_cert' tls2.c:640: error: structure has no member named `ldo_tls_crlcheck' tls2.c:643: error: structure has no member named `ldo_tls_ciphersuite' tls2.c:644: error: structure has no member named `ldo_tls_ciphersuite' tls2.c:647: error: structure has no member named `ldo_tls_protocol_min' tls2.c:650: error: structure has no member named `ldo_tls_randfile' tls2.c:651: error: structure has no member named `ldo_tls_randfile' tls2.c:666: error: structure has no member named `ldo_tls_connect_cb' tls2.c:669: error: structure has no member named `ldo_tls_connect_arg' tls2.c: In function `ldap_pvt_tls_set_option': tls2.c:710: error: structure has no member named `ldo_tls_mode' tls2.c:718: error: structure has no member named `ldo_tls_ctx' tls2.c:719: error: structure has no member named `ldo_tls_ctx' tls2.c:720: error: structure has no member named `ldo_tls_ctx' tls2.c:721: error: structure has no member named `ldo_tls_ctx' tls2.c:724: error: structure has no member named `ldo_tls_connect_cb' tls2.c:727: error: structure has no member named `ldo_tls_connect_arg' tls2.c:730: error: structure has no member named `ldo_tls_cacertfile' tls2.c:730: error: structure has no member named `ldo_tls_cacertfile' tls2.c:731: error: structure has no member named `ldo_tls_cacertfile' tls2.c:734: error: structure has no member named `ldo_tls_cacertdir' tls2.c:734: error: structure has no member named `ldo_tls_cacertdir' tls2.c:735: error: structure has no member named `ldo_tls_cacertdir' tls2.c:738: error: structure has no member named `ldo_tls_certfile' tls2.c:738: error: structure has no member named `ldo_tls_certfile' tls2.c:739: error: structure has no member named `ldo_tls_certfile' tls2.c:742: error: structure has no member named `ldo_tls_keyfile' tls2.c:742: error: structure has no member named `ldo_tls_keyfile' tls2.c:743: error: structure has no member named `ldo_tls_keyfile' tls2.c:746: error: structure has no member named `ldo_tls_dhfile' tls2.c:746: error: structure has no member named `ldo_tls_dhfile' tls2.c:747: error: structure has no member named `ldo_tls_dhfile' tls2.c:750: error: structure has no member named `ldo_tls_crlfile' tls2.c:750: error: structure has no member named `ldo_tls_crlfile' tls2.c:751: error: structure has no member named `ldo_tls_crlfile' tls2.c:761: error: structure has no member named `ldo_tls_require_cert' tls2.c:771: error: structure has no member named `ldo_tls_crlcheck' tls2.c:776: error: structure has no member named `ldo_tls_ciphersuite' tls2.c:776: error: structure has no member named `ldo_tls_ciphersuite' tls2.c:777: error: structure has no member named `ldo_tls_ciphersuite' tls2.c:782: error: structure has no member named `ldo_tls_protocol_min' tls2.c:788: error: structure has no member named `ldo_tls_randfile' tls2.c:788: error: structure has no member named `ldo_tls_randfile' tls2.c:789: error: structure has no member named `ldo_tls_randfile' tls2.c:794: error: structure has no member named `ldo_tls_ctx' tls2.c:795: error: structure has no member named `ldo_tls_ctx' tls2.c:796: error: structure has no member named `ldo_tls_ctx' tls2.c: In function `ldap_int_tls_start': tls2.c:822: error: `tls_imp' undeclared (first use in this function) tls2.c:838: error: structure has no member named `ldo_tls_require_cert' tls2.c: In function `ldap_pvt_tls_get_strength': tls2.c:863: error: `tls_session' undeclared (first use in this function) tls2.c:863: error: `session' undeclared (first use in this function) tls2.c:865: error: `tls_imp' undeclared (first use in this function) make[3]: *** [tls2.lo] Error 1 make[3]: Leaving directory `/home/build/p4/main/ThirdParty/openldap/openldap-2.4.14.2z/libraries/libldap' make[2]: *** [all-common] Error 1 make[2]: Leaving directory `/home/build/p4/main/ThirdParty/openldap/openldap-2.4.14.2z/libraries' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/home/build/p4/main/ThirdParty/openldap/openldap-2.4.14.2z' make: *** [build] Error 2

1 0

RE: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by philippe.eychart＠informatique.gov.pf 06 Feb '09

06 Feb '09

michael(a)stroeder.com wrote: > I'd recommend not to mess around with the hostport portion of the LDAP > URL. In opposite to Hallvard I'm not even sure whether a distinction is > really needed when invoking ldap_initialize(). ok ... The rfc 2255 defined the LDAP URL syntaxe as : scheme "://" [hostport] ["/" [dn etc... where host (rfc1738) must be a fully qualified domain name of a network host or IP address. (a fully qualified domain name cannot effectiely begin with a '.' ;-) Therefore, transforming a fully qualified domain name in a IP adress remains to be a DNS job. But, "My.domain.[:port]" is actually a fully qualified domain name and produce effectively one (at least) IP address of a network host when a SRV rr is defined and an authoritative answer can be obtained from a DNS. Of course I admit it could be not very efficient to try systematically a SRV resolution on every domain name of a LDAP URLS chain ... So I propose to add an extension (something like "forceSrvSearch") which will indicate that the library must perform a SRV request on this URL to find the IP address from the hostname (or hostport) parameter specified. It'll be a bit more complex to patch up ... :( -- PE

1 0

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

06 Feb '09

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. -Matt

1 0

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

06 Feb '09

On Feb 6, 2009, at 12:29 AM, Pierangelo Masarati wrote: > mhardin(a)symas.com wrote: >> Full_Name: Matthew Hardin >> Version: 2.4.13 >> OS: Red Hat Enterprise Linux 4 i686 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (74.38.114.185) >> Hi All, >> We have an LDAP server that is proxying for Active Directory. >> Periodically slapd >> throws an assertion: >> slapd: [....]/ldap24/servers/slapd/schema_init.c:524: >> octetStringIndexer: >> Assertion `i > 0' failed. >> /etc/init.d/solserver: line 192: 6620 Aborted >> (core dumped) >> "$EXEC_DIR/$PROC" $ARGS -h "$HOST_LIST" $EXTRA_SLAPD_ARGS >> Howard Chu's examination of the core file showed that the remote AD >> server >> returned a member attribute with no values. This is only legal in >> LDAP when a >> client sets the attrsonly flag in its search request, and that flag >> was not set >> here. >> The indexer rightly asserts because pcache handed it an attribute >> with nothing >> to index. >> I'm not sure what the correct thing to do might be here, but it >> should not take >> down the slapd. > > The entry should not be cached, IMHO. Fair enough, I think. -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 michael＠stroeder.com 06 Feb '09

06 Feb '09

hyc(a)symas.com wrote: > ando(a)sys-net.it wrote: >> mhardin(a)symas.com wrote: >>> Howard Chu's examination of the core file showed that the remote AD server >>> returned a member attribute with no values. This is only legal in LDAP when a >>> client sets the attrsonly flag in its search request, and that flag was not set >>> here. > [..] > AD is flaky enough already, but it's possible that back-meta may have dropped > the attr values during rewriting, etc. FWIW: I never saw an empty attribute value list returned by AD. I've added code to web2ldap to handle that case since I had this issue with various other LDAP servers but not AD. Ciao, Michael.

1 0

Re: Docs: admin guide describes log levels inconsistently (ITS#5904)
by ghenry＠suretecsystems.com 06 Feb '09

06 Feb '09

----- "Quanah Gibson-Mount" <quanah(a)zimbra.com> wrote: > --On Thursday, February 05, 2009 11:41 AM +0000 ghenry(a)OpenLDAP.org > wrote: > > > Awww, aren't we nice! ;-) > > > > Patch applied, > > The new patch is definitely an improvement, however it fails to > document > the hexadecimal notation for log levels, which is also perfectly > valid. > See slapd.conf(5): > > 1 (0x1 trace) trace function calls > 2 (0x2 packets) debug packet handling > 4 (0x4 args) heavy trace debugging (function args) In the admin guide patch, I see: -1 Any enable all debugging 0 no debugging Do we now use: \".TP \".B 4096 \".B (0x1000 cache) \"caching (unused) \".TP \".B 8192 \".B (0x2000 index) \"data indexing (unused) This is from slapd.conf(5), but it appears in the patch. Thanks. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 13 Whiteley Well Place, Inverurie, Aberdeenshire, AB51 4FP. Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html

1 0

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

06 Feb '09

----- "Howard Chu" <hyc(a)symas.com> wrote: > ando(a)sys-net.it wrote: > > mhardin(a)symas.com wrote: > >> Full_Name: Matthew Hardin > >> Version: 2.4.13 > >> OS: Red Hat Enterprise Linux 4 i686 > >> URL: ftp://ftp.openldap.org/incoming/ > >> Submission from: (NULL) (74.38.114.185) > >> > >> > >> Hi All, > >> > >> We have an LDAP server that is proxying for Active Directory. > Periodically slapd > >> throws an assertion: > >> > >> slapd: [....]/ldap24/servers/slapd/schema_init.c:524: > octetStringIndexer: > >> Assertion `i> 0' failed. > >> /etc/init.d/solserver: line 192: 6620 Aborted > (core dumped) > >> "$EXEC_DIR/$PROC" $ARGS -h "$HOST_LIST" $EXTRA_SLAPD_ARGS > >> > >> Howard Chu's examination of the core file showed that the remote AD > server > >> returned a member attribute with no values. This is only legal in > LDAP when a > >> client sets the attrsonly flag in its search request, and that flag > was not set > >> here. > >> > >> The indexer rightly asserts because pcache handed it an attribute > with nothing > >> to > >> index. > >> > >> I'm not sure what the correct thing to do might be here, but it > should not take > >> down the slapd. > > > > The entry should not be cached, IMHO. > > Perhaps. But then the entire query cannot be cached, because its > result set > would be known to be incomplete. Of course, I meant the whole query. > There's something more going on here, because the query in question > was > searching for > (&(objectclass=posixgroup)(memberUid=foo)(member=foo-DN)). There > was no memberUid at all in the returned entry, so it must have matched > on > member, so the member attr should not have been empty. > > AD is flaky enough already, but it's possible that back-meta may have > dropped > the attr values during rewriting, etc. It is perfectly legitimate for back-meta to return attrs with no values, AFAIK; only, the a_vals should contain the address of slap_dummy_bv... 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#5925
by tchemineau＠linagora.com 06 Feb '09

06 Feb '09

Le Thu, 5 Feb 2009 21:04:08 GMT, hyc(a)symas.com a écrit : > ando(a)sys-net.it wrote: > > If it works, then we still have an issue: operations for "o=1,o=2" > > will probably be intercepted by the back-bdb. However, I > > understand that since the first database is glued, it wants to know > > whom it's glued to. > > A fix is in HEAD. It will allow this scenario to succeed, but it will > also allow completely broken subordinate configs to be dynamically > created in cn=config. (configs read from slapd.conf/slapd.d will > still be error checked appropriately.) As such, it needs a bit more > thought. I confirm that we can not create subordinate configs dynamically in cn=config now. I used a previously build version to realize it, just for testing it. There is still errors with slaptest, even on slapd.d. Same errors when I want to start OpenLDAP. 8<-------- ldif_read_file: read entry file: "/usr/local/openldap-2.4/etc/openldap/slapd.d/cn=config/olcDatabase={4}bdb/olcOverlay={0}glue.ldif" => str2entry: "dn: olcOverlay={0}glue objectClass: olcOverlayConfig olcOverlay: {0}glue structuralObjectClass: olcOverlayConfig entryUUID: 939c8813-5218-44bb-a344-bcef144a7b72 creatorsName: cn=config createTimestamp: 20090206104810Z entryCSN: 20090206104810.538680Z#000000#001#000000 modifiersName: cn=config modifyTimestamp: 20090206104810Z " >>> dnPrettyNormal: <olcOverlay={0}glue> <<< dnPrettyNormal: <olcOverlay={0}glue>, <olcOverlay={0}glue> >>> dnPretty: <cn=config> <<< dnPretty: <cn=config> >>> dnNormalize: <cn=config> <<< dnNormalize: <cn=config> >>> dnPretty: <cn=config> <<< dnPretty: <cn=config> >>> dnNormalize: <cn=config> <<< dnNormalize: <cn=config> <= str2entry(olcOverlay={0}glue) -> 0x1658c958 => test_filter PRESENT => access_allowed: search access to "olcOverlay={0}glue,olcDatabase={4}bdb,cn=config" "objectClass" requested <= root access granted => access_allowed: search access granted by manage(=mwrscxd) <= test_filter 6 slaptest: backglue.c:1126: glue_sub_attach: Assertion `on != ((void *)0)' failed. 8<-------- Thomas. -- Thomas Chemineau Groupe LINAGORA - http://www.linagora.com Tél.: +33(0)1 58 18 68 28 - Fax : +33(0)1 58 18 68 29

1 0

Re: ITS#5924
by tchemineau＠linagora.com 06 Feb '09

06 Feb '09

Le Thu, 5 Feb 2009 18:55:14 GMT, ando(a)sys-net.it a écrit : > Should be fixed in HEAD; please test. Test OK for me. Thanks a lot :) Cheers, Thomas. -- Thomas Chemineau Groupe LINAGORA - http://www.linagora.com Tél.: +33(0)1 58 18 68 28 - Fax : +33(0)1 58 18 68 29

1 0

Re: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by michael＠stroeder.com 06 Feb '09

06 Feb '09

philippe.eychart(a)informatique.gov.pf wrote: > And what do you think about : ldap://.nameOfSrvDomainSearch/ ('.' at > begining of the hostname to say "use SRV record" of this domain - search > domain(s) if only '.') ?... I'd recommend not to mess around with the hostport portion of the LDAP URL. In opposite to Hallvard I'm not even sure whether a distinction is really needed when invoking ldap_initialize(). Ciao, Michael.

1 0

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

06 Feb '09

hyc(a)symas.com wrote: > There's something more going on here, because the query in question was > searching for (&(objectclass=posixgroup)(memberUid=foo)(member=foo-DN)). I meant (&(objectclass=posixgroup)(|(memberUid=foo)(member=foo-DN))) > There > was no memberUid at all in the returned entry, so it must have matched on > member, so the member attr should not have been empty. > > AD is flaky enough already, but it's possible that back-meta may have dropped > the attr values during rewriting, etc. -- -- 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 hyc＠symas.com 06 Feb '09

06 Feb '09

ando(a)sys-net.it wrote: > mhardin(a)symas.com wrote: >> Full_Name: Matthew Hardin >> Version: 2.4.13 >> OS: Red Hat Enterprise Linux 4 i686 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (74.38.114.185) >> >> >> Hi All, >> >> We have an LDAP server that is proxying for Active Directory. Periodically slapd >> throws an assertion: >> >> slapd: [....]/ldap24/servers/slapd/schema_init.c:524: octetStringIndexer: >> Assertion `i> 0' failed. >> /etc/init.d/solserver: line 192: 6620 Aborted (core dumped) >> "$EXEC_DIR/$PROC" $ARGS -h "$HOST_LIST" $EXTRA_SLAPD_ARGS >> >> Howard Chu's examination of the core file showed that the remote AD server >> returned a member attribute with no values. This is only legal in LDAP when a >> client sets the attrsonly flag in its search request, and that flag was not set >> here. >> >> The indexer rightly asserts because pcache handed it an attribute with nothing >> to >> index. >> >> I'm not sure what the correct thing to do might be here, but it should not take >> down the slapd. > > The entry should not be cached, IMHO. Perhaps. But then the entire query cannot be cached, because its result set would be known to be incomplete. There's something more going on here, because the query in question was searching for (&(objectclass=posixgroup)(memberUid=foo)(member=foo-DN)). There was no memberUid at all in the returned entry, so it must have matched on member, so the member attr should not have been empty. AD is flaky enough already, but it's possible that back-meta may have dropped the attr values during rewriting, etc. -- -- 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 05 Feb '09

05 Feb '09

mhardin(a)symas.com wrote: > Full_Name: Matthew Hardin > Version: 2.4.13 > OS: Red Hat Enterprise Linux 4 i686 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (74.38.114.185) > > > Hi All, > > We have an LDAP server that is proxying for Active Directory. Periodically slapd > throws an assertion: > > slapd: [....]/ldap24/servers/slapd/schema_init.c:524: octetStringIndexer: > Assertion `i > 0' failed. > /etc/init.d/solserver: line 192: 6620 Aborted (core dumped) > "$EXEC_DIR/$PROC" $ARGS -h "$HOST_LIST" $EXTRA_SLAPD_ARGS > > Howard Chu's examination of the core file showed that the remote AD server > returned a member attribute with no values. This is only legal in LDAP when a > client sets the attrsonly flag in its search request, and that flag was not set > here. > > The indexer rightly asserts because pcache handed it an attribute with nothing > to > index. > > I'm not sure what the correct thing to do might be here, but it should not take > down the slapd. The entry should not be cached, IMHO. 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs