MirvMon v0.6.9

MirvMon v0.6.9

v0.6.9 is a behavior-preserving authorization cleanup release.

What changed

• Added one RolePolicy for the canonical user, operator, and admin role catalog.
• AdminMiddleware, OperatorMiddleware, AdminController, SystemController, and AuditController now consume the same policy instead of duplicating string comparisons.
• User-role validation now uses that same catalog, so new role handling cannot drift independently from request authorization.
• Existing route permissions are unchanged: users remain read-only, operators keep operational actions, and admin-only credentials/users/system/DR operations remain admin-only.

Upgrade

No database migration or configuration change is required. Pull ghcr.io/mirivlad/mirvmon:0.6.9 and redeploy the existing Compose stack.

MirvMon v0.6.8

MirvMon v0.6.8

External-connectivity probe robustness.

• Connectivity targets are now opened concurrently as a cURL-multi TCP batch instead of one after another.
• The complete round has one shared deadline equal to the configured target timeout. With the maximum 10 targets and 10-second timeout, a total network outage therefore no longer stretches the round toward 100 seconds.
• MirvMon still records the full successful/failed target lists before applying the configured quorum, so System diagnostics keep useful per-target evidence instead of hiding probes that were skipped by an early return.
• Ambient HTTP proxy settings are explicitly disabled for connectivity probes; the check represents MirvMon's own direct network reachability.
• No database migration or agent protocol change is introduced in this release.

For Docker/Portainer use ghcr.io/mirivlad/mirvmon:0.6.8 and perform the normal re-pull/redeploy.

MirvMon v0.6.7

MirvMon v0.6.7

Windows installer enrollment hardening.

• Windows download links now carry a single-use download ticket only. The ticket is consumed as soon as MirvMon accepts the first EXE-generation request.
• MirvMon then mints a different one-time activation credential and embeds only that value into the generated MirvMon-Agent-Setup.exe. The URL secret and installer secret are purpose-separated and stored in different database tables.
• Reusing the same Windows download URL returns 403; normal activation still exchanges the embedded credential for the permanent agent configuration over HTTPS.
• Explicit agent-token rotation invalidates both outstanding download tickets and installer activation credentials.
• A failed NSIS package build revokes the newly minted activation credential instead of leaving an unused live secret behind.
• Disaster-recovery normalization consumes transient Windows download tickets just like other installer credentials.
• Previously generated but not yet downloaded Windows installer links must be regenerated after upgrading to v0.6.7. Installed agents and their permanent credentials are unchanged.

For Docker/Portainer use ghcr.io/mirivlad/mirvmon:0.6.7 and perform the normal re-pull/redeploy.

MirvMon v0.6.6

MirvMon v0.6.6

Security-contract release for centralized website monitoring.

• Website targets are explicitly trusted administrator input. Internal DNS, loopback, private and link-local HTTP(S) targets remain supported so MirvMon can monitor services reachable from its own app container.
• MirvMon no longer documents website monitoring as an SSRF/tenant-isolation boundary that blocks private networks; only administrators can create or modify website checks.
• The actual egress protections are documented consistently: HTTP(S)-only URLs, URL credentials rejected, ambient proxy disabled, bounded redirects/deadlines/body reads, and auth/sensitive-header stripping across unapproved origins.
• Response bodies and configured secrets remain absent from monitoring history, diagnostics and rendered HTML.
• CI now checks this security-model wording together with the existing release-version contract.

For Docker/Portainer use ghcr.io/mirivlad/mirvmon:0.6.6 and perform the normal re-pull/redeploy.

MirvMon v0.6.5

MirvMon v0.6.5

Security and authorization release.

• user is now a read-only monitoring role.
• operator is available again for bounded operational actions: server maintenance, thresholds/services, alert resolution and agent configuration.
• Only admin can create/edit/delete servers or groups, issue installers, rotate credentials, request agent updates, change website definitions, users/system settings or use Backup & Restore.
• Existing database schema already supports operator; no migration is required. Existing user accounts become read-only and can be promoted by an administrator when operational access is required.
• Production image examples now point at ghcr.io/mirivlad/mirvmon:0.6.5, with CI coverage preventing stale pinned release examples.

For Docker/Portainer use ghcr.io/mirivlad/mirvmon:0.6.5 and perform the normal re-pull/redeploy.

MirvMon v0.6.4

MirvMon v0.6.4

Настройки и самодиагностика

