Администрирование

Разработка безопасного программного обеспечения — одна из самых распространенных тем, связанных с ИБ, в 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 так, чтобы после неудачного обновления вернуть рабочую систему за несколько минут.

Сколько замечал, для Debian stable никто не делал отдельных репозиториев со свежими графическими драйверами, в отличие от Ubuntu, а поиграть в новые игры или получить свежие фишки Mesa хочется, не переходя на свежие дистрибутивы вроде Arch Linux или Fedora. Пакетный менеджер в Debian очень строгий, и смесь Ubuntu-ppa он терпеть не будет, так что придётся всё собирать вручную из исходников.

В статье описана сборка свежих драйверов Mesa3D для Debian Trixie с использованием Podman и манифеста Kubernetes.

TL;DR. Я выбирал Timeweb не из-за цены, а из-за «имени» и обещанной надёжности. За май–июнь 2026 года зона ams-1 (Амстердам, дата-центр Qupra) пережила шесть крупных аварий с суммарным окном недоступности около 46 часов — причём последняя авария на момент написания этих строк всё ещё не закрыта и идёт уже более 15 часов. Хостер на своём сайте обещает Tier III и аптайм 99,98 % — это 1 час 45 минут простоя в год. За два месяца факт превысил годовой лимит этого обещания примерно в 26 раз. Все цифры ниже — не мои домыслы и не «жалобы в чате», а сообщения из официального канала статусов самого Timeweb.

Когда сверху прилетает задачка запустить FinOps, чаще всего она звучит так, как будто речь идет про кнопку. Нажал - и косты порезались сами собой, инженеры в тот же миг стали гипер-ответственными, а финансы перестали дышать в затылок. Вот только никакой кнопки, само собой, нет. Есть только точка ноль - тот самый момент, когда ты сидишь с этой задачей и тупо не знаешь, с какой стороны вообще подходить к ее решению.

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

Кстати, все это мы в свое время обсуждали (да и сейчас продолжаем) в канале Практики FinOps в Telegram. Там сидят те, кто проходил этот путь раньше, - иногда один вопрос в чате экономит неделю собственных экспериментов. Залетайте, если тоже на старте.

Демон cron знаком каждому, кто админит Linux. Он крутит бэкапы, чистит временные файлы и запускает скрипты, о которых все уже давно забыли. Однако многие не знают, что одна строка в crontab способна снести данные, забить диск, устроить форк-бомбу или открыть лазейку для хакера. Под катом я разберу, когда и как именно cron становится опасным, и какие команды помогут держать его в узде.