📝В этой статье описывается установка сервера хранения паролей и секретов 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.

📝Fwknop - современный port knocking для Linux

👉fwknop реализует схему авторизации, известную как Single Packet Authorization (SPA), для надежной защиты сервисов. Для авторизации SPA требуется всего один зашифрованный пакет, который невозможно воспроизвести повторно и который проходит аутентификацию с помощью HMAC.

👉Любая информационная система, будь то домашний NAS, корпоративный Active Directory или облачная инфраструктура, ежедневно отвечает на два простых вопроса: «Кто вы?» и «Что вам разрешено делать?». За этими вопросами стоит - контроль доступа.

👉Можно выделить 3 слоя в безопасности систем:
- Разграничение сети - подсети, VLAN и файрволлы создают периметры безопасности.
- Шифрование - позволяет защитить данные от кражи.
- Контроль доступа - это механизмы аутентификации, авторизации и аудита действий пользователей.

👉Контроль доступа важен не только для безопасности, но и для бизнеса. Правильно настроенные права напрямую влияют на работу компании, ускоряя доступ к нужным сервисам и снижая риск выполнения запрещённых действий обычными пользователями или злоумышленниками.

🐧 Не редактируй системные юниты (systemd) напрямую!

Файлы в /usr/lib/systemd/system/ (поставляемые пакетами) перезаписываются при apt upgrade, а ручное копирование в /etc/systemd/system/ ломает прозрачность обновлений.

✅ Правильный подход:

sudo systemctl edit <сервис>

Команда создаст drop-in файл override.conf в /etc/systemd/system/<имя>.d/. Пишите только те директивы, которые нужно изменить.

🔧 Важный нюанс:
При переопределении ExecStart, ExecReload или ExecStop сначала сбросьте значение пустой строкой, иначе новые команды добавятся к старым:

ExecStart=
ExecStart=<новая команда>

🛡 Полезные команды:
- systemctl cat <сервис> — увидеть итоговый конфиг
- sudo systemctl revert <сервис> — мгновенно откатить все правки
- sudo systemctl daemon-reload && sudo systemctl restart <сервис> — применить

💡 Метод официален, безопасен при обновлениях и работает в Debian 13 из коробки. Сохраняйте в закладки.

⚡️ Как быстро проверить реальные права доступа в Windows

Знакомая ситуация? 👤
Пользователь в нужной группе, права вроде выданы, а доступа всё равно нет.

Обычно проблема в том, что Windows проверяет сразу 2 уровня прав:

🔹 Share permissions — права SMB-шары
🔹 NTFS permissions — права файловой системы

👉 Итоговый доступ = пересечение обоих наборов прав.
Если где-то есть ограничение — пользователь его получит.

👇Продолжение