Skip to content

NodeBB - Auf Debian Buster 10 umziehen

NodeBB
  • Da ich ja meine Server am Umstellen bin , hier mal meine Schritte um eine vorhandene NodeBB Installation umzuziehen.

    Grundlage

    Redis Installation

    apt install redis-server
    

    In /etc/redis/redis.conf die Konfiguration einstellen. Wichtig Passwort einstellen!!

    Unter /var/libs/redis die Datenbank dump.rdb aus der Sicherung hin kopieren.

    Kopieren der DB

    service redis stop
    scp -r root@8.8.8.8:/home/frank/dump.rdb /home/frank
    mv /home/frank/dump.rdb /var/lib/redis
    chown redis:redis /var/lib/redis/dump.rdb
    service redis start
    

    Benutzerrechte auf redis anpassen! Wichtig!!!

    Pakete installieren

    apt install curl
    apt install sudo
    

    node.js installieren

    curl -sL https://deb.nodesource.com/setup_10.x | sudo -E bash -
    sudo apt-get install -y nodejs
    
    sudo apt-get install -y git
    

    User für NodeBB anlegen

    adduser user
    

    NodeBB muss mit einem eigenen User laufen. Auch wichtig, alle Befehle die ihr ausführt, müssen mit diesem User ausgeführt werden. Sonst gibt das ordentlich durcheinander 😉

    Solche Befehle meine ich

    ./nodebb start
    ./nodebb build
    

    NodeBB installieren

    cd /home/user
    git clone -b v1.12.x https://github.com/NodeBB/NodeBB.git nodebb
    
    ./nodebb setup
    

    Den Public Ordner nicht vergessen umzuziehen. Dort liegen alle Bilder usw.

    Nginx installieren

    apt install nginx
    

    Ich habe nach dieser Anleitung installiert.
    http://nginx.org/en/linux_packages.html#Debian

    Die Konfig liegt unter /etc/nginx/conf.d/
    Der Webordner wäre /usr/share/nginx/

    Certbot installieren

    Für https brauchen wir auch ein vernünftiges Zertifikat. Dafür installieren wir den Certbot von LetsEncrypt.

    apt install certbot
    

    Für SSL brauchen wir noch folgendes

    openssl dhparam -out /etc/ssl/nginx/dhparam-2048.pem 2048
    

    Nachdem man den DNS-Eintrag umgestellt hat, dauert es unterschiedlich lang, bis das erledigt ist. Man kann mit dem Certbot folgendes machen.

    certbot certonly --dry-run -d forum.frank-mankel.org
    

    So probiert er nur "trocken". Also ein Testlauf. Wenn das klappt dann richtig.

    certbot certonly -d forum.frank-mankel.org
    

    Evt. Fehler bekommt man angezeigt.

    Das sollte es gewesen sein, Daumen drücken und hoffen das es startet 🙂

    Die Zertifikate müssen auch regelmäßig erneuert werden, dazu legt man einen Cronjob an. Schöne Anleitung
    https://goneuland.de/certbot-lets-encrypt-zertifikate-automatisch-erneuern-unter-debian-9-stretch/

    Wenn alles läuft, unbedingt nachsehen ob alle Dienste mit dem entsprechenden User läuft.

    • Redis- Server User:redis
    • NodeBB User:"den ihr angelegt habt"
    • Nginx user:nginx

    Server Ports

    frank@debian:~$ nmap 148.251.198.219
    Starting Nmap 7.70 ( https://nmap.org ) at 2019-08-25 14:01 CEST
    Nmap scan report for webserver2.frank-mankel.org (148.251.198.219)
    Host is up (0.027s latency).
    Not shown: 996 filtered ports
    PORT     STATE  SERVICE
    80/tcp   open   http
    111/tcp  closed rpcbind
    443/tcp  open   https
    4567/tcp open   tram
    
    Nmap done: 1 IP address (1 host up) scanned in 7.85 seconds
    
  • 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

    curl -fsSL https://deb.nodesource.com/setup_14.x | bash -
    

    NodeBB

    git clone -b v1.18.x https://github.com/NodeBB/NodeBB.git nodebb
    

  • Debian 12 Bookworm released

    Linux
    5
    0 Stimmen
    5 Beiträge
    332 Aufrufe
    FrankMF
    Mein persönliches Fazit, alles läuft rund mit Debian Bookworm 12 Alle meine Hetzner VMs sind jetzt auf Bookworm Ok, was schwer und zeitaufwendig war, war die Nextcloud Installation bzw. der ganze PHP-Server. Das ist echt jedes mal eine Herausforderung, aber auch dabei werde ich die letzten Jahre sicherer. Hier die Story zum Nextcloud Server https://linux-nerds.org/topic/1437/nextcloud-upgrade-auf-bookworm-12 Richtig rund lief das Upgrade des NodeBB-Servers, war einfach und direkt auf Node18 hochgezogen. https://linux-nerds.org/topic/1444/nodebb-upgrade-auf-debian-bookworm-12 Damit ist jetzt alles hier auf Debian Bookworm 12 Haupt-PC VMs bei Hetzner VMs in der Proxmox Oh, da fällt mir gerade ein, der Proxmox ist noch fällig. Aber, dazu habe ich mir was einfallen lassen, da ist noch ein neues Mainboard unterwegs und dann gibt es dazu einen etwas größeren Beitrag. Danke Debian-Team, Debian Bookworm 12 ist eine runde Sache! Spannend wird jetzt, wie lange ich auf meinem Haupt-PC (Bookworm, KDE, Wayland) bleibe. Ich habe da so eine unangenehme Eigenschaft, wenn es um veraltete Pakete geht. Diesmal werde ich dann wahrscheinlich auf den Debian Unstable Zweig (sid) wechseln. Aber das dürfte noch was dauern, da ja aktuell erst mal alles passt.
  • Debian Installer Bookworm RC3 released

    Linux
    2
    0 Stimmen
    2 Beiträge
    124 Aufrufe
    FrankMF
    Und da sind wir schon bei RC4 https://lists.debian.org/debian-devel-announce/2023/05/msg00003.html
  • NodeBB - Git Prozess

    NodeBB
    2
    0 Stimmen
    2 Beiträge
    106 Aufrufe
    FrankMF
    Heute gab es ein Update von 2.4.5 -> 2.5.0 Das oben geschriebene funktioniert nicht git fetch git reset --hard origin/v2.x ./nodebb upgrade Ausschnitt der Konsole ~/nodebb$ git fetch remote: Enumerating objects: 244, done. remote: Counting objects: 100% (239/239), done. remote: Compressing objects: 100% (100/100), done. remote: Total 244 (delta 160), reused 212 (delta 138), pack-reused 5 Receiving objects: 100% (244/244), 55.57 KiB | 7.94 MiB/s, done. Resolving deltas: 100% (160/160), completed with 62 local objects. From https://github.com/NodeBB/NodeBB dd3e1a2861..01d276cbee v2.x -> origin/v2.x * [new branch] async-zxcvbn -> origin/async-zxcvbn 9260b4ef19..d06938d877 bootstrap5 -> origin/bootstrap5 884d40756a..8fe41d92a2 develop -> origin/develop a088eb19af..1076285dc9 master -> origin/master + b7d916c321...c85ac68373 renovate/ace-builds-1.x -> origin/renovate/ace-builds-1.x (forced update) * [new tag] v2.5.0 -> v2.5.0 :~/nodebb$ git reset --hard origin/v2.x HEAD is now at 01d276cbee chore: incrementing version number - v2.5.0 :~/nodebb$ ./nodebb upgrade Updating NodeBB...
  • Let's Encrypt - acme.sh

    Verschoben Let's Encrypt
    6
    0 Stimmen
    6 Beiträge
    357 Aufrufe
    FrankMF
    Der Monat ist um, es war Zertifikatsmonat. Und nichts lief mehr..... Was war passiert? Sonntags mache ich von meinem Haupt-PC ein Backup (per Hand) mittels Restic auf meinen Rest-Server. Doch ich bekam eine Fehlermeldung, blabla Zertifikat usw. Ok, ab auf den Server und mit der Fehlersuche gestartet. Das Zertifikat war erneuert worden, aber der Restart Command versuchte immer eine server.service zu starten, die es gar nicht gab!? Da musste ich doch beim @Nico mal kurz nachfragen. Und das kam dann dabei raus. Fehlerursache Der ReloadCmd versuchte einen server.service zu restarten, den es gar nicht gibt. Suche Im acme Pfad liegen die Ordner für die Domains. In diesem Ordner liegt eine Datei DOMAIN.conf In dieser Datei werden bei der Installation des Zertfikiates eine Reihe von Dingen eingetragen. Le_Domain='DOMAIN' Le_Alt='no' Le_Webroot='no' Le_PreHook='' Le_PostHook='' Le_RenewHook='' Le_API='https://acme-v02.api.letsencrypt.org/directory' Le_Keylength='2048' Le_OrderFinalize='https://acme-v02.api.letsencrypt.org/acme/finalize/<ID>' Le_LinkOrder='https://acme-v02.api.letsencrypt.org/acme/order/<ID>' Le_LinkCert='https://acme-v02.api.letsencrypt.org/acme/cert/>ID>' Le_CertCreateTime='1680440374' Le_CertCreateTimeStr='2023-04-02T12:59:34Z' Le_NextRenewTimeStr='2023-05-31T12:59:34Z' Le_NextRenewTime='1685537974' Le_RealCertPath='/mnt/rest-server/DOMAIN/cert.pem' Le_RealCACertPath='' Le_RealKeyPath='/mnt/rest-server/DOMAIN/key.pem' Le_ReloadCmd='__ACME_BASE64__START_c3lzdGVtY3RsIHJlc3RhcnQgc2VydmVyLnNlcnZpY2U=__ACME_BASE64__END_' Le_RealFullChainPath='/mnt/rest-server/DOMAIN/fullchain.pem' Ok, da ist der ReloadCmd, aber der ist base64 kodiert!? Was machen. # echo c3lzdGVtY3RsIHJlc3RhcnQgc2VydmVyLnNlcnZpY2U= | base64 -d systemctl restart server.service Ok, hier sehen wir die fehlerhafte Eintragung, die genau meinem Beispiel oben entspricht (unter Installation Zertifikat) Man könnte jetzt die Installation des Zertifikates mit dem korrigierten EIntrag durchführen, oder diese Base64 Zeile korrigieren. Ok, wie geht das? # echo systemctl restart rest-server.service | base64 c3lzdGVtY3RsIHJlc3RhcnQgcmVzdC1zZXJ2ZXIuc2VydmljZQo= Diese Ausgabe kopieren wir dann in die Konfigurationsdatei. Kurze Kontrolle # echo c3lzdGVtY3RsIHJlc3RhcnQgcmVzdC1zZXJ2ZXIuc2VydmljZQo= | base64 -d systemctl restart rest-server.service Passt Und wieder jede Menge gelernt. Danke @Nico
  • Debian 11.4 released

    Linux
    1
    0 Stimmen
    1 Beiträge
    87 Aufrufe
    Niemand hat geantwortet
  • Debian 11.3 released

    Linux
    1
    0 Stimmen
    1 Beiträge
    93 Aufrufe
    Niemand hat geantwortet
  • NodeBB - Update auf 1.13.3

    NodeBB
    1
    0 Stimmen
    1 Beiträge
    203 Aufrufe
    Niemand hat geantwortet
  • Redis oder MongoDB?

    Verschoben Redis
    1
    0 Stimmen
    1 Beiträge
    493 Aufrufe
    Niemand hat geantwortet