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 - Update 2.8.1

    NodeBB
    1
    0 Stimmen
    1 Beiträge
    48 Aufrufe
    Niemand hat geantwortet
  • NodeBB - Upgrade v1.19.4

    NodeBB
    1
    0 Stimmen
    1 Beiträge
    75 Aufrufe
    Niemand hat geantwortet
  • WLan auf der Konsole einrichten

    Angeheftet Linux
    3
    0 Stimmen
    3 Beiträge
    523 Aufrufe
    FrankMF

    Ich kann im Manjaro keine WPA3 Sicherheit auswählen, dann bekomme ich keine Verbindung. Es geht nur WPA2 Personal. Gegenstelle ist eine FRITZ!Box 6591 Cable.

    2021-11-28_16-37.png

    In der Fritzbox sieht das so aus

    50d23aa8-5f67-485e-a994-244ef4f6a270-image.png

    Das kam als Fehlermeldung

    Nov 28 11:03:07 frank-pc wpa_supplicant[700]: wlan0: Trying to associate with SSID 'FRITZ!Box 6591 Cable AK' Nov 28 11:03:07 frank-pc wpa_supplicant[700]: wlan0: WPA: Failed to select authenticated key management type Nov 28 11:03:07 frank-pc wpa_supplicant[700]: wlan0: WPA: Failed to set WPA key management and encryption suites

    Ich denke, der Treiber unterstützt das nicht.

  • Fedora 34

    Linux
    5
    0 Stimmen
    5 Beiträge
    262 Aufrufe
    FrankMF

  • 0 Stimmen
    1 Beiträge
    169 Aufrufe
    Niemand hat geantwortet
  • LUKS verschlüsselte Platte mounten

    Linux
    2
    0 Stimmen
    2 Beiträge
    647 Aufrufe
    FrankMF

    So, jetzt das ganze noch einen Ticken komplizierter 🙂

    Ich habe ja heute, für eine Neuinstallation von Ubuntu 20.04 Focal eine zweite NVMe SSD eingebaut. Meinen Bericht zu dem Thema findet ihr hier. Aber, darum soll es jetzt hier nicht gehen.

    Wir haben jetzt zwei verschlüsselte Ubuntu NVMe SSD Riegel im System. Jetzt klappt die ganze Sache da oben nicht mehr. Es kommt immer einen Fehlermeldung.

    unbekannter Dateisystemtyp „LVM2_member“.

    Ok, kurz googlen und dann findet man heraus, das es nicht klappen kann, weil beide LVM Gruppen, den selben Namen benutzen.

    root@frank-MS-7C37:/mnt/crypthome/root# vgdisplay --- Volume group --- VG Name vgubuntu2 System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 4 VG Access read/write VG Status resizable MAX LV 0 Cur LV 2 Open LV 1 Max PV 0 Cur PV 1 Act PV 1 VG Size <464,53 GiB PE Size 4,00 MiB Total PE 118919 Alloc PE / Size 118919 / <464,53 GiB Free PE / Size 0 / 0 VG UUID lpZxyv-cNOS-ld2L-XgvG-QILa-caHS-AaIC3A --- Volume group --- VG Name vgubuntu System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 3 VG Access read/write VG Status resizable MAX LV 0 Cur LV 2 Open LV 2 Max PV 0 Cur PV 1 Act PV 1 VG Size <475,71 GiB PE Size 4,00 MiB Total PE 121781 Alloc PE / Size 121781 / <475,71 GiB Free PE / Size 0 / 0 VG UUID jRYTXL-zjpY-lYr6-KODT-u0LJ-9fYf-YVDna7

    Hier oben sieht man das schon mit geändertem Namen. Der VG Name muss unterschiedlich sein. Auch dafür gibt es ein Tool.

    root@frank-MS-7C37:/mnt/crypthome/root# vgrename --help vgrename - Rename a volume group Rename a VG. vgrename VG VG_new [ COMMON_OPTIONS ] Rename a VG by specifying the VG UUID. vgrename String VG_new [ COMMON_OPTIONS ] Common options for command: [ -A|--autobackup y|n ] [ -f|--force ] [ --reportformat basic|json ] Common options for lvm: [ -d|--debug ] [ -h|--help ] [ -q|--quiet ] [ -v|--verbose ] [ -y|--yes ] [ -t|--test ] [ --commandprofile String ] [ --config String ] [ --driverloaded y|n ] [ --nolocking ] [ --lockopt String ] [ --longhelp ] [ --profile String ] [ --version ] Use --longhelp to show all options and advanced commands.

    Das muss dann so aussehen!

    vgrename lpZxyv-cNOS-ld2L-XgvG-QILa-caHS-AaIC3A vgubuntu2 ACHTUNG Es kann zu Datenverlust kommen, also wie immer, Hirn einschalten!

    Ich weiß, das die erste eingebaute Platte mit der Nummer /dev/nvme0n1 geführt wird. Die zweite, heute verbaute, hört dann auf den Namen /dev/nvme1n1. Die darf ich nicht anpacken, weil sonst das System nicht mehr startet.

    /etc/fstab

    # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # <file system> <mount point> <type> <options> <dump> <pass> /dev/mapper/vgubuntu-root / ext4 errors=remount-ro 0 1 # /boot was on /dev/nvme1n1p2 during installation UUID=178c7e51-a1d7-4ead-bbdf-a956eb7b754f /boot ext4 defaults 0 2 # /boot/efi was on /dev/nvme0n1p1 during installation UUID=7416-4553 /boot/efi vfat umask=0077 0 1 /dev/mapper/vgubuntu-swap_1 none swap sw 0 0

    Jo, wenn jetzt die Partition /dev/mapper/vgubuntu2-root / anstatt /dev/mapper/vgubuntu-root / heißt läuft nichts mehr. Nur um das zu verdeutlichen, auch das könnte man problemlos reparieren. Aber, ich möchte nur warnen!!

    Nachdem die Änderung durchgeführt wurde, habe ich den Rechner neugestartet. Puuh, Glück gehabt, richtige NVMe SSD erwischt 🙂

    Festplatte /dev/mapper/vgubuntu2-root: 463,58 GiB, 497754832896 Bytes, 972177408 Sektoren Einheiten: Sektoren von 1 * 512 = 512 Bytes Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes

    Nun können wir die Platte ganz normal, wie oben beschrieben, mounten. Nun kann ich noch ein paar Dinge kopieren 😉

  • 0 Stimmen
    1 Beiträge
    293 Aufrufe
    Niemand hat geantwortet
  • 0 Stimmen
    2 Beiträge
    281 Aufrufe
    FrankMF

    Durch meinen Umzug zu einem neuen Proxmox, habe ich die Gelegenheit genutzt und meine Server alle auf Debian 11 Bullseye neu installiert. So konnte ich das alles noch mal testen und meine Doku anpassen.

    Zu dem obigen Beitrag gibt es nur folgendes zu ergänzen. Ja, wir wollen ja auch was Aktuelles haben 😉

    NodeJS

    Link Preview Image Node.js — Run JavaScript Everywhere

    Node.js® is a JavaScript runtime built on Chrome's V8 JavaScript engine.

    favicon

    (nodejs.org)

    curl -fsSL https://deb.nodesource.com/setup_14.x | bash - NodeBB git clone -b v1.18.x https://github.com/NodeBB/NodeBB.git nodebb

    https://github.com/NodeBB/NodeBB/branches