openldap-bugs

openldap-bugs@openldap.org

1 participants
20961 discussions

Re: (ITS#5185) assertion failure in back-meta when the remote directory does not answer a bind request within the time allotted
by ando＠sys-net.it 13 Oct '07

13 Oct '07

mhardin(a)symas.com wrote: > Remote directory servers that do not answer a bind request within the timeout > period will cause an assertion failure in back-meta. > > Analysis: > The meta_back_bind() function calls either meta_back_proxy_authz_bind() if the > bind is taking place with back_meta's rootdn or meta_back_single_bind() if it's > not. > > Once they make the appropriate bind function call, each of these functions calls > meta_back_bind_op_result() to process the result of the bind. Neither > meta_back_proxy_authz_bind() or meta_back_single_bind() set the > LDAP_BACK_CONN_BINDING state. Because it's meta_back_getconn() that's supposed to set that flag when appropriate. > When meta_back_bind_op_result() calls ldap_result(), one of the possible return > codes is 0, and meta_back_bind_op_result() will repeat the ldap_result() call, > provided the timeout hasn't been exceeded or back-meta has been told not to > retry. > > If the wait time has been exceeded the code falls through to an > assert(LDAP_BACK_CONN_BINDING(msc)) statement. This assert is only valid when > meta_back_do_bind() has made the function call, and it will fail if either > meta_back_proxy_authz_bind() or meta_back_single_bind() made the function call. The assert **should** always be valid. Its execution indicates that there's an error somewhere else. Does this happen when binding as the rootdn of the back-meta instance, or as a regular user? If it occurs when binding as the rootdn, then I think I know where the problem is. In that case, apart from me fixing the problem (working at it...), you should also use "pseudoroot-bind-defer yes". 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

(ITS#5185) assertion failure in back-meta when the remote directory does not answer a bind request within the time allotted
by mhardin＠symas.com 13 Oct '07

13 Oct '07

Full_Name: Matthew Hardin Version: 2.3.38 OS: RHEL4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (74.38.114.43) Remote directory servers that do not answer a bind request within the timeout period will cause an assertion failure in back-meta. Analysis: The meta_back_bind() function calls either meta_back_proxy_authz_bind() if the bind is taking place with back_meta's rootdn or meta_back_single_bind() if it's not. Once they make the appropriate bind function call, each of these functions calls meta_back_bind_op_result() to process the result of the bind. Neither meta_back_proxy_authz_bind() or meta_back_single_bind() set the LDAP_BACK_CONN_BINDING state. When meta_back_bind_op_result() calls ldap_result(), one of the possible return codes is 0, and meta_back_bind_op_result() will repeat the ldap_result() call, provided the timeout hasn't been exceeded or back-meta has been told not to retry. If the wait time has been exceeded the code falls through to an assert(LDAP_BACK_CONN_BINDING(msc)) statement. This assert is only valid when meta_back_do_bind() has made the function call, and it will fail if either meta_back_proxy_authz_bind() or meta_back_single_bind() made the function call. Possible Fixes: The correct fix would seem to be to remove the assert(), since in two out of three cases the meta_back_bind_op_result() function is being called with the LDAP_BACK_CONN_BINDING state not set. It is also possible to set and clear the LDAP_BACK_CONN_BINDING state as appropriate from the other two funcions that call it, but this seems incorrect, as the LDAP_BACK_CONN_BINDING state is only manipulated in the meta_back_single_dobind() direct bind function.

1 0

(ITS#5184) pkg-config file for libraries
by mccann＠jhu.edu 12 Oct '07

12 Oct '07

Full_Name: William Jon McCann Version: 2.3.34 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.220.146.19) It would be really helpful for openldap to ship a pkg-config (.pc) file for libldap. http://en.wikipedia.org/wiki/Pkg-config

1 0

Re: (ITS#5183) Index problem with ;x- attributes.
by quanah＠zimbra.com 12 Oct '07

12 Oct '07

--On Thursday, October 11, 2007 12:37 PM +0000 Magnus.Jonsson(a)umdac.umu.se wrote: > Full_Name: Magnus Jonsson > Version: 2.3.38 > OS: Debian GNU/linux ?Etch? > URL: http://foo.fot.nu/reproduce.txt > Submission from: (NULL) (130.239.200.171) > > > We are using ;x- attributes in a specific appliation to group some > attributes. > > When removing a ;x- attrbute all the indexs for that attribute disapears. > > example: > > cn: index > cn;x-f-1: index > cn;x-f-2: index > > If a remove the cn;x-f-1 attribute I can't search for (cn=index) anymore. > > I have tested with bdb and ldbm. > > Berkeley v4.3 is used. Did you fail to note how OpenLDAP's configure specifically is designed to abort when building against BDB 4.3? BDB 4.3 is known to be a bad release. I suggest using 4.2.52+patchs, 4.4+patches, or 4.5+patches. Not that this necessarily will resolve the issue you are reporting. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5183) Index problem with ;x- attributes.
by Magnus.Jonsson＠umdac.umu.se 11 Oct '07

11 Oct '07

Full_Name: Magnus Jonsson Version: 2.3.38 OS: Debian GNU/linux Etch URL: http://foo.fot.nu/reproduce.txt Submission from: (NULL) (130.239.200.171) We are using ;x- attributes in a specific appliation to group some attributes. When removing a ;x- attrbute all the indexs for that attribute disapears. example: cn: index cn;x-f-1: index cn;x-f-2: index If a remove the cn;x-f-1 attribute I can't search for (cn=index) anymore. I have tested with bdb and ldbm. Berkeley v4.3 is used. A small example with all you need to reproduce the symtoms is available in the provided link.

1 0

Re: (ITS#5182) test048 in OPENLDAP_REL_ENG_2_4
by ghenry＠suretecsystems.com 10 Oct '07

10 Oct '07

<quote who="ghenry(a)suretecsystems.com"> > <quote who="ghenry(a)OpenLDAP.org"> >> Full_Name: Gavin Henry >> Version: OPENLDAP_REL_ENG_2_4 >> OS: Fedora 7 >> URL: http://www.suretec.org/our_docs/test048.tar.gz >> Submission from: (NULL) (80.229.93.1) >> Submitted by: ghenry >> >> >> I'm getting a fail at: >> >> "master and R1 slave databases differ" >> >> I'd like to learn how to debug this. Any tips? >> >> This is on a 64-Bit AMD machine, 2GB Ram, Berkeley 4.2.52. >> >> Thanks. > > I'll double check this in HEAD now too. Should have done that first. > All tests pass in HEAD. test048 still failing in RE24. Gavin.

1 0

Re: (ITS#5172) slash in dn
by hyc＠symas.com 10 Oct '07

10 Oct '07

reinhold.may(a)gmx.de wrote: > Raphael, > >> My new crystal ball tells me that you are not saying the >> essential part of the problem: you are using back-ldif, isn't >> it ? > > It is! Did I miss a hint which would have told me not to use > back-ldif or use it differently? back-ldif is really not meant for general use. It does no caching or indexing, so it will perform very poorly in general. It was only written to provide a base for cn=config. -- -- 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#5172) slash in dn
by reinhold.may＠gmx.de 10 Oct '07

10 Oct '07

Pierangelo, > This output is not useful. I'm sorry. > First of all, can you tell what ldapadd you're using? Please > make sure you run the version of ldapadd that comes with > OpenLDAP sources you built. I can confirm that ldapadd was built alongside slapd whose version I stated in my original post (2.3.35). As I'm not at home at the moment, the only thing I can do is extract the syslog of that import in question which admittedly doesn't say much, however, here it goes: Oct 10 02:16:19 mm slapd[9746]: slapd starting Oct 10 02:16:31 mm slapd[9746]: conn=0 fd=8 ACCEPT from IP=192.168.0.3:40394 (IP =0.0.0.0:389) Oct 10 02:16:31 mm slapd[9746]: conn=0 op=0 BIND dn="cn=root,dc=somedomain,dc=or g" method=128 Oct 10 02:16:31 mm slapd[9746]: failed to open file "/var/lib/openldap-data/dc=s omedomain,dc=org/cn=root.ldif": No such file or directory Oct 10 02:16:31 mm slapd[9746]: conn=0 op=0 BIND dn="cn=root,dc=somedomain,dc=or g" mech=SIMPLE ssf=0 Oct 10 02:16:31 mm slapd[9746]: conn=0 op=0 RESULT tag=97 err=0 text= Oct 10 02:16:31 mm slapd[9746]: conn=0 op=1 ADD dn="dc=somedomain,dc=org" Oct 10 02:16:31 mm slapd[9746]: conn=0 op=1 RESULT tag=105 err=0 text= Oct 10 02:16:31 mm slapd[9746]: conn=0 op=2 ADD dn="ou=My address book,dc=somedo main,dc=org" Oct 10 02:16:31 mm slapd[9746]: conn=0 op=2 RESULT tag=105 err=0 text= Oct 10 02:16:31 mm slapd[9746]: conn=0 op=3 ADD dn="cn=With/Slash,ou=My address book,dc=somedomain,dc=org" Oct 10 02:16:31 mm slapd[9746]: conn=0 op=3 RESULT tag=105 err=32 text=Parent do es not exist Oct 10 02:16:31 mm slapd[9746]: conn=0 op=4 UNBIND Oct 10 02:16:31 mm slapd[9746]: conn=0 fd=8 closed Raphael, > My new crystal ball tells me that you are not saying the > essential part of the problem: you are using back-ldif, isn't > it ? It is! Did I miss a hint which would have told me not to use back-ldif or use it differently? Reinhold

1 0

Re: (ITS#5172) slash in dn
by ando＠sys-net.it 10 Oct '07

10 Oct '07

raphael.ouazana(a)linagora.com wrote: > Le Mer 10 octobre 2007 02:31, reinhold.may(a)gmx.de a écrit : >> adding new entry "cn=With/Slash,ou=My address book,dc=somedomain,dc=org" >> ldap_add: No such object (32) >> additional info: Parent does not exist >> >> which is erroneous. > > My new crystal ball tells me that you are not saying the essential part of > the problem: you are using back-ldif, isn't it ? Well, if Raphael's analysis is correct (in that case, can I borrow your crystal ball, occasionally?), the problem is now fixed in HEAD/re24/re23. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5182) test048 in OPENLDAP_REL_ENG_2_4
by ghenry＠suretecsystems.com 10 Oct '07

10 Oct '07

<quote who="ando(a)sys-net.it"> > ghenry(a)OpenLDAP.org wrote: > >> >> "master and R1 slave databases differ" >> >> I'd like to learn how to debug this. Any tips? >> >> This is on a 64-Bit AMD machine, 2GB Ram, Berkeley 4.2.52. > > Can't look at your tar right now; but: > > - check in scripts/test048* where the "master and R1 slave databases > differ" line is, and see what files are being tested > > - they probably are macros, defined in scripts/defines.sh, something > like testrun/ldif.flt and testrun/ldapsearch.flt yeah, did all that. It's one entry difference. server1.1.flt and server2.1.flt > > - run diff -iu FILE1 FILE2 as resolved above and see where it fails. > > If it points you somewhere (e.g. the difference is trivial, or there's > something very specific to a precise modification) fine, otherwise post > the outcome. Will check again on HEAD and continue. > > 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

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