Tag

terminal

Browsing

J’ai récemment monté un nouveau serveur qui utilise MySQL 8 et après quelques jours d’utilisation, je me suis rendu compte que l’espace disque avait considérablement augmenté.

La cause ? Une multitude de fichiers logs binaires dans le répertoire d’exécution de MySQL 8 : il y en avait pour plus de 260 Go !

Les fichiers logs binaires enregistrent toutes les requêtes qui ont été effectuées par le serveur de bases de données. Inutile de dire qu’il est assez improbable que vous cherchiez à savoir quelles requêtes ont été lancées le mois dernier!

Désactivation des logs binaires

Sous MySQL 8, voici comment désactiver les logs binaires : éditez le fichier de configuration de MySQL:

nano /etc/mysql/mysql.conf.d/mysqld.cnf

et ajoutez cette ligne sous [mysqld] :

skip-log-bin

Vous pouvez également vous connecter au serveur MySQL en ligne de commande:

mysql -u root -p

et lancer la commande suivante dans l’invite de commande MySQL:

SET sql_log_bin = 0;
PURGE BINARY LOGS BEFORE '2019-03-31';

Relancez ensuite le serveur MySQL:

service mysql restart

Il ne vous reste plus qu’à vous rendre dans le dossier d’exécution de MySQL – /etc/mysql par défaut, sauf si vous l’avez modifié – et supprimer les fichiers binlog*.

Voici un tutoriel qui vous permet de supprimer les kernels linux installés sur votre serveur/machine qui ne sont pas actuellement utilisés.

Cela est utile pour faire un peu de ménage sur la partition /boot, idéalement avant qu’elle ne soit complètement saturée. Sinon, je vous donne aussi l’astuce pour faire le ménage manuellement et retrouver APT complètement opérationnel.

Ce tutoriel a été testé sous Ubuntu Server 18.04 LTS, il est complètement transférable sous Ubuntu et Debian.

Cas de figure 1: /boot n’est pas plein à 100% et apt est opérationnel

1. On vérifie la version actuelle du kernel

uname -r

Cela nous donne la version du noyau sous laquelle tourne notre machine:

4.15.0-46-generic

2. On supprime les vieux kernels

2.a. On liste les vieux kernels

sudo dpkg --list 'linux-image*'|awk '{ if ($1=="ii") print $2}'|grep -v `uname -r`

You will get the list of images something like below:

linux-image-4.15.0-45-generic

2.b. On supprime les vieux kernels (un par un)

sudo apt purge linux-image-4.15.0-45-generic

Une fois que les vieux kernels sont supprimés, on supprime également les paquets qui seront maintenant obsolètes:

sudo apt autoremove

Et on finit par la mise à jour de la liste des noyaux de GRUB:

sudo update-grub

Voilà, il ne vous reste plus qu’à rebooter votre machine ou votre serveur. Il ne reste que le dernier kernel.

Cas de figure 2 : apt est indisponible car /boot est plein à 100%

NOTE: cette partie du tutoriel n’est valable que si et seulement si vous ne pouvez utiliser APT parce que la partition /boot est pleine à 100%.

1. Listez les images de kernel

Obtenez la liste des images de kernels et faites la liste des kernels que vous pouvez supprimer car ils ne sont plus utilisés. Cette commande vous montre les kernels installés à l’exception de celui qui est en cours d’utilisation:

sudo dpkg --list 'linux-image*'|awk '{ if ($1=="ii") print $2}'|grep -v `uname -r`

Voici le résultat de la commande, la liste des kernels installés mais inutilisés:

linux-image-3.19.0-59-generic
linux-image-3.19.0-61-generic
linux-image-3.19.0-65-generic
linux-image-extra-3.19.0-59-generic
linux-image-extra-3.19.0-61-generic
linux-image-extra-3.19.0-65-generic

2. Préparez la suppression

Vous devez préparer la commande qui va supprimer tous les kernels inutilisés en utilisant la brace expansion pour vous simplifier la vie. Je vous conseille d’écrire la commande dans un éditeur de texte et de bien la vérifier avant de la lancer dans le terminal.

N’oubliez pas d’exclure le kernel actuel ainsi que les deux kernels les plus récents pour pallier tout problème:

sudo rm -rf /boot/*-3.19.0-{59,61,65}-*

3. Nettoyez APT et ses messages d’avertissement à propos d’une installation partielle

sudo apt-get -f install

4. Autoremove

Enfin, on lance la commande autoremove pour supprimer les paquets relatifs aux vieilles images de kernel qui ont été rendues orphelines par le nettoyage manuel de /boot :

sudo apt autoremove

5. Mise à jour de GRUB

sudo update-grub

6. APT est opérationnel

Vous pouvez de nouveau utiliser APT et mettre à jour, installer et supprimer les paquets de votre distribution:

sudo apt update

J’ai récemment écrit un petit script bash qui me permet de sauvegarder rapidement toutes les bases de données d’un serveur. Le script est lancé par une tâche cron automatiquement, tous les jours.

Si l’on passe l’utilisateur et le mot de passe SQL dans la requête, avec mysql ou mysqldump, vous obtiendrez très certainement le message d’avertissement suivant:

Warning: Using a password on the command line interface can be insecure.

Et pour cause : cela veut dire que n’importe qui ayant accès au serveur pourra voir, dans les logs ou avec un simple ps, vos informations de connexion à vos bases de données. Ce n’est pas ce qui se fait de mieux en matière de sécurité !

Une solution est de passer en argument un fichier qui contiendra vos données de connexion à la base de données.

Donc, au lieu d’écrire :

mysqldump -u $USER -p$PASSWORD --databases $db > $BACKUP_PATH/$date-$db.sql

Il vaut mieux écrire:

mysqldump --defaults-extra-file=/etc/mysql/mysql-backup-script.cnf --databases $db > $BACKUP_PATH/$date-$db.sql

Note: L’argument --defaults-extra-file doit venir en premier, sinon il ne sera pas interprété.

Le fichier /etc/mysql/mysql-backup-script.cnf contient les identifiants de votre utilisateur SQL qui aura les droits sur chacune des bases de données à sauvegarder. Voici à quoi il ressemble:

[client]
user = 'backup'
password = 'GIGANTIC_SECURE_PASSWORD'

Par sécurité, on restreint les droits d’accès au fichier pour qu’il ne soit pas lisible par tout le monde:

chmod 400 /etc/mysql/mysql-backup-script.cnf

Il ne vous reste qu’à créer votre cron avec votre nouvelle commande, sans montrer les identifiants SQL en clair.

Résoudre l'erreur "/var/cache/debconf/config.dat is locked by another process: Resource temporarily unavailable" photo

Lors d’une mise à jour APT, il arrive qu’un installeur vous demande s’il faut écraser ou non un des fichiers de configuration existant. C’est le cas notamment de certaines versions de PHP qui requièrent une mise à jour du fichier php.ini

Si vous êtes derrière votre terminal, pas de problème. Si par contre, vous ne prêtez pas attention à votre terminal, pensant que tout s’est mis à jour, ou si votre connexion SSH est rompue lors de l’installation, vous risquez d’avoir dpkg en vrac, avec une installation de paquet qui restera ‘en cours”.

Concrètement, vous obtiendrez un de ces messages:

debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by another process: Resource temporarily unavailable
dpkg: error processing package XXXXX:amd64 (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 XXXXX:amd64
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)

Mais pas de panique, il est très simple de résoudre le problème en quelques commandes.

Commencez par vérifiez quel est le processus responsable du fichier en question:

fuser -v /var/cache/debconf/config.dat

Résultat :

USER        PID ACCESS COMMAND
/var/cache/debconf/config.dat:
root       8756 F.... frontend

Il ne nous reste plus qu’à tuer proprement le processus:

kill 8756

Il ne vous reste plus qu’à relancer vos commandes apt habituelles, tout est redevenu opérationnel.


Après mise à jour du serveur SQL, il est possible d’obtenir cette erreur au redémarrage physique (boot) du serveur :

error: 'Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)' — Missing /var/run/mysqld/mysqld.sock

Il se trouve que systemd lance bien le service mysql qui est donc démarré mais ne semble pas pouvoir être en mesure de créer son fichier sock. Il va donc falloir l’aider:

On crée un nouveau fichier pour systemd:

nano /etc/tmpfiles.d/mysql.conf

et on y ajoute ce code qui va permettre de chmoder et chowner le répertoire /var/run/mysqld pour l’utilisateur mysql:

# systemd tmpfile settings for mysql
# See tmpfiles.d(5) for details

d /var/run/mysqld 0755 mysql mysql -

Cela règle le problème définivement.

Depuis que j’ai déplacé les bases de données SQL sur une autre partition, logrotate semble avoir quelques soucis avec l’archivage des logs de MariaDB. Voici le message d’erreur complet :

/etc/cron.daily/logrotate: logrotate_script: 3: [: /var/run/mysqld/mysqld.pid: unexpected operator

C’est en fait un problème de regex connu et la solution est très simple.

1. On édite le fichier /etc/logrotate.d/mysql-server:

nano /etc/logrotate.d/mysql-server

2. on recherche la ligne avec la regex de grep:

if [ -f `my_print_defaults --mysqld | grep -oP "pid-file=\K[^$]+"` ]; then

3. on ajoute m1 aux arguments de grep, ce qui nous donne:

if [ -f `my_print_defaults --mysqld | grep -oPm1 "pid-file=\K[^$]+"` ]; then

Sauvegardez le fichier. Vous ne recevrez plus de message d’erreur lors du lancement de la tâche cron et les fichiers logs de MySQL/MariaDB seront bien archivés.

Debian Stretch possède MariaDB 10.1 mais au vu des améliorations récentes de MariaDB, il est intéressant de passer à la version 10.3 pour des raisons de performance.

Ajout du nouveau dépôt

On installe les dépendances et on ajoute le dépôt de MariaDB 10.3 à notre fichier de configuration apt, ainsi que la clé du dépôt:

apt install software-properties-common dirmngr
apt-key adv --recv-keys --keyserver keyserver.ubuntu.com 0xF1656F24C74CD1D8
add-apt-repository 'deb [arch=amd64,i386,ppc64el] http://mariadb.mirrors.ovh.net/MariaDB/repo/10.3/debian stretch main'

Mise à jour de MariaDB

Une fois que la clé du dépôt est ajoutée au trousseau, on installe la nouvelle mouture de MariaDB:

apt update
apt install mariadb-server

Notez que vous pouvez choisir la version de MariaDB à installer très facilement depuis le site officiel.

Et voilà, serveur de base de données mis à jour.

J’ai récemment installé un plugin qui met en cache les requêtes API Amazon mais dont la table SQL gonfle énormément – plus de 5 Go à l’heure où j’écris ces lignes. Le problème, c’est que cela remplit la partition racine du serveur, qui est utilisée par défaut par MariaDB pour stocker les fichiers des bases de données.

MariaDB : changer le répertoire des bases de données sous Debian photo

Lorsque j’ai créé ce serveur, j’ai utilisé la configuration par défault d’OVH, ce qui est une erreur grossière : la partition racine (/) fait 10 Go alors que la partition /home fait 740 Go… même pour un desktop, on ne fait plus cela parce que cela laisse trop peu pour le système alors imaginez un peu pour un serveur !

Nous avons donc le choix entre re-partitionner le disque (autant vous dire que cela ne me tente que très moyennement) ou alors changer le dossier des bases SQL pour les mettre sous /home.

Ce tutoriel vous permet donc de délocaliser les bases de données MySQL/MariaDB sur une autre partition. Le serveur tourne sur la dernière version de Debian.

Vérification du chemin des bases MariaDB

Tout se passe via le terminal. Je vous conseille de faire une sauvegarde de vos bases avant de commencer.

Commençons par vérifier le dossier dans lequel se trouve nos bases de données:

mysql -u root -p

Entrez votre mot de passe root puis entrez la commande suivante:

select @@datadir;

Résultat:

+-----------------+
| @@datadir       |
+-----------------+
| /var/lib/mysql/ |
+-----------------+
1 row in set (0.00 sec)

Ajustement de systemd pour MariaDB

Ceci est une étape fondamentale du tutoriel. Si vous ne faites pas cela, MariaDB ne démarrera pas avec votre nouveau dossier car, par défaut, il n’a pas accès à /home. Il faut donc que nous lui donnions explicitement l’accès :

systemctl edit mariadb

Dans le fichier qui s’ouvre, entrez le code suivant:

[Service]
ProtectHome = false

Enregistrez le fichier tel quel, sans changer le nom. Le fichier que vous venez de créer est /etc/systemd/system/mariadb.service.d/override.conf

Appliquez maintenant les changements :

systemctl daemon-reload

Un nouveau répertoire pour nos bases de données

Nous pouvons maintenant créer le nouveau répertoire qui accueillera les fichiers de nos bases de données. Par simplicité, je choisis de tout mettre sous /home/mysql :

Depuis la mise à jour de MacOSX Mojave, il est devenu impossible de lancer Meld, l’application multi-plateforme dont je me sers pour comparer plusieurs versions de fichiers afin de visualiser les différences dans du texte ou code.

Débloquer le démarrage de Meld sous MacOSX Mojave photo

L’application se lance mais ne présente pas la fenêtre habituelle qui permet de sélectionner les options de comparaison. Le menu apparait bien en haut de l’écran mais reste inutilisable.

On peut débloquer la situation très facilement – ouvrez une fenêtre de terminal et lancez les commandes suivantes:

cd ${HOME}
rm ./.local/share/meld -rf 
rm ./Library/Preferences/org.gnome.meld.plist -f
rm "./Library/Saved Application State/org.gnome.meld.savedState/" -rf 

Ces commandes permettent de supprimer le fichier de préférence GNOME de l’application et de réinitialiser l’état de l’application.

Une fois que vous avez exécuté ces commandes, relancez Meld – il me semble plus lent qu’avant à démarrer mais il est tout à fait fonctionnel ensuite, ce qui est l’essentiel.

Linux : désactiver les emails de notification d'une tâche cron photo

La plupart des tâches cron sont exécutées à un moment où elles n’empiètent pas sur les ressources du serveur (i.e. la nuit). Or crontab envoie un email récapitulatif à chaque fois qu’une tâche est complétée, ce qui peut vite devenir pénible à gérer.

Heureusement, il existe plusieurs manières d’empêcher de recevoir ces emails de notification de tâches cron.

1. Méthode nucléaire : rendre la variable MAILTO nulle

Vous pouvez éditer le fichier /etc/crontab et rendre la variable MAILTO nulle, comme ceci:

MAILTO=""

Cela désactive effectivement tous les emails envoyés depuis crond. C’est par contre une méthode nucléaire : si vous voulez une notification, il faudra l’envoyer depuis le script et non cron. Cela empêche également de recevoir toute notification en cas d’erreur de la tâche cron, ce qui est très gênant – ce n’est pas vraiment la méthode que je conseille.

2. Rediriger STDOUT et STDERR vers null pour supprimer toute sortie

Si vous supprimez la sortie du script, crond n’aura rien à envoyer.

Ajoutez ceci à l’entrée de votre crontab pour envoyer toute sortie (STDERR et STDOUT) vers /dev/null:

>/dev/null 2>&1

Voici un exemple qui lance un script toutes les 5 minutes, sans sortie:

*/5 * * * * /example/script >/dev/null 2>&1

Le principal inconvénient est que cela supprime également toutes les erreurs qui pourraient être utiles au débuggage du script.

3. Configurer crond pour envoyer la sortie du script vers les logs système et désactiver la notification de la sortie

Vous pouvez configurer crond en éditant le fichier /etc/sysconfig/crond pour y changer la ligne CRONDARGS. L’argument “-s” envoie la sortie vers le log système et l’argument “-m off” désactive la notification email du résultat de la tâche.

Voici un exemple :

cat /etc/sysconfig/crond

Résultat:

# Settings for the CRON daemon.
# CRONDARGS= :  any extra command-line startup arguments for crond
CRONDARGS=-s -m off

Il faut ensuite relancer le service cron pour appliquer la nouvelle configuration avec les nouveaux arguments:

service cron restart

Conclusion

Toutes ces méthodes permettent de supprimer totalement les notifications emails du service cron lorsqu’une tâche est lancée.

Si vous souhaitez ne pas produire de sortie mais garder la possibilité de recevoir un email en cas d’erreur, pensez à rediriger STDOUT vers /dev/null:

*/5 * * * * /example/script > /dev/null

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

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

Cela fait un petit moment que je voulais mettre à jour ma configuration TLS et je me suis dit que la Toussaint serait parfaite pour cela. Aujourd’hui, le serveur passe donc à TLS 1.3, ce qui nécessite une mise à jour d’OpenSSL et la mise à jour des ciphers sous NginX.

Mise à jour d’OpenSSL

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

openssl version

Résultat :

OpenSSL v1.1.0f

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

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

Résultat:

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

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

On met à jour nos sources apt:

nano /etc/apt/sources.list

et on y ajoute sid:

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

On met à jour apt:

apt update

Et on met à jour openssl:

apt install openssl libssl1.1

Résultat:

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

glibc (2.26-5) unstable; urgency=medium

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

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

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

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

 -- Aurelien Jarno   Tue, 23 Jan 2018 22:03:12 +0100

openssl (1.1.1-2) unstable; urgency=medium

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

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

On teste notre nouvelle verison d’openssl:

openssl version

Résultat:

OpenSSL 1.1.1  11 Sep 2018

Et en un peu plus précis:

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

Résultat:

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

Mettre à jour les ciphers pour NginX

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

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

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

On vérifie la configuration:

nginx -t

et on redémarre le serveur:

service nginx restart

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

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

Tous les matins, une sauvegarde des sites hébergés sur le serveur est effectuée. A ce moment là, gzip tourne à plein régime et utilise pendant un certain temps le CPU – la montée en charge atteint 50%, ce qui devient limite pour la réactivité des sites Et pour cause : gzip ne fonctionne qu’en mono-core.

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

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

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

Installation de pigz

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

apt install pigz

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

Remplacer gzip par pigz sur le serveur

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

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

nano .bashrc

et on y ajoute les deux fonctions suivantes :

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

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

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

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

source .bashrc

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

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

Spelling error report

The following text will be sent to our editors: