Должен ли я отредактировать / 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>поле, позволяющее администратору настроить задание для запуска от имени пользователя без полномочий root.

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

Лично я предпочитаю третий вариант : для каждого запланированного падения

  • файл /etc/cron.d/с фрагментом cron
  • исполняемый файл (скрипт) в соответствующем /etc/cron.[hourly |daily |weekly |monthly]каталоге.

Это проще для сценария (вы можете просто создавать / перезаписывать / удалять такие файлы, и вам не нужно копаться в содержимом одного файла crontab), и это хорошо работает с инструментами управления конфигурацией, и это то, что менеджеры пакетов уже в любом случае

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

HBruijn
источник
18
Недостаток редактирования /etc/crontabзаключается в том, что слияние потребуется при каждом обновлении cronпакета. У вас нет этой проблемы, если вы просто добавляете новый файл в один из /etc/cron.*каталогов.
Касперд
1
Вы должны добавить, что в большинстве дистрибутивов /etc/cron.[hourly |daily |weekly |monthly]содержатся исполняемые файлы, в то время как /etc/cron.dхранятся crontabs. Кроме этого +1.
GnP
Я определенно фанат cron. [Сроки] каталогов, мне редко нужно что-то более гранулированное, чем параметры commn. Хотя обратите внимание, что некоторые дистрибутивы, в частности Ubuntu, будут молчаливо игнорировать сценарии с расширениями файлов в этих папках (довольно грубая ошибка, учитывая, что большинство людей добавили бы .sh, которая, возможно, была исправлена ​​в последних дистрибутивах). Очень сложно понять, почему скрипты не работают в такой ситуации - по крайней мере, добавление в crontab гарантированно будет выполнено.
Гарграварр
15

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

Gargravarr
источник
2
+1 Хорошее замечание о проверке синтаксиса, хотя он распознает некоторые синтаксические ошибки, но он также далек от надежного (то есть, он с радостью позволит вам ввести /etc/crontabстроку с именем пользователя в 6-м столбце). - Хотя я хотел бы утверждать, что использование интерактивных инструментов не является «наилучшей практикой» , вам следует автоматизировать работу с такими инструментами, как Puppet / Salt / Ansible и т. Д., И вам больше не следует настраивать серверы вручную. С другой стороны, если вы олдскульный, то действительно используйте свои инструменты.
HBruijn
Ansible и другие хороши, если вы конфигурируете 5+ серверов, но не стоит хлопот только за 1. Можно утверждать, что только с 1 сервером скрипт Ansible дает вам возможность перестроить его идентично, если он потерпит неудачу через 2 года, но в этот момент скрипт, скорее всего, больше не будет работать из-за изменений в дистрибутивах и репозиториях.
marcv81,
По этой причине я категорически не согласен с принятым ответом. Какие бы изменения ни делались, они должны проходить через этот процесс проверки как минимум один раз. Если затем скопировать строку из нового crontab и предоставить ее автоматизированному инструменту для распространения на другие серверы, то это лучшее из обоих миров.
Монти Хардер
Не помогает при запуске скрипта, и в скрипте есть ошибки, поэтому в любом случае требуется тестирование без пробега.
Маккензм
@mckenzm согласился, но вы можете применить только столько защиты от идиотов :)
Gargravarr
2

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

rackandboneman
источник
2

Чтобы быть уверенным в добавлении задания cron, которое требует определенных прав пользователя, я лично использую следующую команду:

 # crontab -u <user> -e

Вы sudoтоже можете добавить .

Как сказал @rackandboneman, нет необходимости связываться с файлами /etc/cron.d/. Если речь идет о заданиях пользователя cron, используйте функции crontabкоманды.

aesnak
источник
3
-1 Большим недостатком вышеописанного является то, что пользователь теперь может также изменять / удалять / разбивать cronjob, что обычно нежелательно, когда вы, как администратор, тратите свое драгоценное время на настройку ... Также, когда Пользователь является учетной записью службы, и эта учетная запись заблокирована / истекла, служба продолжит работу, но личные вкладки cron для заблокированных учетных записей обычно отключаются.
HBruijn
Если пользователь, указанный здесь, является публичным пользователем, таким как участник общедоступной терминальной сервисной среды, вы правы. Однако, если речь идет о пользователе службы / агента ... если подумать, то это действительно стиль.
Aesnak