Serveur dédié : mettre à jour OpenSSL sous Debian pour bénéficier de TLS 1.3 photo

Serveur dédié : mettre à jour OpenSSL sous Debian pour bénéficier de TLS 1.3

Cet article fait suite à un précédent tutoriel – installer la dernière version d’OpenSSL sous Debian.

Cela fait un petit moment que je voulais mettre à jour ma configuration TLS et je me suis dit que la Toussaint serait parfaite pour cela.

Aujourd’hui, le serveur passe donc à TLS 1.3, ce qui nécessite une mise à jour d’OpenSSL et la mise à jour des ciphers sous NginX.

Mise à jour d’OpenSSL

Je n’avais pas mis OpenSSL à jour depuis le dernier tuto donc il est aisé de connaitre sa version:

openssl version

Résultat :

OpenSSL v1.1.0f

Un autre moyen de connaître les versions disponibles dans les repos:

dpkg -l '*openssl*' | awk '/^i/{print $2}' | xargs apt-show-versions -a

Résultat:

openssl:amd64 1.1.0f-5 install ok installed
openssl:amd64 1.1.0f-3+deb9u2 stable debian.mirrors.ovh.net
openssl:amd64 1.1.0f-3+deb9u2 stable security.debian.org
openssl:amd64 1.1.0f-5 newer than version in archive
perl-openssl-defaults:amd64 3 install ok installed
perl-openssl-defaults:amd64 3 stable debian.mirrors.ovh.net
perl-openssl-defaults:amd64/stable 3 uptodate
python3-openssl:all 16.2.0-1 install ok installed
python3-openssl:all 16.2.0-1 stable debian.mirrors.ovh.net
python3-openssl:all/stable 16.2.0-1 uptodate

Pour obtenir la version 1.1.1 d’OpenSSL, qui est le sésame pour TLS 1.3, nous allons temporairement ajouter le repo sid, mettre à jour OpenSSL et ses dérivés puis remettre apt dans sa position stable.

On met à jour nos sources apt:

nano /etc/apt/sources.list

et on y ajoute sid:

deb http://ftp.debian.org/debian sid main
deb-src http://ftp.debian.org/debian sid main

On met à jour apt:

apt update

Et on met à jour openssl:

apt install openssl libssl1.1

Résultat:

Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  libc-bin libc-dev-bin libc-l10n libc6 libc6-dev libc6-i386 libnih-dbus1 libnih1 libssl-dev locales
  python-httplib2
apt-listchanges: News
---------------------

glibc (2.26-5) unstable; urgency=medium

  Starting with version 2.26-1, the glibc requires a 3.2 or later Linux
  kernel.  If you use an older kernel, please upgrade it *before*
  installing this glibc version. Failing to do so will end-up with the
  following failure:

    Preparing to unpack .../libc6_2.26-5_amd64.deb ...
    ERROR: This version of the GNU libc requires kernel version
    3.2 or later.  Please upgrade your kernel before installing
    glibc.

  The decision to not support older kernels is a GNU libc upstream
  decision.

  Note: This obviously does not apply to non-Linux kernels.

 -- Aurelien Jarno <aurel32@debian.org>  Tue, 23 Jan 2018 22:03:12 +0100

openssl (1.1.1-2) unstable; urgency=medium

  Following various security recommendations, the default minimum TLS version
  has been changed from TLSv1 to TLSv1.2. Mozilla, Microsoft, Google and Apple
  plan to do same around March 2020.

  The default security level for TLS connections has also be increased from
Suggested packages:
  glibc-doc
The following packages will be upgraded:
Setting up libc6-i386 (2.27-8) ...
Setting up python-httplib2 (0.11.3-1) ...
Processing triggers for libc-bin (2.27-8) ...
Setting up libssl1.1:amd64 (1.1.1-2) ...
locale: Cannot set LC_ALL to default locale: No such file or directory
Setting up libc-l10n (2.27-8) ...
Setting up openssl (1.1.1-2) ...
Installing new version of config file /etc/ssl/openssl.cnf ...
Processing triggers for man-db (2.7.6.1-2) ...
Setting up libc-dev-bin (2.27-8) ...
Setting up libc6-dev:amd64 (2.27-8) ...
Setting up locales (2.27-8) ...
Installing new version of config file /etc/locale.alias ...
Generating locales (this might take a while)...
  en_GB.ISO-8859-1... done
  en_GB.UTF-8... done
  en_GB.ISO-8859-15... done
