>> 2) Что понимается под правкой crontab sed'ом? Почему именно им вообще? Это
> ну хочешь ты снабдить свою ценную программу автодобавлялкой чего-то в кронтаб и еще пару линейных конфигов, почему бы и нет?Ну вот и как ты потом поймёшь, какой пакет попатчил тебе crontab? Что будешь делать, если в crontab кто-то сходит, поправит твою строку и автоудалялка не удалит нужное при удалении пакета? Как защитишься от того, что другие пакеты тем же sed'ом не распотрошат твои настройки из-за ошибки или вредоносных намерений их авторов?
Что будет, если в sed прилетит -9 от системы во время автодобавления?
rename (2) или symlink (2) атомарны, например, в отличие от.
>> типа Ъ и по-какерски? А если я, например, python'ом или perl'ом,
> если ты пользуешься фрей, то должен знать, почему нет. awk - пожалуйста, только надо все время помнить, что это не gnu awk, мне проще помнить что лучше им на фре не пользоваться вообще ;-)
Аргумент про базовую систему принимается, ок. Мне правда религия позволяет ставить условный python на машины, если нужно (обычно да).
Почему bsd awk лучше не использовать? Я правда не знаю. Я знаю, что он отличается от gnu awk, но не настолько владею обоими, чтобы знать, чем бсдшный фундаментально хуже.
Bsd sed, кстати, от гнутого тоже отличается. Поэтому за то время, что я админил и linux и freebsd в один период времени и в примерно равной пропорции, я приучил себя использовать однострочники на perl для замены ~80% кейсов, когда я использовал sed. Да, perl у нас был установлен везде. Да и сейчас кстати, но это уже не про freebsd, к сожалению =(
>> своим ненаглядным sed'ом crontab или что-то типа того, придёт salt и
> и что ты делаешь с установкой пакетов, которые приносят свои конфиги? Особенно в тех случаях, когда они тривиальны, и трогать там в общем-то ничего не надо.
Ничего не делаю, потому что у меня сейчас по работе linux в основном, причём, наиболее фекальный - ubuntu. Увы.
Salt защищает не все файлы, а лишь их часть, те, что новые приезжают в cron.d (обычно с пакетами) так и остаются.
Но я, кстати, считаю, что это в принципе плохая практика для серверов в большом кластере, как приносить с пакетом кронтабы так и патчить их чем либо.
Правильный способ - иметь свой планировщик и запускать его рядом с инстансом приложения или перенести логику в само приложение. А crond использовать для системных тасков и только.
В "волшебном linux-мире" этот подход вылился в контейнеры, жирные причём( Я не против контейнеров, но в данном случае это оверкилл.
>> откатит всё исходному состоянию. Потому что нефиг руками редактировать конфигурацию боевых серверов.
> не вижу проблемы. Если серверов тыща штук и отличаются они толко по uuid'ам-хрен-запомнишь, то, конечно, руками там делать нечего (а скриптами - берущимися из пакета - почему бы и нет, не вижу чем это хуже бранья из пакета мусора для добавления в .d)
Это хуже, но conf.d тоже плохо, да. Чем хуже - я уже много букв написал про то, почему я так считаю, в т.ч. в начале этого сообщения.
> Если сервер специфический, существует, в силу особенностей сервиса, в единственном экземпляре - не вижу необходимости в умножении сущностей и редактирования его конфигов через десять прослоек, не видя результата немедленно. Автоматизировать надо рутинную и отнимающую время работу, а не "чтоб было".
Согласен. У меня просто уникальных серверов уже очень давно нет, ибо требуют наличия реплик в количестве не менее 3х штук.
