Migrazione da hosted a self-hosted: gli upload passati fanno ancora riferimento a discourse infra

Supporto
1

Controllato: Images lost when migrating to self-hosting, posts:rebake non fa nulla di buono.

Problema
Abbiamo seguito le istruzioni ufficiali e creato un’istanza Lightsail, da lì abbiamo scaricato un database dall’interfaccia utente di Discourse e lo abbiamo applicato ottenendo l’80% del risultato. L’idea era di passare all’istanza self-hosted mantenendo attiva la versione precedente.

Una volta che abbiamo una copia live del vecchio forum. Iniziamo a migrare le immagini. Per farlo, prima annulliamo il nostro abbonamento per ottenere e migrare le nostre immagini.

Poiché nuove immagini verrebbero caricate sull’istanza self-hosted, dovremmo solo caricare dall’istanza ospitata prima della data di transizione. Ciò significa che non abbiamo mai utilizzato il dump del database fornito con le nostre immagini e la cancellazione; poiché avevamo già effettuato la migrazione, era ormai scaduto.

Osservo tre comportamenti relativi a questo punto nel tempo.

  1. Le risorse referenziate nel backup (dump SQL, in particolare) puntano all’infrastruttura di Discourse
  2. Le risorse referenziate * create successivamente sul backup, ad esempio le immagini dei nuovi post, sono correttamente referenziate e trovate sulla nostra infrastruttura

Di conseguenza, se ricarico una risorsa che ha lo stesso hash, si collegherà all’infrastruttura di Discourse. Ad esempio: provare a correggere la favicon caricandola non funziona. Posso tuttavia caricare qualsiasi altra immagine casuale, e funzionerà.

Stato attuale
Per quanto ne so, upload://<X> passa attraverso la decodifica b62 (e sha1?) per mapparla nella cartella public/uploads. Abbiamo ognuna di queste immagini:

Il dump che ci è stato fornito dal team di Discourse contiene uno zip con default/original/1X e attualmente può essere visto in /var/www/discourse/public/uploads/default/original/1X. Quest’ultima cartella ora contiene 329 elementi, il dump fornito conteneva 249 elementi - questo mi sembra buono.

Ciò significa che i dati dovrebbero essere individuabili, anche se non riesco a trovare direttamente l’upload nella cartella. Sto cercando di capire questa relazione, in modo da poter in qualche modo correggere la mappatura. Inizialmente sembrava solo una semplice sostituzione di stringhe, e questo ha funzionato per alcune immagini. Alcune sono ora state sostituite da un transparent.png, dove prima c’era solo un’immagine inaccessibile.

4

Se il rebake non è riuscito, dovresti provare un remap per cercare/sostituire tutti i riferimenti all’infrastruttura di Discourse e sostituirli con collegamenti relativi.

5

Grazie Richard!

Per chiarire, con: Replace a string in all posts

Utilizzando

rake posts:remap["trova","sostituisci","stringa",vero]

Fai

rake posts:remap[
  "https://cdck-file-uploads-europe1.s3.dualstack.eu-west-1.amazonaws.com/standard21/uploads/everviz/",
  "/uploads/default/"
]

L’alternativa al sostitutore relativo sarebbe "https://forum.everviz.com/uploads/default/"

Il link relativo è quello a cui stai pensando?

e: correzione dell’url relativo con /

Riga singola:

rake posts:remap["https://cdck-file-uploads-europe1.s3.dualstack.eu-west-1.amazonaws.com/standard21/uploads/everviz/", "/uploads/default/"]
6

sembra buono a me! dovrai aggiungere una barra davanti
/uploads/default/

7

Hai controllato includi tutti i caricamenti durante il backup del tuo sito ospitato? Se eri ospitato con CDCK, c’era un’impostazione nascosta che dovevano abilitare prima che tu potessi eseguire un backup con tutti i caricamenti inclusi. Non sono sicuro se sia cambiato ora, ma sicuramente vorrai coordinarti con il tuo provider di hosting prima di procedere per assicurarti di eseguire un backup completo (e non solo un dump di SQL).

8

Il mio provider di hosting era Discourse, avevamo un piano mensile. L’interfaccia utente ospitata dice di contattare team@discourse.com per ottenere i file caricati. La loro risposta è stata che devo annullare l’abbonamento per ottenere i file.

Ma sì, come menzionato ho ricevuto uploads/original/1X

9

È un buon suggerimento, ma potrei averlo già fatto:

root@...:/var/www/discourse$ rake posts:remap["//cdck-file-uploads-europe1.s3.dualstack.eu-west-1.amazonaws.com/standard21/uploads/everviz/","/uploads/default/"]
Sei sicuro di voler sostituire tutte le occorrenze della stringa "//cdck-file-uploads-europe1.s3.dualstack.eu-west-1.amazonaws.com/standard21/uploads/everviz/" con "/uploads/default/"? (S/n)
S
Rimappatura
0 post rimappati!

I link erano https://europe1.discourse-cdn.com/standard21/uploads/everviz/ nel forum ospitato. Ovviamente è la stessa cosa, solo che passa attraverso il CDN. Proviamo a rimappare.

1 post rimappato.

Trovo questa immagine curiosa:

image
image2272×1242 357 KB

Naturalmente, questo era prima di eseguire tutti questi comandi oggi e prima di pubblicare qui. È stato inviato al team di Discourse prima che eseguissi alcuni rake tasks e altro.

10

Hai fatto così? Devono attivare un’impostazione nascosta che scaricherà le immagini da S3 e le includerà nel tuo backup. Un backup normale non include le immagini ma solo i link ad esse nei loro bucket S3. Annullare un abbonamento attiva automaticamente questa funzione, credo, ma ho avuto clienti che hanno ottenuto l’attivazione della funzione semplicemente chiedendola. Dovresti annullare il tuo abbonamento o chiedere di nuovo.

Se non vuoi farlo in quel modo, dovrai scrivere uno script che scaricherà le immagini da S3 e aggiornerà di conseguenza il database di Discourse.

11

Ho annullato e ho ricevuto i file. Sebbene sembri che il backup originale del database di discourse faccia riferimento al percorso in S3. Essenzialmente, ho tutto ciò di cui ho bisogno in /var/www/discourse/uploads/original/1X.

Ho utilizzato uno dump SQL scaricato manualmente per popolare l’istanza, non quello fornito con i file. Ero preoccupato che quest’ultimo potesse fornire percorsi corretti alle immagini, cosa che ora ho verificato non essere vera.

Per dimostrare:


