fonwa

Деплоим HTTP File Server в LXC (NGINX)

2025-11-15T22:16:16.809Z

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

Для Tampermonkey источник обновления указывается прямо в скрипте, а само расширение уже опрашивает этот адрес.

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

Ниже — простой и рабочий способ поднять HTTP-хост под раздачу файлов.

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

Для тех, кто уже трогал Proxmox - ничего сложного.

1. Создаём LXC-контейнер

Debian 12
Unprivileged
Network: Static IP
Specs: 1 CPU / 512 MB RAM / 8 GB Disk — более чем достаточно

После запуска контейнера подключаемся.

2. Установка базовых пакетов

apt update && apt upgrade -y
apt install curl nginx openssh-server -y
# Создаём каталог, в котором будем хранить скрипты
mkdir -p /var/www/updates
# Активируем NGINX
systemctl enable nginx
systemctl start nginx

3. Проверяем работу

curl http://localhost

Если видишь стандартную страницу — всё ок.

4. Настраиваем NGINX

Открываем конфиг

nano /etc/nginx/sites-enabled/default

Меняем несколько строк:

root /var/www/; # оставляем так, если хотим видеть все каталоги в www
# или
# root /var/www/updates;
index index.html;
autoindex on;
autoindex_exact_size off; # опционально, размеры будут показываться в MB / KB / GB
autoindex_localtime on; # опционально, вывод будет в твоей локальной тайм-зоне

Сохраняем и выходим.

Перезапускаем nginx:

systemctl restart nginx

5. Настраиваем доступ по SSH/SCP

Открываем конфиг SSH:

nano /etc/ssh/sshd_config

Нужно раскомментировать или добавить следующие строчки:

PasswordAuthentication yes
PermitRootLogin yes

Сохраняем и перезапускаем ssh:

systemctl restart ssh

Если сервис доступен только внутри локальной сети, это допустимо.
В публичных сетях лучше переключить на SSH-ключи.

6. Загружаем файлы

Можно через scp

scp /Users/fonwa/script.js root@192.168.1.x:/var/www/updates

Или через любой SFTP-клиент

В GUI-клиент сохраняем хост, подключаемся, просто перетягиваем файлы в /var/www/updates.

7. Проверяем

На этом этапе ресурс уже доступен в локальной сети по IP-адресу контейнера.

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

Если нужно локально прикрутить доменное имя — ранее я рассказывал, как можно настроить домашний DNS.

А если хочется завернуть трафик в HTTPS и опубликовать - это легко делается через Nginx Proxy Manager.

Настраиваем Nginx Proxy Manager для NUT

2025-06-03T19:21:28.452Z

Если вы используете NUT для мониторинга источников бесперебойного питания (ИБП), то наверняка сталкивались с необходимостью организовать доступ к веб-интерфейсу через удобный домен. Мы разберем, как это сделать простым и понятным способом через Nginx Proxy Manager.

Зачем нужен Nginx Proxy Manager для NUT?

