>> Ну как же нет, когда да. Вот я хочу вместе со своей
>> программой приносить на машину отдельные настройки crond или syslog.
>> Что проще - патчить единственный файл или подложить ещё один файл в
> _тебе_ конечно проще. А мне потом этот зоопарк тамагочей кормить - нифига
> не проще, потому что я держу там не твою программу, а
> систему. И вот это программистам, похоже, никак не понять.В смысле _мне_ проще? Объясни в чём разница между мной и тобой.
И при чём тут программисты?
>> Условный "cat /usr/local/etc/cron.d/* | less" не поможет?
> нет, не поможет, особенно если уже понадобилось ТАК в этом разбираться.
Не буду спорить, обычно по имени файла понятно, куда смотреть, делать cat * | less для поиска чего-то в конфигах мне не приходилось.
Ну это как, я не знаю, вот в /etc/ лежат разные файлы с разными названиями, и по их названиям понятно, что за что отвечает. Было бы это в одном файле - была бы помойка.
Тут точно также, кмк.
>> Ну и, как по мне, аргумент странный. А если в конфиге 70+
>> строчек - это тоже что ли удобнее читать в единственном файле?
> не знаю. смотря что за строчки, если это реальные 70+ независимых задач,
> зачем-то понадобившиеся на одной системе (я бы подумал как ее попилить
> на независимые виртуалки), то да, удобнее, ты хотя бы будешь в
> одном месте видеть, что за чем выполняется (и не запустишь два
> тяжелых процесса одновременно).
Строчки, естественно, всякий мусор, который, по-хорошему, надо было делать внутри самих приложений и не таскать с собой cron-задачи. И естественно, это не от хорошей жизни было.
Но так и речь про то, какой подход удобнее в реальном мире (который наполнен адом и кошмаром, увы), а не про то, как настраивать идеальную систему для запуска идеальных приложений.
> Чаще всего это все же означает, что надо было написать скрипты,
> выполняющие это все в правильном порядке, а в кроне оставить десяток
> вызовов этих скриптов, или вообще предоставить этим заниматься periodic (не забыв
> что у него есть _настройки_, или во всяком случае, были задуманы
> когда-то, чтобы ни при каких обстоятельствах не лазить в сами скрипты)
Есть кластер, чуть больше 1000 машин. Есть задача деплоить на него ПО, написанное разными (в общем случае) командами программистов. Некоторые программы таскают с собой cron-таски, некоторые по cron'у запускаются на каком-то срезе хостов, некоторые не чистят за собой временные данные и приходится лепить костыли в cron'е и т.п. - мрак, в общем.
Утверждается, что принудить всех "делать правильно" и не таскать с собой всякое г вот прям сразу невозможно. Т.е. все к этому идут, но бардак уже исторически сложился и надо с ним как-то жить.
И удобнее жить с возможностью раскладывать костыли в разные места, а не перезаписывать файл, в надежде, что его не потрогали ничьи шаловливые ручки или ещё какая оказия не приключилась.
>> И да, crontab на 70+ строк я видел вживую и не раз. Как раз таки на фряхе.
> я их на всем видел, и иногда даже не в силу коекакерства
> сделанных, но это были очень старые системы, до эпохи доступной виртуализации,
> и в них, действительно, было напихано прорву вещей, "процессор же потянет,
> если не в пиковые часы?"(вот оно и лопнет часа в четыре
> утра, вот щастье-то) которые сейчас никто в одну банку не пихает.
На линуксе я не видел исключительно потому, что простыни были разложены по файлам в *.d. Ну и контейнеры, да.
Повторюсь: я не считаю, что 70+ строк в кронтабе - это хорошо. Но иногда это реалии, с которыми приходится жить.
Коекакерство - да. Старые инсталляции - да.
Как я считаю, если есть инструмент, с которым удобнее упорядочивать бардак, не имя возможности радикально искоренить его, то это плюс, а не минус. В конце концов, ничего не мешает фигачить всё одним файлом, если твои задачи это решает.
>> При чём тут sed? Причём тут linux и "его кривой устав"? Я
> потому что они на самом деле разучились - для них реально невыполнимая
> задача добавить строку в неструктурированный построчный конфиг (а потом еще ее
> и найти там, если понадобилось удалить или поменять).
> В основном эта публика тусуется в линуксных системах (потому что ничего другого
> не умеет и не хочет), но иногда прорывается на новые горизонты.
Просто при обновлении существующего файла может больше всего пойти не так, как хотелось, чем при подкладывании дополнительного, линукс тут ни при чём.
И чем больше у тебя парк машин, тем сильнее это ощущается. Как по мне, плохо и приносить 100500 файлов в *.d и деплоить один огромный конфиг, такие задачи должны решаться каким-нибудь etcd/zookeeper или чем-то типа salt/puppet.
Но приходится работать с тем, что имеем, мир не идеален.
> А .d/* вместо явных include (которые как раз полезны) - это диверсия,
> она тебе еще выйдет боком, и не раз.
Да почему же? Это же не принудиловка: не нравится, не клади ничего в .d/*. Это возможность, а использовать её или нет - нужно решать исходя из задач. И хорошо, что теперь есть больше вариантов для выбора. Я рассуждаю так.
