Howard Chu wrote:
There is no need for your step #2.
(step #2 is removing all entryCSN, contextCSN lines).
I did so because the SID of CSN values from the 2.3.30 dump is 00: entryCSN: 20071214130312Z#000000#00#000000
Current SID is 001 or 002.
Given a valid slapcat from OpenLDAP 2.3 you should be able to slapadd it directly in 2.4 without using -S or -w in your step #3. Therefore you don't need step #4.
Ok. Then I misunderstood your post: http://www.openldap.org/lists/openldap-technical/200911/msg00066.html
I read it as the SID of "00" from 2.3 was not a correct CSN from a 2.4 backup.
So since, it's not the procedure, it must be either my configuration or a bug. I'll assume it's my configuration though I suspect this message is about the same problem: http://www.openldap.org/lists/openldap-software/200911/msg00058.html
No, that message refers to a bug that is definitely fixed in 2.4.20. (ITS#6367)
ok.
tool-threads 8
You have 8 CPUs?
Yes. Actually - I have 8 hypertreaded CPUs mpstat -P ALL show 16 cores.
# Allow root to configure slapd via ldapi:/// TLSVerifyClient demand authz-regexp "gidNumber=0\+uidNumber=0,cn=peercred,cn=external,cn=auth" "cn=config"
Neatness nit: your TLSVerifyClient is obviously under the wrong comment.
Oh... yeah sure. I've messed around a bit after that comment was written.
limits dn.exact="cn=config" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited
The rootdn is always unlimited, this clause is superfluous.
Ahh.. thanks. It's a remnant from having a special user for syncrepl. I change to using rootdn to simplify ACLs.
- Then I start slapd on both servers. $ /usr/sbin/slapd -h ldapi:/// ldaps://server1.example.com:636/ \ ldap://server1.example.com/ -g openldap -u openldap \ -F /etc/ldap/slapd.d -4
That won't work in typical Unix shells without quotes.
Yeah... actually. The above text was pasted from "ps ax" output. The server is started from /etc/init.d/slapd and options come from /etc/default/slapd.
- The I load the following LDIF files on server 1 with $ ldapadd -YEXTERNAL -H ldapi:/// -f<LDIFFILE> In sequence:
============================== dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: refint ============================= dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: back_bdb ==============================
Could have just used one mod request for both of those. Why are you loading back-bdb when you're just using back-hdb and it's already loaded?
Because I've tried to reproduce the problem with both back_hdb and back_bdb. I first used back_hdb (hence configured in slapd.conf), then switched to back_bdb, which is why I added the above ModuleLoad LDIF, reproduced the problem and switched back to HDB. Of course, now the last bit above is redundant.
No idea what that is. Your debug logs should tell what it was doing.
I've tried a lot of loglevels and look for anything suspicious. I noticed (as I mentioned) this: bdb_index_read: failed (-30989)
... and another thing I find weird. The last entry in the LDIF is special in the log, like:
======================================================= Dec 4 14:14:30 server1 slapd[5433]: <= bdb_dn2id_children("cn=me,ou=3,uid=apm,o=net,cn=data,dc=example,dc=com"):no (-30989) Dec 4 14:14:30 server1 slapd[5433]: Entry cn=me,ou=3,uid=apm,o=net,cn=data,dc=example,dc=com changed by peer, ignored Dec 4 14:14:30 server1 slapd[5433]: send_ldap_result: conn=1004 op=1 p=3 Dec 4 14:14:30 server1 slapd[5433]: send_ldap_result: err=0 matched="" text="" Dec 4 14:14:30 server1 slapd[5433]: syncprov_search_response: cookie=rid=003,sid=001,csn=20091204141336.982142Z#000000#001#000000 ========================================================
The "ignored" message was let me to suspect the message you say has been fixed as ITS#6367
/Peter