Bug 1480102 - ipa-server-upgrade failes with "This entry already exists"
ipa-server-upgrade failes with "This entry already exists"
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ipa (Show other bugs)
7.4
Unspecified Unspecified
high Severity high
: rc
: ---
Assigned To: IPA Maintainers
Petr Čech
: ZStream
: 1505369 (view as bug list)
Depends On:
Blocks: 1489817
  Show dependency treegraph
 
Reported: 2017-08-10 03:33 EDT by German Parente
Modified: 2018-04-10 12:45 EDT (History)
12 users (show)

See Also:
Fixed In Version: ipa-4.5.0-21.el7.2
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1489817 (view as bug list)
Environment:
Last Closed: 2018-04-10 12:43:55 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:0918 None None None 2018-04-10 12:45 EDT

  None (edit)
Description German Parente 2017-08-10 03:33:31 EDT
Description of problem:

ipa-server-upgrade fails with:

===========================================================
ipa: DEBUG: stderr=
ipa.ipaserver.plugins.ldap2.ldap2: DEBUG: Destroyed connection context.ldap2_100258128
ipa: ERROR: Upgrade failed with This entry already exists
ipa: DEBUG: Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line 220, in __upgrade
    self.modified = (ld.update(self.files) or self.modified)
  File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 911, in update
    self._run_updates(all_updates)
  File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 883, in _run_updates
    self._run_update_plugin(update['plugin'])
  File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 859, in _run_update_plugin
    restart_ds, updates = self.api.Updater[plugin_name]()
  File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 1470, in __call__
    return self.execute(**options)
  File "/usr/lib/python2.7/site-packages/ipaserver/install/plugins/upload_cacrt.py", line 84, in execute
    ldap.update_entry(entry)
  File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1553, in update_entry
    self.conn.modify_s(str(entry.dn), modlist)
  File "/usr/lib64/python2.7/contextlib.py", line 35, in __exit__
    self.gen.throw(type, value, traceback)
  File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 973, in error_handler
    raise errors.DuplicateEntry()
DuplicateEntry: This entry already exists

ipa: DEBUG: Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 504, in start_creation
    run_step(full_msg, method)
  File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 494, in run_step
    method()
  File "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line 228, in __upgrade
    raise RuntimeError(e)
RuntimeError: This entry already exists
===========================================================

"plugins.upload_cacrt"


Taking a look at the logs we see operations like these failing by constraint violation trying to add entries under "cn=certificates,cn=ipa,cn=etc,dc=rh,dc=ad,dc=example,dc=com"


[09/Aug/2017:09:15:18.481708979 +091800] conn=5 op=352 ADD dn="cn=CN\3DITS-ROOT-CA,cn=certificates,cn=ipa,cn=etc,dc=rh,dc=ad,dc=example,dc=com"
[09/Aug/2017:09:15:18.482796949 +091800] conn=5 op=352 RESULT err=19 tag=105 nentries=0 etime=0
[09/Aug/2017:09:15:18.614559050 +091800] conn=5 op=353 ADD dn="cn=CN\3D><some identifier>,cn=certificates,cn=ipa,cn=etc,dc=rh,dc=ad,dc=example,dc=com"
[09/Aug/2017:09:15:18.615085522 +091800] conn=5 op=353 RESULT err=19 tag=105 nentries=0 etime=0
[09/Aug/2017:09:15:18.741092201 +091800] conn=5 op=354 ADD dn="cn=<REALM> IPA CA,cn=certificates,cn=ipa,cn=etc,dc=rh,dc=ad,dc=example,dc=com"
[09/Aug/2017:09:15:18.741626613 +091800] conn=5 op=354 RESULT err=19 tag=105 nentries=0 etime=0
[09/Aug/2017:09:15:18.742198157 +091800] conn=5 op=355 MOD dn="cn=<REALM> IPA CA,cn=certificates,cn=ipa,cn=etc,dc=rh,dc=ad,dc=example,dc=com"
[09/Aug/2017:09:15:18.742698466 +091800] conn=5 op=355 RESULT err=19 tag=103 nentries=0 etime=0
[09/Aug/2017:09:15:18.745671297 +091800] conn=5 op=356 UNBIND


