Sujets-libres.fr

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

Openmailbox modifie son offre

Rédigé par -Fred- 1 commentaire

En soit, une telle nouvelle ne m'intéresse pas car mon mail est auto-hébergé. Toutefois, nombreux sont ceux qui utilisent ce service. Nombreux sont ceux aussi à avoir été pris de cours lorsque le service a sans prévenir modifié son offre, amputant au passage l'offre gratuite de choses de base comme l'accès POP/IMAP. Certains semblent avoir du mal à digérer cela. A mon sens, ça pointe autre chose : un service mail ne peut pas à la fois être simple, gratuit, pérenne, éthique et efficace.

Les conditions générales d'utilisation ne sont jamais lues car souvent illisibles, faut bien l'avouer. Ici coup de bol, elles sont simples et claires : https://www.openmailbox.org/tos. Malheureusement, c'est pas pour ça qu'elles sont plus lues. Il existe bien une offre gratuite mais quoi qu'il arrive, OpenMailBox se décharge des conséquences des aléas techniques sur leurs utilisateurs, utilisateurs qui sont au passage seuls responsables de leurs données.

Je peux comprendre qu'une annonce aussi brutale soit (très) mal perçue mais il faut quand même remettre les choses à leur place. Un service gratuit peut s'arrêter du jour au lendemain sans préavis. C'est quasiment ce qui est arrivé là et c'est une chose à prendre en compte lorsque l'on s'inscrit. Il est de la responsabilité des utilisateurs de prendre les mesures adéquates pour faire face à ce qui peut survenir et qui est prévisible (encore une fois, c'était tout à fait prévisible à plus ou moins longue échéance). Donc la moindre des choses, c'est de sauvegarder ses données ailleurs périodiquement. La bonne pratique serait d'en conserver au moins une copie locale à jour. Cela est aussi utile en cas de problème technique indépendant de la volonté du tiers qui propose le service.

Chose amusante, car sans conséquences sur l'instant, ils sont nombreux à migrer vers un autre service gratuit. A ceux là, je tiens juste à rappeler que ça ne change rien au problème et qu'ils gardent cette épée de damoclès au dessus de la tête s'ils ne se sentent pas plus responsables de leurs données. Le prochain arrêtera peut être complètement son service sans possibilité de récupérer ses données.

Chose plus inquiétante, ceux qui se plaignent sont majoritairement des utilisateurs du service gratuit et ils se comportent comme des clients pour qui tout est dû et qui balaient leurs propres obligations d'un revers de main (envers eux même et envers le tiers qui propose le service). Je ne trouve pas ça sain comme approche. Dans les commentaires que j'ai pu lire, je vois qu'ils sont nombreux à annoncer vouloir migrer vers l'offre gratuite de net-c. Si vous vous trouvez dans ce cas là, je n'ai pas regardé dans le détail mais c'est probablement un très bon choix. Toutefois, en utilisant leur service gratuit, les conditions d'utilisation (point 12.1) stipulent par exemple et très clairement que lorsque vous accédez à leur service, vous ne devez pas bloquer leurs publicités (les CGU sont un peu plus consistantes que celles d'OpenMailBox mais elles restent lisibles, ne vous privez pas). Je serais curieux de connaître la proportion d'utilisateurs qui tiendra compte de ce genre de détail avant de souscrire... Et qu'est-ce qui empêche le service en question de bloquer l'accès à leur site pour les utilisateurs gratuits ne respectant pas cette clause ?

Mon adresse email est inhabituelle

Rédigé par -Fred- 16 commentaires

Cela fait 10 ans cette année que je gère mon mail comme un grand. C'est super d'avoir ses adresses mail personnelles sur son propre serveur mail. Je peux en créer autant que je veux dessus, avec n'importe quel nom, du plus drôle au plus court en passant par des choses plus passe partout. Je ne risque pas en tout cas de ne pas pouvoir en créer une car une autre personne l'a déjà prise. Pour les quelques adresses créées, je suis généralement resté sur des choses courtes ou assez évocatrices en fonction des besoins. Je peux par exemple décider de créer une adresse en cas d'inscription à une liste de diffusion ou quand je sais que je risque de me faire spammer lorsque je dois quand même laisser une adresse valide quelque part. Dans ce dernier cas, je pourrais aussi me créer des adresses jetables ailleurs.

La contrepartie, c'est que mon nom de domaine est ce qu'il est d'une part, et qu'il est surtout inhabituel pour le quidam dans une adresse mail. En soit, il n'est pas trop compliqué car composé de deux mots existants intercalés par un tiret et qu'il est enregistré sur le TLD .fr . Toutefois, il est devenu de plus en plus rare de voir des adresses mail autres que celles fournies par gmail, yahoo et les FAI en général. Non content de présenter un problème de manque de diversité (la centralisation est énorme sur les services mail en général), cela renforce l'idée qu'une adresse mail doit forcement se terminer par un truc comme gmail.com, yahoo.fr, orange.fr, etc... Cela me pose parfois un problème lorsque je donne une adresse personnel de vive voix. Une fois l'étonnement de mon interlocuteur passé, vient le moment où il faut bien épeler le truc. C'est là qu'on peut avoir l'impression d'agacer alors même que ce n'est pas le but. Est-ce que je peux leur en vouloir individuellement ? Non bien entendu. L'environement global conduit massivement vers cela, c'est tout.

Fut un temps, je donnais encore une adresse yahoo dont les mails étaient redirigés vers l'une des boîtes mail sur mon serveur pour éviter de gêner mon monde sans doute. J'ai passé le cap et maintenant, je donne directement l'adresse sur mon domaine. Si c'est pénible, ce n'est pas mon problème. Moi, c'est l'adresse que j'utilise et que je consulte et ce n'est pas moins une adresse mail qu'une autre avec un nom de domaine plus commun. Une lubie de geek ? En partie au début probablement mais aujourd'hui non, je vois les choses de manière plus simple. L'outil est assez ouvert pour permettre à quiconque de le faire (comprendre "quiconque" par le fait que c'est techniquement possible et qu'il n'y a pas d'interdiction à le faire) et je pense que je suis la personne la mieux placée pour gérer mes serveurs mail. Finalement, mes adresses ne sont pas plus compliquées que celles proposées par les gros services de mail mais la complexité ne se retrouve pas au même endroit.

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.

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

Rédigé par -Fred- 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.

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 cette catégorie