Tactical RMM на VPS: власна система віддаленого адміністрування

Що ми налаштовуємо і навіщо

Tactical RMM — система віддаленого моніторингу й керування кінцевими пристроями. Її зазвичай використовують системні адміністратори, невеликі IT-команди, MSP-провайдери, розробники та власники кількох серверів або робочих станцій. На відміну від звичайного SSH-доступу, RMM-платформа показує стан усіх машин в одній панелі, уміє запускати автоматизацію за розкладом і фіксує дії операторів.

Після налаштування на VPS ви отримаєте вебпанель, у якій можна групувати пристрої за клієнтами, сайтами та ролями. Наприклад, окремо вести офісні ПК, сервери застосунків, ноутбуки розробників і тестові віртуальні машини. На пристрої встановлюється агент Tactical RMM; він передає телеметрію, приймає команди та виконує призначені перевірки.

Що вміє Tactical RMM

• Інвентаризація обладнання, ОС, дисків, сервісів і встановленого ПЗ.
• Моніторинг доступності, завантаження CPU, RAM, дискового простору та користувацьких перевірок.
• Віддалене виконання PowerShell, Bash, Python та інших скриптів.
• Планувальник завдань: оновлення, очищення тимчасових файлів, перезапуск служб, інвентаризація.
• Віддалений доступ через MeshCentral і підтримка термінальних сесій.
• Сповіщення через e-mail, вебхуки та інтеграції із зовнішніми системами.
• Керування патчами Windows і сценаріями обслуговування.
• Аудит дій операторів та історія результатів скриптів.

Чому не хмарний RMM

Cloud-managed RMM зручний тим, що не потребує обслуговування серверної частини. Однак у такому варіанті дані про пристрої, імена хостів, користувачів, IP-адреси та сценарії автоматизації проходять через інфраструктуру зовнішнього постачальника. Крім того, вартість підписки зазвичай зростає разом із кількістю агентів.

Self-hosted Tactical RMM дає контроль над даними, DNS, сертифікатами, строком зберігання логів і доступом операторів. Це корисно для внутрішньої інфраструктури, невеликих MSP-команд, лабораторій, homelab-середовищ і організацій із вимогами до розміщення даних. Мінус — сервер, оновлення, безпека та резервне копіювання стають вашою відповідальністю.

Важливо: RMM-сервер має привілейований доступ до керованих пристроїв. Компрометація панелі означає ризик компрометації всієї інфраструктури. Використовуйте унікальні паролі, MFA, обмеження доступу, регулярні оновлення та резервні копії.

Яка VPS-конфігурація потрібна для цього завдання

Навантаження Tactical RMM залежить не лише від кількості агентів, а й від частоти перевірок, зберігання логів, кількості одночасних віддалених сесій, обсягу автоматизації та використання MeshCentral. Для старту не варто обирати VPS з 1–2 ГБ RAM: PostgreSQL, контейнери застосунку, брокер повідомлень і сервіс віддаленого доступу конкуруватимуть за пам’ять.

Практичний стартовий варіант — 4 vCPU, 8 ГБ RAM, 120 ГБ NVMe та канал від 100 Мбіт/с. Такий запас дає змогу обслуговувати десятки агентів, зберігати історію перевірок і не стикатися з постійним OOM під час оновлень контейнерів. Як один із варіантів можна взяти VPS із зазначеними характеристиками, але важливішими є наявність SSD/NVMe, статичного IPv4, стабільної мережі та можливість робити снапшоти.

Диск і мережа

Для бази даних важливіші затримки та IOPS, ніж великий обсяг повільного HDD. Щонайменше 30–40% диска тримайте вільними: PostgreSQL, журнали контейнерів, тимчасові файли та бекапи можуть швидко заповнити розділ. Якщо в панелі багато пристроїв із частими перевірками, заздалегідь налаштуйте ротацію Docker-логів.

Вихідний трафік зазвичай помірний, але зростає під час віддалених сесій, передавання файлів і масового встановлення агентів. Для 50–100 пристроїв достатньо 100 Мбіт/с, однак для частого віддаленого доступу краще 1 Гбіт/с. Перевірте, що провайдер не блокує вхідні 80/TCP і 443/TCP: вони потрібні для випуску та продовження TLS-сертифікатів.

Коли потрібен dedicated, а не VPS

Dedicated-сервер має сенс за сотень агентів, інтенсивного використання віддаленого робочого столу, тривалого зберігання логів, вимог до виділених ресурсів або суворих політик ізоляції. Також він корисний, якщо на тому самому майданчику працюють окремі системи моніторингу, VPN-шлюз, файлове сховище та резервна копія бази даних.

Для 20–150 пристроїв якісний VPS зазвичай простіший та економніший. Масштабування краще починати не з переходу на виділений сервер, а з оптимізації інтервалів перевірок, очищення історії, винесення бекапів і збільшення RAM. Не розміщуйте Tactical RMM на VPS, який одночасно виконує роль публічного сайту, поштового сервера та бази даних критичного застосунку.

Вибір локації

Локація впливає на затримку віддалених сесій, вимоги до юрисдикції даних і швидкість підключення агентів. Якщо більшість співробітників перебуває в Європі, обирайте європейський дата-центр; для локальної команди в одному регіоні бажано тримати сервер поруч із нею. Водночас агенти підключаються через HTTPS, тому фізичне розташування пристрою в іншій країні не є проблемою, якщо з’єднання стабільне.

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

Нижче використовується Ubuntu Server 24.04 LTS. Станом на 2026 рік це актуальна LTS-платформа з тривалим строком підтримки. Розгортайте сервер із чистого образу, призначте йому повне доменне ім’я та до встановлення створіть DNS-записи типу A.

Для прикладу використовуватимуться три піддомени:

• rmm.example.com — вебпанель Tactical RMM.
• api.rmm.example.com — API та реєстрація агентів.
• mesh.rmm.example.com — MeshCentral для віддаленого доступу.

Замініть example.com на власний домен в усіх командах і конфігураційних файлах. Усі три записи мають вказувати на публічну IPv4-адресу VPS до отримання сертифікатів.

Створення адміністратора та налаштування SSH

Підключіться до сервера як root лише один раз, створіть окремого користувача та додайте ваш публічний SSH-ключ. Після перевірки входу під новим користувачем вимкніть парольну автентифікацію.

# Создаёт отдельного пользователя для администрирования.
adduser deploy

# Добавляет пользователя в группу sudo.
usermod -aG sudo deploy

# Создаёт каталог для SSH-ключей.
install -d -m 700 -o deploy -g deploy /home/deploy/.ssh

# Добавляет ваш публичный ключ; замените содержимое ключом из ~/.ssh/id_ed25519.pub.
nano /home/deploy/.ssh/authorized_keys

# Устанавливает безопасные права на файл ключей.
chown deploy:deploy /home/deploy/.ssh/authorized_keys
chmod 600 /home/deploy/.ssh/authorized_keys

Відкрийте другу SSH-сесію та переконайтеся, що вхід під користувачем deploy працює. Лише після цього змінюйте налаштування SSH.

# Открывает настройки SSH-демона.
sudo nano /etc/ssh/sshd_config.d/99-hardening.conf

# Проверяет синтаксис конфигурации SSH.
sudo sshd -t

# Перезапускает SSH после успешной проверки.
sudo systemctl restart ssh

У файлі /etc/ssh/sshd_config.d/99-hardening.conf розмістіть таке:

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
X11Forwarding no
AllowUsers deploy

Оновлення та базові утиліти

Спочатку встановіть оновлення. Tactical RMM — сервіс, який буде доступний з інтернету, тому не відкладайте виправлення ядра, OpenSSL, Docker і вебсервера.

# Обновляет индекс пакетов и устанавливает актуальные исправления.
sudo apt update && sudo apt full-upgrade -y

# Устанавливает базовые инструменты диагностики и администрирования.
sudo apt install -y ca-certificates curl gnupg git jq unzip \
  htop ncdu dnsutils chrony ufw fail2ban

# Включает синхронизацию времени, важную для TLS и журналов.
sudo systemctl enable --now chrony

# Проверяет текущую синхронизацию времени.
timedatectl status

Firewall і Fail2ban

Відкривайте лише SSH і вебпорти. Не відкривайте PostgreSQL, NATS, Redis, внутрішні API та порти контейнерів у зовнішній інтернет. Docker-контейнери мають бути доступні через reverse proxy або внутрішню мережу Compose.

# Разрешает SSH до включения firewall, чтобы не потерять доступ.
sudo ufw allow OpenSSH

# Разрешает HTTP для ACME-проверки и HTTPS для панели и агентов.
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# Включает firewall и показывает активные правила.
sudo ufw enable
sudo ufw status verbose

# Включает Fail2ban для защиты SSH от перебора паролей.
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

Якщо ви адмініструєте сервер лише з постійної IP-адреси, додатково обмежте SSH цією адресою. Не робіть цього за динамічної домашньої IP-адреси без аварійного доступу через консоль провайдера.

# Пример: разрешает SSH только с доверенного IP-адреса.
sudo ufw delete allow OpenSSH
sudo ufw allow from 203.0.113.10 to any port 22 proto tcp

Встановлення ПЗ — покроково

Tactical RMM складається з кількох сервісів: вебзастосунку, API, PostgreSQL, брокера повідомлень, MeshCentral і компонентів фонових завдань. Найбезпечніший шлях — використовувати офіційний інсталятор проєкту, який створює узгоджену конфігурацію та контейнери. Перед запуском прочитайте вміст завантаженого скрипту: він виконується з правами root.

У цій схемі використовується Docker Engine 27+ або 28+ і сучасний Docker Compose plugin. Версії образів Tactical RMM змінюються швидше, ніж версії Ubuntu, тому не фіксуйте неперевірений тег вручну: офіційний інсталятор зазвичай вибирає сумісний стабільний випуск.

Встановлення Docker Engine

# Удаляет старые конфликтующие пакеты Docker, если они присутствуют.
sudo apt remove -y docker.io docker-compose docker-compose-v2 podman-docker || true

# Добавляет официальный ключ репозитория Docker.
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | \
  sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

# Добавляет официальный репозиторий Docker для текущего релиза Ubuntu.
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \
  https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# Устанавливает Docker Engine, CLI и плагин Docker Compose.
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io \
  docker-buildx-plugin docker-compose-plugin

# Включает Docker и проверяет установленную версию.
sudo systemctl enable --now docker
docker version
docker compose version

Дозвольте користувачу deploy працювати з Docker без постійного sudo. Після виконання команди вийдіть із SSH-сесії та підключіться знову.

# Добавляет администратора в группу docker.
sudo usermod -aG docker deploy

# Создаёт каталог для установки и обслуживания Tactical RMM.
sudo install -d -m 0750 -o deploy -g deploy /opt/tacticalrmm

Перевірка DNS перед встановленням

Неправильні DNS-записи — одна з найчастіших причин невдалого випуску TLS-сертифіката. Перевірте кожен піддомен із самого VPS і з зовнішнього комп’ютера. Команда має повернути публічний IP сервера.

# Проверяет, что все доменные имена указывают на IP VPS.
dig +short rmm.example.com A
dig +short api.rmm.example.com A
dig +short mesh.rmm.example.com A

# Показывает публичный IP-адрес, с которого VPS выходит в интернет.
curl -4 ifconfig.me

Завантаження офіційного інсталятора Tactical RMM

Офіційний проєкт підтримує інсталяційний скрипт у репозиторії Tactical RMM. Перед запуском збережіть його локально, перевірте перші рядки та за потреби вивчіть повний код. Не використовуйте однорядкові конструкції на кшталт curl | bash для серверів, якими ви керуєте в production.

# Переходит в рабочий каталог установки.
cd /opt/tacticalrmm

# Загружает официальный установочный скрипт в локальный файл.
curl -fL \
  https://raw.githubusercontent.com/amidaware/tacticalrmm/master/install.sh \
  -o install.sh

# Разрешает запуск и показывает начало файла для ручной проверки.
chmod 700 install.sh
sed -n '1,120p' install.sh

# Показывает параметры, если скрипт поддерживает встроенную справку.
sudo ./install.sh --help || true

Назви параметрів інсталятора можуть змінюватися між випусками. Якщо скрипт пропонує інтерактивний режим, вибирайте встановлення з Docker і вказуйте три FQDN: для панелі, API та MeshCentral. У процесі знадобляться e-mail для Let’s Encrypt і надійні паролі для внутрішніх сервісів.

# Запускает официальный интерактивный установщик с правами root.
sudo ./install.sh

Під час встановлення вкажіть:

• домен панелі: rmm.example.com;
• домен API: api.rmm.example.com;
• домен MeshCentral: mesh.rmm.example.com;
• e-mail для сповіщень Let’s Encrypt;
• випадкові унікальні секрети для бази даних, JWT і внутрішніх компонентів;
• публічний IP VPS, якщо інсталятор запитує його окремо.

