Bug 1268141
| Summary: | AVC when trying to install ipa server using saltstack | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | M. Scherer <mscherer> |
| Component: | ipa | Assignee: | IPA Maintainers <ipa-maint> |
| Status: | CLOSED DUPLICATE | QA Contact: | Namita Soman <nsoman> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.1 | CC: | ipa-maint, lvrabec, mgrepl, mkosek, mmalik, mscherer, plautrba, pvoborni, pvrabec, rcritten, ssekidde, tbabej |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-10-08 09:20:02 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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. What processes are running as unconfined_service_t? Is salt-minion among them? # ps -efZ | grep unconfined_service_t 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. Do we use Salt here? Where? IPA doesn't use Salt at all. I think this is related to https://fedorahosted.org/freeipa/ticket/4815 https://fedorahosted.org/freeipa/ticket/4973 Can you please test on IPA 4.2+ (RHEL-7.2 Beta or later)? (In reply to Martin Kosek from comment #8) > I think this is related to > https://fedorahosted.org/freeipa/ticket/4815 > https://fedorahosted.org/freeipa/ticket/4973 Yes, it looks so. Thank you. > > Can you please test on IPA 4.2+ (RHEL-7.2 Beta or later)? So I tested on 7.2 Beta and it seems to work fine now. Alright, closing as duplicate of Bug 1164896 then. *** This bug has been marked as a duplicate of bug 1164896 *** |
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.