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

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.

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

Backup Manager : résoudre l'erreur

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.

Serveur dédié : résoudre l'erreur

Serveur dédié : résoudre l’erreur “tail: inotify cannot be used, reverting to polling: Too many open files”

Ce matin, je me suis aperçu que le serveur était un peu moins réactif que d’habitude.

Ni une, ni deux, je lance le terminal et commence par vérifier les fichiers log. Un message attire alors mon attention :

tail: inotify cannot be used, reverting to polling: Too many open files Code language: HTTP (http)

C’est bien étrange puisque très peu de services sont censés lancer des tail. Nous allons donc lancer quelques commandes pour savoir qui est responsable de cet état.

Hotfix : à la recherche des anon_inode:inotify

1. Première méthode pour avoir un aperçu de tout ce qui tourne en ce moment sur le serveur :

ps -ef

La liste est très exhaustive (plusieurs pages chez moi) et ne permet pas vraiment de voir ce qui se passe, étant donné que rien n’est trié.

2. Changeons notre fusil d’épaule et trouvons la liste des processus qui font appel à inotify:

for foo in /proc/*/fd/*; do readlink -f $foo; done | grep inotify | sort | uniq -c | sort -nr

Résultat:

      8 /proc/25634/fd/anon_inode:inotify
      1 /proc/715/fd/anon_inode:inotify
      1 /proc/6146/fd/anon_inode:inotify
      1 /proc/330/fd/anon_inode:inotify
      1 /proc/32148/fd/anon_inode:inotify
      1 /proc/31695/fd/anon_inode:inotify
      1 /proc/31262/fd/anon_inode:inotify
      1 /proc/3067/fd/anon_inode:inotify
      1 /proc/3066/fd/anon_inode:inotify
      1 /proc/3065/fd/anon_inode:inotify
      1 /proc/3064/fd/anon_inode:inotify
      1 /proc/3063/fd/anon_inode:inotify
      1 /proc/3062/fd/anon_inode:inotify
      1 /proc/21853/fd/anon_inode:inotify
      1 /proc/2063/fd/anon_inode:inotify
      1 /proc/1924/fd/anon_inode:inotify
      1 /proc/1563/fd/anon_inode:inotify
      1 /proc/1196/fd/anon_inode:inotify

3. Maintenant, nous allons chercher dans cette liste de processus les commandes qui font appel à anon_inode:inotify :

ps -p $(find /proc/*/fd/* -type l -lname 'anon_inode:inotify' -print 2> /dev/null | sed -e 's/^\/proc\/\([0-9]*\)\/.*/\1/')Code language: JavaScript (javascript)

Résultat:

  PID TTY      STAT   TIME COMMAND
  330 ?        Ss     0:00 /lib/systemd/systemd-udevd --daemon
  715 ?        S      0:00 tail -f /tmp/bm-tarball.log.7lZV2O
 1196 ?        S      0:00 tail -f /tmp/bm-tarball.log.B1I64h
 1563 ?        S      0:00 tail -f /tmp/bm-tarball.log.hhDVas
 1924 ?        S      0:00 tail -f /tmp/bm-tarball.log.Ztuk8T
 2063 ?        Ss     0:06 /usr/bin/dbus-daemon --system
 3062 tty1     Ss+    0:00 /sbin/getty 38400 tty1
 3063 tty2     Ss+    0:00 /sbin/getty 38400 tty2
 3064 tty3     Ss+    0:00 /sbin/getty 38400 tty3
 3065 tty4     Ss+    0:00 /sbin/getty 38400 tty4
 3066 tty5     Ss+    0:00 /sbin/getty 38400 tty5
 3067 tty6     Ss+    0:00 /sbin/getty 38400 tty6
 6146 ?        Ss     0:00 gpg-agent --homedir /root/.gnupg --use-standard-socket --daemon
25634 ?        Sl     0:21 /usr/bin/python3 /usr/bin/fail2ban-server -s /var/run/fail2ban/fail2ban.sock -p /var/run/fail2ban/fail2ban.pid -
31262 ?        S      0:00 tail -f /tmp/bm-tarball.log.82bIqR
31695 ?        S      0:00 tail -f /tmp/bm-tarball.log.6Hqw69
32148 ?        S      0:00 tail -f /tmp/bm-tarball.log.UMpkfiCode language: JavaScript (javascript)

