Почему nginx не может получить доступ к сокету Puma на CentOS 7?
Так что у меня есть приложение Ruby on Rails в /var/www/
принадлежит nginx
с 755
разрешения. Указанное приложение предназначено для развертывания через Puma.
Вот так:
rvmsudo -u nginx bundle exec puma -e production -d -b unix:///var/www/my_app/tmp/sockets/my_app.socket
Разрешения для сокета:
srwxrwxrwx. 1 nginx nginx 0 Nov 6 09:43 tmp/sockets/my_app.sock
Этот процесс, конечно же, принадлежит nginx:
nginx 7335 0.0 8.8 536744 90388 ? Sl 09:43 0:00 puma 2.9.2 (unix:///var/www/my_app/tmp/sockets/my_app.sock)
мой nginx
Конфигурация конфигурации выглядит следующим образом:
upstream my_app {
server unix:///var/www/my_app/tmp/sockets/my_app.sock;
}
server {
listen 80;
server_name www.example.com example.com;
root /var/www/my_app/public;
location / {
proxy_pass http://my_app;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
Все это и мое приложение по-прежнему отказано в разрешениях.
connect() to unix:///var/www/my_app/tmp/sockets/my_app.sock failed (13: Permission denied) while connecting to upstream,
Я пробовал все это как пользователь root, а также. Но это все равно не работает.
Кто-нибудь знает, что я делаю не так?
1 ответ
Аллилуйя! Все это оказалось проблемой политики SELinux, относящейся к nginx. После нескольких часов копания я обнаружил такие отрицания, запустив:
sudo grep nginx /var/log/audit/audit.log
Сообщения выглядели так:
type=AVC msg=audit(1415283617.227:1386): avc: denied { write } for pid=1683 comm="nginx" name="my_app.sock" dev="tmpfs" ino=20657 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:var_run_t:s0 tclass=sock_file
Чтобы это исправить, я нашел замечательную статью Axilleas.
Чтобы создать политику, содержащую необходимые разрешения, мне пришлось установить audit2allow
и запустить:
grep nginx /var/log/audit/audit.log | audit2allow -M nginx
После этого я доработал политику:
semodule -i nginx.pp
К сожалению, мне пришлось дважды выполнить этот процесс, прежде чем я смог получить доступ к своему приложению, потому что требовались дополнительные политики. Тем не менее, здесь было решение.
Также есть еще одна приятная статья Сергея Крылькова.
Мораль этой истории: выучи SELinux.