Uptime Kuma auf Webhosting 8000

Seid ihr sicher dass Webspaces dafür gedacht sind, dauerlaufenden Scripte 24/7 im Hintergrund laufen zu lassen?

Mir wurde mal ein Reseller Webspace gesperrt weil ein Kunde dieses installiert hatte.
Ein kleiner VPS wie der Piko oder Nano reichen dafür völlig aus wenn man wenige Dienste damit bobachtet.

Ein klares Jein.

Quote from tab

Ein klares Jein.

Das Stoppen der Scripte bei Nichtzugriff von Außen halte ich da noch für das moderateste Mittel...

Das Ziel war, meine 2-3 Dienste bei Netcup im Webspace inkl. E-Mail für die Familie zu zentralisieren. Nur scheinbar ist es im Fall von Uptime Kuma keine gute Idee. Eine eigene VM ist eine Option, im Moment läuft es "Hosting auf Asteroids" und dort wird es dann erstmal bleiben. Danke euch! ✌🏻

Auch wenn das Thema hier schon etwas älter ist:

Ich habe es inzwischen geschafft, Uptime Kuma 2.5.3 auf einem netcup Webhosting 8000 mit Plesk zum Laufen zu bekommen.

Mich hat das zwar einen ganzen Nachmittag gekostet, aber dank der vorherigen Beiträge, der verlinkten Anleitungen und natürlich etwas KI-Unterstützung funktioniert es jetzt.

Für alle, die Uptime Kuma ebenfalls direkt unter Plesk auf einem netcup Webhosting installieren möchten, hier meine Vorgehensweise:

1. Subdomain anlegen

Zuerst eine Subdomain für Uptime Kuma anlegen, z. B.:

uptime.example.de

Bei den Apache & nginx-Einstellungen den:

Proxy-Modus: AUS

setzen.

2. Git-Repository erstellen

In Plesk über die Git-Funktion ein neues Remote-Repository erstellen.

Repository-URL:

https://github.com/louislam/uptime-kuma.git

Anschließend das Repository per Pull herunterladen und den Branch master verwenden.

3. package.json anpassen & index.html löschen

Nach dem Git-Pull die vorhandene index.html aus dem Document Root entfernen.

In der package.json müssen zwei Einträge angepasst werden, da node bei netcup/Plesk nicht direkt über den normalen PATH aufgerufen werden kann.

Diese beiden Einträge:

"start-server": "node server/server.js",

"download-dist": "node extra/download-dist.js",

ersetzen durch:

"start-server": "/opt/plesk/node/24/bin/node server/server.js",

"download-dist": "/opt/plesk/node/24/bin/node extra/download-dist.js",

Ich habe folgende Node.js-Version verwendet:

24.20.0

4. Node.js-Einstellungen in Plesk

Als Dokumentenstamm und Anwendungsstamm habe ich jeweils denselben Ordner der Subdomain verwendet.

Beispielsweise:

/httpdocs/example.de/uptime.example.de

Als Anwendungsstartdatei später:

server/server.js

5. npm install

Jetzt in Plesk unter Node.js → Run Node.js commands:

install --ignore-scripts

run download-dist

verwenden.

Ein normales npm install schlägt bei mir fehl, weil bei den Installationsskripten node nicht gefunden wird.

6. SQLite manuell nachinstallieren

Durch --ignore-scripts werden allerdings auch die Installationsskripte der nativen Abhängigkeiten übersprungen. Dadurch fehlt anschließend das benötigte SQLite-Binary.

Deshalb in der package.json unter scripts folgendes Script ergänzen:

"sqlite-install": "/opt/plesk/node/24/bin/node node_modules/.bin/node-pre-gyp install --fallback-to-build --directory node_modules/@louislam/sqlite3"

Danach wieder in Plesk unter Node.js → Run Node.js commands ausführen:

run sqlite-install

Bei erfolgreicher Ausführung sollte ungefähr Folgendes erscheinen:

Quote

[@louislam/sqlite3] Success:

".../node_modules/@louislam/sqlite3/lib/binding/..."

is installed via remote

Damit ist das native SQLite-Modul vorhanden.

7. Uptime Kuma einrichten

Danach kann die Subdomain aufgerufen werden:

https://uptime.example.de

Jetzt sollte die normale Uptime-Kuma-Einrichtung erscheinen.

Ich habe dabei SQLite verwendet, da das für meine Zwecke völlig ausreicht.

Falls die Anwendung nach Änderungen nicht sofort reagiert, einfach die Node.js-Anwendung in Plesk neu starten.

