Discourse installieren: Unterschied zwischen den Versionen

Aus Hostsharing Wiki
Zur Navigation springen Zur Suche springen
KKeine Bearbeitungszusammenfassung
 
(78 dazwischenliegende Versionen von 7 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
{{Textkasten|gelb|Für Managed Server|Ein funktionierender Discourse-Server erfordert mehrere laufende Server-Dienste. Für den Betrieb ist ein Managed Server sinnvoll.}}
{{Textkasten|gelb|Für Managed Server|Ein funktionierender Discourse-Server erfordert mehrere laufende Server-Dienste. Für den Betrieb ist ein Managed Server sinnvoll.}}


{{Textkasten|rot|Work in Progress|Dieser Artikel soll erklären, wie man discourse installiert, ist allerdings **noch nicht fertig**}}
{{Textkasten|rot|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 ==


{{Textkasten|rot|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.}}
In diesem Artikel wird die Installation von discourse, Version 2.1.0 (September 2018) beschrieben.


== Vorbereitungen ==
== Vorbereitungen ==
Zeile 14: Zeile 16:


Verwendete IP-Ports der Server-Dienste:
Verwendete IP-Ports der Server-Dienste:
# Monit: localhost:32001
# Redis: localhost:32002
# Redis: localhost:32002
# Discourse-Web: localhost:32003
# Discourse-Web: localhost:13000
 
== Konfiguration der PostgreSQL Datenbank ==
 
{{Textkasten|gelb|PostgreSQL Extensions|Die PostgreSQL-Datenbank braucht die extensions <code>hstore</code>, <code>pg_trgm</code> und <code>unaccent</code>. Diese müssen vom hostsharing-support installiert werden.}}
 
Ansonsten liefe die Erstellung der Datenbank so:
<syntaxhighlight lang=sql line>
# 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;
</syntaxhighlight>
 
Entsprechende Funktionalität (von den extensions abgesehen) ist auch über den HSAdmin verfügbar.


== Konfiguration des Redis Server ==
== Konfiguration des Redis Server ==


    cd
{{Textkasten|gelb|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.}}
    mkdir redis/etc redis/lib redis/log redis/run
 
<syntaxhighlight lang=shell>
cd
mkdir redis/etc redis/lib redis/log redis/run
</syntaxhighlight>


Anlegen einer Datei ''/home/pacs/xyz00/users/discourse/redis/etc/redis.conf'' mit folgendem Inhalt:
Anlegen einer Datei ''/home/pacs/xyz00/users/discourse/redis/etc/redis.conf'' mit folgendem Inhalt:


    daemonize no
<syntaxhighlight lang=shell line>
    pidfile /home/pacs/xyz00/users/discourse/redis/run/redis-server.pid
daemonize no
    port 32002
pidfile /home/pacs/xyz00/users/discourse/redis/run/redis-server.pid
    tcp-backlog 128
port 32002
    bind 127.0.0.1
tcp-backlog 128
    timeout 300
bind 127.0.0.1
    loglevel notice
timeout 300
    logfile /home/pacs/xyz00/users/discourse/redis/log/redis.log
loglevel notice
    databases 16
logfile /home/pacs/xyz00/users/discourse/redis/log/redis.log
    save 900 1
databases 16
    save 300 10
save 900 1
    save 60 10000
save 300 10
    slave-serve-stale-data yes
save 60 10000
    appendonly no
slave-serve-stale-data yes
    dbfilename dump.rdb
appendonly no
    dir /home/pacs/xyz00/users/discourse/redis/lib
dbfilename dump.rdb
dir /home/pacs/xyz00/users/discourse/redis/lib
</syntaxhighlight>
 
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:
 
<syntaxhighlight lang=shell>
gpg --verify redis-server-6.2.12-debian-buster.tar.gz.sig redis-server-6.2.12-debian-buster.tar.gz
</syntaxhighlight>
 
Das Binary muss nach <code>$HOME/bin</code> verschoben werden, und entsprechend beim Starten des Dienstes eingetragen werden.


== Installation von Ruby ==
== Installation von Ruby ==
Zeile 48: Zeile 91:
Zunächst ''rbenv'' and ''ruby-build'':
Zunächst ''rbenv'' and ''ruby-build'':


    git clone https://github.com/rbenv/rbenv.git ~/.rbenv
<syntaxhighlight lang=shell line>
    cd ~/.rbenv && src/configure && make -C src
git clone https://github.com/rbenv/rbenv.git ~/.rbenv
    echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.profile
cd ~/.rbenv && src/configure && make -C src
    echo 'eval "$(rbenv init -)"' >> ~/.profile
echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.profile
echo 'eval "$(rbenv init -)"' >> ~/.profile
</syntaxhighlight>


starte neue Shell:
starte neue Shell:


    exec bash
<syntaxhighlight lang=shell>
exec bash
</syntaxhighlight>


Überprüfe rbenv-Installation
Überprüfe rbenv-Installation


    type rbenv
<syntaxhighlight lang=shell>
type rbenv
</syntaxhighlight>


Installiere ruby-build als rbenv-Plugin
Installiere ruby-build als rbenv-Plugin


    git clone https://github.com/rbenv/ruby-build.git ~/.rbenv/plugins/ruby-build
<syntaxhighlight lang=shell>
git clone https://github.com/rbenv/ruby-build.git ~/.rbenv/plugins/ruby-build
</syntaxhighlight>


Nun kann die benötigte Ruby-Version installiert werden:
Nun kann die benötigte Ruby-Version installiert werden:


    rbenv install 2.4
<syntaxhighlight lang=shell>
rbenv install 2.4
</syntaxhighlight>


== Installation von Discourse selber ==
== Installation von Discourse selber ==
Zeile 73: Zeile 126:
Weiterhin Als User ''xyz00-discourse'':   
Weiterhin Als User ''xyz00-discourse'':   


    cd ~
<syntaxhighlight lang=shell>
    git clone https://github.com/discourse/discourse.git discourse
cd ~
    cd ~/discourse
git clone https://github.com/discourse/discourse.git discourse
cd ~/discourse
</syntaxhighlight>


Die stabile Version auschecken:
Die stabile Version auschecken:


    git checkout stable
<syntaxhighlight lang=shell>
git checkout stable
</syntaxhighlight>


Ruby Pakete installieren:
Ruby Pakete installieren:


    gem install bundler
<syntaxhighlight lang=shell>
    bundle install -j$(getconf _NPROCESSORS_ONLN) --deployment --without development test
gem install bundler
bundle install -j$(getconf _NPROCESSORS_ONLN) --deployment --without development test
</syntaxhighlight>


== Konfiguration der Discourse Software ==
== Konfiguration der Discourse Software ==


Anlegen einer Datei ''/home/pacs/xyz00/users/discourse/discourse/live/.env.production'' mit dem folgenden Inhalt:
Anlegen einer Datei ''/home/pacs/xyz00/users/discourse/discourse/config/discourse.conf'' anhand der Beispiel-Datei:


    REDIS_HOST=localhost
<syntaxhighlight lang=shell>
    REDIS_PORT=32002
cd ~/discourse
    DB_HOST=localhost
cp config/discourse_defaults.conf config/discourse.conf
    DB_USER=xyz00_mastuser
</syntaxhighlight>
    DB_NAME=xyz00_mastdb
    DB_PASS=meinPasswort
    DB_PORT=5432
    LOCAL_DOMAIN=beispiel.social
    SECRET_KEY_BASE=12ab..
    OTP_SECRET=34ef..
    VAPID_PRIVATE_KEY=ABCD..
    VAPID_PUBLIC_KEY=EFGH..
    DEFAULT_LOCALE=de
    SMTP_SERVER=localhost
    SMTP_PORT=25
    SMTP_FROM_ADDRESS=notifications@beispiel.social
    SMTP_AUTH_METHOD=none
    SMTP_OPENSSL_VERIFY_MODE=none
    STREAMING_CLUSTER_NUM=1


Anpassen folgender Inhalte:
<syntaxhighlight lang=ini line>
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
</syntaxhighlight>
===TODO: Secrets setzen! ===
Die Zufallswerte für die Variablen SECRET_KEY_BASE und OTP_SECRET erzeugt man durch zwei Aufrufe des Kommandos
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
<syntaxhighlight lang=shell>
RAILS_ENV=production bundle exec rake secret
</syntaxhighlight>


Die Werte für VAPID_PRIVATE_KEY und VAPID_PUBLIC_KEY erzeugt das Kommando
=== Sidekiq für Hintergrund-Aufgaben konfigurieren ===


    RAILS_ENV=production bundle exec rake mastodon:webpush:generate_vapid_key
''config/sidekiq.conf''


Wichtig: development auf production ändern.


Initialisieren der Datenbank:
Mit diesem Dienst werden z.B. die E-Mails zur Aktivierung oder zum Passwort Reset verschickt.


     export SAFETY_ASSURED=1
=== Problem mit Content Security Policy ===
    RAILS_ENV=production bundle exec rails db:schema:load
 
    RAILS_ENV=production bundle exec rails db:seed
Um ein Problem mit Content Security Policy zu lösen, weil manche Dateien über http nachgeladen werden, muss in der Datei <code>config/site_settings.yml</code> der Default Wert für force_https auf True gesetzt werden:
<syntaxhighlight lang=yaml line>
force_https:
    default: true
</syntaxhighlight>
=== 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 <code>db/migrate/20220428094026_create_post_hotlinked_media.rb</code> vorgenommen werden:
<syntaxhighlight lang=ruby line>
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
</syntaxhighlight>
=== Initialisieren der Datenbank ===
 
<syntaxhighlight lang=shell>
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
</syntaxhighlight>
 
=== Kompilieren der Assets ===
 
<syntaxhighlight lang=shell>
RAILS_ENV=production bundle exec rails assets:precompile
</syntaxhighlight>
 
=== Konfiguration des Web-Servers (am Beispiel Puma)  ===
 
Die Datei ''config/puma.conf'' anpassen (hier nur Änderungen angezeigt):
 
<syntaxhighlight lang=ini>
APP_ROOT = '/home/pacs/xyz00/users/discourse/discourse'
daemonize false
</syntaxhighlight>


== Starten der Dienste  ==
== Starten der Dienste  ==


Zum Start aller notwendigen Dienste wird in dieser Anleitung ''monit'' benutzt. Hier ein Beispiel für eine Datei ''.monitrc'' (überlange Zeilen werden hier im Wiki umgebrochen)
Zum Start aller notwendigen Dienste sollte systemd benutzt werden.
 
Die folgenden Dateien müssen nach <code>.config/systemd/user/</code> kopiert werden (überlange Zeilen werden hier im Wiki umgebrochen)
 
redis.service:
 
<syntaxhighlight lang=ini line>
[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
</syntaxhighlight>
 
sidekiq.service:
 
<syntaxhighlight lang=ini line>
[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=file:%h/var/log/sidekiq.out.log
StandardError=inherit
Restart=always
PrivateTmp=true
NoNewPrivileges=true
 
[Install]
WantedBy=default.target
After=redis.service
</syntaxhighlight>
 
discourse.service:
 
<syntaxhighlight lang=ini line>
[Unit]
Description=Discourse Web Service


    set daemon 60
[Service]
        with start delay 120
WorkingDirectory=%h/discourse
    set logfile /home/pacs/xyz00/users/mastodon/monit/var/monit.log
Environment="PATH=/usr/local/bin:/usr/bin:/bin"
    set idfile /home/pacs/xyz00/users/mastodon/monit/var/monit.id
Environment="RAILS_ENV=production"
    set statefile /home/pacs/xyz00/users/mastodon/monit/var/monit.state
Environment="WEB_CONCURRENCY=2"
    set mailserver localhost
Environment="MAX_THREADS=5"
    set mail-format { from: monit@beispiel.social }
Environment="MALLOC_ARENA_MAX=2"
    set alert mastodon@beispiel.social
ExecStart=%h/.rbenv/shims/bundle exec puma -C config/puma.rb -e production -b tcp://127.0.0.1:13000
    set httpd port 32001 address xyz00.hostsharing.net
StandardOutput=file:%h/var/log/puma.out.log
        allow mostodon:monitpassword
StandardError=inherit
    check process redis with pidfile /home/pacs/xyz00/users/mastodon/redis/var/redis-server.pid
Restart=always
        start program "/usr/bin/redis-server /home/pacs/xyz00/users/mastodon/redis/etc/redis.conf"
PrivateTmp=true
        stop program "/bin/bash -c '/bin/kill $( cat /home/pacs/xyz00/users/mastodon/redis/var/redis-server.pid )'"
NoNewPrivileges=true
    check process mstdn_web with pidfile /home/pacs/xyz00/users/mastodon/mastodon/var/puma.pid
 
        depends redis
[Install]
        start program "/bin/bash -c 'export HOME=/home/pacs/xyz00/users/mastodon && cd $HOME/mastodon/live && ( $HOME/.rbenv/shims/bundle exec puma -C config/puma.rb -e production -b tcp://127.0.0.1:32003 >$HOME/mastodon/var/puma.log 2>&1 &  echo $! > $HOME/mastodon/var/puma.pid  )'"
WantedBy=default.target
        stop program "/bin/bash -c '/bin/kill $( cat /home/pacs/xyz00/users/mastodon/mastodon/var/puma.pid )'"
After=redis.service
    check process mstdn_sidekiq with pidfile /home/pacs/xyz00/users/mastodon/mastodon/var/sidekiq.pid
</syntaxhighlight>
        depends redis
        start program "/bin/bash -c 'export RAILS_ENV=production && export DB_POOL=5 && export HOME=/home/pacs/xyz00/users/mastodon && cd $HOME/mastodon/live && ( $HOME/.rbenv/shims/bundle exec sidekiq -c 5 -q default -q mailers -q pull -q push >$HOME/mastodon/var/sidekiq.log 2>&1 &  echo $! > $HOME/mastodon/var/sidekiq.pid  )'"
        stop program "/bin/bash -c '/bin/kill $( cat /home/pacs/xyz00/users/mastodon/mastodon/var/sidekiq.pid )'"
    check process mstdn_streaming with pidfile /home/pacs/xyz00/users/mastodon/mastodon/var/streaming.pid
        depends redis
        start program "/bin/bash -c 'export HOME=/home/pacs/xyz00/users/mastodon && export NVM_DIR="$HOME/.nvm" && export NVM_BIN=/home/pacs/xyz00/users/mastodon/.nvm/versions/node/v6.14.3/bin && export NODE_ENV=production && export PORT=32004 && BIND=127.0.0.1 && cd $HOME/mastodon/live && ( $HOME/.nvm/versions/node/v6.14.3/bin/node streaming/index.js >$HOME/mastodon/var/streaming.log 2>&1 &  echo $! > $HOME/mastodon/var/streaming.pid  )'"
        stop program "/bin/bash -c '/bin/kill $( cat /home/pacs/xyz00/users/mastodon/mastodon/var/streaming.pid )'"


== Einrichten des Apache VHost ==
== Einrichten des Apache VHost ==


    cd ~/doms/beispiel.social
<syntaxhighlight lang=shell>
    rm -rf htdocs-ssl subs/www subs-ssl/www
cd ~/doms/beispiel.discuss
    ln -s ~/live/public htdocs-ssl
rm -rf htdocs-ssl subs/www subs-ssl/www
    touch htdocs-ssl/.htaccess
ln -s ~/live/public htdocs-ssl
touch htdocs-ssl/.htaccess
</syntaxhighlight>


Dann die ''htdocs-ssl/.htaccess'' mit dem Editor der Wahl öffnen und  
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:
folgende Konfiguration einfügen:


    DirectoryIndex disabled
<syntaxhighlight lang=apache line>
    RewriteEngine On
DirectoryIndex disabled
    RewriteBase /
 
    RewriteCond %{REQUEST_URI}  ^/api/v1/streaming    [NC]
RequestHeader set X-Forwarded-Proto "https"
    RewriteRule .* ws://localhost:32004%{REQUEST_URI}  [proxy]
 
    RequestHeader set X-Forwarded-Proto "https"
RewriteEngine On
    RewriteCond %{REQUEST_FILENAME} !-f
RewriteBase /
    RewriteCond %{REQUEST_FILENAME} !-l
RewriteCond %{REQUEST_FILENAME} !-f
    RewriteRule .* http://localhost:32003%{REQUEST_URI} [proxy]
RewriteCond %{REQUEST_FILENAME} !-l
    RequestHeader set X-Forwarded-Proto "https"
RewriteRule .* http://127.0.0.1:13000%{REQUEST_URI} [proxy,last]
</syntaxhighlight>
== Wartung ==
=== Backup ===


== Cronjobs ==
Discourse macht selbstätig backups und legt diese unter 'public/backups' ab. Enthalten ist ein Datenbank-Dump und die hochgeladenen Dateien.


''Cron'' wird für zwei Aufgaben genutzt:
Im Admin-Bereich lassen sich backups auch manuell antreten.
* Start von monit nach einem Server Reboot
* Aufräumen von alten Resourcen


Einrichten der crontab mit ''cronttab -e''
=== Admin Benutzer einladen ===


    HOME=/home/pacs/xyz00/users/mastodon
Manchmal brauchen wir einen neuen Admin Benutzer, den wir von der Kommandozeile aus einladen möchten.
    MAILTO=mastodon@beispiel.social
    RAILS_ENV=production
    NUM_DAYS=31
   
    @reboot /usr/bin/monit -c $HOME/.monitrc
    18 4 * * * cd $HOME/mastodon/live && $HOME/.rbenv/shims/bundle exec rake mastodon:media:remove_remote


== Volltextsuche ==
<syntaxhighlight lang=shell>
cd /discourse
RAILS_ENV=production rake admin:invite[admin@example.org]
</syntaxhighlight>


In der installierten Version gibt es noch keine Volltextsuche. Es kann lediglich nach Nutzerkennungen und Hastags gesucht werden. Für die Volltextsuche kann optional Elasticsearch installiert werden.
=== Import aus mbox Archiven ===
* https://github.com/tootsuite/documentation/blob/master/Running-Mastodon/Elasticsearch-guide.md
 
Um zum Beispiel ein Mailman2 Archiv zu importieren, wo die Nachrichten als .mbox Datei vorliegen, sind folgende Schritte nötig:
 
Vorbereitungen an Discourse:
 
<syntaxhighlight lang=shell>
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
</syntaxhighlight>
 
Hochladen der Mailinglisten-Archive:
<syntaxhighlight lang=shell>
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.
</syntaxhighlight>
 
Durchführen des Imports:
<syntaxhighlight lang=shell>
source .profile
cd discourse
RAILS_ENV=production IMPORT=1 bundle exec rails runner \
    script/import_scripts/mbox.rb script/import_scripts/mbox/settings.yml
</syntaxhighlight>
 
=== 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
<syntaxhighlight lang=shell>
systemctl --user restart puma
systemctl --user restart sidekiq
systemctl --user restart redis
</syntaxhighlight>
* 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.
 
<syntaxhighlight lang="ini" line>
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
</syntaxhighlight>
 
=== Erforderliche Anpassungen ===
Weil wir bei Debian Bookworm noch mit ImageMagick 6.9 arbeiten, muss dieser [https://github.com/discourse/discourse/commit/17aa831337e352dfd875f1b4ddc4492bd0835119 Patch] rückgängig gemacht werden:
 
<syntaxhighlight lang="bash" line>
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
</syntaxhighlight>
 
== 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 ==
== Links ==


* https://github.com/tootsuite/documentation/blob/master/Running-Mastodon/Production-guide.md
* https://help.skysilk.com/support/solutions/articles/9000120927-how-to-install-discourse-without-docker-using-skysilk-vps-
* https://krinetzki.de/2017/04/installation-von-mastodon-auf-debian-8-jessie/
* 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


----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:RubyOnRails]]
[[Kategorie:Webforen]]
[[Kategorie:Ansible Playbook]]

Aktuelle Version vom 30. August 2024, 13:26 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:

  1. Ein User als Service-User mit /bin/bash als Shell, zum Beispiel Beispiel: xyz00-discourse
  2. Eine Domain mit xyz00-discourse' als Domain-Administrator, zum Beispiel beispiel.discussion
  3. Einen Postgresql-User xyz00_discourseuser mit Passwort meinPasswort
  4. Eine Postgresql-Datenbank xyz00_discoursedb mit Datenbank-Owner xyz00_discourseuser

Verwendete IP-Ports der Server-Dienste:

  1. Redis: localhost:32002
  2. Discourse-Web: localhost:13000

Konfiguration der PostgreSQL Datenbank

PostgreSQL Extensions

Die PostgreSQL-Datenbank braucht die extensions hstore, 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:

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=file:%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=file:%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

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

  1. Im Web-Backend unter Administration->Backups-> Read-Only Mouds setzen (oder Web Server so konfigurieren, dass keine Zugriffe mehr stattfinden können)
  2. Backup
  3. Die lokalen Änderungen sichern:
  4. cd discourse
  5. git diff v3.0.3 > diff-3.0.3.txt
  6. git fetch
  7. git checkout -b hostsharing-deployment-v3.0.5 v3.0.5
  8. evtl. Änderungen aus diff-3.0.3.txt wieder übernehmen und committen
  9. patch -p1 < diff-3.0.3.txt
  10. git commit -a -m "spezifische Änderungen für diese Instanz" --no-verify
  11. Schauen, ob discourse (endlich :) ) eine neue Ruby-Version nutzt (z.B. in https://github.com/discourse/discourse/blob/stable/.ruby-version.sample)
  12. Dies ist der Fall, also
  13. rbenv install 3.2.1
  14. rbenv rehash
  15. echo "3.2.1" > .ruby-version
  16. source ~/.profile
  17. gem update --system
  18. bundle
  19. yarn install
  20. RAILS_ENV=production bundle exec rake db:migrate
  21. RAILS_ENV=production bundle exec rake assets:precompile
  22. 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

Historie

  • 2018, 14 . September: Initiale Fassung
  • 2019, Januar: Update-Informationen ergänzt
  • 2022, Juni: systemd Dienste, Discourse 3.0
Abgerufen von „https://wiki.hostsharing.net/index.php?title=Discourse_installieren&oldid=6936“