https://bugs.openldap.org/show_bug.cgi?id=10088
Issue ID: 10088 Summary: "DN index add failed" when renaming an entry Product: OpenLDAP Version: 2.5.13 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs@openldap.org Reporter: git@zifbang.com Target Milestone: ---
I recently updated a Docker image to the latest Debian release, which means I got a new OpenLDAP version: 2.5.13 (not sure what it was before, but definitely <=2.4.x). The old image's backend was HDB. That disappeared, so I made changes(1) to use the default MDB store. Today I found out that one of my tests is failing against this new image with a "DN index add failed" message. I traced the message down to (2), but I don't understand what is causing the message to be generated and cannot find any documentation on the function that returned the error.
Basically, the test is renaming an entry to a very long name. This script shows the error:
```sh #!/usr/bin/env bash
set -e
function cleanup() { echo "Stopping server..." docker stop ldap-test 2>&1 1>/dev/null } trap cleanup EXIT
echo "Starting server..." docker run --rm -d \ -p 1389:389 -p 1636:636 \ --name ldap-test \ ghcr.io/ldapjs/docker-test-openldap/openldap:2023-07-25 2>&1 1>/dev/null
echo "Waiting for server to start..." sleep 3
echo "Renaming entry..." docker exec ldap-test \ ldapmodrdn -x -H ldapi:/// \ -D 'cn=admin,dc=planetexpress,dc=com' \ -w 'GoodNewsEveryone' \ -v -d 2 \ 'cn=Turanga Leela,ou=people,dc=planetexpress,dc=com' \
'cn=a292979f2c86d513d48bbb9786b564b3c5228146e5ba46f404724e322544a7304a2b1049168803a5485e2d57a544c6a0d860af91330acb77e5907a9e601ad1227e80e0dc50abe963b47a004f2c90f570450d0e920d15436fdc771e3bdac0487a9735473ed3a79361d1778d7e53a7fb0e5f01f97a75ef05837d1d5496fc86968ff47fcb64' ```
What changes do I need to make in order to solve this error? I have tried applying the following ldif to my image creation, but it does not solve the problem:
```ldif dn: cn=config changetype: modify
replace: oldIndexHash64 olcIndexHash64: TRUE ```
1: https://github.com/ldapjs/docker-test-openldap/pull/3/files 2: https://git.openldap.org/openldap/openldap/-/blob/2738a32de3a324fc56effd44c2...
https://bugs.openldap.org/show_bug.cgi?id=10088
--- Comment #1 from git@zifbang.com --- Created attachment 973 --> https://bugs.openldap.org/attachment.cgi?id=973&action=edit The test script as an attachment for easier usage.
https://bugs.openldap.org/show_bug.cgi?id=10088
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED
--- Comment #2 from Quanah Gibson-Mount quanah@openldap.org ---
*** This issue has been marked as a duplicate of issue 8461 ***
https://bugs.openldap.org/show_bug.cgi?id=10088
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED Keywords|needs_review |
https://bugs.openldap.org/show_bug.cgi?id=10088
--- Comment #3 from git@zifbang.com --- I suppose that the closure of this issue without any response means that the solution is to figure out how to revert back to HDB?
https://bugs.openldap.org/show_bug.cgi?id=10088
--- Comment #4 from Quanah Gibson-Mount quanah@openldap.org --- (In reply to git from comment #3)
I suppose that the closure of this issue without any response means that the solution is to figure out how to revert back to HDB?
It was marked as a duplicate of an existing issue since that's what it is. See that ITS for further details.
https://bugs.openldap.org/show_bug.cgi?id=10088
--- Comment #5 from Quanah Gibson-Mount quanah@openldap.org --- (In reply to Quanah Gibson-Mount from comment #4)
(In reply to git from comment #3)
I suppose that the closure of this issue without any response means that the solution is to figure out how to revert back to HDB?
It was marked as a duplicate of an existing issue since that's what it is. See that ITS for further details.
As a side note, back-bdb/hdb no longer exist in any release past 2.4. I'd suggest not making absurdly long name values.
https://bugs.openldap.org/show_bug.cgi?id=10088
--- Comment #6 from git@zifbang.com --- (In reply to Quanah Gibson-Mount from comment #4)
(In reply to git from comment #3)
I suppose that the closure of this issue without any response means that the solution is to figure out how to revert back to HDB?
It was marked as a duplicate of an existing issue since that's what it is. See that ITS for further details.
That issue does not detail the same error, and none of my questions were addressed in it.
https://bugs.openldap.org/show_bug.cgi?id=10088
--- Comment #7 from git@zifbang.com --- (In reply to Quanah Gibson-Mount from comment #5)
(In reply to Quanah Gibson-Mount from comment #4)
(In reply to git from comment #3)
I suppose that the closure of this issue without any response means that the solution is to figure out how to revert back to HDB?
It was marked as a duplicate of an existing issue since that's what it is. See that ITS for further details.
As a side note, back-bdb/hdb no longer exist in any release past 2.4. I'd suggest not making absurdly long name values.
I don't get to make that decision. First, the test is to prove that `ldapjs` has no problem with such long attribute names (https://github.com/ldapjs/node-ldapjs/issues/480). Second, the spec does not impose any limit on attribute names (https://www.rfc-editor.org/rfc/rfc4514).
Given that this worked in prior versions, and does not in recent versions, it is clearly a regression that should be addressed.
https://bugs.openldap.org/show_bug.cgi?id=10088
--- Comment #8 from Quanah Gibson-Mount quanah@openldap.org --- (In reply to git from comment #6)
(In reply to Quanah Gibson-Mount from comment #4)
(In reply to git from comment #3)
I suppose that the closure of this issue without any response means that the solution is to figure out how to revert back to HDB?
It was marked as a duplicate of an existing issue since that's what it is. See that ITS for further details.
That issue does not detail the same error, and none of my questions were addressed in it.
That's because it was hit via different paths. In the case I filed, it was using slapadd when slapd is offline. In your case, it was via a modrdn operation on a live server. The underlying problem is the same however.
https://bugs.openldap.org/show_bug.cgi?id=10088
--- Comment #9 from Quanah Gibson-Mount quanah@openldap.org --- (In reply to git from comment #7)
Given that this worked in prior versions, and does not in recent versions, it is clearly a regression that should be addressed.
No one disputes it is a regression. It is scheduled to be addressed in OpenLDAP 2.7.
https://bugs.openldap.org/show_bug.cgi?id=10088
--- Comment #10 from Quanah Gibson-Mount quanah@openldap.org --- If you read issue 8461 as I suggested, it clearly notes that the issue is related to the length of the value being over 512 characters. If you change the cn value to be fewer than 512 characters, it should work.
This comes from the following hard coded limit in LMDB 0.9:
mdb.c:#define MDB_MAXKEYSIZE ((MDB_DEVEL) ? 0 : 511)
https://bugs.openldap.org/show_bug.cgi?id=10088
--- Comment #11 from git@zifbang.com --- (In reply to Quanah Gibson-Mount from comment #10)
If you read issue 8461 as I suggested, it clearly notes that the issue is related to the length of the value being over 512 characters. If you change the cn value to be fewer than 512 characters, it should work.
This comes from the following hard coded limit in LMDB 0.9:
mdb.c:#define MDB_MAXKEYSIZE ((MDB_DEVEL) ? 0 : 511)
The full DN string is 301 characters:
``` cn=a292979f2c86d513d48bbb9786b564b3c5228146e5ba46f404724e322544a7304a2b1049168803a5485e2d57a544c6a0d860af91330acb77e5907a9e601ad1227e80e0dc50abe963b47a004f2c90f570450d0e920d15436fdc771e3bdac0487a9735473ed3a79361d1778d7e53a7fb0e5f01f97a75ef05837d1d5496fc86968ff47fcb64,ou=people,dc=planetexpress,dc=com ```
The CN value string is 264 characters. You can verify this is true by inspecting the data in the original content of this issue. So I'm confused how this is the same issue if the issue is supposed to be triggered by attribute values exceeding 512 characters in length.
https://bugs.openldap.org/show_bug.cgi?id=10088
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|DUPLICATE |--- Status|VERIFIED |UNCONFIRMED Keywords| |needs_review
--- Comment #12 from Quanah Gibson-Mount quanah@openldap.org --- Needs further review
https://bugs.openldap.org/show_bug.cgi?id=10088
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE Keywords|needs_review |
--- Comment #13 from Quanah Gibson-Mount quanah@openldap.org --- This is a duplicate of 8461 as I initially marked it.
The limit for an RDN with a normalizer is half of the usual 511 byte limit.
*** This issue has been marked as a duplicate of issue 8461 ***
https://bugs.openldap.org/show_bug.cgi?id=10088
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED
-
openldap-its＠openldap.org