One place for hosting & domains

      serveur

      Comment configurer une authentification par clé SSH sur un serveur Linux


      Introduction

      SSH, ou secure shell, est un protocole crypté utilisé pour administrer et communiquer avec des serveurs. Si vous travaillez avec un serveur Linux, il est fort probable que vous passiez la majeure partie de votre temps dans une session terminal connectée à votre serveur par SSH.

      Bien qu’il existe plusieurs façons de se connecter à un serveur SSH, dans ce guide, nous allons essentiellement nous concentrer sur la configuration des clés SSH. Les clés SSH vous donnent un moyen facile et extrêmement sûr de vous connecter à votre serveur. Il s’agit donc de la méthode que nous recommandons à tous les utilisateurs.

      Un serveur SSH utilise diverses méthodes pour authentifier des clients. La plus simple est l’authentification par mot de passe, qui, malgré sa simplicité d’utilisation, est loin d’être la plus sécurisée.

      Bien que l’envoi des mots de passe au serveur se fasse de manière sécurisée, ces derniers ne sont généralement pas suffisamment complexes ou longs pour arrêter les attaquants assidus et insistants. La puissance de traitement moderne combinée aux scripts automatisés rendent tout à fait possible toute attaque par force brute d’un compte protégé par mot de passe. Bien qu’il existe d’autres méthodes d’ajouter davantage de sécurité (fail2ban, etc.), les clés SSH ont fait leur preuve en termes de fiabilité comme de sécurité.

      Les paires de clés SSH sont deux clés chiffrées qui peuvent être utilisées pour authentifier un client sur un serveur SSH. Chaque paire de clés est composée d’une clé publique et d’une clé privée.

      Le client doit conserver la clé privée qui doit rester absolument secrète. Si la clé privée venait à être compromise, tout attaquant pourrait alors se connecter aux serveurs configurés avec la clé publique associée sans authentification supplémentaire. Par mesure de précaution supplémentaire, la clé peut être cryptée sur le disque avec une phrase de passe.

      La clé publique associée pourra être librement partagée sans aucun impact négatif. La clé publique servira à crypter les messages que seule la clé privée pourra déchiffrer. Cette propriété est utilisée comme un moyen de s’authentifier avec la paire de clés.

      La clé publique est chargée sur un serveur distant auquel vous devez pouvoir vous connecter avec SSH. La clé est ajoutée à un fichier spécifique dans le compte utilisateur auquel vous allez vous connecter qui se nomme ~/.ssh/authorized_keys.

      Si un client tente de s’authentifier à l’aide de clés SSH, le serveur pourra demander au client s’il a bien la clé privée en sa possession. Une fois que le client pourra prouver qu’il possède bien la clé privée, une session shell est lancée ou la commande demandée est exécutée.

      Afin de configurer l’authentification avec des clés SSH sur votre serveur, la première étape consiste à générer une paire de clés SSH sur votre ordinateur local.

      Pour ce faire, nous pouvons utiliser un utilitaire spécial appelé ssh-keygen, inclus dans la suite standard d’outils OpenSSH. Par défaut, cela créera une paire de clés RSA de 2048 bits, parfaite pour la plupart des utilisations.

      Sur votre ordinateur local, générez une paire de clés SSH en saisissant ce qui suit : 

      ssh-keygen
      
      Generating public/private rsa key pair.
      Enter file in which to save the key (/home/username/.ssh/id_rsa):
      

      L’utilitaire vous demandera de sélectionner un emplacement pour les clés qui seront générées. Le système stockera les clés par défaut dans le répertoire ~/.ssh du répertoire d’accueil de votre utilisateur. La clé privée se nommera id_rsa et la clé publique associée, id_rsa.pub.

      En règle générale, à ce stade, il est préférable de conserver l’emplacement par défaut. Cela permettra à votre client SSH de trouver automatiquement vos clés SSH lorsqu’il voudra s’authentifier. Si vous souhaitez choisir un autre chemin, vous devez le saisir maintenant. Sinon, appuyez sur ENTER pour accepter l’emplacement par défaut.

      Si vous avez précédemment généré une paire de clés SSH, vous verrez apparaître une invite similaire à la suivante :

      /home/username/.ssh/id_rsa already exists.
      Overwrite (y/n)?
      

      Si vous choisissez d’écraser la clé sur le disque, vous ne pourrez plus vous authentifier à l’aide de la clé précédente. Soyez très prudent lorsque vous sélectionnez « yes », car il s’agit d’un processus de suppression irréversible.

      Created directory '/home/username/.ssh'.
      Enter passphrase (empty for no passphrase):
      Enter same passphrase again:
      

      Vous serez ensuite invité à saisir une phrase de passe pour la clé. Il s’agit d’une phrase de passe facultative qui peut servir à crypter le fichier de la clé privée sur le disque.

      Il serait légitime de vous demander quels avantages pourrait avoir une clé SSH si vous devez tout de même saisir une phrase de passe. Voici quelques-uns des avantages :

      • La clé SSH privée (la partie qui peut être protégée par une phrase de passe) n’est jamais exposée sur le réseau. La phrase de passe sert uniquement à décrypter la clé sur la machine locale. Cela signifie que toute attaque par force brute du réseau sera impossible avec une phrase de passe.
      • La clé privée est conservée dans un répertoire à accès restreint. Le client SSH ne pourra pas reconnaître des clés privées qui ne sont pas conservées dans des répertoires à accès restreint. La clé elle-même doit également être configurée avec des autorisations restreintes (lecture et écriture uniquement disponibles pour le propriétaire). Cela signifie que les autres utilisateurs du système ne peuvent pas vous espionner.
      • Tout attaquant souhaitant craquer la phrase de passe de la clé SSH privée devra préalablement avoir accès au système. Ce qui signifie qu’il aura déjà accès à votre compte utilisateur ou le compte root. Dans ce genre de situation, la phrase de passe peut empêcher l’attaquant de se connecter immédiatement à vos autres serveurs, en espérant que cela vous donne du temps pour créer et implémenter une nouvelle paire de clés SSH et supprimer l’accès de la clé compromise.

      Étant donné que la clé privée n’est jamais exposée au réseau et est protégée par des autorisations d’accès au fichier, ce fichier ne doit jamais être accessible à toute autre personne que vous (et le root user). La phrase de passe offre une couche de protection supplémentaire dans le cas où ces conditions seraient compromises.

      L’ajout d’une phrase de passe est facultatif. Si vous en entrez une, vous devrez la saisir à chaque fois que vous utiliserez cette clé (à moins que vous utilisiez un logiciel d’agent SSH qui stocke la clé décryptée). Nous vous recommandons d’utiliser une phrase de passe. Cependant, si vous ne souhaitez pas définir une phrase de passe, il vous suffit d’appuyer sur ENTER pour contourner cette invite.

      Your identification has been saved in /home/username/.ssh/id_rsa.
      Your public key has been saved in /home/username/.ssh/id_rsa.pub.
      The key fingerprint is:
      a9:49:2e:2a:5e:33:3e:a9:de:4e:77:11:58:b6:90:26 username@remote_host
      The key's randomart image is:
      +--[ RSA 2048]----+
      |     ..o         |
      |   E o= .        |
      |    o. o         |
      |        ..       |
      |      ..S        |
      |     o o.        |
      |   =o.+.         |
      |. =++..          |
      |o=++.            |
      +-----------------+
      

      Vous disposez désormais d’une clé publique et privée que vous pouvez utiliser pour vous authentifier. L’étape suivante consiste à placer la clé publique sur votre serveur afin que vous puissiez utiliser l’authentification par clé SSH pour vous connecter.

      Si vous démarrez un nouveau serveur DigitalOcean, vous pouvez automatiquement intégrer votre clé publique SSH dans le compte root de votre nouveau serveur.

      En bas de la page de création de Droplet, une option vous permet d’ajouter des clés SSH à votre serveur :

      SSH key embed

      Si vous avez déjà ajouté un fichier de clé publique à votre compte DigitalOcean, vous la verrez apparaître comme une option sélectionnable (il y a deux clés existantes dans l’exemple ci-dessus : « Work key » et « Home key »). Pour intégrer une clé existante, cliquez dessus pour la mettre en surbrillance. Vous pouvez intégrer plusieurs clés sur un seul serveur :

      SSH key selection

      Si vous n’avez pas encore chargé de clé SSH publique sur votre compte, ou si vous souhaitez ajouter une nouvelle clé à votre compte, cliquez sur le bouton « + Add SSH Key ». Cela créera une invite :

      SSH key prompt

      Dans la case « SSH Key content », collez le contenu de votre clé publique SSH. En supposant que vous ayez généré vos clés en utilisant la méthode ci-dessus, vous pouvez obtenir le contenu de votre clé publique sur votre ordinateur local en tapant :

      cat ~/.ssh/id_rsa.pub
      
      ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDNqqi1mHLnryb1FdbePrSZQdmXRZxGZbo0gTfglysq6KMNUNY2VhzmYN9JYW39yNtjhVxqfW6ewc+eHiL+IRRM1P5ecDAaL3V0ou6ecSurU+t9DR4114mzNJ5SqNxMgiJzbXdhR+j55GjfXdk0FyzxM3a5qpVcGZEXiAzGzhHytUV51+YGnuLGaZ37nebh3UlYC+KJev4MYIVww0tWmY+9GniRSQlgLLUQZ+FcBUjaqhwqVqsHe4F/woW1IHe7mfm63GXyBavVc+llrEzRbMO111MogZUcoWDI9w7UIm8ZOTnhJsk7jhJzG2GpSXZHmly/a/buFaaFnmfZ4MYPkgJD username@example.com
      

      Collez cette valeur, dans son intégralité, dans la boîte plus grande. Dans la case « Comment (optional) », vous pouvez choisir une étiquette pour la clé. Elle apparaîtra sous le nom de clé dans l’interface DigitalOcean :

      SSH new key

      Lorsque vous créez votre Droplet, les clés SSH publiques que vous avez sélectionnées seront placées dans le fichier ~/.ssh/authorized_keys du compte de l’utilisateur root. Cela vous permettra de vous connecter au serveur à partir de l’ordinateur qui intègre votre clé privée.

      Si vous disposez déjà d’un serveur et que vous n’avez pas intégré de clés lors de la création, vous pouvez toujours charger votre clé publique et l’utiliser pour vous authentifier sur votre serveur.

      La méthode que vous allez utiliser dépendra principalement des outils dont vous disposez et des détails de votre configuration actuelle. Vous obtiendrez le même résultat final avec toutes les méthodes suivantes. La première méthode est la plus simple et la plus automatisée. Celles qui suivent nécessitent chacune des manipulations supplémentaires si vous ne pouvez pas utiliser les méthodes précédentes.

      Copier votre clé publique à l’aide de SSH-Copy-ID

      La façon la plus simple de copier votre clé publique sur un serveur existant consiste à utiliser un utilitaire appelé ssh-copy-id. En raison de sa simplicité, nous vous recommandons d’utiliser cette méthode, si elle est disponible.

      L’outil ssh-copy-id est inclus dans les paquets OpenSSH de nombreuses distributions. Vous pouvez donc en disposer sur votre système local. Pour que cette méthode fonctionne, vous devez déjà disposer d’un accès SSH à votre serveur, basé sur un mot de passe.

      Pour utiliser l’utilitaire, il vous suffit de spécifier l’hôte distant auquel vous souhaitez vous connecter et le compte utilisateur auquel vous avez accès SSH par mot de passe. Il s’agit du compte sur lequel votre clé publique SSH sera copiée.

      La syntaxe est la suivante :

      ssh-copy-id username@remote_host
      

      Il se peut que vous voyez apparaître un message similaire à celui-ci :

      The authenticity of host '111.111.11.111 (111.111.11.111)' can't be established.
      ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe.
      Are you sure you want to continue connecting (yes/no)? yes
      

      Cela signifie simplement que votre ordinateur local ne reconnaît pas l’hôte distant. Cela se produira la première fois que vous vous connecterez à un nouvel hôte. Tapez « yes » et appuyez sur ENTER (ENTRÉE) pour continuer.

      Ensuite, l’utilitaire recherchera sur votre compte local la clé id_rsa.pub que nous avons créée précédemment. Lorsqu’il trouvera la clé, il vous demandera le mot de passe du compte de l’utilisateur distant :

      /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
      /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
      username@111.111.11.111's password:
      

      Saisissez le mot de passe (votre saisie ne s’affichera pas pour des raisons de sécurité) et appuyez sur ENTER. L’utilitaire se connectera au compte sur l’hôte distant en utilisant le mot de passe que vous avez fourni. Il copiera ensuite le contenu de votre clé ~/.ssh/id_rsa.pub dans un fichier situé dans le répertoire de base ~/.ssh du compte distant appelé authorized_keys.

      Vous obtiendrez un résultat similaire à ce qui suit :

      Number of key(s) added: 1
      
      Now try logging into the machine, with:   "ssh 'username@111.111.11.111'"
      and check to make sure that only the key(s) you wanted were added.
      

      À ce stade, votre clé id_rsa.pub a été téléchargée sur le compte distant. Vous pouvez passer à la section suivante.

      Copier votre clé publique à l’aide de SSH

      Si vous ne disposez pas de ssh-copy-id, mais que vous avez un accès SSH par mot de passe à un compte sur votre serveur, vous pouvez télécharger vos clés en utilisant une méthode SSH classique.

      Nous pouvons le faire en extrayant le contenu de notre clé SSH publique sur notre ordinateur local et en l’acheminant par une connexion SSH vers le serveur distant. D’autre part, nous pouvons nous assurer que le répertoire ~/.ssh existe bien sous le compte que nous utilisons pour ensuite générer le contenu que nous avons transmis dans un fichier appelé authorized_keys dans ce répertoire.

      Nous allons utiliser le symbole de redirection >> pour ajouter le contenu au lieu d’écraser le contenu précédent. Cela nous permettra d’ajouter des clés sans détruire les clés précédemment ajoutées.

      La commande ressemblera à ceci :

      cat ~/.ssh/id_rsa.pub | ssh username@remote_host "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"
      

      Il se peut que vous voyez apparaître un message similaire à celui-ci :

      The authenticity of host '111.111.11.111 (111.111.11.111)' can't be established.
      ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe.
      Are you sure you want to continue connecting (yes/no)? yes
      

      Cela signifie simplement que votre ordinateur local ne reconnaît pas l’hôte distant. Cela se produira la première fois que vous vous connecterez à un nouvel hôte. Tapez « yes » et appuyez sur ENTER (ENTRÉE) pour continuer.

      Ensuite, vous serez invité à saisir le mot de passe du compte auquel vous tentez de vous connecter :

      username@111.111.11.111's password:
      

      Après avoir saisi votre mot de passe, le contenu de votre clé id_rsa.pub sera copié à la fin du fichier authorized_keys du compte de l’utilisateur distant. Si cela fonctionne, passez à la section suivante.

      Copier manuellement votre clé publique

      Si vous ne disposez pas d’un accès SSH à votre serveur protégé par un mot de passe, vous devrez suivre le processus décrit ci-dessus manuellement.

      Le contenu de votre fichier id_rsa.pub devra être ajouté à un fichier qui se trouvera dans ~/.ssh/authorized_keys sur votre machine distante.

      Pour afficher le contenu de votre clé id_rsa.pub, tapez ceci dans votre ordinateur local :

      cat ~/.ssh/id_rsa.pub
      

      Vous verrez le contenu de la clé de manière similaire à ceci :

      ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCqql6MzstZYh1TmWWv11q5O3pISj2ZFl9HgH1JLknLLx44+tXfJ7mIrKNxOOwxIxvcBF8PXSYvobFYEZjGIVCEAjrUzLiIxbyCoxVyle7Q+bqgZ8SeeM8wzytsY+dVGcBxF6N4JS+zVk5eMcV385gG3Y6ON3EG112n6d+SMXY0OEBIcO6x+PnUSGHrSgpBgX7Ks1r7xqFa7heJLLt2wWwkARptX7udSq05paBhcpB0pHtA1Rfz3K2B+ZVIpSDfki9UVKzT8JUmwW6NNzSgxUfQHGwnW7kj4jp4AT0VZk3ADw497M2G/12N0PPB5CnhHf7ovgy6nL1ikrygTKRFmNZISvAcywB9GVqNAVE+ZHDSCuURNsAInVzgYo9xgJDW8wUw2o8U77+xiFxgI5QSZX3Iq7YLMgeksaO4rBJEa54k8m5wEiEE1nUhLuJ0X/vh2xPff6SQ1BL/zkOhvJCACK6Vb15mDOeCSq54Cr7kvS46itMosi/uS66+PujOO+xt/2FWYepz6ZlN70bRly57Q06J+ZJoc9FfBCbCyYH7U/ASsmY095ywPsBo1XQ9PqhnN1/YOorJ068foQDNVpm146mUpILVxmq41Cj55YKHEazXGsdBIbXWhcrRf4G2fJLRcGUr9q8/lERo9oxRm5JFX6TCmj6kmiFqv+Ow9gI0x8GvaQ== demo@test
      

      Accédez à votre hôte distant en utilisant la méthode dont vous disposez. Par exemple, si votre serveur est un Droplet DigitalOcean, vous pouvez vous connecter à l’aide de la console Web disponible dans le panneau de configuration :

      Accès à la console DigitalOcean

      Une fois que vous avez accès à votre compte sur le serveur distant, vous devez vous assurer que le répertoire ~/.ssh est créé. Cette commande va créer le répertoire si nécessaire, ou ne rien faire s’il existe déjà :

      mkdir -p ~/.ssh
      

      Maintenant, vous pouvez créer ou modifier le fichier authorized_keys dans ce répertoire. Vous pouvez ajouter le contenu de votre fichier id_rsa.pub à la fin du fichier authorized_keys, en le créant si nécessaire, à l’aide de la commande suivante :

      echo public_key_string >> ~/.ssh/authorized_keys
      

      Dans la commande ci-dessus, remplacez la chaîne public_key_string par la sortie de la commande cat ~/.ssh/id_rsa.pub que vous avez exécutée sur votre système local. Elle devrait commencer par ssh-rsa AAAA....

      Si cela fonctionne, vous pouvez passer à l’authentification sans mot de passe.

      Authentification sur votre serveur à l’aide des clés SSH

      Si vous avez effectué avec succès l’une des procédures ci-dessus, vous devriez pouvoir vous connecter à l’hôte distant sans le mot de passe du compte distant.

      Le processus de base est le même :

      ssh username@remote_host
      

      Si c’est la première fois que vous vous connectez à cet hôte (si vous avez utilisé la dernière méthode ci-dessus), vous verrez peut-être quelque chose comme ceci :

      The authenticity of host '111.111.11.111 (111.111.11.111)' can't be established.
      ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe.
      Are you sure you want to continue connecting (yes/no)? yes
      

      Cela signifie simplement que votre ordinateur local ne reconnaît pas l’hôte distant. Tapez « yes » et appuyez sur ENTER pour continuer.

      Si vous n’avez pas fourni de phrase de passe pour votre clé privée, vous serez immédiatement connecté. Si vous avez configuré une phrase de passe pour la clé privée au moment de la création de la clé, vous devrez la saisir maintenant. Ensuite, une nouvelle session shell devrait être générée pour vous avec le compte sur le système distant.

      Si cela fonctionne, continuer pour savoir comment verrouiller le serveur.

      Désactiver l’authentification par mot de passe sur votre serveur

      Si vous avez pu vous connecter à votre compte en utilisant SSH sans mot de passe, vous avez réussi à configurer une authentification basée sur des clés SSH pour votre compte. Cependant, votre mécanisme d’authentification par mot de passe est toujours actif, ce qui signifie que votre serveur est toujours exposé aux attaques par force brute.

      Avant de procéder aux étapes décrites dans cette section, vérifiez que vous avez bien configuré une authentification par clé SSH pour le compte root sur ce serveur, ou de préférence, que vous avez bien configuré une authentification par clé SSH pour un compte sur ce serveur avec un accès sudo. Cette étape permettra de verrouiller les connexions par mot de passe. Il est donc essentiel de s’assurer que vous pourrez toujours obtenir un accès administratif.

      Une fois les conditions ci-dessus satisfaites, connectez-vous à votre serveur distant avec les clés SSH, soit en tant que root, soit avec un compte avec des privilèges sudo. Ouvrez le fichier de configuration du démon SSH :

      sudo nano /etc/ssh/sshd_config
      

      Dans le fichier, recherchez une directive appelée PasswordAuthentication. Elle est peut-être commentée. Décommentez la ligne et réglez la valeur sur « no ». Cela désactivera votre capacité à vous connecter avec SSH en utilisant des mots de passe de compte :

      PasswordAuthentication no
      

      Enregistrez et fermez le fichier lorsque vous avez terminé. Pour implémenter effectivement les modifications que vous venez d’apporter, vous devez redémarrer le service.

      Sur les machines Ubuntu ou Debian, vous pouvez lancer la commande suivante :

      sudo service ssh restart
      

      Sur les machines CentOS/Fedora, le démon s’appelle sshd :

      sudo service sshd restart
      

      Une fois cette étape terminée, vous avez réussi à transiter votre démon SSH de manière à ce qu’il réponde uniquement aux clés SSH.

      Conclusion

      Vous devriez maintenant avoir une authentification basée sur une clé SSH configurée et active sur votre serveur, vous permettant de vous connecter sans fournir de mot de passe de compte. À partir de là, vos options sont multiples. Si vous souhaitez en savoir plus sur SSH, consultez notre Guide des fondamentaux SSH.



      Source link

      Comment utiliser un serveur SMTP de Google


      L’auteur a choisi le COVID-19 Relief Fund pour recevoir un don dans le cadre du programme Write for DOnations.

      Introduction

      Le serveur SMTP portatif de Google est une fonctionnalité peu connue qu’intègrent les courriels de Gmail et des applications Google. Plutôt que d’avoir à gérer votre propre serveur de courriels sortants sur votre DigitalOcean Droplet ou Kubernetes Cluster, vous pouvez configurer les paramètres du serveur SMTP de Google avec n’importe quel script ou programme avec lequel vous souhaitez envoyer des courriels. Tout ce dont vous avez besoin est soit (i) un compte gratuit Gmail ou (ii) un compte payant G Suite.

      Avantages

      Vous avez la possibilité d’avoir Google Store et d’indexer les e-mails que vous envoyez via son serveur SMTP, de sorte que tous les e-mails que vous envoyez puissent être consultés et sauvegardés sur les serveurs de Google. Si vous décidez d’utiliser également votre compte Gmail ou G Suite pour vos courriels entrants, tous vos courriels se retrouveront alors dans un endroit pratique. De plus, étant donné que le serveur SMTP de Google n’utilise pas le Port 25, vous réduirez la probabilité qu’un ISP puisse bloquer votre courriel ou le baliser comme un pourriel.

      Paramètres

      Le serveur SMTP de Google nécessite une authentification. Voici donc de quelle manière le configurer dans votre client ou application de courriel :

      Remarque : avant de commencer, envisagez de trouver la cote de sécurité de votre client de courrier ou de l’application selon Google. Si vous utilisez un programme que Google ne considère pas comme sécurisé, votre utilisation sera bloquée, à moins que vous n’activiez les applications moins sécurisées (un paramètre de sécurité que Google ne recommande pas) ou que vous génériez un mot de passe App spécifique à une application. Pour plus d’informations sur la sécurité, suivez ce lien pour déterminer la meilleure approche pour votre client ou application de courrier électronique.

      1. Serveur SMTP (c’est-à-dire le serveur des courriels sortants) : [smtp.gmail.com (http://smtp.gmail.com)
      2. SMTP username : votre adresse électronique de Gmail ou G Suite complète (par exemple, example@gmail.com ou example@your_domain)
      3. SMTP password : votre mot de passe de courriel Gmail ou G Suite
      4. SMTP port : 465
      5. SMTP TLS/SSL required : oui

      Afin que Google puisse automatiquement copier les e-mails envoyés dans le dossier Messages envoyés, vous devez également vérifier que l’accès IMAP est activé pour votre compte.

      Pour ce faire, allez dans les paramètres de Gmail et cliquez sur l’onglet Transfert et POP/IMAP. Descendez à la section Accès IMAP et assurez-vous que l’accès IMAP est bien activé pour votre compte.

      Remarque : Google réécrira automatiquement la ligne From de tout courriel que vous envoyez via son serveur SMTP à l’adresse de courrier électronique par défaut associée au compte si celle utilisée n’est pas sur la liste d’adresses Send mail as dans les paramètres de Gmail ou G Suite. Vous pouvez vérifier la liste en allant sur l’onglet Comptes et Importation de l’écran des paramètres.

      Vous devez être conscient de cette nuance car elle affecte la présentation de votre courrier électronique au destinataire et cela peut également affecter la configuration de Répondre à de certains programmes.

      Limites d’envoi

      Google limite la quantité de courriels qu’un utilisateur peut envoyer via son serveur SMTP portatif. Cette limite restreint le nombre de messages envoyés par jour à 99 courriels. La restriction est automatiquement levée 24 heures après que la limite est atteinte.

      Conclusion

      Vous avez maintenant la possibilité d’utiliser le serveur SMTP de Google. Si cette option légère n’est pas suffisante, vous pouvez envisager d’installer et de configurer postfix comme un serveur SMTP pour envois seulement.



      Source link

      Comprendre le serveur Nginx et les algorithmes de sélection de blocs de localisation


      Introduction

      Nginx fait partie des serveurs Web les plus populaires au monde. C’est avec succès qu’il peut gérer de grandes charges avec plusieurs connexions clients concurrentes et être facilement utilisé comme un serveur web, un serveur de courrier ou un serveur proxy inverse.

      Dans ce guide, nous allons traiter de quelques-uns des détails en coulisses qui déterminent la manière dont Nginx traite les requêtes clients. En ayant une compréhension de ces idées, vous n’aurez plus à faire autant de devinettes quant à la conception du serveur et des blocs de localisation et vous serez alors en mesure de rendre la manipulation des requêtes moins imprévisible.

      Configurations de bloc Nginx

      Nginx divise de manière logique les configurations destinées à servir différents contenus dans des blocs qui se trouvent dans une structure hiérarchique. Chaque fois qu’un client fait une requête, Nginx entame un processus pour sélectionner les blocs de configuration qui seront utilisés pour gérer la requête. C’est ce processus de décision que nous allons aborder dans ce guide.

      Les principaux blocs que nous allons aborder sont les suivants : le bloc server et le bloc location.

      Un bloc de serveur est un sous-ensemble de la configuration de Nginx qui définit le serveur virtuel avec lequel les requêtes d’un type donné seront gérées. Les administrateurs configurent souvent plusieurs blocs de serveur et décident ensuite du bloc qui sera chargé de la connexion en fonction du nom du domaine, du port et de l’adresse IP demandés.

      Un bloc de localisation se trouve dans un bloc de serveur. Il permet de définir la façon dont Nginx doit gérer les requêtes pour différentes ressources et URI du serveur parent. L’administrateur peut subdiviser l’espace URI de toutes les manières qu’il le souhaite en utilisant ces blocs. Il s’agit d’un modèle extrêmement flexible.

      Étant donné que Nginx permet à l’administrateur de définir plusieurs blocs de serveur qui fonctionnent comme des instances de serveur virtuel distinctes, il lui faut une procédure qui lui permette de déterminer lesquels de ces blocs utiliser pour satisfaire une requête.

      Pour cela, il passe par un système de vérifications utilisées pour trouver la meilleure correspondance possible. Les directives de bloc de serveur principal que Nginx prend en considération pendant ce processus sont les directives listen et server_name.

      Analyser la directive « listen » pour trouver des correspondances possibles

      Tout d’abord, Nginx examine l’adresse IP et le port de la requête. Il les fait ensuite correspondre avec la directive listen de chaque serveur pour créer une liste des blocs du serveur qui peuvent éventuellement résoudre la requête.

      La directive listen définit généralement l’adresse IP et le port auxquels le bloc de serveur répondra. Par défaut, tout bloc de serveur qui n’inclut pas une directive listen se voit attribuer les paramètres d’écoute de 0.0.0.0:80 (ou 0.0.0.0:8080 si Nginx est exécuté par un non-root user normal). Ces blocs peuvent ainsi répondre aux requêtes sur toute interface sur le port 80. Mais cette valeur par défaut n’a pas beaucoup de poids dans le processus de sélection de serveur.

      La directive listen peut être configurée sur :

      • Un combo adresse IP/port.
      • Une adresse IP unique qui écoutera ensuite le port 80 par défaut.
      • Un port unique qui écoutera chaque interface sur ce port.
      • Le chemin vers une socket Unix.

      La dernière option aura généralement des implications lorsque les requêtes passeront entre les différents serveurs.

      Lorsque Nginx tentera de déterminer le bloc de serveur qui enverra une requête, il tentera d’abord de décider en fonction de la spécificité de la directive listen en utilisant les règles suivantes :

      • Nginx traduit toutes les directives listen « incomplètes » en substituant les valeurs manquantes par leurs valeurs par défaut afin que chaque bloc puisse être évalué par son adresse IP et son port. Voici quelques exemples de ces traductions :
        • Un bloc sans directive listen utilise la valeur 0.0.0.0:80.
        • Un bloc configuré sur une adresse IP 111.111.111.111 sans aucun port devient 111.111.111.111:80
        • Un bloc configuré sur le port 8888 sans adresse IP devient 0.0.0.0:8888
      • Nginx tente ensuite de recueillir une liste des blocs du serveur qui correspondent à la requête de manière plus spécifique en fonction de l’adresse IP et du port. Cela signifie que tout bloc qui utilise fonctionnellement son adresse IP 0.0.0.0 (pour correspondre à toute interface) ne sera pas sélectionné s’il existe des blocs correspondants qui répertorient une adresse IP spécifique. Dans tous les cas, la correspondance avec le port doit être exacte.
      • S’il n’existe qu’une correspondance plus spécifique, la requête sera servie par ce bloc de serveur. En présence de plusieurs blocs de serveur avec le même niveau de spécificité, Nginx commence ensuite à évaluer la directive server_name de chaque bloc de serveur.

      Il est important de comprendre que Nginx évaluera la directive server_name uniquement au moment où il devra faire la distinction entre les blocs de serveur qui correspondent au même niveau de spécificité dans la directive listen. Par exemple, si example.com est hébergé sur le port 80 de 192.168.1.10, le premier bloc servira toujours la requête example.com de cet exemple, malgré la présence de la directive server_name dans le second bloc.

      server {
          listen 192.168.1.10;
      
          . . .
      
      }
      
      server {
          listen 80;
          server_name example.com;
      
          . . .
      
      }
      

      Dans le cas où plusieurs blocs de serveur correspondent à une spécificité égale, l’étape suivante consistera à vérifier la directive server_name.

      Analyser la directive « server_name » pour choisir une correspondance

      Ensuite, pour évaluer les requêtes qui disposent de directives listen également spécifiques, Nginx vérifie l’en-tête « Host » de la requête. Cette valeur contient le domaine ou l’adresse IP que le client a réellement tenté d’atteindre.

      Nginx tente de trouver la meilleure correspondance pour la valeur qu’il trouve en examinant la directive server_name dans chacun des blocs de serveur toujours sélectionnés. Nginx les évalue en utilisant la formule suivante :

      • Nginx tentera d’abord de trouver un bloc de serveur avec un server_name qui correspond à la valeur dans l’en-tête « Host » de la requête exactly. S’il la trouve, la requête sera servie par le bloc associé. S’il trouve plusieurs correspondances exactes, la première est utilisée.
      • S’il ne trouve aucune correspondance exacte, Nginx tentera ensuite de trouver un bloc de serveur avec un server_name correspondant à l’aide d’un métacaractère principal (indiqué par un * au début du nom dans la config). S’il en trouve un, la requête sera servie par ce bloc. S’il trouve plusieurs correspondances, la requête sera servie par la correspondance longest.
      • S’il ne trouve aucune correspondance en utilisant un métacaractère principal, Nginx recherchera ensuite un bloc de serveur avec un server_name correspondant à l’aide d’un métacaractère secondaire (indiqué par un nom de serveur qui se termine par un * dans la config). S’il en trouve un, la requête sera servie par ce bloc. S’il trouve plusieurs correspondances, la requête sera servie par la correspondance longest.
      • S’il ne trouve aucune correspondance en utilisant un métacaractère secondaire, Nginx évalue ensuite les blocs de serveur qui définissent le server_name en utilisant des expressions régulières (indiquées par un ~ avant le nom). Le first server_name avec une expression régulière qui correspond à l’en-tête « Host » sera utilisé pour servir la requête.
      • S’il ne trouve aucune correspondance d’expression régulière, Nginx sélectionne alors le bloc de serveur par défaut pour l’adresse IP et le port en question.

      Chaque combo adresse IP/port est doté d’un bloc de serveur par défaut qui sera utilisé lorsqu’aucun cours d’action ne pourra pas être déterminé avec les méthodes ci-dessus. Pour un combo adresse IP/port, il s’agira soit du premier bloc de la configuration ou du bloc qui contient l’option default_server dans la directive listen (qui remplacera le premier algorithme trouvé). Il ne peut y avoir qu’une seule déclaration default_server pour chaque combinaison adresse IP/port.

      Exemples

      S’il existe un server_name défini qui correspond exactement à la valeur de l’en-tête « Host », ce bloc de serveur sera sélectionné pour traiter la requête.

      Dans cet exemple, si l’en-tête « Host » de la requête est configuré sur « host1.example.com », c’est le second serveur qui sera sélectionné :

      server {
          listen 80;
          server_name *.example.com;
      
          . . .
      
      }
      
      server {
          listen 80;
          server_name host1.example.com;
      
          . . .
      
      }
      

      S’il ne trouve aucune correspondance exacte, Nginx vérifie alors s’il existe un server_name qui commence avec un métacaractère qui convient. Ce sera la correspondance la plus longue et qui commence par un métacaractère qui sera sélectionnée pour répondre à la requête.

      Dans cet exemple, si l’en-tête de la requête indique « Host » pour « www.example.org », c’est le second bloc de serveur qui sera sélectionné :

      server {
          listen 80;
          server_name www.example.*;
      
          . . .
      
      }
      
      server {
          listen 80;
          server_name *.example.org;
      
          . . .
      
      }
      
      server {
          listen 80;
          server_name *.org;
      
          . . .
      
      }
      

      S’il ne trouve aucune correspondance qui commence par un métacaractère, Nginx verra alors s’il existe une correspondance en utilisant un métacaractère à la fin de l’expression. À ce stade, la requête sera servie par la correspondance la plus longue et qui contient un métacaractère.

      Par exemple, si l’en-tête de la requête est configuré sur « www.example.com », ce sera le troisième bloc de serveur qui sera sélectionné :

      server {
          listen 80;
          server_name host1.example.com;
      
          . . .
      
      }
      
      server {
          listen 80;
          server_name example.com;
      
          . . .
      
      }
      
      server {
          listen 80;
          server_name www.example.*;
      
          . . .
      
      }
      

      S’il ne trouve aucune correspondance avec un métacaractère, Nginx tentera alors de faire correspondre les directives server_name qui utilisent des expressions régulières. C’est la first expression régulière correspondante qui sera sélectionnée pour répondre à la requête.

      Par exemple, si l’en-tête « Host » de la requête est configuré sur « www.example.com », c’est alors le second serveur qui sera sélectionné pour satisfaire la requête :

      server {
          listen 80;
          server_name example.com;
      
          . . .
      
      }
      
      server {
          listen 80;
          server_name ~^(www|host1).*.example.com$;
      
          . . .
      
      }
      
      server {
          listen 80;
          server_name ~^(subdomain|set|www|host1).*.example.com$;
      
          . . .
      
      }
      

      Si aucune des étapes ci-dessus ne permet de satisfaire la requête, la requête sera alors transmise au serveur par default de l’adresse IP et le port correspondants.

      Mise en correspondance des blocs de localisation

      Tout comme le processus que Nginx utilise pour sélectionner le bloc de serveur qui traitera une requête, Nginx dispose également d’un algorithme établi pour décider du bloc de localisation du serveur qui servira au traitement des requêtes.

      Syntaxe de bloc de localisation

      Avant de voir de quelle manière Nginx procède pour décider du bloc de localisation qui sera utilisé pour traiter les requêtes, étudions un peu la syntaxe que vous êtes susceptible de rencontrer dans les définitions de bloc de localisation. Les blocs de localisation se trouvent dans les blocs serveur (ou autresblocs de localisation) et servent à décider de quelle manière traité l’URl de la requête (la partie de la demande qui se trouve après le nom du domaine ou l’adresse IP/port).

      Les blocs de localisation ont généralement cette forme :

      location optional_modifier location_match {
      
          . . .
      
      }
      

      Le location_match ci-dessus définit avec quel élément Nginx devrait comparer l’URl de la requête. Dans l’exemple ci-dessus, l’existence ou l’absence du modificateur affecte la façon dont Nginx tente de faire correspondre le bloc de localisation. Les modificateurs donnés ci-dessous entraîneront l’interprétation suivante du bloc de localisation associé :

      • (none) : si aucun modificateur n’est présent, l’emplacement est interprété comme une correspondance de prefix. Cela signifie que la localisation donnée sera comparée avec le début de l’URI de la requête pour voir s’il y a une correspondance.
      • = : si le signe égal est utilisé, ce bloc sera considéré comme une correspondance si l’URI de la requête correspond exactement à la localisation indiquée.
      • ~ : la présence d’un modificateur tilde indique que cet emplacement sera interprété comme une correspondance d’expression régulière sensible à la casse.
      • ~* : si un modificateur tilde et astérisque est utilisé, le bloc de localisation sera interprété comme une correspondance d’expression régulière insensible à la casse.
      • ^~ : si un modificateur de carat et tilde est présent et que ce bloc est sélectionné comme la meilleure correspondance d’expression non régulière, la mise en correspondance des expressions régulières n’aura pas lieu.

      Exemples de la syntaxe d’un bloc de localisation

      Pour vous donner un exemple de correspondance de préfixe, vous pouvez sélectionner le bloc de localisation suivant pour répondre aux URl de requête qui ressemblent à /site, /site/page1/index.html ou /site/index.html:

      location /site {
      
          . . .
      
      }
      

      Pour démontrer une correspondance exacte de l’URI, ce bloc sera toujours utilisé pour répondre à une URI de la requête qui ressemble à /page1. Il ne sera pas utilisé pour répondre à une URI de requête /page1/index.html. N’oubliez pas que, si ce bloc est sélectionné et que la requête est renseignée à l’aide d’une page d’index, le système procédera à une redirection interne vers un autre emplacement qui correspondra au gestionnaire réel de la requête :

      location = /page1 {
      
          . . .
      
      }
      

      Pour vous donner un exemple du type de localisation qui doit être interprétée comme une expression régulière sensible à la casse, vous pouvez utiliser ce bloc pour gérer les requêtes de /tortoise.jpg, mais pas pour /FLOWER.PNG :

      location ~ .(jpe?g|png|gif|ico)$ {
      
          . . .
      
      }
      

      Voici un bloc qui permettrait de faire une mise en correspondance insensible à la casse similaire à ce qui précède : Ici, ce bloc peut gérer /tortoise.jpg et /FLOWER.PNG à la fois :

      location ~* .(jpe?g|png|gif|ico)$ {
      
          . . .
      
      }
      

      Enfin, ce bloc empêchera l’affichage de la correspondance avec l’expression régulière, s’il est configuré de manière à être mis en correspondance avec la meilleure expression non régulière. Il peut gérer les requêtes de /costumes/ninja.html :

      location ^~ /costumes {
      
          . . .
      
      }
      

      Comme vous le voyez, les modificateurs indiquent de quelle manière le bloc de localisation doit être interprété. Cependant, cela ne nous indique pas l’algorithme que Nginx utilise pour décider du bloc de localisation qui enverra la requête. C’est ce que nous allons voir maintenant.

      Nginx choisit la localisation qui sera utilisée pour servir une requête de manière similaire à la façon dont il sélectionne un bloc de serveur. Il passe par un processus qui détermine le meilleur bloc de localisation pour toute requête donnée. Il est vraiment crucial d’avoir une bonne compréhension de ce processus afin de pouvoir configurer Nginx de manière fiable et précise.

      Tout en gardant à l’esprit les types de déclarations de localisation que nous avons décrites ci-dessus, Nginx évalue les contextes de localisation possibles en comparant l’URI de la requête avec chacun des emplacements. Pour cela, il utilise l’algorithme suivant :

      • Nginx commence par vérifier tous les correspondances de localisation sur la base des préfixes (tous les types de localisation qui n’impliquent pas une expression régulière). Il vérifie chaque localisation en fonction de l’URI complet de la requête.
      • Nginx recherche tout d’abord une correspondance exacte. S’il trouve qu’un bloc de localisation qui utilise le modificateur = correspond exactement à l’URI de la requête, ce bloc de localisation est immédiatement sélectionné pour servir la requête.
      • S’il ne trouve aucun bloc de localisation (avec le modificateur =) qui corresponde exactement, Nginx passe alors à l’évaluation des préfixes inexacts. Il trouve la localisation préfixée la plus longue qui correspond à l’URI de la requête donnée, qu’il évalue ensuite de la manière suivante :
        • Si la localisation préfixée la plus longue correspondante contient le modificateur ^~, Nginx arrête immédiatement sa recherche et sélectionnera cette localisation pour servir la requête.
        • Si la localisation préfixée la plus longue correspondante n’utilise pas le modificateur ^~, Nginx enregistre la correspondance pour le moment afin que le focus de la recherche puisse être déplacé.
      • Après avoir déterminé et stocké la localisation préfixée la plus longue correspondante, Nginx passe à l’évaluation des localisations d’expressions régulières (à la fois sensible et insensible à la casse). S’il existe des localisations d’expression régulière à l’intérieur de la localisation préfixée la plus longue correspondante, Nginx les déplacera en haut de la liste des localisations de regex pour procéder à une vérification. Nginx tente ensuite de faire une correspondance avec les localisations d’expression régulières de manière séquentielle. La première localisation d’expressions régulières qui correspond à l’URI de la requête est immédiatement sélectionnée pour servir la requête.
      • S’il ne trouve aucune localisation d’expressions régulières qui corresponde à l’URI de la requête, la localisation préfixée précédemment stockée sera alors sélectionnée pour servir la requête.

      Il est important de comprendre que, par défaut, Nginx préférera servir des correspondances d’expression régulière que des correspondances de préfixe. Cependant, il évalue d’abord les localisations préfixées pour que l’administration puisse écraser cette tendance en spécifiant les localisations avec les modificateurs = et ^~.

      Il est également important de noter que bien que les localisations préfixées sont généralement sélectionnées en fonction de la correspondance la plus spécifique et la plus longue, l’évaluation des expressions régulières s’arrête une fois que la première localisation correspondante est trouvée. Cela signifie que, dans la configuration, le positionnement a un grand impact sur les localisations d’expressions régulières.

      Pour finir, il est important de comprendre que les correspondances d’expressions régulières dans la correspondance de préfixe la plus longue « sauteront la ligne » lorsque Nginx procédera à l’évaluation des localisations de regex. Il procédera à l’évaluation de ces éléments, dans l’ordre, avant même qu’une des autres correspondances d’expression régulière ne soit prise en considération. Dans cet article, Maxim Dounin, un développeur Nginx incroyablement enrichissant, nous explique cette partie de l’algorithme de sélection.

      À quel moment l’évaluation des blocs de localisation passe-t-elle à d’autres localisations ?

      En règle générale, lorsqu’un bloc de localisation est sélectionné pour servir une requête, l’intégralité de la requête est traitée dans ce même contexte à partir de ce moment-là. Seules la localisation sélectionnée et les directives héritées déterminent de quelle manière la requête est traitée, sans que les blocs de localisation apparentés ne viennent interférer.

      Bien qu’il s’agisse d’une règle générale qui vous permettra de concevoir vos blocs de localisation de manière prévisible, il est important que vous sachiez que, parfois, certaines directives dans la localisation sélectionnée déclenchent une nouvelle recherche de localisation. Les exceptions à la règle « seulement un bloc de localisation » peuvent avoir un impact sur la façon dont la requête est effectivement servie et ne seront pas en accord avec les attentes que vous aviez lors de la conception de vos blocs de localisation.

      Voici quelques-unes des directives qui peuvent conduire à ce type de redirection interne :

      • index
      • try_files
      • rewrite
      • error_page

      Examinons-les brièvement.

      La directive index entraîne toujours une redirection interne si elle est utilisée pour gérer la requête. Les correspondances de localisation exactes permettent souvent d’accélérer le processus de sélection en mettant immédiatement fin à l’exécution de l’algorithme. Cependant, si vous effectuez une correspondance de localisation exacte qui est un répertoire, il est possible que la requête soit redirigée vers un autre emplacement pour le traitement en tant que tel.

      Dans cet exemple, la mise en correspondance de la première localisation se fait par un URI de requête /exact, mais pour gérer la requête, la directive index héritée du bloc initialise une redirection interne vers le second bloc :

      index index.html;
      
      location = /exact {
      
          . . .
      
      }
      
      location / {
      
          . . .
      
      }
      

      Dans le cas précédent, si vous souhaitez vraiment que l’exécution reste dans le premier bloc, il vous faudra trouver un moyen différent de satisfaire la requête au répertoire. Par exemple, vous pouvez configurer un index non valide pour ce bloc et activer autoindex :

      location = /exact {
          index nothing_will_match;
          autoindex on;
      }
      
      location  / {
      
          . . .
      
      }
      

      Il s’agit d’un moyen d’empêcher un index de changer de contexte, mais il n’est probablement pas si pratique pour la plupart des configurations. Une correspondance exacte sur les répertoires vous permet la plupart du temps de réécrire la requête par exemple (ce qui peut également générer une nouvelle recherche de localisation).

      Il existe également une autre instance dans laquelle la localisation de traitement peut être réévaluée, avec la directive try_files Cette directive indique à Nginx de vérifier s’il existe un ensemble de fichiers ou de répertoires nommés. Le dernier paramètre peut être un URI vers lequel Nginx procédera à une redirection interne.

      Prenons le cas de la configuration suivante :

      root /var/www/main;
      location / {
          try_files $uri $uri.html $uri/ /fallback/index.html;
      }
      
      location /fallback {
          root /var/www/another;
      }
      

      Dans l’exemple ci-dessus, si une requête est exécutée pour /blahblah, la première localisation obtiendra initialement la requête. Il tentera de trouver un fichier nommé blahblah dans le répertoire /var/www/main. S’il ne peut en trouver, il redirigera sa recherche sur un fichier nommé blahblah.html. Il tentera ensuite de voir s’il existe un répertoire appelé blahblah/ dans le répertoire /var/www/main. Si toutes ces tentatives son un échec, il se redirigera vers /fallback/index.html. Cela déclenchera une autre recherche de localisation que le deuxième bloc de localisation détectera. Cela servira le fichier /var/www/another/fallback/index.html.

      La directive rewrite est également une des autres directives qui permettent de passer un bloc de localisation. Lorsque Nginx utilise le paramètre last avec la directive rewrite, ou n’utilise aucun paramètre du tout, il recherchera une nouvelle localisation correspondante en fonction des résultats de la réécriture.

      Par exemple, si nous modifions le dernier exemple pour y inclure une réécriture, nous pouvons voir que la requête est parfois transmise directement à la seconde localisation sans s’appuyer sur la directive try_files :

      root /var/www/main;
      location / {
          rewrite ^/rewriteme/(.*)$ /$1 last;
          try_files $uri $uri.html $uri/ /fallback/index.html;
      }
      
      location /fallback {
          root /var/www/another;
      }
      

      Dans l’exemple ci-dessus, une requête /rewriteme/hello sera initialement gérée par le premier bloc de localisation. Elle sera réécrite /hello, puis la recherche de la localisation sera déclenchée. Dans ce cas, elle correspondra à nouveau à la première localisation et sera traité par le try_files comme d’habitude, peut même redirigé sur /fallback/index.html si la recherche est infructueuse (en utilisant la redirection interne try_files discutée plus haut).

      Cependant, si une requête /rewriteme/fallback/hello est effectuée, le premier bloc sera à nouveau une correspondance. La réécriture est à nouveau appliquée, ce qui génère cette fois-ci /fallback/hello. La requête sera ensuite servie par le second bloc de localisation.

      La situation est connexe avec la directive return lorsque vous envoyez les codes de statut 301 ou 302. La différence ici est que la requête obtenue et une requête entièrement nouvelle qui prend la forme d’une redirection visible à l’extérieur. Cette même situation peut se produire avec la directive rewrite si vous utilisez les balises redirect ou permanent. Cependant, ces recherches de localisation ne devraient pas être fortuites, car les redirections visibles en externe entraînent toujours une nouvelle requête.

      La directive error_page peut générer une redirection interne similaire à celle créée par try_files. Cette directive permet de définir ce qui devrait se passer si le système rencontre certains codes de statut. Cela ne sera probablement jamais exécuté si try_files est configuré. En effet, cette directive gère l’intégralité du cycle de vie d’une requête.

      Prenons l’exemple suivant :

      root /var/www/main;
      
      location / {
          error_page 404 /another/whoops.html;
      }
      
      location /another {
          root /var/www;
      }
      

      Chaque requête (autres que celles qui commencent par /another) sera traitée par le premier bloc, qui servira les fichiers /var/www/main. Cependant, si un fichier est introuvable (un statut 404), vous verrez se produire une redirection interne vers /another/whoops.html, générant une nouvelle recherche de localisation qui attérira éventuellement sur le second bloc. Ce fichier sera servi à partir de /var/www/another/whoops.html.

      Comme vous pouvez le voir, en comprenant les circonstances dans lesquelles Nginx déclenche une recherche de nouvelle localisation, vous serez plus à même de prévoir le comportement que vous verrez lorsque vous ferez des requêtes.

      Conclusion

      Le fait de comprendre de quelle manière Nginx traite les requêtes clients peut vraiment vous faciliter la tâche en tant qu’administrateur. Vous pourrez savoir quel bloc de serveur Nginx sélectionnera en fonction de chaque requête clients. Vous pourrez également deviner de quelle manière le bloc de localisation sera sélectionné en fonction de l’URI de la requête. Dans l’ensemble, en sachant de quelle manière Nginx sélectionne les différents blocs, vous serez en capacité de reconnaître les contextes que Nginx appliquera pour servir chaque requête.



      Source link