boco

+1, только можно даже не править фстаб, у mkfs и mkswap есть ключ -U

я, честно говоря, ваш ответ не понял. зачем добровольно ломать то, что не сломано? при том что ркн сам предлагает вариант не ломать. или вы что-то знаете, чего нет в записке от ркн?

а зачем ломать существующие системы? они же на выбор предлагают один из 4 вариантов, причем первый (поднять у себя авторитетный отдельно стоящий bind) - наименее инвазивный. пусть развлекаются.

на эти "дропы" можно смело забить. это не потери, это отброшенные левые пакеты. https://www.suse.com/support/kb/doc/?id=000017478

а как вы считаете эти самые дропы?

просто используйте sas-nl. не связывайтесь с sata в этих бакплейнах. если результат интересует. они могут работать нормально, потом случайным образом повыпадать. или не распознается топология при загрузке.

нужно читать документацию на диски. в случае с двумя вышеозначенными моделями wd попробуйте замкнуть указанную в картинке перемычку. но не факт что поможет.

это не контроллер, это бакплейн в CSE-836E2-R800B. если есть возможность на дисках переключателями выставить режим sata150, то взлетит. если нет, то как повезет. мы отказались от sata в таких бакплейнах, sas-nl диски сопоставимых с sata объемов стоят сопоставимых денег, а проблем с ними никаких.

омг =) правило нужно ставить туда, где трафик, который вы хотите собрать, еще есть. например, самым первым в цепочке FORWARD. кусок кода, который я привел был просто намеком на то, что вы забыли добавить правило в фаервол. это, кстати, написано в документации на модуль 4. Example of directing all IPv4 traffic into the module: # iptables -I FORWARD -j NETFLOW # iptables -I INPUT -j NETFLOW # iptables -I OUTPUT -j NETFLOW Note: It is preferable (because easier to understand) to _insert_ NETFLOW target at the top of the chain, otherwise not all traffic may reach NETFLOW if your iptables configuration is complicated and some other rule inadvertently consume the traffic (dropping or acepting before NETFLOW is reached). It's always good to test your configuration. Use iptables -L -nvx to check pkts/bytes counters on the rules.

собирать ее? iptables -A FORWARD -j NETFLOW

плюс можно но лучше unbound и его "max-udp-size"

простой казах знает про le =) но аргумент весомый. согласен. правда тут фишеру еще надо заморочиться, да и нажаловаться в le можно на такого деятеля. а если абсолютно любой вася может даже не заморачиваясь с le лепить подделки - это васе сильно облегчает жизнь. а простому казаху, наоборот, осложняет.   а, то есть они не абсолютно весь https портят? я почему-то подумал, что весь. ну все, я теперь спокоен за казахов =)

не нужно, его же оператор услужливо предоставляет =)

по-моему, страдания о вмешательстве в личную жизнь не так актуальны, как вопрос: "а как простой казах теперь узнает, что попал на официальный сайт, а не на фишинговый?" весь https "интернет" для него теперь небезопасный.

а если закавычить одинарными кавычками весь урл? и заодно запустить с отдельным конфигом, в котором только этот урл.

пробел в пароле. или какой-то другой символ, который превращает урл в огрызок вида "rtsp://cyberlive:passwo", где "passwo" естественно каким-нибудь atoi() преобразуется в "0"

cache-max-ttl, cache-max-negative-ttl

раз: https://www.sysnative.com/forums/networking-tutorials/10398-how-enable-use-rip-listener-routing-computer.html два: http://sourcedaddy.com/windows-7/managing-rip.html

вы о разных вещах говорите. ваши оппоненты предлагают не анализ скачиваемых пользователем файлов на наличие вредоносов, а определение характерного для зараженной машины трафика с последующим уведомлением/отключением пользователя. грубо говоря, пресечение работы ботнетов.

без понятия. нашим сотрудникам этот продукт на какой-то тусовке разрекламировали.

https://rdp.ru/products/service-gateway-engine/qoe/

я просто оставлю это здесь:

а в чем суть вопроса? если нашему нс всегда отдаются заблоченные ипы, то клиенту отдастся пустой ответ. если бы фильтра ответов не было, клиенту улетели бы заблоченные ипы и он все равно не смог бы туда попасть (т.к. заблочены), только после tcp timeout. можно немного изменить схему: поставить перед анбаундом бинд с опцией forward first. тогда если бинд получит от анбаунда пустой ответ, он сам слазит в днс за ответом и отдаст клиенту все полученные записи. то есть, схема будет работать так: клиенту улетают отфильтрованные ип-адреса, если среди них есть незаблокированные и все ип-адреса, если среди них только заблокированные.

я просто загнал в private-address все 5+ тыщ префиксов с типом блокировки "по ip". если там попадется какой-то из полностью заблоченных (например, lcprd1.samsungcloudsolution.net), то клиенту по барабану, сразу оно недоступно из-за отсутствия днс-записей или по таймауту из-за того, что пакеты в нуль смаршрутизированы. зато теперь хоть инструмент диагностики есть - если наш днс возвращает 0 записей, а гуглоднс больше 0, значит ip в блоке. =) ну а частично заблоченные хосты, типа www.google.com, будут работать. автомагически.

странно, у меня работает. unbound 1.7.0