Bonjour,
je trouve un bug avec Libreto sur mon serveur et sur le votre aussi apparement… Vous sauriez si c’est lié àux mise à jour de Yunohost ??
En cliquant sur Écrire j’ai ce message:
Quelqu’un saurait comment corriger ce bug innatendu ? Ou est-ce que ça vient de mon navigateur ? de ma connexion partagée avec un smartphone ??
Bon, toujours pas de solution, j’ai ouvert une issue sur le projet:
Est-ce que vous aussi vous avez ce soucis ? ici par exemple: camp-chatons-2022 - Libreto
Zut je découvre que c’est un bug avec le navigateur !! firefox-91.13.0.esr(64bits), je viens d’essayer d’installer Epiphany et il ouvre bien les pads en écriture !! ou alors un problème avec mes extensions…
Trouvé ! c’est l’extension DuckDuckGo Privacy Essentials qui créé ce bug quand elle est activée !! pardon pour ce post…
Pas de soucis, j’ai pas eu le temps de te répondre avant que tu trouves.
Ça peut aussi arriver en utilisant des pads d’un autre nom de domaine que celui du libreto (et en fonction des header HTTP genre CSP et compagnie).
Par contre, libreto n’est pas très bien optimisé et du coup il faut adapter l’etherpad un peu si il y a beaucoup d’usagers en éditant la propiété importExportRateLimiting
Ci-dessous un petit hook pour que ça s’applique après chaque upgrade d’etherpad
/etc/yunohost/hooks.d/post_app_upgrade/05-etherpad_mypads
#!/bin/bash
source /usr/share/yunohost/helpers
app=$YNH_APP_INSTANCE_NAME
if [[ "$app" == "etherpad_mypads" ]]; then
ynh_write_var_in_file --file=/var/www/etherpad_mypads/settings.json --key=max --value=100 --after=importExportRateLimiting
systemctl restart etherpad_mypads
fi
Super, merci, du coup j’ai éditer ce ficher et un sudo yunohost app upgrade libreto -F pour lancer le script, je peux maintenant accéder à la page en laissant l’extension activée…
Salut, juste une question qui me taraude. Depuis que j’ai ce hook, à chaque upgrade d app j’ai ce message incompréhensible, par exemple pour mattermost (là j’avais renommer le hook 71-etherpad_mypads)
262795 SUCCESS mattermost upgraded
262825 DEBUG Executing command '['sh', '-c', '/bin/bash -x "./71-etherpad_mypads" 7>&1']'
262832 DEBUG + source /usr/share/yunohost/helpers
262832 DEBUG +++ set +o
262833 DEBUG +++ grep xtrace
262834 DEBUG ++ readonly 'XTRACE_ENABLE=set -o xtrace'
262834 DEBUG ++ XTRACE_ENABLE='set -o xtrace'
262834 DEBUG ++ set +x
262848 DEBUG + app=mattermost
262848 DEBUG + [[ mattermost == \e\t\h\e\r\p\a\d\_\m\y\p\a\d\s ]]
263856 DEBUG To view the log of the operation 'Upgrade the 'mattermost' app', use the command 'yunohost log show 20230307-131254-app_upgrade-mattermost'
264067 DEBUG The permission database has been resynchronized
264308 DEBUG SSOwat configuration regenerated
264314 SUCCESS Upgrade complete
ou pour cryptpad
2023-02-26 23:54:20,490: SUCCESS - cryptpad upgraded
2023-02-26 23:54:20,496: DEBUG - Executing command '['sh', '-c', '/bin/bash -x "./71-etherpad_mypads" 7>&1']'
2023-02-26 23:54:20,501: DEBUG - + source /usr/share/yunohost/helpers
2023-02-26 23:54:20,501: DEBUG - +++ set +o
2023-02-26 23:54:20,502: DEBUG - +++ grep xtrace
2023-02-26 23:54:20,503: DEBUG - ++ readonly 'XTRACE_ENABLE=set -o xtrace'
2023-02-26 23:54:20,503: DEBUG - ++ XTRACE_ENABLE='set -o xtrace'
2023-02-26 23:54:20,503: DEBUG - ++ set +x
2023-02-26 23:54:20,518: DEBUG - + app=cryptpad
2023-02-26 23:54:20,518: DEBUG - + [[ cryptpad == \e\t\h\e\r\p\a\d\_\m\y\p\a\d\s ]]
Cela n’a pas l’air de causer un problème, mais j’imaginai plutôt voir quelque chose comme
[[ cryptpad != \e\t\h\e\r\p\a\d\_\m\y\p\a\d\s ]]
Qu’en penser ?
Le hook est lancé à chaque upgrade d’app (peut importe laquelle). On souhaite que les actions du hook ne soient déclenchées que si l’app mise à jour est etherpad_mypads. On cherche donc à tester…
… si l’app mise à jour est etherpad_mypads
if [[ "$app" == "etherpad_mypads" ]]; then
Alors on écrit 100 dans le paramètre importExportRateLimiting.max du fichier /var/www/etherpad_mypads/settings.json puis on relance le service
ynh_write_var_in_file --file=/var/www/etherpad_mypads/settings.json --key=max --value=100 --after=importExportRateLimiting
systemctl restart etherpad_mypads
Ok, j’ai compris… merci