Лига сисадминов

Выставляем любой сервис на порт или сокет с помощью systemd. Обычно это нужно для того, чтобы быстро прокинуть скрипты или legacy-приложения в сеть без необходимости писать для них собственный сетевой стек или поднимать тяжелые веб-серверы. Такое решение отлично подходит для создания легковесных сетевых заглушек, shell-скриптов или организации безопасного проксирования трафика силами встроенных инструментов Linux. https://telegra.ph/Vystavlyaem-lyuboj-servis-na-port-ili-soket-s-pomoshchyu-systemd-07-12 #ит_статьи #devops #linux #shell #systemd #network

Эфемерный TMPFS для скриптов Возможно вы сталкивались с проблемой, когда при внезапном падении или kill -9 shell-скрипт оставляет за собой кучу мусора в /tmp. Классический подход с решением через trap и rm -rf тут пасует: сигнал SIGKILL просто не дает скрипту времени на очистку ресурсов. Но есть решение изящнее и надежнее - изолированные пространства имен ядра и приватное монтирование TMPFS. Идея тут в том, чтобы привязать время жизни временных файлов напрямую к жизненному циклу самого процесса. Скрипт умер - файлы стерлись на уровне ядра, автоматически. Сегодня разберём как это настроить с помощью unshare, обойти ограничения шебанга и заворачивать отдельные файлы в «невидимые» директории. https://telegra.ph/EHfemernyj-TMPFS-dlya-skriptov-07-12 #ит_статьи #devops #linux #shell #kernel #tmpfs

Как использовать Podman для тестирования и симуляции сети В сегодняшней статье посмотрим, как с помощью Podman создавать изолированные сетевые окружения для тестирования, симулировать условия работы сети и проверять поведение распределенных приложений. https://telegra.ph/Kak-ispolzovat-Podman-dlya-testirovaniya-i-simulyacii-seti-07-12 #ит_статьи #devops #network #podman #containers #linux #python

Linux Routing - Load Balancing Итак, недавно я усвоил еще один урок: давным-давно ядро Linux умело нормально балансировать маршруты (веса nexthop), используя кэш маршрутизации, чтобы запоминать, какое соединение связано с каким маршрутом. Затем эту реализацию кэша выпилили и заменили отправкой отдельных пакетов случайным образом по каждому указанному маршруту (примерно так же я поначалу подходил к балансировке OpenVPN между несколькими потоками). Это, однако, ломало состояние соединений и порядок пакетов, так как два линка маршрута могли вести в совершенно разные места. После этого разработчики ядра Linux решили внедрить базовый алгоритм хэширования, который бы всегда связывал поток соединения с одним и тем же хопом маршрутизации. Это очень ограниченная форма балансировки нагрузки, поскольку один и тот же адрес источника и назначения всегда будет преобразовываться в один и тот же хэш, который каждый раз будет соответствовать одному и тому же пути маршрутизации (это будет ограничивать еще сильнее, если вы используете исходный NAT). Оказывается, есть еще один трюк, позволяющий получить более динамически распределенную балансировку маршрутизации в Linux. Он заключается в использовании таблицы mangle в iptables и маркировке нового состояния соединения (connmark), чтобы таблица conntrack могла сохранять и восстанавливать заданные метки пакетов. Затем вы можете установить правило ip rule, чтобы перехватывать эти метки межсетевого экрана и привязывать их к другой таблице маршрутизации. В дополнение к этому, вы можете использовать случайный алгоритм или алгоритм остатка от деления (modding), чтобы равномерно устанавливать разные метки, что дает вам еще большее разнообразие маршрутизации!

$ipt -t mangle -A PREROUTING -i lan -m mark --mark 0x0 -j CONNMARK --restore-mark
$ipt -t mangle -A PREROUTING -i lan -m statistic --mode nth --every 2 --packet 0 -m mark --mark 0x0 -j MARK --set-mark 8
$ipt -t mangle -A PREROUTING -i lan -m statistic --mode nth --every 1 --packet 0 -m mark --mark 0x0 -j MARK --set-mark 9
$ipt -t mangle -A PREROUTING -i lan -m mark ! --mark 0x0 -j CONNMARK --save-mark
echo "8 vpna" >> /etc/iproute2/rt_tables
echo "9 vpnb" >> /etc/iproute2/rt_tables
ip rule add fwmark 8 table vpna
ip rule add fwmark 9 table vpnb

Теперь вы можете добавить свои правила маршрутизации для VPN-туннелей в обе новые таблицы маршрутизации ip, например, vpna и vpnb! #ит_заметки #linux #networking #routing #loadbalancing #iptables

Куда класть секреты? Каждые несколько недель я натыкаюсь в соцсетях на один и тот же вопрос - то ли ради охватов, то ли из искреннего любопытства: Как элегантно управлять секретами? Цель этого поста - показать подход senior-инженера к работе с секретами как в личных, так и в enterprise проектах. https://telegra.ph/Kuda-klast-sekrety-07-12 #ит_статьи #devops #kubernetes #security #secrets

Обработка статус-кодов выхода для условных команд в subshell Совсем недавно при деплое изменений через GitHub Actions пайплайн упал вот с такой максимально загадочной ошибкой:

Error: Process completed with exit code 1.

И больше ничего! Ни единой подсказки! А это значило только одно - мне придется самому лезть в эту кроличью нору. О том, что в итоге пришлось сделать и будет сегодняшняя статья. https://telegra.ph/Obrabotka-status-kodov-vyhoda-dlya-uslovnyh-komand-v-subshell-07-11 #ит_статьи #devops #bash #linux #subshell #cicd #troubleshooting

Docker может обходить UFW через port binding — проверьте у себя Если в вашем docker-compose.yml порты объявлены так:

ports:
  - "5432:5432"

…это привязка к 0.0.0.0 - то есть порт торчит наружу на всех интерфейсах. Проблема в том, что Docker прописывает свои правила прямо в iptables, в обход UFW. Ваш файрвол честно «закрыт», а порт на самом деле открыт всему интернету. Проверить просто. Посмотрите, на каких интерфейсах реально слушается порт внутри ОС::

ss -tlnp | grep 5432
# или через docker: docker port <container_name>

Если в выводе 0.0.0.0:5432 вместо 127.0.0.1:5432 - порт открыт наружу. Исправление - одна строка (явно укажите localhost, чтобы Docker слушал только loopback-интерфейс, и порт оставался доступным только внутри хоста):

ports:
  - "127.0.0.1:5432:5432"

Docker будет слушать только на loopback, и порт останется доступным только с хоста. Почему сканеры не помогут Паттерн "5432:5432" без явного 127.0.0.1: - это слепое пятно для Trivy, Checkov, Semgrep и Snyk. Ни один из них не флагует такой биндинг как эксплойз. Рассчитывать на CI-сканеры в этом случае нельзя - проверять нужно глазами или кастомным правилом. #ит_заметки #devops #linux #docker #firewall #ufw

🚀 Мечтаешь войти в DevOps, но не знаешь с чего начать? Это твой шанс! Привет, меня зовут Вячеслав Федосеев. Я работаю руководителем команды в DevOps, выступаю как спикер в учебном центре Слёрм и веду собственный проект DevOps Bootcamp. У себя в Telegram-канале я регулярно провожу прямые эфиры, публикую полезные статьи и лекции, а главное — отвечаю на вопросы и помогаю новичкам сделать первые шаги в профессии. Присоединяйтесь, чтобы не пропустить самое интересное! 👉 Канал: @devopsupgrade 🔥 Бонус для начинающих Вместе с командой Слёрм мы подготовили бесплатный мини-курс «Быстрый старт в DevOps». На нём разложим по полочкам главные темы, которые волнуют новичков: 👉 что такое DevOps, и как выстроить работу команды в рамках этой методологии; 👉 Kubernetes, Docker и т.д.: как базовые инструменты выстраивают работу в DevOps; 👉 DevOps и компания: как состыковать критерии успеха. ЗАБРАТЬ БЕСПЛАТНЫЙ КУРС

Быстрая массовая загрузка IP-адресов (IPv4, IPv6) в наборы nftables с таймаутами На мой взгляд, одна из лучших фич в Linux nftables - это именованные наборы (named sets). Именованный набор позволяет ссылаться на группу значений (например, IP-адресов) из одного или нескольких правил, не вшивая эти значения прямо в само правило. Что еще круче - элементам набора можно задавать индивидуальные таймауты. Это удобный способ создавать самоочищающиеся наборы, который я уже использовал в своем примере с port knocking в nftables несколько лет назад. https://telegra.ph/Bystraya-massovaya-zagruzka-IP-adresov-IPv4-IPv6-v-nabory-nftables-s-tajmautami-07-09 #ит_статьи #linux #nftables #network #firewall #security

Потестил инструмент для инвентаризации и аудита Proxmox, и он меня впечатлил Я вижу огромное количество инструментов, которые создаются якобы для решения тех или иных проблем в экосистеме Proxmox. За последние пару лет я перепробовал множество разных утилит для Proxmox, и лишь единицы смогли меня по-настоящему удивить. Тем не менее, недавно я наткнулся на инструмент под названием PVEViewer, и он показался мне особенным. Давайте разберем этот инструмент для инвентаризации и аудита, который, на мой взгляд, будет супер-интересен как для домашних лабораторий на базе Proxmox VE Server, так и для продакшн-сред. И посмотрим, почему. https://telegra.ph/Potestil-instrument-dlya-inventarizacii-i-audita-Proxmox-i-on-menya-vpechatlil-07-08 #ит_статьи #devops #proxmox #pveviewer #tools

Наткнулись на интересную, но при этом бесплатную конференцию — Kuber Community Day Она пройдет 30 июля в Москве, жителям из других городов предлагают подключиться онлайн. Участников ждет много любопытных активностей: - доклады и круглые столы от 30 спикеров об использовании ИИ в Kubernetes, мониторинге контейнеров, инструментах экосистемы, получении сертификаций и пр.; - мастер-класс по созданию Kubernetes-оператора, в завершении которого все участники задеплоят его в Yandex Managed Kubernetes; - новый формат arch dating, подразумевающий короткие встречи с опытными менторами, где можно обсудить технические и карьерные вопросы; - много пространства для нетворкинга и на десерт — научпоп-доклад о кибернетическом подходе к управлению сложностью от Александра Нозика, директора центра научного программирования. Места на офлайн ограничены площадкой, советуем заранее пройти регистрацию.

Как исправить уязвимости в контейнере за секунды без пересборки образов Ваш сканер безопасности только что обнаружил 47 уязвимостей в продакшен-образе контейнера. Большинство из них - это пакеты на уровне ОС, о существовании которых вы даже не подозревали. Традиционное решение? Пересобрать весь образ, обновить базовые образы, дождаться исправлений от апстрима, заново все задеплоить. Это занимает часы или может дни. Но есть способ получше. https://telegra.ph/Kak-ispravit-uyazvimosti-v-kontejnere-za-sekundy-bez-peresborki-obrazov-07-07 #ит_статьи #devops #docker #security #trivy #copa #cicd

Спасибо HP, инструкция по деплою в пятницу отличная. А принтер-то как распаковать? #ит_юмор #hp #cheatsheet

Где будет всё ИТ-комьюнити этой осенью? На IT Elements 2026: конференции для профессионального сообщества, где встречаются архитекторы, инженеры, руководители и команды, отвечающие за инфраструктуру, сети, безопасность, данные и ИИ. Вместо абстрактных рассуждений — реальные кейсы, технические доклады и профессиональные дискуссии. Что вас ждет: 📌 лаборатории и практические воркшопы; 📌 выставка главных российских вендоров; 📌 обмен опытом с коллегами из крупнейших компаний; 📌 два дня насыщенной технической программы, нетворкинга и знакомств. Формат: офлайн в Москве и онлайн. Участие бесплатное. Программа будет постепенно пополняться, а зарегистрироваться можно уже сейчас. Если планируете профессиональные мероприятия этой осенью — IT Elements точно стоит добавить в список. 📆

Введение в UEFI HTTP(S) boot с Qemu/OVMF Исторически сложилось так, что классическим решением для сетевой загрузки является PXE. В основе PXE лежат DHCP и TFTP. Настроить его правильно - та еще задача, сделать его отказоустойчивым - задача еще сложнее, а уж про безопасность этого незашифрованного протокола без подписей вообще лучше промолчать. Современный веб уже давно стандартизировал HTTPS с TLS-сертификатами для аутентификации серверов, обеспечения целостности и конфиденциальности данных. Более того, когда речь заходит о HTTPS, высокодоступные конфигурации - это уже давно решенная проблема. Что еще лучше, слой шифрования позволяет запускать загрузку через интернет, не сталкиваясь сразу же с угрозой атаки «человек посередине» (man-in-the-middle), которая была бы тривиальной в случае с TFTP (помните, что буква «t» в названии означает «trivial», а не «secure»). Хорошая новость заключается в том, что большинство современных систем на базе UEFI поддерживают загрузку по HTTP(S). В этом посте мы загрузим snponly-вариант netboot.xyz прямо с официального сайта. Приготовьтесь к веселому квесту с HTTPS. Все эти тесты проводились на Ubuntu 26.04 с дефолтными пакетами Qemu (1:10.2.1+ds-1ubuntu3) и OVMF (2025.11-3ubuntu7), если не указано иное. Обратите внимание, что по причинам, которые станут понятны позже в этой статье, более старые версии могут работать даже лучше . https://telegra.ph/Vvedenie-v-UEFI-HTTPS-boot-s-QemuOVMF-07-06 #ит_статьи #devops #linux #qemu #ovmf #uefi #https #network

Как снизить бюджет миграции на новую АТС Когда компания слышит «миграция», первая мысль — придётся менять всё. Этого можно избежать. ➡️ Шаг первый — аудит По итогам аудита — три списка: 🔵 что можно оставить без ущерба для надёжности, 🔵 что нужно заменить до старта — риск отказа/несовместимость, 🔵 что можно обновить позже, в плановом режиме. Так «заменить всё сразу» превращается в поэтапный план: критичное — на старте, остальное — по мере износа. Это помогает модернизировать телефонию с меньшими рисками и затратами. ▶️ Приходите на кейс-вебинар — расскажут практики: про подводные камни и что стоит сделать иначе, чтобы не ходить по тем же граблям. В программе: 🏦 Солид Банк — импортозамещение АТС в 20+ филиалах без прерывания связи 🚂 Предприятие РЖД — замена Avaya для 740 абонентов без остановки 🎓 ДВГУПС — миграция с Cisco, когда никто не помнит, как устроена телефония 📅 8 июля, 11:00 мск 👉 Зарегистрироваться

Разбираемся с рисками QCOW2 при использовании QEMU cache=none в Proxmox Режим cache=none в QEMU часто понимают неправильно. На первый взгляд все кажется простым: данные идут в обход кэша страниц хоста (host page cache), и вся ответственность за сохранность ложится на гостевую систему. На практике же поведение оказывается куда более тонким. Если запись на RAW-блоки обычно предсказуема и надежна, то QCOW2 добавляет головной боли. Обновления метаданных, порядок записи и обработка сброса буферов (flush) в QCOW2 задерживают или меняют порядок фиксации данных. В итоге, если виртуальная машина "упадет" или внезапно отключится питание, вы рискуете получить частичную потерю или повреждение данных (torn writes). В этой статье мы разберем режим cache=none и посмотрим, как он взаимодействует с записью гостя и хранилищем. Вы узнаете, почему его логика может создавать скрытые риски для виртуальных дисков QCOW2 и какие механизмы нужны для обеспечения целостности. К концу материала вы начнете четко понимать, почему cache=none - это далеко не просто "отключение кэширования", почему RAW-диски остаются самым безопасным вариантом и каким неожиданным образом диски QCOW2 могут испортить ваши данные при сбое. https://telegra.ph/Razbiraemsya-s-riskami-QCOW2-pri-ispolzovanii-QEMU-cachenone-v-Proxmox-07-05 #ит_статьи #devops #proxmox #qemu #qcow2 #storage

Автоматизация обновлений хостов с rootless Docker при помощи Ansible Запуск apt upgrade на хостах с rootless Docker-сервисами может все сломать. Из-за расхождения версий между запущенным пользовательским демоном и только что обновленными системными бинарниками контейнеры падают при перезапуске. В этом посте делюсь Ansible-плейбуком, который находит изменения в критически важных пакетах и автоматически перезапускает только нужные rootless-демоны пользователей, избавляя от даунтайма и ручного вмешательства. https://telegra.ph/Avtomatizaciya-obnovlenij-hostov-s-rootless-Docker-pri-pomoshchi-Ansible-07-04 #ит_статьи #devops #docker #rootless #ansible #automation

BPF CPU Scheduler: не нравится стандартный планировщик в Linux? Напиши свой В статье расскажем про относительно новую возможность написания собственных CPU планировщиков для Linux с помощью BPF. Разберёмся, для чего это нужно, как работает, а также посмотрим на примеры уже написанных планировщиков. https://telegra.ph/BPF-CPU-Scheduler-ne-nravitsya-standartnyj-planirovshchik-v-Linux-Napishi-svoj-07-03 #ит_статьи #linux #kernel #cpu #ebpf

Уязвимости есть у всех. А патчи? Уязвимости в виртуализации есть у всех. У VMware, Hyper-V, Proxmox, oVirt, российских платформ, open source и проприетарных решений. Интереснее другое: что происходит после того, как уязвимость нашли? Можно ли получить патч? Понятно ли, как быстро вендор реагирует? Есть ли публичный changelog, bug bounty, нормальный канал для исследователей? Или безопасность заканчивается на пресс-релизе и фразе «все устранено, твёрдо и чётко»? Отдельно нельзя не упомянуть российскую виртуализацию, которая за последние годы успела обрасти плотным слоем маркетинга. И в чьей среде самый простой способ испортить разговор: спросить не «чья платформа отечественнее», а «как вы закрываете уязвимости?». Причём после ухода VMware этот вопрос стал особенно актуальным для всех. Потому что оставаться на старой версии рискованно, но и переходить на новое отечественное решение вслепую тоже такое себе. Сначала хотел запилить большой разбор про риски ушедших иностранных платформ, патчи под санкциями и прозрачность наших вендоров, но наткнулся на статью на Хабре, где автор уже прошелся примерно по этим же вопросам. Тут автор тоже попытался понять не кто лучше, а кому в этой истории можно доверить инфраструктуру. https://habr.com/ru/articles/1037318/