Avatar persi dopo il ripristino. Come recuperarli?

Supporto
41

Buongiorno @ariznaf,

Prima di trarre questa conclusione, puoi andare su tutte le tue installazioni, accedere alla cartella condivisa di ciascuna e eseguire questo comando per ogni installazione, riportando poi i risultati?

# du -sh uploads

Ad esempio, sulle nostre installazioni ho fatto così:

Installazione originale:

# du -sh uploads
2.5G uploads

Installazione solo socket (prima di risolvere il problema):

# du -sh uploads
444K uploads

Questo mi ha fornito l’indizio necessario per capire che dovevo copiare manualmente la cartella uploads; e, conoscendo il problema, la soluzione è semplice.

Se controlli tutte le tue diverse cartelle uploads con il comando du -sh uploads in tutte le directory condivise, otterrai un indizio prezioso su cosa stia succedendo.

Se sono diverse, allora sai che alcune upload mancano e puoi correggere manualmente la situazione.

Se sono tutte uguali (improbabile), allora il problema diventa più interessante :slight_smile:

42

Ho trovato il problema (non la soluzione).
Il problema non è il ripristino in sé, ma la modifica del nome del server.

Lasciate che vi spieghi come ho eseguito il ripristino (nel caso ci fosse qualche passaggio mancante).

Ho scaricato una copia fresca di Discourse da GitHub.
Ho eseguito il processo di configurazione di Docker.
Prima di avviare l’app e procedere con il ripristino, ho modificato app.yml per configurare l’accesso al socket.
E ho cambiato il nome dell’host in b.domain.com (nell’originale era a.domain.com).

Ho configurato il reverse proxy nginx utilizzando SSL per instradare il traffico HTTPS sulla porta 443 verso il socket di Discourse.
Poi ho ricompilato (launcher rebuild app) e riavviato nginx (service nginx restart).
Ho accesso a https://b.domain.com per eseguire la configurazione iniziale di Discourse.
L’ho configurato per ripristinare da S3 e ho ripristinato l’ultimo backup del database e dei file caricati (senza miniature).
Dopo il ripristino, l’utente viene disconnesso.
Ho modificato app.yml per copiare il file app.yml dal vecchio sito (al fine di ottenere la stessa configurazione e gli stessi plugin).
Ho cambiato il nome dell’host in b.domain.com in app.yml.

Di nuovo una ricompilazione e un riavvio di nginx.

IL PROBLEMA persiste: le immagini del profilo (miniature) di tutti coloro che hanno modificato il proprio profilo sono state sostituite dall’immagine del profilo bianca.
Manca anche il nostro logo nell’angolo in alto a sinistra.

@Stephen force_https era attivo (come nel server originale, senza problemi). Ho provato ad attivarlo e disattivarlo, senza alcun effetto. L’ho lasciato attivo, poiché vogliamo che il nostro sito sia accessibile tramite HTTPS (comunque il traffico HTTP:80 ha un reindirizzamento permanente nella nostra configurazione nginx verso HTTPS:443).

@riking Ho utilizzato sidekiq e attivato il job avatarmissing, che sembrava completarsi correttamente in pochi millisecondi. Nel caso fosse un processo lungo, ho aspettato quasi 24 ore per vedere se le immagini del profilo venivano ricostruite.
Ma oggi abbiamo lo stesso problema: nessuna immagine avatar (per le persone che hanno caricato un’immagine del profilo) e nessuna immagine del logo.

Dopo ciò, ho cercato di capire se il problema fosse il cambio di nome, come suggerito da @Stephen.

Ho riportato il nome dell’host in app.yml e nginx a a.domain.com (quello originale), ho ricompilato e riavviato nginx.
Ho modificato il file hosts locale per puntare a.domain.com all’IP del nuovo server e ho provato un ping per verificare che stesse accedendo al nuovo IP.

E VOILÀ: ecco gli avatar e il nostro profilo.

Quindi il problema non è il processo di ripristino in sé; il problema è che in qualche modo il percorso completo dell’URL viene salvato e il sistema tenta di accedervi dal luogo sbagliato.
È strano comunque, dato che il server originale è attivo e funzionante (dovrebbe aver trovato le immagini anche dal luogo sbagliato, cioè dal server originale invece che dal nuovo).

Comunque, il problema non è legato al processo di ripristino o alla necessità di ricaricare le immagini a causa di qualche tipo di corruzione.

Il problema è il cambio del nome del server.

Ora la domanda è: come si sposta un forum Discourse da un dominio/nome host a un altro?

43

Ho provato a cambiare di nuovo il nome dell’host in b.domain.com.

Nessun risultato.

Sembra che quando uso il vecchio nome tutto funzioni (ma ora sospetto che stia recuperando immagini e altro dal vecchio server che è ancora online, poiché ricevo nuovi post e notifiche da nuovi post sul vecchio server, anche se ho modificato l’IP per a.domain.com nel mio file hosts).

Ho seguito le istruzioni in questo post per cambiare il nome dell’host:

Pensavo che rimappare a.domain.com su b.domain.com avrebbe risolto il problema.
Anche dopo aver eseguito il comando rake posts:rebake, il risultato è lo stesso.

Ho perso gli avatar e il logo, e anche le immagini inserite nei post sono sparite.

Infine, come suggerito da @neounix, ho estratto di nuovo tutti gli upload per sostituire la destinazione in shared/standalone/uploads/, ma senza successo: i risultati sono gli stessi.

44

C’è davvero qualche informazione utile nel tuo database? Potrebbe essere più semplice ricominciare da capo, senza doversi preoccupare affatto dei trasferimenti del server.

45

Tutti i dati e i post dal primo giorno del forum, mesi fa?

Come ho già detto, sono riuscito a spostare il server su un’altra macchina fermando il server, copiando tutti i dati su uno nuovo e riavviandolo.

Ma il supporto mi ha detto che il modo corretto di procedere è utilizzare il backup standard e ripristinare il database.

Sto cercando di farlo, ma ogni volta incontro qualche tipo di problema.
Ho anche bisogno di un server per i test, per verificare l’effetto di plugin, modifiche o aggiornamenti prima di applicarli in produzione.

Non posso aspettare che il server si blocchi per vedere se riesco a ripristinarlo o meno.

I test di ripristino finora si sono conclusi con qualche tipo di problema, lasciando un sistema non funzionante, con immagini o altri elementi persi.

46

Seguendo questa saga:

https://meta.discourse.org/t/postgresql-12-update/151236/193

Ho provato il metodo “backup e ripristino su un’istanza Discourse diversa” e ora mi trovo di fronte a questo. Ho provato ogni trucco del mestiere (il lavoro Sidekiq, il Rebake…): c’è qualche “indizio” su cosa possa causare questo? Solo per cercare di capire qualcosa.

(Una cosa che devo dirvi: con tutto questo sto passando dal “sì, ci capisco qualcosa” a un dottorato in PostGreSQL, un dottorato in Redis… :stuck_out_tongue: Devo solo prendere confidenza con Ruby e gli ambienti di sviluppo locali, e potrei diventare utile alla Community :stuck_out_tongue: )

47

Sono scomparsi tutti gli avatar o solo alcuni? Gli avatar personalizzati sono essenzialmente Upload: funzionano correttamente anche altri caricamenti?

Vai alla console Rails e controlla il record dell’avatar non funzionante nel database… Hanno URL, dimensione file, larghezza, altezza, estensione corretti?

User.find_by_username('Overgrow').user_avatar
User.find_by_username('Overgrow').uploaded_avatar

Devono anche avere le versioni ottimizzate presenti. Puoi verificarlo con:

OptimizedImage.where(upload_id: upload_id).where(version: 2)
48

Innanzitutto, grazie mille per il tuo aiuto @Overgrow.

