root 4dfd512785 Wire up a real main<->VM SSH path for the standby's remote-info feature
The standby's "SSH to main server for containers/stats/system info"
fallback (RUNNING_ON_MAIN_SERVER=False path) was wired in code across
backups.py/users.py/commands.py/app.py but never actually worked:
outbound SSH from the VM is blocked by its own firewall (deliberate
hardening — ufw DENY OUT on 22/tcp and 2222/tcp, left untouched), and
separately the VM's contabo-key was never added to the main server's
authorized_keys in the first place.

Fixed via a persistent reverse tunnel instead of opening the VM's
firewall: main-to-vm-tunnel.service (systemd, auto-restart) runs on the
main server and keeps `ssh -R 2224:localhost:22` open to the VM, so the
VM can reach the main server's SSH via localhost:2224 without ever
needing outbound access itself. Added the standby's public key to the
main server's authorized_keys (chattr +i-locked — unlocked, appended,
re-locked immediately).

config.py (gitignored, not in this commit — edited live on both servers
directly) gets new MAIN_SERVER_SSH_HOST/PORT ("localhost"/"2224"), kept
deliberately separate from the existing MAIN_SERVER_IP (which stays the
real IP and is still used for on-page display in several templates —
overloading it for the tunnel target would have silently changed what's
shown in the UI). All four call sites switched from
MAIN_SERVER_IP/MAIN_SERVER_PORT to the new pair. Also fixed a pre-existing
bug in commands.py's run_command(): its SSH fallback had no -i key at all,
so it could never have authenticated even with the tunnel in place.

Verified end-to-end on the live standby: run_command(), backups.py's and
users.py's _ssh_main() all confirmed to actually execute on the real main
server (hostname/whoami/backup count all matched), not erroring or
silently no-op'ing.
2026-08-21 13:26:07 +02:00

CloudOps - Infrastructure Management & Disaster Recovery Platform

Overview

This repository contains the complete infrastructure code for Navitrends' backup and disaster recovery platform.

Components

  • Platform: Flask web application for backup/restore management
  • Scripts: Backup, restore, and sync scripts
  • Docker Compose: Configuration for all 5 applications

Applications Managed

  • Nextcloud (File sharing)
  • Odoo (ERP/CRM)
  • Frappe/ERPNext
  • Mautic (Marketing automation)
  • n8n (Workflow automation)

Servers

  • Main Server: 173.249.20.244
  • Backup VM: 192.168.152.128
Description
Cloud Infrastructure Management & Disaster Recovery Platform
Readme 40 MiB
Languages
PHP 66.6%
JavaScript 15.8%
Twig 8.6%
CSS 4.4%
Less 2.1%
Other 2.4%