Nur-Lese-Modi in Discourse

Dokumentation Website-Verwaltung
, ,
1

:bookmark: Dieser Leitfaden erklärt die verschiedenen schreibgeschützten Modi, die in Discourse verfügbar sind, wie man sie aktiviert und deaktiviert und in welchen Szenarien man jeden Modus verwenden möchte.

:person_raising_hand: Erforderliches Benutzerniveau: Administrator

Die Verwaltung einer lebendigen Online-Community auf Discourse erfordert gelegentlich, dass Administratoren Benutzeraktivitäten vorübergehend einschränken. Diese Situationen können von der Durchführung von Serverwartungen, der Erleichterung von Backups bis hin zur Migration von Servern reichen. Während solcher Zeiten ist es entscheidend, Forumaktivitäten einzuschränken, ohne den Benutzerzugriff vollständig zu unterbinden.

Discourse bietet verschiedene Schreibgeschützte Modi, die Administratoren aktivieren können, um verschiedene Arten von Interaktionen auf einer Website vorübergehend einzufrieren.

Dieser Leitfaden untersucht diese Modi und konzentriert sich insbesondere darauf, wie man sie aktiviert und deaktiviert, einschließlich des Umgangs mit Situationen, in denen sich bestimmte Modi überschneiden.

Schreibgeschützte Modi verstehen

Discourse unterstützt zwei verschiedene Ebenen von schreibgeschützten Modi, die auf verschiedene administrative Bedürfnisse zugeschnitten sind. Diese sind:

  1. Vollständig schreibgeschützter Modus

    • Beschränkt alle Schreibvorgänge im Forum und verhindert, dass Benutzer Inhalte erstellen oder ändern, wie z. B. Posten, Kommentieren oder Liken.
    • Ermöglicht es dem Forum, im Wesentlichen in seinem aktuellen Zustand “eingefroren” zu werden, sodass Benutzer vorhandene Inhalte lesen und navigieren können, ohne die Datenbank zu beeinträchtigen.
    • Deaktiviert die Änderung von Website-Einstellungen oder Website-Anpassungen, sodass der aktuelle Zustand der Datenbank erhalten bleibt.
    • Deaktiviert neue Forum-Logins.

  2. Nur für Mitarbeiter schreibgeschützter Modus

    • Beschränkt Standardbenutzer von Schreibvorgängen im Forum, wie z. B. Posten, Kommentieren oder Liken. Standardbenutzer sind auf schreibgeschützte Vorgänge beschränkt und können sich nach der Aktivierung dieses Modus nicht mehr in ihr Konto einloggen.
    • Ermöglicht Admin- und Moderatorenaktivitäten, normal fortzufahren. Administratoren können Website-Einstellungen ändern, und Mitarbeiterbenutzer können Schreibvorgänge wie Posten, Liken oder Ändern von Profilen durchführen.

Diese Modi gewährleisten Flexibilität bei der Verwaltung des Betriebs des Forums während kritischer administrativer Zeiträume.

Schreibgeschützte Modi aktivieren/deaktivieren

:warning: Administratoren sollten den Übergang zwischen verschiedenen schreibgeschützten Modi sorgfältig verwalten. Bevor Sie einen schreibgeschützten Modus aktivieren, stellen Sie sicher, dass ein zuvor aktivierter Modus deaktiviert ist.

Vollständig schreibgeschützter Modus

Über die Rails-Konsole

Wenn Sie Zugriff auf Ihre Discourse-Installation haben, verwenden Sie die Discourse-Befehlszeilenschnittstelle von Rails, um den folgenden Befehl auszuführen, nachdem Sie Ihren Docker-Container mit ./launcher enter app und dann die Rails-Konsole mit rails c betreten haben:

Discourse.enable_readonly_mode(Discourse::USER_READONLY_MODE_KEY)

Über das Admin-Panel

Wenn Sie über die Weboberfläche administrativen Zugriff haben, können Sie zu Admin > Backups > Read-Only Mode aktivieren navigieren, um den schreibgeschützten Modus zu aktivieren.

