[10:26:35]
<LoboAureo> Hi, i've got an old computer and want to use it with yuno, but also, that it can be use as a normal computer (web browse, docs, etc). So what's its the best approach:
install yuno and then a desktop environment, or install debian with desktop and later update with yuno?
is there any guide to make this?
[10:26:38]
<DJ Chase (fae/faer)> out of curiosity, why do you want to do that?
[10:27:41]
<orhtej2> > <@loboaureo:matrix.org> Hi, i've got an old computer and want to use it with yuno, but also, that it can be use as a normal computer (web browse, docs, etc). So what's its the best approach:
> install yuno and then a desktop environment, or install debian with desktop and later update with yuno?
> is there any guide to make this?
There are stories on the forums that point towards running full blown desktop environments alongside yunohost causing trouble
[10:27:51]
<orhtej2> so the best approach would be run inside a vm and forward ports to keep the environments separate
[10:36:36]
<LoboAureo> Will be an always on computer, but also my backup computer :)
[10:36:39]
<LoboAureo> Search in that direction, thanks!!
[11:10:28]
<Crou2> Hello 👋
I have installed then removed Scrutiny application in my Yunohost server. However, I may have done something wrong and Scrutiny application wasn't removed properly. I still have scrutiny-collector and scrutiny-web-server that appears in my list of yunohost services (in web admin portal). It is said "service scrutiny-collector is unknown :-( "
Could you advice me how to remove properly these yunohost services and any remaining element from this scrutiny application?
Thanks in advance 🙂
[11:49:09]
<otm33> yunohost service remove scrutiny-collector and yunohost service remove scrutiny-web-server
[13:02:41]
<Crou2> thanks @otm33:matrix.org for your advives, I'll do it. 🤗
[13:16:47]
<Gwên> Coucou, je pose la question pour quelqu'un d'autre
[13:16:51]
<Gwên> Matterbridge c'est toujours maintenu ?
[13:54:01]
<Chatpitaine Caverne> Gwên: ça en a l'iar.
Il y a des PR récentes dans le github ynh-app.
Le manifest indique qu'elle est à la dernière version disponible de Matterbridge.
Elle a un petit diamant dans le catalogue.
Maintenant, il vaut sans doute mieux laisser les packagers de l'app te le confirmer.
[13:54:10]
<Gwên> Non je veux dire, pas le paquet Yunohost
[13:54:13]
<Gwên> Le logiciel lui-même
[13:54:15]
<Chatpitaine Caverne> Ah, pardon.
[13:54:18]
<Gwên> Pas de soucis, j'aurais dû clarifier
[13:54:20]
<Gwên> Comme la dernière version date de 2023
[13:54:22]
<Chatpitaine Caverne> La dernière Release date de janvier 2023. Pas terrible. Apràs elle fonctionne peut-être trop bien ? Il y a des PR récentes tout de même.
[13:54:26]
<Ouranos> https://github.com/matterbridge-org/matterbridge J'ai pris connaissance de ce fork en allant voir les PR en attente dans matterbridge premier du nom, mais pas encore de release (voir issue #133)
[16:24:14]
<khrys> Bonjour, suite à mon souci de port 5349 non ouvert j'aimerais bien comprendre d'où ça vient et si possible le résoudre : est-ce que quelqu'un·e aurait des lignes de commandes pour m'aider à avancer ? Je précise que mon serveur YNH est derrière un VPN FDN et qu'"avant" (la dernière MAJ ? Le dernier reboot physique suite à la perte de connexion ssh suite à la tentative de MAJ ?) il n'y avait pas ce problème...
[16:24:35]
<khrys> (ce n'est pas du tout pressé mais c'est au cas où quelqu'un aurait des billes)
[16:26:27]
<khrys> Le problème étant : l'outil de diagnostic me dit que le port 5349 est fermé, ce port servant au service coturn servant lui-même au serveur XMPP installé via YNH
[16:36:07]
<Aleks (he/him/il/lui)> hmm chelou si ça marchait avant et que d'un seul coup ça marche plus après maj, mais du coup naivement je ferais :
- checker si le port est ouvert dans le firewall (en webadmin dans Outils > Parefeu, ou bien en cli avec `yunohost firewall list`)
- si il ne l'est pas, l'ouvrir (au meme endroit dans Outils > Parefeu, ou bien en cli avec `yunohost firewall allow Both 5349`)
- il se peut aussi que ce soit un faux positif/faux négatif, genre Coturn est un peu un cas particulier je crois, soit il est pas vraiment actif tout le temps, soit en fait il écoute en UDP, mais le diagnostique de yunohost est pas capable de vérifier si un port UDP est vraiment ouvert / exposé sur internet (parce que pour ce faire, on ouvre un socket TCP quand il s'agit de TCP, mais y'a pas de socket UDP bref) et dans ce cas il faut juste ignorer le probleme dans le diagnostique puisque le probleme n'en est pas peut-être pas un
[16:36:13]
<Aleks (he/him/il/lui)> aussi y'a moyen de faire un `ss -tulpn | grep 5349` pour confirmer que y'a bien un process qui écoute sur le port 5349
[16:40:33]
<khrys> J'ai tcp:
- 22
- 25
- 80
- 443
- 587
- 993
- 1935
- 5222
- 5223
- 5269
- 5349
- 5350
[16:41:35]
<khrys> Ça liste les ports ouverts ou fermés ?
[16:41:44]
<khrys> yunohost firewall allow Both 5349 n'a rien modifié
[16:42:25]
<khrys> Ah par contre dans l'outil parefeu ça m'a mis le port en vert
[16:43:47]
<khrys> En revanche l'outil de diagnostic me dit toujours Le port 5349 n'est pas accessible depuis l'extérieur.
[16:45:09]
<khrys> ss -tulpn | grep 5349 me dit des trucs mais je ne sais pas si c'est bien ou pas bien ^_^
[16:45:48]
<khrys> Comment je peux voir si le port est vraiment ouvert ou pas ?
[16:59:15]
<otm33> As-tu aussi regardé si coturn était actif ? `sudo systemctl status coturn`
[17:07:42]
<khrys> Oui, il est actif, running (ce que me dit aussi l'outil listant les services)
[17:12:12]
<otm33> Depuis l'extérieur de ton réseau local : `nc -vvv -w 10 -z domain.tld 5349`
[17:18:04]
<khrys> J'ai un Connection refused
[17:19:07]
<khrys> (je me suis mise sur mon tel pour être sûre mais cela me le fait aussi de mon réseau wi-fi local vu qu'il y a un VPN)
[17:19:30]
<khrys> (et que ce n'est pas mon YNH qui me fournit le wifi ;-)
[17:21:18]
<Salamandar> et depuis ton réseau local ?
[17:21:20]
<Salamandar> (en mettant l'IP au lieu du domaine)
[17:21:24]
<Salamandar> et avec l'IP locale de ta machine ?
[17:24:32]
<khrys> Comment je fais, je me mets sur la machine en ssh et je pingue le port ?
[17:25:00]
<khrys> (je n'ai pas d'antenne wi-fi pour le serveur YNH)
[17:26:47]
<khrys> Depuis la machine en ssh même réponse
[17:27:15]
<khrys> ah j'ai fait avec l'IP FDN j'essaie avec la locale
[17:28:06]
<khrys> Connection to 192.168.2.82 5349 port [tcp/*] succeeded!
[17:45:18]
<Salamandar> tu ne peux pas te connecter sur le même réseau local ?
[17:45:22]
<Salamandar> OK bon bah c'est probablement ton VPN qui déconne
[17:45:24]
<otm33> Un pare-feu capricieux ?
[17:45:27]
<Salamandar> ou alors une config foireuse de coturn qui n'écoute que sur une seule interface
[17:49:46]
<otm33> Tu avais déjà soulevé ce pb d'ouverture de ce port il y a qqs jours, non ? J'avais fait un test et tout était ok. J'ai ré-essayé il y a qqs minutes et... le port était vu comme fermé. Je n'ai pourtant fait que recréer la règle dans 1 PF et la réactiver dans l'autre. J'ai désactivé-réactivé dans le PF1 et recréé la règle dans PF2 : port ouvert... Donc pare-feu capricieux ou... interface siège-machine qui a confondu 5349 et 5439 dans PF2.
[17:51:02]
<Chatpitaine Caverne>
> interface siège-machine
C'est rigolo cette expression.
[17:51:53]
<khrys> C'est bien 5349 :-)
[17:53:12]
<khrys> Il ne me semble pas avoir varié de port dans mes messages
[17:54:02]
<otm33> interface siège-machine: je parlais de moi dans mon test.
[17:54:25]
<khrys> Et FDN ne bloque pas les ports on vient de me le confirmer fièrement 😋️
[17:54:47]
<khrys> ah oki 😁️
[18:04:02]
<Salamandar> Oui enfin là on vient de confirmer que le port est bien ouvert sur la machine
[18:04:03]
<Salamandar> mais pas côté VPN…
[18:04:05]
<Chatpitaine Caverne> C'est cool de le préciser. Mais je crois qu'on est tou.te.s égaux sur ce point. On hallucine peut-être moins que des IA (enfin ça dépend des substances qu'on consomme) mais on fait assez facilement des bêtises.
[18:11:21]
<khrys> Ça pourrait pas être une histoire d'IPv4/v6 ?
[18:17:30]
<otm33> Cela fonctionnait auparavant en plus, non ?
[18:18:23]
<khrys> yep...
[18:18:32]
<khrys> (mais je suis abonnée aux trucs chelous)
[18:18:55]
<khrys> s'il y a un bug quelque part, c'est pour moi 😋️
[18:19:48]
<pti-jean> Je suis chez FDN pour le VPN... Je viens de jouer avec netcat, il semble que FDN bloque le port UDP (et pas le TCP) 5349
[18:22:01]
<pti-jean> Ce qui semble être la source de votre problème!
[18:25:24]
<khrys> oh je vais dire ça (je suis en train d'en parler en query sur IRC)
[18:27:31]
<pti-jean> khrys, Tu es sur les IRC de FDN ?
[18:28:02]
<pti-jean> Je viens de m'y connecter !
[18:29:12]
<khrys> Je suis en query ;-)
[18:29:52]
<khrys> avec un gentil adminsys qui est en train de regarder
[18:30:40]
<pti-jean> C'est quoi en query ??
[18:32:27]
<khrys> en privé
[18:32:35]
<pti-jean> ok
[18:34:06]
<pti-jean> Au pire, je viens de me mettre sur les IRC de FDN... Mais je vais bientôt sortir manger !
[18:38:59]
<khrys> oki :-)
[19:01:40]
<otm33> Oui, peut-être vérifier dans /etc/turnserver.conf que l'/les ip publiques sont bien les bonnes. Peu probable que ce ne soit pas le cas mais...
[19:02:56]
<·☽•Nameless☆•777 · ±> > https://www.grc.com/x/ne.dll?rh1dkyd2
[19:03:00]
<·☽•Nameless☆•777 · ±> Pour tester quels ports sont ouverts vers sa box ou son pare-feu
[19:03:04]
<otm33> Tu peux faire le test en ipv6 en ajoutant -6 je crois
[19:03:24]
<·☽•Nameless☆•777 · ±> C'est FDN ou un intermédiaire ,
j'ai déjà lu des cas où l'opérateur d'infrastructure s'était permis de bloquer Samba, ntp, DNS
[19:03:46]
<otm33> Quelle réponse obtiens-tu en testant en UDP ?
[19:07:58]
<khrys> Bon on me confirme qu'il n'y a pas de souci a priori côté FDN... Et on vient de résoudre le problème : il fallait redémarrer coturn
[19:08:20]
<khrys> (j'avais tout redémarré mais pas juste le service, une fois le VPN démarré)
[19:09:09]
<khrys> Bref, je n'ai plus de problèmes de ports, désolée pour le bruit...
[19:13:00]
<khrys> note to self : l'ordre de redémarrage des services est important et tout rebooter ne résout pas forcément le problème en ce cas
[19:15:52]
<pti-jean> Ils ont dû intervenir chez FDN... sans s'en venter... Car tout-à l'heure, le port était bien bloqué !
[19:15:53]
<anubis> khrys, n'hésite pas à documenter ton cas sur l'app coturn ou sur https://github.com/YunoHost-Apps/prosody_ynh , ca peut nous intéresser pour les prochains troubleshooting
[19:18:16]
<khrys> Avec plaisir mais où ça exactement, pour l'app coturn ? En ce qui concerne github j'y touche le moins possible depuis que c'est à M$
[23:17:53]
<Salamandar> Je suis de l'avis de pti-jean: Ton port était accessible en local d'après toi, donc coturn était bien actif ^^
[23:54:30]
<pti-jean> khrys, Je viens de renter... à mon avis, FDN te l'ont débloqué juste pour toi... Car pour moi, je viens de faire un test... il est toujours bloqué !
[23:59:56]
<otm33> pti-jean: sans blague ?