openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#6476) Failure to delete entry with multi-master replication
by piotr.tarnowski＠us.edu.pl 13 Dec '10

13 Dec '10

Hi! We have observed similiar symptoms with OpenLDAP 2.4.23: 2010-12-10T14:56:45+01:00 ldapst2/192.168.10.48 slapd[29363]: [ID 502419 local4.debug] Entry uid=Replicator,dc=us,dc=edu,dc=pl CSN 2 0101208130342.415481Z#000000#008#000000 older or equal to ctx 20101208130342.415481Z#000000#008#000000 2010-12-10T14:56:45+01:00 ldapst2/192.168.10.48 slapd[29363]: [ID 653192 local4.debug] syncprov_search_response: cookie=rid=008,sid= 008,csn=20101202144622.962136Z#000000#007#000000;20101001125631.576652Z#000000#003#000000;20101210135344.096897Z#000000#008#000000 do you have any fixes? Regards -- [ Piotr Tarnowski piotr.tarnowski(a)us.edu.pl ] [ Unix Administrator, University of Silesia, Katowice, Poland ]

1 0

Re: (ITS#6731) Scrambled error strings from back-ldif
by h.b.furuseth＠usit.uio.no 13 Dec '10

13 Dec '10

Howard Chu writes: > It is not an error in ldif_back_add() since rs->sr_text is only used by > send_ldap_result(). Its value upon return from ldif_back_add is irrelevant. Should have been true but isn't - a number of modules reuse SlapReply variables without clearing them:-( -- Hallvard

1 0

Re: (ITS#6660) paged result searches fail to deallocate memory until slapd shutdown
by h.b.furuseth＠usit.uio.no 13 Dec '10

13 Dec '10

I suppose it could be old misnamed ITS#5340. If so, try http://folk.uio.no/hbf/OpenLDAP/slapreply-draft3.diff Compile with CPPFLAGS="-DRS_USE_ASSERT=0". If that helps, the patch needs to work without the CPPFLAGS, but the asserts may be overeager. -- Hallvard

1 0

Re: (ITS#6716) syncprov sessionlog 'sl_mincsn' not assigned a value.
by rein＠OpenLDAP.org 12 Dec '10

12 Dec '10

On 11/19/10 23:55 , cmikk(a)qwest.net wrote: > will evaluate to true in cases where it should not. A quick fix would be to > compare directly against the CSN of the sessionlog's head: An extended version of this fix, which also ensures that the sessionlog is kept in csn order, is now in head. Please test, syncprov.c revision 1.320. Rein

1 0

Re: (ITS#6744) memory leak when chasing referrals
by arthur＠arthurdejong.org 11 Dec '10

11 Dec '10

--=-dGqU1ahV0Ya5KsADLt/0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2010-12-10 at 19:52 -0800, Howard Chu wrote: > Thanks, reproduced using ldapsearch. Fixed in HEAD. Thanks for the quick response and fix! --=20 -- arthur - arthur(a)arthurdejong.org - http://arthurdejong.org -- --=-dGqU1ahV0Ya5KsADLt/0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAABAgAGBQJNA/gRAAoJECqLdGgQ4K/B3hQP+wbUpmAAws3D7aobKrff+lm1 fe6Bl2kSh/xr7YJptDHQsQf0u7ZfuWPBY7Jm/VYR6vjBqfn2do2J4yZL2yKbkKJS Js9ir23JBgg5hv/qi9c64uA85GTU0NPex7PcWP45y5Y95ZBtDsdGBzvuoePwGCvn Wkb3dNY1Cl6MDL77CZPyoy1qKRHWcWPfVONhbLkQ5LF2BuDPV1dXjFSV1mqRTbLr JXqn1QKYrdRhHhIkZsdXs8RmdtWZ+43lZyqpF2jGtLR3iP8e55kPluih35Mp/fWM 1L/dVYjQO8sV54b1UPGJKAIDHoqacXhRgCZgRTJxQZy3GJ8eKmuM7G4O71TpYuX5 AoxXDcuSOuBY7qDFfTUkICujNDWHXQ0C4/nzN6owyPc5TneXGeJYMgzmyctZb5et jhLwAuS2kwDGNL46XxyuGSF+cDSEeEFxpewo61cXFB/gp2+469MCWfoyWtyp/LHV MZwpTAz9B0FvDjPMOMqd91h4O1WZIxBBo61FnL2iPWD/pNHrmQXlTTQ/y/WMHIXg bWkjqbnT8Qi1PpFYgvo2u+6oe1U4tV6aNRwioQjVyVi8lK+tyC9EL+tJfAGq5f7H JqOZj37PJ5qd26DUU6q2vX7r7RO7wX8TraP0/Kafvg2FnVk+9G+1LSdmjwzviPBp 32EBHtl1GZlq7rP4Q+zm =74Se -----END PGP SIGNATURE----- --=-dGqU1ahV0Ya5KsADLt/0--

1 0

Re: (ITS#6714) Patch - Mozilla NSS - implement full non-blocking semantics
by hyc＠symas.com 10 Dec '10

10 Dec '10

rmeggins(a)redhat.com wrote: > I "rebased" the patch on top of a recent change: > revision 1.24 > date: 2010/12/06 10:31:59; author: hallvard; state: Exp; lines: +5 -17 > ITS#6625 Remove some LDAP_R_COMPILEs I didn't quite understand the point of the discussion of SSLv2 clients in the comments on this patch, but committed it anyway. I would hope that nobody is still using SSLv2 these days. Also if a StartTLS request fails, then the rest of the code in tlsm.c should never even be reached; the TLS sockbuf layer wouldn't be installed. > The new patch is here: > ftp://ftp.openldap.org/incoming/openldap-2.4.23-use-non-blocking-semantics-… > > This patch file is derived from OpenLDAP Software. All of the > modifications to OpenLDAP Software represented in the following > patch(es) were developed by Red Hat. Red Hat has not assigned rights > and/or interest in this work to any party. I, Rich Megginson am > authorized by Red Hat, my employer, to release this work under the > following terms. > > Red Hat hereby place the following modifications to OpenLDAP Software > (and only these modifications) into the public domain. Hence, these > modifications may be freely used and/or redistributed for any purpose > with or without attribution and/or other notice. > > > > -- -- 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#6744) memory leak when chasing referrals
by hyc＠symas.com 10 Dec '10

10 Dec '10

arthur(a)arthurdejong.org wrote: > Full_Name: Arthur de Jong > Version: 2.4.23 > OS: Debian > URL: > Submission from: (NULL) (2001:888:1613:0:218:8bff:fe55:2c9f) > > > There seems to be a memory leak in the LDAP client library when casing > referrals. When the code below is run through valgrind it reports: > > ==30395== 4,184 (80 direct, 4,104 indirect) bytes in 1 blocks are definitely > lost in loss record 3 of 3 > ==30395== at 0x402328F: calloc (vg_replace_malloc.c:467) > ==30395== by 0x41D2CDF: ber_memcalloc_x (in /usr/lib/liblber-2.4.so.2.5.6) > ==30395== by 0x40650A0: ldap_send_server_request (in > /usr/lib/libldap_r-2.4.so.2.5.6) > ==30395== by 0x4065EB1: ldap_chase_v3referrals (in > /usr/lib/libldap_r-2.4.so.2.5.6) > ==30395== by 0x40510A3: ldap_result (in /usr/lib/libldap_r-2.4.so.2.5.6) > ==30395== by 0x8048871: main (test.c:28) > > The code below is not very pretty (does not include error handling) but should > free all returned buffers. I can also reproduce the above leak with the > ldapsearch command-line tool. Thanks, reproduced using ldapsearch. Fixed in 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#6238) contrib: lastbind overlay to record timestamp of last successful bind
by Kurt＠OpenLDAP.org 10 Dec '10

10 Dec '10

On Dec 10, 2010, at 5:16 PM, Michael Str=F6der wrote: > Kurt(a)OpenLDAP.org wrote: >> ( 1.3.6.1.4.1.453.16.2.188 NAME 'authTimestamp' >> DESC 'last successful authentication using any method/mech' >> EQUALITY generalizedTimeMatch >> ORDERING generalizedTimeOrderingMatch >> SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 >> SINGLE-VALUE NO-USER-MODIFICATION USAGE dsaOperation ) >>=20 >> And we use this attribute in our configuration object to = enable/disable =3D >> (default disabled). >>=20 >> ( 1.3.6.1.4.1.453.16.2.189 NAME 'authTimestamps' >> DESC 'enable recording of last successful authentication using =3D= >> any method/mech' >> EQUALITY booleanMatch >> SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 >> SINGLE-VALUE USAGE dsaOperation ) >=20 > Hmm, isn't NAME of the second a little bit confusing since it sounds = like just > the plural of the first? Names should only be for the wire, the wire doesn't get confused. -- Kurt=

1 0

Re: (ITS#6238) contrib: lastbind overlay to record timestamp of last successful bind
by michael＠stroeder.com 10 Dec '10

10 Dec '10

Kurt(a)OpenLDAP.org wrote: > ( 1.3.6.1.4.1.453.16.2.188 NAME 'authTimestamp' > DESC 'last successful authentication using any method/mech' > EQUALITY generalizedTimeMatch > ORDERING generalizedTimeOrderingMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 > SINGLE-VALUE NO-USER-MODIFICATION USAGE dsaOperation ) > > And we use this attribute in our configuration object to enable/disable = > (default disabled). > > ( 1.3.6.1.4.1.453.16.2.189 NAME 'authTimestamps' > DESC 'enable recording of last successful authentication using = > any method/mech' > EQUALITY booleanMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 > SINGLE-VALUE USAGE dsaOperation ) Hmm, isn't NAME of the second a little bit confusing since it sounds like just the plural of the first? Ciao, Michael.

1 0

Re: (ITS#6238) contrib: lastbind overlay to record timestamp of last successful bind
by Kurt＠OpenLDAP.org 10 Dec '10

10 Dec '10

On Dec 10, 2010, at 12:02 PM, Howard Chu wrote: > Good point. In that case it's probably fine as a separate overlay, the = way it is now. Can we use the schema definition that Isode is using? Not only yes, but hell yes. Reuse and convergence is a good thing. ( 1.3.6.1.4.1.453.16.2.188 NAME 'authTimestamp' DESC 'last successful authentication using any method/mech' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE NO-USER-MODIFICATION USAGE dsaOperation ) And we use this attribute in our configuration object to enable/disable = (default disabled). ( 1.3.6.1.4.1.453.16.2.189 NAME 'authTimestamps' DESC 'enable recording of last successful authentication using = any method/mech' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE USAGE dsaOperation )

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs