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

Re: slapd still allows bind but returns no data

Thanks, but this was a brand new DB created from an LDIF. Within hours this problem showed up.
The DB is literally <2 days old.

I can certainly do this again just to be sure?

Josh

On Oct 12, 2007, at 1:40 PM, Dustin Puryear wrote:

You can tell REAL FAST if it's the backend database by archiving the
database files and starting slapd and then restoring a backup via
slapcat or ldapadd. If that works then the database files were corrupted
in some way.

--
Puryear Information Technology, LLC
Baton Rouge, LA * 225-706-8414
http://www.puryear-it.com

Author, "Best Practices for Managing Linux and UNIX Servers"
  http://www.puryear-it.com/pubs/linux-unix-best-practices

Identity Management, LDAP, and Linux Integration


Josh M. Hurd wrote:
I haven't found the version of BDB yet. Anyone know an easy way to do
this?

My DB_CONFIG is basically the example that comes with OpenLDAP:

# $OpenLDAP: pkg/ldap/servers/slapd/DB_CONFIG,v 1.1.2.3 2006/08/17
17:36:19 kurt Exp $
# Example DB_CONFIG file for use with slapd(8) BDB/HDB databases.
#
# See Sleepycat Berkeley DB documentation
#   <http://www.sleepycat.com/docs/ref/env/db_config.html>
# for detail description of DB_CONFIG syntax and semantics.
#
# Hints can also be found in the OpenLDAP Software FAQ
#       <http://www.openldap.org/faq/index.cgi?file=2>
# in particular:
#   <http://www.openldap.org/faq/index.cgi?file=1075>

# Note: most DB_CONFIG settings will take effect only upon rebuilding
# the DB environment.

# one 0.25 GB cache
set_cachesize 0 268435456 1

# Data Directory
#set_data_dir db

# Transaction Log settings
set_lg_regionmax 262144
set_lg_bsize 2097152
#set_lg_dir logs

# Note: special DB_CONFIG flags are no longer needed for "quick"
# slapadd(8) or slapindex(8) access (see their -q option).


This was the next thing I was going to look.


On Oct 11, 2007, at 2:40 PM, Aaron Richton wrote:

If you're binding as the rootdn successfully, it's probably only that
given bdb backend that's faulty. Can you track down the Sleepycat
library you're using (perhaps using ldd), and find out what version it
is?

At risk of my getting shot by Howard, are you caring for your
Sleepycat log files properly? DB_CONFIGs for autoremove, or are there
cron jobs for db_archive, etc.? What are your DB_CONFIGs, for that
matter? (They'd have to be pretty far off to cause this behavior, but
it's a quick look at least.)