Tag

linux

Browsing

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.

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

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.

Et voici le contenu du fichier log en question :

tar: /wp-content/ file changed as we read it

É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*"

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

Cherchez le chmod 600 :

'cache_file_umask' => 0600,

et remplacez-le par un chmod 644:

'cache_file_umask' => 0644,

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 "tail: inotify cannot be used, reverting to polling: Too many open files" photoCe 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 

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

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

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 !

Sommaire de la série Monter un serveur dédié de A à Z

  1. Serveur dédié : installation d’Apache, PHP, MySQL et Webmin
  2. Serveur dédié : créer la base de données MySQL et importer WordPress
  3. Serveur dédié : créer et activer un Virtual Host sous Apache
  4. Serveur dédié : changer les DNS du nom de domaine et le faire pointer vers le serveur
  5. Serveur dédié : sécurisation des services avec iptables et fail2ban
  6. Serveur dédié : sécurisation de la couche TCP/IP
  7. Serveur dédié : création d’un serveur mail Postfix (sécurisé avec Saslauthd et certificat SSL) et Courier (accès POP et IMAP) utilisant une base MySQL d’utilisateurs/domaines virtuels
  8. Serveur dédié : sécuriser Apache 2 avec ModSecurity
  9. Serveur dédié : CHMOD récursif sur des fichiers ou répertoires en ligne de commande
  10. Serveur dédié : installer APC comme système de cache et configurer Varnish comme reverse-proxy pour Apache pour améliorer les performances
  11. Serveur dédié : afficher la véritable IP derrière un reverse-proxy comme Varnish
  12. Serveur dédié : intégrer SSH à WordPress pour mettre à jour le core, les plugins et les thèmes
  13. Serveur dédié : installer la dernière version d’APC par SVN
  14. Serveur dédié : analyse des performances du serveur
  15. Serveur dédié : mettre à jour le noyau Debian de la Kimsufi
  16. Serveur dédié : sauvegarde automatique des fichiers avec Backup Manager sur le serveur de sauvegarde OVH
  17. Serveur dédié : configurer la limite mémoire pour PHP et Suhosin
  18. Bash : supprimer tous les fichiers et sous-répertoires d’un répertoire
  19. Serveur dédié : impossible de se connecter à un port distant
  20. Rsync: rapatrier les fichiers du serveur à la maison
  21. Bash : réparer les tables MySQL en cas de crash
  22. Serveur dédié : création d’une seedbox avec Transmission
  23. Serveur dédié : des paquets LAMP à jour sous Debian
  24. Serveur dédié : mise à jour vers Debian 7 Wheezy
  25. Serveur dédié : activer X11 forwarding pour SSH
  26. Serveur dédié : optimiser toutes les images JPG et PNG avec OptiPNG et JpegOptim
  27. Postfix : résoudre l’erreur « fatal: www-data(33): message file too big »
  28. Serveur dédié : mise en place de l’IPv6
  29. WordPress : accorder les bonnes permissions aux fichiers et dossiers avec chown et chmod
  30. WordPress : héberger les images sur un sous-domaine
  31. Serveur dédié : ajouter l’authentification SPF, Sender-ID et DKIM à Postfix et Bind9 avec opendkim
  32. Apache : lorsque le domaine seul (sans WWW) renvoie une erreur 403
  33. Serveur dédié : sécuriser Apache avec HTTPS (HTTP avec la couche TLS/SSL) en Perfect Forward Secrecy
  34. Serveur dédié : passer WordPress en HTTPS (TLS/SSL)
  35. Serveur dédié : configurer Webmin en TLS avec un certificat SSL
  36. Serveur dédié : configurer Transmission pour accéder au WebUI via TLS-SSL
  37. Serveur dédié : installer et configurer Varnish 4
  38. Serveur dédié : passage au mod FastCGI et PHP-FPM avec Apache MPM Worker
  39. J’ai planté le serveur… ou comment récupérer un serveur Kimsufi après un plantage de kernel avec le mode rescue OVH
  40. Serveur dédié : configurer Postfix et Courier pour utiliser TLS-SSL en Perfect Forward Secrecy
  41. Serveur dédié : retirer Varnish, devenu inutile avec HTTPS
  42. Serveur dédié : ajout de mod_spdy pour accélérer la connexion TLS-SSL sous Apache
  43. Serveur dédié : installer la dernière version d’OpenSSL sous Debian
  44. Serveur dédié : activer l’IP canonique du serveur sous Apache
  45. Serveur dédié : mise à jour vers PHP 5.6
  46. MySQL : convertir les tables MyISAM au format InnoDB
  47. Serveur dédié : optimiser toutes les images GIF avec GIFsicle
  48. Serveur dédié : migration de MySQL vers MariaDB
  49. BASH : lister, bloquer et débloquer des adresses IP avec iptables
  50. Serveur dédié : produire une meilleure réserve d’entropie avec haveged
  51. Serveur dédié : mettre en place DNSSEC pour sécuriser les DNS du domaine
  52. Serveur dédié : mise en place du protocole DANE
  53. 8 règles d’or pour bien déployer DNSSEC et DANE
  54. Serveur dédié : installer PHP7 FPM avec FastCGI sous Debian
  55. Serveur dédié : réduire les connexions TIME_WAIT des sockets et optimiser TCP
  56. Fail2Ban: protéger Postfix contre les attaques DoS de types AUTH, UNKNOWN et EHLO
  57. Serveur dédié : mettre à jour Apache et configurer le mod_http2 pour HTTP/2
  58. Serveur dédié : ajouter le domaine à la liste HSTS preload
  59. Serveur dédié : ajouter l’authentification DMARC à Postfix et BIND
  60. Serveur dédié : à la recherche de l’inode perdue ou comment résoudre le problème « no space left on device »
  61. Serveur dédié : installer NginX avec support HTTP2 et certificat SSL, PHP, MariaDB sous Debian

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

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

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

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 ED25519

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

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

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

Il ne reste plus qu’à éditer la configuration IMAP:

nano /etc/courier/imapd-ssl

et y mettre :

TLS_CERTFILE=/etc/courier/skyminds-cert.pem

puis redémarrez le service:

service courier-imap-ssl restart

Voilà, il me semble que ce sont les principales modifications que j’ai effectué 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.

Linux : résoudre Cannot set LC_ALL to default locale

Les locales sont un ensemble de paramètres qui définissent la langue de l’utilisateur, sa région et les préférences régionales que l’utilisateur souhaire voir dans son interface. Typiquement, une locale est identifiée par un code langue suivi d’un identifiant de région. Nous avons par exemple « en_US.UTF-8 » pour l’anglais américain (en pour l’anglais, US pour les USA) ou « fr_FR.UTF-8 » pour le français de France.

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

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

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

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

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

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

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

Etape 1 : éditez .bashrc

Editez votre fichier .bashrc :

nano .bashrc

et ajoutez cette ligne:

export LC_ALL="en_US.UTF-8"
export LANG="en_US.UTF-8"
export LANGUAGE="en_US.UTF-8"

Enregistrez le fichier et validez vos changements immédiatement avec la commande source :

source .bashrc

Ou, un chouia plus barbare, quittez votre session SSH puis reconnectez-vous.

Etape 2 : reconfigurer les locales

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

locale-gen "en_US.UTF-8"

Et on la reconfigure :

dpkg-reconfigure locales

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

locale

Résultat:

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

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

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

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.

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.

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

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

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

Je vous ai déjà parlé du problème des fichiers de session PHP. Or, je me suis aperçu que le problème n’est toujours pas réglé sous Debian : les fichiers de session de PHP ne sont jamais effacés et cela finit par saturer la partition /root.

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

Sur le serveur, ces fichiers prenaient 590 Mo, ce qui est énorme vu que ces fichiers ont la taille d’un fichier de cookies. Il y en a donc des milliers, dans un seul répertoire, ce qui consomme un maximum d’inodes.

A oneliner to rule ’em all

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

df -i

Résultat:

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

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

find /var/lib/php/sessions -type f -cmin +24 -name 'sess_*' | xargs rm

Notez la rapidité d’exécution de la commande, grâce à xargs.

On relance le calcul d’inodes:

df -i

Résultat:

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

