https://bugs.openldap.org/show_bug.cgi?id=9224
Bug ID: 9224
Summary: Add support for PREPARE/2-phase commit
Product: LMDB
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
In LMDB, add support for PREPARE/2-phase commits
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9363
Issue ID: 9363
Summary: removing olcReadOnly on a DB does not set it to FALSE
Product: OpenLDAP
Version: 2.4.53
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: maxime.besson(a)worteks.com
Target Milestone: ---
Created attachment 771
--> https://bugs.openldap.org/attachment.cgi?id=771&action=edit
ldif config that reproduces the issue
I am running the following test:
* add olcReadOnly: TRUE on a MDB database in cn=config
* Try to write to the MDB database => fails with "unwilling to perform" as
expected
* remove the olcReadOnly attribute from the MDB database
* Try to write to the MDB database => still fails with the same error
* Restart slapd
* Try to write to the MDB database => OK
However the following test works as expected:
* add olcReadOnly: TRUE on a MDB database in cn=config
* Try to write to the MDB database => fails with "unwilling to perform" as
expected
* modify olcReadOnly to FALSE on the MDB database
* Try to write to the MDB database => OK
It seems a little counter intuitive to me that removing a setting does not
reset it to its default value. The fact that a slapd restart make writing
possible again in the first test described above makes it seem to the casual
user that olcReadOnly cannot be undone without a restart at all.
Tested in 2.4.53 and 2.4.44, config attached but it probably works with any
config (hdb, etc)
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9512
Issue ID: 9512
Summary: Add ability to restrict by client ip address in ACLs
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Currently it is possible via ACLs to enforce restrictions based on which slapd
host interface is connected to via the peername parameter. However, it's not
possible to enforce ACL restrictions based on the IP address used by the
client. This would be a useful feature when wanting to restrict certain DNs to
only being able to have access if they connect from a certain IP or IP range.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9219
Bug ID: 9219
Summary: Streamline tool API for 2.5
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
The current tool API is a mess and needs fixing for 2.5. This affects things
like slapacl (The fix for bug#7920 was a kludge to deal with this, needs
revisiting).
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9557
Issue ID: 9557
Summary: syncrepl refreshonly sometimes finishes too early
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: replication
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
In a delta-MMR test environment where conflicts are intentionally introduced,
the fallback sessions sometimes cut off, not sending all entries they ought to.
Instead LDAP_SUCCESS is sent with the snapshot cookie at some point. That
cookie represents the correct contextCSN at the time of the search, so the
missing changes are skipped over forever.
As of now, the cause of the cutoff is under investigation. Currently, this was
only run with 2.5 + persistent sessionlog enabled but there are indications
this might not be limited to 2.5, tests with other versions/configs are
pending.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9551
Issue ID: 9551
Summary: dnSubtreeMatch and others do not handle empty DN as
asserted value
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
AFAIK '(reqDN:dnSubtreeMatch:=)' should be equivalent to 'reqDN=*', however it
only seems to match the empty dn right now.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9537
Issue ID: 9537
Summary: slap_timestamp() can give a duplicated timestamp
across restarts
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
On busy sites, when a slapd restart takes <1s, accesslog can fail to log
changes with LDAP_ALREADY_EXISTS. This is because slap_timestamp() only logs
timestamps with a 1s precision, disambiguating the rest with a counter that's
forgotten across restarts.
It is possible my analysis in ITS#9487 is partially invalidated because of
this.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9526
Issue ID: 9526
Summary: slapadd -w crashes
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: grapvar(a)gmail.com
Target Milestone: ---
Let slapd.conf is:
> database mdb
> suffix "o=Foo"
> sync_use_subentry
database is blank and we are adding this foo.ldif:
> dn: o=FOO
> objectClass:organization
Let's load:
> slapd -T add -v -l foo.ldif -w
then on Solaris:
> added: "o=FOO" (00000001)
> Segmentation Fault (core dumped)
... on Linux:
> added: "o=FOO" (00000001)
> => mdb_next_id: get failed: Invalid argument (22)
> => mdb_tool_next_id: next_id failed: Invalid argument (22)
> => mdb_tool_entry_put: txn_aborted! Invalid argument (22)
> slapadd: couldn't create context entry
> Closing DB...
This is because:
* mdb_tool_next_id() takes dead global [tools.c`static MDB_cursor *mcp] for
further operations
* cursor is dead because mdb_tool_entry_put() didn't initialized it
* mdb_tool_entry_put() didn't initialized cursor because it thinks it is
initialized, because there is an active global [tools.c`MDB_txn *mdb_tool_txn]
* transaction was initialized by mdb_tool_dn2id_get(), which doesn't care about
cursors.
Long story short: the global state in tools.c is not managed consistently and
needs rethinking.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9552
Issue ID: 9552
Summary: slapo-accesslog should record new DN after rename
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
To use accesslog as a sessionlog source, one needs to be able to resolve
whether a modrdn moved an entry in/out of the search scope. Syncprov would
either have to examine every modrdn request or, if accesslog were to log the
final DN, it could check for entries which crossed the scope.
A new attribute 'reqNewDN' should be tracked for modrdn ops.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9529
Issue ID: 9529
Summary: pcache locking issue
Product: OpenLDAP
Version: 2.4.58
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
Since ITS#6954 commit ea228495148 the consistency_check function was changed
to hold the template t_rwlock for the entire duration of a query expiration.
There doesn't appear to be any valid reason for this change, and it causes
the cache to be unresponsive to new searches while expiration is removing
cached entries.
--
You are receiving this mail because:
You are on the CC list for the issue.