Grazie per il ringraziamento! Ho segnalato per l’attenzione dei moderatori perché a quel punto non avevo i diritti di modifica, ma ora li ho grazie al post che ho fatto. Ironico come funzionano le cose, vero?
Ma prima di creare un avviso generale al di fuori della sezione MinIO, possiamo confermare che Discourse nel suo complesso non supporta più percorsi non basati su dominio come quelli del seguente post che ha dato inizio alla mia ricerca di modifiche?
Se sappiamo che Discourse nel suo complesso non supporta la modalità percorso (cioè percorsi minio.server.com/BUCKET/foo/bar/...) e supporta invece solo percorsi di dominio (cioè BUCKET.minio.server.com/foo/bar/...), allora possiamo renderlo un avviso globale nel wiki e sarò felice di farlo - tuttavia ho bisogno di sentirlo da qualcuno molto più in alto nella catena rispetto a me (come semplice persona della community) che questo SIA effettivamente il requisito per Discourse. Se lo è, allora potrò inserirlo, altrimenti… beh, allora lo lascerò semplicemente come avviso nei requisiti di MinIO.
MinIO è l’unico clone S3 popolare con un passato di utilizzo dello stile di percorso S3 ora deprecato, quindi non penso che meriti un avviso globale, è sufficiente solo nella sezione MinIO.
Grazie, Falco, l’ho lasciato nei requisiti di MinIO, ma dai anche molta enfasi a quella sezione di avvertenze a causa del thread collegato sopra che fa riferimento al motivo per cui sto di nuovo insistendo.
FALLITO
--------------------
Pups::ExecError: cd /var/www/discourse && sudo -E -u discourse bundle exec rake s3:upload_assets fallito con ritorno #<Process::Status: pid 2064 exit 1>
Posizione del fallimento: /usr/local/lib/ruby/gems/2.7.0/gems/pups-1.1.1/lib/pups/exec_command.rb:117:in `spawn'
exec fallito con i parametri {"cd"=>"$home", "cmd"=>["sudo -E -u discourse bundle exec rake s3:upload_assets"]}
bootstrap fallito con codice di uscita 1
** IMPOSSIBILE EFFETTUARE IL BOOTSTRAP ** si prega di scorrere verso l'alto e cercare messaggi di errore precedenti, potrebbero essercene più di uno.
./discourse-doctor potrebbe aiutare a diagnosticare il problema.
Ciao @Falco. Ha senso? Sto controllando le risposte per assicurarmi che siano state gestite in modo da poter attivare l’opzione di eliminazione dopo 30 giorni su questo argomento.
Ho controllato alcuni degli upload contrassegnati come privati e si trovavano in argomenti normali, quindi non riuscivo a capire perché fossero contrassegnati come sicuri. (Gli upload sicuri non erano impostati?)
Ha senso. Ho aggiornato la parte superiore dell’OP con quelle informazioni. Hai idea del perché i caricamenti locali siano stati contrassegnati come sicuri su un sito che non aveva S3 o caricamenti sicuri abilitati?
Penso che questo problema con il caricamento su Cloudflare R2 possa essere risolto con Upload.where(secure: true).update_all(secure: false). Cercherò di arrivarci prima che questo messaggio venga eliminato (ma ho aggiunto una nota all’OP).
Hmm, non abbiamo caricamenti sicuri. Penso che proverò Cloudflare R2, dato che i loro limiti gratuiti sono piuttosto generosi e hanno un (beta) migratore S3. Immagino che lo scoprirò, ma hai visto se R2 è andato bene alla fine @pfaffman?
Non ricordo più se il problema si è verificato quando ho provato a caricare immagini o quando ne ho appena caricata una nuova. Ripensandoci, supporrei di averlo testato su un sito nuovo di zecca.
Migrare a una piattaforma S3 diversa è piuttosto complicato. Ci sono alcuni argomenti a riguardo, ma se vuoi usare Cloudflare R2, proverei prima su un sito di test; c’è una buona probabilità che non funzioni.
Funziona in un certo senso, ma non è pronto per l’uso in produzione.
Avevo un’installazione di sviluppo locale di Discourse 2.7 più vecchia in giro e funzionava bene, per quanto riguarda i caricamenti di immagini, l’uso della CDN e i backup su un bucket privato quando configurato per Cloudflare R2. Ho aggiornato all’ultima versione 2.9 (come usa il nostro forum) e sembra che fallisca nell’elaborazione di recupero di Jobs::UpdateGravatar, dove utilizza la notazione del bucket in modo errato per Cloudflare, tentando di memorizzare nella cache un’immagine remota di gravatar su R2. Esempio (dove il nome del mio bucket su R2 è ‘uploads’):
Upload Update (0.3ms) UPDATE "uploads" SET "url" = '//uploads.123123redact.r2.cloudflarestorage.com/original/1X/123123example.jpeg', "updated_at" = '2022-12-12 20:44:02.929494', "etag" = '9c02b086b2aa5e2088ed44e1017fa63e' WHERE "uploads"."id" = 3
Quindi, avviavo l’interfaccia utente e gli avatar nella mia configurazione di test/sviluppo locale punteranno a
Quindi, la mia migliore ipotesi è che S3 vada bene con la notazione a punto del bucket e cloudflare R2 no, o forse la cache di gravatar deve utilizzare invece il valore CDN di S3? È un peccato perché sembra abbastanza vicino.
Ho ricevuto una risposta da Cloudflare che per R2, finché non implementeranno correttamente l’ACL dell’oggetto, lo hanno modificato per restituire un 200 se ricevono valori in quella proprietà che non supportano ancora. Questo comportamento modificato su R2 è apparentemente avvenuto verso la fine di novembre. Ovviamente non è l’ideale (è in un bucket pubblico, con l’API che chiede che sia privato) ma significa che per questo problema ora “funziona”.
Oh! Sembra promettente. Penso che potresti aver bisogno di un bucket separato per i caricamenti, anche se sarebbe un bel gioco di indovinelli ottenere il nome di un file di backup.
Utilizzo bucket separati per caricamento e backup, e sembrava funzionare bene, nel senso che il bucket di backup R2 non è impostato su pubblico e Discourse tramite l’interfaccia di amministrazione ha scritto lì un backup compresso senza problemi. L’ho scaricato e ho dato un’occhiata e sembrava sensato (non è la stessa cosa di un ripristino effettivo, ma abbastanza buono per un lunedì). Il mio bucket di caricamenti l’ho testato con un dominio personalizzato per S3_CDN e sembra funzionare bene.
Ad essere sincero, non riesco a capire cosa c’è che non va nella mia versione 2.9 che non renderizza un’interfaccia utente in ember-cli (si blocca dopo aver creato l’utente amministratore), ma probabilmente è qualcosa che vedrai subito sbagliato.
MODIFICA: Oh, sembra che stia cercando di caricare gli asset JavaScript dei plugin da Pseudo-S3/R2, ad esempio molti 404 su cose come assets/locales/en.br.js.
Non ho fortuna con un bundle exec rake s3:upload_assets, quindi questo è il mio miglior indizio attuale.
MODIFICA2: Sì, è correlato agli asset, nel senso che se cancello il mio DISCOURSE_S3_CDN_URL, l’interfaccia utente si carica. Proverò a caricare manualmente gli asset sul posto per ora.
MODIFICA3: Il problema sembra essere semplicemente che l’app necessita che gli asset siano precompilati e dove punta DISCOURSE_S3_CDN_URL, e per un ambiente di sviluppo locale questo non è insolito. Sarà interessante vedere cosa scopre @pfaffman, poiché penso che questo funzionerebbe in un’istanza self-hosted distribuita correttamente con Docker, utilizzando l’hook after_assets_precompile per R2.
Sì. Una CDN per un ambiente di sviluppo locale? Non riesco a immaginare che possa funzionare. Sembra che dovrebbe funzionare per un’implementazione di produzione.
Sì, col senno di poi, non sorprende in una configurazione di sviluppo. Penso che quello che non mi aspettavo fosse che con DISCOURSE_S3_CDN_URL impostato sul CDN di Cloudflare per R2, ma poi DISCOURSE_CDN_URL impostato su vuoto (o locale o ngrok), ma poi volesse comunque utilizzare l’URL di pull di Cloudflare per gli asset precompilati, ecc. e non solo per i caricamenti/immagini. Penso che funzionerà bene in produzione in un container adeguato, quindi potrei fare una prova veloce. Il mio piano sarà qualcosa del tipo rendere i caricamenti multimediali TL4 temporaneamente, cambiare gli ID, ecc. su Cloudflare nell’app.yaml, testarlo e, se va bene, lasciarlo a R2 e poi trasferire tutti gli oggetti S3 esistenti con rclone - dopodiché rifarò il rebake dei post e spero che tutto vada bene .
.