FreshRSS

🔒
❌ À propos de FreshRSS
Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
À partir d’avant-hierFlux principal

6 extensions pour sauvegarder WordPress

5 août 2021 à 18:01

Avec WordPress, vous pouvez créer de très beaux sites internet personnels comme un blog ou d'entreprise ou présentation de produits.
Mais comment éviter la perte de données ?
En faisant une sauvegarde de votre site WordPress. Vous pouvez effectuer une sauvegarde locale ou à distance dans le Cloud (Google Drive, FTP, OneDrive, ...).

Pour cela, vous pouvez installer une extension qui permet d'exporter la base de données SQL mais aussi les fichiers du site.
Dans cet article, je vous propose une sélection des 6 meilleurs extensions de sauvegardes WordPress.

meilleures extensions de sauvegarde pour WordPress

6 extensions pour sauvegarder WordPress

UpdraftPlus

UpdraftPlus est une extension de sauvegarde très complète avec une version gratuite.
Vous pouvez sauvegarder WordPress manuellement ou planifier des sauvegardes.
Il est aussi possible d'acheter un plugin pour une sauvegarde dans le Cloud vers Microsoft OneDrive, Microsoft Azure, Google Cloud Storage, Backblaze B2, SFTPSCP et WebDAV.

  • Sauvegarde complète ou partielle et incrémentale
  • Vous permet de configurer des horaires de sauvegarde automatiques, pour la commodité ultime.
  • Est plus Rapide et utilise moins de ressources
  • Extension WordPress la plus utilisée avec 3 millions de sites

Choisissez les parties de WordPress à sauvegarder (Core, Thèmes, Extensions, Base de données).

Faire une sauvegarde de son site WordPress avec UpdraftPlus Backups

Le tutoriel du site :

Duplicator

Duplicator est à la fois une extension WordPress de sauvegarde mais aussi de migration.
Elle existe en version gratuite avec des limitations.

Vous configurez un paquet qui correspond à une archive de sauvegarde avec le contenu souhaité (thèmes, extensions, base de données).
Puis au besoin vous restaurez le paquet.
Le paquet peut contenir un fichier install.php avec les instructions de migration pour déplacer WordPress.

Créer un paquet pour sauvegarder WordPress

Voici les fonctionnalités de base :

  • Déplacer, migrer ou cloner un site WordPress entre domaines ou hébergements sans aucune coupure.
  • Récupérer un site en ligne en local pour du développement ;
  • Migrez un site WordPress d’un hébergeur à un autre
  • Sauvegarder manuellement un site WordPress ou certaines parties ;
  • PRO : Sauvegarder dans le Cloud vers Dropbox, Google Drive, Microsoft OneDrive, Amazon S3 et FTP/SFTP
  • Dupliquer un site en production vers un site de pré-production et vice-versa ;
  • Empaqueter un site WordPress entier pour le ré-utiliser ou le distribuer ;
  • Réaliser une migration WordPress complète sans vous embêter avec des scripts d’import/export SQL.

BackWPup

BackWPup est une extension WordPress pour sauvegarder tous vos fichiers joints, ainsi que tous les fichiers systèmes, les extensions et les thèmes dans un seul fichier. Vous pouvez créer une tâche pour mettre à jour votre sauvegarde avec uniquement les fichiers qui ont été modifiés.
Enfin vous pouvez planifier une sauvegarde automatique de votre base de données.

Les fonctionnalités :

  • Sauvegarde de la base de données (nécessite mysqli)
  • Export XML de WordPress
  • Création d’un fichier avec la liste des extensions installées
  • Optimiser la base de données
  • Vérifier et réparer la base de données
  • Sauvegarder les fichiers dans un répertoire local ou FTP au format zip, tar, tar.gz (nécessite gz, ZipArchive)
  • Envoyer les journaux et les sauvegardes par courriel
  • Support du multi-site seulement pour les administrateurs du réseau
  • PRO : Sauvegardes dans le Cloud sur Dropbox, S3, Microsoft Azure (Blob), RackSpaceCloud, SugarSync, Amazon Glacier, Google Drive, OneDrive, HiDrive
  • PRO : Restaurez vos sauvegardes en quelques clics depuis votre admin WordPress. Aussi disponible en tant qu’application autonome.
Lancer une sauvegarde de WordPress avec BackWPup

Attention la version gratuite ne propose pas de fonctionnalités de restauration.
Le ZIP contient tous les fichiers ainsi qu'un export SQL.
Il faut donc réintégrer ce dernier manuellement, ce qui nécessite quelques connaissances informatiques.

All-in-One WP Migration

Voici une autre extension avec une partie gratuite.
Vous pouvez l'utiliser pour créer des sauvegardes que l'on peut restaurer avec la version payante.
Des fonctions d'export et d'import qui inclut  la base de données, les médias, les extensions et les thèmes.
De quoi migrer votre site WordPress.

La création de sauvegarde est très simple.
Par contre, aucune fonction de sauvegarde automatique n'est disponible.

All-in-One WP Migration : Sauvegarder WordPress

Il est possible de télécharger la sauvegarde à tout moment.

All-in-One WP Migration : Sauvegarder WordPress

L'export et import supporte les sources par Fichier, FTP, Dropbox, Google Drive, Amazon S3, URL, OneDrive, Box, Mega, DigitalOcean Spaces, Backblaze B2, Google Cloud Storage, Microsoft Azure Storage, Amazon Glacier, pCloud, WebDAV, S3 Client

All-in-One WP Migration : Sauvegarder à distance WordPress

WPvivid Backup

