Aller au contenu

VPS Hetzner — Cartographie des ports et services

Contexte

Inventaire complet des ports accessibles depuis l'extérieur sur le VPS 178.105.46.57. Inclut l'installation de Hermes WebUI (port 3002) effectuée le 20260514.

Ports accessibles depuis l'extérieur

Port Service Via Auth
22 SSH Direct (host) Clé SSH
80 PsychoEnLigne — Frontend Docker direct Aucune (public)
3901 PsychoEnLigne — Backend API Docker direct JWT
3000 Hermes Workspace Docker direct ⚠️ Aucune
3001 Hermes Workspace (via Caddy) Caddy → 3000 Aucune
2019 Hermes Dashboard Caddy → 9119 hermes / mdp Hermes
7682 Terminal ttyd Caddy → 7681 hermes / mdp Hermes
4001 Datasette (sessions Hermes) Caddy → 8765 hermes / mdp Hermes
3002 Hermes WebUI Caddy → 8787 hermes / mdp Hermes

Point de vigilance : port 3000 exposé directement sans auth par Docker (Docker bypass UFW). Caddy protège 3001 mais 3000 reste accessible directement.

Ports internes uniquement (non accessibles depuis l'extérieur)

Port Service Restriction
8787 Hermes WebUI (process Python) 127.0.0.1 uniquement
9119 Hermes Dashboard (process) 172.16.0.0/12 (Docker interne)
8642 Hermes Gateway 172.16.0.0/12 (Docker interne)
5432 PostgreSQL (shared) 127.0.0.1 uniquement
6379 Redis (shared) 127.0.0.1 uniquement
8765 Datasette (process) 127.0.0.1 uniquement
7681 ttyd (process) Direct host, protégé par Caddy

Installation Hermes WebUI — 20260514

Ce qui a été fait

  1. Clone : git clone https://github.com/nesquena/hermes-webui.git ~/hermes-webui
  2. Bootstrap : python3 bootstrap.py --no-browser — détecte hermes-agent, installe les dépendances Python
  3. Service systemd : ~/.config/systemd/user/hermes-webui.service — démarre au boot, redémarre automatiquement
  4. Caddyfile : bloc :3002 ajouté à ~/hermes/Caddyfile → reverse_proxy localhost:8787 + basic_auth
  5. UFW : ufw allow 3002/tcp via connexion root SSH

Problème rencontré et résolution

Le bootstrap.py démarre le serveur en arrière-plan avant de rendre la main. Quand systemd a ensuite tenté de lancer le service, le port 8787 était déjà occupé → échec au premier démarrage.

Résolution : kill <pid> du process bootstrap → systemd a redémarré le service automatiquement → service active (running).

Caddy reload impossible via caddy reload

Le port 2019 sert à la fois de listener Caddyfile (reverse proxy vers hermes-dashboard) et d'API admin Caddy → conflit HTTP 401 lors du reload.

Résolution : docker restart caddy — Caddy relit le Caddyfile au démarrage.

Commandes utiles Hermes WebUI

systemctl --user status hermes-webui   # statut
systemctl --user stop hermes-webui     # arrêter
systemctl --user start hermes-webui    # démarrer
systemctl --user restart hermes-webui  # redémarrer
cat ~/.hermes/webui.log                # logs

Accès

  • URL : http://178.105.46.57:3002
  • Login : hermes
  • Mot de passe : mot de passe habituel Hermes
  • Workspace : ~/workspace (visible dans le panneau fichiers)

Nommage des ports — Décision en attente

L'option des noms de domaine (sous-domaines via Caddy) est prévue mais reportée car : - Pas encore de nom de domaine disponible - Les services doivent être accessibles depuis tous les appareils (PC + téléphone) → la solution hosts file locale est exclue - Décision : conserver les numéros de ports jusqu'à l'acquisition d'un domaine

Quand le domaine sera disponible, reconfigurer Caddy pour router par sous-domaine sur 80/443 : 

workspace.domaine.com   →  3000 (hermes-workspace)
webui.domaine.com       →  8787 (hermes-webui)
dashboard.domaine.com   →  9119 (hermes-dashboard)
terminal.domaine.com    →  7681 (ttyd)
sessions.domaine.com    →  8765 (datasette)

Liens connexes