Hello J'ai +-7000 entrées. Je viens de changer le script, puisque c'est du BDB je vais faire un slapcat -f /etc/openldap/slapd.conf -b "dc=fft,dc=be" -l backup.ldif avec la DB ouverte.
On Fri, 10 Jun 2005, Xavier Renard wrote: > Hi, > > C'est bizarre quand meme. Tu as combien d'entrée? > Sinon, au niveau debug, essaye peut-etre un niveau plus élevé > avec la directive loglevel: > http://www.openldap.org/doc/admin22/slapdconfig.html#Configuration%20File%20Directives > (cfr section 5.2.1.5 pour les différents niveaux) > > ou avec l'option -d de slapd > > > 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: > > > > > > > > _______________________________________________________ > 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
