Ce moment étrange où tu réalises qu’il est possible de recréer le rythme de batterie de We Will Rock You sur une guitare acoustique, avec un bic.
Alexandr Misko, guitariste russe, l’a fait et appelle ça “penguitar”:
Génial.
Ce moment étrange où tu réalises qu’il est possible de recréer le rythme de batterie de We Will Rock You sur une guitare acoustique, avec un bic.
Alexandr Misko, guitariste russe, l’a fait et appelle ça “penguitar”:
Génial.
Si vous utilisez les fonctions de réplication de MySQL ou MariaDB, il peut arriver que votre slave bloque sur une instruction qui devrait avoir un identifiant unique mais que le serveur tente d’insérer deux fois.
Et quand c’est le cas, la réplication des données prend fin donc c’est un problème à corriger rapidement si vous voulez que votre système haute disponibilité perdure et soit vraiment efficace en cas de coup dur.
Je me suis rendu compte du problème lorsque j’ai ajouté de nouvelles bases à répliquer : j’ai relancé la procédure d’installation, relancé les serveurs, ajouté les nouvelles positions, démarré les slaves.
On regarde le status du slave :
MariaDB [(none)]> SHOW SLAVE STATUS\G
Code language: CSS (css)
Résultat :
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 10.134.23.164
Master_User: replicator
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mariadb-bin.000210
Read_Master_Log_Pos: 2753885
Relay_Log_File: mysqld-relay-bin.000002
Relay_Log_Pos: 103794
Relay_Master_Log_File: mariadb-bin.000210
Slave_IO_Running: Yes
Slave_SQL_Running: No
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 1062
Last_Error: Error 'Duplicate entry '56-724' for key 'PRIMARY'' on query. Default database: 'frenchy'. Query: 'INSERT INTO `wp_term_relationships` (`object_id`, `term_taxonomy_id`) VALUES (56, 724)'
Skip_Counter: 0
Exec_Master_Log_Pos: 1563407
Relay_Log_Space: 1296874
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 1062
Last_SQL_Error: Error 'Duplicate entry '56-724' for key 'PRIMARY'' on query. Default database: 'frenchy'. Query: 'INSERT INTO `wp_term_relationships` (`object_id`, `term_taxonomy_id`) VALUES (56, 724)'
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
Master_SSL_Crl:
Master_SSL_Crlpath:
Using_Gtid: No
Gtid_IO_Pos:
Replicate_Do_Domain_Ids:
Replicate_Ignore_Domain_Ids:
Parallel_Mode: conservative
1 row in set (0.00 sec)
Code language: JavaScript (javascript)
Comme on peut le constater, plusieurs choses ne tournent pas rond et empêchent la synchronisation des données entre nos deux serveurs :
Slave_SQL_Running: No
Last_SQL_Errno: 1062
Last_SQL_Error: Error 'Duplicate entry '56-724' for key 'PRIMARY'' on query. Default database: 'frenchy'. Query: 'INSERT INTO `wp_term_relationships` (`object_id`, `term_taxonomy_id`) VALUES (56, 724)'
Code language: JavaScript (javascript)
En me documentant sur le problème, j’ai lu pas mal de choses sur le net. Certains préfèrent cacher l’erreur, au risque de perdre des données. D’autres préfèrent tout effacer pour recommencer la réplication.
Aucune de ces “solutions” ne me conviennent donc nous allons procéder autrement. Comme l’erreur n’apparaît que sur le serveur BACKUP
et non sur le serveur principal, c’est sur lui que nous travaillerons.
Sur le serveur BACKUP
, dans MariaDB, on arrête notre slave :
MariaDB [(none)]> STOP SLAVE;
Query OK, 0 rows affected (0.01 sec)
Code language: CSS (css)
On flush les privilèges et donc les utilisateurs connectés :
MariaDB [(none)]> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)
Code language: CSS (css)
On efface les fichiers logs de notre slave. C’est comme effacer une ardoise pour repartir sur des bases saines. Cela ne supprime aucune donnée – cf le manuel sur RESET :
MariaDB [(none)]> RESET SLAVE;
Query OK, 0 rows affected (0.00 sec)
Code language: CSS (css)
Et on redémarre notre slave :
MariaDB [(none)]> START SLAVE;
Query OK, 0 rows affected (0.00 sec)
Code language: CSS (css)
On vérifie de nouveau le status de notre slave :
MariaDB [(none)]> SHOW SLAVE STATUS\G
Code language: CSS (css)
Résultat :
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 10.134.23.164
Master_User: replicator
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mariadb-bin.000196
Read_Master_Log_Pos: 77900062
Relay_Log_File: mysqld-relay-bin.000002
Relay_Log_Pos: 6318821
Relay_Master_Log_File: mariadb-bin.000192
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 6318531
Relay_Log_Space: 344030331
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 833890
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
Master_SSL_Crl:
Master_SSL_Crlpath:
Using_Gtid: No
Gtid_IO_Pos:
Replicate_Do_Domain_Ids:
Replicate_Ignore_Domain_Ids:
Parallel_Mode: conservative
1 row in set (0.00 sec)
Code language: CSS (css)
Nous avons bien :
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Code language: HTTP (http)
Et voilà, plus d’erreur et une réplication active dans les deux sens.
La saison 3 de Fear the Walking Dead a commencé sur AMC.
Travis, Madison et Alicia sont capturés par un groupe armé et emmenés dans un complexe militaire. Travis est séparé, enfermé dans un sous-sol, tandis que Madison et Alicia sont retenues captives dans un bureau.
Au sous-sol, Travis retrouve Nick et Luciana qui est blessée, avec d’autres prisonniers. Ils s’enfuient mais Travis est recapturé. Nick et Luciana passent par les égouts.
Pendant ce temps, Madison et Alicia attaquent leur geôlier, Troy, et Madison empale son oeil avec une petite cuiller.
Lorsque les walkers arrivent dans le complexe, Travis, Luciana et Alicia prennent l’hélicoptère tandis que Madison et Nick sont obligés de partir en Jeep avec Troy.
Curieusement, j’ai accroché à cette saison, ce qui n’a jamais été le cas auparavant. C’est à croire que les scénaristes ont fait un travail d’écriture ce coup-ci: c’est un peu plus proche de la série mère, The Walking Dead, et un peu plus violent et rythmé – ce qui, il faut bien l’avouer, n’a pas été le cas lors des deux premières saisons fleuves.
J’attends de voir si la suite est du même acabit. Seize épisodes ont été prévus pour cette saison.
Cette semaine, le système d’exploitation du serveur principal passe de Debian 8 Jessie à Debian 9 Stretch.
La mise à jour s’est faite plutôt simplement pour la majeure partie des paquets :
apt update && apt upgrade
mais il a fallu s’y reprendre à plusieurs fois pour les paquets restants :
apt install
Quelques changements notables sont à noter.
On vérifie que tous nos dépôts pointent bien vers la version Stretch:
nano /etc/apt/sources.list
Code language: PHP (php)
On sauvegarde et on lance les mises à jour:
apt update && apt upgrade
La configuration SSH a été modifiée et certaines directives ne sont plus valables. Avant de redémarrer le serveur SSH ou de rebooter et de perdre tout accès au serveur SSH, assurez-vous que la configuration est correcte :
sshd -t
Résultats :
/etc/ssh/sshd_config line 25: Deprecated option KeyRegenerationInterval
/etc/ssh/sshd_config line 26: Deprecated option ServerKeyBits
/etc/ssh/sshd_config line 44: Deprecated option RhostsRSAAuthentication
Il ne vous reste plus qu’à éditer le fichier de configuration SSH:
nano /etc/ssh/sshd_config
J’ai désactivé les lignes qui posaient problème et ai rajouté de nouveaux protocoles de clé :
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
Sauvegardez le fichier puis lancez cette commande pour créer les couples de clés privées/publiques dans /etc/ssl
:
ssh-keygen -A
Résultat:
ssh-keygen: generating new host keys: ECDSA ED25519
Code language: JavaScript (javascript)
Vérifiez une dernière fois qu’il n’y a aucun problème avec le fichier de configuration SSH:
sshd -t
et redémarrez le service SSH:
service ssh restart
C’est le bon moment de revoir la configuration IMAP et POP de Courier.
On commence par renouveler notre fichier Diffie-Hellman en 4096 bits:
cd /etc/courier
openssl dhparam -out dhparams4096.pem 4096
et on revoit la configuration de /etc/courier/imap-ssl
:
SSLPORT=993
SSLADDRESS=0
SSLPIDFILE=/run/courier/imapd-ssl.pid
SSLLOGGEROPTS="-name=imapd-ssl"
IMAPDSSLSTART=YES
IMAPDSTARTTLS=YES
IMAP_TLS_REQUIRED=1
COURIERTLS=/usr/bin/couriertls
TLS_PROTOCOL=TLS1_2:TLS1_1:TLS1
TLS_STARTTLS_PROTOCOL=TLS1_2:TLS1_1:TLS1
TLS_CIPHER_LIST="ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS"
TLS_KX_LIST=ALL
TLS_COMPRESSION=ALL
TLS_CERTS=X509
TLS_DHCERTFILE=/etc/courier/dhparams4096.pem
TLS_CERTFILE=/etc/courier/skyminds-cert.pem
TLS_TRUSTCERTS=/etc/ssl/certs
TLS_VERIFYPEER=NONE
TLS_CACHEFILE=/var/lib/courier/couriersslcache
TLS_CACHESIZE=524288
MAILDIRPATH=Maildir
Code language: JavaScript (javascript)
Le chemin de SSLPIDFILE a changé donc pensez à le vérifier.
Depuis que j’utilise les certificats TLS de Let’s Encrypt, il y a une petite modification a exécuter pour que le certificat s’applique aussi à notre serveur de mail : créer automatiquement un certificat pour Courier dès que notre certificat principal est généré.
On crée un script bash pour compiler notre clé privée et notre certificat Let’s Encrypt :
nano /home/scripts/letsencrypt-skyminds-mailserver.sh
avec :
#!/bin/bash
cat /etc/letsencrypt/live/skyminds.net/privkey.pem /etc/letsencrypt/live/skyminds.net/fullchain.pem > /etc/courier/skyminds-cert.pem
Code language: JavaScript (javascript)
et on édite notre fichier Let’s Encrypt pour le renouvellement :
nano /etc/letsencrypt/renewal/skyminds.net.conf
et on ajoute la directive renew_hook
avec notre nouveau script:
[renewalparams]
account = ...
renew_hook = /home/scripts/letsencrypt-skyminds-mailserver.sh
Code language: JavaScript (javascript)
Il ne reste plus qu’à éditer la configuration IMAP:
nano /etc/courier/imapd-ssl
et y mettre :
TLS_CERTFILE=/etc/courier/skyminds-cert.pem
Code language: JavaScript (javascript)
puis redémarrez le service:
service courier-imap-ssl restart
Voilà, ce sont les principales modifications a effectuer lors de la mise à jour vers Debian 9.
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.
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").
Code language: PHP (php)
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
Code language: JavaScript (javascript)
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”.
Editez votre fichier /etc/default/locale
:
nano /etc/default/locale
Code language: JavaScript (javascript)
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.
On commence par générer la locale de notre choix :
locale-gen "en_US.UTF-8"
Code language: JavaScript (javascript)
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
Code language: JavaScript (javascript)
Et voilà, plus de messages d’avertissement ou d’erreur concernant les locales de votre système. Problème réglé.
Amazon Elastic Compute Cloud ou EC2 est un service proposé par Amazon Web Services (AWS) permettant à des tiers de louer des serveurs sur lesquels exécuter leurs propres applications web.
Si vous avez déjà travaillé sur une instance Amazon EC2 sous linux, vous avez très certainement essayé d’utiliser sudo
pour lancer des commandes qui nécessitent une élévation des privilèges de votre utilisateur.
Or, la configuration Amazon ne le permet pas par défaut mais utilise une implémentation du fichier sudoers
qui n’est pas standard pour une installation linux.
Normalement, lorsque l’on lance visudo
, on obtient une version éditable du fichier /etc/sudoers
qui nous permet de modifier les comptes utilisateurs pour leur donner la permission d’exécuter la commande sudo
et donc contrôler quelles commandes ces utilisateurs peuvent lancer.
Voici un exemple de fichier sudoers
classique :
# User privilege specification
root ALL=(ALL:ALL) ALL# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL# Allow members of group sudo to execute any command
%sudo ALL=(ALL:ALL) ALL# See sudoers(5) for more information on “#include” directives:#includedir /etc/sudoers.d
Code language: PHP (php)
Les membres des groupes admin
et sudo
bénéficient des privilèges sudo, tout comme le compte root
. Toutefois, aucune de ces lignes ne s’appliquent à un compte EC2 qu’un utilisateur AWS peut utiliser.
C’est la dernière ligne, avec la directive #includedir
, qui permet de charger le bon fichier avec les privilèges utilisateur. Il est vital de noter que le signe #
dans #includedir
n’est pas un commentaire mais indique qu’il faut charger les fichiers contenus dans le répertoire /etc/sudoers.d
– cela peut prêter à confusion mais c’est comme cela que le fichier sudoers
fonctionne.
Sur une instance EC2, il suffit de lister le contenu du répertoire /etc/sudoers.d
pour trouver le bon fichier:
ls /etc/sudoers.d
Dans la plupart des cas et des distributions, le nom du fichier débute par un nombre élevé tel que 90. Ces fichiers sont chargés par ordre décroissant, à la manière du lancement d’une fusée, donc un fichier qui commence par 90 sera exécuté avant un fichier qui commence par 10.
Inner Circle est un groupe Jamaicain de reggae formé en 1968 par les frères Ian et Roger Lewis, qui s’appelait à l’origine The Inner Circle Band et qui est connu pour mélanger pop, rock et reggae.
En 1987, ils sortent l’une de leurs chansons phares “Bad Boys”, qui fut utilisée comme générique pour la série télévisée COPS, diffusée sur Fox.
Pour le site du Kriya Yoga France, on me transmet régulièrement des fichiers PDF que je dois transformer en articles. Je fais donc la plupart du temps un copié-collé et ensuite je m’attèle à la mise en page dans l’éditeur WordPress.
Le hic, c’est que depuis l’année dernière, je travaille sous MacOS pour tout ce qui est développement web.
J’ouvre donc chaque PDF avec Preview – la visionneuse PDF installée par défaut – mais lorsque l’on colle le contenu du PDF dans un autre document, tous les caractères accentués sont suivis d’une espace (oui, on dit bien une espace en typographie) et des sauts de ligne apparaissent de nulle part. Clairement improductif.
Le problème réside entre un conflit lors de l’encodage Unicode entre caractères précomposés et caractères décomposés.
Un caractère précomposé ou caractère composite ou caractère décomposable est une entité Unicode qui peut aussi être définie comme une combinaison de plus de deux caractères.
Un caractère précomposé peut typiquement représenter une lettre surplombée d’un accent, comme é (lettre e avec accent aigu).
Techniquement, é (U+00E9) est un caractère qui peut être décomposé en son équivalent unicode à base de la lettre e (U+0065) et du caractère combinant accent aigu (U+0301).
Heureusement, il existe un petit utilitaire, UnicodeChecker, qui permet de régler le problème très simplement. Voici la marche à suivre.
1. Lancez UnicodeChecker > File > New Utilities Window.
2. Copiez le texte de votre fichier PDF en mémoire (sélectionnez le texte puis Cmd+C ou Ctrl+C au clavier).
3. Dans UnicodeChecker, choississez l’option Normalize (6ème icône) et collez votre texte dans le champ Input puis appuyez sur Entrée. Cela donne :
Quatre champs sont proposés avec le résultat de la normalisation. Les deux champs qui nous importent sont NFC et NFKC, qui utilisent tout deux de l’Unicode précomposé, dans lequel l’accent fait partie intégrante du caractère accentué et non une entité à part.
4. Sélectionnez et copiez le texte contenu dans le champ NFC:
5. Collez maintenant le texte précédemment copié dans votre document ou l’éditeur de texte de votre CMS. A l’œil nu, rien ne change mais dans le rendu, votre texte est désormais correctement accentué, sans espaces inopportunes.
De temps en temps, on me demande de configurer des serveurs dédiés ou des VPS. Dernièrement, j’ai travaillé sur un VPS qui n’avait pas de fichier swap et qui finissait par consommer toute la RAM disponible.
Ce tutoriel vous permet de mettre en place un fichier swap sous Ubuntu 16.04 Server.
Le moyen le plus simple d’avoir un serveur réactif et de le prémunir contre les erreurs out-of-memory des services est d’allouer un fichier swap.
Le swap est une zone du disque dur spécialement créée pour que le système d’exploitation y garde des données temporaires qu’il ne peut plus stocker dans la RAM.
Cet espace permet donc aux services du serveur de continuer de tourner même lorsque la RAM est épuisée et ne sera utilisé que dans ce cas de figure.
Les informations seront cependant écrites sur le disque beaucoup moins rapidement que via la RAM.
Commençons par vérifier si un fichier de swap est déjà en place :
swapon --show
Aucun résultat : le système n’a pas d’espace réservé pour le fichier d’échange.
On vérifie une nouvelle fois s’il existe un fichier de swap actif:
free -h
Résultat:
total used free shared buff/cache available
Mem: 3.9G 517M 2.5G 76M 895M 3.0G
Swap: 0B 0B 0B
Pas de swap actif sur notre système, nous allons donc pouvoir en ajouter une.
Il est très commun de créer une nouvelle partition qui contient le fichier d’échange mais comme il n’est pas toujours possible de changer le schéma de partition, nous allons créer un fichier d’échange qui résidera sur notre partition existante.
Vérifions l’espace disponible :
df -h
Résultat:
Filesystem Size Used Avail Use% Mounted on
udev 2.0G 0 2.0G 0% /dev
tmpfs 396M 3.2M 393M 1% /run
/dev/vda1 59G 13G 45G 22% /
tmpfs 2.0G 0 2.0G 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 2.0G 0 2.0G 0% /sys/fs/cgroup
tmpfs 396M 0 396M 0% /run/user/0
Code language: PHP (php)
Le disque dur se trouve sous /dev
dans notre cas.
En ce qui concerne la taille de la partition swap : elle ne doit pas dépasser 4 Go (parce qu’au-delà, c’est inutile) et doit correspondre à peu près à la taille de votre RAM (ou le double de votre RAM suivant votre serveur).
Nous allons donc créer un fichier d’échange nommé swapfile
, d’une taille de 4 Go, à la racine du système (/).
sudo fallocate -l 4G /swapfile
Par souci de sécurité, ce fichier sera uniquement lisible par l’utilisateur root
:
sudo chmod 600 /swapfile
Vérifions les permissions et l’espace réservé :
ls -lh /swapfile
Résultat:
-rw------- 1 root root 4.0G Jan 17 16:31 /swapfile
La Dispute est un groupe de post-hardcore américain, originaire de Grand Rapids, dans le Michigan. Formé en 2004, les membres principaux sont Jordan Dreyer (chant), Brad Vander Lugt (batterie), Chad Morgan-Sterenberg (guitare) et Adam Vass (basse).
Dreyer n’était pas chanteur et n’avait jamais composé de musique lors de la création de La Dispute mais écrivait déjà à l’époque des poésies et de courtes fictions, ce qui se perçoit dans pas mal de morceaux.
L’origine du nom du groupe La Dispute est issue de la pièce éponyme écrite par le dramaturge français Pierre de Marivaux. En effet, le chanteur du groupe, Jordan Dreyer lut la pièce au lycée et fit de nombreux parallèles entre le travail de Marivaux et la musique qu’il composait à l’époque.
En voici un petit exemple avec King Park:
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
.
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.
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
Code language: JavaScript (javascript)
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.
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 : 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
Code language: PHP (php)
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
Code language: CSS (css)
Et voilà, mine de rien, vous venez de vous enlever une future épine du pied.
C’est typiquement le genre de fichiers que l’on ne surveille pas et qui peuvent un jour poser problème, notamment au niveau des inodes.
Aujourd’hui, nous sautons le pas et passons du serveur Apache au serveur NginX (à prononcer “engine X”) pour booster les performances générales du site.
Cela fait quelques serveurs que je monte pour d’autres en utilisant nginx et force est de constater que c’est beaucoup plus réactif qu’Apache et cela prend moins de temps à configurer pour optimiser les réglages.
Je pars du principe que c’est une nouvelle installation mais si vous aviez déjà votre site qui tournait sous Apache, certaines étapes seront juste optionnelles.
Ce tutoriel vise un serveur Debian mais est adaptable sans problème à ses dérivés comme Ubuntu ou Mint.
Nous allons installer la dernière version du serveur nginx, avec le support pour HTTP2, depuis les dépôts Sury :
nano /etc/apt/sources.list
Code language: PHP (php)
et nous ajoutons :
# SURY, post-Dotdeb
deb https://packages.sury.org/php/ stretch main
deb https://packages.sury.org/nginx-mainline/ stretch main
deb https://packages.sury.org/mariadb/ stretch main
Code language: PHP (php)
On rafraîchit les dépôts :
apt update
et on installe nginx et openssl :
apt install nginx openssl libssl1.0.2 libssl1.0.1 libssl-dev
Code language: CSS (css)
Si vous ne l’avez pas déjà – cela remplace MySQL sans que vous n’ayez rien à changer au niveau du code ou de la configuration du serveur :
apt install mariadb-server
Je vous conseille de suivre mon dernier guide pour installer PHP 7.1.
Nous allons d’abord configurer toutes les options qui nous sont primordiales : compression des fichiers statiques, implémentation SSL, types mime… afin de gagner du temps (et éviter les erreurs) dans l’étape suivante.
1. Nous voulons un site rapide donc nous allons compresser tout ce qui peut l’être. On crée un nouveau fichier :
nano /etc/nginx/snippets/gzip-config.conf
et on y met :
# MATT : add more mime-types to compress
types {
application/x-font-ttf ttf;
font/opentype ott;
}
# MATT : gzip all the things!
gzip on;
gzip_disable "msie6";
gzip_vary on;
gzip_proxied any;
gzip_comp_level 6;
gzip_min_length 256;
gzip_buffers 16 8k;
gzip_http_version 1.1;
#gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
# Compress all output labeled with one of the following MIME-types.
gzip_types
application/atom+xml
application/javascript
application/json
application/ld+json
application/manifest+json
application/rss+xml
application/vnd.geo+json
application/vnd.ms-fontobject
application/x-font-ttf
application/x-web-app-manifest+json
application/xhtml+xml
application/xml
font/opentype
image/bmp
image/svg+xml
image/x-icon
text/cache-manifest
text/css
text/plain
text/vcard
text/vnd.rim.location.xloc
text/vtt
text/x-component
text/x-cross-domain-policy;
# text/html is always compressed by gzip module
# don't compress woff/woff2 as they're compressed already
Code language: PHP (php)
J’ai ajouté deux types mime qui ne sont pas dans la configuration de base d’NginX et étendu la liste des types de fichiers à compresser. Certains types le sont déjà donc c’est inutile de gaspiller des ressources en essayant de les compresser.