Веб-интерфейс NUT работает через CGI-скрипты (например, upsstats.cgi и upsimage.cgi), и это было основной проблемой при настройке Nginx. Эти скрипты могут быть доступны только по локальному адресу (например, http://192.168.1.8/cgi-bin/nut/upsstats.cgi). Далее мы рассмотрим, как сделать их доступными через удобное доменное имя (например, nut.home.local) и защитить соединение через HTTPS.

Подготовка сервера NUT

Перед настройкой Nginx Proxy Manager убедитесь, что:

Установлен и настроен NUT.
В NPM добавлен SSL сертификат - самоподписанный или Let's Encrypt.
Локальный DNS знает доменное имя nut.home.local и на какой IP перенаправлять запросы.
Эти скрипты доступны напрямую по IP адресу, например:
http://192.168.1.8/cgi-bin/nut/upsstats.cgi

Настройка Nginx Proxy Manager

Теперь перейдем к самому интересному — настройке Nginx Proxy Manager.

Создаем новый прокси-хост

Открываем веб-интерфейс Nginx Proxy Manager.
Создаем новый прокси-хост:

Domain Names : nut.home.local
Scheme : https
Forward Hostname/IP : 192.168.1.8
Forward Port : 80

Добавляем Custom Locations

Чтобы все запросы работали корректно, добавляем следующие правила:

Правило 1: Корневой путь

Location : /
Scheme : http
Forward Hostname/IP : 192.168.1.8/cgi-bin/nut/upsstats.cgi
Forward Port : 80

Это правило перенаправляет все запросы к корню (/) на основной скрипт upsstats.cgi.

Правило 2: Путь для `upsstats.cgi`

Location : /upsstats.cgi
Scheme : http
Forward Hostname/IP : 192.168.1.8/cgi-bin/nut/upsstats.cgi
Forward Port : 80

Это правило обрабатывает запросы к https://nut.home.local/upsstats.cgi.

Правило 3: Путь для `upsimage.cgi`

Location : /upsimage.cgi
Scheme : http
Forward Hostname/IP : 192.168.1.8/cgi-bin/nut/upsimage.cgi
Forward Port : 80

Это правило нужно для динамической генерации изображений через upsimage.cgi.

Настройка Advanced

В разделе Advanced добавляем следующие строки:

proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass_request_headers on;
proxy_pass_request_body on;

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

За что отвечает каждая из них:

proxy_set_header Host $host;

Устанавливает заголовок Host в исходящее проксируемое соединение. Обычно это имя хоста, по которому клиент обратился к вашему серверу. Это важно для backend-приложений, которые используют Host для маршрутизации или проверки домена.

proxy_set_header X-Real-IP $remote_addr;

Передаёт реальный IP-адрес клиента в заголовке X-Real-IP. Это позволяет backend-серверу узнать настоящий IP пользователя, а не IP прокси-сервера.

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

Добавляет IP-адрес клиента к цепочке IP-адресов в заголовке X-Forwarded-For. Если запрос уже содержит этот заголовок, то к нему добавляется ещё один IP (адрес клиента, с которым Nginx установил соединение). Это полезно при наличии нескольких прокси на пути запроса, чтобы backend мог видеть всю цепочку адресов.

proxy_set_header X-Forwarded-Proto $scheme;

Указывает протокол (http или https), по которому клиент обратился к прокси. Это важно для backend-приложений, которые должны знать, был ли исходный запрос защищённым (https) или нет.

proxy_pass_request_headers on;

Включает передачу всех заголовков, полученных от клиента, на backend-сервер. По умолчанию Nginx передаёт только стандартные заголовки, а с этой опцией — все, включая кастомные.

proxy_pass_request_body on;

Включает передачу тела запроса (например, данных POST) на backend-сервер. Обычно это включено по умолчанию, но явное указание гарантирует, что тело запроса не будет отброшено.

Проверка работы

Открываем браузер и переходим по адресу:
https://nut.home.local
Убеждаемся, что страница загружается корректно.
Проверяем, отображаются ли изображения (например, график заряда батареи).

Теперь вы знаете, как настроить Nginx Proxy Manager для работы с NUT. Благодаря этому вы сможете:

Получить доступ к веб-интерфейсу NUT через удобное доменное имя.
Защитить соединение через HTTPS.
Автоматически перенаправлять запросы к нужным CGI-скриптам.

NGINX Proxy Manager

2025-05-30T21:36:38.680Z

Раньше я знал все свои IP-адреса наизусть. Теперь я по FQDN, и только мама зовёт меня по имени.

Если вы только начинаете осваивать маршрутизацию трафика или хотите удобно управлять несколькими сайтами на одном IP — эта статья для вас. Сегодня поговорим о NGINX Proxy Manager, который делает управление Nginx простым и понятным даже без глубоких знаний.

Что такое NGINX Proxy Manager?

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

Работает как Docker-образ, то есть его легко запустить и настроить. Всё уже собрано — просто стартуем контейнер и заходим в интерфейс через браузер.

Зачем он нужен?

Допустим, у вас есть несколько сайтов/сервисов, которые крутятся в разных контейнерах/ВМ. У всех свои IP адреса и порты. Запомнить довольно сложно, когда вываливается такой список, как ниже.

Все они ведут на один внешний IP-адрес вашего сервера. И вот тут NGINX Proxy Manager берёт на себя задачу смотреть на заголовок запроса (Host) и отправлять пользователя куда нужно — на нужный сервер, контейнер или виртуальную машину внутри вашей сети.

Кроме этого:

Поддерживает HTTPS (можно автоматически получать сертификаты Let's Encrypt).
Позволяет настраивать доступ по спискам разрешённых/запрещённых IP.
Есть аудит действий пользователей и система ролей.

Устанавливаем NPM

Подготовка среды

Мы будем использовать Ubuntu 22.04 LTS (можно и другие ОС, но пример на Ubuntu).
Нам понадобятся:
- 2 ядра процессора
- 1 ГБ оперативной памяти
- 10 ГБ дискового пространства

Обновляем систему и устанавливаем Docker:

sudo apt update && sudo apt upgrade -y
sudo apt install -y docker.io docker-compose

Создаём файл docker-compose.yml

nano docker-compose.yaml

Копируем и сохраняем

version: "3"
services:
  nginx-proxy-manager:
    image: 'jc21/nginx-proxy-manager:latest'
    restart: unless-stopped
    ports:
      - '80:80' # HTTP port
      - '443:443' # HTTPS port
      - '81:81' # Admin web port
    volumes:
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt

Запускаем контейнер:

docker-compose up -d

Через пару минут можно открыть браузер и перейти по адресу:
http://IP_адрес_хоста:81

Логин по умолчанию:
Email - admin@example.com
Пароль - changeme

При первом входе сервис предложит создать нового администратора и поменять пароль — обязательно сделайте это.

Настраиваем

Добавляем сертификат.

В моём случае, был сгенерирован самоподписанный SSL сертификат, который добавлен в корневые сертификаты на доверенные устройства в сети.

Переходим в SSL Certificates -> Add SSL Certificate -> Custom.

Указываем Name, прикрепляем Certificate Key и Certificate -> Save.

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

Сертификат появится в интерфейсе

Добавляем хост

Переходим в раздел Proxy Hosts → Add Proxy Host.

Во вкладке Details указываем:

Domain Names - доменное имя хоста

Scheme- http/s

Forward Hostname / IP - адрес хоста.

То есть, даже если мы выбираем Scheme - http, NGINX заворачивает его в SSL терминацию и мы ходим по https, так как браузер обращается в системное хранилище сертификатов

Во вкладке SSL выбираем ранее добавленный SSL Certificate.

Включаем все тумблеры и читаем дальше почему.

Force SSL

Принудительно перенаправляет все HTTP-запросы на HTTPS. Если пользователь попытается открыть сайт по протоколу http, его автоматически перенаправит на https, обеспечивая защищённое соединение.

HTTP/2 Support

Включает поддержку протокола HTTP/2 для данного домена. HTTP/2 ускоряет загрузку сайтов за счёт мультиплексирования запросов, более эффективной компрессии заголовков и других улучшений, но работает только поверх HTTPS.

HSTS Enabled

Включает HTTP Strict Transport Security (HSTS) — механизм, который сообщает браузеру, что сайт всегда должен открываться только по HTTPS. Даже если пользователь наберёт http, браузер сам заменит протокол на https до отправки запроса. Это защищает от атак типа “downgrade” и перехвата трафика.

HSTS Subdomains

Расширяет действие политики HSTS на все поддомены выбранного домена. Например, если включено для home.local, то и для *.home.local браузер будет использовать только HTTPS.

Сохраняем — и сайт будет доступен по вашему домену.

Однако, важно:

DNS-запись вашего домена должна указывать на IP-адрес, где работает NGINX Proxy Manager. Для этого рекомендуется развернуть локальный DNS-сервер, например, AdGuard Home, который поддерживает функцию перезаписи DNS-запросов.

Просто развернуть только Nginx Proxy Manager для перенаправления запросов в локальной сети недостаточно, потому что по умолчанию ваш роутер не знает о существовании такого доменного имени. В результате браузер будет пытаться найти этот адрес во внешнем интернете, а не внутри вашей сети. Рекомендую посмотреть видеоролик “Процесс загрузки web страницы” или "Что делает браузер, чтобы загрузить Веб-страницу?" — это поможет лучше понять процесс.

Решение:
Разверните локальный DNS-сервер и укажите его в качестве дополнительного DNS-сервера в настройках вашего роутера. После этого все устройства в вашей локальной сети смогут обращаться к локальным доменным именам, и изменения вступят в силу автоматически.

Немного теории

Как работает SSL-терминация

Если вы выбираете использование SSL-сертификата (даже если Scheme выбран как http), NPM настраивает так называемую SSL-терминацию:

Внешний клиент (браузер) подключается к вашему серверу по HTTPS.
Nginx принимает зашифрованный трафик, расшифровывает его с помощью SSL-сертификата, и далее передаёт уже расшифрованный HTTP-трафик на внутренний сервер (по указанному IP и порту).
Таким образом, внутренний сервис может работать по обычному HTTP, а пользователи снаружи всегда используют защищённое HTTPS-соединение.

Это стандартная практика для обратных прокси и называется SSL-терминацией (SSL termination):

SSL-терминация является процессом на обратном прокси сервере, который обрабатывает шифрование и дешифровку SSL таким образом, чтобы трафик между прокси и внутренними серверами был в HTTP.

Что происходит в браузере

Браузер пользователя устанавливает HTTPS-соединение с Nginx Proxy Manager.
При этом браузер проверяет SSL-сертификат, который хранится в системном хранилище сертификатов (или добавлен вручную, если это self-signed или локальный CA).

Полезные фишки

Статистика и мониторинг

Если хочется видеть нагрузку, количество запросов, ошибки и прочее — можно добавить в `docker-compose` ещё один сервис для анализа логов:

npm-monitoring:
  image: xavierh/goaccess-for-nginxproxymanager:latest
  restart: always
  environment:
    - TZ=Asia/Yekaterinburg
    - LOG_TYPE=NPM
  ports:
    - '82:7880'
  volumes:
    - ./data/logs:/opt/log

Открываете http://IP_адрес_хоста:82 и видите красивую статистику по трафику.

Кастомная страница 404

Вместо скучного сообщения об ошибке можно сделать весёлый редирект. Например, на видео с котиками или... на Rickroll 😄

Добавляем в `docker-compose`:

error-page-404:
  image: 'kale5/rickroll:latest'
  restart: unless-stopped
  ports:
    - '83:80'

А в настройках NGINX Proxy Manager указываем редирект на `http://localhost:83`.

Финальный `docker-compose.yml`

version: "3"
services:
  nginx-proxy-manager:
    image: 'jc21/nginx-proxy-manager:latest'
    restart: unless-stopped
    ports:
      - '80:80'
      - '443:443'
      - '81:81'
    volumes:
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt
  npm-monitoring:
    image: xavierh/goaccess-for-nginxproxymanager:latest
    restart: always
    environment:
      - TZ=Asia/Yekaterinburg
      - LOG_TYPE=NPM
    ports:
      - '82:7880'
    volumes:
      - ./data/logs:/opt/log
  error-page-404:
    image: 'kale5/rickroll:latest'
    restart: unless-stopped
    ports:
      - '83:80'

NGINX Proxy Manager — это отличный выбор для тех, кто хочет быстро поднять reverse proxy без головной боли. Он простой, удобный, поддерживает HTTPS «из коробки» и позволяет настраивать всё через веб-интерфейс.

Мне помогли:

https://akmalov.com/blog/nginx-proxy-manager

Glances в Proxmox и экспорт в Grafana

2025-05-29T21:54:28.949Z

Случайно наткнулся на проект и захотелось им поделиться.

Glances - это кроссплатформенный инструмент для мониторинга системных ресурсов, работающий в терминале и написанный на Python. Основная задача Glances - предоставлять максимально полную информацию о состоянии системы на одном экране в режиме реального времени, что делает его удобным для администрирования серверов и рабочих станций.

Полученные метрики из Glances можно экспортировать в CSV, InfluxDB, Cassandra, OpenTSDB, StatsD, ElasticSearch или даже RabbitMQ. Glances также предоставляет специальную панель мониторинга Grafana.

Тезисно, этакий динамический htop в браузере с возможностью экспорта куда угодно

Устанавливаем змею

apt update && apt install python3-pip python3-dev gcc pipx curl -y

Устанавливаем Glances в pipx

pipx install glances[web]

Если все предыдущие команды выполнялись из домашнего каталога, то явный путь для запуска Glances будет:
/root/.local/bin/glances -w

Добавим в переменную окружения PATH из домашнего каталога

pipx ensurepath

После потребуется рестарт хоста

reboot

Проверяем, что путь добавлен

echo $PATH
which glances

Запускаем процесс

glances -w

Открываем веб интерфейс Glances с указанным хосту IP адреса с портом 61208. Должно получиться http://IP_адрес_хоста:61208

Настраиваем сервис Glances

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

nano /etc/systemd/system/glances.service

Копируем. Вставляем содержимое и сохраняем.

Я делал от рута, поэтому у меня всё просто

[Unit]
Description=Glances - web-based monitoring
After=network.target

[Service]
ExecStart=/root/.local/bin/glances -w
Restart=always
User=root
Environment=PATH=/root/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

[Install]
WantedBy=multi-user.target

Перезапускаем сервисы

systemctl daemon-reexec
systemctl daemon-reload
systemctl enable --now glances
systemctl status glances

Glances запущен, и теперь можно открывать его через web или экспортировать в другие сервисы.

Устанавливаем InfluxDB

curl -LO https://download.influxdata.com/influxdb/releases/influxdb2_2.7.6-1_amd64.deb
sudo dpkg -i influxdb2_2.7.6-1_amd64.deb
sudo service influxdb start

Настраиваем InfluxDB

Настраиваем экспорт в InfluxDB

Так можно найти, где находится glances.conf

find / -type f -name "glances.conf"

Настройка конфигурации (путь к файлу может отличаться):

nano /root/.local/share/pipx/venvs/glances/share/doc/glances/glances.conf

Прокручиваем вниз до:

[influxdb2]
host=localhost
port=8086
protocol=http
org=fonwa
bucket=glances
token=токен, полученный из influxDB
measurement=localhost

Лайфхак - чтобы скролить длинные конфиги, подключайся через SSH и двигай колесо.

Правим и сохраняемся

Установка клиента InfluxDB:

pipx inject glances influxdb-client

Проверяем через консоль экспорт

glances --export influxdb2

Если метрики отправляются и ошибок нет — переходим к следующему шагу.

Проверяем путь к Glances:

which glances

(вставьте его в ExecStart, если он отличается)

sudo nano /etc/systemd/system/glances-influxdb.service

Копируем содержимое и сохраняем

[Unit]
Description=Glances system monitor with InfluxDB 2.x export
After=network.target

[Service]
ExecStart=/root/.local/bin/glances --export influxdb2
Restart=always
User=root

[Install]
WantedBy=multi-user.target

Перезапускаем сервисы

sudo systemctl daemon-reexec
sudo systemctl daemon-reload
sudo systemctl enable glances-influxdb
sudo systemctl start glances-influxdb
systemctl status glances-influxdb.service

Добавляем дашборд в Grafana

Выбираем Data Sources -> Add new data source.

Находим InfluxDB

Query Language - Flux

URL - http://IP_вашего_хоста:8086

User - указанный вами логин в Influx

Password - токен из Influx

Organization - организация из influx

Token - токен из Influx

Выбираем в самом низу Save & Test

Переходим в Dashboard -> New -> Import

Копируем JSON отсюда -> Load

Выбираем в нижнем выпадающем поле Influxdb -> Import

Дашборд готов и работает. Даже после перезагрузки хоста.

Добавляем Glances в GetHomePage

Для добавления в GetHomePage в хеддер нужно поправить widgets.yaml

nano /path/to/config/widgets.yaml

- glances:
    url: http://IP_вашего_хоста:61208
    version: 4 # required only if running glances v4 or higher, defaults to 3
    cpu: true # optional, enabled by default, disable by setting to false
    mem: true # optional, enabled by default, disable by setting to false
    cputemp: true # disabled by default
    uptime: true # disabled by default
    disk: / # disabled by default, use mount point of disk(s) in glances. Can also be a list (see below)
    diskUnits: bytes # optional, bytes (default) or bbytes. Only applies to disk
    expanded: true # show the expanded view

Мне помогли:

https://github.com/nicolargo/glances

https://github.com/nicolargo/glances/blob/develop/conf/glances-grafana-influxql.json

https://habr.com/ru/companies/vdsina/articles/545274/

Локальный DNS-сервер с AdGuard Home

2025-04-30T23:36:30.874Z

Adguard Home - это Github Open Source проект с открытым исходным кодом.

В этой статье разберём, как быстро и просто поднять собственный DNS-сервер в AdGuard Home, чтобы забыть о рекламе и получить полный контроль над интернет-трафиком в нашей сети. В нем так же возможно настроить DHCP, блокировать часть рекламного контента, устанавливать и настраивать различные фильтры. Всё будет работать через Docker Compose. Подходит для виртуалок, выделенных серверов и мини-ПК вроде Raspberry Pi.

Я же для себя выбрал его как дополнительный DNS сервер, с которого удобнее назначать устройствам в сети FQDN имена, чем например с роутера в cli:

ip host adg.home.local 192.168.1.11
system configuration save

Готовим площадку: минимальные требования

Установка будет проходить в LXC-контейнере на Proxmox, но подойдёт любая машина с Ubuntu 22.04 (или новее).
Минимальные ресурсы:
• ОС: Ubuntu 22.04
• CPU: 2 ядра
• RAM: 1 ГБ
• Диск: 10 ГБ

Обновляем систему и ставим Docker:

apt update && apt upgrade -y
apt install -y curl
curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh

Настраиваем docker-compose.yml

Создаем файл

nano docker-compose.yml

Копируем содержимое для docker-compose.yml

version: "3.8"
services:
 adguardhome:
 image: adguard/adguardhome:latest
 hostname: adguard
 volumes:
 - ./adguard/work:/opt/adguardhome/work
 - ./adguard/conf:/opt/adguardhome/conf
 ports:
 - 53:53/tcp
 - 53:53/udp
 - 80:80/tcp
 - 443:443/tcp
 - 443:443/udp
 - 3000:3000/tcp
 restart: unless-stopped

Вносим изменения, сохраняемся и выходим.

Описание используемых портов:

53/tcp 53/udp - для работы DNS сервера.
67/udp 68/tcp 68/udp - для работы DHCP сервера
80/tcp 443/tcp 443/udp 3000/tcp - для доступа к Web панели и работы в режиме HTTPS/DNS-over-HTTPS
853/tcp - для работы в режиме DNS-over-TLS
784/udp 853/udp 8853/udp - для DNS-over-QUIC
5443/tcp 5443/udp - для DNSCrypt

DHCP, DNS-over-QUIC и DNSCrypt я не использовал - соответствующие порты не пробрасываем для безопасности и экономии ресурсов.

Освобождаем порт 53

Если при запуске контейнера видите ошибку:

Error starting userland proxy: listen tcp4 0.0.0.0:53: bind: address already in use

Значит порт 53 уже занят (обычно это systemd-resolve).

Проверяем, кто занял порт:

lsof -i :53

Отключаем DNSStubListener

Открываем файл:

nano /etc/systemd/resolved.conf

В секции [Resolve] прописываем:

DNS=127.0.0.1
DNSStubListener=no

Сохраняем и перезапускаем службу:

systemctl restart systemd-resolved.service

Запускаем AdGuard Home

Теперь запускаем контейнер:

docker compose up -d

Первичная настройка AdGuard Home

Открываем браузер и идём по адресу:
http://<IP-адрес вашего сервера>:3000/
• Придумываем логин и пароль для панели управления.
• Следуем инструкции мастера установки.
• После завершения попадаем в основное меню.

У меня все настройки по умолчанию.

Меняем основной DNS на роутере

Тут я лишь могу показать на примере своего роутера Keenetic.

В настройках Мои Сети и WiFi - Домашняя сеть нужно указать DNS AdGuard.

Не забываем перед этим указать ему статику. У меня это 192.168.10.11

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

Теперь весь трафик домашних устройств будет проходить через AdGuard Home. Устройства в сети автоматически определят этот DNS.

Настраиваем фильтрацию рекламы

Фильтры - Черные списки DNS.

Добавляем чёрные списки - это основной инструмент для блокировки рекламы и вредоносных сайтов.

Все фильтры находятся в Добавить черный список - Выбрать из списка.

Я же добавил эти:

AdGuard DNS filter
AdAway Default Blocklist
1Hosts (Lite)
AdGuard DNS Popup Hosts filter
AWAvenue Ads Rule
OISD Blocklist Big

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

Upstream DNS-серверы

Настройки - Настройки DNS - Upstream DNS-серверы.

Необходимо указать тип DNS over HTTPS. Их можно взять тут.

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

Не рекомендую прописывать великое множество. Разные DNS могут давать разные CDN/IP. Часть запросов уходит во много мест. Сложнее отлаживать. Может быть нестабильность по гео/CDN. Добавьте несколько на свое усмотрение, после смотрите на главной странице Среднее время ответа upstream-сервера. Выбирайте с наименьшим пингом.

Я установил такие:

https://common.dot.dns.yandex.net/dns-query
tls://common.dot.dns.yandex.net
https://dns.comss.one/dns-query
https://dns.google/dns-query
https://freedns.controld.com/p0

Проверяем работоспособность через кнопку TEST Upstream - если ошибок нет, всё работает корректно.

Bootstrap DNS

Оставил только такие , без IPv6.

1.1.1.1
8.8.8.8
77.88.8.8
9.9.9.10

Перезапись DNS-запросов

Собственно, ради чего я это всё затеял.

Фильтры - Перезапись DNS-запросов.

Добавляем записи. У меня большая часть ведет через локальный обратный прокси Nginx Proxy Manager (192.168.1.88), на котором уже указаны статические адреса хостов с самоподписанным сертификатом home.local и на которые хожу по HTTPS.

AdGuard так же прописан в NPM.

Даже не имея сертификата, можно указать любое имя, например phanteks.pc

Можно сразу пингануть этот хост

Либо подключиться к нему по RDP

Проверяем работу фильтров

Для проверки DoH использу сервис Cloudflare - https://1.1.1.1/help

Для теста блокировки рекламы - https://checkadblock.ru

Больше радует что в черные списки попадают сервисы сбора метрик и блокируется это наглядно. Можно увидеть в статистике главной панели.

Где видно как Phanteks активно пытается отправлять телеметрию в Microsoft, но их блокирует Adguard.

Дополнительные настройки

Тонкая настройка клиентов - создавайте группы с разными правилами, управляйте белыми и чёрными списками, блокируйте контент 18+.
Быстрая блокировка популярных сервисов - одним кликом можно ограничить доступ к соцсетям, мессенджерам и другим отвлекающим ресурсам.
Статистика - на главной панели видно, какие устройства чаще всего обращаются к DNS и что именно блокируется.

Блокировка сервисов

Позволяет быстро заблокировать популярные сайты и сервисы.

Итоги

AdGuard Home - мощный и удобный инструмент для домашнего и офисного использования. Простая установка, гибкая настройка, наглядная статистика и возможность блокировать рекламу на всех устройствах без лишних танцев с бубном. Подходит даже для образовательных учреждений и малого бизнеса.
Собственный DNS - это не только про блокировку рекламы, но и про приватность, контроль и безопасность вашей сети.

Мне помогли:

https://akmalov.com/blog/adguard-home

Самоподписанный SSL сертификат для внутреннего использования

2025-04-29T08:02:08.750Z

Шифрование данных стало неотъемлемой частью современного интернета. Практически весь трафик передается через защищенное HTTPS-соединение, а сайты без шифрования встречаются крайне редко и автоматически помечаются браузерами как небезопасные.

Несмотря на предупреждения браузеров о "непроверенных" сертификатах, само шифрование работает корректно. Использование бесплатных сертификатов Lets Encrypt для домашней сети связано со множеством сложностей и затрат:

Покупка домена
Скрытие персональных данных
Настройка DNS-хостинга
Статический IP или DDNS
Проброс портов
Регулярное обновление каждые 3 месяца

Поэтому для внутренней сети оптимальным решением являются самоподписанные сертификаты, а Lets Encrypt лучше оставить для внешних сервисов.

Как оказалось, создание SSL-сертификатов – это проще, чем кажется. Достаточно одной команды:

openssl req -x509 -newkey rsa:4096 -sha256 -days 3650 -nodes \
-keyout homelocal.key -out homelocal.crt -subj "/CN=home.local" \
-addext "subjectAltName=DNS:home.local"

Эта команда создаст:

Файл ключа (homelocal.key)
Файл сертификата (homelocal.crt)
Срок действия: 10 лет
Уровень шифрования (rsa:4096, sha256)

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

Для удобства управления рекомендуется использовать один домен для всей домашней сети (например, home.local) и размещать сервисы на поддоменах:

pve.home.local
npm.home.local
adg.home.local
nut.home.local
etc

Чтобы ходить по данным именам, необходимо:

1. Развернуть 2 сервиса:

DNS - у меня это Adguard Home, который добавлен на роутере как дополнительный DNS.
Nginx - у меня это Nginx Proxy Manager, в который добавлен сертификат.

2. Добавить созданный сертификат в Доверенные корневые сертификаты на Windows или в Связку ключей на macOS

Итог: внедрение SSL-сертификатов в домашнюю сеть – простой и эффективный способ защитить данные, который не требует значительных временных и финансовых затрат.

Мне помогли:

https://andrey.dvur.me/posts/selfsigned-cert/

Как переназначить нечитаемый сектор HDD в Proxmox: пошаговая инструкция

2025-03-31T08:14:45.025Z

В предыдущей статье я описывал, как включить получение уведомлений с Proxmox на Gmail, после чего мне прилетело несколько SMART-алертов по одному диску. Попробуем продлить ему жизнь.

Почему важно реагировать на SMART-алерты

SMART-предупреждения (например, о нечитаемых секторах) — серьёзный сигнал о деградации HDD. Это может привести к потере данных, если не предпринять меры. В статье рассмотрим, как диагностировать проблему и принудительно переназначить повреждённый сектор.

Проверка текущего SMART-статуса

Чтобы понять состояние диска, выполняем команду:

smartctl -a /dev/sdd

Ключевые параметры для анализа:

Reallocated_Sector_Ct – количество переназначенных секторов (если растёт, диск умирает).
Current_Pending_Sector – количество секторов, которые ожидают ремапа (если не 0 – диск нестабилен).
Offline_Uncorrectable – количество необратимо повреждённых секторов.

В моём случае (пример):

Current_Pending_Sector = 1 — 1 сектор требует переназначения.
Reallocated_Sector_Ct = 0 — пока нет переназначенных секторов.
Power_On_Hours = 24857 — диск отработал ~2.8 года.

Запуск глубокого SMART-теста

Для подтверждения ошибки выполняем:

smartctl -t long /dev/sdd

Тест занимает несколько часов.
После завершения проверяем результаты.

smartctl -a /dev/sdd

Результаты теста в моем случае:

Ошибка чтения на LBA 4054769360.
Current_Pending_Sector остался равным 1 — проблема подтверждена.

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

Метод 1: Запись нулей в сектор

Принудительно записать данные в проблемный сектор (⚠️ Возможна потеря данных на этом секторе!)

dd if=/dev/zero of=/dev/sdd bs=512 count=1 seek=4054769360

Это заставит диск либо исправить сектор, либо пометить его как сбойный и заменить на резервный.

Однако, в моём случае, не получилось переназначить

dd: error writing '/dev/sdd': Input/output error

Ошибка означает, что диск не смог записать данные в указанный сектор. Это подтверждает, что сектор физически повреждён и диск не способен автоматически заменить его на резервный.

Метод 2: Форсирование ремапа через hdparm

Попробовать форсировать ремап повреждённого сектора:

hdparm --write-sector 4054769360 --yes-i-know-what-i-am-doing /dev/sdd

Этот метод грубо перезаписывает сектор и может привести к его переназначению.

Проверка результата

После исправления повторно запускаем тест и анализируем SMART-параметры:

smartctl -t long /dev/sdd  
smartctl -a /dev/sdd

Обновлённый анализ SMART-статуса

Что изменилось?

✅ Current_Pending_Sector = 0 — сектор либо исправлен, либо переназначен.
✅ Extended offline test завершился без ошибок.
❗ Отслеживайте Multi_Zone_Error_Rate — рост показателя требует внимания.

Итоги и рекомендации

Если проблема решена:

Диск стабилен, но продолжайте мониторить SMART-параметры.
Регулярно запускайте тесты (smartctl -t long).

Если сектор неисправим:

Reallocated_Sector_Ct > 0 — диск начинает «умирать».
Замените его как можно скорее.

Важно:

Не игнорируйте SMART-предупреждения! Даже единичный повреждённый сектор может стать началом более серьёзных проблем.

👉 Подписывайтесь на мой канал для полезных гайдов!

Уведомления Proxmox на Gmail

2025-03-25T18:12:46.769Z

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

Подключаемся по SSH к нашему узлу Proxmox и авторизуемся в системе как пользователь root.

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

apt update 
apt install -y libsasl2-модули mailutils

Включаем двухфакторную аутентификацию для учётной записи Gmail, которая будет использоваться, перейдя в настройки безопасности.

Создаём пароль приложения для своей учетной записи.

Перейти к Паролям приложения.
Введите: Proxmox или то, как собираетесь идентифицировать этот пароль в дальнейшем.
Выбираем Создать.
Сохраняем пароль.

Вводим учётные данные Gmail в файл

Нужно заменить на свои

echo "smtp.gmail.com youremail@gmail.com:yourpassword" > /etc/postfix/sasl_passwd

# chmod u=rw
chmod 600 /etc/postfix/sasl_passwd

# generate /etc/postfix/sasl_passwd.db
postmap hash:/etc/postfix/sasl_passwd

Открываем файл конфигурации Postfix

nano /etc/postfix/main.cf

Добавляем следующее в конец файла:

relayhost = smtp.gmail.com:587
smtp_use_tls = yes
smtp_sasl_auth_enable = yes
smtp_sasl_security_options =
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_tls_CAfile = /etc/ssl/certs/Entrust_Root_Certification_Authority.pem
smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_tls_session_cache
smtp_tls_session_cache_timeout = 3600s

ВАЖНО: закомментируйте существующую строку, содержащую только relayhost=, поскольку мы используем этот ключ в нашей конфигурации, которую мы только что вставили.

Сохраняем и закрываем

Перезагружаем postfix

postfix reload

Протестируйте, чтобы убедиться, что все в порядке, либо создайте бекап любой ВМ.

echo "sample message" | mail -s "sample subject" anotheremail@gmail.com

Мне помогли:

https://gist.github.com/tomdaley92/9315b9326d4589c9652ce0307c9c38a3

Настройка NUT + Proxmox + Synology

2025-03-21T14:04:43.102Z

У меня в Proxmox развернут DSM (XPEnology). Я недавно переехал и сейчас тут периодические проблемы с электричеством, которые у меня ранее не возникали. Приобрел 1 из доступных ИБП - CyberPower UT850EIG c IEC розетками.

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

В целом, как показала практика, любой UPS с USB можно подружить с Proxmox и прокинуть в DSM как ИБП Synology, несмотря на отсутствие поддержки ИБП в списке моделей для Synology.

Суть реализации в настройке NUT сервера и клиента прямо на машине с Proxmox для контроля ИБП и поведения при изменении статуса батарей. Дополнительно же установим LXC контейнер с NUT клиентом и веб-сервером Apache для мониторинга состояния ИБП без использования консоли. В конце добавим ИБП в Synology.

Настройка NUT сервера и клиента на сервере с Proxmox

Заходим в консоль машины, на которой установлен Proxmox (в моем случае версии 8.3.0) и смотрим список usb устройств командой:

lsusb

Нам нужно найти наш ИБП и узнать его bus и device:

Теперь посмотрим детальную информацию, указав bus и device, в моем случае:

lsusb -v -s 3:5

где 3 - шина (bus), 5 - устройство (device)

Как видно, система распознает ИБП и можно приступать к установке nut:

apt install nut -y

Проверяем, видит ли nut наш ИБП:

nut-scanner -U

Перед правкой конфигов, на всякий случай, лучше сделать резервные копии всех этих файлов:

cp /etc/nut/nut.conf /etc/nut/nut.example.conf
cp /etc/nut/ups.conf /etc/nut/ups.example.conf
cp /etc/nut/upsd.conf /etc/nut/upsd.example.conf
cp /etc/nut/upsd.users /etc/nut/upsd.example.users
cp /etc/nut/upsmon.conf /etc/nut/upsmon.example.conf
cp /etc/nut/upssched.conf /etc/nut/upssched.example.conf
cp /bin/upssched-cmd /bin/upssched-cmd.example

Теперь перейдем к правке. Первый на очереди nut.conf:

nano /etc/nut/nut.conf

Удаляем все и добавляем:

MODE=netserver

Далее редактируем ups.conf:

nano /etc/nut/ups.conf

Удаляем все и добавляем:

# pollinterval и maxretry работают вместе для надежного мониторинга
# Определяет частоту опроса состояния ИБП (в секундах)
pollinterval = 15
# Количество попыток повторного подключения к ИБП при потере связи
# Если после 3 попыток связь не восстановится, система считает ИБП недоступным
maxretry = 3

# offdelay и ondelay образуют временную защиту для процессов выключения/включения
# Задержка перед фактическим выключением питания после команды на shutdown (в секундах)
# Это время дается системе на:
#     Корректное завершение работы всех служб
#     Сохранение данных
#     Выполнение процедур очистки
offdelay = 300
# Задержка перед включением питания после восстановления основного электропитания (в секундах)
# Это предотвращает:
#     Многократные циклы включения/выключения при нестабильном питании
#     Слишком быстрое включение до полной стабилизации напряжения
ondelay = 30

[ups]
   driver = usbhid-ups
   port = auto
   desc = "CyberPower UT850EG"
   vendorid = 0764
   productid = 0501
   serial = ""

Обратите внимание, что все данные по своему ИБП я брал из вывода команд, указанных выше. В квадратных скобках имя ups оставляем как есть для Synology.

Необходимо настроить файл ups.conf на сервере NUT, чтобы ИБП назывался «ups». Он не может называться как-то иначе. В противном случае Synology откажется подключаться.

Сохраняем файл и можем протестировать драйвер:

upsdrvctl start

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

Отредактируем upsd.conf:

nano /etc/nut/upsd.conf

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

LISTEN 0.0.0.0 3493
LISTEN :: 3493

Далее редактируем upsd.users:

nano /etc/nut/upsd.users

Настроим администратора и пользователя. Удаляем все и добавляем:

[upsadmin]
# Administrative user
password = ********
# Allow changing values of certain variables in the UPS.
actions = SET
# Allow setting the "Forced Shutdown" flag in the UPS.
actions = FSD
# Allow all instant commands
instcmds = ALL
upsmon master

[upsuser]
# Normal user
password = ********
upsmon slave

[monuser]
# DSM user
password = secret
admin slave

Нужно создать пользователя на сервере NUT (в uspd.users) с именем «admin» и паролем «secret». Я безуспешно пытался подключить Synology к серверу NUT, используя менее очевидное имя пользователя и сложный пароль, но безрезультатно.

Замените звездочки на ваши пароли.

Редактируем upsmon.conf:

nano /etc/nut/upsmon.conf

Удаляем все и добавляем:

RUN_AS_USER root
MONITOR ups@localhost 1 upsadmin ******* master

MINSUPPLIES 1
SHUTDOWNCMD "/sbin/shutdown -h now"
NOTIFYCMD /usr/sbin/upssched
POLLFREQ 4
POLLFREQALERT 2
HOSTSYNC 15
DEADTIME 24
MAXAGE 24
POWERDOWNFLAG /etc/killpower

NOTIFYMSG ONLINE "UPS %s on line power"
NOTIFYMSG ONBATT "UPS %s on battery"
NOTIFYMSG LOWBATT "UPS %s battary is low"
NOTIFYMSG FSD "UPS %s: forced shutdown in progress"
NOTIFYMSG COMMOK "Communications with UPS %s established"
NOTIFYMSG COMMBAD "Communications with UPS %s lost"
NOTIFYMSG SHUTDOWN "Auto logout and shutdown proceeding"
NOTIFYMSG REPLBATT "UPS %s battery needs to be replaced"
NOTIFYMSG NOCOMM "UPS %s is unavailable"
NOTIFYMSG NOPARENT "upsmon parent process died - shutdown impossible"

NOTIFYFLAG ONLINE   SYSLOG+WALL+EXEC
NOTIFYFLAG ONBATT   SYSLOG+WALL+EXEC
NOTIFYFLAG LOWBATT  SYSLOG+WALL+EXEC
NOTIFYFLAG FSD      SYSLOG+WALL+EXEC
NOTIFYFLAG COMMOK   SYSLOG+WALL+EXEC
NOTIFYFLAG COMMBAD  SYSLOG+WALL+EXEC
NOTIFYFLAG SHUTDOWN SYSLOG+WALL+EXEC
NOTIFYFLAG REPLBATT SYSLOG+WALL
NOTIFYFLAG NOCOMM   SYSLOG+WALL+EXEC
NOTIFYFLAG NOPARENT SYSLOG+WALL

RBWARNTIME 43200
NOCOMMWARNTIME 600

FINALDELAY 5

Не забудьте заменить звездочки на ваш пароль администратора во второй строчке.

Редактируем upssched.conf:

nano /etc/nut/upssched.conf

Удаляем все и добавляем:

CMDSCRIPT /bin/upssched-cmd
PIPEFN /etc/nut/upssched.pipe
LOCKFN /etc/nut/upssched.lock

AT ONBATT * START-TIMER shutdown_proxmox 100
AT ONLINE * CANCEL-TIMER shutdown_proxmox online
AT LOWBATT * EXECUTE shutdown_proxmox
AT COMMBAD * START-TIMER commbad 30
AT COMMOK * CANCEL-TIMER commbad commok
AT NOCOMM * EXECUTE commbad
AT SHUTDOWN * EXECUTE shutdown_proxmox

START-TIMER shutdown_proxmox 120 — запускает таймер на 2 минуты для выключения Proxmox после перехода на батарею.
CANCEL-TIMER shutdown_proxmox online — отменяет таймер, если питание восстановилось до истечения времени.
EXECUTE shutdown_proxmox — немедленно выполняет выключение при критическом уровне заряда батареи или других событиях.

Как это будет работать?

Переход на батарею:

Когда ИБП переходит на батарею (ONBATT), запускается таймер на 2 минуты.
Если за это время питание не восстановится, через 2 минуты выполнится команда shutdown_proxmox.

Восстановление питания:

Если питание восстановится до истечения 2 минут, таймер будет отменен, и система продолжит работу.

Критический уровень батареи:

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

Потеря связи с ИБП:

Если связь с ИБП потеряна более чем на 30 секунд, система также выполнит выключение.

Нужно убедиться, что PIPEFN и LOCKFN указывают на существующую директорию. У меня ее не было, поэтому я ее создал.

mkdir /etc/nut/upssched/

Редактируем upssched-cmd:

nano /bin/upssched-cmd

Удаляем все и добавляем:

#!/bin/bash

case $1 in
    shutdown_proxmox)
        logger -t upssched-cmd "UPS on battery too long — shutting down Proxmox"
        /sbin/shutdown -h now
        ;;
    *)
        logger -t upssched-cmd "Unknown command from upssched: $1"
        ;;
