Peter Mogensen wrote:
What I do is: 1) Took an slapcat generated LDIF from a 2.3.x setup 2) Removed all entryCSN and contextCSN lines. 3) Ran "slapadd -S 1 -q -w -l ~/load_noCSN.ldif" on server-1 4) Did a "slapcat > toserver2.ldif" on server-1 5) Started server-1 and let applications create and modify objects. 6) Moved toserver2.ldif to server-2. 7) Ran slapadd -q -l toserver2.ldif on server-2 8) Started server-2 Now - I would expect the objects created on step 5 to appear after a while on server-2. They are not.
I have discovered, that after load on server-1, the first thing I usually to is to modify the userPassword attribute of the database root object. userPassword is not used by syncrepl, only by an client application. syncrepl uses cn=config which is rootdn in both cn=config and the database.
This of course changes the entryCSN of the root object: Before the modification: entryCSN: 20091202100930.380800Z#000000#001#000000 contextCSN: 20091202100930.696427Z#000000#001#000000 After the modification: contextCSN: 20091202100930.696427Z#000000#001#000000 userPassword:: BASE64 entryCSN: 20091202101058.188515Z#000000#001#000000 modifiersName: cn=config modifyTimestamp: 20091202101058Z What surprises me is that contextCSN does not change. Shouldn't contextCSn change when entryCSN of the root object changes? /Peter