Boom : 20% d’inodes en plus. Pas mal, surtout que ces sessions sont expirées depuis belle lurette et auraient dues être supprimées depuis bien longtemps.

Crontab pour supprimer les fichiers de session PHP

Le mieux reste encore de créer une tâche cron qui va vérifier chaque jour que le répertoire de sessions ne se remplit pas inutilement. Nous allons toutefois faire les choses avec un peu plus de finesse : nous allons chercher le chemin de stockage des sessions ainsi que la durée de vie des sessions et supprimer chaque jour les fichiers expirés.

On crée notre script bash:

nano /etc/scripts/cleanup-php-sessions.sh
#!/bin/bash
# Script Name : cleanup-php-sessions.sh
# Author : Matt Biscay
# Author URL :  https://www.skyminds.net/?p=28992
# Hire me : https://www.skyminds.net/hire-me/

# Export bin paths
export PATH=$PATH:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# Get PHP Session Details
PHPSESSIONPATH=$(php -i 2>/dev/null | grep -w session.save_path | awk '{print $3}' | head -1);
PHPSESSIONLIFETIME=$(php -i 2>/dev/null | grep -w session.gc_maxlifetime | awk '{print $3}' | head -1);
PHPSESSIONLIFETIMEMINUTE=$( expr $PHPSESSIONLIFETIME / 60 );

# If PHPSESSIONPATH exists
if [ -d $PHPSESSIONPATH ];
then
    # Find and delete expired sessions files :

	# Sluggish way
	#find $PHPSESSIONPATH -type f -cmin +$PHPSESSIONLIFETIMEMINUTE -name "sess_*" -exec rm -f {} \;

	# Quick way
	find $PHPSESSIONPATH -type f -cmin +$PHPSESSIONLIFETIMEMINUTE -name 'sess_*' | xargs rm
fi

Il ne reste plus qu’à l’activer:

crontab -e

et on lance le script tous les jours à minuit :

@daily sh /etc/scripts/cleanup-php_sessions.sh #Cleanup PHP sessions daily

Et voilà, mine de rien, vous venez de vous enlever une future épine du pied. C’est typiquement le genre de fichiers que l’on ne surveille pas et qui peuvent un jour poser problème, notamment au niveau des inodes.

Il est idéal de pouvoir s’identifier sur un serveur distant, à l’aide d’une clé SSH, sans avoir à taper son mot de passe à chaque fois. Pas seulement pour un gain de temps mais pour, par exemple, transférer des données ou avoir un cron qui lance une sauvegarde planifiée automatiquement, sans que vous ayez à taper le mot de passe SSH.

Créer une clé SSH pour ouvrir une session distante sans mot de passe photo

Et puis, c’est un degré de sécurité supplémentaire puisque personne ne pourra deviner votre clé RSA, à moins d’avoir eu main mise sur votre machine.

Ce tutoriel est très rapide à mettre en œuvre, quelques minutes à peine suffisent pour créer votre clé et la placer sur le serveur distant.

Voici le principe de fonctionnement en image:

Créer une clé SSH pour ouvrir une session distante sans mot de passe photo 1

Concrètement, au lieu d’utiliser un nom d’utilisateur et un mot de passe en mode interactif (l’invite de commande vous demande d’entrer votre mot de passe), il suffit de donner le nom d’utilisateur et le serveur reconnaît votre machine grâce à votre clé SSH.

Créer un répertoire .ssh pour l’utilisateur

Normalement, votre utilisateur possède déjà un répertoire .ssh mais si ce n’est pas le cas, il faut le créer. Vous pouvez passer à l’étape suivante si vous disposez déjà de ce répertoire.

On se rend dans le répertoire de l’utilisateur:

cd ~/

On crée le répertoire .ssh:

mkdir .ssh

On s’assure que les permissions de fichiers permettent de lire, écrire et exécuter uniquement pour notre utilisateur:

chmod go-rwx .ssh

Créer une clé SSH

Nous allons maintenant créer une clé SSH, ou plutôt 2 clés : une clé privée et une clé publique. Les guillemets à la fin de la commande indiquent que la clé privée n’a pas de mot de passe, ce qui permet de s’identifier sans mot de passe.

