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

Question

В настоящее время мы выполняем обновление с 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)

Answer 1

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

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

Answer 2

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

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

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

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

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

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