[Date Prev][Date Next] [Chronological] [Thread] [Top]

BDB and cache settings - anything wrong? userPassword field keeps getting corrupted.

 I have one LDAP master server, a test server, which no one but me has access to (at least I think). Something really strange is happening, userPassword fields (they are in MD5 format) keep getting changed every 1 or 2 days. Sometimes they change after a mass add operation, or mass delete operation. It could be someone messing with me, but that would be unusual, since they also happen after I do mass operations on the server. I rechecked my "mass operation" scripts, and they do not seem to be breaking other entries while they operate on a given entry (add/delete entry and bind with that DN).
 I think maybe my BDB and cache settings may be causing it, it's just a thought, I really don't know what's going on:

 I have about 15000 entries on my server, they will grown around 1000 each 6 months.
 My slapd.conf ---
include         /etc/openldap/schema/core.schema
include         /etc/openldap/schema/cosine.schema
include         /etc/openldap/schema/inetorgperson.schema
include         /etc/openldap/schema/rfc2307bis.schema
include         /etc/openldap/schema/yast.schema
include         /etc/openldap/schema/postfix.schema
include         /etc/openldap/schema/misc.schema
include         /etc/openldap/acl-ldap.conf
schemacheck on
allow bind_v2
pidfile         /var/run/slapd/slapd.pid
argsfile        /var/run/slapd/slapd.args
modulepath      /usr/lib/openldap/modules
database        bdb
suffix          "dc=organization,dc=com,dc=tld"
cachesize       16500
rootdn          "cn=donotusethisdn,dc=organization,dc=com,dc=tld"
rootpw          {MD5}blablabla
checkpoint      1024    5
loglevel any
lastmod on
directory       /var/lib/ldap
index   objectClass                                     eq,pres # 2008-07-25
index   ou,cn,mail,sn,givenname                         eq,pres,sub # 2008-06-31
index   uid,memberUid,mailacceptinggeneralid,maildrop   pres,eq
index   mailroutingaddress                              pres,eq
TLSCertificateFile /etc/openldap/cert.crt
TLSCertificateKeyFile /etc/openldap/key.key
TLSCACertificateFile /etc/openldap/cacert.crt

replica uri=ldap://ldapslave.organization.com.tld:389
    bindmethod=simple credentials=blebleble starttls=critical

replogfile /var/lib/ldap/replog
 --- slapd.conf

 --- /var/lib/ldap/DB_CONFIG
set_cachesize 0 64781516  1
set_lg_regionmax 262144
set_lg_bsize 2097152
--- /var/lib/ldap/DB_CONFIG

server: # ls -lh /var/lib/ldap/*.bdb
-rw------- 1 ldap ldap 6.2M Aug 28 08:58 /var/lib/ldap/cn.bdb
-rw------- 1 ldap ldap 3.3M Aug 28 08:58 /var/lib/ldap/dn2id.bdb
-rw------- 1 ldap ldap 4.8M Aug 28 08:58 /var/lib/ldap/givenName.bdb
-rw------- 1 ldap ldap  20M Aug 28 08:58 /var/lib/ldap/id2entry.bdb
-rw------- 1 ldap ldap  11M Aug 28 08:58 /var/lib/ldap/mail.bdb
-rw------- 1 ldap ldap 816K Aug 28 08:58 /var/lib/ldap/mailRoutingAddress.bdb
-rw------- 1 ldap ldap 8.0K Aug 22 15:55 /var/lib/ldap/memberUid.bdb
-rw------- 1 ldap ldap 2.0M Aug 28 08:58 /var/lib/ldap/objectClass.bdb
-rw------- 1 ldap ldap 8.0K Aug 22 15:55 /var/lib/ldap/ou.bdb
-rw------- 1 ldap ldap 8.7M Aug 28 08:58 /var/lib/ldap/sn.bdb
-rw------- 1 ldap ldap 804K Aug 28 08:58 /var/lib/ldap/uid.bdb


 These cache settings make sense?
 The "corruptions", if I can call them that, are also happening on the slave, master and slave are exactly equal (slapcat's output is exact the same), so I rule out that the replication is causing this. 
 Before "checkpoint      1024    5" on slapd.conf was "checkpoint      512    15".
 I'm turning replication off, and I'll see what happens.

 I really don't understand what's going on, an attacker messing with me would be really strange, since he does not have access to anything with these passes, and he could do a lot of other more obvious things to mess with my work, I don't know, deleting something....but at the same time, it's strange to get data corrupted and _just_ this particular field. Other fields on the entries are not altered.


Powered by Outblaze