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?
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?
On 1/5/19 2:38 AM, Ulrich Windl wrote:
Out of curiosity: Why are you rebuilding the database in a cron job?
Our LDAP is not the authorative data store. We generate LDIFs on the fly to feed to ldapmodify in a cron job. Once in a while that doesn't work - some error happens, or a change which the automatics don't cover. Then the cron job instead applies the change by building a fresh LDAP DB from a full generated LDIF.
Is it the inability of MDB to handle free space properly (i.e.: Your garbage collection)?
No, not relevant to this issue. Though yes, GC is a concern. And also, since I'm currently coding error handling, I want more intersting errors to handle than MDB can "deliver".
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?
Then we'd have to stop slapd before moving the old DB, and slapd would need to stay down during slapadd. So instead we point a temporary config at a new dir, slapadd to that dir, and give the new dir to slapd.
The crude but safe and simple way is then indeed to stop slapd, rename the new dir into place, and restart slapd. Changing olcDbDirectory is nicer in that we do not need to stop slapd. But instead there we get a bunch of new possible error situations to handle. Automatically, when most of those situations smell "ask for human help".
openldap-technical@openldap.org
-
Hallvard Breien Furuseth -
Ulrich Windl