Pour corriger rapidement la faille Prestashop annoncée en Janvier 2020 :
lister les répertoires ‘phpunit’ de votre installation
find . -type d -name "phpunit"
lister ET supprimer les répertoires :
Blog Déménageur de Sitefind . -type d -name "phpunit" -exec rm -rf {} \
Sur plusieurs installations, nous avons trouvé phpunit dans les répertoires suivants :
modules/autoupgrade/vendor/phpunit
modules/ps_facetedsearch/vendor/phpunit
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 :
La consommation indirecte, c’est l’électricité nécessaire pour faire fonctionner l’environnement du serveur :
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 Change, https://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
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
Si vous avez fait le choix de transférer votre système d’information sur le fameux « nuage », cet article peut vous intéresser :)
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 :
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 »
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 !
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 !
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
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…
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.
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.
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.
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 !
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.
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
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 !
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 !
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
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 :
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 :
La question initiale est parfois mal formulée par le client, ou le client ne s’adresse pas au bon interlocuteur.
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.
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é.
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.
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 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.
Commentaires récents