🤩 Как грепнуть вывод, который "не грепается"

Иногда команда что-то выводит в терминал, но обычный grep внезапно ничего не находит.

Хороший пример - проверка модулей Nginx:

nginx -V

На экране получаем длинную строку с параметрами сборки. Пробуем найти нужный модуль:

nginx -V | grep http_realip_module

И получаем пустой результат.

Причина в том, что nginx -V пишет вывод не в stdout, а в stderr. А пайп | по умолчанию передает дальше только stdout. Решение:

nginx -V 2>&1 | grep http_realip_module

Конструкция:

2>&1

перенаправляет stderr в stdout, после чего вывод уже можно нормально передавать в grep, awk, sed и другие утилиты.

Но есть еще один нюанс: параметры nginx -V обычно идут одной длинной строкой. Чтобы сделать вывод более читаемым, можно разбить его по пробелам:

nginx -V 2>&1 | tr ' ' '\n' | grep http_realip_module

Получим:

--with-http_realip_module

2>&1 - объединяем stderr и stdout
tr ' ' '\n' - заменяем пробелы переносами строк
grep - ищем нужный параметр

Тот же прием полезен не только с Nginx. Например:

command 2>&1 | grep error

Если не уверены, куда именно программа пишет данные, это хороший первый тест.

Посмотреть потоки отдельно тоже можно:

command >stdout.log 2>stderr.log

#bash #grep

🧑‍💻 NetworkAdmin

Читать полностью…

❌ UAC в Windows Server: почему админ не всегда "полный админ"

В Windows Server можно войти под учеткой из группы Administrators и все равно получить: Access denied. Это не баг. Чаще всего причина - UAC.

После входа администратор обычно получает два security token:

• обычный, с урезанными правами
• elevated, с полными административными правами

Поэтому PowerShell или CMD, запущенные обычным способом, могут работать не так, как ожидается.

▪️ Проверить, входит ли пользователь в локальные администраторы:

whoami /groups

Но наличие группы Administrators еще не означает, что текущий процесс уже elevated.

▪️ Быстрая проверка PowerShell:

$principal = New-Object Security.Principal.WindowsPrincipal(
    [Security.Principal.WindowsIdentity]::GetCurrent()
)

$principal.IsInRole(
    [Security.Principal.WindowsBuiltInRole]::Administrator
)

Если вернулось:

False

текущий PowerShell работает без elevation.

▪️ Запустить elevated-консоль можно через:

Start-Process powershell.exe -Verb RunAs

После подтверждения UAC откроется новый процесс уже с повышенными правами.

▪️ Еще одна типичная ситуация - удаленное администрирование. Локальная админская учетная запись при подключении по сети может получить отфильтрованный token из-за Remote UAC. Поэтому команда локально работает, а через удаленный вызов — Access denied.

#windowsserver #uac

🧑‍💻 NetworkAdmin

Читать полностью…

🔍 Как посмотреть environment-переменные запущенного процесса

Иногда во время диагностики нужно понять, в каком окружении реально запущено приложение. Например:

• какой PATH оно видит
• какой HOME используется
• под каким пользователем работает
• какие переменные передал systemd
• какой config-файл или endpoint попал в environment

▪️ Почти вся информация о процессе в linux доступна через:

/proc/<PID>/

▪️ Окружение процесса хранится здесь:

/proc/<PID>/environ

Например:

cat /proc/1427/environ

Но вывод выглядит примерно так:

LANG=en_US.UTF-8PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/binHOME=/var/lib/prometheusUSER=prometheus...

Причина в том, что переменные в /proc/<PID>/environ разделены не переносами строк, а символом NUL. Поэтому читать такой вывод неудобно.

▪️ Один из простых вариантов - использовать xargs:

xargs -0 -n1 < /proc/1427/environ

Получим уже нормальный список:

LANG=en_US.UTF-8
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin
HOME=/var/lib/prometheus
USER=prometheus
LOGNAME=prometheus
SHELL=/usr/sbin/nologin

То же самое можно сделать через tr:

tr '\0' '\n' < /proc/1427/environ

Если нужен конкретный параметр:

tr '\0' '\n' < /proc/1427/environ | grep '^PATH='

▪️ PID процесса можно быстро найти так:

pgrep -a prometheus

или:

systemctl show prometheus -p MainPID

Еще один вариант:

ps eww -p 1427

Он тоже покажет environment, но для большого количества переменных вывод обычно получается менее читаемым.

#proc #environment

🧑‍💻 NetworkAdmin

Читать полностью…

🪄 Почему просто пробросить порт иногда не работает

Классическая задача: есть сервер за NAT, нужно открыть наружу его сервис. Делаем DNAT:

iptables -t nat -A PREROUTING \
  -p tcp --dport 8443 \
  -j DNAT --to-destination 10.20.0.15:443

И кажется, что все готово. Но клиент подключиться не может. Проблема в том, что NAT в linux тесно связан с conntrack - механизмом отслеживания состояний соединений.

Ядро запоминает:

клиент → внешний IP:8443
              ↓ DNAT
          10.20.0.15:443

И ожидает, что обратный трафик пройдет через тот же NAT-хост.

Если бэкенд отвечает клиенту через другой gateway, получаем асимметричную маршрутизацию:

Client → NAT → Backend
Client ←────── Backend

Клиент отправлял запрос одному адресу, а ответ пришел другим путем. TCP-сессия ломается.

Поэтому вместе с DNAT часто требуется SNAT/MASQUERADE:

iptables -t nat -A POSTROUTING \
  -d 10.20.0.15 \
  -p tcp --dport 443 \
  -j MASQUERADE

Теперь бэкенд отвечает NAT-серверу, а тот корректно выполняет обратную трансляцию.

▪️ Посмотреть состояния conntrack:

conntrack -L

▪️ Отфильтровать нужный порт:

conntrack -L -p tcp --dport 443

▪️ Статистика:

conntrack -S

▪️ Еще одна распространенная проблема - таблица conntrack переполнена. Проверяем:

sysctl net.netfilter.nf_conntrack_max
cat /proc/sys/net/netfilter/nf_conntrack_count

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

nf_conntrack: table full, dropping packet

Диагностику проброса порта удобно начинать с tcpdump:

tcpdump -i any -nn port 8443 or port 443

Если SYN приходит на внешний интерфейс, но не уходит к бэкенду - смотрим NAT/firewall. Если уходит, но ответа нет - проверяем бэкенд и его маршрутизацию. Если SYN-ACK возвращается, но клиент его не получает - смотрим обратный NAT и conntrack.

#network #conntrack

🧑‍💻 NetworkAdmin

Читать полностью…

✨ Systemd-команды, которые быстро дают информацию о системе

У systemd есть несколько команд, которыми удобно пользоваться почти на любом современном linux-дистрибутиве. Плюс в том, что интерфейс везде примерно одинаковый: ubuntu, debian, rocky и другие системы.

1️⃣ hostnamectl - что это вообще за сервер

Одна из самых полезных команд:

hostnamectl

