Hi
.. dumping your entire DB via ldapsearch to an LDIF file.
I did this via:
ldapsearch -LLL -x -W \ -D "my_rootdn" "objectClass=*" > all-dap-info
then copied this file to a sles9 test server and on that test server
stopped ldap cleared out all files in /var/lib/ldap slapadd -l /path/to/all-dap-info started ldap
And my own account/password, which I changed before making this transition, worked on a test client set to auth against the test server. slapcat also now sees the entries that it did not see before. I guess that is all good news. I've got no way to know if all the passwords are the most current ones (from the users standpoint) I guess, and I lost the last changed time info too.
After doing so I get this in /var/lib/ldap/
# 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. 299KB 531B Log bytes written. Log bytes written since last checkpoint. 99 Total log file writes. 1 Total log file write due to overflow. 98 Total log file flushes. 1 Current log file number. 306707 Current log file offset. 1 On-disk log file number. 306707 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. 1361 The number of region locks granted without waiting.
Does that look kind of what it should (there are 81 entries in the ldap db)
What cron entries running db_something, or DB_CONFIG settings, should I use to keep the DB in good order, up to date, even in case of a power outage, given my relatively small, ldap DB?
And thanks for answers so far.
Kevin
--On Friday, August 08, 2008 12:52 AM +0200 Kevin Maguire k.c.f.maguire@gmail.com wrote:
Hi
.. dumping your entire DB via ldapsearch to an LDIF file.
I did this via:
ldapsearch -LLL -x -W \ -D "my_rootdn" "objectClass=*" > all-dap-info
then copied this file to a sles9 test server and on that test server
stopped ldap cleared out all files in /var/lib/ldap slapadd -l /path/to/all-dap-info started ldap
And my own account/password, which I changed before making this transition, worked on a test client set to auth against the test server. slapcat also now sees the entries that it did not see before. I guess that is all good news. I've got no way to know if all the passwords are the most current ones (from the users standpoint) I guess, and I lost the last changed time info too.
You could request the operational attrs too, that way you'd keep it:
ldapsearch -LLL -x -W \ -D "my_rootdn" "objectClass=*" '*' '+' > all-dap-info
After doing so I get this in /var/lib/ldap/
# 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. 299KB 531B Log bytes written. Log bytes written since last checkpoint. 99 Total log file writes. 1 Total log file write due to overflow. 98 Total log file flushes. 1 Current log file number. 306707 Current log file offset. 1 On-disk log file number. 306707 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. 1361 The number of region locks granted without waiting.
Does that look kind of what it should (there are 81 entries in the ldap db)
That doesn't really correlate. Size of DB depends on a lot of things, like indices & entry size.
What cron entries running db_something, or DB_CONFIG settings, should I use to keep the DB in good order, up to date, even in case of a power outage, given my relatively small, ldap DB?
You need to make sure and run db_recover after any power outage, before starting slapd. But since (as you noted already) checkpoint does not work correctly in OpenLDAP 2.2, this is of limited benefit. What you really need to do is invest the time to move to either OpenLDAP 2.3 or OpenLDAP 2.4, both of which have auto-recover.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
openldap-software@openldap.org