https://bugs.openldap.org/show_bug.cgi?id=10104
Issue ID: 10104
Summary: Add alias overlay to contrib
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: contrib
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10103
Issue ID: 10103
Summary: Contrib OIDs inconsistent
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: contrib
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
When the latest batch of contrib overlays were added, the OIDs list wasn't
updated and OIDs inside the code populated properly.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10044
Issue ID: 10044
Summary: dynlist sometimes crashes when a search operation is
abandoned
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: ---
Playing with the DB provided in ITS#10041 on master, interrupting the
ldapsearch sometimes leads to a slapd crash. It's not 100% repeatable and the
debugger shows dynlist_search2resp touching memory freed by
dynlist_search_cleanup already, which doesn't make sense. Might be something
else is happening at the same time.
--
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=10084
Issue ID: 10084
Summary: Move away from DIGEST-MD5 as a default in the test
suite
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: test suite
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
cyrus-sasl seem on the verge or removing the DIGEST-MD5 mechanism from 2.2
onwards. As such we should update our defaults in a couple of our test scripts
for master/2.7 at least. Are SCRAM mechanisms the go-to these days?
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10082
Issue ID: 10082
Summary: More dynlist eval tweaks
Product: OpenLDAP
Version: 2.5.14
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
When the memberOf attribute is a user attribute instead of operational, it will
be expanded on any search for (all user attributes). If the search is filtering
on objectclasses that don't contain this attribute, that's wasted work. Check
for a matching objectclass in the filter before doing that.
--
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.
https://bugs.openldap.org/show_bug.cgi?id=9193
Bug ID: 9193
Summary: HTML in mailing list description
Product: website
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: website
Assignee: bugs(a)openldap.org
Reporter: ryan(a)openldap.org
Target Milestone: ---
e.g. https://lists.openldap.org/postorius/lists/openldap-devel.openldap.org/
contains code for links and formatting, but all inside of a <pre> block.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=10136
Issue ID: 10136
Summary: Sync replication causing glue entries.
Product: OpenLDAP
Version: 2.5.13
Hardware: x86_64
OS: Windows
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: mbalakri(a)opentext.com
Target Milestone: ---
Created attachment 991
--> https://bugs.openldap.org/attachment.cgi?id=991&action=edit
Node1 and Nod2 sync replication logs
We have configured mirror mode replication with two nodes.
Node1 syncrepl
{0}rid=1 provider=ldaps://AWPCISQL22.otxlab.net:6366 type=refreshAndPersist
searchbase="o=otxlab.net" schemachecking=off bindmethod=simple
binddn="cn=Directory Manager,o=otxlab.net" credentials=d retry="120 10 300 +"
timeout=60 tls_reqcert=never tls_cacert="C:\Program
Files\OpenText\CARS\defaultInst\certificates\AWPCISQL22.otxlab.net-cert.cer"
tls_cert="C:\Program
Files\OpenText\CARS\defaultInst\certificates\AWPCISQL22.otxlab.net-cert.cer"
tls_key="C:\Program
Files\OpenText\CARS\defaultInst\certificates\AWPCISQL22.otxlab.net-key.pvk"
Node2 syncrepl
{0}rid=2 provider=ldaps://AWPCTHA1.otxlab.net:6366 type=refreshAndPersist
searchbase="o=otxlab.net" schemachecking=off bindmethod=simple
binddn="cn=Directory Manager,o=otxlab.net" credentials=d retry="120 10 300 +"
timeout=60 tls_reqcert=never tls_cacert="C:\Program
Files\OpenText\CARS\defaultInst\certificates\AWPCTHA1.otxlab.net-cert.cer"
tls_cert="C:\Program
Files\OpenText\CARS\defaultInst\certificates\AWPCTHA1.otxlab.net-cert.cer"
tls_key="C:\Program
Files\OpenText\CARS\defaultInst\certificates\AWPCTHA1.otxlab.net-key.pvk"
olcMultiProvider is ON.
Now when records are inserted into node1, it is replicating to node2 but after
sometime glue entries are created in node2 and from then onwards replication is
not working. Attached the sync logs from both the nodes. The below two entries
are in glue state and not recovering from this state.
cn=Method Set CAPackage,cn=Cordys
CAPConnector,cn=cordys,cn=defaultInst,o=otxlab.net
cn=Cordys CAPConnector,cn=cordys,cn=defaultInst,o=otxlab.net
Any clue on what is going wrong here? Is this due to the 'retry' configuration?
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10100
Issue ID: 10100
Summary: Non-sequential timestamps being logged on Windows
Product: OpenLDAP
Version: 2.6.6
Hardware: x86_64
OS: Windows
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: smckinney(a)symas.com
Target Milestone: ---
Presents as a dsync during replication. Consumer will log
```
650af021.2eadd901 0000000000001b40 slap_queue_csn: queueing 0000000002ac1620
20230920131409.992477Z#000000#001#000000
650af021.2eaed239 0000000000001b40 slap_graduate_commit_csn: removing
0000000002ac1620 20230920131409.992477Z#000000#001#000000
650af021.317b2a35 000000000000185c do_syncrep2: rid=102 CSN too old, ignoring
20230920131409.040136Z#000000#001#000000
(uid=slapd-test1-FOO1-6,ou=People,dc=example,dc=com)
```
The entry was not be added.
The provider will log messages using non-sequential timestamps. For example,
when grepping the CSN from above (in provider log):
```
# This:
650af021.3b3060d9 0000000000001ad8 conn=1001 op=1 syncprov_sendresp: to=002,
cookie=rid=102,sid=001,csn=20230920131409.992477Z#000000#001#000000
# and:
650af021.02648749 0000000000001810 slap_get_csn: conn=1003 op=7 generated new
csn=20230920131409.040136Z#000000#001#000000 manage=1
```
--
You are receiving this mail because:
You are on the CC list for the issue.