Effectivement le slapd version woody (et même pendant un bout de temps sur sarge), et impossible d'en trouver la cause: sur des suppression/ajout/edition dans l'arbre, la requete ne finissait pas et le serveur LDAP ne répondait plus à aucune requete, un slapcat s'arretait dès le début, à croire qu'il n'y avait plus rien dans le LDAP. Depuis un certain temps, j'ai changé de backend LDAP avec ldbm (au lieu de dbm). Il n'est pas recommandé par les auteurs de OpenLDAP mais les debianistes le trouvent assurément plus stable. Depuis que je l'ai mis, plus aucun blocage de requete. Mais de toute façon, avec les versions récentes de la sarge, c'était de moins en moins fréquent (mais quand même random). D'ailleurs, cela m'a permis d'optimiser le backup:
Comment restaurer un serveur LDAP en moins de 5min ?
- Etape 1: faire une sauvegarde dans un fichier LDIF de manière journaliere (un slapcat dans un cron par exemple).
- Etape 2: au moment du crash, arreter le serveur LDAP (de toute manière il répond à aucune requete). Virer tous les *.db dans /var/lib/ldap, et faire un slapadd du fichier LDIF de backup.
- Etape 3: redémarrer le serveur LDAP.
D'ailleurs avec un peu de dextérité, en 1min c'est fait ;)
[^] # Re: Si LDAP c etait bien
Posté par EppO . En réponse au journal LDAP, c bien ?. Évalué à 0.
Comment restaurer un serveur LDAP en moins de 5min ?
- Etape 1: faire une sauvegarde dans un fichier LDIF de manière journaliere (un slapcat dans un cron par exemple).
- Etape 2: au moment du crash, arreter le serveur LDAP (de toute manière il répond à aucune requete). Virer tous les *.db dans /var/lib/ldap, et faire un slapadd du fichier LDIF de backup.
- Etape 3: redémarrer le serveur LDAP.
D'ailleurs avec un peu de dextérité, en 1min c'est fait ;)