openldap-bugs

openldap-bugs@openldap.org

1 participants
21065 discussions

Re: (ITS#7682) LMDB: [PATCH] mdb_env_copy should retry open() if O_DIRECT fails
by h.b.furuseth＠usit.uio.no 21 Dec '13

21 Dec '13

This was fixed in LMDB 0.9.9, except: If both O_DIRECT and F_NOCACHE are #defined, both are used. Looks a bit strange. Maybe just one should be used in that case. (Which?) Also I'm still wondering if env_open needs to fail if F_NOCACHE fails. Anyway, maybe it should be something like this. The "else {}" is in case O_DIRECT is an unsupported dummy definiton: #ifdef O_DIRECT if ((rc = fcntl(newfd, F_GETFL)) != -1) (void) fcntl(newfd, F_SETFL, rc | O_DIRECT); else #endif { #ifdef F_NOCACHE /* __APPLE__ */ (void) fcntl(newfd, F_NOCACHE, 1); #endif } -- Hallvard

1 0

Re: (ITS#7515) Nested liblmdb transaction bugs
by h.b.furuseth＠usit.uio.no 21 Dec '13

21 Dec '13

The remaining issues were fixed in LMDB 0.9.9. Closing this ITS. -- Hallvard

1 0

(ITS#7770) mdb_stat in cn=monitor
by michael＠stroeder.com 19 Dec '13

19 Dec '13

Full_Name: Version: OS: URL: Submission from: (NULL) (212.227.35.93) Feature request: It would be handy to have output of mdb_stat in cn=monitor.

1 0

Re: (ITS#7766) Account unlocked in slave after two modifications on a master (overlay ppolicy)
by clem.oudot＠gmail.com 19 Dec '13

19 Dec '13

--001a11c36ad2fcb4a204ede39c11 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2013/12/19 Christian Kratzer <ck(a)cksoft.de> > Hi, > > On Wed, 18 Dec 2013, Cl=E9ment OUDOT wrote: > <snipp/> > >> I sent it by mail but I think it is too big and queued. So here is all >> >> configuration and test result: >> >> http://pastebin.com/earKiHnH >> > > I have not worked trhough all your examples and configs yet as I am > travelling at the moment but things seem quite clear to me. > > > The password lock from you slaves never arrives on your master as you > have not configured referrals or any other kind of replication of state > from your slave to your master. > > That means the data on the masters and the slaves is inconsistent. > > As syncrepl as you use it always replaces the entire entry any changes > from the master will complelete overrite anything on the slaves. > > There is no merging of data in syncrepl. > If you take time to read all I sent, you will see that a first modification on the master DO NOT modifiy ppolicy attributes on the slave, the second modification do. Whatever you think, there is a bug here. If you read with caution the ppolicy draft, you will see that pwdAccountLockedTime and some other attributes SHOULD NOT be replicated on read-only replicas. > > This is working as designed and is not a bug by my understanding. > > We disagree a lot on this point. > You have at least following two options from what I see: > > 1. configure referrals and chaining so password locks etc... on the slav= e > get forwarded to the masters and replicated back to the slave. > > This means that you need to configure lcPPolicyForwardUpdates: TRUE > and chaining on your slave. > I tested it with success (almost, see ITS#7767 and ITS#7768) > > 2. configure multimaster replication so password locks get replicated > to your master. > > I did not test if the bug occurs in multimaster, but I think not. > You should close this ITS and we can discuss anything further on the > regular mailing lists. > > As said above, I am pretty sure there is a bug. Maybe an OpenLDAP developer should give its opinion on this ITS. Cl=E9ment. --001a11c36ad2fcb4a204ede39c11 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail= _quote">2013/12/19 Christian Kratzer <span dir=3D"ltr"><<a href=3D"mailt= o:ck@cksoft.de" target=3D"_blank">ck(a)cksoft.de</a>></span><br><blockquot= e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol= id;padding-left:1ex"> <div class=3D"im">Hi,<br> <br> On Wed, 18 Dec 2013, Cl=E9ment OUDOT wrote:<br> <snipp/><br> </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"> I sent it by mail but I think it is too big and queued. So here is all<div = class=3D"im"><br> configuration and test result:<br> <br> <a href=3D"http://pastebin.com/earKiHnH" target=3D"_blank">http://pastebin.= com/earKiHnH</a><br> </div></blockquote> <br> I have not worked trhough all your examples and configs yet as I am<br> travelling at the moment but things seem quite clear to me.<br></blockquote= ><div>=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 = .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br> The password lock from you slaves never arrives on your master as you<br> have not configured referrals or any other kind of replication of state<br> from your slave to your master.<br> <br> That means the data on the masters and the slaves is inconsistent.<br> <br> As syncrepl as you use it always replaces the entire entry any changes<br> from the master will complelete overrite anything on the slaves.<br> <br> There is no merging of data in syncrepl.<br></blockquote><div><br><br><br><= /div><div>If you take time to read all I sent, you will see that a first mo= dification on the master DO NOT modifiy ppolicy attributes on the slave, th= e second modification do. Whatever you think, there is a bug here.<br> </div><div><br><br><br></div><div>If you read with caution the ppolicy draf= t, you will see that pwdAccountLockedTime and some other attributes SHOULD = NOT be replicated on read-only replicas.<br></div><div><br>=A0</div><blockq= uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc = solid;padding-left:1ex"> <br> This is working as designed and is not a bug by my understanding.<br> <br></blockquote><div><br><br></div><div>We disagree a lot on this point.<b= r><br><br></div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"ma= rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> You have at least following two options from what I see:<br> <br> 1. =A0configure referrals and chaining so password locks etc... on the slav= e<br> =A0 =A0 get forwarded to the masters and replicated back to the slave.<br> <br> =A0 =A0 This means that you need to configure lcPPolicyForwardUpdates: TRUE= <br> =A0 =A0 and chaining on your slave.<br></blockquote><div><br><br></div><div= >I tested it with success (almost, see ITS#7767 and ITS#7768)<br></div><div= >=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord= er-left:1px #ccc solid;padding-left:1ex"> <br> 2. =A0configure multimaster replication so password locks get replicated<br= > =A0 =A0 to your master.<br> <br></blockquote><div><br><br></div><div>I did not test if the bug occurs i= n multimaster, but I think not.<br><br>=A0<br></div><blockquote class=3D"gm= ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le= ft:1ex"> You should close this ITS and we can discuss anything further on the<br> regular mailing lists.<div class=3D"HOEnZb"><div class=3D"h5"><br></div></d= iv></blockquote><div><br><br><br><br></div><div>As said above, I am pretty = sure there is a bug. Maybe an OpenLDAP developer should give its opinion on= this ITS.<br> <br><br>Cl=E9ment.<br></div></div></div></div> --001a11c36ad2fcb4a204ede39c11--

1 0

Re: (ITS#7766) Account unlocked in slave after two modifications on a master (overlay ppolicy)
by ck＠cksoft.de 19 Dec '13

19 Dec '13

This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --4178219828-1095844242-1387443188=:27797 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Hi, On Wed, 18 Dec 2013, Clément OUDOT wrote: <snipp/> > I sent it by mail but I think it is too big and queued. So here is all > configuration and test result: > > http://pastebin.com/earKiHnH I have not worked trhough all your examples and configs yet as I am travelling at the moment but things seem quite clear to me. The password lock from you slaves never arrives on your master as you have not configured referrals or any other kind of replication of state from your slave to your master. That means the data on the masters and the slaves is inconsistent. As syncrepl as you use it always replaces the entire entry any changes from the master will complelete overrite anything on the slaves. There is no merging of data in syncrepl. This is working as designed and is not a bug by my understanding. You have at least following two options from what I see: 1. configure referrals and chaining so password locks etc... on the slave get forwarded to the masters and replicated back to the slave. This means that you need to configure lcPPolicyForwardUpdates: TRUE and chaining on your slave. 2. configure multimaster replication so password locks get replicated to your master. You should close this ITS and we can discuss anything further on the regular mailing lists. Greetings Christian -- Christian Kratzer CK Software GmbH Email: ck(a)cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer --4178219828-1095844242-1387443188=:27797--

1 0

Re: (ITS#7766) Account unlocked in slave after two modifications on a master (overlay ppolicy)
by clem.oudot＠gmail.com 18 Dec '13

18 Dec '13

--089e0160b79ae9bb0c04edcfeff1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2013/12/18 <ck(a)cksoft.de> > This message is in MIME format. The first part should be readable text= , > while the remaining parts are likely unreadable without MIME-aware tool= s. > > --4178219828-444410844-1387368134=3D:27797 > Content-Type: TEXT/PLAIN; charset=3DUTF-8; format=3Dflowed > Content-Transfer-Encoding: 8BIT > > Hi, > > On Wed, 18 Dec 2013, Cl=E9ment OUDOT wrote: > <snipp/> > > Well, I checked that the pwdLockoutDuration was correctly set (The valu= e > > in my case is 1200, so 20 minutes, much more than my tests). Other > > proof, the values of pwdFailureTime are not erased, but replaced by > > those of the master. > > > > > >> It is of course also quite possible that you have hit a special corner > >> case that nobody else has yet found. > > > > > > I think so. I have to say that I use standard syncrepl, not > delta-syncrepl. > > > > > >> > >> The best thing you could do would be to setup a small self contained > >> test case to illustrate the problem. > >> > > > > I will try to, but seems really easy to reproduce : configure master an= d > > slave with ppolicy, lock an account in slave, update same account on > > master (change description) a first time and a second time. > > are you sure the account lock actually arrives on the master ? > > Are you using olcPPolicyForwardUpdates to actually get the account > locked on the master and not only on the slaves ? > > If you do not have all the lock attributes on the master and you modify > the entry it will get replaced on the slaves. > > Can you post your master and slave configs somewhere ? > > I sent it by mail but I think it is too big and queued. So here is all configuration and test result: http://pastebin.com/earKiHnH Cl=E9ment. --089e0160b79ae9bb0c04edcfeff1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail= _quote">2013/12/18 <span dir=3D"ltr"><<a href=3D"mailto:ck@cksoft.de" t= arget=3D"_blank">ck(a)cksoft.de</a>></span><br><blockquote class=3D"gmail_= quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,= 204);padding-left:1ex"> =A0 This message is in MIME format. =A0The first part should be readable te= xt,<br> =A0 while the remaining parts are likely unreadable without MIME-aware tool= s.<br> <br> --4178219828-444410844-1387368134=3D:27797<br> Content-Type: TEXT/PLAIN; charset=3DUTF-8; format=3Dflowed<br> Content-Transfer-Encoding: 8BIT<br> <br> Hi,<br> <br> On Wed, 18 Dec 2013, Cl=E9ment OUDOT wrote:<br> <snipp/><br> <div class=3D"im">> Well, I checked that the pwdLockoutDuration was corr= ectly set (The value<br> > in my case is 1200, so 20 minutes, much more than my tests). Other<br> > proof, the values of pwdFailureTime are not erased, but replaced by<br= > > those of the master.<br> ><br> ><br> >> It is of course also quite possible that you have hit a special co= rner<br> >> case that nobody else has yet found.<br> ><br> ><br> > I think so. I have to say that I use standard syncrepl, not delta-sync= repl.<br> ><br> ><br> >><br> >> The best thing you could do would be to setup a small self contain= ed<br> >> test case to illustrate the problem.<br> >><br> ><br> > I will try to, but seems really easy to reproduce : configure master a= nd<br> > slave with ppolicy, lock an account in slave, update same account on<b= r> > master (change description) a first time and a second time.<br> <br> </div>are you sure the account lock actually arrives on the master ?<br> <br> Are you using olcPPolicyForwardUpdates to actually get the account<br> locked on the master and not only on the slaves ?<br> <br> If you do not have all the lock attributes on the master and you modify<br> the entry it will get replaced on the slaves.<br> <br> Can you post your master and slave configs somewhere ?<br> <div class=3D"im"><br></div></blockquote><div><br><br></div><div>I sent it = by mail but I think it is too big and queued. So here is all configuration = and test result:<br><br><a href=3D"http://pastebin.com/earKiHnH">http://pas= tebin.com/earKiHnH</a><br> <br></div><div>Cl=E9ment.<br></div></div></div></div> --089e0160b79ae9bb0c04edcfeff1--

1 0

Re: (ITS#7766) Account unlocked in slave after two modifications on a master (overlay ppolicy)
by ck＠cksoft.de 18 Dec '13

18 Dec '13

This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --4178219828-444410844-1387368134=:27797 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Hi, On Wed, 18 Dec 2013, Clément OUDOT wrote: <snipp/> > Well, I checked that the pwdLockoutDuration was correctly set (The value > in my case is 1200, so 20 minutes, much more than my tests). Other > proof, the values of pwdFailureTime are not erased, but replaced by > those of the master. > > >> It is of course also quite possible that you have hit a special corner >> case that nobody else has yet found. > > > I think so. I have to say that I use standard syncrepl, not delta-syncrepl. > > >> >> The best thing you could do would be to setup a small self contained >> test case to illustrate the problem. >> > > I will try to, but seems really easy to reproduce : configure master and > slave with ppolicy, lock an account in slave, update same account on > master (change description) a first time and a second time. are you sure the account lock actually arrives on the master ? Are you using olcPPolicyForwardUpdates to actually get the account locked on the master and not only on the slaves ? If you do not have all the lock attributes on the master and you modify the entry it will get replaced on the slaves. Can you post your master and slave configs somewhere ? Greetings Christian -- Christian Kratzer CK Software GmbH Email: ck(a)cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer --4178219828-444410844-1387368134=:27797--

1 0

Re: (ITS#7766) Account unlocked in slave after two modifications on a master (overlay ppolicy)
by coudot＠linagora.com 18 Dec '13

18 Dec '13

On 16/12/2013 22:10, Christian Kratzer wrote: > Hi, > > On Mon, 16 Dec 2013, coudot(a)linagora.com wrote: >> Full_Name: Cl?ment OUDOT >> Version: 2.4.38 >> OS: GNU/Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (88.173.78.196) >> >> >> I have a simple setup with a master (overlay syncprov + overlay >> ppolicy) and a >> slave (syncrepl client, overlay ppolicy). >> >> 1. I lock my account in the slave >> 2. I change the description attribute of my account a first time in >> the master >> 3. My account is still locked in the slave >> 4. I change the description attribute of my account a second time in >> the master >> 5. My account is no more locked in the slave: the password policy >> operational >> attributes pwdFailureTime and pwdAccountUnlockTime were erased by the >> one of the >> master >> >> Seems like a control is done the first time that syncrepl update the >> entry (the >> first time, pwdAccountLockTime and pwdFailureTime are not erased), >> but the >> second time the control is not done. > > I have had a very similar setup for some time now and have never > observed this kind of behaviour from the ppolicy overlay. I am quite > confident it should work correctly in the situation you describe. > > There might be a valid reason for pwdAccountLockedtime and > pwdFailureTime attributes disappearing like perhaps expiry of > pwdLockoutDuration. Please see the account_locked() function in > servers/slapd/overlay/ppolicy.c for this. > Well, I checked that the pwdLockoutDuration was correctly set (The value in my case is 1200, so 20 minutes, much more than my tests). Other proof, the values of pwdFailureTime are not erased, but replaced by those of the master. > It is of course also quite possible that you have hit a special corner > case that nobody else has yet found. I think so. I have to say that I use standard syncrepl, not delta-syncrepl. > > The best thing you could do would be to setup a small self contained > test case to illustrate the problem. > I will try to, but seems really easy to reproduce : configure master and slave with ppolicy, lock an account in slave, update same account on master (change description) a first time and a second time. This behavior was detected by one of my customer, and I was able to reproduce it on my own computer. Clément.

1 0

(ITS#7769) [PATCH] Fix typo in slapd-meta manpage.
by jsynacek＠redhat.com 17 Dec '13

17 Dec '13

Full_Name: Jan Synacek Version: master OS: Linux - Fedora 19 URL: http://jsynacek.fedorapeople.org/openldap/jsynacek-20131217-0001-Fix-typo-i… Submission from: (NULL) (209.132.186.34) Fix for a typo in slapd-meta.5

1 0

Re: (ITS#7766) Account unlocked in slave after two modifications on a master (overlay ppolicy)
by ck＠cksoft.de 16 Dec '13

16 Dec '13

Hi, On Mon, 16 Dec 2013, coudot(a)linagora.com wrote: > Full_Name: Cl?ment OUDOT > Version: 2.4.38 > OS: GNU/Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (88.173.78.196) > > > I have a simple setup with a master (overlay syncprov + overlay ppolicy) and a > slave (syncrepl client, overlay ppolicy). > > 1. I lock my account in the slave > 2. I change the description attribute of my account a first time in the master > 3. My account is still locked in the slave > 4. I change the description attribute of my account a second time in the master > 5. My account is no more locked in the slave: the password policy operational > attributes pwdFailureTime and pwdAccountUnlockTime were erased by the one of the > master > > Seems like a control is done the first time that syncrepl update the entry (the > first time, pwdAccountLockTime and pwdFailureTime are not erased), but the > second time the control is not done. I have had a very similar setup for some time now and have never observed this kind of behaviour from the ppolicy overlay. I am quite confident it should work correctly in the situation you describe. There might be a valid reason for pwdAccountLockedtime and pwdFailureTime attributes disappearing like perhaps expiry of pwdLockoutDuration. Please see the account_locked() function in servers/slapd/overlay/ppolicy.c for this. It is of course also quite possible that you have hit a special corner case that nobody else has yet found. The best thing you could do would be to setup a small self contained test case to illustrate the problem. Greetings Christian -- Christian Kratzer CK Software GmbH Email: ck(a)cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer

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