RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1075118 - Replica installation fails if replica file generated on migrated replica
Summary: Replica installation fails if replica file generated on migrated replica
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ipa
Version: 7.0
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: rc
: ---
Assignee: Martin Kosek
QA Contact: Namita Soman
URL:
Whiteboard:
Depends On:
Blocks: 1073810
TreeView+ depends on / blocked
 
Reported: 2014-03-11 14:24 UTC by Kaleem
Modified: 2014-06-18 00:15 UTC (History)
8 users (show)

Fixed In Version: ipa-3.3.3-24.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-06-13 11:43:40 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
ipa replica install log file (154.50 KB, text/plain)
2014-03-11 14:24 UTC, Kaleem 		no flags Details
console output of ipa replica install (6.23 KB, text/plain)
2014-03-18 12:51 UTC, Kaleem 		no flags Details
View All

Description Kaleem 2014-03-11 14:24:03 UTC 
Created attachment 873161 [details]
ipa replica install log file

Description of problem:

This i faced when i tried to create a replica from a Replica (RHEL-7.0) which was migrated from a RHEL-6.5 based Master.

Version-Release number of selected component (if applicable):
[root@rhel70-replica ~]# rpm -q ipa-server pki-ca 389-ds-base
ipa-server-3.3.3-21.el7.x86_64
pki-ca-10.0.5-3.el7.noarch
389-ds-base-1.3.1.6-22.el7.x86_64
[root@rhel70-replica ~]# 


How reproducible:
Always

Steps to Reproduce:
1. Install Master on RHEL-6.5 
2. Install Replica on RHEL-7.0 from RHEL-6.5 based Master.
3. Now again install another replica on RHEL-7.0 from replica of step (2).

Actual results:

Replica install fails

Expected results:
Replica install should be successful 

Additional info:
Please find the attached ipareplica-install.log from replica machine where replica installation is failing
Comment 2 Martin Kosek 2014-03-11 15:45:52 UTC 
Thanks for report, I can also reproduce. Adding more data

7.0 replica httpd access_log:
...
10.16.78.57 - - [11/Mar/2014:11:34:08 -0400] "GET /ca/rest/securityDomain/domainInfo HTTP/1.1" 200 236
10.16.78.57 - - [11/Mar/2014:11:34:09 -0400] "GET /ca/rest/account/login HTTP/1.1" 403 272


7.0 replica /var/log/pki/pki-tomcat/ca/system:
...
28495.ajp-bio-127.0.0.1-8009-exec-2 - [11/Mar/2014:11:34:09 EDT] [13] [6] checkPermission(): permission denied for the resource certServer.ca.account on operation login
28495.ajp-bio-127.0.0.1-8009-exec-2 - [11/Mar/2014:11:34:09 EDT] [13] [3] Authorization Failed

Nathan, Ade or Rob - any idea what could cause this one? I am also CCing Jan to help with this case.
Comment 4 Nathan Kinder 2014-03-11 16:41:08 UTC 
Is this the same as the other issue you reported with AVC messages when creating a replica?

    https://bugzilla.redhat.com/show_bug.cgi?id=1075153

If it's not the same, do you see any AVC messages for this issue?
Comment 5 Namita Soman 2014-03-11 17:05:11 UTC 
when installing rhel7 replica - the AVCs mentioned in bz1075153 were seen. 

Then this SAME rhel7 ipa server was used to generate replica pkg and install a new rhel7 replica
Comment 6 Martin Kosek 2014-03-11 19:44:22 UTC 
I can reproduce this issue even with SELinux to permissive, I do not think this is solely caused by SELinux (though I agree that potential SELinux issues should be fixed).
Comment 7 Dmitri Pal 2014-03-11 20:07:38 UTC 
Upstream ticket:
https://fedorahosted.org/freeipa/ticket/4243
Comment 8 Martin Kosek 2014-03-11 21:26:08 UTC 
I was now working Endi on investigating the issue in my VMs and Endi discovered that there some ACLs missing (cn=aclResources,o=ipaca) due to incomplete update of the PKI database to Dogtag 10 level.

This is something I would like have investigated further and decide what we would do for 7.0, I see 2 options:

1) Fix pkispawn so that when Dogtag 10 clone is being created and it detects this is a Dogtag 9 DB, it adds missing ACL items or other entries required for Dogtag 10 function. This precludes that these changes do not destroy PKI on RHEL-6.

2) Do not fix anything in 7.0 and just add a new step to the migration procedure so that admin needs to run ldapmodify to add the missing Dogtag 10 DB himself as a requirement to be able install additional Dogtag 10 clone (not my favorite option).
Comment 9 Endi Sukma Dewata 2014-03-11 22:16:25 UTC 
As Martin mentioned, Dogtag 10 (RHEL 7) requires some additional ACL entries, but currently there is no automatic mechanism to upgrade Dogtag 9 (RHEL 6.5) database, so the entries have to be added manually with this command:

$ ldapmodify -h `hostname` -D "cn=Directory Manager" -w <password> -x
dn: cn=aclResources,o=ipaca
changetype: modify
add: resourceACLS
resourceACLS: certServer.ca.account:login,logout:allow (login,logout) user="anybody":Anybody can login and logout
resourceACLS: certServer.ca.certrequests:execute:allow (execute) group="Certificate Manager Agents":Agents may execute cert request operations
resourceACLS: certServer.ca.certs:execute:allow (execute) group="Certificate Manager Agents":Agents may execute cert operations
resourceACLS: certServer.ca.groups:execute:allow (execute) group="Administrators":Admins may execute group operations
resourceACLS: certServer.ca.users:execute:allow (execute) group="Administrators":Admins may execute user operations
-
delete: resourceACLS
resourceACLS: certServer.securitydomain.domainxml:read,modify:allow (read) user="anybody";allow (modify) group="Subsystem Group":Anybody is allowed to read domain.xml but only Subsystem group is allowed to modify the domain.xml
-
add: resourceACLS
resourceACLS: certServer.securitydomain.domainxml:read,modify:allow (read) user="anybody";allow (modify) group="Subsystem Group" || group="Enterprise CA Administrators" || group="Enterprise KRA Administrators" || group="Enterprise RA Administrators" || group="Enterprise OCSP Administrators" || group="Enterprise TKS Administrators" || group="Enterprise TPS Administrators":Anybody is allowed to read domain.xml but only Subsystem group and Enterprise Administrators are allowed to modify the domain.xml
-
delete: resourceACLS
resourceACLS: certServer.ca.connectorInfo:read,modify:allow (modify,read) group="Enterprise KRA Administrators":Only Enterprise Administrators are allowed to update the connector information
-
add: resourceACLS
resourceACLS: certServer.ca.connectorInfo:read,modify:allow (read) group="Enterprise KRA Administrators";allow (modify) group="Enterprise KRA Administrators" || group="Subsystem Group":Only Enterprise Administrators and Subsystem Group are allowed to update the connector information

Note that in order to run this command, the base DN must match the existing tree, and the delete operations must match the current content. Also, since the database is replicated, this command should only be executed once. Additional testing may be needed to verify that the older Dogtag (RHEL 6.5) will continue to run with the upgraded database.
Comment 10 Martin Kosek 2014-03-12 09:48:42 UTC 
I can confirm I was repeatedly able to install IPA replica when these ACLs were fixed. I did basic tests of requesting certificates in both Dogtag 9 and Dogtag 10 based replicas and it worked. I also tried installing IPA client for both D9 and D10 replicas and certmonger correctly retrieved the client certificate.

So now we just need to fix pkispawn to migrate the ACLs when it detects they are not there.
Comment 11 Martin Kosek 2014-03-12 16:00:41 UTC 
Removing needinfo? - we already identified this is not caused by SELinux.
Comment 12 Martin Kosek 2014-03-13 15:57:40 UTC 
After discussion, we chose to do the ACL updates in IPA replica installer. This will fix the issue for the short term.

The long term fix will be used when database migration scripts are added in PKI:

https://fedorahosted.org/pki/ticket/710 (database upgrade framework)
https://fedorahosted.org/pki/ticket/906 (checking database version)
Comment 14 Petr Viktorin (pviktori) 2014-03-14 13:29:05 UTC 
Fixed upstream
master:
https://fedorahosted.org/freeipa/changeset/b3c2197b7e4ed18a7febe3efa6396c2272ebccca
ipa-3-3:
https://fedorahosted.org/freeipa/changeset/9bc032f9ec0c44e83550d6f87f72e9395c3093d9
Comment 15 Kaleem 2014-03-18 12:50:39 UTC 
Verified. Now replica install is successful with replica file created on migrated replica on RHEL-7.0 from RHEL-6.5 based IPA installation.

IPA Version:
============
[root@rhel70-replica ~]# rpm -q ipa-server pki-ca
ipa-server-3.3.3-25.el7.x86_64
pki-ca-10.0.5-3.el7.noarch
[root@rhel70-replica ~]#

Please find the attached console output.
Comment 16 Kaleem 2014-03-18 12:51:31 UTC 
Created attachment 875921 [details]
console output of ipa replica install
Comment 17 Ludek Smid 2014-06-13 11:43:40 UTC 
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.
Note You need to log in before you can comment on or make changes to this bug.