Простой тест (-c 4 - 4 запроса, . - текущий каталог):

$ ioping -c 4 .

Результат показан на скриншоте в предыдущем посте🙂

Первый запрос (warmup) исключается из статистики.

Сводка:
⭐️ 3 requests completed - без warmup и без учёта пауз:
- in - время выполнения 3 запросов (без пауз);
- KiB read - объём прочитанных данных (3 × 4 КБ);
- iops / MiB/s - производительность (без пауз).
⭐️ generated 4 requests - с warmup и паузами между запросами (1с);
- in - время выполнения теста;
- KiB - объём прочитанных данных (4 × 4 КБ);
- iops / KiB/s - производительность с учётом пауз.
⭐️ статистика задержек (min/avg/max/mdev).

Полезные опции:
- ioping -c 10 -i 0.1 . - интервал 0.1с;
- ioping -D -c 5 . - O_DIRECT (без page cache);
- ioping -L . - последовательный доступ (~256 KiB);
- ioping -R . - быстрый тест IOPS (rapid mode);
- ioping -RL . - тест пропускной способности (последовательный доступ);
- ioping -S . - синхронный I/O (O_SYNC).

Рекомендуется тестировать файл, а не каталог, например:

$ dd if=/dev/urandom of=ioping-testfile bs=1M count=4096
$ ioping -R -D -c 1000 ioping-testfile # мелкие случайные чтения (БД, метаданные)
$ ioping -RL -D -c 1000 ioping-testfile # крупные последовательные чтения (бэкапы, ВМ)

📝OOM Killer в Linux

Механизм призван уберечь систему от зависания в случае нехватки RAM. Если на сервере заканчивается RAM, то приходит OOM Killer и убивает самый плохой процесс.

Каждый процесс в системе получает баллы плохости (oom_score).
- Чем больше RAM съел процесс, тем больше баллов.
- Чем больше дочерних процессов у процесса, тем больше баллов.
- Чем меньше процесс работает, тем больше баллов.
- Если процесс не является системным, то баллы ещё накидываются.

Для управления нам оставили корректирующий коэффициент (oom_score_adj). От -1000 до 1000.
* -1000: Процесс никогда не будет убит;
* 0: По умолчанию;
* 1000: Процесс будет убит первым.

Это обычно настраиваются в сервисе SystemD:

[Service]
# Защита от OOM Killer
OOMScoreAdjust=-500
# При завершении - перезапустить
OOMPolicy=restart

Можем включить или выключить механизм:

echo vm.panic_on_oom = 1 »/etc/sysctl.conf # вместо OOM Killer -> kernel panic
echo vm.panic_on_oom = 0 »/etc/sysctl.conf # по умолчанию -> OOM Killer

Для применения: sysctl -p

📝Команды SystemD (systemctl)

✅systemctl status <имя службы> — статус службы;
✅systemctl stop <имя службы> — остановить службу;
✅systemctl start <имя службы> — запустить службу;
✅systemctl restart <имя службы> — перезапустить службу;
✅systemctl reload <имя службы> — перечитать конфиг приложения;
✅systemctl cat <имя службы> — прочитать файл юнита;
✅systemctl daemon-reload — пере-инициализировать все юниты;
✅systemctl enable <имя службы> — добавить службу в автозагрузку;
✅systemctl disable <имя службы> — убрать службу из автозагрузки;
✅systemctl is-enabled <имя службы> — статус автозагрузки для службы;
✅systemctl list-units -t service — список запущенных служб;
✅systemctl list-units -t service --all — список всех служб;
✅systemctl get-default — узнать текущий загрузочный таргет по умолчанию;
✅systemctl set-default -f <таргет> – установить загрузочный таргет, как таргет по умолчанию;
✅systemctl isolate <таргет> – запустить другой загрузочный таргет.

📝Команды SystemD (дополнительно)
✅systemd-analyze - время загрузки
✅systemd-analyze blame - детальнее

✅timedatectl - время
✅sudo timedatectl set-time '2019-08-31 16:14:50' - установить время
✅timedatectl list-timezones
✅sudo timedatectl set-timezone "Europe/Moscow" - установить ЧП

✅hostnamectl - посмотреть имя и информацию о системе
✅hostnamectl set-hostname --static deb-13 - поменять имя

✅localectl - локаль
✅sudo localectl set-locale LANG="ru_RU.UTF-8" - установить локаль

✅loginctl list-sessions - список сессий
✅loginctl list-users - список login-пользователей
✅loginctl session-status - статус сессии
✅sudo loginctl kill-user <user | № сессии> - убить сессию
✅sudo loginctl terminate-user <user | № сессии> - завершить сессию

✅journalctl - логи
✅journalctl --since "2026-03-30 09:35:00" - логи с момента
✅journalctl -u <имя сервиса> - логи службы
✅journalctl _PID=<PID> - логи процесса
✅journalctl _UID=<UID> - логи пользователя
✅journalctl -k - логи ядра
✅journalctl -f - наблюдать за логами

📝В этой статье описывается установка сервера хранения паролей и секретов Vaultwarden в Docker на собственном сервере.

👉Из особенностей, я использую базу данных MariaDB и обратный прокси сервер Caddy. Для поднятия контейнеров использую Docker compose.

📝Общий алгоритм поиска и устранения неисправностей (CompTIA)

Данный алгоритм представляет собой процесс, позволяющий системно подходить к решению любых технических проблем.

1. Определение проблемы. На этом этапе важно максимально точно понять причины проблемы.
- Сбор симптомов. Опросить пользователя, воспроизвести ошибку, посмотреть логи.
- Определение масштаба. Локальная проблема или системная (весь сегмент сети/несколько сервисов).
- Установка приоритетов. Оценить влияние на бизнес-процессы или работу пользователя.

2. Разработка теории / быстрые решения. На основе собранных данных формулируется наиболее вероятная причина неисправности.
- Формулирование гипотезы. Вероятно проблема в том-то или том-то.
- Составление списка быстрых решений. Например: перезагрузка (программы, пк, сервера), проверка кабеля, вход/выход из учетной записи.
👇(продолжение)

👆(начало)
3. Проверка быстрых решений. Из списка составленного на 2 этапе.
- Действие. Последовательно применить быстрые решения.
- Анализ. Если проблема решена - перейти к этапу проверки функциональности (п. 6). Если нет - зафиксировать, что не сработало, и перейти к углубленной диагностики.

4. Углубленная диагностика. Если быстрые решения не помогли, необходимо вернуться к анализу и расширить область поиска проблемы.
- Сбор дополнительных данных. Использовать специализированные инструменты диагностики (мониторинг, тестирование, анализ дампов).
- Формирование новой теории. Основываясь на углубленной диагностики, выдвинуть новую гипотезу о причине проблемы.
- Создание плана Б. Разработать пошаговый план действий для проверки новой теории.

5. Внедрение разработанного плана действий. Выполнение выбранного решения.
- Оценка рисков. При необходимости создать точку восстановления / бэкап.
- Реализация. Выполнить запланированные действия (замена компонента, изменение конфигурации, обновление драйверов).
- Проверка результата. Если решение не помогло - вернуться к пункту 4 для разработки новой теории. Если помогло - продолжить.

6. Проверка функциональности. Убедиться, что проблема решена полностью.
- Тестирование. Проверить не только исправленный узел, но и связанные с ним.
- Проверка безопасности. Убедиться, что предпринятые меры не ослабили систему безопасности (открыли лишние порты / повысили права доступа).
- Получение подтверждения. Убедиться, что заказчик подтверждает работоспособность системы.

7. Документирование. Это позволяет избежать повторения ошибок в будущем.
- Фиксация симптомов и причин. Краткое описание исходной проблемы и корневой причины.
- Описание решения. Пошаговое руководство по устранению.
- Профилактика. При необходимости добавить рекомендации по предотвращению подобных инцидентов (мониторинг, замена расходников, обновление политик).

👉Алгоритм является циклическим. Если на этапе 4 или 5 новая теория не подтверждается или решение не срабатывает, необходимо повторно возвращаться к сбору данных (пункт 1) или разработке новой теории (пункт 4), а не пытаться «додавить» изначально неверную гипотезу.

📝В этой статье я покажу как установить сервер для управления проектами «Taiga.io» в Docker.

👉Особенности установки: я буду производить установку на Debian 13, для обратного проксирования на хост установлю nginx. Затем переведу работу сервера на https используя самоподписанный сертификат.

📝Решение сетевых проблем - диагностика по уровням OSI

Принцип диагностики: Двигаемся снизу вверх (от физического уровня к прикладному). Проблема на нижнем уровне делает бессмысленной проверку верхних.

✅Физический (L1)
Диагностика физического подключения: статус линка, целостность кабеля, ошибки на физическом уровне (CRC, фреймы), затухание, работа SFP-модулей.

Утилиты и инструменты:
- ethtool - статус, статистика ошибок, тестирование
- Диагностика кабеля / Визуальный осмотр порта коммутатора
- Веб-интерфейс / CLI коммутатора (порт: статус / статистика)

✅Канальный (L2)
Проверка связности в пределах локальной сети, корректность настроек интерфейса, работа ARP, отсутствие конфликтов MAC-адресов, правильность VLAN.

Утилиты и инструменты:
- ip - состояние, настройка, статус интерфейса, arp таблица
- ping <локальный_IP_шлюза> — L2-связность
- На коммутаторе: MAC-таблица
👇(продолжение)

👆(начало)
✅Сетевой / Маршрутизация (L3)
Проверка IP-адресации, таблиц маршрутизации, трассировка пути, выявление разрывов маршрута, проблем с MTU и асимметричной маршрутизации.

Утилиты и инструменты:
- ip - IP-адрес, маска, таблица маршрутизации
- ping <удаленный_IP> - связность через маршрутизатор
- traceroute -n <IP> (Linux) / tracert -d <IP> (Windows) - трассировка маршрута
- Проверка таблиц маршрутизации на промежуточных роутерах

✅Транспортный (L4)
Диагностика транспортного уровня: проверка слушающих портов и их доступность (фаервол), состояния соединений.

Утилиты и инструменты:
- ss -tlnp / -ulnp - слушающие TCP / UDP порты
- ss -tn - активные TCP-соединения
- telnet <IP> <порт> или nc -zv <IP> <порт> — проверка доступности порта
- nmap -p <порт> <IP> — сканирование порта (open/filtered)
- iptables -L -n -v (Linux) / netsh advfirewall show (Windows) — правила фаервола
- Проверка фаервола на маршрутизаторах

✅Верхние уровни (L5–L7)
Анализ прикладных протоколов, содержимого трафика, производительности, DNS-резолвинга, ошибок приложений.

Утилиты и инструменты:
- tcpdump / Wireshark — анализ трафика (ретрансмиссии, dup ACK, потери)
- nslookup / dig / host — диагностика DNS
- iperf3 — измерение пропускной способности
- curl / wget — диагностика HTTP/HTTPS
- journalctl -u <сервис> — логи прикладного сервиса
- Логи веб-сервера (access.log, error.log)

Я постепенно перевожу сайт с WordPress на статический генератор Hugo. Процесс идёт в полуавтоматическом режиме: скрипты переносят контент, а я вручную проверяю вёрстку, ссылки и изображения.

Для каждой перенесённой статьи уже настроена постоянная переадресация (301), поэтому старые ссылки продолжат работать без проблем.

Hugo создаёт полностью статический сайт, которому не нужны база данных или серверный бэкенд. Благодаря этому сайт становится:
⚡️Быстрее - статика отдаётся мгновенно.
🛡Безопаснее - без базы данных и PHP взламывать просто нечего.
💰 Дешевле в поддержке - это папка с HTML-файлами и картинками, поэтому хватит максимально экономичного тарифа хостинга.

Миграция требует времени, поэтому, чтобы канал не пустовал, я буду публиковать здесь статьи по мере их переноса. Спасибо, что читаете и следите за обновлениями!

Продолжаю переносить статьи на новый сайт, и заодно актуализирую некоторые из статей.

👉Сегодня — обновил статью по Debian до версии 13 (Trixie): добавил свежие нюансы и поправил устаревшие моменты.

Обновил ещё одну статью — там появилась информация про Ubuntu 26.04 LTS (Resolute Raccoon).

Постепенно переношу старые материалы, но параллельно будут выходить и новые статьи и короткие заметки. Не переключайтесь 🙂

📝 Сравнение файловых систем Linux

✅ Ext4
Журналируемая ФС семейства ext. Надёжная и наиболее распространённая ФС в Linux. Часто является оптимальным выбором по умолчанию, если не требуются специфические возможности других файловых систем.

- максимальная длина имени файла — 255 B;
- максимальный размер файла — до 16 TB;
- максимальный размер ФС — до 1 EB;
- inode создаются заранее при создании ФС;
- контрольные суммы только для метаданных;
- поддержка ACL;
- есть онлайн-дефрагментация, но менее эффективна, чем в XFS.

👇(продолжение)

👆(начало)

✅ XFS
Высокопроизводительная журналируемая файловая система, особенно хорошо подходит для работы с большими файлами и крупными файловыми системами. По умолчанию используется в RHEL / CentOS.

- максимальная длина имени файла — 255 B;
- максимальный размер файла — до 8 EB;
- максимальный размер ФС — до 8 EB;
- динамическое выделение и освобождение inode;
- контрольные суммы только для метаданных;
- поддержка ACL;
- продвинутая онлайн-дефрагментация;
- может уступать ext4 по latency при работе с большим количеством мелких файлов;
- невозможно уменьшить размер существующей файловой системы.

✅ Btrfs
Функциональная Copy-on-Write файловая система с расширенными возможностями управления данными. Требует больше ресурсов и в некоторых сценариях менее предсказуема по сравнению с ext4/XFS.

- максимальная длина имени файла — 255 B;
- максимальный размер файла — до 16 EB;
- максимальный размер ФС — до 16 EB;
- динамическое создание и удаление inode;
- контрольные суммы для данных и метаданных;
- поддержка ACL;
- дополнительно: снапшоты, встроенные RAID1/10 (RAID5/6 — экспериментальные), сжатие.

🗓PowerShell для начинающих администраторов: команды, справка и примеры

👉Из статьи вы узнаете про встроенную справку PowerShell и как её обновлять (Update-Help, Get-Help). А также, в статье есть список полезных команд PowerShell для системных администраторов (Get-Command, Get-Process и другие).

📝Установка двух экземпляров WordPress на Apache 2

👉В этой статье я покажу как установить несколько экземпляров WordPress на физический или виртуальный сервер Debian 13. А в качестве web-сервера будем использовать Apache 2.

👉Перед разворачиванием боевого WordPress, хочется с ним познакомится поближе. Для этого его можно развернуть у себя на виртуалке или на физическом сервере. В этой статье я показываю, как можно установить 2 экземпляра WordPress на одном сервере Debian 13. Например, на первом можно изучать создание Интернет Магазина, а на втором создание Личного Блога. По аналогии вы можете создать третий и четвертый экземпляр.

📝Установка двух экземпляров WordPress на Nginx

👉В предыдущей статье я описал установку двух экземпляров WordPress на Apache2. В этой всё тоже самое, установка на Debian 13, но вместо Apache 2 будем использовать Nginx.

📝Недавно писал статью про Cloud-Init в Proxmox VE - https://sysadminium.ru/pve-template-and-cloud-init/

👉При работе с шаблонами Debian 13 столкнулся с проблемой: cloud image использует Netplan и systemd-networkd, а DHCP-клиент там по умолчанию идентифицируется не по MAC, а по DUID, который генерируется на основе /etc/machine-id.

👉При клонировании виртуальной машины Proxmox VE меняет MAC, но machine-id у клонов остаётся одинаковым. В результате DHCP-сервер выдаёт всем клонам один и тот же IP-адрес.

👉Сначала я попробовал удалять: /etc/machine-id и /var/lib/dbus/machine-id. Но сеть стартовала раньше, чем systemd успевал создать новый machine-id, и VM вообще не получала IP.

💡Решение — заставить DHCP-клиент использовать MAC вместо DUID. Для этого в /etc/netplan/50-cloud-init.yaml нужно добавить - dhcp-identifier: mac.

network:
  version: 2
  ethernets:
    eth0:
      match:
        macaddress: "bc:24:11:df:93:17"
      dhcp4: true
      dhcp-identifier: mac
      set-name: "eth0"

Перед превращением VM в шаблон выполнил:

cloud-init clean --logs
truncate -s 0 /etc/machine-id
shutdown -h now

После этого каждый клон начал получать свой IP.