openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

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 05 Jan '10

05 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 05 Jan '10

05 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

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