openldap-bugs

openldap-bugs@openldap.org

1 participants
21065 discussions

Re: (ITS#6322) slapd suddenly stops working, and starts using 100% CPU
by helge＠monsternett.no 30 Dec '09

30 Dec '09

On Tue, Dec 29, 2009 at 11:00:25AM -0800, Howard Chu wrote: >Sorry, your issue was closed since we hadn't received any feedback >from you in a couple of months. > >The last trace you sent shows nothing unusual, just a bunch of >threads all waiting to write on their respective connections. If the core dump backtrace wasn't helpful, then please tell me so; I thought I had given you sufficient feedback, and that you were working on it. >Have you tried the .21 release yet? No.. I might do that next week. Is there anything else that I can do? I just enabled trace loglevel, perhaps that might give us a clue on what's going on. >-- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ -- Helge Milde, 69701808 www.monsternett.no

1 0

(ITS#6247)
by daniel＠pluta.biz 29 Dec '09

29 Dec '09

Hi, I did just some small cleanups, but added no new functionality. I've extracted the minimalistic slapd-api modifications in an extra file called "now_slapd.patch" also contained in the tgz. The code compiles and runs against todays version of "HEAD". The new tgz-file can be downloaded from here: ftp://ftp.openldap.org/incoming/daniel-pluta-now-091229-1.tgz Cheers Daniel

1 0

Re: (ITS#6322) slapd suddenly stops working, and starts using 100% CPU
by hyc＠symas.com 29 Dec '09

29 Dec '09

helge(a)monsternett.no wrote: > Would be nice to get some feedback on this one.. > Were using a core dump sufficient? If so, was the information helpful at all? > If there's anything more I could do, please say so. > Sorry, your issue was closed since we hadn't received any feedback from you in a couple of months. The last trace you sent shows nothing unusual, just a bunch of threads all waiting to write on their respective connections. Have you tried the .21 release yet? -- -- 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 helge＠monsternett.no 29 Dec '09

29 Dec '09

Would be nice to get some feedback on this one.. Were using a core dump sufficient? If so, was the information helpful at all? If there's anything more I could do, please say so. -- Helge Milde, 69701808 www.monsternett.no

1 0

Re: (ITS#6194) Patch - Enhancement - provide LDIF support as libldif
by hyc＠symas.com 22 Dec '09

22 Dec '09

rmeggins(a)redhat.com wrote: > The ldif code does not currently have knowledge of any of the higher > level LDAP data types such as LDAPMod or LDAPControl - some of the > proposals would have the ldif API return these objects - Do we really > want to introduce this higher level knowledge into the relatively low > level libldif, along with the dependency on libldap? I think in order > to do this properly, we would have to introduce a new LDAP API e.g. > ldap_mods_from_ldif(const char *ldifstr, LDAPMod***, LDAPControl***) or > something like that - something that would parse the given ldif record > into those higher level data types. Should have mentioned this sooner; this ITS needs to be merged with ITS#4033. -- -- 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: Re : Re : ITS#6434
by masarati＠aero.polimi.it 22 Dec '09

22 Dec '09

KISTER RAPHAEL wrote: > I re-test with servers/slapd/overlays/rwm.c in version 1.125 and it works fine. I don't test with the next version. Fine. The other modifications are not strictly related to your issue, but rather to modifications to olcRwmMap using back-config. p.

1 0

Re : Re : ITS#6434
by kraph＠yahoo.com 22 Dec '09

22 Dec '09

Hello,=0A=0AI re-test with servers/slapd/overlays/rwm.c in version 1.125 an= d it works fine. I don't test with the next=A0version.=0A=0ARaphael KISTER= =0A=0A=0A

1 0

Re: (ITS#6435) Hidden schema elements
by michael＠stroeder.com 22 Dec '09

22 Dec '09

Kurt Zeilenga wrote: > On Dec 21, 2009, at 12:35 PM, Michael Ströder wrote: > >> Kurt(a)OpenLDAP.org wrote: >>> Yes, it has long been our practice not to publish schema elements which = >>> are not yet well standardized. This would include any element which = >>> carries a OpenLDAP.666 OID. >>> >>> The idea being that use of such attributes should be limited to early = >>> adopters and such. >> Sorry, but this practice is inconsequent. > > That's your opinion. My opinion is that we should avoid publishing > ''works in progress'' in production systems. Works in progress, by their > very nature, are subject to change without notice. If you'd really like to avoid issues with attributes being falsely handled by the client because the semantics changed you would especially also have to change the attribute type's NAME. Because that's what regular naive LDAP clients look for. A fully schema-aware client like web2ldap discovers OID changes and handles things correctly. E.g. in web2ldap plugins are preferrably registered by OID (besides some exceptions in case of missing schema descriptions). If the semantics changes and you assign a new OID web2ldap would not naively just treat it the same way. One has to explicitly register a plugin class for the new OID, off course after checking that semantics are the same then. Opposite to that if e.g. the semantics of entryCSN changes and you assign a new OID of a hidden schema description there's no chance to discover that. That's simply bad and therefore I won't follow your arguments at all. BTW: OpenLDAP also prefers NAME handling over OIDs. So with an OpenLDAP deployment changing the OID of a schema descriptions has no effect. But changing the NAME does. That's what I think is inconsequent: The current practice does not avoid issues. It only makes things worse. Ciao, Michael.

1 0

Re: (ITS#6435) Hidden schema elements
by Kurt＠OpenLDAP.org 21 Dec '09

21 Dec '09

On Dec 21, 2009, at 12:35 PM, Michael Str=F6der wrote: > Kurt(a)OpenLDAP.org wrote: >> Yes, it has long been our practice not to publish schema elements = which =3D >> are not yet well standardized. This would include any element which = =3D >> carries a OpenLDAP.666 OID. >>=20 >> The idea being that use of such attributes should be limited to early = =3D >> adopters and such. >=20 > Sorry, but this practice is inconsequent. That's your opinion. My opinion is that we should avoid publishing = ''works in progress'' in production systems. Works in progress, by = their very nature, are subject to change without notice. > The attributes are returned in LDAP > responses Generally because the client asked for more than it should have. = Clients really shouldn't generally be asking for * and/or +. The two exceptions are clients which are servers attempting to = server-to-server replication and clients operated by directory = administrators. Clients which are intended to support various user applications really = should ask only for what they designed to consume. > and therefore a client should be able to look up the attribute type > description in the schema e.g. to determine the syntax. I disagree. Schema may not be made available to the client for any = number of reasons. The X.500 and LDAP specifications allow for this. >=20 > Some of the OIDs are now with .666 for years. Each time this topic is = raised > nothing happens... That's because (in general) the ''works in progress'' have not be = finalized. If something hasn't changed in years, then maybe it's time = to finalize it and, in doing so, assign it final OID. -- Kurt=

1 0

Re: (ITS#6435) Hidden schema elements
by michael＠stroeder.com 21 Dec '09

21 Dec '09

Kurt(a)OpenLDAP.org wrote: > Yes, it has long been our practice not to publish schema elements which = > are not yet well standardized. This would include any element which = > carries a OpenLDAP.666 OID. > > The idea being that use of such attributes should be limited to early = > adopters and such. Sorry, but this practice is inconsequent. The attributes are returned in LDAP responses and therefore a client should be able to look up the attribute type description in the schema e.g. to determine the syntax. Some of the OIDs are now with .666 for years. Each time this topic is raised nothing happens... Ciao, Michael.

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