Website verlässt automatisch den schreibgeschützten Modus, wenn 'discourse enable_readonly' aktiviert wird.

Entwickler
1

Hallo Leute,

ich richte gerade eine Automatisierung für die Bereitstellung und Migration mit Ansible ein, habe aber ein Problem mit dem schreibgeschützten Modus.

Wenn ich den schreibgeschützten Modus mit Folgendem aktiviert habe:
docker exec app discourse enable_readonly
oder

./launcher enter app
discourse enable_readonly

Nach ca. 1:20 Uhr verlässt die Website den schreibgeschützten Modus von selbst.

Wenn ich den schreibgeschützten Modus über die WebUI (Admin-/Backup-Bereich) aktiviere, bleibt er aktiviert, bis ich ihn deaktiviere.

Irgendwelche Gedanken dazu?

1 „Gefällt mir“
2

Haben Sie Ihre Protokolle überprüft? Vielleicht gibt es irgendwo einen Hintergrundauftrag oder ein Plugin, das den Prozess unterbricht.

3

Hallo Lilly,

Danke für deine Antwort. Dies ist eine frische Standardinstallation und ich habe keine Plugins installiert oder Jobs erstellt. Welche Protokolle sollte ich am besten überprüfen? Entschuldigung, ich bin ein ziemlicher Anfänger.

Ich habe tail -f auf Folgendem versucht:

/var/discourse/shared/standalone/log/rails/unicorn.stdout.log
/var/discourse/shared/standalone/log/rails/unicorn.stderr.log
/var/discourse/shared/standalone/log/rails/production_errors.log
/var/discourse/shared/standalone/log/rails/production.log
/var/discourse/shared/standalone/log/rails/sidekiq.log
/var/discourse/shared/standalone/log/var-log/redis/current

Ich habe gewartet, bis das Ereignis eintrat, während ich die Protokolle verfolgte, aber ich habe nichts gesehen, was auffällig war.

Es ist seltsam für mich, dass es über die WebUI perfekt funktioniert, aber nicht über die Kommandozeile.

4

Ich hatte auch Schwierigkeiten, dies zu nutzen, sowohl zum Aktivieren als auch zum Deaktivieren des schreibgeschützten Modus. Das letzte Mal habe ich Discourse.enable_readonly_mode in Rails ausgeführt.

Es ist immer ein Notfall, wenn es passiert, und ich habe nicht untersucht, was das Problem sein könnte.

FWIW, in meinem eigenen Ansible-Tooling verwende ich keinen schreibgeschützten Modus, aber ich verwende Introducing Post Deployment Migration

1 „Gefällt mir“
5

Danke Jay. Ich vermute, ich verfolge einen XY-Ansatz für das Problem. Ich werde mir die Post Deployment Migration ansehen. Danke dafür.

Ich schätze, die andere Option könnte sein, RO über einen API-Aufruf zu aktivieren.

6 
- name: post migrations
  shell: "docker exec  {{ discourse_yml }} bash -c 'rake db:ensure_post_migrations db:migrate'"
  become: yes

damit könnte das für den schreibgeschützten Modus funktionieren:

- name: post migrations
  shell: "docker exec  {{ discourse_yml }} bash -c 'echo Discourse.enable_readonly_mode | rails c'"
  become: yes
7

Danke, sehr geschätzt. Ich werde das heute Abend ausprobieren.

1 „Gefällt mir“
8

Liegt der Unterschied am Read-only-Modus, den Sie verwenden?

3 „Gefällt mir“
9

Danke JammyDodger! Die Infos und der Link waren sehr hilfreich. Ich bin mir nicht sicher, was einen Container-Neustart ausmacht – soweit ich weiß, startet mein Container nicht alle ~1:30 neu, was so lange dauert, wie der RO-Modus aktiviert bleibt, wenn discourse enable_readonly verwendet wird, d. h. Discourse.enable_readonly_mode(Discourse::READONLY_MODE_KEY)

Ich kann jedoch bestätigen, dass Discourse.enable_readonly_mode(Discourse::USER_READONLY_MODE_KEY) unbegrenzt “haftet”, was das war, was ich erreichen wollte :+1:

1 „Gefällt mir“
10

Zur Vollständigkeit:

- name: Set read-only mode for live forum host
  ansible.builtin.shell: |
      docker exec app bash -c 'echo Discourse.enable_readonly_mode\(Discourse::USER_READONLY_MODE_KEY\) | rails c'
  register: enable_readonly_output
2 „Gefällt mir“
11

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.