--On Tuesday, November 7, 2023 12:56 PM +0000 falgon.comp@gmail.com wrote:
Hello, sorry for the delay. Thank's for the answers,
Generally, with something like lastbind, you'll run into collissions of the timestamp, which will cause a lot of havoc with replication. It is not the only case where this can occur. I highly advise reading the caveats in the admin guide about MPR replication.
Yes, that's what we thought at first, but with the various tests we've carried out, we're doubtful about the collision problem. When testing with a single account that BIND more than 500 times per second, we can't reproduce the problem. The same applies to 10 accounts looping at 500 BIND/s.
So I'm looking at your configuration and have some question:
a) olcPasswordCryptSaltFormat: $6$rounds=10000$%.16s -> Why are you using crypt passwords? OpenLDAP ships with multiple, secure module for password hashing, such as argon2. I'd advise using that. Note that crypt is non-portable.
b) olcLogLevel: stats sync
This generally should be:
olcLogLevel: stats olcLogLevel: sync
c) olcPasswordHash: {CRYPT} -> See (a)
d) I'd suggest not using a root password at all for cn=config, and use EXTERNAL auth over ldapi. If you are going to use one, upgrade to argon2
e) Why do you have separate credentions for the monitor db?
f) Delete this index: olcDbIndex: pwdLastSuccess eq,pres
g) olcSpReloadHint: TRUE -> This setting should *not* be on the main DB, delete it from dn: olcOverlay={0}syncprov,olcDatabase={2}mdb,cn=config
h) For your benchmark test, this is probably not frequent enough, as the purge will never run since you're saying only data > 1 day old: olcAccessLogPurge: 01+00:00 00+04:00
i) For the accesslog DB, are you sure this is a large enough size? olcDbMaxSize: 2147483648 or are you hitting 2GB?
Also it appears you're running this test on two slapds running on the same server? That's an incredibly bad idea, since the I/O will conflict massively between the two processes writing to disk.