Se hai ricostruito l’app, le modifiche apportate nel container sono andate perse. Forse i ragazzi di Backblaze hanno risolto i problemi mentre lo stavi facendo.
1 Mi Piace
Ho appena commentato S3 e ricostruito. Suppongo che d’ora in poi mi atterrò allo storage locale.
1 Mi Piace
La memoria locale funziona bene. È solo la cancellazione che non funziona.
Grazie per aver pubblicato e confermato che non esiste una soluzione alternativa attuale senza eseguire il downgrade degli SDK AWS. Ho riscontrato problemi con le API S3 b2 da un altro progetto che utilizza l’SDK AWS golang, tentando di eseguire il backup di un database VictoriaMetrics.
Hai qualche indicazione dal tuo team di ingegneria su come o quando potrebbero scegliere di risolvere questo problema, o hai un modo per monitorare/ricevere aggiornamenti su una soluzione alternativa supportata? Sto cercando di decidere se dovrei eseguire il fork e ricompilare un progetto con una modifica delle dipendenze o semplicemente aspettare un po’ per un aggiornamento!
Grazie!
La seguente procedura ha funzionato per me per downgradare le AWS Gems:
# Per entrare nel container:
./launcher enter app
# Apparentemente necessario per sbloccare unfreeze di Gemfile.lock:
bundle config set frozen false
# Imposta una versione più vecchia del gem sdk-s3:
sed -i 's/gem "aws-sdk-s3", require: false/gem "aws-sdk-s3", "1.177.0", require: false/' Gemfile
# Downgrade del gem S3 per corrispondere a quello ora nel Gemfile:
bundle update aws-sdk-s3
# Anche downgrade del gem aws-sdk-core:
bundle add aws-sdk-core --version 3.215.
Dopo aver apportato queste modifiche, sono riuscito a salvare con successo un backup su B2. Sono sicuro che questa sia solo una soluzione temporanea che verrà persa con il prossimo aggiornamento di Discourse, quindi spero che @PatPatterson e il team Backblaze possano presto fornire una correzione di compatibilità più permanente.
2 Mi Piace
Speriamo non dovrai farlo, ma è possibile inserire quel comando sed in app.yml in modo che venga eseguito automaticamente al momento della ricompilazione. Penso che basterebbe inserirlo sotto dove vengono clonati i plugin. Ma potrebbe essere più complicato di quanto pensi.
1 Mi Piace
Ciao AntiMetaman,
Ho passato l’ultima settimana a cercare di far funzionare i backup con lo storage S3 e finalmente sono riuscito a far funzionare il backup con questo thread. Onestamente, non sono sicuro di quale parte abbia funzionato.
Ho seguito quello che hai fatto con la disinstallazione e l’installazione delle gemme, ma ora ricevo un errore durante il caricamento delle immagini. Il mio log degli errori mostra questo:
not entitled /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.219.0/lib/seahorse/client/plugins/raise_response_errors.rb:17:in `call’ /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aw
Prima di dover cestinare il mio intero server e ricominciare (onestamente, a questo punto non sono nemmeno sicuro di voler continuare), sai come posso annullare la disinstallazione e l’installazione delle gemme in modo da poter provare a vedere se questo risolve il problema?
Il comportamento che ho osservato sulla nostra istanza (che utilizza Backblaze per il backup) è che i backup hanno iniziato a fallire, senza alcuna notifica, a febbraio. Sono capitato a notarlo oggi, poiché controllo i nostri backup di tanto in tanto. Considererei questo un problema piuttosto serio.
Sarebbe possibile effettuare un downgrade di AWS-SDK fino a quando non si troverà una soluzione temporanea per Backblaze e altri provider non-AWS?
Ma l’ho fatto per un sito che utilizza Backblaze. Ho creato un template che ho inserito in /root/aws-revert-template.yml con questo:
# Questo template ripristina aws-sdk-s3 a una versione che funziona con backblaze
params:
home: /var/www/discourse
hooks:
after_bundle_exec:
- exec:
cd: $home
cmd:
- bundle config set frozen false
- "sed -i 's/gem \\\"aws-sdk-s3\\\", require: false/gem \\\"aws-sdk-s3\\\", \\\"1.177.0\\\", require: false/' Gemfile"
- bundle update aws-sdk-s3
- bundle add aws-sdk-core --version 3.215
E poi l’ho aggiunto al mio app.yml in questo modo:
# IMPORTANTE: IMPOSTA UNA PASSWORD SEGRETA in Postgres per l'utente Discourse
# TODO: cambia SOME_SECRET in questo template
templates:
- "templates/web.template.yml"
- "templates/web.ratelimited.template.yml"
## Decommenta queste due righe se desideri aggiungere Lets Encrypt (https)
- "templates/web.ssl.template.yml"
- "templates/web.letsencrypt.ssl.template.yml"
- "/root/aws-revert-template.yml"
E ho eseguito un aggiornamento a stable e sembra funzionare.
Potresti anche aggiungere semplicemente ciò che è nel template al tuo app.yml
3 Mi Piace
Ho notato che questa pagina - S3-Compatible API - non elenca più gli header checksum-* come non supportati.
@PatPatterson non sono sicuro se sei ancora in questo thread o meno - ma è stato aggiunto il supporto ufficiale per quelli?
2 Mi Piace
Puoi confermare che il tuo backblaze b2 funziona senza la correzione che suggerisco?
Grazie per la rapida risposta e mi scusi, avrei dovuto aggiungere maggiori dettagli. In un altro pacchetto open source (Mastodon) abbiamo anche bloccato la gemma aws-sdk-core a < 3.216.0 per gestire esattamente questo problema per le persone che utilizzano Backblaze (e sospetto altri, ma è lì che è emerso).
Ma poi, nelle ultime settimane, ho notato:
- Quella pagina sul sito di Backblaze non elenca più tali intestazioni come non supportate
- Una recente versione della gemma
awsmenziona la correzione del problema per cuiwhen_requirednon veniva pienamente rispettato in precedenza
Nella ricerca precedente avevo visto questo thread con più o meno lo stesso problema e stavo cercando di capire se ora possiamo aggiornare in sicurezza la gemma se Backblaze ha aggiunto quel supporto, e/o se la gemma ora aggira completamente il problema.
2 Mi Piace
Ciao, sì, Backblaze B2 ha aggiunto il supporto ufficiale per gli header checksum all’inizio di quest’anno.
2 Mi Piace
Eccellente! Grazie per la conferma.