앱을 다시 빌드했다면 컨테이너에서 했던 변경 사항은 사라졌을 것입니다. 아마도 그 사이에 Backblaze 측에서 문제를 해결했을 수도 있습니다.
S3 주석을 달고 다시 빌드했습니다. 이제 로컬 스토리지만 사용하겠습니다.
로컬 스토리지 저장은 정상적으로 작동합니다. 삭제만 제대로 작동하지 않는 거예요.
현재 aws SDK를 다운그레이드하지 않는 한 우회 방법이 없음을 게시하고 확인해 주셔서 감사합니다. 저는 다른 프로젝트에서 golang aws sdk를 사용하여 b2 s3 api를 다루는 중 VictoriaMetrics 데이터베이스를 백업하려고 시도하면서 비슷한 문제를 겪었습니다.
엔지니어링 팀에서 이 문제를 어떻게 또는 언제 해결할지, 또는 지원되는 우회 방법에 대한 업데이트를 추적하거나 받을 수 있는 방법이 있는지 감이 잡히시나요? 저는 의존성 변경 사항을 포함하여 프로젝트를 포크하고 다시 컴파일해야 할지, 아니면 업데이트를 조금 기다려야 할지 결정하려 하고 있습니다!
감사합니다!
다음 절차로 AWS Gems를 다운그레이드하는 데 성공했습니다:
# 컨테이너에 진입하려면:
./launcher enter app
# Gemfile.lock을 언프리즈(unfreeze)해야 하는 것 같습니다:
bundle config set frozen false
# sdk-s3 gem의 이전 버전을 설정합니다:
sed -i 's/gem "aws-sdk-s3", require: false/gem "aws-sdk-s3", "1.177.0", require: false/' Gemfile
# Gemfile에 현재 설정된 것과 일치하도록 S3 gem을 다운그레이드합니다:
bundle update aws-sdk-s3
# aws-sdk-core gem도 다운그레이드합니다:
bundle add aws-sdk-core --version 3.215.
이 변경 사항을 적용한 후 B2에 백업을 성공적으로 저장할 수 있었습니다. 이것이 다음 Discourse 업데이트 시 사라질 임시적인 우회 조치임이 분명하므로, @PatPatterson님과 Backblaze 팀이 보다 영구적인 호환성 수정을 조속히 제공해 주시기를 바랍니다.
가능하진 않지만, 이 작업을 하지 않아도 되길 바랍니다. app.yml에 해당 sed 명령어를 추가하면 재빌드 시 자동으로 실행되도록 할 수 있습니다. 플러그인이 클론되는 부분 바로 아래에 넣으면 될 것 같습니다. 하지만 제 생각보다 더 복잡할 수도 있습니다.
AntiMetaman님,
지난 일주일 동안 s3 스토리지와 함께 백업이 작동하도록 시도해 보았고, 마침내 이 스레드를 통해 백업이 작동하도록 만들었습니다. 솔직히 어떤 부분이 실제로 효과가 있었는지 확실하지 않습니다.
gem 제거 및 재설치 작업을 진행하셨던 내용을 따라 했더니, 이제 이미지 업로드 시 오류가 발생합니다. 오류 로그에는 다음과 같은 내용이 표시됩니다.
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
서버 전체를 폐기하고 처음부터 다시 시작해야 하기 전에 (솔직히 이 시점에서는 계속 진행할 의향이 있는지조차 확신이 서지 않습니다), gem 제거 및 재설치를 되돌리는 방법을 아시나요? 그렇게 하면 이 문제가 해결될지 확인해 보고 싶습니다.
저희 인스턴스(백업에 Backblaze를 사용)에서 확인한 현상은 2월에 백업이 실패하기 시작했는데, 아무런 알림도 없었습니다. 저는 가끔 백업 상태를 확인하는 습관이 있어서 오늘 우연히 발견하게 되었습니다. 이 문제는 꽤 심각한 상황이라고 생각하지 않나요?
Backblaze를 비롯한 다른 비-AWS 제공업체에 대한 우회책이 나올 때까지 AWS-SDK를 이전 버전으로 다운그레이드하는 것이 가능할까요?
하지만 저는 Backblaze를 사용하는 사이트에서 이 방법을 사용했습니다. /root/aws-revert-template.yml에 다음과 같은 템플릿을 생성했습니다:
# This template reverts aws-sdk-s3 to a version that works with 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
그리고 app.yml에 다음과 같이 추가했습니다:
# IMPORTANT: SET A SECRET PASSWORD in Postgres for the Discourse User
# TODO: change SOME_SECRET in this template
templates:
- "templates/web.template.yml"
- "templates/web.ratelimited.template.yml"
## Uncomment these two lines if you wish to add Lets Encrypt (https)
- "templates/web.ssl.template.yml"
- "templates/web.letsencrypt.ssl.template.yml"
- "/root/aws-revert-template.yml"
그 후 stable 버전으로 업그레이드를 수행했고, 잘 작동하는 것 같습니다.
또는 템플릿에 있는 내용을 app.yml에 직접 추가하는 것도 가능합니다.
이 페이지(S3-Compatible API)에서 다양한 checksum-* 헤더가 지원되지 않는다는 목록이 더 이상 표시되지 않는 것을 확인했습니다.
@PatPatterson 님, 이 스레드에 아직 계신지 모르겠지만, 해당 헤더에 대한 공식 지원이 추가되었나요?
제가 제안한 수정 사항 없이 Backblaze B2가 정상적으로 작동하는지 확인해 주시겠어요?
빠른 답변 감사합니다. 그리고 죄송합니다 — 더 자세한 내용을 추가했어야 했는데 그러지 못했습니다. 다른 오픈소스 패키지(Mastodon)에서는 이 문제를 해결하기 위해 aws-sdk-core 지엄을 < 3.216.0으로 고정하는 조치를 취했습니다. 이는 Backblaze를 사용하는 사용자들(그리고 다른 사용자들도 마찬가지일 것으로 추정되지만, 이 문제에서 처음 발견되었습니다)을 위해 취한 조치입니다.
하지만 지난 몇 주간 다음과 같은 점을 알게 되었습니다:
- Backblaze 웹사이트에서 해당 헤더를 더 이상 지원되지 않는 항목으로 목록에 올리지 않고 있습니다.
- 최근 aws 지엄 릴리스에서
when_required가 이전에는 완전히 준수되지 않던 문제를 수정했다는 언급이 있습니다.
이전에 이 문제를 다루는 유사한 스레드를 확인한 적이 있으며, Backblaze가 실제로 해당 지원을 추가했거나, 지엄이 이제 이 문제를 완전히 우회하도록 작동하는지 확인하여 이제 지엄을 안전하게 업데이트할 수 있는지 이해하려고 노력하고 있습니다.
안녕하세요 - 네, Backblaze B2는 올해 초에 체크섬 헤더에 대한 공식 지원을 추가했습니다.
훌륭합니다! 확인해 주셔서 감사합니다.