Перевірка контейнерів

Після завершення не вважайте встановлення готовим, доки не перевірите стан сервісів. Контейнери можуть запускатися кілька хвилин, особливо під час першого створення бази даних і випуску сертифіката.

# Показывает состояние сервисов в каталоге установки.
cd /opt/tacticalrmm
docker compose ps

# Показывает последние 200 строк логов всех контейнеров.
docker compose logs --tail=200

# Проверяет, что сервер слушает только ожидаемые внешние HTTP/HTTPS-порты.
sudo ss -lntp | grep -E ':(80|443)\s'

# Проверяет свободное место и использование памяти.
df -h
free -h

Відкрийте https://rmm.example.com у браузері. Під час першого входу створіть адміністратора лише з унікальним довгим паролем. Потім увімкніть MFA для всіх операторів, створіть окремі облікові записи співробітників і не використовуйте спільний обліковий запис адміністратора.

Конфігурація

Після базового встановлення налаштуйте домени, секрети, TLS, параметри журналювання та доступ операторів. Конкретні назви файлів залежать від версії офіційного інсталятора, але принцип один: секрети не повинні потрапляти до Git-репозиторію, shell history, скриншотів і публічних paste-сервісів.

Файл оточення та секрети

Якщо ваш deployment використовує Docker Compose, зберігайте секрети в окремому файлі .env з правами 600. Не передавайте паролі через аргументи командного рядка: вони можуть потрапити в історію shell і список процесів.

# Создаёт каталог конфигурации, доступный только root.
sudo install -d -m 0700 /etc/tacticalrmm

# Генерирует криптографически стойкие секреты.
sudo bash -c 'umask 077; cat > /etc/tacticalrmm/.env <<EOF
POSTGRES_PASSWORD='$(openssl rand -base64 36)'
DJANGO_SECRET_KEY='$(openssl rand -base64 48)'
JWT_SECRET='$(openssl rand -base64 48)'
EOF'

# Ограничивает доступ к файлу с секретами.
sudo chmod 600 /etc/tacticalrmm/.env
sudo chown root:root /etc/tacticalrmm/.env

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

TLS через Caddy

У багатьох варіантах встановлення Tactical RMM Caddy вже використовується як reverse proxy. Якщо інсталятор створив Caddyfile, перевірте, що він проксіює лише потрібні сервіси, увімкнув HTTPS і не публікує внутрішні панелі PostgreSQL або NATS.

Нижче наведено приклад загальної структури Caddyfile. Порти контейнерів і шляхи API звіряйте з файлами, створеними вашим випуском Tactical RMM. Не копіюйте приклад навмання поверх робочого Caddyfile: спочатку збережіть резервну копію.

Caddyfile {
    email [email protected]
    servers {
        protocols h1 h2
    }
}

rmm.example.com {
    encode zstd gzip
    reverse_proxy tactical-frontend:8000
}

api.rmm.example.com {
    encode zstd gzip
    reverse_proxy tactical-api:8001
}

mesh.rmm.example.com {
    encode zstd gzip
    reverse_proxy meshcentral:4430
}

Перед застосуванням будь-якої конфігурації Caddy перевірте синтаксис. Під час роботи Caddy всередині Docker використовуйте ім’я контейнера або команди з Compose; під час встановлення як systemd-сервісу — системну команду.

# Сохраняет копию текущего Caddyfile перед редактированием.
sudo cp /etc/caddy/Caddyfile /etc/caddy/Caddyfile.bak.$(date +%F) 2>/dev/null || true

# Проверяет конфигурацию локально установленного Caddy.
sudo caddy validate --config /etc/caddy/Caddyfile 2>/dev/null || true

# Перезагружает Caddy без разрыва активных соединений.
sudo systemctl reload caddy 2>/dev/null || true

Перевірка HTTPS і API

Перевіряйте не лише відкриття сторінки в браузері, а й коректність TLS-ланцюжка, DNS, HTTP-відповіді та доступність API. Відповідь 200, 301, 302 або 401 на закритому endpoint зазвичай означає, що reverse proxy працює; помилка 502 вказує на недоступний backend-контейнер.

# Проверяет заголовки главной страницы и TLS-соединение.
curl -I --fail --max-time 15 https://rmm.example.com

# Проверяет, что API отвечает через HTTPS.
curl -I --max-time 15 https://api.rmm.example.com

# Проверяет сертификат, имя хоста и дату окончания действия.
echo | openssl s_client -connect rmm.example.com:443 \
  -servername rmm.example.com 2>/dev/null | \
  openssl x509 -noout -subject -issuer -dates

# Проверяет доступность MeshCentral по HTTPS.
curl -I --max-time 15 https://mesh.rmm.example.com

Первинне налаштування у вебпанелі

1. Створіть окрему організацію або клієнта для власної інфраструктури.
2. Створіть сайти: наприклад, Office, Production, Home Lab.
3. Створіть технічні групи пристроїв: Windows Servers, Linux Servers, Workstations.
4. Увімкніть MFA для адміністратора до розгортання агентів.
5. Налаштуйте SMTP або webhook для критичних сповіщень.
6. Створіть перевірку вільного місця: попередження за 15%, критичний рівень за 5%.
7. Додайте тестову машину та перевірте виконання безпечної команди.

Для тесту на Linux призначте скрипт, який не змінює систему:

# Показывает имя хоста, uptime, свободное место и версию ядра.
hostnamectl
uptime
df -h /
uname -r

Для Windows використовуйте PowerShell-сценарій:

# Показывает имя компьютера, версию ОС и свободное место на системном диске.
Get-ComputerInfo | Select-Object CsName, WindowsProductName, WindowsVersion
Get-PSDrive -Name C | Select-Object Name, Used, Free

Безпека агентів: встановлюйте агент лише через захищену панель, не розміщуйте installer у відкритому файловому каталозі та не вимикайте перевірку сертифікатів. Для серверів спочатку тестуйте скрипти на одній машині в окремій групі.

Резервні копії та обслуговування

Знімок VPS корисний, але не замінює резервну копію. Він може перебувати в тому самому дата-центрі, бути недоступним через помилку акаунта та не гарантувати консистентність бази під час запису. Для Tactical RMM потрібні щонайменше щоденні резервні копії PostgreSQL, конфігурації reverse proxy, файлів Compose, змінних середовища та постійних Docker volumes.

Що включати до резервної копії

• Дамп PostgreSQL: користувачі, організації, агенти, політики, історія та налаштування.
• Каталог встановлення /opt/tacticalrmm, крім непотрібних тимчасових файлів і великих логів.
• Конфігурації з /etc/tacticalrmm, /etc/caddy та пов'язані systemd unit-файли.
• Список Docker volumes і дані MeshCentral, якщо вони не входять до дампу БД.
• Документ із доменами, DNS-записами, списком операторів і процедурою відновлення.

Резервне копіювання через restic

Restic підтримує шифрування на боці клієнта та S3-сумісні сховища. Не зберігайте пароль репозиторію та ключі доступу в самому бекапі. Тримайте їх у password manager або секретному сховищі, доступному під час аварійного відновлення.

# Встановлює restic та утиліти клієнта PostgreSQL.
sudo apt install -y restic postgresql-client

# Створює каталоги для тимчасових дампів і конфігурації бекапів.
sudo install -d -m 0700 /var/backups/tacticalrmm /etc/restic

# Створює файл із паролем шифрування репозиторію.
sudo bash -c 'umask 077; openssl rand -base64 48 > /etc/restic/tacticalrmm-password'

# Створює файл змінних для S3-сумісного сховища.
sudo nano /etc/restic/tacticalrmm.env

Приклад файлу /etc/restic/tacticalrmm.env:

export RESTIC_REPOSITORY="s3:https://s3.example.net/tacticalrmm-backups"
export RESTIC_PASSWORD_FILE="/etc/restic/tacticalrmm-password"
export AWS_ACCESS_KEY_ID="CHANGE_ME"
export AWS_SECRET_ACCESS_KEY="CHANGE_ME"
export AWS_DEFAULT_REGION="us-east-1"

Створіть скрипт. Ім'я контейнера PostgreSQL уточніть через docker compose ps; у прикладі його шукають за ім'ям сервісу. Якщо ваша інсталяція використовує іншу схему, замініть команду дампу на відповідну.

# Створює щоденний скрипт консистентного бекапу.
sudo nano /usr/local/sbin/backup-tacticalrmm.sh

#!/usr/bin/env bash
set -euo pipefail

source /etc/restic/tacticalrmm.env

