Tag

bash

Browsing

Aujourd’hui, nous installons le serveur Redis pour accélérer les temps de chargement de tous les sites présents sur le serveur.

Installer Redis pour accélérer WordPress sous Debian photo

Redis (de l’anglais REmote DIctionary Server qui peut être traduit par « serveur de dictionnaire distant » et jeu de mot avec Redistribute1) est un système de gestion de base de données clef-valeur scalable, très hautes performances, écrit en C ANSI. Il fait partie de la mouvance NoSQL et vise à fournir les performances les plus élevées possibles.

Redis permet de manipuler des types de données simples : chaînes de caractères, tableaux associatifs, listes, ensembles et ensembles ordonnés.

Une des principales caractéristiques de Redis est de conserver l’intégralité des données en RAM. Cela permet d’obtenir d’excellentes performances en évitant les accès disques, particulièrement coûteux sur ce plan.

Lorsqu’une page WordPress est chargée par exemple, des requêtes sur la base de données sont lancées et cela prend un certain temps pour récupérer ces informations. Lorsque Redis est activé, il garde ces requêtes SQL en mémoire, ce qui permet de gagner en temps de chargement des pages.

Voici donc le tutoriel pour mettre en place Redis sur votre serveur. Cela prend environ 15 minutes.

Installation du serveur Redis

Nous installons le serveur Redis et le paquet PHP associé:

apt install redis-server php-redis

Nous vérifions que Redis est bien actif, il nous suffit de lancer redis-cli:

redis-cli

On tape ping dans l’invite:

127.0.0.1:6379> ping

Réponse:

PONG

Parfait, le serveur Redis est bien installé et actif.

Configuration de Redis

Editons le fichier de configuration de Redis :

nano /etc/redis/redis.conf

Changez les valeurs suivantes :

maxmemory 256mb # max memory 
maxmemory-policy allkeys-lru # replace old keys with fresher ones
requirepass VOTRE-MOT-DE-PASSE

Enregistrez et relancez le serveur pour prendre en charge la nouvelle configuration:

service redis-server restart

Shell : créer une liste de mot de passe facilement photo

Voici un moyen très simple de créer une liste de mots de passe en utilisant le terminal sous Linux ou MacOS par exemple :

for i in `seq 1 8`; do mktemp -u XXXXXXXXXXXXXXXXXXXXXXXX; done

Explications sur le fonctionnement de la commande:

  • seq 1 8 va nous créer 8 mots de passe différents,
  • mktemp -u XXXXXXXXXXXXXXXXXXXXXXXX va nous créer des mots de passe alphanumériques dont le nombre de caractères dépend du nombre de X. Ici, j’ai mis 24 X donc les mots de passe feront 24 caractères.

Simple et efficace, j’utilise souvent cette commande lors de la création ou l’import d’utilisateurs en masse, lors de la création d’un fichier CSV par exemple. Cela permet d’avoir des mots de passe un minimum sécurisés dès le départ de la création des comptes utilisateurs.

Le Time to First Byte (TTFB) est le temps de chargement du premier octet, c’est la mesure qui nous permet d’évaluer la vitesse d’accès à un serveur. Plus la mesure est basse et plus le serveur commencera à servir les ressources rapidement.

Calculer le Time To First Byte (TTFB) d'un serveur photo

Le ping comme moyen de contrôle

A l’origine le “ping” vient du bruit effectué par l’écho d’un sonar, le temps entre deux ping indiquant la distance parcourue par le signal pour détecter les fonds marins et revenir vers un navire. Les sons courts n’étaient pas de bons signaux pour un capitaine, puisqu’ils indiquaient que le danger se rapprochait de la coque du navire.

Le ping correspond pour nous au TTFB car il nous permet de mesurer la réactivité d’un serveur ou d’une ressource réseau.

Le ping comme mesure du Time To First Byte

Le TTFB mesure le temps écoulé entre la requête d’un client qui effectue une requête HTTP et le premier octet de la page reçu dans le navigateur du client. Ce temps se compose du temps de connexion au socket, du temps pris pour envoyer la requête HTTP, et du temps pris pour recevoir le premier octet de la page.

Le calcul du TTFB inclut toujours la latence du réseau lorsqu’il calcule le temps que prend une ressource avant de se charger. Ce temps varie en fonction de plusieurs critères: l’éloignement entre le serveur et le client, la qualité de la connexion, ou les questions de connexion directe (réseau filaire) ou indirecte (WI-FI, 3G, etc) sont des facteurs modifiant le ping.

