Hide Forgot
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.
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.
Upstream ticket: https://pagure.io/freeipa/issue/7125
Fixed upstream master: https://pagure.io/freeipa/c/69bda6b440d6b84f042ff74b9ce708d963616eda
Fixed upstream ipa-4-5: https://pagure.io/freeipa/c/d9035a045bece8c9a205c078a8cdd2e1f101590b
*** Bug 1505369 has been marked as a duplicate of this bug. ***
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".
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