Si realizas las actualizaciones desde la UX, eventualmente recibirás un mensaje que dice que tienes que hacer una actualización de línea de comandos. No depende de Debian, sino de la imagen base de Discourse.
2 Me gusta
Y con el método de 2 contenedores no habría ningún botón de actualización de la GUI, ¿correcto?
La actualización de la GUI proviene del plugin discourse_docker. Si tienes ese plugin, tienes la actualización de la GUI.
Cuando se descubren vulnerabilidades en herramientas de manipulación de imágenes, la excepción de código remoto definitivamente ha ocurrido en el pasado, lo que significa que estás a una carga de imagen de un sistema comprometido.
Clear Linux estableció el estándar de la velocidad de arranque en Linux. Es un trabajo increíble, lo respaldo totalmente.
1 me gusta
Oh, eso cambia un poco las cosas entonces. Por alguna razón, pensé que el actualizador de la GUI no funcionaría con una instalación no estándar de 2 contenedores. En ese caso, siempre que el administrador sea técnicamente competente, parece que no hay muchas desventajas en una instalación de 2 contenedores. Definitivamente quiero tener actualizaciones de la GUI, por ejemplo, si viajo solo con mi teléfono y sale una actualización de seguridad importante de Discourse, al menos puedo aplicarla sin acceso SSH.
1 me gusta
Esa es mi creencia. Básicamente, solo necesitas prestar suficiente atención para saber cuándo hay una actualización de Postgres o Redis que requiere reconstruir el contenedor de datos. También necesitas saber cómo ejecutar ./launcher bootstrap web_only && ./launcher destry web_only; ./launcher start web_only, pero eso no es tan difícil. Simplemente puedes ejecutar ./launcher rebuild web_only, pero eso interrumpe el sitio mientras se reconstruye.
2 Me gusta
Para ser completo: la compilación de la interfaz de usuario web normalmente no tiene tiempo de inactividad; el arranque/destrucción/inicio tiene un tiempo de inactividad mínimo y solo lo haría de forma normal con una página de mantenimiento proporcionada externamente, como con nginx externo, como se documenta aquí. Pero eso es una buena práctica de todos modos, aunque solo sea para introducir direcciones IPv6 en el contenedor.
Muy bien, gracias. Y con una instalación de 2 contenedores, ¿todavía recibes notificaciones del panel de control de Discourse cuando el contenedor necesita ser reconstruido? Y luego, en ese caso, ¿podría determinar si reconstruir solo la aplicación o también el contenedor de datos?
1 me gusta
Sí. Lo veo ahora mismo porque no he aplicado la actualización “solo ha cambiado la versión” 3.1.0.beta1. 
1 me gusta
Este es un caso de “está bien hasta que deja de estarlo”: la gente entra en pánico cuando la actualización falla en la interfaz de usuario y no saben que deben ejecutar git pull; ./launcher rebuild app para solucionar el problema. Esto sucede cada vez que hay un cambio que invalida la actualización de la GUI, creo. Volvió a suceder:
Siento que este pánico resalta el valor de tener un mecanismo de actualización consistente y normal que evite esta experiencia.
Al mismo tiempo, me encontré con el también infrecuente caso de que el bootstrap rompa el sistema en funcionamiento: las actualizaciones con tiempo de inactividad cero ocasionalmente fallan así, ¿una o dos veces al año tal vez en promedio? Así que no te demores entre el bootstrap y el destroy/start.
Debería actualizar el texto para dejar eso claro, así que lo haré a continuación.
Aún no he implementado LibreTranslate, pero estoy considerando hacerlo para que mi sitio sea más accesible internacionalmente.
Si lo implemento con éxito, tengo la intención de editar eso en la publicación principal. 
2 Me gusta
Gran parte de esto se me escapa, pero quiero darte las gracias, porque la poca configuración que mencionas con sugerencias de ajuste y una explicación de las consecuencias sobre cómo funciona la comunidad ya fue súper valiosa para mí.
4 Me gusta
Me alegra que haya sido útil incluso más allá de mi público objetivo declarado. 
Lo usé hace un par de días para configurar una nueva instancia de Discourse, y también me ayudó a mí, porque yo tampoco recuerdo todo esto. 
6 Me gusta
Creo que puede haber un problema con la configuración de THP en la wiki.
Tuve problemas con Redis en 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
Creí que THP ya estaba deshabilitado (por seguir la wiki), pero resultó que todavía estaba habilitado 
. Deshabilitar THP terminó resolviendo lo anterior para mí, si no recuerdo mal (a finales del año pasado).
Ubuntu 24.04 LTS (siguiendo la wiki actual):
cat /sys/kernel/mm/transparent_hugepage/enabled
# salida:
# [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
# salida:
# sys.kernel.mm.transparent_hugepage.enabled=never
sudo sysctl --system
# salida:
* 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
# salida:
# [always] madvise never
AlmaLinux 10 (siguiendo la wiki actual):
cat /sys/kernel/mm/transparent_hugepage/enabled
# salida:
# [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
# salida:
# sys.kernel.mm.transparent_hugepage.enabled=never
sudo sysctl --system
# salida:
* 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
# salida:
# [always] madvise never
¿Quizás esto sería adecuado para la wiki? Pareció funcionar en Ubuntu 24.04 y AlmaLinux 10 según las pruebas realizadas ahora:
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
Salida esperada:
always madvise [never]
Me alegra oír eso; si no sabemos si ayuda, ¡podríamos estar simplemente imitándonos unos a otros!
1 me gusta
No creo que /etc/sysctl.d haya sido desaprobado. ¿Puedes revisar los otros archivos listados allí y ver cuál(es) está(n) anulando /etc/sysctl.d/10-huge-pages.conf? ¿Quizás uno de esos archivos 50-priority?
La mejor solución probablemente será cambiar la prioridad de la configuración de páginas grandes para que gane. Pero no estoy ejecutando ninguna de esas versiones en mis sistemas ahora mismo.
También comprueba si tuned está anulando la configuración.
1 me gusta
Solo tuve un problema con la aplicación de la configuración de THP, vm.overcommit.memory se aplicó según lo esperado a través de /etc/sysctl.d. Esto se notó y resolvió en un servidor a finales del año pasado. Así que intenté verificarlo en un par de micro VPS ayer.
Acabo de probar esto en un micro VPS nuevo con AlmaLinux 9, en un intento de ver si alguno de los archivos .conf predeterminados está afectando la configuración de THP:
echo always | sudo tee /sys/kernel/mm/transparent_hugepage/enabled
# salida:
# always
cat /sys/kernel/mm/transparent_hugepage/enabled
# salida:
# [always] madvise never
sysctl --system
# salida:
* 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
# salida:
# [always] madvise never
echo never | sudo tee /sys/kernel/mm/transparent_hugepage/enabled
# salida:
# never
cat /sys/kernel/mm/transparent_hugepage/enabled
# salida:
# always madvise [never]
sysctl --system
# salida:
* 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
# salida:
# always madvise [never]
Por eso te pido que revises los archivos reales para encontrar qué lo está anulando, para que pueda hacer un cambio informado en la prioridad que recomiendo para la anulación.
1 me gusta
Mi entendimiento actual (limitado) es que los comandos/salidas de mi publicación anterior indican que no hay anulación.
Al revisar los archivos en una nueva instancia de AlmaLinux 9:
Estos resultaron vacíos:
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 predeterminados en los archivos de configuración:
/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
Estoy ejecutando AlmaLinux 9 para mis instancias de Discourse, y la configuración que proporcioné deshabilitó THP con éxito en todas ellas. Si deshabilitar THP a través de sysctl.d no funciona cuando no hay anulaciones implementadas, y tuned no lo está anulando, creo que es un error.
Pensé que estabas diciendo que ya no funcionaba en AlmaLinux 10, por eso preguntaba qué impedía que se aplicara allí.