[09:52:28]
<Yunohost Git/Infra notifications> [yunohost] ewilly opened [pull request #2176](https://github.com/YunoHost/yunohost/pull/2176): Fix ynh_add_swap helper
[09:57:06]
<Yunohost Git/Infra notifications> [yunohost] ewilly [commented](https://github.com/YunoHost/yunohost/pull/2176#issuecomment-3279632530) on [issue #2176](https://github.com/YunoHost/yunohost/pull/2176) Fix ynh_add_swap helper: Once merged, that workaround could be removed: - https://github.com/YunoHost-Apps/immich_ynh/blob/f1b8557e127accfaea284...
[17:21:05]
<lautre> Si à chaque fois qu'il y aurait un `curl 127.0.0.1` pour les installations ou les mises à jour il y aurait aussi un `curl ::1` en cas d'échec du premier, ça simplifierait pas mal de trucs quand le Yunohost est derrière un Proxy-sni, et ce serait transparent.
[17:23:46]
<Yunohost Git/Infra notifications> [yunohost] OniriCorpe approved [pull request #2176](https://github.com/YunoHost/yunohost/pull/2176#pullrequestreview-3212934331) Fix ynh_add_swap helper
[17:24:13]
<Yunohost Git/Infra notifications> [yunohost] OniriCorpe pushed to dev: Fix ynh_add_swap helper chattr +C is possible on a btrfs filesytem but for example produce an error on ext4 ([8708946f](https://github.com/YunoHost/yunohost/commit/8708946f22df527da75fe1463d522a8e17a7e5a7))
[17:24:13]
<Yunohost Git/Infra notifications> [yunohost] OniriCorpe merged [pull request #2176](https://github.com/YunoHost/yunohost/pull/2176): Fix ynh_add_swap helper
[17:27:00]
<Aleks (he/him/il/lui)> heu tu peux expliquer le lien avec le SNI ...?
[17:29:30]
<Émy – OniriCorpe> could be great to also `chattr +C` the databases
[17:29:51]
<Émy – OniriCorpe> but we have to do it on db creation, when the file is empty...
[17:30:06]
<Yunohost Git/Infra notifications> 🏗️ Starting build for yunohost/12.1.22+202509111930 for bookworm/unstable/all...
[17:31:45]
<Yunohost Git/Infra notifications> ✔️ Completed distribution for yunohost/12.1.22+202509111930 for bookworm/unstable.
[17:31:45]
<Yunohost Git/Infra notifications> ✔️ Completed build for yunohost/12.1.22+202509111930 for bookworm/unstable/all.
[17:54:44]
<lautre> > <@Alekswag:matrix.org> heu tu peux expliquer le lien avec le SNI ...?
À cause du SNI, la requête curl 127.0.0.1 échoue parce que les certificats ne sont pas bons. En ipv6, ça passe crème.
Tout ça parce que dans mes config nginx, je suis obligé d'ajouter un proxy_protocol sur la ligne en ipv4, pas en ipv6
[17:56:38]
<Aleks (he/him/il/lui)> hmmm
[17:57:22]
<Aleks (he/him/il/lui)> mouai ok genre faut forcément parler en proxy protocol et pas en "raw HTTP" sur l'ipv4 dans ce cas
[17:58:48]
<Aleks (he/him/il/lui)> ou alors on pourrait autoriser le traffic HTTP en clair vers les apps si la requête viens de 127.0.0.1 vu que ça sert pas à grand chose du http en local loop
[18:00:17]
<Aleks (he/him/il/lui)> ou faire un listen sur un autre port que 443 pour la version proxy_protocol 🤔
[18:01:14]
<Aleks (he/him/il/lui)> ou alors je m'demande si on pourrait faire en sorte que le traffic venant de l'exterieur soit géré via proxy_protocol mais pas le traffic venant de 127.0.0.1 genre avec deux `listen` différents
[18:03:12]
<lautre> J'ai essayé de trouver comment ne pas avoir proxy_protocol pour 127.0.0.1, sans succès.
Ce que je fais, c'est une boucle pour changer toutes les config, puis je fais l'installation ou la mise à jour, puis je remets en état.
Donc, pendant l'opération, aucun site n'est fonctionnel sauf en ipv6.