STAMP="$(date +%F_%H-%M-%S)"
BACKUP_DIR="/var/backups/tacticalrmm/${STAMP}"
mkdir -p "${BACKUP_DIR}"

cd /opt/tacticalrmm

docker compose exec -T postgres pg_dump -U postgres -Fc \
  tacticalrmm > "${BACKUP_DIR}/tacticalrmm.dump"

tar -czf "${BACKUP_DIR}/config.tar.gz" \
  /opt/tacticalrmm \
  /etc/tacticalrmm \
  /etc/caddy 2>/dev/null || true

restic backup "${BACKUP_DIR}" \
  --tag tacticalrmm \
  --tag daily

restic forget --prune \
  --keep-daily 14 \
  --keep-weekly 8 \
  --keep-monthly 12

rm -rf "${BACKUP_DIR}"

# Робить скрипт виконуваним і запускає тестовий бекап вручну.
sudo chmod 700 /usr/local/sbin/backup-tacticalrmm.sh
sudo /usr/local/sbin/backup-tacticalrmm.sh

# Перевіряє вміст і цілісність репозиторію restic.
sudo bash -c 'source /etc/restic/tacticalrmm.env; restic snapshots'
sudo bash -c 'source /etc/restic/tacticalrmm.env; restic check'

Додайте запуск через cron уночі. За великої бази краще використовувати systemd timer, оскільки він краще веде журнали та може запускати пропущені завдання після перезавантаження, але cron достатньо для невеликої інсталяції.

# Відкриває root-crontab для щоденного запуску о 03:20.
sudo crontab -e

20 3   * /usr/local/sbin/backup-tacticalrmm.sh >> /var/log/tacticalrmm-backup.log 2>&1

Перевірка відновлення

Бекап вважається робочим лише після тесту відновлення. Раз на квартал розгорніть окремий тимчасовий VPS, відновіть конфігурацію та базу, потім перевірте вхід до панелі й видимість тестових пристроїв. Не виконуйте перше відновлення під час аварії.

Оновлення

Для Tactical RMM використовуйте maintenance window, особливо якщо підключено сервери клієнтів. Оновлення можуть змінювати схему бази даних, версії контейнерів і поведінку агентів. Спочатку створіть свіжий бекап, прочитайте release notes, протестуйте оновлення на копії або тестовій інсталяції й лише потім оновлюйте production.

# Зберігає стан запущених образів перед оновленням.
cd /opt/tacticalrmm
docker compose images > /root/tacticalrmm-images-before-update.txt

# Створює бекап перед зміною версій.
sudo /usr/local/sbin/backup-tacticalrmm.sh

# Завантажує нові образи та застосовує оновлення за документацією випуску.
docker compose pull
docker compose up -d

# Перевіряє стан і останні журнали після оновлення.
docker compose ps
docker compose logs --tail=150

Не виконуйте автоматичне оновлення контейнерів через Watchtower або аналогічні інструменти без тестування. Для RMM краще контрольоване оновлення у погоджене вікно, оскільки короткочасний збій панелі або несумісність бази можуть вплинути на велику кількість агентів.

Troubleshooting і FAQ

Чому браузер показує помилку сертифіката або Caddy не отримує сертифікат?

Спочатку перевірте DNS: кожен піддомен має повертати публічний IPv4 VPS. Потім переконайтеся, що порти 80/TCP і 443/TCP доступні ззовні, а firewall і зовнішня security group їх не блокують. Перегляньте логи Caddy або reverse proxy через docker compose logs. Поширена причина — запис AAAA вказує на непрацюючий IPv6-сервер або інший вебсервер уже займає 80-й порт.

Чому панель відкривається, але API відповідає помилкою 502 Bad Gateway?

Код 502 означає, що reverse proxy працює, але не може підключитися до backend-сервісу. Виконайте docker compose ps і знайдіть контейнер зі статусом exited, restarting або unhealthy. Потім відкрийте його логи: docker compose logs --tail=200 ім'я_сервісу. Перевірте RAM, вільний диск, значення змінних середовища та доступність PostgreSQL. Не видаляйте volumes до створення резервної копії.

Агент Tactical RMM не реєструється або постійно перебуває offline. Що робити?

Перевірте, що машина клієнта може відкрити https://api.rmm.example.com і https://mesh.rmm.example.com без TLS-помилки. Корпоративний proxy, антивірус, EDR або firewall можуть блокувати зв'язок агента. Зіставте час на пристрої: значне розходження годинників порушує перевірку сертифікатів. Також переконайтеся, що installer агента було завантажено з поточної панелі та він використовує правильний URL API, а не старий домен.

