OVH Cloud OVH Cloud

base ldap corrompue et db4.2_recover

1 réponse
Avatar
pingouin osmolateur
Bonjour
Je viens de m'apercevoir que mon serveur ldap ne
démarre plus. Je viens de voir les logs et y'a un pb :


Jul 6 19:47:47 hoth slapd[537]: @(#) $OpenLDAP: slapd
2.2.23 (May 30 2005 08:52:42) $
^I@pulsar:/home/torsten/packages/openldap/openldap2.2-2.2.23/debian/build/servers/slapd
Jul 6 19:47:48 hoth slapd[537]: bdb_db_init:
Initializing BDB database
Jul 6 19:47:48 hoth slapd[538]: bdb_db_open:
dbenv_open failed: Permission denied (13)
Jul 6 19:47:48 hoth slapd[538]: backend_startup:
bi_db_open failed! (13)
Jul 6 19:47:48 hoth slapd[538]: bdb(o=monldap,c=FR):
DB_ENV->lock_id_free interface requires an environment
configured for the locking subsystem
Jul 6 19:47:48 hoth slapd[538]: bdb(o=monldap,c=FR):
txn_checkpoint interface requires an environment
configured for the transaction subsystem
Jul 6 19:47:48 hoth slapd[538]: bdb_db_destroy:
txn_checkpoint failed: Invalid argument (22)
Jul 6 19:47:48 hoth slapd[538]: slapd stopped.
Jul 6 19:47:48 hoth slapd[538]: connections_destroy:
nothing to destroy.

Pourtant les droits dans mon répertoire de base de
ldap ont l'air bien :

hoth:/opt/ldap# ls -al
total 4348
drwxr-xr-x 2 ldap ldap 4096 Jul 6 19:50 .
drwxr-xr-x 7 root root 4096 May 11 10:03 ..
-rw------- 1 ldap ldap 8192 Jul 6 19:50 dn2id.bdb
-rw------- 1 ldap ldap 229376 Jul 6 19:50
id2entry.bdb
-rw------- 1 ldap ldap 4188219 Jul 6 19:50
log.0000000001
-rw------- 1 ldap ldap 8192 Jul 6 19:50
objectClass.bdb

J'ai lancé la commande suivante car j'ai vu ça dans le
résultat d'une commande /etc/init.d/slapd que je
n'arrive pas à reproduire

hoth:/opt/ldap# db4.2_recover -v -c
db_recover: Finding last valid log LSN: file: 1 offset
4188131
db_recover: Recovery starting from [1][28]
db_recover: Recovery complete at Wed Jul 6 19:50:31
2005
db_recover: Maximum transaction ID 800002a9 Recovery
checkpoint [1][4188131]

Voila le résultat de la commande de démarrage après
passage de la commande précédente:

/etc/init.d/slapd start
Stopping OpenLDAP: slapd.
Starting OpenLDAP: running BDB recovery, slapd.

Voici mon fichier de conf qui est lisible par le user
ldap :

cat /etc/ldap/slapd.conf
# This is the main slapd configuration file. See
slapd.conf(5) for more
# info on the configuration options.

#######################################################################
# Global Directives:

# Features to permit
allow bind_v2

# Schema and objectClass definitions
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/inetorgperson.schema

# Schema check allows for forcing entries to
# match schemas for their objectClasses's
schemacheck on

# Where the pid file is put. The init.d script
# will not stop the server if you change this.
pidfile /var/run/slapd/slapd.pid

# List of arguments that were passed to the server
argsfile /var/run/slapd/slapd.args

# Read slapd.conf(5) for possible values
loglevel 2048

# Where the dynamically loaded modules are stored
modulepath /usr/lib/ldap
#moduleload back_@BACKEND@
moduleload back_bdb

#######################################################################
# Specific Backend Directives for @BACKEND@:
# Backend specific directives apply to this backend
until another
# 'backend' directive occurs
#backend @BACKEND@
backend bdb
#@CHECKPOINT@

#######################################################################
# Specific Backend Directives for 'other':
# Backend specific directives apply to this backend
until another
# 'backend' directive occurs
#backend <other>

#######################################################################
# Specific Directives for database #1, of type
@BACKEND@:
# Database specific directives apply to this databasse
until another
# 'database' directive occurs
database bdb

# The base of your directory in database #1
suffix "o=monldap,c=FR"
rootdn "cn=Manager,o=monldap,c=FR"
rootpw {MD5}6tSa+qNSocXNINhP7CbLZA==

# Where the database file are physically stored
directory "/opt/ldap"

# Indexing options for database #1
index objectClass eq

# Save the time that the entry gets modified, for
database #1
lastmod on

# Where to store the replica logs for database #1
# replogfile /var/lib/ldap/replog

# The userPassword by default can be changed
# by the entry owning it if they are authenticated.
# Others should not be able to see it, except the
# admin entry below
# These access lines apply to database #1 only
access to attrs=userPassword
by dn="cn=Manager,o=monldap,c=FR" write
by anonymous auth
by self write
by * none

# Ensure read access to the base for things like
# supportedSASLMechanisms. Without this you may
# have problems with SASL not knowing what
# mechanisms are available and the like.
# Note that this is covered by the 'access to *'
# ACL below too but if you change that as people
# are wont to do you'll still need this if you
# want SASL (and possible other things) to work
# happily.
access to dn.base="" by * read

# The admin dn has full write access, everyone else
# can read everything.
access to *
by dn="cn=Manager,o=monldap,c=FR" write
by * read


#TLSCertificateFile /etc/ssl/certs/ldap.pem
#TLSCertificateKeyFile /etc/ssl/private/ldap.sk.pem
#TLSCACertificateFile /etc/ssl/causerext.pem

Voila je n'ai pas fait de sauvegarde (pas taper svp
:-))

