Redirection des Requêtes http vers https
Bien souvent, on souhaite disposer d’un serveur web exclusivement en https. Se pose alors le problème de gérer les requêtes http, généralement, on préfère une redirection en https.
Lire la suite
Bien souvent, on souhaite disposer d’un serveur web exclusivement en https. Se pose alors le problème de gérer les requêtes http, généralement, on préfère une redirection en https.
Lire la suite
Je viens de tomber sur LoadImpact, un site sympa pour tester en charge son serveur web. La version gratuite mise à disposition est bien sûr limitée, mais elle permet déjà de se faire une idée. Le résultat complet est disponible en ligne et c’était l’occasion de voir la solidité de mes optimisations.
Malheureusement, sans s’enregistrer et/ou payer il n’est pas possible de monter la charge ou de mener des tests plus fins. Mais j’ai pu constater que :
Nginx peut donc certainement encore encaisser une charge très supérieure. Vu le trafic de mon blog, j’ai de quoi voir venir !
Cet article cherche à répondre à une question qui m’a été adressée sur ce site sur une solution de backup d’ESX sur un serveur SYS. Malheureusement, après 4 ans d’hébergement gracieux en datacenter, j’ai dû récemment rendre l’espace et de-commissionner mon ESXi 4.1. Je n’ai donc pas les moyens, contrairement aux autres articles, de monter rapidement et à peu de frais une infrastructure de test et il s’agit plus d’une présentation de quelques idées pour améliorer le backup d’un ESX en standalone.
Lire la suite
Quand on cherche à optimiser son site web, on se voit souvent conseiller d’utiliser des CDN de librairies JavaScript, par exemple Google Hosted Libraries. C’est une bonne idée, a priori, elles permettent :
C’est du moins la théorie. Dans la pratique, conserver les librairies sur son propre serveur permet d’être certain qu’elles seront toujours disponibles, en tous cas, au moins autant que son propre site. J’utilise HighCharts intensivement pour un autre WordPress et aujourd’hui mauvaise surprise, quelques uns de mes graphiques ne fonctionnaient plus… Après vérification du code, j’avais oublié de remplacer les url des libraires highcharts par celles hébergées sur mon serveur.
1 2 3 4 5 6 | <script src="http://code.highcharts.com/3.0.8/adapters/standalone-framework.js"></script> <script src="http://code.highcharts.com/3.0.8/highcharts.js"></script> <script src="http://code.highcharts.com/3.0.8/highcharts-more.js"></script> <script src="http://code.highcharts.com/3.0.8/modules/exporting.js"></script> <script src="http://code.highcharts.com/3.0.8/modules/no-data-to-display.js"></script> <script src="http://cloud.highcharts.com/resources-0.1.2/js/data.src.js"></script> |
Je ne sais pas très bien pourquoi, mais l’url de la ligne 6 ne fonctionne plus depuis 2 jours (au moins) et renvoie le message d’erreur » The chart could not be found. » au lieu du JS. Et pourtant, cette url était utilisée par le site cloud.highcharts.com
dans ses templates !
Bref, je ne suis pas en train de dire qu’il ne faut pas utiliser ces CDN de librairies. Comme toutes optimisations, elles ont leurs avantages et inconvénients, mais les utiliser à l’aveugle, sans s’être demandé si son site pouvait en bénéficier réellement, est absurde.
Comment configurer le serveur par défaut sous nginx surtout dans un environnement de « virtual host » ? Généralement, on attend de son serveur web le comportement suivant :
Opcache-status et Opcache-gui sont deux interfaces très pratiques pour superviser l’état de Zend Opcache. Elles permettent de mieux comprendre son fonctionnement et d’en améliorer le paramétrage. Elles sont toutes les deux assez similaires, à ceci près qu’Opcache-gui est un peu plus détaillée et permet de vider le cache, ce qui s’avère utile lors de tests.
Bien évidemment, il est nécessaire d’avoir avant installé et activé Zend Opcache !
Lire la suite
Cet article présente l’installation de phpMyAdmin dans une zone d’administration sécurisée dont la base est présentée dans l’introduction de cette série. Est-ce la peine de présenter phpMyAdmin ? Il s’agit d’une interface web d’administration de ses bases de données MySQL. Elle permet d’exécuter, facilement et sans grandes connaissances, de nombreuses requêtes, d’effectuer la plupart des tâches administratives comme la sauvegarde/restauration des bases, etc.
La plupart des distributions linux (Debian, Ubuntu, Fedora, etc.) disposent du package, alors quel est l’intérêt d’installer depuis les sources ? Bien souvent, les versions fournies ne sont pas les plus à jours. De plus on ne maîtrise pas vraiment les répertoires d’installation et leur intégration dans l’architecture globale de son serveur web. rien ne remplace donc une installation customisée pour ses besoins.
Lire la suite
Zend Opcache (ex Zend Optimizer+) est un accélérateur PHP et il fonctionne plutôt bien. Comment ? Il faut savoir que les scripts PHP doivent être compilés en PHP bytecode à chaque exécution, et on constate pour cette raison des temps de réponse de l’ordre de 500ms sur un back-end PHP faisant tourner un WordPress. Zend Opcache stocke et optimise ce code compilé pour une ré-utilisation ultérieure. Et il est plutôt performant.
Zend Opcache est compatible avec PHP depuis la version 5.2 et y est même intégré depuis la 5.5. Malheureusement il n’est pas disponible sur Debian (Wheezy en 7.5) à l’heure actuelle. Alors comment faire ?
Lire la suite
Cette série d’article propose d’expliquer l’installation d’un ensemble d’outils d’administrations web bien pratiques qui aident à la gestion de son serveur tout en en sécurisant l’accès. Ce dernier point est critique, en effet combien de fois peut-on voir des phpMyAdmin installés directement dans le sous répertoire d’un site web ? Bien évidemment, ces installations simplistes sont la cible de scanners sur internet qui les recherchent pour leurs vulnérabilités connues.
Cette introduction pose donc les bases d’une installation sécurisée et sera suivi par d’autres articles expliquant comment implémenter différents outils pratiques que j’ai pu trouver comme phpMyAdmin, Cacti, munin, etc.
Lire la suite
Pendant la rédaction de la précédente série d’articles, je dois avouer avoir passé du temps à débuguer ma configuration Nginx. Bien sûr, le premier réflexe est de passer son error_log
en debug. Mais il n’apporte qu’une aide limitée, et il est toujours aussi difficile de savoir quel est le comportement exact de Nginx ou pourquoi cette damnée regex ne fonctionne pas exactement comment il faut.
Lire la suite