One place for hosting & domains

      configurer

      Comment lire et configurer les variables d’environnement et de shell sous Linux


      Introduction

      Au cours d’une interaction avec votre serveur via une session shell, shell compile de nombreuses informations pour déterminer son comportement et accéder aux ressources. Certains de ces réglages se font dans les paramètres de configuration, d’autres doivent être saisis par l’utilisateur.

      Le shell assure notamment le suivi de tous ces paramètres et ces détails par le biais d’une zone qu’il gère, appelée environnement. L’environnement est une zone que le shell construit à chaque fois qu’il démarre une session qui contient des variables définissant les propriétés du système.

      Dans ce guide, nous allons voir de quelle manière interagir avec l’environnement, lire ou configurer les variables d’environnement et de shell de manière interactive et via les fichiers de configuration.

      Chaque fois qu’une session shell est lancée, un processus est mis en place pour collecter et rassembler les informations qui devraient être à la disposition du processus shell et de ses processus enfant. Il obtient les données de ces paramètres à partir d’un grand nombre de fichiers et paramètres différents qui se trouvent sur le système.

      L’environnement fournit un moyen par lequel le processus shell peut obtenir ou configurer les paramètres et, à son tour, les transmettre à ses processus enfant.

      L’environnement est implémenté en tant que chaînes qui représentent des paires de valeurs clé. Si la transmission comporte plusieurs valeurs, elles sont généralement séparées par un :. Chaque paire ressemblera généralement à ceci :

      KEY=value1:value2:...
      

      Si la valeur contient un white-space significatif, des guillemets sont utilisés :

      KEY="value with spaces"
      

      Dans ces scénarios, les clés sont des variables. Elles peuvent être de deux types différents : les variables d’environnement ou les variables de shell.

      Les variables d’environnement sont des variables qui sont définies pour le shell en cours d’utilisation et héritées par tous les shells ou processus enfant. Les variables d’environnement servent à transmettre des informations dans les processus qui se déclenchent depuis le shell.

      Les variables de shell sont des variables qui sont exclusivement contenues dans le shell dans lequel elles ont été configurées ou définies. Elles sont couramment utilisées pour garder un suivi des données éphémères, comme le répertoire actuellement utilisé.

      Par convention, ces types de variables sont généralement définis par des majuscules. Cela aide les utilisateurs à distinguer les variables d’environnement dans d’autres contextes.

      Impression des variables de shell et d’environnement

      Chaque session de shell garde une trace de ses propres variables de shell et d’environnement. Nous pouvons y accéder de différentes façons.

      Nous pouvons voir une liste de toutes nos variables d’environnement en utilisant les commandes env ou printenv. Dans leur état par défaut, elles devraient fonctionner exactement de la même manière :

      Output

      SHELL=/bin/bash TERM=xterm USER=demouser LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:ca:... MAIL=/var/mail/demouser PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games PWD=/home/demouser LANG=en_US.UTF-8 SHLVL=1 HOME=/home/demouser LOGNAME=demouser LESSOPEN=| /usr/bin/lesspipe %s LESSCLOSE=/usr/bin/lesspipe %s %s _=/usr/bin/printenv

      Ceci est assez typique pour la sortie à la fois de printenv et env. La différence entre les deux commandes ne se voit que dans leur fonctionnalité plus spécifique. Par exemple, avec printenv, vous pouvez demander les valeurs de variables individuelles :

      Output

      /bin/bash

      En revanche, env vous permet de modifier l'environnement dans lequel les programmes s'exécutent en transmettant un ensemble de définitions de variables par le biais d'une commande, de la manière suivante :

      • env VAR1="value" command_to_run command_options

      Étant donné que, comme nous l'avons appris précédemment, les processus enfant héritent généralement des variables d'environnement du processus parent, vous pouvez remplacer les valeurs ou ajouter des variables supplémentaires à l'enfant.

      Comme vous pouvez le constater à partir du résultat de notre commande printenv, de nombreuses variables d'environnement sont configurées par les fichiers et les processus de notre système sans rien à saisir.

      Ces dernières montrent les variables d'environnement, mais comment consulter les variables de shell ?

      Pour cela, vous pouvez utiliser la commande set. Si nous saisissons set sans aucun autre paramètre, nous obtiendrons une liste de toutes les variables de shell, variables d'environnement, variables locales et fonctions de shell :

      Output

      BASH=/bin/bash BASHOPTS=checkwinsize:cmdhist:expand_aliases:extglob:extquote:force_fignore:histappend:interactive_comments:login_shell:progcomp:promptvars:sourcepath BASH_ALIASES=() BASH_ARGC=() BASH_ARGV=() BASH_CMDS=() . . .

      On se retrouve généralement avec une énorme liste. Il est vivement conseillé de les intégrer dans un programme de pagination afin de pouvoir traiter la quantité de résultats obtenus plus facilement :

      La quantité d'informations supplémentaires que nous recevons est quelque peu déroutante. Nous n'avons probablement pas à connaître toutes les fonctions de bash configurées, par exemple.

      Nous pouvons nettoyer le résultat en spécifiant que set devrait s'exécuter en mode POSIX, ce qui n'imprimera pas les fonctions de shell. Nous pouvons l'exécuter dans un sous-shell pour qu'il ne change pas notre environnement actuel :

      Vous obtiendrez ainsi une liste de toutes les variables d'environnement et de shell configurées.

      Nous pouvons tenter de comparer ce résultat avec celui obtenu avec les commandes env ou printenv afin d'obtenir une liste des variables de shell uniquement, mais cela risque d'être imparfait en raison des différentes façons dont ces commandes renverront les informations :

      • comm -23 <(set -o posix; set | sort) <(env | sort)

      Il est probable que la liste contienne encore quelques variables d'environnement, car la commande set déclenche les valeurs citées, tandis que les commandes printenv et env ne citent pas les valeurs des chaînes de caractères.

      Cela devrait vous donner une bonne idée des variables d'environnement et de shell qui se trouvent dans votre session.

      Ces variables sont utilisées pour toute sorte de choses. Elles vous offrent une alternative pour configurer des valeurs persistantes pour la session entre les processus, sans avoir à écrire les modifications sur un fichier.

      Variables d'environnement et de shell communes

      Certaines variables d'environnement et de shell sont très utiles et souvent référencées. Voici quelques variables d'environnement communes que vous allez rencontrer :

      • SHELL : cette variable décrit le shell qui interprétera les commandes que vous saisissez. Dans la plupart des cas, il s'agira de bash par défaut, mais d'autres valeurs peuvent être configurées si vous préférez utiliser d'autres options.
      • TERM : cette variable spécifie le type de terminal à émuler à l'exécution du shell. Il est possible d'émuler différents terminaux de matériel pour différentes exigences d'exploitation. Cependant, de manière générale, vous n'aurez pas à vous soucier de cela.
      • USER : l'utilisateur actuellement connecté.
      • PWD : le répertoire de travail en cours d'exécution.
      • OLDPWD : le précédent répertoire utilisé. Il est conservé par le shell afin de pouvoir revenir au précédent répertoire en exécutant cd-.
      • LS_COLORS : cette variable définit les codes de couleurs qui vous servent à ajouter une couleur aux résultats obtenus avec la commande ls. Elle vous permet de distinguer les différents types de fichiers et donne de plus amples informations à l'utilisateur en un coup d'œil.
      • MAIL : le chemin vers la boîte de réception de l'utilisateur en cours.
      • PATH : une liste des répertoires que le système vérifiera lorsque vous recherchez des commandes. Lorsqu'un utilisateur saisit une commande, le système vérifiera les répertoires dans cet ordre pour l'exécutable.
      • LANG : les paramètres actuels de langue et de localisation, y compris le codage de caractères.
      • HOME : le répertoire d'accueil de l'utilisateur actuellement connecté.
      • _ : la plus récente des précédentes commandes exécutées.

      En plus de ces variables d'environnement, vous verrez souvent les variables de shell suivantes :

      • BASHOPTS : la liste des options qui ont été utilisées lorsque bash a été exécuté. Cette variable peut s'avérer utile pour savoir si l'environnement de shell fonctionne de la manière dont vous le souhaitez.
      • BASH_VERSION : la version de bash en cours d'exécution, dans un format lisible par l'humain.
      • BASH_VERSINFO : la version de bash en cours d'exécution, dans un format lisible par une machine.
      • COLUMNS : le nombre de colonnes larges qui servent à dessiner le résultat à l'écran.
      • DIRSTACK : la pile des répertoires qui sont disponibles avec les commandes pushd et popd.
      • HISTFILESIZE : le nombre de lignes d'historique de commande enregistrées dans un fichier.
      • HISTSIZE : le nombre de lignes d'historique de commandes autorisées en mémoire.
      • HOSTNAME :le nom d'hôte de l'ordinateur du moment.
      • IFS : le séparateur de champ interne utilisé pour séparer les entrées sur la ligne de commande. Un espace est utilisé par défaut.
      • PS1 : la configuration de l'invite de la commande principale. Cette variable sert à définir à quoi ressemble votre invite lorsque vous commencez une session de shell. La variable PS2 permet de déclarer des invites secondaires lorsqu'une commande s'étend sur plusieurs lignes.
      • SHELLOPTS : les options de shell qui peuvent être configurées avec l'option set.
      • UID : l'IUD de l'utilisateur actuellement connecté.

      Configuration des variables de shell et d'environnement

      Pour vous aider à mieux comprendre la différence entre les variables de shell et les variables d'environnement et vous présenter la syntaxe à utiliser pour ces variables, nous allons faire une petite démonstration.

      Création de variables de shell

      Nous allons commencer par configurer une variable de shell dans notre session en cours. Ceci est facile à réaliser, nous n'avons qu'à spécifier un nom et une valeur. Nous allons adhérer à la convention qui consiste à utiliser uniquement des majuscules pour le nom de la variable et à la configurer sur une chaîne simple.

      Ici, nous avons utilisé des guillemets, car la valeur de notre variable contient un espace. De plus, nous avons utilisé des guillemets simples, car le point d'exclamation est un caractère spécial dans le shell bash qui se développe généralement en historique bash si on n'en sort pas ou s'il n'est pas mis entre des guillemets simples.

      Nous disposons maintenant d'une variable de shell. Cette variable est disponible dans notre session en cours, mais elle ne sera pas transmise aux processus enfant.

      Nous pouvons voir cela en recherchant notre nouvelle variable dans le résultat de set :

      Output

      TEST_VAR='Hello World!'

      Nous pouvons vérifier s'il ne s'agit pas d'une variable d'environnement en essayant la même méthode avec printenv :

      Aucun résultat ne devrait être renvoyé.

      Utilisons cela comme une opportunité de présenter un moyen d'accéder à la valeur de toute variable de shell ou d'environnement.

      Output

      Hello World!

      Comme vous pouvez le voir, vous faites référence à la valeur d'une variable en la faisant précéder d'un signe $. Le shell considère que cela signifie qu'il devrait substituer la valeur de la variable lorsqu'il la rencontre.

      Nous disposons donc maintenant d'une variable de shell. Elle ne devrait être transmise à aucun processus enfant. Nous pouvons générer un shell bash new à partir de notre shell actuel pour le démontrer :

      Si nous saisissons bash pour générer un shell enfant, puis tentons d'accéder ensuite au contenu de la variable, aucun résultat ne sera renvoyé. C'est ce à quoi nous nous attendions.

      Revenont à notre shell d'origine en saisissant exit :

      Création de variables d'environnement

      Maintenant, transformons notre variable de shell en variable d'environnement. Pour se faire, il faut exporter la variable. La commande qui permet de le faire se nomme à juste titre :

      Cela permettra de transformer notre variable en variable d'environnement. Nous pouvons vérifier cela en contrôlant à nouveau notre liste d'environnements :

      Output

      TEST_VAR=Hello World!

      Cette fois, notre variable s'affiche. Recommençons notre expérience avec notre shell enfant :

      Output

      Hello World!

      Super ! Notre shell enfant a reçu la variable définie par son parent. Avant de quitter ce shell enfant, essayons d'exporter une autre variable. Nous pouvons configurer les variables d'environnement en une seule étape, comme suit :

      • export NEW_VAR="Testing export"

      Vérifiez qu'elle est bien exportée en tant que variable d'environnement :

      Output

      NEW_VAR=Testing export

      Maintenant, retournons dans notre shell d'origine :

      Voyons si notre nouvelle variable est disponible :

      Aucun résultat n'est renvoyé.

      En effet, les variables d'environnement ne sont transmises qu'aux processus enfant. Il n'existe pas de moyen intégré de configurer les variables d'environnement du shell parent. Ce qui est une bonne chose dans la plupart des cas. Cela empêche également les programmes de modifier l'environnement d'exploitation à partir duquel ils ont été appelés.

      La variable NEW_VAR a été configurée comme une variable d'environnement dans notre shell enfant. Cette variable serait disponible pour elle-même et tous ses shells et processus enfant. Lorsque nous sommes revenus à notre shell principal, cet environnement a été détruit.

      Rétrogradation et annulation des variables

      Notre variable TEST-VAR est toujours définie comme une variable d'environnement. Nous pouvons la reconvertir en une variable de shell en saisissant :

      Il ne s'agit plus d'une variable d'environnement :

      Cependant, il s'agit toujours d'une variable deshell :

      Output

      TEST_VAR='Hello World!'

      Si nous voulons annuler complètement une variable, qu'elle soit de shell ou d'environnement, nous pouvons le faire avec la commande unset :

      Nous pouvons vérifier qu'elle n'est plus configurée :

      Aucun résultat n'est renvoyé car la variable a été annulée.

      Configuration de variables d'environnement à la connexion

      Nous avons déjà mentionné que de nombreux programmes utilisent des variables d'environnement pour décider des spécificités de l'utilisation de ces variables. Nous ne voulons pas avoir à configurer d'importantes variables à chaque fois que nous lançons une nouvelle session shell. Nous avons d'ailleurs déjà vu combien de variables sont déjà configurées lors de la connexion. Alors, de quelle manière créer et configurer des variables automatiquement ?

      Il s'agit en fait d'un problème plus complexe qu'il n'y paraît initialement, en raison des nombreux fichiers de configuration que le shell bash doit lire en fonction de la manière dont il est démarré.

      La différence entre les sessions de shell Login, Non-Login, Interactive et Non-Interactive

      Le shell bash lit différents fichiers de configuration en fonction de la façon dont la session est lancée.

      Il existe une manière de distinguer les différentes sessions qui consiste à établir si le shell est généré comme une session de login ou non-login.

      Un shell de login est une session de shell qui commence par l'authentification de l'utilisateur. Si vous vous connectez à une session via un terminal ou SSH et que vous vous authentifiez, votre session sera considérée comme un shell de login.

      Si vous démarrez une nouvelle session shell à partir de votre session authentifiée, comme nous l'avons fait en appelant la commande bash à partir du terminal, une session shell de non-login sera lancée. Vos données d'authentification ne vous ont pas été demandées lorsque vous avez démarré votre shell enfant.

      On peut également noter une autre distinction qui consiste à déterminer si une session de shell est interactive ou non-interactive.

      Une session shell interactive est une session shell qui est rattachée à un terminal. Une session shell non-interactive est une session qui n'est pas rattachée à une session de terminal.

      Donc, chaque session shell est classée comme étant de login ou non-login et interactive ou non-interactive.

      Une session normale qui commence par SSH est généralement une session shell de login interactive. Un script exécuté à partir de la ligne de commande est généralement exécuté dans une session shell non-interactive et non-login. Une session de terminal peut être une combinaison de ces deux propriétés.

      Que la session soit classée comme un shell de login ou non-login a des implications sur les fichiers à lire pour initialiser la session de shell.

      Une session lancée par comme une session de login lira les détails de configuration tout d'abord à partir du fichier /etc/profile. Ensuite, elle recherchera le premier fichier de configuration de shell de login qui se trouve dans le répertoire d'accueil de l'utilisateur pour obtenir des détails de configuration spécifiques.

      Elle lit le premier fichier qu'elle peut trouver sur ~/.bash_profile, ~/.bash_login et ~/.profile, et ne lit aucun autre fichier.

      En revanche, une session définie comme un shell de non-login lira le fichier /etc/bash.bashrc puis ~/.bashrc spécifique à l'utilisateur pour créer son environnement.

      Les shells non-interactifs lisent la variable d'environnement appelée BASH_ENV et lisent le fichier spécifié pour définir le nouvel environnement.

      Implémentation de variables d'environnement

      Comme vous pouvez le voir, il existe un grand nombre de fichiers différents que nous devrons généralement consulter pour placer nos paramètres.

      Cela permet une grande flexibilité et nous sera d'une grande utilité dans des situations spécifiques, lorsque nous souhaiterons avoir certains paramètres dans un shell de login et d'autres paramètres dans un shell de non-login. Cependant, la plupart du temps nous voudrons avoir les mêmes paramètres dans les deux situations.

      Heureusement, la plupart des distributions Linux configurent les fichiers de configuration de login pour obtenir les fichiers de configuration de non-login. Cela signifie que vous pouvez configurer les variables d'environnement que vous souhaitez avoir dans les deux à l'intérieur des fichiers de configuration de non-login. Ils seront ensuite lus dans les deux scénarios.

      Nous configurerons généralement des variables d'environnement spécifiques à l'utilisateur et souhaiterons que nos réglages soient disponibles dans les deux shells, de login et de non-login. Cela signifie que l'endroit où configurer ces variables se trouve dans le fichier ~/.bashrc.

      Maintenant, ouvrez ce fichier :

      Il est probable qu'il contienne déjà un certain nombre de données. La plupart des définitions ici servent à la configuration des options bash, qui ne sont pas liées à des variables d'environnement. Vous pouvez configurer les variables d'environnement comme vous le feriez avec la ligne de commande suivante :

      Toute nouvelle variable d'environnement peut être ajoutée n'importe où dans le fichier ~/.bashrc tant qu'elle n'est pas placée au milieu d'une autre commande ou pour une boucle. Ensuite, nous pouvons sauvegarder et fermer le fichier. La prochaine fois que vous lancerez une session de shell, la déclaration de votre variable d'environnement sera lue et transmise à l'environnement shell. Vous pouvez forcer votre session actuelle à lire le fichier en saisissant ce qui suit :

      Si vous devez configurer des variables à l'échelle du système, vous devriez éventuellement envisager de les ajouter à /etc/profile, /etc/bash.bashrc, ou /etc/environment.

      Conclusion

      Les variables d'environnement et de shell sont toujours présentes dans votre session shell et peuvent s'avérer très utiles. Il s'agit d'un moyen intéressant pour un processus parent de paramétrer les détails de configuration de ses processus enfant et de configurer des options en-dehors des fichiers.

      Ce qui peut être très avantageux dans des situations spécifiques. Par exemple, certains mécanismes de déploiement dépendent des variables d'environnement pour configurer les données d'authentification. Ceci est utile, car vous n'avez pas besoin de la conserver dans des fichiers qui pourraient être vus par des tiers.

      Il existe de nombreux autres scénarios, plus banals, mais plus courants, dans lesquels vous devrez lire ou modifier l'environnement de votre système. Avec ces outils et ces techniques, vous disposez d'une bonne base pour apporter ces modifications et les utiliser correctement.



      Source link

      Comment installer et configurer Postfix en tant que serveur SMTP à envoi uniquement sur Ubuntu 18.04


      L’auteur a choisi le Free and Open Source Fund comme récipiendaire d’un don dans le cadre du programme Write for DOnations.

      Introduction

      Postfix est un agent de transfert de courriel (MTA), une application utilisée pour envoyer et recevoir des courriels. Elle peut être configurée de manière à ce qu’elle puisse être utilisée pour envoyer des courriels par application locale uniquement. Cela est utile dans les situations où vous devez régulièrement envoyer des notifications par courrier électronique à partir de vos applications, ou simplement en cas de trafic sortant important qu’un fournisseur de services de courrier électronique tiers n’autoriserait pas. C’est également une alternative plus légère à l’exploitation d’un serveur SMTP complet, tout en conservant les fonctionnalités requises.

      Dans ce tutoriel, vous allez installer et configurer Postfix en tant que serveur SMTP pour l’envoi uniquement. Vous allez également demander des certificats TLS gratuits à Let’s Encrypt pour votre domaine et crypter les courriels sortants à l’aide de ces certificats.

      Conditions préalables

      • Un serveur Ubuntu 20.04 configuré avec la Configuration initiale du serveur avec Ubuntu 20.04 y compris la création d’un sudo non root user.
      • Un nom de domaine entièrement enregistré. Ce tutoriel utilisera your_domain. Vous pouvez acheter un nom de domaine sur Namecheap, en obtenir un gratuitement sur Freenom, ou utiliser le bureau d’enregistrement de domaine de votre choix.
      • Un enregistrement DNS A avec your_domain pointant sur l’adresse IP publique de votre serveur. Vous pouvez suivre cette introduction à DigitalOcean DNS pour savoir comment les ajouter.

      Note : Le nom d’hôte de votre serveur et le nom de votre Droplet doivent correspondre à your_domain car DigitalOcean établit automatiquement des enregistrements PTR pour l’adresse IP de la Droplet en fonction de son nom. 

      Vous pouvez vérifier le nom d’hôte du serveur en tapant hostname à l’invite de commande. La sortie doit correspondre au nom que vous avez donné à la Droplet lors de sa création.

      Étape 1 — Installer Postfix

      Dans cette étape, vous allez installer Postfix. Le moyen le plus rapide est d’installer le paquet mailutils qui regroupe Postfix avec quelques programmes supplémentaires que vous utiliserez pour tester l’envoi de courrier électronique. 

      Tout d’abord, mettez à jour la base de données des paquets :

      Ensuite, installez Postfix en exécutant la commande suivante :

      • sudo apt install mailutils

      Vers la fin du processus d’installation, la fenêtre de configuration de Postfix vous sera présentée :

      Sélectionnez Internet Site dans le menu, puis appuyez sur la touche TAB pour sélectionner<Ok>puis ENTRÉE 

      L’option par défaut est Site Internet. C’est l’option recommandée pour votre cas d’utilisation, donc appuyez sur TAB, puis ENTRÉE. Si vous ne voyez que le texte de la description, appuyez sur TAB pour sélectionner OK, puis sur ENTER. 

      S’il ne s’affiche pas automatiquement, exécutez la commande suivante pour le démarrer :

      • sudo dpkg-reconfigure postfix

      Après cela, vous obtiendrez une autre invite de configuration concernant le nom de messagerie du système :

      Entrez votre nom de domaine, puis appuyez sur TAB pour sélectionner<Ok>ENTRÉE

      Le nom de messagerie du système doit être le même que celui que vous avez attribué à votre serveur lors de sa création. Lorsque vous avez terminé, appuyez sur TAB, puis sur ENTRÉE.

      Vous avez maintenant installé Postfix et vous êtes prêt à commencer à le configurer.

      Étape 2 — Configurer Postfix

      Au cours de cette étape, vous configurerez Postfix pour envoyer et recevoir des courriels uniquement à partir du serveur sur lequel il fonctionne, c’est-à-dire à partir de localhost.

      Pour que cela arrive, Postfix doit être configuré pour écouter uniquement sur l’interface de bouclage, l’interface de réseau virtuel que le serveur utilise pour communiquer en interne. Pour effectuer les changements, vous devrez modifier le fichier de configuration principal de Postfix appelé main.cf, stocké sous etc/postfix. 

      Ouvrez-le pour l’éditer à l’aide de votre éditeur de texte préféré :

      • sudo nano /etc/postfix/main.cf

      Trouvez les lignes suivantes :

      /etc/postfix/main.cf

      . . .
      mailbox_size_limit = 0
      recipient_delimiter = +
      inet_interfaces = all
      . . .
      

      Définissez la valeur du paramètre inet_interfaces à loopback-only :

      /etc/postfix/main.cf

      . . .
      mailbox_size_limit = 0
      recipient_delimiter = +
      inet_interfaces = loopback-only
      . . .
      

      Une autre directive que vous devrez modifier est la directive mydestination qui spécifie la liste des domaines qui sont distribués via le transport de courrier local_transport. Par défaut, les valeurs sont similaires à celles-ci :

      /etc/postfix/main.cf

      . . .
      mydestination = $myhostname, your_domain, localhost.com, , localhost
      . . .
      

      Changez la ligne pour qu’elle ressemble à ceci :

      /etc/postfix/main.cf

      . . .
      mydestination = localhost.$mydomain, localhost, $myhostname
      . . .
      

      Si votre domaine est en fait un sous-domaine, et que vous souhaitez que les courriels aient l’air d’avoir été envoyés depuis le domaine principal, vous pouvez ajouter la ligne suivante à la fin de main.cf:

      /etc/postfix/main.cf

      ...
      masquerade_domains = your_main_domain
      

      Le paramètre facultatif masquerade_domains spécifie pour quels domaines la partie de sous-domaine sera supprimée dans l’adresse e-mail.

      Lorsque vous avez terminé, enregistrez et fermez le fichier.

      Note : Si vous hébergez plusieurs domaines sur un seul serveur, les autres domaines peuvent également être transmis à Postfix en utilisant la directive mydestination.

      Ensuite, redémarrez Postfix en exécutant la commande suivante :

      • sudo systemctl restart postfix

      Vous avez configuré Postfix pour n’envoyer des courriels qu’à partir de votre serveur. Vous allez maintenant le tester en envoyant un exemple de message à une adresse électronique.

      Étape 3 — Tester le serveur SMTP

      Au cours de cette étape, vous allez tester si Postfix peut envoyer des courriels à un compte de messagerie externe en utilisant la commande mail qui fait partie du paquet mailutils que vous avez installé lors de la première étape.

      Pour envoyer un courriel de test, exécutez la commande suivante :

      • echo "This is the body of the email" | mail -s "This is the subject line" your_email_address

      Vous pouvez changer le corps et l’objet du courriel à votre convenance. N’oubliez pas de remplacer your_email_address avec une adresse électronique valide à laquelle vous pouvez accéder. 

      Maintenant, vérifiez l’adresse électronique à laquelle vous avez envoyé ce message. Vous devriez voir le message dans votre boîte de réception. S’il n’y est pas, vérifiez votre dossier de courrier indésirable. À ce stade, tous les courriers électroniques que vous envoyez ne sont pas cryptés, ce qui fait penser aux fournisseurs de services qu’il s’agit probablement de spam. Vous mettrez en place le cryptage plus tard, à l’étape 5.

      Si vous recevez une erreur de la part de la commande mail ou que vous n’avez pas reçu de message après une période prolongée, vérifiez que la configuration de Postfix que vous avez modifiée est valide et que le nom de votre serveur et le nom d’hôte sont définis pour votre domaine.

      Notez qu’avec cette configuration, l’adresse dans le champ de départ pour les courriels de test que vous envoyez sera sous la forme your_user_name@your_domain, où your_user_name est le nom d’utilisateur de l’utilisateur du serveur sous lequel vous avez exécuté la commande. 

      Vous avez maintenant envoyé un courriel à partir de votre serveur et vérifié qu’il a bien été reçu. Dans l’étape suivante, vous mettrez en place une redirection de courrier électronique pour root. 

      Étape 4 — Transférer le courrier système

      Au cours de cette étape, vous configurerez le transfert de courrier électronique pour l’utilisateur root afin que les messages générés par le système qui lui sont envoyés sur votre serveur soient transférés à une adresse électronique externe.

      Le fichier /etc/aliases contient une liste de noms alternatifs pour les destinataires du courrier électronique. Ouvrez-le pour le modifier :

      Dans son état par défaut, il ressemble à ceci :

      /etc/aliases

      # See man 5 aliases for format
      postmaster:    root
      

      La seule directive présente précise que les courriels générés par le système sont envoyés à root.

      Ajoutez la ligne suivante à la fin du fichier :

      /etc/aliases

      ...
      root:          your_email_address
      

      Avec cette ligne, vous précisez que les courriels envoyés à root finissent par être transférés à une adresse électronique. N’oubliez pas de remplacer your_email_address avec votre adresse électronique personnelle. Lorsque vous avez terminé, enregistrez et fermez le fichier.

      Pour que le changement prenne effet, exécutez la commande suivante :

      L’exécution de newaliases permet de constituer une base de données des alias utilisés par la commande mail, qui sont extraits du fichier de configuration que vous venez d’éditer.

      Testez que l’envoi de courriels vers root fonctionne, en exécutant :

      • echo "This is the body of the email" | mail -s "This is the subject line" root

      Vous devriez recevoir le courriel à votre adresse électronique. S’il n’y est pas, vérifiez votre dossier spam.

      Dans cette étape, vous avez mis en place le transfert des messages générés par le système vers votre adresse électronique. Vous allez maintenant activer le cryptage des messages de sorte que tous les courriers électroniques envoyés par votre serveur sont à l’abri de toute altération pendant leur transit et seront considérés comme plus légitimes.

      Étape 5 — Activation du cryptage SMTP

      Vous allez maintenant activer le cryptage SMTP en demandant un certificat TLS gratuit à Let’s Encrypt pour votre domaine (en utilisant Certbot) et en configurant Postfix pour l’utiliser lors de l’envoi de messages.

      Ubuntu inclut Certbot dans ses référentiels de paquets par défaut ; vous pouvez donc l’installer en exécutant la commande suivante :

      Lorsqu’on vous demande une confirmation, tapez Y et appuyez sur ENTER .

      Lors de la configuration initiale du serveur dans les conditions préalables, vous avez installé ufw, le pare-feu non compliqué. Vous devrez le configurer pour autoriser le port HTTP 80 afin que la vérification du domaine puisse être effectuée. Exécutez la commande suivante pour l’activer :

      La sortie finale ressemblera à ceci :

      Output

      Rule added Rule added (v6)

      Maintenant que le port est ouvert, lancez Certbot pour obtenir un certificat :

      • sudo certbot certonly --standalone --rsa-key-size 4096 --agree-tos --preferred-challenges http -d your_domain

      Cette commande ordonne à Certbot d’émettre des certificats avec une clé RSA de 4096 bits pour faire fonctionner un serveur Web autonome temporaire (--standalone) pour la vérification, et pour vérifier via le port 80 (--preferred-challenges http). N’oubliez pas de remplacer your_domain par votre domaine avant d’exécuter la commande, et entrez votre adresse électronique lorsque vous y êtes invité. 

      Le résultat sera similaire à celui-ci :

      Output

      Saving debug log to /var/log/letsencrypt/letsencrypt.log Plugins selected: Authenticator standalone, Installer None Obtaining a new certificate Performing the following challenges: http-01 challenge for `your_domain` Waiting for verification... Cleaning up challenges IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at: /etc/letsencrypt/live/your_domain/fullchain.pem Your key file has been saved at: /etc/letsencrypt/live/your_domain/privkey.pem Your cert will expire on 2020-07-11. To obtain a new or tweaked version of this certificate in the future, simply run certbot again. To non-interactively renew *all* of your certificates, run "certbot renew" - If you like Certbot, please consider supporting our work by: Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate Donating to EFF: https://eff.org/donate-le

      Comme indiqué dans les notes, votre certificat et votre fichier de clé privée ont été enregistrés sous /etc/letsencrypt/live/your_domain. 

      Maintenant que vous avez votre certificat, ouvrez main.cf pour l’éditer :

      • sudo nano /etc/postfix/main.cf

      Trouvez la section suivante :

      /etc/postfix/main.cf

      # TLS parameters
      smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
      smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
      smtpd_tls_security_level=may
      
      smtp_tls_CApath=/etc/ssl/certs
      smtp_tls_security_level=may
      smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
      

      Modifiez-le pour qu’il ressemble à ceci, en remplaçant your_domain par votre domaine, si nécessaire. Cela permettra de mettre à jour vos paramètres TLS pour Postfix :

      /etc/postfix/main.cf

      # TLS parameters
      smtpd_tls_cert_file=/etc/letsencrypt/live/your_domain/fullchain.pem
      smtpd_tls_key_file=/etc/letsencrypt/live/your_domain/privkey.pem
      smtpd_tls_security_level=may
      
      smtp_tls_CApath=/etc/ssl/certs
      smtp_tls_security_level=may
      smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
      

      Une fois que vous avez terminé, enregistrez et fermez le fichier.

      Pour appliquer les changements, redémarrez Postfix :

      • sudo systemctl restart postfix

      Maintenant, essayez d’envoyer à nouveau un courriel :

      • echo "This is the body of an encrypted email" | mail -s "This is the subject line" your_email_address

      Ensuite, vérifiez l’adresse électronique que vous avez fournie. Il est possible que vous voyiez le message dans votre boîte de réception immédiatement car les fournisseurs de messagerie électronique sont beaucoup plus susceptibles de marquer les messages non cryptés comme étant du spam.

      Vous pouvez vérifier les informations techniques concernant le message électronique dans votre client pour voir si le message est effectivement crypté.

      Conclusion

      Vous disposez maintenant d’un serveur de courrier électronique à envoi unique, alimenté par Postfix. Le cryptage de tous les messages sortants est un premier pas efficace pour que les fournisseurs de services de messagerie électronique ne marquent pas purement et simplement vos messages comme du spam. Si vous faites cela dans un scénario de développement, alors cette mesure devrait suffire.

      Cependant, si votre cas d’utilisation est l’envoi de courriels aux utilisateurs potentiels du site (comme des courriels de confirmation pour l’inscription à un forum), vous devriez envisager de créer des registres SPF afin que les courriels de votre serveur soient encore plus susceptibles d’être considérés comme légitimes.



      Source link

      Comment configurer l’accès à distance pour MongoDB sur Ubuntu 20.04


      Une version antérieure de ce tutoriel a été écrite par Brennan Bearnes.

      Introduction

      MongoDB, également connu sous le nom de Mongo, est une base de données de documents open-source utilisée couramment dans des applications web modernes. Par défaut, il n’autorise que les connexions provenant du même serveur que celui où il est installée. Si vous souhaitez gérer MongoDB à distance ou le connecter à un serveur d’application distinct, vous devrez apporter quelques changements à la configuration par défaut.

      Dans ce tutoriel, vous allez configurer une installation MongoDB pour permettre un accès sécurisé à partir d’un ordinateur distant de confiance. Pour ce faire, vous allez mettre à jour vos règles de pare-feu pour permettre à la machine distante d’accéder au port sur lequel MongoDB écoute des connexions, puis vous mettrez à jour son fichier de configuration pour modifier son paramètre de liaison IP. Ensuite, comme dernière étape, vous testerez si votre machine distante est capable de se connecter avec succès à votre base de données.

      Conditions préalables

      Pour suivre ce tutoriel, vous aurez besoin des éléments suivants :

      • Un serveur fonctionnant sous Ubuntu 20.04 Ce serveur doit avoir un non-root user administratif et un pare-feu configuré avec UFW. Pour cela, suivez notre guide de configuration initiale du serveur pour Ubuntu 20.04.
      • MongoDB installé sur votre serveur. Ce tutoriel suppose que vous avez installé MongoDB 4.4 ou une version plus récente. Vous pouvez installer cette version en suivant notre tutoriel Comment installer MongoDB sur Ubuntu 20.04.
      • Un deuxième ordinateur à partir duquel vous allez accéder à votre instance MongoDB. Pour plus de simplicité, ce tutoriel suppose que cette machine est un autre serveur Ubuntu 20.04, avec un utilisateur administratif non root et un pare-feu UFW configuré en suivant notre guide de configuration initiale du serveur pour Ubuntu 20.04. Cependant, les étapes 1 et 2, qui décrivent la procédure réelle d’activation de la connectivité à distance sur le serveur de base de données, fonctionneront quel que soit le système d’exploitation de la machine distante.

      Enfin, bien que ce ne soit pas nécessaire pour terminer ce tutoriel, nous vous recommandons fortement de sécuriser votre installation MongoDB en créant un compte utilisateur administratif pour la base de données et en activant l’authentification. Pour ce faire, suivez notre tutoriel Comment sécuriser MongoDB sur Ubuntu 20.04.

      Étape 2 — Ajustement du pare-feu

      En supposant que vous ayez suivi le tutoriel de configuration initiale du serveur et activé un pare-feu UFW sur votre serveur, votre installation MongoDB sera inaccessible depuis Internet. Si vous avez l’intention d’utiliser MongoDB uniquement en local avec des applications fonctionnant sur le même serveur, il s’agit de la configuration recommandée et sécurisée. Cependant, si vous souhaitez pouvoir vous connecter à votre serveur MongoDB à distance, vous devez autoriser les connexions entrantes sur le port où la base de données est à l’écoute en ajoutant une nouvelle règle UFW.

      Commencez par vérifier quel port votre installation MongoDB écoute avec la commande lsof. Cette commande renvoie généralement une liste contenant tous les fichiers ouverts d’un système, mais lorsqu’elle est combinée à l’option -i, elle ne répertorie que les fichiers ou les flux de données liés au réseau.

      La commande suivante redirigera la sortie produite par lsof -i vers une commande grep qui recherche une chaîne nommée mongo :

      • sudo lsof -i | grep mongo

      Cet exemple de sortie montre que MongoDB écoute les connexions sur son port par défaut, 27017 :

      Output

      mongod 82221 mongodb 11u IPv4 913411 0t0 TCP localhost:27017 (LISTEN)

      Dans la plupart des cas, MongoDB ne doit être accessible qu’à partir de certains lieux de confiance (un autre serveur hébergeant une application, par exemple). Une façon de configurer cette méthode consiste à exécuter la commande suivante sur votre serveur MongoDB, qui ouvre un accès sur le port par défaut de MongoDB tout en n’autorisant explicitement que l’adresse IP de l’autre serveur de confiance.

      Exécutez la commande suivante, en vous assurant de remplacer trusted_server_ip par l’adresse IP de la machine distante de confiance que vous utiliserez pour accéder à votre instance MongoDB :

      Remarque : si la sortie de la commande précédente a indiqué que votre installation de MongoDB écoute sur un port non par défaut, utilisez ce numéro de port à la place de 27017 dans cette commande.

      • sudo ufw allow from trusted_server_ip to any port 27017

      À l’avenir, si jamais vous souhaitez accéder à MongoDB à partir d’une autre machine, exécutez à nouveau cette commande avec l’adresse IP de la nouvelle machine à la place de trusted_server_ip.

      Vous pouvez vérifier le changement dans les paramètres de pare-feu avec ufw :

      La sortie montrera que le trafic vers le port 27017 du serveur distant est maintenant autorisé :

      Output

      Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere 27017 ALLOW trusted_server_ip OpenSSH (v6) ALLOW Anywhere (v6)

      Vous pouvez trouver des paramètres de pare-feu plus avancés pour restreindre l’accès aux services dans les Essentiels d’UFW : Règles et commandes communes du pare-feu.

      Ensuite, vous allez lier MongoDB à l’adresse IP publique du serveur afin de pouvoir y accéder à partir de votre machine distante.

      Étape 2 — Configurer une bindIP publique

      À ce stade, même si le port est ouvert, MongoDB est actuellement lié à 127.0.0.1, l’interface du réseau de rebouclage local. Cela signifie que MongoDB n’est en mesure d’accepter que les connexions originaires du serveur où il est installé.

      Pour permettre des connexions distantes, vous devez modifier le fichier de configuration de MongoDB — /etc/mongod.conf — pour lier également MongoDB à l’adresse IP routable publique de votre serveur. De cette façon, votre installation MongoDB sera en mesure d’écouter les connexions faites à votre serveur MongoDB à partir de machines distantes.

      Ouvrez le fichier de configuration de MongoDB dans votre éditeur de texte préféré. L’exemple suivant utilise nano :

      • sudo nano /etc/mongod.conf

      Trouvez la section network interfaces, puis la valeur bindIp :

      /etc/mongod.conf

      . . .
      # network interfaces
      net:
        port: 27017
        bindIp: 127.0.0.1
      
      . . .
      

      Ajoutez une virgule à cette ligne suivie de l’adresse IP publique de votre serveur MongoDB :

      /etc/mongod.conf

      . . .
      # network interfaces
      net:
        port: 27017
        bindIp: 127.0.0.1,mongodb_server_ip
      
      . . .
      

      Enregistrez et fermez le fichier. Si vous avez utilisé nano, faites-le en appuyant sur CTRL+X, Y, puis ENTER.

      Ensuite, redémarrez MongoDB pour mettre ce changement en vigueur :

      • sudo systemctl restart mongod

      Suite à cela, votre installation MongoDB sera en mesure d’accepter des connexions à distance à partir de toutes les machines que vous avez autorisées à accéder au port 27017. En dernière étape, vous pouvez vérifier si le serveur distant de confiance que vous avez autorisé à travers le pare-feu à l’Étape 1 peut atteindre l’instance de MongoDB exécutée sur votre serveur.

      Étape 3 — Test de la connectivité à distance

      Maintenant que vous avez configuré votre installation MongoDB pour écouter des connexions qui proviennent de son adresse IP publique routable et que vous avez accordé à votre machine distante l’accès au port par défaut de Mongo via le pare-feu de votre serveur, vous pouvez tester si la machine distante est capable de se connecter.

      Remarque : comme mentionné dans la section Conditions préalables, ce tutoriel suppose que votre machine distante est un autre serveur fonctionnant sous Ubuntu 20.04. La procédure d’activation des connexions à distance décrite aux Étapes 1 et 2 devrait fonctionner indépendamment du système d’exploitation de votre machine distante, mais les méthodes de test décrites dans cette étape ne fonctionnent pas de manière universelle pour tous les systèmes d’exploitation.

      Une façon de tester si votre serveur distant de confiance est capable de se connecter à l’instance MongoDB, consiste à utiliser la commande nc. nc, abréviation de netcat, est un utilitaire utilisé pour établir des connexions réseau avec TCP ou UDP. Il est utile pour effectuer des tests dans des cas comme celui-ci car il vous permet de spécifier à la fois une adresse IP et un numéro de port.

      Tout d’abord, connectez-vous à votre serveur de confiance en utilisant SSH :

      • ssh sammy@trusted_server_ip

      Ensuite, exécutez la commande nc suivante, qui inclut l’option -z. Cela limite nc à ne chercher qu’un démon d’écoute sur le serveur cible sans lui envoyer de données. Rappelez-vous du tutoriel d’installation préalable qui explique que MongoDB fonctionne en tant que démon service, ce qui rend cette option utile pour tester la connectivité. Elle inclut également l’option v qui augmente la verbosité de la commande, ce qui fait que netcat renvoie des données qu’il ne renverrait pas autrement.

      Exécutez la commande nc suivante à partir de votre serveur distant de confiance, en vous assurant de remplacer mongodb_server_ip par l’adresse IP du serveur sur lequel vous avez installé MongoDB :

      • nc -zv mongodb_server_ip 27017

      Si le serveur de confiance peut accéder au démon MongoDB, sa sortie indiquera que la connexion a réussi :

      Output

      Connection to mongodb_server_ip 27017 port [tcp/*] succeeded!

      En supposant que vous disposez d’une version compatible du shell mongo installé sur votre serveur distant, vous pouvez à ce stade vous connecter directement à l’instance de MongoDB installée sur le serveur hôte.

      Une façon de se connecter est d’utiliser une chaîne de connexion URI, comme celle-ci :

      • mongo "mongodb://mongo_server_ip:27017"

      Remarque : si vous avez suivi le tutoriel recommandé Comment sécuriser MongoDB sur Ubuntu 20.04, vous aurez fermé l’accès à votre base de données aux utilisateurs non authentifiés. Dans ce cas, vous devrez utiliser une URI spécifiant un nom d’utilisateur valide, comme celle-ci :

      • mongo "mongodb://username@mongo_server_ip:27017"

      Le shell vous invitera automatiquement à entrer le mot de passe de l’utilisateur.

      Avec cela, vous avez confirmé que votre serveur MongoDB pouvait accepter les connexions du serveur de confiance.

      Conclusion

      Vous pouvez maintenant accéder à votre installation MongoDB à partir d’un serveur distant. À ce stade, vous pouvez gérer à distance votre base de données Mongo du serveur de confiance. Vous pouvez également configurer une application pour qu’elle s’exécute sur le serveur de confiance et utiliser la base de données à distance.

      Si vous n’avez pas configuré d’utilisateur administratif et activé l’authentification, toute personne ayant accès à votre serveur distant peut également accéder à votre installation MongoDB. Si vous ne l’avez pas encore fait, nous vous recommandons fortement de suivre notre guide Comment sécuriser MongoDB sur Ubuntu 20.04 pour ajouter un utilisateur administratif et verrouiller les choses plus avant.



      Source link