«Сайты с музыкой» — пиратский контент? Я не очень приветствую блокировку сайтов с пираткой, но с точки зрения закона — действие вполне логичное, нет?
Сайты со шлюхами — ну вроде всё понятно тоже.
Интернет-телевидение — это которое «смотреть бесплатно без СМС и регистрации»? Чем оно отличается от пиратских сайтов?
ОЗПП сразу вынули из блокировки, как только они убрали ересь про Крым с сайта.
Про фанатские сайты Дома-2 я не в курсе, но не могу не поддержать такую инициативу :-) В самом Доме-2 контингент специфический, не думаю, что фанаты там лучше :-)
Ну в любом случае, эксцессов исполнителя, как и в любой сложной системе, тут будет предостаточно. Другой вопрос, что:
а) в процентном отношении таких блокировок очень мало
б) какое это отношение имеет к ЦЕНЗУРЕ ИНТЕРНЕТА? Речь ведь именно об этом шла.
Также не очень понял, почему «У Генпрокуратуры кишка тонка блокировать ролики по HTTPS». Какое отношение кишка Генпрокуратуры имеет к шифрованному трафику HTTPS? Генпрокуратура ведь не занимается техническими аспектами блокировок, да и строго говоря, списки блокировки может пополнять куча ведомств — суды, нарко-контроль, налоговая.
Очень много разговоров про «цензуру в интернете»… Товарищ, а вы видели тот список, по которому провайдеры должны блокировку осуществлять? Как человек, реализовавший такую блокировку у нас в конторе, я эти списки наблюдаю регулярно. Поверьте мне — в этих списках на 99.99% всякий трэш — наркота, нелегальные казино, порнуха. И только на оставшиеся 0.01% — это около-политическое. Причём из того, что лично я бы отнёс к категории «политическое», бОльшая часть точно также относится к категории «трэш» — это всякие сайты типа кавказцентр, капаров.ру, грани.ру и прочая.
Так что поверьте, этот инструмент в массовом порядке используется именно по назначению, а вовсе не для цензуры. Да, его можно использовать и для цензуры. Но равно можно использовать и молоток для убийства. Однако почему-то никому в голову не приходит задавать этические вопросы в духе: «насколько это правильно — изготавливать орудия убийства, именуемые молотками»?
Глупостей в реализации этого решения полно, это факт. Я уже писал об этом в одной из тем — РКН проверяет факт блокировки, например, пуская пинги до IP, на котором расположен сайт. Дурь? Несомненно.
Какие-то ресурсы попадают неправомерно/по ошибке? Да наверняка.
Вот эта коробка — «Ревизор» представляет ли собой кривую реализацию? Однозначно представляет, костыль на костыле.
Деньги кто-то пилит на подобных инициативах? Стопудово пилят.
Но всё это не делает возможность блокировки отдельных URL в интернете инструментом цензуры. На текущий момент цензурой тут пока не пахнет.
В любом случае, если эта коробка будет пытаться получить заблокированный URL вместо того, чтобы тупо проверять доступность пингом — это уже существенный шаг в правильном направлении, несмотря на очевидные косяки в такой реализации.
Я, наверное, чего-то не понимаю. В списке блокировки практически нет записей, в которых бы фигурировал только IP-адрес. Всегда есть хостнейм или URL. И блокировка должна производиться по соответствующему хостнейму или URL. Если конкретный интернет-провайдер не в состоянии поднять Squid и обеспечить блокировку по URL, а тупо блочит по IP, то почему претензии к Роскомнадзору, а не к конкретным интернет-провайдерам? Навскидку, в списке блокировки 99% — это порно-сайты, экстремизм, наркота, а также всякие онлайн-казино. Какой-то небольшой процент — условно-политическое. Такое, например, как kasparov.ru.
Да, есть проблема при реализации блокировок по списку РКН — это HTTPS. Когда на одном и том же IP находится заблокированный сайт и сайт нормальный. HTTPS — протокол шифрованный, в общем случае, внутрь заглянуть и посмотреть URL, на который пользователь идёт, нельзя (если не использовать всякие штуки типа SSL bump, конечно). Поэтому остаётся только целиком блокировать HTTPS на конкретных IP. Но по моим наблюдениям, такие обращения относительно редки. При абонентской базе порядка нескольких десятков тысяч абонентов, такое прилетает к нам в среднем раз в две-три недели.
Претензии к Роскомнадозору есть, но они далеко не в том, о чём написано в статье. Основная претензия — это их метод проверки, которым они проверяют выполнение операторами блокировок. По закону (и реестру) большинство блокировок идёт по URL. В списке блокировки при этом есть также IP, на котором нужно блокировать этот URL. Но при этом факт наличия блокировки проверяется на основании пинга на ТЕКУЩИЙ IP-адрес, на котором работает сайт СЕЙЧАС. Т. е. даже не на тот IP, который в реестре фигурирует. Если сайт переехал на другой IP, то понятное дело, он будет открываться. Поэтому для верности пинганём его по текущему IP, и если он пингуется, то запишем косяк за провайдером. Ну это просто несусветная глупость — обязывать блокировать URL, а проверять блокировку на основании пинга. Я даже затрудняюсь в выборе выражений, чтобы охарактеризовать тех людей, которые а) это реализовали и б) приняли такую схему проверки блокировок в продакшн. На ум приходит только короткое и ёмкое высказывание нашего министра иностранных дел в ходе конференции с министром Саудовской Аравии в августе 2015-го.
Второй крупный косяк — несоответствие списков блокировки на сайте, где это можно проверить, находится ли конкретный IP или хостнейм или URL в блокировке (https://eais.rkn.gov.ru/) и того списка, что выдаётся операторам. Например, вышеупомянутый kasparov.ru как заблокированный на сайте eais не числится. А меж тем в списке блокировки, который получают провайдеры, он находится давно и плотно. И как этот факт объяснять клиенту, который на сайте eais проверил URL и ему там сказали, что «ничо не блокируется», а по факту он пытается этот URL открыть, и ему прилетает страница блокировки — это большой вопрос. Наши юристы обращались в РКН с этими вопросами, их там послали, хотя и вежливо.
Довольно странный в технической дискуссии аргумент: "Практических примеров не будет. Я по своей воле даже пробовать использовать систему, структура которой мне заведомо не нравится, не буду."
Я не могу просто взять и поставить систему сразу на ZFS.
ZFS есть не только на Линукс. Точнее, как раз на линукс ZFS ещё довольно сырой, и многие функции отсутствуют вообще. FreeBSD, например, спокойно ставится на ZFS.
Про шифрование — вам нужно шифрование, или вам нужен LUKS? Если всё-таки во главу угла ставится "получить шифрование", а не "запилить LUKS", то есть GELI, поверх которого спокойно разворачивается ZFS. Или наоборот — поверх ZVOL разворачивается GELI с любой файловой системой внутри криптоконтейнера.
Никаких "неиспользуемых слоёв" в ZFS нет — когда вы запускаете ZFS, то практически все слои используются, за малым исключением и в отдельных сценариях.
Есть у ZFS функционал, аналогичный cLVM? Это когда я добавляю логический том в
общую группу на одной ноде кластера, а он сразу же видится на всех нодах.
Именно на ZFS такого функционала нет — пул, подключенный к одной системе, будет виден только ей. Но есть многое другое.
Как насчёт компрессии на лету?
Дедупликации?
Простых средств расширения дискового пространства?
"Тонких" блочных устройств (разумеется, также с компрессией и дедупликацией, на базе ZVOL)
С двухуровневым кэшем (SLOG/ARC/L2ARC)?
С возможностью сохранять более одной копии файлов на датасете, с автоматическим выбором не-битых блоков в случае сбоя носителя?
С автоматическим scrub'ом?
Сколько ещё уровней нужно накрутить будет в связку MD+LVM+ext4 (что влечёт за собой отдельные разборки с каждым из уровней — набор команд, ключей, структура сущностей, что поверх чего должно применяться и т. п.), чтобы получить весь вот этот функционал? Я даже дома использую его ВЕСЬ, за исключением дедупликации и SLOG. Не говоря уже про продакшн. Так что не очень понятно, какие "неиспользуемые" слои можно выделить в ZFS.
Да хотя бы что станет с ZFS, если я размещу её на DRBD и буду одновременно
обращаться с двух нод?
Да не вопрос, если вы будете обращаться к ZVOL. Причём все функции — кэши, компрессия, дедупликация, чексуммы — всё это будет работать.
Да, я имел в виду vSphere 6.
Это вопрос терминологии. То, что у нас обычно называется "отказоустойчивостью", по-английски называется HA — high availability. Что в буквальном переводе означает "высокая доступность". В этом смысле рестарт виртуалок на оставшихся в живых гипервизорах — гораздо более высокая доступность, нежели отвал сервиса на физическом сервере.
Из более-менее production-ready технологий, обеспечивающих совсем уж "отказоустойчивые виртуалки", я знаю только VMware Fault Tolerance. Есть ещё Xen Remus, но там всё сыро, большие проблемы с производительностью, и главное, как ни странно — проблемы с устойчивостью таких отказоусточивых виртуалок — они часто крэшатся из-за вносимых технологией задержек исполнения инструкций.
Поэтому если вам реально нужно "ехать", а не просто шашечки, то для обеспечения отказоустойчивого СЕРВИСА можно использовать кластер HA из трёх и более хостов + гостевую кластеризацию. Логика будет такая:
у вас гостевой кластер работает на разных гипервизорах;
если гипервизор падает, работающий на нём узел гостевого кластера автоматически рестартует на любом из оставшихся узлов;
Товарищ имел в виду так называемую «гостевую кластеризацию». Например, вам нужен отказоустойчивый MS SQL. Тогда делаете два виртуальных сервера с MS SQL, и далее собираете кластер средствами Windows и MS SQL. А в правилах размещения машин указываете, что они должны выполняться строго на разных узлах. Тогда при выходе из строя одного узла сервис у вас не пострадает — на другом узле останется работать второй виртуальный узел кластера MS SQL.
И high availability, вообще говоря, так и строится — если гипервизор падает, то машины переподнимаются на остальных оставшихся узлах, но для виртуалок это равносильно нажатию reset.
Если же речь о технологии, которую VMware называет fault tolerance, то она имеет определённые особенности экслуатации и приличные ограничения. До версии VMware 6 с помощью FT можно было зарезервировать только машину с 1 vCPU и с ограничением по объёму памяти (вроде бы, не более 16 Гб). И линк между узлами обязательно должен был быть 10G. В VMware 6 можно резервировать машины с не более чем 4 vCPU и 64 GB RAM. Ну и надо понимать, что фактически такая машина превращается в две машины аналогичной конфигурации — на другом узле будет работать теневая копия, равная по объёму ресурсов защищаемой машине.
Сайты со шлюхами — ну вроде всё понятно тоже.
Интернет-телевидение — это которое «смотреть бесплатно без СМС и регистрации»? Чем оно отличается от пиратских сайтов?
ОЗПП сразу вынули из блокировки, как только они убрали ересь про Крым с сайта.
Про фанатские сайты Дома-2 я не в курсе, но не могу не поддержать такую инициативу :-) В самом Доме-2 контингент специфический, не думаю, что фанаты там лучше :-)
Ну в любом случае, эксцессов исполнителя, как и в любой сложной системе, тут будет предостаточно. Другой вопрос, что:
а) в процентном отношении таких блокировок очень мало
б) какое это отношение имеет к ЦЕНЗУРЕ ИНТЕРНЕТА? Речь ведь именно об этом шла.
Также не очень понял, почему «У Генпрокуратуры кишка тонка блокировать ролики по HTTPS». Какое отношение кишка Генпрокуратуры имеет к шифрованному трафику HTTPS? Генпрокуратура ведь не занимается техническими аспектами блокировок, да и строго говоря, списки блокировки может пополнять куча ведомств — суды, нарко-контроль, налоговая.
Так что поверьте, этот инструмент в массовом порядке используется именно по назначению, а вовсе не для цензуры. Да, его можно использовать и для цензуры. Но равно можно использовать и молоток для убийства. Однако почему-то никому в голову не приходит задавать этические вопросы в духе: «насколько это правильно — изготавливать орудия убийства, именуемые молотками»?
Глупостей в реализации этого решения полно, это факт. Я уже писал об этом в одной из тем — РКН проверяет факт блокировки, например, пуская пинги до IP, на котором расположен сайт. Дурь? Несомненно.
Какие-то ресурсы попадают неправомерно/по ошибке? Да наверняка.
Вот эта коробка — «Ревизор» представляет ли собой кривую реализацию? Однозначно представляет, костыль на костыле.
Деньги кто-то пилит на подобных инициативах? Стопудово пилят.
Но всё это не делает возможность блокировки отдельных URL в интернете инструментом цензуры. На текущий момент цензурой тут пока не пахнет.
В любом случае, если эта коробка будет пытаться получить заблокированный URL вместо того, чтобы тупо проверять доступность пингом — это уже существенный шаг в правильном направлении, несмотря на очевидные косяки в такой реализации.
Да, есть проблема при реализации блокировок по списку РКН — это HTTPS. Когда на одном и том же IP находится заблокированный сайт и сайт нормальный. HTTPS — протокол шифрованный, в общем случае, внутрь заглянуть и посмотреть URL, на который пользователь идёт, нельзя (если не использовать всякие штуки типа SSL bump, конечно). Поэтому остаётся только целиком блокировать HTTPS на конкретных IP. Но по моим наблюдениям, такие обращения относительно редки. При абонентской базе порядка нескольких десятков тысяч абонентов, такое прилетает к нам в среднем раз в две-три недели.
Претензии к Роскомнадозору есть, но они далеко не в том, о чём написано в статье. Основная претензия — это их метод проверки, которым они проверяют выполнение операторами блокировок. По закону (и реестру) большинство блокировок идёт по URL. В списке блокировки при этом есть также IP, на котором нужно блокировать этот URL. Но при этом факт наличия блокировки проверяется на основании пинга на ТЕКУЩИЙ IP-адрес, на котором работает сайт СЕЙЧАС. Т. е. даже не на тот IP, который в реестре фигурирует. Если сайт переехал на другой IP, то понятное дело, он будет открываться. Поэтому для верности пинганём его по текущему IP, и если он пингуется, то запишем косяк за провайдером. Ну это просто несусветная глупость — обязывать блокировать URL, а проверять блокировку на основании пинга. Я даже затрудняюсь в выборе выражений, чтобы охарактеризовать тех людей, которые а) это реализовали и б) приняли такую схему проверки блокировок в продакшн. На ум приходит только короткое и ёмкое высказывание нашего министра иностранных дел в ходе конференции с министром Саудовской Аравии в августе 2015-го.
Второй крупный косяк — несоответствие списков блокировки на сайте, где это можно проверить, находится ли конкретный IP или хостнейм или URL в блокировке (https://eais.rkn.gov.ru/) и того списка, что выдаётся операторам. Например, вышеупомянутый kasparov.ru как заблокированный на сайте eais не числится. А меж тем в списке блокировки, который получают провайдеры, он находится давно и плотно. И как этот факт объяснять клиенту, который на сайте eais проверил URL и ему там сказали, что «ничо не блокируется», а по факту он пытается этот URL открыть, и ему прилетает страница блокировки — это большой вопрос. Наши юристы обращались в РКН с этими вопросами, их там послали, хотя и вежливо.
ZFS есть не только на Линукс. Точнее, как раз на линукс ZFS ещё довольно сырой, и многие функции отсутствуют вообще. FreeBSD, например, спокойно ставится на ZFS.
Про шифрование — вам нужно шифрование, или вам нужен LUKS? Если всё-таки во главу угла ставится "получить шифрование", а не "запилить LUKS", то есть GELI, поверх которого спокойно разворачивается ZFS. Или наоборот — поверх ZVOL разворачивается GELI с любой файловой системой внутри криптоконтейнера.
Никаких "неиспользуемых слоёв" в ZFS нет — когда вы запускаете ZFS, то практически все слои используются, за малым исключением и в отдельных сценариях.
Именно на ZFS такого функционала нет — пул, подключенный к одной системе, будет виден только ей. Но есть многое другое.
Как насчёт компрессии на лету?
Дедупликации?
Простых средств расширения дискового пространства?
"Тонких" блочных устройств (разумеется, также с компрессией и дедупликацией, на базе ZVOL)
С двухуровневым кэшем (SLOG/ARC/L2ARC)?
С возможностью сохранять более одной копии файлов на датасете, с автоматическим выбором не-битых блоков в случае сбоя носителя?
С автоматическим scrub'ом?
Сколько ещё уровней нужно накрутить будет в связку MD+LVM+ext4 (что влечёт за собой отдельные разборки с каждым из уровней — набор команд, ключей, структура сущностей, что поверх чего должно применяться и т. п.), чтобы получить весь вот этот функционал? Я даже дома использую его ВЕСЬ, за исключением дедупликации и SLOG. Не говоря уже про продакшн. Так что не очень понятно, какие "неиспользуемые" слои можно выделить в ZFS.
Да не вопрос, если вы будете обращаться к ZVOL. Причём все функции — кэши, компрессия, дедупликация, чексуммы — всё это будет работать.
Это вопрос терминологии. То, что у нас обычно называется "отказоустойчивостью", по-английски называется HA — high availability. Что в буквальном переводе означает "высокая доступность". В этом смысле рестарт виртуалок на оставшихся в живых гипервизорах — гораздо более высокая доступность, нежели отвал сервиса на физическом сервере.
Из более-менее production-ready технологий, обеспечивающих совсем уж "отказоустойчивые виртуалки", я знаю только VMware Fault Tolerance. Есть ещё Xen Remus, но там всё сыро, большие проблемы с производительностью, и главное, как ни странно — проблемы с устойчивостью таких отказоусточивых виртуалок — они часто крэшатся из-за вносимых технологией задержек исполнения инструкций.
Поэтому если вам реально нужно "ехать", а не просто шашечки, то для обеспечения отказоустойчивого СЕРВИСА можно использовать кластер HA из трёх и более хостов + гостевую кластеризацию. Логика будет такая:
И high availability, вообще говоря, так и строится — если гипервизор падает, то машины переподнимаются на остальных оставшихся узлах, но для виртуалок это равносильно нажатию reset.
Если же речь о технологии, которую VMware называет fault tolerance, то она имеет определённые особенности экслуатации и приличные ограничения. До версии VMware 6 с помощью FT можно было зарезервировать только машину с 1 vCPU и с ограничением по объёму памяти (вроде бы, не более 16 Гб). И линк между узлами обязательно должен был быть 10G. В VMware 6 можно резервировать машины с не более чем 4 vCPU и 64 GB RAM. Ну и надо понимать, что фактически такая машина превращается в две машины аналогичной конфигурации — на другом узле будет работать теневая копия, равная по объёму ресурсов защищаемой машине.