Obrigado pelo agradecimento! Eu sinalizei para atenção dos moderadores porque não tinha direitos de edição naquele momento, mas agora os tenho graças à postagem que fiz. Irônico como isso funciona, né?
Mas antes de fazer um aviso geral fora da seção MinIO, podemos confirmar que o Discourse como um todo não suporta mais caminhos não baseados em domínio como esta postagem iniciou minha caça por edições?
Se soubermos que o Discourse como um todo não suporta o modo de caminho (ou seja, caminhos minio.server.com/BUCKET/foo/bar/...) e em vez disso suporta apenas caminhos de domínio (ou seja, BUCKET.minio.server.com/foo/bar/...), então podemos fazer disso um aviso global na wiki e ficarei feliz em fazê-lo - no entanto, preciso ouvir de alguém muito mais acima na hierarquia do que eu (como uma simples pessoa da comunidade) que este é de fato o requisito para o Discourse. Se for, então poderei editá-lo, caso contrário… bem, então eu apenas o deixarei como um aviso nos requisitos do MinIO.
O MinIO é o único clone popular do S3 com um histórico de uso do agora descontinuado estilo de caminho S3, então não acho que justifique um aviso global, apenas na seção do MinIO é suficiente.
Obrigado, Falco, deixei nos requisitos do MinIO, mas também dei bastante ênfase àquela seção de ressalvas por causa do tópico vinculado acima que se refere ao motivo pelo qual estou insistindo novamente.
FALHA
--------------------
Pups::ExecError: cd /var/www/discourse & sudo -E -u discourse bundle exec rake s3:upload_assets falhou com retorno #<Process::Status: pid 2064 exit 1>
Localização da falha: /usr/local/lib/ruby/gems/2.7.0/gems/pups-1.1.1/lib/pups/exec_command.rb:117:in `spawn'
exec falhou com os parâmetros {"cd"=>"$home", "cmd"=>["sudo -E -u discourse bundle exec rake s3:upload_assets"]}
bootstrap falhou com código de saída 1
** FALHA AO INICIALIZAR ** por favor, role para cima e procure por mensagens de erro anteriores, pode haver mais de uma.
./discourse-doctor pode ajudar a diagnosticar o problema.
Olá @Falco. Isso faz sentido? Estou revisando as respostas para garantir que foram tratadas para que possamos ativar a opção de exclusão após 30 dias neste tópico.
Verifiquei alguns dos uploads marcados como privados e eles estavam em tópicos normais, então não consegui descobrir por que foram marcados como seguros. (Uploads seguros não estavam definidos?)
Faz sentido. Atualizei o topo do OP com essa informação. Alguma ideia de por que os uploads locais teriam sido marcados como seguros em um site que não tinha S3 ou uploads seguros habilitados?
Acho que este problema com o upload para o Cloudflare R2 pode ser resolvido com Upload.where(secure: true).update_all(secure: false). Tentarei resolver isso antes que esta mensagem seja excluída (mas adicionei uma nota ao OP).
Hmm, não temos nenhum upload seguro. Acho que vou experimentar o Cloudflare R2, pois os limites gratuitos deles são bem generosos e eles têm um migrador S3 (beta). Acho que vou descobrir, mas você viu se o R2 ficou bom no final, @pfaffman?
Não consigo mais me lembrar se o problema ocorreu quando tentei fazer upload de imagens ou quando acabei de fazer upload de uma nova. Pensando bem, eu diria que testei em um site totalmente novo.
Migrar para uma plataforma S3 diferente é bastante complicado. Existem alguns tópicos sobre isso, mas se você quiser usar o Cloudflare R2, eu primeiro tentaria em um site de teste; há uma chance muito boa de que não funcione.
Funciona mais ou menos, mas não está pronto para uso em produção.
Eu tinha uma instalação de desenvolvimento local mais antiga do Discourse 2.7 por perto e funcionou bem, como em uploads de imagem, uso de CDN e backups para um bucket privado quando configurado para Cloudflare R2. Atualizei para a versão mais recente 2.9 (como nosso fórum usa) e parece falhar no processamento de recuperação Jobs::UpdateGravatar, onde está usando a notação de bucket incorretamente para Cloudflare, onde tenta armazenar em cache uma imagem remota do gravatar no R2. Exemplo (onde meu nome de bucket no 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
Então, eu iniciaria a interface do usuário e os avatares na minha configuração de teste/desenvolvimento local apontariam para
Então, minha melhor suposição é que o S3 está bem com a notação de ponto do bucket e o Cloudflare R2 não está, ou talvez o cache do gravatar precise usar o valor da CDN do S3 em vez disso? É uma pena, pois parece muito próximo.
Recebi uma resposta da Cloudflare de que, para o R2, até que eles implementem o ACL de objeto corretamente, eles o alteraram para retornar um 200 se receberem valores nessa propriedade que ainda não suportam. Esse comportamento alterado no R2 ocorreu no final de novembro, aparentemente. Obviamente, não é o ideal (está em um bucket público, com a API solicitando que seja privado), mas significa que, para este problema, agora ‘funciona’.
Oh! Isso parece promissor. Acho que talvez você precise de um bucket separado para uploads, embora seja um jogo de adivinhação para obter o nome do arquivo de backup.
Eu uso buckets de upload e backup separados, e parece que funcionou bem, pois o bucket de backup R2 não está definido como público e o Discourse, através da interface de administração, gravou um backup compactado lá sem problemas. Baixei e dei uma olhada e pareceu razoável (não o mesmo que um restore real, mas bom o suficiente para uma segunda-feira). Meu bucket de uploads testei com uma configuração de domínio personalizado para o S3_CDN e isso parece funcionar bem.
Para ser honesto, não consigo realmente dizer o que está acontecendo com meu 2.9 que não está renderizando uma interface de usuário no ember-cli (fica em branco depois de criar o usuário administrador), mas provavelmente é algo que você verá errado rapidamente.
EDIT: Ah, parece que ele está tentando carregar os ativos de javascript do plugin do Pseudo-S3/R2, por exemplo, muitos 404s em coisas como assets/locales/en.br.js.
Não tenho sorte com um bundle exec rake s3:upload_assets, então essa é minha melhor pista atual.
EDIT2: Sim, está relacionado aos ativos, pois se eu limpar meu DISCOURSE_S3_CDN_URL, a interface de usuário carrega. Tentarei apenas fazer o upload manual dos ativos no local por enquanto.
EDIT3: O problema parece ser apenas um dos aplicativos precisando que os ativos sejam pré-compilados e para onde o DISCOURSE_S3_CDN_URL está apontando, e para um ambiente de desenvolvimento local isso não é usual. Terei interesse no que @pfaffman encontrar, pois acho que isso funcionaria em uma instância auto-hospedada implantada em docker, usando o hook after_assets_precompile para R2.
Sim. Um CDN para um ambiente de desenvolvimento local? Não consigo imaginar que possa funcionar. Soa como se devesse funcionar para uma implantação de produção.
Sim, em retrospectiva, não surpreendentemente em uma configuração de desenvolvimento. Acho que o que eu não esperava era que, com DISCOURSE_S3_CDN_URL definido para o CDN da Cloudflare para R2, mas então DISCOURSE_CDN_URL definido como em branco (ou local ou ngrok), ele ainda quisesse usar a URL de pull da Cloudflare para os ativos pré-compilados, etc., e não apenas para os uploads/imagens. Acho que funcionará bem em produção em um contêiner adequado, então farei um teste rápido. Meu plano será algo como tornar os uploads de mídia TL4 temporariamente, mudar os IDs, etc., para a Cloudflare no app.yaml, testar e, se estiver bom, deixar para o R2 e então usar o rclone para transferir todos os objetos S3 existentes - depois disso, refarei os posts e espero que tudo fique bem .
.