@Falco - Potrebbe essere utile aggiungere un avviso per Scaleway, che supporta solo 1.000 parti per il caricamento multipart, mentre AWS ne supporta 10.000. Questo non è un problema per i caricamenti regolari, ma è un problema per i caricamenti di backup di determinate dimensioni poiché l’SDK S3 utilizzerà 10.000 parti a meno che non venga modificato manualmente e fallirà.
4 Mi Piace
Ottima scoperta! Aggiungila alla wiki dell’OP, se puoi.
4 Mi Piace
Grazie, aggiungo anche che è possibile utilizzare uno qualsiasi di questi strumenti per copiare da cloud a cloud, in particolare da/verso storage di oggetti compatibili con S3, ad esempio Rclone, Shargate, Gs Richcopy360 e GoodSync. tutti questi sono compatibili con cloud simili.
1 Mi Piace
Abbiamo appena scoperto un problema, Cloudflare R2 non consente la lettura pubblica dall’URL dell’endpoint S3, ma solo dal dominio personalizzato o da un dominio casuale r2.dev.
(I download pre-firmati funzionano, semplicemente non è supportato l’accesso pubblico diretto.)
Ma discourse utilizza solo l’URL CDN per le immagini incorporate e non per i download diretti, che utilizzano l’URL dell’endpoint S3.
C’è un modo per farlo utilizzare l’URL CDN per tutti i file, o forzare l’uso di un URL pre-firmato?
Correlato:
La soluzione menzionata in quel post funziona, aggiungere ?dl=1 lo risolve, perché forza discourse a utilizzare un URL S3 pre-firmato.
1 Mi Piace
Corretto in 2023-03-16 ora R2 funziona con Discourse alla perfezione con il piano gratuito
3 Mi Piace
Vedo anche questo con una certa frequenza (ogni diversi mesi) anche se il mio Discourse è in esecuzione su AWS Lightsail e sto caricando su AWS S3. Quindi non sono sicuro che sia colpa di wasabi.
Sarebbe possibile intercettare questo errore e avvisare l’amministratore? Controllo lo spazio su disco e rimuovo i vecchi backup quando aggiorno, ma a volte è troppo tardi e il forum va giù per mancanza di spazio su disco.
1 Mi Piace
Sono abbastanza sicuro che il problema fosse che i riavvii automatici del sistema operativo per gli aggiornamenti di sicurezza avvenivano mentre il backup era in esecuzione. Assicurati di pianificare i riavvii del sistema operativo e i backup in momenti diversi. È stato dopo aver spostato quel sito da wasabi che mi è venuta questa spiegazione, ma sono abbastanza sicuro che fosse così.
2 Mi Piace
uptime dice che è attivo da 300 giorni, quindi non credo che sia quello il problema. Ma in modo simile, avevo pianificato i backup di Discourse alle 2:00 e gli snapshot di Lightsail alle 2:30, quindi forse l’upload a volte non viene completato e lo snapshot lo compromette. Ho separato le due operazioni di un’ora, vedremo se farà la differenza.
Indipendentemente da ciò, penso che sia ragionevole avvisare gli amministratori se l’upload fallisce, per qualsiasi motivo.
2 Mi Piace
Penso che sia ora di fare gli aggiornamenti del kernel e riavviare. 
Potrebbe esaurirsi la RAM?
Dopo aver implementato i backup remoti di Backblaze, vedo questo errore nella mia dashboard:
Il server è configurato per caricare file su S3, ma non è configurato alcun CDN S3. Ciò può comportare costi S3 elevati e prestazioni del sito più lente. Vedere “Utilizzo dello storage di oggetti per i caricamenti” per saperne di più.
Non ho configurato il caricamento di file, ho solo configurato i backup tramite questa configurazione:
DISCOURSE_S3_REGION: "s3.us-west-00X"
DISCOURSE_S3_INSTALL_CORS_RULE: false
DISCOURSE_S3_ENDPOINT: https://s3.us-west-00X.backblazeb2.com
DISCOURSE_S3_ACCESS_KEY_ID: mykeyid
DISCOURSE_S3_SECRET_ACCESS_KEY: myaccesskey
DISCOURSE_S3_BUCKET: community-forum
DISCOURSE_S3_BACKUP_BUCKET: community-forum/backups
DISCOURSE_BACKUP_LOCATION: s3
Ho fatto qualcosa di sbagliato?
Sembra che qualcosa sia mal configurato, ho notato che quando provo a caricare un file in un post, ricevo questo errore:
Valore non supportato per canned acl ‘public-read’
Qualsiasi aiuto sarebbe apprezzato.
2 Mi Piace
Rimuovi questo se non vuoi che i caricamenti vadano su s3.
4 Mi Piace
Hai salvato la giornata, fratello. 
Grazie mille!
2 Mi Piace
Ha funzionato?
1 Mi Piace
È successo una volta nell’ultimo mese da quando ho separato i due processi di un’ora, quindi non l’ha “risolto” e non succede abbastanza spesso da dire se abbia aiutato.
Dal lato positivo, ho notato che c’è una sezione di stato del backup nella pagina di amministrazione che mostra lo spazio su disco disponibile, il che mi evita di aprire costantemente un terminale ed eseguire un df solo per verificare la presenza di backup bloccati. Ho personalizzato il testo per ricordarmi che mi aspetto circa 80 GB liberi.
1 Mi Piace
È una buona idea.
Ho visto l’immagine prima di leggere che avevi personalizzato il testo e mi stavo chiedendo quale logica fosse in gioco per determinare che fosse “buono”!
1 Mi Piace
Non riuscivo a far funzionare questo con Scaleway usando l’immagine Bitnami Discourse.
Le variabili d’ambiente erano impostate ma chiaramente non venivano lette/applicate correttamente (o affatto?).
Quindi ho impostato le variabili S3 nel pannello di amministrazione e ho impostato la regione direttamente nella console Rails (sperando ancora che questo diventi solo un campo di testo):
SiteSetting.s3_region="fr-par"
Mi ha dato un errore di validazione, ma ho semplicemente commentato il controllo di validazione prima di aggiornare l’impostazione, poi l’ho reinserito.
1 Mi Piace
L’immagine Bitnami non è pacchettizzata da noi e non segue le nostre raccomandazioni. Tutto ciò che è documentato qui è stato testato solo rispetto all’installazione ufficiale.
4 Mi Piace
Questo è stato risolto abilitando “s3 use cdn url for all uploads”, un’opzione aggiunta di recente da discourse.
Poiché prima utilizzavamo R2, abbiamo dovuto usare discourse remap per sostituire manualmente i link non funzionanti, abbiamo sincronizzato i file s3 per sicurezza e poi abbiamo ricotto tutti i post.
1 Mi Piace
Sto cercando di configurare questo con idrive e2, che è compatibile con s3. Tuttavia, sto ricevendo un errore/stack trace non molto utile alla fine di ./launcher rebuild app:
I, [2023-10-14T15:08:08.026184 #1] INFO -- : cd /var/www/discourse & sudo -E -u discourse bundle exec rake s3:upload_assets
rake aborted!
Aws::S3::Errors::InternalError: We encountered an internal error, please try again.
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/seahorse/client/plugins/raise_response_errors.rb:17:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-s3-1.114.0/lib/aws-sdk-s3/plugins/sse_cpk.rb:24:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-s3-1.114.0/lib/aws-sdk-s3/plugins/dualstack.rb:27:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-s3-1.114.0/lib/aws-sdk-s3/plugins/accelerate.rb:56:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/aws-sdk-core/plugins/checksum_algorithm.rb:111:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/aws-sdk-core/plugins/jsonvalue_converter.rb:22:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/aws-sdk-core/plugins/idempotency_token.rb:19:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/aws-sdk-core/plugins/param_converter.rb:26:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/seahorse/client/plugins/request_callback.rb:71:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/aws-sdk-core/plugins/response_paging.rb:12:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/seahorse/client/plugins/response_target.rb:24:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/seahorse/client/request.rb:72:in `send_request'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-s3-1.114.0/lib/aws-sdk-s3/client.rb:12369:in `put_object'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-s3-1.114.0/lib/aws-sdk-s3/object.rb:1472:in `put'
/var/www/discourse/lib/s3_helper.rb:78:in `upload'
/var/www/discourse/lib/tasks/s3.rake:41:in `block in upload'
/var/www/discourse/lib/tasks/s3.rake:41:in `open'
/var/www/discourse/lib/tasks/s3.rake:41:in `upload'
/var/www/discourse/lib/tasks/s3.rake:197:in `block (2 levels) in <main>'
/var/www/discourse/lib/tasks/s3.rake:197:in `each'
/var/www/discourse/lib/tasks/s3.rake:197:in `block in <main>'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/rake-13.0.6/exe/rake:27:in `<top (required)>'
/usr/local/bin/bundle:25:in `load'
/usr/local/bin/bundle:25:in `<main>'
Tasks: TOP => s3:upload_assets
(See full trace by running task with --trace)
I, [2023-10-14T15:08:16.413098 #1] INFO -- : Installing CORS rules...
skipping
Uploading: assets/admin-2ebebf57104b0beb47a1c82fe5a8c6decd07f60a706640345fed296a094d1536.js
Questa è la configurazione che ho usato, ma ho anche provato con DISCOURSE_S3_CONFIGURE_TOMBSTONE_POLICY e DISCOURSE_S3_HTTP_CONTINUE_TIMEOUT
DISCOURSE_USE_S3: true
DISCOURSE_S3_REGION: Dallas
DISCOURSE_S3_ENDPOINT: https://y0o9.tx21.idrivee2-4.com
DISCOURSE_S3_ACCESS_KEY_ID: <snip>
DISCOURSE_S3_SECRET_ACCESS_KEY: <snip>
DISCOURSE_S3_BUCKET: discourse
DISCOURSE_S3_INSTALL_CORS_RULE: false
Nota che non lo sto usando per i backup (quello è già configurato nell’interfaccia utente con backblaze) né per DISCOURSE_CDN_URL perché non sono sicuro che idrive supporti quest’ultima - avevo in programma di sperimentare con quella una volta che avessi messo alcuni file effettivi nel bucket.
1 Mi Piace
Sembra che non sia abbastanza compatibile con S3 per le esigenze di Discourse.
Se vuoi approfondire, il prossimo passo sarebbe riprodurre questo in un’installazione di sviluppo e ottenere la chiamata API esatta che fallisce.
2 Mi Piace