Bug 877318 - Unable to delete servers from Satellite with SELinux in Enforcing Mode
Unable to delete servers from Satellite with SELinux in Enforcing Mode
Status: CLOSED DEFERRED
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Other (Show other bugs)
550
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Jan Pazdziora
Red Hat Satellite QA List
:
Depends On:
Blocks: 462714
  Show dependency treegraph
 
Reported: 2012-11-16 03:57 EST by Stephen Benjamin
Modified: 2015-05-29 16:09 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-05-29 16:09:43 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)
When seboolean cobbler_can_network_connect is true (5.65 KB, text/plain)
2012-11-22 06:57 EST, Stephen Benjamin
no flags Details
Strace when cobbler_can_network_connect is false (31.55 KB, text/plain)
2012-11-22 06:57 EST, Stephen Benjamin
no flags Details

  None (edit)
Description Stephen Benjamin 2012-11-16 03:57:18 EST
Description of problem:
Unable to delete system from Satellite GUI. cobbler_can_network_connect needs to be set to on.

Version-Release number of selected component (if applicable):
RHNS 5.5.0


How reproducible:
Always

Steps to Reproduce:
1. Install Satellite 5.5 on RHEL 6.3 with SELinux enforcing
2. Register a new server
3. Attempt to delete server in web interface
  
Actual results:
Internal Server Error: "System profile 1000010000 could not be deleted."

Expected results:
Server is deleted.

Additional info:

Reviewing audit.log I noticed:

type=AVC msg=audit(1353055560.084:55545): avc:  denied  { name_connect } for  pid=3276 comm="cobblerd" dest=53 scontext=unconfined_u:system_r:cobblerd_t:s0 tcontext=syste m_u:object_r:dns_port_t:s0 tclass=tcp_socket

After executing:
setsebool cobbler_can_network_connect true

I am able to delete the server from Satellite, and I stop getting e-mails about cobbler sync failing.
Comment 1 Jan Pazdziora 2012-11-16 09:16:01 EST
What does

rpm -q cobbler

return?
Comment 2 Stephen Benjamin 2012-11-16 09:42:25 EST
cobbler-2.0.7-21.el6sat.noarch
Comment 3 Jan Pazdziora 2012-11-16 09:54:38 EST
Thanks! The problem is this is by no means deterministic -- we did not see this behaviour on other installations.

Could you strace that cobblerd to see what operation (and at what point) it tries to do?

What is in your /etc/hosts?

Would adding FQDN to /etc/hosts prevent it from trying to reach the DNS server?
Comment 4 Stephen Benjamin 2012-11-16 10:23:27 EST
I tried it twice before I opened the bug and both machines failed.  Now, I've turned off cobbler_can_network_connect (and restarted satellite).  Deleting a system is still successful.

The Satellite server itself is not in /etc/hosts, which makes me think that Satellite was trying to resolve the satellite hostname, which failed because it required network connectivity, but now, it's already cached.

So, it seems, my mistake for not having FQDN in /etc/hosts.  However, is that a requirement for RHNS?
Comment 5 Jan Pazdziora 2012-11-16 10:30:20 EST
(In reply to comment #4)
> I tried it twice before I opened the bug and both machines failed.  Now,
> I've turned off cobbler_can_network_connect (and restarted satellite). 
> Deleting a system is still successful.
> 
> The Satellite server itself is not in /etc/hosts, which makes me think that
> Satellite was trying to resolve the satellite hostname, which failed because
> it required network connectivity, but now, it's already cached.

Where would it be cached?

> So, it seems, my mistake for not having FQDN in /etc/hosts.  However, is
> that a requirement for RHNS?

Checking the documentation, it is not. I'm pretty certain we had that requirement in the past.

If you are able to reproduce the issue, we'd still love to see the strace from that cobblerd process, to figure out at which stage this happens.
Comment 6 Stephen Benjamin 2012-11-19 10:21:08 EST
Right, I thought maybe urllib2 or whatever cobbler was using had some short term internal DNS cache, but I tried to reproduce it today, and couldn't.  Seems like it was just a fluke.
Comment 7 Stephen Benjamin 2012-11-22 06:57:30 EST
Created attachment 649737 [details]
When seboolean cobbler_can_network_connect is true
Comment 8 Stephen Benjamin 2012-11-22 06:57:50 EST
Created attachment 649738 [details]
Strace when cobbler_can_network_connect is false
Comment 9 Stephen Benjamin 2012-11-22 06:58:49 EST
It happened again, this time while trying to get a list of kickstarts.  I clicked Systems tab, then Kickstarts, and then Profiles and got an internal server error.

Cobbler was trying to do some kind of DNS lookup:

type=AVC msg=audit(1353585004.742:66749): avc:  denied  { name_connect } for  pid=14375 comm="cobblerd" dest=53 scontext=system_u:system_r:cobblerd_t:s0 tcontext=system_u:object_r:dns_port_t:s0 tclass=tcp_socket

I have an strace: cobbler_failure.txt when the seboolean cobbler_can_network_connect was set to false, cobbler_success.txt when cobbler_can_network_connect is true.  

The list of kickstarts worked when it was true.  So, it seems it's not exactly predictable when cobbler will attempt to do this, because I've probably tried to bring up the list of kickstarts 50 times in the last two weeks, all successfully until now.  Cobbler does seem to need the ability to DNS lookups.
Comment 10 Jan Pazdziora 2012-11-22 07:39:50 EST
(In reply to comment #7)
> Created attachment 649737 [details]
> When seboolean cobbler_can_network_connect is true

There's not connect in the output. You probably want to strace with the -f option.

Note You need to log in before you can comment on or make changes to this bug.