Matt Sporleder wrote:
Migrate now or migrate later when ldbm is removed. BDB is faster and offers more backup/recovery features than ldbm.
More to the point- back-ldbm has no way of recovering from crashes and won't tell you if there are problems in your database. It just starts back up and continues merrily along. Hopefully at some point you will notice things are badly broken, but you will probably have missed the small things like failed lookups due to index failures. Recovery from situations like that can often be difficult. Also note that back-ldbm is not being actively maintained, so if you find a problem it is not likely to be fixed by the OpenLDAP team.
To be blunt, using back-ldbm in any production capacity is a recipe for disaster.
Cheers,
Matthew Hardin Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
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.
Office policy :-S
our replication slave was working fine before upgrading to fc6 now its
fails
to start 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)
If i remove the old db files from datadir and then start 'services ldap start' it works fine but its not working with old db files, we you
thinks i
have to setup the replication from start?
These are all permissions issues. slapd rarely runs as root. Just make sure it runs as a user with permissions to get to all of the directories it needs. (including the slapd.pid file, the database files, and anything else mentioned in the slapd.conf)