8. Cloudflare

Falls die Subdomain über Cloudflare proxied wird, würde ich für die Einrichtung bzw. Fehlersuche unter Caching → Configuration den Developer Mode aktivieren.

Dadurch wird der Cloudflare-Cache für die Domain vorübergehend umgangen und Änderungen an Uptime Kuma werden direkt vom Server geladen.

Nach Abschluss der Einrichtung kann der Developer Mode wieder deaktiviert werden.

Uptime Kuma data-Ordner absichern

Ich habe zusätzlich versucht, Uptime Kuma mit MariaDB/MySQL zu betreiben. Die Verbindung funktioniert und Kuma legt die benötigten Tabellen auch an, danach ist allerdings kein Zugriff auf Kuma mehr möglich und Passenger wirft einen Fehler. Warum genau das passiert, habe ich bisher noch nicht herausgefunden.

Mit SQLite funktioniert Uptime Kuma dagegen problemlos.

Ein weiteres Problem ist der data-Ordner, da dort unter anderem die kuma.db liegt. Da ich den nginx Proxy-Modus für Uptime Kuma deaktiviert habe, funktioniert eine .htaccess dort nicht.

Ich habe deshalb den Datenordner mit der Uptime-Kuma-Umgebungsvariable DATA_DIR aus dem öffentlichen Anwendungsverzeichnis verschoben:

DATA_DIR=/var/www/vhosts/hostingXXXXXX.XXXX.netcup.net/httpdocs/XXXX.de/status-data

Damit liegt der Datenordner außerhalb des Document Roots von status.XXXX.de. Uptime Kuma kann weiterhin normal darauf zugreifen, während die Dateien nicht mehr direkt über die Kuma-Subdomain erreichbar sind.

Bei einer bereits bestehenden Installation kann man den vorhandenen data-Ordner normalerweise einfach in den neuen Ordner verschieben und anschließend DATA_DIR auf den neuen Pfad setzen. Die bestehenden Daten bleiben dadurch erhalten.

Zusätzlich kann man im netcup-Plesk für den status-data-Ordner einfach die Funktion „Geschütztes Verzeichnis“ verwenden. Damit lässt sich der direkte Webzugriff auf den Ordner komfortabel sperren, ohne selbst eine .htaccess erstellen zu müssen.

Vermutlich geht das auch im Ordner selbst des Dokumentenstamm das man einfach den data Ordner sichert. Das habe ich jedoch noch nicht getestet.

Mit dieser Vorgehensweise läuft Uptime Kuma bei mir inzwischen problemlos auf dem netcup Webhosting 8000

Ich konnte anschließend bereits einen Gameserver-Ping als Monitor einrichten und dieser wird auch regelmäßig abgefragt.

Vielleicht hilft die Anleitung ja dem Nächsten, der nicht ebenfalls einen kompletten Nachmittag damit verbringen möchte. 😄

Aktuell ist das nur die Installation und die Funktion ist gegeben.

Jetzt bin ich jedoch an dem Problem von d4nny dran. Da die Anwendung nach ca. 20-25 Minuten gekillt wird.

Man könnte das jetzt mit einem Cronjob der jede Minute nen Keep Alive macht umgehen, aber da bin ich überfragt was die Fair Use Regelung von Netcup angeht. Garantierter RAM ist das eine. Aber nen nicht garantierten CPU Kern dauerhaft zu beanspruchen das andere.

Und aktuell bin ich an der Umstellung zu MariaDB dran, damit die Zugriffe auf SQLite abgefangen werden, was beim SharedHost ja auch so ne Sache ist.

Braucht es dazu das komplette 8000er?

Oder läuft es dann dort nur so nebenher mit?

Quote from ASS

Braucht es dazu das komplette 8000er?

Oder läuft es dann dort nur so nebenher mit?

Ab 4000er wegen Node.

Quote from Vene

Ab 4000e

Wo liegt dann der Vorteil zu nem kleinen Vserver auf dem es auf jeden Fall und Stressfrei läuft?

Quote from MyMattes

Bleibt die Frage, ob die getrickste Installation mit überschaubarem Aufwand gewartet werden kann und dann natürlich das Thema fair use...

Also nachdem es jetzt seit gestern erstmal nur läuft ohne Cronjob oder dergleichen um es am Leben zu erhalten. Ist mir aufgefallen das es die Nacht scheinbar durchlief und erst so gegen 7-8 Uhr das erste Mal gekillt wurde.

Also ich vermute stark, daß der Passenger die Auslastung prüft und die Anwendung dann killt, wenn langsam wieder Auslastung auf dem Host ist, solange kein Zugriff erfolgt.

