NetworkAdmin.ru

Как понять, сколько памяти действительно использует процесс в Linux? Многие, особенно после Windows, теряются при анализе памяти в Linux. Диспетчер задач в Win наглядно показывает, сколько ОЗУ занято, сколько свободно - всё просто. В Linux же понимание, что и сколько потребляет, требует большего погружения. Разберемся на примере анализа потребления памяти процессом, например, nginx или php-fpm. 1️⃣ Находим PID процесса

    
        
ps ax | grep nginx{}
    

Допустим, PID мастер-процесса - 1947. 2️⃣ Используем pmap. Эта утилита показывает, какие участки памяти использует процесс и сколько они занимают. 📍 Виртуальная память (VIRT/VSZ):

    
        
pmap 1947 -p{}
    

Внизу увидим итоговое значение виртуальной памяти - все, включая разделяемые библиотеки и даже то, что может быть в swap. Для многопроцессных сервисов (как nginx) эта цифра будет одинаковой у всех дочерних процессов. Поэтому она мало информативна в отрыве от контекста. 📍 Резидентная память (RES/RSS):

    
        
pmap 1947 -x{}
    

Это объем оперативной памяти, реально занятой процессом (без учета swap). Но и тут не всё идеально - при наличии форков каждый из них покажет одинаковую RSS, хотя они могут разделять память. 📍 Приватная память:

    
        
pmap 1947 -d{}
    

А вот здесь интересно: writeable/private показывает именно ту часть памяти, которую процесс использует исключительно сам. Без общих библиотек и форков. Это значение важно при планировании числа одновременно работающих процессов (например, php-fpm). ❓ Как применять эти данные? Если планируешь запустить 50 PHP-процессов, и каждый из них использует ~30 МБ приватной памяти, нужно минимум 1.5 ГБ ОЗУ только под них. А ещё есть сама ОС, веб-сервер, БД и кэш - нужно считать с запасом, иначе словишь oom-killer. ❓ Где берёт данные pmap? Из /proc/<PID>/smaps, но pmap красиво их парсит. Хочешь больше деталей - загляни туда напрямую.

    
        
cat /proc/1947/smaps{}
    

Анализ потребления памяти в Linux - это не только top или htop. Используй pmap, чтобы понять реальное потребление и не попасть в просак при настройке сервисов. #linux #memory 🧑‍💻 NetworkAdmin

✨ Как работает LACP и зачем использовать агрегирование каналов Когда одного сетевого интерфейса мало - приходит время объединять их в «команду». Это называется агрегация каналов, и один из самых популярных способов реализовать ее - протокол LACP (Link Aggregation Control Protocol). LACP - часть стандарта IEEE 802.3ad. Он позволяет объединить несколько физических интерфейсов в один логический (LAG - Link Aggregation Group), который операционная система и приложения видят как один. 🌟 Зачем это нужно?

📍 Повышение пропускной способности; 📍 Повышение отказоустойчивости (если один порт отваливается - остальные продолжают работать); 📍 Балансировка нагрузки между портами.

🌟 Как это работает

📍 LACP автоматически обнаруживает, какие интерфейсы можно объединить 📍 Обе стороны (свитч и хост) договариваются, какие порты войдут в LAG 📍 Если кабель выпал или порт упал - он просто исключается из группы, ничего не рушится

▪️ Настройка в Linux. Пример для двух интерфейсов ens33 и ens34: 1️⃣ Устанавливаем ifenslave (если нужно):

    
        
sudo apt install ifenslave{}
    

2️⃣ Настраиваем bonding-мод LACP (mode 4): В /etc/network/interfaces или аналогичном конфиге:

    
        
auto bond0
iface bond0 inet static
  address 192.168.1.100
  netmask 255.255.255.0
  gateway 192.168.1.1
  bond-slaves ens33 ens34
  bond-mode 802.3ad
  bond-miimon 100
  bond-lacp-rate fast
  bond-xmit-hash-policy layer3+4{}
    

3️⃣ Важно! На свитче тоже нужно включить LACP на соответствующих портах (обычно называются channel-group или LAG в интерфейсе). ⭐️ Несколько нюансов:

📍 LACP работает только при поддержке с обеих сторон (сервер + свитч) 📍 LAG не удваивает скорость для одного TCP-соединения, но позволяет нескольким соединениям распределяться по разным каналам 📍 Лучше всего работает с хешированием по Layer3+4 (IP + порт)

#network #LACP 🧑‍💻 NetworkAdmin

🛡 Как корректно отслеживать и логировать выполнение Ansible-плейбуков Если вы регулярно работаете с Ansible - важно не только писать рабочие плейбуки, но и контролировать, когда, кем и как они были запущены. Особенно, если в вашей инфраструктуре Ansible используется как часть CI/CD или централизованного управления. 1️⃣ Включаем логирование в конфиге Ansible. В файле /etc/ansible/ansible.cfg (или в локальной копии ansible.cfg) пропишите:

    
        
[defaults]
log_path = /var/log/ansible.log{}
    

Ansible начнет писать все свои действия в указанный файл. Убедитесь, что у пользователя, запускающего Ansible, есть права на запись. 2️⃣ Используйте теги и переменные для понятности. Добавляйте теги к задачам:

    
        
- name: Установка nginx
  apt:
    name: nginx
    state: present
  tags:
    - web
    - nginx{}
    

Это поможет фильтровать задачи в логах, запускать только нужные части и документировать назначение. 3️⃣ Логируйте переменные, хосты, результаты. Для отладки - полезно писать значения переменных в лог:

    
        
- name: Показываем значение переменной
  debug:
    var: some_variable{}
    

Также можно логировать hostname, пользователя и дату запуска, добавляя кастомную задачу:

    
        
- name: Логируем запуск
  shell: echo "{{ ansible_date_time.iso8601 }}: {{ inventory_hostname }} - {{ ansible_user }}" >> /var/log/ansible_run.log{}
    

4️⃣ Используйте Ansible Callback Plugins. Для более глубокого логирования можно подключить callback-плагины. Например, json или yaml:

    
        
[defaults]
stdout_callback = yaml{}
    

А если хотите логировать в файл в формате JSON, можно использовать:

    
        
[defaults]
callback_whitelist = json
stdout_callback = json
log_path = /var/log/ansible-json.log{}
    

5️⃣ Храните вывод выполнения с ansible-playbook. При запуске:

    
        
ansible-playbook site.yml | tee -a /var/log/ansible-run-$(date +%F-%T).log{}
    

Так у вас будет отдельный лог под каждое выполнение. 6️⃣ Интеграция с CI/CD и мониторингом. Если Ansible запускается через GitLab, Jenkins, Drone и прочее - обязательно сохраняйте артефакты выполнения и возвращайте статус завершения. Также можно отправлять результаты выполнения в телегу через webhook после ansible-playbook. #ansible #security 🧑‍💻 NetworkAdmin

🤢 HDD или SSD? Как быстро определить тип диска в linux Если вы не уверены, установлен ли в вашем сервере SSD или классический жесткий диск, вот простой способ это проверить без сторонних утилит:

    
        
cat /sys/block/sda/queue/rotational
1

cat /sys/block/sde/queue/rotational
0{}
    

