Bug 174829 - ldap is broken after update to 2.2.29-1.FC3
ldap is broken after update to 2.2.29-1.FC3
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: openldap (Show other bugs)
3
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Jay Fenlason
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-12-02 10:58 EST by shrek-m
Modified: 2014-08-31 19:27 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-04-18 16:32:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description shrek-m 2005-12-02 10:58:28 EST
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)
                                                           [FEHLGESCHLAGEN]
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):
openldap-servers-2.2.29-1.FC3

How reproducible:
Always

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 02:43:12 EST
10 days without ldap it was time for me to downgrade openldap

download.fedora.redhat.com/pub/fedora/linux/core/3/i386/os/Fedora/RPMS/

# rpm -Uvh --oldpackage packagelist

$ rpm -qa compat-openldap\* openldap\*
openldap-clients-2.2.13-2
compat-openldap-2.1.30-2
openldap-2.2.13-2
openldap-servers-2.2.13-2

all is working now like expected.

thanks for your broken update :-(
Comment 2 Heiner Westphal 2005-12-16 06:52:18 EST
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.

HTH,

Heiner Westphal
Comment 3 shrek-m 2005-12-16 07:59:43 EST
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 09:24:17 EST
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 10:03:04 EST
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 10:37:32 EST
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.