Skip to content

NodeBB - nach Plugin platt

NodeBB
1 1 633
  • Ist mir heute nach der Installation eines Plugins passiert.

    Lösung: Ab auf den Server, und in die Konsole folgendes eingeben.

    ./nodebb upgrade
    

    Danach baut er alles neu, sollte helfen.

  • I'm in the mood to watch content again!

    Uncategorized linux debian
    1
    0 Stimmen
    1 Beiträge
    0 Aufrufe
    Niemand hat geantwortet
  • 0 Stimmen
    17 Beiträge
    425 Aufrufe
    julian@community.nodebb.orgJ
    @esoteric_programmer@social.stealthy.club that's likely because GtS handles summary as a content warning for everything. The whole summary and content warning business is in flux right now, so hopefully a standard will be set soon.
  • Fragen, Probleme, geht nicht?

    Angeheftet Support vaultwarden support linux
    1
    0 Stimmen
    1 Beiträge
    159 Aufrufe
    Niemand hat geantwortet
  • Links zu Vaultwarden

    Angeheftet Vaultwarden vaultwarden bitwarden linux
    1
    0 Stimmen
    1 Beiträge
    165 Aufrufe
    Niemand hat geantwortet
  • Crowdsec - Ein fail2ban Ersatz?

    Linux crowdsec linux fail2ban
    2
    1
    0 Stimmen
    2 Beiträge
    1k Aufrufe
    FrankMF
    Ich kann jetzt hier von meiner ersten Erfahrung berichten und wie CrowdSec mich gebannt hat Was war passiert? Ich war gestern sehr intensiv mit der Konfiguration von Nextcloud <-> Collabora Online beschäftigt. Nachdem ich irgendwie nicht weiterkam habe ich mich der Erstellung eines Dokumentes gewidmet. Nach einiger Zeit war die Nextcloud nicht mehr erreichbar. Ok, hatte ich bei der Konfiguration auch schon mal, den Server einmal neugestartet und fertig. Doch jetzt kam es, Server neugestartet - hilft nicht. Gut, schauen wir mal nach, Der SSH Login ging auch nicht Jetzt war guter Rat gefragt. Zu diesem Zeitpunkt ging ich noch davon aus, das auf diesem Server kein CrowdSec installiert war, sondern fail2ban. Und fail2ban hatte eine sehr kurze Bantime vom 10M. Also blieb wohl nur noch das Rescue System von Hetzner. [image: 1694411392066-488866bc-3dcf-4abc-9e98-6107d65aa4c7-grafik.png] Da hatte ich ja so gut wie gar keine Erfahrung mit. Also mal kurz den Nico angetriggert und es kam folgender Link. https://docs.hetzner.com/de/robot/dedicated-server/troubleshooting/hetzner-rescue-system/ Das Laufwerk war schnell bestimmt und schnell nach /tmp gemountet. Danach musste man sich noch mit chroot in diese Umgebung anmelden. chroot-prepare /mnt chroot /mnt Nachdem das klappte, habe ich eben fail2ban disabled. sysmctl disable fail2ban Danach das Rescue beendet. Der Server startete wieder und ich kam wieder per SSH drauf. Puuh. Bei meiner ersten Kontrolle fiel mir was auf root@:~# pstree systemd─┬─2*[agetty] ├─atd ├─cron ├─crowdsec─┬─journalctl │ └─8*[{crowdsec}] ├─crowdsec-firewa───9*[{crowdsec-firewa}] Wie? Da läuft CrowdSec? Da ich dabei bin die Server auf CrowdSec umzustellen, war das wohl hier schon gemacht, aber leider nicht vernünftig. fail2ban hätte mindestens disabled werden müssen und in meiner Dokumentation war das auch nicht enthalten. 6 setzen! CrowdSec besteht ja aus zwei Diensten, CrowdSec und dem Firewall-Bouncer. Der CrowdSec Dienst lief aber nicht, der war irgendwie failed. Ok, starten wir ihn und schauen was passiert. Nachdem er gestarte war mal die Banliste angeschaut. cscli decisions list ergab diesen Eintrag. 2551501 │ crowdsec │ Ip:5.146.xxx.xxx │ crowdsecurity/http-crawl-non_statics │ ban │ │ │ 53 │ 1h5m55.391864693s │ 1671 Meine IP war gebannt. Dann wissen wir ja , woher die Probleme kamen. cscli decisions delete --id 2551501 Nach Eingabe war der Ban entfernt. Na gut, aber da ich aktuell immer noch an der richtigen Konfiguration von NC <-> CODE bastel, könnte das ja wieder passieren. Was machen? Kurz gegoogelt. Es gibt eine Whitelist. Aha! /etc/crowdsec/parsers/s02-enrich/whitelists.yaml name: crowdsecurity/whitelists description: "Whitelist events from private ipv4 addresses" whitelist: reason: "private ipv4/ipv6 ip/ranges" ip: - "127.0.0.1" - "::1" - "5.146.XXX.XXX" cidr: - "192.168.0.0/16" - "10.0.0.0/8" - "172.16.0.0/12" # expression: # - "'foo.com' in evt.Meta.source_ip.reverse" Danach den Dienst neustarten. Jetzt hoffen wir mal, das es hilft. Zum Schluss noch was, was mir aufgefallen war und was mich auch sehr verwirrt hatte. CrowdSec hatte wegen einem crowdsecurity/http-crawl-non_statics gebannt. Dadurch konnte ich meine subdomain.<DOMAIN> nicht erreichen. Ok, logisch, wenn der Ban von da ausgeht. Ich konnte aber gleichzeitig eine andere subdomain mit derselben <DOMAIN> auch nicht erreichen. Komplett verwirrte es mich dann, als ich eine andere <DOMAIN> auf dem selben Server erreichen konnte. Und zum Schluss ging auch der SSH nicht. Also, wieder viel gelernt..
  • NodeBB - Git Prozess

    NodeBB nodebb
    2
    0 Stimmen
    2 Beiträge
    151 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...
  • Kernel 5.19-rc1

    Quartz64 linux quartz64
    2
    0 Stimmen
    2 Beiträge
    219 Aufrufe
    FrankMF
    Man kann dann den aktuell Kernel [root@frank-pc ~]# uname -a Linux frank-pc 5.17.0-3-MANJARO-ARM-Q64 #1 SMP PREEMPT Sat Jun 4 14:34:03 UTC 2022 aarch64 GNU/Linux mit diesem Befehl aktualisieren sudo pacman -S linux-rc linux-rc-headers Man wechselt dann vom Zweig linux-quartz64 auf linux-rc. Der Zweig linux-rc entspricht dem Mainline Kernel. Achtung! Zum Zeitpunkt der Erstellung des Beitrages crasht das Eure Installation!! Ursache ist, das es aktuell diesen Kernel linux-rc-5.18.rc7-7-aarch64 installiert, dieser enthält aber keine Unterstützung für das Modell B. Und zum Nachschauen, ob schon was Neues da ist [root@frank-pc ~]# pacman -Ss linux-rc linux-rc-headers core/linux-rc-headers 5.18.rc7-7 Header files and scripts for building modules for linux kernel - AArch64 multi-platform (release candidate)
  • Manjaro KDE Plasma 21.2.6

    Linux manjaro kde linux
    16
    2
    0 Stimmen
    16 Beiträge
    921 Aufrufe
    FrankMF
    @FrankM sagte in Manjaro KDE Plasma 21.2.6: Eines betrifft die Anordnung der Icons auf dem Desktop. Die Anordnung, die ich wähle, werden immer wieder geändert. Unschön, aber den Desktop nutze ich so gut wie gar nicht. Also kann ich auch auf den Fix warten. Kann noch was dauern https://pointieststick.com/2023/03/03/this-week-in-kde-plasma-6-begins/ Desktop icons on the active activity should no longer inappropriately re-arrange themselves when the set of connected screens changes. However during the process of investigation, we discovered that the code for storing desktop file position is inherently problematic and in need of a fundamental rewrite just like we did for multi-screen arrangement in Plasma 5.27. This will be done for Plasma 6.0, and hopefully make Plasma’s long history of being bad about remembering desktop icon positions just that–history (Marco Martin, Plasma 5.27.3. Link)