Ah on y arrive, c’est déjà beaucoup plus clair. Le service qui pose problème est donc backup-manager (voir le tutoriel Serveur dédié : sauvegarde automatique des fichiers avec Backup Manager sur le serveur de sauvegarde), qui semble laisser ouvert tous ses fichiers de logs !

Lire la suite

Serveur dédié : mise à jour vers Debian 9 Stretch photo

Serveur dédié : mise à jour vers Debian 9 Stretch

Cette semaine, le système d’exploitation du serveur principal passe de Debian 8 Jessie à Debian 9 Stretch.

Mise à jour des paquets du système

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 

Changements dans la configuration

Quelques changements notables sont à noter.

Configuration apt

On vérifie que tous nos dépôts pointent bien vers la version Stretch:

nano /etc/apt/sources.listCode language: PHP (php)

On sauvegarde et on lance les mises à jour:

apt update && apt upgrade

Configuration SSH

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

Configuration de Courier

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

Le chemin de SSLPIDFILE a changé donc pensez à le vérifier.

Certificat TLS pour Courier

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.pemCode 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.shCode 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.pemCode 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.

Linux : résoudre l'erreur

Linux : résoudre l’erreur “Cannot set LC_ALL to default locale”

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 directoryCode 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”.

Etape 1 : éditez le fichier locale

Editez votre fichier /etc/default/locale :

nano /etc/default/localeCode 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.

Etape 2 : reconfigurer les locales

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

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

Linux : donner les privilèges sudo à un utilisateur sur une instance Amazon Web Service EC2 photo

Linux : donner les privilèges sudo à un utilisateur sur une instance Amazon Web Service EC2

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.

Linux : donner les privilèges sudo à un utilisateur sur une instance Amazon Web Service EC2 photo

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.

Une implémentation du fichier sudoers différente

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.

Anatomie du fichier sudoers

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

EC2 : donner les droits sudo à un utilisateur

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.

Lire la suite

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

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

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

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

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

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

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

Vérification du swap sur le système

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

swapon --show

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

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

free -h

Résultat:

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

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

Vérification de l’espace disponible

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

Vérifions l’espace disponible :

df -h

Résultat:

Filesystem      Size  Used Avail Use% Mounted on
udev            2.0G     0  2.0G   0% /dev
tmpfs           396M  3.2M  393M   1% /run
/dev/vda1        59G   13G   45G  22% /
tmpfs           2.0G     0  2.0G   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           2.0G     0  2.0G   0% /sys/fs/cgroup
tmpfs           396M     0  396M   0% /run/user/0Code 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).

Création du fichier d’échange

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

sudo fallocate -l 4G /swapfile

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

sudo chmod 600 /swapfile

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

ls -lh /swapfile

Résultat:

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

Lire la suite

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

BASH : supprimer les fichiers de session PHP obsolètes

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.

A oneliner to rule ’em all

Voici le nombre d’inodes avant de lancer la commande de nettoyage :

df -i

Résultat:

Filesystem     Inodes IUsed IFree IUse% Mounted on
/dev/root        640K  212K  429K   34% /
devtmpfs         487K  1.5K  486K    1% /dev
tmpfs            487K   864  487K    1% /run
tmpfs            487K     4  487K    1% /run/lock
tmpfs            487K     2  487K    1% /run/shm
/dev/sda2         44M   75K   43M    1% /home

Voici donc comment régler le problème en une seule ligne, dans le terminal. On supprime tous les fichiers de sessions qui existent depuis plus de 24 minutes (TTL par défaut de PHP) :

find /var/lib/php/sessions -type f -cmin +24 -name 'sess_*' | xargs rmCode 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.

Crontab pour supprimer les fichiers de session PHP

Le mieux reste encore de créer une tâche cron qui va vérifier chaque jour que le répertoire de sessions ne se remplit pas inutilement.

Nous allons toutefois faire les choses avec un peu plus de finesse : 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
fiCode 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 dailyCode 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.