This happens when installing replica without all optional components.
The error is printed to console and also into /var/log/ipareplica-install.log:
/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.
attachment ipareplica-install.log.bz2
Could be related to https://fedorahosted.org/389/ticket/48840
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:
/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:
ipa-server-install
associatedDomain
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:
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.
add
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
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)
Login to comment on this ticket.