NetworkAdmin.ru

📷 Кто, когда и какой файл трогал Кто изменил файл? Кто трогал /etc/passwd, кто переписал конфиг, кто удалил файл, и когда это произошло. Если обычные логи тут не помогают, то на помощь идет auditd - подсистема аудита в linux, которая умеет фиксировать действия с файлами, процессами, системными вызовами и пользователями. Для админа это один из самых полезных инструментов, когда нужно не гадать, а точно увидеть факт доступа или изменения. ▪️ Что умеет auditd: отслеживать чтение, запись, удаление и изменение файлов; показывать, какой пользователь это сделал; фиксировать время события; сохранять, какой процесс выполнил действие; помогать в расследованиях "кто это сломал". ▪️ Установка обычно такая:

    
        
apt install auditd audispd-plugins{}
    

или:

    
        
yum install audit{}
    

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

    
        
systemctl enable --now auditd{}
    

Теперь самое полезное - можно поставить правило на конкретный файл или каталог. Например, хотим отслеживать изменения файла /etc/ssh/sshd_config:

    
        
auditctl -w /etc/ssh/sshd_config -p wa -k sshd_config_watch{}
    

-w - watch, следить за файлом -p wa - отслеживать запись (w) и изменение атрибутов (a) -k sshd_config_watch - удобный ключ для поиска событий После этого все изменения файла начнут попадать в audit log. Посмотреть события можно так:

    
        
ausearch -k sshd_config_watch{}
    

Если нужен более читаемый вывод:

    
        
ausearch -k sshd_config_watch -i{}
    

Здесь можно увидеть, например, что файл менял vim, sed, ansible, echo >>, или какой-нибудь скрипт деплоя. Если нужно следить не за одним файлом, а за каталогом:

    
        
auditctl -w /etc/nginx/ -p wa -k nginx_conf_watch{}
    

Теперь можно быстро искать все события по конфигам Nginx:

    
        
ausearch -k nginx_conf_watch -i{}
    

▪️ Еще полезный инструмент - aureport. Например, краткий отчет по событиям:

    
        
aureport -f -i{}
    

Он показывает сводку по файловым операциям. Здесь важно учесть: правила через auditctl обычно неперсистентны. То есть после перезагрузки они исчезнут. Чтобы сохранить их постоянно, добавляют правила в конфиг auditd, например:

    
        
/etc/audit/rules.d/audit.rules{}
    

или отдельным файлом в rules.d, например:

    
        
-w /etc/ssh/sshd_config -p wa -k sshd_config_watch
-w /etc/nginx/ -p wa -k nginx_conf_watch{}
    

А потом загружают правила:

    
        
augenrules --load{}
    

или перезапускают auditd. #linux #auditd 🧑‍💻 NetworkAdmin

Ну это база, когда дело дошло до настройки #юмор 🧑‍💻 NetworkAdmin

🆗 httpie: удобная замена curl для API curl знает почти каждый админ. Но как только нужно не просто дернуть URL, а нормально поработать с API, команды быстро превращаются в нечитаемую строку из флагов, кавычек и JSON в одну линию. В таких случаях очень выручает HTTPie - более удобный CLI-клиент для HTTP-запросов. Он не заменяет curl полностью, но для работы с REST API часто оказывается проще, нагляднее и быстрее. ▪️ Установка:

    
        
apt install httpie{}
    

или:

    
        
pip install httpie{}
    

▪️ Самый простой GET-запрос:

    
        
http GET https://api.netwrokadmin.ru/users{}
    

Можно даже короче:

    
        
http https://api.netwrokadmin.ru/users{}
    

Ответ HTTPie показывает в читаемом виде: статус заголовки JSON с форматированием Именно это делает его удобным при ручной диагностике API. ▪️ POST-запрос с JSON выглядит очень аккуратно:

    
        
http POST https://api.netwrokadmin.ru/users name=alice role=admin{}
    

HTTPie сам соберет JSON и выставит правильный Content-Type. Если нужен явный raw JSON:

    
        
http POST https://api.netwrokadmin.ru/users <<< '{"name":"alice","role":"admin"}'{}
    

▪️ Заголовки добавляются тоже проще, чем в curl:

    
        
http GET https://api.netwrokadmin.ru/users Authorization:"Bearer TOKEN"{}
    

▪️ Отправка файла:

    
        
http -f POST https://api.netwrokadmin.ru/upload file@backup.tar.gz{}
    

Для скриптов и старых automation-цепочек curl по-прежнему часто остается стандартом. А вот для ручной работы с API в терминале httpie обычно приятнее. #httpie #api 🧑‍💻 NetworkAdmin

⭐️ QoS в Linux Как только в linux заходит разговор про QoS, shaping и управление трафиком, у многих сразу одна реакция: tc - это боль, страдание и странные команды из 2009 года. И это недалеко от правды. Утилита мощная, но синтаксис у нее такой, будто она не хочет, чтобы ей пользовались. При этом tc - это стандартный инструмент linux для управления очередями, задержками, полосой и приоритетами трафика.

Что с его помощью обычно делают: ограничивают скорость; дают приоритет важному трафику; режут шумные сервисы; эмулируют плохую сеть: delay, loss, jitter; наводят порядок на WAN-линках и VPN.

Самое главное, что нужно понять: QoS в linux почти всегда про исходящий трафик (egress). Входящий поток контролировать сложнее, обычно его либо полируют через IFB, либо ограничивают уже на стороне отправителя. ▪️ Самый простой пример - ограничить скорость интерфейса до 50 Мбит/с:

    
        
tc qdisc add dev eth0 root tbf rate 50mbit burst 32kbit latency 400ms{}
    

tbf - Token Bucket Filter rate - лимит скорости burst - допустимый всплеск latency - максимальная задержка очереди ▪️ Удалить правило:

    
        
tc qdisc del dev eth0 root{}
    

Если нужен вариант без магии, для большинства случаев, чаще смотрят в сторону fq_codel или cake. Например:

    
        
tc qdisc add dev eth0 root fq_codel{}
    

fq_codel хорош тем, что помогает бороться с bufferbloat и в целом делает очередь более адекватной без сложной ручной настройки. ▪️ Если нужно не просто сделать лучше, а именно ограничить канал и при этом сохранить нормальную отзывчивость, часто используют cake:

    
        
tc qdisc add dev eth0 root cake bandwidth 100mbit{}
    

Почему tc кажется страшным: qdisc class filter parent handle flowid

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

    
        
tc qdisc add dev eth0 root netem delay 100ms{}
    

Или сделать "плохую" сеть с потерями:

    
        
tc qdisc add dev eth0 root netem delay 100ms loss 2%{}
    

Это уже очень полезно для тестирования приложений, API, VoIP, VPN и всего, что в локалке работает идеально, а в реальной сети нет. #tc #network 🧑‍💻 NetworkAdmin

🦖 ECMP: балансировка трафика на уровне маршрутизации Когда говорят о балансировке, то чаще вспоминают L4/L7-балансировщики. Но распределять трафик можно и ниже - прямо на уровне маршрутизации. Для этого существует ECMP - Equal-Cost Multi-Path. Суть простая: если до одной и той же сети есть несколько маршрутов с одинаковой метрикой, роутер может использовать их параллельно, а не держать один основным, а остальные про запас. Что это дает: распределение нагрузки между несколькими линками; лучшее использование полосы; отказоустойчивость - при падении одного пути трафик уходит в оставшиеся. Важный момент: ECMP обычно балансирует не каждый пакет как попало, а по хэшу потока. Например, учитываются source IP, destination IP, порты, протокол и весь конкретный flow идет по одному пути. Это нужно, чтобы не получить reordering пакетов и не сломать TCP-сессии. То есть два клиента могут уйти разными маршрутами, но один и тот же TCP-flow обычно будет идти стабильно по одному next-hop. 🤩 Где часто ошибаются: ▪️ думают, что ECMP всегда делит трафик идеально 50/50. На деле распределение зависит от числа flow и алгоритма хэширования. ▪️ путают ECMP с failover. ECMP - это не только резервирование, а именно одновременное использование нескольких равных путей. ▪️ забывают про asymmetry. В одну сторону трафик может пойти одним путем, в другую - другим. Для stateful-устройств это иногда становится проблемой. ECMP хорошо работает там, где сеть и маршрутизация изначально под это спроектированы. Если просто включить ради баланса, можно получить странное распределение, проблемы с firewall state tracking и сложную диагностику. #network #routing 🧑‍💻 NetworkAdmin

🎥 Вебинар: «Основы Kubernetes: архитектура и абстракции» О чём поговорим: - Ключевые компоненты Kubernetes: контейнеры, поды, ноды, сервисы и их взаимодействие. - Как в Kubernetes происходит развертывание и управление микросервисами. - Принципы масштабируемости, отказоустойчивости и безопасности в Kubernetes. - Реальные кейсы использования Kubernetes для DevOps и архитекторов. Что вы получите: - Фундаментальное понимание структуры Kubernetes и его ключевых абстракций. - Навыки работы с необычными объектами для развертывания и масштабирования приложений. - Практические знания, которые можно сразу применить в работе. 👉 Для участия зарегистрируйтесь: https://otus.pw/El79/ 🎁 Все участники вебинара получат специальные условия на полное обучение курса «Инфраструктурная платформа на основе Kubernetes» Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

Делая ремонт, не забудьте в инсталляцию добавить самое нужное #юмор 🧑‍💻 NetworkAdmin

📱 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