• Выбор хоста, на котором работает MirvMon, перенесён из System / MirvMon в общую страницу Настройки.
• Туда же перенесены параметры контроля внешней сетевой связности: список host:port, quorum, период проверки и timeout.
• Страница System / MirvMon теперь отвечает только за самодиагностику: состояние приложения, PostgreSQL / TimescaleDB, workers, внешнюю связность, очередь уведомлений и метрики выбранного хоста. На ней больше нет редактируемых параметров и кнопок сохранения.
• Старые POST-маршруты настроек сохранены как совместимость для вкладок, которые могли остаться открыты до обновления.

Совместимость и обновление

• Изменений схемы БД нет.
• Agent protocol не изменён; обновлять или переустанавливать агенты не требуется.
• Для Docker/Portainer используйте ghcr.io/mirivlad/mirvmon:0.6.4 и выполните обычный re-pull/redeploy stack.

MirvMon v0.6.3

MirvMon v0.6.3

Настройка контроля сетевой связности

• Проверки собственной сетевой связности MirvMon теперь настраиваются прямо в System / MirvMon.
• Список probe-целей можно редактировать через UI: добавлять и удалять host:port узлы без изменения Compose/.env.
• Через UI настраиваются quorum, период проверки и timeout одной цели.
• Валидация не позволяет сохранить пустой список, некорректные host:port, quorum больше числа целей или значения вне допустимых диапазонов.
• Изменения подхватываются connectivity-worker без redeploy контейнера; offline-worker и website-check-worker используют актуальную конфигурацию при оценке свежести connectivity state.
• Изменение настроек записывается в Audit log.

Совместимость и обновление

• CONNECTIVITY_PROBE_TARGETS, CONNECTIVITY_PROBE_QUORUM, CONNECTIVITY_PROBE_TIMEOUT и CONNECTIVITY_CHECK_INTERVAL сохранены как bootstrap defaults. Пока настройки не сохранены в UI, поведение существующих установок не меняется.
• Для Docker/Portainer используйте ghcr.io/mirivlad/mirvmon:0.6.3 и выполните обычный re-pull/redeploy stack.
• Изменений схемы БД нет.
• Agent protocol не изменён; обновлять или переустанавливать агенты не требуется.

MirvMon v0.6.2

MirvMon v0.6.2

Контроль собственной сетевой связности

• Добавлен отдельный supervised connectivity-worker, который фоном проверяет внешний TCP/443 quorum. По умолчанию используются Cloudflare, Google и Quad9; состояние считается доступным при ответе не менее 2 из 3 целей.
• Цели, quorum, timeout и период проверки настраиваются через CONNECTIVITY_PROBE_TARGETS, CONNECTIVITY_PROBE_QUORUM, CONNECTIVITY_PROBE_TIMEOUT и CONNECTIVITY_CHECK_INTERVAL.
• Потеря внешнего quorum сама по себе больше не выдаётся за падение наблюдаемых серверов. MirvMon подавляет новые offline transitions только когда потеря собственной связности совпадает с массовой потерей ранее доступных агентов.
• Массовой потерей считается не менее двух агентов и не менее 30% наблюдаемого парка; уже находившиеся offline серверы в расчёт не входят.
• После восстановления связности агентам даётся их обычный offline_timeout_seconds на повторное подключение. Только не вернувшийся за это время агент создаёт настоящий offline-инцидент.
• Если сам offline-worker не работал достаточно долго, действует тот же recovery grace period, поэтому рестарт или простой MirvMon не создаёт ложный шторм offline/recovered уведомлений.
• Централизованные проверки сайтов при подтверждённой потере внешней связности MirvMon приостанавливаются и автоматически продолжаются после восстановления сети.
• Состояние внешней связности и heartbeat нового worker отображаются на странице System / MirvMon.

Уведомления и события

• Все даты в Telegram/SMTP уведомлениях теперь приводятся к APP_TIMEZONE и показываются в едином читаемом формате вместо смеси UTC ISO timestamps и локального времени.
• В offline-уведомлении дополнительно показывается последний контакт агента — именно это время используется MirvMon для определения недоступности; время последней метрики остаётся дополнительной диагностикой.
• Добавлены отсутствовавшие RU/EN-названия типов инцидентов для HTTP, assertion, performance, TLS и domain-проверок сайтов.

Обновление

• Для Docker/Portainer используйте ghcr.io/mirivlad/mirvmon:0.6.2 и выполните обычный re-pull/redeploy stack.
• Изменений схемы БД нет.
• Переустанавливать или обновлять агенты не требуется; agent protocol не изменён.
• Новые connectivity-параметры имеют безопасные значения по умолчанию, поэтому существующий .env можно не менять. При необходимости цели и quorum можно переопределить явно.

