[Date Prev][Date Next]
Re: slapd still allows bind but returns no data
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
Author, "Best Practices for Managing Linux and UNIX Servers"
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
> My DB_CONFIG is basically the example that comes with OpenLDAP:
> # $OpenLDAP: pkg/ldap/servers/slapd/DB_CONFIG,v 184.108.40.206 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
>> 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.)