SystemD im Userspace: Unterschied zwischen den Versionen
(RAM Kontigente) |
(XDG_RUNTIME_DIR) |
||
Zeile 3: | Zeile 3: | ||
Auch ein normaler Account ohne besondere Privilegien kann SystemD nutzen, um Prozesse im Userspace zu starten und zu kontrollieren. Auf der Hostsharing Managed Plattform hat jeder Account mit einer gültigen Login-Shell die Möglichkeit Dienste unter Kontrolle von SystemD zu starten. In einem Webspace im Shared Hosting ist es zwingend SystemD als Prozessmonitor für eigene Serverdienste zu nutzen, auf einem Managed Server ist es die empfohlene Vorgehensweise ("Best practice"). | Auch ein normaler Account ohne besondere Privilegien kann SystemD nutzen, um Prozesse im Userspace zu starten und zu kontrollieren. Auf der Hostsharing Managed Plattform hat jeder Account mit einer gültigen Login-Shell die Möglichkeit Dienste unter Kontrolle von SystemD zu starten. In einem Webspace im Shared Hosting ist es zwingend SystemD als Prozessmonitor für eigene Serverdienste zu nutzen, auf einem Managed Server ist es die empfohlene Vorgehensweise ("Best practice"). | ||
== RAM | == RAM Kontingente == | ||
Ab November 2024 unterstützt die Managed Plattform ein RAM Kontigent pro Managed Webspace. Mitglieder buchen für ihre Webspaces jeweils ein RAM Kontigent in Schritten von jeweils 128 Ḿegabyte. Das unterstützt uns besser bei der verursachergerechten Verteilung der Hardwarekosten, als es vorher mit einer Pauschale pro Serverdienst der Fall war. Änderungen des RAM Kontingents für einen Webspace nimmt der Server unter [mailto:service@hostsharing.net service@hostsharing.net] entgegen, wie es bei anderen Paketoptionen die Vorgehensweise ist. | Ab November 2024 unterstützt die Managed Plattform ein RAM Kontigent pro Managed Webspace. Mitglieder buchen für ihre Webspaces jeweils ein RAM Kontigent in Schritten von jeweils 128 Ḿegabyte. Das unterstützt uns besser bei der verursachergerechten Verteilung der Hardwarekosten, als es vorher mit einer Pauschale pro Serverdienst der Fall war. Änderungen des RAM Kontingents für einen Webspace nimmt der Server unter [mailto:service@hostsharing.net service@hostsharing.net] entgegen, wie es bei anderen Paketoptionen die Vorgehensweise ist. | ||
Zeile 18: | Zeile 18: | ||
Hier sind aktuell 58,4 Megabyte RAM genutzt, es sind 14,8 Gigabyte RAM für den Webspace verfügbar. Der verfügbare RAM ist das gebuchte Kontingent. Das gebuchte Kontigent wird im Shared Hosting deutlich kleiner sein. | Hier sind aktuell 58,4 Megabyte RAM genutzt, es sind 14,8 Gigabyte RAM für den Webspace verfügbar. Der verfügbare RAM ist das gebuchte Kontingent. Das gebuchte Kontigent wird im Shared Hosting deutlich kleiner sein. | ||
== Eigene Serverdienste mit SystemD == | |||
In diesem Wiki findet sich viele Beispiele für SystemD-Units zur Kontrolle eines Serverdienstes. An dieser Stelle folgen Erläuterungen die wichtigsten Einstellungen. | |||
Voraussetzung: In ''HSAdmin'' wird ein Service-User zur Rechtetrennung dieses Dienstes von anderen Anwendungen angelegt. In diesem Artikel soll der Beispiel-User ''xyz00-service'' im Webspace ''xyz00'' sein. Dieser User bekommt bei der Einrichtung eine gültige Shell zugewiesen, so dass man sich per ''ssh'' oder vom Paketadmin mit einem Befehl ''sudo -i -u xyz00-service'' anmelden kann. Die Umgebungsvariable ''XDG_RUNTIME_DIR'' sollte im Environment des Users gesetzt sein, wenn man erfolgreich angemeldet ist. Das testet man mit | |||
echo $XDG_RUNTIME_DIR | |||
Die Ausgabe sollte sein: | |||
xyz00-service@h01:~$ echo $XDG_RUNTIME_DIR | |||
/run/user/112345 | |||
xyz00-service@h01:~$ | |||
Dabei wird statt ''112345'' eine andere Zahl erscheinen. Diese Zahl ist die numerische User-Id des Users ''xyz00-service'' im System. |
Version vom 23. Oktober 2024, 17:29 Uhr
SystemD ist seit einigen Jahren das Init-System aller gängigen Linux-Distributionen. Der init-Prozess ist im laufenden System der Prozess mit der Nummer "1", der allen anderen Prozesse als Kind-Prozesse verwaltet.
Auch ein normaler Account ohne besondere Privilegien kann SystemD nutzen, um Prozesse im Userspace zu starten und zu kontrollieren. Auf der Hostsharing Managed Plattform hat jeder Account mit einer gültigen Login-Shell die Möglichkeit Dienste unter Kontrolle von SystemD zu starten. In einem Webspace im Shared Hosting ist es zwingend SystemD als Prozessmonitor für eigene Serverdienste zu nutzen, auf einem Managed Server ist es die empfohlene Vorgehensweise ("Best practice").
RAM Kontingente
Ab November 2024 unterstützt die Managed Plattform ein RAM Kontigent pro Managed Webspace. Mitglieder buchen für ihre Webspaces jeweils ein RAM Kontigent in Schritten von jeweils 128 Ḿegabyte. Das unterstützt uns besser bei der verursachergerechten Verteilung der Hardwarekosten, als es vorher mit einer Pauschale pro Serverdienst der Fall war. Änderungen des RAM Kontingents für einen Webspace nimmt der Server unter service@hostsharing.net entgegen, wie es bei anderen Paketoptionen die Vorgehensweise ist.
Den aktuell belegten RAM eines Webspace xyz00 kann man sich mit dem Befehl
systemctl status pacs-xyz00.slice
ansehen.
Etwa in der fünften Zeile der Ausgabe findet man eine Angabe der Form:
Memory: 58.4M (max: 14.8G available: 14.8G)
Hier sind aktuell 58,4 Megabyte RAM genutzt, es sind 14,8 Gigabyte RAM für den Webspace verfügbar. Der verfügbare RAM ist das gebuchte Kontingent. Das gebuchte Kontigent wird im Shared Hosting deutlich kleiner sein.
Eigene Serverdienste mit SystemD
In diesem Wiki findet sich viele Beispiele für SystemD-Units zur Kontrolle eines Serverdienstes. An dieser Stelle folgen Erläuterungen die wichtigsten Einstellungen.
Voraussetzung: In HSAdmin wird ein Service-User zur Rechtetrennung dieses Dienstes von anderen Anwendungen angelegt. In diesem Artikel soll der Beispiel-User xyz00-service im Webspace xyz00 sein. Dieser User bekommt bei der Einrichtung eine gültige Shell zugewiesen, so dass man sich per ssh oder vom Paketadmin mit einem Befehl sudo -i -u xyz00-service anmelden kann. Die Umgebungsvariable XDG_RUNTIME_DIR sollte im Environment des Users gesetzt sein, wenn man erfolgreich angemeldet ist. Das testet man mit
echo $XDG_RUNTIME_DIR
Die Ausgabe sollte sein:
xyz00-service@h01:~$ echo $XDG_RUNTIME_DIR /run/user/112345 xyz00-service@h01:~$
Dabei wird statt 112345 eine andere Zahl erscheinen. Diese Zahl ist die numerische User-Id des Users xyz00-service im System.