[06:47:05]
<artlog> it looks like upgrade script is not expecting that uPnP is not defined at in old_data; how old is the content of external HDD ? mounting only /home is another topic too.
[06:57:33]
<samuel> Je viens préciser mon message après ma bouteille a la mer.
J'arrive bien a avoir la redirection vers le SSO DEX mais au moment de la connexion, j'ai cette erreur :
> SSO session binding mismatch for uh61XArdsQSSl0ErnjtFzeN2RbcQr2q28af5ZdZybDbkegGghn9hJygZHhDlw7F6\_identifier=00000000-01DC-01DC-01DC-000000000000
[06:57:33]
<artlog> lokking at this : from what content this old_data array is populated ?
[06:57:33]
<artlog> the other thing about the /home : since there is a borg archive, perhaps only applications that don't have there data save in borg are needed in /home/yunohost_apps/${app} , so mounting HDD somewhere else that in /home and bind mounting required apps ... this is app by app then...
[08:25:24]
<artlog> from code it is /etc/yunohost/firewall.yml : this file is not part /home so it comes either from borg backup or was empty
[08:25:36]
<artlog> looking at my /etc/yunohost/firewall.yml there is no uPnP key in this file, it then should either come from library or it dd change ... or ...
[08:25:48]
<artlog> it looks like this migration is for very old data ... to migrate uPnP key to router_forwarding_upnp
[08:25:58]
<artlog> this is a bug indeed : this 0032_firewall_config.py upgrade step was added for 12.0.11 or older confiugrations where uPnP was used, it was then changed to router_forwarding_upnp , so when migration was already done this step will fail.
[08:26:04]
<artlog> Melchisedech: your borg archive might have issues. to activate this migration step your borg archive should indicated a backup version < 12.1 , but in this archive etc/yunohost/firewall.yml was already migrated and does not contains any uPnP .
[08:26:13]
<artlog> Melchisedech: This issue would deserve a Forum post to follow this, if you are not alone in this case to not restart investigation from scratch. there might be some specific context here. Please open a post with yunopaste traces on https://forum.yunohost.org/ , if you did already please mention here what post it is.
[08:26:22]
<artlog> Here i wonder : did you run somehting manualy ? migration of firewall is indeed done automatically by migration step in 0032_firewall_config.py since it provides 'run_after_system_restore' , so you don't have to do anything.
[08:26:39]
<CE418> Bonjour tous, j'ai un soucis avec mes dossiers partagé sur une instance nextcloiud, le dossier /home/yunohost.multimedia/share/ et regulièrement purgé de son contenu, je voudrai utiliser ce dossier pour une autre app est qu'il soit accessible par tout les users.
Le dossier est ajouté dans les stockages externes de nextcloud.
[08:47:41]
<samuel> In case of, I have open this thread :
https://forum.yunohost.org/t/connect-with-oidc-to-vaultwarden-with-dex/42477
[08:53:56]
<CE418> ca semble se purger tout les 20 minutes
[09:15:59]
<Alexandre MOTTIER> Hello par ici, j'ai une petite question pour vous :
Dans mon `/etc/ssowat`, j'ai deux fichiers : un `conf.json` et un `conf.json.persistent`. Jusque-là, rien d'anormal.
En revanche, quand je modifie des accès sur les applications (genre quand je cache mon Gitea derrière le SSO pour éviter les bots de le scanner), je suis obligé de copier manuellement le contenu de `conf.json` vers `conf.json.persistent` pour que ce soit effectif.
Normal ? Il y a peut-être un délai pour que la config passe en persistent alors que moi je veux voir l'effet immédiatement ?
Je pense que c'est un truc tout bête, mais je vois pas 😉
YH 12.1.39 pour info
[09:16:22]
<Alexandre MOTTIER> Hello par ici, j'ai une petite question pour vous :
Dans mon `/etc/ssowat`, j'ai deux fichiers : un `conf.json` et un `conf.json.persistent`. Jusque-là, rien d'anormal.
En revanche, quand je modifie des accès sur les applications (genre quand je cache mon Gitea derrière le SSO pour éviter aux bots de le scanner), je suis obligé de copier manuellement le contenu de `conf.json` vers `conf.json.persistent` pour que ce soit effectif.
Normal ? Il y a peut-être un délai pour que la config passe en persistent alors que moi je veux voir l'effet immédiatement ?
Je pense que c'est un truc tout bête, mais je vois pas 😉
YH 12.1.39 pour info
[09:16:31]
<otm33> Alexandre MOTTIER: Il me semble que le conf.persistent ne doit pas contenir grand chose et permet simplement d'ajouter manuellement des paramètres au conf.json.
[09:17:34]
<Alexandre MOTTIER> Hello par ici, j'ai une petite question pour vous :
Dans mon `/etc/ssowat`, j'ai deux fichiers : un `conf.json` et un `conf.json.persistent`. Jusque-là, rien d'anormal.
En revanche, quand je modifie des accès sur les applications (genre quand je cache mon Gitea derrière le SSO pour éviter aux bots de le scanner), je suis obligé de copier manuellement le contenu de `conf.json` (qui se met à jour) vers `conf.json.persistent` pour que ce soit effectif.
Normal ? Il y a peut-être un délai pour que la config passe en persistent alors que moi je veux voir l'effet immédiatement ?
Je pense que c'est un truc tout bête, mais je vois pas 😉
YH 12.1.39 pour info
[09:17:57]
<Alexandre MOTTIER> En fait, c'est l'inverse : il enregistre mes modifs dans le conf.json, sauf que pas d'effet immédiat. Donc je dois copier conf.json vers conf.json.persistent (et redémarrer Nginx) pour que ce soit effectif
[09:18:03]
<otm33> Est-ce qu'après une modif tu lances `yunohost app ssowatconf` ?
[09:21:15]
<Alexandre MOTTIER> otm33: Nope jamais, je fais les modifs directement sur la WebUI ; j'aurais cru que la WebUI se chargeait de lancer la commande nécessaire ensuite ;-)
[09:21:26]
<otm33> Mouais, cela devrait être suffisant. Tu as un exemple précis de modifiction effectuée via la webadmin et non appliquée ?
[09:25:37]
<Alexandre MOTTIER> otm33: En gros, sur la gestion des groupes, j'ai viré Gitea de l'accès visiteurs, et derrière, pas de prise d'effet. Je sais que j'ai dû copier conf.json vers conf.json.persistent et redémarrer Nginx pour que ça fonctionne, mais je ne me souviens plus si j'ai lancé un `yunohost app ssowatconf`
[09:25:38]
<Alexandre MOTTIER> Après, si c'est un bug connu des devs et corrigé depuis, je peux mettre à jour YunoHost ; j'avoue que je suis de ceux qui ne mettent pas à jour tant que ça marche (je bosse sur Windows en entreprise, on sait ce que font les MàJ Windows hein) 😂
[09:29:30]
<otm33> Pas que je sache. En tout cas copier conf.json vers conf.json.persistent n'est pas la procédure standard pour modifier les paramètres des apps. Il doit y avoir un bug qq part. Ce problème n'est valable que pour gitea ou tu l'as également observé en retirant l'accès visiteurs pour une autre app ?
[09:34:01]
<otm33> Tu as retiré "Gitea" du groupe visteurs dans "Groups and permissions" ou tu as retiré "visiteurs" dans "Groups/users allowed to access" sur la page de Gitea ?
[09:34:01]
<Alexandre MOTTIER> otm33: J'ai ce souci pour toute modif SSO ; à moins que ce soit une tâche cron qui doit gérer ça ? Je viens de me souvenir que j'ai des soucis avec cron aussi qui ne lance plus les tâches planifiées alors que le service tourne bien (mais ça je creuserai de mon côté je pense, c'est du Linux pas du YunoHost).
[09:36:12]
<artlog> rien que trouver la descriptoin de la fonctionnalité mutlimedia... https://forum.yunohost.org/t/understanding-multimedia-folders-in-yunohost/41222
[09:42:53]
<Alexandre MOTTIER> otm33: Dans "Groups and permissions" ;-)
[09:42:53]
<otm33> Alexandre MOTTIER: Pas de rapport avec cron mais la sucharge via conf.json.persistent c'est bien curieux et ça peut ajouter des problèmes...
[09:42:53]
<Alexandre MOTTIER> otm33: J'avoue que je comprends pas trop non plus... :-(
[09:42:53]
<artlog> ça ne semble pas trop normal ... je regarderais autours du cron.php de nextcloud ... mais pourquoi les purger ... je n'ai aps trouvé de chose en ce sens dans le code de yunohost, mais j'avoue que je décourvre un peu tout yunohost.multimedia
[09:50:09]
<CE418> j'ai, je pense, compris l'idée des dossiers (https://doc.yunohost.org/fr/admin/tutorials/external_storage#1-identifier-les-dossiers-%C3%A0-d%C3%A9placer) mais effectivement il y a cette purge qui m'enkikinne 🫠
[18:25:02]
<artlog> pour cehrcher ce genre de problème je créérai un répertoire sous /home/yunohost.multimedia/share/ avec uniquement les droits pour root en espérant que la tache de nettoyage laisse une trace dans les logs lors de sa tentative de purge, comme ça on identifie qui fait la purge.
[18:25:04]
<isAAAc> ou greper le path dans /etc/cron* pour tenter de trouver le cron ?
`grep -Ri "/home/yunohost.multimedia/share/" /etc/cron*` ?
[19:01:39]
<·☽•Nameless☆•777 · ±> Ou ```systemctl list-timers ```
[19:20:16]
<breacher> Whats weird is that it only happens when the user is named "hallo"
[19:20:41]
<orhtej2> does `yunohost-api` log have anything to say?
[19:21:02]
<breacher> No, it doesn't say anything
[19:31:01]
<samuel> Bonsoir
La fonction uPNP est-elle prévu pour fonctionner avec n'importe quel routeur ?
[20:20:57]
<Driawyn> À ma connaissance le protocole upnp est un standard qui fonctionne de la même façon peu importe le routeur. Donc oui
[20:20:57]
<samuel> https://aria.im/_bifrost/v1/media/download/AYKP27cI1agotyz2oKGQ2iGc16cd6RXzMLZS2NpSa4XDcfzSgaKbFZmR8Fw0lwzBNYiRR9f4ou2h0Q3WuYj0BaxCee3GTasQAG1hdHJpeC5hcHBzLnJvbG9uLmZyL1Bkd1FpRUlDTlNpWkJXTmdxRXlkVG1QdQ
[20:33:56]
<samuel> Je viens de faire plusieurs tests sur mon routeur. Je vois bien les requetes UPNP mais la gateway ne met pas en face l'IP WAN
[20:33:56]
<samuel> (Routeur Unifi, il peut gerer plusieurs sortie WAN)
[20:36:57]
<samuel> Désolé, ça fait un peu cross-post mais je savais pas trop ce qui était le plus "actif" ou suivi
[20:36:57]
<artlog> samuel: j'avais vu ton post sur le forum https://forum.yunohost.org/t/upnp-not-working-with-unifi-dream-machine/42478 , mais je n'ai pas idée de ce que prévoit upnp pour le mutlii wan et encore moins où cela pourrait se configurer dans yunohost...
[20:44:03]
<samuel> J'essaye de comprendre, je vais regarder pour prendre des trace rsx car j'aimais bien ne pas me palucher la MAJ des règles de NAT grace a l'UPnP
[20:45:56]
<samuel> je pensais que "par défaut" l'uPNP s'appliquerai au moins sur le WAN 1... voir même sur le seul wan actif
[20:45:56]
<artlog> y a t'il un setup 'par défaut' côté unify, genre default WAN
[20:45:57]
<artlog> quand à unify ils déconseillenet just d'utiliser upnp : https://help.ui.com/hc/en-us/articles/12648697125783-UniFi-Gateway-UPnP
[20:45:57]
<samuel> nan. enfin de toute façon j'ai qu'un seul wan actif là
[20:47:56]
<samuel> mais je pense que c'es p-e côté unifi ceci dis en creusant un peu
je vais leur ouvrir un ticket par curiosité
[20:50:56]
<samuel> ouais bon, dans un monde merveilleux on serait tous en IPv6 toussa toussa ...
[21:31:21]
<artlog> chiche !
[21:31:23]
<samuel> je préfère IPv8; le draft de la RFC a l'air bien plus prometteuse
[21:38:54]
<Melchisedech[m]> Well, I noticed some other bugs (such as emails not working) so I guess I did things the wrong way. Actually, I restored the conf with borg before upgrading the system.
So, I flashed my SD Card again, began by running postinstall (although the doc said not to), made my Yunohost up to date AND THEN restored the conf. Now, everything is working.
[21:40:50]
<Melchisedech[m]> Juste une question, peut-être très conne. Dans `/home/yunohost.app` j’ai les dossiers de mes anciennes applications. Genre nextcloud ou vaultwarden. Si au lieu de restaurer une archive je fais une nouvelle installation, que deviennent ces dossiers ? Sont-ils pris comme base ou sont-ils écrasés ?
[21:41:45]
<Melchisedech[m]> Autrement dit, si j’installe un nextcloud tout neuf alors que `/home/yunohost.app/nextcloud` contient plus de 300 Go de fichiers, que deviennent ces derniers ?