Hostsharing Wiki - Benutzerbeiträge [de]

Container

2026-09-10T14:33:25Z

Tim00: /* OnlyOffice Documentserver */

== Übersicht ==

Es gibt die Möglichkeit, einen Container Server mit Docker oder mit Podman zu buchen.

Dies ist eine Managed Umgebung, also ohne Root-Rechte, wo Docker bzw. Podman rootless ausgeführt werden.

Falls vom Installationsskript einer Anwendung Root-Rechte erforderlich sind, kann entweder versucht werden, dies anzupassen, oder es kann ein Cloud Server gebucht werden, wo der Benutzer Root-Rechte hat.

== Erste Schritte ==

Bei der Bestellung des Container Servers sollte direkt der Public SSH Key mitgegeben werden, am besten bereits nach dem Ed25519-Standard, siehe auch [https://www.heise.de/tipps-tricks/SSH-Key-erstellen-so-geht-s-4400280.html].

Der Zugriff erfolgt über den Benutzer tallyman über SSH auf den Container Server.

<syntaxhighlight lang=shell>
ssh tallyman@vm4xxx.hostsharing.net
</syntaxhighlight>

Um einen "Hello World" Docker Container zu starten:

<syntaxhighlight lang=shell>
tallyman@vm4xxx:~$ docker run hello-world
</syntaxhighlight>

Entsprechend sieht der Befehl für Podman aus:

<syntaxhighlight lang=shell>
tallyman@vm4xxx:~$ podman run hello-world
</syntaxhighlight>

=== Hilfreiche Befehle für Docker ===

<syntaxhighlight lang=shell>
# in einem Ordner ausführen, wo eine Datei mit dem Namen docker-compose.yml liegt, um die Umgebung zu bauen und zu starten:
docker compose up --detach

# zeige alle laufenden Container
docker ps -a

# zeige die Logs eines Containers
docker logs mein-container

# wechsle in eine Shell im Container
docker exec -t -i mein-container /bin/sh

# Images aktualisieren
docker compose pull

# Containerumgebung stoppen und löschen
docker compose down
</syntaxhighlight>

=== Hilfreiche Befehle für Podman ===

Viele Befehle sind ähnlich wie bei Docker.

<syntaxhighlight lang=shell>
# in einem Ordner ausführen, wo eine Datei mit dem Namen compose.yaml liegt, um die Umgebung zu bauen und zu starten:
podman-compose up -d

# zeige alle laufenden Container
podman ps -a

# zeige die Logs eines Containers
podman logs mein-container

# wechsle in eine Shell im Container
podman exec -t -i mein-container /bin/sh

# Images aktualisieren
podman-compose pull

# Containerumgebung stoppen und löschen
docker-compose down
</syntaxhighlight>

Es ist aber zu empfehlen, nicht mit compose zu arbeiten, sondern mit Quadlets. Dabei sind die Container direkt in systemd Userspace eingebettet, und werden mit den richtigen Abhängigkeiten definiert und dann auch bei einem Reboot gestartet.

Siehe auch die Beispiele unten.

Es müssen die container und network Dateien in ~/.config/containers/systemd hinterlegt werden, und dann können die Service Dateien erzeugt werden:

<syntaxhighlight lang=shell>
# eigentlich müsste dieser Befehl die service Dateien in ~/.config/systemd/user/ neu erzeugen, aber es geht irgendwie nicht.
systemctl --user daemon-reload

# manuell:
/usr/lib/systemd/system-generators/podman-system-generator --user ~/.config/systemd/user
systemctl --user daemon-reload
</syntaxhighlight>

== Integration in Hostsharing Managed Platform ==

=== Subdomain einrichten ===

Wir haben bereits die Hauptdomain bei Hostsharing gebucht.

Nun soll unsere Anwendung auf dem Container Server auf einer Subdomain laufen.

Wir benutzen einen Caddy Container, um Letsencrypt bereitszustellen (siehe in den Beispielen unten).

Auf der Managed Umgebung müssen wir das Zonefile anpassen, um die Subdomain per A und AAAA Eintrag auf den Container Server zu verweisen.

Mit dem Befehl <code>dig</code> ermitteln wir die ipv4 und ipv6 Adressen unseres Container Servers:

<syntaxhighlight lang=shell>
dig -t A +short vm4xxx.hostsharing.net
dig -t AAAA +short vm4xxx.hostsharing.net
</syntaxhighlight>

Auf der Managed Umgebung, legen wir ein Zonefile an. Siehe auch die Anleitung im Handbuch: https://www.hostsharing.net/doc/managed-operations-platform/zonefile/

<code>doms/meinedomain.de/etc/pri.meinedomain.de</code>:

<syntaxhighlight lang=text>
{DEFAULT_ZONEFILE}

meinesubdomain IN A 83.223.xx.xxx
meinesubdomain IN AAAA 2a01:xx:xxxx::xxxx:xxxx:0
</syntaxhighlight>

=== Tunnel zur Managed Datenbank einrichten ===

Wir lassen die Anwendung auf dem Container Server laufen. Dort kann natürlich auch die Datenbank laufen, in einem eigenen Container.

Wir haben aber auch Datenbanken in der Managed Umgebung von Hostsharing, mit allen Vorteilen (regelmäßiges Backup, usw.).

Wenn wir eine managed Datenbank aus der Managed Umgebung auf dem Container Server einbinden wollen, sind folgende Schritte notwendig:

* Es muss ein Tunnel eingerichtet werden, damit die Datenbank vom Container Server aus erreichbar ist.

Datei .config/systemd/user/sshtunnel.service:

<syntaxhighlight lang=shell>
[Unit]
Description=SSH Tunnel zu Managed Webspace
After=network.target

[Service]
Environment="LOCAL_ADDR=localhost"
Environment="LOCAL_PORT=5432"
Environment="REMOTE_PORT=5432"
Environment="TARGET=xyz00-myuser@xyz00.hostsharing.net"
ExecStart=/usr/bin/ssh -NT -o ServerAliveInterval=60 -o ExitOnForwardFailure=yes -L ${LOCAL_ADDR}:${LOCAL_PORT}:localhost:${REMOTE_PORT} ${TARGET}

RestartSec=5
Restart=always

[Install]
WantedBy=multi-user.target
</syntaxhighlight>

Den Dienst entsprechend starten:
<syntaxhighlight lang=shell>
systemctl --user enable sshtunnel --now
</syntaxhighlight>

* TODO: Anpassungen an Docker Compose. Beispiel

== Docker fernsteuern ==
Es besteht die Möglichkeit, über SSH den Docker Socket von außen zu erreichen. Damit wird es möglich, über eine IDE wie z.B. Intellij IDEA die Docker Container zu starten und zu stoppen.

Um das auszuprobieren, können diese Befehle ausgeführt werden:

<syntaxhighlight lang="bash">
ssh -nNT -L $(pwd)/docker.sock:/var/run/docker.sock tallyman@vmxxxx.hostsharing.net
export DOCKER_HOST=unix://$(pwd)/docker.sock
docker ps -a
</syntaxhighlight>

Nun sollten die aktuell laufenden Container gelistet werden.

== Beispiel Anwendungen ==
=== Container Umgebung mit Nginx und Certbot ===
TODO siehe https://codeberg.org/tpokorra/hs.compose/src/branch/main/nginx-certbot
=== Container Umgebung mit Caddy und Python Anwendung ===
TODO siehe https://codeberg.org/tpokorra/hs.compose/src/branch/main/caddy-test

=== Nextcloud High Performance Backend mit Caddy ===
* Docker Compose: siehe https://codeberg.org/tpokorra/hs.compose/src/branch/main/nextcloud-high_performance_backend
* Siehe auch dort die [https://codeberg.org/tpokorra/hs.compose/src/branch/main/nextcloud-high_performance_backend#readme README Datei], was für die Einrichtung erforderlich ist.

=== OnlyOffice Documentserver ===
TODO siehe https://codeberg.org/tpokorra/hs.compose/src/branch/main/onlyoffice-document_server

=== Caddy und Uptime-Kuma mit Quadlets für Podman ===

* siehe https://codeberg.org/tpokorra/hs.quadlet.caddy
* siehe https://codeberg.org/tpokorra/hs.quadlet.uptimekuma

In den Beispielen sind Makefiles enthalten, an denen ersichtlich wird, welche Verzeichnisse angelegt werden müssen, und welche Dateien wohin kopiert werden müssen.

== Backups in Volumes einpflegen ==

Auf Anfrage stellen wir einen read-only Snapshot bereit, der unter anderem Docker-Volumes, Container und Compose-Dateien enthält.

Da Docker nicht direkt mit den User- und Gruppen-IDs des tallyman-Users arbeitet, sondern interne Sub-User- und Sub-Group-IDs verwendet, können diese Daten nicht unmittelbar zurückkopiert werden. Für die Wiederherstellung ist daher ein kurzer Zwischenschritt erforderlich.

Hinweis: selbstverständlich helfen wir auf Anfrage auch dabei, die Dateien wieder in das laufende System zu migrieren.

=== Beispiel: das pgdata Verzeichnis eines PostgreSQL Containers tauschen ===

==== Wo liegt das Volume auf dem Dateisystem? ====

<syntaxhighlight lang=bash>
docker ps -a # wie lautet der Containername?
docker inspect --format '{{ range .Mounts }}{{ if eq .Type "volume" }}{{ .Source }}{{ "\n" }}{{ end }}{{ end }}' postgres-1
</syntaxhighlight>

In unserem Fall sehen wir den Pfad: <code>/home/tallyman/.local/share/docker/volumes/8c73a862eaf1fc3dee55a2f29b6f3d3dd68e3049da58a21a5f73010e7233190c/_data</code>

==== Den betroffenen Container abschalten ====

In diesem Beispiel entscheiden wir uns dafür, die Container vollständig zu stoppen.
Der Grund dafür ist, dass es je nach Image nicht immer eindeutig ist, wie der darin laufende Prozess korrekt gestoppt und wieder gestartet werden sollte.

Alternativ könnten wir das Backup also auch direkt in das Volume kopieren und im bestehenden Container eine Shell öffnen, um die Dateien an die richtige Stelle zu verschieben.

<syntaxhighlight lang=bash>
docker ps -a # wie lautet der Containername?
docker stop app-1
docker stop postgres-1

# oder über die Service-Namen aus der compose.yaml
docker compose stop app
docker compose stop postgres
</syntaxhighlight>

==== In eine temporäre Subshell wechseln ====
Hier nutzen wir eine Abkürzung und lassen Docker einen temporären Container starten, der unseren Ordner als Volume einbindet.
So erhalten wir eine Shell im passenden Userid/Gruppenid-Kontext und können direkt mit den Dateien im Volume arbeiten, ohne den eigentlichen Service-Container starten, oder als root arbeiten zu müssen.

<syntaxhighlight lang=bash>
export VOL=".local/share/docker/volumes"
docker run --rm -it -v "$VOL:/data" bash
</syntaxhighlight>

Wir wechseln nun in das oben definierte Volume. Das Beispiel geht davon aus, dass das bereitgestellte Backupverzeichnis "pgdata2" genannt wurde.

<syntaxhighlight lang=bash>
cd data
mv pgdata pgdata.old
mv pgdata2 pgdata
</syntaxhighlight>

Hinweis: Falls wir zusätzliche Pakete brauchen, nutzt das – auf Alpine basierte – Bash image den Paketmanager `apk`. Beispiel: ncdu installieren:

<syntaxhighlight lang=bash>
~$ apk add ncdu
(1/1) Installing ncdu (1.22-r0)
Executing busybox-1.37.0-r30.trigger
OK: 8726 KiB in 20 packages
</syntaxhighlight>

==== Den Container wieder starten ====

Wir verlassen den Container mittels <code>exit</code> <code>Enter</code> oder über die Tastenkombination <code>STRG+D</code>.

<syntaxhighlight lang=bash>
docker start postgres-1
docker start app-1

# oder über die Service-Namen aus der compose.yaml
docker compose start app
docker compose start postgres
</syntaxhighlight>

=== Beispiel: eine Subshell mit Hilfe eine Containerprozesses starten ===
Für Debugging kann es nützlich sein, direkt mit allen vorinstallierten Tools im Containerserver mit Daten der Volumes zu agieren. Hier sind zwei Wege um eine Subshell ohne extra(!) Container zu starten:

==== Mit Hilfe eines beliebigen laufenden Containers: ====
<syntaxhighlight lang=bash>
docker ps
docker inspect --format '{{.State.Pid}}' app-1
nsenter -U -t 2586740 -- bash
</syntaxhighlight>

==== TODO ====
Funktionierende subshell (mit nötigen Berechtigungen) mittels unshare oder nsenter

Container

2026-09-10T14:29:01Z

Tim00: /* Hilfreiche Befehle für Podman */

== Übersicht ==

Es gibt die Möglichkeit, einen Container Server mit Docker oder mit Podman zu buchen.

Dies ist eine Managed Umgebung, also ohne Root-Rechte, wo Docker bzw. Podman rootless ausgeführt werden.

Falls vom Installationsskript einer Anwendung Root-Rechte erforderlich sind, kann entweder versucht werden, dies anzupassen, oder es kann ein Cloud Server gebucht werden, wo der Benutzer Root-Rechte hat.

== Erste Schritte ==

Bei der Bestellung des Container Servers sollte direkt der Public SSH Key mitgegeben werden, am besten bereits nach dem Ed25519-Standard, siehe auch [https://www.heise.de/tipps-tricks/SSH-Key-erstellen-so-geht-s-4400280.html].

Der Zugriff erfolgt über den Benutzer tallyman über SSH auf den Container Server.

<syntaxhighlight lang=shell>
ssh tallyman@vm4xxx.hostsharing.net
</syntaxhighlight>

Um einen "Hello World" Docker Container zu starten:

<syntaxhighlight lang=shell>
tallyman@vm4xxx:~$ docker run hello-world
</syntaxhighlight>

Entsprechend sieht der Befehl für Podman aus:

<syntaxhighlight lang=shell>
tallyman@vm4xxx:~$ podman run hello-world
</syntaxhighlight>

=== Hilfreiche Befehle für Docker ===

<syntaxhighlight lang=shell>
# in einem Ordner ausführen, wo eine Datei mit dem Namen docker-compose.yml liegt, um die Umgebung zu bauen und zu starten:
docker compose up --detach

# zeige alle laufenden Container
docker ps -a

# zeige die Logs eines Containers
docker logs mein-container

# wechsle in eine Shell im Container
docker exec -t -i mein-container /bin/sh

# Images aktualisieren
docker compose pull

# Containerumgebung stoppen und löschen
docker compose down
</syntaxhighlight>

=== Hilfreiche Befehle für Podman ===

Viele Befehle sind ähnlich wie bei Docker.

<syntaxhighlight lang=shell>
# in einem Ordner ausführen, wo eine Datei mit dem Namen compose.yaml liegt, um die Umgebung zu bauen und zu starten:
podman-compose up -d

# zeige alle laufenden Container
podman ps -a

# zeige die Logs eines Containers
podman logs mein-container

# wechsle in eine Shell im Container
podman exec -t -i mein-container /bin/sh

# Images aktualisieren
podman-compose pull

# Containerumgebung stoppen und löschen
docker-compose down
</syntaxhighlight>

Es ist aber zu empfehlen, nicht mit compose zu arbeiten, sondern mit Quadlets. Dabei sind die Container direkt in systemd Userspace eingebettet, und werden mit den richtigen Abhängigkeiten definiert und dann auch bei einem Reboot gestartet.

Siehe auch die Beispiele unten.

Es müssen die container und network Dateien in ~/.config/containers/systemd hinterlegt werden, und dann können die Service Dateien erzeugt werden:

<syntaxhighlight lang=shell>
# eigentlich müsste dieser Befehl die service Dateien in ~/.config/systemd/user/ neu erzeugen, aber es geht irgendwie nicht.
systemctl --user daemon-reload

# manuell:
/usr/lib/systemd/system-generators/podman-system-generator --user ~/.config/systemd/user
systemctl --user daemon-reload
</syntaxhighlight>

== Integration in Hostsharing Managed Platform ==

=== Subdomain einrichten ===

Wir haben bereits die Hauptdomain bei Hostsharing gebucht.

Nun soll unsere Anwendung auf dem Container Server auf einer Subdomain laufen.

Wir benutzen einen Caddy Container, um Letsencrypt bereitszustellen (siehe in den Beispielen unten).

Auf der Managed Umgebung müssen wir das Zonefile anpassen, um die Subdomain per A und AAAA Eintrag auf den Container Server zu verweisen.

Mit dem Befehl <code>dig</code> ermitteln wir die ipv4 und ipv6 Adressen unseres Container Servers:

<syntaxhighlight lang=shell>
dig -t A +short vm4xxx.hostsharing.net
dig -t AAAA +short vm4xxx.hostsharing.net
</syntaxhighlight>

Auf der Managed Umgebung, legen wir ein Zonefile an. Siehe auch die Anleitung im Handbuch: https://www.hostsharing.net/doc/managed-operations-platform/zonefile/

<code>doms/meinedomain.de/etc/pri.meinedomain.de</code>:

<syntaxhighlight lang=text>
{DEFAULT_ZONEFILE}

meinesubdomain IN A 83.223.xx.xxx
meinesubdomain IN AAAA 2a01:xx:xxxx::xxxx:xxxx:0
</syntaxhighlight>

=== Tunnel zur Managed Datenbank einrichten ===

Wir lassen die Anwendung auf dem Container Server laufen. Dort kann natürlich auch die Datenbank laufen, in einem eigenen Container.

Wir haben aber auch Datenbanken in der Managed Umgebung von Hostsharing, mit allen Vorteilen (regelmäßiges Backup, usw.).

Wenn wir eine managed Datenbank aus der Managed Umgebung auf dem Container Server einbinden wollen, sind folgende Schritte notwendig:

* Es muss ein Tunnel eingerichtet werden, damit die Datenbank vom Container Server aus erreichbar ist.

Datei .config/systemd/user/sshtunnel.service:

<syntaxhighlight lang=shell>
[Unit]
Description=SSH Tunnel zu Managed Webspace
After=network.target

[Service]
Environment="LOCAL_ADDR=localhost"
Environment="LOCAL_PORT=5432"
Environment="REMOTE_PORT=5432"
Environment="TARGET=xyz00-myuser@xyz00.hostsharing.net"
ExecStart=/usr/bin/ssh -NT -o ServerAliveInterval=60 -o ExitOnForwardFailure=yes -L ${LOCAL_ADDR}:${LOCAL_PORT}:localhost:${REMOTE_PORT} ${TARGET}

RestartSec=5
Restart=always

[Install]
WantedBy=multi-user.target
</syntaxhighlight>

Den Dienst entsprechend starten:
<syntaxhighlight lang=shell>
systemctl --user enable sshtunnel --now
</syntaxhighlight>

* TODO: Anpassungen an Docker Compose. Beispiel

== Docker fernsteuern ==
Es besteht die Möglichkeit, über SSH den Docker Socket von außen zu erreichen. Damit wird es möglich, über eine IDE wie z.B. Intellij IDEA die Docker Container zu starten und zu stoppen.

Um das auszuprobieren, können diese Befehle ausgeführt werden:

<syntaxhighlight lang="bash">
ssh -nNT -L $(pwd)/docker.sock:/var/run/docker.sock tallyman@vmxxxx.hostsharing.net
export DOCKER_HOST=unix://$(pwd)/docker.sock
docker ps -a
</syntaxhighlight>

Nun sollten die aktuell laufenden Container gelistet werden.

== Beispiel Anwendungen ==
=== Container Umgebung mit Nginx und Certbot ===
TODO siehe https://codeberg.org/tpokorra/hs.compose/src/branch/main/nginx-certbot
=== Container Umgebung mit Caddy und Python Anwendung ===
TODO siehe https://codeberg.org/tpokorra/hs.compose/src/branch/main/caddy-test

=== Nextcloud High Performance Backend mit Caddy ===
* Docker Compose: siehe https://codeberg.org/tpokorra/hs.compose/src/branch/main/nextcloud-high_performance_backend
* Siehe auch dort die [https://codeberg.org/tpokorra/hs.compose/src/branch/main/nextcloud-high_performance_backend#readme README Datei], was für die Einrichtung erforderlich ist.

=== OnlyOffice Documentserver ===
TODO siehe https://codeberg.org/tpokorra/hs.compose/src/branch/main/onlyoffice-document_server

== Backups in Volumes einpflegen ==

Auf Anfrage stellen wir einen read-only Snapshot bereit, der unter anderem Docker-Volumes, Container und Compose-Dateien enthält.

Da Docker nicht direkt mit den User- und Gruppen-IDs des tallyman-Users arbeitet, sondern interne Sub-User- und Sub-Group-IDs verwendet, können diese Daten nicht unmittelbar zurückkopiert werden. Für die Wiederherstellung ist daher ein kurzer Zwischenschritt erforderlich.

Hinweis: selbstverständlich helfen wir auf Anfrage auch dabei, die Dateien wieder in das laufende System zu migrieren.

=== Beispiel: das pgdata Verzeichnis eines PostgreSQL Containers tauschen ===

==== Wo liegt das Volume auf dem Dateisystem? ====

<syntaxhighlight lang=bash>
docker ps -a # wie lautet der Containername?
docker inspect --format '{{ range .Mounts }}{{ if eq .Type "volume" }}{{ .Source }}{{ "\n" }}{{ end }}{{ end }}' postgres-1
</syntaxhighlight>

In unserem Fall sehen wir den Pfad: <code>/home/tallyman/.local/share/docker/volumes/8c73a862eaf1fc3dee55a2f29b6f3d3dd68e3049da58a21a5f73010e7233190c/_data</code>

==== Den betroffenen Container abschalten ====

In diesem Beispiel entscheiden wir uns dafür, die Container vollständig zu stoppen.
Der Grund dafür ist, dass es je nach Image nicht immer eindeutig ist, wie der darin laufende Prozess korrekt gestoppt und wieder gestartet werden sollte.

Alternativ könnten wir das Backup also auch direkt in das Volume kopieren und im bestehenden Container eine Shell öffnen, um die Dateien an die richtige Stelle zu verschieben.

<syntaxhighlight lang=bash>
docker ps -a # wie lautet der Containername?
docker stop app-1
docker stop postgres-1

# oder über die Service-Namen aus der compose.yaml
docker compose stop app
docker compose stop postgres
</syntaxhighlight>

==== In eine temporäre Subshell wechseln ====
Hier nutzen wir eine Abkürzung und lassen Docker einen temporären Container starten, der unseren Ordner als Volume einbindet.
So erhalten wir eine Shell im passenden Userid/Gruppenid-Kontext und können direkt mit den Dateien im Volume arbeiten, ohne den eigentlichen Service-Container starten, oder als root arbeiten zu müssen.

<syntaxhighlight lang=bash>
export VOL=".local/share/docker/volumes"
docker run --rm -it -v "$VOL:/data" bash
</syntaxhighlight>

Wir wechseln nun in das oben definierte Volume. Das Beispiel geht davon aus, dass das bereitgestellte Backupverzeichnis "pgdata2" genannt wurde.

<syntaxhighlight lang=bash>
cd data
mv pgdata pgdata.old
mv pgdata2 pgdata
</syntaxhighlight>

Hinweis: Falls wir zusätzliche Pakete brauchen, nutzt das – auf Alpine basierte – Bash image den Paketmanager `apk`. Beispiel: ncdu installieren:

<syntaxhighlight lang=bash>
~$ apk add ncdu
(1/1) Installing ncdu (1.22-r0)
Executing busybox-1.37.0-r30.trigger
OK: 8726 KiB in 20 packages
</syntaxhighlight>

==== Den Container wieder starten ====

Wir verlassen den Container mittels <code>exit</code> <code>Enter</code> oder über die Tastenkombination <code>STRG+D</code>.

<syntaxhighlight lang=bash>
docker start postgres-1
docker start app-1

# oder über die Service-Namen aus der compose.yaml
docker compose start app
docker compose start postgres
</syntaxhighlight>

=== Beispiel: eine Subshell mit Hilfe eine Containerprozesses starten ===
Für Debugging kann es nützlich sein, direkt mit allen vorinstallierten Tools im Containerserver mit Daten der Volumes zu agieren. Hier sind zwei Wege um eine Subshell ohne extra(!) Container zu starten:

==== Mit Hilfe eines beliebigen laufenden Containers: ====
<syntaxhighlight lang=bash>
docker ps
docker inspect --format '{{.State.Pid}}' app-1
nsenter -U -t 2586740 -- bash
</syntaxhighlight>

==== TODO ====
Funktionierende subshell (mit nötigen Berechtigungen) mittels unshare oder nsenter

Discourse installieren

2026-09-10T05:04:54Z

Tim00: /* Am Beispiel von 2026.1.7 auf 2026.7.2 */

{{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|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 ==

Es müssen noch Erweiterungen für Postgresql installiert werden:

<syntaxhighlight lang=shell line>
psql --user xyz00_discourseuser -c "CREATE EXTENSION IF NOT EXISTS hstore WITH SCHEMA public;"
psql --user xyz00_discourseuser -c "CREATE EXTENSION IF NOT EXISTS pg_trgm WITH SCHEMA public;"
psql --user xyz00_discourseuser -c "CREATE EXTENSION IF NOT EXISTS unaccent WITH SCHEMA public;"
</syntaxhighlight>

== Konfiguration des Redis Server ==

{{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.}}

<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:

<syntaxhighlight lang=shell line>
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
</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 ==

Als User ''xyz00-discourse'': Installation von Ruby mit ''rbenv'' mit folgenden Befehlen:

Zunächst ''rbenv'' and ''ruby-build'':

<syntaxhighlight lang=shell line>
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
</syntaxhighlight>

starte neue Shell:

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

Überprüfe rbenv-Installation

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

Installiere ruby-build als rbenv-Plugin

<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:

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

== Installation von Discourse selber ==

Weiterhin Als User ''xyz00-discourse'':

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

Die stabile Version auschecken:

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

Ruby Pakete installieren:

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

== Konfiguration der Discourse Software ==

Anlegen einer Datei ''/home/pacs/xyz00/users/discourse/discourse/config/discourse.conf'' anhand der Beispiel-Datei:

<syntaxhighlight lang=shell>
cd ~/discourse
cp config/discourse_defaults.conf config/discourse.conf
</syntaxhighlight>

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

<syntaxhighlight lang=shell>
RAILS_ENV=production bundle exec rake secret
</syntaxhighlight>

=== 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 <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 ==

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

[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
</syntaxhighlight>

== Einrichten des Apache VHost ==

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

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:

<syntaxhighlight lang=apache line>
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]
</syntaxhighlight>
== 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.

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

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

<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!

Siehe auch die unterstützten Releases: https://releases.discourse.org/ und die Tags: https://github.com/discourse/discourse/tags

==== Am Beispiel von 2026.1.7 auf 2026.7.2 ====

# 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
# mv ~/plugins.bak/discourse-ai plugins
# git diff v2026.1.7 > diff-2026.1.7.txt
# git fetch
# git checkout -b hostsharing-deployment-v2026.7.2 v2026.7.2
# evtl. Änderungen aus diff-2026.1.7.txt wieder übernehmen und committen
# patch -p1 < diff-2026.1.7.txt
# git commit -a -m "spezifische Änderungen für diese Instanz" --no-verify
# Schauen, ob discourse eine neue Ruby-Version nutzt (z.B. in https://github.com/discourse/discourse_docker/blob/main/image/base/Dockerfile bzw. https://github.com/discourse/discourse/blob/v2026.1.7/Gemfile)
# Ist dies der Fall, dann:
# rbenv install 3.4.10
# rbenv global 3.4.10
# rbenv local 3.4.10
# rbenv rehash
# echo "3.4.10" > .ruby-version
# rm -Rf vendor/bundle/ruby/3.3.0/
# installiere Node 22: https://codeberg.org/tpokorra/hostsharing-scripts/src/branch/main/install-nodejs.sh
# source ~/.profile
# gem update --system
# rm -Rf .bundle
# bundle install
# npm install -g terser uglify-js pnpm@10
# corepack use pnpm@latest-10
# pnpm install
# export $(grep -v '^#' ~/discourse.env | xargs -d '\n')
# source ~/.profile
# Falls die pg extension pg_vector nicht installiert ist: deaktiviere das Plugin während migrate, aber auch für später damit /admin/settings funktioniert (ansonsten in salt pillar pg_vector installieren, und als postgres user: create extension vector;)
## mkdir -p ~/plugins.bak
## mv plugins/discourse-ai ~/plugins.bak
# 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 discourse
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>

Update: es hat sich wieder mehr im Code verändert. Bitte den Patch von https://codeberg.org/tpokorra/hs.ansible/src/branch/main/roles/apps/discourse/templates/imagemagick.patch benutzen!

== 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

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

Discourse installieren

2026-09-10T04:36:22Z

Tim00: /* Am Beispiel von 2026.1.5 auf 2026.1.7 */

{{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|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 ==

Es müssen noch Erweiterungen für Postgresql installiert werden:

<syntaxhighlight lang=shell line>
psql --user xyz00_discourseuser -c "CREATE EXTENSION IF NOT EXISTS hstore WITH SCHEMA public;"
psql --user xyz00_discourseuser -c "CREATE EXTENSION IF NOT EXISTS pg_trgm WITH SCHEMA public;"
psql --user xyz00_discourseuser -c "CREATE EXTENSION IF NOT EXISTS unaccent WITH SCHEMA public;"
</syntaxhighlight>

== Konfiguration des Redis Server ==

{{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.}}

<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:

<syntaxhighlight lang=shell line>
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
</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 ==

Als User ''xyz00-discourse'': Installation von Ruby mit ''rbenv'' mit folgenden Befehlen:

Zunächst ''rbenv'' and ''ruby-build'':

<syntaxhighlight lang=shell line>
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
</syntaxhighlight>

starte neue Shell:

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

Überprüfe rbenv-Installation

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

Installiere ruby-build als rbenv-Plugin

<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:

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

== Installation von Discourse selber ==

Weiterhin Als User ''xyz00-discourse'':

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

Die stabile Version auschecken:

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

Ruby Pakete installieren:

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

== Konfiguration der Discourse Software ==

Anlegen einer Datei ''/home/pacs/xyz00/users/discourse/discourse/config/discourse.conf'' anhand der Beispiel-Datei:

<syntaxhighlight lang=shell>
cd ~/discourse
cp config/discourse_defaults.conf config/discourse.conf
</syntaxhighlight>

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

<syntaxhighlight lang=shell>
RAILS_ENV=production bundle exec rake secret
</syntaxhighlight>

=== 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 <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 ==

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

[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
</syntaxhighlight>

== Einrichten des Apache VHost ==

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

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:

<syntaxhighlight lang=apache line>
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]
</syntaxhighlight>
== 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.

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

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

<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!

Siehe auch die unterstützten Releases: https://releases.discourse.org/ und die Tags: https://github.com/discourse/discourse/tags

==== Am Beispiel von 2026.1.7 auf 2026.7.2 ====

# 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
# mv ~/plugins.bak/discourse-ai plugins
# git diff v2026.1.7 > diff-2026.1.7.txt
# git fetch
# git checkout -b hostsharing-deployment-v2026.7.2 v2026.7.2
# evtl. Änderungen aus diff-2026.1.7.txt wieder übernehmen und committen
# patch -p1 < diff-2026.1.7.txt
# git commit -a -m "spezifische Änderungen für diese Instanz" --no-verify
# Schauen, ob discourse eine neue Ruby-Version nutzt (z.B. in https://github.com/discourse/discourse_docker/blob/main/image/base/Dockerfile bzw. https://github.com/discourse/discourse/blob/v2026.1.7/Gemfile)
# Ist dies der Fall, dann:
# rbenv install 3.4.10
# rbenv global 3.4.10
# rbenv rehash
# echo "3.4.10" > .ruby-version
# installiere Node 22: https://codeberg.org/tpokorra/hostsharing-scripts/src/branch/main/install-nodejs.sh
# source ~/.profile
# gem update --system
# bundle install
# npm install -g terser uglify-js pnpm@10
# corepack use pnpm@latest-10
# pnpm install
# export $(grep -v '^#' ~/discourse.env | xargs -d '\n')
# source ~/.profile
# Falls die pg extension pg_vector nicht installiert ist: deaktiviere das Plugin während migrate, aber auch für später damit /admin/settings funktioniert (ansonsten in salt pillar pg_vector installieren, und als postgres user: create extension vector;)
## mkdir -p ~/plugins.bak
## mv plugins/discourse-ai ~/plugins.bak
# 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 discourse
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>

Update: es hat sich wieder mehr im Code verändert. Bitte den Patch von https://codeberg.org/tpokorra/hs.ansible/src/branch/main/roles/apps/discourse/templates/imagemagick.patch benutzen!

== 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

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

Znuny installieren

2026-09-09T14:48:47Z

Tim00: /* Fehlersuche */

== Allgemein ==

[https://www.znuny.org/de Znuny] ist ein Open Source Ticketing System, und ist als Community Fork von OTRS entstanden. Das Versprechen ist, ein Ticket System mit Langzeitunterstützung (LTS) zu bieten.

Znuny ist in Perl geschrieben.

== Technische Details ==
Es gibt ein Ansible Skript, das die Installationsschritte für Znuny automatisiert durchführt.

Die Quellen für das Ansible Skript können hier eingesehen werden: https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/znuny

== Updates ==

Hier gibt es eine Übersicht über die aktuellen Versionen von Znuny: https://www.znuny.org/de/releases

Updates werden hier beschrieben:
* auf Znuny 6.5: https://doc.znuny.org/znuny_lts/releases/installupdate/update/update-6.5.html

Vor der Durchführung eines Updates auf dem Produktivsystem sollte ein Backup erstellt werden, das im Fall eines Problems wiederhergestellt werden kann.

Der Cronjob sollte deaktiviert werden, und im Administrationsbereich von Znuny sollte der Wartungsmodus aktiviert werden (unter SystemWartung).

<syntaxhighlight lang=shell>
# crontab -e
# Kommentar einfügen vor:

#*/5 * * * * $HOME/otrs/bin/otrs.Daemon.pl start &>/dev/null
$HOME/otrs/bin/otrs.Daemon.pl stop
</syntaxhighlight>

Dann muss der Tarball der gewünschten Version von Znuny heruntergeladen werden, und entpackt werden.

Die Konfigurationsdatei (Kernel/Config.pm) muss aus dem alten Verzeichnis in das neue Verzeichnis kopiert werden, ebenso evtl. Dateien in var/article. Cronjobs sollten ebenfalls von var/cron ins neue Verzeichnis kopiert werden.

Dann wird der symbolische Link gelöscht, und ein neuer symbolischer Link auf das neue Verzeichnis eingerichtet, zum Beispiel so:

<syntaxhighlight lang=shell>
rm Znuny && ln -s znuny-6.5.6 Znuny
</syntaxhighlight>

Danach werden die folgenden Befehle ausgeführt:

<syntaxhighlight lang=shell>
cd Znuny
./bin/otrs.Console.pl Maint::Database::Check
./bin/otrs.CheckModules.pl --all
./scripts/MigrateToZnuny6_5.pl
./bin/otrs.Console.pl Admin::Package::UpgradeAll
./bin/otrs.Console.pl Admin::Package::ReinstallAll
./bin/otrs.Console.pl Admin::Package::UpgradeAll
</syntaxhighlight>

Nun können die Cronjobs wieder aktiviert werden, und der Wartungsmodus kann beendet werden.

Gegebenenfalls müssen die Prozess-Tickets nach einem Update wieder in Betrieb genommen werden, in der Admin-Oberfläche unter Prozessmanagement.

== Einrichtung ==

=== Prozesse ===

Es lassen sich beliebige Prozesse einrichten.

Siehe dazu auch ein Blogbeitrag inkl. Video unseres Mitglieds Timotheus Pokorra: https://solidevereine.de/blog/2023/06/13/2023-06-znuny_prozess/

=== Eingehende E-Mails in Queues sortieren ===

Eingehende E-Mails können nach verschiedenen Kriterien mit Procmail in verschiedene Queues einsortiert werden.

Das sieht zum Beispiel für eine Queue Service mit Subqueue Letsencrypt so aus, in der Datei <code>.procmailrc</code>:

<syntaxhighlight lang="shell">
:0
* ^From: .+expiry@letsencrypt.org
|${HOME}/otrs/bin/otrs.Console.pl Maint::PostMaster::Read --target-queue Service::Letsencrypt --quiet
</syntaxhighlight>

=== Automatische Antwort bei eingehenden E-Mails ===

Normalerweise haben wir eine automatisierte Antwort für eingehende E-Mails ("Wir haben Ihre Anfrage erhalten, und melden uns bald bei Ihnen"). Das konfigurieren wir in den Einstellungen bei '''Auto Response'''/'''Automatische Antworten'''.

Von manchen Dienstleistern erhalten wir E-Mails im Ticketsystem, und wollen dort keine automatisierte Antwort schicken.
Um das umzusetzen, bearbeiten wir in den Einstellungen bei Systemkonfiguration den Eintrag '''SendNoAutoResponseRegExp''', wo wir einen regulären Ausdruck definieren können.

siehe auch https://doc.znuny.org/znuny_lts/admin/communication/autoresponses/index.html

== Fehlersuche ==

Die Konfigurationsdatei ist in <code>Kernel/Config.pm</code>. Die Default Einstellungen sind zu finden in <code>Kernel/Config/Defaults.pm</code> (siehe auch [https://github.com/znuny/Znuny/blob/dev/Kernel/Config/Defaults.pm])

Normalerweise wird in das SysLog (System Log) des Users geloggt. Dieses Log kann so gelesen werden:

<syntaxhighlight lang="bash">
journalctl --user
</syntaxhighlight>

=== Session Einstellungen ===

Wenn das komische Verhalten auftritt, dass z.B. nur das zuletzt hinzugefügte Attachment verschickt wird, dann ist was an den Sessions kaputt.

Wir empfehlen, die Einstellung SessionUseCookie anzuschalten.

Wenn die Session ID im GET Parameter OTRSAgentInterface in der URL erscheint: Das ist ein Zeichen dafür, dass das SessionManagement kaputt ist. Wenn sich aber in der Sysconfig von Znuny was ändert, z.B. Switches für Session per GET-Param oder Cookie, für den ScriptAlias, für HTTP/HTTPS oder den FQDN, dann wird auf Session-ID per URL umgestellt. Das kann auch mit Änderungen am fastcgi-bin Pfad verursacht werden.

== Links ==
*[https://www.znuny.org/de Webseite des Znuny Projekts]
*[https://github.com/znuny/Znuny Quelltext von Znuny bei Github]
*[https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/znuny Ansible Playbook für Hostsharing]

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]
[[Kategorie:Software]]
[[Kategorie:Helpdesk]]

Nextcloud

2026-09-04T20:54:50Z

Tim00: /* Nextcloud Push */

= Nextcloud =

[https://nextcloud.com/ Nextcloud] ist eine PHP-basierte Open Source Lösung für gängige Cloud-Anwendungen, u.a.:

* Filesharing unter Nutzern derselben Nextcloud, und mit der Öffentlichkeit
* Single-Sign-On Authentifizierung (SSO)
* Videokonferenzen (WebRTC)
* Online-Office Anwendung [https://www.collaboraoffice.com/ Collabora Online]

Beispiel-Funktionalität, die über Plugins, sogenannte [https://apps.nextcloud.com/ "Apps"], bereit gestellt werden kann:

* Kalender, Aufgabenverwaltung, Adressbuch
* Datei-Kollaboration (Kommentare zu Dateien, Verschlagwortung)
* Feedreader
* E-Mail-Programm
* Fotogalerie
* Musik- und Videowiedergabe

= Nextcloud installieren =

== Vorbereitungen ==

In ''hsadmin'', zum Beispiel mit ''hsscript'':

''hsadmin''-Shell starten mit:

<syntaxhighlight lang=shell>
hsscript -u xyz00 -i
Password: ********
</syntaxhighlight>

Dann nacheinander anlegen:

* Linux User als Domain-Administrator
* Subdomain ''cloud.example.org''
* PostgreSQL-User
* PostgreSQL Datenbank

<syntaxhighlight lang=shell>
xyz00@hsadmin> user.add({set:{name:'xyz00-cloud',password:'geheim',shell:'/bin/bash',comment:'Nextcloud'}})
xyz00@hsadmin> domain.add({set:{name:'cloud.example.org',user:'xyz00-cloud'}})
xyz00@hsadmin> postgresqluser.add({set:{name:'xyz00_nextclusr',password:'geheim'}})
xyz00@hsadmin> postgresqldb.add({set:{name:'xyz00_nextcloud',owner:'xyz00_nextclusr'}})
</syntaxhighlight>

== Nextcloud installieren ==

Anmelden als Linux-User ''xyz00-cloud'':

<syntaxhighlight lang=shell>
ssh -l xyz00-cloud xyz00.hostsharing.net
</syntaxhighlight>

''htdocs'' Verzeichnis vorbereiten

<syntaxhighlight lang=shell>
cd
mkdir nextcloud
cd doms/cloud.example.org
rm -rf subs/www subs-ssl/www htdocs-ssl
ln -s $HOME/nextcloud htdocs-ssl
</syntaxhighlight>

Falls der ''Redirect'' auf die Domain ''example.org'' umleitet statt auf die Subdomain ''cloud.example.org'', kann diese Aktion helfen:

<syntaxhighlight lang=shell>
cd doms/cloud.example.org
mkdir -p subs-ssl/www
cp htdocs/.htaccess subs-ssl/www/.htaccess
</syntaxhighlight>

Nextcloud herunterladen und entpacken.

<syntaxhighlight lang=shell>
cd
wget https://download.nextcloud.com/server/releases/nextcloud-30.0.6.zip
unzip nextcloud-30.0.6.zip
rm nextcloud-30.0.6.zip
mkdir data tmp
chmod 700 data tmp
</syntaxhighlight>

Um Probleme mit der Anmeldung der Nextcloud App am Mobilgerät zu vermeiden, müssen folgende Zeilen in der Datei <code>doms/cloud.example.org/.htaccess</code> eingefügt werden:

<syntaxhighlight lang=htaccess>
RewriteEngine On
RewriteCond %{HTTP:Authorization} ^(.*)
RewriteRule .* - [e=HTTP_AUTHORIZATION:%1]
</syntaxhighlight>

== Nextcloud konfigurieren ==

Im Verzeichnis "$HOME/doms/cloud.example.org/fastcgi-ssl/" eine Datei "php.ini" anlegen mit folgendem Inhalt:

<syntaxhighlight lang=ini>
memory_limit=512M
session.save_path=/home/pacs/xyz00/users/cloud/tmp
</syntaxhighlight>

Dann mit einem Editor diese Datei bearbeiten: In der zweiten Zeile den korrekten Pfad des vorher angelegten tmp-Verzeichnisses eintragen.

Im Browser auf die Seite
http://cloud.example.org gehen und den Anweisungen folgen.

Auf der ersten Seite sind anzugeben:

* Login und Passwort für den Administrator definieren
* PostgreSQL als Datenbanksystem
* PostgreSQL-User und Passwort aus dem ersten Schritt oben
* Name der PostgreSQL-Datenbank aus dem ersten Schritt
* "localhost" als Datenbankserver (Nextcloud 23.0.2 empfiehlt hier die Angabe des Ports, diesen also lt. [[PostgreSQL]] angeben)
* Das Verzeichnis "/home/pacs/xyz00/users/cloud/data/" als Daten-Verzeichnis (bitte beachten: das im Eingabefeld voreingestellte verweist auf das Verzeichnis "/home/pacs/xyz00/users/cloud/'''nextcloud'''/data/")

'''Achtung!''' Die Felder für die Datenbank sind auf dem Startscreen hinter einem unscheinbaren Link versteckt. Um man das Formular für die Datenbank-Daten zu gelangen, muss man auf den Link klicken. Anschließend kann man die gewünschte Datenbank auswählen und die entsprechenden Daten eintragen. '''Das sollte geschehen, bevor man die Installation abschließt!''' Tut man dies nicht, wird Nextcloud mit SQLite installiert. Eine Änderung der Datenbank soll zwar laut Dokumentation auch später noch möglich sein, ging aber bei einem Test schief.

In der Konfigurationsdatei der Nextcloud (in ''~/nextcloud/config/config.php'') lassen sich weitere Voreinstellungen treffen:

<syntaxhighlight lang=php line>
'maintenance_window_start' => 1, // Wartungsfenster ab 1:00 Uhr
'defaultapp' => 'calendar,files', // bei Start wird der Kalender gezeigt
'default_phone_region' => 'DE', // Format Telefonnummern
'default_language' => 'de', // Sprache deutsch
'force_language' => 'de',
'default_locale' => 'de_DE', // Locale (Formatierung Zeitangaben etc.)
'force_locale' => 'de_DE',
</syntaxhighlight>

== Nextcloud beschleunigen ==

Dieser Teil ist optional.

Wenn regelmäßig '''im Browser''' mit Nextcloud gearbeitet werden soll, ist Nextcloud im Browser oft sehr langsam. Um dies zu verbessern, unterstützt Nextcloud die Anwendung von unterschiedlichen Cache-Verfahren (zum Beispiel Memcache, Redis).

=== Redis Cache ===

Redis ist auf den Hostsharing-Servern vorinstalliert und wird von den Nextcloud-Entwicklern empfohlen. Redis wird als eigener Serverdienst gestartet. '''In Verbindung mit Hostsharing Managed Webspace muss für Redis [https://www.hostsharing.net/paas/managed-webspace/ Arbeitsspeicher für eigene Serverdienste] gebucht werden'''.

Die Konfiguration des Redis-Dientes ist auf der Seite [[Redis]] beschrieben. Hier wird für Nextcloud die Variante mit einem Unixsocket benutzt.

In der Konfiguration der Nextcloud (in ''~/nextcloud/config/config.php'') wird der Redis-Cache wie folgt konfiguriert:

<syntaxhighlight lang=php line>
'memcache.local' => '\\OC\\Memcache\\Redis',
'memcache.distributed' => '\\OC\\Memcache\\Redis',
'memcache.locking' => '\\OC\\Memcache\\Redis',
'redis' =>
array (
'host' => '/home/pacs/xyz00/users/cloud/redis/var/redis-server.sock',
'port' => 0,
'password' => 'mein-redis-passwort',
'timeout' => 1.5,
),
</syntaxhighlight>

Um es perfekt zu machen, nutze ich ''logrotate'' um die Logdateien zu organisieren. Dazu die Konfiguration in ''~/.logrotate''

<syntaxhighlight lang=shell line>
compress
/home/pacs/xyz00/users/cloud/redis/var/redis.log {
rotate 5
daily
missingok
}
</syntaxhighlight>
Mit systemd-Timern werden die Logdateien täglich rotiert:

''~/.config/systemd/user/logrotate.service''
<syntaxhighlight lang=ini line>
[Unit]
Description=rotate log files

[Service]
Type=oneshot
ExecStart=/usr/sbin/logrotate -s %h/.logrotate.state %h/.logrotate
</syntaxhighlight>

''~/.config/systemd/user/logrotate.timer''
<syntaxhighlight lang=ini line>
[Unit]
Description=timer for nextcloud cleanup job

[Timer]
OnCalendar=1:1
Persistent=True

[Install]
WantedBy=timers.target
</syntaxhighlight>

Den Timer aktivieren und starten:
<syntaxhighlight lang=shell line>
$ systemctl --user enable logrotate.timer
$ systemctl --user start logrotate.timer
</syntaxhighlight>

=== Nextcloud Cronjob ===

Für die regelmäßigen Hintergrundaufgaben innerhalb der Nextcloud sollte ein Cronjob eingerichtet werden. Wir lösen dies hier mit einem weiteren Systemd-Timer:

''~/.config/systemd/user/nextcloud_background.service''
<syntaxhighlight lang=ini line>
[Unit]
Description=nextcloud cleanup job

[Service]
Type=oneshot
ExecStart=/usr/bin/php %h/nextcloud/cron.php
</syntaxhighlight>

''~/.config/systemd/user/nextcloud_background.timer''
<syntaxhighlight lang=ini line>
[Unit]
Description=timer for nextcloud cleanup job

[Timer]
OnCalendar=*:0/5
Persistent=True

[Install]
WantedBy=timers.target
</syntaxhighlight>

Den Timer aktivieren und starten:
<syntaxhighlight lang=shell line>
$ systemctl --user enable nextcloud_background.timer
$ systemctl --user start nextcloud_background.timer
</syntaxhighlight>

=== Nextcloud Push ===

Um Vorgänge wie Sync und Benachrichtigungen bei sehr großen Nextcloud Installationen zu beschleunigen, kann der <code>notify_push</code> Dienst hinzuinstalliert werden.

==== Abhängigkeiten und Einschränkungen ====
* <code>notify_push</code> muss Zugriff auf den gleichen Redis-Cache wie die Nextcloud haben
** aufgrund von eingeschränktem Passwort Support sollte ein Redis Socket mit sicheren Berechtigungseinstellungen als Alternative zum Redis Port mit Passwort konfiguriert werden.
* optimaler Weise holt sich <code>notify_push</code> benötigte informationen aus der <code>config.php</code> der bestehenden Nextcloud-Installation
* eine zusätzliche (Sub)domain im gleichen User ist nötig. Andernfalls muss die bestehende <code>.htaccess</code> muss aus o.g. Gründen modifiziert werden, dies könnte bei Nextcloud-Updates verloren gehen(!)
* Bestimmte Portbereiche sind bei Hostsharing eingeschränkt, es empfiehlt sich, direkt beispielsweise Port <code>37867</code> zu nehmen. aus diesem Grund ist das automatische Setup durch das Plugin bei Hostsharing nicht möglich!

==== Installation ====
Siehe auch: https://github.com/nextcloud/notify_push#manual-setup

1. Installieren der Nextcloud-App <code>notify_push</code> – (nach Push suchen, "Client Push" wählen) 
2. falls noch nicht erstellt: <code>mkdir -p ~/.config/systemd/user</code> 
3. mit Lieblingseditor die Datei <code>~/.config/systemd/user/notify_push.service</code> anlegen: 
<syntaxhighlight lang="ini" line>
[Unit]
Description = Push daemon for Nextcloud clients
Documentation = https://github.com/nextcloud/notify_push

[Service]
Environment = BIND=127.0.0.1
# Change if you already have something running on this port
Environment = PORT=37867
# We don't want to bind to 0.0.0.0, hence the --bind
ExecStart = /home/pacs/xyz00/users/cloud/bin/notify_push --bind 127.0.0.1 /home/pacs/xyz00/users/cloud/nextcloud/config/config.php
Type=notify

[Install]
WantedBy = default.target
</syntaxhighlight>
4. das Verzeichnis <code>~/bin</code> anlegen und die aktuellste binary herunterladen und ausführbar machen:
<syntaxhighlight lang="shell" line>release=`curl -L https://api.github.com/repos/nextcloud/notify_push/releases/latest -s | jq -r '.tag_name'` && wget --show-progress -qO ~/bin/notify_push https://github.com/nextcloud/notify_push/releases/download/$release/notify_push-x86_64-unknown-linux-musl && chmod +x ~/bin/notify_push</syntaxhighlight>
5. es könnte die folgende Umgebungsvariable zum Bedienen von systemd notwendig werden: <code>export XDG_RUNTIME_DIR=/run/user/$UID</code> 
6. den neuen systemd-Dienst automatisch bei Systemstart, sowie jetzt sofort starten: <code>systemctl enable --now --user notify_push</code> 
7. nun gehen wir in <code>doms/push.cloud.example.com/htdocs-ssl/.htaccess</code> und ersetzen den Inhalt (bevorzugt), oder wir ergänzen die .htaccess der Nextcloud im unteren Teil um die folgenden Zeilen (letzteres kann bei Updates überschrieben werden!):
<syntaxhighlight lang="apache" line>
# bei eigener (sub)domain ist /push/ nicht erforderlich, aber wer weiß, eventuell ist das mit robuster
RewriteCond %{REQUEST_URI} ^/push/ws [NC,OR]
RewriteCond %{HTTP:UPGRADE} ^WebSocket$ [NC,OR]
RewriteCond %{HTTP:CONNECTION} ^Upgrade$ [NC]
RewriteRule .* ws://127.0.0.1:37867/ws [proxy]

RewriteCond %{REQUEST_URI} ^/push [NC]
RewriteRule .* http://127.0.0.1:37867%{REQUEST_URI} [proxy]
</syntaxhighlight>
8. abschließend im Nextcloud Ordner die Konfiguration des Plugins anstoßen: <code>php occ notify_push:setup https://cloud.example.com/push</code> bzw. <code>php occ notify_push:setup https://push.cloud.example.com/push</code> 
9. es ist möglich, das die erkannte IP-Adresse des Hives noch nicht vertraut ist. In diesem Fall wird der obige Befehl scheitern und es muss jene aus der Fehlermeldung des Setups unter <code>trusted_proxies</code> in der <code>config.php</code> ergänzt werden. 

Es wird im Repo außerdem ein Testclient bereitgestellt, der sich testweise mit dem Push-Dienst verbindet

Folgende Befehle helfen ebenfalls beim Debugging:

<syntaxhighlight lang="bash">
~/nextcloud$ php occ notify_push:self-test
~/nextcloud$ php occ notify_push:metrics
</syntaxhighlight>

== Nextcloud mit Online Office ==

In Nextcloud können Office-Dokumente (Textverarbeitung, Tabellen und Präsentationen) im Browser bearbeitet werden. Dazu steht bei Hostsharing die Collabora Developer Version zur Verfügung. Bestellung und Konfiguration sind hier im Wiki auf der Seite [[Collabora_Online]] beschrieben.

== Nextcloud mit Nextcloud Talk ==

Über die Nextcloud-App "Talk" können Videokonfererenzen mit Screensharing durchgeführt werden. Für die regelmäßige Nutzung kann es sinnvoll sein, einen eigenen TURN Server zu betreiben. Siehe dazu [[Coturn_Installieren]]

Das Hochleistungs-Backend haben wir mittlerweile bei manchen Mitgliedern bereits im Einsatz. Es wird auf einem Container Server installiert. (siehe auch [[Container#Nextcloud_High_Performance_Backend_mit_Caddy|Nextcloud High Performance Backend auf Container Server]])

Unser Mitglied Timotheus Pokorra bietet auch einen Nextcloud High Performance Backend Server zum Teilen an. Siehe [https://solidevereine.de/organisation/nextcloud/#highperf]

Ohne das Hochleistungs-Backend macht wohl die Audio bzw. Video Funktion kaum Sinn, wenn es mit mehr als 2 Teilnehmern genutzt werden soll. Deswegen empfehlen wir, die Anrufe in Talk zu deaktivieren, und stattdessen die BBB zu benutzen.

Das Deaktivieren der Anrufe geschieht in der Administrationsoberfläche von Nextcloud, unter Talk, "Auf Gruppen beschränken", "Starten von Anrufen begrenzen": "Anrufe deaktivieren"

[[Datei:NextcloudTalkAnrufeDeaktivieren.png]]

Die Warnung wegen dem fehlenden Hochleistungs-Backend lässt sich "entschärfen": in der Einstellungsseite von Talk in der Administrationsoberfläche, ganz oben, deaktiviere: "Vor Verbindungsproblemen bei Anrufen mit mehr als 2 Teilnehmern warnen"

[[Datei:NextcloudTalkWarnungDeaktivieren.png]]

== Virenscanner ==

Einige Nutzer wollen die Dateien in Ihrer Nextcloud regelmäßig auf Viren überprüfen. Auf unseren Servern steht dafür der OpenSource-Virenscanner "ClamAV" zur Verfügung. Wenn dieser Scanner benutzt wird, dann sollten die Einstellungen so gewählt sein, dass der ClamAV-Daemon über eine Socket Verbindung angesprochen wird. Die Einstellungen sind im Screenshot dokumentiert.

* Es wird die App [https://apps.nextcloud.com/apps/files_antivirus Antivirus für Dateien] installiert.
* Bei Modus wird gewählt: <code>ClamAV-Daemon (Socket)</code>
* Bei Socket wird gewählt: <code>/var/run/clamav/clamd.ctl</code>

[[Datei:Nextcloud-ClamAV-Einstellungen.png||nextcloud einstellungen für die virenscanner-app]]

== Volltextsuche ==

Über die Dokumente einer Nextcloud kann ein Volltextindex erstellt werden. Die Volltextsuche ermöglicht über den Index eine Suche über beliebige Begriffe, die in Dokumenten vorkommen.

Voraussetzung ist der Betrieb eines Elasticsearch Servers. Der Betrieb im Managed Webspace erfodert die Buchung von zwei "Serverdiensten". Nutzer eines Managed Server müssen mit einem spürbaren Mehrbedarf an Hauptspeicher rechnen.

Zur Installation von Elasticsearch existiert eine eigene Wikiseite: [[Elasticsearch]].

In der Nextcloud sind folgende ''Apps'' zu installieren:
* Full Text Search
* Full Text Search - Elasticsearch Platform
* Full Text Search - Files

nach der Installation der drei Apps steht in den Einstellungen ein neuer Menüpunkt "Volltextsuche" zur Verfügung.

Hier ist einzustellen:
* Suchplattform: Elasticsearch
* Adresse des Servlets: http://elastic:das-erzeugt-passwort@127.0.0.1:39200
* Index: frei-gewaehlter-name-idx
* Analyzer tokenizer: standard

Die anderen Einstellung nach den eigenen Vorstellungen vornehmen.

Der initiale Aufbau des Suchindex erfolgt über ein "occ"-Kommando auf der Shell:

<syntaxhighlight lang=shell line>
cd nextcloud/
php occ fulltextsearch:index --output
</syntaxhighlight>

Wenn dieser Fehler kommt:
<syntaxhighlight lang=text>
TypeError: Return value of OCA\Files_FullTextSearch\Model\MountPoint::isGlobal()
must be of the type bool, null returned in [...]/apps/files_fulltextsearch/lib/Model/MountPoint.php:103
</syntaxhighlight>
sollte dieser Patch angewendet werden: https://github.com/nextcloud/files_fulltextsearch/issues/125#issuecomment-877789742

Zur Pflege des Indexes wird ein weiterer Hintergrundprozess gestartet:

<syntaxhighlight lang=shell line>
cd nextcloud/
php occ fulltextsearch:live -q
</syntaxhighlight>

Die Monit Konfiguration dafür sieht so aus:

<syntaxhighlight lang=shell line>
#~/bin/start-fulltextsearchlive
#
#!/bin/bash
export HOME=/home/pacs/xyz00/users/cloud
cd $HOME
mkdir -p $HOME/var
cd $HOME/nextcloud
exec php occ fulltextsearch:live -q &
echo $! >$HOME/var/fulltextsearchlive.pid
</syntaxhighlight>

<syntaxhighlight lang=shell line>
#~/bin/stop-fulltextsearchlive
#
#!/bin/bash
export HOME=/home/pacs/xyz00/users/cloud
kill $( cat $HOME/var/fulltextsearchlive.pid )
</syntaxhighlight>

~/.monitrc (siehe oben von der Redis Installation) entsprechend ergänzen:
<syntaxhighlight lang=shell line>
check process fulltextsearchlive with pidfile /home/pacs/xyz00/users/cloud/var/fulltextsearchlive.pid
start program "/home/pacs/xyz00/users/cloud/bin/start-fulltextsearchlive"
stop program "/home/pacs/xyz00/users/cloud/bin/stop-fulltextsearchlive"
</syntaxhighlight>

== Integration mit LDAP ==

Um einheitliche Benutzerzugänge für verschiedene Anwendungen zu ermöglichen, wird oft auf ein zentrales LDAP Verzeichnis gesetzt.

Dieses kann für Nextcloud eingesetzt werden, damit Benutzer nicht lokal in Nextcloud, sondern in LDAP verwaltet werden können.

Siehe auch https://docs.nextcloud.com/server/latest/admin_manual/configuration_user/user_auth_ldap.html

Dazu muss die App "LDAP user and group backend" in den Nextcloud Apps aktiviert werden.

Dann muss die LDAP Anbindung in den Administrationseinstellungen unter "LDAP/AD-Integration" eingerichtet werden.

Der Server mit Port, die BenutzerDN mit Passwort und die BaseDN müssen eingetragen werden.

Es muss auch bestimmt werden, welche Klasse (z.B. inetOrgPerson) die Benutzer brauchen, um Zugriff auf die Nextcloud zu erhalten.

Falls schon Benutzer in der Nextcloud existieren, und diese zu LDAP mitgenommen werden sollen, kann der Anleitung aus diesem Forum Eintrag gefolgt werden: https://help.nextcloud.com/t/migration-to-ldap-keeping-users-and-data/13205

* Voraussetzung ist, dass der Benutzernamen der zu übernehmenden Benutzer in Nextcloud der uid in LDAP entspricht.
* Es wird ein Administrator Benutzer benötigt, der lokal angelegt wurde, und auch lokal bleibt.
* Mit diesem Administrator Benutzer wird die LDAP Anbindung eingerichtet.
* In der Experten Ansicht von LDAP/AD muss bei "Attribut für interne Benutzernamen" eingetragen werden: uid
* Klicke den Schalter "LDAP Benutzernamenzuordnung löschen"
* Klicke den Schalter "LDAP Gruppennamenzuordnung löschen"
* dann in der MySQL Datenbank anmelden, und aus uc_users alle Benutzer bis auf den Administrator Benutzer löschen
* Dann in der Nextcloud Weboberfläche sich alle Benutzer anzeigen lassen
* Nun gelingt die Anmeldung mit den anderen Benutzern mit dem LDAP Passwort, und die Dateien wurden übernommen.

== Optimierung der Geschwindigkeit ==
Manchmal fühlt sich die Nextcloud träge an.

Folgende Änderungen können helfen:

* HTTP/2.0 aktivieren: dem Service von Hostsharing Bescheid geben
* Die App Dashboard deaktivieren, und dafür werden direkt die Dateien angezeigt
* Einblenden der README in den Ordnern abschalten: das kann pro Ordner in der UI geschehen (links unten), oder global: <code>occ config:app:set text workspace_available --value=0</code>. Siehe auch [https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/text_configuration.html#disable-rich-workspaces-globally]

== Default App einstellen ==

In der Datei config.php können wir einstellen, welche App direkt nach der Anmeldung gezeigt wird.

Das ist entweder die Dashboard App, wenn sie aktiviert ist, oder die Dateien App (files).

Falls der Kalender direkt angezeigt werden soll, muss folgende Zeile in der config.php hinzugefügt werden (siehe auch [https://docs.nextcloud.com/server/stable/admin_manual/configuration_server/config_sample_php_parameters.html#defaultapp]):

<syntaxhighlight lang=shell>
'defaultapp' => 'calendar',
</syntaxhighlight>

= Nextcloud Updates =

== Updater über die Shell starten ==

Wenn die NextCloud sich nicht über das Webfrontend updaten lässt, kann der Updater auch per Shell im directory /updater durch ausführen des updater.phar gestartet werden:

<syntaxhighlight lang=shell line>
xyz00-cloud@h00:~$ cd ~/nextcloud
xyz00-cloud@h00:~/nextcloud$ php updater/updater.phar
</syntaxhighlight>

Falls während des Updates kein Backup angelegt werden soll:

<syntaxhighlight lang=shell line>
xyz00-cloud@h00:~$ cd ~/nextcloud
xyz00-cloud@h00:~/nextcloud$ php updater/updater.phar --no-backup
</syntaxhighlight>

Es sollten außerdem ein paar Routine-Aufräumarbeiten durchgeführt werden:

<syntaxhighlight lang=shell line>
xyz00-cloud@h00:~$ cd ~/nextcloud
xyz00-cloud@h00:~/nextcloud$ php occ db:add-missing-primary-keys --no-interaction
xyz00-cloud@h00:~/nextcloud$ php occ db:add-missing-columns --no-interaction
xyz00-cloud@h00:~/nextcloud$ php occ db:add-missing-indices --no-interaction
xyz00-cloud@h00:~/nextcloud$ php occ db:convert-filecache-bigint --no-interaction
xyz00-cloud@h00:~/nextcloud$ php occ maintenance:repair --include-expensive
</syntaxhighlight>

So können die Apps noch alle aktualisiert werden:

<syntaxhighlight lang=shell line>
xyz00-cloud@h00:~$ cd ~/nextcloud
xyz00-cloud@h00:~/nextcloud$ php occ app:update --all -n --no-ansi
</syntaxhighlight>

Für weitere Informationen kann auf die offizielle Doku ab Ziffer 2. zurückgegriffen werden.

* [https://docs.nextcloud.com/server/latest/admin_manual/maintenance/update.html#using-the-command-line-based-updater https://docs.nextcloud.com]

Hier gibt es ein kurzes Video, das die Anmeldung über die Kommandozeile mit Putty erklärt und die Aktualisierung von Nextcloud auf der Kommandozeile:

* [https://tube.solidcharity.net/w/0cf5ee97-ba7c-41df-a56f-8d1fea842ab0 Nextcloud auf der Kommandozeile aktualisieren]

== Wartungsmodus per Shell ein- oder ausschalten ==

So kann der Wartungsmodus angeschaltet werden:

<syntaxhighlight lang=shell line>
xyz00-cloud@h00:~$ cd ~/nextcloud
xyz00-cloud@h00:~/nextcloud$ php occ maintenance:mode --on
</syntaxhighlight>

So kann der Wartungsmodus wieder ausgeschaltet werden, d.h. die Nextcloud ist dann wieder in Betrieb:

<syntaxhighlight lang=shell line>
xyz00-cloud@h00:~$ cd ~/nextcloud
xyz00-cloud@h00:~/nextcloud$ php occ maintenance:mode --off
</syntaxhighlight>

== Webfrontend-Updater Probleme / Lösungen ==

=== Datenbank: Indizes | Primärschlüssel | Konvertierungen ===

Aufgetreten nach erfolgtem Versionsupdate Nextcloud 19 auf Nextcloud 20

Nach dem erfolgten Update lädt automatisch die Seite: '''Sicherheits- und Einrichtungswarnungen''' auf dieser wird angemerkt, dass manuelle Schritte für die Datenbank durchzuführen sind. Dies betrifft Indizes, Primärschlüssel und Konvertierungen.

Per Shell in der directory /nextcloud folgende Kommandos ausführen:

<syntaxhighlight lang=shell line>
xyz00-cloud@h00:~$ cd ~/nextcloud
xyz00-cloud@h00:~/nextcloud$ php occ db:add-missing-primary-keys --no-interaction
xyz00-cloud@h00:~/nextcloud$ php occ db:add-missing-columns --no-interaction
xyz00-cloud@h00:~/nextcloud$ php occ db:add-missing-indices --no-interaction
xyz00-cloud@h00:~/nextcloud$ php occ db:convert-filecache-bigint --no-interaction
xyz00-cloud@h00:~/nextcloud$ php occ maintenance:repair --include-expensive
</syntaxhighlight>

Wichtig ist hier dem durch Nextcloud angegebenen Kommando ein '''php''' voranzustellen.

== Update per Skript ==

Es ist möglich die regelmäßigen Updates weitgehend zu automatisieren. Ein Skript wäre etwa:

<syntaxhighlight lang=shell line>
#!/bin/bash
if [ -f $HOME/nextcloud/occ ]; then
echo "Nextcloud Update";
cd $HOME/nextcloud;
php updater/updater.phar -vv --no-backup --no-interaction
php occ maintenance:mode --on
php occ db:add-missing-primary-keys --no-interaction
php occ db:add-missing-columns --no-interaction
php occ db:add-missing-indices --no-interaction
php occ db:convert-filecache-bigint --no-interaction
php occ maintenance:repair --include-expensive
php occ app:update --all
php occ maintenance:mode --off
else
echo "Keine Nextcloud Installation gefunden";
fi
</syntaxhighlight>

== Update: bei old-stable Version bleiben ==

Normalerweise fragt jede Nextcloud Instanz zentral ab, welches Update zur Verfügung steht, abhängig vom Release Channel. Dabei wird aber relativ schnell auf die nächste Version gewechselt, also z.B. von Nextcloud 31 auf Nextcloud 32, obwohl Nextcloud 31 noch mehrere Monate gepflegt wird, und manche Apps noch nicht bereit sind für Nextcloud 32.

Es kann aber auch eine Alternative eingerichtet werden, in der Datei nextcloud/config/config.php, unter dem Eintrag updater.server.url

Hier wird z.B. auf einen Updater von unserem Mitglied Timotheus Pokorra verwiesen:

<syntaxhighlight lang=php line>
updater_server_url: "https://ncupdater.solidcharity.com/31/"
</syntaxhighlight>

Dahinter läuft ein Skript, mit dem wir noch länger eine bestimmte Version anbieten können: https://codeberg.org/tpokorra/ncupdater

= Daten auf HDD Storage =
== Einrichtung des HDD Storage ==

Um den langsameren aber günstigeren HDD Storage von Hostsharing zu nutzen, kann das data Verzeichnis von SSD auf HDD Storage verschoben werden. Ein symbolischer Link reicht nicht aus, man muss den Pfad in der Nextcloud Konfigurationsdatei anpassen.

<syntaxhighlight lang=shell>
# Nextcloud in Wartungsmodus versetzen
xyz00-cloud@h00:~/nextcloud$ php occ maintenance:mode --on
# Daten auf HDD Storage verschieben
xyz00-cloud@h00:~/nextcloud$ mv data /home/storage/xyz00/users/cloud/
# symbolischen Link anlegen
xyz00-cloud@h00:~/nextcloud$ ln -s /home/storage/xyz00/users/cloud/data data
# Pfad in config.php ändern
nano config/config.php
# Die Zeile mit 'datadirectory' finden und entsprechend ändern:
# 'datadirectory' => '/home/storage/xyz00/users/cloud/data',
# Wartungsmodus beenden
xyz00-cloud@h00:~/nextcloud$ php occ maintenance:mode --off
</syntaxhighlight>

Ein Fallstrick: Im data-Verzeichnis liegt eine versteckte Datei ".ncdata". Beim Move-Befehl "mv" für das komplette Data-Verzeichnis wird diese Datei mit verschoben. Sonst muss die Datei ggf. ins neue data-Verzeichnis kopiert werden!

= Einschränkende Bemerkungen =
== Nextcloud Sync Client ==

Der Nextcloud Sync Client erfüllt eine Funktion ähnlich wie Dropbox, und synchronisiert ganze Ordnerstrukturen.

Gerade wenn man mit mehreren Menschen in einer Nextcloud arbeitet, ist diese Funktion mit Vorsicht zu benutzen.

* Änderungen an der Ordnerstruktur sollten nicht lokal, sondern im Webbrowser vorgenommen werden.
* Wenn die Gefahr besteht, dass mehrere Menschen gleichzeitig eine Datei bearbeiten, sollte die Datei nicht lokal, sondern im Webbrowser bearbeitet werden.
* Aus Sicht des Datenschutzes und der Daten-Minimierung sollte überlegt werden, ob die Daten wirklich auf jeden Laptop und Rechner synchronisiert werden sollen, oder ob es reicht, ausschließlich über den Webbrowser auf die Daten zuzugreifen.

= weiterführende Links =

* [https://docs.nextcloud.com/ Nextcloud Dokumentation]
* [https://apps.nextcloud.com/ Nextcloud Erweiterungen ("Apps")]
* [https://docs.nextcloud.com/server/stable/admin_manual/installation/server_tuning.html Optimierung des Caches z.B. für Previews]
* [https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/nextcloud Ansible Playbook für Hostsharing]

= Nextcloud Reseller bei HS =

[https://nextcloud.ossaas.de OS SaaS]

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]
[[Kategorie:Software]]
[[Kategorie:CalDAV]]
[[Kategorie:Nextcloud]]

Nextcloud

2026-09-04T20:28:36Z

Tim00: /* Installation */

= Nextcloud =

[https://nextcloud.com/ Nextcloud] ist eine PHP-basierte Open Source Lösung für gängige Cloud-Anwendungen, u.a.:

* Filesharing unter Nutzern derselben Nextcloud, und mit der Öffentlichkeit
* Single-Sign-On Authentifizierung (SSO)
* Videokonferenzen (WebRTC)
* Online-Office Anwendung [https://www.collaboraoffice.com/ Collabora Online]

Beispiel-Funktionalität, die über Plugins, sogenannte [https://apps.nextcloud.com/ "Apps"], bereit gestellt werden kann:

* Kalender, Aufgabenverwaltung, Adressbuch
* Datei-Kollaboration (Kommentare zu Dateien, Verschlagwortung)
* Feedreader
* E-Mail-Programm
* Fotogalerie
* Musik- und Videowiedergabe

= Nextcloud installieren =

== Vorbereitungen ==

In ''hsadmin'', zum Beispiel mit ''hsscript'':

''hsadmin''-Shell starten mit:

<syntaxhighlight lang=shell>
hsscript -u xyz00 -i
Password: ********
</syntaxhighlight>

Dann nacheinander anlegen:

* Linux User als Domain-Administrator
* Subdomain ''cloud.example.org''
* PostgreSQL-User
* PostgreSQL Datenbank

<syntaxhighlight lang=shell>
xyz00@hsadmin> user.add({set:{name:'xyz00-cloud',password:'geheim',shell:'/bin/bash',comment:'Nextcloud'}})
xyz00@hsadmin> domain.add({set:{name:'cloud.example.org',user:'xyz00-cloud'}})
xyz00@hsadmin> postgresqluser.add({set:{name:'xyz00_nextclusr',password:'geheim'}})
xyz00@hsadmin> postgresqldb.add({set:{name:'xyz00_nextcloud',owner:'xyz00_nextclusr'}})
</syntaxhighlight>

== Nextcloud installieren ==

Anmelden als Linux-User ''xyz00-cloud'':

<syntaxhighlight lang=shell>
ssh -l xyz00-cloud xyz00.hostsharing.net
</syntaxhighlight>

''htdocs'' Verzeichnis vorbereiten

<syntaxhighlight lang=shell>
cd
mkdir nextcloud
cd doms/cloud.example.org
rm -rf subs/www subs-ssl/www htdocs-ssl
ln -s $HOME/nextcloud htdocs-ssl
</syntaxhighlight>

Falls der ''Redirect'' auf die Domain ''example.org'' umleitet statt auf die Subdomain ''cloud.example.org'', kann diese Aktion helfen:

<syntaxhighlight lang=shell>
cd doms/cloud.example.org
mkdir -p subs-ssl/www
cp htdocs/.htaccess subs-ssl/www/.htaccess
</syntaxhighlight>

Nextcloud herunterladen und entpacken.

<syntaxhighlight lang=shell>
cd
wget https://download.nextcloud.com/server/releases/nextcloud-30.0.6.zip
unzip nextcloud-30.0.6.zip
rm nextcloud-30.0.6.zip
mkdir data tmp
chmod 700 data tmp
</syntaxhighlight>

Um Probleme mit der Anmeldung der Nextcloud App am Mobilgerät zu vermeiden, müssen folgende Zeilen in der Datei <code>doms/cloud.example.org/.htaccess</code> eingefügt werden:

<syntaxhighlight lang=htaccess>
RewriteEngine On
RewriteCond %{HTTP:Authorization} ^(.*)
RewriteRule .* - [e=HTTP_AUTHORIZATION:%1]
</syntaxhighlight>

== Nextcloud konfigurieren ==

Im Verzeichnis "$HOME/doms/cloud.example.org/fastcgi-ssl/" eine Datei "php.ini" anlegen mit folgendem Inhalt:

<syntaxhighlight lang=ini>
memory_limit=512M
session.save_path=/home/pacs/xyz00/users/cloud/tmp
</syntaxhighlight>

Dann mit einem Editor diese Datei bearbeiten: In der zweiten Zeile den korrekten Pfad des vorher angelegten tmp-Verzeichnisses eintragen.

Im Browser auf die Seite
http://cloud.example.org gehen und den Anweisungen folgen.

Auf der ersten Seite sind anzugeben:

* Login und Passwort für den Administrator definieren
* PostgreSQL als Datenbanksystem
* PostgreSQL-User und Passwort aus dem ersten Schritt oben
* Name der PostgreSQL-Datenbank aus dem ersten Schritt
* "localhost" als Datenbankserver (Nextcloud 23.0.2 empfiehlt hier die Angabe des Ports, diesen also lt. [[PostgreSQL]] angeben)
* Das Verzeichnis "/home/pacs/xyz00/users/cloud/data/" als Daten-Verzeichnis (bitte beachten: das im Eingabefeld voreingestellte verweist auf das Verzeichnis "/home/pacs/xyz00/users/cloud/'''nextcloud'''/data/")

'''Achtung!''' Die Felder für die Datenbank sind auf dem Startscreen hinter einem unscheinbaren Link versteckt. Um man das Formular für die Datenbank-Daten zu gelangen, muss man auf den Link klicken. Anschließend kann man die gewünschte Datenbank auswählen und die entsprechenden Daten eintragen. '''Das sollte geschehen, bevor man die Installation abschließt!''' Tut man dies nicht, wird Nextcloud mit SQLite installiert. Eine Änderung der Datenbank soll zwar laut Dokumentation auch später noch möglich sein, ging aber bei einem Test schief.

In der Konfigurationsdatei der Nextcloud (in ''~/nextcloud/config/config.php'') lassen sich weitere Voreinstellungen treffen:

<syntaxhighlight lang=php line>
'maintenance_window_start' => 1, // Wartungsfenster ab 1:00 Uhr
'defaultapp' => 'calendar,files', // bei Start wird der Kalender gezeigt
'default_phone_region' => 'DE', // Format Telefonnummern
'default_language' => 'de', // Sprache deutsch
'force_language' => 'de',
'default_locale' => 'de_DE', // Locale (Formatierung Zeitangaben etc.)
'force_locale' => 'de_DE',
</syntaxhighlight>

== Nextcloud beschleunigen ==

Dieser Teil ist optional.

Wenn regelmäßig '''im Browser''' mit Nextcloud gearbeitet werden soll, ist Nextcloud im Browser oft sehr langsam. Um dies zu verbessern, unterstützt Nextcloud die Anwendung von unterschiedlichen Cache-Verfahren (zum Beispiel Memcache, Redis).

=== Redis Cache ===

Redis ist auf den Hostsharing-Servern vorinstalliert und wird von den Nextcloud-Entwicklern empfohlen. Redis wird als eigener Serverdienst gestartet. '''In Verbindung mit Hostsharing Managed Webspace muss für Redis [https://www.hostsharing.net/paas/managed-webspace/ Arbeitsspeicher für eigene Serverdienste] gebucht werden'''.

Die Konfiguration des Redis-Dientes ist auf der Seite [[Redis]] beschrieben. Hier wird für Nextcloud die Variante mit einem Unixsocket benutzt.

In der Konfiguration der Nextcloud (in ''~/nextcloud/config/config.php'') wird der Redis-Cache wie folgt konfiguriert:

<syntaxhighlight lang=php line>
'memcache.local' => '\\OC\\Memcache\\Redis',
'memcache.distributed' => '\\OC\\Memcache\\Redis',
'memcache.locking' => '\\OC\\Memcache\\Redis',
'redis' =>
array (
'host' => '/home/pacs/xyz00/users/cloud/redis/var/redis-server.sock',
'port' => 0,
'password' => 'mein-redis-passwort',
'timeout' => 1.5,
),
</syntaxhighlight>

Um es perfekt zu machen, nutze ich ''logrotate'' um die Logdateien zu organisieren. Dazu die Konfiguration in ''~/.logrotate''

<syntaxhighlight lang=shell line>
compress
/home/pacs/xyz00/users/cloud/redis/var/redis.log {
rotate 5
daily
missingok
}
</syntaxhighlight>
Mit systemd-Timern werden die Logdateien täglich rotiert:

''~/.config/systemd/user/logrotate.service''
<syntaxhighlight lang=ini line>
[Unit]
Description=rotate log files

[Service]
Type=oneshot
ExecStart=/usr/sbin/logrotate -s %h/.logrotate.state %h/.logrotate
</syntaxhighlight>

''~/.config/systemd/user/logrotate.timer''
<syntaxhighlight lang=ini line>
[Unit]
Description=timer for nextcloud cleanup job

[Timer]
OnCalendar=1:1
Persistent=True

[Install]
WantedBy=timers.target
</syntaxhighlight>

Den Timer aktivieren und starten:
<syntaxhighlight lang=shell line>
$ systemctl --user enable logrotate.timer
$ systemctl --user start logrotate.timer
</syntaxhighlight>

=== Nextcloud Cronjob ===

Für die regelmäßigen Hintergrundaufgaben innerhalb der Nextcloud sollte ein Cronjob eingerichtet werden. Wir lösen dies hier mit einem weiteren Systemd-Timer:

''~/.config/systemd/user/nextcloud_background.service''
<syntaxhighlight lang=ini line>
[Unit]
Description=nextcloud cleanup job

[Service]
Type=oneshot
ExecStart=/usr/bin/php %h/nextcloud/cron.php
</syntaxhighlight>

''~/.config/systemd/user/nextcloud_background.timer''
<syntaxhighlight lang=ini line>
[Unit]
Description=timer for nextcloud cleanup job

[Timer]
OnCalendar=*:0/5
Persistent=True

[Install]
WantedBy=timers.target
</syntaxhighlight>

Den Timer aktivieren und starten:
<syntaxhighlight lang=shell line>
$ systemctl --user enable nextcloud_background.timer
$ systemctl --user start nextcloud_background.timer
</syntaxhighlight>

=== Nextcloud Push ===

Um Vorgänge wie Sync und Benachrichtigungen bei sehr großen Nextcloud Installationen zu beschleunigen, kann der <code>notify_push</code> Dienst hinzuinstalliert werden.

==== Abhängigkeiten und Einschränkungen ====
* <code>notify_push</code> muss Zugriff auf den gleichen Redis-Cache wie die Nextcloud haben
** aufgrund von eingeschränktem Passwort Support sollte ein Redis Socket mit sicheren Berechtigungseinstellungen als Alternative zum Redis Port mit Passwort konfiguriert werden.
* optimaler Weise holt sich <code>notify_push</code> benötigte informationen aus der <code>config.php</code> der bestehenden Nextcloud-Installation
* eine zusätzliche (Sub)domain im gleichen User ist nötig. Andernfalls muss die bestehende <code>.htaccess</code> muss aus o.g. Gründen modifiziert werden, dies könnte bei Nextcloud-Updates verloren gehen(!)
* Bestimmte Portbereiche sind bei Hostsharing eingeschränkt, es empfiehlt sich, direkt beispielsweise Port <code>37867</code> zu nehmen. aus diesem Grund ist das automatische Setup durch das Plugin bei Hostsharing nicht möglich!

==== Installation ====
Siehe auch: https://github.com/nextcloud/notify_push#manual-setup

1. Installieren der Nextcloud-App <code>notify_push</code> – (nach Push suchen, "Client Push" wählen) 
2. falls noch nicht erstellt: <code>mkdir -p ~/.config/systemd/user</code> 
3. mit Lieblingseditor die Datei <code>~/.config/systemd/user/notify_push.service</code> anlegen: 
<syntaxhighlight lang="ini" line>
[Unit]
Description = Push daemon for Nextcloud clients
Documentation = https://github.com/nextcloud/notify_push

[Service]
Environment = BIND=127.0.0.1
# Change if you already have something running on this port
Environment = PORT=37867
# We don't want to bind to 0.0.0.0, hence the --bind
ExecStart = /home/pacs/xyz00/users/cloud/bin/notify_push --bind 127.0.0.1 /home/pacs/xyz00/users/cloud/nextcloud/config/config.php
Type=notify

[Install]
WantedBy = default.target
</syntaxhighlight>
4. das Verzeichnis <code>~/bin</code> anlegen und die aktuellste binary herunterladen und ausführbar machen:
<syntaxhighlight lang="shell" line>release=`curl -L https://api.github.com/repos/nextcloud/notify_push/releases/latest -s | jq -r '.tag_name'` && wget --show-progress -qO ~/bin/notify_push https://github.com/nextcloud/notify_push/releases/download/$release/notify_push-x86_64-unknown-linux-musl && chmod +x ~/bin/notify_push</syntaxhighlight>
5. es könnte die folgende Umgebungsvariable zum Bedienen von systemd notwendig werden: <code>export XDG_RUNTIME_DIR=/run/user/$UID</code> 
6. den neuen systemd-Dienst automatisch bei Systemstart, sowie jetzt sofort starten: <code>systemctl enable --now --user notify_push</code> 
7. nun gehen wir in <code>doms/push.cloud.example.com/htdocs-ssl/.htaccess</code> und ersetzen den Inhalt (bevorzugt), oder wir ergänzen die .htaccess der Nextcloud im unteren Teil um die folgenden Zeilen (letzteres kann bei Updates überschrieben werden!):
<syntaxhighlight lang="apache" line>
# bei eigener (sub)domain ist /push/ nicht erforderlich, aber wer weiß, eventuell ist das mit robuster
RewriteCond %{REQUEST_URI} ^/push/ws [NC,OR]
RewriteCond %{HTTP:UPGRADE} ^WebSocket$ [NC,OR]
RewriteCond %{HTTP:CONNECTION} ^Upgrade$ [NC]
RewriteRule .* ws://127.0.0.1:37867/ws [proxy]

RewriteCond %{REQUEST_URI} ^/push [NC]
RewriteRule .* http://127.0.0.1:37867%{REQUEST_URI} [proxy]
</syntaxhighlight>
8. abschließend im Nextcloud Ordner die Konfiguration des Plugins anstoßen: <code>php occ notify_push:setup https://cloud.example.com/push</code> bzw. <code>php occ notify_push:setup https://push.cloud.example.com/push</code> 
9. es ist möglich, das die erkannte IP-Adresse des Hives noch nicht vertraut ist. In diesem Fall wird der obige Befehl scheitern und es muss jene aus der Fehlermeldung des Setups unter <code>trusted_proxies</code> in der <code>config.php</code> ergänzt werden. 

Es wird im Repo außerdem ein Testclient bereitgestellt, der sich testweise mit dem Push-Dienst verbindet

== Nextcloud mit Online Office ==

In Nextcloud können Office-Dokumente (Textverarbeitung, Tabellen und Präsentationen) im Browser bearbeitet werden. Dazu steht bei Hostsharing die Collabora Developer Version zur Verfügung. Bestellung und Konfiguration sind hier im Wiki auf der Seite [[Collabora_Online]] beschrieben.

== Nextcloud mit Nextcloud Talk ==

Über die Nextcloud-App "Talk" können Videokonfererenzen mit Screensharing durchgeführt werden. Für die regelmäßige Nutzung kann es sinnvoll sein, einen eigenen TURN Server zu betreiben. Siehe dazu [[Coturn_Installieren]]

Das Hochleistungs-Backend haben wir mittlerweile bei manchen Mitgliedern bereits im Einsatz. Es wird auf einem Container Server installiert. (siehe auch [[Container#Nextcloud_High_Performance_Backend_mit_Caddy|Nextcloud High Performance Backend auf Container Server]])

Unser Mitglied Timotheus Pokorra bietet auch einen Nextcloud High Performance Backend Server zum Teilen an. Siehe [https://solidevereine.de/organisation/nextcloud/#highperf]

Ohne das Hochleistungs-Backend macht wohl die Audio bzw. Video Funktion kaum Sinn, wenn es mit mehr als 2 Teilnehmern genutzt werden soll. Deswegen empfehlen wir, die Anrufe in Talk zu deaktivieren, und stattdessen die BBB zu benutzen.

Das Deaktivieren der Anrufe geschieht in der Administrationsoberfläche von Nextcloud, unter Talk, "Auf Gruppen beschränken", "Starten von Anrufen begrenzen": "Anrufe deaktivieren"

[[Datei:NextcloudTalkAnrufeDeaktivieren.png]]

Die Warnung wegen dem fehlenden Hochleistungs-Backend lässt sich "entschärfen": in der Einstellungsseite von Talk in der Administrationsoberfläche, ganz oben, deaktiviere: "Vor Verbindungsproblemen bei Anrufen mit mehr als 2 Teilnehmern warnen"

[[Datei:NextcloudTalkWarnungDeaktivieren.png]]

== Virenscanner ==

Einige Nutzer wollen die Dateien in Ihrer Nextcloud regelmäßig auf Viren überprüfen. Auf unseren Servern steht dafür der OpenSource-Virenscanner "ClamAV" zur Verfügung. Wenn dieser Scanner benutzt wird, dann sollten die Einstellungen so gewählt sein, dass der ClamAV-Daemon über eine Socket Verbindung angesprochen wird. Die Einstellungen sind im Screenshot dokumentiert.

* Es wird die App [https://apps.nextcloud.com/apps/files_antivirus Antivirus für Dateien] installiert.
* Bei Modus wird gewählt: <code>ClamAV-Daemon (Socket)</code>
* Bei Socket wird gewählt: <code>/var/run/clamav/clamd.ctl</code>

[[Datei:Nextcloud-ClamAV-Einstellungen.png||nextcloud einstellungen für die virenscanner-app]]

== Volltextsuche ==

Über die Dokumente einer Nextcloud kann ein Volltextindex erstellt werden. Die Volltextsuche ermöglicht über den Index eine Suche über beliebige Begriffe, die in Dokumenten vorkommen.

Voraussetzung ist der Betrieb eines Elasticsearch Servers. Der Betrieb im Managed Webspace erfodert die Buchung von zwei "Serverdiensten". Nutzer eines Managed Server müssen mit einem spürbaren Mehrbedarf an Hauptspeicher rechnen.

Zur Installation von Elasticsearch existiert eine eigene Wikiseite: [[Elasticsearch]].

In der Nextcloud sind folgende ''Apps'' zu installieren:
* Full Text Search
* Full Text Search - Elasticsearch Platform
* Full Text Search - Files

nach der Installation der drei Apps steht in den Einstellungen ein neuer Menüpunkt "Volltextsuche" zur Verfügung.

Hier ist einzustellen:
* Suchplattform: Elasticsearch
* Adresse des Servlets: http://elastic:das-erzeugt-passwort@127.0.0.1:39200
* Index: frei-gewaehlter-name-idx
* Analyzer tokenizer: standard

Die anderen Einstellung nach den eigenen Vorstellungen vornehmen.

Der initiale Aufbau des Suchindex erfolgt über ein "occ"-Kommando auf der Shell:

<syntaxhighlight lang=shell line>
cd nextcloud/
php occ fulltextsearch:index --output
</syntaxhighlight>

Wenn dieser Fehler kommt:
<syntaxhighlight lang=text>
TypeError: Return value of OCA\Files_FullTextSearch\Model\MountPoint::isGlobal()
must be of the type bool, null returned in [...]/apps/files_fulltextsearch/lib/Model/MountPoint.php:103
</syntaxhighlight>
sollte dieser Patch angewendet werden: https://github.com/nextcloud/files_fulltextsearch/issues/125#issuecomment-877789742

Zur Pflege des Indexes wird ein weiterer Hintergrundprozess gestartet:

<syntaxhighlight lang=shell line>
cd nextcloud/
php occ fulltextsearch:live -q
</syntaxhighlight>

Die Monit Konfiguration dafür sieht so aus:

<syntaxhighlight lang=shell line>
#~/bin/start-fulltextsearchlive
#
#!/bin/bash
export HOME=/home/pacs/xyz00/users/cloud
cd $HOME
mkdir -p $HOME/var
cd $HOME/nextcloud
exec php occ fulltextsearch:live -q &
echo $! >$HOME/var/fulltextsearchlive.pid
</syntaxhighlight>

<syntaxhighlight lang=shell line>
#~/bin/stop-fulltextsearchlive
#
#!/bin/bash
export HOME=/home/pacs/xyz00/users/cloud
kill $( cat $HOME/var/fulltextsearchlive.pid )
</syntaxhighlight>

~/.monitrc (siehe oben von der Redis Installation) entsprechend ergänzen:
<syntaxhighlight lang=shell line>
check process fulltextsearchlive with pidfile /home/pacs/xyz00/users/cloud/var/fulltextsearchlive.pid
start program "/home/pacs/xyz00/users/cloud/bin/start-fulltextsearchlive"
stop program "/home/pacs/xyz00/users/cloud/bin/stop-fulltextsearchlive"
</syntaxhighlight>

== Integration mit LDAP ==

Um einheitliche Benutzerzugänge für verschiedene Anwendungen zu ermöglichen, wird oft auf ein zentrales LDAP Verzeichnis gesetzt.

Dieses kann für Nextcloud eingesetzt werden, damit Benutzer nicht lokal in Nextcloud, sondern in LDAP verwaltet werden können.

Siehe auch https://docs.nextcloud.com/server/latest/admin_manual/configuration_user/user_auth_ldap.html

Dazu muss die App "LDAP user and group backend" in den Nextcloud Apps aktiviert werden.

Dann muss die LDAP Anbindung in den Administrationseinstellungen unter "LDAP/AD-Integration" eingerichtet werden.

Der Server mit Port, die BenutzerDN mit Passwort und die BaseDN müssen eingetragen werden.

Es muss auch bestimmt werden, welche Klasse (z.B. inetOrgPerson) die Benutzer brauchen, um Zugriff auf die Nextcloud zu erhalten.

Falls schon Benutzer in der Nextcloud existieren, und diese zu LDAP mitgenommen werden sollen, kann der Anleitung aus diesem Forum Eintrag gefolgt werden: https://help.nextcloud.com/t/migration-to-ldap-keeping-users-and-data/13205

* Voraussetzung ist, dass der Benutzernamen der zu übernehmenden Benutzer in Nextcloud der uid in LDAP entspricht.
* Es wird ein Administrator Benutzer benötigt, der lokal angelegt wurde, und auch lokal bleibt.
* Mit diesem Administrator Benutzer wird die LDAP Anbindung eingerichtet.
* In der Experten Ansicht von LDAP/AD muss bei "Attribut für interne Benutzernamen" eingetragen werden: uid
* Klicke den Schalter "LDAP Benutzernamenzuordnung löschen"
* Klicke den Schalter "LDAP Gruppennamenzuordnung löschen"
* dann in der MySQL Datenbank anmelden, und aus uc_users alle Benutzer bis auf den Administrator Benutzer löschen
* Dann in der Nextcloud Weboberfläche sich alle Benutzer anzeigen lassen
* Nun gelingt die Anmeldung mit den anderen Benutzern mit dem LDAP Passwort, und die Dateien wurden übernommen.

== Optimierung der Geschwindigkeit ==
Manchmal fühlt sich die Nextcloud träge an.

Folgende Änderungen können helfen:

* HTTP/2.0 aktivieren: dem Service von Hostsharing Bescheid geben
* Die App Dashboard deaktivieren, und dafür werden direkt die Dateien angezeigt
* Einblenden der README in den Ordnern abschalten: das kann pro Ordner in der UI geschehen (links unten), oder global: <code>occ config:app:set text workspace_available --value=0</code>. Siehe auch [https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/text_configuration.html#disable-rich-workspaces-globally]

== Default App einstellen ==

In der Datei config.php können wir einstellen, welche App direkt nach der Anmeldung gezeigt wird.

Das ist entweder die Dashboard App, wenn sie aktiviert ist, oder die Dateien App (files).

Falls der Kalender direkt angezeigt werden soll, muss folgende Zeile in der config.php hinzugefügt werden (siehe auch [https://docs.nextcloud.com/server/stable/admin_manual/configuration_server/config_sample_php_parameters.html#defaultapp]):

<syntaxhighlight lang=shell>
'defaultapp' => 'calendar',
</syntaxhighlight>

= Nextcloud Updates =

== Updater über die Shell starten ==

Wenn die NextCloud sich nicht über das Webfrontend updaten lässt, kann der Updater auch per Shell im directory /updater durch ausführen des updater.phar gestartet werden:

<syntaxhighlight lang=shell line>
xyz00-cloud@h00:~$ cd ~/nextcloud
xyz00-cloud@h00:~/nextcloud$ php updater/updater.phar
</syntaxhighlight>

Falls während des Updates kein Backup angelegt werden soll:

<syntaxhighlight lang=shell line>
xyz00-cloud@h00:~$ cd ~/nextcloud
xyz00-cloud@h00:~/nextcloud$ php updater/updater.phar --no-backup
</syntaxhighlight>

Es sollten außerdem ein paar Routine-Aufräumarbeiten durchgeführt werden:

<syntaxhighlight lang=shell line>
xyz00-cloud@h00:~$ cd ~/nextcloud
xyz00-cloud@h00:~/nextcloud$ php occ db:add-missing-primary-keys --no-interaction
xyz00-cloud@h00:~/nextcloud$ php occ db:add-missing-columns --no-interaction
xyz00-cloud@h00:~/nextcloud$ php occ db:add-missing-indices --no-interaction
xyz00-cloud@h00:~/nextcloud$ php occ db:convert-filecache-bigint --no-interaction
xyz00-cloud@h00:~/nextcloud$ php occ maintenance:repair --include-expensive
</syntaxhighlight>

So können die Apps noch alle aktualisiert werden:

<syntaxhighlight lang=shell line>
xyz00-cloud@h00:~$ cd ~/nextcloud
xyz00-cloud@h00:~/nextcloud$ php occ app:update --all -n --no-ansi
</syntaxhighlight>

Für weitere Informationen kann auf die offizielle Doku ab Ziffer 2. zurückgegriffen werden.

* [https://docs.nextcloud.com/server/latest/admin_manual/maintenance/update.html#using-the-command-line-based-updater https://docs.nextcloud.com]

Hier gibt es ein kurzes Video, das die Anmeldung über die Kommandozeile mit Putty erklärt und die Aktualisierung von Nextcloud auf der Kommandozeile:

* [https://tube.solidcharity.net/w/0cf5ee97-ba7c-41df-a56f-8d1fea842ab0 Nextcloud auf der Kommandozeile aktualisieren]

== Wartungsmodus per Shell ein- oder ausschalten ==

So kann der Wartungsmodus angeschaltet werden:

<syntaxhighlight lang=shell line>
xyz00-cloud@h00:~$ cd ~/nextcloud
xyz00-cloud@h00:~/nextcloud$ php occ maintenance:mode --on
</syntaxhighlight>

So kann der Wartungsmodus wieder ausgeschaltet werden, d.h. die Nextcloud ist dann wieder in Betrieb:

<syntaxhighlight lang=shell line>
xyz00-cloud@h00:~$ cd ~/nextcloud
xyz00-cloud@h00:~/nextcloud$ php occ maintenance:mode --off
</syntaxhighlight>

== Webfrontend-Updater Probleme / Lösungen ==

=== Datenbank: Indizes | Primärschlüssel | Konvertierungen ===

Aufgetreten nach erfolgtem Versionsupdate Nextcloud 19 auf Nextcloud 20

Nach dem erfolgten Update lädt automatisch die Seite: '''Sicherheits- und Einrichtungswarnungen''' auf dieser wird angemerkt, dass manuelle Schritte für die Datenbank durchzuführen sind. Dies betrifft Indizes, Primärschlüssel und Konvertierungen.

Per Shell in der directory /nextcloud folgende Kommandos ausführen:

<syntaxhighlight lang=shell line>
xyz00-cloud@h00:~$ cd ~/nextcloud
xyz00-cloud@h00:~/nextcloud$ php occ db:add-missing-primary-keys --no-interaction
xyz00-cloud@h00:~/nextcloud$ php occ db:add-missing-columns --no-interaction
xyz00-cloud@h00:~/nextcloud$ php occ db:add-missing-indices --no-interaction
xyz00-cloud@h00:~/nextcloud$ php occ db:convert-filecache-bigint --no-interaction
xyz00-cloud@h00:~/nextcloud$ php occ maintenance:repair --include-expensive
</syntaxhighlight>

Wichtig ist hier dem durch Nextcloud angegebenen Kommando ein '''php''' voranzustellen.

== Update per Skript ==

Es ist möglich die regelmäßigen Updates weitgehend zu automatisieren. Ein Skript wäre etwa:

<syntaxhighlight lang=shell line>
#!/bin/bash
if [ -f $HOME/nextcloud/occ ]; then
echo "Nextcloud Update";
cd $HOME/nextcloud;
php updater/updater.phar -vv --no-backup --no-interaction
php occ maintenance:mode --on
php occ db:add-missing-primary-keys --no-interaction
php occ db:add-missing-columns --no-interaction
php occ db:add-missing-indices --no-interaction
php occ db:convert-filecache-bigint --no-interaction
php occ maintenance:repair --include-expensive
php occ app:update --all
php occ maintenance:mode --off
else
echo "Keine Nextcloud Installation gefunden";
fi
</syntaxhighlight>

== Update: bei old-stable Version bleiben ==

Normalerweise fragt jede Nextcloud Instanz zentral ab, welches Update zur Verfügung steht, abhängig vom Release Channel. Dabei wird aber relativ schnell auf die nächste Version gewechselt, also z.B. von Nextcloud 31 auf Nextcloud 32, obwohl Nextcloud 31 noch mehrere Monate gepflegt wird, und manche Apps noch nicht bereit sind für Nextcloud 32.

Es kann aber auch eine Alternative eingerichtet werden, in der Datei nextcloud/config/config.php, unter dem Eintrag updater.server.url

Hier wird z.B. auf einen Updater von unserem Mitglied Timotheus Pokorra verwiesen:

<syntaxhighlight lang=php line>
updater_server_url: "https://ncupdater.solidcharity.com/31/"
</syntaxhighlight>

Dahinter läuft ein Skript, mit dem wir noch länger eine bestimmte Version anbieten können: https://codeberg.org/tpokorra/ncupdater

= Daten auf HDD Storage =
== Einrichtung des HDD Storage ==

Um den langsameren aber günstigeren HDD Storage von Hostsharing zu nutzen, kann das data Verzeichnis von SSD auf HDD Storage verschoben werden. Ein symbolischer Link reicht nicht aus, man muss den Pfad in der Nextcloud Konfigurationsdatei anpassen.

<syntaxhighlight lang=shell>
# Nextcloud in Wartungsmodus versetzen
xyz00-cloud@h00:~/nextcloud$ php occ maintenance:mode --on
# Daten auf HDD Storage verschieben
xyz00-cloud@h00:~/nextcloud$ mv data /home/storage/xyz00/users/cloud/
# symbolischen Link anlegen
xyz00-cloud@h00:~/nextcloud$ ln -s /home/storage/xyz00/users/cloud/data data
# Pfad in config.php ändern
nano config/config.php
# Die Zeile mit 'datadirectory' finden und entsprechend ändern:
# 'datadirectory' => '/home/storage/xyz00/users/cloud/data',
# Wartungsmodus beenden
xyz00-cloud@h00:~/nextcloud$ php occ maintenance:mode --off
</syntaxhighlight>

Ein Fallstrick: Im data-Verzeichnis liegt eine versteckte Datei ".ncdata". Beim Move-Befehl "mv" für das komplette Data-Verzeichnis wird diese Datei mit verschoben. Sonst muss die Datei ggf. ins neue data-Verzeichnis kopiert werden!

= Einschränkende Bemerkungen =
== Nextcloud Sync Client ==

Der Nextcloud Sync Client erfüllt eine Funktion ähnlich wie Dropbox, und synchronisiert ganze Ordnerstrukturen.

Gerade wenn man mit mehreren Menschen in einer Nextcloud arbeitet, ist diese Funktion mit Vorsicht zu benutzen.

* Änderungen an der Ordnerstruktur sollten nicht lokal, sondern im Webbrowser vorgenommen werden.
* Wenn die Gefahr besteht, dass mehrere Menschen gleichzeitig eine Datei bearbeiten, sollte die Datei nicht lokal, sondern im Webbrowser bearbeitet werden.
* Aus Sicht des Datenschutzes und der Daten-Minimierung sollte überlegt werden, ob die Daten wirklich auf jeden Laptop und Rechner synchronisiert werden sollen, oder ob es reicht, ausschließlich über den Webbrowser auf die Daten zuzugreifen.

= weiterführende Links =

* [https://docs.nextcloud.com/ Nextcloud Dokumentation]
* [https://apps.nextcloud.com/ Nextcloud Erweiterungen ("Apps")]
* [https://docs.nextcloud.com/server/stable/admin_manual/installation/server_tuning.html Optimierung des Caches z.B. für Previews]
* [https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/nextcloud Ansible Playbook für Hostsharing]

= Nextcloud Reseller bei HS =

[https://nextcloud.ossaas.de OS SaaS]

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]
[[Kategorie:Software]]
[[Kategorie:CalDAV]]
[[Kategorie:Nextcloud]]

Roundcube - Filter

2026-09-03T12:26:15Z

Tim00: /* E-Mail nach Spam Score in den Junk Ordner schieben */

== Roundcube - Filter ==

Das Webmailprogramm [[Roundcube]] erlaubt Emails automatisch zu Filtern. Dieser Artikel beschreibt, wie mit der Erweiterung sieverules solche Filter definiert werden können.

=== Allgemeines zum Filtern ===

Über das Mailzustellungsprogramm Deliver ist es mit der Erweiterung [[Managesieve]] möglich Emails beim Eintreffen in der Mailbox zu Filtern. Die Filterung findet hierbei bereits auf dem Server statt, so daß der User nicht mit seinem Mailprogramm oder Webmailer eingeloggt sein muß.

Hierbei ist es möglich u.a. folgende Aktionen durchzuführen

* Mails in einen bestimmten Ordner abzuspeichern
* Mails an einen anderen Empfänger weiterzuleiten
* eine Abwesenheitsmeldung zu verschicken
* den Empfang einer Email abzulehnen
* eine Mail zu löschen

Die Ausführung dieser Filteraktionen kann gesteuert werden z.B. basierend auf

* dem Absender der eintreffenden Email
* des Titels oder Teilen hiervon
* dem Vorhandensein oder Nichtvorhandensein bestimmter Wörter im Text der Nachricht
* die Auswertung von zusätzlichen Mail-Headern.

[[Bild:Sieve-01-einstellungen.png|miniatur|250px|right|Einstellungen]]
Detaillierte Informationen können z.B. der [http://de.wikipedia.org/wiki/Sieve Wikipedia] oder unter [http://www.sieve.info sieve.info] entnommen werden. Im Hostsharing-Wiki unter [[Managesieve]] sind ebenfalls weitere Grundlageninformationen zu finden.

=== Einrichtung ===

Hinweis: Wenn der Nutzer schon eine .forward mit z.b. procmail nutzt muss wie unter
[https://wiki.hostsharing.net/index.php?title=Managesieve#Zusammenarbeit_mit_Procmail Zusammenarbeit_mit_Procmail]
beschrieben ist beachtet werden.

Filter können unter <tt>Einstellungen</tt> eingerichtet und verändert werden. Hierzu im Menu Einstellungen den Reiter ganz rechts <tt>Filter</tt> auswählen.

 
[[Bild:Sieve-02-mailuebersicht.png|center|none|frame|Ungefilterter Posteingang]]
Für die folgenden Beispiele wird davon ausgegangen, daß der Nutzer in seinem Posteingang ohne Filter die Situation, wie im Bild oben angezeigt vorfindet: Viele Emails aus (drei) Mailinglisten und eine private Email. Alle Mails sind in einem Ordner und erschweren das Finden der ggf. wichtigen privaten Email.

[[Bild:Sieve-03-neuer-filter.png|miniatur|250px|right|Neuen Filter anlegen]]
Zunächst soll ein neuer Filter angelegt werden, der die Emails der Mailingliste <tt>otrs-de</tt> [http://doc.otrs.org/2.2/de/html/additional-resources-mailinglists.html] in einen eigenen Ordner verschiebt.

Hierzu unter der (leeren) Filterliste auf das <tt>+</tt> zum Anlegen eines Neuen Filters klicken.
 
[[Bild:Sieve-04-OTRS-filter.png|miniatur|600px|right|Anlegen eines Filters für eine Mailingliste]]
Im neu geöffneten Formular kann der neue Filter definiert werden.

* '''Filternamen''' vergeben: zum Beispiel OTRS für die entsprechende Maillingliste (oder zur besseren späteren Erinnerung: "Mailingliste otrs-de"). OTRS
* '''Filterregel''': Hier wird definiert unter welchen Bedingungen der Filter angewandt werden soll. Drei Optionen stehen zur Auswahl
** Irgendeine Bedingung muß erfüllt sein (ODER)
** Alle Bedingungen müssen erfüllt sein (UND) Auswählen
** Die Bedingung ist für alle Emails gültig (keine Bedingung notwendig)
* Die Definition der Filterregel beinhaltet das Auswahl eines Teils der Nachricht (z.B. Absender, Datum, Betreff, Text) und einem Wert, mit dem verglichen werden soll. In unserem Beispiel: BETREFF enthält <nowiki>[otrs-de]</nowiki>
* '''Filteraktion''': Die Aktion, die ausgeführt werden soll. Verschiebe Nachricht nach OTRS 
Bei Aktionen, die Nachrichten in andere Ordner verschieben oder kopieren werden die möglichen Ordner die zum Zeitpunkt der Filteranlage existieren in einem Drop-Down-Menu angezeigt.
* '''Speichern'''

[[Bild:Sieve-05-hostsharing-filter.png|miniatur|600px|right|Filter für Mailingliste über Mail-Header und Ausnahme]]
=== Weitere Beispiele ===

==== Maillinglisten Filter ====

Im Beispiel rechts werden wieder die Emails einer Mailinglliste gefiltert. Hier handelt es sich um die <tt>Technik</tt>-Liste von Hostsharing.

Der Filter erhält folgende Kriterien:
* '''Filterregel''': Der Filter wird '''nicht''' angewandt, wenn der Text der Nachricht das Wort "Festplattencrash" enthält, der Empfänger, solche Emails also in seinem Posteingang behalten möchte. Darüber hinaus wird die Mailingliste identifiziert über den Mail-Header <tt>List-Id</tt>. Solche zusätzlichen Mail-Header können über die Auswahl "Anderer Header" ausgewählt werden. Beide Bedingungen müssen erfüllt sein (UND), also "trifft alle folgenden Regeln" auswählen.
* '''Filteraktion''': Wie im ersten Beispiele wieder das Verschieben in einen Ordner, hier <tt>hostsharing</tt>.

 
[[Bild:Sieve-06-abwesenheitsmeldung-filter.png|miniatur|600px|right|Abwesenheitsmeldung]]
==== Abwesenheitsmeldung ====

Nutzer möchten oft bei längerer Abwesenheit dem Absender einer Email mitteilen, daß sie die empfangene Email z.B. wegen Urlaubs nicht lesen können. Hierzu kann eine Abwesenheitsmeldung definiert werden, die automatisch eine Antwort-Email generiert mit einem vordefinierten Text.

Im Beispiel sollen die Absender "peter.lustig" und "Wickie" keine Abwesenheitsmeldung erhalten, sowie bei Emails, die das Wort "Werbung" im Betreff enthalten auch keine Abwesenheitsmeldung verschickt werden.
* "Absender enthält nicht 'peter.lustig'" - Ein Vergleich mit der Email-''Adresse'' wird durchgeführt. Peter <peter.lustig@example.org> - Hier ist peter.lustig in der Adresse enthalten Peter.Lustig <peter@example.org> - Hier ist peter.lustig ''nicht'' in der ''Adresse'' enthalten.
* "Anderer Header "From" enthält nicht 'Wickie'" - Ein Vergleich mit der ''kompletten Absender-Angabe'' wird durchgeführt ''Susanne <wickie@example.org>'' aber auch ''Wickie <susanne@example.org>'' werden gefunden
* "Betreff enthält nicht 'Werbung' - Das Wort Werbung darf nicht im Betreff enthalten sein.

In den '''Filteraktionen''' wird die Aktion "Abwesenheitsmeldung" ausgewählt.
* '''Absender''': Hat man mehrere Identitäten in Webmail angelegt, kann man hier aussuchen unter welchem Absender die Abwesenheitsmeldung geschickt werden soll.
* '''Alias''': Die Vacation-Extension schickt Abwesenheitsmeldungen '''nur''' wenn die Mail an eine dem System für ''diesen'' Account bekannte Email-Adresse geschickt wurde. Im konkreten Fall bei der Erstellung über Roundcube müssen also für jede Email-Adresse Identitäten angelegt werden, also z.B. sowohl max.mustermann@example.org und maexchen@example.org. Diese müssen dann auch unter "Alias" explizit ausgewählt werden. Werden Emails an den Account mit einer anderen Empfänger-Adresse geschickt, erhalten diese '''keine''' Abwesenheitsmeldung. siehe auch [http://tools.ietf.org/html/rfc5230#section-4.5 RFC5230] Abschnitt 4.5
* '''Zeitraum''': Sagt aus, nach wieviel Tagen ein Absender eine erneute Abwesenheitsmeldung erhält. Im Beispiel also z.B. nur einmal alle 3 Tage. Wenn der Absender dazwischen neue Emails versendet, erhält er keine neue Abwesenheitsmeldung. Nach 3 Tagen wird bei erneuten Emails wieder eine Abwesenheitsmeldung verschickt. Hierz speichert sich <tt>deliver</tt> eine Liste der Empfänger.
* '''Betreff''': Der Betreff der Abwesenheitsmeldung, z.B. "Abwesenheit - Urlaub"; der originale Betreff der Email kann zur Identifizierung angehängt werden. Wird also automatisch auf eine Mail "Geburtstagseinladung" geantwortet, wäre der Betreff der Abwesenheitsmeldung "Abwesenheit - Urlaub Geburtstagseinladung".
* '''Nachricht''': Der eigentliche Text der Abwesenheitsmeldung, z.B. Dauer der Abwesenheitsmeldung, Vertretungsregelung, Erreichbarkeit.

[[Bild:Sieve-07-reihenfolge-a.png|miniatur|300px|left|Reihenfolge Filter ändern über Pfeile]]
[[Bild:Sieve-07-reihenfolge-b.png|miniatur|300px|right|Nach Änderung der Reihenfolge]]
===== Reihenfolge von Filtern =====

Insbesondere bei Abwesenheitsmeldungen ist die Reihenfolge der Filter wichtig. Im Beispiel links wird der Filter "osm" erst nach der Abwesenheitsmeldung angewandt, Mails, die durch diesen Filter nicht schon wegsortiert wurden, erhalten also eine Abwesenheitsmeldung. Wenn dies unerwünscht ist, muß der Filter '''vor''' den Filter der Abwesenheitsmeldung verschoben werden (über die Pfeile rechts neben des Filterliste).

 
In (u.a.) folgenden Fällen werden '''Abwesenheitsmeldungen vom System nicht verschickt''':
* Die Absenderadresse deutet auf eine Mailingliste hin, z.B. beginnt mit: ''mailer-daemon'', ''listserv'', ''majordomo'', ''owner-'' oder enthält ''-request''
* Es existiert ein Header "Precedence" der ''junk'', ''bulk'' oder ''list'' enthält.
* Der Empfänger der Nachricht steht nicht in ''To'' oder ''Cc''.
* Sender und Empfänger haben dieselbe Email-Adresse.

[[Bild:Sieve-08-kopiesenden.png|miniatur|600px|right|TEXT]]

==== Kopie an anderen Empfänger versenden. ====

Eine erhaltene Email soll an eine andere Email-Adresse (in Kopie) weitergeleitet werden, z.B. von der Privatadresse an die Geschäftsadresse.

* '''Filterregel''': In diesem Beispiel soll der lokale Teil der Absender-Adresse verglichen werden. "Absender" wählen, dann "weitere Optionen" '''(1)''' und unter ''Operatoren'' ''User-Teil gleich''. '''(2)''' Im Beispiel wurde der User-Teil mit ''susanne.musterfrau'' '''(3)''' angegeben. Zur Email-Adresse ''susanne.musterfrau@example.de'' wird ein Match gefunden für ''sara-susanne.musterfrau@example.org'' hingegen nicht, weil der lokale Teil der Email-Adresse nicht übereinstimmt.
* '''Filteraktionen''': "Sende eine Kopie an" wählen '''(4)''' und eine Ziel-Adresse angeben.

 

[[Bild:Sieve-09-filter-abschalten-a.png|miniatur|400px|left|Filter abschalten]]
[[Bild:Sieve-09-filter-abschalten-b.png|miniatur|300px|right|Filterübersicht im inaktivem Filter]]
<div style="clear: both"></div>
==== E-Mail nach Spam Score in den Junk Ordner schieben ====

Wenn eine E-Mail eine bestimmte Einstufung von Spam hat, soll die E-Mail in den Spam Ordner geschoben werden.

Dazu muss anstelle von "Betreff" der Eintrag mit den 3 Punkten gewählt werden (...), um dort von Hand "X-Spam-Level" einzugeben.

Mit der Anzahl der Sterne bestimmt man, ab welcher Einstufung eine E-Mail als Spam kategorisiert wird.

[[Bild:Roundcube Sieve X-Spam-Level.png|miniatur|600px|X-Spam-Level filtern]]
<div style="clear: both"></div>

==== Filter deaktivieren/aktivieren ====

Soll ein Filter temporär deaktivitert werden, kann in der Filterbearbeitung '''Filterregel abschalten''' angeklickt werden. In der Filterübersicht ist der Filter dann als ''"(abgeschaltet)"'' markiert.

 
[[Bild:Sieve-10-nach-anwendung-filter.png|miniatur|600px|right|Nach dem Filtern]]
==== Nach dem Filtern ====

Die im obigen Beispiel gezeigte Inbox mit über 200 Emails sieht nach Anwendung der Filter wie im nebenstehenden Bild aus.

* Im Posteingang '''(1)''' ist nur noch eine private Email vorhanden
* Die Emails and die Mailinglisten wurden in die jeweiligen Ordner '''(2)''' einsortiert.

=== Technisches ===

==== Speicherort ====

Roundcube speichert die erstellten Regeln unter
<syntaxhighlight lang=shell>
~/Maildir/sieve/roundcube.sieve
</syntaxhighlight>

und verlinkt diese Filterdatei automatisch für die Benutzung mit dovecot:
<syntaxhighlight lang=shell>
xyz00@h01:~$ ls -al
drwxr-xr-x 5 xyz00-max xyz00 4096 Nov 16 07:28 .
drwxr-xr-x 28 xyz00-max xyz00 4096 Oct 22 23:06 ..
lrwxrwxrwx 1 xyz00-max xyz00 29 Nov 16 07:28 .dovecot.sieve -> Maildir/sieve/roundcube.sieve
</syntaxhighlight>
Wurden von anderen Programmen -- oder manuell -- andere Filtersets angelegt, werden diese vom Plugin deaktiviert. Die ursprüngliche Filterdatei bleibt erhalten, aber obiger Symlink verweist dann auf die Roundcube-Filter.

==== Manuelles Editieren ====

Vom manuellen Bearbeiten der Filterdatei <tt>roundcube.sieve</tt> wird abgeraten, da bei erneutem Einlesen durch das Roundcube-Plugin diese Regeln mit großer Wahrscheinlichkeit wieder automatisch umgeschrieben werden.

Für komplexeres Filtern kann eine komplett manuelle Datei angelegt werden und entsprechend verlinkt werden. Siehe auch den Artikel zu [[Managesieve]].

==== Links ====

Einige Sieve-relevante Links, sind im entsprechenden [https://wiki.hostsharing.net/index.php?title=Managesieve#Links Managesieve Wiki-Artikel] angegeben:
----
[[Kategorie:HSDoku]]
[[Kategorie:E-Mail]]
[[Kategorie:Glossar]]

Roundcube - Filter

2026-09-03T12:24:37Z

Tim00: /* Kopie an anderen Empfänger versenden. */

== Roundcube - Filter ==

Das Webmailprogramm [[Roundcube]] erlaubt Emails automatisch zu Filtern. Dieser Artikel beschreibt, wie mit der Erweiterung sieverules solche Filter definiert werden können.

=== Allgemeines zum Filtern ===

Über das Mailzustellungsprogramm Deliver ist es mit der Erweiterung [[Managesieve]] möglich Emails beim Eintreffen in der Mailbox zu Filtern. Die Filterung findet hierbei bereits auf dem Server statt, so daß der User nicht mit seinem Mailprogramm oder Webmailer eingeloggt sein muß.

Hierbei ist es möglich u.a. folgende Aktionen durchzuführen

* Mails in einen bestimmten Ordner abzuspeichern
* Mails an einen anderen Empfänger weiterzuleiten
* eine Abwesenheitsmeldung zu verschicken
* den Empfang einer Email abzulehnen
* eine Mail zu löschen

Die Ausführung dieser Filteraktionen kann gesteuert werden z.B. basierend auf

* dem Absender der eintreffenden Email
* des Titels oder Teilen hiervon
* dem Vorhandensein oder Nichtvorhandensein bestimmter Wörter im Text der Nachricht
* die Auswertung von zusätzlichen Mail-Headern.

[[Bild:Sieve-01-einstellungen.png|miniatur|250px|right|Einstellungen]]
Detaillierte Informationen können z.B. der [http://de.wikipedia.org/wiki/Sieve Wikipedia] oder unter [http://www.sieve.info sieve.info] entnommen werden. Im Hostsharing-Wiki unter [[Managesieve]] sind ebenfalls weitere Grundlageninformationen zu finden.

=== Einrichtung ===

Hinweis: Wenn der Nutzer schon eine .forward mit z.b. procmail nutzt muss wie unter
[https://wiki.hostsharing.net/index.php?title=Managesieve#Zusammenarbeit_mit_Procmail Zusammenarbeit_mit_Procmail]
beschrieben ist beachtet werden.

Filter können unter <tt>Einstellungen</tt> eingerichtet und verändert werden. Hierzu im Menu Einstellungen den Reiter ganz rechts <tt>Filter</tt> auswählen.

 
[[Bild:Sieve-02-mailuebersicht.png|center|none|frame|Ungefilterter Posteingang]]
Für die folgenden Beispiele wird davon ausgegangen, daß der Nutzer in seinem Posteingang ohne Filter die Situation, wie im Bild oben angezeigt vorfindet: Viele Emails aus (drei) Mailinglisten und eine private Email. Alle Mails sind in einem Ordner und erschweren das Finden der ggf. wichtigen privaten Email.

[[Bild:Sieve-03-neuer-filter.png|miniatur|250px|right|Neuen Filter anlegen]]
Zunächst soll ein neuer Filter angelegt werden, der die Emails der Mailingliste <tt>otrs-de</tt> [http://doc.otrs.org/2.2/de/html/additional-resources-mailinglists.html] in einen eigenen Ordner verschiebt.

Hierzu unter der (leeren) Filterliste auf das <tt>+</tt> zum Anlegen eines Neuen Filters klicken.
 
[[Bild:Sieve-04-OTRS-filter.png|miniatur|600px|right|Anlegen eines Filters für eine Mailingliste]]
Im neu geöffneten Formular kann der neue Filter definiert werden.

* '''Filternamen''' vergeben: zum Beispiel OTRS für die entsprechende Maillingliste (oder zur besseren späteren Erinnerung: "Mailingliste otrs-de"). OTRS
* '''Filterregel''': Hier wird definiert unter welchen Bedingungen der Filter angewandt werden soll. Drei Optionen stehen zur Auswahl
** Irgendeine Bedingung muß erfüllt sein (ODER)
** Alle Bedingungen müssen erfüllt sein (UND) Auswählen
** Die Bedingung ist für alle Emails gültig (keine Bedingung notwendig)
* Die Definition der Filterregel beinhaltet das Auswahl eines Teils der Nachricht (z.B. Absender, Datum, Betreff, Text) und einem Wert, mit dem verglichen werden soll. In unserem Beispiel: BETREFF enthält <nowiki>[otrs-de]</nowiki>
* '''Filteraktion''': Die Aktion, die ausgeführt werden soll. Verschiebe Nachricht nach OTRS 
Bei Aktionen, die Nachrichten in andere Ordner verschieben oder kopieren werden die möglichen Ordner die zum Zeitpunkt der Filteranlage existieren in einem Drop-Down-Menu angezeigt.
* '''Speichern'''

[[Bild:Sieve-05-hostsharing-filter.png|miniatur|600px|right|Filter für Mailingliste über Mail-Header und Ausnahme]]
=== Weitere Beispiele ===

==== Maillinglisten Filter ====

Im Beispiel rechts werden wieder die Emails einer Mailinglliste gefiltert. Hier handelt es sich um die <tt>Technik</tt>-Liste von Hostsharing.

Der Filter erhält folgende Kriterien:
* '''Filterregel''': Der Filter wird '''nicht''' angewandt, wenn der Text der Nachricht das Wort "Festplattencrash" enthält, der Empfänger, solche Emails also in seinem Posteingang behalten möchte. Darüber hinaus wird die Mailingliste identifiziert über den Mail-Header <tt>List-Id</tt>. Solche zusätzlichen Mail-Header können über die Auswahl "Anderer Header" ausgewählt werden. Beide Bedingungen müssen erfüllt sein (UND), also "trifft alle folgenden Regeln" auswählen.
* '''Filteraktion''': Wie im ersten Beispiele wieder das Verschieben in einen Ordner, hier <tt>hostsharing</tt>.

 
[[Bild:Sieve-06-abwesenheitsmeldung-filter.png|miniatur|600px|right|Abwesenheitsmeldung]]
==== Abwesenheitsmeldung ====

Nutzer möchten oft bei längerer Abwesenheit dem Absender einer Email mitteilen, daß sie die empfangene Email z.B. wegen Urlaubs nicht lesen können. Hierzu kann eine Abwesenheitsmeldung definiert werden, die automatisch eine Antwort-Email generiert mit einem vordefinierten Text.

Im Beispiel sollen die Absender "peter.lustig" und "Wickie" keine Abwesenheitsmeldung erhalten, sowie bei Emails, die das Wort "Werbung" im Betreff enthalten auch keine Abwesenheitsmeldung verschickt werden.
* "Absender enthält nicht 'peter.lustig'" - Ein Vergleich mit der Email-''Adresse'' wird durchgeführt. Peter <peter.lustig@example.org> - Hier ist peter.lustig in der Adresse enthalten Peter.Lustig <peter@example.org> - Hier ist peter.lustig ''nicht'' in der ''Adresse'' enthalten.
* "Anderer Header "From" enthält nicht 'Wickie'" - Ein Vergleich mit der ''kompletten Absender-Angabe'' wird durchgeführt ''Susanne <wickie@example.org>'' aber auch ''Wickie <susanne@example.org>'' werden gefunden
* "Betreff enthält nicht 'Werbung' - Das Wort Werbung darf nicht im Betreff enthalten sein.

In den '''Filteraktionen''' wird die Aktion "Abwesenheitsmeldung" ausgewählt.
* '''Absender''': Hat man mehrere Identitäten in Webmail angelegt, kann man hier aussuchen unter welchem Absender die Abwesenheitsmeldung geschickt werden soll.
* '''Alias''': Die Vacation-Extension schickt Abwesenheitsmeldungen '''nur''' wenn die Mail an eine dem System für ''diesen'' Account bekannte Email-Adresse geschickt wurde. Im konkreten Fall bei der Erstellung über Roundcube müssen also für jede Email-Adresse Identitäten angelegt werden, also z.B. sowohl max.mustermann@example.org und maexchen@example.org. Diese müssen dann auch unter "Alias" explizit ausgewählt werden. Werden Emails an den Account mit einer anderen Empfänger-Adresse geschickt, erhalten diese '''keine''' Abwesenheitsmeldung. siehe auch [http://tools.ietf.org/html/rfc5230#section-4.5 RFC5230] Abschnitt 4.5
* '''Zeitraum''': Sagt aus, nach wieviel Tagen ein Absender eine erneute Abwesenheitsmeldung erhält. Im Beispiel also z.B. nur einmal alle 3 Tage. Wenn der Absender dazwischen neue Emails versendet, erhält er keine neue Abwesenheitsmeldung. Nach 3 Tagen wird bei erneuten Emails wieder eine Abwesenheitsmeldung verschickt. Hierz speichert sich <tt>deliver</tt> eine Liste der Empfänger.
* '''Betreff''': Der Betreff der Abwesenheitsmeldung, z.B. "Abwesenheit - Urlaub"; der originale Betreff der Email kann zur Identifizierung angehängt werden. Wird also automatisch auf eine Mail "Geburtstagseinladung" geantwortet, wäre der Betreff der Abwesenheitsmeldung "Abwesenheit - Urlaub Geburtstagseinladung".
* '''Nachricht''': Der eigentliche Text der Abwesenheitsmeldung, z.B. Dauer der Abwesenheitsmeldung, Vertretungsregelung, Erreichbarkeit.

[[Bild:Sieve-07-reihenfolge-a.png|miniatur|300px|left|Reihenfolge Filter ändern über Pfeile]]
[[Bild:Sieve-07-reihenfolge-b.png|miniatur|300px|right|Nach Änderung der Reihenfolge]]
===== Reihenfolge von Filtern =====

Insbesondere bei Abwesenheitsmeldungen ist die Reihenfolge der Filter wichtig. Im Beispiel links wird der Filter "osm" erst nach der Abwesenheitsmeldung angewandt, Mails, die durch diesen Filter nicht schon wegsortiert wurden, erhalten also eine Abwesenheitsmeldung. Wenn dies unerwünscht ist, muß der Filter '''vor''' den Filter der Abwesenheitsmeldung verschoben werden (über die Pfeile rechts neben des Filterliste).

 
In (u.a.) folgenden Fällen werden '''Abwesenheitsmeldungen vom System nicht verschickt''':
* Die Absenderadresse deutet auf eine Mailingliste hin, z.B. beginnt mit: ''mailer-daemon'', ''listserv'', ''majordomo'', ''owner-'' oder enthält ''-request''
* Es existiert ein Header "Precedence" der ''junk'', ''bulk'' oder ''list'' enthält.
* Der Empfänger der Nachricht steht nicht in ''To'' oder ''Cc''.
* Sender und Empfänger haben dieselbe Email-Adresse.

[[Bild:Sieve-08-kopiesenden.png|miniatur|600px|right|TEXT]]

==== Kopie an anderen Empfänger versenden. ====

Eine erhaltene Email soll an eine andere Email-Adresse (in Kopie) weitergeleitet werden, z.B. von der Privatadresse an die Geschäftsadresse.

* '''Filterregel''': In diesem Beispiel soll der lokale Teil der Absender-Adresse verglichen werden. "Absender" wählen, dann "weitere Optionen" '''(1)''' und unter ''Operatoren'' ''User-Teil gleich''. '''(2)''' Im Beispiel wurde der User-Teil mit ''susanne.musterfrau'' '''(3)''' angegeben. Zur Email-Adresse ''susanne.musterfrau@example.de'' wird ein Match gefunden für ''sara-susanne.musterfrau@example.org'' hingegen nicht, weil der lokale Teil der Email-Adresse nicht übereinstimmt.
* '''Filteraktionen''': "Sende eine Kopie an" wählen '''(4)''' und eine Ziel-Adresse angeben.

 

[[Bild:Sieve-09-filter-abschalten-a.png|miniatur|400px|left|Filter abschalten]]
[[Bild:Sieve-09-filter-abschalten-b.png|miniatur|300px|right|Filterübersicht im inaktivem Filter]]
<div style="clear: both"></div>
==== E-Mail nach Spam Score in den Junk Ordner schieben ====

Wenn eine E-Mail eine bestimmte Einstufung von Spam hat, soll die E-Mail in den Spam Ordner geschoben werden.

[[Bild:Roundcube Sieve X-Spam-Level.png|miniatur|600px|X-Spam-Level filtern]]
<div style="clear: both"></div>

==== Filter deaktivieren/aktivieren ====

Soll ein Filter temporär deaktivitert werden, kann in der Filterbearbeitung '''Filterregel abschalten''' angeklickt werden. In der Filterübersicht ist der Filter dann als ''"(abgeschaltet)"'' markiert.

 
[[Bild:Sieve-10-nach-anwendung-filter.png|miniatur|600px|right|Nach dem Filtern]]
==== Nach dem Filtern ====

Die im obigen Beispiel gezeigte Inbox mit über 200 Emails sieht nach Anwendung der Filter wie im nebenstehenden Bild aus.

* Im Posteingang '''(1)''' ist nur noch eine private Email vorhanden
* Die Emails and die Mailinglisten wurden in die jeweiligen Ordner '''(2)''' einsortiert.

=== Technisches ===

==== Speicherort ====

Roundcube speichert die erstellten Regeln unter
<syntaxhighlight lang=shell>
~/Maildir/sieve/roundcube.sieve
</syntaxhighlight>

und verlinkt diese Filterdatei automatisch für die Benutzung mit dovecot:
<syntaxhighlight lang=shell>
xyz00@h01:~$ ls -al
drwxr-xr-x 5 xyz00-max xyz00 4096 Nov 16 07:28 .
drwxr-xr-x 28 xyz00-max xyz00 4096 Oct 22 23:06 ..
lrwxrwxrwx 1 xyz00-max xyz00 29 Nov 16 07:28 .dovecot.sieve -> Maildir/sieve/roundcube.sieve
</syntaxhighlight>
Wurden von anderen Programmen -- oder manuell -- andere Filtersets angelegt, werden diese vom Plugin deaktiviert. Die ursprüngliche Filterdatei bleibt erhalten, aber obiger Symlink verweist dann auf die Roundcube-Filter.

==== Manuelles Editieren ====

Vom manuellen Bearbeiten der Filterdatei <tt>roundcube.sieve</tt> wird abgeraten, da bei erneutem Einlesen durch das Roundcube-Plugin diese Regeln mit großer Wahrscheinlichkeit wieder automatisch umgeschrieben werden.

Für komplexeres Filtern kann eine komplett manuelle Datei angelegt werden und entsprechend verlinkt werden. Siehe auch den Artikel zu [[Managesieve]].

==== Links ====

Einige Sieve-relevante Links, sind im entsprechenden [https://wiki.hostsharing.net/index.php?title=Managesieve#Links Managesieve Wiki-Artikel] angegeben:
----
[[Kategorie:HSDoku]]
[[Kategorie:E-Mail]]
[[Kategorie:Glossar]]

Datei:Roundcube Sieve X-Spam-Level.png

2026-09-03T12:22:38Z

Tim00:

Roundcube - Filter

2026-09-03T12:19:49Z

Tim00: Änderung 7636 von Tim00 (Diskussion) rückgängig gemacht.

== Roundcube - Filter ==

Das Webmailprogramm [[Roundcube]] erlaubt Emails automatisch zu Filtern. Dieser Artikel beschreibt, wie mit der Erweiterung sieverules solche Filter definiert werden können.

=== Allgemeines zum Filtern ===

Über das Mailzustellungsprogramm Deliver ist es mit der Erweiterung [[Managesieve]] möglich Emails beim Eintreffen in der Mailbox zu Filtern. Die Filterung findet hierbei bereits auf dem Server statt, so daß der User nicht mit seinem Mailprogramm oder Webmailer eingeloggt sein muß.

Hierbei ist es möglich u.a. folgende Aktionen durchzuführen

* Mails in einen bestimmten Ordner abzuspeichern
* Mails an einen anderen Empfänger weiterzuleiten
* eine Abwesenheitsmeldung zu verschicken
* den Empfang einer Email abzulehnen
* eine Mail zu löschen

Die Ausführung dieser Filteraktionen kann gesteuert werden z.B. basierend auf

* dem Absender der eintreffenden Email
* des Titels oder Teilen hiervon
* dem Vorhandensein oder Nichtvorhandensein bestimmter Wörter im Text der Nachricht
* die Auswertung von zusätzlichen Mail-Headern.

[[Bild:Sieve-01-einstellungen.png|miniatur|250px|right|Einstellungen]]
Detaillierte Informationen können z.B. der [http://de.wikipedia.org/wiki/Sieve Wikipedia] oder unter [http://www.sieve.info sieve.info] entnommen werden. Im Hostsharing-Wiki unter [[Managesieve]] sind ebenfalls weitere Grundlageninformationen zu finden.

=== Einrichtung ===

Hinweis: Wenn der Nutzer schon eine .forward mit z.b. procmail nutzt muss wie unter
[https://wiki.hostsharing.net/index.php?title=Managesieve#Zusammenarbeit_mit_Procmail Zusammenarbeit_mit_Procmail]
beschrieben ist beachtet werden.

Filter können unter <tt>Einstellungen</tt> eingerichtet und verändert werden. Hierzu im Menu Einstellungen den Reiter ganz rechts <tt>Filter</tt> auswählen.

 
[[Bild:Sieve-02-mailuebersicht.png|center|none|frame|Ungefilterter Posteingang]]
Für die folgenden Beispiele wird davon ausgegangen, daß der Nutzer in seinem Posteingang ohne Filter die Situation, wie im Bild oben angezeigt vorfindet: Viele Emails aus (drei) Mailinglisten und eine private Email. Alle Mails sind in einem Ordner und erschweren das Finden der ggf. wichtigen privaten Email.

[[Bild:Sieve-03-neuer-filter.png|miniatur|250px|right|Neuen Filter anlegen]]
Zunächst soll ein neuer Filter angelegt werden, der die Emails der Mailingliste <tt>otrs-de</tt> [http://doc.otrs.org/2.2/de/html/additional-resources-mailinglists.html] in einen eigenen Ordner verschiebt.

Hierzu unter der (leeren) Filterliste auf das <tt>+</tt> zum Anlegen eines Neuen Filters klicken.
 
[[Bild:Sieve-04-OTRS-filter.png|miniatur|600px|right|Anlegen eines Filters für eine Mailingliste]]
Im neu geöffneten Formular kann der neue Filter definiert werden.

* '''Filternamen''' vergeben: zum Beispiel OTRS für die entsprechende Maillingliste (oder zur besseren späteren Erinnerung: "Mailingliste otrs-de"). OTRS
* '''Filterregel''': Hier wird definiert unter welchen Bedingungen der Filter angewandt werden soll. Drei Optionen stehen zur Auswahl
** Irgendeine Bedingung muß erfüllt sein (ODER)
** Alle Bedingungen müssen erfüllt sein (UND) Auswählen
** Die Bedingung ist für alle Emails gültig (keine Bedingung notwendig)
* Die Definition der Filterregel beinhaltet das Auswahl eines Teils der Nachricht (z.B. Absender, Datum, Betreff, Text) und einem Wert, mit dem verglichen werden soll. In unserem Beispiel: BETREFF enthält <nowiki>[otrs-de]</nowiki>
* '''Filteraktion''': Die Aktion, die ausgeführt werden soll. Verschiebe Nachricht nach OTRS 
Bei Aktionen, die Nachrichten in andere Ordner verschieben oder kopieren werden die möglichen Ordner die zum Zeitpunkt der Filteranlage existieren in einem Drop-Down-Menu angezeigt.
* '''Speichern'''

[[Bild:Sieve-05-hostsharing-filter.png|miniatur|600px|right|Filter für Mailingliste über Mail-Header und Ausnahme]]
=== Weitere Beispiele ===

==== Maillinglisten Filter ====

Im Beispiel rechts werden wieder die Emails einer Mailinglliste gefiltert. Hier handelt es sich um die <tt>Technik</tt>-Liste von Hostsharing.

Der Filter erhält folgende Kriterien:
* '''Filterregel''': Der Filter wird '''nicht''' angewandt, wenn der Text der Nachricht das Wort "Festplattencrash" enthält, der Empfänger, solche Emails also in seinem Posteingang behalten möchte. Darüber hinaus wird die Mailingliste identifiziert über den Mail-Header <tt>List-Id</tt>. Solche zusätzlichen Mail-Header können über die Auswahl "Anderer Header" ausgewählt werden. Beide Bedingungen müssen erfüllt sein (UND), also "trifft alle folgenden Regeln" auswählen.
* '''Filteraktion''': Wie im ersten Beispiele wieder das Verschieben in einen Ordner, hier <tt>hostsharing</tt>.

 
[[Bild:Sieve-06-abwesenheitsmeldung-filter.png|miniatur|600px|right|Abwesenheitsmeldung]]
==== Abwesenheitsmeldung ====

Nutzer möchten oft bei längerer Abwesenheit dem Absender einer Email mitteilen, daß sie die empfangene Email z.B. wegen Urlaubs nicht lesen können. Hierzu kann eine Abwesenheitsmeldung definiert werden, die automatisch eine Antwort-Email generiert mit einem vordefinierten Text.

Im Beispiel sollen die Absender "peter.lustig" und "Wickie" keine Abwesenheitsmeldung erhalten, sowie bei Emails, die das Wort "Werbung" im Betreff enthalten auch keine Abwesenheitsmeldung verschickt werden.
* "Absender enthält nicht 'peter.lustig'" - Ein Vergleich mit der Email-''Adresse'' wird durchgeführt. Peter <peter.lustig@example.org> - Hier ist peter.lustig in der Adresse enthalten Peter.Lustig <peter@example.org> - Hier ist peter.lustig ''nicht'' in der ''Adresse'' enthalten.
* "Anderer Header "From" enthält nicht 'Wickie'" - Ein Vergleich mit der ''kompletten Absender-Angabe'' wird durchgeführt ''Susanne <wickie@example.org>'' aber auch ''Wickie <susanne@example.org>'' werden gefunden
* "Betreff enthält nicht 'Werbung' - Das Wort Werbung darf nicht im Betreff enthalten sein.

In den '''Filteraktionen''' wird die Aktion "Abwesenheitsmeldung" ausgewählt.
* '''Absender''': Hat man mehrere Identitäten in Webmail angelegt, kann man hier aussuchen unter welchem Absender die Abwesenheitsmeldung geschickt werden soll.
* '''Alias''': Die Vacation-Extension schickt Abwesenheitsmeldungen '''nur''' wenn die Mail an eine dem System für ''diesen'' Account bekannte Email-Adresse geschickt wurde. Im konkreten Fall bei der Erstellung über Roundcube müssen also für jede Email-Adresse Identitäten angelegt werden, also z.B. sowohl max.mustermann@example.org und maexchen@example.org. Diese müssen dann auch unter "Alias" explizit ausgewählt werden. Werden Emails an den Account mit einer anderen Empfänger-Adresse geschickt, erhalten diese '''keine''' Abwesenheitsmeldung. siehe auch [http://tools.ietf.org/html/rfc5230#section-4.5 RFC5230] Abschnitt 4.5
* '''Zeitraum''': Sagt aus, nach wieviel Tagen ein Absender eine erneute Abwesenheitsmeldung erhält. Im Beispiel also z.B. nur einmal alle 3 Tage. Wenn der Absender dazwischen neue Emails versendet, erhält er keine neue Abwesenheitsmeldung. Nach 3 Tagen wird bei erneuten Emails wieder eine Abwesenheitsmeldung verschickt. Hierz speichert sich <tt>deliver</tt> eine Liste der Empfänger.
* '''Betreff''': Der Betreff der Abwesenheitsmeldung, z.B. "Abwesenheit - Urlaub"; der originale Betreff der Email kann zur Identifizierung angehängt werden. Wird also automatisch auf eine Mail "Geburtstagseinladung" geantwortet, wäre der Betreff der Abwesenheitsmeldung "Abwesenheit - Urlaub Geburtstagseinladung".
* '''Nachricht''': Der eigentliche Text der Abwesenheitsmeldung, z.B. Dauer der Abwesenheitsmeldung, Vertretungsregelung, Erreichbarkeit.

[[Bild:Sieve-07-reihenfolge-a.png|miniatur|300px|left|Reihenfolge Filter ändern über Pfeile]]
[[Bild:Sieve-07-reihenfolge-b.png|miniatur|300px|right|Nach Änderung der Reihenfolge]]
===== Reihenfolge von Filtern =====

Insbesondere bei Abwesenheitsmeldungen ist die Reihenfolge der Filter wichtig. Im Beispiel links wird der Filter "osm" erst nach der Abwesenheitsmeldung angewandt, Mails, die durch diesen Filter nicht schon wegsortiert wurden, erhalten also eine Abwesenheitsmeldung. Wenn dies unerwünscht ist, muß der Filter '''vor''' den Filter der Abwesenheitsmeldung verschoben werden (über die Pfeile rechts neben des Filterliste).

 
In (u.a.) folgenden Fällen werden '''Abwesenheitsmeldungen vom System nicht verschickt''':
* Die Absenderadresse deutet auf eine Mailingliste hin, z.B. beginnt mit: ''mailer-daemon'', ''listserv'', ''majordomo'', ''owner-'' oder enthält ''-request''
* Es existiert ein Header "Precedence" der ''junk'', ''bulk'' oder ''list'' enthält.
* Der Empfänger der Nachricht steht nicht in ''To'' oder ''Cc''.
* Sender und Empfänger haben dieselbe Email-Adresse.

[[Bild:Sieve-08-kopiesenden.png|miniatur|600px|right|TEXT]]

==== Kopie an anderen Empfänger versenden. ====

Eine erhaltene Email soll an eine andere Email-Adresse (in Kopie) weitergeleitet werden, z.B. von der Privatadresse an die Geschäftsadresse.

* '''Filterregel''': In diesem Beispiel soll der lokale Teil der Absender-Adresse verglichen werden. "Absender" wählen, dann "weitere Optionen" '''(1)''' und unter ''Operatoren'' ''User-Teil gleich''. '''(2)''' Im Beispiel wurde der User-Teil mit ''susanne.musterfrau'' '''(3)''' angegeben. Zur Email-Adresse ''susanne.musterfrau@example.de'' wird ein Match gefunden für ''sara-susanne.musterfrau@example.org'' hingegen nicht, weil der lokale Teil der Email-Adresse nicht übereinstimmt.
* '''Filteraktionen''': "Sende eine Kopie an" wählen '''(4)''' und eine Ziel-Adresse angeben.

 

[[Bild:Sieve-09-filter-abschalten-a.png|miniatur|400px|left|Filter abschalten]]
[[Bild:Sieve-09-filter-abschalten-b.png|miniatur|300px|right|Filterübersicht im inaktivem Filter]]
==== Filter deaktivieren/aktivieren ====

Soll ein Filter temporär deaktivitert werden, kann in der Filterbearbeitung '''Filterregel abschalten''' angeklickt werden. In der Filterübersicht ist der Filter dann als ''"(abgeschaltet)"'' markiert.

 
[[Bild:Sieve-10-nach-anwendung-filter.png|miniatur|600px|right|Nach dem Filtern]]
==== Nach dem Filtern ====

Die im obigen Beispiel gezeigte Inbox mit über 200 Emails sieht nach Anwendung der Filter wie im nebenstehenden Bild aus.

* Im Posteingang '''(1)''' ist nur noch eine private Email vorhanden
* Die Emails and die Mailinglisten wurden in die jeweiligen Ordner '''(2)''' einsortiert.

=== Technisches ===

==== Speicherort ====

Roundcube speichert die erstellten Regeln unter
<syntaxhighlight lang=shell>
~/Maildir/sieve/roundcube.sieve
</syntaxhighlight>

und verlinkt diese Filterdatei automatisch für die Benutzung mit dovecot:
<syntaxhighlight lang=shell>
xyz00@h01:~$ ls -al
drwxr-xr-x 5 xyz00-max xyz00 4096 Nov 16 07:28 .
drwxr-xr-x 28 xyz00-max xyz00 4096 Oct 22 23:06 ..
lrwxrwxrwx 1 xyz00-max xyz00 29 Nov 16 07:28 .dovecot.sieve -> Maildir/sieve/roundcube.sieve
</syntaxhighlight>
Wurden von anderen Programmen -- oder manuell -- andere Filtersets angelegt, werden diese vom Plugin deaktiviert. Die ursprüngliche Filterdatei bleibt erhalten, aber obiger Symlink verweist dann auf die Roundcube-Filter.

==== Manuelles Editieren ====

Vom manuellen Bearbeiten der Filterdatei <tt>roundcube.sieve</tt> wird abgeraten, da bei erneutem Einlesen durch das Roundcube-Plugin diese Regeln mit großer Wahrscheinlichkeit wieder automatisch umgeschrieben werden.

Für komplexeres Filtern kann eine komplett manuelle Datei angelegt werden und entsprechend verlinkt werden. Siehe auch den Artikel zu [[Managesieve]].

==== Links ====

Einige Sieve-relevante Links, sind im entsprechenden [https://wiki.hostsharing.net/index.php?title=Managesieve#Links Managesieve Wiki-Artikel] angegeben:
----
[[Kategorie:HSDoku]]
[[Kategorie:E-Mail]]
[[Kategorie:Glossar]]

Roundcube - Filter

2026-09-03T12:17:01Z

Tim00: /* Reihenfolge von Filtern */

== Roundcube - Filter ==

Das Webmailprogramm [[Roundcube]] erlaubt Emails automatisch zu Filtern. Dieser Artikel beschreibt, wie mit der Erweiterung sieverules solche Filter definiert werden können.

=== Allgemeines zum Filtern ===

Über das Mailzustellungsprogramm Deliver ist es mit der Erweiterung [[Managesieve]] möglich Emails beim Eintreffen in der Mailbox zu Filtern. Die Filterung findet hierbei bereits auf dem Server statt, so daß der User nicht mit seinem Mailprogramm oder Webmailer eingeloggt sein muß.

Hierbei ist es möglich u.a. folgende Aktionen durchzuführen

* Mails in einen bestimmten Ordner abzuspeichern
* Mails an einen anderen Empfänger weiterzuleiten
* eine Abwesenheitsmeldung zu verschicken
* den Empfang einer Email abzulehnen
* eine Mail zu löschen

Die Ausführung dieser Filteraktionen kann gesteuert werden z.B. basierend auf

* dem Absender der eintreffenden Email
* des Titels oder Teilen hiervon
* dem Vorhandensein oder Nichtvorhandensein bestimmter Wörter im Text der Nachricht
* die Auswertung von zusätzlichen Mail-Headern.

[[Bild:Sieve-01-einstellungen.png|miniatur|250px|right|Einstellungen]]
Detaillierte Informationen können z.B. der [http://de.wikipedia.org/wiki/Sieve Wikipedia] oder unter [http://www.sieve.info sieve.info] entnommen werden. Im Hostsharing-Wiki unter [[Managesieve]] sind ebenfalls weitere Grundlageninformationen zu finden.

=== Einrichtung ===

Hinweis: Wenn der Nutzer schon eine .forward mit z.b. procmail nutzt muss wie unter
[https://wiki.hostsharing.net/index.php?title=Managesieve#Zusammenarbeit_mit_Procmail Zusammenarbeit_mit_Procmail]
beschrieben ist beachtet werden.

Filter können unter <tt>Einstellungen</tt> eingerichtet und verändert werden. Hierzu im Menu Einstellungen den Reiter ganz rechts <tt>Filter</tt> auswählen.

 
[[Bild:Sieve-02-mailuebersicht.png|center|none|frame|Ungefilterter Posteingang]]
Für die folgenden Beispiele wird davon ausgegangen, daß der Nutzer in seinem Posteingang ohne Filter die Situation, wie im Bild oben angezeigt vorfindet: Viele Emails aus (drei) Mailinglisten und eine private Email. Alle Mails sind in einem Ordner und erschweren das Finden der ggf. wichtigen privaten Email.

[[Bild:Sieve-03-neuer-filter.png|miniatur|250px|right|Neuen Filter anlegen]]
Zunächst soll ein neuer Filter angelegt werden, der die Emails der Mailingliste <tt>otrs-de</tt> [http://doc.otrs.org/2.2/de/html/additional-resources-mailinglists.html] in einen eigenen Ordner verschiebt.

Hierzu unter der (leeren) Filterliste auf das <tt>+</tt> zum Anlegen eines Neuen Filters klicken.
 
[[Bild:Sieve-04-OTRS-filter.png|miniatur|600px|right|Anlegen eines Filters für eine Mailingliste]]
Im neu geöffneten Formular kann der neue Filter definiert werden.

* '''Filternamen''' vergeben: zum Beispiel OTRS für die entsprechende Maillingliste (oder zur besseren späteren Erinnerung: "Mailingliste otrs-de"). OTRS
* '''Filterregel''': Hier wird definiert unter welchen Bedingungen der Filter angewandt werden soll. Drei Optionen stehen zur Auswahl
** Irgendeine Bedingung muß erfüllt sein (ODER)
** Alle Bedingungen müssen erfüllt sein (UND) Auswählen
** Die Bedingung ist für alle Emails gültig (keine Bedingung notwendig)
* Die Definition der Filterregel beinhaltet das Auswahl eines Teils der Nachricht (z.B. Absender, Datum, Betreff, Text) und einem Wert, mit dem verglichen werden soll. In unserem Beispiel: BETREFF enthält <nowiki>[otrs-de]</nowiki>
* '''Filteraktion''': Die Aktion, die ausgeführt werden soll. Verschiebe Nachricht nach OTRS 
Bei Aktionen, die Nachrichten in andere Ordner verschieben oder kopieren werden die möglichen Ordner die zum Zeitpunkt der Filteranlage existieren in einem Drop-Down-Menu angezeigt.
* '''Speichern'''

[[Bild:Sieve-05-hostsharing-filter.png|miniatur|600px|right|Filter für Mailingliste über Mail-Header und Ausnahme]]
=== Weitere Beispiele ===

==== Maillinglisten Filter ====

Im Beispiel rechts werden wieder die Emails einer Mailinglliste gefiltert. Hier handelt es sich um die <tt>Technik</tt>-Liste von Hostsharing.

Der Filter erhält folgende Kriterien:
* '''Filterregel''': Der Filter wird '''nicht''' angewandt, wenn der Text der Nachricht das Wort "Festplattencrash" enthält, der Empfänger, solche Emails also in seinem Posteingang behalten möchte. Darüber hinaus wird die Mailingliste identifiziert über den Mail-Header <tt>List-Id</tt>. Solche zusätzlichen Mail-Header können über die Auswahl "Anderer Header" ausgewählt werden. Beide Bedingungen müssen erfüllt sein (UND), also "trifft alle folgenden Regeln" auswählen.
* '''Filteraktion''': Wie im ersten Beispiele wieder das Verschieben in einen Ordner, hier <tt>hostsharing</tt>.

 
[[Bild:Sieve-06-abwesenheitsmeldung-filter.png|miniatur|600px|right|Abwesenheitsmeldung]]
==== Abwesenheitsmeldung ====

Nutzer möchten oft bei längerer Abwesenheit dem Absender einer Email mitteilen, daß sie die empfangene Email z.B. wegen Urlaubs nicht lesen können. Hierzu kann eine Abwesenheitsmeldung definiert werden, die automatisch eine Antwort-Email generiert mit einem vordefinierten Text.

Im Beispiel sollen die Absender "peter.lustig" und "Wickie" keine Abwesenheitsmeldung erhalten, sowie bei Emails, die das Wort "Werbung" im Betreff enthalten auch keine Abwesenheitsmeldung verschickt werden.
* "Absender enthält nicht 'peter.lustig'" - Ein Vergleich mit der Email-''Adresse'' wird durchgeführt. Peter <peter.lustig@example.org> - Hier ist peter.lustig in der Adresse enthalten Peter.Lustig <peter@example.org> - Hier ist peter.lustig ''nicht'' in der ''Adresse'' enthalten.
* "Anderer Header "From" enthält nicht 'Wickie'" - Ein Vergleich mit der ''kompletten Absender-Angabe'' wird durchgeführt ''Susanne <wickie@example.org>'' aber auch ''Wickie <susanne@example.org>'' werden gefunden
* "Betreff enthält nicht 'Werbung' - Das Wort Werbung darf nicht im Betreff enthalten sein.

In den '''Filteraktionen''' wird die Aktion "Abwesenheitsmeldung" ausgewählt.
* '''Absender''': Hat man mehrere Identitäten in Webmail angelegt, kann man hier aussuchen unter welchem Absender die Abwesenheitsmeldung geschickt werden soll.
* '''Alias''': Die Vacation-Extension schickt Abwesenheitsmeldungen '''nur''' wenn die Mail an eine dem System für ''diesen'' Account bekannte Email-Adresse geschickt wurde. Im konkreten Fall bei der Erstellung über Roundcube müssen also für jede Email-Adresse Identitäten angelegt werden, also z.B. sowohl max.mustermann@example.org und maexchen@example.org. Diese müssen dann auch unter "Alias" explizit ausgewählt werden. Werden Emails an den Account mit einer anderen Empfänger-Adresse geschickt, erhalten diese '''keine''' Abwesenheitsmeldung. siehe auch [http://tools.ietf.org/html/rfc5230#section-4.5 RFC5230] Abschnitt 4.5
* '''Zeitraum''': Sagt aus, nach wieviel Tagen ein Absender eine erneute Abwesenheitsmeldung erhält. Im Beispiel also z.B. nur einmal alle 3 Tage. Wenn der Absender dazwischen neue Emails versendet, erhält er keine neue Abwesenheitsmeldung. Nach 3 Tagen wird bei erneuten Emails wieder eine Abwesenheitsmeldung verschickt. Hierz speichert sich <tt>deliver</tt> eine Liste der Empfänger.
* '''Betreff''': Der Betreff der Abwesenheitsmeldung, z.B. "Abwesenheit - Urlaub"; der originale Betreff der Email kann zur Identifizierung angehängt werden. Wird also automatisch auf eine Mail "Geburtstagseinladung" geantwortet, wäre der Betreff der Abwesenheitsmeldung "Abwesenheit - Urlaub Geburtstagseinladung".
* '''Nachricht''': Der eigentliche Text der Abwesenheitsmeldung, z.B. Dauer der Abwesenheitsmeldung, Vertretungsregelung, Erreichbarkeit.

[[Bild:Sieve-07-reihenfolge-a.png|miniatur|300px|left|Reihenfolge Filter ändern über Pfeile]]
[[Bild:Sieve-07-reihenfolge-b.png|miniatur|300px|right|Nach Änderung der Reihenfolge]]
==== Reihenfolge von Filtern ====

Insbesondere bei Abwesenheitsmeldungen ist die Reihenfolge der Filter wichtig. Im Beispiel links wird der Filter "osm" erst nach der Abwesenheitsmeldung angewandt, Mails, die durch diesen Filter nicht schon wegsortiert wurden, erhalten also eine Abwesenheitsmeldung. Wenn dies unerwünscht ist, muß der Filter '''vor''' den Filter der Abwesenheitsmeldung verschoben werden (über die Pfeile rechts neben des Filterliste).

 
In (u.a.) folgenden Fällen werden '''Abwesenheitsmeldungen vom System nicht verschickt''':
* Die Absenderadresse deutet auf eine Mailingliste hin, z.B. beginnt mit: ''mailer-daemon'', ''listserv'', ''majordomo'', ''owner-'' oder enthält ''-request''
* Es existiert ein Header "Precedence" der ''junk'', ''bulk'' oder ''list'' enthält.
* Der Empfänger der Nachricht steht nicht in ''To'' oder ''Cc''.
* Sender und Empfänger haben dieselbe Email-Adresse.

[[Bild:Sieve-08-kopiesenden.png|miniatur|600px|right|TEXT]]

==== Kopie an anderen Empfänger versenden. ====

Eine erhaltene Email soll an eine andere Email-Adresse (in Kopie) weitergeleitet werden, z.B. von der Privatadresse an die Geschäftsadresse.

* '''Filterregel''': In diesem Beispiel soll der lokale Teil der Absender-Adresse verglichen werden. "Absender" wählen, dann "weitere Optionen" '''(1)''' und unter ''Operatoren'' ''User-Teil gleich''. '''(2)''' Im Beispiel wurde der User-Teil mit ''susanne.musterfrau'' '''(3)''' angegeben. Zur Email-Adresse ''susanne.musterfrau@example.de'' wird ein Match gefunden für ''sara-susanne.musterfrau@example.org'' hingegen nicht, weil der lokale Teil der Email-Adresse nicht übereinstimmt.
* '''Filteraktionen''': "Sende eine Kopie an" wählen '''(4)''' und eine Ziel-Adresse angeben.

 

[[Bild:Sieve-09-filter-abschalten-a.png|miniatur|400px|left|Filter abschalten]]
[[Bild:Sieve-09-filter-abschalten-b.png|miniatur|300px|right|Filterübersicht im inaktivem Filter]]
==== Filter deaktivieren/aktivieren ====

Soll ein Filter temporär deaktivitert werden, kann in der Filterbearbeitung '''Filterregel abschalten''' angeklickt werden. In der Filterübersicht ist der Filter dann als ''"(abgeschaltet)"'' markiert.

 
[[Bild:Sieve-10-nach-anwendung-filter.png|miniatur|600px|right|Nach dem Filtern]]
==== Nach dem Filtern ====

Die im obigen Beispiel gezeigte Inbox mit über 200 Emails sieht nach Anwendung der Filter wie im nebenstehenden Bild aus.

* Im Posteingang '''(1)''' ist nur noch eine private Email vorhanden
* Die Emails and die Mailinglisten wurden in die jeweiligen Ordner '''(2)''' einsortiert.

=== Technisches ===

==== Speicherort ====

Roundcube speichert die erstellten Regeln unter
<syntaxhighlight lang=shell>
~/Maildir/sieve/roundcube.sieve
</syntaxhighlight>

und verlinkt diese Filterdatei automatisch für die Benutzung mit dovecot:
<syntaxhighlight lang=shell>
xyz00@h01:~$ ls -al
drwxr-xr-x 5 xyz00-max xyz00 4096 Nov 16 07:28 .
drwxr-xr-x 28 xyz00-max xyz00 4096 Oct 22 23:06 ..
lrwxrwxrwx 1 xyz00-max xyz00 29 Nov 16 07:28 .dovecot.sieve -> Maildir/sieve/roundcube.sieve
</syntaxhighlight>
Wurden von anderen Programmen -- oder manuell -- andere Filtersets angelegt, werden diese vom Plugin deaktiviert. Die ursprüngliche Filterdatei bleibt erhalten, aber obiger Symlink verweist dann auf die Roundcube-Filter.

==== Manuelles Editieren ====

Vom manuellen Bearbeiten der Filterdatei <tt>roundcube.sieve</tt> wird abgeraten, da bei erneutem Einlesen durch das Roundcube-Plugin diese Regeln mit großer Wahrscheinlichkeit wieder automatisch umgeschrieben werden.

Für komplexeres Filtern kann eine komplett manuelle Datei angelegt werden und entsprechend verlinkt werden. Siehe auch den Artikel zu [[Managesieve]].

==== Links ====

Einige Sieve-relevante Links, sind im entsprechenden [https://wiki.hostsharing.net/index.php?title=Managesieve#Links Managesieve Wiki-Artikel] angegeben:
----
[[Kategorie:HSDoku]]
[[Kategorie:E-Mail]]
[[Kategorie:Glossar]]

Login mit SSH

2026-09-02T09:02:56Z

Tim00: /* Login ohne Passwort */

{{Baustelle}}

Um sich einloggen zu können, brauchst Du natürlich die Daten, die Dir von Hostsharing in einer Mail nach der Anmeldung zugeschickt wurden:

Hostname: '''xyz00.hostsharing.net''' (wenn eine eigene Domain konnektiert ist auch <eigene-domain>.<tld>)

Username: '''xyz00'''

Passwort: '''(wie in der automatischen Mail mitgeteilt)'''

Bei xyz00 handelt es sich um den Account des Paket-Admins. Initial ist für jedes neue Paket nur ein Admin-Account eingerichtet, dessen Benutzername die Form '''xyz00''' besitzt.

Da dieser Account sehr viel Macht über das Paket hat, darf er nur über sichere Protokolle wie SSH benutzt werden. Unsichere Protokolle wie direktes FTP dürfen nicht verwendet werden, da diese die Passwörter im Klartext übertragen. Jeder Administrator auf der Übertragungsstrecke könnte mitlesen.

Gleich vorab: Seine Website kann man später freilich über einen separaten Account per ftps, sftp, scp (und zur Not auch ftp) hochladen, doch dazu später mehr.

Linux Systeme haben meist ssh, scp und sftp Clients vorinstalliert. Eine Freie Software zum sicheren Dateitransfer für Windows ist z.B. [http://winscp.net WinSCP] und ein Shell Zugang mit [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY].

Nach der ggf. nötigen Installation eines ssh Clients, die hier nicht beschrieben werden, da sie nicht Hostsharing-spezifisch ist, kann der erste Login erfolgen.

== Login ==

Mit OpenSSH ist der Aufruf auf der Kommandozeile z.B. folgender:

ssh xyz00@xyz00.hostsharing.net

Nach Aufbau der Verbindung wird dann das [[Passwort]] erfragt.
Danach erscheint in etwa folgende Bildschirmausgabe:

<syntaxhighlight lang="bash">
Last login: Fri Apr 19 06:43:45 2002 from p5081f0c7.dip.t-dialin.net on pts/7

Linux hopi 2.4.17 #2 SMP Thu Jan 17 14:35:38 CET 2002 i686 unknown

+----------------------------------------------------------------+
| hopi.hostsharing.net |
| Bei Fragen oder Problemen bitte E-Mail an: |
| support@hostsharing.net (öffentliche Mailingliste) |
+----------------------------------------------------------------+

Last login: Fri Apr 19 09:36:34 2002 from 62.156.160.59

xyz0@hopi:~$ █
</syntaxhighlight>

Es macht durchaus Sinn, die ganz oben genannte "Last Login" Zeile zu prüfen, ob man dies auch selbst war (Uhrzeit und Provider), unten die "Last Login" Zeile gibt genau genommen das aktuelle Login aus, weil der Programmteil nach dem eigentlichen Login ausgeführt wird.

Als nächstes ändern wir gleich unser [[Passwort]], da dieses schließlich unverschlüsselt per E-Mail versendet wurde. Dies geschieht unter UNIX mit dem Kommando passwd

== Passwort ändern ==

Eine Änderung des Passwortes geht dem Befehl passwd:

<syntaxhighlight lang="bash">
xyz00@hopi:~$ passwd

Changing password for xyz00

(current) UNIX password: ALTESPASSWORT

Enter new UNIX password: NEUESPASSWORT

Retype new UNIX password: NEUESPASSWORT

passwd: password updated successfully

xyz00@hopi:~$ █

</syntaxhighlight>

Die Platzhalter '''NEUESPASSWORT''' und '''ALTESPASSWORT''' müssen dabei selbstverständlich gegen die entsprechenden [[Passworte]] ausgetauscht werden. Dabei sollte jedes Passwort mindestens 6 Zeichen lang sein, besser 8 Zeichen, und aus Buchstaben, Ziffern und ggf. Sonderzeichen bestehen. Allerdings sollte auf Umlaute verzichtet werden, da diese je nach verwendetem Zugangsweg nicht verwendet werden könnten.

Ggf. kommt es zu Fehlermeldungen, z.B. wenn das neue [[Passwort]] zu simpel ist, oder bei der Wiederholung nicht identisch mit dem ersten Passwort ist. In dem Fall, den Vorgang einfach wiederholen. Solange das neue Passwort nicht erfolgreich übernommen wurde, bleibt das alte gültig.

Es gibt User, denen der Paket-Admin nur das Recht eingeräumt hat, das eigene Passwort zu ändern, indem er ihnen die "Shell" /usr/bin/passwd zugewiesen hat. Diese User können durch einen Shell-Login nur ihr Passwort ändern, da das Programm passwd an Stelle einer Shell gestartet wird. Sie werden nach dem Einloggen automatisch auf diesen Dialog geführt.Mehr dazu unter [[User#Rechte]].

==Sitzung beenden==

Um die Sitzung zu beenden, sich also auszuloggen, gibt man exit ein. Das sieht dann so aus:

<syntaxhighlight lang="bash">
xyz00@hopi:~$ exit
logout
Connection to xyz00.hostsharing.net closed.
</syntaxhighlight>
== Login mit Passwort ==
Um logins durch automatisierte Versuche zu erschweren sind auf den shared hosts Mechanismen in Betrieb, die ein Login mit Passwort erschweren, zum Beispiel durch ein Timeout, dass die Eingabe eines Passworts, wenn sie zu lange dauert, nicht funktioniert.
<syntaxhighlight lang="bash">
(xyz00@xyz00.hostsharing.net) Password:
Connection closed by 2a01:37:1000::53df:4f85:0 port 22
</syntaxhighlight>
Man muss also das Passwort in der Zwischenablage haben, dann den Loginbefehl geben und dann sofort das Passwort eingeben. Das ist in vielerlei hinsicht unsicher, da die Zwischenablage evtl gespeichert wird. (ein passwort Manager wie keepassXC löscht die eigenen Abgelegten Werte per Default nach einigen Sekunden), diese Methode, weil es wirklich schnell gehen muss (wenige Sekunden zur Passworteingabe) kann auch zu anderen Fehler führen die dass Passwort offenlegen, z.B. weil es versehentlich in der Hektik in ein falsches Fenster gepostet wird.

Eine andere Alternative ist sshpass:

<syntaxhighlight lang="bash">
sshpass -p your_password ssh xyz00@xyz00.hostsharing.net
</syntaxhighlight>

Es spricht vieles dafür, den Zugang über SSH mit einem Schlüsselpaar zu konfigurieren.

== Login mit SSH Key ==

Es besteht die Möglichkeit, einen public SSH Key in den Benutzer hochzuladen. Dann kann die Anmeldung über den privaten Key erfolgen. Siehe auch zur Erstellung des Key Paares: [https://www.heise.de/tipps-tricks/SSH-Key-erstellen-so-geht-s-4400280.html]

Der public SSH Key muss dann hier gespeichert werden:

<syntaxhighlight lang="bash">
mkdir -p ~/.ssh
nano .ssh/authorized_keys
# hier den public Key einfügen, und speichern
chmod 600 .ssh/authorized_keys
</syntaxhighlight>

Manchmal schlägt bei Power-Usern die Anmeldung fehl, wenn zu viele SSH Keys zur Verfügung stehen, und die alle durchprobiert werden. Dann kommt nach einer gewissen Anzahl die Fehlermeldung: zu viele Anmeldungsversuche.

Die Lösung: beim SSH Aufruf muss der richtige private Key referenziert werden, und die anderen Keys ignoriert werden:

<syntaxhighlight lang="bash">
ssh -p 22 -i /root/.ssh/id_ed25519 -o IdentitiesOnly=yes xyz00@xyz00.hostsharing.net
</syntaxhighlight>

== Zusätzliche Möglichkeiten ==

=== Bestimmte Shell Kommandos automatisch ausführen ===

Lege in dem Verzeichnis, in dem Du direkt nach dem Login landest, mit dem Editor Deiner Wahl die Datei .bash_profile mit folgendem Inhalt an:
<syntaxhighlight lang="bash" line>
# Get the aliases and functions
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi
# User specific environment and startup programs
PATH=$PATH:$HOME/bin
BASH_ENV=$HOME/.bashrc
</syntaxhighlight>

Und nun kannst du in der Datei .bashrc shell Kommandos eingeben. z.B.: quota -g

=== Editor in der Shell einstellen ===

1. manuell Einloggen und:
<syntaxhighlight lang="ini">
VISUAL=nano
export VISUAL
EDITOR=nano
export EDITOR
</syntaxhighlight>

2. in der bash geht es auch kürzer:
<syntaxhighlight lang="bash">
export EDITOR=nano
export VISUAL=nano
</syntaxhighlight>

3. automatisch bei jedem Login
Mit obigen Kommandos in der ~/.bash_profile-Datei.

=== Als Paketadmin in einen Unterbenutzer wechseln ===

Wenn du als Paketadmin xyz00 per SSH angemeldet bist, kannst du ohne Passwort in den Unterbenutzer xyz00-webseite wechseln:

<syntaxhighlight lang="bash">
sudo -iu xyz00-webseite
</syntaxhighlight>

Bei Unix-Benutzern, die z.B. nur für Postfächer genutzt werden, ist als Shell nur passwd eingerichtet. Daher musst du bei sudo die gewünsche Shell angeben:

<syntaxhighlight lang="bash">
sudo -u xyz00-mail_klaus -s bash
</syntaxhighlight>

==Weiterführende Links==

[[HS-Server:SSH-Hostkeys]]

----
[[Kategorie:HSDoku]]
[[Kategorie:Einstieg bei Hostsharing]]
[[Kategorie:Glossar]]

WKD einrichten

2026-09-02T06:54:11Z

Tim00: /* Links */

== Einleitung ==
Ein Web Key Verzeichnis (Web Key Directory, WKD) ermöglicht es auf eine einfache Weise, den aktuell gültigen öffentlichen Schlüssel (Public Key) für eine bestimmte E-Mail Adresse über HTTPS bereitzustellen und abzurufen.

Es gibt die Möglichkeit, das WKD im Advanced- oder Direct-Methode einzurichten. Im Direct-Mode wird der Pfad .well-known direkt auf der Domain erwartet, im Advanced-Mode wird mit einer Subdomain openpgpkey gearbeitet. Da die Trennung von der Hauptanwendung der Domain im Advanced-Mode einfacher ist, und weil die Clients auch erst über den Advanced-Mode versuchen, die Schlüssel herunterzuladen, beschränken wir uns in dieser Anleitung auf den Advanced Mode.

== Voraussetzungen ==

Es wird vorausgesetzt, dass bereits ein Schlüsselpaar (private/public) erzeugt wurde (z.B. mit <code>gpg --full-generate-key</code>, oder mit Thunderbird, siehe unten in den Links).

Es muss eine Domain openpgpkey.<MeineDomain>.de im HSAdmin angelegt werden.

Der öffentliche Schlüssel muss in einer Textdatei im Domainbenutzer gespeichert sein. Diese Datei wird als Parameter für das Skript angeben.

== Skript zur Einrichtung ==

Dieses Skript <code>update_pgp_wkd.sh</code> (Link zum Gist siehe unten) erledigt alles, was man braucht:

<syntaxhighlight lang=shell line>
#!/bin/bash

if [ -z $1 ]
then
echo "Bitte den Pfad für die Datei mit dem öffentlichen Key mitgeben: z.B. $0 ~/public.txt"
exit
fi
publickeyfile=$(realpath $1)

if [ ! -f $publickeyfile ]
then
echo "Kann den öffentlichen Schlüssel nicht finden: $publickeyfile"
exit
fi

DOMAIN=$(find ~/doms/openpgpkey.*/htdocs-ssl | head -n 1 | awk -F/ '{ print $8 }' | sed -e 's/openpgpkey.//g')

if [ -z $DOMAIN ]
then
echo "Zuerst muss die subdomain openpgpkey.$DOMAIN im HSAdmin eingerichtet werden!"
exit
fi

cd ~/doms/openpgpkey.$DOMAIN
cat > .htaccess <<FINISH
ForceType application/octet-stream;
<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin "*"
</IfModule>
FINISH
cd ~/doms/openpgpkey.$DOMAIN/htdocs-ssl/
rm -f .htaccess
mkdir -p .well-known/openpgpkey
cd .well-known
gpg --import < $publickeyfile
gpg --list-options show-only-fpr-mbox -k "@$DOMAIN" | /usr/lib/gnupg/gpg-wks-client --install-key
touch openpgpkey/$DOMAIN/policy
chmod a+x openpgpkey/$DOMAIN/
chmod a+x openpgpkey/$DOMAIN/hu/
touch openpgpkey/$DOMAIN/hu/index.html
</syntaxhighlight>

== Einrichtung bei Hostsharing ==

Man ruft das Skript mit dem Pfad zur Datei mit dem öffentlichen Schlüssel als Parameter auf. Es wird die erste Domain gesucht, die mit "openpgpkey." beginnt.

<syntaxhighlight lang=shell>
./update_pgp_wkd.sh ~/public.txt
</syntaxhighlight>

Anschließend kann man das Ergebnis mit dem Dienst auf metacode.biz testen, siehe Link unten.

== Links ==
* [https://wiki.gnupg.org/WKD Offizielle Webseite]
* [https://wiki.gnupg.org/WKDHosting Offizielle Anleitung]
* [https://www.kuketz-blog.de/gnupg-web-key-directory-wkd-einrichten/ Kuketz Blog: GnuPG: Web Key Directory (WKD) einrichten]
* [https://www.heise.de/tipps-tricks/Thunderbird-PGP-Verschluesselung-fuer-E-Mails-einrichten-4561551.html Thunderbird: PGP-Verschlüsselung für E-Mails einrichten]
* [https://gist.github.com/tpokorra/84aef5f97981535b871fe9e4719e940d Gist: update_pgp_wkd.sh]
* Testen der eigenen Einrichtung: https://wkd.dp42.dev/ oder https://www.webkeydirectory.com/

----

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]

Wordpress

2026-08-30T20:58:34Z

Tim00: /* Umgang mit einem gehackten Wordpress */

= Wordpress in 5 Minuten =

Installiert wird Wordpress hier unter der Domain https://blog.example.org.

== Vorbereitungen ==

In ''hsadmin'', zum Beispiel mit ''hsscript'':

''hsadmin''-Shell starten mit:
<syntaxhighlight lang=shell>
hsscript -u xyz00 -i
Password: ********
</syntaxhighlight>
Dann nacheinander anlegen:

* Linux User als Domain-Administrator
* Subdomain ''blog.example.org''
* MySQL-User
* MySQL Datenbank
<syntaxhighlight lang=shell>
xyz00@hsadmin> user.add({set:{name:'xyz00-blog',password:'geheim',shell:'/bin/bash',comment:'Wordpress Blog'}})
xyz00@hsadmin> domain.add({set:{name:'blog.example.org',user:'xyz00-blog'}})
xyz00@hsadmin> mysqluser.add({set:{name:'xyz00_wpuser',password:'geheim'}})
xyz00@hsadmin> mysqldb.add({set:{name:'xyz00_wpdb',owner:'xyz00_wpuser'}})
</syntaxhighlight>
== Wordpress installieren ==

Anmelden als Linux-User ''xyz00-blog'':

ssh -l xyz00-blog xyz00.hostsharing.net

''htdocs-ssl'' Verzeichnis vorbereiten

<syntaxhighlight lang=shell>
cd doms/blog.example.org
rm -rf subs/www subs-ssl/www
cd htdocs-ssl
rm .htaccess
</syntaxhighlight>

Wordpress downloaden & entpacken z.b. im htdocs-ssl Verzeichnis

<syntaxhighlight lang=shell>
wget -O - https://wordpress.org/latest.tar.gz |tar -xz --strip 1
</syntaxhighlight>

== Wordpress konfigurieren ==

Im Browser auf die Seite
http://blog.example.org gehen und den Anweisungen folgen.

= Verschiedene Hinweise und Anleitungen =
== wp-cli installieren ==

wp-cli ist das Kommandozeilen-Werkzeug für WordPress: https://wp-cli.org/de/

Es kann so installiert werden:

<syntaxhighlight lang=shell>
mkdir ~/bin
cd ~/bin
wget https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod a+x wp-cli.phar
</syntaxhighlight>

== Uraltes Wordpress aktualisieren ==

Manche Wordpress Installationen sind so alt, dass wp-login nicht mehr funktioniert.

Mit wp-cli kann Wordpress auf die aktuelle Version aktualisiert werden:

<syntaxhighlight lang=shell>
cd ~/wordpress # oder ~/doms/meinedomain.de/subs-ssl/www/ oder wo sonst Wordpress installiert ist
~/bin/wp-cli.phar core update
</syntaxhighlight>

Falls nur eine Minor Version installiert werden soll:

<syntaxhighlight lang=shell>
cd ~/wordpress
~/bin/wp-cli.phar core update --minor
</syntaxhighlight>

Update der Plugins und Themes:

<syntaxhighlight lang=shell>
cd ~/wordpress
~/bin/wp-cli.phar plugin update --all
~/bin/wp-cli.phar theme update --all
</syntaxhighlight>

== Umgang mit einem gehackten Wordpress ==

Falls die Wordpress Instanz gehackt wurde, gibt es 2 Möglichkeiten:

* Es kann die Webseite inkl. Dateien und Datenbank auf den Stand aus dem Backup vor dem Angriff zurückgesetzt werden, und muss dann umgehend aktualisiert werden. Bei diesem Vorgehen gehen die seitdem erfassten Beiträge verloren. Leider liegt der Zeitpunkt des Angriffs manchmal schon länger zurück.
* Ansonsten müssen die veränderten Dateien identifiziert und gelöscht werden.

Das Identifizieren der veränderten Dateien kann mit folgenden Mitteln geschehen:

<syntaxhighlight lang=shell>
cd ~/wordpress
~/bin/wp-cli.phar core verify-checksums --include-root --exclude=liesmich.html,readme.html
~/bin/wp-cli.phar plugin --skip-themes --skip-plugins verify-checksums --all
</syntaxhighlight>

in der wp-config.php sollte keine verdächtige Datei eingebunden werden:

<syntaxhighlight lang=shell>
grep include wp-config.php
</syntaxhighlight>

Zuletzt geänderte Dateien finden, im Beispiel der letzten 3 Tage:

<syntaxhighlight lang=shell>
find -ctime -3
</syntaxhighlight>

Zeige Dateien, die schreibgeschützt sind:
<syntaxhighlight lang=shell>
find . -type f ! -perm -u=w
</syntaxhighlight>

Lösche alle .htaccess Dateien mit einer speziellen md5sum:

<syntaxhighlight lang=shell>
md5sum=025ee8275afa054097fc53508448f76a
find . -type f -name ".htaccess" -exec sh -c 'for f; do md5sum "$f" | grep -q "$md5sum" && ls -la "$f"; done' _ {} +
</syntaxhighlight>

Prüfe auch die Dateien im doms Verzeichnis (dort sollten keine php Dateien liegen, z.B. accesson.php oder so):
<syntaxhighlight lang=shell>
find ~/doms
</syntaxhighlight>

Verdächtige Dateien im uploads und cache Verzeichnis finden:

<syntaxhighlight lang=shell>
find wp-content/uploads wp-content/cache -type f \
$ -name '*.php' -o -name '*.phtml' -o -name '*.phar' -o -name '*.ico' $ -ls
</syntaxhighlight>

Verdächtige Dateien finden, die Schadcode speziell kodiert haben:

<syntaxhighlight lang=shell>
grep -rl "eval(base64_decode\|eval(gzinflate\|eval(str_rot13\|eval(htmlspecialchars_decode" . --include="*.php" 2>/dev/null
</syntaxhighlight>

Verdächtige Dateien finden, die versuchen, einen Benutzer mit administrator Rechten anzulegen:

<syntaxhighlight lang=shell>
grep -r '\\"administrator\\"' wp-content/languages/plugins/
</syntaxhighlight>

In der Datenbank sollten die Benutzer mit administrator Rechten kontrolliert werden:

<syntaxhighlight lang=sql>
SELECT m.meta_key, m.meta_value, u.id, u.user_login, u.user_email, u.display_name
FROM wp_usermeta AS m join wp_users AS u ON m.user_id = u.id
WHERE m.meta_key = 'wp_capabilities' AND meta_value LIKE '%administrator%';
</syntaxhighlight>

Die Passwörter der Administratoren müssen zurückgesetzt werden:

<syntaxhighlight lang=shell>
~/bin/wp-cli.phar user reset-password --show-password --skip-email meinadmin
~/bin/wp-cli.phar user reset-password irgendeinadmin
</syntaxhighlight>

Die Authentication Unique Keys and Salts in der wp-config.php sollten zurückgesetzt werden.

== Einen Admin Benutzer hinzufügen ==

Wenn du die Pflege einer WordPress Instanz übernehmen sollst, aber noch keinen Admin Benutzer hast:

<syntaxhighlight lang=shell>

~/bin/wp-cli.phar user create meinuser admin@example.org --role=administrator
</syntaxhighlight>

Entsprechend kann der Benutzer auch wieder gelöscht werden:

<syntaxhighlight lang=shell>
cd ~/wordpress
~/bin/wp-cli.phar user delete meinuser
</syntaxhighlight>

== Bestehendes Wordpress auf neue Domain umziehen ==
Meistens muss nichts weiter geändert werden als die Home und die SITE_URL Option.

Einfach zu ändern geht das indem man sich via phpmyadmin.hostsharing.net in den Datenbank User des Wordpress einloggt und sich die Tabelle wp_options ansieht. Dort müssen die Zeilen mit `siteurl` und `home` an die neuen URLs angepasst werden.

Alternativ kann man das auch über das wp-config.php machen. Meistens gibt es die beiden Einträge noch nicht, einfach an die passende Stelle für die Custom Config neu eintragen:

<syntaxhighlight lang=php>
define('WP_HOME','https://www.new-domain.de/');
define('WP_SITEURL','https://www.new-domain.de/');
</syntaxhighlight>

Generell lohnt es sich die wp_options Tabelle mal noch auf alte Domain Einträge zu untersuchen und ggf zu ersetzen.
Das geht z.B. so:

<syntaxhighlight lang=sql>
SELECT * FROM wp_options WHERE option_value LIKE "%https://old-domain.de%"
</syntaxhighlight>

== Bestehendes Wordpress auf neuen User / Server umziehen / Uploads auf Storage auslagern ==

Meistens muss dafür keine weitere Änderung vorgenommen werden. Manchmal haben vorherige Anbieter einen alternativen Upload Pfad gesetzt. Das zeigt sich dadurch das man angeblich keine Schreibberechtigungen hätte beim Hochladen von z.B. Bildern.

Eine Möglichkeit was dort kaputt sein könnte ist, das die Option `upload_path` noch auf einen alten Pfad vom alten Anbieter gesetzt wurde. Diese Option ist auch zu gebrauchen wenn der häufiger doch mal recht schnell wachsende Uploads Ordner auf den Storage und nicht auf die SSD ausgelagert werden soll.

In der wp_options DB-Tabelle muss entsprechend die Variable `upload_path` angepasst werden. z.B. für den User xyz00-wordpress zu /home/storage/xyz00/users/wordpress/uploads

Generell lohnt es sich die wp_options Tabelle noch mal auf den Alten Pfad zu untersuchen und ggf. anzupassen, das geht z.B. so:

<syntaxhighlight lang=sql>
SELECT * FROM wp_options WHERE option_value LIKE "%/old/path/%"
</syntaxhighlight>

== Objekt Cache einrichten ==

Falls bei dem Bericht über den Zustand der Webseite dieser Eintrag erscheint: "Du solltest einen persistenten Objekt-Cache verwenden", sollte [[Redis#Redis_installieren|Redis installiert]] werden. Es reicht, wenn Redis auf einem Unix-Socket läuft, es muss nicht auf einem Port laufen.

In der wp-config.php sollte dann (relativ weit oben) eingetragen werden:

<syntaxhighlight lang="php">
define('WP_REDIS_SCHEME', 'unix');
define('WP_REDIS_PATH', '/home/pacs/xyz00/users/service/redis/var/redis-server.sock');
define('WP_REDIS_PASSWORD', 'topsecret');
</syntaxhighlight>

Dann kann z.B. das Plugin "Redis Object Cache" von Till Küss installiert werden: https://de.wordpress.org/plugins/redis-cache/

Danach lässt sich der Object Cache unter "Einstellungen / Redis" aktivieren.

== Seiten Cache einrichten ==

Falls bei dem Bericht über den Zustand der Webseite dieser Eintrag erscheint: "Seiten-Cache wurde nicht erkannt, ...", kann das Plugin WP Super Cache von Automattic installiert werden: https://wordpress.org/plugins/wp-super-cache/

Der Cache muss dann in den Einstellungen des Plugins aktiviert werden.

= Links =

*[https://wordpress.org/ Offizielle Webseite von Wordpress]
*[https://wp-cli.org/de/ WP-CLI ist das Kommandozeilen-Werkzeug für WordPress]
*[https://github.com/tpokorra/Hostsharing-Ansible-Wordpress Ansible Playbook für Hostsharing]

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]
[[Kategorie:Software]]
[[Kategorie:Blog]]
[[Kategorie:CMS]]

Wordpress

2026-08-30T20:23:44Z

Tim00: /* Umgang mit einem gehackten Wordpress */

= Wordpress in 5 Minuten =

Installiert wird Wordpress hier unter der Domain https://blog.example.org.

== Vorbereitungen ==

In ''hsadmin'', zum Beispiel mit ''hsscript'':

''hsadmin''-Shell starten mit:
<syntaxhighlight lang=shell>
hsscript -u xyz00 -i
Password: ********
</syntaxhighlight>
Dann nacheinander anlegen:

* Linux User als Domain-Administrator
* Subdomain ''blog.example.org''
* MySQL-User
* MySQL Datenbank
<syntaxhighlight lang=shell>
xyz00@hsadmin> user.add({set:{name:'xyz00-blog',password:'geheim',shell:'/bin/bash',comment:'Wordpress Blog'}})
xyz00@hsadmin> domain.add({set:{name:'blog.example.org',user:'xyz00-blog'}})
xyz00@hsadmin> mysqluser.add({set:{name:'xyz00_wpuser',password:'geheim'}})
xyz00@hsadmin> mysqldb.add({set:{name:'xyz00_wpdb',owner:'xyz00_wpuser'}})
</syntaxhighlight>
== Wordpress installieren ==

Anmelden als Linux-User ''xyz00-blog'':

ssh -l xyz00-blog xyz00.hostsharing.net

''htdocs-ssl'' Verzeichnis vorbereiten

<syntaxhighlight lang=shell>
cd doms/blog.example.org
rm -rf subs/www subs-ssl/www
cd htdocs-ssl
rm .htaccess
</syntaxhighlight>

Wordpress downloaden & entpacken z.b. im htdocs-ssl Verzeichnis

<syntaxhighlight lang=shell>
wget -O - https://wordpress.org/latest.tar.gz |tar -xz --strip 1
</syntaxhighlight>

== Wordpress konfigurieren ==

Im Browser auf die Seite
http://blog.example.org gehen und den Anweisungen folgen.

= Verschiedene Hinweise und Anleitungen =
== wp-cli installieren ==

wp-cli ist das Kommandozeilen-Werkzeug für WordPress: https://wp-cli.org/de/

Es kann so installiert werden:

<syntaxhighlight lang=shell>
mkdir ~/bin
cd ~/bin
wget https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod a+x wp-cli.phar
</syntaxhighlight>

== Uraltes Wordpress aktualisieren ==

Manche Wordpress Installationen sind so alt, dass wp-login nicht mehr funktioniert.

Mit wp-cli kann Wordpress auf die aktuelle Version aktualisiert werden:

<syntaxhighlight lang=shell>
cd ~/wordpress # oder ~/doms/meinedomain.de/subs-ssl/www/ oder wo sonst Wordpress installiert ist
~/bin/wp-cli.phar core update
</syntaxhighlight>

Falls nur eine Minor Version installiert werden soll:

<syntaxhighlight lang=shell>
cd ~/wordpress
~/bin/wp-cli.phar core update --minor
</syntaxhighlight>

Update der Plugins und Themes:

<syntaxhighlight lang=shell>
cd ~/wordpress
~/bin/wp-cli.phar plugin update --all
~/bin/wp-cli.phar theme update --all
</syntaxhighlight>

== Umgang mit einem gehackten Wordpress ==

Falls die Wordpress Instanz gehackt wurde, gibt es 2 Möglichkeiten:

* Es kann die Webseite inkl. Dateien und Datenbank auf den Stand aus dem Backup vor dem Angriff zurückgesetzt werden, und muss dann umgehend aktualisiert werden. Bei diesem Vorgehen gehen die seitdem erfassten Beiträge verloren. Leider liegt der Zeitpunkt des Angriffs manchmal schon länger zurück.
* Ansonsten müssen die veränderten Dateien identifiziert und gelöscht werden.

Das Identifizieren der veränderten Dateien kann mit folgenden Mitteln geschehen:

<syntaxhighlight lang=shell>
cd ~/wordpress
~/bin/wp-cli.phar core verify-checksums --include-root --exclude=liesmich.html,readme.html
~/bin/wp-cli.phar plugin --skip-themes --skip-plugins verify-checksums --all
</syntaxhighlight>

in der wp-config.php sollte keine verdächtige Datei eingebunden werden:

<syntaxhighlight lang=shell>
grep include wp-config.php
</syntaxhighlight>

Zuletzt geänderte Dateien finden, im Beispiel der letzten 3 Tage:

<syntaxhighlight lang=shell>
find -ctime -3
</syntaxhighlight>

Zeige Dateien, die schreibgeschützt sind:
<syntaxhighlight lang=shell>
find . -type f ! -perm -u=w
</syntaxhighlight>

Lösche alle .htaccess Dateien mit einer speziellen md5sum:

<syntaxhighlight lang=shell>
md5sum=025ee8275afa054097fc53508448f76a
find . -type f -name ".htaccess" -exec sh -c 'for f; do md5sum "$f" | grep -q "$md5sum" && ls -la "$f"; done' _ {} +
</syntaxhighlight>

Prüfe auch die Dateien im doms Verzeichnis (dort sollten keine php Dateien liegen, z.B. accesson.php oder so):
<syntaxhighlight lang=shell>
find ~/doms
</syntaxhighlight>

Verdächtige Dateien im uploads und cache Verzeichnis finden:

<syntaxhighlight lang=shell>
find wp-content/uploads wp-content/cache -type f \
$ -name '*.php' -o -name '*.phtml' -o -name '*.phar' -o -name '*.ico' $ -ls
</syntaxhighlight>

Verdächtige Dateien finden, die Schadcode speziell kodiert haben:

<syntaxhighlight lang=shell>
grep -rl "eval(base64_decode\|eval(gzinflate\|eval(str_rot13\|eval(htmlspecialchars_decode" . --include="*.php" 2>/dev/null
</syntaxhighlight>

Verdächtige Dateien finden, die versuchen, einen Benutzer mit administrator Rechten anzulegen:

<syntaxhighlight lang=shell>
grep -r '\\"administrator\\"' wp-content/languages/plugins/
</syntaxhighlight>

In der Datenbank sollten die Benutzer mit administrator Rechten kontrolliert werden:

<syntaxhighlight lang=sql>
SELECT m.meta_key, m.meta_value, u.id, u.user_login, u.user_email, u.display_name
FROM wp_usermeta AS m join wp_users AS u ON m.user_id = u.id
WHERE m.meta_key = 'wp_capabilities' AND meta_value LIKE '%administrator%';
</syntaxhighlight>

Die Passwörter der Administratoren sollten zurückgesetzt werden.

Die Authentication Unique Keys and Salts in der wp-config.php sollten zurückgesetzt werden.

== Einen Admin Benutzer hinzufügen ==

Wenn du die Pflege einer WordPress Instanz übernehmen sollst, aber noch keinen Admin Benutzer hast:

<syntaxhighlight lang=shell>

~/bin/wp-cli.phar user create meinuser admin@example.org --role=administrator
</syntaxhighlight>

Entsprechend kann der Benutzer auch wieder gelöscht werden:

<syntaxhighlight lang=shell>
cd ~/wordpress
~/bin/wp-cli.phar user delete meinuser
</syntaxhighlight>

== Bestehendes Wordpress auf neue Domain umziehen ==
Meistens muss nichts weiter geändert werden als die Home und die SITE_URL Option.

Einfach zu ändern geht das indem man sich via phpmyadmin.hostsharing.net in den Datenbank User des Wordpress einloggt und sich die Tabelle wp_options ansieht. Dort müssen die Zeilen mit `siteurl` und `home` an die neuen URLs angepasst werden.

Alternativ kann man das auch über das wp-config.php machen. Meistens gibt es die beiden Einträge noch nicht, einfach an die passende Stelle für die Custom Config neu eintragen:

<syntaxhighlight lang=php>
define('WP_HOME','https://www.new-domain.de/');
define('WP_SITEURL','https://www.new-domain.de/');
</syntaxhighlight>

Generell lohnt es sich die wp_options Tabelle mal noch auf alte Domain Einträge zu untersuchen und ggf zu ersetzen.
Das geht z.B. so:

<syntaxhighlight lang=sql>
SELECT * FROM wp_options WHERE option_value LIKE "%https://old-domain.de%"
</syntaxhighlight>

== Bestehendes Wordpress auf neuen User / Server umziehen / Uploads auf Storage auslagern ==

Meistens muss dafür keine weitere Änderung vorgenommen werden. Manchmal haben vorherige Anbieter einen alternativen Upload Pfad gesetzt. Das zeigt sich dadurch das man angeblich keine Schreibberechtigungen hätte beim Hochladen von z.B. Bildern.

Eine Möglichkeit was dort kaputt sein könnte ist, das die Option `upload_path` noch auf einen alten Pfad vom alten Anbieter gesetzt wurde. Diese Option ist auch zu gebrauchen wenn der häufiger doch mal recht schnell wachsende Uploads Ordner auf den Storage und nicht auf die SSD ausgelagert werden soll.

In der wp_options DB-Tabelle muss entsprechend die Variable `upload_path` angepasst werden. z.B. für den User xyz00-wordpress zu /home/storage/xyz00/users/wordpress/uploads

Generell lohnt es sich die wp_options Tabelle noch mal auf den Alten Pfad zu untersuchen und ggf. anzupassen, das geht z.B. so:

<syntaxhighlight lang=sql>
SELECT * FROM wp_options WHERE option_value LIKE "%/old/path/%"
</syntaxhighlight>

== Objekt Cache einrichten ==

Falls bei dem Bericht über den Zustand der Webseite dieser Eintrag erscheint: "Du solltest einen persistenten Objekt-Cache verwenden", sollte [[Redis#Redis_installieren|Redis installiert]] werden. Es reicht, wenn Redis auf einem Unix-Socket läuft, es muss nicht auf einem Port laufen.

In der wp-config.php sollte dann (relativ weit oben) eingetragen werden:

<syntaxhighlight lang="php">
define('WP_REDIS_SCHEME', 'unix');
define('WP_REDIS_PATH', '/home/pacs/xyz00/users/service/redis/var/redis-server.sock');
define('WP_REDIS_PASSWORD', 'topsecret');
</syntaxhighlight>

Dann kann z.B. das Plugin "Redis Object Cache" von Till Küss installiert werden: https://de.wordpress.org/plugins/redis-cache/

Danach lässt sich der Object Cache unter "Einstellungen / Redis" aktivieren.

== Seiten Cache einrichten ==

Falls bei dem Bericht über den Zustand der Webseite dieser Eintrag erscheint: "Seiten-Cache wurde nicht erkannt, ...", kann das Plugin WP Super Cache von Automattic installiert werden: https://wordpress.org/plugins/wp-super-cache/

Der Cache muss dann in den Einstellungen des Plugins aktiviert werden.

= Links =

*[https://wordpress.org/ Offizielle Webseite von Wordpress]
*[https://wp-cli.org/de/ WP-CLI ist das Kommandozeilen-Werkzeug für WordPress]
*[https://github.com/tpokorra/Hostsharing-Ansible-Wordpress Ansible Playbook für Hostsharing]

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]
[[Kategorie:Software]]
[[Kategorie:Blog]]
[[Kategorie:CMS]]

Wordpress

2026-08-30T20:21:56Z

Tim00: /* Umgang mit einem gehackten Wordpress */

= Wordpress in 5 Minuten =

Installiert wird Wordpress hier unter der Domain https://blog.example.org.

== Vorbereitungen ==

In ''hsadmin'', zum Beispiel mit ''hsscript'':

''hsadmin''-Shell starten mit:
<syntaxhighlight lang=shell>
hsscript -u xyz00 -i
Password: ********
</syntaxhighlight>
Dann nacheinander anlegen:

* Linux User als Domain-Administrator
* Subdomain ''blog.example.org''
* MySQL-User
* MySQL Datenbank
<syntaxhighlight lang=shell>
xyz00@hsadmin> user.add({set:{name:'xyz00-blog',password:'geheim',shell:'/bin/bash',comment:'Wordpress Blog'}})
xyz00@hsadmin> domain.add({set:{name:'blog.example.org',user:'xyz00-blog'}})
xyz00@hsadmin> mysqluser.add({set:{name:'xyz00_wpuser',password:'geheim'}})
xyz00@hsadmin> mysqldb.add({set:{name:'xyz00_wpdb',owner:'xyz00_wpuser'}})
</syntaxhighlight>
== Wordpress installieren ==

Anmelden als Linux-User ''xyz00-blog'':

ssh -l xyz00-blog xyz00.hostsharing.net

''htdocs-ssl'' Verzeichnis vorbereiten

<syntaxhighlight lang=shell>
cd doms/blog.example.org
rm -rf subs/www subs-ssl/www
cd htdocs-ssl
rm .htaccess
</syntaxhighlight>

Wordpress downloaden & entpacken z.b. im htdocs-ssl Verzeichnis

<syntaxhighlight lang=shell>
wget -O - https://wordpress.org/latest.tar.gz |tar -xz --strip 1
</syntaxhighlight>

== Wordpress konfigurieren ==

Im Browser auf die Seite
http://blog.example.org gehen und den Anweisungen folgen.

= Verschiedene Hinweise und Anleitungen =
== wp-cli installieren ==

wp-cli ist das Kommandozeilen-Werkzeug für WordPress: https://wp-cli.org/de/

Es kann so installiert werden:

<syntaxhighlight lang=shell>
mkdir ~/bin
cd ~/bin
wget https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod a+x wp-cli.phar
</syntaxhighlight>

== Uraltes Wordpress aktualisieren ==

Manche Wordpress Installationen sind so alt, dass wp-login nicht mehr funktioniert.

Mit wp-cli kann Wordpress auf die aktuelle Version aktualisiert werden:

<syntaxhighlight lang=shell>
cd ~/wordpress # oder ~/doms/meinedomain.de/subs-ssl/www/ oder wo sonst Wordpress installiert ist
~/bin/wp-cli.phar core update
</syntaxhighlight>

Falls nur eine Minor Version installiert werden soll:

<syntaxhighlight lang=shell>
cd ~/wordpress
~/bin/wp-cli.phar core update --minor
</syntaxhighlight>

Update der Plugins und Themes:

<syntaxhighlight lang=shell>
cd ~/wordpress
~/bin/wp-cli.phar plugin update --all
~/bin/wp-cli.phar theme update --all
</syntaxhighlight>

== Umgang mit einem gehackten Wordpress ==

Falls die Wordpress Instanz gehackt wurde, gibt es 2 Möglichkeiten:

* Es kann die Webseite inkl. Dateien und Datenbank auf den Stand aus dem Backup vor dem Angriff zurückgesetzt werden, und muss dann umgehend aktualisiert werden. Bei diesem Vorgehen gehen die seitdem erfassten Beiträge verloren. Leider liegt der Zeitpunkt des Angriffs manchmal schon länger zurück.
* Ansonsten müssen die veränderten Dateien identifiziert und gelöscht werden.

Das Identifizieren der veränderten Dateien kann mit folgenden Mitteln geschehen:

<syntaxhighlight lang=shell>
cd ~/wordpress
~/bin/wp-cli.phar core verify-checksums --include-root --exclude=liesmich.html,readme.html
~/bin/wp-cli.phar plugin --skip-themes --skip-plugins verify-checksums --all
</syntaxhighlight>

in der wp-config.php sollte keine verdächtige Datei eingebunden werden:

<syntaxhighlight lang=shell>
grep include wp-config.php
</syntaxhighlight>

Zuletzt geänderte Dateien finden, im Beispiel der letzten 3 Tage:

<syntaxhighlight lang=shell>
find -ctime -3
</syntaxhighlight>

Zeige Dateien, die schreibgeschützt sind:
<syntaxhighlight lang=shell>
find . -type f ! -perm -u=w
</syntaxhighlight>

Lösche alle .htaccess Dateien mit einer speziellen md5sum:

<syntaxhighlight lang=shell>
md5sum=025ee8275afa054097fc53508448f76a
find . -type f -name ".htaccess" -exec sh -c 'for f; do md5sum "$f" | grep -q "$md5sum" && ls -la "$f"; done' _ {} +
</syntaxhighlight>

Prüfe auch die Dateien im doms Verzeichnis (dort sollten keine php Dateien liegen, z.B. accesson.php oder so):
<syntaxhighlight lang=shell>
find ~/doms
</syntaxhighlight>

Verdächtige Dateien im uploads und cache Verzeichnis finden:

<syntaxhighlight lang=shell>
find wp-content/uploads wp-content/cache -type f \
$ -name '*.php' -o -name '*.phtml' -o -name '*.phar' -o -name '*.ico' $ -ls
</syntaxhighlight>

Verdächtige Dateien finden, die Schadcode speziell kodiert haben:

<syntaxhighlight lang=shell>
grep -rl "eval(base64_decode\|eval(gzinflate\|eval(str_rot13\|eval(htmlspecialchars_decode" . --include="*.php" 2>/dev/null
</syntaxhighlight>

Verdächtige Dateien finden, die versuchen, einen Benutzer mit administrator Rechten anzulegen:

<syntaxhighlight lang=shell>
grep -r '\\"administrator\\"' wp-content/languages/plugins/
</syntaxhighlight>

In der Datenbank sollten die Benutzer mit administrator Rechten kontrolliert werden:

<syntaxhighlight lang=sql>
SELECT m.meta_key, m.meta_value, u.id, u.user_login, u.user_email, u.display_name
FROM wp_usermeta AS m join wp_users AS u ON m.user_id = u.id
WHERE m.meta_key = 'wp_capabilities' AND meta_value LIKE '%administrator%';
</syntaxhighlight>

== Einen Admin Benutzer hinzufügen ==

Wenn du die Pflege einer WordPress Instanz übernehmen sollst, aber noch keinen Admin Benutzer hast:

<syntaxhighlight lang=shell>

~/bin/wp-cli.phar user create meinuser admin@example.org --role=administrator
</syntaxhighlight>

Entsprechend kann der Benutzer auch wieder gelöscht werden:

<syntaxhighlight lang=shell>
cd ~/wordpress
~/bin/wp-cli.phar user delete meinuser
</syntaxhighlight>

== Bestehendes Wordpress auf neue Domain umziehen ==
Meistens muss nichts weiter geändert werden als die Home und die SITE_URL Option.

Einfach zu ändern geht das indem man sich via phpmyadmin.hostsharing.net in den Datenbank User des Wordpress einloggt und sich die Tabelle wp_options ansieht. Dort müssen die Zeilen mit `siteurl` und `home` an die neuen URLs angepasst werden.

Alternativ kann man das auch über das wp-config.php machen. Meistens gibt es die beiden Einträge noch nicht, einfach an die passende Stelle für die Custom Config neu eintragen:

<syntaxhighlight lang=php>
define('WP_HOME','https://www.new-domain.de/');
define('WP_SITEURL','https://www.new-domain.de/');
</syntaxhighlight>

Generell lohnt es sich die wp_options Tabelle mal noch auf alte Domain Einträge zu untersuchen und ggf zu ersetzen.
Das geht z.B. so:

<syntaxhighlight lang=sql>
SELECT * FROM wp_options WHERE option_value LIKE "%https://old-domain.de%"
</syntaxhighlight>

== Bestehendes Wordpress auf neuen User / Server umziehen / Uploads auf Storage auslagern ==

Meistens muss dafür keine weitere Änderung vorgenommen werden. Manchmal haben vorherige Anbieter einen alternativen Upload Pfad gesetzt. Das zeigt sich dadurch das man angeblich keine Schreibberechtigungen hätte beim Hochladen von z.B. Bildern.

Eine Möglichkeit was dort kaputt sein könnte ist, das die Option `upload_path` noch auf einen alten Pfad vom alten Anbieter gesetzt wurde. Diese Option ist auch zu gebrauchen wenn der häufiger doch mal recht schnell wachsende Uploads Ordner auf den Storage und nicht auf die SSD ausgelagert werden soll.

In der wp_options DB-Tabelle muss entsprechend die Variable `upload_path` angepasst werden. z.B. für den User xyz00-wordpress zu /home/storage/xyz00/users/wordpress/uploads

Generell lohnt es sich die wp_options Tabelle noch mal auf den Alten Pfad zu untersuchen und ggf. anzupassen, das geht z.B. so:

<syntaxhighlight lang=sql>
SELECT * FROM wp_options WHERE option_value LIKE "%/old/path/%"
</syntaxhighlight>

== Objekt Cache einrichten ==

Falls bei dem Bericht über den Zustand der Webseite dieser Eintrag erscheint: "Du solltest einen persistenten Objekt-Cache verwenden", sollte [[Redis#Redis_installieren|Redis installiert]] werden. Es reicht, wenn Redis auf einem Unix-Socket läuft, es muss nicht auf einem Port laufen.

In der wp-config.php sollte dann (relativ weit oben) eingetragen werden:

<syntaxhighlight lang="php">
define('WP_REDIS_SCHEME', 'unix');
define('WP_REDIS_PATH', '/home/pacs/xyz00/users/service/redis/var/redis-server.sock');
define('WP_REDIS_PASSWORD', 'topsecret');
</syntaxhighlight>

Dann kann z.B. das Plugin "Redis Object Cache" von Till Küss installiert werden: https://de.wordpress.org/plugins/redis-cache/

Danach lässt sich der Object Cache unter "Einstellungen / Redis" aktivieren.

== Seiten Cache einrichten ==

Falls bei dem Bericht über den Zustand der Webseite dieser Eintrag erscheint: "Seiten-Cache wurde nicht erkannt, ...", kann das Plugin WP Super Cache von Automattic installiert werden: https://wordpress.org/plugins/wp-super-cache/

Der Cache muss dann in den Einstellungen des Plugins aktiviert werden.

= Links =

*[https://wordpress.org/ Offizielle Webseite von Wordpress]
*[https://wp-cli.org/de/ WP-CLI ist das Kommandozeilen-Werkzeug für WordPress]
*[https://github.com/tpokorra/Hostsharing-Ansible-Wordpress Ansible Playbook für Hostsharing]

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]
[[Kategorie:Software]]
[[Kategorie:Blog]]
[[Kategorie:CMS]]

Wordpress

2026-08-30T19:58:16Z

Tim00: /* Umgang mit einem gehackten Wordpress */

= Wordpress in 5 Minuten =

Installiert wird Wordpress hier unter der Domain https://blog.example.org.

== Vorbereitungen ==

In ''hsadmin'', zum Beispiel mit ''hsscript'':

''hsadmin''-Shell starten mit:
<syntaxhighlight lang=shell>
hsscript -u xyz00 -i
Password: ********
</syntaxhighlight>
Dann nacheinander anlegen:

* Linux User als Domain-Administrator
* Subdomain ''blog.example.org''
* MySQL-User
* MySQL Datenbank
<syntaxhighlight lang=shell>
xyz00@hsadmin> user.add({set:{name:'xyz00-blog',password:'geheim',shell:'/bin/bash',comment:'Wordpress Blog'}})
xyz00@hsadmin> domain.add({set:{name:'blog.example.org',user:'xyz00-blog'}})
xyz00@hsadmin> mysqluser.add({set:{name:'xyz00_wpuser',password:'geheim'}})
xyz00@hsadmin> mysqldb.add({set:{name:'xyz00_wpdb',owner:'xyz00_wpuser'}})
</syntaxhighlight>
== Wordpress installieren ==

Anmelden als Linux-User ''xyz00-blog'':

ssh -l xyz00-blog xyz00.hostsharing.net

''htdocs-ssl'' Verzeichnis vorbereiten

<syntaxhighlight lang=shell>
cd doms/blog.example.org
rm -rf subs/www subs-ssl/www
cd htdocs-ssl
rm .htaccess
</syntaxhighlight>

Wordpress downloaden & entpacken z.b. im htdocs-ssl Verzeichnis

<syntaxhighlight lang=shell>
wget -O - https://wordpress.org/latest.tar.gz |tar -xz --strip 1
</syntaxhighlight>

== Wordpress konfigurieren ==

Im Browser auf die Seite
http://blog.example.org gehen und den Anweisungen folgen.

= Verschiedene Hinweise und Anleitungen =
== wp-cli installieren ==

wp-cli ist das Kommandozeilen-Werkzeug für WordPress: https://wp-cli.org/de/

Es kann so installiert werden:

<syntaxhighlight lang=shell>
mkdir ~/bin
cd ~/bin
wget https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod a+x wp-cli.phar
</syntaxhighlight>

== Uraltes Wordpress aktualisieren ==

Manche Wordpress Installationen sind so alt, dass wp-login nicht mehr funktioniert.

Mit wp-cli kann Wordpress auf die aktuelle Version aktualisiert werden:

<syntaxhighlight lang=shell>
cd ~/wordpress # oder ~/doms/meinedomain.de/subs-ssl/www/ oder wo sonst Wordpress installiert ist
~/bin/wp-cli.phar core update
</syntaxhighlight>

Falls nur eine Minor Version installiert werden soll:

<syntaxhighlight lang=shell>
cd ~/wordpress
~/bin/wp-cli.phar core update --minor
</syntaxhighlight>

Update der Plugins und Themes:

<syntaxhighlight lang=shell>
cd ~/wordpress
~/bin/wp-cli.phar plugin update --all
~/bin/wp-cli.phar theme update --all
</syntaxhighlight>

== Umgang mit einem gehackten Wordpress ==

Falls die Wordpress Instanz gehackt wurde, gibt es 2 Möglichkeiten:

* Es kann die Webseite inkl. Dateien und Datenbank auf den Stand aus dem Backup vor dem Angriff zurückgesetzt werden, und muss dann umgehend aktualisiert werden. Bei diesem Vorgehen gehen die seitdem erfassten Beiträge verloren. Leider liegt der Zeitpunkt des Angriffs manchmal schon länger zurück.
* Ansonsten müssen die veränderten Dateien identifiziert und gelöscht werden.

Das Identifizieren der veränderten Dateien kann mit folgenden Mitteln geschehen:

<syntaxhighlight lang=shell>
cd ~/wordpress
~/bin/wp-cli.phar core verify-checksums --include-root --exclude=liesmich.html,readme.html
~/bin/wp-cli.phar plugin --skip-themes --skip-plugins verify-checksums --all
</syntaxhighlight>

in der wp-config.php sollte keine verdächtige Datei eingebunden werden:

<syntaxhighlight lang=shell>
grep include wp-config.php
</syntaxhighlight>

Zuletzt geänderte Dateien finden, im Beispiel der letzten 3 Tage:

<syntaxhighlight lang=shell>
find -ctime -3
</syntaxhighlight>

Zeige Dateien, die schreibgeschützt sind:
<syntaxhighlight lang=shell>
find . -type f ! -perm -u=w
</syntaxhighlight>

Lösche alle .htaccess Dateien mit einer speziellen md5sum:

<syntaxhighlight lang=shell>
md5sum=025ee8275afa054097fc53508448f76a
find . -type f -name ".htaccess" -exec sh -c 'for f; do md5sum "$f" | grep -q "$md5sum" && ls -la "$f"; done' _ {} +
</syntaxhighlight>

Verdächtige Dateien im uploads und cache Verzeichnis finden:

<syntaxhighlight lang=shell>
find wp-content/uploads wp-content/cache -type f \
$ -name '*.php' -o -name '*.phtml' -o -name '*.phar' -o -name '*.ico' $ -ls
</syntaxhighlight>

Verdächtige Dateien finden, die Schadcode speziell kodiert haben:

<syntaxhighlight lang=shell>
grep -rl "eval(base64_decode\|eval(gzinflate\|eval(str_rot13\|eval(htmlspecialchars_decode" . --include="*.php" 2>/dev/null
</syntaxhighlight>

Verdächtige Dateien finden, die versuchen, einen Benutzer mit administrator Rechten anzulegen:

<syntaxhighlight lang=shell>
grep -r '\\"administrator\\"' wp-content/languages/plugins/
</syntaxhighlight>

In der Datenbank sollten die Benutzer mit administrator Rechten kontrolliert werden:

<syntaxhighlight lang=sql>
SELECT m.meta_key, m.meta_value, u.id, u.user_login, u.user_email, u.display_name
FROM wp_usermeta AS m join wp_users AS u ON m.user_id = u.id
WHERE m.meta_key = 'wp_capabilities' AND meta_value LIKE '%administrator%';
</syntaxhighlight>

== Einen Admin Benutzer hinzufügen ==

Wenn du die Pflege einer WordPress Instanz übernehmen sollst, aber noch keinen Admin Benutzer hast:

<syntaxhighlight lang=shell>

~/bin/wp-cli.phar user create meinuser admin@example.org --role=administrator
</syntaxhighlight>

Entsprechend kann der Benutzer auch wieder gelöscht werden:

<syntaxhighlight lang=shell>
cd ~/wordpress
~/bin/wp-cli.phar user delete meinuser
</syntaxhighlight>

== Bestehendes Wordpress auf neue Domain umziehen ==
Meistens muss nichts weiter geändert werden als die Home und die SITE_URL Option.

Einfach zu ändern geht das indem man sich via phpmyadmin.hostsharing.net in den Datenbank User des Wordpress einloggt und sich die Tabelle wp_options ansieht. Dort müssen die Zeilen mit `siteurl` und `home` an die neuen URLs angepasst werden.

Alternativ kann man das auch über das wp-config.php machen. Meistens gibt es die beiden Einträge noch nicht, einfach an die passende Stelle für die Custom Config neu eintragen:

<syntaxhighlight lang=php>
define('WP_HOME','https://www.new-domain.de/');
define('WP_SITEURL','https://www.new-domain.de/');
</syntaxhighlight>

Generell lohnt es sich die wp_options Tabelle mal noch auf alte Domain Einträge zu untersuchen und ggf zu ersetzen.
Das geht z.B. so:

<syntaxhighlight lang=sql>
SELECT * FROM wp_options WHERE option_value LIKE "%https://old-domain.de%"
</syntaxhighlight>

== Bestehendes Wordpress auf neuen User / Server umziehen / Uploads auf Storage auslagern ==

Meistens muss dafür keine weitere Änderung vorgenommen werden. Manchmal haben vorherige Anbieter einen alternativen Upload Pfad gesetzt. Das zeigt sich dadurch das man angeblich keine Schreibberechtigungen hätte beim Hochladen von z.B. Bildern.

Eine Möglichkeit was dort kaputt sein könnte ist, das die Option `upload_path` noch auf einen alten Pfad vom alten Anbieter gesetzt wurde. Diese Option ist auch zu gebrauchen wenn der häufiger doch mal recht schnell wachsende Uploads Ordner auf den Storage und nicht auf die SSD ausgelagert werden soll.

In der wp_options DB-Tabelle muss entsprechend die Variable `upload_path` angepasst werden. z.B. für den User xyz00-wordpress zu /home/storage/xyz00/users/wordpress/uploads

Generell lohnt es sich die wp_options Tabelle noch mal auf den Alten Pfad zu untersuchen und ggf. anzupassen, das geht z.B. so:

<syntaxhighlight lang=sql>
SELECT * FROM wp_options WHERE option_value LIKE "%/old/path/%"
</syntaxhighlight>

== Objekt Cache einrichten ==

Falls bei dem Bericht über den Zustand der Webseite dieser Eintrag erscheint: "Du solltest einen persistenten Objekt-Cache verwenden", sollte [[Redis#Redis_installieren|Redis installiert]] werden. Es reicht, wenn Redis auf einem Unix-Socket läuft, es muss nicht auf einem Port laufen.

In der wp-config.php sollte dann (relativ weit oben) eingetragen werden:

<syntaxhighlight lang="php">
define('WP_REDIS_SCHEME', 'unix');
define('WP_REDIS_PATH', '/home/pacs/xyz00/users/service/redis/var/redis-server.sock');
define('WP_REDIS_PASSWORD', 'topsecret');
</syntaxhighlight>

Dann kann z.B. das Plugin "Redis Object Cache" von Till Küss installiert werden: https://de.wordpress.org/plugins/redis-cache/

Danach lässt sich der Object Cache unter "Einstellungen / Redis" aktivieren.

== Seiten Cache einrichten ==

Falls bei dem Bericht über den Zustand der Webseite dieser Eintrag erscheint: "Seiten-Cache wurde nicht erkannt, ...", kann das Plugin WP Super Cache von Automattic installiert werden: https://wordpress.org/plugins/wp-super-cache/

Der Cache muss dann in den Einstellungen des Plugins aktiviert werden.

= Links =

*[https://wordpress.org/ Offizielle Webseite von Wordpress]
*[https://wp-cli.org/de/ WP-CLI ist das Kommandozeilen-Werkzeug für WordPress]
*[https://github.com/tpokorra/Hostsharing-Ansible-Wordpress Ansible Playbook für Hostsharing]

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]
[[Kategorie:Software]]
[[Kategorie:Blog]]
[[Kategorie:CMS]]

Wordpress

2026-08-30T19:42:54Z

Tim00: /* Umgang mit einem gehackten Wordpress */

= Wordpress in 5 Minuten =

Installiert wird Wordpress hier unter der Domain https://blog.example.org.

== Vorbereitungen ==

In ''hsadmin'', zum Beispiel mit ''hsscript'':

''hsadmin''-Shell starten mit:
<syntaxhighlight lang=shell>
hsscript -u xyz00 -i
Password: ********
</syntaxhighlight>
Dann nacheinander anlegen:

* Linux User als Domain-Administrator
* Subdomain ''blog.example.org''
* MySQL-User
* MySQL Datenbank
<syntaxhighlight lang=shell>
xyz00@hsadmin> user.add({set:{name:'xyz00-blog',password:'geheim',shell:'/bin/bash',comment:'Wordpress Blog'}})
xyz00@hsadmin> domain.add({set:{name:'blog.example.org',user:'xyz00-blog'}})
xyz00@hsadmin> mysqluser.add({set:{name:'xyz00_wpuser',password:'geheim'}})
xyz00@hsadmin> mysqldb.add({set:{name:'xyz00_wpdb',owner:'xyz00_wpuser'}})
</syntaxhighlight>
== Wordpress installieren ==

Anmelden als Linux-User ''xyz00-blog'':

ssh -l xyz00-blog xyz00.hostsharing.net

''htdocs-ssl'' Verzeichnis vorbereiten

<syntaxhighlight lang=shell>
cd doms/blog.example.org
rm -rf subs/www subs-ssl/www
cd htdocs-ssl
rm .htaccess
</syntaxhighlight>

Wordpress downloaden & entpacken z.b. im htdocs-ssl Verzeichnis

<syntaxhighlight lang=shell>
wget -O - https://wordpress.org/latest.tar.gz |tar -xz --strip 1
</syntaxhighlight>

== Wordpress konfigurieren ==

Im Browser auf die Seite
http://blog.example.org gehen und den Anweisungen folgen.

= Verschiedene Hinweise und Anleitungen =
== wp-cli installieren ==

wp-cli ist das Kommandozeilen-Werkzeug für WordPress: https://wp-cli.org/de/

Es kann so installiert werden:

<syntaxhighlight lang=shell>
mkdir ~/bin
cd ~/bin
wget https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod a+x wp-cli.phar
</syntaxhighlight>

== Uraltes Wordpress aktualisieren ==

Manche Wordpress Installationen sind so alt, dass wp-login nicht mehr funktioniert.

Mit wp-cli kann Wordpress auf die aktuelle Version aktualisiert werden:

<syntaxhighlight lang=shell>
cd ~/wordpress # oder ~/doms/meinedomain.de/subs-ssl/www/ oder wo sonst Wordpress installiert ist
~/bin/wp-cli.phar core update
</syntaxhighlight>

Falls nur eine Minor Version installiert werden soll:

<syntaxhighlight lang=shell>
cd ~/wordpress
~/bin/wp-cli.phar core update --minor
</syntaxhighlight>

Update der Plugins und Themes:

<syntaxhighlight lang=shell>
cd ~/wordpress
~/bin/wp-cli.phar plugin update --all
~/bin/wp-cli.phar theme update --all
</syntaxhighlight>

== Umgang mit einem gehackten Wordpress ==

Falls die Wordpress Instanz gehackt wurde, gibt es 2 Möglichkeiten:

* Es kann die Webseite inkl. Dateien und Datenbank auf den Stand aus dem Backup vor dem Angriff zurückgesetzt werden, und muss dann umgehend aktualisiert werden. Bei diesem Vorgehen gehen die seitdem erfassten Beiträge verloren. Leider liegt der Zeitpunkt des Angriffs manchmal schon länger zurück.
* Ansonsten müssen die veränderten Dateien identifiziert und gelöscht werden.

Das Identifizieren der veränderten Dateien kann mit folgenden Mitteln geschehen:

<syntaxhighlight lang=shell>
cd ~/wordpress
~/bin/wp-cli.phar core verify-checksums --include-root --exclude=liesmich.html,readme.html
~/bin/wp-cli.phar plugin --skip-themes --skip-plugins verify-checksums --all
</syntaxhighlight>

in der wp-config.php sollte keine verdächtige Datei eingebunden werden:

<syntaxhighlight lang=shell>
grep include wp-config.php
</syntaxhighlight>

Zuletzt geänderte Dateien finden, im Beispiel der letzten 3 Tage:

<syntaxhighlight lang=shell>
find -ctime -3
</syntaxhighlight>

Zeige Dateien, die schreibgeschützt sind:
<syntaxhighlight lang=shell>
find . -type f ! -perm -u=w
</syntaxhighlight>

Lösche alle .htaccess Dateien mit einer speziellen md5sum:

<syntaxhighlight lang=shell>
md5sum=025ee8275afa054097fc53508448f76a
find . -type f -name ".htaccess" -exec sh -c 'for f; do md5sum "$f" | grep -q "$md5sum" && ls -la "$f"; done' _ {} +
</syntaxhighlight>

Verdächtige Dateien im uploads und cache Verzeichnis finden:

<syntaxhighlight lang=shell>
find wp-content/uploads wp-content/cache -type f \
$ -name '*.php' -o -name '*.phtml' -o -name '*.phar' -o -name '*.ico' $ -ls
</syntaxhighlight>

Verdächtige Dateien finden, die Schadcode speziell kodiert haben:

<syntaxhighlight lang=shell>
grep -rl "eval(base64_decode\|eval(gzinflate\|eval(str_rot13\|eval(htmlspecialchars_decode" . --include="*.php" 2>/dev/null
</syntaxhighlight>

Verdächtige Dateien finden, die versuchen, einen Benutzer mit administrator Rechten anzulegen:

<syntaxhighlight lang=shell>
grep -r '\\"administrator\\"' wp-content/languages/plugins/
</syntaxhighlight>

In der Datenbank sollten die Benutzer mit administrator Rechten kontrolliert werden:

<syntaxhighlight lang=sql>
SELECT m.meta_key, m.meta_value, u.id, u.user_login, u.user_email, u.display_name
FROM wp_usermeta AS m join wp_users AS u ON m.user_id = u.id
WHERE meta_value LIKE '%administrator%';
</syntaxhighlight>

== Einen Admin Benutzer hinzufügen ==

Wenn du die Pflege einer WordPress Instanz übernehmen sollst, aber noch keinen Admin Benutzer hast:

<syntaxhighlight lang=shell>

~/bin/wp-cli.phar user create meinuser admin@example.org --role=administrator
</syntaxhighlight>

Entsprechend kann der Benutzer auch wieder gelöscht werden:

<syntaxhighlight lang=shell>
cd ~/wordpress
~/bin/wp-cli.phar user delete meinuser
</syntaxhighlight>

== Bestehendes Wordpress auf neue Domain umziehen ==
Meistens muss nichts weiter geändert werden als die Home und die SITE_URL Option.

Einfach zu ändern geht das indem man sich via phpmyadmin.hostsharing.net in den Datenbank User des Wordpress einloggt und sich die Tabelle wp_options ansieht. Dort müssen die Zeilen mit `siteurl` und `home` an die neuen URLs angepasst werden.

Alternativ kann man das auch über das wp-config.php machen. Meistens gibt es die beiden Einträge noch nicht, einfach an die passende Stelle für die Custom Config neu eintragen:

<syntaxhighlight lang=php>
define('WP_HOME','https://www.new-domain.de/');
define('WP_SITEURL','https://www.new-domain.de/');
</syntaxhighlight>

Generell lohnt es sich die wp_options Tabelle mal noch auf alte Domain Einträge zu untersuchen und ggf zu ersetzen.
Das geht z.B. so:

<syntaxhighlight lang=sql>
SELECT * FROM wp_options WHERE option_value LIKE "%https://old-domain.de%"
</syntaxhighlight>

== Bestehendes Wordpress auf neuen User / Server umziehen / Uploads auf Storage auslagern ==

Meistens muss dafür keine weitere Änderung vorgenommen werden. Manchmal haben vorherige Anbieter einen alternativen Upload Pfad gesetzt. Das zeigt sich dadurch das man angeblich keine Schreibberechtigungen hätte beim Hochladen von z.B. Bildern.

Eine Möglichkeit was dort kaputt sein könnte ist, das die Option `upload_path` noch auf einen alten Pfad vom alten Anbieter gesetzt wurde. Diese Option ist auch zu gebrauchen wenn der häufiger doch mal recht schnell wachsende Uploads Ordner auf den Storage und nicht auf die SSD ausgelagert werden soll.

In der wp_options DB-Tabelle muss entsprechend die Variable `upload_path` angepasst werden. z.B. für den User xyz00-wordpress zu /home/storage/xyz00/users/wordpress/uploads

Generell lohnt es sich die wp_options Tabelle noch mal auf den Alten Pfad zu untersuchen und ggf. anzupassen, das geht z.B. so:

<syntaxhighlight lang=sql>
SELECT * FROM wp_options WHERE option_value LIKE "%/old/path/%"
</syntaxhighlight>

== Objekt Cache einrichten ==

Falls bei dem Bericht über den Zustand der Webseite dieser Eintrag erscheint: "Du solltest einen persistenten Objekt-Cache verwenden", sollte [[Redis#Redis_installieren|Redis installiert]] werden. Es reicht, wenn Redis auf einem Unix-Socket läuft, es muss nicht auf einem Port laufen.

In der wp-config.php sollte dann (relativ weit oben) eingetragen werden:

<syntaxhighlight lang="php">
define('WP_REDIS_SCHEME', 'unix');
define('WP_REDIS_PATH', '/home/pacs/xyz00/users/service/redis/var/redis-server.sock');
define('WP_REDIS_PASSWORD', 'topsecret');
</syntaxhighlight>

Dann kann z.B. das Plugin "Redis Object Cache" von Till Küss installiert werden: https://de.wordpress.org/plugins/redis-cache/

Danach lässt sich der Object Cache unter "Einstellungen / Redis" aktivieren.

== Seiten Cache einrichten ==

Falls bei dem Bericht über den Zustand der Webseite dieser Eintrag erscheint: "Seiten-Cache wurde nicht erkannt, ...", kann das Plugin WP Super Cache von Automattic installiert werden: https://wordpress.org/plugins/wp-super-cache/

Der Cache muss dann in den Einstellungen des Plugins aktiviert werden.

= Links =

*[https://wordpress.org/ Offizielle Webseite von Wordpress]
*[https://wp-cli.org/de/ WP-CLI ist das Kommandozeilen-Werkzeug für WordPress]
*[https://github.com/tpokorra/Hostsharing-Ansible-Wordpress Ansible Playbook für Hostsharing]

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]
[[Kategorie:Software]]
[[Kategorie:Blog]]
[[Kategorie:CMS]]

Wordpress

2026-08-27T04:12:42Z

Tim00: /* Uraltes Wordpress aktualisieren */

= Wordpress in 5 Minuten =

Installiert wird Wordpress hier unter der Domain https://blog.example.org.

== Vorbereitungen ==

In ''hsadmin'', zum Beispiel mit ''hsscript'':

''hsadmin''-Shell starten mit:
<syntaxhighlight lang=shell>
hsscript -u xyz00 -i
Password: ********
</syntaxhighlight>
Dann nacheinander anlegen:

* Linux User als Domain-Administrator
* Subdomain ''blog.example.org''
* MySQL-User
* MySQL Datenbank
<syntaxhighlight lang=shell>
xyz00@hsadmin> user.add({set:{name:'xyz00-blog',password:'geheim',shell:'/bin/bash',comment:'Wordpress Blog'}})
xyz00@hsadmin> domain.add({set:{name:'blog.example.org',user:'xyz00-blog'}})
xyz00@hsadmin> mysqluser.add({set:{name:'xyz00_wpuser',password:'geheim'}})
xyz00@hsadmin> mysqldb.add({set:{name:'xyz00_wpdb',owner:'xyz00_wpuser'}})
</syntaxhighlight>
== Wordpress installieren ==

Anmelden als Linux-User ''xyz00-blog'':

ssh -l xyz00-blog xyz00.hostsharing.net

''htdocs-ssl'' Verzeichnis vorbereiten

<syntaxhighlight lang=shell>
cd doms/blog.example.org
rm -rf subs/www subs-ssl/www
cd htdocs-ssl
rm .htaccess
</syntaxhighlight>

Wordpress downloaden & entpacken z.b. im htdocs-ssl Verzeichnis

<syntaxhighlight lang=shell>
wget -O - https://wordpress.org/latest.tar.gz |tar -xz --strip 1
</syntaxhighlight>

== Wordpress konfigurieren ==

Im Browser auf die Seite
http://blog.example.org gehen und den Anweisungen folgen.

= Verschiedene Hinweise und Anleitungen =
== wp-cli installieren ==

wp-cli ist das Kommandozeilen-Werkzeug für WordPress: https://wp-cli.org/de/

Es kann so installiert werden:

<syntaxhighlight lang=shell>
mkdir ~/bin
cd ~/bin
wget https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod a+x wp-cli.phar
</syntaxhighlight>

== Uraltes Wordpress aktualisieren ==

Manche Wordpress Installationen sind so alt, dass wp-login nicht mehr funktioniert.

Mit wp-cli kann Wordpress auf die aktuelle Version aktualisiert werden:

<syntaxhighlight lang=shell>
cd ~/wordpress # oder ~/doms/meinedomain.de/subs-ssl/www/ oder wo sonst Wordpress installiert ist
~/bin/wp-cli.phar core update
</syntaxhighlight>

Falls nur eine Minor Version installiert werden soll:

<syntaxhighlight lang=shell>
cd ~/wordpress
~/bin/wp-cli.phar core update --minor
</syntaxhighlight>

Update der Plugins und Themes:

<syntaxhighlight lang=shell>
cd ~/wordpress
~/bin/wp-cli.phar plugin update --all
~/bin/wp-cli.phar theme update --all
</syntaxhighlight>

== Umgang mit einem gehackten Wordpress ==

Falls die Wordpress Instanz gehackt wurde, gibt es 2 Möglichkeiten:

* Es kann die Webseite inkl. Dateien und Datenbank auf den Stand aus dem Backup vor dem Angriff zurückgesetzt werden, und muss dann umgehend aktualisiert werden. Bei diesem Vorgehen gehen die seitdem erfassten Beiträge verloren. Leider liegt der Zeitpunkt des Angriffs manchmal schon länger zurück.
* Ansonsten müssen die veränderten Dateien identifiziert und gelöscht werden.

Das Identifizieren der veränderten Dateien kann mit folgenden Mitteln geschehen:

<syntaxhighlight lang=shell>
cd ~/wordpress
~/bin/wp-cli.phar core verify-checksums --include-root --exclude=liesmich.html,readme.html
~/bin/wp-cli.phar plugin --skip-themes --skip-plugins verify-checksums --all
</syntaxhighlight>

in der wp-config.php sollte keine verdächtige Datei eingebunden werden:

<syntaxhighlight lang=shell>
grep include wp-config.php
</syntaxhighlight>

Zuletzt geänderte Dateien finden, im Beispiel der letzten 3 Tage:

<syntaxhighlight lang=shell>
find -ctime -3
</syntaxhighlight>

Verdächtige Dateien im uploads und cache Verzeichnis finden:

<syntaxhighlight lang=shell>
find wp-content/uploads wp-content/cache -type f \
$ -name '*.php' -o -name '*.phtml' -o -name '*.phar' -o -name '*.ico' $ -ls
</syntaxhighlight>

Verdächtige Dateien finden, die Schadcode speziell kodiert haben:

<syntaxhighlight lang=shell>
grep -rl "eval(base64_decode\|eval(gzinflate\|eval(str_rot13\|eval(htmlspecialchars_decode" . --include="*.php" 2>/dev/null
</syntaxhighlight>

Verdächtige Dateien finden, die versuchen, einen Benutzer mit administrator Rechten anzulegen:

<syntaxhighlight lang=shell>
grep -r '\\"administrator\\"' wp-content/languages/plugins/
</syntaxhighlight>

In der Datenbank sollten die Benutzer mit administrator Rechten kontrolliert werden:

<syntaxhighlight lang=sql>
SELECT m.meta_key, m.meta_value, u.id, u.user_login, u.user_email, u.display_name
FROM wp_usermeta AS m join wp_users AS u ON m.user_id = u.id
WHERE meta_value LIKE '%administrator%';
</syntaxhighlight>

== Einen Admin Benutzer hinzufügen ==

Wenn du die Pflege einer WordPress Instanz übernehmen sollst, aber noch keinen Admin Benutzer hast:

<syntaxhighlight lang=shell>

~/bin/wp-cli.phar user create meinuser admin@example.org --role=administrator
</syntaxhighlight>

Entsprechend kann der Benutzer auch wieder gelöscht werden:

<syntaxhighlight lang=shell>
cd ~/wordpress
~/bin/wp-cli.phar user delete meinuser
</syntaxhighlight>

== Bestehendes Wordpress auf neue Domain umziehen ==
Meistens muss nichts weiter geändert werden als die Home und die SITE_URL Option.

Einfach zu ändern geht das indem man sich via phpmyadmin.hostsharing.net in den Datenbank User des Wordpress einloggt und sich die Tabelle wp_options ansieht. Dort müssen die Zeilen mit `siteurl` und `home` an die neuen URLs angepasst werden.

Alternativ kann man das auch über das wp-config.php machen. Meistens gibt es die beiden Einträge noch nicht, einfach an die passende Stelle für die Custom Config neu eintragen:

<syntaxhighlight lang=php>
define('WP_HOME','https://www.new-domain.de/');
define('WP_SITEURL','https://www.new-domain.de/');
</syntaxhighlight>

Generell lohnt es sich die wp_options Tabelle mal noch auf alte Domain Einträge zu untersuchen und ggf zu ersetzen.
Das geht z.B. so:

<syntaxhighlight lang=sql>
SELECT * FROM wp_options WHERE option_value LIKE "%https://old-domain.de%"
</syntaxhighlight>

== Bestehendes Wordpress auf neuen User / Server umziehen / Uploads auf Storage auslagern ==

Meistens muss dafür keine weitere Änderung vorgenommen werden. Manchmal haben vorherige Anbieter einen alternativen Upload Pfad gesetzt. Das zeigt sich dadurch das man angeblich keine Schreibberechtigungen hätte beim Hochladen von z.B. Bildern.

Eine Möglichkeit was dort kaputt sein könnte ist, das die Option `upload_path` noch auf einen alten Pfad vom alten Anbieter gesetzt wurde. Diese Option ist auch zu gebrauchen wenn der häufiger doch mal recht schnell wachsende Uploads Ordner auf den Storage und nicht auf die SSD ausgelagert werden soll.

In der wp_options DB-Tabelle muss entsprechend die Variable `upload_path` angepasst werden. z.B. für den User xyz00-wordpress zu /home/storage/xyz00/users/wordpress/uploads

Generell lohnt es sich die wp_options Tabelle noch mal auf den Alten Pfad zu untersuchen und ggf. anzupassen, das geht z.B. so:

<syntaxhighlight lang=sql>
SELECT * FROM wp_options WHERE option_value LIKE "%/old/path/%"
</syntaxhighlight>

== Objekt Cache einrichten ==

Falls bei dem Bericht über den Zustand der Webseite dieser Eintrag erscheint: "Du solltest einen persistenten Objekt-Cache verwenden", sollte [[Redis#Redis_installieren|Redis installiert]] werden. Es reicht, wenn Redis auf einem Unix-Socket läuft, es muss nicht auf einem Port laufen.

In der wp-config.php sollte dann (relativ weit oben) eingetragen werden:

<syntaxhighlight lang="php">
define('WP_REDIS_SCHEME', 'unix');
define('WP_REDIS_PATH', '/home/pacs/xyz00/users/service/redis/var/redis-server.sock');
define('WP_REDIS_PASSWORD', 'topsecret');
</syntaxhighlight>

Dann kann z.B. das Plugin "Redis Object Cache" von Till Küss installiert werden: https://de.wordpress.org/plugins/redis-cache/

Danach lässt sich der Object Cache unter "Einstellungen / Redis" aktivieren.

== Seiten Cache einrichten ==

Falls bei dem Bericht über den Zustand der Webseite dieser Eintrag erscheint: "Seiten-Cache wurde nicht erkannt, ...", kann das Plugin WP Super Cache von Automattic installiert werden: https://wordpress.org/plugins/wp-super-cache/

Der Cache muss dann in den Einstellungen des Plugins aktiviert werden.

= Links =

*[https://wordpress.org/ Offizielle Webseite von Wordpress]
*[https://wp-cli.org/de/ WP-CLI ist das Kommandozeilen-Werkzeug für WordPress]
*[https://github.com/tpokorra/Hostsharing-Ansible-Wordpress Ansible Playbook für Hostsharing]

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]
[[Kategorie:Software]]
[[Kategorie:Blog]]
[[Kategorie:CMS]]

Wordpress

2026-08-27T04:09:58Z

Tim00: /* Uraltes Wordpress aktualisieren */

= Wordpress in 5 Minuten =

Installiert wird Wordpress hier unter der Domain https://blog.example.org.

== Vorbereitungen ==

In ''hsadmin'', zum Beispiel mit ''hsscript'':

''hsadmin''-Shell starten mit:
<syntaxhighlight lang=shell>
hsscript -u xyz00 -i
Password: ********
</syntaxhighlight>
Dann nacheinander anlegen:

* Linux User als Domain-Administrator
* Subdomain ''blog.example.org''
* MySQL-User
* MySQL Datenbank
<syntaxhighlight lang=shell>
xyz00@hsadmin> user.add({set:{name:'xyz00-blog',password:'geheim',shell:'/bin/bash',comment:'Wordpress Blog'}})
xyz00@hsadmin> domain.add({set:{name:'blog.example.org',user:'xyz00-blog'}})
xyz00@hsadmin> mysqluser.add({set:{name:'xyz00_wpuser',password:'geheim'}})
xyz00@hsadmin> mysqldb.add({set:{name:'xyz00_wpdb',owner:'xyz00_wpuser'}})
</syntaxhighlight>
== Wordpress installieren ==

Anmelden als Linux-User ''xyz00-blog'':

ssh -l xyz00-blog xyz00.hostsharing.net

''htdocs-ssl'' Verzeichnis vorbereiten

<syntaxhighlight lang=shell>
cd doms/blog.example.org
rm -rf subs/www subs-ssl/www
cd htdocs-ssl
rm .htaccess
</syntaxhighlight>

Wordpress downloaden & entpacken z.b. im htdocs-ssl Verzeichnis

<syntaxhighlight lang=shell>
wget -O - https://wordpress.org/latest.tar.gz |tar -xz --strip 1
</syntaxhighlight>

== Wordpress konfigurieren ==

Im Browser auf die Seite
http://blog.example.org gehen und den Anweisungen folgen.

= Verschiedene Hinweise und Anleitungen =
== wp-cli installieren ==

wp-cli ist das Kommandozeilen-Werkzeug für WordPress: https://wp-cli.org/de/

Es kann so installiert werden:

<syntaxhighlight lang=shell>
mkdir ~/bin
cd ~/bin
wget https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod a+x wp-cli.phar
</syntaxhighlight>

== Uraltes Wordpress aktualisieren ==

Manche Wordpress Installationen sind so alt, dass wp-login nicht mehr funktioniert.

Mit wp-cli kann Wordpress auf die aktuelle Version aktualisiert werden:

<syntaxhighlight lang=shell>
cd ~/wordpress # oder ~/doms/meinedomain.de/subs-ssl/www/ oder wo sonst Wordpress installiert ist
~/bin/wp-cli.phar core update
</syntaxhighlight>

Falls nur eine Minor Version installiert werden soll:

<syntaxhighlight lang=shell>
cd ~/wordpress
~/bin/wp-cli.phar core update --minor
</syntaxhighlight>

== Umgang mit einem gehackten Wordpress ==

Falls die Wordpress Instanz gehackt wurde, gibt es 2 Möglichkeiten:

* Es kann die Webseite inkl. Dateien und Datenbank auf den Stand aus dem Backup vor dem Angriff zurückgesetzt werden, und muss dann umgehend aktualisiert werden. Bei diesem Vorgehen gehen die seitdem erfassten Beiträge verloren. Leider liegt der Zeitpunkt des Angriffs manchmal schon länger zurück.
* Ansonsten müssen die veränderten Dateien identifiziert und gelöscht werden.

Das Identifizieren der veränderten Dateien kann mit folgenden Mitteln geschehen:

<syntaxhighlight lang=shell>
cd ~/wordpress
~/bin/wp-cli.phar core verify-checksums --include-root --exclude=liesmich.html,readme.html
~/bin/wp-cli.phar plugin --skip-themes --skip-plugins verify-checksums --all
</syntaxhighlight>

in der wp-config.php sollte keine verdächtige Datei eingebunden werden:

<syntaxhighlight lang=shell>
grep include wp-config.php
</syntaxhighlight>

Zuletzt geänderte Dateien finden, im Beispiel der letzten 3 Tage:

<syntaxhighlight lang=shell>
find -ctime -3
</syntaxhighlight>

Verdächtige Dateien im uploads und cache Verzeichnis finden:

<syntaxhighlight lang=shell>
find wp-content/uploads wp-content/cache -type f \
$ -name '*.php' -o -name '*.phtml' -o -name '*.phar' -o -name '*.ico' $ -ls
</syntaxhighlight>

Verdächtige Dateien finden, die Schadcode speziell kodiert haben:

<syntaxhighlight lang=shell>
grep -rl "eval(base64_decode\|eval(gzinflate\|eval(str_rot13\|eval(htmlspecialchars_decode" . --include="*.php" 2>/dev/null
</syntaxhighlight>

Verdächtige Dateien finden, die versuchen, einen Benutzer mit administrator Rechten anzulegen:

<syntaxhighlight lang=shell>
grep -r '\\"administrator\\"' wp-content/languages/plugins/
</syntaxhighlight>

In der Datenbank sollten die Benutzer mit administrator Rechten kontrolliert werden:

<syntaxhighlight lang=sql>
SELECT m.meta_key, m.meta_value, u.id, u.user_login, u.user_email, u.display_name
FROM wp_usermeta AS m join wp_users AS u ON m.user_id = u.id
WHERE meta_value LIKE '%administrator%';
</syntaxhighlight>

== Einen Admin Benutzer hinzufügen ==

Wenn du die Pflege einer WordPress Instanz übernehmen sollst, aber noch keinen Admin Benutzer hast:

<syntaxhighlight lang=shell>

~/bin/wp-cli.phar user create meinuser admin@example.org --role=administrator
</syntaxhighlight>

Entsprechend kann der Benutzer auch wieder gelöscht werden:

<syntaxhighlight lang=shell>
cd ~/wordpress
~/bin/wp-cli.phar user delete meinuser
</syntaxhighlight>

== Bestehendes Wordpress auf neue Domain umziehen ==
Meistens muss nichts weiter geändert werden als die Home und die SITE_URL Option.

Einfach zu ändern geht das indem man sich via phpmyadmin.hostsharing.net in den Datenbank User des Wordpress einloggt und sich die Tabelle wp_options ansieht. Dort müssen die Zeilen mit `siteurl` und `home` an die neuen URLs angepasst werden.

Alternativ kann man das auch über das wp-config.php machen. Meistens gibt es die beiden Einträge noch nicht, einfach an die passende Stelle für die Custom Config neu eintragen:

<syntaxhighlight lang=php>
define('WP_HOME','https://www.new-domain.de/');
define('WP_SITEURL','https://www.new-domain.de/');
</syntaxhighlight>

Generell lohnt es sich die wp_options Tabelle mal noch auf alte Domain Einträge zu untersuchen und ggf zu ersetzen.
Das geht z.B. so:

<syntaxhighlight lang=sql>
SELECT * FROM wp_options WHERE option_value LIKE "%https://old-domain.de%"
</syntaxhighlight>

== Bestehendes Wordpress auf neuen User / Server umziehen / Uploads auf Storage auslagern ==

Meistens muss dafür keine weitere Änderung vorgenommen werden. Manchmal haben vorherige Anbieter einen alternativen Upload Pfad gesetzt. Das zeigt sich dadurch das man angeblich keine Schreibberechtigungen hätte beim Hochladen von z.B. Bildern.

Eine Möglichkeit was dort kaputt sein könnte ist, das die Option `upload_path` noch auf einen alten Pfad vom alten Anbieter gesetzt wurde. Diese Option ist auch zu gebrauchen wenn der häufiger doch mal recht schnell wachsende Uploads Ordner auf den Storage und nicht auf die SSD ausgelagert werden soll.

In der wp_options DB-Tabelle muss entsprechend die Variable `upload_path` angepasst werden. z.B. für den User xyz00-wordpress zu /home/storage/xyz00/users/wordpress/uploads

Generell lohnt es sich die wp_options Tabelle noch mal auf den Alten Pfad zu untersuchen und ggf. anzupassen, das geht z.B. so:

<syntaxhighlight lang=sql>
SELECT * FROM wp_options WHERE option_value LIKE "%/old/path/%"
</syntaxhighlight>

== Objekt Cache einrichten ==

Falls bei dem Bericht über den Zustand der Webseite dieser Eintrag erscheint: "Du solltest einen persistenten Objekt-Cache verwenden", sollte [[Redis#Redis_installieren|Redis installiert]] werden. Es reicht, wenn Redis auf einem Unix-Socket läuft, es muss nicht auf einem Port laufen.

In der wp-config.php sollte dann (relativ weit oben) eingetragen werden:

<syntaxhighlight lang="php">
define('WP_REDIS_SCHEME', 'unix');
define('WP_REDIS_PATH', '/home/pacs/xyz00/users/service/redis/var/redis-server.sock');
define('WP_REDIS_PASSWORD', 'topsecret');
</syntaxhighlight>

Dann kann z.B. das Plugin "Redis Object Cache" von Till Küss installiert werden: https://de.wordpress.org/plugins/redis-cache/

Danach lässt sich der Object Cache unter "Einstellungen / Redis" aktivieren.

== Seiten Cache einrichten ==

Falls bei dem Bericht über den Zustand der Webseite dieser Eintrag erscheint: "Seiten-Cache wurde nicht erkannt, ...", kann das Plugin WP Super Cache von Automattic installiert werden: https://wordpress.org/plugins/wp-super-cache/

Der Cache muss dann in den Einstellungen des Plugins aktiviert werden.

= Links =

*[https://wordpress.org/ Offizielle Webseite von Wordpress]
*[https://wp-cli.org/de/ WP-CLI ist das Kommandozeilen-Werkzeug für WordPress]
*[https://github.com/tpokorra/Hostsharing-Ansible-Wordpress Ansible Playbook für Hostsharing]

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]
[[Kategorie:Software]]
[[Kategorie:Blog]]
[[Kategorie:CMS]]

Wordpress

2026-08-26T18:08:55Z

Tim00: /* Umgang mit einem gehackten Wordpress */

= Wordpress in 5 Minuten =

Installiert wird Wordpress hier unter der Domain https://blog.example.org.

== Vorbereitungen ==

In ''hsadmin'', zum Beispiel mit ''hsscript'':

''hsadmin''-Shell starten mit:
<syntaxhighlight lang=shell>
hsscript -u xyz00 -i
Password: ********
</syntaxhighlight>
Dann nacheinander anlegen:

* Linux User als Domain-Administrator
* Subdomain ''blog.example.org''
* MySQL-User
* MySQL Datenbank
<syntaxhighlight lang=shell>
xyz00@hsadmin> user.add({set:{name:'xyz00-blog',password:'geheim',shell:'/bin/bash',comment:'Wordpress Blog'}})
xyz00@hsadmin> domain.add({set:{name:'blog.example.org',user:'xyz00-blog'}})
xyz00@hsadmin> mysqluser.add({set:{name:'xyz00_wpuser',password:'geheim'}})
xyz00@hsadmin> mysqldb.add({set:{name:'xyz00_wpdb',owner:'xyz00_wpuser'}})
</syntaxhighlight>
== Wordpress installieren ==

Anmelden als Linux-User ''xyz00-blog'':

ssh -l xyz00-blog xyz00.hostsharing.net

''htdocs-ssl'' Verzeichnis vorbereiten

<syntaxhighlight lang=shell>
cd doms/blog.example.org
rm -rf subs/www subs-ssl/www
cd htdocs-ssl
rm .htaccess
</syntaxhighlight>

Wordpress downloaden & entpacken z.b. im htdocs-ssl Verzeichnis

<syntaxhighlight lang=shell>
wget -O - https://wordpress.org/latest.tar.gz |tar -xz --strip 1
</syntaxhighlight>

== Wordpress konfigurieren ==

Im Browser auf die Seite
http://blog.example.org gehen und den Anweisungen folgen.

= Verschiedene Hinweise und Anleitungen =
== wp-cli installieren ==

wp-cli ist das Kommandozeilen-Werkzeug für WordPress: https://wp-cli.org/de/

Es kann so installiert werden:

<syntaxhighlight lang=shell>
mkdir ~/bin
cd ~/bin
wget https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod a+x wp-cli.phar
</syntaxhighlight>

== Uraltes Wordpress aktualisieren ==

Manche Wordpress Installationen sind so alt, dass wp-login nicht mehr funktioniert.

Mit wp-cli kann Wordpress auf die aktuelle Version aktualisiert werden:

<syntaxhighlight lang=shell>
cd ~/wordpress # oder ~/doms/meinedomain.de/subs-ssl/www/ oder wo sonst Wordpress installiert ist
~/bin/wp-cli.phar core update
</syntaxhighlight>

== Umgang mit einem gehackten Wordpress ==

Falls die Wordpress Instanz gehackt wurde, gibt es 2 Möglichkeiten:

* Es kann die Webseite inkl. Dateien und Datenbank auf den Stand aus dem Backup vor dem Angriff zurückgesetzt werden, und muss dann umgehend aktualisiert werden. Bei diesem Vorgehen gehen die seitdem erfassten Beiträge verloren. Leider liegt der Zeitpunkt des Angriffs manchmal schon länger zurück.
* Ansonsten müssen die veränderten Dateien identifiziert und gelöscht werden.

Das Identifizieren der veränderten Dateien kann mit folgenden Mitteln geschehen:

<syntaxhighlight lang=shell>
cd ~/wordpress
~/bin/wp-cli.phar core verify-checksums --include-root --exclude=liesmich.html,readme.html
~/bin/wp-cli.phar plugin --skip-themes --skip-plugins verify-checksums --all
</syntaxhighlight>

in der wp-config.php sollte keine verdächtige Datei eingebunden werden:

<syntaxhighlight lang=shell>
grep include wp-config.php
</syntaxhighlight>

Zuletzt geänderte Dateien finden, im Beispiel der letzten 3 Tage:

<syntaxhighlight lang=shell>
find -ctime -3
</syntaxhighlight>

Verdächtige Dateien im uploads und cache Verzeichnis finden:

<syntaxhighlight lang=shell>
find wp-content/uploads wp-content/cache -type f \
$ -name '*.php' -o -name '*.phtml' -o -name '*.phar' -o -name '*.ico' $ -ls
</syntaxhighlight>

Verdächtige Dateien finden, die Schadcode speziell kodiert haben:

<syntaxhighlight lang=shell>
grep -rl "eval(base64_decode\|eval(gzinflate\|eval(str_rot13\|eval(htmlspecialchars_decode" . --include="*.php" 2>/dev/null
</syntaxhighlight>

Verdächtige Dateien finden, die versuchen, einen Benutzer mit administrator Rechten anzulegen:

<syntaxhighlight lang=shell>
grep -r '\\"administrator\\"' wp-content/languages/plugins/
</syntaxhighlight>

In der Datenbank sollten die Benutzer mit administrator Rechten kontrolliert werden:

<syntaxhighlight lang=sql>
SELECT m.meta_key, m.meta_value, u.id, u.user_login, u.user_email, u.display_name
FROM wp_usermeta AS m join wp_users AS u ON m.user_id = u.id
WHERE meta_value LIKE '%administrator%';
</syntaxhighlight>

== Einen Admin Benutzer hinzufügen ==

Wenn du die Pflege einer WordPress Instanz übernehmen sollst, aber noch keinen Admin Benutzer hast:

<syntaxhighlight lang=shell>

~/bin/wp-cli.phar user create meinuser admin@example.org --role=administrator
</syntaxhighlight>

Entsprechend kann der Benutzer auch wieder gelöscht werden:

<syntaxhighlight lang=shell>
cd ~/wordpress
~/bin/wp-cli.phar user delete meinuser
</syntaxhighlight>

== Bestehendes Wordpress auf neue Domain umziehen ==
Meistens muss nichts weiter geändert werden als die Home und die SITE_URL Option.

Einfach zu ändern geht das indem man sich via phpmyadmin.hostsharing.net in den Datenbank User des Wordpress einloggt und sich die Tabelle wp_options ansieht. Dort müssen die Zeilen mit `siteurl` und `home` an die neuen URLs angepasst werden.

Alternativ kann man das auch über das wp-config.php machen. Meistens gibt es die beiden Einträge noch nicht, einfach an die passende Stelle für die Custom Config neu eintragen:

<syntaxhighlight lang=php>
define('WP_HOME','https://www.new-domain.de/');
define('WP_SITEURL','https://www.new-domain.de/');
</syntaxhighlight>

Generell lohnt es sich die wp_options Tabelle mal noch auf alte Domain Einträge zu untersuchen und ggf zu ersetzen.
Das geht z.B. so:

<syntaxhighlight lang=sql>
SELECT * FROM wp_options WHERE option_value LIKE "%https://old-domain.de%"
</syntaxhighlight>

== Bestehendes Wordpress auf neuen User / Server umziehen / Uploads auf Storage auslagern ==

Meistens muss dafür keine weitere Änderung vorgenommen werden. Manchmal haben vorherige Anbieter einen alternativen Upload Pfad gesetzt. Das zeigt sich dadurch das man angeblich keine Schreibberechtigungen hätte beim Hochladen von z.B. Bildern.

Eine Möglichkeit was dort kaputt sein könnte ist, das die Option `upload_path` noch auf einen alten Pfad vom alten Anbieter gesetzt wurde. Diese Option ist auch zu gebrauchen wenn der häufiger doch mal recht schnell wachsende Uploads Ordner auf den Storage und nicht auf die SSD ausgelagert werden soll.

In der wp_options DB-Tabelle muss entsprechend die Variable `upload_path` angepasst werden. z.B. für den User xyz00-wordpress zu /home/storage/xyz00/users/wordpress/uploads

Generell lohnt es sich die wp_options Tabelle noch mal auf den Alten Pfad zu untersuchen und ggf. anzupassen, das geht z.B. so:

<syntaxhighlight lang=sql>
SELECT * FROM wp_options WHERE option_value LIKE "%/old/path/%"
</syntaxhighlight>

== Objekt Cache einrichten ==

Falls bei dem Bericht über den Zustand der Webseite dieser Eintrag erscheint: "Du solltest einen persistenten Objekt-Cache verwenden", sollte [[Redis#Redis_installieren|Redis installiert]] werden. Es reicht, wenn Redis auf einem Unix-Socket läuft, es muss nicht auf einem Port laufen.

In der wp-config.php sollte dann (relativ weit oben) eingetragen werden:

<syntaxhighlight lang="php">
define('WP_REDIS_SCHEME', 'unix');
define('WP_REDIS_PATH', '/home/pacs/xyz00/users/service/redis/var/redis-server.sock');
define('WP_REDIS_PASSWORD', 'topsecret');
</syntaxhighlight>

Dann kann z.B. das Plugin "Redis Object Cache" von Till Küss installiert werden: https://de.wordpress.org/plugins/redis-cache/

Danach lässt sich der Object Cache unter "Einstellungen / Redis" aktivieren.

== Seiten Cache einrichten ==

Falls bei dem Bericht über den Zustand der Webseite dieser Eintrag erscheint: "Seiten-Cache wurde nicht erkannt, ...", kann das Plugin WP Super Cache von Automattic installiert werden: https://wordpress.org/plugins/wp-super-cache/

Der Cache muss dann in den Einstellungen des Plugins aktiviert werden.

= Links =

*[https://wordpress.org/ Offizielle Webseite von Wordpress]
*[https://wp-cli.org/de/ WP-CLI ist das Kommandozeilen-Werkzeug für WordPress]
*[https://github.com/tpokorra/Hostsharing-Ansible-Wordpress Ansible Playbook für Hostsharing]

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]
[[Kategorie:Software]]
[[Kategorie:Blog]]
[[Kategorie:CMS]]

ListMonk installieren

2026-08-21T10:06:48Z

Tim00: /* Installation mit Ansible Skript */

== ListMonk ==
ListMonk [https://listmonk.app/] ist ein Newsletter-Manager zum Selbsthosten, und steht unter der Open Source Lizenz AGPLv3.

Monk hat in diesem Fall nichts mit einem Mönch zu tun, sondern ist eine versteckte Anspielung auf Monkey, da ListMonk eine Alternative zu MailChimp (Chimpanse) ist.

'''Achtung:''' Listmonk wirbt damit, [https://github.com/knadh/listmonk/blob/master/README.md Newsletter- und Mailinglisten-Manager] zu sein. Laut [https://github.com/knadh/listmonk/issues/1355 Fehlerbericht] ist das Tool aber lediglich für Einweg-Kommunikation (Newsletter) vorgesehen.

== Zur Technik ==
ListMonk ist in Go geschrieben, und wird als ein einziges Binary (Programm) installiert. Man muss im Shared Webspace bei Hostsharing einen Service dazu buchen, oder man setzt es auf einem Managed Server von Hostsharing ein.

Im Hintergrund wird PostgreSQL als Datenbank benutzt.

ListMonk bietet Anmeldungen per Double-Opt-In, und es gibt auch eine API für die Integration mit CRM/ERP Systemen (https://listmonk.app/docs/apis/apis/).

== Zur Installation ==
Die Installation ist recht einfach: https://listmonk.app/docs/installation/

* Das Programm beispielsweise [https://github.com/knadh/listmonk/releases auf Github herunterladen] und entpacken
* Vorher den Hostsharing Service um eine freie Port Nummer fragen.
* Eine Datenbank anlegen
* Mit [[systemd]] wird das Programm als Dienst gestartet. Hierzu wird das Verzeichnis <code>~/.config/systemd/user/</code> erstellt und eine .service Datei angelegt:

<syntaxhighlight lang="ini" line>
[Unit]
Description=Listmonk

[Service]
Type=simple
Restart=on-abort
WorkingDirectory=/home/pacs/xyz00/users/newsletter
# --config mit vollständigem Pfad zum Configfile falls nicht im WorkingDirectory
ExecStart=/home/pacs/xyz00/users/newsletter/bin/listmonk

[Install]
WantedBy=default.target
</syntaxhighlight>

* Start und aktivieren von Autostart mittels <code>systemctl enable --now --user listmonk</code>
* Beispiel Webserver--Konfiguration unter <code>doms/meine-domain/htdocs-ssl/.htaccess</code>

<syntaxhighlight lang="apache" line>
DirectoryIndex disabled
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RequestHeader set X-Forwarded-Proto "https"
# Port entsprechend der config.toml nach Absprache mit Service s.o.
RewriteRule ^(.*) http://127.0.0.1:9000/$1 [proxy,last]
</syntaxhighlight>

=== Installation mit Ansible Skript ===
Es gibt ein Ansible Skript für Hostsharing [https://codeberg.org/tpokorra/hs.ansible.app.listmonk], das die Installation automatisiert vornimmt, und schon den SMTP und POP Zugang konfiguriert.

Dort kann man sicherlich auch Feinheiten der Installation abschauen, wenn man ListMonk manuell installieren will.

== Zur Bedienung ==

Hier ist ein Bildschirmfoto zur Einrichtung von SMTP für den Versand der E-Mails:

[[Datei:ListMonk SMTPSetup.png]]

Hier ist ein Bildschirmfoto zur Generierung des Formulars zur Anmeldung für einen Newsletter:

[[Datei:ListMonk SubscriptionForm.png]]

== Links ==

* https://listmonk.app/ Projektseite
* https://github.com/knadh/listmonk ListMonk auf Github
* https://codeberg.org/tpokorra/hs.ansible.app.listmonk Ansible Rolle für Hostsharing

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]
[[Kategorie:Software]]
[[Kategorie:Mailinglisten]]
[[Kategorie:Newsletterversand]]
[[Kategorie:E-Mail]]

Wordpress

2026-08-20T10:46:09Z

Tim00: /* Gehackte Dateien identifizieren */

= Wordpress in 5 Minuten =

Installiert wird Wordpress hier unter der Domain https://blog.example.org.

== Vorbereitungen ==

In ''hsadmin'', zum Beispiel mit ''hsscript'':

''hsadmin''-Shell starten mit:
<syntaxhighlight lang=shell>
hsscript -u xyz00 -i
Password: ********
</syntaxhighlight>
Dann nacheinander anlegen:

* Linux User als Domain-Administrator
* Subdomain ''blog.example.org''
* MySQL-User
* MySQL Datenbank
<syntaxhighlight lang=shell>
xyz00@hsadmin> user.add({set:{name:'xyz00-blog',password:'geheim',shell:'/bin/bash',comment:'Wordpress Blog'}})
xyz00@hsadmin> domain.add({set:{name:'blog.example.org',user:'xyz00-blog'}})
xyz00@hsadmin> mysqluser.add({set:{name:'xyz00_wpuser',password:'geheim'}})
xyz00@hsadmin> mysqldb.add({set:{name:'xyz00_wpdb',owner:'xyz00_wpuser'}})
</syntaxhighlight>
== Wordpress installieren ==

Anmelden als Linux-User ''xyz00-blog'':

ssh -l xyz00-blog xyz00.hostsharing.net

''htdocs-ssl'' Verzeichnis vorbereiten

<syntaxhighlight lang=shell>
cd doms/blog.example.org
rm -rf subs/www subs-ssl/www
cd htdocs-ssl
rm .htaccess
</syntaxhighlight>

Wordpress downloaden & entpacken z.b. im htdocs-ssl Verzeichnis

<syntaxhighlight lang=shell>
wget -O - https://wordpress.org/latest.tar.gz |tar -xz --strip 1
</syntaxhighlight>

== Wordpress konfigurieren ==

Im Browser auf die Seite
http://blog.example.org gehen und den Anweisungen folgen.

= Verschiedene Hinweise und Anleitungen =
== wp-cli installieren ==

wp-cli ist das Kommandozeilen-Werkzeug für WordPress: https://wp-cli.org/de/

Es kann so installiert werden:

<syntaxhighlight lang=shell>
mkdir ~/bin
cd ~/bin
wget https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod a+x wp-cli.phar
</syntaxhighlight>

== Uraltes Wordpress aktualisieren ==

Manche Wordpress Installationen sind so alt, dass wp-login nicht mehr funktioniert.

Mit wp-cli kann Wordpress auf die aktuelle Version aktualisiert werden:

<syntaxhighlight lang=shell>
cd ~/wordpress # oder ~/doms/meinedomain.de/subs-ssl/www/ oder wo sonst Wordpress installiert ist
~/bin/wp-cli.phar core update
</syntaxhighlight>

== Umgang mit einem gehackten Wordpress ==

Falls die Wordpress Instanz gehackt wurde, gibt es 2 Möglichkeiten:

* Es kann die Webseite inkl. Dateien und Datenbank auf den Stand aus dem Backup vor dem Angriff zurückgesetzt werden, und muss dann umgehend aktualisiert werden. Bei diesem Vorgehen gehen die seitdem erfassten Beiträge verloren. Leider liegt der Zeitpunkt des Angriffs manchmal schon länger zurück.
* Ansonsten müssen die veränderten Dateien identifiziert und gelöscht werden.

Das Identifizieren der veränderten Dateien kann mit folgenden Mitteln geschehen:

<syntaxhighlight lang=shell>
cd ~/wordpress
~/bin/wp-cli.phar core verify-checksums
~/bin/wp-cli.phar plugin --skip-themes --skip-plugins verify-checksums --all
</syntaxhighlight>

in der wp-config.php sollte keine verdächtige Datei eingebunden werden:

<syntaxhighlight lang=shell>
grep include wp-config.php
</syntaxhighlight>

Zuletzt geänderte Dateien finden, im Beispiel der letzten 3 Tage:

<syntaxhighlight lang=shell>
find -ctime -3
</syntaxhighlight>

Verdächtige Dateien im uploads und cache Verzeichnis finden:

<syntaxhighlight lang=shell>
find wp-content/uploads wp-content/cache -type f \
$ -name '*.php' -o -name '*.phtml' -o -name '*.phar' -o -name '*.ico' $ -ls
</syntaxhighlight>

Verdächtige Dateien finden, die Schadcode speziell kodiert haben:

<syntaxhighlight lang=shell>
grep -rl "eval(base64_decode\|eval(gzinflate\|eval(str_rot13\|eval(htmlspecialchars_decode" . --include="*.php" 2>/dev/null
</syntaxhighlight>

Verdächtige Dateien finden, die versuchen, einen Benutzer mit administrator Rechten anzulegen:

<syntaxhighlight lang=shell>
grep -r '\\"administrator\\"' wp-content/languages/plugins/
</syntaxhighlight>

In der Datenbank sollten die Benutzer mit administrator Rechten kontrolliert werden:

<syntaxhighlight lang=sql>
SELECT m.meta_key, m.meta_value, u.id, u.user_login, u.user_email, u.display_name
FROM wp_usermeta AS m join wp_users AS u ON m.user_id = u.id
WHERE meta_value LIKE '%administrator%';
</syntaxhighlight>

== Einen Admin Benutzer hinzufügen ==

Wenn du die Pflege einer WordPress Instanz übernehmen sollst, aber noch keinen Admin Benutzer hast:

<syntaxhighlight lang=shell>

~/bin/wp-cli.phar user create meinuser admin@example.org --role=administrator
</syntaxhighlight>

Entsprechend kann der Benutzer auch wieder gelöscht werden:

<syntaxhighlight lang=shell>
cd ~/wordpress
~/bin/wp-cli.phar user delete meinuser
</syntaxhighlight>

== Bestehendes Wordpress auf neue Domain umziehen ==
Meistens muss nichts weiter geändert werden als die Home und die SITE_URL Option.

Einfach zu ändern geht das indem man sich via phpmyadmin.hostsharing.net in den Datenbank User des Wordpress einloggt und sich die Tabelle wp_options ansieht. Dort müssen die Zeilen mit `siteurl` und `home` an die neuen URLs angepasst werden.

Alternativ kann man das auch über das wp-config.php machen. Meistens gibt es die beiden Einträge noch nicht, einfach an die passende Stelle für die Custom Config neu eintragen:

<syntaxhighlight lang=php>
define('WP_HOME','https://www.new-domain.de/');
define('WP_SITEURL','https://www.new-domain.de/');
</syntaxhighlight>

Generell lohnt es sich die wp_options Tabelle mal noch auf alte Domain Einträge zu untersuchen und ggf zu ersetzen.
Das geht z.B. so:

<syntaxhighlight lang=sql>
SELECT * FROM wp_options WHERE option_value LIKE "%https://old-domain.de%"
</syntaxhighlight>

== Bestehendes Wordpress auf neuen User / Server umziehen / Uploads auf Storage auslagern ==

Meistens muss dafür keine weitere Änderung vorgenommen werden. Manchmal haben vorherige Anbieter einen alternativen Upload Pfad gesetzt. Das zeigt sich dadurch das man angeblich keine Schreibberechtigungen hätte beim Hochladen von z.B. Bildern.

Eine Möglichkeit was dort kaputt sein könnte ist, das die Option `upload_path` noch auf einen alten Pfad vom alten Anbieter gesetzt wurde. Diese Option ist auch zu gebrauchen wenn der häufiger doch mal recht schnell wachsende Uploads Ordner auf den Storage und nicht auf die SSD ausgelagert werden soll.

In der wp_options DB-Tabelle muss entsprechend die Variable `upload_path` angepasst werden. z.B. für den User xyz00-wordpress zu /home/storage/xyz00/users/wordpress/uploads

Generell lohnt es sich die wp_options Tabelle noch mal auf den Alten Pfad zu untersuchen und ggf. anzupassen, das geht z.B. so:

<syntaxhighlight lang=sql>
SELECT * FROM wp_options WHERE option_value LIKE "%/old/path/%"
</syntaxhighlight>

== Objekt Cache einrichten ==

Falls bei dem Bericht über den Zustand der Webseite dieser Eintrag erscheint: "Du solltest einen persistenten Objekt-Cache verwenden", sollte [[Redis#Redis_installieren|Redis installiert]] werden. Es reicht, wenn Redis auf einem Unix-Socket läuft, es muss nicht auf einem Port laufen.

In der wp-config.php sollte dann (relativ weit oben) eingetragen werden:

<syntaxhighlight lang="php">
define('WP_REDIS_SCHEME', 'unix');
define('WP_REDIS_PATH', '/home/pacs/xyz00/users/service/redis/var/redis-server.sock');
define('WP_REDIS_PASSWORD', 'topsecret');
</syntaxhighlight>

Dann kann z.B. das Plugin "Redis Object Cache" von Till Küss installiert werden: https://de.wordpress.org/plugins/redis-cache/

Danach lässt sich der Object Cache unter "Einstellungen / Redis" aktivieren.

== Seiten Cache einrichten ==

Falls bei dem Bericht über den Zustand der Webseite dieser Eintrag erscheint: "Seiten-Cache wurde nicht erkannt, ...", kann das Plugin WP Super Cache von Automattic installiert werden: https://wordpress.org/plugins/wp-super-cache/

Der Cache muss dann in den Einstellungen des Plugins aktiviert werden.

= Links =

*[https://wordpress.org/ Offizielle Webseite von Wordpress]
*[https://wp-cli.org/de/ WP-CLI ist das Kommandozeilen-Werkzeug für WordPress]
*[https://github.com/tpokorra/Hostsharing-Ansible-Wordpress Ansible Playbook für Hostsharing]

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]
[[Kategorie:Software]]
[[Kategorie:Blog]]
[[Kategorie:CMS]]

Wordpress

2026-08-20T10:45:31Z

Tim00: /* Gehackte Dateien identifizieren */

= Wordpress in 5 Minuten =

Installiert wird Wordpress hier unter der Domain https://blog.example.org.

== Vorbereitungen ==

In ''hsadmin'', zum Beispiel mit ''hsscript'':

''hsadmin''-Shell starten mit:
<syntaxhighlight lang=shell>
hsscript -u xyz00 -i
Password: ********
</syntaxhighlight>
Dann nacheinander anlegen:

* Linux User als Domain-Administrator
* Subdomain ''blog.example.org''
* MySQL-User
* MySQL Datenbank
<syntaxhighlight lang=shell>
xyz00@hsadmin> user.add({set:{name:'xyz00-blog',password:'geheim',shell:'/bin/bash',comment:'Wordpress Blog'}})
xyz00@hsadmin> domain.add({set:{name:'blog.example.org',user:'xyz00-blog'}})
xyz00@hsadmin> mysqluser.add({set:{name:'xyz00_wpuser',password:'geheim'}})
xyz00@hsadmin> mysqldb.add({set:{name:'xyz00_wpdb',owner:'xyz00_wpuser'}})
</syntaxhighlight>
== Wordpress installieren ==

Anmelden als Linux-User ''xyz00-blog'':

ssh -l xyz00-blog xyz00.hostsharing.net

''htdocs-ssl'' Verzeichnis vorbereiten

<syntaxhighlight lang=shell>
cd doms/blog.example.org
rm -rf subs/www subs-ssl/www
cd htdocs-ssl
rm .htaccess
</syntaxhighlight>

Wordpress downloaden & entpacken z.b. im htdocs-ssl Verzeichnis

<syntaxhighlight lang=shell>
wget -O - https://wordpress.org/latest.tar.gz |tar -xz --strip 1
</syntaxhighlight>

== Wordpress konfigurieren ==

Im Browser auf die Seite
http://blog.example.org gehen und den Anweisungen folgen.

= Verschiedene Hinweise und Anleitungen =
== wp-cli installieren ==

wp-cli ist das Kommandozeilen-Werkzeug für WordPress: https://wp-cli.org/de/

Es kann so installiert werden:

<syntaxhighlight lang=shell>
mkdir ~/bin
cd ~/bin
wget https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod a+x wp-cli.phar
</syntaxhighlight>

== Uraltes Wordpress aktualisieren ==

Manche Wordpress Installationen sind so alt, dass wp-login nicht mehr funktioniert.

Mit wp-cli kann Wordpress auf die aktuelle Version aktualisiert werden:

<syntaxhighlight lang=shell>
cd ~/wordpress # oder ~/doms/meinedomain.de/subs-ssl/www/ oder wo sonst Wordpress installiert ist
~/bin/wp-cli.phar core update
</syntaxhighlight>

== Gehackte Dateien identifizieren ==

Falls die Wordpress Instanz gehackt wurde, gibt es 2 Möglichkeiten:

* Es kann die Webseite inkl. Dateien und Datenbank auf den Stand aus dem Backup vor dem Angriff zurückgesetzt werden, und muss dann umgehend aktualisiert werden. Bei diesem Vorgehen gehen die seitdem erfassten Beiträge verloren. Leider liegt der Zeitpunkt des Angriffs manchmal schon länger zurück.
* Ansonsten müssen die veränderten Dateien identifiziert und gelöscht werden.

Das Identifizieren der veränderten Dateien kann mit folgenden Mitteln geschehen:

<syntaxhighlight lang=shell>
cd ~/wordpress
~/bin/wp-cli.phar core verify-checksums
~/bin/wp-cli.phar plugin --skip-themes --skip-plugins verify-checksums --all
</syntaxhighlight>

in der wp-config.php sollte keine verdächtige Datei eingebunden werden:

<syntaxhighlight lang=shell>
grep include wp-config.php
</syntaxhighlight>

Zuletzt geänderte Dateien finden, im Beispiel der letzten 3 Tage:

<syntaxhighlight lang=shell>
find -ctime -3
</syntaxhighlight>

Verdächtige Dateien im uploads und cache Verzeichnis finden:

<syntaxhighlight lang=shell>
find wp-content/uploads wp-content/cache -type f \
$ -name '*.php' -o -name '*.phtml' -o -name '*.phar' -o -name '*.ico' $ -ls
</syntaxhighlight>

Verdächtige Dateien finden, die Schadcode speziell kodiert haben:

<syntaxhighlight lang=shell>
grep -rl "eval(base64_decode\|eval(gzinflate\|eval(str_rot13\|eval(htmlspecialchars_decode" . --include="*.php" 2>/dev/null
</syntaxhighlight>

Verdächtige Dateien finden, die versuchen, einen Benutzer mit administrator Rechten anzulegen:

<syntaxhighlight lang=shell>
grep -r '\\"administrator\\"' wp-content/languages/plugins/
</syntaxhighlight>

In der Datenbank sollten die Benutzer mit administrator Rechten kontrolliert werden:

<syntaxhighlight lang=sql>
SELECT m.meta_key, m.meta_value, u.id, u.user_login, u.user_email, u.display_name
FROM wp_usermeta AS m join wp_users AS u ON m.user_id = u.id
WHERE meta_value LIKE '%administrator%';
</syntaxhighlight>

== Einen Admin Benutzer hinzufügen ==

Wenn du die Pflege einer WordPress Instanz übernehmen sollst, aber noch keinen Admin Benutzer hast:

<syntaxhighlight lang=shell>

~/bin/wp-cli.phar user create meinuser admin@example.org --role=administrator
</syntaxhighlight>

Entsprechend kann der Benutzer auch wieder gelöscht werden:

<syntaxhighlight lang=shell>
cd ~/wordpress
~/bin/wp-cli.phar user delete meinuser
</syntaxhighlight>

== Bestehendes Wordpress auf neue Domain umziehen ==
Meistens muss nichts weiter geändert werden als die Home und die SITE_URL Option.

Einfach zu ändern geht das indem man sich via phpmyadmin.hostsharing.net in den Datenbank User des Wordpress einloggt und sich die Tabelle wp_options ansieht. Dort müssen die Zeilen mit `siteurl` und `home` an die neuen URLs angepasst werden.

Alternativ kann man das auch über das wp-config.php machen. Meistens gibt es die beiden Einträge noch nicht, einfach an die passende Stelle für die Custom Config neu eintragen:

<syntaxhighlight lang=php>
define('WP_HOME','https://www.new-domain.de/');
define('WP_SITEURL','https://www.new-domain.de/');
</syntaxhighlight>

Generell lohnt es sich die wp_options Tabelle mal noch auf alte Domain Einträge zu untersuchen und ggf zu ersetzen.
Das geht z.B. so:

<syntaxhighlight lang=sql>
SELECT * FROM wp_options WHERE option_value LIKE "%https://old-domain.de%"
</syntaxhighlight>

== Bestehendes Wordpress auf neuen User / Server umziehen / Uploads auf Storage auslagern ==

Meistens muss dafür keine weitere Änderung vorgenommen werden. Manchmal haben vorherige Anbieter einen alternativen Upload Pfad gesetzt. Das zeigt sich dadurch das man angeblich keine Schreibberechtigungen hätte beim Hochladen von z.B. Bildern.

Eine Möglichkeit was dort kaputt sein könnte ist, das die Option `upload_path` noch auf einen alten Pfad vom alten Anbieter gesetzt wurde. Diese Option ist auch zu gebrauchen wenn der häufiger doch mal recht schnell wachsende Uploads Ordner auf den Storage und nicht auf die SSD ausgelagert werden soll.

In der wp_options DB-Tabelle muss entsprechend die Variable `upload_path` angepasst werden. z.B. für den User xyz00-wordpress zu /home/storage/xyz00/users/wordpress/uploads

Generell lohnt es sich die wp_options Tabelle noch mal auf den Alten Pfad zu untersuchen und ggf. anzupassen, das geht z.B. so:

<syntaxhighlight lang=sql>
SELECT * FROM wp_options WHERE option_value LIKE "%/old/path/%"
</syntaxhighlight>

== Objekt Cache einrichten ==

Falls bei dem Bericht über den Zustand der Webseite dieser Eintrag erscheint: "Du solltest einen persistenten Objekt-Cache verwenden", sollte [[Redis#Redis_installieren|Redis installiert]] werden. Es reicht, wenn Redis auf einem Unix-Socket läuft, es muss nicht auf einem Port laufen.

In der wp-config.php sollte dann (relativ weit oben) eingetragen werden:

<syntaxhighlight lang="php">
define('WP_REDIS_SCHEME', 'unix');
define('WP_REDIS_PATH', '/home/pacs/xyz00/users/service/redis/var/redis-server.sock');
define('WP_REDIS_PASSWORD', 'topsecret');
</syntaxhighlight>

Dann kann z.B. das Plugin "Redis Object Cache" von Till Küss installiert werden: https://de.wordpress.org/plugins/redis-cache/

Danach lässt sich der Object Cache unter "Einstellungen / Redis" aktivieren.

== Seiten Cache einrichten ==

Falls bei dem Bericht über den Zustand der Webseite dieser Eintrag erscheint: "Seiten-Cache wurde nicht erkannt, ...", kann das Plugin WP Super Cache von Automattic installiert werden: https://wordpress.org/plugins/wp-super-cache/

Der Cache muss dann in den Einstellungen des Plugins aktiviert werden.

= Links =

*[https://wordpress.org/ Offizielle Webseite von Wordpress]
*[https://wp-cli.org/de/ WP-CLI ist das Kommandozeilen-Werkzeug für WordPress]
*[https://github.com/tpokorra/Hostsharing-Ansible-Wordpress Ansible Playbook für Hostsharing]

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]
[[Kategorie:Software]]
[[Kategorie:Blog]]
[[Kategorie:CMS]]

Wordpress

2026-08-20T08:01:11Z

Tim00: /* Gehackte Dateien identifizieren */

= Wordpress in 5 Minuten =

Installiert wird Wordpress hier unter der Domain https://blog.example.org.

== Vorbereitungen ==

In ''hsadmin'', zum Beispiel mit ''hsscript'':

''hsadmin''-Shell starten mit:
<syntaxhighlight lang=shell>
hsscript -u xyz00 -i
Password: ********
</syntaxhighlight>
Dann nacheinander anlegen:

* Linux User als Domain-Administrator
* Subdomain ''blog.example.org''
* MySQL-User
* MySQL Datenbank
<syntaxhighlight lang=shell>
xyz00@hsadmin> user.add({set:{name:'xyz00-blog',password:'geheim',shell:'/bin/bash',comment:'Wordpress Blog'}})
xyz00@hsadmin> domain.add({set:{name:'blog.example.org',user:'xyz00-blog'}})
xyz00@hsadmin> mysqluser.add({set:{name:'xyz00_wpuser',password:'geheim'}})
xyz00@hsadmin> mysqldb.add({set:{name:'xyz00_wpdb',owner:'xyz00_wpuser'}})
</syntaxhighlight>
== Wordpress installieren ==

Anmelden als Linux-User ''xyz00-blog'':

ssh -l xyz00-blog xyz00.hostsharing.net

''htdocs-ssl'' Verzeichnis vorbereiten

<syntaxhighlight lang=shell>
cd doms/blog.example.org
rm -rf subs/www subs-ssl/www
cd htdocs-ssl
rm .htaccess
</syntaxhighlight>

Wordpress downloaden & entpacken z.b. im htdocs-ssl Verzeichnis

<syntaxhighlight lang=shell>
wget -O - https://wordpress.org/latest.tar.gz |tar -xz --strip 1
</syntaxhighlight>

== Wordpress konfigurieren ==

Im Browser auf die Seite
http://blog.example.org gehen und den Anweisungen folgen.

= Verschiedene Hinweise und Anleitungen =
== wp-cli installieren ==

wp-cli ist das Kommandozeilen-Werkzeug für WordPress: https://wp-cli.org/de/

Es kann so installiert werden:

<syntaxhighlight lang=shell>
mkdir ~/bin
cd ~/bin
wget https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod a+x wp-cli.phar
</syntaxhighlight>

== Uraltes Wordpress aktualisieren ==

Manche Wordpress Installationen sind so alt, dass wp-login nicht mehr funktioniert.

Mit wp-cli kann Wordpress auf die aktuelle Version aktualisiert werden:

<syntaxhighlight lang=shell>
cd ~/wordpress # oder ~/doms/meinedomain.de/subs-ssl/www/ oder wo sonst Wordpress installiert ist
~/bin/wp-cli.phar core update
</syntaxhighlight>

== Gehackte Dateien identifizieren ==

Falls die Wordpress Instanz gehackt wurde, müssen die veränderten Dateien identifiziert und gelöscht werden.

Das geht wieder mit wp-cli.

<syntaxhighlight lang=shell>
cd ~/wordpress
~/bin/wp-cli.phar core verify-checksums
~/bin/wp-cli.phar plugin --skip-themes --skip-plugins verify-checksums --all
</syntaxhighlight>

in der wp-config.php sollte keine verdächtige Datei eingebunden werden:

<syntaxhighlight lang=shell>
grep include wp-config.php
</syntaxhighlight>

Zuletzt geänderte Dateien finden, im Beispiel der letzten 3 Tage:

<syntaxhighlight lang=shell>
find -ctime -3
</syntaxhighlight>

Verdächtige Dateien im uploads und cache Verzeichnis finden:

<syntaxhighlight lang=shell>
find wp-content/uploads wp-content/cache -type f \
$ -name '*.php' -o -name '*.phtml' -o -name '*.phar' -o -name '*.ico' $ -ls
</syntaxhighlight>

Verdächtige Dateien finden, die Schadcode speziell kodiert haben:

<syntaxhighlight lang=shell>
grep -rl "eval(base64_decode\|eval(gzinflate\|eval(str_rot13\|eval(htmlspecialchars_decode" . --include="*.php" 2>/dev/null
</syntaxhighlight>

Verdächtige Dateien finden, die versuchen, einen Benutzer mit administrator Rechten anzulegen:

<syntaxhighlight lang=shell>
grep -r '\\"administrator\\"' wp-content/languages/plugins/
</syntaxhighlight>

In der Datenbank sollten die Benutzer mit administrator Rechten kontrolliert werden:

<syntaxhighlight lang=sql>
SELECT m.meta_key, m.meta_value, u.id, u.user_login, u.user_email, u.display_name
FROM wp_usermeta AS m join wp_users AS u ON m.user_id = u.id
WHERE meta_value LIKE '%administrator%';
</syntaxhighlight>

== Einen Admin Benutzer hinzufügen ==

Wenn du die Pflege einer WordPress Instanz übernehmen sollst, aber noch keinen Admin Benutzer hast:

<syntaxhighlight lang=shell>

~/bin/wp-cli.phar user create meinuser admin@example.org --role=administrator
</syntaxhighlight>

Entsprechend kann der Benutzer auch wieder gelöscht werden:

<syntaxhighlight lang=shell>
cd ~/wordpress
~/bin/wp-cli.phar user delete meinuser
</syntaxhighlight>

== Bestehendes Wordpress auf neue Domain umziehen ==
Meistens muss nichts weiter geändert werden als die Home und die SITE_URL Option.

Einfach zu ändern geht das indem man sich via phpmyadmin.hostsharing.net in den Datenbank User des Wordpress einloggt und sich die Tabelle wp_options ansieht. Dort müssen die Zeilen mit `siteurl` und `home` an die neuen URLs angepasst werden.

Alternativ kann man das auch über das wp-config.php machen. Meistens gibt es die beiden Einträge noch nicht, einfach an die passende Stelle für die Custom Config neu eintragen:

<syntaxhighlight lang=php>
define('WP_HOME','https://www.new-domain.de/');
define('WP_SITEURL','https://www.new-domain.de/');
</syntaxhighlight>

Generell lohnt es sich die wp_options Tabelle mal noch auf alte Domain Einträge zu untersuchen und ggf zu ersetzen.
Das geht z.B. so:

<syntaxhighlight lang=sql>
SELECT * FROM wp_options WHERE option_value LIKE "%https://old-domain.de%"
</syntaxhighlight>

== Bestehendes Wordpress auf neuen User / Server umziehen / Uploads auf Storage auslagern ==

Meistens muss dafür keine weitere Änderung vorgenommen werden. Manchmal haben vorherige Anbieter einen alternativen Upload Pfad gesetzt. Das zeigt sich dadurch das man angeblich keine Schreibberechtigungen hätte beim Hochladen von z.B. Bildern.

Eine Möglichkeit was dort kaputt sein könnte ist, das die Option `upload_path` noch auf einen alten Pfad vom alten Anbieter gesetzt wurde. Diese Option ist auch zu gebrauchen wenn der häufiger doch mal recht schnell wachsende Uploads Ordner auf den Storage und nicht auf die SSD ausgelagert werden soll.

In der wp_options DB-Tabelle muss entsprechend die Variable `upload_path` angepasst werden. z.B. für den User xyz00-wordpress zu /home/storage/xyz00/users/wordpress/uploads

Generell lohnt es sich die wp_options Tabelle noch mal auf den Alten Pfad zu untersuchen und ggf. anzupassen, das geht z.B. so:

<syntaxhighlight lang=sql>
SELECT * FROM wp_options WHERE option_value LIKE "%/old/path/%"
</syntaxhighlight>

== Objekt Cache einrichten ==

Falls bei dem Bericht über den Zustand der Webseite dieser Eintrag erscheint: "Du solltest einen persistenten Objekt-Cache verwenden", sollte [[Redis#Redis_installieren|Redis installiert]] werden. Es reicht, wenn Redis auf einem Unix-Socket läuft, es muss nicht auf einem Port laufen.

In der wp-config.php sollte dann (relativ weit oben) eingetragen werden:

<syntaxhighlight lang="php">
define('WP_REDIS_SCHEME', 'unix');
define('WP_REDIS_PATH', '/home/pacs/xyz00/users/service/redis/var/redis-server.sock');
define('WP_REDIS_PASSWORD', 'topsecret');
</syntaxhighlight>

Dann kann z.B. das Plugin "Redis Object Cache" von Till Küss installiert werden: https://de.wordpress.org/plugins/redis-cache/

Danach lässt sich der Object Cache unter "Einstellungen / Redis" aktivieren.

== Seiten Cache einrichten ==

Falls bei dem Bericht über den Zustand der Webseite dieser Eintrag erscheint: "Seiten-Cache wurde nicht erkannt, ...", kann das Plugin WP Super Cache von Automattic installiert werden: https://wordpress.org/plugins/wp-super-cache/

Der Cache muss dann in den Einstellungen des Plugins aktiviert werden.

= Links =

*[https://wordpress.org/ Offizielle Webseite von Wordpress]
*[https://wp-cli.org/de/ WP-CLI ist das Kommandozeilen-Werkzeug für WordPress]
*[https://github.com/tpokorra/Hostsharing-Ansible-Wordpress Ansible Playbook für Hostsharing]

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]
[[Kategorie:Software]]
[[Kategorie:Blog]]
[[Kategorie:CMS]]

Wordpress

2026-08-20T06:02:18Z

Tim00: /* Gehackte Dateien identifizieren */

= Wordpress in 5 Minuten =

Installiert wird Wordpress hier unter der Domain https://blog.example.org.

== Vorbereitungen ==

In ''hsadmin'', zum Beispiel mit ''hsscript'':

''hsadmin''-Shell starten mit:
<syntaxhighlight lang=shell>
hsscript -u xyz00 -i
Password: ********
</syntaxhighlight>
Dann nacheinander anlegen:

* Linux User als Domain-Administrator
* Subdomain ''blog.example.org''
* MySQL-User
* MySQL Datenbank
<syntaxhighlight lang=shell>
xyz00@hsadmin> user.add({set:{name:'xyz00-blog',password:'geheim',shell:'/bin/bash',comment:'Wordpress Blog'}})
xyz00@hsadmin> domain.add({set:{name:'blog.example.org',user:'xyz00-blog'}})
xyz00@hsadmin> mysqluser.add({set:{name:'xyz00_wpuser',password:'geheim'}})
xyz00@hsadmin> mysqldb.add({set:{name:'xyz00_wpdb',owner:'xyz00_wpuser'}})
</syntaxhighlight>
== Wordpress installieren ==

Anmelden als Linux-User ''xyz00-blog'':

ssh -l xyz00-blog xyz00.hostsharing.net

''htdocs-ssl'' Verzeichnis vorbereiten

<syntaxhighlight lang=shell>
cd doms/blog.example.org
rm -rf subs/www subs-ssl/www
cd htdocs-ssl
rm .htaccess
</syntaxhighlight>

Wordpress downloaden & entpacken z.b. im htdocs-ssl Verzeichnis

<syntaxhighlight lang=shell>
wget -O - https://wordpress.org/latest.tar.gz |tar -xz --strip 1
</syntaxhighlight>

== Wordpress konfigurieren ==

Im Browser auf die Seite
http://blog.example.org gehen und den Anweisungen folgen.

= Verschiedene Hinweise und Anleitungen =
== wp-cli installieren ==

wp-cli ist das Kommandozeilen-Werkzeug für WordPress: https://wp-cli.org/de/

Es kann so installiert werden:

<syntaxhighlight lang=shell>
mkdir ~/bin
cd ~/bin
wget https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod a+x wp-cli.phar
</syntaxhighlight>

== Uraltes Wordpress aktualisieren ==

Manche Wordpress Installationen sind so alt, dass wp-login nicht mehr funktioniert.

Mit wp-cli kann Wordpress auf die aktuelle Version aktualisiert werden:

<syntaxhighlight lang=shell>
cd ~/wordpress # oder ~/doms/meinedomain.de/subs-ssl/www/ oder wo sonst Wordpress installiert ist
~/bin/wp-cli.phar core update
</syntaxhighlight>

== Gehackte Dateien identifizieren ==

Falls die Wordpress Instanz gehackt wurde, müssen die veränderten Dateien identifiziert und gelöscht werden.

Das geht wieder mit wp-cli.

<syntaxhighlight lang=shell>
cd ~/wordpress
~/bin/wp-cli.phar core verify-checksums
~/bin/wp-cli.phar plugin --skip-themes --skip-plugins verify-checksums --all
</syntaxhighlight>

in der wp-config.php sollte keine verdächtige Datei eingebunden werden:

<syntaxhighlight lang=shell>
grep include wp-config.php
</syntaxhighlight>

Zuletzt geänderte Dateien finden, im Beispiel der letzten 3 Tage:

<syntaxhighlight lang=shell>
find -ctime -3
</syntaxhighlight>

Verdächtige Dateien im uploads und cache Verzeichnis finden:

<syntaxhighlight lang=shell>
find wp-content/uploads wp-content/cache -type f \
$ -name '*.php' -o -name '*.phtml' -o -name '*.phar' -o -name '*.ico' $ -ls
</syntaxhighlight>

Verdächtige Dateien finden, die versuchen, einen Benutzer mit administrator Rechten anzulegen:

<syntaxhighlight lang=shell>
grep -r '\\"administrator\\"' wp-content/languages/plugins/
</syntaxhighlight>

In der Datenbank sollten die Benutzer mit administrator Rechten kontrolliert werden:

<syntaxhighlight lang=sql>
SELECT m.meta_key, m.meta_value, u.id, u.user_login, u.user_email, u.display_name
FROM wp_usermeta AS m join wp_users AS u ON m.user_id = u.id
WHERE meta_value LIKE '%administrator%';
</syntaxhighlight>

== Einen Admin Benutzer hinzufügen ==

Wenn du die Pflege einer WordPress Instanz übernehmen sollst, aber noch keinen Admin Benutzer hast:

<syntaxhighlight lang=shell>

~/bin/wp-cli.phar user create meinuser admin@example.org --role=administrator
</syntaxhighlight>

Entsprechend kann der Benutzer auch wieder gelöscht werden:

<syntaxhighlight lang=shell>
cd ~/wordpress
~/bin/wp-cli.phar user delete meinuser
</syntaxhighlight>

== Bestehendes Wordpress auf neue Domain umziehen ==
Meistens muss nichts weiter geändert werden als die Home und die SITE_URL Option.

Einfach zu ändern geht das indem man sich via phpmyadmin.hostsharing.net in den Datenbank User des Wordpress einloggt und sich die Tabelle wp_options ansieht. Dort müssen die Zeilen mit `siteurl` und `home` an die neuen URLs angepasst werden.

Alternativ kann man das auch über das wp-config.php machen. Meistens gibt es die beiden Einträge noch nicht, einfach an die passende Stelle für die Custom Config neu eintragen:

<syntaxhighlight lang=php>
define('WP_HOME','https://www.new-domain.de/');
define('WP_SITEURL','https://www.new-domain.de/');
</syntaxhighlight>

Generell lohnt es sich die wp_options Tabelle mal noch auf alte Domain Einträge zu untersuchen und ggf zu ersetzen.
Das geht z.B. so:

<syntaxhighlight lang=sql>
SELECT * FROM wp_options WHERE option_value LIKE "%https://old-domain.de%"
</syntaxhighlight>

== Bestehendes Wordpress auf neuen User / Server umziehen / Uploads auf Storage auslagern ==

Meistens muss dafür keine weitere Änderung vorgenommen werden. Manchmal haben vorherige Anbieter einen alternativen Upload Pfad gesetzt. Das zeigt sich dadurch das man angeblich keine Schreibberechtigungen hätte beim Hochladen von z.B. Bildern.

Eine Möglichkeit was dort kaputt sein könnte ist, das die Option `upload_path` noch auf einen alten Pfad vom alten Anbieter gesetzt wurde. Diese Option ist auch zu gebrauchen wenn der häufiger doch mal recht schnell wachsende Uploads Ordner auf den Storage und nicht auf die SSD ausgelagert werden soll.

In der wp_options DB-Tabelle muss entsprechend die Variable `upload_path` angepasst werden. z.B. für den User xyz00-wordpress zu /home/storage/xyz00/users/wordpress/uploads

Generell lohnt es sich die wp_options Tabelle noch mal auf den Alten Pfad zu untersuchen und ggf. anzupassen, das geht z.B. so:

<syntaxhighlight lang=sql>
SELECT * FROM wp_options WHERE option_value LIKE "%/old/path/%"
</syntaxhighlight>

== Objekt Cache einrichten ==

Falls bei dem Bericht über den Zustand der Webseite dieser Eintrag erscheint: "Du solltest einen persistenten Objekt-Cache verwenden", sollte [[Redis#Redis_installieren|Redis installiert]] werden. Es reicht, wenn Redis auf einem Unix-Socket läuft, es muss nicht auf einem Port laufen.

In der wp-config.php sollte dann (relativ weit oben) eingetragen werden:

<syntaxhighlight lang="php">
define('WP_REDIS_SCHEME', 'unix');
define('WP_REDIS_PATH', '/home/pacs/xyz00/users/service/redis/var/redis-server.sock');
define('WP_REDIS_PASSWORD', 'topsecret');
</syntaxhighlight>

Dann kann z.B. das Plugin "Redis Object Cache" von Till Küss installiert werden: https://de.wordpress.org/plugins/redis-cache/

Danach lässt sich der Object Cache unter "Einstellungen / Redis" aktivieren.

== Seiten Cache einrichten ==

Falls bei dem Bericht über den Zustand der Webseite dieser Eintrag erscheint: "Seiten-Cache wurde nicht erkannt, ...", kann das Plugin WP Super Cache von Automattic installiert werden: https://wordpress.org/plugins/wp-super-cache/

Der Cache muss dann in den Einstellungen des Plugins aktiviert werden.

= Links =

*[https://wordpress.org/ Offizielle Webseite von Wordpress]
*[https://wp-cli.org/de/ WP-CLI ist das Kommandozeilen-Werkzeug für WordPress]
*[https://github.com/tpokorra/Hostsharing-Ansible-Wordpress Ansible Playbook für Hostsharing]

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]
[[Kategorie:Software]]
[[Kategorie:Blog]]
[[Kategorie:CMS]]

Speicherbelegung

2026-08-19T07:27:30Z

Tim00: /* Unvermutete Speicherbelegung */

== Paketspeicher ==

Der im gesamten Paket zur Verfügung stehende bzw genutzte Speicher kann wie folgt abgefragt werden:

Einloggen als Paketadmin

{{Textkasten|gruen||xyz00@h01:~$ pac-du-quota}}
Es wird der Speicherplatz (NVMe SSD) und der Zusatz-Speicherplatz (HDD) angezeigt.

oder

{{Textkasten|gruen||xyz00@h01:~$ quota -gs}}
(g > wir nutzen Gruppenquota, s > für Ausgabe in MB). Die Felder bedeuten:

{| class="wikitable" style="margin: 0em 0em 0em 2em; font-size:1em;"
|- style="background-color:orange;"
!Feld !! Bedeutung
|- style="background-color:#CAE1FF;"
|blocks || KB belegt
|- style="background-color:#B9D3EE;"
|quota || normales (gebuchtes) Limit in KB; "soft quota"
|- style="background-color:#CAE1FF;"
|limit || maximales (temporär toleriertes) Limit in KB; "hard quota"
|- style="background-color:#B9D3EE;"
|grace || Anzahl der Tage, die man noch über "quota" bleiben darf (ist nur gesetzt, wenn blocks>quota)
|- style="background-color:#CAE1FF;"
|files ||Anzahl der INodes (entspricht nicht immer, aber fast einem File. Lediglich Hardlinks verbrauchen nur einen INode pro "realer" Datei)
|- style="background-color:#B9D3EE;"
|quota ||normales Limit der INode-Anzahl
|- style="background-color:#CAE1FF;"
|limit ||maximales Limit der INode-Anzahl
|- style="background-color:#B9D3EE;"
|grace || Anzahl der Tage, die man noch über "INode-quota" bleiben darf (ist nur gesetzt, wenn quota überschritten ist)
|-
|}

Um zu prüfen, ob ein Paket die Quota bald erreicht oder schon überschritten hat, muss man '''blocks''' mit '''quota''' in Verhältnis setzen. Wenn '''blocks > quota''', beginnt die ''grace period'', während der ein weiterer Anstieg des Speicherverbrauchs noch toleriert wird. In jedem Fall gilt '''blocks < limit''': die "hard quota" kann nicht überschritten werden und liegt z.B. bei 150% der "soft quota".

Der genutzte Speicher nur für den Paketadmin selbst kann mit '''du''' abgefragt werden: Einloggen als Paket-Admin und '''du -h''' eingeben. Der Befehl listet die aktuellen Größen der einzelnen Verzeichnisse auf und am Ende den gesamt belegten Plattenplatz in MB.

{{Textkasten|gruen||'''Achtung:''' Die Auflistung (mit '''du''') erfolgt ohne den Speicherplatz der User, für deren Verzeichnisse der Paketadmin kein Zugriffsrecht hat, ohne Dateien in /tmp/ und ohne Datenbanken!}}

An dieser Stelle unser Danke an die Mitglieder Andreas Loesch und Timotheus Pokorra die das hervorragende Skript 'pac-du-quota' bereit gestellt haben.

== Unvermutete Speicherbelegung ==

Manchmal wunderst du dich, welche Dateien deinen Speicherplatz belegen?

du und pac-du-quota zeigen nur die Dateien im Home Verzeichnis.

Manche Anwendungen legen im /tmp Verzeichnis für deinen Benutzer Dateien an.

Diese Dateien findest du mit diesem Befehl, für deinen aktuellen Benutzer:

<syntaxhighlight lang=shell>
xyz00-meinbenutzer@hxy:~$ find /tmp/user/$UID
xyz00-meinbenutzer@hxy:~$ ls -lat /tmp | grep xyz00
</syntaxhighlight>

Falls eine Datei fntxyzabc heißt, kann so erfahren werden, welcher Prozess die Datei geschrieben hat:

<syntaxhighlight lang=shell>
xyz00-meinbenutzer@hxy:~$ lsof /tmp/fntxyzabc
</syntaxhighlight>

== Warnung bei Erreichen des Quotas ==

=== Warnungen beim Paketspeicher ===

Wenn die Speicherbelegung (Soft- oder Hard-Quota) beim Paketspeicher überschritten wird, bekommen die dafür eingetragenen E-Mail-Adressen (siehe Ansprechpartner, OPERATIONS_ALERT) jeden Morgen eine E-Mail mit einem Warn-Hinweis.

=== Speicherbelegung von einzelnen Benutzern prüfen ===

Diese automatische E-Mail berücksichtigt nicht die Quotas der einzelnen Benutzer/Postfächer.

Dafür kann das folgende Python-Skript genutzt werden: https://codeberg.org/tpokorra/hostsharing-scripts/src/branch/main/check-userquota.py

Es sollte im bin Verzeichnis des Paketnutzers (/home/pacs/xyz00/bin) gespeichert werden.

Es muss mit einem Timer eingerichtet werden:

<syntaxhighlight lang=shell>
xyz00@h00:~$ cat .config/systemd/user/check-userquota.timer
[Unit]
Description=check user quota

[Timer]
OnCalendar=00:55:00
RandomizedDelaySec=3 minutes
Persistent=true

[Install]
WantedBy=timers.target

xyz00@h00:~$ cat .config/systemd/user/check-userquota.service
[Unit]
Description=check user quotas

[Service]
Environment="MAILTO=monitoring@meinedomain.de"
ExecStart=%h/bin/check-userquota.py
</syntaxhighlight>

Aktivieren des Timers mit:

<syntaxhighlight lang=shell>
systemctl --user enable check-userquota.timer --now
</syntaxhighlight>

----
[[Kategorie:Pakete bei HS]]
[[Kategorie:HSDoku]]

Container

2026-08-19T04:39:42Z

Tim00: /* Tunnel zur Managed Datenbank einrichten */

== Übersicht ==

Es gibt die Möglichkeit, einen Container Server mit Docker oder mit Podman zu buchen.

Dies ist eine Managed Umgebung, also ohne Root-Rechte, wo Docker bzw. Podman rootless ausgeführt werden.

Falls vom Installationsskript einer Anwendung Root-Rechte erforderlich sind, kann entweder versucht werden, dies anzupassen, oder es kann ein Cloud Server gebucht werden, wo der Benutzer Root-Rechte hat.

== Erste Schritte ==

Bei der Bestellung des Container Servers sollte direkt der Public SSH Key mitgegeben werden, am besten bereits nach dem Ed25519-Standard, siehe auch [https://www.heise.de/tipps-tricks/SSH-Key-erstellen-so-geht-s-4400280.html].

Der Zugriff erfolgt über den Benutzer tallyman über SSH auf den Container Server.

<syntaxhighlight lang=shell>
ssh tallyman@vm4xxx.hostsharing.net
</syntaxhighlight>

Um einen "Hello World" Docker Container zu starten:

<syntaxhighlight lang=shell>
tallyman@vm4xxx:~$ docker run hello-world
</syntaxhighlight>

Entsprechend sieht der Befehl für Podman aus:

<syntaxhighlight lang=shell>
tallyman@vm4xxx:~$ podman run hello-world
</syntaxhighlight>

=== Hilfreiche Befehle für Docker ===

<syntaxhighlight lang=shell>
# in einem Ordner ausführen, wo eine Datei mit dem Namen docker-compose.yml liegt, um die Umgebung zu bauen und zu starten:
docker compose up --detach

# zeige alle laufenden Container
docker ps -a

# zeige die Logs eines Containers
docker logs mein-container

# wechsle in eine Shell im Container
docker exec -t -i mein-container /bin/sh

# Images aktualisieren
docker compose pull

# Containerumgebung stoppen und löschen
docker compose down
</syntaxhighlight>

=== Hilfreiche Befehle für Podman ===

TODO

== Integration in Hostsharing Managed Platform ==

=== Subdomain einrichten ===

Wir haben bereits die Hauptdomain bei Hostsharing gebucht.

Nun soll unsere Anwendung auf dem Container Server auf einer Subdomain laufen.

Wir benutzen einen Caddy Container, um Letsencrypt bereitszustellen (siehe in den Beispielen unten).

Auf der Managed Umgebung müssen wir das Zonefile anpassen, um die Subdomain per A und AAAA Eintrag auf den Container Server zu verweisen.

Mit dem Befehl <code>dig</code> ermitteln wir die ipv4 und ipv6 Adressen unseres Container Servers:

<syntaxhighlight lang=shell>
dig -t A +short vm4xxx.hostsharing.net
dig -t AAAA +short vm4xxx.hostsharing.net
</syntaxhighlight>

Auf der Managed Umgebung, legen wir ein Zonefile an. Siehe auch die Anleitung im Handbuch: https://www.hostsharing.net/doc/managed-operations-platform/zonefile/

<code>doms/meinedomain.de/etc/pri.meinedomain.de</code>:

<syntaxhighlight lang=text>
{DEFAULT_ZONEFILE}

meinesubdomain IN A 83.223.xx.xxx
meinesubdomain IN AAAA 2a01:xx:xxxx::xxxx:xxxx:0
</syntaxhighlight>

=== Tunnel zur Managed Datenbank einrichten ===

Wir lassen die Anwendung auf dem Container Server laufen. Dort kann natürlich auch die Datenbank laufen, in einem eigenen Container.

Wir haben aber auch Datenbanken in der Managed Umgebung von Hostsharing, mit allen Vorteilen (regelmäßiges Backup, usw.).

Wenn wir eine managed Datenbank aus der Managed Umgebung auf dem Container Server einbinden wollen, sind folgende Schritte notwendig:

* Es muss ein Tunnel eingerichtet werden, damit die Datenbank vom Container Server aus erreichbar ist.

Datei .config/systemd/user/sshtunnel.service:

<syntaxhighlight lang=shell>
[Unit]
Description=SSH Tunnel zu Managed Webspace
After=network.target

[Service]
Environment="LOCAL_ADDR=localhost"
Environment="LOCAL_PORT=5432"
Environment="REMOTE_PORT=5432"
Environment="TARGET=xyz00-myuser@xyz00.hostsharing.net"
ExecStart=/usr/bin/ssh -NT -o ServerAliveInterval=60 -o ExitOnForwardFailure=yes -L ${LOCAL_ADDR}:${LOCAL_PORT}:localhost:${REMOTE_PORT} ${TARGET}

RestartSec=5
Restart=always

[Install]
WantedBy=multi-user.target
</syntaxhighlight>

Den Dienst entsprechend starten:
<syntaxhighlight lang=shell>
systemctl --user enable sshtunnel --now
</syntaxhighlight>

* TODO: Anpassungen an Docker Compose. Beispiel

== Docker fernsteuern ==
Es besteht die Möglichkeit, über SSH den Docker Socket von außen zu erreichen. Damit wird es möglich, über eine IDE wie z.B. Intellij IDEA die Docker Container zu starten und zu stoppen.

Um das auszuprobieren, können diese Befehle ausgeführt werden:

<syntaxhighlight lang="bash">
ssh -nNT -L $(pwd)/docker.sock:/var/run/docker.sock tallyman@vmxxxx.hostsharing.net
export DOCKER_HOST=unix://$(pwd)/docker.sock
docker ps -a
</syntaxhighlight>

Nun sollten die aktuell laufenden Container gelistet werden.

== Beispiel Anwendungen ==
=== Container Umgebung mit Nginx und Certbot ===
TODO siehe https://codeberg.org/tpokorra/hs.compose/src/branch/main/nginx-certbot
=== Container Umgebung mit Caddy und Python Anwendung ===
TODO siehe https://codeberg.org/tpokorra/hs.compose/src/branch/main/caddy-test

=== Nextcloud High Performance Backend mit Caddy ===
* Docker Compose: siehe https://codeberg.org/tpokorra/hs.compose/src/branch/main/nextcloud-high_performance_backend
* Siehe auch dort die [https://codeberg.org/tpokorra/hs.compose/src/branch/main/nextcloud-high_performance_backend#readme README Datei], was für die Einrichtung erforderlich ist.

=== OnlyOffice Documentserver ===
TODO siehe https://codeberg.org/tpokorra/hs.compose/src/branch/main/onlyoffice-document_server

== Backups in Volumes einpflegen ==

Auf Anfrage stellen wir einen read-only Snapshot bereit, der unter anderem Docker-Volumes, Container und Compose-Dateien enthält.

Da Docker nicht direkt mit den User- und Gruppen-IDs des tallyman-Users arbeitet, sondern interne Sub-User- und Sub-Group-IDs verwendet, können diese Daten nicht unmittelbar zurückkopiert werden. Für die Wiederherstellung ist daher ein kurzer Zwischenschritt erforderlich.

Hinweis: selbstverständlich helfen wir auf Anfrage auch dabei, die Dateien wieder in das laufende System zu migrieren.

=== Beispiel: das pgdata Verzeichnis eines PostgreSQL Containers tauschen ===

==== Wo liegt das Volume auf dem Dateisystem? ====

<syntaxhighlight lang=bash>
docker ps -a # wie lautet der Containername?
docker inspect --format '{{ range .Mounts }}{{ if eq .Type "volume" }}{{ .Source }}{{ "\n" }}{{ end }}{{ end }}' postgres-1
</syntaxhighlight>

In unserem Fall sehen wir den Pfad: <code>/home/tallyman/.local/share/docker/volumes/8c73a862eaf1fc3dee55a2f29b6f3d3dd68e3049da58a21a5f73010e7233190c/_data</code>

==== Den betroffenen Container abschalten ====

In diesem Beispiel entscheiden wir uns dafür, die Container vollständig zu stoppen.
Der Grund dafür ist, dass es je nach Image nicht immer eindeutig ist, wie der darin laufende Prozess korrekt gestoppt und wieder gestartet werden sollte.

Alternativ könnten wir das Backup also auch direkt in das Volume kopieren und im bestehenden Container eine Shell öffnen, um die Dateien an die richtige Stelle zu verschieben.

<syntaxhighlight lang=bash>
docker ps -a # wie lautet der Containername?
docker stop app-1
docker stop postgres-1

# oder über die Service-Namen aus der compose.yaml
docker compose stop app
docker compose stop postgres
</syntaxhighlight>

==== In eine temporäre Subshell wechseln ====
Hier nutzen wir eine Abkürzung und lassen Docker einen temporären Container starten, der unseren Ordner als Volume einbindet.
So erhalten wir eine Shell im passenden Userid/Gruppenid-Kontext und können direkt mit den Dateien im Volume arbeiten, ohne den eigentlichen Service-Container starten, oder als root arbeiten zu müssen.

<syntaxhighlight lang=bash>
export VOL=".local/share/docker/volumes"
docker run --rm -it -v "$VOL:/data" bash
</syntaxhighlight>

Wir wechseln nun in das oben definierte Volume. Das Beispiel geht davon aus, dass das bereitgestellte Backupverzeichnis "pgdata2" genannt wurde.

<syntaxhighlight lang=bash>
cd data
mv pgdata pgdata.old
mv pgdata2 pgdata
</syntaxhighlight>

Hinweis: Falls wir zusätzliche Pakete brauchen, nutzt das – auf Alpine basierte – Bash image den Paketmanager `apk`. Beispiel: ncdu installieren:

<syntaxhighlight lang=bash>
~$ apk add ncdu
(1/1) Installing ncdu (1.22-r0)
Executing busybox-1.37.0-r30.trigger
OK: 8726 KiB in 20 packages
</syntaxhighlight>

==== Den Container wieder starten ====

Wir verlassen den Container mittels <code>exit</code> <code>Enter</code> oder über die Tastenkombination <code>STRG+D</code>.

<syntaxhighlight lang=bash>
docker start postgres-1
docker start app-1

# oder über die Service-Namen aus der compose.yaml
docker compose start app
docker compose start postgres
</syntaxhighlight>

=== Beispiel: eine Subshell mit Hilfe eine Containerprozesses starten ===
Für Debugging kann es nützlich sein, direkt mit allen vorinstallierten Tools im Containerserver mit Daten der Volumes zu agieren. Hier sind zwei Wege um eine Subshell ohne extra(!) Container zu starten:

==== Mit Hilfe eines beliebigen laufenden Containers: ====
<syntaxhighlight lang=bash>
docker ps
docker inspect --format '{{.State.Pid}}' app-1
nsenter -U -t 2586740 -- bash
</syntaxhighlight>

==== TODO ====
Funktionierende subshell (mit nötigen Berechtigungen) mittels unshare oder nsenter

Discourse installieren

2026-08-06T09:21:20Z

Tim00: /* Erforderliche Anpassungen */

{{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|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 ==

Es müssen noch Erweiterungen für Postgresql installiert werden:

<syntaxhighlight lang=shell line>
psql --user xyz00_discourseuser -c "CREATE EXTENSION IF NOT EXISTS hstore WITH SCHEMA public;"
psql --user xyz00_discourseuser -c "CREATE EXTENSION IF NOT EXISTS pg_trgm WITH SCHEMA public;"
psql --user xyz00_discourseuser -c "CREATE EXTENSION IF NOT EXISTS unaccent WITH SCHEMA public;"
</syntaxhighlight>

== Konfiguration des Redis Server ==

{{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.}}

<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:

<syntaxhighlight lang=shell line>
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
</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 ==

Als User ''xyz00-discourse'': Installation von Ruby mit ''rbenv'' mit folgenden Befehlen:

Zunächst ''rbenv'' and ''ruby-build'':

<syntaxhighlight lang=shell line>
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
</syntaxhighlight>

starte neue Shell:

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

Überprüfe rbenv-Installation

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

Installiere ruby-build als rbenv-Plugin

<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:

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

== Installation von Discourse selber ==

Weiterhin Als User ''xyz00-discourse'':

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

Die stabile Version auschecken:

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

Ruby Pakete installieren:

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

== Konfiguration der Discourse Software ==

Anlegen einer Datei ''/home/pacs/xyz00/users/discourse/discourse/config/discourse.conf'' anhand der Beispiel-Datei:

<syntaxhighlight lang=shell>
cd ~/discourse
cp config/discourse_defaults.conf config/discourse.conf
</syntaxhighlight>

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

<syntaxhighlight lang=shell>
RAILS_ENV=production bundle exec rake secret
</syntaxhighlight>

=== 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 <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 ==

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

[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
</syntaxhighlight>

== Einrichten des Apache VHost ==

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

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:

<syntaxhighlight lang=apache line>
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]
</syntaxhighlight>
== 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.

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

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

<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!

Siehe auch die unterstützten Releases: https://releases.discourse.org/ und die Tags: https://github.com/discourse/discourse/tags

==== Am Beispiel von 2026.1.5 auf 2026.1.7 ====

# 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
# mv ~/plugins.bak/discourse-ai plugins
# git diff v2026.1.5 > diff-2026.1.5.txt
# git fetch
# git checkout -b hostsharing-deployment-v2026.1.7 v2026.1.7
# evtl. Änderungen aus diff-2026.1.5.txt wieder übernehmen und committen
# patch -p1 < diff-2026.1.5.txt
# git commit -a -m "spezifische Änderungen für diese Instanz" --no-verify
# Schauen, ob discourse eine neue Ruby-Version nutzt (z.B. in https://github.com/discourse/discourse_docker/blob/main/image/base/Dockerfile bzw. https://github.com/discourse/discourse/blob/v2026.1.7/Gemfile)
# Ist dies der Fall, dann:
# rbenv install 3.3.8
# rbenv global 3.3.8
# rbenv rehash
# echo "3.3.8" > .ruby-version
# installiere Node 22: https://codeberg.org/tpokorra/hostsharing-scripts/src/branch/main/install-nodejs.sh
# source ~/.profile
# gem update --system
# bundle install
# npm install -g terser uglify-js pnpm@10
#
# to avoid this error: ERR_PNPM_INVALID_DEPENDENCY_NAME The current package contains a dependency with an invalid name: "@types/@glimmer__component"
# vi frontend/discourse-types/package.json

- "@types/@glimmer__component": "npm:@glimmer/component@^2.0.0",
- "@types/@glint__ember-tsc": "npm:@glint/ember-tsc@^1.0.7",
- "@types/@glint__template": "npm:@glint/template@^1.7.2"
+ "@types/glimmer__component": "npm:@glimmer/component@^2.0.0",
+ "@types/glint__ember-tsc": "npm:@glint/ember-tsc@^1.0.7",
+ "@types/glint__template": "npm:@glint/template@^1.7.2"

#
# corepack use pnpm@latest-10
# pnpm install
# export $(grep -v '^#' ~/discourse.env | xargs -d '\n')
# source ~/.profile
# Falls die pg extension pg_vector nicht installiert ist: deaktiviere das Plugin während migrate, aber auch für später damit /admin/settings funktioniert (ansonsten in salt pillar pg_vector installieren, und als postgres user: create extension vector;)
## mkdir -p ~/plugins.bak
## mv plugins/discourse-ai ~/plugins.bak
# 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>

Update: es hat sich wieder mehr im Code verändert. Bitte den Patch von https://codeberg.org/tpokorra/hs.ansible/src/branch/main/roles/apps/discourse/templates/imagemagick.patch benutzen!

== 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

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

Discourse installieren

2026-08-06T08:59:12Z

Tim00: /* Am Beispiel von 2026.1.5 auf 2026.1.7 */

{{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|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 ==

Es müssen noch Erweiterungen für Postgresql installiert werden:

<syntaxhighlight lang=shell line>
psql --user xyz00_discourseuser -c "CREATE EXTENSION IF NOT EXISTS hstore WITH SCHEMA public;"
psql --user xyz00_discourseuser -c "CREATE EXTENSION IF NOT EXISTS pg_trgm WITH SCHEMA public;"
psql --user xyz00_discourseuser -c "CREATE EXTENSION IF NOT EXISTS unaccent WITH SCHEMA public;"
</syntaxhighlight>

== Konfiguration des Redis Server ==

{{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.}}

<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:

<syntaxhighlight lang=shell line>
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
</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 ==

Als User ''xyz00-discourse'': Installation von Ruby mit ''rbenv'' mit folgenden Befehlen:

Zunächst ''rbenv'' and ''ruby-build'':

<syntaxhighlight lang=shell line>
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
</syntaxhighlight>

starte neue Shell:

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

Überprüfe rbenv-Installation

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

Installiere ruby-build als rbenv-Plugin

<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:

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

== Installation von Discourse selber ==

Weiterhin Als User ''xyz00-discourse'':

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

Die stabile Version auschecken:

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

Ruby Pakete installieren:

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

== Konfiguration der Discourse Software ==

Anlegen einer Datei ''/home/pacs/xyz00/users/discourse/discourse/config/discourse.conf'' anhand der Beispiel-Datei:

<syntaxhighlight lang=shell>
cd ~/discourse
cp config/discourse_defaults.conf config/discourse.conf
</syntaxhighlight>

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

<syntaxhighlight lang=shell>
RAILS_ENV=production bundle exec rake secret
</syntaxhighlight>

=== 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 <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 ==

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

[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
</syntaxhighlight>

== Einrichten des Apache VHost ==

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

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:

<syntaxhighlight lang=apache line>
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]
</syntaxhighlight>
== 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.

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

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

<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!

Siehe auch die unterstützten Releases: https://releases.discourse.org/ und die Tags: https://github.com/discourse/discourse/tags

==== Am Beispiel von 2026.1.5 auf 2026.1.7 ====

# 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
# mv ~/plugins.bak/discourse-ai plugins
# git diff v2026.1.5 > diff-2026.1.5.txt
# git fetch
# git checkout -b hostsharing-deployment-v2026.1.7 v2026.1.7
# evtl. Änderungen aus diff-2026.1.5.txt wieder übernehmen und committen
# patch -p1 < diff-2026.1.5.txt
# git commit -a -m "spezifische Änderungen für diese Instanz" --no-verify
# Schauen, ob discourse eine neue Ruby-Version nutzt (z.B. in https://github.com/discourse/discourse_docker/blob/main/image/base/Dockerfile bzw. https://github.com/discourse/discourse/blob/v2026.1.7/Gemfile)
# Ist dies der Fall, dann:
# rbenv install 3.3.8
# rbenv global 3.3.8
# rbenv rehash
# echo "3.3.8" > .ruby-version
# installiere Node 22: https://codeberg.org/tpokorra/hostsharing-scripts/src/branch/main/install-nodejs.sh
# source ~/.profile
# gem update --system
# bundle install
# npm install -g terser uglify-js pnpm@10
#
# to avoid this error: ERR_PNPM_INVALID_DEPENDENCY_NAME The current package contains a dependency with an invalid name: "@types/@glimmer__component"
# vi frontend/discourse-types/package.json

- "@types/@glimmer__component": "npm:@glimmer/component@^2.0.0",
- "@types/@glint__ember-tsc": "npm:@glint/ember-tsc@^1.0.7",
- "@types/@glint__template": "npm:@glint/template@^1.7.2"
+ "@types/glimmer__component": "npm:@glimmer/component@^2.0.0",
+ "@types/glint__ember-tsc": "npm:@glint/ember-tsc@^1.0.7",
+ "@types/glint__template": "npm:@glint/template@^1.7.2"

#
# corepack use pnpm@latest-10
# pnpm install
# export $(grep -v '^#' ~/discourse.env | xargs -d '\n')
# source ~/.profile
# Falls die pg extension pg_vector nicht installiert ist: deaktiviere das Plugin während migrate, aber auch für später damit /admin/settings funktioniert (ansonsten in salt pillar pg_vector installieren, und als postgres user: create extension vector;)
## mkdir -p ~/plugins.bak
## mv plugins/discourse-ai ~/plugins.bak
# 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 ==

* 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

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

Matrix Synapse installieren

2026-08-04T09:36:19Z

Tim00: /* Verwalten von Benutzern */

Der Matrix Server ''Synapse'', der sogenannte 'Homeserver', ist aktuell die einzige vollständige serverseitige Implementierung des Matrix-Protokolls.

{{Textkasten|gelb|Work in Progress|Leider funktioniert die Server-zu-Server-Kommunikation von Synapse hinter dem Apache-Proxy mit den genannten Rewrite-Rules nicht. Bitten Sie dazu den Service, Ihren Apache VHost individuell für den Matrix Server anzupassen.}}

Die hier beschriebene Installation benötigt bei Hostsharing die Paket-Option "RAM". Benötigt werden min. 512 MB. Im Managed Webspace ist diese Option kostenpflichtig: https://www.hostsharing.net/angebote/managed-webspace/ gebucht werden muss der RAM auch bei einem Managed-Server.
Wir empfehlen für den Betrieb einen ''Managed Server''.

Diese Anleitung beschreibt, wie man den Matrix-Homeserver Synapse auf der Managed Hosting Plattform von Hostsharing installieren kann. Dabei sind die User-IDs nach dem Schema @user:beispiel.de aufgebaut, der Homeserver an sich ist unter matrix.beispiel.de erreichbar.

== Vorbereitungen ==

Mit Hilfe von HSAdmin werden angelegt:
# Ein User als Service-User mit ''/bin/bash'' als Shell, zum Beispiel Beispiel: ''xyz00-matrix''
# Eine Domain mit ''xyz00-matrix'' als Domain-Administrator, zum Beispiel ''matrix.beispiel.de''
# Einen Postgresql-User ''xyz00_matrixuser'' mit Passwort ''meinPasswort''
# Eine Postgresql-Datenbank ''xyz00_matrixdb'' mit Datenbank-Owner ''xyz00_matrixuser''

Verwendeter IP-Port für den Server-Dienst:
# Synapse: localhost:32801

== Installation von Synapse ==

Installationsanleitung basierend auf https://matrix-org.github.io/synapse/latest/setup/installation.html#installing-as-a-python-module-from-pypi

Als User ''xyz00-matrix" ein Python3 virtualenv erstellen:

<syntaxhighlight lang="shell">
mkdir -p ~/synapse
cd ~/synapse
python -m venv .venv
</syntaxhighlight>

Synapse und Postgres-Dependencies installieren:

<syntaxhighlight lang="shell">
source ~/synapse/.venv/bin/activate
pip install pipenv
pipenv install matrix-synapse[postgres,oidc] lxml authlib
</syntaxhighlight>

Initiale Konfiguration mit richtigem server-name "beispiel.de" generieren, außerdem im laufenden Betrieb keine Statistiken an Matrix.org senden:

<syntaxhighlight lang="shell">
cd ~/synapse
pipenv run python -m synapse.app.homeserver --server-name beispiel.de --config-path homeserver.yaml --generate-config --report-stats=no
</syntaxhighlight>

== Konfiguration von Synapse ==

In die initial generierte Konfiguration muss noch die Port- und Datenbank-Konfiguration eingetragen werden:

Port: Innerhalb der listener-section den Port 8008 auf 32801 (wie initial definiert) ändern, alles andere beibehalten:

<syntaxhighlight lang=yaml line>
- port: 32801
tls: false
bind_addresses: ['::1', '127.0.0.1']
type: http
x_forwarded: true
</syntaxhighlight>

Postgres-Datenbank:
<syntaxhighlight lang=yaml line>
database:
# The database engine name
name: "psycopg2"
# Arguments to pass to the engine
args:
host: "localhost"
database: "xyz00_matrixdb"
user: "xyz00_matrixuser"
password: "meinPasswort"
cp_min: 5
cp_max: 10
</syntaxhighlight>

== Starten der Dienste ==

Der ''Synapse''-Dienst wird hier als Service-Unit im SystemD des Users eingetragen.

Lege dazu die folgende Datei an: ''~/.config/systemd/user/synapse.service'' mit dem Inhalt:
<syntaxhighlight lang="ini" line>
[Unit]
Description=Synapse

[Service]
Type=simple
WorkingDirectory=%h/synapse
Environment=LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so.2
ExecStart=pipenv run python -m synapse.app.homeserver --config-path=%h/synapse/homeserver.yaml

[Install]
WantedBy=default.target
</syntaxhighlight>

Durch Aufruf der folgenden Kommandos wird der Dienst aktiviert und gestartet:
<syntaxhighlight lang="shell" lines>
systemctl --user daemon-reload
systemctl --user enable synapse.service
systemctl --user start synapse.service
</syntaxhighlight>
== Verwalten von Benutzern ==

Mit den folgenden Befehlen kann ein Benutzer angelegt werden:

<syntaxhighlight lang=bash>
cd ~/synapse
source .venv/bin/activate
register_new_matrix_user -c homeserver.yaml --user <USERNAME> <--admin|--no-admin>
</syntaxhighlight>

So kann ein Benutzer auch wieder deaktiviert werden:

<syntaxhighlight lang=bash>
user=<USERNAME>
domain="https://<matrix.example.org>"
password="<TOPSECRET>"

cd ~/synapse
source .venv/bin/activate

url_user=`echo -n "$user" | jq -s -R -r @uri`
json=`curl -s --insecure -XPOST -d '{"type":"m.login.password", "user":"root", "password":"'$password'"}' "https://$domain/_matrix/client/r0/login"`
access_token=`echo "$json" | jq -r ".access_token"`

# see https://matrix-org.github.io/synapse/latest/admin_api/user_admin_api.html#deactivate-account
curl --insecure -XPOST -H "Authorization: Bearer $access_token" -H "Content-Type: application/json" -d \
'{"erase": true}' "$domain/_synapse/admin/v1/deactivate/$url_user"
</syntaxhighlight>

Es gibt auch Bash Skripte dafür, damit die Benutzung vereinfacht wird:
* https://codeberg.org/tpokorra/hs.ansible.app.synapse/src/branch/main/templates/adduser.sh
* https://codeberg.org/tpokorra/hs.ansible.app.synapse/src/branch/main/templates/deluser.sh

Es gibt auch eine grafische Oberfläche:
* https://github.com/Awesome-Technologies/synapse-admin
* bzw. der Fork https://github.com/etkecc/ketesa

Ansonsten kann für die Benutzerverwaltung ein Keycloak installiert werden, und Synapse über OIDC an den Keycloak angeschlossen werden.

== Einrichten des Apache VHost ==

Die ''~/doms/matrix.beispiel.de/.htaccess'' mit dem Editor der Wahl öffnen und
folgende Konfiguration einfügen:
<syntaxhighlight lang=apache line>
DirectoryIndex disabled
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule .* http://localhost:32801%{REQUEST_URI} [NE,proxy]
RequestHeader set X-Forwarded-Proto "https"
</syntaxhighlight>

== Well-Known unter beispiel.de ==

Damit die User-Accounts das Format @user:beispiel.de haben, der Server aber unter matrix.beispiel.de erreichbar ist, müssen noch folgende zwei Dateien unter der Domain beispiel.de abgelegt werden:

https://beispiel.de/.well-known/matrix/server
<syntaxhighlight lang=json line>
{
"m.server": "matrix.beispiel.de:443"
}
</syntaxhighlight>

https://beispiel.de/.well-known/matrix/client
<syntaxhighlight lang=json line>
{
"m.homeserver": {
"base_url": "https://matrix.beispiel.de"
},
"m.identity_server": {
"base_url": "https://vector.im"
}
}
</syntaxhighlight>

Für die muss noch der CORS-Header Access-Control-Allow-Origin "*" gesetzt werden, damit die Datei aus beliebigem Riot-Web im Browser abrufbar ist. Dazu in den Ordner .well-known/matrix/ folgende .htaccess anlegen:
<syntaxhighlight lang=apache line>
<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin "*"
</IfModule>
</syntaxhighlight>

Die Dokumentation dazu findet man unter https://matrix.org/docs/spec/server_server/r0.1.2#get-well-known-matrix-server und https://matrix.org/docs/spec/client_server/r0.5.0#get-well-known-matrix-client

== Update von Synapse ==

Normalerweise sollte es so gehen, mit pipenv:

<syntaxhighlight lang=shell>
cd ~/synapse
pipenv update --outdated || echo "there are packages to update"
pipenv update
systemctl --user restart synapse
</syntaxhighlight>

In seltenen Fällen gibt es Probleme bei den Abhängigkeiten, die schon wieder aktualisiert wurden, und nicht mehr kompatibel zum aktuellen Synapse sind.
Dann ist es zu empfehlen, Synapse mit der offiziellen poetry.lock Datei zu aktualisieren, um die Konflikte zu vermeiden.

mit poetry:
<syntaxhighlight lang=shell>
systemctl --user stop synapse.service
source ~/.venv/bin/activate
release=`curl -L https://api.github.com/repos/element-hq/synapse/releases/latest -s | jq -r '.tag_name'`
rm -Rf ~/synapse.src
git clone --depth 1 https://github.com/element-hq/synapse.git -b ${release} ~/synapse.src
cd ~/synapse.src
pip install poetry
poetry install --extras=postgres --extras=oidc
systemctl --user start synapse.service
</syntaxhighlight>

Wenn die Föderation für den Synapse Server aktiviert ist, kann mit dem [https://federationtester.matrix.org/ Matrix Federation Tester] die eigene Instanz auf die laufende Version geprüft werden. Als Server nicht matrix.example.org eingeben, sondern den öffentlichen Namen, wo auch die Benutzernamen drauf laufen, z.B. example.org

Ansonsten ist die laufende Version auch über die URL https://matrix.example.org/_synapse/admin/v1/server_version zu erfahren.

== Element-Web ==

Element-Web ist aus Server-Seite eine rein statische html+javascript-Kombination, daher:

* Account und Domain anlegen (separat von der Synapse-Domain)
* [https://github.com/element-hq/element-web/releases/latest aktuelles element-web release] .tgz herunterladen
* Symlink von htdocs-ssl auf entpacktes element-web-Verzeichnis
* config.sample.json in config.json kopieren und Matrix-Homeserver-Einträge anpassen
* Piwik aus config.json entfernen

== SAML mit Synapse ==

Synapse unterstützt mit Version 1.1.0 SAML. Dazu wie folgt vorgehen:

Das Paket xmlsec1 muss installiert sein:

<syntaxhighlight lang=shell>
$ xmlsec1 --version
xmlsec1 1.2.23 (openssl)
</syntaxhighlight>

Das Python-Paket pysaml2 installieren

<syntaxhighlight lang=shell>
cd ~/synapse
pipenv shell
pipenv install pysaml2
</syntaxhighlight>

In der homeserver.yaml die SAML-Direktiven einkommentieren, hier mit dem Beispiel eines SAML IdP unter https://login.beispiel.de/simplesaml/saml2/idp/metadata.php:

<syntaxhighlight lang=yaml line>
# Once SAML support is enabled, a metadata file will be exposed at
# https://<server>:<port>/_matrix/saml2/metadata.xml, which you may be able to
# use to configure your SAML IdP with. Alternatively, you can manually configure
# the IdP to use an ACS location of
# https://<server>:<port>/_matrix/saml2/authn_response.
#
saml2_config:
sp_config:
# point this to the IdP's metadata. You can use either a local file or
# (preferably) a URL.
metadata:
#local: ["saml2/idp.xml"]
remote:
- url: https://login.beispiel.de/simplesaml/saml2/idp/metadata.php
</syntaxhighlight>
Wichtig ist außerdem, dass die public_baseurl in der homeserver.yaml gesetzt ist, damit Synapse weiß, wie es erreichbar ist und dies in seine SP-Metadaten einbauen kann:
<syntaxhighlight lang=yaml line>
public_baseurl: https://matrix.beispiel.de/
</syntaxhighlight>
Die Service-Provider-Konfiguration als XML bekommt man von Synapse dann wie schon in der homeserver.yaml als Kommentar beschrieben, unter https://matrix.beispiel.de/_matrix/saml2/metadata.xml

Diese dann in den SAML-IdP-importieren und dann sollte der Single-Sign-On via SAML funktionieren.

== Federation Sender Worker für Synapse ==

Zur Parallelisierung bietet Synapse das Konzept "Worker" an, die spezifische Aufgaben übernehmen, damit der Hauptprozess diese nicht durchführen muss.

Details dazu: https://github.com/matrix-org/synapse/blob/master/docs/workers.md

Ein einfach einzurichtender Worker, der auch viel Last abfedert, ist der Federation Sender Worker, da das Verschicken des Federation-Traffics 10-50% der Serverlast ausmacht.

In der homeserver.yaml die Worker-Konfiguration aktivieren:
<syntaxhighlight lang=yaml line>
## Worker ##
worker_app: synapse.app.homeserver
daemonize: true
</syntaxhighlight>

und dazugehörige Listener (Abschnitt listener:) aktivieren:
<syntaxhighlight lang=yaml line>
# The TCP replication port
- port: 32892
bind_address: '127.0.0.1'
type: replication
# The HTTP replication port
- port: 32893
bind_address: '127.0.0.1'
type: http
resources:
- names: [replication]
</syntaxhighlight>

Funktionen, die Worker machen sollen, in der homeserver.yaml deaktivieren:
<syntaxhighlight lang=yaml line>
# disable federation sending here, use worker for it
send_federation: False
</syntaxhighlight>
Dann Verzeichnis synapse/workers anlegen, darin federation_sender.yaml:
<syntaxhighlight lang=yaml line>
worker_app: synapse.app.federation_sender

# The replication listener on the synapse to talk to.
worker_replication_host: 127.0.0.1
worker_replication_port: 32892
worker_replication_http_port: 32893

worker_daemonize: True
worker_pid_file: /home/pacs/xyz00/users/matrix/synapse/federation_sender.pid
worker_log_config: /home/pacs/xyz00/users/matrix/synapse/federation_sender.log.config
</syntaxhighlight>
.monitrc um worker erweitern:
<syntaxhighlight lang=shell line>
check process federation_sender with pidfile /home/pacs/xyz00/users/matrix/synapse/federation_sender.pid
start program "/bin/bash -c 'export VIRTUAL_ENV=$HOME/synapse/env && export PATH=$VIRTUAL_ENV/bin:$PATH && cd $HOME/synapse && synctl -w workers/federation_sender.yaml start'"
stop program "/bin/bash -c '/bin/kill $( cat $HOME/synapse/federation_sender.pid )'"
</syntaxhighlight>
Monit neu laden und synapse und federation_sender neustarten:

<syntaxhighlight lang=shell>
monit reload
monit restart all
</syntaxhighlight>

Nach Updates ebenfalls immer Hauptprozess und alle Worker neustarten

<syntaxhighlight lang=shell>
monit restart all
</syntaxhighlight>

== Sliding Sync Proxy ==
Zum Zeitpunkt dieser Anleitung werden aktiv neue Element Anwendungen (Element X) und ein neues Syncverfahren entwickelt um Matrix performanter und weniger ressourcenhungrig zu machen. Bei stärkerer Matrix Nutzung können die neuen Anwendungen besonders mobil schon eine große Entlastung sein.

Ende 2024 wurden grundlegende Funktionen direkt in Synapse implementiert. Der Proxy wird nicht länger weiterentwickelt und sollte deinstalliert werden (nicht vergessen die .well-known zurück zu ändern). Auch der 3rdparty Server [[Conduit]] bringt nativ Support für Sliding Sync.

== Links ==

* https://matrix.org/docs/projects/server/synapse
* https://github.com/element-hq/synapse
* https://github.com/element-hq/synapse/blob/master/INSTALL.md
* https://github.com/matrix-org/sliding-sync
* https://matrix.org/docs/spec/
* https://www.hostsharing.net/loesungen/matrix/
* https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/synapse
* https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/element

[[Kategorie:Messenger]]
[[Kategorie:Software]]
[[Kategorie:Eigene Daemons]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]

Matrix Synapse installieren

2026-08-04T09:00:28Z

Tim00: /* Verwalten von Benutzern */

Der Matrix Server ''Synapse'', der sogenannte 'Homeserver', ist aktuell die einzige vollständige serverseitige Implementierung des Matrix-Protokolls.

{{Textkasten|gelb|Work in Progress|Leider funktioniert die Server-zu-Server-Kommunikation von Synapse hinter dem Apache-Proxy mit den genannten Rewrite-Rules nicht. Bitten Sie dazu den Service, Ihren Apache VHost individuell für den Matrix Server anzupassen.}}

Die hier beschriebene Installation benötigt bei Hostsharing die Paket-Option "RAM". Benötigt werden min. 512 MB. Im Managed Webspace ist diese Option kostenpflichtig: https://www.hostsharing.net/angebote/managed-webspace/ gebucht werden muss der RAM auch bei einem Managed-Server.
Wir empfehlen für den Betrieb einen ''Managed Server''.

Diese Anleitung beschreibt, wie man den Matrix-Homeserver Synapse auf der Managed Hosting Plattform von Hostsharing installieren kann. Dabei sind die User-IDs nach dem Schema @user:beispiel.de aufgebaut, der Homeserver an sich ist unter matrix.beispiel.de erreichbar.

== Vorbereitungen ==

Mit Hilfe von HSAdmin werden angelegt:
# Ein User als Service-User mit ''/bin/bash'' als Shell, zum Beispiel Beispiel: ''xyz00-matrix''
# Eine Domain mit ''xyz00-matrix'' als Domain-Administrator, zum Beispiel ''matrix.beispiel.de''
# Einen Postgresql-User ''xyz00_matrixuser'' mit Passwort ''meinPasswort''
# Eine Postgresql-Datenbank ''xyz00_matrixdb'' mit Datenbank-Owner ''xyz00_matrixuser''

Verwendeter IP-Port für den Server-Dienst:
# Synapse: localhost:32801

== Installation von Synapse ==

Installationsanleitung basierend auf https://matrix-org.github.io/synapse/latest/setup/installation.html#installing-as-a-python-module-from-pypi

Als User ''xyz00-matrix" ein Python3 virtualenv erstellen:

<syntaxhighlight lang="shell">
mkdir -p ~/synapse
cd ~/synapse
python -m venv .venv
</syntaxhighlight>

Synapse und Postgres-Dependencies installieren:

<syntaxhighlight lang="shell">
source ~/synapse/.venv/bin/activate
pip install pipenv
pipenv install matrix-synapse[postgres,oidc] lxml authlib
</syntaxhighlight>

Initiale Konfiguration mit richtigem server-name "beispiel.de" generieren, außerdem im laufenden Betrieb keine Statistiken an Matrix.org senden:

<syntaxhighlight lang="shell">
cd ~/synapse
pipenv run python -m synapse.app.homeserver --server-name beispiel.de --config-path homeserver.yaml --generate-config --report-stats=no
</syntaxhighlight>

== Konfiguration von Synapse ==

In die initial generierte Konfiguration muss noch die Port- und Datenbank-Konfiguration eingetragen werden:

Port: Innerhalb der listener-section den Port 8008 auf 32801 (wie initial definiert) ändern, alles andere beibehalten:

<syntaxhighlight lang=yaml line>
- port: 32801
tls: false
bind_addresses: ['::1', '127.0.0.1']
type: http
x_forwarded: true
</syntaxhighlight>

Postgres-Datenbank:
<syntaxhighlight lang=yaml line>
database:
# The database engine name
name: "psycopg2"
# Arguments to pass to the engine
args:
host: "localhost"
database: "xyz00_matrixdb"
user: "xyz00_matrixuser"
password: "meinPasswort"
cp_min: 5
cp_max: 10
</syntaxhighlight>

== Starten der Dienste ==

Der ''Synapse''-Dienst wird hier als Service-Unit im SystemD des Users eingetragen.

Lege dazu die folgende Datei an: ''~/.config/systemd/user/synapse.service'' mit dem Inhalt:
<syntaxhighlight lang="ini" line>
[Unit]
Description=Synapse

[Service]
Type=simple
WorkingDirectory=%h/synapse
Environment=LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so.2
ExecStart=pipenv run python -m synapse.app.homeserver --config-path=%h/synapse/homeserver.yaml

[Install]
WantedBy=default.target
</syntaxhighlight>

Durch Aufruf der folgenden Kommandos wird der Dienst aktiviert und gestartet:
<syntaxhighlight lang="shell" lines>
systemctl --user daemon-reload
systemctl --user enable synapse.service
systemctl --user start synapse.service
</syntaxhighlight>
== Verwalten von Benutzern ==

Mit den folgenden Befehlen kann ein Benutzer angelegt werden:

<syntaxhighlight lang=bash>
cd ~/synapse
source .venv/bin/activate
register_new_matrix_user -c homeserver.yaml --user <USERNAME> <--admin|--no-admin>
</syntaxhighlight>

So kann ein Benutzer auch wieder deaktiviert werden:

<syntaxhighlight lang=bash>
user=<USERNAME>
domain="https://<matrix.example.org>"
password="<TOPSECRET>"

cd ~/synapse
source .venv/bin/activate

url_user=`echo -n "$user" | jq -s -R -r @uri`
json=`curl -s --insecure -XPOST -d '{"type":"m.login.password", "user":"root", "password":"'$password'"}' "https://$domain/_matrix/client/r0/login"`
access_token=`echo "$json" | jq -r ".access_token"`

# see https://matrix-org.github.io/synapse/latest/admin_api/user_admin_api.html#deactivate-account
curl --insecure -XPOST -H "Authorization: Bearer $access_token" -H "Content-Type: application/json" -d \
'{"erase": true}' "$domain/_synapse/admin/v1/deactivate/$url_user"
</syntaxhighlight>

Ansonsten kann für die Benutzerverwaltung ein Keycloak installiert werden, und Synapse über OIDC an den Keycloak angeschlossen werden.

== Einrichten des Apache VHost ==

Die ''~/doms/matrix.beispiel.de/.htaccess'' mit dem Editor der Wahl öffnen und
folgende Konfiguration einfügen:
<syntaxhighlight lang=apache line>
DirectoryIndex disabled
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule .* http://localhost:32801%{REQUEST_URI} [NE,proxy]
RequestHeader set X-Forwarded-Proto "https"
</syntaxhighlight>

== Well-Known unter beispiel.de ==

Damit die User-Accounts das Format @user:beispiel.de haben, der Server aber unter matrix.beispiel.de erreichbar ist, müssen noch folgende zwei Dateien unter der Domain beispiel.de abgelegt werden:

https://beispiel.de/.well-known/matrix/server
<syntaxhighlight lang=json line>
{
"m.server": "matrix.beispiel.de:443"
}
</syntaxhighlight>

https://beispiel.de/.well-known/matrix/client
<syntaxhighlight lang=json line>
{
"m.homeserver": {
"base_url": "https://matrix.beispiel.de"
},
"m.identity_server": {
"base_url": "https://vector.im"
}
}
</syntaxhighlight>

Für die muss noch der CORS-Header Access-Control-Allow-Origin "*" gesetzt werden, damit die Datei aus beliebigem Riot-Web im Browser abrufbar ist. Dazu in den Ordner .well-known/matrix/ folgende .htaccess anlegen:
<syntaxhighlight lang=apache line>
<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin "*"
</IfModule>
</syntaxhighlight>

Die Dokumentation dazu findet man unter https://matrix.org/docs/spec/server_server/r0.1.2#get-well-known-matrix-server und https://matrix.org/docs/spec/client_server/r0.5.0#get-well-known-matrix-client

== Update von Synapse ==

Normalerweise sollte es so gehen, mit pipenv:

<syntaxhighlight lang=shell>
cd ~/synapse
pipenv update --outdated || echo "there are packages to update"
pipenv update
systemctl --user restart synapse
</syntaxhighlight>

In seltenen Fällen gibt es Probleme bei den Abhängigkeiten, die schon wieder aktualisiert wurden, und nicht mehr kompatibel zum aktuellen Synapse sind.
Dann ist es zu empfehlen, Synapse mit der offiziellen poetry.lock Datei zu aktualisieren, um die Konflikte zu vermeiden.

mit poetry:
<syntaxhighlight lang=shell>
systemctl --user stop synapse.service
source ~/.venv/bin/activate
release=`curl -L https://api.github.com/repos/element-hq/synapse/releases/latest -s | jq -r '.tag_name'`
rm -Rf ~/synapse.src
git clone --depth 1 https://github.com/element-hq/synapse.git -b ${release} ~/synapse.src
cd ~/synapse.src
pip install poetry
poetry install --extras=postgres --extras=oidc
systemctl --user start synapse.service
</syntaxhighlight>

Wenn die Föderation für den Synapse Server aktiviert ist, kann mit dem [https://federationtester.matrix.org/ Matrix Federation Tester] die eigene Instanz auf die laufende Version geprüft werden. Als Server nicht matrix.example.org eingeben, sondern den öffentlichen Namen, wo auch die Benutzernamen drauf laufen, z.B. example.org

Ansonsten ist die laufende Version auch über die URL https://matrix.example.org/_synapse/admin/v1/server_version zu erfahren.

== Element-Web ==

Element-Web ist aus Server-Seite eine rein statische html+javascript-Kombination, daher:

* Account und Domain anlegen (separat von der Synapse-Domain)
* [https://github.com/element-hq/element-web/releases/latest aktuelles element-web release] .tgz herunterladen
* Symlink von htdocs-ssl auf entpacktes element-web-Verzeichnis
* config.sample.json in config.json kopieren und Matrix-Homeserver-Einträge anpassen
* Piwik aus config.json entfernen

== SAML mit Synapse ==

Synapse unterstützt mit Version 1.1.0 SAML. Dazu wie folgt vorgehen:

Das Paket xmlsec1 muss installiert sein:

<syntaxhighlight lang=shell>
$ xmlsec1 --version
xmlsec1 1.2.23 (openssl)
</syntaxhighlight>

Das Python-Paket pysaml2 installieren

<syntaxhighlight lang=shell>
cd ~/synapse
pipenv shell
pipenv install pysaml2
</syntaxhighlight>

In der homeserver.yaml die SAML-Direktiven einkommentieren, hier mit dem Beispiel eines SAML IdP unter https://login.beispiel.de/simplesaml/saml2/idp/metadata.php:

<syntaxhighlight lang=yaml line>
# Once SAML support is enabled, a metadata file will be exposed at
# https://<server>:<port>/_matrix/saml2/metadata.xml, which you may be able to
# use to configure your SAML IdP with. Alternatively, you can manually configure
# the IdP to use an ACS location of
# https://<server>:<port>/_matrix/saml2/authn_response.
#
saml2_config:
sp_config:
# point this to the IdP's metadata. You can use either a local file or
# (preferably) a URL.
metadata:
#local: ["saml2/idp.xml"]
remote:
- url: https://login.beispiel.de/simplesaml/saml2/idp/metadata.php
</syntaxhighlight>
Wichtig ist außerdem, dass die public_baseurl in der homeserver.yaml gesetzt ist, damit Synapse weiß, wie es erreichbar ist und dies in seine SP-Metadaten einbauen kann:
<syntaxhighlight lang=yaml line>
public_baseurl: https://matrix.beispiel.de/
</syntaxhighlight>
Die Service-Provider-Konfiguration als XML bekommt man von Synapse dann wie schon in der homeserver.yaml als Kommentar beschrieben, unter https://matrix.beispiel.de/_matrix/saml2/metadata.xml

Diese dann in den SAML-IdP-importieren und dann sollte der Single-Sign-On via SAML funktionieren.

== Federation Sender Worker für Synapse ==

Zur Parallelisierung bietet Synapse das Konzept "Worker" an, die spezifische Aufgaben übernehmen, damit der Hauptprozess diese nicht durchführen muss.

Details dazu: https://github.com/matrix-org/synapse/blob/master/docs/workers.md

Ein einfach einzurichtender Worker, der auch viel Last abfedert, ist der Federation Sender Worker, da das Verschicken des Federation-Traffics 10-50% der Serverlast ausmacht.

In der homeserver.yaml die Worker-Konfiguration aktivieren:
<syntaxhighlight lang=yaml line>
## Worker ##
worker_app: synapse.app.homeserver
daemonize: true
</syntaxhighlight>

und dazugehörige Listener (Abschnitt listener:) aktivieren:
<syntaxhighlight lang=yaml line>
# The TCP replication port
- port: 32892
bind_address: '127.0.0.1'
type: replication
# The HTTP replication port
- port: 32893
bind_address: '127.0.0.1'
type: http
resources:
- names: [replication]
</syntaxhighlight>

Funktionen, die Worker machen sollen, in der homeserver.yaml deaktivieren:
<syntaxhighlight lang=yaml line>
# disable federation sending here, use worker for it
send_federation: False
</syntaxhighlight>
Dann Verzeichnis synapse/workers anlegen, darin federation_sender.yaml:
<syntaxhighlight lang=yaml line>
worker_app: synapse.app.federation_sender

# The replication listener on the synapse to talk to.
worker_replication_host: 127.0.0.1
worker_replication_port: 32892
worker_replication_http_port: 32893

worker_daemonize: True
worker_pid_file: /home/pacs/xyz00/users/matrix/synapse/federation_sender.pid
worker_log_config: /home/pacs/xyz00/users/matrix/synapse/federation_sender.log.config
</syntaxhighlight>
.monitrc um worker erweitern:
<syntaxhighlight lang=shell line>
check process federation_sender with pidfile /home/pacs/xyz00/users/matrix/synapse/federation_sender.pid
start program "/bin/bash -c 'export VIRTUAL_ENV=$HOME/synapse/env && export PATH=$VIRTUAL_ENV/bin:$PATH && cd $HOME/synapse && synctl -w workers/federation_sender.yaml start'"
stop program "/bin/bash -c '/bin/kill $( cat $HOME/synapse/federation_sender.pid )'"
</syntaxhighlight>
Monit neu laden und synapse und federation_sender neustarten:

<syntaxhighlight lang=shell>
monit reload
monit restart all
</syntaxhighlight>

Nach Updates ebenfalls immer Hauptprozess und alle Worker neustarten

<syntaxhighlight lang=shell>
monit restart all
</syntaxhighlight>

== Sliding Sync Proxy ==
Zum Zeitpunkt dieser Anleitung werden aktiv neue Element Anwendungen (Element X) und ein neues Syncverfahren entwickelt um Matrix performanter und weniger ressourcenhungrig zu machen. Bei stärkerer Matrix Nutzung können die neuen Anwendungen besonders mobil schon eine große Entlastung sein.

Ende 2024 wurden grundlegende Funktionen direkt in Synapse implementiert. Der Proxy wird nicht länger weiterentwickelt und sollte deinstalliert werden (nicht vergessen die .well-known zurück zu ändern). Auch der 3rdparty Server [[Conduit]] bringt nativ Support für Sliding Sync.

== Links ==

* https://matrix.org/docs/projects/server/synapse
* https://github.com/element-hq/synapse
* https://github.com/element-hq/synapse/blob/master/INSTALL.md
* https://github.com/matrix-org/sliding-sync
* https://matrix.org/docs/spec/
* https://www.hostsharing.net/loesungen/matrix/
* https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/synapse
* https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/element

[[Kategorie:Messenger]]
[[Kategorie:Software]]
[[Kategorie:Eigene Daemons]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]

Matrix Synapse installieren

2026-08-04T08:59:48Z

Tim00: Benutzerverwaltung

Der Matrix Server ''Synapse'', der sogenannte 'Homeserver', ist aktuell die einzige vollständige serverseitige Implementierung des Matrix-Protokolls.

{{Textkasten|gelb|Work in Progress|Leider funktioniert die Server-zu-Server-Kommunikation von Synapse hinter dem Apache-Proxy mit den genannten Rewrite-Rules nicht. Bitten Sie dazu den Service, Ihren Apache VHost individuell für den Matrix Server anzupassen.}}

Die hier beschriebene Installation benötigt bei Hostsharing die Paket-Option "RAM". Benötigt werden min. 512 MB. Im Managed Webspace ist diese Option kostenpflichtig: https://www.hostsharing.net/angebote/managed-webspace/ gebucht werden muss der RAM auch bei einem Managed-Server.
Wir empfehlen für den Betrieb einen ''Managed Server''.

Diese Anleitung beschreibt, wie man den Matrix-Homeserver Synapse auf der Managed Hosting Plattform von Hostsharing installieren kann. Dabei sind die User-IDs nach dem Schema @user:beispiel.de aufgebaut, der Homeserver an sich ist unter matrix.beispiel.de erreichbar.

== Vorbereitungen ==

Mit Hilfe von HSAdmin werden angelegt:
# Ein User als Service-User mit ''/bin/bash'' als Shell, zum Beispiel Beispiel: ''xyz00-matrix''
# Eine Domain mit ''xyz00-matrix'' als Domain-Administrator, zum Beispiel ''matrix.beispiel.de''
# Einen Postgresql-User ''xyz00_matrixuser'' mit Passwort ''meinPasswort''
# Eine Postgresql-Datenbank ''xyz00_matrixdb'' mit Datenbank-Owner ''xyz00_matrixuser''

Verwendeter IP-Port für den Server-Dienst:
# Synapse: localhost:32801

== Installation von Synapse ==

Installationsanleitung basierend auf https://matrix-org.github.io/synapse/latest/setup/installation.html#installing-as-a-python-module-from-pypi

Als User ''xyz00-matrix" ein Python3 virtualenv erstellen:

<syntaxhighlight lang="shell">
mkdir -p ~/synapse
cd ~/synapse
python -m venv .venv
</syntaxhighlight>

Synapse und Postgres-Dependencies installieren:

<syntaxhighlight lang="shell">
source ~/synapse/.venv/bin/activate
pip install pipenv
pipenv install matrix-synapse[postgres,oidc] lxml authlib
</syntaxhighlight>

Initiale Konfiguration mit richtigem server-name "beispiel.de" generieren, außerdem im laufenden Betrieb keine Statistiken an Matrix.org senden:

<syntaxhighlight lang="shell">
cd ~/synapse
pipenv run python -m synapse.app.homeserver --server-name beispiel.de --config-path homeserver.yaml --generate-config --report-stats=no
</syntaxhighlight>

== Konfiguration von Synapse ==

In die initial generierte Konfiguration muss noch die Port- und Datenbank-Konfiguration eingetragen werden:

Port: Innerhalb der listener-section den Port 8008 auf 32801 (wie initial definiert) ändern, alles andere beibehalten:

<syntaxhighlight lang=yaml line>
- port: 32801
tls: false
bind_addresses: ['::1', '127.0.0.1']
type: http
x_forwarded: true
</syntaxhighlight>

Postgres-Datenbank:
<syntaxhighlight lang=yaml line>
database:
# The database engine name
name: "psycopg2"
# Arguments to pass to the engine
args:
host: "localhost"
database: "xyz00_matrixdb"
user: "xyz00_matrixuser"
password: "meinPasswort"
cp_min: 5
cp_max: 10
</syntaxhighlight>

== Starten der Dienste ==

Der ''Synapse''-Dienst wird hier als Service-Unit im SystemD des Users eingetragen.

Lege dazu die folgende Datei an: ''~/.config/systemd/user/synapse.service'' mit dem Inhalt:
<syntaxhighlight lang="ini" line>
[Unit]
Description=Synapse

[Service]
Type=simple
WorkingDirectory=%h/synapse
Environment=LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so.2
ExecStart=pipenv run python -m synapse.app.homeserver --config-path=%h/synapse/homeserver.yaml

[Install]
WantedBy=default.target
</syntaxhighlight>

Durch Aufruf der folgenden Kommandos wird der Dienst aktiviert und gestartet:
<syntaxhighlight lang="shell" lines>
systemctl --user daemon-reload
systemctl --user enable synapse.service
systemctl --user start synapse.service
</syntaxhighlight>
== Verwalten von Benutzern ==

Mit den folgenden Befehlen kann ein Benutzer angelegt werden:

<syntaxhighlight lang=bash>
cd ~/synapse
source .venv/bin/activate
register_new_matrix_user -c homeserver.yaml --user <USERNAME> <--admin|--no-admin>
</syntaxhighlight>

So kann ein Benutzer auch wieder deaktiviert werden:

<syntaxhighlight lang=bash>
user=<USERNAME>
domain="https://<matrix.example.org>"

cd ~/synapse
source .venv/bin/activate

url_user=`echo -n "$user" | jq -s -R -r @uri`
json=`curl -s --insecure -XPOST -d '{"type":"m.login.password", "user":"root", "password":"'$password'"}' "https://$domain/_matrix/client/r0/login"`
access_token=`echo "$json" | jq -r ".access_token"`

# see https://matrix-org.github.io/synapse/latest/admin_api/user_admin_api.html#deactivate-account
curl --insecure -XPOST -H "Authorization: Bearer $access_token" -H "Content-Type: application/json" -d \
'{"erase": true}' "$domain/_synapse/admin/v1/deactivate/$url_user"
</syntaxhighlight>

Ansonsten kann für die Benutzerverwaltung ein Keycloak installiert werden, und Synapse über OIDC an den Keycloak angeschlossen werden.

== Einrichten des Apache VHost ==

Die ''~/doms/matrix.beispiel.de/.htaccess'' mit dem Editor der Wahl öffnen und
folgende Konfiguration einfügen:
<syntaxhighlight lang=apache line>
DirectoryIndex disabled
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule .* http://localhost:32801%{REQUEST_URI} [NE,proxy]
RequestHeader set X-Forwarded-Proto "https"
</syntaxhighlight>

== Well-Known unter beispiel.de ==

Damit die User-Accounts das Format @user:beispiel.de haben, der Server aber unter matrix.beispiel.de erreichbar ist, müssen noch folgende zwei Dateien unter der Domain beispiel.de abgelegt werden:

https://beispiel.de/.well-known/matrix/server
<syntaxhighlight lang=json line>
{
"m.server": "matrix.beispiel.de:443"
}
</syntaxhighlight>

https://beispiel.de/.well-known/matrix/client
<syntaxhighlight lang=json line>
{
"m.homeserver": {
"base_url": "https://matrix.beispiel.de"
},
"m.identity_server": {
"base_url": "https://vector.im"
}
}
</syntaxhighlight>

Für die muss noch der CORS-Header Access-Control-Allow-Origin "*" gesetzt werden, damit die Datei aus beliebigem Riot-Web im Browser abrufbar ist. Dazu in den Ordner .well-known/matrix/ folgende .htaccess anlegen:
<syntaxhighlight lang=apache line>
<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin "*"
</IfModule>
</syntaxhighlight>

Die Dokumentation dazu findet man unter https://matrix.org/docs/spec/server_server/r0.1.2#get-well-known-matrix-server und https://matrix.org/docs/spec/client_server/r0.5.0#get-well-known-matrix-client

== Update von Synapse ==

Normalerweise sollte es so gehen, mit pipenv:

<syntaxhighlight lang=shell>
cd ~/synapse
pipenv update --outdated || echo "there are packages to update"
pipenv update
systemctl --user restart synapse
</syntaxhighlight>

In seltenen Fällen gibt es Probleme bei den Abhängigkeiten, die schon wieder aktualisiert wurden, und nicht mehr kompatibel zum aktuellen Synapse sind.
Dann ist es zu empfehlen, Synapse mit der offiziellen poetry.lock Datei zu aktualisieren, um die Konflikte zu vermeiden.

mit poetry:
<syntaxhighlight lang=shell>
systemctl --user stop synapse.service
source ~/.venv/bin/activate
release=`curl -L https://api.github.com/repos/element-hq/synapse/releases/latest -s | jq -r '.tag_name'`
rm -Rf ~/synapse.src
git clone --depth 1 https://github.com/element-hq/synapse.git -b ${release} ~/synapse.src
cd ~/synapse.src
pip install poetry
poetry install --extras=postgres --extras=oidc
systemctl --user start synapse.service
</syntaxhighlight>

Wenn die Föderation für den Synapse Server aktiviert ist, kann mit dem [https://federationtester.matrix.org/ Matrix Federation Tester] die eigene Instanz auf die laufende Version geprüft werden. Als Server nicht matrix.example.org eingeben, sondern den öffentlichen Namen, wo auch die Benutzernamen drauf laufen, z.B. example.org

Ansonsten ist die laufende Version auch über die URL https://matrix.example.org/_synapse/admin/v1/server_version zu erfahren.

== Element-Web ==

Element-Web ist aus Server-Seite eine rein statische html+javascript-Kombination, daher:

* Account und Domain anlegen (separat von der Synapse-Domain)
* [https://github.com/element-hq/element-web/releases/latest aktuelles element-web release] .tgz herunterladen
* Symlink von htdocs-ssl auf entpacktes element-web-Verzeichnis
* config.sample.json in config.json kopieren und Matrix-Homeserver-Einträge anpassen
* Piwik aus config.json entfernen

== SAML mit Synapse ==

Synapse unterstützt mit Version 1.1.0 SAML. Dazu wie folgt vorgehen:

Das Paket xmlsec1 muss installiert sein:

<syntaxhighlight lang=shell>
$ xmlsec1 --version
xmlsec1 1.2.23 (openssl)
</syntaxhighlight>

Das Python-Paket pysaml2 installieren

<syntaxhighlight lang=shell>
cd ~/synapse
pipenv shell
pipenv install pysaml2
</syntaxhighlight>

In der homeserver.yaml die SAML-Direktiven einkommentieren, hier mit dem Beispiel eines SAML IdP unter https://login.beispiel.de/simplesaml/saml2/idp/metadata.php:

<syntaxhighlight lang=yaml line>
# Once SAML support is enabled, a metadata file will be exposed at
# https://<server>:<port>/_matrix/saml2/metadata.xml, which you may be able to
# use to configure your SAML IdP with. Alternatively, you can manually configure
# the IdP to use an ACS location of
# https://<server>:<port>/_matrix/saml2/authn_response.
#
saml2_config:
sp_config:
# point this to the IdP's metadata. You can use either a local file or
# (preferably) a URL.
metadata:
#local: ["saml2/idp.xml"]
remote:
- url: https://login.beispiel.de/simplesaml/saml2/idp/metadata.php
</syntaxhighlight>
Wichtig ist außerdem, dass die public_baseurl in der homeserver.yaml gesetzt ist, damit Synapse weiß, wie es erreichbar ist und dies in seine SP-Metadaten einbauen kann:
<syntaxhighlight lang=yaml line>
public_baseurl: https://matrix.beispiel.de/
</syntaxhighlight>
Die Service-Provider-Konfiguration als XML bekommt man von Synapse dann wie schon in der homeserver.yaml als Kommentar beschrieben, unter https://matrix.beispiel.de/_matrix/saml2/metadata.xml

Diese dann in den SAML-IdP-importieren und dann sollte der Single-Sign-On via SAML funktionieren.

== Federation Sender Worker für Synapse ==

Zur Parallelisierung bietet Synapse das Konzept "Worker" an, die spezifische Aufgaben übernehmen, damit der Hauptprozess diese nicht durchführen muss.

Details dazu: https://github.com/matrix-org/synapse/blob/master/docs/workers.md

Ein einfach einzurichtender Worker, der auch viel Last abfedert, ist der Federation Sender Worker, da das Verschicken des Federation-Traffics 10-50% der Serverlast ausmacht.

In der homeserver.yaml die Worker-Konfiguration aktivieren:
<syntaxhighlight lang=yaml line>
## Worker ##
worker_app: synapse.app.homeserver
daemonize: true
</syntaxhighlight>

und dazugehörige Listener (Abschnitt listener:) aktivieren:
<syntaxhighlight lang=yaml line>
# The TCP replication port
- port: 32892
bind_address: '127.0.0.1'
type: replication
# The HTTP replication port
- port: 32893
bind_address: '127.0.0.1'
type: http
resources:
- names: [replication]
</syntaxhighlight>

Funktionen, die Worker machen sollen, in der homeserver.yaml deaktivieren:
<syntaxhighlight lang=yaml line>
# disable federation sending here, use worker for it
send_federation: False
</syntaxhighlight>
Dann Verzeichnis synapse/workers anlegen, darin federation_sender.yaml:
<syntaxhighlight lang=yaml line>
worker_app: synapse.app.federation_sender

# The replication listener on the synapse to talk to.
worker_replication_host: 127.0.0.1
worker_replication_port: 32892
worker_replication_http_port: 32893

worker_daemonize: True
worker_pid_file: /home/pacs/xyz00/users/matrix/synapse/federation_sender.pid
worker_log_config: /home/pacs/xyz00/users/matrix/synapse/federation_sender.log.config
</syntaxhighlight>
.monitrc um worker erweitern:
<syntaxhighlight lang=shell line>
check process federation_sender with pidfile /home/pacs/xyz00/users/matrix/synapse/federation_sender.pid
start program "/bin/bash -c 'export VIRTUAL_ENV=$HOME/synapse/env && export PATH=$VIRTUAL_ENV/bin:$PATH && cd $HOME/synapse && synctl -w workers/federation_sender.yaml start'"
stop program "/bin/bash -c '/bin/kill $( cat $HOME/synapse/federation_sender.pid )'"
</syntaxhighlight>
Monit neu laden und synapse und federation_sender neustarten:

<syntaxhighlight lang=shell>
monit reload
monit restart all
</syntaxhighlight>

Nach Updates ebenfalls immer Hauptprozess und alle Worker neustarten

<syntaxhighlight lang=shell>
monit restart all
</syntaxhighlight>

== Sliding Sync Proxy ==
Zum Zeitpunkt dieser Anleitung werden aktiv neue Element Anwendungen (Element X) und ein neues Syncverfahren entwickelt um Matrix performanter und weniger ressourcenhungrig zu machen. Bei stärkerer Matrix Nutzung können die neuen Anwendungen besonders mobil schon eine große Entlastung sein.

Ende 2024 wurden grundlegende Funktionen direkt in Synapse implementiert. Der Proxy wird nicht länger weiterentwickelt und sollte deinstalliert werden (nicht vergessen die .well-known zurück zu ändern). Auch der 3rdparty Server [[Conduit]] bringt nativ Support für Sliding Sync.

== Links ==

* https://matrix.org/docs/projects/server/synapse
* https://github.com/element-hq/synapse
* https://github.com/element-hq/synapse/blob/master/INSTALL.md
* https://github.com/matrix-org/sliding-sync
* https://matrix.org/docs/spec/
* https://www.hostsharing.net/loesungen/matrix/
* https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/synapse
* https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/element

[[Kategorie:Messenger]]
[[Kategorie:Software]]
[[Kategorie:Eigene Daemons]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]

Matrix Synapse installieren

2026-08-04T08:54:40Z

Tim00: /* Installation von Synapse */

Der Matrix Server ''Synapse'', der sogenannte 'Homeserver', ist aktuell die einzige vollständige serverseitige Implementierung des Matrix-Protokolls.

{{Textkasten|gelb|Work in Progress|Leider funktioniert die Server-zu-Server-Kommunikation von Synapse hinter dem Apache-Proxy mit den genannten Rewrite-Rules nicht. Bitten Sie dazu den Service, Ihren Apache VHost individuell für den Matrix Server anzupassen.}}

Die hier beschriebene Installation benötigt bei Hostsharing die Paket-Option "RAM". Benötigt werden min. 512 MB. Im Managed Webspace ist diese Option kostenpflichtig: https://www.hostsharing.net/angebote/managed-webspace/ gebucht werden muss der RAM auch bei einem Managed-Server.
Wir empfehlen für den Betrieb einen ''Managed Server''.

Diese Anleitung beschreibt, wie man den Matrix-Homeserver Synapse auf der Managed Hosting Plattform von Hostsharing installieren kann. Dabei sind die User-IDs nach dem Schema @user:beispiel.de aufgebaut, der Homeserver an sich ist unter matrix.beispiel.de erreichbar.

== Vorbereitungen ==

Mit Hilfe von HSAdmin werden angelegt:
# Ein User als Service-User mit ''/bin/bash'' als Shell, zum Beispiel Beispiel: ''xyz00-matrix''
# Eine Domain mit ''xyz00-matrix'' als Domain-Administrator, zum Beispiel ''matrix.beispiel.de''
# Einen Postgresql-User ''xyz00_matrixuser'' mit Passwort ''meinPasswort''
# Eine Postgresql-Datenbank ''xyz00_matrixdb'' mit Datenbank-Owner ''xyz00_matrixuser''

Verwendeter IP-Port für den Server-Dienst:
# Synapse: localhost:32801

== Installation von Synapse ==

Installationsanleitung basierend auf https://matrix-org.github.io/synapse/latest/setup/installation.html#installing-as-a-python-module-from-pypi

Als User ''xyz00-matrix" ein Python3 virtualenv erstellen:

<syntaxhighlight lang="shell">
mkdir -p ~/synapse
cd ~/synapse
python -m venv .venv
</syntaxhighlight>

Synapse und Postgres-Dependencies installieren:

<syntaxhighlight lang="shell">
source ~/synapse/.venv/bin/activate
pip install pipenv
pipenv install matrix-synapse[postgres,oidc] lxml authlib
</syntaxhighlight>

Initiale Konfiguration mit richtigem server-name "beispiel.de" generieren, außerdem im laufenden Betrieb keine Statistiken an Matrix.org senden:

<syntaxhighlight lang="shell">
cd ~/synapse
pipenv run python -m synapse.app.homeserver --server-name beispiel.de --config-path homeserver.yaml --generate-config --report-stats=no
</syntaxhighlight>

== Konfiguration von Synapse ==

In die initial generierte Konfiguration muss noch die Port- und Datenbank-Konfiguration eingetragen werden:

Port: Innerhalb der listener-section den Port 8008 auf 32801 (wie initial definiert) ändern, alles andere beibehalten:

<syntaxhighlight lang=yaml line>
- port: 32801
tls: false
bind_addresses: ['::1', '127.0.0.1']
type: http
x_forwarded: true
</syntaxhighlight>

Postgres-Datenbank:
<syntaxhighlight lang=yaml line>
database:
# The database engine name
name: "psycopg2"
# Arguments to pass to the engine
args:
host: "localhost"
database: "xyz00_matrixdb"
user: "xyz00_matrixuser"
password: "meinPasswort"
cp_min: 5
cp_max: 10
</syntaxhighlight>

== Starten der Dienste ==

Der ''Synapse''-Dienst wird hier als Service-Unit im SystemD des Users eingetragen.

Lege dazu die folgende Datei an: ''~/.config/systemd/user/synapse.service'' mit dem Inhalt:
<syntaxhighlight lang="ini" line>
[Unit]
Description=Synapse

[Service]
Type=simple
WorkingDirectory=%h/synapse
Environment=LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so.2
ExecStart=pipenv run python -m synapse.app.homeserver --config-path=%h/synapse/homeserver.yaml

[Install]
WantedBy=default.target
</syntaxhighlight>

Durch Aufruf der folgenden Kommandos wird der Dienst aktiviert und gestartet:
<syntaxhighlight lang="shell" lines>
systemctl --user daemon-reload
systemctl --user enable synapse.service
systemctl --user start synapse.service
</syntaxhighlight>
== Einrichten des Apache VHost ==

Die ''~/doms/matrix.beispiel.de/.htaccess'' mit dem Editor der Wahl öffnen und
folgende Konfiguration einfügen:
<syntaxhighlight lang=apache line>
DirectoryIndex disabled
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule .* http://localhost:32801%{REQUEST_URI} [NE,proxy]
RequestHeader set X-Forwarded-Proto "https"
</syntaxhighlight>
== Well-Known unter beispiel.de ==

Damit die User-Accounts das Format @user:beispiel.de haben, der Server aber unter matrix.beispiel.de erreichbar ist, müssen noch folgende zwei Dateien unter der Domain beispiel.de abgelegt werden:

https://beispiel.de/.well-known/matrix/server
<syntaxhighlight lang=json line>
{
"m.server": "matrix.beispiel.de:443"
}
</syntaxhighlight>

https://beispiel.de/.well-known/matrix/client
<syntaxhighlight lang=json line>
{
"m.homeserver": {
"base_url": "https://matrix.beispiel.de"
},
"m.identity_server": {
"base_url": "https://vector.im"
}
}
</syntaxhighlight>

Für die muss noch der CORS-Header Access-Control-Allow-Origin "*" gesetzt werden, damit die Datei aus beliebigem Riot-Web im Browser abrufbar ist. Dazu in den Ordner .well-known/matrix/ folgende .htaccess anlegen:
<syntaxhighlight lang=apache line>
<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin "*"
</IfModule>
</syntaxhighlight>

Die Dokumentation dazu findet man unter https://matrix.org/docs/spec/server_server/r0.1.2#get-well-known-matrix-server und https://matrix.org/docs/spec/client_server/r0.5.0#get-well-known-matrix-client

== Update von Synapse ==

Normalerweise sollte es so gehen, mit pipenv:

<syntaxhighlight lang=shell>
cd ~/synapse
pipenv update --outdated || echo "there are packages to update"
pipenv update
systemctl --user restart synapse
</syntaxhighlight>

In seltenen Fällen gibt es Probleme bei den Abhängigkeiten, die schon wieder aktualisiert wurden, und nicht mehr kompatibel zum aktuellen Synapse sind.
Dann ist es zu empfehlen, Synapse mit der offiziellen poetry.lock Datei zu aktualisieren, um die Konflikte zu vermeiden.

mit poetry:
<syntaxhighlight lang=shell>
systemctl --user stop synapse.service
source ~/.venv/bin/activate
release=`curl -L https://api.github.com/repos/element-hq/synapse/releases/latest -s | jq -r '.tag_name'`
rm -Rf ~/synapse.src
git clone --depth 1 https://github.com/element-hq/synapse.git -b ${release} ~/synapse.src
cd ~/synapse.src
pip install poetry
poetry install --extras=postgres --extras=oidc
systemctl --user start synapse.service
</syntaxhighlight>

Wenn die Föderation für den Synapse Server aktiviert ist, kann mit dem [https://federationtester.matrix.org/ Matrix Federation Tester] die eigene Instanz auf die laufende Version geprüft werden. Als Server nicht matrix.example.org eingeben, sondern den öffentlichen Namen, wo auch die Benutzernamen drauf laufen, z.B. example.org

Ansonsten ist die laufende Version auch über die URL https://matrix.example.org/_synapse/admin/v1/server_version zu erfahren.

== Element-Web ==

Element-Web ist aus Server-Seite eine rein statische html+javascript-Kombination, daher:

* Account und Domain anlegen (separat von der Synapse-Domain)
* [https://github.com/element-hq/element-web/releases/latest aktuelles element-web release] .tgz herunterladen
* Symlink von htdocs-ssl auf entpacktes element-web-Verzeichnis
* config.sample.json in config.json kopieren und Matrix-Homeserver-Einträge anpassen
* Piwik aus config.json entfernen

== SAML mit Synapse ==

Synapse unterstützt mit Version 1.1.0 SAML. Dazu wie folgt vorgehen:

Das Paket xmlsec1 muss installiert sein:

<syntaxhighlight lang=shell>
$ xmlsec1 --version
xmlsec1 1.2.23 (openssl)
</syntaxhighlight>

Das Python-Paket pysaml2 installieren

<syntaxhighlight lang=shell>
cd ~/synapse
pipenv shell
pipenv install pysaml2
</syntaxhighlight>

In der homeserver.yaml die SAML-Direktiven einkommentieren, hier mit dem Beispiel eines SAML IdP unter https://login.beispiel.de/simplesaml/saml2/idp/metadata.php:

<syntaxhighlight lang=yaml line>
# Once SAML support is enabled, a metadata file will be exposed at
# https://<server>:<port>/_matrix/saml2/metadata.xml, which you may be able to
# use to configure your SAML IdP with. Alternatively, you can manually configure
# the IdP to use an ACS location of
# https://<server>:<port>/_matrix/saml2/authn_response.
#
saml2_config:
sp_config:
# point this to the IdP's metadata. You can use either a local file or
# (preferably) a URL.
metadata:
#local: ["saml2/idp.xml"]
remote:
- url: https://login.beispiel.de/simplesaml/saml2/idp/metadata.php
</syntaxhighlight>
Wichtig ist außerdem, dass die public_baseurl in der homeserver.yaml gesetzt ist, damit Synapse weiß, wie es erreichbar ist und dies in seine SP-Metadaten einbauen kann:
<syntaxhighlight lang=yaml line>
public_baseurl: https://matrix.beispiel.de/
</syntaxhighlight>
Die Service-Provider-Konfiguration als XML bekommt man von Synapse dann wie schon in der homeserver.yaml als Kommentar beschrieben, unter https://matrix.beispiel.de/_matrix/saml2/metadata.xml

Diese dann in den SAML-IdP-importieren und dann sollte der Single-Sign-On via SAML funktionieren.

== Federation Sender Worker für Synapse ==

Zur Parallelisierung bietet Synapse das Konzept "Worker" an, die spezifische Aufgaben übernehmen, damit der Hauptprozess diese nicht durchführen muss.

Details dazu: https://github.com/matrix-org/synapse/blob/master/docs/workers.md

Ein einfach einzurichtender Worker, der auch viel Last abfedert, ist der Federation Sender Worker, da das Verschicken des Federation-Traffics 10-50% der Serverlast ausmacht.

In der homeserver.yaml die Worker-Konfiguration aktivieren:
<syntaxhighlight lang=yaml line>
## Worker ##
worker_app: synapse.app.homeserver
daemonize: true
</syntaxhighlight>

und dazugehörige Listener (Abschnitt listener:) aktivieren:
<syntaxhighlight lang=yaml line>
# The TCP replication port
- port: 32892
bind_address: '127.0.0.1'
type: replication
# The HTTP replication port
- port: 32893
bind_address: '127.0.0.1'
type: http
resources:
- names: [replication]
</syntaxhighlight>

Funktionen, die Worker machen sollen, in der homeserver.yaml deaktivieren:
<syntaxhighlight lang=yaml line>
# disable federation sending here, use worker for it
send_federation: False
</syntaxhighlight>
Dann Verzeichnis synapse/workers anlegen, darin federation_sender.yaml:
<syntaxhighlight lang=yaml line>
worker_app: synapse.app.federation_sender

# The replication listener on the synapse to talk to.
worker_replication_host: 127.0.0.1
worker_replication_port: 32892
worker_replication_http_port: 32893

worker_daemonize: True
worker_pid_file: /home/pacs/xyz00/users/matrix/synapse/federation_sender.pid
worker_log_config: /home/pacs/xyz00/users/matrix/synapse/federation_sender.log.config
</syntaxhighlight>
.monitrc um worker erweitern:
<syntaxhighlight lang=shell line>
check process federation_sender with pidfile /home/pacs/xyz00/users/matrix/synapse/federation_sender.pid
start program "/bin/bash -c 'export VIRTUAL_ENV=$HOME/synapse/env && export PATH=$VIRTUAL_ENV/bin:$PATH && cd $HOME/synapse && synctl -w workers/federation_sender.yaml start'"
stop program "/bin/bash -c '/bin/kill $( cat $HOME/synapse/federation_sender.pid )'"
</syntaxhighlight>
Monit neu laden und synapse und federation_sender neustarten:

<syntaxhighlight lang=shell>
monit reload
monit restart all
</syntaxhighlight>

Nach Updates ebenfalls immer Hauptprozess und alle Worker neustarten

<syntaxhighlight lang=shell>
monit restart all
</syntaxhighlight>

== Sliding Sync Proxy ==
Zum Zeitpunkt dieser Anleitung werden aktiv neue Element Anwendungen (Element X) und ein neues Syncverfahren entwickelt um Matrix performanter und weniger ressourcenhungrig zu machen. Bei stärkerer Matrix Nutzung können die neuen Anwendungen besonders mobil schon eine große Entlastung sein.

Ende 2024 wurden grundlegende Funktionen direkt in Synapse implementiert. Der Proxy wird nicht länger weiterentwickelt und sollte deinstalliert werden (nicht vergessen die .well-known zurück zu ändern). Auch der 3rdparty Server [[Conduit]] bringt nativ Support für Sliding Sync.

== Links ==

* https://matrix.org/docs/projects/server/synapse
* https://github.com/element-hq/synapse
* https://github.com/element-hq/synapse/blob/master/INSTALL.md
* https://github.com/matrix-org/sliding-sync
* https://matrix.org/docs/spec/
* https://www.hostsharing.net/loesungen/matrix/
* https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/synapse
* https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/element

[[Kategorie:Messenger]]
[[Kategorie:Software]]
[[Kategorie:Eigene Daemons]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]

Prozessmanagement mit systemd im Userspace

2026-08-03T10:31:07Z

Tim00: /* RAM- und CPU-Limits */

== Über systemd ==
''systemd'' ist seit einigen Jahren das Init-System aller gängigen Linux-Distributionen. Der ''init''-Prozess hat im laufenden System die Prozessnummer "1". Er verwaltet alle anderen Prozesse als Kind-Prozesse.

Auch ein normaler Account ohne besondere Privilegien kann systemd nutzen, um Prozesse im Userspace zu starten und zu kontrollieren. Auf der Hostsharing Managed Operations Platform kann jeder Account mit einer gültigen Login-Shell Dienste unter der Kontrolle von systemd starten.

Im Hostsharing Managed Webspace ist es zwingend, systemd als Prozessmonitor für eigene Serverdienste zu nutzen; auf einem Hostsharing Managed Server ist es die empfohlene Vorgehensweise ("Best practice").

== Eigene Serverdienste mit systemd ==

Die systemd-Konfiguration wird in dem Verzeichnis des Benutzers eingerichtet, unter dem die Anwendung laufen soll.
In diesem Beispiel soll die Anwendung GotoSocial unter der Benutzerkennung von ''xyz00-service'' laufen.
Nachdem die Anwendung im Benutzer ''xyz00-service'' installiert wurde, erfolgt nun die Konfiguration von systemd in demselben Benutzer.

Benutzer, die systemd steuern sollen, müssen über eine gültige Shell verfügen, so dass man sich per ''ssh'' oder vom Paketadmin mit dem Befehl ''sudo -i -u xyz00-service'' anmelden kann.
Die Umgebungsvariable ''XDG_RUNTIME_DIR'' sollte im Environment des Users gesetzt sein, wenn man erfolgreich angemeldet ist. Das testet man mit

<syntaxhighlight lang="bash">
echo $XDG_RUNTIME_DIR
</syntaxhighlight>

Die Ausgabe sollte sein:

<syntaxhighlight lang="bash">
xyz00-service@h01:~$ echo $XDG_RUNTIME_DIR
/run/user/112345
xyz00-service@h01:~$
</syntaxhighlight>

Dabei wird statt ''112345'' eine andere Zahl erscheinen. Diese Zahl ist die numerische User-Id des Users ''xyz00-service'' im System.

=== systemd Units ===

Die systemd-Units für einen User werden im Verzeichnis ''$HOME/.config/systemd/user/'' verwaltet. Dieser Pfad ist fest vorgegeben. Der Pfad muss bei einem neuen Benutzer angelegt werden.

<syntaxhighlight lang="bash">
mkdir -p $HOME/.config/systemd/user
</syntaxhighlight>

In diesem Verzeichnis wird für jeden Service eine Datei mit der Endung ''.service'' angelegt. In diesem Beispiel ist dies eine GotoSocial-Instanz. GotoSocial ist ein einfaches Binärprogramm, das in der Programmiersprache ''Go'' programmiert ist.

<syntaxhighlight lang="ini" line>
[Unit]
Description=GotoSocial Service
#After=my-redis.service

[Service]
Type=simple
WorkingDirectory=%h/gotosocial
Environment="PATH=/usr/local/bin:/usr/bin:/bin"
ExecStart=%h/gotosocial/gotosocial --config-path %h/gotosocial/config.yaml server start
StandardOutput=append:%h/var/gotosocial.log
StandardError=inherit
Restart=always
PrivateTmp=true

[Install]
WantedBy=default.target
</syntaxhighlight>

Folgende Eigenschaften sind einstellbar:

; After: Hier kann eingestellt werden, welcher Dienst bereits laufen muss, bevor dieser Dienst gestartet wird. Wenn GotoSocial eine Redis-Instanz benötigt, könnte das entsprechend eingestellt werden.
; Type=simple : ''simple'' ist die Voreinstellung und kann weggelassen werden. Evtl. braucht man auch ''forking'', wenn ein Dienst als Daemon im Hintergrund startet. Wenn man die Wahl hat, sollte man den Dienst immer im Vordergrund starten und nicht forken.
; WorkingDirectory : ist das Verzeichnis, in dem der Dienst gestartet wird. %h ist in dieser Datei eine Abkürzung für das Home-Verzeichnis des Users.
; Environment : Hier wird die Variable ''PATH'' definiert. Man kann mehrere Einträge des Namens ''Environment'' eintragen und bei Bedarf eine beliebige Anzahl von Environment-Variablen definieren.
; ExecStart : Das Programm, das als Dienst ausgeführt wird. Man kann eine komplette Kommandozeile angeben.
; StandardOutput : Eine Log-Datei, in die die Standardausgabe des laufenden Dienstes geschrieben wird.
; StandardError : Entsprechend zu ''StandardOutput''. Mit ''inherit'' wird die Datei von ''StandardOutput'' geerbt.
; Restart=always : Der Dienst soll grundsätzlich neu gestartet werden, wenn der Prozess unerwartet beendet wird.
; PrivateTmp=true : ''/tmp'' und ''/var/tmp'' werden temporär im Namespace gemountet, so dass sie nicht mit anderen Prozessen geteilt werden.
; WantedBy : sollte im Usermodus von systemd meistens ''default.target'' sein. Andere Targets sind z.B. ''base.target'' oder ''timers.target''. Für eine komplette Liste: <code>systemctl list-units --user --type=target</code>

==== RAM- und CPU-Limits ====

Auf Wunsch kann man die RAM- und CPU-Ressourcen für den Dienst begrenzen. Dazu trägt man weitere Eigenschaften im Abschnitt ''Service'' ein:

<syntaxhighlight lang="ini" line>
[Service]
...
MemoryAccounting=true
CPUAccounting=true
MemoryHigh=512M
MemoryMax=768M
MemorySwapMax=128M
CPUQuota=50%
</syntaxhighlight>

; MemoryHigh : Weiches RAM-Limit, das ggf. überschritten werden kann, wenn es unvermeidlich ist.
; MemoryMax : Hartes, absolutes RAM-Limit.
; MemorySwapMax: Wenn wir den RAM begrenzen, sollten wir auch den Swap begrenzen, da ansonsten die SSDs langfristig Schaden nehmen bei zu viel Swapping
; CPUQuota : Maximale Belegung eines CPU-Threads in Prozent. Werte über 100% sind sinnvoll, wenn mehr als ein CPU-Thread verfügbar ist.

==== Ausführliche Dokumentation der Direktiven ====
Eine ausführliche Dokumentation der Direktiven findet sich hier:

https://www.freedesktop.org/software/systemd/man/latest/systemd.directives.html

=== systemd Unit starten und stoppen ===

Nachdem die systemd-Unit definiert ist, soll der Dienst gestartet werden.
Für die Verwaltung des Dienstes stehen die folgenden Kommandos zur Verfügung:

==== Reload ====

<syntaxhighlight lang="bash">
systemctl --user daemon-reload
</syntaxhighlight>

Die Konfigurationsdateien im Verzeichnis ''$HOME/.config/systemd/user/'' werden neu eingelesen. Dieses Kommando ist nach jeder Änderung einer ''.service''-Datei nötig.

==== Start und Stopp ====

<syntaxhighlight lang="bash">
systemctl --user start gotosocial.service
</syntaxhighlight>

bzw.

<syntaxhighlight lang="bash">
systemctl --user stop gotosocial.service
</syntaxhighlight>

sind die Kommandos zum Starten und Beenden des Dienstes.

==== Enable und Disable ====

Wenn ein Dienst nach einem Reboot des Servers automatisch gestartet werden soll, muss er aktiviert werden:

<syntaxhighlight lang="bash">
systemctl --user enable gotosocial.service
</syntaxhighlight>

Wenn er nicht automatisch nach einem Reboot starten soll, muss der Dienst entsprechend deaktiviert werden:

<syntaxhighlight lang="bash">
systemctl --user disable gotosocial.service
</syntaxhighlight>

sind die Kommandos, die den Dienst für einen Reboot des Servers aktivieren bzw. deaktivieren.

==== Status ====

<syntaxhighlight lang="bash">
systemctl --user status
</syntaxhighlight>

oder

<syntaxhighlight lang="bash">
systemctl --user status gotosocial.service
</syntaxhighlight>

zeigen den Status aller Dienste des Users bzw. eines bestimmten Dienstes an.

=== Ressourcen einer systemd Unit beschränken ===

Mit den folgenden Befehlen können die zur Verfügung stehenden Ressourcen einer systemd Unit beschränkt werden:

<syntaxhighlight lang="bash">
systemctl --user set-property gitea.service MemoryMax=500M
systemctl --user set-property gitea.service CPUQuota=25%
systemctl --user set-property gitea.service TasksMax=100
systemctl --user daemon-reload
</syntaxhighlight>

== Zeitgesteuerte Ausführung mit systemd ==

Mit Hilfe von systemd können auch wiederkehrende Aufgaben zeitgesteuert automatisiert werden.
Cronjobs, die früher für solche Zwecke benutzt wurden, lassen sich also durch systemd Units ersetzen.
Neben dem »service-file« wird dazu eine weitere Unit, nämlich ein »timer-file«, mit der Endung ».timer« angelegt und aktiviert.

=== Einrichten des »service-files« ===

<syntaxhighlight lang=bash line>
$ cat $HOME/.config/systemd/user/my-cleanup.service

[Unit]
Description=My Cleanup Service

[Service]
Type=oneshot
ExecStart=%h/bin/cleanup-script

ExecStopPost=/usr/local/bin/hs-notify-unit-failure %N %H %u $EXIT_CODE $SERVICE_RESULT %u
</syntaxhighlight>

Bemerkung: das Skript hs-notify-unit-failure schickt bei einem Fehler des Hauptskripts eine E-Mail an den aktuellen Benutzer, die über .forward oder über .procmailrc auch an eine andere E-Mail Adresse weitergeleitet werden kann.

Alternativ kann auch eine Umgebungsvariable (z.B. MAILTO) gesetzt werden, in der mehrere E-Mailadressen mit Komma getrennt sein dürfen:

<syntaxhighlight lang=bash line>
Environment="MAILTO=email1@example.org,alarm@example.org"
ExecStopPost=/usr/local/bin/hs-notify-unit-failure %N %H %u $EXIT_CODE $SERVICE_RESULT $MAILTO
</syntaxhighlight>

=== Testen ===

<syntaxhighlight lang=bash>
$ systemctl --user start my-cleanup.service
</syntaxhighlight>

=== Einrichten des »timer-files« ===

<syntaxhighlight lang=bash>
$ cat $HOME/.config/systemd/user/my-cleanup.timer

[Unit]
Description=Daily My Cleanup Timer

[Timer]
OnCalendar=daily
RandomizedDelaySec=3600
Persistent=true

[Install]
WantedBy=timers.target
</syntaxhighlight>

Der RandomizedDelay bewirkt, dass der Prozess zufällig im Zeitraum einer Stunde gestartet wird.
Wenn mehrere Timer-Aufgaben täglich (daily) auf einem System gestartet werden, verhindert diese Einstellung, dass alle Prozesse exakt zur gleichen Zeit starten und das System eventuell überlasten.

Die zufällige Verzögerung sollte in einem sinnvollen Verhältnis zur Frequenz der Zeitsteuerung erfolgen.
Bei täglich ausgeführten Aufgaben mag eine Stunde (3600 Sekunden) sinnvoll sein.
Bei Aufgaben, die stündlich ausgeführt werden, wählt man eine kürzere Verzögerung, zum Beispiel fünf Minuten.

Die Syntax der Datei lässt sich mit diesem Befehl prüfen:

<syntaxhighlight lang=bash>
systemd-analyze verify $HOME/.config/systemd/user/my-cleanup.timer
</syntaxhighlight>

Einzelne Kalendereinträge lassen sich mit Erklärung ausgeben:

<syntaxhighlight lang=bash>
systemd-analyze calendar '*:0/2'
</syntaxhighlight>

Eine ausführliche Dokumentation der Direktiven findet sich hier:

https://www.freedesktop.org/software/systemd/man/latest/systemd.timer.html

=== Aktivieren der zeitgesteuerten Ausführung ===

Der Timer muss noch aktiviert und gestartet werden:

<syntaxhighlight lang=bash>
$ systemctl --user enable my-cleanup.timer --now
</syntaxhighlight>

=== Übersicht über die Timer im aktuellen User ===

<syntaxhighlight lang=bash>
$ systemctl --user list-timers --all
</syntaxhighlight>

== RAM Kontingent eines Webspace ==

Den aktuell belegten RAM eines Webspace ''xyz00'' kann man sich mit dem Befehl

<syntaxhighlight lang="bash">
systemctl status pacs-xyz00.slice
</syntaxhighlight>

ansehen.

Etwa in der fünften Zeile der Ausgabe findet man eine Angabe der Form:

<syntaxhighlight lang="bash">
Memory: 58.4M (max: 14.8G available: 14.8G)
</syntaxhighlight>

Hier sind aktuell 58,4 Megabyte RAM genutzt, es sind 14,8 Gigabyte RAM für den Webspace verfügbar. Der verfügbare RAM ist das gebuchte Kontingent. Das gebuchte Kontigent wird im Shared Hosting deutlich kleiner sein.

Das RAM Kontingent wird in Schritten von jeweils 128 Ḿegabyte gebucht. Änderungen des RAM Kontingents für einen Webspace nimmt der Service unter [mailto:service@hostsharing.net service@hostsharing.net] entgegen, wie es bei anderen Paketoptionen die Vorgehensweise ist.

== Beliebte Fehler ==
=== Fehler: Failed to connect to bus: No such file or directory ===

Wenn ich einen systemctl Befehl ausführe, kommt:

<syntaxhighlight lang="bash">
systemctl --user daemon-reload
Failed to connect to bus: No such file or directory
</syntaxhighlight>

Bitte prüfen, ob Lingering für den Benutzer aktiviert ist. Dazu muss im Hsadmin beim Benutzer die Login Shell <code>/bin/bash</code> eingetragen sein. Falls das bereits der Fall ist, ist es vielleicht ein sehr alter Benutzer. Dann bitte kurz auf <code>/usr/bin/passwd</code> stellen, und dann wieder auf <code>/bin/bash</code> zurückstellen.

Evtl. hilft es auch, die Umgebungsvariable XDG_RUNTIME_DIR zu setzen:

<syntaxhighlight lang="bash">
export XDG_RUNTIME_DIR=/run/user/$UID
</syntaxhighlight>

Das kann auch in die Datei <code>$HOME/.profile</code> eingefügt werden.

=== Fehler: Beim Starten passiert nichts ===

Ich hatte das Problem bei einem Redis Dienst. Er stoppte innerhalb von Millisekunden. In der Log Datei stand nichts.

Ursache: in der Service Datei war bei <code>WorkingDirectory</code> ein nicht existierendes Verzeichnis eingetragen.

= weiterführende Links =

* https://www.freedesktop.org/software/systemd/man/latest/systemd.directives.html
* https://www.freedesktop.org/software/systemd/man/latest/systemd.timer.html
* https://documentation.suse.com/smart/systems-management/html/systemd-working-with-timers/index.html#systemd-timer-catchup
* https://wiki.archlinux.org/title/Systemd/Timers#As_a_cron_replacement

----
[[Kategorie:systemd]]
[[Kategorie:Eigene Daemons]]

ListMonk installieren

2026-08-01T21:32:59Z

Tim00: /* Links */

== ListMonk ==
ListMonk [https://listmonk.app/] ist ein Newsletter-Manager zum Selbsthosten, und steht unter der Open Source Lizenz AGPLv3.

Monk hat in diesem Fall nichts mit einem Mönch zu tun, sondern ist eine versteckte Anspielung auf Monkey, da ListMonk eine Alternative zu MailChimp (Chimpanse) ist.

'''Achtung:''' Listmonk wirbt damit, [https://github.com/knadh/listmonk/blob/master/README.md Newsletter- und Mailinglisten-Manager] zu sein. Laut [https://github.com/knadh/listmonk/issues/1355 Fehlerbericht] ist das Tool aber lediglich für Einweg-Kommunikation (Newsletter) vorgesehen.

== Zur Technik ==
ListMonk ist in Go geschrieben, und wird als ein einziges Binary (Programm) installiert. Man muss im Shared Webspace bei Hostsharing einen Service dazu buchen, oder man setzt es auf einem Managed Server von Hostsharing ein.

Im Hintergrund wird PostgreSQL als Datenbank benutzt.

ListMonk bietet Anmeldungen per Double-Opt-In, und es gibt auch eine API für die Integration mit CRM/ERP Systemen (https://listmonk.app/docs/apis/apis/).

== Zur Installation ==
Die Installation ist recht einfach: https://listmonk.app/docs/installation/

* Das Programm beispielsweise [https://github.com/knadh/listmonk/releases auf Github herunterladen] und entpacken
* Vorher den Hostsharing Service um eine freie Port Nummer fragen.
* Eine Datenbank anlegen
* Mit [[systemd]] wird das Programm als Dienst gestartet. Hierzu wird das Verzeichnis <code>~/.config/systemd/user/</code> erstellt und eine .service Datei angelegt:

<syntaxhighlight lang="ini" line>
[Unit]
Description=Listmonk

[Service]
Type=simple
Restart=on-abort
WorkingDirectory=/home/pacs/xyz00/users/newsletter
# --config mit vollständigem Pfad zum Configfile falls nicht im WorkingDirectory
ExecStart=/home/pacs/xyz00/users/newsletter/bin/listmonk

[Install]
WantedBy=default.target
</syntaxhighlight>

* Start und aktivieren von Autostart mittels <code>systemctl enable --now --user listmonk</code>
* Beispiel Webserver--Konfiguration unter <code>doms/meine-domain/htdocs-ssl/.htaccess</code>

<syntaxhighlight lang="apache" line>
DirectoryIndex disabled
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RequestHeader set X-Forwarded-Proto "https"
# Port entsprechend der config.toml nach Absprache mit Service s.o.
RewriteRule ^(.*) http://127.0.0.1:9000/$1 [proxy,last]
</syntaxhighlight>

=== Installation mit Ansible Skript ===
Es gibt ein Ansible Skript für Hostsharing [https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/listmonk], das die Installation automatisiert vornimmt, und schon den SMTP und POP Zugang konfiguriert.

Dort kann man sicherlich auch Feinheiten der Installation abschauen, wenn man ListMonk manuell installieren will.

== Zur Bedienung ==

Hier ist ein Bildschirmfoto zur Einrichtung von SMTP für den Versand der E-Mails:

[[Datei:ListMonk SMTPSetup.png]]

Hier ist ein Bildschirmfoto zur Generierung des Formulars zur Anmeldung für einen Newsletter:

[[Datei:ListMonk SubscriptionForm.png]]

== Links ==

* https://listmonk.app/ Projektseite
* https://github.com/knadh/listmonk ListMonk auf Github
* https://codeberg.org/tpokorra/hs.ansible.app.listmonk Ansible Rolle für Hostsharing

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]
[[Kategorie:Software]]
[[Kategorie:Mailinglisten]]
[[Kategorie:Newsletterversand]]
[[Kategorie:E-Mail]]

ListMonk installieren

2026-08-01T21:32:44Z

Tim00: aktualisierter Link zur Ansible Rolle

== ListMonk ==
ListMonk [https://listmonk.app/] ist ein Newsletter-Manager zum Selbsthosten, und steht unter der Open Source Lizenz AGPLv3.

Monk hat in diesem Fall nichts mit einem Mönch zu tun, sondern ist eine versteckte Anspielung auf Monkey, da ListMonk eine Alternative zu MailChimp (Chimpanse) ist.

'''Achtung:''' Listmonk wirbt damit, [https://github.com/knadh/listmonk/blob/master/README.md Newsletter- und Mailinglisten-Manager] zu sein. Laut [https://github.com/knadh/listmonk/issues/1355 Fehlerbericht] ist das Tool aber lediglich für Einweg-Kommunikation (Newsletter) vorgesehen.

== Zur Technik ==
ListMonk ist in Go geschrieben, und wird als ein einziges Binary (Programm) installiert. Man muss im Shared Webspace bei Hostsharing einen Service dazu buchen, oder man setzt es auf einem Managed Server von Hostsharing ein.

Im Hintergrund wird PostgreSQL als Datenbank benutzt.

ListMonk bietet Anmeldungen per Double-Opt-In, und es gibt auch eine API für die Integration mit CRM/ERP Systemen (https://listmonk.app/docs/apis/apis/).

== Zur Installation ==
Die Installation ist recht einfach: https://listmonk.app/docs/installation/

* Das Programm beispielsweise [https://github.com/knadh/listmonk/releases auf Github herunterladen] und entpacken
* Vorher den Hostsharing Service um eine freie Port Nummer fragen.
* Eine Datenbank anlegen
* Mit [[systemd]] wird das Programm als Dienst gestartet. Hierzu wird das Verzeichnis <code>~/.config/systemd/user/</code> erstellt und eine .service Datei angelegt:

<syntaxhighlight lang="ini" line>
[Unit]
Description=Listmonk

[Service]
Type=simple
Restart=on-abort
WorkingDirectory=/home/pacs/xyz00/users/newsletter
# --config mit vollständigem Pfad zum Configfile falls nicht im WorkingDirectory
ExecStart=/home/pacs/xyz00/users/newsletter/bin/listmonk

[Install]
WantedBy=default.target
</syntaxhighlight>

* Start und aktivieren von Autostart mittels <code>systemctl enable --now --user listmonk</code>
* Beispiel Webserver--Konfiguration unter <code>doms/meine-domain/htdocs-ssl/.htaccess</code>

<syntaxhighlight lang="apache" line>
DirectoryIndex disabled
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RequestHeader set X-Forwarded-Proto "https"
# Port entsprechend der config.toml nach Absprache mit Service s.o.
RewriteRule ^(.*) http://127.0.0.1:9000/$1 [proxy,last]
</syntaxhighlight>

=== Installation mit Ansible Skript ===
Es gibt ein Ansible Skript für Hostsharing [https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/listmonk], das die Installation automatisiert vornimmt, und schon den SMTP und POP Zugang konfiguriert.

Dort kann man sicherlich auch Feinheiten der Installation abschauen, wenn man ListMonk manuell installieren will.

== Zur Bedienung ==

Hier ist ein Bildschirmfoto zur Einrichtung von SMTP für den Versand der E-Mails:

[[Datei:ListMonk SMTPSetup.png]]

Hier ist ein Bildschirmfoto zur Generierung des Formulars zur Anmeldung für einen Newsletter:

[[Datei:ListMonk SubscriptionForm.png]]

== Links ==

* https://listmonk.app/ Projektseite
* https://github.com/knadh/listmonk ListMonk auf Github
* https://codeberg.org/tpokorra/hs.ansible.app.listmonk Ansible Rolle für Hostsharing von Timotheus Pokorra

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]
[[Kategorie:Software]]
[[Kategorie:Mailinglisten]]
[[Kategorie:Newsletterversand]]
[[Kategorie:E-Mail]]

Keycloak installieren

2026-07-14T09:47:09Z

Tim00: /* Admin User einrichten */

== Allgemein ==

Keycloak [http://www.keycloak.org/] ist eine Open Source Lösung, die ein Single Sign On für verschiedene Anwendungen ermöglicht. Dabei ermöglicht es sowohl die Identitätsverwaltung als auch Zugriffsmanagement.

Es kann die Benutzer entweder aus einem existierenden Verzeichnisdienst (LDAP, Active Directory) auslesen, oder die Gruppen und Benutzer auch selber verwalten.

== Technische Details ==
Keycloak ist in Java geschrieben. Bisher lief es in einem Wildfly Server, aber seit Version 17 (Februar 2022) benutzt es Quarkus, welches ein leichtgewichtiges Java Framework ist.

Es gibt ein Ansible Skript, das die Installationsschritte für Keycloak automatisiert durchführt.

Die Quellen für das Ansible Skript können hier eingesehen werden: [https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/keycloak]

== Installation ==
Was das Ansible Skript macht, lässt sich mit diesen Worten beschreiben:

* Es wird ein Linux Benutzer eingerichtet.
* Es wird eine Postgresql Datenbank eingerichtet.
* Es wird eine Domain aufgeschaltet.
* Es wird Keycloak als Zip Datei heruntergeladen, z.B. [https://github.com/keycloak/keycloak/releases/download/17.0.0/keycloak-17.0.0.zip], und ins Verzeichnis $HOME/keycloak-17.0.0 entpackt.
* Dann werden ein paar Konfigurationen an der Datei <code>keycloak/conf/keycloak.conf</code> vorgenommen, um die Postgresql Datenbank einzurichten, und um den Proxymodus auf edge zu setzen und den Hostname zu setzen.
* Nun wird die Keycloak Instanz initialisiert, mit dem Befehl: <code>keycloak/bin/kc.sh --cache=local --profile=prod build</code>. Hierbei verhindert die Einstellung für den Cache, dass Keycloak versucht über das Netzwerk Verbindungen zu anderen Instanzen herzustellen.
* Es muss der Server einmal gestartet werden, während der Admin Benutzer mit Passwort in einer Umgebungsvariable gesetzt ist, damit der Benutzer eingerichtet wird.
* Es wird Monit konfiguriert, um den Keycloak Service zu starten, der auf einem internen Port lauscht.
* Es wird der Apache in der htaccess Datei konfiguriert, damit die aufgeschaltete Domain über Proxy auf den Keycloak Dienst verweist. Dabei ist wichtig, dass der Java Prozess mitbekommt, dass die Seite über https läuft. Dazu wird in der htaccess Datei der Wert X-Forwarded-Proto auf https gesetzt.

=== Keycloak mit Systemd ===

Sofern <code>linger</code> für den User schon verfügbar ist, kann auch Systemd verwendet werden. Zudem sollte im Vorfeld <code>export XDG_RUNTIME_DIR=/run/user/$UID</code> ausgeführt werden um Zugriff auf die Befehle zu erhalten.

Beispiel einer Systemd Konfiguration in <code>.config/systemd/user/keycloak.service</code>
<syntaxhighlight lang=ini line>
[Unit]
Description=Keycloak

[Service]
Type=simple
Restart=on-abort
WorkingDirectory=/home/pacs/xyz00/users/login/keycloak
Environment=PROXY_ADDRESS_FORWARDING=true

# Für den ersten Start, um den Adminuser zu setzen
#Environment=KEYCLOAK_ADMIN=changeme
#Environment=KEYCLOAK_ADMIN_PASSWORD=changeme

# Die Option cache=local kann auch an anderer Stelle gesetzt werden.
# Hauptsache sie taucht auf, da es sonst zu Performance-Problemen wie
# Timeouts kommen kann.
ExecStart=/home/pacs/xyz00/users/login/keycloak/latest/bin/kc.sh start --cache=local

[Install]
# Achtung: multiuser.target würde hier zu Problemen führen
WantedBy=default.target
</syntaxhighlight>
== Beispiel einer Einrichtung ==
Diese Anleitung steht auch als [https://youtu.be/bmOp8epgxsM Video auf Youtube] zur Verfügung.

* Auf https://keycloak.example.org/admin anmelden.

=== Admin User einrichten ===
* Der auf der Kommandozeile angelegte Benutzer ist nur vorübergehend gültig.
* Bitte einen permanenten Admin User anlegen, mit den entsprechenden Rollen (Realm Role: admin und default-roles-master) ausstatten
* Login mit permanentem Admin durchführen
* Dann den temporären Benutzer löschen.

=== Realm einrichten ===
* Es soll nicht mit der master Realm gearbeitet werden, sondern sollte eine weitere Realm eingerichtet werden, z.B. "MeineFirma"
* Diese neue Realm wird dann ausgewählt

=== Benutzer einrichten ===
* Innerhalb der neuen Realm wird dann ein neuer Benutzer angelegt.
* Beim neuen Benutzer kann ausgewählt werden, dass die E-Mail bereits bestätigt ist.
* Nach dem Speichern des Benutzers kann man dann auch bei Credentials das Passwort setzen. Wenn es nur temporär ist, muss der Benutzer es bei der ersten Anmeldung ändern.
* Nun kann man sich als Administrator abmelden und sich als der Benutzer anmelden, auf https://keycloak.example.org/realms/MeineFirma/account/#/
** Achtung: in anderen Anleitungen heißen die URLs /auth/realms usw, aber auth scheint nicht mehr Teil der Standardeinrichtung zu sein.
* Als Benutzer kann man sein Passwort ändern.
* Wieder abmelden, und wieder als Administrator anmelden.

=== Client einrichten ===
* Achtung: erst aus der Master Realm in die vorher angelegte Realm wechseln, z.B. "MeineFirma"
* Nun sollte ein Client hinzugefügt werden, also eine beliebige Anwendung, die mit Keycloak zusammenarbeiten soll
** Als Client-Protokoll wählt man "OpenID Connect"
** Die Client-ID kann so aussehen: my-nextcloud
** Anwählen: 'Client Authentication', um den OID Typ auf 'Confidential Access Type' zu setzen.
** Anwählen: 'Standard Flow', 'Implicit Flow' und 'Direct Access Grants'
* Eine Root Url eingeben, z.B. https://nextcloud.example.org
* Eine Valid Redirect URI eingeben, z.B. https://nextcloud.example.org/*
* Gültige Web Origins eingeben, z.B. https://nextcloud.example.org
* Speichern
* Unter Roles eine neue Rolle mit Namen admin anlegen.
* Wieder unter den Client Nextcloud gehen, und bei "Client Scopes" klicke auf "my-nextcloud-dedicated", und wähle dort "Add predefined Mapper". Wähle "client roles", und klicke auf "Add". Dann diesen neuen Mapper "client roles" Bearbeiten, und Client ID auf "my-nextcloud" setzen, und "Token Claim Name" mit "roles" setzen, und "Add to userinfo" auf "ON" stellen. Dann Speichern.
* Dann zu nochmal zu Client Scopes (im Client) gehen, und auf "my-nextcloud-dedicated" klicken, und dort im Reiter "Scope" die Option "Full Scope Allowed" abschalten.

* Dann unter Configure / Realm Settings, in General, bei Endpoints auf "OpenID Endpoint Configuration" klicken, dann wird eine Seite geöffnet, auf dieser URL: https://keycloak.example.org/realms/MeineFirma/.well-known/openid-configuration; diese Seite offen halten, wir brauchen daraus die Daten für die Nextcloud Einrichtung

=== Nextcloud einrichten (Einfach) ===
* Als Administrator anmelden, und bei den Apps die App [https://apps.nextcloud.com/apps/sociallogin "Social Login"] installieren.
* Dann bei Einstellungen, unter Verwaltung, Social Login, die gewünschten Einstellungen vornehmen.
* Es sollte ein Kreuz sein bei: Anlegen eines Kontos verhindern, wenn die E-Mail-Adresse bereits von einem anderen Konto verwendet wird.
* Es sollte ein Kreuz sein bei: Verhindern, dass sich Benutzer ohne gemappte Gruppe anmelden können.
* Speichern
* Dann bei "Benutzerdefinierte OpenID Connect Anbindung" auf das Plus klicken
* Nun die Daten aus der "OpenID Endpoint Configuration" (siehe oben) übernehmen: Authorize URL, Token URL, User info URL, Logout URL
* Client ID: nc (Name des Clients in Keycloak)
* Client Secret: hier kommt das Secret hinein, das in Keycloak im Client unter Credentials "Client Secret" zu finden ist. Das kann über die Zwischenablage kopiert werden.
* Scope: openid
* Speichern

=== Nextcloud einrichten (Fortgeschritten) ===
Die folgende App wird mit Rücksicht auf Keycloak entwickelt und hat daher eine bessere Kompatibilität als das Beispiel oben. Allerdings gibt es hierfür keine Optionen in der Cloud, stattdessen wird die <code>config.php</code> direkt bearbeitet.

==== Plugin-Installation ====

# Als Administrator die App [https://github.com/pulsejet/nextcloud-oidc-login "Nextcloud OIDC Login"] installieren
# Die Nextcloud Konfigurationsdatei unter <code>pfad/zur/nextcloud/config/config.php</code> öffnen und basierend auf dem Readme der App (Link aus Schritt #1) befüllen. Das könnte so aussehen:
<syntaxhighlight lang=php line>
'oidc_login_client_id' => 'nextcloud',
'oidc_login_client_secret' => 'bSIPDNUyTQpxmfOpXdwyoBP8nZDQZVuL', // Client Reiter "Credentials" in Keycloak
'oidc_login_provider_url' => 'https://login.mydomain.de/realms/myrealm',
'oidc_login_end_session_redirect' => true,
'oidc_login_logout_url' => 'https://cloud.mydomain.de/index.php/apps/oidc_login/oidc',
'oidc_login_auto_redirect' => true, // hiermit wird das Login-Formular übergangen um Leute weniger zu verwirren
'oidc_login_redir_fallback' => false,
'oidc_login_disable_registration' => false, // Nextcloud soll neue Keycloak Accounts akzeptieren
'oidc_create_groups' => true,
'oidc_login_attributes' => array(
'id' => 'preferred_username',
'mail' => 'email',
'groups' => 'ownCloudGroups',
'is_admin' => 'ownCloudAdmin',
),
</syntaxhighlight>

==== In Keycloak nochmal alles kontrollieren ====
# Client ID stimmt überein
# unter <code>Capability config</code> ist <code>Client authentication</code> aktiv (damit wir ua. unser Secret bekommen)
# <code>Valid redirect URIs</code> erlaubt </code>https://cloud.mydomain.de/*</code> – oder eine konkretere Adresse. Das Plus übernimmt die Einstellung aus <code>Valid redirect URIs</code>
# <code>Valid post logout redirect URIs</code> erlaubt <code>+</code> oder </code>https://cloud.mydomain.de/*</code> – oder eine konkretere Adresse
# <code>Fine Grain OpenID Connect Configuration</code> steht unter <code>ID Token Signature Algorithm</code> auf <code>RS256</code> (Achtung, hier verrutscht man schnell weil die Einträge sich ähneln)

==== Gruppen Synchronisation über Rollen ermöglichen ====
Hierfür legen wir einen Mapper in <code>nextcloud</code> Client an. Anschließend müssen die tatsächlichen Gruppen mit Roles verknüpft werden. Hintergrund ist, dass Roles eigentlich für Berechtigungsmanagement gedacht sind, und Gruppen eigentlich nur User gruppieren sollen.
# wir wechseln im Client <code>nextcloud</code> auf den Reiter <code>Client scopes</code>
# wir wählen <code>nextcloud-dedicated</code>
# Add mapper -> by configuration
## Type: <code>User Client Role</code>
## Name: <code>ownCloudGroups</code>
## Client ID
### Option #1: <code>none</code> – es werden alle <code>Realm roles</code> abgerufen. Das umfasst allerdings auch die Defaults wie <code>uma_authorization</code>, <code>offline_access</code>, <code>default-user-roles</code> und ist nicht immer gewünscht.
### Option #2: <code>nextcloud</code> hier können im Anschluss roles im Client angelegt und mit <code>Groups</code> oder <code>Realm roles</code> verknüpft werden.
## Multivalued: <code>On</code>
## Token Claim Name: <code>NextcloudGroups</code>
## Claim JSON Type: <code>String</code>
## die folgenden drei Optionen: <code>On</code>

==== Gruppen Synchronisation in der Praxis ====

Option #2: Client ID <code>nextcloud</code>
# wir wechseln im Client <code>nextcloud</code> auf den Reiter <code>Roles</code>
# Create role
## Wunschname
# wir wechseln in <code>Groups</code> (Sidebar)
# Create group
## Wunschname: Wichtig: es muss der Name der Gruppe in Nextcloud genommen werden, der in der URL der Gruppe erkennbar ist; nicht der DisplayName
# In der Gruppe wechseln wir auf den Reiter <code>Role mapping</code>
## Assign role
## Im Dropdown wechseln wir auf den Filter <code>by clients</code>
## Wir wählen die gewünschte Rolle
## Unten Links, button <code>Assign</code>

Ab hier können wir die Gruppe normal zuweisen.

=== Benutzer einrichten ===
* Einen Benutzer im Keycloak einrichten, in der Realm "MeineFirma".
* Den Benutzer bearbeiten, und unter "Role Mappings", "Assign Role", "Filter by Clients", wähle "my-nextcloud admin" und klicke auf "Assign".

== Fehler beheben ==

Problem: Gerade beim Experimentieren kommt schon mal die Meldung: "expected expression, got end of script"
* Lösung: Webseite aus der Firefox Chronik komplett löschen, oder in einem privaten Fenster öffnen, dann geht es wieder.

Generell kann es zu verwirrenden Fehlermeldungen kommen, wenn man sich versucht in einer verknüpften Anwendung einzuloggen aber beispielsweise noch als Admin im Master-Realm eingeloggt ist.

=== Logging ===
Um Fehler besser verstehen zu können, kann das Logging angeschaltet werden, siehe auch [https://www.keycloak.org/server/logging].

Dazu müssen im Start Skript <code>bin/start-keycloak.sh</code> folgende Parameter hinzugefügt werden:
<syntaxhighlight lang=shell>
--log-level=ERROR --log=file
</syntaxhighlight>
Also sieht es z.B. so aus:
<syntaxhighlight lang=shell>
./bin/kc.sh start --http-port [...] --proxy edge --log-level=ERROR --log=file &
</syntaxhighlight>
Nach dem Neustart von Keycloak gibt es dann die Datei <code>keycloak/data/log/keycloak.log</code>.

== Links ==
*[http://www.keycloak.org/ Webseite von Keycloak]
*[https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/keycloak Ansible Playbook für Hostsharing]
*[https://robferguson.org/blog/2019/12/24/getting-started-with-keycloak/ Getting started with Keycloak]
*[https://janikvonrotz.ch/2020/10/20/openid-connect-with-nextcloud-and-keycloak/ OpenID Connect with Nextcloud and Keycloak] von Janik Vonrotz, Oktober 2020
* [https://www.muehlencord.de/wordpress/2019/12/14/nextcloud-sso-using-keycloak/ Nextcloud SSO using Keycloak] von Jörns Blog, Dezember 2019
* [https://youtu.be/bmOp8epgxsM Erklärvideo auf Youtube] zum Einrichten von Keycloak und Nextcloud
* [https://apps.nextcloud.com/apps/sociallogin Nextcloud App Social Login]

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]
[[Kategorie:Software]]
[[Kategorie:SSO]]
[[Kategorie:Java]]

Verzeichnis-Struktur

2026-07-08T15:48:51Z

Tim00:

{{Textkasten|rot|Hinweis:|Inhalt ist nun in der HS Dokumentation.
https://www.hostsharing.net/doc/managed-operations-platform/webpaket/
}}

---
[[Kategorie:Glossar]]

Verzeichnis-Struktur

2026-07-08T15:48:02Z

Tim00:

{{Textkasten|rot|Hinweis:|Inhalt ist nun in der HS Dokumentation.
https://www.hostsharing.net/doc/managed-operations-platform/tutorials/webspace/
}}

---
[[Kategorie:Glossar]]

Discourse installieren

2026-07-02T04:29:53Z

Tim00: /* Am Beispiel von 2026.1.3 auf 2026.1.4 */

{{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|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 ==

Es müssen noch Erweiterungen für Postgresql installiert werden:

<syntaxhighlight lang=shell line>
psql --user xyz00_discourseuser -c "CREATE EXTENSION IF NOT EXISTS hstore WITH SCHEMA public;"
psql --user xyz00_discourseuser -c "CREATE EXTENSION IF NOT EXISTS pg_trgm WITH SCHEMA public;"
psql --user xyz00_discourseuser -c "CREATE EXTENSION IF NOT EXISTS unaccent WITH SCHEMA public;"
</syntaxhighlight>

== Konfiguration des Redis Server ==

{{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.}}

<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:

<syntaxhighlight lang=shell line>
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
</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 ==

Als User ''xyz00-discourse'': Installation von Ruby mit ''rbenv'' mit folgenden Befehlen:

Zunächst ''rbenv'' and ''ruby-build'':

<syntaxhighlight lang=shell line>
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
</syntaxhighlight>

starte neue Shell:

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

Überprüfe rbenv-Installation

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

Installiere ruby-build als rbenv-Plugin

<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:

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

== Installation von Discourse selber ==

Weiterhin Als User ''xyz00-discourse'':

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

Die stabile Version auschecken:

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

Ruby Pakete installieren:

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

== Konfiguration der Discourse Software ==

Anlegen einer Datei ''/home/pacs/xyz00/users/discourse/discourse/config/discourse.conf'' anhand der Beispiel-Datei:

<syntaxhighlight lang=shell>
cd ~/discourse
cp config/discourse_defaults.conf config/discourse.conf
</syntaxhighlight>

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

<syntaxhighlight lang=shell>
RAILS_ENV=production bundle exec rake secret
</syntaxhighlight>

=== 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 <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 ==

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

[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
</syntaxhighlight>

== Einrichten des Apache VHost ==

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

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:

<syntaxhighlight lang=apache line>
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]
</syntaxhighlight>
== 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.

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

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

<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!

Siehe auch die unterstützten Releases: https://releases.discourse.org/ und die Tags: https://github.com/discourse/discourse/tags

==== Am Beispiel von 2026.1.4 auf 2026.1.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
# mv ~/plugins.bak/discourse-ai plugins
# git diff v2026.1.4 > diff-2026.1.4.txt
# git fetch
# git checkout -b hostsharing-deployment-v2026.1.5 v2026.1.5
# evtl. Änderungen aus diff-2026.1.4.txt wieder übernehmen und committen
# patch -p1 < diff-2026.1.4.txt
# git commit -a -m "spezifische Änderungen für diese Instanz" --no-verify
# Schauen, ob discourse eine neue Ruby-Version nutzt (z.B. in https://github.com/discourse/discourse_docker/blob/main/image/base/Dockerfile bzw. https://github.com/discourse/discourse/blob/v2026.1.5/Gemfile)
# Ist dies der Fall, dann:
# rbenv install 3.3.8
# rbenv global 3.3.8
# rbenv rehash
# echo "3.3.8" > .ruby-version
# installiere Node 22: https://codeberg.org/tpokorra/hostsharing-scripts/src/branch/main/install-nodejs.sh
# source ~/.profile
# gem update --system
# bundle install
# npm install -g terser uglify-js pnpm@10
#
# to avoid this error: ERR_PNPM_INVALID_DEPENDENCY_NAME The current package contains a dependency with an invalid name: "@types/@glimmer__component"
# vi frontend/discourse-types/package.json

- "@types/@glimmer__component": "npm:@glimmer/component@^2.0.0",
- "@types/@glint__ember-tsc": "npm:@glint/ember-tsc@^1.0.7",
- "@types/@glint__template": "npm:@glint/template@^1.7.2"
+ "@types/glimmer__component": "npm:@glimmer/component@^2.0.0",
+ "@types/glint__ember-tsc": "npm:@glint/ember-tsc@^1.0.7",
+ "@types/glint__template": "npm:@glint/template@^1.7.2"

#
# corepack use pnpm@latest-10
# pnpm install
# export $(grep -v '^#' ~/discourse.env | xargs -d '\n')
# source ~/.profile
# Falls die pg extension pg_vector nicht installiert ist: deaktiviere das Plugin während migrate, aber auch für später damit /admin/settings funktioniert (ansonsten in salt pillar pg_vector installieren, und als postgres user: create extension vector;)
## mkdir -p ~/plugins.bak
## mv plugins/discourse-ai ~/plugins.bak
# 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 ==

* 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

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

Skript hs-list-apps

2026-07-01T20:10:57Z

Tim00: /* Beschreibung */

== Beschreibung ==

hs-list-apps ist ein Skript, in Python geschrieben, welches viele der aktuell installierten Anwendungen und die Belegung von RAM, SSD und HDD anzeigt.

Es hilft, gerade bei Paketen mit vielen Anwendungen, den Überblick zu behalten. Als Reseller will ich zum Beispiel wissen, wieviele Nextclouds in meinem Paket installiert sind, wieviel Platz sie belegen, und auf welchem Versionsstand sie sind.

Das Skript wird momentan hier gepflegt: https://codeberg.org/tpokorra/hostsharing-scripts/src/branch/main/hs_list_apps

== Einschränkungen ==

Es werden bisher einige Anwendungen unterstützt, aber längst nicht alle Anwendungen, die bei Hostsharing installiert werden können oder installiert worden sind. Weitere Anwendungen können gerne ins Skript aufgenommen werden. Bitte einen PR oder Issue auf dem Repo bei Codeberg aufmachen.

Es werden einige Annahmen getroffen, wo eine Anwendung zu finden ist. Damit vermeiden wir einen vollständigen Scan der Dateien, der sehr zeitintensiv wäre. z.B. wird erwartet, dass die Nextclouds alle im Benutzerverzeichnis im Ordner nextcloud liegen.

Es wird versucht, die richtige Domain zu bestimmen. Wenn im Benutzer aber mehrere Domains eingetragen sind, wird die mit dem längsten Namen angezeigt.

== Benutzung ==

Das Skript steht auf den Hives zur Verfügung, es liegt in /usr/local/bin, und ist damit Teil des Standardpfades.

Das Skript kann entweder innerhalb eines Benutzers aufgerufen werden:

<syntaxhighlight lang=shell>
xyz00-nextcloud@h01:~$ hs-list-apps --detail
|-----------|---------|-------|-----------|-----------------------------------|--------|------|------|
| AppName | Version | PAC | USER | URL | RAM | SSD | HDD |
|-----------|---------|-------|-----------|-----------------------------------|--------|------|------|
| Nextcloud | 32.0.6 | xyz00 | nextcloud | https://test.nextcloud.example.de | 164.7M | 1.4G | 131M |
|-----------|---------|-------|-----------|-----------------------------------|--------|------|------|
</syntaxhighlight>

Ohne den Parameter --detail wird der SSD Platz und der HDD Platz nicht berechnet. Das kann sonst etwas Zeit in Anspruch nehmen.

Das Skript kann auch vom Paket Admin aufgerufen werden:

<syntaxhighlight lang=shell>
xyz00@h01:~$ hs-list-apps
|-----------|---------------|-------|-----------------|----------------------------- -----|-------|-----|-----|
| AppName | Version | PAC | USER | URL | RAM | SSD | HDD |
|-----------|---------------|-------|-----------------|-----------------------------------|-------|-----|-----|
| Wordpress | 6.8.3 | xyz00 | mywordpresstest | https://www.example.de | 21.2M | | |
| OpenLDAP | 2.5.13+dfsg-5 | xyz00 | openldap | https://openldap.example.de | 28.5M | | |
| Nextcloud | 32.0.6 | xyz00 | nextcloud | https://test.nextcloud.example.de | 33.0M | | |
|-----------|---------------|-------|-----------------|-----------------------------------|-------|-----|-----|
</syntaxhighlight>

Das Skript kann auch nur nach bestimmten Anwendungen suchen:

<syntaxhighlight lang=shell>
xyz00@h01:~$ hs-list-apps --app nextcloud
|-----------|---------------|-------|-----------------|----------------------------- -----|-------|-----|-----|
| AppName | Version | PAC | USER | URL | RAM | SSD | HDD |
|-----------|---------------|-------|-----------------|-----------------------------------|-------|-----|-----|
| Nextcloud | 32.0.6 | xyz00 | nextcloud | https://test.nextcloud.example.de | 33.0M | | |
|-----------|---------------|-------|-----------------|-----------------------------------|-------|-----|-----|
</syntaxhighlight>

Spamfilter

2026-06-24T08:20:38Z

Tim00: /* Konfiguration pro Domain */

Einrichtung, Konfiguration und Optimierung eines Spamfilters auf den Hostsharing Servern. Der Artikel beschreibt drei alternative Möglichkeiten:

1. Die Nutzung der "xmailin"-Server für eine komplette Domain

2. Die Einrichtung von Spamassassin für das persönliche Postfach

3. Nutzung der Spam-Appliance "SecureMX" für eine komplette Domain

= Alternative 1: Maileingangsserver mit Spamfilter nutzen =

Diese Alternative kann von einer Domain-Administration oder vom "Webmaster on Demand" für eine oder mehrere E-Mail-Domains eingerichtet werden. Ein globaler Sieve-Filter für markiete Spam-Nachrichten ist in der Standard-Konfiguration voreingestellt,
so dass Nachrichten mit Spam-Bewertung in einen vorhandenen Spam-Ordner einsortiert werden.

Seit einigen Jahren betreibt Hostsharing zusätzlich zu den vorkonfigurierte Maileingangsservern einen zweiten Satz von Maileingangsservern, bei denen Spamassassin bereits beim Annehmen einer E-Mail ausgeführt wird. Anfang 2026 ist eine Gruppe von Eingangsserver mit der Software "rspamd" hinzugekommen. Eingehende Nachrichten mit Malware oder sehr hoher Bewertung als Spam werden bereits im SMTP-Dialog abgewiesen. Nachrichten mit einem geringeren Spam-Score werden angenommen und zugestellt. Spamassassin fügt die Bewertung für diese Nachrichten in die Header der Nachricht ein, zum Beispiel:

<syntaxhighlight lang=bash>
X-Spam-Status: Yes, score=11.29
</syntaxhighlight>

Der globale Sieve-Filter schiebt Nachrichten mit der Markierung "X-Spam-Status: Yes" in einen Ordner "Junk", wenn der Ordner vorhanden ist. Viele Mailprogramme legen beim ersten Verbinden mit dem IMAP-Server einen solchen Ordner an. Unser "Roundcube"
unter https://webmail.hostsharing.net ist entsprechend eingerichtet, so dass der Ordner nach einer Nutzung von Webmail vorhanden ist.

== Eingangsserver konfigurieren ==

Die Maileingangsserver mit Rspamd lassen sich pro Domain konfigurieren, indem die MX-Records im DNS-Zonefile gegenüber dem Default-Zonefile angepasst werden.

Im Zonefile entfällt der Platzhalter "{MX_RR}". Stattdessen werden die folgenden MX-Records eingefügt:

<syntaxhighlight lang=bash>
{DOM_HOSTNAME}. IN MX 30 xmailin1.hostsharing.net.
{DOM_HOSTNAME}. IN MX 30 xmailin2.hostsharing.net.
{DOM_HOSTNAME}. IN MX 30 xmailin3.hostsharing.net.
</syntaxhighlight>

Zur Änderung der DNS-Zone siehe: https://www.hostsharing.net/doc/managed-operations-platform/zonefile/
Wer sich die Aktion auf der Shell nicht zutraut, möge bitte den "Webmaster on Demand" beauftragen.

Die Änderung des Zonefile kann für eine Domain "hs-example.de" wie folgt überprüft werden:

<syntaxhighlight lang=bash>
dig +short -t MX hs-example.de @dns1.hostsharing.net
</syntaxhighlight>

Die folgende Ausgabe wird erwartet:

<syntaxhighlight lang=bash>
30 xmailin2.hostsharing.net.
30 xmailin3.hostsharing.net.
30 xmailin1.hostsharing.net.
</syntaxhighlight>

Die Reihenfolge der drei Eingangsserver kann variieren.
Die führende Zahl ist die Priorität im MX-Record (hier der Wert "30").

== Den Filter trainieren ==
Wer auch am Trainieren des Filters mitwirken möchte, sendet den/die Benutzername/n xyz00-name (das ist der eMail Benutzername) an:
service (at) hostsharing (dot) net

Das bedeutet dann, dass das Verschieben einer E-Mail in den Spam-Ordner (Junk) darauf Einfluß hat, das zukünftige E-Mails in dieser Art besser als Spam erkannt werden. Andersrum genauso: wenn ich eine E-Mail aus dem Spam-Ordner (Junk) in einen anderen Ordner verschiebe, werden in Zukunft ähnliche E-Mails auch nicht mehr als Spam erkannt.

Da das Training gemeinschaftlich ist, sollte bitte darauf geachtet werden, Newsletter nicht in den Junk Ordner zu schieben, sondern sich davon abzumelden und die E-Mail zu löschen. Nur weil du den Newsletter der Firma xy nicht mehr magst, soll er für andere Benutzer nicht automatisch als Spam erkannt werden.

== Weitere Konfigurationen pro Domain ==

Die E-Mails werden vom Spamfilter auf verschiedene Kriterien geprüft, für die dann Punkte vergeben werden. Manche Eigenschaften sind positiv, andere sind negativ. Am Ende ergibt das eine Punktzahl.

Voreingestellt ist:
* ab einer Gesamt-Punktzahl von 5 wird die E-Mail als Spam kategorisiert, und wandert in den Spam-Ordner (Junk).
* ab einer Gesamt-Punktzahl von 15 wird die E-Mail direkt abgewiesen, und der Absender erhält von seinem E-Mail-Server eine Unzustellbarkeitsbenachrichtigung.

Wir können diese Punktzahlen pro Domain konfigurieren. Das geht leider noch nicht im HSAdmin, daher bitte eine E-Mail an den Hostsharing Service schicken.

Ebenso können einzelne Kriterien pro Domain abgeschaltet werden. Wenn z.B. in Ihren Geschäftsemails oft hohe Euro Beträge vorkommen, wollen Sie vielleicht das Symbol LOTS_OF_MONEY für die Domain meinefirma.de ignorieren. Dann bitte ebenfalls eine E-Mail an den Hostsharing Service schreiben, und wir stellen das für die Domain ein.

= Alternative 2: Persönlichen Spamfilter einrichten =

Hier geht es darum, wie Personen mit (grundlegenden) Kenntnissen in der Shell-Bedienung für ihr persönliches Postfach einen Spam-Filter einrichten können. Spamassassin kann für jedes Postfach individuell konfiguriert werden. Für die Einrichtung und Pflege ist Shell-Zugang zur Mailbox erforderlich.

Ein Bayesfilter kann mit den persönlichen Nachrichten angelernt werden. Dazu sind tiefergehende Shell-Kenntnisse erforderlich (Shell-Skript und Einrichtung eines systemd-Timers).

== Spamassassin Konfigurieren ==

Der Spamfilter "Spamassassin" ist bei HS vorinstalliert. Es muss über das Kommando "spamc", das Kommando zur Nutzung des Spamassassin-Daemon, in der Datei ".forward" eines Mail-Users aufgerufen werden:

<syntaxhighlight lang=bash>
"|/usr/bin/spamc -U /var/run/spamd -e /usr/lib/dovecot/deliver"
</syntaxhighlight>

Der Effekt: Spammassassin schreibt seine Testergebnisse in die Headerzeilen jeder E-Mail und leitet die E-Mails weiter an das Programm "deliver" aus dem Dovecot-Paket. Das Sortieren von Spam-EMail in einen Spam-Ordner lässt sich mit Sieve-Filtern umsetzen.

In dieser Variante kann man Spamassassin individuell konfigurieren. Dazu legt man im $HOME des Mailbox-Account ein Verzeichnis "$HOME/.spamassassin" an. Die Konfiguration erfolgt in der Datei "$HOME/.spamassassin/user_prefs".

Konfigurationsbeispiel:

<syntaxhighlight lang=bash>
required_score 4.0
report_safe 0
use_bayes 1
bayes_auto_learn 1
skip_rbl_checks 0
use_razor2 1
use_pyzor 1
</syntaxhighlight>

== Bayesfilter anlernen ==

Wenn der Bayesfilter eingeschaltet ist, macht es Sinn den Filter mit den Befehlen

<syntaxhighlight lang=bash>
sa-learn --spam <platzhalter-spam-nachricht-oder-verzeichnis>
sa-learn --ham <platzhalter-erwünschte-nachricht-oder-verzeichnis>
</syntaxhighlight>

anzulernen. Ein Bash-Skript für das Erlernen von Spam/Nonspam kann wie folgt aussehen:

<syntaxhighlight lang=bash>
#!/bin/bash

HAM_MIN_AGE_DAYS=5
MAILDIR_HAM=${HOME}/Maildir/cur
TMPDIR=${HOME}/sa-learn-tmp
SPAMFOLDER=Junk
SPAMFOLDER_LEARNED=${SPAMFOLDER}.sa-learned
MAILDIR_SPAM=${HOME}/Maildir/.${SPAMFOLDER}

# Learn spam from MAILDIR_SPAM
mkdir -p ${TMPDIR}/spam
rm -f ${TMPDIR}/spam/*
SPAM_COUNT=0
for DIR in "cur" "new"; do
DIR="${MAILDIR_SPAM}/${DIR}"
cd ${DIR}
# echo "---" DIR ${DIR}
for SPAMFILE in $( ls ); do
# echo " " ${SPAMFILE}
TMPFILE="${TMPDIR}/spam/${SPAMFILE}"
if ! zcat "${SPAMFILE}" > "${TMPFILE}" 2>/dev/null; then
cp "${SPAMFILE}" "${TMPFILE}"
fi
SPAM_COUNT=$((SPAM_COUNT + 1))
done
done
sa-learn --spam ${TMPDIR}/spam/*

# Move processed spam to keep it in another folder
doveadm move -u $(whoami) INBOX.${SPAMFOLDER_LEARNED} mailbox INBOX.${SPAMFOLDER} all 2>/dev/null

# Learn ham from MAILDIR_HAM (> HAM_MIN_AGE_DAYS days; max. 2x spam count)
mkdir -p ${TMPDIR}/ham
rm -f ${TMPDIR}/ham/*
cd ${MAILDIR_HAM}
MAX_HAM=$((SPAM_COUNT * 2))
HAM_COUNT=0
for HAMFILE in $( find . -type f -mtime +${HAM_MIN_AGE_DAYS} -printf '%T@ %p\n' | sort -rn | cut -d' ' -f2- | head -n ${MAX_HAM} ); do
TMPFILE="${TMPDIR}/ham/${HAMFILE}"
if ! zcat "${HAMFILE}" > "${TMPFILE}" 2>/dev/null; then
cp "${HAMFILE}" "${TMPFILE}"
fi
HAM_COUNT=$((HAM_COUNT + 1))
done
sa-learn --ham ${TMPDIR}/ham/*

echo "Training erfolgte mit ${SPAM_COUNT} Spam, ${HAM_COUNT} (max ${MAX_HAM}) Ham Mails."
</syntaxhighlight>

Dabei werden Mails verarbeitet, unabhängig davon, ob sie durch Procmail (unkomprimiert) oder über den Mailclient (komprimiert) verschoben vorliegen.
Für Ham wird ein Teil des Inhalts der Inbox verwendet, wobei die empfohlene Maximalanzahl von zweimal der Spammailanzahl und ein minimales Alter in Tagen gilt. Das Mindestalter garantiert ein inzwischen erfolgtes manuelles Aussortieren des Spams. Der verarbeitete Spam wird anschließend in ein separates Verzeichnis verschoben um den späteren Zugriff auf False Positives zu ermöglichen.

Das Skript wird über einen systemd-Timer täglich ausgeführt, der pro Mailbox eingerichtet werden muss.

= Alternative 3: SecureMX zubuchen =

Über unseren Domain-Anbieter "Partnergate" bietet Hostsharing als dritte Alternative die kommerzielle Spam-Appliance von Cisco an. Das Produkt heißt bei Partnergate "SecureMX": https://www.hostsharing.net/loesungen/email/spam-abwehr/

Die Nutzung von SecureMX ist kostenpflichtig und wird auf Wunsch vom Hostsharing-Service eingerichtet.

Es ist zu beachten, dass bei der Nutzung von SecureMX alle eingehenden E-Mail Nachrichten über Server geleitet werden, die nicht unter der Kontrolle von Hostsharing stehen und proprietäre Software einsetzen. Dieser Sachverhalt muss vom Mitglied ggf. datenschutzrechtlich bewertet werden.

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Glossar]]

Spamfilter

2026-06-24T08:14:00Z

Tim00: /* Den Filter trainieren */

Einrichtung, Konfiguration und Optimierung eines Spamfilters auf den Hostsharing Servern. Der Artikel beschreibt drei alternative Möglichkeiten:

1. Die Nutzung der "xmailin"-Server für eine komplette Domain

2. Die Einrichtung von Spamassassin für das persönliche Postfach

3. Nutzung der Spam-Appliance "SecureMX" für eine komplette Domain

= Alternative 1: Maileingangsserver mit Spamfilter nutzen =

Diese Alternative kann von einer Domain-Administration oder vom "Webmaster on Demand" für eine oder mehrere E-Mail-Domains eingerichtet werden. Ein globaler Sieve-Filter für markiete Spam-Nachrichten ist in der Standard-Konfiguration voreingestellt,
so dass Nachrichten mit Spam-Bewertung in einen vorhandenen Spam-Ordner einsortiert werden.

Seit einigen Jahren betreibt Hostsharing zusätzlich zu den vorkonfigurierte Maileingangsservern einen zweiten Satz von Maileingangsservern, bei denen Spamassassin bereits beim Annehmen einer E-Mail ausgeführt wird. Anfang 2026 ist eine Gruppe von Eingangsserver mit der Software "rspamd" hinzugekommen. Eingehende Nachrichten mit Malware oder sehr hoher Bewertung als Spam werden bereits im SMTP-Dialog abgewiesen. Nachrichten mit einem geringeren Spam-Score werden angenommen und zugestellt. Spamassassin fügt die Bewertung für diese Nachrichten in die Header der Nachricht ein, zum Beispiel:

<syntaxhighlight lang=bash>
X-Spam-Status: Yes, score=11.29
</syntaxhighlight>

Der globale Sieve-Filter schiebt Nachrichten mit der Markierung "X-Spam-Status: Yes" in einen Ordner "Junk", wenn der Ordner vorhanden ist. Viele Mailprogramme legen beim ersten Verbinden mit dem IMAP-Server einen solchen Ordner an. Unser "Roundcube"
unter https://webmail.hostsharing.net ist entsprechend eingerichtet, so dass der Ordner nach einer Nutzung von Webmail vorhanden ist.

== Eingangsserver konfigurieren ==

Die Maileingangsserver mit Rspamd lassen sich pro Domain konfigurieren, indem die MX-Records im DNS-Zonefile gegenüber dem Default-Zonefile angepasst werden.

Im Zonefile entfällt der Platzhalter "{MX_RR}". Stattdessen werden die folgenden MX-Records eingefügt:

<syntaxhighlight lang=bash>
{DOM_HOSTNAME}. IN MX 30 xmailin1.hostsharing.net.
{DOM_HOSTNAME}. IN MX 30 xmailin2.hostsharing.net.
{DOM_HOSTNAME}. IN MX 30 xmailin3.hostsharing.net.
</syntaxhighlight>

Zur Änderung der DNS-Zone siehe: https://www.hostsharing.net/doc/managed-operations-platform/zonefile/
Wer sich die Aktion auf der Shell nicht zutraut, möge bitte den "Webmaster on Demand" beauftragen.

Die Änderung des Zonefile kann für eine Domain "hs-example.de" wie folgt überprüft werden:

<syntaxhighlight lang=bash>
dig +short -t MX hs-example.de @dns1.hostsharing.net
</syntaxhighlight>

Die folgende Ausgabe wird erwartet:

<syntaxhighlight lang=bash>
30 xmailin2.hostsharing.net.
30 xmailin3.hostsharing.net.
30 xmailin1.hostsharing.net.
</syntaxhighlight>

Die Reihenfolge der drei Eingangsserver kann variieren.
Die führende Zahl ist die Priorität im MX-Record (hier der Wert "30").

== Den Filter trainieren ==
Wer auch am Trainieren des Filters mitwirken möchte, sendet den/die Benutzername/n xyz00-name (das ist der eMail Benutzername) an:
service (at) hostsharing (dot) net

Das bedeutet dann, dass das Verschieben einer E-Mail in den Spam-Ordner (Junk) darauf Einfluß hat, das zukünftige E-Mails in dieser Art besser als Spam erkannt werden. Andersrum genauso: wenn ich eine E-Mail aus dem Spam-Ordner (Junk) in einen anderen Ordner verschiebe, werden in Zukunft ähnliche E-Mails auch nicht mehr als Spam erkannt.

Da das Training gemeinschaftlich ist, sollte bitte darauf geachtet werden, Newsletter nicht in den Junk Ordner zu schieben, sondern sich davon abzumelden und die E-Mail zu löschen. Nur weil du den Newsletter der Firma xy nicht mehr magst, soll er für andere Benutzer nicht automatisch als Spam erkannt werden.

== Konfiguration pro Domain ==

= Alternative 2: Persönlichen Spamfilter einrichten =

Hier geht es darum, wie Personen mit (grundlegenden) Kenntnissen in der Shell-Bedienung für ihr persönliches Postfach einen Spam-Filter einrichten können. Spamassassin kann für jedes Postfach individuell konfiguriert werden. Für die Einrichtung und Pflege ist Shell-Zugang zur Mailbox erforderlich.

Ein Bayesfilter kann mit den persönlichen Nachrichten angelernt werden. Dazu sind tiefergehende Shell-Kenntnisse erforderlich (Shell-Skript und Einrichtung eines systemd-Timers).

== Spamassassin Konfigurieren ==

Der Spamfilter "Spamassassin" ist bei HS vorinstalliert. Es muss über das Kommando "spamc", das Kommando zur Nutzung des Spamassassin-Daemon, in der Datei ".forward" eines Mail-Users aufgerufen werden:

<syntaxhighlight lang=bash>
"|/usr/bin/spamc -U /var/run/spamd -e /usr/lib/dovecot/deliver"
</syntaxhighlight>

Der Effekt: Spammassassin schreibt seine Testergebnisse in die Headerzeilen jeder E-Mail und leitet die E-Mails weiter an das Programm "deliver" aus dem Dovecot-Paket. Das Sortieren von Spam-EMail in einen Spam-Ordner lässt sich mit Sieve-Filtern umsetzen.

In dieser Variante kann man Spamassassin individuell konfigurieren. Dazu legt man im $HOME des Mailbox-Account ein Verzeichnis "$HOME/.spamassassin" an. Die Konfiguration erfolgt in der Datei "$HOME/.spamassassin/user_prefs".

Konfigurationsbeispiel:

<syntaxhighlight lang=bash>
required_score 4.0
report_safe 0
use_bayes 1
bayes_auto_learn 1
skip_rbl_checks 0
use_razor2 1
use_pyzor 1
</syntaxhighlight>

== Bayesfilter anlernen ==

Wenn der Bayesfilter eingeschaltet ist, macht es Sinn den Filter mit den Befehlen

<syntaxhighlight lang=bash>
sa-learn --spam <platzhalter-spam-nachricht-oder-verzeichnis>
sa-learn --ham <platzhalter-erwünschte-nachricht-oder-verzeichnis>
</syntaxhighlight>

anzulernen. Ein Bash-Skript für das Erlernen von Spam/Nonspam kann wie folgt aussehen:

<syntaxhighlight lang=bash>
#!/bin/bash

HAM_MIN_AGE_DAYS=5
MAILDIR_HAM=${HOME}/Maildir/cur
TMPDIR=${HOME}/sa-learn-tmp
SPAMFOLDER=Junk
SPAMFOLDER_LEARNED=${SPAMFOLDER}.sa-learned
MAILDIR_SPAM=${HOME}/Maildir/.${SPAMFOLDER}

# Learn spam from MAILDIR_SPAM
mkdir -p ${TMPDIR}/spam
rm -f ${TMPDIR}/spam/*
SPAM_COUNT=0
for DIR in "cur" "new"; do
DIR="${MAILDIR_SPAM}/${DIR}"
cd ${DIR}
# echo "---" DIR ${DIR}
for SPAMFILE in $( ls ); do
# echo " " ${SPAMFILE}
TMPFILE="${TMPDIR}/spam/${SPAMFILE}"
if ! zcat "${SPAMFILE}" > "${TMPFILE}" 2>/dev/null; then
cp "${SPAMFILE}" "${TMPFILE}"
fi
SPAM_COUNT=$((SPAM_COUNT + 1))
done
done
sa-learn --spam ${TMPDIR}/spam/*

# Move processed spam to keep it in another folder
doveadm move -u $(whoami) INBOX.${SPAMFOLDER_LEARNED} mailbox INBOX.${SPAMFOLDER} all 2>/dev/null

# Learn ham from MAILDIR_HAM (> HAM_MIN_AGE_DAYS days; max. 2x spam count)
mkdir -p ${TMPDIR}/ham
rm -f ${TMPDIR}/ham/*
cd ${MAILDIR_HAM}
MAX_HAM=$((SPAM_COUNT * 2))
HAM_COUNT=0
for HAMFILE in $( find . -type f -mtime +${HAM_MIN_AGE_DAYS} -printf '%T@ %p\n' | sort -rn | cut -d' ' -f2- | head -n ${MAX_HAM} ); do
TMPFILE="${TMPDIR}/ham/${HAMFILE}"
if ! zcat "${HAMFILE}" > "${TMPFILE}" 2>/dev/null; then
cp "${HAMFILE}" "${TMPFILE}"
fi
HAM_COUNT=$((HAM_COUNT + 1))
done
sa-learn --ham ${TMPDIR}/ham/*

echo "Training erfolgte mit ${SPAM_COUNT} Spam, ${HAM_COUNT} (max ${MAX_HAM}) Ham Mails."
</syntaxhighlight>

Dabei werden Mails verarbeitet, unabhängig davon, ob sie durch Procmail (unkomprimiert) oder über den Mailclient (komprimiert) verschoben vorliegen.
Für Ham wird ein Teil des Inhalts der Inbox verwendet, wobei die empfohlene Maximalanzahl von zweimal der Spammailanzahl und ein minimales Alter in Tagen gilt. Das Mindestalter garantiert ein inzwischen erfolgtes manuelles Aussortieren des Spams. Der verarbeitete Spam wird anschließend in ein separates Verzeichnis verschoben um den späteren Zugriff auf False Positives zu ermöglichen.

Das Skript wird über einen systemd-Timer täglich ausgeführt, der pro Mailbox eingerichtet werden muss.

= Alternative 3: SecureMX zubuchen =

Über unseren Domain-Anbieter "Partnergate" bietet Hostsharing als dritte Alternative die kommerzielle Spam-Appliance von Cisco an. Das Produkt heißt bei Partnergate "SecureMX": https://www.hostsharing.net/loesungen/email/spam-abwehr/

Die Nutzung von SecureMX ist kostenpflichtig und wird auf Wunsch vom Hostsharing-Service eingerichtet.

Es ist zu beachten, dass bei der Nutzung von SecureMX alle eingehenden E-Mail Nachrichten über Server geleitet werden, die nicht unter der Kontrolle von Hostsharing stehen und proprietäre Software einsetzen. Dieser Sachverhalt muss vom Mitglied ggf. datenschutzrechtlich bewertet werden.

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Glossar]]

Spamfilter

2026-06-24T08:13:12Z

Tim00: /* Den Filter trainieren */

Einrichtung, Konfiguration und Optimierung eines Spamfilters auf den Hostsharing Servern. Der Artikel beschreibt drei alternative Möglichkeiten:

1. Die Nutzung der "xmailin"-Server für eine komplette Domain

2. Die Einrichtung von Spamassassin für das persönliche Postfach

3. Nutzung der Spam-Appliance "SecureMX" für eine komplette Domain

= Alternative 1: Maileingangsserver mit Spamfilter nutzen =

Diese Alternative kann von einer Domain-Administration oder vom "Webmaster on Demand" für eine oder mehrere E-Mail-Domains eingerichtet werden. Ein globaler Sieve-Filter für markiete Spam-Nachrichten ist in der Standard-Konfiguration voreingestellt,
so dass Nachrichten mit Spam-Bewertung in einen vorhandenen Spam-Ordner einsortiert werden.

Seit einigen Jahren betreibt Hostsharing zusätzlich zu den vorkonfigurierte Maileingangsservern einen zweiten Satz von Maileingangsservern, bei denen Spamassassin bereits beim Annehmen einer E-Mail ausgeführt wird. Anfang 2026 ist eine Gruppe von Eingangsserver mit der Software "rspamd" hinzugekommen. Eingehende Nachrichten mit Malware oder sehr hoher Bewertung als Spam werden bereits im SMTP-Dialog abgewiesen. Nachrichten mit einem geringeren Spam-Score werden angenommen und zugestellt. Spamassassin fügt die Bewertung für diese Nachrichten in die Header der Nachricht ein, zum Beispiel:

<syntaxhighlight lang=bash>
X-Spam-Status: Yes, score=11.29
</syntaxhighlight>

Der globale Sieve-Filter schiebt Nachrichten mit der Markierung "X-Spam-Status: Yes" in einen Ordner "Junk", wenn der Ordner vorhanden ist. Viele Mailprogramme legen beim ersten Verbinden mit dem IMAP-Server einen solchen Ordner an. Unser "Roundcube"
unter https://webmail.hostsharing.net ist entsprechend eingerichtet, so dass der Ordner nach einer Nutzung von Webmail vorhanden ist.

== Eingangsserver konfigurieren ==

Die Maileingangsserver mit Rspamd lassen sich pro Domain konfigurieren, indem die MX-Records im DNS-Zonefile gegenüber dem Default-Zonefile angepasst werden.

Im Zonefile entfällt der Platzhalter "{MX_RR}". Stattdessen werden die folgenden MX-Records eingefügt:

<syntaxhighlight lang=bash>
{DOM_HOSTNAME}. IN MX 30 xmailin1.hostsharing.net.
{DOM_HOSTNAME}. IN MX 30 xmailin2.hostsharing.net.
{DOM_HOSTNAME}. IN MX 30 xmailin3.hostsharing.net.
</syntaxhighlight>

Zur Änderung der DNS-Zone siehe: https://www.hostsharing.net/doc/managed-operations-platform/zonefile/
Wer sich die Aktion auf der Shell nicht zutraut, möge bitte den "Webmaster on Demand" beauftragen.

Die Änderung des Zonefile kann für eine Domain "hs-example.de" wie folgt überprüft werden:

<syntaxhighlight lang=bash>
dig +short -t MX hs-example.de @dns1.hostsharing.net
</syntaxhighlight>

Die folgende Ausgabe wird erwartet:

<syntaxhighlight lang=bash>
30 xmailin2.hostsharing.net.
30 xmailin3.hostsharing.net.
30 xmailin1.hostsharing.net.
</syntaxhighlight>

Die Reihenfolge der drei Eingangsserver kann variieren.
Die führende Zahl ist die Priorität im MX-Record (hier der Wert "30").

== Den Filter trainieren ==
Wer auch am Trainieren des Filters mitwirken möchte, sendet den/die Benutzername/n xyz00-name (das ist der eMail Benutzername) an:
service (at) hostsharing (dot) net

Das bedeutet dann, dass das Verschieben einer E-Mail in den Spam-Ordner (Junk) darauf Einfluß hat, das zukünftige E-Mails in dieser Art besser als Spam erkannt werden. Andersrum genauso: wenn ich eine E-Mail aus dem Spam-Ordner (Junk) in einen anderen Ordner verschiebe, werden in Zukunft ähnliche E-Mails auch nicht mehr als Spam erkannt.

Da das Training gemeinschaftlich ist, sollte bitte darauf geachtet werden, Newsletter nicht in den Junk Ordner zu schieben, sondern sich davon abzumelden und die E-Mail zu löschen. Nur weil du den Newsletter der Firma xy nicht mehr magst, soll er für andere Benutzer nicht automatisch als Spam erkannt werden.

= Alternative 2: Persönlichen Spamfilter einrichten =

Hier geht es darum, wie Personen mit (grundlegenden) Kenntnissen in der Shell-Bedienung für ihr persönliches Postfach einen Spam-Filter einrichten können. Spamassassin kann für jedes Postfach individuell konfiguriert werden. Für die Einrichtung und Pflege ist Shell-Zugang zur Mailbox erforderlich.

Ein Bayesfilter kann mit den persönlichen Nachrichten angelernt werden. Dazu sind tiefergehende Shell-Kenntnisse erforderlich (Shell-Skript und Einrichtung eines systemd-Timers).

== Spamassassin Konfigurieren ==

Der Spamfilter "Spamassassin" ist bei HS vorinstalliert. Es muss über das Kommando "spamc", das Kommando zur Nutzung des Spamassassin-Daemon, in der Datei ".forward" eines Mail-Users aufgerufen werden:

<syntaxhighlight lang=bash>
"|/usr/bin/spamc -U /var/run/spamd -e /usr/lib/dovecot/deliver"
</syntaxhighlight>

Der Effekt: Spammassassin schreibt seine Testergebnisse in die Headerzeilen jeder E-Mail und leitet die E-Mails weiter an das Programm "deliver" aus dem Dovecot-Paket. Das Sortieren von Spam-EMail in einen Spam-Ordner lässt sich mit Sieve-Filtern umsetzen.

In dieser Variante kann man Spamassassin individuell konfigurieren. Dazu legt man im $HOME des Mailbox-Account ein Verzeichnis "$HOME/.spamassassin" an. Die Konfiguration erfolgt in der Datei "$HOME/.spamassassin/user_prefs".

Konfigurationsbeispiel:

<syntaxhighlight lang=bash>
required_score 4.0
report_safe 0
use_bayes 1
bayes_auto_learn 1
skip_rbl_checks 0
use_razor2 1
use_pyzor 1
</syntaxhighlight>

== Bayesfilter anlernen ==

Wenn der Bayesfilter eingeschaltet ist, macht es Sinn den Filter mit den Befehlen

<syntaxhighlight lang=bash>
sa-learn --spam <platzhalter-spam-nachricht-oder-verzeichnis>
sa-learn --ham <platzhalter-erwünschte-nachricht-oder-verzeichnis>
</syntaxhighlight>

anzulernen. Ein Bash-Skript für das Erlernen von Spam/Nonspam kann wie folgt aussehen:

<syntaxhighlight lang=bash>
#!/bin/bash

HAM_MIN_AGE_DAYS=5
MAILDIR_HAM=${HOME}/Maildir/cur
TMPDIR=${HOME}/sa-learn-tmp
SPAMFOLDER=Junk
SPAMFOLDER_LEARNED=${SPAMFOLDER}.sa-learned
MAILDIR_SPAM=${HOME}/Maildir/.${SPAMFOLDER}

# Learn spam from MAILDIR_SPAM
mkdir -p ${TMPDIR}/spam
rm -f ${TMPDIR}/spam/*
SPAM_COUNT=0
for DIR in "cur" "new"; do
DIR="${MAILDIR_SPAM}/${DIR}"
cd ${DIR}
# echo "---" DIR ${DIR}
for SPAMFILE in $( ls ); do
# echo " " ${SPAMFILE}
TMPFILE="${TMPDIR}/spam/${SPAMFILE}"
if ! zcat "${SPAMFILE}" > "${TMPFILE}" 2>/dev/null; then
cp "${SPAMFILE}" "${TMPFILE}"
fi
SPAM_COUNT=$((SPAM_COUNT + 1))
done
done
sa-learn --spam ${TMPDIR}/spam/*

# Move processed spam to keep it in another folder
doveadm move -u $(whoami) INBOX.${SPAMFOLDER_LEARNED} mailbox INBOX.${SPAMFOLDER} all 2>/dev/null

# Learn ham from MAILDIR_HAM (> HAM_MIN_AGE_DAYS days; max. 2x spam count)
mkdir -p ${TMPDIR}/ham
rm -f ${TMPDIR}/ham/*
cd ${MAILDIR_HAM}
MAX_HAM=$((SPAM_COUNT * 2))
HAM_COUNT=0
for HAMFILE in $( find . -type f -mtime +${HAM_MIN_AGE_DAYS} -printf '%T@ %p\n' | sort -rn | cut -d' ' -f2- | head -n ${MAX_HAM} ); do
TMPFILE="${TMPDIR}/ham/${HAMFILE}"
if ! zcat "${HAMFILE}" > "${TMPFILE}" 2>/dev/null; then
cp "${HAMFILE}" "${TMPFILE}"
fi
HAM_COUNT=$((HAM_COUNT + 1))
done
sa-learn --ham ${TMPDIR}/ham/*

echo "Training erfolgte mit ${SPAM_COUNT} Spam, ${HAM_COUNT} (max ${MAX_HAM}) Ham Mails."
</syntaxhighlight>

Dabei werden Mails verarbeitet, unabhängig davon, ob sie durch Procmail (unkomprimiert) oder über den Mailclient (komprimiert) verschoben vorliegen.
Für Ham wird ein Teil des Inhalts der Inbox verwendet, wobei die empfohlene Maximalanzahl von zweimal der Spammailanzahl und ein minimales Alter in Tagen gilt. Das Mindestalter garantiert ein inzwischen erfolgtes manuelles Aussortieren des Spams. Der verarbeitete Spam wird anschließend in ein separates Verzeichnis verschoben um den späteren Zugriff auf False Positives zu ermöglichen.

Das Skript wird über einen systemd-Timer täglich ausgeführt, der pro Mailbox eingerichtet werden muss.

= Alternative 3: SecureMX zubuchen =

Über unseren Domain-Anbieter "Partnergate" bietet Hostsharing als dritte Alternative die kommerzielle Spam-Appliance von Cisco an. Das Produkt heißt bei Partnergate "SecureMX": https://www.hostsharing.net/loesungen/email/spam-abwehr/

Die Nutzung von SecureMX ist kostenpflichtig und wird auf Wunsch vom Hostsharing-Service eingerichtet.

Es ist zu beachten, dass bei der Nutzung von SecureMX alle eingehenden E-Mail Nachrichten über Server geleitet werden, die nicht unter der Kontrolle von Hostsharing stehen und proprietäre Software einsetzen. Dieser Sachverhalt muss vom Mitglied ggf. datenschutzrechtlich bewertet werden.

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Glossar]]

Spamfilter

2026-06-24T08:09:10Z

Tim00: /* Filtern lernen teilnehmen */

Einrichtung, Konfiguration und Optimierung eines Spamfilters auf den Hostsharing Servern. Der Artikel beschreibt drei alternative Möglichkeiten:

1. Die Nutzung der "xmailin"-Server für eine komplette Domain

2. Die Einrichtung von Spamassassin für das persönliche Postfach

3. Nutzung der Spam-Appliance "SecureMX" für eine komplette Domain

= Alternative 1: Maileingangsserver mit Spamfilter nutzen =

Diese Alternative kann von einer Domain-Administration oder vom "Webmaster on Demand" für eine oder mehrere E-Mail-Domains eingerichtet werden. Ein globaler Sieve-Filter für markiete Spam-Nachrichten ist in der Standard-Konfiguration voreingestellt,
so dass Nachrichten mit Spam-Bewertung in einen vorhandenen Spam-Ordner einsortiert werden.

Seit einigen Jahren betreibt Hostsharing zusätzlich zu den vorkonfigurierte Maileingangsservern einen zweiten Satz von Maileingangsservern, bei denen Spamassassin bereits beim Annehmen einer E-Mail ausgeführt wird. Anfang 2026 ist eine Gruppe von Eingangsserver mit der Software "rspamd" hinzugekommen. Eingehende Nachrichten mit Malware oder sehr hoher Bewertung als Spam werden bereits im SMTP-Dialog abgewiesen. Nachrichten mit einem geringeren Spam-Score werden angenommen und zugestellt. Spamassassin fügt die Bewertung für diese Nachrichten in die Header der Nachricht ein, zum Beispiel:

<syntaxhighlight lang=bash>
X-Spam-Status: Yes, score=11.29
</syntaxhighlight>

Der globale Sieve-Filter schiebt Nachrichten mit der Markierung "X-Spam-Status: Yes" in einen Ordner "Junk", wenn der Ordner vorhanden ist. Viele Mailprogramme legen beim ersten Verbinden mit dem IMAP-Server einen solchen Ordner an. Unser "Roundcube"
unter https://webmail.hostsharing.net ist entsprechend eingerichtet, so dass der Ordner nach einer Nutzung von Webmail vorhanden ist.

== Eingangsserver konfigurieren ==

Die Maileingangsserver mit Rspamd lassen sich pro Domain konfigurieren, indem die MX-Records im DNS-Zonefile gegenüber dem Default-Zonefile angepasst werden.

Im Zonefile entfällt der Platzhalter "{MX_RR}". Stattdessen werden die folgenden MX-Records eingefügt:

<syntaxhighlight lang=bash>
{DOM_HOSTNAME}. IN MX 30 xmailin1.hostsharing.net.
{DOM_HOSTNAME}. IN MX 30 xmailin2.hostsharing.net.
{DOM_HOSTNAME}. IN MX 30 xmailin3.hostsharing.net.
</syntaxhighlight>

Zur Änderung der DNS-Zone siehe: https://www.hostsharing.net/doc/managed-operations-platform/zonefile/
Wer sich die Aktion auf der Shell nicht zutraut, möge bitte den "Webmaster on Demand" beauftragen.

Die Änderung des Zonefile kann für eine Domain "hs-example.de" wie folgt überprüft werden:

<syntaxhighlight lang=bash>
dig +short -t MX hs-example.de @dns1.hostsharing.net
</syntaxhighlight>

Die folgende Ausgabe wird erwartet:

<syntaxhighlight lang=bash>
30 xmailin2.hostsharing.net.
30 xmailin3.hostsharing.net.
30 xmailin1.hostsharing.net.
</syntaxhighlight>

Die Reihenfolge der drei Eingangsserver kann variieren.
Die führende Zahl ist die Priorität im MX-Record (hier der Wert "30").

== Den Filter trainieren ==
Wer auch am Trainieren des Filters mitwirken möchte, sendet den/die Benutzername/n xyz00-name (das ist der eMail Benutzername) an:
service (at) hostsharing (dot) net

= Alternative 2: Persönlichen Spamfilter einrichten =

Hier geht es darum, wie Personen mit (grundlegenden) Kenntnissen in der Shell-Bedienung für ihr persönliches Postfach einen Spam-Filter einrichten können. Spamassassin kann für jedes Postfach individuell konfiguriert werden. Für die Einrichtung und Pflege ist Shell-Zugang zur Mailbox erforderlich.

Ein Bayesfilter kann mit den persönlichen Nachrichten angelernt werden. Dazu sind tiefergehende Shell-Kenntnisse erforderlich (Shell-Skript und Einrichtung eines systemd-Timers).

== Spamassassin Konfigurieren ==

Der Spamfilter "Spamassassin" ist bei HS vorinstalliert. Es muss über das Kommando "spamc", das Kommando zur Nutzung des Spamassassin-Daemon, in der Datei ".forward" eines Mail-Users aufgerufen werden:

<syntaxhighlight lang=bash>
"|/usr/bin/spamc -U /var/run/spamd -e /usr/lib/dovecot/deliver"
</syntaxhighlight>

Der Effekt: Spammassassin schreibt seine Testergebnisse in die Headerzeilen jeder E-Mail und leitet die E-Mails weiter an das Programm "deliver" aus dem Dovecot-Paket. Das Sortieren von Spam-EMail in einen Spam-Ordner lässt sich mit Sieve-Filtern umsetzen.

In dieser Variante kann man Spamassassin individuell konfigurieren. Dazu legt man im $HOME des Mailbox-Account ein Verzeichnis "$HOME/.spamassassin" an. Die Konfiguration erfolgt in der Datei "$HOME/.spamassassin/user_prefs".

Konfigurationsbeispiel:

<syntaxhighlight lang=bash>
required_score 4.0
report_safe 0
use_bayes 1
bayes_auto_learn 1
skip_rbl_checks 0
use_razor2 1
use_pyzor 1
</syntaxhighlight>

== Bayesfilter anlernen ==

Wenn der Bayesfilter eingeschaltet ist, macht es Sinn den Filter mit den Befehlen

<syntaxhighlight lang=bash>
sa-learn --spam <platzhalter-spam-nachricht-oder-verzeichnis>
sa-learn --ham <platzhalter-erwünschte-nachricht-oder-verzeichnis>
</syntaxhighlight>

anzulernen. Ein Bash-Skript für das Erlernen von Spam/Nonspam kann wie folgt aussehen:

<syntaxhighlight lang=bash>
#!/bin/bash

HAM_MIN_AGE_DAYS=5
MAILDIR_HAM=${HOME}/Maildir/cur
TMPDIR=${HOME}/sa-learn-tmp
SPAMFOLDER=Junk
SPAMFOLDER_LEARNED=${SPAMFOLDER}.sa-learned
MAILDIR_SPAM=${HOME}/Maildir/.${SPAMFOLDER}

# Learn spam from MAILDIR_SPAM
mkdir -p ${TMPDIR}/spam
rm -f ${TMPDIR}/spam/*
SPAM_COUNT=0
for DIR in "cur" "new"; do
DIR="${MAILDIR_SPAM}/${DIR}"
cd ${DIR}
# echo "---" DIR ${DIR}
for SPAMFILE in $( ls ); do
# echo " " ${SPAMFILE}
TMPFILE="${TMPDIR}/spam/${SPAMFILE}"
if ! zcat "${SPAMFILE}" > "${TMPFILE}" 2>/dev/null; then
cp "${SPAMFILE}" "${TMPFILE}"
fi
SPAM_COUNT=$((SPAM_COUNT + 1))
done
done
sa-learn --spam ${TMPDIR}/spam/*

# Move processed spam to keep it in another folder
doveadm move -u $(whoami) INBOX.${SPAMFOLDER_LEARNED} mailbox INBOX.${SPAMFOLDER} all 2>/dev/null

# Learn ham from MAILDIR_HAM (> HAM_MIN_AGE_DAYS days; max. 2x spam count)
mkdir -p ${TMPDIR}/ham
rm -f ${TMPDIR}/ham/*
cd ${MAILDIR_HAM}
MAX_HAM=$((SPAM_COUNT * 2))
HAM_COUNT=0
for HAMFILE in $( find . -type f -mtime +${HAM_MIN_AGE_DAYS} -printf '%T@ %p\n' | sort -rn | cut -d' ' -f2- | head -n ${MAX_HAM} ); do
TMPFILE="${TMPDIR}/ham/${HAMFILE}"
if ! zcat "${HAMFILE}" > "${TMPFILE}" 2>/dev/null; then
cp "${HAMFILE}" "${TMPFILE}"
fi
HAM_COUNT=$((HAM_COUNT + 1))
done
sa-learn --ham ${TMPDIR}/ham/*

echo "Training erfolgte mit ${SPAM_COUNT} Spam, ${HAM_COUNT} (max ${MAX_HAM}) Ham Mails."
</syntaxhighlight>

Dabei werden Mails verarbeitet, unabhängig davon, ob sie durch Procmail (unkomprimiert) oder über den Mailclient (komprimiert) verschoben vorliegen.
Für Ham wird ein Teil des Inhalts der Inbox verwendet, wobei die empfohlene Maximalanzahl von zweimal der Spammailanzahl und ein minimales Alter in Tagen gilt. Das Mindestalter garantiert ein inzwischen erfolgtes manuelles Aussortieren des Spams. Der verarbeitete Spam wird anschließend in ein separates Verzeichnis verschoben um den späteren Zugriff auf False Positives zu ermöglichen.

Das Skript wird über einen systemd-Timer täglich ausgeführt, der pro Mailbox eingerichtet werden muss.

= Alternative 3: SecureMX zubuchen =

Über unseren Domain-Anbieter "Partnergate" bietet Hostsharing als dritte Alternative die kommerzielle Spam-Appliance von Cisco an. Das Produkt heißt bei Partnergate "SecureMX": https://www.hostsharing.net/loesungen/email/spam-abwehr/

Die Nutzung von SecureMX ist kostenpflichtig und wird auf Wunsch vom Hostsharing-Service eingerichtet.

Es ist zu beachten, dass bei der Nutzung von SecureMX alle eingehenden E-Mail Nachrichten über Server geleitet werden, die nicht unter der Kontrolle von Hostsharing stehen und proprietäre Software einsetzen. Dieser Sachverhalt muss vom Mitglied ggf. datenschutzrechtlich bewertet werden.

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Glossar]]

NGinX installieren

2026-06-17T03:34:01Z

Tim00: /* Betreiben des Nginx als Apache Ersatz mit Letsencrypt und HTTP Challenge */

__TOC__

Mit der Option "eigener Daemon" ist es möglich in einem Paket statt des Apache Webserver, den Hostsharing zentral zur Verfügung stellt, einen Nginx (oder einen anderen Webserver) in einem Webspace zu nutzen.

=== Port-Weiterleitung als Apache Ersatz ===

Mit der Bestellung des eigenen Daemon gibt man an, mit den Rechten welcher Nutzerkennung der Nginx-Prozess laufen soll. Die Nutzerkennung muss bereits angelegt sein. Ich verwende hier: ''xyz00-nginx''. Weiterhin bittet man die Hostmaster eine Portweiterleitung über IPTables-Regeln einzurichten. Ich verwende in dieser Wikiseite 38080 für HTTP und 38443 für HTTPS. Nach Einrichtung der IPTables Regeln in der Firewall wird euer NGinX unter den normalen Ports für HTTPS und HTTPS 80 und 443 erreichbar sein.

==== Konfiguration ====

Nginx ist auf allen Managed Servern vorinstalliert. Wir müssen also lediglich eine Konfigurationsdatei anlegen und anschliessend eine eigene Instanz des Dienstes starten.

Eine Beispielkonfiguration sieht wie folgt aus:

<syntaxhighlight lang="nginx" line>
error_log /home/pacs/xyz00/users/nginx/var/error.log warn;
pid /home/pacs/xyz00/users/nginx/var/nginx.pid;
events {
worker_connections 4096;
}
http {
include /etc/nginx/mime.types;
access_log /home/pacs/xyz00/users/nginx/var/access.log;
server_names_hash_bucket_size 64;
server {
listen xyz00.hostsharing.net:38080 default_server;
server_name _;
return 301 https://$host$request_uri;
}
server {
listen xyz00.hostsharing.net:38443 ssl http2;
server_name www.hs-example.de;
ssl_certificate /home/pacs/xyz00/users/nginx/etc/xyz00.hs-example.de.crt;
ssl_certificate_key /home/pacs/xyz00/users/nginx/etc/xyz00.hs-example.de.key;
root /home/pacs/xyz00/users/nginx/htdocs;
index index.html;
location / {
ssi on;
}
}
}
</syntaxhighlight>

=== Betreiben des Nginx als Apache Ersatz mit Letsencrypt und HTTP Challenge ===
In dem Fall, dass man für einen Kunden ein Projekt auf einer Domain hostet, dessen DNS woanders eingerichtet ist,
dann hat man das Problem, dass das Let's Encrypt mit DNS Challenge bei Hostsharing erstmal nicht tut.

Es gibt natürlich die Möglichkeit, die Subdomain per DNS Zonen-Delegation (siehe https://de.wikipedia.org/wiki/NS_Resource_Record#Zonendelegation) zu Hostsharing zu delegieren.
Falls das aber dem Kunden zu kompliziert ist, kann man auch mit der folgenden Nginx Variante arbeiten:

Die Subdomain mit dem eigenen Nginx konfigurieren, auf den die Standardports 80 und 443 weitergeleitet werden, wie im vorhergehenden Abschnitt beschrieben.

Dann kann man auch wieder Let's Encrypt mit HTTP Challenge einsetzen.

Hier gibt es ein Ansible Projekt, das diesen Fall umsetzt: https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/nginx

Es gibt dort ein Skript <code>~/bin/addwebsite.sh</code>, das eine Subdomain entsprechend einrichtet, und automatisch das Let's Encrypt Zertifikat signiert und einrichtet.

Ein Systemd Timer wird eingerichtet, der täglich die Gültigkeit des Zertifikates überprüft und gegebenenfalls das Zertifikat erneuert.

Das Ansible Projekt richtet ebenfalls den systemd Service ein, der für den Start des Nginx Servers zuständig ist.

=== Betreiben eines lokalen Nginx ===

Es gibt Konstellationen, da soll die Webseite auf dem zentralen Apache Webserver ausgeliefert werden, aber die Dienste dahinter sind leichter mit Nginx zu konfigurieren.
Das macht auf einem Managed Server Sinn, wo man die Ports frei wählen kann, ohne Rücksicht auf andere Benutzer.
In diesem Beispiel wurde der Port 18003 gewählt, um dort intern den Nginx hören zu lassen.

In diesem Fall kann die Weiterleitung für den Apache so aussehen:

Datei <code>xyz00-nginx@h99:~/doms/demo.example.org/htdocs-ssl/.htaccess</code>:

<syntaxhighlight lang="apache" line>
DirectoryIndex index.html
RewriteEngine on
RewriteBase /
RewriteRule ^(.*) http://127.0.0.1:18003/$1 [proxy,last]
</syntaxhighlight>

Die entsprechende Nginx Konfiguration sieht so aus:

<syntaxhighlight lang="nginx" line>
error_log /home/pacs/xyz00/users/nginx/var/error.log warn;
pid /home/pacs/xyz00/users/nginx/var/nginx.pid;
events {
worker_connections 4096;
}
http {
include /etc/nginx/mime.types;
access_log /home/pacs/xyz00/nginx/var/access.log;
server_names_hash_bucket_size 64;
server {
listen 127.0.0.1:18003;
server_name _;
root /home/pacs/xyz00/users/nginx/htdocs;
index index.html;
}
}
</syntaxhighlight>

Hier gibt es ein Ansible Projekt, das diesen Fall umsetzt: https://codeberg.org/tpokorra/hs.ansible/src/branch/main/roles/nginx

== Links ==

*[https://www.nginx.com/resources/wiki/ Offizielles Wiki von Nginx]
*[https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/nginx Ansible Playbook für Hostsharing]

----

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]

Discourse installieren

2026-06-11T20:29:08Z

Tim00: workaround for issue with pnpm 10

{{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|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 ==

Es müssen noch Erweiterungen für Postgresql installiert werden:

<syntaxhighlight lang=shell line>
psql --user xyz00_discourseuser -c "CREATE EXTENSION IF NOT EXISTS hstore WITH SCHEMA public;"
psql --user xyz00_discourseuser -c "CREATE EXTENSION IF NOT EXISTS pg_trgm WITH SCHEMA public;"
psql --user xyz00_discourseuser -c "CREATE EXTENSION IF NOT EXISTS unaccent WITH SCHEMA public;"
</syntaxhighlight>

== Konfiguration des Redis Server ==

{{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.}}

<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:

<syntaxhighlight lang=shell line>
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
</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 ==

Als User ''xyz00-discourse'': Installation von Ruby mit ''rbenv'' mit folgenden Befehlen:

Zunächst ''rbenv'' and ''ruby-build'':

<syntaxhighlight lang=shell line>
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
</syntaxhighlight>

starte neue Shell:

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

Überprüfe rbenv-Installation

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

Installiere ruby-build als rbenv-Plugin

<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:

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

== Installation von Discourse selber ==

Weiterhin Als User ''xyz00-discourse'':

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

Die stabile Version auschecken:

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

Ruby Pakete installieren:

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

== Konfiguration der Discourse Software ==

Anlegen einer Datei ''/home/pacs/xyz00/users/discourse/discourse/config/discourse.conf'' anhand der Beispiel-Datei:

<syntaxhighlight lang=shell>
cd ~/discourse
cp config/discourse_defaults.conf config/discourse.conf
</syntaxhighlight>

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

<syntaxhighlight lang=shell>
RAILS_ENV=production bundle exec rake secret
</syntaxhighlight>

=== 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 <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 ==

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

[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
</syntaxhighlight>

== Einrichten des Apache VHost ==

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

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:

<syntaxhighlight lang=apache line>
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]
</syntaxhighlight>
== 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.

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

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

<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!

Siehe auch die unterstützten Releases: https://releases.discourse.org/ und die Tags: https://github.com/discourse/discourse/tags

==== Am Beispiel von 2026.1.3 auf 2026.1.4 ====

# 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
# mv ~/plugins.bak/discourse-ai plugins
# git diff v2026.1.3 > diff-2026.1.3.txt
# git fetch
# git checkout -b hostsharing-deployment-v2026.1.4 v2026.1.4
# evtl. Änderungen aus diff-2026.1.3.txt wieder übernehmen und committen
# patch -p1 < diff-2026.1.3.txt
# git commit -a -m "spezifische Änderungen für diese Instanz" --no-verify
# Schauen, ob discourse eine neue Ruby-Version nutzt (z.B. in https://github.com/discourse/discourse_docker/blob/main/image/base/Dockerfile bzw. https://github.com/discourse/discourse/blob/v2026.1.4/Gemfile)
# Ist dies der Fall, dann:
# rbenv install 3.3.8
# rbenv global 3.3.8
# rbenv rehash
# echo "3.3.8" > .ruby-version
# installiere Node 22: https://codeberg.org/tpokorra/hostsharing-scripts/src/branch/main/install-nodejs.sh
# source ~/.profile
# gem update --system
# bundle install
# npm install -g terser uglify-js pnpm@10
#
# to avoid this error: ERR_PNPM_INVALID_DEPENDENCY_NAME The current package contains a dependency with an invalid name: "@types/@glimmer__component"
# vi frontend/discourse-types/package.json

- "@types/@glimmer__component": "npm:@glimmer/component@^2.0.0",
- "@types/@glint__ember-tsc": "npm:@glint/ember-tsc@^1.0.7",
- "@types/@glint__template": "npm:@glint/template@^1.7.2"
+ "@types/glimmer__component": "npm:@glimmer/component@^2.0.0",
+ "@types/glint__ember-tsc": "npm:@glint/ember-tsc@^1.0.7",
+ "@types/glint__template": "npm:@glint/template@^1.7.2"

#
# corepack use pnpm@latest-10
# pnpm install
# export $(grep -v '^#' ~/discourse.env | xargs -d '\n')
# source ~/.profile
# Falls die pg extension pg_vector nicht installiert ist: deaktiviere das Plugin während migrate, aber auch für später damit /admin/settings funktioniert (ansonsten in salt pillar pg_vector installieren, und als postgres user: create extension vector;)
## mkdir -p ~/plugins.bak
## mv plugins/discourse-ai ~/plugins.bak
# 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 ==

* 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

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

Discourse installieren

2026-06-11T20:06:06Z

Tim00: /* Am Beispiel von 2026.1.3 auf 2026.1.4 */

{{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|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 ==

Es müssen noch Erweiterungen für Postgresql installiert werden:

<syntaxhighlight lang=shell line>
psql --user xyz00_discourseuser -c "CREATE EXTENSION IF NOT EXISTS hstore WITH SCHEMA public;"
psql --user xyz00_discourseuser -c "CREATE EXTENSION IF NOT EXISTS pg_trgm WITH SCHEMA public;"
psql --user xyz00_discourseuser -c "CREATE EXTENSION IF NOT EXISTS unaccent WITH SCHEMA public;"
</syntaxhighlight>

== Konfiguration des Redis Server ==

{{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.}}

<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:

<syntaxhighlight lang=shell line>
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
</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 ==

Als User ''xyz00-discourse'': Installation von Ruby mit ''rbenv'' mit folgenden Befehlen:

Zunächst ''rbenv'' and ''ruby-build'':

<syntaxhighlight lang=shell line>
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
</syntaxhighlight>

starte neue Shell:

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

Überprüfe rbenv-Installation

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

Installiere ruby-build als rbenv-Plugin

<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:

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

== Installation von Discourse selber ==

Weiterhin Als User ''xyz00-discourse'':

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

Die stabile Version auschecken:

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

Ruby Pakete installieren:

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

== Konfiguration der Discourse Software ==

Anlegen einer Datei ''/home/pacs/xyz00/users/discourse/discourse/config/discourse.conf'' anhand der Beispiel-Datei:

<syntaxhighlight lang=shell>
cd ~/discourse
cp config/discourse_defaults.conf config/discourse.conf
</syntaxhighlight>

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

<syntaxhighlight lang=shell>
RAILS_ENV=production bundle exec rake secret
</syntaxhighlight>

=== 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 <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 ==

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

[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
</syntaxhighlight>

== Einrichten des Apache VHost ==

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

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:

<syntaxhighlight lang=apache line>
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]
</syntaxhighlight>
== 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.

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

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

<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!

Siehe auch die unterstützten Releases: https://releases.discourse.org/ und die Tags: https://github.com/discourse/discourse/tags

==== Am Beispiel von 2026.1.3 auf 2026.1.4 ====

# 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
# mv ~/plugins.bak/discourse-ai plugins
# git diff v2026.1.3 > diff-2026.1.3.txt
# git fetch
# git checkout -b hostsharing-deployment-v2026.1.4 v2026.1.4
# evtl. Änderungen aus diff-2026.1.3.txt wieder übernehmen und committen
# patch -p1 < diff-2026.1.3.txt
# git commit -a -m "spezifische Änderungen für diese Instanz" --no-verify
# Schauen, ob discourse eine neue Ruby-Version nutzt (z.B. in https://github.com/discourse/discourse_docker/blob/main/image/base/Dockerfile bzw. https://github.com/discourse/discourse/blob/v2026.1.4/Gemfile)
# Ist dies der Fall, dann:
# rbenv install 3.3.8
# rbenv global 3.3.8
# rbenv rehash
# echo "3.3.8" > .ruby-version
# installiere Node 22: https://codeberg.org/tpokorra/hostsharing-scripts/src/branch/main/install-nodejs.sh
# source ~/.profile
# gem update --system
# bundle install
# npm install -g terser uglify-js pnpm@10
# corepack use pnpm@latest-10
# pnpm install
# export $(grep -v '^#' ~/discourse.env | xargs -d '\n')
# source ~/.profile
# Falls die pg extension pg_vector nicht installiert ist: deaktiviere das Plugin während migrate, aber auch für später damit /admin/settings funktioniert (ansonsten in salt pillar pg_vector installieren, und als postgres user: create extension vector;)
## mkdir -p ~/plugins.bak
## mv plugins/discourse-ai ~/plugins.bak
# 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 ==

* 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

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