https://bugs.openldap.org/show_bug.cgi?id=10021
Issue ID: 10021
Summary: Cannot insert data into wiredtiger backend
Product: OpenLDAP
Version: 2.6.4
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: jailbird(a)fdf.net
Target Milestone: ---
I have a test system running OpenLDAP 2.6.4 linked against WiredTiger 11.1.0
running on a RHEL9.1-based system. Running kernel is 6.1.16, filesystem is XFS.
back_wt.la was added to cn=module and a simple olcDatabase=wt was created like:
dn: olcDatabase=wt
objectClass: olcDatabaseConfig
objectClass: olcWtConfig
olcDatabase: wt
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=fdf,dc=net
olcLimits: {0}dn.base="cn=root,dc=fdf,dc=net" time.soft=unlimited time.hard=u
nlimited size.soft=unlimited size.hard=unlimited
olcRootDN: cn=root,dc=fdf,dc=net
olcWtConfig: create
olcDbIndex: objectClass,uid,gidNumber,uidNumber pres,eq
olcDbIndex: ou,cn,mail pres,eq,sub
structuralObjectClass: olcWtConfig
I start slapd and it creates the database files correctly. I then go and try to
create the container with a simple .ldif and ldapadd:
dn: dc=fdf,dc=net
objectClass: dcObject
objectClass: organization
o: FDF
dc: fdf
That generates:
[1677801597:758327][83158:0x55b4158fb640], file:dn2id.wt, WT_CURSOR.insert:
[WT_VERB_DEFAULT][ERROR]: __wt_txn_id_check, 1339: write operations are not
supported in read-committed or read-uncommitted transactions.: Operation not
supported
Mar 2 15:59:57 slapd[83158]: wt_dn2id_add: insert failed: Operation not
supported (95)
That comes from WiredTiger @
https://github.com/wiredtiger/wiredtiger/blob/5a032be765b1ebd9bb789e837cd00…
but I don't seem to understand why it's happening on a simple add? Am I missing
something obvious?
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9436
Issue ID: 9436
Summary: OpenSSL 3.0: libldap uses depreciated functions
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
OpenLDAP master fails to build against OpenSSL 3.0 alpha when "no-deprecated"
is specified.
Currently hitting these errors:
./.libs/libldap.so: undefined reference to `SSL_get_peer_certificate'
./.libs/libldap.so: undefined reference to `PEM_read_bio_DHparams'
./.libs/libldap.so: undefined reference to `ERR_get_error_line'
./.libs/libldap.so: undefined reference to `DH_free'
./.libs/libldap.so: undefined reference to `SSL_CTX_set_tmp_dh'
Notes:
SSL_get_peer_certificate is SSL_get1_peer_certificate in 3.0.0
SSL_CTX_set_tmp_dh should be replaced as follows:
# define SSL_CTX_set_tmp_dh(ctx,dh) \
SSL_CTX_ctrl(ctx,SSL_CTRL_SET_TMP_DH,0,(char *)(dh))
Have to dig deeper for:
PEM_read_bio_DHparams
ERR_get_error_line
DH_free
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9832
Issue ID: 9832
Summary: back-monitor crash when sizelimit in operation
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
If a back-monitor search gets a failure in send_search_entry(), e.g. due to
sizelimit being reached, a pending server pause, etc., it will try to call
monitor_cache_release( mi, e ) where e == NULL instead of the correct entry to
release.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10034
Issue ID: 10034
Summary: Assertion 'i < NUMKEYS(mp)' failed in
mdb_page_search_root()"
Product: LMDB
Version: 0.9.23
Hardware: Other
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: 763280032(a)qq.com
Target Milestone: ---
We found that when lmdb is opened after OS startup and data is written to it,
lmdb will trigger abort probabilistically(Restart the OS 600 times will trigger
once);
We want to know what situation triggers this issue(Assertion 'i < NUMKEYS(mp)'
failed in mdb_page_search_root()); we want to know if there is a problem with
our usage;
Please Help Us
(gdb) x/8s 0x8baee988
0x8baee988: "8\373Բ\b\371Բmdb.c:5542: Assertion 'i < NUMKEYS(mp)' failed in
mdb_page_search_root()"
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9460
Issue ID: 9460
Summary: Drop support for OpenSSL older than 1.1.1
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
OpenSSL no longer supports the 1.0.2 series and specifically notes it should
not be used:
"All older versions (including 1.1.0, 1.0.2, 1.0.0 and 0.9.8) are now out of
support and should not be used."
Currently configure checks for 1.0.2 or higher.
OpenSSL 1.1.1 is supported through 11 Sep 2023.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8977
Ondřej Kuzník <ondra(a)mistotebe.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://bugs.openldap.org/s
| |how_bug.cgi?id=10031
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10027
Issue ID: 10027
Summary: MDB_TXN_FULL on large write transactions
Product: LMDB
Version: unspecified
Hardware: All
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: renault.cle(a)gmail.com
Target Milestone: ---
Hello,
Our users ([1], [2]) encountered MDB_TXN_FULL errors when our Meilisearch
engine processed a large write transaction. We did read the documentation about
this error in the codebase of LMDB:
Spill pages from the dirty list back to disk.
This is intended to prevent running into #MDB_TXN_FULL situations,
but note that they may still occur in a few cases:
1) our estimate of the txn size could be too small. Currently this
seems unlikely, except with a large number of #MDB_MULTIPLE items.
2) child txns may run out of space if their parents dirtied a
lot of pages and never spilled them. TODO: we probably should do
a preemptive spill during #mdb_txn_begin() of a child txn, if
the parent's dirty_room is below a given threshold.
Otherwise, if not using nested txns, it is expected that apps will
not run into #MDB_TXN_FULL any more. The pages are flushed to disk
the same way as for a txn commit, e.g. their P_DIRTY flag is cleared.
If the txn never references them again, they can be left alone.
If the txn only reads them, they can be used without any fuss.
If the txn writes them again, they can be dirtied immediately without
going thru all of the work of #mdb_page_touch(). Such references are
handled by #mdb_page_unspill().
However, It looks like we are not in those scenarios, we are not using
MDB_DUPFIXED, and we are not using sub-transactions. We don't use the MDB_VL32
flag either, so this is not related to [3].
Thank you for your time,
Have a nice day 💡
[1]: https://github.com/meilisearch/meilisearch/issues/3603
[2]: https://github.com/meilisearch/meilisearch/issues/3349
[3]: https://bugs.openldap.org/show_bug.cgi?id=8813
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10029
Issue ID: 10029
Summary: slapd crashes when run with unlimited open files
Product: OpenLDAP
Version: 2.6.4
Hardware: All
OS: Mac OS
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: gray(a)nxg.name
Target Milestone: ---
To reproduce:
% ulimit -n
unlimited
% $T/openldap-2.6.4/libexec/slapd -d-1
641ee8bc.32f05820 0x1dc760140 @(#) $OpenLDAP: slapd 2.6.4 (Mar 25 2023
12:25:49) $
openldap
641ee8bc.32f39ff8 0x1dc760140 daemon_init: <null>
641ee8bc.32f40588 0x1dc760140 daemon: SLAP_SOCK_INIT: dtblsize=-1
641ee8bc.32f43080 0x1dc760140 ch_calloc of 1 elems of 18446744073709551615
bytes failed
Assertion failed: (0), function ch_calloc, file ch_malloc.c, line 107.
zsh: abort $T/openldap-2.6.4/libexec/slapd -d-1
This is because `daemon.c` (line 1867) uses the maximum number of open files to
set `dtblsize`, which is subsequently used to size an array:
1867 #ifdef HAVE_SYSCONF
1868 dtblsize = sysconf( _SC_OPEN_MAX );
1869 #elif defined(HAVE_GETDTABLESIZE)
1870 dtblsize = getdtablesize();
1871 #else /* ! HAVE_SYSCONF && ! HAVE_GETDTABLESIZE */
1872 dtblsize = FD_SETSIZE;
1873 #endif /* ! HAVE_SYSCONF && ! HAVE_GETDTABLESIZE */
If the maximum number of FDs is unlimited, then sysconf(_SC_OPEN_MAX) returns
-1, and the program crashes when it tries to malloc that much memory.
I've marked this as OS=macOS because that's what I'm illustrating this on, but
the same thing would happen on any OS where the sysconf call returns a negative
number for the 'unlimited' case.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10022
Issue ID: 10022
Summary: OlcAccess (META)
Product: OpenLDAP
Version: 2.5.7
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: bourguijl(a)gmail.com
Target Milestone: ---
Dears,
I've configured a META ldap instance pointing to a LDAP backend.
In this backend, there are a few ACLs but which ones don't restrict ldapsearch
that I perform from the META frontend.
I just have an issue when I set some ACLs on the META frontend and more
specially when I insert attrs=xxx in the ACL.
ACL = OK
{0}to dn.one="ou=staff,o=mobistar.be" by
dn="uid=a0621004,ou=ObeExternalITOnGcp,ou=partners,o=mobistar.be" read
ACL NOT OK
{0}to dn.one="ou=staff,o=mobistar.be" attrs=uid by
dn="uid=a0621004,ou=ObeExternalITOnGcp,ou=partners,o=mobistar.be" read
Can you explain why when I restrict to an attribute, my ldapsearch didn't
provide me any response as expected ?
Is it a bug ?
Thx in advance,
J-L.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10024
Issue ID: 10024
Summary: MDB_PREVSNAPSHOT broken
Product: LMDB
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: markus(a)objectbox.io
Target Milestone: ---
It seems that the patch #9496 had a negative side effect on MDB_PREVSNAPSHOT.
In certain cases, when opening the DB using MDB_PREVSNAPSHOT, the previous (2nd
latest) commit is not selected. Instead, reads show that the latest commit was
selected voiding the effect of MDB_PREVSNAPSHOT.
I observed this in our test cases a while back. Today, I was finally able to
reproduce it and debug into it.
When creating the transaction to read the data, I debugged into mdb_txn_renew0.
Here, ti (MDB_txninfo; env->me_txns) was non-NULL. However, ti->mti_txnid was 0
(!) and thus txn->mt_txnid was set to 0. That's the reason for always selecting
the first (index 0) meta page inside mdb_txn_renew0:
meta = env->me_metas[txn->mt_txnid & 1];
This line occurs twice (once for read txn and once for write txn; it affects
both txn types).
Thus, the chances of MDB_PREVSNAPSHOT selecting the correct meta page is 50-50.
It's only correct if the first meta page (index 0) is the older one.
I believe that this is related to #9496 because the patch, that was provided
there, removed the initialization of "env->me_txns->mti_txnid" in
mdb_env_open2. This would explain why txn->mt_txnid inside mdb_txn_renew0 was
set to 0.
I can confirm that adding back the following two lines back in fixes
MDB_PREVSNAPSHOT:
if (env->me_txns)
env->me_txns->mti_txnid = meta.mm_txnid;
The said patch including the removal of these two lines was applied in the
commit(s) "ITS#9496 fix mdb_env_open bug from #8704" (Howard Chu on 09.04.21).
I hope this information is useful to find a suitable fix. Please let me know if
you have questions. Also, I'd be happy to help confirming a potential fix with
our test suite.
--
You are receiving this mail because:
You are on the CC list for the issue.