Recherche de site Web

Exemples utiles de trucs et astuces en ligne de commande Bash - Partie 6

Dans cet article, nous allons voir comment obtenir des informations de base sur le matériel, le système et la configuration du système d’exploitation directement à partir de l’invite de commande de votre terminal. Disposer de ces informations et savoir où les trouver est souvent utile lors de la configuration d’un système, de la recherche de solutions matérielles et logicielles optimales et, d’une manière générale, du contrôle du système Linux que vous possédez ou gérez.

Nous nous concentrerons principalement sur les informations quotidiennes, celles qui sont requises régulièrement. Pour aller plus en profondeur, il faut souvent quelques recherches en ligne pour mieux définir l’alignement, puis nécessite souvent des compétences supplémentaires pour interpréter les résultats ou les résultats affichés.

Par exemple, nous n’examinerons pas la sortie de vmstat, mais nous découvrirons comment savoir quel processeur se trouve dans votre système sans ouvrir le capot. Nous examinerons également certaines variables de base de limite de ressources et les préoccupations environnantes. Le public cible de cet article est donc de débutant à moyennement avancé.

Cet article fait partie de la série de conseils et astuces utiles de la ligne de commande Bash.

Dans ce tutoriel, vous allez apprendre :

  • Conseils, astuces et méthodes utiles de la ligne de commande Bash
  • Comment interagir avec la ligne de commande Bash de manière avancée
  • Comment affiner vos compétences globales en Bash et devenir un utilisateur plus compétent de Bash

Exemples utiles de trucs et astuces en ligne de commande Bash - Partie 6

Configuration logicielle requise et conventions utilisées

Exemple 1 : Quel processeur y a-t-il dans votre système ?

Souvent, nous voulons savoir rapidement quel processeur se trouve dans le système, sans ouvrir la boîte. L’ouverture de l’ordinateur physique est également un peu difficile si vous gérez un serveur à l’autre bout de la planète. Découvrir les détails du processeur est simple et direct :

cat /proc/cpuinfo | grep 'model name' | head -n1
model name  : Intel(R) Core(TM) i9-9900K CPU @ 3.60GHz
cat /proc/cpuinfo | grep 'model name' | wc -l
16

Dans la première commande, nous avons interrogé le fichier dynamique /proc/cpuinfo qui répertorie le processeur actuel tel qu’il a été détecté par le système d’exploitation. Il y a 16 lignes (comme on le voit dans la deuxième commande) de la même sortie, donc nous ne listons que la première ligne à l’aide de la commande head -n1. Notez que nous pourrions également écrire ces commandes comme suit :

grep 'model name' /proc/cpuinfo | head -n1
model name  : Intel(R) Core(TM) i9-9900K CPU @ 3.60GHz
grep 'model name' /proc/cpuinfo | wc -l
16

Vous pouvez cependant utiliser la méthode cat pour explorer la sortie complète (cat /proc/cpuinfo) car il y a beaucoup d’informations intéressantes affichées sur votre processeur. Le compte de 16 est dû au fait qu’il y a 16 threads dans ce processeur particulier, de sorte que le système d’exploitation le considère comme 16 processeurs individuels, ou threads, à utiliser.

Découvrir votre système d’exploitation et votre version

Souvent, lors de la gestion d’un serveur distant, nous voulons nous assurer qu’il est corrigé selon la bonne révision d’un système d’exploitation. Pour en savoir plus sur le système d’exploitation utilisé par votre machine et sur sa révision, exécutez simplement cat /etc/*release* :

cat /etc/*release*
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=20.04
DISTRIB_CODENAME=focal
DISTRIB_DESCRIPTION="Ubuntu 20.04.1 LTS"
NAME="Ubuntu"
VERSION="20.04.1 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.1 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal

À titre de comparaison, voici le résultat de la même commande sur un Raspberry Pi 4 basé sur Raspbian :

cat /etc/*release*
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

Une fois que vous vous souviendrez de ce raccourci, vous vous retrouverez bientôt à l’utiliser dans de nombreuses situations. Les fichiers réels affichés ici, au moins sur Ubuntu, sont : /etc/lsb-release et /etc/os-release. Sur Raspbian, il n’y a que /etc/os-release.

Limites de fonctionnement et de système

De nombreuses limites du système d’exploitation sont implémentées par défaut sous Linux. Ils sont définis de manière astucieuse, car vous ne les rencontrerez souvent que lorsque vous serez un ingénieur DevOps ou similaire maximisant le débit d’un ensemble de serveurs distants.

La modification de ces variables du système d’exploitation nécessite une certaine connaissance de chacune d’entre elles, et leur définition peut parfois nécessiter des tests pour établir des limites raisonnables.

Une autre considération ici est que les limites du système peuvent être atteintes bien avant qu’une limite configurée du système d’exploitation ne soit atteinte, et cela est particulièrement vrai si vous définissez ces limites de système d’exploitation sur un nombre très élevé. C’est aussi la raison pour laquelle de telles limites du système d’exploitation sont là en premier lieu : pour empêcher le système d’exploitation de perdre le contrôle d’une ressource physique du système (disque, RAM, mémoire, CPU) en raison d’un cap/limite mal géré.

Ainsi, la modification des limites d’un système d’exploitation comporte divers risques. Non seulement il est assez facile de les définir trop grands, ce qui fait que le système d’exploitation perd souvent le contrôle de ressources spécifiques, mais la modification de certaines variables comporte également certains risques de sécurité.

Par exemple, supposons qu’un pirate lance une bombe à la fourchette sur le système. Une bombe de fourche n’est pas une vraie bombe, mais plutôt un exploit logiciel qui aboutit à ce que le système bifurque de nouvelles coquilles et de nouveaux fils vers un processus d’organisation de type « bombe de fourche ». Si le nombre de fourches autorisées avait été modifié d’une manière ou d’une autre en changeant une ou plusieurs variables système, le système pourrait rapidement manquer de ressources CPU en essayant de forker jusqu’à l’infini.

Un autre aspect à prendre en compte ici est le niveau de sécurité du serveur ou du poste de travail que vous gérez au départ. S’il se trouve dans une zone DMZ d’un centre de données, isolé des autres serveurs et utilisé uniquement pour des tâches à faibles privilèges (comme les tests), il peut être tout à fait acceptable de fixer des limites plutôt élevées. Si ce même serveur poussait le code de production et signait des packages de version, une gestion beaucoup plus prudente des ressources système serait conseillée.

Vous pouvez voir comment la modification de ces variables nécessite une certaine expertise et expérience. Pourtant, la plupart d’entre eux sont faciles à comprendre et ont des noms anglais courants.

Les plus courants sont définis dans /etc/security/limits.conf. Par exemple, pour augmenter considérablement le nombre maximum de fichiers ouverts à 300000, vous pouvez ajouter les lignes suivantes à /etc/security/limits.conf :

* soft nofile 300000
* hard nofile 300000

Cela permettra d’ouvrir 300k fichiers à la fois. Le maximum qui peut être défini pour ces variables est de 1048576.

Notez qu’il y a une différence entre les limites « souples » et les limites « dures » : les limites strictes ne peuvent être augmentées que par un accès au niveau racine, alors que n’importe quel processus peut abaisser la limite. C’est idéal pour des raisons de sécurité, car les processus non root ne pourront pas dépasser une limite. Une limite souple peut être modifiée par un processus donné à tout moment.

Il existe de nombreux autres paramètres similaires qui peuvent être modifiés à partir de ce fichier. Pour avoir une idée générale, vous pouvez utiliser ulimit -a pour voir les limites applicables à votre système à ce moment-là.

Le fichier suivant le plus important lorsqu’il s’agit de régler les ressources système est /etc/sysctl.conf. Dans ce fichier, il est possible d’affiner de nombreux paramètres du noyau. Par exemple, pour définir le nombre maximum de PID (identificateurs de processus) à 500k et la permutation de votre système (la facilité avec laquelle le système d’exploitation échangera des informations basées sur la mémoire avec des informations basées sur le disque - également appelée « permutation ») à 5 (un paramètre qui limite considérablement l’échangement), vous pouvez ajouter ce qui suit à /etc/sysctl.conf :

kernel.pid_max=500000
vm.swappiness=5

Nous vous déconseillons d’implémenter l’un des paramètres indiqués ci-dessus sans effectuer de recherches supplémentaires et de les ajuster spécifiquement à votre système. Souvent, l’élévation d’une variable à un paramètre plus élevé ne produira aucun problème, à moins qu’un événement imprévu ne se produise, comme l’exemple du pirate informatique évoqué précédemment.

Conclusion

Dans cet article, nous avons vu comment notre système d’exploitation garde les ressources sous contrôle, et quels sont les principaux fichiers de configuration en relation avec cela. Nous avons également découvert comment savoir quel processeur se trouve dans le système, et quel système d’exploitation et sa version nous utilisons. Sachant ces éléments de base, on peut explorer davantage les paramètres spécifiques définis dans /etc/security/limits.conf et /etc/sysctl.conf et gérer les systèmes basés sur Linux avec plus de confiance. Jouir!

Articles connexes: