- openldap-bugs - openldap.org

(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

Re: (ITS#6322) slapd suddenly stops working, and starts using 100% CPU
by quanah＠zimbra.com 05 Jan '10

05 Jan '10

--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?hideat…> --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: ITS#6439
by j＠gropefruit.com 05 Jan '10

05 Jan '10

--Apple-Mail-21-951114980 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jan 5, 2010, at 12:56 , Hallvard B Furuseth wrote: > j(a)telepaths.org writes: >> For compatibility reasons, It may well be in OpenLDAP's best interest = to >> provide options such as the ones I described previously, for "broken" = or >> "substandard" clients such as the ones I am using. >=20 I do not program. > If someone (you?) cares enough, they can write an overlay to > the OpenLDAP slapd frontend which intercepts searches with > (baseObject=3D"", scope=3DwholeSubtree) and changes the scope of > the operation to baseObject. That shouldn't be much code. >=20 Thats an interesting idea nonetheless, thanks. > A server using this overlay must not have a database with suffix "", > since this would break subtree searches in that database. >=20 >> I will point out that Solaris 11 doesn't exhibit these issues ---- = But >> my company wants to use Solaris 10, which leaves me in the middle of = a >> finger pointing party between OPENLDAP and SUN. So you can = understand >> why I might be asking for something as strange as this .... >>=20 >> SUN says OpenLDAP's standard/methods are questionable & strange.=20 >> OpenLDAP says Sun's client is broken and that we should hack it. I = say >> screw Solaris 10. >=20 No this is a commercial support issue I am working on. I doubt its being = publicized anywhere. > 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: >=20 > "The root DSE SHALL NOT be included if the client performs a subtree > search starting from the root." >=20 I appreciate what you're trying to say, but let me be clear about = something. USERS do not care about RFCs. Even some Administrators, = like me, don't care! We are too busy trying to make stuff work, rather = that having a debate with the makers of software as to what rules they = should be following. 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. Nevertheless, as I said earlier, OpenLDAP (like many other high and = mighty open source systems) should continue to follow RFCs like always. = But it won't kill anyone to offer alternatives that do NOT involve = reaching deep into the bowels of code we don't understand. Even if the = solutions are bizarre, someone out there is wasting hours and hours = trying to make his own solution work, and would be delighted to find = something native had been implemented. > (Onelevel search is not relevant in this context since it wouldn't > return the baseobject anyway.) >=20 Thanks for your input. > --=20 > Hallvard --Apple-Mail-21-951114980 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii <html><head></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; = "><br><div><div>On Jan 5, 2010, at 12:56 , Hallvard B Furuseth = wrote:</div><br class=3D"Apple-interchange-newline"><blockquote = type=3D"cite"><div><a href=3D"mailto:j@telepaths.org">j(a)telepaths.org</a> = writes:<br><blockquote type=3D"cite">For compatibility reasons, It may = well be in OpenLDAP's best interest to<br></blockquote><blockquote = type=3D"cite">provide options such as the ones I described previously, = for "broken" or<br></blockquote><blockquote type=3D"cite">"substandard" = clients such as the ones I am = using.<br></blockquote><br></div></blockquote><div><br></div><div>I do = not program.</div><br><blockquote type=3D"cite"><div>If someone (you?) = cares enough, they can write an overlay to<br>the OpenLDAP slapd = frontend which intercepts searches with<br>(baseObject=3D"", = scope=3DwholeSubtree) and changes the scope of<br>the operation to = baseObject.  That shouldn't be much = code.<br><br></div></blockquote><div><br></div><div>Thats an interesting = idea nonetheless, thanks.</div><br><blockquote type=3D"cite"><div>A = server using this overlay must not have a database with suffix = "",<br>since this would break subtree searches in that = database.<br><br><blockquote type=3D"cite">I will point out that Solaris = 11 doesn't exhibit these issues ---- But<br></blockquote><blockquote = type=3D"cite">my company wants to use Solaris 10, which leaves me in the = middle of a<br></blockquote><blockquote type=3D"cite">finger pointing = party between OPENLDAP and SUN.  So you can = understand<br></blockquote><blockquote type=3D"cite">why I might be = asking for something as strange as this ....<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">SUN says = OpenLDAP's standard/methods are questionable & strange. = <br></blockquote><blockquote type=3D"cite">OpenLDAP says Sun's client is = broken and that we should hack it.   I = say<br></blockquote><blockquote type=3D"cite">screw Solaris = 10.<br></blockquote><br></div></blockquote><div><br></div><div>No this = is a commercial support issue I am working on. I doubt its being = publicized anywhere.</div><br><blockquote type=3D"cite"><div>Are they = saying it somewhere public?  I'm sure there are some = OpenLDAP<br>things they disagree with (I do too), but on this, RFC 4512 = section 5.1<br>is quite clear, not to say = loud:<br><br></div></blockquote><blockquote = type=3D"cite"><div>  "The root DSE SHALL NOT be included if = the client performs a subtree<br>   search starting from the = root."<br><font class=3D"Apple-style-span" color=3D"#000000"><font = class=3D"Apple-style-span" = color=3D"#144FAE"><br></font></font></div></blockquote><div><br></div><div= ><div>I appreciate what you're trying to say, but let me be clear about = something.  USERS do not care about RFCs.  Even some = Administrators, like me, don't care! We are too busy trying to make = stuff work, rather that having a debate with the makers of software as = to what rules they should be = following.</div><div><br></div><div>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.</div><div><br></div><div>Nevertheless, as I said = earlier, OpenLDAP (like many other high and mighty open source systems) = should continue to follow RFCs like always.  But it won't kill = anyone to offer alternatives that do NOT involve reaching deep into the = bowels of code we don't understand.  Even if the solutions are = bizarre, someone out there is wasting hours and hours trying to make his = own solution work, and would be delighted to find something native had = been implemented.</div><div><br></div></div><blockquote = type=3D"cite"><div>(Onelevel search is not relevant in this context = since it wouldn't<br>return the baseobject = anyway.)<br><br></div></blockquote><div><br></div><div>Thanks for your = input.</div><br><blockquote type=3D"cite"><div>-- = <br>Hallvard<br></div></blockquote></div><br></body></html>= --Apple-Mail-21-951114980--

1 0

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

05 Jan '10

j(a)telepaths.org writes: > For compatibility reasons, It may well be in OpenLDAP's best interest to > provide options such as the ones I described previously, for "broken" or > "substandard" clients such as the ones I am using. If someone (you?) cares enough, they can write an overlay to the OpenLDAP slapd frontend which intercepts searches with (baseObject="", scope=wholeSubtree) and changes the scope of the operation to baseObject. That shouldn't be much code. A server using this overlay must not have a database with suffix "", since this would break subtree searches in that database. > I will point out that Solaris 11 doesn't exhibit these issues ---- But > my company wants to use Solaris 10, which leaves me in the middle of a > finger pointing party between OPENLDAP and SUN. So you can understand > why I might be asking for something as strange as this .... > > SUN says OpenLDAP's standard/methods are questionable & strange. > OpenLDAP says Sun's client is broken and that we should hack it. I say > screw Solaris 10. 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." (Onelevel search is not relevant in this context since it wouldn't return the baseobject anyway.) -- Hallvard

1 0

Re: ITS#6439
by masarati＠aero.polimi.it 05 Jan '10

05 Jan '10

> =46rom Solaris 10's 'ldapclient' manpage: > > defaultSearchScope=3Done | sub > > Specify the default search scope for the client's search > operations. This default can be overridden for a given > service by specifying a serviceSearchDescriptor. The > default is one level search. > > The parameter 'defaultSearchScope' only allows ONE or SUB. > > The 'serviceSearchDescriptor' is not an option, since this is designed = > to work with NSS objects like 'passwd', 'shadow', 'hosts', etc. rootDSE = > is not a service in that sense, so it won't work here. > > For compatibility reasons, It may well be in OpenLDAP's best interest to = > provide options such as the ones I described previously, for "broken" or = > "substandard" clients such as the ones I am using. > > I will point out that Solaris 11 doesn't exhibit these issues ---- But = > my company wants to use Solaris 10, which leaves me in the middle of a = > finger pointing party between OPENLDAP and SUN. So you can understand = > why I might be asking for something as strange as this .... > > SUN says OpenLDAP's standard/methods are questionable & strange. = > OpenLDAP says Sun's client is broken and that we should hack it. I say = > screw Solaris 10. OpenLDAP may be questionable & strange, I'm not going to debate it. But I pointed you to a RFC that clearly states what's the correct procedure to perform an operation. You're pointing me to the man page of a client that eventually got fixed across releases. If a client can't perform an operation dictated by an RFC, and pretends to do it another way, I'd call that "questionable & strange". > Thank you for your assistance. You can probably close this ticket. :) p.

