-
-
Notifications
You must be signed in to change notification settings - Fork 883
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CentOS 6.6 Nginx and SELinux Issue #496
Comments
There is a forum post about it on CentOS's forums as well, here is the link to it. |
Is this a problem with the module's configuration of nginx? I'm aware of SELinux and what it's for but have no experience with it. Also as suggested in the forum did you try the EPEL version of nginx? Or are you using the version from nginx.org? As you said this looks like a SELinux issue rather than an issue with this module, so I'm not sure what action we can take to resolve the problem here? |
Yes, even with EPEL version the error persists. #Configure SELinux to allow nginx file { 'Creating Nginx Policy for SELinux': nginx.te is the one I wrote above. |
Thanks for the code... however this has more to do with SELinux and this module. Glad you were able to solve it for your environment! |
After upgrading CentOS to 6.6, SELinux started to prevent nginx to do hostname lookups and reloads.
This is my code,
class { 'nginx': }
nginx::resource::upstream { 'gunicorn-graphite-web':
ensure => present,
members => [
'mon01:7777',
],
}
nginx::resource::vhost { 'gunicorn-graphite':
listen_options => 'default_server',
listen_port => 80,
ensure => present,
server_name => ['mon01'],
proxy => 'http://gunicorn-graphite-web',
access_log => '/var/log/nginx/gunicorn-graphite.access.log',
error_log => '/var/log/nginx/gunicorn-graphite.error.log',
notify => Service['nginx'],
}
It fails to do vagrant up like this;
==> mon01: Error: Could not start Service[nginx]: Execution of '/sbin/service nginx start' returned 1: Starting nginx: [FAILED]
==> mon01: Wrapped exception:
==> mon01: Execution of '/sbin/service nginx start' returned 1: Starting nginx: [FAILED]
==> mon01: Error: /Stage[main]/Nginx::Service/Service[nginx]/ensure: change from stopped to running failed: Could not start Service[nginx]: Execution of '/sbin/service nginx start' returned 1: Starting nginx: [FAILED]
When I ssh into it, this is the error.log at "/var/log/nginx/error.log"
2014/10/30 11:51:29 [emerg] 9380#0: host not found in upstream "mon01:7777" in /etc/nginx/conf.d/gunicorn-graphite-web-upstream.conf:3
If I do setenforce 0, it starts to work normally, which means it's a SELinux problem.
If I change mon01 to 127.0.0.1, vagrant up works without errors but I get a 502 bad gateway.
When I ssh into it, this is the error.log at "/var/log/nginx/error.log"
2014/10/30 12:40:09 [alert] 9412#0: setrlimit(RLIMIT_NOFILE, 1024) failed (13: Permission denied)
And I have another log this time which is "/var/log/nginx/gunicorn-graphite.error.log" and it is
2014/10/30 12:40:22 [crit] 9412#0: *1 connect() to 127.0.0.1:7777 failed (13: Permission denied) while connecting to upstream, client: 10.0.2.2, server: mon01, request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:7777/", host: "localhost:5280"
2014/10/30 12:40:22 [crit] 9412#0: *1 connect() to 127.0.0.1:7777 failed (13: Permission denied) while connecting to upstream, client: 10.0.2.2, server: mon01, request: "GET /favicon.ico HTTP/1.1", upstream: "http://127.0.0.1:7777/favicon.ico", host: "localhost:5280"
I can fix this with the following from command line,
grep nginx /var/log/audit/audit.log | audit2allow -m nginx > nginx.te
grep nginx /var/log/audit/audit.log | audit2allow -M nginx
semodule -i nginx.pp
nginx.te is created by the audit2allow and contains the following;
module nginx 1.0;
require {
type httpd_t;
type port_t;
class process setrlimit;
class tcp_socket name_connect;
}
============= httpd_t ==============
!!!! This avc can be allowed using one of the these booleans:
allow_ypbind, httpd_can_network_connect
allow httpd_t port_t:tcp_socket name_connect;
!!!! This avc can be allowed using the boolean 'httpd_setrlimit'
allow httpd_t self:process setrlimit;
This problem started to happen when CentOS upgraded to 6.6.
The text was updated successfully, but these errors were encountered: