On 2/23/07, Asrai khn asraikhn@gmail.com wrote:
Hi,
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
how to fix this warning or just ignore it
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 transparent.
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..
- Can we replication older version of openldap (master) to newer version of
openldap (slave) currently 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: shutdown slapd slapcat -f /path/to/slapd.conf -l mydb.ldif vi /path/to/slapd.conf 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. :wq 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 restart slapd
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.
_Matt
Some links: http://www.openldap.org/faq/data/cache/1166.html http://www.openldap.org/faq/data/cache/1075.html