Значение 1 означает HDD (с вращающимся шпинделем), 0 - SSD (без вращения). 🌟 Как это работает? Это файловый интерфейс к параметрам устройств в Linux. Поле rotational говорит ядру, как обращаться с устройством: HDD - запросы стараются упорядочивать, чтобы сократить перемещения головки. SSD - доступ равномерный, очередь не критична. Поэтому для SSD оптимизация очереди часто не нужна - это влияет на планировщик ввода-вывода. ❓ А что в виртуалках? Виртуальные машины чаще всего по умолчанию видят виртуальные диски как HDD, даже если физический диск - SSD. Проверка rotational внутри VM может вернуть 1. Пример: Proxmox. Чтобы "объяснить" виртуалке, что она на SSD: 📍 В настройках диска активируйте опцию SSD Emulation. 📍 После этого значение rotational станет 0. Это не критично, но желательно - для корректной работы планировщика в гостевой ОС. ❓ Trim в VM: работает или нет? Появляется логичный вопрос: если включить SSD-эмуляцию, будет ли работать TRIM в виртуалке? Нет, сам по себе флаг SSD не включает поддержку TRIM. Чтобы TRIM работал в гостевой ОС: 📍 Виртуальный диск должен поддерживать discard. 📍 Должна быть включена поддержка в гипервизоре (например, в proxmox - флаг Discard). 📍 Гостевая ОС должна использовать файловую систему, поддерживающую TRIM (ext4, btrfs и т.д.) и выполнять его (например, через fstrim или discard в /etc/fstab). #linux #storage 🧑‍💻 NetworkAdmin

Неожиданно стал верующим человеком #юмор 🧑‍💻 NetworkAdmin

По мере того, как сети становятся сложнее и масштабнее, организации сталкиваются с растущими трудностями в поддержании точной, динамичной и безопасной сетевой инвентаризации. Устаревшие системы, гибридные инфраструктуры и развивающиеся угрозы безопасности усложняют решение таких задач. Готовые решения существуют, и, как всегда, есть различные “но”, вынуждающие либо идти на компромиссы или вложения дополнительных ресурсов, либо же раздувать штат соответствующих специалистов для увеличения охвата текущих задач по сетевой инфраструктуре. В первой части статьи мы рассказали о нашей идеологии в инструментарии для поддержки и конфигурирования сети. В этой части мы хотим детальнее рассказать о реализованных нами решениях по поднятым вопросам и размышлениям и поделиться результатами. Прочитать можно здесь:⬇️ https://dzen.ru/a/aJx4knpIYn5Ct87m

🐶 Фейковый root в linux: зачем он нужен и когда пригодится Наткнулся на утилиту с говорящим названием - fakeroot. Оказывается, она довольно старая и есть в стандартных репозиториях большинства дистрибутивов. Программа запускает окружение, в котором приложения думают, что работают с root-доступом. На самом деле вы остаетесь обычным пользователем, а fakeroot просто перехватывает системные вызовы (через LD_PRELOAD) и подменяет информацию. ▪️ Установка:

    
        
sudo apt install fakeroot{}
    

Запускаем:

    
        
fakeroot{}
    

В консоли появляется как будто бы root@host, и все поведение напоминает работу с sudo su. ▪️ Пример

    
        
touch test.txt
ls -la test.txt{}
    

Внутри fakeroot получите:

    
        
-rw-r--r-- 1 root root 0 ...{}
    

Выйдя из него:

    
        
-rw-r--r-- 1 username username 0 ...{}
    

То есть реально файл принадлежит обычному пользователю, но fakeroot создаёт иллюзию root-доступа. ❓ Зачем это вообще нужно? Основное назначение - создание архивов и пакетов, содержащих файлы от имени root, без необходимости работать под настоящим root. Например, вы собираете .deb-пакет с системными файлами или конфигами, которые в реальной установке должны принадлежать root. С помощью fakeroot вы можете задать нужные владельцы/права без прав суперпользователя. 🌟 Также будет полезно, если: 📍 Вы хотите пропустить ошибки доступа к файлам при архивации/копировании; 📍 Программа ругается на отсутствие root-доступа, но для вашей задачи это некритично; 📍 Вы работаете на CI/CD или в изолированном окружении без root-доступа #fakeroot #linux 🧑‍💻 NetworkAdmin

Не до всех доходит #юмор 🧑‍💻 NetworkAdmin

