Category

Web/Tech

Category

Tous les tutoriels et articles de barbus orientés technique.

De temps en temps, on me demande de configurer des serveurs dédiés ou des VPS. Dernièrement, j’ai travaillé sur un VPS qui n’avait pas de fichier swap et qui finissait par consommer toute la RAM disponible.

Linux : créer un fichier d'échange (swap) pour optimiser un VPS photo

Ce tutoriel vous permet de mettre en place un fichier swap sous Ubuntu 16.04 Server.

Le fichier swap

Le moyen le plus simple d’avoir un serveur réactif et de le prémunir contre les erreurs out-of-memory des services est d’allouer un fichier swap.

Le swap est une zone du disque dur spécialement créée pour que le système d’exploitation y garde des données temporaires qu’il ne peut plus stocker dans la RAM.

Cet espace permet donc aux services du serveur de continuer de tourner même lorsque la RAM est épuisée et ne sera utilisé que dans ce cas de figure.

Les informations seront cependant écrites sur le disque beaucoup moins rapidement que via la RAM.

Vérification du swap sur le système

Commençons par vérifier si un fichier de swap est déjà en place :

swapon --show

Aucun résultat : le système n’a pas d’espace réservé pour le fichier d’échange.

On vérifie une nouvelle fois s’il existe un fichier de swap actif:

free -h

Résultat:

                        total        used        free      shared  buff/cache   available
Mem:           3.9G        517M        2.5G         76M        895M        3.0G
Swap:            0B          0B          0B

Pas de swap actif sur notre système, nous allons donc pouvoir en ajouter une.

Vérification de l’espace disponible

Il est très commun de créer une nouvelle partition qui contient le fichier d’échange mais comme il n’est pas toujours possible de changer le schéma de partition, nous allons créer un fichier d’échange qui résidera sur notre partition existante.

Vérifions l’espace disponible :

df -h

Résultat:

Filesystem      Size  Used Avail Use% Mounted on
udev            2.0G     0  2.0G   0% /dev
tmpfs           396M  3.2M  393M   1% /run
/dev/vda1        59G   13G   45G  22% /
tmpfs           2.0G     0  2.0G   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           2.0G     0  2.0G   0% /sys/fs/cgroup
tmpfs           396M     0  396M   0% /run/user/0

Le disque dur se trouve sous /dev dans notre cas.

En ce qui concerne la taille de la partition swap : elle ne doit pas dépasser 4 Go (parce qu’au-delà, c’est inutile) et doit correspondre à peu près à la taille de votre RAM (ou le double de votre RAM suivant votre serveur).

Création du fichier d’échange

Nous allons donc créer un fichier d’échange nommé swapfile, d’une taille de 4 Go, à la racine du système (/).

sudo fallocate -l 4G /swapfile

Par souci de sécurité, ce fichier sera uniquement lisible par l’utilisateur root :

sudo chmod 600 /swapfile

Vérifions les permissions et l’espace réservé :

ls -lh /swapfile

Résultat:

-rw------- 1 root root 4.0G Jan 17 16:31 /swapfile

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.

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

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 : nous allons 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.

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.

