Server administrieren - wo fange ich an?

    Mein Problem: Beim aufrufen von https://Orilla-IP:3000 bekomme ich folgende Meldung:

    Meine Gedankengänge bis jetzt...


    1) ufw deaktivieren, um auszuschließen, dass es irgendwie trotzdem an der Firewall liegt ⇒ ohne Erfolg


    2) Apache stoppen, um auzuschließen das mit der Webserver irgendwie dazwischenfunkt, auch wenn das für mich keinen Sinn ergeben hätte. Aaaaaber was heißt das schon ^^ ⇒ ohne Erfolg.


    3) https://Orilla-IP:3000 über mein Smartphone (Netz) aufzurufen, um meinen PC/Browser als Fehlerquelle auszuschließen


    Wie komme ich eigentlich in den node server, welcher jetzt unter wiki.service läuft?

    [RS] 2000 G9 | Cyber Quack

    [VPS] 2000 ARM G11 | 1000 G9 | 200 G8 | Secret | A | mikro G11s | 4x nano G11s
    [WH] 8000 SE | 4000 SE | 2000 SE

    Nachdem du den Dienst mit dem Systemd Service gestartet hast, konntest du dich immer noch nicht lokal (über 127.0.0.1) verbinden? Solang das nicht funktioniert, brauchst du den externen Zugriff gar nicht zu testen. Da müssen wir mal ansetzen. Du bist mir auch immer noch die Ausgabe von "ss -tulpn" schuldig ;)

    Zitat von Paul

    Nachdem du den Dienst mit dem Systemd Service gestartet hast, konntest du dich immer noch nicht lokal (über 127.0.0.1) verbinden? Solang das nicht funktioniert, brauchst du den externen Zugriff gar nicht zu testen.

    Doch, das funktioniert. Habe ich vermutlich nicht erwähnt.

    Code
    sudouser@orilla:~/wikijs$ telnet 127.0.0.1 3000
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.


    Zitat von Paul

    Du bist mir auch immer noch die Ausgabe von "ss -tulpn" schuldig ;)

    Code
    sudouser@orilla:~/wikijs$ ss -tulpn