Donc si quelqu'un a une idée je suis preneur.

ps : je ne suis pas devant la machine tout le temps
donc je ne serai pas très réactif.

merci d'avance
AC






___________________________________________________________________________
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger
Téléchargez cette version sur http://fr.messenger.yahoo.com


--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

1 réponse

Avatar
pingouin osmolateur
--- pingouin osmolateur
a écrit :

Bonjour
[..]



hoth:/opt/ldap# db4.2_recover -v -c
db_recover: Finding last valid log LSN: file: 1
offset
4188131
db_recover: Recovery starting from [1][28]
db_recover: Recovery complete at Wed Jul 6 19:50:31
2005
db_recover: Maximum transaction ID 800002a9 Recovery
checkpoint [1][4188131]




Je viens de découvrir que certains fichiers ont été
crées après le passage de la commande db4.2_recover

hoth:/opt/ldap# ls -al
total 4660
drwxr-xr-x 2 ldap ldap 4096 Jul 6 19:47 .
drwxr-xr-x 7 root root 4096 May 11 10:03 ..
-rw-r----- 1 root root 8192 Jul 6 19:47 __db.001
-rw-r----- 1 root root 270336 Jul 6 19:47 __db.002
-rw-r----- 1 root root 98304 Jul 6 19:47 __db.003
-rw-r----- 1 root root 368640 Jul 6 19:47 __db.004
-rw-r----- 1 root root 16384 Jul 6 19:47 __db.005
-rw------- 1 ldap ldap 4188131 Jul 6 19:47
ancien_log
-rw------- 1 ldap ldap 8192 Jul 6 19:47 dn2id.bdb
-rw------- 1 ldap ldap 229376 Jul 6 19:47
id2entry.bdb
-rw-r----- 1 root root 28 Jul 6 19:47
log.0000000001
-rw------- 1 ldap ldap 8192 Jul 6 19:47
objectClass.bdb

Est-ce que quelqu'un sait ce que je dois en faire ?

Je viens de trouver un post sur le problème :
http://mirror.hamakor.org.il/archives/linux-il/05-2005/15103.html

Est-ce que quelqu'un a deja fait la manip avec la
commande db4.2_checkpoint ?

Si oui quels paramètres je dois passer ?

Je continue à chercher






___________________________________________________________________________
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger
Téléchargez cette version sur http://fr.messenger.yahoo.com


--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact