Hello List,
what settings do i need to write my ldap changes (almost) immedialtely to disk? I do not need much of performance but would rather have a higher security.
Thanks, Mario
ml@bortal.de wrote:
Hello List,
what settings do i need to write my ldap changes (almost) immedialtely to disk? I do not need much of performance but would rather have a higher security.
That is the default behavior for slapd, no other settings are needed.
Hi,
Howard Chu schrieb:
ml@bortal.de wrote:
Hello List,
what settings do i need to write my ldap changes (almost) immedialtely to disk? I do not need much of performance but would rather have a higher security.
That is the default behavior for slapd, no other settings are needed.
In my case i add a samba user to my ldap DB, then after 15 seconds i reset that box by pressing the reset button. After the box has rebootet the added user is not there anymore.
So i am not quite sure if its really writing to disk streight away.
Thanks, Mario
On 18/02/2008, ml@bortal.de ml@bortal.de wrote:
Hi,
Howard Chu schrieb:
ml@bortal.de wrote:
Hello List,
what settings do i need to write my ldap changes (almost) immedialtely to disk? I do not need much of performance but would rather have a higher security.
That is the default behavior for slapd, no other settings are needed.
In my case i add a samba user to my ldap DB, then after 15 seconds i reset that box by pressing the reset button. After the box has rebootet the added user is not there anymore.
So i am not quite sure if its really writing to disk streight away.
Maybe this will guide you towards some answers:
man sync (and more under "info sync")
A small utility that "exercises the sync system call".
Regards, Michal
Thanks, Mario
Hello,
ml@bortal.de wrote:
In my case i add a samba user to my ldap DB, then after 15 seconds i reset that box by pressing the reset button. After the box has rebootet the added user is not there anymore.
So i am not quite sure if its really writing to disk streight away.
I think you are barking up the wrong tree: Could it be that your operating system hasn't committed ('sync'ed) it's filesystem write cache?
Maybe you can instruct BDB to sync after each change, or you can instruct your operating system not to cache writes on that particular file system.
bye Christian
Is this more of an OS issue versus an OpenLDAP issue? Since OpenLDAP does not have raw access to the physical disk, it depends on the OS to flush it's buffers, so hitting reset on a system like that may cause things to get lost in the cache/buffer for the file system??
Sellers
On Feb 18, 2008, at 2:37 AM, ml@bortal.de wrote:
Hi,
Howard Chu schrieb:
ml@bortal.de wrote:
Hello List,
what settings do i need to write my ldap changes (almost) immedialtely to disk? I do not need much of performance but would rather have a higher security.
That is the default behavior for slapd, no other settings are needed.
In my case i add a samba user to my ldap DB, then after 15 seconds i reset that box by pressing the reset button. After the box has rebootet the added user is not there anymore.
So i am not quite sure if its really writing to disk streight away.
Thanks, Mario
______________________________________________ Chris G. Sellers | NITLE - Technology Team 734.661.2318 | chris.sellers@nitle.org AIM: imthewherd | GoogleTalk: cgseller@gmail.com
Chris G. Sellers wrote:
Is this more of an OS issue versus an OpenLDAP issue? Since OpenLDAP does not have raw access to the physical disk, it depends on the OS to flush it's buffers, so hitting reset on a system like that may cause things to get lost in the cache/buffer for the file system??
Possibly. The original poster didn't mention what version of OpenLDAP or what backend he's using. No guarantees with back-ldbm. With back-bdb and default settings, the transaction log is written synchronously and flushed after each write. With OpenLDAP 2.3 and newer, the auto-recovery on startup will replay the transaction log, so anything that didn't make it back into the database files originally will be recovered. Of course, synchronous writes of the transaction log still may get lost if the hard drive caches the writes but reports that they completed successfully.
Sellers
On Feb 18, 2008, at 2:37 AM, ml@bortal.de mailto:ml@bortal.de wrote:
Hi,
Howard Chu schrieb:
ml@bortal.de mailto:ml@bortal.de wrote:
Hello List,
what settings do i need to write my ldap changes (almost) immedialtely to disk? I do not need much of performance but would rather have a higher security.
That is the default behavior for slapd, no other settings are needed.
In my case i add a samba user to my ldap DB, then after 15 seconds i reset that box by pressing the reset button. After the box has rebootet the added user is not there anymore.
So i am not quite sure if its really writing to disk streight away.
Thanks, Mario
Chris G. Sellers | NITLE - Technology Team 734.661.2318 | chris.sellers@nitle.org mailto:chris.sellers@nitle.org AIM: imthewherd | GoogleTalk: cgseller@gmail.com mailto:cgseller@gmail.com
On Mon, 18 Feb 2008, Chris G. Sellers wrote:
Is this more of an OS issue versus an OpenLDAP issue? Since OpenLDAP does not have raw access to the physical disk, it depends on the OS to flush it's buffers, so hitting reset on a system like that may cause things to get lost in the cache/buffer for the file system??
That's what the fsync() and fdatasync() system calls are for. The Berkeley DB library uses them in the transaction-commit operation to tell the OS that the transaction log data should be forced to permanent storage so that durability is guaranteed. That can be disabled in the DB library using lines in the DB_CONFIG file: set_flags DB_TXN_NOSYNC or set_flags DB_TXN_WRITE_NOSYNC
or the "dbnosync" option in the slapd.conf, which sets the DB_TXN_NOSYNC flag.
If none of those is present, then the problem is the OS or hardware. IIRC, many UNIX variants don't *really* guarantee flushing permanent storage unless you disable the disk's write-cache...and even then, some hardware lies...
Philip Guenther
On Tuesday 19 February 2008 00:55:41 Philip Guenther wrote:
If none of those is present, then the problem is the OS or hardware. IIRC, many UNIX variants don't *really* guarantee flushing permanent storage unless you disable the disk's write-cache...and even then, some hardware lies...
Or, the transactions in the transaction log not being replayed, as is the case with <= 2.2 with no db_recover run before slapd starts.
Regards, Buchan
On Monday 18 February 2008 09:37:11 ml@bortal.de wrote:
Hi,
Howard Chu schrieb:
ml@bortal.de wrote:
Hello List,
what settings do i need to write my ldap changes (almost) immedialtely to disk? I do not need much of performance but would rather have a higher security.
That is the default behavior for slapd, no other settings are needed.
In my case i add a samba user to my ldap DB, then after 15 seconds i reset that box by pressing the reset button. After the box has rebootet the added user is not there anymore.
If you are using ldbm, there are no guarantees of anything. If you are using bdb on OpenLDAP 2.2 and you don't run database recovery after a reboot (or unclean shutdown of slapd) and before starting slapd, you could lose some data (as slapd in 2.2 doesn't do automatic database recovery, the operations in the transaction logs could be lost). The fix for this is to ensure the init script runs database recovery before starting slapd, or upgrading to 2.3.
But, this is why it would have been useful if you provided at least *some* information on what version your are using, and what backend.
Regards, Buchan
openldap-software@openldap.org
-
Buchan Milne -
Chris G. Sellers -
Christian Marg -
Howard Chu -
Michal Dobroczynski -
ml＠bortal.de -
Philip Guenther