Sommaire de la série Monter un serveur dédié de A à Z

  1. Serveur dédié : installation d’Apache, PHP, MySQL et Webmin
  2. Serveur dédié : créer la base de données MySQL et importer WordPress
  3. Serveur dédié : créer et activer un Virtual Host sous Apache
  4. Serveur dédié : changer les DNS du nom de domaine et le faire pointer vers le serveur
  5. Serveur dédié : sécurisation des services avec iptables et fail2ban
  6. Serveur dédié : sécurisation de la couche TCP/IP
  7. Serveur dédié : création d’un serveur mail Postfix (sécurisé avec Saslauthd et certificat SSL) et Courier (accès POP et IMAP) utilisant une base MySQL d’utilisateurs/domaines virtuels
  8. Serveur dédié : sécuriser Apache 2 avec ModSecurity
  9. Serveur dédié : CHMOD récursif sur des fichiers ou répertoires en ligne de commande
  10. Serveur dédié : installer APC comme système de cache et configurer Varnish comme reverse-proxy pour Apache pour améliorer les performances
  11. Serveur dédié : afficher la véritable IP derrière un reverse-proxy comme Varnish
  12. Serveur dédié : intégrer SSH à WordPress pour mettre à jour le core, les plugins et les thèmes
  13. Serveur dédié : installer la dernière version d’APC par SVN
  14. Serveur dédié : analyse des performances du serveur
  15. Serveur dédié : mettre à jour le noyau Debian de la Kimsufi
  16. Serveur dédié : sauvegarde automatique des fichiers avec Backup Manager sur le serveur de sauvegarde OVH
  17. Serveur dédié : configurer la limite mémoire pour PHP et Suhosin
  18. Bash : supprimer tous les fichiers et sous-répertoires d’un répertoire
  19. Serveur dédié : impossible de se connecter à un port distant
  20. Rsync: rapatrier les fichiers du serveur à la maison
  21. Bash : réparer les tables MySQL en cas de crash
  22. Serveur dédié : création d’une seedbox avec Transmission
  23. Serveur dédié : des paquets LAMP à jour sous Debian
  24. Serveur dédié : mise à jour vers Debian 7 Wheezy
  25. Serveur dédié : activer X11 forwarding pour SSH
  26. Serveur dédié : optimiser toutes les images JPG et PNG avec OptiPNG et JpegOptim
  27. Postfix : résoudre l’erreur “fatal: www-data(33): message file too big”
  28. Serveur dédié : mise en place de l’IPv6
  29. WordPress : accorder les bonnes permissions aux fichiers et dossiers avec chown et chmod
  30. WordPress : héberger les images sur un sous-domaine
  31. Serveur dédié : ajouter l’authentification SPF, Sender-ID et DKIM à Postfix et Bind9 avec opendkim
  32. Apache : lorsque le domaine seul (sans WWW) renvoie une erreur 403
  33. Serveur dédié : sécuriser Apache avec HTTPS (HTTP avec la couche TLS/SSL) en Perfect Forward Secrecy
  34. Serveur dédié : passer WordPress en HTTPS (TLS/SSL)
  35. Serveur dédié : configurer Webmin en TLS avec un certificat SSL
  36. Serveur dédié : configurer Transmission pour accéder au WebUI via TLS-SSL
  37. Serveur dédié : installer et configurer Varnish 4
  38. Serveur dédié : passage au mod FastCGI et PHP-FPM avec Apache MPM Worker
  39. Récupérer un serveur Kimsufi après un plantage de kernel avec le mode rescue OVH
  40. Serveur dédié : configurer Postfix et Courier pour utiliser TLS-SSL en Perfect Forward Secrecy
  41. Serveur dédié : retirer Varnish, devenu inutile avec HTTPS
  42. Serveur dédié : installer la dernière version d’OpenSSL sous Debian
  43. Serveur dédié : activer l’IP canonique du serveur sous Apache
  44. Serveur dédié : mise à jour vers PHP 5.6
  45. MySQL : convertir les tables MyISAM au format InnoDB
  46. Serveur dédié : optimiser toutes les images GIF avec GIFsicle
  47. Serveur dédié : migration de MySQL vers MariaDB
  48. BASH : lister, bloquer et débloquer des adresses IP avec iptables
  49. Serveur dédié : produire une meilleure réserve d’entropie avec haveged
  50. Serveur dédié : mettre en place DNSSEC pour sécuriser les DNS du domaine
  51. Serveur dédié : mise en place du protocole DANE
  52. 8 règles d’or pour bien déployer DNSSEC et DANE
  53. Serveur dédié : installer PHP7 FPM avec FastCGI sous Debian
  54. Serveur dédié : réduire les connexions TIME_WAIT des sockets et optimiser TCP
  55. Fail2Ban: protéger Postfix contre les attaques DoS de types AUTH, UNKNOWN et EHLO
  56. Serveur dédié : mettre à jour Apache et configurer le mod_http2 pour HTTP/2
  57. Serveur dédié : ajouter le domaine à la liste HSTS preload
  58. Serveur dédié : ajouter l’authentification DMARC à Postfix et BIND
  59. Serveur dédié : à la recherche de l’inode perdue ou comment résoudre le problème “no space left on device”
  60. Serveur dédié : installer NginX avec support HTTP2 et certificat SSL, PHP, MariaDB sous Debian

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

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

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

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

