Réduire l’empreinte carbone de votre hébergement de serveur

L’industrie de l’hébergement de serveurs est grosse consommatrice d’énergie.
A ce titre, en tant que clients de cette industrie, nous avons tous un rôle à jouer pour limiter l’empreinte carbone de notre activité numérique.

Au delà des chiffres souvent fantaisistes que l’on peut voir sur la consommation énergétique des emails ou des services de streaming, il existe une action toute simple que à mettre en oeuvre pour réduire la pollution générée par vos serveurs : migrer vers l’électricité bas carbone.

Écartons pour l’instant les considérations sur la fabrication, le transport et le recyclage des serveurs, et examinons la pollution liée au fonctionnement de nos machines.

Un serveur consomme de l’électricité de deux manières : sa consommation directe, et sa consommation indirecte.

La consommation directe, c’est l’électricité nécessaire pour faire fonctionner les éléments internes de la machine :

  • le transformateur et le ventilateur de l’alimentation
  • les processeurs CPU et éventuellement GPU
    Les consommations des différents types et générations de processeurs sont très variables – celle ci sont indiquées dans les spécifications des constructeurs. Le choix d’un processeur « efficient » impactera beaucoup votre consommation directe.
  • les différentes cartes (motherboard, cartes réseaux, RAM, etc)
  • les supports de stockage
    Les disques durs mécaniques consomment une énergie importante, même pour une faible utilisation. Les disques SSD consomment considérablement moins d’énergie ! Préférez donc des serveurs uniquement SSD pour réduire votre consommation directe.
  • la ventilation interne du serveur
    Plus le serveur chauffe, plus il faut le ventiler : en choisissant un processeur à faible consommation et en supprimant les disques mécaniques, vous produisez moins de chaleur, et vous consommez donc moins d’énergie à l’évacuer.

La consommation indirecte, c’est l’électricité nécessaire pour faire fonctionner l’environnement du serveur :

  • toute la consommation « périphérique » du datacenter et notamment la climatisation des salles machines
    Les datacenters n’ont pas tous la même consommation périphérique : l’indicateur du Power Usage Effectiveness (PUE) est un critère intéressant.
    Les datacenters modernes, situés dans des pays ‘froids’ ou tempérés utilisent notamment le Free Cooling, c’est à dire l’utilisation d’un air extérieur froid ou d’une eau fraîche pour évacuer les calories, ce qui est beaucoup moins énergivore que le refroidissement par des climatiseurs classiques.
    Certains datacenters « recyclent » la chaleur produite pour chauffer des bâtiments, mais ces initiatives restent marginales.
  • les éléments de réseau qu’utilise le serveur pour acheminer les flux vers vos usagers
    Plus votre serveur est éloigné de ses usagers, plus vous utilisez de routeurs et répéteurs au long des parcours.

La somme de ces deux consommations électriques est importante ! N’oublions pas que nos serveurs sont allumés en permanence, pour des années.

Le cumul est impressionnant : pour un serveur de 250 Watts, dans un datacenter avec un PUE 1,10, allumé pendant 1 an,
365*24*250*1.2 = 2628 KwH ! Soit plus que la consommation annuelle d’un ménage : 2 350 kWh

 

Une électricité plus ou moins polluante à produire

Il existe de nombreuses façons de produire de l’électricité, et toutes les méthodes ne se valent pas au niveau du bilan carbone.

L’électricité produite par les énergies fossiles (fioul, gaz, charbon) est une source monumentale de CO2 atmosphérique : 820 grammes de CO2 par kWh !

L’électricité hydraulique ou nucléaire ont un taux bien meilleur : L’énergie nucléaire émet près de 150 fois moins de gaz à effet de serre que le thermique charbon.

Aussi, il devient immédiatement intéressant de migrer nos serveurs hors des pays dont l’électricité est produite par des énergies fossiles ! 

Cette splendide carte  ElectricityMap vous montrera très visuellement que pour moins polluer, il faut éviter d’héberger vos serveurs aux USA, en Pologne ou en Australie… Et que la France, le Canada ou la Norvège se placent très bien sur ce classement !

Nous devons donc nous attacher à réaliser le meilleur choix de configuration pour limiter nos consommations : un serveur économe, dans un datacenter économe, alimenté par une électricité bas carbone !.

 

 

 

Sources :

RTE, Bilan électrique 2018, https://www.rte-france.com/sites/default/files/be_pdf_2018v3.pdf
RTE, Eco2mix : https://www.rte-france.com/fr/eco2mix/eco2mix-co2
Wikipédia, Émission de gaz à effet de serre par source d’énergie électrique
Intergovernmental Panel on Climate Changehttps://www.ipcc.ch/site/assets/uploads/2018/02/ipcc_wg3_ar5_annex-iii.pdf
Sylvestre Huet, Blog Lemonde, https://www.lemonde.fr/blog/huet/2019/05/06/electricite-et-co2-le-tableau-europeen/
ElectricityMap, https://www.electricitymap.org/?page=map&solar=false&remote=true&wind=false

Publié dans Actualités, Environnement

Activer DNSSEC pour votre domaine chez Gandi.net

Comment activer la fonctionnalité DNSSEC pour votre domaine géré par Gandi.net ?

Première étape, vérifiez que les serveurs de noms de votre domaine sont bien les serveurs « Gandi LiveDNS »  : la fonctionnalité DNSSEC n’est accessible que sur LiveDNS.

Il faut également que l’extension de votre domaine (le TLD) soit compatible avec DNSSEC. C’est le cas du « .com » que nous allons utiliser en exemple.

Si c’est le cas, vous avez un lien « accéder à DNSSEC » en bas à droite : rendons-nous sur cette page

Cliquons sur le bouton « Activer DNSSEC »

Au bout de quelques dizaines de secondes, le temps pour Gandi de générer et enregistrer la clé, votre domaine est sécurisé par DNSSEC.

Vous trouverez ici la documentation Gandi sur DNSSEC, comprenant notamment la liste des extensions compatibles.

La page Wikipédia francophone sur DNSSEC est ici.

Pour tester votre implémentation DNSSEC, un outil en ligne fourni par Verisign est disponible à cette adresse : https://dnssec-analyzer.verisignlabs.com/

En ligne de commande, vous pouvez utiliser la commande dig pour récupérer la clé :

dig sebastiengalliot.com IN DNSKEY

 

L’activation de DNSSEC rend les transferts de domaine et le changement des serveurs de noms un peu plus complexe. N’hésitez pas à faire appel à nos services pour vos migrations de domaines DNSSEC

 

Publié dans Domaines et DNS, Sécurité

Préparez votre « Cloud Exit Plan »

Si vous avez fait le choix de transférer votre système d’information sur le fameux « nuage », cet article peut vous intéresser :)

Pourquoi préparer un « Plan de sortie du Nuage » ou Cloud Exit Plan ?

Vos données et applications sont maintenant hébergées par un grand fournisseur de cloud. Les performances sont au rendez-vous, tout est bien rodé, les utilisateurs satisfaits et vous avez enfin supprimé la case « maintenance matérielle » de votre emploi du temps.

Petit détail, vous êtes maintenant sujet à deux risques :

  • l’évolution tarifaire de vos hébergements cloud
  • vous faire bannir par le prestataire

La partie tarifaire est un pari sur l’avenir. Votre prestataire cloud ne s’engage jamais pour une durée bien longue sur ses tarifs. Aujourd’hui il est intéressant, mais le sera-t-il tout autant dans un an ou deux ? C’est une industrie en pleine évolution et la concurrence est rude ; certains prix sont très bas mais sont-ils tenables dans la durée ? Un autre cloud provider va peut-être vous donner envie de changer… Ou votre provider actuel va vouloir reconstituer un peu de marge … et vous êtes dans une situation assez captive non ?

La partie bannissement est un jeu de dupe. Relisez bien les conditions générales : le cloud provider peut vous virer sous des prétextes parfois bien flous, ou sur des événements que vous ne pourrez pas forcément maîtriser. Imaginez : une petite faille de sécurité dans votre appli, un comportement délictueux se met en place sur vos systèmes (piratage, phising, pédopornographie ou virus…) et l’ensemble de votre compte est soudain bloqué.

Il est essentiel de prévoir une porte de sortie pour votre système hébergé.
Préparer la migration d’un système entier ne se fait pas en quelques minutes, surtout dans l’urgence et le stress d’une situation de blocage.

N’hésitez pas à nous solliciter pour élaborer, tester et réaliser vos migrations « Cloud Exit Plan »

 

Publié dans Hébergeurs, Sécurité

Quelques astuces pour un site WordPress en bonne santé

Nous sommes régulièrement missionnés par des clients ayant le malheur de voir leur site WordPress piraté par divers malwares…

Voici quelques conseils pour garder votre site WordPress en pleine forme !

Réalisez les mises à jour WordPress

La première des bonnes pratiques du webmaster, c’est de profiter du travail des développeurs WordPress en installant sans tarder les mises à jour disponibles !

Si le noyau de WP propose une MAJ, n’hésitez pas : une sauvegarde complète et on lance l’installation de la mise à jour – qui se passe en général très bien !

Mettre à jour ses plugins et thèmes

Les développeurs de plugins ne publient pas de mise à jour pour vous embêter, surtout lorsque celles-ci incluent des correctifs de sécurité. Maintenez vos plugins à jour ! C’est une source extrêmement fréquente de vulnérabilités

Restez léger !

Plus vous installez de plugins, plus vous agrandissez votre surface d’exposition aux problèmes potentiels. Beaucoup de plugins = beaucoup de plugins pouvant potentiellement contenir une faille exploitable.

Limitez vos extensions au strict nécessaire, cela aura aussi l’avantage de rendre votre site rapide et fluide…

Vérifiez vos droits d’accès

Ne conservez pas inutilement des utilisateurs avec privilèges (éditeurs, administrateurs) dans votre table d’utilisateurs. Ne conservez que les utilisateurs absolument nécessaires et assurez vous de l’utilisation de mots de passes forts (longs et complexes), pour éviter des logins indésirables.

Le plugin magique n’existe pas

Ne faites pas une confiance aveugle dans les « plugins de sécurité » vous promettant un wordpress indestructible ! Si ces plugins « de protection » ont des avantages certains,  ils ne vous évitent pas d’appliquer une politique de sécurité stricte et régulièrement mise en oeuvre.

Sauvegardez vos données

Une sauvegarde n’est jamais du temps perdu : prenez le temps de sauvegarder régulièrement votre site (fichiers ET base de données) et vérifiez l’intégrité de vos backups.

Utilisez un serveur à jour

Veillez à utiliser un hébergement de qualité, disposant des versions à jour des logiciels serveurs (serveur web / php / mysql / sftp / ssh). Ce serait dommage de subir une attaque due à un système obsolète !

Lisez les messages de votre hébergeur !

Si votre hébergeur vous signale un envoi massif d’email, ou vous remonte un problème de sécurité, ne prenez pas cette alerte à la légère ! Votre site mérite toute votre attention.

 

Publié dans Sécurité

base de données OVH mutualisée pleine (READONLY)

Attention : ces commandes sont à manier avec précaution, si vous ne savez pas ce que vous faites, ne le faites pas. 

Sur un hébergement mutualisé OVH, vos bases de données sont limitées en taille.

« Si vous dépassez l’espace de stockage recommandé, vos droits seront limités à un accès en lecture seule. »

Lorsque cela vous arrive, la base est accessible uniquement en READONLY et lorsque vous essayez de passer par PhpMyadmin pour vider des tables, vous n’avez pas le droit de lancer de commandes comme DROP ou TRUNCATE

La solution est de se connecter en ligne de commande via SSH et lancer les opérations Mysql depuis la ligne de commande

ssh USER@HOST
mysql -u USERNAME -pPASSWORD -h HOSTNAME
use DATABASENAME;
delete from TABLENAME ;

Les opérations de delete sont parfois très longues.

Lorsque vous avez fait de la place, le problème peut persister car les tables occupent toujours beaucoup d’espace disque, et vous n’avez pas le droit de lancer une commande « OPTIMIZE »

Il faut donc maintenant faire un dump de la base depuis la ligne de commande

mysqldump -u USER -pPASSWORD -h HOSTNAME DATABASENAME > dump.sql

Vérifiez que le dump est convenable, puis supprimez la base de données dans l’interface OVH.
Recréez la base de données à l’identique, puis importez votre dump

mysql -u USER -pPASSWORD -h HOSTNAME DATABASENAME < dump.sql

 

 

Publié dans Hébergeurs, Php / Mysql

Installez un certificat SSL sur votre site

Protection des données personnelles, sécurité des échanges, RGPD, référencement… Si votre site n’est pas sécurisé via le protocole https , il est temps de faire quelque chose !

La très grande majorité des hébergeurs proposent maintenant des certificats SSL, parfois payants, parfois gratuits comme Let’s Encrypt.

Nous pouvons vous aider à réaliser un passage rapide et efficace vers un site mieux sécurisé !

Consultez nous pour nos forfaits installation SSL et redirections pour WordPress, Prestashop, Drupal, Joomla…

Un tarif abordable pour se débarrasser de ces messages anxiogènes délivrés par les navigateurs !

Publié dans Actualités

Déliverabilité : Activer DKIM dans un VPS avec CPANEL

Pour améliorer la déliverabilité des envois d’email effectués par votre serveur web, il est très important de bien configurer DKIM.

Si votre serveur est managé par un CPANEL, c’est assez simple, mais l’interface est un peu confuse. Voici l’astuce, surtout utile si votre zone DNS de votre domaine n’est pas servie directement par le serveur lui-même.

Première étape : activer DKIM
Dans la partie des réglages emails, aller dans la zone « authentification » et cliquez sur le bouton « activer DKIM ».
L’interface précise que DKIM sera activé pour la réception des emails, mais en réalité cela va activer AUSSI pour l’envoi des emails, via la fonction mail de php par exemple.

Seconde étape : récupérer la clé publique associée au domaine
C’est là où c’est un peu confus. La clé publique nécessaire est stockée dans

/var/cpanel/domainkeys/public/nomdedomaine.tld

Connectez vous en SSH sur le serveur et récupérez le contenu de ce fichier.

Troisième étape : la zone DNS
Ensuite, créez un enregistrement TXT dans votre éditeur de zone DNS
Celui ci sera de la forme suivante :

default._domainkey 14400 IN TXT "v=DKIM1; k=rsa; p=CONTENU_DU_FICHIER_DE_CLE_PUBLIQUE"

Certains fournisseur de zones DNS ne supportent pas un champ aussi long pour un enregistrement TXT, il vous faudra alors couper la clé en DEUX selon cette forme :une paire de doubles guillemets

default._domainkey 14400 IN TXT "v=DKIM1; k=rsa; p=CONTENU_DU_FICHIE""R_DE_CLE_PUBLIQUE"

Vous validez, vous attendez un peu la propagation et vous vérifiez avec la commande suivante que vous avez bien la clé publique dans votre zone DNS

dig default._domainkey.nomdedomaine.tld IN TXT

Normalement tout est ok, vous pouvez aller vérifier par exemple chez Mail-tester que votre serveur est capable d’atteindre un score honorable.

Si vous désirez une prestation de réglage de votre serveur web pour l’envoi d’email, n’hésitez pas à nous contacter !

Publié dans Domaines et DNS, Gnu / Linux

Bug WordPress 4.9.3 : réalisez les mises à jour !

La version de WordPress 4.9.4 corrige un petit bug qui n’a pas l’air bien méchant, mais qui risque de faire très mal… d’ici quelques mois !

Voir le changelog officiel : https://codex.wordpress.org/Version_4.9.4

En clair : la version 4.9.3 ne peut pas se mettre à jour « toute seule ».. Donc tous les webmasters économes de leurs énergies, (ceux qui laissent « tourner tout ça sans s’en occuper ») , se sont retrouvés avec une version de WordPress 4.9.3 qui restera bloquée tant qu’une mise à jour manuelle n’est pas réalisée….

D’ici quelques mois une faille sera forcément découverte sur la 4.9.3 et des  milliers de wordpress vont se retrouver sans défenses…

La seule solution est donc une mise à jour manuelle de votre WordPress si celui-ci est en 4.9.3

 

Publié dans Actualités

Pourquoi nos clients veulent changer d’hébergeur web ?

Après quelques années d’activités et quelques milliers de migrations, il nous semble intéressant de lister ici les raisons qui poussent un éditeur de site web à changer d’hébergeur.

Ce billet repose sur notre ressenti au contact des clients.

Voici, par ordre de fréquence, les raisons de changement d’hébergeur, exprimées par les clients directs de services d’hébergement :

Un support technique inadapté

C’est nettement le problème le plus fréquent remonté par les clients hébergés : un problème ou une question technique apparaît, le client contacte le support, et la réponse n’est pas satisfaisante, pour une ou plusieurs raisons :

  • le délai de réponse du support est excessif
  • la réponse ne solutionne pas le problème
  • la réponse est incompréhensible par le client
  • le ticket est morcelé entre différentes personnes du support, avec des réponses parfois contradictoires

La question initiale est parfois mal formulée par le client, ou le client ne s’adresse pas au bon interlocuteur.

Une succession de pannes d’hébergement ou de mauvaises performances

  • le service web subit des interruptions de services longues, à répétition
  • le serveur web met trop de temps à répondre
  • certains scripts tombent en timeout
  • le site requiert une infrastructure d’hébergement plus puissante

Les raisons sont multiples.

Certains sites à fort traffic sont hébergés sur des offres inadaptées et le client n’est pas orienté par l’hébergeur vers une offre convenable. Il en résulte une perte de trafic potentiel et un mécontentement de l’éditeur.

Certains sites sont développés ou configurés de très mauvaise façon. Des sites parfois simples consomment une quantité de ressources démesurée.

Certains hébergeurs sont vraiment mauvais en production, de manière temporaire ou récurrente.

L’offre d’hébergement est obsolète

Les clients les plus anciens ont créé et hébergé leurs sites il y a des années, en souscrivant à des offres d’hébergement qui n’ont pas évoluées ou qui n’ont pas évoluées suffisamment.

Les services disponibles ne répondent plus aux besoins des clients actuels  : versions de logiciels dépassées, nouveaux services inexistants. Le client ne peut plus maintenir son applicatif à jour dans le cadre technique proposé.

L’interface de gestion de l’hébergeur est inutilisable par le client

Chaque hébergeur propose une interface de gestion totalement différente.

Certaines sont efficaces mais aucune n’est parfaite.

Parfois l’ergonomie est tellement mauvaise que le client n’arrive absolument pas à la comprendre et donc à l’utiliser correctement. De mauvaises manipulations entraînent des problèmes techniques. Le client n’arrive pas à activer ou gérer des fonctions essentielles.

La documentation est inaccessible, incomplète, inutilisable, incompréhensible, obsolète, erronée, mal traduite.

Les messages d’erreur sont incompréhensibles par le client.

L’interface de gestion est fréquemment en panne, très lente, ou génère des erreurs.

Le client regroupe tous ses actifs chez un même hébergeur

Certains clients très actifs ont souscrit des hébergements chez plusieurs prestataires. Le client désire regrouper ses actifs dans une gestion unifiée.

Le tarif est excessif

Le tarif de location n’est plus en rapport avec l’offre du marché, l’hébergeur n’est pas compétitif.

 

Vous êtes concernés par l’un de ces sujets ?
Consultez nous pour effectuer le déménagement de votre site web vers l’hébergeur de votre choix

 

Vous êtes hébergeur ?
Notre expertise en interface de gestion est à votre disposition.

Publié dans Déménageur, Gnu / Linux, Hébergeurs

Accéder à un bureau à distance depuis Windows vers Linux et depuis Linux vers Windows

De Windows vers Linux Debian / Ubuntu

Dans le cadre d’un réseau local de confiance (nous n’aborderons donc pas la question du chiffrement des connections), comment accéder depuis Windows vers un environnement graphique d’un poste Linux debian ou Ubuntu :

Sur le poste Debian, disposant d’un environnement graphique XFCE par exemple,  installez le paquet XRDP

sudo apt-get install xrdp

Indiquez xfce4 comme gestionnaire de fenêtres par défaut pour les connexions RDP.

echo xfce4-session > ~/.xsession

Ouvrez le fichier xrdp.ini pour autoriser la modification du port hôte auquel vous allez vous connecter.

sudo nano /etc/xrdp/xrdp.ini

Recherchez la section [xrdp1] et modifiez le texte suivant
port=-1
par
port=ask-1

Redémarrez xrdp.

sudo service xrdp restart

Sous Windows, ouvrez le client Connexion Bureau à distance, indiquez l’IP du poste Linux dans le champ Ordinateur, puis cliquez sur Connexion.

Indiquez l’identifiant et le mot de passe de l’utilisateur du poste Linux.

Tutoriel basé sur l’exemple AWS

 

 

De Linux Debian / Ubuntu vers Windows

Installez le paquet freerdp

sudo apt-get install freerdp-x11

Lancez la commande

xfreerdp /u:identifiant /p:motdepasse /w:1920 /h:1024 /v:192.168.2.100

où w est la largeur de la fenêtre en pixels, h la hauteur. Remplacez l’ip par l’IP de votre poste windows

Publié dans Gnu / Linux