[Date Prev][Date Next]
Re: Two contextCSNs
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:
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.
Then I misunderstood your post:
I read it as the SID of "00" from 2.3 was not a correct CSN from a 2.4
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:
No, that message refers to a bug that is definitely fixed in 2.4.20.
You have 8 CPUs?
Actually - I have 8 hypertreaded CPUs
mpstat -P ALL show 16 cores.
# Allow root to configure slapd via ldapi:///
Neatness nit: your TLSVerifyClient is obviously under the wrong comment.
Oh... yeah sure. I've messed around a bit after that comment was written.
The rootdn is always unlimited, this clause is superfluous.
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.
The above text was pasted from "ps ax" output.
The server is started from /etc/init.d/slapd and options come from
* The I load the following LDIF files on server 1 with
$ ldapadd -YEXTERNAL -H ldapi:/// -f<LDIFFILE>
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: <=
Dec 4 14:14:30 server1 slapd: 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: send_ldap_result: conn=1004 op=1 p=3
Dec 4 14:14:30 server1 slapd: send_ldap_result: err=0 matched=""
Dec 4 14:14:30 server1 slapd: syncprov_search_response:
The "ignored" message was let me to suspect the message you say has been
fixed as ITS#6367