openldap-bugs

openldap-bugs@openldap.org

1 participants
20966 discussions

Re: (ITS#5694) Usage of -w with slapadd breaks delta-syncrepl
by quanah＠zimbra.com 09 Sep '08

09 Sep '08

--On Tuesday, September 09, 2008 6:27 PM +0000 quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: RE24 9/7/2008 > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > As reported by David Hawes: > > http://www.openldap.org/lists/openldap-software/200808/msg00163.html > > If you load a server that will become the delta-syncrepl master using > slapadd -w, the slave will not see changes that occur after the accesslog > expires. Additionally did the following: Stopped the replica again, purged its db, restarted it so it got a fresh sync from the master (all users present). stopped the replica, added a new user on the master, let it expire from the accesslog db. started the replica. New user is not replicated. So it essentially appears that once -w is used to slapadd a master, no replica will be consistent if changes occur that are purged before the replica gets them. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5694) Usage of -w with slapadd breaks delta-syncrepl
by quanah＠zimbra.com 09 Sep '08

09 Sep '08

Full_Name: Quanah Gibson-Mount Version: RE24 9/7/2008 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) As reported by David Hawes: http://www.openldap.org/lists/openldap-software/200808/msg00163.html If you load a server that will become the delta-syncrepl master using slapadd -w, the slave will not see changes that occur after the accesslog expires. To confirm this, I did the following: (a) Created a base LDIF file that set up the suffix, a people tree, and a replica user (b) slapadded this LDIF file WITHOUT -w on the master (c) started the master (d) started the replica All data was replicated correctly (e) Stopped the replica (f) Added 6 users, and then deleted one (g) waited for the accesslog to expire (h) started the replica All data was replicated correctly (i) did a slapcat of the master (j) stopped the master and replica (k) deleted the database on the master and replica (l) Used slapadd -w to restore my slapcat of 5 users (m) started the replica, verified the contents were the same (n) stopped the replica (o) added a user on the master (p) waited for the accesslog to expire (q) started the replica The user I added was not replicated, and now the databases are inconsistent.

1 0

Re: (ITS#5690) cn=config cannot be rootdn
by quanah＠zimbra.com 09 Sep '08

09 Sep '08

--On Tuesday, September 09, 2008 4:52 PM +0000 ando(a)sys-net.it wrote: > Quanah Gibson-Mount wrote: >> --On Tuesday, September 09, 2008 10:10 AM +0000 ando(a)sys-net.it wrote: >> >>> quanah(a)zimbra.com wrote: >>> >>>> In OpenLDAP 2.3, it was possible to set the rootdn of the main database >>>> to be cn=config. This no longer works in OpenLDAP 2.4, but seems like >>>> it should be valid to me. >>> >>> ... >>> >>>> cn=config is *clearly* under "" >>> >>> No, cn=config is *clearly* under cn=config, which comes earlier than "". >>> But then you don't need to set rootpw. >> >> Ah, I see. So this is more just a behavior change between 2.3 and 2.4. >> Thanks! > > Well, I don't think they changed that much. If you expose cn=config > then any DN in that namespace will belong to the back-config; if you > don't expose it, then it will belong to "". I think you weren't using > the same slapd.conf with 2.3 and 2.4, if you noticed a different behavior. Hm, you're right, I mixed parts of a stock 2.4 slapd.conf with my 2.3 slapd.conf. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5690) cn=config cannot be rootdn
by ando＠sys-net.it 09 Sep '08

09 Sep '08

Quanah Gibson-Mount wrote: > --On Tuesday, September 09, 2008 10:10 AM +0000 ando(a)sys-net.it wrote: > >> quanah(a)zimbra.com wrote: >> >>> In OpenLDAP 2.3, it was possible to set the rootdn of the main database >>> to be cn=config. This no longer works in OpenLDAP 2.4, but seems like >>> it should be valid to me. >> >> ... >> >>> cn=config is *clearly* under "" >> >> No, cn=config is *clearly* under cn=config, which comes earlier than "". >> But then you don't need to set rootpw. > > Ah, I see. So this is more just a behavior change between 2.3 and 2.4. > Thanks! Well, I don't think they changed that much. If you expose cn=config then any DN in that namespace will belong to the back-config; if you don't expose it, then it will belong to "". I think you weren't using the same slapd.conf with 2.3 and 2.4, if you noticed a different behavior. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5690) cn=config cannot be rootdn
by quanah＠zimbra.com 09 Sep '08

09 Sep '08

