Exploitation

Sauvegardes, mises à jour, retour arrière, supervision et ce qu'implique une instance Colombe unique par établissement.

Sauvegardes

À sauvegarder :

• le dossier de données (/var/lib/colombe en archive, ou le volume colombe-data en Docker) : base SQLite des préférences, contacts, identités, réponses types et secrets de double authentification ;
• à part, WEBMAIL_DATA_KEY : sans elle, les secrets de double authentification déjà stockés deviennent illisibles en cas de perte du fichier de configuration.

Copie cohérente à chaud (la base reste utilisable pendant la copie) :

sqlite3 /var/lib/colombe/webmail.sqlite ".backup /sauvegarde/colombe.sqlite"

Le courrier lui-même reste en permanence sur le serveur IMAP : Colombe n'en garde aucune copie, donc rien à sauvegarder de ce côté pour Colombe spécifiquement (vos sauvegardes habituelles de Dovecot restent nécessaires).

Mises à jour

# Archive
tar -xzf colombe-<nouvelle>.tar.gz -C /opt
mv /opt/colombe /opt/colombe.prev && mv /opt/colombe-<nouvelle> /opt/colombe
systemctl restart colombe
# Retour arrière : inverser les deux dossiers et redémarrer.

# Docker
docker compose pull && docker compose up -d

La base SQLite locale est migrée automatiquement au démarrage. Un redémarrage déconnecte les utilisateurs en cours (les sessions sont en mémoire, voir §Montée en charge) : préférez un moment calme. Le déploiement par SSH (scripts/deploy-ssh.sh, voir Contribuer) garde automatiquement la version précédente ($DIR.prev) pour un retour arrière rapide.

Supervision

GET /api/health répond, sans authentification et sans information interne :

{ "status": "ok", "version": "1.0.0-rc.1" }

À brancher sur votre supervision habituelle (contrôle actif, sonde de load balancer). En Docker, le HEALTHCHECK de l'image l'interroge déjà toutes les 30 secondes (docker inspect --format '{{.State.Health.Status}}' colombe).

Journaux

Une ligne par échec de connexion ou de double authentification, exploitable par fail2ban :

[colombe] auth-failure ip=203.0.113.7 user=jean.dupont@univ-exemple.fr

En archive/systemd : journalctl -u colombe -f. En Docker : docker compose logs -f colombe. Voir Sécurité, §Recommandations pour la configuration fail2ban fournie (deploy/fail2ban/).

colombe-doctor : diagnostic

node scripts/colombe-doctor.mjs                                    # archive
docker compose exec colombe node scripts/colombe-doctor.mjs        # Docker

Vérifie : version de Node, validité de la configuration, accès en écriture et intégrité SQLite du dossier de données, sondes réseau IMAP/SMTP/ManageSieve (certificat, capacités annoncées), et, avec --user <adresse> --password-stdin, une authentification réelle (mot de passe lu sur l'entrée standard, jamais en argument de ligne de commande, jamais affiché). Sortie : une ligne ✔/✖/! par vérification, code de sortie 1 si un ✖ a été émis — adapté à un script de vérification post-déploiement.

Montée en charge

Colombe est un seul processus Node : les sessions utilisateur, les compteurs de limitation (envoi, tentatives de connexion) et le cache des scripts de filtres vivent en mémoire de ce processus. Conséquences pratiques :

• Pas de répartition de charge entre plusieurs instances : deux processus Colombe ne partagent ni leurs sessions ni leurs compteurs. Un load balancer devant plusieurs instances romprait les sessions en cours de route.
• Un redémarrage déconnecte tout le monde. Les sessions ne survivent pas au processus.
• Chaque session ouverte garde une connexion IMAP au serveur de messagerie (pour les nouveaux messages en direct). Vérifiez mail_max_userip_connections de Dovecot (défaut 10) : si Colombe tourne sur une machine séparée du serveur de messagerie, toutes les connexions Colombe proviennent de la même IP, il faut donc relever cette limite pour cette IP (ou globalement), par exemple mail_max_userip_connections = 50, ajusté au nombre d'utilisateurs simultanés attendus.

Pour un établissement de taille moyenne, un seul processus suffit largement ; il n'existe aujourd'hui pas de mode multi-instance.