Configurazione di dispiegamento del discorso di MKJ con opinioni

[pfaffman (Jay Pfaffman)]

@rahim123

La dashboard di Discourse notifica specificamente quel tipo di aggiornamento richiesto?

Se esegui gli aggiornamenti dall’interfaccia utente, alla fine riceverai un messaggio che dice che devi eseguire un aggiornamento da riga di comando. Non dipende da Debian, ma dall’immagine base di Discourse.

[rahim123]

E con il metodo a 2 contenitori non ci sarebbe alcun pulsante di aggiornamento dell’interfaccia grafica, corretto?

[pfaffman (Jay Pfaffman)]

L’aggiornamento dell’interfaccia grafica proviene dal plugin discourse_docker. Se hai quel plugin, hai l’aggiornamento dell’interfaccia grafica.

[mcdanlj (Michael K Johnson)]

@rahim123

la tipica vulnerabilità / vettore di attacco che porta a siti web compromessi nel mondo reale si trova quasi sempre nel codice dell’applicazione web o in uno dei suoi framework di sviluppo web

Quando vengono scoperte vulnerabilità negli strumenti di manipolazione delle immagini, in passato si è verificata un’eccezione di codice remoto, il che significa che sei a un caricamento di immagini di distanza da un sistema compromesso.

@rahim123

una rapida menzione per Clear Linux

Clear Linux ha stabilito lo standard per la velocità di avvio su Linux. È un lavoro fantastico, lo approvo di tutto cuore.

[rahim123]

@pfaffman

L’aggiornamento dell’interfaccia grafica proviene dal plugin discourse_docker. Se hai quel plugin, hai l’aggiornamento dell’interfaccia grafica.

Oh, questo cambia un po’ le cose allora. Per qualche motivo pensavo che l’aggiornamento dell’interfaccia grafica non avrebbe funzionato con un’installazione non standard a 2 container. In tal caso, finché l’amministratore è tecnicamente competente, sembra che non ci siano molti svantaggi in un’installazione a 2 container. Voglio assolutamente avere aggiornamenti dell’interfaccia grafica, ad esempio se sono in viaggio solo con il mio telefono ed esce un importante aggiornamento di sicurezza di Discourse, posso almeno applicarlo senza accesso SSH.

[pfaffman (Jay Pfaffman)]

@rahim123

Finché l’amministratore è tecnicamente competente, non ci sono molti svantaggi in un’installazione a 2 container

Questa è la mia convinzione. Devi solo prestare abbastanza attenzione per sapere quando c’è un aggiornamento di Postgres o Redis che richiede la ricostruzione del container dati. Devi anche sapere come eseguire ./launcher bootstrap web_only && ./launcher destry web_only; ./launcher start web_only, ma non è così difficile. Puoi semplicemente eseguire ./launcher rebuild web_only, ma questo mette offline il sito mentre viene ricostruito.

[mcdanlj (Michael K Johnson)]

Per completezza: la build dell’interfaccia web normalmente non ha tempi di inattività; il bootstrap/destroy/start ha tempi di inattività minimi e lo farei solo normalmente con una pagina di manutenzione fornita esternamente come con nginx esterno come documentato qui. Ma questa è comunque una buona prassi, anche solo per inserire gli indirizzi IPv6 nel container.

[rahim123]

Molto bene, grazie. E con un’installazione a 2 container si ricevono ancora le notifiche della dashboard di Discourse quando il container deve essere ricostruito? E in quel caso potrei determinare se ricostruire solo l’app o anche il container dei dati?

[mcdanlj (Michael K Johnson)]

Sì. Lo vedo adesso perché non ho applicato l’aggiornamento “è cambiata solo la versione” 3.1.0.beta1.

[mcdanlj (Michael K Johnson)]

Questo è un caso di “va tutto bene finché non va più bene” — le persone vanno nel panico quando l’aggiornamento fallisce nell’interfaccia utente e non sanno di dover eseguire git pull; ./launcher rebuild app per aggirare il problema. Questo accade ogni volta che c’è una modifica che invalida l’aggiornamento dell’interfaccia grafica, credo. È successo di nuovo:

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 …

Ritengo che questo panico metta in evidenza il valore di avere un meccanismo di aggiornamento coerente e normale che eviti questa esperienza.

