syncrepl löscht existierende Einträge auf consumer
Hallo,
ich hatte heute zum zweiten mal seit einem Monat das "Erlebis", dass syncrep
fast 90% aller Einträge des ldap auf dem Consumer gelöscht hat. peinlich, da
es unser Mailserver ist, gibt es die Nutzer nicht wenn mail für sie ankommt.
Wir nutzen gosa für die administration des ldap. Meine Kollegin hat in den
letzten Tagen einige Nutzer aus dem LDAP gelöscht. An allen Tagen gab es
keine Probleme, die synchronisation war korrekt. Heute allerdings passierte
es. In den logs des Consumers fand ich folgene Einträge:
Apr 21 08:48:45 dcs slapd[7236]: do_syncrep2: rid=101 LDAP_RES_INTERMEDIATE -
SYNC_ID_SET
Apr 21 08:48:45 dcs slapd[7236]: do_syncrep2:
cookie=csn=20090421064823Z#000003#00#000000,rid=101
Apr 21 08:48:45 dcs slapd[7236]: slap_queue_csn: queing 0xae7069c0
20090421064823Z#000003#00#000000
Apr 21 08:48:45 dcs slapd[7236]: slap_graduate_commit_csn: removing 0xae72dc78
20090421064823Z#000003#00#000000
Apr 21 08:48:45 dcs slapd[7236]: syncrepl_del_nonpresent: rid=101 be_delete
uid=nutzera,ou=people,ou=arbgrp,ou=abt,ou=my,o=domain,c=de (0)
:
:
slapd[7236]: syncrepl_entry: rid=101 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Apr 21 08:48:45 dcs slapd[7236]: syncrepl_entry: rid=101 inserted UUID
33fdb48e-c28c-102d-9d8a-c5d1aca5fa09
Apr 21 08:48:45 dcs slapd[7236]: syncrepl_entry: rid=101 be_search (0)
Apr 21 08:48:45 dcs slapd[7236]: syncrepl_entry: rid=101
cn=b9d1d7db1b3bc592e9b7b57acc40041e,ou=gosa,ou=configs,ou=systems,ou=tz,o=fal,c=de
Apr 21 08:48:45 dcs slapd[7236]: syncrepl_entry: rid=101 be_add (0)
Apr 21 08:48:45 dcs slapd[7236]: do_syncrep2: rid=101 LDAP_RES_SEARCH_RESULT
Apr 21 08:48:45 dcs slapd[7236]: do_syncrep2:
cookie=csn=20090421064845Z#000000#00#000000,rid=101
Apr 21 08:48:45 dcs slapd[7236]: slap_queue_csn: queing 0xae715640
20090421064845Z#000000#00#000000
Apr 21 08:48:45 dcs slapd[7236]: slap_graduate_commit_csn: removing 0xae702e40
20090421064845Z#000000#00#000000
Apr 21 08:58:45 dcs slapd[7236]: do_syncrep2: rid=101 LDAP_RES_INTERMEDIATE -
SYNC_ID_SET
Apr 21 08:58:45 dcs slapd[7236]: syncrepl_entry: rid=101
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Apr 21 08:58:45 dcs slapd[7236]: syncrepl_entry: rid=101 inserted UUID
8b82805e-0867-102b-8021-e9137c6ded0b
Apr 21 08:58:45 dcs slapd[7236]: syncrepl_entry: rid=101 be_search (0)
Apr 21 08:58:45 dcs slapd[7236]: syncrepl_entry: rid=101
cn=mygrp,ou=groups,ou=my,o=domain,c=de
Apr 21 08:58:45 dcs slapd[7236]: syncrepl_entry: rid=101 be_modify (0)
Apr 21 08:58:45 dcs slapd[7236]: syncrepl_entry: rid=101
Apr 21 08:58:45 dcs slapd[7236]: do_syncrep2: rid=101 LDAP_RES_SEARCH_RESULT
Apr 21 08:58:45 dcs slapd[7236]: do_syncrep2:
cookie=csn=20090421065817Z#000003#00#000000,rid=101
Apr 21 08:58:45 dcs slapd[7236]: nonpresent_callback: rid=101 not UUID
8a5d17de-0867-102b-9fad-e9137c6ded0b, dn c=de
Apr 21 08:58:45 dcs slapd[7236]: nonpresent_callback: rid=101 not UUID
8a5e5f86-0867-102b-9fb0-e9137c6ded0b, dn o=domain,c=de
Apr 21 08:58:45 dcs slapd[7236]: nonpresent_callback: rid=101 not UUID
8a5ed024-0867-102b-9fb2-e9137c6ded0b, dn ou=my,o=domain,c=de
: (es folgen hier ca. 90% aller ldapeinträge)
pr 21 08:58:45 dcs slapd[7236]: slap_queue_csn: queing 0xae72c058
20090421065817Z#000003#00#000000
Apr 21 08:58:45 dcs slapd[7236]: slap_graduate_commit_csn: removing 0xae72cf50
20090421065817Z#000003#00#000000
Apr 21 08:58:45 dcs slapd[7236]: syncrepl_del_nonpresent: rid=101 be_delete
cn=b9d1d7db1b3bc592e9b7b57acc40041e,ou=gosa,ou=configs,ou=systems,ou=my,o=domain,c=de
(0)
: ((die schon erwähnten 90% bis hinzu..)
Apr 21 08:58:46 dcs slapd[7236]: syncrepl_del_nonpresent: rid=101 be_delete
ou=my,o=domain,c=de (66)
Apr 21 08:58:46 dcs slapd[7236]: syncrepl_del_nonpresent: rid=101 be_delete
o=domain,c=de (66)
Apr 21 08:58:46 dcs slapd[7236]: syncrepl_del_nonpresent: rid=101 be_delete
c=de (66)
Apr 21 08:58:46 dcs slapd[7236]: slap_queue_csn: queing 0xae72c058
20090421065817Z#000003#00#000000
Apr 21 08:58:46 dcs slapd[7236]: slap_graduate_commit_csn: removing 0xb4d03ff0
20090421065817Z#000003#00#000000
Wenn ich ein ldapsearch auf einen Nutzer, von dem ich weiss, dass er
garantiert nicht von meiner Kollegin gelöscht wurde mache, ist er auf diesem
Server nicht vorhanden, aber auf dem provder und den noch ueber slurpd
synchronisierten.
Ich weiss, das die log-Einträge ansich keine Fehler darstellen, aber das dies
mit wirklich besteheden Einträgen, auf denen definitive keine Änderungen zu
diesem Zeitpunkt erfolgten, ist ein gravierendes Problem. Vorallem, da es
mehrere Wochen lang ohne Probleme funktioniert und dann auf einmal dieses
Verhalten.
Ich habe die Datenbank gelöscht und slap neu gestrtet, er hat alle Einträge
wieder sauber eingelesen.
Zur Konfiguration:
Provider: slapd 2.3.30-5+etch2
Config: ....
moduleload back_bdb
moduleload syncprov
:
:
# Fuer syncreply
index entryCSN,entryUUID eq
:
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
Der Provider arbeitet auch als Master für den slurpd, der noch eine älteren
slap versorgt. (Ohne Probleme)
Consumer: slapd 2.4.11-1 (lenny)
Config: .....
index entryCSN,entryUUID eq
:
:
syncrepl rid=101
provider=ldaps://ldap.my.local:636
type=refreshOnly
searchbase="c=de"
retry="60 10 300 3 600 +"
scope=sub
schemachecking=off
bindmethod=simple
binddn="cn=replicator,ou=my,o=domai,c=de"
credentials=ReSumpti0n
Da wir auch kerberos im Einsatz haben, hier die Config:
[kdcdefaults]
kdc_ports = 750,88
[realms]
MY.LOCAL = {
database_name = /var/lib/krb5kdc/principal
admin_keytab = FILE:/etc/krb5kdc/kadm5.keytab
acl_file = /etc/krb5kdc/kadm5.acl
key_stash_file = /etc/krb5kdc/stash
kdc_ports = 750,88
max_life = 10h 0m 0s
max_renewable_life = 7d 0h 0m 0s
master_key_type = des3-hmac-sha1
supported_enctypes = des3-hmac-sha1:normal des-cbc-crc:normal
des:normal des:v4 des:norealm des:onlyrealm des:afs3
default_principal_flags = +preauth
}
Ich kann gerne die gesamten Konfigurationen noch schicken, aber die Mail ist
so schon überladen.
Ich hoffe es kannmir jemand einen Tip geben, woher dieses Verhalten komt und
wie ich es in der nächsten Zeit verhindern kann.
Monika
--
________________________________________________________________________________
Monika Strack
Institut fuer Nutztiergenetik
Friedrich-Loeffler-Institut
31535 Neustadt e-mail: monika.strack@fli.bund.de
Germany Tel: +49 5034 /871 154
Fax: +49 5034 /871 239
_______________________________________________________________________________
Reply to: