Nginx-Konfiguration:
Hinter einem Reverse-Proxy (haproxy) müssen Sie die Datei /var/discourse/config/nginx-config-sample.conf nach /etc/nginx/sites-enabled/discourse.conf oder ein ähnliches Ziel kopieren, dann listen <yourreverseproxyport> (falls erforderlich) und das _ von server_name durch Ihren Hostnamen (subdomain.example.com) ersetzen. Sonst nichts ändern.
Seiten werden nicht angezeigt (“Oops”-Nachricht) und E-Mail-Admin-Registrierung funktioniert nicht:
Magick war die Ursache dafür, dass nach den Admin-Registrierungsseiten beim ersten Start keine Seiten angezeigt wurden. Ich folgte der im Log angegebenen Datei: /var/www/discourse/lib/letter_avatar.rb:112. In Zeile 112 gab es zwei magick-Befehle, die tatsächlich nicht reagierten. convert reagierte, also ersetzte ich magick in dieser Zeile durch convert. Nach diesen Korrekturen wurde ein weiterer Fehler protokolliert. Wenn ich das gleiche Verfahren mit dem angegebenen Befehl aus der Datei versuchte, funktionierte der magick-Befehl nicht und convert schlug fehl. HINWEIS: magick --version war 7.x und convert --version ergab 6.x. Die Ursache war, dass ich zuerst imagemagick mit apt installiert hatte und dann Magick 7 aus dem Quellcode. Es gab einige Konflikte und Magick sagte dem convert-Befehl, er sei veraltet. Also startete ich mein Skript nur mit Magick 7 neu. Dies löste das Problem sofort und ich konnte die brandneuen Seiten sehen, auf die ich tagelang gewartet hatte, und auch die E-Mail funktionierte! Magick ist wirklich magisch.
Das Problem mit gemischten Inhalten bleibt bestehen, aber die Website funktioniert trotzdem gut.
HINWEIS: In puma.rb muss die Zeile bind ENV.fetch("PUMA_BIND", "tcp://#{ENV['PUMA_BIND_ALL'] ? '' : '127.0.0.1:'}3000") wie folgt aussehen (Korrektur des ersten Beitrags).
BEARBEITUNG “3.”, bezüglich HTTPS-Erzwingung für Discourse: Ich weiß nicht genau warum, aber meine Browser zeigen keine Warnungen wegen “gemischtem Inhalt” mehr an (vielleicht wegen der Cache-Aktualisierung), also ist jetzt alles in Ordnung. Ich muss nur noch mein Skript fertigstellen.
Funktioniert bestätigt!!!
ImageMagick v7 löst das Ooops-Problem!
Soweit ich getestet habe, funktioniert es einwandfrei.
Ich werde die restlichen Funktionen testen und so schnell wie möglich berichten.
Was ich zum Testen getan habe, war, die Umgebungsvariable PUMA_BIND beim Ausführen von Puma zu setzen.
Bezüglich ImageMagick schlägt Discourse aus irgendeinem Grund fehl, eine Bildkonvertierung in der WebUI auszuführen. Wenn ich ein großes Bild hochlade, weigert es sich freundlicherweise, es zu konvertieren… Ich debugge das Problem immer noch.
Gibt es Fortschritte beim Debugging? Ich arbeite meinerseits an Magick.
Bei einigen Bildern von etwa 50 KB wird im Browser ein Popup angezeigt: timeout -k 40.0 20 magick gif:/tmp/RackMultipart20250927-23598-xrrp6e.gif -auto-orient -background white -interlace none -flatten -debug all -quality 90 jpg:/tmp/image20250927-23598-9ujq3d.jpg und es wird kein Bild geladen
Bei größeren Größen erscheint kein Popup, aber das Laderad dreht sich unendlich lange im Kreis, ohne Ergebnis. Es werden keine Fehler in /var/www/discourse/log protokolliert.
Die einzige Möglichkeit, wie ich es zum Laufen gebracht habe, war die Verwendung von ImageMagick aus dem Brew-Repository.
ABER es schlägt fehl, wenn das Bild mehr als 3 MB groß war… vielleicht habe ich eine sehr restriktive Policy-Konfiguration eingerichtet.
Probieren Sie es aus!!!
Ich teste die Docker-Installation, aber ich glaube, oder es ist ziemlich dumm, Nginx, Unicorn, Redis, PostgreSQL und den Rest in NUR einem Container bereitzustellen… das ergibt überhaupt keinen Sinn. Und es gibt keine Infrastrukturdokumentation für große Bereitstellungen… Ich arbeite seit mehr als 20 Jahren im IT-Bereich und sehe nur Probleme in naher Zukunft, wenn solche Infrastrukturen genutzt werden.
Ganz zu schweigen von „Docker The Space Eater“ (wie Dormammu)
Dieses Problem ist mit der folgenden Lösung am Ende behoben:
Debug 1: bundle db:create gibt Folgendes aus, auch in den Logs beim ersten Start:
…
unknown OID 21096: failed to recognize type of ‘embeddings’. It will be treated as String.
pngquant worker: pngquant not found; please provide proper binary or disable this worker (–no-pngquant argument or :pngquant => false through options)
oxipng worker: oxipng not found; please provide proper binary or disable this worker (–no-oxipng argument or :oxipng => false through options)
jhead worker: jhead not found, jpegtran not found; please provide proper binary or disable this worker (–no-jhead argument or :jhead => false through options)
jpegoptim worker: jpegoptim not found; please provide proper binary or disable this worker (–no-jpegoptim argument or :jpegoptim => false through options)
…
Debug 2: Einige magick-Befehle mit Dateien geben Folgendes aus:
Danach kann meine Upload-Größe bis zu 518KB betragen. Darüber hinaus nicht. Dies gilt nur für Bilder. Alle anderen Dokumente, Audio- und Video-Uploads funktionieren.
Temporäre Lösung für das verbleibende Problem:
Ich habe in den Admin-Einstellungen, discourse.conf, nginx/sites-enables/discourse.conf, im Git-Ordner nachgesehen. Schließlich habe ich im AdminPanel/Parameter/Dateien die Option “Composer media optimization image enabled” deaktiviert, dann funktioniert alles einwandfrei. Ich kann jedes Bild hochladen.
Ja, IMEI ist fast die gleiche Lösung wie die Verwendung von Brew, aber ich bin sicher, dass es nicht ungefähr 2 GB Speicherplatz beanspruchen wird
Ich werde Ihre Lösung für die maximale Dateigröße bei Uploads überprüfen.
Ich kämpfe auch mit einer Lösung, um E-Mails „kostenlos“ zu versenden (ich bin in einem frühen Stadium und möchte keine E-Mail-Dienste wie Mailtrap/Mailgun/etc. abonnieren).
Warum installieren Sie keinen Mailserver? Ich habe meinen eigenen und habe die Installation skriptet. Sagen Sie mir Bescheid, wenn Sie interessiert sind.
Ich habe festgestellt, dass der folgende Fehler auftritt:
bundler: failed to load command: puma (/home/mry/.rbenv/versions/3.4.6/bin/puma)
/home/mry/.rbenv/versions/3.4.6/lib/ruby/gems/3.4.0/gems/puma-7.0.4/lib/puma/cluster.rb:472:in 'Puma::Cluster#run': undefined method 'wait_readable' for nil (NoMethodError)
if read.wait_readable([0, @next_check - Time.now].max)
^^^^^^^^^^^^^^
from /home/mry/.rbenv/versions/3.4.6/lib/ruby/gems/3.4.0/gems/puma-7.0.4/lib/puma/launcher.rb:202:in 'Puma::Launcher#run'
from /home/mry/.rbenv/versions/3.4.6/lib/ruby/gems/3.4.0/gems/puma-7.0.4/lib/puma/cli.rb:73:in 'Puma::CLI#run'
from /home/mry/.rbenv/versions/3.4.6/lib/ruby/gems/3.4.0/gems/puma-7.0.4/bin/puma:10:in '<top (required)>'
from /home/mry/.rbenv/versions/3.4.6/bin/puma:25:in 'Kernel#load'
from /home/mry/.rbenv/versions/3.4.6/bin/puma:25:in '<top (required)>'
from /home/mry/.rbenv/versions/3.4.6/lib/ruby/gems/3.4.0/gems/bundler-2.6.4/lib/bundler/cli/exec.rb:59:in 'Kernel.load'
from /home/mry/.rbenv/versions/3.4.6/lib/ruby/gems/3.4.0/gems/bundler-2.6.4/lib/bundler/cli/exec.rb:59:in 'Bundler::CLI::Exec#kernel_load'
from /home/mry/.rbenv/versions/3.4.6/lib/ruby/gems/3.4.0/gems/bundler-2.6.4/lib/bundler/cli/exec.rb:23:in 'Bundler::CLI::Exec#run'
from /home/mry/.rbenv/versions/3.4.6/lib/ruby/gems/3.4.0/gems/bundler-2.6.4/lib/bundler/cli.rb:452:in 'Bundler::CLI#exec'
from /home/mry/.rbenv/versions/3.4.6/lib/ruby/gems/3.4.0/gems/bundler-2.6.4/lib/bundler/vendor/thor/lib/thor/command.rb:28:in 'Bundler::Thor::Command#run'
from /home/mry/.rbenv/versions/3.4.6/lib/ruby/gems/3.4.0/gems/bundler-2.6.4/lib/bundler/vendor/thor/lib/thor/invocation.rb:127:in 'Bundler::Thor::Invocation#invoke_command'
from /home/mry/.rbenv/versions/3.4.6/lib/ruby/gems/3.4.0/gems/bundler-2.6.4/lib/bundler/vendor/thor/lib/thor.rb:538:in 'Bundler::Thor.dispatch'
from /home/mry/.rbenv/versions/3.4.6/lib/ruby/gems/3.4.0/gems/bundler-2.6.4/lib/bundler/cli.rb:35:in 'Bundler::CLI.dispatch'
from /home/mry/.rbenv/versions/3.4.6/lib/ruby/gems/3.4.0/gems/bundler-2.6.4/lib/bundler/vendor/thor/lib/thor/base.rb:584:in 'Bundler::Thor::Base::ClassMethods#start'
from /home/mry/.rbenv/versions/3.4.6/lib/ruby/gems/3.4.0/gems/bundler-2.6.4/lib/bundler/cli.rb:29:in 'Bundler::CLI.start'
from /home/mry/.rbenv/versions/3.4.6/lib/ruby/gems/3.4.0/gems/bundler-2.6.4/exe/bundle:28:in 'block in <top (required)>'
from /home/mry/.rbenv/versions/3.4.6/lib/ruby/gems/3.4.0/gems/bundler-2.6.4/lib/bundler/friendly_errors.rb:117:in 'Bundler.with_friendly_errors'
from /home/mry/.rbenv/versions/3.4.6/lib/ruby/gems/3.4.0/gems/bundler-2.6.4/exe/bundle:20:in '<top (required)>'
from /home/mry/.rbenv/versions/3.4.6/bin/bundle:25:in 'Kernel#load'
from /home/mry/.rbenv/versions/3.4.6/bin/bundle:25:in '<main>'
Dann startet Puma sich neu. Was kann ich tun, um dies zu verhindern?
Bearbeitet: Dies scheint ein Problem von Puma seit Ruby 3.4.0 zu sein. Gelöst durch Deaktivieren von YJIT.
