Разрешить SELinux syslog и logrotate обрабатывать файлы за пределами /var/log
Итак, после дополнительного расследования и просмотра журналов nginx выяснилось, что проблема была в SELinux. Выполнение шагов вhttp://alfredoroca.github.io/nginx/selinux/2017/03/13/Allowing-Nginx-to-use-a-Puma-Unicorn-UNIX-socket-with-SELinuxустранило проблему. Я опубликую их ниже для полноты.
$ sudo grep nginx /var/log/audit/audit.log | audit2allow -m nginx > nginx.te
$ cat nginx.te
# cat output
# require {
# type unconfined_t;
# type httpd_t;
# type httpd_sys_content_t;
# class sock_file write;
# class unix_stream_socket connectto;
# class capability2 block_suspend;
# }
#
# ============= httpd_t ==============
# allow httpd_t httpd_sys_content_t:sock_file write;
# allow httpd_t self:capability2 block_suspend;
# allow httpd_t unconfined_t:unix_stream_socket connectto;
$ checkmodule -M -m -o nginx.mod nginx.te
$ semodule_package -o nginx.pp -m nginx.mod
$ sudo semodule -i nginx.pp
$ sudo systemctl restart nginx
Вы можете пометить каталог журналов тем же ярлыком, что и /var/log. Затем вызовите restorecon, чтобы изменения вступили в силу.
semanage fcontext -a -t var_log_t /mnt/data/logs
restorecon /mnt/data/logs
Это будет работать до тех пор, пока фактические файлы в разделе /mnt/data/logsсоздаются с помощью rsyslog и ротируются с помощью logrotate. Возможно, вам придется пометить ваши $HOSTNAMEкаталоги; в зависимости от вашей настройки.
Чуть более правильный способ — создать собственную политику selinux, которая разрешает нужные вам операции. Это можно сделать автоматически с помощью соответствующих строк audit.logи инструмента audit2allow.
Другая возможность состоит в том, чтобы просто установить selinux в разрешительный режим для logrotate с помощью semanage permissive -a logrotate_t. И то же самое для rsyslog. Но это эффективно снимает системную -широкую защиту для logrotate и rsyslog, если один из них сошел с ума, поэтому я не рекомендую это делать.