Після запуску контейнерів сервер починає використовувати swap або сервіси перезапускаються.

Зазвичай причина — нестача RAM. Перевірте free -h, docker stats, dmesg -T | grep -i oom і розмір Docker-логів. Для стабільної роботи невеликої інсталяції рекомендується 8 ГБ RAM; 4 ГБ підходить лише для лабораторного навантаження. Тимчасово можна збільшити swap, але це не заміна пам'яті: PostgreSQL і сервіси RMM працюватимуть повільніше. Зменшіть кількість важких перевірок і оновіть конфігурацію VPS.

Диск швидко заповнюється. Які дані можна очищати?

Спочатку визначте джерело: використовуйте df -h, du -xh /var/lib/docker | sort -h | tail і docker system df. Часто зростають Docker container logs, старі образи та архіви резервних копій, які не було видалено після надсилання до зовнішнього сховища. Не видаляйте PostgreSQL volumes і дані MeshCentral командою docker system prune --volumes без точного розуміння наслідків. Налаштуйте ротацію логів і зберігання історії алертів.

Яка конфігурація VPS мінімально підійде?

Для тестового середовища до 20 пристроїв підійдуть 2 vCPU, 4 ГБ RAM і 60 ГБ NVMe. Для практичного використання з кількома десятками пристроїв краще починати з 4 vCPU, 8 ГБ RAM і 100–120 ГБ NVMe. Важливі стабільний статичний IP, відкриті порти 80 і 443, нормальні дискові IOPS і можливість зберігати бекапи поза основним сервером. Не розраховуйте на 1 ГБ RAM.

Що вибрати — VPS чи dedicated для цього завдання?

VPS підходить для більшості невеликих інсталяцій до 100–150 пристроїв, якщо має гарантовані ресурси, NVMe-диск і стабільну мережу. Dedicated варто обирати за сотень агентів, високої активності віддалених сесій, тривалих термінів зберігання логів, вимог до ізоляції або потреби запускати поруч додаткові сервіси. Почніть із VPS і відстежуйте RAM, IOPS, навантаження CPU та зростання бази; міграція на виділений сервер знадобиться лише за підтвердженого навантаження.

Чи можна відкрити панель лише через VPN?

Так, і це хороший варіант для адміністративного інтерфейсу. Можна обмежити доступ до rmm.example.com IP-адресами WireGuard-мережі або правилами Caddy/firewall, залишивши API та MeshCentral доступними агентам через HTTPS. Однак уважно розділяйте шляхи та домени: якщо повністю закрити API від інтернету, пристрої за NAT перестануть підключатися. Перед зміною правил протестуйте доступ із тестового агента поза вашою локальною мережею.

Чому після оновлення частина агентів перестала підключатися?

Перевірте release notes встановленої версії, логи API, строк дії TLS-сертифіката та зміни доменних імен. Якщо під час оновлення змінювався reverse proxy, можливо, не проксіюються WebSocket-з'єднання, потрібні MeshCentral. Також переконайтеся, що системний час VPS коректний і база успішно пройшла міграції. У разі серйозного збою відновіть перевірений бекап або відкотіть образи лише за документованою процедурою, не змішуючи версії бази та застосунку.

Висновки та наступні кроки

Тепер у вас є власна інсталяція Tactical RMM на VPS: захищений сервер, HTTPS-домени, контейнерна платформа, панель керування агентами та схема резервного копіювання. Така система дає змогу централізовано обслуговувати робочі станції та сервери без залежності від хмарного RMM-сервісу.

1. Додайте одну тестову Windows-машину та один Linux-сервер, потім перевірте алерти, віддалені команди й доступ через MeshCentral.
2. Створіть бібліотеку безпечних скриптів: перевірка місця, очищення тимчасових файлів, оновлення пакетів, перезапуск сервісів та інвентаризація.
3. Налаштуйте MFA, ролі операторів, зовнішні сповіщення та регулярний тест відновлення резервної копії.

У міру зростання кількості пристроїв переглядайте інтервали перевірок, обсяг диска, строк зберігання історії та доступну RAM. Спочатку автоматизуйте повторювані дії, потім за потреби виносьте бекапи, моніторинг і окремі компоненти на незалежну інфраструктуру.