>> В смысле _мне_ проще? Объясни в чём разница между мной и тобой.
> потому что у тебя - "своя программа". А у меня - "cвоя
> система", единое целое, а программы в ней бывают в количестве энцать
> штук.Я ничего не понял. Причём тут "моя программа - твоя система"? Как нарушается целостность системы от того, что я могу складывать конфиги для crond/syslogd/something в отдельные директории?
Или ты про то, что устанавливаемое ПО не должно менять персистентную систему, иначе кластер превратится в зоопарк со временем? Ну так с этой позиции нововведение лишь пользу приносит - я могу монтировать /etc, или вообще корень + /usr (не /usr/local/ !) в ro и все сторонние конфиги складывать в /usr/local/etc/*.d/. Кажется, это куда надёжнее, чем перезаписывать единственный файл?
>> Не буду спорить, обычно по имени файла понятно, куда смотреть
> ты точно-точно админ?
Что ты ожидаешь услышать в ответ? Нет, я не побегу выкладывать скан трудовой, извини. А апеллировать к личности оппонента - не комильфо.
> что тебе по имени файла будет понятно, когда по данным мониторинга в
> системе охрененная нагрузка с 3:25 по 4:30 с перерывами на
> полежать?
Что мне будет понятно из /etc/crontab, когда по данным мониторинга в системе охрененная нагрузка с 3:25 по 4:30 с перерывами на полежать?
Кажется, вопрос учёта и ограничения ресурсов несколько выходит за рамки обсуждаемого?
Можно настроить логин-классы, аккаунтинг, мониторинг и пр. - это про поиск злодея, сожравшего все ресурсы на хосте.
При чём тут способ доставки конфигов на кластер?
> В какой, мля, файл из тыщи смотреть и что в нем искать?
> С какого прохода ты наконец заметишь нужную строчку в миллионе мусора?
> Уверен ли ты, что нашел нужную, а не похожую, потому что
> забыл еще один стопятый вариант того, откуда, БЕЗ явного указания этого
> в конфигах, шибкоумно хакнутый крон берет себе задания?
Никогда не искал в кронтабе программу, которая ушатала машину, честно. Это даже звучит как абсурд =).
Имя программы/пользователя обычно не сложно найти более прямыми способами, далее найти файл, из которого запустился cron-таск - это секунды грепанья.
>> Не буду спорить, обычно по имени файла понятно, куда смотреть
> по имени файла сrontab, понятно, что туда надо смотреть, когда речь о
> периодических задачах.
По имени файла, содержащего "(cron|syslog|something).d/" всё также понятно. И?
> случаи бардака, когда кронтаб на самом деле пишешь не ты, а стопицот
> косоруких программистов, решаются явным include в конфиге, который не может внезапно
> притащить что-то левое без твоего ведома.
> (ну а правильней именно в freebsd это решается уносом в periodic, и
> написанием отдельного конфига верхнего уровня для него)
Т.е. вместо того, чтобы принести +N файлов ты предлагаешь принести +N файлов и в довесок добавить +N инклюдов в основной конфиг?
И считаешь это улучшением? В чём тогда оно? Тогда уж проще в самом деле один файл таскать, ей богу.
>> Повторюсь: я не считаю, что 70+ строк в кронтабе - это хорошо.
> это приемлемо, и совершенно не является проблемой для прочитать и разобраться -
> если ты все же админ.
Админ, админ. И именно поэтому я хочу не читать простыни по 70+ строк, а автоматизировать процессы так, чтобы мне не нужно было этого делать. Я хочу, чтобы ОС работала на меня, а не я на неё. И, кмк, в этом вообще смысл вычислительной техники.
Ревьюить простыню, которая изменяется иногда по N раз в день или дать возможность запускать своё Г без вмешательства администратора...
Даже не знаю, что выбрать =) *ИРОНИЯ*
> Вот когда оно в семидесяти контейнерах по одной, и даже добраться туда
> чтобы их увидеть нужно с помощью танцев и приседаний - это
> да, это жопа.
Учёт ресурсов, для тасков, запущеных в cgroups+namespaces/jail (да, я знаю, что их возможности не всецело эквивалентны), проще же.
Какие нужны приседания? Окей, линуксовый зоопарк/изобилие решений действительно может заставить тупить и путаться по первым порам, но в bsd, где jail'ы и только - какие там проблемы с этим?
Но это, опять же, не про доставку конфигов на машину и их хранение на диске, правда?
>> Просто при обновлении существующего файла может больше всего пойти не так, как
>> хотелось, чем при подкладывании дополнительного
> нет. Это неосиляторы сед не думают головой - и получаем рейсы в
> fs (они ж даже атоммарно его создать не сообразят), файлы не
> с теми правами, и массу других интересных штук.
> У тех кто думают, у них и с обновлением нет на пустом
> месте проблем, а на непустом они честно тебе выдают лог и
> говорят, что и куда добавить руками.
1) С каких пор править конфиги sed'ом в продакшене - это хорошая идея? Если уж мы говорим про один файл, то правильный подход - поправить (хоть бы и sed'ом, ага) его в безопасном месте (один раз), проверить, раскатить на кластер, поэтапно.
2) С каких пор правка конфига sed'ом атомарна? А если на 1 из 1000 машин в тот момент, когда твоя автоматика запустит sed кончится память посреди процесса и процесс sed'а будет принудительно завершён?
3) А если на куске кластера crontab отличается, или его даже потрогали чьи-то шаловливые ручки, у которых есть root, и теперь регулярка не работает?
Можно ещё придумать много аналогичных по смыслу примеров.
А можно даже не пытаться решить искусственно созданные проблемы и позволить приносить конфиги в /usr/local/etc/cron.d/ и не париться. Принёс некорректный файл? Отлично, ССЗБ. Твои таски не запустятся, у всех остальных работают как и ранее.
Не успех ли это?
>> Это же не принудиловка
> это принудиловка - я не могу это выключить и быть уверен, что
> коекакерский скрипт не нагадит в каталог хз где, который я забуду
> проверить.
> Более того, очевидно что это не было бы сделано в релизе с
> номером, предполагающим только критические исправления, если бы толпы коекакеров не занесли
> уже руку над комитом подобных скриптов.
Не давай права на запись в /usr/local/etc/cron.d/ пользователям, из под которых будет организована доставка файлов в эту директорию?
Кошмар, принудиловка уровня "bind в базовой системе, я принуждён использовать bind!11".
Откуда растёт противоестественное желание глазами валидировать все конфиги мне также не понятно. Эдак можно целый день только конфиги читать.
Не, если у тебя небольшой кластер, мало cron-тасков и редактируешь crontab только ты и не очень часто, то один файл - это самое то, да.
При несоблюдении хотя бы одного условия это мазохизм, извините.
> С единственным аргументом "хотим как в линукс". Вот уж что-что, а еще
> один линукс мне нафиг не сдался.
Истерика на пустом месте. Хотим не как в линукс, а как удобнее/практичнее. А то, что в линуксе также - не повод отказываться от решения.
И уж точно это изменение (минорное, к слову), не сделает freebsd "опасно похожей на linux". Бред.
PS: Таскать вагон настроек для cron/syslog/etc, которые нужны каким-то сторонним боевым программам в любом случае ЗЛО и так делать не надо, не важно, сколько файлов и где их по дефолту ищут системные сервисы. Я лишь попытался сравнить подходы, помня, что они оба плохие, исходя из имеющегося опыта.
