- openldap-bugs - openldap.org

Re: (ITS#4739) Server crashes every time alias is dereferenced
by hardimankevin＠yahoo.com 09 Nov '06

09 Nov '06

--0-1753053770-1163092074=:90949 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable Buchan,=0A=0ANot sure what to say - I can reproduce this error with the Man= driva packages and from source (which leads me to believe it has nothing to= do with the packaging) with a 100% rate. I had sent Howard Chu an email l= ast night with much more detail; if you'd like me to forward that I will.= =0A=0A -kph=0A=0A=0A----- Original Message ----=0AFrom: Buchan Milne <bg= milne(a)staff.telkomsa.net>=0ATo: hardimankevin(a)yahoo.com=0ACc: openldap-its@= openldap.org=0ASent: Thursday, November 9, 2006 11:07:10 AM=0ASubject: Re: = (ITS#4739) Server crashes every time alias is dereferenced=0A=0AOn Wednesda= y 08 November 2006 21:18, hardimankevin(a)yahoo.com wrote:=0A> Full_Name: Kev= in Hardiman=0A> Version: 2.3.27=0A> OS: Linux (Mandriva 2007)=0A> URL: ftp:= //ftp.openldap.org/incoming/=0A> Submission from: (NULL) (24.90.130.182)=0A= >=0A>=0A> Using the very simple alias below, OpenLDAP will crash every time= it is=0A> dereferenced:=0A>=0A> dn: uid=3Dtest,ou=3DUsers,ou=3Dbladiant,ou= =3Dsmb,ou=3DCore Services,dc=3Dexample,dc=3Dcom=0A> objectClass: alias=0A> = objectclass: extensibleObject=0A> uid: test=0A> aliasedObjectName: uid=3Dte= st,ou=3DUsers,dc=3Dexample,dc=3Dcom=0A>=0A> This error has been experience = with OpenLDAP releases 2.3.6 and 2.3.27,=0A> both in the form of provided M= andriva packages. I also have seen a number=0A> of references to this erro= r in previous releases, with no explicit fix. =0A> Please advise.=0A=0A=0AC= an't reproduce:=0A=0A$ ldapsearch -h localhost -LLL -s children -a never -= x -b "ou=3DTest =0AAliases,dc=3Dranger,dc=3Ddnsalias,dc=3Dcom"=0Adn: uid=3D= bgmilne,ou=3DTest Aliases,dc=3Dranger,dc=3Ddnsalias,dc=3Dcom=0AobjectClass:= alias=0AobjectClass: extensibleObject=0Auid: bgmilne=0AaliasedObjectName: = uid=3Dbgmilne,ou=3DPeople,dc=3Dranger,dc=3Ddnsalias,dc=3Dcom=0A=0A$ ldapsea= rch -h localhost -LLL -s children -a always -x -b "ou=3DTest =0AAliases,dc= =3Dranger,dc=3Ddnsalias,dc=3Dcom" objectclass=0Adn: uid=3Dbgmilne,ou=3DPeop= le,dc=3Dranger,dc=3Ddnsalias,dc=3Dcom=0AobjectClass: mailRecipient=0Aobject= Class: person=0AobjectClass: organizationalPerson=0AobjectClass: inetOrgPer= son=0AobjectClass: posixAccount=0AobjectClass: top=0AobjectClass: kerberosS= ecurityObject=0AobjectClass: shadowAccount=0AobjectClass: sambaSamAccount= =0A=0A$ rpm -q openldap-servers=0Aopenldap-servers-2.3.27-1mdv2007.0=0A=0A$= rpm -q openldap-servers --qf "%{PACKAGER}\n"=0ABuchan Milne <bgmilne@mandr= iva.org>=0A=0A=0ARegards,=0ABuchan=0A=0A-- =0ABuchan Milne=0AISP Systems Sp= ecialist - Monitoring/Authentication Team Leader=0AB.Eng,RHCE(8030047890107= 97),LPIC-2(LPI000074592)=0A=0A=0A=0A=0A=0A=0A=0A =0A_______________________= _____________________________________________________________=0ADo you Yaho= o!?=0AEveryone is raving about the all-new Yahoo! Mail beta.=0Ahttp://new.m= ail.yahoo.com --0-1753053770-1163092074=:90949 Content-Type: text/html; charset=ascii Content-Transfer-Encoding: quoted-printable <html><head><style type=3D"text/css"></style></he= ad><body><div style=3D"font-family:arial, helvetica, sans-serif;font-size:1= 0pt"><div style=3D"font-family: arial,helvetica,sans-serif; font-size: 10pt= ;">Buchan, Not sure what to say - I can reproduce this error with th= e Mandriva packages and from source (which leads me to believe it has nothi= ng to do with the packaging) with a 100% rate.  I had sent Howard Chu = an email last night with much more detail; if you'd like me to forward that= I will.     -kph <div style=3D"font-famil= y: times new roman,new york,times,serif; font-size: 12pt;">----- Original M= essage ---- From: Buchan Milne <bgmilne(a)staff.telkomsa.net> To:= hardimankevin(a)yahoo.com Cc: openldap-its(a)openldap.org Sent: Thursday= , November 9, 2006 11:07:10 AM Subject: Re: (ITS#4739) Server crashes ev= ery time alias is dereferenced <div>On Wednesday 08 November 2006 21= :18, hardimankevin(a)yahoo.com wrote: > Full_Name: Kevin Hardiman > V= ersion: 2.3.27 > OS: Linux (Mandriva 2007) > URL: ftp://ftp.ope= nldap.org/incoming/ > Submission from: (NULL) (24.90.130.182) >= > > Using the very simple alias below, OpenLDAP will crash eve= ry time it is > dereferenced: > > dn: uid=3Dtest,ou=3DUse= rs,ou=3Dbladiant,ou=3Dsmb,ou=3DCore Services,dc=3Dexample,dc=3Dcom > = objectClass: alias > objectclass: extensibleObject > uid: test<= br>> aliasedObjectName: uid=3Dtest,ou=3DUsers,dc=3Dexample,dc=3Dcom &= gt; > This error has been experience with OpenLDAP releases 2.3.6 and= 2.3.27, > both in the form of provided Mandriva packages. &nbsp= ;I also have seen a number > of references to this error in previous = releases, with no explicit fix. > Please advise. Can't re= produce: $ ldapsearch -h localhost -LLL -s children -a never &n= bsp;-x -b "ou=3DTest Aliases,dc=3Dranger,dc=3Ddnsalias,dc=3Dcom" dn: uid=3Dbgmilne,ou=3D= Test Aliases,dc=3Dranger,dc=3Ddnsalias,dc=3Dcom objectClass: alias ob= jectClass: extensibleObject uid: bgmilne aliasedObjectName: uid=3Dbgm= ilne,ou=3DPeople,dc=3Dranger,dc=3Ddnsalias,dc=3Dcom $ ldapsearch -h = localhost -LLL -s children -a always  -x -b "ou=3DTest Aliase= s,dc=3Dranger,dc=3Ddnsalias,dc=3Dcom" objectclass dn: uid=3Dbgmilne,ou= =3DPeople,dc=3Dranger,dc=3Ddnsalias,dc=3Dcom objectClass: mailRecipient<= br>objectClass: person objectClass: organizationalPerson objectClass:= inetOrgPerson objectClass: posixAccount objectClass: top objectCl= ass: kerberosSecurityObject objectClass: shadowAccount objectClass: s= ambaSamAccount $ rpm -q openldap-servers openldap-servers-2.3.27-= 1mdv2007.0 $ rpm -q openldap-servers --qf "%{PACKAGER}\n" Buchan = Milne <bgmilne(a)mandriva.org> Regards, Buchan -- = Buchan Milne ISP Systems Specialist - Monitoring/Authentication Team Leader B.Eng,RHCE(803004789010797),LPIC-= 2(LPI000074592) </div></div> </div></div> =0A=0A<hr size=3D1>Every= one is raving about <a href=3D"http://us.rd.yahoo.com/evt=3D45083/*http://a= dvision.webevents.yahoo.com/mailbeta">the all-new Yahoo! Mail beta.</a></bo= dy></html> --0-1753053770-1163092074=:90949--

1 0

Re: (ITS#4739) Server crashes every time alias is dereferenced
by bgmilne＠staff.telkomsa.net 09 Nov '06

09 Nov '06

--nextPart2681002.ZbxIqWnAlZ Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 08 November 2006 21:18, hardimankevin(a)yahoo.com wrote: > Full_Name: Kevin Hardiman > Version: 2.3.27 > OS: Linux (Mandriva 2007) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (24.90.130.182) > > > Using the very simple alias below, OpenLDAP will crash every time it is > dereferenced: > > dn: uid=3Dtest,ou=3DUsers,ou=3Dbladiant,ou=3Dsmb,ou=3DCore Services,dc=3D= example,dc=3Dcom > objectClass: alias > objectclass: extensibleObject > uid: test > aliasedObjectName: uid=3Dtest,ou=3DUsers,dc=3Dexample,dc=3Dcom > > This error has been experience with OpenLDAP releases 2.3.6 and 2.3.27, > both in the form of provided Mandriva packages. I also have seen a number > of references to this error in previous releases, with no explicit fix.=20 > Please advise. Can't reproduce: $ ldapsearch -h localhost -LLL -s children -a never -x -b "ou=3DTest=20 Aliases,dc=3Dranger,dc=3Ddnsalias,dc=3Dcom" dn: uid=3Dbgmilne,ou=3DTest Aliases,dc=3Dranger,dc=3Ddnsalias,dc=3Dcom objectClass: alias objectClass: extensibleObject uid: bgmilne aliasedObjectName: uid=3Dbgmilne,ou=3DPeople,dc=3Dranger,dc=3Ddnsalias,dc= =3Dcom $ ldapsearch -h localhost -LLL -s children -a always -x -b "ou=3DTest=20 Aliases,dc=3Dranger,dc=3Ddnsalias,dc=3Dcom" objectclass dn: uid=3Dbgmilne,ou=3DPeople,dc=3Dranger,dc=3Ddnsalias,dc=3Dcom objectClass: mailRecipient objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: posixAccount objectClass: top objectClass: kerberosSecurityObject objectClass: shadowAccount objectClass: sambaSamAccount $ rpm -q openldap-servers openldap-servers-2.3.27-1mdv2007.0 $ rpm -q openldap-servers --qf "%{PACKAGER}\n" Buchan Milne <bgmilne(a)mandriva.org> Regards, Buchan =2D-=20 Buchan Milne ISP Systems Specialist - Monitoring/Authentication Team Leader B.Eng,RHCE(803004789010797),LPIC-2(LPI000074592) --nextPart2681002.ZbxIqWnAlZ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBFU1IvrJK6UGDSBKcRAhkQAKDCpV5W+plszHrf/GIqkx2yMcTtwQCePs67 JaAwrB9eaYnzEcK7uS41ZEo= =4WpH -----END PGP SIGNATURE----- --nextPart2681002.ZbxIqWnAlZ--

1 0

Re: (ITS#4739) Server crashes every time alias is dereferenced
by hyc＠symas.com 09 Nov '06

09 Nov '06

hardimankevin(a)yahoo.com wrote: > Full_Name: Kevin Hardiman > Version: 2.3.27 > OS: Linux (Mandriva 2007) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (24.90.130.182) > > > Using the very simple alias below, OpenLDAP will crash every time it is > dereferenced: > > dn: uid=test,ou=Users,ou=bladiant,ou=smb,ou=Core Services,dc=example,dc=com > objectClass: alias > objectclass: extensibleObject > uid: test > aliasedObjectName: uid=test,ou=Users,dc=example,dc=com > > This error has been experience with OpenLDAP releases 2.3.6 and 2.3.27, both in > the form of provided Mandriva packages. I also have seen a number of references > to this error in previous releases, with no explicit fix. Please advise. Well, considering that no one has reported any such problem during the whole time releases 2.3.6-2.3.27 were published, it's no surprise that there has been no fix yet. There's not enough information here to reproduce the bug. What backend are you using, what other entries are in the database? In particular, does "uid=test,ou=Users,dc=example,dc=com" exist? You should provide a sample slapd.conf and minimal LDIF needed to reproduce the error. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4741) ppolicy.c improperly discards return value of check_password() function
by lsherida＠nccs.nasa.gov 09 Nov '06

09 Nov '06

Full_Name: Lee Sheridan Version: 2.3.27 OS: Debian GNU/Linux (etch) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (69.168.13.7) In servers/slapd/overlays/ppolicy.c, check_password_quality function, at line 530, the value of the 'ok' variable is discarded by unconditionally assigning it the value LDAP_SUCCESS. The variable is the return code of the user-defined check_password() function, which is assigned at line 522. The next if-then-else block is checking to see if the module reported an error, at which point 'ok' would be assigned LDAP_OTHER regardless of what check_password() returned. A superfluous else block appears after this check, assigning 'ok' to LDAP_SUCCESS. It works fine for me if I remove the else block. Thanks,

1 0

(ITS#4740) SASL bind assert
by hyc＠OpenLDAP.org 09 Nov '06

09 Nov '06

Full_Name: Howard Chu Version: all < 2.3.29 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.168.84.21) Submitted by: hyc Apparently this bug was discovered by Evgeny Legerov but was not previously reported to anyone on the Project. The bug is now fixed in HEAD and RE23. Performing a SASL Bind with an authcid longer than 255 characters, with a space as the 255th character, will cause the length of the normalized name to be computed incorrectly, failing to take into account the escaping of the space character. (The SASL Bind code truncates all incoming names longer than 255 to exactly 255 characters.) This triggers an assert in libldap because the resulting string length doesn't match what we expected it to be. The fix is in libldap/getdn.c rev 1.134. The MITRE CVE record for this bug is http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5779

1 0

(ITS#4739) Server crashes every time alias is dereferenced
by hardimankevin＠yahoo.com 08 Nov '06

08 Nov '06

Full_Name: Kevin Hardiman Version: 2.3.27 OS: Linux (Mandriva 2007) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.90.130.182) Using the very simple alias below, OpenLDAP will crash every time it is dereferenced: dn: uid=test,ou=Users,ou=bladiant,ou=smb,ou=Core Services,dc=example,dc=com objectClass: alias objectclass: extensibleObject uid: test aliasedObjectName: uid=test,ou=Users,dc=example,dc=com This error has been experience with OpenLDAP releases 2.3.6 and 2.3.27, both in the form of provided Mandriva packages. I also have seen a number of references to this error in previous releases, with no explicit fix. Please advise. Kevin Hardiman

1 0

Re: (ITS#4738) hdb livelock
by hyc＠symas.com 08 Nov '06

08 Nov '06

richton(a)nbcs.rutgers.edu wrote: > Please visit > https://www.nbcs.rutgers.edu/~richton/richton-20061107-livelock_2.txt for > an updated backtrace. This one almost looks like it has lock contention, > and a writewaiter assert is notably missing... The trace shows several threads backing off because they think some other thread is about to read the entry from the database. At a guess, none of them is actually going to perform the database read. Most likely a lock is missing here. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4738) hdb livelock
by richton＠nbcs.rutgers.edu 08 Nov '06

08 Nov '06

Please visit https://www.nbcs.rutgers.edu/~richton/richton-20061107-livelock_2.txt for an updated backtrace. This one almost looks like it has lock contention, and a writewaiter assert is notably missing... I'm going to rm the bad link, it can only hurt people. On Tue, 7 Nov 2006, Aaron Richton wrote: > Sigh. As may be obvious to anybody unfortunate enough to look at the link, I > seem to have gotten my core files confused. I have a bunch of db_stat -CA > done properly, but the backtrace for this may be lost to the bit bucket. I'll > poke around my systems and see what I can find, but I think it might be > nothing. A syslog of "waiting for 1027 threads to terminate" might be the > only other durable evidence. >

1 0

Re: (ITS#4738) hdb livelock
by richton＠nbcs.rutgers.edu 08 Nov '06

08 Nov '06

Sigh. As may be obvious to anybody unfortunate enough to look at the link, I seem to have gotten my core files confused. I have a bunch of db_stat -CA done properly, but the backtrace for this may be lost to the bit bucket. I'll poke around my systems and see what I can find, but I think it might be nothing. A syslog of "waiting for 1027 threads to terminate" might be the only other durable evidence.

1 0

(ITS#4738) hdb livelock
by richton＠nbcs.rutgers.edu 07 Nov '06

07 Nov '06

Full_Name: Aaron Richton Version: 2.3.28+4720 OS: Solaris 9 URL: https://www.nbcs.rutgers.edu/~richton/richton-20061107-livelock.txt Submission from: (NULL) (128.6.31.137) See also ITS#4720, although this is slightly different. hdb livelock (CPU 100% gunned) on 2.3.28 with patch for ITS #4720 (syncprov.c 1.161 -> 1.162 diff). See URL for backtrace and db_stat -CA of the database on threads t@13 and t@16, which (if I'm reading correctly) are the affected ones. I have the db_stat -CA of the other backends saved if I misread, and the core file available if variables are needed. Aside, I know you're looking for RE23 testing, I was kicking the tires of that and about to put it up when this happened. Soon I'll be there, regardless of how this turns out, due to writewaiter concern.

1 0

Re: (ITS#4737) "overlay not found"
by ando＠sys-net.it 07 Nov '06

07 Nov '06

mmollet(a)westar.com wrote: > Full_Name: Matthieu Mollet > Version: 2.2.13 > OS: Centos 4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (208.45.242.10) > > > Built the smbk5pwd.la overlay and installed it with the 2.2.13 openldap that > comes with Centos. Added module = pathto/smbk5pwd.la and overlay = smbk5pwd > slapd fails with "overlay smbk5pwd not found" > the syntax "<keyword> = <value>" has never been implemented in OpenLDAP software; the keyword "module" has never been supported as well. I suggest you read at least slapd.conf(5) (but I suspect you need to read more) before considering the possibility of a software bug. This ITS will be closed. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4737) "overlay not found"
by Kurt＠OpenLDAP.org 07 Nov '06

07 Nov '06

At 09:19 AM 11/7/2006, mmollet(a)westar.com wrote: >Full_Name: Matthieu Mollet >Version: 2.2.13 >OS: Centos 4 >URL: ftp://ftp.openldap.org/incoming/ >Submission from: (NULL) (208.45.242.10) > > >Built the smbk5pwd.la overlay and installed it with the 2.2.13 openldap that >comes with Centos. Added module = pathto/smbk5pwd.la and overlay = smbk5pwd >slapd fails with "overlay smbk5pwd not found" While there is no indication that this behavior is due to a bug in OpenLDAP Software and 2.2 is Historic, there seems this report should be closed. If you believe this behavior due to a bug in OpenLDAP Software, I suggest you duplicate it in the latest 2.3 release and then file a new bug report that elaborates on why you believe the behavior is due to a bug in OpenLDAP Software.

1 0

(ITS#4737) "overlay not found"
by mmollet＠westar.com 07 Nov '06

07 Nov '06

Full_Name: Matthieu Mollet Version: 2.2.13 OS: Centos 4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (208.45.242.10) Built the smbk5pwd.la overlay and installed it with the 2.2.13 openldap that comes with Centos. Added module = pathto/smbk5pwd.la and overlay = smbk5pwd slapd fails with "overlay smbk5pwd not found"

1 0

Re: (ITS#4736) writewaiter == 1 in connection_destroy
by hyc＠symas.com 07 Nov '06

07 Nov '06

richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: 2.3.28 > OS: Solaris 9 > URL: https://www.nbcs.rutgers.edu/~richton/richton-20061106-backtrace.txt > Submission from: (NULL) (68.196.250.61) > > > 822 assert( c->c_writewaiter == 0); > > Unfortunately writewaiter == 1, the assertion catches, byebye... > > This happened earlier with 2.3.27 (see > https://www.nbcs.rutgers.edu/~richton/richton-20061023-backtrace.txt). Kurt > advised upgrading to 2.3.28, which was running when this caught today. See > https://www.nbcs.rutgers.edu/~richton/richton-20061106-backtrace.txt for the > 2.3.28 trace, not that it looks all too different. I've sync'd the connection manager in RE23 with HEAD. Please test RE23. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4736) writewaiter == 1 in connection_destroy
by hyc＠symas.com 07 Nov '06

07 Nov '06

richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: 2.3.28 > OS: Solaris 9 > URL: https://www.nbcs.rutgers.edu/~richton/richton-20061106-backtrace.txt > Submission from: (NULL) (68.196.250.61) > > > 822 assert( c->c_writewaiter == 0); > > Unfortunately writewaiter == 1, the assertion catches, byebye... > > This happened earlier with 2.3.27 (see > https://www.nbcs.rutgers.edu/~richton/richton-20061023-backtrace.txt). Kurt > advised upgrading to 2.3.28, which was running when this caught today. See > https://www.nbcs.rutgers.edu/~richton/richton-20061106-backtrace.txt for the > 2.3.28 trace, not that it looks all too different. There have been no changes to the connection management since 2.3.27, so it makes sense that the traces look the same. A number of fixes have gone into HEAD along these lines, but they haven't been backported to RE23. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4736) writewaiter == 1 in connection_destroy
by richton＠nbcs.rutgers.edu 07 Nov '06

07 Nov '06

Full_Name: Aaron Richton Version: 2.3.28 OS: Solaris 9 URL: https://www.nbcs.rutgers.edu/~richton/richton-20061106-backtrace.txt Submission from: (NULL) (68.196.250.61) 822 assert( c->c_writewaiter == 0); Unfortunately writewaiter == 1, the assertion catches, byebye... This happened earlier with 2.3.27 (see https://www.nbcs.rutgers.edu/~richton/richton-20061023-backtrace.txt). Kurt advised upgrading to 2.3.28, which was running when this caught today. See https://www.nbcs.rutgers.edu/~richton/richton-20061106-backtrace.txt for the 2.3.28 trace, not that it looks all too different.

1 0

Re: (ITS#4704) accesslog database fails to store contextCSN at shutdown
by quanah＠stanford.edu 07 Nov '06

07 Nov '06

--On Tuesday, November 07, 2006 12:35 AM +0000 quanah(a)stanford.edu wrote: > I've finally figured out how to reproduce this -- The problem is related > to the log purging done by access log. Here is what I did: After applying the commit to HEAD to my source, behavior after log purge was correct. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4704) accesslog database fails to store contextCSN at shutdown
by quanah＠stanford.edu 07 Nov '06

07 Nov '06

I've finally figured out how to reproduce this -- The problem is related to the log purging done by access log. Here is what I did: Make changes to the database, that were replicated. Everything is happy. Shut down slapd, modify the logpurge parameter so that log purging is done. Restart slapd Verified that log purging was done, and that everything was still happily in sync. Stop slapd, restart slapd Now the access log DB has generated a new CSN that is in the future of the suffix stored CSN. So it appears that somehow the logpurge operation either causes a new contextCSN to be written at the time the server is shut down, or it erases the contextCSN held by the accesslog db. Now, this is when I restarted slapd: Nov 6 16:27:14 ldap-dev0 slapd[27400]: @(#) $OpenLDAP: slapd 2.3.28 (Oct 26 2006 13:41:27) $ ^Iquanah@ldap-uat00.stanford.edu:/usr/local/build/openldap-2.3.28/servers/slapd However, the contextCSN that was generated is: contextCSN: 20061107002625Z#000000#00#000000 This matches the time at which I started slapd when log purging was run: Nov 6 16:26:25 ldap-dev0 slapd[27385]: @(#) $OpenLDAP: slapd 2.3.28 (Oct 26 2006 13:41:27) $ ^Iquanah@ldap-uat00.stanford.edu:/usr/local/build/openldap-2.3.28/servers/slapd so I'd say that when log purge is run, it resets the contextCSN in the accesslog DB to the time at which slapd last started... --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4734) Segmentation fault
by hyc＠symas.com 07 Nov '06

07 Nov '06

Christopher Moore wrote: >> This trace indicates that an attribute in the given entry had NULL for >> its AttributeDescription, which is pretty much a "this-can't-happen" >> situation. It would probably be useful to look at the contents of the >> Entry e in frame 2, and all of its attributes. How was this database >> created, how was the entry created? >> > > I forgot to mention that I have just upgraded from Openldap 2.2.23 and the > database was created by open-xchange. > Here is entry e in frame 2. I hope this is what you are after: > (gdb) frame 2 > #2 0x0807e491 in test_filter (op=0x8265c88, e=0x8266140, f=0x40d3b14c) at > filterentry.c:797 > 797 for(a = attrs_find( e->e_attrs, desc ); > (gdb) print *e > $1 = {e_id = 16777216, e_name = {bv_len = 100, bv_val = 0x8265ef5 > "c=open-xchange,dc=org"}, > e_nname = {bv_len = 103, bv_val = 0x8265f5b "e"}, e_attrs = 0x8266168, > e_ocflags = 0, e_bv = { > bv_len = 585, bv_val = 0x8265ef0 "\202\001è\026dc=open-xchange,dc=org"}, > e_private = 0x8265e90} > (gdb) Apparently you are using the OpenLDAP 2.2 database files with OpenLDAP 2.3. This is not supported since the database format changed between 2.2 and 2.3; you have to export with 2.2 slapcat and import with 2.3 slapadd as described in the docs on upgrading. This ITS will be closed. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

RE: (ITS#4734) Segmentation fault
by chris＠linuxepos.com 07 Nov '06

07 Nov '06

> chris(a)linuxepos.com wrote: > > > #0 is_ad_subtype (sub=0x0, super=0x81eafb0) at ad.c:489 > > 489 for ( a = sub->ad_type; a; a=a->sat_sup ) { > > (gdb) where > > #0 is_ad_subtype (sub=0x0, super=0x81eafb0) at ad.c:489 > > #1 0x0806952e in attrs_find (a=0x8266168, desc=0x81eafb0) at attr.c:347 > > #2 0x0807e491 in test_filter (op=0x8265c88, e=0x8266140, f=0x40d3b14c) > at > > filterentry.c:797 > > #3 0x080c83cf in bdb_search (op=0x8265c88, rs=0x40d3a8bc) at > search.c:853 > > #4 0x080632b9 in fe_op_search (op=0x8265c88, rs=0x40d3a8bc) at > search.c:355 > > #5 0x08062a44 in do_search (op=0x8265c88, rs=0x40d3a8bc) at > search.c:217 > > #6 0x08061218 in connection_operation (ctx=0x40d3a93c, arg_v=0x8265c88) > at > > connection.c:1307 > > #7 0x08133ff8 in ldap_int_thread_pool_wrapper (xpool=0x81f1558) at > tpool.c:478 > > #8 0x40263d70 in pthread_start_thread (arg=0x40d3abe0) at manager.c:301 > > #9 0x4038d4a7 in __clone () from /lib/libc.so.6 > > (gdb) > > This trace indicates that an attribute in the given entry had NULL for > its AttributeDescription, which is pretty much a "this-can't-happen" > situation. It would probably be useful to look at the contents of the > Entry e in frame 2, and all of its attributes. How was this database > created, how was the entry created? > I forgot to mention that I have just upgraded from Openldap 2.2.23 and the database was created by open-xchange. Here is entry e in frame 2. I hope this is what you are after: (gdb) frame 2 #2 0x0807e491 in test_filter (op=0x8265c88, e=0x8266140, f=0x40d3b14c) at filterentry.c:797 797 for(a = attrs_find( e->e_attrs, desc ); (gdb) print *e $1 = {e_id = 16777216, e_name = {bv_len = 100, bv_val = 0x8265ef5 "c=open-xchange,dc=org"}, e_nname = {bv_len = 103, bv_val = 0x8265f5b "e"}, e_attrs = 0x8266168, e_ocflags = 0, e_bv = { bv_len = 585, bv_val = 0x8265ef0 "\202\001è\026dc=open-xchange,dc=org"}, e_private = 0x8265e90} (gdb) _________________________________________________________________________________ Scanned by an Igaware Box - protecting computers from viruses, spam, spyware and other Internet junk. For more information visit http://www.igaware.com/security.html _________________________________________________________________________________

1 0

Re: (ITS#4735) configure choice of ODBC
by ando＠sys-net.it 07 Nov '06

07 Nov '06

rk(a)owen.sj.ca.us wrote: > Full_Name: R.K. Owen > Version: HEAD > OS: linux > URL: ftp://ftp.openldap.org/incoming/rkowen-061106.patch > Submission from: (NULL) (66.87.79.68) > > > When using the back-sql with the Oracle XE DB, the Oracle ODBC library > libsqora.so.10.1 was designed to be linked against the unixODBC interface > library instead of the iODBC interface library. This can be demonstrated by > using the unixODBC isql tool which will allow successful interactive querying > of the Oracle DB. However, when trying to start up the slapd daemon with 'slapd > -d 1' the daemon will quit with an error claiming: > Message: [iODBC][Driver Manager] > /usr/lib/oracle/xe/app/oracle/product/10.2.0/server/lib/libsqora.so.10.1: > undefined symbol: bcuMsgBoxError > > The cause for this is that the configure script will first search for iodbc, > then odbc, and thus cause slapd to be built against the iodbc library. > By adding the -with-odbc option the configure script will allow the > administrator to choose which library to use in a flexible way: > > --with-odbc=iodbc # current default (-liodbc) > --with-odbc=odbc # try -lodbc > --with-odbc=/usr/lib/libodbc.so.1 # link against the shared object library > > The changes have been made to the source configure.in file and uploaded as a > patch. > > The patch is not acceptable, since it requires to specify the desired OBDC support, which is counter-intuitive, as most of the RDBMS have drivers or allow to use drivers for both implementations of ODBC. However, your need is clear. I've designed a different fix, which requires to set --with-odbc to the preferred sequence of ODBCs to try (iodbc | unixodbc), while the default (auto) tries the original sequence. It is now committed to HEAD; please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

(ITS#4735) configure choice of ODBC
by rk＠owen.sj.ca.us 06 Nov '06

06 Nov '06

Full_Name: R.K. Owen Version: HEAD OS: linux URL: ftp://ftp.openldap.org/incoming/rkowen-061106.patch Submission from: (NULL) (66.87.79.68) When using the back-sql with the Oracle XE DB, the Oracle ODBC library libsqora.so.10.1 was designed to be linked against the unixODBC interface library instead of the iODBC interface library. This can be demonstrated by using the unixODBC isql tool which will allow successful interactive querying of the Oracle DB. However, when trying to start up the slapd daemon with 'slapd -d 1' the daemon will quit with an error claiming: Message: [iODBC][Driver Manager] /usr/lib/oracle/xe/app/oracle/product/10.2.0/server/lib/libsqora.so.10.1: undefined symbol: bcuMsgBoxError The cause for this is that the configure script will first search for iodbc, then odbc, and thus cause slapd to be built against the iodbc library. By adding the -with-odbc option the configure script will allow the administrator to choose which library to use in a flexible way: --with-odbc=iodbc # current default (-liodbc) --with-odbc=odbc # try -lodbc --with-odbc=/usr/lib/libodbc.so.1 # link against the shared object library The changes have been made to the source configure.in file and uploaded as a patch.

1 0

Re: (ITS#4734) Segmentation fault
by hyc＠symas.com 06 Nov '06

06 Nov '06

chris(a)linuxepos.com wrote: > #0 is_ad_subtype (sub=0x0, super=0x81eafb0) at ad.c:489 > 489 for ( a = sub->ad_type; a; a=a->sat_sup ) { > (gdb) where > #0 is_ad_subtype (sub=0x0, super=0x81eafb0) at ad.c:489 > #1 0x0806952e in attrs_find (a=0x8266168, desc=0x81eafb0) at attr.c:347 > #2 0x0807e491 in test_filter (op=0x8265c88, e=0x8266140, f=0x40d3b14c) at > filterentry.c:797 > #3 0x080c83cf in bdb_search (op=0x8265c88, rs=0x40d3a8bc) at search.c:853 > #4 0x080632b9 in fe_op_search (op=0x8265c88, rs=0x40d3a8bc) at search.c:355 > #5 0x08062a44 in do_search (op=0x8265c88, rs=0x40d3a8bc) at search.c:217 > #6 0x08061218 in connection_operation (ctx=0x40d3a93c, arg_v=0x8265c88) at > connection.c:1307 > #7 0x08133ff8 in ldap_int_thread_pool_wrapper (xpool=0x81f1558) at tpool.c:478 > #8 0x40263d70 in pthread_start_thread (arg=0x40d3abe0) at manager.c:301 > #9 0x4038d4a7 in __clone () from /lib/libc.so.6 > (gdb) This trace indicates that an attribute in the given entry had NULL for its AttributeDescription, which is pretty much a "this-can't-happen" situation. It would probably be useful to look at the contents of the Entry e in frame 2, and all of its attributes. How was this database created, how was the entry created? -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4734) Segmentation fault
by chris＠linuxepos.com 06 Nov '06

06 Nov '06

Full_Name: Christopher Moore Version: 2.3.27 OS: Linux 2.4.31 URL: Submission from: (NULL) (62.49.7.243) Hi, I'm recieving a repeatable Segmentation fault when I try to connect to the ldap server as indicated with this excerpt of gdb trace: Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/local/BerkeleyDB.4.3/lib/libdb-4.3.so...done. Loaded symbols for /usr/local/BerkeleyDB.4.3/lib/libdb-4.3.so Reading symbols from /usr/local/lib/libsasl2.so.2...done. Loaded symbols for /usr/local/lib/libsasl2.so.2 Reading symbols from /usr/local/lib/libssl.so.0.9.7...done. Loaded symbols for /usr/local/lib/libssl.so.0.9.7 Reading symbols from /usr/local/lib/libcrypto.so.0.9.7...done. Loaded symbols for /usr/local/lib/libcrypto.so.0.9.7 Reading symbols from /lib/libcrypt.so.1...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /lib/libresolv.so.2...done. Loaded symbols for /lib/libresolv.so.2 Reading symbols from /lib/libpthread.so.0...done. Loaded symbols for /lib/libpthread.so.0 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /lib/libnss_files.so.2...done. Loaded symbols for /lib/libnss_files.so.2 Reading symbols from /usr/local/lib/sasl2/libsasldb.so.2...done. Loaded symbols for /usr/lib/sasl2/libsasldb.so.2 Reading symbols from /usr/local/lib/sasl2/libcrammd5.so.2...done. Loaded symbols for /usr/lib/sasl2/libcrammd5.so.2 Reading symbols from /usr/local/lib/sasl2/libdigestmd5.so.2...done. Loaded symbols for /usr/lib/sasl2/libdigestmd5.so.2 Reading symbols from /usr/local/lib/sasl2/libotp.so.2...done. Loaded symbols for /usr/lib/sasl2/libotp.so.2 Reading symbols from /usr/local/lib/sasl2/libplain.so.2...done. Loaded symbols for /usr/lib/sasl2/libplain.so.2 Reading symbols from /usr/local/lib/sasl2/libanonymous.so.2...done. Loaded symbols for /usr/lib/sasl2/libanonymous.so.2 Reading symbols from /usr/local/lib/sasl2/liblogin.so.2...done. Loaded symbols for /usr/lib/sasl2/liblogin.so.2 #0 is_ad_subtype (sub=0x0, super=0x81eafb0) at ad.c:489 489 for ( a = sub->ad_type; a; a=a->sat_sup ) { (gdb) where #0 is_ad_subtype (sub=0x0, super=0x81eafb0) at ad.c:489 #1 0x0806952e in attrs_find (a=0x8266168, desc=0x81eafb0) at attr.c:347 #2 0x0807e491 in test_filter (op=0x8265c88, e=0x8266140, f=0x40d3b14c) at filterentry.c:797 #3 0x080c83cf in bdb_search (op=0x8265c88, rs=0x40d3a8bc) at search.c:853 #4 0x080632b9 in fe_op_search (op=0x8265c88, rs=0x40d3a8bc) at search.c:355 #5 0x08062a44 in do_search (op=0x8265c88, rs=0x40d3a8bc) at search.c:217 #6 0x08061218 in connection_operation (ctx=0x40d3a93c, arg_v=0x8265c88) at connection.c:1307 #7 0x08133ff8 in ldap_int_thread_pool_wrapper (xpool=0x81f1558) at tpool.c:478 #8 0x40263d70 in pthread_start_thread (arg=0x40d3abe0) at manager.c:301 #9 0x4038d4a7 in __clone () from /lib/libc.so.6 (gdb)

1 0

RE: (ITS#3460) Adding LDAP statistics script to contrib directory
by ghenry＠suretecsystems.com 06 Nov '06

06 Nov '06

<quote who="daveh(a)ci.com.au"> >> Do you mind if I do some clean up on it? >> >> Mainly Perl::Critic and Perl::Tidy. There's a few tests missing and >> assumptions been made with opening files and system commands etc. > > You might also highlight the fact that it seems to require at least 5.8 > (due to the "qw()" lists). Well, according to the method I always use to check that, Perl::MinimumVersion, we get: perlver ldap-stats.pl -------------------------------------------- | file | explicit | syntax | external | | -------------------------------------------- | | ldap-stats.pl | ~ | v5.6.0 | n/a | | -------------------------------------------- | | Minimum explicit version : ~ | | Minimum syntax version : v5.6.0 | | Minimum version of perl : v5.6.0 | -------------------------------------------- > > I also don't like hard-wiring "/usr/bin/perl", as the system Perls are > rarely up to date. My favourite technique is: > > #! /usr/bin/env perl -w > > which finds Perl from $PATH. > > Or just hard-wire "/usr/local/bin/perl" and let the sysadmin sort it > out... Sounds good. env method is best I suppose, but there are others as listed at: http://perldoc.perl.org/perlrun.html#DESCRIPTION Almost finished that cleanup. It's taken a bit longer than expected. Thanks. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs