I maintainer di AWS SDK hanno interrotto la compatibilità. Spetta al tuo provider di cloni S3 mettersi al passo e implementare una migliore compatibilità in modo da poter rimuovere le soluzioni alternative.
4 Mi Piace
Per chiarire, questo riguarda solo i file JS/map/CSS in assets, e non influenzerà gli upload, giusto?
Intendo, influenzerà la pulizia dei file orfani?
A proposito, suppongo che questo problema potrebbe influenzare l’aggiornamento di Discourse dal pannello di amministrazione?
In realtà, l’aggiornamento tramite il pannello di amministrazione è fallito per me, motivo per cui ho eseguito una ricostruzione.
Sì, è solo per gli assets.
Questo rake task? No.
Ma l’intero cambiamento dell’SDK AWS potrebbe averlo anche rotto per le persone con cloni non compatibili.
1 Mi Piace
Sono abbastanza sicuro che sia sbagliato. Quindi probabilmente dovremo disattivare anche clean up uploads. Questo causerà solo errori quando esegui, però. Non ti impedirà di ricostruire.
Sembra probabile. Forse abbiamo bisogno di un’impostazione “skip_s3_delete” per risolvere questo problema finché gli altri provider non si aggiorneranno? E forse impostarla automaticamente per i provider che sappiamo essere rotti?
Quel rake task è l’unico modo in cui vengono rimossi gli asset scaduti?
Mi stavo chiedendo, perché non aggiungere un’opzione per mantenere gli asset sul server principale di Discourse (intendo, senza memorizzarli su S3)?
Finché non influisce sui caricamenti o sul processo di pulizia dei file orfani, sembra una soluzione praticabile.
Sì. Non è che sia un grosso problema. I siti normali che si aggiornano di tanto in tanto non vedranno molta differenza.
Le persone possono impostare le proprie regole del ciclo di vita se tengono a queste cose.
Non è già quello che fa l’impostazione clean up uploads = false?
Lol no. Discourse supporta ufficialmente S3. Mentre mi sono fatto in quattro iniziando l’intera wiki Configura un provider di object storage compatibile con S3 per i caricamenti e aggiungendo alcuni toggle per aumentare la compatibilità con i cloni, non abbiamo alcun piano di investire più tempo in questo oggi.
Se la community vuole inviare un paio di PR che aumentano la compatibilità e sono disattivati per impostazione predefinita, sono pr-welcome, ma non aspettatevi di vedere un supporto ufficiale nel core per ogni clone a breve.
4 Mi Piace
Per quanto ne so, sembra che Digital Ocean non abbia problemi a eliminare i backup né a invalidare gli asset mancanti.
Per i provider che sono in errore, ci vorrebbe molto tempo prima che gli asset non necessari causassero molti problemi. Mantenere un sacco di backup, inclusi enormi database e tutti i caricamenti, potrebbe essere un bel problema se si paga per lo storage.
1 Mi Piace
Ciao, sono Pat Patterson, Chief Technical Evangelist di Backblaze; sono arrivato su questo thread perché ho un forum Discourse self-hosted proof-of-concept e mi sono imbattuto esattamente in questo problema oggi mentre configuravo il mio forum per utilizzare Backblaze B2 per backup e caricamenti.
Impostare AWS_REQUEST_CHECKSUM_CALCULATION e AWS_RESPONSE_CHECKSUM_CALCULATION su WHEN_REQUIRED è una soluzione utile per casi base di caricamento e download di file, ma è utile sapere che non copre una serie di scenari, tra cui:
- Eliminazione di file: Discourse utilizza l’operazione S3
DeleteObjectsper eliminare più file in un’unica chiamata API, come dovrebbe. - Caricamento di file in bucket con object lock abilitato.
Il problema è che un checksum (o l’header Content-MD5 o uno dei nuovi header checksum) è richiesto (piuttosto che solo supportato) per queste operazioni, e questo fa sì che gli attuali SDK AWS forniscano il nuovo header checksum. Per quanto ne so, non c’è modo di sovrascrivere questo e far sì che l’SDK fornisca Content-MD5 come faceva in precedenza.
I nostri ingegneri stanno lavorando per risolvere tutto questo; nel frattempo, la migliore mitigazione è utilizzare la versione 1.177.0 o precedente della gemma aws-sdk-s3.
Ho provato a eseguire il downgrade delle versioni della gemma AWS SDK nel mio PoC modificando il Gemfile e sostituendo
gem "aws-sdk-s3", require: false
gem "aws-sdk-sns", require: false
con
gem "aws-sdk-core", "~> 3.215.1", require: false
gem "aws-sdk-kms", "~> 1.96.0", require: false
gem "aws-sdk-s3", "~> 1.177.0", require: false
gem "aws-sdk-sns", "~> 1.92.0", require: false
ma il mio bundle-fu non è forte e sono riuscito solo a rompere il mio deployment con l’errore:
/var/www/discourse/config/initializers/100-sidekiq.rb:69:in `<main>': undefined method `logger=' for module Sidekiq (NoMethodError)
Sidekiq.logger = Logger.new(nil)
^^^^^^^^^
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-7.2.2.1/lib/rails/engine.rb:689:in `load'
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-7.2.2.1/lib/rails/engine.rb:689:in `block in load_config_initializer'
...
Suppongo di aver perso qualche passaggio fondamentale.
Senza voler gettare ombra sui nostri amici di DO, lo hanno fatto aggiornando il loro servizio per ignorare semplicemente i nuovi header checksum piuttosto che rifiutare la chiamata API a causa del checksum non supportato.
Il loro rapporto sull’incidente dice:
Si noti che Spaces attualmente non verifica i checksum di integrità dei dati inviati dalla AWS CLI e dagli SDK AWS come parte delle richieste di caricamento
Abbiamo deciso che accettare e archiviare semplicemente dati che potrebbero non corrispondere al checksum fornito dal client API era una cosa negativa.
9 Mi Piace
grazie per aver pubblicato!
2 Mi Piace
Sì, e i manutentori dell’SDK AWS ci stanno solo dando il benservito su questo
2 Mi Piace
Sono lieto di vedere che anche il team B2 ha notato questo problema.
Ecco la mia soluzione temporanea:
Ho commentato tutte le configurazioni relative a S3 in app.yml e ricostruito Discourse con successo. Ciò non influisce sull’accesso ai file precedentemente caricati sul mio sito e tutti gli allegati caricati durante questo periodo verranno archiviati localmente senza causare problemi.
A proposito, mi chiedo ancora perché non aggiungere un’opzione per mantenere gli asset sul server principale di Discourse (intendo, senza archiviarli su S3)?
???
È così che Discourse funziona “out of the box”, è necessario scegliere esplicitamente di inviare gli asset a un servizio di object storage.
Voglio dire, potrebbe essere utile avere un’opzione per mantenere le risorse principali di Discourse (JS, CSS, ecc.) sul server locale. Allo stesso tempo, solo i file caricati dall’utente verrebbero archiviati in S3.
1 Mi Piace
Puoi farlo non abilitando “use_s3”, ma sono piccole, le caricherei e non mi preoccuperei dello spazio sprecato.
1 Mi Piace
Per favore, aiutami a capire correttamente.
Intendi impostare DISCOURSE_USE_S3: false in app.yml?
Vorrei farlo perché il mio server Discourse si trova in Asia e B2 ha server solo negli Stati Uniti.
Inoltre, questa volta, il problema dell’SDK AWS è correlato alla gestione degli asset, giusto?
Quindi, se memorizzo gli asset sul server locale, potrei evitare il problema (se ho capito bene la situazione).
Il problema è correlato alla rimozione di asset da S3. Se rimuovi solo la riga che tenta di rimuovere gli asset inutilizzati, funzionerà subito. E sembra che presto il problema sarà risolto. Questa è la soluzione più semplice. È quello che consiglio. Questa è la mia migliore risposta gratuita.
1 Mi Piace
Grazie, è molto utile per me!
1 Mi Piace
Questo accade perché, nella definizione dell’API S3, l’operazione DeleteObjects ha httpChecksum.requestChecksumRequired impostato su true, a differenza, ad esempio, di PutObject, che lo imposta su false. Quindi l’SDK sta rispettando WHEN_REQUIRED, perché il checksum è richiesto.
Tutti gli SDK AWS sono ora generati dalla definizione dell’API, con un codice aggiuntivo minimo per coprire situazioni limite. Il codice vede che DeleteObjects richiede un checksum e il modo per farlo ora è utilizzare uno dei nuovi checksum, piuttosto che Content-MD5.
Sfortunatamente, AWS non ha ritenuto opportuno fornire una configurazione del tipo “usa Content-MD5 come facevi prima”. Tendono a non considerare l’ecosistema di storage di oggetti di terze parti quando apportano questo tipo di modifiche, poiché non ne hanno davvero bisogno. L’unica volta che cose del genere vengono risolte è quando finiscono per danneggiare accidentalmente uno dei propri servizi in qualche caso limite.
3 Mi Piace
Non che aiuti particolarmente se ti trovi in Asia, ma, per la cronaca, abbiamo anche data center in Europa (Amsterdam, Paesi Bassi) e, dall’inizio di quest’anno, in Canada (Toronto).
Non posso fare promesse, ma stiamo sicuramente prendendo in considerazione una sede in Asia.
Inoltre, se utilizzi una CDN, non ha molta importanza dove si trova il server di origine.
3 Mi Piace
Hai ragione!
Backblaze non supporta x-amz-checksum-crc32 e la versione più recente dell’SDK AWS di Discourse potrebbe averlo abilitato per impostazione predefinita.
Quindi sono entrato nell’app:
./launcher enter app
e ho disinstallato la versione corrente dell’SDK AWS:
gem uninstall aws-sdk-s3 aws-sdk-core aws-sdk-kms
e ho installato quella che il ragazzo di Backblaze ha detto che avrebbe funzionato:
gem install aws-sdk-core -v “~> 3.215.1”
gem install aws-sdk-kms -v “~> 1.96.0”
gem install aws-sdk-s3 -v “~> 1.177.0”
Poi ho ricostruito l’app e ha funzionato!
2 Mi Piace