- openldap-bugs - openldap.org

Re: (ITS#6230) test056-monitor: comparison failed - database monitor output is not correct
by hyc＠symas.com 27 Jul '09

27 Jul '09

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: HEAD > OS: openSUSE Linux 11.1 > URL: > Submission from: (NULL) (84.163.81.222) > > > Please let me know whether testrun/ is needed for examining this issue: You could simply post the diff of the two files it was comparing. > >>>>>> Starting test056-monitor for bdb... > running defines.sh > Starting slapd on TCP/IP port ... > Using ldapsearch to check that slapd is running... > Using ldapsearch to read connection monitor entries... > Filtering ldapsearch results... > Filtering expected data... > Comparing filter output... > Using ldapsearch to read database monitor entries... > Filtering ldapsearch results... > Comparing filter output... > comparison failed - database monitor output is not correct >>>>>> ./scripts/test056-monitor failed for bdb (exit 1) > make[2]: *** [bdb-mod] Error 1 > make[2]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' > make[1]: *** [test] Error 2 > make[1]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' > make: *** [test] Error 2 > > -- -- 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

(ITS#6230) test056-monitor: comparison failed - database monitor output is not correct
by michael＠stroeder.com 27 Jul '09

27 Jul '09

Full_Name: Michael Ströder Version: HEAD OS: openSUSE Linux 11.1 URL: Submission from: (NULL) (84.163.81.222) Please let me know whether testrun/ is needed for examining this issue: >>>>> Starting test056-monitor for bdb... running defines.sh Starting slapd on TCP/IP port ... Using ldapsearch to check that slapd is running... Using ldapsearch to read connection monitor entries... Filtering ldapsearch results... Filtering expected data... Comparing filter output... Using ldapsearch to read database monitor entries... Filtering ldapsearch results... Comparing filter output... comparison failed - database monitor output is not correct >>>>> ./scripts/test056-monitor failed for bdb (exit 1) make[2]: *** [bdb-mod] Error 1 make[2]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' make: *** [test] Error 2

1 0

Re: (ITS#6229) make test blocked on test001-slapadd
by battery＠writeme.com 27 Jul '09

27 Jul '09

--0015175707f6684066046fb12f9b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Yeah... those. On Mon, Jul 27, 2009 at 8:48 AM, czybear <czybear(a)qq.com> wrote: > Did you mean patches from the following URL? I didn't apply them yet, I'll > try them tomorry, thank you! > > http://www.oracle.com/technology/products/berkeley-db/db/update/4.7.25/patc… > > > ------------------ Original ------------------ > *From: * "Matt Kassawara"<battery(a)writeme.com>; > *Date: * Mon, Jul 27, 2009 10:40 PM > *To: * "czybear"<czybear(a)qq.com>; > *Cc: * "openldap-its"<openldap-its(a)openldap.org>; > *Subject: * Re: (ITS#6229) make test blocked on test001-slapadd > > Did you build against BDB 4.7.25? ?If so, did you apply all the patches? > > On Mon, Jul 27, 2009 at 3:04 AM, <czybear(a)qq.com> wrote: > >> Full_Name: John Chen >> Version: 2.4.16/2.4.17 >> OS: RHEL AS 5.2 (Tikanga) x86)64 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (117.88.156.12) >> >> >> [root@as5u2-64]# make test >> cd tests; make test >> make[1]: Entering directory `/home/install/ldap-2.4/openldap-2.4.16/tests' >> make[2]: Entering directory `/home/install/ldap-2.4/openldap-2.4.16/tests' >> Initiating LDAP tests for BDB... >> Cleaning up test run directory leftover from previous run. >> Running ./scripts/all... >> >>>>> Executing all LDAP tests for bdb >> >>>>> Starting test000-rootdse ... >> running defines.sh >> Starting slapd on TCP/IP port 9011... >> Using ldapsearch to retrieve the root DSE... >> Waiting 5 seconds for slapd to start... >> Using ldapsearch to retrieve the cn=Subschema... >> Using ldapsearch to retrieve the cn=Monitor... >> dn: >> objectClass: top >> objectClass: OpenLDAProotDSE >> structuralObjectClass: OpenLDAProotDSE >> configContext: cn=config >> namingContexts: o=OpenLDAP Project,l=Internet >> monitorContext: cn=Monitor >> supportedControl: 1.3.6.1.4.1.4203.1.9.1.1 >> supportedControl: 2.16.840.1.113730.3.4.18 >> supportedControl: 2.16.840.1.113730.3.4.2 >> supportedControl: 1.3.6.1.4.1.4203.1.10.1 >> supportedControl: 1.2.840.113556.1.4.319 >> supportedControl: 1.2.826.0.1.3344810.2.3 >> supportedControl: 1.3.6.1.1.13.2 >> supportedControl: 1.3.6.1.1.13.1 >> supportedControl: 1.3.6.1.1.12 >> supportedExtension: 1.3.6.1.4.1.4203.1.11.1 >> supportedExtension: 1.3.6.1.4.1.4203.1.11.3 >> supportedExtension: 1.3.6.1.1.8 >> supportedFeatures: 1.3.6.1.1.14 >> supportedFeatures: 1.3.6.1.4.1.4203.1.5.1 >> supportedFeatures: 1.3.6.1.4.1.4203.1.5.2 >> supportedFeatures: 1.3.6.1.4.1.4203.1.5.3 >> supportedFeatures: 1.3.6.1.4.1.4203.1.5.4 >> supportedFeatures: 1.3.6.1.4.1.4203.1.5.5 >> supportedLDAPVersion: 3 >> vendorName: The OpenLDAP Project <http://www.openldap.org/> >> entryDN: >> subschemaSubentry: cn=Subschema >> >> dn: cn=Subschema >> objectClass: top >> objectClass: subentry >> objectClass: subschema >> objectClass: extensibleObject >> cn: Subschema >> >> dn: cn=Monitor >> objectClass: monitorServer >> cn: Monitor >> description: This subtree contains monitoring/managing objects. >> description: This object contains information about this server. >> description: Most of the information is held in operational attributes, >> which >> ?must be explicitly requested. >> monitoredInfo: OpenLDAP: slapd 2.4.16 (Jul 23 2009 13:44:24) >> >> >>>>> Test succeeded >> >>>>> ./scripts/test000-rootdse completed OK. >> >> >>>>> Starting test001-slapadd ... >> running defines.sh >> Running slapadd to build slapd database... >> >> ========================================== >> Then blocked, and no moving any more ... >> >> > --0015175707f6684066046fb12f9b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yeah... those.<br><br><div class=3D"gmail_quote">On Mon, Jul 27, 2009 at 8:= 48 AM, czybear <span dir=3D"ltr"><<a href=3D"mailto:czybear@qq.com">czyb= ear(a)qq.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style= =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div>Did you mean patches from the following URL? I didn't apply them y= et, I'll try them tomorry, thank you!</div><div class=3D"im"> <div><a href=3D"http://www.oracle.com/technology/products/berkeley-db/db/up= date/4.7.25/patch.4.7.25.html" target=3D"_blank">http://www.oracle.com/tech= nology/products/berkeley-db/db/update/4.7.25/patch.4.7.25.html</a></div> </div><div> <div>=A0</div> <div>=A0</div> <div style=3D"color:#000"><div class=3D"im"> <div style=3D"padding-right:0px;padding-left:0px;font-size:12px;padding-bot= tom:2px;padding-top:2px;font-family:Arial Narrow">------------------=A0Orig= inal=A0------------------</div> <div style=3D"font-size:12px"> <div><b>From: </b>=A0"Matt Kassawara"<<a href=3D"mailto:batter= y(a)writeme.com" target=3D"_blank">battery(a)writeme.com</a>>;</div> <div><b>Date: </b>=A0Mon, Jul 27, 2009 10:40 PM</div> <div><b>To: </b>=A0"czybear"<<a href=3D"mailto:czybear@qq.com"= target=3D"_blank">czybear(a)qq.com</a>>; </div> <div><b>Cc: </b>=A0"openldap-its"<<a href=3D"mailto:openldap-i= ts(a)openldap.org" target=3D"_blank">openldap-its(a)openldap.org</a>>; </div= > <div><b>Subject: </b>=A0Re: (ITS#6229) make test blocked on test001-slapadd= </div></div> <div>=A0</div></div><div><div class=3D"h5">Did you build against BDB 4.7.25= ? ?If so, did you apply all the patches?<br><br> <div class=3D"gmail_quote">On Mon, Jul 27, 2009 at 3:04 AM, <span dir=3D"lt= r"><<a href=3D"mailto:czybear@qq.com" target=3D"_blank">czybear(a)qq.com</= a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"padding-left:1ex;margin:0px 0px = 0px 0.8ex;border-left:#ccc 1px solid">Full_Name: John Chen<br>Version: 2.4.= 16/2.4.17<br>OS: RHEL AS 5.2 (Tikanga) x86)64<br>URL: <a href=3D"ftp://ftp.= openldap.org/incoming/" target=3D"_blank">ftp://ftp.openldap.org/incoming/<= /a><br> Submission from: (NULL) (117.88.156.12)<br><br><br>[root@as5u2-64]# make te= st<br>cd tests; make test<br>make[1]: Entering directory `/home/install/lda= p-2.4/openldap-2.4.16/tests'<br>make[2]: Entering directory `/home/inst= all/ldap-2.4/openldap-2.4.16/tests'<br> Initiating LDAP tests for BDB...<br>Cleaning up test run directory leftover= from previous run.<br>Running ./scripts/all...<br>>>>>> Exe= cuting all LDAP tests for bdb<br>>>>>> Starting test000-root= dse ...<br> running defines.sh<br>Starting slapd on TCP/IP port 9011...<br>Using ldapse= arch to retrieve the root DSE...<br>Waiting 5 seconds for slapd to start...= <br>Using ldapsearch to retrieve the cn=3DSubschema...<br>Using ldapsearch = to retrieve the cn=3DMonitor...<br> dn:<br>objectClass: top<br>objectClass: OpenLDAProotDSE<br>structuralObject= Class: OpenLDAProotDSE<br>configContext: cn=3Dconfig<br>namingContexts: o= =3DOpenLDAP Project,l=3DInternet<br>monitorContext: cn=3DMonitor<br>support= edControl: 1.3.6.1.4.1.4203.1.9.1.1<br> supportedControl: 2.16.840.1.113730.3.4.18<br>supportedControl: 2.16.840.1.= 113730.3.4.2<br>supportedControl: 1.3.6.1.4.1.4203.1.10.1<br>supportedContr= ol: 1.2.840.113556.1.4.319<br>supportedControl: 1.2.826.0.1.3344810.2.3<br> supportedControl: 1.3.6.1.1.13.2<br>supportedControl: 1.3.6.1.1.13.1<br>sup= portedControl: 1.3.6.1.1.12<br>supportedExtension: 1.3.6.1.4.1.4203.1.11.1<= br>supportedExtension: 1.3.6.1.4.1.4203.1.11.3<br>supportedExtension: 1.3.6= .1.1.8<br> supportedFeatures: 1.3.6.1.1.14<br>supportedFeatures: 1.3.6.1.4.1.4203.1.5.= 1<br>supportedFeatures: 1.3.6.1.4.1.4203.1.5.2<br>supportedFeatures: 1.3.6.= 1.4.1.4203.1.5.3<br>supportedFeatures: 1.3.6.1.4.1.4203.1.5.4<br>supportedF= eatures: 1.3.6.1.4.1.4203.1.5.5<br> supportedLDAPVersion: 3<br>vendorName: The OpenLDAP Project <<a href=3D"= http://www.openldap.org/" target=3D"_blank">http://www.openldap.org/</a>&gt= ;<br>entryDN:<br>subschemaSubentry: cn=3DSubschema<br><br>dn: cn=3DSubschem= a<br> objectClass: top<br>objectClass: subentry<br>objectClass: subschema<br>obje= ctClass: extensibleObject<br>cn: Subschema<br><br>dn: cn=3DMonitor<br>objec= tClass: monitorServer<br>cn: Monitor<br>description: This subtree contains = monitoring/managing objects.<br> description: This object contains information about this server.<br>descrip= tion: Most of the information is held in operational attributes, which<br>?= must be explicitly requested.<br>monitoredInfo: OpenLDAP: slapd 2.4.16 (Jul= 23 2009 13:44:24)<br> <br>>>>>> Test succeeded<br>>>>>> ./scripts/t= est000-rootdse completed OK.<br><br>>>>>> Starting test001-s= lapadd ...<br>running defines.sh<br>Running slapadd to build slapd database= ...<br> <br>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>Then blocked, = and no moving any more ...<br><br></blockquote></div><br></div></div></div>= </div></blockquote></div><br> --0015175707f6684066046fb12f9b--

1 0

Re: (ITS#6229) make test blocked on test001-slapadd
by battery＠writeme.com 27 Jul '09

27 Jul '09

--000e0cd51bbc607056046fb112fc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit http://www.oracle.com/technology/products/berkeley-db/db/update/4.7.25/patc… Include the list in your reply next time... On Mon, Jul 27, 2009 at 8:44 AM, czybear <czybear(a)qq.com> wrote: > yes, I build aginst BDB 4.7.25 and downloaded from > http://www.oracle.com/technology/software/products/berkeley-db/htdocs/popup… > I didn't see any patches about BDB 4.7.25 from Oracle yet. > > > ------------------ Original ------------------ > *From: * "Matt Kassawara"<battery(a)writeme.com>; > *Date: * Mon, Jul 27, 2009 10:40 PM > *To: * "czybear"<czybear(a)qq.com>; > *Cc: * "openldap-its"<openldap-its(a)openldap.org>; > *Subject: * Re: (ITS#6229) make test blocked on test001-slapadd > > Did you build against BDB 4.7.25? ?If so, did you apply all the patches? On > Mon, Jul 27, 2009 at 3:04 AM, wrote: Full_Name: John Chen Version: > 2.4.16/2.4.17 OS: RHEL AS 5.2 (Tikanga) x86)64 URL: > ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (117.88.156.12) > [root@as5u2-64]# make test cd tests; make test make[1]: Entering directory > `/home/install/ldap-2.4/openldap-2.4.16/tests' make[2]: Entering directory > `/home/install/ldap-2.4/openldap-2.4.16/tests' Initiating LDAP tests for > BDB... Cleaning up test run directory leftover from previous run. Running > ./scripts/all... >>>>> Executing all LDAP tests for bdb >>>>> Starting > test000-rootdse ... running defines.sh Starting slapd on TCP/IP port 9011... > Using ldapsearch to retrieve the root DSE... Waiting 5 seconds for slapd to > start... Using ldapsearch to retrieve the cn=Subschema... Using ldapsearch > to retrieve the cn=Monitor... dn: objectClass: top objectClass: > OpenLDAProotDSE structuralObjectClass: OpenLDAProotDSE configContext: > cn=config namingContexts: o=OpenLDAP Project,l=Internet monitorContext: > cn=Monitor supportedControl: 1.3.6.1.4.1.4203.1.9.1.1 supportedControl: > 2.16.840.1.113730.3.4.18 supportedControl: 2.16.840.1.113730.3.4.2 > supportedControl: 1.3.6.1.4.1.4203.1.10.1 supportedControl: > 1.2.840.113556.1.4.319 supportedControl: 1.2.826.0.1.3344810.2.3 > supportedControl: 1.3.6.1.1.13.2 supportedControl: 1.3.6.1.1.13.1 > supportedControl: 1.3.6.1.1.12 supportedExtension: 1.3.6.1.4.1.4203.1.11.1 > supportedExtension: 1.3.6.1.4.1.4203.1.11.3 supportedExtension: 1.3.6.1.1.8 > supportedFeatures: 1.3.6.1.1.14 supportedFeatures: 1.3.6.1.4.1.4203.1.5.1 > supportedFeatures: 1.3.6.1.4.1.4203.1.5.2 supportedFeatures: > 1.3.6.1.4.1.4203.1.5.3 supportedFeatures: 1.3.6.1.4.1.4203.1.5.4 > supportedFeatures: 1.3.6.1.4.1.4203.1.5.5 supportedLDAPVersion: 3 > vendorName: The OpenLDAP Project entryDN: subschemaSubentry: cn=Subschema > dn: cn=Subschema objectClass: top objectClass: subentry objectClass: > subschema objectClass: extensibleObject cn: Subschema dn: cn=Monitor > objectClass: monitorServer cn: Monitor description: This subtree contains > monitoring/managing objects. description: This object contains information > about this server. description: Most of the information is held in > operational attributes, which ?must be explicitly requested. monitoredInfo: > OpenLDAP: slapd 2.4.16 (Jul 23 2009 13:44:24) >>>>> Test succeeded >>>>> > ./scripts/test000-rootdse completed OK. >>>>> Starting test001-slapadd ... > running defines.sh Running slapadd to build slapd database... > ========================================== Then blocked, and no moving any > more ... > --000e0cd51bbc607056046fb112fc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div><a href=3D"http://www.oracle.com/technology/products/berkeley-db/db/up= date/4.7.25/patch.4.7.25.html">http://www.oracle.com/technology/products/be= rkeley-db/db/update/4.7.25/patch.4.7.25.html</a><br></div><div></div><div> Include the list in your reply next time...</div><br><div class=3D"gmail_qu= ote">On Mon, Jul 27, 2009 at 8:44 AM, czybear <span dir=3D"ltr"><<a href= =3D"mailto:czybear@qq.com">czybear(a)qq.com</a>></span> wrote:<br><blockqu= ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s= olid;padding-left:1ex;"> <div>yes, I build aginst BDB 4.7.25 and downloaded from <a href=3D"http://w= ww.oracle.com/technology/software/products/berkeley-db/htdocs/popup/db/4.7.= 25/db-targz.html" target=3D"_blank">http://www.oracle.com/technology/softwa= re/products/berkeley-db/htdocs/popup/db/4.7.25/db-targz.html</a></div> <div>I didn't see any patches about BDB 4.7.25 from Oracle yet.</div> <div> <div>=A0</div> <div>=A0</div> <div style=3D"color:#000"> <div style=3D"padding-right:0px;padding-left:0px;font-size:12px;padding-bot= tom:2px;padding-top:2px;font-family:Arial Narrow">------------------=A0Orig= inal=A0------------------</div> <div style=3D"font-size:12px"> <div><b>From: </b>=A0"Matt Kassawara"<<a href=3D"mailto:batter= y(a)writeme.com" target=3D"_blank">battery(a)writeme.com</a>>;</div> <div><b>Date: </b>=A0Mon, Jul 27, 2009 10:40 PM</div> <div><b>To: </b>=A0"czybear"<<a href=3D"mailto:czybear@qq.com"= target=3D"_blank">czybear(a)qq.com</a>>; </div> <div><b>Cc: </b>=A0"openldap-its"<<a href=3D"mailto:openldap-i= ts(a)openldap.org" target=3D"_blank">openldap-its(a)openldap.org</a>>; </div= > <div><b>Subject: </b>=A0Re: (ITS#6229) make test blocked on test001-slapadd= </div></div> <div>=A0</div>Did you build against BDB 4.7.25? ?If so, did you apply all t= he patches? On Mon, Jul 27, 2009 at 3:04 AM, wrote: Full_Name: John Chen Ve= rsion: 2.4.16/2.4.17 OS: RHEL AS 5.2 (Tikanga) x86)64 URL: <a href=3D"ftp:/= /ftp.openldap.org/incoming/" target=3D"_blank">ftp://ftp.openldap.org/incom= ing/</a> Submission from: (NULL) (117.88.156.12) [root@as5u2-64]# make test= cd tests; make test make[1]: Entering directory `/home/install/ldap-2.4/op= enldap-2.4.16/tests' make[2]: Entering directory `/home/install/ldap-2.= 4/openldap-2.4.16/tests' Initiating LDAP tests for BDB... Cleaning up t= est run directory leftover from previous run. Running ./scripts/all... >= >>>> Executing all LDAP tests for bdb >>>>> Star= ting test000-rootdse ... running defines.sh Starting slapd on TCP/IP port 9= 011... Using ldapsearch to retrieve the root DSE... Waiting 5 seconds for s= lapd to start... Using ldapsearch to retrieve the cn=3DSubschema... Using l= dapsearch to retrieve the cn=3DMonitor... dn: objectClass: top objectClass:= OpenLDAProotDSE structuralObjectClass: OpenLDAProotDSE configContext: cn= =3Dconfig namingContexts: o=3DOpenLDAP Project,l=3DInternet monitorContext:= cn=3DMonitor supportedControl: 1.3.6.1.4.1.4203.1.9.1.1 supportedControl: = 2.16.840.1.113730.3.4.18 supportedControl: 2.16.840.1.113730.3.4.2 supporte= dControl: 1.3.6.1.4.1.4203.1.10.1 supportedControl: 1.2.840.113556.1.4.319 = supportedControl: 1.2.826.0.1.3344810.2.3 supportedControl: 1.3.6.1.1.13.2 = supportedControl: 1.3.6.1.1.13.1 supportedControl: 1.3.6.1.1.12 supportedEx= tension: 1.3.6.1.4.1.4203.1.11.1 supportedExtension: 1.3.6.1.4.1.4203.1.11.= 3 supportedExtension: 1.3.6.1.1.8 supportedFeatures: 1.3.6.1.1.14 supported= Features: 1.3.6.1.4.1.4203.1.5.1 supportedFeatures: 1.3.6.1.4.1.4203.1.5.2 = supportedFeatures: 1.3.6.1.4.1.4203.1.5.3 supportedFeatures: 1.3.6.1.4.1.42= 03.1.5.4 supportedFeatures: 1.3.6.1.4.1.4203.1.5.5 supportedLDAPVersion: 3 = vendorName: The OpenLDAP Project entryDN: subschemaSubentry: cn=3DSubschema= dn: cn=3DSubschema objectClass: top objectClass: subentry objectClass: sub= schema objectClass: extensibleObject cn: Subschema dn: cn=3DMonitor objectC= lass: monitorServer cn: Monitor description: This subtree contains monitori= ng/managing objects. description: This object contains information about th= is server. description: Most of the information is held in operational attr= ibutes, which ?must be explicitly requested. monitoredInfo: OpenLDAP: slapd= 2.4.16 (Jul 23 2009 13:44:24) >>>>> Test succeeded >>= >>> ./scripts/test000-rootdse completed OK. >>>>> S= tarting test001-slapadd ... running defines.sh Running slapadd to build sla= pd database... =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Then blo= cked, and no moving any more ... </div> </div></blockquote></div><br> --000e0cd51bbc607056046fb112fc--

1 0

Re: (ITS#6229) make test blocked on test001-slapadd
by battery＠writeme.com 27 Jul '09

27 Jul '09

--000e0cd2e7328a11aa046fb0ee75 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Did you build against BDB 4.7.25? If so, did you apply all the patches? On Mon, Jul 27, 2009 at 3:04 AM, <czybear(a)qq.com> wrote: > Full_Name: John Chen > Version: 2.4.16/2.4.17 > OS: RHEL AS 5.2 (Tikanga) x86)64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (117.88.156.12) > > > [root@as5u2-64]# make test > cd tests; make test > make[1]: Entering directory `/home/install/ldap-2.4/openldap-2.4.16/tests' > make[2]: Entering directory `/home/install/ldap-2.4/openldap-2.4.16/tests' > Initiating LDAP tests for BDB... > Cleaning up test run directory leftover from previous run. > Running ./scripts/all... > >>>>> Executing all LDAP tests for bdb > >>>>> Starting test000-rootdse ... > running defines.sh > Starting slapd on TCP/IP port 9011... > Using ldapsearch to retrieve the root DSE... > Waiting 5 seconds for slapd to start... > Using ldapsearch to retrieve the cn=Subschema... > Using ldapsearch to retrieve the cn=Monitor... > dn: > objectClass: top > objectClass: OpenLDAProotDSE > structuralObjectClass: OpenLDAProotDSE > configContext: cn=config > namingContexts: o=OpenLDAP Project,l=Internet > monitorContext: cn=Monitor > supportedControl: 1.3.6.1.4.1.4203.1.9.1.1 > supportedControl: 2.16.840.1.113730.3.4.18 > supportedControl: 2.16.840.1.113730.3.4.2 > supportedControl: 1.3.6.1.4.1.4203.1.10.1 > supportedControl: 1.2.840.113556.1.4.319 > supportedControl: 1.2.826.0.1.3344810.2.3 > supportedControl: 1.3.6.1.1.13.2 > supportedControl: 1.3.6.1.1.13.1 > supportedControl: 1.3.6.1.1.12 > supportedExtension: 1.3.6.1.4.1.4203.1.11.1 > supportedExtension: 1.3.6.1.4.1.4203.1.11.3 > supportedExtension: 1.3.6.1.1.8 > supportedFeatures: 1.3.6.1.1.14 > supportedFeatures: 1.3.6.1.4.1.4203.1.5.1 > supportedFeatures: 1.3.6.1.4.1.4203.1.5.2 > supportedFeatures: 1.3.6.1.4.1.4203.1.5.3 > supportedFeatures: 1.3.6.1.4.1.4203.1.5.4 > supportedFeatures: 1.3.6.1.4.1.4203.1.5.5 > supportedLDAPVersion: 3 > vendorName: The OpenLDAP Project <http://www.openldap.org/> > entryDN: > subschemaSubentry: cn=Subschema > > dn: cn=Subschema > objectClass: top > objectClass: subentry > objectClass: subschema > objectClass: extensibleObject > cn: Subschema > > dn: cn=Monitor > objectClass: monitorServer > cn: Monitor > description: This subtree contains monitoring/managing objects. > description: This object contains information about this server. > description: Most of the information is held in operational attributes, > which > must be explicitly requested. > monitoredInfo: OpenLDAP: slapd 2.4.16 (Jul 23 2009 13:44:24) > > >>>>> Test succeeded > >>>>> ./scripts/test000-rootdse completed OK. > > >>>>> Starting test001-slapadd ... > running defines.sh > Running slapadd to build slapd database... > > ========================================== > Then blocked, and no moving any more ... > > --000e0cd2e7328a11aa046fb0ee75 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Did you build against BDB 4.7.25? =A0If so, did you apply all the patches?<= br><br><div class=3D"gmail_quote">On Mon, Jul 27, 2009 at 3:04 AM, <span d= ir=3D"ltr"><<a href=3D"mailto:czybear@qq.com">czybear(a)qq.com</a>></sp= an> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;">Full_Name: John Chen<br> Version: 2.4.16/2.4.17<br> OS: RHEL AS 5.2 (Tikanga) x86)64<br> URL: <a href=3D"ftp://ftp.openldap.org/incoming/" target=3D"_blank">ftp://f= tp.openldap.org/incoming/</a><br> Submission from: (NULL) (117.88.156.12)<br> <br> <br> [root@as5u2-64]# make test<br> cd tests; make test<br> make[1]: Entering directory `/home/install/ldap-2.4/openldap-2.4.16/tests&#= 39;<br> make[2]: Entering directory `/home/install/ldap-2.4/openldap-2.4.16/tests&#= 39;<br> Initiating LDAP tests for BDB...<br> Cleaning up test run directory leftover from previous run.<br> Running ./scripts/all...<br> >>>>> Executing all LDAP tests for bdb<br> >>>>> Starting test000-rootdse ...<br> running defines.sh<br> Starting slapd on TCP/IP port 9011...<br> Using ldapsearch to retrieve the root DSE...<br> Waiting 5 seconds for slapd to start...<br> Using ldapsearch to retrieve the cn=3DSubschema...<br> Using ldapsearch to retrieve the cn=3DMonitor...<br> dn:<br> objectClass: top<br> objectClass: OpenLDAProotDSE<br> structuralObjectClass: OpenLDAProotDSE<br> configContext: cn=3Dconfig<br> namingContexts: o=3DOpenLDAP Project,l=3DInternet<br> monitorContext: cn=3DMonitor<br> supportedControl: 1.3.6.1.4.1.4203.1.9.1.1<br> supportedControl: 2.16.840.1.113730.3.4.18<br> supportedControl: 2.16.840.1.113730.3.4.2<br> supportedControl: 1.3.6.1.4.1.4203.1.10.1<br> supportedControl: 1.2.840.113556.1.4.319<br> supportedControl: 1.2.826.0.1.3344810.2.3<br> supportedControl: 1.3.6.1.1.13.2<br> supportedControl: 1.3.6.1.1.13.1<br> supportedControl: 1.3.6.1.1.12<br> supportedExtension: 1.3.6.1.4.1.4203.1.11.1<br> supportedExtension: 1.3.6.1.4.1.4203.1.11.3<br> supportedExtension: 1.3.6.1.1.8<br> supportedFeatures: 1.3.6.1.1.14<br> supportedFeatures: 1.3.6.1.4.1.4203.1.5.1<br> supportedFeatures: 1.3.6.1.4.1.4203.1.5.2<br> supportedFeatures: 1.3.6.1.4.1.4203.1.5.3<br> supportedFeatures: 1.3.6.1.4.1.4203.1.5.4<br> supportedFeatures: 1.3.6.1.4.1.4203.1.5.5<br> supportedLDAPVersion: 3<br> vendorName: The OpenLDAP Project <<a href=3D"http://www.openldap.org/" t= arget=3D"_blank">http://www.openldap.org/</a>><br> entryDN:<br> subschemaSubentry: cn=3DSubschema<br> <br> dn: cn=3DSubschema<br> objectClass: top<br> objectClass: subentry<br> objectClass: subschema<br> objectClass: extensibleObject<br> cn: Subschema<br> <br> dn: cn=3DMonitor<br> objectClass: monitorServer<br> cn: Monitor<br> description: This subtree contains monitoring/managing objects.<br> description: This object contains information about this server.<br> description: Most of the information is held in operational attributes, whi= ch<br> =A0must be explicitly requested.<br> monitoredInfo: OpenLDAP: slapd 2.4.16 (Jul 23 2009 13:44:24)<br> <br> >>>>> Test succeeded<br> >>>>> ./scripts/test000-rootdse completed OK.<br> <br> >>>>> Starting test001-slapadd ...<br> running defines.sh<br> Running slapadd to build slapd database...<br> <br> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br> Then blocked, and no moving any more ...<br> <br> </blockquote></div><br> --000e0cd2e7328a11aa046fb0ee75--

1 0

(ITS#6229) make test blocked on test001-slapadd
by czybear＠qq.com 27 Jul '09

27 Jul '09

Full_Name: John Chen Version: 2.4.16/2.4.17 OS: RHEL AS 5.2 (Tikanga) x86)64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (117.88.156.12) [root@as5u2-64]# make test cd tests; make test make[1]: Entering directory `/home/install/ldap-2.4/openldap-2.4.16/tests' make[2]: Entering directory `/home/install/ldap-2.4/openldap-2.4.16/tests' Initiating LDAP tests for BDB... Cleaning up test run directory leftover from previous run. Running ./scripts/all... >>>>> Executing all LDAP tests for bdb >>>>> Starting test000-rootdse ... running defines.sh Starting slapd on TCP/IP port 9011... Using ldapsearch to retrieve the root DSE... Waiting 5 seconds for slapd to start... Using ldapsearch to retrieve the cn=Subschema... Using ldapsearch to retrieve the cn=Monitor... dn: objectClass: top objectClass: OpenLDAProotDSE structuralObjectClass: OpenLDAProotDSE configContext: cn=config namingContexts: o=OpenLDAP Project,l=Internet monitorContext: cn=Monitor supportedControl: 1.3.6.1.4.1.4203.1.9.1.1 supportedControl: 2.16.840.1.113730.3.4.18 supportedControl: 2.16.840.1.113730.3.4.2 supportedControl: 1.3.6.1.4.1.4203.1.10.1 supportedControl: 1.2.840.113556.1.4.319 supportedControl: 1.2.826.0.1.3344810.2.3 supportedControl: 1.3.6.1.1.13.2 supportedControl: 1.3.6.1.1.13.1 supportedControl: 1.3.6.1.1.12 supportedExtension: 1.3.6.1.4.1.4203.1.11.1 supportedExtension: 1.3.6.1.4.1.4203.1.11.3 supportedExtension: 1.3.6.1.1.8 supportedFeatures: 1.3.6.1.1.14 supportedFeatures: 1.3.6.1.4.1.4203.1.5.1 supportedFeatures: 1.3.6.1.4.1.4203.1.5.2 supportedFeatures: 1.3.6.1.4.1.4203.1.5.3 supportedFeatures: 1.3.6.1.4.1.4203.1.5.4 supportedFeatures: 1.3.6.1.4.1.4203.1.5.5 supportedLDAPVersion: 3 vendorName: The OpenLDAP Project <http://www.openldap.org/> entryDN: subschemaSubentry: cn=Subschema dn: cn=Subschema objectClass: top objectClass: subentry objectClass: subschema objectClass: extensibleObject cn: Subschema dn: cn=Monitor objectClass: monitorServer cn: Monitor description: This subtree contains monitoring/managing objects. description: This object contains information about this server. description: Most of the information is held in operational attributes, which must be explicitly requested. monitoredInfo: OpenLDAP: slapd 2.4.16 (Jul 23 2009 13:44:24) >>>>> Test succeeded >>>>> ./scripts/test000-rootdse completed OK. >>>>> Starting test001-slapadd ... running defines.sh Running slapadd to build slapd database... ========================================== Then blocked, and no moving any more ...

1 0

Re: (ITS#6228) test000-rootdse: slapd fails to start
by hyc＠symas.com 25 Jul '09

25 Jul '09

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: HEAD > OS: openSUSE Linux 11.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.163.115.191) > > > HEAD synced right now fails right in test000. Thanks, fixed. > > ----------- console output ----------- > > michael@nb2:/usr/src/michael/openldap/HEAD/openldap> make test > cd tests; make test > make[1]: Entering directory `/usr/src/michael/openldap/HEAD/openldap/tests' > make[2]: Entering directory `/usr/src/michael/openldap/HEAD/openldap/tests' > Initiating LDAP tests for BDB... > Cleaning up test run directory leftover from previous run. > Running ./scripts/all for bdb... >>>>>> Executing all LDAP tests for bdb >>>>>> Starting test000-rootdse for bdb... > running defines.sh > Starting slapd on TCP/IP port 9011... > Using ldapsearch to retrieve the root DSE... > Waiting 5 seconds for slapd to start... > Waiting 5 seconds for slapd to start... > Waiting 5 seconds for slapd to start... > Waiting 5 seconds for slapd to start... > Waiting 5 seconds for slapd to start... > Waiting 5 seconds for slapd to start... > ./scripts/test000-rootdse: line 66: kill: (2749) - No such process > ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) >>>>>> Test failed >>>>>> ./scripts/test000-rootdse failed for bdb (exit 255) > make[2]: *** [bdb-mod] Error 255 > make[2]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' > make[1]: *** [test] Error 2 > make[1]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' > make: *** [test] Error 2 > > ----------- last lines of tests/testrun/slapd.1.log ----------- > > backend_startup_one: starting "cn=config" > config_back_db_open > config_build_entry: "cn=config" > config_build_entry: "cn=module{0}" > config_build_entry: "cn=module{1}" > config_build_entry: "cn=schema" > config_build_entry: "cn={0}core" > config_build_entry: "cn={1}cosine" > config_build_entry: "cn={2}corba" > config_build_entry: "cn={3}java" > config_build_entry: "cn={4}inetorgperson" > config_build_entry: "cn={5}misc" > config_build_entry: "cn={6}nis" > config_build_entry: "cn={7}openldap" > config_build_entry: "cn={8}duaconf" > config_build_entry: "cn={9}dyngroup" > config_build_entry: "cn={10}ppolicy" > config_build_entry: "olcDatabase={-1}frontend" > config_build_entry: "olcDatabase={0}config" > config_build_entry: "olcDatabase={1}bdb" > config_build_attrs: error 21 on olcDbCacheSize value #0 > config_build_entry: build "1000d" failed: "" > backend_startup_one: bi_db_open failed! (-1) > lt-slapd shutdown: initiated > ====> bdb_cache_release_all > lt-slapd destroy: freeing system resources. > slapd stopped. > > -- -- 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

(ITS#6228) test000-rootdse: slapd fails to start
by michael＠stroeder.com 25 Jul '09

25 Jul '09

Full_Name: Michael Ströder Version: HEAD OS: openSUSE Linux 11.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.115.191) HEAD synced right now fails right in test000. ----------- console output ----------- michael@nb2:/usr/src/michael/openldap/HEAD/openldap> make test cd tests; make test make[1]: Entering directory `/usr/src/michael/openldap/HEAD/openldap/tests' make[2]: Entering directory `/usr/src/michael/openldap/HEAD/openldap/tests' Initiating LDAP tests for BDB... Cleaning up test run directory leftover from previous run. Running ./scripts/all for bdb... >>>>> Executing all LDAP tests for bdb >>>>> Starting test000-rootdse for bdb... running defines.sh Starting slapd on TCP/IP port 9011... Using ldapsearch to retrieve the root DSE... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... ./scripts/test000-rootdse: line 66: kill: (2749) - No such process ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) >>>>> Test failed >>>>> ./scripts/test000-rootdse failed for bdb (exit 255) make[2]: *** [bdb-mod] Error 255 make[2]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' make: *** [test] Error 2 ----------- last lines of tests/testrun/slapd.1.log ----------- backend_startup_one: starting "cn=config" config_back_db_open config_build_entry: "cn=config" config_build_entry: "cn=module{0}" config_build_entry: "cn=module{1}" config_build_entry: "cn=schema" config_build_entry: "cn={0}core" config_build_entry: "cn={1}cosine" config_build_entry: "cn={2}corba" config_build_entry: "cn={3}java" config_build_entry: "cn={4}inetorgperson" config_build_entry: "cn={5}misc" config_build_entry: "cn={6}nis" config_build_entry: "cn={7}openldap" config_build_entry: "cn={8}duaconf" config_build_entry: "cn={9}dyngroup" config_build_entry: "cn={10}ppolicy" config_build_entry: "olcDatabase={-1}frontend" config_build_entry: "olcDatabase={0}config" config_build_entry: "olcDatabase={1}bdb" config_build_attrs: error 21 on olcDbCacheSize value #0 config_build_entry: build "1000d" failed: "" backend_startup_one: bi_db_open failed! (-1) lt-slapd shutdown: initiated ====> bdb_cache_release_all lt-slapd destroy: freeing system resources. slapd stopped.

1 0

Re: (ITS#6223) [patch] snprint() fix in guess_service_principal()
by jerry＠plainjoe.org 25 Jul '09

25 Jul '09

This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB83678E9A284CB48B3D6C2FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Howard Chu wrote: > jerry(a)plainjoe.org wrote: >> Correction to the URL. Should be: >> ftp://ftp.openldap.org/incoming/openldap-2.4.16-guess_service_principa= l.diff >> >=20 > That file is zero bytes long. Did we run out of space on > ftp.openldap.org again? Howard, I've got update patches (more bug fixes related to the gssapi bind). I'll try uploading a new patch on Monday. cheers, jerry --------------enigB83678E9A284CB48B3D6C2FB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKawDfIR7qMdg1EfYRAt3iAKChKPg7VCwWuqevthDTvlcELJdTPgCg8pNq AIp/ts+OeQ2gfB4AlwehEAY= =RhWQ -----END PGP SIGNATURE----- --------------enigB83678E9A284CB48B3D6C2FB--

1 0

Re: ITS#6226
by test.007＠seznam.cz 25 Jul '09

25 Jul '09

Probably dup, sorry, I should have checked.

1 0

Re: (ITS#6222) Add "unlimited" option for cachesize settings
by hyc＠symas.com 25 Jul '09

25 Jul '09

quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.17 > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > Now that we have multiple cache sizes, it would be extremely useful, > particularly with dncachesize, to be able to specify an "unlimited" setting, so > that the 2.3 behavior can be easily replicated. Also so that people who have > systems with plenty of RAM can just set it once. Yeah, I guess it was kind of a bad idea to make the default 2.4 behavior differ from 2.3 here. Fixed in HEAD. > In particular, I've noticed in 2.3->2.4 upgrades, if dncachesize is particularly > small in relation to the size of the database, slapd is essentially unusable. > I'd rather see dncachesize default to unlimited if it isn't set (2.3 behavior), > and people can tune it down from there if they need to do so. This allows slapd > to remain usable without severely impacting the ability of slapd to function. > It is so bad, that it becomes impossible to modify cn=config via ldap commands, > and you have to stop slapd and manually hack the cn=config text files to return > slapd to a usable state. > -- -- 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#6225) GSSAPI support for client library (fixes)
by hyc＠symas.com 25 Jul '09

25 Jul '09

mimir(a)samba.org wrote: > Full_Name: Rafal Szczesniak > Version: Stable (2.4.16) > OS: GNU/Linux > URL: http://www.samba.org/~mimir/gssapi-bugfix.diff > Submission from: (NULL) (67.51.54.234) > > > This is a bugfix patch for OpenLDAP's gssapi support. > One of these patches appears to duplicate ITS#6092. As the original author of this code, could you also take a look at #6091 and #6093? -- -- 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#6223) [patch] snprint() fix in guess_service_principal()
by hyc＠symas.com 25 Jul '09

25 Jul '09

jerry(a)plainjoe.org wrote: > Correction to the URL. Should be: > ftp://ftp.openldap.org/incoming/openldap-2.4.16-guess_service_principal.diff That file is zero bytes long. Did we run out of space on ftp.openldap.org again? -- -- 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#6221) slapd segfault in SSL_CTX_set_info_callback
by steve＠falchion.com 24 Jul '09

24 Jul '09

Thanks for the encouragement Michael :) For those who find this in searches to come, I compiled OpenSSL (0.9.8k) myself and the problem is resolved. Not sure if this is a bug fixed between 0.9.8h and 0.9.8k or something weird that IBM did when building the package, but all is well now. Steve=20 On Fri, 2009-07-24 at 13:24 +0200, Michael Str=C3=B6der wrote: > steve(a)falchion.com wrote: > > Now you might tell me (as you've already implied) to compile my own SSL > > libraries, >=20 > Being in your situation I'd try that. >=20 > > which I may try, but doing so opens me up to a world of > > interop issues as IBM tends to compile their tools with links to > > specific versions of shared libraries (I've been there and done that in > > AIX this year once already). >=20 > You could build all the necessary libs (Berkeley DB, OpenSSL, > cyrus-sasl, heimdal etc.) and install them in a separate prefix without > conflicting with any pre-installed libs. I'd go that route and did that > on e.g. old Solaris platforms. And I think it would be feasible for me > even though I'm not an C programmer. >=20 > > Do I sound frustrated yet? Cause I am... >=20 > Sometimes things are hard. But just don't give up! >=20 > Ciao, Michael.

1 0

Re: (ITS#6227) autogroup overlay breaks all searches
by hyc＠symas.com 24 Jul '09

24 Jul '09

Fixed now in CVS HEAD. mbuschman(a)cashnetusa.com wrote: > Full_Name: Marshall Buschman > Version: 2.4.17 > OS: Debian Etch > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (38.98.177.132) > > I'm using OpenLDAP 2.4.17 with bdb 4.7 Debian Lenny. I've enabled the > autogroup overlay, and I get the following error when I do an ldapsearch: > > $ ldapsearch -x -H "ldap://ldapserver" -b dc=cashnetusa,dc=com > # extended LDIF > ... > # search result > search: 2 > result: 53 Server is unwilling to perform > text: operation not supported within namingContext > > Relevant config: > ---------------------------------------------- > moduleload autogroup > > database bdb > suffix "dc=cashnetusa,dc=com" > > overlay autogroup > autogroup-attrset groupOfURLs memberURL member > ---------------------------------------------- > > OpenLDAP does start normally without the overlay. > -- -- 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#6227) autogroup overlay breaks all searches
by mbuschman＠cashnetusa.com 24 Jul '09

24 Jul '09

OS is Debian Lenny, not Debian Etch. Apologies. openldap-its(a)OpenLDAP.org wrote: > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** > > Thanks for your report to the OpenLDAP Issue Tracking System. Your > report has been assigned the tracking number ITS#6227. > > One of our support engineers will look at your report in due course. > Note that this may take some time because our support engineers > are volunteers. They only work on OpenLDAP when they have spare > time. > > If you need to provide additional information in regards to your > issue report, you may do so by replying to this message. Note that > any mail sent to openldap-its(a)openldap.org with (ITS#6227) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=(ITS#6227) > > You may follow the progress of this report by loading the following > URL in a web browser: > http://www.OpenLDAP.org/its/index.cgi?findid=6227 > > Please remember to retain your issue tracking number (ITS#6227) > on any further messages you send to us regarding this report. If > you don't then you'll just waste our time and yours because we > won't be able to properly track the report. > > Please note that the Issue Tracking System is not intended to > be used to seek help in the proper use of OpenLDAP Software. > Such requests will be closed. > > OpenLDAP Software is user supported. > http://www.OpenLDAP.org/support/ > > -------------- > Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. > >

1 0

(ITS#6227) autogroup overlay breaks all searches
by mbuschman＠cashnetusa.com 24 Jul '09

24 Jul '09

Full_Name: Marshall Buschman Version: 2.4.17 OS: Debian Etch URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (38.98.177.132) I'm using OpenLDAP 2.4.17 with bdb 4.7 Debian Lenny. I've enabled the autogroup overlay, and I get the following error when I do an ldapsearch: $ ldapsearch -x -H "ldap://ldapserver" -b dc=cashnetusa,dc=com # extended LDIF ... # search result search: 2 result: 53 Server is unwilling to perform text: operation not supported within namingContext Relevant config: ---------------------------------------------- moduleload autogroup database bdb suffix "dc=cashnetusa,dc=com" overlay autogroup autogroup-attrset groupOfURLs memberURL member ---------------------------------------------- OpenLDAP does start normally without the overlay.

1 0

Re: (ITS#6221) slapd segfault in SSL_CTX_set_info_callback
by michael＠stroeder.com 24 Jul '09

24 Jul '09

steve(a)falchion.com wrote: > Now you might tell me (as you've already implied) to compile my own SSL > libraries, Being in your situation I'd try that. > which I may try, but doing so opens me up to a world of > interop issues as IBM tends to compile their tools with links to > specific versions of shared libraries (I've been there and done that in > AIX this year once already). You could build all the necessary libs (Berkeley DB, OpenSSL, cyrus-sasl, heimdal etc.) and install them in a separate prefix without conflicting with any pre-installed libs. I'd go that route and did that on e.g. old Solaris platforms. And I think it would be feasible for me even though I'm not an C programmer. > Do I sound frustrated yet? Cause I am... Sometimes things are hard. But just don't give up! Ciao, Michael.

1 0

Re: (ITS#6221) slapd segfault in SSL_CTX_set_info_callback
by steve＠falchion.com 24 Jul '09

24 Jul '09

Thank-you, that is much more helpful. I apologize for my rant. I'll join that mailing list and post my issue there. Thanks, Steve On Thu, 2009-07-23 at 15:23 -0700, Howard Chu wrote: > Steve Paras-Charlton wrote: > > Thanks, that was sooo helpful. > > > > What I'm trying to do is port your software package to a platform where > > it obviously fails to work properly using the vendor's supplied SSL > > libraries, and you're giving me a PFO. > > The ITS is for tracking problems in the actual OpenLDAP code base. Since > you're not reporting an actual issue in OpenLDAP code, this is the wrong forum > for this discussion. > > You can get help on interoperability issues elsewhere, e.g. the > openldap-technical mailing list. > > > So now I get to go to IBM and say "your library is broken but I can't > > tell you how/why" (gee... I wonder how that call will go) or abandon > > open source and install their LDAP server package (which is what they'll > > tell me to do anyhow). > > > > Now you might tell me (as you've already implied) to compile my own SSL > > libraries, which I may try, but doing so opens me up to a world of > > interop issues as IBM tends to compile their tools with links to > > specific versions of shared libraries (I've been there and done that in > > AIX this year once already). > > > Do I sound frustrated yet? Cause I am... > > > > Sorry to anyone else who reads this rant. > > You obviously have to ask the right questions to the right people who can > actually help you. We can't fix your OpenSSL build for you. > > > > Steve > > > > On Thu, 2009-07-23 at 14:15 -0700, Howard Chu wrote: > >> Steve Paras-Charlton wrote: > >>> > >>> I tried re-compiling with CC="gcc -g" and got the following backtrace > >>> from gdb: > >>> > >>> Program received signal SIGSEGV, Segmentation fault. > >>> [Switching to Thread 1] > >>> 0xd26d07d0 in SSL_CTX_set_info_callback () > >>> > >>> from /LDAP/build/openldap-2.4.16/libraries/libldap_r/.libs/libldap_r.a(libldap_r-2.4.so.2) > >>> (gdb) bt > >>> #0 0xd26d07d0 in SSL_CTX_set_info_callback () > >>> > >>> from /LDAP/build/openldap-2.4.16/libraries/libldap_r/.libs/libldap_r.a(libldap_r-2.4.so.2) > >>> #1 0xd26cdedc in tlso_ctx_init (lo=0x200c087c, lt=0x2ff22970, > >>> is_server=1) at tls_o.c:320 > >>> #2 0xd26ca50c in ldap_int_tls_init_ctx (lo=0x200c087c, is_server=1) at > >>> tls2.c:245 > >>> #3 0xd26cc1cc in ldap_pvt_tls_set_option (ld=0x200c0878, option=24591, > >>> arg=0x2ff22ae8) at tls2.c:800 > >>> #4 0x10001f90 in main (argc=9, argv=0x2ff22b94) at main.c:826 > >>> > >>> This one seems much more useful from a debugging perspective. > >>> > >>> I noticed that the configure program has some options along the lines of > >>> "--with-PIC" which defaults to "both PIC and non-PIC". Could I use this > >>> to help debug the issue perhaps? How would I use it (not sure what > >>> options it takes). > >> > >> This trace is the kind that we would normally look for, yes. But the crash is > >> in an OpenSSL function, and you haven't got debug symbols for that since you > >> haven't recompiled that yet. Anyway, it still has nothing to do with OpenLDAP, > >> your OpenSSL library is broken. Since this is not an OpenLDAP bug this ITS > >> will be closed. > >> > > > > > >

1 0

2.4.17 - autogroup overlay breaks searches
by Marshall Buschman 24 Jul '09

24 Jul '09

Hello All: I'm running OpenLDAP 2.4.17+bdb 4.7 on Debian Lenny. I've enabled the autogroup overlay, and I get the following when I do an ldapsearch. Disabling the overlay does fix the issue, but I do need the functionality the overlay provides. $ ldapsearch -x -H "ldap://ldapserver" -b dc=cashnetusa,dc=com # extended LDIF ... # search result search: 2 result: 53 Server is unwilling to perform text: operation not supported within namingContext Relevant config: ---------------------------------------------- moduleload autogroup database bdb suffix "dc=cashnetusa,dc=com" overlay autogroup autogroup-attrset posixGroup memberURL member ---------------------------------------------- Help? -Marshall Buschman

2 1

Re: (ITS#6200)
by hyc＠symas.com 24 Jul '09

24 Jul '09

imf(a)u.washington.edu wrote: > The changes made to 2.4.17 seem to have fixed the crashes in the caching > module. Thanks for that. > > We still are able to crash 2.4.17, however. It only happens after a heavy > load is placed on the producer for>24 hours continuous. Unfortunately, > we've not been able to get good tracebacks. They all look like this, > > (gdb) where > #0 0x00869410 in __kernel_vsyscall () > #1 0x00390d80 in raise () from /lib/libc.so.6 > #2 0x00392691 in abort () from /lib/libc.so.6 > #3 0x0038a1fb in __assert_fail () from /lib/libc.so.6 > #4 0x0808d532 in malloc () > #5 0x0822c93f in ?? () > #6 0x0822c933 in ?? () > #7 0x00000039 in ?? () > #8 0x0822c908 in ?? () > #9 0x00000000 in ?? () > > The producer slowly grows its memory footprint. I can't tell if it's from > just normal operations or memory leaks. I suspect it's a little of both. > The end result, as you can see from the core above, is that there's likely > some corrupted (or unfreed) memory somewhere. Sorry I can't nail it down > further. There's not enough information here. An assert is always accompanied by an error message on stderr; we need to see the actual error message. There are no symbols in the stack trace pertaining to slapd itself. You seem to be running a stripped binary. Please provide a trace using a non-stripped binary that was compiled with -g (debug symbols enabled). > > The load profile that we placed on the server is documented in my prior > report. See above. -- -- 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#6221) slapd segfault in SSL_CTX_set_info_callback
by hyc＠symas.com 24 Jul '09

24 Jul '09

Steve Paras-Charlton wrote: > Thanks, that was sooo helpful. > > What I'm trying to do is port your software package to a platform where > it obviously fails to work properly using the vendor's supplied SSL > libraries, and you're giving me a PFO. The ITS is for tracking problems in the actual OpenLDAP code base. Since you're not reporting an actual issue in OpenLDAP code, this is the wrong forum for this discussion. You can get help on interoperability issues elsewhere, e.g. the openldap-technical mailing list. > So now I get to go to IBM and say "your library is broken but I can't > tell you how/why" (gee... I wonder how that call will go) or abandon > open source and install their LDAP server package (which is what they'll > tell me to do anyhow). > > Now you might tell me (as you've already implied) to compile my own SSL > libraries, which I may try, but doing so opens me up to a world of > interop issues as IBM tends to compile their tools with links to > specific versions of shared libraries (I've been there and done that in > AIX this year once already). > Do I sound frustrated yet? Cause I am... > > Sorry to anyone else who reads this rant. You obviously have to ask the right questions to the right people who can actually help you. We can't fix your OpenSSL build for you. > > Steve > > On Thu, 2009-07-23 at 14:15 -0700, Howard Chu wrote: >> Steve Paras-Charlton wrote: >>> >>> I tried re-compiling with CC="gcc -g" and got the following backtrace >>> from gdb: >>> >>> Program received signal SIGSEGV, Segmentation fault. >>> [Switching to Thread 1] >>> 0xd26d07d0 in SSL_CTX_set_info_callback () >>> >>> from /LDAP/build/openldap-2.4.16/libraries/libldap_r/.libs/libldap_r.a(libldap_r-2.4.so.2) >>> (gdb) bt >>> #0 0xd26d07d0 in SSL_CTX_set_info_callback () >>> >>> from /LDAP/build/openldap-2.4.16/libraries/libldap_r/.libs/libldap_r.a(libldap_r-2.4.so.2) >>> #1 0xd26cdedc in tlso_ctx_init (lo=0x200c087c, lt=0x2ff22970, >>> is_server=1) at tls_o.c:320 >>> #2 0xd26ca50c in ldap_int_tls_init_ctx (lo=0x200c087c, is_server=1) at >>> tls2.c:245 >>> #3 0xd26cc1cc in ldap_pvt_tls_set_option (ld=0x200c0878, option=24591, >>> arg=0x2ff22ae8) at tls2.c:800 >>> #4 0x10001f90 in main (argc=9, argv=0x2ff22b94) at main.c:826 >>> >>> This one seems much more useful from a debugging perspective. >>> >>> I noticed that the configure program has some options along the lines of >>> "--with-PIC" which defaults to "both PIC and non-PIC". Could I use this >>> to help debug the issue perhaps? How would I use it (not sure what >>> options it takes). >> >> This trace is the kind that we would normally look for, yes. But the crash is >> in an OpenSSL function, and you haven't got debug symbols for that since you >> haven't recompiled that yet. Anyway, it still has nothing to do with OpenLDAP, >> your OpenSSL library is broken. Since this is not an OpenLDAP bug this ITS >> will be closed. >> > > -- -- 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#6221) slapd segfault in SSL_CTX_set_info_callback
by steve＠falchion.com 23 Jul '09

23 Jul '09

Thanks, that was sooo helpful. What I'm trying to do is port your software package to a platform where it obviously fails to work properly using the vendor's supplied SSL libraries, and you're giving me a PFO. So now I get to go to IBM and say "your library is broken but I can't tell you how/why" (gee... I wonder how that call will go) or abandon open source and install their LDAP server package (which is what they'll tell me to do anyhow). Now you might tell me (as you've already implied) to compile my own SSL libraries, which I may try, but doing so opens me up to a world of interop issues as IBM tends to compile their tools with links to specific versions of shared libraries (I've been there and done that in AIX this year once already). Do I sound frustrated yet? Cause I am... Sorry to anyone else who reads this rant. Steve On Thu, 2009-07-23 at 14:15 -0700, Howard Chu wrote: > Steve Paras-Charlton wrote: > > > > I tried re-compiling with CC="gcc -g" and got the following backtrace > > from gdb: > > > > Program received signal SIGSEGV, Segmentation fault. > > [Switching to Thread 1] > > 0xd26d07d0 in SSL_CTX_set_info_callback () > > > > from /LDAP/build/openldap-2.4.16/libraries/libldap_r/.libs/libldap_r.a(libldap_r-2.4.so.2) > > (gdb) bt > > #0 0xd26d07d0 in SSL_CTX_set_info_callback () > > > > from /LDAP/build/openldap-2.4.16/libraries/libldap_r/.libs/libldap_r.a(libldap_r-2.4.so.2) > > #1 0xd26cdedc in tlso_ctx_init (lo=0x200c087c, lt=0x2ff22970, > > is_server=1) at tls_o.c:320 > > #2 0xd26ca50c in ldap_int_tls_init_ctx (lo=0x200c087c, is_server=1) at > > tls2.c:245 > > #3 0xd26cc1cc in ldap_pvt_tls_set_option (ld=0x200c0878, option=24591, > > arg=0x2ff22ae8) at tls2.c:800 > > #4 0x10001f90 in main (argc=9, argv=0x2ff22b94) at main.c:826 > > > > This one seems much more useful from a debugging perspective. > > > > I noticed that the configure program has some options along the lines of > > "--with-PIC" which defaults to "both PIC and non-PIC". Could I use this > > to help debug the issue perhaps? How would I use it (not sure what > > options it takes). > > This trace is the kind that we would normally look for, yes. But the crash is > in an OpenSSL function, and you haven't got debug symbols for that since you > haven't recompiled that yet. Anyway, it still has nothing to do with OpenLDAP, > your OpenSSL library is broken. Since this is not an OpenLDAP bug this ITS > will be closed. >

1 0

Re: (ITS#6221) slapd segfault in SSL_CTX_set_info_callback
by hyc＠symas.com 23 Jul '09

23 Jul '09

Steve Paras-Charlton wrote: > > I tried re-compiling with CC="gcc -g" and got the following backtrace > from gdb: > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 1] > 0xd26d07d0 in SSL_CTX_set_info_callback () > > from /LDAP/build/openldap-2.4.16/libraries/libldap_r/.libs/libldap_r.a(libldap_r-2.4.so.2) > (gdb) bt > #0 0xd26d07d0 in SSL_CTX_set_info_callback () > > from /LDAP/build/openldap-2.4.16/libraries/libldap_r/.libs/libldap_r.a(libldap_r-2.4.so.2) > #1 0xd26cdedc in tlso_ctx_init (lo=0x200c087c, lt=0x2ff22970, > is_server=1) at tls_o.c:320 > #2 0xd26ca50c in ldap_int_tls_init_ctx (lo=0x200c087c, is_server=1) at > tls2.c:245 > #3 0xd26cc1cc in ldap_pvt_tls_set_option (ld=0x200c0878, option=24591, > arg=0x2ff22ae8) at tls2.c:800 > #4 0x10001f90 in main (argc=9, argv=0x2ff22b94) at main.c:826 > > This one seems much more useful from a debugging perspective. > > I noticed that the configure program has some options along the lines of > "--with-PIC" which defaults to "both PIC and non-PIC". Could I use this > to help debug the issue perhaps? How would I use it (not sure what > options it takes). This trace is the kind that we would normally look for, yes. But the crash is in an OpenSSL function, and you haven't got debug symbols for that since you haven't recompiled that yet. Anyway, it still has nothing to do with OpenLDAP, your OpenSSL library is broken. Since this is not an OpenLDAP bug this ITS will be closed. -- -- 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

ITS#6226
by masarati＠aero.polimi.it 23 Jul '09

23 Jul '09

Duplicate of ITS#5941? p.

1 0

Re: (ITS#6221) slapd segfault in SSL_CTX_set_info_callback
by steve＠falchion.com 23 Jul '09

23 Jul '09

I tried re-compiling with CC="gcc -g" and got the following backtrace from gdb: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1] 0xd26d07d0 in SSL_CTX_set_info_callback () from /LDAP/build/openldap-2.4.16/libraries/libldap_r/.libs/libldap_r.a(libldap_r-2.4.so.2) (gdb) bt #0 0xd26d07d0 in SSL_CTX_set_info_callback () from /LDAP/build/openldap-2.4.16/libraries/libldap_r/.libs/libldap_r.a(libldap_r-2.4.so.2) #1 0xd26cdedc in tlso_ctx_init (lo=0x200c087c, lt=0x2ff22970, is_server=1) at tls_o.c:320 #2 0xd26ca50c in ldap_int_tls_init_ctx (lo=0x200c087c, is_server=1) at tls2.c:245 #3 0xd26cc1cc in ldap_pvt_tls_set_option (ld=0x200c0878, option=24591, arg=0x2ff22ae8) at tls2.c:800 #4 0x10001f90 in main (argc=9, argv=0x2ff22b94) at main.c:826 This one seems much more useful from a debugging perspective. I noticed that the configure program has some options along the lines of "--with-PIC" which defaults to "both PIC and non-PIC". Could I use this to help debug the issue perhaps? How would I use it (not sure what options it takes). Thanks, Steve

1 0

(ITS#6200)
by imf＠u.washington.edu 23 Jul '09

23 Jul '09

The changes made to 2.4.17 seem to have fixed the crashes in the caching module. Thanks for that. We still are able to crash 2.4.17, however. It only happens after a heavy load is placed on the producer for >24 hours continuous. Unfortunately, we've not been able to get good tracebacks. They all look like this, (gdb) where #0 0x00869410 in __kernel_vsyscall () #1 0x00390d80 in raise () from /lib/libc.so.6 #2 0x00392691 in abort () from /lib/libc.so.6 #3 0x0038a1fb in __assert_fail () from /lib/libc.so.6 #4 0x0808d532 in malloc () #5 0x0822c93f in ?? () #6 0x0822c933 in ?? () #7 0x00000039 in ?? () #8 0x0822c908 in ?? () #9 0x00000000 in ?? () The producer slowly grows its memory footprint. I can't tell if it's from just normal operations or memory leaks. I suspect it's a little of both. The end result, as you can see from the core above, is that there's likely some corrupted (or unfreed) memory somewhere. Sorry I can't nail it down further. The load profile that we placed on the server is documented in my prior report. See above. --- Tracy Stenvik University Computing Services 354843. University of Washington email: imf(a)u.washington.edu voice: (206) 685-3344

1 0

(ITS#6226) Double free() with translucent+rwm
by test.007＠seznam.cz 23 Jul '09

23 Jul '09

Full_Name: Test Seven Version: 2.4.17 OS: Linux/Windows URL: Submission from: (NULL) (195.113.184.10) Have sample setup with bdb database, add the following to the bottom of slapd.conf: overlay translucent overlay rwm uri "ldap://127.6.6.6/" # (the server 127.6.6.6 must not exist) Run any search query against the server (with correct credentials). Slapd tries to contact the remote server, then it properly returns an error (32, or 52...) to the client, but then it aborts. Variations: a) Change .conf: uri "ldap://something.that.resolves.but.doesnt.respond" b) Add to the bottom of .conf: idassert-bind binddn="cn=doesnt,ou=matter" credentials=secret The variations return different errors to the client, and may crash elsewhere. Problem in the code (for Variation a): ldap_back_dobind_int() calls send_ldap_result(op,rs), which eventually free-s ((*op).o_request).oq_search.rs_filterstr.bv_val; the same string is later free-d after return to translucent_search() after being retrieved from local variable "fbv".

1 0

(ITS#6225) GSSAPI support for client library (fixes)
by mimir＠samba.org 22 Jul '09

22 Jul '09

Full_Name: Rafal Szczesniak Version: Stable (2.4.16) OS: GNU/Linux URL: http://www.samba.org/~mimir/gssapi-bugfix.diff Submission from: (NULL) (67.51.54.234) This is a bugfix patch for OpenLDAP's gssapi support.

1 0

Re: (ITS#6223) [patch] snprint() fix in guess_service_principal()
by jerry＠plainjoe.org 22 Jul '09

22 Jul '09

Correction to the URL. Should be: ftp://ftp.openldap.org/incoming/openldap-2.4.16-guess_service_principal.diff

1 0

(ITS#6224) [patch] snprint() fix in guess_service_principal()
by jerry＠plainjoe.org 22 Jul '09

22 Jul '09

Full_Name: Gerald Carter Version: 2.4.16 OS: Linux URL: ftp://ftp.openldap.org/incoming/openldap-2.4.6-guess_service_principal.diff Submission from: (NULL) (71.12.192.77) There's an off by one error in guess_service_principal() when copying and checking the return value from snprintf(). Trivial patch is included.

1 0

(ITS#6223) [patch] snprint() fix in guess_service_principal()
by jerry＠plainjoe.org 22 Jul '09

22 Jul '09

Full_Name: Gerald Carter Version: 2.4.16 OS: Linux URL: ftp://ftp.openldap.org/incoming/openldap-2.4.6-guess_service_principal.diff Submission from: (NULL) (71.12.192.77) There's an off by one error in guess_service_principal() when copying and checking the return value from snprintf(). Trivial patch is included.

1 0

(ITS#6222) Add "unlimited" option for cachesize settings
by quanah＠zimbra.com 22 Jul '09

22 Jul '09

Full_Name: Quanah Gibson-Mount Version: 2.4.17 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) Now that we have multiple cache sizes, it would be extremely useful, particularly with dncachesize, to be able to specify an "unlimited" setting, so that the 2.3 behavior can be easily replicated. Also so that people who have systems with plenty of RAM can just set it once. In particular, I've noticed in 2.3->2.4 upgrades, if dncachesize is particularly small in relation to the size of the database, slapd is essentially unusable. I'd rather see dncachesize default to unlimited if it isn't set (2.3 behavior), and people can tune it down from there if they need to do so. This allows slapd to remain usable without severely impacting the ability of slapd to function. It is so bad, that it becomes impossible to modify cn=config via ldap commands, and you have to stop slapd and manually hack the cn=config text files to return slapd to a usable state.

1 0

Re: (ITS#6220) Problem with writetimeout
by moenoel＠informatik.uni-bremen.de 22 Jul '09

22 Jul '09

Howard Chu wrote: > moenoel(a)informatik.uni-bremen.de wrote: >> Full_Name: Christian Manal >> Version: 2.4.17 >> OS: SunOS 5.10 Generic_139556-08 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (2001:638:708:30c9:221:85ff:fe3f:1775) >> >> >> Clients that take a long time to process search results are geting a >> writetimeout, even though the keyword is unset or 0 in slapd.conf. >> Setting the >> value to a big enough number solves the problem, but that behavior >> doesn't >> conform to the docs. >> >> Noticed through a Net::LDAP based Perl-scipt, which reads a big amount of >> entries from the directory, but failed sporadically on slow systems since >> updating to OpenLDAP 2.4.17. >> >> Backend is hdb using BDB 4.4 from opencsw repository. Server setup is >> one master >> and four slaves on Solaris 10. > > Thanks for the report, this is now fixed in CVS HEAD. > I just tested it and can confirm that it works now. Thank you. Regards, Christian Manal

1 0

Re: (ITS#6145) Resource leaks shown when running cppcheck against openldap
by hyc＠symas.com 22 Jul '09

22 Jul '09

Paul Albert wrote: > Even if these are one shot commands, it could still mask a potential > problem that comes up in a later release that does have a real leak (think why any programmer doesn't want any warnings in his code when building). Would you consider making the changes if I were to get you a patch to fix all of these problems? If I were to do this, would you like one patch to cover the entire fix or a patch per file? Thanks for the offer. The use of scanf() in getpass.c was in code that was never actually compiled before. Due to ITS#4643 I've removed the obsolete scanf() calls. The assignment error detected in slapi_utils.c is wrong, there is no error in this code. Your tool needs to be fixed. dsaschema is a contrib module; you're welcome to submit a patch for that. The code in thr_debug.c is not compiled by default; any developer who uses it is expected to know what they're doing. Since the only way to free the table being allocated is by use of something like an atexit() handler, and those things tend to be non-portable, it's best left alone. The code in tests/progs is never installed, it's only for internal testing (and again, it's all one-shot commands) so none of that is of any concern. ldapdelete.c and ldapmodrdn.c are now fixed in HEAD. >> sleepy code/openldap-2.4.16> ../cppcheck-1.32/cppcheck -q . >> [./clients/tools/ldapdelete.c:230]: (error) Resource leak: fp >> [./clients/tools/ldapmodrdn.c:233]: (error) Memory leak: entrydn >> [./clients/tools/ldapmodrdn.c:233]: (error) Memory leak: rdn >> [./clients/tools/ldapmodrdn.c:233]: (error) Resource leak: fp >> [./contrib/slapd-modules/dsaschema/dsaschema.c:260]: (error) Memory leak: >> saveline >> [./libraries/libldap_r/thr_debug.c:575]: (error) Memory leak: t >> [./libraries/liblutil/getpass.c:128]: (style) Found 'scanf'. You should use >> 'fgets' instead >> [./libraries/liblutil/getpass.c:153]: (style) Found 'scanf'. You should use >> 'fgets' instead >> [./servers/slapd/slapi/slapi_utils.c:2511]: (error) Wrong assignement of an >> auto-variable to an effective parameter of a function >> [./tests/progs/slapd-addel.c:192]: (error) Memory leak: manager >> [./tests/progs/slapd-addel.c:192]: (error) Memory leak: filename >> [./tests/progs/slapd-modify.c:194]: (error) Memory leak: manager >> [./tests/progs/slapd-modify.c:194]: (error) Memory leak: entry >> [./tests/progs/slapd-modrdn.c:177]: (error) Memory leak: manager >> [./tests/progs/slapd-read.c:227]: (error) Memory leak: manager >> [./tests/progs/slapd-read.c:227]: (error) Memory leak: entry >> [./tests/progs/slapd-read.c:227]: (error) Memory leak: filter >> [./tests/progs/slapd-search.c:250]: (error) Memory leak: manager >> [./tests/progs/slapd-search.c:250]: (error) Memory leak: sbase >> [./tests/progs/slapd-search.c:250]: (error) Memory leak: filter -- -- 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

ITS#4643 getpass()
by hyc＠symas.com 22 Jul '09

22 Jul '09

Since getpass() has been dropped from POSIX and is now considered unsafe, I've decided to remove all detection of it. I've reworked the implementation of lutil_getpass() which is used instead, when getpassphrase() is not present. In addition to streamlining the code, I've removed the Merit-specific use of telnet control codes, since that was specifically for a long obsolete deployment at UMich (most likely the old ud client which was deleted from the OpenLDAP tree years ago). -- -- 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#6202) adding command line option to disable line breaking in ldif output
by hyc＠symas.com 22 Jul '09

22 Jul '09

dieter(a)bloms.de wrote: > Hi, > > On Thu, Jul 09, Michael Str=F6der wrote: > >>> I want to do an enhancement request for ldapsearch, because it insert a= > line >>> break after 78 characters. >>> Many people like me use the ldapsearch command in shell script and have= > to >>> workaround this issue. >>> Maybe it make sense to add a command line option to deactivate this lin= > e breaks. >> =20 >> I'd rather recommend to use a decent scripting language with LDAP and/or >> LDIF modules than using ldapsearch in shell scripts. This gives better >> control over data and error handling. > > there are several ldapsearch binaries from other distributor, which > includes an option -T for this concern. > > http://www.koders.com/c/fidD1B671B4DA7CB116CA077E4694EEBAE167D3F85E.aspx > http://docs.sun.com/source/816-6400-10/lsearch.html > =2E.. > > so why doesn't ldapsearch from openldap inlcude this option. > It doesn't break any rfc and historcal implementation and as far as I > can see (with google), there are many admins who have to workaround this > with a little perl script. > > I think it must be a little diff, with a few lines > > I can write it, but is someone willing to inlcude it in the upstream > versions ? It has already been written, see ITS#6149. Closing this ITS as a dup. Since the LDIF spec says that lines MAY be folded, any script that processes LDIF MUST be able to handle folded lines correctly. As such, there is nothing to gain from changing things at this late date, IMO. Other folks may have different opinions, but I don't think the ITS is the place to discuss this. -- -- 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#6214) slapacl causes bdb_db_close error
by hyc＠symas.com 22 Jul '09

22 Jul '09

dkastens(a)uni-osnabrueck.de wrote: > Full_Name: Dirk Kastens > Version: 2.4.17 > OS: Red Hat Enterprise Linux Server release 5.3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (131.173.16.92) > > > I'm using BerkeleyDB.4.6.21 > This issue existed in openldap 2.4.16, so I updated to 2.4.17, but the error > still exists. It seems no one else encountered the problem or reported it against 2.4.16 before... Anyway, thanks for the report, it's now fixed in CVS HEAD. > When I call "slapacl", for example > slapacl -b uid=xmuster,ou=people,dc=myorg -D uid=xmuster,ou=people,dc=myorg > the output ends with the lines: > > bdb(dc=myorg): Error: closing the transaction region with active transactions > bdb_db_close: database "dc=myorg": close failed: Invalid argument (22) > > and the database is corrupted. slapd wasn't running during execution. After > running slapacl slapd starts with the message: > > bdb_db_open: database "dc=myorg": unclean shutdown detected; attempting > recovery. > > This seems to be an old but re-occuring bug. > -- -- 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#6220) Problem with writetimeout
by hyc＠symas.com 22 Jul '09

22 Jul '09

moenoel(a)informatik.uni-bremen.de wrote: > Full_Name: Christian Manal > Version: 2.4.17 > OS: SunOS 5.10 Generic_139556-08 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:638:708:30c9:221:85ff:fe3f:1775) > > > Clients that take a long time to process search results are geting a > writetimeout, even though the keyword is unset or 0 in slapd.conf. Setting the > value to a big enough number solves the problem, but that behavior doesn't > conform to the docs. > > Noticed through a Net::LDAP based Perl-scipt, which reads a big amount of > entries from the directory, but failed sporadically on slow systems since > updating to OpenLDAP 2.4.17. > > Backend is hdb using BDB 4.4 from opencsw repository. Server setup is one master > and four slaves on Solaris 10. Thanks for the report, this is now fixed in CVS HEAD. -- -- 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#6221) slapd segfault in SSL_CTX_set_info_callback
by steve＠falchion.com 22 Jul '09

22 Jul '09

On Tue, 2009-07-21 at 11:17 -0700, Howard Chu wrote: > Steve Paras-Charlton wrote: > > On Tue, 2009-07-21 at 10:32 -0700, Howard Chu wrote: > >> steve(a)falchion.com wrote: > >>> 2.4.17 fails in an identical manner. > >>> > >>> For those interested, 2.4.17 failed to compile because the installed > >>> 2.4.16 libs were being picked up instead of the freshly compiled ones > >>> during the link phase. > >> > >> Looks like a problem in your OpenSSL build, not in OpenLDAP. > > > > Any ideas what that problem might be or what leads you to believe this? > > The backtrace shows that these SSL functions are contained inside your > libldap_r shared library object file. Usually they should be present in > OpenSSL's own shared libraries. If OpenSSL was only provided as a static > library, it's not clear that their code will behave correctly when used inside > a shared library (i.e., PIC vs non-PIC dependencies). Thanks for that info. I apologize for my ignorance but I got out of code development 15-20 years ago. Would it help if I compiled slapd statically? Is there an option for that in configure? > > > Unfortunately this OpenSSL is the one distributed by IBM as part of the > > AIX operating system, so it's not really my build... If I'm going to go > > to them with this, I could use a little more ammo :) > > It would also help if you compile without optimization, with debug symbols, > and run the non-stripped binaries. Your backtraces are lacking a lot of info > at the moment. I re-configured with --enable-debug and re-compiled, then ran slapd from the servers/slapd directory and got the following backtrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1] 0xd2514a34 in SSL_CTX_set_info_callback () from /LDAP/build/openldap-2.4.17/libraries/libldap_r/.libs/libldap_r.a(libldap_r-2.4.so.2) (gdb) bt #0 0xd2514a34 in SSL_CTX_set_info_callback () from /LDAP/build/openldap-2.4.17/libraries/libldap_r/.libs/libldap_r.a(libldap_r-2.4.so.2) #1 0xd2512118 in tlso_ctx_init () from /LDAP/build/openldap-2.4.17/libraries/libldap_r/.libs/libldap_r.a(libldap_r-2.4.so.2) #2 0xd250e70c in ldap_int_tls_init_ctx () from /LDAP/build/openldap-2.4.17/libraries/libldap_r/.libs/libldap_r.a(libldap_r-2.4.so.2) #3 0xd2510400 in ldap_pvt_tls_set_option () from /LDAP/build/openldap-2.4.17/libraries/libldap_r/.libs/libldap_r.a(libldap_r-2.4.so.2) #4 0x10001fb0 in main () To my relatively untrained eye this doesn't look much different from the original. Can you give me an example of how I could compile and run to produce a better stack trace? I couldn't find documentation of that sort on the OpenLDAP web page... Thanks again, Steve > > > > > Steve > > > >>> > >>> Steve > >>> > >>> On Mon, 2009-07-20 at 20:04 -0700, Steve Paras-Charlton wrote: > >>>> Currently 2.4.17 fails to compile under AIX 5.3TL10, so I'll try to work > >>>> on it, but in the meantime, any ideas why 2.4.16 is crashing thus? > >>>> > >>>> Steve > >>>> > >>>> On Mon, 2009-07-20 at 15:58 -0700, Quanah Gibson-Mount wrote: > >>>>> --On Monday, July 20, 2009 3:52 PM -0700 Steve Paras-Charlton > >>>>> <steve(a)falchion.com> wrote: > >>>>> > >>>>>> Haven't tried it. is it stable now (or soon to be?) > >>>>> > >>>>> I'd assume that depends on what bugs people report against it. Knowing > >>>>> whether or not this affects 2.4.17 would certainly be useful in that > >>>>> determination. ;) > >>>>> > >>>>> --Quanah > >> > > > > > >

1 0

Re: (ITS#6221) slapd segfault in SSL_CTX_set_info_callback
by hyc＠symas.com 21 Jul '09

21 Jul '09

Steve Paras-Charlton wrote: > On Tue, 2009-07-21 at 10:32 -0700, Howard Chu wrote: >> steve(a)falchion.com wrote: >>> 2.4.17 fails in an identical manner. >>> >>> For those interested, 2.4.17 failed to compile because the installed >>> 2.4.16 libs were being picked up instead of the freshly compiled ones >>> during the link phase. >> >> Looks like a problem in your OpenSSL build, not in OpenLDAP. > > Any ideas what that problem might be or what leads you to believe this? The backtrace shows that these SSL functions are contained inside your libldap_r shared library object file. Usually they should be present in OpenSSL's own shared libraries. If OpenSSL was only provided as a static library, it's not clear that their code will behave correctly when used inside a shared library (i.e., PIC vs non-PIC dependencies). > Unfortunately this OpenSSL is the one distributed by IBM as part of the > AIX operating system, so it's not really my build... If I'm going to go > to them with this, I could use a little more ammo :) It would also help if you compile without optimization, with debug symbols, and run the non-stripped binaries. Your backtraces are lacking a lot of info at the moment. > > Steve > >>> >>> Steve >>> >>> On Mon, 2009-07-20 at 20:04 -0700, Steve Paras-Charlton wrote: >>>> Currently 2.4.17 fails to compile under AIX 5.3TL10, so I'll try to work >>>> on it, but in the meantime, any ideas why 2.4.16 is crashing thus? >>>> >>>> Steve >>>> >>>> On Mon, 2009-07-20 at 15:58 -0700, Quanah Gibson-Mount wrote: >>>>> --On Monday, July 20, 2009 3:52 PM -0700 Steve Paras-Charlton >>>>> <steve(a)falchion.com> wrote: >>>>> >>>>>> Haven't tried it. is it stable now (or soon to be?) >>>>> >>>>> I'd assume that depends on what bugs people report against it. Knowing >>>>> whether or not this affects 2.4.17 would certainly be useful in that >>>>> determination. ;) >>>>> >>>>> --Quanah >> > > -- -- 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#6221) slapd segfault in SSL_CTX_set_info_callback
by steve＠falchion.com 21 Jul '09

21 Jul '09

On Tue, 2009-07-21 at 10:32 -0700, Howard Chu wrote: > steve(a)falchion.com wrote: > > 2.4.17 fails in an identical manner. > > > > For those interested, 2.4.17 failed to compile because the installed > > 2.4.16 libs were being picked up instead of the freshly compiled ones > > during the link phase. > > Looks like a problem in your OpenSSL build, not in OpenLDAP. Any ideas what that problem might be or what leads you to believe this? Unfortunately this OpenSSL is the one distributed by IBM as part of the AIX operating system, so it's not really my build... If I'm going to go to them with this, I could use a little more ammo :) Steve > > > > Steve > > > > On Mon, 2009-07-20 at 20:04 -0700, Steve Paras-Charlton wrote: > >> Currently 2.4.17 fails to compile under AIX 5.3TL10, so I'll try to work > >> on it, but in the meantime, any ideas why 2.4.16 is crashing thus? > >> > >> Steve > >> > >> On Mon, 2009-07-20 at 15:58 -0700, Quanah Gibson-Mount wrote: > >>> --On Monday, July 20, 2009 3:52 PM -0700 Steve Paras-Charlton > >>> <steve(a)falchion.com> wrote: > >>> > >>>> Haven't tried it. is it stable now (or soon to be?) > >>> > >>> I'd assume that depends on what bugs people report against it. Knowing > >>> whether or not this affects 2.4.17 would certainly be useful in that > >>> determination. ;) > >>> > >>> --Quanah >

1 0

Re: (ITS#6221) slapd segfault in SSL_CTX_set_info_callback
by hyc＠symas.com 21 Jul '09

21 Jul '09

steve(a)falchion.com wrote: > 2.4.17 fails in an identical manner. > > For those interested, 2.4.17 failed to compile because the installed > 2.4.16 libs were being picked up instead of the freshly compiled ones > during the link phase. Looks like a problem in your OpenSSL build, not in OpenLDAP. > > Steve > > On Mon, 2009-07-20 at 20:04 -0700, Steve Paras-Charlton wrote: >> Currently 2.4.17 fails to compile under AIX 5.3TL10, so I'll try to work >> on it, but in the meantime, any ideas why 2.4.16 is crashing thus? >> >> Steve >> >> On Mon, 2009-07-20 at 15:58 -0700, Quanah Gibson-Mount wrote: >>> --On Monday, July 20, 2009 3:52 PM -0700 Steve Paras-Charlton >>> <steve(a)falchion.com> wrote: >>> >>>> Haven't tried it. is it stable now (or soon to be?) >>> >>> I'd assume that depends on what bugs people report against it. Knowing >>> whether or not this affects 2.4.17 would certainly be useful in that >>> determination. ;) >>> >>> --Quanah -- -- 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#6221) slapd segfault in SSL_CTX_set_info_callback
by steve＠falchion.com 21 Jul '09

21 Jul '09

2.4.17 fails in an identical manner. For those interested, 2.4.17 failed to compile because the installed 2.4.16 libs were being picked up instead of the freshly compiled ones during the link phase. Steve On Mon, 2009-07-20 at 20:04 -0700, Steve Paras-Charlton wrote: > Currently 2.4.17 fails to compile under AIX 5.3TL10, so I'll try to work > on it, but in the meantime, any ideas why 2.4.16 is crashing thus? > > Steve > > On Mon, 2009-07-20 at 15:58 -0700, Quanah Gibson-Mount wrote: > > --On Monday, July 20, 2009 3:52 PM -0700 Steve Paras-Charlton > > <steve(a)falchion.com> wrote: > > > > > Haven't tried it. is it stable now (or soon to be?) > > > > I'd assume that depends on what bugs people report against it. Knowing > > whether or not this affects 2.4.17 would certainly be useful in that > > determination. ;) > > > > --Quanah > > > > -- > > > > Quanah Gibson-Mount > > Principal Software Engineer > > Zimbra, Inc > > -------------------- > > Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6221) slapd segfault in SSL_CTX_set_info_callback
by steve＠falchion.com 21 Jul '09

21 Jul '09

Currently 2.4.17 fails to compile under AIX 5.3TL10, so I'll try to work on it, but in the meantime, any ideas why 2.4.16 is crashing thus? Steve On Mon, 2009-07-20 at 15:58 -0700, Quanah Gibson-Mount wrote: > --On Monday, July 20, 2009 3:52 PM -0700 Steve Paras-Charlton > <steve(a)falchion.com> wrote: > > > Haven't tried it. is it stable now (or soon to be?) > > I'd assume that depends on what bugs people report against it. Knowing > whether or not this affects 2.4.17 would certainly be useful in that > determination. ;) > > --Quanah > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6221) slapd segfault in SSL_CTX_set_info_callback
by quanah＠zimbra.com 21 Jul '09

21 Jul '09

--On Monday, July 20, 2009 3:52 PM -0700 Steve Paras-Charlton <steve(a)falchion.com> wrote: > Haven't tried it. is it stable now (or soon to be?) I'd assume that depends on what bugs people report against it. Knowing whether or not this affects 2.4.17 would certainly be useful in that determination. ;) --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6221) slapd segfault in SSL_CTX_set_info_callback
by steve＠falchion.com 21 Jul '09

21 Jul '09

Haven't tried it. is it stable now (or soon to be?) Steve On Mon, 2009-07-20 at 15:28 -0700, Quanah Gibson-Mount wrote: > --On Monday, July 20, 2009 5:44 PM +0000 steve(a)falchion.com wrote: > > > Full_Name: Steve Paras-Charlton > > Version: 2.4.16 > > OS: AIX > > URL: ftp://ftp.openldap.org/incoming/spc-slapd-info.txt.1 > > Submission from: (NULL) (66.18.215.114) > > > > > > slapd works fine unless I enable TLS and give it certificates > > (self-signed). Segfault occurs after reading config and opening > > certificate files. > > Does this happen with 2.4.17? > > --Quanah > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6221) slapd segfault in SSL_CTX_set_info_callback
by quanah＠zimbra.com 21 Jul '09

21 Jul '09

--On Monday, July 20, 2009 5:44 PM +0000 steve(a)falchion.com wrote: > Full_Name: Steve Paras-Charlton > Version: 2.4.16 > OS: AIX > URL: ftp://ftp.openldap.org/incoming/spc-slapd-info.txt.1 > Submission from: (NULL) (66.18.215.114) > > > slapd works fine unless I enable TLS and give it certificates > (self-signed). Segfault occurs after reading config and opening > certificate files. Does this happen with 2.4.17? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6221) slapd segfault in SSL_CTX_set_info_callback
by steve＠falchion.com 20 Jul '09

20 Jul '09

Full_Name: Steve Paras-Charlton Version: 2.4.16 OS: AIX URL: ftp://ftp.openldap.org/incoming/spc-slapd-info.txt.1 Submission from: (NULL) (66.18.215.114) slapd works fine unless I enable TLS and give it certificates (self-signed). Segfault occurs after reading config and opening certificate files. built with: gcc 4.2.0, openssl 9.8.840 configure --enable-crypt --enable-modules --enable-overlays --with-tls=openssl --prefix=/usr/local backtrace, program trace and slapd.conf attached ftp://ftp.openldap.org/incoming/spc-slapd-info.txt.1

1 0

(ITS#6220) Problem with writetimeout
by moenoel＠informatik.uni-bremen.de 20 Jul '09

20 Jul '09

Full_Name: Christian Manal Version: 2.4.17 OS: SunOS 5.10 Generic_139556-08 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:638:708:30c9:221:85ff:fe3f:1775) Clients that take a long time to process search results are geting a writetimeout, even though the keyword is unset or 0 in slapd.conf. Setting the value to a big enough number solves the problem, but that behavior doesn't conform to the docs. Noticed through a Net::LDAP based Perl-scipt, which reads a big amount of entries from the directory, but failed sporadically on slow systems since updating to OpenLDAP 2.4.17. Backend is hdb using BDB 4.4 from opencsw repository. Server setup is one master and four slaves on Solaris 10. Sample of 'stats' log: Jul 20 11:42:43 ldapserver slapd[9053]: [ID 848112 local4.debug] conn=12479 fd=79 ACCEPT from IP=192.168.1.1:50210 (IP=0.0.0.0:389) Jul 20 11:42:43 ldapserver slapd[9053]: [ID 270379 local4.debug] conn=12479 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jul 20 11:42:43 ldapserver slapd[9053]: [ID 560212 local4.debug] conn=12479 op=0 STARTTLS Jul 20 11:42:43 ldapserver slapd[9053]: [ID 875301 local4.debug] conn=12479 op=0 RESULT oid= err=0 text= Jul 20 11:42:43 ldapserver slapd[9053]: [ID 105384 local4.debug] conn=12479 fd=79 TLS established tls_ssf=256 ssf=256 Jul 20 11:42:43 ldapserver slapd[9053]: [ID 215403 local4.debug] conn=12479 op=1 BIND dn="uid=dummyuser,ou=System,dc=example,dc=com" method=128 Jul 20 11:42:43 ldapserver slapd[9053]: [ID 600343 local4.debug] conn=12479 op=1 BIND dn="uid=dummyuser,ou=System,dc=example,dc=com" mech=SIMPLE ssf=0 Jul 20 11:42:43 ldapserver slapd[9053]: [ID 588225 local4.debug] conn=12479 op=1 RESULT tag=97 err=0 text= Jul 20 11:42:43 ldapserver slapd[9053]: [ID 469902 local4.debug] conn=12479 op=2 SRCH base="ou=people,dc=example,dc=com" scope=2 deref=2 filter="(objectClass=posixAccount)" Jul 20 11:42:43 ldapserver slapd[9053]: [ID 744844 local4.debug] conn=12479 op=2 SRCH attr=uid userpassword uidnumber gidnumber gecos homedirectory loginshell Jul 20 11:43:00 ldapserver slapd[9053]: [ID 485650 local4.debug] conn=12479 fd=79 closed (writetimeout) The (slightly modified) config files of the master and the slaves can be obtained here: http://www.informatik.uni-bremen.de/~moenoel/ldap/master.conf http://www.informatik.uni-bremen.de/~moenoel/ldap/slaves.conf

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs