Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
Description of problem:
When I try to run ipa-server-install from salt-stack, it fail when selinux is in enforcing mode.
Version-Release number of selected component (if applicable):
# rpm -q selinux-policy-targeted salt-minion ipa-server
selinux-policy-targeted-3.13.1-23.el7_1.18.noarch
salt-minion-2015.5.5-1.el7.noarch
ipa-server-4.1.0-18.el7_1.4.x86_64
How reproducible:
each time
Steps to Reproduce:
1. run ipa-server-install in the domain system_u:system_r:unconfined_service_t
( the command I used:
ipa-server-install -r EXAMPLE.ORG -n example.org -p ldap_password -U -a kerberos_password
3.
Actual results:
it fail at the end with a generic error message and this 2 AVC in audit.log:
type=AVC msg=audit(1443737437.066:574): avc: denied { read } for pid=22100 comm="httpd" scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=key
type=AVC msg=audit(1443737437.080:575): avc: denied { write } for pid=22100 comm="httpd" scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=key
Expected results:
no error and no AVC
Additional info:
I did the test on centos initially, but specifically reproduced it on RHEL 7, up to date.
It seems the issue is at the very end of the installation process, when it try to enroll the server in the ipa directory. Since this likely use heavily kerberos, I guess that's why the key in kernel are involved. I can provides the log if needed, but they are quite big.
So the last line of the error message (mostly so it can be found by search engine):
Forwarding 'ping' to json server 'https://freeipa01.rax.example.org/ipa/json'
Cannot connect to the server due to generic error: cannot connect to 'https://freeipa01.rax.example.org/ipa/json': Internal Server Error
Installation failed. As this is IPA server, changes will not be rolled back.
2015-10-01T15:44:45Z DEBUG File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 646, in run_script
return_value = main_function()
File "/usr/sbin/ipa-server-install", line 1292, in main
sys.exit("Configuration of client side components failed!\nipa-client-install returned: " + str(e))
2015-10-01T15:44:45Z DEBUG The ipa-server-install command failed, exception: SystemExit: Configuration of client side components failed!
ipa-client-install returned: Command ''/usr/sbin/ipa-client-install' '--on-master' '--unattended' '--domain' 'example.org' '--server' 'freeipa01.rax.example.org' '--realm' 'EXAMPLE.ORG' '--hostname' 'freeipa01.rax.example.org'' returned non-zero exit status 1
My current work around is to set selinux to permissive for the time of the installation.
Here is what I see on my VM:
# ps -efZ | grep salt
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root 3357 2301 0 09:59 pts/0 00:00:00 grep --color=auto salt
# service salt-minion start
Redirecting to /bin/systemctl start salt-minion.service
# service salt-minion status
Redirecting to /bin/systemctl status salt-minion.service
● salt-minion.service - The Salt Minion
Loaded: loaded (/usr/lib/systemd/system/salt-minion.service; disabled; vendor preset: disabled)
Active: active (running) since Sun 2015-10-04 09:59:41 CEST; 2s ago
Main PID: 3374 (/usr/bin/python)
CGroup: /system.slice/salt-minion.service
├─3374 /usr/bin/python /usr/bin/salt-minion
└─3398 /usr/bin/python /usr/bin/salt-minion
Oct 04 09:59:41 rhel72.localdomain systemd[1]: Started The Salt Minion.
Oct 04 09:59:41 rhel72.localdomain systemd[1]: Starting The Salt Minion...
Oct 04 09:59:42 rhel72.localdomain salt-minion[3374]: [ERROR ] DNS lookup o...
Oct 04 09:59:42 rhel72.localdomain salt-minion[3374]: [ERROR ] Master hostn...
Hint: Some lines were ellipsized, use -l to show in full.
# ps -efZ | grep unconfined_service_t
system_u:system_r:unconfined_service_t:s0 root 3374 1 0 09:59 ? 00:00:00 /usr/bin/python /usr/bin/salt-minion
system_u:system_r:unconfined_service_t:s0 root 3398 3374 2 09:59 ? 00:00:00 /usr/bin/python /usr/bin/salt-minion
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root 3513 2301 0 09:59 pts/0 00:00:00 grep --color=auto unconfined_service_t
#
$ ssh root.example.org ps faxZ |grep unconfined_serv
system_u:system_r:unconfined_service_t:s0 752 ? Ssl 0:34 /usr/sbin/nova-agent -q -p /var/run/nova-agent.pid -o /var/log/nova-agent.log -l debug /usr/share/nova-agent/nova-agent.py
system_u:system_r:unconfined_service_t:s0 11809 ? Ss 0:00 /usr/bin/python /usr/bin/salt-minion
system_u:system_r:unconfined_service_t:s0 11812 ? Sl 1:52 \_ /usr/bin/python /usr/bin/salt-minion
I didn't test (yet) on fedora, but I suspect it would be the same.
Description of problem: When I try to run ipa-server-install from salt-stack, it fail when selinux is in enforcing mode. Version-Release number of selected component (if applicable): # rpm -q selinux-policy-targeted salt-minion ipa-server selinux-policy-targeted-3.13.1-23.el7_1.18.noarch salt-minion-2015.5.5-1.el7.noarch ipa-server-4.1.0-18.el7_1.4.x86_64 How reproducible: each time Steps to Reproduce: 1. run ipa-server-install in the domain system_u:system_r:unconfined_service_t ( the command I used: ipa-server-install -r EXAMPLE.ORG -n example.org -p ldap_password -U -a kerberos_password 3. Actual results: it fail at the end with a generic error message and this 2 AVC in audit.log: type=AVC msg=audit(1443737437.066:574): avc: denied { read } for pid=22100 comm="httpd" scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=key type=AVC msg=audit(1443737437.080:575): avc: denied { write } for pid=22100 comm="httpd" scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=key Expected results: no error and no AVC Additional info: I did the test on centos initially, but specifically reproduced it on RHEL 7, up to date. It seems the issue is at the very end of the installation process, when it try to enroll the server in the ipa directory. Since this likely use heavily kerberos, I guess that's why the key in kernel are involved. I can provides the log if needed, but they are quite big.