зачем использовать runit + нашлепку сбоку на ruby если можно поставить supervisord который все умеет сам без постороенней помощи. По возможностям они абсолютно идентичны. runit хорошь там где мало ресурсов в embedded или на vps, но он не предназначен для распределенного управления.
runit это не мониторинг, это супервайзер для процессов.
Необходимо отметить, что данное решение работает только если мастер никак не отвечает по сети и никак не помогает когда система «прогнулась» под нагрузкой или не работает приложение. То есть например в случае reverse proxy возможна ситуация когда сервер захлебнется от большого кол-ва конектов, но при этом будет исправно отвечать на ARP при этом выключить его через carp не будет никакой возможности из-за --preempt. Единственный выход в подобной ситуации выключать мастер физически например порт на свиче.
Мы используем CARP в связке с внешним арбитром, который следит за тем что мастер сервер работает на уровне приложения и таким образом подстраховывает от описаного мною случая.
ваш коментарии относится к сверическим коням в вакууме, мы конкретный случай обсуждаем.
как выше было замечено приложение предоставляется в apple в бинарном виде. по этому к религиозным спорам про open source это не имеет никакого отношения, если вы не хотите поговорить про «open source только для apple». Но apple показала что им исходники приложений предоставлять не нужно. по этому и обсуждать тут нечего.
Зато теперь точно известно что никакого code review в apple не делают, запустили — посмотрели. может прогнали какие то тесты. не более того. Даже глубоко в интерфейс программы не лазили. Трояны для iphone welcome.
Вы помните не совсем правильно ssh позволяет делать port forwarding, SOCKS 4/5 (dynamic port forwarding) а в последних версиях OpenSSH и VPN (только на UNIX)
статью читали внимательно? оба варианта не рабочие, потому что
— попыток (с одного IP) крайне мало (одна, две)
— эти средства не блокируют доступ постоянно а только на некоторое время (и это правильно) по этому когда с того же IP опять придет бот через 2 дня (неделю) то бан будет уже снят
надо собирать централизованно информацию с нескольких хостов (чем больше тем лучше) чтобы правильно оценить ситуацию. если не хотите использовать denyhosts, можно написать свой вариант с централизованным syslog сервером и распространением block list-ов на защищаемые сервера каким то способом (rsync)
еще вариант научить sshd проверять адрес клиента через dnsbl и вести соответствующие списки
— сменить порт ssh на не стандартный, если вдруг вы еще этого не сделали
— запретить доступ root-у через ssh или разрешить только ему авторизоваться только по ключу (PermitRootLogin without-password)
— поставить DenyHosts, написаный на python демон следящий за попытками подбора паролей и имеющая возможность обмениваться этой информацией с другими хостами
зачем использовать runit + нашлепку сбоку на ruby если можно поставить supervisord который все умеет сам без постороенней помощи. По возможностям они абсолютно идентичны. runit хорошь там где мало ресурсов в embedded или на vps, но он не предназначен для распределенного управления.
runit это не мониторинг, это супервайзер для процессов.
Мы используем CARP в связке с внешним арбитром, который следит за тем что мастер сервер работает на уровне приложения и таким образом подстраховывает от описаного мною случая.
как выше было замечено приложение предоставляется в apple в бинарном виде. по этому к религиозным спорам про open source это не имеет никакого отношения, если вы не хотите поговорить про «open source только для apple». Но apple показала что им исходники приложений предоставлять не нужно. по этому и обсуждать тут нечего.
можно еще интервью прочитать www.artima.com/scalazine/articles/twitter_on_scala.html
— попыток (с одного IP) крайне мало (одна, две)
— эти средства не блокируют доступ постоянно а только на некоторое время (и это правильно) по этому когда с того же IP опять придет бот через 2 дня (неделю) то бан будет уже снят
надо собирать централизованно информацию с нескольких хостов (чем больше тем лучше) чтобы правильно оценить ситуацию. если не хотите использовать denyhosts, можно написать свой вариант с централизованным syslog сервером и распространением block list-ов на защищаемые сервера каким то способом (rsync)
еще вариант научить sshd проверять адрес клиента через dnsbl и вести соответствующие списки
— запретить доступ root-у через ssh или разрешить только ему авторизоваться только по ключу (PermitRootLogin without-password)
— поставить DenyHosts, написаный на python демон следящий за попытками подбора паролей и имеющая возможность обмениваться этой информацией с другими хостами
ну и конечно же xhotkeys и
xbindkeys