Как эффективно управлять файлом crontab, чтобы избежать проблем, связанных с многочисленными обновлениями, выполняемыми несколькими пользователями?

Как эффективно управлять файлом crontab, чтобы избежать проблем, связанных с многочисленными обновлениями, выполняемыми несколькими пользователями?

У меня есть crontab, который включает в себя множество пользователей, обновляющих его. Проблема в том, что из-за этого нелегко узнать, кто сделал какую модификацию cronjob.

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

решение1

Подрывная деятельность

Я бы поместил содержимое crontab под контроль subversion и предоставил бы доступ только этому пользователю через sudo. В частности, я бы разрешил людям доступ к команде a через , sudoкоторая бы взяла head из subversion и установила бы ее как последний crontab для этого конкретного пользователя. Это предоставит вам следующее:

  • Аудиторский след того, кто что сделал
  • Возможность отката к предыдущему файлу crontab в случае возникновения проблем
  • Оградите операторов от предоставления им слишком большого количества разрешений для этой специальной учетной записи.

Это может показаться слишком сложным, но в том, что я описал, нет ничего слишком сложного, если разбить это на небольшие части.

МультиКрон

Другой подход — использовать такой инструмент/скрипт, какМультиКронЭтот инструмент позволит вам управлять данными crontab, внешними по отношению к записи crontab, чтобы вы могли лучше контролировать, кто и когда имеет доступ к этим изменениям.

Пример использования Subversion

Предположим, вы настроили репозиторий SVN, и вы можете создать sudoзапись, которая позволит пользователям делать что-то вроде этого:

$ sudo deploy_app_cron.bash

Внутренности этого скрипта могли бы, среди прочего, делать следующее:

svn cat file:///home/saml/svnrepo/app_cron_data.txt | crontab -u saml -

Содержимое файла app_cron_data.txt:

$ svn cat file:///home/saml/svnrepo/app_cron_data.txt
*/5 * * * * /path/to/job -with args"

Пример использования цикла

Итак, пользователь A хочет обновить запись в crontab. Для начала он сделает следующее:

$ cd $HOME/somedir
$ svn co file:///home/saml/svnrepo/ mywksp
A    mywksp/app_cron_data.txt
$ cd mywksp

Теперь они вносят некоторые изменения в файл crontab app_cron_data.txtи, когда они готовы, помещают их в репозиторий.

$ svn commit -m "some msg.." app_cron_data.txt

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

$ sudo deploy_app_cron.bash

Рекомендации

решение2

Ну, правильным решением будет правильно использовать cron и позволить каждому пользователю иметь свой собственный crontab для каждого пользователя. Есть ли какая-то упущенная причина, по которой вы настраиваете crontab таким образом? Возможно, даже предпочтительнее использовать crontab для каждого пользователя и какой-то другой обходной путь для всего, что этот "унифицированный crontab" призван преодолеть... ?

Связанный контент