Bug 174829 - ldap is broken after update to 2.2.29-1.FC3
Summary: ldap is broken after update to 2.2.29-1.FC3
Alias: None
Product: Fedora
Classification: Fedora
Component: openldap
Version: 3
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Jay Fenlason
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2005-12-02 15:58 UTC by shrek-m
Modified: 2014-08-31 23:27 UTC (History)
3 users (show)

Clone Of:
Last Closed: 2006-04-18 20:32:43 UTC

Attachments (Terms of Use)

Description shrek-m 2005-12-02 15:58:28 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.7.12-1.3.1

Description of problem:
after the update to the last openldap-servers on 2 machines ldap is broken.
even with the provided ldap.conf slapd.conf it is not starting.
befor the update all was working ok.

# slaptest
slap_startup failed (test would succeed using the -u switch)

# slaptest -u
config file testing succeeded

# service ldap start
Konfigurationsdateien nach slapd untersuchen: slap_startup failed (test would succeed using the -u switch)
stale lock files may be present in /var/lib/ldap           [WARNUNG]

# ls /var/lib/ldap
__db.001  __db.005       givenName.bdb   mail.bdb         sn.bdb
__db.002  cn.bdb         id2entry.bdb    memberUid.bdb    uid.bdb
__db.003  dn2id.bdb      log.0000000001  objectClass.bdb  uidNumber.bdb
__db.004  gidNumber.bdb  loginShell.bdb  ou.bdb

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. start ldap, ok
2. update ldap
3. service ldap status

Actual Results:  ldap is not starting

Expected Results:  ldap should work after the update

Additional info:

Comment 1 shrek-m 2005-12-13 07:43:12 UTC
10 days without ldap it was time for me to downgrade openldap


# rpm -Uvh --oldpackage packagelist

$ rpm -qa compat-openldap\* openldap\*

all is working now like expected.

thanks for your broken update :-(

Comment 2 Heiner Westphal 2005-12-16 11:52:18 UTC
I got the same problem but was able to "fix" it for me.

Source of the problem is, that /etc/init.d/ldap function
configtest() runs slaptest as user root, not user ldap.
slaptest does not seem to close the DB properly thus
leaving __* files owned by root in the db dir.
This prevents slapd to access the db when started with
uid ldap.

I commented out the last if-block in function configtest
thus skipping the configtest, which I had done by hand
before. My slapd starts now.


Heiner Westphal

Comment 3 shrek-m 2005-12-16 12:59:43 UTC
hi heiner,

can you provide a "diff" because i do not know which lines i have to comment out :-(

Comment 4 Heiner Westphal 2005-12-16 14:24:17 UTC
If you already ran into the problem, go to your bdb-directory,
do a "db_recover" and "chown ldap.ldap *" before trying to restart
it again.

The last *top level* if-block in function configtest, I should have called 
the part to comment:
(all lines start with #, all else is unintended line break):

----------- cut here --- no diff, since I changed the orig file ---
        # Check the configuration file.
#       if ! action $"Checking configuration files for $prog: " $slaptest
$slaptestflags ; then
#               if $slaptest -u > /dev/null 2> /dev/null ; then
#                       dirs=`LANG=C egrep '^directory[[:space:]]+[[:print:]]+$'
 /etc/openldap/slapd.conf | awk '{print $2}'`
#                       for directory in $dirs ; do
#                               if test -r $directory/__db.001 ; then
#                                       echo -n $"stale lock files may be presen
t in $directory" ; warning ; echo
#                               fi
#                       done
#               fi
#               exit 1
#       fi
-------------- cut here ----------------------

Comment 5 shrek-m 2005-12-16 15:03:04 UTC
thanks :-)

`chown ldap:ldap`  was not necessary because  user:group  was "ldap"
your modification in the script and  `db_recover`  was necessary.

i do not know if this is ok, i tried `db_recover` a second time and i got this
result, ldap is ok.

# db_recover
db_recover: Program version 4.2 doesn't match environment version
db_recover: Ignoring log file: log.0000000002: unsupported log version 10
db_recover: Invalid log file: log.0000000002: Invalid argument
db_recover: PANIC: Invalid argument
db_recover: PANIC: DB_RUNRECOVERY: Fatal error, run database recovery
db_recover: DB_ENV->open: DB_RUNRECOVERY: Fatal error, run database recovery

Comment 6 shrek-m 2005-12-16 15:37:32 UTC
and the db is no longer valid for the previous openldap :-(
thanks :-(

this should be a openldap-FC3 update and no FC3 -> FC4 update.

Note You need to log in before you can comment on or make changes to this bug.