NetworkAdmin.ru

🤩 Как расшифровать код ошибки 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

💻 Как жестко перезагрузить 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

🌚 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

👌 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

Звезда родилась. И у нее уже есть что рассказать. 24 сентября — День “ТризТех” — первое в России мероприятие, посвященное сетевой безопасности, где вендоры, регуляторы и крупнейшие заказчики обсудят текущее состояние, проблемы и перспективы рынка. В программе — разговор о и том, что происходит с сетевой безопасностью в России прямо сейчас, подходы к сравнению решений и реальный опыт внедрений. А для тех, кому важна инженерия, — управление сложными структурами, домены доступа, командная строка, архитектура и производительность в реальных условиях. И конечно, цифры и результаты ТризТеха с начала года, стратегия и планы, а также продуктовые анонсы компании. Это не очередная презентация продукта. Это первый большой выход ТризТеха в новом статусе и возможность узнать планы компании раньше большинства. 📅 24 сентября | 10:30–17:00 | онлайн ➡️ Регистрируйтесь на трансляцию Дня ТризТеха и проходите за эксклюзивом.

Звезда родилась. И у нее уже есть что рассказать. 24 сентября — День “ТризТех” — первое в России мероприятие, посвященное сетевой безопасности, где вендоры, регуляторы и крупнейшие заказчики обсудят текущее состояние, проблемы и перспективы рынка. В программе — разговор о и том, что происходит с сетевой безопасностью в России прямо сейчас, подходы к сравнению решений и реальный опыт внедрений. А для тех, кому важна инженерия, — управление сложными структурами, домены доступа, командная строка, архитектура и производительность в реальных условиях. И конечно, цифры и результаты ТризТеха с начала года, стратегия и планы, а также продуктовые анонсы компании. Это не очередная презентация продукта. Это первый большой выход ТризТеха в новом статусе и возможность узнать планы компании раньше большинства. 📅 24 сентября | 10:30–17:00 | онлайн ➡️ Регистрируйтесь на трансляцию Дня ТризТеха и проходите за эксклюзивом.

🖥 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

🌲 Как посмотреть дерево процессов в 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

😐 #юмор 🧑‍💻 NetworkAdmin

Этот файл был удален пользователем Встречаемся в Москве с теми, кто отвечает за хранение данных бизнеса. Обсудим, как решить задачу со звездочкой — уберечь массивы файлов и резервных копий от атак шифровальщиков, утечки или случайной перезаписи. На бизнес-ужине эксперты провайдера ИТ-инфраструктуры Selectel расскажут: ➕как устроено хранилище S3 под капотом; ➕какие угрозы данным существуют и как выстроить многослойную систему защиты; ➕почему защита данных — это не статья расходов, а управление рисками. Будет актуально руководителям в ИТ-компаниях, старшим архитекторам, системным администраторам. Поговорим и про стратегию хранения, и про реализацию. 📆 24 сентября (чт), 18:30 📍Москва, м. Динамо ⏩Участие бесплатное, дождитесь подтверждения заявки. Смотрите полную программу и регистрируйтесь: https://slc.tl/t7ito Реклама. АО "Селектел". erid:2W5zFJz9JhX

💚 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

👁 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

📁 Логирование скриптов в 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

Вы не заставите меня их закрыть. 🤩 #юмор 🧑‍💻 NetworkAdmin

NVMe VPS для рабочих и пет-проектов от DLine Media — от 300 ₽ за месяц -> Combo 1 · 1 vCPU · 1 ГБ · 10 ГБ NVMe · 100 Мбит — 300 ₽ -> Combo 2 · 2 vCPU · 4 ГБ · 25 ГБ NVMe · 300 Мбит — 750 ₽ -> Combo 3 · 4 vCPU · 8 ГБ · 50 ГБ NVMe · 500 Мбит — 1 700 ₽ В каждом тарифе: безлимитный трафик, IPv4, защита от DDoS, root, любой образ. 15 локаций — Москва, Петербург, Казань, Новосибирск, Амстердам, Франкфурт, Лондон, Токио и другие. Looking Glass, чтобы проверить сеть до оплаты. Забукировать сервер можно по ссылке

⏰ Точное время до запуска сервисов: одноразовая синхронизация через 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

Хотите выйти на зарубежный рынок, но непонятно, с чего начать? Если вы: — фрилансер и хотите работать с иностранными заказчиками; — IT-специалист или развиваете IT-компанию; — владелец digital- или маркетингового агентства; — дизайнер или руководитель дизайн-студии; — эксперт и хотите продавать свои услуги за пределами локального рынка; — предприниматель, который планирует развивать бизнес за рубежом Меня зовут Альберт Сабиров. Владелец международного digital агентства. Приглашаю вас на свой канал, где я на практике работаю с зарубежными рынками и в канале делюсь опытом, который помогает разобраться: — где искать первых клиентов за рубежом; — как выйти на иностранных заказчиков; — как адаптировать и упаковать свои услуги под зарубежный рынок; — как принимать оплату из других стран; — как открывать зарубежные счета и работать с ними; — как зарегистрировать компанию за границей; — что учитывать в договорах, налогах и законодательстве; — как выстроить маркетинг и привлечение клиентов на новом рынке; — какие ошибки могут стоить денег и времени при выходе за рубеж. Если хотите перестать зависеть только от локального рынка и понять, как системно начать работать за рубежом — присоединяйтесь. Альберт Сабиров | Зарубежный рынок

💚 Как один неверный 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

😩 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

🤩 Почему места достаточно, но приложение всё равно не может записать файл Иногда на сервере возникает странная ситуация. Проверяем диск:

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