I caricamenti non vengono orfani e purgati.

Ciao,

Recentemente sono diventato l’ultimo amministratore e manutentore rimasto di un’istanza di base di Discourse Docker, installata originariamente sul nostro server nel 2021 (credo) e per lo più aggiornata da qualcun altro. Da tempo, forse fin dall’inizio, abbiamo avuto un problema con gli upload dai post eliminati in modo “soft” che non venivano orfani e purgati, e ho cercato di risolvere questo problema di nuovo per alcuni giorni poiché i file obsoleti continuano ad accumularsi e a sprecare spazio di archiviazione. Non stiamo usando S3 e c’è abbastanza spazio di archiviazione per gli upload che vogliamo effettivamente mantenere disponibili.

Ho migrato il file di backup completo di Discourse, inclusi gli upload, su un server di staging separato per i test, ricostruendo con il nostro app.yml seguendo le guide ufficiali di installazione di Discourse Docker e successivamente ripristinando il backup dalla riga di comando. Entrambe le installazioni sembrano funzionare in modo identico e senza altri problemi evidenti, ma il problema degli upload persiste.

Non riesco a trovare errori rilevanti nei log e Sidekiq sta eseguendo i processi di pulizia come previsto. Ho eseguito rake db:migrate sulla versione di staging e ricostruito molte volte, ho provato a eliminare definitivamente i post e a controllare le impostazioni. Dopo aver eliminato definitivamente alcuni post direttamente dalla console Rails e aver provato a eseguire manualmente il processo di pulizia, ho notato che la directory “tombstone” era leggermente aumentata di dimensioni a un certo punto e c’erano comunque alcuni file all’inizio, quindi il meccanismo deve aver funzionato in alcune situazioni, giusto? A giudicare dal piccolo aumento di dimensioni, quasi tutti i file obsoleti non vengono ancora rilevati come orfani.

Le impostazioni correnti rilevanti del pannello di amministrazione sono elencate di seguito. Posso impostare le ultime su 0 per saltare effettivamente i periodi di grazia durante i test?

pulisci upload = true
periodo di grazia ore per upload orfani = 1
giorni di periodo di grazia per purghe upload eliminati = 1

Come posso risolvere questo problema in modo efficiente? Ho familiarità con la riga di comando ma le mie competenze di database sono rudimentali, quindi apprezzerei molto alcuni suggerimenti per evitare di esaminare ogni possibile dettaglio di configurazione del server senza un’idea chiara di cosa sto cercando a questo punto.

Ho cercato disperatamente e letto questo forum per casi simili, ma ce ne sono solo alcuni e quelle discussioni sembrano fermarsi a un vicolo cieco o a soluzioni manuali per singoli file, quindi non sono direttamente adatte a questo caso d’uso.

Per favore, chiedetemi ulteriori dettagli se necessario, sto facendo del mio meglio per risolvere questo problema definitivamente.

3 Mi Piace

Ciao e benvenuto @Uphill4721 :slight_smile:

Penso che ci siano alcune informazioni pertinenti in questi argomenti, se ricordo bene:

1 Mi Piace

Grazie per la rapida risposta!

Questi argomenti e alcuni altri collegati sono diventati piuttosto familiari mentre cercavo di risolvere questo problema, ma sfortunatamente non hanno fornito alcuna soluzione definitiva a questo problema.

Ieri sul server di staging ho eseguito questi comandi modificati per argomenti e post eliminati più di 9 giorni fa:

Dopo questo, ho notato un leggero aumento delle dimensioni del contenuto della directory delle lapidi e sto ancora monitorando la situazione a causa del periodo di grazia, chiedendomi ancora se la modifica delle impostazioni pertinenti a zero ore/giorni aggirerebbe il tempo di attesa durante i test.

In precedenza sul server originale avevo provato a rimuovere gli upload dalle revisioni dei post più recenti, ma i file erano ancora disponibili dopo il periodo di grazia.

A questo punto sarei personalmente più che lieto di scoprire qualsiasi soluzione manuale funzionante per eliminare definitivamente anche un singolo argomento con i suoi post e upload non referenziati altrove, ma questo potrebbe essere un grosso problema per altre persone che utilizzano Discourse, presumendo naturalmente che le impostazioni di pulizia nel pannello di amministrazione sarebbero efficaci come descritto, ma non notando necessariamente se non è così e finendo con upload potenzialmente sensibili che si prevede vengano eliminati definitivamente ma che in realtà rimangono nel file system. Il nostro problema considera fortunatamente solo lo spazio di archiviazione sprecato, ma per qualcun altro questo potrebbe essere molto peggio.

C’è un’altra menzione simile solo due mesi fa:

Quindi, qualche consiglio su come capire se si tratta di una errata configurazione da parte nostra o di un bug effettivo? Siamo stati molto contenti di Discourse altrimenti e sono molto motivato a risolvere questo problema e ad aiutare gli altri lungo la strada.

1 Mi Piace

Questa è pura speculazione, ma da una rapida occhiata ai modelli post, post_upload e upload, probabilmente puoi scoprire se hai upload orfani (oggetti del database) con questo:

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))")

Non l’ho testato, quindi non posso essere sicuro se troverà correttamente gli upload orfani o se verrà eseguito senza errori. Nel caso in cui non funzioni così com’è e qualcun altro possa farlo funzionare, oltre che per chiunque altro sia interessato, spiegherò l’intento.

  1. Upload.find_by_sql() restituisce una raccolta di oggetti Upload corrispondenti alla query SQL fornita.
  2. (select id from posts) ottiene tutti gli ID dei post esistenti.
  3. (select upload_id from post_uploads where post_id not in () ottiene tutti gli ID degli upload di post per i quali non esiste alcun post.
  4. select * from uploads where id in () ottiene tutti gli upload corrispondenti a quegli ID di upload di post.

Questa è solo una possibile via da esplorare, sfortunatamente non conosco abbastanza bene il sistema di upload per contribuire in altro modo, se non per dire che quanto sopra non tiene conto di tutte le situazioni. Post modificati anziché eliminati ne sono un esempio ovvio.

Ci sono anche altri tipi di upload non considerati, come gli upload degli utenti, che presumo siano cose come il caricamento di un’immagine del profilo.

I plugin possono anche creare e conservare upload, non so cosa succede con quelli se, ad esempio, il plugin viene rimosso. Penso che i dati del plugin rimangano nel database dopo la rimozione di un plugin, il che potenzialmente significa che tutti gli upload creati da quel plugin non vengono mai rimossi in quella situazione.

4 Mi Piace

Grazie per la risposta!

La query funziona ma elenca solo due caricamenti e i relativi dettagli. Dovrebbero esserci centinaia o migliaia di caricamenti che corrispondono ai criteri “orphan”, la maggior parte dei quali sono file immagine originariamente caricati dagli utenti durante la creazione di normali post.

Attualmente stiamo utilizzando solo plugin ufficiali:

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

C’è stato una sorta di revisione del processo di caricamento poco dopo la nostra installazione originale, mi chiedo se possa essere correlato alla nostra situazione in qualche modo: A new era for file uploads in Discourse

Il periodo di grazia dovrebbe essere terminato sul server di staging ormai, ma non vedo alcun effetto sulla dimensione della directory di caricamento e i file di test sono ancora disponibili. Cosa dovrei cercare successivamente? Potrebbe essere causato da permessi del filesystem errati o simili, c’è un modo semplice per verificarlo? Sto esaurendo le idee per obiettivi specifici, tutto il resto funziona alla grande e questo è l’unico problema che abbiamo attualmente.

Sto esaminando argomenti simili per raccogliere casi irrisolti potenzialmente pertinenti, ecco un buon esempio di come queste situazioni possano persino causare problemi legali a causa di caricamenti degli utenti che non vengono resi orfani e rimossi permanentemente come dovrebbero:

Un’altra situazione simile risalente al 2016:

Questi tipi di condizioni creano un’enorme apertura per abusi e persino attacchi mirati per il caricamento di contenuti illegali che potrebbero non essere rimossi permanentemente dal server anche quando gli amministratori presumono che lo sarebbero. Naturalmente, eliminare singoli file manualmente direttamente dal file system è possibile, ma non credo che le persone debbano essere costrette a percorrere quella strada per un’esigenza così basilare, soprattutto quando c’è un’impostazione GUI che indica un processo di eliminazione automatica e i moderatori spesso non hanno accesso diretto al server. Inoltre, l’eliminazione manuale non è pratica con molti file sparsi in diversi argomenti eliminati.

C’è qui una base sufficiente per un vero report di bug? Non escludo ancora una possibile errata configurazione da parte nostra, ma sono sconcertato dalla mancanza di messaggi di errore e tutto il resto sembra funzionare correttamente. Ho trascorso un numero crescente di giorni per la risoluzione dei problemi e i test, acquisendo maggiori conoscenze su Discourse e i suoi componenti nel processo, quindi penso che con qualche guida potrei essere in grado di aiutare a capire se c’è qualche dettaglio di un caso limite che scatena questo strano comportamento. Spero che vada bene menzionare @zogstrip a questo punto?

Come soluzione temporanea, è possibile spostare manualmente tutti i caricamenti nella directory “tombstone” e utilizzare i metodi di recupero dei caricamenti per ripristinare solo i file non orfani nelle loro directory corrette? Ho effettivamente provato a farlo oggi, ma rake uploads:recover_from_tombstone non ha ripristinato alcun file. Questo potrebbe indicare un problema più grande con le voci del database dei caricamenti?

Ciao. Sto riscontrando lo stesso problema o uno simile, non riesco a capire perché i file non vengano eliminati. Qualcun altro ha ancora questo problema?
Ho eseguito alcune query SQL e i riferimenti di caricamento “bloccati” sembrano essere tutti Bozze, ma ho controllato le mie e quelle di altri utenti e non ce ne sono. Le tabelle delle Bozze sono vuote.
La pulizia degli orfani è abilitata e le impostazioni sono impostate per eliminare gli orfani il più velocemente possibile.
Ho allegato una query SQL.

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)

Ciò accade da quando ho installato il forum. Anche quando non c’erano temi personalizzati o plugin installati.
Persino il vecchio logo del forum che ho caricato un paio di volte (il primo file caricato in assoluto) è ancora referenziato come Bozza ed è ancora nella cartella degli upload. :man_facepalming:
Teoricamente potrei filtrare tutti i riferimenti di caricamento e filtrare per Bozze per tipo di destinazione, quindi eliminare dal database… e lasciare che i task di sidekiq gestiscano la pulizia (ho ragione?)
ma sto usando un’istanza self-hosted e sono abbastanza nuovo a Discourse, quindi è meglio chiedere qui…
Sarebbe una soluzione temporanea, ma rimane una domanda: perché sta succedendo?

Spero che qualcuno abbia qualche suggerimento, il mio spazio su disco sta crescendo esponenzialmente :smile:

1 Mi Piace

Sì, abbiamo ancora questo problema.\n\nMi piacerebbe davvero risolverlo in qualche modo, il nostro forum riceve molti caricamenti ma solo una frazione di essi deve essere conservata a lungo termine, quindi molto spazio su disco viene sprecato. Qualsiasi suggerimento per la risoluzione dei problemi è apprezzato.\n\n[quote="kilometrs, post:7, topic:259036, username:groove6j"]\nIn teoria potrei filtrare tutti i riferimenti ai caricamenti e filtrare per Bozze per tipo di destinazione, quindi eliminare dal database… e lasciare che i task di sidekiq gestiscano la pulizia (ho ragione?)\n[/quote]\n\nInteressato a questa come soluzione temporanea, se è pratica. :thinking:

Ho installato il forum 2 settimane fa e ha questo problema fin dall’inizio. Sembra un bug.
Puoi eseguire la stessa query SQL e verificare se ci sono molti riferimenti “Bozze” bloccati? È facile da vedere, ne ho dozzine ma nella tabella delle bozze ci sono 2, forse 3 bozze reali. Sembra che non vengano eliminate dopo la modifica (non essendo più una bozza, ma il riferimento rimane nel database ogni volta che un post viene modificato, ad esempio).

Devo capire come eliminare una voce di riferimento dal database ed eliminare prima i riferimenti per un file, quindi verificare se l’attività di pulizia funziona.
Non so quanto sia sicuro farlo, ma queste innumerevoli voci di bozze mi sembrano semplicemente sbagliate.

Posso fornire i log allo staff/sviluppatori, sono solo nuovo a Discourse e non so quali file di log sarebbero utili.

MODIFICA:
Sto cercando di capire la struttura del database e posso eliminare queste voci di caricamento senza ulteriori problemi (non voglio perdere alcune importanti relazioni del database). Inoltre, non capisco cosa siano esattamente le sequenze di bozze.
Ma devo duplicare il mio forum di produzione su una VM locale, solo allora potrò testare…

Un altro argomento pertinente, ho pubblicato lì poiché non ero a conoscenza di questo argomento.

Credo che l’unico modo per eliminare veramente un’immagine in modo automatico sia modificarla manualmente dal post prima di eliminarla. Ma non sono del tutto sicuro che funzioni nemmeno. Sto usando impostazioni identiche alle tue per quanto riguarda la pulizia (ma uso storage compatibile con S3) e posso anche confermare che le immagini non vengono mai eliminate se l’unico post contenente quell’immagine (diversi post possono contenere la stessa immagine, presumibilmente anche avatar e banner utente) viene eliminato.

Uso questa soluzione per cercare se un’immagine viene utilizzata in post aggiuntivi, che è stata fornita da @RGJ

Sarebbe davvero fantastico se ciò potesse essere fatto automaticamente. Soprattutto perché Discourse gestisce le immagini in modo intelligente, impedendo la creazione di file duplicati se molti post utilizzano la stessa immagine. Il rovescio della medaglia è che è molto noioso rimuovere singole immagini che sono state utilizzate molto.

Ho avuto qualcuno che ha inviato spam di contenuti che necessitavano di rimozione urgente tramite diversi account in precedenza ed è stato molto stressante cercare di gestirlo e assicurarsi che fosse completamente rimosso (tutti i file originali, file ottimizzati, cache CDN, post, avatar, banner utente, ecc.).

Ho creato questo suggerimento di funzionalità, poiché sarebbe molto utile secondo me. Se ciò venisse implementato, oltre a eliminare automaticamente i contenuti contenuti nei post eliminati, penso che tutti i casi sarebbero coperti e potrebbero essere gestiti senza accesso SSH.

1 Mi Piace