Nur-Lese-Modi in Discourse

:bookmark: Dieser Leitfaden erläutert die verschiedenen Nur-Lese-Modi, die in Discourse verfügbar sind, wie man sie aktiviert und deaktiviert, sowie die Szenarien, in denen Sie jeden Modus verwenden möchten.

:person_raising_hand: Erforderliche Benutzerstufe: 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 Serverwartungsarbeiten über die Erleichterung von Backups bis hin zur Migration von Servern reichen. In solchen Zeiten ist es entscheidend, die Forenaktivitäten einzuschränken, ohne den Benutzerzugriff vollständig zu unterbrechen.

Discourse bietet verschiedene Nur-Lese-Modi, die Administratoren aktivieren können, um vorübergehend verschiedene Arten von Interaktionen innerhalb einer Site einzufrieren.

Dieser Leitfaden untersucht diese Modi mit besonderem Fokus darauf, wie man sie aktiviert und deaktiviert, einschließlich der Handhabung von Situationen, in denen sich bestimmte Modi überschneiden.

Verständnis der Nur-Lese-Modi

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

  1. Vollständiger Nur-Lese-Modus
  • Schränkt alle Schreibvorgänge im Forum ein und verhindert, dass Benutzer Inhalte erstellen oder ändern, wie z. B. Beiträge verfassen, kommentieren oder liken.
  • Ermöglicht es dem Forum, im Wesentlichen in seinem aktuellen Zustand „eingefroren" zu sein, sodass Benutzer weiterhin bestehende Inhalte lesen und navigieren können, ohne die Datenbank zu beeinträchtigen.
  • Deaktiviert das Ändern von Admin-Site-Einstellungen oder Site-Anpassungen, um den aktuellen Zustand der Datenbank zu erhalten.
  • Deaktiviert neue Foren-Logins für reguläre Benutzer. Administratoren können sich weiterhin über den Admin-E-Mail-Login-Flow (/u/admin-login) anmelden.
  1. Nur-Mitarbeiter-Schreibmodus
  • Schränkt Standardbenutzer von Schreibvorgängen im Forum ein, wie z. B. Beiträge verfassen, kommentieren oder liken. Standardbenutzer sind auf Nur-Lese-Operationen beschränkt, können sich jedoch weiterhin bei ihren Konten anmelden.
  • Ermöglicht es Admin- und Moderator-Aktivitäten, normal fortzusetzen. Administratoren können Site-Einstellungen ändern, und Mitarbeiterbenutzer können Schreibvorgänge wie das Verfassen von Beiträgen, Liken oder das Ändern von Profilen durchführen.

Diese Modi gewährleisten Flexibilität bei der Verwaltung der Betriebsfähigkeit des Forums während kritischer administrativer Phasen.

So aktivieren/deaktivieren Sie Nur-Lese-Modi

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

Vollständiger Nur-Lese-Modus

Über die Rails-Konsole

Wenn Sie Zugriff auf Ihre Discourse-Installation haben, verwenden Sie die Discourse-Rails-Befehlszeilenschnittstelle, 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 das Webinterface Administrationszugriff haben, können Sie zu Admin > Backups > Nur-Lese-Modus aktivieren navigieren, um den Nur-Lese-Modus zu aktivieren.

Um den Nur-Lese-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 > Nur-Lese-Modus deaktivieren navigieren.

Nur-Mitarbeiter-Schreibmodus

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

Um den Nur-Mitarbeiter-Schreibmodus zu aktivieren, verwenden Sie den folgenden Rails-Konsole-Befehl:

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 Nur-Lese-Zeiträume, um angemessene Erwartungen zu setzen.
  • Tests: Führen Sie vor der Implementierung dieser Modi während kritischer Operationen Tests in Zeiten mit geringem Verkehrsaufkommen 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 Operationsplanung zu unterstützen.

Häufig gestellte Fragen (FAQs)

  • Wie lange dauert es, den Nur-Lese-Modus zu aktivieren/deaktivieren?

    • Die Änderung ist sofort wirksam. Das Benutzererlebnis kann jedoch je nach Aktionen während des Übergangszeitraums leicht variieren.
  • Hilfe! Ich bin wegen des Nur-Lese-Modus von meiner Site ausgeschlossen – was kann ich tun, um wieder Zugriff auf meine Site zu erhalten?

  • Ich habe festgestellt, dass es andere READ-ONLY-Modi gibt, die in discourse/lib/discourse.rb 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 übersteht jedoch keinen Container-Neustart.
    • USER_READONLY_MODE_KEY wird verwendet, wenn ein Admin den Nur-Lese-Button im Admin-Interface klickt. Das Besondere an diesem Schlüssel ist, dass wir ihn nicht als ablaufenden Schlüssel festlegen, da ein von einem Benutzer aktivierter Nur-Lese-Modus Container-Neustarts überstehen muss. Andere Schlüssel werden mit einer TTL festgelegt (60 Sekunden für READONLY_MODE_KEY, 300 Sekunden für PG_READONLY_MODE_KEY), und wir haben einen Thread, der alle 30 Sekunden das Ablaufdatum verlängert, um sicherzustellen, dass eine App niemals im Nur-Lese-Modus stecken bleibt.
    • PG_READONLY_MODE_KEY und PG_FORCE_READONLY_MODE_KEY werden für das PG-Failover verwendet. Ersterer ist als ablaufender Schlüssel festgelegt, während Letzterer nicht abläuft.
9 „Gefällt mir“

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

1 „Gefällt mir“

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“

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

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“

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“

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“

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?

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