One place for hosting & domains

      configurer

      Comment configurer un cluster Mesosphere prêt pour la production sur Ubuntu 14.04


      Introduction

      Mesosphere est un système qui combine un certain nombre de composants afin de gérer efficacement la création de clusters des serveurs et des déploiements hautement disponibles au-dessus d’une couche de système d’exploitation existante. Contrairement aux systèmes comme CoreOS, Mesosphere n’est pas un système d’exploitation spécialisé mais plutôt un ensemble de paquets.

      Dans ce guide, nous allons découvrir comment configurer un cluster hautement disponible dans Mesosphere. Cette configuration nous permettra de nous doter d’une fonctionnalité de basculement dans le cas où l’un de nos nœuds maîtres tomberait en panne, ainsi qu’un pool de serveurs esclaves qui gère les tâches planifiées.

      Au cours de ce guide, nous utiliserons des serveurs Ubuntu 14.04.

      Conditions prélables et objectifs

      Avant de suivre ce guide, il est fortement recommandé de revoir notre introduction à Mesosphere. Il s’agit d’un excellent moyen pour vous de vous familiariser avec les composants dont le système est composé et de vous aider à identifier de quoi chaque unité est responsable.

      Au cours de ce tutoriel, nous utiliserons six serveurs Ubuntu. Cela satisfait à la recommandation Apache Mesos qui préconise l’utilisation d’au moins trois maîtres dans un environnement de production. Cela permet également d’avoir un pool de trois serveurs de travail ou esclaves, qui se verront attribués du travail lorsque les tâches seront envoyées au cluster.

      Les six serveurs avec lesquels nous travaillerons utiliserons zookeeper pour suivre le serveur maître leader actuel. La couche Mesos, intégré au-dessus, offrira une synchronisation et une manipulation des ressources distribuées Elle est responsable de la gestion du cluster. Marathon, le système d’init distribué du cluster, est utilisé pour planifier des tâches et travailler manuellement sur les serveurs esclaves.

      Dans le cas de ce guide, nous supposerons que nos machines ont la configuration suivante :

      Nom d’hôte Fonction adresse IP
      maître1 Maître Mesos 192.0.2.1
      maître2 Maître Mesos 192.0.2.2
      maître3 Maître Mesos 192.0.2.3
      esclave1 Esclave Mesos 192.0.2.51
      esclave2 Esclave Mesos 192.0.2.52
      esclave3 Esclave Mesos 192.0.2.53

      Ubuntu 14.04 devrait être installé sur chacune de ces machines. Vous devriez compléter les éléments de configuration de base répertoriés dans notre guide de configuration du serveur initial Ubuntu 14.04.

      Une fois que vous aurez terminé les deux étapes ci-dessus, poursuivez la lecture de ce guide.

      Installer Mesosphere sur les serveurs

      La première étape pour faire fonctionner votre cluser consiste à installer le logiciel. Heureusement, le projet Mesosphere conserve un dépôt Ubuntu avec des packages à jour faciles à installer.

      Ajouter les dépôts Mesosphere à vos hôtes

      Sur tous les hôtes (maîtres et esclaves), suivez les étapes suivantes.

      Tout d’abord, ajoutez le dépôt Mesosphere à votre liste de sources. Pour suivre ce processus, la clé du projet Mesosphere devra être téléchargée à partir du serveur de clés Ubuntu, puis l’URL applicable de notre version Ubuntu développée. Le projet vous offre un moyen pratique de le faire :

      sudo apt-key adv --keyserver keyserver.ubuntu.com --recv E56151BF
      DISTRO=$(lsb_release -is | tr '[:upper:]' '[:lower:]')
      CODENAME=$(lsb_release -cs)
      echo "deb http://repos.mesosphere.io/${DISTRO} ${CODENAME} main" | sudo tee /etc/apt/sources.list.d/mesosphere.list
      

      Installer les composants nécessaires

      Une fois le dépôt Mesosphere ajouté à votre système, vous devez mettre à jour votre cache de package local pour avoir accès à votre nouveau composant :

      sudo apt-get -y update
      

      Ensuite, vous devez installer les packages nécessaires. Les composants dont vous avez besoin dépendront du rôle de l’hôte.

      Pour vos hôtes maîtres, vous avez besoin du package de méta mesosphere. Cela inclut les applications zookeeper, mesos, marathon et chronos :

      sudo apt-get install mesosphere
      

      Pour vos hôtes slave, vous avez uniquement besoin du package mesos, qui extrait également zookeeper comme dépendance :

      sudo apt-get install mesos
      

      Configurer les informations de connexion de Zookeeper pour Mesos

      Dans un premier temps, nous allons configurer nos informations de connexion à zookeeper. Il s’agit de la couche sous-jacente qui permet à tous vos hôtes de se connecter aux bons serveurs maîtres, c’est pourquoi il est logique de commencer ici.

      Nos serveurs maîtres seront les seuls membres de notre cluster zookeeper, mais l’intégralité de nos serveurs devront être configurés pour pouvoir communiquer en utilisant le protocole. Le fichier qui définit cela est le suivant /etc/mesos/zk.

      Sur tous vos hôtes, procédez à l’étape suivante. Ouvrez le fichier avec les privilèges root :

      sudo nano /etc/mesos/zk
      

      À l’intérieur, vous trouverez l’URL de connexion configurée par défaut pour accéder à une instance locale. Cela ressemble à ce qui suit :

      zk://localhost:2181/mesos
      

      Vous devez la modifier afin qu’elle pointe vers nos trois serveurs maîtres. Pour cela, vous devez remplacer localhost par l’adresse IP de notre premier maître Mesos. Nous pouvons ensuite ajouter une virgule après la spécification du port et reproduire le format pour ajouter nos deuxième et troisième maîtres à la liste.

      Dans notre guide, les adresses IP de nos maîtres sont les suivantes : 192.0.2.1, 192.168.2.2 et 192.168.2.3. En utilisant ces valeurs, notre fichier ressemblera à ce qui suit :

      zk://192.0.2.1:2181,192.0.2.2:2181,192.0.2.3:2181/mesos
      

      La ligne doit commencer par zk:// et se terminer par /mesos. Entre deux sont spécifiées les adresses IP de vos serveurs maîtres et les ports zookeeper (2181 par défaut).

      Enregistrez et fermez le fichier lorsque vous avez terminé.

      Utilisez cette même saisie dans chacun de vos maîtres et esclaves. Cela aidera chaque serveur individuel à se connecter aux bons serveurs maîtres et pouvoir ainsi communiquer avec le cluster.

      Paramétrer la configuration de Zookeeper des serveurs maîtres

      Sur vos serveurs master, nous devrons procéder à une configuration supplémentaire de zookeeper.

      La première étape consiste à configurer un numéro d’identification unique, de 1 à 255 pour chacun de vos serveurs maîtres. Il se trouve dans le fichier /etc/zookeeper/conf/myid. Maintenant, ouvrez-le :

      sudo nano /etc/zookeeper/conf/myid
      

      Supprimez toutes les informations qui se trouvent dans ce fichier et remplacez-les par un seul numéro, de 1 à 255. Le numéro attribué à chacun de vos serveurs maîtres doit être unique. Par souci de simplicité, il est plus facile de commencer par 1 et de progresser. Dans notre guide, nous utiliserons 1, 2 et 3.

      Notre premier serveur contiendra uniquement ce qui suit dans le fichier :

      1
      

      Enregistrez et fermez le fichier lorsque vous avez terminé. Procédez ainsi sur chacun de vos serveurs maîtres.

      Ensuite, nous devons modifier notre fichier de configuration zookeeper pour cartographier nos ID zookeeper sur les hôtes en tant que tel. Vous aurez ainsi la garantie que le service est bien en capacité de résoudre correctement chaque hôte à partir du système d’ID qu’il utilise.

      Maintenant, ouvrez le fichier de configuration zookeeper :

      sudo nano /etc/zookeeper/conf/zoo.cfg
      

      Dans ce fichier, vous devrez cartographier chaque ID sur un hôte. La spécification de l’hôte inclura deux ports. Le premier servira à communiquer avec le leader. Le second se chargera des élections au moment où un nouveau leader sera nécessaire. Les serveurs zookeeper sont identifiés par le terme « server » suivi d’un point et de leur numéro d’ID.

      Dans notre guide, nous utiliserons les ports par défaut pour chaque fonction et nos ID vont de 1 à 3. Notre fichier ressemblera à ce qui suit :

      server.1=192.168.2.1:2888:3888
      server.2=192.168.2.2:2888:3888
      server.3=192.168.2.3:2888:3888
      

      Ajoutez ces mêmes cartographies dans chacun des fichiers de configuration de vos serveurs maîtres. Enregistrez et fermez chaque fichier lorsque vous avez terminé.

      Avec cela, notre configuration zookeeper est achevée. Nous pouvons commencer à nous concentrer sur Mesos et Marathon.

      Configurer Mesos sur les serveurs maîtres

      Ensuite, nous allons configurer Mesos sur les trois serveurs maîtres. Suivez ces étapes sur chacun de vos serveurs maîtres.

      Modifier le Quorum pour refléter la taille de votre cluster

      Tout d’abord, nous devons ajuster le quorum nécessaire à la prise de décision. Il déterminera le nombre d’hôtes nécessaires pour que le cluster soit en état de fonctionnement.

      Le quorum doit être configuré de manière à ce que plus de 50 pour cent des membres maîtres soient présents pour prendre des décisions. Cependant, il nous faut également établir une certaine tolérance de défaillance dans le cas où, si tous nos maîtres ne sont pas présents, le cluster puisse toujours fonctionner.

      Nous disposons de trois maîtres. Par conséquent, le seul réglage qui satisfait à ces deux exigences est un quorum de deux. Étant donné que la configuration initiale suppose un réglage de serveur unique, le quorum est actuellement défini à un.

      Ouvrez le fichier de configuration du quorum :

      sudo nano /etc/mesos-master/quorum
      

      Remplacez la valeur par « 2 » :

      2
      

      Enregistrez et fermez le fichier. Procédez ainsi sur chacun de vos serveurs maîtres.

      Configurer le nom d’hôte et l’adresse IP

      Nous allons ensuite spécifier le nom de l’hôte et l’adresse IP de chacun de nos serveurs maîtres. Pour le nom de l’hôte, nous utiliserons l’adresse IP afin que nos instances n’aient pas de difficultés à se résoudre correctement.

      Pour nos serveurs maîtres, l’adresse IP doit être placée dans ces fichiers :

      • /etc/mesos-master/ip
      • /etc/mesos-master/hostname

      Tout d’abord, ajoutez l’adresse IP individuelle de chaque nœud maître dans le fichier /etc/mesos-master/ip. N’oubliez pas de la modifier sur chaque serveur afin qu’elle corresponde à la valeur applicable :

      echo 192.168.2.1 | sudo tee /etc/mesos-master/ip
      

      Maintenant, nous pouvons copier cette valeur sur le fichier du nom de l’hôte :

      sudo cp /etc/mesos-master/ip /etc/mesos-master/hostname
      

      Procédez ainsi sur chacun de vos serveurs maîtres.

      Configurer Marathon sur les serveurs maîtres

      Maintenant que Mesos est configuré, nous pouvons procéder à la configuration de l’implémentation du système init en cluster de Mesosphere.

      Marathon s’exécutera sur chacun de nos hôtes maîtres. Cependant, seul le serveur maître principal pourra planifier des tâches. Les autres instances de Marathon transmettront les requêtes de manière transparente sur le serveur maîtres.

      Tout d’abord, nous devons à nouveau configurer le nom de l’hôte pour l’instance de Marathon de chaque serveur. Encore une fois, nous utiliserons l’adresse IP dont nous disposons déjà dans un fichier. Nous pouvons la copier dans l’emplacement du fichier dont nous avons besoin.

      Cependant, la structure du répertoire de configuration de Marathon dont nous avons besoin n’est pas automatiquement créée. Nous allons devoir créer le répertoire pour pouvoir ensuite y copier le fichier :

      sudo mkdir -p /etc/marathon/conf
      sudo cp /etc/mesos-master/hostname /etc/marathon/conf
      

      Ensuite, nous devons définir la liste des maîtres zookeeper auxquels Marathon se connectera pour obtenir des informations et une planification. Il s’agit de la même chaîne de connexion zookeeper que nous avons utilisée pour Mesos afin que nous puissions tout simplement y copier le fichier. Nous devons le placer dans un fichier appelé master :

      sudo cp /etc/mesos/zk /etc/marathon/conf/master
      

      Notre service Marathon pourra ainsi se connecter au cluster Mesos. Cependant, nous souhaitons également que Marathon stocke ses propres informations dans zookeeper. Pour cela, nous utiliserons l’autre fichier de connexion zookeeper comme base et modifierons tout simplement le point final.

      Tout d’abord, copiez le fichier dans l’emplacement zookeeper de Marathon :

      sudo cp /etc/marathon/conf/master /etc/marathon/conf/zk
      

      Ensuite, ouvrez le fichier dans votre éditeur :

      sudo nano /etc/marathon/conf/zk
      

      Le point final est la seule partie que nous ayons besoin de modifier. Nous allons remplacer /mesos par /marathon :

      zk://192.0.2.1:2181,192.0.2.2:2181,192.0.2.3:2181/marathon
      

      C’est tout ce qu’il faut faire pour configurer Marathon.

      Configurer les règles d’init des services et redémarrer les services

      Ensuite, nous allons redémarrer les services de serveurs maîtres pour utiliser les paramètres qui nous avons configurés.

      Tout d’abord, nous allons nous assurer que nos serveurs maîtres exécutent uniquement le processus maître Mesos et non pas le processus esclave. Nous pouvons arrêter tout processus esclave actuellement en cours d’exécution (cela peut échouer mais ce n’est pas un problème car il s’agit uniquement de vérifier que le processus est arrêté). Nous pouvons également que le serveur ne commence pas avec le processus esclave au démarrage en créant un fichier de remplacement :

      sudo stop mesos-slave
      echo manual | sudo tee /etc/init/mesos-slave.override
      

      Maintenant, il ne reste plus qu’à redémarrer zookeeper, qui configurera nos élections maîtresses. Nous pouvons ensuite démarrer nos processus Mesos maître et Marathon :

      sudo restart zookeeper
      sudo start mesos-master
      sudo start marathon
      

      Pour obtenir un pic dans ce que vous venez juste de configurer, consultez l’un de nos serveurs maîtres notre navigateur web au port 5050 :

      http://192.168.2.1:5050
      

      Vous devriez voir l’interface principale de Mesos. Vous serez éventuellement informé que vous êtes redirigé vers le master actif en fonction de si vous vous êtes connecté au leader ou pas. Dans tous les cas, l’écran ressemblera à ce qui suit :

      Principale interface de Mesos

      Il s’agit d’une vue de votre cluster actuel. Vous n’y voyez pas grand-chose car il n’y a aucun nœud esclave disponible et aucune tâche a été démarrée.

      Nous avons également configuré Marathon, le contrôleur de tâches longue durée de Mesosphere. Il sera disponible sur le port 8080 sur l’un de vos maîtres :

      Interface principale de Marathon

      Nous allons brièvement voir comment utiliser ces interfaces une fois que nous avons configuré nos esclaves.

      Configurer les serveurs esclaves

      Maintenant que nous avons configuré nos serveurs maîtres, nous pouvons commencer à configurer nos serveurs esclaves.

      Nous avons déjà configuré nos esclaves avec les informations de connexion zookeeper de nos serveurs maîtres. Les esclaves eux-mêmes n’exécutent pas leurs propres instances zookeeper.

      Nous pouvons arrêter tout processus zookeeper qui fonctionne actuellement sur nos nœuds esclaves et créer un fichier de remplacement afin qu’il ne démarre pas automatiquement lorsque le serveur redémarre :

      sudo stop zookeeper
      echo manual | sudo tee /etc/init/zookeeper.override
      

      Ensuite, nous voulons créer un autre fichier de remplacement pour s’assurer que le processus maître Mesos ne commence pas sur nos serveurs esclaves. Nous allons également nous assurer qu’il est actuellement arrêté (il se peut que cette commande échoue si le processus est déjà arrêté. Ceci n’est pas un problème) :

      echo manual | sudo tee /etc/init/mesos-master.override
      sudo stop mesos-master
      

      Ensuite, nous devons configurer l’adresse IP et le nom de l’hôte, tout comme nous l’avons fait pour nos serveurs maîtres. Cela implique la mise en place de l’adresse IP de chaque nœud dans un fichier, cette fois sous le répertoire /etc/mesos-slave. Nous utiliserons également le nom de l’hôte pour accéder facilement aux services via l’interface web :

      echo 192.168.2.51 | sudo tee /etc/mesos-slave/ip
      sudo cp /etc/mesos-slave/ip /etc/mesos-slave/hostname
      

      Encore une fois, utilisez l’adresse IP de chaque serveur esclave pour la première commande. Cela garantira qu’elle est bien liée à la bonne interface.

      Maintenant, nous avons tous les éléments pour démarrer nos esclaves Mesos. Il nous suffit juste d’activer le service :

      sudo start mesos-slave
      

      Procédez ainsi sur chacune de vos machines esclaves.

      Pour voir si vos esclaves s’enregistrent avec succès dans votre cluster, revenez à l’un de vos serveurs maîtres au port 5050 :

      http://192.168.2.1:5050
      

      Maintenant, vous devriez voir le nombre d’esclaves actifs afficher « 3 » dans l’interface :

      Trois esclaves Mesos

      Vous pouvez également voir que les ressources disponibles dans l’interface ont été mises à jour pour refléter les ressources pooled dans vos machines esclaves :

      Ressources Mesos

      Pour obtenir de plus amples informations sur chacune de vos machines, vous pouvez cliquer sur le lien « Slaves » en haut de l’interface. Ceci nous donnera un aperçu de la contribution en ressources de chaque machine, ainsi que les liens vers une page de chaque esclave :

      Page des esclaves Mesos

      Démarrer des services sur Mesos et Marathon

      Marathon est l’utilitaire Mesosphere permettant de planifier les tâches de longue durée. Il est facile de penser que Marathon est le système init pour un cluster Mesosphere car il prend en charge les services de démarrage et d’arrêt, tout en planifiant les tâches et en s’assurant que les applications remontent si elles descendent.

      Vous pouvez également ajouter des services et des tâches à Marathon de quelques manières différentes. Nous allons uniquement couvrir les services de base. Les conteneurs Docker seront traités dans un prochain guide.

      Démarrer un service via l’interface Web

      La manière la plus directe de lancer un service rapidement sur le cluster consiste à ajouter une application par le biais de l’interface Web Marathon.

      Tout d’abord, consultez l’interface Web de Marathon sur l’un de vos serveurs maîtres. N’oubliez pas que l’interface de Marathon se trouve sur le port 8080 :

      http://192.168.2.1:8080
      

      À partir de là, vous pouvez cliquer sur le bouton « New App » dans le coin supérieur droit. Cela fera apparaître une superposition dans laquelle vous pouvez ajouter des informaions sur votre nouvelle application :

      Nouvelle application Marathon

      Complétez les champs avec les exigences de votre application. Seules les champs suivants sont obligatoires

      • ID : un ID unique que l’utilisateur choisi pour identifier un processus. Vous pouvez utiliser ce que vous voulez, mais il doit être unique.
      • Command : il s’agit de la commande réelle que Marathon exécutera réellement. Il s’agit du processus qui sera surveillé et redémarré en cas d’échec.

      En utilisant ces informations, vous pouvez configurer un service simple qui imprime simplement « hello » et se met en veille pendant 10 secondes. Nous allons appeler ce « hello » :

      Application simple de Marathon

      Une fois que vous reviendrez à l’interface, le service passera de « Deploying » à « Running » :

      Application Marathon en cours d'exécution

      Environ toutes les 10 secondes, l’élément « Tasks/Instances » passera de « 1/1 » à « 0/1 » au fur et à mesure que la quantité de mise en veille passe et le service s’arrête. Ensuite, Marathon redémarre automatiquement la tâche. Nous pouvons voir ce processus plus clairement dans l’interface Web de Mesos sur le port 5050 :

      http://192.168.2.1:5050
      

      Ici, vous pouvez voir le processus se terminer et être redémarré :

      Tâche de redémarrage de Mesos

      En cliquant sur « Sandbox » et que « stdout » d’une des tâches, vous pouvez voir la sortie « hello » en cours de production :

      Sortie Mesos

      Démarrage d’un service via l’API

      Nous pouvons également soumettre des services via l’API Marathon. Pour cela, il vous faudra y transmettre un objet JSON contenant tous les champs que la superposition contenait.

      Il s’agit d’un processus relativement simple. Encore une fois, les seuls champs requis sont id pour l’identificateur de processus et cmd qui contient la commande réelle à exécuter.

      Donc, nous devons créer un fichier JSON appelé hello.json avec ces informations :

      nano hello.json
      

      À l’intérieur, la spécification minimum devrait ressembler à ce qui suit :

      {
        "id": "hello2",
        "cmd": "echo hello; sleep 10"
      }
      

      Ce service fonctionnera correctement. Cependant, si nous souhaitons réellement émuler le service que nous avons créé dans l’IU web, nous devons ajouter quelques champs supplémentaires. Ces valeurs seront configurées par défaut dans l’IU web et nous pouvons les répliquer ici :

      {
        "id": "hello2",
        "cmd": "echo hello; sleep 10",
        "mem": 16,
        "cpus": 0.1,
        "instances": 1,
        "disk": 0.0,
        "ports": [0]
      }
      

      Sauvegardez et fermez le fichier JSON une fois que vous aurez fini.

      Ensuite, nous pouvons le soumettre en utilisant l’API Marathon. La cible est l’un de nos services maître de Marathon sur le port 8080 et le point de terminaison est /v2/apps. La charge de données de notre fichier, que nous nous pouvons y lire curl en utilisant la balise -d avec la balsise @ pour indiquer un fichier.

      La commande ressemblera à ceci :

      curl -i -H 'Content-Type: application/json' -d@hello2.json 192.168.2.1:8080/v2/apps
      

      Si nous regardons l’interface Marathon, nous pouvons voir que l’ajout à bien été effectué. Il semble avoir exactement les mêmes propriétés que notre premier service :

      Deux services Marathon

      Vous pouvez surveiller et accéder au nouveau service exactement de la même manière que le premier service.

      Conclusion

      À ce stade, vous devriez avoir un cluster Mesosphere qui fonctionne. Pour le moment, nous avons uniquement abordé la configuration de base. Vous devriez cependant être en mesure de voir les possibilités qu’offre le système Mesosphere.

      Dans les futurs guides, nous allons voir comment déployer des conteneurs Docker sur votre cluster et utiliser certains outils plus en profondeur.



      Source link

      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 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