Системное администрирование *

Поддерживать стабильную работу сетевой инфраструктуры крупного предприятия — задача непростая. Взаимодействие промышленных и корпоративных сетевых сред на предприятиях требуют гибкого подхода к сетевым архитектурам. Именно здесь особенно важна грамотно спроектированная маршрутизация и устойчивость соединений. Правильный выбор BGP-решений, будь то внутренний iBGP или внешний eBGP, оказывает значительное влияние на производительность и отказоустойчивость сетевой инфраструктуры.

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

В статье описан способ быстрого превращения обычного VPS с Debian 13 в полноценный OpenWrt роутер за 20 секунд одной командой.

Добавить каталог в PATH кажется тривиальной задачей – пока всё не перестаёт работать. Почему команда «не найдена», какой файл конфигурации действительно читает ваш shell и что именно вы добавляете в переменную окружения? В статье – аккуратный разбор этого процесса с практическими проверками и типичными ловушками, в которые регулярно попадают начинающие администраторы Linux.

В какой-то момент cron-заданий становится много, появляются сложные зависимости между скриптами, когда результат выполнение одного важен для начала работы другого. Балансировать такую историю доводится сис.админу, DevOps'у или разработчику. С этого и начинается наш рассказ.

Казалось бы, права на чтение — что с них взять? Оказывается, в Kubernetes разрешение nodes/proxy GET позволяет выполнять любой код в любых подах кластера. Уязвимость уже нашли в популярных Helm-чартах, включая Prometheus, Datadog и Grafana. И да, команда Kubernetes решила это не исправлять.

Привет, Хабр! Меня зовут Ольга, я инженер по автоматизации в компании РЕД СОФТ. Моя работа – превращать сложные и рутинные задачи системных администраторов в простые и понятные конфигурации в РЕД АДМ. Сегодня поговорим о системе, которая у многих администраторов вызывает легкую (или не очень) дрожь – о SELinux.

Для многих технических специалистов AWX на протяжении многих лет был синонимом «бесплатного Ansible Tower» — надёжным и функциональным решением для управления Ansible-автоматизацией. Это был стандарт де-факто для тех, кто хотел получить удобство (практически) "коробочного" решения и функциональность корпоративного уровня, не вкладываясь в лицензии коммерческого решения.

Однако 2 июля 2024 года вышел релиз AWX версии 24.6.1, который стал последним на данный момент выпуском проекта. С тех пор прошло более полутора лет, а новых релизов так и не появилось. В репозитории проекта на GitHub висит предупреждение: «Releases of this project are now paused during a large scale refactoring». Для сообщества, активно использующего или планирующего использовать AWX как основной инструмент централизованного управления Ansible-автоматизацией, эта ситуация вызывает закономерные вопросы: Что происходит с проектом? Есть ли у него будущее?

Для конечного пользователя не совсем очевидно, но AWX не умирает, а кардинально трансформируется. В данной статье мы разберем текущую ситуацию вокруг AWX, опираясь на официальные анонсы, технические дискуссии разработчиков и статусы ключевых проектов. Проанализируем архитектурные изменения проекта. Разберемся, почему эти изменения были неизбежны, что именно было «вырезано» из проекта и что всё это значит для вас — инженеров ИТ инфраструктуры и архитекторов автоматизации, которые используют AWX в своей работе и проектах.

В преддверии выхода очередного шедевра (хотя не факт) от Capcom, хотелось бы рассказать одну занятную вещь, на которую я обратил внимание в крайних трейлерах этой игры.

TLDR: Создана рабочая легковесная реализация AmneziaWG для Mikrotik для подключения к AmneziaWG серверам.

Генератор на основе AWG-конфига

Github

upd: Добавлена поддержка протокола AmneziaWG v2.

Первое. Предупреждаю заранее. Эта статья не является технической, и ничего нового конкретно в техническом плане вы из неё не вынесите. Это просто повторение и закрепление тех вещей, которые я пытаюсь продвигать уже который раз.

Второе. Некоторым может показаться, что в статье много негатива. Я не испытываю неприязни или ненависти к каким-то конкретным людям. Не потому, что я добрый. А потому, что я рассматриваю их как явление. Как некоторую стихию, которую невозможно победить и перевоспитать. И моё несогласие с законами физики никак не избавит меня от последствий, если я вдруг решу выпрыгнуть в окно. Со стихией бороться бесполезно, такие люди были, есть и будут всегда и везде. Можете назвать это не явлением, можете назвать это типажом. Очевидно также, что конкретный человек может включать в себе несколько типажей и менять их с течением лет под воздействием внешних обстоятельств. И сам я не исключение.

Третье. Разбирать ситуации я буду на примере системного администрирования. Но вы можете подставлять свои должности и технологии, суть не поменяется.

Четвёртое. Многим кажется, что я то встаю на сторону руководителей, то на сторону простых сотрудников. Прочитав эту статью до конца вы поймёте, на чьей я стороне.

Привет, Хабр!

Многим из нас не раз приходилось настраивать интеграцию того и сего c Active Directory по LDAP, и в этот момент начинается судорожный поиск в гугле, как же делалась эта конкретная штука, было же что-то такое. Пусть обобщённая информация останется здесь.

