www.menfin.net
français
GEEK ZONE
Calendrier12 novembre 2007
Commentaires 1 Commentaire
1. Le livre d’un geek précédent suivant man pages

Problème dans la mise à jour openLDAP

Suite à une mise à jour de mon annuaire Ldap, j’ai eu une impossibilité de relancer le service. Quelques messages obscures, peu d’informations sur google et encore moins de solutions satisfaisantes...

Un annuaire est un outil très pratique pour le geek que je suis. Il me permet de stocker l’ensemble de mes contacts par catégories et d’y avoir directement accès par Thunderbird.

Le problème est apparu lors de la mise à jour du paquet openldap-2.3.38 ou db-4.5.20 (berkleyDB). Impossible de redémarrer le service.

Voici les logs...


lune slapd[22421]: backend_startup_one: starting "dc=menfin,dc=net"
lune slapd[22421]: bdb_db_open: dc=menfin,dc=net
lune slapd[22421]: bdb_db_open: dbenv_open(/var/lib/openldap-data)
lune slapd[22421]: bdb_db_open: Database cannot be opened, err 22. Restore from backup!
lune slapd[22421]: ====> bdb_cache_release_all
lune slapd[22421]: bdb(dc=menfin,dc=net): DB_ENV->lock_id_free interface requires an environment configured for the locking subsystem
lune slapd[22421]: bdb(dc=menfin,dc=net): txn_checkpoint interface requires an environment configured for the transaction subsystem
lune slapd[22421]: bdb_db_close: txn_checkpoint failed: Invalid argument (22)
lune slapd[22421]: backend_startup_one: bi_db_open failed! (22)
lune slapd[22421]: slapd shutdown: initiated
lune slapd[22421]: ====> bdb_cache_release_all
lune slapd[22421]: bdb_db_close: alock_close failed
lune slapd[22421]: slapd destroy: freeing system resources.
lune slapd[22421]: slapd stopped.
lune slapd[22421]: connections_destroy: nothing to destroy.

Après des recherches infructueuses sur les listes, les forums (ici par exemple) et google, je me suis orienté pour restaurer la base de donnée via les fichiers brutes.

Pour cela, deux outils m’ont été précieux ! La sauvegarde a été faite par db4.5_dump (ou db_dump) et la réinsertion des données db4.5_load (db_load).

Pour automatiser le tout, j’ai créé ce petit script :

  1. #!/bin/bash
  2. # We are sure to stop the service
  3. /etc/init.d/slapd stop
  4. cd /var/lib/openldap-data/
  5. mkdir backup
  6. cp -p * backup
  7. for x in *.bdb
  8. do
  9.         echo "dumping: $x to backup/$x.txt"
  10.         db4.5_dump -k -f backup/${x}.txt ${x} && rm -f ${x}
  11. done
  12. rm alock __db.* log.*
  13. # start the service with empty db to recreate needed files
  14. /etc/init.d/slapd start
  15. sleep 5
  16. # stop the service to close all opened files
  17. /etc/init.d/slapd stop
  18. for x in *.bdb
  19. do
  20.         echo "restoring: $x with backup/$x.txt"
  21.         db4.5_load -f backup/${x}.txt ${x}
  22. done

L’astuce de l’ensemble consiste à faire démarrer openLDAP sans les fichiers de base de données pour que celui-ci les crée au démarrage. Puis, nous stoppons à nouveau le service et restaurons le contenu dans les fichiers au nouveau format.

edit 24/11/2007 :

Il est possible qu’il n’y ai pas de db5*. Cela dépend souvent de la distribution utilisée. dans ce cas la, il faut chercher ce qui suit :
db_*
db4*

Le plus simple à mon avis :
ls /usr/bin/ | grep ^db


1 commentaire de mouche. (afficher)
Réagissez maintenant à cet article (afficher)
Crédits
Adoptez Firefox Profile :: Coolphotoblogs.org Votez ! Valid XHTML 1.0 Strict Valid CSS! 8 Personnes suivant le site Site sans Pub © BobCaTT — 2003 - 2008