![](upload://3Qa5S9sUTcc42dT4EFAbz5K0iJP.gif) = 1aec065017da50538fe5866ae91a6396185234e1.gif

https://forum.everviz.com/uploads/default/original/1X/1aec065017da50538fe5866ae91a6396185234e1.gif

http://cdck-file-uploads-europe1.s3.dualstack.eu-west-1.amazonaws.com/standard21/uploads/everviz/original/1X/1aec065017da50538fe5866ae91a6396185234e1.gif

<img src="https://forum.everviz.com/images/transparent.png" alt="" data-orig-src="upload://3Qa5S9sUTcc42dT4EFAbz5K0iJP.gif" role="presentation" width="1" height="1" style="aspect-ratio: 1 / 1;" loading="lazy">

Quanto sopra è un caso speciale in cui il riferimento precedente a cdck… è solo un’immagine trasparente.png. Indipendentemente da ciò, puoi aprire il link e vedere che esiste.

12

Quindi mi aspetterei di avere problemi.

In quella che presumo sia una discussione raw che hai incluso, con il database incluso nei file, mi aspetterei che il ![](upload://3Qa5S9sUTcc42dT4EFAbz5K0iJP.gif) si riferisca al tuo storage locale, ma se qualcuno avesse incollato esplicitamente un link a un’immagine nel proprio bucket, sarebbe stato necessario fare qualcosa per risolvere il problema. Se l’immagine esisteva e avevi l’impostazione download-su-locale attiva, l’immagine dal bucket sarebbe stata scaricata (dato che soddisfaceva i criteri di impostazione).

Non sono del tutto sicuro di come sia stata generata l’ultima \u003cimg nel tuo esempio.

13

Il download in locale è abilitato.

Per il file collegato, il dump “ufficiale” di addio non include percorsi relativi.

<img src="https://europe1.discourse-cdn.com/standard21/uploads/everviz/original/1X/1aec065017da50538fe5866ae91a6396185234e1.gif" alt="" data-base62-sha1="3Qa5S9sUTcc42dT4EFAbz5K0iJP" ...

Questo riferimento esatto al file punta anche a cdck… in alcuni punti.

Mi sembra un po’ folle, ma potrei fare un backup ora. E poi scartare i riferimenti all’infrastruttura Discourse per il percorso locale nel dumpfile stesso, e ricaricarlo.

L’ultimo file potrebbe fare riferimento a transparent.png perché ho ricotto il post, e il file sorgente non era più individuabile nell’infrastruttura Discourse. Non credo che si tratti di una perdita completa di dati.

14

Se il tuo sito è attivo, allora dovresti semplicemente entrare e correggere le cose in Rails, nella misura in cui è possibile.

Ma quell’<img è un post elaborato, giusto? Non il post grezzo?

15

L’\u003cimg proviene dal dump del database. Presumo sia cotto. Il post cotto fa riferimento a b62 come upload://

L’attuale cotto è:

\u003cimg src="https://forum.everviz.com/images/transparent.png" alt="" data-orig-src="upload://3Qa5S9sUTcc42dT4EFAbz5K0iJP.gif" ...

Finora non ho avuto molto successo con rake per trovare e correggere upload mancanti, rimappare e ricuocere post.

Grazie Jay per tutto il tuo aiuto!

16

Il file a cui si fa riferimento nel post cotto funziona. Non c’è nessun problema.

Se stai cercando nei post cotti nello scarico del database, allora stai cercando nel posto sbagliato.

Ora hai un sito live, quindi devi lavorarci sopra.

Cosa vedi nel post raw? Dopo un ribake di quel post, cosa mostra il post cotto che non è quello che ti aspetti?

Senza sapere esattamente cosa hai fatto e cosa c’è nei post (raw e cotti), non c’è molto modo di aiutare. Dato che hai iniziato con un database che ci si aspetta non contenga i dati giusti, questo argomento non sarà utile ad altri.

17

Ho fatto quello che tutti mi avevano detto di non fare: armeggiare con il database e il suo dumpfile. Attualmente, quasi tutto funziona, tranne alcuni casi di:

<img src="https://forum.everviz.com/images/transparent.png"
alt="image" data-orig-src="upload://npqpp5O0wbL89nR9OXtP7Btu4hc.png"
width="517" height="90" style="aspect-ratio: 517 / 90;" loading="lazy">

Calcoliamo il b62 e prendiamo il suo esadecimale

npqpp5O0wbL89nR9OXtP7Btu4hc = 0x a411c90267cafca7a1cbcd7c8f4f9b8db17e51ba

Ora prova a trovarlo da /var/www/discourse/public/uploads:

find . -name '*a411c90267cafca7a1cbcd7c8f4f9b8db17e51ba*'
./default/original/1X/a411c90267cafca7a1cbcd7c8f4f9b8db17e51ba.png

Sì!

932×164 18.5 KB

Ma perché nel post è transparent.png? Ho eseguito rake uploads:recover_from_tombstone e rake posts:rebake

Come sono arrivato qui?

La colonna uploads nel database, per la tabella url, mostrava ancora cdck come parte dell’URL di origine per le immagini. Sono entrato nel database dall’interno del container:

postgres psql discourse

Poi

UPDATE uploads
SET url = REPLACE(
           url,
           '//cdck-file-uploads-europe1.s3.dualstack.eu-west-1.amazonaws.com/standard21/uploads/everviz/',
           '/uploads/default/'
         )
WHERE url LIKE '//cdck-file-uploads-europe1.s3.dualstack.eu-west-1.amazonaws.com/standard21/uploads/everviz/%';

Questo ha mostrato risultati promettenti, dove la maggior parte delle immagini originali e delle miniature riapparirebbe.

Un passo avanti: modifica dei dumpfile
L’ipotesi è che Discourse sia stateless* e l’unica cosa di cui dobbiamo preoccuparci è ciò che è contenuto nel database. Non ero ansioso di armeggiare con rake tasks o ruby per questo, poiché non ho molta familiarità né con questi né con gli interni di Discourse. Voglio solo risultati, velocemente.

*manca la cartella public che contiene le nostre immagini. Possiamo comunque confermare che abbiamo tutto il necessario.

Quindi scarichiamo una copia del database dall’interfaccia utente, quindi la apriamo in VSCode e sostituiamo progressivamente i riferimenti a cdck (bucket) e europe1 (bucket da CDN)

Con progressivo intendo che in alcuni casi vedresti ‘//…’ e in altri casi vedresti ‘https://’. Pertanto, devi prima trovare e sostituire ‘//…’, altrimenti avrai https: finali in tutto il file.

Quindi ricarica il dumpfile modificato. Parte di ciò che ha reso tutto questo complicato è il passaggio base62, che rende un po’ più difficile passare da una rappresentazione grezza all’URL effettivo dell’immagine.

18

Attività completata

Dopo aver ricontrollato le dimensioni della tabella uploads, ho notato che mancavano alcune centinaia di voci. Non so da quale passaggio siano scomparse. Ho unito il backup del database passato con un join SQL di base da una tabella temporanea.

Come ho potuto fare riferimento sopra, l’URL richiesto per un’immagine è quello memorizzato nella tabella uploads, colonna url. Dalla console di Rails ho rimappato questi riferimenti CDN al nostro dominio locale con SQL sulla tabella uploads.

Perché non usare il rake task

Probabilmente ce ne sono alcuni che vanno bene e una loro combinazione funzionerebbe. Tuttavia, quando puoi osservare il comportamento attuale, sai cosa vuoi e sai come arrivarci, allora trovo la limitazione arbitraria.

Voglio ringraziare il team di Discourse e i volontari qui che mi hanno fornito tutti i pezzi di informazione necessari per scoprire la soluzione, che alla fine è consistita in alcuni passaggi.

1 Mi Piace
19

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