Je suis pas super actif, mais actif quand même. Je regarde ce soir. Mais si tu veux y jeter un oeil, aucun pb. Tu peux faire une PR dans le dépôt : https://github.com/YunoHost-Apps/garradin_ynh. Il y a des PR qui ont été faites aussi, mais je n’ai pas pu tester pour l’instant (et je ne suis pas convaincu de leur fonctionnement).
Salut,
j’ai discuter sur le salon apps de yunohost hier à propos des choses à faire encore pour améliorer l’application. Là j’ai pu l’installer, mais il faut modifier un fichier créer lors de l’installation config.local.ph. Au départ, il y a le fichier config.dist.php dans le fichier d’installation. À la fin de l’installation, il faudrait copier le lignes de ce fichier pour les ajouter au fichier config.local.ph en changeant ainsi ces lignes.
const ROOT = '/var/www/garradin';
const WWW_URI = '/garradin/';
const SECRET_KEY = 'changer_cette_clé_par_défaut_?';
Puis il faudrait aussi que cette manipulation soit dans les fichiers update, change_url aussi.
Me reste à trouver comment mettre en place ce script, avec ynh_replace_string et/ou cp ? Je vais devoir tester tout cela.
Sinon, la chose importante que j’ai trouver est de remplacer
/var/run/php5-fpm-__NAME__.sock;
par
/var/run/php/php7.0-fpm-__NAME__.sock
Je ne sais pas si il faudrait aussi supprimer ensuite le fichier /www/index.php ??
Mon fork pour tester est ici: https://github.com/rodinux/garradin_ynh/
Je vais petit à petit voir comment faire et comment améliorer tout cela…
Peut-être faut-il pour les Si debian version = “jessie” Alors ynh_die, car c’est obsolète maintenant, non ?
Aussi je crois qu’il doit y peut-être avoir des choses à faire côté nginx (mais c’est peut-être déjà bon ?: Adaptez la configuration : il faut interdire l’accès aux répertoires include, cache, plugins et templates, ainsi que l’accès aux fichiers *.sqlite, et faire rediriger les pages non trouvées dans www/ sur www/index.php ou faut-il supprimer ce fichier index.php ?
Je prépare une installation avec virtualbox sur un autre OS, car sur ma Debian Buster, ce n’est pas conseillé d’avoir Virtualbox et je galérais un peu avec vagrant. Donc je fais un peu de mise en place d’outils, je relis bien la doc du contributeur, et je te préviens dès que je suis satisfait. Dans l’idéal, j’espère que ce sera possible de faire une upgrade en gardant bien sa base de données…
Bonsoir,
j’ai passer un peu de temps sur le fichier.
Déjà j’arrive à installer garradin avec mon script qui est placé dans un dossier hooks https://github.com/rodinux/garradin_ynh/tree/master/hooks
Par contre je n’arrive pas à mettre à jour de la version actuelle à la nouvelle version…
J’ai essayer plusieurs choses.
Voici des logs que j’obtiens en essayant un
sudo yunohost app upgrade garradin -u https://github.com/rodinux/garradin_ynh
https://paste.yunohost.org/raw/isumixuxej
https://paste.yunohost.org/raw/hefogamapa
Finalement, le plus simple est de télécharger la sauvegarde via Garradin et de la réinstallée, mais c’est limité à maximum 2Mo (quoique, c’est déjà beaucoup)
… Ou dans le dossier upgrade arriver à sauvegarder la bdd (par défaut association.sqlite)
Ce n’est pas si simple vu la doc: https://fossil.kd2.org/garradin/wiki?name=Mise%20à%20jour
J’ai fait un test de sauvegarde de la bdd pendant l’installation qui foire encore voici les logs (longs), mais ça y est presque…
https://paste.yunohost.org/raw/ejunucuveq
Ça y est, j’y suis arrivé ! j’ai réussi à faire une upgrade sans perdre la base de données !!
Mieux encore, j’ai aussi essayé de faire une sauvegarde, de supprimer l’application et la restaurer, pareil, ça marche !
Il faut que je fasse un PR maintenant. Depuis mon PR, la version est améliorée et j’ai supprimé le dossier hooks (pas nécessaire)
Je discute avec le salon yunohost_apps. J’ai mis ma version sur Jenkins pour voir les résultats de package_check.
J’ai encore amélioré des choses, par contre j’ai un soucis, avec Jenkins pour le package_check, il trouve un échec pour le script upgrade, car j’ai mis des lignes de code pour garder un backup de la bdd et du dossier squelettes qui permet de restaurer les configurations, mais évidemment, sur une fraîche installation, la bdd n’existe pas encore, puisque on est qu’il manque la post-installation… Du coup il failed.
Ah, ça y est j’y suis presque tout de même, la fin de mon dernier push sur jenkins donne à la fin:
Package linter: SUCCESS
Installation: SUCCESS
Deleting: SUCCESS
Installation in a sub path: SUCCESS
Deleting from a sub path: SUCCESS
Installation on the root: FAIL
Deleting from root: SUCCESS
Upgrade: SUCCESS
Installation in private mode: SUCCESS
Installation in public mode: SUCCESS
Multi-instance installations: SUCCESS
Malformed path: SUCCESS
Port already used: Not evaluated.
Backup: SUCCESS
Restore: SUCCESS
Change URL: Not evaluated.
Level of this application: 1 (Installable)
Level 1: 1
Level 2: 0
Level 3: 1
Level 4: 1
Level 5: 1
Level 6: 1
Level 7: 1
Level 8: 0
Level 9: 0
Level 10: 0
Pourtant j’ai bien tester aussi les changements d’url de domaine et de path, je sais que ça marche… strange
Ouf, cette fois c’est bon ! @frju365 qu’est-ce que tu en penses ?
https://ci-apps-dev.yunohost.org/jenkins/job/garradin_ynh%20(rodinux)/15/console
Package linter: SUCCESS
Installation: SUCCESS
Deleting: SUCCESS
Installation in a sub path: SUCCESS
Deleting from a sub path: SUCCESS
Installation on the root: SUCCESS
Deleting from root: SUCCESS
Upgrade: SUCCESS
Installation in private mode: SUCCESS
Installation in public mode: SUCCESS
Multi-instance installations: SUCCESS
Malformed path: SUCCESS
Port already used: Not evaluated.
Backup: SUCCESS
Restore: SUCCESS
Change URL: SUCCESS
Actions and config-panel: Not evaluated.
Level of this application: 7 (Successfully pass functional tests)
Level 1: 1
Level 2: 1
Level 3: 1
Level 4: 1
Level 5: 1
Level 6: 1
Level 7: 1
Level 8: 0
Level 9: 0
Level 10: 0
1 Like
@Aleks, I am afraid with the PR you have push on the testing branch today ti fix path travesal, I think the script change_url will found a mistake. I have try on local virtualbox, when you change the subpath the adress becomes https://domain.tld/subpath/ with the trailing slash at the end and without like https://domain.tld/subpath it did not redirect to the app page, so clicking in the SSO, you are redirect to a 404 error…
I am trying to put the code (after pull the current testing branch) on jenkins to see also the errors…
It is strange, jenkins show only errors on restore_script ??
https://ci-apps-dev.yunohost.org/jenkins/job/garradin_ynh%20(rodinux)/35/console
Level of this application: 3 (Can be updated)
It is also strange that for every tests with success we have this advertisement before Success:
Test url: sous.domain.tld/
Real url: https://sous.domain.tld/admin/install.php
and for the restore script’test Failed it finished with:
Test url: sous.domain.tld/path/
Real url: https://sous.domain.tld/path/
I am trying ti see where is the issue (perhaps on the remove script ?)
Well I don’t quite understand why you resurect this old thread which is two years old and has nothing to do with the maintenance of this app instead of for example discussing this directly on the chat or on github or in a new forum thread …
That could help if you can be accurate on where exactly this url that you’re talking about is displayed … URL (domain and path) are in settings, they are in variable, they are in the output of “yunohost app map”, they are in the nginx conf, etc…
Yunohost is supposed to normalize domain and paths where needed, so what you’re talking about should not happen, but can’t really be sure about your issue if you’re provide an accurate description or step-by-step way to reproduce the issue.
As for the path traversal issue, the warning has been there for a while in package linter (something like a year or so), we’re moving to report this as an error (considering it’s a security weakness) for a month now) and PRs have been opened 10+ days ago on all affected apps, so yeah, I ended up arbitrarily merging the change because we’re trying to erradicate the issue.
Note that something like 90% of webapps typically have the same first lines in ngninx.conf looking exactly like
#sub_path_only rewrite ^__PATH__$ __PATH__/ permanent;
location __PATH__/ {
so pretty sure that there’s no reason that Garradin can’t work with this just like all the others app do …
Can be a temporary glitch in the CI, wouldn’t be the first time this happen, by far…
Ok, I don’t really understand what does is mean, but I confirm after trying on a local virtualbox vm to delete and restore Garradin and it works.
You’re right, sorry. I am going to open another issue to resolve in the forum to found help