openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

Re: (ITS#4813) glue/syncrepl
by hyc＠symas.com 25 Jan '07

25 Jan '07

hyc(a)symas.com wrote: > Hm, in re-reading ITS#4626, I see a pertinent detail in followup #2. I think > I understand part of the problem. > > The particular entry was modified after the current refresh session began, so > that entry is omitted from the current refresh results. Since the entry is > actually missing from the refresh data, the consumer treats it as deleted. > Since the entry has children, it cannot actually be deleted, so it gets > turned into a glue entry. > > So there's two issues - the provider should still send the UUID of the entry, > so that the consumer doesn't consider it deleted. But also, this problem > ought to have self-corrected. Once the replication transitioned from Refresh > to Persist phase, the modified entry should have been sent to the consumer, > and the glue entry should have been replaced by the correct data. > > Looks like both problems are in the syncprov overlay. syncprov.c is now patched in HEAD to always send the UUIDs of the present entries. That appears to prevent the problem from arising. It's a bit difficult to automate a test for this because it requires such exact timing; a modification must occur on the provider while the consumer is just beginning its refresh search. Currently I can only test this by inserting a Debug message and a sleep() in the provider to indicate that the consumer is connected, and to give time to issue a modification. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4814) Tree Archiving
by ando＠sys-net.it 25 Jan '07

25 Jan '07

hyc(a)symas.com wrote: > wells_robert_frank(a)yahoo.com wrote: >> --0-2146048140-1169674999=:43135 >> Content-Type: text/plain; charset=iso-8859-1 >> Content-Transfer-Encoding: 8bit >> >> Apologies - >> >> This did in fact work. I had not been aware of the backend DB functionality. > > Apparently few people are, since most other LDAP servers don't support this > part of the LDAP specification. Although he claimed he needed subtree rename, in his example all was needed was just plain rename, which has been supported by OpenLDAP since ever (when LDAPv3 introduced rename, i.e. modrdn with new rdn). p.

1 0

Re: (ITS#4813) glue/syncrepl
by hyc＠symas.com 25 Jan '07

25 Jan '07

hyc(a)symas.com wrote: > Allan E. Johannesen wrote: >>>>>>> "hyc" == Howard Chu <hyc(a)symas.com> writes: >> hyc> Since you mention that this occurs more often in 2.3.33 than in "previous >> hyc> releases" - what previous version are you comparing to? >> >> Well, I should have said I've never seen it before. I've generally been >> running the new releases within a day of release, and I rebuild the data at >> each release, so everything starts clean. Therefore, it _may_ have existed >> previously, but never showed up in the days during which the given releases >> ran. >> >> I guess I only mentioned that since someone saw it several releases ago in a >> different ITS. I never saw it before. >> In 2.3.33, it happened right after loading the data. I thought I did it wrong, >> so I loaded things again and it was fine. After some days, though, it (meaning >> the change to "objectClass: glue") happened again. > > The only change to syncrepl between 2.3.32 and .33 was one or two debug > messages, no functional changes. In 2.3.32 there was no change to syncrepl at > all (the bug in ITS#4790 was in connection.c, not syncrepl.c). The only > change in 2.3.31 was also in debug messages, not functional changes. So as > unlikely as it seems, at the moment this appears to be a coincidence and the > bug must be older. > > If you see this happening repeatedly, turn on the sync debug level and > capture that output for a while. When you notice the problem, you should also > see some number of "syncrepl_del_nonpresent" messages in the log. We'll > probably need to see a large chunk of the log to be able to follow the > sequence of events. Hm, in re-reading ITS#4626, I see a pertinent detail in followup #2. I think I understand part of the problem. The particular entry was modified after the current refresh session began, so that entry is omitted from the current refresh results. Since the entry is actually missing from the refresh data, the consumer treats it as deleted. Since the entry has children, it cannot actually be deleted, so it gets turned into a glue entry. So there's two issues - the provider should still send the UUID of the entry, so that the consumer doesn't consider it deleted. But also, this problem ought to have self-corrected. Once the replication transitioned from Refresh to Persist phase, the modified entry should have been sent to the consumer, and the glue entry should have been replaced by the correct data. Looks like both problems are in the syncprov overlay. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4813) glue/syncrepl
by hyc＠symas.com 25 Jan '07

25 Jan '07

Allan E. Johannesen wrote: >>>>>> "hyc" == Howard Chu <hyc(a)symas.com> writes: > > hyc> Since you mention that this occurs more often in 2.3.33 than in "previous > hyc> releases" - what previous version are you comparing to? > > Well, I should have said I've never seen it before. I've generally been > running the new releases within a day of release, and I rebuild the data at > each release, so everything starts clean. Therefore, it _may_ have existed > previously, but never showed up in the days during which the given releases > ran. > > I guess I only mentioned that since someone saw it several releases ago in a > different ITS. I never saw it before. > > These are the build times of the past few releases: > > drwxrwxr-x 10 imphss 2000 4096 Dec 19 08:57 .snapshot/weekly.0/openldap-2.3.31/ > drwxrwxr-x 10 imphss 2000 4096 Jan 7 10:33 .snapshot/weekly.0/openldap-2.3.32/ > drwxrwx--- 10 aej 101 4096 Jan 18 14:29 .snapshot/weekly.0/openldap-2.3.33/ > > In 2.3.33, it happened right after loading the data. I thought I did it wrong, > so I loaded things again and it was fine. After some days, though, it (meaning > the change to "objectClass: glue") happened again. The only change to syncrepl between 2.3.32 and .33 was one or two debug messages, no functional changes. In 2.3.32 there was no change to syncrepl at all (the bug in ITS#4790 was in connection.c, not syncrepl.c). The only change in 2.3.31 was also in debug messages, not functional changes. So as unlikely as it seems, at the moment this appears to be a coincidence and the bug must be older. If you see this happening repeatedly, turn on the sync debug level and capture that output for a while. When you notice the problem, you should also see some number of "syncrepl_del_nonpresent" messages in the log. We'll probably need to see a large chunk of the log to be able to follow the sequence of events. > > hyc> Please provide the relevant section of your slave slapd.conf - the > hyc> database clause and its syncrepl statement at least. Are there any ACLs on > hyc> the provider that would prevent the slave from seeing parts of the > hyc> affected entries? > > In the client: > > > database bdb > suffix "dc=WPI,dc=EDU" > rootdn "cn=Manager,ou=Access,dc=wpi,dc=edu" > checkpoint 256 15 > > # limits for different users > > limits dn=wpieduPersonUUID=2af586df6800b3389cbe7bcbf2a920df,ou=People,dc=WPI,dc=EDU size=unlimited time=unlimited > limits dn=cn=application,ou=access,dc=wpi,dc=edu size=unlimited time=unlimited > limits dn="cn=pam,ou=access,dc=wpi,dc=edu" size=unlimited time=unlimited > limits users size=200 time=10 > limits anonymous size=20 time=1 > > directory /var/openldap-data > > # replication > > syncrepl rid=1 provider=ldap://ldapv2.wpi.edu type=refreshAndPersist retry="60 +" > searchbase="dc=WPI,dc=EDU" scope=sub starttls=yes bindmethod=sasl saslmech=gssapi > > > > Its keytab is k5start'd as ldap-manager, this is from the provider: > > > > sasl-regexp uid=ldap-manager/.*,cn=WPI.EDU,cn=gssapi,cn=auth ldap:///ou=access,dc=WPI,dc=EDU??one?(cn=manager) > sasl-regexp uid=(.*),cn=WPI.EDU,cn=gssapi,cn=auth ldap:///ou=people,dc=WPI,dc=EDU??one?(uid=$1) > > ####################################################################### > # bdb database definitions > ####################################################################### > > database bdb > suffix "dc=WPI,dc=EDU" > rootdn "cn=Manager,ou=Access,dc=wpi,dc=edu" > checkpoint 256 15 > -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4814) Tree Archiving
by hyc＠symas.com 25 Jan '07

25 Jan '07

wells_robert_frank(a)yahoo.com wrote: > --0-2146048140-1169674999=:43135 > Content-Type: text/plain; charset=iso-8859-1 > Content-Transfer-Encoding: 8bit > > Apologies - > > This did in fact work. I had not been aware of the backend DB functionality. Apparently few people are, since most other LDAP servers don't support this part of the LDAP specification. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4815) TLSCipherSuite conversion to olcTLSCipherSuite
by hyc＠symas.com 24 Jan '07

24 Jan '07

erici(a)motown.cc.utexas.edu wrote: > Full_Name: Eric Irrgang > Version: 2.3.28 > OS: Solaris 9 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.83.217.14) > > > TLSCipherSuite in slapd.conf does not get converted into olcTLSCipherSuite in > cn=config Thanks for the report. The libldap function to retrieve this option was actually missing. Fixed now in HEAD. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4815) TLSCipherSuite conversion to olcTLSCipherSuite
by erici＠motown.cc.utexas.edu 24 Jan '07

24 Jan '07

Full_Name: Eric Irrgang Version: 2.3.28 OS: Solaris 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.83.217.14) TLSCipherSuite in slapd.conf does not get converted into olcTLSCipherSuite in cn=config

1 0

Re: (ITS#4814) Tree Archiving
by wells_robert_frank＠yahoo.com 24 Jan '07

24 Jan '07

--0-2146048140-1169674999=:43135 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Apologies - This did in fact work. I had not been aware of the backend DB functionality. Regards, RFW Quanah Gibson-Mount <quanah(a)stanford.edu> wrote: --On Wednesday, January 24, 2007 6:55 PM +0000 wells_robert_frank(a)yahoo.com wrote: > Full_Name: Bob Wells > Version: 2.3.33 > OS: Linux RH 4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (63.81.96.200) Isn't this just the modrdn operation? It is supported when using the back-hdb database. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html --0-2146048140-1169674999=:43135 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Apologies - This did in fact work.  I had not been aware of the backend DB functionality. Regards, RFW Quanah Gibson-Mount <quanah(a)stanford.edu> wrote:<blockquote class="replbq" style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"> --On Wednesday, January 24, 2007 6:55 PM +0000 wells_robert_frank(a)yahoo.com wrote: > Full_Name: Bob Wells > Version: 2.3.33 > OS: Linux RH 4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (63.81.96.200) Isn't this just the modrdn operation? It is supported when using the back-hdb database. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html </blockquote> --0-2146048140-1169674999=:43135--

1 0

Re: (ITS#4813) glue/syncrepl
by hyc＠symas.com 24 Jan '07

24 Jan '07

aej(a)wpi.edu wrote: > Full_Name: Allan E. Johannesen > Version: 2.3.33 > OS: Linux EL 4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (130.215.24.208) > > > I have two synrepl slaves and entries in both of them seem to degrade, over > time, into "objectClass: glue" entities. > > These entries are not updated, so this degradation appears to be autonomous in > the slaves. The slaves have identical problems, the master retains the > structure of the entries. > > I see IS#4626 which has this same sort of problem, and perhaps I should have > followed on to that, but I can say that this problem must be much worse in > 2.3.33 than previously, since this has only happened to me since upgrading to > this release. > > My ou people is reduced to glue as is the ou access. The simplesecurity object > is gone entirely from the slaves' database. This is only the beginning of the > display of differences in the data. > > These entries were not modified since the database creation, and the > disintegration only occurs in the slaves. > > Let me know if more info is needed. Since you mention that this occurs more often in 2.3.33 than in "previous releases" - what previous version are you comparing to? Please provide the relevant section of your slave slapd.conf - the database clause and its syncrepl statement at least. Are there any ACLs on the provider that would prevent the slave from seeing parts of the affected entries? -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4814) Tree Archiving
by quanah＠stanford.edu 24 Jan '07

24 Jan '07

--On Wednesday, January 24, 2007 6:55 PM +0000 wells_robert_frank(a)yahoo.com wrote: > Full_Name: Bob Wells > Version: 2.3.33 > OS: Linux RH 4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (63.81.96.200) Isn't this just the modrdn operation? It is supported when using the back-hdb database. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

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