[07:33:34]
<artlog> pour améliorer le modèle de confiance debian fait en sorte que l'on utilise les clés publiques gpg/pgp de confiance dédiées pour chaque dépôt. C'est la norme en debian 13 mais était déjà conseillé en debian 12.
[07:34:44]
<artlog> les clés publiques placées sous /etc/apt/trusted.gpg sont acceptée pour signer tous les dépôts qui ne spécifient pas quelle clé utiliser.
[07:34:58]
<artlog> Et ça -c'est pas terrible-
[07:35:23]
<artlog> apt-key plaçait tout là dedans, c'est pourquoi apt-key n'est plus conseillée
[07:37:53]
<artlog> au lieu de clea il faut placer les clés ailleurs, il y a des répertoires normalisés. /usr/share/keyrings pour ceux du système et /etc/apt/keyrings pour ceux que vous manipulez; mais en fait vous pouvez mettre ce que vous voulez vu que vous spécifier le chemin complet du fichier dans la définition du dépot.
[07:39:00]
<artlog> ainsi , par exemple, la clé du dépôt postgres ne peut pas servir pour signer un paquet d'un autre dépôt.
[07:40:39]
<artlog> tout cela est écrit ici https://wiki.debian.org/DebianRepository/UseThirdParty mais en ce moment le site semble inaccessible.
[07:41:39]
<artlog> donc le principe est de copier lka clé quelque part et de la référencer dans le fichier de définition du dépôt.
[07:42:39]
<artlog> il y a deux formats pour les dépôt, l'ancien et ... le nouveau ;-) l'ancien est un dépot pas ligne et le nouveau est un fihcier par dépot avec un ensemble de champs à remplir.
[07:43:23]
<artlog> il existe un outil pour transformer globalement les formats .list anciens en format .source nouveau
[07:44:18]
<artlog> cet outil s'appelle ... euh je n'ai plus le nom en tête et je ne l'ai pas noté dans mon wiki ...
[07:45:34]
<artlog> c'est un des changement majeur de la debian 13 mais c'était dans les cartons depuis quelques temps.
[07:48:08]
<bbohard> https://launchpad.net/ubuntu/+source/apt/2.9.26
[07:48:46]
<bbohard> une commande a été ajoutée à apt pour la conversion des sources list
[07:49:00]
<bbohard> `apt modernize-sources`
[07:50:57]
<artlog> Error: Something went wrong while updating the cache of APT (Debian's package manager). Here is a dump of the sources.list lines, which might help identify problematic lines:
... L'erreur semble après ... qu'est-ce qui est écrit ?
[08:55:53]
<Joris> https://aria.im/_bifrost/v1/media/download/ASSYvVX8cInYp_gflG5JUCx5hGhXjdSaKt-nRlSnTj_hSXP9Cnq-4z5ryUO_kQ_V-PS51oDKECopBeyeBWJfJvpCebl6ttxwAG1hdHJpeC5vcmcvbG9DUmpCS1NPTEJsekZJc0tUT25QUVpH
[08:56:03]
<Joris> C'est ou déjà yunopaste ? :p
[09:01:39]
<Joris> https://paste.yunohost.org/gonimiwiro.yaml
[09:03:28]
<Joris> Bon c'est juste ma liste de sources apt. Mais c'est la clé pour http://apt.postgresql.org qui pose problème
[09:04:01]
<Joris> c'est juste un warning en fait, mais yunhost l'affiche comme une erreur
[09:05:07]
<artlog> yep j'en déduis la mêem chose
[09:05:07]
<Joris> merci pour l'explication, je vais étudier ça pour le passage à debian 13
[09:05:51]
<artlog> et tu es comme moi je fais toujours cette typo yunhost ;-)
[09:06:19]
<Joris> ah oui tient :p
[09:13:25]
<artlog> il doit suffire de déplacer la clé de /etc/apt/trusted.gpg/ à /etc/apt/keyrings/ et la référencer dans ... dans à voir le fichier qui déclare /apt.postgresql.org sous /etc/apt/ ... find /etc/apt -type f | xargs grep 'apt.postgresql.org' ...
[09:13:56]
<artlog> créer /etc/apt/keyrings/ si besoin ...
[09:17:31]
<artlog> tiens je n'ai pas de dépot spécifique à postgres sur ma trixie, j'ai celui de la distro
[09:18:13]
<artlog> et le précédant postgresql-15 de la bookworm 12 est toujours là ...
[09:59:10]
<bbohard> Ça ne me semble pas aberrant : la procédure de migration d’un cluster postgresql nécessite que les deux versions soient présentes en même temps (l’ancienne et la nouvelle).
[10:00:49]
<bbohard> on peut enlever l’ancienne après s’être assuré que le cluster migré ne pose pas de problème. C’est jamais évident à faire automatiquement (je ne parle pas de l’intégration spécifique dans yunohost mais j’ai la même difficulté dans un autre produit)
[11:18:31]
<Joris> So, in conclusion:
In case of annoying complain from package update about sources key
I've applied the instruction found in `man apt-key` section DEPRECATION
that is :
`If your existing use of apt-key add looks like this:`
`wget -qO- https://myrepo.example/myrepo.asc | sudo apt-key add -`
` Then you can directly replace this with (though note the recommendation below):`
`wget -qO- https://myrepo.example/myrepo.asc | sudo tee /etc/apt/trusted.gpg.d/myrepo.asc`
[11:19:40]
<Joris> so for the (debian 12) apt source for postgress, see https://apt.postgresql.org/pub/repos/apt/README
thats give:
`wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo tee /etc/apt/trusted.gpg.d/ACCC4CF8.asc`
[11:19:52]
<Joris> et voilà
[11:20:21]
<Joris> the name `ACCC4CF8.asc` sounds really weird, but it's working
[11:57:22]
<artlog> c'est très exactement pas le tuto que j'aurais écris... on place encore la clé dans /etc/apt/trusted.gpg.d/ ... pas glop, c'éait les conseils d'il y a deux ans ...
[11:57:51]
<artlog> README 11-Aug-2016 08:43 962
[11:58:07]
<artlog> presque dix ans le fichier ...
[11:58:53]
<artlog> https://wiki.postgresql.org/wiki/Apt semble mieux comme tuto
[11:59:49]
<artlog> et on place le fichier dans /usr/share/postgresql-common/pgdg/apt.postgresql.org.asc , ce qui est mieux.
[12:00:57]
<artlog> this https://wiki.postgresql.org/wiki/Apt is actuly up to date compared to README. and name does not sound weird : apt.postgresql.org.asc
[12:02:04]
<artlog> as usual , the key for the repository is old.
[12:08:54]
<Joris> 😭
[12:09:06]
<Joris> j'ai fait de mon mieux 😅
[12:10:49]
<artlog> il y a whatmille tutos et pour savoir lesquels sont bons ... le README datant de 2016 sur le site, c'est pas cool...
[12:15:09]
<artlog> en fait il y a plus d'information obsolètes sur le net que d'informations à jour. Et cela va être intensifié par les LLM...
[12:15:10]
<Joris> déjà, je comprend pas pourquoi j'ai ce problème à la base. Sachant que j'ai pas sur mon autre serveur, qui a surement lui aussi postgress. Après c'est possible que ca soit une erreur provenant de l'execution d'un script horrible d'install de zulip
[12:15:12]
<Joris> que évidement j'ai jamais vraiment nettoyé ce qu'il a fait
[12:15:14]
<artlog> un paquet a du décider d'installer le dépot spécifique postgres, celui-ci n'est pas nécessaire, les paquets sont dans la distro
[12:15:32]
<Joris> oui ben ben ca doit être ce script
[12:19:32]
<artlog> et biensur désinstaller ne suffit pas à revenir dans le bon état si le script de désinstallation n'a pas été écrit correctement...
[12:19:32]
<artlog> c'est le talon d'achile de yunohost, un seul paquet peut vriller tout. Il ya presque autant d'install de yunhost qu'il y a de combinaisons d'applications ynh
[12:19:33]
<artlog> genre une action qui écrase un fichier
[12:19:33]
<artlog> et même si il a été bien écrit ... toute action d'installation n'est pas nécessairement réversible
[12:19:33]
<Joris> oui. L'autre truc, et c'est un vrai questionnement que j'ai : est-ce que c'est vraiment une bonne idée que quelqu'un comme moi administre un serveur publique ? J'en sais juste assez pour être dangereux (je suis dev pas admin).
[12:21:44]
<artlog> il n'y a que ceux qui ne font rien... et il n'y a pas de limites à l'expertise, il faut bien commencer de quelque part.
[12:26:06]
<artlog> tu es ici et tu poses des questions : tu fais ce qu'il faut.
[12:27:18]
<Joris> En fait, un jour j'ai essayé d'installer https://github.com/YunoHost-Apps/zulip_ynh/
et en fait ca télécharge un script genre celui là https://github.com/zulip/zulip/blob/main/scripts/lib/install
et ca a planté au milieu
j'ai montré les log à Aleks ici et il a dit : "ho mon dieu"
[12:27:45]
<Joris> le script a modifié plein de chose brutalement
[12:28:03]
<Joris> ca a cassé ngninx
[12:29:19]
<Joris> j'ai réussi à récupérer le webadmin en desactivant la config Nginx que le script avait ajouté
mais j'ai jamais été plus loin dans le nettoyage
[12:30:06]
<artlog> effectivement, cet App ... This is TRAP ! :-) https://github.com/YunoHost-Apps/zulip_ynh/issues/14
[12:30:46]
<Joris> question : quand on restore une sauvegarde YNH, en fait c'est pas juste une restauration simple qui copie/colle tout. ca réinstalle les choses ? puis copie les données utilisateur/service, c'est ca ?
[12:34:16]
<artlog> je n'ai pas une réponse correcte, mon expérience c'est que la restauration c'est le moment critique ou des scripts ancien qui proviennent de l'app à l'heure où elle a été installée sont appelés. Et si l'appli est ancienne, non seulement les scripts sont buggué mais peut ^tre pas non plus adaptés à la version de yunhost actuelle.
[12:35:46]
<artlog> si on a besoin de restaurer parce que l'appli était mal foutue, bah souvent on se trouve dans un état encore pire.
[12:36:13]
<Joris> oui je comprend. Mais en fait Zulip n'est pas installé, il ne l'a jamais été vraiment
[12:36:40]
<Joris> j'ai juste des bout de trucs qui trainent mais qui ne servent à rien
[12:36:51]
<Joris> la seul appli que j'ai maintenant c'est nextcloud
[12:37:25]
<artlog> alors virer le dépot postgres est une idée, mais la question est de savoir si une autre app l'utilise
[12:37:49]
<Joris> si je refait une sauvegarde complete. Je réinstalle YNH et je charge le backup contenant Nexcloud et mes données. Je repart d'un base saine non ?
[12:38:07]
<Joris> de toute façon il faut que je fasse des changement sur les disques
[12:39:07]
<artlog> nextcloud est un appli solide normalement.
[12:40:34]
<artlog> je me sens un peu seul à te répondre là ;-)
[12:41:07]
<artlog> en général je n'aime conseiller de faire quelquechose que je n'ai jamais testé.
[12:42:54]
<Joris> lol 😁
[12:42:59]
<artlog> si tu dois retoucher le système alors c'est effectivment l'occasion. Le système de backup yunohost est conçu pour ça. Sois juste prêt à poser des questions ici et à ouvrir un post de forum si cela ne se passe pas comme prévu
[12:43:22]
<bbohard> désolé, je n’ai pas non plus encore suffisamment d’expérience : je n’ai pas encore eu à tout restaurer pour l’instant (pas encore un an en service)
[12:43:54]
<artlog> et sauvegarde tes backups à deux endroits si c'est possible niveau volume ...
[12:44:31]
<Joris> non mais ca va aller. Dans le nextcloud, j'ai surtout des photos, je ferai une sauvegarde des photos à part en plus (enfin j'en ai déjà une sur un DD externe) avec borg. Et au pire du pire je repart de ca
[12:46:18]
<Joris> je vais faire ça. Merci pour l'aide et le temps passé 🥰
[13:59:18]
<darl200> @Joris. A ma connaissance, les données nextcloud ne sont pas sauvegardées par yunohost, il faut faire une sauvegarde séparée par une appli cliente de synchronisation par ex.
[15:36:56]
<pti-jean> Si-si, les données NextCloud sont sauvegardé!
Et je pense que repartir sur une nouvelle installation avec les sauvegardes... cela me semble repartir sur une base saine!
[16:00:32]
<Chatpitaine Caverne> Je suis en cours de test de migration et Nextcloud (2 instances) n'a jusqu'ici posé aucun souci de restauration complète, avec les données. Elle est simplement en mode maintenance après restauration, ce qui est logique.
Pour sauvegarder tes données, tu peux aussi utiliser Nextcloud Desktop et synchroniser tous tes fichiers sur ton PC, ça fait une tranquillité d'esprit aussi.
L'option base neuve toute propre semble mieux que d'essayer d'enlever des bouts de paquets à droite et à gauche.
[16:08:55]
<Joris> https://imgflip.com/i/agn99l
[19:46:15]
<hook> I’m having trouble updating Wallabag.
[19:46:35]
<hook> ```
Warning: File or folder '/etc/php/8.2/fpm/pool.d/wallabag2.conf' to be backed up does not exist
Error: Failed to collect files to backed up for wallabag2.
```
[19:46:58]
<hook> Any idea what to do?
[20:15:38]
<hisand708> Hi is there a way, I could allow apps to use another disk, without moving them? Apps like immich, jellyfin?
[21:13:04]
<jax> > <hook> ```
> Warning: File or folder '/etc/php/8.2/fpm/pool.d/wallabag2.conf' to be backed up does not exist
> Error: Failed to collect files to backed up for wallabag2.
> ```
i'm having this same issue with freshrss
[22:54:05]
<hook> I have half a mind to just `touch wallabag2.conf` and see what happens … but I really don’t want to lose all my reading.
[23:39:29]
<orhtej2> > <hook> ```
> Warning: File or folder '/etc/php/8.2/fpm/pool.d/wallabag2.conf' to be backed up does not exist
> Error: Failed to collect files to backed up for wallabag2.
> ```
--no-safety-backup?
[23:40:38]
<orhtej2> What version are you running? Is the file there? Or under different php version?
[23:41:32]
<orhtej2> you can always edit backup/restore script under /etc/yunohost/apps iirc to amend for actual file location