BASH : supprimer les fichiers de session PHP obsolètes photo

BASH : supprimer les fichiers de session PHP obsolètes

Je vous ai déjà parlé du problème des fichiers de session PHP.

Or, je me suis aperçu que le problème n’est toujours pas réglé sous Debian : les fichiers de session de PHP ne sont jamais effacés et cela finit par saturer la partition /root.

Sur le serveur, ces fichiers prenaient 590 Mo, ce qui est énorme vu que ces fichiers ont la taille d’un fichier de cookies. Il y en a donc des milliers, dans un seul répertoire, ce qui consomme un maximum d’inodes.

A oneliner to rule ’em all

Voici le nombre d’inodes avant de lancer la commande de nettoyage :

df -i

Résultat:

Filesystem     Inodes IUsed IFree IUse% Mounted on
/dev/root        640K  212K  429K   34% /
devtmpfs         487K  1.5K  486K    1% /dev
tmpfs            487K   864  487K    1% /run
tmpfs            487K     4  487K    1% /run/lock
tmpfs            487K     2  487K    1% /run/shm
/dev/sda2         44M   75K   43M    1% /home

Voici donc comment régler le problème en une seule ligne, dans le terminal. On supprime tous les fichiers de sessions qui existent depuis plus de 24 minutes (TTL par défaut de PHP) :

find /var/lib/php/sessions -type f -cmin +24 -name 'sess_*' | xargs rm

Notez la rapidité d’exécution de la commande, grâce à xargs.

On relance le calcul d’inodes:

df -i

Résultat:

Filesystem     Inodes IUsed IFree IUse% Mounted on
/dev/root        640K   88K  553K   14% /
devtmpfs         487K  1.5K  486K    1% /dev
tmpfs            487K   864  487K    1% /run
tmpfs            487K     4  487K    1% /run/lock
tmpfs            487K     2  487K    1% /run/shm
/dev/sda2         44M   75K   43M    1% /home

Boom : 20% d’inodes en plus. Pas mal, surtout que ces sessions sont expirées depuis belle lurette et auraient dues être supprimées depuis bien longtemps.

Crontab pour supprimer les fichiers de session PHP

Le mieux reste encore de créer une tâche cron qui va vérifier chaque jour que le répertoire de sessions ne se remplit pas inutilement.

Nous allons toutefois faire les choses avec un peu plus de finesse : chercher le chemin de stockage des sessions ainsi que la durée de vie des sessions et supprimer chaque jour les fichiers expirés.

On crée notre script bash:

nano /etc/scripts/cleanup-php-sessions.sh
#!/bin/bash
# Script Name : cleanup-php-sessions.sh
# Author : Matt Biscay
# Author URL :  https://www.skyminds.net/?p=28992
# Hire me : https://www.skyminds.net/hire-me/

# Export bin paths
export PATH=$PATH:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# Get PHP Session Details
PHPSESSIONPATH=$(php -i 2>/dev/null | grep -w session.save_path | awk '{print $3}' | head -1);
PHPSESSIONLIFETIME=$(php -i 2>/dev/null | grep -w session.gc_maxlifetime | awk '{print $3}' | head -1);
PHPSESSIONLIFETIMEMINUTE=$( expr $PHPSESSIONLIFETIME / 60 );

# If PHPSESSIONPATH exists
if [ -d $PHPSESSIONPATH ];
then
    # Find and delete expired sessions files :

	# Sluggish way
	#find $PHPSESSIONPATH -type f -cmin +$PHPSESSIONLIFETIMEMINUTE -name "sess_*" -exec rm -f {} \;

	# Quick way
	find $PHPSESSIONPATH -type f -cmin +$PHPSESSIONLIFETIMEMINUTE -name 'sess_*' | xargs rm
fi

Il ne reste plus qu’à l’activer:

crontab -e

et on lance le script tous les jours à minuit :

@daily sh /etc/scripts/cleanup-php_sessions.sh #Cleanup PHP sessions daily

Et voilà, mine de rien, vous venez de vous enlever une future épine du pied.

C’est typiquement le genre de fichiers que l’on ne surveille pas et qui peuvent un jour poser problème, notamment au niveau des inodes.

Serveur dédié : installer NginX avec support HTTP2 et certificat SSL, PHP, MariaDB sous Debian photo

Serveur dédié : installer NginX avec support HTTP2 et certificat SSL, PHP, MariaDB sous Debian

Aujourd’hui, nous sautons le pas et passons du serveur Apache au serveur NginX (à prononcer “engine X”) pour booster les performances générales du site.

Serveur dédié : installer NginX avec support HTTP2 et certificat SSL, PHP, MariaDB sous Debian photo

Cela fait quelques serveurs que je monte pour d’autres en utilisant nginx et force est de constater que c’est beaucoup plus réactif qu’Apache et cela prend moins de temps à configurer pour optimiser les réglages.

Je pars du principe que c’est une nouvelle installation mais si vous aviez déjà votre site qui tournait sous Apache, certaines étapes seront juste optionnelles.

Ce tutoriel vise un serveur Debian mais est adaptable sans problème à ses dérivés comme Ubuntu ou Mint.

Etape 1 : NginX

Nous allons installer la dernière version du serveur nginx, avec le support pour HTTP2, depuis les dépôts Sury :

nano /etc/apt/sources.list

et nous ajoutons :

# SURY, post-Dotdeb
deb https://packages.sury.org/php/ stretch main
deb https://packages.sury.org/nginx-mainline/ stretch main
deb https://packages.sury.org/mariadb/ stretch main

On rafraîchit les dépôts :

apt update

et on installe nginx et openssl :

apt install nginx openssl libssl1.0.2 libssl1.0.1 libssl-dev

Etape 2 : MariaDB

Si vous ne l’avez pas déjà – cela remplace MySQL sans que vous n’ayez rien à changer au niveau du code ou de la configuration du serveur :

apt install mariadb-server

Etape 3 : PHP

Je vous conseille de suivre mon dernier guide pour installer PHP 7.1.

Etape 4 : configurer NginX

Nous allons d’abord configurer toutes les options qui nous sont primordiales : compression des fichiers statiques, implémentation SSL, types mime… afin de gagner du temps (et éviter les erreurs) dans l’étape suivante.

1. Nous voulons un site rapide donc nous allons compresser tout ce qui peut l’être. On crée un nouveau fichier :

nano /etc/nginx/snippets/gzip-config.conf

et on y met :

# MATT : add more mime-types to compress
types {
	application/x-font-ttf           ttf;
	font/opentype                    ott;
}

# MATT : gzip all the things!
 gzip on;
 gzip_disable "msie6";
 gzip_vary on;
 gzip_proxied any;
 gzip_comp_level 6;
 gzip_min_length 256;
 gzip_buffers 16 8k;
 gzip_http_version 1.1;
 #gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

  # Compress all output labeled with one of the following MIME-types.
 gzip_types
    application/atom+xml
    application/javascript
    application/json
    application/ld+json
    application/manifest+json
    application/rss+xml
    application/vnd.geo+json
    application/vnd.ms-fontobject
    application/x-font-ttf
    application/x-web-app-manifest+json
    application/xhtml+xml
    application/xml
    font/opentype
    image/bmp
    image/svg+xml
    image/x-icon
    text/cache-manifest
    text/css
    text/plain
    text/vcard
    text/vnd.rim.location.xloc
    text/vtt
    text/x-component
    text/x-cross-domain-policy;
# text/html is always compressed by gzip module
# don't compress woff/woff2 as they're compressed already

J’ai ajouté deux types mime qui ne sont pas dans la configuration de base d’NginX et étendu la liste des types de fichiers à compresser. Certains types le sont déjà donc c’est inutile de gaspiller des ressources en essayant de les compresser.

Lire la suite

Better Call Saul saison 3 photo

Better Call Saul saison 3

La saison 3 de Better Call Saul nous ramène exactement là où nous étions à la fin de la seconde saison, après la querelle entre Jimmy et son frère Chuck.

Pas de prolepse. En 2002, Jimmy aide son frère Chuck à retirer les panneaux d’aluminium qui couvrent les murs de sa maison et rappelle à son frère un livre qu’ils ont lu ensemble pendant leur enfance. Mais Chuck tranche la nostalgie sèchement et dit à Jimmy que jamais ses actions ne seront oubliées, ni pardonnées.

Pendant ce temps, Kim commence à développer une certaine anxiété à développer sa propre firme d’avocats tout en gérant le secret frauduleux de Jimmy.

Chuck joue l’enregistrement de la confession de Jimmy à Hamlin, qui le prévient que cela n’a aucune valeur juridique.

Mike, déterminé à retrouver les traces du saboteur qui lui a empêché de tuer Hector, désosse sa voiture à la recherche d’un traqueur GPS. Cela lui prend un certain temps et sur le point d’abandonner, il a une épiphanie et le découvre finalement.

Quelqu’un vient récupérer le traqueur. Mike s’habille, s’arme et commence sa filature.

Lire la suite

Serveur dédié : mise à jour vers PHP7.1 sous Debian photo

Serveur dédié : mise à jour vers PHP7.1 sous Debian

Aujourd’hui, le serveur passe à PHP7.1 !

Ce tutoriel aborde le passage de PHP7.0 à PHP7.1 sur une Debian stable (Jessie).

L’opération prend une vingtaine de minutes, en comptant les opérations de vérifications (pre-flight checks en anglais).

La retraite PHP chez Dotdeb

Guillaume Plessis, qui maintient Dotdeb, a récemment annoncé que pour des raisons personnelles et professionnelles, Dotdeb ne fournira plus les mises à jour de PHP passé la version 7.0.

Je comprends sa décision : c’est chronophage et il faut pouvoir être en mesure de répondre aux commentaires et attentes d’une foule de personnes qui utilisent ce dépôt. Pas toujours simple. Merci Guillaume pour tout le travail accompli !

Vérification de la compatibilité PHP7.x sous WordPress

Si votre site tourne sous WordPress, il existe un plugin très utile – PHP Compatibility Checker – qui permet de vérifier que la mise à jour n’impactera pas votre site.

Je pense notamment aux plugins dont certains peuvent être assez vieillots et dont les fonctions peuvent être maintenant obsolètes.

Lancez-le avant de faire la mise à jour. S’il rapporte des warnings, ce n’est pas un problème. Si ce sont des erreurs par contre, mieux vaut y jeter un oeil avant de mettre à jour votre serveur.

Nouveau dépôt PHP : Ondrey Sury

Si l’on veut PHP7.1, il faut donc changer de dépôt et utiliser celui d’Ondrey Sury.

On installe donc ce nouveau dépôt :

apt install apt-transport-https lsb-release ca-certificates
wget -O /etc/apt/trusted.gpg.d/php.gpg https://packages.sury.org/php/apt.gpg
echo "deb https://packages.sury.org/php/ $(lsb_release -sc) main" >> /etc/apt/sources.list

Installation de PHP7.1

On met à jour et on installe PHP7.1 :

apt update && apt upgrade

Résultat :

The following NEW packages will be installed:
  libzip4 php7.1-cli php7.1-common php7.1-curl php7.1-fpm php7.1-gd php7.1-json php7.1-mbstring php7.1-mcrypt php7.1-opcache php7.1-readline php7.1-xml php7.1-xmlrpc
The following packages will be upgraded:
  libssl-doc libssl1.0.2 php-common php-curl php-fpm php-gd php-mbstring php-mcrypt php-xml php-xmlrpc php7.0 php7.0-bcmath php7.0-cli php7.0-common php7.0-curl php7.0-fpm php7.0-gd php7.0-json php7.0-mbstring php7.0-mcrypt php7.0-mysql php7.0-opcache php7.0-readline php7.0-soap php7.0-xml php7.0-xmlrpc php7.0-zip

On installe les paquets manquants :

php7.1-mysql php7.1-soap

Lire la suite

DJ Schmolli - Rock Of Ages photo 1

DJ Schmolli – Rock Of Ages

Voici un petit mashup rock de DJ Schmolli qui s’appelle Rock Of Ages et qui fleure bon le rock et hard-rock de notre jeunesse :

Pas mal de chansons des années 60, 70 et 80.

Allez, petit blind test musical : quels artistes êtes-vous capables de reconnaitre, à l’oreille comme à l’écran ?

Donnez vos réponses en commentaires (avec timer si vous le souhaitez).

Serveur High Availability : créer un load balancer avec une IP flottante photo 1

Serveur High Availability : créer un load balancer avec une IP flottante

Après la réplication des bases de données et la réplication des fichiers, passons maintenant à la mise en place d’un load balancer avec keepalived et une IP flottante.

Voici le principe général de ce que nous cherchons à accomplir, avec une petite animation:

Serveur High Availability : créer un load balancer avec une IP flottante photo 1

Voici ce dont vous avez besoin pour ce tutoriel:

Installation et paramétrage de keepalived

Keepalived est une application de routage qui permet de fournir un moyen simple et robuste de mettre en place des solutions de load balancing et de haute disponibilité sur des systèmes Linux. Cela se passe au niveau de la couche 4 du modèle OSI :

Serveur High Availability : créer un load balancer avec une IP flottante photo

Concrètement, keepalived va vérifier toutes les quelques secondes que notre serveur de fichier est bien actif sur notre serveur MASTER. Si jamais le serveur est down, l’IP flottante sera assignée au serveur BACKUP. L’enregistrement DNS A du site doit pointer vers l’IP flottante. Cela permet de rediriger le trafic automatiquement et de manière transparente sur le serveur BACKUP.

Sur le serveur MASTER

1. On installe donc keepalived:

apt-get install keepalived

et on édite sa configuration init:

nano /etc/init/keepalived.conf

On y ajoute :

description "load-balancing and high-availability service"

start on runlevel [2345]
stop on runlevel [!2345]

respawn
exec /usr/local/sbin/keepalived --dont-fork

2. On obtient l’adresse IP privée du serveur:

curl http://169.254.169.254/metadata/v1/interfaces/private/0/ipv4/address && echo

Résultat:

10.134.23.164

Lire la suite

Hébergement OVH : passer à TLS 1.2 pour WooCommerce et PayPal photo 1

Hébergement OVH : passer à TLS 1.2+ pour WooCommerce et PayPal

Si vous possédez une boutique en ligne et que vous acceptez PayPal comme moyen de paiement, vous n’êtes pas sans savoir qu’à partir du 30 juin, PayPal exigera une connexion TLS version 1.2 pour gérer la transaction entre votre boutique et PayPal.

Concrètement, votre serveur ou votre hébergement doit être configuré pour servir les pages en HTTPS (certificat SSL obligatoire) et avec une version d’OpenSSL qui donne la priorité au protocole TLS version 1.2+.

Hébergement OVH : passer à TLS 1.2 pour WooCommerce et PayPal photo 1

Chez OVH, la version d’OpenSSL dépend de la version de PHP configurée pour votre hébergement et surtout du mode utilisé. Pour avoir la dernière version d’OpenSSL, il faut absolument être en mode Stable.

Cela ne prend que quelques minutes à configurer.

TLS sur un serveur dédié

Dans le cas de votre serveur dédié, il suffit de mettre à jour OpenSSL et d’éditer la configuration du serveur (Apache / nginx) pour désactiver les protocoles SSL, TLSv1, TLS v1.1 pour ne garder que TLS v1.2 et TLS v1.3.

TLS sur un hébergement mutualisé OVH

Dans le cadre d’un hébergement mutualisé OVH voici la marche à suivre. Commencez par vous rendre dans le Manager OVH puis :

  1. activer le certificat SSL Let’s Encrypt.
  2. choisir une version de PHP récente en mode Stable.
  3. passer l’intégralité de votre WordPress / Woocommerce en https (si ce n’est déjà fait mais si vous avez une boutique en ligne, ce devrait être le cas depuis longtemps).

En image, voici ce que cela donne :

Hébergement OVH : passer à TLS 1.2 pour WooCommerce et PayPal photo

C’est l’étape 2 qui est primordiale pour activer TLS 1.2 : cela permet de passer d’OpenSSL 0.9.8 à OpenSSL 1.0.1t à l’heure où j’écris ces lignes.

Vérification TLS v1.2

Pour connaître la version d’OpenSSL en vigueur sur votre serveur :

openssl version

Enfin, pour savoir si la connexion entre votre serveur et les serveurs de PayPal se fait bien à l’aide du chiffrement TLS 1.2, lancez cette commande sur votre serveur/hébergement dans un terminal :

php -r '$ch = curl_init(); curl_setopt($ch, CURLOPT_URL, "https://tlstest.paypal.com/"); var_dump(curl_exec($ch)); var_dump(curl_error($ch));'

Si la connexion est bien servie en TLS 1.2, le résultat devrait être :

PayPal_Connection_OKbool(true)
string(0) ""

Voilà, en espérant que cela puisse vous servir. C’est simple à mettre en place et ne prend que quelques minutes pour retrouver un chiffrement plus sécurisé.

Si vous avez besoin d’un développeur WooCommerce professionel pour mettre tout cela en place, contactez-moi.

Bonne mise à jour.

Prison Break saison 5 : Resurrection photo

Prison Break saison 5 : Resurrection

La cinquième saison de Prison Break, sous-titrée “Prison Break: Resurrection”, continue la série originale de Paul Scheuring qui a été diffusée sur la Fox de 2005 à 2009.

Au niveau des acteurs, Wentworth Miller est toujours Michael Scofield, Dominic Purcell est Lincoln Burrows, et Sarah Wayne Callies, Amaury Nolasco, Paul Adelstein, Robert Knepper et Rockmond Dunbar font toujours partie du casting.

Au début de cette saison, T-Bag sort de prison et reçoit une photo de Michael qui semble être dans une nouvelle prison. T-Bag montre cette image à Lincoln, qui trouve le mot caché, “Ogygia”, qui est un établissement pénitentier situé à Sana’a, au Yemen.

Lincoln informe Sara, qui élève Mike, le fils qu’elle a eu avec Michael, en compagnie de son mari Jacob. Elle refuse d’y croire. Lincoln part au Yemen avec C-Note, qui s’est converti à l’Islam. Lincoln échange son passeport contre la promesse de voir Michael en prison mais ce dernier fait semblant de ne pas le reconnaitre.

Pendant ce temps, T-Bag est contacté par un chirurgien qui lui propose une main bionique aussi fonctionnelle qu’une main naturelle. T-Bag apprend qu’une personne anonyme appelée Outis (“Personne” en grec) a financé l’opération et a insisté pour que ce soit uniquement lui qui en bénéficie.

Personnellement, revoir Prison Break sur les écrans, cela me fait un peu étrange : il y eu énormément de séries de qualité depuis et ce n’est pas une série qui brille par son intrigue ou ses dialogues.

C’est même la série type que je conseillais aux élèves et parents pour montrer que l’on pouvait très bien suivre une série en anglais sans sous-titres :)

Lire la suite

Créer un serveur High Availability : la réplication des fichiers photo

Créer un serveur High Availability : la réplication des fichiers

Nous avons vu il y a quelques jours comment répliquer nos bases de données à la volée d’un serveur à l’autre.

Voyons aujourd’hui comment répliquer les fichiers en temps réel avec lsyncd.

Créer un serveur High Availability : la réplication des fichiers photo

Pour les besoins de ce tutoriel, vous avez besoin:

Mon serveur principal s’appelle MASTER. Le serveur de sauvegarde s’appelle BACKUP.

Copier tous les fichiers d’un serveur à l’autre avec rsync

rsync est le moyen le plus simple de copier tous les fichiers d’un répertoire sur votre serveur de sauvegarde.

Nous copions donc tous les fichiers qui se trouvent dans /var/www/html de notre serveur MASTER vers BACKUP :

rsync --progress -av --delete --stats --checksum --human-readable /var/www/html/* root@10.134.4.220:/var/www/html/

Cela permet d’avoir deux copies identiques très rapidement, surtout si vos deux VPS sont dans le même datacenter : vous pouvez alors utiliser l’IP interne du serveur – vitesse décuplée assurée (et cela ne compte pas dans la bande passante allouée).

La réplication des fichiers du site avec lsyncd

Je choisis d’utiliser lsyncd pour assurer la réplication des fichiers du site. C’est un petit service qui surveille le contenu d’un répertoire et qui fait un rsync toutes les 20 secondes vers votre autre VPS.

1. Sur le serveur MASTER, on installe lsyncd:

apt-get install lsyncd

2. Et on crée ses répertoires et son fichier de configuration :

mkdir /etc/lsyncd
mkdir /var/log/lsyncd
nano /etc/lsyncd/lsyncd.conf.lua

Lire la suite

Billions saison 2 photo

Billions saison 2

La seconde saison de Billions, diffusée sur Showtime, commence par le bureau de Chuck qui fait l’objet d’une enquête de la part du procureur général.

Pendant ce temps, Axe reconsolide Axe Capital et se demande quoi faire ensuite pour rendre à Chuck la monnaie de sa pièce. Le fonds d’investissement se bat contre une situation économique précaire qui menace l’existence même d’Axe Cap.

Quant à Wendy, elle accepte l’offre d’un fond de capital rival tandis que Lara se porte volontaire en urgence pour travailler à l’école de ses enfants.

Axe affronte publiquement le dirigeant d’un hedge fund concurrent et, grâce à l’aide précieuse d’un stagiaire très talentueux, lance un plan financier qui cherche à faire mal à la compétition. Chuck déploie son équipe sur le terrain afin de trouver rapidement une affaire importante qui pourrait le sortir de sa mauvaise passe – il doit impérativement faire ses preuves pour ne pas être mis à pied.

Wendy doit répondre à une série de questions embarrassantes qui pourraient bien faire tomber Chuck, qui vit au Yale Club le temps de leur séparation.

La série redémarre bien, les personnages sont vraiment construits avec intelligence et réalisme.

Billions a d’ores et déjà été renouvelée pour une troisième saison, qui sera diffusée l’année prochaine, au début de l’année 2018.

Lire la suite

Créer une clé SSH pour ouvrir une session distante sans mot de passe photo

Créer une clé SSH pour ouvrir une session distante sans mot de passe

Il est idéal de pouvoir s’identifier sur un serveur distant, à l’aide d’une clé SSH, sans avoir à taper son mot de passe à chaque fois.

Pas seulement pour un gain de temps mais pour, par exemple, transférer des données ou avoir un cron qui lance une sauvegarde planifiée automatiquement, sans que vous ayez à taper le mot de passe SSH.

Et puis, c’est un degré de sécurité supplémentaire puisque personne ne pourra deviner votre clé RSA, à moins d’avoir eu main mise sur votre machine.

Ce tutoriel est très rapide à mettre en œuvre, quelques minutes à peine suffisent pour créer votre clé et la placer sur le serveur distant.

Voici le principe de fonctionnement en image:

Créer une clé SSH pour ouvrir une session distante sans mot de passe photo 1

Concrètement, au lieu d’utiliser un nom d’utilisateur et un mot de passe en mode interactif (l’invite de commande vous demande d’entrer votre mot de passe), il suffit de donner le nom d’utilisateur et le serveur reconnaît votre machine grâce à votre clé SSH.

Créer un répertoire .ssh pour l’utilisateur

Normalement, votre utilisateur possède déjà un répertoire .ssh mais si ce n’est pas le cas, il faut le créer. Vous pouvez passer à l’étape suivante si vous disposez déjà de ce répertoire.

On se rend dans le répertoire de l’utilisateur:

cd ~/

On crée le répertoire .ssh:

mkdir .ssh

On s’assure que les permissions de fichiers permettent de lire, écrire et exécuter uniquement pour notre utilisateur:

chmod go-rwx .ssh

Créer une clé SSH

Nous allons maintenant créer une clé SSH, ou plutôt 2 clés : une clé privée et une clé publique.

Les guillemets à la fin de la commande indiquent que la clé privée n’a pas de mot de passe, ce qui permet de s’identifier sans mot de passe.

On se place dans le répertoire .ssh:

cd .ssh

Nous créons une clé de 4096 bits, sans mot de passe :

ssh-keygen -b 4096 -t ed25519 -f id_rsa -P ""

Nous obtenons deux fichiers :

  • id_rsa : notre clé privée
  • id_rsa.pub : notre clé publique

Lire la suite

Créer un serveur High Availability : la réplication des bases de données photo

Créer un serveur High Availability : la réplication des bases de données

Ce tutoriel aborde la réplication des données d’un VPS ou serveur dédié : les bases de données seront répliquées d’un serveur principal (master) sur un autre serveur auxiliaire (backup).

En cas de défaillance du serveur principal, le serveur auxiliaire prendra le relais automatiquement.

Ce guide considère que vous avez :

  • deux VPS ou Droplets chez Digital Ocean dans le même datacenter;
  • une IP flottante qui peut être assignée à l’un ou l’autre des serveurs, à la demande;
  • le même système d’exploitation sur les deux serveurs, pour des raisons de compatibilité.

Créer une image du VPS principal pour le VPS de sauvegarde

Commençons par la base du système : le système d’exploitation (OS). Lorsque j’ai pris le projet en main, le site était déjà en production et tournait sur la dernière version d’Ubuntu Server, avec NginX, MariaDB et SSL activé.

On aurait pu tout réinstaller sur le nouveau VPS mais autant gagner du temps : Digital Ocean permet de faire une image du VPS existant et de l’installer sur un nouveau droplet. C’est quelques heures d’installation et de configuration d’économisées.

Voici les données de mes deux VPS :

MASTER

ipv4: 104.xxx.xxx.133
Private IP:  10.134.23.164

BACKUP

ipv4: 104.xxx.xxx.186
Private IP:  10.134.4.220

Floating IP

Floating IP:  138.xxx.xxx.177

Je masque les IP publiques puisque mes serveurs sont en production mais ces IP serviront pour le tuto : l’IP qui se termine en .133 est le Master, l’IP qui se termine en .186 est le Backup, et l’IP qui se termine en .177 est l’IP flottante.

Réplication de la base de données

Les deux serveurs LEMP sont maintenant identiques, même les fichiers et bases de données. Mais nous avons besoin d’avoir une base de données synchronisée en temps réel, dans les deux sens, master-master.

Si un serveur tombe, l’autre prend le relais. Lorsque le serveur Master revient à lui, le serveur Backup lui redonne les données SQL manquantes.

1. Configuration du serveur MASTER

On édite la configuration MariaDB:

nano /etc/mysql/my.cnf

On édite et remplace/ajoute :

# MATT - skyminds.net : MariaDB replication instructions.
# https://www.skyminds.net/?p=28739

# 1. bind-adress : replace 127.0.0.1 with Internal IP.
# bind-address          = 127.0.0.1
bind-address            = 10.134.23.164

# 2. enable log_bin
log_bin                 = /var/log/mysql/mariadb-bin
log_bin_index           = /var/log/mysql/mariadb-bin.index

# 3. add server-id AND binlog_do_db
# NOTE : server-id is a way to identify this server in MariaDB configs.
# NOTE : binlog_do_db contains the names of the databases to replicate
server-id               = 1
binlog_format=mixed
# first DB
binlog_do_db            = first_wpdb
# second DB
binlog_do_db            = second_wp

# /MATT

Nous allons maintenant lancer quelques commandes sur le serveur SQL:

mysql -u root -p

Lire la suite