Skip to content

NodeBB - Upgrade auf v1.9.0

NodeBB
  • Datensicherung nicht vergessen!

    Praxistipp: Es hat sich jetzt bei meiner mittlerweilen sehr langen Nutzung von NodeBB herausgestellt, das es sinnvoll sein kann, den Installationsordner vorher zu kopieren, damit man problemlos zum alten Stand zurück kann! (Update: 01.11.2021)

    In das Installationsverzeichnis wechseln. Dran denken, mit dem richtigen User! (Ich habe da mal was durcheinander gewürfelt)

    ./nodebb stop
    Stopping NodeBB. Goodbye!
    

    Jetzt ist ein guter Zeitpunkt um alle seine Daten zu sichern. Ich gehe hier jetzt nicht drauf ein!

    Dann

    git fetch
    

    Danach dann folgendes

    git checkout v1.8.x 
    Already on 'v1.8.x'
    Your branch is up-to-date with 'origin/v1.8.x'.
    

    Ok, auf dieser Version sind wir. Das bringt so nichts. Also ...

    git checkout v1.9.x 
    Branch v1.9.x set up to track remote branch v1.9.x from origin.
    Switched to a new branch 'v1.9.x'
    

    Damit sind wir jetzt auf dem Zweig 1.9.x

    ./nodebb upgrade
    
    Updating NodeBB...
    
    1. Updating package.json file with defaults...  OK
    
    2. Bringing base dependencies up to date...  started
    added 20 packages and updated 4 packages in 6.407s
    
    3. Checking installed plugins for updates...  OK
    4. Updating NodeBB data store schema...
    Parsing upgrade scripts... 
    OK | 2 script(s) found, 51 skipped
      → [2018/2/28] Give registered users signature privilege... OK
      → [2018/4/16] Refresh post-upload associations... OK
    Schema update complete!
    
    
    5. Rebuilding assets...  started
    2018-05-03T14:55:01.217Z [1638] - info: [build] Building in parallel mode
    2018-05-03T14:55:01.219Z [1638] - info: [build]         plugin static dirs  build started
    .
    .
    . (gekürzt)
    
    
                            NodeBB Upgrade Complete!
    

    Danach ein

    ./nodebb start
    

    und ich bin auf v1.9.0

    Update

    Nach dem Update ist bei mir immer noch ein Rebuild & Restart im Backend nötig, sonst fehlen mir immer die Karten (Recent Cards). Danach läuft dann alles 🙂

    P.S.: Ich bin nicht so der git König, falls jemand mit Ahnung hier Fehler oder Unsinn sieht, bitte ich um einen kurzen Hinweis. Vielen Dank!

    0_1525360190866_NodeBB_v_1_9_0.png

  • Da oben fehlt ein Schritt.

    cd nodebb (or path to where nodebb is installed)
    ./nodebb stop
    git fetch
    git checkout v1.12.x
    git merge origin/v1.12.x
    ./nodebb upgrade
    

    Beim nächsten Upgrade testen.

  • FrankMF FrankM hat am auf dieses Thema verwiesen
  • FrankMF FrankM hat am auf dieses Thema verwiesen
  • FrankMF FrankM hat am auf dieses Thema verwiesen
  • FrankMF FrankM hat am auf dieses Thema verwiesen
  • FrankMF FrankM hat dieses Thema am abgepinnt

  • Proxmox - HomeAssistant

    Proxmox
    1
    0 Stimmen
    1 Beiträge
    271 Aufrufe
    Niemand hat geantwortet
  • Nextcloud - extrem lange Ladezeiten

    Nextcloud
    1
    0 Stimmen
    1 Beiträge
    134 Aufrufe
    Niemand hat geantwortet
  • HSTS - Sicherheitsmechanismus für HTTPS-Verbindungen

    Linux
    1
    0 Stimmen
    1 Beiträge
    68 Aufrufe
    Niemand hat geantwortet
  • VSCodium

    Linux
    1
    0 Stimmen
    1 Beiträge
    235 Aufrufe
    Niemand hat geantwortet
  • NodeBB - v1.15.0

    NodeBB
    1
    0 Stimmen
    1 Beiträge
    176 Aufrufe
    Niemand hat geantwortet
  • Kopia - Error 405

    Kopia
    1
    0 Stimmen
    1 Beiträge
    212 Aufrufe
    Niemand hat geantwortet
  • Nextcloud Talk

    Nextcloud
    5
    0 Stimmen
    5 Beiträge
    811 Aufrufe
    FrankMF

    All I needed to do was setting the permissions to 744 for the archive directory and the symlinks resolved correctly after a reboot of coturn

    My turnserver installation on Debian runs as the user turnserver and not as root, nor is the user turnserver in any group owning the letsencrypt directory.
    If your turnserver does run as root, it should be fine just adding execute permissions.

    I hope this helps some of you.
    Quelle: https://help.nextcloud.com/t/lets-encrypt-symlink-breaks-coturn-configuration/70166

    Was zum Testen die Tage....

  • Restic - forget --keep-last 3 --prune

    Restic
    2
    0 Stimmen
    2 Beiträge
    600 Aufrufe
    FrankMF

    Ich habe mich damit noch ein wenig beschäftigt, die letzten drei zu behalten, ist nicht so optimal. Da es viele Optionen bei dem Befehl gibt, hier ein Ausschnitt

    Flags: -l, --keep-last n keep the last n snapshots -H, --keep-hourly n keep the last n hourly snapshots -d, --keep-daily n keep the last n daily snapshots -w, --keep-weekly n keep the last n weekly snapshots -m, --keep-monthly n keep the last n monthly snapshots -y, --keep-yearly n keep the last n yearly snapshots

    habe ich das ein wenig so angepasst, das ich denke es passt für mich.

    restic --password-file /root/passwd -r /media/NAS_neu/Restic/Home/ forget --keep-last 3 --keep-monthly 3 --prune

    Damit behalte ich auch die jeweils eines pro Monat. Und die letzten drei. Das sieht dann so aus.

    root@debian:~# ./backup2.sh repository 2f3f6147 opened successfully, password is correct Files: 38 new, 100 changed, 13268 unmodified Dirs: 0 new, 1 changed, 0 unmodified Added to the repo: 10.166 GiB processed 13406 files, 50.324 GiB in 3:24 snapshot 849f614c saved repository 2f3f6147 opened successfully, password is correct Applying Policy: keep the last 3 snapshots, 3 monthly snapshots snapshots for (host [debian], paths [/home/frank]): keep 5 snapshots: ID Time Host Tags Reasons Paths ------------------------------------------------------------------------------------ a7251cfd 2019-11-28 17:00:01 debian monthly snapshot /home/frank 283d4027 2019-12-31 17:00:01 debian monthly snapshot /home/frank ae2b96ec 2020-01-01 21:47:46 debian last snapshot /home/frank 079e00a6 2020-01-02 17:00:01 debian last snapshot /home/frank 849f614c 2020-01-03 21:08:45 debian last snapshot /home/frank monthly snapshot ------------------------------------------------------------------------------------ 5 snapshots remove 26 snapshots: ID Time Host Tags Paths ------------------------------------------------------------------ 896f16c2 2019-11-07 22:23:40 debian /home/frank b21bcf6d 2019-11-11 17:00:01 debian /home/frank f89248fb 2019-11-12 17:00:01 debian /home/frank 123ab546 2019-11-13 17:00:01 debian /home/frank b82d87d0 2019-11-18 17:00:01 debian /home/frank 040b0ab7 2019-11-19 17:00:01 debian /home/frank 7221d8ef 2019-11-20 17:00:01 debian /home/frank 84132a25 2019-11-21 17:00:01 debian /home/frank b558a52c 2019-11-25 17:00:01 debian /home/frank e5cc0c3e 2019-12-02 17:00:01 debian /home/frank 22423fa5 2019-12-03 17:00:01 debian /home/frank 39df1ab9 2019-12-04 17:00:01 debian /home/frank 98843457 2019-12-05 17:00:01 debian /home/frank b0cdd4b6 2019-12-09 17:00:01 debian /home/frank 828414f9 2019-12-10 17:00:01 debian /home/frank e34a27c3 2019-12-11 17:00:01 debian /home/frank 6e488c3b 2019-12-12 17:00:01 debian /home/frank 17898403 2019-12-16 17:00:01 debian /home/frank 1973305a 2019-12-17 17:00:01 debian /home/frank 9553bedd 2019-12-18 17:00:01 debian /home/frank fedf749d 2019-12-19 17:00:01 debian /home/frank 8e7cb876 2019-12-23 17:00:01 debian /home/frank 0bd0d102 2019-12-25 17:00:01 debian /home/frank 13d348b0 2019-12-26 17:00:01 debian /home/frank c7d960aa 2019-12-30 17:00:01 debian /home/frank f6ea9118 2020-01-01 17:00:01 debian /home/frank ------------------------------------------------------------------ 26 snapshots 26 snapshots have been removed, running prune counting files in repo building new index for repo [0:35] 100.00% 7806 / 7806 packs repository contains 7806 packs (46537 blobs) with 41.110 GiB processed 46537 blobs: 0 duplicate blobs, 0 B duplicate load all snapshots find data that is still in use for 5 snapshots [0:01] 100.00% 5 / 5 snapshots found 32654 of 46537 data blobs still in use, removing 13883 blobs will remove 0 invalid files will delete 715 packs and rewrite 752 packs, this frees 5.027 GiB [2:28] 100.00% 752 / 752 packs rewritten counting files in repo [0:01] 100.00% 6571 / 6571 packs finding old index files saved new indexes as [d137b425 f7caee99 a6e9711a] remove 35 old index files [1:13] 100.00% 1467 / 1467 packs deleted done using temporary cache in /tmp/restic-check-cache-916655151 repository 2f3f6147 opened successfully, password is correct created new cache in /tmp/restic-check-cache-916655151 create exclusive lock for repository load indexes check all packs check snapshots, trees and blobs read all data [7:47] 100.00% 6571 / 6571 items duration: 7:47 no errors were found root@debian:~#

    Am Ende seht ihr noch, wie Restic alle Files testet. Mein Script sieht jetzt so aus.

    #!/bin/bash # Script um mit Restic Daten automatisiert zu sichern! # Dient zum Sichern der Homepartition auf dem ROCKPro64 NAS! # Was soll gesichert werden? backup_pfad=/home/frank # Programm Start restic --password-file /root/passwd -r /media/NAS_neu/Restic/Home/ backup $backup_pfad --exclude-file=excludes.txt restic --password-file /root/passwd -r /media/NAS_neu/Restic/Home/ forget --keep-last 3 --keep-monthly 3 --prune # Testen restic --password-file /root/passwd -r /media/NAS_neu/Restic/Home/ check --read-data

    Das dann schön mit einem Cronjob laufen lassen und die Datensicherung ist erledigt 😉