From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Description of problem:
nss_db is built with static db-4.0.14 rather than the db4-devel
library supplied with a fresh install. This leads to issues when
using tools such as nss_updatedb to generate cached .db files. The
issue is realted to the fact that 4.0.14 uses db verion 8 btrees and
4.2.52-6 ( db4-devel ) is verion 9 btrees. nss_db fails silently when
attempting to open these newer files.
You should upgrade nss_db to use the current db4 libraries.
NOTE: In order to build nss_db against 4.2.x db libraries I needed to
apply a single fix to the source.
err = db->open (db, file, NULL, type, flags, mode);
err = db->open (db, NULL, file, NULL, type, flags, mode);
And that was all. I recompiled the source with that one change and
shared library support and then copied the new libnss_db to .lib .
The .db files created with nss_updatedb then worked as expected.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install nss_updatedb in LDAP environment
2. Run nss_updatedb ldap
3. attempt to use /var/db/*.db files in /etc/nsswitch.conf
Actual Results: nsswitch and libnss_db ignore the .db files becaue it
does not uderstand version 9 btree files.
Expected Results: cached LDAP passwd and group information should be
used seemessly through the nss_db module.
Linux ua-40433.msc.albany.edu 2.6.9-1.667smp #1 SMP Tue Nov 2 14:59:52
EST 2004 i686 i686 i386 GNU/Linux
CPU: Intel(R) Pentium(R) 4 CPU 3.20GHz ( HT enabled )
I have created a possible solution. I have created a .i386 and .src
rpm's that work as expected on my system by linking dynamically rather
than statically. This includes the .patch file to compile against
4.2.x db libraries.
( although I have been a linux user since pre 1.0, this is my first
.rpm, so please take it easy on me :-) )
Use the 'makedb' tool, which mimics the functionality of the NIS
server's makedbm tool while guaranteeing that the files which it
generates are usable by nss_db. makedb also ensures that the right
SELinux context is applied to the database files which it generates,
which you may need to watch out for if you're attempting to use
db_load to accomplish the same job.
FWIW, the reason we link with a static copy of libdb (which we build
with the unique-symbol-name option) is to avoid potential symbol
conflicts in applications which link to a different version of libdb.
The functionality provided by nss_updatedb can, for the most part, be
provided by altering the nss_db makefile to use 'getent' instead of
'cat' to read the contents of your databases.
Closing because 2.2-30 switches to DB 4.3 (mainly to move off of 4.0
bits, the maintenance status of which I'm unclear on), which removes
the problem the bug reporter is seeing.