Sommaire de la série Créer un serveur High Availability (HA)

  1. Créer un serveur High Availability : la réplication des bases de données
  2. Créer un serveur High Availability : la réplication des fichiers
  3. Serveur High Availability : créer un load balancer avec une IP flottante

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 2017, 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 SSL et TLSv1 pour ne garder que TLS v1.1 et TLS v1.2.

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é.

Bonne mise à jour.

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

Sommaire de la série Créer un serveur High Availability (HA)

  1. Créer un serveur High Availability : la réplication des bases de données
  2. Créer un serveur High Availability : la réplication des fichiers
  3. Serveur High Availability : créer un load balancer avec une IP flottante

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.

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

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

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).

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

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

Sommaire de la série Créer un serveur High Availability (HA)

  1. Créer un serveur High Availability : la réplication des bases de données
  2. Créer un serveur High Availability : la réplication des fichiers
  3. Serveur High Availability : créer un load balancer avec une IP flottante

Quoi de plus normal que de regarder des séries et films en VO ? Et si vos sous-titres étaient automatiquement téléchargés sur votre NAS tous les soirs ?

Regarder des séries et films en version originale, c’est ce que je passe mon temps à faire à recommander à mes élèves – et à leurs parents lors des réunions parents-professeurs.

NAS Synology : télécharger automatiquement les sous-titres avec Subliminal photo 3

On s’affranchit souvent de ces petits fichiers textes mais il peut arriver de tomber sur une série un peu plus coriace, qui demande de bien tout comprendre si on veut vraiment saisir le fin mot de l’histoire. Bref, parfois, les sous-titres, ça peut servir.

Voici donc un petit tutoriel pour récupérer automatiquement les bons sous-titres pour vos fichiers, avec en script en ligne de commande ou exécutable par votre NAS.

Synology : installation de pip

1. Ouvrez une session SSH sur le NAS et passez root :

ssh user@NAS
sudo -i

2. Installez pip, le gestionnaire de paquets Python.

Synology : installation de subliminal

Subliminal est une librairie Python qui permet de rechercher et télécharger des sous-titres. C’est ce que nous allons lancer, soit en ligne de commande, soit par un cron sur le NAS.

Installez subliminal:

pip install subliminal

Résultat, après quelques minutes:

Successfully built pysrt enzyme guessit babelfish dogpile.cache rarfile rebulk
Installing collected packages: pytz, chardet, pysrt, enzyme, rebulk, babelfish, python-dateutil, guessit, pbr, stevedore, futures, click, dogpile.cache, rarfile, beautifulsoup4, requests, subliminal

Successfully installed babelfish-0.5.5 beautifulsoup4-4.5.3 chardet-2.3.0 click-6.7 dogpile.cache-0.6.2 enzyme-0.4.1 futures-3.0.5 guessit-2.1.1 pbr-1.10.0 pysrt-1.1.1 python-dateutil-2.6.0 pytz-2016.10 rarfile-3.0 rebulk-0.8.2 requests-2.13.0 stevedore-1.20.0 subliminal-2.0.5

Script de téléchargement automatique des sous-titres

Passons maintenant au script de téléchargement automatique de nos sous-titres. Voici mes pré-requis :

  1. dossier à scanner : /volume1/video
  2. âge maximum des fichiers pour lesquels on recherche les sous-titres : 4 weeks
  3. langue des sous-titres: eng pour l’anglais, fra pour le français. Ici, je ne souhaite que de l’anglais.

Créez donc un nouveau fichier (dans votre dossier utilisateur du NAS, pas dans root):

nano /volume1/homes/matt/subby.py

et ajoutez-y:

from datetime import timedelta
from babelfish import Language
from subliminal import download_best_subtitles, region, save_subtitles, scan_videos

# configure the cache
region.configure('dogpile.cache.dbm', arguments={'filename': 'cachefile.dbm'})

# scan for videos newer than 2 weeks and their existing subtitles in a folder
videos = scan_videos('/volume1/video', age=timedelta(weeks=10))

# download best subtitles in English
subtitles = download_best_subtitles(videos, {Language('eng')})

# save them to disk, next to the video
for v in videos:
    save_subtitles(v, subtitles[v])

Vous pouvez lancer ce script directement depuis un terminal avec :

python /volume1/homes/matt/subby.py

Mise à jour : on peut encore mieux faire ! Lassé d’avoir à installer pip et subliminal à chaque mise à jour du DSM, j’ai écrit un script bash qui gère toute l’installation (pip, subliminal) et qui lance le script python pour le téléchargement des sous-titres.

On crée notre script bash :

nano /volume1/homes/matt/subby.sh

avec :

#!/bin/bash
# Script Name : Pip and Subliminal dependences FTW
# Script Author : Matt Biscay
# Script URL : https://www.skyminds.net/nas-synology-telecharger-automatiquement-sous-titres-subliminal/
# Script Version : 1.0 (2017-07)

# working dir
cd /volume1/homes/matt

# is pip installed ?
if which pip 2>/dev/null;
then
  echo "pip is installed. Fetching subtitles..."
  python subby.py
  echo "Subs fetching complete. Enjoy !"
  exit 1
else
  echo "pip is missing. Installing it now..."

  # remove pip install file
  rm get-pip.py -f

  # fetch pip install file
  wget https://bootstrap.pypa.io/get-pip.py

  # install pip
  python get-pip.py

  # install subliminal
  pip install subliminal

  # get subs
  echo "pip and subliminal have been installed. Fetching subtitles..."
  python subby.py
  echo "Subs fetching complete. Enjoy !"
fi

Kaboom ! Si le binaire pip n’est pas présent sur le système, c’est qu’il n’a pas survécu à la mise à jour du DSM. On l’installe donc, ainsi que subliminal. Ensuite on lance le script de téléchargement.

Mise en place d’un cron pour automatiser le téléchargement des sous-titres

Si vous êtes sous Unix, vous pouvez mettre en place un cronjob avec le script tel quel.

Sur le Synology, tout se met en place en quelques clics :

  1. Rendez-vous dans Panneau de configuration > Planificateur de tâches > Créer > Tâche planifiée > Script défini par l’utilisateur:

    NAS Synology : télécharger automatiquement les sous-titres avec Subliminal photo

    Donnez un nom à votre tâche et assignez-lui un utilisateur (root).

  2. dans l’onglet Programmer, ajouter la fréquence de lancement du script :

    NAS Synology : télécharger automatiquement les sous-titres avec Subliminal photo 1

  3. enfin, dans l’onglet Paramètres de tâches, donnez le chemin du script précédé de la commande bash puisque c’est un script bash:

    NAS Synology : télécharger automatiquement les sous-titres avec Subliminal photo 4

    Ici, ce sera donc:

    bash /volume1/homes/matt/subby.sh

A vous les sous-titres synchros tous les soirs !

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 :

ssh admin@DiskStation

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+

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:

rm -rf /opt
ln -sf /volume1/@entware-ng/opt /opt

3. On lance le script d’installation:

Pour armv5:

wget -O - http://pkg.entware.net/binaries/armv5/installer/entware_install.sh | /bin/sh

Pour armv7:

wget -O - http://pkg.entware.net/binaries/armv7/installer/entware_install.sh | /bin/sh

Pour x86-32:

wget -O - http://pkg.entware.net/binaries/x86-32/installer/entware_install.sh | /bin/sh

Pour x86-64:

wget -O - http://pkg.entware.net/binaries/x86-64/installer/entware_install.sh | /bin/sh

Pour MIPS:

wget -O - http://pkg.entware.net/binaries/mipsel/installer/installer.sh | /bin/sh

4. On édite le fichier /etc/rc.local et on ajoute à la fin du fichier:

/bin/ln -sf /volume1/@entware-ng/opt /opt
/opt/etc/init.d/rc.unslung start

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:

NAS Synology : installer Entware en remplacement d'IPKG pour des applications à jour photo

avec les instructions suivantes:

/bin/ln -sf /volume1/@entware-ng/opt /opt
/opt/etc/init.d/rc.unslung start
NAS Synology : installer Entware en remplacement d'IPKG pour des applications à jour photo 1

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 !

Utiliser Rsync pour sauvegarder un serveur Debian/Ubuntu vers un NAS Synology photo

É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 :

ssh admin@IP_NAS

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 directory

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é :

ssh-keygen -t rsa

On copie la clé sur le serveur distant:

cat ~/.ssh/id_rsa.pub | ssh user@IP_SERVER "mkdir -p ~/.ssh && cat >>  ~/.ssh/authorized_keys"

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:

chmod /volume1/backup/.ssh 700
chmod /volume1/backup/.ssh/id_rsa.pub 644
chmod /volume1/backup/.ssh/id_rsa 600