openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

(ITS#6446) Quickstart guide only uses slapd.conf
by quanah＠OpenLDAP.org 07 Jan '10

07 Jan '10

Full_Name: Quanah Gibson-Mount Version: RE24 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) The quickstart guide on the OpenLDAP home page only references using slapd.conf. It has no references to the new config backend. Since slapd.conf is deprecated, it would be good to have a quickstart guide that reflected this.

1 0

(ITS#6445) Duplicate free with back-relay + passwd op
by h.b.furuseth＠usit.uio.no 07 Jan '10

07 Jan '10

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard HEAD configured with CPPFLAGS=-DSLAP_NO_SL_MALLOC ./run test030-relay with slapd under valgrind Bad frees of op->o_req_ndn.bv_val and op->o_req_dn.bv_val: Invalid slap_sl_free() by 0x4864F1: do_extended (extended.c:187) Address 0xd8853a0 is 0 bytes inside a block of size 62 free'd by 0x487DAC: passwd_extop (passwd.c:321) by 0x486712: fe_extended (extended.c:225) by 0x486491: do_extended (extended.c:180) Invalid slap_sl_free() by 0x486515: do_extended (extended.c:189) Address 0xd8855d0 is 0 bytes inside a block of size 62 free'd by 0x487DFF: passwd_extop (passwd.c:325) by 0x486712: fe_extended (extended.c:225) by 0x486491: do_extended (extended.c:180) The four backtraces are surrounded by: at 0x4A05A31: free (vg_replace_malloc.c:325) by 0x4E707E5: ber_memfree_x (memory.c:152) by 0x4B7157: slap_sl_free (sl_malloc.c:481) <...backtrace above...> by 0x4444F8: connection_operation (connection.c:1109) by 0x444A7D: connection_read_thread (connection.c:1245) by 0x4C1AFE2: ldap_int_thread_pool_wrapper (tpool.c:685)

1 0

(ITS#6444) OpenLDAP 2.5 RoadMap Question
by j＠gropefruit.com 06 Jan '10

06 Jan '10

Full_Name: J Version: 2.4.20 OS: Debian/Lenny-AMD64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (207.67.92.30) Please clarify this statement in your 2.5 roadmap: LDAPv3 extensions: *LDAP Transaction support Do you mean that SyncRepl will actually become legitimately enterprise-class, in that replication will work 100% of the time? Or does this mean transaction support for some other element unrelated to content synchronization? Why I ask: I've opened a few tickets on OpenLDAP in the past, related to replication issues involving multiple multimaster servers with a frontend employed (a hardware load balancer) to control writes. From time to time, it seems as though SyncRepl just "decides" to fail, and gives no indication ANYWHERE as to why. We log all sync activity, and we see no indication that the host is unreachable or down, and we see no performance delays when querying the DSAs manually. * All slapd servers' clocks are perfectly synchronized and are in a common time zone * Of all six multimasters, only two of them actually receive WRITES * All are 2.4.20 on amd64 kernel (Debian Lenny) * We see no discernible improvement when switching from refreshOnly to refreshAndPersist. Replication will work fine for awhile (in the most recent case, it worked for 16 days, having written test records ranging from 1000 to 50000 *repeatedly* without issues) and then just "fail" .... We have ruled out the following: * Bad hardware * slapd Configuration error (have posted our config before) * Firewall timeout issues for cross-site replication (a timeout wouldn't wait 16 days) * Firewall policies between sites (wouldn't cause it to work and then not work). * slapd segfaulting or crashing in some way This behavior is quite lackluster for a business environment and is ultimately insufficient for any legitimate application. As far as I am concerned, the results are so unbelievably inconsistent that this is an affront to the way SyncRepl is represented/advertised. If it NEVER worked at all, at least THAT would be consistent. SyncRepl rarely makes any valid attempt to "sync up" when differences are detected between DSAs - SOMETIMES it feels like it, most of the time it does not. I hate to say it, but SyncRepl is a huge pile of misrepresentation and broken promises. So: Is transaction support intended to SOLVE these issues? If not, maybe you should invent something to replace SyncRepl altogether. J

1 0

Re: (ITS#6443) test022-ppolicy failure
by hyc＠symas.com 06 Jan '10

06 Jan '10

richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: 2.4.21 > OS: CentOS 5.4 > URL: https://www.nbcs.rutgers.edu/~richton/openldap-testfail-20100106.tar.bz2 > Submission from: (NULL) (128.6.31.135) > > > During CentOS 5 x86_64 RPM build using the Buchan specfile: > >>>>>> Starting test022-ppolicy for bdb... > running defines.sh > Starting slapd on TCP/IP port 9065... > Using ldapsearch to check that slapd is running... > Using ldapadd to populate the database... > Testing account lockout... > Waiting 20 seconds for lockout to reset... > Testing password expiration > Waiting 20 seconds for password to expire... > Password expiration test failed >>>>>> ./scripts/test022-ppolicy failed for bdb (exit 1) > > and then everything exited clean. testrun directory attached. > > This is not reproducible; a subsequent rebuild from the same specfile on the > same hardware finished clean. Given that these expiration tests are timing dependent, not sure there's anything real to track down here. -- -- 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#6443) test022-ppolicy failure
by richton＠nbcs.rutgers.edu 06 Jan '10

06 Jan '10

Full_Name: Aaron Richton Version: 2.4.21 OS: CentOS 5.4 URL: https://www.nbcs.rutgers.edu/~richton/openldap-testfail-20100106.tar.bz2 Submission from: (NULL) (128.6.31.135) During CentOS 5 x86_64 RPM build using the Buchan specfile: >>>>> Starting test022-ppolicy for bdb... running defines.sh Starting slapd on TCP/IP port 9065... Using ldapsearch to check that slapd is running... Using ldapadd to populate the database... Testing account lockout... Waiting 20 seconds for lockout to reset... Testing password expiration Waiting 20 seconds for password to expire... Password expiration test failed >>>>> ./scripts/test022-ppolicy failed for bdb (exit 1) and then everything exited clean. testrun directory attached. This is not reproducible; a subsequent rebuild from the same specfile on the same hardware finished clean.

1 0

Re: (ITS#6442) slaptools iteration enhancement
by masarati＠aero.polimi.it 06 Jan '10

06 Jan '10

> masarati(a)aero.polimi.it writes: >> Both changes will cause binary incompatibility; the latter will not >> require to modify custom backends (I've already modified all the >> existing backends, exploiting in most cases the new feature; in >> back-bdb there is room for minimal improvement, as DN lookahead is >> relatively straightforward, so if base/scope is defined, but no >> filter, some advantages can be expected). > > Could you put them at the end of the tool_globals variable instead? > Then the binary incompatibility will only be in tool_globals, not in the > backend structure. I suppose this variant makes a bit a mess for glue > if nothing else - I assume it would need to to save/modify/restore such > global parameters. Slap tools could accept these parameters only for > backends which which set a flag to say they handle them. > > Might even put them in a mostly empty Operation in tool_globals. Some > backends may be able to reuse existing Search code that way, and other > search-like parameters could be added later if we want. However that > introduces incompatibility after all, so maybe that's for RE25. > '#define tv_sub_ndn tv_op.o_req_ndn' can handle source code compat. I don't think we'll ever need more than a subtree specification. In any case, I think passing those parameters as args rather than as global variables makes more sense. First of all, if you look at the patches, <ftp://ftp.openldap.org/incoming/slaptools-opt1.patch> <ftp://ftp.openldap.org/incoming/slaptools-opt2.patch> backglue is sort of a nightmare. And it doesn't deal yet with gluing backends that only support one of the methods. Second, I'd prefer backends not to know about tool global variables, for basic data isolation. Take it any way 'round, binary incompatibility arises. Option 2 avoids source incompatibility, that's basically what we need. I find it utopistic to expect binary compatibility within the whole life of a minor release. We never guaranteed that, although we tried to preserve it. p.

1 0

Re: (ITS#6442) slaptools iteration enhancement
by h.b.furuseth＠usit.uio.no 06 Jan '10

06 Jan '10

masarati(a)aero.polimi.it writes: > Both changes will cause binary incompatibility; the latter will not > require to modify custom backends (I've already modified all the > existing backends, exploiting in most cases the new feature; in > back-bdb there is room for minimal improvement, as DN lookahead is > relatively straightforward, so if base/scope is defined, but no > filter, some advantages can be expected). Could you put them at the end of the tool_globals variable instead? Then the binary incompatibility will only be in tool_globals, not in the backend structure. I suppose this variant makes a bit a mess for glue if nothing else - I assume it would need to to save/modify/restore such global parameters. Slap tools could accept these parameters only for backends which which set a flag to say they handle them. Might even put them in a mostly empty Operation in tool_globals. Some backends may be able to reuse existing Search code that way, and other search-like parameters could be added later if we want. However that introduces incompatibility after all, so maybe that's for RE25. '#define tv_sub_ndn tv_op.o_req_ndn' can handle source code compat. -- Hallvard

1 0

(ITS#6442) slaptools iteration enhancement
by masarati＠aero.polimi.it 06 Jan '10

06 Jan '10

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.149.38.230) Submitted by: ando I've modified bi_tool_entry_first(), the call that initiates an iteration in slaptools, to allow to pass a subtree, a scope and a filter. This allows backends to only return IDs of entries that meet the specification. Currently, slapcat and slapschema can do this check downstream. This makes sense with most backends, significantly with back-bdb/hdb. However, other backends, like back-ndb and back-sql, and custom or private ones, may be able to exploit this information. I have two variants: one adds three arguments to bi_tool_entry_first(), thus breaking existing custom backends. The other adds a new call bi_tool_entry_first_x(), leaving the existing one untouched. Both changes will cause binary incompatibility; the latter will not require to modify custom backends (I've already modified all the existing backends, exploiting in most cases the new feature; in back-bdb there is room for minimal improvement, as DN lookahead is relatively straightforward, so if base/scope is defined, but no filter, some advantages can be expected). I'd be happy to receive further comments before I proceed with the commit. p.

1 0

Re: (ITS#6411) Possible bug in Overlay pPolicy
by jarbas.junior＠gmail.com 06 Jan '10

06 Jan '10

Please close this its. In 2.4.21 Version works fine. Tanks Jarbas 2009/12/3 Jarbas Peixoto J=FAnior <jarbas.junior(a)gmail.com>: > Attached to the configuration file server testing openldap squeeze. > > I made some changes to the file /etc/ldap/slapd.overlay.conf being > included by /etc/ldap/slapd.conf and discovered that the problem is > with the overlay rwm, because when I comment that overlay the problem > does not appear. > > If I keep the following entries rwm overlay the problem happen again: > > moduleload rwm > overlay rwm > > Even with the other settings overlay rwm commented the problem continues. > > Any ideas? > > > 2009/12/2 Howard Chu <hyc(a)symas.com>: >> jarbas.junior(a)gmail.com wrote: >>> >>> Full_Name: Jarbas Peixoto Junior >>> Version: 2.4.11 / 2.4.17 / 2.4.20 >>> OS: Gnu/Linux Debian >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (200.152.34.143) >>> >>> >>> Possible bug in Overlay pPolicy >>> >>> I have OpenLDAP installed via the Debian Lenny package functioning >>> normally. >>> >>> Aiming to test the version of Debian Squeeze in the test machine instal= led >>> package slapd (2.4.17-2.1) with the same set of Debian Lenny (2.4.11). >>> >>> However, when testing the overlay pPolicy noticed that a wrong password >>> authentication, runs all objects in the ldap database, causing a "delay= " >>> that >>> does not exist in version Lenny. >>> >>> Below is some information that may be useful in detecting the problem: >>> >>> File: slapd.conf >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> moduleload =A0 =A0 =A0ppolicy >>> overlay ppolicy >>> ppolicy_default >>> "cn=3Ddefault,ou=3DLdapPassword,ou=3DPoliticas,ou=3DBuiltin,dc=3Dprevid= encia,dc=3Dgov,dc=3Dbr" >>> ppolicy_use_lockout >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>> ldapsearch -LLL -x -H ldap://squeeze -b >>> ou=3DLdapPassword,ou=3DPoliticas,ou=3DBuiltin,dc=3Dprevidencia,dc=3Dgov= ,dc=3Dbr >>> '(cn=3Ddefault)' >>> dn: >>> cn=3Ddefault,ou=3DLdapPassword,ou=3DPoliticas,ou=3DBuiltin,dc=3Dprevide= ncia,dc=3Dgov,d >>> =A0c=3Dbr >>> objectClass: top >>> objectClass: device >>> objectClass: pwdPolicy >>> pwdAttribute: userPassword >>> description:: >>> UG9sw610aWNhIGRlIFNlbmhhIERlZmF1bHQgcGFyYSB0b2RvcyB1c3XDoXJpb3M=3D >>> pwdAllowUserChange: TRUE >>> pwdFailureCountInterval: 3600 >>> pwdGraceAuthNLimit: 5 >>> pwdInHistory: 0 >>> pwdLockoutDuration: 60 >>> pwdMaxAge: 7776000 >>> pwdMinAge: 0 >>> pwdMinLength: 6 >>> pwdSafeModify: FALSE >>> pwdCheckQuality: 1 >>> pwdExpireWarning: 600 >>> cn: default >>> pwdMustChange: FALSE >>> pwdMaxFailure: 10 >>> pwdLockout: FALSE >>> >>> date ; ldapsearch -LLL -x -H ldap://squeeze -b >>> ou=3Dusuarios,dc=3Dprevidencia,dc=3Dgov,dc=3Dbr -D >>> uid=3Djarbas.peixoto,ou=3Dpessoas,ou=3Dusuarios,dc=3Dprevidencia,dc=3Dg= ov,dc=3Dbr -w >>> wrong-password '(uid=3Djarbas.peixoto)' cn mail pwdFailureTime >>> pwdAccountLockedTime modifyTimeStamp ; date >>> Qua Dez =A02 16:14:56 AMST 2009 >>> ldap_bind: Invalid credentials (49) >>> Qua Dez =A02 16:15:36 AMST 2009 >>> >>> grep 'access_allowed: search access to' /var/log/debug | wc -l >>> 83714 >>> >>> The question is: why access all entries in LDAP? >> >> Don't know. This would have to be the result of a search operation, but >> there is no search code in ppolicy.c. Since ppolicy cannot be the culpri= t, >> we'll need to see the rest of your config to track down the issue. >> >> -- >> =A0-- Howard Chu >> =A0CTO, Symas Corp. =A0 =A0 =A0 =A0 =A0 http://www.symas.com >> =A0Director, Highland Sun =A0 =A0 http://highlandsun.com/hyc/ >> =A0Chief Architect, OpenLDAP =A0http://www.openldap.org/project/ >> >

1 0

(ITS#6441) auxprop_lookup in cyrus-sasl 2.1.24 returns status
by rein＠OpenLDAP.org 06 Jan '10

06 Jan '10

Full_Name: Rein Tollevik Version: CVS HEAD OS: Irrelevant URL: Submission from: (NULL) (2a01:600:0:1:21c:23ff:feab:61cd) Submitted by: rein The upcoming 2.1.24 release of cyrus-sasl have changed the auxprop_lookup plugin from void to returning a status value. A patch that fixes it is coming. Rein Tollevik Basefarm AS

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