Собрали бы cloud-init образ сами, это ведь намного интереснее, чем загрузить готовый. Возможностей автоматизации после старта там огромное количество и все это гибко настраивается под нужды среды или задачи образа.
Кстати, всю конфигурацию VM в PVE можно (и удобнее :) делать через этот же qm.
Несколько лет назад искали MFA решение и в т.ч. это смотрели.
Забавно было на встрече с сейлами слушать, почему они работают только как SaaS и в этот момент смотреть на их status page, где было несколько инцидентов недоступности за последние пару месяцев :)
Как клиент для обучения - почему бы и нет, новичкам может будет удобно интерпретировать ошибки и получать runbook, плюс справка под рукой. Но вот попытка защищать от опасных команд выглядит спорно, мне кажется. С root можно сломать все запустив чужой бинарник, собственный скрипт или просто cat - так отучите думать о том, что вообще вводится в терминал и к чему это приведет.
Да, established и правда забывается, я вот сам только что забыл :)
Скорость обновления должна сильно зависеть не только от размеров и топологии кластера. Как минимум, я вижу такие зоны влияния: конфиг (batch period, slice size и т.п.), нагрузка на api и controller (количество изменений, длина очереди).
Кстати, вам действительно нужно добиваться 0% ошибок при выкатке? Какой-то очень жестокий SLO получается.
А почему не используется хотя бы netflow для определения цели атаки?
И какой у вас будет алгоритм действий, если это будет не простой TCP/HTTP флуд в адрес, а какой-нибудь UDP volumetric/DNS amplification и прочие разновидности? А если уже не на одного клиента, а целенаправленно на вашу инфраструктуру?
Думаю, что на ваших масштабах минимальная автоматика для diversion/RTBH необходима. В конце-концов, есть gatekeeper.
Намного интереснее смотреть, как от атак на ARP защищаются пятью разными способами, пока где-нибудь рядом летят IPv6 RA от злоумышленника.
Ну, классика, в целом, в самом начале статьи:
Проблемы от недооценки рисков, отсутствия DR стратегии и, видимо, экономии на специалистах.
Хорошо ещё, если после таких инцидентов выводы действительно делаются.
Интересно будет, когда модель отправит что-нибудь типа:
Не говоря о том, что пайп - это валидная конструкция для bash.
Чтобы их не забывать, ими нужно пользоваться. А чтобы вспомнить, есть man.
Эта задача решается одним скриптом на bash, а не обращением к LLM.
В таком случае, да, выглядит разумным решением.
Это скорее повод задуматься об изоляции нагрузок. Например, через виртуализацию, контейнеры или те же cgroups.
Этим же админам лучше оставить и развертывание серверов, мониторинг и оценку состояния систем :)
А еще не помешало бы предварительно сделать нагрузочные тесты и увидеть работу page cache там.
И available при этом ещё 30 gb?
Если вы постоянно пишете с sync, далеко масштабировать свое решение у вас не получится - IO дисков кончится раньше.
Для управления page cache есть vm.dirty, как минимум.
Собрали бы cloud-init образ сами, это ведь намного интереснее, чем загрузить готовый. Возможностей автоматизации после старта там огромное количество и все это гибко настраивается под нужды среды или задачи образа.
Кстати, всю конфигурацию VM в PVE можно (и удобнее :) делать через этот же qm.
Синтаксис: https://chromeenterprise.google/policies/ca-certificates-with-constraints/
Конфигурация политик в Linux: https://support.google.com/chrome/a/answer/9027408?hl=en
Для Cursor может и не статистика. Только историй в таком духе про LLM все больше.
В статье непонятно в итоге, реализовали или нет.
Несколько лет назад искали MFA решение и в т.ч. это смотрели.
Забавно было на встрече с сейлами слушать, почему они работают только как SaaS и в этот момент смотреть на их status page, где было несколько инцидентов недоступности за последние пару месяцев :)
Так есть у вас on-premises вариант, полностью независимый от ваших ресурсов и доступа в интернет?
Тоже никак не понимаю, откуда желание использовать все эти менеджеры в принципе.
Имхо, продуманный нейминг и DNS в принципе закрывает эту проблему. В конце-концов, есть .ssh/config и known_hosts со всеми этими дополнениями.
IaC для VCD вспоминаю как кошмар. Раньше управляли правилами FW в NSX через terraform - пайплайны по часу были обычным явлением.
API у него тоже монструозный :)
Уже думали (и даже начинали) писать свою автоматизацию под это, но уехали с VCD раньше.
Как клиент для обучения - почему бы и нет, новичкам может будет удобно интерпретировать ошибки и получать runbook, плюс справка под рукой. Но вот попытка защищать от опасных команд выглядит спорно, мне кажется. С root можно сломать все запустив чужой бинарник, собственный скрипт или просто cat - так отучите думать о том, что вообще вводится в терминал и к чему это приведет.
Хорошая статья, спасибо.
Да, established и правда забывается, я вот сам только что забыл :)
Скорость обновления должна сильно зависеть не только от размеров и топологии кластера. Как минимум, я вижу такие зоны влияния: конфиг (batch period, slice size и т.п.), нагрузка на api и controller (количество изменений, длина очереди).
Кстати, вам действительно нужно добиваться 0% ошибок при выкатке? Какой-то очень жестокий SLO получается.
Интересно, почему? Эксплуатировал Nutanix и никогда не видел такой проблемы. Да и в обычном Linux KVM с OVS - тоже.
А обычный curl ваши сценарии тестов не покрывает?
Если платформа не совсем на коленке собрана, то в том или ином виде в ней будет какой-то SDN для организации сети VM.
BGP в таких системах используется для доставки трафика на VM.
Собирать сети на растянутых L2 доменах в масштабах хостинга/облака - это собирать огромный домен отказа, бороться со штормами и прочими приколами L2.
А почему не используется хотя бы netflow для определения цели атаки?
И какой у вас будет алгоритм действий, если это будет не простой TCP/HTTP флуд в адрес, а какой-нибудь UDP volumetric/DNS amplification и прочие разновидности? А если уже не на одного клиента, а целенаправленно на вашу инфраструктуру?
Думаю, что на ваших масштабах минимальная автоматика для diversion/RTBH необходима. В конце-концов, есть gatekeeper.