From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0 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. In db-compat.c err = db->open (db, file, NULL, type, flags, mode); becomes 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): nss_db-2.2-29 How reproducible: Always 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. Additional info: nss_updatedb: http://www.padl.com/OSS/nss_updatedb.html uname -a 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. http://opus.snowmoon.com/~eric/nss_db-2.2-29.1.src.rpm http://opus.snowmoon.com/~eric/nss_db-2.2-29.1.i386.rpm ( 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.