Uploads werden nicht verwaist und bereinigt

Unterstützung
1

Hallo,

Ich bin kürzlich der letzte verbleibende Administrator und Betreuer einer einfachen Discourse Docker-Image-Instanz geworden, die ursprünglich (ich glaube) 2021 auf unserem Server installiert und größtenteils von jemand anderem aktualisiert wurde. Seit einiger Zeit, möglicherweise von Anfang an, haben wir ein Problem damit, dass Uploads aus weich gelöschten Beiträgen nicht verwaist und gelöscht werden. Ich versuche nun seit einigen Tagen erneut, dieses Problem zu beheben, da sich die veralteten Dateien immer weiter ansammeln und Speicherplatz verschwenden. Wir verwenden kein S3 und es gibt genügend Speicherplatz für die Uploads, die wir tatsächlich behalten möchten.

Ich habe die vollständige Discourse-Backup-Datei einschließlich Uploads auf einen separaten Staging-Server migriert, um dies zu testen, indem ich unsere app.yml gemäß den offiziellen Discourse Docker-Installationsanleitungen neu erstellt und anschließend das Backup über die Befehlszeile wiederhergestellt habe. Beide Installationen scheinen identisch gut zu laufen, ohne andere offensichtliche Probleme, aber das Upload-Problem bleibt bestehen.

Ich kann keine relevanten Fehler in den Protokollen finden und Sidekiq führt die Bereinigungsaufträge wie geplant aus. Ich habe rake db:migrate auf der Staging-Version ausgeführt und viele Male neu erstellt, versucht, Beiträge dauerhaft zu löschen und die Einstellungen überprüft. Nachdem ich einige Beiträge direkt über die Rails-Konsole dauerhaft gelöscht und versucht habe, den Bereinigungsauftrag manuell auszuführen, bemerkte ich, dass das Tombstone-Verzeichnis zu diesem Zeitpunkt nur ein wenig an Größe zugenommen hatte und sowieso einige Dateien vorhanden waren, sodass der Mechanismus in einigen Situationen funktioniert haben muss, oder? Nach der geringen Größenänderung werden fast alle veralteten Dateien immer noch nicht als Waisen erkannt.

Die aktuell relevanten Einstellungen im Admin-Panel sind unten aufgeführt. Kann ich die letzten auf 0 setzen, um die Wartezeiten beim Testen effektiv zu überspringen?

uploads bereinigen = true
Wartezeit für verwaiste Uploads (Stunden) = 1
Wartezeit für das Löschen von Uploads (Tage) = 1

Wie kann ich dies effizient beheben? Ich bin mit der Befehlszeile vertraut, aber meine Datenbankkenntnisse sind rudimentär, daher würde ich mich über einige Tipps freuen, um nicht alle möglichen Server-Setup-Details ohne Ahnung zu durchsuchen, wonach ich im Moment suche.

Ich habe verzweifelt dieses Forum nach ähnlichen Fällen durchsucht und gelesen, aber es gibt nur wenige und diese Threads scheinen entweder in einer Sackgasse zu enden oder manuelle Lösungen für einzelne Dateien zu bieten, was für diesen Anwendungsfall nicht direkt geeignet ist.

Bitte fragen Sie mich nach weiteren Details, falls erforderlich. Ich tue mein Bestes, um dies endgültig zu lösen.

3 „Gefällt mir“
2

Hallo und willkommen @Uphill4721 :slight_smile:

Ich glaube, in diesen Themen gibt es einige relevante Informationen, wenn ich mich recht erinnere:

1 „Gefällt mir“
3

Vielen Dank für die schnelle Antwort!

Diese Themen und ein paar weitere, die in ihnen verlinkt sind, sind mir bei der Lösung dieses Problems sehr vertraut geworden, aber leider haben sie keine definitive Lösung für dieses Problem geboten.

Gestern habe ich auf dem Staging-Server diese Befehle ausgeführt, die für gelöschte Themen und Beiträge, die älter als 9 Tage sind, modifiziert wurden:

Danach bemerkte ich eine leichte Zunahme der Größe des Tombstone-Verzeichnisses und beobachte die Situation aufgrund der Schonfrist weiterhin. Ich frage mich immer noch, ob eine Änderung der relevanten Einstellungen auf null Stunden/Tage die Wartezeit beim Testen umgehen würde.

Zuvor habe ich auf dem ursprünglichen Server versucht, Uploads aus den neuesten Beitragsrevisionen zu entfernen, aber die Dateien waren nach der Schonfrist immer noch verfügbar.

