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

Re: slapd still allows bind but returns no data

Josh M. Hurd skrev, on 13-10-2007 19:41:

Excellent!  Thank you!

Clearly I am using an old version:
Sleepycat Software: Berkeley DB 4.2.52: (December 11, 2004)
I will upgrade that and see.

You do not mention your OS, distribution, details about your hardware configuration or anything else relevant to your OL environment save DB_CONFIG details.

I can't see much wrong with the latter for a small scale DB; if you are running a large scale DB then you probably haven't allocated enough cache memory. I don't know what the defaults are for max_locks, max_lockers or max_objects - Quanah or others could possibly help with those.

I've been running, and am presently running, OL 2.2.33-2.3.37 SleepyCat (now Oracle) BDB 4.2.52 in production on 4 servers at my 1500+ user, 50MB DB location 24x7x52 for years with no problems. First on Red Hat RHEL4, since Aug last on RHEL5. On grade A IBM hardware, both x86_32 and 64. Thousands of others are running 4.2.52 without problem on other hardware and other OSs.

The proviso is, that the libraries *have* to be patched with 4, possibly 5 depending on the patch versions, discrete patches.

Standard db4 on RHEL5 is 4.3.29. i.e. later than 4.2.52 with patches. But I've found out for myself by using standard Red Hat-supplied OL 2.3.27 that it doesn't work with OL 2.3.38. Therefore I use discrete db4 4.2.52 libraries for slapd and friends supplied by Buchan Milne.

If you do upgrade your db4 version, please make it 4.6+, enough has been written about that in this ML. Everything between patched 4.2.52 and 4.6 should be avoided. Moreover, if other things are making use of db4 4.2.52 on your unknown OS/distribution, then simply replacing it with an upgrade will most probably break everything else depending on 4.2.52.

In the dim and distant past (on RHEL3) I had source OL, BDB 4.2.52, Cyrus SASL 2.1 all separate in /usr/local and life was hell for various reasons. Try to avoid this kind of thing, keep installs as uniform as possible with a package managing system. Luckily, Buchan Milne supplies plug-in Red Hat rpms, which I use (actually I rebuild his srpms, since I have 2 architectures to build on).

Bottom line: I don't believe that swapping 4.2.52 for a db4 "upgrade" is going to help your problem: 4.2.52 works well for all than the most demanding uses. Could document this with Howard Chu's extensive doco, but I'll leave it up to you to search this out in the archives.



Tony Earnshaw
Email: tonni at hetnet dot nl