Allo stesso tempo, ho riscontrato il caso, anch’esso infrequente, in cui il bootstrap rompe il sistema in esecuzione: gli aggiornamenti con tempi di inattività quasi nulli occasionalmente si rompono in questo modo, una o due volte all’anno forse in media? Quindi non ritardare tra il bootstrap e il 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.

Dovrei aggiornare il testo per renderlo chiaro, quindi lo farò dopo.

[mcdanlj (Michael K Johnson)]

Non ho ancora distribuito LibreTranslate, ma sto pensando di farlo per rendere il mio sito più disponibile a livello internazionale.

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 ci riuscirò, ho intenzione di inserirlo nel post principale.

[stephtara (Stephanie Booth)]

Molto di questo mi sfugge, ma voglio ringraziarti, perché le poche impostazioni che menzioni con suggerimenti di regolazione e una spiegazione delle conseguenze su come funziona la community mi sono già state super preziose!

[mcdanlj (Michael K Johnson)]

Sono contento che sia stato utile anche al di fuori del mio pubblico di destinazione dichiarato. L’ho usato un paio di giorni fa per avviare una nuova istanza di Discourse, e anche a me è stato d’aiuto, perché non ricordo tutto questo da solo.

[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

Penso che ci possa essere un problema con la configurazione di THP nella wiki.

Stavo riscontrando problemi con Redis su 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

Credevo che THP fosse già disabilitato (seguendo la wiki), ma si è scoperto che era ancora abilitato . Disabilitare THP ha finito per risolvere il problema sopra per me, se ricordo bene (tardo l’anno scorso).

---

Ubuntu 24.04 LTS (seguendo la wiki corrente):

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 (seguendo la wiki corrente):

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

---

Forse questo sarebbe adatto per la wiki? Sembra aver funzionato su Ubuntu 24.04 e AlmaLinux 10 dai test effettuati ora:

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

Per confermare:

cat /sys/kernel/mm/transparent_hugepage/enabled

Output previsto:

always madvise [never]

[Ed_S]

@markersocial

Disabilitare THP ha risolto il problema per me

Sono lieto di sentirlo: se non sappiamo se aiuta, potremmo starci solo imitando a vicenda!

[mcdanlj (Michael K Johnson)]

Non credo che /etc/sysctl.d sia stato deprecato. Puoi controllare gli altri file elencati lì e vedere quale/i sta sovrascrivendo /etc/sysctl.d/10-huge-pages.conf? Forse uno di quei file 50-priority?

La soluzione migliore sarà probabilmente cambiare la priorità dell’impostazione delle pagine enormi (huge-pages) per prevalere. Ma al momento non sto eseguendo nessuna di quelle versioni sui miei sistemi.

Verifica anche se tuned sta sovrascrivendo l’impostazione.

[markersocial]

Ho riscontrato problemi solo con l’applicazione della configurazione THP, vm.overcommit.memory è stata applicata come previsto tramite /etc/sysctl.d. Questo è stato notato e risolto su un server alla fine dell’anno scorso. Quindi ho provato a verificare tramite un paio di micro VPS ieri.

Ho appena provato questo su un nuovo micro VPS AlmaLinux 9, nel tentativo di vedere se uno dei file .conf predefiniti sta influenzando la configurazione THP:

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

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

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

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

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

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

[mcdanlj (Michael K Johnson)]

@markersocial

Ho avuto problemi solo con l’applicazione della configurazione THP, vm.overcommit.memory è stata applicata come previsto tramite /etc/sysctl.d

Ecco perché ti chiedo di esaminare i file effettivi per trovare cosa lo sta sovrascrivendo, in modo che io possa apportare una modifica informata alla priorità che raccomando per la sovrascrittura.

[markersocial]

La mia attuale (limitata) comprensione è che i comandi/output del mio post precedente indicano che non c’è alcuna sovrascrittura.

Esaminando i file su una nuova istanza di AlmaLinux 9:

Questi sono risultati vuoti:

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

Valori predefiniti nei file di configurazione:

/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

Scorrendo i file su una nuova istanza AlmaLinux 9:

Eseguo AlmaLinux 9 per le mie istanze Discourse e la configurazione che ho fornito ha disabilitato con successo THP su tutte quante. Se la disabilitazione di THP tramite sysctl.d non funziona quando non ci sono override in atto, e tuned non la sta sovrascrivendo, penserei che sia un bug.

Pensavo stessi dicendo che non funzionava più su AlmaLinux 10, motivo per cui chiedevo cosa impedisse la sua applicazione lì.