[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#4813) glue/syncrepl



Allan E. Johannesen wrote:
>>>>>> "hyc" == Howard Chu <hyc@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/