Чи слід редагувати / etc / crontab або запускати crontab -e як root?

43

Я налаштовую регулярні завдання з обслуговування системи, які повинні запускатися як root. Я планую використовувати аромат cron, який поставляється з Ubuntu 14.04 LTS за замовчуванням.

Я бачу, як попередній адміністратор (який покинув компанію) редагував / etc / crontab безпосередньо. Однак я розумію, що іншим можливим підходом було б використання crontab -eяк root. Чи є якісь переконливі аргументи для використання того чи іншого, чи це віддає перевагу?

linux cron ubuntu-14.04

— marcv81
джерело

9

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

— MadHatter підтримує Моніку

1

Я колись пішов набрати crontab -l (щоб перелічити crontab), але я ввів crontab -; помилково замість цього видалили мій crontab. Я багато чого навчився того дня.

— Дроворуб

64

Можливо, буде корисно зауважити, що завдання в особистому crontab ( crontab -e) завжди виконуються як їх власник, де /etc/crontabміститься додаткове обов'язкове <user>поле, що дозволяє адміністратору налаштувати завдання для запуску як позакористувацького користувача.

Редагування системного crontab або налаштування особистого crontab для root, ймовірно, трохи більш портативні, не притаманні певним дистрибутивам Linux і, можливо, зручніше людині підтримувати з усіма завданнями в одному файлі, але:

Особисто я віддаю перевагу третьому варіанту : для кожного запланованого завдання відмовтесь або

файл у /etc/cron.d/фрагменті крона
виконуваний файл (скрипт) у відповідному /etc/cron.[hourly |daily |weekly |monthly]каталозі.

Це простіше в сценарії (ви можете просто створити / перезаписати / видалити такі файли, і вам не доведеться гнатися за вміст одного файлу crontab), і це добре працює з інструментами управління конфігурацією, і саме це вже є менеджерами пакетів робити все одно.

Роботи / сценарії в /etc/cron.[hourly |daily |weekly |monthly]завжди виконуються як корінь, де фрагменти крона /etc/cron.d/дозволяють як встановити власний графік, так і працювати як інший користувач із тим самим обов'язковим <user>полем, яке знайдено в /etc/crontab.

— HBruijn
джерело

18

Недолік редагування /etc/crontabполягає в тому, що для оновлення cronпакета буде потрібно злиття . У вас немає такої проблеми, якщо ви просто додасте новий файл до одного з /etc/cron.*каталогів.

— kasperd

1

Вам слід додати, що в більшості дистрибутивів /etc/cron.[hourly |daily |weekly |monthly]зберігаються виконувані файли, а /etc/cron.dзберігаються кронти. Крім цього, +1.

— GnP

Я, безумовно, шанувальник cron. [Timing] каталоги, мені рідко потрібно щось більш детальне, ніж параметри comn. Хоча зауважте, що деякі дистрибутиви, зокрема Ubuntu, будуть мовчки ігнорувати скрипти з розширеннями файлів у цих папках (досить помилка в Інтернеті, враховуючи, що більшість людей додасть .sh, що, можливо, було виправлено в останніх дистрибутивах). Дуже складно розібратися, чому сценарії не працювали в такій ситуації - принаймні додавання до crontab гарантовано виконується.

— Гарграварр

15

Як найкраще я пам'ятаю, crontab -eмає додаткову перевагу в тому, що він перевіряє синтаксис crontab перед його встановленням, і помилиться та відновить попередній, якщо ви помилитесь. Таким чином, все, що раніше працювало, раптом не зупиниться, якщо ви неправильно зрозумієте синтаксис. Я думаю, що найкраща практика - це використовувати утиліти, як запуск, visudoа не редагування /etc/sudoersбезпосередньо.

— Гарграварр
джерело

2

+1 Хороший момент щодо перевірки синтаксису, хоча він визнає деякі синтаксичні помилки, він також далеко не дурний (тобто він із задоволенням дозволить вам ввести /etc/crontabрядок з іменем користувача у 6-му стовпчику). - Хоча я хотів би стверджувати, що використання інтерактивних інструментів не є «найкращою практикою» , вам слід автоматизувати такі інструменти, як Puppet / Salt / Ansible тощо, і не слід більше налаштовувати сервери вручну. З іншого боку, якщо ви старенька школа, то дійсно використовуйте свої інструменти.

— HBruijn

Ansible та інші хороші, якщо ви налаштовуєте 5+ серверів, але не варто клопоту лише за 1. Ви можете стверджувати, що за допомогою всього 1 сервера скрипт Ansible дає вам можливість відновити його однаково, коли він не виходить за 2 роки вниз, але в цей момент сценарій, ймовірно, більше не працюватиме через зміни дистрибутива / репост.

— marcv81

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

— Monty Harder

Не допомагає, якщо запускаєте скрипт, і в ньому є помилки, тому тестування сухого запуску не потрібно.

— mckenzm

@mckenzm погодився, але ви можете застосувати лише стільки ідіотів, які ви можете застосувати :)

— Гарграварр

2

Це дійсно стильове запитання, і тому ОС пропонує декілька методів. Просто будьте послідовні і не змішуйте та не співставляйте, якщо ви не хочете плутати когось іншого (або себе через деякий час, коли не маєте справу з системою) - якщо важко зрозуміти, які завдання насправді заплановані для всього хоста, це прагне закінчитися неприємними сюрпризами.

— rackandboneman
джерело

2

Для того, щоб бути впевненим у додаванні завдання cron, що вимагає конкретних прав користувача, я особисто використовую таку команду:

 # crontab -u <user> -e

Ви також можете додати sudo.

Як заявив @rackandboneman, не потрібно возитися з файлами /etc/cron.d/. Якщо справа стосується задач cron користувача, використовуйте функції crontabкоманди.

— аеснак
джерело

3

-1 Великим недоліком вищезазначеного є те, що користувач тепер може змінювати / видаляти / порушувати cronjob, що, як правило, не бажано, коли ви як адміністратор витратили свій цінний час на налаштування речей ... Також, коли користувач - це обліковий запис сервісу, і цей обліковий запис заблоковано / минув, служба продовжуватиме працювати, але особисті вкладки cron для заблокованих облікових записів зазвичай будуть відключені.

— HBruijn

Якщо вказаний тут користувач є загальнодоступним користувачем, таким як член середовища обслуговування громадських терміналів, ви маєте рацію. Однак якщо мова йде про користувача послуги / агента ... по-друге, це справді стосується стилю.

— аеснак