Hébergeur refuse SQlite, quelle solution ?

Général
1

Bonjour,
J’apprends, un peu par hasard, que mon hébergeur (depuis 20 ans…) n’accepte plus SQLite (et me dit, d’ailleurs, qu’il
ne l’a jamais accepté…).
Je vous donne ci-dessous ses arguments.

Comme ce sont des arguments de sécurité j’imagine qu’il faut en tenir compte pour éventuellement changer le mode de
sauvegarde de la base dans SPIP.
Ils me précisent donc que " Donc il est important de configurer SPIP pour utiliser MySQL/MariaDB".
Ce qui est le cas pour l’installation, on utlise mysql.domaine.tld, mais pas pour la sauvegarde.

Je ne peux donc plus sauvegarder la base de mes domaines sous PHP 7, à partir de SPIP, je ne peux que passer par PHP MySQL.
Ce qui empêche un administrateur de sauvegarder, entre autres problèmes.

Ne peut-on pas donner le choix de sauvegarder, dans la partie privée, entre SQlite et MySQL ?

Merci de votre aide.

— Explication ----

Nous ne supportons pas SQLite sur les serveurs web.

Le module SQLite pour PHP5 existe sur nos serveurs, cependant nous n’avons pas installé le module SQLite pour
PHP7 - et nous ne comptons probablement pas le faire.

A cause de comment SQLite fonctionne, il n’existe pas de service de base de données centralisé qui utilise ce logiciel
qui peut être
accédé par plusieurs serveurs différents: SQLite charge généralement la base de données à partir d’un fichier sur la
même machine que le
logiciel qui en fait la demande.

De manière généralisée il est donc fortement déconseillé d’utiliser SQLite dans une installation en production.

Comme notre service d’hébergement utilise plusieurs serveurs web pour assurer la redondance et une meilleure
performance, il serait en
fait impossible d’utiliser SQLite puisque le fichier de base de données aurait de grandes chances de devenir corrompu si
plusieurs serveurs
web modifiaient le fichier en même temps.

Donc il est important de configurer SPIP pour utiliser MySQL/MariaDB
à la place. Notre serveur MariaDB est disponible sous le nom mysql.domaine.tld.

— Fin de l’explication ----

–
Fin du message end - Signature
Perline

spip@perline.org – http://perline.org/

Ce message est couvert par le secret de la correspondance
(art. 226-15 et 432-9 du Code pénal)

2

Hello,
je crois que quelqu’un a déjà fait remonter ce problème et c’est bien embêtant.

Ce que je comprends c’est que l’hébergeur ne veut pas que sqlite soit utilisé comme moteur de base de données pour les sites en Prod, pour des raisons qui peuvent se comprendre dans certaines architectures sur lesquelles SQLite serait lent et aurait des problèmes de concurrence d’accès à la base

Dans le cas de l’utilisation par SPIP pour les backup on ne tombe pas sur ces problèmes car SQLite est utilisé comme interface SQL pour écrire un fichier de sauvegarde : il n’y a pas de problème de performance ni de concurrence car c’est du one shot et c’est donc safe dans toutes les architectures.

Malheureusement donc, l’hébergeur ne peut pas faire la différence entre les 2 cas.

Pour revenir à ta question, non on ne peut pas utiliser mysql pour faire la sauvegarde :frowning:

Au passage à SPIP 3 on avait ré-écrit tout le script de sauvegarde de la base qui se faisait autrefois dans un fichier mais avait plein de soucis de robustesse pour utiliser à la place SQLite qui a un avantage très simple : on écrit la sauvegarde avec des requêtes SQL qui nous permettent une bonne robustesse, et à la fin on a un fichier unique qu’il suffit de copier ou de télécharger pour le réutiliser.
De même le processus de restauration est simple, puisqu’il suffit de lire dans le backup SQLite avec des requetes SQL et de réinjecter les données dans la base principale.

Si on utilisait une base mysql pour faire le backup, il faudrait déjà créer une nouvelle base pour chaque backup et renseigner à SPIP les infos de connexion, ce qui complique. Mais surtout, on écrirait dans mysql, donc pas dans un fichier unique, et le backup serait toujours sur le même serveur que la base principale, et pas téléchargeable depuis l’interface.

L’alternative est probablement d’écrire une méthode de sauvegarde/restauration alternative, qui reprendrait d’un côté le code de phpmyadmin pour générer un dump mysql au format texte que l’on téléchargerait directement (ce qui évite le problème du timeout), et de l’autre quelque chose comme https://github.com/fadlee/bigdump qui serait capable de réimporter le dump mysql en plusieurs fois en gérant le timeout.

Bref, c’est loin d’être trivial et un gros chantier…

Alternativement, on peut essayer de recycler le vieux plugin de dump à la sauce SPIP 2 qui faisait ça dans un fichier xml mais il était assez buggué, pas fiable, et il doit falloir l’adapter aux versions récentes de SPIP et PHP.

3

Cela étant pour répondre à une question à court terme de @perline il existe des plugins qui permettent de faire des sauvegardes au format texte depuis l’espace privé de SPIP

  • saveauto, mais ne me marche pas sur les grosses bases (pour les problèmes soulevés par cedric)
  • adminer, jamais testé pour ma part
4

je viens de tester adminer sur contrib, et ça plante donc sur une page blanche cause timeout dès que la base est trop grosse, ce qui est la principale difficulté pour faire un backup robuste… (et pour réimporter ensuite bien entendu)

5

Bonjour,

Puisque la question est « quelle solution » il faut peut-être aussi évoquer la possibilité de changer d’hébergeur ? De ce que je lis ce ne sont pas exactement des arguments de sécurité (risque de vol ou d’intrusion ou de détournement) mais plutôt des arguments d’intégrité des bases SQLite lors des accès concurrentiels … J’ai aussi l’impression que l’argument n’est pas la concurrence d’accès à la base (ce que je comprends comme plusieurs accès simultanés à la base, courant sur un site quand on a plusieurs visiteurs simultanés, je pense que SQLite gère cette problématique) mais la possibilité d’accès à une base SQLite depuis un autre serveur simultanément, ils utilisent du clustering (plusieurs serveurs web qui servent le même site en parallèle), c’est là qu’ils pensent que SQLite n’est pas adapté … seuls les gens de PHP/SQLite pourraient confirmer ou infirmer ça j’imagine … De toute évidence il n’ont pas pris en compte le problème exact, ils croient que la base SQLite est celle qui est utilisée pour servir le site alors que comme le dit cerdic c’est du oneshot pour une sauvegarde. – Pierre

···

Le 14/07/2021 à 11:57, Perline via Discuter de SPIP a écrit :

Perline
Juillet 14

Bonjour,
J’apprends, un peu par hasard, que mon hébergeur (depuis 20 ans…) n’accepte plus SQLite (et me dit, d’ailleurs, qu’il
ne l’a jamais accepté…).
Je vous donne ci-dessous ses arguments.

Comme ce sont des arguments de sécurité j’imagine qu’il faut en tenir compte pour éventuellement changer le mode de
sauvegarde de la base dans SPIP.
Ils me précisent donc que " Donc il est important de configurer SPIP pour utiliser MySQL/MariaDB".
Ce qui est le cas pour l’installation, on utlise mysql.domaine.tld, mais pas pour la sauvegarde.

Je ne peux donc plus sauvegarder la base de mes domaines sous PHP 7, à partir de SPIP, je ne peux que passer par PHP MySQL.
Ce qui empêche un administrateur de sauvegarder, entre autres problèmes.

Ne peut-on pas donner le choix de sauvegarder, dans la partie privée, entre SQlite et MySQL ?

Merci de votre aide.

— Explication ----

Nous ne supportons pas SQLite sur les serveurs web.

Le module SQLite pour PHP5 existe sur nos serveurs, cependant nous n’avons pas installé le module SQLite pour
PHP7 - et nous ne comptons probablement pas le faire.

A cause de comment SQLite fonctionne, il n’existe pas de service de base de données centralisé qui utilise ce logiciel
qui peut être
accédé par plusieurs serveurs différents: SQLite charge généralement la base de données à partir d’un fichier sur la
même machine que le
logiciel qui en fait la demande.

De manière généralisée il est donc fortement déconseillé d’utiliser SQLite dans une installation en production.

Comme notre service d’hébergement utilise plusieurs serveurs web pour assurer la redondance et une meilleure
performance, il serait en
fait impossible d’utiliser SQLite puisque le fichier de base de données aurait de grandes chances de devenir corrompu si
plusieurs serveurs
web modifiaient le fichier en même temps.

Donc il est important de configurer SPIP pour utiliser MySQL/MariaDB
à la place. Notre serveur MariaDB est disponible sous le nom mysql.domaine.tld.

— Fin de l’explication ----

–
Fin du message end - Signature
Perline

spip@perline.org – http://perline.org/

6

Bonjour,
Pour répondre à plusieurs questions, bien sûr j’installe toujours aussi le plugin sauvegarde, mais ce n’est pas la même chose. en particulier parce qu’il faut passer par l’interface PHPMysql pour la réintégrer, avec toutes les exclusions et spécialisations que ça implique.
Changer d’hébergeur, alors que celui-ci a toutes les qualités, techniques et éthiques, et que j’y suis depuis 20 ans maintenant, ça me pose un problème. Sans compter le nombre de transferts et contrôles que ça me ferait faire, le tout gracieusement !
En l’occurrence ce que je pense faire est trier les arguments de Cerdic pour leur expliquer que les problèmes qu’ils craignent ne sont pas ceux créés par SPIP.
Mais comme il est dit, s’ils ne peuvent pas faire la différence techniquement entre un oneshot et de l’accès en continu on est mal…
Ce qui me sidère c’est de m’en apercevoir et d’avoir cette réponse (ça n’a jamais existé…) après 20 ans et de très nombreux sites hébergés et sauvegardés chez eux :confused:
A suivre peut-être…
Merci pour tout.

···

Pierr0t via Discuter de SPIP a écrit le 14/07/2021 à 16:53 :

Pierr0t
Juillet 14

Bonjour,

Puisque la question est « quelle solution » il faut peut-être aussi évoquer la possibilité de changer d’hébergeur ? De ce que je lis ce ne sont pas exactement des arguments de sécurité (risque de vol ou d’intrusion ou de détournement) mais plutôt des arguments d’intégrité des bases SQLite lors des accès concurrentiels … J’ai aussi l’impression que l’argument n’est pas la concurrence d’accès à la base (ce que je comprends comme plusieurs accès simultanés à la base, courant sur un site quand on a plusieurs visiteurs simultanés, je pense que SQLite gère cette problématique) mais la possibilité d’accès à une base SQLite depuis un autre serveur simultanément, ils utilisent du clustering (plusieurs serveurs web qui servent le même site en parallèle), c’est là qu’ils pensent que SQLite n’est pas adapté … seuls les gens de PHP/SQLite pourraient confirmer ou infirmer ça j’imagine … De toute évidence il n’ont pas pris en compte le problème exact, ils croient que la base SQLite est celle qui est utilisée pour servir le site alors que comme le dit cerdic c’est du oneshot pour une sauvegarde. – Pierre

··· (cliquer pour plus de détails)

Voir le sujet ou répondre à ce courriel pour répondre.

Vous recevez ce courriel car vous avez activé la liste de diffusion.

Pour se désabonner de ces courriels, cliquez ici.

-- 
****Fin du message end - Signature****
Perline 

Ce message est couvert par le secret de la correspondance
(art. 226-15 et 432-9 du Code pénal)
********************************************

spip@perline.org