Hostsharing Wiki - Benutzerbeiträge [de]

Mailman 3 installieren

2025-10-07T20:55:03Z

Tim: /* Web Frontend */ compress

Die folgende Anleitung zur Installation von Mailman 3 auf Hostsharing geht davon aus, dass als Domäne ''lists.example.org'' und als Domänennutzer ''xyz00-lists'' verwendet wird. Es ist zu empfehlen, auszuführende Befehle und Konfigurationen vorab auf zu ersetzende Werte zu prüfen. Alle Befehle sind als Benutzer ''xyz00-lists'' zu starten. Damit mehrere aufeinander folgende Shell-Kommandos leichter kopiert werden können, wird nur vor das jeweils erste Kommando ein ''$'' gesetzt. Zum Verständnis mancher der folgenden Anweisungen kann es hilfreich sein, die [https://mailman.readthedocs.io/ Mailman-Dokumentation] gelesen und sich mit [https://pipenv.readthedocs.io/en/latest/ Pipenv] beschäftigt zu haben.

Achtung: Mailman 3 benötigt zahlreiche Hintergrundprozesse, was beim Managed Webspace zusätzliche Kosten verursacht.

== Datenbank ==
Zunächst muss eine PostgreSQL- oder MySQL-Datenbank angelegt werden. (Mailman läuft auch mit SQLite, ist aber für den Produktivbetrieb nicht empfohlen.) Je nach gewählter Datenbank unterscheiden sich manche Schritte geringfügig, was an den entsprechenden Stellen dokumentiert ist.

== Mailman Core ==
Für die Installation von Mailman Core sind folgende Kommandos auszuführen:

<syntaxhighlight lang="bash" line>
pip3 install --user pipenv
echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.profile
source ~/.profile
mkdir ~/mailman
cd ~/mailman
pipenv install mailman
pipenv install mailman_hyperkitty
pipenv install psycopg2-binary # Für PostgreSQL
pipenv install pymysql # Für MySQL
</syntaxhighlight>

Hinweis: Das Kommando <code>pipenv</code> muss immer im Verzeichnis <code>~/mailman</code> ausgeführt werden.

Anschließend wird das Verzeichnis für die Konfigurationsdatei angelegt:
<syntaxhighlight lang="bash">
mkdir -p ~/mailman/etc
</syntaxhighlight>

Die Konfiguration wird in die Datei <code>~/mailman/core/etc/mailman.cfg</code> geschrieben:

<syntaxhighlight lang="ini" line>
[mailman]
site_owner: admin@example.org
default_language: de

[paths.here]
var_dir: $cwd/core

[database] # https://mailman.readthedocs.io/en/latest/src/mailman/docs/database.html
class: mailman.database.postgresql.PostgreSQLDatabase
url: postgresql://myuser:mypassword@mypghost/mailman
# Fallls MySQL verwendet:
#class: mailman.database.mysql.MySQLDatabase
#url: mysql+pymysql://myuser:mypassword@mymysqlhost/mailman?charset=utf8&use_unicode=1
# SQLite ist Standard, wenn nichts konfiguriert ist

[webservice] # REST Service von Mailman. Wird von [[#Web_Frontend|Web Frontend]] verwendet
port: 8001 # ändern, falls belegt
admin_user: restadmin
admin_pass: restpass

[mta]
smtp_host: xyz00.hostsharing.net
smtp_port: 4587
smtp_user: xyz00-lists
smtp_pass: secret
smtp_secure_mode: starttls
# https://mailman.readthedocs.io/en/latest/src/mailman/docs/mta.html
# NullMTA, da MTA nicht selbst konfiguriert werden kann
incoming: mailman.mta.null.NullMTA
lmtp_port: 8024 # ändern, falls belegt

[runner.nntp]
# Runner für [https://de.wikipedia.org/wiki/Network_News_Transfer_Protocol NNTP] Gateway ausschalten
start: no

[archiver.hyperkitty]
class: mailman_hyperkitty.Archiver
enable: yes
# $HOME muss durch den tatsächlichen Pfad zum Benutzerverzeichnis ersetzt werden
configuration: $HOME/mailman/core/etc/mailman-hyperkitty.cfg
</syntaxhighlight>

Zugriffsrechte einschränken:
<syntaxhighlight lang="bash">chmod 0600 ~/mailman/core/etc/mailman.cfg</syntaxhighlight>

Damit Hyperkitty als [[#Web_Frontend|Web Frontend]] für das Archiv verwendet werden kann, ist in die Datei <code>~/mailman/core/etc/mailman-hyperkitty.cfg</code> Foglendes zu schreiben:
<syntaxhighlight lang="ini" line>
[general]
base_url: https://lists.example.org/hyperkitty/
# Muss identisch mit Key in Hyperkitty sein (s.u.)
api_key: SecretArchiverAPIKey
</syntaxhighlight>

Zugriffsrechte einschränken:
<syntaxhighlight lang="bash">chmod 0600 ~/mailman/core/etc/mailman-hyperkitty.cfg</syntaxhighlight>

Kommando ''mailman'' anlegen:
<syntaxhighlight lang="bash" line>
cat <<'EOD' >~/.local/bin/mailman
#!/bin/sh

export MAILMAN_CONFIG_FILE=$HOME/mailman/core/etc/mailman.cfg
cd ~/mailman
pipenv run mailman "$@"
EOD

chmod +x ~/.local/bin/mailman
</syntaxhighlight>

Hinweis: Da in <code>mailman</code> das Verzeichnis gewechselt wird, funktionieren relative Pfadangaben als Argument nicht bzw. nur, wenn man sich bereits in <code>~/mailman</code> befindet.

Nun kann mit <code>mailman info</code> nochmal die aktuelle Konfiguration geprüft werden.
Danach kann Mailman gestartet werden:
mailman start

== Web Frontend ==
In diesem Abschnitt wird die Installation des Web Frontends beschrieben.

Zunächst werden die Redirects aus der <code>.htaccess</code> gelöscht:
<syntaxhighlight lang="bash">echo "" > ~/doms/lists.example.org/htdocs-ssl/.htaccess</syntaxhighlight>

Anschließend werden die erforderlichen Python-Pakete installiert:
<syntaxhighlight lang="bash">
cd ~/mailman
pipenv install mailman-web
</syntaxhighlight>

Um Plattenplatz freizugeben, kann optional der Pip Cache gelöscht werden:
<syntaxhighlight lang="bash">pipenv --clear</syntaxhighlight>

Zur Konfiguration von Hyperkitty wird die IP-Adresse benötigt, von der die Anfragen von Mailman Core kommen. Diese kann wie folgt ermittelt werden:
<syntaxhighlight lang="bash" line>
cat <<EOD >~/doms/lists.example.org/htdocs-ssl/ip.php
<?php
echo \$_SERVER['REMOTE_ADDR'] . "\n";
EOD

curl <nowiki>https://lists.example.org/ip.php</nowiki>
rm ~/doms/lists.example.org/htdocs-ssl/ip.php
</syntaxhighlight>

Die Konfiguration wird nun in Die Datei <code>~/mailman/web/settings.py</code> geschrieben:
<syntaxhighlight lang="python" line>
# See https://mailman-web.readthedocs.io/en/latest/settings.html

from mailman_web.settings.base import *
from mailman_web.settings.mailman import *

BASE_DIR = os.path.join(os.environ['HOME'], 'mailman', 'web')

# Default path where static files will be placed.
# 'collectstatic' command will copy all the static files here.
# Alias this location from your webserver to `/static`
STATIC_ROOT = os.path.join(BASE_DIR, 'static')

# Make sure that the directory is created or Django will fail on start.
LOGGING['handlers']['file']['filename'] = os.path.join(BASE_DIR, 'logs', 'mailmanweb.log')

# Change path of Whoosh index
HAYSTACK_CONNECTIONS['default']['PATH'] = os.path.join(BASE_DIR, 'whoosh_index')

# django-compressor
# https://pypi.python.org/pypi/django_compressor
COMPRESS_PRECOMPILERS = (
('text/x-scss', 'sass -t compressed {infile} {outfile}'),
('text/x-sass', 'sass -t compressed {infile} {outfile}'),
)

# https://django-q.readthedocs.io/en/latest/configure.html
# 1 worker is probably enough. (Default is 3.)
Q_CLUSTER['workers'] = 1

# Default list of admins who receive the emails from error logging.
# https://docs.djangoproject.com/en/dev/ref/settings/#admins
ADMINS = (
('Mailman Admin', 'admin@example.org'),
)
# Database setup.
# https://docs.djangoproject.com/en/dev/ref/settings/#databases
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.postgresql_psycopg2', # Für MySQL: django.db.backends.mysql
'HOST': 'localhost',
'NAME': 'database_name',
'USER': 'database_user',
'PASSWORD': 'database_password',
}
}

# Hosts/domain names that are valid for this site; required if DEBUG is False.
# https://docs.djangoproject.com/en/dev/ref/settings/#allowed-hosts
ALLOWED_HOSTS = [
'lists.example.org',
]

# A secret key for a particular Django installation. This is used to provide
# cryptographic signing, and should be set to a unique, unpredictable value.
# https://docs.djangoproject.com/en/dev/ref/settings/#secret-key
SECRET_KEY = 'change-this-on-your-production-server'

# Mailman Core default API Path
MAILMAN_REST_API_URL = 'http://localhost:8001'
# Mailman Core API user
MAILMAN_REST_API_USER = 'restadmin'
# Mailman Core API user's password.
MAILMAN_REST_API_PASS = 'restpass'
# Mailman Core Shared archiving key. This value is set in the
# mailman-hyperkitty's configuration file.
MAILMAN_ARCHIVER_KEY = 'SecretArchiverAPIKey'
# Host for Mailman Core, from where Hyperkitty will accept connections
# for archiving.
MAILMAN_ARCHIVER_FROM = ('<IP von Mailman Core>')

# Base URL where Django/Mailman-web would be listening for requests. Used by
# Mailman Core for fetching templates.
POSTORIUS_TEMPLATE_BASE_URL = 'https://lists.example.org'

# Sender in emails sent out by Postorius.
# https://docs.djangoproject.com/en/dev/ref/settings/#std:setting-DEFAULT_FROM_EMAIL
DEFAULT_FROM_EMAIL = 'postorius@lists.example.org'

# If you enable email reporting for error messages, this is where those emails
# will appear to be coming from. Make sure you set a valid domain name,
# otherwise the emails may get rejected.
# https://docs.djangoproject.com/en/dev/ref/settings/#std:setting-SERVER_EMAIL
SERVER_EMAIL = 'django@lists.example.org'

# Configuration used to send emails.
# https://docs.djangoproject.com/en/dev/ref/settings/#email-host
EMAIL_HOST = 'xyz00.hostsharing.net'
EMAIL_PORT = 4587
EMAIL_USE_TLS = True
EMAIL_HOST_USER = 'xyz00-lists'
EMAIL_HOST_PASSWORD = 'secret'
EMAIL_TIMEOUT = 60

# A string representing the time zone for this installation.
# https://docs.djangoproject.com/en/dev/ref/settings/#std:setting-TIME_ZONE
TIME_ZONE = 'Europe/Berlin'

# A string representing the language code for this installation.
# https://docs.djangoproject.com/en/dev/ref/settings/#language-code
LANGUAGE_CODE = 'de-de'

# Disable support for gravatars in HyperKitty and Postorius.
# https://docs.mailman3.org/projects/hyperkitty/en/latest/install.html#customization
HYPERKITTY_ENABLE_GRAVATAR = False

# Hinweis: In der derzeit aktuellen Version (1.3.5) der Komponente
# django-mailman3 wird obige Variable nicht berücksichtigt. Deshalb kann die
# folgende Direktive nur mit dem Entwicklungsstand aus git einkommentiert werden.
# django_gravatar is not required, anymore.
#INSTALLED_APPS.remove('django_gravatar')
</syntaxhighlight>

Zugriffsrechte einschränken:
<syntaxhighlight lang="bash">chmod 600 ~/mailman/web/settings.py</syntaxhighlight>

Hinweis: Wird die Konfiguration geändert, nachdem das Web Frontend aufgerufen wurde, muss es neu gestartet werden:
<syntaxhighlight lang="bash" line>
mkdir -p ~/doms/lists.example.org/app-ssl/tmp
touch ~/doms/lists.example.org/app-ssl/tmp/restart.txt
</syntaxhighlight>

Das für Logs definierte Verzeichnis anlegen:
<syntaxhighlight lang="bash">mkdir -p ~/mailman/web/logs</syntaxhighlight>

Damit per Django verfügbare Kommandos leicht ausgeführt werden können, wird der Befehl ''mailman-web'' eingerichtet:
<syntaxhighlight lang="bash" line>
cat <<'EOD' >~/.local/bin/mailman-web
#!/bin/sh

export MAILMAN_WEB_CONFIG=$HOME/mailman/web/settings.py
cd ~/mailman
pipenv run mailman-web "$@"
EOD
chmod +x ~/.local/bin/mailman-web
</syntaxhighlight>

Anschließend wird das Datenbankschema eingerichtet:
<syntaxhighlight lang="bash">mailman-web migrate</syntaxhighlight>

Mit dem folgenden Kommando werden statische Daten für das Web Frontend ins konfigurierte Verzeichnis geschrieben:
<syntaxhighlight lang="bash">mailman-web collectstatic</syntaxhighlight>

Um den Fehler zu vermeiden: "You have offline compression enabled but key ... is missing"
<syntaxhighlight lang="bash">mailman-web compress</syntaxhighlight>

Nun müssen die statischen Dateien für das Web Frontend noch per HTTPS verfügbar gemacht werden:
<syntaxhighlight lang="bash">ln -s ~/mailman/mailman-suite/mailman-suite_project/static ~/doms/lists.example.org/htdocs-ssl/</syntaxhighlight>

Zum Anlegen des Administrators des Web Frontends wird dieser Befehl ausgeführt:
<syntaxhighlight lang="bash">mailman-web createsuperuser</syntaxhighlight>

Da die Übersetzungsdateien nur in Mailman Core, jedoch nicht bei den Web Frontend Komponenten im Binärformat enthalten sind, muss die Konvertierung nachgeholt werden:
<syntaxhighlight lang="bash" line>
for pofile in $(find $(pipenv --venv) -path '*/locale/*/LC_MESSAGES/*.po'); do
mofile=${pofile/.po/.mo}
if [ ! -f $mofile ] || [ $pofile -nt $mofile ]; then
echo $pofile
msgfmt $pofile -o $mofile -v
fi
done
</syntaxhighlight>

Damit das Web Frontend per [[Phusion_Passenger|Phusion Passenger]] geladen werden kann:

<syntaxhighlight lang="python" line>
cat <<EOD >~/doms/lists.example.org/app-ssl/passenger_wsgi.py
import os
import subprocess
import sys

os.environ['LANG'] = 'C.UTF-8'
os.environ['LC_ALL'] = 'C.UTF-8'

HOME = os.environ['HOME']
PIPENV = os.path.join(HOME, '.local', 'bin', 'pipenv')
PIPFILE_DIR = os.path.join(HOME, 'mailman')
PIPENV_PYTHON = subprocess.check_output([PIPENV, '--py'], cwd=PIPFILE_DIR).strip().decode('utf-8')
if sys.executable != PIPENV_PYTHON:
os.execl(PIPENV_PYTHON, PIPENV_PYTHON, *sys.argv)

os.environ['MAILMAN_WEB_CONFIG'] = os.path.join(HOME, 'mailman', 'web', 'settings.py')
from mailman_web.wsgi import application
EOD
</syntaxhighlight>

Nun steht das Web Frontend unter <code><nowiki>https://lists.example.org/</nowiki></code> zur Verfügung. Über die Django Administration sollte unter <code><nowiki>https://lists.example.org/admin/sites/site/1/change/</nowiki></code> die Domäne angepasst werden.

== Mails an Mailman weiterleiten ==
Da die MTA-Konfiguration nicht direkt angepasst werden kann, ist ein Hilfskonstrukt erforderlich: Mittels ''.forward-Datei'' werden eingehende Mails an das Programm <code>msmtp</code> weitergeleitet, welches diese per [https://de.wikipedia.org/wiki/Local_Mail_Transfer_Protocol LMTP] bei Mailman abliefert. msmtp ist auf den Managed Servern vorinstalliert.

MM_LMTP_PORT=8024 # In Mailman Core konfigurierter Port
cat <<EOD >.forward+mailman
"|/usr/bin/msmtp --host=localhost --port=$MM_LMTP_PORT --protocol=lmtp --read-envelope-from \$(echo \$ORIGINAL_RECIPIENT | sed 's/+.\+@/@/')"
EOD

Der <code>sed</code> Befehl ist erforderlich, damit Mails mit ''Plus Addressing'' mit der eigentlichen Empfängeradresse bei Mailman ankommen.

Für die Domain <code>lists.example.org</code> wird in HSAdmin oder per <code>hssscript</code> eine Catchall-Adresse mit <code>xyz00-lists+mailman</code> als Ziel eingerichtet. Bei einer Catchall-Adresse wird als <code>localpart</code> ein leerer String angegeben.

== Dienste starten und überwachen ==
Für die beiden benötigten Dienste kann ''monit'' wie folgt konfiguriert werden:

<syntaxhighlight lang="bash" line>
mkdir monit
cat <<EOD >~/.monitrc
set daemon 60
with start delay 90
set httpd unixsocket $HOME/monit/monit.sock
permission 600
allow mailman:monit
set mailserver localhost
set mail-format { from: monit@lists.example.org }
set alert admin@example.org
set logfile $HOME/monit/monit.log
set idfile $HOME/monit/monit.id
set pidfile $HOME/monit/monit.pid
set statefile $HOME/monit/monit.state

check process mailman
pidfile $HOME/mailman/core/master.pid
start program = "$HOME/.local/bin/mailman start"
stop program = "$HOME/.local/bin/mailman stop"
restart program = "$HOME/.local/bin/mailman restart"

check process mailman-web-qcluster
matching "mailman-web qcluster"
start program = "/bin/bash -c 'nohup $HOME/.local/bin/mailman-web qcluster >>$HOME/mailman/web/logs/qcluster.log 2>&1 &'"
stop program = "/usr/bin/pkill -f 'mailman-web qcluster'"
depends on mailman
EOD
</syntaxhighlight>

Dienste starten:
<syntaxhighlight lang="bash">monit</syntaxhighlight>

Für <code>mailman-web qcluster</code> kann alternativ ein minütlich laufender Systemd Timer verwendet werden.

== Logrotation ==
Die Rotation der Logdateien kann so konfiguriert werden:

<syntaxhighlight lang="bash" line>
cat <<EOD >~/logrotate.conf
compress
delaycompress
missingok
notifempty
dateext

$HOME/monit/monit.log {
rotate 1
weekly
maxsize 1M
}

$HOME/mailman/core/logs/*.log {
rotate 6
daily
sharedscripts
postrotate
$HOME/.local/bin/mailman reopen >/dev/null ||:
endscript
}

$HOME/mailman/web/logs/mailmanweb.log {
rotate 6
daily
}

$HOME/mailman/web/logs/qcluster.log {
rotate 1
size 100k
postrotate
/usr/bin/monit restart mailman-web-qcluster >/dev/null ||:
endscript
}
EOD
</syntaxhighlight>

Hinweis: <code>qcluster.log</code> wird hier nur bei Überschreiten der definierten Größe rotiert, um regelmäßige Mails von ''monit'' zu vermeiden.

== Cron Jobs ==
Für Mailman sind verschiedene Cron Jobs erforderlich. Zudem sollen nach einem Neustart die <code>monit</code> Dienste gestartet werden und täglich eine Logrotation erfolgen. Die Einrichtung kann so erfolgen (eine bereits existierende crontab wird überschrieben):

<syntaxhighlight lang="bash" line>
cat <<EOD | crontab -
MAILTO=admin@example.org
HOME=$HOME
PATH=$HOME/.local/bin:/usr/bin:/bin:/usr/sbin

@reboot rm -f \$HOME/monit/monit.pid \$HOME/mailman/core/master.pid && monit

@daily logrotate -s \$HOME/.logrotate_state \$HOME/logrotate.conf

# Send periodic digests.
@daily mailman digests --send

* * * * * mailman-web runjobs minutely
2,17,32,47 * * * * mailman-web runjobs quarter_hourly
@hourly mailman-web runjobs hourly
@daily mailman-web runjobs daily
@weekly mailman-web runjobs weekly
@monthly mailman-web runjobs monthly
@yearly mailman-web runjobs yearly
EOD
</syntaxhighlight>

Soll eine existierende crontab nicht überschrieben werden, muss das Kommando <code>crontab -e</code> ausgeführt und die crontab entsprechend angepasst werden. (Dabei <code>\$HOME</code> mit <code>$HOME</code> und <code>$HOME</code> mit dem Pfad des Benutzerverzeichnisses ersetzen.)

== Liste anlegen ==
Damit Mailman tatsächlich genutzt werden kann, muss natürlich eine Liste eingerichtet werden.
<syntaxhighlight lang=bash>mailman create meine-erste-liste@lists.example.org # Alternativ über Web Frontend</syntaxhighlight>

Außerdem müssen die E-Mail Adressen für die Mailingliste angelegt werden, im HSAdmin. Zum Beispiel für die Liste meine-erste-liste: meine-erste-liste, meine-erste-liste-join, meine-erste-liste-leave, meine-erste-liste-owner, für die Domain lists.example.org. Die E-Mails sollen in das Postfach gehen, wo mailman installiert ist.
Alternativ kann eine Catch-All Adresse eingerichtet werden, damit alle E-Mails an die Subdomain in das Postfach vom mailman gehen. Der Catch-All ist laut Postfix Regeln eine Adresse mit einem leeren lokalen Teil (siehe auch der Screenshot in der [[Sympa_installieren#Neue_Liste_einrichten|entsprechenden Anleitung von Sympa]]).

== Die Selbst-Registrierung von Benutzern verhindern ==

Per Default kann sich jede Person im Mailman3 ein Benutzerkonto anlegen. Wenn das nicht erwünscht ist, kann in der Datei <code>var/etc/settings.py</code> die folgende Zeile hinzugefügt werden:

<syntaxhighlight lang="python">
ACCOUNT_ADAPTER = 'django_mailman3.views.user_adapter.DisableSignupAdapter'
</syntaxhighlight>

Es können in diesem Fall im Django Backend durch den Administrator Benutzerkonten angelegt werden, auf https://lists.example.org/admin/auth/user/

== Update ==
Mailman lässt sich wie im Folgenden beschrieben aktualisieren.

Python-Pakete für die Aktualisierungen vorliegen ausgeben:

<syntaxhighlight lang="bash">
cd ~/mailman
pipenv update --outdated
</syntaxhighlight>

Vor dem eigentlichen Update empfiehlt es sich, die Release Notes (zumindest von [https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/docs/NEWS.html Mailman]) zu lesen und auf relevante Änderungen zu prüfen.

Mailman stoppen:
<syntaxhighlight lang="bash">
monit stop mailman
</syntaxhighlight>

Update der Pakete:

<syntaxhighlight lang="bash">
pipenv update
</syntaxhighlight>

Ggf. Pip Cache löschen:

<syntaxhighlight lang="bash">
pipenv --clear
</syntaxhighlight>

Datenbankmigrationen durchführen:
<syntaxhighlight lang="bash">
mailman-web makemigrations
mailman-web migrate
</syntaxhighlight>

Übersetzungen aktualisieren:
<syntaxhighlight lang="bash" line>
for pofile in $(find $(pipenv --venv) -path '*/locale/*/LC_MESSAGES/*.po'); do
mofile=${pofile/.po/.mo}
if [ ! -f $mofile ] || [ $pofile -nt $mofile ]; then
echo $pofile
msgfmt $pofile -o $mofile -v
fi
done
</syntaxhighlight>

Statische Dateien aktualisieren:
<syntaxhighlight lang="bash">mailman-web collectstatic -c</syntaxhighlight>

Abschließend die Dienste wieder starten:
<syntaxhighlight lang="bash">
monit start mailman
monit start mailman-web-qcluster
</syntaxhighlight>

Web Frontend neu starten:
<syntaxhighlight lang="bash">
mkdir -p ~/doms/lists.example.org/app-ssl/tmp
touch ~/doms/lists.example.org/app-ssl/tmp/restart.txt
</syntaxhighlight>

== Links ==
* [https://docs.mailman3.org/en/latest/ Offizielle Anleitung für Mailman3]
* [https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/mailman3 Ansible Playbook für Hostsharing]

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]
[[Kategorie:Software]]
[[Kategorie:Mailinglisten]]
[[Kategorie:E-Mail]]
[[Kategorie:Python]]

Mailman 3 installieren

2025-10-07T20:50:37Z

Tim: Links und Link zu Ansible Playbook hinzugefügt

Die folgende Anleitung zur Installation von Mailman 3 auf Hostsharing geht davon aus, dass als Domäne ''lists.example.org'' und als Domänennutzer ''xyz00-lists'' verwendet wird. Es ist zu empfehlen, auszuführende Befehle und Konfigurationen vorab auf zu ersetzende Werte zu prüfen. Alle Befehle sind als Benutzer ''xyz00-lists'' zu starten. Damit mehrere aufeinander folgende Shell-Kommandos leichter kopiert werden können, wird nur vor das jeweils erste Kommando ein ''$'' gesetzt. Zum Verständnis mancher der folgenden Anweisungen kann es hilfreich sein, die [https://mailman.readthedocs.io/ Mailman-Dokumentation] gelesen und sich mit [https://pipenv.readthedocs.io/en/latest/ Pipenv] beschäftigt zu haben.

Achtung: Mailman 3 benötigt zahlreiche Hintergrundprozesse, was beim Managed Webspace zusätzliche Kosten verursacht.

== Datenbank ==
Zunächst muss eine PostgreSQL- oder MySQL-Datenbank angelegt werden. (Mailman läuft auch mit SQLite, ist aber für den Produktivbetrieb nicht empfohlen.) Je nach gewählter Datenbank unterscheiden sich manche Schritte geringfügig, was an den entsprechenden Stellen dokumentiert ist.

== Mailman Core ==
Für die Installation von Mailman Core sind folgende Kommandos auszuführen:

<syntaxhighlight lang="bash" line>
pip3 install --user pipenv
echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.profile
source ~/.profile
mkdir ~/mailman
cd ~/mailman
pipenv install mailman
pipenv install mailman_hyperkitty
pipenv install psycopg2-binary # Für PostgreSQL
pipenv install pymysql # Für MySQL
</syntaxhighlight>

Hinweis: Das Kommando <code>pipenv</code> muss immer im Verzeichnis <code>~/mailman</code> ausgeführt werden.

Anschließend wird das Verzeichnis für die Konfigurationsdatei angelegt:
<syntaxhighlight lang="bash">
mkdir -p ~/mailman/etc
</syntaxhighlight>

Die Konfiguration wird in die Datei <code>~/mailman/core/etc/mailman.cfg</code> geschrieben:

<syntaxhighlight lang="ini" line>
[mailman]
site_owner: admin@example.org
default_language: de

[paths.here]
var_dir: $cwd/core

[database] # https://mailman.readthedocs.io/en/latest/src/mailman/docs/database.html
class: mailman.database.postgresql.PostgreSQLDatabase
url: postgresql://myuser:mypassword@mypghost/mailman
# Fallls MySQL verwendet:
#class: mailman.database.mysql.MySQLDatabase
#url: mysql+pymysql://myuser:mypassword@mymysqlhost/mailman?charset=utf8&use_unicode=1
# SQLite ist Standard, wenn nichts konfiguriert ist

[webservice] # REST Service von Mailman. Wird von [[#Web_Frontend|Web Frontend]] verwendet
port: 8001 # ändern, falls belegt
admin_user: restadmin
admin_pass: restpass

[mta]
smtp_host: xyz00.hostsharing.net
smtp_port: 4587
smtp_user: xyz00-lists
smtp_pass: secret
smtp_secure_mode: starttls
# https://mailman.readthedocs.io/en/latest/src/mailman/docs/mta.html
# NullMTA, da MTA nicht selbst konfiguriert werden kann
incoming: mailman.mta.null.NullMTA
lmtp_port: 8024 # ändern, falls belegt

[runner.nntp]
# Runner für [https://de.wikipedia.org/wiki/Network_News_Transfer_Protocol NNTP] Gateway ausschalten
start: no

[archiver.hyperkitty]
class: mailman_hyperkitty.Archiver
enable: yes
# $HOME muss durch den tatsächlichen Pfad zum Benutzerverzeichnis ersetzt werden
configuration: $HOME/mailman/core/etc/mailman-hyperkitty.cfg
</syntaxhighlight>

Zugriffsrechte einschränken:
<syntaxhighlight lang="bash">chmod 0600 ~/mailman/core/etc/mailman.cfg</syntaxhighlight>

Damit Hyperkitty als [[#Web_Frontend|Web Frontend]] für das Archiv verwendet werden kann, ist in die Datei <code>~/mailman/core/etc/mailman-hyperkitty.cfg</code> Foglendes zu schreiben:
<syntaxhighlight lang="ini" line>
[general]
base_url: https://lists.example.org/hyperkitty/
# Muss identisch mit Key in Hyperkitty sein (s.u.)
api_key: SecretArchiverAPIKey
</syntaxhighlight>

Zugriffsrechte einschränken:
<syntaxhighlight lang="bash">chmod 0600 ~/mailman/core/etc/mailman-hyperkitty.cfg</syntaxhighlight>

Kommando ''mailman'' anlegen:
<syntaxhighlight lang="bash" line>
cat <<'EOD' >~/.local/bin/mailman
#!/bin/sh

export MAILMAN_CONFIG_FILE=$HOME/mailman/core/etc/mailman.cfg
cd ~/mailman
pipenv run mailman "$@"
EOD

chmod +x ~/.local/bin/mailman
</syntaxhighlight>

Hinweis: Da in <code>mailman</code> das Verzeichnis gewechselt wird, funktionieren relative Pfadangaben als Argument nicht bzw. nur, wenn man sich bereits in <code>~/mailman</code> befindet.

Nun kann mit <code>mailman info</code> nochmal die aktuelle Konfiguration geprüft werden.
Danach kann Mailman gestartet werden:
mailman start

== Web Frontend ==
In diesem Abschnitt wird die Installation des Web Frontends beschrieben.

Zunächst werden die Redirects aus der <code>.htaccess</code> gelöscht:
<syntaxhighlight lang="bash">echo "" > ~/doms/lists.example.org/htdocs-ssl/.htaccess</syntaxhighlight>

Anschließend werden die erforderlichen Python-Pakete installiert:
<syntaxhighlight lang="bash">
cd ~/mailman
pipenv install mailman-web
</syntaxhighlight>

Um Plattenplatz freizugeben, kann optional der Pip Cache gelöscht werden:
<syntaxhighlight lang="bash">pipenv --clear</syntaxhighlight>

Zur Konfiguration von Hyperkitty wird die IP-Adresse benötigt, von der die Anfragen von Mailman Core kommen. Diese kann wie folgt ermittelt werden:
<syntaxhighlight lang="bash" line>
cat <<EOD >~/doms/lists.example.org/htdocs-ssl/ip.php
<?php
echo \$_SERVER['REMOTE_ADDR'] . "\n";
EOD

curl <nowiki>https://lists.example.org/ip.php</nowiki>
rm ~/doms/lists.example.org/htdocs-ssl/ip.php
</syntaxhighlight>

Die Konfiguration wird nun in Die Datei <code>~/mailman/web/settings.py</code> geschrieben:
<syntaxhighlight lang="python" line>
# See https://mailman-web.readthedocs.io/en/latest/settings.html

from mailman_web.settings.base import *
from mailman_web.settings.mailman import *

BASE_DIR = os.path.join(os.environ['HOME'], 'mailman', 'web')

# Default path where static files will be placed.
# 'collectstatic' command will copy all the static files here.
# Alias this location from your webserver to `/static`
STATIC_ROOT = os.path.join(BASE_DIR, 'static')

# Make sure that the directory is created or Django will fail on start.
LOGGING['handlers']['file']['filename'] = os.path.join(BASE_DIR, 'logs', 'mailmanweb.log')

# Change path of Whoosh index
HAYSTACK_CONNECTIONS['default']['PATH'] = os.path.join(BASE_DIR, 'whoosh_index')

# django-compressor
# https://pypi.python.org/pypi/django_compressor
COMPRESS_PRECOMPILERS = (
('text/x-scss', 'sass -t compressed {infile} {outfile}'),
('text/x-sass', 'sass -t compressed {infile} {outfile}'),
)

# https://django-q.readthedocs.io/en/latest/configure.html
# 1 worker is probably enough. (Default is 3.)
Q_CLUSTER['workers'] = 1

# Default list of admins who receive the emails from error logging.
# https://docs.djangoproject.com/en/dev/ref/settings/#admins
ADMINS = (
('Mailman Admin', 'admin@example.org'),
)
# Database setup.
# https://docs.djangoproject.com/en/dev/ref/settings/#databases
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.postgresql_psycopg2', # Für MySQL: django.db.backends.mysql
'HOST': 'localhost',
'NAME': 'database_name',
'USER': 'database_user',
'PASSWORD': 'database_password',
}
}

# Hosts/domain names that are valid for this site; required if DEBUG is False.
# https://docs.djangoproject.com/en/dev/ref/settings/#allowed-hosts
ALLOWED_HOSTS = [
'lists.example.org',
]

# A secret key for a particular Django installation. This is used to provide
# cryptographic signing, and should be set to a unique, unpredictable value.
# https://docs.djangoproject.com/en/dev/ref/settings/#secret-key
SECRET_KEY = 'change-this-on-your-production-server'

# Mailman Core default API Path
MAILMAN_REST_API_URL = 'http://localhost:8001'
# Mailman Core API user
MAILMAN_REST_API_USER = 'restadmin'
# Mailman Core API user's password.
MAILMAN_REST_API_PASS = 'restpass'
# Mailman Core Shared archiving key. This value is set in the
# mailman-hyperkitty's configuration file.
MAILMAN_ARCHIVER_KEY = 'SecretArchiverAPIKey'
# Host for Mailman Core, from where Hyperkitty will accept connections
# for archiving.
MAILMAN_ARCHIVER_FROM = ('<IP von Mailman Core>')

# Base URL where Django/Mailman-web would be listening for requests. Used by
# Mailman Core for fetching templates.
POSTORIUS_TEMPLATE_BASE_URL = 'https://lists.example.org'

# Sender in emails sent out by Postorius.
# https://docs.djangoproject.com/en/dev/ref/settings/#std:setting-DEFAULT_FROM_EMAIL
DEFAULT_FROM_EMAIL = 'postorius@lists.example.org'

# If you enable email reporting for error messages, this is where those emails
# will appear to be coming from. Make sure you set a valid domain name,
# otherwise the emails may get rejected.
# https://docs.djangoproject.com/en/dev/ref/settings/#std:setting-SERVER_EMAIL
SERVER_EMAIL = 'django@lists.example.org'

# Configuration used to send emails.
# https://docs.djangoproject.com/en/dev/ref/settings/#email-host
EMAIL_HOST = 'xyz00.hostsharing.net'
EMAIL_PORT = 4587
EMAIL_USE_TLS = True
EMAIL_HOST_USER = 'xyz00-lists'
EMAIL_HOST_PASSWORD = 'secret'
EMAIL_TIMEOUT = 60

# A string representing the time zone for this installation.
# https://docs.djangoproject.com/en/dev/ref/settings/#std:setting-TIME_ZONE
TIME_ZONE = 'Europe/Berlin'

# A string representing the language code for this installation.
# https://docs.djangoproject.com/en/dev/ref/settings/#language-code
LANGUAGE_CODE = 'de-de'

# Disable support for gravatars in HyperKitty and Postorius.
# https://docs.mailman3.org/projects/hyperkitty/en/latest/install.html#customization
HYPERKITTY_ENABLE_GRAVATAR = False

# Hinweis: In der derzeit aktuellen Version (1.3.5) der Komponente
# django-mailman3 wird obige Variable nicht berücksichtigt. Deshalb kann die
# folgende Direktive nur mit dem Entwicklungsstand aus git einkommentiert werden.
# django_gravatar is not required, anymore.
#INSTALLED_APPS.remove('django_gravatar')
</syntaxhighlight>

Zugriffsrechte einschränken:
<syntaxhighlight lang="bash">chmod 600 ~/mailman/web/settings.py</syntaxhighlight>

Hinweis: Wird die Konfiguration geändert, nachdem das Web Frontend aufgerufen wurde, muss es neu gestartet werden:
<syntaxhighlight lang="bash" line>
mkdir -p ~/doms/lists.example.org/app-ssl/tmp
touch ~/doms/lists.example.org/app-ssl/tmp/restart.txt
</syntaxhighlight>

Das für Logs definierte Verzeichnis anlegen:
<syntaxhighlight lang="bash">mkdir -p ~/mailman/web/logs</syntaxhighlight>

Damit per Django verfügbare Kommandos leicht ausgeführt werden können, wird der Befehl ''mailman-web'' eingerichtet:
<syntaxhighlight lang="bash" line>
cat <<'EOD' >~/.local/bin/mailman-web
#!/bin/sh

export MAILMAN_WEB_CONFIG=$HOME/mailman/web/settings.py
cd ~/mailman
pipenv run mailman-web "$@"
EOD
chmod +x ~/.local/bin/mailman-web
</syntaxhighlight>

Anschließend wird das Datenbankschema eingerichtet:
<syntaxhighlight lang="bash">mailman-web migrate</syntaxhighlight>

Mit dem folgenden Kommando werden statische Daten für das Web Frontend ins konfiguriete Verzeichnis geschrieben:
<syntaxhighlight lang="bash">mailman-web collectstatic</syntaxhighlight>

Nun müssen die statischen Dateien für das Web Frontend noch per HTTPS verfügbar gemacht werden:
<syntaxhighlight lang="bash">ln -s ~/mailman/mailman-suite/mailman-suite_project/static ~/doms/lists.example.org/htdocs-ssl/</syntaxhighlight>

Zum Anlegen des Administrators des Web Frontends wird dieser Befehl ausgeführt:
<syntaxhighlight lang="bash">mailman-web createsuperuser</syntaxhighlight>

Da die Übersetzungsdateien nur in Mailman Core, jedoch nicht bei den Web Frontend Komponenten im Binärformat enthalten sind, muss die Konvertierung nachgeholt werden:
<syntaxhighlight lang="bash" line>
for pofile in $(find $(pipenv --venv) -path '*/locale/*/LC_MESSAGES/*.po'); do
mofile=${pofile/.po/.mo}
if [ ! -f $mofile ] || [ $pofile -nt $mofile ]; then
echo $pofile
msgfmt $pofile -o $mofile -v
fi
done
</syntaxhighlight>

Damit das Web Frontend per [[Phusion_Passenger|Phusion Passenger]] geladen werden kann:

<syntaxhighlight lang="python" line>
cat <<EOD >~/doms/lists.example.org/app-ssl/passenger_wsgi.py
import os
import subprocess
import sys

os.environ['LANG'] = 'C.UTF-8'
os.environ['LC_ALL'] = 'C.UTF-8'

HOME = os.environ['HOME']
PIPENV = os.path.join(HOME, '.local', 'bin', 'pipenv')
PIPFILE_DIR = os.path.join(HOME, 'mailman')
PIPENV_PYTHON = subprocess.check_output([PIPENV, '--py'], cwd=PIPFILE_DIR).strip().decode('utf-8')
if sys.executable != PIPENV_PYTHON:
os.execl(PIPENV_PYTHON, PIPENV_PYTHON, *sys.argv)

os.environ['MAILMAN_WEB_CONFIG'] = os.path.join(HOME, 'mailman', 'web', 'settings.py')
from mailman_web.wsgi import application
EOD
</syntaxhighlight>

Nun steht das Web Frontend unter <code><nowiki>https://lists.example.org/</nowiki></code> zur Verfügung. Über die Django Administration sollte unter <code><nowiki>https://lists.example.org/admin/sites/site/1/change/</nowiki></code> die Domäne angepasst werden.

== Mails an Mailman weiterleiten ==
Da die MTA-Konfiguration nicht direkt angepasst werden kann, ist ein Hilfskonstrukt erforderlich: Mittels ''.forward-Datei'' werden eingehende Mails an das Programm <code>msmtp</code> weitergeleitet, welches diese per [https://de.wikipedia.org/wiki/Local_Mail_Transfer_Protocol LMTP] bei Mailman abliefert. msmtp ist auf den Managed Servern vorinstalliert.

MM_LMTP_PORT=8024 # In Mailman Core konfigurierter Port
cat <<EOD >.forward+mailman
"|/usr/bin/msmtp --host=localhost --port=$MM_LMTP_PORT --protocol=lmtp --read-envelope-from \$(echo \$ORIGINAL_RECIPIENT | sed 's/+.\+@/@/')"
EOD

Der <code>sed</code> Befehl ist erforderlich, damit Mails mit ''Plus Addressing'' mit der eigentlichen Empfängeradresse bei Mailman ankommen.

Für die Domain <code>lists.example.org</code> wird in HSAdmin oder per <code>hssscript</code> eine Catchall-Adresse mit <code>xyz00-lists+mailman</code> als Ziel eingerichtet. Bei einer Catchall-Adresse wird als <code>localpart</code> ein leerer String angegeben.

== Dienste starten und überwachen ==
Für die beiden benötigten Dienste kann ''monit'' wie folgt konfiguriert werden:

<syntaxhighlight lang="bash" line>
mkdir monit
cat <<EOD >~/.monitrc
set daemon 60
with start delay 90
set httpd unixsocket $HOME/monit/monit.sock
permission 600
allow mailman:monit
set mailserver localhost
set mail-format { from: monit@lists.example.org }
set alert admin@example.org
set logfile $HOME/monit/monit.log
set idfile $HOME/monit/monit.id
set pidfile $HOME/monit/monit.pid
set statefile $HOME/monit/monit.state

check process mailman
pidfile $HOME/mailman/core/master.pid
start program = "$HOME/.local/bin/mailman start"
stop program = "$HOME/.local/bin/mailman stop"
restart program = "$HOME/.local/bin/mailman restart"

check process mailman-web-qcluster
matching "mailman-web qcluster"
start program = "/bin/bash -c 'nohup $HOME/.local/bin/mailman-web qcluster >>$HOME/mailman/web/logs/qcluster.log 2>&1 &'"
stop program = "/usr/bin/pkill -f 'mailman-web qcluster'"
depends on mailman
EOD
</syntaxhighlight>

Dienste starten:
<syntaxhighlight lang="bash">monit</syntaxhighlight>

Für <code>mailman-web qcluster</code> kann alternativ ein minütlich laufender Systemd Timer verwendet werden.

== Logrotation ==
Die Rotation der Logdateien kann so konfiguriert werden:

<syntaxhighlight lang="bash" line>
cat <<EOD >~/logrotate.conf
compress
delaycompress
missingok
notifempty
dateext

$HOME/monit/monit.log {
rotate 1
weekly
maxsize 1M
}

$HOME/mailman/core/logs/*.log {
rotate 6
daily
sharedscripts
postrotate
$HOME/.local/bin/mailman reopen >/dev/null ||:
endscript
}

$HOME/mailman/web/logs/mailmanweb.log {
rotate 6
daily
}

$HOME/mailman/web/logs/qcluster.log {
rotate 1
size 100k
postrotate
/usr/bin/monit restart mailman-web-qcluster >/dev/null ||:
endscript
}
EOD
</syntaxhighlight>

Hinweis: <code>qcluster.log</code> wird hier nur bei Überschreiten der definierten Größe rotiert, um regelmäßige Mails von ''monit'' zu vermeiden.

== Cron Jobs ==
Für Mailman sind verschiedene Cron Jobs erforderlich. Zudem sollen nach einem Neustart die <code>monit</code> Dienste gestartet werden und täglich eine Logrotation erfolgen. Die Einrichtung kann so erfolgen (eine bereits existierende crontab wird überschrieben):

<syntaxhighlight lang="bash" line>
cat <<EOD | crontab -
MAILTO=admin@example.org
HOME=$HOME
PATH=$HOME/.local/bin:/usr/bin:/bin:/usr/sbin

@reboot rm -f \$HOME/monit/monit.pid \$HOME/mailman/core/master.pid && monit

@daily logrotate -s \$HOME/.logrotate_state \$HOME/logrotate.conf

# Send periodic digests.
@daily mailman digests --send

* * * * * mailman-web runjobs minutely
2,17,32,47 * * * * mailman-web runjobs quarter_hourly
@hourly mailman-web runjobs hourly
@daily mailman-web runjobs daily
@weekly mailman-web runjobs weekly
@monthly mailman-web runjobs monthly
@yearly mailman-web runjobs yearly
EOD
</syntaxhighlight>

Soll eine existierende crontab nicht überschrieben werden, muss das Kommando <code>crontab -e</code> ausgeführt und die crontab entsprechend angepasst werden. (Dabei <code>\$HOME</code> mit <code>$HOME</code> und <code>$HOME</code> mit dem Pfad des Benutzerverzeichnisses ersetzen.)

== Liste anlegen ==
Damit Mailman tatsächlich genutzt werden kann, muss natürlich eine Liste eingerichtet werden.
<syntaxhighlight lang=bash>mailman create meine-erste-liste@lists.example.org # Alternativ über Web Frontend</syntaxhighlight>

Außerdem müssen die E-Mail Adressen für die Mailingliste angelegt werden, im HSAdmin. Zum Beispiel für die Liste meine-erste-liste: meine-erste-liste, meine-erste-liste-join, meine-erste-liste-leave, meine-erste-liste-owner, für die Domain lists.example.org. Die E-Mails sollen in das Postfach gehen, wo mailman installiert ist.
Alternativ kann eine Catch-All Adresse eingerichtet werden, damit alle E-Mails an die Subdomain in das Postfach vom mailman gehen. Der Catch-All ist laut Postfix Regeln eine Adresse mit einem leeren lokalen Teil (siehe auch der Screenshot in der [[Sympa_installieren#Neue_Liste_einrichten|entsprechenden Anleitung von Sympa]]).

== Die Selbst-Registrierung von Benutzern verhindern ==

Per Default kann sich jede Person im Mailman3 ein Benutzerkonto anlegen. Wenn das nicht erwünscht ist, kann in der Datei <code>var/etc/settings.py</code> die folgende Zeile hinzugefügt werden:

<syntaxhighlight lang="python">
ACCOUNT_ADAPTER = 'django_mailman3.views.user_adapter.DisableSignupAdapter'
</syntaxhighlight>

Es können in diesem Fall im Django Backend durch den Administrator Benutzerkonten angelegt werden, auf https://lists.example.org/admin/auth/user/

== Update ==
Mailman lässt sich wie im Folgenden beschrieben aktualisieren.

Python-Pakete für die Aktualisierungen vorliegen ausgeben:

<syntaxhighlight lang="bash">
cd ~/mailman
pipenv update --outdated
</syntaxhighlight>

Vor dem eigentlichen Update empfiehlt es sich, die Release Notes (zumindest von [https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/docs/NEWS.html Mailman]) zu lesen und auf relevante Änderungen zu prüfen.

Mailman stoppen:
<syntaxhighlight lang="bash">
monit stop mailman
</syntaxhighlight>

Update der Pakete:

<syntaxhighlight lang="bash">
pipenv update
</syntaxhighlight>

Ggf. Pip Cache löschen:

<syntaxhighlight lang="bash">
pipenv --clear
</syntaxhighlight>

Datenbankmigrationen durchführen:
<syntaxhighlight lang="bash">
mailman-web makemigrations
mailman-web migrate
</syntaxhighlight>

Übersetzungen aktualisieren:
<syntaxhighlight lang="bash" line>
for pofile in $(find $(pipenv --venv) -path '*/locale/*/LC_MESSAGES/*.po'); do
mofile=${pofile/.po/.mo}
if [ ! -f $mofile ] || [ $pofile -nt $mofile ]; then
echo $pofile
msgfmt $pofile -o $mofile -v
fi
done
</syntaxhighlight>

Statische Dateien aktualisieren:
<syntaxhighlight lang="bash">mailman-web collectstatic -c</syntaxhighlight>

Abschließend die Dienste wieder starten:
<syntaxhighlight lang="bash">
monit start mailman
monit start mailman-web-qcluster
</syntaxhighlight>

Web Frontend neu starten:
<syntaxhighlight lang="bash">
mkdir -p ~/doms/lists.example.org/app-ssl/tmp
touch ~/doms/lists.example.org/app-ssl/tmp/restart.txt
</syntaxhighlight>

== Links ==
* [https://docs.mailman3.org/en/latest/ Offizielle Anleitung für Mailman3]
* [https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/mailman3 Ansible Playbook für Hostsharing]

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]
[[Kategorie:Software]]
[[Kategorie:Mailinglisten]]
[[Kategorie:E-Mail]]
[[Kategorie:Python]]

Container

2025-10-02T08:12:13Z

Tim: /* Beispiel Anwendungen */

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

* TODO Es muss ein Tunnel eingerichtet werden, damit die Datenbank vom Container Server aus erreichbar ist.
* TODO: Anpassungen an Docker Compose. Beispiel

== 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 ===
TODO siehe https://codeberg.org/tpokorra/hs.compose/src/branch/main/nextcloud-high_performance_backend

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

Container

2025-10-01T10:24:33Z

Tim: /* Container Umgebung mit Caddy und Python Anwendung */

Container

2025-10-01T07:01:15Z

Tim: Integration in Managed Platform

Speicherbelegung

2025-09-03T06:19:53Z

Tim: /* 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
</syntaxhighlight>

----
[[Kategorie:Pakete bei HS]]
[[Kategorie:HSDoku]]

Speicherbelegung

2025-09-03T06:18:50Z

Tim: 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 dein Paket xyz00:

<syntaxhighlight lang=shell>
find /tmp/user/$UID
</syntaxhighlight>

----
[[Kategorie:Pakete bei HS]]
[[Kategorie:HSDoku]]

Container

2025-09-01T09:29:49Z

Tim: /* Erste Schritte */

Container

2025-09-01T09:27:20Z

Tim: /* Hilfreiche Befehle für Docker */

Container

2025-09-01T09:26:54Z

Tim: hilfreiche Befehle für Docker

Container

2025-09-01T09:09:50Z

Tim: /* Erste Schritte */

Container

2025-09-01T09:07:19Z

Tim: /* Übersicht */

Container

2025-09-01T09:06:52Z

Tim: erste Version

DKIM

2025-08-27T08:30:46Z

Tim: /* DKIM prüfen */

[[Kategorie:HSDoku]][[Kategorie:E-Mail]]
= DomainKeys Identified Mail (DKIM) =

DKIM ist ein Verfahren, dass die Authentizität einer E-Mail sicherstellen kann. Dazu wird die E-Mail auf dem sendenden System mit einer elektronischen Signatur in den unsichtbaren Headerzeilen der E-Mail versehen. Es kommt ein asymmetrisches Schlüsselverfahren zum Einsatz. Der sendende Server verwendet seinen privaten Schlüssel, um die Signatur zu erstellen.

Der öffentliche Schlüssel wird im DNS der E-Mail-Domain veröffentlicht, so dass Empfänger die Authentizität der Signatur prüfen können.

== DKIM bei Hostsharing aktivieren ==

Die Nutzer der Hostsharing-Plattform können E-Mails, die sie über die Hostsharing-Server versenden, mit einer DKIM Signatur versehen lassen. Dazu sind zwei Voraussetzungen notwendig:

# Die Veröffentlichung des öffentlichen Domainkey im DNS der eigenen E-Mail-Domain.
# Das Setzen der Domain-Option "Domain Key – DKIM" mit Hilfe von HSAdmin.

=== Domainkey im DNS ===

==== Wenn ein individuell angepasstes Zonefile existiert ====

Wenn das Zonefile individuell angepasst wurde, muss es entweder den Platzhalter

<code>{DEFAULT_ZONEFILE}</code>

oder den Platzhalter

<code>{DKIM_RR}</code>

enthalten.

Wenn das nicht der Fall ist, muss eine der beiden Zeilen ergänzt werden.

==== Wenn das Zonefile nicht verändert wurde ====

Wenn kein Zonefile im etc-Verzeichnis der Domain vorhanden ist, bedeutet dies, dass das Default-Zonefile mit der Zeile "<code>{DEFAULT_ZONEFILE}</code>" genutzt wird.

Die Veröffentlichung des Domainkeys ist dann mit einem einfachen "touch"-Befehl möglich.

<syntaxhighlight lang=shell>
touch doms/hs-example.de/etc/pri.hs-example.de
</syntaxhighlight>

Daraufhin erstellt das System automatisch einen Domain-Key und veröffentlicht ihn.
Etwa drei Minuten nach dem "touch" liefert der Befehl

<syntaxhighlight lang=shell>
dig -t TXT +short hskey1._domainkey.hs-example.de @dns1.hostsharing.net
</syntaxhighlight>

("hs-example.de" durch die eigene Domain ersetzen)

das folgende Alias:

<syntaxhighlight lang=ini>
hskey1._domainkey.hostsharing.net.
</syntaxhighlight>

=== Domainoption DKIM ===

Über die Domainoption "Domain Key – DKIM" wird gesteuert, dass der SMTP-Server, auf dem der Webspace mit der Domain liegt, die ausgehenden E-Mail mit einer DKIM-Signatur ausstattet.

Zum Anpassen der Domainoptionen wählt man in HSAdmin links den Punkt "Web-Paket" und im rechten Bereich im Menü die Auswahl "Domain". Bei Domains, die ab 3. September 2021 eingerichtet wurden, ist die Domainoption per Voreinstellung gesetzt,

[[Datei:dkim-domain.png]]

[[Datei:dkim-option.png]]

== DKIM prüfen ==

Es gibt Tools wie z.B. https://easydmarc.com/tools/dkim-lookup

Auf der Kommandozeile geht es auch:

<syntaxhighlight lang=shell>
dig @dns1.hostsharing.net default._domainkey.tst2.hs-example.de +short -t TXT
</syntaxhighlight>

wobei '''default''' der DKIM Selektor ist, und '''tst2.hs-example.de''' die gewünschte Domain.

== DKIM deaktivieren ==

Das Abstellen der DKIM-Option in folgender Reihenfolge wird funktionieren:

# Die Domainoption deaktivieren
# Abwarten bis alle mit der Option (und damit mit einer Signatur) versendeten E-Mail zugestellt sind
# Den Domainkey im DNS entfernen

== DKIM bei Google ==

Die Server von ''gmail'' sind so eingestellt, dass E-Mails von Domains ohne DKIM oder SPF nicht zugestellt werden. Die Empfängerseite wird nicht informiert. An die Absenderseite geht eine Fehlermeldung in der Art:
<Blockquote>... host gmail-smtp-in.l.google.com[2a00:1450:4010:c0f::1a] said: 550-5.7.26 Your email has been blocked because the sender is unauthenticated. 550-5.7.26 Gmail requires all senders to authenticate with either SPF or DKIM. 550-5.7.26 550-5.7.26 Authentication results: 550-5.7.26 DKIM = did not pass 550-5.7.26 ...</blockquote>
Dieser Google-Support-Artikel: [https://support.google.com/a/answer/81126 Richtlinien für E-Mail-Absender] (abgerufen am 26. Mai 2024) soll das erläutern.

Nach erfolgreicher Umstellung findet sich im Header einer E-Mail in Googles Posteingang Text in der Art:
<syntaxhighlight lang=ini>Authentication-Results: mx.google.com;
dkim=pass ...
spf=pass ...
</syntaxhighlight>

== Links ==

* [https://de.wikipedia.org/wiki/DomainKeys DKIM Artikel der Wikipedia]
* [https://www.hostsharing.net/doc/managed-operations-platform/zonefile/ Hostsharing-Dokumentation zur Anpassung des Zonefile]
* [https://www.hostsharing.net/doc/managed-operations-platform/domain/#kap-domain-optionen Hostsharing-Dokumentation Domain-Optionen]

DKIM

2025-08-27T08:29:58Z

Tim: /* DKIM deaktivieren */

[[Kategorie:HSDoku]][[Kategorie:E-Mail]]
= DomainKeys Identified Mail (DKIM) =

DKIM ist ein Verfahren, dass die Authentizität einer E-Mail sicherstellen kann. Dazu wird die E-Mail auf dem sendenden System mit einer elektronischen Signatur in den unsichtbaren Headerzeilen der E-Mail versehen. Es kommt ein asymmetrisches Schlüsselverfahren zum Einsatz. Der sendende Server verwendet seinen privaten Schlüssel, um die Signatur zu erstellen.

Der öffentliche Schlüssel wird im DNS der E-Mail-Domain veröffentlicht, so dass Empfänger die Authentizität der Signatur prüfen können.

== DKIM bei Hostsharing aktivieren ==

Die Nutzer der Hostsharing-Plattform können E-Mails, die sie über die Hostsharing-Server versenden, mit einer DKIM Signatur versehen lassen. Dazu sind zwei Voraussetzungen notwendig:

# Die Veröffentlichung des öffentlichen Domainkey im DNS der eigenen E-Mail-Domain.
# Das Setzen der Domain-Option "Domain Key – DKIM" mit Hilfe von HSAdmin.

=== Domainkey im DNS ===

==== Wenn ein individuell angepasstes Zonefile existiert ====

Wenn das Zonefile individuell angepasst wurde, muss es entweder den Platzhalter

<code>{DEFAULT_ZONEFILE}</code>

oder den Platzhalter

<code>{DKIM_RR}</code>

enthalten.

Wenn das nicht der Fall ist, muss eine der beiden Zeilen ergänzt werden.

==== Wenn das Zonefile nicht verändert wurde ====

Wenn kein Zonefile im etc-Verzeichnis der Domain vorhanden ist, bedeutet dies, dass das Default-Zonefile mit der Zeile "<code>{DEFAULT_ZONEFILE}</code>" genutzt wird.

Die Veröffentlichung des Domainkeys ist dann mit einem einfachen "touch"-Befehl möglich.

<syntaxhighlight lang=shell>
touch doms/hs-example.de/etc/pri.hs-example.de
</syntaxhighlight>

Daraufhin erstellt das System automatisch einen Domain-Key und veröffentlicht ihn.
Etwa drei Minuten nach dem "touch" liefert der Befehl

<syntaxhighlight lang=shell>
dig -t TXT +short hskey1._domainkey.hs-example.de @dns1.hostsharing.net
</syntaxhighlight>

("hs-example.de" durch die eigene Domain ersetzen)

das folgende Alias:

<syntaxhighlight lang=ini>
hskey1._domainkey.hostsharing.net.
</syntaxhighlight>

=== Domainoption DKIM ===

Über die Domainoption "Domain Key – DKIM" wird gesteuert, dass der SMTP-Server, auf dem der Webspace mit der Domain liegt, die ausgehenden E-Mail mit einer DKIM-Signatur ausstattet.

Zum Anpassen der Domainoptionen wählt man in HSAdmin links den Punkt "Web-Paket" und im rechten Bereich im Menü die Auswahl "Domain". Bei Domains, die ab 3. September 2021 eingerichtet wurden, ist die Domainoption per Voreinstellung gesetzt,

[[Datei:dkim-domain.png]]

[[Datei:dkim-option.png]]

== DKIM prüfen ==

Es gibt Tools wie z.B. https://easydmarc.com/tools/dkim-lookup

Auf der Kommandozeile geht es auch:

<syntaxhighlight lang=shell>
dig @dns1.hostsharing.net default._domainkey.tst2.beispielverein.de +short -t TXT
</syntaxhighlight>

wobei '''default''' der DKIM Selektor ist, und '''tst2.beispielverein.de''' die gewünschte Domain.

== DKIM deaktivieren ==

Das Abstellen der DKIM-Option in folgender Reihenfolge wird funktionieren:

# Die Domainoption deaktivieren
# Abwarten bis alle mit der Option (und damit mit einer Signatur) versendeten E-Mail zugestellt sind
# Den Domainkey im DNS entfernen

== DKIM bei Google ==

Die Server von ''gmail'' sind so eingestellt, dass E-Mails von Domains ohne DKIM oder SPF nicht zugestellt werden. Die Empfängerseite wird nicht informiert. An die Absenderseite geht eine Fehlermeldung in der Art:
<Blockquote>... host gmail-smtp-in.l.google.com[2a00:1450:4010:c0f::1a] said: 550-5.7.26 Your email has been blocked because the sender is unauthenticated. 550-5.7.26 Gmail requires all senders to authenticate with either SPF or DKIM. 550-5.7.26 550-5.7.26 Authentication results: 550-5.7.26 DKIM = did not pass 550-5.7.26 ...</blockquote>
Dieser Google-Support-Artikel: [https://support.google.com/a/answer/81126 Richtlinien für E-Mail-Absender] (abgerufen am 26. Mai 2024) soll das erläutern.

Nach erfolgreicher Umstellung findet sich im Header einer E-Mail in Googles Posteingang Text in der Art:
<syntaxhighlight lang=ini>Authentication-Results: mx.google.com;
dkim=pass ...
spf=pass ...
</syntaxhighlight>

== Links ==

* [https://de.wikipedia.org/wiki/DomainKeys DKIM Artikel der Wikipedia]
* [https://www.hostsharing.net/doc/managed-operations-platform/zonefile/ Hostsharing-Dokumentation zur Anpassung des Zonefile]
* [https://www.hostsharing.net/doc/managed-operations-platform/domain/#kap-domain-optionen Hostsharing-Dokumentation Domain-Optionen]

Discourse installieren

2025-08-26T06:37:03Z

Tim: /* Am Beispiel von 3.4.5 auf 3.4.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!

==== Am Beispiel von 3.4.5 auf 3.4.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
# git diff v3.4.5 > diff-3.4.5.txt
# git fetch
# git checkout -b hostsharing-deployment-v3.4.7 v3.4.7
# evtl. Änderungen aus diff-3.4.1.txt wieder übernehmen und committen
# patch -p1 < diff-3.4.5.txt
# git commit -a -m "spezifische Änderungen für diese Instanz" --no-verify
# Schauen, ob discourse (endlich :) ) eine neue Ruby-Version nutzt (z.B. in https://github.com/discourse/discourse_docker/blob/main/image/base/Dockerfile)
# Dies ist der Fall, also
# rbenv install 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
# npm install -g terser uglify-js pnpm@9
# corepack use pnpm@latest-9
# pnpm install
# export $(grep -v '^#' ~/discourse.env | xargs -d '\n')
# 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]]

Nextcloud

2025-08-23T04:37:38Z

Tim: /* Update: bei old-stable Version bleiben */

= 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]
# 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 noch nicht ausprobiert (siehe https://nextcloud-talk.readthedocs.io/en/latest/quick-install/)

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://ownyourbits.com/2019/06/29/understanding-and-improving-nextcloud-previews/ Optimierung des Caches 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]]

Znuny installieren

2025-08-20T12:53:48Z

Tim: /* Links */

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

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

Znuny installieren

2025-08-20T12:49:42Z

Tim: Verschiedene Punkte unter dem Thema Einrichtung zusammengefasst

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

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

Znuny installieren

2025-08-20T07:51:01Z

Tim: Automatische Antwort bei eingehenden E-Mails

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

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

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

.htaccess

2025-06-11T20:44:08Z

Tim: Beispiel Cryptpad

Mit <code>.htaccess</code> Dateien innerhalb der Dokument-Verzeichnisse einer Domain (möglichst in ~/doms/example.com/.htaccess oder gezielt in Unterverzeichnissen subs/www ect. ), können Einstellungen des Apache Webservers konfiguriert werden.

Zum Beispiel kann angegeben werden, welches Apache-Modul für bestimmte Dateien (oder bestimmte Datei-Endungen) benutzt werden soll, wohin Dokumente verschoben worden sind, oder auch, wer Zugriff auf die Dateien hat.

== Einstellen von MIME-Typen ==

<syntaxhighlight lang=apache line>
# Download von Zertifikaten ermöglichen:
AddType application/x-x509-ca-cert .crt
</syntaxhighlight>

== Einstellen des im HTTP Header angegebenen Zeichensatzes ==

für .html Dateien:
<syntaxhighlight lang=apache line>
AddCharset UTF-8 .html

# oder
AddDefaultCharset UTF-8
</syntaxhighlight>

(für PHP Skripte siehe [[PHP]] )

== Einstellen von Datei Handlern ==

<syntaxhighlight lang=apache line>
AddType application/x-httpd-phpcgi .php
Action application/x-httpd-phpcgi /fastcgi-bin/phpstub
</syntaxhighlight>

==Passwortschutz für Dateien==

'''Achtung:''' Sofern der Zugriff http Zugriff auf die Dateien nicht automatisch auf https:// bzw. [[TLS_/_SSL|SSL]] umgeleitet wird, können die Passwörter unverschlüsselt übertragen werden!

Zunächst wollen wir den Zugriff auf ein Unterverzeichnis unserer Beispiel-Domain per .htaccess einschränken. Dazu legen wir zunächst eine Passwort-Datei an. Am einfachsten lässt sich diese spezielle Passwort-Datei in einer Shell anlegen. Wir legen sie in das etc-Verzeichnis der Domain:

<syntaxhighlight lang=bash>
xyz00-doms@hopi$ cd ~/doms/example.com/etc
xyz00-doms@hopi$ htpasswd -c .htpasswd peter
New password: *****
Re-type new password: *****
xyz00-doms@hopi$
</syntaxhighlight>

Beim ersten User, hier peter wird das Programm htpasswd mit der Option -c (create) aufgerufen, aber auch wirklich nur beim ersten mal, da sonst die Datei .htpasswd neu erzeugt werden würde und vorherige Einträge damit gelöscht wären.

Sollte es beim Versuch, die Datei anzulegen, zu der Fehlermeldung kommando htpasswd nicht bekannt kommen, dann müssen wir zunächst den Befehl lokalisieren und mit dem richtigen Pfad neu aufrufen:

<syntaxhighlight lang=bash>
xyz00-doms@hopi$ locate htpasswd
/usr/bin/htpasswd
xyz00-doms@hopi$ /usr/bin/htpasswd -c .htpasswd peter
</syntaxhighlight>

Beim zweiten User erfolgt der Aufruf dann ohne die Option -c:

<syntaxhighlight lang=bash>
xyz00-doms@hopi$ htpasswd .htpasswd petra
New password: *****
Re-type new password: *****
xyz00-doms@hopi$
</syntaxhighlight>

Die Sternchen * stehen selbstverständlich für das jeweilige Passwort, welches dem User zugeordnet werden soll.

Diese Datei könnten wir auch einfach mit scp/pscp oder FTP hochladen, dabei stellt sich dann jedoch die Frage, wie wir sie erzeugen. Auf den meisten Windows-Systemen dürfte kein htpasswd-Kommando verfügbar sein. Für diese Fälle gibt es eine online-Version z.b.: https://de.functions-online.com/crypt.html
die Ausgabe einfach mit Copy&Paste in eine Datei kopieren und diese hochladen.

Die so angelegte Passwort-Datei kann nun von einer oder mehreren .htaccess-Dateien verwendet werden. Dazu begeben wir uns in das zu schützende Verzeichnis und legen dort eine Datei .htaccess an. Dies kann wieder per Upload oder in einer Shell geschehen. Die Datei kann beispielsweise so aussehen:

<syntaxhighlight lang=apache line>
order allow,deny
allow from all
require valid-user
Authname "Privater Bereich, bitte Anmelden."
Authtype Basic
AuthUserFile /home/doms/example.com/etc/.htpasswd
</syntaxhighlight>

Dabei verweist die letzte Zeile auf die von uns angelegte .htpasswd Datei. Zu beachten ist:
* Das die Pfadangabe absolut erfolgt, um einen "Internal Server Error" zu vermeiden.
* Falls die Datei innerhalb des Dokumenten Verzeichnisses liegen muss, sie auf jeden Fall .htpasswd heißt, damit sie vom Webserver nicht herausgegeben wird.
* Die .htaccess Datei in den Paketdomains innerhalb des web/ bzw. web-ssl/ Verzeichnisses liegen muss, damit kein "Internal Server Error" auftritt.

===Passwortschutz von CGI- und PHP-Anwendungen===

Mit dem beschriebenen Mechanismus können selbstverständlich auch PHP-Skripte und CGI-Anwendungen vor unberechtigten Zugriffen geschützt werden. In dem geschützten Skript kann über die Umgebungsvariable <code>REDIRECT_REMOTE_USER</code> der Benutzername des Benutzers abgefragt werden, der sich angemeldet hat.

In PHP-Skripten kann mit Hilfe der automatisch global sichtbaren Variablen <code>$_ENV</code> auf die Umgebungsvariablen zugegriffen werden. Um die Variable <code>REDIRECT_REMOTE_USER</code> zu lesen, schreibt man also <code>$_ENV['REDIRECT_REMOTE_USER']</code>.

=== Passwortschutz abhängig vom REQUEST_URI ===

Falls ich für eine oder mehrere REQUEST_URI eine htpasswd Abfrage möchte, z.B. für Keycloak Admin Login:

<syntaxhighlight lang=apache line>
SetEnvIf REQUEST_URI ^/realms/master/.* HTTPAUTHPROTECT

Authname "Privater Bereich, bitte Anmelden."
Authtype Basic
AuthUserFile /home/doms/login.beispielverein.de/.htpasswd

Order Allow,Deny
Satisfy any
Require valid-user
Allow from all
Deny from env=HTTPAUTHPROTECT
</syntaxhighlight>

Anders herum würde es auch gehen: Wenn ich für eine oder mehrere REQUEST_URI keine htpasswd Abfrage möchte:

<syntaxhighlight lang=apache line>
SetEnvIf REQUEST_URI ^/public/.* NOPASSWD

Authname "Privater Bereich, bitte Anmelden."
Authtype Basic
AuthUserFile /home/doms/app.beispielverein.de/.htpasswd

Order Deny,Allow
Satisfy Any
Deny from all
Require valid-user
Allow from env=NOPASSWD
</syntaxhighlight>

Siehe auch [https://stackoverflow.com/a/11439361/1632368] für eine Erklärung.

=== Cryptpad als Beispiel für SetEnvIf und env in Headern ===

Im Vergleich zum vorherigen Beispiel ist die .htaccess Datei von Cryptpad noch komplexer, siehe [[Cryptpad#Webserver_Konfiguration]].

Zum Beispiel können Umgebungsvariablen auch wieder zurückgesetzt werden:

<syntaxhighlight lang=apache>
SetEnvIfNoCase Host ^(?!sandbox\.).*$ !SET_UNSAFE
</syntaxhighlight>

Und Header können gesetzt werden, abhängig davon ob die Umgebungsvariable gesetzt wurde oder nicht:

<syntaxhighlight lang=apache>
Header Set DebugAllowAllOrigins "allowall" env=ALLOW_ALL_ORIGINS
Header Set DebugAllowOrigins "sandboxonly" env=!ALLOW_ALL_ORIGINS
</syntaxhighlight>

Beachte: <code>SetEnv</code> kann in diesem Fall nicht eingesetzt werden, der Wert der Variablen steht einfach noch nicht zur Verfügung.

'''Das geht nicht''':

<syntaxhighlight lang=apache>
SetEnv MYTEST true
<If "%{ENV:MYTEST} == 'true'">
Header Set DebugMyTest1 "DebugMyTest1"
</If>
Header Set DebugMyTest2 "%{ENV:MYTEST}e"
</syntaxhighlight>

== Redirects ==

<syntaxhighlight lang=apache line>
Redirect permanent / http://www.example.com/
</syntaxhighlight>

== Rewrite Rules ==

<syntaxhighlight lang=apache line>
RewriteEngine On
RewriteRule ^mailman/(.*)$ /cgi-bin/mailman/$1
</syntaxhighlight>

Oder auch zum Testen:

<syntaxhighlight lang=apache line>
RewriteEngine on
RewriteBase /
RewriteRule "push/(.*)$" https://www.hostsharing.net/push/$1 [last]
RewriteRule "/(.*)$" https://www.hostsharing.net/alles/$1 [last]
</syntaxhighlight>

Mit curl testen:

<syntaxhighlight lang=bash>
curl -XGET https://hello.beispielverein.de/push/test -I
</syntaxhighlight>

Das gibt aus, wohin der Redirect geht: z.B.

<syntaxhighlight lang=html>
Location: https://www.hostsharing.net/push/test
</syntaxhighlight>

== Nur SSL erlauben und automatisch umschalten ==

Bei per Symlink zusammengeschalteten Verzeichnissen, kann dies für die Verzeichnisse auf die nur per SSL zugegriffen werden soll, wie folgt erreicht werden:

<syntaxhighlight lang=apache line>
# SSL so fordern, dass ggf. Basic Auth nur einmal innerhalb von SSL abgefragt wird.
#
#SSLOptions +StrictRequire #Bei HS festgelegt.
SSLRequireSSL
ErrorDocument 403 https://xyz00.hostsharing.net/https/URL/mit/entspechendem/Ziel/Verzeichnis
</syntaxhighlight>

In diesem Beispiel wird auf eine xyz00 Domain umgeleitet für die das HS Zertifikat gilt. Liegen die Seiten nicht dort ist die entprechende URL des Speicherortes mit https:// anzugegeben.

Bei separaten Verzeichnissen für ssl und nicht-ssl kann auch ein permanenter Redirekt gelegt werden.

Beispiel:
<syntaxhighlight lang=apache line>
Redirect permanent / https://www.example.org/
</syntaxhighlight>

Um alle http Requests nach https weiter zu leiten:

<syntaxhighlight lang=apache line>
RewriteEngine On
RewriteCond %{SERVER_PORT} !=443
RewriteRule .* https://%{HTTP_HOST}:443%{REQUEST_URI} [QSA,R=permanent,L]
</syntaxhighlight>

==Verzeichnislisting ausschalten==

Ruft ein Nutzer ein Verzeichnis auf, z.B. www.example.com/verzeichnis, so wird normalerweise die sich darin befindliche index.html als Standard aufgerufen. Gibt es diese Datei nicht, wird der Inhalt des Verzeichnisses gelistet. Das kann ein Sicherheitsproblem sein.

Die Einstellung
<syntaxhighlight lang=apache line>
IndexIgnore *
</syntaxhighlight>
sorgt dafür, dass alle Datein Unterhalb des Speicherortes der .htaccess Datei für das Verzeichnislisting ignoriert werden.

Hinweis: Das Listen der Verzeichnisse kann auch schon auf Dateisystemebene durch ändern der Verzeichnisrechte (o-r) unterbunden werden, wodurch auch lokale User berücksichtigt werden.

== Ausnahme die eigene IP-Adresse ==

Zum Testen willst du möglicherweise auf ein anderes Backend zugreifen, als es die normalen Webseiten-Besucherinnen tun. Du kannst die eigene IP-Adresse als "RewriteCond" verwenden:

<syntaxhighlight lang=apache line>
DirectoryIndex disabled
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteCond %{REMOTE_ADDR} !=62.27.244.230
RewriteRule ^(.*) ajp://hsh02.hostsharing.net:8009/$1 [proxy,last]

RewriteRule ^(.*) ajp://127.0.0.1:34380/$1 [proxy,last]
</syntaxhighlight>

== Bestimmte Clients blockieren ==

Jeder Web-Browser gibt sich mit einer Kennung zu erkennen. Auch Bots sollten sich mit einer bestimmten Kennung zu erkennen geben. Diese Kennung wird ersichtlich, wenn Du die web.log Datei durchsuchst (siehe [[Traffic]]). Damit ist es möglich, bestimmte Clients oder Bots auszuschließen.

Hier im Beispiel werden der SemrushBot, der MJ12bot, und der AI Bot Claude von Anthropic ausgeschlossen:

<syntaxhighlight lang=apache line>
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_USER_AGENT} ^.*SemrushBot.*$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^.*MJ12bot.*$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^.*ClaudeBot.*$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^$
RewriteRule ^.* - [F,L]
</syntaxhighlight>

Siehe auch https://stackoverflow.com/a/35775449/1632368

== Bestimmte Verzeichnisse nicht ausliefern ==

zum Beispiel das .git Verzeichnis sollte nicht gezeigt werden:

<syntaxhighlight lang=apache line>
RedirectMatch 404 /\.git
</syntaxhighlight>

Oder wenn Wordpress für alle URLs mit HTTP Code 200 die Startseite anzeigt, denken manche Angreifer, es läuft ein mailman.

<syntaxhighlight lang=apache line>
RedirectMatch 404 /mailman/
</syntaxhighlight>

== Gesperrte Optionen ==

Einstellungen, die es ermöglichen würden, über den Webserver Rechte anderer
User zu erhalten, sind nicht erlaubt.
--
[[Kategorie:HSDoku]]
[[Kategorie:WWW]]
[[Kategorie:Glossar]]

Cryptpad

2025-06-11T20:33:52Z

Tim: Refactoring, mit angepasster .htaccess

= Cryptpad =

'''Cryptpad''' ist ein Online-Office, dass in erster Linie im Internet-Browser zu bedienen ist. Das Alleinstellungsmerkmal ist die '''Ende-zu-Ende-Verschlüsselung''' aller Dokumente. Die Entschlüsselung und die Verschlüsselung erfolgen im Browser. Auf dem Server sind keinerlei lesbare Daten abgelegt.

Cryptpad bietet Editoren für formatierte '''Textdokumente''' (im HTML-Format) und für '''Markdown-Dateien''' und andere Textdateien. Der Anwendungsfall der '''Tabellenkalkulation''' wird durch Onlyoffice-Tabellen abgedeckt. Präsentationen können mit Hilfe von Markdown erstellt werden. Bilder und PDF-Dokumente können in die Umgebung hochgeladen und im Browser betrachtet werden. Ein '''Kalender''' und ein '''Kanbanboard''' zur Aufgabenverwaltung vervollständigen das Angebot.

Das Projekt stellt eine gute [https://docs.cryptpad.fr/de/admin_guide/installation.html Installationsanleitung] bereit. Leider ist die Konfiguration des Webservers nur für NGinX dokumentiert, so dass für die Konfiguration des Apache Webserver einige Experimente notwendig wurden.

= Installation =

Mitglieder, die einen Managed Webspace im Shared Hosting nutzen, müssen für ihre Cryptpad-Installation einen "eigenen Serverdienst" beim Hostsharing-Service anmelden. Diese Option ist im Shared Hosting kostenpflichtig. Für den Serverdienst werden zwei IP-Ports mit dem Server vereinbart. Im Beispiel werden Ports '30001' und '30002' genutzt.

Für die Installation werden mit Hilfe von HSAdmin ein User (hier: 'xyz00-cryptpad') und eine Domain angelegt (hier: 'cryptpad.hs-example.de'). Die Entwickler empfehlen die Nutzung von zwei Domains für eine Cryptpad Installation. Wir nutzen hier eine 'leichtgewichtige' Subdomain 'sandbox.cryptpad.hs-example.de', die bei Hostsharing ohne weitere Konfiguration nutzbar ist.

Für die aktuelle Version wird Node LTS (Version 22.x) empfohlen. Zur Installation (erfolgt weiter unten) siehe
[[NodeJS]].

== Webserver Konfiguration ==

Nach dem Aufschalten der Domain 'cryptpad.hs-example.de' passen wir die generierte Verzeichnisstruktur der Domain wie folgt an:

<syntaxhighlight lang=shell>
cd ~/doms/cryptpad.hs-example.de
rm -rf subs/www subs-ssl/www htdocs-ssl/.htaccess
mkdir subs/sandbox subs-ssl/sandbox
</syntaxhighlight>

In die Verzeichnisse 'subs/sandbox', 'htdocs', 'subs-ssl/sandbox' und 'htdocs-ssl' werden jeweils Dateien mit dem Namen '.htaccess' zur Konfiguration des Apache Webserver abgelegt:

<syntaxhighlight lang=apache line>
# cd ~/doms/cryptpad.hs-example.de
# cat subs/sandbox/.htaccess

Redirect permanent / https://sandbox.cryptpad.hs-example.de/

# cd ~/doms/cryptpad.hs-example.de
# cat subs-ssl/sandbox/.htaccess

DirectoryIndex disabled
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP:UPGRADE} ^WebSocket$ [NC,OR]
RewriteCond %{HTTP:CONNECTION} ^Upgrade$ [NC]
RewriteRule .* ws://127.0.0.1:30002%{REQUEST_URI} [proxy]
RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
RewriteRule .* http://127.0.0.1:30001%{REQUEST_URI} [proxy,last]

# cd ~/doms/cryptpad.hs-example.de
# cat htdocs-ssl/.htaccess

DirectoryIndex disabled
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{HTTP:UPGRADE} ^WebSocket$ [NC,OR]
RewriteCond %{HTTP:CONNECTION} ^Upgrade$ [NC]
RewriteRule .* ws://127.0.0.1:30002%{REQUEST_URI} [proxy]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
RewriteRule .* http://127.0.0.1:30001%{REQUEST_URI} [proxy,last]
</syntaxhighlight>

Eine weitere '.htaccess'-Datei liegt direkt im Hauptverzeichnis der Domain:

* Beachte die überlangen Zeilen!
* Wir orientieren uns an der Beispiel Konfiguration des NGinx Servers vom Cryptpad Projekt: [https://github.com/cryptpad/cryptpad/blob/main/docs/example-advanced.nginx.conf]

<syntaxhighlight lang=apache line>
# cd ~/doms/cryptpad.hs-example.de
# cat .htaccess

# OnlyOffice fonts may be loaded from both domains
SetEnvIf REQUEST_URI ^/common/onlyoffice/.*/fonts/.*$ ALLOW_ALL_ORIGINS
Header Set Access-Control-Allow-Origin "*" env=ALLOW_ALL_ORIGINS
Header Set Access-Control-Allow-Origin "https://sandbox.cryptpad.hs-example.de" env=!ALLOW_ALL_ORIGINS

Header Set Access-Control-Allow-Methods "GET, POST, OPTIONS"
Header Set Access-Control-Allow-Headers "DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Content-Range,Range"
Header Set Access-Control-Max-Age "1728000"
Header Set X-XSS-Protection "1; mode=block"
Header Set X-Content-Type-Options "nosniff"
Header Set Cross-Origin-Resource-Policy "cross-origin"
Header Set Cross-Origin-Embedder-Policy "require-corp"

# the following assets are loaded via the sandbox domain
# they unfortunately still require exceptions to the sandboxing to work correctly.
# if ($uri ~ ^/(?:sheet|doc|presentation)/inner.html) { set $unsafe 1; }
# if ($uri ~ ^/common/onlyoffice/.*/.*\.html) { set $unsafe 1; }
# if ($uri ~ ^/common/onlyoffice/dist/.*/sdkjs/common/spell/spell/spell.js.*$) { set $unsafe 1; }
SetEnvIf REQUEST_URI ^/(sheet|doc|presentation)/inner\.html SET_UNSAFE
SetEnvIf REQUEST_URI ^/common/onlyoffice/.*/.*\.html SET_UNSAFE
SetEnvIf REQUEST_URI ^/common/onlyoffice/dist/.*/sdkjs/common/spell/spell/spell.js.* SET_UNSAFE

# everything except the sandbox domain is a privileged scope, as they might be used to handle keys
# if ($host != $sandbox_domain) { set $unsafe 0; }
SetEnvIfNoCase Host ^sandbox.*$ IS_SANDBOX
SetEnvIfNoCase Host ^(?!sandbox\.).*$ NOT_SANDBOX
SetEnvIfNoCase Host ^(?!sandbox\.).*$ !SET_UNSAFE

# this iframe is an exception. Office file formats are converted outside of the sandboxed scope
# because of bugs in Chromium-based browsers that incorrectly ignore headers that are supposed to enable
# the use of some modern APIs that we require when javascript is run in a cross-origin context.
# We've applied other sandboxing techniques to mitigate the risk of running WebAssembly in this privileged scope
# if ($uri ~ ^/unsafeiframe/inner\.html) { set $unsafe 1; }
SetEnvIf REQUEST_URI ^/unsafeiframe/inner\.html SET_UNSAFE=1

# !SET_UNSAFE: script-src without exceptions
Header Set Content-Security-Policy "default-src 'none'; child-src https://cryptpad.hs-example.de; worker-src 'self'; media-src blob:; style-src 'unsafe-inline' 'self' https://cryptpad.hs-example.de; script-src 'self' resource: https://cryptpad.hs-example.de; connect-src 'self' https://cryptpad.hs-example.de blob: wss://cryptpad.hs-example.de https://sandbox.cryptpad.hs-example.de; font-src 'self' data: https://cryptpad.hs-example.de; img-src 'self' data: blob: https://cryptpad.hs-example.de; frame-src 'self' https://sandbox.cryptpad.hs-example.de blob:; frame-ancestors 'self' https: vector:" env=!SET_UNSAFE
# SET_UNSAFE: script-src with unsafe exceptions
Header Set Content-Security-Policy "default-src 'none'; child-src https://cryptpad.hs-example.de; worker-src 'self'; media-src blob:; style-src 'unsafe-inline' 'self' https://cryptpad.hs-example.de; script-src 'self' 'unsafe-eval' 'unsafe-inline' resource: https://cryptpad.hs-example.de; connect-src 'self' https://cryptpad.hs-example.de blob: wss://cryptpad.hs-example.de https://sandbox.cryptpad.hs-example.de; font-src 'self' data: https://cryptpad.hs-example.de; img-src 'self' data: blob: https://cryptpad.hs-example.de; frame-src 'self' https://sandbox.cryptpad.hs-example.de blob:; frame-ancestors 'self' https: vector:" env=SET_UNSAFE

# for debugging
Header Set DebugAllowAllOrigins "allowall" env=ALLOW_ALL_ORIGINS
Header Set DebugAllowOrigins "sandboxonly" env=!ALLOW_ALL_ORIGINS
Header Set DebugSetUnsafe "unsafe" env=SET_UNSAFE
Header Set DebugIsSafe "safe" env=!SET_UNSAFE
Header Set DebugIsSandbox "sandbox" env=IS_SANDBOX
Header Set DebugIsMainDomain "maindomain" env=NOT_SANDBOX

</syntaxhighlight>

Zwei Datenverzeichnisse werden angelegt und direkt ins 'htdocs-ssl' verlinkt:

<syntaxhighlight lang=shell>
cd $HOME
mkdir data
mkdir data/blob
mkdir data/block
cd $HOME/doms/cryptpad.hs-example.de/htdocs-ssl/
ln -s /home/pacs/xyz00/users/cryptpad/data/blob .
ln -s /home/pacs/xyz00/users/cryptpad/data/block .
</syntaxhighlight>

Dieser Link muss angepasst werden, wenn der Blob-Speicher in den Zusatzspeicher unter /home/storage verschoben wird (siehe unten)!

== Installation von NodeJS ==

Nach dieser [https://wiki.hostsharing.net/index.php?title=NodeJS Anleitung] hier im Wiki sollte mit Hilfe von 'nvm' 'node' in der Version 22 installiert werden.

== Installation des Cryptpad ==

<syntaxhighlight lang=shell>
source ~/.profile
cd $HOME
git clone https://github.com/xwiki-labs/cryptpad.git cryptpad
cd cryptpad
# aktuelle Version nachsehen
git checkout 2025.3.1
npm ci
npm run install:components
cd config
cp config.example.js config.js
vi config.js
</syntaxhighlight>

Meine Konfiguration in der 'config.js':

<syntaxhighlight lang=javascript line>
// $ cat config.js
module.exports = {

httpUnsafeOrigin: 'https://cryptpad.hs-example.de',
httpSafeOrigin: "https://sandbox.cryptpad.hs-example.de",
httpAddress: '127.0.0.1',
httpPort: 30001,
websocketPort: 30002,
maxWorkers: 4,
/*
adminKeys: [
"[admin@cryptpad.hs-example.de/xxxxxxxxxxxxxxxxxxxxxxxx=]",
],
*/
inactiveTime: 90, // days
archiveRetentionTime: 15,
accountRetentionTime: 365,
maxUploadSize: 8 * 1024 * 1024,
filePath: '/home/pacs/xyz00/users/cryptpad/data/file/',
archivePath: '/home/pacs/xyz00/users/cryptpad/data/archive/',
pinPath: '/home/pacs/xyz00/users/cryptpad/data/pins',
taskPath: '/home/pacs/xyz00/users/cryptpad/data/tasks',
blockPath: '/home/pacs/xyz00/users/cryptpad/data/block',
blobPath: '/home/pacs/xyz00/users/cryptpad/data/blob',
blobStagingPath: '/home/pacs/xyz00/users/cryptpad/data/blobstage',
decreePath: '/home/pacs/xyz00/users/cryptpad/data/decrees',
logPath: '/home/pacs/xyz00/users/cryptpad/data/logs',
logToStdout: true,
logLevel: 'info',
logFeedback: false,
verbose: false,
installMethod: 'unspecified',
};
</syntaxhighlight>

Der Admin-Key wird später ergänzt. Der erste registrierte User im Cryptpad kann den öffentlichen Schlüssel aus seinem Profil herauskopieren.

Wenn größere Datenmengen erwartet werden, kann der 'blobPath' in den Zusatzspeicher verlegt werden:

<syntaxhighlight lang=javascript line>
blobPath: '/home/storage/xyz00/users/cryptpad/data/blob',
</syntaxhighlight>

== Installation von onlyoffice ==

Es kann onlyoffice installiert werden, um auch das Bearbeiten von z.B. Calc/Excel Dateien zu ermöglichen.

<syntaxhighlight lang=shell>
source ~/.profile
cd ~/cryptpad
/install-onlyoffice.sh --accept-license
</syntaxhighlight>

== Start des Cryptpad ==

Ich starte das Cryptpad zunächst einfach mit dem 'nohup'-Kommando:

<syntaxhighlight lang=shell>
source ~/.profile
cd ~/cryptpad
nohup node server &
</syntaxhighlight>

== Cryptpad als Dienst starten ==

Die Cryptpad-Prozesse sollen von Systemd als Dienst automatisch gestartet werden.

Dazu legen wir eine Systemd-Unit an:

<syntaxhighlight lang=shell>
mkdir -p $HOME/.config/systemd/user/
vi $HOME/.config/systemd/user/cryptpad.service
</syntaxhighlight>

Der Inhalt der Datei soll sein:

<syntaxhighlight lang=ini line>
[Unit]
Description=Cryptpad
After=network.target

[Service]
Type=simple
WorkingDirectory=%h/cryptpad
Environment="NODE_ENV=production"
Environment="PATH=%h/node_modules/.bin:/usr/local/bin:/usr/bin:/bin"
ExecStart=%h/.nvm/versions/node/v22.16.0/bin/node server
Restart=always
PrivateTmp=true
NoNewPrivileges=true

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

(Die Node-Version im Pfad muss ggf. korrigiert werden)

Der Dienst wird aktiviert und gestartet mit:

systemctl --user daemon-reload
systemctl --user enable cryptpad.service
systemctl --user start cryptpad.service

= weiterführende Links =

* [https://cryptpad.fr/ Die Cryptpad Installation der Entwickler]
* [https://docs.cryptpad.fr/de/ Dokumentation in deutscher Sprache]
* [https://docs.cryptpad.fr/de/admin_guide/installation.html Installationanleitung]
* [https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/cryptpad Ansible Playbook für Hostsharing]

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

Discourse installieren

2025-06-03T08:24:20Z

Tim: 3.3.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!

==== Am Beispiel von 3.4.1 auf 3.4.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
# git diff v3.4.1 > diff-3.4.1.txt
# git fetch
# git checkout -b hostsharing-deployment-v3.4.4 v3.4.4
# evtl. Änderungen aus diff-3.4.1.txt wieder übernehmen und committen
# patch -p1 < diff-3.4.1.txt
# git commit -a -m "spezifische Änderungen für diese Instanz" --no-verify
# Schauen, ob discourse (endlich :) ) eine neue Ruby-Version nutzt (z.B. in https://github.com/discourse/discourse_docker/blob/main/image/base/Dockerfile)
# Dies ist der Fall, also
# rbenv install 3.3.7
# rbenv rehash
# echo "3.3.7" > .ruby-version
# installiere Node 22: https://codeberg.org/tpokorra/hostsharing-scripts/src/branch/main/install-nodejs.sh
# source ~/.profile
# gem update --system
# bundle
# npm install -g terser uglify-js pnpm@9
# corepack use pnpm@latest-9
# pnpm install
# export $(grep -v '^#' ~/discourse.env | xargs -d '\n')
# 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

2025-05-17T06:50:44Z

Tim: /* Am Beispiel von 3.3.3 auf 3.4.1 */

{{Textkasten|gelb|Für Managed Server|Ein funktionierender Discourse-Server erfordert mehrere laufende Server-Dienste. Für den Betrieb ist ein Managed Server sinnvoll.}}

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

==== Am Beispiel von 3.3.3 auf 3.4.1 ====

# Im Web-Backend unter Administration->Backups-> Read-Only Mouds setzen (oder Web Server so konfigurieren, dass keine Zugriffe mehr stattfinden können)
# Backup
# Die lokalen Änderungen sichern:
# cd discourse
# git diff v3.3.3 > diff-3.3.3.txt
# git fetch
# git checkout -b hostsharing-deployment-v3.4.1 v3.4.1
# evtl. Änderungen aus diff-3.3.3.txt wieder übernehmen und committen
# patch -p1 < diff-3.3.3.txt
# git commit -a -m "spezifische Änderungen für diese Instanz" --no-verify
# Schauen, ob discourse (endlich :) ) eine neue Ruby-Version nutzt (z.B. in https://github.com/discourse/discourse_docker/blob/main/image/base/Dockerfile)
# Dies ist der Fall, also
# rbenv install 3.3.6
# rbenv rehash
# echo "3.3.6" > .ruby-version
# installiere Node 22: https://codeberg.org/tpokorra/hostsharing-scripts/src/branch/main/install-nodejs.sh
# source ~/.profile
# gem update --system
# bundle
# npm install -g terser uglify-js pnpm@9
# corepack use pnpm@latest-9
# pnpm install
# export $(grep -v '^#' ~/discourse.env | xargs -d '\n')
# 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]]

Collabora Online

2025-05-06T16:00:45Z

Tim: /* Empfohlene Hardwareausrüstung */

= Collabora installieren =

== Empfohlene Hardwareausrüstung ==

siehe auch https://sdk.collaboraonline.com/docs/installation/Configuration.html#performance

Wir konfigurieren nun Collabora Online so, dass die Anzahl der verfügbaren CPUs automatisch berücksichtigt.

== Vorbereitungen ==

Voraussetzungen sind folgende Punkte:

1. Per Mail an service@hostsharing.net die Aktivierung der Paket Option Collabora Online beauftragen mit der Angabe des Paketkürzel xyz00 und des Benutzers xyz00-cloud unter der die Installation läuft.

2. Grundlage bei Hostsharing ist die Installation der Nextcloud laut Wiki Anleitung [[Nextcloud]].

3. Die APP ''Nextcloud Office'' erst installieren wenn der Service die Bestätigung gesendet hat, dass die Aktivierung erfolgt ist. Hinweis: Bei der Nextcloud-Installation wird ''Nextcloud Office'' u.U. automatisch mit installiert. In diesem Fall ist es notwendig, die App zunächst zu deaktivieren: als Admin im Profilmenü "+ Apps" öffnen und sie dort unter "Aktive Apps" deaktivieren.

== Collabora installieren ==

Collabora ist auf allen 64 Bit hive installiert. Es muss hier nun noch die APP Collabora Online in der Nextcloud installiert werden.

'''WICHTIG:''' Die Freigabe vom Service muss erst per Mail vorliegen!!

1. Anmeldung als '''Admin''' in der Nextcloud Installation

2. Rechts oben auf '''Profilmenü''' den Eintrag '''+APP''' auswählen
[[Datei:Hs-collabora-app-install.jpg|300px]]

3. Im '''Suchfeld''' oben "Nextcloud Office" eingeben
[[Datei:Nextcloud-Office-Suche.png|600px]]

4. Auf den Button ''Herunterladen und aktivieren'' klicken

Damit ist die APP Nextcloud Office installiert und muss nun noch konfiguriert werden.

== Collabora konfigurieren ==

Rechts oben unter '''Profilmenü''' den Eintrag '''Einstellungen''' auswählen.

Anschließend im linken Fensterbereich unter dem Menüpunkt '''Verwaltung'''
den Eintrag '''Collabora Online''' auswählen.

[[Bild:Nextcloud-Office-Menue.png|300px]]

Hier muss nun die PaketDomain entsprechend Eingetragen werden.
Wobei '''xyz00'''.hostsharing.net durch Ihr Paket Kürzel zu ersetzten ist.
Es wird kein Port eingetragen!
Anschließend einmal auf den Button ''Anwenden'' klicken.
[[Bild:Nextcloud-Office-URL.png|600px]]

Es wird empfohlen bei 'Allow list for WOPI requests' die aufgelöste IP Adresse des Webpaketes xyz00.hostsharing.net einzutragen. Sodass nur diese Collabora Instanz Dokumente aus der Nextcloud erhalten kann. Die IP erhält man z.B. über den Konsolenbefehl

<syntaxhighlight lang=shell>
dig xyz00.hostsharing.net
</syntaxhighlight>

Die Relevante Zeile im Output sieht ungefähr so aus:

<syntaxhighlight lang=output line>
;; ANSWER SECTION:
xyz00.hostsharing.net. 3807 IN A 83.223.79.177
</syntaxhighlight>

Die IP Adresse ist die, die dann auch in der Nextcloud auf der Admin Config Seite von Collabora hinterlegt werden muss.

Weitere Einstellungen können individuell noch vorgenommen werden.

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]

Nextcloud

2025-05-02T16:20:14Z

Tim: maintenance:repair ergänzt

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

== 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 28 auf Nextcloud 29, obwohl Nextcloud 28 noch mehrere Monate gepflegt wird, und manche Apps noch nicht bereit sind für Nextcloud 29.

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"
</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://ownyourbits.com/2019/06/29/understanding-and-improving-nextcloud-previews/ Optimierung des Caches 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]]

Wordpress

2025-04-19T04:18:08Z

Tim: /* Links */

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

= 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

2025-04-19T04:17:28Z

Tim: Einen Admin Benutzer hinzufügen

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

= Links =

*[https://wordpress.org/ Offizielle Webseite von 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

2025-04-19T04:15:10Z

Tim: 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 # oder ~/doms/meinedomain.de/subs-ssl/www/ oder wo sonst Wordpress installiert ist
~/bin/wp-cli.phar core verify-checksums
</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>

= Links =

*[https://wordpress.org/ Offizielle Webseite von 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

2025-04-19T04:09:44Z

Tim: /* Links */

= 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 =
== 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>
mkdir ~/bin
cd ~/bin
wget https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod a+x wp-cli.phar
cd ~/wordpress # oder ~/doms/meinedomain.de/subs-ssl/www/ oder wo sonst Wordpress installiert ist
~/bin/wp-cli.phar core update
</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>

= Links =

*[https://wordpress.org/ Offizielle Webseite von 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

2025-04-19T04:09:30Z

Tim: Umstrukturierung

= 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 =
== 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>
mkdir ~/bin
cd ~/bin
wget https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod a+x wp-cli.phar
cd ~/wordpress # oder ~/doms/meinedomain.de/subs-ssl/www/ oder wo sonst Wordpress installiert ist
~/bin/wp-cli.phar core update
</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>

== Links ==

*[https://wordpress.org/ Offizielle Webseite von 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]]

Prozessmanagement mit systemd im Userspace

2025-04-09T17:54:44Z

Tim: hs-notify-unit-failure

== Ü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
CPUQuota=50%
</syntaxhighlight>

; MemoryHigh : Weiches RAM-Limit, das ggf. überschritten werden kann, wenn es unvermeidlich ist.
; MemoryMax : Hartes, absolutes RAM-Limit.
; 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.

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

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

Prozessmanagement mit systemd im Userspace

2025-04-08T12:24:58Z

Tim: /* Einrichten des »service-files« */

== Ü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
CPUQuota=50%
</syntaxhighlight>

; MemoryHigh : Weiches RAM-Limit, das ggf. überschritten werden kann, wenn es unvermeidlich ist.
; MemoryMax : Hartes, absolutes RAM-Limit.
; 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.

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

Environment=MAILTO=admin@example@org
ExecStopPost=-/bin/bash -c 'if [ "$EXIT_STATUS" != "0" ]; then mail -s "ERROR with cleanup service" "$MAILTO" <<<"SYSTEMD status \n Service_result: $SERVICE_RESULT \n Exit_code(systemd): $EXIT_CODE \n Exit_status(proc exit code): $EXIT_STATUS\n`journalctl --user --no-pager -n 20 -u my-cleanup.service`"; fi'

</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]]

Prozessmanagement mit systemd im Userspace

2025-04-08T12:23:50Z

Tim: timer with email notification on error

== Ü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
CPUQuota=50%
</syntaxhighlight>

; MemoryHigh : Weiches RAM-Limit, das ggf. überschritten werden kann, wenn es unvermeidlich ist.
; MemoryMax : Hartes, absolutes RAM-Limit.
; 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.

== 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>
$ cat $HOME/.config/systemd/user/my-cleanup.service

[Unit]
Description=My Cleanup Service

[Service]
Type=oneshot
ExecStart=%h/bin/cleanup-script

Environment=MAILTO=admin@example@org
ExecStopPost=-/bin/bash -c 'if [ "$EXIT_STATUS" != "0" ]; then mail -s "ERROR with cleanup service" "$MAILTO" <<<"SYSTEMD status \n Service_result: $SERVICE_RESULT \n Exit_code(systemd): $EXIT_CODE \n Exit_status(proc exit code): $EXIT_STATUS\n`journalctl --user --no-pager -n 20 -u my-cleanup.service`"; fi'

</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]]

Matrix Synapse installieren

2025-04-07T03:57:31Z

Tim: kein Python 3.9 mehr erforderlich

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
pipenv install
</syntaxhighlight>

Synapse und Postgres-Dependencies installieren:

<syntaxhighlight lang="shell">
cd ~/synapse
pipenv shell
pipenv install matrix-synapse[postgres]
</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 ==

mit pipenv:
<syntaxhighlight lang=shell>
systemctl --user stop synapse.service
cd ~/synapse
source .venv/bin/activate || pipenv shell
pipenv install update
systemctl --user start synapse.service
</syntaxhighlight>

oder falls Synapse mit pip verwaltet wird:

<syntaxhighlight lang=shell>
systemctl --user stop synapse.service
cd ~/synapse
source venv/bin/activate
pip freeze > requirements.txt
sed -i "s/==.*//g" requirements.txt
pip install -r requirements.txt --upgrade
systemctl --user start synapse.service
</syntaxhighlight>
Falls Monit verwendet wird statt systemctl:

<syntaxhighlight lang=shell>
monit stop synapse
#... updaten ...
monit start synapse
</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]]

.htaccess

2025-03-31T16:23:07Z

Tim: /* Rewrite Rules */

Mit <code>.htaccess</code> Dateien innerhalb der Dokument-Verzeichnisse einer Domain (möglichst in ~/doms/example.com/.htaccess oder gezielt in Unterverzeichnissen subs/www ect. ), können Einstellungen des Apache Webservers konfiguriert werden.

Zum Beispiel kann angegeben werden, welches Apache-Modul für bestimmte Dateien (oder bestimmte Datei-Endungen) benutzt werden soll, wohin Dokumente verschoben worden sind, oder auch, wer Zugriff auf die Dateien hat.

== Einstellen von MIME-Typen ==

<syntaxhighlight lang=apache line>
# Download von Zertifikaten ermöglichen:
AddType application/x-x509-ca-cert .crt
</syntaxhighlight>

== Einstellen des im HTTP Header angegebenen Zeichensatzes ==

für .html Dateien:
<syntaxhighlight lang=apache line>
AddCharset UTF-8 .html

# oder
AddDefaultCharset UTF-8
</syntaxhighlight>

(für PHP Skripte siehe [[PHP]] )

== Einstellen von Datei Handlern ==

<syntaxhighlight lang=apache line>
AddType application/x-httpd-phpcgi .php
Action application/x-httpd-phpcgi /fastcgi-bin/phpstub
</syntaxhighlight>

==Passwortschutz für Dateien==

'''Achtung:''' Sofern der Zugriff http Zugriff auf die Dateien nicht automatisch auf https:// bzw. [[TLS_/_SSL|SSL]] umgeleitet wird, können die Passwörter unverschlüsselt übertragen werden!

Zunächst wollen wir den Zugriff auf ein Unterverzeichnis unserer Beispiel-Domain per .htaccess einschränken. Dazu legen wir zunächst eine Passwort-Datei an. Am einfachsten lässt sich diese spezielle Passwort-Datei in einer Shell anlegen. Wir legen sie in das etc-Verzeichnis der Domain:

<syntaxhighlight lang=bash>
xyz00-doms@hopi$ cd ~/doms/example.com/etc
xyz00-doms@hopi$ htpasswd -c .htpasswd peter
New password: *****
Re-type new password: *****
xyz00-doms@hopi$
</syntaxhighlight>

Beim ersten User, hier peter wird das Programm htpasswd mit der Option -c (create) aufgerufen, aber auch wirklich nur beim ersten mal, da sonst die Datei .htpasswd neu erzeugt werden würde und vorherige Einträge damit gelöscht wären.

Sollte es beim Versuch, die Datei anzulegen, zu der Fehlermeldung kommando htpasswd nicht bekannt kommen, dann müssen wir zunächst den Befehl lokalisieren und mit dem richtigen Pfad neu aufrufen:

<syntaxhighlight lang=bash>
xyz00-doms@hopi$ locate htpasswd
/usr/bin/htpasswd
xyz00-doms@hopi$ /usr/bin/htpasswd -c .htpasswd peter
</syntaxhighlight>

Beim zweiten User erfolgt der Aufruf dann ohne die Option -c:

<syntaxhighlight lang=bash>
xyz00-doms@hopi$ htpasswd .htpasswd petra
New password: *****
Re-type new password: *****
xyz00-doms@hopi$
</syntaxhighlight>

Die Sternchen * stehen selbstverständlich für das jeweilige Passwort, welches dem User zugeordnet werden soll.

Diese Datei könnten wir auch einfach mit scp/pscp oder FTP hochladen, dabei stellt sich dann jedoch die Frage, wie wir sie erzeugen. Auf den meisten Windows-Systemen dürfte kein htpasswd-Kommando verfügbar sein. Für diese Fälle gibt es eine online-Version z.b.: https://de.functions-online.com/crypt.html
die Ausgabe einfach mit Copy&Paste in eine Datei kopieren und diese hochladen.

Die so angelegte Passwort-Datei kann nun von einer oder mehreren .htaccess-Dateien verwendet werden. Dazu begeben wir uns in das zu schützende Verzeichnis und legen dort eine Datei .htaccess an. Dies kann wieder per Upload oder in einer Shell geschehen. Die Datei kann beispielsweise so aussehen:

<syntaxhighlight lang=apache line>
order allow,deny
allow from all
require valid-user
Authname "Privater Bereich, bitte Anmelden."
Authtype Basic
AuthUserFile /home/doms/example.com/etc/.htpasswd
</syntaxhighlight>

Dabei verweist die letzte Zeile auf die von uns angelegte .htpasswd Datei. Zu beachten ist:
* Das die Pfadangabe absolut erfolgt, um einen "Internal Server Error" zu vermeiden.
* Falls die Datei innerhalb des Dokumenten Verzeichnisses liegen muss, sie auf jeden Fall .htpasswd heißt, damit sie vom Webserver nicht herausgegeben wird.
* Die .htaccess Datei in den Paketdomains innerhalb des web/ bzw. web-ssl/ Verzeichnisses liegen muss, damit kein "Internal Server Error" auftritt.

===Passwortschutz von CGI- und PHP-Anwendungen===

Mit dem beschriebenen Mechanismus können selbstverständlich auch PHP-Skripte und CGI-Anwendungen vor unberechtigten Zugriffen geschützt werden. In dem geschützten Skript kann über die Umgebungsvariable <code>REDIRECT_REMOTE_USER</code> der Benutzername des Benutzers abgefragt werden, der sich angemeldet hat.

In PHP-Skripten kann mit Hilfe der automatisch global sichtbaren Variablen <code>$_ENV</code> auf die Umgebungsvariablen zugegriffen werden. Um die Variable <code>REDIRECT_REMOTE_USER</code> zu lesen, schreibt man also <code>$_ENV['REDIRECT_REMOTE_USER']</code>.

=== Passwortschutz abhängig vom REQUEST_URI ===

Falls ich für eine oder mehrere REQUEST_URI eine htpasswd Abfrage möchte, z.B. für Keycloak Admin Login:

<syntaxhighlight lang=apache line>
SetEnvIf REQUEST_URI ^/realms/master/.* HTTPAUTHPROTECT

Authname "Privater Bereich, bitte Anmelden."
Authtype Basic
AuthUserFile /home/doms/login.beispielverein.de/.htpasswd

Order Allow,Deny
Satisfy any
Require valid-user
Allow from all
Deny from env=HTTPAUTHPROTECT
</syntaxhighlight>

Anders herum würde es auch gehen: Wenn ich für eine oder mehrere REQUEST_URI keine htpasswd Abfrage möchte:

<syntaxhighlight lang=apache line>
SetEnvIf REQUEST_URI ^/public/.* NOPASSWD

Authname "Privater Bereich, bitte Anmelden."
Authtype Basic
AuthUserFile /home/doms/app.beispielverein.de/.htpasswd

Order Deny,Allow
Satisfy Any
Deny from all
Require valid-user
Allow from env=NOPASSWD
</syntaxhighlight>

Siehe auch [https://stackoverflow.com/a/11439361/1632368] für eine Erklärung.

== Redirects ==

<syntaxhighlight lang=apache line>
Redirect permanent / http://www.example.com/
</syntaxhighlight>

== Rewrite Rules ==

<syntaxhighlight lang=apache line>
RewriteEngine On
RewriteRule ^mailman/(.*)$ /cgi-bin/mailman/$1
</syntaxhighlight>

Oder auch zum Testen:

<syntaxhighlight lang=apache line>
RewriteEngine on
RewriteBase /
RewriteRule "push/(.*)$" https://www.hostsharing.net/push/$1 [last]
RewriteRule "/(.*)$" https://www.hostsharing.net/alles/$1 [last]
</syntaxhighlight>

Mit curl testen:

<syntaxhighlight lang=bash>
curl -XGET https://hello.beispielverein.de/push/test -I
</syntaxhighlight>

Das gibt aus, wohin der Redirect geht: z.B.

<syntaxhighlight lang=html>
Location: https://www.hostsharing.net/push/test
</syntaxhighlight>

== Nur SSL erlauben und automatisch umschalten ==

Bei per Symlink zusammengeschalteten Verzeichnissen, kann dies für die Verzeichnisse auf die nur per SSL zugegriffen werden soll, wie folgt erreicht werden:

<syntaxhighlight lang=apache line>
# SSL so fordern, dass ggf. Basic Auth nur einmal innerhalb von SSL abgefragt wird.
#
#SSLOptions +StrictRequire #Bei HS festgelegt.
SSLRequireSSL
ErrorDocument 403 https://xyz00.hostsharing.net/https/URL/mit/entspechendem/Ziel/Verzeichnis
</syntaxhighlight>

In diesem Beispiel wird auf eine xyz00 Domain umgeleitet für die das HS Zertifikat gilt. Liegen die Seiten nicht dort ist die entprechende URL des Speicherortes mit https:// anzugegeben.

Bei separaten Verzeichnissen für ssl und nicht-ssl kann auch ein permanenter Redirekt gelegt werden.

Beispiel:
<syntaxhighlight lang=apache line>
Redirect permanent / https://www.example.org/
</syntaxhighlight>

Um alle http Requests nach https weiter zu leiten:

<syntaxhighlight lang=apache line>
RewriteEngine On
RewriteCond %{SERVER_PORT} !=443
RewriteRule .* https://%{HTTP_HOST}:443%{REQUEST_URI} [QSA,R=permanent,L]
</syntaxhighlight>

==Verzeichnislisting ausschalten==

Ruft ein Nutzer ein Verzeichnis auf, z.B. www.example.com/verzeichnis, so wird normalerweise die sich darin befindliche index.html als Standard aufgerufen. Gibt es diese Datei nicht, wird der Inhalt des Verzeichnisses gelistet. Das kann ein Sicherheitsproblem sein.

Die Einstellung
<syntaxhighlight lang=apache line>
IndexIgnore *
</syntaxhighlight>
sorgt dafür, dass alle Datein Unterhalb des Speicherortes der .htaccess Datei für das Verzeichnislisting ignoriert werden.

Hinweis: Das Listen der Verzeichnisse kann auch schon auf Dateisystemebene durch ändern der Verzeichnisrechte (o-r) unterbunden werden, wodurch auch lokale User berücksichtigt werden.

== Ausnahme die eigene IP-Adresse ==

Zum Testen willst du möglicherweise auf ein anderes Backend zugreifen, als es die normalen Webseiten-Besucherinnen tun. Du kannst die eigene IP-Adresse als "RewriteCond" verwenden:

<syntaxhighlight lang=apache line>
DirectoryIndex disabled
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteCond %{REMOTE_ADDR} !=62.27.244.230
RewriteRule ^(.*) ajp://hsh02.hostsharing.net:8009/$1 [proxy,last]

RewriteRule ^(.*) ajp://127.0.0.1:34380/$1 [proxy,last]
</syntaxhighlight>

== Bestimmte Clients blockieren ==

Jeder Web-Browser gibt sich mit einer Kennung zu erkennen. Auch Bots sollten sich mit einer bestimmten Kennung zu erkennen geben. Diese Kennung wird ersichtlich, wenn Du die web.log Datei durchsuchst (siehe [[Traffic]]). Damit ist es möglich, bestimmte Clients oder Bots auszuschließen.

Hier im Beispiel werden der SemrushBot, der MJ12bot, und der AI Bot Claude von Anthropic ausgeschlossen:

<syntaxhighlight lang=apache line>
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_USER_AGENT} ^.*SemrushBot.*$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^.*MJ12bot.*$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^.*ClaudeBot.*$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^$
RewriteRule ^.* - [F,L]
</syntaxhighlight>

Siehe auch https://stackoverflow.com/a/35775449/1632368

== Bestimmte Verzeichnisse nicht ausliefern ==

zum Beispiel das .git Verzeichnis sollte nicht gezeigt werden:

<syntaxhighlight lang=apache line>
RedirectMatch 404 /\.git
</syntaxhighlight>

Oder wenn Wordpress für alle URLs mit HTTP Code 200 die Startseite anzeigt, denken manche Angreifer, es läuft ein mailman.

<syntaxhighlight lang=apache line>
RedirectMatch 404 /mailman/
</syntaxhighlight>

== Gesperrte Optionen ==

Einstellungen, die es ermöglichen würden, über den Webserver Rechte anderer
User zu erhalten, sind nicht erlaubt.
--
[[Kategorie:HSDoku]]
[[Kategorie:WWW]]
[[Kategorie:Glossar]]

.htaccess

2025-03-31T16:20:47Z

Tim: /* Rewrite Rules */

Mit <code>.htaccess</code> Dateien innerhalb der Dokument-Verzeichnisse einer Domain (möglichst in ~/doms/example.com/.htaccess oder gezielt in Unterverzeichnissen subs/www ect. ), können Einstellungen des Apache Webservers konfiguriert werden.

Zum Beispiel kann angegeben werden, welches Apache-Modul für bestimmte Dateien (oder bestimmte Datei-Endungen) benutzt werden soll, wohin Dokumente verschoben worden sind, oder auch, wer Zugriff auf die Dateien hat.

== Einstellen von MIME-Typen ==

<syntaxhighlight lang=apache line>
# Download von Zertifikaten ermöglichen:
AddType application/x-x509-ca-cert .crt
</syntaxhighlight>

== Einstellen des im HTTP Header angegebenen Zeichensatzes ==

für .html Dateien:
<syntaxhighlight lang=apache line>
AddCharset UTF-8 .html

# oder
AddDefaultCharset UTF-8
</syntaxhighlight>

(für PHP Skripte siehe [[PHP]] )

== Einstellen von Datei Handlern ==

<syntaxhighlight lang=apache line>
AddType application/x-httpd-phpcgi .php
Action application/x-httpd-phpcgi /fastcgi-bin/phpstub
</syntaxhighlight>

==Passwortschutz für Dateien==

'''Achtung:''' Sofern der Zugriff http Zugriff auf die Dateien nicht automatisch auf https:// bzw. [[TLS_/_SSL|SSL]] umgeleitet wird, können die Passwörter unverschlüsselt übertragen werden!

Zunächst wollen wir den Zugriff auf ein Unterverzeichnis unserer Beispiel-Domain per .htaccess einschränken. Dazu legen wir zunächst eine Passwort-Datei an. Am einfachsten lässt sich diese spezielle Passwort-Datei in einer Shell anlegen. Wir legen sie in das etc-Verzeichnis der Domain:

<syntaxhighlight lang=bash>
xyz00-doms@hopi$ cd ~/doms/example.com/etc
xyz00-doms@hopi$ htpasswd -c .htpasswd peter
New password: *****
Re-type new password: *****
xyz00-doms@hopi$
</syntaxhighlight>

Beim ersten User, hier peter wird das Programm htpasswd mit der Option -c (create) aufgerufen, aber auch wirklich nur beim ersten mal, da sonst die Datei .htpasswd neu erzeugt werden würde und vorherige Einträge damit gelöscht wären.

Sollte es beim Versuch, die Datei anzulegen, zu der Fehlermeldung kommando htpasswd nicht bekannt kommen, dann müssen wir zunächst den Befehl lokalisieren und mit dem richtigen Pfad neu aufrufen:

<syntaxhighlight lang=bash>
xyz00-doms@hopi$ locate htpasswd
/usr/bin/htpasswd
xyz00-doms@hopi$ /usr/bin/htpasswd -c .htpasswd peter
</syntaxhighlight>

Beim zweiten User erfolgt der Aufruf dann ohne die Option -c:

<syntaxhighlight lang=bash>
xyz00-doms@hopi$ htpasswd .htpasswd petra
New password: *****
Re-type new password: *****
xyz00-doms@hopi$
</syntaxhighlight>

Die Sternchen * stehen selbstverständlich für das jeweilige Passwort, welches dem User zugeordnet werden soll.

Diese Datei könnten wir auch einfach mit scp/pscp oder FTP hochladen, dabei stellt sich dann jedoch die Frage, wie wir sie erzeugen. Auf den meisten Windows-Systemen dürfte kein htpasswd-Kommando verfügbar sein. Für diese Fälle gibt es eine online-Version z.b.: https://de.functions-online.com/crypt.html
die Ausgabe einfach mit Copy&Paste in eine Datei kopieren und diese hochladen.

Die so angelegte Passwort-Datei kann nun von einer oder mehreren .htaccess-Dateien verwendet werden. Dazu begeben wir uns in das zu schützende Verzeichnis und legen dort eine Datei .htaccess an. Dies kann wieder per Upload oder in einer Shell geschehen. Die Datei kann beispielsweise so aussehen:

<syntaxhighlight lang=apache line>
order allow,deny
allow from all
require valid-user
Authname "Privater Bereich, bitte Anmelden."
Authtype Basic
AuthUserFile /home/doms/example.com/etc/.htpasswd
</syntaxhighlight>

Dabei verweist die letzte Zeile auf die von uns angelegte .htpasswd Datei. Zu beachten ist:
* Das die Pfadangabe absolut erfolgt, um einen "Internal Server Error" zu vermeiden.
* Falls die Datei innerhalb des Dokumenten Verzeichnisses liegen muss, sie auf jeden Fall .htpasswd heißt, damit sie vom Webserver nicht herausgegeben wird.
* Die .htaccess Datei in den Paketdomains innerhalb des web/ bzw. web-ssl/ Verzeichnisses liegen muss, damit kein "Internal Server Error" auftritt.

===Passwortschutz von CGI- und PHP-Anwendungen===

Mit dem beschriebenen Mechanismus können selbstverständlich auch PHP-Skripte und CGI-Anwendungen vor unberechtigten Zugriffen geschützt werden. In dem geschützten Skript kann über die Umgebungsvariable <code>REDIRECT_REMOTE_USER</code> der Benutzername des Benutzers abgefragt werden, der sich angemeldet hat.

In PHP-Skripten kann mit Hilfe der automatisch global sichtbaren Variablen <code>$_ENV</code> auf die Umgebungsvariablen zugegriffen werden. Um die Variable <code>REDIRECT_REMOTE_USER</code> zu lesen, schreibt man also <code>$_ENV['REDIRECT_REMOTE_USER']</code>.

=== Passwortschutz abhängig vom REQUEST_URI ===

Falls ich für eine oder mehrere REQUEST_URI eine htpasswd Abfrage möchte, z.B. für Keycloak Admin Login:

<syntaxhighlight lang=apache line>
SetEnvIf REQUEST_URI ^/realms/master/.* HTTPAUTHPROTECT

Authname "Privater Bereich, bitte Anmelden."
Authtype Basic
AuthUserFile /home/doms/login.beispielverein.de/.htpasswd

Order Allow,Deny
Satisfy any
Require valid-user
Allow from all
Deny from env=HTTPAUTHPROTECT
</syntaxhighlight>

Anders herum würde es auch gehen: Wenn ich für eine oder mehrere REQUEST_URI keine htpasswd Abfrage möchte:

<syntaxhighlight lang=apache line>
SetEnvIf REQUEST_URI ^/public/.* NOPASSWD

Authname "Privater Bereich, bitte Anmelden."
Authtype Basic
AuthUserFile /home/doms/app.beispielverein.de/.htpasswd

Order Deny,Allow
Satisfy Any
Deny from all
Require valid-user
Allow from env=NOPASSWD
</syntaxhighlight>

Siehe auch [https://stackoverflow.com/a/11439361/1632368] für eine Erklärung.

== Redirects ==

<syntaxhighlight lang=apache line>
Redirect permanent / http://www.example.com/
</syntaxhighlight>

== Rewrite Rules ==

<syntaxhighlight lang=apache line>
RewriteEngine On
RewriteRule ^mailman/(.*)$ /cgi-bin/mailman/$1
</syntaxhighlight>

Oder auch zum Testen:

<syntaxhighlight lang=apache line>
RewriteEngine on
RewriteBase /
RewriteRule "push/(.*)$" https://www.hostsharing.net/push/ [last]
RewriteRule .* https://www.hostsharing.net/alles/ [last]
</syntaxhighlight>

Mit curl testen:

<syntaxhighlight lang=bash>
curl -XGET https://hello.beispielverein.de/push/test -I
</syntaxhighlight>

Das gibt aus, wohin der Redirect geht: z.B.

<syntaxhighlight lang=html>
Location: https://www.hostsharing.net/push/
</syntaxhighlight>

== Nur SSL erlauben und automatisch umschalten ==

Bei per Symlink zusammengeschalteten Verzeichnissen, kann dies für die Verzeichnisse auf die nur per SSL zugegriffen werden soll, wie folgt erreicht werden:

<syntaxhighlight lang=apache line>
# SSL so fordern, dass ggf. Basic Auth nur einmal innerhalb von SSL abgefragt wird.
#
#SSLOptions +StrictRequire #Bei HS festgelegt.
SSLRequireSSL
ErrorDocument 403 https://xyz00.hostsharing.net/https/URL/mit/entspechendem/Ziel/Verzeichnis
</syntaxhighlight>

In diesem Beispiel wird auf eine xyz00 Domain umgeleitet für die das HS Zertifikat gilt. Liegen die Seiten nicht dort ist die entprechende URL des Speicherortes mit https:// anzugegeben.

Bei separaten Verzeichnissen für ssl und nicht-ssl kann auch ein permanenter Redirekt gelegt werden.

Beispiel:
<syntaxhighlight lang=apache line>
Redirect permanent / https://www.example.org/
</syntaxhighlight>

Um alle http Requests nach https weiter zu leiten:

<syntaxhighlight lang=apache line>
RewriteEngine On
RewriteCond %{SERVER_PORT} !=443
RewriteRule .* https://%{HTTP_HOST}:443%{REQUEST_URI} [QSA,R=permanent,L]
</syntaxhighlight>

==Verzeichnislisting ausschalten==

Ruft ein Nutzer ein Verzeichnis auf, z.B. www.example.com/verzeichnis, so wird normalerweise die sich darin befindliche index.html als Standard aufgerufen. Gibt es diese Datei nicht, wird der Inhalt des Verzeichnisses gelistet. Das kann ein Sicherheitsproblem sein.

Die Einstellung
<syntaxhighlight lang=apache line>
IndexIgnore *
</syntaxhighlight>
sorgt dafür, dass alle Datein Unterhalb des Speicherortes der .htaccess Datei für das Verzeichnislisting ignoriert werden.

Hinweis: Das Listen der Verzeichnisse kann auch schon auf Dateisystemebene durch ändern der Verzeichnisrechte (o-r) unterbunden werden, wodurch auch lokale User berücksichtigt werden.

== Ausnahme die eigene IP-Adresse ==

Zum Testen willst du möglicherweise auf ein anderes Backend zugreifen, als es die normalen Webseiten-Besucherinnen tun. Du kannst die eigene IP-Adresse als "RewriteCond" verwenden:

<syntaxhighlight lang=apache line>
DirectoryIndex disabled
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteCond %{REMOTE_ADDR} !=62.27.244.230
RewriteRule ^(.*) ajp://hsh02.hostsharing.net:8009/$1 [proxy,last]

RewriteRule ^(.*) ajp://127.0.0.1:34380/$1 [proxy,last]
</syntaxhighlight>

== Bestimmte Clients blockieren ==

Jeder Web-Browser gibt sich mit einer Kennung zu erkennen. Auch Bots sollten sich mit einer bestimmten Kennung zu erkennen geben. Diese Kennung wird ersichtlich, wenn Du die web.log Datei durchsuchst (siehe [[Traffic]]). Damit ist es möglich, bestimmte Clients oder Bots auszuschließen.

Hier im Beispiel werden der SemrushBot, der MJ12bot, und der AI Bot Claude von Anthropic ausgeschlossen:

<syntaxhighlight lang=apache line>
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_USER_AGENT} ^.*SemrushBot.*$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^.*MJ12bot.*$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^.*ClaudeBot.*$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^$
RewriteRule ^.* - [F,L]
</syntaxhighlight>

Siehe auch https://stackoverflow.com/a/35775449/1632368

== Bestimmte Verzeichnisse nicht ausliefern ==

zum Beispiel das .git Verzeichnis sollte nicht gezeigt werden:

<syntaxhighlight lang=apache line>
RedirectMatch 404 /\.git
</syntaxhighlight>

Oder wenn Wordpress für alle URLs mit HTTP Code 200 die Startseite anzeigt, denken manche Angreifer, es läuft ein mailman.

<syntaxhighlight lang=apache line>
RedirectMatch 404 /mailman/
</syntaxhighlight>

== Gesperrte Optionen ==

Einstellungen, die es ermöglichen würden, über den Webserver Rechte anderer
User zu erhalten, sind nicht erlaubt.
--
[[Kategorie:HSDoku]]
[[Kategorie:WWW]]
[[Kategorie:Glossar]]

.htaccess

2025-03-31T16:20:19Z

Tim: /* Rewrite Rules */

Mit <code>.htaccess</code> Dateien innerhalb der Dokument-Verzeichnisse einer Domain (möglichst in ~/doms/example.com/.htaccess oder gezielt in Unterverzeichnissen subs/www ect. ), können Einstellungen des Apache Webservers konfiguriert werden.

Zum Beispiel kann angegeben werden, welches Apache-Modul für bestimmte Dateien (oder bestimmte Datei-Endungen) benutzt werden soll, wohin Dokumente verschoben worden sind, oder auch, wer Zugriff auf die Dateien hat.

== Einstellen von MIME-Typen ==

<syntaxhighlight lang=apache line>
# Download von Zertifikaten ermöglichen:
AddType application/x-x509-ca-cert .crt
</syntaxhighlight>

== Einstellen des im HTTP Header angegebenen Zeichensatzes ==

für .html Dateien:
<syntaxhighlight lang=apache line>
AddCharset UTF-8 .html

# oder
AddDefaultCharset UTF-8
</syntaxhighlight>

(für PHP Skripte siehe [[PHP]] )

== Einstellen von Datei Handlern ==

<syntaxhighlight lang=apache line>
AddType application/x-httpd-phpcgi .php
Action application/x-httpd-phpcgi /fastcgi-bin/phpstub
</syntaxhighlight>

==Passwortschutz für Dateien==

'''Achtung:''' Sofern der Zugriff http Zugriff auf die Dateien nicht automatisch auf https:// bzw. [[TLS_/_SSL|SSL]] umgeleitet wird, können die Passwörter unverschlüsselt übertragen werden!

Zunächst wollen wir den Zugriff auf ein Unterverzeichnis unserer Beispiel-Domain per .htaccess einschränken. Dazu legen wir zunächst eine Passwort-Datei an. Am einfachsten lässt sich diese spezielle Passwort-Datei in einer Shell anlegen. Wir legen sie in das etc-Verzeichnis der Domain:

<syntaxhighlight lang=bash>
xyz00-doms@hopi$ cd ~/doms/example.com/etc
xyz00-doms@hopi$ htpasswd -c .htpasswd peter
New password: *****
Re-type new password: *****
xyz00-doms@hopi$
</syntaxhighlight>

Beim ersten User, hier peter wird das Programm htpasswd mit der Option -c (create) aufgerufen, aber auch wirklich nur beim ersten mal, da sonst die Datei .htpasswd neu erzeugt werden würde und vorherige Einträge damit gelöscht wären.

Sollte es beim Versuch, die Datei anzulegen, zu der Fehlermeldung kommando htpasswd nicht bekannt kommen, dann müssen wir zunächst den Befehl lokalisieren und mit dem richtigen Pfad neu aufrufen:

<syntaxhighlight lang=bash>
xyz00-doms@hopi$ locate htpasswd
/usr/bin/htpasswd
xyz00-doms@hopi$ /usr/bin/htpasswd -c .htpasswd peter
</syntaxhighlight>

Beim zweiten User erfolgt der Aufruf dann ohne die Option -c:

<syntaxhighlight lang=bash>
xyz00-doms@hopi$ htpasswd .htpasswd petra
New password: *****
Re-type new password: *****
xyz00-doms@hopi$
</syntaxhighlight>

Die Sternchen * stehen selbstverständlich für das jeweilige Passwort, welches dem User zugeordnet werden soll.

Diese Datei könnten wir auch einfach mit scp/pscp oder FTP hochladen, dabei stellt sich dann jedoch die Frage, wie wir sie erzeugen. Auf den meisten Windows-Systemen dürfte kein htpasswd-Kommando verfügbar sein. Für diese Fälle gibt es eine online-Version z.b.: https://de.functions-online.com/crypt.html
die Ausgabe einfach mit Copy&Paste in eine Datei kopieren und diese hochladen.

Die so angelegte Passwort-Datei kann nun von einer oder mehreren .htaccess-Dateien verwendet werden. Dazu begeben wir uns in das zu schützende Verzeichnis und legen dort eine Datei .htaccess an. Dies kann wieder per Upload oder in einer Shell geschehen. Die Datei kann beispielsweise so aussehen:

<syntaxhighlight lang=apache line>
order allow,deny
allow from all
require valid-user
Authname "Privater Bereich, bitte Anmelden."
Authtype Basic
AuthUserFile /home/doms/example.com/etc/.htpasswd
</syntaxhighlight>

Dabei verweist die letzte Zeile auf die von uns angelegte .htpasswd Datei. Zu beachten ist:
* Das die Pfadangabe absolut erfolgt, um einen "Internal Server Error" zu vermeiden.
* Falls die Datei innerhalb des Dokumenten Verzeichnisses liegen muss, sie auf jeden Fall .htpasswd heißt, damit sie vom Webserver nicht herausgegeben wird.
* Die .htaccess Datei in den Paketdomains innerhalb des web/ bzw. web-ssl/ Verzeichnisses liegen muss, damit kein "Internal Server Error" auftritt.

===Passwortschutz von CGI- und PHP-Anwendungen===

Mit dem beschriebenen Mechanismus können selbstverständlich auch PHP-Skripte und CGI-Anwendungen vor unberechtigten Zugriffen geschützt werden. In dem geschützten Skript kann über die Umgebungsvariable <code>REDIRECT_REMOTE_USER</code> der Benutzername des Benutzers abgefragt werden, der sich angemeldet hat.

In PHP-Skripten kann mit Hilfe der automatisch global sichtbaren Variablen <code>$_ENV</code> auf die Umgebungsvariablen zugegriffen werden. Um die Variable <code>REDIRECT_REMOTE_USER</code> zu lesen, schreibt man also <code>$_ENV['REDIRECT_REMOTE_USER']</code>.

=== Passwortschutz abhängig vom REQUEST_URI ===

Falls ich für eine oder mehrere REQUEST_URI eine htpasswd Abfrage möchte, z.B. für Keycloak Admin Login:

<syntaxhighlight lang=apache line>
SetEnvIf REQUEST_URI ^/realms/master/.* HTTPAUTHPROTECT

Authname "Privater Bereich, bitte Anmelden."
Authtype Basic
AuthUserFile /home/doms/login.beispielverein.de/.htpasswd

Order Allow,Deny
Satisfy any
Require valid-user
Allow from all
Deny from env=HTTPAUTHPROTECT
</syntaxhighlight>

Anders herum würde es auch gehen: Wenn ich für eine oder mehrere REQUEST_URI keine htpasswd Abfrage möchte:

<syntaxhighlight lang=apache line>
SetEnvIf REQUEST_URI ^/public/.* NOPASSWD

Authname "Privater Bereich, bitte Anmelden."
Authtype Basic
AuthUserFile /home/doms/app.beispielverein.de/.htpasswd

Order Deny,Allow
Satisfy Any
Deny from all
Require valid-user
Allow from env=NOPASSWD
</syntaxhighlight>

Siehe auch [https://stackoverflow.com/a/11439361/1632368] für eine Erklärung.

== Redirects ==

<syntaxhighlight lang=apache line>
Redirect permanent / http://www.example.com/
</syntaxhighlight>

== Rewrite Rules ==

<syntaxhighlight lang=apache line>
RewriteEngine On
RewriteRule ^mailman/(.*)$ /cgi-bin/mailman/$1
</syntaxhighlight>

Oder auch zum Testen:

<syntaxhighlight lang=apache line>
RewriteEngine on
RewriteBase /
RewriteRule "push/(.*)$" https://www.hostsharing.net/push/ [last]
RewriteRule .* https://www.hostsharing.net/alles/ [last]
</syntaxhighlight>

Mit curl testen:

<syntaxhighlight lang=bash>
curl -XGET https://hello.beispielverein.de/push/test -I
</syntaxhighlight>

Das gibt aus, wohin der Redirect geht: z.B.

<syntaxhighlight lang=html>
Location: https://www.hostsharing.net/alles/
</syntaxhighlight>

== Nur SSL erlauben und automatisch umschalten ==

Bei per Symlink zusammengeschalteten Verzeichnissen, kann dies für die Verzeichnisse auf die nur per SSL zugegriffen werden soll, wie folgt erreicht werden:

<syntaxhighlight lang=apache line>
# SSL so fordern, dass ggf. Basic Auth nur einmal innerhalb von SSL abgefragt wird.
#
#SSLOptions +StrictRequire #Bei HS festgelegt.
SSLRequireSSL
ErrorDocument 403 https://xyz00.hostsharing.net/https/URL/mit/entspechendem/Ziel/Verzeichnis
</syntaxhighlight>

In diesem Beispiel wird auf eine xyz00 Domain umgeleitet für die das HS Zertifikat gilt. Liegen die Seiten nicht dort ist die entprechende URL des Speicherortes mit https:// anzugegeben.

Bei separaten Verzeichnissen für ssl und nicht-ssl kann auch ein permanenter Redirekt gelegt werden.

Beispiel:
<syntaxhighlight lang=apache line>
Redirect permanent / https://www.example.org/
</syntaxhighlight>

Um alle http Requests nach https weiter zu leiten:

<syntaxhighlight lang=apache line>
RewriteEngine On
RewriteCond %{SERVER_PORT} !=443
RewriteRule .* https://%{HTTP_HOST}:443%{REQUEST_URI} [QSA,R=permanent,L]
</syntaxhighlight>

==Verzeichnislisting ausschalten==

Ruft ein Nutzer ein Verzeichnis auf, z.B. www.example.com/verzeichnis, so wird normalerweise die sich darin befindliche index.html als Standard aufgerufen. Gibt es diese Datei nicht, wird der Inhalt des Verzeichnisses gelistet. Das kann ein Sicherheitsproblem sein.

Die Einstellung
<syntaxhighlight lang=apache line>
IndexIgnore *
</syntaxhighlight>
sorgt dafür, dass alle Datein Unterhalb des Speicherortes der .htaccess Datei für das Verzeichnislisting ignoriert werden.

Hinweis: Das Listen der Verzeichnisse kann auch schon auf Dateisystemebene durch ändern der Verzeichnisrechte (o-r) unterbunden werden, wodurch auch lokale User berücksichtigt werden.

== Ausnahme die eigene IP-Adresse ==

Zum Testen willst du möglicherweise auf ein anderes Backend zugreifen, als es die normalen Webseiten-Besucherinnen tun. Du kannst die eigene IP-Adresse als "RewriteCond" verwenden:

<syntaxhighlight lang=apache line>
DirectoryIndex disabled
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteCond %{REMOTE_ADDR} !=62.27.244.230
RewriteRule ^(.*) ajp://hsh02.hostsharing.net:8009/$1 [proxy,last]

RewriteRule ^(.*) ajp://127.0.0.1:34380/$1 [proxy,last]
</syntaxhighlight>

== Bestimmte Clients blockieren ==

Jeder Web-Browser gibt sich mit einer Kennung zu erkennen. Auch Bots sollten sich mit einer bestimmten Kennung zu erkennen geben. Diese Kennung wird ersichtlich, wenn Du die web.log Datei durchsuchst (siehe [[Traffic]]). Damit ist es möglich, bestimmte Clients oder Bots auszuschließen.

Hier im Beispiel werden der SemrushBot, der MJ12bot, und der AI Bot Claude von Anthropic ausgeschlossen:

<syntaxhighlight lang=apache line>
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_USER_AGENT} ^.*SemrushBot.*$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^.*MJ12bot.*$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^.*ClaudeBot.*$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^$
RewriteRule ^.* - [F,L]
</syntaxhighlight>

Siehe auch https://stackoverflow.com/a/35775449/1632368

== Bestimmte Verzeichnisse nicht ausliefern ==

zum Beispiel das .git Verzeichnis sollte nicht gezeigt werden:

<syntaxhighlight lang=apache line>
RedirectMatch 404 /\.git
</syntaxhighlight>

Oder wenn Wordpress für alle URLs mit HTTP Code 200 die Startseite anzeigt, denken manche Angreifer, es läuft ein mailman.

<syntaxhighlight lang=apache line>
RedirectMatch 404 /mailman/
</syntaxhighlight>

== Gesperrte Optionen ==

Einstellungen, die es ermöglichen würden, über den Webserver Rechte anderer
User zu erhalten, sind nicht erlaubt.
--
[[Kategorie:HSDoku]]
[[Kategorie:WWW]]
[[Kategorie:Glossar]]

.htaccess

2025-03-31T16:19:35Z

Tim: /* Rewrite Rules */

Mit <code>.htaccess</code> Dateien innerhalb der Dokument-Verzeichnisse einer Domain (möglichst in ~/doms/example.com/.htaccess oder gezielt in Unterverzeichnissen subs/www ect. ), können Einstellungen des Apache Webservers konfiguriert werden.

Zum Beispiel kann angegeben werden, welches Apache-Modul für bestimmte Dateien (oder bestimmte Datei-Endungen) benutzt werden soll, wohin Dokumente verschoben worden sind, oder auch, wer Zugriff auf die Dateien hat.

== Einstellen von MIME-Typen ==

<syntaxhighlight lang=apache line>
# Download von Zertifikaten ermöglichen:
AddType application/x-x509-ca-cert .crt
</syntaxhighlight>

== Einstellen des im HTTP Header angegebenen Zeichensatzes ==

für .html Dateien:
<syntaxhighlight lang=apache line>
AddCharset UTF-8 .html

# oder
AddDefaultCharset UTF-8
</syntaxhighlight>

(für PHP Skripte siehe [[PHP]] )

== Einstellen von Datei Handlern ==

<syntaxhighlight lang=apache line>
AddType application/x-httpd-phpcgi .php
Action application/x-httpd-phpcgi /fastcgi-bin/phpstub
</syntaxhighlight>

==Passwortschutz für Dateien==

'''Achtung:''' Sofern der Zugriff http Zugriff auf die Dateien nicht automatisch auf https:// bzw. [[TLS_/_SSL|SSL]] umgeleitet wird, können die Passwörter unverschlüsselt übertragen werden!

Zunächst wollen wir den Zugriff auf ein Unterverzeichnis unserer Beispiel-Domain per .htaccess einschränken. Dazu legen wir zunächst eine Passwort-Datei an. Am einfachsten lässt sich diese spezielle Passwort-Datei in einer Shell anlegen. Wir legen sie in das etc-Verzeichnis der Domain:

<syntaxhighlight lang=bash>
xyz00-doms@hopi$ cd ~/doms/example.com/etc
xyz00-doms@hopi$ htpasswd -c .htpasswd peter
New password: *****
Re-type new password: *****
xyz00-doms@hopi$
</syntaxhighlight>

Beim ersten User, hier peter wird das Programm htpasswd mit der Option -c (create) aufgerufen, aber auch wirklich nur beim ersten mal, da sonst die Datei .htpasswd neu erzeugt werden würde und vorherige Einträge damit gelöscht wären.

Sollte es beim Versuch, die Datei anzulegen, zu der Fehlermeldung kommando htpasswd nicht bekannt kommen, dann müssen wir zunächst den Befehl lokalisieren und mit dem richtigen Pfad neu aufrufen:

<syntaxhighlight lang=bash>
xyz00-doms@hopi$ locate htpasswd
/usr/bin/htpasswd
xyz00-doms@hopi$ /usr/bin/htpasswd -c .htpasswd peter
</syntaxhighlight>

Beim zweiten User erfolgt der Aufruf dann ohne die Option -c:

<syntaxhighlight lang=bash>
xyz00-doms@hopi$ htpasswd .htpasswd petra
New password: *****
Re-type new password: *****
xyz00-doms@hopi$
</syntaxhighlight>

Die Sternchen * stehen selbstverständlich für das jeweilige Passwort, welches dem User zugeordnet werden soll.

Diese Datei könnten wir auch einfach mit scp/pscp oder FTP hochladen, dabei stellt sich dann jedoch die Frage, wie wir sie erzeugen. Auf den meisten Windows-Systemen dürfte kein htpasswd-Kommando verfügbar sein. Für diese Fälle gibt es eine online-Version z.b.: https://de.functions-online.com/crypt.html
die Ausgabe einfach mit Copy&Paste in eine Datei kopieren und diese hochladen.

Die so angelegte Passwort-Datei kann nun von einer oder mehreren .htaccess-Dateien verwendet werden. Dazu begeben wir uns in das zu schützende Verzeichnis und legen dort eine Datei .htaccess an. Dies kann wieder per Upload oder in einer Shell geschehen. Die Datei kann beispielsweise so aussehen:

<syntaxhighlight lang=apache line>
order allow,deny
allow from all
require valid-user
Authname "Privater Bereich, bitte Anmelden."
Authtype Basic
AuthUserFile /home/doms/example.com/etc/.htpasswd
</syntaxhighlight>

Dabei verweist die letzte Zeile auf die von uns angelegte .htpasswd Datei. Zu beachten ist:
* Das die Pfadangabe absolut erfolgt, um einen "Internal Server Error" zu vermeiden.
* Falls die Datei innerhalb des Dokumenten Verzeichnisses liegen muss, sie auf jeden Fall .htpasswd heißt, damit sie vom Webserver nicht herausgegeben wird.
* Die .htaccess Datei in den Paketdomains innerhalb des web/ bzw. web-ssl/ Verzeichnisses liegen muss, damit kein "Internal Server Error" auftritt.

===Passwortschutz von CGI- und PHP-Anwendungen===

Mit dem beschriebenen Mechanismus können selbstverständlich auch PHP-Skripte und CGI-Anwendungen vor unberechtigten Zugriffen geschützt werden. In dem geschützten Skript kann über die Umgebungsvariable <code>REDIRECT_REMOTE_USER</code> der Benutzername des Benutzers abgefragt werden, der sich angemeldet hat.

In PHP-Skripten kann mit Hilfe der automatisch global sichtbaren Variablen <code>$_ENV</code> auf die Umgebungsvariablen zugegriffen werden. Um die Variable <code>REDIRECT_REMOTE_USER</code> zu lesen, schreibt man also <code>$_ENV['REDIRECT_REMOTE_USER']</code>.

=== Passwortschutz abhängig vom REQUEST_URI ===

Falls ich für eine oder mehrere REQUEST_URI eine htpasswd Abfrage möchte, z.B. für Keycloak Admin Login:

<syntaxhighlight lang=apache line>
SetEnvIf REQUEST_URI ^/realms/master/.* HTTPAUTHPROTECT

Authname "Privater Bereich, bitte Anmelden."
Authtype Basic
AuthUserFile /home/doms/login.beispielverein.de/.htpasswd

Order Allow,Deny
Satisfy any
Require valid-user
Allow from all
Deny from env=HTTPAUTHPROTECT
</syntaxhighlight>

Anders herum würde es auch gehen: Wenn ich für eine oder mehrere REQUEST_URI keine htpasswd Abfrage möchte:

<syntaxhighlight lang=apache line>
SetEnvIf REQUEST_URI ^/public/.* NOPASSWD

Authname "Privater Bereich, bitte Anmelden."
Authtype Basic
AuthUserFile /home/doms/app.beispielverein.de/.htpasswd

Order Deny,Allow
Satisfy Any
Deny from all
Require valid-user
Allow from env=NOPASSWD
</syntaxhighlight>

Siehe auch [https://stackoverflow.com/a/11439361/1632368] für eine Erklärung.

== Redirects ==

<syntaxhighlight lang=apache line>
Redirect permanent / http://www.example.com/
</syntaxhighlight>

== Rewrite Rules ==

<syntaxhighlight lang=apache line>
RewriteEngine On
RewriteRule ^mailman/(.*)$ /cgi-bin/mailman/$1
</syntaxhighlight>

Oder auch zum Testen:

<syntaxhighlight lang=apache line>
RewriteEngine on
RewriteBase /
RewriteRule "push/(.*)$" https://www.hostsharing.net/push/ [last]
RewriteRule .* https://www.hostsharing.net/alles/ [last]
</syntaxhighlight>

Mit curl testen:

<syntaxhighlight lang=bash>
curl -XGET https://hello.beispielverein.de/push/test
</syntaxhighlight>

Das gibt aus, wohin der Redirect geht: z.B.

<syntaxhighlight lang=html>
The document has moved <a href="https://www.hostsharing.net/alles/">here</a>.
</syntaxhighlight>

== Nur SSL erlauben und automatisch umschalten ==

Bei per Symlink zusammengeschalteten Verzeichnissen, kann dies für die Verzeichnisse auf die nur per SSL zugegriffen werden soll, wie folgt erreicht werden:

<syntaxhighlight lang=apache line>
# SSL so fordern, dass ggf. Basic Auth nur einmal innerhalb von SSL abgefragt wird.
#
#SSLOptions +StrictRequire #Bei HS festgelegt.
SSLRequireSSL
ErrorDocument 403 https://xyz00.hostsharing.net/https/URL/mit/entspechendem/Ziel/Verzeichnis
</syntaxhighlight>

In diesem Beispiel wird auf eine xyz00 Domain umgeleitet für die das HS Zertifikat gilt. Liegen die Seiten nicht dort ist die entprechende URL des Speicherortes mit https:// anzugegeben.

Bei separaten Verzeichnissen für ssl und nicht-ssl kann auch ein permanenter Redirekt gelegt werden.

Beispiel:
<syntaxhighlight lang=apache line>
Redirect permanent / https://www.example.org/
</syntaxhighlight>

Um alle http Requests nach https weiter zu leiten:

<syntaxhighlight lang=apache line>
RewriteEngine On
RewriteCond %{SERVER_PORT} !=443
RewriteRule .* https://%{HTTP_HOST}:443%{REQUEST_URI} [QSA,R=permanent,L]
</syntaxhighlight>

==Verzeichnislisting ausschalten==

Ruft ein Nutzer ein Verzeichnis auf, z.B. www.example.com/verzeichnis, so wird normalerweise die sich darin befindliche index.html als Standard aufgerufen. Gibt es diese Datei nicht, wird der Inhalt des Verzeichnisses gelistet. Das kann ein Sicherheitsproblem sein.

Die Einstellung
<syntaxhighlight lang=apache line>
IndexIgnore *
</syntaxhighlight>
sorgt dafür, dass alle Datein Unterhalb des Speicherortes der .htaccess Datei für das Verzeichnislisting ignoriert werden.

Hinweis: Das Listen der Verzeichnisse kann auch schon auf Dateisystemebene durch ändern der Verzeichnisrechte (o-r) unterbunden werden, wodurch auch lokale User berücksichtigt werden.

== Ausnahme die eigene IP-Adresse ==

Zum Testen willst du möglicherweise auf ein anderes Backend zugreifen, als es die normalen Webseiten-Besucherinnen tun. Du kannst die eigene IP-Adresse als "RewriteCond" verwenden:

<syntaxhighlight lang=apache line>
DirectoryIndex disabled
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteCond %{REMOTE_ADDR} !=62.27.244.230
RewriteRule ^(.*) ajp://hsh02.hostsharing.net:8009/$1 [proxy,last]

RewriteRule ^(.*) ajp://127.0.0.1:34380/$1 [proxy,last]
</syntaxhighlight>

== Bestimmte Clients blockieren ==

Jeder Web-Browser gibt sich mit einer Kennung zu erkennen. Auch Bots sollten sich mit einer bestimmten Kennung zu erkennen geben. Diese Kennung wird ersichtlich, wenn Du die web.log Datei durchsuchst (siehe [[Traffic]]). Damit ist es möglich, bestimmte Clients oder Bots auszuschließen.

Hier im Beispiel werden der SemrushBot, der MJ12bot, und der AI Bot Claude von Anthropic ausgeschlossen:

<syntaxhighlight lang=apache line>
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_USER_AGENT} ^.*SemrushBot.*$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^.*MJ12bot.*$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^.*ClaudeBot.*$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^$
RewriteRule ^.* - [F,L]
</syntaxhighlight>

Siehe auch https://stackoverflow.com/a/35775449/1632368

== Bestimmte Verzeichnisse nicht ausliefern ==

zum Beispiel das .git Verzeichnis sollte nicht gezeigt werden:

<syntaxhighlight lang=apache line>
RedirectMatch 404 /\.git
</syntaxhighlight>

Oder wenn Wordpress für alle URLs mit HTTP Code 200 die Startseite anzeigt, denken manche Angreifer, es läuft ein mailman.

<syntaxhighlight lang=apache line>
RedirectMatch 404 /mailman/
</syntaxhighlight>

== Gesperrte Optionen ==

Einstellungen, die es ermöglichen würden, über den Webserver Rechte anderer
User zu erhalten, sind nicht erlaubt.
--
[[Kategorie:HSDoku]]
[[Kategorie:WWW]]
[[Kategorie:Glossar]]

.htaccess

2025-03-31T16:18:26Z

Tim: /* Rewrite Rules */

Mit <code>.htaccess</code> Dateien innerhalb der Dokument-Verzeichnisse einer Domain (möglichst in ~/doms/example.com/.htaccess oder gezielt in Unterverzeichnissen subs/www ect. ), können Einstellungen des Apache Webservers konfiguriert werden.

Zum Beispiel kann angegeben werden, welches Apache-Modul für bestimmte Dateien (oder bestimmte Datei-Endungen) benutzt werden soll, wohin Dokumente verschoben worden sind, oder auch, wer Zugriff auf die Dateien hat.

== Einstellen von MIME-Typen ==

<syntaxhighlight lang=apache line>
# Download von Zertifikaten ermöglichen:
AddType application/x-x509-ca-cert .crt
</syntaxhighlight>

== Einstellen des im HTTP Header angegebenen Zeichensatzes ==

für .html Dateien:
<syntaxhighlight lang=apache line>
AddCharset UTF-8 .html

# oder
AddDefaultCharset UTF-8
</syntaxhighlight>

(für PHP Skripte siehe [[PHP]] )

== Einstellen von Datei Handlern ==

<syntaxhighlight lang=apache line>
AddType application/x-httpd-phpcgi .php
Action application/x-httpd-phpcgi /fastcgi-bin/phpstub
</syntaxhighlight>

==Passwortschutz für Dateien==

'''Achtung:''' Sofern der Zugriff http Zugriff auf die Dateien nicht automatisch auf https:// bzw. [[TLS_/_SSL|SSL]] umgeleitet wird, können die Passwörter unverschlüsselt übertragen werden!

Zunächst wollen wir den Zugriff auf ein Unterverzeichnis unserer Beispiel-Domain per .htaccess einschränken. Dazu legen wir zunächst eine Passwort-Datei an. Am einfachsten lässt sich diese spezielle Passwort-Datei in einer Shell anlegen. Wir legen sie in das etc-Verzeichnis der Domain:

<syntaxhighlight lang=bash>
xyz00-doms@hopi$ cd ~/doms/example.com/etc
xyz00-doms@hopi$ htpasswd -c .htpasswd peter
New password: *****
Re-type new password: *****
xyz00-doms@hopi$
</syntaxhighlight>

Beim ersten User, hier peter wird das Programm htpasswd mit der Option -c (create) aufgerufen, aber auch wirklich nur beim ersten mal, da sonst die Datei .htpasswd neu erzeugt werden würde und vorherige Einträge damit gelöscht wären.

Sollte es beim Versuch, die Datei anzulegen, zu der Fehlermeldung kommando htpasswd nicht bekannt kommen, dann müssen wir zunächst den Befehl lokalisieren und mit dem richtigen Pfad neu aufrufen:

<syntaxhighlight lang=bash>
xyz00-doms@hopi$ locate htpasswd
/usr/bin/htpasswd
xyz00-doms@hopi$ /usr/bin/htpasswd -c .htpasswd peter
</syntaxhighlight>

Beim zweiten User erfolgt der Aufruf dann ohne die Option -c:

<syntaxhighlight lang=bash>
xyz00-doms@hopi$ htpasswd .htpasswd petra
New password: *****
Re-type new password: *****
xyz00-doms@hopi$
</syntaxhighlight>

Die Sternchen * stehen selbstverständlich für das jeweilige Passwort, welches dem User zugeordnet werden soll.

Diese Datei könnten wir auch einfach mit scp/pscp oder FTP hochladen, dabei stellt sich dann jedoch die Frage, wie wir sie erzeugen. Auf den meisten Windows-Systemen dürfte kein htpasswd-Kommando verfügbar sein. Für diese Fälle gibt es eine online-Version z.b.: https://de.functions-online.com/crypt.html
die Ausgabe einfach mit Copy&Paste in eine Datei kopieren und diese hochladen.

Die so angelegte Passwort-Datei kann nun von einer oder mehreren .htaccess-Dateien verwendet werden. Dazu begeben wir uns in das zu schützende Verzeichnis und legen dort eine Datei .htaccess an. Dies kann wieder per Upload oder in einer Shell geschehen. Die Datei kann beispielsweise so aussehen:

<syntaxhighlight lang=apache line>
order allow,deny
allow from all
require valid-user
Authname "Privater Bereich, bitte Anmelden."
Authtype Basic
AuthUserFile /home/doms/example.com/etc/.htpasswd
</syntaxhighlight>

Dabei verweist die letzte Zeile auf die von uns angelegte .htpasswd Datei. Zu beachten ist:
* Das die Pfadangabe absolut erfolgt, um einen "Internal Server Error" zu vermeiden.
* Falls die Datei innerhalb des Dokumenten Verzeichnisses liegen muss, sie auf jeden Fall .htpasswd heißt, damit sie vom Webserver nicht herausgegeben wird.
* Die .htaccess Datei in den Paketdomains innerhalb des web/ bzw. web-ssl/ Verzeichnisses liegen muss, damit kein "Internal Server Error" auftritt.

===Passwortschutz von CGI- und PHP-Anwendungen===

Mit dem beschriebenen Mechanismus können selbstverständlich auch PHP-Skripte und CGI-Anwendungen vor unberechtigten Zugriffen geschützt werden. In dem geschützten Skript kann über die Umgebungsvariable <code>REDIRECT_REMOTE_USER</code> der Benutzername des Benutzers abgefragt werden, der sich angemeldet hat.

In PHP-Skripten kann mit Hilfe der automatisch global sichtbaren Variablen <code>$_ENV</code> auf die Umgebungsvariablen zugegriffen werden. Um die Variable <code>REDIRECT_REMOTE_USER</code> zu lesen, schreibt man also <code>$_ENV['REDIRECT_REMOTE_USER']</code>.

=== Passwortschutz abhängig vom REQUEST_URI ===

Falls ich für eine oder mehrere REQUEST_URI eine htpasswd Abfrage möchte, z.B. für Keycloak Admin Login:

<syntaxhighlight lang=apache line>
SetEnvIf REQUEST_URI ^/realms/master/.* HTTPAUTHPROTECT

Authname "Privater Bereich, bitte Anmelden."
Authtype Basic
AuthUserFile /home/doms/login.beispielverein.de/.htpasswd

Order Allow,Deny
Satisfy any
Require valid-user
Allow from all
Deny from env=HTTPAUTHPROTECT
</syntaxhighlight>

Anders herum würde es auch gehen: Wenn ich für eine oder mehrere REQUEST_URI keine htpasswd Abfrage möchte:

<syntaxhighlight lang=apache line>
SetEnvIf REQUEST_URI ^/public/.* NOPASSWD

Authname "Privater Bereich, bitte Anmelden."
Authtype Basic
AuthUserFile /home/doms/app.beispielverein.de/.htpasswd

Order Deny,Allow
Satisfy Any
Deny from all
Require valid-user
Allow from env=NOPASSWD
</syntaxhighlight>

Siehe auch [https://stackoverflow.com/a/11439361/1632368] für eine Erklärung.

== Redirects ==

<syntaxhighlight lang=apache line>
Redirect permanent / http://www.example.com/
</syntaxhighlight>

== Rewrite Rules ==

<syntaxhighlight lang=apache line>
RewriteEngine On
RewriteRule ^mailman/(.*)$ /cgi-bin/mailman/$1
</syntaxhighlight>

Oder auch zum Testen:

<syntaxhighlight lang=apache line>
RewriteEngine on
RewriteBase /
RewriteRule "push/(.*)$" https://www.hostsharing.net/push/ [last]
RewriteRule .* https://www.hostsharing.net/alles/ [last]
</syntaxhighlight>

Mit curl testen:

<syntaxhighlight lang=bash>
curl -XGET https://hello.beispielverein.de/push/test
</syntaxhighlight>

Das gibt aus, wohin der Redirect geht: z.B <code>The document has moved <a href="https://www.hostsharing.net/alles/">here</a>.</code>

== Nur SSL erlauben und automatisch umschalten ==

Bei per Symlink zusammengeschalteten Verzeichnissen, kann dies für die Verzeichnisse auf die nur per SSL zugegriffen werden soll, wie folgt erreicht werden:

<syntaxhighlight lang=apache line>
# SSL so fordern, dass ggf. Basic Auth nur einmal innerhalb von SSL abgefragt wird.
#
#SSLOptions +StrictRequire #Bei HS festgelegt.
SSLRequireSSL
ErrorDocument 403 https://xyz00.hostsharing.net/https/URL/mit/entspechendem/Ziel/Verzeichnis
</syntaxhighlight>

In diesem Beispiel wird auf eine xyz00 Domain umgeleitet für die das HS Zertifikat gilt. Liegen die Seiten nicht dort ist die entprechende URL des Speicherortes mit https:// anzugegeben.

Bei separaten Verzeichnissen für ssl und nicht-ssl kann auch ein permanenter Redirekt gelegt werden.

Beispiel:
<syntaxhighlight lang=apache line>
Redirect permanent / https://www.example.org/
</syntaxhighlight>

Um alle http Requests nach https weiter zu leiten:

<syntaxhighlight lang=apache line>
RewriteEngine On
RewriteCond %{SERVER_PORT} !=443
RewriteRule .* https://%{HTTP_HOST}:443%{REQUEST_URI} [QSA,R=permanent,L]
</syntaxhighlight>

==Verzeichnislisting ausschalten==

Ruft ein Nutzer ein Verzeichnis auf, z.B. www.example.com/verzeichnis, so wird normalerweise die sich darin befindliche index.html als Standard aufgerufen. Gibt es diese Datei nicht, wird der Inhalt des Verzeichnisses gelistet. Das kann ein Sicherheitsproblem sein.

Die Einstellung
<syntaxhighlight lang=apache line>
IndexIgnore *
</syntaxhighlight>
sorgt dafür, dass alle Datein Unterhalb des Speicherortes der .htaccess Datei für das Verzeichnislisting ignoriert werden.

Hinweis: Das Listen der Verzeichnisse kann auch schon auf Dateisystemebene durch ändern der Verzeichnisrechte (o-r) unterbunden werden, wodurch auch lokale User berücksichtigt werden.

== Ausnahme die eigene IP-Adresse ==

Zum Testen willst du möglicherweise auf ein anderes Backend zugreifen, als es die normalen Webseiten-Besucherinnen tun. Du kannst die eigene IP-Adresse als "RewriteCond" verwenden:

<syntaxhighlight lang=apache line>
DirectoryIndex disabled
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteCond %{REMOTE_ADDR} !=62.27.244.230
RewriteRule ^(.*) ajp://hsh02.hostsharing.net:8009/$1 [proxy,last]

RewriteRule ^(.*) ajp://127.0.0.1:34380/$1 [proxy,last]
</syntaxhighlight>

== Bestimmte Clients blockieren ==

Jeder Web-Browser gibt sich mit einer Kennung zu erkennen. Auch Bots sollten sich mit einer bestimmten Kennung zu erkennen geben. Diese Kennung wird ersichtlich, wenn Du die web.log Datei durchsuchst (siehe [[Traffic]]). Damit ist es möglich, bestimmte Clients oder Bots auszuschließen.

Hier im Beispiel werden der SemrushBot, der MJ12bot, und der AI Bot Claude von Anthropic ausgeschlossen:

<syntaxhighlight lang=apache line>
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_USER_AGENT} ^.*SemrushBot.*$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^.*MJ12bot.*$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^.*ClaudeBot.*$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^$
RewriteRule ^.* - [F,L]
</syntaxhighlight>

Siehe auch https://stackoverflow.com/a/35775449/1632368

== Bestimmte Verzeichnisse nicht ausliefern ==

zum Beispiel das .git Verzeichnis sollte nicht gezeigt werden:

<syntaxhighlight lang=apache line>
RedirectMatch 404 /\.git
</syntaxhighlight>

Oder wenn Wordpress für alle URLs mit HTTP Code 200 die Startseite anzeigt, denken manche Angreifer, es läuft ein mailman.

<syntaxhighlight lang=apache line>
RedirectMatch 404 /mailman/
</syntaxhighlight>

== Gesperrte Optionen ==

Einstellungen, die es ermöglichen würden, über den Webserver Rechte anderer
User zu erhalten, sind nicht erlaubt.
--
[[Kategorie:HSDoku]]
[[Kategorie:WWW]]
[[Kategorie:Glossar]]

RAM Belegung

2025-03-28T10:49:48Z

Tim: /* systemd status slice */

== Das Problem ==
Manchmal ist es sinnvoll, gerade bei komplexeren Installationen jenseits von PHP, dass man weiß, wieviel RAM Hauptspeicher für eine Anwendung verwendet wird.

Generell ist zu empfehlen, jede Anwendung in einem eigenen User zu betreiben. Das hilft auch hier, denn dann kann man leichter sehen, welche Anwendung wieviel Speicher verbraucht.

== htop ==
Ein hilfreicher Befehl ist <code>htop</code>:

{{Textkasten|gruen||xyz00-max@h01:~$ htop --user `whoami`}}

bzw.

{{Textkasten|gruen||xyz00-max@h01:~$ htop --user xyz00-max}}

Mit diesem Befehl werden für den aktuellen Benutzer xyz00-max die einzelnen Prozesse angezeigt. Leider ist aber der Speicherverbrauch im Hauptspeicher nicht so einfach zu erkennen.

== systemd status slice ==

Siehe auch [[Prozessmanagement_mit_systemd_im_Userspace#RAM_Kontingent_eines_Webspace|RAM Kontingent eines Webspace]]

<syntaxhighlight lang="bash">
systemctl status pacs-xyz00.slice
</syntaxhighlight>

Da wird der RAM Verbrauch für den gesamten Webspace xyz00 angezeigt.

== Skript list-memory-usage ==
Unser Mitglied Timotheus Pokorra hat ein [https://codeberg.org/tpokorra/hostsharing-scripts/src/branch/main/list-memory-usage Skript in Python] geschrieben, das den Speicherverbrauch pro Benutzer und auch in einer Übersicht anzeigen kann.

Es wird heruntergeladen und für die Ausführung vorbereitet:

{{Textkasten|gruen||
xyz00@h01:~$ wget https://codeberg.org/tpokorra/hostsharing-scripts/raw/branch/main/list-memory-usage
xyz00@h01:~$ chmod a+x list-memory-usage}}

Nun gibt es folgende Optionen:

Zeigt alle Prozesse, nach Größe sortiert, inkl. des Users und dem Namen des Prozesses und der belegte Speicherplatz im Arbeitsspeicher. Darunter wird die Summe aller Prozesse pro User gelistet, nach Gesamtgröße sortiert:
{{Textkasten|gruen||xyz00@h01:~$ ./list-memory-usage}}

Zeige alle Prozesse eines bestimmten Benutzers, und die Summe des belegten Arbeitsspeichers:
{{Textkasten|gruen||xyz00@h01:~$ ./list-memory-usage --user xyz00-user }}

Zeige alle Prozesse eines bestimmten Programms, über alle Benutzer hinweg:
{{Textkasten|gruen||xyz00@h01:~$ ./list-memory-usage --name php }}

Normalerweise werden einige Prozesse und Benutzer ausgeblendet. Mit dieser Option werden alle Prozesse und Benutzer berücksichtigt:
{{Textkasten|gruen||xyz00@h01:~$ ./list-memory-usage --all}}

----
[[Kategorie:Pakete bei HS]]
[[Kategorie:HSDoku]]

RAM Belegung

2025-03-28T10:49:16Z

Tim:

== Das Problem ==
Manchmal ist es sinnvoll, gerade bei komplexeren Installationen jenseits von PHP, dass man weiß, wieviel RAM Hauptspeicher für eine Anwendung verwendet wird.

Generell ist zu empfehlen, jede Anwendung in einem eigenen User zu betreiben. Das hilft auch hier, denn dann kann man leichter sehen, welche Anwendung wieviel Speicher verbraucht.

== htop ==
Ein hilfreicher Befehl ist <code>htop</code>:

{{Textkasten|gruen||xyz00-max@h01:~$ htop --user `whoami`}}

bzw.

{{Textkasten|gruen||xyz00-max@h01:~$ htop --user xyz00-max}}

Mit diesem Befehl werden für den aktuellen Benutzer xyz00-max die einzelnen Prozesse angezeigt. Leider ist aber der Speicherverbrauch im Hauptspeicher nicht so einfach zu erkennen.

== systemd status slice ==

Siehe auch [[RAM_Kontingent_eines_Webspace|Prozessmanagement_mit_systemd_im_Userspace#RAM_Kontingent_eines_Webspace]]

<syntaxhighlight lang="bash">
systemctl status pacs-xyz00.slice
</syntaxhighlight>

Da wird der RAM Verbrauch für den gesamten Webspace xyz00 angezeigt.

== Skript list-memory-usage ==
Unser Mitglied Timotheus Pokorra hat ein [https://codeberg.org/tpokorra/hostsharing-scripts/src/branch/main/list-memory-usage Skript in Python] geschrieben, das den Speicherverbrauch pro Benutzer und auch in einer Übersicht anzeigen kann.

Es wird heruntergeladen und für die Ausführung vorbereitet:

{{Textkasten|gruen||
xyz00@h01:~$ wget https://codeberg.org/tpokorra/hostsharing-scripts/raw/branch/main/list-memory-usage
xyz00@h01:~$ chmod a+x list-memory-usage}}

Nun gibt es folgende Optionen:

Zeigt alle Prozesse, nach Größe sortiert, inkl. des Users und dem Namen des Prozesses und der belegte Speicherplatz im Arbeitsspeicher. Darunter wird die Summe aller Prozesse pro User gelistet, nach Gesamtgröße sortiert:
{{Textkasten|gruen||xyz00@h01:~$ ./list-memory-usage}}

Zeige alle Prozesse eines bestimmten Benutzers, und die Summe des belegten Arbeitsspeichers:
{{Textkasten|gruen||xyz00@h01:~$ ./list-memory-usage --user xyz00-user }}

Zeige alle Prozesse eines bestimmten Programms, über alle Benutzer hinweg:
{{Textkasten|gruen||xyz00@h01:~$ ./list-memory-usage --name php }}

Normalerweise werden einige Prozesse und Benutzer ausgeblendet. Mit dieser Option werden alle Prozesse und Benutzer berücksichtigt:
{{Textkasten|gruen||xyz00@h01:~$ ./list-memory-usage --all}}

----
[[Kategorie:Pakete bei HS]]
[[Kategorie:HSDoku]]

.htaccess

2025-03-18T14:39:51Z

Tim: /* Passwortschutz abhängig vom REQUEST_URI */

Mit <code>.htaccess</code> Dateien innerhalb der Dokument-Verzeichnisse einer Domain (möglichst in ~/doms/example.com/.htaccess oder gezielt in Unterverzeichnissen subs/www ect. ), können Einstellungen des Apache Webservers konfiguriert werden.

Zum Beispiel kann angegeben werden, welches Apache-Modul für bestimmte Dateien (oder bestimmte Datei-Endungen) benutzt werden soll, wohin Dokumente verschoben worden sind, oder auch, wer Zugriff auf die Dateien hat.

== Einstellen von MIME-Typen ==

<syntaxhighlight lang=apache line>
# Download von Zertifikaten ermöglichen:
AddType application/x-x509-ca-cert .crt
</syntaxhighlight>

== Einstellen des im HTTP Header angegebenen Zeichensatzes ==

für .html Dateien:
<syntaxhighlight lang=apache line>
AddCharset UTF-8 .html

# oder
AddDefaultCharset UTF-8
</syntaxhighlight>

(für PHP Skripte siehe [[PHP]] )

== Einstellen von Datei Handlern ==

<syntaxhighlight lang=apache line>
AddType application/x-httpd-phpcgi .php
Action application/x-httpd-phpcgi /fastcgi-bin/phpstub
</syntaxhighlight>

==Passwortschutz für Dateien==

'''Achtung:''' Sofern der Zugriff http Zugriff auf die Dateien nicht automatisch auf https:// bzw. [[TLS_/_SSL|SSL]] umgeleitet wird, können die Passwörter unverschlüsselt übertragen werden!

Zunächst wollen wir den Zugriff auf ein Unterverzeichnis unserer Beispiel-Domain per .htaccess einschränken. Dazu legen wir zunächst eine Passwort-Datei an. Am einfachsten lässt sich diese spezielle Passwort-Datei in einer Shell anlegen. Wir legen sie in das etc-Verzeichnis der Domain:

<syntaxhighlight lang=bash>
xyz00-doms@hopi$ cd ~/doms/example.com/etc
xyz00-doms@hopi$ htpasswd -c .htpasswd peter
New password: *****
Re-type new password: *****
xyz00-doms@hopi$
</syntaxhighlight>

Beim ersten User, hier peter wird das Programm htpasswd mit der Option -c (create) aufgerufen, aber auch wirklich nur beim ersten mal, da sonst die Datei .htpasswd neu erzeugt werden würde und vorherige Einträge damit gelöscht wären.

Sollte es beim Versuch, die Datei anzulegen, zu der Fehlermeldung kommando htpasswd nicht bekannt kommen, dann müssen wir zunächst den Befehl lokalisieren und mit dem richtigen Pfad neu aufrufen:

<syntaxhighlight lang=bash>
xyz00-doms@hopi$ locate htpasswd
/usr/bin/htpasswd
xyz00-doms@hopi$ /usr/bin/htpasswd -c .htpasswd peter
</syntaxhighlight>

Beim zweiten User erfolgt der Aufruf dann ohne die Option -c:

<syntaxhighlight lang=bash>
xyz00-doms@hopi$ htpasswd .htpasswd petra
New password: *****
Re-type new password: *****
xyz00-doms@hopi$
</syntaxhighlight>

Die Sternchen * stehen selbstverständlich für das jeweilige Passwort, welches dem User zugeordnet werden soll.

Diese Datei könnten wir auch einfach mit scp/pscp oder FTP hochladen, dabei stellt sich dann jedoch die Frage, wie wir sie erzeugen. Auf den meisten Windows-Systemen dürfte kein htpasswd-Kommando verfügbar sein. Für diese Fälle gibt es eine online-Version z.b.: https://de.functions-online.com/crypt.html
die Ausgabe einfach mit Copy&Paste in eine Datei kopieren und diese hochladen.

Die so angelegte Passwort-Datei kann nun von einer oder mehreren .htaccess-Dateien verwendet werden. Dazu begeben wir uns in das zu schützende Verzeichnis und legen dort eine Datei .htaccess an. Dies kann wieder per Upload oder in einer Shell geschehen. Die Datei kann beispielsweise so aussehen:

<syntaxhighlight lang=apache line>
order allow,deny
allow from all
require valid-user
Authname "Privater Bereich, bitte Anmelden."
Authtype Basic
AuthUserFile /home/doms/example.com/etc/.htpasswd
</syntaxhighlight>

Dabei verweist die letzte Zeile auf die von uns angelegte .htpasswd Datei. Zu beachten ist:
* Das die Pfadangabe absolut erfolgt, um einen "Internal Server Error" zu vermeiden.
* Falls die Datei innerhalb des Dokumenten Verzeichnisses liegen muss, sie auf jeden Fall .htpasswd heißt, damit sie vom Webserver nicht herausgegeben wird.
* Die .htaccess Datei in den Paketdomains innerhalb des web/ bzw. web-ssl/ Verzeichnisses liegen muss, damit kein "Internal Server Error" auftritt.

===Passwortschutz von CGI- und PHP-Anwendungen===

Mit dem beschriebenen Mechanismus können selbstverständlich auch PHP-Skripte und CGI-Anwendungen vor unberechtigten Zugriffen geschützt werden. In dem geschützten Skript kann über die Umgebungsvariable <code>REDIRECT_REMOTE_USER</code> der Benutzername des Benutzers abgefragt werden, der sich angemeldet hat.

In PHP-Skripten kann mit Hilfe der automatisch global sichtbaren Variablen <code>$_ENV</code> auf die Umgebungsvariablen zugegriffen werden. Um die Variable <code>REDIRECT_REMOTE_USER</code> zu lesen, schreibt man also <code>$_ENV['REDIRECT_REMOTE_USER']</code>.

=== Passwortschutz abhängig vom REQUEST_URI ===

Falls ich für eine oder mehrere REQUEST_URI eine htpasswd Abfrage möchte, z.B. für Keycloak Admin Login:

<syntaxhighlight lang=apache line>
SetEnvIf REQUEST_URI ^/realms/master/.* HTTPAUTHPROTECT

Authname "Privater Bereich, bitte Anmelden."
Authtype Basic
AuthUserFile /home/doms/login.beispielverein.de/.htpasswd

Order Allow,Deny
Satisfy any
Require valid-user
Allow from all
Deny from env=HTTPAUTHPROTECT
</syntaxhighlight>

Anders herum würde es auch gehen: Wenn ich für eine oder mehrere REQUEST_URI keine htpasswd Abfrage möchte:

<syntaxhighlight lang=apache line>
SetEnvIf REQUEST_URI ^/public/.* NOPASSWD

Authname "Privater Bereich, bitte Anmelden."
Authtype Basic
AuthUserFile /home/doms/app.beispielverein.de/.htpasswd

Order Deny,Allow
Satisfy Any
Deny from all
Require valid-user
Allow from env=NOPASSWD
</syntaxhighlight>

Siehe auch [https://stackoverflow.com/a/11439361/1632368] für eine Erklärung.

== Redirects ==

<syntaxhighlight lang=apache line>
Redirect permanent / http://www.example.com/
</syntaxhighlight>

== Rewrite Rules ==

<syntaxhighlight lang=apache line>
RewriteEngine On
RewriteRule ^mailman/(.*)$ /cgi-bin/mailman/$1
</syntaxhighlight>

== Nur SSL erlauben und automatisch umschalten ==

Bei per Symlink zusammengeschalteten Verzeichnissen, kann dies für die Verzeichnisse auf die nur per SSL zugegriffen werden soll, wie folgt erreicht werden:

<syntaxhighlight lang=apache line>
# SSL so fordern, dass ggf. Basic Auth nur einmal innerhalb von SSL abgefragt wird.
#
#SSLOptions +StrictRequire #Bei HS festgelegt.
SSLRequireSSL
ErrorDocument 403 https://xyz00.hostsharing.net/https/URL/mit/entspechendem/Ziel/Verzeichnis
</syntaxhighlight>

In diesem Beispiel wird auf eine xyz00 Domain umgeleitet für die das HS Zertifikat gilt. Liegen die Seiten nicht dort ist die entprechende URL des Speicherortes mit https:// anzugegeben.

Bei separaten Verzeichnissen für ssl und nicht-ssl kann auch ein permanenter Redirekt gelegt werden.

Beispiel:
<syntaxhighlight lang=apache line>
Redirect permanent / https://www.example.org/
</syntaxhighlight>

Um alle http Requests nach https weiter zu leiten:

<syntaxhighlight lang=apache line>
RewriteEngine On
RewriteCond %{SERVER_PORT} !=443
RewriteRule .* https://%{HTTP_HOST}:443%{REQUEST_URI} [QSA,R=permanent,L]
</syntaxhighlight>

==Verzeichnislisting ausschalten==

Ruft ein Nutzer ein Verzeichnis auf, z.B. www.example.com/verzeichnis, so wird normalerweise die sich darin befindliche index.html als Standard aufgerufen. Gibt es diese Datei nicht, wird der Inhalt des Verzeichnisses gelistet. Das kann ein Sicherheitsproblem sein.

Die Einstellung
<syntaxhighlight lang=apache line>
IndexIgnore *
</syntaxhighlight>
sorgt dafür, dass alle Datein Unterhalb des Speicherortes der .htaccess Datei für das Verzeichnislisting ignoriert werden.

Hinweis: Das Listen der Verzeichnisse kann auch schon auf Dateisystemebene durch ändern der Verzeichnisrechte (o-r) unterbunden werden, wodurch auch lokale User berücksichtigt werden.

== Ausnahme die eigene IP-Adresse ==

Zum Testen willst du möglicherweise auf ein anderes Backend zugreifen, als es die normalen Webseiten-Besucherinnen tun. Du kannst die eigene IP-Adresse als "RewriteCond" verwenden:

<syntaxhighlight lang=apache line>
DirectoryIndex disabled
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteCond %{REMOTE_ADDR} !=62.27.244.230
RewriteRule ^(.*) ajp://hsh02.hostsharing.net:8009/$1 [proxy,last]

RewriteRule ^(.*) ajp://127.0.0.1:34380/$1 [proxy,last]
</syntaxhighlight>

== Bestimmte Clients blockieren ==

Jeder Web-Browser gibt sich mit einer Kennung zu erkennen. Auch Bots sollten sich mit einer bestimmten Kennung zu erkennen geben. Diese Kennung wird ersichtlich, wenn Du die web.log Datei durchsuchst (siehe [[Traffic]]). Damit ist es möglich, bestimmte Clients oder Bots auszuschließen.

Hier im Beispiel werden der SemrushBot, der MJ12bot, und der AI Bot Claude von Anthropic ausgeschlossen:

<syntaxhighlight lang=apache line>
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_USER_AGENT} ^.*SemrushBot.*$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^.*MJ12bot.*$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^.*ClaudeBot.*$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^$
RewriteRule ^.* - [F,L]
</syntaxhighlight>

Siehe auch https://stackoverflow.com/a/35775449/1632368

== Bestimmte Verzeichnisse nicht ausliefern ==

zum Beispiel das .git Verzeichnis sollte nicht gezeigt werden:

<syntaxhighlight lang=apache line>
RedirectMatch 404 /\.git
</syntaxhighlight>

Oder wenn Wordpress für alle URLs mit HTTP Code 200 die Startseite anzeigt, denken manche Angreifer, es läuft ein mailman.

<syntaxhighlight lang=apache line>
RedirectMatch 404 /mailman/
</syntaxhighlight>

== Gesperrte Optionen ==

Einstellungen, die es ermöglichen würden, über den Webserver Rechte anderer
User zu erhalten, sind nicht erlaubt.
--
[[Kategorie:HSDoku]]
[[Kategorie:WWW]]
[[Kategorie:Glossar]]

.htaccess

2025-03-18T11:25:13Z

Tim: /* Passwortschutz abhängig vom REQUEST_URI */

Mit <code>.htaccess</code> Dateien innerhalb der Dokument-Verzeichnisse einer Domain (möglichst in ~/doms/example.com/.htaccess oder gezielt in Unterverzeichnissen subs/www ect. ), können Einstellungen des Apache Webservers konfiguriert werden.

Zum Beispiel kann angegeben werden, welches Apache-Modul für bestimmte Dateien (oder bestimmte Datei-Endungen) benutzt werden soll, wohin Dokumente verschoben worden sind, oder auch, wer Zugriff auf die Dateien hat.

== Einstellen von MIME-Typen ==

<syntaxhighlight lang=apache line>
# Download von Zertifikaten ermöglichen:
AddType application/x-x509-ca-cert .crt
</syntaxhighlight>

== Einstellen des im HTTP Header angegebenen Zeichensatzes ==

für .html Dateien:
<syntaxhighlight lang=apache line>
AddCharset UTF-8 .html

# oder
AddDefaultCharset UTF-8
</syntaxhighlight>

(für PHP Skripte siehe [[PHP]] )

== Einstellen von Datei Handlern ==

<syntaxhighlight lang=apache line>
AddType application/x-httpd-phpcgi .php
Action application/x-httpd-phpcgi /fastcgi-bin/phpstub
</syntaxhighlight>

==Passwortschutz für Dateien==

'''Achtung:''' Sofern der Zugriff http Zugriff auf die Dateien nicht automatisch auf https:// bzw. [[TLS_/_SSL|SSL]] umgeleitet wird, können die Passwörter unverschlüsselt übertragen werden!

Zunächst wollen wir den Zugriff auf ein Unterverzeichnis unserer Beispiel-Domain per .htaccess einschränken. Dazu legen wir zunächst eine Passwort-Datei an. Am einfachsten lässt sich diese spezielle Passwort-Datei in einer Shell anlegen. Wir legen sie in das etc-Verzeichnis der Domain:

<syntaxhighlight lang=bash>
xyz00-doms@hopi$ cd ~/doms/example.com/etc
xyz00-doms@hopi$ htpasswd -c .htpasswd peter
New password: *****
Re-type new password: *****
xyz00-doms@hopi$
</syntaxhighlight>

Beim ersten User, hier peter wird das Programm htpasswd mit der Option -c (create) aufgerufen, aber auch wirklich nur beim ersten mal, da sonst die Datei .htpasswd neu erzeugt werden würde und vorherige Einträge damit gelöscht wären.

Sollte es beim Versuch, die Datei anzulegen, zu der Fehlermeldung kommando htpasswd nicht bekannt kommen, dann müssen wir zunächst den Befehl lokalisieren und mit dem richtigen Pfad neu aufrufen:

<syntaxhighlight lang=bash>
xyz00-doms@hopi$ locate htpasswd
/usr/bin/htpasswd
xyz00-doms@hopi$ /usr/bin/htpasswd -c .htpasswd peter
</syntaxhighlight>

Beim zweiten User erfolgt der Aufruf dann ohne die Option -c:

<syntaxhighlight lang=bash>
xyz00-doms@hopi$ htpasswd .htpasswd petra
New password: *****
Re-type new password: *****
xyz00-doms@hopi$
</syntaxhighlight>

Die Sternchen * stehen selbstverständlich für das jeweilige Passwort, welches dem User zugeordnet werden soll.

Diese Datei könnten wir auch einfach mit scp/pscp oder FTP hochladen, dabei stellt sich dann jedoch die Frage, wie wir sie erzeugen. Auf den meisten Windows-Systemen dürfte kein htpasswd-Kommando verfügbar sein. Für diese Fälle gibt es eine online-Version z.b.: https://de.functions-online.com/crypt.html
die Ausgabe einfach mit Copy&Paste in eine Datei kopieren und diese hochladen.

Die so angelegte Passwort-Datei kann nun von einer oder mehreren .htaccess-Dateien verwendet werden. Dazu begeben wir uns in das zu schützende Verzeichnis und legen dort eine Datei .htaccess an. Dies kann wieder per Upload oder in einer Shell geschehen. Die Datei kann beispielsweise so aussehen:

<syntaxhighlight lang=apache line>
order allow,deny
allow from all
require valid-user
Authname "Privater Bereich, bitte Anmelden."
Authtype Basic
AuthUserFile /home/doms/example.com/etc/.htpasswd
</syntaxhighlight>

Dabei verweist die letzte Zeile auf die von uns angelegte .htpasswd Datei. Zu beachten ist:
* Das die Pfadangabe absolut erfolgt, um einen "Internal Server Error" zu vermeiden.
* Falls die Datei innerhalb des Dokumenten Verzeichnisses liegen muss, sie auf jeden Fall .htpasswd heißt, damit sie vom Webserver nicht herausgegeben wird.
* Die .htaccess Datei in den Paketdomains innerhalb des web/ bzw. web-ssl/ Verzeichnisses liegen muss, damit kein "Internal Server Error" auftritt.

===Passwortschutz von CGI- und PHP-Anwendungen===

Mit dem beschriebenen Mechanismus können selbstverständlich auch PHP-Skripte und CGI-Anwendungen vor unberechtigten Zugriffen geschützt werden. In dem geschützten Skript kann über die Umgebungsvariable <code>REDIRECT_REMOTE_USER</code> der Benutzername des Benutzers abgefragt werden, der sich angemeldet hat.

In PHP-Skripten kann mit Hilfe der automatisch global sichtbaren Variablen <code>$_ENV</code> auf die Umgebungsvariablen zugegriffen werden. Um die Variable <code>REDIRECT_REMOTE_USER</code> zu lesen, schreibt man also <code>$_ENV['REDIRECT_REMOTE_USER']</code>.

=== Passwortschutz abhängig vom REQUEST_URI ===

Falls ich für eine oder mehrere REQUEST_URI eine htpasswd Abfrage möchte, z.B. für Keycloak Admin Login:

<syntaxhighlight lang=apache line>
SetEnvIf REQUEST_URI ^/realms/master/.* HTTPAUTHPROTECT
SetEnvIf REQUEST_URI ^/admin/.* HTTPAUTHPROTECT

Authname "Privater Bereich, bitte Anmelden."
Authtype Basic
AuthUserFile /home/doms/login.beispielverein.de/.htpasswd

Order Allow,Deny
Satisfy any
Require valid-user
Allow from all
Deny from env=HTTPAUTHPROTECT
</syntaxhighlight>

Anders herum würde es auch gehen: Wenn ich für eine oder mehrere REQUEST_URI keine htpasswd Abfrage möchte:

<syntaxhighlight lang=apache line>
SetEnvIf REQUEST_URI ^/public/.* NOPASSWD

Authname "Privater Bereich, bitte Anmelden."
Authtype Basic
AuthUserFile /home/doms/app.beispielverein.de/.htpasswd

Order Deny,Allow
Satisfy Any
Deny from all
Require valid-user
Allow from env=NOPASSWD
</syntaxhighlight>

Siehe auch [https://stackoverflow.com/a/11439361/1632368] für eine Erklärung.

== Redirects ==

<syntaxhighlight lang=apache line>
Redirect permanent / http://www.example.com/
</syntaxhighlight>

== Rewrite Rules ==

<syntaxhighlight lang=apache line>
RewriteEngine On
RewriteRule ^mailman/(.*)$ /cgi-bin/mailman/$1
</syntaxhighlight>

== Nur SSL erlauben und automatisch umschalten ==

Bei per Symlink zusammengeschalteten Verzeichnissen, kann dies für die Verzeichnisse auf die nur per SSL zugegriffen werden soll, wie folgt erreicht werden:

<syntaxhighlight lang=apache line>
# SSL so fordern, dass ggf. Basic Auth nur einmal innerhalb von SSL abgefragt wird.
#
#SSLOptions +StrictRequire #Bei HS festgelegt.
SSLRequireSSL
ErrorDocument 403 https://xyz00.hostsharing.net/https/URL/mit/entspechendem/Ziel/Verzeichnis
</syntaxhighlight>

In diesem Beispiel wird auf eine xyz00 Domain umgeleitet für die das HS Zertifikat gilt. Liegen die Seiten nicht dort ist die entprechende URL des Speicherortes mit https:// anzugegeben.

Bei separaten Verzeichnissen für ssl und nicht-ssl kann auch ein permanenter Redirekt gelegt werden.

Beispiel:
<syntaxhighlight lang=apache line>
Redirect permanent / https://www.example.org/
</syntaxhighlight>

Um alle http Requests nach https weiter zu leiten:

<syntaxhighlight lang=apache line>
RewriteEngine On
RewriteCond %{SERVER_PORT} !=443
RewriteRule .* https://%{HTTP_HOST}:443%{REQUEST_URI} [QSA,R=permanent,L]
</syntaxhighlight>

==Verzeichnislisting ausschalten==

Ruft ein Nutzer ein Verzeichnis auf, z.B. www.example.com/verzeichnis, so wird normalerweise die sich darin befindliche index.html als Standard aufgerufen. Gibt es diese Datei nicht, wird der Inhalt des Verzeichnisses gelistet. Das kann ein Sicherheitsproblem sein.

Die Einstellung
<syntaxhighlight lang=apache line>
IndexIgnore *
</syntaxhighlight>
sorgt dafür, dass alle Datein Unterhalb des Speicherortes der .htaccess Datei für das Verzeichnislisting ignoriert werden.

Hinweis: Das Listen der Verzeichnisse kann auch schon auf Dateisystemebene durch ändern der Verzeichnisrechte (o-r) unterbunden werden, wodurch auch lokale User berücksichtigt werden.

== Ausnahme die eigene IP-Adresse ==

Zum Testen willst du möglicherweise auf ein anderes Backend zugreifen, als es die normalen Webseiten-Besucherinnen tun. Du kannst die eigene IP-Adresse als "RewriteCond" verwenden:

<syntaxhighlight lang=apache line>
DirectoryIndex disabled
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteCond %{REMOTE_ADDR} !=62.27.244.230
RewriteRule ^(.*) ajp://hsh02.hostsharing.net:8009/$1 [proxy,last]

RewriteRule ^(.*) ajp://127.0.0.1:34380/$1 [proxy,last]
</syntaxhighlight>

== Bestimmte Clients blockieren ==

Jeder Web-Browser gibt sich mit einer Kennung zu erkennen. Auch Bots sollten sich mit einer bestimmten Kennung zu erkennen geben. Diese Kennung wird ersichtlich, wenn Du die web.log Datei durchsuchst (siehe [[Traffic]]). Damit ist es möglich, bestimmte Clients oder Bots auszuschließen.

Hier im Beispiel werden der SemrushBot, der MJ12bot, und der AI Bot Claude von Anthropic ausgeschlossen:

<syntaxhighlight lang=apache line>
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_USER_AGENT} ^.*SemrushBot.*$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^.*MJ12bot.*$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^.*ClaudeBot.*$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^$
RewriteRule ^.* - [F,L]
</syntaxhighlight>

Siehe auch https://stackoverflow.com/a/35775449/1632368

== Bestimmte Verzeichnisse nicht ausliefern ==

zum Beispiel das .git Verzeichnis sollte nicht gezeigt werden:

<syntaxhighlight lang=apache line>
RedirectMatch 404 /\.git
</syntaxhighlight>

Oder wenn Wordpress für alle URLs mit HTTP Code 200 die Startseite anzeigt, denken manche Angreifer, es läuft ein mailman.

<syntaxhighlight lang=apache line>
RedirectMatch 404 /mailman/
</syntaxhighlight>

== Gesperrte Optionen ==

Einstellungen, die es ermöglichen würden, über den Webserver Rechte anderer
User zu erhalten, sind nicht erlaubt.
--
[[Kategorie:HSDoku]]
[[Kategorie:WWW]]
[[Kategorie:Glossar]]

.htaccess

2025-03-18T11:24:18Z

Tim: /* Passwortschutz abhängig vom REQUEST_URI */

Mit <code>.htaccess</code> Dateien innerhalb der Dokument-Verzeichnisse einer Domain (möglichst in ~/doms/example.com/.htaccess oder gezielt in Unterverzeichnissen subs/www ect. ), können Einstellungen des Apache Webservers konfiguriert werden.

Zum Beispiel kann angegeben werden, welches Apache-Modul für bestimmte Dateien (oder bestimmte Datei-Endungen) benutzt werden soll, wohin Dokumente verschoben worden sind, oder auch, wer Zugriff auf die Dateien hat.

== Einstellen von MIME-Typen ==

<syntaxhighlight lang=apache line>
# Download von Zertifikaten ermöglichen:
AddType application/x-x509-ca-cert .crt
</syntaxhighlight>

== Einstellen des im HTTP Header angegebenen Zeichensatzes ==

für .html Dateien:
<syntaxhighlight lang=apache line>
AddCharset UTF-8 .html

# oder
AddDefaultCharset UTF-8
</syntaxhighlight>

(für PHP Skripte siehe [[PHP]] )

== Einstellen von Datei Handlern ==

<syntaxhighlight lang=apache line>
AddType application/x-httpd-phpcgi .php
Action application/x-httpd-phpcgi /fastcgi-bin/phpstub
</syntaxhighlight>

==Passwortschutz für Dateien==

'''Achtung:''' Sofern der Zugriff http Zugriff auf die Dateien nicht automatisch auf https:// bzw. [[TLS_/_SSL|SSL]] umgeleitet wird, können die Passwörter unverschlüsselt übertragen werden!

Zunächst wollen wir den Zugriff auf ein Unterverzeichnis unserer Beispiel-Domain per .htaccess einschränken. Dazu legen wir zunächst eine Passwort-Datei an. Am einfachsten lässt sich diese spezielle Passwort-Datei in einer Shell anlegen. Wir legen sie in das etc-Verzeichnis der Domain:

<syntaxhighlight lang=bash>
xyz00-doms@hopi$ cd ~/doms/example.com/etc
xyz00-doms@hopi$ htpasswd -c .htpasswd peter
New password: *****
Re-type new password: *****
xyz00-doms@hopi$
</syntaxhighlight>

Beim ersten User, hier peter wird das Programm htpasswd mit der Option -c (create) aufgerufen, aber auch wirklich nur beim ersten mal, da sonst die Datei .htpasswd neu erzeugt werden würde und vorherige Einträge damit gelöscht wären.

Sollte es beim Versuch, die Datei anzulegen, zu der Fehlermeldung kommando htpasswd nicht bekannt kommen, dann müssen wir zunächst den Befehl lokalisieren und mit dem richtigen Pfad neu aufrufen:

<syntaxhighlight lang=bash>
xyz00-doms@hopi$ locate htpasswd
/usr/bin/htpasswd
xyz00-doms@hopi$ /usr/bin/htpasswd -c .htpasswd peter
</syntaxhighlight>

Beim zweiten User erfolgt der Aufruf dann ohne die Option -c:

<syntaxhighlight lang=bash>
xyz00-doms@hopi$ htpasswd .htpasswd petra
New password: *****
Re-type new password: *****
xyz00-doms@hopi$
</syntaxhighlight>

Die Sternchen * stehen selbstverständlich für das jeweilige Passwort, welches dem User zugeordnet werden soll.

Diese Datei könnten wir auch einfach mit scp/pscp oder FTP hochladen, dabei stellt sich dann jedoch die Frage, wie wir sie erzeugen. Auf den meisten Windows-Systemen dürfte kein htpasswd-Kommando verfügbar sein. Für diese Fälle gibt es eine online-Version z.b.: https://de.functions-online.com/crypt.html
die Ausgabe einfach mit Copy&Paste in eine Datei kopieren und diese hochladen.

Die so angelegte Passwort-Datei kann nun von einer oder mehreren .htaccess-Dateien verwendet werden. Dazu begeben wir uns in das zu schützende Verzeichnis und legen dort eine Datei .htaccess an. Dies kann wieder per Upload oder in einer Shell geschehen. Die Datei kann beispielsweise so aussehen:

<syntaxhighlight lang=apache line>
order allow,deny
allow from all
require valid-user
Authname "Privater Bereich, bitte Anmelden."
Authtype Basic
AuthUserFile /home/doms/example.com/etc/.htpasswd
</syntaxhighlight>

Dabei verweist die letzte Zeile auf die von uns angelegte .htpasswd Datei. Zu beachten ist:
* Das die Pfadangabe absolut erfolgt, um einen "Internal Server Error" zu vermeiden.
* Falls die Datei innerhalb des Dokumenten Verzeichnisses liegen muss, sie auf jeden Fall .htpasswd heißt, damit sie vom Webserver nicht herausgegeben wird.
* Die .htaccess Datei in den Paketdomains innerhalb des web/ bzw. web-ssl/ Verzeichnisses liegen muss, damit kein "Internal Server Error" auftritt.

===Passwortschutz von CGI- und PHP-Anwendungen===

Mit dem beschriebenen Mechanismus können selbstverständlich auch PHP-Skripte und CGI-Anwendungen vor unberechtigten Zugriffen geschützt werden. In dem geschützten Skript kann über die Umgebungsvariable <code>REDIRECT_REMOTE_USER</code> der Benutzername des Benutzers abgefragt werden, der sich angemeldet hat.

In PHP-Skripten kann mit Hilfe der automatisch global sichtbaren Variablen <code>$_ENV</code> auf die Umgebungsvariablen zugegriffen werden. Um die Variable <code>REDIRECT_REMOTE_USER</code> zu lesen, schreibt man also <code>$_ENV['REDIRECT_REMOTE_USER']</code>.

=== Passwortschutz abhängig vom REQUEST_URI ===

Falls ich für eine oder mehrere REQUEST_URI eine htpasswd Abfrage möchte, z.B. für Keycloak Admin Login:

<syntaxhighlight lang=apache line>
SetEnvIf REQUEST_URI ^/realms/master/.* HTTPAUTHPROTECT
SetEnvIf REQUEST_URI ^/admin/.* HTTPAUTHPROTECT

Authname "Privater Bereich, bitte Anmelden."
Authtype Basic
AuthUserFile /home/doms/login.beispielverein.de/.htpasswd

Order Allow,Deny
Satisfy any
Require valid-user
Allow from all
Deny from env=HTTPAUTHPROTECT
</syntaxhighlight>

Anders herum würde es auch gehen: Wenn ich für eine oder mehrere REQUEST_URI keine htpasswd Abfrage möchte:

<syntaxhighlight lang=apache line>
SetEnvIf REQUEST_URI ^/public/.* NOPASSWD

Authname "Privater Bereich, bitte Anmelden."
Authtype Basic
AuthUserFile /home/doms/login.beispielverein.de/.htpasswd

Order Deny,Allow
Satisfy Any
Deny from all
Require valid-user
Allow from env=NOPASSWD
</syntaxhighlight>

Siehe auch [https://stackoverflow.com/a/11439361/1632368] für eine Erklärung.

== Redirects ==

<syntaxhighlight lang=apache line>
Redirect permanent / http://www.example.com/
</syntaxhighlight>

== Rewrite Rules ==

<syntaxhighlight lang=apache line>
RewriteEngine On
RewriteRule ^mailman/(.*)$ /cgi-bin/mailman/$1
</syntaxhighlight>

== Nur SSL erlauben und automatisch umschalten ==

Bei per Symlink zusammengeschalteten Verzeichnissen, kann dies für die Verzeichnisse auf die nur per SSL zugegriffen werden soll, wie folgt erreicht werden:

<syntaxhighlight lang=apache line>
# SSL so fordern, dass ggf. Basic Auth nur einmal innerhalb von SSL abgefragt wird.
#
#SSLOptions +StrictRequire #Bei HS festgelegt.
SSLRequireSSL
ErrorDocument 403 https://xyz00.hostsharing.net/https/URL/mit/entspechendem/Ziel/Verzeichnis
</syntaxhighlight>

In diesem Beispiel wird auf eine xyz00 Domain umgeleitet für die das HS Zertifikat gilt. Liegen die Seiten nicht dort ist die entprechende URL des Speicherortes mit https:// anzugegeben.

Bei separaten Verzeichnissen für ssl und nicht-ssl kann auch ein permanenter Redirekt gelegt werden.

Beispiel:
<syntaxhighlight lang=apache line>
Redirect permanent / https://www.example.org/
</syntaxhighlight>

Um alle http Requests nach https weiter zu leiten:

<syntaxhighlight lang=apache line>
RewriteEngine On
RewriteCond %{SERVER_PORT} !=443
RewriteRule .* https://%{HTTP_HOST}:443%{REQUEST_URI} [QSA,R=permanent,L]
</syntaxhighlight>

==Verzeichnislisting ausschalten==

Ruft ein Nutzer ein Verzeichnis auf, z.B. www.example.com/verzeichnis, so wird normalerweise die sich darin befindliche index.html als Standard aufgerufen. Gibt es diese Datei nicht, wird der Inhalt des Verzeichnisses gelistet. Das kann ein Sicherheitsproblem sein.

Die Einstellung
<syntaxhighlight lang=apache line>
IndexIgnore *
</syntaxhighlight>
sorgt dafür, dass alle Datein Unterhalb des Speicherortes der .htaccess Datei für das Verzeichnislisting ignoriert werden.

Hinweis: Das Listen der Verzeichnisse kann auch schon auf Dateisystemebene durch ändern der Verzeichnisrechte (o-r) unterbunden werden, wodurch auch lokale User berücksichtigt werden.

== Ausnahme die eigene IP-Adresse ==

Zum Testen willst du möglicherweise auf ein anderes Backend zugreifen, als es die normalen Webseiten-Besucherinnen tun. Du kannst die eigene IP-Adresse als "RewriteCond" verwenden:

<syntaxhighlight lang=apache line>
DirectoryIndex disabled
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteCond %{REMOTE_ADDR} !=62.27.244.230
RewriteRule ^(.*) ajp://hsh02.hostsharing.net:8009/$1 [proxy,last]

RewriteRule ^(.*) ajp://127.0.0.1:34380/$1 [proxy,last]
</syntaxhighlight>

== Bestimmte Clients blockieren ==

Jeder Web-Browser gibt sich mit einer Kennung zu erkennen. Auch Bots sollten sich mit einer bestimmten Kennung zu erkennen geben. Diese Kennung wird ersichtlich, wenn Du die web.log Datei durchsuchst (siehe [[Traffic]]). Damit ist es möglich, bestimmte Clients oder Bots auszuschließen.

Hier im Beispiel werden der SemrushBot, der MJ12bot, und der AI Bot Claude von Anthropic ausgeschlossen:

<syntaxhighlight lang=apache line>
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_USER_AGENT} ^.*SemrushBot.*$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^.*MJ12bot.*$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^.*ClaudeBot.*$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^$
RewriteRule ^.* - [F,L]
</syntaxhighlight>

Siehe auch https://stackoverflow.com/a/35775449/1632368

== Bestimmte Verzeichnisse nicht ausliefern ==

zum Beispiel das .git Verzeichnis sollte nicht gezeigt werden:

<syntaxhighlight lang=apache line>
RedirectMatch 404 /\.git
</syntaxhighlight>

Oder wenn Wordpress für alle URLs mit HTTP Code 200 die Startseite anzeigt, denken manche Angreifer, es läuft ein mailman.

<syntaxhighlight lang=apache line>
RedirectMatch 404 /mailman/
</syntaxhighlight>

== Gesperrte Optionen ==

Einstellungen, die es ermöglichen würden, über den Webserver Rechte anderer
User zu erhalten, sind nicht erlaubt.
--
[[Kategorie:HSDoku]]
[[Kategorie:WWW]]
[[Kategorie:Glossar]]

.htaccess

2025-03-18T11:24:04Z

Tim: /* Passwortschutz von CGI- und PHP-Anwendungen */

Mit <code>.htaccess</code> Dateien innerhalb der Dokument-Verzeichnisse einer Domain (möglichst in ~/doms/example.com/.htaccess oder gezielt in Unterverzeichnissen subs/www ect. ), können Einstellungen des Apache Webservers konfiguriert werden.

Zum Beispiel kann angegeben werden, welches Apache-Modul für bestimmte Dateien (oder bestimmte Datei-Endungen) benutzt werden soll, wohin Dokumente verschoben worden sind, oder auch, wer Zugriff auf die Dateien hat.

== Einstellen von MIME-Typen ==

<syntaxhighlight lang=apache line>
# Download von Zertifikaten ermöglichen:
AddType application/x-x509-ca-cert .crt
</syntaxhighlight>

== Einstellen des im HTTP Header angegebenen Zeichensatzes ==

für .html Dateien:
<syntaxhighlight lang=apache line>
AddCharset UTF-8 .html

# oder
AddDefaultCharset UTF-8
</syntaxhighlight>

(für PHP Skripte siehe [[PHP]] )

== Einstellen von Datei Handlern ==

<syntaxhighlight lang=apache line>
AddType application/x-httpd-phpcgi .php
Action application/x-httpd-phpcgi /fastcgi-bin/phpstub
</syntaxhighlight>

==Passwortschutz für Dateien==

'''Achtung:''' Sofern der Zugriff http Zugriff auf die Dateien nicht automatisch auf https:// bzw. [[TLS_/_SSL|SSL]] umgeleitet wird, können die Passwörter unverschlüsselt übertragen werden!

Zunächst wollen wir den Zugriff auf ein Unterverzeichnis unserer Beispiel-Domain per .htaccess einschränken. Dazu legen wir zunächst eine Passwort-Datei an. Am einfachsten lässt sich diese spezielle Passwort-Datei in einer Shell anlegen. Wir legen sie in das etc-Verzeichnis der Domain:

<syntaxhighlight lang=bash>
xyz00-doms@hopi$ cd ~/doms/example.com/etc
xyz00-doms@hopi$ htpasswd -c .htpasswd peter
New password: *****
Re-type new password: *****
xyz00-doms@hopi$
</syntaxhighlight>

Beim ersten User, hier peter wird das Programm htpasswd mit der Option -c (create) aufgerufen, aber auch wirklich nur beim ersten mal, da sonst die Datei .htpasswd neu erzeugt werden würde und vorherige Einträge damit gelöscht wären.

Sollte es beim Versuch, die Datei anzulegen, zu der Fehlermeldung kommando htpasswd nicht bekannt kommen, dann müssen wir zunächst den Befehl lokalisieren und mit dem richtigen Pfad neu aufrufen:

<syntaxhighlight lang=bash>
xyz00-doms@hopi$ locate htpasswd
/usr/bin/htpasswd
xyz00-doms@hopi$ /usr/bin/htpasswd -c .htpasswd peter
</syntaxhighlight>

Beim zweiten User erfolgt der Aufruf dann ohne die Option -c:

<syntaxhighlight lang=bash>
xyz00-doms@hopi$ htpasswd .htpasswd petra
New password: *****
Re-type new password: *****
xyz00-doms@hopi$
</syntaxhighlight>

Die Sternchen * stehen selbstverständlich für das jeweilige Passwort, welches dem User zugeordnet werden soll.

Diese Datei könnten wir auch einfach mit scp/pscp oder FTP hochladen, dabei stellt sich dann jedoch die Frage, wie wir sie erzeugen. Auf den meisten Windows-Systemen dürfte kein htpasswd-Kommando verfügbar sein. Für diese Fälle gibt es eine online-Version z.b.: https://de.functions-online.com/crypt.html
die Ausgabe einfach mit Copy&Paste in eine Datei kopieren und diese hochladen.

Die so angelegte Passwort-Datei kann nun von einer oder mehreren .htaccess-Dateien verwendet werden. Dazu begeben wir uns in das zu schützende Verzeichnis und legen dort eine Datei .htaccess an. Dies kann wieder per Upload oder in einer Shell geschehen. Die Datei kann beispielsweise so aussehen:

<syntaxhighlight lang=apache line>
order allow,deny
allow from all
require valid-user
Authname "Privater Bereich, bitte Anmelden."
Authtype Basic
AuthUserFile /home/doms/example.com/etc/.htpasswd
</syntaxhighlight>

Dabei verweist die letzte Zeile auf die von uns angelegte .htpasswd Datei. Zu beachten ist:
* Das die Pfadangabe absolut erfolgt, um einen "Internal Server Error" zu vermeiden.
* Falls die Datei innerhalb des Dokumenten Verzeichnisses liegen muss, sie auf jeden Fall .htpasswd heißt, damit sie vom Webserver nicht herausgegeben wird.
* Die .htaccess Datei in den Paketdomains innerhalb des web/ bzw. web-ssl/ Verzeichnisses liegen muss, damit kein "Internal Server Error" auftritt.

===Passwortschutz von CGI- und PHP-Anwendungen===

Mit dem beschriebenen Mechanismus können selbstverständlich auch PHP-Skripte und CGI-Anwendungen vor unberechtigten Zugriffen geschützt werden. In dem geschützten Skript kann über die Umgebungsvariable <code>REDIRECT_REMOTE_USER</code> der Benutzername des Benutzers abgefragt werden, der sich angemeldet hat.

In PHP-Skripten kann mit Hilfe der automatisch global sichtbaren Variablen <code>$_ENV</code> auf die Umgebungsvariablen zugegriffen werden. Um die Variable <code>REDIRECT_REMOTE_USER</code> zu lesen, schreibt man also <code>$_ENV['REDIRECT_REMOTE_USER']</code>.

=== Passwortschutz abhängig vom REQUEST_URI ===

Falls ich für eine oder mehrere REQUEST_URI eine htpasswd Abfrage möchte, z.B. für Keycloak Admin Login:

<syntaxhighlight lang=apache line>
SetEnvIf REQUEST_URI ^/realms/master/.* HTTPAUTHPROTECT
SetEnvIf REQUEST_URI ^/admin/.* HTTPAUTHPROTECT

Authname "Privater Bereich, bitte Anmelden."
Authtype Basic
AuthUserFile /home/doms/login.beispielverein.de/.htpasswd

Order Allow,Deny
Satisfy any
Require valid-user
Allow from all
Deny from env=HTTPAUTHPROTECT
</syntaxhighlight

Anders herum würde es auch gehen: Wenn ich für eine oder mehrere REQUEST_URI keine htpasswd Abfrage möchte:

<syntaxhighlight lang=apache line>
SetEnvIf REQUEST_URI ^/public/.* NOPASSWD

Authname "Privater Bereich, bitte Anmelden."
Authtype Basic
AuthUserFile /home/doms/login.beispielverein.de/.htpasswd

Order Deny,Allow
Satisfy Any
Deny from all
Require valid-user
Allow from env=NOPASSWD
</syntaxhighlight

Siehe auch [https://stackoverflow.com/a/11439361/1632368] für eine Erklärung.

== Redirects ==

<syntaxhighlight lang=apache line>
Redirect permanent / http://www.example.com/
</syntaxhighlight>

== Rewrite Rules ==

<syntaxhighlight lang=apache line>
RewriteEngine On
RewriteRule ^mailman/(.*)$ /cgi-bin/mailman/$1
</syntaxhighlight>

== Nur SSL erlauben und automatisch umschalten ==

Bei per Symlink zusammengeschalteten Verzeichnissen, kann dies für die Verzeichnisse auf die nur per SSL zugegriffen werden soll, wie folgt erreicht werden:

<syntaxhighlight lang=apache line>
# SSL so fordern, dass ggf. Basic Auth nur einmal innerhalb von SSL abgefragt wird.
#
#SSLOptions +StrictRequire #Bei HS festgelegt.
SSLRequireSSL
ErrorDocument 403 https://xyz00.hostsharing.net/https/URL/mit/entspechendem/Ziel/Verzeichnis
</syntaxhighlight>

In diesem Beispiel wird auf eine xyz00 Domain umgeleitet für die das HS Zertifikat gilt. Liegen die Seiten nicht dort ist die entprechende URL des Speicherortes mit https:// anzugegeben.

Bei separaten Verzeichnissen für ssl und nicht-ssl kann auch ein permanenter Redirekt gelegt werden.

Beispiel:
<syntaxhighlight lang=apache line>
Redirect permanent / https://www.example.org/
</syntaxhighlight>

Um alle http Requests nach https weiter zu leiten:

<syntaxhighlight lang=apache line>
RewriteEngine On
RewriteCond %{SERVER_PORT} !=443
RewriteRule .* https://%{HTTP_HOST}:443%{REQUEST_URI} [QSA,R=permanent,L]
</syntaxhighlight>

==Verzeichnislisting ausschalten==

Ruft ein Nutzer ein Verzeichnis auf, z.B. www.example.com/verzeichnis, so wird normalerweise die sich darin befindliche index.html als Standard aufgerufen. Gibt es diese Datei nicht, wird der Inhalt des Verzeichnisses gelistet. Das kann ein Sicherheitsproblem sein.

Die Einstellung
<syntaxhighlight lang=apache line>
IndexIgnore *
</syntaxhighlight>
sorgt dafür, dass alle Datein Unterhalb des Speicherortes der .htaccess Datei für das Verzeichnislisting ignoriert werden.

Hinweis: Das Listen der Verzeichnisse kann auch schon auf Dateisystemebene durch ändern der Verzeichnisrechte (o-r) unterbunden werden, wodurch auch lokale User berücksichtigt werden.

== Ausnahme die eigene IP-Adresse ==

Zum Testen willst du möglicherweise auf ein anderes Backend zugreifen, als es die normalen Webseiten-Besucherinnen tun. Du kannst die eigene IP-Adresse als "RewriteCond" verwenden:

<syntaxhighlight lang=apache line>
DirectoryIndex disabled
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteCond %{REMOTE_ADDR} !=62.27.244.230
RewriteRule ^(.*) ajp://hsh02.hostsharing.net:8009/$1 [proxy,last]

RewriteRule ^(.*) ajp://127.0.0.1:34380/$1 [proxy,last]
</syntaxhighlight>

== Bestimmte Clients blockieren ==

Jeder Web-Browser gibt sich mit einer Kennung zu erkennen. Auch Bots sollten sich mit einer bestimmten Kennung zu erkennen geben. Diese Kennung wird ersichtlich, wenn Du die web.log Datei durchsuchst (siehe [[Traffic]]). Damit ist es möglich, bestimmte Clients oder Bots auszuschließen.

Hier im Beispiel werden der SemrushBot, der MJ12bot, und der AI Bot Claude von Anthropic ausgeschlossen:

<syntaxhighlight lang=apache line>
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_USER_AGENT} ^.*SemrushBot.*$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^.*MJ12bot.*$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^.*ClaudeBot.*$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^$
RewriteRule ^.* - [F,L]
</syntaxhighlight>

Siehe auch https://stackoverflow.com/a/35775449/1632368

== Bestimmte Verzeichnisse nicht ausliefern ==

zum Beispiel das .git Verzeichnis sollte nicht gezeigt werden:

<syntaxhighlight lang=apache line>
RedirectMatch 404 /\.git
</syntaxhighlight>

Oder wenn Wordpress für alle URLs mit HTTP Code 200 die Startseite anzeigt, denken manche Angreifer, es läuft ein mailman.

<syntaxhighlight lang=apache line>
RedirectMatch 404 /mailman/
</syntaxhighlight>

== Gesperrte Optionen ==

Einstellungen, die es ermöglichen würden, über den Webserver Rechte anderer
User zu erhalten, sind nicht erlaubt.
--
[[Kategorie:HSDoku]]
[[Kategorie:WWW]]
[[Kategorie:Glossar]]

.htaccess

2025-03-18T07:24:07Z

Tim: /* Passwortschutz für Dateien */

Mit <code>.htaccess</code> Dateien innerhalb der Dokument-Verzeichnisse einer Domain (möglichst in ~/doms/example.com/.htaccess oder gezielt in Unterverzeichnissen subs/www ect. ), können Einstellungen des Apache Webservers konfiguriert werden.

Zum Beispiel kann angegeben werden, welches Apache-Modul für bestimmte Dateien (oder bestimmte Datei-Endungen) benutzt werden soll, wohin Dokumente verschoben worden sind, oder auch, wer Zugriff auf die Dateien hat.

== Einstellen von MIME-Typen ==

<syntaxhighlight lang=apache line>
# Download von Zertifikaten ermöglichen:
AddType application/x-x509-ca-cert .crt
</syntaxhighlight>

== Einstellen des im HTTP Header angegebenen Zeichensatzes ==

für .html Dateien:
<syntaxhighlight lang=apache line>
AddCharset UTF-8 .html

# oder
AddDefaultCharset UTF-8
</syntaxhighlight>

(für PHP Skripte siehe [[PHP]] )

== Einstellen von Datei Handlern ==

<syntaxhighlight lang=apache line>
AddType application/x-httpd-phpcgi .php
Action application/x-httpd-phpcgi /fastcgi-bin/phpstub
</syntaxhighlight>

==Passwortschutz für Dateien==

'''Achtung:''' Sofern der Zugriff http Zugriff auf die Dateien nicht automatisch auf https:// bzw. [[TLS_/_SSL|SSL]] umgeleitet wird, können die Passwörter unverschlüsselt übertragen werden!

Zunächst wollen wir den Zugriff auf ein Unterverzeichnis unserer Beispiel-Domain per .htaccess einschränken. Dazu legen wir zunächst eine Passwort-Datei an. Am einfachsten lässt sich diese spezielle Passwort-Datei in einer Shell anlegen. Wir legen sie in das etc-Verzeichnis der Domain:

<syntaxhighlight lang=bash>
xyz00-doms@hopi$ cd ~/doms/example.com/etc
xyz00-doms@hopi$ htpasswd -c .htpasswd peter
New password: *****
Re-type new password: *****
xyz00-doms@hopi$
</syntaxhighlight>

Beim ersten User, hier peter wird das Programm htpasswd mit der Option -c (create) aufgerufen, aber auch wirklich nur beim ersten mal, da sonst die Datei .htpasswd neu erzeugt werden würde und vorherige Einträge damit gelöscht wären.

Sollte es beim Versuch, die Datei anzulegen, zu der Fehlermeldung kommando htpasswd nicht bekannt kommen, dann müssen wir zunächst den Befehl lokalisieren und mit dem richtigen Pfad neu aufrufen:

<syntaxhighlight lang=bash>
xyz00-doms@hopi$ locate htpasswd
/usr/bin/htpasswd
xyz00-doms@hopi$ /usr/bin/htpasswd -c .htpasswd peter
</syntaxhighlight>

Beim zweiten User erfolgt der Aufruf dann ohne die Option -c:

<syntaxhighlight lang=bash>
xyz00-doms@hopi$ htpasswd .htpasswd petra
New password: *****
Re-type new password: *****
xyz00-doms@hopi$
</syntaxhighlight>

Die Sternchen * stehen selbstverständlich für das jeweilige Passwort, welches dem User zugeordnet werden soll.

Diese Datei könnten wir auch einfach mit scp/pscp oder FTP hochladen, dabei stellt sich dann jedoch die Frage, wie wir sie erzeugen. Auf den meisten Windows-Systemen dürfte kein htpasswd-Kommando verfügbar sein. Für diese Fälle gibt es eine online-Version z.b.: https://de.functions-online.com/crypt.html
die Ausgabe einfach mit Copy&Paste in eine Datei kopieren und diese hochladen.

Die so angelegte Passwort-Datei kann nun von einer oder mehreren .htaccess-Dateien verwendet werden. Dazu begeben wir uns in das zu schützende Verzeichnis und legen dort eine Datei .htaccess an. Dies kann wieder per Upload oder in einer Shell geschehen. Die Datei kann beispielsweise so aussehen:

<syntaxhighlight lang=apache line>
order allow,deny
allow from all
require valid-user
Authname "Privater Bereich, bitte Anmelden."
Authtype Basic
AuthUserFile /home/doms/example.com/etc/.htpasswd
</syntaxhighlight>

Dabei verweist die letzte Zeile auf die von uns angelegte .htpasswd Datei. Zu beachten ist:
* Das die Pfadangabe absolut erfolgt, um einen "Internal Server Error" zu vermeiden.
* Falls die Datei innerhalb des Dokumenten Verzeichnisses liegen muss, sie auf jeden Fall .htpasswd heißt, damit sie vom Webserver nicht herausgegeben wird.
* Die .htaccess Datei in den Paketdomains innerhalb des web/ bzw. web-ssl/ Verzeichnisses liegen muss, damit kein "Internal Server Error" auftritt.

===Passwortschutz von CGI- und PHP-Anwendungen===

Mit dem beschriebenen Mechanismus können selbstverständlich auch PHP-Skripte und CGI-Anwendungen vor unberechtigten Zugriffen geschützt werden. In dem geschützten Skript kann über die Umgebungsvariable <code>REDIRECT_REMOTE_USER</code> der Benutzername des Benutzers abgefragt werden, der sich angemeldet hat.

In PHP-Skripten kann mit Hilfe der automatisch global sichtbaren Variablen <code>$_ENV</code> auf die Umgebungsvariablen zugegriffen werden. Um die Variable <code>REDIRECT_REMOTE_USER</code> zu lesen, schreibt man also <code>$_ENV['REDIRECT_REMOTE_USER']</code>.

== Redirects ==

<syntaxhighlight lang=apache line>
Redirect permanent / http://www.example.com/
</syntaxhighlight>

== Rewrite Rules ==

<syntaxhighlight lang=apache line>
RewriteEngine On
RewriteRule ^mailman/(.*)$ /cgi-bin/mailman/$1
</syntaxhighlight>

== Nur SSL erlauben und automatisch umschalten ==

Bei per Symlink zusammengeschalteten Verzeichnissen, kann dies für die Verzeichnisse auf die nur per SSL zugegriffen werden soll, wie folgt erreicht werden:

<syntaxhighlight lang=apache line>
# SSL so fordern, dass ggf. Basic Auth nur einmal innerhalb von SSL abgefragt wird.
#
#SSLOptions +StrictRequire #Bei HS festgelegt.
SSLRequireSSL
ErrorDocument 403 https://xyz00.hostsharing.net/https/URL/mit/entspechendem/Ziel/Verzeichnis
</syntaxhighlight>

In diesem Beispiel wird auf eine xyz00 Domain umgeleitet für die das HS Zertifikat gilt. Liegen die Seiten nicht dort ist die entprechende URL des Speicherortes mit https:// anzugegeben.

Bei separaten Verzeichnissen für ssl und nicht-ssl kann auch ein permanenter Redirekt gelegt werden.

Beispiel:
<syntaxhighlight lang=apache line>
Redirect permanent / https://www.example.org/
</syntaxhighlight>

Um alle http Requests nach https weiter zu leiten:

<syntaxhighlight lang=apache line>
RewriteEngine On
RewriteCond %{SERVER_PORT} !=443
RewriteRule .* https://%{HTTP_HOST}:443%{REQUEST_URI} [QSA,R=permanent,L]
</syntaxhighlight>

==Verzeichnislisting ausschalten==

Ruft ein Nutzer ein Verzeichnis auf, z.B. www.example.com/verzeichnis, so wird normalerweise die sich darin befindliche index.html als Standard aufgerufen. Gibt es diese Datei nicht, wird der Inhalt des Verzeichnisses gelistet. Das kann ein Sicherheitsproblem sein.

Die Einstellung
<syntaxhighlight lang=apache line>
IndexIgnore *
</syntaxhighlight>
sorgt dafür, dass alle Datein Unterhalb des Speicherortes der .htaccess Datei für das Verzeichnislisting ignoriert werden.

Hinweis: Das Listen der Verzeichnisse kann auch schon auf Dateisystemebene durch ändern der Verzeichnisrechte (o-r) unterbunden werden, wodurch auch lokale User berücksichtigt werden.

== Ausnahme die eigene IP-Adresse ==

Zum Testen willst du möglicherweise auf ein anderes Backend zugreifen, als es die normalen Webseiten-Besucherinnen tun. Du kannst die eigene IP-Adresse als "RewriteCond" verwenden:

<syntaxhighlight lang=apache line>
DirectoryIndex disabled
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteCond %{REMOTE_ADDR} !=62.27.244.230
RewriteRule ^(.*) ajp://hsh02.hostsharing.net:8009/$1 [proxy,last]

RewriteRule ^(.*) ajp://127.0.0.1:34380/$1 [proxy,last]
</syntaxhighlight>

== Bestimmte Clients blockieren ==

Jeder Web-Browser gibt sich mit einer Kennung zu erkennen. Auch Bots sollten sich mit einer bestimmten Kennung zu erkennen geben. Diese Kennung wird ersichtlich, wenn Du die web.log Datei durchsuchst (siehe [[Traffic]]). Damit ist es möglich, bestimmte Clients oder Bots auszuschließen.

Hier im Beispiel werden der SemrushBot, der MJ12bot, und der AI Bot Claude von Anthropic ausgeschlossen:

<syntaxhighlight lang=apache line>
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_USER_AGENT} ^.*SemrushBot.*$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^.*MJ12bot.*$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^.*ClaudeBot.*$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^$
RewriteRule ^.* - [F,L]
</syntaxhighlight>

Siehe auch https://stackoverflow.com/a/35775449/1632368

== Bestimmte Verzeichnisse nicht ausliefern ==

zum Beispiel das .git Verzeichnis sollte nicht gezeigt werden:

<syntaxhighlight lang=apache line>
RedirectMatch 404 /\.git
</syntaxhighlight>

Oder wenn Wordpress für alle URLs mit HTTP Code 200 die Startseite anzeigt, denken manche Angreifer, es läuft ein mailman.

<syntaxhighlight lang=apache line>
RedirectMatch 404 /mailman/
</syntaxhighlight>

== Gesperrte Optionen ==

Einstellungen, die es ermöglichen würden, über den Webserver Rechte anderer
User zu erhalten, sind nicht erlaubt.
--
[[Kategorie:HSDoku]]
[[Kategorie:WWW]]
[[Kategorie:Glossar]]

Collabora Online

2025-03-13T13:41:12Z

Tim: /* Empfohlene Hardwareausrüstung */

= Collabora installieren =

== Empfohlene Hardwareausrüstung ==

Bei weniger als 4 CPU-Threads zeigt Collabora eine Warnung: "Dein Server verfügt über unzureichende Hardware-Ressourcen, was zu einer schlechten Leistung führen kann.", mit einem Verweis auf [https://sdk.collaboraonline.com/docs/installation/Configuration.html#performance]. Man kommt zu diesem Hinweis, wenn man als Admin angemeldet ist, und auf Hilfe / Server-Prüfung geht.

Das wurde auch von Mitgliedern bestätigt, die mit 3 Personen gleichzeitig an einem Tabellendokument arbeiten wollten.

Es wird bei einem Managed Server daher empfohlen, 4 CPU Threads einzusetzen. Bei den Shared Servern ist das bereits der Fall.

== Vorbereitungen ==

Voraussetzungen sind folgende Punkte:

1. Per Mail an service@hostsharing.net die Aktivierung der Paket Option Collabora Online beauftragen mit der Angabe des Paketkürzel xyz00 und des Benutzers xyz00-cloud unter der die Installation läuft.

2. Grundlage bei Hostsharing ist die Installation der Nextcloud laut Wiki Anleitung [[Nextcloud]].

3. Die APP ''Nextcloud Office'' erst installieren wenn der Service die Bestätigung gesendet hat, dass die Aktivierung erfolgt ist. Hinweis: Bei der Nextcloud-Installation wird ''Nextcloud Office'' u.U. automatisch mit installiert. In diesem Fall ist es notwendig, die App zunächst zu deaktivieren: als Admin im Profilmenü "+ Apps" öffnen und sie dort unter "Aktive Apps" deaktivieren.

== Collabora installieren ==

Collabora ist auf allen 64 Bit hive installiert. Es muss hier nun noch die APP Collabora Online in der Nextcloud installiert werden.

'''WICHTIG:''' Die Freigabe vom Service muss erst per Mail vorliegen!!

1. Anmeldung als '''Admin''' in der Nextcloud Installation

2. Rechts oben auf '''Profilmenü''' den Eintrag '''+APP''' auswählen
[[Datei:Hs-collabora-app-install.jpg|300px]]

3. Im '''Suchfeld''' oben "Nextcloud Office" eingeben
[[Datei:Nextcloud-Office-Suche.png|600px]]

4. Auf den Button ''Herunterladen und aktivieren'' klicken

Damit ist die APP Nextcloud Office installiert und muss nun noch konfiguriert werden.

== Collabora konfigurieren ==

Rechts oben unter '''Profilmenü''' den Eintrag '''Einstellungen''' auswählen.

Anschließend im linken Fensterbereich unter dem Menüpunkt '''Verwaltung'''
den Eintrag '''Collabora Online''' auswählen.

[[Bild:Nextcloud-Office-Menue.png|300px]]

Hier muss nun die PaketDomain entsprechend Eingetragen werden.
Wobei '''xyz00'''.hostsharing.net durch Ihr Paket Kürzel zu ersetzten ist.
Es wird kein Port eingetragen!
Anschließend einmal auf den Button ''Anwenden'' klicken.
[[Bild:Nextcloud-Office-URL.png|600px]]

Es wird empfohlen bei 'Allow list for WOPI requests' die aufgelöste IP Adresse des Webpaketes xyz00.hostsharing.net einzutragen. Sodass nur diese Collabora Instanz Dokumente aus der Nextcloud erhalten kann. Die IP erhält man z.B. über den Konsolenbefehl

<syntaxhighlight lang=shell>
dig xyz00.hostsharing.net
</syntaxhighlight>

Die Relevante Zeile im Output sieht ungefähr so aus:

<syntaxhighlight lang=output line>
;; ANSWER SECTION:
xyz00.hostsharing.net. 3807 IN A 83.223.79.177
</syntaxhighlight>

Die IP Adresse ist die, die dann auch in der Nextcloud auf der Admin Config Seite von Collabora hinterlegt werden muss.

Weitere Einstellungen können individuell noch vorgenommen werden.

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]

Collabora Online

2025-03-13T13:39:49Z

Tim: /* Vorbereitungen */

= Collabora installieren =

== Empfohlene Hardwareausrüstung ==

Bei weniger als 4 CPU-Threads zeigt Collabora eine Warnung: "Dein Server verfügt über unzureichende Hardware-Ressourcen, was zu einer schlechten Leistung führen kann.", mit einem Verweis auf [https://sdk.collaboraonline.com/docs/installation/Configuration.html#performance].

Das wurde auch von Mitgliedern bestätigt, die mit 3 Personen gleichzeitig an einem Tabellendokument arbeiten wollten.

Es wird bei einem Managed Server daher empfohlen, 4 CPU Threads einzusetzen. Bei den Shared Servern ist das bereits der Fall.

== Vorbereitungen ==

Voraussetzungen sind folgende Punkte:

1. Per Mail an service@hostsharing.net die Aktivierung der Paket Option Collabora Online beauftragen mit der Angabe des Paketkürzel xyz00 und des Benutzers xyz00-cloud unter der die Installation läuft.

2. Grundlage bei Hostsharing ist die Installation der Nextcloud laut Wiki Anleitung [[Nextcloud]].

3. Die APP ''Nextcloud Office'' erst installieren wenn der Service die Bestätigung gesendet hat, dass die Aktivierung erfolgt ist. Hinweis: Bei der Nextcloud-Installation wird ''Nextcloud Office'' u.U. automatisch mit installiert. In diesem Fall ist es notwendig, die App zunächst zu deaktivieren: als Admin im Profilmenü "+ Apps" öffnen und sie dort unter "Aktive Apps" deaktivieren.

== Collabora installieren ==

Collabora ist auf allen 64 Bit hive installiert. Es muss hier nun noch die APP Collabora Online in der Nextcloud installiert werden.

'''WICHTIG:''' Die Freigabe vom Service muss erst per Mail vorliegen!!

1. Anmeldung als '''Admin''' in der Nextcloud Installation

2. Rechts oben auf '''Profilmenü''' den Eintrag '''+APP''' auswählen
[[Datei:Hs-collabora-app-install.jpg|300px]]

3. Im '''Suchfeld''' oben "Nextcloud Office" eingeben
[[Datei:Nextcloud-Office-Suche.png|600px]]

4. Auf den Button ''Herunterladen und aktivieren'' klicken

Damit ist die APP Nextcloud Office installiert und muss nun noch konfiguriert werden.

== Collabora konfigurieren ==

Rechts oben unter '''Profilmenü''' den Eintrag '''Einstellungen''' auswählen.

Anschließend im linken Fensterbereich unter dem Menüpunkt '''Verwaltung'''
den Eintrag '''Collabora Online''' auswählen.

[[Bild:Nextcloud-Office-Menue.png|300px]]

Hier muss nun die PaketDomain entsprechend Eingetragen werden.
Wobei '''xyz00'''.hostsharing.net durch Ihr Paket Kürzel zu ersetzten ist.
Es wird kein Port eingetragen!
Anschließend einmal auf den Button ''Anwenden'' klicken.
[[Bild:Nextcloud-Office-URL.png|600px]]

Es wird empfohlen bei 'Allow list for WOPI requests' die aufgelöste IP Adresse des Webpaketes xyz00.hostsharing.net einzutragen. Sodass nur diese Collabora Instanz Dokumente aus der Nextcloud erhalten kann. Die IP erhält man z.B. über den Konsolenbefehl

<syntaxhighlight lang=shell>
dig xyz00.hostsharing.net
</syntaxhighlight>

Die Relevante Zeile im Output sieht ungefähr so aus:

<syntaxhighlight lang=output line>
;; ANSWER SECTION:
xyz00.hostsharing.net. 3807 IN A 83.223.79.177
</syntaxhighlight>

Die IP Adresse ist die, die dann auch in der Nextcloud auf der Admin Config Seite von Collabora hinterlegt werden muss.

Weitere Einstellungen können individuell noch vorgenommen werden.

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]

Collabora Online

2025-03-13T13:39:17Z

Tim: /* Vorbereitungen */

= Collabora installieren =

== Vorbereitungen ==

Voraussetzungen sind folgende Punkte:

1. Per Mail an service@hostsharing.net die Aktivierung der Paket Option Collabora Online beauftragen mit der Angabe des Paketkürzel xyz00 und des Benutzers xyz00-cloud unter der die Installation läuft.

2. Grundlage bei Hostsharing ist die Installation der Nextcloud laut Wiki Anleitung [[Nextcloud]].

3. Die APP ''Nextcloud Office'' erst installieren wenn der Service die Bestätigung gesendet hat, dass die Aktivierung erfolgt ist. Hinweis: Bei der Nextcloud-Installation wird ''Nextcloud Office'' u.U. automatisch mit installiert. In diesem Fall ist es notwendig, die App zunächst zu deaktivieren: als Admin im Profilmenü "+ Apps" öffnen und sie dort unter "Aktive Apps" deaktivieren.

Empfohlene Hardwareausrüstung:

* Bei weniger als 4 CPU-Threads zeigt Collabora eine Warnung: "Dein Server verfügt über unzureichende Hardware-Ressourcen, was zu einer schlechten Leistung führen kann.", mit einem Verweis auf [https://sdk.collaboraonline.com/docs/installation/Configuration.html#performance]. Das wurde auch von Mitgliedern bestätigt, die mit 3 Personen gleichzeitig an einem Tabellendokument arbeiten wollten. Es wird bei einem Managed Server daher empfohlen, 4 CPU Threads einzusetzen. Bei den Shared Servern ist das bereits der Fall.

== Collabora installieren ==

Collabora ist auf allen 64 Bit hive installiert. Es muss hier nun noch die APP Collabora Online in der Nextcloud installiert werden.

'''WICHTIG:''' Die Freigabe vom Service muss erst per Mail vorliegen!!

1. Anmeldung als '''Admin''' in der Nextcloud Installation

2. Rechts oben auf '''Profilmenü''' den Eintrag '''+APP''' auswählen
[[Datei:Hs-collabora-app-install.jpg|300px]]

3. Im '''Suchfeld''' oben "Nextcloud Office" eingeben
[[Datei:Nextcloud-Office-Suche.png|600px]]

4. Auf den Button ''Herunterladen und aktivieren'' klicken

Damit ist die APP Nextcloud Office installiert und muss nun noch konfiguriert werden.

== Collabora konfigurieren ==

Rechts oben unter '''Profilmenü''' den Eintrag '''Einstellungen''' auswählen.

Anschließend im linken Fensterbereich unter dem Menüpunkt '''Verwaltung'''
den Eintrag '''Collabora Online''' auswählen.

[[Bild:Nextcloud-Office-Menue.png|300px]]

Hier muss nun die PaketDomain entsprechend Eingetragen werden.
Wobei '''xyz00'''.hostsharing.net durch Ihr Paket Kürzel zu ersetzten ist.
Es wird kein Port eingetragen!
Anschließend einmal auf den Button ''Anwenden'' klicken.
[[Bild:Nextcloud-Office-URL.png|600px]]

Es wird empfohlen bei 'Allow list for WOPI requests' die aufgelöste IP Adresse des Webpaketes xyz00.hostsharing.net einzutragen. Sodass nur diese Collabora Instanz Dokumente aus der Nextcloud erhalten kann. Die IP erhält man z.B. über den Konsolenbefehl

<syntaxhighlight lang=shell>
dig xyz00.hostsharing.net
</syntaxhighlight>

Die Relevante Zeile im Output sieht ungefähr so aus:

<syntaxhighlight lang=output line>
;; ANSWER SECTION:
xyz00.hostsharing.net. 3807 IN A 83.223.79.177
</syntaxhighlight>

Die IP Adresse ist die, die dann auch in der Nextcloud auf der Admin Config Seite von Collabora hinterlegt werden muss.

Weitere Einstellungen können individuell noch vorgenommen werden.

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]