On Sat, Dec 18, 2010 at 12:26 PM, Peter Lambrechtsen plambrechtsen@gmail.com wrote:
Or perhaps TinyLdap? http://www.fefe.de/tinyldap/
Also FreeRadius (if your app's support Radius and LDAP) supports a myriad of backend databases.
Hmm, very interesting. I was not aware of this project. My concern is that there's been very little activity on the project in recent years.
Is there no simple, reliable, backend config for openldap?
I'm not concerned with speed, just reliability and data integrity.
I'd settle for a 10x performance penalty for data integrity.
-Bruce
On Sun, Dec 19, 2010 at 5:59 AM, Bruce Edge bruce.edge@gmail.com wrote:
On Sat, Dec 18, 2010 at 12:19 AM, Peter Lambrechtsen plambrechtsen@gmail.com wrote:
Why don't you use SQLite instead??? It's pretty rock solid backend database.
Unless your client side only wants to talk LDAP.
Hi, Thanks the the response. One of the reasons for ldap is that it handles all the authentication for a lot of the packages we're using out of the box so it was a natural progression to extend it to handle the other data we need as well. The only probems, it appears, is how to make it more failsafe on the back end.
-Bruce
On Sat, Dec 18, 2010 at 6:48 AM, Bruce Edge bruce.edge@gmail.com wrote:
Perhaps a bit more detail... During testing our developers frequently hang the target machines. This usually results in a corrupted ldap database even though no write activity was present on the box since long before the crash.
What ldap config tuning options are required to get slapd to sync the backend to a state where power loss / kernel crashes do not corrupt the data?
Thanks
-Bruce
On Wed, Dec 15, 2010 at 10:25 AM, Bruce Edge bruce.edge@gmail.com wrote:
I'm working on an embedded system for which I would like to use openldap as the means of config storage. I've spent a lot of time RTFM'ing and still feel that there is a lot that is escaping me as far as the optimal configuration.
If the primary goal is data safety and zero human intervention, what would be the optimal combination of file system / backend storage / and config options?
I would like to never have to manually recover a database and have it gracefully recover from power failures. Speed is not an issue as it's very low traffic. Integritiy is everything. It's target storage is a USB flash device. Are there any special considerations WRT flash storage and ldap?
Thanks in advance.
-Bruce
Bruce Edge wrote:
On Sat, Dec 18, 2010 at 12:26 PM, Peter Lambrechtsen plambrechtsen@gmail.com wrote:
Or perhaps TinyLdap? http://www.fefe.de/tinyldap/
Also FreeRadius (if your app's support Radius and LDAP) supports a myriad of backend databases.
Hmm, very interesting. I was not aware of this project. My concern is that there's been very little activity on the project in recent years.
Is there no simple, reliable, backend config for openldap?
I'm not concerned with speed, just reliability and data integrity.
I'd settle for a 10x performance penalty for data integrity.
You could give back-ldif a try. It certainly will not perform well, but it's so simple that data corruption wouldn't be an issue.
-Bruce
On Sun, Dec 19, 2010 at 5:59 AM, Bruce Edgebruce.edge@gmail.com wrote:
On Sat, Dec 18, 2010 at 12:19 AM, Peter Lambrechtsen plambrechtsen@gmail.com wrote:
Why don't you use SQLite instead??? It's pretty rock solid backend database.
Unless your client side only wants to talk LDAP.
Hi, Thanks the the response. One of the reasons for ldap is that it handles all the authentication for a lot of the packages we're using out of the box so it was a natural progression to extend it to handle the other data we need as well. The only probems, it appears, is how to make it more failsafe on the back end.
-Bruce
On Sat, Dec 18, 2010 at 6:48 AM, Bruce Edgebruce.edge@gmail.com wrote:
Perhaps a bit more detail... During testing our developers frequently hang the target machines. This usually results in a corrupted ldap database even though no write activity was present on the box since long before the crash.
What ldap config tuning options are required to get slapd to sync the backend to a state where power loss / kernel crashes do not corrupt the data?
Thanks
-Bruce
On Wed, Dec 15, 2010 at 10:25 AM, Bruce Edgebruce.edge@gmail.com wrote:
I'm working on an embedded system for which I would like to use openldap as the means of config storage. I've spent a lot of time RTFM'ing and still feel that there is a lot that is escaping me as far as the optimal configuration.
If the primary goal is data safety and zero human intervention, what would be the optimal combination of file system / backend storage / and config options?
I would like to never have to manually recover a database and have it gracefully recover from power failures. Speed is not an issue as it's very low traffic. Integritiy is everything. It's target storage is a USB flash device. Are there any special considerations WRT flash storage and ldap?
Thanks in advance.
-Bruce
On Sat, Dec 18, 2010 at 4:04 PM, Howard Chu hyc@symas.com wrote:
Bruce Edge wrote:
On Sat, Dec 18, 2010 at 12:26 PM, Peter Lambrechtsen plambrechtsen@gmail.com wrote:
Or perhaps TinyLdap? http://www.fefe.de/tinyldap/
Also FreeRadius (if your app's support Radius and LDAP) supports a myriad of backend databases.
Hmm, very interesting. I was not aware of this project. My concern is that there's been very little activity on the project in recent years.
Is there no simple, reliable, backend config for openldap?
I'm not concerned with speed, just reliability and data integrity.
I'd settle for a 10x performance penalty for data integrity.
You could give back-ldif a try. It certainly will not perform well, but it's so simple that data corruption wouldn't be an issue.
I'll give it a try. Thanks.
Are there no hdb back end settings that accomplish something similar ? Or is that back end always going to be vulnerable to ungraceful shut downs?
Thanks
-Bruce
-Bruce
On Sun, Dec 19, 2010 at 5:59 AM, Bruce Edgebruce.edge@gmail.com wrote:
On Sat, Dec 18, 2010 at 12:19 AM, Peter Lambrechtsen plambrechtsen@gmail.com wrote:
Why don't you use SQLite instead??? It's pretty rock solid backend database.
Unless your client side only wants to talk LDAP.
Hi, Thanks the the response. One of the reasons for ldap is that it handles all the authentication for a lot of the packages we're using out of the box so it was a natural progression to extend it to handle the other data we need as well. The only probems, it appears, is how to make it more failsafe on the back end.
-Bruce
On Sat, Dec 18, 2010 at 6:48 AM, Bruce Edgebruce.edge@gmail.com wrote:
Perhaps a bit more detail... During testing our developers frequently hang the target machines. This usually results in a corrupted ldap database even though no write activity was present on the box since long before the crash.
What ldap config tuning options are required to get slapd to sync the backend to a state where power loss / kernel crashes do not corrupt the data?
Thanks
-Bruce
On Wed, Dec 15, 2010 at 10:25 AM, Bruce Edgebruce.edge@gmail.com wrote: > > I'm working on an embedded system for which I would like to use > openldap as the means of config storage. > I've spent a lot of time RTFM'ing and still feel that there is a lot > that is escaping me as far as the optimal configuration. > > If the primary goal is data safety and zero human intervention, what > would be the optimal combination of file system / backend storage / > and config options? > > I would like to never have to manually recover a database and have it > gracefully recover from power failures. Speed is not an issue as it's > very low traffic. Integritiy is everything. > It's target storage is a USB flash device. Are there any special > considerations WRT flash storage and ldap? > > Thanks in advance. > > -Bruce >
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Am Sun, 19 Dec 2010 08:02:02 -0800 schrieb Bruce Edge bruce.edge@gmail.com:
On Sat, Dec 18, 2010 at 4:04 PM, Howard Chu hyc@symas.com wrote:
Bruce Edge wrote:
On Sat, Dec 18, 2010 at 12:26 PM, Peter Lambrechtsen plambrechtsen@gmail.com wrote:
Or perhaps TinyLdap? http://www.fefe.de/tinyldap/
Also FreeRadius (if your app's support Radius and LDAP) supports a myriad of backend databases.
Hmm, very interesting. I was not aware of this project. My concern is that there's been very little activity on the project in recent years.
Is there no simple, reliable, backend config for openldap?
I'm not concerned with speed, just reliability and data integrity.
I'd settle for a 10x performance penalty for data integrity.
You could give back-ldif a try. It certainly will not perform well, but it's so simple that data corruption wouldn't be an issue.
I'll give it a try. Thanks.
Are there no hdb back end settings that accomplish something similar ? Or is that back end always going to be vulnerable to ungraceful shut downs?
slapd always runs db_recover on any bdb and hdb database, which will repair any corrupted database if appropriate transaction logs are available.
-Dieter
On Sun, Dec 19, 2010 at 9:12 AM, Dieter Kluenter dieter@dkluenter.de wrote:
Am Sun, 19 Dec 2010 08:02:02 -0800 schrieb Bruce Edge bruce.edge@gmail.com:
On Sat, Dec 18, 2010 at 4:04 PM, Howard Chu hyc@symas.com wrote:
Bruce Edge wrote:
On Sat, Dec 18, 2010 at 12:26 PM, Peter Lambrechtsen plambrechtsen@gmail.com wrote:
Or perhaps TinyLdap? http://www.fefe.de/tinyldap/
Also FreeRadius (if your app's support Radius and LDAP) supports a myriad of backend databases.
Hmm, very interesting. I was not aware of this project. My concern is that there's been very little activity on the project in recent years.
Is there no simple, reliable, backend config for openldap?
I'm not concerned with speed, just reliability and data integrity.
I'd settle for a 10x performance penalty for data integrity.
You could give back-ldif a try. It certainly will not perform well, but it's so simple that data corruption wouldn't be an issue.
I'll give it a try. Thanks.
Are there no hdb back end settings that accomplish something similar ? Or is that back end always going to be vulnerable to ungraceful shut downs?
slapd always runs db_recover on any bdb and hdb database, which will repair any corrupted database if appropriate transaction logs are available.
Could you direct me to the reference documentation on this feature? I'd like to read up on the specifics.
Are there any hdb configuration parameters which affect the speed/integrity tradeoff which would make the recovery procedure more reliable?
Thanks
-Bruce
-Dieter
-- Dieter Klünter | Systemberatung http://dkluenter.de GPG Key ID:DA147B05 53°37'09,95"N 10°08'02,42"E
Bruce Edge wrote:
On Sun, Dec 19, 2010 at 9:12 AM, Dieter Kluenterdieter@dkluenter.de wrote:
Am Sun, 19 Dec 2010 08:02:02 -0800 schrieb Bruce Edgebruce.edge@gmail.com:
On Sat, Dec 18, 2010 at 4:04 PM, Howard Chuhyc@symas.com wrote:
Bruce Edge wrote:
On Sat, Dec 18, 2010 at 12:26 PM, Peter Lambrechtsen plambrechtsen@gmail.com wrote:
Or perhaps TinyLdap? http://www.fefe.de/tinyldap/
Also FreeRadius (if your app's support Radius and LDAP) supports a myriad of backend databases.
Hmm, very interesting. I was not aware of this project. My concern is that there's been very little activity on the project in recent years.
Is there no simple, reliable, backend config for openldap?
I'm not concerned with speed, just reliability and data integrity.
I'd settle for a 10x performance penalty for data integrity.
You could give back-ldif a try. It certainly will not perform well, but it's so simple that data corruption wouldn't be an issue.
I'll give it a try. Thanks.
Are there no hdb back end settings that accomplish something similar ? Or is that back end always going to be vulnerable to ungraceful shut downs?
slapd always runs db_recover on any bdb and hdb database, which will repair any corrupted database if appropriate transaction logs are available.
Could you direct me to the reference documentation on this feature? I'd like to read up on the specifics.
Read the BerkeleyDB docs.
Are there any hdb configuration parameters which affect the speed/integrity tradeoff which would make the recovery procedure more reliable?
Yes, the checkpoint option documented in the slapd-bdb(5) manpage.
Howard Chu writes:
You could give back-ldif a try. It certainly will not perform well, but it's so simple that data corruption wouldn't be an issue.
Actually it can leave behind a temporary file if you pull the plug on slapd at just the wrong moment, when an entry is being written. That won't affect the entry, but the parent entry cannot be deleted when there are temporary files in its directory.
A fix would be: Before starting slapd, delete regular files without an '.ldif' suffix below the database directory. On Unix filesystems,
find '<database-directory>' -type f ! -name '*.ldif' -exec rm '{}' ;
On filesystem with case-insensitive, max 3 chars extensions etc, you'd have to take more care...
openldap-technical@openldap.org
-
Bruce Edge -
Dieter Kluenter -
Hallvard B Furuseth -
Howard Chu