Ich würde es mal mit nem Cronjob probieren und schauen ob das soweit passt.

Quote from ASS

Wo liegt dann der Vorteil zu nem kleinen Vserver auf dem es auf jeden Fall und Stressfrei läuft?

Das Stressfrei ist halt bei mir leider nicht der Fall gewesen. Denke da trifft die Aussage von MyMattes ganz gut. Und da ich mein Hostung hier jetzt seit fast 10 Jahren habe und es nie richtig genutzt habe, ist das zB etwas was mal Sinn ergibt um meine anderen Dienste zu überwachen. Hier weiß ich das das Hosting läuft. Ein Uptime Kuma auf einem Server laufen zu lassen, der selbst überwacht werden soll, ist halt nur Semi gut.

Quote from MyMattes

und Du auch, da bin ich sicher

Nunja, es ist ein Monitoring Tool, das macht fast alles von innen nach außen und man kann praktisch alles schon in der Firewall sperren. Die eigene Abfrage dann über 100Mbit Vlan und man hat 0 Ports von außen offen.

Und Installation und Wartung sind um Längen einfacher. Und man ist sicher, dass man die Resourcen nutzt, wie es gedacht ist.

Allein dass das Teil wohl alle 20 Minuten gekillt wird zeigt schon, dass das so nicht gewollt ist...

Und der Vserver ist preislich vermutlich auch noch billiger...

Quote from Vene

Und da ich mein Hostung hier jetzt seit fast 10 Jahren habe und es nie richtig genutzt habe

Ah, es ist also eh vorhanden. War ja Teil meiner Frage

Ja, sowas kenn ich. Ich zahl seit geschätzten 10 Jahren ein BigEi und da läuft glaub ich gerademal eine statische Webseite drauf

Ich hab das übrigens als Addon in meinem Homeassistant laufen...

Quote from ASS

Ah, es ist also eh vorhanden. War ja Teil meiner Frage

Achso ja, hab das nicht raus gelesen.

Genau istn Blitzverkauf von 2016 oder 2017 gewesen. Hab auch noch nen VPS 10 G7. Der hat zwar nur 128MB RAM, aber könnte sein das er das auch noch packt. Aber der läuft aktuell als VPN und ist für meine großen RDP Server als Login gewhitelistet.

Wenn erstmal alles eingerichtet ist, lässt man sowas dann auch gern mal paar Jahre liegen und denkt sich, mmh hab noch so viel Speicher und Domains die leer liegen.

Ich hab bei Oracle im FreeTier auch 2 Server. Den einen auf arm Basis und eben den E2 Micro mit 1GB Ram. Und da hatte ich das Uptime Kuma drauf und weiß nicht, das lief irgendwie nicht so schön, das ich nen täglichen reboot einstellen musste weil der Server sonst teilweise so lahm wird das nen SSH Login über 5Min dauert. Aber während des reboot wird dann halt nicht überwacht.

Wie gesagt, sollte netcup hier das außerhalb ihrer Fair Use Regelung sehen, wirds wieder abgeschaltet. Fand es nur interessant, ob ich es hinbekomme

Wenn man in Uptime Kuma den Monitor Type="PUSH" erstellt, den Heartbeat Interval="1500" setzt und anschließend in Plesk einen Cronjob mit Aufgabentyp="URL abrufen", der passenden URL und Cron-Stil="*/15 * * * *" setzt. Soll das seit Monaten funktionieren...hab ich gehört. 😉

Quote from d4nny

Wenn man in Uptime Kuma den Monitor Type="PUSH" erstellt, den Heartbeat Interval="1500" setzt und anschließend in Plesk einen Cronjob mit Aufgabentyp="URL abrufen", der passenden URL und Cron-Stil="*/15 * * * *" setzt. Soll das seit Monaten funktionieren...hab ich gehört. 😉

Du monitorst damit ja die Verfügbarkeit von dem Webhosting 🤷

Quote from d4nny

Wenn man in Uptime Kuma den Monitor Type="PUSH" erstellt, den Heartbeat Interval="1500" setzt und anschließend in Plesk einen Cronjob mit Aufgabentyp="URL abrufen", der passenden URL und Cron-Stil="*/15 * * * *" setzt. Soll das seit Monaten funktionieren...hab ich gehört. 😉

Es reicht ein Cronjob der einfach die Webseite alle 2 Minuten aufruft. Der Prozess wird trzd nach einer gewissen Zeit gekillt aber dann direkt wieder aufgerufen und gestartet.