Pull to refresh
122
0
Evgeny Talyzin @Mnemonik

User

Send message

А вы точно не перепутали красивый код и рабочий? Потому что проблему которую вы тут так смачно описывали стопудово можно было бы решить бахнув пяток if'ов тут и там. Работало бы прям хорошо. Правда почему-то другие глядя на такое называют это legacy, да ещё и говорят так, как будто это что-то плохое...

Интересно что за люди пишут такие статьи вообще, у меня есть два варианта и оба крайние - это когда люди считают что если всё по PSR, отступы, стиль кодирования, DI, интерфейсы и наследование то такой код в принципе не содержит багов. И другой тип когда считают что если задача выполнена то продукт в принципе готов. Если код работает и проходит все тесты - это уже полный продакшн реди и в комментариях не нуждается.

Оба типа сильно ошибаются...

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

"эксплоитов выходящих из песочниц"? а не подскажете рабочий, а то мне надоели бесплатные тарифы на AWS, хотелось бы захватить весь сервер там выйдя из виртуалки, должно быть несложно вроде как вы описываете.

Ни первый ни второй явно не работали с arm.

На arm декдоер видео это отдельный IP, отдельный блок в процессоре. Никакого отношения не имеет ни к видеокарте и ни к процессору. То есть в свой armv8 можно прицепить кусок одного производителя, или другого, как захочется. У rockchip этот блок называется Hantro, у Samsung - MFC, у Amlogic... блин вот взял и забыл. Ну короче не важно. Важно то, что практически для всех этих блоков нужен отдельный драйвер в ядре линукса, писать который страшная, древняя жопоболь. А потом этот драйвер ещё и должен быть корректно использован плеером, который будет в него пихать сжатые кадры, а из другого места читать распакованные. Все вендоры лабают жуткий кусок лапши для андроида который стыкуется с их древним проприетарным ядром и андроидским фреймворком для видео и перекрестившись считают на этом свою задачу выполненной. Единственная плата у которой более-менее поддержка декодирования видео работает - raspberry pi. Для их VideoCore есть драйвер в ядре и его более менее умеет использовать ffmpeg. Что уже делает его на голову продвинутей поддержки в линуксе любого другого кодека. Samsung-овский MFC был в ядре давно, но у него свой особенный интерфейс который с трудом понимает ffmpeg и чтобы его завести надо было писать прослойку для каждого плеера. Hantro от рокчипа в зачаточном состоянии, если вообще принят, а не до сих пор в виде патчей, для Amlogic Baylibre (которые просто энтузиасты которые пытаются сделать апстрим линукс работающим на процах Amlogic нормально) целый отдел создали чтобы написать драйвер который примут в апстрим. Более-менее ни шатко ни валко дело идёт, аж целый h264 вроде как работает. Возможно даже 4к. И вроде даже можно связать его с ffpmeg без особой магии.

Так вот. Для начала я сомневаюсь что Байкал вообще поставил какой-то IP для видео в процессор, зачем? И уж совсем сомнительно чтобы они написали достойный драйвер который стыкуется с ffmpeg который без труда смогут понять плееры видео. Если бы они это сделали, шум бы в чатиках которые занимаются видео на встроенных одноплатниках поднялся бы до небес.

Так что всё это скорее всего просто тупо исполняется на проце. И это настоящая печаль, потому что современный арм может h264, и даже 1080 будет видно, если прикрыть глаза и не смотреть на загрузку и температуру, но вот 4к это уже будет во-первых плохо, 24 кадра если сцена не сильно меняется, во-вторых загрузка уедет в небо сразу и прочно.

Меня одного смутило "Bare-metal" в названии и рассказ о том как запустить всё на виртуалках?..

Ещё конечно бы хотелось услышать обоснование аж трёх мастеров для тестового кластера, тогда как и продакшн справится с одним. Ведь вы же знаете что мастер не критичен для работы кластера, это control-plane. Им кластер управляется, то есть если мастера выключить, то всё мгновенно не исчезент в варпе, просто пропадёт возможность что-то менять и вообще доступ к API. но поды всё так же будут запущены и будут работать и отвечать? Знаете же да? Что в кластере с одним мастером если его перегрузить пока он перегружается особо ничего не произойдёт? Ну так зачем в тестовом кластере ТРИ мастера?

