openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

Re: (ITS#4850) back-meta stops returning data
by ando＠sys-net.it 23 Feb '07

23 Feb '07

hyc(a)symas.com wrote: >> I am experiencing problems with back_meta. It does return search results for >> some time, but at some point starts returning empty search results, with SEARCH >> RESULT err=32 in the logfile. This often (but not always) happens after 5 - 30 >> minutes. > > Significant changes were made to back-meta between 2.3.32 and 2.3.33. The > current version is 2.3.34. Please upgrade and see if the issue is still present. I believe the reported behavior does no longer occur with 2.3.34. What you report seems to be related to broken behavior when the remote server closes the connection as a consequence of an idletimeout. 2.3.33 saw a lot of improvements on this side, resulting from significant development efforts and stress testing in a harsh environment, where resilience to odd target behavior was a key requirement. 2.3.34 fixed minor issues after that upgrade, and more minor fixes already are in re23 for next 2.3 release, if any. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#3812
by hyc＠symas.com 23 Feb '07

23 Feb '07

quanah(a)stanford.edu wrote: > --On Friday, February 23, 2007 7:27 PM +0000 hyc(a)symas.com wrote: > >> It might be nice to set up an automated script to pull the updated >> manpages from CVS onto the web site. > >>From CVS for the current primary release. I.e., I think it would be bad if > the manpages for 2.4 showed up right now on the website. You'll note that the web site has a selector for the release you want to view. In some respects I like the old pages being on there because their dates establish a ballpark for when a feature first appeared (well, was first documented). But I think we should always have a "Current" selection as well, that always corresponds to the latest general-use release. -- -- 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#3812
by quanah＠stanford.edu 23 Feb '07

23 Feb '07

--On Friday, February 23, 2007 7:27 PM +0000 hyc(a)symas.com wrote: > It might be nice to set up an automated script to pull the updated > manpages from CVS onto the web site. >From CVS for the current primary release. I.e., I think it would be bad if the manpages for 2.4 showed up right now on the website. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

ITS#3812
by hyc＠symas.com 23 Feb '07

23 Feb '07

It might be nice to set up an automated script to pull the updated manpages from CVS onto the web site. -- -- 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#4844) Missing 2.4 man pages and things marked as "Experimental"
by ghenry＠suretecsystems.com 23 Feb '07

23 Feb '07

<quote who="Howard Chu"> > ghenry(a)suretecsystems.com wrote: >> <quote who="ando(a)sys-net.it"> >>> ghenry(a)suretecsystems.com wrote: >>> >>>> Just a quick to note that there are some overlays missing from >>>> slapd.overlays.5 >>>> in 2.4.4alpha and actual man pages. >>> Please enumerate them; some are intentionally not present because they >>> are not intended for real use. >> >> * dyngroup has no man page, but is listed slapd.overlays.5 >> * slapo-valsort.5 isn't in slapd.overlays.5 >> * slapo-dds.5 isn't listed in slapd.overlays.5 >> * constraint.c has no docs or listed in slapd.overlays.5 > > slapo-constraint.5 was added to CVS April 29 2006. Ok, it wasn't in the 2.4.4alpha though. > >> * seqmod.c has no docs or listed in slapd.overlays.5 > > This is a demo overlay, not intended for actual use. Ah, ok. > > -- > -- 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#4850) back-meta stops returning data
by hyc＠symas.com 23 Feb '07

23 Feb '07

ulf.moeller(a)secardeo.com wrote: > Full_Name: Ulf Moeller > Version: 2.3.32 > OS: SLES 9 > URL: > Submission from: (NULL) (62.245.244.226) > > > I am experiencing problems with back_meta. It does return search results for > some time, but at some point starts returning empty search results, with SEARCH > RESULT err=32 in the logfile. This often (but not always) happens after 5 - 30 > minutes. Significant changes were made to back-meta between 2.3.32 and 2.3.33. The current version is 2.3.34. Please upgrade and see if the issue is still present. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#4850) back-meta stops returning data
by ulf.moeller＠secardeo.com 23 Feb '07

23 Feb '07

Full_Name: Ulf Moeller Version: 2.3.32 OS: SLES 9 URL: Submission from: (NULL) (62.245.244.226) I am experiencing problems with back_meta. It does return search results for some time, but at some point starts returning empty search results, with SEARCH RESULT err=32 in the logfile. This often (but not always) happens after 5 - 30 minutes. It doesn't return data from either of the ldap servers it is connected to. The problem also occurs in a minimal configuration with just one "uri" defined. After slapd is restarted, it again works properly for some time. When running in GDB, I get the following backtrace: Program received signal SIGPIPE, Broken pipe. 0xffffe410 in __kernel_vsyscall () (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0x4003a55b in __write_nocancel () from /lib/tls/libpthread.so.0 #2 0x08127f34 in sb_stream_write (sbiod=0x81e69c0, buf=0x81deb60, len=64) at sockbuf.c:521 #3 0x081287b6 in sb_debug_write (sbiod=0x81e69d8, buf=0x81deb60, len=64) at sockbuf.c:820 #4 0x08127e50 in ber_int_sb_write (sb=0x81e6d38, buf=0x81deb60, len=64) at sockbuf.c:431 #5 0x08124dd6 in ber_flush (sb=0x81e6d38, ber=0x81e6e40, freeit=0) at io.c:232 #6 0x08111813 in ldap_int_flush_request (ld=0x81e6c00, lr=0x81dfb88) at request.c:151 #7 0x08111c1a in ldap_send_server_request (ld=0x81e6c00, ber=0x81e6e40, msgid=21, parentreq=0x0, srvlist=0x0, lc=0x81dfb40, bind=0x0) at request.c:301 #8 0x081117ca in ldap_send_initial_request (ld=0x81e6c00, msgtype=99, dn=0x40a1300c "", ber=0x81e6e40, msgid=21) at request.c:135 #9 0x08104661 in ldap_search_ext (ld=0x81e6c00, base=0x40a1300c "", scope=2, filter=0x81e6e18 "(mail=someone(a)domain.de)", attrs=0x0, attrsonly=0, sctrls=0x0, cctrls=0x0, timeout=0x40a10f18, sizelimit=500, msgidp=0x81e6b60) at search.c:109 #10 0x080c8194 in meta_back_search_start (op=0x40c007b0, rs=0x40a12210, dc=0x40a110f0, msc=0x81e6bb8, candidate=0, candidates=0x81e6b58) at search.c:208 #11 0x080c83f3 in meta_back_search (op=0x40c007b0, rs=0x40a12210) at search.c:285 #12 0x08063944 in fe_op_search (op=0x40c007b0, rs=0x40a12210) at search.c:355 #13 0x08063465 in do_search (op=0x40c007b0, rs=0x40a12210) at search.c:217 #14 0x08061180 in connection_operation (ctx=0x40a122a0, arg_v=0x40c007b0) at connection.c:1132 #15 0x0810052f in ldap_int_thread_pool_wrapper (xpool=0x81b8b18) at tpool.c:478 #16 0x40035cf7 in start_thread () from /lib/tls/libpthread.so.0 #17 0x400fa21e in clone () from /lib/tls/libc.so.6 #18 0x40a12bb0 in ?? () Here is an (anonymized) log: Feb 22 15:16:17 server slapd[14494]: daemon: activity on 1 descriptor Feb 22 15:16:17 server slapd[14494]: daemon: activity on: Feb 22 15:16:17 server slapd[14494]: Feb 22 15:16:17 server slapd[14494]: >>> slap_listener(ldap://:3389) Feb 22 15:16:17 server slapd[14494]: daemon: listen=8, new connection on 11 Feb 22 15:16:17 server slapd[14494]: daemon: added 11r (active) listener=(nil) Feb 22 15:16:17 server slapd[14494]: conn=5 fd=11 ACCEPT from IP=127.0.0.1:34632 (IP=0.0.0.0 :3389) Feb 22 15:16:17 server slapd[14494]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Feb 22 15:16:17 server slapd[14494]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Feb 22 15:16:17 server slapd[14494]: daemon: activity on 1 descriptor Feb 22 15:16:17 server slapd[14494]: daemon: activity on: Feb 22 15:16:17 server slapd[14494]: 11r Feb 22 15:16:17 server slapd[14494]: Feb 22 15:16:17 server slapd[14494]: daemon: read active on 11 Feb 22 15:16:17 server slapd[14494]: connection_get(11) Feb 22 15:16:17 server slapd[14494]: connection_get(11): got connid=5 Feb 22 15:16:17 server slapd[14494]: connection_read(11): checking for input on id=5 Feb 22 15:16:17 server slapd[14494]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Feb 22 15:16:17 server slapd[14494]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Feb 22 15:16:17 server slapd[14494]: do_bind Feb 22 15:16:17 server slapd[14494]: >>> dnPrettyNormal: <> Feb 22 15:16:17 server slapd[14494]: <<< dnPrettyNormal: <>, <> Feb 22 15:16:17 server slapd[14494]: do_bind: version=3 dn="" method=128 Feb 22 15:16:17 server slapd[14494]: conn=5 op=0 BIND dn="" method=128 Feb 22 15:16:17 server slapd[14494]: conn=5 op=0 BIND dn="" method=128 Feb 22 15:16:17 server slapd[14494]: send_ldap_result: conn=5 op=0 p=3 Feb 22 15:16:17 server slapd[14494]: send_ldap_result: err=0 matched="" text="" Feb 22 15:16:17 server slapd[14494]: send_ldap_response: msgid=1 tag=97 err=0 Feb 22 15:16:17 server slapd[14494]: conn=5 op=0 RESULT tag=97 err=0 text= Feb 22 15:16:17 server slapd[14494]: do_bind: v3 anonymous bind Feb 22 15:16:17 server slapd[14494]: daemon: activity on 1 descriptor Feb 22 15:16:17 server slapd[14494]: daemon: activity on: Feb 22 15:16:17 server slapd[14494]: 11r Feb 22 15:16:17 server slapd[14494]: Feb 22 15:16:17 server slapd[14494]: daemon: read active on 11 Feb 22 15:16:17 server slapd[14494]: connection_get(11) Feb 22 15:16:17 server slapd[14494]: connection_get(11): got connid=5 Feb 22 15:16:17 server slapd[14494]: connection_read(11): checking for input on id=5 Feb 22 15:16:17 server slapd[14494]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Feb 22 15:16:17 server slapd[14494]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Feb 22 15:16:17 server slapd[14494]: do_search Feb 22 15:16:17 server slapd[14494]: >>> dnPrettyNormal: <> Feb 22 15:16:17 server slapd[14494]: <<< dnPrettyNormal: <>, <> Feb 22 15:16:17 server slapd[14494]: SRCH "" 2 0 Feb 22 15:16:17 server slapd[14494]: 0 0 0 Feb 22 15:16:17 server slapd[14494]: begin get_filter Feb 22 15:16:17 server slapd[14494]: EQUALITY Feb 22 15:16:17 server slapd[14494]: end get_filter 0 Feb 22 15:16:17 server slapd[14494]: filter: (mail=someone(a)domain.de) Feb 22 15:16:17 server slapd[14494]: attrs: Feb 22 15:16:17 server slapd[14494]: Feb 22 15:16:17 server slapd[14494]: conn=5 op=1 SRCH base="" scope=2 deref=0 filter="(mail=someone(a)domain.de)" Feb 22 15:16:17 server slapd[14494]: ==> limits_get: conn=5 op=1 dn="[anonymous]" Feb 22 15:16:17 server slapd[14494]: conn=5 op=1: meta_back_getconn[0] Feb 22 15:16:17 server slapd[14494]: conn=5 op=1 meta_back_getconn: candidates=1 conn=-1 fet ched Feb 22 15:16:17 server slapd[14494]: conn=5 op=1 meta_back_dobind: conn=-1 Feb 22 15:16:17 server slapd[14494]: conn=5 op=1 meta_back_dobind: conn=-1 bound=1 Feb 22 15:16:17 server slapd[14494]: [rw] searchBase: "" -> "" Feb 22 15:16:17 server slapd[14494]: send_ldap_result: conn=5 op=1 p=3 Feb 22 15:16:17 server slapd[14494]: send_ldap_result: err=32 matched="" text="" Feb 22 15:16:17 server slapd[14494]: send_ldap_response: msgid=2 tag=101 err=32 Feb 22 15:16:17 server slapd[14494]: conn=5 op=1 SEARCH RESULT tag=101 err=32 nentries=0 tex t= Feb 22 15:16:17 server slapd[14494]: daemon: activity on 1 descriptor Feb 22 15:16:17 server slapd[14494]: daemon: activity on: Feb 22 15:16:17 server slapd[14494]: 11r Feb 22 15:16:17 server slapd[14494]: Feb 22 15:16:17 server slapd[14494]: daemon: read active on 11 Feb 22 15:16:17 server slapd[14494]: connection_get(11) Feb 22 15:16:17 server slapd[14494]: connection_get(11): got connid=5 Feb 22 15:16:17 server slapd[14494]: connection_read(11): checking for input on id=5 Feb 22 15:16:17 server slapd[14494]: ber_get_next on fd 11 failed errno=0 (Success) Feb 22 15:16:17 server slapd[14494]: connection_read(11): input error=-2 id=5, closing. Feb 22 15:16:17 server slapd[14494]: connection_closing: readying conn=5 sd=11 for close Feb 22 15:16:17 server slapd[14494]: connection_close: deferring conn=5 sd=11 Feb 22 15:16:17 server slapd[14494]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Feb 22 15:16:17 server slapd[14494]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Feb 22 15:16:17 server slapd[14494]: daemon: activity on 1 descriptor Feb 22 15:16:17 server slapd[14494]: daemon: activity on: Feb 22 15:16:17 server slapd[14494]: Feb 22 15:16:17 server slapd[14494]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Feb 22 15:16:17 server slapd[14494]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Feb 22 15:16:17 server slapd[14494]: do_unbind Feb 22 15:16:17 server slapd[14494]: conn=5 op=2 UNBIND Feb 22 15:16:17 server slapd[14494]: connection_resched: attempting closing conn=5 sd=11 Feb 22 15:16:17 server slapd[14494]: connection_close: conn=5 sd=11 Feb 22 15:16:17 server slapd[14494]: =>meta_back_conn_destroy: fetching conn=5 DN="" Feb 22 15:16:17 server slapd[14494]: daemon: removing 11 Feb 22 15:16:17 server slapd[14494]: conn=5 fd=11 closed ()

1 0

Re: (ITS#4844) Missing 2.4 man pages and things marked as "Experimental"
by hyc＠symas.com 23 Feb '07

23 Feb '07

ghenry(a)suretecsystems.com wrote: > <quote who="ando(a)sys-net.it"> >> ghenry(a)suretecsystems.com wrote: >> >>> Just a quick to note that there are some overlays missing from >>> slapd.overlays.5 >>> in 2.4.4alpha and actual man pages. >> Please enumerate them; some are intentionally not present because they >> are not intended for real use. > > * dyngroup has no man page, but is listed slapd.overlays.5 > * slapo-valsort.5 isn't in slapd.overlays.5 > * slapo-dds.5 isn't listed in slapd.overlays.5 > * constraint.c has no docs or listed in slapd.overlays.5 slapo-constraint.5 was added to CVS April 29 2006. > * seqmod.c has no docs or listed in slapd.overlays.5 This is a demo overlay, not intended for actual use. -- -- 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#4849) LDAP URL not recognized with bind9
by cyril＠coupel.net 23 Feb '07

23 Feb '07

Tanks for your answer. I tested by removing the %xxxx% from the URL and the tests are passed; but there is an error saying that there is no %xxx% token. I already open a case to the BIND team, but they reply this is not a bind problem. However, I will transmit this information to the BIND/DLZ team. -----Message d'origine----- De : Pierangelo Masarati [mailto:ando@sys-net.it] Envoyé : vendredi 23 février 2007 12:56 À : Cyril COUPEL; openldap-its(a)openldap.org Objet : Re: (ITS#4849) LDAP URL not recognized with bind9 Please keep replies on the Issue Tracking System (ITS) list, otherwise you'll defeat its purpose of tracking issues. Cyril COUPEL wrote: > I agree with this information. > The fact is the ldapURL is not used as it, the key %zone% (or %client%) is > replaced with the ns domain (the client name). > > It was working well since I upgrade to 2.3.30-r2. > I tried to downgrade to a previous version of openldap and it was working > again, so it is a openldap problem. I see the fact that earlier versions of OpenLDAP were not compliant with standard track documents as a good reason to improve it by making it compliant, rather than a reason to keep it broken. The client is broken since it appears to parse the URL __before__ replacing portions of it that are marked using a character that is invalid in URLs. Either that client implements and uses its own broken URL parsing routines (at the risk of parsing broken URLs incorrectly, since they contain invalid characters), or it does URL parsing __after__ string replacement (i.e. after their string has been turned into a valid URL). I don't see why OpenLDAP should break (or, in this case, remain broken) to maintain compatibility with a poorly implemented client. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4849) LDAP URL not recognized with bind9
by ando＠sys-net.it 23 Feb '07

23 Feb '07

Please keep replies on the Issue Tracking System (ITS) list, otherwise you'll defeat its purpose of tracking issues. Cyril COUPEL wrote: > I agree with this information. > The fact is the ldapURL is not used as it, the key %zone% (or %client%) is > replaced with the ns domain (the client name). > > It was working well since I upgrade to 2.3.30-r2. > I tried to downgrade to a previous version of openldap and it was working > again, so it is a openldap problem. I see the fact that earlier versions of OpenLDAP were not compliant with standard track documents as a good reason to improve it by making it compliant, rather than a reason to keep it broken. The client is broken since it appears to parse the URL __before__ replacing portions of it that are marked using a character that is invalid in URLs. Either that client implements and uses its own broken URL parsing routines (at the risk of parsing broken URLs incorrectly, since they contain invalid characters), or it does URL parsing __after__ string replacement (i.e. after their string has been turned into a valid URL). I don't see why OpenLDAP should break (or, in this case, remain broken) to maintain compatibility with a poorly implemented client. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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

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