Configuration de déploiement de discours d'opinion de MKJ

pfaffman · Janvier 12, 2023, 5:37

Si vous effectuez les mises à jour à partir de l’interface utilisateur, vous finirez par recevoir un message indiquant que vous devez effectuer une mise à jour en ligne de commande. Cela dépend non pas de Debian, mais de l’image Discourse de base.

rahim123 · Janvier 12, 2023, 5:38

Et avec la méthode à 2 conteneurs, il n’y aurait pas du tout de bouton de mise à jour de l’interface graphique, n’est-ce pas ?

pfaffman · Janvier 12, 2023, 5:40

La mise à jour de l’interface graphique provient du plugin discourse_docker. Si vous avez ce plugin, vous avez la mise à jour de l’interface graphique.

mcdanlj · Janvier 12, 2023, 5:44

Lorsqu’il y a des vulnérabilités découvertes dans les outils de manipulation d’images, une exception de code à distance s’est définitivement produite dans le passé, ce qui signifie que vous êtes à une téléversement d’image d’un système compromis.

Clear Linux a établi la norme en matière de rapidité de démarrage sous Linux. C’est un travail formidable, j’approuve de tout cœur.

rahim123 · Janvier 12, 2023, 5:48

Oh, cela change un peu les choses alors. Pour une raison quelconque, je pensais que le programme de mise à jour de l’interface graphique ne fonctionnerait pas avec une installation non standard à 2 conteneurs. Dans ce cas, tant que l’administrateur est techniquement compétent, il semble qu’il n’y ait pas beaucoup d’inconvénients à une installation à 2 conteneurs. Je veux absolument avoir des mises à jour de l’interface graphique, par exemple si je voyage avec seulement mon téléphone et qu’une mise à jour de sécurité majeure de Discourse sort, je peux au moins l’appliquer sans accès SSH.

pfaffman · Janvier 12, 2023, 5:57

C’est ce que je crois. Il faut juste faire assez attention pour savoir quand il y a une mise à niveau de Postgres ou Redis qui nécessite de reconstruire le conteneur de données. Il faut aussi savoir faire ./launcher bootstrap web_only && ./launcher destry web_only; ./launcher start web_only, mais ce n’est pas si difficile. Vous pouvez simplement faire un ./launcher rebuild web_only, mais cela met le site hors service pendant sa reconstruction.

mcdanlj · Janvier 12, 2023, 6:23

Pour être complet : la construction de l’interface utilisateur Web n’a normalement aucun temps d’arrêt ; le bootstrap/destroy/start a un temps d’arrêt minimal et je ne le ferais que normalement avec une page de maintenance fournie en externe comme avec nginx en externe, comme documenté ici. Mais c’est de toute façon une bonne pratique, ne serait-ce que pour obtenir les adresses IPv6 dans le conteneur.

rahim123 · Janvier 12, 2023, 6:27

Très bien, merci. Et avec une installation à 2 conteneurs, recevez-vous toujours les notifications du tableau de bord Discourse lorsque le conteneur doit être reconstruit ? Et dans ce cas, je pourrais déterminer s’il faut reconstruire uniquement l’application ou aussi le conteneur de données ?

mcdanlj · Janvier 12, 2023, 7:58

Oui. Je le vois maintenant car je n’ai pas appliqué la mise à jour « seule la version a changé » 3.1.0.beta1.

mcdanlj · Janvier 25, 2023, 9:36

C’est un cas de « tout va bien jusqu’à ce que ça n’aille plus » — les gens paniquent lorsque la mise à jour échoue dans l’interface utilisateur et qu’ils ne savent pas qu’il faut faire git pull; ./launcher rebuild app pour contourner le problème. Cela se produit à chaque fois qu’il y a un changement qui invalide la mise à jour de l’interface graphique, je pense. C’est encore arrivé :

Je pense que cette panique souligne l’importance d’avoir un mécanisme de mise à jour cohérent et normal qui évite cette expérience.

Dans le même temps, j’ai rencontré le cas également peu fréquent où le bootstrap casse le système en cours d’exécution : les mises à jour avec un temps d’arrêt quasi nul se cassent occasionnellement comme cela, une ou deux fois par an peut-être en moyenne ? Il ne faut donc pas tarder entre le bootstrap et le destroy/start.

Je devrais mettre à jour le texte pour clarifier cela, je vais donc le faire ensuite.

mcdanlj · Mars 23, 2024, 6:38

Je n’ai pas encore déployé LibreTranslate, mais j’envisage de le faire pour rendre mon site plus accessible à l’international.

Si j’y parviens, j’ai l’intention de l’ajouter au premier message.

stephtara · Décembre 15, 2025, 11:05

Beaucoup de choses me dépassent, mais je tiens à vous remercier, car les quelques paramètres que vous mentionnez avec des suggestions d’ajustement et une explication des conséquences sur le fonctionnement de la communauté étaient déjà super précieux pour moi !

mcdanlj · Décembre 15, 2025, 11:56

