June 2007 - openldap-bugs

Re: (ITS#5022) ldappasswd crash consumer slapd with some loglevels

by ando＠sys-net.it

gao(a)schrodinger.com wrote: > URL: ftp://ftp.schrodinger.com/support/openldap/simon.gao.openldap_2.3.35.its.ext ^^^ This link is unreachable > When following command against a consumer slapd, it will crash slapd of the > consumer when loglevel is set to any other value other than 1 or -1 on the > consumer: > > ldappasswd -v -H ldap://consumer -D "uid=joe,ou=people,dc=example,dc=com" -W -S > -x -A > > The crash happens to at least to loglevel 0, 256, 512. When loglevel is set to 1 > or "-1", then no crash is experienced. In addition, when run consumer slapd > manually as front process, ^^^ what does this mean? > then all debug level works without problem. OpenLDAP re23 (in practice, 2.3.36 just released) doesn't show anything like that. I note that differences related to the debug level usually mean that a NULL or an invalid pointer is passed to a *printf(3) routine on those systems that do not tolerate it (e.g. Solaris). But usually the bug disappears when __decreasing__ the log level, while -1 means all. p. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

15 years, 9 months

1
0
0 / 0

Re: (ITS#4986) manageDSAit might control cause problems in database selection

by hyc＠symas.com

hyc(a)symas.com wrote: > ando(a)sys-net.it wrote: >> A tentative fix is in HEAD (servers/slapd/backend.c 1.377 -> 1.378). >> >> Please test. > > Not entirely sure about that test myself. The original is rev 1.94 > > revision 1.94 > date: 2000/10/21 01:29:02; author: kurt; state: Exp; lines: +20 -7 > First-cut at manageDSAit-aware backend selection. > > Seems a bit unnecessary really. > Thinking back, I think the idea here is that you might have a set of nested databases connected by referral entries. E.g., database ldbm suffix dc=sub,dc=example,dc=com database ldbm suffix dc=example,dc=com If you had an referral entry in the superior DB that pointed to the sub database, you would need the manageDSAit control to be able to operate on the referral entry. None of this really makes sense post 2.1 since subordinate/glue makes it superfluous. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

15 years, 9 months

1
0
0 / 0

Re: (ITS#4986) manageDSAit might control cause problems in database selection

by hyc＠symas.com

ando(a)sys-net.it wrote: > A tentative fix is in HEAD (servers/slapd/backend.c 1.377 -> 1.378). > > Please test. Not entirely sure about that test myself. The original is rev 1.94 revision 1.94 date: 2000/10/21 01:29:02; author: kurt; state: Exp; lines: +20 -7 First-cut at manageDSAit-aware backend selection. Seems a bit unnecessary really. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

15 years, 9 months

1
0
0 / 0

Re: (ITS#5024) Disabling pagedResults advertisements

by hyc＠symas.com

v_orgos(a)yahoo.com.au wrote: > Full_Name: Vic Orgos > Version: 2.2.13 > OS: RHEL4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (61.9.136.163) > I really do not want to have to maintain a custom RPM or have to patch RedHat's > everytime there is an update/security patch. 2.2.13 was obsoleted years ago. If you can't get adequate support from RedHat then you should upgrade to a current release. This ITS will be closed. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

15 years, 9 months

1
0
0 / 0

(ITS#5024) Disabling pagedResults advertisements

by v_orgos＠yahoo.com.au

Full_Name: Vic Orgos Version: 2.2.13 OS: RHEL4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (61.9.136.163) Hi, I am upgrading from 2.0.xx (RHEL3) to 2.2.13 on RHEL4. Outlook 2003 clients have been using the old ldap server with no issues at all but during testing on the new RHEL4 test server I've come across the problem discussed at http://www.openldap.org/lists/openldap-software/200408/msg00298.html As suggested I've tried to stop it advertising pagedResults but it does not work. I've tried access to dn.exact="" filter="(supportedControl=1.2.840.113556.1.4.319)" by * none but this does not work and I've tried ccess to dn.exact="" attrs=supportedControl val=1.2.840.113556.1.4.319 by * none which seg faults. I would appreciate if you would provide me with the correct syntax or some means to allow Outlook to work correctly. I really do not want to have to maintain a custom RPM or have to patch RedHat's everytime there is an update/security patch. Thank you for your time. Vic.

15 years, 9 months

1
0
0 / 0

(ITS#5023) ldappasswd crash consumer slapd with some loglevels

by gao＠schrodinger.com

Full_Name: Simon Gao Version: 2.3.35 OS: Gentoo Linux 2007.0 kernel 2.6.16 URL: ftp://ftp.schrodinger.com/support/openldap/simon.gao.openldap_20070618.ext Submission from: (NULL) (192.156.98.12) When following command against a consumer slapd, it will crash slapd of the consumer when loglevel is set to any other value other than 1 or -1 on the consumer: ldappasswd -v -H ldap://consumer -D "uid=joe,ou=people,dc=example,dc=com" -W -S -x -A The crash happens to at least to loglevel 0, 256, 512. When loglevel is set to 1 or "-1", then no crash is experienced. In addition, when run consumer slapd manually as front process, then all debug level works without problem. Please check attached ftp link for detailed logs and information.

15 years, 9 months

1
0
0 / 0

(ITS#5022) ldappasswd crash consumer slapd with some loglevels

by gao＠schrodinger.com

Full_Name: Simon Gao Version: 2.3.35 OS: Gentoo Linux 2007.0 kernel 2.6.16 URL: ftp://ftp.schrodinger.com/support/openldap/simon.gao.openldap_2.3.35.its.ext Submission from: (NULL) (192.156.98.12) When following command against a consumer slapd, it will crash slapd of the consumer when loglevel is set to any other value other than 1 or -1 on the consumer: ldappasswd -v -H ldap://consumer -D "uid=joe,ou=people,dc=example,dc=com" -W -S -x -A The crash happens to at least to loglevel 0, 256, 512. When loglevel is set to 1 or "-1", then no crash is experienced. In addition, when run consumer slapd manually as front process, then all debug level works without problem. Please check attached ftp link for detailed logs and information.

15 years, 9 months

1
0
0 / 0

Re: (ITS#4995) SampleLDAP.pm w/back_perl appears to be broken

by h.b.furuseth＠usit.uio.no

We've clarified the usage text in SampleLDAP.py. -- Hallvard

15 years, 9 months

1
0
0 / 0

Re: (ITS#5021) test021-certificate fails on HP-UX

by h.b.furuseth＠usit.uio.no

Howard Chu writes: > Are you using the same version of OpenSSL on your other test machines? > Have you tried a newer version? Yes, and not yet. > (...) But at the moment this seems to be an OpenSSL problem, in which > case we can close this ITS. Yes, or put it on Feedback. I'll have a closer look at this eventually, but just compiling OpenSSL on that HP box takes ages. Don't hold RE23 for this. -- Regards, Hallvard

15 years, 9 months

1
0
0 / 0

Re: (ITS#5021) test021-certificate fails on HP-UX

by hyc＠symas.com

h.b.furuseth(a)usit.uio.no wrote: > Bug in OpenSSL 0.9.7d - unless it's with how OpenLDAP uses it, I don't > know. Are you using the same version of OpenSSL on your other test machines? Have you tried a newer version? Makes sense that this wouldn't be a problem in HEAD since we're now using liblber for certificate handling. I suppose we could patch RE23 to use ber_get_int for the serial number. But at the moment this seems to be an OpenSSL problem, in which case we can close this ITS. > The offending operation (on Jennifer Smith) adds one certificate and > deletes the old one. However the added and the old certificate compare > equal because certificateExactNormalize() produces the same string for > both: > 0$email=ca(a)example.com,cn=example ca, > o=openldap example\2C ltd.,st=california,c=us > > That's because i2s_ASN1_INTEGER(0, sn ) in certificateExactNormalize() > returns serial number "0". The inputs to that function are > (gdb) p *sn > $6 = {length = 1, type = 2, data = 0x402e5278 "\003", flags = 0} > and > (gdb) p *sn > $8 = {length = 1, type = 2, data = 0x402e5cf0 "\001xample.@\036", flags = 0} > Those *sn values are the same as on a successful run on Linux, except > the 2nd data[1...] (the xample... string) which I presume does not > matter when length=1. > > The input certificates ('val' arg to certificateExactNormalize()) are > correct. > -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

15 years, 9 months

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs June 2007