Два self-hosted S3, которые доверяют друг другу: DataSafeS3 v1.1.0

v1.1.0: убрали HTTP-костыль для sink’ов, закрыли /metrics, Teams в UI, trusted clusters. Про v1.0.3 и типичный «pairing failed» на Docker — внутри. Продолжение серии.

v1.1.0: убрали HTTP-костыль для sink’ов, закрыли /metrics, Teams в UI, trusted clusters. Про v1.0.3 и типичный «pairing failed» на Docker — внутри. Продолжение серии.

Вас тоже достаёт спам и реклама? Рекламу я блокирую через свой DNS сервер и локальными CSS фильтрами, а вот для почты пришлось придумать что-то другое.
Схема многоступенчатая. Первыми срабатывают фильтры Яндекса и Mail — что-то они отсеивают сами, ещё до пересылки. То, что прошло через них, падает на мой сервер, где стоит SpamAssassin. Ловит ещё часть. Но после двух уровней всё равно что-то просачивается, спамеры же не сидят без дела. И вот этот остаток доезжает до Gmail и что-то оседает в папке Спам, а что-то попадает во входящие и приходит раздражающее уведомление. Хотелось, чтобы со временем не накапливался мусор в папках, который надо разгребать вручную. Особенно важно заблокировать то, что не является полностью спамом: приглашения на конференции, партнёрские предложения, кредиты — формально не нарушение, поэтому байесовский фильтр такие вещи плохо ловит.
Локальная BERT-модель закрыла обе проблемы. Взял ruBert-base-antispam с HuggingFace — файн-тюн на базе DeepPavlov/rubert-base-cased-conversational. 177 миллионов параметров, 12 слоёв трансформера, 768 hidden size. Физически не принимает больше 512 токенов на вход. В памяти занимает около 550 МБ, ответ приходит за 100-200 миллисекунд. Бинарный классификатор — текст на входе, 0 или 1 на выходе, никаких промптов и reasoning. Идеально!

Надоело каждое утро вручную обходить 5+ площадок — написал агрегатор на Python. Собирает вакансии с HH, Habr Career, GeekJob и Telegram-каналов, убирает дубли, присылает в Telegram. Код открытый.

GUI-утилита в один клик, которая автоматически разворачивает на копеечном VPS сразу 6 протоколов обхода блокировок. бесплатная генерация доменов для обмана DPI, автоматический выпуск TLS-сертификатов, NaiveProxy и olcRTC

Разработка безопасного программного обеспечения — одна из самых распространенных тем, связанных с ИБ, в 2026 году. Вокруг нее мы все чаще слышим слова «управление секретами», «безопасная доставка секретов» и т.д. Мы уже писали практическую статью тут, но, как показывает практика, системы управления секретами не крутятся только вокруг key-value значений или динамических секретов для database. Я Руслан Гайфутдинов, ведущий пресейл-инженер системы управления секретами StarVault в Orion soft. В этой статье предлагаю рассмотреть еще один (не забытый, а, скорее, не известный) механизм секретов LDAP.

В этой статье я хочу рассказать, как после обучения Cisco CCNA дальше углубить свои знания и развиваться в направлении компьютерные сети. Я сам проходил профессиональную переподготовку на курсе инфокоммуникационные сети, что в дальнейшем оказалось учебными материалами, очень напоминающими материалы CCNAv6 Routing and Switching Essentials.
После чего задумался, как применять свои навыки и развиваться как сетевой инженер.

Привет, Хабр! Меня зовут Алексей, и я занимаюсь беспроводными технологиями. Среди прочего, компания, в которой я работаю, проводит радиоразведку, радиопланирование, проектирование новых беспроводных сетей и аудит существующих.
За последние полтора года я заметил устойчивый рост запросов именно на детализированный аудит беспроводных сетей – причём в области промышленного интернета, логистических комплексов, складов и т.д. Заказчики чаще всего приходят с конкретной задачей: «Сделайте что-нибудь, чтобы всё работало получше, но без замены железа». И, как правило, они уже обращались к кому-то за аудитом, но результат их не удовлетворил.
Именно такому зпросу и будет посвящена данная статья. В виде пошагового руководства я распишу, как провести аудит беспроводной сети промышленного или логистического объекта, диагностировать проблемы и найти решения. Статья будет полезна специалистам по аудиту, коллегам на предприятиях, которые хотят попробовать решить проблемы своими силами, руководителям которые выбирают подрядчика для аудита.

В одной из предыдущих статей я поднимал вопрос о том, что интерфейс системы целиком и полностью работает на Английском языке. Я пообещал, что в будущем реализую поддержку нескольких языков, и вот этот момент настал. Но, как это часто бывает, пока я копался в коде ради мультиязычности, попутно переписал пару системных модулей, чтобы они наконец-то работали стабильно ну и не ручками же вводить переменные в файл пакета. Поэтому релиз 3.6.6 получился тройным: Системные исправления, исправления интерфейса ну и новый плагин.

Команда VK Cloud перевела разбор запуска self-hosted (размещаемого на собственных мощностях), read-only ИИ-агента внутри кластера Kubernetes, где всю цепочку CI/CD обслуживают GitHub Actions и Argo CD Image Updater. Никакие данные не покидают кластер, облачные ИИ-провайдеры не задействованы.

