Mirroring

[IndignonsNous]

La mise en place du CMS résoud de nombreux problèmes mais crée une fragilité : le CMS n'est que sur UN site.

Il faut le mirrorer sur d'autres sites.

Compte tenu de l'infra existante et de nos moyens dérisoires, la meilleure solution est probablement de créer les sites miroirs en dupliquant la BDD et le dossier /cms/IMG par un CRONJOB, et de désactiver l'accès à l'admin sur les miroirs. C'est assez simple à faire et ça permet de basculer immédiatement sur un miroir en cas de problème sur le CMS "maître" pour restaurer le service, éventuellement sur le nom de domaine d'un miroir.

[Hugo-Trentesaux]

Ça m'intéresse de participer à la décentralisation du CMS. La base de données contient-elle des données sensibles comme le mail des comptes qui y ont accès en écriture ? Si c'est le cas, on ne peut pas partager la base telle quelle, il faut soit retirer les données, soit la chiffrer pour une clé partagée uniquement avec des personnes de confiance ou la servir derrière une authentification par secret.

Tant que la base est petite, voici ce que je vois dans un premier temps : servir directement le fichier sqlite ou un dump périodique si MariaDB ou PostgreSQL. Les sites miroir auront leur propre cron pour récupérer la base.

Si un jour la base devient trop grande, il faudra un mécanisme pour synchroniser uniquement les diff (transactions).

[IndignonsNous]

Oui, elle contient ces données sensibles. Et si on les retire, on perd la possibilité de basculer sur un miroir en cas de problème sur le site CMS "master".
Les mots de passe ne sont pas stockés en clair. Les mails sont visibles de tous les gens qui ont un compte sur le CMS. Inviter les admins à créer un mail pour ça sur des trucs genre Proton est un palliatif envisageable, préservant l'anonymat dans certaines limites (celles des abus des états).

Servir directement le fichier de sauvagarde SPIP en sqlite (et copier le dossier /cms/IMG) est la meilleure solution pour rester agnostique vis-à vis de la config BDD du miroir. Ça implique d'écrire un peu de code utilisant l'API pour faire ça régulièrement par cronjob côté master.

[Hugo-Trentesaux]

écrire un peu de code utilisant l'API pour faire ça régulièrement par cronjob côté master

Quelle API ?

Est-ce que schématiquement ceci conviendrait :

• un virtualhost apache avec htaccess vers la base sur une route dédiée comme https://private.10s25.fr/cms-database.sqlite
• un cron qui fait un tar.gz du dossier /cms/IMG vers un emplacement donné comme https://10s25.fr/cms-filesystem.tar.gz

À moins que "l'API" désigne une base de donnée externe hébergée sur un serveur différent du cms ? Dans ce cas il faut "sortir" la base avec une solution similaire à une backup sur un object storage.

[IndignonsNous]

L'API de SPIP. Cf. https://git.spip.net/spip/dump/-/tree/master?ref_type=heads

[IndignonsNous]

En fait, il suffit d'utiliser les plugins Dumpauto et Mes fichiers pour récupérer automatiquement et quotidiennement un zip contenant les documents (dossier /IMG) et le backup de la BDD au format sqlite.

Il ne reste plus qu'à récupérer ce fichier zip, et à mettre à jour les miroirs avec. On peut envisager d'utiliser les notifications par mail pour déclencher un "pull" depuis les miroirs, ou se contenter d'un CRONJOB.

La fonction native de restauration de la base est dans plugins-dist/dump/action/.

[IndignonsNous]

C'est presque totalement implémenté, et intégré dans le backoffice. Il ne reste qu'à implémenter une restauration non interactive de la sauvegarde sqlite copiée dans tmp/dump à partir de celle crée automatiquement sur le CMS source.

C'est à implémenter dans le plugin 10s25, dans genie/sq10s25_mirror.php.