[02:09:25]
<Solrac> Hello~! Can I ask, why is Raid 1 considered safer than Raid 5?
[02:14:43]
<trendless> A big part of it is odds/probability of failure. Of both the original failure, but also in this era of massive drives because it takes so long to rebuild that the chance of sustaining another failure and losing the dataset.
[02:15:18]
<trendless> A big part of it is odds/probability of failure. Of both the original failure, but also in this era of massive drives of sustaining another failure and losing the dataset because it takes so long to rebuild
[02:15:45]
<trendless> A big part of it is odds/probability of failure. Of both the original failure, but also in this era of massive drives of sustaining a second failure and losing the dataset because it takes so long to rebuild
[04:58:55]
<Solrac> So if OpenZFS... Raid 1 either way?
[04:59:28]
<Solrac> Also, I just migrated from one install to another; and I got an error....
[04:59:33]
<Solrac> https://aria.im/_bifrost/v1/media/download/AWBVnvg7KDigWlun0OwDdS4DF9R0ODZTekVDCrSAg75Ash-6db3BiRuQFV87rURJf2Qx1akmxUYh2dEdEGkLUmVCecMVHYdQAG1hdHJpeC5vcmcvek5nQWFBY3pRc0pSa1JGTXdkUU9za09x
[04:59:38]
<Solrac> There are no error logs, sadly.
[05:01:30]
<Solrac> When I check `yunohost log list`, everything seems fine, a lot of restores are successful, except;
```
17:
description: Restore 'mautrix_discord' from a backup archive
name: 20260205-043956-backup_restore_app-mautrix_discord
path: /var/log/yunohost/operations/20260205-043956-backup_restore_app-mautrix_discord.yml
started_at: 2026-02-05 00:39:56
success: False
18:
description: Remove the 'mautrix_discord' app
name: 20260205-044018-app_remove-mautrix_discord
path: /var/log/yunohost/operations/20260205-044018-app_remove-mautrix_discord.yml
started_at: 2026-02-05 00:40:18
success: False
```
[05:01:51]
<Solrac> and also, my admin account now can't read their own directory
[08:58:56]
<Luc (he/him)> Hello there! I have a problem where I am unsure how to troubleshot further:
I have Yunohost with Nextcloud and Onlyoffice
I upgraded OnlyOffice from 9.2.1~ynh1 to 9.2.1~ynh2. It failed (logs: https://paste.yunohost.org/raw/atupijihif). After the fail the OnlyOffice services were restarting in loop
I uninstalled OnlyOffice and reinstalled the backup from just before the upgrade
Restoring the backup seem to have worked:
* The url of OnlyOffice correctly says "Document Server is running"
* The services are up with no weird logs
* From the admin page of Nextcloud, if I save the OnlyOffice settings, it successfully tests the connection.
But: when I try to open a file, I get an error: "ONLYOFFICE cannot be reached. Please contact admin"
I'm not sure where I can find logs for this error, there is nothing in `/var/log/onlyoffice/docservice.log` or in `/var/log/nextcloud/nextcloud.log`
[10:23:26]
<lautre> Solrac: Try to restore from CLI with ssh. May be you will see more things
[11:03:43]
<homelab-fr> packages.sury.org
[11:06:39]
<homelab-fr> Bonjour, du coup, j'ai aussi ce message comment avez vous fait pour corriger svp ?
Récupération des mises à jour disponibles pour les paquets du système…
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: https://packages.sury.org/php bookworm InRelease: The following signatures were invalid: EXPKEYSIG B188E2B695BD4743 DEB.SURY.ORG Automatic Signing Key
W: Failed to fetch https://packages.sury.org/php/dists/bookworm/InRelease The following signatures were invalid: EXPKEYSIG B188E2B695BD4743 DEB.SURY.ORG Automatic Signing Key
W: Some index files failed to download. They have been ignored, or old ones used instead.
Des erreurs se sont produites lors de la mise à jour du cache APT (gestionnaire de paquets Debian). Voici un extrait des lignes du fichier sources.list qui pourrait vous aider à identifier les lignes problématiques :
sources.list:deb http://ftp.debian.org/debian bookworm main contrib non-free-firmware
sources.list:deb-src http://ftp.debian.org/debian bookworm main contrib non-free-firmware
sources.list:deb [signed-by=/etc/apt/keyrings/YunoHost_repository.asc] http://repo.yunohost.org/debian/ bookworm stable
sources.list:deb http://security.debian.org/debian-security bookworm-security main contrib non-free-firmware
sources.list:deb-src http://security.debian.org/debian-security bookworm-security main contrib non-free-firmware
sources.list:deb http://ftp.debian.org/debian bookworm-updates main contrib non-free-firmware
sources.list:deb-src http://ftp.debian.org/debian bookworm-updates main contrib non-free-firmware
sources.list.d/yarn.list:deb [signed-by=/etc/apt/trusted.gpg.d/yarn.gpg] https://dl.yarnpkg.com/debian/ stable main
sources.list.d/extra_php_version.list:deb [signed-by=/etc/apt/trusted.gpg.d/extra_php_version.gpg] https://packages.sury.org/php/ bookworm main
[11:09:19]
<otm33> homelab-fr: Normalement, la commande devrait également fonctionner pour le dépôt sury.
[11:11:51]
<Chatpitaine Caverne> Il semblerait que nous soyons 2 semaines plus tard :
[11:12:00]
<Chatpitaine Caverne> https://aria.im/_bifrost/v1/media/download/Ab42J6YjAmFJZxfRCxP9_whfHa6W1jrIYM3XLnmmo3Lp5OcW_0qmR4-jaPNoYdF0ezXhHNzlZNbZJGaZLp6jRFVCecMqbV9wAGNpcmthdS5hcnQvR2hPd2hwYmhuZVdQa1RuU3FXcXJDVnRG
[11:14:02]
<Chatpitaine Caverne> Oui, c'est bien la clé extra_php_version.gpg qui vient d'expirer.
[11:14:41]
<homelab-fr> est-ce que ca serait la solution ou bien l'IA me dit des conneries ?
sudo apt-get update
sudo apt-get -y install lsb-release ca-certificates curl
curl -sSLo /tmp/debsuryorg-archive-keyring.deb https://packages.sury.org/debsuryorg-archive-keyring.deb
sudo dpkg -i /tmp/debsuryorg-archive-keyring.deb
[11:16:39]
<Chatpitaine Caverne> ça donne quoi chez toi ?
`sudo gpg /etc/apt/trusted.gpg.d/extra_php_version.gpg`
[11:17:13]
<Chatpitaine Caverne> Je viens de dire une bêtise, elle a auto-rotaté (pas fr mais on comprend \[expires: 2028-02-04\]
[11:17:42]
<homelab-fr> je vais tester sudo gpg /etc/apt/trusted.gpg.d/extra_php_version.gpg maintenant
[11:18:17]
<homelab-fr> gpg: répertoire « /root/.gnupg » créé
gpg: le trousseau local « /root/.gnupg/pubring.kbx » a été créé
gpg: WARNING: no command supplied. Trying to guess what you mean ...
pub rsa3072 2019-03-18 [SC] [expirée : 2026-02-04]
id DEB.SURY.ORG Automatic Signing Key <deb@sury.org>
sub rsa3072 2019-03-18 [E] [expirée : 2026-02-04]
[11:19:53]
<otm33> homelab-fr: As-tu essayé `sudo yunohost tools regen-conf apt --force` ?
[11:23:39]
<homelab-fr> non je vais essayé là
[11:23:52]
<Chatpitaine Caverne> 1 - Il semblerait qu'elle en fasse un peu trop sur ce coup. Tu veux juste récupérer la nouvelle clé.
2 - faut pas me demander ce que je pense du travail d'une IA, je les boycotte et les aime pas.
[11:24:50]
<homelab-fr> je comprends pour l'IA c'est pour ça que je demande car trop souvent je me fais avoir par l'IA quand elle touche à mon serveur
[11:25:24]
<homelab-fr> et là j'ai fais comme tu as dis, c'est à dire :
sudo yunohost tools regen-conf apt --force ensuite sudo gpg /etc/apt/trusted.gpg.d/extra_php_version.gpg et là on dirait que je suis bon ! (si j'ai bien compris) sub rsa3072 2019-03-18 [E] [expire : 2028-02-04]
[11:26:17]
<couscousyeah> la restauration s'est bien passée, j'ai coupé nginx sur le laptop et les sous domaines commencent à apparaitre sur le VPS
plus qu'à faire un tour de nextcloud avec les utilisateurices pour s'assurer que tout fonctionne et ce sera bon
merci encore à vous !
[11:26:20]
<homelab-fr> un grand MERCI !
[11:29:14]
<otm33> Le keyring n'est pas une mauvaise idée en soi mais la regen-conf recrée le extra_php.list (donc la référence au fichier du keyring)
[11:41:13]
<Gwên> Ah bah j'ai lemême message qui s'affiche à chaque recherche de mise à jour
[11:41:49]
<Gwên> Que faut-il faire du coup ? '^'
[11:42:23]
<Chatpitaine Caverne> `sudo yunohost tools regen-conf apt --force`
[11:42:26]
<Gwên> Ça m'arrive d'en passer par là quand je suis désespérée de trouver une info introuvable, mais 90 % du temps ça me renvoie des conneries ^^ Au moins ça me confirme l'inutilité
[11:42:30]
<Gwên> Merciii !
[11:43:23]
<Gwên> Hm ça refait la même chose :(
[11:43:53]
<Gwên> J'ai Pas de journaux (logs) disponibles.
[11:44:09]
<Chatpitaine Caverne> C'est plus une raison écologique et politique de mon côté.
En plus tu travaille dans la création artistique, ça doit te causer le merdier que ça peut causer. Et je ne parle même pas des aspects militaires...
[11:44:19]
<Gwên> Entièrement d'accord
[11:44:20]
<Chatpitaine Caverne> Mais c'est hors sujet. Déso.
[11:44:26]
<Gwên> pas de soucis
[11:44:40]
<Gwên> J'en parle régulièrement autour de moi pour sensibiliser au problème (et j'attends avec impatience le jour du crash)
[11:45:02]
<Chatpitaine Caverne> Inch'Allah de los computers
[11:45:48]
<Gwên> L'avantage de m'en être servi quelques fois c'est que j'ai des exemples concrets à donner aux gens pour leur expliquer que c'est pas une bonne idée de demander à ChatGPT
[12:42:54]
<@err404:matrix.numericore.com> Les exemples m'intéressent
[12:49:25]
<otm33> https://aria.im/_bifrost/v1/media/download/Adh8sJBo4CxXflf4LzxBGLzLG4Mems4QxMMxoPaEx46qbPxTqmYvpD9W0CBl0ohDdb6zXtq-UhDitPf7CTxBo2hCecMwAHFwAG1hdHJpeC5vcmcvcERXUmhpVllpbk9sS2J1ek5pWldYRktZ
[12:49:57]
<otm33> https://aria.im/_bifrost/v1/media/download/AVVZ64fhJdAFZhO8DToqoDDcB2gkAS03XMeIh2Moj6jO0w5tAt40WdmU_A_12cdKjTJ0Q5sY_htv0KK_0-yvqvlCecMwCExwAG1hdHJpeC5vcmcvemN3QndNcnBEQ0dKcHN1UUxTUGd5b1dk
[12:52:27]
<otm33> un peu daté quand même.
[12:52:37]
<otm33> https://aria.im/_bifrost/v1/media/download/AY9nlvwBKHJNByFxs1BCfHNr6BaAZgqCQAyMahMi8qqNk1AiOk3i3kgTFz2e_6p-1fnhBrNzKyQTW59jWcQSkzBCecMwLzJAAG1hdHJpeC5vcmcvUWdJVEt4ZmNmQUhheGhaeklJSWl6dnpV
[12:53:06]
<otm33> https://aria.im/_bifrost/v1/media/download/AUaTavNXJ9Iq94OFgFt305EJT7J2O4z5fbnBfsYN25mJTILneDWxSPmpXdOsglmZ52vuhNRmMCd2Q6Wzm6OaBuNCecMwNloAAG1hdHJpeC5vcmcvaHNTQmVxRGlDdW9iWXdmWGhkTmFqWmtT
[12:53:40]
<otm33> https://aria.im/_bifrost/v1/media/download/ATp-hNFqUqfl-b1cPMWqJGjHj35pRiarf5zrhZFxJrOq0k6naNCjRQ0RlCDE5RMiKMImTsyF2iurBCaN0GII7mZCecMwPpLAAG1hdHJpeC5vcmcvQXh6VEFtdFRIWGNubnZnc3BGRWhJSU9U
[12:54:11]
<otm33> J'ai deux mains gauches aujourd'hui
[13:12:28]
<xs> j'aime assez https://clocks.brianmoore.com/
[13:14:30]
<pti-jean> otm33, C'est quoi ces fichiers sans extension ?
[13:17:02]
<@err404:matrix.numericore.com> Merci pour les exemples
[13:24:31]
<otm33> Les images ne s'affichent pas ?
[13:35:21]
<pti-jean> Non!
[14:28:09]
<@err404:matrix.numericore.com> Moi je vois les images
[14:41:03]
<Chatpitaine Caverne> Salut, question Borg,
Suis en train d'évaluer et tester Borg pour remplacer mon script à base de yunohost backup create dont je suis très content et kimsuffi(sait).
En effet sommes confrontés à un problème classique d'espace disponible en backup intégral avec des volumes qui augmentent. De plus, nous allons mettre en place un backup sur site déporté (ça sera plus safe que la copie sur grosse clé USB qu'on oublie toujours d'embarquer avec soi).
Par contre, avoir les sauvegardes uniquement sur le site déporté me stresse pas mal (en plus de tous ces changements dans un compartiment aussi critique que les backups).
Je n'ai trouvé de solution de redondance de backups viable (en tout cas non déconseillé par Borg) que dans Borg V2 (avec borg transfer).
Or, la V2, je vois des messages qui l'attendent datant de 2022...
Quelqu'un aurait-il des retours d'expériences sur comment vous faites ?
Merci.
PS, j'ai comme l'impression qu'on serait mieux sur le forum pour laisser des traces servant à tout le monde s'il en sort des infos intéressantes. Je reporterai sur le forum si justifié/désiré.
[14:42:32]
<Chatpitaine Caverne> Salut, question Borg,
Suis en train d'évaluer et tester Borg pour remplacer mon script à base de yunohost backup create dont je suis très content et kimsuffi(sait).
En effet sommes confrontés à un problème classique d'espace disponible en backup intégral avec des volumes qui augmentent. De plus, nous allons mettre en place un backup sur site déporté (ça sera plus safe que la copie sur grosse clé USB qu'on oublie toujours d'embarquer avec soi).
Par contre, avoir les sauvegardes uniquement sur le site déporté me stresse pas mal (en plus de tous ces changements dans un compartiment aussi critique que les backups).
Je n'ai trouvé de solution de redondance de backups viable (en tout cas non déconseillé par Borg) que dans Borg V2 (avec borg transfer et aussi faire 2 repo et 2 backups, mais...)
Or, la V2, je vois des messages qui l'attendent datant de 2022...
Quelqu'un aurait-il des retours d'expériences sur comment vous faites ?
Merci.
PS, j'ai comme l'impression qu'on serait mieux sur le forum pour laisser des traces servant à tout le monde s'il en sort des infos intéressantes. Je reporterai sur le forum si justifié/désiré.
[19:07:11]
<rainer.szs> I know this sounds stupid but yesterday I was moving some videos in one of the jellyfin folders with filezilla without problems, and today I'm testing 3 different methods to regain the same privileges, failing.
I don't exactly remember how I logged in yesterday but today I tried:
- scp command for copying a file between client and server, didn't work even with sudo
- generated a public key and a private key as stated in the "Howto" page of the filezilla wiki. I copied and pasted the content of "my-ssh-key.pub" from the client, into ~/.ssh/authorized_keys file on the server. Then imported the private key "my-ssh-key" in filezilla, and I still can't connect to the server.
- trying to access as root in both filezilla and terminal (root@domain.nohost.me) without success. Although I learned that the root user isn't accessible anymore after post install
[19:23:55]
<rainer.szs> I copied the authorized_keys file in /root/.ssh/ too, in the server
[20:39:55]
<trendless> Weird. Could the owner/permissions of the folder(s) you're working with have changed?
Are you on the same LAN as the server?
If you wanna access as root via filezilla and key, you'll need to put the public key in /root/.ssh/authorized_keys on the server and login as root.
[20:58:40]
<rainer.szs> I need to check the permissions
Yes
So authorized_key is a text file with the key in it, or a directory?
[21:02:31]
<trendless> authorized_key is a file with the key in it. It can contain multiple keys with comments, etc. Eg.
```
# Key for User A
ssh - rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQ... user_a@example.com
# Key for User B
ssh - rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQ... user_b@example.com
```
[21:04:14]
<trendless> if you're on the same LAN, you should still be able to login as root, assuming the password didn't change. There are a bunch of related settings here: `https://domain.nohost.me/yunohost/admin/#/tools/settings/security`
[21:26:23]
<Chatpitaine Caverne> rainer.szs:
> Although I learned that the root user isn't accessible anymore after post install
It is still accessible. It should be the same password as first user (not sure, I don't remember well) and you can change it (recommended) through Tools menu / Yunohost parameters / Change the root password.
That said, better to use ssh keys, indeed.
[21:29:16]
<otm33> You can check a few things:
- has the key been generated for your current user?
- do you have multiple keys for this user?
You can try debugging with ssh -vvv user@distantserver
[21:31:19]
<otm33> ssh can try 6 keys while the distant server only allows 5 tries.
[21:33:31]
<otm33> You can try ssh -i path/to/yourkey user@server
scp -i path/to/yourkey etc
[22:34:40]
<rainer.szs> I will try tomorrow, thank you