openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

Re: (ITS#6469) push replication entryCSN of database suffix out of sync
by rhafer＠suse.de 03 Feb '10

03 Feb '10

Am Dienstag 02 Februar 2010 23:30:23 schrieb hyc(a)symas.com: > ralf(a)OpenLDAP.org wrote: > > Full_Name: Ralf Haferkamp > > Version: RE24, HEAD > > OS: > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (89.166.208.247) > > Submitted by: ralf > > > > > > When using push-based replication (syncrepl-proxy) the entryCSN of > > the consumer's server's suffix entry (the one that also holds the > > contextCSN Attribute) is not in sync with the value on the > > provider. (Other operational Attributes are out of sync as well) > > > > This is because the MOD Operation to update the contextCSN (sent by > > the provider) does not contain any other operational Attributes. > > That causes the consumer to add those attributes itself. > > > > I guess the problem is mostly cosmetic, but I'll submit a fix > > anyway. (not calling slap_mods_opattrs() if the updatedn modifies > > "contextCSN") > > But how did the suffix entry get created without an entryCSN in the > first place? The MOD that updates the contextCSN doesn't happen until > after the suffix entry already exists. It wasn't created without an entryCSN. It always had one. But the MOD to update the contextCSN (coming from the provider) doesn't contain one. So bdb_modify() will call slap_mods_opattrs() to add entryCSN to the MOD operation. The easiest fix is probably to never touch the opattrs if "updatedn" is doing MODs, though I am not yet sure if it might break something. Currently my fix (not committed yet) only skips the slap_mods_opattrs() step if "updatedn" it is doing a MOD on contextCSN. -- Ralf

1 0

Re: (ITS#6469) push replication entryCSN of database suffix out of sync
by hyc＠symas.com 02 Feb '10

02 Feb '10

ralf(a)OpenLDAP.org wrote: > Full_Name: Ralf Haferkamp > Version: RE24, HEAD > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (89.166.208.247) > Submitted by: ralf > > > When using push-based replication (syncrepl-proxy) the entryCSN of the > consumer's server's suffix entry (the one that also holds the contextCSN > Attribute) is not in sync with the value on the provider. (Other operational > Attributes are out of sync as well) > > This is because the MOD Operation to update the contextCSN (sent by the > provider) does not contain any other operational Attributes. That causes the > consumer to add those attributes itself. > > I guess the problem is mostly cosmetic, but I'll submit a fix anyway. (not > calling slap_mods_opattrs() if the updatedn modifies "contextCSN") > But how did the suffix entry get created without an entryCSN in the first place? The MOD that updates the contextCSN doesn't happen until after the suffix entry already exists. -- -- 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#6432) PATCH: MozNSS crypto (tls_m.c) - support InitContext, improved PEM support
by rmeggins＠redhat.com 02 Feb '10

02 Feb '10

New and improved patch, to address issues mentioned by Howard, and to clean up some memory leaks. ftp://ftp.openldap.org/incoming/openldap-2.4.21-tls_m_c-InitContext-PEM-201… Note: This new version depends on Mozilla NSS 3.12.6 (currently unreleased) and currently unreleased patches of PEM NSS in order to avoid a couple of memory leaks.

1 0

(ITS#6469) push replication entryCSN of database suffix out of sync
by ralf＠OpenLDAP.org 02 Feb '10

02 Feb '10

Full_Name: Ralf Haferkamp Version: RE24, HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.208.247) Submitted by: ralf When using push-based replication (syncrepl-proxy) the entryCSN of the consumer's server's suffix entry (the one that also holds the contextCSN Attribute) is not in sync with the value on the provider. (Other operational Attributes are out of sync as well) This is because the MOD Operation to update the contextCSN (sent by the provider) does not contain any other operational Attributes. That causes the consumer to add those attributes itself. I guess the problem is mostly cosmetic, but I'll submit a fix anyway. (not calling slap_mods_opattrs() if the updatedn modifies "contextCSN")

1 0

Re: (ITS#6468) ACLs in subordinate databases can be ignored
by rein＠OpenLDAP.org 02 Feb '10

02 Feb '10

On 02/02/2010 04:25 PM, Hallvard B Furuseth wrote: > Hold on. Is the current behavior self-consistent, i.e. one could call > it an undocumented feature? If so someone may have noticed this and > written their ACLs accordingly. It's not friendly to change the > meaning of existing installations' ACLs in the middle of RE24. > > OTOH if current behavior is broken even as a "feature", fix away. > E.g. if clients can choose which ACLs will apply in the subordinate > by picking a base DN inside vs outside the subordinate. From my analyzis of the problem, the subordinate ACLs are used in all cases except when syncprov desides which "live" modifications it should replicate to its consumers. Searching with the credentials used by the syncrepl consumer gives me the attributes and entries my subordinate ACLs allows, and they are replicated during the refresh phase. But access to entries and/or attributes being modified during the persistent phase are rejected. But yes, the change should be analyzed by somebody else before being included in a release. Rein

1 0

Re: (ITS#6468) ACLs in subordinate databases can be ignored
by h.b.furuseth＠usit.uio.no 02 Feb '10

02 Feb '10

Hold on. Is the current behavior self-consistent, i.e. one could call it an undocumented feature? If so someone may have noticed this and written their ACLs accordingly. It's not friendly to change the meaning of existing installations' ACLs in the middle of RE24. OTOH if current behavior is broken even as a "feature", fix away. E.g. if clients can choose which ACLs will apply in the subordinate by picking a base DN inside vs outside the subordinate. -- Hallvard

1 0

(ITS#6468) ACLs in subordinate databases can be ignored
by rein＠OpenLDAP.org 02 Feb '10

02 Feb '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 In a glued database configuration where overlays (syncprov, accesslog) are stacked on top of the glue overlay, ACL evaluation initiated from these overlays can be evaluated by the superior glue database and not the subordinate database where the entry actually exist. I.e, ACLs defined in the subordinate databases are ignored in these cases. A fix that implements bi_access_allowed in the glue overlay is coming, it delegates the call to the actual backend where the entry being referenced exist. An alternative approach I considered was to require the overlays to call select_backend() to find the actual backend where the entry exist, but that would imo obfuscate the modularization of the code. -- Rein Tollevik Basefarm AS

1 0

Re: (ITS#6465) startup error after converting to slapd-config
by gerard.ranke＠kmt.hku.nl 02 Feb '10

02 Feb '10

Ralf Haferkamp wrote: > A fix is in HEAD now (servers/slapd/config.c rev 1.513) please test. Thanks! Hopefully I can compile & test tomorrow, I'll let you know. Best, gerard

1 0

Re: (ITS#6465) startup error after converting to slapd-config
by Ralf Haferkamp 02 Feb '10

02 Feb '10

A fix is in HEAD now (servers/slapd/config.c rev 1.513) please test.

1 0

Re: (ITS#6465) startup error after converting to slapd-config
by Ralf Haferkamp 02 Feb '10

02 Feb '10

This got introduced by the fix for ITS#6419. I am currently working on a fix.

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