August 2011 - openldap-bugs

Re: (ITS#7019) attribute auditContext should not get replicated

by hyc＠symas.com

hyc(a)symas.com wrote: > michael(a)stroeder.com wrote: >> Full_Name: >> Version: 2.4.26 >> OS: >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (84.163.26.156) >> >> >> It seems that attribute auditContext is replicated to consumers if there's an >> accesslog DB configured at the provider. IMO this does not make sense since the >> accesslog DB is not replicated and one might not want to load slapo-accesslog >> module at all in the consumer's config. >> >> In a 2-way MMR setup with accesslog DB attached to both master providers the >> auditContext contains two values for auditContext and even the same one. > > Since a syncrepl operation is a regular LDAP search, the provider sends > everything that matches the search request. Probably we should be filtering > out DSA-specific opattrs at the consumer side. > Hm, I take this back. slapd/result.c already filters out DSA-specific opattrs on the provider side, when the Syncrepl control is present. Something else is going on here, but since you failed to provide any config info there's no way to tell where the problem is. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

12 years, 3 months

1
0
0 / 0

Re: (ITS#7019) attribute auditContext should not get replicated

by hyc＠symas.com

michael(a)stroeder.com wrote: > Full_Name: > Version: 2.4.26 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.163.26.156) > > > It seems that attribute auditContext is replicated to consumers if there's an > accesslog DB configured at the provider. IMO this does not make sense since the > accesslog DB is not replicated and one might not want to load slapo-accesslog > module at all in the consumer's config. > > In a 2-way MMR setup with accesslog DB attached to both master providers the > auditContext contains two values for auditContext and even the same one. Since a syncrepl operation is a regular LDAP search, the provider sends everything that matches the search request. Probably we should be filtering out DSA-specific opattrs at the consumer side. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

12 years, 3 months

1
0
0 / 0

Re: (ITS#7019) attribute auditContext should not get replicated

by quanah＠zimbra.com

--On Monday, August 15, 2011 9:03 PM +0200 Michael Ströder <michael(a)stroeder.com> wrote: > quanah(a)zimbra.com wrote: >> Delta-Syncrepl (normal and MMR modes) both use an accesslog database. >> So your contention that accesslog DBs are not replicated is somewhat >> incorrect. > > Up to now I thought that the accesslog DB itself is only accessible at the > provider and not replicated to the consumer. At least that's what's IMO > written in the OpenLDAP Admin Guide: I just wanted to be clear that accesslog can be used for replication. Thank you for providing such a nice test case example. ;) As for delta-syncrepl MMR, it exists, its in HEAD, and I have it working with RE24 just fine. It may well go into the next 2.4 release, so don't ignore it. ;) --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

12 years, 3 months

1
0
0 / 0

Re: (ITS#7019) attribute auditContext should not get replicated

by michael＠stroeder.com

quanah(a)zimbra.com wrote: > Delta-Syncrepl (normal and MMR modes) both use an accesslog database. So > your contention that accesslog DBs are not replicated is somewhat incorrect. Up to now I thought that the accesslog DB itself is only accessible at the provider and not replicated to the consumer. At least that's what's IMO written in the OpenLDAP Admin Guide: http://www.openldap.org/doc/admin24/replication.html#Delta-syncrepl "Delta-syncrepl works by maintaining a changelog of a selectable depth on the provider." Also in the Admin Guide: http://www.openldap.org/doc/admin24/replication.html#Delta-syncrepl There's no accesslog database at the consumer (replica) configured. Delta-syncrepl in MMR mode is not finished yet, therefore I ignore this case for now. Because you are nitpicking in my case I set up a testbed. The accesslog DB itself is *not* replicated. Anyway the main issue here is that I regard replicating the attribute auditContext as not appropriate since you cannot access the referenced accesslog DB at the consumer. And it seems that with delta syncrepl the attribute is not replicated. But it seems to be replicated in a MMR setup with separate accesslog DBs configured at both providers. And this leads to this multiple but same(!) attribute values. We have four databases in our MMR test setup: cn=wsvdir-accesslog-de (for c=DE) cn=wsvdir-accesslog-system (for o=SYSTEM) o=SYSTEM (replicated in MMR setup) c=DE (replicated in MMR setup) In both providers I have dn: o=SYSTEM auditContext: cn=wsvdir-accesslog-system auditContext: cn=wsvdir-accesslog-system It does not happen in c=DE though. Ciao, Michael.

12 years, 3 months

1
0
0 / 0

Re: (ITS#7019) attribute auditContext should not get replicated

by quanah＠zimbra.com

--On Monday, August 15, 2011 2:42 PM +0000 michael(a)stroeder.com wrote: > Full_Name: > Version: 2.4.26 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.163.26.156) > > > It seems that attribute auditContext is replicated to consumers if > there's an accesslog DB configured at the provider. IMO this does not > make sense since the accesslog DB is not replicated and one might not > want to load slapo-accesslog module at all in the consumer's config. > > In a 2-way MMR setup with accesslog DB attached to both master providers > the auditContext contains two values for auditContext and even the same > one. Delta-Syncrepl (normal and MMR modes) both use an accesslog database. So your contention that accesslog DBs are not replicated is somewhat incorrect. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

12 years, 3 months

1
0
0 / 0

(ITS#7019) attribute auditContext should not get replicated

by michael＠stroeder.com

Full_Name: Version: 2.4.26 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.26.156) It seems that attribute auditContext is replicated to consumers if there's an accesslog DB configured at the provider. IMO this does not make sense since the accesslog DB is not replicated and one might not want to load slapo-accesslog module at all in the consumer's config. In a 2-way MMR setup with accesslog DB attached to both master providers the auditContext contains two values for auditContext and even the same one.

12 years, 3 months

1
0
0 / 0

(ITS#7018) unique URI's host part must be empty

by masarati＠aero.polimi.it

Full_Name: Pierangelo Masarati Version: master,re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.144.24.27) Submitted by: ando If empty "host" part is checked, misconfigurations like in <http://www.openldap.org/lists/openldap-technical/201108/msg00116.html> would be easily detected. A fix is coming. p.

12 years, 3 months

1
0
0 / 0

(ITS#7017) DDS overlay: TTL tolerance has inverse effect

by jvcelak＠redhat.com

Full_Name: Jan Vcelak Version: master OS: Linux URL: ftp://ftp.openldap.org/incoming/jvcelak-110811-dds-overlay-tolerance.patch Submission from: (NULL) (209.132.186.34) Hi! olcDDStolerance setting of DDS overlay has inverse effect and in fact it is shortening the real TTL of dynamic entries. I have uploaded the patch (against git master). Regards, Jan

12 years, 3 months

1
0
0 / 0

(ITS#7016) slapd.ldif bootstrap fails on olcDatabase=frontend

by andrew.findlay＠skills-1st.co.uk

Full_Name: Andrew Findlay Version: 2.4.26 OS: OpenSuSE 11.4 URL: ftp://ftp.openldap.org/incoming/ajf-20110811-slapd.ldif Submission from: (NULL) (2a01:348:28c:1:222:68ff:fe15:3346) Using a slapd.ldif (attached) closely based on the example from servers/slapd/slapd.ldif I find that the server will not bootstrap: $ slapadd -F ./config -n 0 -l slapd-try.ldif _#################### 100.00% eta none elapsed none fast! Closing DB... $ slapadd -F ./config -l data.ldif -b dc=example,dc=org slapadd: bad configuration directory! The problem appears to be this entry in the LDIF: dn: olcDatabase=frontend,cn=config objectClass: olcDatabaseConfig olcDatabase: frontend olcAccess: to * by * read If 'frontend' is replaced with '{-1}frontend' in both places then the server works. At the least this needs changing in the example file slapd.ldif, in the manpage slapd-config(5), and in the admin guide. Some explanation as to why it is necessary would be welcome too! (I suspect it is because the cn=config DB has already been instantiated as DB zero, yet the frontend has to come ahead of all other DBs in some list). The error message is not very helpful, and winding up the debugging level just sent me up blind alleys so could the server please say a bit more about just what is bad about the config directory?

12 years, 3 months

1
0
0 / 0

Re: (ITS#7015) slapd.ldif example file not installed

by masarati＠aero.polimi.it

> Full_Name: Andrew Findlay > Version: 2.4.26 > OS: OpenSuSE 11.4 > URL: > Submission from: (NULL) (2a01:348:28c:1:222:68ff:fe15:3346) > > > slapdconf2.sdf says: > The distribution contains an example configuration file that will > be installed in the {{F: /usr/local/etc/openldap}} directory. > > There is an example file in the source: servers/slapd/slapd.ldif > but it is not installed anywhere. The corresponding slapd.conf example > does get installed, so this one should probably go alongside it. Fixed in master, please test. p.

12 years, 3 months

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs August 2011