[06:36:22]
<0x346e3730> > <@titus:pijean.ovh> 0x346e3730: je suis vraiment désolé, en fait l'autoconfig je l'avais codée pour Bazarr... ça fait trop d'application en *arr!
C'est ce que j'ai remarqué hier en l'installant :D Mais je n'arrive toujours pas à setup Sonarr avec Prowlarr... j'ai aussi l'impression que Sonarr est en retard en terme de version, j'ai des options de config que j'ai sur les autres *arr que je n'ai pas sur Sonarr... 🤔
[10:11:01]
<nalla22> Bonjour, J'ai essayé d'installer le certificat auto-signé en suivant ce tutoriel : https://techexpert.tips/nginx/enable-https-nginx/l'URL
j'ai fait un premier test en configurant le nom commun du certificat avec `127.0.0.1:8098` mais ça n'a pas fonctionné malgré la configuration nginx du fichier `/etc/nginx/sites-available/default`
[10:11:09]
<nalla22> https://aria.im/_matrix/media/v1/download/matrix.org/ggVEYGXewFXgkkMEEEFBdgCq
[10:11:48]
<nalla22> Ensuite j'ai recréé un autre certificat auto-signé avec le nom commun `192.168.0.110:8098` mais ça n'a toujours pas fonctionné
[10:12:11]
<nalla22> https://aria.im/_matrix/media/v1/download/matrix.org/MmUIQrEhOXntIjeebkACCMcC
[10:12:33]
<nalla22> Mon objectif est de faire fonctionner Radarr en HTTPS directement sur l'adresse IP local
suivante `https://192.168.0.110:8098` !
[10:12:50]
<nalla22> Est-ce que c'est la configuration yunohost de nginx qui bloque ? Ou est-ce que j'ai mal fait quelque chose ?
[10:17:15]
<Aleks (he/him/il/lui)> :| ...
[12:28:22]
<0x346e3730> > <@nalla22:matrix.org> Est-ce que c'est la configuration yunohost de nginx qui bloque ? Ou est-ce que j'ai mal fait quelque chose ?
Il n'est pas possible de faire des certificats HTTPs pour des IPs locales
[12:30:36]
<nalla22> > <@0x346e3730:matrix.org> Il n'est pas possible de faire des certificats HTTPs pour des IPs locales
Pardon ?!
J'utilise syncthing et webmin en HTTPS avec l'IP locale, yunohost lui-même fonctionne en HTTPS sur adresse IP locale 🤔
[12:31:56]
<nalla22> Regarde l'URL : https://i.imgur.com/fVGx2RD.png
[12:33:16]
<0x346e3730> L'URL ne veut pas dire que le certificat est valide et trusté par le browser
[12:34:12]
<nalla22> Le certificat est valide et le HTTPS fonctionne sur les IP en LAN. Merci quand même de ton aide !
[12:39:35]
<0x346e3730> Je pense que c'est une mauvaise idée d'essayer de contourner le fonctionnement de YunoHost qui est de faire fonctionner les applis sur des domaines. ça n'empêche pas que les applis peuvent communiquer entre elles via leurs adresses IPs et ports respectifs. Avec plaisir !
[12:41:30]
<nalla22> > <@0x346e3730:matrix.org> Je pense que c'est une mauvaise idée d'essayer de contourner le fonctionnement de YunoHost qui est de faire fonctionner les applis sur des domaines. ça n'empêche pas que les applis peuvent communiquer entre elles via leurs adresses IPs et ports respectifs. Avec plaisir !
Merci pour votre message, mais chacun a des besoins différents, mes besoins ne sont pas forcément les mêmes que les vôtres. Bonne journée !
[12:43:46]
<tomlamo> Bonjour, autre sujet : sur un serveur yunohost, j'ai 100 Go de données dans /root/data/nextcloud/nextcloud/data, alors que les données nextcloud sont dans /home/yunohost.app/nextcloud/data. Est-ce que quelqu'un a une idée de ce que sont ces données ? Est-ce que je peux les supprimer ?
J'ai aussi des données (15 Go) dans /root/home.
[12:46:48]
<0x346e3730> > <@tomlamo:matrix.org> Bonjour, autre sujet : sur un serveur yunohost, j'ai 100 Go de données dans /root/data/nextcloud/nextcloud/data, alors que les données nextcloud sont dans /home/yunohost.app/nextcloud/data. Est-ce que quelqu'un a une idée de ce que sont ces données ? Est-ce que je peux les supprimer ?
> J'ai aussi des données (15 Go) dans /root/home.
L'un des deux est probablement un symlink vers l'autre, vérifiable avec `ls -al`
[12:49:46]
<0x346e3730> Voilà à quoi ressemble des liens symboliques (ici "Torrents" et "Torrent to download") :
[12:49:48]
<0x346e3730> https://aria.im/_matrix/media/v1/download/matrix.org/tTcPPmferIWpkMfwQPjjMenX
[13:05:35]
<tomlamo> Oui j'ai vérifié, pas de lien symbolique, et les données dans /root/data/nextcloud sont anciennes (plus d'un an).
[13:05:57]
<tomlamo> A priori, il n'y a pas de raison que nextcloud stocke des données dans /root ? Ça doit être une ancienne manip ?
[13:12:22]
<0x346e3730> Peut être des relicas d'avant une upgrade (de l'appli ou de YunoHost) qui n'ont pas été supprimés ?
[13:12:33]
<tomlamo> Bon, j'ai vérifié sur un autre serveur, /root est vide, donc ça doit être des anciennes sauvegardes manuelles, je vire. Merci !
[13:15:05]
<rico416> Hello all,
After successfully installing Pydio and setting an admin password, I can't login! I receive a "Login Failed" message with any input I use for user account: admin, root, pydio, cells and even the yunohost admin account.
Any help would be appreciated?
On a side-note, the same thing happens with PhotoPrism.
What am I missing?
Regards,
rico416
[13:53:38]
<T> User permissions or firewall issues. Is it accessible from the outside (in case you are trying from the web)?
[13:55:02]
<rico416> > <@tsh:envs.net> User permissions or firewall issues. Is it accessible from the outside (in case you are trying from the web)?
Yes, it's fully accessible externally.
[13:58:19]
<rico416> Currently: all_users & visitors are "currently allowed to access this app".
[14:23:04]
<T> > <@rico416:matrix.org> Currently: all_users & visitors are "currently allowed to access this app".
Should I assume that you set a password for the app when installing it? I'm reffering to the Install settings in the web admin area.
[14:24:12]
<T> https://aria.im/_matrix/media/v1/download/envs.net/90d0e71c94a0f36b94f9f98f376d0f7a08dde094
[14:32:26]
<rico416> > <@tsh:envs.net> sent an image.
That's correct. I did.
[14:33:02]
<T> Any possibility that you had caps lock on when setting the pass??
[14:33:03]
<rico416> > <@tsh:envs.net> sent an image.
Since I've got the password, what should I be using as the login ID?
[14:33:27]
<T> Which user did you choose for the admin?
[14:33:37]
<rico416> > <@tsh:envs.net> Any possibility that you had caps lock on when setting the pass??
I copy and pasted from the BitWarden generator.
[14:34:09]
<T> Bitwarden generator from the mobile client or web one?
[14:34:31]
<rico416> > <@tsh:envs.net> Bitwarden generator from the mobile client or web one?
web.
[14:35:01]
<rico416> > <@tsh:envs.net> Which user did you choose for the admin?
I used 1 of 2 user/admins.
[14:36:26]
<T> When you pasted the pass from Bitwarden, did you copy anything else after that and had to go again to Bitwarden and copy again the password?
[14:37:12]
<T> That is, when trying to enter the login details in the actual app.
[14:38:28]
<rico416> Not that I'm aware of. I've even tried with a shorter password.
[14:39:05]
<T> You mean that you re isntalled the app with another password?
[14:39:14]
<rico416> > <@tsh:envs.net> You mean that you re isntalled the app with another password?
Correct.
[14:39:35]
<T> again copying it from Bitwarden?
[14:40:01]
<rico416> correct.
[14:40:38]
<T> Did you by any chance, got to the history of Bitwarde to copy the password?
[14:42:40]
<T> What I face few times in such situations is that when I have to copy the password tfrom Bitwarde and get to the generator option, the actual pass I want to copy is below the one that Bitwarde has generated.
[14:43:35]
<T> cause eveytime it creates a new password. So maybe the one that you entered in the app when trying to login is the previous one in Bitwarden
[15:06:04]
<rico416> What i'll try doing in the next few minutes is just use a simple password... i'll uninstall, reinstall with simple password and report back.
[16:19:45]
<rico416> something's broken with pydio now. after reinstalling, it broke. after deleting the subdomain and recreating it, then install pydio, it's still broken. agh.
[18:36:29]
<T> > <@rico416:matrix.org> something's broken with pydio now. after reinstalling, it broke. after deleting the subdomain and recreating it, then install pydio, it's still broken. agh.
Did you try to restart the server and try again?
[19:26:47]
<nalla22> On dirait que le fichier `/etc/nginx/sites-available/default` n'est pas pris en compte par le serveur nginx, malgré les différentes configurations testées !
[19:26:49]
<nalla22> Est-ce que la configuration TLS doit se faire directement dans les fichiers de configuration nginx des applications yunohost ?
[19:28:52]
<nalla22> Est-ce que ça serait possible d'utiliser des tunnels SSH pour les applications yunohost qui ne disposent pas de chiffrement SSL avec les redirections sur IP LAN ?
[19:29:08]
<nalla22> J'ai lu qu'il était possible de faire des redirections de ports de n'importe quel protocole TCP via des tunnels SSH chiffrés d'une machine à l'autre https://www.malekal.com/comment-configurer-le-tunnel-ssh-redirection-de-port/
[19:31:12]
<Aleks (he/him/il/lui)> sinon y'a aussi moyen d'utiliser redirect_ynh plutôt que de créer des cyberfrankensteins...
[19:33:22]
<nalla22> redirect_ynh fait parti des premières applications que j'ai testé pour résoudre ce problème, mais il ne permet pas de certifier les connexions Lan sur IP des applications pour les faire passer en HTTPS !
[19:34:36]
<Aleks (he/him/il/lui)> oui enfin quel est ton vrai problème ? Apriori de ce qu'on comprends, ton problème c'est d'accéder à ton application, pas de "certifier une connexion LAN sur IP"chépakoi, ça ça ressemble à ta tentative de solution
[19:35:11]
<Aleks (he/him/il/lui)> jusqu'à preuve du contraire, redirect_ynh permet d'exposer "correctement" une app installée à la main si l'app écoute sur 127.0.0.1 + un port donné
[19:37:43]
<nalla22> > <@Alekswag:matrix.org> oui enfin quel est ton vrai problème ? Apriori de ce qu'on comprends, ton problème c'est d'accéder à ton application, pas de "certifier une connexion LAN sur IP"chépakoi, ça ça ressemble à ta tentative de solution
Non, les applications YunoHost j'arrive à y accéder sans problème après les ouverture de ports directement sur ip lan (ex: http://192.168.0.110:8098), le problème réside dans le fait que la connexions à ses applications se fait via le protocole HTTP, donc sans le chiffrement SSL, ce qui pose un problème de sécurité même si c'est principalement pour utilisation sur réseau local !
[19:38:36]
<Aleks (he/him/il/lui)> non, le problème c'est que t'es pas censé exposer le port "privé" d'une app sur le réseau, t'es censé passer par un vrai serveur, au hasard nginx, via son port 443, comme n'importe quelle app
[19:38:51]
<Aleks (he/him/il/lui)> c'est nginx qui est censée gérer la couche SSL, pas l'app
[19:39:30]
<Aleks (he/him/il/lui)> de la même manière que quand tu vas à l'hopital, c'est pas au médecin de gérer la compta
[19:54:36]
<rico416> > <@tsh:envs.net> Did you try to restart the server and try again?
yes, i have. even tried reverting to an earlier checkpoint and that didnt fix it either.
[19:57:45]
<nalla22> Je ne suis pas contre d'utiliser nginx pour appliquer des certificats SSL sur ces applications, mais toutes mes tentatives de configuration du fichier `/etc/nginx/sites-available/default` ont échoués, car on dirait que nginx ne prend pas ce fichier en compte, sûrement dû à une configuration de yunohost sur le serveur nginx...
[19:58:03]
<nalla22> Si vous avez une solution sur comment faire passer ces applications par le protocole HTTPS tout en utilisant le serveur nginx, dans ce cas je serais plus que preneuse !
[20:02:20]
<nalla22> Mais à la condition que les applications passent en https en utilisant l'adresse IP LAN dans ce format `https://192.168.0.110:8098`
[20:07:44]
<nalla22> La solution serait d'exposé les applications avec un nom de domaine publique via yunohost, et de profiter en même temps des avantages des connexions LAN des applications en ouvrant leurs ports localement (sans routage vers l’extérieur). Mais le seul problème que je rencontre est la certification SSL de ces applications pour pouvoir sécuriser leurs communications en local et parer d'éventuelles attaques MITM, ... !
[20:10:44]
<mrflos> > <@nalla22:matrix.org> Mais à la condition que les applications passent en https en utilisant l'adresse IP LAN dans ce format `https://192.168.0.110:8098`
In reply to @nalla22:matrix.org
Mais à la condition que les applications passent en https en utilisant l'adresse IP LAN dans ce format https://192.168.0.110:8098
nalla22: si ta machine yunohost accède a l'internet et a ton réseau LAN, tu pourrais confier la création des certificats ssl et des domaines à yunohost, puis utiliser l'app "redirect" pour dire que mondomaine.fr pointe sur HTTPS://192.168.0.110:8098
[20:11:25]
<mrflos> Yunohost ferait proxy
[20:19:47]
<nalla22> > <@mrfloss:matrix.org> In reply to @nalla22:matrix.org
> Mais à la condition que les applications passent en https en utilisant l'adresse IP LAN dans ce format https://192.168.0.110:8098
>
> nalla22: si ta machine yunohost accède a l'internet et a ton réseau LAN, tu pourrais confier la création des certificats ssl et des domaines à yunohost, puis utiliser l'app "redirect" pour dire que mondomaine.fr pointe sur HTTPS://192.168.0.110:8098
Malheureusement, ça n'a pas l'air de fonctionner, car yunohost pars du principe que l'URL de départ est déjà utilisée https://i.imgur.com/1l50dtr.png
[20:21:06]
<Aleks (he/him/il/lui)> bah du coup oui si y'a une app déjà installée sur la racine du domaine, tu peux pas installer une autre app sur cette même url, forcément ...
[20:21:12]
<nalla22> Les applications yunohost ne peuvent pas prendre deux noms de domaines en même temps, mais elles sont limitées à un seul nom de domaine. Ce qui m'oblige à choisir entre le LAN et le WAN pour n'importe quelle application, car elle ne pourra pas faire les deux en même temps. J'ai besoin d'une connexion LAN à mes applications et j'aurai aussi besoin d'une connexion publique par la suite. Cerise sur le gâteau, il s'avère que les noms de domaine domain.local utilisés par yunohost possèdent de sérieuses limitations qui les empêchent d'être pris en compte par certaines applications comme Deluge, Jellyseerr... Pour faire de l'inter-connexion entre les applications.
[20:22:34]
<nalla22> Je suis d'accord, c'est pour ça que cette solution ne fonctionne pas !
[20:23:32]
<Aleks (he/him/il/lui)> 😐️
[20:23:56]
<Aleks (he/him/il/lui)> sinon tu peux aussi genre ... installer l'app sur un domaine qui n'est pas déjà utilisé par une autre app ...
[20:24:20]
<mrflos> Si tu veux garder qu'un seul domaine et que le principal est pris, il te reste l'option iptable/ufw pour rediriger le port
[20:25:38]
<mrflos> Mais perso, je trouverai cela plus simple de faire plusieurs domaines, enfin plutôt plein de sous domaines
[20:28:48]
<T> > <@rico416:matrix.org> yes, i have. even tried reverting to an earlier checkpoint and that didnt fix it either.
🥴
[20:38:23]
<nalla22> > <@Alekswag:matrix.org> sinon tu peux aussi genre ... installer l'app sur un domaine qui n'est pas déjà utilisé par une autre app ...
J'ai utilisé les 4 redirections de l'application Redirect une à une en faisant attention de supprimer la précédente avant d'installer la nouvelle, et en redémarrant le serveur nginx après chaque installation. Aucune connexion HTTPS sur https://192.168.0.110:8098 n'a été constatée !
[20:40:12]
<nalla22> > <@mrfloss:matrix.org> Si tu veux garder qu'un seul domaine et que le principal est pris, il te reste l'option iptable/ufw pour rediriger le port
J'ai déjà ouvert les ports et les applications sont fonctionnelles en http, ce n'est pas un problème du firewall mais un problème d'application des certificat SSL avec le serveur nginx !
[20:40:41]
<Aleks (he/him/il/lui)> 🤦
[20:41:55]
<Aleks (he/him/il/lui)> 1. Ajoutes un domaine whatever.local
2. Installes l'app redirect sur ce domaine, en sélectionnant le mode proxy_pass, avec comme cible 127.0.0.1:<le port de ton app>
3. Accèdes à https://whatever.local
4. ???
5. profit!
[20:49:08]
<nalla22> > <@Alekswag:matrix.org> 1. Ajoutes un domaine whatever.local
> 2. Installes l'app redirect sur ce domaine, en sélectionnant le mode proxy_pass, avec comme cible 127.0.0.1:<le port de ton app>
> 3. Accèdes à https://whatever.local
> 4. ???
> 5. profit!
Je viens de refaire le teste avec https://127.0.0.1:8089, malheureusement ÇA NE FONCTIONNE PAS. Je ne vais pas te dire que ça fonctionne juste pour te faire plaisir 🤔
[20:49:24]
<nalla22> Je t'invite à effectuer le même teste et tu verras que ça ne fonctionnera pas !
[20:49:32]
<Aleks (he/him/il/lui)> >Accèdes à https://whatever.local
[20:51:39]
<nalla22> C'est le nom de domaine `https://zerobin.local` que j'ai utilisé, voici le résultat après avoir installé l'app de redirection et redémarrer le serveur nginx : https://i.imgur.com/kHTgJqB.png
[20:52:06]
<Aleks (he/him/il/lui)> dans ce cas ça ressemble à un truc où ton app n'écoute pas sur 127.0.0.1 + le port que tu as utilisé ...
[20:53:20]
<nalla22> Pourtant le lien suivant http://192.168.0.110:8098 mène bien à l'application radarr installée par yunohost !
[20:53:55]
<Aleks (he/him/il/lui)> ça c'est avec 192.168.0.x
[20:55:06]
<nalla22> J'ai testé aussi https://192.168.0.110:8098 en mode `proxy_pass` avec l'app redirect, le message de retour est le même !
[20:56:00]
<Aleks (he/him/il/lui)> bah écoute, je sais pas quoi te dire, mais une erreur 502 ça veut dire que nginx n'arrive pas à discuter avec le machin derrière le proxy-pass, donc sans doute qu'il n'écoute pas sur le bon ip+port, donc sans doute que le machin est mal configuré
[20:56:29]
<Aleks (he/him/il/lui)> on ne sait pas comment tu as configuré ton app custom donc on ne peut pas magiquement trouver la solution
[21:08:22]
<mrflos> > <@nalla22:matrix.org> J'ai testé aussi https://192.168.0.110:8098 en mode `proxy_pass` avec l'app redirect, le message de retour est le même !
Sur le terminal de ton serveur yunohost, tu peux tenter de faire des curl https://192.168.0.110:8098 et autres variantes, et tenter d'avoir une réponse, ensuite mettre la même chose dans l'app redirect
[21:11:10]
<nalla22> > <@mrfloss:matrix.org> Sur le terminal de ton serveur yunohost, tu peux tenter de faire des curl https://192.168.0.110:8098 et autres variantes, et tenter d'avoir une réponse, ensuite mettre la même chose dans l'app redirect
Voici les réponses que j'obtiens https://i.imgur.com/XBFEdDs.png
[21:11:50]
<mrflos> Après c'est vrai que normalement si tout est hébergé sur une même machine, l' IP locale 127.0.0.1 devrait répondre, à moins que soucis de firewall ou/et restrictions dans la config de l'App qui fait qqchose avec le port 8098
[21:12:03]
<mrflos> Ah t'as répondu entre temps
[21:12:38]
<mrflos> Essaye en http tout court
[21:14:21]
<nalla22> > <@Alekswag:matrix.org> on ne sait pas comment tu as configuré ton app custom donc on ne peut pas magiquement trouver la solution
Le 127.0.0.1 dans l'application Radarr a été remplacé par 0.0.0.0 pour que l'application soit accessible via `http://192.168.0.110:8098` (avec l'ouverture du port 8098 dans le firewal yunohost). Ce sont les seules modifications qu'il y a eu.
[21:15:10]
<Aleks (he/him/il/lui)> ben du coup essayes donc de remettre 127.0.0.1, reload/restart tout ce qu'il y a à reload/restart, et essayes de nouveau l'app redirect ...
[21:17:44]
<nalla22> > <@mrfloss:matrix.org> Essaye en http tout court
En HTTP tout répond : https://i.imgur.com/kDLGYLK.png
[21:18:54]
<mrflos> Donc mettre la même chose dans redirect et normalement c'est bon
[21:20:38]
<mrflos> Pfou, tout ce temps d'ingénieur.e pour réussir à installer un setup pour télécharger des animes illégalement, c'etait mieux avant avec eMule.. 😝
[21:37:33]
<nalla22> En pointant le nom de domaine .local vers l'application en écoute sur `http://127.0.0.1:8098`, le nom de domaine arrive bien à accéder à l'application, ce qui veut dire qu'il est possible de cette manière d'utiliser un nom de domaine publique + un nom de domaine .local en même temps sur une seule application (même si c'est du bricolage ^^), c'est déjà une bonne chose :)
[21:37:45]
<nalla22> Mais ça n'arange pas mon problème initial qui consiste à utiliser les applications directement sur l'adresse IP LAN avec HTTPS `https://192.168.0.110:8098` à cause des limitations des domaines .local cités plus haut. Donc il faut que je trouve une solution pour ajouter le chiffrement ssl. Je vais tester certbot qui d'après ce que j'ai lu fonctionne bien pour les noms de domaines publiques, mais c'est un enfer à utiliser pour les IP locales !
[21:38:44]
<Aleks (he/him/il/lui)> aucune idée de quelle "limitation des domaines .local" tu parles
[21:39:20]
<nalla22> > <@Alekswag:matrix.org> aucune idée de quelle "limitation des domaines .local" tu parles
il s'avère que les noms de domaine domain.local utilisés par yunohost possèdent de sérieuses limitations qui les empêchent d'être pris en compte par certaines applications comme Deluge, Jellyseerr... Pour faire de l'inter-connexion entre les applications.
[21:39:43]
<Aleks (he/him/il/lui)> et donc, quelles sont ces mystérieuses "sérieuses limitations"
[21:45:17]
<mrflos> > <@nalla22:matrix.org> Mais ça n'arange pas mon problème initial qui consiste à utiliser les applications directement sur l'adresse IP LAN avec HTTPS `https://192.168.0.110:8098` à cause des limitations des domaines .local cités plus haut. Donc il faut que je trouve une solution pour ajouter le chiffrement ssl. Je vais tester certbot qui d'après ce que j'ai lu fonctionne bien pour les noms de domaines publiques, mais c'est un enfer à utiliser pour les IP locales !
Sinon prendre un sous domaine noho.st ou je ne sais plus quel domaines proposent du dyndns gratuit
[21:46:38]
<mrflos> Mettre du https sur des réseaux locaux, ça sert pas forcément à grand chose, vaut mieux laisser le proxy faire la gestion de la connexion sécurisée
[21:47:11]
<mrflos> Yunohost gère super bien les certificats avec letsencrypt
[21:47:34]
<nalla22> > <@Alekswag:matrix.org> et donc, quelles sont ces mystérieuses "sérieuses limitations"
Pas si mystérieuses que ça, et j'en ai déjà parlé à plusieurs reprises. Les clients ne sont pas fans des noms de domaines locaux de yunohost. Jellyfin MPV Shime n'accepte pas l'utilisation du nom de domaine Jellyfin.local, la résolution ne se fait pas car ils ne pointe pas vers l'adresse IP LAN du serveur cible. Jellyseerr n'arrive pas non plus à résoudre les domaines .local de radarr.local sonarr.local et jellyfin.local, il lui faut des adresses IP pour fonctionner ou des noms de domaines publiques. Pareil pour le think client Deluge qui reconnaît seulement l'IP du serveur.
[21:47:48]
<nalla22> Toutes les applications que j'ai utilisées ont des problèmes avec la résolution des domaines .local de yunohost, vous pouvez faire vous même les tests pour vous en rendre compte !
[21:49:38]
<Aleks (he/him/il/lui)> bah si t'es capable de nous dire c'est quoi la spécificité des "noms de domaines locaux de yunohost" qui fait que ça marcherait avec des "locaux pas-yunohost",, on est preneur
[21:50:01]
<Aleks (he/him/il/lui)> m'enfin l'explication c'est sans doute que la résolution de .local, yunohost ou pas, ça nécessite de supporter le bonjour-protocol
[21:50:18]
<mrflos> Ben ya possibilité de passer sur un vrai nom de domaine si.local c'est pas possible
[21:50:38]
<nalla22> > <@mrfloss:matrix.org> Mettre du https sur des réseaux locaux, ça sert pas forcément à grand chose, vaut mieux laisser le proxy faire la gestion de la connexion sécurisée
C'est très utile pour ne pas être dépendants des connexions externes, et être autosuffisant en cas de coupure de réseau. C'est le principe même d'un serveur privé NAS !
[21:50:39]
<Aleks (he/him/il/lui)> bref, comme dit mrflos, le problème c'est surtout d'essayer de s'enteter à faire des trucs chelou avec des machins en réseau local plutot que d'utiliser des vrais nom de domaine
[21:50:57]
<Aleks (he/him/il/lui)> oui bah du coup go demander aux développeurs des apps upstream de supporter les domaines en .local quoi
[21:51:40]
<nalla22> > <@Alekswag:matrix.org> bah si t'es capable de nous dire c'est quoi la spécificité des "noms de domaines locaux de yunohost" qui fait que ça marcherait avec des "locaux pas-yunohost",, on est preneur
Quelque soit l'origine du problème concernant les noms de domaine .local. Le constat reste le même, les clients ne l'acceptent pas !
[21:52:41]
<Aleks (he/him/il/lui)> le constat c'est surtout qu'on est en train de parler de tout un setup turbo-avancé pour une situation hypothétique future où t'aurais une coupure de réseau de plus d'une heure ...
[21:53:38]
<Aleks (he/him/il/lui)> sachant que y'a aussi moyen de mettre le nom de domaine en dur mappé vers 127.0.0.1 dans ton /etc/hosts, .local ou pas, et ça marcherait sans doute très bien meme avec une coupure de réseau
[21:55:33]
<nalla22> J'ai dit celà juste pour répondre à la question, mais si les noms de domaines locaux fonctionnaient avec les clients et les autres applications yunohost, alors je ne chercherais pas à utiliser les applications via l'adresse IP local du serveur. C'est aussi simple que ça !
[21:57:32]
<mrflos> C'est pas un problème de mettre un nom de domaine de ton choix, et de s'arranger pour qu'il marche même qu'en lan si ya coupure internet
[21:58:09]
<mrflos> S'il n'aime pas les .local , prends autre chose
[21:59:38]
<mrflos> Et sur tes machines locales indique dans les /etc/hosts que mondomaine.ext pointe sur l'ip locale
[22:04:50]
<Aleks (he/him/il/lui)> 😐️
[22:04:55]
<nalla22> Pourtant quand je fais un ping sur mes autres machine en utilisant un domaine comme celui-ci `radarr.local`, l'adresse IP du serveur ressort bien, mais je suppose que les clients s'attendent à avoir également le port de l'application. Les autres nom de domaine locaux habituelles ressemble plutôt à ceci `domain.local:8098`, alors qu'avec yunohost les ports ne sont pas utilisés sur les noms de domaine. Le problème vient surement de là !
[22:05:03]
<nalla22> Pourtant quand je fais un ping sur mes autres machine en utilisant un domaine comme celui-ci `radarr.local`, l'adresse IP du serveur ressort bien, mais je suppose que les clients s'attendent à avoir également le port de l'application. Les autres nom de domaine locaux habituelles ressemblent plutôt à ceci `domain.local:8098`, alors qu'avec yunohost les ports ne sont pas utilisés sur les noms de domaine. Le problème vient surement de là !
[22:05:56]
<nalla22> Pourtant quand je fais un ping sur mes autres machines en utilisant un domaine comme celui-ci `radarr.local`, l'adresse IP du serveur ressort bien, mais je suppose que les clients s'attendent à avoir également le port de l'application. Les autres noms de domaines locaux habituelles ressemblent plutôt à ceci `domain.local:8098`, alors qu'avec yunohost les ports ne sont pas utilisés sur les noms de domaine. Le problème vient surement de là !
[22:07:36]
<nalla22> Pourtant quand je fais un ping sur mes autres machines en utilisant un domaine comme celui-ci `radarr.local`, l'adresse IP du serveur ressort bien, mais je suppose que les clients s'attendent à avoir également le port de l'application. Les autres noms de domaines locaux habituelles ressemblent plutôt à ceci `domain.local:8098`, alors qu'avec yunohost les ports ne sont pas utilisés sur les noms de domaine locaux. Le problème vient surement de là !
[22:10:37]
<mrflos> En fait sur le réseau local, les .local peuvent être découverts grâce à un protocole qui s'appelle bonjour mais qui pose problème dès que tu veux accéder depuis le web
[22:11:58]
<mrflos> Pour que cela fonctionne, tu passes par des DNS,des noms de domaines et tu securises avec des certificats ssl pour faire du https
[22:13:26]
<mrflos> Pour les ports dans les applications, tu peux ouvrir le firewall et laisser les applications gérer ou bien, et c'est plus élégant, faire des redirections proxy
[22:15:00]
<mrflos> Si tu passes par redirect, yunohost s'occupe de renvoyer entre le port 443 HTTPS et le port que tu choisis pour ton app
[22:15:57]
<mrflos> En faisant comme ça ça marche depuis l'extérieur et en local quand internet marche
[22:19:16]
<mrflos> Et si pas de connexion depuis l'extérieur, en bidouillant la configuration /etc/Host de tes machines, tu court-circuites les DNS et ton nom de domaine continue à fonctionner localement
[22:26:30]
<nalla22> Merci pour les informations, mais je compte éviter au maximum l'utilisation de noms de domaines publiques.
[22:26:38]
<nalla22> J'espère qu'un jour yunohost pourra gérer nativement les redirections des applications sur l'IP du serveur avec activation du HTTPS et sans utilisation de nom de domaine (comme le fais déjà Unraid, TrueNAS, DiskStation... et pleins d'autres gestionnaires d'applications qui ne sont pas forcément moins sécurisés que yunohost)
[22:28:54]
<Aleks (he/him/il/lui)> oui enfin là c'est pas un problème technique, c'est du dogmatisme : on t'as donné une solution pour résoudre ton problème, il s'agit d'utiliser un vrai nom de domaine, mais de mapper ce domaine vers 127.0.0.1 (ou l'IP locale appropriée si c'est sur une autre machine) dans le /etc/hosts, ce qui techniquement est équivalent à avoir un domaine local, aucun trafic ne passe vers l'extérieur ...
[22:34:36]
<@err404:matrix.org> nalla22: tu peux peut être regarder comment font Unraid, TrueNAS, DiskStation... et appliquer leur methode (il se peut que ça soit faisable facilement via des commandes shell ou en éditant des fichiers de config)
[22:36:39]
<@err404:matrix.org> j'ai chez moi un unbound, pour gérer des noms de domaine de machines locales (VM ou machines physiques, et des Yunohost aussi), ça me permet d'utiliser des noms comme dans /etc/hosts mais de façon centralisée et utilisable par tous les ordis de mon réseau local
[22:41:39]
<nalla22> > <@Alekswag:matrix.org> oui enfin là c'est pas un problème technique, c'est du dogmatisme : on t'as donné une solution pour résoudre ton problème, il s'agit d'utiliser un vrai nom de domaine, mais de mapper ce domaine vers 127.0.0.1 (ou l'IP locale appropriée si c'est sur une autre machine) dans le /etc/hosts, ce qui techniquement est équivalent à avoir un domaine local, aucun trafic ne passe vers l'extérieur ...
C'est une limitation technique, par conséquent ça peut être considéré comme un problème technique. J'ai utilisé beaucoup de gestionnaires d'applications WEB, et malheureusement yunohost est le seul gestionnaire d'applications WEB qui ne fait pas de redirection des applications sur l'IP du serveur nativement, ce qui a tendance à poser certaines limites d'utilisation !
[22:41:45]
<nalla22> Mais heureusement que yunohost a d'autres avantages comme la facilité d'installation des applications par exemple !
[22:43:27]
<nalla22> Exactement, c'est pour cette raison que je bricole yunohost afin de répondre à mes besoins 😉
[22:44:18]
<Aleks (he/him/il/lui)> non, il n'y a pas de limitation technique : on t'as expliqué quoi faire comme configuration pour résoudre ton problème, libre à toi de le faire ou non, mais pas la peine d'essayer de vendre le truc de "y'a une limitation technique", faire du HTTPS sur une IP avec un certif auto-signé **en plus** de l'exposer sur un vrai domaine n'a pas de sens quand tu peux simplement l'exposer sur le vrai domaine avec un vrai certif lets encrypt tout en mappant le domaine vers l'IP locale via ton /etc/hosts
[22:45:29]
<@err404:matrix.org> il y a beaucoup de choses que yunohost ne fait pas mais qui sont faisable "à la main"
[22:51:31]
<nalla22> Non, ça ne résous pas le problème principal, mais je remercie mrflos pour son aide, ça m'a aidé à comprendre mieux le fonctionnement de certains mécanismes, notamment au niveau de la redirection DNS en se servant de l'app Redirect de yunohost.
[22:51:33]
<nalla22> Pour ce qui est de la redirection des applications sur l'IP du serveur avec certificats autosignés, tous les autres gestionnaires d'application web le font, il faudrat sûrement leur expliquer que ce qu'ils font ne sert à rien ! ^^
[22:54:04]
<nalla22> C'était de l'ironie ^^ je fonce me battre avec certbot et les certificats autosignés sur yunohost !
[23:06:48]
<nalla22> Je voulais vérifier si Let's encrypt était utilisé sur les domain.local. Apparemment il s'agit seulement de certificats autosignés https://i.imgur.com/HLPS3mS.png
[23:06:57]
<nalla22> Est-ce que ceci veut dire qu'il sera possible d'installer des applications hors ligne, dans le cas où des miroirs des dépôts app,debian,npm.... sont déjà présents localement, sans que yunohost cherche à consulter une autorité de certification SSL externe pour l'installation de l'application ?
[23:09:45]
<lapineige> > <@nalla22:matrix.org> Merci pour les informations, mais je compte éviter au maximum l'utilisation de noms de domaines publiques.
En fait dans l'histoire je ne comprends pas ce choix qui limite fortement les possibilités.
D'autant qu'en utilisant le fichier host, ça n'a même pas besoin d'être des vrais domaines publiques vu que tout peut être redirigé en local.
[23:15:05]
<Aleks (he/him/il/lui)> > <@nalla22:matrix.org> Est-ce que ceci veut dire qu'il sera possible d'installer des applications hors ligne, dans le cas où des miroirs des dépôts app,debian,npm.... sont déjà présents localement, sans que yunohost cherche à consulter une autorité de certification SSL externe pour l'installation de l'application ?
tu veux des miroirs locaux hors-ligne de debian, npm et tous les autres gestionnaires de paquet hypés ? Ça nécessitera sans doute un projet de recherche sur 3 ans, et aussi une bonne cinquantaine de tera-octets pour chaque personne qui veut effectivement faire ça. Et d'ailleurs, ça n'a aucun rapport avec une quelconque histoire de certif auto-signé ou pas ...
[23:16:41]
<Aleks (he/him/il/lui)> on devrait sérieusement réfléchir à créer un salon genre support-advanced pour rediriger tous les gens qui veulent discuter des trucs complètement out-of-scope ~_~
[23:21:13]
<nalla22> J'imagine qu'il n'y aura pas besoin d'autres miroires supplémentaires pour faire fonctionner yunohost en hors ligne, à moins que d'autres dépôts soient également de la partie !
[23:21:30]
<nalla22> Je me suis déjà renseignée sur ça bien avant de poser ma question https://www.debian.org/mirror/size.fr.html , le dépôt Debian architechture AMD64 pèse seulement 600GB, npm et pip pèsent encore moins et le dépôt yunohost aussi. On est vers les 2TB pour le tout, très loin des 50TB pour le coup
[23:28:33]
<nalla22> > En fait dans l'histoire je ne comprends pas ce choix qui limite fortement les possibilités.
> D'autant qu'en utilisant le fichier host, ça n'a même pas besoin d'être des vrais domaines publiques vu que tout peut être redirigé en local.
Exact, le fichier host peut aider en cas de soucis. Mais je veux particulièrement limiter les requêtes vers un DNS public pour des raisons de sécurité, je préfère que les communications entre les applications en local restent seulement en local sans faire appel à des DNS externes. Ces derniers pourront s'illustrer lors de connexions distantes.
[23:29:20]
<Aleks (he/him/il/lui)> ne pas faire appel à un DNS externe ... hmmm ... si seulement il existait un mécanisme pour faire littéralement exactement ça
[23:35:20]
<barking bandicoot> Last night there was a power outage. Searxng now gives 'Internal error'. I ran diagnostics and many ports are not working. Checking the router I find the ports are still entered there. How do I resolve this?
[23:39:19]
<Aleks (he/him/il/lui)> i guess you can try looking at the logs for searxng, either from Tools > Services > searxng > Share with yunopaste (or read / dig the log yourself)
[23:39:35]
<Aleks (he/him/il/lui)> or maybe `jourtnalctl -u searxng -n 100 --no-pager --no-hostname`