Das längste Thema

  • Da ich ja nun auch zu den Serverhoardern gehöre,

    habe ich mal eine Auflistung meiner monatlichen Kosten gemacht.

    22.88€ für Server und Hosting und 5.20€ für Domains

    macht 28.08€

    Ich glaube ich bin noch nicht gefährdet :D

    Es gibt deutlich teurere Hobbies

    It's me, only me, pure michi 🦆

    RS: ja:thumbup: VPS: yep:thumbup: ARM: sicher:thumbup: WH: klar :thumbup:

    Domains: auch:thumbup:

  • der Adventkalender is unzuverläßig;

    dass mein Standardbrowser damit nicht zurecht kommt ist eine Sache,

    aber dass dann Tür 4 nicht aufgeht eine andere;

    bei dem Schneechaos wohl festgefroren ...

    Grüße / Greetings

    Walter H.

    RS, VPS, Webhosting - was man halt so braucht;)

    2 Mal editiert, zuletzt von mainziman (4. Dezember 2023 um 06:27)

  • Hmmm... Wollte gerade Uptime Kuma installieren, aber die Standardseite für den Download des Installskripts funktioniert nicht mehr:

    https://git.kuma.pet/install.sh

    Muss ich mal nach Alternativen suchen....

    (Oder node/npm/pm2 doch manuell installieren)

    Das Install-Script ist deprecated. Die manuelle Installation ist aber auch überschaubar.

    RS 2000+1000 G9.5 · VPS nano G11s · EiWoMiSau

  • Hmmm... Wollte gerade Uptime Kuma installieren, aber die Standardseite für den Download des Installskripts funktioniert nicht mehr:

    https://git.kuma.pet/install.sh

    Muss ich mal nach Alternativen suchen....

    (Oder node/npm/pm2 doch manuell installieren)

    Ich empfehle das offizielle Docker Image: https://hub.docker.com/r/louislam/uptime-kuma

    Bei solchen Installationsskripten wäre ich generell vorsichtig. Ich weiß, dass das momentan ziemlich in Mode ist und viele Projekte das so anbieten. Aber ein unbekanntes Skript aus dem Internet herunterladen und mit Root Rechten ausführen ist so mit das letzte was man eigentlich machen sollte. Ich würde von dieser Art der Installation generell abraten. Ja, est ist komfortabel und meist funktioniert das auch zuverlässig, aber es ist halt so eine Grundsatzregel, dass man das eigentlich nicht machen sollte. Genauso wenig wie man unbekannte Code Schnipsel nicht einfach so C&P sollte.

    Einmal editiert, zuletzt von Paul (4. Dezember 2023 um 09:21)

  • docker kommt mir nicht in die Tüte. ;)

    Ich habe das jetzt aber mal ganz anders gemacht und mir schnell ein bash-Skript gestrickt, welches im Prinzip das gleiche macht. (Per cron Server anpingen oder Seiten curlen, bei Scheitern zwei weitere Versuche starten und wenn das auch fehlschlägt bekomme ich eine eMail)

    Das funktioniert, reicht mir erstmal völlig und ich muss nix installieren :)

  • docker kommt mir nicht in die Tüte ;)

    Wobei ich mir das in diesem Fall wirklich nochmal überlegen würde ;). Sich das System mit NodeJS Abhängigkeiten und NPM zu verbasteln, ist jetzt auch nicht unbedingt die schönste Lösung. Zumal man ja gerade bei NodeJS oft darauf achten, muss, dass die benötigte Version auch der entspricht, die man für das Projekt gerade benötigt. Unter Umständen ist hier auch wieder eine zusätzliche Quelle nötig. Genau aus diesem Grund läuft bei mir alles NodeJS-basierte grundsätzlich in isolierten Containern. Bei Golang kann ich es noch verstehen, wenn die Installation im Grunde nur daraus besteht, dass man ein Binary herunterlädt und als unprivilegierter User laufen lässt. Da hat man dann im Grunde dieselbe Isolation wie in einem Container. Aber gerade, wenn dann noch zusätzliche Abhängigkeiten mit ins Spiel kommen oder bestimmte Versionen einer Sprache benötigt wird, spielen Container ihre Stärken aus, weil man dann auch das eigentliche OS aktualisieren kann ohne sich Gedanken machen zu müssen welche Applikation man damit evtl. kaputt macht.

    Man darf auch die Updates nicht vergessen. Mit Docker startet man einfach den Container mit einem neuen Tag. Die manuelle Installation von uptime-kuma muss dann wieder mit npm gemacht werden. npm hat eigentlich auf einem produktiven System auch nichts verloren. Das sollte eher der Entwicklung dienen, wo man ein fertiges Paket baut, das dann wiederum auf Prod ausgerollt werden kann. Wobei das natürlich auch etwas an mir liegen könnte, weil ich da noch etwas aus der alten Schule komme. Hier werden neue Applikationen grundsätzlich nur in Dev gebaut, dann getestet und anschließend erst über einen sicheren Weg in Prod ausgerollt.

  • Wobei ich mir das in diesem Fall wirklich nochmal überlegen würde ;). Sich das System mit NodeJS Abhängigkeiten und NPM zu verbasteln, ist jetzt auch nicht unbedingt die schönste Lösung. Zumal man ja gerade bei NodeJS oft darauf achten, muss, dass die benötigte Version auch der entspricht, die man für das Projekt gerade benötigt.

    Ja, da gebe ich dir durchaus recht.

    Ich habe ja auch nix prinzipiell gegen docker. Es gibt Anwendungsfälle, da macht es Sinn.

    Ich mag es halt nur nicht besonders. ;)

    Aber in diesem Fall ist beides nicht nötig. Ich setze erstmal auf die Minimallösung: :)

    Ich habe das jetzt aber mal ganz anders gemacht und mir schnell ein bash-Skript gestrickt, welches im Prinzip das gleiche macht. (Per cron Server anpingen oder Seiten curlen, bei Scheitern zwei weitere Versuche starten und wenn das auch fehlschlägt bekomme ich eine eMail)

    Das funktioniert, reicht mir erstmal völlig und ich muss nix installieren :)

    Da brauche ich weder docker noch nodejs/npm. :S

  • Wobei ich mir das in diesem Fall wirklich nochmal überlegen würde ;). Sich das System mit NodeJS Abhängigkeiten und NPM zu verbasteln, ist jetzt auch nicht unbedingt die schönste Lösung. Zumal man ja gerade bei NodeJS oft darauf achten, muss, dass die benötigte Version auch der entspricht, die man für das Projekt gerade benötigt. Unter Umständen ist hier auch wieder eine zusätzliche Quelle nötig. Genau aus diesem Grund läuft bei mir alles NodeJS-basierte grundsätzlich in isolierten Containern. Bei Golang kann ich es noch verstehen, wenn die Installation im Grunde nur daraus besteht, dass man ein Binary herunterlädt und als unprivilegierter User laufen lässt. Da hat man dann im Grunde dieselbe Isolation wie in einem Container. Aber gerade, wenn dann noch zusätzliche Abhängigkeiten mit ins Spiel kommen oder bestimmte Versionen einer Sprache benötigt wird, spielen Container ihre Stärken aus, weil man dann auch das eigentliche OS aktualisieren kann ohne sich Gedanken machen zu müssen welche Applikation man damit evtl. kaputt macht.

    Man darf auch die Updates nicht vergessen. Mit Docker startet man einfach den Container mit einem neuen Tag. Die manuelle Installation von uptime-kuma muss dann wieder mit npm gemacht werden. npm hat eigentlich auf einem produktiven System auch nichts verloren. Das sollte eher der Entwicklung dienen, wo man ein fertiges Paket baut, das dann wiederum auf Prod ausgerollt werden kann. Wobei das natürlich auch etwas an mir liegen könnte, weil ich da noch etwas aus der alten Schule komme. Hier werden neue Applikationen grundsätzlich nur in Dev gebaut, dann getestet und anschließend erst über einen sicheren Weg in Prod ausgerollt.

    Könnt ihr mal aufhören sowas zu schreiben? Jetzt muss ich mich wirklich noch in Docker einarbeiten... ;(

    [RS] 2000 G11 | 3x 1000 G12 Pro | 2x Vincent van Bot | Piccolo | Piccolo ARMore
    [VPS] 1000 G9 | 500 G11s | mikro G11s | 4x nano G11s | 4x piko G11s
    [WH] 8000 SE | 4000 SE | 2000 SE | 2x Spezial

  • Könnt ihr mal aufhören sowas zu schreiben? Jetzt muss ich mich wirklich noch in Docker einarbeiten... ;(

    na das haben wir Dir aber eh schon öfter nahegelegt. Sehr lohnenswert.

    RS 2000 G12 Pro BW25 (8C EPYC 9645, 16GB, 1TB) | RS 500 G12 BW25 (2C EPYC 9645, 4GB, 128GB) | RS Cyber Quack (1C,2GB,40GB)