Lundi matin, une journée qui commence bien. Le service « slapd » étant arrêté, je me jette dans les logs et voilà ce que j’y trouve:
1 2 | bdb_db_open: unclean shutdown detected; attempting recovery. bdb_db_open: Recovery skipped in read-only mode. Run manual recovery if errors are encountered. |
Après quelques recherches sur « db_recover » et après avoir essayé de lire les pages man introuvables… je me lance à la sauvage:
1 | /etc/init.d/ldap stop |
1 | db_recover -v -h /var/lib/ldap |
1 | /etc/init.d/ldap start |
Le service repart, puis s’écroule quelques minutes plus tard en m’insultant de la même façon. Seule option restante: Récupérer les .bdb stocké sur la bande de sauvegarde de la veille:
1 | /etc/init.d/ldap stop |
A la recherche de mes fichiers:
1 | tar tvf /dev/st0 | grep *.bdb |
Ouf, tout est là: On restaure.
1 | tar xvf /dev/st0 var/lib/ldap |
Si, comme moi, vos fichiers font plus de 2Go, allez donc boire une cafetière de café.. ou prendre un Xanax..
1 | slapd -d 256 |
Je vous passe le tas de logs qu’il m’a vomi à ce moment précis -c’est plutôt bon signe- il est enfin lancé… et à l’air de s’y plaire. Attention à ne pas le stopper à l’aide d’un CTRL+C, ce qui pourrais causer une nouvelle corruption ! Pour cela on va lui demander plus poliment:
1 | kill -INT ‛cat /var/run/ldap/slapd.pid‛ |
Puis on relance, proprement:
1 | /etc/init.d/ldap start |
Note: n’oubliez pas de vérifier que les fichiers contenus dans le répertoire /var/lib/ldap appartiennent bien à ldap:ldap après la restauration, c’est du vécu..
bonjour adrien
voila je suis entrain de mettre en place un serveur openldap sous fedora 10 et lorsque je lance service ldap start
il m envoie les erreurs suivantes:
bdb_db_open: database « dc=glaizer,dc=net »: unclean shutdown detected; attempting recovery.
bdb_db_open: database « dc=glaizer,dc=net »: recovery skipped in read-only mode. Run manual recovery if errors are encountered.
bdb(dc=glaizer,dc=net): /var/lib/ldap/dn2id.bdb: file size not a multiple of the pagesize
bdb_db_open: database « dc=glaizer,dc=net »: db_open(/var/lib/ldap/dn2id.bdb) failed: Invalid argument (22).
bdb(dc=glaizer,dc=net): Database handles still open at environment close
bdb(dc=glaizer,dc=net): Open database handle: id2entry.bdb
bdb_db_close: database « dc=glaizer,dc=net »: close failed: Invalid argument (22)
backend_startup_one: bi_db_open failed! (22)
slap_startup failed (test would succeed using the -u switch)
stale lock files may be present in /var/lib/ldap
apparemment vous vous y connaissez bcp plus que moi qui suis debutant si vous avez des documents pour m aider ou des commandes pour resoudre ces erreurs priere de m aider
et merci
avez vous essayé le:
# db_recover -v -h /var/lib/ldap
oui
fedora ne reconnait pas db_recover :s
# db_recover -v -h /var/lib/ldap
bash: db_recover: command not found
ok, est ce que le paquet « db4.2-util » (ou une version différente) est installé ?
alors la aucune idée il sert a koi
voici ce que j ai obtenu en essayant de l installé
yum install db4.2-util
Modules complémentaires chargés : refresh-packagekit
fedora | 2.8 kB 00:00
updates | 2.3 kB 00:00
adobe-linux-i386 | 951 B 00:00
Configuration du processus d’installation
Traitement des options d’installation des paquetages
No package db4.2-util available.
Rien à faire
il sert a koi et sinon quelles sont les autres versions et merci
je ne connais pas trop fédora mais après quelques recherches l’utilitaire pourrais se nommer:
slapd_db_recover
il dit que y a pas de slapd_db_recover available
Malheureusement pour toi je ne connais pas du tout l’environnement LDAP sur Fedora, a mon avis pour résoudre ton problème il te faut trouver le paquet contenant l’outil db_recover ou bien le compiler depuis les sources..
pas de /usr/sbin/slapd_db_recover non plus ?
c bon j ai reformaté ma machine et la ça marche comme par enchantement :D
je te tiendrai au courant de mon evolution :p
merci bcp
bonjour me revoila avec une nouvelle erreur
:)
[root@localhost openldap]# ldapadd -W -D « cn=Manager,o=test,c=net » -xh localhost -f /etc/openldap/base.ldiff
Enter LDAP Password:
ldap_bind: Invalid DN syntax (34)
additional info: invalid DN
rebonjour j ai résolu l erreur précedente et la j ai celle ci
[root@localhost openldap]# ldapadd -W -D ‘cn=manager,dc=society,dc=net’ -xh localhost -f /home/anass/Bureau/society.txt
Enter LDAP Password:
ldap_bind: Invalid credentials (49)
et je m excuse pour le derangement
Comme l’erreur le dit: problème de mot de passe ;)
je l ai changé avec la commande slappasswd : {SSHA}WW2PMcKsh0ZVrFFSuwAtAXIUISAq1VIU
et remplacé dans le slapd.conf et dans base et tjrs le mm probleme
voici mon fichier base.ldif:
# Organization for Samba Base
dn: dc=society,dc=net
objectclass: dcObject
objectclass: organization
dc: glaizer
o: Samba 3
description: Samba 3
# Manager LDAP
dn: cn=manager,dc=society,dc=net
objectclass: organizationalRole
cn: manager
description: LDAP Manager
# Conteneur d’utilisateurs
dn: ou=Users,dc=society,dc=net
objectclass: top
objectclass: organizationalUnit
ou: Users
# Conteneur de machines
dn: ou=Computers,dc=society,dc=net
objectclass: top
objectclass: organizationalUnit
ou: Computers
# Administrateur
dn: cn=admin,ou=Users,dc=society,dc=net
cn: admin
objectclass: top
objectclass: organizationalRole
objectclass: simpleSecurityObject
userPassword: {SSHA}WW2PMcKsh0ZVrFFSuwAtAXIUISAq1VIU
voila adri c ma configuration et je vois pas prkoi ça ne marche pas :s
[root@localhost anass]# ldapadd -D « cn=manager,o=company,c=net » -W -f /etc/openldap/base.ldif
Enter LDAP Password:
SASL/DIGEST-MD5 authentication started
ldap_sasl_interactive_bind_s: Invalid DN syntax (34)
here is my ldap.conf:
# LDAP Defaults
#
# See ldap.conf(5) for details
# This file should be world readable but not world writable.
#BASE dc=example,dc=com
#URI ldap://ldap.example.com ldap://ldap-master.example.com:666
#SIZELIMIT 12
#TIMELIMIT 15
#DEREF never
URI ldap://127.0.20.1/
BASE dc=company,dc=net
TLS_CACERTDIR /etc/openldap/cacerts
[/SIZE][/SIZE]
my base.ldif is :
#Organization for Samba Base
dn: dc=company,dc=net
objectclass: dcObject
objectclass: organization
dc: company
o: Samba 3
description: Samba 3
# Manager LDAP
dn: cn=manager,dc=company,dc=net
objectclass: organizationalRole
cn: manager
description: LDAP Manager
# Conteneur d’utilisateurs
dn: ou=Users,dc=company,dc=net
objectclass: top
objectclass: organizationalUnit
ou: Users
# Conteneur de machines
dn: ou=Computers,dc=company,dc=net
objectclass: top
objectclass: organizationalUnit
ou: Computers
# Administrateur
dn: cn=admin,ou=Users,dc=company,dc=net
cn: admin
objectclass: top
objectclass: organizationalRole
objectclass: simpleSecurityObject
userPassword: {SSHA}WW2PMcKsh0ZVrFFSuwAtAXIUISAq1VIU
and my slapd.conf is:
#######################################################################
# ldbm and/or bdb database definitions
#######################################################################
database bdb
suffix « dc=company,dc=net »
checkpoint 1024 15
rootdn « cn=manager,dc=company,dc=net »
# Cleartext passwords, especially for the rootdn, should
# be avoided. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
# rootpw secret
rootpw {SSHA}WW2PMcKsh0ZVrFFSuwAtAXIUISAq1VIU
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory /var/lib/ldap
# Indices to maintain for this database
#index objectClass eq,pres
#index ou,cn,mail,
# Replicas of this database
#replogfile /var/lib/ldap/openldap-master-replog
#replica host=ldap-1.example.com:389 starttls=critical
# bindmethod=sasl saslmech=GSSAPI
# authcId=host/ldap-master.example.com@EXAMPLE.COM
# enable monitoring
database monitor
# allow onlu rootdn to read the monitor
access to *
by dn.exact= »cn=manager,dc=company,dc=net » read
by * none
Bonjour,
J’ai un gros problème sur Ldap, en effet lorsque je rentre une entrée sur le ldap maitre, celle ci va être insérée dans un fichier nommé sluprd.replog, puis grâce au daemon slurpd va être lu pour être injecté dans mon serveur de réplication ldap
Tout fonctionne, mais si je fais genre 15 entrées le fichier slurpd.replog va être saturé en écriture et a partir de la c’est tout le serveur qui lague.Le fichier atteint les 7 GO o_O .
Si je coupe le ldap puis le relance voila le message d’erreur :
2
3
bdb_db_open: Recovery skipped in read-only mode. Run manual recovery if errors are encountered.
config file testing succeeded
J’ai fais un slap_db_recover mais l’erreur va réapparaitre au bout d’une quinzaine d’entrées.
Avez vous déjà eu le problème???
Faut t’il paramétrer le fichier DB_CONFIG ???
Merci :p
Aye, je ne vais pas du tout pouvoir t’aider puisque j’ai toujours utilisé syncrepl et je ne connais pas du tout slurpd.. que disent les logs ?
merci de ta réponse :)
Pour les logs rien de spécial, la réplication se fait c’est tout :(
Je connais pas syncrepl ça marche comment???
Je vais tester ça demain ^^
Ca remplace slurpd apparemment un espoir peut etre :)
ça marche bien !
Plus sérieusement, tu fait quelques modifs dans les /etc/ldap/slapd.conf, tu charge le modules qui va bien… et ça roule !
Tu as pas mal de tutos qui t’expliquerons bien mieux que moi en quelques lignes.
http://www.google.fr/search?q=syncrepl
;)
hello toujours la???
je veux charger ce module
« moduleload syncprov.la »
Mais il n’existe pas sur ma distrib :(
Tu aurais le slapd.conf qui va bien :)
Ou juste ce que tu as rajouter pour la réplciation sur le maitre et serveur.
Si c’est possible :)
Merci
essaye simplement: « moduleload syncprov », ça devrait rouler tout seul !
ok ça marche nikel merci :)
Par contre il faut mettre de moduleload sur centos, tout est intégré avec slapd
merci pour la précision ;)
Au fait, comprend tu précisément le fonctionnement de syncrepl?
j’ai trouvé ce site, pour le mode 7.2.1.2.2 Replication refreshAndPersist (provider Push)
http://www.zytrax.com/books/ldap/ch7/
Mais l’histoire du cookie je ne comprends pas trop :(
Le serveur envoie un cookie avec un timestamp indiquant le dernier changement effectué, un truc du genre
overlay syncprov
# Le contextCSN (cookie) est écrit toutes les 100 opérations d’écriture ou toutes
# les 10 minutes.
syncprov-checkpoint 100 10
# Les logs de session gardent en mémoire presque toutes les opérations
# d’écriture sur la base, cela permet d’interroger les logs plutôt que de
# faire des requêtes sur la base. Jusqu’à 100 opérations sont
# enregistrées dans cette exemple.
syncprov-sessionlog 100
# Le contextCSN (cookie) est écrit toutes les 100 opérations d’écriture ou toutes les 10 minutes.
Donc comment se fait la synchro si c’est tous les 10 minutes, ca se fait en temps réel, cette option ne sert a rien?
Enfin si tu peux m’éclairer sur le fonctionnement :)
Merci
En fait les cookies de réplication servent a vérifier si les serveurs sont bien synchronisés en comparant directement les timestamps (contenu dans ces cookies).
–
Dans le mode refreshOnly, la synchronisation programmé selon un intervalle de temps – spécifié par le paramètre « interval ». Par défaut: 1 jour alors que dans le mode refreshAndPersist, la synchronisation est persistante… presque temps-réel.
ok merci de ta réponse
donc syncprov-checkpoint 100 10 ==> sur le maitre est complètement inutile?
au contraire, il est indispensable. Tiens, je te conseille de lire cet article qui est vraiment très bien foutu: http://www.zytrax.com/books/ldap/ch7/
J’ai le même problème (bdb_db_open: unclean shutdown detected) mais sur une machine virtuelle KVM (CentOS 5) exécutée dans une Fedora 12.
Avez-vous une idée de la manière d’effectuer un db_recover dans ces conditions ?
Le message exact est:
Vérification des fichiers de configuration pour slapd :
bdb_db_open: unclean shutdown detected; attempting recovery.
bdb_db_open: Warning – No DB_CONFIG file found in directory /var/lib/ldap: (2)
Expect poor perfomance for suffix dc=dclic, dc=fr.
bdb_db_open: Recovery skipped in read-only mode. Run manual recovery if errors are encountered.
config file testing succeeded.
Et le système ne répond plus.
la commande sur debian est db4.2_recover -h /var/lib/ldap/