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 :
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.
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.
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:
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.sshCode language:CSS(css)
On s’assure que les permissions de fichiers permettent de lire, écrire et exécuter uniquement pour notre utilisateur:
chmodgo-rwx.sshCode language:CSS(css)
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.sshCode language:CSS(css)
Nous créons une clé de 4096 bits, sans mot de passe :
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.
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.
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
# /MATTCode language:PHP(php)
Nous allons maintenant lancer quelques commandes sur le serveur SQL:
Vous avez sûrement remarqué qu’IPKG n’est plus maintenu depuis maintenant quelques années (2014) et qu’à chaque mise à jour DSM du NAS Synology, les applications sautent.
Il devenait quasiment impossible d’installer IPKG sur les nouveaux NAS – jusqu’à l’arrivée d’Entware.
Entware est un petit nouveau qui a mis des années à mûrir mais il est mis à jour en permanence et offre plus de 1800 paquets à votre NAS. Il est aussi compatible avec les routeurs OpenWRT et LEDE.
Voyons donc comment installer cette nouvelle source d’applications.
Entware-ng, le petit nouveau
Entware-ng prend en charge les processeurs ARM et Intel, votre version de DSM doit quant à elle être égale ou supérieure à la version 3.2.
Il faut utiliser :
l’installeur armv5 pour les processeurs Marvell Kirkwood mv6282,
l’installeur armv7 pour les processeurs ARM plus récents. Le dépôt armv7 a été compilé avec l’optimisation cortex-a9 mais reste totalement compatible avec les NAS basés sur des Marvell Armada XP .
Déterminer le modèle du processeur du NAS
Considérons que SSH est activé dans les options du DSM (Control Panel > Applications > Terminal & SNMP > Terminal > Enable SSH service).
On commence par lancer une connexion SSH vers le NAS avec l’utilisateur admin :
sshadmin@DiskStationCode language:CSS(css)
et on passe root:
sudo -i
On peut trouver le modèle du processeur en tapant:
cat /proc/cpuinfo | more
Cela vous permet de savoir si vous êtes en armv5 ou armv7 (plus récent).
Un autre moyen, peut-être même plus simple :
uname -a
Résultat chez moi:
Linux DiskStation 2.6.32.12#15132 Wed Jun 14 12:24:38 CST 2017 armv5tel GNU/Linux synology_212+Code language:PHP(php)
Installer Entware-ng sur notre NAS Synology
Toujours dans votre session SSH, en tant que root, vous allez maintenant installer Entware sur votre Synology.
1. On crée un dossier sur le disque, en dehors du rootfs :
mkdir -p /volume1/@entware-ng/opt
Le dossier /opt doit absolument être vide, c’est-à-dire qu’Optware ne doit pas être installé. Dans le doute, on le vide dans l’étape suivante.
2. On supprime /opt et on crée un lien symbolique:
La dernière ligne permet de lancer les services Entware lors du démarrage du NAS.
Depuis DSM 6.1, /etc/rc.local n’est plus exécuté lors de la séquence de boot. Il faut donc créer une tâche planifiée qui lance ces deux instructions au démarrage du NAS.
Rendez-vous dans Panneau de configuration > Planificateur de tâches > Créer > Tâche déclenchée > Script défini par l’utilisateur. Cette tâche sera lancée au démarrage du NAS:
Dans ce tutoriel, nous allons voir comment configurer rsync pour planifier des sauvegardes d’un serveur distant et permettre l’accès SSH vers votre NAS Synology en local.
Armez-vous de votre terminal préféré et lancez une session SSH, c’est parti !
Étape 1 : créer un nouvel utilisateur Synology
Afin de bien séparer les processus et privilèges, il vaut mieux créer un nouvel utilisateur Synology : cela permet de contrôler exactement ce à quoi il a accès.
Dans ce tutoriel, notre utilisateur s’appellera saveme.
Étape 2 : activer l’accès SFTP
Activez l’accès SFTP dans Diskstation > Control Panel > FTP > SFTP > Enable SFTP service. Vérifiez aussi que le port 22 (SSH) est bien ouvert dans votre routeur et firewall; et bien redirigé vers votre NAS.
Ensuite, ouvrez une session SSH sur votre NAS :
sshadmin@IP_NASCode language:CSS(css)
Entrez votre mot de passe, vous devriez être loggué. Si ce n’est pas le cas, vérifiez la configuration routeur/firewall du port 22.
Étape 3 : éditer le fichier passwd
Une fois que vous êtes identifié en SSH sur votre NAS, il vous faut éditer le fichier passwd:
nano /etc/passwd
Allez à la dernière ligne, qui gère le nouvel utilisateur créé à l’étape 1. A la fin de cette ligne, remplacez :
/sbin/nologin
par
/bin/sh
Sauvegardez le fichier.
Maintenant, on assigne un dossier de travail avec tous les droits nécessaires à notre utilisateur (qui s’appelle saveme). Au lieu de le mettre dans /homes, on va plutôt le mettre à la racine, bien au chaud, sous /volume1/backup.
On donne accès au dossier :
chown saveme:users /volume1/backup
Étape 4 : identification avec notre nouvel utilisateur
On s’identifie avec notre utilisateur saveme :
su - saveme
Si vous obtenez des messages d’erreur comme :
su: can't chdir to home directory '/volume1/backup'
su: can't run /sbin/sh: No such file or directoryCode language:PHP(php)
La première erreur est due à une erreur de permissions. Vérifiez que vous avez bien chowné le bon dossier. La seconde montre que vous avez oublié d’ajouter
/bin/sh
à votre utilisateur dans l’étape 3.
Étape 5 : ajouter la clé SSH du NAS sur le serveur distant
On crée la clé en utilisant le chemin par défaut et on appuie juste sur “entrée” lorsqu’on nous demande un mot de passe de clé :
Essayez maintenant d’ouvrir une session SSH sur votre serveur distant depuis la session SSH du NAS : la session devrait s’ouvrir sans que vous n’ayez à entrer le mot de passe du compte.
Si vous obtenez une erreur de permission, voici les bonnes permissions à appliquer :
le répertoire .ssh doit avoir un chmod 700,
la clé publique (fichier .pub) doit avoir un chmod 644,
la clé privée (id_rsa) doit avoir un chmod 600.
Voici donc les commandes à lancer pour attribuer les bonnes permissions sur le NAS:
Depuis DSM6, on ne peut plus ouvrir de session SSH avec l’utilisateur root. Il faut donc ruser en ouvrant une session avec un autre utilisateur (admin par exemple) puis passer root avec sudo -i
2. Une fois connecté en tant que root, on récupère le paquet pip :
pip est maintenant installé. Il ne vous reste plus qu’à installer les paquets de votre choix, à la manière d’un apt, apt-get ou aptitude :
Usage:
pip [options]
Commands:
install Install packages.
download Download packages.
uninstall Uninstall packages.
freeze Output installed packages in requirements format.
listList installed packages.
show Show information about installed packages.
search Search PyPI for packages.
wheel Build wheels from your requirements.
hash Compute hashes of package archives.
help Show help for commands.Code language:PHP(php)
Linux Mint Debian Edition (LMDE) est vraiment très stable et fonctionne avec des paquets éprouvés mais pas vraiment à jour.
Si vous avez du matériel récent, il est possible qu’il ne soit pas détecté – c’est le cas du pavé tactile de mon ordinateur portable – à cause du noyau linux qui laggue un peu.
A l’heure où j’écris ces lignes, Linux Mint Debian Edition utilise le kernel 3.16 alors que le dernier en date est le 4.6.3… voyons comment on peut le mettre à jour.
Le kernel Liquorix
Liquorix vient remplacer le noyau linux de votre distribution.
C’est un noyau à jour, avec des configurations supplémentaires pour les ordinateurs de travail, le multimédia et les jeux vidéos.
Installation de Liquorix
On passe root :
sudo -i
On édite le fichier sources.list d’apt :
nano /etc/apt/sources.listCode language:PHP(php)
et on y ajoute :
# liquorix kernel
deb http://liquorix.net/debian sid mainCode language:PHP(php)
On sauvegarde le fichier, on met à jour les paquets et on installe le keyring de Liquorix :
Aujourd’hui, petite mise à jour mineure de PHP7, en utilisant les dépôts DotDeb.
Le problème : PHP-FPM désactivé par défaut
A la fin de l’installation, j’obtiens ce message d’avertissement :
Setting up php7.0-fpm (7.0.8-1~dotdeb+8.1) ...
Installing new version of config file /etc/init.d/php7.0-fpm ...
NOTICE: Not enabling PHP 7.0 FPM by default.
NOTICE: To enable PHP 7.0 FPM in Apache2 do:
NOTICE: a2enmod proxy_fcgi setenvif
NOTICE: a2enconf php7.0-fpm
NOTICE: You are seeing this message because you have apache2 package installed.
[ ok ] Restarting PHP 7.0 FastCGI Process Manager: php-fpm7.0.Code language:JavaScript(javascript)
C’est bien la première fois qu’une mise à jour de PHP désactive PHP-FPM, ce n’est pas vraiment une mise à jour mineure et sans accroc.
On réactive donc les deux modules indiqués et on relance la configuration de PHP-FPM avant de relancer Apache et PHP-FPM :
Je lance le site : page d’erreur de certificat la première fois, et page blanche ensuite !
Des modules PHP à installer séparément
Après analyse des dernières lignes du fichier log d’Apache, je me suis rendu compte que le site avait besoin des modules mbstring et xml or, cette nouvelle version ne les fournit plus : ce sont maintenant des paquets à installer à part.
Voici le message d’erreur des logs:
[26-Jun-2016 08:39:12 UTC] PHP Fatal error: Uncaught Error: Class 'DOMDocument' not found in /public_html/wp-content/plugins/ginger/front/gingerfront.core.php:171
Stack trace:
#0 /public_html/wp-includes/plugin.php(235): ginger_parse_dom('...')
On installe donc mbstring et xml avant de relancer Apache et PHP :
Cette fois-ci, c’est tout bon. Tous les services sont actifs et le site est de nouveau opérationnel.
Attention donc : c’est une mise à jour mineure que j’aurais pu faire en SSH depuis mon téléphone, sans avoir les moyens de réparer à distance. Cela remet en perspective les mises à jour “on-the-go“.
Voici les nouveaux modules qui ne sont plus inclus par défaut avec PHP : bcmath, dba, mbstring, soap, xml et zip. Ce sont donc maintenant des paquets à part entière, à installer séparément.
Pas de clé publique disponible pour vérifier l’authenticité des dépôts
Au lancement de la mise à jour des paquets du serveur, je suis tombé sur le message d’erreur suivant :
W: There is no public key available for the following key IDs:
8B48AD6246925553
W: There is no public key available for the following key IDs:
8B48AD6246925553
W: There is no public key available for the following key IDs:
8B48AD6246925553Code language:PHP(php)
Visiblement, APT a perdu ses petits et ne retrouve plus la clé publique GPG d’un des mes dépôts (webmin en l’occurence).
Voici comment remédier au problème.
Solution : demander et ajouter la clé au trousseau GPG
Un peu de ménage dans APT
On commence par faire un peu de ménage dans les fichiers APT avec un petit coup de balai:
apt-get cleanCode language:JavaScript(javascript)
… avant de récréer le dossier lists/partial pour véritablement recréer le cache APT :
Les inodes perdues ! Cette semaine, j’ai eu droit à un problème particulier sur le serveur : alors que rien dans la configuration des services n’a été changé, je me suis rendu compte que WordPress ne réagissait pas comme d’habitude.
Les symptômes les plus visibles sont la lenteur de l’application, l’impossibilité de mettre à jour ou corriger un article ou encore ajouter des tags à un nouvel article.
Je tente alors un df -i pour vérifier le nombres d’inodes disponibles :
df -i
Un nœud d’index ou inode (contraction de l’anglais index et node) est une structure de données contenant des informations à propos d’un fichier stocké dans les systèmes de fichiers Linux/Unix.
À chaque fichier correspond un numéro d’inode (i-number) dans le système de fichiers dans lequel il réside, unique au périphérique sur lequel il est situé.
Descripteurs de fichiers, table des fichiers et table des inodes sous Linux
Les inodes contiennent notamment les métadonnées des systèmes de fichiers, et en particulier celles concernant les droits d’accès.
Les inodes sont créés lors de la création du système de fichiers. La quantité d’inodes (généralement déterminée lors du formatage et dépendant de la taille de la partition) indique le nombre maximum de fichiers que le système de fichiers peut contenir.
Dans notre cas, catastrophe, il ne reste quasiment plus d’inodes disponibles !
Mon NAS Synology est configuré pour se mettre automatiquement à jour, ce qui est plutôt pratique puisque cela permet d’automatiser les mise à jour de sécurité et des paquets essentiels.
Hier, une nouvelle mise à jour du DSM est arrivée : DSM 6. La mise à jour s’est visiblement bien déroulée mais quelques petites choses ont été modifiées au sein du système, dont la perte d’accès root pour rsync, ce qui est problématique pour mes sauvegardes.
Le truc qui change, c’est qu’au lieu d’utiliser root comme utilisateur, il va désormais être obligatoire d’utiliser un utilisateur qui appartient au groupe administrators. Chez moi, il y en a plusieurs mais pour des raisons de simplicité, nous utiliserons l’utilisateur admin dans ce tutoriel.
Voyons donc comment donner l’accès à rsync pour l’utilisateur admin, cela ne prend que quelques minutes.
Ajouter des utilisateurs dans le groupe des administrateurs
Nous commençons par vérifier que nous possédons bien au moins un administrateur sur le NAS. Par défaut, il devrait au minimum y avoir le compte admin mais vous pourriez l’avoir désactivé pour des raisons de sécurité (c’était mon cas avant de faire cette mise à jour).
Rendez-vous dans Synology > Control Panel > Group > Administrators > Edit members:
Ici, nous avons bien l’utilisateur admin. N’hésitez pas à y ajouter vos autres utilisateurs qui possèdent les droits d’administration.
Note: profitez-en pour faire un détour par Control Panel > User et changez le mot de passe de l’utilisateur admin pour un mot de passe plus robuste.
