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
Suite à l’article précédent, on dispose maintenant, grâce aux mécanismes de cache de W3 Total Cache (W3TC), d’un site WordPress relativement bien optimisé et résistant aux pannes PHP/MySQL. Il ne reste plus maintenant qu’à précharger ce cache afin qu’une version de chaque page y soit déjà présente à chaque nouvelle visite. Ce point est particulièrement important avec les paramètres « Inline CSS minification » et « Inline JS minification » qui assomment le CPU avec, sur ce blog, 6 à 8s pour générer la page d’accueil.
Lire la suite
Ce post continue le précédent sur l’optimisation de WordPress avec Nginx et W3 Total Cache (W3TC). Après avoir passé une configuration standard et vérifié le bon paramétrage de la compression Gzip, il est temps de passer à la configuration de W3TC. Est-il besoin de rappeler que c’est le bon moment pour réaliser un back-up de la de données? A priori les opérations suivantes sont sans danger, mais on ne sait jamais.
Lire la suite
WordPress est un outil de blog très populaire, mais il faut le reconnaître tel quel, il est très consommateur de ressource. L’affichage des pages est abominablement lent même sur un site à faible trafic sur un serveur robuste. Ce post va donc présenter des optimisations très efficaces qui permettront à la fois de descendre à un affichage de pages sous la demi-seconde et de permettre à votre serveur d’encaisser un trafic plus important. Je me sers ici de W3 Total Cache (W3TC) qui est assez bon, on peut lui préférer WP Super Cache, pourquoi pas, mais la configuration de Nginx sera différente.
OS : Debian 7.5 stable (Wheezy) (64bits)
Nginx : nginx/1.6.0
PHP : 5.5.12-1 avec Zend Engine v2.4.0 et Zend OPcache v7.0.4
W3 Total Cache : Version 0.9.4 avec les paramètres suivants
J’ai donc passé une mise à jour du package php5-fpm tout à l’heure. Généralement, c’est relativement sans risque. Sauf que mes sites web affichaient ensuite une erreur 502 !
Un tour rapide sur les logs d’erreurs de nginx donne:
1 | 2014/05/10 17:45:19 [crit] 17131#0: *1 connect() to unix:/var/run/php5-fpm.sock failed (13: Permission denied) while connecting to upstream, client: xx.xxx.xxx.xx, server: phil.writesthisblog.com, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "phil.writesthisblog.com" |
Je vais donc consulter le site qui gère les repositories et effectivement :
Please note that if you’re using an Unix socket to make PHP-FPM talk to your web server, you’ll have to set the listen.owner and listen.group directive to the right user/group (usually www-data), for each of your pool. Don’t change the permissions on the socket from 0660 to 0666 (too permissive), it would avoid the CVE-2014-0185 fix.
La solution consiste donc à dé-commenter les lignes listen dans /etc/php5/fpm/pool.d/www.conf:
1 2 3 4 5 6 7 8 9 | root@server:~# cat /etc/php5/fpm/pool.d/www.conf | grep -A 7 for\ unix\ socket ; Set permissions for unix socket, if one is used. In Linux, read/write ; permissions must be set in order to allow connections from a web server. Many ; BSD-derived systems allow connections regardless of permissions. ; Default Values: user and group are set as the running user ; mode is set to 0660 listen.owner = www-data listen.group = www-data listen.mode = 0660 |
Il ne reste plus qu’à recharger php5-fpm avec un service php5-fpm restart.
Bilan, 20 min d’interruption du site (et encore), ce n’est pas un drame. Mais il faut toujours se méfier des mises à jour automatiques. Mieux vaut les limiter au strict minimum (sécurité) et passer régulièrement sur son serveur appliquer les autres à la main. En cas de crash, on peut intervenir rapidement et on a une idée de l’origine du problème. Idéalement, on dispose d’un serveur de maquette sur lequel on test chaque manipulation, mais il s’agit de moyens plus généralement mis en œuvre sur des infrastructures professionnelles. Sur un serveur personnel, c’est moins évident…
Ce post présente UFW un outil simplifié de configuration d’iptable sur son serveur dédié, il est disponible sur les distributions Ubuntu et Debian. Pour rappel, iptables, et ip6tables pour l’IPv6, sont deux outils d’administration du module netfilter au sein du noyau qui permettent la manipulation des paquets IP. Ces deux utilitaires sont extrêmement puissants et utilisés principalement pour
Toute bonne administration d’un serveur linux passe donc par la maîtrise d’iptables, et soyons honnêtes ce n’est pas un outil simple prendre en main. Comme souvent sur internet, on trouvera beaucoup trop de tuto qui sont soit mauvais soit simplistes, et dans tous les cas, on voit toujours trop de gens qui
Pourtant, UFW propose une solution simple pour tous les débutants ou les plus flemmards qui n’ont pas envie de passer une journée à configurer/débuguer leur config iptables. Si la prise en main est aisée, UFW conserve la polyvalence d’iptables en permettant d’intégrer les règles les plus complexes.
Lire la suite