У меня есть crontab, который включает в себя множество пользователей, обновляющих его. Проблема в том, что из-за этого нелегко узнать, кто сделал какую модификацию cronjob.
Я думал создать скрипт для выполнения diff
crontab с ранее сохраненной версией, чтобы по крайней мере увидеть, что было изменено, но я подумал, что, возможно, есть стандартное решение для этого. Какой наилучший подход для управления моим 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" призван преодолеть... ?