Content que cela ait été utile même au-delà de mon public cible déclaré. Je l’ai utilisé il y a quelques jours pour mettre en place une nouvelle instance Discourse, et cela m’a aussi aidé, car je ne me souviens pas de tout cela moi-même.

markersocial · Février 15, 2026, 3:11

Je pense qu’il pourrait y avoir un problème avec la configuration THP dans le wiki.

J’avais des problèmes avec Redis sur 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

Je pensais que THP était déjà désactivé (en suivant le wiki) - mais il s’est avéré qu’il était toujours activé . La désactivation de THP a fini par résoudre le problème ci-dessus pour moi, si je me souviens bien (fin de l’année dernière).

Ubuntu 24.04 LTS (en suivant le wiki actuel) :

cat /sys/kernel/mm/transparent_hugepage/enabled
# sortie :
# [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
# sortie :
# sys.kernel.mm.transparent_hugepage.enabled=never
sudo sysctl --system
# sortie :
* 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
# sortie :
# [always] madvise never

AlmaLinux 10 (en suivant le wiki actuel) :

cat /sys/kernel/mm/transparent_hugepage/enabled
# sortie :
# [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
# sortie :
# sys.kernel.mm.transparent_hugepage.enabled=never
sudo sysctl --system
# sortie :
* 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
# sortie :
# [always] madvise never

Peut-être que ceci serait approprié pour le wiki ? Semble avoir fonctionné sur Ubuntu 24.04 et AlmaLinux 10 d’après mes tests actuels :

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

Pour confirmer :

cat /sys/kernel/mm/transparent_hugepage/enabled

Sortie attendue :

always madvise [never]

Ed_S · Février 15, 2026, 3:19

C’est une bonne nouvelle - si nous ne savons pas si cela aide, nous pourrions simplement nous imiter les uns les autres !

mcdanlj · Février 15, 2026, 10:00

Je ne pense pas que /etc/sysctl.d ait été déprécié. Pouvez-vous examiner les autres fichiers listés là-bas et voir lequel (lesquels) écrase /etc/sysctl.d/10-huge-pages.conf ? Peut-être l’un de ces fichiers 50-priority ?

La meilleure solution sera probablement de changer la priorité du paramètre huge-pages pour qu’il l’emporte. Mais je n’exécute aucune de ces versions sur mes systèmes actuellement.

Vérifiez également si tuned écrase le paramètre.

markersocial · Février 16, 2026, 4:37

Je n’ai eu de problème qu’avec l’application de la configuration THP, vm.overcommit.memory s’est appliqué comme prévu via /etc/sysctl.d. Cela a été remarqué et résolu sur un serveur à la fin de l’année dernière. J’ai donc essayé de vérifier via quelques micro VPS hier.

Je viens d’essayer ceci sur un nouveau micro VPS AlmaLinux 9, pour voir si l’un des fichiers .conf par défaut affecte la configuration THP :

echo always | sudo tee /sys/kernel/mm/transparent_hugepage/enabled
# sortie :
# always

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

sysctl --system
# sortie :
* 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
# sortie :
# [always] madvise never

echo never | sudo tee /sys/kernel/mm/transparent_hugepage/enabled
# sortie :
# never

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

sysctl --system
# sortie :
* 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
# sortie :
# always madvise [never]

mcdanlj · Février 16, 2026, 1:02

C’est pourquoi je vous demande d’examiner les fichiers réels pour trouver ce qui la surcharge, afin que je puisse faire un changement éclairé sur la priorité que je recommande pour la surcharge.

markersocial · Février 16, 2026, 3:22

Ma compréhension actuelle (limitée) est que les commandes/sorties de mon message précédent indiquent qu’il n’y a pas de substitution.

En examinant les fichiers sur une nouvelle instance AlmaLinux 9 :

Ceux-ci sont revenus vides :

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

Valeurs par défaut dans les fichiers de configuration :

/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 · Février 16, 2026, 7:56

J’utilise AlmaLinux 9 pour mes instances Discourse, et la configuration que j’ai fournie a désactivé THP avec succès sur toutes mes instances. Si la désactivation de THP via sysctl.d ne fonctionne pas lorsqu’aucune substitution n’est en place, et que tuned ne la surcharge pas, je considérerais cela comme un bogue.

Je pensais que vous disiez que cela ne fonctionnait plus sur AlmaLinux 10, c’est pourquoi je demandais ce qui empêchait son application là-bas.

Sujet		Réponses	Vues
I'm writing a short documentation for admins of Discourse forums I've helped set up. Do I miss something in it? General	12	260	Décembre 30, 2025
Installing Discourse With Plesk Onyx (Ubuntu 14.04) Self-hosting unsupported-install	47	12618	Octobre 10, 2019
Deploy Discourse without Docker Sysadmins unsupported-install , advanced-setup	33	1403	Janvier 8, 2026
Install Discourse on CloudPanel Sysadmins unsupported-install , install	36	4397	Février 6, 2025
Discourse image and installation size. Clean /var/lib/docker/overlay2? Self-hosting server-resources	10	4272	Juillet 28, 2021

Configuration de déploiement de discours d'opinion de MKJ

Sujets connexes