现已上线！2025 年 Telegram 研究 — 年度关键洞察 
NetworkAdmin.ru
前往频道在 Telegram
Авторский блог про сетевое и системное администрирование. Сайт: networkadmin.ru Реклама: @dad_admin Биржа: https://telega.in/c/networkadminru
显示更多4 723
订阅者
-224 小时
-67 天
-230 天
帖子存档
4 723
📱 Что показывать на IP-адресе Nginx, чтобы не светить виртуальные хосты
Если обратиться к Nginx-серверу по IP-адресу, а не по доменному имени, то обычно откроется либо первый virtual host в конфиге, либо тот, где указан default_server в listen. Чаще всего показывать что-то реальное на таком запросе не хочется, поэтому на IP обычно вешают заглушку.
▪️ Для HTTP это решается просто:
server {
listen 80 default_server;
server_name _;
return 404;
}
server {
listen 443 ssl default_server;
server_name _;
return 404;
}
openssl req -x509 -nodes -days 3650 -newkey rsa:2048 \
-keyout /etc/nginx/certs/nginx.key \
-out /etc/nginx/certs/nginx.crt
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
🧑💻 NetworkAdmin4 723
📱 K8s на практике
Теория без практики - не даст большого результата. Наткнулся на hands-on челлендж:
В кластере есть Pod, который не может нормально стартануть.
Он пытается подняться, но постоянно падает.
Причина: в спецификацию недавно добавили новый контейнер, и после этого init-последовательность стала некорректной.
Задачей является найти, что именно сломали, и починить, чтобы Pod снова запускался.
Внутри будет:
▪️init containers и порядок старта;
▪️логи Pod / events;
▪️kubectl describe / logs;
▪️диагностика CrashLoopBackOff и зависаний.
Ссылка 👈
#kubernetes #devops
🧑💻 NetworkAdmin
4 723
Вот такое упражнение раз в полгода делай и системный блок всегда чистый будет
#юмор
🧑💻 NetworkAdmin
4 723
👉 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
4 723
🎥 Вебинар: «От кода до Kubernetes за полтора часа»
О чём поговорим:
- Создание Docker-образа ASP.NET-приложения
- Подготовка манифестов для Kubernetes
- Разворачивание в кластере (minikube/microk8s/demo-кластер)
- Настройка сервисов, ingress, переменных окружения
- Практика с kubectl и манифестами
- Ответы на вопросы в режиме live
Что вы получите:
- Пошаговый сценарий деплоя ASP.NET-приложения в Kubernetes;
- Поймёте, как настроить сервисы, ingress и переменные окружения;
- Освоите базовые команды для управления кластером;
- Готовый шаблон манифестов и инструкцию для своих проектов.
👉 Для участия зарегистрируйтесь: https://otus.pw/ceHE/
🎁 Все участники вебинара получат специальные условия на полное обучение курса «Инфраструктурная платформа на основе Kubernetes»
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru
4 723
❗️ 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=200MemoryMax=500M - сервис не сможет использовать больше 500 МБ памяти
CPUQuota=50% - максимум половина одного CPU
TasksMax=200 - не более 200 процессов/потоков
После этого применяем изменения:
systemctl daemon-reload
systemctl restart myapp.service
systemctl show myapp.service | grep -E "MemoryMax|CPUQuota|TasksMax"
systemctl status myapp.service
systemctl set-property myapp.service MemoryMax=300M CPUQuota=25%
[Service]
MemoryHigh=400M
MemoryMax=500M
CPUWeight=200
IOWeight=200MemoryHigh - мягкий порог, после которого ядро начинает сильнее давить процесс по памяти
MemoryMax - жесткий предел
CPUWeight - относительный приоритет по CPU среди других cgroup
IOWeight - относительный приоритет по дисковому I/O
⚠️ Важно помнить
CPUQuota=50% - это не половина всех ядер, а квота CPU-времени. На многоядерных системах поведение нужно понимать внимательно.
И еще: если сервис уже упирается в лимит памяти, он может начать падать, а не магически оптимизироваться. Лимиты защищают систему, но не исправляют плохое приложение.
#systemd #cgroups
🧑💻 NetworkAdmin4 723
👨💻 tcpdump: набор команд для быстрой диагностики сети
Инструмент незаменимый, возможностей у него огромное количество, но на практике чаще всего хватает небольшого набора команд. Ниже краткая шпаргалка из того, что реально используется в работе.
⚠️ Практически всегда добавляю ключ
-nn, чтобы tcpdump не резолвил IP-адреса в домены и не подменял номера портов именами сервисов. В отладке это только мешает.
▪️ Список интерфейсов для захвата. Посмотреть, с каких интерфейсов можно слушать трафик:
tcpdump -D
tcpdump -nn -i any
tcpdump -nn -i eth0
tcpdump -nn -i any not port 22
tcpdump -nn -i any port 443
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
tcpdump -nn -i any arp
tcpdump -nn -i any not arp
tcpdump -nn -i any > ~/traffic.log
tcpdump -nn -i tun0 src 10.10.0.25 and dst 10.10.0.5 and port 443
IP 10.0.0.12.53422 > 10.0.0.5.4434 723
В России можно посещать IT-мероприятия хоть каждый день: как оффлайн, так и онлайн
Но где их находить? Как узнавать о них раньше, чем когда все начнут выкладывать фотографии оттуда?
Переходите на канал IT-Мероприятия России. В нём каждый день анонсируются мероприятия со всех городов России
📆 в канале размещаются как онлайн, так и оффлайн мероприятия;
👩💻 можно найти ивенты по любому стеку: программирование, frontend-backend разработка, кибербезопасность, дата-аналитика, osint, devops и другие;
🎙 разнообразные форматы мероприятий: митапы с коллегами по цеху, конференции и вебинары с известными опытными специалистами, форумы и олимпиады от важных представителей индустрии и многое другое
А чтобы не искать по разным форумам и чатам новости о предстоящих ивентах:
🚀 IT-мероприятия России — подписывайся и будь в курсе всех предстоящих мероприятий!
4 723
💫 Быстрые откаты системы без LVM
Файловая система Btrfs умеет делать снапшоты - мгновенные снимки состояния файловой системы. Это позволяет быстро откатывать систему или данные назад без использования LVM, внешних бэкапов или сложных схем.
Снапшоты в Btrfs работают по принципу Copy-on-Write (CoW): данные не копируются сразу. Создается только метаданные-ссылка на текущие блоки. Реальное место начинает занимать только то, что изменяется после создания снимка.
▪️ Создание subvolume. Сначала создаем подтом (subvolume), если его еще нет:
btrfs subvolume create /data
btrfs subvolume snapshot /data /data_snapshot
btrfs subvolume snapshot -r /data /snapshots/data_2026-04-20
btrfs subvolume list /
btrfs subvolume delete /data
btrfs subvolume snapshot /snapshots/data_2026-04-20 /data4 723
🚀 INFRAX 1.0.0 — официальный выход из беты!
INFRAX — это единая российская on-premise платформа (ситуационный центр ИТ-инфраструктуры).
В одном интерфейсе: мониторинг (ITOM), Service Desk (ITSM), CMDB + ITAM, резервное копирование, удалённый доступ (RPAM), автоматизация, агентный ИИ-помощник и управление виртуализацией.
Заменяет зоопарк из 12+ разрозненных систем — всё под рукой, данные не уходят наружу.
✨ Главное в версии 1.0.0
• SNMP-мониторинг
• Резервное копирование
• SLA
• CMDB + ITAM
• Поддержка из тикета
• Инструменты инженера
• Агентный ИИ-помощник
INFRAX 1.0.0 — вся ИТ-инфраструктура теперь в одной удобной и мощной системе.
Готовы закрыть все боли одним решением?
infrax.ru 🔥
#реклама
О рекламодателе
4 723
📎 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
sysctl -w net.ipv4.tcp_keepalive_time=300
sysctl -w net.ipv4.tcp_keepalive_intvl=30
sysctl -w net.ipv4.tcp_keepalive_probes=54 723
😭 Как один 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./data - пустая локальная папка
rsync --delete удаляет все на целевом хранилище.
▪️ Пустая переменная
SRC=""
rsync -av --delete $SRC /backup/
rsync -av --delete backup:/data/ /data/
rsync -av --delete --dry-run ...
mountpoint -q /data || exit 1
--max-delete=1004 723
❗️ 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
- 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
/etc/ansible/facts.d/app.fact
{
"role": "backend",
"env": "prod"
}
ansible_local.app.role
ansible_local.app.env
- set_fact:
is_prod: "{{ 'prod' in inventory_hostname }}"
when: is_prod
- name: Get DB IP
command: hostname -I
register: db_ip
delegate_to: db01
run_once: true
fact_caching = jsonfile
fact_caching_connection = /tmp/ansible_facts_cache
fact_caching_timeout = 86400
when: ansible_memtotal_mb > 160004 723
🤩 Как быстро проверить ширину канала через netcat
Если нужно оперативно прикинуть пропускную способность канала между двумя Linux-машинами, можно обойтись без установки
iperf. Достаточно netcat, который в большинстве дистрибутивов уже есть.
▪️ Простой тест
Допустим, есть сервер 10.25.1.157.
На нем запускаем слушатель:
nc -lvp 5201 > /dev/null
dd if=/dev/zero bs=10M count=10 | nc 10.25.1.157 5201netcat и 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
🧑💻 NetworkAdmin4 723
Приглашаем на AMA-сессию 4.0
2026 год продолжает быть годом активного импортозамещения. В этот период особенно важно, чтобы производитель был максимально открыт к диалогу. Именно поэтому мы проводим открытую AMA-сессию 4.0 с генеральным директором vStack Евгением Карповым.
Кому это будет особенно полезно:
➖ Системным администраторам
➖ Архитекторам ИТ-инфраструктуры
➖ ИТ-директорам
➖ Собственникам бизнеса
➖ Облачным провайдерам
«Мы вступаем в 2026 год с пониманием, что российские продукты должны быть не просто альтернативой, а полноценными инструментами, которыми удобно пользоваться. Формат AMA позволит нам глубже понять потребности рынка и сориентировать развитие продукта в русле реальных запросов пользователей», — Евгений Карпов, генеральный директор vStack.
Дата и время вебинара: 14 апреля в 13.00
Спикер: Евгений Карпов, генеральный директор vStack
🔗 Регистрация
#реклама
О рекламодателе
4 723
📱 Настройка 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
export HISTSIZE=10000
export HISTIGNORE="ls:history:w:htop:pwd:top:iftop"
export HISTCONTROL=ignorespace
source ~/.bashrc
export | grep -i hist
/etc/profile.d/history.shCtrl + R.
Нажимаете и начинаете вводить команду. Повторное Ctrl + R - следующий результат.
Я чаще делаю так:
history | grep 'apt install'4 723
🔖 tcpdump advanced: фильтры, которые реально нужны
Большинство используют tcpdump как "посмотреть весь трафик на 80 порт". Но настоящая сила в BPF-фильтрах. Правильный фильтр = меньше шума, быстрее диагностика и меньше нагрузки на сервер. Небольшая шпаргалка фильтров, которые реально пригождаются.
1️⃣ Конкретный хост + порт
tcpdump -i eth0 host 10.10.10.5 and port 443
tcpdump -i eth0 src host 192.168.1.10
tcpdump -i eth0 dst host 192.168.1.10
tcpdump -i eth0 'tcp[tcpflags] & tcp-syn != 0'
tcpdump -i eth0 'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn'
tcpdump -i eth0 not port 22
tcpdump -i eth0 not net 10.0.0.0/8
tcpdump -i eth0 'tcp[tcpflags] & tcp-rst != 0'
tcpdump -nn -i eth0 tcp
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)'
tcpdump -i eth0 -w dump.pcap
tcpdump -i eth0 -C 100 -W 5 -w dump.pcap
tcpdump -i eth0 port 53
tcpdump -i eth0 'udp port 53 and greater 512'
