[12:01:39]
<2plig> Hi everyone! I hope this is the correct place to ask a question. Sorry I don't speak French, hopefully English is OK (but if not I can try to translate via Deepl etc...)
Today, something weird happened with my server and while I think I fixed the problem for now, I need to understand what happened and why.
I ran a system upgrade to 12.1.37. I'm not sure what version I had before that, if someone can help me check it I will be grateful. However, I am almost sure if was major 12 like now.
After upgrade I rebooted my server. After reboot, I found out that SSH access to my server did not work, and neither did accessing the webadmin by the local address (I previously disabled access to admin from non-local subnet). However, requests over my "remote" connection (I had tailscale access configured) worked fine.
After I connected a kb and monitor to my server to do some debugging, I found out in syslog that UFW was blocking my requests within the local subnet. UFW status showed default deny, and allow to 80 and 51820 (I understand that 51820 is for Tailscale). I ran `ufw allow from 192.168.1.0/24 to any port 443` and this solved the problem with access to webadmin. (I did not touch SSH for now.)
My question: could system upgrade result in such a change to UFW? Is what I did a good way to manage such issues? Will it be a good idea to open my SSH port the same way?
[12:07:45]
<2plig> (Also, if anyone would like to see some logs, pastes, etc - let me know what you'd like to see, I will provide.)
[12:13:31]
<2plig> Hi everyone! I hope this is the correct place to ask a question. Sorry I don't speak French, hopefully English is OK (but if not I can try to translate via Deepl etc...)
Today, something weird happened with my server and while I think I fixed the problem for now, I need to understand what happened and why.
I ran a system upgrade to 12.1.37. I'm not sure what version I had before that, if someone can help me check it I will be grateful. However, I am almost sure if was major 12 like now.
After upgrade I rebooted my server. After reboot, I found out that SSH access to my server did not work, and neither did accessing the webadmin by the local address (I previously disabled access to admin from non-local subnet). However, requests over my "remote" connection (I had tailscale access configured) worked fine.
After I connected a kb and monitor to my server to do some debugging, I found out in syslog that UFW was blocking my requests within the local subnet. UFW status showed default deny, and allow to 80 and 51820 (I understand that 51820 is for Tailscale). I ran `ufw allow from 192.168.1.0/24 to any port 443` and this solved the problem with access to webadmin. (I did not touch SSH for now.)
My question: could system upgrade result in such a change to UFW? Or reboot? Is what I did a good way to manage such issues? Will it be a good idea to open my SSH port the same way?
[12:14:48]
<2plig> Oh, and 2 more points for clarification.
- All this time, even when the requests were blocked, port 443 showed as "open" for TCP in Yunohost firewall.
- I access my server via HTTP, not HTTPS, on my local subnet (via tailscale it's a different story, I use letsencrypt cert there). But, as the settings of webadmin say "Redirect HTTP requests to HTTPs by default (DO NOT TURN OFF unless you really know what you're doing!)" I kept the "Force HTTPS" setting on. So, obviously, even requests over HTTP went to 443 instead of 80. If closing 443 in UFW by default is expected behavior, maybe this wording in settings should be changed?
[12:15:29]
<2plig> Oh, and 2 more points for clarification.
- All this time, even when the requests were blocked, port 443 showed as "open" for TCP in Yunohost firewall.
- I access my server via HTTP, not HTTPS, on my local subnet (via tailscale it's a different story, I use letsencrypt cert there). But, as the settings of webadmin say "Redirect HTTP requests to HTTPs by default (DO NOT TURN OFF unless you really know what you're doing!)" I kept the "Force HTTPS" setting on. So, I assume, even requests over HTTP went to 443 instead of 80. If closing 443 in UFW by default is expected behavior, maybe this wording in settings should be changed?
[12:19:55]
<2plig> Oh, and 2 more points for clarification.
- All this time, even when the requests were blocked, port 443 showed as "open" for TCP in Yunohost firewall. My SSH port is also still open in Yunohost firewall - but not in UFW, and so SSH access still does not work.
- I access my server via HTTP, not HTTPS, on my local subnet (via tailscale it's a different story, I use letsencrypt cert there). But, as the settings of webadmin say "Redirect HTTP requests to HTTPs by default (DO NOT TURN OFF unless you really know what you're doing!)" I kept the "Force HTTPS" setting on. So, I assume, even requests over HTTP went to 443 instead of 80. If closing 443 in UFW by default is expected behavior, maybe this wording in settings should be changed?
[12:30:49]
<@err404:matrix.numericore.com> letsencrypt need http, so you need to have an open port 80 when you want renew certs
[12:32:48]
<2plig> 80 was open the whole time, I think there are no problems with it.
[12:33:16]
<2plig> The question is why did system upgrade and/or reboot caused 443 to become blocked.
[12:33:52]
<@err404:matrix.numericore.com> hum, may be your ip where banned?
[12:36:30]
<@err404:matrix.numericore.com> (my english skills is not realy good, I need reread your messages)
[12:36:46]
<2plig> No problem. But this is not ban issue, I checked, fail2ban jails were empty.
UFW status was "default deny, allow 80 and 51820". Since it did not have allow 443, I did not have access. But I had access before upgrade+reboot.
[12:42:54]
<Chatpitaine Caverne> 2plig: Maybe a check of the nftables conf would help :
`sudo yunohost tools regen-conf nftables --dry-run --with-diff`
I don't remembrer when the change was done in Yunohost (maybe first release of 12, maybe later), but they passed from iptables to nftables as firewall tool.
[12:49:18]
<2plig> I received no output from this
[12:50:55]
<Chatpitaine Caverne> Ok, this mean it's up to date. Which is normal cause a yunohost upgrade includes a global regen-conf. Was just to check if that was not that.
[12:51:47]
<Chatpitaine Caverne> Ok, this mean it's up to date. Which is normal (but normal and computers...)cause a yunohost upgrade includes a global regen-conf. Was just to check if that was not that.
[12:56:04]
<2plig> Maybe more "radical" question - is it even normal that I have UFW? I do not remember since when I had it, but after quick check on forums, it does not seem that Yunohost includes or uses it by default.
[13:19:07]
<Chatpitaine Caverne> On my server, there is a nftable service running. And no sign of ufw in my syslog. To be sure, how can I check if ufw is acting somehow ?
[13:19:08]
<Chatpitaine Caverne> On my server, there is a nftables service running. And no sign of ufw in my syslog. To be sure, how can I check if ufw is acting somehow ?
[13:23:19]
<2plig> Maybe, just try `sudo ufw status`?
[13:25:03]
<Chatpitaine Caverne> ufw command is not even installed. Looks like a response to your radical question.
[13:25:37]
<2plig> Yeah, definitely.
[13:28:05]
<2plig> (But if no one wants to comment on those here, given that this is a Yunohost support room and not general linux sysadmin support - no problem)
[13:28:29]
<2plig> So I guess this question is out of the scope of Yunohost. Rather a general question - what could cause a UFW rule to disappear after reboot, and is it secure to leave 80, 443 and my SSH port open. (I am still not forwarding them on my router, the external access is only via Tailscale.)
[13:32:01]
<Chatpitaine Caverne> All I can say is the Yunohost documentation on security questions, hope this help :
https://doc.yunohost.org/en/admin/security/
[13:33:38]
<Chatpitaine Caverne> It's usually nor recommended to have a port 22 SSH opened on the Internet, but your are behind Tailscale and fail2ban is acting on SSH in Yunohost.
[13:34:50]
<2plig> Oh, 22 is out of the question, my SSH port is custom
[14:30:22]
<2plig> I also have an unrelated question to the previous story. Is there a reliable way to launch a Borg backup for the first time, in a detached manner, so that I can terminate the SSH and walk away?
[14:30:57]
<2plig> I tried with screen, tried with nohup, but no matter what I do - as soon as I detach from the screen session, all Borg processes go to sleep
[14:31:57]
<2plig> (I really wish there was a UI button in the webadmin to "start borg backup now", but seems like such option does not exist)
[14:37:49]
<Chatpitaine Caverne> 2plig: Not good with that, but maybe a cron lauch one time at a close time ?
In the past I was working on AS/400 and we had a SBMJOB (Submit Job) command to lauch batch job. I don't know such fonctionnality in Linux, but I'm interrested.
[14:38:57]
<Chatpitaine Caverne> Maybe : https://linuxcapable.com/how-to-use-the-batch-command-in-linux/
[14:46:51]
<homelab-fr> Bonjour à tous, je suis novice et j'essaye d'installer Yunohost 13 beta. J'ai fait cela via une machine virtuelle. J'ai installé débian 13 et par dessus Yunohost. J'ai bien l'interface de Yunohost 13 via mon navigateur, j'ai rajouté un domaine qui tourne uniquement en local du type yh13.arpa et j'ai changé le fichier host sur mon ordinateur pour pouvoir acceder au serveur Yunohost sans avoir à inscrire l'adresse ip dans mon navigateur mais directement le domaine yh13.arpa. Tout fonctionne sauf quand j'essaye d'installer une application (j'ai avant cela fait un update / upgrade comme il faut). Voici le message que j'ai :
Installer l'application '{}'
YunoHost a rencontré une erreur interne
Vraiment désolé de cela.
Vous devez chercher de l'aide sur le forum ou le chat pour corriger la situation, ou signaler le bug sur le bugtracker.
Les informations suivantes peuvent être utiles à la personne qui vous aide :
Erreur: "500"
Action: "POST" /yunohost/api/apps
Message d'erreur :
Erreur serveur inattendue
Retraçage
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/moulinette/interfaces/api.py", line 430, in process
ret = self.actionsmap.process(arguments, timeout=30, route=_route)
File "/usr/lib/python3/dist-packages/moulinette/actionsmap.py", line 580, in process
return func(**arguments)
File "/usr/lib/python3/dist-packages/yunohost/log.py", line 532, in func_wrapper
result = func(*args, **kwargs)
File "/usr/lib/python3/dist-packages/yunohost/app.py", line 1462, in app_install
raise e
File "/usr/lib/python3/dist-packages/yunohost/app.py", line 1455, in app_install
AppResourceManager(app_instance_name, wanted=manifest, current={}).apply(
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
rollback_and_raise_exception_if_failure=True,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
operation_logger=operation_logger,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
action="install",
^^^^^^^^^^^^^^^^^
)
^
File "/usr/lib/python3/dist-packages/yunohost/utils/resources.py", line 56, in apply
todos = list(self.compute_todos())
File "/usr/lib/python3/dist-packages/yunohost/utils/resources.py", line 132, in compute_todos
wanted_resource = AppResourceClassesByType[name](infos, self.app, self)
File "/usr/lib/python3/dist-packages/yunohost/utils/resources.py", line 466, in __init__
super().__init__({"sources": properties}, *args, **kwargs)
~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/yunohost/utils/resources.py", line 188, in __init__
"__YNH_DEBIAN_VERSION_ID__": str(debian_version_id()),
~~~~~~~~~~~~~~~~~^^
File "/usr/lib/python3/dist-packages/yunohost/utils/system.py", line 63, in debian_version_id
return int(os_release()["VERSION_ID"]) # type: ignore[return-value]
ValueError: invalid literal for int() with base 10: '"13"'
[15:06:56]
<·☽•Nameless☆•777 · ±> Avec une autre application, tu as la même chose ?
( c'est peut-être dû à la version bêta )
[15:07:39]
<·☽•Nameless☆•777 · ±> Normalement, pour un domaine privé, il est recommandé d'utiliser ``` home.arpa. ```
[15:13:23]
<homelab-fr> ah je ne savais pas pour home.arpa je vais changer.
par contre c'est peut-être tt bête mais en demandant à l'IA, elle me dit que si je fais cela dans mon terminal :
sudo sed -i.bak -E 's/^VERSION_ID="([0-9]+)"$/VERSION_ID=\1/' /etc/os-release /usr/lib/os-release
C'est à dire si j'ai bien compris :
grep -nE '^(NAME|VERSION|VERSION_ID)=' /etc/os-release /usr/lib/os-release 2>/dev/null
/etc/os-release:2:NAME="Debian GNU/Linux"
/etc/os-release:3:VERSION_ID="13"
/etc/os-release:4:VERSION="13 (trixie)"
/usr/lib/os-release:2:NAME="Debian GNU/Linux"
/usr/lib/os-release:3:VERSION_ID="13"
/usr/lib/os-release:4:VERSION="13 (trixie)"
on enlève les guillemets autour de VERSION_ID (c’est ce qui fait échouer int() côté YunoHost).
J'ai donc fait cela et j'ai enfin réussi à installé Adguard, c'est un peu bête je trouve comme erreur si c'est juste ça. J'imagine que cela doit être fait exprès ?
J'ai demandé à l'IA pourquoi car je ne comprends pas. Voici la réponse que j'ai eu :
Oui, c’est “étrange” dans le sens où ce n’est pas un problème AdGuard Home, mais un bug de parsing dans YunoHost (ou une partie de sa stack) sur Debian 13.
Ce qui s’est passé, précisément :
YunoHost essaie de lire VERSION_ID via /etc/os-release, puis de faire int(VERSION_ID).
Chez toi, VERSION_ID valait "13" (avec guillemets), et l’appel tentait de convertir la chaîne incluant les guillemets en entier, ce qui donne l’erreur : ValueError: invalid literal for int() with base 10: '"13"'.
La commande sed a simplement transformé VERSION_ID="13" en VERSION_ID=13, donc la conversion en entier fonctionne.
Deux points importants :
Les guillemets dans os-release sont normalement autorisés (c’est très courant). Donc ce n’est pas Debian qui “fait n’importe quoi” : c’est bien un bout de code qui lit mal la valeur (il aurait dû retirer les guillemets).
Tu as modifié un fichier système. Ça marche, mais c’est un contournement : une mise à jour peut remettre les guillemets.
Étape suivante (recommandée, simple) : vérifier si ton système a un “override” ou un fichier qui réécrit os-release, et garder la trace du backup.
Exécute uniquement : ls -l /etc/os-release /usr/lib/os-release /etc/os-release.bak /usr/lib/os-release.bak 2>/dev/null
Si tu veux rester propre à long terme, la vraie correction sera côté YunoHost (strip des guillemets avant int()), mais en attendant, ton contournement explique parfaitement pourquoi “ça marche seulement avec cette commande”.
[15:50:11]
<Aleks (he/him/il/lui)> il y a des quotes `"` autour du 13, le probleme a été corrigé dans https://github.com/YunoHost/yunohost/pull/2242/files mais pas le correctif est pas encore publié ...
[16:58:09]
<Chatpitaine Caverne> Je n'en peux plus. Ce n'était donc pas ma manip' osée de modifier les fichiers de config à la volée suite à leur restauration dans tmp qui était la cause de l'erreur de module non trouvé.
Au secours !
Si quelqu'un a une idée, ben, j'lui fait un gros câlin.
Y'a pas moyen de tordre le programme de restauration pour juste s'arrêter si le service ne démarre pas et ne pas tout désinstaller, je veux dire, c'est la dernière ou quasi dernière étape après environ 5 heures de restauration...
```
yunohost backup restore 2025-12-23-042457_peertube.tar
Info: Preparing archive for restoration…
Info: Restoring peertube…
Info: Provisioning sources...
Info: Provisioning system_user...
Info: Provisioning install_dir...
Info: Provisioning data_dir...
Info: Provisioning permissions...
Info: Provisioning ports...
Success! Configuration updated for 'nftables'
Info: Provisioning apt...
Info: Provisioning database...
Info: Provisioning nodejs...
Info: [+++.................] > Restoring the app main directory...
Info: [###+++..............] > Restoring the data directory...
Info: [######++++..........] > Restoring the PostgreSQL database...
Info: [##########+++.......] > Restoring system configurations related to peertube...
Info: [#############+++....] > Reloading NGINX web server and peertube's service...
Warning: (this may take some time)
Warning: The service peertube didn't fully execute the action start before the timeout.
Warning: Please find here an extract of the end of the log of the service peertube:
Warning: Dec 23 17:46:23 peertube[460953]: at legacyMainResolve (node:internal/modules/esm/resolve:204:26)
Warning: Dec 23 17:46:23 peertube[460953]: at packageResolve (node:internal/modules/esm/resolve:777:12)
Warning: Dec 23 17:46:23 peertube[460953]: at moduleResolve (node:internal/modules/esm/resolve:853:18)
Warning: Dec 23 17:46:23 peertube[460953]: at defaultResolve (node:internal/modules/esm/resolve:983:11)
Warning: Dec 23 17:46:23 peertube[460953]: at #cachedDefaultResolve (node:internal/modules/esm/loader:731:20)
Warning: Dec 23 17:46:23 peertube[460953]: at ModuleLoader.resolve (node:internal/modules/esm/loader:708:38)
Warning: Dec 23 17:46:23 peertube[460953]: at ModuleLoader.getModuleJobForImport (node:internal/modules/esm/loader:310:38)
Warning: Dec 23 17:46:23 peertube[460953]: at ModuleJob._link (node:internal/modules/esm/module_job:182:49) {
Warning: Dec 23 17:46:23 peertube[460953]: code: 'ERR_MODULE_NOT_FOUND'
Warning: Dec 23 17:46:23 peertube[460953]: }
Warning: Dec 23 17:46:23 peertube[460953]: Node.js v22.21.1
Warning: Dec 23 17:46:23 systemd[1]: peertube.service: Main process exited, code=exited, status=1/FAILURE
Warning: Dec 23 17:46:23 systemd[1]: peertube.service: Failed with result 'exit-code'.
Warning: Dec 23 17:46:23 systemd[1]: peertube.service: Consumed 1.701s CPU time.
Warning: Dec 23 17:46:24 systemd[1]: peertube.service: Scheduled restart job, restart counter is at 10.
Warning: Dec 23 17:46:24 systemd[1]: Stopped peertube.service - PeerTube: video streaming platform.
Warning: Dec 23 17:46:24 systemd[1]: peertube.service: Consumed 1.701s CPU time.
Warning: Dec 23 17:46:24 systemd[1]: peertube.service: Start request repeated too quickly.
Warning: Dec 23 17:46:24 systemd[1]: peertube.service: Failed with result 'exit-code'.
Warning: Dec 23 17:46:24 systemd[1]: Failed to start peertube.service - PeerTube: video streaming platform.
Error: Could not restore peertube: An error occured inside the app restore script
Info: The operation 'Restore 'peertube' from a backup archive' could not be completed. Please share the full log of this operation using the command 'yunohost log share 20251223-145220-backup_restore_app-peertube' to get help
Warning: Here's an extract of the logs before the crash. It might help debugging the error:
Info: WARNING - Dec 23 17:46:23 systemd[1]: peertube.service: Main process exited, code=exited, status=1/FAILURE
Info: WARNING - Dec 23 17:46:23 systemd[1]: peertube.service: Failed with result 'exit-code'.
Info: WARNING - Dec 23 17:46:23 systemd[1]: peertube.service: Consumed 1.701s CPU time.
Info: WARNING - Dec 23 17:46:24 systemd[1]: peertube.service: Scheduled restart job, restart counter is at 10.
Info: WARNING - Dec 23 17:46:24 systemd[1]: Stopped peertube.service - PeerTube: video streaming platform.
Info: WARNING - Dec 23 17:46:24 systemd[1]: peertube.service: Consumed 1.701s CPU time.
Info: WARNING - Dec 23 17:46:24 systemd[1]: peertube.service: Start request repeated too quickly.
Info: WARNING - Dec 23 17:46:24 systemd[1]: peertube.service: Failed with result 'exit-code'.
Info: WARNING - Dec 23 17:46:24 systemd[1]: Failed to start peertube.service - PeerTube: video streaming platform.
Info: DEBUG - + '[' -e systemd ']'
Info: DEBUG - + '[' start == reload ']'
Info: DEBUG - + '[' start == start ']'
Info: DEBUG - + _ynh_clean_check_starting
Info: DEBUG - + '[' -n 459837 ']'
Info: DEBUG - + kill -SIGTERM 459837
Info: DEBUG - + '[' -n /tmp/tmp.WAC9gZc4l4 ']'
Info: DEBUG - + ynh_safe_rm /tmp/tmp.WAC9gZc4l4
Info: DEBUG - + local target=/tmp/tmp.WAC9gZc4l4
Info: DEBUG - + return 1
Info: DEBUG - + ynh_exit_properly
Info: Removing peertube…
Info: [++++++++++..........] > Removing system configurations related to peertube...
Info: [####################] > Removal of peertube completed
Info: Deprovisioning nodejs...
Info: Deprovisioning database...
Info: Deprovisioning apt...
Info: Deprovisioning ports...
Success! Configuration updated for 'nftables'
Info: Deprovisioning permissions...
Info: Deprovisioning data_dir...
Info: Deprovisioning install_dir...
Info: Deprovisioning system_user...
Info: Deprovisioning sources...
Success! peertube uninstalled
Error: The operation 'Restore 'peertube' from a backup archive' could not be completed. Please share the full log of this operation using the command 'yunohost log share 20251223-145220-backup_restore_app-peertube' to get help
Error: Nothing was restored
```
Fatigué.
[17:00:01]
<Aleks (he/him/il/lui)> Chatpitaine Caverne: yes normalement depuis la toute dernière version y'a une option --no-remove-on-failure sur la commande "yunohost backup restore"
[17:00:11]
<Aleks (he/him/il/lui)> tu peux double-check la syntaxe exacte avec `yunohost backup restore --help`
[17:01:33]
<Chatpitaine Caverne> `--no-remove-on-failure For app only, debug option to avoid removing the app on a failed restore`
[17:09:22]
<Chatpitaine Caverne> Merci Aleks (he/him/il/lui) vais tester ça et chercher ce fichu module. Je vous dit demain si ça fonctionne ce nouveau paramètre. Si ça fonctionne avec Murphy qui ne me lâche pas, c'est sûr ça fonctionne tout le temps 😸.
Voilà le câlin promis : 🫂
J'ai tellement plus confiance dans cette migration que j'ai commandé un autre SSD Sata pour le système afin de ne pas avoir à écraser l'ancien au cas où je devrais revenir en arrière.
[17:39:19]
<Chatpitaine Caverne> C'est parti. Je l'avais lancé sans le --app peertube et puis je me suis dis, tu vas voir que le --no-remove-on-failure ne fonctionne que si --app est précisé...
```
yunohost backup restore 2025-12-23-042457_peertube.tar --app peertube --no-remove-on-failure
Info: Preparing archive for restoration…
```
[19:07:29]
<homelab-fr> Merci pour votre retour !
[20:08:57]
<homelab-fr> Petits retour avec YunoHost 13 Beta :
- J'ai du pour l'installer faire depuis Debian trixie : PATH=/sbin:$PATH
curl -fsSL https://install.yunohost.org/trixie | bash -s -- -d testing
- Ensuite il a fallu faire : sudo sed -i.bak -E 's/^VERSION_ID="([0-9]+)"$/VERSION_ID=\1/' /etc/os-release /usr/lib/os-release
Pour corrigé un bug déjà connu (Merci Aleks (he/him/il/lui) )
- Pour l'instant j'arrive à installer toutes les applications sans problème, en revanche, je ne sais pas si c'est une histoire d'être sur une VM ou pas mais je ne peux acceder à mes apps uniquement si je mets en mode visiteurs. si je fais uniquement admin, ou les utilisateurs YunoHost, ca ne fonctionne pas et ca revient sur la page du portail avec les tuiles des apps. J'ai pourtant changé mon fichier host sur sur l'ordi (pas sur la VM hein ;-)), j'ai flashé le DNS mais non je suis obligé de tout passé en mode "visiteurs".
- Il y a tt de même Cockpit qui ne fonctionne pas, je pense que c'est à cause de cette histoire de SSO, même si je mets en mode "visiteurs" ca se lance mais après j'ai un message d'erreur : Connection failed
There was an unexpected error while connecting to the machine.
Messages related to the failure might be found in the journal: / journalctl -u cockpit
- Pour l'instant je ne vois pas de différence avec YunoHost 12, et je n'arrive pas encore à comprendre concrètement ce que cela va changer de passer de 12 à 13. J'ai regardé ici : https://forum.yunohost.org/t/yunohost-13-0-trixie-spooky-beta/40656 mais je n'arrive pas à comprendre dans le quotidien ce que je vais avoir de mieux, de plus. Si quelqu'un ici arrive à vulgariser tt ça pour un noob comme moi, je suis vraiment preneur. (pour info, j'ai fait l'effort et j'ai lu https://github.com/YunoHost/yunohost/blob/refs/tags/debian/13.0.3/debian/changelog mais je n'ai tj pas compris désolé)
[20:11:45]
<Aleks (he/him/il/lui)> pour le dernier point, y'a pas vraiment de différence concrète notable je crois, ce genre de montée de version est principalement technique, sous le capot toute la base du système Debian est mise à jour ... généralement on en profite pour changer des choses un peu majeure dans YunoHost (par exemple entre 11 et 12 y'a eu une refonte du portail utilisateurice) mais pour 12->13 pour le moment c'est pas spécialement le cas
[20:18:15]
<homelab-fr> Merci c'est bien ce que je pensais. Je viens aussi de voir la feuille de route : https://yunohost.org/roadmap.fr.html et pour l'instant ce que j'attends le + c'est l'implémentation de Authelia. A voir si c'est mieux que maintenant mais ca me servira pour supprimer DEX et pouvoir utiliser la suite (Meet et Docs) sans avoir besoin d'installer d'autres apps. Donc il faudra attendre la 13.1 pour cela. Pour le remplacement de fail2ban par reaction, je n'ai pas d'avis, je ne vois pas bien la différence. Pour le reste le 2FA c'est pas pour tt de suite d'après la feuille de route. Il y a aussi ça qui est pas mal je trouve, mais pareil pas encore de date: Be able to have the portal on a subdomain
[20:19:32]
<m606> l'intérêt restant tout de même qu'à moyen terme il te faudra passer à la version 13, car arrivé à la fin de la date de support de la version 12, Debian ne fera plus de correctif pour cette version (enfin je crois) pour se concentrer sur les versions suivantes.
[20:20:08]
<m606> et idem pour YNH
[20:23:10]
<homelab-fr> je comprends, idem, je viens de tomber là dessus pour expliquer le changement de fail2ban vers reaction, je n'ai pas tt compris, mais je sais que ca sera moins compliqué et que cela prendra moins de ressources pour le reste ... https://linuxfr.org/news/reaction-remplacant-de-fail2ban
[21:57:17]
<Chatpitaine Caverne> ça semble bien Reaction. En plus j'aime beaucoup beaucoup leur important disclaimer dans leur wiki 🌈
[22:23:57]
<Chatpitaine Caverne> Le --no-remove-on-failure a fonctionné
`Error: The restore of peertube failed, but was not cleaned up as requested by --no-remove-on-failure`
La log complète du plantage de restauration est là : https://paste.yunohost.org/raw/ebabazuvel
Je pense que j'investiguerai demain sur ce module manquant. Suis crevé.
Merci Aleks pour le tuyau.
[22:31:07]
<Chatpitaine Caverne> Evidemment, la ligne la plus importante du plantage dans journalctl est celle juste avant la première ligne reprise dans la log de la restauration ....
`Error: Cannot find package '/home/www/peertube/node_modules/@peertube/peertube-models/index.js' imported from /home/www/peertube/dist/server.js`
[22:31:15]
<Chatpitaine Caverne> Qu'est-ce que c'est que ce chemin /home/www .... ?
[22:31:19]
<orhtej2> are the permissions on /var/www/peertube/node_modules something like peertube:peertube?
[22:33:31]
<Aleks (he/him/il/lui)> `/home/www` ? 🙀
[22:33:41]
<orhtej2> oO
[22:34:22]
<Chatpitaine Caverne> All are peertube:www-data
[22:34:50]
<Chatpitaine Caverne> Bien d'accord.
[22:35:07]
<orhtej2> `sudo yunohost app setting peertube install_dir` ?
[22:35:51]
<Chatpitaine Caverne> ```
sudo yunohost app setting peertube install_dir
/var/www/peertube
```
[22:38:08]
<Chatpitaine Caverne> J'imagine qu'il s’emmêle les pinceaux par la faute du lien symbolique que j'ai dû faire pour mes tests :
`www -> /home/www`
[22:38:57]
<Chatpitaine Caverne> Vu que je suis sur une petite carte SD pour le système pour l'instant, il a fallu que je ruse sur l'espace disque.
[22:39:51]
<Chatpitaine Caverne> Du coup, ça serait bon signe pour ma migration si je repars en configuration normale avec un disque système ayant plus de place et pas de magouille dans ce genre.
[22:41:29]
<Aleks (he/him/il/lui)> Bon dans le log on voit
```
2025-12-23 23:14:12,123: DEBUG - + is_in_dir /etc/logrotate.d/peertube /var/www/peertube
2025-12-23 23:14:12,123: DEBUG - + '[' -n /var/www/peertube ']'
2025-12-23 23:14:12,124: DEBUG - ++ realpath /etc/logrotate.d/peertube
2025-12-23 23:14:12,125: DEBUG - + local child=/etc/logrotate.d/peertube
2025-12-23 23:14:12,126: DEBUG - ++ realpath /var/www/peertube
2025-12-23 23:14:12,127: DEBUG - + local parent=/home/www/peertube
```
qui correspondent aux log de ce bout de code: https://github.com/YunoHost/yunohost/blob/dev/helpers/helpers.v2.1.d/0-utils#L254-L260
[22:41:37]
<Chatpitaine Caverne> Ceci dit index.js ne semble pas exister. Ou je ne sais le chercher.
[22:41:41]
<Aleks (he/him/il/lui)> ce qui suggère que `realpath /var/www/peertube` renvoie ... /home/www/peertube
[22:41:48]
<Aleks (he/him/il/lui)> tu peux faire un `ls -l /var/www/peertube` ?
[22:41:53]
<Aleks (he/him/il/lui)> ça ressemble à un lien symbolique wtf
[22:43:14]
<Chatpitaine Caverne> ```
ls -l /var/www/peertube
total 680
drwxr-x--- 4 peertube www-data 4096 Oct 12 11:47 client
drwxr-x--- 2 peertube www-data 4096 Dec 18 18:58 config
-rwxr-x--- 1 peertube www-data 13562 Jul 31 10:13 CREDITS.md
drwxr-x--- 5 peertube www-data 4096 Sep 9 11:13 dist
-rwxr-x--- 1 peertube www-data 38 Dec 14 2021 FAQ.md
-rwxr-x--- 1 peertube www-data 34520 Apr 10 2019 LICENSE
drwxr-x--- 738 peertube www-data 20480 Oct 12 11:39 node_modules
-rwxr-x--- 1 peertube www-data 10223 Sep 9 11:07 package.json
drwxr-x--- 7 peertube www-data 4096 Oct 12 11:29 packages
-rwxr-x--- 1 peertube www-data 9861 Feb 18 2025 README.md
drwxr-x--- 2 peertube www-data 4096 Dec 21 10:27 scripts
drwxr-x--- 3 peertube www-data 4096 Oct 12 11:54 storage
drwxr-x--- 9 peertube www-data 4096 Oct 12 11:30 support
-rwxr-x--- 1 peertube www-data 563013 Aug 7 14:41 yarn.lock
```
[22:44:14]
<Chatpitaine Caverne> Et /var (avec mon ln -s qui à priori semble à l'origine :
```
ls -l /var
total 524336
drwxr-xr-x 4 root root 4096 Dec 23 17:46 backups
drwxr-xr-x 15 root root 4096 Dec 22 23:15 cache
drwxr-xr-x 46 root root 4096 Dec 22 17:55 lib
drwxrwsr-x 2 root staff 4096 Oct 31 2024 local
lrwxrwxrwx 1 root root 9 Nov 19 2024 lock -> /run/lock
drwxr-xr-x 22 root root 4096 Dec 22 17:55 log
drwxrwsr-t 38 root mail 4096 Dec 18 11:19 mail
drwxr-xr-x 2 root root 4096 Nov 19 2024 opt
lrwxrwxrwx 1 root root 4 Nov 19 2024 run -> /run
drwxr-xr-x 5 root root 4096 May 5 2025 spool
-rw------- 1 root root 536870912 Dec 18 10:13 swap
drwxrwxrwt 18 root root 4096 Dec 23 23:39 tmp
drwxrwxrwx 2 root root 4096 Dec 18 11:15 vmail
drwx------ 5 root bin 4096 Dec 23 09:39 webmin
lrwxrwxrwx 1 root root 9 Dec 18 10:42 www -> /home/www
```
[22:44:51]
<Aleks (he/him/il/lui)> ah, donc c'est `/var/www` qui pointe vers `/home/www` mouerf
[22:45:04]
<Aleks (he/him/il/lui)> beh j'imagine que si c'est volontaire c'est ok-ish
[22:45:59]
<Chatpitaine Caverne> C'était uniquement dans cette config de test, par manque d'espace sur carte système.
[22:46:22]
<Chatpitaine Caverne> Ce dont j'aimerais être certain c'est que ce index.js est là.
[22:52:20]
<Chatpitaine Caverne> Bon, ça semble clair que ça vient de ce ln -s
Vais attendre mon disque et je referai des essais sans ruser dans tous les sens.
En plus d'ici là, node(.js) aura eu le temps de sortir une nouvelle release, histoire de jouer un peu.
[22:55:01]
<Chatpitaine Caverne> Merci en tout cas.
Vais me coucher. Bonne soirée.