--On Tuesday, November 7, 2023 12:56 PM +0000 [email protected] 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.
