Несколько раз пытался получить эту «bugbounty». В итоге за обход авторизации, и по факту возможность слить большую часть абонбазы мог получить 20$. От вознаграждения отказался.
В итоге, компания «Киевстар» — жлобы еще те.
Еще хуже скажу, не один из крупных операторов связи Украины особо платить денег за уязвимости не собираются.
Могу написать пост об моем опыте связки postfix + dovecot + rspamd + clamav с использованием dkim, dmarc и некоторых своих разработках для этого чуда. Ну еще о том, как это дело кластеризовать в несколько датацентров и пережить падения половину машин.
Если, конечно, будет кому-либо это интересно.
Так точно, мой властелин!
Но у меня есть замечания. Мой разум не вместится в один психоконтейнер. По предложению Кусуну Матата из системы Обиван-2 — можно использовать таулдык майя.
;)
Как происходит сбор данных? Используете пассивные, активные или комбинированные методы проверки?
Данные сливаются в один ЦОД или в несколько? Если в один, то не боитесь стать «слепыми», если ЦОД с мониторингом уйдет в оффлайн?
Какой используете мониторинг?(кроме какти — его сложно не заметить) Вендорный, самописный или что-то из открытого?
Используете машинное обучения для прогнозирования выходу из строя оборудования или для автоматизации процессов?
Собрать Ваш код на D не удалось. (та и время тратить не хотел)
Проведя тест(test1.go) на среднестатистическом сервере, у меня получилось ~16970.795 rps
Первое что бросается в глаза — отсутствие url роутера.
Без роутера(test2.go) получаем +~88.51 rps.
Во время сборки кода на D, заметил интересную строку: Compiling diet template 'index.dt'…
Будем считать, что D загружает шаблон в память.
Третей тест (test3.go) показывает ~55588.8625 rps, что дает ~+38618 rps
Исходя из Ваших тестов, возьмем среднепальцеве число производительности кода D в 17000 rps.
Если этот код на D загружает все в память, то этот тест показывает, на сколько в хлам GO разбивает производительность D. Это выглядит как 17000 vs 55000 rps
> В смысле Google Public DNS не видел в этих AS'ках авторитативных серверов или не обслуживал запросы пользователей из них?
Не обслуживал запросы. Отваливалось по таймауту.
> В любом случае налицо нерасторопность администраторов этих AS, не могу поверить что «Корпорация Добра» решала вопросы сетевой связанности после обращения к ней в поддержку так долго.
Это было нарушения со стороны монтерев процесса настройки сети. Были поймание на горячем и наказаные. Потом бегали и исправляли…
«Корпорация Добра» совершенно не отвечает на noc@… и другие… Единственный вариант добиться контакта — отправить в блекхол их важные адреса и передача их аплинкам…
> Вполне себе реалистичный сценарий, особенно если последняя цифра в SOA записи, так называемая «Minimum TTL» или «The negative result TTL» установлено в относительно большое значение.
Возможно… Но другие сервера работают без таких приколов…
google public dns последние 2 года совершенно неадекватно себя ведет с новыми записями или апдейтами.
Бывали случаи, что на некоторые AS-ки переставал работать резолвинг на несколько недель.
Есть подозрения, что они парсят данные из страниц, и потом пробуют его проверить. Если это подтвердится — то все будет логично — они кешируют зону из статусом NXDOMAIN…
В итоге, компания «Киевстар» — жлобы еще те.
Еще хуже скажу, не один из крупных операторов связи Украины особо платить денег за уязвимости не собираются.
Если, конечно, будет кому-либо это интересно.
простите, не удержалсяНо у меня есть замечания. Мой разум не вместится в один психоконтейнер. По предложению Кусуну Матата из системы Обиван-2 — можно использовать таулдык майя.
;)
Данные сливаются в один ЦОД или в несколько? Если в один, то не боитесь стать «слепыми», если ЦОД с мониторингом уйдет в оффлайн?
Какой используете мониторинг?(кроме какти — его сложно не заметить) Вендорный, самописный или что-то из открытого?
Используете машинное обучения для прогнозирования выходу из строя оборудования или для автоматизации процессов?
Линукс — это конструктор.
Если nvidia захочет — сделает все нужное.
Писал на geo@ несколько раз — полный ингор.
Нашел занимательный баг в маршрутизации на juniper-ах вместе с межународними noc-ами.На Go запускал как и Ваш, так и свой. Результаты тестов в репозиторию
Хотя теоретически D — должен работать быстрее GO.
В go пожертвовали некоторою производительностью для простоты.
Собрать Ваш код на D не удалось. (та и время тратить не хотел)
Проведя тест(test1.go) на среднестатистическом сервере, у меня получилось ~16970.795 rps
Первое что бросается в глаза — отсутствие url роутера.
Без роутера(test2.go) получаем +~88.51 rps.
Во время сборки кода на D, заметил интересную строку: Compiling diet template 'index.dt'…
Будем считать, что D загружает шаблон в память.
Третей тест (test3.go) показывает ~55588.8625 rps, что дает ~+38618 rps
Исходя из Ваших тестов, возьмем среднепальцеве число производительности кода D в 17000 rps.
Если этот код на D загружает все в память, то этот тест показывает, на сколько в хлам GO разбивает производительность D. Это выглядит как 17000 vs 55000 rps
Сам код: github.com/vitalvas/go-benchmark
Не обслуживал запросы. Отваливалось по таймауту.
> В любом случае налицо нерасторопность администраторов этих AS, не могу поверить что «Корпорация Добра» решала вопросы сетевой связанности после обращения к ней в поддержку так долго.
Это было нарушения со стороны монтерев процесса настройки сети. Были поймание на горячем и наказаные. Потом бегали и исправляли…
«Корпорация Добра» совершенно не отвечает на noc@… и другие… Единственный вариант добиться контакта — отправить в блекхол их важные адреса и передача их аплинкам…
> Вполне себе реалистичный сценарий, особенно если последняя цифра в SOA записи, так называемая «Minimum TTL» или «The negative result TTL» установлено в относительно большое значение.
Возможно… Но другие сервера работают без таких приколов…
Бывали случаи, что на некоторые AS-ки переставал работать резолвинг на несколько недель.
Есть подозрения, что они парсят данные из страниц, и потом пробуют его проверить. Если это подтвердится — то все будет логично — они кешируют зону из статусом NXDOMAIN…