Logrotate больше не читает символьный файл конфигурации из-за отсутствия прав root

3621
phantomwhale

В настоящее время мы обновляем Ubuntu 12.04 LTS до 14.04 LTS на нашем ruby ​​на серверах приложений rails и заметили, что файлы журнала больше не вращаются.

На обеих машинах у нас есть файл, /var/app-name/config/logrotateпринадлежащий нашему пользователю Unix, deployerкоторый содержит действительный файл logrotate следующим образом:

/var/app-name/log/*.log { daily rotate 365 delaycompress compress dateext dateformat -%Y%m%d missingok copytruncate }

Затем он помещается в /etc/logrotate.d/каталог какapp-name

На нашем сервере Ubuntu 12.04 у нас есть logrotate 3.7.8, который отлично работает. Он входит в var/app-name/log/каталог и вращает все файлы журнала

Но на сервере Ubuntu 14.04 у нас есть logrotate 3.8.7, который не вращает файлы журнала для нашего приложения.

Когда я отлаживаю это через, sudo logrotate -d -f /etc/logrotate/.confя получаю следующий вывод:

Ignoring /etc/logrotate.d/app-name because the file owner is wrong (should be root).

Преследуя это в коде, кажется, что это изменение было добавлено для потока выпуска 3.8.x: https://github.com/demands/logrotate/commit/b8ce386a969c60e5c8ee78023c24a1ba0aab1526

Если изменить владельца файла символическую ссылку, /var/app-name/config/logrotateчтобы rootзатем снова начинает работать. Но, учитывая, что этот файл является частью моего приложения и создан с помощью инфраструктуры развертывания capistrano, которую мы используем в этом состоянии, я бы предпочел не менять владельца, если раньше он работал нормально.

Итак, рекомендованные / поддерживаемые файлы конфигурации с символическими ссылками logrotate?

И если так, то должен ли он быть отказом от использования моего файла (принадлежащего deployer), который является символической ссылкой на /etc/logrotate.dкаталог, как ошибка?

Или есть другой рекомендуемый подход для ротации журнала для конкретного приложения?

(также спрашивается в Unix StackExchange )

14
Хороший вопрос! Я вижу, что позже было [некоторое обсуждение] (https://fedorahosted.org/logrotate/ticket/36) о проверке имени пользователя «root» вместо uid == 0, но также это не вызвало вопроса почему требуется владение root. agtoever 9 лет назад 0

2 ответа на вопрос

5
pelle

Проблема в том, что файл конфигурации logrotate может запускать любую команду от имени пользователя root (используя разделы prerotate / postrotate). Таким образом, вы фактически дадите deployerпользователю привилегии root, предоставив ему доступ для записи в файлы /etc/logrotate.d/. Так что нет, это не ошибка.

Если вы доверяете своему пользователю-установщику, то, я думаю, вы могли бы решить эту проблему, предоставив ему права sudo для копирования файлов в /etc/logrotate.d/. Разумеется, если предположить, что пользователь, выполняющий развертывание, не тот же пользователь, с которым работает веб-приложение.

Наш подход всегда заключался в том, чтобы отдавать предпочтение символической ссылке из каталогов, внешних по отношению к приложению, в файлы приложения, так что каждое развертывание не только выталкивает новое приложение, но также и любые изменения файла конфигурации. Даже предоставление развертывателю прав на развертывание кода за пределами каталога приложения нарушает этот подход, но в равной степени необходимость разбивать файл приложения на права после развертывания ощущается как плохая вещь (tm). Возможно, оригинальный подход больше не может хорошо работать с logrotate 3.8.0+ phantomwhale 9 лет назад 0
@phantomwhale Ваш оригинальный подход неявным образом предоставил пользователю развертывания полные привилегии root. Это не ново в logrotate 3.8. Если вы хотите ограничить права развертывателя, в то же время позволяя ему обновлять конфигурацию, тогда я думаю, что вам нужно использовать что-то другое, чем logrotate. pelle 9 лет назад 2
2
dayer4b

Я понимаю, что немного опаздываю на вечеринку, но у меня была похожая проблема, и я решил поделиться своим решением.

Мои проблемы начались, когда я logrotateне прочитал написанную мной конфигурацию. Я не хочу, чтобы развернуть новые конфигурации в папке, принадлежащей корню, потому что я не хочу, чтобы пользователь Deploy иметь корневой доступ к чему .

Сначала я пытался работать logrotateот имени пользователя развертывания, но он жаловался на доступ к файлу состояния по адресу /var/lib/logrotate/state. Затем я прочитал справочную страницу. Вы можете указать файл состояния, который logrotateиспользует! Поэтому мне показалось, что лучше настроить ежедневный cron для выполнения logrotateв качестве пользователя развертывания с пользовательским файлом состояния. Таким образом, пользователю или приложению не требуется root-доступ.

Вот как вы указываете файл состояния:

logrotate --state /path/to/status /path/to/custom_logrotate.conf

Теперь вы можете запустить logrotate как любой пользователь и владелец конфигурации, который вам нравится!

Похожие вопросы