Netid    State     Recv-Q    Send-Q       Local Address:Port         Peer Address:Port    Process
tcp      LISTEN    0         511              127.0.0.1:3000              0.0.0.0:*        users:(("node",pid=2991,fd=19))
tcp      LISTEN    0         244              127.0.0.1:5432              0.0.0.0:*
tcp      LISTEN    0         128                0.0.0.0:22                0.0.0.0:*
tcp      LISTEN    0         511                      *:80                      *:*
tcp      LISTEN    0         244                  [::1]:5432                 [::]:*
tcp      LISTEN    0         4096                     *:4949                    *:*
tcp      LISTEN    0         128                   [::]:22                   [::]:*

    [RS] 2000 G9 | Cyber Quack

    [VPS] 2000 ARM G11 | 1000 G9 | 200 G8 | Secret | A | mikro G11s | 4x nano G11s
    [WH] 8000 SE | 4000 SE | 2000 SE

    Danke 1

    Ha, da haben wir es doch.

    Code
    127.0.0.1:3000

    Das heißt, der Dienst hört ausschließlich auf 127.0.0.1. Von extern kommst du da also gar nicht drauf. Egal wie deine Firewall konfiguriert ist. Das musst du in der lokalen wikijs config.yml ändern. Standardmäßig sollte das eigentlich auf 0.0.0.0 stehen. Hast du da was geändert? Ansonsten könntest du das mal machen und den Wert "bindIP" entsprechend setzen.

    Zitat von Bud

    bindIP 127.0.0.1

    Keine Ahnung wie ich darauf gekommen bin... Aber vielen vielen Dank Paul


    Ich bekomme bei der Wiki.js-Installation zwar folgende Fehlermeldung...

    EACCES: permission denied, mkdir '/home/sudouser/wikijs/data/cache'

    ...aber ich meine, ich habe eine mögliche Lösung gefunden. Ich probiere es mal aus und melde mich dann, für den Rest des Abends geb ich euch erstmal frei ;)

    [RS] 2000 G9 | Cyber Quack

    [VPS] 2000 ARM G11 | 1000 G9 | 200 G8 | Secret | A | mikro G11s | 4x nano G11s
    [WH] 8000 SE | 4000 SE | 2000 SE

    Gefällt mir 1
    Zitat von Bud

    Keine Ahnung wie ich darauf gekommen bin... Aber vielen vielen Dank Paul


    Ich bekomme bei der Wiki.js-Installation zwar folgende Fehlermeldung...

    EACCES: permission denied, mkdir '/home/sudouser/wikijs/data/cache'

    ...aber ich meine, ich habe eine mögliche Lösung gefunden. Ich probiere es mal aus und melde mich dann, für den Rest des Abends geb ich euch erstmal frei ;)

    Prima! In dem Systemd Service File hast du ja angegeben unter welchem User der Dienst laufen soll (Normalerweise sollte jeder Dienst auch seinen eigenen User und sein eigenes Home Verzeichnis haben - z.B. /var/lib/wikijs - aber das ist ein anderes Thema für später.). Dieser User sollte dann auch der Owner des Verzeichnisses sein, in dem du die Wiki Installation getätigt hast. Vermutlich dürfte daher folgendes schon reichen

    Code
    sudo chown -R <USER> /home/sudouser/wikijs

    Dabei ist <USER> der User, den du in dem Service File angegeben hast (evtl. sogar dein sudouser, was zwar ungünstig wäre, aber technisch zumindest funktioniert). Ggfs. dann noch den "data" Ordner selbst erstellen (mkdir /home/sudouser/wikijs/data). Könnte auch sein, dass er den cache Ordner nicht erstellen kann, weil data schon fehlt.

    Wenn ich das alles ohne sudouser machen will, am Ende einfach chown - R keinsudouser /home/keinsudouser und dann passts?

    [RS] 2000 G9 | Cyber Quack

    [VPS] 2000 ARM G11 | 1000 G9 | 200 G8 | Secret | A | mikro G11s | 4x nano G11s
    [WH] 8000 SE | 4000 SE | 2000 SE

    Ich habe heute Morgen an meinem munin-master zwei Versuche gestartet, bzw. Änderungen durchgeführt. Aus...

    ... habe ich zuerst ...

    ...und dann folgendes...

    ... gemacht. An den IPs hat sich ja nie etwas geändert, aber trotzdem hat Munin alle vorher erfassten Daten gelöscht. Ich denke mal, das lag daran das ich in der ersten Abänderung den Nodes einen neuen Namen verpasst habe? Wenn ja: Schade das munin dann gleich alle Daten löscht, denn der Server ist ja der gleiche, ich habe ihn nur unbenannt...

    [RS] 2000 G9 | Cyber Quack

    [VPS] 2000 ARM G11 | 1000 G9 | 200 G8 | Secret | A | mikro G11s | 4x nano G11s
    [WH] 8000 SE | 4000 SE | 2000 SE

    Einmal editiert, zuletzt von Bud ()

    Mit Munin selbst kenne ich mich nicht aus, aber das ist mit vielen Software Lösungen so. Das ist ja deine Konfiguration und das in den eckigen Klammern wird der genaue Identifier sein. Du hast ihn geändert, also ist es was neues :) Bei Icinga ist das auch so. Sonst müsste im Hintergrund irgendeine für dich unsichtbare ID gepflegt werden oder ähnliches...

    Zitat von Valkyrie

    Mit Munin selbst kenne ich mich nicht aus, aber das ist mit vielen Software Lösungen so. Das ist ja deine Konfiguration und das in den eckigen Klammern wird der genaue Identifier sein. Du hast ihn geändert, also ist es was neues :) Bei Icinga ist das auch so. Sonst müsste im Hintergrund irgendeine für dich unsichtbare ID gepflegt werden oder ähnliches...

    Finde ich sehr schade. Letztendlich ist es die IP, die ich Monitoren will...

    Zitat von ThomasChr

    Nur zur Sicherheit: Das hier kennst du?

    https://www.linuxatemyram.com

    Kann mir jemand erklären, warum sich meine zwei VPS 200 G8 so unterschiedlich verhalten? Beide haben zur Zeit der Grafiken nur ufw, fail2ban und munin-node unter Debian 12 am laufen.

    [RS] 2000 G9 | Cyber Quack

    [VPS] 2000 ARM G11 | 1000 G9 | 200 G8 | Secret | A | mikro G11s | 4x nano G11s
    [WH] 8000 SE | 4000 SE | 2000 SE

    Zitat von Bud

    Kann mir jemand erklären, warum sich meine zwei VPS 200 G8 so unterschiedlich verhalten?

    Unterschiedlich lange Uptimes? Hast du auf dem einen Befehle ausgeführt, Konfigurationen angeschaut oder ähnliches?

    Ansonsten brauch dich das eigentlich gar nicht stören :)

    Zitat von Valkyrie

    Unterschiedlich lange Uptimes? Hast du auf dem einen Befehle ausgeführt, Konfigurationen angeschaut oder ähnliches?

    Ansonsten brauch dich das eigentlich gar nicht stören :)

    Nein, ich hab beide Server 1:1 parallel aufgesetzt... Es stört mich nicht, hat mich nur interessiert ^^

    [RS] 2000 G9 | Cyber Quack

    [VPS] 2000 ARM G11 | 1000 G9 | 200 G8 | Secret | A | mikro G11s | 4x nano G11s
    [WH] 8000 SE | 4000 SE | 2000 SE

    Zitat von Bud

    Ich denke mal, das lag daran das ich in der ersten Abänderung den Nodes einen neuen Namen verpasst habe?

    Ja, so ist das.

    Wenn du mal in /var/lib/munin/ reinschaust, siehts du, wie munin das strukturiert.

    Die alten Daten dürften dort noch liegen. Wenn du also den Namen wieder zurückänderst, solltest du die alten Daten in den Graphen wieder sehen.

    Zitat von tab

    Unterschiedliche Einstellungen bei ufw und/oder fail2ban? Eventuell auch mal in die Logfiles reinschauen, vielleicht ist ja bei einem der beiden mehr Aktivität von aussen.

    Nein und auch in den logs finde ich nichts.

    Zitat von aRaphael

    Ja, so ist das.

    Wenn du mal in /var/lib/munin/ reinschaust, siehts du, wie munin das strukturiert.

    Die alten Daten dürften dort noch liegen. Wenn du also den Namen wieder zurückänderst, solltest du die alten Daten in den Graphen wieder sehen.

    Ohne das recherchiert zu haben: Ich vermute mal, die alten Daten in das neue Verzeichnis zu kopieren ist keine gute Idee? ^^

    [RS] 2000 G9 | Cyber Quack

    [VPS] 2000 ARM G11 | 1000 G9 | 200 G8 | Secret | A | mikro G11s | 4x nano G11s
    [WH] 8000 SE | 4000 SE | 2000 SE

    Einmal editiert, zuletzt von Bud ()

    Zitat von Bud

    Ohne das recherchiert zu haben: Ich vermute mal, die alten Daten in das neue Verzeichnis zu kopieren ist keine gute Idee? ^^

    Ausprobiert habe ich das noch nicht. ^^

    Falls du das testen willst, dann musst du aber u.U. auch die Dateinamen ändern, auf die aktuellen. (Falls die anders sind)

    Zitat von Bud

    Nein und auch in den logs finde ich nichts.

    Ohne das recherchiert zu haben: Ich vermute mal, die alten Daten in das neue Verzeichnis zu kopieren ist keine gute Idee? ^^

    Naja, die Hauptunterschiede sind ja die Caches (Felder "cache", "slab_cache"), Dateien , Verzeichnisse, inodes usw. Bei Orilla hat das System wohl einfach mehr mit Dateien gearbeitet als bei Pangar, diese ins RAM geladen und sie dort belassen, weil das RAM seither nicht anderweitig benötigt wurde.


    Was die einzelnen Felder bedeuten kann man z.B. hier nachlesen:

    https://grace.mit.edu/munin/PostgreSQL/grace/memory.html


    Edit: LOL, vergiss den Link, kannst du ja eh unter deiner eigenen munin-Anzeige anschauen. Hatte mich schon gewundert, wo ich das wohl gefunden habe :D;(

    Zitat von Valkyrie

    Ob das wirklich alles anzeigt, kann ich nicht beurteilen.

    Sieht nicht so aus. Bei einem meiner Server zeigt munin an, dass 12 GB für Cache genutzt werden, slabtop zeigt mir aber viel weiniger an.

    Da wird wohl nur der slab-cache berücksichtigt. (Was ja dem Namen nach auch zu erwarten ist ;) )

    Zitat von aRaphael

    Ausprobiert habe ich das noch nicht. ^^

    Falls du das testen willst, dann musst du aber u.U. auch die Dateinamen ändern, auf die aktuellen. (Falls die anders sind)

    Ach, so wichtig ist das nicht. Aber ich bin froh, dass ich diesen „Fehler“ jetzt gemacht habe, und nicht erst in einem Jahr... Finde es trotzdem noch schade, so kann ich meine Server nie umfunktionieren bzw. umbenennen oder gar in eine andere Gruppe stecken, ohne alle Daten zu „verlieren“ (Ja, ich weiß, sind noch vorhanden...)

    Zitat von Valkyrie

    Ich habe gerade den interessanten Befehl slabtop -s c gefunden mit dem man sich den Cache ansehen kann.

    Da sehe ich bei mir hauptsächlich sehr viel Disk Caching. Ob das wirklich alles anzeigt, kann ich nicht beurteilen.


    Zitat von tab

    Naja, die Hauptunterschiede sind ja die Caches (Felder "cache", "slab_cache"), Dateien , Verzeichnisse, inodes usw. Bei Orilla hat das System wohl einfach mehr mit Dateien gearbeitet als bei Pangar, diese ins RAM geladen und sie dort belassen, weil das RAM seither nicht anderweitig benötigt wurde.

    Der einzige Unterschied, der mir jetzt noch einfällt: Orilla ist ein zurückgespielter Snapshot, Pangar neu aufgesetzt. Aber der Snapshot von Orilla ist identisch mit der Installation von Pangar. Also sind vermutlich noch "Reste" von vor dem Snapshot im RAM?

    [RS] 2000 G9 | Cyber Quack

    [VPS] 2000 ARM G11 | 1000 G9 | 200 G8 | Secret | A | mikro G11s | 4x nano G11s
    [WH] 8000 SE | 4000 SE | 2000 SE