NetworkAdmin.ru

📱 Ansible Pull: когда сервер сам себя настраивает Обычно с Ansible работают в режиме push: управляющая машина подключается по SSH и применяет playbook к целевым хостам. Но есть и обратная модель - ansible-pull, когда сервер сам забирает конфигурацию и применяет ее локально. Это удобно там, где: хосты находятся за NAT или в изолированной сети; нет постоянного доступа с управляющего узла; инфраструктура динамическая (VPS, авто-масштабирование).

Как это работает Сервер: Клонирует репозиторий (обычно Git) Запускает playbook локально Повторяет процесс по cron/systemd timer

▪️ Пример запуска:

    
        
ansible-pull -U https://git.networkadminru/infra.git site.yml{}
    

Где: -U - URL репозитория site.yml - основной playbook По сути, это self-configuring node. ▪️ Автоматизация по расписанию. Чаще всего делают так:

    
        
*/15 * * * * ansible-pull -U https://git.networkadminru/infra.git site.yml{}
    

И сервер каждые 15 минут сам проверяет обновления конфигурации. ▪️ Когда это особенно полезно Edge-серверы и филиалы; Облака с автоскейлингом; Zero-trust сети; Immutable-подход с периодическим re-apply. 🤩 Плюсы Нет необходимости держать открытый SSH; Хорошо масштабируется; Минимальная точка отказа; Можно использовать Git как single source of truth. 🤩 Минусы Сложнее централизованный контроль; Нужно аккуратно работать с секретами; Логи выполнения нужно куда-то отправлять. ▪️ Push vs Pull - что выбрать? Классический Ansible: удобен для администрирования и ad-hoc задач Ansible Pull: хорош для распределенных и автономных систем Иногда разумно комбинировать оба подхода. #ansible #devops 🧑‍💻 NetworkAdmin

Встречайте AIOps в INFRAX — виртуального инженера, который работает прямо внутри карточки инцидента:- анализирует логи,- предлагает команды,- помогает устранять неполадки быстрее и надёжнее.🔐 Все действия прозрачны и безопасны: журналируются в инциденте и выполняются строго в рамках ваших политик доступа.Что такое INFRAX? Это:🖥 Мультиметричный мониторинг — CPU, память, диски, трафик, доступность узлов, интерактивные графики и гибкие алерты.🎫 Helpdesk — управление тикетами, статусы, приоритеты, исполнители и комментарии, портал самообслуживания для пользователей.🤖 Автоматизация — агенты для Windows/Linux, запуск скриптов по расписанию, планировщик задач, автодетект узлов.🔐 Удалённые подключения — RDP, SSH, VNC прямо из веба или нативных клиентов, видеозапись сессий для аудита.📚 База знаний — статьи, категории, контроль публикаций, статистика по популярности.👥 Управление пользователями — детальная система прав, интеграция с IAM, аудит действий, изоляция данных.📊 Дашборды — мониторинг, техподдержка, удалённые подключения с realtime-обновлением.🔥 Infrax — это ситуационный центр вашей ИТ-инфраструктуры. Всё, что нужно для стабильной и безопасной работы сервисов, в одном решении.#рекламаО рекламодателе

⌛️ Как посмотреть прогресс cp, dd, gzip и других утилит В репозиториях большинства linux-дистрибутивов есть небольшая, но очень полезная утилита - progress. Она показывает процент выполнения для операций coreutils: cp, mv, dd, tar, gzip/gunzip, cat и других. По смыслу ее часто сравнивают с pv, но принцип работы разный. pv получает данные из pipe - значит, поток нужно заранее направить через него. progress работает иначе: он сканирует /proc, находит поддерживаемые процессы, затем через fd и fdinfo отслеживает изменения открытых файлов и вычисляет прогресс. Главный плюс - подключиться можно в любой момент, даже если процесс уже запущен. Например, вы распаковываете огромный SQL-дамп и хотите понять, сколько еще ждать. ▪️ Пример. Создадим тестовый файл:

    
        
dd if=/dev/urandom of=testfile bs=1M count=2048{}
    

(Для dd процент может не отображаться, если конечный размер неизвестен, будет показываться только скорость.) Сжимаем файл:

    
        
gzip testfile{}
    

В другой консоли смотрим прогресс:

    
        
watch -n 1 progress -q{}
    

Вывод будет примерно такой:

    
        
[34209] gzip /tmp/testfile
    6.5% (132.2 MiB / 2 GiB){}
    

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

    
        
gunzip testfile.gz{}
    

Во второй консоли:

    
        
watch -n 1 progress -q

[35685] gzip /tmp/testfile.gz
    76.1% (1.5 GiB / 2.0 GiB){}
    

progress - крошечная утилита (~31 КБ), написанная на C, с единственной зависимостью - ncurses. Устанавливается просто:

    
        
apt install progress
dnf install progress{}
    

Минимум веса и максимум пользы. #linux #progress 🧑‍💻 NetworkAdmin

Уходи, здесь все под контролем моих лап #юмор 🧑‍💻 NetworkAdmin

🤩 Почему изнутри сети не открывается ваш же сервис Довольно классическая ситуация: снаружи сайт работает, а из локальной сети по публичному IP или домену не открывается. Пингуется, но HTTPS не отвечает. Или вообще таймаут. Виновник часто один - Hairpin NAT (он же NAT loopback). ▪️ В чем проблема Допустим: • Сервер внутри сети: 192.168.1.10 • Публичный IP роутера: 203.x.x.x • На роутере настроен проброс 443 → 192.168.1.10 Снаружи все ок. Но когда клиент внутри сети обращается к 203.x.x.x, пакет: 1. Уходит на роутер 2. Роутер должен отправить его обратно внутрь 3. Сервер отвечает напрямую клиенту И тут соединение ломается, потому что NAT не переписывает обратный трафик корректно. В итоге асимметрия маршрута и разрыв сессии. ▪️ Что такое Hairpin NAT Это механизм, при котором роутер позволяет внутренним клиентам обращаться к внутренним сервисам через внешний IP, корректно делая двойной NAT. Если функция отключена, то доступ изнутри по внешнему адресу работать не будет. ▪️ Где это встречается • Домашние роутеры • MikroTik • Kubernetes NodePort • Docker с опубликованными портами • Облачные VPC ▪️ Как чинить 1️⃣ Включить NAT loopback Во многих роутерах есть отдельная опция: NAT Loopback / Hairpin NAT / Reflection 2️⃣ Добавить правило SNAT (пример для iptables)

    
        
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -d 192.168.1.10 -j MASQUERADE{}
    

Это заставляет сервер отвечать обратно через роутер. 3️⃣ Split DNS (самый правильный способ). Во внутреннем DNS сделать:

    
        
site.networkadmin.ru → 192.168.1.10{}
    

А наружу оставить публичный IP. Это избавляет от NAT-костылей и работает стабильнее. #network #nat 🧑‍💻 NetworkAdmin

📘 На Stepik вышел курс — «DevOps-инженер: От основ до продакшена» Хотите автоматизировать деплой и выстраивать надёжные CI/CD процессы? Этот курс — полный путь DevOps-инженера: от первого сервера до продакшена. • CI/CD: Jenkins, GitLab CI/CD, GitHub Actions, Blue-Green, Canary, rollback • Контейнеризация: Docker (образы, Compose, networking), безопасность контейнеров • Kubernetes: Pods, Services, Deployments, Helm • Infrastructure as Code: Terraform, Ansible, ArgoCD и Flux для GitOps • Мониторинг: Prometheus, Grafana, ELK Stack, OpenTelemetry, SLI/SLO/SLA • Продакшен практики: High Availability, Disaster Recovery, Chaos Engineering • В стоимость включено: поддержка на протяжении курса, разбор задач и вопросов, рецензирование итогового проекта и помощь в составлении резюме 🎓 Сертификат — добавьте в резюме или LinkedIn 🔥 Цена со скидкой: 9 990 ₽ → 5 990 ₽, действует ограниченное время 👉 Пройти курс на Stepik

📁 Централизованный сбор логов в Windows без стороннего ПО Если в инфраструктуре десятки или сотни Windows-машин, смотреть логи на каждой вручную - тупиковый путь. Для централизованного сбора событий microsoft давно встроила в систему механизм Windows Event Forwarding (WEF) и он работает без агентов и сторонних SIEM. WEF позволяет автоматически отправлять события с клиентов на сервер-коллектор через WinRM (HTTP/HTTPS). ▪️ Архитектура ▪️Source Computers - клиенты, которые отправляют события; ▪️Collector - сервер, принимающий события; ▪️Используется служба Windows Remote Management (WinRM); ▪️События попадают в журнал Forwarded Events. Поддерживаются два режима: ▪️Collector-initiated - сервер сам подписывается на машины (удобно в домене) ▪️Source-initiated - клиенты сами знают, куда отправлять логи (через GPO) ▪️ Быстрая настройка коллектора. На сервере:

    
        
wecutil qc{}
    

Это включает службу Windows Event Collector и создает журнал Forwarded Events. Проверяем WinRM:

    
        
winrm quickconfig{}
    

▪️ Создание подписки Открываем Event Viewer → Subscriptions → Create Subscription. Выбираем: ▪️Тип (Collector или Source initiated) ▪️Какие события собирать (через XPath или GUI) ▪️Частоту доставки (Normal / Minimize latency) Пример фильтра: собирать события входа (Event ID 4624) и неудачных попыток (4625) из Security. ▪️ Настройка через GPO. Для Source-initiated режима: Computer Configuration → Administrative Templates → Windows Components → Event Forwarding → Configure target Subscription Manager Указываем:

    
        
Server=http://wef-server:5985/wsman/SubscriptionManager/WEC{}
    

После применения политики клиенты начнут отправлять события автоматически. #windows #wef 🧑‍💻 NetworkAdmin

✈️ Паразитное чтение диска в linux Бывает неприятная ситуация: диск постоянно нагружен чтением, latency растет, сервисы подтормаживают, а по iotop, pidstat и lsof - тишина. Никакой очевидный процесс диск не ест, но I/O живет своей жизнью. В таких случаях на помощь приходит blktrace. blktrace работает на уровне блочного устройства, а не процессов. Он показывает реальные операции чтения и записи, которые уходят в диск: кто, куда и с какими смещениями обращается. Это особенно полезно, когда: чтение идет из page cache/readahead, нагрузка создается kernel-потоками, виноват не процесс, а ФС, LVM, RAID, snapshot или backup-агент. ▪️ Устанавливается просто:

    
        
apt install blktrace{}
    

▪️ Запускаем трассировку, например, для диска sda:

    
        
blktrace -d /dev/sda -o /tmp/trace{}
    

Даем системе поработать 10–30 секунд и останавливаем. Далее анализируем:

    
        
blkparse /tmp/trace.* | less{}
    

В выводе видно: тип операции (Read/Write), сектор и размер, PID и имя процесса (если применимо), временные метки. Если нужен быстрый срез, кто больше всего читает:

    
        
blkparse /tmp/trace.* | grep " R " | awk '{print $6}' | sort | uniq -c | sort -nr | head{}
    

▪️ Для наглядности можно использовать btt (Block Tracing Tool):

    
        
btt -i /tmp/trace.*{}
    

Он строит статистику задержек и нагрузки по времени, удобно, когда ищете периодическую активность. ⚠️ Важно: blktrace - тяжелый инструмент. Не держите его включенным долго, особенно на проде. Но как инструмент расследования - это один из самых точных. #linux #storage 🧑‍💻 NetworkAdmin

⬛️ Подозрение на взлом linux-сервера Чек-лист действий, который можно использовать, когда есть основания считать, что сервер был скомпрометирован и на нем исполняется вредоносный код. Чаще всего это нужно не для починить здесь и сейчас, а для расследования: понять вектор атаки и масштаб проблемы. Если факт взлома подтвержден - правильное решение почти всегда одно: полная переустановка сервера с переносом только проверенных данных. 1️⃣ Анализ логов (особенно для веб-сервера). Начинать стоит с логов веб-сервера и приложения. Если известно о незакрытой уязвимости - ищем: её эксплуатацию, загрузку или запуск web-shell, подозрительные запросы к конкретным файлам. Часто уязвимость привязана к одному файлу, тогда имеет смысл искать все обращения именно к нему и цепочку последующих запросов. 2️⃣ Поиск недавно измененных файлов. Не серебряная пуля (mtime легко подменить), но иногда сильно помогает:

    
        
find /var/www/site -type f -mtime -30 ! -mtime -1 -printf '%TY-%Tm-%Td %TT %p\n' | sort -r{}
    

Команда выводит файлы, измененные за последние 30 дней (кроме сегодняшнего), и сортирует их от новых к старым. Если вывод большой, то сохраняйте в файл и анализируйте отдельно. В таком виде команда реально полезна. 3️⃣ Системные журналы и планировщики. Проверяем: системные логи, логи аутентификации SSH, cron, at, systemd timers. Отдельный плюс - если логи отправляются на внешний log-server: злоумышленнику сложнее их подчистить. Где именно искать запланированные задачи - это тема отдельного разбора, но пропускать ее нельзя. 4️⃣ История команд. Иногда всплывает что-то интересное:

    
        
cat ~/.bash_history
cat ~/.mysql_history
sudo -u postgres psql
\s{}
    

Да, историю могут чистить, но если этого не сделали, то есть шанс увидеть и ручную активность атакующего. 5️⃣ Проверка целостности пакетов. Сравниваем системные файлы с эталонными хешами из пакетов:

    
        
dpkg --verify
rpm -Va{}
    

Любые неожиданные изменения в системных бинарниках - серьезный красный флаг. 6️⃣ Пользователи, SSH и домашние каталоги. Проверяем: системных пользователей и их shell, authorized_keys, домашние каталоги пользователей, от которых работают сервисы (web, app, db), временные директории (/tmp, /var/tmp). Часто зловреды прячутся именно там. 7️⃣ Сетевые соединения. Смотрим, какие порты слушаются и куда сервер ходит сам:

    
        
ss -tulnp | column -t
ss -ntu{}
    

Неожиданные исходящие соединения - это один из самых надежных индикаторов компрометации. 8️⃣ Список процессов. Иногда достаточно просто посмотреть глазами:

    
        
ps axf{}
    

Майнеры, странные бинарники и процессы без имени часто палятся именно здесь. #linux #security

Современные требования к DevOps #юмор 🧑‍💻 NetworkAdmin