image
image1971×298 22.3 KB

Um den schreibgeschützten Modus zu deaktivieren, führen Sie den folgenden Rails-Befehl aus:

Discourse.disable_readonly_mode(Discourse::USER_READONLY_MODE_KEY)

Oder verwenden Sie das Admin-Panel, indem Sie zu Admin > Backups > Read-Only Mode deaktivieren navigieren.

image
image1956×381 30.5 KB

Nur für Mitarbeiter schreibgeschützter Modus

:discourse: Der Modus “Nur für Mitarbeiter schreibgeschützt” kann nur über die Discourse Rails-Konsole aktiviert/deaktiviert werden. Wenn Ihre Website von Discourse gehostet wird, wenden Sie sich bitte an team@discourse.org, wenn Sie einen dieser Modi aktivieren oder deaktivieren möchten.

Um den Modus “Nur für Mitarbeiter schreibgeschützt” zu aktivieren, verwenden Sie den folgenden Befehl in der Rails-Konsole:

Discourse.enable_readonly_mode(Discourse::STAFF_WRITES_ONLY_MODE_KEY)

Zum Deaktivieren:

Discourse.disable_readonly_mode(Discourse::STAFF_WRITES_ONLY_MODE_KEY)

Best Practices

  • Rechtzeitige Kommunikation: Informieren Sie Ihre Community im Voraus über geplante schreibgeschützte Zeiträume, um die Erwartungen richtig zu setzen.
  • Testen: Führen Sie vor der Implementierung dieser Modi während kritischer Operationen Tests in Zeiten geringer Auslastung durch, um deren Auswirkungen zu verstehen.
  • Dokumentation: Führen Sie detaillierte Aufzeichnungen darüber, wann und warum jeder Modus aktiviert oder deaktiviert wurde, um die zukünftige operative Planung zu unterstützen.

FAQs

  • Wie lange dauert es, den schreibgeschützten Modus zu aktivieren/deaktivieren?

    • Die Änderung ist sofort wirksam. Die Benutzererfahrung kann jedoch geringfügig variieren, abhängig von ihren Aktionen während der Übergangszeit.

  • Hilfe! Ich bin wegen des schreibgeschützten Modus von meiner Website ausgesperrt – was kann ich tun, um wieder Zugriff auf meine Website zu erhalten?

  • Ich habe bemerkt, dass in discourse/lib/discourse.rb andere READ-ONLY-Modi aufgeführt sind. Was bewirken diese Modi?

    • READONLY_MODE_KEY wird hauptsächlich für den Backup- und Wiederherstellungsprozess verwendet und wird von der Anwendung selbst ausgelöst. Dieser Modus kann auch über die Discourse-Befehlszeilenschnittstelle mit discourse enable_readonly und discourse disable_readonly aktiviert oder deaktiviert werden. Dieser Schlüssel überlebt jedoch keinen Container-Neustart.
    • USER_READONLY_MODE_KEY wird verwendet, wenn ein Administrator auf die Schaltfläche “Nur schreibgeschützt” in der Admin-Oberfläche klickt. Das Besondere an diesem Schlüssel ist, dass wir ihn nicht als ablaufenden Schlüssel setzen, da ein vom Benutzer aktivierter schreibgeschützter Modus Container-Neustarts überleben muss. Andere Schlüssel werden mit einer TTL von 60 Sekunden gesetzt, und wir haben einen Thread, der das Ablaufdatum alle 30 Sekunden verlängert, um sicherzustellen, dass eine App niemals im schreibgeschützten Modus stecken bleibt.
    • PG_READONLY_MODE_KEY und PG_FORCE_READONLY_MODE_KEY werden für PG-Failover verwendet. Ersteres wird als ablaufender Schlüssel gesetzt, während letzteres nicht abläuft.
9 „Gefällt mir“
2

Ich kann keinen Unterschied erkennen! Könnten diese Beschreibungen entsprechend angepasst werden, falls es tatsächlich einen Unterschied gibt?

