openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

Re: (ITS#5593) Back-meta search references
by andrew.graham＠agustawestland.com 10 Jul '08

10 Jul '08

*** Before acting on this email or opening any attachment you are advised to read the disclaimer at the end of this email *** I patched the changes into 2.4.10 and it works perfectly. Will this make it into 2.4.11? If so what is the time frame for release? Thanks for such a fast response! Drew Andrew Graham AgustaWestland UK andrew.graham(a)agustawestland.com >>> <ando(a)sys-net.it> 07/07/2008 20:27 >>> andrew.graham(a)agustawestland.com wrote: > Please provide an option to stop search references being proxied from target to > client in back-meta. "norefs yes" added to HEAD (default "no"). Please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando(a)sys-net.it ----------------------------------- *** Disclaimer *** The information contained in this E-Mail and any subsequent correspondence may be subject to the Export Control Act (ECA) 2002. The content is private and is intended solely for the recipient(s). For those other than the recipient any disclosure, copying, distribution, or action taken, or omitted to be taken, in reliance on such information is prohibited and may be unlawful. If received in error please return to sender immediately. Under the laws of England misuse of information that is subject to the ECA 2002, is a criminal offence. Westland Helicopters Ltd Lysander Road Yeovil BA20 2YB England Registered in England under No 604352

1 0

Re: (ITS#5608) additional info: modify/delete: postalAddress: no equality matching rule
by ando＠sys-net.it 10 Jul '08

10 Jul '08

michael(a)stroeder.com wrote: > Kurt Zeilenga wrote: >> Declarations of schema elements should be published as specified in >> RFCs. [..] If caseIgnoreListMatch is not supported, than the >> MatchingRule definition for caseIgnoreListMatch should not be >> published. > > I suspected an answer like this. I've changed my code to also look up > whether the matching rule description itself exists but loose subschema > definitions like this makes it really hard to implement smarter > schema-aware clients. :-/ > > These kind of things would be interesting subjects of interop testing. > >> I note that the specification does allow publication of unimplemented >> descriptions. > > Even worse. :-( Aside from conformity of OpenLDAP's current behavior, I'd consider this ITS as a request to finally implement that matching rule. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5608) additional info: modify/delete: postalAddress: no equality matching rule
by michael＠stroeder.com 10 Jul '08

10 Jul '08

Kurt Zeilenga wrote: > The definitions themselves, such as for postalAddress, should be > generally viewed as immutable. Additionally if a local configuration differs from a RFC you might consider this to be bad practice. But thinking this to the end a server MAY then apply another matching rule to a given attribute type but keep the attribute type description as defined in the RFC. That's even worse because the server behaves differently but the client won't be able to find out. Very bad! Ciao, Michael.

1 0

Re: (ITS#5608) additional info: modify/delete: postalAddress: no equality matching rule
by michael＠stroeder.com 10 Jul '08

10 Jul '08

Kurt Zeilenga wrote: > Declarations of schema elements should be published as specified in > RFCs. [..] If caseIgnoreListMatch is not supported, than the > MatchingRule definition for caseIgnoreListMatch should not be > published. I suspected an answer like this. I've changed my code to also look up whether the matching rule description itself exists but loose subschema definitions like this makes it really hard to implement smarter schema-aware clients. :-/ These kind of things would be interesting subjects of interop testing. > I note that the specification does allow publication of unimplemented > descriptions. Even worse. :-( Ciao, Michael.

1 0

Re: (ITS#5608) additional info: modify/delete: postalAddress: no equality matching rule
by Kurt＠OpenLDAP.org 10 Jul '08

10 Jul '08

Declarations of schema elements should be published as specified in RFCs. RFC 4512: Servers SHOULD provide definitions of all schema elements they support in subschema (sub)entries. The definitions themselves, such as for postalAddress, should be generally viewed as immutable. Only certain additions (alternative names and extensions can be added, and DESC values changed. Matching rules should never be changed. > If the equality matching rule is not implemented it should not be announced in the subschema. Assuming you mean that the "EQUALITY caseIgnoreListMatch" should be removed, no. If caseIgnoreListMatch is not supported, than the MatchingRule definition for caseIgnoreListMatch should not be published. > The server should not simply report what might have been defined in some RFC. No. See above. I note that the specification does allow publication of unimplemented descriptions. It actually legal to publish caseIgnoreListMatch. But OpenLDAP has traditionally only published supported descriptions.

1 0

(ITS#5609) slapo-constraint with typ 'uri' rejects valid attribute values
by michael＠stroeder.com 10 Jul '08

10 Jul '08

Full_Name: Michael Ströder Version: HEAD OS: OpenSUSE Linux 10.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.78.239) Looking at the logs slapo-constraint seems to generate a filter which is considered bad by slapd: constraint_violation uri filter = (&((objectClass=organizationalUnit))(|(ou=Abteilung 1))) This filter would work and finds the correct entry containing the valid attribute value: (&(objectClass=organizationalUnit)(|(ou=Abteilung 1)))

1 0

Re: (ITS#5565) slapd crashes due to SIGPIPE
by quanah＠zimbra.com 09 Jul '08

09 Jul '08

--On Wednesday, July 09, 2008 1:18 PM +0000 jwm(a)horde.net wrote: > On Wed, Jul 09, 2008 at 09:48:52AM +0200, Buchan Milne wrote: >> On Saturday 21 June 2008 00:26:00 jwm(a)horde.net wrote: >> > On Fri, Jun 20, 2008 at 01:37:15PM -0700, Howard Chu wrote: >> > > > Program received signal SIGABRT, Aborted. >> > > > [Switching to Thread -1963996240 (LWP 22635)] >> > > > 0xb7bb1947 in raise () from /lib/tls/libc.so.6 >> > > >> > > This trace resembles ITS#5401, which was only fixed in RE24. You can >> > > look at the patch to syncprov.c there. There's no plan to make >> > > another 2.3 release at the moment. >> > >> > I don't mind patching for this locally, since slapd is crashing every >> > few days. I looked at the patch for ITS 5401 in RE24. I don't know >> > enough about slapd internals to easily backport it to RE23 since a fair >> > bit of the surrounding code differs between RE23 and RE24; would you be >> > willing to do >> >> The patches I found for this in RE24 seem to apply without problems on >> RE23. See attached patch its5401-re23.patch. >> >> Howard, this includes syncprov.c 1.219->1.220 and 1.147.2.27->1.147.2.28 >> (see attached its5401.patch), was that all? > > Heh, I totally glossed over 1.120 and went straight for 1.147.2.28; given > that the latter is on top of the former, it makes perfect sense now. :-/ This will be in 2.3.43. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#4685) Updated changelog overlay by Neil Dunbar
by sebastian＠rieger.info 09 Jul '08

09 Jul '08

since we're still using the overlay to synchronize our identities between OpenLDAP and Active Directory using Novell Identity Manager, I made a little update again that keeps up with latest OpenLDAP development in HEAD and finally includes some documentation that was initially written by Neil Dunbar. Thanks to Paul Turgyan I was able to fix some memory leaks that occured in specific situations when base64 encoded attributes were changed. As requested I also tried to get conform to the IPR policies that are required when contributing to OpenLDAP. I know that the changelog mechanism as described in the draft draft-good-ldap-changelog-03 is not new fashion - but some large dirctory servers and identity management products seem to stick to this "standard". You can find the updated versions in: for OpenLDAP 2.3.x (tested up to 2.3.42): ftp://ftp.openldap.org/incoming/rieger-changelog-23-pkg-080706.tgz for OpenLDAP 2.4.x (tested up to HEAD): ftp://ftp.openldap.org/incoming/rieger-changelog-24-pkg-080706.tgz I'll be glad for any feedback, Sebastian

1 0

Re: (ITS#5565) slapd crashes due to SIGPIPE
by jwm＠horde.net 09 Jul '08

09 Jul '08

On Wed, Jul 09, 2008 at 09:48:52AM +0200, Buchan Milne wrote: > On Saturday 21 June 2008 00:26:00 jwm(a)horde.net wrote: > > On Fri, Jun 20, 2008 at 01:37:15PM -0700, Howard Chu wrote: > > > > Program received signal SIGABRT, Aborted. > > > > [Switching to Thread -1963996240 (LWP 22635)] > > > > 0xb7bb1947 in raise () from /lib/tls/libc.so.6 > > > > > > This trace resembles ITS#5401, which was only fixed in RE24. You can > > > look at the patch to syncprov.c there. There's no plan to make another > > > 2.3 release at the moment. > > > > I don't mind patching for this locally, since slapd is crashing every > > few days. I looked at the patch for ITS 5401 in RE24. I don't know > > enough about slapd internals to easily backport it to RE23 since a fair > > bit of the surrounding code differs between RE23 and RE24; would you be > > willing to do > > The patches I found for this in RE24 seem to apply without problems on > RE23. See attached patch its5401-re23.patch. > > Howard, this includes syncprov.c 1.219->1.220 and 1.147.2.27->1.147.2.28 > (see attached its5401.patch), was that all? Heh, I totally glossed over 1.120 and went straight for 1.147.2.28; given that the latter is on top of the former, it makes perfect sense now. :-/ Thanks, Buchan. john -- John Morrissey _o /\ ---- __o jwm(a)horde.net _-< \_ / \ ---- < \, www.horde.net/ __(_)/_(_)________/ \_______(_) /_(_)__

1 0

(ITS#5608) additional info: modify/delete: postalAddress: no equality matching rule
by michael＠stroeder.com 09 Jul '08

09 Jul '08

Full_Name: Michael Ströder Version: RE24 OS: OpenSUSE Linux 10.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.107.210) Using OpenLDAP 2.4.10 (RE24) I'm trying to explicitly delete a value of attribute postalAddress: --------------------------------------------------------------- dn: cn=Fred Feuerstein,ou=Testing,dc=stroeder,dc=de changetype: modify delete: postalAddress postalAddress: zeile 1$zeile 2$zeile 3 - --------------------------------------------------------------- But this results in an error: modifying entry "cn=Fred Feuerstein,ou=Testing,dc=stroeder,dc=de" ldapmodify: Inappropriate matching (18) additional info: modify/delete: postalAddress: no equality matching rule But postalAddress is declared in the schema like this: ( 2.5.4.16 NAME 'postalAddress' DESC 'RFC2256: postal address' EQUALITY caseIgnoreListMatch SUBSTR caseIgnoreListSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) If the equality matching rule is not implemented it should not be announced in the subschema. The server should not simply report what might have been defined in some RFC. 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