Voici une autre extension de sauvegarde gratuite qui propose les fonctionnalités suivantes :

  • Sauvegarde de base de donnée
  • Puissant moteur de planification
  • Envoyer des sauvegardes à plusieurs stockages cloud
  • Stratégie incluse/exclue (fichiers/dossiers/types de fichiers)
  • La migration automatique avancée (personnalisez tout ce qu'il faut migrer)

Elle est très simple d'utilisation.
Pour effectuer une sauvegarde manuelle de WordPress, un simple clic suffit.
De même pour activer les planifications de sauvegarde.

WPvivid Backup : Sauvegarder WordPress

C'est aussi la seule extension gratuite qui propose une sauvegarde dans le Cloud.

WPvivid Backup : Sauvegarder WordPress

Database Backup for WordPress

On termine cette revue des extensions de sauvegarde WordPress avec Database Backup for WordPress.
Comme son nom l'indique, elle ne sauvegarde que la base de données.
Les fichiers du site ne le seront pas.

Vous choisissez les tables de la base de données à inclure ou exclure.

Sauvegarder la base de données WordPress avec Database Backup for WordPress

Puis vous obtenez un fichier tar.sql que vous pouvez télécharger ou envoyer par mail.

Sauvegarder la base de données WordPress avec Database Backup for WordPress

Quelle est la meilleure extension de sauvegarde pour WordPress ?

Elles se valent toutes et propose à peu près les mêmes fonctionnalités.
Des sauvegardes locales ou dans le Cloud mais aussi une planifications pour une sauvegarde automatique.
Toutes les extensions existent en version gratuite avec des limitations.
Mais c'est WPvivid Backup qui s'en sort le mieux en proposant des fonctionnalités intéressantes dans la version gratuite.

L’article 6 extensions pour sauvegarder WordPress est apparu en premier sur malekal.com.

Testez la montée en charge de votre serveur avec Locust

17 juillet 2021 à 09:00
Par : Korben

Si vous voulez tester la résistance de votre serveur et l’évolution de ses performances lors d’une augmentation du trafic, rien de mieux qu’un outil de test de montée en charge.

Et c’est pourquoi je vous présente aujourd’hui Locust.

Locust est un outil de test de charge facile à utiliser qui vous permet d’écrire et de jouer des scénarios de test en Python. Ainsi, avec un peu de code, vous pouvez simuler des comportements utilisateurs, qui bouclent ou qui prennent des chemins conditionnels différents.

Locust est également distribué, ce qui signifie que vous pouvez lancer des tests de charges répartis sur plusieurs machines, ce qui permet de simuler des milliers d’utilisateurs simultanés.

Ce qui est sympa également, c’est que Locust possède une interface graphique qui vous affichera la progression de votre test en temps réel. Vous pourrez même modifier la charge pendant l’exécution du test et comme il peut également fonctionner en ligne de commandes, vous pouvez l’intégrer à vos process CI/CD.

Ne pensez pas non plus que Locust soit uniquement dédié à du test de site web. En écrivant un client spécifique, vous pourrez ainsi tester d’autres systèmes ou protocoles.

Pour installer Locust, il vous faudra Python >= 3.6 et lancer la commande suivante :

pip3 install locust

Vous aurez également besoin d’écrire un premier scénario de test. Voici un exemple :

import time
from locust import HttpUser, task, between

class QuickstartUser(HttpUser):
    wait_time = between(1, 2.5)

    @task
    def hello_world(self):
        self.client.get("/hello")
        self.client.get("/world")

    @task(3)
    def view_items(self):
        for item_id in range(10):
            self.client.get(f"/item?id={item_id}", name="/item")
            time.sleep(1)

    def on_start(self):
        self.client.post("/login", json={"username":"foo", "password":"bar"})

Si vous regardez le code, vous pouvez voir qu’il y a 2 @task.

Ce sont les tâches qui seront effectuées par les utilisateurs simulés. Lorsque le QuickstartUser s’exécutera, il choisira au hasard l’une des tâches déclarées. Notez que la @task(3) a une pondération plus élevée, donc il y a 3 fois plus de chances que ce soit celle-ci qui soit choisie.

Ensuite, le reste n’est qu’une histoire de post et de get sur différents endpoints de votre site.

Bref, sauvegardez ce script sous la nom de fichier :

locustfile.py

Puis lancez locust :

locust -f locustfile.py

L’outil se lancera et vous donnera une URL à laquelle accéder avec votre ordinateur. Ensuite y’a plus qu’à mettre vos paramètres et à lancer le test.

Le test commencera alors en vrai. J’espère que votre serveur tiendra le coup 🙂

Et vous pourrez voir de beaux graphiques en temps réel, les erreurs rencontrées et bien sûr récupérer toutes les données pour les exploiter ensuite dans d’autres outils.

Locust est distribué sous licence libre et vous pouvez trouver son code en vous rendant sur le github.

Je vous invite également à lire la documentation ici.

Connaitre les modules PHP installés sur son serveur

9 juillet 2021 à 17:37

Lorsque l'on doit ajouter un nouveau module ou extension à PHP, il convient de vérifier que l'installation est correcte.
Pour cela, on peut avoir besoin de vérifier et connaître les modules PHP installés sur son serveur WEB.

Dans ce tutoriel, je vous donne deux méthodes avec php.ini ou en ligne de commandes pour lister les modules PHP installés.

Connaitre les modules PHP installés sur son serveur

Connaitre les modules PHP installés sur son serveur

avec php.ini

phpinfo est une fonction PHP capable d'afficher la configuration PHP.
Cela inclut des informations sur les options et extensions de compilation PHP, la version PHP, les informations sur le serveur et l'environnement (si compilé en tant que module), l'environnement PHP, les informations sur la version du système d'exploitation, les chemins, les valeurs principales et locales des options de configuration, les en-têtes HTTP et le PHP Licence.

  • Créez un fichier phpinfo.php sur votre site WEB
  • Puis insérez la code suivant :
<?php
phpinfo();
?>
  • Enregistrez le fichier
  • Ensuite accédez à l'URL https://www.adressedusite.com/phpinfo.php
  • Si tout va bien la page phpinfo s'affiche avec la liste des extensions
Connaitre les modules PHP installés sur son serveur avec phpinfo

Notez qu'il est possible de restreindre les informations à la liste des extensions et modules en utilisant la fonction phpinfo de cette manière ;

phpinfo(INFO_MODULES);

en ligne de commandes

Si vous avez un accès SSH à votre serveur, vous pouvez aussi lister les extensions PHP actives en ligne de commandes.

php -m
  • La liste des modules PHP s'affiche
Connaitre les modules PHP installés sur son serveur en ligne de commandes

L’article Connaitre les modules PHP installés sur son serveur est apparu en premier sur malekal.com.

Installer/Configurer le module Google PageSpeed pour optimiser vos sites WEB

9 juillet 2021 à 13:58

Pour atteindre le score de 100 sur Google PageSpeed Insights, de nombreuses optimisations sont à effectuer sur votre site WEB.
Pour vous y aider, Google propose un module pour Apache (Mod_PageSpeed) ou Nginx (ngx_pagespeed) afin d’automatiser un grand nombre d'opérations.
Mod_PageSpeed effectuer les tâches suivantes côté serveur :

  • Minimise HTML, CSS et JavaScript
  • Optimise la mise en cache des fichiers
  • Combine les fichiers JavaScript externes et les optimise
  • Optimise le chargement des fichiers en donnant la priorité aux CSS importants et en différant JavaScript
  • Optimise les images via la compression, la conversion de PNG en JPG (si aucune transparence), le redimensionnement des images et la conversion en WebP (pour les navigateurs prenant en charge WebP)

Ainsi, votre site délivre une page optimisée en respectant les conceptions de structures et de code.
Au final, le module permet de gagner en vitesse de chargement des pages, faire baisser les indicateurs FCP, LCP, TBT, CLS pour améliorer score google pagespeed insights.

Dans ce tutoriel, je vous montre comment installer le Module Google PageSpeed de Google et comment le configurer sur Nginx.

Installer/Configurer le module Google PageSpeed pour optimiser vos sites WEB

Installer le Module Google PageSpeed

Pour installer le module Google PageSpeed dans Nginx, deux méthodes depuis les sources ou via les paquets de votre distribution Linux.

Depuis les sources

Pour installer depuis les sources pour Debian, Ubuntu, CentOS ou Fedora, suivez le tutoriel officiel : Installer ngx_pagespeed depuis les sources

  • Installez les paquets, libraires et paquets essentiels (make, gcc) pour compiler depuis des sources
sudo apt-get install build-essential zlib1g-dev libpcre3 libpcre3-dev unzip uuid-dev
  • Puis passez les commandes suivantes pour configurer puis compiler le module pagespeed-ngx depuis les sources.
  • Modifiez la variable de version présente sur la première ligne. Les versions sont présentes sur la page de téléchargement.
NPS_VERSION=1.13.35.2-stable
cd
wget -O- https://github.com/apache/incubator-pagespeed-ngx/archive/v${NPS_VERSION}.tar.gz | tar -xz
nps_dir=$(find . -name "*pagespeed-ngx-${NPS_VERSION}" -type d)
cd "$nps_dir"
NPS_RELEASE_NUMBER=${NPS_VERSION/beta/}
NPS_RELEASE_NUMBER=${NPS_VERSION/stable/}
psol_url=https://dl.google.com/dl/page-speed/psol/${NPS_RELEASE_NUMBER}.tar.gz
[ -e scripts/format_binary_url.sh ] && psol_url=$(scripts/format_binary_url.sh PSOL_BINARY_URL)
wget -O- ${psol_url} | tar -xz  # extracts to psol/
  • Ensuite on peut passer à la compilation de Nginx. Là aussi il faut choisir la version à installer en suivant celles disponibles sur la page de téléchargement.
  • Si vous souhaitez plutôt construire ngx_pagespeed en tant que module dynamique, utilisez --add-dynamic-module= au lieu de --add-module=.
NGINX_VERSION=1.18.0
cd
wget -O- http://nginx.org/download/nginx-${NGINX_VERSION}.tar.gz | tar -xz
cd nginx-${NGINX_VERSION}/
./configure --add-module=$HOME/$nps_dir ${PS_NGX_EXTRA_FLAGS}
make
sudo make install

Depuis APT

Suivez les instructions de cette page pour installer sur Debian, Ubuntu, CentOS ou Fedora : Installer depuis les paquets par APT

Au moment où sont écrites ces lignes, Debian est en version 10 (Buster).
nginx est en version 1.14 qui est trop ancienne pour accueillir pagespeed depuis les paquets.
Il faut mettre à jour nginx vers une version plus récente :

  • Ajoutez la ligne suivante dans /etc/apt/sources.list :
deb https://nginx.org/packages/debian/buster nginx
  • Installez la clé GPG du dépôt :
wget https://nginx.org/keys/nginx_signing.key
sudo apt-key ajouter nginx_signing.key

Mettez à jour l'index du package puis installe le paquet nginx :

sudo apt-get update
udo apt-get install nginx
  • Installez le paquet pagespeed depuis le lien donné précédemment

Configurer le Module Google PageSpeed

Exemple de configuration

Voici un exemple de configuration complète pour charger le module ngx_pagespeed dans Nginx.

  • La directive http se trouve dans /etc/nginx/nginx.conf où y charge le module et on active l'emplacement du cache.
  • Puis on configure les chemins
  • Ensuite on active pagespeed avec pagespeed on;
  • Au besoin on ajoute un en-tête HTTP
  • Ensuite on configure le cache
  • Puis la configuration des statistiques pour la page d'administration
  • Autoriser les domaines avec la directive pagespeed Domain
load_module modules/ngx_pagespeed.so;

  http {
    pagespeed On;
    pagespeed FileCachePath "/var/cache/ngx_pagespeed/";
    pagespeed SslCertDirectory /etc/pki/tls/certs;
    pagespeed SslCertFile /etc/pki/tls/cert.pem;

    # Enables pagespeed for each website:
    pagespeed on;

    pagespeed XHeaderValue                   "Powered By ngx_pagespeed";

    ## PageSpeed Cache Purge
    pagespeed EnableCachePurge               on;
    pagespeed PurgeMethod                    PURGE;
    pagespeed DownstreamCacheRewrittenPercentageThreshold 95;
 
    # Cache
    pagespeed MaxCacheableContentLength      -1;
    pagespeed FileCacheSizeKb                102400;
    pagespeed FileCacheCleanIntervalMs       3600000;
    pagespeed FileCacheInodeLimit            500000;
    pagespeed LRUCacheKbPerProcess           1024;
    pagespeed LRUCacheByteLimit              16384;

    ## Enable these if you want to see the admin console
    pagespeed LogDir /var/log/pagespeed;
    pagespeed Statistics on;
    pagespeed StatisticsLogging on;

    ## PageSpeed admin pages configuration
    pagespeed UsePerVhostStatistics on;
    pagespeed StatisticsLoggingIntervalMs 60000;
    pagespeed StatisticsLoggingMaxFileSizeKb 1024;
    pagespeed MessageBufferSize 100000;
    pagespeed StatisticsPath /monitor/ngx_pagespeed_statistics;
    pagespeed GlobalStatisticsPath /monitor/ngx_pagespeed_global_statistics;
    pagespeed MessagesPath /monitor/ngx_pagespeed_message;
    pagespeed ConsolePath /monitor/pagespeed_console;
    pagespeed AdminPath /monitor/pagespeed_admin;
    pagespeed GlobalAdminPath /monitor/pagespeed_global_admin;

    #Autoriser les domaines
    pagespeed Domain *.malekal.com;

    ## Enable these if you want to see the admin console
    pagespeed LogDir /var/log/pagespeed;
    pagespeed Statistics on;
    pagespeed StatisticsLogging on;
}
  • Puis voici un exemple de configuration de vhost. Pagespeed on/off pour désactiver le module sur un site ou global
server {
    listen 80;
    server_name www.example1.com;
    root /www/example1;
    pagespeed MapRewriteDomain cdn.example1.com *example.com;
  }

  server {
    listen 80;
    server_name www.example2.org;
    root /www/example2;
    pagespeed MapRewriteDomain cdn.example2.org *example.org;
    # Don't want combine_css here
    pagespeed DisableFilters combine_css;
  }

  server {
    listen 80;
    server_name www.example3.org;
    root /www/example3;

    # mod_pagespeed off for this virtual host
    pagespeed off;
  }
}

Activer les filtres

Le module Google PageSpeed fonctionne avec des filtres à activer.
Comme cela peut casser des sites, il faut y aller petit à petit.
Sachez que vous pouvez activer un ensemble de filtres.

PageSpeed propose trois « niveaux » pour simplifier la configuration : PassThrough, CoreFilters et OptimizeForBandwidth.
L'ensemble CoreFilters contient des filtres qui, selon l'équipe de PageSpeed, sont sans danger pour la plupart des sites Web.

  • En utilisant l'ensemble CoreFilters, à mesure que PageSpeed est mis à jour avec de nouveaux filtres, votre site deviendra plus rapide
  • Le paramètre OptimizeForBandwidth offre une garantie de sécurité renforcée et convient comme paramètre par défaut à utiliser avec des sites qui ne connaissent pas PageSpeed
pagespeed RewriteLevel PassThrough;

Ensuite on active les manuellement filtres souhaités.
Pour Nginx, il faut utiliser la directive pagespeed EnableFilter.
On peut les séparer par des virgules.

pagespeed EnableFilters combine_css,combine_javascript;

Ou utiliser plusieurs fois la directive.

pagespeed EnableFilters rewrite_css;
pagespeed EnableFilters collapse_whitespace,remove_comments;
pagespeed EnableFilters flatten_css_imports;

Pour harmoniser les server, créez un fichier pagespeed_filters.conf
Puis appelez le dans chaque server par include :

include pagespeed_filters.conf;

La liste dese filtres

Le module PageSpeed de Google propose énormes de filtres.
La liste complète est disponible dans sur ce lien et les modules pagespeed

Nom du FiltreDescription
responsive_imagesRend les images réactives en ajoutant srcset avec des images optimisées pour différentes résolutions.
outline_cssExternalisez de gros blocs de CSS dans un fichier pouvant être mis en cache.
outline_javascriptExternalisez de gros blocs de JS dans un fichier pouvant être mis en cache.
combine_cssCombine plusieurs éléments CSS en un seul.
rewrite_css
rewrite_javascript_inline
Réécrit les fichiers CSS ou JavaScript pour supprimer les espaces et les commentaires en excès et, si activé, réécrit ou étend le cache des images référencées dans les fichiers CSS. En mode OptimizeForBandwidth, la minification se produit sur place sans modifier les URL.

Réécrit les fichiers JavaScript pour supprimer les espaces et les commentaires en excès. En mode OptimizeForBandwidth, la minification se produit sur place sans modifier les URL.
make_google_analytics_asyncConvertir l'utilisation synchrone de l'API Google Analytics en asynchrone
rewrite_javascript_inlineRéécrit les blocs JavaScript en ligne pour supprimer les espaces blancs et les commentaires en excès.
inline_css
inline_google_font_css
inline_javascript
Injecter le code CSS ou Javascript dans le document HTML.
rewrite_imagesOptimise les images, les réencode, supprime les pixels en excès et inline les petites images. En mode OptimizeForBandwidth, la minification se produit sur place sans modifier les URL.
convert_jpeg_to_progressive
convert_png_to_jpeg
oonvert_gif_to_png
convert_jpeg_to_webp
convert_to_webp_animated
convert_to_webp_lossless
Conversion de formats d'images pour alléger leurs poids.
insert_image_dimensionsAjoute des attributs de largeur et de hauteur aux balises qui en manquent.
resize_images
resize_mobile_images
Redimensionnez les images pour alléger leurs poids
recompress_jpeg
recompress_png
recompress_webp
Supprimer les métadonnées en excès.
Les filtres de pagespeed

Enfin pour désactiver tous les filtres, ce sera comme ceci :

pagespeed ForbidAllDisabledFilters true;

Modifier la configuration des filtres

Certains filtres accueillent des réglages.
Par exemple pour les redimensionnement ou compression, il faut établir des seuils.
Voici les réglages par défaut avec les noms de filtres.

CssFlattenMaxBytes                       102400 (was 2048 prior to 1.9.32.1)
CssImageInlineMaxBytes                        0
CssInlineMaxBytes                          2048
CssOutlineMinBytes                         3000
ImageInlineMaxBytes                        3072
ImageJpegNumProgressiveScans                 -1
ImageJpegNumProgressiveScansForSmallScreens  -1
ImageLimitOptimizedPercent                  100
ImageLimitResizeAreaPercent                 100
ImageRecompressionQuality                    85
ImageResolutionLimitBytes              32000000
JpegRecompressionQuality                     -1
JpegRecompressionQualityForSmallScreens      70
WebpRecompressionQuality                     80
WebpAnimatedRecompressionQuality             70
WebpRecompressionQualityForSmallScreens      70
JsInlineMaxBytes                           2048
JsOutlineMinBytes                          3000
MaxInlinedPreviewImagesIndex                 -1
MinImageSizeLowResolutionBytes             3072
RetainComment                             "[WILDCARD PATTERN]"
RewriteRandomDropPercentage                   0

Voir cette page : Image Filter and Option Reference

Mappage LoadFromFile

Par défaut, PageSpeed charge les sous-ressources via une récupération HTTP ce qui peut surcharger le serveur WEB.
Aussi, Il est plus rapide de charger les sous-ressources directement à partir du système de fichiers, mais cela peut ne pas être sûr car les sous-ressources peuvent être générées dynamiquement ou les sous-ressources peuvent ne pas être stockées sur le même serveur.

Cependant, vous pouvez explicitement indiquer à PageSpeed de charger des sous-ressources statiques à partir du disque en utilisant la directive LoadFromFile.
Une mappage configurée avec LoadFromFile permet le chargement du système de fichiers pour tout ce qui correspond. Si vous avez des répertoires ou des types de fichiers qui ne peuvent pas être chargés directement à partir du système de fichiers, LoadFromFileRule vous permet d'ajouter des règles précises pour contrôler quels fichiers chargés directement et arriveront au processus standard, via HTTP.

pagespeed LoadFromFile "https://forum.malekal.com" "/data/www/forum.malekal.com";

PageSpeed et memcached

Par défaut, la localisation du cache se trouve sur le disque mais on peut aussi utiliser memcached pour bénéficier d'un cache en mémoire.
Voici un exemple de configuration :

## Speed up PageSpeed by storing it in memcached
pagespeed MemcachedThreads               1;
pagespeed MemcachedServers               "localhost:11211";

Page d'administration et statistique

Le module propose aussi une page d'administration WEB pour chaque domaine.
Pour l'activer :

  • Créez un fichier pagespeed_monitoring.conf avec ce contenu :
location ~ "\.pagespeed\.([a-z]\.)?[a-z]{2}\.[^.]{10}\.[^.]+" { add_header "" ""; }
location ~ "^/pagespeed_static/" { }
location ~ "^/ngx_pagespeed_beacon$" { }
location /ngx_pagespeed_statistics { allow 127.0.0.1; deny all; }
location /ngx_pagespeed_global_statistics { allow 127.0.0.1; deny all; }
location /ngx_pagespeed_message { allow 127.0.0.1; deny all; }
location /pagespeed_console { allow 127.0.0.1; deny all; }
location ~ ^/pagespeed_admin { allow 127.0.0.1; deny all; }
location ~ ^/pagespeed_global_admin { allow 127.0.0.1; deny all; }
  • Allow protège l'accès aux ressources et permet de restreindre les adresses IP à consulter la page, sinon vous aurez une erreur 403 access denied.
  • Faites un include de la page dans la directive server de chaque site :
include pagespeed_monitoring.conf;
  • On peut alors visualiser des graphiques qui montrent le % de mise en cache, les erreurs de réécritures des images, etc.
La page d'administration et statistique du module Pagespeed
  • La page d'administration de Pagespeed donne aussi la configuration.
  • Enfin on peut aussi vider le cache depuis l'interface.
La page d'administration et statistique du module Pagespeed

L’article Installer/Configurer le module Google PageSpeed pour optimiser vos sites WEB est apparu en premier sur malekal.com.

Optimiser PHP-FPM

2 août 2019 à 16:25

PHP-FPM est un serveur PHP que l'on utilise souvent avec nginx afin de délivrer du contenu PHP.

Par défaut, la configuration de PHP-FPM n'est pas top surtout si vous avez un site avec pas mal de trafic.

Cet article vous présente les paramètres à modifier afin d'optimiser PHP-FPM.

Optimiser PHP-FPM

Introduction

PHP-FPM est un serveur PHP que l'on peut utiliser avec Nginx ou Apache.
Ce dernier agit en tant que proxy pour se connecter au serveur PHP afin de retourner les pages WEB au navigateur WEB.

Le schéma ci-dessous récapitule le process.

Image credit: ProinerTech

PHP-FPM fonctionne avec des processus que l'on peut configurer.
Un peu comme sur Apache avec le nombre de clients.

Lorsque le nombre de processus est trop petit, le serveur ne pourra répondre à la demande.
En général, cela se traduit par des erreurs de type Connection reset by peer dans les logs.
En effet la connexion de Nginx ou Apache vers PHP-FPM ne se fait pas car ce dernier ne parvient pas à répondre.

Nginx et Connection reset by peer vers PHP-FPM

Du côté de l'internaute, on assiste à des latences et parfois des erreurs HTTP.
Une bonne configuration permet de délivrer les pages rapidement et éviter de mauvaises expériences.

Optimiser les paramètres pm

La configuration de PHP-FPM se fait depuis le fichier www.conf.
Par exemple sur une Debian, on trouve ces deux fichiers :

  • /etc/php/7.3/fpm/php-fpm.conf.
  • et une autre partie dans /etc/php/7.3/fpm/pool.d/www.conf

Bien sûr selon la distribution Linux ou si vous utilisez Windows, le fichier de configuration aura un autre emplacement.

C'est ce dernier qui nous intéresse.
Les paramètres pm sont les plus importants et régit le fonctionnement du serveur PHP.

Que sont les paramètres PM ?

Tout d'abord le paramètre pm propose trois modes de fonctionnement.

  • demand : Les processus sont créés et supprimés à la demande.
  • dynamic : On fixe un nombre minimale et maximale de processus que PHP-FPM va garder en vie.
  • static : Un nombre fixe de processus est gardé quoiqu'il arrive.

Ces paramètres sont rangés du moins performant au plus performant.
En effet, les va et vient incessant qui nécessite de créer des processus réduit les performances.
Par contre, le dernier paramètre consomme plus de ressources.
En effet les processus PHP restent toujours ouverts.

Voici ensuite les paramètres que l'on peut régler pour le cas du dynamic et static.

  • pm.max_children: Le nombre maximum de processus enfant
  • pm.max_requests: Le nombre de requête par processus avant de ressusciter.
  • pm.min_spare_servers: Le nombre minimum de processus serveur inactifs
  • pm.max_spare_servers: Le nombre maximum de processus serveur inactifs
  • pm.process_idle_timeout: Le temps avant qu'un processus inactifs soient tués.
PHP-FPM et les paramètres pm.

Par exemple le nombre de processus inactifs doit être suffisants afin d'éviter de devoir en créer.
Cela fait perdre du temps et selon comment peut faire que le serveur ne répond plus.
Il ne sert pas non plus à créer trop de serveurs inactifs car ils vont consommer de la mémoire pour rien.
En clair donc, il faut trouver un équilibre entre votre trafic et les ressources systèmes.

Par défaut, sur Debian, PHP-FPM est réglé en mode dynamique.
Toutefois sur les sites qui ont un peu de trafic, les réglages sont trop petits.
Ainsi on arrive à un message : server reached pm.max_children settings. Consider raising it.
Les conséquences évoquées plus haut comme des latences ou erreur 502 arrivent alors régulièrement.
Ce dernier indique d'augmenter le nombre maximum de processus enfant.

PHP-FPM : server reached pm.max_children settings. Consider raising it.

Les bon réglages

On conseille donc de régler le serveur en static pour de meilleurs performances surtout si vous avez du trafic.
En effet pour les petits sites le gain ne se verra pas beaucoup car il n'y a pas beaucoup de fluctuation.
Par contre, si vous avez de grosses fluctuations de trafic, le mode dynamic risque de poser des problèmes.

Enfin le mode static demande plus de ressources systèmes.

Les paramètres se font ensuite selon le volume de trafic.
Voici un ordre d'idée.

TraficMoyenImportant
Max Children100500
Process Idle Timeout100150
Max Requests3002000

Bien entendu, vous pouvez partir du plus petit et monter au fur et à mesures afin de tester.

D'autre part, vous pouvez calculer le nombre maximum de processus PHP-FPM.
Pour cela, on utilise la commande top :

top -bn1 | grep php-fpm

Prenez en compte la 7e colonne qui correspond au RES, soit la mémoire privée du processus.
On voit que la moyenne est à 100k.
Ainsi vous pouvez calculer la consommation mémoire totale selon le nombre de processus.

Lister les processus php-fpm en cours de fonctionnement

Enfin PHP-FPM propose une page de status qui permet aussi d'obtenir des informations.

Activer la page de status

On peut activer les pages de status en décommettant la valeur pm.status_path.

Activer la page de status

Ensuite on créé le site qui va bien dans nginx.
Par exemple comme ceci.
Bien sûr, vous devez modifier selon votre configuration surtout par rapport au fastcgi_pass.

server {
#### STATUS...
        server_name localhost;
        server_name 127.0.0.1;
        access_log off;

        location /nginx_status {
                stub_status on;
                allow 127.0.0.1;
                deny all;
        }

        location ~ ^/(status|ping)$ {
            include fastcgi_params;
            fastcgi_param SCRIPT_FILENAME $fastcgi_script_name;
            fastcgi_pass   unix:/run/php/php7.3-fpm.sock;
             allow 127.0.0.1;
             deny all;
        }
}
Activer la page de status

On peut alors accéder au site avec l'URL : http://127.0.0.1/status.
Ce qui donne ceci.

status php-fpm pour obtenir des informations

Ce qui donne les informations suivantes :

  • pool - le nom de la piscine
  • process manager - statique, dynamique ou à la demande
  • start time - la date et l'heure auxquelles FPM a commencé
  • start since - nombre de secondes écoulées depuis le début de FPM
  • accepted conn - le nombre de demandes acceptées par le pool
  • listen queue - nombre de demandes dans la file d'attente des connexions en attente
  • max listen queue - nombre maximal de demandes dans la file d'attente de connexions en attente depuis le démarrage de FPM
  • listen queue len - taille de la file d'attente des connexions en attente
  • idle process- nombre de processus inactifs
  • active processes - nombre de processus actifs
  • total process - nombre de processus inactifs + processus actifs
  • max actives processes - nombre maximal de processus actifs depuis le démarrage de FPM
  • max children reached - nombre de fois que la limite de processus a été atteinte, lorsque pm tente de démarrer plus d'enfants (fonctionne uniquement pour pm ‘dynamic’ et ‘ondemand’)
  • requêtes lentes - nombre de requêtes dépassant votre valeur request_slowlog_timeout

Ainsi ici on voit que l'on a beaucoup de processus en idle.
Le maximum de processus actif est 41.
On doit donc pouvoir réduire le nombre de processus.
Toutefois le serveur n'est pas encore saturée au niveau de la mémoire comme le montre top.

Consommation mémoire php-fpm

Activer les plugins PHP-FPM pour Munin

Enfin Munin peut grapher des infos PHP-FPM afin de suivre dans le temps.
Cela permet aussi d'obtenir des infos supplémentaires.
Pour se faire, il faut ajouter des plugins sur Munin.
Cela n'a rien de compliqué.
Deux projets github existent :

Ces derniers nécessitent l'activation de la page status de PHP-FPM.

Ci-dessous les connexions PHP-FPM avec leurs états.
Le second graph est très important.
En effet, il donne le nombre de processus max avec le nombre d'actif et donc idle.
Il ne faut pas que le nombre de processus actif se rapproche trop du nombre max total.
Sinon vous aurez des problèmes de performance.

PHP-FPM en graphique sur Munin

L'âge des processus avant que ces derniers soit tués quand il dépasse le délai max d'inactivité (idle).
On trouve aussi l'utilisation mémoire moyenne.
Ce dernier graph permet donc de calculer le nombre de maximum de processus que l'on peut lancer.

PHP-FPM en graphique sur Munin

Enfin la CPU utilisée par PHP-FPM et le nombre de processus.
On retrouve ici la configuration pm.max_children.

PHP-FPM en graphique sur Munin

Les slowlog

Enfin les slowlog enregistrent les requêtes lentes.
Cela permet donc de connaître les pages lentes de votre site ou déceler des anomalies.

Vous pouvez activer ces derniers.

Pour cela, on active le paramètre slowlog avec le chemin du fichier journal.
Le délai d'écriture avec le paramètre request_slowlog_timeout.

Les slowlog de PHP-FPM

Enfin on relance php-fpm avec service php-fpm restart.

Les slowlog de PHP-FPM

L’article Optimiser PHP-FPM est apparu en premier sur malekal.com.

Optimiser le cache de Nginx

7 juillet 2021 à 10:46

Nginx est un serveur WEB très performant qui a grâce à sa rapidité a réussi à détrôner Apache.
Il offre énormément de directives de cache pour optimiser le serveur WEB et gagner en vitesse.
Que vous aillez un contenu statique, dynamique, WordPress, Joomla ou autres CMS, grâce au cache Nginx, vous pouvez améliorer les temps de réponse et vitesse de chargement de vos pages WEB.

Dans ce tutoriel complet, je vous donne tous les réglages à faire sur le cache Nginx pour une vitesse maximale de votre site WEB.

Optimiser le cache de Nginx

Optimiser le cache de Nginx

Pour la mise en place et configuration générale du cache Nginx, suivez ce tutoriel :

Les buffers

Les buffers sont des tampons en mémoire pour stocker des données en bénéficiant de la vitesse de la mémoire RAM.
En augmentant, les tampons, cela peut améliorer les temps de réponse selon les besoins de vos applications.
Mais le serveur WEB va utiliser plus de mémoire.
De plus, des valeurs trop hautes, peut aussi aider à faire tomber plus facilement votre serveur WEB par une attaque par déni de service.
ils font donc trouver le bon équilibre entre performances et mémoire disponible.

  • client_body_buffer_size : définit la taille de la mémoire tampon pour la lecture du corps de la requête client. Si le corps de la requête est plus grand que le tampon, le corps entier ou seulement sa partie est écrit dans un fichier temporaire. La valeur doit être réglé sur la limite de la taille d'un fichier en upload
  • client_header_buffer_size : tampon pour la lecture de l'en-tête HTTP de demande du client
  • client_max_body_size : la taille maximale autorisée du corps de la demande client. Si la taille d'une requête dépasse la valeur configurée, l'erreur 413 (Request Entity Too Large) est renvoyée au client
  • large_client_header_buffers : La taille maximum des tampons utilisés pour la lecture d'un en-tête de requête client volumineux. Une ligne de demande ne peut pas dépasser la taille d'un tampon, ou l'erreur 414 (Request-URI Too Large) est renvoyée au client. Un champ d'en-tête de demande ne peut pas non plus dépasser la taille d'un tampon, sinon l'erreur 400 (Mauvaise demande) est renvoyée au client

Dans Nginx, il existe le tampon d'en-tête HTTP par défaut qui est configuré avec la directive client_header_buffer_size. Lorsqu'une requête arrive, les en-têtes sont d'abord lus dans ce tampon, les large_client_header_buffers ne sont pas engagés tant que la taille totale des en-têtes de requête ne dépasse pas la valeur configurée pour client_header_buffer_size, par défaut 1 Ko.

En général, on préconise ces réglages mais cela dépend de vos besoins.

client_body_buffer_size 10K;
client_header_buffer_size 1k;
client_max_body_size 8m;
large_client_header_buffers 4 4k;

On préconise aussi la formule suivant qui s'approche de celle pour optimiser PHP-FPM :

MAX_RAM = client_body_buffer_size X concurrent_traffic - OS_RAM - FS_CACHE.

Proxy buffers

Par défaut, NGINX met en mémoire tampon les réponses des serveurs proxy. Une réponse est stockée dans les tampons internes et n'est envoyée au client qu'une fois la réponse complète reçue.
La mise en mémoire tampon permet d'optimiser les performances avec les clients lents, ce qui peut faire perdre du temps au serveur proxy si la réponse est transmise de NGINX au client de manière synchrone.
Cependant, lorsque la mise en mémoire tampon est activée, NGINX permet au serveur proxy de traiter les réponses rapidement, tandis que NGINX stocke les réponses aussi longtemps que les clients ont besoin de les télécharger.

  • proxy_buffers : Définit le nombre et la taille des tampons utilisés pour lire une réponse du serveur proxy, pour une seule connexion. Par défaut, la taille du tampon est égale à une page mémoire. Il s'agit de 4K ou de 8K, selon la plate-forme.
  • proxy_buffer_size : Définit la taille du tampon utilisé pour lire la première partie de la réponse reçue du serveur proxy. Cette partie contient généralement un petit en-tête de réponse. Par défaut, la taille du tampon est égale à une page mémoire. Il s'agit de 4K ou de 8K, selon la plate-forme. Il peut cependant être réduit. Cette valeur est à augmenter, si vous rencontrez l'erreur too big header while reading response header from upstream.
  • proxy_busy_buffers_size : Lorsque la mise en mémoire tampon des réponses du serveur proxy est activée, limite la taille totale des tampons pouvant être occupés à envoyer une réponse au client alors que la réponse n'est pas encore entièrement lue. En attendant, le reste des tampons peut être utilisé pour lire la réponse et, si nécessaire, mettre en mémoire tampon une partie de la réponse dans un fichier temporaire. Par défaut, la taille est limitée par la taille de deux tampons définie par les directives proxy_buffer_size et proxy_buffers
  • proxy_max_temp_file_size : il s'agit de la taille maximale, par requête, pour un fichier temporaire sur le disque. Ceux-ci sont créés lorsque la réponse en amont est trop grande pour tenir dans un tampon.
  • proxy_temp_file_write_size : c'est la quantité de données que Nginx écrira dans le fichier temporaire à un moment donné lorsque la réponse du serveur proxy est trop grande pour les tampons configurés.
  • proxy_temp_path : il s'agit du chemin d'accès à la zone du disque où Nginx doit stocker tous les fichiers temporaires lorsque la réponse du serveur en amont ne peut pas tenir dans les tampons configurés.
Si votre nginx fait un proxy pass vers PHP-FPM, il faut alors optimiser les valeurs fastcgi_buffers, fastcgi_buffer_size, fastcgi_busy_buffers_size en suivant la même logique.

La taille proxy_buffers doit être choisie pour éviter les E/S disque. Si la taille de la réponse est supérieure à (proxy_buffers size + proxy_buffer_size), la réponse peut être écrite sur le disque, augmentant ainsi les E/S, le temps de réponse, etc.

Pour vous aider à calculer la bonne valeur proxy_buffers, utilisez curl pour récupérer la taille de l'en-tête HTTP :

curl -s -w \%{size_header} -o /dev/null "https://www.malekal.com" -H "Accept-Encoding: gzip"

Pour définir proxy_buffers, il faut déterminer la taille d'une page WEB, par exemple avec curl :

curl -so /dev/null https://forum.malekal.com/ -w '%{size_download}'

Si vous retournez systématiquement du contenu compressé alors :

curl --compressed -so /dev/null https://forum.malekal.com/ -w '%{size_download}'

Dans mon cas, cela retourne 65872 (65k).
On peut alors définir les valeurs en divisant par le nombre de buffers.

proxy_buffers 8 8k; # 64-bits
proxy_buffers 4 16k; # 32-bits

Désactiver proxy buffering

proxy_busy_buffers_size correspond à a mise en mémoire tampon des réponses du serveur proxy.

Lorsque la mise en mémoire tampon est activée, Nginx reçoit une réponse du serveur proxy dès que possible, l'enregistrant dans les tampons définis par les directives proxy_buffer_size et proxy_buffers.
Si la réponse entière ne tient pas dans la mémoire, une partie peut être enregistrée dans un fichier temporaire sur le disque.
Si la mise en mémoire tampon est désactivée, la réponse est envoyée au client de manière synchrone pendant qu'il la reçoit du serveur proxy. Vous pouvez donc abaisser le Time To First Byte (TTFB).

Lorsque la mise en mémoire tampon est désactivée, la réponse est transmise à un client de manière synchrone, dès sa réception. nginx n'essaiera pas de lire l'intégralité de la réponse du serveur proxy. La taille maximale des données que nginx peut recevoir du serveur à la fois est définie par la directive proxy_buffer_size.

Activer la compression Gzip

Il existe deux méthodes de compression GZIP et Brotli des pages WEB.
Ce dernier est plus efficace mais n'est pas inclut par défaut dans nginx.
Il faut recompiler ce dernier ou trouver un paquet pour votre distribution Linux.

Cela réduit fortement la taille des pages WEB pour accélérer le transfert.

Pour activer GZIP sur Nginx :

    gzip on;
    # gzip_static on;
    gzip_min_length 10240;
    gzip_buffers 16 8k;
    gzip_comp_level 2;
    gzip_vary on;
    gzip_disable msie6;
    gzip_proxied expired no-cache no-store private auth;
    gzip_types
        # text/html is always compressed by HttpGzipModule
        text/css
        text/javascript
        text/xml
        text/plain
        text/x-component
        application/javascript
        application/x-javascript
        application/json
        application/xml
        application/rss+xml
        application/atom+xml
        font/truetype
        font/opentype
        application/vnd.ms-fontobject
        image/svg+xml;

Mettre en place un cache statique

Ensuite il faut configurer la mise en cache statique pour le navigateur internet.
Ainsi, les fichiers statiques seront téléchargés dans le navigateur WEB. Lors du retour sur le site, ils ne seront plus télécharger sur le site, ce qui permet de gagner en vitesse de chargement de la page.

Voici un exemple pour définir une mise en cache par extension de fichiers.
On désactive aussi les journaux pour limiter les accès disque.

location ~* ^.+\.(xml|ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|css|rss|atom|js|jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi|wav|bmp|rtf|woff2|webp)$ {
                access_log off;
                log_not_found off;
                add_header Cache-Control "public, no-transform";
                expires 365d;
        }

Microcaching avec tmpfs

Le contenu dynamique ne peut être mis en cache, du moins trop longtemps, puisque ce dernier temps à être modifié régulièrement.
Mais pour diminuer le TTFB ou Time To First Byte, vous pouvez utiliser la technique de est le microcaching.
Cela consiste à définir un délai de cache très court entre 1 et 10s.
C'est une méthode efficace pour accélérer la livraison de contenu dynamique et non personnalisé en le mettant en cache pendant de très courtes périodes.
Cela peut accélérer une application basée sur WordPress jusqu'à 400 fois en utilisant la technique de microcaching.

Par exemple sur PHPBB, un forum à contenu dynamique, lorsque la page est en cache, le DOM se charge en moins de 600 ms.

Microcaching avec tmpfs pour diminuer le temps de chargement des pages WEB

Lorsque la page n'est pas en cache, le temps de chargement du DOM dépasse les 2s.

Microcaching avec tmpfs pour diminuer le temps de chargement des pages WEB

Voici comment mettre en place un microcaching en mémoire grâce à tmpfs.

  • Tout d'abord on créé le répertoire suivant :
mkdir -p /var/cache/nginx/ramcache
  • Puis on le monte en mémoire :
mount -t tmpfs -o size=2G tmpfs /var/cache/nginx/ramcache
  • Modifiez /etc/fstab afin de le recréer au démarrage du serveur :
tmpfs /var/cache/nginx/ramcache tmpfs defaults,size=2G 0 0
  • Puis on créé la zone de microcaching qui sera stocké dans cet espace :
fastcgi_cache_path /var/cache/nginx/ramcache/fastcgi_temp/ levels=1:2 keys_zone=cachezone:100m max_size=2g inactive=60m use_temp_path=off;
  • Ensuite pour l'appeler dans la directive server :
fastcgi_cache_key $scheme$request_method$host$request_uri;
proxy_cache_lock on;
proxy_cache_use_stale updating;
fastcgi_ignore_headers Cache-Control Expires Set-Cookie;
  • Enfin relancez le service nginx :
/etc/init.d/nginx restart
Notez qu'il existe des modules Nginx pour utiliser memcached ou redis comme emplacement de cache.

Liens

Liens

L’article Optimiser le cache de Nginx est apparu en premier sur malekal.com.

Configurer le cache de Nginx

7 juillet 2021 à 10:46

En informatique, la mise en cache est un procédé courant pour améliorer les performances.
Nginx, un serveur WEB très populaire ne déroge pas à cette règle.
Grâce à une mise en cache efficace, vous pouvez grandement réduire le temps de chargement des sites WEB.
Avec des pages rapides, vous améliorez l'expérience utilisateur final et votre référencement sur les moteurs de recherche comme Google.

Dans ce tutoriel, je vous montre comment configurer le cache de Nginx pour obtenir de meilleures performances.
Pour vous y aider, vous trouverez plusieurs exemples de configuration de cache nginx.

Configurer le cache de Nginx

Configurer le cache statique de Nginx

Dans un site WEB, une partie des données sont des fichiers HTML, CSS, JavaScript et images.
C'est le contenu dit statique car il ne bouge pas ou très peu.
Ce contenu est facile à cacher puisqu'il ne bouge pas, on le place en mémoire et on vide le cache que quand il est modifié.
De ce fait, on peut aussi demander à le cacher du côté client, c'est à dire dans le navigateur WEB.
Cela évite de re-télécharger à chaque consultation du site internet, pris sur le disque, on gagne en temps de chargement de la page.

La configuration du cache statique de Nginx s'effectue dans les blocs http.
Voici un exemple pour cacher les images, polices et Javascript en visant des extensions de fichiers spécifique.
Cela nécessite d'envoyer un header Cache-Control pour que le navigateur WEB reçoit l'information de cacher le contenu.

location ~* \.(svg|gif|otf|jpg|jpeg|png|css|js|ttf)$ {
  add_header Cache-Control public; # En-tête de contrôle de cache pour les navigateurs
  add_header Pragma public; # En-tête de contrôle de cache pour les navigateurs
  add_header Vary Accept-Encoding; # En-tête de contrôle de cache pour les navigateurs
  expires max; # Stockez les fichiers statiques aussi longtemps que possible, cela prendra plus d'un an.
}

La directive expires permet d'indiquer combien de temps le navigateur doit garder le contenu en cache.
Par exemple pour 30d ou 24h :

OptionsDescription
offCette valeur désactive la logique des en-têtes de cache Nginx. Rien ne sera ajouté, et plus important encore, les en-têtes existants reçus des amonts ne seront pas modifiés.
epochIl s'agit d'une valeur artificielle utilisée pour purger une ressource stockée de tous les caches en définissant l'en-tête Expires sur “1 January, 1970 00:00:01 GMT”.
maxDemande cacher pour 10 ans. Cela signifie essentiellement que les réponses HTTP sont garanties de ne jamais changer, les clients sont donc libres de ne jamais demander deux fois la même chose et peuvent utiliser leurs propres valeurs stockées.
Specific timeUne valeur de temps spécifique réelle signifie un délai d'expiration à partir du moment de la demande respective. Par exemple, expire 10w ; Une valeur négative pour cette directive émettra un en-tête spécial Cache-Control : no-cache.
“modified” specific timeSi vous ajoutez le mot-clé modified avant la valeur de l'heure, alors le moment d'expiration sera calculé par rapport à l'heure de modification du fichier qui est servi.
“@” specific timeUne heure avec un préfixe @ spécifie une expiration absolue de l'heure du jour.
Cela devrait être inférieur à 24 heures. Par exemple, Expire @17h ;.
Les options de la directive expire

Pour désactiver le cache statique dans Nginx, réglez expires de cette manière :

expires -1;

Ou encore if_modified_since :

if_modified_since off; # Spécifie comment comparer l'heure de modification d'une réponse avec l'heure dans le champ d'en-tête de requête plutôt pour les moteurs de recherche
        expires off;
        etag off;

Configurer le fastcgi_cache ou proxy_cache de Nginx

Ce cache est utilisé lorsque Nginx agit comme proxy entre le client et le backend.
Ce backend peut-être une serveur PHP ou un autre serveur Nginx.
Les directives diffèrent alors.

Configuration générale

La déclaration de cache se scinde en deux parties.
Une directive proxy_cache_path pour créer la zone de cache.
Puis des directives pour appeler cette dernière ou modifier la configuration.

proxy_cache_path /path/to/cache levels=1:2 keys_zone=my_cache:10m max_size=10g 
                 inactive=60m use_temp_path=off;
proxy_cache_key "$host$request_uri$cookie_user";

server {
    # ...
    location / {
        proxy_cache my_cache;
        proxy_pass http://my_upstream;
    }
}

En réalité, il existe plusieurs protocoles de cache dont la configuration est assez identique :

  • fastcgi_cache est lié au protocole backend FastCGI. Il met en cache la sortie des backends connectés FastCGI utilisées par des applications par exemple PHP-FPM.
  • proxy_cache est lié aux backends qui utilisent HTTP comme protocole backend, et il met en cache la sortie des backends connectés HTTP. On l'utilise pour du reverse-proxy ou load balancing

Notez que l'on peut mélanger sans problème ces protocoles.

La directive proxy_cache_path ou fastcgi_cache_path

Voici un exemple de configuration :

Les deux se déclarent de la même manière.
Voici les principales options :

  • level définit une hiérarchie de répertoires à deux niveaux sous /path/to/cache/. Le fait d'avoir un grand nombre de fichiers dans un seul répertoire peut ralentir l'accès aux fichiers, c'est pourquoi nous recommandons une hiérarchie de répertoires à deux niveaux pour la plupart des déploiements. Si le paramètre level n'est pas inclus, NGINX place tous les fichiers dans le même répertoire.
  • keys_zone configure une zone de mémoire partagée pour stocker les clés de cache et les métadonnées telles que les minuteurs d'utilisation. Avoir une copie des clés en mémoire permet à NGINX de déterminer rapidement si une demande est un HIT ou un MISS sans avoir à aller sur le disque, ce qui accélère considérablement la vérification. Une zone de 1 Mo peut stocker des données pour environ 8 000 clés, de sorte que la zone de 10 Mo configurée dans l'exemple peut stocker des données pour environ 80 000 clés.
  • max_size définit la limite supérieure de la taille du cache (à 10 gigaoctets dans cet exemple). C'est facultatif; ne pas spécifier de valeur permet au cache de croître pour utiliser tout l'espace disque disponible. Lorsque la taille du cache atteint la limite, un processus appelé gestionnaire de cache supprime les fichiers les moins récemment utilisés pour ramener la taille du cache sous la limite.
  • inactif spécifie combien de temps un élément peut rester dans le cache sans y accéder. Dans cet exemple, un fichier qui n'a pas été demandé depuis 60 minutes est automatiquement supprimé du cache par le processus du gestionnaire de cache, qu'il ait ou non expiré. La valeur par défaut est de 10 minutes (10 m). Le contenu inactif diffère du contenu expiré. NGINX ne supprime pas automatiquement le contenu qui a expiré tel que défini par un en-tête de contrôle de cache (Cache-Control:max-age=120 par exemple). Le contenu expiré (obsolète) est supprimé uniquement lorsqu'il n'a pas été consulté pendant la durée spécifiée par inactif. Lors de l'accès à un contenu expiré, NGINX l'actualise à partir du serveur d'origine et réinitialise le compteur d'inactivité.

proxy_cache_key définit une clé pour la mise en cache, par exemple pour forcer la prise en compte de paramètres dans l'URL.

proxy_cache_key "$host$request_uri $cookie_user";

Déclarer le cache dans la directive server

Ensuite, on appelle le cache à tout moment dans la directive server comme montré précédemment.

server {
    # ...
    location / {
        proxy_cache my_cache;
        proxy_pass http://my_upstream;
    }
}

Il est tout à fait possible de créer plusieurs zones de cache avec des paramètres différents.

proxy_cache_path /var/lib/nginx/http1 levels=1:2 keys_zone=php:10m max_size=5g 
                 inactive=60m use_temp_path=off;
proxy_cache_path /var/lib/nginx/http2 levels=1:2 keys_zone=php:10m max_size=10g 
                 inactive=10m use_temp_path=off;

server {
    # ...
    location / {
        proxy_cache http1;
        proxy_pass http://my_upstream;
    }


location /private {
        proxy_cache http2;
        proxy_pass http://my_upstream;
    }
}

fastcgi_cache

fastcgi_cache fonctionne de la même manière que proxy_cache.
Voici un exemple de configuration.

fastcgi_cache_path /var/lib/nginx/php levels=1:2 keys_zone=php:500m inactive=60m max_size=10G;

server {
   # ...

   location ~ \.php {
      fastcgi_cache php;
      fastcgi_cache_revalidate on;
      fastcgi_pass unix:/run/php/php7.3-fpm.sock;
      fastcgi_index index.php;
   }
}

Notez ici que le proxy se fait avec un socket unix mais on peut très bien passer une URL pour attaquer, par exemple pour attaquer PHP-FPM.

fastcgi_pass http://127.0.0.1:9000;

Ignorer le cache sur des pages spécifiques

Lors d'une session, sur des pages d'administrations, on peut vouloir ignorer le cache car cela peut fausser le contenu.
Il est alors possible d'ajouter des excentrions de cache dans des blocs HTTP de nginx.
Pour cela, on définit variable $skip_cache :

  • à 1 : le cache est ignoré
  • à 0 : le cache est actif

Par exemple pour ignorer les pages admin de WordPress ou lorsque l'on est authentifié (un cookie est créé dans ce cas) :

set $skip_cache 0;

if ($request_uri ~* "/wp-admin/|/xmlrpc.php|wp-.*.php|/feed/|index.php|sitemap(_index)?.xml") {
	set $skip_cache 1;
}
# Don't use the cache for logged in users or recent commenters
if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_no_cache|wordpress_logged_in") {
	set $skip_cache 1;
}

location ~ \.php$ {
    # Mettre la configuration fastfastcgi_cache
}

Ajouter un en-tête HTTP X-Cache-Status

Vous pouvez configurer un statut du cache dans la réponse de l'en-tête HTTP.
Pour cela, ajoutez cette directive pour ajouter l'en-tête X-Cache-Status :

add_header X-Cache-Status $upstream_cache_status;

Voici les valeurs possibles pour $upstream_cache_status :

  • MISS - La réponse n'a pas été trouvée dans le cache et a donc été récupérée à partir d'un serveur d'origine. La réponse peut alors avoir été mise en cache.
  • BYPASS – La réponse a été récupérée depuis le serveur d'origine au lieu d'être servie depuis le cache car la requête correspondait à une directive proxy_cache_bypass. La réponse peut alors avoir été mise en cache.
  • EXPIRED – L'entrée dans le cache a expiré. La réponse contient du contenu récent du serveur d'origine.
  • STALE – Le contenu est périmé car le serveur d'origine ne répond pas correctement et proxy_cache_use_stale a été configuré.
  • UPDATING – Le contenu est périmé car l'entrée est actuellement mise à jour en réponse à une demande précédente et la mise à jour proxy_cache_use_stale est configurée.
  • REVALIDATED - La directive proxy_cache_revalidate a été activée et NGINX a vérifié que le contenu mis en cache actuel était toujours valide (If-Modified-Since ou If-None-Match).
  • HIT – La réponse contient du contenu valide et frais directement à partir du cache.
Ajouter un en-tête HTTP X-Cache-Status dans Nginx

Les directives cache à connaître

Voici quelques directives de caches supplémentaires utiles à connaître.

proxy_cache_methods permet de définir les méthodes HTTP à mettre en cache.

proxy_cache_methods GET HEAD POST;

proxy_ignore_headers désactive le traitement de certains champs d'en-tête de réponse à partir du serveur proxy.
Cache-Control est un en-tête HTTP utilisé pour spécifier les politiques de mise en cache du navigateur dans les demandes des clients et les réponses du serveur. Les politiques incluent la façon dont une ressource est mise en cache, où elle est mise en cache et son âge maximum avant d'expirer (c'est-à-dire la durée de vie).
Si vous utilisez un CDN, proxy-reverse, le Cache-Control peut-être imposé, vous pouvez alors désirer l'ignorer pour forcer la mise en cache.

proxy_ignore_headers Cache-Control Expires Set-Cookie;

proxy_cache_bypass définit les conditions dans lesquelles la réponse ne sera pas extraite d'un cache. Si au moins une valeur des paramètres de chaîne n'est pas vide et n'est pas égale à « 0 », la réponse ne sera pas extraite du cache :

proxy_cache_bypass $cookie_nocache $arg_nocache$arg_comment;
proxy_cache_bypass $http_pragma    $http_authorization;

La liste des directives de ngx_http_proxy_module

Comment vider le cache Nginx

Il peut arriver que l'on ait besoin de vider le cache Nginx.
Vous pouvez tout simplement vider le dossier sans arrêter le serveur WEB.
Par exemple pour un cache se trouvant dans /var/lib/nginx/http1 :

rm -rf /var/lib/nginx/http1/*

Pour faciliter le vidage du cache, on peut aussi créer une fonction de purge de cache grâce à la directive proxy_cache_purge.

proxy_cache_path /tmp/cache keys_zone=mycache:10m levels=1:2 inactive=60s;

map $request_method $purge_method {
    PURGE 1;
    default 0;
}

server {
    listen 80;
    server_name www.example.com;

    location / {
        proxy_pass http://localhost:8002;
        proxy_cache mycache;

        proxy_cache_purge $purge_method;
    }
}

Ensuite, on envoie une requête contenant un en-tête ou une méthode HTTP personnalisée.
Par exemple avec curl :

curl -X PURGE -D – "http://www.example.com/*"

Optimiser la mise en cache de Nginx

Nous venons de voir la configuration générale de mise en cache sur Nginx.
Mais il existe de nombreuses directives de buffer pour optimiser le cache et ainsi améliorer les performances de vos sites WEB.
Retrouvez ces réglages dans le tutoriel suivant :

Liens

Liens

L’article Configurer le cache de Nginx est apparu en premier sur malekal.com.

Optimiser Nginx pour améliorer la vitesse des sites WEB

7 juillet 2021 à 10:46

Nginx est un serveur Web très rapide, robuste, léger et très performant exécutant au moins 40 % des sites Web les plus fréquentés au monde. En raison de la polyvalence de Nginx, il est également utilisé comme équilibreur de charge, proxy inverse et serveur de cache HTTP.

La meilleure caractéristique de Nginx est sa vitesse qui lui permet de gérer facilement des milliers de connexions simultanées.

Dans ce tutoriel, nous allons illustrer les meilleures façons de régler et d'optimiser le serveur web Nginx.

Optimiser Nginx pour améliorer la vitesse des sites WEB

Optimiser Nginx pour améliorer la vitesse des sites WEB

Optimiser la couche réseau Linux

Linux regorge de réglages pour optimiser le réseau.
On trouve notamment des paramètres qui concernent les connexions et la façon dont elles sont mises en file d'attente.
Cela peut jouer sur les performances lorsque vous avez beaucoup de connexions.
Ces optimisations réseaux de la couche réseau de Linux s'effectue à travers l'utilitaire sysctl.
il faut modifier /etc/systctl.conf pour les rendre permanent.

net.core.somaxconn – Le nombre maximal de connexions pouvant être mises en file d'attente pour acceptation par NGINX. La valeur par défaut est souvent très faible et c'est généralement acceptable car NGINX accepte les connexions très rapidement, mais cela peut valoir la peine de l'augmenter si votre site Web connaît un trafic important. Si des messages d'erreur dans le journal du noyau indiquent que la valeur est trop petite, augmentez-la jusqu'à ce que les erreurs cessent.

Remarque : Si vous définissez cette valeur sur une valeur supérieure à 512, remplacez le paramètre backlog par la directive d'écoute NGINX pour qu'elle corresponde.

net.core.somaxconn = 4096

net.core.netdev_max_backlog – Le taux auquel les paquets sont mis en mémoire tampon par la carte réseau avant d'être transmis au CPU. L'augmentation de la valeur peut améliorer les performances sur les machines avec une grande quantité de bande passante. Vérifiez le journal du noyau pour les erreurs liées à ce paramètre et consultez la documentation de la carte réseau pour obtenir des conseils sur sa modification.

net.core.netdev_max_backlog = 262144
  • sys.fs.file-max – La limite à l'échelle du système pour les descripteurs de fichiers
  • nofile – La limite de descripteur de fichier utilisateur, définie dans le fichier /etc/security/limits.conf

Pour aller plus loin, vous pouvez appliquer ce fichier network-tuning.conf ou ce tutoriel Optimization of linux kernel parameters when using Nginx

Optimiser les réglages server

Les workers

Nginx comme toute application moderne fonctionne avec plusieurs processus.
Un processus maître et des sous processus dit processus de travail ou worker.
Ce sont les processus de travail impliqués dans la tâche de traitement des demandes des clients.
Le nombre de processus de travail se paramètre dans le fichier de configuration.
En général, on le fixe fonction des cœurs du CPU.

Cette directive détermine le nombre de processus à générer dans Nginx peu de temps après la connexion du serveur aux ports. Il est recommandé de définir un processus de travail par cœur de processeur. Élever les processus au-dessus du cœur du processeur ralentira les performances de votre système.

La valeur par défaut des processus de travail est généralement définie sur auto mais on peut le régler manuellement.

  • Vérifiez le nombre de coeur
grep processor /proc/cpuinfo |wc -l
  • Cela peut retourner 4, 8 ou 16.
  • Editez le fichier /etc/nginx/nginx.conf
  • Puis modifiez la directive worker_processes avec le nombre de coeur
worker_processes X;

Ensuite, toujours dans le fichier nginx.conf, vous pouvez optimiser les réglages suivants.

worker_connections : Définit le nombre maximal de connexions simultanées pouvant être ouvertes par un processus de travail.
Il convient de garder à l'esprit que ce nombre inclut toutes les connexions (par exemple, les connexions avec des serveurs proxy, entre autres), pas seulement les connexions avec les clients. Une autre considération est que le nombre réel de connexions simultanées ne peut pas dépasser la limite actuelle du nombre maximum de fichiers ouverts, qui peut être modifié par worker_rlimit_nofile.

Lorsque Nginx effectue un travail gourmand en ressources processeur tel que SSL ou gzipping et que vous disposez de 2 processeurs/cœurs ou plus, vous pouvez définir que worker_processes soit égal au nombre de processeurs ou de cœurs. Appliquez ce calcul : worker_processes*worker_connections = max. no. of clients
Mais si vous servez beaucoup de fichiers statiques et que la taille totale des fichiers est supérieure à la mémoire disponible, vous pouvez augmenter worker_processes pour utiliser pleinement la bande passante du disque.

Si vous servez beaucoup de fichiers statiques et que la taille totale des fichiers est supérieure à la mémoire disponible, vous pouvez augmenter worker_processes pour utiliser pleinement la bande passante du disque.

Enfin deux autres directives worker à personnaliser :

  • worker_rlimit_core : Modifie la limite de la plus grande taille d'un fichier core (RLIMIT_CORE) pour les processus de travail. Utilisé pour augmenter la limite sans redémarrer le processus principal.
  • worker_rlimit_nofile : Modifie la limite du nombre maximal de fichiers ouverts (RLIMIT_NOFILE) pour les processus de travail. Utilisé pour augmenter la limite sans redémarrer le processus principal.
worker_rlimit_nofile 262144;
worker_connections 16384;

sendfile, tcp_nopush et open_file_cache

Puis voici quelques directives à optimiser pour servir du contenu statique.
Ils jouent surtout sur l'ouverture de fichiers.

tcp_nopush : Utilisez la directive tcp_nopush avec la directive sendfile on;. Cela permet à NGINX d'envoyer des en-têtes de réponse HTTP dans un paquet juste après que le bloc de données ait été obtenu par sendfile().

tcp_nopush on;

Par défaut, NGINX gère lui-même la transmission du fichier et copie le fichier dans le tampon avant de l'envoyer. L'activation de la directive sendfile élimine l'étape de copie des données dans le tampon et permet la copie directe des données d'un descripteur de fichier à un autre.
Alternativement, pour éviter qu'une connexion rapide n'occupe entièrement le processus de travail, vous pouvez utiliser la directive sendfile_max_chunk pour limiter la quantité de données transférées en un seul appel sendfile() (dans cet exemple, à 1 Mo) :

sendfile on;
sendfile_max_chunk 1m;

keepalive_requests : Définit le nombre maximal de requêtes pouvant être traitées via une connexion persistante. Une fois le nombre maximal de demandes effectué, la connexion est fermée.
La fermeture périodique des connexions est nécessaire pour libérer les allocations de mémoire par connexion. Par conséquent, l'utilisation d'un nombre maximal de requêtes trop élevé peut entraîner une utilisation excessive de la mémoire et n'est pas recommandée.

open_file_cache : définit un cache sur les informations de fichiers.

keepalive_requests 100;
open_file_cache max=100;

Les directives du module core sont disponible depuis ce lien : Core functionality

Optimiser le cache de Nginx

Le cache de Nginx vous permet d'améliorer la vitesse de chargement des pages de manière significative.
Le serveur WEB va piocher des données dans la RAM ce qui réduit les I/O.
Il existe énormément de tampons (buffer) pour régler le cache et proxy cache.
Cela peut fortement baisser le Time To First Byte (TTFB) de votre site WEB.
Suivez ce tutoriel très complet :

Optimiser les timeouts

Dans l'étape suivant, on peut jouer sur les timeouts pour gagner en performances.

client_body_timeout :
Le temps d'attente du serveur Nginx pour que le corps du client soit envoyé après une requête. Si client_body n'est pas envoyé, le serveur finira par afficher 408 Error (ou Request Time Out).

client_header_timeout :
Le temps d'attente du serveur Nginx pour que l'en-tête client soit envoyé après une requête. Si le client_header n'a pas été envoyé, le serveur finira par afficher 408 Error (ou Request Time Out).

Keepalive_timeout :
C'est le temps pris pour la connexion keep-alive avec les clients, après quoi le serveur met fin à la connexion.

send_timeout :
C'est le temps d'envoi de la réponse au client concerné. En cas d'échec de ce processus, le serveur Nginx met fin à la connexion.

client_body_timeout 12;
client_header_timeout 12;
keepalive_timeout 15;
send_timeout 10;

Activer le support HTTP/2 ou QUIC+HTTP/3

server {
    listen 443 ssl;              # TCP listener for HTTP/1.1
    listen 443 http3 reuseport;  # UDP listener for QUIC+HTTP/3

    ssl_protocols       TLSv1.3; # QUIC requires TLS 1.3
    ssl_certificate     ssl/www.example.com.crt;
    ssl_certificate_key ssl/www.example.com.key;

    add_header Alt-Svc 'h3=":443"';   # Advertise that HTTP/3 is available
    add_header QUIC-Status $quic;     # Sent when QUIC was used
}

Introducing a Technology Preview of NGINX Support for QUIC and HTTP/3

Optimiser le SSL

Votre site WEB est probablement en HTTPS avec un certificat SSL.
Là aussi on peut aussi appliquer quelques configurations pour améliorer les temps de réponses.

  • SSL : utilisez sur TLS et désactivez SSL (SSL est assez ancien et obsolète et présente de nombreuses vulnérabilités). Optimisez les suites de chiffrement avec ssl_ciphers, car elles sont au cœur de TLS.
  • Cache de session : la création d'un cache de paramètres de connexion TLS réduit le nombre d'établissements de liaison et peut ainsi améliorer les performances de votre application. La mise en cache est configurée à l'aide de la directive ssl_session_cache.
  • Tickets de session : les tickets de session sont une alternative au cache de session. En cas de cache de session, les informations sur la session sont stockées sur le serveur.
  • OSCP : Pour avoir une connexion sécurisée à un serveur, le client doit vérifier le certificat que le serveur a présenté. Afin de vérifier que le certificat n'est pas révoqué, le client (navigateur) contactera l'émetteur du certificat. Cela ajoute un peu plus de temps à l'initialisation de la connexion (et donc au temps de chargement de notre page).

Utilisez ces directives dans votre configuration NGINX et vous êtes prêt pour l'optimisation SSL.

http {

...  
   # SSL Settings
   ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
   ssl_prefer_server_ciphers on;
   ssl_ciphers ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GC$
   
   # Optimize session cache
   ssl_session_cache shared:SSL:50m;
   ssl_session_timeout 1d;
   
   # Enable session tickets
   ssl_session_tickets on;
   
   # OCSP Stapling
   ssl_stapling on;
   ssl_stapling_verify on;
   resolver 8.8.8.8 8.8.4.4 208.67.222.222 208.67.220.220 valid=60s;
   resolver_timeout 2s;
...
}

L'option de configuration Nginx ssl_buffer_size définit la taille du tampon utilisé pour l'envoi de données via HTTPS
Par défaut, la mémoire tampon est définie sur 16 Ko, ce qui est une approche unique axée sur les grandes réponses. Cependant, pour minimiser le TTFB (Time To First Byte), il est souvent préférable d'utiliser une valeur plus petite, par exemple :

ssl_buffer_size 4k;

Optimiser les journaux et logs

L'écriture des journaux sur le disque est important pour suivre l'activité du serveur WEB.
Toutefois là aussi cela génère des accès disques.
Pour limiter ces derniers et libérer des ressources, vous pouvez appliquer ces recommandations.

Désactiver les journaux avec access_log off; pour les types de fichiers statiques.
Par exemple :

location ~* ^.+\.(xml|ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|css|rss|atom|js|jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi|wav|bmp|rtf|woff2|webp)$ {
                access_log off;
                log_not_found off;
                add_header Cache-Control "public, no-transform";
                expires 365d;
        }

Toujours pour minimiser les accès disques vous pouvez activez la mise en mémoire tampon des journaux d'accès. Cela permet à Nginx de mettre en mémoire tampon une série d'entrées de journal et de les écrire simultanément dans le fichier journal au lieu d'effectuer une opération d'écriture différente pour chaque entrée de journal.

access_log /var/log/nginx/access.log main buffer=16k

Liens

Liens

L’article Optimiser Nginx pour améliorer la vitesse des sites WEB est apparu en premier sur malekal.com.

Masquer l’adresse IP de l’expéditeur dans Postfix

3 juillet 2021 à 13:01

Par défaut, Postfix ajoute l'adresse IP de l'expéditeur du mail dans les en-tête de mail.
Cela cause des problèmes de confidentialités puisque le destinataire peut récupérer l'adresse IP du contact.
De même, si vous utilisez un serveur Postfix comme relai mail, l'adresse IP du serveur WEB source s'inscrit dans le header du mail.
Cela peut poser des problèmes de sécurité, si le serveur Web est caché derrière un CDN comme Cloudflare car on peut récupérer l'adresse IP réelle du serveur WEB.

Dans ce tutoriel, je vous guide pour masquer et supprimer l'adresse IP de l'expéditeur dans Postfix.

Masquer l'adresse IP de l'expéditeur dans Postfix

Masquer l'adresse IP de l'expéditeur dans Postfix

Pour supprimer l'adresse IP dans les en-tête de mail sur Postfix, il faut tout d'abord installer l'extension PCRE.
Cela permet de spécifier des expressions régulières avec la notation de style PERL dans postfix.

  • Sur une distribution de type Debian, avec APT :
apt install postfix-pcre
  • Puis éditez le fichier /etc/postfix/dynamicmaps.cf pour ajouter la ligne :
pcre /usr/lib/postfix/postfix-pcre.so dict_pcre_open
  • Ensuite éditez le fichier de configuration Postfix /etc/postfix/master.cf
  • Remplacez la ligne cleanup par celle-ci
cleanup unix  n       -       y       -       0       cleanup
  -o header_checks=pcre:/etc/postfix/header_checks_submission
  • Ensuite créez le fichier /etc/postfix/header_checks_submission et inscrivez les lignes suivantes :
/^Received: .*/     IGNORE
/^X-Originating-IP:/    IGNORE
  • Enfin relancez le service postfix :
/etc/init.d/postfix restart

Dans cet exemple d'en-tête de message, on voit une première ligne Received by avec une adresse IP commençant par 51.

En-tête du message avec l'adresse IP du client

Après avoir suivi les instructions, Postfix la masque et la supprime, il ne reste plus que le relai du serveur Postfix qui s'affiche en Received.

En-tête du message avec l'adresse IP du client supprimé

L’article Masquer l’adresse IP de l’expéditeur dans Postfix est apparu en premier sur malekal.com.

Installer et configurer Postfix avec SPF + DKIM + DMARC

20 juin 2017 à 15:04

Postfix est serveur mail (MTA) très efficace et populaire et disponible sur la plupart des distributions Linux (Ubuntu, Debian, CentOS, Redhat ...).
Dans ce tutoriel, nous allons voir comment configurer Postfix avec les normes et technologiques : Sender Policy Framework (SPF), DKIM (DomainKeys Identified Mail) et DMARC.

Vous trouverez toutes les explications pour la mise en place de SPF et DKIM sur Postfix avec les fichiers de configuration.
En fin du tutoriel, des aides pour tester l'envoie de mail et vérifier que votre serveur de mail répond bien à ces spécifications.

Installer et configurer Postfix avec SPF + DKIM + DMARC

Introduction

La sécurisation des serveurs de mails (MTA) et la lutte contre l'usurpation d'email (spoofing en anglais), le phishing et SPAM n'est pas forcément chose facile.
Une des problématiques étant que le protocole Simple Mail Transfer Protocol (SMTP) utilisé pour le transfert du courrier électronique sur Internet ne prévoit pas de mécanisme de vérification de l'expéditeur.
C'est-à-dire qu'il est facile d'envoyer un courrier avec une adresse d'expéditeur factice, voire usurpée.
Quelques liens du site autour de ces problématiques :

Afin de limiter ces problèmes, des normes sont apparues pour tenter de limiter ces usurpations.
Quelques rappels :

  • SPF (Sender Policy Framework) : Définit les domaines ou IP autorisés à envoyer des mails dans la déclaration DNS du domaine. Cela vise à protéger contre l'usurpation d'identité et le SPAM
  • DKIM (DomainKeys Identified Mail) : ajoute une signature cryptographique à l’en-tête de chaque message envoyé afin de prouver que votre serveur SMTP est bien l'émetteur des emails. Là aussi il s'agit de protéger contre l'usurpation d'identité
  • DMARC (Domain-based Message Authentication, Reporting and Conformance) : Définit une politique à appliquer sur les emails reçus

Installation et configuration Postfix avec SPF + DKIM

SPF : Faire ses déclarations DNS

On commence par effectuer ses déclarations DNS SPF.
Pour cela, ouvrez l'interface de votre fournisseur DNS.
Vous pouvez vous en inspirer pour effectuer votre déclaration SPF.

Ceci indique que seul le serveur 1.1.1.1 peut envoyer des emails pour ce domaine :

@ 10800 IN TXT "v=spf1 ip4:1.1.1.1 ~all"

Il est aussi possible de déclarer un reverse DNS :

@ 10800 IN TXT "v=spf1 ptr:monreverse.mon_domaine.fr ~all"

Ceci indique que tous les serveurs ayant un “reverse” se terminant par malekal.com peuvent envoyer les emails de ce domaine:

@ 10800 IN TXT "v=spf1 ptr:malekal.com ~all"

ici seulement le serveur 94.23.44.69 peut envoyer des mails

@ 10800 IN TXT "v=spf1 ip4:94.23.44.69 ~all"

Configurer OpenDKIM

On commence par installer le package opendkim, le package spamass-milter est nécessaire si vous utilisez spamassassin.

 apt-get install opendkim opendkim-tools spamass-milter

Si vous utilisez clamav, il faut installer le packageclamav-milter (non testé)

Éditez le fichier /etc/opendkim.conf à la fin, ajoutez les éléments suivants :

AutoRestart             Yes
AutoRestartRate         10/1h
UMask                   002
Syslog                  yes
SyslogSuccess           Yes
LogWhy                  Yes

Canonicalization        relaxed/simple

ExternalIgnoreList      refile:/etc/opendkim/TrustedHosts
InternalHosts           refile:/etc/opendkim/TrustedHosts
KeyTable                refile:/etc/opendkim/KeyTable
SigningTable            refile:/etc/opendkim/SigningTable

Mode                    sv
PidFile                 /var/run/opendkim/opendkim.pid
SignatureAlgorithm      rsa-sha256

UserID                  opendkim:opendkim

Socket                  inet:[email protected]
  • AutoRestart: Redémarre le filtre en cas de plantage.
  • AutoRestartRate: Indique le ratio de redémarrage minimum et maximum. Si le nombre de redémarrage est plus rapide que ce ratio, ce dernier va être arreté.
  • UMask: indique les permissions et ID utilisateur/groupe.
  • Syslog, SyslogSuccess, *LogWhy: activé les log syslog
  • Canonicalization: méthode canonical de signature des messages,
    • simple : autorise aucune modification
    • relaxed : autorise des modificiations mineures comme changer les espaces.
    • relaxed/simple : L'en-tête du mail utilisera la méthode relaxed et le corps du message utilisera la méthode simple.
  • ExternalIgnoreList: la liste des des hôtes par lequel les mails peuvent passer sans signatures.
  • InternalHosts: liste des hôtes à ne pas vérifier et signer : signature sans vérification.
  • KeyTable: Le chemin des tables de clés de signatures.
  • SigningTable: Liste des tables de signatures pour lequels seront basés les champs from des mails.
  • Mode: declares operating modes; in this case the milter acts as a signer (s) and a verifier (v)
  • PidFile: Le fichier PID (process identification number)
  • SignatureAlgorithm:  indique l'algorithme de signatures à utiliser
  • UserID: Le UserID du processus opendkim
  • Socket: Le socket d'écoute de opendkim. Postfix va envoyer les messages à opendkim pour les vérification et signatures à travers ce socket.

A noter que vous pouvez déclarer un serveur DNS avec nameservers dans le fichier de configuration opendkim autre que celui de /etc/resolv.conf si vous filtrez certains résolutions DNS.

Editez /etc/default/opendkim

Ajoutez à la fin :

smtpd_milters = unix:/spamass/spamass.sock, inet:localhost:12301
non_smtpd_milters = unix:/spamass/spamass.sock, inet:localhost:12301

Si vous utilisez clamav et avez installé clamav-milter (non testé), cela donne :

smtpd_milters = unix:/spamass/spamass.sock, unix:/clamav/clamav-milter.ctl, inet:localhost:12301
non_smtpd_milters = unix:/spamass/spamass.sock, unix:/clamav/clamav-milter.ctl, inet:localhost:12301

On créé les dossiers suivants :

mkdir /etc/opendkim
mkdir /etc/opendkim/keys

Éditez le fichier :

/etc/opendkim/TrustedHosts

Il s'agit ici de déclarer les zones de confiances, modifiez selon votre classe d'IP et domaines.
Vous pouvez utiliser les wildcards, si vous désirez déclarer des sous-domaines

127.0.0.1
localhost
192.168.0.1/24
*.malekal.com

Éditez le fichier /etc/opendkim/KeyTable pour y insérer la ligne suivante
Il s'agit de la déclaration des clés par domaine avec le selector.
Par défaut, opendkim utilise le selector mail.
Modifiez le domaine ci-dessous, ajoutez d'autres domaines, si vous êtes en multi-domaines

mail._domainkey.malekal.com malekal.com:mail:/etc/opendkim/keys/malekal.com/mail.private

La table de signature dans le fichier : /etc/opendkim/SigningTable
Là aussi, modifiez et ajoutez les domaines selon votre configuration.

*@malekal.com mail._domainkey.malekal.com

Si vous utilisez spamassassin et vous avez installé spamass-milter.
Modifiez le paramètre OPTIONS du fichier /etc/default/spamass-milter

OPTIONS="-u spamass-milter -i 127.0.0.1 -m -I -- --socket=/var/run/spamassassin/spamd.sock"

Génération des clés privées et publiques

cd /etc/opendkim/keys
mkdir malekal.com
cd malekal.com

puis on génère les clés :

opendkim-genkey -s mail -d malekal.com
  • -s indique le sélecteur, ici dans notre cas il s'agit de mail
  • -d le domaine,

Cette commande créé deux fichiers :

  • mail.private est votre clé privée
  • mail.txt contient la clé publique

puis on attribue le bon utilisateur et groupe au fichier :

chown opendkim:opendkim mail.private

Ajouter les clés publics au DNS

On récupère la clé publique :

cat mail.txt

La clé publique se trouve dans le paramètre p.
On récupère l'entrée mail._domainkey correspondant à la table du fichier /etc/opendkim/KeyTable

mail._domainkey IN      TXT     ( "v=DKIM1; k=rsa; "
          "p=lacleprubliquequiestlongue" )  ; ----- DKIM key mail for malekal.com

La clé publique est à récupérer afin de la placer dans la déclaration DNS.
Cette déclaration DNS est de type TXT, elle est de la forme :

mail._domainkey 10800 IN TXT "v=DKIM1; k=rsa; p=lacleprubliquequiestlongue"

On redémarre les services :

service postfix restart
service spamass-milter restart
service opendkim restart

Installer clamav et Spamassassin

Pour installer un filtrage antivirus et Spam sur votre passerelle SMTP Postfix, cela se passe sur ces tutoriels :

Tester l'envoi de mail

Voici un exemple de déclaration DNS SPF et DKIM sur les serveurs Gandi :

Il faut attendre quelques heures que les modifications DNS se propagent.

Test et vérification de l'envoi de mails

Vérifier les entrées DNS de votre serveur mail

Pour vérifier les entrées DNS,
Sur Windows, vous pouvez la commande nslookup

nslookup
> set type=TXT
> malekal.com
Test et vérification de l'envoi de mails

Sur GNU/Linux, vous pouvez utiliser la commande dig afin de vérifier l'entrée spf.

dig TXT malekal.com
Test et vérification de l'envoi de mails

Voici la commande à utiliser pour vérifier l'entrée DKIM avec le selector mail.

dig mail._domainkey.malekal.com TXT

On peut utiliser aussi ce site qui vérifie aussi le contenu de la clé publique.

Pour les tests emails, de malekal.com vers une adresse gmail.com
Lorsqu'aucune entrée SPF n'est déclarée, le serveur gmail "devine" la règle SPF à appliquer "best guess record domain for"

Authentication-Results: mx.google.com;
spf=pass (google.com: best guess record for domain of [email protected] designates 94.23.44.69 as permitted sender) [email protected]
Test et vérification de l'envoi de mails

avec une déclaration SPF, la vérification est en succès :

Authentication-Results: mx.google.com;
spf=pass (google.com: domain of [email protected] designates 94.23.44.69 as permitted sender) [email protected]
Test et vérification de l'envoi de mails

Côté DKIM,

nslookup
> set type=txt
> mail._domainkey.malekal.com
Test et vérification de l'envoi de mails

on récupère un en-tête et on y retrouve la signature DKIM avec les informations déclarées :

  • -d domaine
  • -s le sélecteur
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=malekal.com; s=mail; t=1497960309; bh=xHOSDWRzKq/MzUni/4wNm2H933+iN2Z7+9Lq3JdxPvA=; h=To:Subject:Date:From:From; b=xxxx/code>

Tester l'envoie de mail

Côté Gmail, on obtient le dkim=pass et spf=pass

Test et vérification de l'envoi de mails

Vous pouvez aussi vérifier les entrées DNS avec le service mxtoolbox : http://mxtoolbox.com/

Test et vérification de l'envoi de mails

Le site mail-tester.com permet aussi de vérifier l'envoi de mail (surtout pour des mailling).
Rendez-vous sur le site https://www.mail-tester.com/
Récupérer l'adresse email, cliquez sur vérifier votre score
Envoyez un mail sur l'adresse email indiquée.

Test et vérification de l'envoi de mails

On note et des commentaire sont attribués à la configuration de votre serveur mail.

Test et vérification de l'envoi de mails

Voici un log de réception avec SPF et DKIM en fonction :

Dec 9 13:13:20 www postfix/smtpd[23402]: connect from mail-oi1-f171.google.com[209.85.167.171]
Dec 9 13:13:20 www policyd-spf[23471]: None; identity=helo; client-ip=209.85.167.171; helo=mail-oi1-f171.google.com; [email protected]; [email protected]
Dec 9 13:13:20 www policyd-spf[23471]: Pass; identity=mailfrom; client-ip=209.85.167.171; helo=mail-oi1-f171.google.com; [email protected]; [email protected]
Dec 9 13:13:20 www postfix/smtpd[23402]: B2309102668: client=mail-oi1-f171.google.com[209.85.167.171]
Dec 9 13:13:20 www postfix/cleanup[23472]: B2309102668: message-id=<[email protected]om>
Dec 9 13:13:20 www opendkim[23367]: B2309102668: mail-oi1-f171.google.com [209.85.167.171] not internal
Dec 9 13:13:20 www opendkim[23367]: B2309102668: not authenticated
Dec 9 13:13:21 www opendkim[23367]: B2309102668: DKIM verification successful
Dec 9 13:13:21 www opendkim[23367]: B2309102668: s=20161025 d=gmail.com SSL
Dec 9 13:13:21 www postfix/qmgr[19745]: B2309102668: from=<[email protected]>, size=2758, nrcpt=1 (queue active)
Dec 9 13:13:21 www spamd[10336]: spamd: connection from ::1 [::1]:44134 to port 783, fd 5
Dec 9 13:13:21 www spamd[10336]: spamd: processing message <[email protected]om> for spamassassin:1004
Dec 9 13:13:21 www postfix/smtpd[23402]: disconnect from mail-oi1-f171.google.com[209.85.167.171]
Dec 9 13:13:21 www spamd[10336]: util: refusing to untaint suspicious path: "/${SAHOME}"
Dec 9 13:13:21 www spamd[23476]: util: setuid: ruid=1004 euid=1004 rgid=1004 33 1004 1004 egid=1004 33 1004 1004
Dec 9 13:13:21 www spamd[10336]: spamd: clean message (-1.9/5.0) for spamassassin:1004 in 0.5 seconds, 2855 bytes.
Dec 9 13:13:21 www spamd[10336]: spamd: result: . -1 - BAYES_00,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_MSPIKE_H2,SPF_PASS,TVD_SPACE_RATIO scantime=0.5,size=2855,user=spamassassin,uid=1004,required_score=5.0,rhost=::1,raddr=::1,rport=44134,mid=<[email protected]om>,bayes=0.000000,autolearn=ham autolearn_force=no
Dec 9 13:13:21 www postfix/pickup[19744]: 94001105C23: uid=1004 from=<[email protected]>
Dec 9 13:13:21 www postfix/pipe[23474]: B2309102668: to=<[email protected]>, relay=spamassassin, delay=1.1, delays=0.53/0/0/0.52, dsn=2.0.0, status=sent (delivered via spamassassin service)
Dec 9 13:13:21 www postfix/qmgr[19745]: B2309102668: removed
Dec 9 13:13:21 www postfix/cleanup[23472]: 94001105C23: message-id=<[email protected]om>
Dec 9 13:13:21 www opendkim[23367]: 94001105C23: no signing table match for '[email protected]'
Dec 9 13:13:21 www opendkim[23367]: 94001105C23: DKIM verification successful
Dec 9 13:13:21 www opendkim[23367]: 94001105C23: s=20161025 d=gmail.com SSL
Dec 9 13:13:21 www postfix/qmgr[19745]: 94001105C23: from=<[email protected]>, size=3337, nrcpt=1 (queue active)
Dec 9 13:13:21 www spamd[10333]: prefork: child states: II
Dec 9 13:13:21 www postfix/local[23480]: 94001105C23: to=<[email protected]>, orig_to=<[email protected]>, relay=local, delay=0.06, delays=0.05/0.01/0/0, dsn=2.0.0, status=sent (delivered to command: /usr/bin/procmail -Y -a $DOMAIN)
Dec 9 13:13:21 www postfix/qmgr[19745]: 94001105C23: removed

Enfin cet autre site permet de tester le contenu des mails.

Test et vérification de l'envoi de mails

Configurer DMARC sur Postfix

DMARC, qui vient de l'anglais Domain-based Message Authentication, Reporting and Conformance est un standard qui vient se greffer à SPF et DKIM

DMARC standardise la façon dont les destinataires (au sens des MTA destinataires) réalisent l'authentification des e-mails en utilisant les mécanismes de Sender Policy Framework et de DomainKeys Identified Mail. Cela signifie que l'expéditeur (au sens d'un MTA expéditeur) recevra les résultats de l'authentification de ses messages par AOL, Gmail, Hotmail, Yahoo! et tout autre destinataire qui implémente DMARC.

Une politique DMARC autorise l'expéditeur à indiquer que ses e-mails sont protégés par SPF et/ou DKIM et dit au destinataire que faire si ces méthodes d'authentification échouent (ex : rejeter tous les emails sans DKIM et prévenir une adresse email). DMARC supprime les conjectures que le destinataire doit faire à propos de la façon de gérer ces messages en échec, limitant ou supprimant l'exposition de l'utilisateur aux messages potentiellement frauduleux ou dangereux. DMARC fournit également un moyen pour les destinataires de rendre compte à l'émetteur du message qu'il a réussi ou échoué l'évaluation DMARC.

v=DMARC1;p=quarantine;pct=100;rua=mailto:[email protected];ruf=mailto:[email protected];adkim=s;aspf=r
ParamètreDescription
vVersion du protocole
pctPourcentage de messages à filtrer
rufDestinataire du rapport forensique
ruaDestinataire du rapport agrégé
pProcédure avec le domaine principal
spProcédure avec le sous-domaine
adkimRègle pour le DKIM
aspfRègle pour le SPF

Source : https://fr.wikipedia.org/wiki/DMARC

Sur Debian, il faut installer le paquet opendmarc

apt-get install opendmarc

puis dans le fichier /etc/opendmarc.conf, on peut remplacer le socket.

Socket inet:[email protected]

Enfin on peut ajouter le contenu dans /etc/postfix/main.cf comme ceci.

smtpd_milters = inet:localhost:12301 inet:localhost:54321
non_smtpd_milters = inet:localhost:12301 inet:localhost:54321

Enfin relancez les daemon postfix et opendmarc.

Générer et configurer un certificat SSL sur Postfix

Pour chiffrer vos emails avec un certificat SSL sur Postfix, suivez ce tutoriel :

Liens

L’article Installer et configurer Postfix avec SPF + DKIM + DMARC est apparu en premier sur malekal.com.

File Browser, LE gestionnaire de fichiers gratuit pour votre serveur…

10 juin 2021 à 07:00
Par : EVOTk

File BrowserParcourir les fichiers d’un serveur (cloud) avec une jolie interface graphique, c’est bien plus agréable que les lignes de commande. C’est pour cela que je vais vous présenter File Browser. Ce gestionnaire de fichiers gratuit est bien plus qu’une simple interface graphique. Explications… File Browser Tout d’abord, commençons par quelques images provenant du site officiel. Elles permettent une première approche de l’interface. Comme vous pouvez le constater, elle est très épurée et facile à prendre en main. Cerise sur le […]

Cet article File Browser, LE gestionnaire de fichiers gratuit pour votre serveur… est apparu en premier sur Cachem

❌