install openldap berkley version errors
 

I hope this is the right place to post this and that I can get some help. I pretty much suck at troubleshooting build issues.
we are running oracle red-hat linux 2.6.32-200.20.1.el5uek #1 SMP Fri Oct 7 02:29:42 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux

trying to build the latest stable version of openldap ( 2.4.23 )

When running configure I keep getting a version error for berkely db.
checking for db.h... yes
checking for Berkeley DB major version in db.h... 4
checking for Berkeley DB minor version in db.h... 3
checking if Berkeley DB version supported by BDB/HDB backends... no
configure: error: BerkeleyDB version incompatible with BDB/HDB backends

I've read what I can on the forums but with my limited knowledge of how configure works I am still at a loss.

I downloaded and built the lastest version of berkley db (5.3.15). It still failed.
I exported LD_LIBRARY_PATH to point to the berkely db lib directory. It still failed.

Can someone help me or point me in the right direction please ?

Thanks,
floyd

Hi and welcome to LQ,

For the ./configure script to find the correct BerkeleyDB, you need to add the following:
Of course you must change the path to BerkeleyBD accordingly if it's not installed under /usr/local/BerkeleyDB.5.3

Regards

Thank you very much. I think that helped, as I got a bit farther now but still complaining about Berkley.
Here's my message now.

checking for db.h... yes
checking for Berkeley DB major version in db.h... 5
checking for Berkeley DB minor version in db.h... 3
checking if Berkeley DB version supported by BDB/HDB backends... yes
checking for Berkeley DB link (default)... no
configure: error: BDB/HDB: BerkeleyDB not available

Do I have to do some linking of the berkely db I installed ?

Thank You !
Floyd

Hi,

According to this, you need a 4.x version of BerkeleyDB.
FYI, I'm using 4.8.24 with the latest openldap 2.4.28 and it works fine.

Regards

Much obliged. I will give that a try and report back.

Thank you,
Floyd

Oh well, still doesn't work.
I downloaded and installed Berkeley DB 4.7.25, and ran LDFLAGS=-L/usr/local/BerkeleyDB.4.7/lib CPPFLAGS="-D_GNU_SOURCE -I/usr/local/BerkeleyDB.4.7/include" ./configure

Now I am getting this:
checking for db.h... yes
checking for Berkeley DB major version in db.h... 4
checking for Berkeley DB minor version in db.h... 7
checking if Berkeley DB version supported by BDB/HDB backends... yes
checking for Berkeley DB link (-ldb-4.7)... yes
checking for Berkeley DB library and header version match... no
configure: error: Berkeley DB version mismatch


I see in the configure log that it's failing here.

./conftest: error while loading shared libraries: libdb-4.7.so: cannot open shared object file: No such file or directory
configure:28943: $? = 127


Wonder why that .so file isn't found , since it's there, as evidenced by this:
ls -lL /usr/local/BerkeleyDB.4.7/lib
total 8760
-rw-r--r-- 1 root root 2272180 Dec 28 09:20 libdb-4.7.a
-rw-r--r-- 1 root root 821 Dec 28 09:19 libdb-4.7.la
-rwxr-xr-x 1 root root 1463493 Dec 28 09:19 libdb-4.7.so
-rwxr-xr-x 1 root root 1463493 Dec 28 09:19 libdb-4.so
-rw-r--r-- 1 root root 2272180 Dec 28 09:20 libdb.a
-rwxr-xr-x 1 root root 1463493 Dec 28 09:19 libdb.so


Thank you,
Floyd

I guess you have a /usr/include/db.h that is a symlink pointing to a different BerkeleyDB (maybe the one came with your system).
You can change the symlink to point to /usr/local/BerkeleyDB.4.7include/db.h. After the build is finished you should undo that change, because it may harm other system components

Regards

Thanks. That's not it.
I relinked the db.h in /usr/include to point to the 4.7 one. Same exact error.
Then I even replaced the original link and copied over the newer db.h to that location, just to see.
Same exact error.

Why can't it find that lib.so file ?

Must be something simple that I'm missing.

Thank you !

Floyd

The version mismatch is because it's reading the version from the db.h and the symlink trick should have worked.
Anyway, you can add /usr/local/BerkeleyDB.4.7/lib on top of /etc/ld.so.conf and run as root
Also check your LD_LIBRARY_PATH and make sure it points to the correct BerkeleyDB

OOOOH Yeaaaaaa!!!

Thanks so so much.
Can't say that I won't have more issues, but adding the Berkely path back to the LD_LIBRARY_PATH got me through the configure.
I had it there before, when under the 5.3 version.

Thanks for sticking with me Bathory.

Glad to see it worked
You may mark the thread "Solve" using the "Thread Tools" on top of the page.

Regards

help starting slapd
 

Hello,
I'm pretty new to openldap. We have had an instance of slap running for Aix in the past, using symas version of ldap.
Now I am trying to get openldap version 2.4.23 running on Linux.
we are running oracle red-hat linux 2.6.32-200.20.1.el5uek #1 SMP Fri Oct 7 02:29:42 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux

I built the openldap with the default options for configure ( except for pointing it to a new Berkley db.

I went into /usr/openldap-2.4.23/servers/slapd and edited the slapd.conf file to tell it about our database and the schema we want to use.

I would think that I just need to run slapd now in order to initialize the database, but when I run /usr/openldap-2.4.23/servers/slapd/slapd nothing happens.

Can someone point me in the right direction here ?

Thank you,
Floyd

Are you sure it's not running? What gives:
BTW, you should run "make install" after running "make" to install the various openldap files in their correct location.

Thanks.
I did run make install, now I went and started everything again.
I did a make clean and a rebuild of berkley bd,
then I did a configure, make depend on ldap.
Now I am running a make test and it hangs right here:
>>>>> Starting test001-slapadd for bdb...
running defines.sh
Running slapadd to build slapd database...

a ps -ef|grep make yields this

root 10569 25153 0 13:25 pts/1 00:00:00 make test
root 10570 10569 0 13:25 pts/1 00:00:00 /bin/sh -c cd tests; make test
root 10571 10570 0 13:25 pts/1 00:00:00 make test
root 10572 10571 0 13:25 pts/1 00:00:00 make bdb

a ps -ef|grep ldap, yields this:
root 10841 10591 0 13:25 pts/1 00:00:00 /bin/sh ./scripts/test001-slapadd
root 10857 10841 0 13:25 pts/1 00:00:00 /usr/openldap-2.4.23/tests/../servers/slapd/slapd -Ta -d 0 -f /usr/openldap-2.4.23/tests/testrun/slapadd.conf -l ./testdata/test-ordered.ldif


I tried an strace on all those processes. They all say:
Process 10570 attached - interrupt to quit
wait4(-1,

The only one that says something a little different is process 10857 which shows this:

[root@prod-meteor1v4 floydw]# strace -p 10857
Process 10857 attached - interrupt to quit
futex(0x7f7d1fbfd924, FUTEX_WAIT, 1, NULL


So something is hanging, but why I don't know.

Thank you !
Floyd

make test can take a good amount of time to complete, so I tend to skip this step ;)
If you want to rebuild a program compiled from sources, it's always better to run "make distclean" and if that's not available to run "make clean". And you should do this for both BerkeleyDB and openldap.
BTW since you're doing all this, I suggest you to use the latest openldap-2.4.28

Ok thanks again. I will get on it tomorrow with the newer version and see what we get.
For now, I think since I did a nice clean and rebuild of the database, without any errors, I'll leave that alone and concentrate on openldap tomorrow.

Thanks again Bathory !

Floyd

I installed version 2.8. I ran all the tests. They looked good as far as I can see scrolling across the screen. ( there was no leftover log to look at )
So I tried again to start ldap with the command below. You can see the output. It looks like it starts but then just kills itself.
I don't find any logs that I can look at to see what's going on. Shouldn't there be a slapd log somewhere ? I saw nowhere to configure for one in the slapd.conf file.

One more thing I thought of.
I am not so sure about this part of the slapd.conf file.

# Load dynamic backend modules:
# modulepath %MODULEDIR%
moduleload back_bdb.la
# moduleload back_hdb.la
# moduleload back_ldap.la


For one thing, what is %MODULEDIR% supposed to point to, the berkly db libraries or what ?
For another, moduleload, we have nothing anywahere called back_bdb.la. What should that be pointing to. Maybe this is why things wont't start right ??


Please advise :))

Thanks !!
Floyd


Ok, I figured out how to get more debugging. This is the most I can get ( -1 level ).
It seems to show that there is something it doesn't like in the core.schema. I got that from our other older ldap installation because I didn't see one in my new installation.
Is there somewhere I am supposed to get the core schema from ??


4efc6460 line 128 (attributetype ( 2.5.4.13 NAME 'description' DESC 'RFC2256: descriptive information' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} ))
4efc6460 /usr/openldap-2.4.28/schemas/core.schema: line 128 attributetype: Duplicate attributeType: "2.5.4.13"
4efc6460 slapd.conf: line 6: <include> handler exited with 1!
4efc6460 slapd destroy: freeing system resources.
4efc6460 slapd stopped.
4efc6460 connections_destroy: nothing to destroy.


[root@prod-meteor1v4 slapd]# ./slapd -f slapd.conf -F /usr/openldap-2.4.28/servers/slapd -d 1
4efc5d03 @(#) $OpenLDAP: slapd 2.4.28 (Dec 28 2011 14:32:20) $
floydw@prod-meteor1v4.nslc.org:/usr/openldap-2.4.28/servers/slapd
ldap_pvt_gethostbyname_a: host=prod-meteor1v4.nslc.org, r=0
4efc5d03 daemon_init: listen on ldap:///
4efc5d03 daemon_init: 1 listeners to open...
ldap_url_parse_ext(ldap:///)
4efc5d03 daemon: listener initialized ldap:///
4efc5d03 daemon_init: 2 listeners opened
ldap_create
4efc5d03 slapd init: initiated server.
4efc5d03 slap_sasl_init: initialized!
4efc5d03 bdb_back_initialize: initialize BDB backend
4efc5d03 bdb_back_initialize: Berkeley DB 4.7.25: (May 15, 2008)
4efc5d03 hdb_back_initialize: initialize HDB backend
4efc5d03 hdb_back_initialize: Berkeley DB 4.7.25: (May 15, 2008)
4efc5d03 mdb_back_initialize: initialize MDB backend
4efc5d03 mdb_back_initialize: MDB 0.9.0: ("September 1, 2011")
4efc5d03 backend_startup_one: starting "cn=config"
4efc5d03 slapd destroy: freeing system resources.
4efc5d03 slapd stopped.
4efc5d03 connections_destroy: nothing to destroy.

Hi,

You don't need the -F option. Try the same command without the "-F /usr/openldap-2.4.28/servers/slapd"
Regarding logs, take a look at /var/log/debug (at least this is where slapd write its logs on my Slackware)

If you didn't use "--enable-modules" while configuring the sources, you don't need any moduleload options.

Hi Bathory,
Well I may not have something set in my environment but I apparently need the -F dir option. If I try and run it without it, then nothing happens. I just get my prompt back.
Also, there is nothing in /var/log messages about this. I may have to look at syslog.conf and see where the default LOCAL4 logs to.

As far as modules, we'll need the backend database, that is where our ldap registry will be stored. So don't we have to load it ?

Thanks,
floyd

The -F option is used when you're not using slapd.conf, but the cn=config DIT in order to configure your server. Using both of them makes slapd to try to convert slapd.conf into the necessary ldifs used by cn=config and write them into the directory specified by the -F option. See the slapd manpage for a better explanation

Regarding the modules, if you haven't used the "--enable-modules" option in ./configure, they are built statically into slapd, so you don't need that directive.

Could you post the slapd.conf you;re using to do your tests?

Thank you.
Can't say I really understand your first line. I appreciate you trying with me. I must have a mental block about understanding this, that I haven't gotten through yet.
btw, I got the logs going by editing syslog.conf to send local4.debug to a file.
Below is the slapd.conf I'm trying to get running.



#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
#include %SYSCONFDIR%/schema/core.schema
include /usr/openldap-2.4.28/schemas/core.schema
include /usr/openldap-2.4.28/schemas/nchelp.schema

# Define global ACLs to disable default read access.

# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral ldap://root.openldap.org

#pidfile %LOCALSTATEDIR%/run/slapd.pid
#argsfile %LOCALSTATEDIR%/run/slapd.args
pidfile /usr/openldap-2.4.28/servers/run/slapd.pid
pidfile /usr/openldap-2.4.28/servers/run/slapd.args

# Load dynamic backend modules:
# modulepath %MODULEDIR%
moduleload back_bdb.la
# moduleload back_hdb.la
# moduleload back_ldap.la

# Sample security restrictions
# Require integrity protection (prevent hijacking)
# Require 112-bit (3DES or better) encryption for updates
# Require 63-bit encryption for simple bind
# security ssf=1 update_ssf=112 simple_bind=64

# Sample access control policy:
# Root DSE: allow anyone to read it
# Subschema (sub)entry DSE: allow anyone to read it
# Other DSEs:
# Allow self write access
# Allow authenticated users read access
# Allow anonymous users to authenticate
# Directives needed to implement policy:
# access to dn.base="" by * read
# access to dn.base="cn=Subschema" by * read
# access to *
# by self write
# by users read
# by anonymous auth
#
# if no access controls are present, the default policy
# allows anyone and everyone to read anything but restricts
# updates to rootdn. (e.g., "access to * by * read")
#
# rootdn can always read and write EVERYTHING!

#######################################################################
# BDB database definitions
#######################################################################

database bdb
suffix "o=meteorregistry.com"
rootdn "cn=nslcadmin,o=meteorregistry.com"
# Cleartext passwords, especially for the rootdn, should
# be avoid. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
rootpw secret
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
#directory %LOCALSTATEDIR%/openldap-data
directory /usr/openldap-2.4.23/servers/openldap-data
# Indices to maintain
index objectClass eq

Please comment out the following 2 lines and try again
Also make sure that the schema files are in the correct location.

I'm again telling you to run "make install", so everything is installed in its correct place and run slapd from /usr/local/libexec/slapd (if you used no prefix in ./configure)

Thank you.
I've done everything you said just now.
Here's the command I ran to get it started:
/usr/local/libexec/slapd -f /usr/openldap-2.4.28/servers/slapd/slapd.conf -d -1 >slapd.out 2>&1


And here is the output of slapd.out

4efc814e @(#) $OpenLDAP: slapd 2.4.28 (Dec 28 2011 14:32:20) $
floydw@prod-meteor1v4.nslc.org:/usr/openldap-2.4.28/servers/slapd
ldap_pvt_gethostbyname_a: host=prod-meteor1v4.nslc.org, r=0
4efc814e daemon_init: <null>
4efc814e daemon_init: listen on ldap:///
4efc814e daemon_init: 1 listeners to open...
ldap_url_parse_ext(ldap:///)
4efc814e daemon: listener initialized ldap:///
4efc814e daemon_init: 2 listeners opened
ldap_create
4efc814e slapd init: initiated server.
4efc814e slap_sasl_init: initialized!
4efc814e bdb_back_initialize: initialize BDB backend
4efc814e bdb_back_initialize: Berkeley DB 4.7.25: (May 15, 2008)
4efc814e hdb_back_initialize: initialize HDB backend
4efc814e hdb_back_initialize: Berkeley DB 4.7.25: (May 15, 2008)
4efc814e mdb_back_initialize: initialize MDB backend
4efc814e mdb_back_initialize: MDB 0.9.0: ("September 1, 2011")
4efc814e reading config file /usr/openldap-2.4.28/servers/slapd/slapd.conf
4efc814e line 6 (include /usr/openldap-2.4.28/schemas/core.schema)
4efc814e reading config file /usr/openldap-2.4.28/schemas/core.schema
4efc814e line 77 (attributetype ( 2.5.4.2 NAME 'knowledgeInformation' DESC 'RFC2256: knowledge information' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} ))
4efc814e line 86 (attributetype ( 2.5.4.4 NAME ( 'sn' 'surname' ) DESC 'RFC2256: last (family) name(s) for which the entity is known by' SUP name ))
4efc814e line 92 (attributetype ( 2.5.4.5 NAME 'serialNumber' DESC 'RFC2256: serial number of the entity' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{64} ))
4efc814e line 96 (attributetype ( 2.5.4.6 NAME ( 'c' 'countryName' ) DESC 'RFC2256: ISO-3166 country 2-letter code' SUP name SINGLE-VALUE ))
4efc814e line 100 (attributetype ( 2.5.4.7 NAME ( 'l' 'localityName' ) DESC 'RFC2256: locality which this object resides in' SUP name ))
4efc814e line 104 (attributetype ( 2.5.4.8 NAME ( 'st' 'stateOrProvinceName' ) DESC 'RFC2256: state or province which this object resides in' SUP name ))
4efc814e line 110 (attributetype ( 2.5.4.9 NAME ( 'street' 'streetAddress' ) DESC 'RFC2256: street address of this object' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} ))
4efc814e line 114 (attributetype ( 2.5.4.10 NAME ( 'o' 'organizationName' ) DESC 'RFC2256: organization this object belongs to' SUP name ))
4efc814e line 118 (attributetype ( 2.5.4.11 NAME ( 'ou' 'organizationalUnitName' ) DESC 'RFC2256: organizational unit this object belongs to' SUP name ))
4efc814e line 122 (attributetype ( 2.5.4.12 NAME 'title' DESC 'RFC2256: title associated with the entity' SUP name ))
4efc814e line 128 (attributetype ( 2.5.4.13 NAME 'description' DESC 'RFC2256: descriptive information' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} ))
4efc814e /usr/openldap-2.4.28/schemas/core.schema: line 128 attributetype: Duplicate attributeType: "2.5.4.13"
4efc814e /usr/openldap-2.4.28/servers/slapd/slapd.conf: line 6: <include> handler exited with 1!
4efc814e slapd destroy: freeing system resources.
4efc814e slapd stopped.
4efc814e connections_destroy: nothing to destroy.

Well I don't know why it's trying to read attributetype ( 2.5.4.13). In the core.schema that comes with openldap-2.4.28 it's commented out

Remember I told you I couldn't find the core.schema, so I copied the one over from a previous version of our symas ldap.
Do you know where core.schema is ? I'll copy it into the schemas directory that I made.

never mind, I found it. I'll copy it over and try again.

Oh yea !
root 20154 18054 0 10:56 pts/1 00:00:00 /usr/local/libexec/slapd -f /usr/openldap-2.4.28/servers/slapd/slapd.conf -d -1

So I moved the DB_CONFIG file where it was supposed to go, put the proper schema.core file in place and now I have slapd running in the foreground.
Above is the actual process.
Things look good so far.

Next I have to try and configure it somehow so it can talk to my ldap browser and I can see, modify ldif files through it.

Any ideas what is next ?

So many thanks for helping me get this far !!

Another problem sprang up.
I am not sure if there is a start / stop script to modify that does proper shutdowns and startups.
When I started it before I just did it in the foreground with:
/usr/local/libexec/slapd -f /usr/openldap-2.4.28/servers/slapd/slapd.conf -d 1

I eventually control c'd that. I tried to start it again and apparently since I didn't shut it down correctly the database is corrupted and it wont' start now.
Can you point me right here ?

Thank you,
Floyd



member $ owner $ roleOccupant $ PreferredTransport $ PreferredEncryption $ Contact ) )
4efc96e0 2.5.13.0 (objectIdentifierMatch): 4efc96e0 matchingRuleUse: ( 2.5.13.0 NAME 'objectIdentifierMatch' APPLIES ( supportedControl $ supportedExtension $ supportedFeatures $ supportedApplicationContext ) )
4efc96e0 slapd startup: initiated.
4efc96e0 backend_startup_one: starting "cn=config"
4efc96e0 config_back_db_open
4efc96e0 config_build_entry: "cn=config"
4efc96e0 config_build_entry: "cn=schema"
4efc96e0 >>> dnNormalize: <cn={0}core>
4efc96e0 <<< dnNormalize: <cn={0}core>
4efc96e0 config_build_entry: "cn={0}core"
4efc96e0 >>> dnNormalize: <cn={1}nchelp>
4efc96e0 <<< dnNormalize: <cn={1}nchelp>
4efc96e0 config_build_entry: "cn={1}nchelp"
4efc96e0 config_build_entry: "olcDatabase={-1}frontend"
4efc96e0 config_build_entry: "olcDatabase={0}config"
4efc96e0 config_build_entry: "olcDatabase={1}bdb"
4efc96e0 backend_startup_one: starting "o=meteorregistry.com"
4efc96e0 bdb_db_open: database "o=meteorregistry.com": unclean shutdown detected; attempting recovery.
4efc96e0 bdb_db_open: database "o=meteorregistry.com": dbenv_open(/usr/openldap-2.4.28/servers/slapd/openldap-data).
4efc96e0 bdb(o=meteorregistry.com): /usr/openldap-2.4.28/servers/slapd/openldap-data/logs: No such file or directory
4efc96e0 bdb(o=meteorregistry.com): PANIC: No such file or directory
4efc96e0 bdb(o=meteorregistry.com): unable to join the environment
4efc96e0 bdb_db_open: database "o=meteorregistry.com" cannot be recovered, err -30974. Restore from backup!
4efc96e0 ====> bdb_cache_release_all
4efc96e0 bdb(o=meteorregistry.com): txn_checkpoint interface requires an environment configured for the transaction subsystem
4efc96e0 bdb_db_close: database "o=meteorregistry.com": txn_checkpoint failed: Invalid argument (22).
4efc96e0 backend_startup_one (type=bdb, suffix="o=meteorregistry.com"): bi_db_open failed! (-30974)
4efc96e0 slapd shutdown: initiated
4efc96e0 ====> bdb_cache_release_all
4efc96e0 bdb_db_close: database "o=meteorregistry.com": alock_close failed
4efc96e0 slapd destroy: freeing system resources.
4efc96e0 slapd stopped

I'm using the attached script to start/stop openldap and never had such problems. If you want to use it change LD_LIBRARY_PATH accordingly.

Check DB_CONFIG to see why it's trying to write the logs in that directory, By defaults logs are written to the same directory where DB_CONFIG is located (it should be the directory defined by the "directory" directive in slapd.conf)

Thanks.
I will check out and use your script. I appreciate it.
As for the start problem.
I told it in the slapd.conf that the data files go into that directory. Then it told me I need to put DB_CONFIG in there. that seemed fine. It started up the first time.
Then after I stopped it it wouldn't start again.
During troubleshooting that, I figured I'd start it from scratch so I removed all the database stuff from that directory.
that caused the log error. Apparently it needs to be able to write to logs.
So I created the log directory in there and it gets further now. It makes a bunch of databases in there as evidenced by this ls :

[root@prod-meteor1v4 slapd]# ls openldap-data
alock __db.001 __db.002 __db.003 __db.004 __db.005 __db.006 DB_CONFIG logs

But it fails trying to create a database called id2entry.bdb ( see below )


4efca081 slapd startup: initiated.
4efca081 backend_startup_one: starting "cn=config"
4efca081 config_back_db_open
4efca081 config_build_entry: "cn=config"
4efca081 config_build_entry: "cn=schema"
4efca081 >>> dnNormalize: <cn={0}core>
4efca081 <<< dnNormalize: <cn={0}core>
4efca081 config_build_entry: "cn={0}core"
4efca081 >>> dnNormalize: <cn={1}nchelp>
4efca081 <<< dnNormalize: <cn={1}nchelp>
4efca081 config_build_entry: "cn={1}nchelp"
4efca081 config_build_entry: "olcDatabase={-1}frontend"
4efca081 config_build_entry: "olcDatabase={0}config"
4efca081 config_build_entry: "olcDatabase={1}bdb"
4efca081 backend_startup_one: starting "o=meteorregistry.com"
4efca081 bdb_db_open: database "o=meteorregistry.com": dbenv_open(/usr/openldap-2.4.28/servers/slapd/openldap-data).
4efca081 bdb_db_open: database "o=meteorregistry.com": db_open(/usr/openldap-2.4.28/servers/slapd/openldap-data/id2entry.bdb) failed: No such file or directory (2).
4efca081 ====> bdb_cache_release_all
4efca081 backend_startup_one (type=bdb, suffix="o=meteorregistry.com"): bi_db_open failed! (2)
4efca081 slapd shutdown: initiated
4efca081 ====> bdb_cache_release_all
4efca081 bdb_db_close: database "o=meteorregistry.com": alock_close failed
4efca081 slapd destroy: freeing system resources.
4efca081 slapd stopped.

You need to populate your directory. See this for an explanation
While slapd is not running use slapadd to add the ldif containing the base dn(s)

Ok,
So I put an ldif file in the current directory ( same directory where the slapd.conf is ), and I ran this:

./slapadd -l /usr/openldap-2.4.28/servers/slapd/s18.ldif -f slapd.conf -d -1

I get the same basic error, which is this:
4efcbbf3 slapadd startup: initiated.
4efcbbf3 backend_startup_one: starting "o=meteorregistry.com"
4efcbbf3 bdb_db_open: "o=meteorregistry.com"
4efcbbf3 bdb_db_open: database "o=meteorregistry.com": dbenv_open(/usr/openldap-2.4.28/servers/slapd/openldap-data).
4efcbbf3 bdb_db_open: database "o=meteorregistry.com": db_open(/usr/openldap-2.4.28/servers/slapd/openldap-data/id2entry.bdb) failed: No such file or directory (2).
4efcbbf3 ====> bdb_cache_release_all
4efcbbf3 backend_startup_one (type=bdb, suffix="o=meteorregistry.com"): bi_db_open failed! (2)
slap_startup failed


Thanks !!
Floyd

What's in s18.ldif? If there are some sensitive data, you may mask it.

Since you're migrating from another ldap server, you should export the correct ldif from it, and import the same in openldap with slapadd. You can delete everything (except DB_CONFIG) from /usr/openldap-2.4.28/servers/slapd/openldap-data before running slapadd again
I guess it's not a permissions problem, as slapd can write in /usr/openldap-2.4.28/servers/slapd/openldap-data its logs and transaction data, but anyway check the permissions of that directory. Also, I don't know if oracle linux uses selinux, so check if that's the case.

Thank you.
I deleted all the files in the openldap-data directory except the logs directory and the DB_CONFIG. ( done this before too )
I ran this:
slapadd -b "o=meteorregistry.com" -v -l s18.ldif

I got back the same.
[root@prod-meteor1v4 slapd]# ./slapadd -b "o=meteorregistry.com" -v -l s18.ldif
4efda633 bdb_db_open: database "o=meteorregistry.com": db_open(/usr/openldap-2.4.28/servers/slapd/openldap-data/id2entry.bdb) failed: No such file or directory (2).
4efda633 backend_startup_one (type=bdb, suffix="o=meteorregistry.com"): bi_db_open failed! (2)
slap_startup failed

Our ldif file is really open to all so it's ok. I just took the liberty of snipping out the encrypted ssl certs in there, and I cut out a lot of the file because it's just more of the same. It's attached.

Permissions aren't a problem because right now everything is done by root.

Thank you !
Floyd

Did you check if it's selinux? If selinux is enabled, a process cannot write in some directories even if run as root, if there is no such permission by selinux
FYI I've tried your ldif and the 1st dn was imported successfully. The rest was rejected because of invalid dn

I don't know what selinux is or how to check for it. We have Oracle's version of Red Hat unbreakable linux. Is there something I can check ?

I would imagine that maybe the reason the ldif doesn't work for you is because you need the special schema ?

You can run
to check if that's the case

Yeah, I'm missing some objectclasses, but I tried to import the ldif just to see what happens. The id2entry.bdb and the other dbs was created as they should.

Thanks.
So selinux is disabled. I guess that means no permission problems right ?

Yup it's disabled. I cannot think of anything else that does not allow writing!
Try to use a different directory to store the data. You can use the attached slapd.conf (adjust the schemas location) and create the /tmp/data directory to store the database.
It's the one I've used to test your ldif.

That seems to work, thank you !!

I run this to start it:
./slapd -f ./slapd-linux.conf -d -1

and I run this to kill it.
kill -INT `cat /usr/local/var/run/slapd.pid`

Now I will try and get it running with the script you gave me.

Thanks again Bathory !!

So I am not able to start it with your script. The only thing I changed in your script was the LD_LIBRARY_PATH.
It just exits and says it can't start ldap.

But I can start it with this little script.
#!/bin/ksh

if [ $1 = "start" ]
then
cd /usr/openldap-2.4.28/servers/slapd
nohup /usr/local/libexec/slapd -f ./slapd-linux.conf &
fi
if [ $1 = "stop" ]
then
kill -INT `cat /usr/local/var/run/slapd.pid`
fi


Any idea why ?

Also I have a question.
In your slapd.conf file you have these:
suffix "o=meteorregistry.com"
rootdn "cn=Manager,o=meteorregistry.com"

I would like to change the rootdn to match what we have in our ldif which is this:
rootdn "cn=nslcadmin,o=meteorregistry.com"

Will that mess up the database if I do that ??

Thanks again !!

Floyd

First of all the script is not mine. Credits go to the person mentioned in the very first lines of it. Maybe it's because of the pid file being in a different place


No.
The rootdn is used when you have to run some ldap tools that need authentication (like ldapadd). Usually it's not even present in the database.

Regards

Sorry about that. Didn't want to insinuate anything. :-) Yea it's not the pid file location, I changed that. NO biggy.



Thanks Bathory !!
You really stuck with me, and I appreciate it.
Of course this is just the beginning. <grin>

I am going to mark this as solved.

the reason I couldn't get the id2entry.bdb database made was that I needed to make a directory called "db" in the database directory.
It was being pointed to by the DB_CONFIG file.

After that, I was able to import my ldif with slapadd -l [ldif file]

Thanks for all your help !!!!!