Antw: How should a cron jobb handle modify(cn=config) error?

["Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de>]

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?

-- 
Hallvard