Sujets-libres.fr

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

Serveur

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

Rédigé par -Fred- / 04 janvier 2017 / 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.

Ce que je n'hébergerai pas sur mon serveur

Rédigé par -Fred- / 12 septembre 2016 / 6 commentaires

Souvent, les auto-hébergés (comme moi) partagent leurs dernières trouvailles et en règle générale tout ce qui peut présenter un intérêt pour d'autres dans ce domaine. J'ai donc trouvé amusant de prendre un peu le contre-pied de cette approche et de parler de ce que je n'hébergerai pas (ou plus) chez moi.

Un webmail

Il n'y a pas si longtemps, j'en utilisais. D'abord Roundcube durant quelques années, puis ensuite Rainloop pendant quelques mois. L'un et l'autre faisaient le boulot. J'ai toutefois repensé un peu mon utilisation du mail et je suis arrivé à la conclusion que je n'avais pas besoin d'accéder à mes mails en dehors de chez moi. J'en reçois finalement assez peu et je n'ai jamais d'urgence à y accéder dans l'heure. Du coup, je n'y accède aujourd'hui qu'avec un client lourd, uniquement depuis un seul poste fixe chez moi. Ça peut sembler être très limité vu comme ça mais c'est très bien.

J'ajoute qu'avant, même si je n'avais pas un besoin vital de lire mes mails, je me connectais quand même à mon webmail depuis un peu partout. On se rend compte après coup que l'on consulte machinalement sa boite et que ça devient presque un TOC. Quelque part, c'est aussi une façon de montrer qu'on est pas l'esclave de ses mails.

Un CMS lourd

J'utilisais Wordpress précédemment mais là, ce dont je parle est plus global.

Ces outils offrent beaucoup de fonctionnalités, trop en tout cas par rapport à ce dont j'ai vraiment besoin. La question de leur pertinence vis à vis de mes usages propres s'est posée. Clairement, mon blog perso tel que je l'envisage, c'est pour y mettre du texte, quelques photos et de temps à autre, un petite vidéo ou deux. Pas besoin d'une usine à gaz pour le faire (ici par exemple, PluXML fait l'affaire sans soucis).

De base, ces outils sont complexes et donc plus sujets aux failles de sécurité (j'en ai fait les frais sur Wordpress). Constater qu'un outil qui se met à jour automatiquement et qui n'utilise que deux ou trois plugins officiels est tout de même piraté, c'est peu rassurant...

Un gros CMS peut devenir vraiment lourd, notamment si on lui ajoute de nombreux plugins ou quelques plugins mal configurés. L'intérêt d'un gros CMS tient pour beaucoup dans les grosses possibilités de configuration et de personnalisation qu'ils offrent. Le revers de la médaille, c'est que ces outils deviennent ainsi potentiellement plus sujets aux bugs, aux failles et plus consommateurs de ressources, ce qui peut dans ce dernier cas entraîner des lenteurs de chargement (dans certains cas extrêmes, ça peut rendre un blog totalement impraticable).

Des services, sur un coup de tête

On peut être tenté d'installer tout et n'importe quoi sur sa machine de prod, le temps d'essayer et de se forger un avis. Aujourd'hui, je peux faire mes tests sur une machine virtuelle dédiée, c'est plus propre et ne risque pas de mettre en péril l'activité des machines de prod.

En fait, si je décide de supprimer quelque chose que j'ai installé sur un coup de tête sur une machine en prod, je ne suis jamais certain que je retrouverai son serveur dans l'état exact d'avant installation. D'une part, je ne me fais pas à moi même une confiance absolue. Je suis un humain câblé à peu près normalement et je fais des erreurs. Je peux donc involontairement mal désinstaller une application ou laisser traîner un reliquat de configuration de l'application en question. D'autre part, si par le jeu des dépendances, l'installation d'un paquet a entraîné l'installation de d'autres paquets, je vais très probablement ne pas penser à les virer eux aussi lorsque j'aurai décidé de désinstaller le premier paquet. Ce n'est pas très propre.

Pour les services qui restent installés, il faut déjà penser à tous les tenir à jour. Plus il y en a, plus ça fait du boulot et plus ça augmente la surface d'attaque sur mon système auto-hébergé. Réduire la voilure n'est pas déconnant en fait..

Une connaissance

L'auto-hébergement, c'est en principe héberger ses propres données chez soit, sur un système qui est accessible depuis n'importe où sur internet. On le fait sur une machine qui est rarement exploitée à fond. Il est donc possible de fournir, à titre gracieux par exemple, un peu d'espace disque et des ressources diverses sur cette machine à d'autres personnes.

C'est ce que j'ai fait une fois il y a un certain temps et que je ne referai plus, tant cela s'est mal passé. En effet, cela demande parfois du temps (dont on ne dispose pas toujours) et de la patience (dont on s'aperçois qu'elle s'amenuise au fur et à mesure des demandes incessantes de la personne).

Dans le cas où ça se passe bien (ce qui doit quand même se passer en temps normal), l'idée même d'héberger quelqu'un d'autre sur mon serveur a fini par me poser un problème de principe. L'auto-hébergé, c'est moi, uniquement moi, pas celui que j'héberge. Conceptuellement, il n'y a presque pas de différence pour une connaissance entre héberger ses données chez moi ou chez un hébergeur ayant pignon sur rue. Enfin si, il y en a une de taille. Je peux le faire ponctuellement mais il est très probable que je connaisse déjà avant celui que j'héberge (IRL ou par un autre biais). Ce n'est pas le cas pour le fournisseur d'hébergement classique qui lui ne verra qu'un client comme un autre, noyé dans la masse. Tout le problème est là. Je peux avoir un intérêt particulier à accéder aux données de celui que j'héberge et même si je ne le fais pas, j'en ai techniquement la possibilité. Une connaissance que j'héberge ne peux pas avoir la certitude que je n'abuse pas de mon pouvoir. Cela donc n'est pas sain.

Conclusion

Ce que j'énumère ici n'est pas exhaustif mais à travers ça, je montre un peu mon approche de l'auto-hébergement. Je cherche à ne pas oublier que même si j'ai commencé à le faire de manière artisanale, cela reste un système en production, sur lequel j'ai les pleins pouvoir et que je dois conserver en état de fonctionnement.

Bonemine entre en service

Rédigé par -Fred- / 07 juillet 2016 / Aucun commentaire

Bonemine, mon nouveau serveur, entre progressivement en service. La machine en elle même ne sert qu'à virtualiser d'autres machines. Ainsi, elle accueil à présent Ordralfabetix (serveur MAIL) et Cetautomatix (serveur WEB). Prochainement, Assurancetourix viendra les rejoindre et prendra en charge le reste de ce que je veux faire tourner.

Le remplacement d'Assurancetourix par un ensemble de machines virtuelles m'a amené à réfléchir à ma manière de superviser mon parc. Ainsi, j'utilise à présent Nagios. Je ne connaissais pas du tout cet outil. J'ai donc déjà passé un peu de temps pour le prendre en main. Ça a un peu retardé ma mise en production de Bonemine mais je n'ai aucune urgence donc...

Bienvenue à Bonemine

Rédigé par -Fred- / 24 juin 2016 / Aucun commentaire

Après plusieurs années de bons et loyaux services, Abraracourcix, mon modeste serveur va passer la main à Bonemine. La config de cette nouvelle machine est la suivante :

  • Athlon 5150
  • 8Go de DDR3
  • DD de 1To
  • Alim Corsair 350W
  • GNU/Linux Debian 8

La config n'est pas monstrueuse mais amplement suffisante pour accueillir plusieurs machines virtuelles. La préparation du serveur va prendre quelques jours mais je devrais pouvoir le mettre en production début juillet si tout va bien.

Un changement de machine est l'occasion de refaire les choses proprement. L'utilisation de machines virtuelles va notamment me permettre d'en dédier à certains usages et donc de mieux cloisonner les différents services que j'utilise. Ceci dit, cela fait plus de machines à administrer au quotidien. Je dois donc encore choisir l'outil qui me permettra de garder un œil sur tout ça. Aujourd'hui, j'utilise Munin pour surveiller l'activité d'Abraracourcix mais je vais quand même faire le tour des solutions existantes pour trouver la plus adaptée.

Abraracourcix ne sera pas totalement démobilisé. Une fois que Bonemine sera en production, il sera reconfiguré pour resservir au cas où Bonemine venait à défaillir (il vaut mieux prévenir que guérir :p ).

Anticiper les ennuis en auto-hébergement

Rédigé par -Fred- / 25 avril 2016 / 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.