1 0

Re: ITS#6439
by j＠telepaths.org 05 Jan '10

05 Jan '10

=46rom Solaris 10's 'ldapclient' manpage: defaultSearchScope=3Done | sub Specify the default search scope for the client's search operations. This default can be overridden for a given service by specifying a serviceSearchDescriptor. The default is one level search. The parameter 'defaultSearchScope' only allows ONE or SUB. The 'serviceSearchDescriptor' is not an option, since this is designed = to work with NSS objects like 'passwd', 'shadow', 'hosts', etc. rootDSE = is not a service in that sense, so it won't work here. For compatibility reasons, It may well be in OpenLDAP's best interest to = provide options such as the ones I described previously, for "broken" or = "substandard" clients such as the ones I am using. I will point out that Solaris 11 doesn't exhibit these issues ---- But = my company wants to use Solaris 10, which leaves me in the middle of a = finger pointing party between OPENLDAP and SUN. So you can understand = why I might be asking for something as strange as this .... SUN says OpenLDAP's standard/methods are questionable & strange. = OpenLDAP says Sun's client is broken and that we should hack it. I say = screw Solaris 10. Thank you for your assistance. You can probably close this ticket. J On Jan 5, 2010, at 10:05 , masarati(a)aero.polimi.it wrote: > The behavior you describe violates RFC 4512 (section 5.1), while = OpenLDAP > complies with it. Please note that the root DSE is accessed using a > plain, perfectly legal LDAP operation. The fact a client cannot be > configured to perform such a simple operation clearly indicates the = client > is broken. A quick answer would be "get the client fixed". >=20 > <advertisement> > I can imagine simple workarounds, consisting in few lines of code that > allow to circumvent the issue. They probably require to hire some = expert > consultant. > </advertisement> >=20 > p. >=20

1 0

ITS#6439
by masarati＠aero.polimi.it 05 Jan '10

05 Jan '10

The behavior you describe violates RFC 4512 (section 5.1), while OpenLDAP complies with it. Please note that the root DSE is accessed using a plain, perfectly legal LDAP operation. The fact a client cannot be configured to perform such a simple operation clearly indicates the client is broken. A quick answer would be "get the client fixed". <advertisement> I can imagine simple workarounds, consisting in few lines of code that allow to circumvent the issue. They probably require to hire some expert consultant. </advertisement> p.

1 0

(ITS#6440) slapcat could write info about how it was run in form of LDIF comments
by masarati＠aero.polimi.it 05 Jan '10

05 Jan '10

Full_Name: Pierangelo Masarati Version: irrelevant OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.149.38.230) Submitted by: ando Something like # slapcat run by <who>@<host> on <date> ... LDIF of database # number of entries, execution time, file size, ... For backward compatibility, this would need to be enabled by a specific switch. p.

1 0

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

05 Jan '10

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. Thanks J

1 0

Re: (ITS#6438) usage of invalid mutexint in syncprov
by hyc＠symas.com 04 Jan '10

04 Jan '10

Aaron Richton wrote: > *so = { > s_next = 0x54f778 > s_base = { > bv_len = 0 > bv_val = (nil) > } > s_eid = 2147483967U > s_op = (nil) > s_rid = -34707408 > s_sid = -32897008 > s_filterstr = { > bv_len = 0 > bv_val = (nil) > } > s_flags = 0 > s_inuse = -1 Looks like syncprov_free_syncop() was getting called twice while in the middle of freeing. A potential fix is 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#6438) usage of invalid mutexint in syncprov
by richton＠nbcs.rutgers.edu 04 Jan '10

04 Jan '10

*so = { s_next = 0x54f778 s_base = { bv_len = 0 bv_val = (nil) } s_eid = 2147483967U s_op = (nil) s_rid = -34707408 s_sid = -32897008 s_filterstr = { bv_len = 0 bv_val = (nil) } s_flags = 0 s_inuse = -1 s_res = 0x523120 s_restail = (nil) s_mutex = { __pthread_mutex_flags = { __pthread_mutex_flag1 = 0 __pthread_mutex_flag2 = '\0' __pthread_mutex_ceiling = '\0' __pthread_mutex_type = 82U __pthread_mutex_magic = 19800U } __pthread_mutex_lock = { __pthread_mutex_lock64 = { __pthread_mutex_pad = "" } __pthread_mutex_lock32 = { __pthread_ownerpid = 0 __pthread_lockword = 5392720U } __pthread_mutex_owner64 = 5392720ULL } __pthread_mutex_data = 0 } }

1 0

Re: (ITS#6438) usage of invalid mutexint in syncprov
by hyc＠symas.com 04 Jan '10

04 Jan '10

richton(a)nbcs.rutgers.edu wrote: > Backtrace: https://www.nbcs.rutgers.edu/~richton/openldap-6438-bt.txt So we passed a NULL pointer in here, odd. Thread 5 is the one that crashed; in frame 4 can you print *so ? -- -- 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#6438) usage of invalid mutexint in syncprov
by richton＠nbcs.rutgers.edu 04 Jan '10

04 Jan '10

Backtrace: https://www.nbcs.rutgers.edu/~richton/openldap-6438-bt.txt

1 0

(ITS#6438) usage of invalid mutexint in syncprov
by richton＠nbcs.rutgers.edu 04 Jan '10

04 Jan '10

Full_Name: Aaron Richton Version: RE24 20091217 (2.4.21) OS: Solaris 9 URL: :wq Submission from: (NULL) (128.6.31.135) dec_mutexint was called with a NULL parameter while running the test suite. Unfortunately, the only evidence of this is a core file.

1 0

Re: (ITS#6437) sl_malloc issues
by hyc＠symas.com 04 Jan '10

04 Jan '10

Hallvard B Furuseth wrote: > hyc(a)symas.com writes: >> Nobody uses the pool code. I would suggest you profile it against the stack >> code before spending any time fixing it. > > The pool version crashes if I divide SLAP_SLAB_SIZE by 16 or multiply > the allocated amounts by 17. The stack version stays happy. I also > tried RE23 and rev 1.48 in case of code rot. (Should have tried > OpenLDAP 2.2, but would need to install an old Berkeley DB.) Adding a > sl_malloc fallback to ch_malloc instead of returning NULL didn't help. > > Anyway, I tried this because I assume the pool version is intended to > reduce the number of sl_malloc fallbacks to ch_malloc, but that almost > never happens in 'make test' with the current SLAP_SLAB_SIZE. Which > made that aspect hard to test. > > Also the pool version does a number of ch_mallocs for administration and > ch_frees them at reset. If the idea is to reduce ch_mallocs, it should > keep these blocks around. (Or allocate them with the slab.) Except the > 'slab_object's It only needs cleanup if the slab size changes, which > slapd never seems to do. This stuff was originally written to grow the slab as needed, but it was also being very braindead and would have kept a lot of excess memory lying around so I dropped that. So right, currently the slab size doesn't change. -- -- 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#6432) PATCH: MozNSS crypto (tls_m.c) - support InitContext, improved PEM support
by rmeggins＠redhat.com 04 Jan '10

04 Jan '10

> > OK. Another question - you're only using NSS_InitContext() for client > initialization. Any particular reason not to always use it? > I had coded around a bug in NSS_InitContext that caused it not to work in server mode - the MozNSS guys are aware of this issue - I'm waiting on the fix. > Also in tlsm_ctx_free() is it safe to pass a NULL to NSS_ShutdownContext()? I > think these two lines should be enclosed in "if (c->tc_initctx) {}" I'll change it to check for NULL.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs