[Date Prev][Date Next]
Re: WARNING: No dynamic config support for database ldbm
On 2/23/07, Asrai khn <firstname.lastname@example.org> wrote:
After upgrading our ldap server to FC5 and openldap-2.3.19-4 (we are using
yum to update packages). We getting ...
WARNING: No dynamic config support for database ldbm
when starting ldap services, however it starts fine and we are not facing
any issues while authentication from that openldap or adding new entries to
it using phpldapadmin.
I have read in archives of this mailing list that ldbm backend is going to
be removed when 2.4 releases, now my concern is
1) how to fix this warning or just ignore it
2) If recommend to migrate to another backend database eg bdb, then how to
convert the current records to it so that if we change 'database' directive
in slapd.conf to 'bdb' it gives no error and migration would seem
Another problem which we are facing is our ldap replication is broken after
we upgraded our slave ldap server to FC6 which comes with newer version of
openldap ' openldap-2.3.27-4', when we tries to start ldap services on slave
it exit with error...
Checking configuration files for slapd: WARNING: No dynamic config support
for database ldbm.
unable to open file "/var/run/slapd.pid": 13 (Permission denied)
I am no expert of openldap neither is ldap is configured by me, now i have
to fix the replication and all other warnings..
1) Can we replication older version of openldap (master) to newer version of
master (FC5) < slave (FC6)
You can ignore that warning. It's mostly talking about ldbm's
inability to be used with cn=config and other fancy features.
Migrate to BDB or HDB. Here's the rough idea:
slapcat -f /path/to/slapd.conf -l mydb.ldif
Change your database to a new directory.
Read about tuning, cache sizing, and other stuff.
Read openldap man pages.
Read oracle's tuning docs for bdb.
Re-Read openldap man pages.
slapadd -f /path/to/slapd.conf -l mydb.ldif
Fix permissions on /var/run so the slapd user can write there -- this
one is pretty easy
Also- there isn't any good reason to rely on redhat for your openldap
packages. (office politics are a bad reason ;) They move much slower
than the bug fixes/releases of openldap (which are very frequent). If
you check the archives, there are a few people who keep up-to-date
rpm's around. You didn't mention slurpd, so I assume that's working
correctly, or you're using syncrepl.