Discourse installieren: Unterschied zwischen den Versionen
KKeine Bearbeitungszusammenfassung |
KKeine Bearbeitungszusammenfassung |
||
Zeile 272: | Zeile 272: | ||
Environment="MALLOC_ARENA_MAX=2" | Environment="MALLOC_ARENA_MAX=2" | ||
ExecStart=%h/.rbenv/shims/bundle exec sidekiq -C %h/discourse/config/sidekiq.yml | ExecStart=%h/.rbenv/shims/bundle exec sidekiq -C %h/discourse/config/sidekiq.yml | ||
StandardOutput= | StandardOutput=append:%h/var/log/sidekiq.out.log | ||
StandardError=inherit | StandardError=inherit | ||
Restart=always | Restart=always | ||
Zeile 297: | Zeile 297: | ||
Environment="MALLOC_ARENA_MAX=2" | Environment="MALLOC_ARENA_MAX=2" | ||
ExecStart=%h/.rbenv/shims/bundle exec puma -C config/puma.rb -e production -b tcp://127.0.0.1:13000 | ExecStart=%h/.rbenv/shims/bundle exec puma -C config/puma.rb -e production -b tcp://127.0.0.1:13000 | ||
StandardOutput= | StandardOutput=append:%h/var/log/puma.out.log | ||
StandardError=inherit | StandardError=inherit | ||
Restart=always | Restart=always |
Aktuelle Version vom 25. November 2024, 11:42 Uhr
Für Managed Server
Ein funktionierender Discourse-Server erfordert mehrere laufende Server-Dienste. Für den Betrieb ist ein Managed Server sinnvoll.
Support von der Discourse-Community
Die Discourse-Entwickler haben sich entschieden, nur eine mehr oder weniger genormte Installationsmethode (via docker) zu unterstützen. Dies ist so auf der hostsharing-Architektur aufgrund mehrerer Bedenken und Überlegungen nicht möglich. Die Community ist durchaus hilfreich, geht aber davon aus, dass quasi alle Nutzer* eine "supported"e Installation durchgeführt haben. Wenn man in entsprechenden Kanälen nach Hilfe fragt, sollte man unbedingt erwähnen, dass man discourse selber anhand dieser hier lesbaren Anleitung installiert hat, um bereits entsprechenden Kommentaren und Nachfragen vorzugreifen.
Über
In diesem Artikel wird die Installation von discourse, Version 2.1.0 (September 2018) beschrieben.
Vorbereitungen
Mit Hilfe von HSAdmin wird angelegt:
- Ein User als Service-User mit /bin/bash als Shell, zum Beispiel Beispiel: xyz00-discourse
- Eine Domain mit xyz00-discourse' als Domain-Administrator, zum Beispiel beispiel.discussion
- Einen Postgresql-User xyz00_discourseuser mit Passwort meinPasswort
- Eine Postgresql-Datenbank xyz00_discoursedb mit Datenbank-Owner xyz00_discourseuser
Verwendete IP-Ports der Server-Dienste:
- Redis: localhost:32002
- Discourse-Web: localhost:13000
Konfiguration der PostgreSQL Datenbank
PostgreSQL Extensions
Die PostgreSQL-Datenbank braucht die extensionshstore
, pg_trgm
und unaccent
. Diese müssen vom hostsharing-support installiert werden.
Ansonsten liefe die Erstellung der Datenbank so:
# su - postgres -c psql
CREATE DATABASE discourse;
CREATE USER discourse;
ALTER USER discourse WITH ENCRYPTED PASSWORD 'password';
ALTER DATABASE discourse OWNER TO discourse;
\connect discourse
CREATE EXTENSION hstore;
CREATE EXTENSION pg_trgm;
CREATE EXTENSION unaccent;
Entsprechende Funktionalität (von den extensions abgesehen) ist auch über den HSAdmin verfügbar.
Konfiguration des Redis Server
Firewall/Redis Port
Leider unterstützt discourse nicht die Kommunikation mit Redis über Unix-Sockets. Dementsprechend muss der für Redis konfigurierte Port von dem hostsharing-Support in der Firewall freigegeben werden.
cd
mkdir redis/etc redis/lib redis/log redis/run
Anlegen einer Datei /home/pacs/xyz00/users/discourse/redis/etc/redis.conf mit folgendem Inhalt:
daemonize no
pidfile /home/pacs/xyz00/users/discourse/redis/run/redis-server.pid
port 32002
tcp-backlog 128
bind 127.0.0.1
timeout 300
loglevel notice
logfile /home/pacs/xyz00/users/discourse/redis/log/redis.log
databases 16
save 900 1
save 300 10
save 60 10000
slave-serve-stale-data yes
appendonly no
dbfilename dump.rdb
dir /home/pacs/xyz00/users/discourse/redis/lib
Für Discourse 3.x gilt: "Discourse requires Redis 6.2.0 or up"
Für Debian Buster und Bullseye ist daher das Installieren eines neueren Binaries erforderlich. Bei Debian Bookwork ist bereits Redis 7.0 enthalten (siehe https://packages.debian.org/search?keywords=redis-server).
Hier steht ein entsprechendes Binary für Debian Buster zur Verfügung, das mit dem Public Key von Timotheus geprüft werden kann:
- https://download.solidcharity.com/tarballs/tpokorra/hostsharing/redis-server-6.2.12-debian-buster.tar.gz
- Prüfsignatur: https://download.solidcharity.com/tarballs/tpokorra/hostsharing/redis-server-6.2.12-debian-buster.tar.gz.sig
Prüfen der Signatur:
gpg --verify redis-server-6.2.12-debian-buster.tar.gz.sig redis-server-6.2.12-debian-buster.tar.gz
Das Binary muss nach $HOME/bin
verschoben werden, und entsprechend beim Starten des Dienstes eingetragen werden.
Installation von Ruby
Als User xyz00-discourse: Installation von Ruby mit rbenv mit folgenden Befehlen:
Zunächst rbenv and ruby-build:
git clone https://github.com/rbenv/rbenv.git ~/.rbenv
cd ~/.rbenv && src/configure && make -C src
echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.profile
echo 'eval "$(rbenv init -)"' >> ~/.profile
starte neue Shell:
exec bash
Überprüfe rbenv-Installation
type rbenv
Installiere ruby-build als rbenv-Plugin
git clone https://github.com/rbenv/ruby-build.git ~/.rbenv/plugins/ruby-build
Nun kann die benötigte Ruby-Version installiert werden:
rbenv install 2.4
Installation von Discourse selber
Weiterhin Als User xyz00-discourse:
cd ~
git clone https://github.com/discourse/discourse.git discourse
cd ~/discourse
Die stabile Version auschecken:
git checkout stable
Ruby Pakete installieren:
gem install bundler
bundle install -j$(getconf _NPROCESSORS_ONLN) --deployment --without development test
Konfiguration der Discourse Software
Anlegen einer Datei /home/pacs/xyz00/users/discourse/discourse/config/discourse.conf anhand der Beispiel-Datei:
cd ~/discourse
cp config/discourse_defaults.conf config/discourse.conf
Anpassen folgender Inhalte:
db_host = 127.0.0.1
db_port = 5432
#db_backup_port = 5432 #(auskommentieren)
db_name = xyz00_discoursedb
db_username = xyz00_discourseuser
db_password = "" #db password
hostname = "discourse.xyz00" # hostname
smtp_address = localhost
smtp_enable_start_tls = false
smtp_openssl_verify_mode = 'none'
developer_emails = # your email-address
redis_host = 127.0.0.1
redis_port = 32002
TODO: Secrets setzen!
Die Zufallswerte für die Variablen SECRET_KEY_BASE und OTP_SECRET erzeugt man durch zwei Aufrufe des Kommandos
RAILS_ENV=production bundle exec rake secret
Sidekiq für Hintergrund-Aufgaben konfigurieren
config/sidekiq.conf
Wichtig: development auf production ändern.
Mit diesem Dienst werden z.B. die E-Mails zur Aktivierung oder zum Passwort Reset verschickt.
Problem mit Content Security Policy
Um ein Problem mit Content Security Policy zu lösen, weil manche Dateien über http nachgeladen werden, muss in der Datei config/site_settings.yml
der Default Wert für force_https auf True gesetzt werden:
force_https:
default: true
Problem beim Aufsetzen der Datenbank vermeiden
→ Notiz Mai 2024: dies scheint aktuell nicht aufzutreten.
Aus irgendeinem Grund wird beim Initialisieren der Datenbank versucht, den TYPE hotlinked_media_status zweimal in der Datenbank anzulegen. Der Grund ist nicht ersichtlich.
Es kann folgende Änderung an der Datei db/migrate/20220428094026_create_post_hotlinked_media.rb
vorgenommen werden:
reversible do |dir|
dir.up { execute <<~SQL }
DO $$ BEGIN CREATE TYPE hotlinked_media_status AS ENUM('downloaded', 'too_large', 'download_failed', 'upload_create_failed'); EXCEPTION WHEN duplicate_object THEN null; END $$;
SQL
dir.down { execute <<~SQL }
DROP TYPE hotlinked_media_status
SQL
end
Initialisieren der Datenbank
export SAFETY_ASSURED=1
# In Version 2.0.4 funktioniert db:migrate noch, ansonsten db:schema:load und seed nutzen!
# In Version 3.0.3 funktioniert db:migrate auch noch, db:schema:load ging nicht weil die Datei structure.sql fehlte
#RAILS_ENV=production bundle exec rails db:schema:load
#RAILS_ENV=production bundle exec rails db:seed
RAILS_ENV=production bundle exec rails db:migrate
Kompilieren der Assets
RAILS_ENV=production bundle exec rails assets:precompile
Konfiguration des Web-Servers (am Beispiel Puma)
Die Datei config/puma.conf anpassen (hier nur Änderungen angezeigt):
APP_ROOT = '/home/pacs/xyz00/users/discourse/discourse'
daemonize false
Starten der Dienste
Zum Start aller notwendigen Dienste sollte systemd benutzt werden.
Die folgenden Dateien müssen nach .config/systemd/user/
kopiert werden (überlange Zeilen werden hier im Wiki umgebrochen)
redis.service:
[Unit]
Description=Redis User Service
[Service]
WorkingDirectory=%h/var/redis
Environment="PATH=/usr/local/bin:/usr/bin:/bin"
ExecStart=%h/bin/redis-server %h/etc/redis.conf
Restart=always
PrivateTmp=true
NoNewPrivileges=true
[Install]
WantedBy=default.target
sidekiq.service:
[Unit]
Description=Discourse Sidekiq Service
[Service]
WorkingDirectory=%h/discourse
Environment="PATH=/usr/local/bin:/usr/bin:/bin"
Environment="RAILS_ENV=production"
Environment="DB_POOL=8"
Environment="MALLOC_ARENA_MAX=2"
ExecStart=%h/.rbenv/shims/bundle exec sidekiq -C %h/discourse/config/sidekiq.yml
StandardOutput=append:%h/var/log/sidekiq.out.log
StandardError=inherit
Restart=always
PrivateTmp=true
NoNewPrivileges=true
[Install]
WantedBy=default.target
After=redis.service
discourse.service:
[Unit]
Description=Discourse Web Service
[Service]
WorkingDirectory=%h/discourse
Environment="PATH=/usr/local/bin:/usr/bin:/bin"
Environment="RAILS_ENV=production"
Environment="WEB_CONCURRENCY=2"
Environment="MAX_THREADS=5"
Environment="MALLOC_ARENA_MAX=2"
ExecStart=%h/.rbenv/shims/bundle exec puma -C config/puma.rb -e production -b tcp://127.0.0.1:13000
StandardOutput=append:%h/var/log/puma.out.log
StandardError=inherit
Restart=always
PrivateTmp=true
NoNewPrivileges=true
[Install]
WantedBy=default.target
After=redis.service
Einrichten des Apache VHost
cd ~/doms/beispiel.discuss
rm -rf htdocs-ssl subs/www subs-ssl/www
ln -s ~/live/public htdocs-ssl
touch htdocs-ssl/.htaccess
Dann die htdocs-ssl/.htaccess (durch das gelinkte Verzeichnis entspricht das dem Pfad /home/pacs/xyz00/users/discourse/discourse/public/.htaccess ) mit dem Editor der Wahl öffnen und folgende Konfiguration einfügen:
DirectoryIndex disabled
RequestHeader set X-Forwarded-Proto "https"
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule .* http://127.0.0.1:13000%{REQUEST_URI} [proxy,last]
Wartung
Backup
Discourse macht selbstätig backups und legt diese unter 'public/backups' ab. Enthalten ist ein Datenbank-Dump und die hochgeladenen Dateien.
Im Admin-Bereich lassen sich backups auch manuell antreten.
Admin Benutzer einladen
Manchmal brauchen wir einen neuen Admin Benutzer, den wir von der Kommandozeile aus einladen möchten.
cd /discourse
RAILS_ENV=production rake admin:invite[admin@example.org]
Import aus mbox Archiven
Um zum Beispiel ein Mailman2 Archiv zu importieren, wo die Nachrichten als .mbox Datei vorliegen, sind folgende Schritte nötig:
Vorbereitungen an Discourse:
source .profile
cd discourse
bundle config set frozen false
IMPORT=1 bundle install
bundle config set frozen true
nano script/import_scripts/mbox/settings.yml
# dort ändern:
# data_dir: /home/pacs/xyz00/users/discourse/list-archiv
Hochladen der Mailinglisten-Archive:
mkdir ~/list-archiv
# dort muss es Unterordner mit dem Namen der gewünschten Kategorie geben,
# und die mbox Datei muss auch diesen Namen haben, z.B.:
# ~/list-archiv/beispiel/beispiel.mbox
# ~/list-archiv/example/example.mbox
# um die Beiträge in den entsprechenden Kategorien beispiel und example einzufügen.
Durchführen des Imports:
source .profile
cd discourse
RAILS_ENV=production IMPORT=1 bundle exec rails runner \
script/import_scripts/mbox.rb script/import_scripts/mbox/settings.yml
Export
- Wenn ein Forum beendet wird, möchte man evtl. eine Sicherung als statische HTML Seiten.
- Das wird hier diskutiert: https://meta.discourse.org/t/how-do-i-export-the-complete-forum-as-static-html-pages/71007/3
- Um ein Forum von Discourse zu Flarum umzuziehen, hat Timotheus ein Skript geschrieben.
- Das Migrations-Skript: https://github.com/SolidCharity/discourse_to_flarum
- siehe auch https://discuss.flarum.org/d/4930-discourse-to-flarum-migration-support/29
Updates
Discourse wird über update via mail informieren (dies kann man m.W. abschalten).
Achtung: bei größeren Updates auch immer Änderungen an der Datei site_settings.yml (https://github.com/discourse/discourse/blob/main/config/site_settings.yml) beachten!
Am Beispiel von 3.0.3 auf 3.0.5
- Im Web-Backend unter Administration->Backups-> Read-Only Mouds setzen (oder Web Server so konfigurieren, dass keine Zugriffe mehr stattfinden können)
- Backup
- Die lokalen Änderungen sichern:
- cd discourse
- git diff v3.0.3 > diff-3.0.3.txt
- git fetch
- git checkout -b hostsharing-deployment-v3.0.5 v3.0.5
- evtl. Änderungen aus diff-3.0.3.txt wieder übernehmen und committen
- patch -p1 < diff-3.0.3.txt
- git commit -a -m "spezifische Änderungen für diese Instanz" --no-verify
- Schauen, ob discourse (endlich :) ) eine neue Ruby-Version nutzt (z.B. in https://github.com/discourse/discourse/blob/stable/.ruby-version.sample)
- Dies ist der Fall, also
- rbenv install 3.2.1
- rbenv rehash
- echo "3.2.1" > .ruby-version
- source ~/.profile
- gem update --system
- bundle
- yarn install
- RAILS_ENV=production bundle exec rake db:migrate
- RAILS_ENV=production bundle exec rake assets:precompile
- Services neu starten
systemctl --user restart puma
systemctl --user restart sidekiq
systemctl --user restart redis
- Zuletzt: Read-Only Modus wieder deaktivieren
Debugging
Es können folgende Einstellungen in der Datei config/environments/production.rb vorgenommen werden. Danach den Puma Dienst neustarten. Fehlermeldungen und Stacktraces werden dann im Browser ausgegeben.
config.log_level = :debug
config.action_dispatch.show_exceptions = :all
config.action_dispatch.debug_exception_log_level = :error
# Full error reports are enabled and caching is turned off
config.consider_all_requests_local = true
config.action_controller.perform_caching = false
Erforderliche Anpassungen
Weil wir bei Debian Bookworm noch mit ImageMagick 6.9 arbeiten, muss dieser Patch rückgängig gemacht werden:
wget https://github.com/discourse/discourse/commit/17aa831337e352dfd875f1b4ddc4492bd0835119.patch -O ~/imagemagick.patch
patch -p1 --reverse < ~/imagemagick.patch
git commit -a -m "revert imagemagick patch" --no-verify
ToDos
- Ein Patch, um Discourse auch via Unix-Socket mit Redis sprechen lassen zu können dürfte relativ einfach sein (es wird ein Wrapper um das redis-gem genutzt).
- Konfiguration von discourse, um mit postgresql via Unix-Socket zu kommunizieren (DISCOURSE_DB_SOCKET environment variable)
- Performance-tuning an diversen Stellen, anhand der discourse_docker-Vorgaben (https://github.com/discourse/discourse_docker), z.B.
- thpoff (huge page settings)
- unicorn (hat eine wesentlich ausgefeiltere Konfigurations-Vorlage, wahrscheinlich bereits ordentlich optimiert)
Links
- https://help.skysilk.com/support/solutions/articles/9000120927-how-to-install-discourse-without-docker-using-skysilk-vps-
- https://github.com/discourse/discourse_docker
- https://github.com/discourse/discourse
- https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/discourse
Historie
- 2018, 14 . September: Initiale Fassung
- 2019, Januar: Update-Informationen ergänzt
- 2022, Juni: systemd Dienste, Discourse 3.0