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/[email protected]
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/[email protected]
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/[email protected]
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/[email protected]
IRC: chat.unixtech.be:6667 - #unixtech
NNTP: news.gname.org - gmane.org.user-groups.linux.unixtech