On se place dans le répertoire .ssh:

cd .ssh

Nous créons une clé de 4096 bits, sans mot de passe :

ssh-keygen -b 4096 -t ed25519 -f id_rsa -P ""

Nous obtenons deux fichiers :

  • id_rsa : notre clé privée
  • id_rsa.pub : notre clé publique

Vous avez sûrement remarqué qu’IPKG n’est plus maintenu depuis maintenant quelques années (2014) et qu’à chaque mise à jour DSM du NAS Synology, les applications sautent. Il devenait quasiment impossible d’installer IPKG sur les nouveaux NAS… jusqu’à l’arrivée d’Entware.

NAS Synology : installer Entware en remplacement d'IPKG pour des applications à jour

Entware est un petit nouveau qui a mis des années à mûrir mais il est mis à jour en permanence et offre plus de 1800 paquets à votre NAS. Il est aussi compatible avec les routeurs OpenWRT et LEDE.

Voyons donc comment installer cette nouvelle source d’applications.

Entware-ng, le petit nouveau

Entware-ng prend en charge les processeurs ARM et Intel, votre version de DSM doit quant à elle être égale ou supérieure à la version 3.2.

Il faut utiliser :

  • l’installeur armv5 pour les processeurs Marvell Kirkwood mv6282,
  • l’installeur armv7 pour les processeurs ARM plus récents. Le dépôt armv7 a été compilé avec l’optimisation cortex-a9 mais reste totalement compatible avec les NAS basés sur des Marvell Armada XP .

Déterminer le modèle du processeur du NAS

Considérons que SSH est activé dans les options du DSM (Control Panel > Applications > Terminal & SNMP > Terminal > Enable SSH service).

On commence par lancer une connexion SSH vers le NAS avec l’utilisateur admin :

ssh admin@DiskStation

et on passe root:

sudo -i

On peut trouver le modèle du processeur en tapant:

cat /proc/cpuinfo | more

Cela vous permet de savoir si vous êtes en armv5 ou armv7 (plus récent).

Un autre moyen, peut-être même plus simple :

uname -a

Résultat chez moi:

Linux DiskStation 2.6.32.12 #15132 Wed Jun 14 12:24:38 CST 2017 armv5tel GNU/Linux synology_212+

Installer Entware-ng sur notre NAS Synology

Toujours dans votre session SSH, en tant que root, vous allez maintenant installer Entware sur votre Synology.

1. On crée un dossier sur le disque, en dehors du rootfs :

mkdir -p /volume1/@entware-ng/opt

Le dossier /opt doit absolument être vide, c’est-à-dire qu’Optware ne doit pas être installé. Dans le doute, on le vide dans l’étape suivante.

2. On supprime /opt et on crée un lien symbolique:

rm -rf /opt
ln -sf /volume1/@entware-ng/opt /opt

3. On lance le script d’installation:

Pour armv5:

wget -O - http://pkg.entware.net/binaries/armv5/installer/entware_install.sh | /bin/sh

Pour armv7:

wget -O - http://pkg.entware.net/binaries/armv7/installer/entware_install.sh | /bin/sh

Pour x86-32:

wget -O - http://pkg.entware.net/binaries/x86-32/installer/entware_install.sh | /bin/sh

Pour x86-64:

wget -O - http://pkg.entware.net/binaries/x86-64/installer/entware_install.sh | /bin/sh

Pour MIPS:

wget -O - http://pkg.entware.net/binaries/mipsel/installer/installer.sh | /bin/sh

4. On édite le fichier /etc/rc.local et on ajoute à la fin du fichier:

/bin/ln -sf /volume1/@entware-ng/opt /opt
/opt/etc/init.d/rc.unslung start

La dernière ligne permet de lancer les services Entware lors du démarrage du NAS.

Depuis DSM 6.1, /etc/rc.local n’est plus exécuté lors de la séquence de boot. Il faut donc créer une tâche planifiée qui lance ces deux instructions au démarrage du NAS.

Rendez-vous dans Panneau de configuration > Planificateur de tâches > Créer > Tâche déclenchée > Script défini par l’utilisateur. Cette tâche sera lancée au démarrage du NAS:

NAS Synology : installer Entware en remplacement d'IPKG pour des applications à jour photo

avec les instructions suivantes:

/bin/ln -sf /volume1/@entware-ng/opt /opt
/opt/etc/init.d/rc.unslung start

NAS Synology : installer Entware en remplacement d'IPKG pour des applications à jour photo 1

Hier, petite surprise sur ma machine à la maison : au démarrage, Ubuntu se charge puis finit dans les limbes avec un écran noir. Je redémarre la machine et là, patatras, une erreur GRUB laconique :

Grub loading 1.5. 
Grub loading, please wait...

ERROR 15

Un redémarrage plus tard, je m’aperçois que même certains réglages du BIOS sont même revenus aux réglages d’usine… Étrange, c’est la première fois que je vois ça sur ma machine.

GRUB, l’erreur 15

L’erreur 15 de GRUB correspond à un fichier de démarrage non trouvé. Cela signifieque GRUB n’est pas installé sur le disque de démarrage et qu’il ne peut donc lancer le menu de démarrage.

Ma machine comprend quatre disques dur, et mes deux disques durs principaux (Linux et Windows) sont du même type et de la même marque, ce qui n’est pas vraiment idéal pour les identifier puisque dans les réglages du BIOS, la référence est la même. Le BIOS ne m’indique qu’un seul disque dur de démarrage, sans autre indication que le numéro de série.

Vérification des options du BIOS

On commence par vérifier les options du BIOS et la séquence initiale de boot : DVD, disque dur. Cela nous sera utile pour la suite lorsque nous utiliserons le live CD.

Utilisation de Boot-Repair

J’ai commencé par utiliser le live CD d’Ubuntu avant de me rendre rapidement compte des limitations dues au montage des points critiques du système.

Le plus simple est d’utiliser Boot-Repair-Disk, le disque ultime de réparation du démarrage qui vous permettra de redémarrer votre machine comme avant.

GRUB : résoudre l'erreur "Grub loading 1.5. Grub loading, please wait... ERROR 15" photo

Le Réparateur de Démarrage (Boot-Repair en anglais) est un petit outil qui propose :

  • un bouton Réparation recommandée permettant de réparer la plupart des problèmes de démarrage (par exemple lorsque Ubuntu ne démarre plus suite à l’installation de Windows, lorsque le menu GRUB n’apparaît plus1) ou lorsque vous avez une erreur GRUB rescue> ou out-of-disk) ;
  • un deuxième bouton permettant de créer un rapport Boot-Info en un clic (pour obtenir de l’aide via email ou forum) ;
  • les options avancées permettant, entre autres, de :
    • mettre à jour le menu de démarrage GRUB ;
    • reconfigurer GRUB (ajouter des options de kernel, etc.) ;
    • purger et réinstaller GRUB2 ;
    • restaurer un secteur d’amorçage compatible Windows (XP, Vista, Seven) ;
    • restaurer un MBR permettant de démarrer Windows en mode Legacy.

Restauration de GRUB

Voici la marche à suivre :

  1. téléchargez Boot Repair Disk
  2. gravez l’image sur un CD / DVD ou utilisez Rufus ou Unetbootin pour graver l’image sur une clé USB.
  3. Insérer votre CD/DVD/clé USB contenant Boo Repair puis redémarrez la machine.
  4. Choisissez la langue de l’interface et activez la connexion internet (recommandé)
  5. Choissisez « Réparation recommandée » dans la majeure partie des cas courants.
  6. Redémarrez la machine, cela solutionne la majorité des problèmes de boot liés à GRUB.

Curieusement, lorsque Boot Repair s’est lancé, il m’a demandé si mon disque sdb était un disque dur externe alors que c’est mon disque dur de démarrage principal sous Ubuntu. J’ai répondu « non » puis ai choisi le menu Options avancées afin d’installer de purger GRUB et d’installer la dernière version de GRUB sur tous mes disques durs. Ce n’est qu’avec cette option que j’ai vraiment pu retrouver un démarrage normal.

Je vous conseille Boot-Repair pour résoudre les problèmes liés au démarrage de GRUB. Cela m’a bien dépanné – en quelques clics et moins de dix minutes, je retrouvais mon bureau.

A garder dans la boite à outil, c’est extrêmement utile.

Linux Mint Debian EditionLinux Mint Debian Edition (LMDE) est vraiment très stable et fonctionne avec des paquets éprouvés mais pas vraiment à jour. Si vous avez du matériel récent, il est possible qu’il ne soit pas détecté – c’est le cas du pavé tactile de mon ordinateur portable – à cause du noyau linux qui laggue un peu.

A l’heure où j’écris ces lignes, Linux Mint Debian Edition utilise le kernel 3.16 alors que le dernier en date est le 4.6.3… voyons comment on peut le mettre à jour.

Le kernel Liquorix

Linux Mint : mettre à jour le noyau linux avec le kernel liquorix photo 1Liquorix vient remplacer le noyau linux de votre distribution. C’est un noyau à jour, avec des configurations supplémentaires pour les ordinateurs de travail, le multimédia et les jeux vidéos.

Installation de Liquorix

On passe root :

sudo -i

On édite le fichier sources.list d’apt :

nano /etc/apt/sources.list

et on y ajoute :

# liquorix kernel
deb http://liquorix.net/debian sid main

On sauvegarde le fichier, on met à jour les paquets et on installe le keyring de Liquorix :

apt-get update && apt-get install '^liquorix-([^-]+-)?keyring.?'

On peut voir quels sont les derniers noyaux ajoutés sur le dépôt liquorix:

apt search liquorix

Ensuite, il vous suffit d’installer le dernier kernel en date:

apt-get install linux-image-liquorix-amd64 linux-headers-liquorix-amd64

Et on reboote la machine pour activer les changements. Le pavé tactile est miraculeusement actif après installation de ce kernel.

Ce noyau est stable et complémente très bien Linux Mint. Recommandé.

Aujourd’hui, ma machine desktop – The Reaper – vient d’avoir une jolie petite mise à jour et passe d’Ubuntu 14.04 à 16.04, codename Xenial Xerus.

The Reaper : mise à jour vers Ubuntu 16.04 Xenial Xerus photo

Mise à jour d’Ubuntu

La mise à jour se fait assez simplement :

sudo apt update && sudo apt upgrade
sudo apt autoremove
sudo apt dist-upgrade

Comme je n’installe que des versions LTS (Long-Time Support) sur cette machine, il y avait plus de 2.3 Go de paquets à télécharger soit un sacré paquet de mises à jour.

Plusieurs erreurs sont apparues pendant l’installation, qui a laissé à peu près une trentaine de paquets non configurés et non des moindres : GRUB, initramfs-tools etc.

En regardant les messages d’erreurs, j’ai vu que le problème se situait au niveau de DPKG.

Lorsqu’un paquet obsolète bloque DPKG

Si cela vous arrive, pas de panique. Il faut juste régler le problème *avant* de redémarrer la machine.

On commence par relancer la configuration des paquets non configurés:

dpkg --configure -a

En résultat, vous obtenez une (très) longue liste de tous les paquets non configurés avec tous les messages d’erreurs associés. Ce qui importe, ce sont les premières lignes du résultat : le paquet qui bloque est toujours mentionné en premier.

Dans mon cas, il s’agissait d’un paquet obsolète depuis Ubuntu 12.04 (donc depuis 4 ans), virtuoso-nepomuk. Je l’ai donc totalement supprimé :

sudo apt purge virtuoso-nepomuk

On relance ensuite la configuration des paquets :

dpkg --configure -a

Puis une petite vérification des nouveaux paquets au cas où et la suppression des paquets obsolètes :

sudo apt update && sudo apt upgrade && sudo apt autoremove

Un reboot plus tard, Ubuntu 16.04 boote tranquillement. Je conseille de régler le problème des paquets non configurés avant le reboot, c’est bien plus galère autrement.

Réactiver les dépôts désactivés pendant la mise à niveau

Enfin, il reste à réactiver les dépôts APT qui ont été désactivés pendant la mise à niveau.

Rapport de faute d’orthographe

Le texte suivant sera envoyé à nos rédacteurs :