Tutti gli avatar e gli emoji (e persino le immagini del sito, come le intestazioni, ecc.) erano “presenti” ma invisibili. Per gli elementi non relativi agli avatar, apparivano come rotti; per gli avatar, si vedeva il segnaposto grigio. Alcune persone sono riuscite semplicemente a caricarne uno nuovo e quelle si vedono.

Al primo tentativo di eseguire il comando, ho ottenuto:

FATAL: il sistema del database è in modalità di recupero

Quindi… c’è questo :eyes: (ho molti “disconnettersi”, quindi presumo che abbia a che fare con il DB, forse?)

Ma dopo aver persistito alla fine:

User.find_by_username(‘Overgrow’).user_avatar

=> #<UserAvatar:0x000055702722d200
 id: 4,
 user_id: 3,
 custom_upload_id: 20504,
 gravatar_upload_id: 12240,
 last_gravatar_download_attempt: Thu, 21 May 2020 10:16:55 UTC +00:00,
 created_at: Sat, 30 May 2019 16:33:16 UTC +00:00,
 updated_at: Thu, 21 May 2020 10:16:55 UTC +00:00>

(Ho provato a caricarne uno nuovo oggi ma non funziona).

User.find_by_username(‘Overgrow’).uploaded_avatar

=> #<Upload:0x00005555cd911b58
 id: 20504,
 user_id: 3,
 original_filename: "16_2.png.jpg",
 filesize: 56220,
 width: 360,
 height: 360,
 url: "/uploads/default/original/3X/6/3/63347a46c0ca945f53613722a73c233484d642c8.jpeg",
 created_at: Thu, 15 Aug 2019 20:02:47 UTC +00:00,
 updated_at: Thu, 15 Aug 2019 20:02:47 UTC +00:00,
 sha1: "63347a46c0ca945f53613722a73c233484d642c8",
 origin: nil,
 retain_hours: nil,
 extension: "jpeg",
 thumbnail_width: 360,
 thumbnail_height: 360,
 etag: nil,
 secure: false,
 access_control_post_id: nil,
 original_sha1: nil>

OptimizedImage.where(upload_id: 20504).where(version: 2)

