Вам на какой? Мне на 192.168.1.3

#юмор

🧑‍💻 NetworkAdmin

🔖 tcpdump advanced: фильтры, которые реально нужны

Большинство используют tcpdump как "посмотреть весь трафик на 80 порт". Но настоящая сила в BPF-фильтрах. Правильный фильтр = меньше шума, быстрее диагностика и меньше нагрузки на сервер. Небольшая шпаргалка фильтров, которые реально пригождаются.

1️⃣ Конкретный хост + порт

tcpdump -i eth0 host 10.10.10.5 and port 443

Когда нужно понять, что происходит между двумя узлами.

2️⃣ Только входящий или исходящий трафик

Исходящий:

tcpdump -i eth0 src host 192.168.1.10

Входящий:

tcpdump -i eth0 dst host 192.168.1.10

3️⃣ Только SYN (поиск новых соединений)

tcpdump -i eth0 'tcp[tcpflags] & tcp-syn != 0'

Подойдет для: выявления сканирования, анализа всплеска подключений, диагностики DoS

Только SYN без ACK:

tcpdump -i eth0 'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn'

4️⃣ Исключить шум. Например, убрать SSH:

tcpdump -i eth0 not port 22

Или исключить конкретную подсеть:

tcpdump -i eth0 not net 10.0.0.0/8

5️⃣ Поиск ресетов (Rst-шторм)

tcpdump -i eth0 'tcp[tcpflags] & tcp-rst != 0'

Помогает понять, кто рвет соединения: сервер, клиент или firewall.

6️⃣ Поиск retransmissions (косвенно). Прямого фильтра нет, но можно смотреть повторяющиеся sequence numbers:

tcpdump -nn -i eth0 tcp

Дальше анализ через Wireshark или tcptrace.

7️⃣ HTTP без мусора

tcpdump -i eth0 -A -s 0 'tcp port 80'

-A - показать ASCII
-s 0 - не обрезать пакеты

Можно сразу фильтровать по методу:

tcpdump -i eth0 -A 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]>>4)<<2)) != 0)'

(когда нужно видеть payload, а не только заголовки)

8️⃣ Захват в файл для анализа

tcpdump -i eth0 -w dump.pcap

С ограничением по размеру:

tcpdump -i eth0 -C 100 -W 5 -w dump.pcap

Это создаст ротацию файлов по 100MB (до 5 файлов).

9️⃣ Поиск DNS-аномалий

tcpdump -i eth0 port 53

Только большие ответы:

tcpdump -i eth0 'udp port 53 and greater 512'

Часто помогает при подозрении на туннелирование через DNS.

#linux #tcpdump

🧑‍💻 NetworkAdmin

📱 Настройка history

На всех linux-серверах, которые необходимо настроить или с которыми предстоит плотно поработать, первым делом стоит задуматься про историю команд. Т.к я часто пользуюсь history, поэтому важно, чтобы команды: сохранялись сразу, хранились долго, были с таймстампами и не засорялись мусором. Обычно добавляю все в ~/.bashrc.

1️⃣ Немедленное сохранение истории. По умолчанию bash записывает команды в файл истории только при завершении сессии. Это неудобно: открыл вторую SSH-сессию и свежих команд там нет. Решение - PROMPT_COMMAND:

PROMPT_COMMAND='history -a'

history -a сохраняет команды текущей сессии в файл перед каждым выводом приглашения.

2️⃣ Таймстамп у каждой команды. Без времени история малоинформативна.

export HISTTIMEFORMAT='%F %T '

Формат будет таким:

2026-03-31 12:20:30 apt install nginx

3️⃣ Увеличение размера истории. По умолчанию хранится около 500 команд и это мало.

export HISTSIZE=10000

Теперь в лимит не упретесь 🙂

4️⃣ Игнорирование мусорных команд. Некоторые команды не несут ценности и только засоряют историю:

export HISTIGNORE="ls:history:w:htop:pwd:top:iftop"

Список можно адаптировать под себя.

5️⃣ Команда с пробела - не сохраняется. Иногда нужно выполнить что-то, что не должно попасть в историю. Для этого:

export HISTCONTROL=ignorespace

Теперь команда, введенная с пробела, не будет сохранена.

▪️ Применение настроек

source ~/.bashrc

▪️ Проверить активные параметры:

export | grep -i hist

Если хотите применить настройки ко всем пользователям, для этого создайте файл, например:

/etc/profile.d/history.sh

Скрипты оттуда выполняются при запуске shell.

▪️ Поиск по истории

Стандартный способ - Ctrl + R.
Нажимаете и начинаете вводить команду. Повторное Ctrl + R - следующий результат.

Я чаще делаю так:

history | grep 'apt install'

Сразу видно все и можно быстро скопировать нужную строку.

#linux #terminal

🧑‍💻 NetworkAdmin

🤩 Как быстро проверить ширину канала через netcat

Если нужно оперативно прикинуть пропускную способность канала между двумя Linux-машинами, можно обойтись без установки iperf. Достаточно netcat, который в большинстве дистрибутивов уже есть.

▪️ Простой тест

Допустим, есть сервер 10.25.1.157.

На нем запускаем слушатель:

nc -lvp 5201 > /dev/null

На второй машине отправляем 100 МБ нулевых данных (10 блоков по 10 МБ):

dd if=/dev/zero bs=10M count=10 | nc 10.25.1.157 5201

dd покажет скорость передачи - это и будет приблизительная оценка ширины канала.

▪️ Насколько это точно?

Если сравнить результаты netcat и iperf3, получается интересная картина:

До 1 Gbit/sec показатели практически совпадают (разница в пределах погрешности).

Для обычных VPS и типичных серверных подключений - способ вполне рабочий.
Для быстрой диагностики, более чем достаточно.

Можно смело использовать netcat, если нужно быстро понять: канал живой и дает ли он заявленную скорость.

▪️ Что на высоких скоростях? Внутри гипервизора картина меняется.

При тестах в виртуальной среде:

iperf3 показывал около 15 Gbit/sec
netcat - примерно 4 Gbit/sec

при этом гипервизор заявлял бридж на 10 Gbit/sec

Разброс серьезный. Почему так происходит:

netcat не оптимизирован под high-performance тестирование
нет тонкой настройки TCP-параметров
влияет размер буферов
влияет CPU и обработка в user-space
виртуальная сеть дает свою специфику

В таких сценариях уже сложно сказать, кто ближе к истине. Корректный замер реальной скорости требует учета множества факторов: MTU, offload, congestion control, NUMA, CPU pinning и т.д.

#networking #netcat

🧑‍💻 NetworkAdmin

❗️ Ansible facts: нестандартные приемы и кастомные факты

В Ansible многие используют facts только для базовых вещей: ansible_os_family, ansible_hostname, ansible_default_ipv4. Но механизм фактов куда мощнее, если копнуть глубже, можно строить динамичную и умную автоматизацию.

1️⃣ Отключаем сбор всего лишнего (и ускоряем playbook). По умолчанию Ansible собирает огромный набор фактов. Если они не нужны - это просто трата времени.

- hosts: all
  gather_facts: false

А если нужны только сетевые:

- hosts: all
  gather_facts: true
  gather_subset:
    - network

Это особенно заметно в больших инфраструктурах.

2️⃣ Используем facts как динамические условия. Например, разные действия для разных типов виртуализации:

- name: Install qemu tools
  package:
    name: qemu-guest-agent
    state: present
  when: ansible_virtualization_type == "kvm"```yaml

Или автоматический выбор пакетов по версии ОС:

```yaml
when: ansible_distribution_major_version | int >= 9

3️⃣ Кастомные факты (local facts). Самый недооцененный механизм.

Создаем на хосте файл:

/etc/ansible/facts.d/app.fact

Пример содержимого (JSON):

{
  "role": "backend",
  "env": "prod"
}

После этого факты будут доступны как:

ansible_local.app.role
ansible_local.app.env

Теперь сервер сам знает, кто он, а плейбук просто реагирует.

4️⃣ Динамические факты через set_fact. Можно вычислять значения на лету:

- set_fact:
    is_prod: "{{ 'prod' in inventory_hostname }}"

И дальше использовать:

when: is_prod

Важно помнить: set_fact живет в рамках хоста и текущего play.

5️⃣ Делегированные факты. Иногда нужно собрать факт с одного хоста и использовать на другом:

- name: Get DB IP
  command: hostname -I
  register: db_ip
  delegate_to: db01
  run_once: true

