Bug 1360268 - Duplicate collation entries
Summary: Duplicate collation entries
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: 389-ds-base
Version: 24
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Noriko Hosoi
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-07-26 11:38 UTC by DaveG
Modified: 2016-11-19 21:10 UTC (History)
6 users (show)

Fixed In Version: 389-ds-base-1.3.5.15-1.fc24 389-ds-base-1.3.5.15-1.fc25
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-11-06 00:25:51 UTC


Attachments (Terms of Use)

Description DaveG 2016-07-26 11:38:16 UTC
Description of problem:

Desktop LDAP clients have trouble accessing FreeIPA via LDAP.
GQ crashes when accessing objects. Can display object hierarchy and schema but fails as soon as it accesses and object (leaf).
Luma can access and display objects but reports many errors:
ERROR: [base.backend.ObjectClassAttributeInfo/MainThread]: Could not fetch LDAP schema from server. Reason:
NAME not unique for ( 2.16.840.1.113730.3.3.2.211.1 NAME 'caseIgnoreOrderingMatch-sk' DESC 'sk' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )


Version-Release number of selected component (if applicable):

freeipa-admintools-4.3.1-1.fc24.noarch
freeipa-common-4.3.1-1.fc24.noarch
freeipa-server-common-4.3.1-1.fc24.noarch
freeipa-client-common-4.3.1-1.fc24.noarch
freeipa-client-4.3.1-1.fc24.x86_64
freeipa-server-4.3.1-1.fc24.x86_64
389-ds-base-libs-1.3.5.10-1.fc24.x86_64
389-ds-base-1.3.5.10-1.fc24.x86_64


How reproducible:

Always.


Steps to Reproduce:
1. Install freeipa and create instance.
2. Access the LDAP service using a desktop client.


Actual results:

See above.


Expected results:

Should work.


Additional info:

My FreeIPA instance started life some time ago and has been upgraded a number of times so I tried a new VM installation and it has exactly the same issue. That implies that it is not an upgrade issue.

Since GQ can see the schema tree I used that. It shows some duplicate entries under {server}/matchingRules:

Name				OID
...
caseIgnoreOrderingMatch-sk	2.16.840.1.113730.3.3.2.42.1
caseIgnoreOrderingMatch-sk	2.16.840.1.113730.3.3.2.211.1
caseIgnoreOrderingMatch-sl	2.16.840.1.113730.3.3.2.43.1
caseIgnoreOrderingMatch-sl	2.16.840.1.113730.3.3.2.212.1
caseIgnoreOrderingMatch-sq	2.16.840.1.113730.3.3.2.44.1
caseIgnoreOrderingMatch-sq	2.16.840.1.113730.3.3.2.213.1
...

It looks like these languages are being added twice.
All other entries are unique (I think).

Just guessing but the probable cause is:
https://git.fedorahosted.org/cgit/389/ds.git/tree/ldap/schema/slapd-collations.conf#n58
https://git.fedorahosted.org/cgit/389/ds.git/tree/ldap/schema/slapd-collations.conf#n59
https://git.fedorahosted.org/cgit/389/ds.git/tree/ldap/schema/slapd-collations.conf#n61
then:
https://git.fedorahosted.org/cgit/389/ds.git/tree/ldap/schema/slapd-collations.conf#n227
https://git.fedorahosted.org/cgit/389/ds.git/tree/ldap/schema/slapd-collations.conf#n228
https://git.fedorahosted.org/cgit/389/ds.git/tree/ldap/schema/slapd-collations.conf#n229

I think the second batch of entries is for sub-languages but they also appear to add the main language too which is defined in the first batch.

Commit?
https://git.fedorahosted.org/cgit/389/ds.git/commit/ldap/schema/slapd-collations.conf?id=e0c78d5b87d4d798a936eba9c90f5db5347bcb3c

Comment 1 Noriko Hosoi 2016-07-26 17:00:51 UTC
Upstream ticket:
https://fedorahosted.org/389/ticket/48936

Comment 2 Noriko Hosoi 2016-07-26 17:03:18 UTC
Thank you for the report.

Could it be possible to share the steps how to reproduce the problem?

Also, it'd be helpful if you could share the access and errors log files in /var/log/dirsrv/slapd-INSTANCE.

Comment 3 DaveG 2016-07-26 20:55:13 UTC
My only experience with 389-ds is through freeipa-server.

I have been using gq desktop LDAP client to inspect the LDAP data maintained by freeipa, check service account entries etc. It just crashes now, as noted.

That stopped working a while back (months?) so I tried the luma desktop LDAP client. After configuring for anonymous access it shows the duplicate name errors but keeps running.

The freeipa instance is still functional and, as far as I can tell, it is not throwing any errors.

389-ds does not appear to be throwing any errors either. The error log just has start, stop, SSL cypher messages, plugins... Nothing interesting.

