openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

(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

Re: ITS#6439
by h.b.furuseth＠usit.uio.no 06 Jan '10

06 Jan '10

j(a)gropefruit.com writes: > On Jan 5, 2010, at 12:56 , Hallvard B Furuseth wrote: >> Are they saying it somewhere public? I'm sure there are some OpenLDAP >> things they disagree with (I do too), but on this, RFC 4512 section 5.1 >> is quite clear, not to say loud: >> >> "The root DSE SHALL NOT be included if the client performs a subtree >> search starting from the root." > > I appreciate what you're trying to say, but let me be clear about > something. USERS do not care about RFCs. Yes, that's why I asked where they were saying it, to talk with them directly without you caught in the middle... > Fortunately, I have a solution. I was surgical in whom I was going to > argue with. I chose to argue with SUN and denounce their crappy > software. They too touted RFC this and RFC that. I told them to shove > their RFCs somewhere long and narrow. As a result, they ADMIT that its > wrong and they're going to issue a BACKPORT for my situation. Which > should have been done to begin with. Thank you. -- Hallvard

1 0

Re: (ITS#6439) rootDSE access method question
by j＠gropefruit.com 05 Jan '10

05 Jan '10

ldapclient is also used to initialize system-wide configuration of a = solaris box involving LDAP. You pass it the basic parameters needed to = perform LDAP lookups of users, groups, etc., and it generates the system = configuration. This is the message me and my associates have gathered = after all the reading we have done. (Note: This is also "similar" to the = way RedHat's LDAP configuration tool (system-config-authentication) = works, in that parameters are passed from the command line, into a = parser, which then edits files and then initialized the configuration.) Solaris 10's system, even when explicitly told to BIND WITH A PROXY USER = and NOT ANONYMOUSLY, it insists on binding anonymously. --> Our OpenLDAP system does not permit anonymous binds. This is by = design and I will not budge on this. <-- When we try to initialize ldapclient using the automatic config, it = tries to download a profile (which we have ready and waiting in our DIT) = to configure the local system - unfortunately, since its binding = anonymously, this fails. So our remaining option is to use the ldapclient utility with the MANUAL = config option, where we DON'T use a profile, rather we pass the needed = parameters to it manually, on the command line . When we configure this manually and execute the configuration changes, = we see in our slapd logs an attempt to talk to our system looking for = the supportedControl and supportedSASLMechanisms attributes -- which are = only available in the rootDSE. Unfortunately, this process uses every = scope EXCEPT base, which is the only scope that allows rootDSE to be = queried. Furthermore, I got them to admit that the very act of looking for SASL = entries when doing a SIMPLE BIND config is retarded. They agreed. So we have a few issues on Solaris' side: * Superfluous SASL queries, even in SIMPLE config. * Lack of base scope makes rootDSE query impossible * Client insists on binding anonymously, even when told NOT to They have offered to fix these things, I'm waiting on them now ... The important thing is that our slapd config is not to blame, as = everything else in our infrastructure that uses the DS system I built is = working nicely. J Solaris 10's system implicitly tries to perform=20 On Jan 5, 2010, at 15:05 , Howard Chu wrote: > j(a)gropefruit.com wrote: >> Full_Name: J >> Version: 2.4.20 >> OS: Debian-Lenny/amd64 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (68.15.14.98) >>=20 >>=20 >> Certain clients (for example, a Solaris 10 host) need to query the = rootDSE of >> our OpenLDAP server. Unfortunately, due to the way their client = software is >> written, the Solaris 10 client will only be able to attempt to view = the rootDSE >> using a scope of ONELEVEL or SUBTREE - it does not support BASELEVEL = searches of >> the rootDSE. >>=20 >> Solaris 10's 'ldapsearch' allows manual querying of our rootDSE for >> testing-purposes, so I know otherwise things should work (ACL-wise, = etc). It >> just seems to be a problem in the system-config, as the man page = clearly states >> that only the two aforementioned scopes are allowed. >>=20 >> Options? Is there a way I can alias a DN-less object? If so, is this = even >> advisable?=20 >>=20 >> Or, perhaps is there a way to store an alternate copy of the rootDSE = somewhere >> that is more "conventionally" accessible? >>=20 >> At this point, I'll consider any alternative. I reviewed the manpage = for >> slapd.conf, however the rootDSE parameter in slapd.conf seems to be = only used >> for "additions" or supplemental changes to an existing rootDSE. >=20 > Since you quoted the ldapclient docs, I have to ask what exactly = you're trying > to accomplish. Solaris ldapclient is only used to configure NSS, and = there are > no NSS tables that serve anything that could be extracted from an LDAP > server's rootDSE. What are you really trying to do? >=20 > --=20 > -- 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#6439) rootDSE access method question
by hyc＠symas.com 05 Jan '10

05 Jan '10

j(a)gropefruit.com wrote: > Full_Name: J > Version: 2.4.20 > OS: Debian-Lenny/amd64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (68.15.14.98) > > > Certain clients (for example, a Solaris 10 host) need to query the rootDSE of > our OpenLDAP server. Unfortunately, due to the way their client software is > written, the Solaris 10 client will only be able to attempt to view the rootDSE > using a scope of ONELEVEL or SUBTREE - it does not support BASELEVEL searches of > the rootDSE. > > Solaris 10's 'ldapsearch' allows manual querying of our rootDSE for > testing-purposes, so I know otherwise things should work (ACL-wise, etc). It > just seems to be a problem in the system-config, as the man page clearly states > that only the two aforementioned scopes are allowed. > > Options? Is there a way I can alias a DN-less object? If so, is this even > advisable? > > Or, perhaps is there a way to store an alternate copy of the rootDSE somewhere > that is more "conventionally" accessible? > > At this point, I'll consider any alternative. I reviewed the manpage for > slapd.conf, however the rootDSE parameter in slapd.conf seems to be only used > for "additions" or supplemental changes to an existing rootDSE. Since you quoted the ldapclient docs, I have to ask what exactly you're trying to accomplish. Solaris ldapclient is only used to configure NSS, and there are no NSS tables that serve anything that could be extracted from an LDAP server's rootDSE. What are you really trying to do? -- -- 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#6322) slapd suddenly stops working, and starts using 100% CPU
by quanah＠zimbra.com 05 Jan '10

05 Jan '10

--On Tuesday, January 05, 2010 1:39 PM -0800 Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Wednesday, December 30, 2009 1:09 PM +0000 helge(a)monsternett.no > wrote: > >> On Wed, Dec 30, 2009 at 09:04:12AM +0100, Helge Milde wrote: >>> I just enabled trace loglevel, perhaps that might give us a clue on >>> what's going on. >> >> Slapd just stopped working again. Here's the (annotated) log for viewing >> and/or downloading: http://www.pastie.org/761198.txt >> >> Does this give you any clues? >> >> Tell me if I can do anything else to help. > > A fix for this has been committed to HEAD. You can apply it to the > latest source (2.4.21) if you would like to try it out: > > <http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/daemon.c.diff?hid > eattic=1&r1=text&tr1=1.442&r2=text&tr2=1.443&f=u> Hm, correction, it fixes a minor shutdown issue, not your main issue. :/ --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

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