esac

При получении команды shutdown_proxmox система логгирует сообщение и выполняет выключение командой /sbin/shutdown -h now.

Сохраняем, затем предоставляем права:

chmod +x /bin/upssched-cmd

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

systemctl restart nut-server
systemctl restart nut-client
systemctl restart nut-monitor
upsdrvctl stop
upsdrvctl start

После перезагрузки выполняем команду:

upsc ups@localhost

и смотрим, показана ли информация о нашем ИБП:

Проверяем, какие значения мы можем записывать

upscmd -l ups@localhost

В моем ИБП не оказалось возможности аппаратно записать значения минимального времени работы (200 секунд) и заряда (50%), но оставлю эти команды тут:

upsrw -s battery.runtime.low=200 ups@localhost
upsrw -s battery.charge.low=50 ups@localhost

После ввода каждой команды будет запрошен логин и пароль, используйте логин upsadmin и пароль, который вы указывали при редактировании /etc/nut/upsmon.conf и /etc/nut/upsd.users. После ввода команд система будет возвращать ОК, даже если изменения нельзя записать.
Перезагружаем сервисы/сервер.

Эти команды не настраивают автоматическое отключение хоста, а задаются критические значения для самого ИБП.
Так же, я заметил, что на моем ИБП нет возможности изменить параметр battery.charge.low. Рекомендую проверить изменения предыдущей командой, которая выводит ваши значения по ИБП.