🚫 Блокировка стран по IP Если нужно ограничить доступ к сервису из определенных стран (например, через iptables или nginx), потребуется актуальный список IP-сетей по географии. Готовые списки можно взять отсюда. Например, список сетей России здесь Каждая строка - отдельная подсеть, удобно парсить скриптами. 🛠 Пример скрипта: создаем IP whitelist через ipset

    
        
#!/bin/bash

# Удаляем старый список (если был)
ipset destroy whitelist 2>/dev/null

# Создаем новый
ipset create whitelist hash:net

# Скачиваем нужные страны (пример: некоторые страны СНГ)
wget -O netwhite http://www.ipdeny.com/ipblocks/data/countries/{ru,kz,by,uz,kg,am,az,ge,tj}.zone

# Добавляем подсети в ipset
for ipnet in $(cat netwhite); do
    ipset add whitelist $ipnet
done

# Проверка
ipset save whitelist > whitelist-export.txt
echo "IP-сети загружены в ipset"{}
    

Теперь подключаем список к iptables:

    
        
iptables -A INPUT -m set --match-set whitelist src -p tcp --dport 80 -j ACCEPT{}
    

⚠️ Важно: если сетей больше ~2000, не загружайте их напрямую в iptables - используйте ipset, иначе правила займут много памяти и ресурсов. ▪️ Альтернатива - готовые конфиги под разные сервисы Сервис: https://www.ip2location.com/free/visitor-blocker Можно сразу получить правила под apache, nginx, iptables, mikrotik и другие. #iptables #ipset 🧑‍💻 NetworkAdmin

📄 Разделение логов по уровням и сервисам с systemd-journald Если вы работаете на современном дистрибутиве linux, то почти наверняка используете systemd, а значит - и journald для сбора логов. Это система логирования, которая умеет куда больше, чем просто показывать логи командой journalctl. Сегодня - о том, как удобно фильтровать и разделять логи по уровню важности (info, warning, error и т.д.) и сервисам, чтобы быстро находить нужную информацию. ▪️ Фильтрация логов по юниту. Чтобы посмотреть логи конкретного сервиса:

    
        
journalctl -u nginx.service{}
    

Добавьте -b для вывода только с текущей загрузки:

    
        
journalctl -u ssh.service -b{}
    

▪️ Логи по уровню важности. Вы можете указать минимальный уровень важности:

    
        
journalctl -p err  # Только ошибки и критичнее{}
    

Список уровней (от менее к более важным):

0: emerg 1: alert 2: crit 3: err 4: warning 5: notice 6: info 7: debug

Пример: показать все warning и выше от sshd:

    
        
journalctl -u ssh.service -p warning{}
    

▪️ Ограничение по времени. Чтобы не утонуть в огромных логах:

    
        
journalctl --since "1 hour ago"
journalctl --since "2025-09-18" --until "2025-09-19 03:00"{}
    

▪️ Разделение логов по каталогам. По умолчанию journald пишет в /run/log/journal (в RAM), если /var/log/journal отсутствует. Чтобы сохранять логи между перезагрузками:

    
        
mkdir -p /var/log/journal
systemd-tmpfiles --create --prefix /var/log/journal
systemctl restart systemd-journald{}
    

▪️ Настройка persist-логирования и лимитов. В файле /etc/systemd/journald.conf можно настроить:

    
        
Storage=persistent
SystemMaxUse=500M
RuntimeMaxUse=100M
MaxRetentionSec=7day{}
    

После правок - перезапустите journald:

    
        
systemctl restart systemd-journald{}
    

▪️ Глубокие фильтры. Вывести только ошибки от ядра:

    
        
journalctl _TRANSPORT=kernel -p err{}
    

Фильтр по PID:

    
        
journalctl _PID=1234{}
    

По имени бинарника:

    
        
journalctl _COMM=nginx{}
    

#logs #systemd 🧑‍💻 NetworkAdmin