Pas bien grave il vaut mieux avoir deux sécurités plutôt qu’une et puis c’est une bonne habitude de mettre fail2ban pour les apps au moins celles et ceux qui prennent modèle sur une déjà créé elles/ils pensent à mettre fail2ban.
Merci de ton aide, mais ça n’a pas résolu pas le problème. J’ai testé en navigation privée sous FF et dans un autre navigateur, avec le même résultat : je suis locked out of my shaarli. Le contenu actuel du dossier data
/var/www/shaarli/data# ls -l
total 304
-rw-rw-r-- 1 shaarli shaarli 2149 Jan 24 12:47 config.json.php
-rw-r--r-- 1 shaarli shaarli 103587 Jan 24 12:47 datastore.20210124124732_1.php
-rw-rw-r-- 1 shaarli shaarli 127551 Jan 24 12:47 datastore.php
-rw-rw-r-- 1 shaarli shaarli 531 Jan 19 12:18 history.php
-rw-rw-r-- 1 shaarli shaarli 40229 Jul 1 2020 import.2020-07-01.log
-rw-rw-r-- 1 shaarli shaarli 13600 Jan 19 12:17 log.txt
-rw-r--r-- 1 root root 70 Feb 6 20:09 ori.ipbans.php
-rw-rw-r-- 1 shaarli shaarli 591 Jan 24 12:47 updates.txt
Pas mieux. Je remarque qu’au clic sur le bouton de login dans la page d’accueil (https://domain.me/?do=login), aucune requête n’est déclenchée. En revanche, j’ai quelques erreurs, mais c’est peut-être “normal”
La ressource à l’adresse « https://domain.me/ynh_portal.js » a été bloquée en raison d’un type MIME (« text/html ») incorrect (X-Content-Type-Options: nosniff).
ainsi que
Le cookie « SSOwAuthRedirect » a été rejeté car il a déjà expiré.
Pour contourner le problème, que je n’ai pas résolu, j’ai désinstallé l’application Shaarli et restauré la sauvegarde créée lors de la mise à jour en suivant la doc.
j’ai ensuite eu une erreur Nginx 502 suite à la restauration (le fichier php7.3-fpm-shaarli.sock n’existait pas) , il a fallu que j’aille modifier la configuration :
éditer /etc/php/7.3/fpm/pool.d/shaarli.conf
y remplacer listen = /var/run/php/php7.0-fpm-shaarli.sock par listen = /var/run/php/php7.3-fpm-shaarli.sock
relancer php : sudo systemctl restart php7.3-fpm
relancer nginx : sudo systemctl restart nginx
Et voilà. Je suis revenu en arrière d’une version de Shaarli mais au moins ça fonctionne. Je ne sais en revanche pas du tout ce qui s’est passé et je ne suis pas certain de retenter la mise à jour dans l’immédiat.
Ok, désolé que ça ait été aussi galère… (l’histoire de version de php, je pense que c’est parce que depuis Debian 10 php7.3 est installé en standard, et on ne doit pas bien gérer la version de php dans les anciennes versions).
Une sauvegarde dans l’état actuel devrait être meilleure si jamais la mise à jour foire. Au pire, fait une sauvegarde de ce fichier de configuration.
ça va, j’ai survécu et il n’y a pas de dégâts. Merci aux contributeurs de Yunohost et aux packagers. Je retenterai la mise à jour au calme, je sais maintenant comment m’en dépétrer si ça foire à nouveau.
J’ai le même souci que @Djiko mais je veux bien essayer de trouver une vrai solution si vous m’aidez !
Chez moi je n’ai pas de fichier ipbans.php.
Ce que je remarque c’est que le dossier tpl est complètement différent entre la version github de shaarli Release v0.12.1 · shaarli/Shaarli · GitHub et ce que j’ai dans mon /var/www/shaarli/tpl.
La version de loginform.html que j’ai fait par exemple appel à une variable can_user_login qui ne semble plus exister ! (et du coup ceci expliquerais que j’ai le message comme quoi je suis “banis”)
J’imagine que quelque chose se passe mal lors de l’installation de l’archive (ou que l’archive n’est pas bonne), mais je ne connais pas assez bien yunohost pour vérifier.
Il paraît que je suis censé le maintenir (mais je ne l’utilise plus, ce qui n’aide pas).
Mais non, aucune idée, puisque ça a l’air de venir de Shaarli et pas du packaging de Yunohost (sinon j’aurais pensé à Fail2Ban) et que je ne sais pas comment il fonctionne.
Cf. mon message. Je suis sur que le problème vient des fichirs installés dans tpl. Peut être peux tu indiquer vers où je dois regarder (comment est fait l’installation des fichiers ?) pour me faire gagner du temps, si tu as ça en tête !