Ce post présente la mise à jour d’une Debian Wheezy vers Jessie. Il s’appuie sur la documentation officielle de Debian et en est une version raccourcie. Mais ce n’est pas pour autant une raison de ne pas aller la lire.
Faites avant tout un backup des données du serveur et prévoyez 2 ou 3 heures en partant du principe que vous allez devoir tout réinstaller. Normalement, tout devrait bien se passer, mais on n’est jamais trop prudent… Lire la suite →
Un des gros problèmes souvent rencontré dans l’administration d’un système est la mise à jour. Combien de fois peut-on voir sur les forums quelqu’un se plaindre de s’être fait hacker son serveur et, dans le même temps, avouer benoîtement ne pas en avoir passé une seule depuis l’installation ! Les différentes distributions mettent pourtant en place des système de gestion des packages (yum ou apt), mais on n’a pas forcément toujours le temps de régulièrement se connecter sur son ou (surtout) ses serveurs pour s’en occuper.
Pour résoudre ce problème, Debian, mais aussi Ubuntu, proposent un package, unattended-upgrade, permettant d’automatiser les mises à jour. Ce n’est pas la panacée, une mise à jour présente toujours le risque de casser quelque chose et mieux vaut toujours les passer manuellement, mais c’est toujours mieux que de rien faire. Lire la suite →
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…
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 →
Voici un script sympa que j’utilise pour faire des backups de mon système. rien de bien original et j’avoue m’être pas mal inspiré d’exemples divers sur internet. Je crois qu’on ne rappellera jamais la nécessité de réaliser des backups. Un jour ou l’autre, vous pouvez faire une fausse manip, ou tout simplement les disques durs de votre serveur seront morts (même en raid 1 ça arrive !) ou encore votre base de données sera irrémédiablement corrompue. Ce jour là, vous serez plus qu’heureux d’avoir mis en place un système de backup régulier. Mais avant de commencer, quelques pré-requis :