https://bugs.openldap.org/show_bug.cgi?id=9225
Bug ID: 9225
Summary: back-mdb: Add support for PREPARE/2-phase commit
Product: OpenLDAP
Version: 2.4.50
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Add support for PREPARE/2-phase commit in back-mdb
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=10286
Issue ID: 10286
Summary: ldap_pvt_gettime may result in "not new enough csn"
problems in multi-thread case.
Product: OpenLDAP
Version: 2.6.6
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: 971748261(a)qq.com
Target Milestone: ---
Created attachment 1041
--> https://bugs.openldap.org/attachment.cgi?id=1041&action=edit
the log of adding two entry which shows the time sequence.
I used openldap as krb5's database, and openldap was deploymented in
mirrormode.
I tried to add kerberos principals via kadmin.local -q "addprinc -randkey
principal.
slapd log showed that the entry of kadmin/admin was added earlier than the
entry of ossuser. But the csn of kadmin/admin was greater than ossuser.
In this case, when the two entry began to sync to the other slapd server,
ossuser was ignored because of "csn not new enough"
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8673
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |VERIFIED
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8070
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |VERIFIED
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10268
Issue ID: 10268
Summary: Operation rate limiting
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: chris.paul(a)rexconsulting.net
Target Milestone: ---
Please consider this request for enhancement. It would be very useful for slapd
to have some basic rate limiting per connection or per IP. The
monitorConnectionsOpsCompleted counts are available in cn=monitor. A dependency
of cn=monitor seems reasonable.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8943
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |VERIFIED
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10365
Issue ID: 10365
Summary: OOM during replication with a lot of updates
Product: OpenLDAP
Version: 2.6.10
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: elecharny(a)apache.org
Target Milestone: ---
When applying millions of updates on a huge database (30M entries), the server
can crash with an out of memory.
What happens is that the replication client does not process the incoming
updates fast enough, syncprov accumulate the changes in memory up to the point
it crashes.
The clear workaround: use more memory on the server.
Context: the replication mode used is delta-syncrepl, 2 servers, MMR , with MDB
and accesslog.
My assumption is that it would be valuable to benefit from the fact that we
know when the socket is ready for write to actually push data to the replica,
which means we can use the changes stored in accesslog and not in memory, while
keeping a state of replication. I assume it's a huge change in the way it
currently works.
There is no urgency, considering it's quite a specific use case, and it would
be way faster to slapmodify the changes on a stopped base, then copy the
content to the replica, then restart everything.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9767
Issue ID: 9767
Summary: slapo-unique handling of deletion of multi-valued
configuration attributes removes wrong value from list
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
If olcUniqueIgnore/olcUniqueAttribute is passed multiple names in a single
value that is later removed, the overlay doesn't handle its removal correctly.
We should encourage users to provide a single attribute name per value, just
like we do in EMIT for those provided in slapd.conf.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9768
Issue ID: 9768
Summary: slapo-translucent handling of deletion of multi-valued
configuration attributes removes wrong value from list
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
If olcTranslucentLocal/olcTranslucentRemote is passed multiple attribute names
in a single value that (or one further down the list) is later removed, the
overlay doesn't handle its removal correctly. We should encourage users to
provide a single attribute name per value, just like we do in EMIT for those
provided in slapd.conf.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10013
Issue ID: 10013
Summary: Some code (ppolicy, etc.) ignores
REP_CTRLS_MUSTBEFREED when touching rs->sr_ctrls
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
Certain parts of the source indicate that rs->sr_ctrls shouldn't be
realloc'd/free'd unless REP_CTRLS_MUSTBEFREED is set, but then other parts of
slapd (slap_ctrl_whatFailed_add, glue_op_search?, ...) and overlays (ppolicy,
syncprov, ...) will blindly overwrite and/or realloc it.
slap_add_control() (an analog of slap_add_controls()) might be useful for this,
possibly alongside some way to free the other data kept around to streamline
the code other users need for correct operation.
--
You are receiving this mail because:
You are on the CC list for the issue.