NetworkAdmin.ru

📱 Bash как DSL: пишем читаемые админские скрипты Многие админские bash-скрипты со временем превращаются в свалку из if, grep, awk, sed и случайных команд, склеенных по принципу: работает - не трогай. Проблема в том, что через месяц такой скрипт уже тяжело читать. Через полгода - страшно менять. А если его откроет другой админ, он вообще решит, что это археология, а не автоматизация. Один из рабочих подходов - писать bash не как набор команд, а как маленький DSL: domain-specific language, то есть мини-язык под свою задачу. Идея простая: вместо простыни команд вы собираете скрипт из понятных функций с говорящими именами. Например, не так:

useradd -m -s /bin/bash "$name"
mkdir -p "/home/$name/.ssh"
cp ./authorized_keys "/home/$name/.ssh/authorized_keys"
chown -R "$name:$name" "/home/$name/.ssh"
chmod 700 "/home/$name/.ssh"
chmod 600 "/home/$name/.ssh/authorized_keys"

А так:

create_user "$name"
install_ssh_keys "$name"
harden_ssh_dir "$name"

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

create_user() {
  useradd -m -s /bin/bash "$1"
}

install_ssh_keys() {
  local user="$1"
  mkdir -p "/home/$user/.ssh"
  cp ./authorized_keys "/home/$user/.ssh/authorized_keys"
  chown -R "$user:$user" "/home/$user/.ssh"
}

harden_ssh_dir() {
  local user="$1"
  chmod 700 "/home/$user/.ssh"
  chmod 600 "/home/$user/.ssh/authorized_keys"
}

Теперь верхний уровень скрипта выглядит уже не как набор случайных действий, а как понятный workflow:

create_user "$name"
install_ssh_keys "$name"
harden_ssh_dir "$name"

👍 Что это дает на практике: скрипт легче читать: сразу видно, что делает логика, без погружения в детали. проще сопровождать: меняете реализацию внутри функции, не ломая структуру всего скрипта. меньше копипасты: повторяющиеся куски уезжают в функции. проще дебажить: если сломалось install_ssh_keys, вы уже знаете, где искать проблему. ➕ Еще один полезный прием - делать функции в стиле команд:

require_root
check_dependencies
backup_config "/etc/nginx/nginx.conf"
deploy_new_config "./nginx.conf" "/etc/nginx/nginx.conf"
test_nginx_config
reload_nginx

Такой bash уже напоминает не набор shell-команд, а язык операций для конкретной задачи. Пример плохого Bash-скрипта:

cp "$src" "$dst" &&
nginx -t &&
systemctl reload nginx ||
echo "something failed"

Пример более читаемого подхода:

deploy_config "$src" "$dst"
validate_nginx
reload_service nginx

Да, bash не станет от этого python. Но даже в shell можно писать так, чтобы скрипт был похож на понятную инструкцию, а не на клубок из условий, пайпов и боли. #bash #scripting 🧑‍💻 NetworkAdmin

📘 На платформе Mentorix вышел курс — «DevOps-инженер: от основ до продакшена» Если вы хотите не просто изучить инструменты, а понять, как собирается реальная DevOps-инфраструктура — этот курс даёт полный системный подход. 🔧 Что внутри: • Linux, администрирование и bash • Docker и Kubernetes (реальная оркестрация) • Terraform и Ansible (Infrastructure as Code) • CI/CD: GitLab CI, GitHub Actions, Jenkins • мониторинг и логирование: Prometheus, Grafana, ELK • безопасность, сети, балансировка нагрузки • облака (AWS/GCP/Azure) 📊 Формат: — 82 урока и 784 шага — 320 теорий, 325 тестов, 139 задач практических задач — практика в каждом блоке 💡 Важно: вы не просто изучаете инструменты — вы собираете end-to-end инфраструктуру, которую можно положить в портфолио и показывать на собеседованиях. 💰 скидка 40%, действует 24 часа 👉 Пройти курс

🖥 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

✍️ 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

🔖 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

👾 Быстрый поиск пожирателей диска Когда на сервере внезапно заканчивается место, первое желание - запустить что-нибудь вроде 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

📘 На платформе Mentorix вышел курс — «Nginx на практике: от деплоя до production» Практический курс по настройке Nginx для реальных задач: от базовой конфигурации до использования в production. В курсе: • настройка и конфигурация Nginx • работа как reverse proxy • SSL и HTTPS • балансировка нагрузки • подготовка конфигурации для production Начать можно сразу — вводная часть курса доступна без оплаты. 🎁 Промокод: NGINX_20 Скидка 20% — действует 48 часов 👉 Пройти курс

Те самые юзеры: «да я и сам соберу, там делов то» #юмор 🧑‍💻 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

📱 K8s на практике Теория без практики - не даст большого результата. Наткнулся на hands-on челлендж: В кластере есть Pod, который не может нормально стартануть. Он пытается подняться, но постоянно падает. Причина: в спецификацию недавно добавили новый контейнер, и после этого init-последовательность стала некорректной. Задачей является найти, что именно сломали, и починить, чтобы Pod снова запускался. Внутри будет: ▪️init containers и порядок старта; ▪️логи Pod / events; ▪️kubectl describe / logs; ▪️диагностика CrashLoopBackOff и зависаний. Ссылка 👈 #kubernetes #devops 🧑‍💻 NetworkAdmin

Вот такое упражнение раз в полгода делай и системный блок всегда чистый будет #юмор 🧑‍💻 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

🎥 Вебинар: «От кода до Kubernetes за полтора часа» О чём поговорим: - Создание Docker-образа ASP.NET-приложения - Подготовка манифестов для Kubernetes - Разворачивание в кластере (minikube/microk8s/demo-кластер) - Настройка сервисов, ingress, переменных окружения - Практика с kubectl и манифестами - Ответы на вопросы в режиме live Что вы получите: - Пошаговый сценарий деплоя ASP.NET-приложения в Kubernetes; - Поймёте, как настроить сервисы, ingress и переменные окружения; - Освоите базовые команды для управления кластером; - Готовый шаблон манифестов и инструкцию для своих проектов. 👉 Для участия зарегистрируйтесь: https://otus.pw/ceHE/ 🎁 Все участники вебинара получат специальные условия на полное обучение курса «Инфраструктурная платформа на основе Kubernetes» Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

❗️ 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

👨‍💻 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

В России можно посещать IT-мероприятия хоть каждый день: как оффлайн, так и онлайн Но где их находить? Как узнавать о них раньше, чем когда все начнут выкладывать фотографии оттуда? Переходите на канал IT-Мероприятия России. В нём каждый день анонсируются мероприятия со всех городов России 📆 в канале размещаются как онлайн, так и оффлайн мероприятия; 👩‍💻 можно найти ивенты по любому стеку: программирование, frontend-backend разработка, кибербезопасность, дата-аналитика, osint, devops и другие; 🎙 разнообразные форматы мероприятий: митапы с коллегами по цеху, конференции и вебинары с известными опытными специалистами, форумы и олимпиады от важных представителей индустрии и многое другое А чтобы не искать по разным форумам и чатам новости о предстоящих ивентах: 🚀 IT-мероприятия России — подписывайся и будь в курсе всех предстоящих мероприятий!

💫 Быстрые откаты системы без 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

🚀 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 🔥 #реклама О рекламодателе

Просьба не завидовать 😎 #юмор 🧑‍💻 NetworkAdmin

📎 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