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
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
(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
(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
(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
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
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