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.