Sujets-libres.fr

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

Blog

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.

Mise à jour blog vers PluXml 5.5

Rédigé par -Fred- / 06 avril 2016 / Aucun commentaire

Le blog évolue et passe de PluXml 5.4 à PluXml 5.5 . La mise à jour s'est effectuée sans incident. Une fois les nouveaux fichiers copiés (tous sauf les répertoires /data, /plugins et /themes, ainsi que le fichier config.php) et leurs droits vérifiés, il suffit de se rendre sur le blog et d'exécuter la mise à jour proposée afin de finaliser la migration. C'est tout.

J'apprécie toujours autant la simplicité d'utilisation de ce CMS. Merci donc aux contributeurs.

Page officielle du projet : www.pluxml.org

Le blogueur et les commentaires

Rédigé par -Fred- / 05 janvier 2016 / Aucun commentaire

Je me pose une question toute bête en ce début d'année : "Y a-t-il une manière de bloguer ?", ou dit autrement et de manière plus précise "Est-ce que quelque part figurent des règles de bonnes pratiques du blogueur, notamment concernant la gestion des commentaires ?".

En fait, je note un comportement surprenant sur plusieurs blogs (avec un certain trafic ou non d'ailleurs). En effet, le ou les blogueur(s), auteur(s) d'articles, ne réagissent pas du tout lorsque des commentaires sont postés en réaction à un de leurs billet. Ce que je trouve d'étonnant, c'est que cela touche autant de gros blogs que de plus petits et/ou confidentiels pour lesquels cela est humainement plus facile à traiter.

Au final, je ne saisis pas trop l'intérêt de la démarche, et si cela est volontaire ou non. Lorsque je laisse un commentaire, j'éprouve en tout cas une certaine frustration face à cette situation. Ce n'est pas tant de ne pas avoir de retour par rapport à mon commentaire qui m’ennuie mais vraiment qu'il n'y ai aucun retour pour personne. Lorsque ça se répète sur un blog, ça donne vraiment l'image que l'auteur n'a pas besoin des retours qui lui sont soumit par le visiteur lambda. Je lis ici ou là des commentaires d'internautes vraiment intéressants et qui méritent une réponse ou du moins un signe de vie de l'auteur.

Afin de ne froisser personne, je ne donne bien entendu pas d'exemple mais certains sont coutumiers du fait et c'est dommage :-p . Je continue à les lire avec plaisir mais je poste plus rarement mes commentaires ensuite.

Migration Wordpress vers Pluxml

Rédigé par -Fred- / 22 septembre 2015 / 4 commentaires

Suite aux problèmes de sécurité que j'ai rencontré récemment via mon blog sous Wordpress, j'ai décidé de réagir. Ma réaction suite à l'incident en question sera détaillée dans un prochain billet. Toutefois, l'une des choses que j'ai décidé est de changer de moteur de blog et de migrer vers Pluxml.

J'apprécie Wordpress au quotidien, notamment le côté intuitif à mon sens de l'interface d'administration. Malgré cela, c'est une usine à gaz. Pour un usage normal il n'est normalement pas nécessaire de mettre les mains dedans. Toutefois, le côté ultra complet de ce CMS et le nombre impressionnant de plugins qui peut l'accompagner reste une source problèmes potentiels.

J'ai donc étudié plusieurs options afin de pouvoir bloguer un peu plus en paix...

Conserver Wordpress en l'état

La solution la plus simple. J'ai d'ailleurs refait une installation propre de Wordpress lorsque j'ai constaté mon problème. Malheureusement, j'ai un peu moins confiance dans ce CMS et je n'ai pas été en mesure de déterminer comment exactement l'attaquant s'y était pris. L'outil est certes très puissant et configurable mais la contrepartie, c'est qu'il est plus difficile pour la communauté WP de le rendre sûr. Donc, j'ai pris la décision de trouver une alternative.

Conserver partiellement Wordpress

Solution nécessitant un peu de développement de ma part. L'outil Wordpress pour rédiger mes billets et une interface minimaliste codée par mes soins pour accéder aux billets en lecture seule. Gros avantage, mes visiteurs n'ont plus à interagir directement avec Wordpress car finalement, seule la base de donnée est commune. Gros inconvénients, d'une part je perd l'intérêt du blog si les visiteurs ne peuvent plus laisser de commentaires et d'autre part, plus de flux rss de disponibles, sauf à coder ça moi même. Bref, bonne idée sur le moment mais au final je risquais d'accoucher d'un truc limité et pas forcement moins buggué que Worpress. Ce n'est donc pas la solution à retenir ici.

Changer carrément de moteur de blog

Encore faut-il trouver chaussure à son pied et quitter un CMS pour un autre tout autant à risque, ça n'a pas vraiment d'intérêt. J'ai donc fait le tour de quelques moteurs de blog et pour faire court, je me suis arrêté sur Pluxml. J'apprécie de pouvoir y trouver les fonctionnalités de base pour un blog sans m'encombrer de ce que je trouve accessoire. J'apprécie aussi qu'il fonctionne sans base de donnée. J'ajoute que j'ai opéré ma migration depuis Wordpress grâce à "wp2pluxml" (l'outil ne fait pas tout mais permet un gros gain de temps).

Des détails sont encore à régler mais la migration est opérée.