Hi!
Out of curiosity: Why are you rebuilding the database in a cron job? Is it the inability of MDB to handle free space properly (i.e.: Your garbage collection)? Second: Why do you start the new database under a new name? Why not move the current one under a new name, create the new one with the same (old) name, then force slapd to reopen the (new) database?
Ulrich
Hallvard Breien Furuseth h.b.furuseth@usit.uio.no 02.01.19 16.03 Uhr >>>
We have a cn=config database with
olcDbDirectory: /ldap/var/db/foobar-<directory version>
A cron job in a quandary can clear things up thus: Rebuild the database in a new directory with slapadd, ldapmodify cn=config so olcDbDirectory points at the new DB directory, and finally throw away the old DB dir.
ldapmodify -H ldapi:// -Q -Y EXTERNAL <<EOF # hdb can have more "interesting" problems than mdb:-) dn: olcDatabase={3}hdb,cn=config changetype: modify replace: olcDbDirectory olcDbDirectory: /ldap/var/db/foobar-$NEW_DIR_VERSION EOF
Now if ldapmodify fails, what should the cron job do - in addition to alerting a human?
When can it assume that the new DB dir is unused and can be deleted? ...that the old DB dir can be deleted?
How complicated code should I have to examine the situation and decide what to do?
Do we just wait for a human to fix things? Or is it time to restart slapd? Yet that can fail too, so next question becomes what to do next - reboot? A cron job which keeps escalating the problem in order to fix it makes me nervous - LDAP must be up. It's load balanced, so a single server in trouble is OK - unless the problem is a systemic one so all servers hiccup at once.
Do others have something like this implemented?