Ces smartphones ne sont, pour le moment, que des preuves de concepts : y’a du GNU/Linux qui marche dans un téléphones. Après, on se souvient toutes et tous de FirefoxOS et de Ubuntu Touch. Ça a fait plouf. L’influence de Google ou de Apple dans le monde des applications et des services fait qu’un téléphone sous autre chose que Android ou iOS, ça n’est pas très pertinent pour une personne active, en France, en 2023. J’ai beau avoir ce Pinephone et bidouiller avec, je ne peux pas m’en servir. Je suis malheureusement dépendant d’applications Android.
Je veux bien débattre du vocabulaire et je considère que l’auto hébergement peut couvrir un nombre large de configurations différentes.
J’ai une situation ou j’utilise mes propres ressources matérielles et ma propre connexion réseau pour héberger les services qui m’intéressent, je pense donc pouvoir parler d’auto hébergement sans être trompeur. J’utilise des services externes dont je pourrais me passer, et qui viennent surtout me rajouter du confort et de la sécurité. Mais dans ce cadre, ou s’arrêter ? Je dépend aussi des dépôts apt, de docker hub, de mon FAI, de mon fournisseur d’électricité, etc.
De mon point de vue, utiliser un VPS hébergé chez OVH reste aussi de l’auto-hébergement dans le sens ou je maîtrise mon infrastructure, je ne suis pas lié à un prestataire unique, je suis maître de mes données, etc.
Donc pour moi la définition de l’auto-hébergement est suffisamment large pour englober mon cas d’usage. Après j’entend que d’autres peuvent avoir une perception différente. Je n’ai pas trouvé de définition faisant consensus sur ce sujet, mais je suis peut être passé à côté.
Jme lance ! J’ai un vieux dell optiplex fx160 reconditionné (acheté 50€ en 2017 sur ebay, 3Go de ram, un intel atom a330, un vieux hdd de 500go), debian, apache2, mariadb, sqlite, php & python.
Un site perso avec blog & liste des projets (php/mariadb/vanilla html & css), une instance nextcloud, deux/trois sites django, quelques sites très simples (html/css, voire juste du txt si bcp d’audience vu que j’ai un débit montant ridicule et que si j’envoie trop de données j’ai pu internet à la maison, et un ou deux ptits trucs avec un peu de php derrière mais pas grand chose).
Un uptime ? Il a planté juste tout à l’heure, donc 3h (mais avant on était à plus de 100 jours donc ça va). C’est pas grave si le site n’est pas accessible de temps en temps. Pas d’utilisation de cloudflare ou d’un autre truc externe non plus, ça fait 6 ans que j’autohéberge (environ) et ya jamais eu le besoin d’autre chose que fail2ban (pis bon la plupart du code est custom et aucun bot va aller s’amuser à tenter autre chose que des failles hyperconnues de frameworks dépassés, donc ça va jsuis tranquille).
J’ai 2 noms de domaines chez Gandi, j’utilise leurs zones DNS aussi avec leur api et des appels de temps en temps depuis mon serveur pour màj l’ip quand elle change.
On peut trouver un nom pour cette configuration mais utiliser « auto-hébergement » est trompeur. Ça n’est pas « puriste » de le dire, c’est juste une façon de faire. Passer par des outils tiers n’est pas de l’auto-hébergement.
Le vocabulaire n’est pas bon et c’est un peu malheureux.
Je te rejoins sur le fond, dans une approche ‘puriste’, mais je dois dire que s’ils sont des colosses c’est que justement ils fournissent un service qui a de la valeur.
Les fonctionnalités que j’utilise chez Google et Cloudflare sont sur l’aspect sécurité. Et je pense qu’on peut se rejoindre sur un point, c’est que la sécurité sur internet, c’est difficile. Pour des projets personnels sans grande importance, le risque principal en faisant de l’auto hébergement c’est d’ouvrir une porte à un acteur mal intentionné qui viendrait faire des dégâts sur mon réseau local, sur mon poste professionnel, etc. Dans ce contexte, j’utilise des services qui me permettent de gagner du temps et de la sérénité pour un coût nul.
Google, je pourrais faire autrement, je l’utilise car ça m’évite de demander à ma femme de se créer un autre compte dont elle oublierait le mot de passe.
Cloudflare, à aujourd’hui je ne connais pas d’alternative qui m’apporte la même sécurité et les mêmes services, mais je suis à l’écoute d’idées différentes !
Ça m’attriste toujours de voir de l’autohébergement mais que derrière ça utilise Google pour de l’auth et Cloudflare comme CDN/proxy…
Mon but dans l’auto-hébergement c’est de sortir un peu des sentiers battus et donc de ne pas dépendre de ces deux colosses qui sont déjà partout sur le web.
Tu as tout à fait raison et c’est pour ça que j’inclue la télémétrie : parce qu’on ne peut pas se porter garant des hypothétiques bonnes intentions des tiers.
Pour quel usage ? Ces appareils ont un prix élevé (smartphones). Cela vaut-il vraiment le coût ? Prendre des photos, des vidéos, passer des appels téléphoniques… Je ne dénigre pas ces technologies mais on peut se demander si c’est vraiment adapté : le fait que cela soit courant ne rend pas les choses pertinentes.
Les outils de télémétrie ne sont pas forcément le mal incarné et contre les utilisateurs.
S’ils restent anonymes et a usage de l’entreprise qui développent le logiciel, ils peuvent être utilisés pour comprendre le comportement des utilisateurs en
supprimant les fonctionnalités non utilisés (et améliorer la stabilité et la performance de l’application)
améliorer l’ux de l’application.
comprendre quelles fonctionnalités sont à optimiser (les plus longues et les plus utilisés)
Le problème des outils de télémétrie et d’analytics, sont souvent qu’ils ne sont pas anonyme, ou fournis par des tiers qui en profite pour eux même.
Absolument, et celui depuis quelques années maintenant…
Tu comprends mieux ma “surprise” et mes questions ;)
Dans les faits, c’était “expérimental” début 2018 et vers la fin de ladite année est devenu “supportée”.
Voilà !
Même si je ne l’ai pas exprimé, j’avoue avoir eu du mal avec ton commentaire précédent, puisqu’unbound est capable de communiquer en DoT, depuis l’année précisée ci-dessus. Il suffit de “pointer” vers des serveurs DNS gérant ce protocole. Bien-sûr, il gère aussi très bien les requêtes selon le chiffrement DNSSEC, et le fait même avec les serveurs DNS roots, sans aucun soucis.
J’utilise unbound pour la simple raison que le service est intégré nativement sous Open… BSD, depuis des années - c’est même là que je l’ai découvert ; quand je me suis mis à Open… WRT, j’ai cherché à l’utiliser logiquement.
Pour tout avouer, j’ai même intégré le proxy DoH dans OpenWRT ; qui me semble très bien fait, et qui intègre la possibilité de divers listes de filtrage, dont la plupart des serveurs DNS supportant DoH, supportent aussi DoT, voire se mettent même à faire du Quic-over-DNS.
(d’où le partage de la liste dans mon article)
Ainsi, sans grande modification, j’ai dans mon OpenWRT, dnsmasq le chef d’orchestre qui forward en premier à unbound les requêtes DNS sur DoT - depuis mes deux sous-réseaux, Lan et Wifi -, et si pour une raison ou un autre, il bascule sur le proxy DoH, qui envoie/enverra les requêtes DNS vers plusieurs serveurs différents, sur les deux couches IPv(4|6).
(“ceinture et bretelles”)
Oui il fait du DoT et DoH mais pas au même endroit, en gros tu te retrouves avec ça :
Serveurs roots + la récursion < – DNS en clair – > (X)|Unbound < – DNS / DoH / DoT – > clients
et avec blocky tu as
Serveurs roots + la récursion < – DNS en clair – > Résolveurs upstreams < – DNS / DoH / DoT – > (X)|Blocky < – DNS – > clients
Du coup au niveau de ton routeur (X), le trafic vu avec unbound sera du DNS en clair, alors qu’avec blocky ça sera du DNS/DoT/DoH donc potentiellement chiffré.
Unbound est un “vrai” résolveur DNS.
Son boulot est d’aller interroger les serveurs roots puis de faire la récursion.
Il peut également faire du blocage bien que ce ne soit pas dans ses fonctionnalités initiales.
Blocky lui n’est pas un vrai résolveur, il va par contre consulter des résolveurs (de ce fait je le qualifie de proxy). Par contre lui est vraiment taillé pour le blocage, du coup il sait charger des blocklist mais surtout il sait les mettre à jour de lui-même et régulièrement.
Et il a pour gros avantage de pouvoir parler à plusieurs serveurs récursifs simultannément et ce via les nouveaux protocoles que sont DoT et DoH qui permettent de chiffrer la communication entre le résolveur et lui.
Du coup d’un point de vue extérieur les deux logiciels font sensiblement la même chose, mais sous le capot ça ne marche pas pareil.
Les deux ont leurs avantages.
Unbound permet de directement parler aux roots ainsi qu’au serveurs faisant autorité c’est donc un fonctionnement plus décentralisé. L’inconvénient c’est que du coup le trafic est en clair.
À contrario, blocky fait appels à des résolveurs extérieurs et donc plus centralisés (tout en permettant d’en utiliser de multiples et donc éviter de trop cette centralisation) mais avec du chiffrement.
Yep ^^
Tcho !
Ces smartphones ne sont, pour le moment, que des preuves de concepts : y’a du GNU/Linux qui marche dans un téléphones. Après, on se souvient toutes et tous de FirefoxOS et de Ubuntu Touch. Ça a fait plouf. L’influence de Google ou de Apple dans le monde des applications et des services fait qu’un téléphone sous autre chose que Android ou iOS, ça n’est pas très pertinent pour une personne active, en France, en 2023. J’ai beau avoir ce Pinephone et bidouiller avec, je ne peux pas m’en servir. Je suis malheureusement dépendant d’applications Android.
Je veux bien débattre du vocabulaire et je considère que l’auto hébergement peut couvrir un nombre large de configurations différentes.
J’ai une situation ou j’utilise mes propres ressources matérielles et ma propre connexion réseau pour héberger les services qui m’intéressent, je pense donc pouvoir parler d’auto hébergement sans être trompeur. J’utilise des services externes dont je pourrais me passer, et qui viennent surtout me rajouter du confort et de la sécurité. Mais dans ce cadre, ou s’arrêter ? Je dépend aussi des dépôts apt, de docker hub, de mon FAI, de mon fournisseur d’électricité, etc.
De mon point de vue, utiliser un VPS hébergé chez OVH reste aussi de l’auto-hébergement dans le sens ou je maîtrise mon infrastructure, je ne suis pas lié à un prestataire unique, je suis maître de mes données, etc.
Donc pour moi la définition de l’auto-hébergement est suffisamment large pour englober mon cas d’usage. Après j’entend que d’autres peuvent avoir une perception différente. Je n’ai pas trouvé de définition faisant consensus sur ce sujet, mais je suis peut être passé à côté.
Ca devrait être réparé !
Je vois pas le schéma dans Synthèse.
Tcho !
Jme lance ! J’ai un vieux dell optiplex fx160 reconditionné (acheté 50€ en 2017 sur ebay, 3Go de ram, un intel atom a330, un vieux hdd de 500go), debian, apache2, mariadb, sqlite, php & python.
Un site perso avec blog & liste des projets (php/mariadb/vanilla html & css), une instance nextcloud, deux/trois sites django, quelques sites très simples (html/css, voire juste du txt si bcp d’audience vu que j’ai un débit montant ridicule et que si j’envoie trop de données j’ai pu internet à la maison, et un ou deux ptits trucs avec un peu de php derrière mais pas grand chose).
Un uptime ? Il a planté juste tout à l’heure, donc 3h (mais avant on était à plus de 100 jours donc ça va). C’est pas grave si le site n’est pas accessible de temps en temps. Pas d’utilisation de cloudflare ou d’un autre truc externe non plus, ça fait 6 ans que j’autohéberge (environ) et ya jamais eu le besoin d’autre chose que fail2ban (pis bon la plupart du code est custom et aucun bot va aller s’amuser à tenter autre chose que des failles hyperconnues de frameworks dépassés, donc ça va jsuis tranquille).
J’ai 2 noms de domaines chez Gandi, j’utilise leurs zones DNS aussi avec leur api et des appels de temps en temps depuis mon serveur pour màj l’ip quand elle change.
On peut trouver un nom pour cette configuration mais utiliser « auto-hébergement » est trompeur. Ça n’est pas « puriste » de le dire, c’est juste une façon de faire. Passer par des outils tiers n’est pas de l’auto-hébergement. Le vocabulaire n’est pas bon et c’est un peu malheureux.
Je te rejoins sur le fond, dans une approche ‘puriste’, mais je dois dire que s’ils sont des colosses c’est que justement ils fournissent un service qui a de la valeur. Les fonctionnalités que j’utilise chez Google et Cloudflare sont sur l’aspect sécurité. Et je pense qu’on peut se rejoindre sur un point, c’est que la sécurité sur internet, c’est difficile. Pour des projets personnels sans grande importance, le risque principal en faisant de l’auto hébergement c’est d’ouvrir une porte à un acteur mal intentionné qui viendrait faire des dégâts sur mon réseau local, sur mon poste professionnel, etc. Dans ce contexte, j’utilise des services qui me permettent de gagner du temps et de la sérénité pour un coût nul. Google, je pourrais faire autrement, je l’utilise car ça m’évite de demander à ma femme de se créer un autre compte dont elle oublierait le mot de passe. Cloudflare, à aujourd’hui je ne connais pas d’alternative qui m’apporte la même sécurité et les mêmes services, mais je suis à l’écoute d’idées différentes !
Si vous aussi vous auto hébergez, partagez ici vos stacks et vos préférences !
Ça m’attriste toujours de voir de l’autohébergement mais que derrière ça utilise Google pour de l’auth et Cloudflare comme CDN/proxy… Mon but dans l’auto-hébergement c’est de sortir un peu des sentiers battus et donc de ne pas dépendre de ces deux colosses qui sont déjà partout sur le web.
Tu as tout à fait raison et c’est pour ça que j’inclue la télémétrie : parce qu’on ne peut pas se porter garant des hypothétiques bonnes intentions des tiers.
Merci pour ton commentaire !
Pour quel usage ? Ces appareils ont un prix élevé (smartphones). Cela vaut-il vraiment le coût ? Prendre des photos, des vidéos, passer des appels téléphoniques… Je ne dénigre pas ces technologies mais on peut se demander si c’est vraiment adapté : le fait que cela soit courant ne rend pas les choses pertinentes.
Les outils de télémétrie ne sont pas forcément le mal incarné et contre les utilisateurs.
S’ils restent anonymes et a usage de l’entreprise qui développent le logiciel, ils peuvent être utilisés pour comprendre le comportement des utilisateurs en
Le problème des outils de télémétrie et d’analytics, sont souvent qu’ils ne sont pas anonyme, ou fournis par des tiers qui en profite pour eux même.
Pour le reste je trouve l’idée intéressante.
Honnêtement au début j’ai cru que c’était un hommage au sketch du bon chasseur des inconnus….. :D
Absolument, et celui depuis quelques années maintenant… Tu comprends mieux ma “surprise” et mes questions ;)
Dans les faits, c’était “expérimental” début 2018 et vers la fin de ladite année est devenu “supportée”. Voilà !
Même si je ne l’ai pas exprimé, j’avoue avoir eu du mal avec ton commentaire précédent, puisqu’unbound est capable de communiquer en DoT, depuis l’année précisée ci-dessus. Il suffit de “pointer” vers des serveurs DNS gérant ce protocole. Bien-sûr, il gère aussi très bien les requêtes selon le chiffrement DNSSEC, et le fait même avec les serveurs DNS roots, sans aucun soucis.
J’utilise unbound pour la simple raison que le service est intégré nativement sous Open… BSD, depuis des années - c’est même là que je l’ai découvert ; quand je me suis mis à Open… WRT, j’ai cherché à l’utiliser logiquement.
Pour tout avouer, j’ai même intégré le proxy DoH dans OpenWRT ; qui me semble très bien fait, et qui intègre la possibilité de divers listes de filtrage, dont la plupart des serveurs DNS supportant DoH, supportent aussi DoT, voire se mettent même à faire du Quic-over-DNS. (d’où le partage de la liste dans mon article)
Ainsi, sans grande modification, j’ai dans mon OpenWRT, dnsmasq le chef d’orchestre qui forward en premier à unbound les requêtes DNS sur DoT - depuis mes deux sous-réseaux, Lan et Wifi -, et si pour une raison ou un autre, il bascule sur le proxy DoH, qui envoie/enverra les requêtes DNS vers plusieurs serveurs différents, sur les deux couches IPv(4|6). (“ceinture et bretelles”)
Voilà ! :D (tu sais tout… ou presque)
Ha bha je viens de voir ton article et je ne savais pas que Unbound pouvais parler à des résolveurs DoT ^__^
Oui il fait du DoT et DoH mais pas au même endroit, en gros tu te retrouves avec ça :
Serveurs roots + la récursion < – DNS en clair – > (X)|Unbound < – DNS / DoH / DoT – > clients
et avec blocky tu as
Serveurs roots + la récursion < – DNS en clair – > Résolveurs upstreams < – DNS / DoH / DoT – > (X)|Blocky < – DNS – > clients
Du coup au niveau de ton routeur (X), le trafic vu avec unbound sera du DNS en clair, alors qu’avec blocky ça sera du DNS/DoT/DoH donc potentiellement chiffré.
unbound fait du DoT assurément, et même du DoH. ;)
Concernant les métriques, il semble possible de les envoyer au couple Prometheus/Grafana, aussi.
À-propos des listes de blocages, il est vrai qu’il faut mettre en place un script/système de màj par ses petites mimines, et redémarrer le service.
Unbound est un “vrai” résolveur DNS. Son boulot est d’aller interroger les serveurs roots puis de faire la récursion. Il peut également faire du blocage bien que ce ne soit pas dans ses fonctionnalités initiales.
Blocky lui n’est pas un vrai résolveur, il va par contre consulter des résolveurs (de ce fait je le qualifie de proxy). Par contre lui est vraiment taillé pour le blocage, du coup il sait charger des blocklist mais surtout il sait les mettre à jour de lui-même et régulièrement. Et il a pour gros avantage de pouvoir parler à plusieurs serveurs récursifs simultannément et ce via les nouveaux protocoles que sont DoT et DoH qui permettent de chiffrer la communication entre le résolveur et lui.
Du coup d’un point de vue extérieur les deux logiciels font sensiblement la même chose, mais sous le capot ça ne marche pas pareil.
Les deux ont leurs avantages.
Unbound permet de directement parler aux roots ainsi qu’au serveurs faisant autorité c’est donc un fonctionnement plus décentralisé. L’inconvénient c’est que du coup le trafic est en clair.
À contrario, blocky fait appels à des résolveurs extérieurs et donc plus centralisés (tout en permettant d’en utiliser de multiples et donc éviter de trop cette centralisation) mais avec du chiffrement.
IO
Blocky me semble être une alternative à Unbound, qui est hautement “paramétrable” aussi, non ?!