Bug 107253 - LDAP database is not createable on Fedora Core 0.95
Summary: LDAP database is not createable on Fedora Core 0.95
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: openldap (Show other bugs)
(Show other bugs)
Version: rawhide
Hardware: i386 Linux
medium
medium
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: CambridgeTarget
TreeView+ depends on / blocked
 
Reported: 2003-10-16 06:51 UTC by Emmanuel Seyman
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Fixed In Version: 2.1.22-7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-10-16 22:32:38 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Emmanuel Seyman 2003-10-16 06:51:31 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030715
Mozilla Firebird/0.6

Description of problem:
                                                                               
                                            
U8pon installation of openldap-server, running the command "service ldap starts"
logs this in /var/log/messages:
                                                                               
                                            
Oct  4 06:59:06 rokjor slapd[7847]: ldbm: ==> unable to initialize mutex:
Function not implemented
Oct  4 06:59:06 rokjor slapd[7847]: ldbm: ==> process-private: unable to
initialize environment lock: Function not
+implemented
Oct  4 06:59:06 rokjor slapd[7847]: ldbm_initialize_env(): FATAL error in
dbEnv->open() : Function not implemented (38)
Oct  4 06:59:06 rokjor ldap: D�rrage de slapd succeeded
                                                                               
                                            
Injecting an ldif file gives the following error message:
                                                                               
                                            
SASL/DIGEST-MD5 authentication started
ldap_sasl_interactive_bind_s: Internal (implementation specific) error (80)
        additional info: SASL(-13): user not found: no secret in database
                                                                               
                                            


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

How reproducible:
Always

Steps to Reproduce:
1. Install openldap-server on Fedora Core 0.95
2. Run the command "service ldap starts"
3. See contents of /var/log/messages
    

Actual Results:  It is not possible to inject LDAP entries in the ldbm database

Expected Results:  Adding entries should be possible

Additional info:

The dbEnv->open() line makes me wonder if this isn't a db4 error.

Sounds like somebody suffered this on Severn 1 and asked the question on the
openldap lists to no avail:
http://www.openldap.org/lists/openldap-bugs/200308/msg00024.html

Also, this sounds related to another openldap in bugzilla: #90092

Comment 1 Nalin Dahyabhai 2003-10-16 19:47:48 UTC
What type of CPU is the system on?  Which arch/version of glibc is installed
(rpm -q --qf '%{name}-%{version}-%{release}-%{arch}\n' glibc)?

Comment 2 Emmanuel Seyman 2003-10-16 22:19:35 UTC
The CPU is a Pentium 133 from the Dark Ages (ie 1995).

[root@rokjor root]# rpm -q --qf '%{name}-%{version}-%{release}-%{arch}\n' glibc
glibc-2.3.2-98-i386

relevant parts of /proc/cpuinfo:

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 5
model           : 2
model name      : Pentium 75 - 200
stepping        : 11
cpu MHz         : 132.634


Comment 3 Nalin Dahyabhai 2003-10-16 22:32:38 UTC
That's what I suspected.  The bundled libdb is unconditionally dependent on
NPTL-specific functionality when used by multi-threaded applications like slapd,
and NPTL is only part of the i686 version of the glibc package.

The openldap-servers-2.1.22-7 package should include both NPTL and non-NPTL
bundled libraries, so the ldbm back-end should work again (the bdb back-end
absolutely requires it, so you'll need to use an ldbm database).

Marking as resolved in that version/release, please reopen if you find that this
continues to be a problem.


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