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
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 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..
1) Can we replication older version of openldap (master) to newer version of openldap (slave) currently master (FC5) < slave (FC6)
Any help in this regards will be greatly appreciated.
Thanks.
I am no OpenLDAP expert nor be able to help you with the error, but just like to share an idea of migrating.
1. Export your current directory and import to a new backend. (Perhaps slapcat can help?) 2. Fix replication and set the replica server to use the new db backend, when all is synced switch from there. (Not sure though if using different backends for replication is allowed)
I am also as new as you with regard to LDAP, but google has been my friend, comments and suggestions regarding the above will be very helpful.
---OpenLDAP/SSL/sudo/PostFix
_____
From: openldap-software-bounces+zoticaicpassion=gmail.com@OpenLDAP.org [mailto:openldap-software-bounces+zoticaicpassion=gmail.com@OpenLDAP.org] On Behalf Of Asrai khn Sent: Friday, February 23, 2007 9:41 PM To: openldap-software@openldap.org Subject: WARNING: No dynamic config support for database ldbm
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
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 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..
1) Can we replication older version of openldap (master) to newer version of openldap (slave) currently master (FC5) < slave (FC6)
Any help in this regards will be greatly appreciated.
Thanks.
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
Matt thanks for the reply
You can ignore that warning. It's mostly talking about ldbm's
inability to be used with cn=config and other fancy features.
So what you suggest, do we need to migrate to some other backend db or we can use the existing ldbm and ignoring the warning? (remember this is our primary ldap server for authenticating users for different services eg, company php application, wiki, phpmyadmin etc
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?
Thanks. Askar
Asrai khn ha scritto:
Matt thanks for the reply
You can ignore that warning. It's mostly talking about ldbm's
inability to be used with cn=config and other fancy features.
So what you suggest, do we need to migrate to some other backend db or we can use the existing ldbm and ignoring the warning? (remember this is our primary ldap server for authenticating users for different services eg, company php application, wiki, phpmyadmin etc
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?
Thanks. Askar
The error seems clear enough: does the user running slapd as have the right permissions to write under /var/run ? I believe you only need to fix the paths in your slapd.conf to point back where your installation was pointing to...
Ing. Luca Scamoni Responsabile Ricerca e Sviluppo
SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------- Office: +39.0382.573859 (137) Mobile: +39.347.1014425 Email: luca.scamoni@sys-net.it -------------------------------------
On 2/23/07, Asrai khn asraikhn@gmail.com wrote:
Matt thanks for the reply
You can ignore that warning. It's mostly talking about ldbm's inability to be used with cn=config and other fancy features.
So what you suggest, do we need to migrate to some other backend db or we can use the existing ldbm and ignoring the warning? (remember this is our primary ldap server for authenticating users for different services eg, company php application, wiki, phpmyadmin etc
Migrate now or migrate later when ldbm is removed. BDB is faster and offers more backup/recovery features than ldbm.
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)
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)
On 2/23/07, matthew sporleder msporleder@gmail.com wrote:
Migrate now or migrate later when ldbm is removed. BDB is faster and offers more backup/recovery features than ldbm.
yeah we have to decide fast, and look like all eyes on me now for making this move :)
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)
Thanks for the hint also thanks to Luca, i just changed two directives in slapd.conf to use /tmp instead of /var/run directory
pidfile /tmp/slapd.pid argsfile /tmp/slapd.args
and now slapd is starting, i have to run 'slapd_db_recover' to get rid of warning.. ldbm_back_db_open: unclean shutdown detected; database may be inconsistent
Now only left with with 'WARNING: No dynamic config support for database ldbm' and I am not mode to mess with master and slave atm. :)
Okay its time to confirm if this slave is getting updates from master, any idea how to confirm this, and suppose i have to monitor (my using some bash script) this replication whether its in sync or not how should i accomplished this?
I greatly appreciate you guys help and support.
Thanks. Askar
On Friday, February 23, 2007 8:57 AM, Asrai khn wrote:
On 2/23/07, matthew sporleder msporleder@gmail.com wrote:
[...]
Migrate now or migrate later when ldbm is removed. BDB is faster and offers more backup/recovery features than ldbm.
yeah we have to decide fast, and look like all eyes on me now for making
this move :)
[...]
and now slapd is starting, i have to run 'slapd_db_recover' to get rid of
warning..
ldbm_back_db_open: unclean shutdown detected; database may be inconsistent
That message is provided only as an indicator that your back-ldbm database is likely to be corrupt, and I mean in a bad way. Running db_recover will NOT fix any inconsistencies in a back-ldbm database or perform any meaningful recovery. Notice that slapd didn't say it was attempting recovery. What cleared the warning was simply starting slapd and shutting it down properly. The database remains potentially corrupt. The only _certain_ way to recover from this is to reload the database from an ldif backup.
Cheers,
Matthew Hardin Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
matthew sporleder wrote:
On 2/23/07, Asrai khn asraikhn@gmail.com wrote:
So what you suggest, do we need to migrate to some other backend db or we can use the existing ldbm and ignoring the warning? (remember this is our primary ldap server for authenticating users for different services eg, company php application, wiki, phpmyadmin etc
Migrate now or migrate later when ldbm is removed. BDB is faster and offers more backup/recovery features than ldbm.
"when ldbm is removed" - that's a done deal, the code was removed from CVS HEAD April 8 2006. We *can* still make patches to the 2.3 branch, but the likelihood of that happening from here on out is about zero.
Migrate now or migrate later when ldbm is removed. BDB is faster and offers more backup/recovery features than ldbm.
"when ldbm is removed" - that's a done deal, the code was removed from CVS HEAD April 8 2006. We *can* still make patches to the 2.3 branch, but the likelihood of that happening from here on out is about zero.
Okay you people completely convinced me (my boss) me that ldbm->bdb is urgently required.
And posting related to migration from idbm To bdb will probably goes to another 'thread' :)
Thanks and greatly appreciated.
Askar
openldap-software@openldap.org
-
Asrai khn -
Howard Chu -
Luca Scamoni -
Matthew Hardin -
matthew sporleder -
zoticaic