Auteur/autrice : Fabien

Impossible de démarrer Elasticsearch après un downgrade

Je suis en train de préparer la migration d’un boutique sous Magento 1.9 vers Magento 2.3 et une des grandes nouveautés de cette version est la prise en charge en natif du moteur de recherche Elasticsearch.


J’ai installé la dernière version stable d’ES pour CentOS 7, soit la version 7.5, mais j’ai rencontré des problèmes avec Magento 2.3.3, car celui-ci ne prend en charge officiellement que la version 6 d’ES. J’ai donc downgradé ce dernier en version 6.8.6, mais un nouveau problème est survenu : impossible de démarrer le moteur de recherche.

Je n’ai plus le message d’erreur exact rencontré dans le fichier de log /var/log/elasticsearch/elasticsearch.log, mais c’était quelque chose comme :

failed to open /var/lib/elasticsearch/node/0

Après quelque recherche, il s’avère que lors de la mise à jour vers une version plus ancienne, le répertoire data doit être supprimé pour que la version 6 fonctionne et démarre correctement.

Ainsi après la suppression de la version 7.x avec yum remove elasticsearch, il faut supprimer le répertoire /var/lib/elasticsearch, puis installer la version 6.x. Et là, plus de problème, ES démarre et fonctionne.

Pour installer Elasticsearch sous CentOS ou tout autre distribution, c’est ici : https://www.elastic.co/guide/en/elastic-stack/current/index.html

Installer plusieurs versions de PHP avec les Software Collection sous CentOS 7

Les Software Collection (SCL) permettent d’installer plusieurs versions d’un programme sur un même système, c’est le choix parfait pour avoir plusieurs versions de PHP installées sur un même serveur web.


Ajouter PHP 7.3 à mon serveur

Sur mon serveur web Nginx, je possède plusieurs versions de PHP, notamment un vieux PHP 5.4 pour de vieux projets et PHP 7.0. Je veux mettre à jour mes sites en PHP 7.3 avec les SCL.

Installation de PHP 7.3

yum install php73

L’installation est maintenant faite dans le répertoire /opt/remi/php73, la configuration quant à elle est dans /etc/opt/remi/php73.

Pour installer d’autres modules PHP 7.3, il faut le faire en préfixant les paquets par php73-, comme ceci :

yum install php73-php-json php73-php-pecl-memcached php73-php-xml php73-php-fpm php73-php-mcrypt php73-php-mbstring php73-php-pecl-mysql php73-php-pdo php73-php-pecl-igbinary php73-php-mysqlnd php73-php-gd php73-php-tidy

Configuration du pool de PHP FPM

La configuration du pool se fait dans le fichier /etc/opt/remi/php73/php-fpm.d/www.conf. Par défaut FPM écoute sur un socket TCP, moi j’utilise un socket UNIX, voici le contenu des parties éditées du fichier www.conf, le reste ne change pas :

user = nginx
group = nginx
listen = /var/opt/remi/php73/run/php-fpm/www.sock
listen.owner = nginx
listen.group = nginx
listen.mode = 0666

Je démarre le service PHP FPM pour PHP 7.3 et je l’active au démarrage du serveur :

systemctl start php73-php-fpm
systemctl enable php73-php-fpm

Pour rappel, voici la partie relative à PHP FPM de la configuration d’un server Nginx :

location ~ \.php$ {
        include                         fastcgi_params;
        fastcgi_intercept_errors        on;
        fastcgi_read_timeout            240s;
        fastcgi_pass                    unix:/var/opt/remi/php73/run/php-fpm/www.sock;
        fastcgi_index                   index.php;
        fastcgi_param                   SCRIPT_FILENAME  $document_root	$fastcgi_script_name;
}

Tout site avec cette configuration fastCGI devrait désormais fonctionner avec PHP 7.3.

MySQL/MariaDB : Déterminer la taille recommandée de innodb_buffer_pool_size

Rapide mémo pour déterminer la taille recommandée du buffer pour les tables utilisant le moteur de stockage InnoDB de MySQL. Par défaut après installation cette valeur est en général à 128 Mo, ce qui peut être bien bas pour de grosses bases de données.


La requête ci-dessous retourne la taille à renseigner pour la valeur de la variable innodb_buffer_pool_size :

SELECT 
	CEILING(Total_InnoDB_Bytes*1.6/POWER(1024,3)) RIBPS 
FROM (
	SELECT 
		SUM(data_length+index_length) Total_InnoDB_Bytes
	FROM information_schema.tables 
	WHERE engine='InnoDB'
) A;

Il suffit alors de renseigner cette valeur dans le fichier de configuration /etc/my.cnf :

[mysqld]
innodb_buffer_pool_size=8G

Redémarrer MySQL/MariaDB :

$ sudo systemctl restart mariadb

Sécuriser Memcached pour éviter des attaques par amplification

J’utilisais Memcached depuis des années sans soucis. Jusqu’à ce début de semaine.

Il aura fallu une méchante attaque sur un serveur de production pour mettre celui-ci à genoux (et le site d’e-commerce sous Magento qu’il hébergeait) à cause d’un Memcached mal configuré.


Pour les détails techniques de ce type d’attaque par amplification visant Memcached, se reporter à cet article sur le blog de CloudFlare : Memcrashed – Major amplification attacks from UDP port 11211.

Sécuriser Memcached

Par défaut Memcached écoute sur toute les interfaces et sur le protocole UDP. Il faut donc désactiver UDP et le faire écouter seulement en localhost :

$ sudo vim /etc/sysconfig/memcached

Ajouter (ou adapter) ceci dans le champ OPTIONS :

OPTIONS="-l 127.0.0.1 -U 0"

Redémarrage de Memcached :

$ sudo systemctl restart memcached

Vérification que Memcached écoute bien seulement 127.0.0.1 en TCP :

$ sudo netstat -plunt
(...)
tcp 0 0 127.0.0.1:11211 0.0.0.0:* LISTEN 31938/memcached