Wie verwendet man `systemctl` zur Verwaltung von systemd-Einheiten und -Diensten?

Systemd ist der Standard-System- und Dienstmanager, der in den meisten modernen Linux-Distributionen verwendet wird. Er ist dafür zuständig, das System beim Bootvorgang hochzufahren und die laufenden Dienste zu verwalten. Er übernimmt die Prozess-ID 1 (PID 1), was bedeutet, dass er der allererste vom Linux-Kernel gestartete Prozess im Benutzerbereich ist und bis zum Herunterfahren des Systems weiterläuft.

Im Gegensatz zu älteren Init-Systemen wie SysV verwendet systemd Einheiten (Units), um Systemressourcen zu definieren und zu verwalten. Jede Einheit wird durch eine Konfigurationsdatei beschrieben, die als Unit-Datei bezeichnet wird und systemd mitteilt, wie diese Ressource zu verwalten ist. Einheiten können Dienste, Geräte, Einhängepunkte oder sogar Gruppen von Einheiten darstellen, die als Ziele (Targets) bezeichnet werden und während des Bootvorgangs wie Kontrollpunkte fungieren.

Das wichtigste Werkzeug für die Interaktion mit systemd ist systemctl, mit dem Sie Dienste und andere Einheiten starten, stoppen, neu starten, aktivieren, deaktivieren und deren Status überprüfen können.

Um Systemprotokolle im Zusammenhang mit systemd und seinen Diensten einzusehen, können Sie journalctl verwenden, einen Befehl, der Meldungen aus dem systemd-Journal anzeigt.

In diesem Leitfaden werden wir untersuchen, wie man den Befehl systemctl verwendet, ein Werkzeug zur Verwaltung des Initialisierungssystems unter Linux. Wir werden auch erläutern, wie Sie Dienste steuern, deren Status anzeigen, Systemzustände anpassen und mit Konfigurationsdateien interagieren können.

Es ist wichtig zu erwähnen, dass systemd zwar in vielen gängigen Linux-Distributionen das Standard-Init-System ist, es jedoch nicht von jeder Distribution verwendet wird. Wenn Sie eine Fehlermeldung wie „bash: systemctl: command not found“ erhalten, basiert Ihr System wahrscheinlich auf einem anderen Init-System, und systemctl ist nicht verfügbar.

Verwaltung von Diensten mit systemctl

Eine der Kernaufgaben eines Init-Systems besteht darin, wichtige Komponenten zu starten, nachdem der Linux-Kernel vollständig geladen wurde. Zu diesen Komponenten, die oft als Userland-Prozesse bezeichnet werden, gehören verschiedene Dienste und Daemons, die für einen reibungslosen Betrieb des Systems sorgen. Ein Init-System spielt zudem eine fortlaufende Rolle bei der Steuerung dieser Dienste, während das System läuft.

Im Falle von systemd werden die von ihm verwalteten Schlüsselelemente als Units bezeichnet. Units werden in Konfigurationsdateien definiert, die als Unit-Dateien bezeichnet werden, und jede Datei legt fest, wie eine bestimmte Ressource behandelt werden soll. Der Typ der Ressource wird durch die Dateiendung (Suffix) angegeben.

Speziell für die Verwaltung von Diensten verwendet systemd Service-Units, deren Dateinamen auf .service enden. Bei der Verwendung von systemctl-Befehlen können Sie die Endung .service jedoch in der Regel weglassen – systemd geht automatisch davon aus, dass Sie sich auf einen Dienst beziehen.

Starten und Beenden von Diensten mit systemctl

Um einen Dienst manuell zu starten und die in seiner Unit-Datei definierten Aktionen auszulösen, verwenden Sie den folgenden Befehl:

$ sudo systemctl start application.service

Da systemd erkennen kann, dass Sie mit einem Dienst arbeiten, könnten Sie auch Folgendes ausführen:

$ sudo systemctl start application

Beide Formate funktionieren, aber der Übersichtlichkeit halber wird in diesem Leitfaden bei der Arbeit mit Service-Units durchgehend das Suffix .service verwendet.

