#5972 LDAP updater does not respect equality matching rules from LDAP schema
Closed: wontfix 5 years ago by rcritten. Opened 7 years ago by pspacek.

This happens when installing replica without all optional components.

The error is printed to console and also into /var/log/ipareplica-install.log:

2016-06-17T12:50:44Z DEBUG Unhandled LDAPError: TYPE_OR_VALUE_EXISTS: {'desc': 'Type or value exists'}
2016-06-17T12:50:44Z ERROR Update failed: Type or value exists:

I'm going to attach full log but I'm not able to find detailed information in it.


Interestingly this is reproducible even on clean 4.3.1 master + 4.3.1 replica.

Okay, so relevant parts of logs are:

  • /var/log/dirsrv/slapd-DOM-058-082-ABC-IDM-LAB-ENG-BRQ-REDHAT-COM/access:

    [27/Jun/2016:09:44:19.921122110 +0200] conn=3 op=181 MOD dn="dc=dom-058-082,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com"
    [27/Jun/2016:09:44:19.922111461 +0200] conn=3 op=181 RESULT err=20 tag=103 nentries=0 etime=0 csn=5770d954000000030000

  • /var/log/ipareplica-install.log:

    2016-06-27T07:44:19Z DEBUG [(0, u'associatedDomain', ['DOM-058-082.ABC.IDM.LAB.ENG.BRQ.REDHAT.COM']), (0, u'nisDomain', ['DOM-058-082.ABC.IDM.LAB.ENG.BRQ.REDHAT.COM'])]
    2016-06-27T07:44:19Z DEBUG Updated 1
    2016-06-27T07:44:19Z DEBUG Unhandled LDAPError: TYPE_OR_VALUE_EXISTS: {'desc': 'Type or value exists'}

This is most likely caused by parameters I used for replica promotion. I'm installing the (to-be-promoted) client using following command:

ipa-client-install --domain=DOM-058-082.ABC.IDM.LAB.ENG.BRQ.REDHAT.COM

Please note the uppercase domain. The ipa-server-install stored lowercased values into associatedDomain attribute in LDAP:

dn: dc=dom-058-082,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com
objectClass: domainRelatedObject
objectClass: nisDomainObject
objectClass: pilotObject
objectClass: domain
objectClass: top
associatedDomain: dom-058-082.abc.idm.lab.eng.brq.redhat.com
dc: dom-058-082
nisDomain: dom-058-082.abc.idm.lab.eng.brq.redhat.com
info: IPA V2.0

In theory this is okay because equality match for the attribute is case-insensitive:

( 0.9.2342.19200300.100.1.37 NAME 'associatedDomain'  EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN ( 'RFC 4524' 'user defined' ) )

Apparently the updater is ignoring the equality rule when determining if the value should be added which leads to LDAP_TYPE_OR_VALUE_EXISTS error.

Right now I would say that this is low risk in this particular case but we should fix the LDAP abstraction to respect the rules before it bittes us in sensitive parts ...

On Master:

ipa-server-install --hostname=vm.<lowercase domain> -p Secret123 -a Secret123 --domain <lowercase domain>  -U --realm <UPPERCASE domain>

ldapsearch -LLL -h localhost -p 389 -D "cn=directory manager" -w Secret123 -b "<suffix>" -s base nisDomain associatedDomain
dn: <suffix>
nisDomain: <lowercase domain>
associatedDomain: <lowercase domain>

On Replica:

ipa-client-install --domain=<UPPERCASE domain> --realm=<UPPERCASE domain> --server=vm-058-116.<lowercase domain>
ipa-replica-install
Upgrading IPA:
  [1/9]: stopping directory server
  [2/9]: saving configuration
  [3/9]: disabling listeners
  [4/9]: enabling DS global lock
  [5/9]: starting directory server
  [6/9]: upgrading server
ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR    Update failed: Type or value exists: 
  [7/9]: stopping directory server
  [8/9]: restoring configuration



/var/log/ipareplica-install.log shows that the errors occurs with an update adding <UPPERCASE domain>


