A ce propos, c'est peut-etre l'occasion d'essayer le directory server de
redhat plutot qu'openldap :-)
http://directory.fedora.redhat.com/wiki/Main_Page
Xavier
Vincent Jamart wrote:
Hello
A nouveau, la DB est corrompue ce matin mais cette fois-ci, le FS n'est
pas en cause puisque 95%. Le daemon est stoppé et lordsque je le
redémarre, localmessages n'affiche pas d'erreurs:
Jun 10 09:05:19 hera slapd[1371]: @(#) $OpenLDAP: slapd 2.2.15 (Jan 26
2005 16:34:33) $
[EMAIL PROTECTED]:/usr/src/packages/BUILD/openldap-2.2.15/servers/slapd
Jun 10 09:05:19 hera slapd[1371]: bdb_initialize: Sleepycat Software:
Berkeley DB 4.2.52: (October 1, 2004) Jun 10 09:05:20 hera slapd[1371]:
bdb_db_init: Initializing bdb database
Jun 10 09:05:20 hera slapd[1376]: slapd starting Jun 10 09:05:20 hera
slapd[1376]: conn=0 fd=12 ACCEPT from IP=127.0.0.1:51261 (IP=0.0.0.0:389)
Jun 10 09:05:20 hera slapd[1376]: conn=0 op=0 BIND dn="" method=128
Jun 10 09:05:20 hera slapd[1376]: conn=0 op=0 RESULT tag=97 err=0 text=
Jun 10 09:05:20 hera slapd[1376]: connection_input: conn=0 deferring
operation: binding Jun 10 09:05:20 hera slapd[1376]: conn=0 op=1 SRCH
base="" scope=0 deref=0 filter="(objectClass=*)"
Par compte, si je fais un ldapsearch -x, il s'arrête tout de suite:
hera:/var/log # ldapsearch -x
# extended LDIF
#
# LDAPv3
# base <> with scope sub
# filter: (objectclass=*)
# requesting: ALL
#
# fft.be
dn: dc=fft,dc=be
o: fft
dc: fft
objectClass: top
objectClass: dcObject
objectClass: organization
# Manager, fft.be
dn: cn=Manager,dc=fft,dc=be
cn: Manager
sn: Manager
objectClass: top
objectClass: person
# People, fft.be
dn: ou=People,dc=fft,dc=be
ou: People
objectClass: top
objectClass: organizationalUnit
Je dois faire un ^C pour reprendre la main et db_recover n'y change rien.
Ca arrive trop souvent, sans logique et je n'ai plus confiance dans ce
package bdb +openldap (en tout cas le RPM de Suse). Activer un PDC windows
me prendrait moins de temps que débugger ce brol...
On Fri, 3 Jun 2005, Vincent Jamart wrote:
Hello
le slapcat est fait avec la DB down, donc a froid...c'est ca le pire
db_recover, je vais tester plutot qu'un restore brutal
On Thu, 2 Jun 2005, Xavier Renard wrote:
Hello,
En fait,faire un slapcat à chaud risque de corrompre tes fichiers.
cfr man slapcat
<quote>
Limitations
Your slapd(8) should not be running (at least, not in read-write
mode) when you do this to ensure consistency of the database.
</quote>
Note qu'il me semble qu' avec des versions plus récentes, on puisse le
faire (mais je ne sais plus quel numéro de version :-()
maintenant, si tu n'as pas besoin des attributs opérationnels, un
ldapsearch ferait l'affaire
Pour rétablir la db en cas de corruption, tu as aussi l'utilitaire
db_recover
Xavier
Vincent Jamart wrote:
Hello
Depuis presque un an, le PDC de la societe tourne avec Samba et LDAP. e
remarque régulièrement que lorsqu'un backup s'est terminé en erreur
(le plus souvent media full), la DB LDAP est corrompue. Le système est
en SuSE 9.2, openldap2-2.2.15-5.2, mode bdb (le seul compilé dans le RPM
De SuSE, c'est déja pas sérieux) et db-4.2.52-90/db41-4.1.25-75. Tous
les soirs, je fais un backup offline de la DB ldap avec un slapcat -l. Le
matin, régulièrement, les users SMB et les services dépendant du LDAP ne peuvent
s'authentifier et pour cause, le service n'a pas redémarré après le backup
comme prévu et lorsqu'à ce moment je fais un restart du daemon et un
ldapsearch -x, l'output s'arrête après:
# extended LDIF
#
# LDAPv3
# base <> with scope sub
# filter: (objectclass=*)
# requesting: ALL
#
# fft.be
dn: dc=fft,dc=be
o: fft
dc: fft
objectClass: top
objectClass: dcObject
objectClass: organization
# Manager, fft.be
dn: cn=Manager,dc=fft,dc=be
cn: Manager
sn: Manager
objectClass: top
objectClass: person
# People, fft.be
dn: ou=People,dc=fft,dc=be
ou: People
objectClass: top
objectClass: organizationalUnit
et je dois faire un stop du daemon, crasher les fichiers bdb corrompus et
restaurer le backup avec slapadd -l et ensuite redémarrer le dameon (+smb)
et là tout remarche. J'ai l'impression que l'implémentation de LDAP avec
BDB est super foireuse et que SuSE n'ait pas compilé avec un support GDBM
(ou autre plus robuste) c'est du n'importe quoi.
_______________________________________________________
Linux Mailing List - http://www.unixtech.be
Subscribe/Unsubscribe: http://www.unixtech.be/mailman/listinfo/linux
Archives: http://www.mail-archive.com/linux@lists.unixtech.be
IRC: chat.unixtech.be:6667 - #unixtech
NNTP: news.gname.org - gmane.org.user-groups.linux.unixtech
_______________________________________________________
Linux Mailing List - http://www.unixtech.be
Subscribe/Unsubscribe: http://www.unixtech.be/mailman/listinfo/linux
Archives: http://www.mail-archive.com/linux@lists.unixtech.be
IRC: chat.unixtech.be:6667 - #unixtech
NNTP: news.gname.org - gmane.org.user-groups.linux.unixtech
_______________________________________________________
Linux Mailing List - http://www.unixtech.be
Subscribe/Unsubscribe: http://www.unixtech.be/mailman/listinfo/linux
Archives: http://www.mail-archive.com/linux@lists.unixtech.be
IRC: chat.unixtech.be:6667 - #unixtech
NNTP: news.gname.org - gmane.org.user-groups.linux.unixtech
_______________________________________________________
Linux Mailing List - http://www.unixtech.be
Subscribe/Unsubscribe: http://www.unixtech.be/mailman/listinfo/linux
Archives: http://www.mail-archive.com/linux@lists.unixtech.be
IRC: chat.unixtech.be:6667 - #unixtech
NNTP: news.gname.org - gmane.org.user-groups.linux.unixtech