Um einen derzeit laufenden Dienst zu stoppen, lautet der Befehl:

$ sudo systemctl stop application.service

Systemctl-Dienst neu starten

Um einen Dienst vollständig neu zu starten (d. h. ihn zu stoppen und anschließend erneut zu starten), verwenden Sie:

$ sudo systemctl restart application.service

Einige Dienste unterstützen das Neuladen ihrer Konfigurationsdateien, ohne dass ein vollständiger Neustart erforderlich ist. Um ein Neuladen der Konfiguration auszulösen, führen Sie Folgendes aus:

$ sudo systemctl reload application.service

Wenn Sie sich nicht sicher sind, ob der Dienst das Neuladen unterstützt, können Sie einen sichereren, kombinierten Befehl verwenden:

$ sudo systemctl reload-or-restart application.service

Dadurch wird versucht, die Konfiguration neu zu laden, sofern dies unterstützt wird. Ist dies nicht der Fall, wird der Dienst stattdessen neu gestartet.

Aktivieren und Deaktivieren von Diensten mit systemctl

Die bisher behandelten Befehle helfen bei der Verwaltung von Diensten innerhalb der aktuellen Sitzung. Wenn Sie jedoch möchten, dass ein Dienst beim Systemstart automatisch gestartet wird, müssen Sie ihn aktivieren.

Systemctl-Dienst aktivieren (systemd enable service)

Um einen Dienst so zu konfigurieren, dass er beim Systemstart gestartet wird, führen Sie Folgendes aus:

$ sudo systemctl enable application.service

Dieser Befehl erstellt einen symbolischen Link von der Datei des Dienstes – die sich normalerweise in /lib/systemd/system/ oder /etc/systemd/system/ befindet – zu einem Verzeichnis, das systemd beim Systemstart nach automatisch startenden Diensten durchsucht (üblicherweise etwas wie /etc/systemd/system/some_target.target.wants).

Systemctl-Dienst deaktivieren

Um zu verhindern, dass ein Dienst beim Systemstart gestartet wird, verwenden Sie:

$ sudo systemctl disable application.service

Dadurch wird der symbolische Link entfernt, sodass systemd den Dienst nicht mehr automatisch startet.

Beachten Sie, dass das Aktivieren eines Dienstes lediglich dessen Start beim Systemstart plant – der Dienst wird in der aktuellen Sitzung nicht sofort gestartet. Wenn Sie den Dienst aktivieren und sofort starten möchten, müssen Sie sowohl „enable“ als auch „start“ ausführen.

Dienststatus überprüfen

Um zu überprüfen, ob ein Dienst läuft, und einige grundlegende Informationen dazu anzuzeigen, können Sie Folgendes verwenden:

$ systemctl status application.service

Dadurch werden Details angezeigt, z. B. ob der Dienst aktiv ist, wie lange er bereits läuft und die neuesten Protokolleinträge dazu.

Diese Zusammenfassung bietet Ihnen einen schnellen Zustandscheck des Dienstes und hebt etwaige Probleme hervor, falls solche bestehen.

Überprüfen bestimmter Dienstzustände

Wenn Sie lediglich überprüfen möchten, ob ein Dienst läuft, können Sie folgenden Befehl verwenden:

$ systemctl is-active application.service

Dieser Befehl gibt entweder „active“ oder „inactive“ aus. Er gibt zudem einen Exit-Code zurück – 0 bedeutet, dass der Dienst aktiv ist, was nützlich sein kann, wenn Sie Überprüfungen in einem Skript automatisieren.

Um herauszufinden, ob ein Dienst so eingestellt ist, dass er beim Systemstart ausgeführt wird, führen Sie folgenden Befehl aus:

$ systemctl is-enabled application.service

Dies gibt entweder „enabled“ oder „disabled“ zurück, und wie zuvor kann der Exit-Code des Befehls das Ergebnis anzeigen.

Um schließlich zu prüfen, ob ein Dienst fehlgeschlagen ist, d. h. ob beim Starten oder Ausführen ein Fehler aufgetreten ist, verwenden Sie:

