openldap-bugs January 2010

openldap-bugs@openldap.org

30 participants
86 discussions

(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

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs January 2010