An diesem Punkt wäre ich persönlich mehr als erfreut, eine funktionierende manuelle Lösung zu finden, um auch nur ein einziges Thema mit seinen Beiträgen und Uploads dauerhaft zu löschen, auf die sonst nirgendwo verwiesen wird. Dies könnte jedoch ein großes Problem für andere Personen sein, die Discourse nutzen, da sie davon ausgehen, dass die Bereinigungseinstellungen im Admin-Panel wie beschrieben wirksam sind, aber nicht unbedingt bemerken, wenn dies nicht der Fall ist, und am Ende potenziell sensible Uploads haben, von denen erwartet wird, dass sie dauerhaft gelöscht werden, aber tatsächlich im Dateisystem verbleiben. Unser Problem betrifft glücklicherweise nur verschwendeten Speicherplatz, aber für jemand anderen könnte dies viel schlimmer sein.

Es gibt eine weitere ähnliche Erwähnung vor nur zwei Monaten:

Haben Sie also Tipps, wie wir herausfinden können, ob es sich um eine Fehlkonfiguration unsererseits oder um einen tatsächlichen Fehler handelt? Wir sind mit Discourse ansonsten sehr zufrieden und ich bin sehr motiviert, dies zu lösen und anderen dabei zu helfen.

1 „Gefällt mir“
4

Dies ist rein spekulativ, aber bei einem kurzen Blick auf die Modelle post, post_upload und upload können Sie wahrscheinlich herausfinden, ob Sie verwaiste Uploads (Datenbankobjekte) haben, indem Sie Folgendes verwenden:

Upload.find_by_sql("select * from uploads where id in (select upload_id from post_uploads where post_id not in (select id from posts))")

Ich habe das nicht getestet, daher bin ich mir nicht sicher, ob es verwaiste Uploads korrekt findet oder sogar fehlerfrei ausgeführt wird. Falls es nicht wie erwartet funktioniert und jemand anderes es zum Laufen bringen kann, sowie für alle anderen Interessierten, werde ich die Absicht erläutern.

  1. Upload.find_by_sql() gibt eine Sammlung von Upload-Objekten zurück, die mit der bereitgestellten SQL-Abfrage übereinstimmen.
  2. (select id from posts) ruft alle IDs für vorhandene Beiträge ab.
  3. (select upload_id from post_uploads where post_id not in ()) ruft alle IDs für Post-Uploads ab, für die kein Beitrag existiert.
  4. select * from uploads where id in () ruft alle Uploads ab, die diesen Post-Upload-IDs entsprechen.

Das ist jedoch nur ein möglicher Weg zur Untersuchung. Leider kenne ich das Upload-System nicht gut genug, um sonst viel beizutragen, außer zu sagen, dass das oben Genannte definitiv nicht alle Situationen abdeckt. Bearbeitete statt gelöschter Beiträge sind ein offensichtliches Beispiel.

Es gibt auch andere Arten von Uploads, die nicht berücksichtigt werden, wie z. B. Benutzer-Uploads, bei denen ich davon ausgehe, dass es sich um Dinge wie das Hochladen eines Profilbildes handelt.

Plugins können auch Uploads erstellen und behalten. Ich weiß nicht, was mit diesen passiert, wenn z. B. das Plugin entfernt wird. Ich glaube, dass Plugin-Daten nach dem Entfernen eines Plugins in der Datenbank verbleiben, was potenziell bedeutet, dass alle von diesem Plugin erstellten Uploads in dieser Situation nie entfernt werden.

4 „Gefällt mir“
5

Vielen Dank für die Antwort!

Die Abfrage funktioniert, listet aber nur zwei Uploads und deren Details auf. Es sollte Hunderte oder Tausende von Uploads geben, die den Kriterien für verwaiste Dateien entsprechen, die meisten davon sind Bilddateien, die ursprünglich von Benutzern beim Erstellen normaler Beiträge hochgeladen wurden.

Wir verwenden derzeit nur offizielle Plugins:

hooks:
  after_code:
    - exec:
        cd: $home/plugins
        cmd:
          - git clone https://github.com/discourse/docker_manager.git
          - git clone https://github.com/discourse/discourse-chat-integration.git
          - git clone https://github.com/discourse/discourse-prometheus.git
          - git clone https://github.com/discourse/discourse-bbcode-color
          - git clone https://github.com/discourse/discourse-data-explorer

Es gab eine Art Überarbeitung des Upload-Prozesses eine Weile nach unserer ursprünglichen Installation, ich frage mich, ob dies irgendwie mit unserer Situation zusammenhängen könnte: A new era for file uploads in Discourse

