Démarrer votre NAS Synology à distance avec Wake On Lan photo 1

Démarrer votre NAS Synology à distance grâce à Wake On Lan (WOL)

J’ai récemment réorganisé le matériel informatique de la maison pour ne plus voir la box et le NAS traîner dans la pièce à vivre.

J’avais tout mis là par défaut parce qu’il y avait une prise de téléphone à proximité mais finalement, a-t-on vraiment besoin d’avoir cela sous les yeux en permanence ?

Du coup, hop, tout est monté à l’étage. Le NAS Synology est configuré pour démarrer chaque soir, rapatrier les derniers épisodes et récupérer les derniers sous-titres puis s’éteindre à l’heure du coucher.

Mais il arrive parfois que l’on ait besoin d’avoir accès à nos fichiers en dehors de cette plage horaire… mais maintenant, il faut changer de pièce, monter l’escalier, redescendre et au final, on perd le fil de ce que l’on était en train de faire !

Voici donc comment démarrer votre NAS Synology à distance, sans bouger de votre chaise (pas bien!) en utilisant la fonction Wake On Lan.

La fonction Wake On Lan (WOL)

La fonction Wake On LAN (WOL) est une technologie qui permet de réveiller ou démarrer à distance un ordinateur ou périphérique qui est en veille ou éteint.

Le Disk Station Manager (DSM) du Synology posséde la fonction WOL, qui est présente sur la plupart des modèles de NAS de la marque, ce qui vous permet de démarrer votre NAS sans avoir à vous lever pour aller appuyer sur le bouton de mise sous tension.

Notez que les requêtes WOL sont plutôt destinées au réseau local.

Étape 1 : configuration du Wake On Lan (WOL) sur le Synology

Identifiez-vous sur le DSM et rendez-vous sur Panneau de Configuration > Matériel et Alimentation et cochez la case Activer WOL sur le réseau local:

Démarrer votre NAS Synology à distance avec Wake On Lan photo

Sauvegardez les changements.

Étape 2 : utiliser l’utilitaire WakeOnLan

Il existe un petit utilitaire, WakeOnLan, qui permet d’envoyer le paquet magique qui démarrera le Synology à distance:

Démarrer votre NAS Synology à distance avec Wake On Lan photo 1

WOL est activé lorsqu’un paquet magique (magic packet en anglais) est envoyé au NAS. Ce paquet magique contient les octets suivants FF FF FF FF FF FF suivi de l’adresse MAC de la carte réseau de destination répétée 16 fois.

Le paquet magique est une trame réseau transmise sur le port 0, 7 ou 9. Quand la carte réseau de destination reçoit cette trame, elle envoie un signal à la carte mère du périphérique et lance alors la séquence de démarrage.

Voilà – bon, bougez de temps en temps aussi hein !

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

Installer Redis pour accélérer WordPress sous Debian

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

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> pingCode language: CSS (css)

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-PASSECode language: PHP (php)

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

service redis-server restart

Lire la suite

PHP : configurer un pool PHP pour chaque site photo

PHP : configurer un pool PHP pour chaque site

Au départ, ce serveur n’avait qu’un seul site – celui que vous lisez en ce moment ;) – mais au fil du temps, plusieurs sites sont venus s’installer dans son giron.

Au début, nous n’avions donc besoin d’une seule configuration PHP – www.conf par défaut – qui est un pool (ou conteneur) selon la terminologie PHP.

Ce fichier de configuration dicte le nombre de threads PHP à lancer, les permissions, etc.

Afin de monter en charge et fournir à chaque site les ressources qui lui sont nécessaires, adoptons la stratégie “un site, un pool”.

Mise en place du nouveau pool PHP

Pour être sûr de partir d’une base éprouvée, copions notre pool de départ dans un nouveau fichier :

cp /etc/php/7.2/fpm/pool.d/www.conf /etc/php/7.2/fpm/pool.d/skyminds.conf

Editons ensuite notre pool :

nano /etc/php/7.2/fpm/pool.d/skyminds.conf

1. Nom du pool : remplacez [www] par le nom de votre site, ici [skyminds] de manière à pouvoir l’identifier plus aisément.

2. Vérifiez l’utilisateur et le groupe dans les directives user et group.

3. On modifie le nom du site dans la directive listen en utilisant le nom du pool que vous avez choisi dans l’étape 1:

listen = /run/php/skyminds.sockCode language: JavaScript (javascript)

Mise à jour de la configuration NginX

Il nous reste maintenant à mettre à jour la configuration du site :

nano /etc/nginx/sites-available/skyminds.net

Mettez à jour cette ligne (même chemin que la directive listen dans la configuration PHP):

fastcgi_pass unix:/run/php/skyminds.sock;Code language: JavaScript (javascript)

Relancez les services PHP et NginX:

service php7.4-fpm restart && service nginx restartCode language: CSS (css)

Lire la suite

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

Shell : créer une liste de mots de passe facilement

Créer une liste de mots de passe simples

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; doneCode language: JavaScript (javascript)

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.

Créer une liste de mots de passe sécurisés

La méthode précédente n’est pas vraiment sécurisée car le degré d’entropie est trop faible. Pour augmenter le niveau de sécurité, j’utilise cette commande:

for i in $(seq 1 8); do LC_CTYPE=C tr -dc '[:graph:]' < /dev/urandom | tr -d "'" | tr -d '"' | head -c 64 && echo; doneCode language: JavaScript (javascript)

Voici une explication de la commande :

  • for i in $(seq 1 8); do : Cela commence une boucle for qui se répète 8 fois (de 1 à 8).
  • LC_CTYPE=C : Cela définit la variable d’environnement LC_CTYPE à la valeur C, ce qui assure que le générateur de mots de passe utilise le jeu de caractères ASCII.
  • tr -dc '[:graph:]' < /dev/urandom : Cela utilise la commande tr pour supprimer les caractères non imprimables et générer des caractères graphiques aléatoires à partir de /dev/urandom, qui est une source d’entropie aléatoire sur les systèmes Unix.
  • tr -d "'" | tr -d '"' : Cela utilise deux commandes tr supplémentaires pour supprimer les caractères de guillemets simples (') et les guillemets doubles (") des mots de passe générés. Cela garantit que les guillemets simples et doubles sont supprimés des mots de passe générés.
  • head -c 32 : Cela utilise la commande head pour limiter la longueur des mots de passe générés à 32 caractères.
  • && echo; done : Cela termine la boucle for et ajoute un retour à la ligne (echo) pour afficher chaque mot de passe généré sur une ligne séparée.

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.

Linux : récupérer des vidéos depuis votre terminal avec MovGrab photo

Linux : récupérer des vidéos depuis votre terminal avec MovGrab

Movgrab est un outil en ligne de commande écrit en C (sans dépendances) qui permet de récupérer facilement des vidéos sur des sites comme YouTube, DailyMotion, Vimeo, Blip.tv, Liveleak, Guardian…

Il permet de choisir les flux disponibles sur les pages vidéo, supporte les proxies, peut reprendre des téléchargements… c’est une application très utile.

Liste des sites supportés par movgrab

Movgrab fonctionne avec:

  • YouTube
  • Metacafe
  • Dailymotion
  • Vimeo
  • Break.com
  • eHow
  • 5min.com
  • vbox7
  • blip.tv
  • Ted
  • MyVideo
  • ClipShack
  • MyTopClip
  • RedBalcony
  • Mobando
  • Yale University
  • Princeton University
  • Reuters
  • LiveLeak
  • Academic Earth
  • Photobucket
  • VideoEmo
  • VideosFacebook
  • Aljazeera
  • Mefeedia
  • IViewTube
  • Washington Post
  • CBS News
  • Euro News
  • MetaTube
  • MotionFeeds
  • Escapist
  • Guardian
  • RedOrbit
  • Sciive
  • Izlese
  • uctv.tv
  • royalsociety.tv
  • British Academy
  • Kitp
  • Dotsub
  • Astronomy.com
  • Teachertube.com
  • Discovery
  • Bloomberg.com

Lire la suite

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

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

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.netCode language: JavaScript (javascript)

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,347745Code language: CSS (css)

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.066848Code language: CSS (css)

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 !

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

Nginx : créer un nouveau site WordPress dans un sous-répertoire, sans conflit avec le site principal

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.

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;
}Code language: PHP (php)

Sauvegardez le fichier. On teste la nouvelle configuration:

nginx -t

et on relance nginx et PHP:

service nginx restart 
service php7.2-fpm restartCode language: CSS (css)

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

Subliminal : résoudre l'erreur "AttributeError: list object has no attribute lower" photo

Subliminal : résoudre l’erreur “AttributeError: list object has no attribute lower”

Dernièrement, le script python que j’ai écrit pour télécharger les sous-titres automatiquement avec Subliminal a renvoyé le message d’erreur suivant :

AttributeError: 'list' object has no attribute 'lower'Code language: JavaScript (javascript)

Il se trouve que l’attribut lower ne peut-être appliqué qu’à des variables (type string) et non pour des objets (type array).

Nous allons donc éditer le code source de subliminal pour corriger le problème.

Ajout de nouvelles directives à subtitle.py

1. On se connecte au Synology en SSH:

ssh admin@SYNOLOGYCode language: CSS (css)

2. On passe root:

sudo -i

3. On recherche le fichier subtitle.py :

find / -type f -name "subtitle.py"Code language: JavaScript (javascript)

Résultat, 3 fichiers trouvés sur le NAS:

/usr/lib/python2.7/site-packages/subliminal/subtitle.py
/volume1/@appstore/VideoStation/subtitle_plugins/syno_subscene/subtitle.py
/volume1/@appstore/subliminal/env/lib/python2.7/site-packages/subliminal/subtitle.py

4. Le fichier qui nous intéresse se trouve sous /usr/lib donc nous l’éditons:

nano /usr/lib/python2.7/site-packages/subliminal/subtitle.py

5. Faites une recherche avec le terme lower (avec Ctrl+W sous nano). Vous trouver cette ligne:

    # format
    if video.format and 'format' in guess and guess['format'].lower() == video.format.lower():
       matches.add('format')Code language: PHP (php)

Nous allons commenter ces lignes et ajouter des conditions pour que lower ne soit appliqué qu’aux chaînes (type string):

    # format
    #if video.format and 'format' in guess and guess['format'].lower() == video.format.lower():
       #matches.add('format')
    if video.format and 'format' in guess:
       guess_format = guess['format'] if isinstance(guess['format'], list) else [guess['format']]
       if any(gf.lower() == video.format.lower() for gf in guess_format):
            matches.add('format')Code language: PHP (php)
Attention à bien respecter le nombre d’espaces pour l’indentation : il s’agit d’un script python donc très tatillon à ce sujet !

6. Sauvegardez le fichier.

7. Relancez la recherche automatique des sous-titres : plus d’erreurs relatives à l’attribut lower :)

Enjoy!

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

WordPress: mettre un plugin à jour sur plusieurs sites sur le serveur en une seule opération

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.

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à !

Lire la suite

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

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

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.

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.

Lire la suite

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

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

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.

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

ous 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.shCode language: JavaScript (javascript)

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)Code language: JavaScript (javascript)

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.

Backup Manager : résoudre l'erreur "tar: file changed as we read it" lors de la création de la sauvegarde photo

Backup Manager : résoudre l’erreur “tar: file changed as we read it” lors de la création de la sauvegarde

Cela fait quelques jours que Backup Manager, qui me sert à sauvegarder automatiquement les fichiers et bases de données du site sur le serveur de sauvegarde, renvoie une erreur lors de la création d’un de mes fichiers de sauvegarde, alors que tout se passait sans encombres jusqu’alors.

C’est gênant dans le sens où on ne sait pas vraiment ce qui a empêché la bonne création du fichier et on ne peut vraiment être certain de l’intégrité du fichier de sauvegarde, ce qui est critique.

Voici le message d’erreur reçu par email à la fin de la sauvegarde :

