Configuração de Implantação de Discurso Opinativo do MKJ

[pfaffman (Jay Pfaffman)]

@rahim123

O painel do Discourse notifica especificamente sobre esse tipo de atualização necessária?

Se você fizer as atualizações pela UX, eventualmente receberá uma mensagem dizendo que precisa fazer uma atualização pela linha de comando. Não depende do Debian, mas da imagem base do Discourse.

[rahim123]

E com o método de 2 contêineres não haveria botão de atualização da GUI, correto?

[pfaffman (Jay Pfaffman)]

A atualização da GUI vem do plugin discourse_docker. Se você tiver esse plugin, terá a atualização da GUI.

[mcdanlj (Michael K Johnson)]

@rahim123

a vulnerabilidade / vetor de ataque típico que leva a sites comprometidos no mundo real está quase sempre no código do aplicativo web ou em um de seus frameworks de desenvolvimento web

Quando há vulnerabilidades descobertas em ferramentas de manipulação de imagem, a exceção de código remoto definitivamente aconteceu no passado, o que significa que você está a um upload de imagem de um sistema comprometido.

@rahim123

uma rápida propaganda para o Clear Linux

O Clear Linux estabeleceu o padrão de quão rápido você pode inicializar no Linux. É um trabalho incrível, endosso de todo o coração.

[rahim123]

@pfaffman

A atualização da GUI vem do plugin discourse_docker. Se você tiver esse plugin, terá a atualização da GUI.

Ah, isso muda um pouco as coisas então. Por algum motivo, eu estava pensando que o atualizador da GUI não funcionaria com uma instalação não padrão de 2 contêineres. Nesse caso, desde que o administrador seja tecnicamente competente, parece que não há muitas desvantagens em uma instalação de 2 contêineres. Eu definitivamente quero ter atualizações da GUI, por exemplo, se eu estiver viajando apenas com meu telefone e uma grande atualização de segurança do Discourse for lançada, eu posso pelo menos aplicá-la sem acesso SSH.

[pfaffman (Jay Pfaffman)]

@rahim123

enquanto o administrador for tecnicamente competente, parece que não há muitas desvantagens em uma instalação de 2 contêineres

Essa é a minha crença. Você basicamente precisa prestar atenção o suficiente apenas para saber quando há uma atualização do Postgres ou Redis que exige a reconstrução do contêiner de dados. Você também precisa saber como executar ./launcher bootstrap web_only && ./launcher destry web_only; ./launcher start web_only, mas isso não é tão difícil. Você pode simplesmente executar um ./launcher rebuild web_only, mas isso tira o site do ar enquanto ele está sendo reconstruído.

[mcdanlj (Michael K Johnson)]

Para completar: a interface web normalmente não tem tempo de inatividade; o bootstrap/destroy/start tem tempo de inatividade mínimo e eu só faria isso normalmente com uma página de manutenção fornecida externamente, como com nginx externo, conforme documentado aqui. Mas isso é uma boa prática de qualquer maneira, se apenas para obter endereços IPv6 no contêiner.

[rahim123]

Muito bom, obrigado. E com uma instalação de 2 contêineres, você ainda recebe notificações do painel do Discourse quando o contêiner precisa ser reconstruído? E então, nesse caso, eu poderia determinar se devo reconstruir apenas o aplicativo ou também o contêiner de dados?

[mcdanlj (Michael K Johnson)]

Sim. Eu a vejo agora porque não apliquei a atualização "apenas a versão mudou" 3.1.0.beta1.

[mcdanlj (Michael K Johnson)]

Este é um caso de “está tudo bem até que não esteja” — as pessoas entram em pânico quando a atualização falha na interface do usuário e elas não sabem que precisam executar git pull; ./launcher rebuild app para contornar o problema. Isso acontece sempre que há uma alteração que invalida a atualização da GUI, eu acho. Aconteceu novamente:

Failed upgrade from 2.9.0.beta14 to 3.1.0.beta

I upgrade every month, always on a few development systems first, then production. During this month’s cycle, the upgrade failed on the 1st development system. docker_manager upgraded fine but the discourse upgrade failed with: Sorry, there was an error upgrading Discourse. Please check the logs below. The Discourse app is completely down (it’s displaying the “Oops” error 500 page). Here’s what the on-screen log contains: ******************************************************** *** Please …

Sinto que esse pânico destaca o valor de ter um mecanismo de atualização consistente e normal que evita essa experiência.

Ao mesmo tempo, encontrei o também infrequente caso em que o bootstrap quebra o sistema em execução: atualizações com tempo de inatividade zero ocasionalmente quebram assim, uma ou duas vezes por ano, talvez em média? Portanto, não demore entre o bootstrap e o destroy/start.

Self-hosted upgrade to 3.1.0.beta2 with typical multi-container install requires extra downtime

I updated my sites from 3.1.0.beta1 to 3.1.0.beta2, and after bootstrapping the new version, but before destroying the old app containers and starting new ones, at least one of those sites started giving the generic error page to users. I didn’t notice it on my test site or the other sites I run, but it’s possible that it happened and I didn’t see it. In any case, for me in at least one case, the “zero downtime” update process did not succeed.

Devo atualizar o texto para deixar isso claro, então farei isso em seguida.

[mcdanlj (Michael K Johnson)]

Ainda não implementei o LibreTranslate, mas estou considerando fazer isso para tornar meu site mais acessível internacionalmente.

LibreTranslate Plugin -- Free and Open Source Translation API

Continuing the discussion from Discourse Translator: LibreTranslate - Github project page Project discussion at https://community.libretranslate.com/ Free and Open Source Machine Translation API. 100% self-hosted, offline capable and easy to setup. Powered by the open source Argos Translate API Docs Discourse Installation copy-pasted from the Github readme You can use this discourse translator plugin to translate Discourse topics. To install it simply modify /var/discourse/containers/app…

Se eu conseguir fazer isso com sucesso, pretendo editar isso na postagem principal.

[stephtara (Stephanie Booth)]

Muito disso está acima da minha compreensão, mas quero agradecer, porque as poucas configurações que você menciona com sugestões de ajuste e uma explicação das consequências sobre como a comunidade funciona já foram super preciosas para mim!

[mcdanlj (Michael K Johnson)]

Fico feliz que tenha sido útil mesmo além do meu público-alvo declarado. Eu a usei há alguns dias para configurar uma nova instância do Discourse, e me ajudou também, porque eu não me lembro de tudo isso.

[markersocial]

@mcdanlj

echo 'sys.kernel.mm.transparent_hugepage.enabled=never' > /etc/sysctl.d/10-huge-pages.conf
echo 'vm.overcommit_memory=1' > /etc/sysctl.d/90-vm_overcommit_memory.conf
sysctl --system

Acho que pode haver um problema com a configuração do THP na wiki.

Eu estava tendo problemas com o Redis no Ubuntu:

Your Redis network connection is performing extremely poorly. Last RTT readings were [96585, 101554, 97189, 99769, 94618], ideally these should be < 1000. Ensure Redis is running in the same AZ or dat

Eu acreditei que o THP já estava desabilitado (por seguir a wiki) - mas descobri que ele ainda estava habilitado . Desabilitar o THP acabou resolvendo o problema acima para mim, se bem me lembro (final do ano passado).

---

Ubuntu 24.04 LTS (seguindo a wiki atual):

cat /sys/kernel/mm/transparent_hugepage/enabled
# output:
# [always] madvise never

echo 'sys.kernel.mm.transparent_hugepage.enabled=never' > /etc/sysctl.d/10-huge-pages.conf

cat /etc/sysctl.d/10-huge-pages.conf
# output:
# sys.kernel.mm.transparent_hugepage.enabled=never

sudo sysctl --system
# output:
* Applying /usr/lib/sysctl.d/10-apparmor.conf ...
* Applying /etc/sysctl.d/10-bufferbloat.conf ...
* Applying /etc/sysctl.d/10-console-messages.conf ...
* Applying /etc/sysctl.d/10-huge-pages.conf ...
* Applying /etc/sysctl.d/10-ipv6-privacy.conf ...
* Applying /etc/sysctl.d/10-kernel-hardening.conf ...
* Applying /etc/sysctl.d/10-magic-sysrq.conf ...
* Applying /etc/sysctl.d/10-map-count.conf ...
* Applying /etc/sysctl.d/10-network-security.conf ...
* Applying /etc/sysctl.d/10-ptrace.conf ...
* Applying /etc/sysctl.d/10-zeropage.conf ...
* Applying /usr/lib/sysctl.d/50-pid-max.conf ...
* Applying /etc/sysctl.d/99-cloudimg-ipv6.conf ...
* Applying /usr/lib/sysctl.d/99-protect-links.conf ...
* Applying /etc/sysctl.d/99-sysctl.conf ...
* Applying /etc/sysctl.conf ...
kernel.apparmor_restrict_unprivileged_userns = 1
net.core.default_qdisc = fq_codel
kernel.printk = 4 4 1 7
net.ipv6.conf.all.use_tempaddr = 2
net.ipv6.conf.default.use_tempaddr = 2
kernel.kptr_restrict = 1
kernel.sysrq = 176
vm.max_map_count = 1048576
net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.all.rp_filter = 2
kernel.yama.ptrace_scope = 1
vm.mmap_min_addr = 65536
kernel.pid_max = 4194304
net.ipv6.conf.all.use_tempaddr = 0
net.ipv6.conf.default.use_tempaddr = 0
fs.protected_fifos = 1
fs.protected_hardlinks = 1
fs.protected_regular = 2
fs.protected_symlinks = 1

cat /sys/kernel/mm/transparent_hugepage/enabled
# output:
# [always] madvise never

---

AlmaLinux 10 (seguindo a wiki atual):

cat /sys/kernel/mm/transparent_hugepage/enabled
# output:
# [always] madvise never

echo 'sys.kernel.mm.transparent_hugepage.enabled=never' > /etc/sysctl.d/10-huge-pages.conf

cat /etc/sysctl.d/10-huge-pages.conf
# output:
# sys.kernel.mm.transparent_hugepage.enabled=never

sudo sysctl --system
# output:
* Applying /usr/lib/sysctl.d/10-default-yama-scope.conf ...
* Applying /etc/sysctl.d/10-huge-pages.conf ...
* Applying /usr/lib/sysctl.d/10-map-count.conf ...
* Applying /usr/lib/sysctl.d/50-coredump.conf ...
* Applying /usr/lib/sysctl.d/50-default.conf ...
* Applying /usr/lib/sysctl.d/50-libkcapi-optmem_max.conf ...
* Applying /usr/lib/sysctl.d/50-pid-max.conf ...
* Applying /usr/lib/sysctl.d/50-redhat.conf ...
* Applying /etc/sysctl.d/99-sysctl.conf ...
* Applying /etc/sysctl.conf ...
kernel.yama.ptrace_scope = 0
vm.max_map_count = 1048576
kernel.core_pattern = |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h
kernel.core_pipe_limit = 16
fs.suid_dumpable = 2
kernel.sysrq = 16
kernel.core_uses_pid = 1
net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.eth0.rp_filter = 2
net.ipv4.conf.eth1.rp_filter = 2
net.ipv4.conf.lo.rp_filter = 2
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.conf.eth0.accept_source_route = 0
net.ipv4.conf.eth1.accept_source_route = 0
net.ipv4.conf.lo.accept_source_route = 0
net.ipv4.conf.default.promote_secondaries = 1
net.ipv4.conf.eth0.promote_secondaries = 1
net.ipv4.conf.eth1.promote_secondaries = 1
net.ipv4.conf.lo.promote_secondaries = 1
net.ipv4.ping_group_range = 0 2147483647
net.core.default_qdisc = fq_codel
fs.protected_hardlinks = 1
fs.protected_symlinks = 1
fs.protected_regular = 1
fs.protected_fifos = 1
net.core.optmem_max = 81920
kernel.pid_max = 4194304
kernel.kptr_restrict = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.eth0.rp_filter = 1
net.ipv4.conf.eth1.rp_filter = 1
net.ipv4.conf.lo.rp_filter = 1

cat /sys/kernel/mm/transparent_hugepage/enabled
# output:
# [always] madvise never

---

Talvez isto seja adequado para a wiki? Pareceu funcionar no Ubuntu 24.04 e AlmaLinux 10 a partir dos testes agora:

echo 'w /sys/kernel/mm/transparent_hugepage/enabled - - - - never' | sudo tee /etc/tmpfiles.d/10-huge-pages.conf
sudo systemd-tmpfiles --create /etc/tmpfiles.d/10-huge-pages.conf

Para confirmar:

cat /sys/kernel/mm/transparent_hugepage/enabled

Saída esperada:

always madvise [never]

[Ed_S]

@markersocial

Desativar o THP acabou resolvendo o problema acima para mim

Que bom ouvir isso - se não soubermos se ajuda, podemos estar apenas imitando uns aos outros!

[mcdanlj (Michael K Johnson)]

Eu não acho que /etc/sysctl.d tenha sido descontinuado. Você pode verificar os outros arquivos listados lá e ver qual(is) está(ão) substituindo /etc/sysctl.d/10-huge-pages.conf? Talvez um daqueles arquivos 50-priority?

A melhor solução provavelmente será mudar a prioridade da configuração de páginas grandes para prevalecer. Mas eu não estou executando nenhuma dessas versões nos meus sistemas agora.

Verifique também se o tuned está substituindo a configuração.

[markersocial]

Tive um problema apenas com a aplicação da configuração do THP, vm.overcommit.memory foi aplicado como esperado via /etc/sysctl.d. Isso foi notado e resolvido em um servidor no final do ano passado. Então, tentei verificar em alguns micro VPS ontem.

Acabei de tentar isto em um micro VPS AlmaLinux 9 novo, na tentativa de ver se algum dos arquivos .conf padrão está afetando a configuração do THP:

echo always | sudo tee /sys/kernel/mm/transparent_hugepage/enabled
# saída:
# always

cat /sys/kernel/mm/transparent_hugepage/enabled
# saída:
# [always] madvise never

sysctl --system
# saída:
* Applying /usr/lib/sysctl.d/10-default-yama-scope.conf ...
* Applying /usr/lib/sysctl.d/50-coredump.conf ...
* Applying /usr/lib/sysctl.d/50-default.conf ...
* Applying /usr/lib/sysctl.d/50-libkcapi-optmem_max.conf ...
* Applying /usr/lib/sysctl.d/50-pid-max.conf ...
* Applying /usr/lib/sysctl.d/50-redhat.conf ...
* Applying /etc/sysctl.d/99-sysctl.conf ...
* Applying /etc/sysctl.conf ...
kernel.yama.ptrace_scope = 0
kernel.core_pattern = |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h
kernel.core_pipe_limit = 16
fs.suid_dumpable = 2
kernel.sysrq = 16
kernel.core_uses_pid = 1
net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.eth0.rp_filter = 2
net.ipv4.conf.eth1.rp_filter = 2
net.ipv4.conf.lo.rp_filter = 2
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.conf.eth0.accept_source_route = 0
net.ipv4.conf.eth1.accept_source_route = 0
net.ipv4.conf.lo.accept_source_route = 0
net.ipv4.conf.default.promote_secondaries = 1
net.ipv4.conf.eth0.promote_secondaries = 1
net.ipv4.conf.eth1.promote_secondaries = 1
net.ipv4.conf.lo.promote_secondaries = 1
net.ipv4.ping_group_range = 0 2147483647
net.core.default_qdisc = fq_codel
fs.protected_hardlinks = 1
fs.protected_symlinks = 1
fs.protected_regular = 1
fs.protected_fifos = 1
net.core.optmem_max = 81920
kernel.pid_max = 4194304
kernel.kptr_restrict = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.eth0.rp_filter = 1
net.ipv4.conf.eth1.rp_filter = 1
net.ipv4.conf.lo.rp_filter = 1

cat /sys/kernel/mm/transparent_hugepage/enabled
# saída:
# [always] madvise never

echo never | sudo tee /sys/kernel/mm/transparent_hugepage/enabled
# saída:
# never

cat /sys/kernel/mm/transparent_hugepage/enabled
# saída:
# always madvise [never]

sysctl --system
# saída:
* Applying /usr/lib/sysctl.d/10-default-yama-scope.conf ...
* Applying /usr/lib/sysctl.d/50-coredump.conf ...
* Applying /usr/lib/sysctl.d/50-default.conf ...
* Applying /usr/lib/sysctl.d/50-libkcapi-optmem_max.conf ...
* Applying /usr/lib/sysctl.d/50-pid-max.conf ...
* Applying /usr/lib/sysctl.d/50-redhat.conf ...
* Applying /etc/sysctl.d/99-sysctl.conf ...
* Applying /etc/sysctl.conf ...
kernel.yama.ptrace_scope = 0
kernel.core_pattern = |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h
kernel.core_pipe_limit = 16
fs.suid_dumpable = 2
kernel.sysrq = 16
kernel.core_uses_pid = 1
net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.eth0.rp_filter = 2
net.ipv4.conf.eth1.rp_filter = 2
net.ipv4.conf.lo.rp_filter = 2
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.conf.eth0.accept_source_route = 0
net.ipv4.conf.eth1.accept_source_route = 0
net.ipv4.conf.lo.accept_source_route = 0
net.ipv4.conf.default.promote_secondaries = 1
net.ipv4.conf.eth0.promote_secondaries = 1
net.ipv4.conf.eth1.promote_secondaries = 1
net.ipv4.conf.lo.promote_secondaries = 1
net.ipv4.ping_group_range = 0 2147483647
net.core.default_qdisc = fq_codel
fs.protected_hardlinks = 1
fs.protected_symlinks = 1
fs.protected_regular = 1
fs.protected_fifos = 1
net.core.optmem_max = 81920
kernel.pid_max = 4194304
kernel.kptr_restrict = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.eth0.rp_filter = 1
net.ipv4.conf.eth1.rp_filter = 1
net.ipv4.conf.lo.rp_filter = 1

cat /sys/kernel/mm/transparent_hugepage/enabled
# saída:
# always madvise [never]

[mcdanlj (Michael K Johnson)]

@markersocial

Eu tive um problema apenas com a aplicação da configuração do THP, vm.overcommit.memory foi aplicado como esperado via /etc/sysctl.d

É por isso que estou pedindo para você analisar os arquivos reais para encontrar o que está substituindo isso, para que eu possa fazer uma alteração informada na prioridade que recomendo para a substituição.

[markersocial]

Meu entendimento atual (limitado) é que os comandos/saídas da minha postagem anterior indicam que não há substituição (override).

Analisando os arquivos em uma nova instância do AlmaLinux 9:

Estes retornaram vazios:

grep -r "transparent_hugepage" /usr/lib/sysctl.d/ /etc/sysctl.d/ /etc/sysctl.conf
grep -r "transparent" /usr/lib/sysctl.d/ /etc/sysctl.d/ /etc/sysctl.conf
grep -r "huge" /usr/lib/sysctl.d/ /etc/sysctl.d/ /etc/sysctl.conf
grep -r "page" /usr/lib/sysctl.d/ /etc/sysctl.d/ /etc/sysctl.conf

Valores padrão nos arquivos de configuração:

/usr/lib/sysctl.d/50-redhat.conf:kernel.kptr_restrict = 1
/usr/lib/sysctl.d/50-redhat.conf:net.ipv4.conf.default.rp_filter = 1
/usr/lib/sysctl.d/50-redhat.conf:net.ipv4.conf.*.rp_filter = 1
/usr/lib/sysctl.d/50-redhat.conf:-net.ipv4.conf.all.rp_filter
/usr/lib/sysctl.d/10-default-yama-scope.conf:kernel.yama.ptrace_scope = 0
/usr/lib/sysctl.d/50-libkcapi-optmem_max.conf:net.core.optmem_max = 81920
/usr/lib/sysctl.d/50-coredump.conf:kernel.core_pattern=|/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h
/usr/lib/sysctl.d/50-coredump.conf:kernel.core_pipe_limit=16
/usr/lib/sysctl.d/50-coredump.conf:fs.suid_dumpable=2
/usr/lib/sysctl.d/50-default.conf:kernel.sysrq = 16
/usr/lib/sysctl.d/50-default.conf:kernel.core_uses_pid = 1
/usr/lib/sysctl.d/50-default.conf:net.ipv4.conf.default.rp_filter = 2
/usr/lib/sysctl.d/50-default.conf:net.ipv4.conf.*.rp_filter = 2
/usr/lib/sysctl.d/50-default.conf:-net.ipv4.conf.all.rp_filter
/usr/lib/sysctl.d/50-default.conf:net.ipv4.conf.default.accept_source_route = 0
/usr/lib/sysctl.d/50-default.conf:net.ipv4.conf.*.accept_source_route = 0
/usr/lib/sysctl.d/50-default.conf:-net.ipv4.conf.all.accept_source_route
/usr/lib/sysctl.d/50-default.conf:net.ipv4.conf.default.promote_secondaries = 1
/usr/lib/sysctl.d/50-default.conf:net.ipv4.conf.*.promote_secondaries = 1
/usr/lib/sysctl.d/50-default.conf:-net.ipv4.conf.all.promote_secondaries
/usr/lib/sysctl.d/50-default.conf:-net.ipv4.ping_group_range = 0 2147483647
/usr/lib/sysctl.d/50-default.conf:-net.core.default_qdisc = fq_codel
/usr/lib/sysctl.d/50-default.conf:fs.protected_hardlinks = 1
/usr/lib/sysctl.d/50-default.conf:fs.protected_symlinks = 1
/usr/lib/sysctl.d/50-default.conf:fs.protected_regular = 1
/usr/lib/sysctl.d/50-default.conf:fs.protected_fifos = 1
/usr/lib/sysctl.d/50-pid-max.conf:kernel.pid_max = 4194304

[mcdanlj (Michael K Johnson)]

@markersocial

Analisando os arquivos em uma nova instância do AlmaLinux 9:

Eu estou rodando o AlmaLinux 9 para minhas instâncias do Discourse, e a configuração que forneci desabilitou com sucesso o THP em todas elas. Se desabilitar o THP através do sysctl.d não estiver funcionando quando não há substituições em vigor, e o tuned não estiver substituindo, eu pensaria que isso é um bug.

Eu pensei que você estava dizendo que não funcionava mais no AlmaLinux 10, que é o motivo pelo qual eu estava perguntando o que estava impedindo sua aplicação lá.