Bug 1007606

Summary: ipa-server-install failing with fault 907 during ipa-client-install phase
Product: Red Hat Enterprise Linux 7 Reporter: Michael Gregg <mgregg>
Component: policycoreutilsAssignee: Daniel Walsh <dwalsh>
Status: CLOSED CURRENTRELEASE QA Contact: David Spurek <dspurek>
Severity: high Docs Contact:
Priority: urgent    
Version: 7.0CC: ajes+redhat, dspurek, dwalsh, ebenes, jpazdziora, mgregg, mgrepl, misterbot, mkosek, mtruneck, rcritten, spoore
Target Milestone: rcKeywords: TestBlocker
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-06-13 13:17: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:
Attachments:
Description Flags
CLI output from running ipa-server-install
none
offending client install log
none
audit log from install after eratta
none
client install log from after eratta
none
strace from setsebool command none

Description Michael Gregg 2013-09-12 23:05:38 UTC
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 23:07:06 UTC
Created attachment 797057 [details]
offending client install log

Comment 4 Rob Crittenden 2013-09-13 01:27:58 UTC
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 19:07:09 UTC
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 21:10:20 UTC
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 21:40:27 UTC
Scott, are you seeing the same AVC?

Comment 9 Scott Poore 2013-09-13 21:44:12 UTC
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 22:01:03 UTC
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 23:49:50 UTC
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 23:55:17 UTC
Also, I did setenforce 0 before a test that was failing and install worked without a problem.

Comment 13 Martin Kosek 2013-09-16 11:43:08 UTC
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 14:40:19 UTC
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 16:58:49 UTC
Need me to also post entire ipaserver-install.log?

Comment 16 Martin Kosek 2013-09-17 06:29:18 UTC
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 11:49:26 UTC
Dan
I sent you a patch for this issue.

Comment 18 Scott Poore 2013-09-19 00:29:58 UTC
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 07:25:07 UTC
(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 14:25:27 UTC
Hi Dan,

Is this going to be fixed soon for RHEL7?

Thanks,
Scott

Comment 21 Daniel Walsh 2013-09-23 15:56:35 UTC
I need flags in order to build.

Fixed in /policycoreutils-2.1.14-81.el7

Comment 22 Martin Kosek 2013-09-24 07:26:11 UTC
We have the flags now, can we please build now to unblock IPA QE?

Comment 23 Scott Poore 2013-09-25 18:01:29 UTC
*** Bug 1011164 has been marked as a duplicate of this bug. ***

Comment 25 Michael Gregg 2013-09-30 23:45:20 UTC
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 23:51:08 UTC
Created attachment 805630 [details]
audit log from install after eratta

Comment 27 Michael Gregg 2013-09-30 23:51:58 UTC
Created attachment 805631 [details]
client install log from after eratta

Comment 29 Martin Kosek 2013-10-01 06:40:26 UTC
Looks like a Bug 1012051 to me.

Comment 30 Scott Poore 2013-10-01 17:59:59 UTC
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 20:09:01 UTC
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 22:11:02 UTC
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 08:39:55 UTC
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 20:00:06 UTC
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 13:33:51 UTC
policycoreutils-2.1.14-84.el7 is now in rhel7

Comment 37 Scott Poore 2013-10-04 23:56:37 UTC
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-05 00:06:44 UTC
Created attachment 807991 [details]
strace from setsebool command

Comment 39 Miroslav Grepl 2013-10-07 12:43:12 UTC
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 16:43:22 UTC
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 17:06:51 UTC
Well libselinux/policycoreutils/libsemanage could all be involved with this.

Comment 42 Scott Poore 2013-10-07 17:50:57 UTC
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 21:07:58 UTC
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 07:50:59 UTC
This will be a problem with old versions, I guess.

Comment 46 Scott Poore 2013-10-25 15:13:36 UTC
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 13:17:02 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.