$ systemctl is-failed application.service

Dies gibt „failed“ zurück, wenn etwas schiefgelaufen ist, oder „active“, wenn der Dienst ordnungsgemäß läuft. Wurde der Dienst absichtlich gestoppt, wird möglicherweise „inactive“ oder „unknown“ angezeigt. Ein Exit-Code von 0 signalisiert einen Fehler, während 1 jeden anderen Status anzeigt.

Anzeigen des allgemeinen Systemstatus (systemctl list services)

Bisher haben wir uns Befehle angesehen, die bei der Verwaltung einzelner Dienste helfen, aber wenn Sie einen umfassenderen Überblick über das System als Ganzes erhalten möchten, bietet systemctl auch dafür Befehle an.

Aktive Einheiten anzeigen

Um zu sehen, welche Einheiten derzeit laufen oder aktiv sind, können Sie den Befehl list-units verwenden:

$ systemctl list-units

Dadurch werden alle Einheiten angezeigt, die derzeit aktiv von systemd verwaltet werden. Die Ausgabe sieht in etwa so aus:

Hier ist die Bedeutung der einzelnen Spalten:

• UNIT: Der eigentliche Name der Einheit.
• LOAD: Gibt an, ob systemd die Einheitsdatei erfolgreich gelesen und in den Speicher geladen hat.
• ACTIVE: Ein allgemeiner Indikator dafür, ob die Einheit ordnungsgemäß läuft.
• SUB: Ein detaillierterer Status auf niedrigerer Ebene, der vom spezifischen Typ der Einheit abhängt.
• DESCRIPTION: Eine kurze Zusammenfassung, die den Zweck der Einheit erläutert.

Standardmäßig werden hier nur Einheiten angezeigt, die derzeit aktiv sind. Tatsächlich liefert die Ausführung von systemctl ohne zusätzliche Argumente dieselbe Ausgabe.

$ systemctl

Alle Einheiten anzeigen (aktive und inaktive)

Wenn Sie alle Einheiten sehen möchten, die systemd entweder zu laden versucht hat oder die sich derzeit im Speicher befinden – auch wenn sie gerade nicht laufen –, können Sie das Flag --all hinzufügen:

$ systemctl list-units --all

Dies umfasst Einheiten, die gelaufen sind und dann gestoppt wurden, oder sogar Einheiten, die systemd zu laden versucht hat, aber nicht finden konnte.

Um die Anzeige einzugrenzen, können Sie nach bestimmten Zuständen filtern. Wenn Sie beispielsweise nur inaktive Einheiten anzeigen möchten, können Sie folgenden Befehl ausführen:

$ systemctl list-units --all --state=inactive

Sie können auch nach Typ filtern. Um beispielsweise nur Dienste anzuzeigen:

$ systemctl list-units --type=service

Alle Unit-Dateien auflisten (unabhängig davon, ob sie geladen sind oder nicht)

Die obigen Befehle zeigen nur Einheiten an, mit denen systemd interagiert hat – entweder durch Laden oder durch den Versuch, sie auszuführen. Um alle auf dem System verfügbaren Unit-Dateien anzuzeigen (unabhängig davon, ob systemd sie berührt hat oder nicht), verwenden Sie:

$ systemctl list-unit-files

Dies listet alle Unit-Definitionsdateien auf, die in den systemd-Verzeichnissen gefunden wurden. Dazu gehören auch Dateien, die systemd nie zu laden versucht hat. Die Ausgabe sieht wie folgt aus:

Es gibt zwei Spalten:

• UNIT FILE: Der Name der Unit-Datei.
• STATE: Ob die Unit-Datei aktiviert, deaktiviert, statisch oder maskiert ist.

Hier ist die Bedeutung dieser Zustände:

• enabled: Die Unit ist so eingestellt, dass sie bei Bedarf automatisch startet.
• disabled: Die Unit startet nicht automatisch, kann aber manuell gestartet werden.
• static: Diese Unit verfügt über keinen „install“-Abschnitt, was bedeutet, dass sie nicht dafür ausgelegt ist, direkt aktiviert zu werden – stattdessen soll sie durch Abhängigkeiten ausgelöst werden.
• masked: Die Unit wurde explizit deaktiviert, sodass sie unter keinen Umständen gestartet werden kann (mehr dazu im nächsten Abschnitt).

