https://bugs.openldap.org/show_bug.cgi?id=10417
Issue ID: 10417
Summary: Objects not receivable anymore after schema attribute
name /alias change
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: best(a)univention.de
Target Milestone: ---
Created attachment 1100
--> https://bugs.openldap.org/attachment.cgi?id=1100&action=edit
ITS10417.txt
We have objects in the directory which cannot be received anymore after we
change the schema.
The objects are returned in a search but using the DN as search base yields NO
SUCH OBJECT error code.
The schema change:
Add another NAME for the existing attribute and put it into the first
(canonical) position.
The attribute is used as RDN component for objects.
Schema change as (unified) diff:
```diff
-attributetype ( 1.3.6.1.4.1.10176.4221.1.10 NAME
'univentionRecycleBinOriginalUniventionObjectIdentifier'
+attributetype ( 1.3.6.1.4.1.10176.4221.1.10
+ NAME ('univentionRecycleBinID'
'univentionRecycleBinOriginalUniventionObjectIdentifier')
DESC 'Original univentionObjectIdentifier of the deleted object'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE )
objectclass ( 1.3.6.1.4.1.10176.4221.2.2 NAME 'univentionRecycleBinObject'
DESC 'Object stored in the Recycle Bin'
SUP top STRUCTURAL
MUST ( univentionRecycleBinOriginalDN $
univentionRecycleBinDeleteAt $
- univentionRecycleBinOriginalUniventionObjectIdentifier $
+ univentionRecycleBinID $
univentionRecycleBinOriginalObjectClass $
univentionRecycleBinDeletionDate $
univentionRecycleBinOriginalEntryUUID $
univentionRecycleBinOriginalType )
MAY ( univentionObjectIdentifier $ univentionObjectType $
univentionRecycleBinReference ) )
```
Now the proof script:
It searches for a certain example object. And get its DN. (stored in a variable
with correct LDAP DN escape sequences).
Then it searches for that object. → no result
Then it searches for a modified DN so that its RDN uses a new name → no result
Then it searches for a modified DN so that its RDN uses the OID → no result
```bash
start="$(date '+%Y-%m-%d %H:%M:%S')"
sleep 1
ldaps () {
ldapsearch -o ldif-wrap=no -ZZ -D
cn=master,cn=dc,cn=computers,dc=ucs,dc=test -y /etc/machine.secret -LLL "$@"
}
DN=$(ldaps -LLLb 'cn=recyclebin,cn=internal'
univentionRecycleBinID=785c156b-bc84-4cb2-b34d-e10d78065a57 1.1 | sed -ne
's/^dn: //p')
echo "$DN"
ldaps -b "$DN" 1.1
ldaps -b "$(echo "$DN" | sed
's/univentionRecycleBinOriginalUniventionObjectIdentifier/univentionRecycleBinID/g')"
1.1
ldaps -b "$(echo "$DN" | sed
's/univentionRecycleBinOriginalUniventionObjectIdentifier/1.3.6.1.4.1.10176.4221.1.10/g;
s/univentionRecycleBinOriginalDN/1.3.6.1.4.1.10176.4221.1.5/')" 1.1
sleep 1
end="$(date '+%Y-%m-%d %H:%M:%S')"
journalctl --since="$start" --until="$end"
```
The command output and logs are attached, with stripped date prefix.
The logs show, that OL normalizes the DN internally. So the search by OID, or
alias is not a problem.
I don't know yet, (but i would suspect it), if OL backends store object DNs
internally by storing AVA-lists with OIDs: [[(OID, value, AVA_TYPE), …], …]
---
Background of our schema change reasoning:
We have very long RDN components now and reach some MDB limits.
I don't know if the limit only affect RDN values or as well the RDN
attribute-names.
But also for user-friendly-ness we want to shorten the DN name.
ldap.OTHER: {'msgtype': 105, 'msgid': 3, 'result': 80, 'desc': 'Other (e.g.,
implementation specific) error', 'ctrls': []}
slapd[28205]: => mdb_dn2id_add 0x3fb:
"univentionRecycleBinOriginalDN=uid\3Dumc_test_user_xvju2bhb6t\2Ccn\3Dintermediate_test_container\2Ccn\3Dbase_test_container\2Cdc\3Dautotest092\2Cdc\3Daaaa+univentionRecycleBinOriginalUniventionObjectIdentifier=675f8041-87d9-4483-9c46-e558f9f58c7f,cn=recyclebin,cn=internal"
slapd[28205]: <= mdb_dn2id_add 0x3fb: -30781
slapd[28205]: mdb_add: dn2id_add failed: MDB_BAD_VALSIZE: Unsupported size of
key/DB name/data, or wrong DUPFIXED size (-30781)
So we want to change:
univentionRecycleBinOriginalDN = {DN} +
univentionRecycleBinOriginalUniventionObjectIdentifier = {UUID} , cn =
recyclebin , cn = internal
to:
univentionRecycleBinID = {UUID} , parent(DN) , cn = recyclebin , cn = internal
But we must be backward compatible to a certain degree for old productive
systems.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10416
Issue ID: 10416
Summary: Allow setting fractional timeouts in ldaprc
Product: OpenLDAP
Version: 2.6.10
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: enhancement
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
Created attachment 1099
--> https://bugs.openldap.org/attachment.cgi?id=1099&action=edit
Patch to libldap init.c
Currently the ldap.conf parser only accepts integer seconds, even though the
internal variable also accommodates microseconds. A simple patch is attached.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10293
Issue ID: 10293
Summary: Log operations generated by syncrepl at STATS level
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: nivanova(a)symas.com
Target Milestone: ---
Similarly to how incoming operations are logged, operations created by syncrepl
should be logged as well.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8988
Howard Chu <hyc(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |TEST
Target Milestone|0.9.34 |1.0.0
Status|CONFIRMED |RESOLVED
--- Comment #28 from Howard Chu <hyc(a)openldap.org> ---
Fixed in 8ba07ad71138d7735df9225638f436dc060266b0 in mdb.master3
Note that this is an incompatible DB format change, DBs must be dumped and
reloaded.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10415
Issue ID: 10415
Summary: Allow limiting the buffers for data pending to be sent
to client
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: lloadd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
In many scenarios it is more useful to limit the amount of data we buffer to be
written to the client's socket even if it means that sometimes a connection
might have to be dropped abruptly to enforce this.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10258
Issue ID: 10258
Summary: test050 failure: connection_close race?
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
Created attachment 1032
--> https://bugs.openldap.org/attachment.cgi?id=1032&action=edit
tail of slapd log
Running test050 repeatedly, the slapd managed to get itself into an apparent
inconsistency in the connections structure. The logs suggest that there might
be a race closing the connection. Unfortunately the sanitiser didn't initiate a
core dump in this case.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10414
Issue ID: 10414
Summary: slapadd/modify adding a new entry to cn=config tries
to re-add frontend
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
The tool API does not know that the frontend entry was already present so it
tries and fails to add it.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10412
Issue ID: 10412
Summary: slapadd stops if the ldif files starts with 'version:'
Product: OpenLDAP
Version: 2.6.10
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: client tools
Assignee: bugs(a)openldap.org
Reporter: elecharny(a)apache.org
Target Milestone: ---
Injecting data with slapadd fails if the file starts with 'version: 1', with
such a message:
str2entry: entry -1 has no dn
slapadd: could not parse entry (line=1)
A LDIF file starting with 'version: 1' is a valid LDIF file per RFC 2849:
ldif-file = ldif-content / ldif-changes
ldif-content = version-spec 1*(1*SEP ldif-attrval-record)
version-spec = "version:" FILL version-number
version-number = 1*DIGIT
; version-number MUST be "1" for the
; LDIF format described in this document.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10026
Issue ID: 10026
Summary: Refresh handling can skip entries (si_dirty not
managed properly)
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: ---
Take MPR plain syncrepl with 3+ providers.
When a provider's own syncrepl session transitions to persist and a it starts a
new parallel session towards another host, that session always has to start as
a refresh. If that refresh serves entries to us, our handling of si_dirty is
not consistent:
- if the existing persist session serves some of these entries to us, we can
"forget" to pass the others to a newly connected consumer
- same if the refresh is abandoned and we start refreshing from a different
provider that might be behind what we were being served (again our consumers
could suffer)
- if we restart, si_dirty is forgotten and our consumers suffer even worse
We might need to be told (at the beginning of the refresh?) what the end state
we're going for is, so we can keep si_dirty on until then. And somehow persist
that knowledge in the DB...
--
You are receiving this mail because:
You are on the CC list for the issue.