MirvMon v0.6.1

MirvMon v0.6.1

Backup job visibility

• Исправлено поведение страницы Backup & Disaster Recovery после ухода и повторного входа: активные и завершённые backup jobs теперь снова находятся по persistent DR-state, а не только по исходному URL с ?backup=<id>.
• Добавлен список последних backup-операций со статусами В очереди / Создаётся / Готов / Ошибка.
• Для каждой операции показываются имя файла, время создания и завершения, размер готового архива и точное время автоматического удаления.
• Готовый archive можно скачать прямо из списка после нового входа на страницу или повторного открытия браузера.
• Если в истории есть queued/running backup, страница продолжает автоматически обновляться до изменения его состояния.
• Временный completed backup, как и раньше, хранится 24 часа после завершения, после чего dr-worker физически удаляет archive и operation state.

Обновление

• Для Docker/Portainer используйте ghcr.io/mirivlad/mirvmon:0.6.1 и выполните обычный re-pull/redeploy stack.
• Изменений схемы БД нет.
• Agent protocol не изменён; переустанавливать агенты не требуется.
• Уже созданные в v0.6.0 backup jobs совместимы: после обновления v0.6.1 они появятся в истории, если их 24-часовой срок хранения ещё не истёк.

MirvMon v0.6.0

MirvMon v0.6.0

Backup & Disaster Recovery

• Добавлен полный password-protected backup MirvMon из web UI: PostgreSQL/TimescaleDB, история метрик и сайтов, настройки, инциденты, audit log и остальные постоянные данные.
• Backup имеет собственный версионированный формат, manifest, checksums и потоковое шифрование; APP_KEY в архив не записывается.
• Backup создаётся асинхронно отдельным dr-worker из согласованного PostgreSQL snapshot, поэтому длительный pg_dump не держит HTTP-запрос открытым.
• Restore начинается с read-only preflight: пароль, целостность архива, manifest, dump, миграции и версии PostgreSQL/TimescaleDB проверяются до изменения рабочей БД.
• Восстановление выполняется в отдельную staging database. Только после restore, forward migrations, re-encryption секретов, normalization и integrity checks выполняется cutover.
• Cutover защищён maintenance lock и crash-recovery journal: ingestion и фоновые workers получают контролируемую паузу, а прерванный процесс может безопасно завершить или откатить переключение БД.
• Restore поддерживает новый APP_KEY: application secrets расшифровываются из backup и заново шифруются текущим ключом установки.
• Permanent credentials и server IDs уже установленных агентов сохраняются. Существующий агент с прежним token продолжает отправлять метрики после восстановления.
• Если после DR с другим APP_KEY требуется новый installer для такого сервера, MirvMon не выдаёт заведомо нерабочий installer: сначала требуется явная регенерация token, которая инвалидирует старый агент.
• После неудачного restore UI сохраняет исходные версии MirvMon, PostgreSQL и TimescaleDB из backup для восстановления на matching stack.

Проверенный disaster-recovery сценарий

CI воспроизводит полный сценарий A(APP_KEY=A) -> encrypted backup -> fresh B(APP_KEY=B) -> restore -> unchanged real Go agent -> metrics accepted на production amd64 image и настоящем TimescaleDB.

Acceptance также проверяет:

• неверный пароль и повреждённый archive не изменяют B;
• restore backup с предыдущей поддерживаемой схемой применяет обычные forward migrations;
• application secrets после restore читаются новым APP_KEY;
• временный administrator/session установки B исчезает после cutover;
• maintenance 503 заставляет настоящий агент сохранить метрики в durable queue и отправить их после окончания maintenance.

Обновление

• Для Docker/Portainer используйте ghcr.io/mirivlad/mirvmon:0.6.0 и выполните обычный re-pull/redeploy stack.
• Новых миграций схемы БД в v0.6.0 нет.
• Agent protocol не изменён; переустанавливать агенты для обновления MirvMon не требуется.
• Для backup upload доступны BACKUP_MAX_UPLOAD_BYTES (по умолчанию 8 GiB) и DR_WORKER_INTERVAL (по умолчанию 2 секунды). Значения уже есть в актуальных .env.example.

Важно перед Disaster Recovery

Чтобы уже установленные агенты продолжили работу без изменения конфигурации, новая установка B должна быть доступна по тому же публичному MirvMon endpoint (тот же URL/домен/IP), который записан у агентов. Автоматическая миграция endpoint/discovery в v0.6.0 не реализуется.