Unable to create "/home/archives/mail.skyminds.net-home.20180208.master.tar.gz", check /tmp/bm-tarball.log.TZ2VAU
1 error occurred during the tarball generation.Code language: JavaScript (javascript)

Et voici le contenu du fichier log en question :

tar: /wp-content/ file changed as we read itCode language: JavaScript (javascript)

Étapes du débogage

Le moins que l’on puisse dire, c’est que tar ne nous donne pas vraiment d’indications sur la cause du problème. Un fichier qui change lors de la lecture, d’accord mais lequel ? De plus, il indique un répertoire et non un fichier précis.

Dans le fichier de configuration de Backup Manager, il est possible de choisir plusieurs formats de fichier pour compresser les fichiers de sauvegarde. J’utilise .tar.gz puisque tous mes machines tournent sous Unix mais là, j’ai changé la configuration pour utiliser le format zip.

On relance le script de sauvegarde : zip est beaucoup plus loquace dans ses messages d’erreur !

Voici ce qu’il nous indique :

zip warning: Not all files were readable
  files/entries read:  55621 (1.3G bytes)  skipped:  96 (414K bytes)

Très bien. Il ne nous reste plus qu’à trouver quels sont ces fichiers qui n’ont pas les droits de lecture.

A la racine du site, on lance donc une recherche pour trouver tous les fichiers et dossiers qui n’auraient pas les droits basiques de lecture (read) :

find . ! -perm -o=r

Résultat :

./wp-content/plugins/amazonsimpleadmin/cache/zend_cache---internal-metadatas---B0089KSLUY
./wp-content/plugins/amazonsimpleadmin/cache/zend_cache---internal-metadatas---CustomerReviews_B004LS7G3G
./wp-content/plugins/amazonsimpleadmin/cache/zend_cache---CustomerReviews_B00B2OI0FU
./wp-content/plugins/amazonsimpleadmin/cache/zend_cache---B00JGYYQ24
./wp-content/plugins/amazonsimpleadmin/cache/zend_cache---CustomerReviews_B006H4R9LG
./wp-content/plugins/amazonsimpleadmin/cache/zend_cache---internal-metadatas---B005BHE48Q
./wp-content/plugins/amazonsimpleadmin/cache/zend_cache---internal-metadatas---B00H2O1YOI
./wp-content/plugins/amazonsimpleadmin/cache/zend_cache---CustomerReviews_B00MVQLMPI
./wp-content/plugins/amazonsimpleadmin/cache/zend_cache---B017EOYW9Y

Il s’agit donc de fichiers de cache de produits Amazon, qui sont absolument inutiles pour les sauvegardes: nous allons donc exclure ce répertoire de cache de nos fichiers de backup.

Suppression des répertoires de cache avant compression des archives

Dans la configuration de Backup Manager, ajoutez le chemin des répertoires de cache de quasiment tous les plugins WordPress :

export BM_TARBALL_BLACKLIST="/home/public_html/wp-content/plugins/*/cache/* /home/public_html/wp-content/*cache*"Code language: JavaScript (javascript)

Sauvegardez le fichier et relancez votre script de backup.

Méthode plus radicale : éditer le script

Si la méthode précédente ne porte pas ses fruits, en voici une autre. Il suffit de modifier la valeur du chmod dans ces deux fichiers :

/wp-content/plugins/amazonsimpleadmin/lib/AsaZend/Cache/Backend/File.php
/wp-content/plugins/amazonsimpleadmin/lib/AsaZend/Cache/Backend/Static.phpCode language: PHP (php)

Cherchez le chmod 600 :

'cache_file_umask' => 0600,Code language: PHP (php)

et remplacez-le par un chmod 644:

'cache_file_umask' => 0644,Code language: PHP (php)

Tada, plus d’erreur et des fichiers de sauvegarde propres, sans fichiers de cache inutiles !

Je suis assez content d’avoir trouvé une solution à ce problème assez récurrent.

Le fait d’avoir momentanément modifié le type d’archive à créer a bien aidé à isoler la cause du problème.