Skip to content

NodeBB - Automatisch starten

NodeBB
  • Im Beitrag https://frank-mankel.org/topic/3/node-js-auf-dem-raspberry3-b-installieren habe ich berichtet, wie man node.js installiert. Darin liegt die ausführbare Datei node in /opt/node/bin. Das behalten wir jetzt erst mal so im Hinterkopf.

    Unter Debian arbeitet man mit systemd, ein System und Service Manager. Dieser Dienst sorgt dafür, das Dienste automatisch, z.B. beim Neustart des Servers gestartet werden. Dazu findet man im Ordner /etc/systemd/system eine ganze Reihe von Diensten. z.B.: sshd.service

    Gut, hier geht es aber um NodeBB. Von NodeBB gibt es eine Anleitung zum Thema, die findet man hier. Aber, wir verfeinern das Ganze hier noch ein wenig 😉

    nodebb.service

    [Unit]
    Description=NodeBB
    Documentation=https://docs.nodebb.org
    After=system.slice multi-user.target mongod.service
    
    [Service]
    Type=forking
    User=user
    
    StandardOutput=syslog
    StandardError=syslog
    SyslogIdentifier=nodebb
    
    WorkingDirectory=/home/user/nodebb
    PIDFile=/home/user/nodebb/pidfile
    ExecStart=/usr/bin/env node loader.js
    Restart=always
    
    [Install]
    WantedBy=multi-user.target
    

    Den User ersetzt ihr mit dem Namen Euren User's der NodeBB startet. Die NodeBB Installation liegt unter folgendem Pfad

    /home/user/nodebb/
    

    Den Dienst aktivieren

    sudo systemctl enable nodebb.service
    

    und starten

    sudo systemctl start nodebb.service
    

    Nun sollte der Dienst normalerweise beim Booten NodeBB starten, macht er aber bei mir um's verrecken nicht. Also Logfiles durchsuchen.

    Das sieht dort so aus

    May  3 21:15:07 one systemd[1]: Starting NodeBB...
    May  3 21:15:07 one nodebb[1366]: /usr/bin/env: ‘node’: No such file or directory
    May  3 21:15:07 one systemd[1]: nodebb.service: Control process exited, code=exited status=127
    May  3 21:15:07 one systemd[1]: Failed to start NodeBB.
    May  3 21:15:07 one systemd[1]: nodebb.service: Unit entered failed state.
    May  3 21:15:07 one systemd[1]: nodebb.service: Failed with result 'exit-code'.
    May  3 21:15:07 one systemd[1]: nodebb.service: Service hold-off time over, scheduling restart.
    May  3 21:15:07 one systemd[1]: Stopped NodeBB.
    

    Und nun kommen wir wieder auf den Anfang des Beitrages zu sprechen. Node ist die Anwendung node.js, die die Applikation NodeBB startet.

    Aus nodebb.service

    /usr/bin/env node loader.js
    

    node.js lädt die Datei loader.js, die im NodeBB Ordner liegt. So weit alles gut, aber bei unserer Installation, siehe den verlinkten Beitrag am Anfang, liegt die ausführbare Datei node in /opt/node/bin

    Ok, nun kann ich mir das Problem erklären, der User Root hat keinen Zugriff auf die Datei node. Und jetzt das Rätsel für mich, mein User für NodeBB hat Zugriff, mein User Root nicht. Stundenlang alles probiert. .profile editiert usw. Nichts brachte Erfolg. Ok, dann halt dirty 😞

    Ich habe dann die Datei nach /bin kopiert.

    cp /opt/node/bin/node /bin
    

    Danach hatte der User Root Zugriff auf die Datei und der nodebb.service funktioniert einwandfrei.

    Wer den Fehler kennt und eine Lösung für mich hat, immer her damit.

  • NodeBB - v3.6.0

    NodeBB
    1
    0 Stimmen
    1 Beiträge
    58 Aufrufe
    Niemand hat geantwortet
  • NAS 2023 - Software Teil 1

    Angeheftet Verschoben Linux
    1
    0 Stimmen
    1 Beiträge
    179 Aufrufe
    Niemand hat geantwortet
  • NodeBB - Update

    Angeheftet NodeBB
    1
    0 Stimmen
    1 Beiträge
    44 Aufrufe
    Niemand hat geantwortet
  • NodeBB - Upgrade v2.0.0

    NodeBB
    3
    0 Stimmen
    3 Beiträge
    134 Aufrufe
    FrankMF

    Irgendwie hatte ich Differenzen zwischen meinen beiden Foren, die es eigentlich nicht geben dürfte!?

    Problem scheint zu sein, das das Plugin

    nodebb-plugin-ns-embed

    nicht richtig funktioniert. Da bekam ich den Tipp, das Plugin

    nodebb-plugin-embed

    zu installieren. Das ging aber nicht über das Admin Panel, da kam folgendes.

    plugin_error.png

    Ok, dann von Hand

    npm install nodebb-plugin-embed

    Im Admin Panel aktivieren, danach Rebuild und Restarten. Aktuell in v2.0.0 nicht über das Admin Panle durchführbar, Fix ist schon fertig. Kommt wohl mit v2.0.1

    ./nodebb upgrade ./nodebb restart

    Danach lief alles!?? Hoffe ich 🙂

  • NodeBB - Update auf v1.18.5 - sharp problem

    NodeBB
    2
    0 Stimmen
    2 Beiträge
    134 Aufrufe
    FrankMF

    Heute Morgen beim Kaffee dann dieses Forum hier gemacht. Dazu habe ich aber die Vorgehensweise, nach einem Tipp aus dem NodeBB-Forum, ein wenig geändert.

    Ich habe jetzt festgestellt, das es sehr sinnvoll sein kann, nur mit einer Kopie zu arbeiten. Also, kopieren wir uns den ganzen Ordner.

    cp -r nodebb/ nodebb_test/

    In diesen Ordner dann wechseln.

    cd nodebb_test/

    Der Versuch von

    ./nodebb upgrade

    ist wieder gescheitert.

    In file included from ../src/common.cc:24: /usr/include/vips/vips8:35:10: fatal error: glib-object.h: Datei oder Verzeichnis nicht gefunden 35 | #include <glib-object.h> | ^~~~~~~~~~~~~~~ compilation terminated. make: *** [sharp-linux-x64.target.mk:139: Release/obj.target/sharp-linux-x64/src/common.o] Fehler 1 make: Verzeichnis „/home/user_nodebb/nodebb_test/node_modules/sharp/build“ wird verlassen gyp ERR! build error gyp ERR! stack Error: `make` failed with exit code: 2

    Nun der Tipp aus dem NodeBB-Forum. Ich soll den node_modules/ Ordner neu installieren lassen. Ok, dazu sichern wir uns den erstmal.

    mv node_modules/ node_modules_BAK/

    Danach ein

    npm install

    Da ich kein nodejs Nerd bin, vermute ich mal, das npm (der Paketmanager) jetzt alle Pakete aus der package.json neu runterlädt und installiert!? Die Aussage ist mit Vorsicht zu genießen, da ich mir nicht 100% sicher bin. Sollte aber passen 😉 Jedenfalls habe ich danach wieder einen node_modules/ Ordner.

    Dann hatte ich ja gestern gelernt, wie ich mir die Version der Pakete anzeigen lassen kann.

    user@webserver2:~/nodebb_test$ npm list sharp nodebb@1.18.5 /home/user/nodebb_test └── sharp@0.29.2

    Jetzt hat der Paketmanager npm in der richtigen Version installiert. 🤔 Schon ein wenig verrückt, oder?

    Danach ein

    ./nodebb upgrade

    Das lief durch

    NodeBB Upgrade Complete!

    Um das jetzt nicht nochmal machen zu müssen, habe ich die Original NodeBB Installation gesichert und den Testordner an dessen Stelle kopiert. Einmal neugestartet und ausprobiert. Bei dieser Version muss ich leider immer zweimal

    ./nodebb upgrade

    machen, bis es ordentlich läuft. Seltsam, aber kann ich mit leben. Diese Paket sharp macht jedesmal auf eine andere Art und Weise Probleme - ziemlich nervig. Eigentlich ist dieser Upgrade Vorgang nämlich stressfrei und problemlos. In seltenen Fällen meckert er mal über ein FIle was schon da ist. Das sieht man aber in der Ausgabe und löscht das dann einfach, Vorgang erneut starten und gut.

    Merksatz

    Original Ordner kopieren und darin den Upgrade Prozess erst testen!!

  • NodeBB - v1.17.0

    NodeBB
    1
    0 Stimmen
    1 Beiträge
    151 Aufrufe
    Niemand hat geantwortet
  • ClusterSSH

    Angeheftet Linux
    4
    0 Stimmen
    4 Beiträge
    723 Aufrufe
    FrankMF

    Mal wieder lange dran rumgefummelt, bis es passte.

    I have figured out how to use any font in xterm. So for the case of the mentioned Inconsolata font size 14, the following works:

    Add these 2 lines into ~/.Xresources (create it if it does not exist)

    XTermfaceName: Inconsolata
    XTermfaceSize: 14

    Then, tell xterm to use this file:

    export XENVIRONMENT="${HOME}/.Xresources"

    Preferably add this export into .bashrc, so that it is persistent.

    comment out the font settings in ~/.clusterssh/config, if it exists: # terminal_font=6x13

    Quelle: https://unix.stackexchange.com/questions/230106/cluster-ssh-specify-terminal-font

  • Restic & Rclone & Nextcloud

    Linux
    3
    0 Stimmen
    3 Beiträge
    688 Aufrufe
    FrankMF

    Hier mal eine Ausgabe vom ersten Durchgang

    root@frank-MS-7C37:~# restic --password-file /root/passwd -r rclone:Nextcloud:HOME_UBUNTU backup --files-from /root/includes.txt repository 99xxxxa0 opened successfully, password is correct created new cache in /root/.cache/restic rclone: 2020/05/08 17:47:57 ERROR : locks: error listing: directory not found rclone: 2020/05/08 17:47:58 ERROR : index: error listing: directory not found rclone: 2020/05/08 17:47:58 ERROR : snapshots: error listing: directory not found Files: 3503 new, 0 changed, 0 unmodified Dirs: 2 new, 0 changed, 0 unmodified Added to the repo: 16.872 GiB processed 3503 files, 21.134 GiB in 1:02:56 snapshot fdxxxxec saved

    Der erste Durchgang hat also etwa eine Stunde benötigt. Durch die Deduplikation der Daten, ist der Vorgang beim zweiten Durchgang viel schneller weil nur neue oder geänderte Daten gesichert werden. Und außerdem sind alle Daten AES-256 verschlüsselt. Also perfekt zur Ablage in irgendeiner Cloud 😉

    root@frank-MS-7C37:~# restic --password-file /root/passwd -r rclone:Nextcloud:HOME_UBUNTU backup --files-from /root/includes.txt repository 99xxxxa0 opened successfully, password is correct Files: 57 new, 41 changed, 3449 unmodified Dirs: 0 new, 2 changed, 0 unmodified Added to the repo: 22.941 MiB processed 3547 files, 21.137 GiB in 0:13 snapshot c6xxxxe4 saved

    Wie ihr seht, hat der zweite Durchgang nur ein paar neue und geänderte Daten gesichert. Der Rest ist ja schon vorhanden. Und das kann man dann auch problemlos täglich, wöchentlich oder was auch immer mal eben schnell durchführen.

    Eines meiner absoluten Lieblingstool 🙂