Serveur dédié : retirer Varnish, devenu inutile avec HTTPS photo

Serveur dédié : retirer Varnish, devenu inutile avec HTTPS

J’ai vraiment aimé jouer avec Varnish.

Le problème, c’est qu’en passant l’intégralité du site en HTTPS, il m’est devenu inutile.

Varnish est incompatible avec HTTPS et ne le sera probablement jamais puisque les connexions chiffrées ne doivent, par définition, jamais être mises en cache.

Par conséquent, j’ai décidé de le retirer temporairement du serveur : cela me fera un service de moins à gérer.

Notez que je ne le désinstalle pas, je m’assure juste qu’on ne fait pas appel à lui. Cela me permettra de le remettre en route si jamais j’héberge un jour un site en HTTP simple.

Ce tutoriel part du principe que vous avez suivi les tutoriels précédents et que votre serveur tourne avec Apache et Varnish comme reverse-proxy.

Configuration d’Apache

On doit éditer plusieurs fichiers :

1. le fichier /etc/apache2/ports.conf :

 nano /etc/apache2/ports.conf 

On remet les valeurs par défaut et on écoute sur le port 80 :

# If you just change the port or add more ports here, you will likely also
# have to change the VirtualHost statement in
# /etc/apache2/sites-enabled/000-default
# This is also true if you have upgraded from before 2.2.9-3 (i.e. from
# Debian etch). See /usr/share/doc/apache2.2-common/NEWS.Debian.gz and
# README.Debian.gz

# SkyMinds.Net
# Quand Varnish est actif
# NameVirtualHost *:8080
# Listen 8080

# Apache only
NameVirtualHost *:80
Listen 80


    # If you add NameVirtualHost *:443 here, you will also have to change
    # the VirtualHost statement in /etc/apache2/sites-available/default-ssl
    # to 
    # Server Name Indication for SSL named virtual hosts is currently not
    # supported by MSIE on Windows XP.

   NameVirtualHost *:443
   Listen 443



    Listen 443
Code language: PHP (php)

2. les fichiers de chacun de nos VirtualHosts :

nano /etc/apache2/sites-available/www.skyminds.net
nano /etc/apache2/sites-available/static.skyminds.netCode language: JavaScript (javascript)

On écoutait sur le port 8080, on se remet sur le port 80 :

#<virtualhost *:8080="">
<virtualhost *:80="">
Code language: HTML, XML (xml)

Lire la suite

Postfix : résoudre l'erreur SASL

Postfix : résoudre l’erreur “close database /var/lib/postfix/verify_cache.db: No such file or directory (possible Berkeley DB bug)”

postfix-logo

En jetant un oeil sur les logs du serveur du mail, je me suis aperçu que le même message d’erreur revenait à intervalles réguliers, entre quelques statistiques.

Il s’agit de Postfix qui donne le message suivant :

close database /var/lib/postfix/verify_cache.db: No such file or directory (possible Berkeley DB bug)Code language: JavaScript (javascript)

Selon le créateur de Postfix, ce n’est pas un bug mais juste un message sans conséquence. N’empêche que l’on peut s’en passer facilement.

Solution : ajouter address_verify_map à la configuration Postfix

Cette erreur survient lorsque le fichier de configuration Postfix n’est pas tout à fait complet.

Lire la suite

PHP : solution pour l'erreur

PHP : résoudre l’erreur “Redefining already defined constructor for class …”

php-logo

Il vous est peut-être déjà arrivé d’obtenir l’erreur PHP suivante en mode strict sous PHP 5.4 et versions ultérieures:

Redefining already defined constructor for class {nom_de_la_classe}

Cela arrive lorsque – dans le code d’une classe -, le code PHP4 précède le code PHP5 avec le constructeur de classe.

Le problème : une fonction PHP4 précédant le constructeur PHP5

Voici un petit exemple pour bien comprendre, avec une classe SkymindsExampleClass, une fonction qui s’appelle SkymindsExampleClass() et donc porte le même nom, et la fonction constructeur __construct().

L’exemple suivant produit l’erreur Redefining already defined constructor for class parce que la fonction PHP4 SkymindsExampleClass() se trouve avant la fonction PHP5 __construct() :

<?php
// This example outputs a PHP error in strict mode
class SkymindsExampleClass {
	//PHP4
	function SkymindsExampleClass()
	{
		$this->__construct();
	}
	//PHP5
	public function __construct()
	{
		$this->admin_page();
	}
}Code language: HTML, XML (xml)

La solution : placer le code PHP5 avant le code PHP4

Pour supprimer l’erreur PHP stricte, il suffit de placer la fonction PHP5 avant la fonction PHP4.

Lire la suite

MySQL : résoudre l'erreur

MySQL : résoudre l’erreur “mysql_connect(): Headers and client library minor version mismatch”

Après la mise à jour vers MySQL 5.6, certaines applications peuvent renvoyer l’avertissement PHP suivant :

PHP Warning: mysql_connect(): Headers and client library minor version mismatch. Headers:50535 Library:50617Code language: CSS (css)
icon-mysql

C’est le cas lorsqu’une application est liée à l’utilisation d’une version spécifique de libmysqlclient18 alors qu’elle est connectée à un serveur MySQL qui tourne sur une version différente.

C’est libmysqlclient18 qui renvoie cet avertissement mais dans certains cas, cela peut impacter l’application et tient plus de l’erreur que de l’avertissement.

MySQL Native Driver

La solution est toute simple : il suffit d’utiliser le pilote MySQL Native Driver php5-mysqlnd au lieu du paquet php5-mysql.

Les avantages de php5-mysqlnd sont multiples : il vient en remplacement de php5-mysql, n’est pas lié à la librairie libmysqlclient, ne renvoie pas d’avertissement “version mismatch” et possède pas mal d’autres caractéristiques intéressantes.

Lire la suite

Serveur dédié : configurer Postfix et Courier pour utiliser TLS-SSL en Perfect Forward Secrecy photo

Serveur dédié : configurer Postfix et Courier pour utiliser TLS-SSL en Perfect Forward Secrecy

Aujourd’hui, on va s’atteler à sécuriser le serveur de mail, géré par Postfix et Courier, pour utiliser notre certificat SSL et en ajoutant le Perfect Forward Secrecy.

Ce tutoriel part du principe que votre serveur tourne sous Debian et que vous avez suivi le tutoriel précédent sur Postfix avec gestion d’utilisateurs virtuels, c’est-à-dire que le serveur de mail doit déjà être opérationnel.

Vérification du fonctionnement du serveur de mail

On commence par vérifier que le serveur est capable d’envoyer des mails avec :

echo "test" | mail -s testsubject user@example.comCode language: PHP (php)

Si le mail est reçu, passez à l’étape suivante.

Configuration du certificat SSL

Nous allons concaténer la clé et le certificat pour Courier :

cd /etc/ssl
cat skyminds.net.key  skyminds_net.crt >> courier-key-crt-dh.pem

et on va y inclure un échange de clés Diffie-Hellman :

openssl dhparam 2048 >> courier-key-crt-dh.pemCode language: CSS (css)

On ajoute une autre clé DH en 2048 bits:

openssl gendh -out /etc/postfix/dh_2048.pem -2 2048

L’échange de clés Diffie-Hellman – du nom de ses auteurs Whitfield Diffie et Martin Hellman – est une méthode par laquelle deux personnes nommées conventionnellement Alice et Bob peuvent se mettre d’accord sur un nombre (qu’ils peuvent utiliser comme clé pour chiffrer la conversation suivante) sans qu’une troisième personne appelée Ève puisse découvrir le nombre, même en ayant écouté tous leurs échanges. Cela sécurise un peu plus l’échange.

Lire la suite

Linux : résoudre l'erreur SSH

Linux : résoudre l’erreur SSH “the RSA host key differs from the key for the IP address”

ssh

Au cours de mes errements avec le mode rescue, j’ai été obligé de m’identifier sur le serveur avec des identifiants temporaires différents de ceux que j’utilise habituellement.

J’ai retiré la clé habituelle, ajouté la nouvelle (celle du mode rescue), et maintenant, de retour sur ma session habituelle, SSH se plaint – à juste titre – que l’empreinte de la clé RSA du serveur a changé.

Problème : la clé RSA du serveur a changé

Dans ma précipitation à vouloir tout réparer, j’ai ajouté les identifiants temporaires de manière permanente au fichier /home/matt/.ssh/known_hosts.

Et, bien sûr, dès que j’ai voulu me connecter, j’ai obtenu ce message d’erreur :

Warning: the RSA host key for 'hostname' differs from the key for the IP address 'xxx.xxx.xxx.xxx'
Offending key for IP in /home/matt/.ssh/known_hosts:16
Matching host key in /home/matt/.ssh/known_hosts:11
Are you sure you want to continue connecting (yes/no)? Code language: JavaScript (javascript)

Lire la suite

J'ai planté le serveur... ou comment récupérer un serveur Kimsufi après un plantage de kernel avec le mode rescue OVH photo

Récupérer un serveur Kimsufi après un plantage de kernel avec le mode rescue OVH

J’ai lamentablement fait planter le serveur en voulant mettre le kernel à jour…

Heureusement, il existe le mode rescue chez OVH qui permet d’installer un linux provisoire sur le serveur et d’initier une connexion SSH pour que l’on puisse réparer le système.

Si jamais cela vous arrive, voici la marche à suivre.

Passage en mode rescue depuis le manager OVH

lifesaver

1. Aller sur le manager OVH > Dedicated > Infrastructure > clic sur votre serveur > clic sur l’onglet Server Status.

Lire la suite

Serveur dédié : passage au mod FastCGI et PHP-FPM avec Apache MPM Worker photo

Serveur dédié : passage au mod FastCGI et PHP-FPM avec Apache MPM Worker

Aujourd’hui, j’ai changé la manière dont Apache et PHP interagissent ensemble.

Concrètement, au lieu d’utiliser la configuration par défaut du serveur Apache, c’est-à-dire le module mod_php par défaut, le serveur utilisera dorénavant mod_fastcgi (fastcgi) avec PHP-FPM (FastCGI Process Manager).

PHP : mod_php vs mod_fastcgi

La raison principale pour laquelle mod_php utilise plus de ressources réside dans le fait que le module est chargé par le serveur même lors de requêtes pour des fichiers autres que PHP, comme des fichiers HTML ou des fichiers JavaScript.

debian-apache-php-fpm

FastCGI Process Manager (PHP-FPM) aide à réduire l’addition des ressources système utilisées en forçant le serveur à agir comme un proxy et à ne passer que les fichiers portant l’extension php à PHP-FPM.

Ce tutoriel assume que vous avez une installation Apache/PHP sous Debian qui tourne sous mod_php, c’est-à-dire une installation standard. Les changements prennent moins de 15 minutes.

Objectifs : gagner en rapidité d’exécution et avoir une installation plus légère. On peut ainsi envisager un jour de changer Apache pour un autre serveur tout en gardant la même configuration PHP.

Lire la suite

PHP : résoudre l'erreur

PHP : résoudre l’erreur Apache “child pid xxxx exit signal Segmentation fault (11)”

php-logo

J’ai découvert dernièrement qu’après une mise à jour du module php-apc, mes logs Apache étaient emplis de message d’erreur comme ceux-ci :

[Sun Nov 02 09:15:11 2014] [notice] child pid 5937 exit signal Segmentation fault (11)
[Sun Nov 02 09:17:36 2014] [notice] child pid 5586 exit signal Segmentation fault (11)
[Sun Nov 02 09:21:50 2014] [notice] child pid 6230 exit signal Segmentation fault (11)
[Sun Nov 02 09:21:51 2014] [notice] child pid 6388 exit signal Segmentation fault (11)
[Sun Nov 02 09:21:52 2014] [notice] child pid 6228 exit signal Segmentation fault (11)
[Sun Nov 02 09:21:53 2014] [notice] child pid 6235 exit signal Segmentation fault (11)
[Sun Nov 02 09:21:54 2014] [notice] child pid 6392 exit signal Segmentation fault (11)
[Sun Nov 02 09:21:55 2014] [notice] child pid 6385 exit signal Segmentation fault (11)Code language: CSS (css)

Cela en fait des erreurs !

Augmenter la taille de la limite de mémoire PHP

Sur le serveur, APC est configuré pour utiliser un unique segment de 128 Mo. Le problème, c’est que la directive memory_limit de PHP est elle aussi à 128 Mo. Par conséquent, il convient d’augmenter cette dernière :

1. On édite notre fichier de configuration PHP :

nano /etc/php5/apache2/php.ini

2. On recherche (Ctrl + w) le mot clé memory_limit et on remplace:

; Maximum amount of memory a script may consume (128MB)
; http://php.net/manual/en/ini.core.php#ini.memory-limit
memory_limit = -1Code language: JavaScript (javascript)

par

; Maximum amount of memory a script may consume (128MB)
; http://php.net/manual/en/ini.core.php#ini.memory-limit
; memory_limit = -1
memory_limit = 256MCode language: JavaScript (javascript)

3. On enregistre la nouvelle configuration et on relance Apache :

service apache2 restart

Vérifiez maintenant les logs Apache. Cela peut ne pas être suffisant.

Désinstaller APC

Dans mon cas, avec PHP 5.4.x, APC semble générer ces erreurs de manière aléatoire. J’ai donc désactivé APC avec :

apt-get remove php5-apcCode language: JavaScript (javascript)

Après relance du serveur Apache et analyse des logs, la situation est revenue à la normale :

Apache PHP/5.4.34 configured -- resuming normal operations

Le problème viendrait donc d’APC et de PHP 5.4 – il est important de noter que PHP 5.5 contient déjà un optimiseur de code intégré (Zend) donc à la prochaine mise à jour majeure de PHP, il sera inutile d’installer APC.

Serveur dédié : installer et configurer Varnish 4 photo

Serveur dédié : installer et configurer Varnish 4

Cette semaine, j’ai décidé de mettre mon installation de Varnish à jour.

La version 3.0.5 date de décembre 2013 et il est temps de mettre le serveur à jour pour bénéficier des dernières nouveautés et corrections de bugs. Nous passons donc de Varnish 3 à Varnish 4.

Cela ne se fait pas sans peine car chez Varnish, ils renomment certaines directives d’une version à l’autre… ce qui fait planter le serveur Varnish puisqu’il ne reconnait plus les directives.

Résultat : le fichier de configuration de la version précédente plantera obligatoirement sous la dernière version !

Ce tutoriel en 3 étapes nous donnera l’occasion de mettre à jour Varnish et de scinder notre fichier de configuration en plusieurs modules de manière à en simplifier l’édition et la maintenance futures.

Etape 1 : mise à jour des dépôts Varnish

Pour mettre à jour Varnish, il suffit de pointer apt vers les derniers dépôts à jour. On édite donc /etc/apt/sources.list :

nano /etc/apt/sources.listCode language: PHP (php)

et on y met à jour nos dépôts:

# varnish
deb http://repo.varnish-cache.org/debian/ wheezy varnish-4.0Code language: PHP (php)

On rafraîchit la liste des paquets et on lance la mise à jour :

apt-get update && apt-get upgradeCode language: JavaScript (javascript)

Varnish est maintenant mis à jour mais loin d’être fonctionnel étant donné que le format du fichier de configuration a changé.

Etape 2 : le nouveau fichier de configuration de Varnish 4 pour WordPress

Certaines directives ont changé de nom et, malgré avoir lu le guide de migration officiel, j’ai modifié mon fichier de configuration en corrigeant les erreurs une à une. Cela prend du temps mais au final, le fichier est plus clair qu’avant.

Lire la suite

PHP: résoudre l'erreur

PHP : résoudre l’erreur “it is not safe to rely on the system’s timezone settings”

php-logo

Voici le message d’erreur PHP qui est apparu récemment dans mes logs Apache :

PHP Warning: strtotime(): It is not safe to rely on the system’s timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone ‘UTC’ for now, but please set date.timezone to select your timezone.

Ajout de la directive date.timezone dans php.ini

On commence par trouver le fichier php.ini qui est actuellement utilisé par le serveur. Il en existe plusieurs, suivant les modules activés donc on commence par repérer le bon avec :

php -i | grep 'Configuration File'Code language: JavaScript (javascript)

Résultat :

Configuration File (php.ini) Path => /etc/php5/cli
Loaded Configuration File => /etc/php5/cli/php.ini
PHP Warning:  Unknown: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone. in Unknown on line 0Code language: JavaScript (javascript)

Effectivement, l’erreur est répétée même dans un simple phpinfo(). On édite donc notre fichier :

nano /etc/php5/cli/php.ini

La page de manuel des timezones nous indique toute la liste des fuseaux horaires disponibles. Nous choisissons celle qui correspond à l’emplacement de notre serveur : ‘Europe/Paris’.

On recherche la bonne directive avec Ctrl + W et en tapant :

date.

On trouve alors :

[Date]
; Defines the default timezone used by the date functions
; http://php.net/manual/en/datetime.configuration.php#ini.date.timezone
;date.timezone =Code language: JavaScript (javascript)

qu’il faut modifier en :

[Date]
; Defines the default timezone used by the date functions
; http://php.net/manual/en/datetime.configuration.php#ini.date.timezone
date.timezone = 'Europe/Paris'Code language: JavaScript (javascript)

On relance Apache pour prendre en compte la nouvelle configuration :

service apache2 restart

Lire la suite

Serveur dédié : configurer Transmission pour accéder au WebUI via TLS-SSL photo

Serveur dédié : configurer Transmission pour accéder au WebUI via TLS-SSL

TLS est activé sur notre serveur Apache, WordPress sert désormais ses pages avec une connexion chiffrée et Webmin se sert de notre certificat SSL.

Aujourd’hui, je cherche à lancer le client bittorent Transmission et… je tombe sur un message d’erreur qui m’empêche d’accéder son interface web : “Error code: ssl_error_rx_record_too_long”.

transmission-icon

Voici donc comment corriger le problème et afficher l’interface Web de Transmission en HTTPS. Ce tutoriel prend moins de 10 minutes à réaliser.

Erreur : “SSL received a record that exceeded the maximum permissible length”

Le premier message d’erreur sur lequel je tombe est le suivant :

Secure Connection Failed

An error occurred during a connection to www.example.com:9091. SSL received a record that exceeded the maximum permissible length. (Error code: ssl_error_rx_record_too_long)

Je commence par vérifier le fichier de configuration de Transmission et m’aperçoit assez rapidement qu’il ne sera d’aucun secours.

Une recherche sur le net m’informe qu’il faut probablement voir du côté de la configuration Apache – qui ne contenait jusqu’alors aucune référence à Transmission.

Plusieurs essais de configuration plus tard, l’erreur se transforme en erreur 409.

Erreur “409: Conflict”

Le second message auquel je me heurte est le suivant :

409: Conflict

Your request had an invalid session-id header.

To fix this, follow these steps:

When reading a response, get its X-Transmission-Session-Id header and remember it
Add the updated header to your outgoing requests
When you get this 409 error message, resend your request with the updated header

This requirement has been added to help prevent CSRF attacks.

C’est la première fois que je tombe sur une erreur 409, je suis plutôt content. Je continue donc de tester diverses directives Apache jusqu’à trouver la bonne recette pour faire fonctionner le client web UI de Transmission over SSL.

Lire la suite