From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6 Description of problem: ldap complains upon startup - looks like it's due to a berkeley database issue of some sort (Program version 4.3 doesn't match environment version) Version-Release number of selected component (if applicable): openldap-servers-2.2.23-5 and db4-4.3.27-3 How reproducible: Always Steps to Reproduce: Background: this occurred after upgrading from FC3 to FC4 1. execute "slaptest" OR "service ldap start" 2. Watch slaptest complain...(see below) Actual Results: [root@localhost ~]# service ldap start Checking configuration files for slapd: slap_startup failed (test would succeed using the -u switch) [FAILED] [root@localhost ~]# slaptest slap_startup failed (test would succeed using the -u switch) [root@localhost ~]# slaptest -d 4 -v bdb_back_initialize: Sleepycat Software: Berkeley DB 4.3.27: (December 22, 2004) bdb_back_initialize: Sleepycat Software: Berkeley DB 4.3.27: (December 22, 2004) bdb_db_init: Initializing BDB database bdb_db_open: dc=fresno,dc=edu bdb(dc=fresno,dc=edu): Program version 4.3 doesn't match environment version bdb_db_open: dbenv_open failed: DB_VERSION_MISMATCH: Database environment version mismatch (-30974) backend_startup: bi_db_open failed! (-30974) slap_startup failed (test would succeed using the -u switch) [root@localhost ~]# Expected Results: Who am I to say? (openldap should be less picky about the bdb version maybe? fedora should bundle a bdb compatible w/ldap maybe? or maybe I'm missing something else in the 'dumb-dumb' category...) Additional info: Database looks like it's there... [root@localhost ~]# ls -al /var/lib/ldap total 548 drwx------ 3 ldap ldap 4096 Sep 13 09:21 . drwxr-xr-x 23 root root 4096 Sep 7 15:30 .. -rw------- 1 ldap ldap 16384 Jul 15 13:12 __db.001 -rw------- 1 ldap ldap 278528 Jul 15 13:12 __db.002 -rw------- 1 ldap ldap 98304 Jul 15 13:12 __db.003 -rw------- 1 ldap ldap 450560 Jul 15 13:12 __db.004 -rw------- 1 ldap ldap 16384 Jul 15 13:12 __db.005 -rw------- 1 ldap ldap 8192 Jul 15 13:13 dn2id.bdb drwxr-xr-x 2 ldap ldap 4096 Jul 15 15:46 fresno.edu -rw------- 1 ldap ldap 32768 Jul 15 13:13 id2entry.bdb -rw------- 1 ldap ldap 42225 Jul 15 13:13 log.0000000001 [root@localhost ~]# [root@localhost ~]# rpm -qa | grep db4 db4-utils-4.3.27-3 db4-4.3.27-3 db4-devel-4.3.27-3 [root@localhost ~]# [root@localhost ~]# rpm -qa | grep ldap openldap-2.2.23-5 python-ldap-2.0.6-4 openldap-clients-2.2.23-5 openldap-servers-2.2.23-5 nss_ldap-234-4 openldap-devel-2.2.23-5 (See bug 156787?) Is this related to http://ldapguru.com/modules/newbb/viewtopic.php?topic_id=2426&forum=6&post_id=7265#forumpost7265?
Were the database files created on the fc4 system? It's possible that the fc4 openldap is having trouble with database files created on an fc3 system. I'm not having any trouble on my fc4 system with creating a database, importing an ldif and serving data out of it. If the files were created on an fc3 system, you might try: 1: copy the database files (and the slapd.conf) to an fc3 system 2: use slapcat on the fc3 system to create an ldif of the database 3: move /var/lib/ldap/* to a safe place 4: start slapd 5: import the ldif you created in step 2
The database files were created on the FC3 system. I hadn't invested much thought in things and had just assumed the ldap database would transparently migrate to FC4. Your suggestion worked like a charm. Sorry for not thinking of trying that myself... Thanks for your time...
This report targets the FC3 or FC4 products, which have now been EOL'd. Could you please check that it still applies to a current Fedora release, and either update the target product or close it ? Thanks.
The same problem does not [seem to] occur in FC6. I think it's safe to say it's a non-issue at this point.