Теперь можно передать IP в шаблон для backend-серверов.

6️⃣ Кэширование фактов. В больших инвентарях сбор фактов - это дорогая операция. Можно включить fact caching (например, в Redis или JSON):

fact_caching = jsonfile
fact_caching_connection = /tmp/ansible_facts_cache
fact_caching_timeout = 86400

7️⃣ Факты как источник архитектуры. Можно строить инфраструктурную логику без жестких групп:

если есть второй диск, то настраиваем RAID
если RAM > 16GB, то увеличиваем worker-пулы
если это VM, то отключаем tuned-профили для bare metal

Пример:

when: ansible_memtotal_mb > 16000

#ansible #devops

🧑‍💻 NetworkAdmin

😭 Как один rsync положил прод

Иногда прод падает не из-за zero-day, не из-за DDoS и не из-за кривого кода. Иногда его кладет… обычный rsync.

🔖 Сценарий. Есть:

прод-сервер
staging
cron-задача синхронизации
и уверенность «я же сто раз так делал»

Команда выглядела примерно так:

rsync -av --delete /data/ backup@storage:/prod-data/

Или еще лучше:

rsync -av --delete /data/ /mnt/nfs/prod/

Все работало годами. Пока однажды:

/data не примонтировался
NFS отвалился
переменная с путем оказалась пустой
кто-то перепутал source и destination

И rsync честно сделал то, что должен был сделать.

С --delete.

▪️ Почему это происходит. rsync - не "умная синхронизация". Он синхронизирует состояние директорий. Если source пустой - значит, и на destination должно быть пусто. Логика железная.

Особенно опасные кейсы:

▪️ Не примонтированный диск
/data - пустая локальная папка

rsync --delete удаляет все на целевом хранилище.

▪️ Пустая переменная

SRC=""
rsync -av --delete $SRC /backup/

Подставится / или текущая директория. И дальше - лотерея.

▪️ Перепутаны местами аргументы

rsync -av --delete backup:/data/ /data/

Удаляем прод, потому что backup оказался пустым.

▪️ Что происходит в этот момент

inode удаляются
файловая система занята
приложения падают
БД начинают ругаться
контейнеры теряют volume

А вы смотрите на логи и видите, как rsync методично чистит прод.

▪️ Как не повторить

1️⃣ Всегда делайте dry-run

rsync -av --delete --dry-run ...

Если видите тысячи deleting - остановитесь.

2️⃣ Проверяйте, что диск примонтирован (добавляйте это в скрипты)

mountpoint -q /data || exit 1

3️⃣ Используйте защитные опции

--max-delete=100

Если удалений больше - rsync аварийно завершится.

4️⃣ Делайте snapshot перед синхронизацией.
LVM, ZFS, btrfs - спасают карьеры.

5️⃣ Разделяйте роли.
Бэкап не должен иметь права удалять прод-данные.

#linux #rsync

📎 TCP keepalive: почему соединения умирают и как это чинить

Знакомая ситуация: приложение держит постоянное TCP-соединение (к БД, API, брокеру), все работает… а потом внезапно «connection reset» или таймаут. Особенно часто это происходит через 5–30 минут простоя. Причина обычно не в приложении, а в сети.

🤩 Что происходит

Между клиентом и сервером почти всегда есть:

NAT
firewall
балансировщик
облачный LB

Эти устройства хранят таблицы состояний соединений. Если трафика нет - запись удаляется. Со стороны приложения соединение живое, но по факту его уже нет.

▪️ Где здесь TCP keepalive

TCP keepalive - это механизм, при котором стек TCP периодически отправляет служебные пакеты, чтобы подтвердить, что соединение ещё активно.

По умолчанию в Linux:

tcp_keepalive_time = 7200 (2 часа!)
tcp_keepalive_intvl = 75
tcp_keepalive_probes = 9

Для современных инфраструктур это слишком долго - NAT обычно живет 300–900 секунд.

▪️ Как чинить

1️⃣ Включить keepalive в приложении (многие драйверы БД и HTTP-клиенты это поддерживают).

2️⃣ Настроить параметры в системе:

sysctl -w net.ipv4.tcp_keepalive_time=300
sysctl -w net.ipv4.tcp_keepalive_intvl=30
sysctl -w net.ipv4.tcp_keepalive_probes=5

Теперь проверка пойдет через 5 минут простоя, а не через 2 часа.

3️⃣ Учитывать таймауты балансировщиков (например, в облаке они могут быть 350 секунд).

#linux #networking

🧑‍💻 NetworkAdmin

Просьба не завидовать 😎

#юмор

🧑‍💻 NetworkAdmin

💫 Быстрые откаты системы без LVM

Файловая система Btrfs умеет делать снапшоты - мгновенные снимки состояния файловой системы. Это позволяет быстро откатывать систему или данные назад без использования LVM, внешних бэкапов или сложных схем.

Снапшоты в Btrfs работают по принципу Copy-on-Write (CoW): данные не копируются сразу. Создается только метаданные-ссылка на текущие блоки. Реальное место начинает занимать только то, что изменяется после создания снимка.

▪️ Создание subvolume. Сначала создаем подтом (subvolume), если его еще нет:

btrfs subvolume create /data

▪️ Создание snapshot. Сделаем снимок текущего состояния:

btrfs subvolume snapshot /data /data_snapshot

Это занимает доли секунды независимо от размера данных.

Можно сделать snapshot только для чтения:

btrfs subvolume snapshot -r /data /snapshots/data_2026-04-20

▪️ Просмотр снапшотов

btrfs subvolume list /

▪️ Откат к предыдущему состоянию. Удаляем текущий subvolume:

btrfs subvolume delete /data

И возвращаем snapshot:

btrfs subvolume snapshot /snapshots/data_2026-04-20 /data

Система или сервис сразу получают прежнее состояние файлов.

⚠️ Важно помнить

снапшот не является полноценным Бэконом
повреждение диска уничтожит и данные, и снапшоты

для защиты данных используйте отдельные бэкапы (например restic или borg)

#linux #btrfs

🧑‍💻 NetworkAdmin

👨‍💻 tcpdump: набор команд для быстрой диагностики сети

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

⚠️ Практически всегда добавляю ключ -nn, чтобы tcpdump не резолвил IP-адреса в домены и не подменял номера портов именами сервисов. В отладке это только мешает.

▪️ Список интерфейсов для захвата. Посмотреть, с каких интерфейсов можно слушать трафик:

tcpdump -D

Если запускать tcpdump без параметров, он будет слушать первый активный интерфейс из списка.

▪️ Захват трафика. Слушаем все интерфейсы:

tcpdump -nn -i any

Или конкретный:

tcpdump -nn -i eth0

▪️ Фильтрация по портам. Иногда один протокол полностью забивает вывод. Например, SSH. Его можно исключить:

tcpdump -nn -i any not port 22

Или наоборот смотреть только нужный порт:

tcpdump -nn -i any port 443

▪️ Фильтрация по IP. Трафик к определенному серверу:

tcpdump -nn dst 1.1.1.1

Несколько адресов:

tcpdump -nn dst 1.1.1.1 or dst 9.9.9.9

Комбинация адреса и порта:

tcpdump -nn dst 1.1.1.1 and port 443

Фильтры можно комбинировать через and / or / not.

▪️ Фильтрация по протоколу. Например, посмотреть ARP:

tcpdump -nn -i any arp

Или исключить его:

tcpdump -nn -i any not arp

▪️ Сохранение вывода. Если трафика много, удобнее писать его в файл:

tcpdump -nn -i any > ~/traffic.log

▪️ Пример из практики. Посмотреть HTTPS-трафик от конкретного клиента к серверу через VPN:

tcpdump -nn -i tun0 src 10.10.0.25 and dst 10.10.0.5 and port 443

Несмотря на пугающий вывод, tcpdump довольно простой инструмент.
Чаще всего достаточно увидеть строки вроде:

IP 10.0.0.12.53422 > 10.0.0.5.443

Где указаны источник, порт, получатель и порт назначения. Этого уже хватает, чтобы понять, что происходит в сети.

#network #tcpdump

🧑‍💻 NetworkAdmin

❗️ cgroups v2: ограничение CPU/RAM для сервисов без Docker

Многие привыкли к тому, что лимиты CPU и памяти - это что-то из мира docker и k8s. Но на самом деле механизм один и тот же: cgroups. И если у вас обычный linux-сервер без контейнеров, вы все равно можете жестко ограничивать ресурсы для systemd-сервисов.

Это удобно, когда один процесс начинает съедать всю память, душить CPU или мешать остальным сервисам на хосте.

В современных дистрибутивах используется cgroups v2, а systemd умеет работать с ним из коробки.

▪️ Что можно ограничить:

Память. Чтобы сервис не выедал весь RAM и не отправлял сервер в OOM.
CPU. Чтобы процесс не занимал все ядра и не мешал соседям.
Число процессов. Чтобы защититься от fork-бомб и неконтролируемого роста дочерних процессов.

▪️ Пример: ограничим сервис по памяти и CPU.. Откроем override-конфиг:

systemctl edit myapp.service

Добавим:

[Service]
MemoryMax=500M
CPUQuota=50%
TasksMax=200

MemoryMax=500M - сервис не сможет использовать больше 500 МБ памяти
CPUQuota=50% - максимум половина одного CPU
TasksMax=200 - не более 200 процессов/потоков

После этого применяем изменения:

systemctl daemon-reload
systemctl restart myapp.service

Проверить лимиты можно так:

systemctl show myapp.service | grep -E "MemoryMax|CPUQuota|TasksMax"

Или посмотреть, в какой cgroup живет процесс:

systemctl status myapp.service

Если хотите ограничить уже запущенный сервис без ручного редактирования unit-файла, можно использовать runtime-свойства:

systemctl set-property myapp.service MemoryMax=300M CPUQuota=25%

Это удобно для быстрого придушивания прожорливого процесса на боевом сервере.

▪️ Еще полезные параметры:

[Service]
MemoryHigh=400M
MemoryMax=500M
CPUWeight=200
IOWeight=200

Тут разница такая:

MemoryHigh - мягкий порог, после которого ядро начинает сильнее давить процесс по памяти
MemoryMax - жесткий предел
CPUWeight - относительный приоритет по CPU среди других cgroup
IOWeight - относительный приоритет по дисковому I/O

⚠️ Важно помнить

CPUQuota=50% - это не половина всех ядер, а квота CPU-времени. На многоядерных системах поведение нужно понимать внимательно.

И еще: если сервис уже упирается в лимит памяти, он может начать падать, а не магически оптимизироваться. Лимиты защищают систему, но не исправляют плохое приложение.

#systemd #cgroups

🧑‍💻 NetworkAdmin

👉 NTFS vs ReFS: что использовать на серверах Windows

Когда речь заходит о файловой системе на Windows Server, многие смотрят на ReFS как на новый NTFS. Но в реальной эксплуатации все не так просто.

NTFS - это универсальный и самый совместимый вариант.
ReFS - это специализированный инструмент под определенные сценарии, а не замена везде и для всего. Microsoft прямо позиционирует NTFS как файловую систему по умолчанию, а ReFS - как вариант для задач, где важны целостность данных, масштабирование и отдельные storage-оптимизации.

▪️ Что дает NTFS:

▪️максимальную совместимость с приложениями и ролями windows;
▪️привычные функции вроде ACL, квот, сжатия и EFS;
▪️нормальную жизнь для системных и загрузочных томов;
▪️меньше сюрпризов в проде, когда у вендора в требованиях написано просто: Windows Server;

▪️ Что дает ReFS:

▪️лучшую защиту от повреждения данных;
▪️integrity streams и проверку целостности;
▪️block cloning и другие оптимизации для крупных storage-нагрузок;
▪️хорошие сценарии в связке с Storage Spaces / S2D и Hyper-V-нагрузками ;

Но вот где начинается практика.

▪️ ReFS - не ставим везде вместо NTFS.

У него до сих пор не такая универсальная совместимость, как у NTFS. Для части сценариев microsoft сама рекомендует NTFS: например, SAN-тома в Failover Cluster обычно форматируют в NTFS, а для Azure File Sync серверный endpoint вообще поддерживается только на NTFS. Для S2D/Storage Spaces Direct, наоборот, ReFS - рекомендуемый вариант.

То есть выбор обычно выглядит так:

▪️Системный диск, обычный файловый сервер, универсальный сервер под все - NTFS
▪️Hyper-V, Storage Spaces Direct, большие data-volume, backup/storage-нагрузки - смотреть в сторону ReFS

▪️ Где NTFS лучше:

▪️системные и boot-разделы;
▪️серверы с максимальной совместимостью ПО;
▪️роли, где нужны квоты, сжатие, EFS и предсказуемое поведение;
▪️инфраструктура, где важнее “работает у всех”, чем storage-фишки;

▪️ Где ReFS уместен:

▪️Hyper-V-хосты;
▪️volumes под VHDX;
▪️Storage Spaces Direct;
▪️большие хранилища, где важна целостность и быстрые операции на уровне метаданных;

#windowsserver #refs

🧑‍💻 NetworkAdmin

Вот такое упражнение раз в полгода делай и системный блок всегда чистый будет

#юмор

🧑‍💻 NetworkAdmin

📱 K8s на практике

Теория без практики - не даст большого результата. Наткнулся на hands-on челлендж:

В кластере есть Pod, который не может нормально стартануть.
Он пытается подняться, но постоянно падает.
Причина: в спецификацию недавно добавили новый контейнер, и после этого init-последовательность стала некорректной.

Задачей является найти, что именно сломали, и починить, чтобы Pod снова запускался.

Внутри будет:

▪️init containers и порядок старта;
▪️логи Pod / events;
▪️kubectl describe / logs;
▪️диагностика CrashLoopBackOff и зависаний.

Ссылка 👈

#kubernetes #devops

🧑‍💻 NetworkAdmin

📱 Что показывать на IP-адресе Nginx, чтобы не светить виртуальные хосты

Если обратиться к Nginx-серверу по IP-адресу, а не по доменному имени, то обычно откроется либо первый virtual host в конфиге, либо тот, где указан default_server в listen. Чаще всего показывать что-то реальное на таком запросе не хочется, поэтому на IP обычно вешают заглушку.

▪️ Для HTTP это решается просто:

server {
    listen 80 default_server;
    server_name _;
    return 404;
}

С обычным HTTP все понятно.

▪️ С HTTPS начинается самое интересное.. Если клиент приходит на сервер по IP через HTTPS, Nginx все равно должен отдать какой-то сертификат. И если отдельный сертификат для такого случая не задан, будет использован сертификат одного из виртуальных хостов. То есть конфиг вроде такого:

server {
    listen 443 ssl default_server;
    server_name _;
    return 404;
}

не решает проблему полностью.

Что увидит пользователь: сначала предупреждение браузера о том, что сертификат не соответствует адресу, а потом, если продолжить, в сертификате можно будет увидеть домен реального сайта

Получается, что даже заглушка на IP все равно может засветить боевой домен.

▪️ Один из старых и рабочих вариантов - использовать самоподписанный сертификат-пустышку.. Создаем его так:

openssl req -x509 -nodes -days 3650 -newkey rsa:2048 \
  -keyout /etc/nginx/certs/nginx.key \
  -out /etc/nginx/certs/nginx.crt

И подключаем в default server:

server {
    listen 443 ssl default_server;
    server_name _;
    ssl_certificate /etc/nginx/certs/nginx.crt;
    ssl_certificate_key /etc/nginx/certs/nginx.key;
    return 404;
}

Такой подход уже лучше: реальные домены не светятся, но браузер все равно покажет предупреждение о недоверенном сертификате.

Для многих этого достаточно. Я и сам долго делал именно так. Но есть более аккуратный вариант:

server {
    listen 80 default_server;
    listen 443 ssl default_server;
    server_name _;
    ssl_reject_handshake on;
    return 404;
}

Здесь ключевая директива - ssl_reject_handshake on.

Она позволяет сразу отклонять TLS-handshake, не отдавая пользователю чужой сертификат и не доводя дело до стандартного браузерного предупреждения о несовпадении имени.

Что это дает на практике:

запросы по IP на 443 сразу режутся;
сертификаты реальных виртуальных хостов не светятся;
пользователь сразу получает ошибку соединения, без лишних переходов и предупреждений.

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

ssl_reject_handshake on удобно использовать именно в default server для HTTPS-запросов, которые не должны попадать ни в один нормальный виртуальный хост. Если задача - не просто вернуть 404, а вообще не раскрывать ничего лишнего по IP, это один из самых аккуратных вариантов.

#nginx #webserver

🧑‍💻 NetworkAdmin

Те самые юзеры: «да я и сам соберу, там делов то»

#юмор

🧑‍💻 NetworkAdmin

👾 Быстрый поиск пожирателей диска

Когда на сервере внезапно заканчивается место, первое желание - запустить что-нибудь вроде du -sh * и начать вручную искать, кто сожрал диск. Рабочий способ, но неудобный. Особенно если каталогов много, структура глубокая, а проблема уже горит.

В таких ситуациях выручает ncdu - консольная утилита для быстрого анализа использования диска. По сути это удобная оболочка над du, но с нормальной навигацией по каталогам в терминале.

▪️ Установка простая:

apt install ncdu

или

yum install ncdu

▪️ Запуск:

ncdu /

После сканирования увидите дерево каталогов, отсортированное по размеру. Дальше можно просто ходить стрелками по директориям и сразу смотреть, что именно занимает место.

Почему это удобно:

не нужно вручную гонять du по каждому уровню
сразу видно самые тяжелые каталоги
можно быстро проваливаться внутрь и искать источник проблемы
работает прямо в терминале, без GUI и лишних зависимостей

▪️ Типичный сценарий: сервер начал ругаться на нехватку места, заходите через SSH, запускаете:

ncdu /var

и почти сразу видите, кто виноват: разросшиеся логи, старые бэкапы, кэш пакетов, временные файлы или мусор в home-директориях.

▪️ Полезные варианты запуска:. анализ только нужного раздела:

ncdu /var

исключить файловые системы mount points (будет полезно, если не хотите случайно уйти в примонтированные тома и сетевые FS):

ncdu -x /

работать тише и быстрее на больших системах:

ncdu -q /data

Если запускать от root, картина будет полной, потому что утилита сможет читать все каталоги.

▪️ Еще один приятный момент: в ncdu можно не только смотреть размеры, но и сразу удалять ненужные файлы и каталоги из интерфейса. Но тут уже нужно быть очень аккуратным.

#ncdu #disk

🧑‍💻 NetworkAdmin

🔖 DNS caching servers: unbound vs bind vs systemd-resolved

Когда в инфраструктуре нужен локальный DNS-кэш, выбор обычно сводится к трем вариантам: Unbound, BIND и systemd-resolved. Все они умеют работать с DNS, но подходят под разные задачи.

▪️ Важно понять главное:

systemd-resolved - это в первую очередь локальный stub-resolver для хоста.
Unbound - легкий рекурсивный и кэширующий резолвер.
BIND - большой комбайн, который умеет и рекурсию, и authoritative DNS, и сложные серверные сценарии.

▪️ Что это значит на практике.

▪️Unbound -отличный вариант, когда нужен именно быстрый caching/recursive DNS server без лишней тяжести. Он изначально позиционируется как validating, recursive, caching resolver и хорошо подходит для локального DNS-кэша в офисе, на шлюзе, в домашней лаборатории или как отдельный резолвер для серверов.

▪️BIND - подходит, когда DNS в вашей инфраструктуре - это уже не просто кэш, а полноценный сервис с зонами, views, форвардингом, authoritative-частью, интеграциями и сложной логикой. Он мощный, гибкий, но за это платите более тяжелой конфигурацией и большим объемом настроек.

▪️systemd-resolved - удобен как локальный резолвер на самой машине. Он дает кэширование, stub-resolver на 127.0.0.53, умеет DNSSEC validation, а также работает с LLMNR и mDNS. Для ноутбука, обычного Linux-хоста или VM это часто уже достаточно хорошо. Но строить на нем центральный DNS-кэширующий сервер для всей сети - обычно не лучший выбор.

▪️ Как выбирать?

нужен DNS-кэш для сервера или небольшой сети - это Unbound
нужен DNS-комбайн с authoritative-зонами и сложной серверной логикой - это BIND
нужен просто нормальный локальный резолвер на Linux-хосте - это systemd-resolved

Поэтому перед выбором инструмента лучше честно ответить на вопрос: вам нужен локальный резолвер для одного хоста, кэширующий DNS для сети или полноценный DNS-сервер. И вот от этого уже выбирать: systemd-resolved, Unbound или BIND.

#dns #network

🧑‍💻 NetworkAdmin

✍️ iotop, dstat, pidstat: поиск узких мест по диску и CPU

Когда сервер начинает тормозить, первая ошибка - сразу лезть в логи и гадать, что что-то жрет ресурсы. Гораздо полезнее сначала быстро ответить на три вопроса: кто грузит CPU, кто долбит диск, и где именно начинается узкое место.

Для такой первичной диагностики очень хорошо работают три утилиты: iotop, dstat и pidstat. Они не заменяют полноценный мониторинг, но отлично помогают, когда нужно быстро понять, что происходит прямо сейчас.

▪️ iotop - показывает, кто активно читает и пишет на диск. Если сервер упирается в I/O, обычный top это не всегда покажет. Процесс может почти не грузить CPU, но при этом убивать систему постоянной записью или чтением.

Запуск:

iotop

Полезный вариант:

iotop -o

Ключ -o оставляет только процессы, у которых прямо сейчас есть дисковая активность.

▪️ dstat - дает общую картину по системе

dstat хорош тем, что показывает сразу несколько метрик в одном месте:

CPU
disk I/O
network
memory
swap
interrupts

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

dstat

Более полезный вариант:

dstat -cdngym

Что здесь видно:

загрузка CPU
чтение/запись на диск
сетевой трафик
использование памяти
swap
активность файловой системы

▪️ pidstat - показывает статистику по конкретным процессам. Если top и iotop уже намекнули на виновника, pidstat помогает посмотреть детальнее.

Например, по CPU:

pidstat 1

По дисковой активности:

pidstat -d 1

По памяти:

pidstat -r 1

По отдельному процессу:

pidstat -p 1234 1

Где 1234 - это PID нужного процесса.

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

▪️ Как использовать это на практике:

1. Сначала смотрим общую картину

dstat -cdngym

Понимаем, куда система упирается: CPU, диск, память или сеть.

2. Если подозрение на диск

iotop -o

Сразу ищем, кто генерирует I/O.

3. Если нужен разбор по процессам

pidstat -d 1
pidstat 1

Смотрим поведение процессов в динамике.

Такой набор часто дает ответ быстрее, чем долгие догадки и хаотичный запуск всего подряд.

#linux #sysadmin

🧑‍💻 NetworkAdmin

🖥 gping и fping

Стандартный ping - полезный инструмент, но в реальной админской жизни его часто не хватает. Иногда хочется быстро увидеть задержку на графике, а иногда - массово проверить десятки или сотни адресов без лишней возни с выводом.

Для этого есть как минимум две полезные утилиты: gping и fping. Они не заменяют классический ping, а скорее дополняют его под разные задачи.

1️⃣ gping - ping с графиком задержки. Она умеет не просто пинговать хост, а показывать время отклика в виде графика. Причем можно проверять сразу несколько адресов одновременно.

Установка:

apt install gping

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

gping 1.1.1.1 8.8.8.8 8.8.4.4

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

Практической пользы для серверной рутины тут не всегда много, но для личного терминала, быстрой проверки канала или просто наглядной диагностики - вещь приятная.

gping скорее из категории удобных и визуально понятных инструментов, чем must-have на каждом сервере.

2️⃣ fping - массовая проверка узлов без лишнего шума. А вот fping - уже куда более прикладная история. Это старая и проверенная утилита, которая отлично подходит для быстрого пинга списков хостов, диапазонов адресов и целых подсетей. Именно за это ее любят в мониторинге и автоматизации.

Установка:

apt install fping

Например, быстро найти активные узлы в сети можно так:

fping -g 192.168.13.0/24 -qa

На выходе получите только адреса тех хостов, которые ответили:

192.168.13.1
192.168.13.2
192.168.13.17
192.168.13.50
192.168.13.186

Очень удобно, потому что формат вывода уже готов для скриптов: одна строка - один IP.

Можно проверять и диапазон явно:

fping -s -g 192.168.13.1 192.168.13.50 -qa

Если нужен обычный пинг одного хоста:

fping 10.20.1.2

Результат будет простой и понятный:

10.20.1.2 is alive

Еще один полезный сценарий - использовать fping в скриптах через код возврата. Например:

fping 10.20.1.2 -q
echo $?

Если хост доступен, получите: 0

Если нет:

fping 10.20.1.3 -q
echo $?

Результат: 1

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

Обе утилиты полезны, но в разных сценариях.

gping - больше про удобство и визуализацию.
fping - про практичность, автоматизацию и реальные админские задачи.

#ping #network

🧑‍💻 NetworkAdmin