Bug 107253 - LDAP database is not createable on Fedora Core 0.95
LDAP database is not createable on Fedora Core 0.95
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: openldap (Show other bugs)
rawhide
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
:
Depends On:
Blocks: CambridgeTarget
  Show dependency treegraph
 
Reported: 2003-10-16 02:51 EDT by Emmanuel Seyman
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

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


Attachments (Terms of Use)

  None (edit)
Description Emmanuel Seyman 2003-10-16 02:51:31 EDT
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 15:47:48 EDT
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 18:19:35 EDT
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 18:32:38 EDT
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.