2016-06-29T10:39:21Z DEBUG Final value after applying updates
2016-06-29T10:39:21Z DEBUG dn: <suffix>
2016-06-29T10:39:21Z DEBUG info:
2016-06-29T10:39:21Z DEBUG      IPA V2.0
2016-06-29T10:39:21Z DEBUG objectClass:
2016-06-29T10:39:21Z DEBUG      pilotObject
2016-06-29T10:39:21Z DEBUG      top
2016-06-29T10:39:21Z DEBUG      nisDomainObject
2016-06-29T10:39:21Z DEBUG      domain
2016-06-29T10:39:21Z DEBUG      domainRelatedObject
2016-06-29T10:39:21Z DEBUG associatedDomain:
2016-06-29T10:39:21Z DEBUG      <lowercase domain>
2016-06-29T10:39:21Z DEBUG      <UPPERCASE domain>
2016-06-29T10:39:21Z DEBUG dc:
2016-06-29T10:39:21Z DEBUG      abc
2016-06-29T10:39:21Z DEBUG nisDomain:
2016-06-29T10:39:21Z DEBUG      <lowercase domain>
2016-06-29T10:39:21Z DEBUG      <UPPERCASE domain>
...
2016-06-29T10:39:21Z DEBUG [(0, u'associatedDomain', ['<UPPERCASE domain>']), (0, u'nisDomain', ['<UPPERCASE domain>'])]
2016-06-29T10:39:21Z DEBUG Updated 1
2016-06-29T10:39:21Z DEBUG Unhandled LDAPError: TYPE_OR_VALUE_EXISTS: {'desc': 'Type or value exists'}
2016-06-29T10:39:21Z ERROR Update failed: Type or value exists:




The LDAP update is



time: 20160629123921
dn: <suffix>
result: 20
changetype: modify
add: associatedDomain
associatedDomain: <UPPERCASE domain>
-
add: nisDomain
nisDomain: <UPPERCASE domain>
-
replace: modifiersname
modifiersname: cn=Directory Manager
-
replace: modifytimestamp
modifytimestamp: 20160629103921Z
-
replace: entryusn
entryusn: 45
-



The suffix entry remains unchanged (because of err=20) with the lowercase domain


ldapsearch -LLL -h localhost -p 389 -x -b "<suffix>" -s base nisDomain associatedDomain
dn: <suffix>
nisDomain: <lowercase domain>
associatedDomain: <lowercase domain>

Could it be possible to do a LDAP replace with the new values ?

The trick is that IPA updater should detect that the (supposedly) new value is already in LDAP and do not attempt to add a duplicite:

See file install/updates/20-nss_ldap.update:

# Update the top-level entry 
dn: $SUFFIX
add:objectClass: domain
add:objectClass: domainRelatedObject
add:objectClass: nisDomainObject
add:associatedDomain: $DOMAIN
add:nisDomain: $DOMAIN

I.e. the problem is that LDAP updater is not respecting equality matching rule when evaluating add command in the update file.

We may use the comparison to determine if the value to add is already present:

ldapsearch -LLL -h localhost -p 389 -b "<suffix>" -s base associatedDomain
dn: <suffix>
associatedDomain: <lowercase domain>

[root@vm-058-116 ~]# ldapcompare -h localhost -p 389  "<suffix>" associatedDomain:<UPPERCASE domain>
TRUE

The drawback is that it is one more request before the update.

Metadata Update from @pspacek:
- Issue assigned to someone
- Issue set to the milestone: Future Releases

7 years ago

Thank you taking time to submit this request for FreeIPA. Unfortunately this bug was not given priority and the team lacks the capacity to work on it at this time.

Given that we are unable to fulfil this request I am closing the issue as wontfix. To request re-consideration of this decision please reopen this issue and provide additional technical details about its importance to you.

Metadata Update from @rcritten:
- Issue close_status updated to: wontfix
- Issue status updated to: Closed (was: Open)

5 years ago

Login to comment on this ticket.

Metadata