Однако, можно программно записать значения в ups.conf, добавив мониторинг нагрузки через override:

nano /etc/nut/ups.conf

override.battery.charge.low = 50
override.battery.runtime.low = 200

Тогда содержимое ups.conf будет выглядеть так:

pollinterval = 15
maxretry = 3

offdelay = 300
ondelay = 30

[ups]
   driver = usbhid-ups
   port = auto
   desc = "CyberPower UT850EG"
   vendorid = 0764
   productid = 0501
   serial = ""
   override.battery.charge.low = 50
   override.battery.runtime.low = 200

После внесения изменений проверяем той же командой:

upsc ups@localhost

И видим, что конфиг применился.

Как это вообще все работает?

Да я сам не сразу понял.

Порядок приоритетов работы системы:

1. Сначала проверяются override параметры:

override.battery.charge.low (50%)
override.battery.runtime.low (200 секунд)

2. Потом срабатывают таймеры из upssched.conf:

AT ONBATT запускает таймер на 120 секунд
AT LOWBATT может прервать процесс раньше

3. В конце учитываются временные задержки:

offdelay (300 секунд) - должно быть ≥ времени таймера
ondelay (30 секунд)

Рекомендации по согласованию значений:

override.battery.runtime.low ≤ offdelay
таймер в AT ONBATT ≤ override.battery.runtime.low
override.battery.charge.low < override.battery.runtime.low