Un TTFB faible est perçu comme une indication d’un serveur bien configuré. Cela signifie que moins de calculs dynamiques sont effectués par le serveur ou alors que le cache (DNS, serveur, ou applicatif) est en place.

Calcul to TTFB avec curl

Il existe pas mal de services en ligne qui permettent de calculer le TTFB mais il est aussi très simple de le calculer soi-même, avec un simple terminal avec curl :

curl -o /dev/null -w "Connect: %{time_connect} TTFB: %{time_starttransfer} Total time: %{time_total} \n" https://www.skyminds.net

Ce qui nous donne le résultat suivant depuis chez moi:

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 54616    0 54616    0     0   153k      0 --:--:-- --:--:-- --:--:--  153k

Connect: 0,039729 TTFB: 0,269024 Total time: 0,347745

A titre indicatif, si on lance la requête depuis le serveur:

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 54616    0 54616    0     0   797k      0 --:--:-- --:--:-- --:--:--  808k

Connect: 0.001645 TTFB: 0.066232 Total time: 0.066848

On peut voir une sacrée différence, dû au temps de latence et à l’éloignement géographique. Une autre raison pour laquelle il faut travailler sur la baisse du TTFB : si le TTFB met 270ms en France, à combien sera-t-il pour un visiteur Américain ou Australien ?

Concrètement, plus la connexion au serveur est rapide et plus le site se chargera tôt, ce qui a un fort impact sur le ranking du site. A surveiller donc !

Dernièrement, j’ai développé un nouveau site WordPress pour une cliente dont l’hébergement ne prévoit pas de staging site, ce qui est un peu ballot.

Plutôt que d’utiliser son hébergeur, je me suis dit que j’allais travailler sur la nouvelle version depuis un répertoire sous SkyMinds.

Ajouter un nouveau site WordPress dans un répertoire, sans conflit avec le site principal photo

Le problème s’est assez rapidement posé : les diverses règles de configuration de SkyMinds (à la racine du domaine) entrent en conflit avec le nouveau site qui se trouve dans un répertoire. Il est donc nécessaire d’ajuster la configuration du bloc serveur NginX.

J’ai bien sûr effectué quelques recherches sur le net et après moults tests, il s’avère que la plupart des configurations nginx que l’on y trouve sont erronées. En relisant les docs, j’ai fini par trouver une solution satisfaisante.

Des erreurs 404, 403 ou 500

Je mentionnais à l’instant les configurations erronées – elles ne permettent pas au nouveau site d’afficher les pages correctement : erreur 404 pour les pages, erreur 404 pour la partie administration ou alors erreur 403 ou même 500…

Le plus surprenant est que l’on retrouve quasiment ces mêmes configurations dans tous les tutoriels. Cela fonctionnait peut-être à une époque mais plus maintenant avec les dernières versions de WordPress et NginX.

La configuration qui fonctionne

