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 "tar: file changed as we read it" lors de la création de la sauvegarde photo

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

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

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

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

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

Et voici le contenu du fichier log en question :

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

Étapes du débogage

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

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

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

Voici ce qu’il nous indique :

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

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

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

find . ! -perm -o=r

Résultat :

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

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

Suppression des répertoires de cache avant compression des archives

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

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

Sauvegardez le fichier et relancez votre script de backup.

Méthode plus radicale : éditer le script

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

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

Cherchez le chmod 600 :

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

et remplacez-le par un chmod 644:

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

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

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

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

Serveur dédié : résoudre l'erreur "tail: inotify cannot be used, reverting to polling: Too many open files" photo

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 "Cannot set LC_ALL to default locale" photo

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.

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

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

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.

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

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

chmod go-rwx .sshCode language: CSS (css)

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

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

ssh-keygen -b 4096 -t ed25519 -f id_rsa -P ""Code language: JavaScript (javascript)

Nous obtenons deux fichiers :

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

Lire la suite

Installer IPKG sur un NAS Synology photo

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

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.

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

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

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

Pour armv7:

wget -O - http://pkg.entware.net/binaries/armv7/installer/entware_install.sh | /bin/shCode language: JavaScript (javascript)

Pour x86-32:

wget -O - http://pkg.entware.net/binaries/x86-32/installer/entware_install.sh | /bin/shCode language: JavaScript (javascript)

Pour x86-64:

wget -O - http://pkg.entware.net/binaries/x86-64/installer/entware_install.sh | /bin/shCode language: JavaScript (javascript)

Pour MIPS:

wget -O - http://pkg.entware.net/binaries/mipsel/installer/installer.sh | /bin/shCode language: JavaScript (javascript)

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

Lire la suite

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

GRUB : résoudre l’erreur “Grub loading 1.5. Grub loading, please wait… ERROR 15”

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

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 : mettre à jour le noyau linux avec le kernel liquorix photo 1

Linux Mint : mettre à jour le noyau linux avec le kernel Liquorix

Linux Mint Debian Edition

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

Liquorix 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.listCode language: PHP (php)

et on y ajoute :

# liquorix kernel
deb http://liquorix.net/debian sid mainCode language: PHP (php)

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

apt-get update && apt-get install '^liquorix-([^-]+-)?keyring.?'Code language: JavaScript (javascript)

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

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