В 2026 году асинхронный Python уже никого не удивляет. Мы привыкли к автоскейлингу в облаках, но что делать, если ваш бюджет на инфраструктуру равен нулю, а в распоряжении есть только «печка» из 2012 года? Рассказываю про личный опыт выжимания максимума из FastAPI на AMD FX-8320: от тюнинга ядра Linux и PostgreSQL до миграции на Ed25519 и использования Rust-сервера Granian.

Хабр, привет!

Это история о том, как желание просто проверить, жив ли мой блог, привело к трём дням танцев с бубном вокруг SSL-сертификата, а затем — к созданию собственного сервиса мониторинга, который теперь используют сотни разработчиков. Расскажу, почему существующие решения перестали устраивать, как мы реализовали поддержку UDP и ICMP в облаке и почему мониторинг должен быть «скучным».

5 лет назад мы пытались внедрить видеодетекцию движения для промышленного освещения. Программист не справился, проект лёг в ящик. В январе 2026-го я собрал работающий MVP за 40 минут с помощью Claude Code — без единого программиста нужного стека в команде.

Пока медийное пространство завалено «легкими решениями одной кнопкой» в виде публичных прокси из сомнительных каналов, техническое сообщество сталкивается с суровой реальностью. Публичные варианты либо безнадежно перегружены, либо моментально детектируются системами фильтрации.

В этой статье мы разберем, как на самом деле работает замедление Telegram, какие методы позволяют вернуть полную скорость работы мессенджера

Начнём не с технологий, а с причины, по которой эта статья вообще нужна.

В физическом мире USB-порт — дыра в периметре. Воткнул флешку — и у тебя либо данные утекли, либо малварь приехала, либо оба сценария одновременно. Stuxnet, обнаруженный в 2010-м (но активный с ~2007), пробил air gap завода в Натанзе — первоначально через завербованного агента, а дальше распространялся через USB-накопители. FIN7 в 2021-22 годах рассылали по почте подарочные коробки (от имени Amazon и HHS) с «флешками» — на деле это были Arduino ATMEGA32U4, эмулирующие клавиатуру и набивающие PowerShell-команды быстрее любого оператора. Конечная цель — Cobalt Strike, затем ransomware (BlackMatter, REvil). BadUSB, продемонстрированный на Black Hat 2014, показал, что любое USB-устройство может прикинуться клавиатурой и вводить команды — и VID/PID фильтрация тут не спасёт, потому что идентификаторы прошиты в firmware и перешиваются за минуту.

VDI в теории решает часть проблем: данные живут на сервере, а не на эндпоинте. Но USB-редиректор эту изоляцию пробивает — если разрешить проброс mass storage, пользователь утащит файлы на флешку ровно так же, как с физического ПК. А если не разрешить — придут люди со смарт-картами и принтерами, и скажут «нам нужно работать».

Вот тут начинается инженерный компромисс, который не решается одним галочкой в политике.

Три предыдущие статьи были про картинку. Картинка — вещь терпимая: можно сжать, можно потерять кадр, можно догнать следующим. Человеческий глаз прощает многое.

Со звуком всё иначе.

150 миллисекунд задержки — и собеседник начинает перебивать. 200 — и вы оба замолкаете, ждёте, потом говорите одновременно. 300 — созвон превращается в пытку. Это не абстрактные цифры из RFC, это реальность, которую каждый испытывал на плохом Zoom-звонке. (Кстати, порог в 150 мс — это ITU-T G.114, одна из самых цитируемых рекомендаций в телеком-индустрии. Не потому что магическое число, а потому что дальше начинаются перебивания.)

А теперь представьте: вы построили VDI, развернули 500 рабочих мест, люди довольны. И тут приходит запрос от call-центра: «Мы хотим работать через VDI тоже». Или от отдела продаж: «Нам нужен софтфон в виртуалке».

Вот тут начинается отдельная история.

Недавно наткнулся на статью про Echovault на Хабре — инструмент для памяти AI-агентов, написанный на Python. Автор описывал ровно ту же боль, что и я испытывал месяцами. Идея хорошая, реализация — рабочая. Но Python. Я ничего не имею против языка, просто не мой выбор для инструментов, которыми пользуюсь каждый день. Люблю скомпилированные бинарники: кинул файл — и работает, без virtualenv, без pip, без «а какая у тебя версия питона». Поэтому я взял идею и переписал её с нуля на Go. Получился Pantry.

Расскажу, зачем это вообще нужно и что внутри.

Landlock — редкий для Linux случай, когда «песочницу» можно включить руками самого приложения: без root, без километров политик и с понятной логикой «по умолчанию запрещено всё». В этой статье разбираем, что это за LSM, какие три системных вызова нужны, как выбрать минимальный набор прав и почему открытые до ограничений файловые дескрипторы способны тихо обнулить всю задумку.

Мы все привыкли к классическому раскладу: для поддержки есть сервис деск, в проектных командах — Jira, у ИБ — свои системы. При этом одни и те же сотрудники могут решать заявки, участвовать в проектах и устранять инциденты — сами или совместно с безопасниками. 

Когда эти процессы существуют по отдельности, данные разрознены, ответственность размывается, работа движется медленнее, растет риск ошибок. Гораздо лучше объединить эти три направления на одной платформе — ловкость рук и никакого соперничества между окнами систем за внимание специалистов.

Рассказываем, как такой подход работает на практике и почему единая система — это не печальный компромисс, а реальное усиление каждого процесса.