[15:09:50]
<nalla22> Bonjour, est-ce qu'une version BETA pour Debian 12 sera bientôt disponible ?
[15:11:18]
<Aleks (he/him/il/lui)> cf https://forum.yunohost.org/t/debian-bookworm-12-x-has-been-released-yunohost-is-not-yet-compatible/25082
[15:17:33]
<nalla22> Malheureusement, ça ne dit pas quand la BETA sera disponible. J'ai un parc de serveurs à installer, mais j'aimerai éviter la transition de Debian 11 à 12, donc une version BETA me suffirait !
[15:25:41]
<Aleks (he/him/il/lui)> cf https://github.com/YunoHost/issues/issues/2050
[15:25:42]
<Aleks (he/him/il/lui)> >We are a volunteer team, we will release stuff when it's stable, and you are welcome to effectively help us getting shit done, but for the love of god don't pressure volunteers as if they owe you something
[15:25:42]
<Aleks (he/him/il/lui)> There is no ETA, shit will be released when it works
[15:25:42]
<mavric34> > <@nalla22:matrix.org> Malheureusement, ça ne dit pas quand la BETA sera disponible. J'ai un parc de serveurs à installer, mais j'aimerai éviter la transition de Debian 11 à 12, donc une version BETA me suffirait !
Je suis exactement confronté au même problème !
[15:34:01]
<Nadine> Hi,
I need to install a CLI Tool via npm which requires nodejs>=18.12.0. Currently I have nodejs 16.20.0 installed on my yunohost server. Can I just update my nodejs version or do I risk to break anything?
[15:37:47]
<Aleks (he/him/il/lui)> you probably want to use `/opt/node_n/bin/n` which should be available if you already have a yunohost nodejs-based app installed
[15:40:53]
<Nadine> > <@Alekswag:matrix.org> you probably want to use `/opt/node_n/bin/n` which should be available if you already have a yunohost nodejs-based app installed
Yes, I have this file. How can I use it to update nodejs?
[15:43:07]
<Aleks (he/him/il/lui)> you don't update nodejs, you install additional versions, cf `/opt/node_n/bin/n --help`
[15:48:46]
<Nadine> > <@Alekswag:matrix.org> you don't update nodejs, you install additional versions, cf `/opt/node_n/bin/n --help`
Ok got it, thanks. I see 3 versions there:
- node/14.21.3
- node/16.20.0 (currently active)
- node/18.16.0
However, when I select the latest version 18.16.0 and I do node --version it still show v16.20.0.
[15:52:16]
<ynhuser> Hello, how can I change the PHP version of a domain?
[15:52:58]
<ynhuser> I get the following error message:
[15:52:58]
<ynhuser> Composer detected issues in your platform: Your Composer dependencies require a PHP version ">= 8.0.2".
[15:55:04]
<tituspijean[m]> ynhuser: wrong question. What are you trying to achieve, on which app, and with what command?
[15:55:05]
<ynhuser> I am using the YunoHost Application "my_capsule"
[16:01:43]
<tituspijean[m]> Anyways, try to find out its php vetsion with `sudo yunohost app setting my_capsule phpversion`
[16:01:43]
<tituspijean[m]> Mmmh this app is weird, it refers to PHP without mentioning a version.
[16:01:44]
<tituspijean[m]> With that in mind, re-run whatever php command you were running in its directory with
sudo -u my_capsule php8.1 <the_command> (assuming you got 8.1 from th previous command)
[16:01:44]
<ynhuser> I have since install other software
[16:03:16]
<tituspijean[m]> That's not a problem. Multiple PHP versions can co-exist on a system. It's only a matter of calling the right command like `php8.1`, not a generic `php`
[16:04:04]
<ynhuser> Why can't you change the PHP version via yunohost/admin
[16:05:37]
<Aleks (he/him/il/lui)> ... are you even reading the messages ...
[16:09:06]
<fch> I see this line on ssh logs: Jun 18 16:49:53 sshd[320807]: Connection from 8.222.229.84 port 36134 on 192.168.1.xxx port 22 rdomain ""
[16:09:28]
<fch> does it mean 8.222.229.84 have ssh access into my server?
[16:09:58]
<Aleks (he/him/il/lui)> no
[16:10:18]
<fch> thank God
[16:10:44]
<fch> what is it, if you have the time to explain it?
[16:11:58]
<Aleks (he/him/il/lui)> the number of IPv4 is "so small" (like a couple billions or so) that it's easy to write a bot scanning all the internets, looking for exposed SSH ports, and attempting to brute force it with stupidly simple passwords etc, such as "root/admin", "root/password", "root/azerty", "admin/azerty", whatever
[16:12:13]
<Aleks (he/him/il/lui)> Fail2ban is a common tool to automatically ban the corresponding IP after a couple of failed login attemps
[16:12:20]
<Aleks (he/him/il/lui)> and it's preinstalled and preconfigured in YunoHost
[16:12:42]
<Aleks (he/him/il/lui)> similar stuff happens for other kind of services, with similar counter-measures, such as email server, web apps, etc
[16:14:10]
<fch> I see, but that line in specific "Connection from 8.222.229.84 port 36134 on 192.168.1.xxx port 22 rdomain" what does this kind of connection mean?
[16:14:15]
<Nadine> > Ok got it, thanks. I see 3 versions there:
> - node/14.21.3
> - node/16.20.0 (currently active)
> - node/18.16.0
> However, when I select the latest version 18.16.0 and I do node --version it still show v16.20.0.
I ran /opt/node_n/bin/n run 18.16.0. Then it says "Welcome to Node.js v18.16.0" and then when I quit node -v still shows v16.20.0 . Any thoughts about that?
[16:14:58]
<Aleks (he/him/il/lui)> idk, i would find the actual full path to the 18.16.x binary and use this to run whichever command you want
[16:15:41]
<Aleks (he/him/il/lui)> should be in /opt/node_n//n/versions/node/18.16.0/bin/
[16:16:37]
<Aleks (he/him/il/lui)> > <fch> I see, but that line in specific "Connection from 8.222.229.84 port 36134 on 192.168.1.xxx port 22 rdomain" what does this kind of connection mean?
there's a difference between "Connecting" in terms of "Opening a TCP socket to discuss with the SSH daemon" and "Actually being authenticated"
[16:17:21]
<Aleks (he/him/il/lui)> for you to be able to connect through SSH server, anybody has to be able to discuss with SSH (hence opening a connection), and the SSH prompts for the password (or the key), and then it actually lets you in"
[16:17:38]
<Aleks (he/him/il/lui)> like "Connection" here is just the "knocking on the door" phase, not actually opening it
[16:17:50]
<fch> oh I see, makes sense now. Thank you
[16:18:33]
<fch> like as if you do ssh admin@myip I will see your attempt in the logs...but jailed if put the wrong passwd, right?
[16:20:07]
<Aleks (he/him/il/lui)> yes, after a bunch of failed attempts
[16:21:50]
<fch> jailed IP's are kept in jail for how long? forever?
[16:23:26]
<Aleks (he/him/il/lui)> for 10 minutes and then there's a recidive jail for IPs that .. recidive ..
[17:02:30]
<nalla22> Est-ce qu'il y a déjà eu des applications corrompues ou des pertes de données lors de la transition officielle de Debian 10 vers Debian 11 ?
[17:12:07]
<mavric34> > <@nalla22:matrix.org> Est-ce qu'il y a déjà eu des applications corrompues ou des pertes de données lors de la transition officielle de Debian 10 vers Debian 11 ?
D'après ce que j'ai vu sur certains fils de discussions, la transition de Yunohost/Debian10 vers Yunohost/Debian11 s'est très mal passée pour certains !
[17:15:26]
<mavric34> À chaque sorti d'une nouvelle version Debian, je suis obligé de supprimer l'instance Yunohost et de la réinstaller sur la nouvelle version Debian pour éviter les problèmes de transition. Chose qui n'est pas du tout pratique
[17:27:04]
<Guillaume Bouzige> > <@mavric34:matrix.org> À chaque sorti d'une nouvelle version Debian, je suis obligé de supprimer l'instance Yunohost et de la réinstaller sur la nouvelle version Debian pour éviter les problèmes de transition. Chose qui n'est pas du tout pratique
je ne partage pas ce retour d'experience et les migrations se passent toujours bien lorsqu'elles sont correctement faites par l'administrateur du serveur.
[17:30:19]
<mavric34> > je ne partage pas ce retour d'experience et les migrations se passent toujours bien lorsqu'elles sont correctement faites par l'administrateur du serveur.
il y a qu'à appuyer sur un bouton pour procéder à la migration, la marge d'erreur est très faible !
Mais apparement il y a souvent des problèmes qui se produisent d'après ce que j'ai lu. Peut être que vous utilisez très peu d'applications avec yunohost...
[17:32:31]
<Guillaume Bouzige> oui voila exactement les yolo-updates fait par un pseudo-administrateur...cela est évidemment source de multiples problemes.
[17:35:14]
<mavric34> > oui voila exactement les yolo-updates fait par un pseudo-administrateur...cela est évidemment source de multiples problemes.
yunohost est justement fait pour ne pas utiliser le terminal et de faire n'importe quoi ! Dis-moi où est l'erreur d'utiliser les outils GUI fournis par yunohost pour effectuer la mise à jour ?
[17:35:21]
<mavric34> Qu'elle est ta méthode d'update ? Tu invoques les esprits avant d'effectuer la mise à jour ?
[17:38:53]
<@err404:matrix.org> j'ai déjà eu des problèmes sur certains paquets après mise à jour de ces paquets (via l'interface graphique de yunohost), c'est pas facile de revenir en arière dans certains cas.
alors maintenant je fais d'abord une sauvegarde avec proxmox (mes yunohosts sont dans des machines virtuelles), et si la mise à jour ne se passe pas bien alors je peux restaurer la sauvegarde précédante. (yunohost est très bien pour sauver les applications, mais pas pour lui même, ou bien j'ai pas trouvé)
[17:40:33]
<@err404:matrix.org> yunohost est un outil formidable qui permet de gagner pas mal de temps, et en général ça se passe vraiment très bien
[17:43:05]
<nalla22> > <@err404:matrix.org> j'ai déjà eu des problèmes sur certains paquets après mise à jour de ces paquets (via l'interface graphique de yunohost), c'est pas facile de revenir en arière dans certains cas.
> alors maintenant je fais d'abord une sauvegarde avec proxmox (mes yunohosts sont dans des machines virtuelles), et si la mise à jour ne se passe pas bien alors je peux restaurer la sauvegarde précédante. (yunohost est très bien pour sauver les applications, mais pas pour lui même, ou bien j'ai pas trouvé)
Effectivement, c'est pour cette raison que je préfère installer yunohost en évitant les transitions qui peuvent faire planter le système. Qu'elles sont les paquets qui ont été problématiques dans ton cas ? Est-ce que tu as perdu des données ?
[17:44:41]
<@err404:matrix.org> navidrome qui ne lisait plus la musique, mais j'ai attendu un peu et à un moment navidrome a pu lire les musiques après mise à jour, je n'ai pas cherché plus loin
[17:46:32]
<lapineige> > je ne partage pas ce retour d'experience et les migrations se passent toujours bien lorsqu'elles sont correctement faites par l'administrateur du serveur.
Il y a toujours un certain nombre de cas qui posent problème, notamment peu après la sortie, car fatalement tout n'a pas pu être testé. La dernière s'est globalement très bien passée, mais ce n'est pas magique non plus (ni une question de compétences)
[17:46:43]
<@err404:matrix.org> le problème à duré quelques semaines environ (je testais une fois par semaine)
[17:46:48]
<nalla22> > <@err404:matrix.org> navidrome qui ne lisait plus la musique, mais j'ai attendu un peu et à un moment navidrome a pu lire les musiques après mise à jour, je n'ai pas cherché plus loin
Tu utilisais beaucoup d'applications ou pas ?
J'ai vu qu'une liste de compatibilité a été mise en place par les admins concernant la compatibilité des applications avec Debian 12 : https://dash.yunohost.org/appci/compare/stable...bookworm
[17:47:24]
<@err404:matrix.org> par contre c'était avant la sortie de debian 12, ça ne concerne pas un problème avec debian 12
[17:48:24]
<@err404:matrix.org> j'ai eu une VM de test yunohost avec une bonne dizaine d'applications (tu veux tester un truc? tu clic et hop c'est installé :p)
[17:49:11]
<Aleks (he/him/il/lui)> > <@nalla22:matrix.org> Effectivement, c'est pour cette raison que je préfère installer yunohost en évitant les transitions qui peuvent faire planter le système. Qu'elles sont les paquets qui ont été problématiques dans ton cas ? Est-ce que tu as perdu des données ?
tôt ou tard tu devras faire une mise à jour majeure, si c'est pas 11->12, ce sera 12->13, essayer d'esquiver le problème n'apporte pas grand chose, c'est quand même + constructif de juste apprendre à faire le passage en étant méthodique : backup complet du système, tu lances le truc, si ça plante alors tu demandes de l'aide (sans appuyer frénétiquement sur tout les boutons pour bruteforcer le truc ce qui souvent empire la situation), et tu itères avec l'équipe
[17:49:49]
<@err404:matrix.org> maintenant que j'utilise proxmox pour gérer mes VM yunohost, j'ai des yunohosts avec moins d'applications, donc potentiellement moins de risque de conflits
[17:49:54]
<nalla22> > <@err404:matrix.org> j'ai eu une VM de test yunohost avec une bonne dizaine d'applications (tu veux tester un truc? tu clic et hop c'est installé :p)
Je pense que je vais faire la même chose, je vais créer une VM de test aussi
[17:50:34]
<@err404:matrix.org> et du coup je peux faire les tests de migration sur des VM yunohost de test
[17:50:34]
<Aleks (he/him/il/lui)> > <@nalla22:matrix.org> Tu utilisais beaucoup d'applications ou pas ?
> J'ai vu qu'une liste de compatibilité a été mise en place par les admins concernant la compatibilité des applications avec Debian 12 : https://dash.yunohost.org/appci/compare/stable...bookworm
oui enfin super de partager à tout le monde un outil qui est fait pour les développeurs et uniquement destinés aux devs ... c'est pas une "liste de compatibilité", c'est des tests automatisés et des résultats techniques
[17:50:47]
<Aleks (he/him/il/lui)> si c'est marqué "level 0" ca veut pas dire que le truc sera jamais compatible ou quoi ...
[17:51:37]
<nalla22> > <@Alekswag:matrix.org> tôt ou tard tu devras faire une mise à jour majeure, si c'est pas 11->12, ce sera 12->13, essayer d'esquiver le problème n'apporte pas grand chose, c'est quand même + constructif de juste apprendre à faire le passage en étant méthodique : backup complet du système, tu lances le truc, si ça plante alors tu demandes de l'aide (sans appuyer frénétiquement sur tout les boutons pour bruteforcer le truc ce qui souvent empire la situation), et tu itères avec l'équipe
Le problème c'est que dans mon cas il faudra faire d'énormes sauvegardes car les supports de stockage de la VM yunohost seront remplis à plus de 50TB de données, car je me sert de yunohost en tant que NAS !
[17:51:52]
<Aleks (he/him/il/lui)> ¯\_(ツ)_/¯
[17:52:38]
<nalla22> > <@Alekswag:matrix.org> oui enfin super de partager à tout le monde un outil qui est fait pour les développeurs et uniquement destinés aux devs ... c'est pas une "liste de compatibilité", c'est des tests automatisés et des résultats techniques
Mince ! Je ne savais pas 😅
[17:52:59]
<Aleks (he/him/il/lui)> si t'es pas en mesure de gérer un système ou de le backuper parce que tu as trop de données, peut-être que ça veut dire que tu ne peux pas te permettre de gérer ce système toi-même alors ...
[17:53:33]
<@err404:matrix.org> j'ai passé pas mal de temps à vouloir installer dokuwiki dans une debian, les chemins coté debian ne corespondaient pas à la doc coté dokuwiki, alors qu'avec yunohost certes je ne peux pas choisir les chemins mais ça s'installe en 1 clic et les droits d'accès sont facile à gérer, merci yunohost 😛
[17:55:00]
<lautre> Si tu as 50To, soit c'est une mauvaise stratégie que tu utilises, soit tu dois adapter ta stratégie (peut être que c'est déjà le cas).
regarde aussi du côté de la déduplication. Bref, 50To, c'est pas la cours des petits
[17:55:28]
<nalla22> > <@Alekswag:matrix.org> si t'es pas en mesure de gérer un système ou de le backuper parce que tu as trop de données, peut-être que ça veut dire que tu ne peux pas te permettre de gérer ce système toi-même alors ...
Je peux faire des snapshot et pleins d'autres choses, mais le NAS est censé lui-même permettre de sauvegarder d'autres éléments, je ne suis pas sensé trembler à chaque passage d'une version différente de Debian arce que yunohost gère mal la transition d'après ce que j'ai pu lire ici ! !
[17:55:50]
<lautre> Il y a 10 ans, c'est orange, c'était du P... (c'est pas compliqué, TOUT est enregistré, y compris l'emplacement et le mouvement de la sourie des utilisateurs/clients )
[17:56:00]
<Aleks (he/him/il/lui)> oui enfin "ce que tu as pu lire ici" est basé sur aucun élément précis et juste sur un ressenti d'un utilisateur, si j'ai bien lu
[17:56:27]
<Aleks (he/him/il/lui)> il y a aussi plein de gens sur le forum qui ont cliqué et ça a juste marché, ou bien pleins de gens qui ont eu des problèmes qu'on a réussi à dépatouiller et leur système fonctionne très bien
[17:56:30]
<mavric34> C'est vrai que c'est un problème, il faudrait peut être sortir la transition yunohost seulement quand elle sera vraiment stable
[17:56:36]
<lautre> Rien n'est sensé faire quelque chose... c'est à toi de vérifier ou de configurer/mettre en place
[17:57:23]
<lautre> Yunohost est stable, avec l'usage que j'en fait (et je ne me considère pas tendre)... donc, il est clair que tes besoins dépassent ce que tu as.
[17:57:45]
<Aleks (he/him/il/lui)> > <@mavric34:matrix.org> C'est vrai que c'est un problème, il faudrait peut être sortir la transition yunohost seulement quand elle sera vraiment stable
la transition ne peux pas être magiquement stable, on ne peux pas tester toutes les combinaisons d'apps installées + combinaisons avec le type de hardware, et d'ailleurs une bonne grosse moitié de problèmes viennent aussi des trucs installés à la main par les utilistauers, par exemple les interfaces graphiques
[17:58:34]
<Aleks (he/him/il/lui)> pour info sur le forum de RPi, ils ont carrément dit qu'ils ne supportaient pas du tout la mise à jour de Buster vers Bullseye, il faut juste résintaller. De notre côté on entends au moins fournir une migration, et elle a marché pour plein de monde
[17:58:34]
<nalla22> lautremavric34 et d'autres ont rapportés des mésaventures du genre. Oui mon avis est basé sur ce que vous dites tous !
[18:00:52]
<nalla22> J'espère seulement que la migration sera à la hauteur, car plusieurs de mes serveurs en dépendront !
[18:01:12]
<@err404:matrix.org> nalla22: tu peux installer un yunohost dans une VM, avec toutes tes applications, mais sans les données utilisateur (donc ça ne prendra pas 50To) et du coup tu pourra tester la migration
[18:02:13]
<Aleks (he/him/il/lui)> en vrai un `apt dist-upgrade` n'a jamais supprimé 50 To de données hein ...
[18:02:16]
<nalla22> > <@err404:matrix.org> nalla22: tu peux installer un yunohost dans une VM, avec toutes tes applications, mais sans les données utilisateur (donc ça ne prendra pas 50To) et du coup tu pourra tester la migration
Effectivement, c'est ce que je comptais faire. J'utiliserai une VM témoin !
[18:02:16]
<lautre> C'est pas parce qu'on utilise des trucs magiques que ça dispense de faire des tests de migration et de prendre des précautions avant de migrer, y compris des sauvegardes
[18:02:50]
<lautre> Surtout des sauvegardes... c'est aussi le moment de revérifier les restaurations (une sauvegarde non vérifiée ne sert à rien)
[18:02:59]
<lautre> C'est du boulot, en effet
[18:05:20]
<nalla22> > <@Alekswag:matrix.org> en vrai un `apt dist-upgrade` n'a jamais supprimé 50 To de données hein ...
Sur la VM yunohost, j'aurai le /var qui sera sur le ssd d'installation (avec toutes les données des applications), et j'aurai également un deuxième disque constituer d'un ensemble RAID pour toutes les données exploités par Jelyfin, sauvegardes, et d'autres application. Donc en cas de crash de l'installation, je perderai au moin le /var !
[18:06:43]
<nalla22> > <@lautre:matrix.org> Surtout des sauvegardes... c'est aussi le moment de revérifier les restaurations (une sauvegarde non vérifiée ne sert à rien)
Je me base seulement sur le RAIDZ2 et les snapshot pour garantir l'intégrité des données sur le serveur
[18:22:07]
<lautre> Si un jour tu rédiges un article sur ce que tu as mis en place, publie-le sur Linuxfr.org
ça va en intéresser plus d'un😃
[20:15:47]
<@err404:matrix.org> nalla22: moi j'ai choisi une autre voie: je préfère avoir deux serveurs dans deux endroits différents et du coup j'ai moins besoin d'avoir du raid ou autre
[20:16:31]
<@err404:matrix.org> par contre je n'ai pas encore automatisé les sauvegardes, donc je le fais à la main une fois par semaine
[20:17:10]
<@err404:matrix.org> (il y a des VM dont ce n'est pas critique et qui ne bougent pas, celles là je peux me contenter d'une sauvegarde par mois)
[20:19:10]
<@err404:matrix.org> chacun sa stratégie, mais avoir tout au même endroit, même si c'est répliqué, c'est risqué
[20:21:55]
<@err404:matrix.org> je sauvegarde les VM, donc si il y a un problème je peux récupérer une version plus ancienne
[20:22:08]
<@err404:matrix.org> mais c'est encore très manuel,
[20:23:10]
<@err404:matrix.org> ce ne sont pas des serveurs en miroir
[20:24:23]
<@err404:matrix.org> mes VM sont sauvegardées sur le premier serveur et sur le deuxieme, c'est tout
[20:24:24]
<@err404:matrix.org> d'ailleur le deuxieme serveur est bien incapable de faire tourner toutes les VM du premier serveur (cpu faible et pas beaucoup de ram)
[20:25:22]
<lapineige> > <@Alekswag:matrix.org> tôt ou tard tu devras faire une mise à jour majeure, si c'est pas 11->12, ce sera 12->13, essayer d'esquiver le problème n'apporte pas grand chose, c'est quand même + constructif de juste apprendre à faire le passage en étant méthodique : backup complet du système, tu lances le truc, si ça plante alors tu demandes de l'aide (sans appuyer frénétiquement sur tout les boutons pour bruteforcer le truc ce qui souvent empire la situation), et tu itères avec l'équipe
Je comprends bien le côté malcommode / pénible / chronophage de devoir faire une mise à jour majeure.
Cependant attendre la sortie d'une version de Yunohost adaptée, ou pire partir sur une version bêta, me semble poser plusieurs problèmes:
- ça peut être long. On a très peu d'applications compatibles à l'heure actuelle, pratiquement zéro test (ça démarre), et c'est difficile d'avoir une idée de quand le travail sera fini. Il semble raisonnable de compter sur plusieurs mois, d'autant plus si on attend plus de retours d'utilisateurices pour corriger les cas particuliers.
Ce qui veut dire plusieurs mois (probablement) sans le service, et une durée indéterminée.
- il faudra tôt ou tard faire la migration suivante, et plus on a attendu pour la première, plus la version suivante arrive vite ^^
- partir sur une bêta me semble beaucoup plus casse-gueule qu'une version 11, bien éprouvée et fonctionnellement même un moment après que la migration soit disponible, puis une migration certes pas 100% fiable (ça ne sera pas possible) mais beaucoup plus que des versions bêtas *broken by design* et en constante évolution.
À ce jeu là, il me semble limite moins risqué de partir sur une debian 12 sans Yunohost et de la gérer comme telle (donc sans l'automatisation de Yunohost) puis de migrer les services (ça reste du boulot) après installation de Yunohost.
Par contre, pour tester (= on peut tout perdre sans grande conséquence), ça peut se faire, quitter à répliquer le système, certaines applications (sauvegarde YNH + restauration sur le nouveau) et données utilisateurs pour voir ce que ça donne, ça me semble beaucoup plus instructif pour voir ce qui marche, voir utile pour faire progresser Yunohost et préparer une vraie migration ensuite.
À toi de voir si c'est quelque chose de plus intéressant pour toi que de partir sur Debian 11.
[20:30:36]
<lapineige> > Donc si je voulais monter un autre serveur de sauvegarde il faudra également le mettre à jour matériellement pour qu'il puisse suivre le serveur de production, ce qui va me coûtera une somme phénoménale
Oui.
Et dans le même temps, combien coûterait une perte (vs le risque de perdre les données) ?
Cette balance là va compter.
Le risque d'un problème sur le local où est le NAS/serveur peut être limité, en tout cas on peut le considérer acceptable face aux autres problématiques (coût d'une sauvegarde externalisée, …).
Par contre si ça implique ne pas avoir la possibilité d'une sauvegarde à un instant T pour annuler une erreur logiciel ou humaine, c'est un enjeu plus global. Et la moindre migration d'une version de Debian, ou d'un des logiciels utilisé, peut casser tout ça.
[20:32:41]
<lapineige> Quelque soit la qualité de Yunohost, Debian ou n'importe quoi d'autres, il n'y aura jamais de garanti absolue, ni même très très grande, que dans 100% des cas ça se passe sans dommage (irréparable).
(J'en profite pour rappeler que Yunohost est développé par des bénévoles, avec des moyens limités, et s'il est de bonne qualité générale il n'est pas prévu (ni promu) comme un outil magique qui sera (presque) infaillible. Ça ne veut pas dire qu'on ne peut pas critiquer ses limites, mais qu'il faut en avoir conscience en le choisissant)
[20:34:30]
<lapineige> Quelque soit la qualité de Yunohost, Debian ou n'importe quoi d'autres, il n'y aura jamais de garanti absolue, ni même très très grande, que dans 100% des cas ça se passe sans dommage (irréparable).
*(J'en profite pour rappeler que Yunohost est développé par des bénévoles, avec des moyens limités, et s'il est de bonne qualité générale il n'est pas prévu (ni promu) comme un outil magique qui sera (presque) infaillible. Ça ne veut pas dire qu'on ne peut pas critiquer ses limites, mais qu'il faut en avoir conscience en le choisissant)*
[20:35:05]
<nalla22> > Oui.
> Et dans le même temps, combien coûterait une perte (vs le risque de perdre les données) ?
> Cette balance là va compter.
> Le risque d'un problème sur le local où est le NAS/serveur peut être limité, en tout cas on peut le considérer acceptable face aux autres problématiques (coût d'une sauvegarde externalisée, …).
>
> Par contre si ça implique ne pas avoir la possibilité d'une sauvegarde à un instant T pour annuler une erreur logiciel ou humaine, c'est un enjeu plus global. Et la moindre migration d'une version de Debian, ou d'un des logiciels utilisé, peut casser tout ça.
D'après mon expérience, il est plus sûr de blinder un serveur en RAID avec des disques en redondance que de miser sur un deuxième serveur en miroir.
C'est moins couteaux, il est possible de faire des snapshot, il est également possible de dupliquer un disque dur virtuel (système) sur une deuxième pool pour une sauvegarde sur deux pool tout en restant sur le même serveur, faire une sauvegarde des fichiers les plus importants sur une machine cliente "chiffrée" (gestionnaire de mots de passe, documents…)… Et d'investir autour pour des protections physique, de la domotique pour prévenir un risque d'incendies ou d'intrusion physique, alarme et câble antivols...
[20:39:30]
<@err404:matrix.org> mon serveur est chez moi, dans un immeuble d'habitation, donc le risque d'incendie est loin d'être nul, c'est pour ça que je privilegie un deuxieme serveur ailleurs plutôt que du raid au même endroit.
et je n'ai pas les moyens d'avoir du raid (du moins je ne veux pas me donner les moyens d'avoir du raid), la présence d'un deuxieme serveur me suffit
[20:40:16]
<@err404:matrix.org> et mes serveurs ne sont pas en miroir, seul le premier est sauvegardé sur place et vers le deuxieme serveur, ce n'est pas le mieux
[20:45:11]
<nalla22> > <@err404:matrix.org> mon serveur est chez moi, dans un immeuble d'habitation, donc le risque d'incendie est loin d'être nul, c'est pour ça que je privilegie un deuxieme serveur ailleurs plutôt que du raid au même endroit.
> et je n'ai pas les moyens d'avoir du raid (du moins je ne veux pas me donner les moyens d'avoir du raid), la présence d'un deuxieme serveur me suffit
Je comprends bien, je pense que chacun a ses propres stratégies basées sur ses propres expériences !
[20:58:01]
<lapineige> > <@nalla22:matrix.org> D'après mon expérience, il est plus sûr de blinder un serveur en RAID avec des disques en redondance que de miser sur un deuxième serveur en miroir.
>
> C'est moins couteaux, il est possible de faire des snapshot, il est également possible de dupliquer un disque dur virtuel (système) sur une deuxième pool pour une sauvegarde sur deux pool tout en restant sur le même serveur, faire une sauvegarde des fichiers les plus importants sur une machine cliente "chiffrée" (gestionnaire de mots de passe, documents…)… Et d'investir autour pour des protections physique, de la domotique pour prévenir un risque d'incendies ou d'intrusion physique, alarme et câble antivols...
Mais ce n'est pas résilient à un problème en local. Cela les rend moins probables, mais si ça arrive, kaboum.
[21:06:21]
<nalla22> > Mais ce n'est pas résilient à un problème en local. Cela les rend moins probables, mais si ça arrive, kaboum.
Encore une fois, les probabilités sont infimes. Ma stratégie est tout d'abord sécuritaire. Je préfère que mes données soient détruites que de tomber entre de mauvaises mains. Ensuite pour ce qui est d'une mauvaise manipulation des données, ça peut arriver mais c'est très rare (pour ma part). Depuis 2015 j'utilise un serveur de 40TB avec beaucoup moins de sécurité de données que celui que je configure actuellement, et jamais eu de soucis en termes de suppression malencontreuse de données importantes ou autres. Je mettrais de toute manière certaines sécurités lors de la suppression de données sur des partitions spécifiques !
[21:09:56]
<lapineige> Mais tu n'as pas d'assurance de revenir en arrière en cas de mise à niveau version Debian 12 raté si je comprends bien ?
C'est une limite forte.
[21:10:00]
<lapineige> Mais tu n'as pas d'assurance de revenir en arrière en cas de mise à niveau version Debian 12 ratée si je comprends bien ?
C'est une limite forte.
[21:12:31]
<nalla22> > Mais tu n'as pas d'assurance de revenir en arrière en cas de mise à niveau version Debian 12 ratée si je comprends bien ?
> C'est une limite forte.
Si j'aurai une garantie de revenir en arrière, car le disque virtuel (system) sera stocké sur la pool SSD en RAIDZ de 7TB, je dupliquerai ce dique sur la pool RAIDZ2 juste avant la grande mise à jour et après avoir effectué des tests de mise à jour sur VM témoin…
[21:12:59]
<lapineige> ah ben cool, mais du coup de quel problème on parle depuis tout à l'heure ?
[21:14:51]
<nalla22> > ah ben cool, mais du coup de quel problème on parle depuis tout à l'heure ?
Le deuxième disque virtuel qui sert de stockage de masse, ne sera pas dupliqué sur l'autre pool car il pèse une tonne. Il faudra donc que je le détache de la VM avant d'effectuer la mise à jour
[21:15:03]
<lautre> Ben, Yunohost peut être utilisé sur des systèmes familiaux avec des pelletées de Téraoctets
[21:15:27]
<lapineige> > <@nalla22:matrix.org> Le deuxième disque virtuel qui sert de stockage de masse, ne sera pas dupliqué sur l'autre pool car il pèse une tonne. Il faudra donc que je le détache de la VM avant d'effectuer la mise à jour
et ça ne va pas poser problème pour la mise à niveau (applications comprises) ? (y'a quoi dessus)
[21:18:02]
<nalla22> > et ça ne va pas poser problème pour la mise à niveau (applications comprises) ? (y'a quoi dessus)
Non car il ne contiendra pas de racine système, il sera seulement monté sur un dossier /mnt ou autre pour exploiter les données qu'il contiendra par les applications yunohost. Les téléchargements avec Deluge/transmission se feront directement sur ce disque par exemple !
[21:18:29]
<nalla22> Je compte installer SMB sur le même OS que yunohost pour gérer les dossiers partagés
[21:20:20]
<nalla22> Donc il ne sera pas nécéssaire pour la mise à jour normalement. Je prendrai soin d'arrêter tous les services des applications avant d'entreprendre la mise à jour !
[21:20:59]
<@err404:matrix.org> moi j'utilise sshfs, qui ne m'a jamais trahi 😛
[21:23:24]
<nalla22> intéressant, est-ce que tu as déjà utilisé SMB avec Yunohost ? Est-ce que tu utilise sshfs avec yunohost ?
[21:27:42]
<pti-jean> nalla22, SMB avec YunoHost, ça fait peur... faut installer des truc... risque de dénaturer YunoHost... puis niveau sécurité, c'est à risque! Tandis que sshfs, s'utilise sans rein installer !
[21:30:03]
<nalla22> > <pti-jean> nalla22, SMB avec YunoHost, ça fait peur... faut installer des truc... risque de dénaturer YunoHost... puis niveau sécurité, c'est à risque! Tandis que sshfs, s'utilise sans rein installer !
Merci pour le conseil, mais je ne sais pas ce que sshfs donne au niveau performances face à SMB ! Est-ce que je pourrais avoir les mêmes performances en utilisant SSHFS qu'avec SAMBA ?
[21:31:09]
<pti-jean> À mon avis sshfs doit être encore plus performent que samba !
[21:32:39]
<pti-jean> Car il me semble que ssh est plus léger que samba !
[21:33:23]
<nalla22> Merci. C'est une information que je n'avais pas. Je vais approfondir mes recherches concernant SSHFS, car s'il peut remplir les mêmes tâches que SAMBA, ça serait carrément plus pratique pour une installation NAS !
[21:35:26]
<pti-jean> nalla22, Si tu désire gérer des backup de YunoHost avec un Nas... Borg backup est ton amis... Y a une apps pour YunoHost!
[21:37:54]
<nalla22> C'est noté. Car jusqu'à maintenant je gèrais les sauvegardes que du côté de l'hyperviseur avec proxmox, et synchting à l'intérieur des VM
[21:40:13]
<pti-jean> Depuis que j'ai opté pour Borg pour mes backup... Je suis tranquille... Tous les soir à 12h, j'ai un backup incrémentiel qui s’exécute... Et tout ça automatisé... rein à géré !
[21:41:58]
<pti-jean> Et si je me souviens bien... Borg utilise ssh pour effectuer ses backup!
[21:43:31]
<nalla22> D'accord. Apparement il ne possède pas d'interface graphique d'après ce que je vois https://borgbackup.readthedocs.io/en/stable/
[21:44:55]
<lapineige> Pour un serveur distant, non pas vraiment (à ma connaissance), à part Borg Web (pas sûr qu'il soit suffisamment stable).
En local Vorta fait le taf.
[21:46:24]
<pti-jean> Non... pas d'interface graphique... Il faut te faire un pence bête de quelque commande de base... Mais, c'est-un régal en ligne de commande... Puis en ligne de commande, c'est plus simple pour obtenir une aide !
[21:46:40]
<nalla22> https://aria.im/_matrix/media/v1/download/matrix.org/csKUhKHFQtrfGENWTqEXZfFg
[21:46:40]
<nalla22> Apparement il a bien une interface graphique, je ne sais pas si elle est intégré dans yunohost
[21:48:54]
<pti-jean> Dans YunoHost, pas besoin d'interface graphique... Tu as juste une interface de configuration... Une fois configuré... tu n'y touche plus... il gère les sauvegarde tout seul!
[21:51:46]
<nalla22> Dans ce cas, je testerai Borg backup. Je testerai également le SSHFS dans un objectif de remplacer définitivement SAMBA, j'espère que ça ne posera pas de problèmes !
[21:54:00]
<pti-jean> Pour restaurer... y a une commande que je peux retrouvé pour extraire l'archive sous forme d'un fichier .tar (si je me rappelle bien)... Tu donnes fichier à manger à YunoHost dans le répertoire backup/archives/... et la sauvegarde apparaît dans le webadmin dans les backup!
[22:17:27]
<lapineige> > <pti-jean> Dans YunoHost, pas besoin d'interface graphique... Tu as juste une interface de configuration... Une fois configuré... tu n'y touche plus... il gère les sauvegarde tout seul!
sauf pour restaurer. Et là faut comprendre un peu
[22:19:22]
<pti-jean> Oui... Mais quand on gère un serveur YunoHost... cela ne devrait pas poser un problème !
[22:39:46]
<lapineige> Au moment de la cata c'est bien de maîtriser un peu pour comprendre ce qu'on doit/peut faire 😅