Voici donc la configuration que j’ai concoctée et qui permet d’avoir un autre site WordPress (comme par exemple https://example.com/nouveau-site/) lorsqu’un site WordPress (de type https://example.com) existe déjà à la racine du domaine. Le but est donc d’avoir deux sites fonctionnels qui n’entrent pas en conflit au niveau de la gestion des règles.

On édite le server block de notre domaine :

nano /etc/nginx/sites-available/example.com

Dans la partie server de la configuration, on ajoute :


# Script name : Add new WP site in subfolder
# Author : Matt Biscay
# Author URI : https://www.skyminds.net/?p=29604

# Add new location point with rewrite rule
location @nouveausite{
rewrite . /nouveau-site/index.php last;
}

# Add subfolder config
location  /nouveau-site {
         root /home/example/public_html/nouveau-site;
         index index.php;
         try_files $uri $uri/ @nouveausite;
}

Sauvegardez le fichier. On teste la nouvelle configuration:

nginx -t

et on relance nginx et PHP:

service nginx restart 
service php7.2-fpm restart

Et voilà, le nouveau site dans son répertoire devrait maintenant être fonctionnel, sans conflit avec le site principal.

Sur un serveur qui héberge plusieurs sites WordPress différents, il est fort probable qu’il y ait quelques plugins en commun sur chaque installation.

WordPress permet de mettre à jour les thèmes et plugins en quelques clics mais cela suppose de s’identifier sur chaque site ou alors de donner permission à une application tierce comme JetPack pour vous faciliter la tâche.

WorddPress : éviter d'avoir à mettre le même plugin à jour sur chaque site hébergé sur le serveur photo

Cela suppose toutefois de bien vouloir rassembler toutes les autorisations sur un seul compte, ce qui n’est pas optimal puisqu’il n’y a plus cloisonnement entre les sites hébergés.

Nous allons donc mettre en place un système de liens symboliques (symlink ou symbolic link en anglais) pour gagner pas mal de temps lors des mises à jour.

Principe d’optimisation de la mise à jour des plugins récurrents

Sur le serveur, j’utilise une petite astuce tout simple : j’utilise mon site comme master officiel du serveur. C’est lui que je mets à jour en premier et tous les autres sites “hériteront” des nouvelles mises à jour, automatiquement et sans manipulation de ma part.

Mise en place de liens symboliques

Comme le serveur tourne sous Linux, il nous suffit de faire un lien symbolique sur le site slave vers le dossier d’un plugin qui se trouve sur le site master.

Lorsque je mettrai certains plugins de SkyMinds à jour par exemple, ces plugins qui sont également installés sur le site du Centre de Kriya Yoga France seront également à jour. En fait, aucun fichier de ce plugin ne sera présent chez eux, seul un lien symbolique.

Concrètement, voici la marche à suivre :

  1. On se place dans le répertoire /wp-content/plugins du site slave (kriyayoga.fr dans cet exemple):
    cd /kriyayoga/wp-content/plugins
  2. On crée un lien symbolique qui va pointer vers le répertoire qui se trouve dans le répertoire de SkyMinds :
    ln -s /skyminds/wp-content/plugins/my-plugin my-plugin
  3. Et voilà !

A la maison, je galère un peu avec les taux de transfert des fichiers entre ma machine fixe (The Reaper) et le NAS Synology.

NAS Synology : mapper un répertoire du NAS sur un répertoire local sous Ubuntu photo 2

Lors des transferts via le navigateur, la vitesse arrive à peu près à 2MB/s, ce qui, excusez-moi du peu, sonne comme une douce plaisanterie.

Pour pallier ce problème, nous allons donc “mapper” un des répertoires du NAS directement dans un répertoire local de ma machine. Comme cette dernière tourne sous Ubuntu, il suffira dans Nautilus de copier des fichiers ou dossiers dans ce répertoire pour que tout soit uploadé directement dans le NAS. Un gain de temps en perspective !

Activation de NFS sur le NAS

Sur le NAS, nous allons avoir besoin du protocole NFS (Network File System). Rendez vous dans Control Panel > File Sharing > File Services > cochez la case pour activer le service NFS et appliquez les changements:

NAS Synology : mapper un répertoire du NAS sur un répertoire local sous Ubuntu photo

Ensuite, cliquez sur l’icône qui se trouve juste au dessus, Shared folders :

  1. créez un nouveau dossier partagé. Je vais prendre NetBackup comme exemple pour ce tutoriel.
  2. sélectionnez le dossier > cliquez sur Edit > sélectionnez l’onglet NFS permissions.
  3. cliquez sur Create pour ajouter une nouvelle politique de droits NFS sur ce dossier.

Voici les droits à accorder:

NAS Synology : mapper un répertoire du NAS sur un répertoire local sous Ubuntu photo 1

Configuration :

  • Hostname/IP : on indique l’IP de la machine locale. Sur mon réseau local, 192.168.0.10 est l’adresse de ma machine fixe.
  • Privileges: Read/Write pour lecture et écriture.
  • Squash : Map root to admin. Cela permet de monter automatiquement le répertoire au démarrage de la machine.
  • Je laisse coché toutes les autres options, les transferts asynchrones ne me dérangent pas.

Au début du mois de février, l’université de Graz et Google Project Zero ont annoncé avoir découvert deux failles de sécurité importantes s’appuyant sur les mécanismes de fonctionnement interne des processeurs.

Serveur dédié : mise à jour du kernel OVH pour combler les failles Spectre et Meltdown photo

Trois vulnérabilités permettant d’accéder à de la mémoire privilégiée ont été publiées, qui ont pour point commun d’exploiter les mécanismes d’exécution spéculative et les timings des caches mémoires.

Meltdown

La première faille, Meltdown (CVE-2017-5754), permet de bypasser les mécanismes d’isolation mémoire entre mémoire classique (utilisée par les applications) et mémoire kernel (utilisée par le noyau du système d’exploitation, et protégée normalement par des mécanismes hardware dans le CPU).

Meltdown est une attaque side channel permanent;qui s’attaque à une faille de certains processeurs OOO (Out Of Order, la plupart des processeurs performants modernes depuis le Pentium Pro) qui, dans leur mécanismes d’exécution spéculatifs, peuvent non seulement lire des données mémoires protégées mais aussi exécuter des instructions sur ces données mémoires.

Concrètement, avec Meltdown, il est possible de lire tout type de mémoire à partir d’un process malicieux, y compris côté serveur de bypasser toutes les protections de type VM/Hyperviseur/Docker. Meltdown touche spécifiquement les architectures d’Intel et ARM.

Spectre

En parallèle à Meltdown, une autre faille a été dévoilée baptisée Spectre. permanent;Pour Spectre, la situation est plus compliquée. Il s’agit toujours d’une variation sur le même thème, à savoir tenter d’exploiter les mécanismes d’exécution spéculative des processeurs. Tous les processeurs modernes sont concernés a différents niveau et l’on retrouve, y compris chez un même constructeur, des différences d’une architecture à l’autre en fonction des mécanismes précis de fonctionnement de chaque génération.

Le papier décrit deux attaques distinctes. La première, connue sous le nom de CVE-2017-5753 (bounds check bypass) permet à un processus d’accéder, dans certains conditions un peu plus complexes, à la mémoire d’un autre processus. Contrairement à Meltdown dont l’exploitation est triviale, il faut ici connaître les spécificités du programme que l’on attaque pour réussir à l’exploiter.

Le groupe Google Project Zero a montré que cette attaque était exploitable aussi bien sur les CPU Intel, AMD (FX et APU), et ARM (un Cortex A57 à été testé). Si tous les processeurs sont exploitables, c’est que tous les modèles OOO modernes reposent, dans les grandes lignes, sur l’algorithme de Tomasulo, du nom de l’ingénieur qui l’a développé en 1967 chez IBM.

Virtuellement, tous les systèmes (du serveur au smartphone) sont vulnérables à cette attaque pour laquelle des PoC existent même en Javascript (pour bypasser les barrières des VM qui isolent le code Javascript de vos différents onglets), ce qui la rend assez grave. Des méthodes de mitigations, aussi bien au niveau des compilateurs, des navigateurs, et des systèmes d’exploitations sont en cours de développement et des patchs sont attendus rapidement pour limiter le problème.

Vous pouvez retrouver les détails techniques des failles Spectre et Meltdown chez OVH.

Mon machine est-elle touchée par ces failles?

Il vous suffit de tester votre processeur avec le script Spectre & Meltdown Checker:

curl -L https://meltdown.ovh -o spectre-meltdown-checker.sh
chmod +x spectre-meltdown-checker.sh
sh ./spectre-meltdown-checker.sh

Résultat avant la mise à jour du kernel:

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Checking count of LFENCE opcodes in kernel:  NO 
> STATUS:  VULNERABLE  (only 46 opcodes found, should be >= 70, heuristic to be improved when official patches become available)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigation 1
*   Hardware (CPU microcode) support for mitigation:  NO 
*   Kernel support for IBRS:  NO 
*   IBRS enabled for Kernel space:  NO 
*   IBRS enabled for User space:  NO 
* Mitigation 2
*   Kernel compiled with retpoline option:  NO 
*   Kernel compiled with a retpoline-aware compiler:  NO 
> STATUS:  VULNERABLE  (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate the vulnerability)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Kernel supports Page Table Isolation (PTI):  NO 
* PTI enabled and active:  NO 
> STATUS:  VULNERABLE  (PTI is needed to mitigate the vulnerability)

Mise à jour du kernel OVH

Sur la Kimsufi, c’est le kernel OVH 4.9.87 qui intégre tous les correctifs Meltdown et Spectre, ainsi que la mise à jour du microcode pour les puces Intel.

Il suffit de suivre le tutoriel pour mettre à jour le noyau OVH.

Après mise à jour du noyau et redémarrage du serveur, les failles semblent maintenant comblées:

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Checking whether we're safe according to the /sys interface:  YES  (kernel confirms that the mitigation is active)
> STATUS:  NOT VULNERABLE  (Mitigation: __user pointer sanitization)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Checking whether we're safe according to the /sys interface:  YES  (kernel confirms that the mitigation is active)
> STATUS:  NOT VULNERABLE  (Mitigation: Full generic retpoline)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Checking whether we're safe according to the /sys interface:  YES  (kernel confirms that the mitigation is active)
> STATUS:  NOT VULNERABLE  (Mitigation: PTI)

Voilà, mettez vos noyaux à jour, c’est important.

Récemment, j’ai installé un serveur en Chine, derrière le Great Firewall of China (GFW) pour un des mes clients. Le code n’a pas de frontières mais la langue peut parfois poser problème – même pour un système d’exploitation, au niveau de la locale.

Linux : résoudre Cannot set LC_ALL to default locale

Les locales sont un ensemble de paramètres qui définissent la langue de l’utilisateur, sa région et les préférences régionales que l’utilisateur souhaire voir dans son interface.

Typiquement, une locale est identifiée par un code langue suivi d’un identifiant de région. Nous avons par exemple “en_US.UTF-8” pour l’anglais américain (en pour l’anglais, US pour les USA) ou “fr_FR.UTF-8” pour le français de France.

Dans le cas de mon serveur chinois, qui tourne sous Debian, les paramètres de la locale n’étaient pas uniformément remplis avec le même code langue et certains paramètres étaient manquants.

On obtenait donc ces messages lors d’un apt update :

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
	LANGUAGE = (unset),
	LC_ALL = (unset),
	LANG = "fr_FR.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").

ou encore ces messages avec apt upgrade, après chaque installation ou mise à jour de paquets :

locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory

Pas de panique, j’ai quelques solutions pour régler le problème si vous aussi y êtes confronté.

Dans ce tutoriel, j’utilise “en_US.UTF-8” parce que j’aime tout avoir en anglais. Si vous préférez le français, remplacez tout par “fr_FR.UTF-8”.

Etape 1 : éditez le fichier locale

Editez votre fichier /etc/default/locale :

nano /etc/default/locale

et ajoutez ces lignes:

LC_ALL=en_US.UTF-8
LC_CTYPE=en_US.UTF-8
LC_MESSAGES=en_US.UTF-8
LANG=en_US.UTF-8
LANGUAGE=en_US.UTF-8

Enregistrez le fichier, quittez votre session SSH puis reconnectez-vous pour avoir une nouvelle session avec le changement de locale.

Etape 2 : reconfigurer les locales

On commence par générer la locale de notre choix :

locale-gen "en_US.UTF-8"

Et on la reconfigure :

dpkg-reconfigure locales

Il ne reste plus qu’à tester les locales du système:

locale

Résultat:

LANG=en_US.UTF-8
LANGUAGE=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=en_US.UTF-8

Et voilà, plus de messages d’avertissement ou d’erreur concernant les locales de votre système. Problème réglé.

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, 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

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