1 „Gefällt mir“
3

Ich habe den Leitfaden aktualisiert, um hier zusätzliche Klarheit zu schaffen. Bitte lassen Sie uns wissen, wenn Sie noch Fragen zu den schreibgeschützten Modi haben. :slightly_smiling_face:

1 „Gefällt mir“
4

Aber was macht discourse enable_readonly?

Es verwendet READONLY_MODE_KEY, das ttl auf 60 setzt, sodass es irgendwann wieder ausgeschaltet wird. Jetzt sehe ich, dass

Gibt es einen Grund, warum dies das Standardverhalten für diesen Befehl ist? Es hat mich fast ein Jahrzehnt gekostet, um zu lernen, dass dieser Befehl völlig anders ist als der Readonly-Modus der Weboberfläche, selbst nachdem ich ein paar Mal auf die Nase gefallen bin. Und ich erinnere mich jetzt, dass mir jemand einmal versucht hat, etwas über diese Schlüssel zu erzählen, und ich habe ihre Bedeutung nicht verstanden.

Meiner Meinung nach wäre es viel sinnvoller, wenn discourse enable_readonly Discourse.enable_readonly_mode(Discourse::STAFF_WRITES_ONLY_MODE_KEY) ausführen würde. Das hätte ich mir schon vor vielen Jahren gewünscht!

Könnte ich einen PR einreichen, der so etwas tut?

  desc "enable_readonly", "Enable the readonly mode, allowing staff writes"
  def staff_writes_only
    load_rails

    Discourse.enable_readonly_mode(Discourse::STAFF_WRITES_ONLY_MODE_KEY)
    puts 'The site is now in readonly mode with staff writes permitted.'
  end
6

Ich bin damit nicht sehr vertraut, aber ich denke, es wäre verwirrend, wenn enable_readonly_mode die Seite in einen staff_writes_only_mode versetzen würde. Das sind unterschiedliche Modi. Bei bestimmten Operationen möchten Sie nicht, dass das Personal Schreibrechte in der Datenbank hat (z. B. bei einer Wiederherstellung, dann werden sie entfernt).

Vielleicht können wir stattdessen ein paar andere Dinge tun:

  1. Klären Sie, dass der Readonly-Modus eine TTL in der Beschreibung dieser Aufgabe festlegt.
  2. Fügen Sie eine Aufgabe hinzu, die keep_readonly_mode aufruft, damit sie auf mehr als 60 Minuten erweitert werden kann.
  3. Fügen Sie enable_staff_writes_only und disable_staff_writes_only Aufgaben hinzu.
2 „Gefällt mir“
7

Ich würde zustimmen, aber es wäre viel weniger verwirrend als „Lesezugriffsmodus für eine Weile festlegen“.

Ich bin ziemlich sicher, dass das Wiederherstellungsskript den Lesezugriffsmodus selbst festlegt, sodass es von diesem Befehl nicht betroffen ist.

Ich würde es eher so formulieren, dass es verkündet, dass es für X Minuten festgelegt ist, wenn es festgelegt wird. Es ist nicht so einfach, die Beschreibung zu finden.

Vielleicht. Ich bin mir nicht sicher, wer es benutzen würde.

Das wäre großartig!

Außerdem müssen wir klarstellen, dass wir die Rake-Aufgaben nicht mit den über den discourse-Befehl verfügbaren Befehlen verwechseln.

2 „Gefällt mir“
8

Das ergibt Sinn. Gibt es eine Chance, dass Sie dies als PR einreichen können? Dasselbe gilt für die Befehle enable_staff_writes_only und disable_staff_writes_only, wenn möglich. Danke!

3 „Gefällt mir“
9

Ich frage mich, welche Uhren nach dem Start im Nur-Lese-Modus anhalten? Wird es Topic-Bumps geben, nachdem der Nur-Lese-Modus aktiviert wurde?

10

Es sieht auch so aus, als ob Updates nicht funktionieren, wenn der Nur-Lese-Modus über die Web-UI eingestellt ist.