Looks like 389-ds itself is OK but GUI clients that use schema for display are hitting this duplicate entry issue. I doubt many applications use or access the schema tree.

So, to reproduce, try the luma desktop client on any recent 389-ds instance, configure an anonymous bind to the server, enable error messages and try browsing the tree. Should show the same errors.

I'm fairly sure the problem is in the cited git commit - new sub-languages added separately rather than added to the originals.

If you need the error logs, let me know.

--DaveG.

Comment 4 Noriko Hosoi 2016-07-26 21:22:22 UTC
Thanks for your response, Dave.

I'm curious how the collation is being used in your environment.  
Do you have indexes based upon some language? 
What does this command line return?
# grep nsMatchingRule /etc/dirsrv/slapd-*/dse.ldif

Or are you running server side sorting searches?  If you could share your access log, it may tell us some idea...

Thanks,
--noriko

Comment 5 DaveG 2016-07-26 22:20:37 UTC
First:
# grep nsMatchingRule /etc/dirsrv/slapd-*/dse.ldif
nsMatchingRule: integerOrderingMatch
nsMatchingRule: integerOrderingMatch
nsMatchingRule: integerOrderingMatch
nsMatchingRule: integerOrderingMatch
nsMatchingRule: integerOrderingMatch
nsMatchingRule: integerOrderingMatch
nsMatchingRule: integerOrderingMatch
nsMatchingRule: integerOrderingMatch

LDAP instance is "stock" freeipa, external CA, no DNS.
No custom indexes.

Using desktop GUI LDAP clients to explore data.

Tried a "fix" that appears to work for me:
Commented out lines 58-60 in /etc/dirsrv/slapd-*/slapd-collations.conf and restarted ipa.service.
(Not sure which entries are correct (lines 58-60 or 227-229))
No more errors reported in the luma client.

-DaveG

P.S.
Looks like the gq client is no longer maintained and still crashes. There are other similar BZ reports for it so I'll stop using that.

Comment 6 DaveG 2016-07-29 13:01:01 UTC
Not sure of the exact syntax but I think this is what was intended:

--- /etc/dirsrv/config/slapd-collations.conf	2016-07-01 21:46:48.000000000 +0100
+++ /etc/dirsrv/slapd-EXAMPLE-ORG/slapd-collations.conf	2016-07-29 13:50:49.128677795 +0100
@@ -224,9 +224,9 @@
 collation ru RU "" 1 3	2.16.840.1.113730.3.3.2.208.1	ru-RU
 collation ru UA "" 1 3	2.16.840.1.113730.3.3.2.209.1	ru-UA
 collation si "" "" 1 3	2.16.840.1.113730.3.3.2.210.1	si	si-LK
-collation sk "" "" 1 3	2.16.840.1.113730.3.3.2.211.1	sk	sk-SK
-collation sl "" "" 1 3	2.16.840.1.113730.3.3.2.212.1	sl	sl-SI
-collation sq "" "" 1 3	2.16.840.1.113730.3.3.2.213.1	sq	sq-AL
+collation sk SK "" 1 3	2.16.840.1.113730.3.3.2.211.1	sk-SK
+collation sl SI "" 1 3	2.16.840.1.113730.3.3.2.212.1	sl-SI
+collation sq AL "" 1 3	2.16.840.1.113730.3.3.2.213.1	sq-AL
 collation sr Cyrl "" 1 3	2.16.840.1.113730.3.3.2.214.1	sr-Cyrl
 collation sr Cyrl BA 1 3	2.16.840.1.113730.3.3.2.215.1	sr-Cyrl-BA
 collation sr Cyrl ME 1 3	2.16.840.1.113730.3.3.2.216.1	sr-Cyrl-ME

The commit noted above added the base language again, causing the duplication.
This works for me.

--DaveG.

Comment 7 Noriko Hosoi 2016-07-29 17:07:05 UTC
Thank you, Dave.  

We verified that the lines in slapd-collation.conf you reported caused the regression.  It will be fixed in the next 389-ds-base build for F24.

Thanks!

Comment 8 Fedora Update System 2016-11-03 20:44:40 UTC
389-ds-base-1.3.5.15-1.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-8660c7656f

Comment 9 Fedora Update System 2016-11-03 21:17:15 UTC
389-ds-base-1.3.5.15-1.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-8f9d466bcc

Comment 10 Fedora Update System 2016-11-05 03:34:26 UTC
389-ds-base-1.3.5.15-1.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-8660c7656f

Comment 11 Fedora Update System 2016-11-05 18:59:26 UTC
389-ds-base-1.3.5.15-1.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-8f9d466bcc

Comment 12 Fedora Update System 2016-11-06 00:25:51 UTC
389-ds-base-1.3.5.15-1.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.

Comment 13 Fedora Update System 2016-11-19 21:10:35 UTC
389-ds-base-1.3.5.15-1.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.