Si l’on souhaite rajouter pas mal de fonctionnalités à un NAS Synology, on est vite limité par les applications officielles. On peut passer par IPKG ou alors tout simplement installer pip, le gestionnaire de paquets Python.

Synology : installer PIP, le gestionnaire de paquets Python photo

Voici comment installer pip sur votre NAS Synology en moins de 3 minutes.

Installation de pip sur votre Synology

Pré-requis : vous devez avoir installé Python (version 2.7 chez moi) depuis le gestionnaire de paquets du DSM.

1. On commence par ouvrir une session SSH avec l’utilisateur root sur le port 22 de l’IP de notre NAS :

ssh -l admin 192.168.IP.NAS -p22
sudo -i

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 :

wget https://bootstrap.pypa.io/get-pip.py

3. et on installe pip :

python get-pip.py

Cela prend un peu de temps. Voici ce que vous devriez obtenir :

Collecting pip
  Downloading pip-8.1.2-py2.py3-none-any.whl (1.2MB)
    100% |████████████████████████████████| 1.2MB 103kB/s 
Collecting setuptools
  Downloading setuptools-27.1.2-py2.py3-none-any.whl (464kB)
    100% |████████████████████████████████| 471kB 99kB/s 
Collecting wheel
  Downloading wheel-0.29.0-py2.py3-none-any.whl (66kB)
    100% |████████████████████████████████| 71kB 535kB/s 
Installing collected packages: pip, setuptools, wheel
Successfully installed pip-8.1.2 setuptools-27.1.2 wheel-0.29.0

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.
  list                        List 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.

A vous les paquets Python sur votre Synology !