С момента написания первой статьи о B4 прошло полгода. Казалось бы, не очень много времени, но софтина получила ну очень большое количество фич, о которых хочется рассказать подробно. Не буду скрывать: хабраэффект сделал своё дело, и благодаря большому интересу после первой статьи очень многие не разочаровались в отсутствии какого-то функционала, а активно помогали - коммуникацией, запросами, тестированием, - благодаря чему все эти фичи в B4 и появились.
В итоге на сегодняшний день B4 - это не инструмент для обхода блокировок (коим и задумывался изначально), а полноценный сетевой мультитул с гибкой и продвинутой маршрутизацией таргетированного трафика.

Уволенный уносит ноутбук. Новичок выходит без ноутбука. Между ними — «серая зона» из техники, которая числится за людьми только на бумаге. Считаем, сколько это стоит компании в год.

HTTP-прокси вспоминают в двух случаях: когда сервису нужно вывести наружу строго ограниченный трафик или когда инцидент уже случился и нужно понять, кто и куда ходил. Первый вариант дешевле.
Меня зовут Саша Скоков, я блогер, инженер группы сопровождения системной инфраструктуры в ОККО и в этой статье разберу, как работает Squid в проде.

Привет, Хабр!
На связи команда инженеров сервисного центра с очередной нетривиальной задачей, которую мы решали у одного нашего крупного заказчика.
Многие Linux-серверы со временем сталкиваются с одной и той же проблемой: корневая файловая система постепенно «обрастает» данными приложений, снэпшоты виртуальных машин становятся слишком большими, резервное копирование занимает всё больше времени, а свободного места для классической миграции уже не остаётся. Особенно часто это встречается на старых системах, где изначальная разметка дисков создавалась без понимания того, какое прикладное программное обеспечение будет использоваться в будущем.
Так возникает необходимость вынести данные приложения на отдельную файловую систему, но традиционный подход требует полного копирования больших объёмов данных и длительного простоя сервисов. В этой статье мы покажем способ изменить разметку уже работающей Linux-системы без переустановки ОС и без копирования сотен гигабайт данных.

Безопасный AI-мониторинг Oracle в закрытом контуре с использованием Python, Ollama и V$WAITCLASSMETRIC
Введение
В существующей системе мониторинга Oracle уже использовалось разработанное мной решение, которое с интервалом в 1 минуту собирало метрики производительности из представления V$WAITCLASSMETRIC и отображало их в Grafana. Графики наглядно показывали изменения времени ожиданий в классах User I/O, Commit, Concurrency и других, однако они показывали лишь сам факт изменения нагрузки, не объясняя его причины.
Возникла идея: если метрики уже собираются для построения дашбордов, почему бы одновременно не отправлять их локальной языковой модели? Тогда вместе с графиком можем сразу отображать текстовое объяснение происходящего, список наиболее вероятных причин изменения показателей и рекомендации, с чего начать дальнейшую диагностику.
Так появился небольшой эксперимент — дополнить существующую систему мониторинга Oracle локальным AI-ассистентом.

Представьте ситуацию: вы приходите к руководству с четким техническим обоснованием миграции в облако: оборудование устаревает, вычислительных мощностей не хватает, риски простоев растут. Рассказываете, как облако поможет быстрее запускать новые сервисы, масштабировать инфраструктуру и снизить нагрузку на команду. А в ответ слышите: «Бюджет не согласован. Живите с тем, что есть».
Знакомая ситуация? Проблема не в качестве ваших аргументов. Проблема в том, что ИТ и бизнес говорят на разных языках. Вы говорите на языке технологий, а CFO – на языке финансов. У вас даже KPI разные: для вас важны аптайм, время восстановления, скорость развертывания сред, в то время как для финансового директора – только деньги.
Пока вы не найдете точки соприкосновения, договориться о бюджете на миграцию в облако будет тяжело. Но не стоит отказываться от технологической логики, просто нужно научиться переводить её на язык инвестиций. Показать CFO, что облако выгодно не потому, что оно «гибкое, масштабируемое и современное», а потому что оно приносит деньги или помогает перестать их терять.

Всем привет! Это первая публикация из цикла статей про распределение сервисов в кластере виртуализации. В статье будет описан один из подходов к решению задачи от определения проблемы до результатов тестов с демонстрацией работы готового решения.

Привет, Хабр! На связи Игорь Шишкин, я руковожу отделом разработки облачной платформы Рег.облака. Когда инженеру нужно где-то сложить данные, первая мысль — взять диск побольше. Но внутри нашей инфраструктуры почти всё, что растет и читается параллельно, давно переехало в S3: логи, метрики, бэкапы баз, образы контейнеров, артефакты сборок. Диск остался только там, где он по-настоящему незаменим. В этой статье я расскажу, где именно мы используем объектное хранилище и почему в каждом из этих мест выбрали именно его, а не диск.

Привет, Habr! Меня зовут Валентин, я DevOps-инженер команды Platform V Kintsugi. Мы занимаемся развитием облачного сервиса и на практике регулярно сталкиваемся как с архитектурными задачами построения распределённых систем, так и с вопросами обеспечения их безопасности.
В предыдущей части мы подробно разобрали механизм делегирования TLS-соединения на уровень Service Mesh и показали, как Egress Gateway может выступать полноценным участником PostgreSQL handshake. Однако этот сценарий рассматривался в упрощённой конфигурации — один сервис, один сертификат, одно подключение.

Доменные имена не резолвятся, страницы висят, а по IP всё доступно. В логах DNS‑сервера при этом чисто, BIND запущен, конфигурация на первый взгляд выглядит рабочей.
Разбираемся, как одна ошибка в forwarders может отправить DNS‑запросы по кругу и превратить обычный резолвинг в цепочку таймаутов.

Как в Debian настроить Btrfs, Snapper и grub-btrfs так, чтобы после неудачного обновления вернуть рабочую систему за несколько минут.