Generation complete.
Setting up libnih1 (1.0.3-10+b1) ...
Setting up libnih-dbus1 (1.0.3-10+b1) ...
Setting up libssl-dev:amd64 (1.1.1-2) ...
Processing triggers for libc-bin (2.27-8) ...
Scanning processes...
Scanning candidates...
Scanning linux images...
Failed to retrieve available kernel versions.
Restarting services...
 invoke-rc.d bind9 restart
 invoke-rc.d cgmanager restart
 invoke-rc.d cgproxy restart
 invoke-rc.d fail2ban restart
ERROR  No section: 'Definition'
ERROR  No section: 'Definition'
ERROR  No section: 'Definition'
ERROR  No section: 'Definition'
ERROR  No section: 'Definition'
ERROR  No section: 'Definition'
ERROR  No section: 'Definition'
ERROR  No section: 'Definition'
 invoke-rc.d haveged restart
 invoke-rc.d irqbalance restart
 invoke-rc.d lvm2-lvmetad restart
 invoke-rc.d lvm2-lvmpolld restart
 invoke-rc.d lwresd restart
 invoke-rc.d mdadm restart
 invoke-rc.d mdadm-waitidle restart
 invoke-rc.d minissdpd restart
 invoke-rc.d nginx restart
 invoke-rc.d opendkim restart
 invoke-rc.d opendmarc restart
 invoke-rc.d php7.2-fpm restart
 invoke-rc.d postfix restart
 invoke-rc.d redis-server restart
 invoke-rc.d rsyslog restart
 invoke-rc.d saslauthd restart
 invoke-rc.d ssh restart
Services being skipped:
 invoke-rc.d dbus restart
No containers need to be restarted.</aurel32@debian.org>

On teste notre nouvelle verison d’openssl:

openssl version

Résultat:

OpenSSL 1.1.1  11 Sep 2018

Et en un peu plus précis:

dpkg -l '*openssl*' | awk '/^i/{print $2}' | xargs apt-show-versions -a

Résultat:

openssl:amd64 1.1.1-2 install ok installed
openssl:amd64 1.1.0f-3+deb9u2 stable debian.mirrors.ovh.net
openssl:amd64 1.1.0f-3+deb9u2 stable security.debian.org
openssl:amd64 1.1.1-2         sid    ftp.debian.org
openssl:amd64/sid 1.1.1-2 uptodate
perl-openssl-defaults:amd64 3 install ok installed
perl-openssl-defaults:amd64 3 stable debian.mirrors.ovh.net
perl-openssl-defaults:amd64 3 sid    ftp.debian.org
perl-openssl-defaults:amd64/stable 3 uptodate
python3-openssl:all 16.2.0-1 install ok installed
python3-openssl:all 16.2.0-1 stable debian.mirrors.ovh.net
python3-openssl:all 18.0.0-1 sid    ftp.debian.org
python3-openssl:all/stable 16.2.0-1 upgradeable to 18.0.0-1

Mettre à jour les ciphers pour NginX

Il ne nous reste plus qu’à ajouter les nouveaux ciphers pour TLS 1.3 pour les services sécurisés.

Nous mettons donc la configuration des server blocks NginX à jour:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers "TLS13+AESGCM+AES128:EECDH+AESGCM:EECDH+CHACHA20";

On vérifie la configuration:

nginx -t

et on redémarre le serveur:

service nginx restart

Il ne vous reste plus qu’à vérifier votre configuration TLS sur SSL Labs.

Serveur dédié : remplacer gzip par pigz pour profiter de la compression multi-core photo

Serveur dédié : remplacer gzip par pigz pour profiter de la compression multi-core

Tous les matins, une sauvegarde des sites hébergés sur le serveur est effectuée.

A ce moment là, gzip tourne à plein régime et utilise pendant un certain temps le CPU – la montée en charge atteint 50%, ce qui devient limite pour la réactivité des sites Et pour cause : gzip ne fonctionne qu’en mono-core.

Il nous faut donc optimiser tout cela ! Mark Adler, l’auteur de gzip, a écrit pigz (qui se prononce pig-zee, à l’américaine) pour compresser fichiers et répertoires en utilisant tous les coeurs du processeur simultanément.

Pigz représente donc un gain de temps mais allège également la charge du processeur, sollicité moins longtemps.

Installation de pigz

Pigz est disponible sur la plupart des distributions linux, on peut donc l’installer avec un simple :

apt install pigz

L’autre avantage, c’est que si on lit le manuel, on se rend compte que les options et paramètres sont les mêmes que ceux de gzip, ce qui en fait un drop-in replacement de choix.

Remplacer gzip par pigz sur le serveur

L’occasion d’optimiser la compression des sauvegardes est trop belle : et si nous remplacions tout simplement gzip par pigz, sur l’intégralité du serveur et sans toucher à aucun de nos scripts ?

Allez, c’est parti ! On édite donc le fichier .bashrc :

nano .bashrc

et on y ajoute les deux fonctions suivantes :

###
# Matt Biscay
# https://www.skyminds.net/?p=29838
# Use pigz instead of gzip
###
function gzip(){
 pigz $@
}
export -f gzip

function gunzip(){
 unpigz $@
}
export -f gunzip

Cela nous permet de remplacer les fonctions gzip et gunzip par pigz et unpigz, respectivement.

Sauvegardez le fichier et rechargez-le pour activer les changements :

source .bashrc

Et voilà : pigz remplace désormais gzip pour toutes les opérations de compression du serveur. A nous la compression multi-core :)

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

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

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; done

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.

CSS : supprimer subtilement le placeholder d'un champ input ou textarea photo

CSS : supprimer subtilement le placeholder d’un champ input ou textarea

Je viens de finir un projet sur Codeable qui utilisait WordPress et Gravity Forms et lors de la réalisation d’un formulaire de réservation complexe, je me suis heurté à Chrome qui ne supprime pas toujours (suivant les versions utilisées) le texte du placeholder d’un champ de type input ou textarea lorsque le curseur est placé à l’intérieur (action focus).

Normalement, la valeur du placeholder disparaît et permet à l’utilisateur de compléter sa saisie mais sous certaines versions de Chrome, cela ne passe pas bien.

J’ai considéré l’utilisation de JavaScript, évidemment, avant de me rendre compte que l’on pouvait résoudre le problème avec quelques règles CSS natives. Toutes les déclarations sont à ajouter – ne cherchez pas à les compiler, cela ne fonctionnera pas !

On joue donc avec l’opacité et un léger effet de transition pour le côté subtil et smooth :

/* Placeholders */
::-webkit-input-placeholder { opacity: 1; transition: opacity .5s; }  /* Chrome 56, Safari 9 */
:-moz-placeholder { opacity: 1; transition: opacity .5s; } /* FF 4-18 */
::-moz-placeholder { opacity: 1; transition: opacity .5s; } /* FF 19-51 */
:-ms-input-placeholder { opacity: 1; -ms-transition: opacity .5s; transition: opacity .5s; } /* IE 10+ */
::placeholder { opacity: 1; transition: opacity .5s; } /* Modern Browsers */

/* Focus */
*:focus::-webkit-input-placeholder { opacity: 0; } /* Chrome 56, Safari 9 */
*:focus:-moz-placeholder { opacity: 0; } /* FF 4-18 */
*:focus::-moz-placeholder { opacity: 0; } /* FF 19-50 */
*:focus:-ms-input-placeholder { opacity: 0; } /* IE 10+ */
*:focus::placeholder { opacity: 0; } /* Modern Browsers */

Ps : Chrome souffre également d’un bug qui concerne la fonction autofill qui aide les utilisateurs à pré-remplir les formulaires.

Pensez donc à supprimer les valeurs enregistrées pendant vos tests (Chrome > Paramètres > Paramètres avancés > Confidentialité et sécurité > Effacer les données de navigation > Paramètres avancés > cocher Données de saisie automatique).

Enjoy !

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

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;
}

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.

Subliminal : résoudre l'erreur

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'

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@SYNOLOGY

2. On passe root:

sudo -i

3. On recherche le fichier subtitle.py :

find / -type f -name "subtitle.py"

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

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