https://bugs.openldap.org/show_bug.cgi?id=9652
Issue ID: 9652
Summary: Add "tee" capability to load balancer
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: lloadd
Assignee: bugs(a)openldap.org
Reporter: mhardin(a)symas.com
Target Milestone: ---
This is a request for an enhancement that would add a "tee" or "fan-out"
capability to load balancer, where received operations are sent to two or more
destinations simultaneously.
The primary goal or the enhancement is to make it possible to keep multiple
independent and likely dissimilar directory systems in lock-step with each
other over hours, days, or possibly even weeks.
The enhancement would not necessarily need to include a mechanism for
converging the target systems should they become out of sync.
This is not intended to be a replication solution, rather it is viewed more as
a "copy" solution intended to be used for specific short-term tasks that need
multiple directory systems to be exactly synchronized but where replication is
not desirable or even possible.
At least two uses come to mind:
1. Test harnesses, evaluating side-by-side operation of separate directory
systems over time
2. Directory system transition validation harnesses
3. (maybe) Part of a test harness to record or replay LDAP workloads
* Other uses?
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9667
Issue ID: 9667
Summary: 2.6 to 2.7 upgrade documentation
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: documentation
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Need to document any upgrade information for going from 2.6 to 2.7
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9398
Issue ID: 9398
Summary: Stale accesslog cookie due to unclean shutdown
Product: OpenLDAP
Version: 2.4.56
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
If slapd terminates uncleanly, a checkpoint will be lost on the accesslog db.
Depending on the syncprov overlay checkpoint settings (usually no checkpointing
is enabled on the accesslog db) this can cause the system to refuse engage in
replication at startup.
--
You are receiving this mail because:
You are on the CC list for the issue.
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=9186
Bug ID: 9186
Summary: RFE: More metrics in cn=monitor
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: michael(a)stroeder.com
Target Milestone: ---
Currently I'm grepping metrics from syslog with mtail:
https://gitlab.com/ae-dir/ansible-ae-dir-server/-/blob/master/templates/mta…
With a new binary logging this is not possible anymore.
Thus it would be nice if cn=monitor provides more metrics.
1. Overall connection count per listener starting at 0 when started. This would
be a simple counter added to:
entries cn=Listener 0,cn=Listeners,cn=Monitor
2. Counter for the various "deferring" messages separated by the reason for
deferring.
3. Counters for all possible result codes. In my mtail program I also label it
with the result type.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9796
Issue ID: 9796
Summary: Deprecate GnuTLS support
Product: OpenLDAP
Version: 2.6.1
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Support for GnuTLS was added specifically for the Debian (and thus Ubuntu) due
to the license objections at the time that the Debian project had for the
OpenSSL license.
Since that time, Debian has reclassified OpenSSL as a core library and the
OpenSSL project has resolved the original complaint by licensing OpenSSL 3 and
later under the Apache License v2.
Thus there is no longer a reason to maintain support for GnuTLS and given the
long standing concerns over the security and quality of the GnuTLS bridge in
addition to the extra cost of maintaining that code, it should be marked as
deprecated and removed in a future release.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9827
Issue ID: 9827
Summary: Feature request for module argon2.so to support
Argon2i, Argon2d, Argon2id
Product: OpenLDAP
Version: 2.6.1
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: juergen.sprenger(a)swisscom.com
Target Milestone: ---
Hi,
This is a feature request.
I would like to be able to chooses between Argon2i, Argon2d and Argon2id in
slappasswd like in argon2 command:
# argon2
Usage: argon2 [-h] salt [-i|-d|-id] [-t iterations] [-m log2(memory in KiB) |
-k memory in KiB] [-p parallelism] [-l hash length] [-e|-r] [-v (10|13)]
Password is read from stdin
Parameters:
salt The salt to use, at least 8 characters
-i Use Argon2i (this is the default)
-d Use Argon2d instead of Argon2i
-id Use Argon2id instead of Argon2i
-t N Sets the number of iterations to N (default = 3)
-m N Sets the memory usage of 2^N KiB (default 12)
-k N Sets the memory usage of N KiB (default 4096)
-p N Sets parallelism to N threads (default 1)
-l N Sets hash output length to N bytes (default 32)
-e Output only encoded hash
-r Output only the raw bytes of the hash
-v (10|13) Argon2 version (defaults to the most recent version,
currently 13)
-h Print argon2 usage
Example:
/usr/local/etc/openldap # /usr/sbin/slappasswd -h "{ARGON2}" -o
module-load="argon2.so i" -s secret
/usr/local/etc/openldap # /usr/sbin/slappasswd -h "{ARGON2}" -o
module-load="argon2.so d" -s secret
/usr/local/etc/openldap # /usr/sbin/slappasswd -h "{ARGON2}" -o
module-load="argon2.so id" -s secret
Best regards
Juergen Sprenger
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9921
Issue ID: 9921
Summary: Tautology in clients/tools/common.c:print_vlv()
Product: OpenLDAP
Version: 2.6.3
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: client tools
Assignee: bugs(a)openldap.org
Reporter: dpa-openldap(a)aegee.org
Target Milestone: ---
https://git.openldap.org/openldap/openldap/-/blob/master/clients/tools/comm…
contains:
tool_write_ldif( ldif ? LDIF_PUT_COMMENT : LDIF_PUT_VALUE,
ldif ? "vlvResult" : "vlvResult", buf, rc );
The second parameter is always vlvResult, irrespective of the value of ldif.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9378
Issue ID: 9378
Summary: Crash in mdb_put() / mdb_page_dirty()
Product: LMDB
Version: 0.9.26
Hardware: All
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: nate(a)kde.org
Target Milestone: ---
The KDE Baloo file indexer uses lmdb as its database (source code available at
https://invent.kde.org/frameworks/baloo). Our most common crash, with over 100
duplicate bug reports, is in lmdb. Here's the bug report tracking it:
https://bugs.kde.org/show_bug.cgi?id=389848.
The version of lmdb does not seem to matter much. We have bug reports from Arch
users with lmdb 0.9.26 as well as bug reports from people using many earlier
versions.
Here's an example backtrace, taken from
https://bugs.kde.org/show_bug.cgi?id=426195:
#6 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#7 0x00007f3c0bbb9859 in __GI_abort () at abort.c:79
#8 0x00007f3c0b23ba83 in mdb_assert_fail (env=0x55e2ad710600,
expr_txt=expr_txt@entry=0x7f3c0b23e02f "rc == 0",
func=func@entry=0x7f3c0b23e978 <__func__.7221> "mdb_page_dirty",
line=line@entry=2127, file=0x7f3c0b23e010 "mdb.c") at mdb.c:1542
#9 0x00007f3c0b2306d5 in mdb_page_dirty (mp=<optimized out>,
txn=0x55e2ad7109f0) at mdb.c:2114
#10 mdb_page_dirty (txn=0x55e2ad7109f0, mp=<optimized out>) at mdb.c:2114
#11 0x00007f3c0b231966 in mdb_page_alloc (num=num@entry=1,
mp=mp@entry=0x7f3c0727aee8, mc=<optimized out>) at mdb.c:2308
#12 0x00007f3c0b231ba3 in mdb_page_touch (mc=mc@entry=0x7f3c0727b420) at
mdb.c:2495
#13 0x00007f3c0b2337c7 in mdb_cursor_touch (mc=mc@entry=0x7f3c0727b420) at
mdb.c:6523
#14 0x00007f3c0b2368f9 in mdb_cursor_put (mc=mc@entry=0x7f3c0727b420,
key=key@entry=0x7f3c0727b810, data=data@entry=0x7f3c0727b820,
flags=flags@entry=0) at mdb.c:6657
#15 0x00007f3c0b23976b in mdb_put (txn=0x55e2ad7109f0, dbi=5,
key=key@entry=0x7f3c0727b810, data=data@entry=0x7f3c0727b820,
flags=flags@entry=0) at mdb.c:9022
#16 0x00007f3c0c7124c5 in Baloo::DocumentDB::put
(this=this@entry=0x7f3c0727b960, docId=<optimized out>,
docId@entry=27041423333263366, list=...) at ./src/engine/documentdb.cpp:79
#17 0x00007f3c0c743da7 in Baloo::WriteTransaction::replaceDocument
(this=0x55e2ad7ea340, doc=..., operations=operations@entry=...) at
./src/engine/writetransaction.cpp:232
#18 0x00007f3c0c736b16 in Baloo::Transaction::replaceDocument
(this=this@entry=0x7f3c0727bc10, doc=..., operations=operations@entry=...) at
./src/engine/transaction.cpp:295
#19 0x000055e2ac5d6cbc in Baloo::UnindexedFileIndexer::run
(this=0x55e2ad79ca20) at
/usr/include/x86_64-linux-gnu/qt5/QtCore/qrefcount.h:60
#20 0x00007f3c0c177f82 in QThreadPoolThread::run (this=0x55e2ad717f20) at
thread/qthreadpool.cpp:99
#21 0x00007f3c0c1749d2 in QThreadPrivate::start (arg=0x55e2ad717f20) at
thread/qthread_unix.cpp:361
#22 0x00007f3c0b29d609 in start_thread (arg=<optimized out>) at
pthread_create.c:477
#23 0x00007f3c0bcb6103 in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95
--
You are receiving this mail because:
You are on the CC list for the issue.