Сергей Озеранский

Это не цветокоррекция. Это реальность ⛵️

"Вот такая вот хня, собачка" Разница DC дисков от потребительных

Выпустил большую статью про tempus.build https://vas3k.club/project/32399/

У tempus.build появился YouTube канал - https://www.youtube.com/@tempusbuild Подписывайтесь, ставьте лайки и жмите колокольчик (чтобы это не значило 😅️️️️️️). Это очень ценно для продукта и меня лично. Спасибо 😊️️️️️️

У tempus.build появился YouTube канал - https://www.youtube.com/@tempusbuild Подписывайтесь и ставьте лайки. Это оцень ценно для проудкта и меня лично. Спасибо 😊️️️️️️

Под капотом ИИ-агента: от бизнес-задачи до GPU ИИ-агент выполнил тестовую задачу. Теперь его нужно подключить к корпоративным системам и запустить под рабочей нагрузкой. Как распределить GPU, организовать доступ к данным и понять, где искать причину сбоя? 29 октября в 12:00 на вебинаре эксперты Deckhouse и Kept разберут всю цепочку: от инфраструктуры и инференса до действий агента в корпоративных приложениях. На примере платформы KeptStore, развёрнутой на Deckhouse Platform, обсудим:

• инфраструктуру для контейнеров и виртуальных машин; • выделение GPU с помощью DRA; • масштабирование, отказоустойчивость и метрики инференса; • работу агента с данными, правами и секретами; • границы ответственности инфраструктурной, прикладной и AI/ML-команд.

А также покажем демо автономного ИИ-бухгалтера. Узнать подробности и зарегистрироваться Реклама. АО "ФЛАНТ". ИНН 7723661439.

↖️↖️↖️ РЕГИСТРАЦИЯ НА AVITO INFRAWEEN PARTY ↖️↖️↖️ Обсудите реальные инфраструктурные задачи, а после поучаствуйте в чемпионате по метанию старой сломанной техники. P. S. Если хотите прийти в костюме (Хеллоуин всё-таки), максимально welcome. #infra #sre #dba #devops

Интересный факт, работа с кешами у конкурентов tempus.build часто встречается как дополнительный продукт, который дополнительно тарифицируется. В tempus.build это БЕСПЛАТНО и по умолчанию включен для каждого репозитория подключенной организации. Эффект вы увидите уже со второго запуска раннеров, когда кеш будет прогрет.

Кеши это одна из областей, где очень много возможностей оптимизировать и экономить ресурсы. В CI/CD один из злавных ресурсов это время. За прошлую неделю в tempus.build выпущено два очень важных и крупных обновления по работе с кешем. С одним я уже ознакомил вас с помощью ролика тут - это BuildKit cache. Но в Github CI/CD есть еще actions cache, который очень тоже можно оптимизировать - что и было сделано. Подробности в видео

а у тебюя как дела с продажами?

Проделал большую работу по работе с кешем сборов в tempus.build. В видео объяснение того, как вообще работает кеширование в Docker, как это реализовано в tempus.build, и почему это лучше чем в github runners, а так же советы по кешированию слоев.

А я тут рендерю 4к ролик по cache в tempus.build...

Компрометация emSign ECC Root CA - G3: что стоит проверить в Python-сервисах и контейнерах Удостоверяющий центр eMudhra (emSign) отозвал восемь промежуточных сертификатов, выпущенных под корнем emSign ECC Root CA - G3: их закрытые ключи скомпрометированы. С таким ключом можно выпустить валидный сертификат на любой домен. Если атакующий при этом находится между клиентом и сервером (MITM), он может читать и подменять TLS-трафик клиента, который доверяет этому корню. Остальные корни emSign не затронуты. Где этот корень есть 1. certifi < 2026.10.19 (GHSA-6q48-6c7w-9gw2, critical). Им по умолчанию пользуются requests, urllib3 и pip. Версия 2026.10.18 удалила все корни emSign, а 2026.10.19 вернула незатронутые. 2. Системный пакет ca-certificates. В Debian 13 (trixie) исправление вышло в 20250419+deb13u1, но пока только в trixie-security. Официальные образы python:*-trixie, собранные раньше, содержат старую версию, и образ, закрепленный по digest, ее не получит. Важно: Trivy и подобные сканеры видят уязвимость в certifi, но не в системном наборе сертификатов. Если в приложении выставлены REQUESTS_CA_BUNDLE или SSL_CERT_FILE, requests и ssl проверяют TLS по системному файлу, а не по certifi. В таком случае обновление одного certifi проблему не закрывает. Как проверить Каким набором пользуется процесс:

env | grep -E 'REQUESTS_CA_BUNDLE|SSL_CERT_FILE'
python -c "import certifi; print(certifi.__version__, certifi.where())"

Есть ли корень в системном наборе:

openssl crl2pkcs7 -nocrl -certfile /etc/ssl/certs/ca-certificates.crt \
  | openssl pkcs7 -print_certs -noout | grep 'emSign ECC Root CA - G3'

То же для certifi:

grep -c 'emSign ECC Root CA - G3' "$(python -m certifi)"

Митигация certifi: обновить до 2026.10.19 или новее и пересобрать образы, в которые он встроен. Системный набор в Debian или Ubuntu, если пакет с исправлением еще недоступен: отозвать доверие к корню при сборке. Пример для Dockerfile:

RUN grep -qx 'mozilla/emSign_ECC_Root_CA_-_G3.crt' /etc/ca-certificates.conf \
    && sed -i 's|^mozilla/emSign_ECC_Root_CA_-_G3\.crt$|!&|' /etc/ca-certificates.conf \
    && update-ca-certificates --fresh \
    && ! test -e /etc/ssl/certs/emSign_ECC_Root_CA_-_G3.pem

Сборка упадет, если строки нет или корень остался в наборе. apt-get upgrade не нужен, сборка остается воспроизводимой. Когда базовый образ пересоберут с исправленным ca-certificates, этот шаг можно убрать. Если certifi нельзя обновить, потому что его версию жестко закрепляет другая зависимость, используйте системный набор с удаленным корнем: REQUESTS_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt и SSL_CERT_FILE на тот же файл. Учтите, что часть библиотек берет certifi напрямую, мимо этих переменных.

Я так понимаю никто на PHP не пишет? Видели суету с CVE (https://jackalsyn.com/posts/php-up-2026.html)

Больше всего меня бесят те, кто создает встречи и не устанавливает напоминание. Обожаю...