Я использую CentOS, NGINX и Passenger для обслуживания приложения Rails. У меня активирован SELinux, и у меня возникла серия проблем с logrotate. Я смог решить большинство проблем, следуя различным советам в Интернете. К сожалению, logrotate не выполняет ротацию моих файлов журналов NGINX. NGINX установлен в / opt / nginx
Это мой файл конфигурации logrotate:
/opt/nginx/logs/*log {
daily
rotate 30
missingok
notifempty
sharedscripts
delaycompress
postrotate
[ ! -f /opt/nginx/logs/nginx.pid ] || kill -USR1 `cat /opt/nginx/logs/nginx.pid`
endscript
}
Это сообщения, которые я получаю в / var / log / messages
Mar 9 03:49:14 localhost setroubleshoot: SELinux is preventing /usr/sbin/logrotate from rename access on the file logrotate_temp.RTg4y3. For complete SELinux messages. run sealert -l 8c5238cd-3e95-4af6-b150-498080c862b8
Mar 9 03:49:14 localhost setroubleshoot: SELinux is preventing /usr/sbin/logrotate from rename access on the file logrotate_temp.OjvGsG. For complete SELinux messages. run sealert -l 8c5238cd-3e95-4af6-b150-498080c862b8
Mar 10 03:55:46 localhost logrotate: ALERT exited abnormally with [1]
Я пробовал использовать sealert чтобы обновить политики в соответствии с рекомендациями сообщений, однако это не решает проблему (я подозреваю, что это может быть связано с тем, что временные файлы всегда имеют разные имена).
Может ли кто-нибудь предложить, как я могу решить эту проблему, чтобы файлы журналов были успешно повернуты.
- EDIT - добавлен вывод
sudo sealert -l 8c5238cd-3e95-4af6-b150-498080c862b8
:
SELinux is preventing /usr/sbin/logrotate from rename access on the file logrotate_temp.NuwGkX.
***** Plugin catchall (100. confidence) suggests ***************************
If you believe that logrotate should be allowed rename access on the logrotate_temp.NuwGkX file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep logrotate /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp
Я обнаружил, что проблема заключалась в паре старых (повернутых) файлов журнала.
Бег ls --scontext в каталоге, где находится журнал, показал, что 2 из повернутых журналов не имеют var_log_t контекст.
Я исправил это, удалив именно эти файлы (им было несколько месяцев).
При следующем запланированном запуске журналы повернулись правильно.
Может ли это иметь какое-то отношение к тому факту, что вы не объявляете разрешения для файла управления Logrotate с чем-то вроде этого. (обратите внимание на строку create 0644 ....)
/var/log/nginx/*log {
create 0644 nginx nginx
daily
rotate 10
missingok
notifempty
compress
sharedscripts
postrotate
/bin/kill -USR1 `cat /run/nginx.pid 2>/dev/null` 2>/dev/null || true
endscript }