Создание и настройка LXC контейнера для мониторинга ИБП

В принципе, на стороне сервера уже все настроено и сервер будет отключаться в соответствии с настройками NUT, но для удобства можно настроить веб страничку с данными об ИБП. Я это сделал в отдельном LXC контейнере.

Характеристики: 1 ядро, 128мб ОЗУ, 2гб диск, ubuntu 24.04, автозапуск контейнера при загрузке.

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

apt update && apt upgrade -y

Затем ставим openssh-server.

apt install openssh-server -y

Далее изменим конфиг

nano /etc/ssh/sshd_config

Нужно раскомментировать или добавить следующие строчки:

PasswordAuthentication yes
PermitRootLogin yes

Сохраняем и перезапускаем openssh сервер:

systemctl restart ssh

Установим веб-сервер Apache, nut-cgi и nut клиент:

apt install apache2 nut-cgi nut-client -y

Сразу сделаем резервные копии всех редактируемых конфигов:

cp /etc/nut/nut.conf /etc/nut/nut.example.conf
cp /etc/nut/hosts.conf /etc/nut/hosts.example.conf
cp /etc/nut/upsset.conf /etc/nut/upsset.example.conf
cp /etc/nut/upsmon.conf /etc/nut/upsmon.example.conf

Редактируем /etc/nut/nut.conf:

nano /etc/nut/nut.conf

Удаляем все и добавляем:

MODE=netclient

Далее редактируем /etc/nut/hosts.conf:

nano /etc/nut/hosts.conf

Удаляем все и добавляем:

MONITOR ups@xxx.xxx.xxx.xxx "CyberPower UT850IEG"

где xxx.xxx.xxx.xxx это ip адрес вашего сервера Proxmox

Редактируем/etc/nut/upsset.conf:

nano /etc/nut/upsset.conf

Удаляем все и добавляем:

I_HAVE_SECURED_MY_CGI_DIRECTORY

Редактируем /etc/nut/upsmon.conf:

nano /etc/nut/upsmon.conf

Добавляем вначале:

RUN_AS_USER root
MONITOR ups@xxx.xxx.xxx.xxx 1 upsuser ******* slave

где xxx.xxx.xxx.xxx это ip адрес вашего сервера Proxmox, а ******** это пароль юзера upsuser, настроенного на сервере с proxmox.

Далее вводим команду:

sudo a2enmod cgi

И перезапускаем веб сервер:

sudo systemctl restart apache2

Теперь можно перейти по адресу http://xxx.xxx.xxx.xxx/cgi-bin/nut/upsstats.cgi где xxx.xxx.xxx.xxx это ip вашего lxc контейнера и мониторить статус ИБП. В моем случае это выглядит так:

Добавление ИБП в Synology

Чтобы все работало, нужно настроить Synology с помощью IP-адреса сервера NUT.

1. Включить функцию UPS support.

2. Выбрать Тип ИБП - Сервер ИБП Synology.

3. Настроить время - совет, ниже, чем на самом хосте.

Указать IP адрес вашего Proxmox.

Напоминаю, что также необходимо было настроить файл ups.conf на сервере NUT, чтобы ИБП назывался «ups». Он не может называться как-то иначе. В противном случае Synology откажется подключаться.

Вам также нужно было создать пользователя на сервере NUT (в uspd.users) с именем «admin» и паролем «secret». Я безуспешно пытался подключить Synology к серверу NUT, используя менее очевидное имя пользователя и сложный пароль, но безрезультатно.

Это не такая серьёзная проблема с точки зрения безопасности, как может показаться, поскольку пользователь «admin» имеет доступ к ИБП только для чтения. Я подтвердил это с помощью:

upscmd -l ups@localhost

Очевидно, что мы не хотим, чтобы любой злоумышленник в сети L3 мог отключить ИБП с помощью простых учётных данных.

upscmd -u admin -p secret ups@localhost shutdown.stayoff

Созданная выше учётная запись суперпользователя может выполнять все эти опасные команды, но встроенная учётная запись Synology не может.

upd. 02.05.2025

Благодаря подписчику переработал конфиги и скрипт, а так же протестировал их работу.

Тестируем аварийное отключение

В самом DSM я выставил таймер на 40 секунд, а для Proxmox 120.

В первом тесте ИБП был без питания 26 секунд. Все системы продолжили работу.

Во втором тесте ИБП был без питания 86 секунд. DSM самостоятельно завершил работу и возобновил после подачи питания. Proxmox при этом считал 120 секунд и продолжил работу.

Третьим тестом будет полное отключение Proxmox спустя 120 секунд

По итогам тестов я выяснил, что аккумулятор в ИБП разряжается до критического состояния с заданными ему максимальными значениями, поэтому занизил их, так как для меня нет необходимости тащить систему на резервном питании, дожидаясь восстановления.
ИБП все же не продовый, а скорее для домашнего использования, чем и является мой хост.
Основной приоритет - безопасное завершение работы.

В 04:32:55 было отключение электричества

В 04:34:25 прошло 90 секунд и proxmox начал останавливать все процессы

В 04:38:41 все процессы были остановлены и система была отключена

Мои финальные параметры в конфигах с таймерами остались такими:

override.battery.runtime.low = 120
override.battery.charge.low = 30
AT ONBATT * START-TIMER shutdown_proxmox 90
offdelay = 300

А что получилось у вас? Делитесь в комментариях.

Мне помогли:

https://kvvhost.ru/2024/07/04/nut-proxmox/

https://blog.zanshindojo.org/nut/

Сервер Transmission в Proxmox

2025-01-28T20:13:45.401Z

Тут я хочу описать способ создания сервера ВМ для штатной торрентокачалки, на мой взгляд, одной из самых удобных. Изначально я познакомился с Transmission благодаря Keenetic и загружал всё на подключенный к роутеру диск. Мне стало интересно, как его можно развернуть самостоятельно на хосте Proxmox с остальными ВМ и снять эту задачу с Keenetic.

Transmission по умолчанию имеет простенький веб интерфейс, который мы затюним, а так же клиенты под большинство ОС.

Перед написанием этой статьи я так же пробовал выполнить трюк в LXC контейнере, где для:

Привелигированного контейнера не совсем безопасно для ядра;
В непривилегированном контейнере нельзя выполнять операции, требующие прямого доступа к ядру, в том числе монтирование, а если и обходить , то нужно учитывать особенности работы с ID-сдвигами (UID/GID mapping). Сначала нужно монтировать шару на хосте, а затем привязать её к контейнеру. Это добавляет дополнительный уровень сложности.

В данном случае остается выбор ВМ. Изолированно от хоста. Просто разворачивается. Показываю с создания ВМ до самого конца.

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

TL:DR

Создание ВМ для Transmission

Выбор образа, установка параметров, подключение к хосту.

Установка и настройка Transmission

Обновление списка пакетов, установка Transmission, CIFS, nano. Создание каталога downloads, добавление записи о монтировании в /etc/fstab, настройка параметров в settings.json.

Тюнинг интерфейса Transmission

Установка веб-интерфейса с GitHub, настройка параметров для работы через веб-интерфейс.

Описание переменных в settings.json

Создаём ВМ для Transmission

Находим линк для закачки iso образа в releases.ubuntu.com и копируем. Я выбрал ubuntu-22.04.5-live-server-amd64

Идем на наш хост и выбираем local -> ISO Images -> Download from URL.

У меня этот образ ранее был загружен

Вставляем ссылку из буфера в полеURL и выбираем Query URL. В File name отобразится имя образа. Жмем Download.

После загрузки образа выбираем Create VM и создаем ВМ с минимально доступными параметрами по железу.

Задаем Name в General.

В OS находим загруженный образ, который ранее закинули в local.

Во вкладке System оставляем параметры по умолчанию.

Во вкладке Disks выделяем минимальный Disk size 8 GiB и указываем Storage.

По CPU и Memory, по моим тестам, одновременно на 5 активных загрузок достаточно 2 cores и 2048 MiB. Больше не пробовал.

В Network снимаем маркер с Firewall если он настроен на хосте, либо настраиваем самостоятельно под свои нужды.

Общий конфиг ВМ может выглядеть так. Ставим маркер Start after created и Finish.

Проходим в Console и выполняем стандартную процедуру установки. На первом этапе я выбираю English.

В Installer update available выбираем Continue without updating.

В Keyboard configuration оставляем как есть -> Done.

В Chose the type of installation оставляем по умолчанию Ubuntu Server (minimized) -> Done.

Сэкономим немного дискового пространства

Далее Network configuration, ну тут уж сами. У меня раздаётDHCP.

Позже задам статику на роутере.

ВProxy configuration мне ничего не нужно, оставляю пустым.

Ждем прогрузки зеркала вUbuntu archive mirror configuration -> Done

В Guided storage configuration оставляю по умолчанию -> Done -> Done -> Continue

В Profile Configuration - указываем своё имя для входа, имя сервера и пароль.

В Upgrade to Ubuntu Pro ничего не меняя, выбираем Continue.

В SSH Configuration я ставлю маркер на Instal OpenSSH Server чтобы в дальнейшем подключаться через терминал, мне так удобнее, а как вам - решайте сами.

В Featured server snaps ничего не меняя, выбираем Done.

После завершения установки отправляем ВМ в перезагрузку -> Reboot now

Так же может потребоваться нажать Enter, что якобы failed unmounting /cdrom. Отмонтировать для этого ничего не нужно.

После загрузки авторизуемся в системе и проверяем, какой адрес был выдан хосту чтобы потом не возникло вопросов, почему по SSH не доступен или не выполняется apt update. Выполняем ip a.

В сетевой карте ens18, где строка inet находим выданный адрес.

Установка и настройка Transmission

Далее я подключаюсь к свежеустановленному хосту по SSH и начинаю установку пакетов.

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

# Обновляем список пакетов
sudo apt update
# Устанавливаем Transmission, CIFS для монтирования по SMB, nano (по умолчанию в minimized отсутствует)
sudo apt install transmission-cli transmission-daemon transmission-common cifs-utils nano -y
# Создаем каталог downloads в mnt, в которую будем монтировать папку
sudo mkdir -p /mnt/downloads
# Открываем /etc/fstab для добавления записи о монтировании:
sudo nano /etc/fstab

Добавляем в конец файла и меняем под себя

Список длинный и прокручивается. Выдели триплкликом ЛКМ ниже.

//192.168.1.x/downloads /mnt/downloads cifs username=transmission,password=YoUrPaSSw0rd,uid=fonwa,gid=fonwa,file_mode=0777,dir_mode=0777,iocharset=utf8,_netdev 0 0

Пояснение:

//192.168.1.x/downloads — путь к SMB-ресурсу на целевом хосте, куда будут загружаться файлы.
/mnt/torrents — папка на только что созданном сервере Ubuntu, куда будет монтироваться сетевое хранилище.
username=transmission,password=YoUrPaSSw0rd — учетные данные для доступа к SMB-ресурсу.
uid=fonwa,gid=fonwa — задаёт владельцем и группой для всех файлов в этой папке пользователя fonwa.
file_mode=0777,dir_mode=0777 — устанавливает права на файлы и каталоги, чтобы они были доступны для записи.
iocharset=utf8 — кодировка.
_netdev указывает, что это сетевое устройство, и монтирование должно происходить после запуска сети.

Сохраняем изменения и закрываем файл: Ctrl+X, Y, Enter.

# Применяем настройки монтирования
sudo mount -a
# Проверяем, что диск смонтирован правильно
df -h

Убедитесь, что у папки /mnt/torrents есть права для пользователя fonwa (поскольку именно этот пользователь будет использовать Transmission):

ls -ld /mnt/downloads/

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

Теперь нужно настроить Transmission так, чтобы он использовал смонтированную папку /mnt/torrents для сохранения скачиваемых торрентов.

# Останавливаем сервис transmission-daemon
sudo systemctl stop transmission-daemon

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

# Открываем файл конфигурации Transmission:
sudo nano /etc/transmission-daemon/settings.json

Далее меняем параметры. Я лишь опишу некоторые из них, необходимые для первоначального запуска и показать, что всё работает.

1. Найдите параметр "download-dir" и замените его на путь к смонтированной папке:

"download-dir": "/mnt/downloads",

2. Отключаем whitelist, иначе на WEB морду не пустит:

"rpc-whitelist-enabled": false,

3. Выставляем логин/пароль с которыми будем заходить на WEB GUI, по умолчанию transmission/transmission

rpc-password шифрует пароль после сохранения конфига, не удивляемся длинному шифру

"rpc-password": "transmission",
"rpc-username": "transmission",

Сохраняем изменения и закрываем файл: Ctrl+X, Y, Enter.

# Запускаем сервис transmission-daemon
sudo systemctl start transmission-daemon
# Проверяем, что сервис активен
sudo systemctl status transmission-daemon

Открываем веб-интерфейс Transmission. Он обычно доступен на порту 9091, вводим в браузере:

http://192.168.1.X:9091 и введите свои логин/пароль, указанные в settings.json.

На этом этапе мы увидим скудный интерфейс Transmission.

Настройка задержки монтирования

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

# Создаем файл сервиса 
sudo nano /etc/systemd/system/mnt-downloads.mount

Добавляем в него содержимое и меняем под свои данные:

[Unit]
Description=Mount CIFS Share 
Requires=network-online.target 
After=network-online.target

[Mount] 
What=//192.168.1.x/downloads 
Where=/mnt/downloads 
Type=cifs
Options=username=transmission,password=YoUrPaSSw0rd,uid=fonwa,gid=fonwa,file_mode=0777,dir_mode=0777,iocharset=utf8,_netdev 

[Install] 
WantedBy=multi-user.target

# Включаем и запускаем сервис
sudo systemctl enable mnt-downloads.mount 
sudo systemctl start mnt-downloads.mount

Тюним интерфейс Transmission

# Переходим во временный каталог, откуда будем устанавливать веб-интерфейс
cd /var/tmp/
# Загружаем последнюю версию Transmission Web Control с GitHub
wget https://github.com/ronggang/transmission-web-control/raw/master/release/install-tr-control.sh --no-check-certificate
# Запускаем скрипт
sudo bash install-tr-control.sh

Ставим папку по умолчанию, нажав 6 и скопировав путь ниже:

/usr/share/transmission

Устанавливаем последнюю версию, нажав 1

После установки открываем веб-интерфейс по тому же адресу

http://<IP-адрес вашего хоста>:9091

Поздравляю. Вы установили Transmission с человеческим WEB интерфейсом, если придется зайти на него через браузер.

Так же можно:

Интуитивно менять настройки через WEB GUI;
Переключаться между десктопной и мобильной версиями;
Пробросить порты в наружу чтобы ставить на загрузку извне.

Попробуем добавить рандомную magnet ссылку на скачивание.

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

upd. 06.11.2025

Дополнение:

Монтирование CIFS восстанавливается само при обращении;
Система не виснет при старте, если сеть недоступна;
Пароль хранится отдельно в /etc/cifs-credentials;

Вынести учётные данные в защищённый файл.

# Вынести учётные данные в защищённый файл
sudo nano /etc/cifs-credentials

Изменить данные под себя

username=fonwa
password=yourpassword
domain=WORKGROUP # если домена нет, удалить строку

Сохранить и выйти

# Задать права
sudo chmod 600 /etc/cifs-credentials
sudo chown root:root /etc/cifs-credentials

Отредактировать уже существующий mnt-downloads.mount

sudo nano /etc/systemd/system/mnt-downloads.mount

Изменить под себя IP, name и имя папки, если отличается

[Unit]
Description=Mount CIFS Share /mnt/downloads
After=network-online.target
Requires=network-online.target

[Mount]
What=//192.168.1.x/downloads
Where=/mnt/downloads
Type=cifs
Options=credentials=/etc/cifs-credentials,uid=fonwa,gid=fonwa,file_mode=0777,dir_mode=0777,iocharset=utf8,_netdev

Сохранить и выйти

Создать еще 1 systemd юнит mnt-downloads.automount для автомонтирования

sudo nano /etc/systemd/system/mnt-downloads.automount

[Unit]
Description=Automount trigger for /mnt/downloads
After=network-online.target
Requires=network-online.target

[Automount]
Where=/mnt/downloads
TimeoutIdleSec=600

[Install]
WantedBy=multi-user.target

Сохранить и выйти

Удалить или закомментировать последнюю запись в /etc/fstab.

Никаких дубликатов //192.168.1.x/downloads быть не должно. Это будет мешать работе systemd.

sudo nano /etc/fstab

Сохранить и выйти

Перезагрузить конфигурацию и активировать

sudo systemctl daemon-reload
sudo systemctl enable --now mnt-downloads.automount

Проверить работу:

ls /mnt/downloads # вызовет автоматическое монтирование
mount | grep downloads # убедиться, что точка активна
# Временно отключить SMB сервис и запустить через некоторое время
# Убедиться, что автомонтирование отрабатывает самостоятельно

Переменные в settings.json

Файл /etc/transmission-daemon/settings.json содержит все настройки для Transmission, включая параметры для работы веб-интерфейса, настроек сети, пути загрузки и другие. Я расшифрую основные параметры этого конфигурационного файла, чтобы вы могли настроить его под свои нужды.

Основные параметры конфигурации

1. rpc-username

- Описание: Устанавливает имя пользователя для аутентификации на веб-интерфейсе Transmission. Если не требуется аутентификация, оставьте пустым..

- Пример: rpc-username": "fonwa"

2. rpc-password

- Описание: Пароль для веб-интерфейса Transmission.

- Пример: rpc-password": "YoUrPaSSw0rd"

- Описание: Пароль для пользователя, указанного в rpc-username. Пароль сохраняется в виде зашифрованной строки (с использованием хэширования). Не рекомендуется ставить слишком простой пароль, особенно если сервер доступен из внешней сети.

3. rpc-port

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

- Пример:rpc-port": 9091

4. rpc-bind-address

- Описание: Указывает, на какой IP-адрес веб-интерфейс должен слушать. Если значение установлено в 0.0.0.0, веб-интерфейс будет доступен на всех интерфейсах сервера. Если вы хотите ограничить доступ только локальной сети или конкретному интерфейсу, укажите IP этого интерфейса.

- Пример: "rpc-bind-address": "0.0.0.0"

5. rpc-authentication-required

- Описание: Указывает, требуется ли ввод имени пользователя и пароля для доступа к веб-интерфейсу. Если установлено в false, веб-интерфейс будет доступен без авторизаци.

- Пример: "rpc-authentication-required": true

6. rpc-whitelist

- Описание: Указывает, какие IP-адреса могут получить доступ к веб-интерфейсу. Используйте * для указания диапазонов (например, 192.168.1.* для разрешения всем в локальной сети).

- Пример: rpc-whitelist": ["127.0.0.1", "192.168.1.*"]

- Описание: Указывает, какие IP-адреса могут получить доступ к веб-интерфейсу. Используйте * для указания диапазонов (например, 192.168.1.* для разрешения всем в локальной сети).

7. rpc-whitelist-enabled

- Описание: Если установлено в true, Transmission будет проверять белый список rpc-whitelist. Если в белом списке не указан IP, доступ будет заблокирован.

- Пример: "rpc-whitelist-enabled": true

8. download-dir

- Описание: Папка для сохранения загруженных файлов.

- Пример: "download-dir": "/mnt/omv_share"

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

9. incomplete-dir

- Описание: Указывает место для хранения неполных файлов до завершения загрузки. Если параметр не установлен, все файлы загружаются в директорию, указанную в download-dir.

- Пример: incomplete-dir": "/mnt/omv_share/incomplete"

10. incomplete-dir-enabled

- Описание: Если установлено в true, файлы, находящиеся на стадии загрузки, будут сохраняться в директории, указанной в incomplete-dir

- Пример: "incomplete-dir-enabled": true

- Описание: Если установлено в true, файлы, находящиеся на стадии загрузки, будут сохраняться в директории, указанной в incomplete-dir.

11. download-queue-size

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

- Пример: "download-queue-size": 5

12. upload-queue-size

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

- Пример: "upload-queue-size": 10

13. peer-port

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

- Пример: "peer-port": 51413

14. peer-port-random-high

- Описание: Верхний предел диапазона для случайного выбора порта для P2P-соединений.

- Пример: "peer-port-random-high": 65535

15. peer-port-random-low

- Описание: Нижний предел диапазона для случайного выбора порта для P2P-соединений.

- Пример: "peer-port-random-low": 49152

16. ratio-limit

- Описание: Если соотношение раздачи к загрузке превышает это значение, Transmission завершит торрент.

- Пример: ratio-limit": 2.0

17. ratio-limit-enabled

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

- Пример: "ratio-limit-enabled": true

- Описание: Если установлено в true, соотношение раздачи/загрузки будет

18. blocklist-enabled

- Описание: Если установлено в true, Transmission будет использовать блок-лист для блокировки нежелательных IP-адресов.

- Пример: "blocklist-enabled": false

19. blocklist-url

- Описание: Указывает URL для загрузки блок-листа IP-адресов. Transmission будет скачивать и использовать его для блокировки вредоносных или нежелательных пиров.

- Пример: "blocklist-url": "http://www.example.com/blocklist"

Мне помогли:

https://evs.msk.ru/transmission-on-debian/

https://tweenpath.net/installing-transmission-torrent-client-debian/

https://habr.com/ru/articles/658463/

fonwa

Деплоим HTTP File Server в LXC (NGINX)

1. Создаём LXC-контейнер

2. Установка базовых пакетов

3. Проверяем работу

4. Настраиваем NGINX

5. Настраиваем доступ по SSH/SCP

6. Загружаем файлы

7. Проверяем

Настраиваем Nginx Proxy Manager для NUT

Зачем нужен Nginx Proxy Manager для NUT?

Подготовка сервера NUT

Настройка Nginx Proxy Manager

Создаем новый прокси-хост

Добавляем Custom Locations

Правило 1: Корневой путь

Правило 2: Путь для upsstats.cgi

Правило 3: Путь для upsimage.cgi

Настройка Advanced

Проверка работы

NGINX Proxy Manager

Что такое NGINX Proxy Manager?

Зачем он нужен?

Устанавливаем NPM

Подготовка среды

Запускаем контейнер:

Настраиваем

Добавляем сертификат.

Добавляем хост

Force SSL

HTTP/2 Support

HSTS Enabled

HSTS Subdomains

Немного теории

Как работает SSL-терминация

Что происходит в браузере

Полезные фишки

Статистика и мониторинг

Кастомная страница 404

Glances в Proxmox и экспорт в Grafana

Устанавливаем змею

Устанавливаем Glances в pipx

Настраиваем сервис Glances

Устанавливаем InfluxDB

Настраиваем InfluxDB

Настраиваем экспорт в InfluxDB

Добавляем дашборд в Grafana

Добавляем Glances в GetHomePage

Локальный DNS-сервер с AdGuard Home

Готовим площадку: минимальные требования​

Настраиваем docker-compose.yml

Освобождаем порт 53

Отключаем DNSStubListener

Запускаем AdGuard Home

Первичная настройка AdGuard Home​

Меняем основной DNS на роутере

Настраиваем фильтрацию рекламы

Upstream DNS-серверы

Bootstrap DNS

Перезапись DNS-запросов

Проверяем работу фильтров

Итоги​

Самоподписанный SSL сертификат для внутреннего использования

Как переназначить нечитаемый сектор HDD в Proxmox: пошаговая инструкция

Почему важно реагировать на SMART-алерты

Проверка текущего SMART-статуса

Запуск глубокого SMART-теста

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

Метод 1: Запись нулей в сектор

Метод 2: Форсирование ремапа через hdparm

Проверка результата

Обновлённый анализ SMART-статуса

Что изменилось?

Итоги и рекомендации

Важно:

Уведомления Proxmox на Gmail

Настройка NUT + Proxmox + Synology

Настройка NUT сервера и клиента на сервере с Proxmox

Как это будет работать?

Сохраняем, затем предоставляем права:

Правило 2: Путь для `upsstats.cgi`

Правило 3: Путь для `upsimage.cgi`

Готовим площадку: минимальные требования

Первичная настройка AdGuard Home

Итоги