NetworkAdmin.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

😭 Как один 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

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

🤩 Как быстро проверить ширину канала через 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

Приглашаем на AMA-сессию 4.0 2026 год продолжает быть годом активного импортозамещения. В этот период особенно важно, чтобы производитель был максимально открыт к диалогу. Именно поэтому мы проводим открытую AMA-сессию 4.0 с генеральным директором vStack Евгением Карповым. Кому это будет особенно полезно: ➖ Системным администраторам ➖ Архитекторам ИТ-инфраструктуры ➖ ИТ-директорам ➖ Собственникам бизнеса ➖ Облачным провайдерам «Мы вступаем в 2026 год с пониманием, что российские продукты должны быть не просто альтернативой, а полноценными инструментами, которыми удобно пользоваться. Формат AMA позволит нам глубже понять потребности рынка и сориентировать развитие продукта в русле реальных запросов пользователей», — Евгений Карпов, генеральный директор vStack. Дата и время вебинара: 14 апреля в 13.00 Спикер: Евгений Карпов, генеральный директор vStack 🔗 Регистрация #реклама О рекламодателе

📱 Настройка 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

🔖 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

Вам на какой? Мне на 192.168.1.3 #юмор 🧑‍💻 NetworkAdmin

🔐 Хранение секретов внутри инфраструктуры Пароли в txt, доступы в вики - классика, которая рано или поздно заканчивается утечкой. Если инфраструктура растет, без централизованного менеджера секретов уже не обойтись. Один из самых практичных вариантов - Bitwarden или его легкая self-hosted реализация Vaultwarden. ▪️ Bitwarden vs Vaultwarden ▪️ Bitwarden Официальный продукт; Есть облачная версия; Есть self-hosted; Поддержка, enterprise-функции. ▪️ Vaultwarden Open-source реализация сервера Bitwarden; Легкий (часто запускается в одном Docker-контейнере); Минимальные требования; Полная совместимость с официальными клиентами. Для небольших и средних инфраструктур Vaultwarden часто идеальный вариант. ▪️ Что это дает инфраструктуре Централизованное хранение паролей Шифрование на стороне клиента (zero-knowledge) Разграничение доступа по организациям и коллекциям Поддержка 2FA Аудит доступа Можно хранить: SSH-пароли Учетки админов Доступы к сетевому оборудованию API-токены Пароли сервисных аккаунтов ▪️ Развертывание (минимальный пример)

docker run -d \
  --name vaultwarden \
  -v /vw-data:/data \
  -p 8080:80 \
  vaultwarden/server:latest

И все, дальше подключаемся через браузер или официальные клиенты Bitwarden. В продакшене, конечно: HTTPS через reverse proxy; регулярные бэкапы /data; ограничение доступа по сети; включенная админ-панель с отдельным токеном. #security #vaultwarden 🧑‍💻 NetworkAdmin

🏠 Бэкапы Windows Есть одно малоизвестное и бесплатное решение для резервного копирования Windows (включая серверные версии) - Hasleo Backup Suite Free, но при этом функциональность на уровне многих коммерческих продуктов. ▪️Что имеется в базе:

✅Резервное копирование всей системы, диска, раздела или отдельных файлов и папок ✅Клонирование системы и дисков ✅Типы бэкапов: полный, инкрементальный, дифференциальный ✅Расписание, политики хранения, автоочистка старых копий ✅Universal Restore (восстановление на другое железо) ✅Шифрование и проверка целостности бэкапов ✅Создание загрузочного носителя на базе WinPE ✅Подробное логирование

Функционально - все, что ожидаешь от нормального backup-решения. Без перегруза и маркетинговых фич ради фич. Русский перевод в целом аккуратный, без явных ляпов. Но есть нюанс: программа создает каталоги бэкапов на русском, например: Бэкап системы 20260330181411 И вот это уже спорный момент: кириллица + пробелы в именах директорий - не всегда хорошо Но в таком случае лучше использовать английскую версию интерфейса. ▪️ Тестирование 1️⃣Установил программу и сделал полный бэкап системы в сетевую папку; 2️⃣Создал загрузочный диск через интерфейс; 3️⃣Развернул чистую виртуальную машину; 4️⃣Загрузился с rescue-носителя, назначил IP, подключил сетевой ресурс; 5️⃣Восстановил систему из сетевого бэкапа. Все прошло удивительно гладко: быстро, без танцев с драйверами и неожиданными ошибками. Загрузочный носитель показался даже более удобным и шустрым. Если нужен бесплатный инструмент для резервного копирования рабочих станций или небольших серверов - это вполне рабочий вариант. #backup #windows 🧑‍💻 NetworkAdmin

💾 Бэкапы с шифрованием без боли Если вам нужен простой, быстрый и безопасный инструмент для резервного копирования без громоздких серверов и агентов, то обратите внимание на restic. Это современный backup-инструмент с встроенным шифрованием, дедупликацией и поддержкой десятков хранилищ.

Почему restic удобен Шифрование из коробки (AES-256); Дедупликация на уровне блоков; Инкрементальные бэкапы; Работа с локальными дисками, SFTP, S3, Backblaze, MinIO и др.; Один бинарник - без сервера и БД; И главное - максимально простой workflow.

▪️ Базовая настройка. Создаем репозиторий (например, в S3 или просто в каталоге):

restic init --repo /backup

Или через переменные окружения:

export RESTIC_REPOSITORY=/backup
export RESTIC_PASSWORD=StrongPassword

▪️ Создание бэкапа

restic backup /etc /var/www

restic автоматически: разобьет данные на чанки, зашифрует их, выполнит дедупликацию, сохранит снапшот. Каждый запуск - это новый снапшот, но без полного копирования данных. ▪️ Просмотр снапшотов

restic snapshots

Восстановление:

restic restore <snapshot_id> --target /restore

Можно восстанавливать отдельные файлы или каталоги. ▪️ Очистка старых бэкапов. Политики хранения настраиваются одной командой:

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Это безопасно удалит устаревшие данные с учетом дедупликации. ▪️ Практические советы Храните пароль вне сервера (например, в Vault или менеджер секретов); Используйте restic check для проверки целостности; Настройте cron + мониторинг exit-кодов; Тестируйте восстановление (бэкап без restore - это иллюзия безопасности). #backup #restic 🧑‍💻 NetworkAdmin

💚 Практика настройки SSHD: что имеет смысл проверить Служба SSH есть почти на каждом сервере: виртуальном или железном. Доступ по SSH - это основа администрирования. В идеале его стоит закрывать от публичной сети, но на практике это не всегда возможно. Основные параметры настраиваются в /etc/ssh/sshd_config. Ниже указаны моменты, на которые стоит обратить внимание. 1️⃣ Парольная аутентификация. Каждый решает сам:

PasswordAuthentication yes

Можно оставить ее включенной как резервный вариант. Если пароль сложный и несловарный - реального риска перебора нет. Но если отключить парольную аутентификацию, почти весь бот-скан исчезает из логов. 2️⃣ Аутентификация по ключам. По умолчанию включена:

PubkeyAuthentication yes

Лучше использовать ключи ed25519 - они короче, быстрее и безопаснее RSA в большинстве практических сценариев. 3️⃣ Доступ root. Разрешать или нет - зависит от модели работы:

PermitRootLogin no

Если вы администрируете сервер один - работа напрямую под root упрощает жизнь. Если команда, то лучше отдельные пользователи + sudo + аудит действий. Если сомневаетесь, лучше временно отключите вход root и работайте через sudo. 4️⃣ Ограничение пользователей и групп. Можно явно задать, кто имеет право подключаться:

AllowGroups sshgroup
AllowUsers user01 user02

Я чаще применяю это для SFTP-доступа, создавая отдельную группу под файловый обмен. 5️⃣ Порт. Стандарт - 22:

Port 22

Смена порта - это не защита, а лишь снижение шума. Боты все равно найдут сервис, особенно если порт открыт публично и индексируется сканерами. Но хуже от смены обычно не становится. 6️⃣ Количество попыток входа. Ограничиваем перебор в рамках одной сессии:

MaxAuthTries 3

Три неверных ввода - соединение рвется. 7️⃣ Количество сессий внутри подключения. Не путать с числом параллельных подключений:

MaxSessions 1

Для обычного администрирования одной сессии достаточно. 8️⃣ Принудительная команда и SFTP-изоляция. Можно запускать не shell, а конкретную команду, например, логирующую обертку или SFTP. Пример для группы sftpusers с chroot:

Subsystem sftp internal-sftp -u 002
Match User sftpusers
ChrootDirectory /var/www
ForceCommand internal-sftp -u 002

Пользователи группы будут ограничены SFTP-доступом к /var/www с umask 002. Главное - это осознанная настройка, а не конфиг по умолчанию. #linux #ssh 🧑‍💻 NetworkAdmin

Высокие технологии, они среди нас #юмор 🧑‍💻 NetworkAdmin

📱 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