Bug 1007606 - ipa-server-install failing with fault 907 during ipa-client-install phase
ipa-server-install failing with fault 907 during ipa-client-install phase
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: policycoreutils (Show other bugs)
7.0
Unspecified Unspecified
urgent Severity high
: rc
: ---
Assigned To: Daniel Walsh
David Spurek
: TestBlocker
: 1011164 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-12 19:05 EDT by Michael Gregg
Modified: 2015-03-02 00:28 EST (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-06-13 09:17:02 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)
CLI output from running ipa-server-install (7.23 KB, text/plain)
2013-09-12 19:05 EDT, Michael Gregg
no flags Details
offending client install log (15.24 KB, text/plain)
2013-09-12 19:07 EDT, Michael Gregg
no flags Details
audit log from install after eratta (58.16 KB, text/x-log)
2013-09-30 19:51 EDT, Michael Gregg
no flags Details
client install log from after eratta (14.82 KB, text/x-log)
2013-09-30 19:51 EDT, Michael Gregg
no flags Details
strace from setsebool command (833.94 KB, text/plain)
2013-10-04 20:06 EDT, Scott Poore
no flags Details

  None (edit)
Description Michael Gregg 2013-09-12 19:05:38 EDT
Created attachment 797056 [details]
CLI output from running ipa-server-install

Description of problem:
Manually installing IPA with:

ipa-server-install --idstart=3000 --ip-address 10.16.76.40 --idmax=50000 --setup-dns --forwarder=10.11.5.19 --hostname=qe-blade-09.testrelm.com -r TESTRELM.COM -n testrelm.com -p Secret123 -P Secret123 -a Secret123 -U

Failure in ipa-client-install 


Version-Release number of selected component (if applicable):
ipa-server-3.3.1-3.el7.x86_64
pki-base-10.0.5-1.el7.noarch

How reproducible:
unknown

Steps to Reproduce:
1. 
ipa-server-install --idstart=3000 --ip-address <your IP address> --idmax=50000 --setup-dns --forwarder=10.11.5.19 --hostname=<hostname>.testrelm.com -r TESTRELM.COM -n testrelm.com -p Secret123 -P Secret123 -a Secret123 -U

Actual results:
  [9/11]: restarting named
  [10/11]: configuring named to start on boot
  [11/11]: changing resolv.conf to point to ourselves
Done configuring DNS (named).

Global DNS configuration in LDAP server is empty
You can use 'dnsconfig-mod' command to set global DNS options that
would override settings in local named.conf files

Restarting the web server
Configuration of client side components failed!
ipa-client-install returned: Command '/usr/sbin/ipa-client-install --on-master --unattended --domain testrelm.com --server qe-blade-09.testrelm.com --realm TESTRELM.COM --hostname qe-blade-09.testrelm.com' returned non-zero exit status 1
Comment 1 Michael Gregg 2013-09-12 19:07:06 EDT
Created attachment 797057 [details]
offending client install log
Comment 4 Rob Crittenden 2013-09-12 21:27:58 EDT
Does /var/run%/slapd-TESTRELM-COM.socket exist? Are there any AVCs?

Can you see if there are any errors in the 389-ds error log, or look for issues at the tail of /var/log/httpd/error_log?
Comment 5 Michael Gregg 2013-09-13 15:07:09 EDT
The socket file does exist:
[root@ipaqa64vml ~]#  ls /var/run/slapd-TESTRELM-COM.socket  -alh
srw-rw-rw-. 1 root root 0 Sep 13 14:50 /var/run/slapd-TESTRELM-COM.socket

There is one AVC that may be helpful:

type=AVC msg=audit(1379098222.224:360): avc:  denied  { name_connect } for  pid=29785 comm="httpd" dest=389 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:ldap_port_t:s0 tclass=tcp_socket


The httpd error log doesn't seem to have much useful. 
This is the last 2 starts worth:

