[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Corrupt LDAP DB ...
Greetings ...
Thanks for all the suggestions ...
FRLinux wrote:
On 10/27/05, C.Lee Taylor <leet@leenx.co.za> wrote:
It used to hang our server every once in a while (every month like).
We noticed after a while that the drive was dodgy which could have
explained the issue.
We have one master (r/w), one local slave (r/o), one near slave (r/o)
and one remote slave (r/o), plus about 5 servers using these slaves and
master in fall over ...
The server all fail at different times ... Again, not like a
replication of a bad attr or something is causing this, because I will
find two servers down in the morning, but the other two working still
... So, I really don't understand. The two remote servers seem to fall
over less, but that does not mean anything to me.
When we added the SAMBA schemas, we migrated to 2.2.x on FreeBSD 5. We
are currently running 5.4-STABLE with OpenLDAP 2.2.29 (from the
FreeBSD ports). We have one master (r/w) and a slave (ro). The slave
handles all LDAP queries on auth and the master handles all the
queries with Samba auth. Since then, no more crash.
Do you think that maybe the use of the master on a server is a problem?
We used to do a : db4.2_recover
I'm worried that a recover might loose data, so I'm sticking with a
delete and slapadd from the last backup, which is done by the hour and
we are yet to lose and attr changes ...
It has been documented on some lists and you are encouraged to save
your /var/lib/ldap (or wherever you might find it) before attempting
this command. This is called disaster recovery and it means something.
This is why I'm thinking, rather start clean, than maybe inherit some
other craft ...
Also, i am not sure from your limited config file but do you do
checkpoints and indexes ? If not you should.
Okay, on suggestion from Buchan Milne, I have found and added some more
conf options ... Here is what my conf file looks like now ...
/etc/openldap/slapd.conf - the default conf less comments ...
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/leenx/samba.schema
include /etc/openldap/schema/misc.schema
allow bind_v2
pidfile /var/run/slapd.pid
argsfile /var/run/slapd.args
database bdb
suffix "dc=my-domain,dc=com"
rootdn "cn=Manager,dc=my-domain,dc=com"
rootpw secret
directory /var/lib/ldap
index objectClass eq,pres
index ou,cn,mail,surname,givenname eq,pres,sub
index uidNumber,gidNumber,loginShell eq,pres
index uid,memberUid eq,pres,sub
index nisMapName,nisMapEntry eq,pres,sub
include /etc/openldap/za.conf
replogfile /home/services/ldap/za/repl/master-slapd.replog
EOF
then my config start with za.conf
database bdb
suffix "dc=leenx,dc=co,dc=za"
rootdn "cn=Manager,dc=leenx,dc=co,dc=za"
rootpw thiscouldbemysecret
directory /home/services/ldap/za/db
cachesize 100
checkpoint 128 15
#dbnosync
lastmod on
schemacheck on
include /etc/openldap/readonly.conf
include /etc/openldap/logging.conf
include /etc/openldap/za-repl-master.conf
#include /etc/openldap/za-repl-slave.conf
include /etc/openldap/indices.conf
include /etc/openldap/rights.conf
EOF
Used to put the DB into for readonly for backup ...
/etc/openldap/readonly.conf
readonly off
EOF
Used to modify the logging with all the coments for each log level ...
/etc/openldap/logging.conf
loglevel -1
EOF
/etc/openldap/za-repl-master.conf
replica host=n.leenx.co.za tls=no
binddn="cn=Replicator,dc=leenx,dc=co,dc=za"
bindmethod=simple credentials=thiscouldbemysecret
replica host=a.leenx.co.za tls=no
binddn="cn=Replicator,dc=leenx,dc=co,dc=za"
bindmethod=simple credentials=thiscouldbemysecret
replica host=b.leenx.co.za tls=no
binddn="cn=Replicator,dc=leenx,dc=co,dc=za"
bindmethod=simple credentials=thiscouldbemysecret
replica host=p.leenx.co.za tls=no
binddn="cn=Replicator,dc=leenx,dc=co,dc=za"
bindmethod=simple credentials=thiscouldbemysecret
EOF
/etc/openldap/za-repl-slave.conf
updatedn "cn=Replicator,dc=leenx,dc=co,dc=za"
updateref ldap://master.leenx.co.za
EOF
/etc/openldap/indices.conf
index default eq,pres
index objectClass eq,pres
## required to support pdb_getsampwnam
index uid eq,pres,sub
## required to support pdb_getsambapwrid()
index displayName eq,pres,sub
index cn,sn,givenname,ou eq,pres,sub,approx
index mail eq,pres,sub,approx
index mailLocalAddress eq,pres,approx
index uidNumber,loginShell eq
index gidNumber eq
index memberUid eq
index uniqueMember pres
index sambaSID eq
index sambaSIDList eq,pres
index sambaPrimaryGroupSID eq
index sambaDomainName eq
index sambaPwdCanChange eq,pres
index entryCSN,entryUUID eq,pres
index nisMapName,nisMapEntry eq,pres,sub
EOF
/etc/openldap/rights.conf
access to dn.subtree="ou=old,dc=leenx,dc=co,dc=za" attrs=uid,uidNumber
by dn.base="cn=Replicator,dc=leenx,dc=co,dc=za" write
by dn.subtree="ou=ldap,dc=leenx,dc=co,dc=za" write
by * read
access to dn.subtree="ou=old,dc=leenx,dc=co,dc=za"
by dn.base="cn=Replicator,dc=leenx,dc=co,dc=za" write
by dn.subtree="ou=ldap,dc=leenx,dc=co,dc=za" write
by * none
access to
attrs=userPassword,sambaNTPassword,sambaLMPassword,sambaPasswordHistory
by self write
by anonymous auth
by dn.base="cn=Replicator,dc=leenx,dc=co,dc=za" write
by dn.subtree="ou=ldap,dc=leenx,dc=co,dc=za" write
by * none
access to *
by self write
by dn.base="cn=Replicator,dc=leenx,dc=co,dc=za" write
by dn.subtree="ou=ldap,dc=leenx,dc=co,dc=za" write
by * read
EOF
Hope this helps,
I'm sure it will. Thanks.
Mailed
Lee
P.S. I wonder if any logs might help. I have even gone as far as giving
each sub system there own dn for updates and so, in the hope of finding
what might be cause the corruption.