Например, на ubuntu server вывод может выглядеть так:

 Static hostname: app-prod-02
       Icon name: computer-vm
         Chassis: vm
      Machine ID: 97e42f42c9da49e39a8c0fcb45a2d772
         Boot ID: 8aa12e8be6874464a2ec83c070bdcc76
  Virtualization: kvm
Operating System: Ubuntu 24.04.2 LTS
          Kernel: Linux 6.8.0-60-generic
    Architecture: x86-64
 Hardware Vendor: QEMU
  Hardware Model: Standard PC

Сразу видно:

hostname
дистрибутив
версию ядра
архитектуру
виртуализацию
производителя виртуального железа

То есть одной командой можно быстро понять, куда вообще подключился: VM это, железо или другая среда. Во многих случаях hostnamectl заменяет несколько отдельных команд:

uname -a
cat /etc/os-release
lsb_release -a

2️⃣ timedatectl - время, timezone и синхронизация

timedatectl

Пример:

Local time: Mon 2026-09-17 11:38:42 CEST
Universal time: Mon 2026-09-17 09:38:42 UTC
RTC time: Mon 2026-09-17 09:38:42
Time zone: Europe/Berlin (CEST, +0200)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no

Полезно, когда нужно сразу проверить:

локальное время
UTC
timezone
работает ли синхронизация
в каком режиме RTC

Если нужно просто посмотреть текущую дату и время:

date

Но для диагностики NTP удобнее именно timedatectl.

3️⃣ loginctl - кто подключен и что делает

Без параметров:

loginctl

показывает активные пользовательские сессии.

Например:

SESSION  UID USER   SEAT  LEADER CLASS   TTY  IDLE
      3 1001 admin  -     1842   user    pts/0 no

А подробности можно получить так:

loginctl session-status 3

Пример:

3 - admin (1001)
           Since: Mon 2026-09-17 11:20:15 CEST; 18min ago
          Leader: 1842 (sshd)
          Remote: 10.40.12.27
         Service: sshd; type tty; class user
           State: active
            Unit: session-3.scope
                  ├─1842 "sshd: admin@pts/0"
                  ├─1850 -bash
                  └─2141 loginctl session-status 3

Здесь уже видно:

когда подключился пользователь
откуда пришел SSH
PID сессии
какие процессы внутри нее запущены

Для быстрой проверки пользователей я чаще использовал бы:

w
who
id

Но loginctl полезен, когда нужны именно детали systemd-сессии.

4️⃣ journalctl - системные логи

Одна из основных команд:

journalctl

Чаще всего полезны варианты:

journalctl -b
journalctl -u nginx
journalctl -p err
journalctl -f

То есть:

логи текущей загрузки
логи конкретного сервиса
только ошибки
просмотр в реальном времени

5️⃣ localectl - locale и раскладка

localectl

Покажет системную locale и настройки клавиатуры.

Например:

System Locale: LANG=en_US.UTF-8
    VC Keymap: (unset)
   X11 Layout: us

Для обычной проверки переменных окружения часто достаточно:

locale

Но localectl удобен именно как systemd-интерфейс для системных настроек locale.

#linux #systemd

🧑‍💻 NetworkAdmin

Читать полностью…

🥱 Как быстро разобраться с дисками и маунтами

Когда на сервере несколько дисков, LVM, отдельные разделы и сетевые маунты, быстро понять "что куда примонтировано" бывает не так просто. Для базовой диагностики хватает трех команд:

1️⃣ lsblk - структура дисков

lsblk

Покажет диски, разделы, LVM и точки монтирования.

Более полезный вариант:

lsblk -f

Здесь дополнительно видны:

файловая система;
UUID;
label;
mount point

Например:

sda
├─sda1 ext4   /boot
└─sda2 LVM2_member
  ├─vg-root ext4 /
  └─vg-data xfs  /data

Если нужно увидеть размеры и тип устройств:

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS

2️⃣ blkid - UUID и тип файловой системы

blkid

Полезно, когда нужно проверить запись в /etc/fstab.

Например:

/dev/sdb1: UUID="a1b2-c3d4" TYPE="ext4"

После этого можно использовать UUID вместо /dev/sdb1:

UUID=a1b2-c3d4 /backup ext4 defaults 0 2

Это надежнее, потому что имя устройства после перезагрузки теоретически может измениться.

3️⃣ findmnt - что реально примонтировано

findmnt

Показывает дерево текущих маунтов.

Для конкретного каталога:

findmnt /data

Очень удобно, когда непонятно, на какой файловой системе лежит путь:

findmnt -T /var/lib/myapp/data/file.db

Команда покажет mount point, устройство и тип файловой системы, которые реально обслуживают этот файл.

Посмотреть только ext4:

findmnt -t ext4

Проверить /etc/fstab:

findmnt --verify

У каждой команды своя задача:

lsblk - какие блочные устройства есть и как они связаны
blkid - UUID, LABEL и тип файловой системы
findmnt - что и куда реально примонтировано

#storage #filesystem

🧑‍💻 NetworkAdmin

Читать полностью…

🤩 Как расшифровать код ошибки Windows через certutil

При установке обновлений Windows рано или поздно встречаются ошибки вида:

0x80070422

По одному шестнадцатеричному коду не всегда понятно, что именно произошло. Но в Windows есть встроенная утилита, которая умеет переводить многие системные коды ошибок в нормальное текстовое описание - certutil.exe. Например:

certutil -error 0x80070422

В ответ получим примерно следующее:

ERROR_SERVICE_DISABLED
The service cannot be started, either because it is disabled or because it has no enabled devices associated with it.

То есть вместо непонятного:

0x80070422

мы сразу получаем подсказку: служба отключена и не может быть запущена.

Дальше уже можно искать проблему предметно. Например, проверить службы Windows Update:

Get-Service wuauserv,bits,cryptsvc

И посмотреть их состояние:

Get-Service wuauserv | Select-Object Name,Status,StartType

certutil -error полезен не только для Windows Update. Команда помогает расшифровывать различные HRESULT, Win32 и системные коды ошибок, которые встречаются в:

Event Viewer
PowerShell
установщиках
службах Windows
DISM
сетевых компонентах
сертификатах и криптографии

Например:

certutil -error 0x80070005

вернет:

E_ACCESSDENIED
Access is denied.

А это уже намного полезнее для диагностики, чем просто код.

#windows #troubleshooting

🧑‍💻 NetworkAdmin

Читать полностью…

🌚 watch: простая динамическая диагностика в терминале

Иногда не нужен отдельный мониторинг, графики и дашборд. Нужно просто увидеть, как меняется состояние системы прямо сейчас. Для этого в линукс есть простая команда watch. Она периодически запускает другую команду и обновляет вывод в терминале.

Например, смотреть свободное место:

watch df -h

По умолчанию команда выполняется каждые 2 секунды.

▪️ Изменить интервал:

watch -n 1 df -h

Теперь обновление идет раз в секунду.

▪️ Полезный режим - подсветка изменений:

watch -d free -h

watch выделит строки и значения, которые изменились между обновлениями.

▪️ Где это удобно:

cмотреть рост файловой системы

watch -n 1 'du -sh /var/log'

следить за памятью

watch -n 1 free -h