[Fri Sep 13 14:48:57.156476 2013] [core:notice] [pid 28975] AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND'
[Fri Sep 13 14:49:01.580854 2013] [:error] [pid 28977] ipa: INFO: *** PROCESS START ***
[Fri Sep 13 14:49:01.740416 2013] [:error] [pid 28978] ipa: INFO: *** PROCESS START ***
[Fri Sep 13 14:50:15.917708 2013] [mpm_prefork:notice] [pid 28975] AH00170: caught SIGWINCH, shutting down gracefully
[Fri Sep 13 14:50:17.238747 2013] [core:notice] [pid 29743] SELinux policy enabled; httpd running as context system_u:system_r:httpd_t:s0
[Fri Sep 13 14:50:17.240876 2013] [suexec:notice] [pid 29743] AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Fri Sep 13 14:50:17.555577 2013] [auth_digest:notice] [pid 29743] AH01757: generating secret for digest authentication ...
[Fri Sep 13 14:50:17.557087 2013] [lbmethod_heartbeat:notice] [pid 29743] AH02282: No slotmem from mod_heartmonitor
[Fri Sep 13 14:50:17.564756 2013] [:warn] [pid 29743] mod_wsgi: Compiled for Python/2.7.3.
[Fri Sep 13 14:50:17.564814 2013] [:warn] [pid 29743] mod_wsgi: Runtime using Python/2.7.5.
[Fri Sep 13 14:50:17.637543 2013] [mpm_prefork:notice] [pid 29743] AH00163: Apache/2.4.6 (Red Hat) mod_auth_kerb/5.4 mod_nss/2.4.4 NSS/3.15 mod_wsgi/3.4 Python/2.7.5 configured -- resuming normal operations
[Fri Sep 13 14:50:17.637670 2013] [core:notice] [pid 29743] AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND'
[Fri Sep 13 14:50:21.576975 2013] [:error] [pid 29745] ipa: INFO: *** PROCESS START ***
[Fri Sep 13 14:50:22.042598 2013] [:error] [pid 29746] ipa: INFO: *** PROCESS START ***
Comment 6 Scott Poore 2013-09-13 17:10:20 EDT
Marking this one TestBlocker. 

I'm hitting the same bug.  It's causing problems with my trust tests.
Comment 8 Rob Crittenden 2013-09-13 17:40:27 EDT
Scott, are you seeing the same AVC?
Comment 9 Scott Poore 2013-09-13 17:44:12 EDT
yes, similar:

type=SOCKADDR msg=audit(1379098968.774:216): saddr=020001850A1004110000000000000000

type=SYSCALL msg=audit(1379098968.774:216): arch=c000003e syscall=42 success=no exit=-13 a0=13 a1=7fd1bc0161b0 a2=10 a3=0 items=0 ppid=17527 pid=17577 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=4294967295 comm="httpd" exe="/usr/sbin/httpd" subj=system_u:system_r:httpd_t:s0 key=(null)

type=AVC msg=audit(1379098968.774:216): avc:  denied  { name_connect } for  pid=17577 comm="httpd" dest=389 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:ldap_port_t:s0 tclass=tcp_socket
Comment 10 Rob Crittenden 2013-09-13 18:01:03 EDT
Scott provided a system demonstrating this. Putting it into permissive mode results in a successful install when re-running the ipa-client-install command.

I'm a little confused by this AVC because it would appear that we're connecting over 389, but the error coming out of the server refers to ldapi.

audit2allow suggests adding this:

allow httpd_t ldap_port_t:tcp_socket name_connect;
Comment 11 Michael Gregg 2013-09-13 19:49:50 EDT
Adding a selinux module containing "allow httpd_t ldap_port_t:tcp_socket name_connect;" does allow ipa to install properly.
Comment 12 Scott Poore 2013-09-13 19:55:17 EDT
Also, I did setenforce 0 before a test that was failing and install worked without a problem.
Comment 13 Martin Kosek 2013-09-16 07:43:08 EDT
I think the failure is caused by ipa-server-install's inability to set respective SELinux booleans:

WARNING: could not set the following SELinux boolean(s):
  httpd_can_network_connect -> on
  httpd_manage_ipa -> on
The web interface may not function correctly until the booleans
are successfully changed with the command:
/usr/sbin/setsebool -P httpd_can_network_connect=on httpd_manage_ipa=on
Try updating the policycoreutils and selinux-policy packages.

It would be useful to get respective excerpt from ipaserver-install.log so that we can see what error was printed by setsebool.
Comment 14 Scott Poore 2013-09-16 10:40:19 EDT
This is what I see on a quick install check this morning:

2013-09-16T14:09:20Z DEBUG   [12/15]: configuring SELinux for httpd
2013-09-16T14:09:20Z DEBUG Starting external process
2013-09-16T14:09:20Z DEBUG args=/usr/sbin/selinuxenabled
2013-09-16T14:09:20Z DEBUG Process finished, return code=0
2013-09-16T14:09:20Z DEBUG stdout=
2013-09-16T14:09:20Z DEBUG stderr=
2013-09-16T14:09:20Z DEBUG Starting external process
2013-09-16T14:09:20Z DEBUG args=/usr/sbin/getsebool httpd_can_network_connect
2013-09-16T14:09:20Z DEBUG Process finished, return code=0
2013-09-16T14:09:20Z DEBUG stdout=httpd_can_network_connect --> off

2013-09-16T14:09:20Z DEBUG stderr=
2013-09-16T14:09:20Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state'
2013-09-16T14:09:20Z DEBUG Starting external process
2013-09-16T14:09:20Z DEBUG args=/usr/sbin/getsebool httpd_manage_ipa
2013-09-16T14:09:20Z DEBUG Process finished, return code=0
2013-09-16T14:09:20Z DEBUG stdout=httpd_manage_ipa --> off

2013-09-16T14:09:20Z DEBUG stderr=
2013-09-16T14:09:20Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state'
2013-09-16T14:09:20Z DEBUG Starting external process
2013-09-16T14:09:20Z DEBUG args=/usr/sbin/setsebool -P httpd_can_network_connect=on httpd_manage_ipa=on
2013-09-16T14:09:21Z DEBUG Process finished, return code=255
2013-09-16T14:09:21Z DEBUG stdout=
2013-09-16T14:09:21Z DEBUG stderr=Boolean httpd_can_network_connect is not defined

2013-09-16T14:09:21Z DEBUG WARNING: could not set the following SELinux boolean(s):
  httpd_can_network_connect -> on
  httpd_manage_ipa -> on
The web interface may not function correctly until the booleans
are successfully changed with the command:
/usr/sbin/setsebool -P httpd_can_network_connect=on httpd_manage_ipa=on
Try updating the policycoreutils and selinux-policy packages.
2013-09-16T14:09:21Z DEBUG   duration: 0 seconds
Comment 15 Scott Poore 2013-09-16 12:58:49 EDT
Need me to also post entire ipaserver-install.log?
Comment 16 Martin Kosek 2013-09-17 02:29:18 EDT
No, this should be enough. I am reassigning the Bug to policycoreutils, they have more experience with finding what gone wrong with setsebool.
Comment 17 Miroslav Grepl 2013-09-17 07:49:26 EDT
Dan
I sent you a patch for this issue.
Comment 18 Scott Poore 2013-09-18 20:29:58 EDT
FYI: 

Seems like this may be a workaround to run before ipa-server-install or ipa-replica-install:

/usr/sbin/semanage boolean --modify --on httpd_can_network_connect
/usr/sbin/semanage boolean --modify --on httpd_manage_ipa

So can this be fixed the same way bug 998974 was?  Is there a build of policycoreutils I can test with yet?