Version-Release number of selected component (if applicable): ipa-server-4.5.0-21.el7.x86_64


How reproducible: very often. I have seen it in two customers. So, I am logging this bug.
Comment 2 Florence Blanc-Renaud 2017-08-10 04:48:08 EDT
The issue happens when the upgrade plugin upload_cacrt is run. This plugin looks for CA certs in /etc/httpd/alias and uploads them into cn='nickname',cn=certificates,cn=ipa,cn=etc,<BASEDN>.

The attribute uniqueness plugin is configured on the subtree cn=certificates,cn=ipa,cn=etc,<BASEDN> and makes sure that only one entry contains the certificate (with the same ipaCertIssuerSerial attribute or with the same ipaCertSubject).

In the customer case 01905789, the CA certificate is already stored as cn=CA 1,cn=certificates,cn=ipa,cn=etc,<BASEDN> and the upgrade plugin is trying to add it as cn=UNIX.LOCAL IPA CA,cn=certificates,cn=etc,<BASEDN>. The attribute uniqueness plugin prevents the ADD operation and the ADD returns 19 (constraint violation).

Not clear to me why the cert was stored with a dn cn=CA1 (maybe older versions of IPA did not use the nickname when uploading the certs to LDAP), but for sure we should enhance the error message to ease troubleshooting.

The workaround is to rename cn=CA 1,cn=certificates,cn=ipa,cn=etc,<BASEDN> into cn=UNIX.LOCAL IPA CA,cn=certificates,cn=etc,<BASEDN> and re-run ipa-server-upgrade.
Comment 17 Florence Blanc-Renaud 2017-08-28 04:46:20 EDT
Upstream ticket:
https://pagure.io/freeipa/issue/7125
Comment 20 Stanislav Laznicka 2017-08-30 06:50:19 EDT
Fixed upstream
master:
https://pagure.io/freeipa/c/69bda6b440d6b84f042ff74b9ce708d963616eda
Comment 21 Stanislav Laznicka 2017-09-08 06:42:48 EDT
Fixed upstream
ipa-4-5:
https://pagure.io/freeipa/c/d9035a045bece8c9a205c078a8cdd2e1f101590b
Comment 24 Florence Blanc-Renaud 2017-11-13 01:59:19 EST
*** Bug 1505369 has been marked as a duplicate of this bug. ***
Comment 25 Nikhil Dehadrai 2017-12-14 07:41:29 EST
ipa server: ipa-server-4.5.4-6.el7.x86_64

Verified the bug in two PARTS:-
1) Upgrade
2) Plain-Installation

PART-ONE:
================
Following steps for UPGRADE SCENARIOs:

1) Setup IPA server (in my case RHEL 7.3.z / RHEl 7.4.3, using self-sign certificate)
2) Run ldapsearch to check for certificate serial number / nickname details.
3) Modify the certificate nickname to "CA 1"
4) Re-run step2 to confirm changes implemented.
5) Add latest repo for RHEL 7.5 and run "yum -y update ' ipa*' sssd"
6) After upgrade, ldapsearch command to check for certificate serial number / nickname details returns the default details displayed in step2 (and not step4).
7) ipactl command is run successfully
8) ipaupgrade is successful.
9) UI login is successful.

PART-TWO:
================
Following steps for PLAIN INSTALLATION SCENARIO:

1. Setup IPA server (in my case RHEL 7.5), using command on master:
#ipa-server-install --subject=O=subject_testrelm.test
2. Run ldapsearch to check for the content of cn=certificates,cn=ipa,cn=etc,$BASEDN on IPA master.
3. Setup Replica (RHEL 7.5)
4. Run ldapsearch to check for the content of cn=certificates,cn=ipa,cn=etc,$BASEDN on IPA Replica and noticed that the original entry CN=$DOMAIN IPA CA,cn=certificates,cn=ipa,cn=etc,$BASEDN is displayed as expected.

Thus on the basis of above observations, marking the status of bug to "VERIFIED".
Comment 29 errata-xmlrpc 2018-04-10 12:43:55 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:0918

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