Donc pour moi la définition de l’auto-hébergement est suffisamment large pour englober mon cas d’usage.
En fait, tu élargis la définition de « auto-hébergement » en y ajoutant une grosse dépendance externe discutable. On est un paquet à s’auto-héberger depuis des décennies sans ce type de bidouille.
Après, si c’est cette façon de s’auto-héberger qui s’impose dans les années à venir, tant pis pour le vieux libriste que je suis, je ne me battrais pas ;)
Remplacer Android par autre chose est le but de Pinephone. Si les gens veulent se servir d’Android sans les soucis inhérents de vie privée, effectivement, ils peuvent aller vers /e/ (Murena) ou encore le bon vieux AOSP avec un téléphone supporté.
Ces modèles sont des prototypes. Peut-être qu’un Fairphone aurait-été plus adéquat ? Il semblerait qu’ils soutiennent moralement certains SE ouverts (dérivés d’Android), sans la collecte de données personnelles.
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é.
En fait, tu élargis la définition de « auto-hébergement » en y ajoutant une grosse dépendance externe discutable. On est un paquet à s’auto-héberger depuis des décennies sans ce type de bidouille. Après, si c’est cette façon de s’auto-héberger qui s’impose dans les années à venir, tant pis pour le vieux libriste que je suis, je ne me battrais pas ;)
Remplacer Android par autre chose est le but de Pinephone. Si les gens veulent se servir d’Android sans les soucis inhérents de vie privée, effectivement, ils peuvent aller vers /e/ (Murena) ou encore le bon vieux AOSP avec un téléphone supporté.
Ces modèles sont des prototypes. Peut-être qu’un Fairphone aurait-été plus adéquat ? Il semblerait qu’ils soutiennent moralement certains SE ouverts (dérivés d’Android), sans la collecte de données personnelles.
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é.