наблюдать TCP-соединения

watch -n 1 'ss -s'

проверять очередь systemd-задач

watch -n 1 'systemctl --failed'

следить за конкретным процессом

watch -n 1 'ps -p 1234 -o pid,%cpu,%mem,etime,cmd'

смотреть состояние RAID

watch -n 1 cat /proc/mdstat

наблюдать число файлов в каталоге

watch -n 1 'find /data/incoming -type f | wc -l'

▪️ Иногда удобно скрыть заголовок watch:

watch -t 'ss -s'

▪️ А если команда использует pipe, redirect или несколько операций, лучше брать ее в кавычки:

watch -n 1 'ps aux | sort -rk 3 | head'

#linux #watch

🧑‍💻 NetworkAdmin

Читать полностью…

🖥 Windows зависла на "Подготовке Windows": как проверить состояние удаленно

Типичная ситуация: после установки обновлений, компонентов или серверных ролей отправляем Windows в перезагрузку и видим сообщение:

Выполняется подготовка Windows.
Не выключайте компьютер.

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

Локально войти в систему на этом этапе нельзя, однако иногда удаленные службы уже доступны. Подключиться к консоли можно через PsExec:

PsExec.exe \\192.168.158.10 -u localadmin powershell.exe

Если нужно запустить процесс в интерактивной сессии:

PsExec.exe \\192.168.158.10 -i 1 -u localadmin powershell.exe

В открывшейся консоли первым делом стоит проверить свободное место:

Get-Volume

Посмотреть процессы с высокой нагрузкой:

Get-Process |
Sort-Object CPU -Descending |
Select-Object -First 15 Name, Id, CPU

И найти службы, зависшие в переходном состоянии:

Get-CimInstance Win32_Service |
Where-Object State -eq "Stop Pending" |
Select-Object Name, DisplayName, ProcessId, State

Часто во время обновлений в списке встречается служба установщика модулей Windows:

TrustedInstaller

Перед завершением процесса желательно проверить журналы и убедиться, что установка действительно не продвигается:

Get-Content C:\Windows\Logs\CBS\CBS.log -Tail 50

Принудительное завершение процесса - крайняя мера:

taskkill /PID <ProcessId> /F

После этого система может продолжить выключение или выполнить откат незавершенных изменений.

Когда Windows загрузится, стоит проверить хранилище компонентов и системные файлы:

DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow

Дополнительно проверьте результат установки обновлений:

Get-WinEvent -FilterHashtable @{
    LogName = "System"
    StartTime = (Get-Date).AddHours(-6)
} |
Where-Object Message -match "update|servicing|TrustedInstaller" |
Select-Object TimeCreated, Id, LevelDisplayName, Message

#windows #psexec

🧑‍💻 NetworkAdmin

Читать полностью…

😐

#юмор

🧑‍💻 NetworkAdmin

Читать полностью…

👁 Linux audit rules: минимальный набор для контроля критичных файлов

Обычные логи не всегда отвечают на главный вопрос: кто изменил конфигурацию и какой процесс это сделал? Для таких задач в Linux есть auditd. Он фиксирует обращения к файлам на уровне ядра и сохраняет пользователя, процесс, команду и время события.

▪️ Установка:

apt install auditd audispd-plugins
systemctl enable --now auditd

Правила лучше хранить в отдельном файле:

nano /etc/audit/rules.d/critical-files.rules

▪️ Минимальный набор:

-w /etc/passwd -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/gshadow -p wa -k identity

-w /etc/sudoers -p wa -k sudoers
-w /etc/sudoers.d/ -p wa -k sudoers

-w /etc/ssh/sshd_config -p wa -k ssh_config
-w /root/.ssh/ -p wa -k ssh_keys

-w /etc/systemd/system/ -p wa -k systemd_units
-w /etc/cron.d/ -p wa -k cron_changes
-w /etc/crontab -p wa -k cron_changes

-w /etc/audit/ -p wa -k audit_config

-w - файл или каталог для наблюдения
-p w - запись в файл
-p a - изменение атрибутов и прав
-k - удобная метка для поиска

▪️ Загружаем правила:

augenrules --load

▪️ Проверяем:

auditctl -l

▪️ Примеры использования:

Ищем изменения, например, SSH-конфига:

ausearch -k ssh_config -i

Посмотреть события за сегодня:

ausearch -k sudoers -ts today -i

Краткий отчет по измененным файлам:

aureport -f -i

▪️ В событии можно увидеть:

какой файл изменили
UID и реального пользователя
PID процесса
исполняемую команду
успешность операции
точное время

#linux #auditd

🧑‍💻 NetworkAdmin

Читать полностью…

Вы не заставите меня их закрыть. 🤩

#юмор

🧑‍💻 NetworkAdmin

Читать полностью…

💚 Как один неверный chmod -R ломает прод сильнее, чем падение сервиса

Падение сервиса обычно видно сразу. Мониторинг красный, пользователи жалуются, в логах ошибка. Перезапустили, откатили, восстановили. А вот один неверный chmod -R может сломать прод намного тише и неприятнее. Классический сценарий:

chmod -R 777 /var/www

или еще хуже:

chmod -R 755 /

Хотели быстро пофиксить права, а получили хаос.

▪️ Почему это опасно?

Права в linux - это не просто можно читать или нельзя.
От них зависит работа сервисов, безопасность, SSH, sudo, systemd, базы данных, веб-приложения и приватные ключи.

▪️ Что может сломаться:

• SSH перестанет принимать ключи, потому что ~/.ssh и authorized_keys стали слишком открытыми
• приватные ключи начнут считаться небезопасными
• nginx/apache потеряют доступ к нужным файлам или, наоборот, получат лишний доступ
• база данных откажется стартовать из-за неправильных прав на data directory
• sudo может начать ругаться на права конфигов
• приложения начнут писать туда, куда не должны
• исполняемые файлы потеряют нужные биты

▪️ Особенно опасны рекурсивные команды с переменными:

chmod -R 755 "$DIR"

Если $DIR пустой, неправильный или подставился не тот путь - последствия могут быть очень неприятными.

Перед такими командами лучше явно проверять переменные:

: "${DIR:?DIR is empty}"

И сначала смотреть, куда команда попадет:

find "$DIR" -maxdepth 2 -print

Для файлов и директорий права часто должны отличаться.

🤩 Плохо:

chmod -R 755 /var/www/app

🤩 Лучше:

find /var/www/app -type d -exec chmod 755 {} +
find /var/www/app -type f -exec chmod 644 {} +

Так директории остаются проходимыми, а обычные файлы не становятся исполняемыми без необходимости.

▪️ Если нужно дать права конкретному пользователю, часто правильнее менять владельца:

chown -R www-data:www-data /var/www/app/storage

А не открывать все через 777.
777 - это почти всегда сигнал, что проблему не поняли, а просто выключили защиту.

Для диагностики полезно смотреть текущие права:

ls -la
namei -l /var/www/app/storage/file.log
stat /var/www/app/storage

namei -l особенно удобен: он показывает права на каждом уровне пути.
Иногда файл доступен, но один из родительских каталогов не дает пройти дальше.