Dadurch erhalten Sie eine vollständige Übersicht über alle Units im System, unabhängig davon, ob systemd tatsächlich versucht hat, sie zu verwenden oder nicht.

Wie arbeitet man mit Systemd-Einheiten?

Bisher haben wir uns hauptsächlich auf das Starten und Beenden von Diensten sowie auf die Anzeige grundlegender Details zu Systemd-Einheiten und deren Dateien konzentriert. Systemd bietet jedoch mehrere Befehle, um tiefer in die Informationen zu den Einheiten einzutauchen und diese präziser zu steuern.

Anzeigen der Datei einer Unit

Um die tatsächliche Unit-Datei anzuzeigen, die systemd in den Speicher geladen hat, können Sie den Befehl `cat` verwenden (dies wurde in systemd Version 209 eingeführt). Um beispielsweise die Unit-Datei für den Dienst `apache2` anzuzeigen, würden Sie Folgendes ausführen:

$ systemctl cat apache2.service

Dieser Befehl gibt den Inhalt der Unit-Datei aus, die systemd derzeit bekannt ist. Dies ist besonders nützlich, wenn die Datei kürzlich geändert wurde oder wenn benutzerdefinierte Überschreibungen angewendet wurden. Der angezeigte Inhalt spiegelt den aktuellen Status der Datei wider, wie systemd ihn sieht.

Überprüfen der Unit-Abhängigkeiten

Wenn Sie überprüfen möchten, auf welche anderen Units ein bestimmter Dienst angewiesen ist, ist der Befehl list-dependencies hilfreich. Um beispielsweise zu sehen, von welchen Einheiten der Dienst „sshd“ abhängt, würden Sie Folgendes ausführen:

$ systemctl list-dependencies sshd.service

Dies zeigt eine baumartige Ansicht der Einheiten an, die „sshd.service“ entweder direkt benötigt oder wünscht (optionale Abhängigkeiten). Systemd-Targets, bei denen es sich um spezielle Gruppierungen von Einheiten handelt, die Systemzustände repräsentieren, zeigen ebenfalls ihre eigenen internen Abhängigkeiten an.

Um alle rekursiven Abhängigkeiten anzuzeigen, können Sie die Option --all verwenden:

$ systemctl list-dependencies --all sshd.service

Sie können diese Ansicht auch umkehren, um herauszufinden, welche Einheiten von dem angegebenen Dienst abhängen. Fügen Sie dazu das Flag --reverse hinzu:

systemctl list-dependencies --reverse sshd.service

Wenn Sie überprüfen möchten, welche Einheiten so konfiguriert sind, dass sie vor oder nach dem betreffenden Dienst starten, können Sie diese Optionen verwenden:

systemctl list-dependencies sshd.service --before

systemctl list-dependencies sshd.service --after

Anzeigen von Unit-Eigenschaften

Jede Unit verfügt über zahlreiche Eigenschaften, die steuern, wie systemd mit ihr umgeht. Um alle diese Eigenschaften für eine bestimmte Unit anzuzeigen, verwenden Sie den Befehl show. Dadurch werden detaillierte Unit-Daten im Format Schlüssel=Wert angezeigt:

systemctl show sshd.service

Dadurch werden Dutzende von Eigenschaften ausgegeben, darunter die Ziele, zu denen diese Unit gehört, etwaige Konflikte mit anderen Units sowie ihre Abhängigkeitsbeziehungen.

Wenn Sie nur eine bestimmte Eigenschaft anzeigen möchten, können Sie mit der Option -p filtern. Um beispielsweise zu überprüfen, mit welchen Units der sshd-Dienst in Konflikt steht:

systemctl show sshd.service -p Conflicts

Einheiten maskieren und entmaskieren

Manchmal reicht es nicht aus, einen Dienst einfach zu stoppen oder zu deaktivieren – möglicherweise möchten Sie unter keinen Umständen zulassen, dass er gestartet wird. Hier kommt das Maskieren ins Spiel. Wenn eine Einheit maskiert ist, verknüpft systemd sie mit /dev/null und verhindert so effektiv, dass sie manuell oder automatisch gestartet wird.

Um eine Einheit zu maskieren, führen Sie Folgendes aus:

$ sudo systemctl mask apache2.service

Wenn Sie anschließend alle Unit-Dateien überprüfen, werden Sie feststellen, dass apache2.service als „masked“ gekennzeichnet ist:

$ systemctl list-unit-files

Wenn Sie versuchen, einen maskierten Dienst zu starten, lehnt systemd dies ab und zeigt eine Fehlermeldung an:

$ sudo systemctl start apache2.service

Um den Dienst wieder starten zu können, heben Sie die Maskierung mit folgendem Befehl auf:

$ sudo systemctl unmask apache2.service

Dadurch wird die Sperre aufgehoben und die Unit in ihren normalen Zustand zurückversetzt, sodass sie wieder wie jeder andere Dienst gestartet oder aktiviert werden kann.

Wie bearbeitet man Unit-Dateien mit systemctl?

Obwohl die Erläuterung der genauen Struktur und Syntax von Unit-Dateien den Rahmen dieses Leitfadens sprengen würde, bietet systemd integrierte Tools, mit denen Sie bei Bedarf direkt Änderungen vornehmen können. Diese Bearbeitungsfunktionen wurden in systemd Version 218 eingeführt.

Bearbeiten mit systemctl

Mit dem Befehl `edit` können Sie über eine einfache Oberfläche Änderungen an einer Unit-Datei vornehmen. Standardmäßig öffnet dieser Befehl eine leere Override-Datei speziell für die Unit, die Sie ändern möchten. Um beispielsweise einen Override für `nginx.service` zu erstellen, würden Sie Folgendes verwenden:

$ sudo systemctl edit nginx.service

Dadurch wird ein Verzeichnis unter `/etc/systemd/system` mit dem Namen der Unit gefolgt von `.d` erstellt – zum Beispiel `nginx.service.d`. In diesem Verzeichnis legt systemd eine Datei namens override.conf ab, in die Sie Ihre benutzerdefinierte Konfiguration einfügen können.

Beim Start des Dienstes kombiniert systemd diese Override-Datei mit der Haupt-Unit-Datei und räumt dabei den im Override definierten Einstellungen Vorrang ein. Dies erleichtert die Anpassung bestimmter Optionen, ohne die Originaldatei direkt bearbeiten zu müssen.

Bearbeiten der vollständigen Unit-Datei

Wenn Sie die gesamte Unit-Datei ändern möchten, anstatt einen kleinen Override zu erstellen, können Sie die Option --full verwenden:

$ sudo systemctl edit --full nginx.service

Dieser Befehl lädt die aktuelle vollständige Datei in Ihren Editor, sodass Sie alle erforderlichen Änderungen vornehmen können. Sobald Sie den Editor speichern und schließen, speichert systemd die geänderte Datei unter /etc/systemd/system, die Vorrang vor der Standarddatei unter /lib/systemd/system hat.

Entfernen benutzerdefinierter Änderungen

Sollten Sie Ihre Änderungen jemals rückgängig machen müssen, können Sie einfach entweder das Override-Verzeichnis oder die benutzerdefinierte Unit-Datei selbst löschen.

So entfernen Sie ein Override-Verzeichnis:

$ sudo rm -r /etc/systemd/system/nginx.service.d

So entfernen Sie eine vollständig angepasste Unit-Datei:

$ sudo rm /etc/systemd/system/nginx.service

Sobald die Dateien gelöscht sind, müssen Sie systemd neu laden, damit es die entfernten Dateien vergisst und wieder die ursprüngliche System-Unit-Datei verwendet:

sudo systemctl daemon-reload

Dadurch wird sichergestellt, dass systemd nicht mehr nach den von Ihnen entfernten Änderungen sucht oder diese anwendet.

Verwalten von Systemzuständen mit Targets