=> [#<OptimizedImage:0x000056366a01c1a0
  id: 95962,
  sha1: "5a32b5cc3e6f5c58d88a3c92a23076980a8ce840",
  extension: ".jpeg",
  width: 200,
  height: 200,
  upload_id: 20504,
  url: "/uploads/default/optimized/3X/6/3/63347a46c0ca945f53613722a73c233484d642c8_2_200x200.jpeg",
  filesize: 28916,
  etag: nil,
  version: 2>,
 #<OptimizedImage:0x000056366a0741e8
  id: 95942,
  sha1: "ee353c9e23511b471e1a59c1f71a2ded3e366b1e",
  extension: ".jpeg",
  width: 20,
  height: 20,
  upload_id: 20504,
  url: "/uploads/default/optimized/3X/6/3/63347a46c0ca945f53613722a73c233484d642c8_2_20x20.jpeg",
  filesize: 1270,
  etag: nil,
  version: 2>,
 #<OptimizedImage:0x000056366a074120
  id: 95943,
  sha1: "944fa9fc542a79a5c50394c75022bf84ace297e5",
  extension: ".jpeg",
  width: 30,
  height: 30,
  upload_id: 20504,
  url: "/uploads/default/optimized/3X/6/3/63347a46c0ca945f53613722a73c233484d642c8_2_30x30.jpeg",
  filesize: 1952,
  etag: nil,
  version: 2>,
 #<OptimizedImage:0x000056366a074058
  id: 95944,
  sha1: "983490e58bed58c971ffa44e440b02ce3ea72bba",
  extension: ".jpeg",
  width: 40,
  height: 40,
  upload_id: 20504,
  url: "/uploads/default/optimized/3X/6/3/63347a46c0ca945f53613722a73c233484d642c8_2_40x40.jpeg",
  filesize: 2695,
  etag: nil,
  version: 2>,
 #<OptimizedImage:0x000056366a07bf60

Quindi apparentemente le immagini sono lì, ma non vengono visualizzate. Solo il segnaposto grigio dell’avatar predefinito.

49

Tutto sembra corretto a livello di record del database. Puoi procedere a indagare sui livelli superiori.

Cosa ottieni quando segui manualmente gli URL dei caricamenti che hai elencato?

50

Se inserisco /uploads/default/optimized/3X/6/3/63347a46c0ca945f53613722a73c233484d642c8_2_200x200.jpeg (cioè) dopo l’URL del mio Discourse? Ottengo un 404, non trovato.

Quindi… non esistono? (Chiedo con speranza :stuck_out_tongue: )

51

Controlla anche alcuni URL di file da /uploads/default/original, non solo da /uploads/default/optimized.

404 … Ciò significa che devi verificare la cartella uploads all’interno di /var/discourse/shared/standalone nel filesystem e individuare dove si trovano effettivamente i vecchi file (se esistono). Una volta trovati, prova a confrontare la loro posizione con quella dei file caricati di recente (quelli che funzionano).

Puoi anche ripristinarli manualmente dal backup.

52

Grazie per la spiegazione.

Sono appena andato a controllare e ho verificato che alcuni dei percorsi elencati non esistono.

La parte strana è che ho utenti che cercano di caricare nuovi file, ma anche questi non funzionano. Quando usi i comandi che mi hai dato, vedi un percorso che non esiste. Come fa Discourse a “mappare” questo? Perché una cosa che non riesco a capire è che i file mancano (anche se il backup avrebbe dovuto trasferirli), ma i nuovi caricamenti vanno su percorsi fantasma?

53

Controlla la cartella tombstone all’interno della cartella uploads - ci sono alcuni dei file mancanti lì?

54

L’unica cartella che vedo dentro uploads è default… la cartella tombstone è per i file deprecati o qualcosa del genere?

Inoltre, un’informazione aggiuntiva: risulta che se un utente tenta di caricare la stessa immagine che possiede già (anche se ne cambia il nome del file; presumo, da quanto vedo con quelle query, che si basi sull’hash), l’immagine non verrà caricata e apparirà vuota. Una volta salvato, vedrai il segnaposto grigio.

Apparentemente, se modifichi in qualche modo l’immagine (anche solo salvandola in un formato diverso in Photoshop), puoi ricaricarla.

55

Questo è un comportamento normale. L’hash del file dati viene memorizzato nel database per evitare immagini duplicate.

Cosa succede se carichi un’immagine tramite l’editor di composizione? Il caricamento viene completato? L’immagine appare nel pannello di anteprima?

56

Se scrivo un messaggio e includo un’immagine, verrà visualizzata nel pannello di anteprima e il caricamento verrà completato. Sì, è il comportamento normale.

57

Quindi in quale punto esatto l’immagine smette di essere visualizzata?

Controlla l’URL dell’immagine che vedi e rintracciala nel filesystem.

Controlla l’URL delle immagini che non funzionano (tramite gli strumenti per sviluppatori del browser). Qual è la differenza?

Forse puntano a un dominio diverso..

58

Nel primo messaggio mi riferivo specificamente agli avatar (tramite il profilo dell’utente), il secondo riguarda l’editor.

Quindi, in un messaggio normale, se trascini e rilasci un’immagine o premi il pulsante “carica immagine”, funzionerà senza problemi, come al solito.

In breve:

  • Gli avatar non vengono visualizzati, appare solo il segnaposto.
  • Anche le emoji personalizzate non vengono mostrate.
  • Le immagini del sito (logo, ecc.) non venivano visualizzate.
  • Se carichi immagini dal compositore, funziona correttamente.
  • Se provi a caricare lo stesso avatar che avevi prima dell’incidente, non funzionerà. Il comportamento è il seguente: l’immagine verrà caricata, ma nella casella dove scegli se usare una lettera predefinita, Gravatar o un caricamento, verrà mostrato un quadrato vuoto. Quando confermi la scelta e la pagina si ricarica, vedrai il segnaposto grigio.

Inoltre:

  • Nessuna cartella Tombstone.
  • Le vecchie immagini si trovano in directory (come mostrato dalle query che mi hai fornito) che non esistono.

Lascia che controlli la questione del dominio. A titolo di nota, mentre cercavo informazioni ho provato:

  • Avviare il job CreateMissingAvatars da Sidekiq → Nessun successo.
  • Rigenerare tutti i post (sì, un po’ forzato) → Nessun successo.
  • Basandomi su questo thread, dato che ho usato un dominio diverso (in realtà un sottodominio) per testare il ripristino dal backup mentre il sito principale era offline, pensavo che forse alcuni URL fossero errati, quindi ho eseguito questo comando: discourse remap talk.foo.com talk.bar.com → Nessun successo.
59

@Iceman

Questo è principalmente a titolo informativo, e forse è troppo dettaglio, ma potrebbe aiutarti in qualche piccola misura a ottenere ulteriori informazioni su alcune delle cose interessanti che sperimentiamo nell’esecuzione di tre container contemporaneamente (due applicazioni web e un container dati) (e come ciò influisca anche sugli avatar degli utenti).

È molto interessante (e molto figo, a mio avviso) come funziona il pianificatore di job Redis / Sidekiq quando vengono eseguiti in parallelo, ma solo uno è “attivo sul lato web dell’utente”:

Spero che tu trovi interessante questa breve discussione con un esempio reale. Potrebbe fornire una piccola intuizione sul pianificatore di job di Discourse, l’ottimizzazione delle immagini e gli avatar in base alla nostra configurazione:

Sono un grande sostenitore di come Discourse utilizzi Redis / Sidekiq per pianificare i job in background; e considero questo uno dei punti di forza e dei vantaggi principali dell’architettura software di Discourse.

Nota: Questi concetti si applicano anche, in vari modi sottili, alle diverse fasi del processo di backup e ripristino e ad altri processi (dipendenti dal tempo), quindi è una buona idea comprendere come e perché Sidekiq pianifica i job in background.

60

Grazie per le informazioni @neounix, sono molto utili per comprendere meglio gli “intimi” di Discourse dal punto di vista di “Sto imparando Rails per poter aiutare, ma per Dio, la curva di apprendimento è ripida mentre provo a risolvere problemi sulla tua stessa installazione” :stuck_out_tongue:

Al momento mi sto concentrando su Redis/Sidekiq per capire perché alcuni embed non funzionano, dato che penso che possa essere legato a “Bake”, ma non posso dare per scontato nulla, poiché sto ancora imparando le basi del debug (spero).

Per quanto riguarda il mio problema qui, grazie a @Overgrow sono riuscito a determinare che:

  • In effetti, il processo di Backup ha copiato i file nel backup, ma non li ha ripristinati nell’installazione di Discourse. In base allo stato e/o alle correzioni degli altri tre problemi che ho, potrei dover recuperare un altro backup su un’altra installazione e testare nuovamente il processo di backup, ma potrebbe essere un problema per tutti, non lo so ancora.

  • A causa di ciò, si verificava questo comportamento strano.

  • Alla fine ho aperto il backup e ho inserito i file mancanti nell’installazione. Tutto è stato ripristinato senza la necessità di Rebake.

Tuttavia, gli altri problemi persistono (non riesco a ricostruire il contenitore dei dati, su cui sono completamente all’oscuro, e due problemi che mi stanno facendo concentrare su Sidekiq e sugli eventi, perché potrebbero essere risolti in questo modo: alcuni Onebox (YouTube, in particolare) non funzionano e alcune notifiche relative a “falsi” edit che si verificano in modo ricorsivo su alcuni utenti, anche se non sono stati effettuati edit. Quindi penso che la nuova installazione possa avere problemi con i suoi eventi, sto cercando di capire :man_shrugging: