[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
SIZELIMIT -1
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
binddn=cn=slavereplicator,ou=adm,dc=organization,dc=com,dc=tld
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
set_flags DB_LOG_AUTOREMOVE
--- /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