drBatty
Я уже не в первый раз вижу, как вы отвечаете совершенно невпопад. Прокручивайте тему назад для освежения памяти перед написанием ответа, пожалуйста.
drBatty писал(а): ↑24.02.2014 02:03
Rootlexx писал(а): ↑23.02.2014 21:11
При том, что защита от взлома используется принципиально одинаковая: увеличить время между попытками, блокировать при превышении порога неудачных попыток.
ну и зачем её дублировать? В sshd всё это есть, и работает вроде.
Речь шла о том, что автоматический перезапуск некоторого сервиса якобы чреват подбором и эксплуатацией уязвимости, на что я ответил, что для защиты от подбора используется та же техника, что в ssh для защиты от подбора пароля/ключа: пауза между попытками, блокирование при превышении лимита неудачных попыток. sshd здесь очевидно не дублируется, ибо он не занимается перезапуском произвольных сервисов.
drBatty писал(а): ↑24.02.2014 02:03
Rootlexx писал(а): ↑23.02.2014 21:11
всё это при желании можно сделать с помощью шелла.
На Тьюринг-полном языке можно всё написать. Вопрос в том, нужно ли, то есть является ли данный язык более подходящим для решения задачи, чем другой.
ответ: да, нужно, причём именно на shell'e. Не забывайте, речь у нас идёт о срочной работе: ВНЕЗАПНО рухнул какой-то демон, нужно по быстрому слепить костыль причём администратору, которой вообще говоря не обязан разбираться в C/C++ или ещё чем-то подобном. Времени ждать помощь от разработчиков демона НЕТ, нужно взять и сделать, срок вчера. В данной ситуации shell поджходит как нельзя лучше, администратор просто обязан его знать, и уметь быстро слепить требуемый костыль, который как-то будет подымать демон, пока его не вылечат. Ситуация не только срочная, но и нестандартная, потому стандартный systemd тут не подходит, там просто не будет таких особых правил для поднятия этого неведомого демона, который НЕГАДАННО рухнул.
Ну что же вы занимаетесь такой явной демагогией? "Ситуация не является стандартной, поэтому systemd не подходит, ибо является стандартным". Вы исходите из предположения, что "стандартный" в обоих случаях означает одно и то же, что очевидно не так.
systemd имеет множество директив для описания подавляющего большинства возникающих ситуаций при падении сервиса (см.
man systemd.service), а для совсем уж нестандартных случаев (которые очевидно маловероятны) можно указать свои команды для проверки, аварийно ли был завершён сервис, в ExecStopPost.
drBatty писал(а): ↑24.02.2014 02:03
Лучше, вместо того, что-бы делать стандартную подымалку, исправлять падучий демон.
Я безусловно согласен, что необходимо исправлять найденные ошибки в сервисах, и автоматический перезапуск не предлагается в качестве мотивации к игнорированию этих ошибок, а лишь для продолжения работы в условиях наличия этих ошибок или невозможности их исправления (например, используется проприетарное ПО; или проект заброшен, и некому реагировать на отчёт об ошибке).
drBatty писал(а): ↑24.02.2014 02:03
Rootlexx писал(а): ↑23.02.2014 21:11
shell для этого плохо подходит из-за изобилия подводных камней в самом языке, а также ненадёжного поведения в граничных случаях, о чём я и вёл речь.
за всё надо платить. "Подводные камни" -- расплата за универсальность.
Вот тут не соглашусь. Изобилие подводных камней в shell является следствием особенностей реализации. Нет непреодолимых преград перед тем, чтобы такая синтаксически и семантически корректная конструкция работала так, как ожидается:
Код: Выделить всё
i=0
some_command | while read output; do
data[$i]=`process $output`
let i++
done
echo ${data[*]}
Пример, когда опытные разработчики совершили такую же ошибку, я уже приводил.
