> и чтобы меньше было шансов нечаянно просрать/поломать при переносе сервиса или апгрейде - потому что конфиги в /etc ты точно не забудешь, а вот "юзерские кронтабы" на машине где нет никаких настоящих юзеров на раз.
> Впрочем, некоторые и на машине с юзерами ухитряются - "ой, а у юзера есть еще что-то кроме хомяка, надо же?!" facepalm.jpg
Но с оратором согласен, несмотря на "офигительную" аргументацию, использовать юзерские кронтабы для псевдопользователй - абсурд.
> А теперь расскажи, почему у тебя лопается пукан от правок в /etc/crontab - тоже сед не умеешь, каждый раз мучаешься с ee? [вот тебя на моих-то системах облом так облом ждет]
Я не Тигар, но можно я отвечу? У меня просто лопается пукан от правок /etc/crontab sed'ом, не могу молчать. И я сейчас не про "single file vs conf.d/".
1) ee - это типа как nano, да? Сорян, за всё время использования bsd запускал это ужос раза 2 примерно. А nano-юзерам я, будучи аутсорсером, прописывал в .bashrc что-то типа alias nano="rm -f". Если бы не WITHOUT_EE, я бы поступал с ним так же. vim - наше всё, vi тоже сойдёт, если почему-то порты/пакеты ставить нет возможности.
2) Что понимается под правкой crontab sed'ом? Почему именно им вообще? Это типа Ъ и по-какерски? А если я, например, python'ом или perl'ом, или awk'ом - это Ъ или нет?.. Отвлёкся, простите. Так что под этим понимается? Обновление конфигов в продакшене, на боевых серверах? Использование sed'а вместо интерактивного текстового редактора на локалхосте? Что?
3) Какой вообще критерий оценки трушности подхода?
> вот тебя на моих-то системах облом так облом ждет
А тебя на моих. Потому что через ~3-7min после того, как поправишь своим ненаглядным sed'ом crontab или что-то типа того, придёт salt и откатит всё исходному состоянию. Потому что нефиг руками редактировать конфигурацию боевых серверов.
