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.
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…
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
mettre en place des règles de filtrage des paquets IP (firewall)
partager une connexion internet (NAT)
l’historisation du trafic réseau (log)
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
pensent qu’ils n’ont pas besoin d’iptables puisque leur serveur fonctionne… pour le moment
débarquent sur les forum paniqués, leur serveur venant d’être hacké ou fermé car il a servi pour un DDoS
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 →
Quand je parlais des abrutis qui pratiquent le DDoS dans un précédent post, je ne pensais pas être tombé sur un cas. Mon serveur subit maintenant un DDoS depuis le 28 avril!!
Pour résumer rapidement, l’abruti en question s’est fait bannir du serveur TeamSpeak par les admins (hasard) et pas de chance pour lui, son IP étant statique, il ne peut vraiment plus revenir. Estimant que sa présence ne pouvait que nous manquer, il en est rapidement venu aux menaces de DDoS si son ban n’était pas levé. Les menaces étant sans résultats, il a décidé de nous démontrer ses compétences techniques… et utiliser son compte paypal pour payer un site tel que Titanium et nous « punir ». Lire la suite →
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 →
