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
-
hyc＠symas.com