Die Kulanzfrist sollte auf dem Staging-Server inzwischen abgelaufen sein, aber ich sehe keine Auswirkung auf die Größe des Upload-Verzeichnisses und Testdateien sind immer noch verfügbar. Was sollte ich als Nächstes suchen? Könnte dies durch fehlerhafte Dateisystemberechtigungen oder ähnliches verursacht werden, gibt es eine einfache Möglichkeit, dies zu überprüfen? Mir gehen die Ideen für spezifische Ziele aus, alles andere läuft großartig und dies ist das einzige Problem, das wir derzeit haben.

6

Ähnliche Themen durchgehen, um möglicherweise passende ungelöste Fälle zu sammeln. Hier ist ein gutes Beispiel dafür, wie diese Situationen aufgrund von Benutzer-Uploads, die nicht wie erwartet verwaist und dauerhaft entfernt werden, sogar rechtliche Probleme verursachen können:

Eine weitere ähnliche Situation aus dem Jahr 2016:

Diese Art von Bedingungen schafft eine riesige Angriffsfläche für Missbrauch und sogar gezielte Angriffe zum Hochladen illegaler Inhalte, die möglicherweise nicht dauerhaft vom Server entfernt werden, selbst wenn die Administratoren davon ausgehen. Natürlich ist das manuelle Löschen einzelner Dateien direkt aus dem Dateisystem möglich, aber ich glaube nicht, dass die Leute für eine so grundlegende Notwendigkeit gezwungen werden sollten, diesen Weg zu gehen, insbesondere wenn eine GUI-Einstellung einen automatischen Bereinigungsprozess anzeigt und Moderatoren oft keinen direkten Zugriff auf den Server haben. Außerdem ist das manuelle Löschen bei vielen Dateien, die über verschiedene gelöschte Themen verstreut sind, nicht praktikabel.

Gibt es hier genug Grundlage für einen tatsächlichen Fehlerbericht? Ich schließe eine mögliche Fehlkonfiguration unsererseits nicht aus, aber ich bin verblüfft über das Fehlen von Fehlermeldungen und alles andere scheint einwandfrei zu funktionieren. Ich habe immer mehr Tage mit Fehlerbehebung und Tests verbracht und dabei mehr Wissen über Discourse und seine Komponenten gewonnen, sodass ich denke, dass ich mit etwas Anleitung herausfinden könnte, ob es einen Eckfall gibt, der dieses seltsame Verhalten auslöst. Ich hoffe, es ist in Ordnung, @zogstrip zu diesem Zeitpunkt zu pingen?

Ist es als temporäre Lösung möglich, alle Uploads manuell in das Tombstone-Verzeichnis zu verschieben und die Upload-Wiederherstellungsmethoden zu verwenden, um nur die nicht verwaisten Dateien wieder in ihre richtigen Verzeichnisse wiederherzustellen? Ich habe dies heute tatsächlich versucht, aber rake uploads:recover_from_tombstone hat keine Dateien wiederhergestellt. Könnte dies auf ein größeres Problem mit den Datenbankeinträgen der Uploads hinweisen?

7

Hallo. Ich habe dasselbe oder ein ähnliches Problem, kann aber nicht herausfinden, warum die Dateien nicht gelöscht werden können. Hat noch jemand dieses Problem?
Ich habe einige SQL-Abfragen ausgeführt und die „hängenden“ Upload-Referenzen scheinen alle Entwürfe (Drafts) zu sein, aber ich habe meine und die Entwürfe anderer Benutzer überprüft und es gibt keine. Die Entwurfs-Tabellen sind leer.
Die Waisenbereinigung (orphan cleaning) ist aktiviert und die Einstellungen sind so gesetzt, dass die Waisen so schnell wie möglich gelöscht werden.
Ich habe eine SQL-Abfrage angehängt.

SELECT 
    uploads.original_filename,
    ROUND(uploads.filesize / 1000000.0, 2) AS size_in_mb,
    uploads.extension,
    uploads.created_at,
    uploads.url,
    upload_references.upload_id,
    upload_references.target_id,
    upload_references.target_type,
    upload_references.created_at,
    upload_references.updated_at
FROM upload_references
JOIN uploads ON uploads.id = upload_references.upload_id
ORDER BY uploads.filesize DESC
LIMIT 250

sql.csv (46,1 KB)

Das passiert, seit ich das Forum installiert habe. Selbst als keine benutzerdefinierten Themes oder Plugins installiert waren.
Selbst das alte Forum-Logo, das ich ein paar Mal hochgeladen habe (die allererste hochgeladene Datei), wird immer noch als Entwurf referenziert und ist immer noch im Upload-Ordner. :man_facepalming:
Theoretisch könnte ich alle Upload-Referenzen filtern und nach Entwürfen nach target_type filtern, dann aus der Datenbank löschen… und die Sidekiq-Aufgaben die Bereinigung erledigen lassen (habe ich Recht?)
aber ich benutze eine selbst gehostete Instanz und bin ziemlich neu bei Discourse, daher frage ich lieber hier…
Das wäre eine Problemumgehung, aber es bleibt die Frage: Warum passiert das?