In systemd stellen Targets bestimmte Systemzustände dar, ähnlich wie traditionelle Runlevels in älteren Init-Systemen. Diese Targets sind als spezielle Unit-Dateien definiert, die auf .target enden, und sie gruppieren andere Units, um den gewünschten Zustand zu erreichen.

Standard-Target (Boot-Target)

Das System bootet in ein Standard-Target, das den Systemzustand nach dem Start bestimmt. Sie können das aktuelle Standard-Target mit folgendem Befehl überprüfen:

$ systemctl get-default

Um das Standardziel beispielsweise auf eine grafische Desktop-Umgebung zu ändern, verwenden Sie:

$ sudo systemctl set-default graphical.target

Auflisten und Anzeigen von Zielen

So zeigen Sie alle auf dem System verfügbaren Ziele an:

$ systemctl list-unit-files --type=target

So zeigen Sie nur die derzeit aktiven Ziele an:

$ systemctl list-units --type=target

Wechseln zwischen Zielen (Isolieren)

Sie können das System auf ein anderes Ziel umschalten, wobei alle nicht benötigten Dienste gestoppt und nur die für das neue Ziel erforderlichen Dienste gestartet werden. Dies erfolgt mit dem Befehl `isolate`.

Um beispielsweise von einem grafischen Desktop zu einer reinen Befehlszeilenumgebung zu wechseln:

$ sudo systemctl isolate multi-user.target

Vor dem Isolieren ist es sinnvoll zu prüfen, von welchen Diensten ein Ziel abhängt:

$ systemctl list-dependencies multi-user.target

Dadurch stellen Sie sicher, dass Sie nicht versehentlich wichtige Dienste anhalten.

Verwendung von Systemctl-Shortcuts für wichtige Ereignisse

Systemd bietet spezielle Shortcuts für die Behandlung wesentlicher Systemereignisse wie Herunterfahren, Neustarten oder den Wechsel in den Rettungsmodus. Diese Shortcuts lösen die entsprechenden Ziele aus und benachrichtigen alle angemeldeten Benutzer über das Ereignis, wodurch eine zusätzliche Kommunikationsebene geschaffen wird.

Um den Rettungsmodus (Einzelbenutzermodus) aufzurufen, können Sie folgenden Befehl ausführen:

$ sudo systemctl rescue

Dies verhält sich ähnlich wie das Isolieren von rescue.target, bietet jedoch den zusätzlichen Vorteil, dass aktive Benutzer informiert werden.

Um das System anzuhalten (alle Prozesse zu stoppen, ohne das System auszuschalten):

$ sudo systemctl halt

Um ein vollständiges Herunterfahren des Systems durchzuführen, verwenden Sie:

$ sudo systemctl poweroff

Um den Rechner neu zu starten:

$ sudo systemctl reboot

Die meisten Linux-Systeme bieten auch herkömmliche Befehle, die direkt mit systemd verknüpft sind, sodass Sie oft einfach Folgendes eingeben können:

$ sudo reboot

Diese Befehle lassen sich nahtlos in systemd integrieren und gewährleisten eine ordnungsgemäße Kommunikation sowie eine saubere Verarbeitung von Systemereignissen.

Verbessern Sie die Sicherheit von Diensten mit systemd

Die Absicherung von systemd-Diensten ist ein entscheidender Schritt, um Ihr System vor Angriffen, unbefugtem Zugriff und versehentlichen Schäden zu schützen. Nachfolgend finden Sie einen optimierten Ansatz zur Absicherung von Diensten mithilfe von systemd.

1. Verstehen Sie die Unit-Dateien der Dienste

Jeder von systemd verwaltete Dienst verfügt über eine entsprechende Unit-Datei, die festlegt, wie der Dienst ausgeführt wird, einschließlich Startprozessen, Zugriffsberechtigungen und Ressourcenbeschränkungen. Diese Dateien werden in der Regel unter /etc/systemd/system/ gespeichert und können zur Verbesserung der Sicherheit angepasst werden.

2. Dienstprivilegien einschränken

• Als Nicht-Root-Benutzer ausführen: Weisen Sie jedem Dienst einen eigenen Benutzer und eine eigene Gruppe zu, anstatt ihn als Root auszuführen. Dies verringert das Risiko, falls der Dienst kompromittiert wird.

3. Integrierte systemd-Sicherheitsoptionen nutzen

• Temporäre Verzeichnisse isolieren: Aktivieren Sie PrivateTmp, damit der Dienst über einen eigenen temporären Speicherbereich verfügt, wodurch datendienstübergreifende Datenlecks verhindert werden.
• Systemzugriff einschränken: Setzen Sie ProtectSystem, um zu begrenzen, auf welche Teile des Dateisystems der Dienst zugreifen darf. Verwenden Sie ProtectHome, um den Zugriff auf Benutzer-Home-Verzeichnisse zu blockieren.
• Verzeichniszugriff steuern: Verwenden Sie ReadOnlyPaths, um Verzeichnisse als schreibgeschützt zu kennzeichnen, und ReadWritePaths, um festzulegen, wo der Dienst Daten schreiben darf.

4. Ressourcenbeschränkungen festlegen

• CPU- und Speicherauslastung begrenzen: Verwenden Sie CPUQuota, um die CPU-Auslastung des Dienstes zu begrenzen, und MemoryLimit, um den Speicherverbrauch zu beschränken. Dies hilft, übermäßigen Ressourcenverbrauch zu verhindern, sei es absichtlich oder aufgrund von Fehlern.

5. Netzwerkzugriff verwalten

• Netzwerkpräsenz kontrollieren: Verwenden Sie „RestrictAddressFamilies“, um einzuschränken, welche Adressfamilien der Dienst nutzen darf (beispielsweise durch Deaktivieren von „AF_INET“, wenn kein Netzwerkzugriff erforderlich ist).
• Verwenden Sie „IPAddressAllow“ und „IPAddressDeny“, um Netzwerkzugriffsregeln zu erstellen, falls der Dienst kommunizieren muss.

6. Dateibesitz und Berechtigungen

• Stellen Sie korrekte Dateiberechtigungen sicher: Die vom Dienst verwendeten Dateien und Verzeichnisse sollten den richtigen Eigentümer (über chown) und restriktive Berechtigungen (über chmod) haben. Nur der erforderliche Benutzer sollte Schreibzugriff auf Konfigurationsdateien, Protokolle und Daten haben.

7. Halten Sie das System auf dem neuesten Stand und überwachen Sie die Protokolle

• Wenden Sie regelmäßig Updates an: Halten Sie sowohl das System als auch die Dienstsoftware auf dem neuesten Stand, um die neuesten Sicherheitspatches zu erhalten.
• Überwachen Sie die Dienstaktivität: Verwenden Sie journalctl, um die Protokolle des Dienstes auf Fehler, verdächtige Aktivitäten oder sicherheitsrelevante Meldungen zu überprüfen.

Fazit

In diesem Artikel haben wir gelernt, wie man den Befehl systemctl verwendet. systemctl ist das wichtigste Werkzeug zur Verwaltung von Diensten und Systemzuständen in systemd. Es dient als Hauptschnittstelle für die Interaktion mit dem Kernprozess des Systems. systemd enthält jedoch auch zusätzliche Werkzeuge wie journalctl zum Anzeigen von Protokollen und loginctl zur Verwaltung von Benutzersitzungen. Das Verständnis dieser zugehörigen Werkzeuge wird Ihnen helfen, Ihr System effektiver zu verwalten.

Wächst Ihr Unternehmen über die Grenzen des VPS-Hostings hinaus? Steigen Sie um auf die Leistung und Performance eines dedizierten Servers von BlueServers!

• Vollständig anpassbar und auf Ihre Bedürfnisse skalierbar
• Volle Serversteuerung in einer dedizierten Umgebung
• Genießen Sie unbegrenzten Datenverkehr für Ihr wachsendes Unternehmen

Bringen Sie Ihr Hosting auf die nächste Stufe – Entdecken Sie noch heute die dedizierten Server bei BlueServers!