Logrotate більше не зчитує файл конфігурації, що посилається на зв’язок, через право власності не на root

15

Зараз ми переходимо від Ubuntu 12.04 LTS до 14.04 LTS на нашому рубіні на серверах додатків рейлів, і помітили, що файли журналів більше не обертаються.

На обох машинах у нас є файл, що /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 ми маємо логротат 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 )

ubuntu permissions logrotate

— фантомний кит
джерело

Гарне питання! Я бачу, що пізніше була певна дискусія щодо перевірки імені користувача "root" замість uid == 0, але це також не викликало питання, чому потрібне право власності на root.

— agtoever

6

Проблема полягає в тому, що файл конфігурації logrotate може виконувати будь-яку команду як корінь (використовуючи prerotate / postrotate строфи). Отже, ви фактично надаєте deployerкористувачеві привілеї root, надаючи їм доступ до файлів у /etc/logrotate.d/. Так ні, це не помилка.

Якщо ви довіряєте користувачеві, що розгортається, то, мабуть, ви могли б вирішити проблему, надавши йому права sudo на копіювання файлів у /etc/logrotate.d/ . Припустимо, звичайно, що користувач-розгортальник - це не той самий користувач, яким працює веб-додаток.

— гранули
джерело

Наш підхід завжди вважав за краще передати посилання з каталогів, що знаходяться поза додатком, у файли прикладних програм, так що кожен розгортання не тільки виштовхує нову програму, але і будь-які зміни файлів конфігурації. Навіть надання розповсюджувачу прав на розгортання коду за межами каталогу додатків порушує цей підхід, але однаково необхідність пригнічувати файл програми, який належить кореневій власності після розгортання, теж погана справа (tm). Можливо, тому оригінальний підхід тому більше не може працювати з логротатом 3.8.0+

— phantomwhale

2

@phantomwhale Ваш оригінальний підхід неявно дав користувачеві розгортальника повні кореневі привілеї. Це не нове у логротаті 3.8. Якщо ви хочете обмежити права диспетчера, в той же час дозволяючи йому оновлювати конфігурацію, я думаю, вам потрібно використовувати щось інше, ніж логротат.

— пелет

2

Я усвідомлюю, що я запізнююся на вечірку, але у мене виникло подібне питання і я думав, що поділюсь своїм рішенням.

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

Спочатку я намагався запуститись logrotateяк користувач розгортання, але він скаржився на доступ до файла стану на/var/lib/logrotate/state . Потім я прочитав сторінку людини. Ви можете вказати файл стану, який logrotateвикористовує! Отже, мені здалося кращим рішенням встановити щоденний cron, який виконується logrotateяк користувач розгортання зі спеціальним файлом стану. Таким чином, користувач розгортання або програма не потребує кореневого доступу.

Ось як вказати файл стану:

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

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

— dayer4b
джерело