Hello
I am using an opeldap DB for authentication on Linux clients. Twice in recent months we have had "issues" with power loss, on recovery recent (and not so recent) changes have been completely lost and had to be re-added manually. The number of users is not large, 60 or so. But still ....
I have read a lot on this, and understand that the issue is to do with the bdb backend, checkpoints and the like. However there seems to be some contradictory advice, and the getting to the core issue and resolving it has proved difficult.
Today I returned to look at the issue, and first of all I thought I would dump the db using slapcat. This I did. But the dump is incomplete - users who I know exist in the "people" container are not listed. For example I know the account xxx exists, I can login on a client using that account, I can change the password, the new password works on other clients straight away, but the account info does not appear at all in slapcat out.
If I db_stat -l in /var/lib/ldap I get
# db_stat -l 40988 Log magic number. 8 Log version number. 32KB Log record cache size. 0600 Log file mode. 10Mb Current log file size. 27KB 854B Log bytes written. 27KB 854B Log bytes written since last checkpoint. 49 Total log file writes. 0 Total log file write due to overflow. 49 Total log file flushes. 1 Current log file number. 89679 Current log file offset. 1 On-disk log file number. 89679 On-disk log file offset. 1 Max commits in a log flush. 0 Min commits in a log flush. 96KB Log region size. 0 The number of region locks granted after waiting. 826 The number of region locks granted without waiting.
I admit I don't really understand the above, not the real purpose/function of the __db.XXX and log.XXXXXX files.
If I do db_printlog I can see entries corresponding to the password changing above, i.e.
repl: 0x10 shadowLastChange0 0x1 0x5 140980 0 0xc userPassword0 0x1 0x14 {crypt}452R6o6ONphks0 0 0x8 entryCSN0 0x1 20080807183642Z#000001#00#0000000 0 0xd modifiersName0 0x1 .uid=xxx,ou=people,dc=company,dc=com0 0x1 .uid =xxx,ou=people,dc=company,dc=com0 0xf modifyTimestamp0 0x1 0xf 200808 071836
Ideas? I am afraid whatever changes we are making here as going to get lost somewhere if we lose power again. Perhaps other db_tools can help me, but I am afraid I make things worse. I have built a parallel VM, with the same versions, that I can use for testing.
We have the "checkpoint 1024 5" enabled in /etc/openldap/slapd.conf, but I've read that as we are using 2.2.x this does not have the "obvious" meaning you might think.
TiA Kevin
PS: I am running the following versions
# rpm -q openldap2 db openldap2-2.2.24-4.12 db-4.2.52-86.3
on SLES9+sp2. We are committed to staying with that platform for compatibility reasons.