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.
Environnement
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
Page Cache – Disk Enhanced
Minify – Disk ou Désactivé (le Minify peut massacrer des thèmes mal codés)
Database Cache – Memcache ou Alternative PHP Cache (APC)
Object Cache – Memcache ou Alternative PHP Cache (APC)
Browser Cache – Désactivé (on laisse Nginx le gérer)
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:
Dans les logs d'erreur de Nginx
1
2014/05/1017: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"
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:
pool www de php5-fpm
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
;permissions must be set inorder toallow connections fromaweb server.Many
;BSD-derived systems allow connections regardless of permissions.
;DefaultValues:user andgroup are set asthe running user
;mode isset to0660
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…
Le but de ce post est de déployer sur son serveur dédié une seedbox. Pour ceux qui ne connaissent pas, une seedbox est un serveur privé utilisé pour le partage de fichiers numériques. L’avantage d’utiliser un serveur dédié est de disposer d’une bande passante importante (100Mbps ou plus) et symétrique, ce qui permet des chargements et/ou de diffuser (seed) ses propres fichiers très rapidement. Je sais on trouve déjà pas mal de tutos sur le net, mais là il s’agit de ne pas faire les choses à moitié. Je propose ici de mettre en place :
le tout sécurisé par contrôle d’accès et chiffrement SSL
Et afin de créer le meilleur tuto possible, toutes les configurations ont été passées sur un VPS Classic d’OVH à 2.39€ par mois fraîchement installé. J’ai même utilisé Dyn pour faire pointer le dns seedbox-bt.writesthisblog.com sur le VPS. Ne cherchez pas, au moment où vous lirez ces lignes, le domaine n’existera plus et le vps aura été reformaté. En attendant, soyez assuré que toute la configuration fonctionne, au nom de domaine près que vous aurez à changer bien évidemment. Question performances, j’ai obtenu sans problème des pointes de download à 12Mo/s, tout dépend, bien sûr, de la popularité du torrent. Lire la suite →
Comme promis, après avoir installé TeamSpeak 3, il est maintenant temps de mettre en place une interface web de gestion qui simplifie grandement l’administration de son serveur. Elle est un peu brute, mais elle reste quand même beaucoup plus simple, pour gérer rapidement les instances de son serveur, que la ligne de commande du ServerQuery. Lire la suite →
La nature humaine étant ce qu’elle est, particulièrement sur internet, il est de plus en plus indispensable de pouvoir chiffrer ses communications et authentifier le serveur avec lequel on échange. Le protocole SSL répond à ce besoin mais il nécessite de disposer au préalables de certificats.
Il faut savoir qu’il existe deux type de certificats SSL. Ceux qui sont signés par une autorité de certification (CA) comme Verisigns ou Thawte, minimum 50€ par an ou plus, et ceux auto-signés et gratuits. Le signataire étant censé être un tiers de confiance garantissant la validité du certificat, on comprend que cela peut poser problème dans le cas des certificats auto-signés. Ceci dit, pour un usage personnel, vous pourrez raisonnablement supposer, sauf à être schizophrène, que vous pouvez faire confiance à vous même et au certificat que vous avez auto-signés.
Je propose donc, dans ce post, un script qui permet de générer rapidement une clé privée RSA de 2048 bits et un certificat auto-signé. Je donne aussi quelques explications qui, une fois le certificat créé, permettront de le mettre en place sur votre serveur web préféré (nginx). Lire la suite →
Nginx est un serveur web concurrent d’Apache très populaire, mais il est bien plus encore. Il peut aussi être utilisé comme reverse-proxy, load-balancer, terminaison ssl etc. Personnellement, je le trouve bien plus simple et cohérent à configurer qu’Apache. Ce post va proposer et expliquer une configuration basique pour faire tourner nginx avec du php sous Debian.
Concernant les configurations que l’on peut trouver dans les tutos sur internet, j’appellerai à la plus grande méfiance (à commencer par le mien) ! Pour vous en convaincre, je vous conseille de faire un tour sur la page des pièges de config du wiki nginx. La erreurs référencées se retrouvent fréquemment dans la plupart des tutos quand ces derniers n’utilisent pas des éléments de config obsolètes. Bien évidemment, je m’inspire des docs officielles (ici et là) pour mes propres configurations. Lire la suite →