Thanks,
Scott
Comment 19 Miroslav Grepl 2013-09-19 03:25:07 EDT
(In reply to Scott Poore from comment #18)
> FYI: 
> 
> Seems like this may be a workaround to run before ipa-server-install or
> ipa-replica-install:
> 
> /usr/sbin/semanage boolean --modify --on httpd_can_network_connect
> /usr/sbin/semanage boolean --modify --on httpd_manage_ipa

Yes, it can be workaround for now.
> 
> So can this be fixed the same way bug 998974 was?

Yes, it should be fixed in the same way.

>  Is there a build of
> policycoreutils I can test with yet?

I sent a patch. So I believe Dan will build a new policycoreutils soon.
> 
> Thanks,
> Scott
Comment 20 Scott Poore 2013-09-23 10:25:27 EDT
Hi Dan,

Is this going to be fixed soon for RHEL7?

Thanks,
Scott
Comment 21 Daniel Walsh 2013-09-23 11:56:35 EDT
I need flags in order to build.

Fixed in /policycoreutils-2.1.14-81.el7
Comment 22 Martin Kosek 2013-09-24 03:26:11 EDT
We have the flags now, can we please build now to unblock IPA QE?
Comment 23 Scott Poore 2013-09-25 14:01:29 EDT
*** Bug 1011164 has been marked as a duplicate of this bug. ***
Comment 25 Michael Gregg 2013-09-30 19:45:20 EDT
This bug still seems to be around. 

After switching to:
policycoreutils-python-2.1.14-81.el7.x86_64
ipa-server-3.3.1-5.el7.x86_64

I no longer get the error 907 during client install, but the install still fails with very similar looking AVC's

type=AVC msg=audit(1380584149.400:221): avc:  denied  { write } for  pid=5955 comm="httpd" scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:httpd_t:s0 tclass=key
type=SYSCALL msg=audit(1380584149.400:221): arch=c000003e syscall=248 success=no exit=-13 a0=7ffb134e9b2e a1=7ffb22d3b240 a2=0 a3=0 items=0 ppid=5852 pid=5955 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=4294967295 comm="httpd" exe="/usr/sbin/httpd" subj=system_u:system_r:httpd_t:s0 key=(null)
type=AVC msg=audit(1380584149.401:222): avc:  denied  { write } for  pid=5955 comm="httpd" scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:httpd_t:s0 tclass=key
type=SYSCALL msg=audit(1380584149.401:222): arch=c000003e syscall=248 success=no exit=-13 a0=7ffb134e9b2e a1=7ffb23325570 a2=0 a3=0 items=0 ppid=5852 pid=5955 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=4294967295 comm="httpd" exe="/usr/sbin/httpd" subj=system_u:system_r:httpd_t:s0 key=(null)


I'll submit my install and audit logs for review.
Comment 26 Michael Gregg 2013-09-30 19:51:08 EDT
Created attachment 805630 [details]
audit log from install after eratta
Comment 27 Michael Gregg 2013-09-30 19:51:58 EDT
Created attachment 805631 [details]
client install log from after eratta
Comment 29 Martin Kosek 2013-10-01 02:40:26 EDT
Looks like a Bug 1012051 to me.
Comment 30 Scott Poore 2013-10-01 13:59:59 EDT
I'm seeing this fail again as well today:

[root@qe-blade-05 ~]# rpm -q policycoreutils
policycoreutils-2.1.14-81.el7.x86_64
[root@qe-blade-05 ~]# rpm -q selinux-policy
selinux-policy-3.12.1-84.el7.noarch
[root@qe-blade-05 ~]# getenforce 
Permissive
[root@qe-blade-05 ~]# getsebool -a|grep -i httpd_can_network_connect
httpd_can_network_connect --> off
httpd_can_network_connect_cobbler --> off
httpd_can_network_connect_db --> off
[root@qe-blade-05 ~]# getsebool -a|grep -i httpd_manage_ipa
httpd_manage_ipa --> off
[root@qe-blade-05 ~]# /usr/sbin/setsebool -P httpd_can_network_connect=on httpd_manage_ipa=on
Boolean httpd_can_network_connect is not defined

The above was run after ipa-server-install was run.  From ipaserver-install.log:

2013-10-01T17:30:37Z DEBUG args=/usr/sbin/setsebool -P httpd_can_network_connect=on httpd_manage_ipa=on
2013-10-01T17:30:37Z DEBUG Process finished, return code=255
2013-10-01T17:30:37Z DEBUG stdout=
2013-10-01T17:30:37Z DEBUG stderr=Boolean httpd_can_network_connect is not defined

2013-10-01T17:30:37Z DEBUG WARNING: could not set the following SELinux boolean(s):
  httpd_can_network_connect -> on
  httpd_manage_ipa -> on
The web interface may not function correctly until the booleans
are successfully changed with the command:
/usr/sbin/setsebool -P httpd_can_network_connect=on httpd_manage_ipa=on
Try updating the policycoreutils and selinux-policy packages.
2013-10-01T17:30:37Z DEBUG   duration: 0 seconds
Comment 31 Scott Poore 2013-10-01 16:09:01 EDT
Ok, I'm able to manually reproduce this one manually with the following:

[root@rhel7-1 ~]#  /usr/sbin/setsebool -P httpd_can_network_connect=on httpd_manage_ipa=on

[root@rhel7-1 ~]# echo $?
255

[root@rhel7-1 ~]# rpm -q policycoreutils selinux-policy
policycoreutils-2.1.14-81.el7.x86_64
selinux-policy-3.12.1-84.el7.noarch

[root@rhel7-1 ~]# getsebool -a |egrep "httpd_can_network_connect|httpd_manage_ipa"
httpd_can_network_connect --> off
httpd_can_network_connect_cobbler --> off
httpd_can_network_connect_db --> off
httpd_manage_ipa --> off

So, is this a different issue than previously believed?

What other information is needed to troubleshoot and resolve this?

Thanks,
Scott
Comment 32 Scott Poore 2013-10-02 18:11:02 EDT
Dan,

Can we get an estimate for when this will be fixed?

Our workaround seems to have failed us in an automated test I ran earlier today:

:: [ 16:26:59 ] ::  force setting selinux booleans for ipa install failure
libsemanage.semanage_read_policydb: Could not open kernel policy /etc/selinux/targeted/modules/active/policy.kern for reading. (No such file or directory).
ValueError: Could not test MLS enabled status

:: [   FAIL   ] :: Running '/usr/sbin/semanage boolean --modify --on httpd_can_network_connect' (Expected 0, got 1)
libsemanage.semanage_read_policydb: Could not open kernel policy /etc/selinux/targeted/modules/active/policy.kern for reading. (No such file or directory).
ValueError: Could not test MLS enabled status

:: [   FAIL   ] :: Running '/usr/sbin/semanage boolean --modify --on httpd_manage_ipa' (Expected 0, got 1)

Version:

policycoreutils-2.1.14-81.el7.x86_64
selinux-policy-3.12.1-84.el7.noarch

I'm re-running that test now to see if it occurs again.  Does that error need a separate bug or is it related here?

Thanks,
Scott
Comment 33 Miroslav Grepl 2013-10-03 04:39:55 EDT
Any chance to re-test it with the latest builds.

selinux-policy,policycoreutils,libsemanage.

I believe it should work correctly.
Comment 34 Scott Poore 2013-10-03 16:00:06 EDT
This is from a test today.

[root@qe-blade-12 ~]# rpm -q selinux-policy policycoreutils libsemanage
selinux-policy-3.12.1-85.el7.noarch
policycoreutils-2.1.14-81.el7.x86_64
libsemanage-2.1.10-12.el7.x86_64

[root@qe-blade-12 ~]# less /var/log/ipaserver-install.log
...
2013-10-03T15:52:06Z DEBUG args=/usr/sbin/setsebool -P httpd_can_network_connect=on httpd_manage_ipa=on
2013-10-03T15:52:06Z DEBUG Process finished, return code=255
2013-10-03T15:52:06Z DEBUG stdout=
2013-10-03T15:52:06Z DEBUG stderr=Boolean httpd_can_network_connect is not defined

2013-10-03T15:52:06Z DEBUG WARNING: could not set the following SELinux boolean(s):
  httpd_can_network_connect -> on
  httpd_manage_ipa -> on
The web interface may not function correctly until the booleans
are successfully changed with the command:
/usr/sbin/setsebool -P httpd_can_network_connect=on httpd_manage_ipa=on
Try updating the policycoreutils and selinux-policy packages.
...

[root@qe-blade-12 ~]# getenforce
Permissive

[root@qe-blade-12 ~]# /usr/sbin/setsebool -P httpd_can_network_connect=on httpd_manage_ipa=on
Boolean httpd_can_network_connect is not defined

[root@qe-blade-12 ~]# getsebool -a |egrep "httpd_can_network_connect|httpd_manage_ipa"
httpd_can_network_connect --> off
httpd_can_network_connect_cobbler --> off
httpd_can_network_connect_db --> off
httpd_manage_ipa --> off

So, what else can we check?
Comment 36 Daniel Walsh 2013-10-04 09:33:51 EDT
policycoreutils-2.1.14-84.el7 is now in rhel7
Comment 37 Scott Poore 2013-10-04 19:56:37 EDT
This still does not appear to be fixed:

[root@ipaqa64vmd ~]# setenforce 1

[root@ipaqa64vmd ~]# /usr/sbin/setsebool -P httpd_can_network_connect=on httpd_manage_ipa=on
Boolean httpd_can_network_connect is not defined

[root@ipaqa64vmd ~]# setenforce 0

[root@ipaqa64vmd ~]# /usr/sbin/setsebool -P httpd_can_network_connect=on httpd_manage_ipa=on
Boolean httpd_can_network_connect is not defined

[root@ipaqa64vmd ~]# getsebool -a |egrep "httpd_can_network_connect|httpd_manage_ipa"
httpd_can_network_connect --> off
httpd_can_network_connect_cobbler --> off
httpd_can_network_connect_db --> off
httpd_manage_ipa --> off

[root@ipaqa64vmd ~]# /usr/sbin/setsebool -P httpd_can_network_connect=on httpd_manage_ipa=on
Boolean httpd_can_network_connect is not defined

[root@ipaqa64vmd ~]# rpm -q policycoreutils selinux-policy libsemanage
policycoreutils-2.1.14-84.el7.x86_64
selinux-policy-3.12.1-86.el7.noarch
libsemanage-2.1.10-12.el7.x86_64

I'll also attach an strace in case that helps here.
Comment 38 Scott Poore 2013-10-04 20:06:44 EDT
Created attachment 807991 [details]
strace from setsebool command
Comment 39 Miroslav Grepl 2013-10-07 08:43:12 EDT
I see

# rpm -q policycoreutils
policycoreutils-2.1.14-84.el7.x86_64

# getsebool httpd_can_network_connect
httpd_can_network_connect --> on

# /usr/sbin/setsebool -P httpd_can_network_connect=off
# echo $?
0

# getsebool httpd_can_network_connect
httpd_can_network_connect --> off

So it works for me.

Michal,
could you also check it?
Comment 40 Scott Poore 2013-10-07 12:43:22 EDT
Looks like it's working again with a build from the latest repos from this morning:

[root@dell-pem805-01 ~]# rpm -q policycoreutils selinux-policy libsemanage
policycoreutils-2.1.14-84.el7.x86_64
selinux-policy-3.12.1-86.el7.noarch
libsemanage-2.1.10-13.el7.x86_64

[root@dell-pem805-01 ~]# setsebool -P httpd_can_network_connect=on 

[root@dell-pem805-01 ~]# echo $?
0

[root@dell-pem805-01 ~]# getsebool -a |grep httpd_can_network_connect
httpd_can_network_connect --> on
httpd_can_network_connect_cobbler --> off
httpd_can_network_connect_db --> off

So, not sure if the updates to libsemanage affected this or if it was a result of the build that's now resolved in the latest.

Going back to doublecheck Friday's failure, it looks like I had this version of libselinux:

libselinux-2.1.13-16.el7.x86_64

While now, I have:

libselinux-2.1.13-21.el7.x86_64

Was something updated there that could have caused the failure I saw in comment #37?

Thanks,
Scott
Comment 41 Daniel Walsh 2013-10-07 13:06:51 EDT
Well libselinux/policycoreutils/libsemanage could all be involved with this.
Comment 42 Scott Poore 2013-10-07 13:50:57 EDT
Well, looks better now.  I just ran a full IPA server install without the semanage workarounds and it looks good.

I'm guessing my recent previous failures may have had something to do with the repos I was pointing to missing some updates.

Thanks,
Scott
Comment 44 Scott Poore 2013-10-21 17:07:58 EDT
Miroslav, Michal, 

What's the status here?  When I test this from a VM just built from a rhel7 repo, I am still seeing this error.

Also, in a training class we have today, we're seeing this in VMs that were built for the class.

Thanks,
Scott
Comment 45 Miroslav Grepl 2013-10-25 03:50:59 EDT
This will be a problem with old versions, I guess.
Comment 46 Scott Poore 2013-10-25 11:13:36 EDT
It does finally look like the repos built on 10/24 seem to be fixed:

[root@vm1 ~]# getsebool httpd_can_network_connect
httpd_can_network_connect --> off

[root@vm1 ~]# rpm -qa|egrep "policy|selinux|semanage"|sort
libselinux-2.1.13-21.el7.x86_64
libselinux-python-2.1.13-21.el7.x86_64
libselinux-utils-2.1.13-21.el7.x86_64
libsemanage-2.1.10-14.el7.x86_64
policycoreutils-2.1.14-88.el7.x86_64
selinux-policy-3.12.1-94.el7.noarch
selinux-policy-targeted-3.12.1-94.el7.noarch

[root@vm1 ~]# setsebool -P httpd_can_network_connect=on

[root@vm1 ~]# 

Thanks
Comment 48 Ludek Smid 2014-06-13 09:17:02 EDT
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.