#linux #chmod

🧑‍💻 NetworkAdmin

Читать полностью…

🤩 Почему места достаточно, но приложение всё равно не может записать файл

Иногда на сервере возникает странная ситуация. Проверяем диск:

df -h

Свободное место есть. Например, десятки гигабайт. Но приложение всё равно пишет: No space left on device

▪️ Первая частая причина - закончились inodes. inode - это запись о файле в файловой системе. Если маленьких файлов очень много, можно упереться не в объем, а в количество файлов. Проверить:

df -i

Если IUse% близко к 100%, новые файлы создаваться не будут, даже если свободные гигабайты еще есть. Типичные виновники: миллионы мелких cache-файлов, сессии приложения, временные файлы, мелкие логи и т.д. Найти каталоги с большим количеством файлов:

find /var -xdev -type f | cut -d/ -f1-3 | sort | uniq -c | sort -nr | head

▪️ Вторая причина - квоты. Для пользователя или группы может быть ограничение, хотя на файловой системе место есть. Проверить:

quota -s

или для XFS:

xfs_quota -x -c 'report -h' /mountpoint

▪️ Третья причина - приложение пишет не туда, куда вы смотрите. Например, вы проверяете /data, а сервис пишет в /var/lib/app, /tmp или внутрь контейнера. Полезно посмотреть mount point:

df -h /path/to/file

И понять, какая файловая система реально используется.

▪️ Четвертая причина - лимиты systemd. У сервиса могут быть ограничения через unit:

systemctl cat myapp.service
systemctl show myapp.service | grep -i limit

▪️ Пятая причина - read-only файловая система. Например, после ошибок диска система могла перемонтировать раздел в ro. Проверить:

findmnt -o TARGET,OPTIONS

или:

mount | grep ' ro,'

#linux #filesystem #storage

🧑‍💻 NetworkAdmin

Читать полностью…

✏️ Пишем события скриптов в Windows Event Viewer

В Windows-скриптах часто делают логирование в обычные текстовые файлы:

C:\Scripts\Logs\script.log

Это рабочий вариант, но не всегда удобный. Логи могут лежать в разных папках, забываться при переносе скрипта, не попадать в централизованный сбор и быстро превращаться в зоопарк форматов. Иногда удобнее писать важные события прямо в Event Viewer.

▪️ Плюсы такого подхода:

• события видны в стандартном журнале Windows;
• их можно собирать через WEF, SIEM или агент мониторинга;
• проще фильтровать по источнику, Event ID и уровню;
• не нужно отдельно искать лог-файл скрипта;
• события попадают в привычный механизм аудита и диагностики.

▪️ Например, в PowerShell можно создать отдельный источник событий:

New-EventLog -LogName Application -Source "MyScript"
После этого можно писать события в журнал Application:
Write-EventLog `
  -LogName Application `
  -Source "MyScript" `
  -EntryType Information `
  -EventID 1 `
  -Message "Запущен PowerShell-скрипт опроса состояния сервера"

В Event Viewer появится событие с источником MyScript.

Тип события можно менять:

-EntryType Information
-EntryType Warning
-EntryType Error

Например, если скрипт завершился с ошибкой:

Write-EventLog `
  -LogName Application `
  -Source "MyScript" `
  -EntryType Error `
  -EventID 1001 `
  -Message "Скрипт завершился с ошибкой при подключении к серверу"

▪️ Можно использовать свою схему Event ID:

1 - старт скрипта
2 - успешное завершение
100 - предупреждение
1001 - ошибка подключения
1002 - ошибка доступа

Так потом проще строить фильтры и алерты.

▪️ Если не хочется смешивать события с общим Application, можно создать отдельный журнал:

New-EventLog -LogName CustomPSLog -Source "PS1Script"

И писать уже туда:

Write-EventLog `
  -LogName CustomPSLog `
  -Source "PS1Script" `
  -EntryType Information `
  -EventID 1 `
  -Message "PowerShell script started"

▪️ Для BAT/CMD-скриптов тоже есть вариант - команда eventcreate:

eventcreate /t information /l application /id 1 /d "BAT script started"

Для ошибки:

eventcreate /t error /l application /id 1001 /d "BAT script failed"

Event Viewer удобен не вместо всех логов, а как место для важных событий, которые должны быть видны системе мониторинга и администратору. Если скрипт делает что-то важное, он должен не просто молча выполниться. Он должен оставить понятный след: когда стартовал, чем закончился и где сломался.

#windows #powershell #eventviewer

🧑‍💻 NetworkAdmin

Читать полностью…

💚 Test-NetConnection: удобная диагностика сети в Windows без telnet

В PowerShell есть встроенная команда Test-NetConnection, которую удобно использовать для быстрой сетевой диагностики. У нее есть короткий alias:

tnc

1️⃣ Быстрая проверка сетевого подключения. Можно запустить просто:

tnc

PowerShell выполнит стандартную сетевую проверку и покажет полезную информацию:

ComputerName           : internetbeacon.msedge.net
RemoteAddress          : 13.107.4.52
InterfaceAlias         : Ethernet
SourceAddress          : 192.168.50.24
PingSucceeded          : True
PingReplyDetails (RTT) : 28 ms

Сразу видно:

• какой интерфейс используется
• локальный IP
• удаленный IP
• проходит ли ICMP
• RTT

Это особенно удобно на ноутбуках и рабочих станциях, где одновременно могут быть активны Ethernet, Wi-Fi, VPN и несколько виртуальных адаптеров.

2️⃣ Проверка TCP-порта. Один из самых полезных сценариев:

tnc app01.pc_02.local -Port 443

Пример результата:

ComputerName     : app01.pc_02.local
RemoteAddress    : 10.30.10.15
RemotePort       : 443
InterfaceAlias   : Ethernet
SourceAddress    : 192.168.50.24
TcpTestSucceeded : True

Если:

TcpTestSucceeded : True

TCP-соединение до указанного порта устанавливается. Если False - дальше уже проверяем firewall, маршрут, NAT и слушает ли сервис порт.

По сути, для обычной проверки доступности TCP это удобная замена telnet. Не нужно отдельно устанавливать Telnet Client и потом выходить из открытого соединения.

3️⃣ Трассировка маршрута

tnc 8.8.8.8 -TraceRoute

Полезно, когда нужно быстро посмотреть путь до узла без отдельного tracert. Есть и подробный режим:

tnc db01.networkadmin.local -Port 5432 -InformationLevel Detailed

А если нужен только результат проверки:

tnc db01.networkadmin.local -Port 5432 -InformationLevel Quiet

Получим просто: True

Это удобно и в скриптах:

if (tnc db01.networkadmin.local -Port 5432 -InformationLevel Quiet) {
    "PostgreSQL доступен"
}

#windows #network

🧑‍💻 NetworkAdmin

Читать полностью…

🦖 GNU parallel: когда xargs уже мало для массовых задач

Для простого параллельного запуска часто хватает xargs:

cat hosts.txt | xargs -n1 -P4 ping -c 1

Но когда задача становится сложнее - несколько аргументов, логирование, сохранение порядка вывода, запуск на удаленных хостах - удобнее использовать GNU parallel.

▪️ Установка:

apt install parallel

▪️ Базовый пример:

parallel -j 4 ping -c 1 ::: 10.20.0.11 10.20.0.12 10.20.0.13

-j 4 означает, что одновременно выполнять максимум 4 задания.

Если список лежит в файле:

parallel -j 8 'curl -fsS http://{}/health' :::: hosts.txt

Здесь {} заменяется текущей строкой из входных данных.

Можно удобно работать с именами файлов:

find /var/log -name '*.gz' -print0 |
parallel -0 -j 4 'gzip -t {}'

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

▪️ Одна из полезных возможностей - сохранить порядок вывода:

parallel -k -j 4 'echo START {}; sleep 2; echo DONE {}' ::: srv1 srv2 srv3

Без -k результаты будут появляться по мере завершения задач.

▪️ Для контроля ошибок:

parallel --halt soon,fail=1 -j 4 './deploy.sh {}' :::: hosts.txt

Если одна задача завершится с ошибкой, новые задания перестанут запускаться.

▪️ Можно даже запускать команды по SSH:

parallel -S server1,server2 'hostname; uptime' ::: 1

▪️ Когда использовать что

xargs -P отлично подходит, если нужно:

быстро распараллелить одну простую команду
минимум синтаксиса
не нужен сложный контроль выполнения

parallel удобнее, когда нужны:

несколько источников аргументов
управление количеством джобов
сохранение порядка вывода
остановка при ошибках
удаленный запуск
более сложные шаблоны команд

Например:

parallel -j 6 './backup.sh {} > logs/{}.log 2>&1' :::: databases.txt

Шесть баз обрабатываются одновременно, а каждая пишет в свой лог.

#bash #parallel #xargs

🧑‍💻 NetworkAdmin

Читать полностью…

🔐 PASSWD_NOTREQD в Active Directory: почему этот флаг нужно контролировать

При стандартной парольной политике Active Directory пользователь не может иметь пустой пароль, если в домене настроены минимальная длина и требования к сложности. Но есть исключение - флаг:

PASSWD_NOTREQD

В PowerShell он отображается как:

PasswordNotRequired

Если этот атрибут включен у учетной записи, AD допускает сценарий, при котором для пользователя пароль может не требоваться. Сам по себе флаг не означает, что пароль обязательно пустой. Но его наличие уже повод проверить учетную запись внимательнее.

▪️ Найти всех пользователей с включенным PasswordNotRequired:

Get-ADUser -Filter {PasswordNotRequired -eq $true} `
  -Properties PasswordNotRequired |
Select-Object SamAccountName,Enabled,PasswordNotRequired

Особенно важно проверить:

• привилегированные учетные записи
• сервисные аккаунты
• старые или забытые учетные записи
• пользователей, созданных через автоматизацию
• тестовые аккаунты, которые случайно остались в проде

▪️ Дополнительно можно вывести больше информации:

Get-ADUser -Filter {PasswordNotRequired -eq $true} `
  -Properties PasswordNotRequired,LastLogonDate,Description |
Select-Object SamAccountName,Enabled,LastLogonDate,Description

▪️ Если флаг не нужен, его можно отключить:

Set-ADUser -Identity "test-user" -PasswordNotRequired $false

После этого стоит убедиться, что у учетной записи установлен нормальный пароль и на нее распространяется актуальная парольная политика.

#activeDirectory #security

🧑‍💻 NetworkAdmin

Читать полностью…

✍️ DNS-диагностика без гадания и браузера

Когда сайт не открывается, очень легко сразу обвинить nginx, firewall или приложение. Но проблема может быть банально в DNS. Для нормальной диагностики удобнее всего использовать dig.

▪️ Базовый запрос:

dig networkadmin.ru

В ответе нас обычно интересует секция:

ANSWER SECTION

Именно там видно, в какой IP резолвится имя.

▪️ Посмотреть только результат без лишнего вывода:

dig +short networkadmin.ru

▪️ Проверить конкретный DNS-сервер:

dig @8.8.8.8 networkadmin.ru

Например, можно сравнить внутренний и публичный DNS:

dig @10.20.0.10 app.networkadmin.ru
dig @1.1.1.1 app.networkadmin.ru

Если ответы разные - возможно, используется split DNS.

▪️ Проверить конкретный тип записи:

dig A networkadmin.ru
dig AAAA networkadmin.ru
dig MX networkadmin.ru
dig TXT networkadmin.ru
dig NS networkadmin.ru

Полезно при диагностике почты, IPv6, SPF/DKIM и делегирования домена.

▪️ Посмотреть цепочку DNS-разрешения от корневых серверов:

dig +trace networkadmin.ru

Это помогает понять, на каком уровне ломается делегирование.

▪️ Еще один важный параметр - TTL:

dig networkadmin.ru

Число перед типом записи в ANSWER SECTION- показывает, сколько секунд ответ еще может храниться в кеше.

Для reverse DNS:

dig -x 203.0.113.15

▪️ Проверить, какой DNS реально использует linux:

cat /etc/resolv.conf

А при systemd-resolved:

resolvectl status

#dns #dig

🧑‍💻 NetworkAdmin

Читать полностью…

🖥 Get-ADUser: полезные примеры для работы с пользователями Active Directory

Get-ADUser - один из самых часто используемых PowerShell-командлетов при работе с active directory. С его помощью можно получать информацию о пользователях:

логин и имя
email
отдел и должность
компанию
состояние учетной записи
дату истечения пароля
дополнительные AD-атрибуты

Для работы нужен модуль:

ActiveDirectory

На контроллерах домена он обычно уже установлен. На рабочих станциях и рядовых серверах его можно добавить через RSAT.

▪️ Проверить наличие модуля:

Get-Module -ListAvailable ActiveDirectory

▪️ Вывести всех пользователей домена:

Get-ADUser -Filter *

Но по умолчанию Get-ADUser возвращает только базовый набор свойств.

▪️ Если нужны дополнительные атрибуты, используем -Properties. Например, посмотреть все свойства пользователя:

Get-ADUser -Identity "petrov" -Properties *

Вывести только нужные поля:

Get-ADUser -Identity "petrov" `
  -Properties Company,Department,Title,Mail |
Select-Object Name,Company,Department,Title,Mail

▪️ Один из самых полезных вариантов - фильтрация пользователей. Например, найти активные учетные записи без заполненного email:

Get-ADUser -Filter {
    Enabled -eq $true -and Mail -notlike "*"
} -Properties Mail |
Select-Object Name,SamAccountName,Mail

Найти пользователей с истекшим паролем:

Get-ADUser -Filter {
    Enabled -eq $true
} -Properties PasswordExpired |
Where-Object PasswordExpired |
Select-Object Name,SamAccountName,PasswordExpired

Найти пользователей определенного отдела:

Get-ADUser -Filter {
    Department -eq "IT"
} -Properties Department,Title |
Select-Object Name,Department,Title

▪️ Можно сразу выгрузить результат в CSV:

Get-ADUser -Filter * `
  -Properties Mail,Department,Title |
Select-Object Name,SamAccountName,Mail,Department,Title |
Export-Csv C:\Temp\ad-users.csv -NoTypeInformation -Encoding UTF8

#powershell #activedirectory

🧑‍💻 NetworkAdmin

Читать полностью…

🔎 TCP keepalive: как находить мертвые соединения до того, как они создадут проблему

Иногда TCP-соединение выглядит живым, хотя в реальности удаленная сторона уже давно недоступна.

Например:

клиент выключился;
оборвался VPN;
пропал маршрут;
firewall удалил state;
NAT-сессия протухла;
сервер завис без корректного закрытия соединения.

Если по соединению нет трафика, приложение может еще долго считать его активным.

Для таких случаев в TCP есть механизм keepalive.

▪️ Проверить текущие настройки linux:

sysctl net.ipv4.tcp_keepalive_time
sysctl net.ipv4.tcp_keepalive_intvl
sysctl net.ipv4.tcp_keepalive_probes

Типичная логика такая:

tcp_keepalive_time - сколько ждать простоя до первой проверки
tcp_keepalive_intvl - интервал между проверками
tcp_keepalive_probes - сколько неудачных попыток сделать

Например:

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 минут простоя ядро начнет проверять соединение, а при отсутствии ответа будет делать повторные попытки.

▪️ Для постоянной настройки:

cat > /etc/sysctl.d/99-tcp-keepalive.conf <<'EOF'
net.ipv4.tcp_keepalive_time=300
net.ipv4.tcp_keepalive_intvl=30
net.ipv4.tcp_keepalive_probes=5
EOF

sysctl --system

▪️ Посмотреть активные TCP-соединения:

ss -nto

▪️ Подробнее по конкретному соединению:

ss -ti

Но есть важный нюанс: системные значения работают только для сокетов, где приложение вообще включило SO_KEEPALIVE. То есть одной настройки sysctl иногда недостаточно. Например, nginx, PostgreSQL, HAProxy, SSH и различные runtime могут иметь собственные keepalive-параметры.

▪️ У SSH есть похожий механизм на уровне приложения:

ServerAliveInterval 30
ServerAliveCountMax 3

Это уже не TCP keepalive, но задача похожая - быстрее понять, что удаленная сторона больше не отвечает.

#tcp #keepalive

🧑‍💻 NetworkAdmin

Читать полностью…

💻 Как жестко перезагрузить linux, когда обычный reboot уже не помогает

Иногда сервер зависает настолько неприятно, что обычные команды:

reboot
shutdown -r now
systemctl reboot

либо не отрабатывают, либо висят вместе со всей системой. В таких случаях у Linux есть более низкоуровневый механизм - Magic SysRq.

▪️ Одна из самых известных команд:

echo b > /proc/sysrq-trigger

Она отправляет команду на перезагрузку напрямую ядру. По эффекту это примерно как нажать аппаратный Reset.

⚠️ Важно понимать: это нештатная перезагрузка.

▪️ Команда:

• не завершает процессы корректно;
• не размонтирует файловые системы;
• не делает sync;
• не ждет systemd;
• практически сразу перезапускает машину.

Именно поэтому она может помочь там, где обычный reboot уже не работает.

Если shell уже открыт, запись в /proc/sysrq-trigger может сработать даже в довольно поврежденной системе.

▪️ Проверить состояние SysRq:

cat /proc/sys/kernel/sysrq

0 - SysRq отключен
1 - разрешены все функции
>1 - разрешена только часть функций по битовой маске

▪️ Полный список доступных команд можно запросить так:

echo h > /proc/sysrq-trigger

Подсказка обычно попадет в kernel log:

journalctl -k

или:

dmesg

▪️ Кроме b, есть и другие полезные команды. Например:

echo s > /proc/sysrq-trigger

пытается синхронизировать файловые системы.

echo u > /proc/sysrq-trigger

пытается перемонтировать файловые системы в read-only.

И только потом:

echo b > /proc/sysrq-trigger

Есть даже известная последовательность: REISUB, где поэтапно пытаются вернуть управление клавиатурой, завершить процессы, синхронизировать диски, перемонтировать FS в read-only и только затем перезагрузиться.

#linux #reboot

🧑‍💻 NetworkAdmin

Читать полностью…

👌 Firewall default deny: как внедрять без внезапного отрезания доступа

Идея простая: разрешаем только то, что действительно нужно, все остальное блокируем. На бумаге это выглядит идеально. На практике одна неправильная команда - и SSH-сессия заканчивается вместе с доступом к серверу.

Поэтому default deny лучше внедрять не одной командой, а поэтапно.

▪️ Для nftables базовая политика может выглядеть так:

table inet filter {
    chain input {
        type filter hook input priority 0;
        policy drop;

        iif lo accept
        ct state established,related accept

        tcp dport 22 ip saddr 10.20.0.0/16 accept
        tcp dport { 80, 443 } accept
    }
}

Критически важные строки:

iif lo accept
ct state established,related accept

Первая не ломает localhost-взаимодействия сервисов.
Вторая разрешает пакеты уже установленных соединений.

▪️ Перед включением policy drop сначала выпишите все, что сервер реально принимает:

ss -lntup

Проверьте текущие соединения:

ss -nt

И не забудьте про инфраструктурный трафик:

SSH / RDP
мониторинг
бэкап
DNS
NTP
балансировщики
кластеры

▪️ Хороший порядок внедрения:

1. Создать явные allow-правила.
2. Проверить доступ из отдельной сессии.
3. Сохранить текущую SSH-сессию открытой.
4. Иметь доступ через console/IPMI/iDRAC/VM console.
5. Только после этого включать drop.

▪️ Перед применением конфигурации:

nft -c -f /etc/nftables.conf

Ключ -c проверит синтаксис, не применяя правила.

▪️ Еще полезнее - заранее сделать автооткат. Например:

echo "nft flush ruleset" | at now + 5 minutes

Применили firewall, проверили доступ - отменили задание:

atq
atrm <job_id>

Если сами себя отрезали, через несколько минут правила сбросятся.

#firewall #nftables

🧑‍💻 NetworkAdmin

Читать полностью…

🌲 Как посмотреть дерево процессов в Linux: htop, ps и pstree

Когда нужно понять, какой процесс кого запустил, обычного списка ps часто недостаточно. Намного удобнее посмотреть процессы в виде дерева: родительский процесс -> дочерние процессы -> подпроцессы. Есть несколько простых способов.

1️⃣ Дерево процессов в htop. Если htop уже установлен, нажмите: t. Это переключит список в режим Tree View. Так удобно быстро посмотреть структуру процессов прямо в интерактивном интерфейсе: например, какие worker-процессы запустил nginx, systemd или приложение.

Но если процессов много и вывод нужно спокойно изучить, интерактивный интерфейс бывает не самым удобным.

2️⃣ Команда ps axf Консольный вариант:

ps axf

Ключ f показывает процессы в виде ASCII-дерева. Если вывод большой, его можно сохранить в файл:

ps axf > ~/process-tree.txt

После этого список удобно открыть в редакторе, искать по нему и прикладывать к разбору инцидента.

Более информативный вариант:

ps -eo user,pid,ppid,stat,lstart,cmd --forest

Здесь дополнительно видны пользователь, PID, PPID, статус, время запуска и полная команда.

3️⃣ Утилита pstree. pstree входит в пакет psmisc, который часто уже установлен в системе.

Установка:

apt install psmisc

Базовый запуск:

pstree

Показать PID:

pstree -p

Показать аргументы команд:

pstree -a

Вывести дерево для конкретного процесса:

pstree -p 1234

Или для пользователя:

pstree -p username

Полезные параметры:

-p - показывает PID
-a - показывает аргументы командной строки
-n - сортирует процессы по PID
-u - показывает смену пользователя
-s - показывает родителей указанного процесса
-c - не объединяет одинаковые ветки

Например:

pstree -p -a -u

#linux #terminal #processes

🧑‍💻 NetworkAdmin

Читать полностью…

💚 Bonding в Linux: active-backup, LACP и типовые ошибки настройки

Bonding объединяет несколько сетевых интерфейсов в один логический bond0. Обычно его используют для:

• резервирования сетевого подключения
• распределения нагрузки
• защиты от отказа кабеля, порта или сетевой карты
• увеличения суммарной пропускной способности

Два самых популярных режима - active-backup и 802.3ad.

▪️ Active-backup. В каждый момент работает только один интерфейс. Второй находится в резерве и включается при отказе основного.

[NetDev]
Name=bond0
Kind=bond

[Bond]
Mode=active-backup
MIIMonitorSec=100ms
Primary=eno1

Главный плюс - простота. Специальная настройка коммутатора обычно не требуется. Подходит, когда нужна прежде всего отказоустойчивость.

▪️ LACP - 802.3ad. Оба интерфейса могут передавать трафик одновременно:

[Bond]
Mode=802.3ad
MIIMonitorSec=100ms
LACPTransmitRate=fast
TransmitHashPolicy=layer3+4

Но на коммутаторе порты должны быть объединены в один LAG с поддержкой LACP.

Важно понимать: одно TCP-соединение обычно не получит скорость двух интерфейсов. Трафик распределяется по хешу между разными потоками.

Проверить состояние bonding:

cat /proc/net/bonding/bond0

Там видно:

текущий активный интерфейс
состояние каждого slave
скорость и duplex
количество переключений
состояние LACP

Дополнительно:

ip -br link
ip -s link show bond0
ethtool eno1

▪️ Типовые ошибки

• включили 802.3ad, но не настроили LAG на коммутаторе
• порты подключены к разным независимым коммутаторам без MLAG/stack
• IP назначен одновременно на bond0 и физические интерфейсы
• интерфейсы имеют разную скорость или MTU
• забыли удалить старые маршруты и конфигурации slave-интерфейсов
• считают, что LACP удвоит скорость одного соединения
• проверяют только link up, хотя трафик через порт не проходит

#linux #bonding #network

🧑‍💻 NetworkAdmin

Читать полностью…

📁 Логирование скриптов в Windows Event Viewer

Для логов PowerShell и BAT-скриптов необязательно создавать отдельные текстовые файлы. Важные события можно записывать прямо в Event Viewer. Это удобно, потому что такие записи проще искать, фильтровать и собирать централизованно через WEF, SIEM или систему мониторинга.

▪️ Сначала создадим отдельный источник событий:

New-EventLog -LogName Application -Source "MyScript"

Эту команду обычно достаточно выполнить один раз с правами администратора.

▪️ Теперь можно записать событие в журнал Application:

Write-EventLog `
  -LogName Application `
  -Source "MyScript" `
  -EntryType Information `
  -EventID 1 `
  -Message "Запущен PowerShell-скрипт проверки состояния сервера"

▪️ Для ошибок и предупреждений меняем тип события:

Write-EventLog `
  -LogName Application `
  -Source "MyScript" `
  -EntryType Error `
  -EventID 1001 `
  -Message "Не удалось подключиться к серверу"

Полезно заранее определить свою схему Event ID:

1 -запуск скрипта
2 - успешное завершение
100 - предупреждение
1001 - ошибка выполнения

▪️ Если не хочется смешивать записи с общим журналом Application, можно создать отдельный EVTX-журнал:

New-EventLog -LogName CustomPSLog -Source "PS1Script"

А затем писать события уже в него:

Write-EventLog `
  -LogName CustomPSLog `
  -Source "PS1Script" `
  -EntryType Information `
  -EventID 1 `
  -Message "Скрипт запущен"

▪️ В BAT- и CMD-скриптах для этого есть команда eventcreate:

eventcreate /t information /l application /id 1 /d "BAT script started"

Для записи ошибки:

eventcreate /t error /l application /id 1001 /d "BAT script failed"

Подробный debug-вывод удобнее оставлять в обычном текстовом логе. Хорошая схема выглядит так: детали — в файл, важные события — в Event Viewer.

#windows #eventviewer

🧑‍💻 NetworkAdmin

Читать полностью…

⏰ Точное время до запуска сервисов: одноразовая синхронизация через chrony

Обычно синхронизация времени в Linux работает незаметно: установили chrony, systemd-timesyncd или другой NTP-клиент - и забыли. Но после загрузки виртуальной машины системное время иногда отличается на несколько минут. Служба синхронизации исправит его, однако часть сервисов к этому моменту уже может успеть запуститься.

В результате появляются:

• события в логах с неправильным временем
• ошибки проверки сертификатов
• проблемы с Kerberos и токенами
• некорректный порядок событий
• странности в распределенных системах и мониторинге

Для обычной работы постепенная коррекция времени подходит. Но на старте иногда нужно сначала выставить часы, а уже потом запускать приложение. Для этого можно создать одноразовый systemd-unit с chronyd -q.

▪️ Устанавливаем chrony:

apt install chrony

▪️ Создаем unit:

systemctl edit --force --full chrony-once-sync.service

▪️ Добавляем:

[Unit]
Description=Initial time synchronization with chrony
Wants=network-online.target
After=network-online.target
Before=myapp.service

[Service]
Type=oneshot
ExecStart=/usr/sbin/chronyd -q -t 10

[Install]
WantedBy=multi-user.target

-q - один раз выставить время и завершить работу
-t 10 - прекратить попытку через 10 секунд
After=network-online.target - запускать после готовности сети
Before=myapp.service - выполнить синхронизацию раньше критичного приложения

▪️ Активируем юнит:

systemctl daemon-reload
systemctl enable chrony-once-sync.service

▪️ Проверяем после перезагрузки:

systemctl status chrony-once-sync.service
journalctl -u chrony-once-sync.service -b

▪️ Посмотреть порядок запуска:

systemd-analyze critical-chain myapp.service

#linux #systemd #chrony

🧑‍💻 NetworkAdmin

Читать полностью…

😩 systemd-analyze: почему сервер долго загружается и кто виноват

Иногда сервер после reboot поднимается подозрительно долго. Вроде железо нормальное, диск живой, сервисов не так много, но до нормального состояния система доходит через минуту, две или даже дольше.

В systemd для такого разбора есть удобная утилита:

systemd-analyze

Она покажет общее время загрузки:

Startup finished in 5.2s (kernel) + 28.4s (userspace) = 33.6s

Здесь видно, сколько заняло ядро и сколько - userspace, то есть запуск systemd-сервисов.

▪️ Чтобы понять, какие иниты запускались дольше всего:

systemd-analyze blame

Пример вывода:

12.834s docker.service
8.421s NetworkManager-wait-online.service
6.102s postgresql.service
3.451s nginx.service

Это хороший первый ориентир, но есть важный нюанс.

blame показывает длительность запуска юнитов, но не всегда показывает реального виновника. Сервисы могут запускаться параллельно, и длинный сервис не обязательно блокировал всю загрузку.

▪️ Для понимания цепочки зависимостей лучше использовать:

systemd-analyze critical-chain

Эта команда показывает критический путь загрузки - что действительно задерживало достижение нужного target.

▪️ Можно посмотреть цепочку для конкретного сервиса:

systemd-analyze critical-chain docker.service

▪️ Частые причины долгой загрузки:

ожидание сети
зависший mount из /etc/fstab
медленный DNS
NFS/SMB mount без `nofail`
долгий старт базы данных
Docker/container runtime
cloud-init
некорректные зависимости в юнитах
таймауты несуществующих устройств

▪️ Отдельно стоит проверить failed-юниты:

systemctl --failed

▪️ Логи текущей загрузки:

journalctl -b

Если проблема была на предыдущем boot:

journalctl -b -1

▪️ Еще полезная команда - построить SVG-график загрузки:

systemd-analyze plot > boot.svg

Файл boot.svg можно открыть в браузере и визуально посмотреть, какие сервисы когда стартовали и сколько длились.

▪️ Для поиска ошибок в unit-файлах:

systemd-analyze verify /etc/systemd/system/myapp.service

Это помогает поймать неправильные директивы, опечатки и странности в конфигурации.

#linux #systemd

🧑‍💻 NetworkAdmin

Читать полностью…

👀 inotifywait: реакция на изменения файлов без cron

Иногда нужно выполнить действие сразу после изменения файла или каталога. Например:

• изменился конфиг - перезапустить сервис
• появился новый файл - обработать его
• загрузили архив - распаковать
• изменился сертификат - перечитать nginx
• в каталог упал лог - отправить уведомление

Первое решение, которое часто приходит в голову - cron. Но cron работает по расписанию. Он не реагирует на событие сразу, а просто периодически проверяет состояние. Для событий в файловой системе удобнее использовать inotifywait.

▪️ Установка:

apt install inotify-tools

▪️ Посмотреть изменения файла:

inotifywait -m /etc/nginx/nginx.conf

Ключ -m включает постоянное наблюдение.

Пример вывода:

/etc/nginx/nginx.conf MODIFY

▪️ Следить за каталогом:

inotifywait -m /var/www

Рекурсивно:

inotifywait -m -r /var/www

Можно выбрать конкретные события:

inotifywait -m -e create,modify,delete /var/www

▪️ Простой пример: перезагрузить nginx после изменения конфига.

while inotifywait -e modify /etc/nginx/nginx.conf; do
  nginx -t && systemctl reload nginx
done

Смысл простой:

• ждем изменение файла
• проверяем конфиг
• если всё нормально - reload nginx
• снова ждем следующее изменение

▪️ Еще пример: обработать новые файлы в каталоге.

inotifywait -m -e close_write --format '%w%f' /data/incoming |
while read -r file; do
  echo "new file: $file"
  /opt/scripts/process-file.sh "$file"
done

Почему close_write, а не просто create? Потому что файл может появиться, но запись в него еще не закончилась. close_write срабатывает, когда файл уже записан и закрыт.

⚠️ inotifywait - не замена очередям, брокерам сообщений и нормальной event-driven архитектуре. У него есть лимиты ядра, события можно потерять при перегрузке, а рекурсивное наблюдение за огромными деревьями может быть тяжелым. Проверить лимиты можно так:

sysctl fs.inotify.max_user_watches
sysctl fs.inotify.max_user_instances

#linux #inotify

🧑‍💻 NetworkAdmin

Читать полностью…

📂 sshfs: монтируем удаленный каталог через SSH и systemd

sshfs позволяет монтировать удаленную файловую систему через обычное SSH-соединение. То есть если у вас есть SSH-доступ к серверу, можно подключить его каталог как локальную директорию. Это не самый быстрый способ: SSHFS работает через FUSE в user space, плюс само SSH-соединение добавляет накладные расходы. Но для некоторых задач это очень удобно. Особенно когда: SSH уже открыт; NFS/SMB поднимать не хочется; нужен быстрый доступ к отдельному каталогу или нужно временно подключить данные

▪️ Установка:

apt install sshfs

▪️ Для автомонтирования лучше сразу настроить доступ по ключу. Генерируем ключ:

ssh-keygen -t ed25519

Копируем его на удаленный сервер:

ssh-copy-id root@10.20.1.6

Можно подключаться и по паролю, но для systemd-автомонтирования это неудобно: пароль придется вводить интерактивно. С ключом все проще и надежнее.

▪️ Пример. Допустим, нужно смонтировать каталог:

root@10.20.1.6:/etc/letsencrypt

в локальный путь:

/mnt/letsencrypt

Создаем точку монтирования:

mkdir -p /mnt/letsencrypt

Монтируем вручную:

sshfs root@10.20.1.6:/etc/letsencrypt /mnt/letsencrypt

Проверяем:

df -h | grep 10.20.1.6

Размонтировать можно так:

fusermount -u /mnt/letsencrypt

▪️ Теперь сделаем systemd-unit, чтобы монтировать каталог автоматически. Создаем service:

systemctl edit --force --full sshfs-letsencrypt.service

Пример unit-файла:

[Unit]
Description=Mount /etc/letsencrypt over SSHFS
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
RemainAfterExit=true

ExecStart=/usr/bin/sshfs root@10.20.1.6:/etc/letsencrypt /mnt/letsencrypt -o reconnect,ServerAliveInterval=15,ServerAliveCountMax=3
ExecStop=/usr/bin/fusermount -u /mnt/letsencrypt

[Install]
WantedBy=multi-user.target

Перечитываем systemd:

systemctl daemon-reload

Запускаем:

systemctl start sshfs-letsencrypt.service

Добавляем в автозагрузку:

systemctl enable sshfs-letsencrypt.service

Если нужно размонтировать каталог:

systemctl stop sshfs-letsencrypt.service

▪️ Полезные опции:

• reconnect - Пытаться восстановить подключение при обрыве.
• ServerAliveInterval=15 - Периодически проверять, живо ли SSH-соединение.
• ServerAliveCountMax=3 - После нескольких неудачных проверок считать соединение мертвым.

В примере все сделано от root для простоты. Для постоянной схемы лучше использовать отдельного пользователя с минимальными правами. В systemd можно указать:

User=sftp-user
Group=sftp-user

Но тогда важно, чтобы у этого пользователя были права на точку монтирования и SSH-ключи.

#linux #sshfs

🧑‍💻 NetworkAdmin

Читать полностью…