Вообще-то вы привели ссылку на мой пост в how-to :)
Да, мне удалось запустить 8.4(2). Но на момент моего ответа (11 декабря) я еще сидел в глубоком дебаге.
Самая используемая цветовая схема: set background=dark
позволяет быстро сделать читаемыми конфиги и комментарии в них (так как дефолтный темносиний не читается очень часто) — на новых/незнакомых серверах.
Еще один возможный use case — использование Cisco ASA как VPN сервера. И тут тоже появляются баги. Из-за того что NVRAM в эмуляторе не реализована, то все RSA ключи теряются при перезагрузке. Соответственно тестировать IPSec (и SSL) VPN с использованием сертификатов можно только в течении одного сеанса — после перезагрузки все сертификаты устройства и ключи SSH слетят и их нужно генерировать по новой.
Это все не проблема, понравился подход tsung к мониторингу что в одном месте собрана статистика с сервера (cщpu, mem, etc.) и привязано к результатам нагрузки.
Просто не было необходимости делать это на одном хосте — в jmeter можно наконфигурить все ip адреса которые есть на хосте, правда (сходив по ссылке), наверно менее элегантно чем в tsung.
Разные ip полезны когда проверяешь различные лоадбалансеры и jmeter прекрасно справляется благодаря нескольким клиентам. А вот отсутствие загрузки кастомных данных… Тут и httperf справится :-)
Т.е. пользователю достаточно 200 раз обновить страницу 10.128.1.1/open.php чтобы лишить других возможности пользоваться инетом?
Хотя, по коду, если открыть в браузере напрямую 10.128.1.1/open.php — оно будет бесконечно редиректить само не себя…
Просто непонятно зачем в таком случае делать этот параметр динамическим. Если в нормальном состоянии срипты отдают контент с большой задержкой (больше чем вы динамически 30 секунд выставляете) — то в вашем случае клиенты будут видеть оборванные соединения :(
Имхо, один раз правильно настроить и не трогать.
А какое отношение tcp_keepalive_* имеют к SYN-flood атаке? Keepalive у TCP отсылается когда соединение установлено и после какого-либо пакета с данными.
В случае SYN-flood — до соединения не доходит.
Мало того что она не адекватна, так еще и является «плохой практикой». Вот, например, что думают по этому поводу SpamCop.net:
Challenge/response spam filtering
Description: This «selfish» method of spam filtering replies to all email with a «challenge» — a message only a living person can (theoretically) respond to. There are several problems with this method which have been well known for many years.
— Does not scale: If everyone used this method, nobody would ever get any mail.
— Annoying: Many users refuse to reply to the challenge emails, don't know what they are or don't trust them.
— Ineffective: Because of confusion about these emails, many of them are confirmed by people who did not trigger them. This results in the original malicious email being delivered.
— Selfish: This is the problem we are mainly concerned with. By using challenge/response filtering, you are asking innumerable third parties to receive your challenge emails just so that a relatively few legitimate ones get through to the intended recipient.
SpamCop abandoned this method of filtering after a short test period in 2001.
Solution: Do not use challenge/response filtering. Although it may stop most unwanted email for the person shielded by it, it generates more unwanted email for others.
Since more and more sites will rightly block these challenge emails, you can never be sure they will reach their target even when they are not misdirected themselves. So these systems will lose legitimate mail in an attempt to stop unwanted mail.
Т.е. кратко можно сказать что использование challenge/response систем приводит к генерации большого количества нежелательный писем для других (читай «спама»), а это уже не этично.
Мы сами какое-то время назад использовали TMDA (прикручивается к любому MTA) для борьбы со спамом, но реально оказалось что очень много писем остаются не подтвержденными или находятся адресатом в Спаме раньше чем приходит подтверждение.
Да и отсылка такого «подтверждения» в ответ на «спам» часто попадает в spam-traps — и ваш мейлер заносится в блеклисты, что плохо влияет на циркуляцию писем в природе.
Есть более легковесный вариант NetworkManager'a — Wicd. Есть как GTK фронтенд (без Gnome зависимостей) так и wicd-curses или wicd-cli, для тех кто искы не запускает.
Да, мне удалось запустить 8.4(2). Но на момент моего ответа (11 декабря) я еще сидел в глубоком дебаге.
позволяет быстро сделать читаемыми конфиги и комментарии в них (так как дефолтный темносиний не читается очень часто) — на новых/незнакомых серверах.
Ушел изучать tsung %)
Хотя, по коду, если открыть в браузере напрямую 10.128.1.1/open.php — оно будет бесконечно редиректить само не себя…
Имхо, один раз правильно настроить и не трогать.
В случае SYN-flood — до соединения не доходит.
Т.е. кратко можно сказать что использование challenge/response систем приводит к генерации большого количества нежелательный писем для других (читай «спама»), а это уже не этично.
Мы сами какое-то время назад использовали TMDA (прикручивается к любому MTA) для борьбы со спамом, но реально оказалось что очень много писем остаются не подтвержденными или находятся адресатом в Спаме раньше чем приходит подтверждение.
Да и отсылка такого «подтверждения» в ответ на «спам» часто попадает в spam-traps — и ваш мейлер заносится в блеклисты, что плохо влияет на циркуляцию писем в природе.
Какая-то «психологическая роль» точно присутствует