Наверное я каким-то другим алиэекспрессом пользуюсь, но на моём алиэкспрессе у продавцов появились склады в европе. При покупке мелкой электроники (типа одноплатников или всякой мелочевки) достаточно прокликать несколько продавцов и можно без проблем найти продавца с выбором склада отправки, с вариантами "из польши", "из италии", "из украины", "из германии". Те же цены, никакой пошлины, да ещё и доставка за неделю вместо месяца как раньше.

Открывал статью с предвкушением "ща как читну как всё бывает всрато и какие бывают сумашедшие люди! угорю с утреца"...

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

"Одна из небольших странностей «Минервы» заключается в том, что многое в ней использует принцип «главное — данные», а не «главное — код»" - вообще максимально здравая мысль. Проектируя системы достаточно долгое время так или иначе понимаешь что всё что ты делаешь это фильтр над данными которые ты имеешь, все эти слои прекрасно проходящего PSR-7 проверку кода - просто сложный фильтр, который преобразует массу данных которые у тебя есть в зрительные образы, ничего более.

Да и всё остальное - тоже максимально похожий на так любимый теми же цифровыми фашистами (те которые про важности места скобок в коде) моно-репозиторий концепт. Просто эволюционировавший ещё дальше: возьмём вообще всё что только можно, и данные, и код, и среду исполнения, всё в масштабе предприятия - и сунем в одно место где всё это будет доступно всем сразу.

Короче не вышло угореть. Разочарован. Полнейший адекват в статье. =(

Да, причём в ipv6 можно прокидывать айпишник используя роутеры с внутренними айпишниками по пути.

То есть можно дать устройству айпишник типа 2001:x:x:x:x:x:x:x и указать что default gateway fd00::1 какой-нибудь (роутер с wireguard которому не обазательно выдавать внешний адрес) и это совершенно нормальная ситуация. Это как дать устройству ipv4 212.1.1.1/32 и указать гейтом 192.168.1.1 (не получится), а в ipv6 работает.

Правда тут конечно придётся слега уже приколотить роутинг от и до этого айпишника через туннель. но всему же есть предел =D

У вас правильное направление мышления, но всё ещё закостенелое под "ipv4" типа "зачем выделять так много адресов небольшому сегменту?". В парадигме ipv6 имеет значение префикс, всё примерно до /64, все остальные /64 это локальный блок, который выделяют не глядя иногда даже и на одно устройство. Суть в том, что ipv6 адреса уже нереально запоминать, мало того некоторые устройства их рандомно меняют (это тоже часть стандарта направленная на безопасность). В ipv6 сети надо полагаться на DNS, без этого уже никак. И если полагаться на DNS уже всё равно сколько там у кого каких адресов.

В вашем случае если я верно понял описание, что можно было бы сделать - так это например сделать wireguard туннель поддерживающим и ipv6 и выдать внутри вашей сети дома внешние айпишники вход на которые на хостинге кому надо. так можно было бы добиться доступности снаружи по ipv6 без всяких проблем для устройств внутри, раз вы переживаете что для дома не выбить свой ipv4. с ipv6 без проблем.

В моём случае у меня умный дом на две квартиры и загородный дом, это три подсети. Всего в одном месте есть реальный ipv4 (повезло с провайдером) из двух других мест туда wireguard туннели, и внутри всё по ipv6. три сегмента ipv6 /64, общая внутренняя /48 сеть, из любого места видно любое устройство, и что самое главное с ipv6 - это реально просто работает. если с ipv4 мне бы пришлось точно знать где у кого какой адрес в каких подсетях, какие там адреса в туннелях и так далее, настраивать роутинг на всех трёх роутерах чтобы один видел оба, а с двух друхи было видно всё через центральный, с ipv6 достаточно было настроить адреса на трех роутерах, и все устройства внутри получили свои адреса и сразу увидели друг друга, то есть не пришлось заморачиваться со сложным роутингом (он как бы так и остался сложным, но с ipv6 это заработало без проблем, включая то что я описал выше - некоторые интерфейсы имет по три разных айпишника, и всегда правильно выбирают с какого адреса выплёвывать пакеты в зависимости от того куда они идут). Отлично работает локализация трафика, не важно где я со своим айпадом, выплёвывается трафик в интернет из локального мне роутера (в одном месте есть внешний ipv6), мой внутренний трафик до устройств ходит внутри сети, где надо и через два хопа).

Сложность из заморочек с роутингом сместилась в сторону грамотно настроить DNS, так чтобы всех было видно по именам.

ipv6 крутая технология.

её конечно довольно сложно понять чисто теоретически. можно читать статьи, можно пытаться прикинуть что к чему пытаясь провести параллели с тем как всё в твоей лично сети устроено и как бы это было с ipv6, но всё равно самый крупный толчок ты получаешь начав что-то делать.

когда у меня появился ipv6 адрес от провайдера это стало отправной точкой чтобы подумать "так, ну вот адрес как бы уже есть, может попытаться уже сделать что-то?". и всё оказалось довольно просто и понятно и действительно удобно.

что меня больше всего поражает, это то, о чём почему-то никто не пишет во всех этих огромных статьях, но что знакомо каждому сетевику который делал хоть сколько-нибудь сложные сети. это то, как протокол грамотно выбирает исходных адрес при установке связи. каждый, кто пытался настроить сеть, когда на интерфейсе есть глобальный адрес, пара локальных и ещё впн, поймёт о чём я. в ipv4 есть адрес интерфейса с которого он будет выплёвывать все пакеты, и, чтобы заставить его правильно выбрать исходный айпишник, надо понаколотить всяких правил, чтобы пакеты в какой-нибудь туннель уходили откуда надо. в ipv6 это всё работает из коробки само собой. у меня сейчас на интерфейсе глобальный адрес (аналог внешнего айпишника), локальный адрес (что-то среднее между 127.0.0.1 и 192.168.0.0 - адреса которые существуют только между соседями и роутером, и никогда не выходят за роутер) и два немаршрутизируемых адреса (аналог 192.168.0.0 - два впн-а), и всё это работает вообще без всяких дополнительных настроек без всяких проблем. куда бы я ни коннектился, мой исходящих айпишник всегда тот, от которого до цели ближе всего по маске. вот это прямо крутая фишка ради которой я перевёл все свои внутренние соединения на ipv6, это прямо реально делает жизнь легче.

плюс по мелочи типа SLAAC, это такая недо-DHCP технология, когда роутер может объявлять себя роутером, и устройства в сети буду автоматически подхватывать нужные адреса и цепляться к этому роутеру. в сочетании с пунктом выше это делает ipv6 сети прямо практически магически рабочими. достаточно настроить роутер в сети и любое косое кривое неадекватное устройство прицепится и будет работать как надо.

Мы так сделали в первой версии, оказалось что против ботов это не то чтобы супер эффективно, - боты зачастую заточены на решение капчи второй версии, причём делают это как-то через фермы с живыми людьми, то есть где-то живые люди решают капчи по публичным ключам с сайта, и производят коды решения. и в итоге скрипты просто игнорируют третью капчу и херачат сразу запросы к апи с решениями второй капчи (сразу с правильными ключами в параметрах). Я смотрю эти скрипты подвержены той же проблеме - достаточно передать им решение второй капчи и всё будет тип топ.

В итоге наша финальная версия имеет промежуточный стейдж - после того как бэк решает что третья капча так себе была решена, бэк возвращает запрос на рендер второй капчи с nonce и подписью nonce + дата + решение третьей капчи. и решение второй капчи принимается только если вместе с ним поставляется так же решение третьей плюс nonce плюс дата плюс подпись из ответа на третью. И если дата разъезжается минуты на две - машем ручкой.
Так удалось логически прицепить не решивших третью капчу к решающим вторую и как показала практика это сильно затруднило жизнь всяким умельцам которые покупают на сайтах "решение второй капчи 1 доллар за 10000", потому что это уже просто так не заинтегрировать туда (хотя и можно конечно).

Конечно боты всё равно регистрируются, но теперь судя по запросам из логов это живые люди которые решают капчи в браузерах. Потому что запрашиваются целиком страницы со стилями и скриптами. Но хотя бы не бесконечный поток запросов прямо к api с корректными решенями второй капчи.

Да, я пересобирал на сервере где делал изначальные тестовые прогоны. Ну там вообще не только для этого ядро кастомное, так что было ок. Потом убедился что достаточно поменять iptables c iptables-legacy на iptables-nft через /etc/alternatives, и старые модули не подгружаются со временем от использования любого софта который у нас в продакшене, и дальше на серверах которые уже ставились с nft не парился. Я думаю можно в /etc/modprobe.d/blacklist.conf перечислить основные модули iptables-legacy:

bpfilter

iptable_filter

iptable_nat

iptable_mangle

и этого будет достаточно чтобы те кто попытаются дёрнуть за старый интерфейс обломились.

конечно.

вот кусок из iptables -L -n -v

Chain DOCKER (3 references)
 pkts bytes target     prot opt in     out     source               destination
 8193  452K ACCEPT     tcp  --  !docker_gwbridge docker_gwbridge  0.0.0.0/0            172.18.0.9           tcp dpt:443
