Nützliche Bash-Befehlszeilen-Tipps und Tricks Beispiele - Teil 6

In diesem Artikel werfen wir einen Blick darauf, wie wir einige grundlegende Informationen zur Hardware-, System- und Betriebssystemkonfiguration direkt über die Eingabeaufforderung in Ihrem Terminal abrufen. Diese Informationen zu haben und zu wissen, wo sie zu finden sind, hilft oft bei der Konfiguration eines Systems, bei der Suche nach optimalen Hardware- und Softwarelösungen und generell bei der Kontrolle über das Linux-System, das Sie besitzen oder verwalten.

Wir werden uns hauptsächlich auf alltägliche Informationen konzentrieren, die regelmäßig benötigt werden. Um tiefer in die Tiefe zu gehen, sind oft einige Online-Suchen erforderlich, um die Ausrichtung zunächst besser zu definieren, und dann sind oft zusätzliche Fähigkeiten erforderlich, um die angezeigten Ergebnisse oder Ausgaben zu interpretieren.

Zum Beispiel werden wir uns die Ausgabe von vmstat nicht ansehen, obwohl wir herausfinden können, wie Sie herausfinden können, welche CPU sich in Ihrem System befindet, ohne die Haube zu öffnen. Wir werden uns auch einige grundlegende Variablen zur Ressourcenbegrenzung und die damit verbundenen Bedenken ansehen. Die Zielgruppe für diesen Artikel ist somit Anfänger bis mittelweit fortgeschritten.

Dieser Artikel ist Teil der Reihe "Nützliche Bash-Befehlszeilentipps und -tricks".

In diesem Tutorial lernen Sie:

• Nützliche Tipps, Tricks und Methoden zur Bash-Befehlszeile
• So interagieren Sie mit der Bash-Befehlszeile auf fortgeschrittene Weise
• Wie du deine Bash-Fähigkeiten insgesamt schärfst und ein kompetenterer Bash-Benutzer wirst

Nützliche Bash-Befehlszeilen-Tipps und Tricks Beispiele – Teil 6

Verwendete Softwareanforderungen und Konventionen

Beispiel 1: Welche CPU befindet sich in Ihrem System?

Oft möchten wir schnell herausfinden, welche CPU sich im System befindet, ohne die Box zu öffnen. Das Öffnen des physischen Computers ist auch etwas schwierig, wenn Sie einen Server auf der anderen Seite des Planeten verwalten. Das Herausfinden der CPU-Details ist einfach und unkompliziert:

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

Im ersten Befehl haben wir die dynamische Datei /proc/cpuinfo abgefragt, die die aktuelle CPU auflistet, wie sie vom Betriebssystem erkannt wurde. Es gibt 16 Zeilen (wie im zweiten Befehl zu sehen) mit genau der gleichen Ausgabe, daher listen wir nur die erste Zeile mit dem Befehl head -n1 auf. Beachten Sie, dass wir diese Befehle auch wie folgt schreiben können:

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

Sie können jedoch die cat-Methode verwenden, um die vollständige Ausgabe (cat /proc/cpuinfo) zu untersuchen, da dort viele interessante Informationen über Ihren Prozessor angezeigt werden. Die Anzahl von 16 ist darauf zurückzuführen, dass es 16 Threads in dieser speziellen CPU gibt, sodass das Betriebssystem sie als 16 einzelne Prozessoren oder Threads ansieht, die verwendet werden sollen.

Herausfinden Ihres Betriebssystems und Ihrer Version

Bei der Verwaltung eines Remote-Servers möchten wir häufig sicherstellen, dass er auf die richtige Version eines Betriebssystems gepatcht ist. Um mehr darüber zu erfahren, welches Betriebssystem Ihr Rechner verwendet und welche Revision er hat, führen Sie einfach cat /etc/*release* aus:

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

Zum Vergleich hier die Ausgabe desselben Befehls auf einem Raspbian-basierten Raspberry Pi 4:

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"

Sobald Sie sich an diese Abkürzung erinnern, werden Sie sie bald in vielen Situationen verwenden. Die tatsächlich hier gezeigten Dateien, zumindest unter Ubuntu, sind: /etc/lsb-release und /etc/os-release. Auf Raspbian gibt es nur /etc/os-release.

Betriebs- vs. Systemgrenzen

Viele Betriebssystemgrenzen sind unter Linux standardmäßig implementiert. Sie sind auf eine geschickte Art und Weise festgelegt, da Sie oft erst dann auf sie stoßen, wenn Sie ein DevOps- oder ähnlicher Ingenieur sind, der den Durchsatz einer Reihe von Remote-Servern maximiert.

Das Ändern dieser Betriebssystemvariablen erfordert einige Kenntnisse über jede von ihnen, und das Festlegen dieser Variablen kann manchmal einige Tests erfordern, um vernünftige Grenzen festzulegen.

Eine weitere Überlegung ist, dass Systemgrenzwerte erreicht werden können, lange bevor ein vom Betriebssystem konfigurierter Grenzwert erreicht wird, und dies gilt insbesondere, wenn Sie solche Betriebssystemgrenzwerte auf einen sehr hohen Wert festlegen. Das ist auch der Grund, warum es solche Betriebssystem-Limits überhaupt gibt: um zu verhindern, dass das Betriebssystem die Kontrolle über eine physische Systemressource (Festplatte, RAM, Speicher, CPU) aufgrund einer schlecht verwalteten Obergrenze/Begrenzung verliert.

Daher birgt die Änderung eines Betriebssystem-basierten Limits verschiedene Risiken. Es ist nicht nur ziemlich einfach, sie zu groß zu setzen, was dazu führt, dass das Betriebssystem oft die Kontrolle über bestimmte Ressourcen verliert, sondern das Ändern einiger Variablen birgt auch einige Sicherheitsrisiken.

Nehmen wir zum Beispiel an, dass ein Hacker eine Fork-Bombe auf das System werfen würde. Eine Fork Bomb ist keine echte Bombe, sondern eher ein softwarebasierter Exploit, der dazu führt, dass das System wiederholt neue Shells und Threads aufgabelt, um einen "Fork Bomb"-Organisationsprozess zu ermöglichen. Wenn die Anzahl der erlaubten Forks irgendwie durch Ändern einer oder mehrerer Systemvariablen geändert worden wäre, könnten dem System bald die CPU-Ressourcen ausgehen, wenn es versucht, bis ins Unendliche zu forken.

Ein weiterer Aspekt, den Sie hier berücksichtigen sollten, ist, wie sicher der Server oder die Workstation ist, die Sie verwalten. Wenn es sich in einer DMZ-Zone in einem Rechenzentrum befindet, ansonsten von anderen Servern isoliert ist und nur für Aufgaben mit geringen Berechtigungen (wie Tests) verwendet wird, kann es durchaus akzeptabel sein, eher hohe Grenzwerte festzulegen. Wenn derselbe Server Produktionscode pusht und Release-Pakete signiert, wäre eine viel sorgfältigere Verwaltung der Systemressourcen ratsam.

Sie können sehen, dass das Ändern dieser Variablen etwas Fachwissen und Erfahrung erfordert. Dennoch sind die meisten von ihnen leicht zu verstehen und haben gebräuchliche englische Namen.

Die gebräuchlichsten sind in /etc/security/limits.conf festgelegt. Um beispielsweise die maximale Anzahl der geöffneten Dateien auf 300000 zu erhöhen, können Sie die folgenden Zeilen zu /etc/security/limits.conf hinzufügen:

* soft nofile 300000
* hard nofile 300000

Dadurch werden 300k Dateien auf einmal geöffnet. Das Maximum, das für diese Variablen festgelegt werden kann, beträgt 1048576.

Beachten Sie, dass es einen Unterschied zwischen 'weichen' und 'harten' Grenzwerten gibt: Harte Grenzwerte können nur durch Zugriff auf Root-Ebene weiter angehoben werden, während jeder Prozess das Limit senken kann. Dies ist aus Sicherheitsgründen ideal, da Nicht-Root-Prozesse nicht in der Lage sind, ein Limit zu überschreiten. Ein Soft-Limit kann durch einen bestimmten Prozess jederzeit geändert werden.

Es gibt viele andere ähnliche Einstellungen, die in dieser Datei geändert werden können. Um eine allgemeine Vorstellung zu erhalten, können Sie ulimit -a verwenden, um die Grenzwerte zu sehen, die zu diesem Zeitpunkt auf Ihr System anwendbar sind.

Die nächstbekannteste Datei, wenn es um die Optimierung von Systemressourcen geht, ist /etc/sysctl.conf. In dieser Datei ist es möglich, viele Kernel-Parameter fein abzustimmen. Zum Beispiel, um die maximale Anzahl von PIDs (Prozesskennungen) auf 500k und die Swappiness Ihres Systems (wie leicht das Betriebssystem speicherbasierte Informationen mit plattenbasierten Informationen austauscht – auch 'swapping' genannt) auf 5 zu setzen (eine Einstellung, die das Swapping erheblich einschränkt), können Sie Folgendes zu /etc/sysctl.conf hinzufügen:

kernel.pid_max=500000
vm.swappiness=5

Es wird nicht empfohlen, eine der oben gezeigten Einstellungen ohne weitere Recherchen zu implementieren und dann speziell auf Ihr System abzustimmen. Oft führt das Erhöhen einer Variablen auf eine höhere Einstellung zu keinen Problemen, es sei denn, es tritt ein unvorhergesehenes Ereignis ein, wie das zuvor beschriebene Hackerbeispiel.

Schlussfolgerung

In diesem Artikel haben wir uns angesehen, wie unser Betriebssystem die Ressourcen unter Kontrolle hält und was die wichtigsten Konfigurationsdateien in diesem Zusammenhang sind. Wir haben auch herausgefunden, wie wir herausfinden können, welche CPU sich im System befindet und welches Betriebssystem und welche Version wir verwenden. Wenn man diese grundlegenden Dinge kennt, kann man sich eingehender mit den spezifischen Einstellungen befassen, die in /etc/security/limits.conf und /etc/sysctl.conf vorgenommen wurden, und Linux-basierte Systeme sicherer verwalten. Genießen!