Pour créer un email, on peut utiliser la commande exim, avec l’option -v pour voir l’échange entre le client du mail, exim dans le cas présent, et le serveur SMTP distant, aspmx.l.google.com, pour le domaine tohero.fr

Lorsqu’on lance le programme exim comme ci-dessous, on se retrouve dans le dialogue SMTP directement. Pour définir le sujet du mail, il faut taper « Subject: mon sujet » et un retour à la ligne, puis saisir le message. Pour terminer la saisie du message, il faut taper . et retour à la ligne ou Ctrl+D

arditi-host3:~# exim -v aa2@tohero.fr
Subject: test

Bonjour
.
LOG: MAIN
  <= alain@arditi.fr U=root P=local S=332
delivering 1rvBpA-0002z1-5b
R: dnslookup for aa2@tohero.fr
T: remote_smtp for aa2@tohero.fr
Connecting to aspmx.l.google.com [142.251.168.27]:25 ... connected
  SMTP<< 220 mx.google.com ESMTP v3-20020adfebc3000000b003460665686fsi1845359wrn.1051 - gsmtp
  SMTP>> EHLO arditi-host3.arditi.net
  SMTP<< 250-mx.google.com at your service, [51.159.28.23]
         250-SIZE 157286400
         250-8BITMIME
         250-STARTTLS
         250-ENHANCEDSTATUSCODES
         250-PIPELINING
         250-CHUNKING
         250 SMTPUTF8
  SMTP>> STARTTLS
  SMTP<< 220 2.0.0 Ready to start TLS
  SMTP>> EHLO arditi-host3.arditi.net
  SMTP<< 250-mx.google.com at your service, [51.159.28.23]
         250-SIZE 157286400
         250-8BITMIME
         250-ENHANCEDSTATUSCODES
         250-PIPELINING
         250-CHUNKING
         250 SMTPUTF8
  SMTP>> MAIL FROM:<alain@arditi.fr> SIZE=1365
  SMTP>> RCPT TO:<aa2@tohero.fr>
         will write message using CHUNKING
  SMTP>> BDAT 342 LAST
  SMTP<< 250 2.1.0 OK v3-20020adfebc3000000b003460665686fsi1845359wrn.1051 - gsmtp
  SMTP<< 250 2.1.5 OK v3-20020adfebc3000000b003460665686fsi1845359wrn.1051 - gsmtp
  SMTP<< 250 2.0.0 OK v3-20020adfebc3000000b003460665686fsi1845359wrn.1051 - gsmtp
  SMTP>> QUIT
  SMTP(close)>>
LOG: MAIN
  => aa2@tohero.fr R=dnslookup T=remote_smtp H=aspmx.l.google.com [142.251.168.27] X=TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256 CV=yes DN="CN=mx.google.com" K C="250 2.0.0 OK v3-20020adfebc3000000b003460665686fsi1845359wrn.1051 - gsmtp"
LOG: MAIN
  Completed

arditi-host3:~#

Le détail de l’échange SMTP nous permet de voir exactement comment l’email est envoyé. Les lignes

SMTP>> indiquent les messages émis par le serveur local
SMTP<< indiquent les messages reçus du serveur distant

On peut voir qui est le destinataire « RCPT TO: », qui est l’émetteur « MAIL FROM: », qui est le serveur SMTP distant: « Connecting to aspmx.l.google.com », comment se présente le serveur local: « EHLO arditi-host3.arditi.net ». Le message « completed » indique que le mail a été envoyé au serveur SMTP distant.

Les lignes « LOG: MAIN » sont les lignes qu’on retrouve dans le fichier de log d’Exim /var/log/exim4/mainlog qui contient le détail de tous les envois/réception d’email

arditi-host3:~# tail /var/log/exim4/mainlog
2024-04-12 09:31:18 Start queue run: pid=7666
2024-04-12 09:31:18 End queue run: pid=7666
2024-04-12 09:58:54 1rvBo6-0002yh-50 <= alain@arditi.fr U=root P=local S=333
2024-04-12 09:58:54 1rvBo6-0002yh-50 => aa2@tohero.fr R=dnslookup T=remote_smtp H=aspmx.l.google.com [142.251.168.27] X=TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256 CV=yes DN="CN=mx.google.com" K C="250 2.0.0 OK dd12-20020a0560001e8c00b0034557e685a1si1823281wrb.34 - gsmtp"
2024-04-12 09:58:54 1rvBo6-0002yh-50 Completed
arditi-host3:~#

« 1rvBo6-0002yh-50 » est l’identifiant Exim du message.

Avec ce test, on peut détecter de suite les divers problèmes, comme un refus de connexion, un port 25 bloqué, un blocage par la politique anti-spam du destinataire, une boîte aux lettres inexistante, etc…

bsd-mailx pour tester

bsd-mailx est un client mail un peu plus évolué que Exim ou Sendmail qui permet de voir plus simplement les échanges. C’est une petite surcouche… Il suffit d’installer le paquet « bsd-mailx » pour l’utiliser. On peut l’appeler par la commande mail :

arditi-host3:~# mail -v aa2@tohero.fr
Subject: Test
Bonjour
.
Cc: 
LOG: MAIN
  <= alain@arditi.fr U=root P=local S=442
delivering 1rvCQu-0003Bg-6R
R: dnslookup for aa2@tohero.fr
T: remote_smtp for aa2@tohero.fr
Connecting to aspmx.l.google.com [66.102.1.26]:25 ... connected
  SMTP<< 220 mx.google.com ESMTP y18-20020a5d6152000000b0033ec3e493ccsi1863889wrt.179 - gsmtp
  SMTP>> EHLO arditi-host3.arditi.net
  SMTP<< 250-mx.google.com at your service, [51.159.28.23]
         250-SIZE 157286400
         250-8BITMIME
         250-STARTTLS
         250-ENHANCEDSTATUSCODES
         250-PIPELINING
         250-CHUNKING
         250 SMTPUTF8
  SMTP>> STARTTLS
  SMTP<< 220 2.0.0 Ready to start TLS
  SMTP>> EHLO arditi-host3.arditi.net
  SMTP<< 250-mx.google.com at your service, [51.159.28.23]
         250-SIZE 157286400
         250-8BITMIME
         250-ENHANCEDSTATUSCODES
         250-PIPELINING
         250-CHUNKING
         250 SMTPUTF8
  SMTP>> MAIL FROM:<alain@arditi.fr> SIZE=1479
  SMTP>> RCPT TO:<aa2@tohero.fr>
         will write message using CHUNKING
  SMTP>> BDAT 456 LAST
  SMTP<< 250 2.1.0 OK y18-20020a5d6152000000b0033ec3e493ccsi1863889wrt.179 - gsmtp
  SMTP<< 250 2.1.5 OK y18-20020a5d6152000000b0033ec3e493ccsi1863889wrt.179 - gsmtp
  SMTP<< 250 2.0.0 OK y18-20020a5d6152000000b0033ec3e493ccsi1863889wrt.179 - gsmtp
  SMTP>> QUIT
  SMTP(close)>>
LOG: MAIN
  => aa2@tohero.fr R=dnslookup T=remote_smtp H=aspmx.l.google.com [66.102.1.26] X=TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256 CV=yes DN="CN=mx.google.com" K C="250 2.0.0 OK y18-20020a5d6152000000b0033ec3e493ccsi1863889wrt.179 - gsmtp"
LOG: MAIN
  Completed
arditi-host3:~#

A noter que notre client, bsd-mailx ou Exim, communique directement avec le serveur SMTP cible. Il n’y a pas de connexion sur le serveur Exim local. Exim est en mode client.

L’article Tester Exim 2/2 est apparu en premier sur Alain ARDITI's blog.

Tester les destinataires

Pour vérifier comment Exim envoie un email, on utilise le mode test, c’est la commande exim4 -bt adresse

Pour une boîte aux lettres existante :

arditi-host3:~# exim4 -bt alain@arditi.fr
R: dnslookup for alain@arditi.fr
alain@arditi.fr
  router = dnslookup, transport = remote_smtp
  host aspmx.l.google.com      [173.194.76.26]  MX=5
  host alt1.aspmx.l.google.com [142.251.9.26]   MX=10
  host alt2.aspmx.l.google.com [142.250.150.27] MX=10
  host aspmx2.googlemail.com   [142.250.153.26] MX=20
  host aspmx3.googlemail.com   [142.251.9.27]   MX=20
  host aspmx5.googlemail.com   [142.250.157.26] MX=20
  host aspmx4.googlemail.com   [74.125.200.27]  MX=20
arditi-host3:~#

Dans le cas d’une boîte aux lettres réelle, il n’y a pas trop de surprise. C’est plus intéressant de faire le test sur une boîte aux lettres locale, puisqu’on voit la réécriture de l’adresse et l’envoi :

arditi-host3:~# exim4 -bt root
R: system_aliases for root@arditi-host3.arditi.net
R: dnslookup for alain@arditi.fr
alain@arditi.fr
    <-- root@arditi-host3.arditi.net
  router = dnslookup, transport = remote_smtp
  host aspmx.l.google.com      [108.177.15.27]  MX=5
  host alt2.aspmx.l.google.com [142.250.150.27] MX=10
  host alt1.aspmx.l.google.com [142.250.153.27] MX=10
  host aspmx4.googlemail.com   [74.125.200.26]  MX=20
  host aspmx3.googlemail.com   [142.250.150.26] MX=20
  host aspmx2.googlemail.com   [142.251.9.26]   MX=20
arditi-host3:~#

On voit la reécriture de root, utilisateur local en alain@arditi.fr conformément à ce qu’on a déclaré dans le fichier /etc/aliases. On voit également que Exim4 récupère le champ Gecos dans /etc/passwd pour donner le nom root@arditi-host3.arditi.net à l’utilisateur root.

Tester les émetteurs

Pour vérifier quel est le signataire d’un email, il faut utiliser la commande « exim4 -brw adresse » qui affiche le détail de la réécriture des adresses. Pour une boîte aux lettres existante, il n’y a pas de surprises :

arditi-host3:~# exim4 -brw alain@arditi.fr
  sender: alain@arditi.fr
    from: alain@arditi.fr
      to: alain@arditi.fr
      cc: alain@arditi.fr
     bcc: alain@arditi.fr
reply-to: alain@arditi.fr
env-from: alain@arditi.fr
  env-to: alain@arditi.fr
arditi-host3:~#

Pour une boîte aux lettres locale, on voit la transformation :

arditi-host3:~# exim4 -brw root
  sender: alain@arditi.fr
    from: alain@arditi.fr
      to: root@arditi-host3.arditi.net
      cc: root@arditi-host3.arditi.net
     bcc: root@arditi-host3.arditi.net
reply-to: alain@arditi.fr
env-from: alain@arditi.fr
  env-to: root@arditi-host3.arditi.net
arditi-host3:~#

Là aussi, on voit qu’Exim utilise le contenu des fichiers /etc/aliases, /etc/email-addresses et /etc/passwd pour compléter les informations liées au compte root

L’article Tester Exim 1/2 est apparu en premier sur Alain ARDITI's blog.

Le serveur SMTP est souvent la dernière roue du carrosse sur les serveurs de l’Internet. Aussi, il arrive souvent qu’au login sur le serveur, on voit passer un message signalant qu’on a reçu des emails. Beaucoup d’utilisateurs ignorent le message qui est souvent la marque d’un serveur SMTP non configuré.

aa2@apollo:~ $ ssh arditi-host3.arditi.net
Linux arditi-host3 4.19.0-24-amd64 #1 SMP Debian 4.19.282-1 (2023-04-29) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Fri Feb 23 10:43:40 2024 from 68.201.202.129
You have new mail
arditi-host3:~#

Si on décide de regarder ce qu’il y a dans la boîte aux lettres, on a souvent une surprise de ce type :

arditi-host3:~# mail
Mail version 8.1.2 01/15/2001.  Type ? for help.
"/var/mail/root": 1812 messages 1812 new
>N  1 root@localhost     Fri Feb 23 10:43   19/657   Cron <root@localhost> [ -x /usr/sbin/filetraq ] && /usr/sbin/filetraq
 N  2 root@localhost     Fri Feb 23 10:45   19/657   Cron <root@localhost> [ -x /usr/sbin/filetraq ] && /usr/sbin/filetraq
 N  3 root@localhost     Fri Feb 23 10:53   19/593   Cron <root@localhost> [ -x /usr/sbin/filetraq ] && /usr/sbin/filetraq
 N  4 root@localhost     Fri Feb 23 10:54   19/593   Cron <root@localhost> [ -x /usr/sbin/filetraq ] && /usr/sbin/filetraq
 N  5 root@localhost     Fri Feb 23 10:55   18/642   *** SECURITY information for localhost ***
 N  6 root@localhost     Fri Feb 23 10:55   18/675   *** SECURITY information for localhost ***
&

On voit que le serveur émet des alertes, qui, tant qu’on n’a pas ouvert la boîte aux lettres, sont ignorées. D’autre part, le fichier qui contient tous ces emails « /var/mail/root » ne fait que grossir….

C’est dommage, car les messages des crons permettent souvent de diagnostiquer un problème rapidement.

Exim est particulièrement simple à configurer pour faire le minimum, c’est à dire permettre l’envoi des emails administratifs. Pour les emails applicatifs, il est souvent préférable d’avoir un service externalisé d’envoi d’emails pour éviter d’avoir à gérer tous les problèmes de rejets d’emails et de whitelisting auprès des grands acteurs du mail, comme Gmail, Hotmail, Free, Orange, La Poste, etc…

Préliminaires

L’outil dpkg-reconfigure permet d’initialiser la configuration d’Exim de manière interactive en quelques écrans.

Avant de lancer la configuration, il faut s’assurer que la machine a un nom FQDN correct, c’est à dire que la commande « hostname -f » renvoie le nom complet de la machine. Lors de l’installation le nom fourni se retrouve dans le fichier /etc/hostname. C’est le nom court de la machine. Le nom long provient du fichier /etc/hosts dans lequel on doit retrouver le nom court.

Si /etc/hostname contient arditi-host3, dans /etc/hosts on doit retrouver une ligne avec le nom FQDN suivi du nom court.

127.0.0.1       localhost 
51.159.28.23    arditi-host3.arditi.net arditi-host3

# The following lines are desirable for IPv6 capable hosts 
::1     localhost ip6-localhost ip6-loopback 
ff02::1 ip6-allnodes 
ff02::2 ip6-allrouters

Ici, on déclare l’IP du serveur lui-même, mais on peut aussi utiliser une IP locale : 127.0.1.1 pour déclarer le FQDN. On a un fichier de la forme

127.0.0.1     localhost
127.0.1.1     arditi-host3.arditi.net arditi-host3

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

Et la commande répond :

arditi-host3:~# hostname -f
arditi-host3.arditi.net
arditi-host3:~#

Une fois cette étape réalisée, on peut lancer la configuration d’Exim avec la commande dpkg-reconfigure exim4-config

Dans les écrans qui suivent, on indique qu’on va envoyer et recevoir des emails sur Internet, mais comme on mettre 127.0.0.1 en IP d’écoute, aucun mail ne pourra arriver depuis l’extérieur. On est donc dans une configuration qui ne peut qu’envoyer des emails vers l’Internet. On verra dans un autre article l’utilisation d’un relais (smarthost). Dans le nom du système, on met le nom FQDN de la machine.

Configuration des alias et des adresses

Dernier point pour que les emails administratifs fonctionnent, c’est la configuration des alias. En effet, les emails administratifs sont pour la plupart des emails provenant de tâches planifiées (cron), qui sont adressés à « root » par défaut. On va donc donner à root une véritable adresse email grâce au fichier /etc/aliases, c’est la dernière ligne du fichier :

arditi-host3:~# cat /etc/aliases 
# /etc/aliases
mailer-daemon: postmaster
postmaster: root
nobody: root
hostmaster: root
usenet: root
news: root
webmaster: root
www: root
ftp: root
abuse: root
noc: root
security: root
root: alain@arditi.fr
arditi-host3:~#

Pour signer les emails administratifs, et en particulier s’ils bouncent, il faut une boîte aux lettres réelle pour les émetteurs. Ainsi les bounces vont pouvoir revenir sur une boîte aux lettres plutôt que d’être perdus dans le « goulp » ! On déclare ces emails dans le fichier /etc/email-addresses

arditi-host3:~# cat /etc/email-addresses
# This is /etc/email-addresses. It is part of the exim package
#
# This file contains email addresses to use for outgoing mail. Any local
# part not in here will be qualified by the system domain as normal.
#
# It should contain lines of the form:
#
#user: someone@isp.com
#otheruser: someoneelse@anotherisp.com
root: alain@arditi.fr
www-data: alain@arditi.fr
arditi-host3:~#

A noter que j’ai déclaré une adresse pour www-data, car c’est l’utilisateur qui va envoyer les emails lorsqu’on utilise un serveur Apache pour une application Web.

Pour terminer, afin de donner un nom à l’émetteur, on peut modifier le fichier /etc/password et mettre à jour le champ Gecos de l’utilisateur

arditi-host3:~# cat /etc/passwd
root:x:0:0:root-arditi-host3.arditi.net:/root:/bin/bash
....
www-data:x:33:33:Wordpress Contact:/var/www:/usr/sbin/nologin
....

La ligne root contient le nom long, comme ça on voit d’où vient l’email sans avoir à regarder les en-têtes SMTP.

Un email reçu depuis cette machine sera de la forme :

On voit dans cet exemple, la différence entre le destinataire du message qui est root et l’adresse de l’enveloppe, alain@arditi.fr qui permet à l’email de sortir sur Internet et d’arriver dans la boîte aux lettres.

L’article Configuration Exim est apparu en premier sur Alain ARDITI's blog.

1. la partie port 80, qui gère le lien avec les navigateurs et les redirigent vers le port 443 (SSL)
2. la partie port 443, qui fait office de proxy SSL
3. la partie port 8080, qui fait office de proxy pour PHP-fpm

Ici on va s’intéresser en particulier au deux premières parties qui gèrent la connexion avec les Internautes, car on va pouvoir y intégrer des règles qui permettent d’ajouter une authentification ou une page de maintenance. L’authentification est typiquement utilisée pour les sites de préproduction ou de recette et la page de maintenance est utilisée pour les mises en production ou lors d’incidents de production.

Port 80

La configuration sur le port 80 a pour seul objectif de renvoyer l’Internaute vers une connexion sécurisée SSL sur le port 443. Ca ne doit pas être une généralité, car pour des sites qui ne gèrent pas de login, il n’y a aucun intérêt à faire du SSL, même si Google souhaite le contraire. On s’aperçoit que forcer le SSL de manière généralisée, quelque soient les contenus, consomme de la CPU et détruit les ressources de la planète.

Néanmoins, voici une configuration de serveur Nginx pour forcer le SSL !

server {
        listen 80 default_server;
        listen [::]:80 default_server;

        # prend tous les noms de serveurs
        server_name _;

        # reecriture en HTTPS
        rewrite ^(.*) https://$host$1 permanent;
}

Port 443

La configuration du port 443 a pour objectif de présenter le certificat SSL et de faire le proxy vers l’application. C’est donc à ce niveau, qu’on peut faire des filtres en fonction des noms DNS, des URLs, des IP des clients, etc…

Une configuration simple du proxy qui renverrait tout le trafic entrant vers un Varnish sur le port 6081 aurait cette syntaxe :

server {

    listen 443 ssl;
    listen [::]:443 ssl;

    # le nom ou les noms DNS gérés dans le certificat
    server_name mon_serveur;

    # le certificat SSL
    ssl_certificate         /etc/letsencrypt/live/mon_serveur/fullchain.pem;
    ssl_certificate_key     /etc/letsencrypt/live/mon_serveur/privkey.pem;

    access_log /var/log/nginx/proxy-ssl-access.log;
    error_log /var/log/nginx/proxy-ssl-error.log;

    location / {
        proxy_pass http://127.0.0.1:6081;
        include /etc/nginx/proxy_params;
    }
}

Authentification pour un environnement de recette

Une fois que Nginx est configuré comme proxy SSL, il est assez simple d’ajouter une authentification pour tout un site.

Voici un exemple de configuration :

server {

    listen 443 ssl;
    listen [::]:443 ssl;

    # le nom ou les noms DNS gérés dans le certificat
    server_name mon_serveur;

    # le certificat SSL
    ssl_certificate         /etc/letsencrypt/live/mon_serveur/fullchain.pem;
    ssl_certificate_key     /etc/letsencrypt/live/mon_serveur/privkey.pem;

    access_log /var/log/nginx/proxy-ssl-access.log;
    error_log /var/log/nginx/proxy-ssl-error.log;

    # Protection de toutes les pages
    auth_basic "Restricted access";
    auth_basic_user_file /etc/nginx/htpassword;

    location / {
        proxy_pass http://127.0.0.1:6081;
        include /etc/nginx/proxy_params;
    }
}

L’article Nginx comme proxy SSL est apparu en premier sur Alain ARDITI's blog.

La gestion du cache Varnish est alors intégrée à l’outil. C’est à dire que l’outil va générer un en-tête du type TTL (expires ou autre) qui va permettre à Varnish d’appliquer la politique de cache de l’outil. Quand les éléments de sites contiennent des hash dans les URLs, généralement les TTL sont très grands (une année, voire plus). A chaque nouvelle version de cet élément l’outil va modifier le hash, et les utilisateurs pourront ainsi récupérer la nouvelle version sans qu’il n’y ait eu de purge de l’ancienne, puisque l’élément a un nouveau nom !

Dans le cas où les éléments ne changent pas de nom, la home page par exemple, ou des pages Web avec des permaliens, c’est l’outil qui va envoyer une requête de purge à Varnish (généralement une requête HTTP de type PURGE), qui va ainsi rafraîchir son cache et envoyer la nouvelle version.

Ces technologies sont relativement bien rodées sauf dans quelques cas où une extension ne gère pas le cache Varnish ou bien quand on insère dans blocs dans une page ou qu’on fait de l’ESI par exemple.

Dans ces cas, on peut toujours rafraîchir le cache Varnish en ligne de commande avec l’outil d’administration varnishadm ou bien en forgeant une requête de type PURGE, mais ces techniques dépassent souvent les permissions accordés aux webmestres ou leur compétences.

Il reste une solution assez simple d’utilisation, c’est de déclencher une purge Varnish quand l’utilisateur demande une version de la page qui ne provient pas du cache, c’est à dire avec le header HTTP « Cache-Control: no-cache »

C’est le header envoyé par les navigateurs quand on demande le rafraîchissement d’une page. Selon les OS et les navigateurs, le rafraîchissement s’obtient par les raccourcis claviers suivants :

• Windows: Ctrl + F5
• Mac: Command + Shift + R
• Linux: Ctrl + Shift + R

Dans le livre Varnish 6 by example, il est écrit :
« How Varnish deals with Cache-Control
First things first: Varnish doesn’t respect the Cache-Control as a request header, only as a response header. »

Effectivement l’objectif de Varnish ce n’est pas que les utilisateurs contournent le cache et le vide sans arrêt. L’idée de la mise en place du rafraîchissement par un navigateur, c’est de filtrer les IP qui ont le droit de de procéder au rafraîchissement.

On trouve des articles des années 2010 sur Internet qui indiquent comment faire et qui proposent des élément de configuration des fichiers VCL de Varnish datant de Varnish 3 ou 4 :

acl CTRLF5 {
   "127.0.0.1";
}

sub vcl_hit {

  if (client.ip ~ CTRLF5) {
    if (req.http.pragma ~ "no-cache" || req.http.Cache-Control ~ "no-cache")
    {
      set obj.ttl = 0s;
      return(pass);
    }
    else { return(deliver); }
  }
  else { return(deliver); }
}

Bref, quand on travaille sur Varnish 6 avec des CDN ou des proxy SSL type Nginx, on ne risque pas de faire fonctionner le rafraîchissement avec le code ci-dessus !

La configuration actualisée pour Varnish 6 serait du type :

# VCL version 5.0 is not supported so it should be 4.0 even though actually used Varnish version is 6
vcl 4.0;
import std;
...

# Declaration des IP autorisées à purger les pages
purge {
  "localhost";
  "127.0.0.1";
  "::1";
  "78.201.202.159"; # IP de ma maison
  "90.63.253.70";   # toHero (Orange)
  "212.114.18.211"; # toHero (Free)
}
...

sub vcl_hit {
    # Comme on est derrière Nginx, client.ip est l'IP du proxy pour tous les clients !!!
    # Si on se basait sur client.ip, il n'y aurait aucun filtrage...
    # On utilise X-Real-IP, sauf si la requête provient de localhost
    if ((req.http.X-Real-IP) && (std.ip(req.http.X-Real-IP) ~ purge) ||
            client.ip ~ purge) {
        if (req.http.pragma ~ "no-cache" || req.http.Cache-Control ~ "no-cache")
        {
          ban("obj.http.X-Req-URL ~ " + req.url);
          return (restart);
        }
    }
...

Une fois cette configuration installée, on peut procéder à quelques tests !

aa2@apollo:~$ curl -s -k -D - -o /dev/null "https://alain.arditi.fr/"
HTTP/1.1 200 OK
Server: nginx
Date: Wed, 22 Feb 2023 14:51:19 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Last-Modified: Sun, 06 Nov 2022 21:39:44 GMT
Vary: Accept-Encoding
Age: 24
X-Cache: HIT
Accept-Ranges: bytes

aa2@apollo:~$

# On force le rafraichissement
aa2@apollo:~$ curl -s -k -H "Cache-control: no-cache" -D - -o /dev/null "https://alain.arditi.fr/"
HTTP/1.1 200 OK
Server: nginx
Date: Wed, 22 Feb 2023 14:51:25 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Last-Modified: Sun, 06 Nov 2022 21:39:44 GMT
Vary: Accept-Encoding
Age: 0
X-Cache: MISS
Accept-Ranges: bytes

aa2@apollo:~$
aa2@apollo:~$ curl -s -k -D - -o /dev/null "https://alain.arditi.fr/"
HTTP/1.1 200 OK
Server: nginx
Date: Wed, 22 Feb 2023 15:33:08 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 31761
Connection: keep-alive
Last-Modified: Sun, 06 Nov 2022 21:39:44 GMT
Vary: Accept-Encoding
Age: 14
X-Cache: HIT
Accept-Ranges: bytes

aa2@apollo:~$ 

# Test depuis une IP qui n'est pas dans l'access list "purge" :
arditi-host3:~# curl -s -k -H "Cache-control: no-cache" -D - -o /dev/null "https://alain.arditi.fr/"
HTTP/1.1 200 OK
Server: nginx
Date: Wed, 22 Feb 2023 15:35:23 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 31761
Connection: keep-alive
Last-Modified: Sun, 06 Nov 2022 21:39:44 GMT
Vary: Accept-Encoding
Age: 149
X-Cache: HIT
Accept-Ranges: bytes

arditi-host3:~#

…..

L’article Forcer le rafraichissement du cache Varnish avec Ctrl+F5 ! est apparu en premier sur Alain ARDITI's blog.

Bref, on est confronté, comme souvent sur Internet, à l’énorme quantité d’informations qu’il faut savoir trier. 
C’est au lecteur de se faire une idée et de construire son savoir.
Et quand on travaille seul, on se pose souvent des questions qui restent sans réponse.

Si on travaille en équipe, ça relève de la technique des fourmis, celui qui a trouvé la bonne manière de faire va diffuser l’information aux collègues. Encore faut-il que ce soit effectivement la bonne manière de faire. J’ai vu de nombreux informaticiens utiliser des options qui ne faisaient pas ce qu’ils pensaient…

L’objectif de ce document est de vous exposer ma manière de faire, c’est-à-dire les commandes de base que j’utilise au quotidien dans mon travail d’administrateur système.
Ce n’est pas la meilleure manière ni la plus complète, c’est la mienne. Elle est probablement différente de celle des autres administrateurs, chacun ayant ses propres trucs.
Je vous livre ma manière d’utiliser la ligne de commande, à vous d’y piocher ce qui vous paraît pertinent.

La manière dont je travaille est le résultat d’un long processus qui a pris des années et des années. J’ai commencé à travailler sous Unix en 1988…. J’ai eu la chance de croiser beaucoup d’autres utilisateurs sous Unix ou Linux, dans mon travail quotidien comme lors d' »install parties » ou des salons.

Chacun a sa propre manière d’utiliser la ligne de commande.
Chacun a son propre jeu d’instructions, certains en utilisent beaucoup, d’autres moins. Enfin, certains qui ne veulent pas s’immerger dans Linux, en utilisent le minimum. 

Ce document s’adresse à des débutants, puisqu’on y retrouve les commandes de base et, dans la très grande majorité, dans une utilisation simple.
Mais si on veut comprendre le sens de ces commandes, ou plutôt pour quelle raison il vaut mieux utiliser une commande sous cette forme plutôt qu’une autre, il vaut mieux avoir déjà une expérience de la ligne de commande. Et c’est le sujet de ce partage : la recherche de sens.

C’est comme l’apprentissage du piano. Si votre professeur vous dit de mettre les doigts comme ça, vous le faîtes parce que vous êtes persuadé qu’il faut faire ainsi. Si vous avez déjà fait des années de piano, vous allez comprendre pour quelle raison il fallait le faire ainsi.

Lorsqu’on apprend l’informatique, on est souvent confronté à une problématique de transmission de savoir. On va vous dire que si vous ne connaissez pas une commande, il faut regarder le « man » ou bien chercher sur Internet. Les cours que j’ai eu l’occasion de donner ou de voir sur la ligne de commande, sont soit minimalistes pour les débutants qui n’ont jamais vu une console, soit un partage de syntaxe spécifiques pour des élèves avancés. Dans ce dernier cas, on arrive souvent à l’énumération des options de la commande, qui pour la plupart sont peu utiles au quotidien. On retombe facilement dans la paraphrase du « man ».
Alors, les bons professeurs, lorsqu’ils paraphrasent le man illustrent souvent leur propos avec des exemples. Sinon, ils diraient à leurs élèves : lisez la doc !
C’est d’ailleurs ce qu’on peut critiquer à l’esprit du RTFM.

Si on illustre toutes les options, on se dit que les élèves auront au moins entendu une fois dans leur vie le contenu de cette documentation et s’en rappelleront au moment opportun. C’est ce qu’on se dit tous, en imaginant qu’en lisant l’exhaustivité de cette documentation on va trouver une option magique qu’on n’avait jamais utilisée jusqu’à présent.

A mon avis, il vaut mieux se concentrer sur les bonnes options à retenir et savoir ce qu’elles font exactement plutôt que de connaître vaguement le sens de toutes les options.
Comme souvent en informatique, il faut supprimer le « vague » ou l' »à peu près » de sa manière de penser.

Certains de mes collègues en arrivant dans l’équipe m’expliquaient qu’ils utilisaient toujours rsync avec les options -trolpg. Soit !
Moi j’utilise les options -av ou -avz, les autres options sont des cas particuliers.

On est dans une situation où pour comprendre la manière de faire, il faut déjà avoir un certain bagage. Et des cours où on explique la manière de faire, je n’en connais pas. C’est très souvent en échangeant avec un autre admin qu’on se dit que sa manière d’utiliser telle commande est plus efficace que la nôtre.
Des fois à la lecture d’un article on se dit quelle « cool feature » cette option ! Et on se l’approprie.

La difficulté comme souvent dans l’apprentissage étant de transmettre le maximum d’informations sans noyer les élèves. Si on dit juste qu’il faut utiliser telle commande de cette manière, on restreint souvent très fortement les fonctionnalités de la commande.

Mais c’est mon parti pris : limiter le nombre de commandes et leurs options.

Ce qui ne veut pas dire qu’avec l’expérience, il ne faudra pas aller creuser les autres options ou les autres commandes. D’ailleurs, je remarque que la très grande majorité des administrateurs ont une connaissance encyclopédique des commandes et de leurs options. Cette connaissance, il faudra l’avoir un jour ou l’autre. Même si on utilise certaines options une fois par an !

Alors, le jeu de commandes que j’utilise au quotidien est relativement simple. C’est un compromis entre l’efficacité des commandes et ma capacité à mémoriser les syntaxes.  

Afin d’avoir une démarche rationnelle, j’ai extrait quelques statistiques de mes historiques de ligne de commande.
Les échantillons que j’ai utilisés pour extraire les commandes les plus utilisées sont les suivants :

Top 10 des commandes de base que j’utilise

Note : j’ai pris uniquement la première commande après le prompt sans tenir compte des commandes qui suivent un pipe.

Quelques commentaires

1. Les commandes ci-dessus sont essentiellement des commandes d’administration système. C’est de la recherche d’information pour la réutiliser ou pour la modifier.
2. la commande sudo provient de mes historiques de postes personnels sur lequel je travaille avec un compte utilisateur. Pour les serveurs, je travaille sous root, il n’y a donc pas de sudo. Sauf pour lancer une commande avec l’environnement spécifique à un utilisateur.
3. Si on l’élimine la commande sudo, la commande man arrive en 10^ème position !
4. Une commande particulièrement utile qui n’apparaît pas dans cette liste est « pwd » (Print Working Directory). Comme l’invite de commande (le prompt) affiche le répertoire courant, inutile d’utiliser pwd !
5. Les deux premières commandes cd et ls reflètent l’exploration de l’arborescence des fichiers. Il faut ajouter la commande pwd qui est implicite car affichée dans le prompt. Le triplet de commandes « cd ls pwd » est l’équivalent des explorateurs de fichiers en mode graphique. On se déplace dans les répertoires en cliquant sur le répertoire qui montre alors les fichiers qui s’y trouvent.
6. rsync arrive en 3^ème position. C’est la commande qui permet de copier un fichier ou une arborescence. Je n’utilise plus ou quasiment plus ni cp, ni scp.
7. history est la commande qui permet d’afficher les commandes qu’on a déjà saisies. C’est l’aide mémoire de la ligne de commande, suivi très souvent de la commande grep afin de rechercher une commande en particulier. L’objectif étant de réutiliser au maximum ce qu’on a déjà fait !
8. la commande grep apparaît ici dans le cas où elle est la première commande de la ligne. Elle correspond à des recherches de chaînes dans des fichiers et non pas derrière un pipe. En fait je l’utilise énormément derrière les pipes suite à un history, mais je n’ai pas comptabilisé ce mode d’utilisation.
9. la commande rm (remove), pour supprimer des fichiers ou des arborescences arrive haut dans le listing. 2000 rsync pour 1000 rm, c’est le signe du nettoyage des fichiers obsolètes. Une partie du travail d’administration système consiste à déplacer ou à recopier des arborescences. Il faut ensuite supprimer les fichiers inutiles, ça relève des bonnes pratiques.

Détail des options de ls

Voici plus en détail l’utilisation que je fais de la commande ls, d’après mes historiques :

Les 2 principales options sont :

• ls -l (long) pour avoir le détail de chaque fichier listé par ordre alphabétique
• ls -ltr (long time reverse) pour avoir le fichier le plus récent en bas du listing. C’est la commande qui permet de connaître les fichiers « chauds », donc ceux qui bougent, dans les logs ou les répertoires de configuration par exemple.

Détail des options de rsync

Voici les options que j’utilise le plus souvent

Le bilan pour les rsync tapés en ligne de commande font que les plus simples sont de la forme
rsync -av source destination
et les plus compliqués sont de la forme
rsync -avz –delete -P source destination
L’option -n (dry-run) permet de lancer la commande pour voir ce qu’elle ferait.
L’option -P permet de « voir » la progression du rsync
L’option -c permet de comparer les fichiers source et destination par un checksum. Par defaut rsync considère qu’un fichier est identique sur la source et la destination si la taille et la date de modification sont identiques. Avec -c on peut contrôler une arborescence suite à une intrusion ou limiter le listing des fichiers modifiés….

Les scripts de synchro utilisent principalement des exclusions et parfois l’option –numeric-ids

En voici deux exemples :

rsync -av $DRY --delete \
--exclude=@eaDir/ \
--exclude=".DS_Store" \
--exclude=".TemporaryItems/" \
$SOURCE $DEST

rsync -avz \
--numeric-ids \
--delete \
--exclude="var/cache/" \
--exclude="var/run/" \
--exclude="tmp/" \
--exclude="dev/" \
--exclude="etc/network/" \
--exclude="run/utmp" \
$SRV:/mnt/disk1/$VM/ /mnt/disk1/$VM/

Le –numeric-ids permet de conserver les id utilisateurs et groupes lors du rsync. C’est utile pour manipuler des VM LXC depuis un host sans perturber les permissions de la VM guest qu’on vient de copier.

L’article Linux efficace ou les 10 commandes à connaître est apparu en premier sur Alain ARDITI's blog.

Les marches d’escalier quand elles sont suffisamment longues par rapport à la fréquence des prises de mesures du côté de l’infrastructure, permettent de faire une corrélation directe entre la charge et le comportement de la plateforme. En effet, la plateforme va consommer des ressources en fonction de l’injection et on pourra visualiser les marches d’escalier du côté des graphiques de l’infrastructure.

A condition que la durée des marches, ou plus précisément la durée des paliers, permette d’avoir suffisamment de points de mesure côté infrastructure. Si la fréquence de la métrologie est de 5 minutes, par exemple, qui est la valeur courante des logiciels de métrologie, il faut au moins des paliers de 15 à 20 minutes pour avoir 3 à 4 mesures et visualiser ainsi le palier.

Dans l’exemple suivant, on peut voir l’utilisation du plugin “Concurrency Thread Group” avec des paliers de 20 minutes.

Du côté de l’infrastructure, sur le graphe du débit réseau on retrouve les paliers :

On peut ainsi faire la correspondance entre le nombre de threads et la charge de la plateforme.

On peut dire qu’à 60 threads, au 3^ème palier, le débit de la plateforme est de 60 Mbps et qu’au 8^ème et dernier palier, à 150 threads, le débit est de 150Mbps.

Même si les paliers de la métrologie ne sont pas plats, on retrouve bien l’évolution de l’injecteur, et dans ce cas précis, on peut même conclure sans trop se tromper que le débit augmente de 1 Mbps par thread.

Par contre, on n’en déduit pas facilement le nombre de parcours ou de sessions simultanées à chaque palier.

Un moyen assez simple d’extrapoler les résultats pour avoir des métriques marketing, est de spécifier des valeurs judicieuses dans le plugin “Concurrency Thread Group”, comme on va le voir dans le graphique ci-dessous :

Ici, on a des marches d’escalier de 20 minutes avec 20 threads supplémentaires à chaque marche. On remarque que les surfaces sous les marches augmentent d’une unité de surface (4 carreaux) par marche.

Ainsi la surface sous la dernière marche vaut 5 fois la surface sous la première marche.

Comme les threads travaillent de manière uniforme, on peut en déduire que s’ils parcourent n scénarios pendant les 20 première minutes, c’est à dire pendant la première marche, ils en parcourent 5 fois plus lorsque JMeter atteint les 100 threads, c’est à dire à la dernière marche.

Comme JMeter fournit le nombre total de scénarios qu’il a exécutés à la fin du tir, en détaillant le nombre d’exécution par URL, on peut en déduire facilement le nombre de visites.

Pour connaître le nombre de scénarios exécutés pendant les 20 premières minutes, on part de l’hypothèse que nombre de scénarios est proportionnel à la surface sous les marches.

La surface totale de l’escalier de 5 marches, qu’on appellera S_tot, est de 1+2+3+4+5 = 5×6/2 = 15. Donc S_tot = 15.

Si le nombre total de scénarios exécutés par JMeter, donc le nombre de visites, est V_tot, alors pendant les 20 premières minutes (durée de la première marche), JMeter a exécuté  V_tot / S_tot visites.

Et pendant les 20 dernières minutes, à la 5^ème marche, il aura exécuté (V_tot / S_tot * 5) visites, puisque la surface sous la 5eme marche est 5 fois plus grande que la surface de la première.

En prenant les usages du Web qui comptabilisent les sessions comme toute visite après 30 minutes d’inactivité, si on extrapole le nombre de visites du dernier palier de 20 minutes à 30 minutes, on obtient (V_tot / S_tot * 5) * 3/2 sessions simultanées lorsqu’on atteint 100 threads.

On voit que ce calcul s’applique quel que soit le nombre de threads et la durée des paliers, sur la base des éléments fournis par JMeter, et se fait de manière simple, pour peu qu’on choisisse bien les paramètres du plugin “Concurrency Thread Group”.

En faisant la corrélation avec les graphes de l’infrastructure, on peut en déduire facilement le nombre de sessions simultanées qu’elle peut supporter !

Une fois qu’on connaît le nombre de sessions simultanées, on peut extrapoler les nombre de visite à l’heure, puis par jour et enfin le nombre de visites mensuelles, en jetant un oeil sur l’article : Test de charge : Comment extrapoler le nombre de visites ?

L’article Tests de charge : le plugin jp@gc Concurrency Thread Group est apparu en premier sur Alain ARDITI's blog.

On va s’intéresser à l’audience d’un site de commerce en ligne. Avant de passer une commande sur un site de commerce en ligne, un internaute va peut-être passer 20 minutes à naviguer sur le site pour parcourir le catalogue et remplir son panier. Ensuite, il va passer la commande, créer son compte, saisir son adresse de livraison, effectuer le paiement, et éventuellement vérifier sa commande sur le site. Il aura passé 30 minutes sur le site.

Afin de simuler l’audience, nous utilisons l’outil JMeter (https://jmeter.apache.org).

Si on veut simuler une audience équivalente à 600 commandes à l’heure, il faudra lancer notre scénario 600 fois en une heure. Comme il dure 30 minutes, il faudra lancer 300 threads en parallèle qui vont chacun effectuer 2 scénarios. On aura bien nos 600 commandes en une heure, sauf qu’on imagine que les passages de commande vont se trouver plutôt à la fin des 30 minutes, on aura donc un biais par rapport à la réalité.

Si on veut supprimer ce biais, il faudrait que l’injecteur soit dans un rythme de croisière nominal, avant la prise des mesures, afin que les aléas temporels du scénario permettent de distribuer les commandes. Ca veut dire, qu’il faudra lancer les 300 threads quelques heures auparavant et au moins 30 minutes après l’heure de mesure.

Et si le site de commerce en ligne à un taux de conversion de 5%, c’est à dire le nombre de visiteurs qui vont passer une commande, il faut multiplier par 20 le nombre de scénarios exécutés par l’injecteur, sachant que 95% pourcents d’entre eux ne doivent pas passer de commande. En conservant des scénarios de 30 minutes, il faudra 6000 threads pour simuler l’audience et faire durer le test un bon paquet d’heures….

Bref, dans ces conditions, la simulation de la réalité devient très difficile en pratique, car la durée des tests est prohibitive !

Afin de permettre la réalisation des tests dans des durées acceptables, on va raccourcir la durée du parcours d’un visiteur.

On va faire la supposition que lancer 300 threads qui jouent un scénario de 30 minutes pendant 1 heure, c’est équivalent pour le site qui reçoit les visites à 30 threads qui jouent un scénario de 3 minutes pendant 1 heure.

Dans les 2 cas, on aura exécuté 600 scénarios en 1 heure. Le site aura répondu aux mêmes sollicitations sauf que dans le deuxième cas, le rythme de croisière sera atteint dix fois plus rapidement, facilitant du même coup la réalisation du test qui pourra durer 10 fois moins longtemps !

Si finalement, le scénario est accéléré pour durer 30 secondes, avec un enchaînement de 20 à 40 requêtes HTTP et des aléas temporels de quelques centaines de millisecondes entre les requêtes, on obtient l’équivalent de la charge précédente avec 5 threads pendant 30 secondes.

Si on fait durer ce dernier test 10 minutes, chaque thread aura fait 20 boucles. On n’est pas loin d’un rythme de croisière avec suffisamment d’aléa pour le considérer comme représentatif d’une audience de 600 commandes à l’heure.

Une manière simple de créer des tirs sur JMeter simulant une charge données est d’utiliser les paramètres “Number of Threads” et “Ramp-up period” dans l’objet “Thread Group”  

Dans l’exemple ci dessous :

les 30 threads seront atteint après une période de 20 minutes, pendant laquelle, JMeter va graduellement augmenter le nombre de threads pour passer de 1 à 30, puis il va continuer avec ce nombre de threads pendant 10 minutes, jusqu’à l’arrêt du test.

Le graphique du nombre de threads en fonction du temps est le suivant :

On peut remarquer que si la durée du “Ramp-up” fait les ⅔ de la durée totale, alors les surfaces A et B ci-dessous sont égales :

Si le nombre de conversion réalisées par JMeter pendant toute la durée du tir vaut N, alors, le nombre de conversions effectuées pendant la période nominale, ici, les 10 dernières minutes, vaut la moitié, soit N/2.

On peut dire que le nombre de conversions à l’heure vaut N/2×6, soit 3N conversions à l’heure.

Si les statistiques de la boutique indiquent un taux de conversion de 5%, alors, en ajoutant des scénarios sans conversion et en multipliant le nombre de threads par 20, on simulerait l’audience de la boutique.

Pour calculer l’audience équivalente au tir ci-dessus, on peut dire qu’on a 3Nx20 visiteurs à l’heure. Comme une session dans les usages du Web est comptabilisée après 30 minutes d’inactivité, on peut dire qu’on a un équivalent de 2x3Nx20 sessions simultanées.

Comment estimer le trafic quotidien et mensuel ?

La réponse dépend largement du type du site et des habitudes de fréquentation.

On peut se lancer dans un calcul à la louche, sachant qu’on obtient des ordres de grandeur et qu’il faut adapter le calcul en fonction des statistiques du site.

Si on estime que l’heure du pic d’affluence représente 20% du trafic de la journée, dans notre cas 3Nx20 visiteurs, pour la journée on en aurait 5 fois plus, soit Nx300 visites par jour.

Reste à extrapoler au mois. Si on considère que le jour le plus chargé représente 10% des visites du mois, on aurait Nx3000 visites par mois !

Si N vaut 100, notre tir produirait une charge équivalente à :

• 300 commandes à l’heure,
• 30 000 visites par jour,
• 300 000 visites par mois.

L’article Test de charge : Comment extrapoler le nombre de visites ? est apparu en premier sur Alain ARDITI's blog.

Pourtant c’est un outil incontournable de l’administration système. A tel point que je n’utilise que très rarement la commande cp (copy).

A l’origine rsync a été développé pour transférer des fichiers ou plutôt des arborescences sur des liaisons lentes. Voir http://rsync.samba.org On imagine le nombre d’utilisateurs qui se sont arrachés les cheveux en transférant une arborescence de site Web à l’époque des modems ADSL !

En effet, à chaque coupure de la liaison, on relançait la copie de l’arborescence même si la destination avait reçu 80% des fichiers.

D’ailleurs ce problème existe toujours pour les copies d’arborescences locales sur tous les outils de gestion de fichiers, comme l’Explorateur Windows, le Finder Mac ou les outils graphiques divers sous Linux. Si vous copiez une arborescence contenant des milliers de fichiers et qu’au bout d’une heure vous arrêtez le programme, car vous ne savez pas si la copie va durer toute la nuit, vous êtes bon pour refaire l’opération. Sauf que la première copie a laissé l’arborescence cible dans un certain état et vous ne connaissez pas le delta ! Donc, la seule manière simple de refaire la copie est de supprimer la destination et lancer la copie ensuite. Vous êtes reparti pour un tour ! (ou répondre que vous écrasez les fichiers identiques).

rsync répond parfaitement à la problématique des miroirs de l’Internet.

rsync permet de transférer des fichiers entre 2 machines ou sur
la même machine, selon la notation utilisée. C’est comme cp + rcp !

La puissance de rsync tient dans les points suivants :

• respect des arborescences, des droits, des liens, des ACL, etc….
• copie uniquement des fichiers modifiés entre 2 arborescences
• transfert uniquement des morceaux (chunks) modifiés d’un fichier
• possibilité de compresser les fichiers pour accélérer le transfert

Notez quand même, que selon les OS sur lesquels se trouvent la source et la destination (Unix/Windows, Windows/Mac, etc…), les droits et les ACL ou attributs ne vont pas pouvoir être transférés correctement.

La préservation des droits, etc… existe avec cp ou rcp. En local, c’est le « cp -a … ». Mais un deuxième « cp -a … » recopie tout une deuxième fois. Alors que l’équivalent « rsync -a … » lancé une deuxième fois ne transfère plus rien, car la source et la destination sont identiques !

Par défaut pour comparer les différences entre la source et la cible, rsync compare la taille et la date des fichiers. S’ils ces informations sont identique pour un fichier, il ne le transfère pas, car il considère qu’ils sont identiques. On peut forcer le contrôle en calculant les signatures des chunks (CRC) avec l’option -c (check). En fait, le CRC est calculé par morceaux de fichier de manière à trouver les différence à l’intérieur du fichier et ne transférer que ces morceaux.

D’autre part, pour reconstituer le fichier cible, il crée une copie du fichier cible.
Ainsi pour mettre à jour un fichier de 1Go, on a besoin d’1Go d’espace libre en plus du fichier cible, même s’il n’y a que quelques octets transférés. Ca veut dire que si vous transférez un unique fichier de 8Go et que le transfert est coupé, le fichier destination temporaire est effacé, et le rsync suivant va recommencer le transfert depuis le début.

C’est pour cette raison, qu’il vaut toujours mieux découper les gros fichiers en petits morceaux avec la commande split, transférer tous les morceaux avec rsync, puis les reconstruire avec cat !

Exemple :

$ split -b 100m mon_film.mp4 monfilm.mp4.
$ rsync -av monfilm.mp4.* alain.arditi.fr:/tmp/
puis sur l'ordinateur alain.arditi.fr on reconstitue la source 
alain.arditi.fr $ cat monfilm.mp4.* > monfilm.mp4
Pour plus de sécurité, on peut gzipper les morceaux,
comme ça on ajoute le contrôle de l'intégrité des morceaux.
Ou bien on lance un dernier rsync de contrôle :
$ rsync -av -c monfilm.mp4 alain.arditi.fr:/tmp/

L’option -n permet de lancer rsync sans effectuer les opérations (dry run). Avec l’option -v (verbose), on peut comparer deux arborescences pour « voir » les différences. Si on est pointilleux, on peut ajouter le -c, qu’on pourra utiliser pour comparer des arborescences suite à une intrusion….

Le dernier intérêt de rsync, c’est qu’il utilise un tuyau ssh pour pour les fichiers distants. Ainsi, lorsqu’on a une clé SSH sur l’ordinateur cible, pas besoin de saisie de mot de passe…. On peut lancer ses synchronisations d’arborescences dans des tâches planifiées (cron) !

L’article Rsync où comment transférer des fichiers est apparu en premier sur Alain ARDITI's blog.

Il y a deux objectifs dans ma démarche :

1. améliorer les sites de nos clients. Les tests de charge permettent d’apprécier le comportement d’un site lors de fortes audiences et de détecter les éventuelles contentions.
2. développer la maîtrise du Web chez les développeurs. A travers la mise au point des scénarios, on apprend comment un navigateur dialogue avec un site Web. C’est une brique essentielle dans la fabrication des sites Web.

Un sujet récurrent depuis le début du Web

On connaît tous l’importance des temps de réponse et les problématiques d’audience des sites Web.

En 1996, lorsque j’ai travaillé sur le premier site Web bancaire français, j’ai mis au point mon premier outil de test car il n’y avait aucun produit pour accomplir cette tâche. J’ai utilisé l’inoxydable Telnet pour simuler des connexions, des scénarios et des tests de charge !

A cette époque, Telnet sur HP-UX permettait d’injecter des requêtes HTTP avec un pipe.

Ca donnait des commandes de ce type :

$ echo -n “GET / HTTP/1.0\n\n” | telnet tohero.fr 80
Trying 92.222.234.216...
Connected to tohero.fr.
Escape character is '^]'.
HTTP/1.1 301 Moved Permanently
Server: nginx/1.10.3 (Ubuntu)
Date: Mon, 12 Jul 2021 09:19:03 GMT
Content-Type: text/html
Content-Length: 194
Connection: close
Location: https://www.tohero.fr/actualites

<html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx/1.10.3 (Ubuntu)</center>
</body>
</html>
Connection closed by foreign host.
$

Grâce à la simplicité du protocole HTTP, ça devenait (plus ou moins) facile d’injecter des requêtes POST, de stocker des cookies et de jouer un scénario avec des Shell scripts. C’est ainsi que j’ai commencé les tests de charge sur le site que j’étais en train de construire.  J’avais baptisé ce petit programme de tests “Gator”. On s’en servait également pour les tests systèmes, fonctionnels de bout en bout. On avait déjà un ancêtre de Sélénium pour les recettes.

Malheureusement, la grande majorité des “Telnet” ne supportaient pas le pipe. J’ai donc réécrit Gator en Perl, ce qui a donné naissance à gator.pl

Cette fois le script Perl était bien plus évolué et prenait en entrée des scénarios de test sous forme de fichiers.

Au début des années 2000, on n’envoyait pas beaucoup d’informations dans les headers et le JavaScript ne posait pas trop de problèmes. On était capable de créer nos tests sans sniffer le trafic Web, uniquement avec la connaissance des pages à tester.

Néanmoins, la mise au point de ce type de tests n’était  possible que par les développeurs. Et les années passant, je me suis dit que les scripts Perl étaient trop compliqués à maintenir et je me suis tourné vers un produit. Comme à l’époque je programmais en Java et j’utilisais Tomcat comme serveur applicatif, je me suis naturellement tourné vers Jakarta JMeter, qui faisait partie de la même suite logicielle que Tomcat, pour faire les tests de charge.

Les RFC

L’intérêt de travailler sur la mise au point des scénarios de tests de charge est de comprendre le dialogue entre un client (navigateur) et un serveur Web. Ce dialogue a été formalisé pour la première fois dans un « Request For Comment », la RFC 1945 écrite en partie par Tim Berners Lee qui détaille le protocole HTTP. Par la suite d’autres RFC , comme la RFC 2068 ont complété cette documentation au fur et à mesure que le protocole s’est enrichi. Depuis, il y a eu bien d’autres RFC qui illustrent la complexité du dialogue entre le client Web et le serveur.

Depuis quelques années, cette communication est au cœur de l’optimisation de l’expérience client. Tout le monde s’y intéresse et des logiciels comme Google PageSpeed qui font aujourd’hui le bonheur des agences digitales, décortiquent en détail cette communication. On parle ici des performances d’un site.

Les tests de charge supposent idéalement que le site est déjà performant. On constate en pratique qu’un site performant supporte mieux la charge qu’un site peu performant. Ça veut dire que les équipes qui ont travaillé sur le projet étaient déjà sensibles à la performance.

Pour autant les tests de charges vont permettre de trouver des optimisations liées aux pics d’audience. C’est leur objectif premier, mais on peut trouver bien d’autres contentions ou imperfections avec ce type de tests !

L’article Tests de charge : Un peu d’histoire est apparu en premier sur Alain ARDITI's blog.