openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

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

09 Sep '08

quanah(a)zimbra.com wrote: > --On Tuesday, September 09, 2008 8:59 PM +0200 Pierangelo Masarati > <ando(a)sys-net.it> wrote: > > >>> I'll give what you suggested a try, but this is still a serious bug. >> There's something I don't clearly get. As far as I understand, you are >> saying that consumers lose sync when the log database is purged before >> they have a chance to sync (because they were down). I don't see how >> they could sync, then. Of course, there should be a means for >> slapo-syncprov(5) to tell that, and force a refresh. > > Because the consumer is supposed to do a full refresh if they find their > context CSN doesn't match the contextCSN of the master. Not quite. More precisely, the provider is supposed to tell the consumer that the consumer's cookie is out of date if the cookie is older than anything in the provider, and the consumer asked for the reload Hint. Otherwise the provider just sees the consumer is stale and returns a full dump implicitly. In plain syncrepl the consumer never asks for the reload hint. In delta-sync the consumer does ask for a reload hint, because that tells it to do a sync from the main DB instead of the log DB. It sounds like if there's a bug here, it's caused by the logdb's provider not sending a reload hint when it should. > See ITS#5376, ITS#5378, ITS#5465, ITS#5493, ITS#5282 -- -- 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#5694) Usage of -w with slapadd breaks delta-syncrepl
by quanah＠zimbra.com 09 Sep '08

09 Sep '08

--On Tuesday, September 09, 2008 8:59 PM +0200 Pierangelo Masarati <ando(a)sys-net.it> wrote: >> I'll give what you suggested a try, but this is still a serious bug. > > There's something I don't clearly get. As far as I understand, you are > saying that consumers lose sync when the log database is purged before > they have a chance to sync (because they were down). I don't see how > they could sync, then. Of course, there should be a means for > slapo-syncprov(5) to tell that, and force a refresh. Because the consumer is supposed to do a full refresh if they find their context CSN doesn't match the contextCSN of the master. See ITS#5376, ITS#5378, ITS#5465, ITS#5493, ITS#5282 --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5694) Usage of -w with slapadd breaks delta-syncrepl
by ando＠sys-net.it 09 Sep '08

09 Sep '08

Quanah Gibson-Mount wrote: > --On Tuesday, September 09, 2008 8:50 PM +0200 Pierangelo Masarati > <ando(a)sys-net.it> wrote: > >> I thuink the issue is related to the fact that slapadd -w uses >> bi_tool_entry_modify() and bi_tool_sync(). However, slapo-accesslog(5) >> does not implement those hooks. As a consequence, any modification to >> the context entry is not reflected in slapo-accesslog(5). >> >> However, I don't see how this should affect replication, since a >> consistent database, after slapcatt'ing, should generate a ldif with the >> correct contextCSN. However, if you slapcat before stopping the >> producer, the resulting ldif will not contain the contextCSN, because >> after a fresh slapadd without -w it's kept in memory until the producer >> is stopped. You should try > > It should be possible to restore a working provider/slave relationship > from a hot slapcat taken at any point in time. Well, actually slapadd -w should suffice. As an alternative, slapcat could support -w as well, for symmetry, so that consistent ldifs can be generated. > I'll give what you suggested a try, but this is still a serious bug. There's something I don't clearly get. As far as I understand, you are saying that consumers lose sync when the log database is purged before they have a chance to sync (because they were down). I don't see how they could sync, then. Of course, there should be a means for slapo-syncprov(5) to tell that, and force a refresh. 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#5694) Usage of -w with slapadd breaks delta-syncrepl
by quanah＠zimbra.com 09 Sep '08

09 Sep '08

--On Tuesday, September 09, 2008 8:50 PM +0200 Pierangelo Masarati <ando(a)sys-net.it> wrote: > I thuink the issue is related to the fact that slapadd -w uses > bi_tool_entry_modify() and bi_tool_sync(). However, slapo-accesslog(5) > does not implement those hooks. As a consequence, any modification to > the context entry is not reflected in slapo-accesslog(5). > > However, I don't see how this should affect replication, since a > consistent database, after slapcatt'ing, should generate a ldif with the > correct contextCSN. However, if you slapcat before stopping the > producer, the resulting ldif will not contain the contextCSN, because > after a fresh slapadd without -w it's kept in memory until the producer > is stopped. You should try It should be possible to restore a working provider/slave relationship from a hot slapcat taken at any point in time. I'll give what you suggested a try, but this is still a serious bug. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5694) Usage of -w with slapadd breaks delta-syncrepl
by ando＠sys-net.it 09 Sep '08

09 Sep '08

I thuink the issue is related to the fact that slapadd -w uses bi_tool_entry_modify() and bi_tool_sync(). However, slapo-accesslog(5) does not implement those hooks. As a consequence, any modification to the context entry is not reflected in slapo-accesslog(5). However, I don't see how this should affect replication, since a consistent database, after slapcatt'ing, should generate a ldif with the correct contextCSN. However, if you slapcat before stopping the producer, the resulting ldif will not contain the contextCSN, because after a fresh slapadd without -w it's kept in memory until the producer is stopped. You should try (i) stop the master and replica (j) do a slapcat of the master (k) delete the database on the master and replica (l) Use slapadd -w to restore your slapcat of 5 users (m) start the replica, verify the contents are the same (n) stop the replica (o) add a user on the master (p) wait for the accesslog to expire (q) start the replica In the meanwhile, you should check what contextCSN your consumers have after syncing from a producer loaded without -w. 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#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

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