В этой статье я покажу процесс установки и настройки простого файлового сервера Samba на сервере Debian 13.

👉Добавим корзину на сервере, настроим аудит доступа к файлам.

👉Также покажу подключение к серверу с Windows и Linux клиентов.

📝Подсистема ввода вывода в Windows

Работает в режиме ядра. Основные компоненты:
- Диспетчер ввода / вывода. Связывает приложения с устройствами.
- Диспетчер PnP. Загружает драйверы при подключении устройств.
- Диспетчер электропитания. Управляет переходами оборудования в разные состояния энергосбережения.

Каждое устройство в системе получает свой номер прерывания (IRQ). Посмотреть список IRQ можно в "Сведения о системе" (Аппаратные ресурсы / Прерывания (IRQ).

Суть прерываний в следующем. Процессор занят задачей → устройство посылает сигнал (например, мы подвинули мышку) → процессор запускает обработчик прерывания (ISR) → возвращается к задаче.

Это позволяет эффективно совмещать вычисления и операции ввода-вывода.

📝Кто открыл файл в общей папке Windows

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

🔎Чтобы найти того, кто уже редактирует этот файл используем mmc.exe (на файловом сервере). Выбираем оснастку "Общие папки". Прямой запуск оснастки "Общие папки":

fsmgmt.msc

В этой оснастке переходим в меню "Открытые файлы", и там находим нужный файл. Здесь же видим кто его открыл. А для того чтобы его закрыть нужно щелкнуть по нему правой кнопкой мышки и выбрать "Закрыть открытый файл".

То есть вы, как администратор, можете закрыть этот файл, но лучше связаться с пользователем и попросить сохранить и закрыть файл самостоятельно.

📌В этой статье разбираемся с NFS сервером на LInux. Установим NFS сервер на Debian 13, создадим общий каталог и примонтируем его на другом сервере по сети.

👉NFS (Network File System) — это сетевая файловая система с открытым исходным кодом для Linux, реализующая одноимённый протокол. Она позволяет Linux-серверу предоставлять общий доступ к файлам и директориям для клиентов по сети. Наиболее часто используется в среде Linux и Unix-подобных систем, тогда как для подключения из Windows требуется установка отдельного NFS-клиента. Продукт распространяется под лицензией GPL.

📌В этой статье я покажу как создать FTPS сервер на Linux (Debian 13) с отдельными каталогами для разных пользователей.

👉В этой статье я покажу процесс подготовки FTPS сервера на Linux, при этом каждый пользователь будет видеть только свой каталог.

📝 Ключи репозиториев в Linux (APT)

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

👉 Ключи официальных репозиториев дистрибутива уже предустановленны. Ключи сторонних репозиториев нужно добавлять вручную.

👉 Раньше ключи добавляли в глобальное хранилище /etc/apt/trusted.gpg с помощью команды apt-key add.
⚠️ Сейчас этот метод устарел и небезопасен, так как ключ получает доверие ко всем репозиториям сразу.

👉 В новых системах используется изолированное доверие: каждый репозиторий использует свой ключ.
- Ключи хранятся в каталоге /etc/apt/keyrings/.
- Файлам дают понятные имена, например: vendor-archive-keyring.gpg.
- Ключи часто поставляются в текстовом формате (ASCII armored), но рекомендуется хранить их в бинарном формате (dearmor). Конвертация выполняется через gpg --dearmor.

👉 В файле списка источников (/etc/apt/sources.list.d/...) нужно явно указать путь к ключу через опцию signed-by:

deb [signed-by=/etc/apt/keyrings/vendor-archive-keyring.gpg] ...

👉 Команда для скачивания, конвертации и установки ключа:

curl -fsSL repo.example.com/key.gpg | \
  sudo gpg --dearmor -o /etc/apt/keyrings/vendor-archive-keyring.gpg

- Если директории /etc/apt/keyrings/ не существует, предварительно создайте её.

📝Бесплатные утилиты для Windows

⭐️Анализ ошибок
- BlueScreenView — бесплатная утилита от NirSoft. Показывает список всех файлов дампа памяти, созданных при BSOD. Предоставляет информацию о коде ошибки, драйверах или модулях, которые могли вызвать сбой.

⭐️Исследование работы сети
- Advanced IP Scanner – простая в использовании утилита для анализа локальных сетей.
- WinMTR — утилита позволяющая отследить трассировку данных между клиентской машиной и сервером для дальнейшей диагностики сетевых соединений.

⭐️Наблюдением за дисками
- Free disk analyzer — помогает определить самые большие файлы и каталоги на вашем диске.
- Tree Size Free — также, позволяет вычислить самые большие каталоги и файлы.
- CrystalDiskInfo — утилита позволяет считать S.M.A.R.T. данные с диска, а также ведёт постоянный контроль за температурой диска.

⭐️Железо и наблюдение за датчиками
- CPU-Z — бесплатная программа, которая собирает информацию о некоторых основных устройствах вашей системы.
- HWMonitor — утилита считывает основные датчики оборудования: напряжение, температуру, скорость вращения вентиляторов, тактовую частоту.

⭐️Подключения к серверам
- WinSCP — графический клиент SFTP для Windows с открытым исходным кодом.
- FileZilla — бесплатный FTP клиент.
- Bitvise SSH Client — бесплатный SSH клиент для Windows.
- PuTTY — бесплатный SSH клиент, с открытым исходным кодом.

⭐️Создание ISO или запись их на USB-флешку
- ImgBurn – утилита для работы с образами дисков.
- Rufus – утилита для создания загрузочных USB-носителей.
- Ventoy — удобная утилита, которая позволяет загружать несколько ISO с одной флешки без их распаковки.

⭐️Создание заметок
- Obsidian — утилита для создания личных заметок. Хранит заметки в отдельных текстовых файлах в формате md. Позволяет создавать связи между заметками формируя сеть знаний.

📌Недавно познакомился с утилитой ioping, думаю она многим уже знакома.

Эта утилита позволяет легко проверить производительность дисковой подсистемы. По умолчанию выполняются случайные чтения небольшими блоками (~4 KiB) через page cache.👇

Простой тест (-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-файлами и картинками, поэтому хватит максимально экономичного тарифа хостинга.

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