On 10/22/2009 10:05 AM, Rich Megginson wrote: > Brodie, Kent wrote: >> Rich: Thanks for the debugging help! I'm still stuck, as I am not >> sure exactly what I am looking at in terms of messages. I can see that >> the same uniqueid 4922d291-be7a11de-adce9eef-94681f9f keeps failing, but >> the message surrounding that error are anything but clear to me. > Try using the /usr/bin/cl-dump tool to dump the changelog (man > cl-dump) - look for uniqueid 4922d291-be7a11de-adce9eef-94681f9f and > dn="uid=jgretzon,ou=spine,dc=hmgc,dc=mcw,dc=edu" and > csn=4ae06697000000020000 > > Rich-- ok, we're getting closer. cl-dump told me lots, and when I looked for all three items together (uniqueid, uid, and csn), I found this entry: changetype: modify replgen: 4a7758f2000000010000 csn: 4ae06697000000020000 nsuniqueid: 4922d291-be7a11de-adce9eef-94681f9f dn: uid=jgretzon,ou=spine,dc=hmgc,dc=mcw,dc=edu change:: replace: retryCountResetTime retryCountResetTime: 20091022141509Z - replace: passwordRetryCount passwordRetryCount: 1 So, there's some sort of passwordretry entry that's bogus (not sure why)-- I guess now my question is, now that I've found what the error entry is that's giving replication fits, what do I do about it? I really appreciate the help--- this is good stuff for the email list archives for others to see when they have something like this.