18438  891K ACCEPT     tcp  --  !docker_gwbridge docker_gwbridge  0.0.0.0/0            172.18.0.9           tcp dpt:80
15691  854K ACCEPT     tcp  --  !docker_gwbridge docker_gwbridge  0.0.0.0/0            172.18.0.13          tcp dpt:51413
5327K  672M ACCEPT     udp  --  !docker_gwbridge docker_gwbridge  0.0.0.0/0            172.18.0.13          udp dpt:51413

Chain DOCKER-ISOLATION-STAGE-1 (1 references)
 pkts bytes target     prot opt in     out     source               destination
 6762  457K DOCKER-ISOLATION-STAGE-2  all  --  docker0 !docker0  0.0.0.0/0            0.0.0.0/0
    0     0 DOCKER-ISOLATION-STAGE-2  all  --  br-pvythdd8ctos !br-pvythdd8ctos  0.0.0.0/0            0.0.0.0/0
  19M   27G DOCKER-ISOLATION-STAGE-2  all  --  docker_gwbridge !docker_gwbridge  0.0.0.0/0            0.0.0.0/0
  40M   36G RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain DOCKER-USER (1 references)
 pkts bytes target     prot opt in     out     source               destination
 172M  133G RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain DOCKER-ISOLATION-STAGE-2 (3 references)
 pkts bytes target     prot opt in     out     source               destination
    2   386 DROP       all  --  *      docker0  0.0.0.0/0            0.0.0.0/0
    3   937 DROP       all  --  *      br-pvythdd8ctos  0.0.0.0/0            0.0.0.0/0
    0     0 DROP       all  --  *      docker_gwbridge  0.0.0.0/0            0.0.0.0/0
  19M   27G RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0

вот кусок из nft list table ip filter

	chain DOCKER {
		iifname != "docker_gwbridge" oifname "docker_gwbridge" meta l4proto tcp ip daddr 172.18.0.9 tcp dport 443 counter packets 8193 bytes 452260 accept
		iifname != "docker_gwbridge" oifname "docker_gwbridge" meta l4proto tcp ip daddr 172.18.0.9 tcp dport 80 counter packets 18441 bytes 891064 accept
		iifname != "docker_gwbridge" oifname "docker_gwbridge" meta l4proto tcp ip daddr 172.18.0.13 tcp dport 51413 counter packets 15691 bytes 854236 accept
		iifname != "docker_gwbridge" oifname "docker_gwbridge" meta l4proto udp ip daddr 172.18.0.13 udp dport 51413 counter packets 5327475 bytes 672496088 accept
	}

	chain DOCKER-ISOLATION-STAGE-1 {
		iifname "docker0" oifname != "docker0" counter packets 6762 bytes 456593 jump DOCKER-ISOLATION-STAGE-2
		iifname "br-pvythdd8ctos" oifname != "br-pvythdd8ctos" counter packets 0 bytes 0 jump DOCKER-ISOLATION-STAGE-2
		iifname "docker_gwbridge" oifname != "docker_gwbridge" counter packets 19095322 bytes 26769977257 jump DOCKER-ISOLATION-STAGE-2
		counter packets 40298535 bytes 36112505838 return
	}

	chain DOCKER-USER {
		counter packets 171779895 bytes 133264417545 return
	}

	chain DOCKER-ISOLATION-STAGE-2 {
		oifname "docker0" counter packets 2 bytes 386 drop
		oifname "br-pvythdd8ctos" counter packets 3 bytes 937 drop
		oifname "docker_gwbridge" counter packets 0 bytes 0 drop
		counter packets 19102079 bytes 26770432527 return
	}

можно заметить что даже счётчики пакетов примерно совпадают (всё же там была секунда паузы между первой и второй командой). то есть это не дубликаты, это одни и те же правила в ядре, просто выведенные с помощью двух разных утилит

звучит странно.

и nft и iptables-nft это интерфейсы к nftables в ядре. они обе редактируют одни и те же правила и очевидно взаимозаменяемы.

iptables -L -n -v

в моей системе показывает тоже самое что и

nft list table ip filter

я вообще в своём ядре забанил модули которые отвечали за "классический" iptables, и старый iptables невозможно использовать в принципе, ни через cli ни через api. и всё нормально работает.

извиняюсь что повторяюсь, но с iptables-nft докер прекрасно и без проблем работает (и kubernetes, вернее flannel и calico тоже).

fail2ban работает, да я думаю вообще всё работает. я перечислил только то, что я точно пробовал.

iptables-nft консольная утилита полностью повторяющая синтаксис iptables, но работающая с интерфейсом nft в ядре. то есть ей можно колбасить привычные правила и делать всё как обычно, под капотом это всё будет nftables (и даже отображаться в виде длиннющих правил если использовать утилиту nft)

а так в целом есть какие-то проекты типа использования nft вместо iptables для докера - но они в настолько зачаточном состоянии уже годы, что не стоит надеяться что ими можно будет пользоваться. мне кажется все кто хочет просто ставят iptables-nft и пользуются (я реально пытался запустить докер с поддержкой nft, и это где-то в 2020-м было даже хуже чем концепт)

Хорошая инструкция, тоже заморочался два года назад, когда вышал убунта 18.04, где можно было использовать nft вместо iptables.

Два года парился, ломал пальцы и мозги (всё-таки вся эта борода ближе к тому как правила использует компьютер, чем человек), пока в итоге не дочитался до того, что nftables и iptables это проект одной и той же команды и конечно же они сделали iptables-nft, который имеет тот же самый один в один синтаксис что и iptables, но использует kernel интерфейс nft. то есть просто привычная утилита которая не враппер над nftables, а просто имплементирует работу с kernel nft другим синтаксисом (всем привычным).

iptables-nft являются частью iptables, и допустим в убунте их можно просто включить с помощью alternatives.

посмотреть что используется можно сделав iptables -v, например это выглядит так:

root@c2:~# iptables -v

iptables v1.8.4 (nf_tables): no command specified

и это значит что используется iptables-nft

Я реально два года пользовался nft но так и не смог к нему привыкнуть (а я сторонник всего нового) и через два года вернулся на iptables синтаксис, но безусловно пользуясь nft (потому что это крутой новый интефейс для фильтрации пакетов)

Работаю на маке много лет, как так вышло что всё что тут написано я считаю отличным функционалом которым удобно и легко пользоваться? И с удовольствием пользуюсь, и полноэкранным режимом, и ланчпадом (вообще постоянно) и активными углами (лучшая фишка со времён нортон коммандера).

Но ладно, допустим всё это можно назвать вкусовщиной и делом привычки, но объясните мне одну штуку, - вот я пересел на мак в 2009-м году с винды, и макос выходит новый каждый год, и каждая новая версия что-то вносит что-то удаляет, но в целом тебе не надо вообще заморачиваться поставив новую версию - она всё равно будет тем же самым макосом. да я даже уверен что если взять сейчас меня из 2009 и посадить за современный макос, то в принципе мне будет всё сходу понятно, потому что в целом все элементы там же логически и где что искать всё на тех же местах...

Но каждая грёбаная версия винды это цирк с конями, я помню первый переход с 3.11 на 95, ну допустим это был большой скачок, всё сильно поменялось, допустим. Через несколько лет выходит ХР, в которой всё на новых местах, сука. Потом семерка, СУКА, СУКА, СУКА, восьмерка (ну ладно эта была похожа на семерку), потом десятка, ДА ВЫ СУКА ИЗДЕВАЕТЕСЬ ЧТОЛИ? И теперь великолепных богоподобных приверженцев винды собираются в очередной раз как собачек павлова накормить полностью изменённым интерфейсом... Как это можно объяснить логически, это что-ли пользователе ориентированный пример дизайна к которому надо стремиться?

это вроде не анекдот, а реальная ситуация, как дело было.

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

правда и русские не совсем идиоты и карандаши в них были восковые.

с другой же стороны НАСА которые «потратили миллион долларов» на самом деле сначала писали фломастерами, а потом заключили контракт с какой-то частной компанией производителем ручек которые действительно за миллион долларов (только свой, коммерческий, а не налогоплательщиков) разработали ручку и сами пришли к ним и единственное условие было что НАСА упоминает о том что в космосе пишут ручками этой компании…

ручки эти кстати потом замени и наши карандаши и американские фломастеры

Потом приходит менеджер и мягко объясняет вам что вы токсичный член команды, и если оба подхода работают, и разницы между ними нет (миллисекунды) то обижать других членов команды критикуя их решения подрывает командный дух. Такие дела...

Блин, я читал и прям ждал что в конце будет реклама «хочешь стать программистом? трёхнедельный курс с гарантией трудоустройства…»

Прям немножко расстроился. Без такой вишенки статья выглядит хорошей, но неполной =(

Information

Rating
Does not participate
Registered
Activity