openldap-devel July 2011

openldap-devel@openldap.org

3 participants
2 discussions

cn=config
by Ondrej Kuznik 04 Jul '11

04 Jul '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I'm modifying an overlay for proper cn=config behaviour and have come across some things I'm not sure about. The overlay keeps a mapping derived from entries under its config entry, if the overlay's dn is "olcoverlay={1}bla, olcdatabase={2}null, cn=config" there are entries like: "olcMappingRuleName={x}, olcoverlay={1}bla, olcdatabase={2}null, cn=config" The rules are then stored in an avl in the overlay's info struct. However to maintain the avl I think I need to know the boundaries of the request. When adding the entry online, it is easy, one registers the cleanup callback. When processing the entry during startup, the only way to have the callback run is mucking with ConfigArgs' lineno variable. However a modify operation is harder. It can transform the entry in almost whatever way it pleases. Updating the entry in the avl each time a subpart of the modify is sent to a ConfigDriver makes providing the atomicity required by LDAP very hard. For instance, the mapping defined by the entry may at one time be equal to another one in the avl. At that time, the overlay does not know, whether this is supposed to be the final version or there is a part of the modify that makes it a distinct one again. Hopefully this paragraph makes sense. If there is no such way, I propose that the cleanup be aplicable to a modify operation too. No patches so far though. - -- Ondrej Kuznik -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4MUyUACgkQ9GWxeeH+cXuGtwCfXrKV7D5NRo6xqmIl94pYW3xA lVsAniZFXMCDQOpv4dbj+r8kiPktp6+p =nr22 -----END PGP SIGNATURE----- This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

2 2

OID for Relax Rules Control (was: (ITS#6830) slapo-ppolicy.5 has incorrect schema fragments)
by Michael Ströder 01 Jul '11

01 Jul '11

andrew.findlay(a)skills-1st.co.uk wrote: > On Thu, Jun 09, 2011 at 01:45:17AM -0700, Howard Chu wrote: > >> I note that in ppolicy.c we have: >> >> { "( 1.3.6.1.4.1.42.2.27.8.1.17 " >> "NAME ( 'pwdAccountLockedTime' ) " >> "DESC 'The time an user account was locked' " >> "EQUALITY generalizedTimeMatch " >> "ORDERING generalizedTimeOrderingMatch " >> "SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 " >> "SINGLE-VALUE " >> #if 0 >> /* Not until Relax control is released */ >> "NO-USER-MODIFICATION " >> #endif >> "USAGE directoryOperation )", >> >> We have in fact released support for the Relax control, so it's >> probably time to unifdef these bits and go back to the documented >> behavior. What does "released support" really mean? $ grep -i relax openldap-2.4.26/include/ldap.h #define LDAP_CONTROL_RELAX "1.3.6.1.4.1.4203.666.5.12" #define LDAP_CONTROL_MANAGEDIT LDAP_CONTROL_RELAX "No released software should use an OID under this arc." See http://www.openldap.org/faq/data/cache/200.html I'd really love to see an officially assigned OID (especially given the fact that web2ldap supports it). Ciao, Michael.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel July 2011