Ich hoffe, jemand hat einige Vorschläge, mein Speicherplatz wächst exponentiell :smile:

1 „Gefällt mir“
8

Ja, wir haben dieses Problem auch immer noch.

Ich würde es wirklich gerne irgendwie lösen, unser Forum erhält viele Uploads, aber nur ein Bruchteil davon muss langfristig aufbewahrt werden, sodass viel Speicherplatz verschwendet wird. Vorschläge zur Fehlerbehebung werden gerne angenommen.

Interessiert an dieser als temporäre Lösung, wenn sie praktikabel ist. :thinking:

9

Ich habe das Forum vor 2 Wochen installiert und es hat seit Beginn dieses Problem. Sieht aus wie ein Bug.
Können Sie die gleiche SQL-Abfrage ausführen und prüfen, ob es viele festsitzende „Entwürfe“-Referenzen gibt? Es ist leicht zu sehen, ich habe Dutzende davon, aber in der Entwurftabelle gibt es 2, vielleicht 3 echte Entwürfe. Es sieht so aus, als ob sie nach der Bearbeitung nicht gelöscht werden (nicht mehr als Entwurf gelten, aber die Referenz jedes Mal in der Datenbank verbleibt, wenn ein Beitrag bearbeitet wird, zum Beispiel).

Ich muss herausfinden, wie man einen Referenzeintrag aus der Datenbank löscht und zuerst die Referenzen für eine Datei löscht, dann prüfen, ob die Bereinigungsaufgabe funktioniert.
Ich weiß nicht, wie sicher das ist, aber diese unzähligen Entwurfs-Einträge scheinen mir einfach falsch zu sein.

Ich kann Protokolle für Mitarbeiter/Entwickler bereitstellen, ich bin nur neu bei Discourse und weiß nicht, welche Protokolldateien helfen würden.

EDIT:
Ich versuche, die Datenbankstruktur zu verstehen, und kann ich diese Upload-Einträge ohne weitere Probleme löschen (ich möchte keine wichtigen DB-Beziehungen verpassen). Ich verstehe auch nicht genau, was draft_sequences sind.
Aber ich muss mein Produktionsforum auf eine lokale VM duplizieren, erst dann kann ich testen…

10

Ein weiteres relevantes Thema, ich habe dort gepostet, da ich mir dieses Themas nicht bewusst war.

Ich glaube, der einzige Weg, ein Bild auf automatische Weise wirklich zu löschen, ist, es manuell aus dem Beitrag zu bearbeiten, bevor es gelöscht wird. Aber ich bin mir nicht ganz sicher, ob das auch funktioniert. Ich verwende identische Einstellungen wie Sie bezüglich des Purging (verwende aber S3-kompatiblen Speicher) und kann auch bestätigen, dass Bilder niemals gelöscht werden, wenn der einzige Beitrag, der dieses Bild enthält (mehrere Beiträge können dasselbe Bild enthalten, vermutlich auch Avatare und Benutzerbanner), gelöscht wird.

Ich verwende diese Lösung, um zu suchen, ob ein Bild in zusätzlichen Beiträgen verwendet wird, die von @RGJ bereitgestellt wurde

Es wäre wirklich großartig, wenn dies automatisch geschehen könnte. Insbesondere da Discourse Bilder auf intelligente Weise handhabt und die Erstellung doppelter Dateien verhindert, wenn viele Beiträge dasselbe Bild verwenden. Die Kehrseite ist, dass es sehr mühsam ist, einzelne Bilder zu entfernen, die oft verwendet wurden.

Ich hatte jemanden, der Inhalte gespammt hat, die dringend entfernt werden mussten, über mehrere Konten hinweg, und es war sehr stressig, damit umzugehen und sicherzustellen, dass sie vollständig entfernt wurden (alle Originaldateien, optimierte Dateien, CDN-Cache, Beiträge, Avatare, Benutzerbanner usw.).

Ich habe diesen Feature-Vorschlag gemacht, da er meiner Meinung nach sehr hilfreich wäre. Wenn dies implementiert würde, sowie das automatische Löschen von Inhalten, die in gelöschten Beiträgen enthalten sind, denke ich, dass alle Fälle abgedeckt wären und ohne SSH-Zugriff gehandhabt werden könnten.

1 „Gefällt mir“