Sujets-libres.fr

Informatique, logiciels libres, internet, humeurs et… le reste !

L'auto-hébergement garde-t-il du sens si le plus important n'y est pas ?

Rédigé par -Fred- 13 commentaires

Récemment, Genma a publié un article au sujet de l'impact de diverses coupures électriques sur son activité auto-hébergée : Coupure-de-courant-et-auto-hebergement. Diverses idées sont développées dans ce billet mais celle qui a retenu mon attention est la suivante : L'auto-hébergement c'est bien mais il ne faut pas le faire pour les services sensibles et desquels on est fortement dépendant. J'ai bien entendu laissé un commentaire sur son blog mais je trouvais justifié de développer un peu plus mon point de vue ici.

En gros, le blog et le mail seraient à ne pas héberger derrière une ligne ADSL car on ne peut se permettre soit un blog inaccessible, soit la non réception de ses mails. On a chacun des priorités variables mais je conçois aussi que ces deux usages soient importants. Dans le cas des coupures électriques à répétition il est évident que ça perturbe fortement l'activité de ces services et que si c'est prolongé, ça fini par causer des pertes définitives de données. Typiquement, vous commencez à perdre des messages si votre serveur mail n'est pas en mesure de les réceptionner pendant plusieurs jours d'affilée et dans la mesure du possible, il est préférable d'éviter ça. A l'inverse les divers services moins importants peuvent être auto-hébergés.

J'ai en fait une approche diamétralement opposée et forcement, j'en arrive à préconiser à peu près l'inverse. J'ai décidé de m'auto-héberger, non pas pour tester des services mais parce que j'ai éprouvé le besoin de reprendre le contrôle de mes données personnelles, notamment le mail. J'ai alors décidé de m'auto-héberger. Forcement de mon point de vue, l'auto-hébergement perd fortement de son sens si on décide de ne pas y stocker les données que l'on a de plus précieuses.

Alors oui, le faire soit même présente des risques car on a rien sans rien. Il faut cependant se donner les moyens de ses ambitions. Dans des billets de blog divers et variés, je vois que certains peuvent utiliser des machines peu fiables pour faire de l'auto-hébergement (typiquement des Raspberry Pi avec un système sur carte SD). Sur le principe bon, pourquoi pas, c'est amusant et très formateur. Le côté Geek en plus, c'est cool aussi.

Pourtant quand on se lance là dedans pour vraiment rapatrier ses données personnelles, le jeu doit être pensé sérieusement dès le départ. Grossièrement, il faut déjà penser à se faire son analyse de risques puis identifier ceux qui sont les plus impactants et corriger ce qui doit vraiment l'être par des actions les plus efficientes possible. Et comme on pense à l'avenir, et bien on planifie ce qui n'aura pas pu être mené immédiatement tout en prévoyant des mesures palliatives si d'aventure le pire devait arriver.

Dans le cas de multiples coupures électriques de quelques heures il est assez simple d'évaluer l'impact que ça peut avoir sur ses services auto-hébergé. On peut alors apprécier les risques encourus : perdre des visiteurs de blog ? voir ses mails arriver avec 1 jour de retard ? Perdre carrément des mails ? Risquer de la casse matérielle ? Perte définitive des données stockées ? Risque très probable d'avoir d'autres priorités que les services auto-hébergés à gérer lorsque la coupure survient ? Tout ça est prévisible et si on pense son auto-hébergement sérieusement on peut immédiatement éliminer certains risques, atténuer les effets encourus par d'autres risques et dans tout les cas avoir une meilleure vue sur l'ensemble des risques résiduels. Le tout encore une fois, c'est de penser ce jeu de manière sérieuse car le risque, ça se gère.

Je pense que différentes motivations poussent à s'auto-héberger. Je me garderai bien d'être catégorique sur ce qu'il convient ou non de faire. La seule chose sur laquelle il faut à mon sens être clair quand on parle d'auto-hébergement, ce sont justement les motivations qui conduisent à s'y essayer. Ça aide à mettre en perspective les propos des uns et des autres et à les replacer dans le bon contexte. Les propos de Genma sont tout à fait pertinent dans son contexte et, à mesure que j'y réfléchi, pas du tout dans le mien.

L'abus de requêtes inter-domaines

Rédigé par -Fred- Aucun commentaire

S'il y a un truc qui me pose problème quand je navigue sur le web, c'est bien les requêtes inter-domaines. Prenez un site quelconque, et regardez la liste des domaines hébergeant les ressources nécessaires à l'affichage d'une page. On peut s'amuser à les compter si on veut (un petit "tcpdump port 53" par exemple est assez instructif). A titre indicatif, se connecter sur www.lemonde.fr nécessite d'effectuer plusieurs dizaines de requêtes DNS, pointant vers presque autant de domaines différents. Histoire de ne pas en accabler un plus qu'un autre, tout en restant dans les journaux en ligne, le constat est identique pour www.mediapart.fr , pour rue89.nouvelobs.com ou pour www.ouest-france.fr.

Sans forcement examiner dans le détail l'ensemble des domaines contactés, dans le lot on voit quand même passer beaucoup de domaines dont on sent bien qu'ils ne sont pas là pour apporter des contenus mais plutôt pour tracer l'activité des visiteurs ou pour afficher de la pub.

J'ai pris l'exemple des journaux en ligne mais bien entendu, ça ne se limite pas à eux (allez voir la page d'accueil de www.marmiton.org pour rigoler). Je constate que c'est plutôt, et de loin, la norme pour les sites un peu gros générant du trafic. Les sites plus confidentiels sont globalement plus propres de ce point de vue. Je me doute bien que les sites en question n'ont pour vocation première de pister leurs visiteurs mais ils font peut être quelque chose de plus grave : globalement ils s'en fichent, tout simplement.

Ce qui est gênant, pour l'internaute que je suis en tout cas, c'est de voir que parmi les sites abusant de ce type de pratiques, on retrouve à peu près toujours les mêmes fournisseurs de services CDN, les mêmes outils d'analyse de trafic, les mêmes régies de pub. Indépendamment c'est sûr rien à signaler car il n'y a pas d'entente à proprement parler entre les gestionnaires des sites en question mais à grande échelle, ils font tous les mêmes choix et créent ainsi, sans vraiment s'en rendre compte, de la centralisation.

Quand on met en place un outil sur son site, on se doit de prendre en compte tout les aspects de l'outil en question. Les gestionnaires de ces sites sont peut être entre l'enclume et le marteau car ils doivent composer avec des contraintes économiques et probablement tout un tas d'autres choses. Pour autant, ils sont les premiers responsables du pistage des internautes car ce sont eux, chacun dans leur coin mais quand même tous ensemble finalement, qui placent la majeure partie des sondes pour le compte des gros silos de données.

C'est principalement pour cette raison que j'utilise le plugin request policy dans firefox. Ça ne résoud pas tout, loin de là mais ça permet de faire un peu le ménage. A l'usage, je dois quand même régulièrement autoriser l'accès à tel ou tel CDN pour voir les contenus sur tel ou tel site. En de rares occasions, je constate même que pour accéder aux contenus de certains sites il faut autoriser l'accès à un grand nombre de domaines depuis tel autre domaine, ce qui est déplaisant car j'ai parfois l'impression que ça ne s'arrête pas.

Limites des réseaux sociaux

Rédigé par -Fred- Aucun commentaire

Les réseaux sociaux tels qu'on les connaît aujourd'hui ont vraiment modifié la manière de communiquer sur Internet. On pourrait aller jusqu'à dire qu'il y a un avant et un après. A une époque pas si lointaine encore, si l'on voulait communiquer sur Internet (et le web en particulier), on se construisait son propre site et on pouvait ensuite l'alimenter. Chaque site était différent et potentiellement géré par des acteurs différents eux aussi. Cette manière de faire fonctionne même si chacun propose des contenus dans son coin car des liens se tissent entre les pages. C'est à mon sens quelque chose de très important en fait car le système n'est pas centralisé.

Ils (les réseaux sociaux) fonctionnent sur le web mais pour autant, leur fonctionnement est un peu différent. Il faut les voir comme une couche intermédiaire entre l'utilisateur et le web. Lorsqu'il modifie sa page ou ajoute du contenu dans son profil de réseau social, l'utilisateur ne poste pas tant sur le web que sur la plateforme du réseau social qui lui est présent sur le web. La nuance est importante car bien que ce soit les utilisateurs qui apportent leur contenus au réseau social, c'est bien le réseau social lui même qui organise ces données ensuite et les met en valeur. Ces quelques sites sont tellement utilisés qu'ils sont à juste titre considérés comme des points de centralisation sur Internet. Si j'osais la comparaison, on pourrait dire qu'on est passé d'une démarche "artisanale" à une démarche "industrielle".

A l'heure où les blogs et autres page perso sont souvent remplacés par des simples pages facebook ou des comptes twitter, l'information y est donc concentrée. Cela va même plus loin car ces réseaux deviennent les canaux de communication principaux de bon nombre de communicants. Du côté de ceux qui recherchent l'information, ces médias deviennent vraiment incontournables et c'est ainsi que l'on rentre dans un cercle vicieux.

Dans leur recherche de confort, d'efficacité et de simplicité d'usage, bon nombre de communicants ont délégué à quelques entreprises la gestion des outils sur lesquels il s'appuient pour communiquer. On le constate vraiment à différents niveaux, depuis l'internaute lambda jusqu'aux politiques en passant par les journalistes. Globalement, ça peut concerner tout ceux ayant à un moment donné besoin de communiquer.

Ces plateformes centralisées posent plusieurs problèmes dont l'un concerne la censure. En fait, même si ce n'est pas leur but, les plateformes de réseaux sociaux doivent être à même de prendre des mesures permettant de retirer des contenus qu'ils hébergent lorsque ces contenus sont signalés comme posant un problème. Les raisons peuvent être multiples, violation de copyright, contenus violents, racistes, terroristes, etc ... Devant la masse d'informations gérées par ces sites, des procédures sont mises en place afin qu'il ne soit pas nécessaire d'engager une armée de modérateurs. Tout le monde peut ainsi remonter au réseau social des contenus inapproprié à faire enlever. Le site en question peut alors agir en écartant les contenus et en suspendant le compte de celui qui les a postés.

Ce qui est grave avec ce système, c'est que le fond n'est pas analysé immédiatement. C'est le ou les signalements qui ont de l'importance car c'est ce qui motive la suppression de contenus ou la suspension de compte (quitte à y revenir ensuite mais le mal est déjà fait). Ce procédé permet, au même titre qu'un DDOS mais en plus simple, de nuire à la capacité de communication d'une personne ou d'un groupe sur Internet. Voilà pourquoi il est important de ne pas dépendre uniquement des réseaux sociaux pour gérer sa communication sur internet. A ceux qui veulent faire passer des informations, prévoyez un site, une mailling list ou tout autre moyen neutre vous permettant de communiquer normalement. Les réseaux sociaux ne devraient être qu'un moyen parmi d'autre de communiquer et si vous en dépendez, vous devriez considérer que cela pose un problème. Accessoirement, amener les discussions à se dérouler via des outils neutres, ça permet à des olibrius dans mon genre de suivre un peu mieux ce qui se passe et se dit en marge des actus et autres billets de blogs.

Malgré cela, même ceux qui ont conscience du problème (les médias notamment) ne peuvent pas grand chose si ceux qui les suivent ne changent pas eux aussi leurs habitudes. Dernièrement, c'est le site Reflets qui a fait les frais d'une suspension abusive de deux comptes twitter (la Fachosphère ayant signalé des contenus inapproprié sur ces comptes ; twitter a réagit, sans autre forme de procès). Ni une ni deux, les administrateurs du site Reflets ont eu la bonne réaction en proposant une mailling list permettant à tout ceux qui le souhaitaient de pouvoir communiquer entre eux. Deux jours plus tard, les comptes twitter ont été réactivés et la mailling list ne vit pas beaucoup (je ne connais pas l'activité des comptes twitter mais ce serait intéressant de comparer, à titre indicatif). Ça me fait dire qu'on a beau avoir conscience des limites du système, on est pas près d'abandonner notre petit confort...

Anticiper les ennuis en auto-hébergement

Rédigé par -Fred- 4 commentaires

Introduction

L'auto-hébergement permet de retrouver un certain contrôle sur ses données et c'est le gros intérêt de la démarche. Mais, l'auto-hébergement implique, et c'est le revers de la médaille, d'assumer seul plusieurs risques supplémentaires. Il est donc utile de se poser quelques questions à un moment.

Précisions

Précision importante, l'auto-hébergement dont je parle ici est typiquement celui mis en œuvre par un particulier dans un cadre privé par exemple. C'est la forme qui m'intéresse là.

Venons en à mon cas

Google, Yahoo!, ou n'importe quel autre fournisseur habituel de mail n'est pas responsable si mon serveur de mail n'est plus accessible ou si mes données sont perdues par exemple. Les ressources physiques sous mon contrôle sont sous ma responsabilité. Cela couvre à la fois les problèmes logiciels et les problèmes matériels qui pourraient intervenir.

Méthode d'analyse

Je ne passe pas vraiment par une méthode particulière mais par simplement un peu de bon sens. L'idée, c'est d'anticiper ce que je peux et d'avoir déjà des réponses à apporter lorsque je me trouverai réellement en situation. Avant de proposer des réponses, il faut se poser les bonnes questions et pour se poser les bonnes questions. Je vais donc procéder comme suit :

  • Identifier le système sur lequel je veux agir.
  • Estimer les impacts des défaillances sur ce système complet.
  • Indiquer ce qui est déjà prévu en cas de défaillance.
  • Identifier les "trous dans la raquette".
  • Identifier les actions à mener afin de combler ces faiblesses.

Vue assez fidèle de mon réseau :

note : pour ce schéma, j'ai utilisé dia et les icônes de Jean Cartier.

Estimation de l'impact des défaillances :

Chaque élément sur ce réseau peut tomber en panne. Que le problème soit d'origine logiciel ou matériel importe peu, la seule chose importante est que l'élément considéré peut ne plus fonctionner à un moment donné. Élément par élément, quels sont donc les impacts d'une panne sur le système entier ? C'est aussi l'occasion d'estimer le niveau de gravité des impacts causés par chaque panne. J'en profite donc pour classifier chaque impact avec un niveau allant de 1 (impact mineur) à 3 (impact majeur). J'ai estimé qu'il était possible de fonctionner avec un effet de niveau 1. Pour les effets de niveau 2, j'ai considéré qu'une gène était visible que ce soit à l'intérieur ou à l'extérieur de mon réseau et qu'il n'était de fait pas possible de fonctionner en l'état. Enfin, les effets de niveau 3 traduisent un risque irréversible de perte de donnée. Voyons voir :

Modem ADSL HS :
  • (2) Plus de connexion à internet possible depuis mon réseau.
  • (2) Serveur auto-hébergé n'est plus visible de l'extérieur.
  • (3) Si la situation se prolonge, risque de perte des nouveaux mails entrant.
  • (1) Téléphonie fixe non fonctionnelle.
Parefeu HS :
  • (2) Plus de connexion à internet possible depuis mon réseau.
  • (2) Serveur auto-hébergé n'est plus du tout accessible, y compris depuis le réseau local.
  • (3) Si la situation se prolonge, risque de perte des nouveaux mails entrant.
  • (2) Serveur NAS inaccessible en local.
  • (1) Téléphonie fixe non fonctionnelle.
Switch 16 ports HS :
  • (2) Plus de connexion à internet possible pour le serveur auto-hébergé, le serveur NAS et les autres postes sur mon réseau.
  • (2) Serveur auto-hébergé n'est plus du tout accessible, y compris depuis le réseau local.
  • (3) Si la situation se prolonge, risque de perte des nouveaux mails entrant.
  • (2) Serveur NAS inaccessible en local.
  • (1) Téléphonie fixe non fonctionnelle.
Switch 8 ports HS :
  • (2) Plus de connexion à internet possible les postes bureautique sur mon réseau.
  • (2) Serveur auto-hébergé n'est plus du tout accessible en local.
  • (2) Serveur NAS inaccessible en local.
  • (1) Téléphonie fixe non fonctionnelle.
  • (1) Impression sur l'imprimante réseau locale impossible.
Serveur public HS :
  • (2) Services auto-hébergé non fonctionnels.
  • (3) Si la situation se prolonge, risque de perte des nouveaux mails entrant.
  • (3) Selon la panne du serveur, risque possible de perte des données stockées dessus.
Serveur NAS HS :
  • (2) Serveur NAS inaccessible en local.
  • (3) Selon la panne du NAS, risque possible de perte des données stockées dessus.
Ensemble des équipements réseau, serveur, bureautique HS :
  • Reprendre l'ensemble des points listés précédemment.

Je ne traite pas le cas d'une panne sur la box OVH car la maintenance de cet appareil n'est pas à ma charge. En cas de défaillance, le problème est à traiter par OVH.

On peut déjà voir que certains éléments sont plus critiques que d'autres mais ils ont tous ou presque la possibilité d'entrainer des pertes de données. Si je n'en avais pas conscience avant, au moins là, c'est clairement établi. A y regarder de plus près, je vois deux types de problèmes sur les données. La non récupération de données externe et la perte de données préalablement récupérées. Dans le premier cas, c'est la conséquence d'une défaillance réseau et dans le second cas, il s'agit de la défaillance du système de stockage.

Ce qui est prévu en cas de défaillance :

S'il me faut maintenant assumer la défaillance d'un équipement, comment est-ce que j'ai prévu de réagir ? Voici ma réponse élément par élément :

Modem ADSL :
  • J'ai un modem équivalent de rechange.
Parefeu :
  • Aie ! Pas de machine de remplacement.
  • Configuration sauvegardée.
Switch 16 ports :
  • Aie ! Pas de switch manageable de remplacement.
  • Configuration sauvegardée.
Switch 8 ports :
  • Aie ! Pas de switch manageable de remplacement.
  • Configuration sauvegardée.
Serveur public :
  • Aie ! Pas de machine identique de remplacement.
  • Sauvegarde journalière des données importantes sur DD USB externe
  • Sauvegarde journalière des données importantes sur le NAS
Serveur NAS :
  • Aie ! Pas de machine identique de remplacement.
  • NAS deux baies en RAID 1. Réduction du risque de perte des données.
  • Les données les plus importantes stockées sur le NAS sont aussi sauvegardées sur une machine bureautique.
Ensemble des équipements réseau, serveur, bureautique HS :
  • Aie ! Pas de solution de remplacent de matériel.
  • Perte de toutes mes données.

Comme on peut le voir, je ne dispose pratiquement pas d'équipements "sur étagère" afin d'intervenir immédiatement en cas de défaillance, ceci afin de repartir sur une configuration strictement identique. Ça ne veut pas dire que je suis bloqué mais ça demande quelques aménagements.

Mon réseau actuel n'est que l'évolution d'un réseau à plat. Si mon parefeu ou l'un de mes switchs manageable venait à dysfonctionner, j'ai la possibilité de basculer rapidement vers une architecture réseau plus simple. Je dispose d'un switch de secours et mon modem ADSL étant un modem/routeur en mode bridge, je n'ai qu'à en modifier la configuration si besoin pour le repasser en routeur. Reste ensuite simplement à revoir l'adressage IP. Ces manipulations ne sont pas longues à réaliser et me permettent de passer facilement dans un mode dégradé.

Les données importantes sur le NAS ou le serveur public sont aussi stockées ailleurs.

Globalement donc, je sais quoi faire si un élément de mon réseau tombe et mes données sont protégées contre une défaillance isolée de matériel.

Les trous dans la raquette :

Bien que le NAS soit en mesure d'assurer mon hébergement web et mail, tout comme il est possible au serveur public d'assurer le stockage des données actuellement sur le NAS, je préfère si possible éviter de rassembler l'ensemble de ces usages sur une même machine. Une défaillance du NAS n'est pas dramatique mais une défaillance du serveur public l'est plus dans la mesure où je ne peux m'en passer et parce que je ne dispose pas de solution à déployer rapidement s'il venait à me lâcher.

Le problème le plus important pourrait se produire en cas d'incendie ou de vol de matériel. Je ne dispose pas aujourd'hui de moyen de repartir même en mode fortement dégradé après ce type de problème. Pire, je perds toutes mes données puisque je ne dispose que de sauvegardes locales.

Actions à mener afin de combler ces faiblesses :

Je vais prévoir assez rapidement une machine supplémentaire que je serai en mesure de configurer rapidement en cas de défaillance de mon serveur public ou de mon parefeu.

Je vais prévoir de placer une sauvegarde récente de mes données sur un autre lieu, de sorte que les pertes de données soient minimes même en cas de problème grave.

Dernier point, je vais aussi réfléchir à une solution permettant de poursuivre mon activité ailleurs en cas de problème grave chez moi.

Conclusion

Tant que ça marche, on ne se pose pas de question mais dès que ça ne marche plus, il peut être trop tard pour chercher des réponses. Cette petite analyse me montre quels sont les points à travailler sur mon installation. Chaque installation auto-hébergée est différente mais je pense qu'elles méritent toutes une petite réflexion de ce type.

Fil RSS des articles de ce mot clé