--On Tuesday, September 09, 2008 10:10 AM +0000 ando(a)sys-net.it wrote: > quanah(a)zimbra.com wrote: > >> In OpenLDAP 2.3, it was possible to set the rootdn of the main database >> to be cn=config. This no longer works in OpenLDAP 2.4, but seems like >> it should be valid to me. > > ... > >> cn=config is *clearly* under "" > > No, cn=config is *clearly* under cn=config, which comes earlier than "". > But then you don't need to set rootpw. Ah, I see. So this is more just a behavior change between 2.3 and 2.4. Thanks! --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5691) Re: malloc without check
by ando＠sys-net.it 09 Sep '08

09 Sep '08

Actually, I see plenty of places where it occurs. I vaguely recall that malloc used to be #defined as ch_malloc within slapd, although I believe it is no longer. In any case, I'm in favor of avoiding those redefinitions, for the sake of clarity. The correct solution should be to replace them with ch_malloc() (same for other memory-related functions, like calloc(), realloc(), strdup() and free(), although the latter is not strictly needed). 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5692) Re: literal constant 8192 used instead of SLAP_LDAPDN_MAXLEN
by ando＠sys-net.it 09 Sep '08

09 Sep '08

In none of the files you indicated the buffer size 8192 is used for a DN, so I see no reason for hijacking SLAP_LDAPDN_MAXLEN for that purpose. It might be good practice to define one or more macros and consistently use them, although in the specific cases there is no repeated use of the value, nor specific consistency constraints for the use of that value. With respect to your second question, OpenLDAP never relies on SLAP_LDAPDN_MAXLEN stability in terms of buffer access; since that macro is local to slapd, if it changes the whole slapd will see it. The only issue could be with redefinition of the macro across module compilation, if you use dynamic modules. Also in that case things shouldn't be critical, as slapd never relies on that macro for accessing buffers, but rather on actual buffer size. The only potentia issue I see is with spurious syntax errors if a module with larger SLAP_LDAPDN_MAXLEN calls a DN-related validation/normalization function passing a DN whose length is larger than the value of SLAP_LDAPDN_MAXLEN slapd was built with. No buffer overflow risk, though; at most, DoS on uncommonly long DNs. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5693) [enhancement] extension of slapo-translucent filtering approach
by ando＠sys-net.it 09 Sep '08

09 Sep '08

Full_Name: Pierangelo Masarati Version: irrelevant OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando I see a few potential issues in current slapo-translucent(5) filtering approach: - if an attribute is marked as local, it will not be used to filter entries on the remote server; however, that attribute might exist in entries on the remote server, resulting in inconsistent search results - the same is also true in the reverse case in those cases, it might be helpful to let the same attribute be listed as local *and* remote, acting accordingly. Also, there is no way to indicate that some attributes are local and *all the others* are remote (and viceversa); it is suggested to allow "*" (and "+"?), as well as "1.1" to indicate no attributes. Wildcards would take effect unless attribute specifications are present. I don't know, right now, how easy it would be to implement those enhancements; I'm just noting them here as a reminder for a feature request. p.

1 0

Re: (ITS#5665) slapd crashing with slapo-pcache when using attrset "*"
by toby＠inf.ed.ac.uk 09 Sep '08

09 Sep '08

Hi again, I haven't been able to reproduce the problem since patching, so I consider it fixed.... Many thanks Toby -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

(ITS#5692) literal constant 8192 used instead of SLAP_LDAPDN_MAXLEN
by andreas.moroder＠gmx.net 09 Sep '08

09 Sep '08

Full_Name: Andreas Moroder Version: 2.4.11 OS: Suse Linux 10.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (151.47.3.213) Hello, in /servers/slapd/bconfig.c /libraries/libldap_r/tls.c /libraries/libldap_r/tls.c ./libraries/liblber/stdio.c /libraries/liblunicode/ucdata/ucgendat.c /contrib/slapd-modules/lastmod/lastmod.c the literal value 8192 is used for array sizes instead of SLAP_LDAPDN_MAXLEN 8192 defined in /servers/slapd/slap.h I think this could become a problem if SLAP_LDAPDN_MAXLEN grows in a future release. A question from a newbie: What happens in a mixed environment with a never version with bigger SLAP_LDAPDN_MAXLEN that replicates his entries to a version with SLAP_LDAPDN_MAXLEN at 8192 ? Isn't it wrong not to check for a buffer owerflow when strings are concantenated and suppose that the data we use does not exceed the limit ? Bye Andreas

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