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
