Нет. PT отсутствет напрочь, о чем говорится в документации, да и в комментариях выше уже упоминалось. Сеть должна работать стабильно, иначе кластеру хана.
Фактически, rabbitmq обеспечивает только availability: про pt я только что сказал, строгая же consistency отсутствеут (репликация только входящего потока данных, притом асинхронная, и гарантия записи на диск в лучших традициях монги).
При этом, если мы попытаемся сделать сетевую консистентность чуть менее слабой (строгую мы не получим все равно), включив автосинхронизацию очередей, то мы потеряем даже availability, потому что в течение синхронизации очереди недоступны ни на запись, ни на чтение.
Суть двухфакторной аутентификации не в том, чтобы получить более длинный пароль, а в том, чтобы использовать различные факторы вместе — например, «то, что юзер знает» (пароль) и «то, чем юзер обладает» (ключевой файл).
1. добавление 3ей ноды в кластер rabbitmq ничего общего с понятием кворума не имеет, поскольку нормального арбитража в rabbitmq нет, как и, к слову, нормальной синхронизации (синхронизация очередей сейчас выглядит как костыль, поскольку на время синхронизации работа с очередями недоступна). И, вообще, о какой consistency может идти речь, если нет даже write consisntecy между нодами кластера?
3. Запись на диск и гарантированная запись на диск — это две большие разницы. У вас может быть disk node с persistent queues, но при этом помещение сообщения в очередь не означает, что она легла на диск, а, например, не осела в кэше.
4. Я, возможно, недостаточно знаю про rabbitmq, но про «авторитетную ноду» в контексте mirrored queues слышу впервые. Состояние ведущего/ведомого имеют сами очереди, а не ноды.
Вообще, надо просто учитывать, что rabbitmq mirrored queues защищают от падения N-1 серверов в кластере и, вообще, имеют ряд специфичных особенностей в эксплуатации. Если серверы у вас поморгают в неудачной для вас последовательности, никто вам сохранность данных не гарантирует.
Потому рассматривать mirrored queues как универсальное средство обеспечения отказоустойчивости не следует.
> В том то и дело, что, к сожалению, нет. Может быть даже свободно 4 ГБ из 8 ГБ, но из-за фрагментации памяти, особенно после длительной работы разношёрстного софта уже не удастся выделить даже небольшой кусочек, к примеру размером 64 кБ, ну или не удастся запустить поток или процесс, которому под стек обязательно необходимо зарезервировать кусок непрерывной памяти (до нескольких МБ размером), соответственно получим ошибку создания потока в приложении и какой нибудь глюк в нём, а то и вовсе BSOD с сообщением PROCESS_INITIALIZATION_FAILED :)
Вы переоцениваете опасность фрагментации памяти. Она, конечно, имеет место, но лишь внутри выделенной отдельному процессу виртуальной памяти, потому играет какую-то роль лишь в случаях, когда есть 1-2 приложения, занимающих большой объем памяти и интенсивно аллоцирующих/освобождающих ее.
Оперативная память — это ведь не жесткий диск: у каждого процесса свое адресное пространство, и запрос на 1ГБ к ОС не требует 1ГБ непрерывного свободного места в пространстве физических адресов, поскольку MMU все равно виртуализирует всю память и раскидает этот гигабайт на кучу мелких 4кб страниц, которые могут располагать по любым физическим адресам в любом порядке.
Фрагментация имеет значение, когда, например, есть, например, in-memory DB, использующая почти всю память и постоянно выделяющая/освобождающая ее во время оперцаий. И, поскольку выделяемые/освобождаемые куски не всегда совпадают с размером страницы, то вернуть их ОС не возможно (а менеджер памяти оперирует именно ими), получается ситуация, когда есть куча аллоцированных страниц памяти, с малой долей объема занятого полезными данным.
Например, если есть 1024 4к страниц, занятых на 25%, то полезных данных 1МБ, однако, системой программе выделено 4МБ. И, если у нас всего 5МБ оперативки, то фрагментация для нас опасна.
Если же есть пара десятоков программ, к тому же, постоянно запускающихся и завершающихся, то фрагментацию памяти можно вообще не рассматривать.
Кстати, вот вам еще пара тестов:
— уроните одну ноду, потом вторую, потом поднимите первую, а затем вторую.
— уроните первую ноду, потом поднимите ее через какое-то время и тут же положите вторую, а затем поднимите ее.
Разумеется, тесты надо проводить, все это время помещая сообщения в очереди, желательно, с большой задержкой извлекая их после помещения.
Подсказки:
— в первом тесте на третьем шаге первая нода у вас тупо не поднимется без второй.
— во втором тесте вы потеряете на четвертом шаге, когда поднимете вторую ноду, те сообщения, которые легли в очереди после падения первой ноды, но не успели извлечься потребителями до момента падения второй.
И, вообще, чтобы в общем обрисовать ситуацию, отмечу несколько моментов:
— на свежеподнятой (например, после падения) ноде все очереди переключаются в ведомое состояние и сбрасывают свое содержимое (даже если на ведущих очередях на другой ноде каких-то сообщений нет)
— запись на диск содержимого персистентных очередей идет без каких-либо гарантий, т.е. никакого ACID
— по-умолчанию, разные ноды кластера не синхронизируют содержимое очередей, потому, при восстановлении упавшей ноды сообщения, прилетевшие на живую после падения первой, существуют только на одной ноде и на свежеподнятую не будут реплицированы. т.е. реплицируется между нодами только входящий поток сообщений, но не содержимое очередей. В последних версиях синхронизация появилась, но она не гарантирует вам, что автоматически она будет работать правильно.
Взгляните на затраты с точки зрения исследователей. Когда код закрыт, стоимость поиска уязвимостей выше, когда открыт — ниже.
Разумеется, когда код открыт, баги увидеть проще, однако, стоимость нахождения багов меньше и выше вероятность того, что о них сообщат вам, а не ребятам, пишущим эксплоиты.
Если же стоимость нахождения уязвимости высока, мотивация искать их остается лишь у тех, кто коммерчески заинтересован находить их. Ну а способы надежного получения коммерческой выгоды от 0day-уязвимостей вы знаете.
Referer — опциональное поле заголовка. Более того, RFC предупреждает о потенциальной утечке приватной информации через Referer и прямо рекомендует в таких случаях резать его совсем.
Какой-то витиеватый ответ на вопрос. :)
Т.е. можно считать, что все-таки вы будете доверять коду, который отдает вам почтовый сервис, которому вы не доверяете содержимое писем. Я правильно понял?
И я правильно понял, что вы не хотите доверять серверу яндекса открытый текст сообщения, но с радостью доверите его коду, который передается в браузер с сервера яндекса и может измениться в любой момент?
Я, конечно, прошу прощения, но браузеров, умеющих получать почту по POP3/IMAP и затем исполняющих полученный с сервера JS для обратоки писем, не бывает.
> Ничто, и никто не мешает магистральному провайдеру подсовывать для ваших smtp сертификаты, подписанные купленым Intermediate CA(аналогичных используемым в DPI)
Мешает то, что за подобные выкрутасы мозилла выкинет из списка доверенных CA, выпустивший сертификат для такого SubCA.
Обычно, насколько я знаю, SSL bump в DPI делается лишь внутри организаций, при этом используется частный CA, добавленный в качестве доверенного на корпоративные машины через какие-нибудь групповые политики.
Для голого ipsec в линуксе маршрутизацию править не надо, потому что xfrm-политики и так задают, что куда и через что посылать. И это, кстати, довольно неудобно порой бывает.
Фактически, rabbitmq обеспечивает только availability: про pt я только что сказал, строгая же consistency отсутствеут (репликация только входящего потока данных, притом асинхронная, и гарантия записи на диск в лучших традициях монги).
При этом, если мы попытаемся сделать сетевую консистентность чуть менее слабой (строгую мы не получим все равно), включив автосинхронизацию очередей, то мы потеряем даже availability, потому что в течение синхронизации очереди недоступны ни на запись, ни на чтение.
3. Запись на диск и гарантированная запись на диск — это две большие разницы. У вас может быть disk node с persistent queues, но при этом помещение сообщения в очередь не означает, что она легла на диск, а, например, не осела в кэше.
4. Я, возможно, недостаточно знаю про rabbitmq, но про «авторитетную ноду» в контексте mirrored queues слышу впервые. Состояние ведущего/ведомого имеют сами очереди, а не ноды.
Вообще, надо просто учитывать, что rabbitmq mirrored queues защищают от падения N-1 серверов в кластере и, вообще, имеют ряд специфичных особенностей в эксплуатации. Если серверы у вас поморгают в неудачной для вас последовательности, никто вам сохранность данных не гарантирует.
Потому рассматривать mirrored queues как универсальное средство обеспечения отказоустойчивости не следует.
Вы переоцениваете опасность фрагментации памяти. Она, конечно, имеет место, но лишь внутри выделенной отдельному процессу виртуальной памяти, потому играет какую-то роль лишь в случаях, когда есть 1-2 приложения, занимающих большой объем памяти и интенсивно аллоцирующих/освобождающих ее.
Оперативная память — это ведь не жесткий диск: у каждого процесса свое адресное пространство, и запрос на 1ГБ к ОС не требует 1ГБ непрерывного свободного места в пространстве физических адресов, поскольку MMU все равно виртуализирует всю память и раскидает этот гигабайт на кучу мелких 4кб страниц, которые могут располагать по любым физическим адресам в любом порядке.
Фрагментация имеет значение, когда, например, есть, например, in-memory DB, использующая почти всю память и постоянно выделяющая/освобождающая ее во время оперцаий. И, поскольку выделяемые/освобождаемые куски не всегда совпадают с размером страницы, то вернуть их ОС не возможно (а менеджер памяти оперирует именно ими), получается ситуация, когда есть куча аллоцированных страниц памяти, с малой долей объема занятого полезными данным.
Например, если есть 1024 4к страниц, занятых на 25%, то полезных данных 1МБ, однако, системой программе выделено 4МБ. И, если у нас всего 5МБ оперативки, то фрагментация для нас опасна.
Если же есть пара десятоков программ, к тому же, постоянно запускающихся и завершающихся, то фрагментацию памяти можно вообще не рассматривать.
Ха-ха.
Кстати, вот вам еще пара тестов:
— уроните одну ноду, потом вторую, потом поднимите первую, а затем вторую.
— уроните первую ноду, потом поднимите ее через какое-то время и тут же положите вторую, а затем поднимите ее.
Разумеется, тесты надо проводить, все это время помещая сообщения в очереди, желательно, с большой задержкой извлекая их после помещения.
Подсказки:
— в первом тесте на третьем шаге первая нода у вас тупо не поднимется без второй.
— во втором тесте вы потеряете на четвертом шаге, когда поднимете вторую ноду, те сообщения, которые легли в очереди после падения первой ноды, но не успели извлечься потребителями до момента падения второй.
И, вообще, чтобы в общем обрисовать ситуацию, отмечу несколько моментов:
— на свежеподнятой (например, после падения) ноде все очереди переключаются в ведомое состояние и сбрасывают свое содержимое (даже если на ведущих очередях на другой ноде каких-то сообщений нет)
— запись на диск содержимого персистентных очередей идет без каких-либо гарантий, т.е. никакого ACID
— по-умолчанию, разные ноды кластера не синхронизируют содержимое очередей, потому, при восстановлении упавшей ноды сообщения, прилетевшие на живую после падения первой, существуют только на одной ноде и на свежеподнятую не будут реплицированы. т.е. реплицируется между нодами только входящий поток сообщений, но не содержимое очередей. В последних версиях синхронизация появилась, но она не гарантирует вам, что автоматически она будет работать правильно.
Вот такие вот пироги.
Разумеется, когда код открыт, баги увидеть проще, однако, стоимость нахождения багов меньше и выше вероятность того, что о них сообщат вам, а не ребятам, пишущим эксплоиты.
Если же стоимость нахождения уязвимости высока, мотивация искать их остается лишь у тех, кто коммерчески заинтересован находить их. Ну а способы надежного получения коммерческой выгоды от 0day-уязвимостей вы знаете.
Впервые слышу, чтобы акционеры стояли за спинами разработчиков и сортировали бэклоги команд.
Т.е. можно считать, что все-таки вы будете доверять коду, который отдает вам почтовый сервис, которому вы не доверяете содержимое писем. Я правильно понял?
Мешает то, что за подобные выкрутасы мозилла выкинет из списка доверенных CA, выпустивший сертификат для такого SubCA.
Обычно, насколько я знаю, SSL bump в DPI делается лишь внутри организаций, при этом используется частный CA, добавленный в качестве доверенного на корпоративные машины через какие-нибудь групповые политики.
По какой причине взят именно testing, а не stable+backports?