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/2738a32de3a324fc56effd44c2fedaff1a359011/servers/slapd/back-mdb/modrdn.c#L442
Created attachment 973 [details] The test script as an attachment for easier usage.
*** This issue has been marked as a duplicate of issue 8461 ***
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?
(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.
(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.
(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.
(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.
(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.
(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.
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)
(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.
Needs further review
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 ***