Hostsharing Wiki - Benutzerbeiträge [de]

LeafWiki installieren

2026-10-16T13:14:31Z

Peh00:

LeafWiki ist eine moderne Wiki-Software, die in der Programmiersprache "Go" entwickelt wird. LeafWiki ist ein junges Projekt. Die Version v0.1.0 ist im Mai 2025 erschienen. Aktuell ist heute, am 15. Oktober 2026, die Version v0.14.1. Etwa monatlich erscheinen neue Versionen.

LeafWiki verwendet Markdown als Wiki-Markup. Die Markdown-Dateien werden auf der Festplatte gespeichert. Eine Datenbank wird nicht benötigt. Einige Metadaten werden jedoch mit Hilfe von SQLite gespeichert.

== Technische Details ==

Die LeafWiki-Software steht als Binärprogramm ohne weitere Abhängigkeiten zur Verfügung. Das macht die Installation sehr einfach.

== Installation ==

Folgende Schritte sind sinnvoll:

# Einen Domain-Admin-Account in HSAdmin einrichten. Ich verwende 'xyz00-leafwiki' als Beispiel.
# Eine (Sub-)Domain bei diesem Account aufschalten. Beispiel: 'wiki.hs-example.de'
# Das Binärprogramm von Github-Releases herunterladen und in 'leafwiki' umgenennen.
# Eine Environment-Datei mit den Einstellungen für Leafwiki anlegen.
# In der '.htaccess'-Datei der Domain einen Proxy konfigurieren.
# Einen Service für Systemd im Userspace einrichten.

== HSAdmin ==

Über die HSAdmin-Oberfläche wird ein User mit Shell '/bin/bash' angelegt. Im zweiten Schritt wird die gewünschte Domain bei diesem User aufgeschaltet.

== Download ==

Die aktuellen Version finden sich beim Github-Projekt:
https://github.com/perber/leafwiki/releases

Wir benötigen das Binary für Linux mit AMD64-Prozessor, aktuell also 'leafwiki-v0.14.1-linux-amd64'.

Ich nenne das Binary in 'leafwiki' um und lege es im Verzeichnis '~/bin' ab. Das Execute-Recht muss gesetzt werden, z.B.:

chmod u+x ~/leafwiki

== Einstellungen ==

Für die Einstellungen des Leafwiki-Dienstes lege ich eine Datei '~/etc/leafwiki.env' an. Ein Beispielinhalt:

LEAFWIKI_HOST=127.0.0.1
LEAFWIKI_PORT=34567
LEAFWIKI_DATA_DIR="/home/storage/xyz00/users/leafwiki/data"
LEAFWIKI_ADMIN_PASSWORD="change_me_soon"
LEAFWIKI_JWT_SECRET="xxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
LEAFWIKI_ENABLE_REVISION=true
LEAFWIKI_LOG_LEVEL=warn
LEAFWIKI_DEFAULT_LANGUAGE=de
LEAFWIKI_SMTP_HOST=127.0.0.1
LEAFWIKI_SMTP_PORT=4025
LEAFWIKI_SMTP_FROM=webmaster@hs-example.de
LEAFWIKI_SMTP_SECURITY=none
LEAFWIKI_PUBLIC_URL=https://wiki.hs-example.de

Ein zufälliges JWT_SECRET lässt sich zum Beipiel wie folgt erzeugen:

LC_ALL=C tr -dc 'A-Za-z0-9' < /dev/urandom | head -c 64; echo

Für die Konfiguration des Apache-Webserver als Proxy wird die Datei '~/doms/wiki.hs-example.com/htdocs-ssl/.htaccess' wie folgt geändert:

DirectoryIndex disabled
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RequestHeader set X-Forwarded-Proto "https"
RewriteRule ^(.*) http://127.0.0.1:34567/$1 [proxy,last]

Einzige Anpassung ist hier der Port '34567'. Der konfigurierte Wert muss auf dem Server frei sein und in beiden Konfigurationsdateien übereinstimmen.

== Systemd Service Konfiguration ==

Als letzte Aktion richten wir den leafwiki-Prozess als Service ein. Dazu legen wir die Unit-Definition in der Datei '~/.config/systemd/user/leafwiki.service' an:

[Unit]
Description=Leafwiki

[Service]
Type=simple
Restart=on-abort
WorkingDirectory=%h
EnvironmentFile=%h/etc/leafwiki.env
ExecStart=%h/bin/leafwiki

[Install]
WantedBy=default.target

Den Dienst starten und aktivieren mit:

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

Viel Spaß mit Leafwiki!

== Links ==
*[https://leafwiki.com/ Webseite des LeafWiki Projekt]

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

LeafWiki installieren

2026-10-16T13:13:49Z

Peh00:

LeafWiki ist eine moderne Wiki-Software, die in der Programmiersprache "Go" entwickelt wird. LeafWiki ist ein junges Projekt. Die Version v0.1.0 ist im Mai 2025 erschienen. Aktuell ist heute, am 15. Oktober 2026, die Version v0.14.1. Etwa monatlich erscheinen neue Versionen.

LeafWiki verwendet Markdown als Wiki-Markup. Die Markdown-Dateien werden auf der Festplatte gespeichert. Eine Datenbank wird nicht benötigt. Eine Metadaten werden jedoch mit Hilfe von SQLite gespeichert.

== Technische Details ==

Die LeafWiki-Software steht als Binärprogramm ohne weitere Abhängigkeiten zur Verfügung. Das macht die Installation sehr einfach.

== Installation ==

Folgende Schritte sind sinnvoll:

# Einen Domain-Admin-Account in HSAdmin einrichten. Ich verwende 'xyz00-leafwiki' als Beispiel.
# Eine (Sub-)Domain bei diesem Account aufschalten. Beispiel: 'wiki.hs-example.de'
# Das Binärprogramm von Github-Releases herunterladen und in 'leafwiki' umgenennen.
# Eine Environment-Datei mit den Einstellungen für Leafwiki anlegen.
# In der '.htaccess'-Datei der Domain einen Proxy konfigurieren.
# Einen Service für Systemd im Userspace einrichten.

== HSAdmin ==

Über die HSAdmin-Oberfläche wird ein User mit Shell '/bin/bash' angelegt. Im zweiten Schritt wird die gewünschte Domain bei diesem User aufgeschaltet.

== Download ==

Die aktuellen Version finden sich beim Github-Projekt:
https://github.com/perber/leafwiki/releases

Wir benötigen das Binary für Linux mit AMD64-Prozessor, aktuell also 'leafwiki-v0.14.1-linux-amd64'.

Ich nenne das Binary in 'leafwiki' um und lege es im Verzeichnis '~/bin' ab. Das Execute-Recht muss gesetzt werden, z.B.:

chmod u+x ~/leafwiki

== Einstellungen ==

Für die Einstellungen des Leafwiki-Dienstes lege ich eine Datei '~/etc/leafwiki.env' an. Ein Beispielinhalt:

LEAFWIKI_HOST=127.0.0.1
LEAFWIKI_PORT=34567
LEAFWIKI_DATA_DIR="/home/storage/xyz00/users/leafwiki/data"
LEAFWIKI_ADMIN_PASSWORD="change_me_soon"
LEAFWIKI_JWT_SECRET="xxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
LEAFWIKI_ENABLE_REVISION=true
LEAFWIKI_LOG_LEVEL=warn
LEAFWIKI_DEFAULT_LANGUAGE=de
LEAFWIKI_SMTP_HOST=127.0.0.1
LEAFWIKI_SMTP_PORT=4025
LEAFWIKI_SMTP_FROM=webmaster@hs-example.de
LEAFWIKI_SMTP_SECURITY=none
LEAFWIKI_PUBLIC_URL=https://wiki.hs-example.de

Ein zufälliges JWT_SECRET lässt sich zum Beipiel wie folgt erzeugen:

LC_ALL=C tr -dc 'A-Za-z0-9' < /dev/urandom | head -c 64; echo

Für die Konfiguration des Apache-Webserver als Proxy wird die Datei '~/doms/wiki.hs-example.com/htdocs-ssl/.htaccess' wie folgt geändert:

DirectoryIndex disabled
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RequestHeader set X-Forwarded-Proto "https"
RewriteRule ^(.*) http://127.0.0.1:34567/$1 [proxy,last]

Einzige Anpassung ist hier der Port '34567'. Der konfigurierte Wert muss auf dem Server frei sein und in beiden Konfigurationsdateien übereinstimmen.

== Systemd Service Konfiguration ==

Als letzte Aktion richten wir den leafwiki-Prozess als Service ein. Dazu legen wir die Unit-Definition in der Datei '~/.config/systemd/user/leafwiki.service' an:

[Unit]
Description=Leafwiki

[Service]
Type=simple
Restart=on-abort
WorkingDirectory=%h
EnvironmentFile=%h/etc/leafwiki.env
ExecStart=%h/bin/leafwiki

[Install]
WantedBy=default.target

Den Dienst starten und aktivieren mit:

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

Viel Spaß mit Leafwiki!

== Links ==
*[https://leafwiki.com/ Webseite des LeafWiki Projekt]

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

LeafWiki installieren

2026-10-15T18:19:41Z

Peh00: /* Systemd Service Konfiguration */

LeafWiki ist eine moderne Wiki-Software, die in der Programmiersprache "Go" entwickelt wird. LeafWiki ist ein junges Projekt. Die Version v0.1.0 im im Mai 2025 erschienen. Aktuell ist heute, am 15. Oktober 2026, die Version v0.14.1. Etwa monatlich erscheinen neue Versionen.

LeafWiki verwendet Markdown als Wiki-Markup. Die Markdown-Dateien werden auf der Festplatte gespeichert. Eine Datenbank wird nicht benötigt. Eine Metadaten werden jedoch mit Hilfe von SQLite gespeichert.

== Technische Details ==

Die LeafWiki-Software steht als Binärprogramm ohne weitere Abhängigkeiten zur Verfügung. Das macht die Installation sehr einfach.

== Installation ==

Folgende Schritte sind sinnvoll:

# Einen Domain-Admin-Account in HSAdmin einrichten. Ich verwende 'xyz00-leafwiki' als Beispiel.
# Eine (Sub-)Domain bei diesem Account aufschalten. Beispiel: 'wiki.hs-example.de'
# Das Binärprogramm von Github-Releases herunterladen und in 'leafwiki' umgenennen.
# Eine Environment-Datei mit den Einstellungen für Leafwiki anlegen.
# In der '.htaccess'-Datei der Domain einen Proxy konfigurieren.
# Einen Service für Systemd im Userspace einrichten.

== HSAdmin ==

Über die HSAdmin-Oberfläche wird ein User mit Shell '/bin/bash' angelegt. Im zweiten Schritt wird die gewünschte Domain bei diesem User aufgeschaltet.

== Download ==

Die aktuellen Version finden sich beim Github-Projekt:
https://github.com/perber/leafwiki/releases

Wir benötigen das Binary für Linux mit AMD64-Prozessor, aktuell also 'leafwiki-v0.14.1-linux-amd64'.

Ich nenne das Binary in 'leafwiki' um und lege es im Verzeichnis '~/bin' ab. Das Execute-Recht muss gesetzt werden, z.B.:

chmod u+x ~/leafwiki

== Einstellungen ==

Für die Einstellungen des Leafwiki-Dienstes lege ich eine Datei '~/etc/leafwiki.env' an. Ein Beispielinhalt:

LEAFWIKI_HOST=127.0.0.1
LEAFWIKI_PORT=34567
LEAFWIKI_DATA_DIR="/home/storage/xyz00/users/leafwiki/data"
LEAFWIKI_ADMIN_PASSWORD="change_me_soon"
LEAFWIKI_JWT_SECRET="xxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
LEAFWIKI_ENABLE_REVISION=true
LEAFWIKI_LOG_LEVEL=warn
LEAFWIKI_DEFAULT_LANGUAGE=de
LEAFWIKI_SMTP_HOST=127.0.0.1
LEAFWIKI_SMTP_PORT=4025
LEAFWIKI_SMTP_FROM=webmaster@hs-example.de
LEAFWIKI_SMTP_SECURITY=none
LEAFWIKI_PUBLIC_URL=https://wiki.hs-example.de

Ein zufälliges JWT_SECRET lässt sich zum Beipiel wie folgt erzeugen:

LC_ALL=C tr -dc 'A-Za-z0-9' < /dev/urandom | head -c 64; echo

Für die Konfiguration des Apache-Webserver als Proxy wird die Datei '~/doms/wiki.hs-example.com/htdocs-ssl/.htaccess' wie folgt geändert:

DirectoryIndex disabled
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RequestHeader set X-Forwarded-Proto "https"
RewriteRule ^(.*) http://127.0.0.1:34567/$1 [proxy,last]

Einzige Anpassung ist hier der Port '34567'. Der konfigurierte Wert muss auf dem Server frei sein und in beiden Konfigurationsdateien übereinstimmen.

== Systemd Service Konfiguration ==

Als letzte Aktion richten wir den leafwiki-Prozess als Service ein. Dazu legen wir die Unit-Definition in der Datei '~/.config/systemd/user/leafwiki.service' an:

[Unit]
Description=Leafwiki

[Service]
Type=simple
Restart=on-abort
WorkingDirectory=%h
EnvironmentFile=%h/etc/leafwiki.env
ExecStart=%h/bin/leafwiki

[Install]
WantedBy=default.target

Den Dienst starten und aktivieren mit:

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

Viel Spaß mit Leafwiki!

== Links ==
*[https://leafwiki.com/ Webseite des LeafWiki Projekt]

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

LeafWiki installieren

2026-10-15T18:17:47Z

Peh00: /* Technische Details */

LeafWiki ist eine moderne Wiki-Software, die in der Programmiersprache "Go" entwickelt wird. LeafWiki ist ein junges Projekt. Die Version v0.1.0 im im Mai 2025 erschienen. Aktuell ist heute, am 15. Oktober 2026, die Version v0.14.1. Etwa monatlich erscheinen neue Versionen.

LeafWiki verwendet Markdown als Wiki-Markup. Die Markdown-Dateien werden auf der Festplatte gespeichert. Eine Datenbank wird nicht benötigt. Eine Metadaten werden jedoch mit Hilfe von SQLite gespeichert.

== Technische Details ==

Die LeafWiki-Software steht als Binärprogramm ohne weitere Abhängigkeiten zur Verfügung. Das macht die Installation sehr einfach.

== Installation ==

Folgende Schritte sind sinnvoll:

# Einen Domain-Admin-Account in HSAdmin einrichten. Ich verwende 'xyz00-leafwiki' als Beispiel.
# Eine (Sub-)Domain bei diesem Account aufschalten. Beispiel: 'wiki.hs-example.de'
# Das Binärprogramm von Github-Releases herunterladen und in 'leafwiki' umgenennen.
# Eine Environment-Datei mit den Einstellungen für Leafwiki anlegen.
# In der '.htaccess'-Datei der Domain einen Proxy konfigurieren.
# Einen Service für Systemd im Userspace einrichten.

== HSAdmin ==

Über die HSAdmin-Oberfläche wird ein User mit Shell '/bin/bash' angelegt. Im zweiten Schritt wird die gewünschte Domain bei diesem User aufgeschaltet.

== Download ==

Die aktuellen Version finden sich beim Github-Projekt:
https://github.com/perber/leafwiki/releases

Wir benötigen das Binary für Linux mit AMD64-Prozessor, aktuell also 'leafwiki-v0.14.1-linux-amd64'.

Ich nenne das Binary in 'leafwiki' um und lege es im Verzeichnis '~/bin' ab. Das Execute-Recht muss gesetzt werden, z.B.:

chmod u+x ~/leafwiki

== Einstellungen ==

Für die Einstellungen des Leafwiki-Dienstes lege ich eine Datei '~/etc/leafwiki.env' an. Ein Beispielinhalt:

LEAFWIKI_HOST=127.0.0.1
LEAFWIKI_PORT=34567
LEAFWIKI_DATA_DIR="/home/storage/xyz00/users/leafwiki/data"
LEAFWIKI_ADMIN_PASSWORD="change_me_soon"
LEAFWIKI_JWT_SECRET="xxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
LEAFWIKI_ENABLE_REVISION=true
LEAFWIKI_LOG_LEVEL=warn
LEAFWIKI_DEFAULT_LANGUAGE=de
LEAFWIKI_SMTP_HOST=127.0.0.1
LEAFWIKI_SMTP_PORT=4025
LEAFWIKI_SMTP_FROM=webmaster@hs-example.de
LEAFWIKI_SMTP_SECURITY=none
LEAFWIKI_PUBLIC_URL=https://wiki.hs-example.de

Ein zufälliges JWT_SECRET lässt sich zum Beipiel wie folgt erzeugen:

LC_ALL=C tr -dc 'A-Za-z0-9' < /dev/urandom | head -c 64; echo

Für die Konfiguration des Apache-Webserver als Proxy wird die Datei '~/doms/wiki.hs-example.com/htdocs-ssl/.htaccess' wie folgt geändert:

DirectoryIndex disabled
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RequestHeader set X-Forwarded-Proto "https"
RewriteRule ^(.*) http://127.0.0.1:34567/$1 [proxy,last]

Einzige Anpassung ist hier der Port '34567'. Der konfigurierte Wert muss auf dem Server frei sein und in beiden Konfigurationsdateien übereinstimmen.

== Systemd Service Konfiguration ==

Als letzte Aktion richten wir den leafwiki-Prozess als Service ein. Dazu legen wir die Unit-Definition in der Datei '~/.config/systemd/user/leafwiki.service' an:

[Unit]
Description=Leafwiki

[Service]
Type=simple
Restart=on-abort
WorkingDirectory=%h
EnvironmentFile=%h/etc/leafwiki.env
ExecStart=%h/bin/leafwiki

[Install]
WantedBy=default.target

== Links ==
*[https://leafwiki.com/ Webseite des LeafWiki Projekt]

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

LeafWiki installieren

2026-10-15T18:16:14Z

Peh00:

LeafWiki ist eine moderne Wiki-Software, die in der Programmiersprache "Go" entwickelt wird. LeafWiki ist ein junges Projekt. Die Version v0.1.0 im im Mai 2025 erschienen. Aktuell ist heute, am 15. Oktober 2026, die Version v0.14.1. Etwa monatlich erscheinen neue Versionen.

LeafWiki verwendet Markdown als Wiki-Markup. Die Markdown-Dateien werden auf der Festplatte gespeichert. Eine Datenbank wird nicht benötigt. Eine Metadaten werden jedoch mit Hilfe von SQLite gespeichert.

== Technische Details ==

Die LeafWiki-Software steht als Binärprogramm ohen weitere Abhängigkeiten zur Verfügung. Das macht die Installation sehr einfach.

== Installation ==

Folgende Schritte sind sinnvoll:

# Einen Domain-Admin-Account in HSAdmin einrichten. Ich verwende 'xyz00-leafwiki' als Beispiel.
# Eine (Sub-)Domain bei diesem Account aufschalten. Beispiel: 'wiki.hs-example.de'
# Das Binärprogramm von Github-Releases herunterladen und in 'leafwiki' umgenennen.
# Eine Environment-Datei mit den Einstellungen für Leafwiki anlegen.
# In der '.htaccess'-Datei der Domain einen Proxy konfigurieren.
# Einen Service für Systemd im Userspace einrichten.

== HSAdmin ==

Über die HSAdmin-Oberfläche wird ein User mit Shell '/bin/bash' angelegt. Im zweiten Schritt wird die gewünschte Domain bei diesem User aufgeschaltet.

== Download ==

Die aktuellen Version finden sich beim Github-Projekt:
https://github.com/perber/leafwiki/releases

Wir benötigen das Binary für Linux mit AMD64-Prozessor, aktuell also 'leafwiki-v0.14.1-linux-amd64'.

Ich nenne das Binary in 'leafwiki' um und lege es im Verzeichnis '~/bin' ab. Das Execute-Recht muss gesetzt werden, z.B.:

chmod u+x ~/leafwiki

== Einstellungen ==

Für die Einstellungen des Leafwiki-Dienstes lege ich eine Datei '~/etc/leafwiki.env' an. Ein Beispielinhalt:

LEAFWIKI_HOST=127.0.0.1
LEAFWIKI_PORT=34567
LEAFWIKI_DATA_DIR="/home/storage/xyz00/users/leafwiki/data"
LEAFWIKI_ADMIN_PASSWORD="change_me_soon"
LEAFWIKI_JWT_SECRET="xxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
LEAFWIKI_ENABLE_REVISION=true
LEAFWIKI_LOG_LEVEL=warn
LEAFWIKI_DEFAULT_LANGUAGE=de
LEAFWIKI_SMTP_HOST=127.0.0.1
LEAFWIKI_SMTP_PORT=4025
LEAFWIKI_SMTP_FROM=webmaster@hs-example.de
LEAFWIKI_SMTP_SECURITY=none
LEAFWIKI_PUBLIC_URL=https://wiki.hs-example.de

Ein zufälliges JWT_SECRET lässt sich zum Beipiel wie folgt erzeugen:

LC_ALL=C tr -dc 'A-Za-z0-9' < /dev/urandom | head -c 64; echo

Für die Konfiguration des Apache-Webserver als Proxy wird die Datei '~/doms/wiki.hs-example.com/htdocs-ssl/.htaccess' wie folgt geändert:

DirectoryIndex disabled
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RequestHeader set X-Forwarded-Proto "https"
RewriteRule ^(.*) http://127.0.0.1:34567/$1 [proxy,last]

Einzige Anpassung ist hier der Port '34567'. Der konfigurierte Wert muss auf dem Server frei sein und in beiden Konfigurationsdateien übereinstimmen.

== Systemd Service Konfiguration ==

Als letzte Aktion richten wir den leafwiki-Prozess als Service ein. Dazu legen wir die Unit-Definition in der Datei '~/.config/systemd/user/leafwiki.service' an:

[Unit]
Description=Leafwiki

[Service]
Type=simple
Restart=on-abort
WorkingDirectory=%h
EnvironmentFile=%h/etc/leafwiki.env
ExecStart=%h/bin/leafwiki

[Install]
WantedBy=default.target

== Links ==
*[https://leafwiki.com/ Webseite des LeafWiki Projekt]

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

LeafWiki installieren

2026-10-15T18:15:17Z

Peh00: erste version

LeafWiki ist eine moderne Wiki-Software, die in der Programmiersprache "Go" entwickelt wird. LeafWiki ist ein jungen Projekt. Die Version v0.1.0 im im Mai 2025 erschienen. Aktuell ist heute, am 15. Oktober 2026, die Version v0.14.1. Etwa monatlich erscheinen neue Versionen.

LeafWiki verwendet Markdown als Wiki-Markup. Die Markdown-Dateien werden auf der Festplatte gespeichert. Eine Datenbank wird nicht benötigt. Eine Metadaten werden jedoch mit Hilfe von SQLite gespeichert.

== Technische Details ==

Die LeafWiki-Software steht als Binärprogramm ohen weitere Abhängigkeiten zur Verfügung. Das macht die Installation sehr einfach.

== Installation ==

Folgende Schritte sind sinnvoll:

# Einen Domain-Admin-Account in HSAdmin einrichten. Ich verwende 'xyz00-leafwiki' als Beispiel.
# Eine (Sub-)Domain bei diesem Account aufschalten. Beispiel: 'wiki.hs-example.de'
# Das Binärprogramm von Github-Releases herunterladen und in 'leafwiki' umgenennen.
# Eine Environment-Datei mit den Einstellungen für Leafwiki anlegen.
# In der '.htaccess'-Datei der Domain einen Proxy konfigurieren.
# Einen Service für Systemd im Userspace einrichten.

== HSAdmin ==

Über die HSAdmin-Oberfläche wird ein User mit Shell '/bin/bash' angelegt. Im zweiten Schritt wird die gewünschte Domain bei diesem User aufgeschaltet.

== Download ==

Die aktuellen Version finden sich beim Github-Projekt:
https://github.com/perber/leafwiki/releases

Wir benötigen das Binary für Linux mit AMD64-Prozessor, aktuell also 'leafwiki-v0.14.1-linux-amd64'.

Ich nenne das Binary in 'leafwiki' um und lege es im Verzeichnis '~/bin' ab. Das Execute-Recht muss gesetzt werden, z.B.:

chmod u+x ~/leafwiki

== Einstellungen ==

Für die Einstellungen des Leafwiki-Dienstes lege ich eine Datei '~/etc/leafwiki.env' an. Ein Beispielinhalt:

LEAFWIKI_HOST=127.0.0.1
LEAFWIKI_PORT=34567
LEAFWIKI_DATA_DIR="/home/storage/xyz00/users/leafwiki/data"
LEAFWIKI_ADMIN_PASSWORD="change_me_soon"
LEAFWIKI_JWT_SECRET="xxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
LEAFWIKI_ENABLE_REVISION=true
LEAFWIKI_LOG_LEVEL=warn
LEAFWIKI_DEFAULT_LANGUAGE=de
LEAFWIKI_SMTP_HOST=127.0.0.1
LEAFWIKI_SMTP_PORT=4025
LEAFWIKI_SMTP_FROM=webmaster@hs-example.de
LEAFWIKI_SMTP_SECURITY=none
LEAFWIKI_PUBLIC_URL=https://wiki.hs-example.de

Ein zufälliges JWT_SECRET lässt sich zum Beipiel wie folgt erzeugen:

LC_ALL=C tr -dc 'A-Za-z0-9' < /dev/urandom | head -c 64; echo

Für die Konfiguration des Apache-Webserver als Proxy wird die Datei '~/doms/wiki.hs-example.com/htdocs-ssl/.htaccess' wie folgt geändert:

DirectoryIndex disabled
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RequestHeader set X-Forwarded-Proto "https"
RewriteRule ^(.*) http://127.0.0.1:34567/$1 [proxy,last]

Einzige Anpassung ist hier der Port '34567'. Der konfigurierte Wert muss auf dem Server frei sein und in beiden Konfigurationsdateien übereinstimmen.

== Systemd Service Konfiguration ==

Als letzte Aktion richten wir den leafwiki-Prozess als Service ein. Dazu legen wir die Unit-Definition in der Datei '~/.config/systemd/user/leafwiki.service' an:

[Unit]
Description=Leafwiki

[Service]
Type=simple
Restart=on-abort
WorkingDirectory=%h
EnvironmentFile=%h/etc/leafwiki.env
ExecStart=%h/bin/leafwiki

[Install]
WantedBy=default.target

== Links ==
*[https://leafwiki.com/ Webseite des LeafWiki Projekt]

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

WebDAV mit Tomcat

2026-05-15T17:18:38Z

Peh00: RAM Kontingent

= WebDAV mit Tomcat =

Tomcat steht als Software auf jedem Shared Server mit Webspaces der Mitglieder als Software zur Verfügung. Eine einfache WebDAV-Implementierung ist enthalten.

Der Betrieb von Tomcat im Webspace erfordert ein ausreichendes RAM-Kontingent, das zum Webspace zugebucht werden muss. Man muss vermutlich 256 MB für einen WebDAV-Dienst mit Tomcat als Server einplanen.

Die Einrichtung von Apache Tomcat im Webspace ist auf der Seite [[Tomcat Installieren|'Tomcat installieren']] beschrieben.

Sei 'hs-example.de' die Domain, unter der der Tomcat erreichbar ist, wie auf der Installationsseite. Unter der URL https://hs-example.de/dav/ soll der WebDAV-Dienst erreichbar sein. Dann legen wir eine Datei 'dav.xml' ins Verzeichnis '~/tomcat/conf/Catalina/localhost' ('Catalina' ist der Name der 'Engine', 'localhost' der Name des 'Host' aus der 'server.xml' des Tomcat). Inhalt der Datei:

<syntaxhighlight lang="xml">
<Context docBase="/home/storage/xyz00/users/webdav/data" reloadable="false" />
</syntaxhighlight>

Hier liegen die Dateien in der '/home/storage'-Partition auf der HDD, 'xyz00' steht für den Namen des Webspace, 'webdav' ist der hintere Teil des Users, mit dessen Rechten der Tomcat läuft (Beispiel-User ist also 'xyz00-webdav'). Das Verzeichnis muss angelegt werden, zum Beispiel mit:

<syntaxhighlight lang="bash">
mkdir /home/storage/xyz00/users/webdav/data
</syntaxhighlight>

In dieses 'docBase'-Verzeichnis legen wir ein Verzeichnis 'WEB-INF' mit einer Datei 'web.xml', um die Webapplikation im Tomcat zu konfigurieren.

<syntaxhighlight lang="bash">
mkdir /home/storage/xyz00/users/webdav/data/WEB-INF
</syntaxhighlight>

Inhalt der 'web.xml' in diesem Verzeichnis:

<syntaxhighlight lang="xml" line>
<?xml version="1.0" encoding="UTF-8"?>
<web-app
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
id="WebApp_ID" version="3.0">
<servlet>
<servlet-name>webdav</servlet-name>
<servlet-class>org.apache.catalina.servlets.WebdavServlet</servlet-class>
<init-param>
<param-name>debug</param-name>
<param-value>0</param-value>
</init-param>
<init-param>
<param-name>listings</param-name>
<param-value>true</param-value>
</init-param>
<init-param>
<param-name>readonly</param-name>
<param-value>false</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>webdav</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>
<security-role>
<role-name>webdavaccess</role-name>
</security-role>
<security-constraint>
<web-resource-collection>
<web-resource-name>WebDAV Access</web-resource-name>
<url-pattern>/*</url-pattern>
<http-method>*</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>webdavaccess</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>WebDAV Access</realm-name>
</login-config>
</web-app>
</syntaxhighlight>

In der 'web.xml' werden auch die Zugriffsrechte auf die WebDAV-Freigabe definiert. Hier bekommt die Rolle 'webdavaccess' Vollzugriff. In der Default-Konfiguration des Tomcat werden Accounts und Rollen in der Datei '~/tomcat/conf/tomcat-users.xml' definiert:

<syntaxhighlight lang="xml" line>
<?xml version="1.0" encoding="UTF-8"?>
<tomcat-users xmlns="http://tomcat.apache.org/xml"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://tomcat.apache.org/xml tomcat-users.xsd"
version="1.0">
<role rolename="webdavaccess"/>
<user username="webdavlogin" password="**gutes*Passwort**" roles="webdavaccess"/>
</tomcat-users>
</syntaxhighlight>

Ohne weiteres können Accounts, Passworte und Rollen auch in einer SQL-Datenbank oder in einem LDAP-Verzeichnis abgelegt werden. Dazu ein Verweis auf die Upstream-Dokumentation:
[https://tomcat.apache.org/tomcat-10.1-doc/realm-howto.html Apache Tomcat Realm Configuration How-To]

== Links ==

* [https://tomcat.apache.org/tomcat-10.1-doc/api/org/apache/catalina/servlets/WebdavServlet.html JavaDoc zur Klasse WebdavServlet]

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

WebDAV mit RClone

2026-05-15T17:12:07Z

Peh00: RAM Bedarf

= WebDAV mit Rclone =

Rclone ist ein einfaches Binärprogramm. Es ist in der Programmiersprache 'Go' programmiert und ist vom klassischen 'rsync' beeinflusst.

Rclone kann Dateien über verschiedene Netzwerkprotokolle kopieren und sychronisieren, und es enthält auch Server-Funktionalität. Hier nutzen wir es als WebDAV-Server.

Rclone ist als Paket in der Debian-Distribution verfügbar und auf den Hostsharing-Servern vorinstalliert. In Debian 12 ist die Version 'rclone v1.60.1-DEV' enthalten. Für den Betrieb als Server im Webspace sollte man 128 MB RAM-Kontigent für diesen Dienst einplanen.

Wir können ad hoc sehr einfach einen WebDAV-Server starten:

mkdir $HOME/data
rclone serve webdav $HOME/data --addr 127.0.0.1:38246 --user test --pass kein-gutes-passwort

Den 'rclone'-Befehl brechen wir zunächst mit 'Ctrl-C' wieder ab.

Dann müssen wir eine Domain beim User aufschalten und die '.htaccess'-Datei erstellen, damit der WebDAV-Server über https/Port 443 erreichbar wird.

Für die Domain 'webdav.hs-example.de' wäre die .htaccess im Verzeichnis '$HOME/doms/webdav.hs-example.de/htdocs-ss/' mit dem oben gewählten Port '38246':

DirectoryIndex disabled
RewriteEngine On
RewriteBase /
RewriteRule .* http://127.0.0.1:38246%{REQUEST_URI} [proxy]
RequestHeader set X-Forwarded-Proto "https"

Damit 'rclone' als Dienst läuft, erstellen wir eine Datei 'rclone.service' im Verzeichnis '$HOME/.config/systemd/user/' mit dem Inhalt:

[Unit]
Description=Rclone WebDAV Service

[Service]
Environment="UMASK=0022"
ExecStart=/usr/bin/rclone serve webdav %h/data --addr 127.0.0.1:38246 --htpasswd %h/etc/htpasswd
Restart=always

[Install]
WantedBy=default.target

Hier wird eine Datei '$HOME/etc/htpasswd' für die WebDAV-Accounts benutzt. Diese Datei können wir wie folgt mit einem Account 'webdav' und Passwort 'geheim' anlegen:

htpasswd -cb $HOME/etc/htpasswd webdav geheim
chmod 600 $HOME/etc/htpasswd

Den Dienst aktivieren und starten:

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

WebDAV mit RClone

2026-05-15T17:10:53Z

Peh00: Netzwerkfunktion

= WebDAV mit Rclone =

Rclone ist ein einfaches Binärprogramm. Es ist in der Programmiersprache 'Go' programmiert und ist vom klassischen 'rsync' beeinflusst.

Rclone kann Dateien über verschiedene Netzwerkprotokolle kopieren und sychronisieren, und es enthält auch Server-Funktionalität. Hier nutzen wir es als WebDAV-Server.

Rclone ist als Paket in der Debian-Distribution verfügbar und auf den Hostsharing-Servern vorinstalliert. In Debian 12 ist die Version 'rclone v1.60.1-DEV' enthalten.

Wir können ad hoc sehr einfach einen WebDAV-Server starten:

mkdir $HOME/data
rclone serve webdav $HOME/data --addr 127.0.0.1:38246 --user test --pass kein-gutes-passwort

Den 'rclone'-Befehl brechen wir zunächst mit 'Ctrl-C' wieder ab.

Dann müssen wir eine Domain beim User aufschalten und die '.htaccess'-Datei erstellen, damit der WebDAV-Server über https/Port 443 erreichbar wird.

Für die Domain 'webdav.hs-example.de' wäre die .htaccess im Verzeichnis '$HOME/doms/webdav.hs-example.de/htdocs-ss/' mit dem oben gewählten Port '38246':

DirectoryIndex disabled
RewriteEngine On
RewriteBase /
RewriteRule .* http://127.0.0.1:38246%{REQUEST_URI} [proxy]
RequestHeader set X-Forwarded-Proto "https"

Damit 'rclone' als Dienst läuft, erstellen wir eine Datei 'rclone.service' im Verzeichnis '$HOME/.config/systemd/user/' mit dem Inhalt:

[Unit]
Description=Rclone WebDAV Service

[Service]
Environment="UMASK=0022"
ExecStart=/usr/bin/rclone serve webdav %h/data --addr 127.0.0.1:38246 --htpasswd %h/etc/htpasswd
Restart=always

[Install]
WantedBy=default.target

Hier wird eine Datei '$HOME/etc/htpasswd' für die WebDAV-Accounts benutzt. Diese Datei können wir wie folgt mit einem Account 'webdav' und Passwort 'geheim' anlegen:

htpasswd -cb $HOME/etc/htpasswd webdav geheim
chmod 600 $HOME/etc/htpasswd

Den Dienst aktivieren und starten:

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

WebDAV mit RClone

2026-05-15T16:57:07Z

Peh00: htpasswd, enable

= WebDAV mit Rclone =

Rclone ist ein einfaches Binärprogramm. Es ist in der Programmiersprache 'Go' programmiert und ist vom klassischen 'rsync' beeinflusst.

Rclone kann Dateien kopieren und sychronisieren, aber es enthält auch Server-Funktionalität. Hier nutzen wir es als WebDAV-Server.

Rclone ist als Paket in der Debian-Distribution verfügbar und auf den Hostsharing-Servern vorinstalliert. In Debian 12 ist die Version 'rclone v1.60.1-DEV' enthalten.

Wir können ad hoc sehr einfach einen WebDAV-Server starten:

mkdir $HOME/data
rclone serve webdav $HOME/data --addr 127.0.0.1:38246 --user test --pass kein-gutes-passwort

Den 'rclone'-Befehl brechen wir zunächst mit 'Ctrl-C' wieder ab.

Dann müssen wir eine Domain beim User aufschalten und die '.htaccess'-Datei erstellen, damit der WebDAV-Server über https/Port 443 erreichbar wird.

Für die Domain 'webdav.hs-example.de' wäre die .htaccess im Verzeichnis '$HOME/doms/webdav.hs-example.de/htdocs-ss/' mit dem oben gewählten Port '38246':

DirectoryIndex disabled
RewriteEngine On
RewriteBase /
RewriteRule .* http://127.0.0.1:38246%{REQUEST_URI} [proxy]
RequestHeader set X-Forwarded-Proto "https"

Damit 'rclone' als Dienst läuft, erstellen wir eine Datei 'rclone.service' im Verzeichnis '$HOME/.config/systemd/user/' mit dem Inhalt:

[Unit]
Description=Rclone WebDAV Service

[Service]
Environment="UMASK=0022"
ExecStart=/usr/bin/rclone serve webdav %h/data --addr 127.0.0.1:38246 --htpasswd %h/etc/htpasswd
Restart=always

[Install]
WantedBy=default.target

Hier wird eine Datei '$HOME/etc/htpasswd' für die WebDAV-Accounts benutzt. Diese Datei können wir wie folgt mit einem Account 'webdav' und Passwort 'geheim' anlegen:

htpasswd -cb $HOME/etc/htpasswd webdav geheim
chmod 600 $HOME/etc/htpasswd

Den Dienst aktivieren und starten:

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

WebDAV mit RClone

2026-05-15T16:30:17Z

Peh00: fix

= WebDAV mit Rclone =

Rclone ist ein einfaches Binärprogramm. Es ist in der Programmiersprache 'Go' programmiert und ist vom klassischen 'rsync' beeinflusst.

Rclone kann Dateien kopieren und sychronisieren, aber es enthält auch Server-Funktionalität. Hier nutzen wir es als WebDAV-Server.

Rclone ist als Paket in der Debian-Distribution verfügbar und auf den Hostsharing-Servern vorinstalliert. In Debian 12 ist die Version 'rclone v1.60.1-DEV' enthalten.

Wir können ad hoc sehr einfach einen WebDAV-Server starten:

mkdir $HOME/data
rclone serve webdav $HOME/data --addr 127.0.0.1:38246 --user test --pass kein-gutes-passwort

Den 'rclone'-Befehl brechen wir zunächst mit 'Ctrl-C' wieder ab.

Dann müssen wir eine Domain beim User aufschalten und die '.htaccess'-Datei erstellen, damit der WebDAV-Server über https/Port 443 erreichbar wird.

Für die Domain 'webdav.hs-example.de' wäre die .htaccess im Verzeichnis '$HOME/doms/webdav.hs-example.de/htdocs-ss/' mit dem oben gewählten Port '38246':

DirectoryIndex disabled
RewriteEngine On
RewriteBase /
RewriteRule .* http://127.0.0.1:38246%{REQUEST_URI} [proxy]
RequestHeader set X-Forwarded-Proto "https"

Damit 'rclone' als Dienst läuft, erstellen wir eine Datei 'rclone.service' im Verzeichnis '$HOME/.config/systemd/user/' mit dem Inhalt:

[Unit]
Description=Rclone WebDAV Service

[Service]
Environment="UMASK=0022"
ExecStart=/usr/bin/rclone serve webdav %h/data --addr 127.0.0.1:38246 --user test --pass kein-gutes-passwort
Restart=always

[Install]
WantedBy=default.target

WebDAV mit RClone

2026-05-15T16:26:53Z

Peh00: Initiale Version

= WebDAV mit Rclone =

Rclone ist ein einfaches Binärprogramm. Es ist in der Programmiersprache 'Go' programmiert und ist vom klassischen 'rsync' beeinflusst.

Rclone kann Dateien kopieren und sychronisieren, aber es enthält auch Server-Funktionalität. Hier nutzen wir es als WebDAV-Server.

Rclone ist als Paket in der Debian-Distribution verfügbar und auf den Hostsharing-Servern vorinstalliert. In Debian 12 ist die Version 'rclone v1.60.1-DEV' enthalten.

Wir können ad hoc sehr einfach einen WebDAV-Server starten:

mkdir $HOME/data
rclone serve webdav $HOME/data --addr 127.0.0.1:38246 --user test --pass kein-gutes-passwort

Den 'rclone'-Befehl brechen wir zunächst mit 'Ctrl-C' wieder ab.

Dann müssen wir eine Domain beim User aufschalten und die '.htaccess'-Datei erstellen, damit der WebDAV-Server über https/Port 443 erreichbar wird.

Für die Domain 'webdav.hs-example.de' wäre die .htaccess im Verzeichnis '$HOME/doms/webdav.hs-example.de/htdocs-ss/' mit dem oben gewählten Port '38246':

DirectoryIndex disabled
RewriteEngine On
RewriteBase /
RewriteRule .* http://127.0.0.1:38246%{REQUEST_URI} [proxy]
RequestHeader set X-Forwarded-Proto "https"

Damit 'rclone' als Dienst läuft, erstellen wir eine Datei 'rclone.service' im Verzeichnis '$HOME/.config/systemd/user/' mit dem Inhalt:

[Unit]
Description=Rclone WebDAV Service

[Service]
Environment="UMASK=0022"
ExecStart=/usr/bin/rclone serve_webdav %h/data --addr 127.0.0.1:38246 --user test --pass kein-gutes-passwort
Restart=always

[Install]
WantedBy=default.target

WebDAV mit Tomcat

2026-05-14T19:07:02Z

Peh00: Typos

= WebDAV mit Tomcat =

Tomcat steht als Software auf jedem Shared Server mit Webspaces der Mitglieder als Software zur Verfügung. Eine einfache WebDAV-Implementierung ist enthalten.

Der Betrieb von Tomcat im Webspace erfordert ein ausreichendes RAM-Kontingent, das zum Webspace zugebucht werden muss.

Die Einrichtung von Apache Tomcat im Webspace ist auf der Seite [[Tomcat Installieren|'Tomcat installieren']] beschrieben.

Sei 'hs-example.de' die Domain, unter der der Tomcat erreichbar ist, wie auf der Installationsseite. Unter der URL https://hs-example.de/dav/ soll der WebDAV-Dienst erreichbar sein. Dann legen wir eine Datei 'dav.xml' ins Verzeichnis '~/tomcat/conf/Catalina/localhost' ('Catalina' ist der Name der 'Engine', 'localhost' der Name des 'Host' aus der 'server.xml' des Tomcat). Inhalt der Datei:

<syntaxhighlight lang="xml">
<Context docBase="/home/storage/xyz00/users/webdav/data" reloadable="false" />
</syntaxhighlight>

Hier liegen die Dateien in der '/home/storage'-Partition auf der HDD, 'xyz00' steht für den Namen des Webspace, 'webdav' ist der hintere Teil des Users, mit dessen Rechten der Tomcat läuft (Beispiel-User ist also 'xyz00-webdav'). Das Verzeichnis muss angelegt werden, zum Beispiel mit:

<syntaxhighlight lang="bash">
mkdir /home/storage/xyz00/users/webdav/data
</syntaxhighlight>

In dieses 'docBase'-Verzeichnis legen wir ein Verzeichnis 'WEB-INF' mit einer Datei 'web.xml', um die Webapplikation im Tomcat zu konfigurieren.

<syntaxhighlight lang="bash">
mkdir /home/storage/xyz00/users/webdav/data/WEB-INF
</syntaxhighlight>

Inhalt der 'web.xml' in diesem Verzeichnis:

<syntaxhighlight lang="xml" line>
<?xml version="1.0" encoding="UTF-8"?>
<web-app
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
id="WebApp_ID" version="3.0">
<servlet>
<servlet-name>webdav</servlet-name>
<servlet-class>org.apache.catalina.servlets.WebdavServlet</servlet-class>
<init-param>
<param-name>debug</param-name>
<param-value>0</param-value>
</init-param>
<init-param>
<param-name>listings</param-name>
<param-value>true</param-value>
</init-param>
<init-param>
<param-name>readonly</param-name>
<param-value>false</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>webdav</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>
<security-role>
<role-name>webdavaccess</role-name>
</security-role>
<security-constraint>
<web-resource-collection>
<web-resource-name>WebDAV Access</web-resource-name>
<url-pattern>/*</url-pattern>
<http-method>*</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>webdavaccess</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>WebDAV Access</realm-name>
</login-config>
</web-app>
</syntaxhighlight>

In der 'web.xml' werden auch die Zugriffsrechte auf die WebDAV-Freigabe definiert. Hier bekommt die Rolle 'webdavaccess' Vollzugriff. In der Default-Konfiguration des Tomcat werden Accounts und Rollen in der Datei '~/tomcat/conf/tomcat-users.xml' definiert:

<syntaxhighlight lang="xml" line>
<?xml version="1.0" encoding="UTF-8"?>
<tomcat-users xmlns="http://tomcat.apache.org/xml"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://tomcat.apache.org/xml tomcat-users.xsd"
version="1.0">
<role rolename="webdavaccess"/>
<user username="webdavlogin" password="**gutes*Passwort**" roles="webdavaccess"/>
</tomcat-users>
</syntaxhighlight>

Ohne weiteres können Accounts, Passworte und Rollen auch in einer SQL-Datenbank oder in einem LDAP-Verzeichnis abgelegt werden. Dazu ein Verweis auf die Upstream-Dokumentation:
[https://tomcat.apache.org/tomcat-10.1-doc/realm-howto.html Apache Tomcat Realm Configuration How-To]

== Links ==

* [https://tomcat.apache.org/tomcat-10.1-doc/api/org/apache/catalina/servlets/WebdavServlet.html JavaDoc zur Klasse WebdavServlet]

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

WebDAV mit Tomcat

2026-05-14T19:00:49Z

Peh00: Links tomcat.apache.org

= WebDAV mit Tomcat =

Tomcat steht als Software auf jedem Shared Server mit Webspaces der Mitglieder als Software zur Verfügung. Eine einfache WebDAV-Implementierung ist enthalten.

Der Betrieb von Tomcat im Webspace erfordert ein ausreichendes RAM-Kontingent, das zum Webspace zugebucht werden muss.

Die Einrichtung von Apache Tomcat im Webspace ist auf der Seite [[Tomcat Installieren|'Tomcat installieren']] beschrieben.

Sei 'hs-example.de' die Domain, unter der der Tomcat erreichbar ist, wie auf der Installationsseite. Unter der URL https://hs-example.de/dav/ soll der WebDAV-Dienst erreichbar sein. Dann legen wir eine Datei 'dav.xml' ins Verzeichnis '~/tomcat/conf/Catalina/localhost' ('Catalina' ist der Name der 'Engine', 'localhost' der Name des 'Host' aus der 'server.xml' des Tomcat). Inhalt der Datei:

<syntaxhighlight lang="xml">
<Context docBase="/home/storage/xyz00/users/webdav/data" reloadable="false" />
</syntaxhighlight>

Hier liegen die Dateien in der '/home/storage'-Partition auf der HDD, 'xyz00' steht für den Namen des Webspace, 'webdav' ist der hintere Teil des Users, mit dessen Rechten der Tomcat läuft (Beispiel-User ist also 'xyz00-webdav'). Das Verzeichnis muss angelegt werden, zum Beispiel mit:

<syntaxhighlight lang="bash">
mkdir /home/storage/xyz00/users/webdav/data
</syntaxhighlight>

In dieses 'docBase'-Verzeichnis legen wir ein Verzeichnis 'WEB-INF' mit einer Datei 'web.xml', um die Webapplikation im Tomcat zu konfigurieren.

<syntaxhighlight lang="bash">
mkdir /home/storage/xyz00/users/webdav/data/WEB-INF
</syntaxhighlight>

Inhalt der 'web.xml' in diesem Verzeichnis:

<syntaxhighlight lang="xml" line>
<?xml version="1.0" encoding="UTF-8"?>
<web-app
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
id="WebApp_ID" version="3.0">
<servlet>
<servlet-name>webdav</servlet-name>
<servlet-class>org.apache.catalina.servlets.WebdavServlet</servlet-class>
<init-param>
<param-name>debug</param-name>
<param-value>0</param-value>
</init-param>
<init-param>
<param-name>listings</param-name>
<param-value>true</param-value>
</init-param>
<init-param>
<param-name>readonly</param-name>
<param-value>false</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>webdav</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>
<security-role>
<role-name>webdavaccess</role-name>
</security-role>
<security-constraint>
<web-resource-collection>
<web-resource-name>WebDAV Access</web-resource-name>
<url-pattern>/*</url-pattern>
<http-method>*</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>webdavaccess</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>WebDAV Access</realm-name>
</login-config>
</web-app>
</syntaxhighlight>

In der 'web.xml' werden auch die Zugriffsrechte auf die WebDAV-Freigabe definiert. Hier bekommt die Rolle 'webdavaccess' Vollzugriff. In der Defalut-Konfiguration des Tomcat werden Accounts und Rollen in der Datei '~/tomcat/conf/tomcat-users.xml' definiert:

<syntaxhighlight lang="xml" line>
<?xml version="1.0" encoding="UTF-8"?>
<tomcat-users xmlns="http://tomcat.apache.org/xml"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://tomcat.apache.org/xml tomcat-users.xsd"
version="1.0">
<role rolename="webdavaccess"/>
<user username="webdavlogin" password="**gutes*Passwort**" roles="webdavaccess"/>
</tomcat-users>
</syntaxhighlight>

Ohne weiteres können Accounts, Passworte und Rollen auch in einer SQL-Datenbank oder eine LDAP-Verzeichnis abgelegt werden. Dazu ein Verweis auf die Upstream-Dokumentation:
[https://tomcat.apache.org/tomcat-10.1-doc/realm-howto.html Apache Tomcat Realm Configuration How-To]

== Links ==

* [https://tomcat.apache.org/tomcat-10.1-doc/api/org/apache/catalina/servlets/WebdavServlet.html JavaDoc zur Klasse WebdavServlet]

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

WebDAV mit Tomcat

2026-05-14T18:54:06Z

Peh00: Startversion

= WebDAV mit Tomcat =

Tomcat steht als Software auf jedem Shared Server mit Webspaces der Mitglieder als Software zur Verfügung. Eine einfache WebDAV-Implementierung ist enthalten.

Der Betrieb von Tomcat im Webspace erfordert ein ausreichendes RAM-Kontingent, das zum Webspace zugebucht werden muss.

Die Einrichtung von Apache Tomcat im Webspace ist auf der Seite [[Tomcat Installieren|'Tomcat installieren']] beschrieben.

Sei 'hs-example.de' die Domain, unter der der Tomcat erreichbar ist, wie auf der Installationsseite. Unter der URL https://hs-example.de/dav/ soll der WebDAV-Dienst erreichbar sein. Dann legen wir eine Datei 'dav.xml' ins Verzeichnis '~/tomcat/conf/Catalina/localhost' ('Catalina' ist der Name der 'Engine', 'localhost' der Name des 'Host' aus der 'server.xml' des Tomcat). Inhalt der Datei:

<syntaxhighlight lang="xml">
<Context docBase="/home/storage/xyz00/users/webdav/data" reloadable="false" />
</syntaxhighlight>

Hier liegen die Dateien in der '/home/storage'-Partition auf der HDD, 'xyz00' steht für den Namen des Webspace, 'webdav' ist der hintere Teil des Users, mit dessen Rechten der Tomcat läuft (Beispiel-User ist also 'xyz00-webdav'). Das Verzeichnis muss angelegt werden, zum Beispiel mit:

<syntaxhighlight lang="bash">
mkdir /home/storage/xyz00/users/webdav/data
</syntaxhighlight>

In dieses 'docBase'-Verzeichnis legen wir ein Verzeichnis 'WEB-INF' mit einer Datei 'web.xml', um die Webapplikation im Tomcat zu konfigurieren.

<syntaxhighlight lang="bash">
mkdir /home/storage/xyz00/users/webdav/data/WEB-INF
</syntaxhighlight>

Inhalt der 'web.xml' in diesem Verzeichnis:

<syntaxhighlight lang="xml" line>
<?xml version="1.0" encoding="UTF-8"?>
<web-app
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
id="WebApp_ID" version="3.0">
<servlet>
<servlet-name>webdav</servlet-name>
<servlet-class>org.apache.catalina.servlets.WebdavServlet</servlet-class>
<init-param>
<param-name>debug</param-name>
<param-value>0</param-value>
</init-param>
<init-param>
<param-name>listings</param-name>
<param-value>true</param-value>
</init-param>
<init-param>
<param-name>readonly</param-name>
<param-value>false</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>webdav</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>
<security-role>
<role-name>webdavaccess</role-name>
</security-role>
<security-constraint>
<web-resource-collection>
<web-resource-name>WebDAV Access</web-resource-name>
<url-pattern>/*</url-pattern>
<http-method>*</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>webdavaccess</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>WebDAV Access</realm-name>
</login-config>
</web-app>
</syntaxhighlight>

In der 'web.xml' werden auch die Zugriffsrechte auf die WebDAV-Freigabe definiert. Hier bekommt die Rolle 'webdavaccess' Vollzugriff. In der Defalut-Konfiguration des Tomcat werden Accounts und Rollen in der Datei '~/tomcat/conf/tomcat-users.xml' definiert:

<syntaxhighlight lang="xml" line>
<?xml version="1.0" encoding="UTF-8"?>
<tomcat-users xmlns="http://tomcat.apache.org/xml"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://tomcat.apache.org/xml tomcat-users.xsd"
version="1.0">
<role rolename="webdavaccess"/>
<user username="webdavlogin" password="**gutes*Passwort**" roles="webdavaccess"/>
</tomcat-users>
</syntaxhighlight>

Ohne weiteres können Accounts, Passworte und Rollen auch in einer SQL-Datenbank oder eine LDAP-Verzeichnis abgelegt werden. Dazu ein Verweis auf die Upstream-Dokumentation:

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

Kategorie:WebDAV

2026-05-14T18:04:27Z

Peh00: Kategorie WevDAV

= WebDAV =

[https://de.wikipedia.org/wiki/WebDAV WebDAV (Web-based Distributed Authoring and Versioning)] ist eine Erweiterung des HTTP-Protokoll. WebDAV ermöglicht es, eine Verzeichnisstruktur, die auf dem WebDAV-Server liegt, auf Arbeitsplatz-PC einzubinden. Auf diese Weise kann mit den Dateien in der Verzeichnisstruktur direkt gearbeitet werden, nahezu wie mit lokalen Verzeichnissen oder Verzeichnissen im lokalen Netzwerk.

WebDAV ist als Funktionalität in vielen Werkzeugen zur Dateiverwaltung verfügbar. Beispiele sind [[Nextcloud]] oder [[SeedDMS installieren|SeedDMS]].

Wer nur auf der Suche nach einer einfachen WebDAV-Implementierung ist, die im Webspace bei Hostsharing benutzt werden kann, hat findet vielleicht hier eine Lösung:

* [[WebDAV_mit_Tomcat|WebDAV mit Tomcat]]
* [[WebDAV_mit_Sabre|WebDAV mit Sabre]]
* [[WebDAV_mit_RClone|WebDAV mit RClone]]

Spamfilter

2026-02-16T13:57:28Z

Peh00: /* Eingangsserver konfigurieren */

Einrichtung, Konfiguration und Optimierung eines Spamfilters auf den Hostsharing Servern. Der Artikel beschreibt drei alternative Möglichkeiten:

1. Die Nutzung der "xmailin"-Server für eine komplette Domain

2. Die Einrichtung von Spamassassin für das persönliche Postfach

3. Nutzung der Spam-Appliance "SecureMX" für eine komplette Domain

= Alternative 1: Maileingangsserver mit Spamfilter nutzen =

Diese Alternative kann von einer Domain-Administration oder vom "Webmaster on Demand" für eine oder mehrere E-Mail-Domains eingerichtet werden. Ein globaler Sieve-Filter für markiete Spam-Nachrichten ist in der Standard-Konfiguration voreingestellt,
so dass Nachrichten mit Spam-Bewertung in einen vorhandenen Spam-Ordner einsortiert werden.

Seit einigen Jahren betreibt Hostsharing zusätzlich zu den vorkonfigurierte Maileingangsservern einen zweiten Satz von Maileingangsservern, bei denen Spamassassin bereits beim Annehmen einer E-Mail ausgeführt wird. Anfang 2026 ist eine Gruppe von Eingangsserver mit der Software "rspamd" hinzugekommen. Eingehende Nachrichten mit Malware oder sehr hoher Bewertung als Spam werden bereits im SMTP-Dialog abgewiesen. Nachrichten mit einem geringeren Spam-Score werden angenommen und zugestellt. Spamassassin fügt die Bewertung für diese Nachrichten in die Header der Nachricht ein, zum Beispiel:

<syntaxhighlight lang=bash>
X-Spam-Status: Yes, score=11.29
</syntaxhighlight>

Der globale Sieve-Filter schiebt Nachrichten mit der Markierung "X-Spam-Status: Yes" in einen Ordner "Junk", wenn der Ordner vorhanden ist. Viele Mailprogramme legen beim ersten Verbinden mit dem IMAP-Server einen solchen Ordner an. Unser "Roundcube"
unter https://webmail.hostsharing.net ist entsprechend eingerichtet, so dass der Ordner nach einer Nutzung von Webmail vorhanden ist.

== Eingangsserver konfigurieren ==

Die Maileingangsserver mit Rspamd lassen sich pro Domain konfigurieren, indem die MX-Records im DNS-Zonefile gegenüber dem Default-Zonefile angepasst werden.

Im Zonefile entfällt der Platzhalter "{MX_RR}". Stattdessen werden die folgenden MX-Records eingefügt:

<syntaxhighlight lang=bash>
{DOM_HOSTNAME}. IN MX 30 xmailin1.hostsharing.net.
{DOM_HOSTNAME}. IN MX 30 xmailin2.hostsharing.net.
{DOM_HOSTNAME}. IN MX 30 xmailin3.hostsharing.net.
</syntaxhighlight>

Zur Änderung der DNS-Zone siehe: https://www.hostsharing.net/doc/managed-operations-platform/zonefile/
Wer sich die Aktion auf der Shell nicht zutraut, möge bitte den "Webmaster on Demand" beauftragen.

Die Änderung des Zonefile kann für eine Domain "hs-example.de" wie folgt überprüft werden:

<syntaxhighlight lang=bash>
dig +short -t MX hs-example.de @dns1.hostsharing.net
</syntaxhighlight>

Die folgende Ausgabe wird erwartet:

<syntaxhighlight lang=bash>
30 xmailin2.hostsharing.net.
30 xmailin3.hostsharing.net.
30 xmailin1.hostsharing.net.
</syntaxhighlight>

Die Reihenfolge der drei Eingangsserver kann variieren.
Die führende Zahl ist die Priorität im MX-Record (hier der Wert "30").

= Alternative 2: Persönlichen Spamfilter einrichten =

Hier geht es darum, wie Personen mit (grundlegenden) Kenntnissen in der Shell-Bedienung für ihr persönliches Postfach einen Spam-Filter einrichten können. Spamassassin kann für jedes Postfach individuell konfiguriert werden. Für die Einrichtung und Pflege ist Shell-Zugang zur Mailbox erforderlich.

Ein Bayesfilter kann mit den persönlichen Nachrichten angelernt werden. Dazu sind tiefergehende Shell-Kenntnisse erforderlich (Shell-Skript und Einrichtung eines systemd-Timers).

== Spamassassin Konfigurieren ==

Der Spamfilter "Spamassassin" ist bei HS vorinstalliert. Es muss über das Kommando "spamc", das Kommando zur Nutzung des Spamassassin-Daemon, in der Datei ".forward" eines Mail-Users aufgerufen werden:

<syntaxhighlight lang=bash>
"|/usr/bin/spamc -U /var/run/spamd -e /usr/lib/dovecot/deliver"
</syntaxhighlight>

Der Effekt: Spammassassin schreibt seine Testergebnisse in die Headerzeilen jeder E-Mail und leitet die E-Mails weiter an das Programm "deliver" aus dem Dovecot-Paket. Das Sortieren von Spam-EMail in einen Spam-Ordner lässt sich mit Sieve-Filtern umsetzen.

In dieser Variante kann man Spamassassin individuell konfigurieren. Dazu legt man im $HOME des Mailbox-Account ein Verzeichnis "$HOME/.spamassassin" an. Die Konfiguration erfolgt in der Datei "$HOME/.spamassassin/user_prefs".

Konfigurationsbeispiel:

<syntaxhighlight lang=bash>
required_score 4.0
report_safe 0
use_bayes 1
bayes_auto_learn 1
skip_rbl_checks 0
use_razor2 1
use_pyzor 1
</syntaxhighlight>

== Bayesfilter anlernen ==

Wenn der Bayesfilter eingeschaltet ist, macht es Sinn den Filter mit den Befehlen

<syntaxhighlight lang=bash>
sa-learn --spam <platzhalter-spam-nachricht-oder-verzeichnis>
sa-learn --ham <platzhalter-erwünschte-nachricht-oder-verzeichnis>
</syntaxhighlight>

anzulernen. Ein Bash-Skript für das Erlernen von Spam/Nonspam kann wie folgt aussehen:

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

HAM_MIN_AGE_DAYS=5
MAILDIR_HAM=${HOME}/Maildir/cur
TMPDIR=${HOME}/sa-learn-tmp
SPAMFOLDER=Junk
SPAMFOLDER_LEARNED=${SPAMFOLDER}.sa-learned
MAILDIR_SPAM=${HOME}/Maildir/.${SPAMFOLDER}

# Learn spam from MAILDIR_SPAM
mkdir -p ${TMPDIR}/spam
rm -f ${TMPDIR}/spam/*
SPAM_COUNT=0
for DIR in "cur" "new"; do
DIR="${MAILDIR_SPAM}/${DIR}"
cd ${DIR}
# echo "---" DIR ${DIR}
for SPAMFILE in $( ls ); do
# echo " " ${SPAMFILE}
TMPFILE="${TMPDIR}/spam/${SPAMFILE}"
if ! zcat "${SPAMFILE}" > "${TMPFILE}" 2>/dev/null; then
cp "${SPAMFILE}" "${TMPFILE}"
fi
SPAM_COUNT=$((SPAM_COUNT + 1))
done
done
sa-learn --spam ${TMPDIR}/spam/*

# Move processed spam to keep it in another folder
doveadm move -u $(whoami) INBOX.${SPAMFOLDER_LEARNED} mailbox INBOX.${SPAMFOLDER} all 2>/dev/null

# Learn ham from MAILDIR_HAM (> HAM_MIN_AGE_DAYS days; max. 2x spam count)
mkdir -p ${TMPDIR}/ham
rm -f ${TMPDIR}/ham/*
cd ${MAILDIR_HAM}
MAX_HAM=$((SPAM_COUNT * 2))
HAM_COUNT=0
for HAMFILE in $( find . -type f -mtime +${HAM_MIN_AGE_DAYS} -printf '%T@ %p\n' | sort -rn | cut -d' ' -f2- | head -n ${MAX_HAM} ); do
TMPFILE="${TMPDIR}/ham/${HAMFILE}"
if ! zcat "${HAMFILE}" > "${TMPFILE}" 2>/dev/null; then
cp "${HAMFILE}" "${TMPFILE}"
fi
HAM_COUNT=$((HAM_COUNT + 1))
done
sa-learn --ham ${TMPDIR}/ham/*

echo "Training erfolgte mit ${SPAM_COUNT} Spam, ${HAM_COUNT} (max ${MAX_HAM}) Ham Mails."
</syntaxhighlight>

Dabei werden Mails verarbeitet, unabhängig davon, ob sie durch Procmail (unkomprimiert) oder über den Mailclient (komprimiert) verschoben vorliegen.
Für Ham wird ein Teil des Inhalts der Inbox verwendet, wobei die empfohlene Maximalanzahl von zweimal der Spammailanzahl und ein minimales Alter in Tagen gilt. Das Mindestalter garantiert ein inzwischen erfolgtes manuelles Aussortieren des Spams. Der verarbeitete Spam wird anschließend in ein separates Verzeichnis verschoben um den späteren Zugriff auf False Positives zu ermöglichen.

Das Skript wird über einen systemd-Timer täglich ausgeführt, der pro Mailbox eingerichtet werden muss.

= Alternative 3: SecureMX zubuchen =

Über unseren Domain-Anbieter "Partnergate" bietet Hostsharing als dritte Alternative die kommerzielle Spam-Appliance von Cisco an. Das Produkt heißt bei Partnergate "SecureMX": https://www.hostsharing.net/loesungen/email/spam-abwehr/

Die Nutzung von SecureMX ist kostenpflichtig und wird auf Wunsch vom Hostsharing-Service eingerichtet.

Es ist zu beachten, dass bei der Nutzung von SecureMX alle eingehenden E-Mail Nachrichten über Server geleitet werden, die nicht unter der Kontrolle von Hostsharing stehen und proprietäre Software einsetzen. Dieser Sachverhalt muss vom Mitglied ggf. datenschutzrechtlich bewertet werden.

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

Spamfilter

2025-02-07T16:48:49Z

Peh00:

Einrichtung, Konfiguration und Optimierung eines Spamfilters auf den Hostsharing Servern. Der Artikel beschreibt drei alternative Möglichkeiten:

1. Die Einrichtung von Spamassassin für das persönliche Postfach

2. Die Nutzung der "smailin"-Server für eine komplette Domain

3. Nutzung der Spam-Appliance "SecureMX"

= Alternative 1: Persönlichen Spamfilter einrichten =

Hier geht es darum, wie Personen mit (grundlegenden) Kenntnissen in der Shell-Bedienung für ihr persönliches Postfach einen Spam-Filter einrichten können. Spamassassin kann für jedes Postfach individuell konfiguriert werden. Für die Einrichtung und Pflege ist Shell-Zugang zur Mailbox erforderlich.

Ein Bayesfilter kann mit den persönlichen Nachrichten angelernt werden. Dazu sind tiefergehende Shell-Kenntnisse erforderlich (Shell-Skript und Einrichtung eines systemd-Timers).

== Spamassassin Konfigurieren ==

Der Spamfilter "Spamassassin" ist bei HS vorinstalliert und kann wie auf der Seite [[Procmail]] beschrieben für eine Mailbox eingebunden werden.
Alternativ kann "spamc", das Kommando zur Nutzung des Spamassassin-Daemon, auch einfach in der Datei ".forward" eines Mail-Users aufgerufen werden:

<syntaxhighlight lang=bash>
"|/usr/bin/spamc -U /var/run/spamd -e /usr/lib/dovecot/deliver"
</syntaxhighlight>

Der Effekt: Spammassassin schreibt seine Testergebnisse in die Headerzeilen jeder E-Mail und leitet die E-Mails weiter an das Programm "deliver" aus dem Dovecot-Paket. Das Sortieren von Spam-EMail in einen Spam-Ordner lässt sich mit Sieve-Filtern umsetzen.

In dieser Variante kann man Spamassassin individuell konfigurieren. Dazu legt man im $HOME des Mailbox-Account ein Verzeichnis "$HOME/.spamassassin" an. Die Konfiguration erfolgt in der Datei "$HOME/.spamassassin/user_prefs".

Konfigurationsbeispiel:

<syntaxhighlight lang=bash>
required_score 4.0
report_safe 0
use_bayes 1
bayes_auto_learn 1
skip_rbl_checks 0
use_razor2 1
use_pyzor 1
</syntaxhighlight>

== Bayesfilter anlernen ==

Wenn der Bayesfilter eingeschaltet ist, macht es Sinn den Filter mit den Befehlen

<syntaxhighlight lang=bash>
sa-learn --spam <platzhalter-spam-nachricht>
sa-learn --ham <platzhalter-erwünschte-nachricht>
</syntaxhighlight>

anzulernen. Ein Bash-Skript für das Erlernen von Spam/Nonspam kann wie folgt aussehen:

<syntaxhighlight lang=bash>
#!/bin/bash
#
# Learn Spam from Maildir folder Junk/LearnSpam
#
mkdir -p ${HOME}/sa-learn-tmp
cd ${HOME}/Maildir/.Junk.LearnSpam/cur/
for JUNK in $( ls ); do zcat ${JUNK} > ${HOME}/sa-learn-tmp/$( echo ${JUNK} | cut -d'.' -f2 ).eml ; done
cd ${HOME}/
sa-learn --spam ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/Maildir/.Junk.LearnSpam/cur/*
#
# Learn Non-Spam from Maildir folder Junk/LearnHam
#
cd ${HOME}/Maildir/.Junk.LearnHam/cur/
for HAM in $( ls ); do zcat ${HAM} > ${HOME}/sa-learn-tmp/$( echo ${HAM} | cut -d'.' -f2 ).eml ; done
cd ${HOME}/
sa-learn --ham ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/Maildir/.Junk.LearnHam/cur/*
</syntaxhighlight>

Die Empfängerin der Nachrichten / der Empfänger füttert den Lernprozess, indem Spam-Nachrichten in den Ordner "Spam/LearnSpam" verschoben werden und indem gute Nachrichten in den Ordner "Spam/LearnHam" kopiert werden.

Das Skript wird über einen systemd-Timer täglich ausgeführt, der pro Mailbox eingerichtet werden muss.

= Alternative 2: Maileingangsserver mit Spamfilter nutzen =

Diese Alternative kann von einem Domain-Administrator oder vom "Webmaster on Demand" für eine oder mehrere E-Mail-Domains eingerichtet werden. Die einzelnen Nutzer:innen können mit Hilfe des Hostsharing-Webmail einen Filter einrichten, so dass verdächtige Nachrichten in einem Spam-Ordner einsortiert werden.

Seit einigen Jahren betreibt Hostsharing zusätzlich zu den vorkonfigurierte Maileingangsservern einen zweiten Satz von Maileingangsservern, bei denen Spamassassin bereits beim Annehmen einer E-Mail ausgeführt wird. Eingehende Nachrichten mit eindeutiger Bewertung als Spam werden bereits im SMTP-Dialog abgewiesen. Nachrichten mit einem Spam-Score über 5 Punkten werden angenommen und zugestellt. Spamassassin fügt die Bewertung für diese Nachrichten in die Header der Nachricht ein, zum Beispiel:

<syntaxhighlight lang=bash>
X-Spam-Flag: YES
X-Spam-Score: 6.263
X-Spam-Level: ******
</syntaxhighlight>

Anhand dieser Zeilen kann man in Roundcube Filter einrichten, die die Nachrichten beim Eingehen der Nachricht in einen Spam-Ordner mit verdächtigen Nachrichten verschieben (siehe später folgenden Abschnitt).

== Eingangsserver konfigurieren ==

Die Maileingangsserver mit Spamassassin lassen sich pro Domain konfigurieren, indem die MX-Records im DNS-Zonefile gegenüber dem Default-Zonefile angepasst werden.

Im Zonefile entfällt der Platzhalter "{MX_RR}". Stattdessen werden die folgenden MX-Records eingefügt:

<syntaxhighlight lang=bash>
{DOM_HOSTNAME}. IN MX 10 smailin1.hostsharing.net.
{DOM_HOSTNAME}. IN MX 10 smailin2.hostsharing.net.
{DOM_HOSTNAME}. IN MX 10 smailin3.hostsharing.net.
</syntaxhighlight>

Zur Änderung der DNS-Zone siehe: https://www.hostsharing.net/doc/managed-operations-platform/zonefile/
Wer sich die Aktion auf der Shell nicht zutraut, möge bitte den "Webmaster on Demand" beauftragen.

== Spam-Ordner ==

Mit dem folgenden Filter können Nachrichten, die von Spamassassin markiert wurden, automatisch in einen Spam-Ordner verschoben werden.

[[Datei:2025-02-07 Sievefilter-Spam.png|960x480px|gerahmt|links|alternativtext=Screenshot Filterregel zum Spam Aussortieren|Filter in Roundcube einrichten]]

= Alternative 3: SecureMX zubuchen =

Über unseren Domain-Anbieter "Partnergate" bietet Hostsharing als dritte Alternative die kommerzielle Spam-Appliance von Cisco an. Das Produkt heißt bei Partnergate "SecureMX": https://www.hostsharing.net/loesungen/email/spam-abwehr/

Die Nutzung von SecureMX ist kostenpflichtig und wird auf Wunsch vom Hostsharing-Service eingerichtet.

Es ist zu beachten, dass bei der Nutzung von SecureMX alle eingehenden E-Mail Nachrichten über Server geleitet werden, die nicht unter der Kontrolle von Hostsharing stehen und proprietäre Software einsetzen. Dieser Sachverhalt muss vom Mitglied ggf. datenschutzrechtlich bewertet werden.

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

Spamfilter

2025-02-07T16:48:06Z

Peh00: /* Alternative 3: SecureMX zubuchen */

Einrichtung, Konfiguration und Optimierung eines Spamfilters auf den Hostsharing Servern. Der Artikel beschreibt drei Möglichkeiten:

1. Die Einrichtung von Spamassassin für das persönliche Postfach

2. Die Nutzung der "smailin"-Server für eine komplette Domain

3. Nutzung der Spam-Appliance "SecureMX"

= Alternative 1: Persönlichen Spamfilter einrichten =

Hier geht es darum, wie Personen mit (grundlegenden) Kenntnissen in der Shell-Bedienung für ihr persönliches Postfach einen Spam-Filter einrichten können. Spamassassin kann für jedes Postfach individuell konfiguriert werden. Für die Einrichtung und Pflege ist Shell-Zugang zur Mailbox erforderlich.

Ein Bayesfilter kann mit den persönlichen Nachrichten angelernt werden. Dazu sind tiefergehende Shell-Kenntnisse erforderlich (Shell-Skript und Einrichtung eines systemd-Timers).

== Spamassassin Konfigurieren ==

Der Spamfilter "Spamassassin" ist bei HS vorinstalliert und kann wie auf der Seite [[Procmail]] beschrieben für eine Mailbox eingebunden werden.
Alternativ kann "spamc", das Kommando zur Nutzung des Spamassassin-Daemon, auch einfach in der Datei ".forward" eines Mail-Users aufgerufen werden:

<syntaxhighlight lang=bash>
"|/usr/bin/spamc -U /var/run/spamd -e /usr/lib/dovecot/deliver"
</syntaxhighlight>

Der Effekt: Spammassassin schreibt seine Testergebnisse in die Headerzeilen jeder E-Mail und leitet die E-Mails weiter an das Programm "deliver" aus dem Dovecot-Paket. Das Sortieren von Spam-EMail in einen Spam-Ordner lässt sich mit Sieve-Filtern umsetzen.

In dieser Variante kann man Spamassassin individuell konfigurieren. Dazu legt man im $HOME des Mailbox-Account ein Verzeichnis "$HOME/.spamassassin" an. Die Konfiguration erfolgt in der Datei "$HOME/.spamassassin/user_prefs".

Konfigurationsbeispiel:

<syntaxhighlight lang=bash>
required_score 4.0
report_safe 0
use_bayes 1
bayes_auto_learn 1
skip_rbl_checks 0
use_razor2 1
use_pyzor 1
</syntaxhighlight>

== Bayesfilter anlernen ==

Wenn der Bayesfilter eingeschaltet ist, macht es Sinn den Filter mit den Befehlen

<syntaxhighlight lang=bash>
sa-learn --spam <platzhalter-spam-nachricht>
sa-learn --ham <platzhalter-erwünschte-nachricht>
</syntaxhighlight>

anzulernen. Ein Bash-Skript für das Erlernen von Spam/Nonspam kann wie folgt aussehen:

<syntaxhighlight lang=bash>
#!/bin/bash
#
# Learn Spam from Maildir folder Junk/LearnSpam
#
mkdir -p ${HOME}/sa-learn-tmp
cd ${HOME}/Maildir/.Junk.LearnSpam/cur/
for JUNK in $( ls ); do zcat ${JUNK} > ${HOME}/sa-learn-tmp/$( echo ${JUNK} | cut -d'.' -f2 ).eml ; done
cd ${HOME}/
sa-learn --spam ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/Maildir/.Junk.LearnSpam/cur/*
#
# Learn Non-Spam from Maildir folder Junk/LearnHam
#
cd ${HOME}/Maildir/.Junk.LearnHam/cur/
for HAM in $( ls ); do zcat ${HAM} > ${HOME}/sa-learn-tmp/$( echo ${HAM} | cut -d'.' -f2 ).eml ; done
cd ${HOME}/
sa-learn --ham ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/Maildir/.Junk.LearnHam/cur/*
</syntaxhighlight>

Die Empfängerin der Nachrichten / der Empfänger füttert den Lernprozess, indem Spam-Nachrichten in den Ordner "Spam/LearnSpam" verschoben werden und indem gute Nachrichten in den Ordner "Spam/LearnHam" kopiert werden.

Das Skript wird über einen systemd-Timer täglich ausgeführt, der pro Mailbox eingerichtet werden muss.

= Alternative 2: Maileingangsserver mit Spamfilter nutzen =

Diese Alternative kann von einem Domain-Administrator oder vom "Webmaster on Demand" für eine oder mehrere E-Mail-Domains eingerichtet werden. Die einzelnen Nutzer:innen können mit Hilfe des Hostsharing-Webmail einen Filter einrichten, so dass verdächtige Nachrichten in einem Spam-Ordner einsortiert werden.

Seit einigen Jahren betreibt Hostsharing zusätzlich zu den vorkonfigurierte Maileingangsservern einen zweiten Satz von Maileingangsservern, bei denen Spamassassin bereits beim Annehmen einer E-Mail ausgeführt wird. Eingehende Nachrichten mit eindeutiger Bewertung als Spam werden bereits im SMTP-Dialog abgewiesen. Nachrichten mit einem Spam-Score über 5 Punkten werden angenommen und zugestellt. Spamassassin fügt die Bewertung für diese Nachrichten in die Header der Nachricht ein, zum Beispiel:

<syntaxhighlight lang=bash>
X-Spam-Flag: YES
X-Spam-Score: 6.263
X-Spam-Level: ******
</syntaxhighlight>

Anhand dieser Zeilen kann man in Roundcube Filter einrichten, die die Nachrichten beim Eingehen der Nachricht in einen Spam-Ordner mit verdächtigen Nachrichten verschieben (siehe später folgenden Abschnitt).

== Eingangsserver konfigurieren ==

Die Maileingangsserver mit Spamassassin lassen sich pro Domain konfigurieren, indem die MX-Records im DNS-Zonefile gegenüber dem Default-Zonefile angepasst werden.

Im Zonefile entfällt der Platzhalter "{MX_RR}". Stattdessen werden die folgenden MX-Records eingefügt:

<syntaxhighlight lang=bash>
{DOM_HOSTNAME}. IN MX 10 smailin1.hostsharing.net.
{DOM_HOSTNAME}. IN MX 10 smailin2.hostsharing.net.
{DOM_HOSTNAME}. IN MX 10 smailin3.hostsharing.net.
</syntaxhighlight>

Zur Änderung der DNS-Zone siehe: https://www.hostsharing.net/doc/managed-operations-platform/zonefile/
Wer sich die Aktion auf der Shell nicht zutraut, möge bitte den "Webmaster on Demand" beauftragen.

== Spam-Ordner ==

Mit dem folgenden Filter können Nachrichten, die von Spamassassin markiert wurden, automatisch in einen Spam-Ordner verschoben werden.

[[Datei:2025-02-07 Sievefilter-Spam.png|960x480px|gerahmt|links|alternativtext=Screenshot Filterregel zum Spam Aussortieren|Filter in Roundcube einrichten]]

= Alternative 3: SecureMX zubuchen =

Über unseren Domain-Anbieter "Partnergate" bietet Hostsharing als dritte Alternative die kommerzielle Spam-Appliance von Cisco an. Das Produkt heißt bei Partnergate "SecureMX": https://www.hostsharing.net/loesungen/email/spam-abwehr/

Die Nutzung von SecureMX ist kostenpflichtig und wird auf Wunsch vom Hostsharing-Service eingerichtet.

Es ist zu beachten, dass bei der Nutzung von SecureMX alle eingehenden E-Mail Nachrichten über Server geleitet werden, die nicht unter der Kontrolle von Hostsharing stehen und proprietäre Software einsetzen. Dieser Sachverhalt muss vom Mitglied ggf. datenschutzrechtlich bewertet werden.

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

Spamfilter

2025-02-07T16:40:59Z

Peh00: /* Alternative 2: Maileingangsserver mit Spamfilter nutzen */

Einrichtung, Konfiguration und Optimierung eines Spamfilters auf den Hostsharing Servern. Der Artikel beschreibt drei Möglichkeiten:

1. Die Einrichtung von Spamassassin für das persönliche Postfach

2. Die Nutzung der "smailin"-Server für eine komplette Domain

3. Nutzung der Spam-Appliance "SecureMX"

= Alternative 1: Persönlichen Spamfilter einrichten =

Hier geht es darum, wie Personen mit (grundlegenden) Kenntnissen in der Shell-Bedienung für ihr persönliches Postfach einen Spam-Filter einrichten können. Spamassassin kann für jedes Postfach individuell konfiguriert werden. Für die Einrichtung und Pflege ist Shell-Zugang zur Mailbox erforderlich.

Ein Bayesfilter kann mit den persönlichen Nachrichten angelernt werden. Dazu sind tiefergehende Shell-Kenntnisse erforderlich (Shell-Skript und Einrichtung eines systemd-Timers).

== Spamassassin Konfigurieren ==

Der Spamfilter "Spamassassin" ist bei HS vorinstalliert und kann wie auf der Seite [[Procmail]] beschrieben für eine Mailbox eingebunden werden.
Alternativ kann "spamc", das Kommando zur Nutzung des Spamassassin-Daemon, auch einfach in der Datei ".forward" eines Mail-Users aufgerufen werden:

<syntaxhighlight lang=bash>
"|/usr/bin/spamc -U /var/run/spamd -e /usr/lib/dovecot/deliver"
</syntaxhighlight>

Der Effekt: Spammassassin schreibt seine Testergebnisse in die Headerzeilen jeder E-Mail und leitet die E-Mails weiter an das Programm "deliver" aus dem Dovecot-Paket. Das Sortieren von Spam-EMail in einen Spam-Ordner lässt sich mit Sieve-Filtern umsetzen.

In dieser Variante kann man Spamassassin individuell konfigurieren. Dazu legt man im $HOME des Mailbox-Account ein Verzeichnis "$HOME/.spamassassin" an. Die Konfiguration erfolgt in der Datei "$HOME/.spamassassin/user_prefs".

Konfigurationsbeispiel:

<syntaxhighlight lang=bash>
required_score 4.0
report_safe 0
use_bayes 1
bayes_auto_learn 1
skip_rbl_checks 0
use_razor2 1
use_pyzor 1
</syntaxhighlight>

== Bayesfilter anlernen ==

Wenn der Bayesfilter eingeschaltet ist, macht es Sinn den Filter mit den Befehlen

<syntaxhighlight lang=bash>
sa-learn --spam <platzhalter-spam-nachricht>
sa-learn --ham <platzhalter-erwünschte-nachricht>
</syntaxhighlight>

anzulernen. Ein Bash-Skript für das Erlernen von Spam/Nonspam kann wie folgt aussehen:

<syntaxhighlight lang=bash>
#!/bin/bash
#
# Learn Spam from Maildir folder Junk/LearnSpam
#
mkdir -p ${HOME}/sa-learn-tmp
cd ${HOME}/Maildir/.Junk.LearnSpam/cur/
for JUNK in $( ls ); do zcat ${JUNK} > ${HOME}/sa-learn-tmp/$( echo ${JUNK} | cut -d'.' -f2 ).eml ; done
cd ${HOME}/
sa-learn --spam ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/Maildir/.Junk.LearnSpam/cur/*
#
# Learn Non-Spam from Maildir folder Junk/LearnHam
#
cd ${HOME}/Maildir/.Junk.LearnHam/cur/
for HAM in $( ls ); do zcat ${HAM} > ${HOME}/sa-learn-tmp/$( echo ${HAM} | cut -d'.' -f2 ).eml ; done
cd ${HOME}/
sa-learn --ham ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/Maildir/.Junk.LearnHam/cur/*
</syntaxhighlight>

Die Empfängerin der Nachrichten / der Empfänger füttert den Lernprozess, indem Spam-Nachrichten in den Ordner "Spam/LearnSpam" verschoben werden und indem gute Nachrichten in den Ordner "Spam/LearnHam" kopiert werden.

Das Skript wird über einen systemd-Timer täglich ausgeführt, der pro Mailbox eingerichtet werden muss.

= Alternative 2: Maileingangsserver mit Spamfilter nutzen =

Diese Alternative kann von einem Domain-Administrator oder vom "Webmaster on Demand" für eine oder mehrere E-Mail-Domains eingerichtet werden. Die einzelnen Nutzer:innen können mit Hilfe des Hostsharing-Webmail einen Filter einrichten, so dass verdächtige Nachrichten in einem Spam-Ordner einsortiert werden.

Seit einigen Jahren betreibt Hostsharing zusätzlich zu den vorkonfigurierte Maileingangsservern einen zweiten Satz von Maileingangsservern, bei denen Spamassassin bereits beim Annehmen einer E-Mail ausgeführt wird. Eingehende Nachrichten mit eindeutiger Bewertung als Spam werden bereits im SMTP-Dialog abgewiesen. Nachrichten mit einem Spam-Score über 5 Punkten werden angenommen und zugestellt. Spamassassin fügt die Bewertung für diese Nachrichten in die Header der Nachricht ein, zum Beispiel:

<syntaxhighlight lang=bash>
X-Spam-Flag: YES
X-Spam-Score: 6.263
X-Spam-Level: ******
</syntaxhighlight>

Anhand dieser Zeilen kann man in Roundcube Filter einrichten, die die Nachrichten beim Eingehen der Nachricht in einen Spam-Ordner mit verdächtigen Nachrichten verschieben (siehe später folgenden Abschnitt).

== Eingangsserver konfigurieren ==

Die Maileingangsserver mit Spamassassin lassen sich pro Domain konfigurieren, indem die MX-Records im DNS-Zonefile gegenüber dem Default-Zonefile angepasst werden.

Im Zonefile entfällt der Platzhalter "{MX_RR}". Stattdessen werden die folgenden MX-Records eingefügt:

<syntaxhighlight lang=bash>
{DOM_HOSTNAME}. IN MX 10 smailin1.hostsharing.net.
{DOM_HOSTNAME}. IN MX 10 smailin2.hostsharing.net.
{DOM_HOSTNAME}. IN MX 10 smailin3.hostsharing.net.
</syntaxhighlight>

Zur Änderung der DNS-Zone siehe: https://www.hostsharing.net/doc/managed-operations-platform/zonefile/
Wer sich die Aktion auf der Shell nicht zutraut, möge bitte den "Webmaster on Demand" beauftragen.

== Spam-Ordner ==

Mit dem folgenden Filter können Nachrichten, die von Spamassassin markiert wurden, automatisch in einen Spam-Ordner verschoben werden.

[[Datei:2025-02-07 Sievefilter-Spam.png|960x480px|gerahmt|links|alternativtext=Screenshot Filterregel zum Spam Aussortieren|Filter in Roundcube einrichten]]

= Alternative 3: SecureMX zubuchen =

Über unseren Domain-Anbieter "Partnergate" bietet Hostsharing als dritte Alternative die kommerzielle Spam-Appliance von Cisco an. Das Produkt heißt bei Partnergate "SecureMX": https://www.hostsharing.net/loesungen/email/spam-abwehr/

Die Nutzung von SecureMX ist kostenpflichtig und wird auf Wunsch von Service eingerichtet.

Es ist zu beachten, dass bei der Nutzung von SecureMX alle eingehenden E-Mail Nachrichten über Server geleitet werden, die nicht unter der Kontrolle von Hostsharing stehen und proprietäre Software einsetzen. Dieser Sachverhalt muss vom Mitglied ggf. datenschutzrechtlich bewertet werden.

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

Spamfilter

2025-02-07T16:36:30Z

Peh00: /* Bayesfilter anlernen */

Einrichtung, Konfiguration und Optimierung eines Spamfilters auf den Hostsharing Servern. Der Artikel beschreibt drei Möglichkeiten:

1. Die Einrichtung von Spamassassin für das persönliche Postfach

2. Die Nutzung der "smailin"-Server für eine komplette Domain

3. Nutzung der Spam-Appliance "SecureMX"

= Alternative 1: Persönlichen Spamfilter einrichten =

Hier geht es darum, wie Personen mit (grundlegenden) Kenntnissen in der Shell-Bedienung für ihr persönliches Postfach einen Spam-Filter einrichten können. Spamassassin kann für jedes Postfach individuell konfiguriert werden. Für die Einrichtung und Pflege ist Shell-Zugang zur Mailbox erforderlich.

Ein Bayesfilter kann mit den persönlichen Nachrichten angelernt werden. Dazu sind tiefergehende Shell-Kenntnisse erforderlich (Shell-Skript und Einrichtung eines systemd-Timers).

== Spamassassin Konfigurieren ==

Der Spamfilter "Spamassassin" ist bei HS vorinstalliert und kann wie auf der Seite [[Procmail]] beschrieben für eine Mailbox eingebunden werden.
Alternativ kann "spamc", das Kommando zur Nutzung des Spamassassin-Daemon, auch einfach in der Datei ".forward" eines Mail-Users aufgerufen werden:

<syntaxhighlight lang=bash>
"|/usr/bin/spamc -U /var/run/spamd -e /usr/lib/dovecot/deliver"
</syntaxhighlight>

Der Effekt: Spammassassin schreibt seine Testergebnisse in die Headerzeilen jeder E-Mail und leitet die E-Mails weiter an das Programm "deliver" aus dem Dovecot-Paket. Das Sortieren von Spam-EMail in einen Spam-Ordner lässt sich mit Sieve-Filtern umsetzen.

In dieser Variante kann man Spamassassin individuell konfigurieren. Dazu legt man im $HOME des Mailbox-Account ein Verzeichnis "$HOME/.spamassassin" an. Die Konfiguration erfolgt in der Datei "$HOME/.spamassassin/user_prefs".

Konfigurationsbeispiel:

<syntaxhighlight lang=bash>
required_score 4.0
report_safe 0
use_bayes 1
bayes_auto_learn 1
skip_rbl_checks 0
use_razor2 1
use_pyzor 1
</syntaxhighlight>

== Bayesfilter anlernen ==

Wenn der Bayesfilter eingeschaltet ist, macht es Sinn den Filter mit den Befehlen

<syntaxhighlight lang=bash>
sa-learn --spam <platzhalter-spam-nachricht>
sa-learn --ham <platzhalter-erwünschte-nachricht>
</syntaxhighlight>

anzulernen. Ein Bash-Skript für das Erlernen von Spam/Nonspam kann wie folgt aussehen:

<syntaxhighlight lang=bash>
#!/bin/bash
#
# Learn Spam from Maildir folder Junk/LearnSpam
#
mkdir -p ${HOME}/sa-learn-tmp
cd ${HOME}/Maildir/.Junk.LearnSpam/cur/
for JUNK in $( ls ); do zcat ${JUNK} > ${HOME}/sa-learn-tmp/$( echo ${JUNK} | cut -d'.' -f2 ).eml ; done
cd ${HOME}/
sa-learn --spam ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/Maildir/.Junk.LearnSpam/cur/*
#
# Learn Non-Spam from Maildir folder Junk/LearnHam
#
cd ${HOME}/Maildir/.Junk.LearnHam/cur/
for HAM in $( ls ); do zcat ${HAM} > ${HOME}/sa-learn-tmp/$( echo ${HAM} | cut -d'.' -f2 ).eml ; done
cd ${HOME}/
sa-learn --ham ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/Maildir/.Junk.LearnHam/cur/*
</syntaxhighlight>

Die Empfängerin der Nachrichten / der Empfänger füttert den Lernprozess, indem Spam-Nachrichten in den Ordner "Spam/LearnSpam" verschoben werden und indem gute Nachrichten in den Ordner "Spam/LearnHam" kopiert werden.

Das Skript wird über einen systemd-Timer täglich ausgeführt, der pro Mailbox eingerichtet werden muss.

= Alternative 2: Maileingangsserver mit Spamfilter nutzen =

Diese Alternative kann von einem Domain-Administrator oder vom "Webmaster on Demand" für eine oder mehrere E-Mail-Domains eingerichtet werden. Die einzelnen Nutzer:innen können mit Hilfe des Hostsharing-Webmail einen Filter einrichten, so dass verdächtige Nachrichten in einem Spam-Ordner einsortiert werden.

Zusätzlich zu den vorkonfigurierte Maileingangsservern betreibt Hostsharing seit einigen Jahren einen zweiten Satz von Maileingangsservern, bei denen Spamassassin bereits beim Annehmen einer E-Mail ausgeführt wird. Eingehende Nachrichten mit eindeutiger Bewertung als Spam werden bereits im SMTP-Dialog abgewiesen. Nachrichten mit einem Spam-Score über 5 Punkten werden angenommen und zugestellt. Spamassassin fügt die Bewertung für diese Nachrichten in die Header der Nachricht ein, zum Beispiel:

<syntaxhighlight lang=bash>
X-Spam-Flag: YES
X-Spam-Score: 6.263
X-Spam-Level: ******
</syntaxhighlight>

Anhand dieser Zeilen kann man in Roundcube Filter einrichten, die die Nachrichten beim Eingehen der Nachricht in einen Spam-Ordner mit verdächtigen Nachrichten verschieben (siehe später folgenden Abschnitt).

== Eingangsserver konfigurieren ==

Die Maileingangsserver mit Spamassassin lassen sich pro Domain konfigurieren, indem die MX-Records im DNS-Zonefile gegenüber dem Default-Zonefile angepasst werden.

Im Zonefile entfällt der Platzhalter "{MX_RR}". Stattdessen werden die folgenden MX-Records eingefügt:

<syntaxhighlight lang=bash>
{DOM_HOSTNAME}. IN MX 10 smailin1.hostsharing.net.
{DOM_HOSTNAME}. IN MX 10 smailin2.hostsharing.net.
{DOM_HOSTNAME}. IN MX 10 smailin3.hostsharing.net.
</syntaxhighlight>

Zur Änderung der DNS-Zone siehe: https://www.hostsharing.net/doc/managed-operations-platform/zonefile/
Wer sich die Aktion auf der Shell nicht zutraut, möge bitte den "Webmaster on Demand" beauftragen.

== Spam-Ordner ==

Mit dem folgenden Filter können Nachrichten, die von Spamassassin markiert wurden, automatisch in einen Spam-Ordner verschoben werden.

[[Datei:2025-02-07 Sievefilter-Spam.png|960x480px|gerahmt|links|alternativtext=Screenshot Filterregel zum Spam Aussortieren|Filter in Roundcube einrichten]]

= Alternative 3: SecureMX zubuchen =

Über unseren Domain-Anbieter "Partnergate" bietet Hostsharing als dritte Alternative die kommerzielle Spam-Appliance von Cisco an. Das Produkt heißt bei Partnergate "SecureMX": https://www.hostsharing.net/loesungen/email/spam-abwehr/

Die Nutzung von SecureMX ist kostenpflichtig und wird auf Wunsch von Service eingerichtet.

Es ist zu beachten, dass bei der Nutzung von SecureMX alle eingehenden E-Mail Nachrichten über Server geleitet werden, die nicht unter der Kontrolle von Hostsharing stehen und proprietäre Software einsetzen. Dieser Sachverhalt muss vom Mitglied ggf. datenschutzrechtlich bewertet werden.

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

Spamfilter

2025-02-07T15:25:58Z

Peh00: /* Alternative 2: Maileingangsserver mit Spamfilter nutzen */

Einrichtung, Konfiguration und Optimierung eines Spamfilters auf den Hostsharing Servern. Der Artikel beschreibt drei Möglichkeiten:

1. Die Einrichtung von Spamassassin für das persönliche Postfach

2. Die Nutzung der "smailin"-Server für eine komplette Domain

3. Nutzung der Spam-Appliance "SecureMX"

= Alternative 1: Persönlichen Spamfilter einrichten =

Hier geht es darum, wie Personen mit (grundlegenden) Kenntnissen in der Shell-Bedienung für ihr persönliches Postfach einen Spam-Filter einrichten können. Spamassassin kann für jedes Postfach individuell konfiguriert werden. Für die Einrichtung und Pflege ist Shell-Zugang zur Mailbox erforderlich.

Ein Bayesfilter kann mit den persönlichen Nachrichten angelernt werden. Dazu sind tiefergehende Shell-Kenntnisse erforderlich (Shell-Skript und Einrichtung eines systemd-Timers).

== Spamassassin Konfigurieren ==

Der Spamfilter "Spamassassin" ist bei HS vorinstalliert und kann wie auf der Seite [[Procmail]] beschrieben für eine Mailbox eingebunden werden.
Alternativ kann "spamc", das Kommando zur Nutzung des Spamassassin-Daemon, auch einfach in der Datei ".forward" eines Mail-Users aufgerufen werden:

<syntaxhighlight lang=bash>
"|/usr/bin/spamc -U /var/run/spamd -e /usr/lib/dovecot/deliver"
</syntaxhighlight>

Der Effekt: Spammassassin schreibt seine Testergebnisse in die Headerzeilen jeder E-Mail und leitet die E-Mails weiter an das Programm "deliver" aus dem Dovecot-Paket. Das Sortieren von Spam-EMail in einen Spam-Ordner lässt sich mit Sieve-Filtern umsetzen.

In dieser Variante kann man Spamassassin individuell konfigurieren. Dazu legt man im $HOME des Mailbox-Account ein Verzeichnis "$HOME/.spamassassin" an. Die Konfiguration erfolgt in der Datei "$HOME/.spamassassin/user_prefs".

Konfigurationsbeispiel:

<syntaxhighlight lang=bash>
required_score 4.0
report_safe 0
use_bayes 1
bayes_auto_learn 1
skip_rbl_checks 0
use_razor2 1
use_pyzor 1
</syntaxhighlight>

== Bayesfilter anlernen ==

Wenn der Bayesfilter eingeschaltet ist, macht es Sinn den Filter mit den Befehlen

<syntaxhighlight lang=bash>
sa-learn --spam <platzhalter-spam-nachricht>
sa-learn --ham <platzhalter-erwünschte-nachricht>
</syntaxhighlight>

anzulernen. Ein Bash-Skript für das Erlernen von Spam/Nonspam kann wie folgt aussehen:

<syntaxhighlight lang=bash>
!/bin/bash
#
# Learn Spam from Maildir folder Junk/LearnSpam
#
mkdir -p ${HOME}/sa-learn-tmp
cd ${HOME}/Maildir/.Junk.LearnSpam/cur/
for JUNK in $( ls ); do zcat ${JUNK} > ${HOME}/sa-learn-tmp/$( echo ${JUNK} | cut -d'.' -f2 ).eml ; done
cd ${HOME}/
sa-learn --spam ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/Maildir/.Junk.LearnSpam/cur/*
#
# Learn Non-Spam from Maildir folder Junk/LearnHam
#
cd ${HOME}/Maildir/.Junk.LearnHam/cur/
for HAM in $( ls ); do zcat ${HAM} > ${HOME}/sa-learn-tmp/$( echo ${HAM} | cut -d'.' -f2 ).eml ; done
cd ${HOME}/
sa-learn --ham ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/Maildir/.Junk.LearnHam/cur/*
</syntaxhighlight>

Die Empfängerin der Nachrichten / der Empfänger füttert den Lernprozess, indem Spam-Nachrichten in den Ordner "Spam/LearnSpam" verschoben werden und indem gute Nachrichten in den Ordner "Spam/LearnHam" kopiert werden.

Das Skript wird über einen systemd-Timer täglich ausgeführt, der pro Mailbox eingerichtet werden muss.

= Alternative 2: Maileingangsserver mit Spamfilter nutzen =

Diese Alternative kann von einem Domain-Administrator oder vom "Webmaster on Demand" für eine oder mehrere E-Mail-Domains eingerichtet werden. Die einzelnen Nutzer:innen können mit Hilfe des Hostsharing-Webmail einen Filter einrichten, so dass verdächtige Nachrichten in einem Spam-Ordner einsortiert werden.

Zusätzlich zu den vorkonfigurierte Maileingangsservern betreibt Hostsharing seit einigen Jahren einen zweiten Satz von Maileingangsservern, bei denen Spamassassin bereits beim Annehmen einer E-Mail ausgeführt wird. Eingehende Nachrichten mit eindeutiger Bewertung als Spam werden bereits im SMTP-Dialog abgewiesen. Nachrichten mit einem Spam-Score über 5 Punkten werden angenommen und zugestellt. Spamassassin fügt die Bewertung für diese Nachrichten in die Header der Nachricht ein, zum Beispiel:

<syntaxhighlight lang=bash>
X-Spam-Flag: YES
X-Spam-Score: 6.263
X-Spam-Level: ******
</syntaxhighlight>

Anhand dieser Zeilen kann man in Roundcube Filter einrichten, die die Nachrichten beim Eingehen der Nachricht in einen Spam-Ordner mit verdächtigen Nachrichten verschieben (siehe später folgenden Abschnitt).

== Eingangsserver konfigurieren ==

Die Maileingangsserver mit Spamassassin lassen sich pro Domain konfigurieren, indem die MX-Records im DNS-Zonefile gegenüber dem Default-Zonefile angepasst werden.

Im Zonefile entfällt der Platzhalter "{MX_RR}". Stattdessen werden die folgenden MX-Records eingefügt:

<syntaxhighlight lang=bash>
{DOM_HOSTNAME}. IN MX 10 smailin1.hostsharing.net.
{DOM_HOSTNAME}. IN MX 10 smailin2.hostsharing.net.
{DOM_HOSTNAME}. IN MX 10 smailin3.hostsharing.net.
</syntaxhighlight>

Zur Änderung der DNS-Zone siehe: https://www.hostsharing.net/doc/managed-operations-platform/zonefile/
Wer sich die Aktion auf der Shell nicht zutraut, möge bitte den "Webmaster on Demand" beauftragen.

== Spam-Ordner ==

Mit dem folgenden Filter können Nachrichten, die von Spamassassin markiert wurden, automatisch in einen Spam-Ordner verschoben werden.

[[Datei:2025-02-07 Sievefilter-Spam.png|960x480px|gerahmt|links|alternativtext=Screenshot Filterregel zum Spam Aussortieren|Filter in Roundcube einrichten]]

= Alternative 3: SecureMX zubuchen =

Über unseren Domain-Anbieter "Partnergate" bietet Hostsharing als dritte Alternative die kommerzielle Spam-Appliance von Cisco an. Das Produkt heißt bei Partnergate "SecureMX": https://www.hostsharing.net/loesungen/email/spam-abwehr/

Die Nutzung von SecureMX ist kostenpflichtig und wird auf Wunsch von Service eingerichtet.

Es ist zu beachten, dass bei der Nutzung von SecureMX alle eingehenden E-Mail Nachrichten über Server geleitet werden, die nicht unter der Kontrolle von Hostsharing stehen und proprietäre Software einsetzen. Dieser Sachverhalt muss vom Mitglied ggf. datenschutzrechtlich bewertet werden.

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

Spamfilter

2025-02-07T15:16:19Z

Peh00: /* Alternative 1: Persönlichen Spamfilter einrichten */

Einrichtung, Konfiguration und Optimierung eines Spamfilters auf den Hostsharing Servern. Der Artikel beschreibt drei Möglichkeiten:

1. Die Einrichtung von Spamassassin für das persönliche Postfach

2. Die Nutzung der "smailin"-Server für eine komplette Domain

3. Nutzung der Spam-Appliance "SecureMX"

= Alternative 1: Persönlichen Spamfilter einrichten =

Hier geht es darum, wie Personen mit (grundlegenden) Kenntnissen in der Shell-Bedienung für ihr persönliches Postfach einen Spam-Filter einrichten können. Spamassassin kann für jedes Postfach individuell konfiguriert werden. Für die Einrichtung und Pflege ist Shell-Zugang zur Mailbox erforderlich.

Ein Bayesfilter kann mit den persönlichen Nachrichten angelernt werden. Dazu sind tiefergehende Shell-Kenntnisse erforderlich (Shell-Skript und Einrichtung eines systemd-Timers).

== Spamassassin Konfigurieren ==

Der Spamfilter "Spamassassin" ist bei HS vorinstalliert und kann wie auf der Seite [[Procmail]] beschrieben für eine Mailbox eingebunden werden.
Alternativ kann "spamc", das Kommando zur Nutzung des Spamassassin-Daemon, auch einfach in der Datei ".forward" eines Mail-Users aufgerufen werden:

<syntaxhighlight lang=bash>
"|/usr/bin/spamc -U /var/run/spamd -e /usr/lib/dovecot/deliver"
</syntaxhighlight>

Der Effekt: Spammassassin schreibt seine Testergebnisse in die Headerzeilen jeder E-Mail und leitet die E-Mails weiter an das Programm "deliver" aus dem Dovecot-Paket. Das Sortieren von Spam-EMail in einen Spam-Ordner lässt sich mit Sieve-Filtern umsetzen.

In dieser Variante kann man Spamassassin individuell konfigurieren. Dazu legt man im $HOME des Mailbox-Account ein Verzeichnis "$HOME/.spamassassin" an. Die Konfiguration erfolgt in der Datei "$HOME/.spamassassin/user_prefs".

Konfigurationsbeispiel:

<syntaxhighlight lang=bash>
required_score 4.0
report_safe 0
use_bayes 1
bayes_auto_learn 1
skip_rbl_checks 0
use_razor2 1
use_pyzor 1
</syntaxhighlight>

== Bayesfilter anlernen ==

Wenn der Bayesfilter eingeschaltet ist, macht es Sinn den Filter mit den Befehlen

<syntaxhighlight lang=bash>
sa-learn --spam <platzhalter-spam-nachricht>
sa-learn --ham <platzhalter-erwünschte-nachricht>
</syntaxhighlight>

anzulernen. Ein Bash-Skript für das Erlernen von Spam/Nonspam kann wie folgt aussehen:

<syntaxhighlight lang=bash>
!/bin/bash
#
# Learn Spam from Maildir folder Junk/LearnSpam
#
mkdir -p ${HOME}/sa-learn-tmp
cd ${HOME}/Maildir/.Junk.LearnSpam/cur/
for JUNK in $( ls ); do zcat ${JUNK} > ${HOME}/sa-learn-tmp/$( echo ${JUNK} | cut -d'.' -f2 ).eml ; done
cd ${HOME}/
sa-learn --spam ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/Maildir/.Junk.LearnSpam/cur/*
#
# Learn Non-Spam from Maildir folder Junk/LearnHam
#
cd ${HOME}/Maildir/.Junk.LearnHam/cur/
for HAM in $( ls ); do zcat ${HAM} > ${HOME}/sa-learn-tmp/$( echo ${HAM} | cut -d'.' -f2 ).eml ; done
cd ${HOME}/
sa-learn --ham ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/Maildir/.Junk.LearnHam/cur/*
</syntaxhighlight>

Die Empfängerin der Nachrichten / der Empfänger füttert den Lernprozess, indem Spam-Nachrichten in den Ordner "Spam/LearnSpam" verschoben werden und indem gute Nachrichten in den Ordner "Spam/LearnHam" kopiert werden.

Das Skript wird über einen systemd-Timer täglich ausgeführt, der pro Mailbox eingerichtet werden muss.

= Alternative 2: Maileingangsserver mit Spamfilter nutzen =

Zusätzlich zu den vorkonfigurierte Maileingangsservern betreibt Hostsharing seit einigen Jahren einen zweiten Satz von Maileingangsservern, bei denen Spamassassin bereits beim Annehmen einer E-Mail ausgeführt wird. Eingehende Nachrichten mit eindeutiger Bewertung als Spam werden bereits im SMTP-Dialog abgewiesen. Nachrichten mit einem Spam-Score über 5 Punkten werden angenommen und zugestellt. Spamassassin für die Bewertung für diese Nachrichten in die Header der Nachricht ein, zum Beispiel:

<syntaxhighlight lang=bash>
X-Spam-Flag: YES
X-Spam-Score: 6.263
X-Spam-Level: ******
</syntaxhighlight>

Anhand dieser Zeilen kann man in Roundcube Filter einrichten, die die Nachrichten beim Eintreffen der Nachricht in einen Spam-Ordner mit verdächtigen Nachrichten verschieben (siehe später folgenden Abschnitt).

== Eingangsserver konfigurieren ==

Die Maileingangsserver mit Spamassassin lassen sich pro Domain konfigurieren, indem die MX-Records im DNS-Zonefile gegenüber dem Default-Zonefile angepasst werden.

Im Zonefile entfällt der Platzhalter "{MX_RR}". Stattdessen werden die folgenden MX-Records eingefügt:

<syntaxhighlight lang=bash>
{DOM_HOSTNAME}. IN MX 10 smailin1.hostsharing.net.
{DOM_HOSTNAME}. IN MX 10 smailin2.hostsharing.net.
{DOM_HOSTNAME}. IN MX 10 smailin3.hostsharing.net.
</syntaxhighlight>

Zur Änderung der DNS-Zone siehe: https://www.hostsharing.net/doc/managed-operations-platform/zonefile/
Wer sich die Aktion auf der Shell nicht zutraut, möge bitte den "Webmaster on Demand" beauftragen.

== Spam-Ordner ==

Mit dem folgenden Filter können Nachrichten, die von Spamassassin markiert wurden, automatisch in einen Spam-Ordner verschoben werden.

[[Datei:2025-02-07 Sievefilter-Spam.png|960x480px|gerahmt|links|alternativtext=Screenshot Filterregel zum Spam Aussortieren|Filter in Roundcube einrichten]]

= Alternative 3: SecureMX zubuchen =

Über unseren Domain-Anbieter "Partnergate" bietet Hostsharing als dritte Alternative die kommerzielle Spam-Appliance von Cisco an. Das Produkt heißt bei Partnergate "SecureMX": https://www.hostsharing.net/loesungen/email/spam-abwehr/

Die Nutzung von SecureMX ist kostenpflichtig und wird auf Wunsch von Service eingerichtet.

Es ist zu beachten, dass bei der Nutzung von SecureMX alle eingehenden E-Mail Nachrichten über Server geleitet werden, die nicht unter der Kontrolle von Hostsharing stehen und proprietäre Software einsetzen. Dieser Sachverhalt muss vom Mitglied ggf. datenschutzrechtlich bewertet werden.

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

Spamfilter

2025-02-07T15:15:53Z

Peh00: /* Alternative 1: Persönlichen Spamfilter einrichten */

Einrichtung, Konfiguration und Optimierung eines Spamfilters auf den Hostsharing Servern. Der Artikel beschreibt drei Möglichkeiten:

1. Die Einrichtung von Spamassassin für das persönliche Postfach

2. Die Nutzung der "smailin"-Server für eine komplette Domain

3. Nutzung der Spam-Appliance "SecureMX"

= Alternative 1: Persönlichen Spamfilter einrichten =

Hier geht es darum, wie Personen mit (grundlegenden) Kenntnissen in der Shell-Bedienung für ihr persönliches Postfach einen Spam-Filter einrichten können. Spamassassin kann für jedes Postfach individuell konfiguriert werden. Für die Einrichtung und Pflege ist Shell-Zugang zur Mailbox erforderlich.

Ein Bayesfilter kann mit den persönlichen Nachrichten angelernt werden. Dazu sind tiefergehende Shell-Kenntnisse erforderlich (Shell-Skript und Einrichtung eine systemd-Timers).

== Spamassassin Konfigurieren ==

Der Spamfilter "Spamassassin" ist bei HS vorinstalliert und kann wie auf der Seite [[Procmail]] beschrieben für eine Mailbox eingebunden werden.
Alternativ kann "spamc", das Kommando zur Nutzung des Spamassassin-Daemon, auch einfach in der Datei ".forward" eines Mail-Users aufgerufen werden:

<syntaxhighlight lang=bash>
"|/usr/bin/spamc -U /var/run/spamd -e /usr/lib/dovecot/deliver"
</syntaxhighlight>

Der Effekt: Spammassassin schreibt seine Testergebnisse in die Headerzeilen jeder E-Mail und leitet die E-Mails weiter an das Programm "deliver" aus dem Dovecot-Paket. Das Sortieren von Spam-EMail in einen Spam-Ordner lässt sich mit Sieve-Filtern umsetzen.

In dieser Variante kann man Spamassassin individuell konfigurieren. Dazu legt man im $HOME des Mailbox-Account ein Verzeichnis "$HOME/.spamassassin" an. Die Konfiguration erfolgt in der Datei "$HOME/.spamassassin/user_prefs".

Konfigurationsbeispiel:

<syntaxhighlight lang=bash>
required_score 4.0
report_safe 0
use_bayes 1
bayes_auto_learn 1
skip_rbl_checks 0
use_razor2 1
use_pyzor 1
</syntaxhighlight>

== Bayesfilter anlernen ==

Wenn der Bayesfilter eingeschaltet ist, macht es Sinn den Filter mit den Befehlen

<syntaxhighlight lang=bash>
sa-learn --spam <platzhalter-spam-nachricht>
sa-learn --ham <platzhalter-erwünschte-nachricht>
</syntaxhighlight>

anzulernen. Ein Bash-Skript für das Erlernen von Spam/Nonspam kann wie folgt aussehen:

<syntaxhighlight lang=bash>
!/bin/bash
#
# Learn Spam from Maildir folder Junk/LearnSpam
#
mkdir -p ${HOME}/sa-learn-tmp
cd ${HOME}/Maildir/.Junk.LearnSpam/cur/
for JUNK in $( ls ); do zcat ${JUNK} > ${HOME}/sa-learn-tmp/$( echo ${JUNK} | cut -d'.' -f2 ).eml ; done
cd ${HOME}/
sa-learn --spam ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/Maildir/.Junk.LearnSpam/cur/*
#
# Learn Non-Spam from Maildir folder Junk/LearnHam
#
cd ${HOME}/Maildir/.Junk.LearnHam/cur/
for HAM in $( ls ); do zcat ${HAM} > ${HOME}/sa-learn-tmp/$( echo ${HAM} | cut -d'.' -f2 ).eml ; done
cd ${HOME}/
sa-learn --ham ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/Maildir/.Junk.LearnHam/cur/*
</syntaxhighlight>

Die Empfängerin der Nachrichten / der Empfänger füttert den Lernprozess, indem Spam-Nachrichten in den Ordner "Spam/LearnSpam" verschoben werden und indem gute Nachrichten in den Ordner "Spam/LearnHam" kopiert werden.

Das Skript wird über einen systemd-Timer täglich ausgeführt, der pro Mailbox eingerichtet werden muss.

= Alternative 2: Maileingangsserver mit Spamfilter nutzen =

Zusätzlich zu den vorkonfigurierte Maileingangsservern betreibt Hostsharing seit einigen Jahren einen zweiten Satz von Maileingangsservern, bei denen Spamassassin bereits beim Annehmen einer E-Mail ausgeführt wird. Eingehende Nachrichten mit eindeutiger Bewertung als Spam werden bereits im SMTP-Dialog abgewiesen. Nachrichten mit einem Spam-Score über 5 Punkten werden angenommen und zugestellt. Spamassassin für die Bewertung für diese Nachrichten in die Header der Nachricht ein, zum Beispiel:

<syntaxhighlight lang=bash>
X-Spam-Flag: YES
X-Spam-Score: 6.263
X-Spam-Level: ******
</syntaxhighlight>

Anhand dieser Zeilen kann man in Roundcube Filter einrichten, die die Nachrichten beim Eintreffen der Nachricht in einen Spam-Ordner mit verdächtigen Nachrichten verschieben (siehe später folgenden Abschnitt).

== Eingangsserver konfigurieren ==

Die Maileingangsserver mit Spamassassin lassen sich pro Domain konfigurieren, indem die MX-Records im DNS-Zonefile gegenüber dem Default-Zonefile angepasst werden.

Im Zonefile entfällt der Platzhalter "{MX_RR}". Stattdessen werden die folgenden MX-Records eingefügt:

<syntaxhighlight lang=bash>
{DOM_HOSTNAME}. IN MX 10 smailin1.hostsharing.net.
{DOM_HOSTNAME}. IN MX 10 smailin2.hostsharing.net.
{DOM_HOSTNAME}. IN MX 10 smailin3.hostsharing.net.
</syntaxhighlight>

Zur Änderung der DNS-Zone siehe: https://www.hostsharing.net/doc/managed-operations-platform/zonefile/
Wer sich die Aktion auf der Shell nicht zutraut, möge bitte den "Webmaster on Demand" beauftragen.

== Spam-Ordner ==

Mit dem folgenden Filter können Nachrichten, die von Spamassassin markiert wurden, automatisch in einen Spam-Ordner verschoben werden.

[[Datei:2025-02-07 Sievefilter-Spam.png|960x480px|gerahmt|links|alternativtext=Screenshot Filterregel zum Spam Aussortieren|Filter in Roundcube einrichten]]

= Alternative 3: SecureMX zubuchen =

Über unseren Domain-Anbieter "Partnergate" bietet Hostsharing als dritte Alternative die kommerzielle Spam-Appliance von Cisco an. Das Produkt heißt bei Partnergate "SecureMX": https://www.hostsharing.net/loesungen/email/spam-abwehr/

Die Nutzung von SecureMX ist kostenpflichtig und wird auf Wunsch von Service eingerichtet.

Es ist zu beachten, dass bei der Nutzung von SecureMX alle eingehenden E-Mail Nachrichten über Server geleitet werden, die nicht unter der Kontrolle von Hostsharing stehen und proprietäre Software einsetzen. Dieser Sachverhalt muss vom Mitglied ggf. datenschutzrechtlich bewertet werden.

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

Spamfilter

2025-02-07T15:08:33Z

Peh00: /* Bayesfilter anlernen */

Einrichtung, Konfiguration und Optimierung eines Spamfilters auf den Hostsharing Servern. Der Artikel beschreibt drei Möglichkeiten:

1. Die Einrichtung von Spamassassin für das persönliche Postfach

2. Die Nutzung der "smailin"-Server für eine komplette Domain

3. Nutzung der Spam-Appliance "SecureMX"

= Alternative 1: Persönlichen Spamfilter einrichten =

Hier geht es darum, wie Personen mit (grundlegenden) Kenntnissen in der Shell-Bedienung für ihr persönliches Postfach einen Spam-Filter einrichten können. Spamassassin kann für jedes Postfach individuell konfiguriert werden und der Bayesfilter kann mit den persönlichen Nachrichten angelernt werden. Für die Einrichtung und Pflege ist Shell-Zugang zur Mailbox erforderlich.

== Spamassassin Konfigurieren ==

Der Spamfilter "Spamassassin" ist bei HS vorinstalliert und kann wie auf der Seite [[Procmail]] beschrieben für eine Mailbox eingebunden werden.
Alternativ kann "spamc", das Kommando zur Nutzung des Spamassassin-Daemon, auch einfach in der Datei ".forward" eines Mail-Users aufgerufen werden:

<syntaxhighlight lang=bash>
"|/usr/bin/spamc -U /var/run/spamd -e /usr/lib/dovecot/deliver"
</syntaxhighlight>

Der Effekt: Spammassassin schreibt seine Testergebnisse in die Headerzeilen jeder E-Mail und leitet die E-Mails weiter an das Programm "deliver" aus dem Dovecot-Paket. Das Sortieren von Spam-EMail in einen Spam-Ordner lässt sich mit Sieve-Filtern umsetzen.

In dieser Variante kann man Spamassassin individuell konfigurieren. Dazu legt man im $HOME des Mailbox-Account ein Verzeichnis "$HOME/.spamassassin" an. Die Konfiguration erfolgt in der Datei "$HOME/.spamassassin/user_prefs".

Konfigurationsbeispiel:

<syntaxhighlight lang=bash>
required_score 4.0
report_safe 0
use_bayes 1
bayes_auto_learn 1
skip_rbl_checks 0
use_razor2 1
use_pyzor 1
</syntaxhighlight>

== Bayesfilter anlernen ==

Wenn der Bayesfilter eingeschaltet ist, macht es Sinn den Filter mit den Befehlen

<syntaxhighlight lang=bash>
sa-learn --spam <platzhalter-spam-nachricht>
sa-learn --ham <platzhalter-erwünschte-nachricht>
</syntaxhighlight>

anzulernen. Ein Bash-Skript für das Erlernen von Spam/Nonspam kann wie folgt aussehen:

<syntaxhighlight lang=bash>
!/bin/bash
#
# Learn Spam from Maildir folder Junk/LearnSpam
#
mkdir -p ${HOME}/sa-learn-tmp
cd ${HOME}/Maildir/.Junk.LearnSpam/cur/
for JUNK in $( ls ); do zcat ${JUNK} > ${HOME}/sa-learn-tmp/$( echo ${JUNK} | cut -d'.' -f2 ).eml ; done
cd ${HOME}/
sa-learn --spam ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/Maildir/.Junk.LearnSpam/cur/*
#
# Learn Non-Spam from Maildir folder Junk/LearnHam
#
cd ${HOME}/Maildir/.Junk.LearnHam/cur/
for HAM in $( ls ); do zcat ${HAM} > ${HOME}/sa-learn-tmp/$( echo ${HAM} | cut -d'.' -f2 ).eml ; done
cd ${HOME}/
sa-learn --ham ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/Maildir/.Junk.LearnHam/cur/*
</syntaxhighlight>

Die Empfängerin der Nachrichten / der Empfänger füttert den Lernprozess, indem Spam-Nachrichten in den Ordner "Spam/LearnSpam" verschoben werden und indem gute Nachrichten in den Ordner "Spam/LearnHam" kopiert werden.

Das Skript wird über einen systemd-Timer täglich ausgeführt, der pro Mailbox eingerichtet werden muss.

= Alternative 2: Maileingangsserver mit Spamfilter nutzen =

Zusätzlich zu den vorkonfigurierte Maileingangsservern betreibt Hostsharing seit einigen Jahren einen zweiten Satz von Maileingangsservern, bei denen Spamassassin bereits beim Annehmen einer E-Mail ausgeführt wird. Eingehende Nachrichten mit eindeutiger Bewertung als Spam werden bereits im SMTP-Dialog abgewiesen. Nachrichten mit einem Spam-Score über 5 Punkten werden angenommen und zugestellt. Spamassassin für die Bewertung für diese Nachrichten in die Header der Nachricht ein, zum Beispiel:

<syntaxhighlight lang=bash>
X-Spam-Flag: YES
X-Spam-Score: 6.263
X-Spam-Level: ******
</syntaxhighlight>

Anhand dieser Zeilen kann man in Roundcube Filter einrichten, die die Nachrichten beim Eintreffen der Nachricht in einen Spam-Ordner mit verdächtigen Nachrichten verschieben (siehe später folgenden Abschnitt).

== Eingangsserver konfigurieren ==

Die Maileingangsserver mit Spamassassin lassen sich pro Domain konfigurieren, indem die MX-Records im DNS-Zonefile gegenüber dem Default-Zonefile angepasst werden.

Im Zonefile entfällt der Platzhalter "{MX_RR}". Stattdessen werden die folgenden MX-Records eingefügt:

<syntaxhighlight lang=bash>
{DOM_HOSTNAME}. IN MX 10 smailin1.hostsharing.net.
{DOM_HOSTNAME}. IN MX 10 smailin2.hostsharing.net.
{DOM_HOSTNAME}. IN MX 10 smailin3.hostsharing.net.
</syntaxhighlight>

Zur Änderung der DNS-Zone siehe: https://www.hostsharing.net/doc/managed-operations-platform/zonefile/
Wer sich die Aktion auf der Shell nicht zutraut, möge bitte den "Webmaster on Demand" beauftragen.

== Spam-Ordner ==

Mit dem folgenden Filter können Nachrichten, die von Spamassassin markiert wurden, automatisch in einen Spam-Ordner verschoben werden.

[[Datei:2025-02-07 Sievefilter-Spam.png|960x480px|gerahmt|links|alternativtext=Screenshot Filterregel zum Spam Aussortieren|Filter in Roundcube einrichten]]

= Alternative 3: SecureMX zubuchen =

Über unseren Domain-Anbieter "Partnergate" bietet Hostsharing als dritte Alternative die kommerzielle Spam-Appliance von Cisco an. Das Produkt heißt bei Partnergate "SecureMX": https://www.hostsharing.net/loesungen/email/spam-abwehr/

Die Nutzung von SecureMX ist kostenpflichtig und wird auf Wunsch von Service eingerichtet.

Es ist zu beachten, dass bei der Nutzung von SecureMX alle eingehenden E-Mail Nachrichten über Server geleitet werden, die nicht unter der Kontrolle von Hostsharing stehen und proprietäre Software einsetzen. Dieser Sachverhalt muss vom Mitglied ggf. datenschutzrechtlich bewertet werden.

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

Spamfilter

2025-02-07T15:07:14Z

Peh00: Individuelle Konfiguration per Shell Zugang für Alternative 1

Einrichtung, Konfiguration und Optimierung eines Spamfilters auf den Hostsharing Servern. Der Artikel beschreibt drei Möglichkeiten:

1. Die Einrichtung von Spamassassin für das persönliche Postfach

2. Die Nutzung der "smailin"-Server für eine komplette Domain

3. Nutzung der Spam-Appliance "SecureMX"

= Alternative 1: Persönlichen Spamfilter einrichten =

Hier geht es darum, wie Personen mit (grundlegenden) Kenntnissen in der Shell-Bedienung für ihr persönliches Postfach einen Spam-Filter einrichten können. Spamassassin kann für jedes Postfach individuell konfiguriert werden und der Bayesfilter kann mit den persönlichen Nachrichten angelernt werden. Für die Einrichtung und Pflege ist Shell-Zugang zur Mailbox erforderlich.

== Spamassassin Konfigurieren ==

Der Spamfilter "Spamassassin" ist bei HS vorinstalliert und kann wie auf der Seite [[Procmail]] beschrieben für eine Mailbox eingebunden werden.
Alternativ kann "spamc", das Kommando zur Nutzung des Spamassassin-Daemon, auch einfach in der Datei ".forward" eines Mail-Users aufgerufen werden:

<syntaxhighlight lang=bash>
"|/usr/bin/spamc -U /var/run/spamd -e /usr/lib/dovecot/deliver"
</syntaxhighlight>

Der Effekt: Spammassassin schreibt seine Testergebnisse in die Headerzeilen jeder E-Mail und leitet die E-Mails weiter an das Programm "deliver" aus dem Dovecot-Paket. Das Sortieren von Spam-EMail in einen Spam-Ordner lässt sich mit Sieve-Filtern umsetzen.

In dieser Variante kann man Spamassassin individuell konfigurieren. Dazu legt man im $HOME des Mailbox-Account ein Verzeichnis "$HOME/.spamassassin" an. Die Konfiguration erfolgt in der Datei "$HOME/.spamassassin/user_prefs".

Konfigurationsbeispiel:

<syntaxhighlight lang=bash>
required_score 4.0
report_safe 0
use_bayes 1
bayes_auto_learn 1
skip_rbl_checks 0
use_razor2 1
use_pyzor 1
</syntaxhighlight>

== Bayesfilter anlernen ==

Wenn der Bayesfilter eingeschaltet ist, macht es Sinn den Filter mit den Befehlen

<syntaxhighlight lang=bash>
sa-learn --spam <platzhalter-spam-nachricht>
sa-learn --ham <platzhalter-erwünschte-nachricht>
</syntaxhighlight>

anzulernen. Ein Bash-Skript für das Erlernen von Spam/Nonspam kann wie folgt aussehen:

<syntaxhighlight lang=bash>
!/bin/bash
#
# Learn Spam from Maildir folder Junk/LearnSpam
#
mkdir -p ${HOME}/sa-learn-tmp
cd ${HOME}/Maildir/.Junk.LearnSpam/cur/
for JUNK in $( ls ); do zcat ${JUNK} > ${HOME}/sa-learn-tmp/$( echo ${JUNK} | cut -d'.' -f2 ).eml ; done
cd ${HOME}/
sa-learn --spam ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/Maildir/.Junk.LearnSpam/cur/*
#
# Learn Non-Spam from Maildir folder Junk/LearnHam
#
cd ${HOME}/Maildir/.Junk.LearnHam/cur/
for HAM in $( ls ); do zcat ${HAM} > ${HOME}/sa-learn-tmp/$( echo ${HAM} | cut -d'.' -f2 ).eml ; done
cd ${HOME}/
sa-learn --ham ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/Maildir/.Junk.LearnHam/cur/*
</syntaxhighlight>

Die Empfängerin der Nachrichten / der Empfänger füttert den Lernprozess, indem Spam-Nachrichten in den Ordner "Spam/LearnSpam" verschoben werden und indem gute Nachrichten in den Ordner "Spam/LearnHam" kopiert werden.

Das Skript wird über einen systemd-Timer täglich ausgefürt.

= Alternative 2: Maileingangsserver mit Spamfilter nutzen =

Zusätzlich zu den vorkonfigurierte Maileingangsservern betreibt Hostsharing seit einigen Jahren einen zweiten Satz von Maileingangsservern, bei denen Spamassassin bereits beim Annehmen einer E-Mail ausgeführt wird. Eingehende Nachrichten mit eindeutiger Bewertung als Spam werden bereits im SMTP-Dialog abgewiesen. Nachrichten mit einem Spam-Score über 5 Punkten werden angenommen und zugestellt. Spamassassin für die Bewertung für diese Nachrichten in die Header der Nachricht ein, zum Beispiel:

<syntaxhighlight lang=bash>
X-Spam-Flag: YES
X-Spam-Score: 6.263
X-Spam-Level: ******
</syntaxhighlight>

Anhand dieser Zeilen kann man in Roundcube Filter einrichten, die die Nachrichten beim Eintreffen der Nachricht in einen Spam-Ordner mit verdächtigen Nachrichten verschieben (siehe später folgenden Abschnitt).

== Eingangsserver konfigurieren ==

Die Maileingangsserver mit Spamassassin lassen sich pro Domain konfigurieren, indem die MX-Records im DNS-Zonefile gegenüber dem Default-Zonefile angepasst werden.

Im Zonefile entfällt der Platzhalter "{MX_RR}". Stattdessen werden die folgenden MX-Records eingefügt:

<syntaxhighlight lang=bash>
{DOM_HOSTNAME}. IN MX 10 smailin1.hostsharing.net.
{DOM_HOSTNAME}. IN MX 10 smailin2.hostsharing.net.
{DOM_HOSTNAME}. IN MX 10 smailin3.hostsharing.net.
</syntaxhighlight>

Zur Änderung der DNS-Zone siehe: https://www.hostsharing.net/doc/managed-operations-platform/zonefile/
Wer sich die Aktion auf der Shell nicht zutraut, möge bitte den "Webmaster on Demand" beauftragen.

== Spam-Ordner ==

Mit dem folgenden Filter können Nachrichten, die von Spamassassin markiert wurden, automatisch in einen Spam-Ordner verschoben werden.

[[Datei:2025-02-07 Sievefilter-Spam.png|960x480px|gerahmt|links|alternativtext=Screenshot Filterregel zum Spam Aussortieren|Filter in Roundcube einrichten]]

= Alternative 3: SecureMX zubuchen =

Über unseren Domain-Anbieter "Partnergate" bietet Hostsharing als dritte Alternative die kommerzielle Spam-Appliance von Cisco an. Das Produkt heißt bei Partnergate "SecureMX": https://www.hostsharing.net/loesungen/email/spam-abwehr/

Die Nutzung von SecureMX ist kostenpflichtig und wird auf Wunsch von Service eingerichtet.

Es ist zu beachten, dass bei der Nutzung von SecureMX alle eingehenden E-Mail Nachrichten über Server geleitet werden, die nicht unter der Kontrolle von Hostsharing stehen und proprietäre Software einsetzen. Dieser Sachverhalt muss vom Mitglied ggf. datenschutzrechtlich bewertet werden.

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

Nextcloud

2025-02-07T15:01:52Z

Peh00: /* Einrichtung des HDD Storage */

= 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-27.1.2.zip
unzip nextcloud-27.1.2.zip
rm nextcloud-27.1.2.zip
mkdir data tmp
chmod 700 data tmp
</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. '''In Verbindung mit einem Managed Webspace''' muss für Redis als eigener Serverdienst RAM gebucht werden und ist '''kostenpflichtig'''. Siehe zu Kosten im Webspace Konfigurator unter: https://www.hostsharing.net/angebote/managed-webspace/ – '''Arbeitsspeicher für eigene Serverdienste'''.

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>

Mit einem weiteren Timer für die regelmäßigen Hintergrundaufgaben von Nextcloud lässt sie sich noch etwas beschleunigen:

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

[Service]
Type=oneshot
ExecStart=php8.2 /home/pacs/xyz00/users/cloud/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.

[[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/updater
xyz00-cloud@h00:~/nextcloud/updater$ chmod u+x updater.phar
xyz00-cloud@h00:~/nextcloud/updater$ ./updater.phar
</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
</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
</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 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]]

Nextcloud

2025-02-07T15:01:19Z

Peh00: /* Einrichtung des HDD Storage */

= 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-27.1.2.zip
unzip nextcloud-27.1.2.zip
rm nextcloud-27.1.2.zip
mkdir data tmp
chmod 700 data tmp
</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. '''In Verbindung mit einem Managed Webspace''' muss für Redis als eigener Serverdienst RAM gebucht werden und ist '''kostenpflichtig'''. Siehe zu Kosten im Webspace Konfigurator unter: https://www.hostsharing.net/angebote/managed-webspace/ – '''Arbeitsspeicher für eigene Serverdienste'''.

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>

Mit einem weiteren Timer für die regelmäßigen Hintergrundaufgaben von Nextcloud lässt sie sich noch etwas beschleunigen:

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

[Service]
Type=oneshot
ExecStart=php8.2 /home/pacs/xyz00/users/cloud/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.

[[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/updater
xyz00-cloud@h00:~/nextcloud/updater$ chmod u+x updater.phar
xyz00-cloud@h00:~/nextcloud/updater$ ./updater.phar
</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
</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
</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 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-verezcihnis 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]]

Spamfilter

2025-02-07T14:43:23Z

Peh00: /* Alternative 3: SecureMX zubuchen */

Einrichtung, Konfiguration und Optimierung eines Spamfilters auf den Hostsharing Servern. Der Artikel beschreibt drei Möglichkeiten:

1. Die Einrichtung von Apamassassin für das persönliche Postfach

2. Die Nutzung der "smailin"-Server für eine komplette Domain

3. Nutzung der Spam-Appliance "SecureMX"

= Alternative 1: Persönlichen Spamfilter einrichten =

Hier geht es darum, wie Personen mit (grundlegenden) kenntnissen in der Shell-Bedienung für ihr persönliches Postfach einen Spam-Filter einrichten können.

== Spamassassin Konfigurieren ==

Der Spamfilter "Spamassassin" ist bei HS vorinstalliert und kann wie auf der Seite [[Procmail]] beschrieben für eine Mailbox eingebunden werden.
Alternativ kann "spamc", das Kommando zur Nutzung des Spamassassin-Daemon, auch einfach in der Datei ".forward" eines Mail-Users aufgerufen werden:

<syntaxhighlight lang=bash>
"|/usr/bin/spamc -U /var/run/spamd -e /usr/lib/dovecot/deliver"
</syntaxhighlight>

Der Effekt: Spammassassin schreibt seine Testergebnisse in die Headerzeilen jeder E-Mail und leitet die E-Mails weiter an das Programm "deliver" aus dem Dovecot-Paket. Das Sortieren von Spam-EMail in einen Spam-Ordner lässt sich mit Sieve-Filtern umsetzen.

In dieser Variante kann man Spamassassin individuell konfigurieren. Dazu legt man im $HOME des Mailbox-Account ein Verzeichnis "$HOME/.spamassassin" an. Die Konfiguration erfolgt in der Datei "$HOME/.spamassassin/user_prefs".

Konfigurationsbeispiel:

<syntaxhighlight lang=bash>
required_score 4.0
report_safe 0
use_bayes 1
bayes_auto_learn 1
skip_rbl_checks 0
use_razor2 1
use_pyzor 1
</syntaxhighlight>

== Bayesfilter anlernen ==

Wenn der Bayesfilter eingeschaltet ist, macht es Sinn den Filter mit den Befehlen

<syntaxhighlight lang=bash>
sa-learn --spam <platzhalter-spam-nachricht>
sa-learn --ham <platzhalter-erwünschte-nachricht>
</syntaxhighlight>

anzulernen. Ein Bash-Skript für das Erlernen von Spam/Nonspam kann wie folgt aussehen:

<syntaxhighlight lang=bash>
!/bin/bash
#
# Learn Spam from Maildir folder Junk/LearnSpam
#
mkdir -p ${HOME}/sa-learn-tmp
cd ${HOME}/Maildir/.Junk.LearnSpam/cur/
for JUNK in $( ls ); do zcat ${JUNK} > ${HOME}/sa-learn-tmp/$( echo ${JUNK} | cut -d'.' -f2 ).eml ; done
cd ${HOME}/
sa-learn --spam ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/Maildir/.Junk.LearnSpam/cur/*
#
# Learn Non-Spam from Maildir folder Junk/LearnHam
#
cd ${HOME}/Maildir/.Junk.LearnHam/cur/
for HAM in $( ls ); do zcat ${HAM} > ${HOME}/sa-learn-tmp/$( echo ${HAM} | cut -d'.' -f2 ).eml ; done
cd ${HOME}/
sa-learn --ham ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/Maildir/.Junk.LearnHam/cur/*
</syntaxhighlight>

Die Empfängerin der Nachrichten / der Empfänger füttert den Lernprozess, indem Spam-Nachrichten in den Ordner "Spam/LearnSpam" verschoben werden und indem gute Nachrichten in den Ordner "Spam/LearnHam" kopiert werden.

Das Skript wird über einen systemd-Timer täglich ausgefürt.

= Alternative 2: Maileingangsserver mit Spamfilter nutzen =

Zusätzlich zu den vorkonfigurierte Maileingangsservern betriebt Hostsharing seit einigen Jahren einen zweiten Satz von Maileingangsservern, bei denen Spamassassin bereits beim Annehmen einer E-Mail ausgeführt wird. Eingehende Nachrichten mit eindeutiger Bewertung als Spam werden bereits im SMTP-Dialog abgewiesen. Nachrichten mit einem Spam-Score über 5 Punkten werden angenommen und zugestellt. Spamassassin für die Bewertung für diese Nachrichten in die Header der Nachricht ein, zum Beispiel:

<syntaxhighlight lang=bash>
X-Spam-Flag: YES
X-Spam-Score: 6.263
X-Spam-Level: ******
</syntaxhighlight>

Anhand dieser Zeilen kann man in Roundcube Filter einrichten, die die Nachrichten beim Eintreffen der Nachricht in einen Spam-Ordner mit verdächtigen Nachrichten verschieben (siehe später folgenden Abschnitt).

== Eingangsserver konfigurieren ==

Um die Maileingangsserver mit Spamassassin lassen sich pro Domain konfigurieren, indem die MX-Records im DNS-Zonefile gegenüber dem Default-Zonefile angepasst werden.

Im Zonefile entfällt der Platzhalter "{MX_RR}". Stattdessen werden die folgenden MX-Records eingefügt:

<syntaxhighlight lang=bash>
{DOM_HOSTNAME}. IN MX 10 smailin1.hostsharing.net.
{DOM_HOSTNAME}. IN MX 10 smailin2.hostsharing.net.
{DOM_HOSTNAME}. IN MX 10 smailin3.hostsharing.net.
</syntaxhighlight>

Zur Änderung der DNS-Zone siehe: https://www.hostsharing.net/doc/managed-operations-platform/zonefile/
Wer sich die Aktion auf der Shell nicht zutraut, möge bitte den "Webmaster on Demand" beauftragen.

== Spam-Ordner ==

Mit dem folgenden Filter können Nachrichten, die von Spamassassin markiert wurden, automatisch in einen Spam-Ordner verschoben werden.

[[Datei:2025-02-07 Sievefilter-Spam.png|960x480px|gerahmt|links|alternativtext=Screenshot Filterregel zum Spam Aussortieren|Filter in Roundcube einrichten]]

= Alternative 3: SecureMX zubuchen =

Über unseren Domain-Anbieter "Partnergate" bietet Hostsharing als dritte Alternative die kommerzielle Spam-Appliance von Cisco an. Das Produkt heißt bei Partnergate "SecureMX": https://www.hostsharing.net/loesungen/email/spam-abwehr/

Die Nutzung von SecureMX ist kostenpflichtig und wird auf Wunsch von Service eingerichtet.

Es ist zu beachten, dass bei der Nutzung von SecureMX alle eingehenden E-Mail Nachrichten über Server geleitet werden, die nicht unter der Kontrolle von Hostsharing stehen und proprietäre Software einsetzen. Dieser Sachverhalt muss vom Mitglied ggf. datenschutzrechtlich bewertet werden.

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

Spamfilter

2025-02-07T14:43:05Z

Peh00: /* Alternative 3: SecureMX zubuchen */

Einrichtung, Konfiguration und Optimierung eines Spamfilters auf den Hostsharing Servern. Der Artikel beschreibt drei Möglichkeiten:

1. Die Einrichtung von Apamassassin für das persönliche Postfach

2. Die Nutzung der "smailin"-Server für eine komplette Domain

3. Nutzung der Spam-Appliance "SecureMX"

= Alternative 1: Persönlichen Spamfilter einrichten =

Hier geht es darum, wie Personen mit (grundlegenden) kenntnissen in der Shell-Bedienung für ihr persönliches Postfach einen Spam-Filter einrichten können.

== Spamassassin Konfigurieren ==

Der Spamfilter "Spamassassin" ist bei HS vorinstalliert und kann wie auf der Seite [[Procmail]] beschrieben für eine Mailbox eingebunden werden.
Alternativ kann "spamc", das Kommando zur Nutzung des Spamassassin-Daemon, auch einfach in der Datei ".forward" eines Mail-Users aufgerufen werden:

<syntaxhighlight lang=bash>
"|/usr/bin/spamc -U /var/run/spamd -e /usr/lib/dovecot/deliver"
</syntaxhighlight>

Der Effekt: Spammassassin schreibt seine Testergebnisse in die Headerzeilen jeder E-Mail und leitet die E-Mails weiter an das Programm "deliver" aus dem Dovecot-Paket. Das Sortieren von Spam-EMail in einen Spam-Ordner lässt sich mit Sieve-Filtern umsetzen.

In dieser Variante kann man Spamassassin individuell konfigurieren. Dazu legt man im $HOME des Mailbox-Account ein Verzeichnis "$HOME/.spamassassin" an. Die Konfiguration erfolgt in der Datei "$HOME/.spamassassin/user_prefs".

Konfigurationsbeispiel:

<syntaxhighlight lang=bash>
required_score 4.0
report_safe 0
use_bayes 1
bayes_auto_learn 1
skip_rbl_checks 0
use_razor2 1
use_pyzor 1
</syntaxhighlight>

== Bayesfilter anlernen ==

Wenn der Bayesfilter eingeschaltet ist, macht es Sinn den Filter mit den Befehlen

<syntaxhighlight lang=bash>
sa-learn --spam <platzhalter-spam-nachricht>
sa-learn --ham <platzhalter-erwünschte-nachricht>
</syntaxhighlight>

anzulernen. Ein Bash-Skript für das Erlernen von Spam/Nonspam kann wie folgt aussehen:

<syntaxhighlight lang=bash>
!/bin/bash
#
# Learn Spam from Maildir folder Junk/LearnSpam
#
mkdir -p ${HOME}/sa-learn-tmp
cd ${HOME}/Maildir/.Junk.LearnSpam/cur/
for JUNK in $( ls ); do zcat ${JUNK} > ${HOME}/sa-learn-tmp/$( echo ${JUNK} | cut -d'.' -f2 ).eml ; done
cd ${HOME}/
sa-learn --spam ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/Maildir/.Junk.LearnSpam/cur/*
#
# Learn Non-Spam from Maildir folder Junk/LearnHam
#
cd ${HOME}/Maildir/.Junk.LearnHam/cur/
for HAM in $( ls ); do zcat ${HAM} > ${HOME}/sa-learn-tmp/$( echo ${HAM} | cut -d'.' -f2 ).eml ; done
cd ${HOME}/
sa-learn --ham ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/Maildir/.Junk.LearnHam/cur/*
</syntaxhighlight>

Die Empfängerin der Nachrichten / der Empfänger füttert den Lernprozess, indem Spam-Nachrichten in den Ordner "Spam/LearnSpam" verschoben werden und indem gute Nachrichten in den Ordner "Spam/LearnHam" kopiert werden.

Das Skript wird über einen systemd-Timer täglich ausgefürt.

= Alternative 2: Maileingangsserver mit Spamfilter nutzen =

Zusätzlich zu den vorkonfigurierte Maileingangsservern betriebt Hostsharing seit einigen Jahren einen zweiten Satz von Maileingangsservern, bei denen Spamassassin bereits beim Annehmen einer E-Mail ausgeführt wird. Eingehende Nachrichten mit eindeutiger Bewertung als Spam werden bereits im SMTP-Dialog abgewiesen. Nachrichten mit einem Spam-Score über 5 Punkten werden angenommen und zugestellt. Spamassassin für die Bewertung für diese Nachrichten in die Header der Nachricht ein, zum Beispiel:

<syntaxhighlight lang=bash>
X-Spam-Flag: YES
X-Spam-Score: 6.263
X-Spam-Level: ******
</syntaxhighlight>

Anhand dieser Zeilen kann man in Roundcube Filter einrichten, die die Nachrichten beim Eintreffen der Nachricht in einen Spam-Ordner mit verdächtigen Nachrichten verschieben (siehe später folgenden Abschnitt).

== Eingangsserver konfigurieren ==

Um die Maileingangsserver mit Spamassassin lassen sich pro Domain konfigurieren, indem die MX-Records im DNS-Zonefile gegenüber dem Default-Zonefile angepasst werden.

Im Zonefile entfällt der Platzhalter "{MX_RR}". Stattdessen werden die folgenden MX-Records eingefügt:

<syntaxhighlight lang=bash>
{DOM_HOSTNAME}. IN MX 10 smailin1.hostsharing.net.
{DOM_HOSTNAME}. IN MX 10 smailin2.hostsharing.net.
{DOM_HOSTNAME}. IN MX 10 smailin3.hostsharing.net.
</syntaxhighlight>

Zur Änderung der DNS-Zone siehe: https://www.hostsharing.net/doc/managed-operations-platform/zonefile/
Wer sich die Aktion auf der Shell nicht zutraut, möge bitte den "Webmaster on Demand" beauftragen.

== Spam-Ordner ==

Mit dem folgenden Filter können Nachrichten, die von Spamassassin markiert wurden, automatisch in einen Spam-Ordner verschoben werden.

[[Datei:2025-02-07 Sievefilter-Spam.png|960x480px|gerahmt|links|alternativtext=Screenshot Filterregel zum Spam Aussortieren|Filter in Roundcube einrichten]]

= Alternative 3: SecureMX zubuchen =

Über unseren Domain-Anbieter "Partnergate" bietet Hostsharing als dritte Alternative die kommerzielle Spam-Appliance von Cisco an. Das Produkt heißt bei Partnergate "SecureMX": https://www.hostsharing.net/loesungen/email/spam-abwehr/

Die Nutzung von SecureMX ist kostenpflichtig und wird auf Wunsch von Service eingerichtet.

Es ist zu beachten, dass bei der Nutzung von SecureMX alle eingehenden E-Mail Nachrichten über Server geleitet werden, die nicht unter der Kontrolle von Hostsharing stehen und propiretäre Software einsetzen. Dieser Sachverhalt muss vom Mitglied ggf. datenschutzrechtlich bewertet werden.

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

Spamfilter

2025-02-07T14:28:04Z

Peh00: Typo

Einrichtung, Konfiguration und Optimierung eines Spamfilters auf den Hostsharing Servern. Der Artikel beschreibt drei Möglichkeiten:

1. Die Einrichtung von Apamassassin für das persönliche Postfach

2. Die Nutzung der "smailin"-Server für eine komplette Domain

3. Nutzung der Spam-Appliance "SecureMX"

= Alternative 1: Persönlichen Spamfilter einrichten =

Hier geht es darum, wie Personen mit (grundlegenden) kenntnissen in der Shell-Bedienung für ihr persönliches Postfach einen Spam-Filter einrichten können.

== Spamassassin Konfigurieren ==

Der Spamfilter "Spamassassin" ist bei HS vorinstalliert und kann wie auf der Seite [[Procmail]] beschrieben für eine Mailbox eingebunden werden.
Alternativ kann "spamc", das Kommando zur Nutzung des Spamassassin-Daemon, auch einfach in der Datei ".forward" eines Mail-Users aufgerufen werden:

<syntaxhighlight lang=bash>
"|/usr/bin/spamc -U /var/run/spamd -e /usr/lib/dovecot/deliver"
</syntaxhighlight>

Der Effekt: Spammassassin schreibt seine Testergebnisse in die Headerzeilen jeder E-Mail und leitet die E-Mails weiter an das Programm "deliver" aus dem Dovecot-Paket. Das Sortieren von Spam-EMail in einen Spam-Ordner lässt sich mit Sieve-Filtern umsetzen.

In dieser Variante kann man Spamassassin individuell konfigurieren. Dazu legt man im $HOME des Mailbox-Account ein Verzeichnis "$HOME/.spamassassin" an. Die Konfiguration erfolgt in der Datei "$HOME/.spamassassin/user_prefs".

Konfigurationsbeispiel:

<syntaxhighlight lang=bash>
required_score 4.0
report_safe 0
use_bayes 1
bayes_auto_learn 1
skip_rbl_checks 0
use_razor2 1
use_pyzor 1
</syntaxhighlight>

== Bayesfilter anlernen ==

Wenn der Bayesfilter eingeschaltet ist, macht es Sinn den Filter mit den Befehlen

<syntaxhighlight lang=bash>
sa-learn --spam <platzhalter-spam-nachricht>
sa-learn --ham <platzhalter-erwünschte-nachricht>
</syntaxhighlight>

anzulernen. Ein Bash-Skript für das Erlernen von Spam/Nonspam kann wie folgt aussehen:

<syntaxhighlight lang=bash>
!/bin/bash
#
# Learn Spam from Maildir folder Junk/LearnSpam
#
mkdir -p ${HOME}/sa-learn-tmp
cd ${HOME}/Maildir/.Junk.LearnSpam/cur/
for JUNK in $( ls ); do zcat ${JUNK} > ${HOME}/sa-learn-tmp/$( echo ${JUNK} | cut -d'.' -f2 ).eml ; done
cd ${HOME}/
sa-learn --spam ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/Maildir/.Junk.LearnSpam/cur/*
#
# Learn Non-Spam from Maildir folder Junk/LearnHam
#
cd ${HOME}/Maildir/.Junk.LearnHam/cur/
for HAM in $( ls ); do zcat ${HAM} > ${HOME}/sa-learn-tmp/$( echo ${HAM} | cut -d'.' -f2 ).eml ; done
cd ${HOME}/
sa-learn --ham ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/Maildir/.Junk.LearnHam/cur/*
</syntaxhighlight>

Die Empfängerin der Nachrichten / der Empfänger füttert den Lernprozess, indem Spam-Nachrichten in den Ordner "Spam/LearnSpam" verschoben werden und indem gute Nachrichten in den Ordner "Spam/LearnHam" kopiert werden.

Das Skript wird über einen systemd-Timer täglich ausgefürt.

= Alternative 2: Maileingangsserver mit Spamfilter nutzen =

Zusätzlich zu den vorkonfigurierte Maileingangsservern betriebt Hostsharing seit einigen Jahren einen zweiten Satz von Maileingangsservern, bei denen Spamassassin bereits beim Annehmen einer E-Mail ausgeführt wird. Eingehende Nachrichten mit eindeutiger Bewertung als Spam werden bereits im SMTP-Dialog abgewiesen. Nachrichten mit einem Spam-Score über 5 Punkten werden angenommen und zugestellt. Spamassassin für die Bewertung für diese Nachrichten in die Header der Nachricht ein, zum Beispiel:

<syntaxhighlight lang=bash>
X-Spam-Flag: YES
X-Spam-Score: 6.263
X-Spam-Level: ******
</syntaxhighlight>

Anhand dieser Zeilen kann man in Roundcube Filter einrichten, die die Nachrichten beim Eintreffen der Nachricht in einen Spam-Ordner mit verdächtigen Nachrichten verschieben (siehe später folgenden Abschnitt).

== Eingangsserver konfigurieren ==

Um die Maileingangsserver mit Spamassassin lassen sich pro Domain konfigurieren, indem die MX-Records im DNS-Zonefile gegenüber dem Default-Zonefile angepasst werden.

Im Zonefile entfällt der Platzhalter "{MX_RR}". Stattdessen werden die folgenden MX-Records eingefügt:

<syntaxhighlight lang=bash>
{DOM_HOSTNAME}. IN MX 10 smailin1.hostsharing.net.
{DOM_HOSTNAME}. IN MX 10 smailin2.hostsharing.net.
{DOM_HOSTNAME}. IN MX 10 smailin3.hostsharing.net.
</syntaxhighlight>

Zur Änderung der DNS-Zone siehe: https://www.hostsharing.net/doc/managed-operations-platform/zonefile/
Wer sich die Aktion auf der Shell nicht zutraut, möge bitte den "Webmaster on Demand" beauftragen.

== Spam-Ordner ==

Mit dem folgenden Filter können Nachrichten, die von Spamassassin markiert wurden, automatisch in einen Spam-Ordner verschoben werden.

[[Datei:2025-02-07 Sievefilter-Spam.png|960x480px|gerahmt|links|alternativtext=Screenshot Filterregel zum Spam Aussortieren|Filter in Roundcube einrichten]]

= Alternative 3: SecureMX zubuchen =

Über unseren Domain-Anbieter "Partnergate" bietet Hostsharing als dritte Alternative die kommerzielle Spam-Appliance von Cisco an. Das Produkt heißt bei Partnergate "SecureMX": https://www.hostsharing.net/loesungen/email/spam-abwehr/

Die Nutzung von SecureMX ist kostenpflichtig und wird auf Wunsch von Service eingerichtet.

Es ist zu beachten, dass bei der Nutzung von SecureMX alle eingehenden E-Mail Nachrichten über Server geleitet werden, die nicht unter der Kontrolle von Hostsharing stehen. Dieser Sachverhalt muss vom Mitglied ggf. dateschutzrechtlich bewertet werden.

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

Spamfilter

2025-02-07T14:27:23Z

Peh00: Formatierung Screenshot

Einrichtung, Konfiguration und Optimierung eines Spamfilters auf den Hostsharing Servern. Der Artikel beschreibt drei Möglichkeiten:

1. Die Einrichtung von Apamassassin für das persönliche Postfach

2. Die Nutzung der "smailin"-Server für eine komplette Domain

3. Nutzung der Spam-Appliance "SecureMX"

= Alternative 1: Persönlichen Spamfilter einrichten =

Hier geht es darum, wie Personen mit (grundlegenden) kenntnissen in der Shell-Bedienung für ihr persönliches Postfach einen Spam-Filter einrichten können.

== Spamassassin Konfigurieren ==

Der Spamfilter "Spamassassin" ist bei HS vorinstalliert und kann wie auf der Seite [[Procmail]] beschrieben für eine Mailbox eingebunden werden.
Alternativ kann "spamc", das Kommando zur Nutzung des Spamassassin-Daemon, auch einfach in der Datei ".forward" eines Mail-Users aufgerufen werden:

<syntaxhighlight lang=bash>
"|/usr/bin/spamc -U /var/run/spamd -e /usr/lib/dovecot/deliver"
</syntaxhighlight>

Der Effekt: Spammassassin schreibt seine Testergebnisse in die Headerzeilen jeder E-Mail und leitet die E-Mails weiter an das Programm "deliver" aus dem Dovecot-Paket. Das Sortieren von Spam-EMail in einen Spam-Ordner lässt sich mit Sieve-Filtern umsetzen.

In dieser Variante kann man Spamassassin individuell konfigurieren. Dazu legt man im $HOME des Mailbox-Account ein Verzeichnis "$HOME/.spamassassin" an. Die Konfiguration erfolgt in der Datei "$HOME/.spamassassin/user_prefs".

Konfigurationsbeispiel:

<syntaxhighlight lang=bash>
required_score 4.0
report_safe 0
use_bayes 1
bayes_auto_learn 1
skip_rbl_checks 0
use_razor2 1
use_pyzor 1
</syntaxhighlight>

== Bayesfilter anlernen ==

Wenn der Bayesfilter eingeschaltet ist, macht es Sinn den Filter mit den Befehlen

<syntaxhighlight lang=bash>
sa-learn --spam <platzhalter-spam-nachricht>
sa-learn --ham <platzhalter-erwünschte-nachricht>
</syntaxhighlight>

anzulernen. Ein Bash-Skript für das Erlernen von Spam/Nonspam kann wie folgt aussehen:

<syntaxhighlight lang=bash>
!/bin/bash
#
# Learn Spam from Maildir folder Junk/LearnSpam
#
mkdir -p ${HOME}/sa-learn-tmp
cd ${HOME}/Maildir/.Junk.LearnSpam/cur/
for JUNK in $( ls ); do zcat ${JUNK} > ${HOME}/sa-learn-tmp/$( echo ${JUNK} | cut -d'.' -f2 ).eml ; done
cd ${HOME}/
sa-learn --spam ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/Maildir/.Junk.LearnSpam/cur/*
#
# Learn Non-Spam from Maildir folder Junk/LearnHam
#
cd ${HOME}/Maildir/.Junk.LearnHam/cur/
for HAM in $( ls ); do zcat ${HAM} > ${HOME}/sa-learn-tmp/$( echo ${HAM} | cut -d'.' -f2 ).eml ; done
cd ${HOME}/
sa-learn --ham ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/Maildir/.Junk.LearnHam/cur/*
</syntaxhighlight>

Die Empfängerin der Nachrichten / der Empfänger füttert den Lernprozess, indem Spam-Nachrichten in den Ordner "Spam/LearnSpam" verschoben werden und indem gute Nachrichten in den Ordner "Spam/LearnHam" kopiert werden.

Das Skript wird über einen systemd-Timer täglich ausgefürt.

= Alternative 2: Maileingangsserver mit Spamfilter nutzen =

Zusätzlich zu den vorkonfigurierte Maileingangsservern betriebt Hostsharing seit einigen Jahren einen zweiten Satz von Maileingangsservern, bei denen Spamassassin bereits beim Annehmen einer E-Mail ausgeführt wird. Eingehende Nachrichten mit eindeutiger Bewertung als Spam werden bereits im SMTP-Dialog abgewiesen. Nachrichten mit einem Spam-Score über 5 Punkten werden angenommen und zugestellt. Spamassassin für die Bewertung für diese Nachrichten in die Header der Nachricht ein, zum Beispiel:

<syntaxhighlight lang=bash>
X-Spam-Flag: YES
X-Spam-Score: 6.263
X-Spam-Level: ******
</syntaxhighlight>

Anhand dieser Zeilen kann man in Roundcube Filter einrichten, die die Nachrichten beim Eintreffen der Nachricht in einen Spam-Ordner mit verdächtigen Nachrichten verschieben (siehe später folgenden Abschnitt).

== Eingangsserver konfigurieren ==

Um die Maileingangsserver mit Spamassassin lassen sich pro Domain konfigurieren, indem die MX-Records im DNS-Zonefile gegenüber dem Default-Zonefile angepasst werden.

Im Zonefile entfällt der Platzhalter "{MX_RR}". Stattdessen werden die folgenden MX-Records eingefügt:

<syntaxhighlight lang=bash>
{DOM_HOSTNAME}. IN MX 10 smailin1.hostsharing.net.
{DOM_HOSTNAME}. IN MX 10 smailin2.hostsharing.net.
{DOM_HOSTNAME}. IN MX 10 smailin3.hostsharing.net.
</syntaxhighlight>

Zur Änderung der DNS-Zone siehe: https://www.hostsharing.net/doc/managed-operations-platform/zonefile/
Wer sich die Aktion auf der Shell nicht zutraut, möge bitte den "Webmaster on Demand" beauftragen.

== Spam-Ordner ==

Mit dem folgenden Filter können Nachrichten, die von Spamassassin markiert wurden, automatisch in einen Spam-Ordner verschoben werden.

[[Datei:2025-02-07 Sievefilter-Spam.png|960x480px|gerahmt|links|alternativtext=Screenshot Filterregel zum Spam Aussortieren|Filter in Roundcube einrichten]]

= Alternative 3: SecureMX zubuchen =

Über unseren Domain-Anbieter "Partnergate" bietet Hostsharing als dritte Alternative die kommerzielle Spam-Appliance von Cisco an. Das Produkt heißt bei Partnergate "SecureMX": https://www.hostsharing.net/loesungen/email/spam-abwehr/

Die Nutzung von SecureMX ist kostenpflichtig und wird auf Wunsch von Service eingerichtet.

Es ist zu beachten, dass bei der Nutzung von SecureMX alle eingehenden E-Mail Nachrichten über Server geleitet werden, die nicht unter der Kontrolle von Hostsharing stehen. Dieser Sachverhalt muss von Mitglied ggf. dateschutzrechtlich bewertet werden.

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

Spamfilter

2025-02-07T14:24:25Z

Peh00: SecureMX

Einrichtung, Konfiguration und Optimierung eines Spamfilters auf den Hostsharing Servern. Der Artikel beschreibt drei Möglichkeiten:

1. Die Einrichtung von Apamassassin für das persönliche Postfach

2. Die Nutzung der "smailin"-Server für eine komplette Domain

3. Nutzung der Spam-Appliance "SecureMX"

= Alternative 1: Persönlichen Spamfilter einrichten =

Hier geht es darum, wie Personen mit (grundlegenden) kenntnissen in der Shell-Bedienung für ihr persönliches Postfach einen Spam-Filter einrichten können.

== Spamassassin Konfigurieren ==

Der Spamfilter "Spamassassin" ist bei HS vorinstalliert und kann wie auf der Seite [[Procmail]] beschrieben für eine Mailbox eingebunden werden.
Alternativ kann "spamc", das Kommando zur Nutzung des Spamassassin-Daemon, auch einfach in der Datei ".forward" eines Mail-Users aufgerufen werden:

<syntaxhighlight lang=bash>
"|/usr/bin/spamc -U /var/run/spamd -e /usr/lib/dovecot/deliver"
</syntaxhighlight>

Der Effekt: Spammassassin schreibt seine Testergebnisse in die Headerzeilen jeder E-Mail und leitet die E-Mails weiter an das Programm "deliver" aus dem Dovecot-Paket. Das Sortieren von Spam-EMail in einen Spam-Ordner lässt sich mit Sieve-Filtern umsetzen.

In dieser Variante kann man Spamassassin individuell konfigurieren. Dazu legt man im $HOME des Mailbox-Account ein Verzeichnis "$HOME/.spamassassin" an. Die Konfiguration erfolgt in der Datei "$HOME/.spamassassin/user_prefs".

Konfigurationsbeispiel:

<syntaxhighlight lang=bash>
required_score 4.0
report_safe 0
use_bayes 1
bayes_auto_learn 1
skip_rbl_checks 0
use_razor2 1
use_pyzor 1
</syntaxhighlight>

== Bayesfilter anlernen ==

Wenn der Bayesfilter eingeschaltet ist, macht es Sinn den Filter mit den Befehlen

<syntaxhighlight lang=bash>
sa-learn --spam <platzhalter-spam-nachricht>
sa-learn --ham <platzhalter-erwünschte-nachricht>
</syntaxhighlight>

anzulernen. Ein Bash-Skript für das Erlernen von Spam/Nonspam kann wie folgt aussehen:

<syntaxhighlight lang=bash>
!/bin/bash
#
# Learn Spam from Maildir folder Junk/LearnSpam
#
mkdir -p ${HOME}/sa-learn-tmp
cd ${HOME}/Maildir/.Junk.LearnSpam/cur/
for JUNK in $( ls ); do zcat ${JUNK} > ${HOME}/sa-learn-tmp/$( echo ${JUNK} | cut -d'.' -f2 ).eml ; done
cd ${HOME}/
sa-learn --spam ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/Maildir/.Junk.LearnSpam/cur/*
#
# Learn Non-Spam from Maildir folder Junk/LearnHam
#
cd ${HOME}/Maildir/.Junk.LearnHam/cur/
for HAM in $( ls ); do zcat ${HAM} > ${HOME}/sa-learn-tmp/$( echo ${HAM} | cut -d'.' -f2 ).eml ; done
cd ${HOME}/
sa-learn --ham ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/Maildir/.Junk.LearnHam/cur/*
</syntaxhighlight>

Die Empfängerin der Nachrichten / der Empfänger füttert den Lernprozess, indem Spam-Nachrichten in den Ordner "Spam/LearnSpam" verschoben werden und indem gute Nachrichten in den Ordner "Spam/LearnHam" kopiert werden.

Das Skript wird über einen systemd-Timer täglich ausgefürt.

= Alternative 2: Maileingangsserver mit Spamfilter nutzen =

Zusätzlich zu den vorkonfigurierte Maileingangsservern betriebt Hostsharing seit einigen Jahren einen zweiten Satz von Maileingangsservern, bei denen Spamassassin bereits beim Annehmen einer E-Mail ausgeführt wird. Eingehende Nachrichten mit eindeutiger Bewertung als Spam werden bereits im SMTP-Dialog abgewiesen. Nachrichten mit einem Spam-Score über 5 Punkten werden angenommen und zugestellt. Spamassassin für die Bewertung für diese Nachrichten in die Header der Nachricht ein, zum Beispiel:

<syntaxhighlight lang=bash>
X-Spam-Flag: YES
X-Spam-Score: 6.263
X-Spam-Level: ******
</syntaxhighlight>

Anhand dieser Zeilen kann man in Roundcube Filter einrichten, die die Nachrichten beim Eintreffen der Nachricht in einen Spam-Ordner mit verdächtigen Nachrichten verschieben (siehe später folgenden Abschnitt).

== Eingangsserver konfigurieren ==

Um die Maileingangsserver mit Spamassassin lassen sich pro Domain konfigurieren, indem die MX-Records im DNS-Zonefile gegenüber dem Default-Zonefile angepasst werden.

Im Zonefile entfällt der Platzhalter "{MX_RR}". Stattdessen werden die folgenden MX-Records eingefügt:

<syntaxhighlight lang=bash>
{DOM_HOSTNAME}. IN MX 10 smailin1.hostsharing.net.
{DOM_HOSTNAME}. IN MX 10 smailin2.hostsharing.net.
{DOM_HOSTNAME}. IN MX 10 smailin3.hostsharing.net.
</syntaxhighlight>

Zur Änderung der DNS-Zone siehe: https://www.hostsharing.net/doc/managed-operations-platform/zonefile/
Wer sich die Aktion auf der Shell nicht zutraut, möge bitte den "Webmaster on Demand" beauftragen.

== Spam-Ordner ==

Mit dem folgenden Filter können Nachrichten, die von Spamassassin markiert wurden, automatisch in einen Spam-Ordner verschoben werden.

[[Datei:2025-02-07 Sievefilter-Spam.png|960x480px|links|alternativtext=Screenshot Filterregel zum Spam Aussortieren|Filter in Roundcube einrichten]]

= Alternative 3: SecureMX zubuchen =

Über unseren Domain-Anbieter "Partnergate" bietet Hostsharing als dritte Alternative die kommerzielle Spam-Appliance von Cisco an. Das Produkt heißt bei Partnergate "SecureMX": https://www.hostsharing.net/loesungen/email/spam-abwehr/

Die Nutzung von SecureMX ist kostenpflichtig und wird auf Wunsch von Service eingerichtet.

Es ist zu beachten, dass bei der Nutzung von SecureMX alle eingehenden E-Mail Nachrichten über Server geleitet werden, die nicht unter der Kontrolle von Hostsharing stehen. Dieser Sachverhalt muss von Mitglied ggf. dateschutzrechtlich bewertet werden.

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

Spamfilter

2025-02-07T14:17:00Z

Peh00: /* Spamassassin Konfigurieren */

Einrichtung, Konfiguration und Optimierung eines Spamfilters auf den Hostsharing Servern. Der Artikel beschreibt zwei Möglichkeiten:

1. Die Einrichtung von Apamassassin für das persönliche Postfach

2. Die Nutzung der "smailin"-Server für eine komplette Domain

= Alternative 1: Persönlichen Spamfilter einrichten =

Hier geht es darum, wie Personen mit (grundlegenden) kenntnissen in der Shell-Bedienung für ihr persönliches Postfach einen Spam-Filter einrichten können.

== Spamassassin Konfigurieren ==

Der Spamfilter "Spamassassin" ist bei HS vorinstalliert und kann wie auf der Seite [[Procmail]] beschrieben für eine Mailbox eingebunden werden.
Alternativ kann "spamc", das Kommando zur Nutzung des Spamassassin-Daemon, auch einfach in der Datei ".forward" eines Mail-Users aufgerufen werden:

<syntaxhighlight lang=bash>
"|/usr/bin/spamc -U /var/run/spamd -e /usr/lib/dovecot/deliver"
</syntaxhighlight>

Der Effekt: Spammassassin schreibt seine Testergebnisse in die Headerzeilen jeder E-Mail und leitet die E-Mails weiter an das Programm "deliver" aus dem Dovecot-Paket. Das Sortieren von Spam-EMail in einen Spam-Ordner lässt sich mit Sieve-Filtern umsetzen.

In dieser Variante kann man Spamassassin individuell konfigurieren. Dazu legt man im $HOME des Mailbox-Account ein Verzeichnis "$HOME/.spamassassin" an. Die Konfiguration erfolgt in der Datei "$HOME/.spamassassin/user_prefs".

Konfigurationsbeispiel:

<syntaxhighlight lang=bash>
required_score 4.0
report_safe 0
use_bayes 1
bayes_auto_learn 1
skip_rbl_checks 0
use_razor2 1
use_pyzor 1
</syntaxhighlight>

== Bayesfilter anlernen ==

Wenn der Bayesfilter eingeschaltet ist, macht es Sinn den Filter mit den Befehlen

<syntaxhighlight lang=bash>
sa-learn --spam <platzhalter-spam-nachricht>
sa-learn --ham <platzhalter-erwünschte-nachricht>
</syntaxhighlight>

anzulernen. Ein Bash-Skript für das Erlernen von Spam/Nonspam kann wie folgt aussehen:

<syntaxhighlight lang=bash>
!/bin/bash
#
# Learn Spam from Maildir folder Junk/LearnSpam
#
mkdir -p ${HOME}/sa-learn-tmp
cd ${HOME}/Maildir/.Junk.LearnSpam/cur/
for JUNK in $( ls ); do zcat ${JUNK} > ${HOME}/sa-learn-tmp/$( echo ${JUNK} | cut -d'.' -f2 ).eml ; done
cd ${HOME}/
sa-learn --spam ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/Maildir/.Junk.LearnSpam/cur/*
#
# Learn Non-Spam from Maildir folder Junk/LearnHam
#
cd ${HOME}/Maildir/.Junk.LearnHam/cur/
for HAM in $( ls ); do zcat ${HAM} > ${HOME}/sa-learn-tmp/$( echo ${HAM} | cut -d'.' -f2 ).eml ; done
cd ${HOME}/
sa-learn --ham ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/Maildir/.Junk.LearnHam/cur/*
</syntaxhighlight>

Die Empfängerin der Nachrichten / der Empfänger füttert den Lernprozess, indem Spam-Nachrichten in den Ordner "Spam/LearnSpam" verschoben werden und indem gute Nachrichten in den Ordner "Spam/LearnHam" kopiert werden.

Das Skript wird über einen systemd-Timer täglich ausgefürt.

= Alternative 2: Maileingangsserver mit Spamfilter nutzen =

Zusätzlich zu den vorkonfigurierte Maileingangsservern betriebt Hostsharing seit einigen Jahren einen zweiten Satz von Maileingangsservern, bei denen Spamassassin bereits beim Annehmen einer E-Mail ausgeführt wird. Eingehende Nachrichten mit eindeutiger Bewertung als Spam werden bereits im SMTP-Dialog abgewiesen. Nachrichten mit einem Spam-Score über 5 Punkten werden angenommen und zugestellt. Spamassassin für die Bewertung für diese Nachrichten in die Header der Nachricht ein, zum Beispiel:

<syntaxhighlight lang=bash>
X-Spam-Flag: YES
X-Spam-Score: 6.263
X-Spam-Level: ******
</syntaxhighlight>

Anhand dieser Zeilen kann man in Roundcube Filter einrichten, die die Nachrichten beim Eintreffen der Nachricht in einen Spam-Ordner mit verdächtigen Nachrichten verschieben (siehe später folgenden Abschnitt).

== Eingangsserver konfigurieren ==

Um die Maileingangsserver mit Spamassassin lassen sich pro Domain konfigurieren, indem die MX-Records im DNS-Zonefile gegenüber dem Default-Zonefile angepasst werden.

Im Zonefile entfällt der Platzhalter "{MX_RR}". Stattdessen werden die folgenden MX-Records eingefügt:

<syntaxhighlight lang=bash>
{DOM_HOSTNAME}. IN MX 10 smailin1.hostsharing.net.
{DOM_HOSTNAME}. IN MX 10 smailin2.hostsharing.net.
{DOM_HOSTNAME}. IN MX 10 smailin3.hostsharing.net.
</syntaxhighlight>

Zur Änderung der DNS-Zone siehe: https://www.hostsharing.net/doc/managed-operations-platform/zonefile/
Wer sich die Aktion auf der Shell nicht zutraut, möge bitte den "Webmaster on Demand" beauftragen.

== Spam-Ordner ==

Mit dem folgenden Filter können Nachrichten, die von Spamassassin markiert wurden, automatisch in einen Spam-Ordner verschoben werden.

[[Datei:2025-02-07 Sievefilter-Spam.png|960x480px|links|alternativtext=Screenshot Filterregel zum Spam Aussortieren|Filter in Roundcube einrichten]]

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

Spamfilter

2025-02-07T14:16:23Z

Peh00: /* Alternative 1: Persönlichen Spamfilter einrichten */

Einrichtung, Konfiguration und Optimierung eines Spamfilters auf den Hostsharing Servern. Der Artikel beschreibt zwei Möglichkeiten:

1. Die Einrichtung von Apamassassin für das persönliche Postfach

2. Die Nutzung der "smailin"-Server für eine komplette Domain

= Alternative 1: Persönlichen Spamfilter einrichten =

Hier geht es darum, wie Personen mit (grundlegenden) kenntnissen in der Shell-Bedienung für ihr persönliches Postfach einen Spam-Filter einrichten können.

== Spamassassin Konfigurieren ==

Der Spamfilter "Spamassassin" ist bei HS vorinstalliert und kann wie auf der Seite [[Procmail]] beschrieben für eine Mailbox eingebunden werden.
Alternativ kann "spamc", das Kommando zur Nutzung des Spamassassin-Daemon, auch einfach in der Datei ".forward" eines Mail-Users aufgerufen werden:

<syntaxhighlight lang=bash>
"|/usr/bin/spamc -U /var/run/spamd -e /usr/lib/dovecot/deliver"
</syntaxhighlight>

Der Effekt: Spammassassin schreibt seine Testergebnisse in die Headerzeilen jeder E-Mail und leitet die E-Mails weiter an das Programm "deliver" aus dem Dovecot-Paket. Das Sortieren von Spam-EMail in einen Spam-Ordner lässt sich mit Sieve-Filtern umsetzen.

In dieser Variante kann man Spamassassin individuell konfigurieren. Dazu legt man im $HOME des Mailbox-Account ein Verzeichnis "$HOME/.spamassassin" an. Die Konfiguration erfolgt in der Datei "$HOME/.spamassassin/user_prefs".

Konfigurationsbeispiel:

<syntaxhighlight lang=bash>
required_score 3.8
report_safe 0
use_bayes 1
bayes_auto_learn 1
skip_rbl_checks 0
use_razor2 1
use_pyzor 1
</syntaxhighlight>

== Bayesfilter anlernen ==

Wenn der Bayesfilter eingeschaltet ist, macht es Sinn den Filter mit den Befehlen

<syntaxhighlight lang=bash>
sa-learn --spam <platzhalter-spam-nachricht>
sa-learn --ham <platzhalter-erwünschte-nachricht>
</syntaxhighlight>

anzulernen. Ein Bash-Skript für das Erlernen von Spam/Nonspam kann wie folgt aussehen:

<syntaxhighlight lang=bash>
!/bin/bash
#
# Learn Spam from Maildir folder Junk/LearnSpam
#
mkdir -p ${HOME}/sa-learn-tmp
cd ${HOME}/Maildir/.Junk.LearnSpam/cur/
for JUNK in $( ls ); do zcat ${JUNK} > ${HOME}/sa-learn-tmp/$( echo ${JUNK} | cut -d'.' -f2 ).eml ; done
cd ${HOME}/
sa-learn --spam ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/Maildir/.Junk.LearnSpam/cur/*
#
# Learn Non-Spam from Maildir folder Junk/LearnHam
#
cd ${HOME}/Maildir/.Junk.LearnHam/cur/
for HAM in $( ls ); do zcat ${HAM} > ${HOME}/sa-learn-tmp/$( echo ${HAM} | cut -d'.' -f2 ).eml ; done
cd ${HOME}/
sa-learn --ham ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/Maildir/.Junk.LearnHam/cur/*
</syntaxhighlight>

Die Empfängerin der Nachrichten / der Empfänger füttert den Lernprozess, indem Spam-Nachrichten in den Ordner "Spam/LearnSpam" verschoben werden und indem gute Nachrichten in den Ordner "Spam/LearnHam" kopiert werden.

Das Skript wird über einen systemd-Timer täglich ausgefürt.

= Alternative 2: Maileingangsserver mit Spamfilter nutzen =

Zusätzlich zu den vorkonfigurierte Maileingangsservern betriebt Hostsharing seit einigen Jahren einen zweiten Satz von Maileingangsservern, bei denen Spamassassin bereits beim Annehmen einer E-Mail ausgeführt wird. Eingehende Nachrichten mit eindeutiger Bewertung als Spam werden bereits im SMTP-Dialog abgewiesen. Nachrichten mit einem Spam-Score über 5 Punkten werden angenommen und zugestellt. Spamassassin für die Bewertung für diese Nachrichten in die Header der Nachricht ein, zum Beispiel:

<syntaxhighlight lang=bash>
X-Spam-Flag: YES
X-Spam-Score: 6.263
X-Spam-Level: ******
</syntaxhighlight>

Anhand dieser Zeilen kann man in Roundcube Filter einrichten, die die Nachrichten beim Eintreffen der Nachricht in einen Spam-Ordner mit verdächtigen Nachrichten verschieben (siehe später folgenden Abschnitt).

== Eingangsserver konfigurieren ==

Um die Maileingangsserver mit Spamassassin lassen sich pro Domain konfigurieren, indem die MX-Records im DNS-Zonefile gegenüber dem Default-Zonefile angepasst werden.

Im Zonefile entfällt der Platzhalter "{MX_RR}". Stattdessen werden die folgenden MX-Records eingefügt:

<syntaxhighlight lang=bash>
{DOM_HOSTNAME}. IN MX 10 smailin1.hostsharing.net.
{DOM_HOSTNAME}. IN MX 10 smailin2.hostsharing.net.
{DOM_HOSTNAME}. IN MX 10 smailin3.hostsharing.net.
</syntaxhighlight>

Zur Änderung der DNS-Zone siehe: https://www.hostsharing.net/doc/managed-operations-platform/zonefile/
Wer sich die Aktion auf der Shell nicht zutraut, möge bitte den "Webmaster on Demand" beauftragen.

== Spam-Ordner ==

Mit dem folgenden Filter können Nachrichten, die von Spamassassin markiert wurden, automatisch in einen Spam-Ordner verschoben werden.

[[Datei:2025-02-07 Sievefilter-Spam.png|960x480px|links|alternativtext=Screenshot Filterregel zum Spam Aussortieren|Filter in Roundcube einrichten]]

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

Spamfilter

2025-02-07T14:15:29Z

Peh00: /* Spamassassin Konfigurieren */

Einrichtung, Konfiguration und Optimierung eines Spamfilters auf den Hostsharing Servern. Der Artikel beschreibt zwei Möglichkeiten:

1. Die Einrichtung von Apamassassin für das persönliche Postfach

2. Die Nutzung der "smailin"-Server für eine komplette Domain

= Alternative 1: Persönlichen Spamfilter einrichten =

Hier geht es darum, wie Personen mit (grundlegenden) kenntnissen in der Shell-Bedienung für ihr persönliches Postfach einen Spam-Filter einrichten können.

== Spamassassin Konfigurieren ==

Der Spamfilter "Spamassassin" ist bei HS vorinstalliert und kann wie auf der Seite [[Procmail]] beschrieben für eine Mailbox eingebunden werden.
Alternativ kann "spamc", das Kommando zur Nutzung des Spamassassin-Daemon, auch einfach in der Datei ".forward" eines Mail-Users aufgerufen werden:

<syntaxhighlight lang=bash>
"|/usr/bin/spamc -U /var/run/spamd -e /usr/lib/dovecot/deliver"
</syntaxhighlight>

Der Effekt: Spammassassin schreibt seine Testergebnisse in die Headerzeilen jeder E-Mail und leitet die E-Mails weiter an das Programm "deliver" aus dem Dovecot-Paket. Das Sortieren von Spam-EMail in einen Spam-Ordner lässt sich mit Sieve-Filtern umsetzen.

In dieser Variante kann man Spamassassin individuell konfigurieren. Dazu legt man im $HOME des Mailbox-Account ein Verzeichnis "$HOME/.spamassassin" an. Die Konfiguration erfolgt in der Datei "$HOME/.spamassassin/user_prefs".

Konfigurationsbeispiel:

<syntaxhighlight lang=bash>
required_score 3.8
report_safe 0
use_bayes 1
bayes_auto_learn 1
skip_rbl_checks 0
use_razor2 1
use_pyzor 1
</syntaxhighlight>

Wenn der Bayesfilter eingeschaltet ist, macht es Sinn den Filter mit den Befehlen

<syntaxhighlight lang=bash>
sa-learn --spam <platzhalter-spam-nachricht>
sa-learn --ham <platzhalter-erwünschte-nachricht>
</syntaxhighlight>

anzulernen. Ein Bash-Skript für das Erlernen von Spam/Nonspam kann wie folgt aussehen:

<syntaxhighlight lang=bash>
!/bin/bash
#
# Learn Spam from Maildir folder Junk/LearnSpam
#
mkdir -p ${HOME}/sa-learn-tmp
cd ${HOME}/Maildir/.Junk.LearnSpam/cur/
for JUNK in $( ls ); do zcat ${JUNK} > ${HOME}/sa-learn-tmp/$( echo ${JUNK} | cut -d'.' -f2 ).eml ; done
cd ${HOME}/
sa-learn --spam ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/Maildir/.Junk.LearnSpam/cur/*
#
# Learn Non-Spam from Maildir folder Junk/LearnHam
#
cd ${HOME}/Maildir/.Junk.LearnHam/cur/
for HAM in $( ls ); do zcat ${HAM} > ${HOME}/sa-learn-tmp/$( echo ${HAM} | cut -d'.' -f2 ).eml ; done
cd ${HOME}/
sa-learn --ham ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/Maildir/.Junk.LearnHam/cur/*
</syntaxhighlight>

Die Empfängerin der Nachrichten / der Empfänger füttert den Lernprozess, indem Spam-Nachrichten in den Ordner "Spam/LearnSpam" verschoben werden und indem gute Nachrichten in den Ordner "Spam/LearnHam" kopiert werden.

Das Skript wird über einen systemd-Timer täglich ausgefürt.

= Alternative 2: Maileingangsserver mit Spamfilter nutzen =

Zusätzlich zu den vorkonfigurierte Maileingangsservern betriebt Hostsharing seit einigen Jahren einen zweiten Satz von Maileingangsservern, bei denen Spamassassin bereits beim Annehmen einer E-Mail ausgeführt wird. Eingehende Nachrichten mit eindeutiger Bewertung als Spam werden bereits im SMTP-Dialog abgewiesen. Nachrichten mit einem Spam-Score über 5 Punkten werden angenommen und zugestellt. Spamassassin für die Bewertung für diese Nachrichten in die Header der Nachricht ein, zum Beispiel:

<syntaxhighlight lang=bash>
X-Spam-Flag: YES
X-Spam-Score: 6.263
X-Spam-Level: ******
</syntaxhighlight>

Anhand dieser Zeilen kann man in Roundcube Filter einrichten, die die Nachrichten beim Eintreffen der Nachricht in einen Spam-Ordner mit verdächtigen Nachrichten verschieben (siehe später folgenden Abschnitt).

== Eingangsserver konfigurieren ==

Um die Maileingangsserver mit Spamassassin lassen sich pro Domain konfigurieren, indem die MX-Records im DNS-Zonefile gegenüber dem Default-Zonefile angepasst werden.

Im Zonefile entfällt der Platzhalter "{MX_RR}". Stattdessen werden die folgenden MX-Records eingefügt:

<syntaxhighlight lang=bash>
{DOM_HOSTNAME}. IN MX 10 smailin1.hostsharing.net.
{DOM_HOSTNAME}. IN MX 10 smailin2.hostsharing.net.
{DOM_HOSTNAME}. IN MX 10 smailin3.hostsharing.net.
</syntaxhighlight>

Zur Änderung der DNS-Zone siehe: https://www.hostsharing.net/doc/managed-operations-platform/zonefile/
Wer sich die Aktion auf der Shell nicht zutraut, möge bitte den "Webmaster on Demand" beauftragen.

== Spam-Ordner ==

Mit dem folgenden Filter können Nachrichten, die von Spamassassin markiert wurden, automatisch in einen Spam-Ordner verschoben werden.

[[Datei:2025-02-07 Sievefilter-Spam.png|960x480px|links|alternativtext=Screenshot Filterregel zum Spam Aussortieren|Filter in Roundcube einrichten]]

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

Spamfilter

2025-02-07T14:11:32Z

Peh00: /* Alternative 1: Persönlichen Spamfilter einrichten */

Einrichtung, Konfiguration und Optimierung eines Spamfilters auf den Hostsharing Servern. Der Artikel beschreibt zwei Möglichkeiten:

1. Die Einrichtung von Apamassassin für das persönliche Postfach

2. Die Nutzung der "smailin"-Server für eine komplette Domain

= Alternative 1: Persönlichen Spamfilter einrichten =

Hier geht es darum, wie Personen mit (grundlegenden) kenntnissen in der Shell-Bedienung für ihr persönliches Postfach einen Spam-Filter einrichten können.

== Spamassassin Konfigurieren ==

Der Spamfilter "Spamassassin" ist bei HS vorinstalliert und kann wie auf der Seite [[Procmail]] beschrieben für eine Mailbox eingebunden werden.
Alternativ kann "spamc", das Kommando zur Nutzung des Spamassassin-Daemon, auch einfach in der Datei ".forward" eines Mail-Users aufgerufen werden:

<syntaxhighlight lang=bash>
"|/usr/bin/spamc -U /var/run/spamd -e /usr/lib/dovecot/deliver"
</syntaxhighlight>

Der Effekt: Spammassassin schreibt seine Testergebnisse in die Headerzeilen jeder E-Mail und leitet die E-Mails weiter an das Programm "deliver" aus dem Dovecot-Paket. Das Sortieren von Spam-EMail in einen Spam-Ordner lässt sich mit Sieve-Filtern umsetzen.

In dieser Variante kann man Spamassassin individuell konfigurieren. Dazu legt man im $HOME des Mailbox-Account ein Verzeichnis "$HOME/.spamassassin" an. Die Konfiguration erfolgt in der Datei "$HOME/.spamassassin/user_prefs".

Konfigurationsbeispiel:

<syntaxhighlight lang=bash>
required_score 3.8
report_safe 0
use_bayes 1
bayes_auto_learn 1
skip_rbl_checks 0
use_razor2 1
use_pyzor 1
</syntaxhighlight>

Wenn der Bayesfilter eingeschaltet ist, macht es Sinn den Filter mit den Befehlen

<syntaxhighlight lang=bash>
sa-learn --spam <platzhalter-spam-nachricht>
sa-learn --ham <platzhalter-erwünschte-nachricht>
</syntaxhighlight>

anzulernen. Ein Bash-Skript für das Erlernen von Spam/Nonspam kann wie folgt aussehen:

<syntaxhighlight lang=bash>
!/bin/bash
#
# Learn Spam from Maildir folder Junk/LearnSpam
#
mkdir -p ${HOME}/sa-learn-tmp
cd ${HOME}/Maildir/.Junk.LearnSpam/cur/
for JUNK in $( ls ); do zcat ${JUNK} > ${HOME}/sa-learn-tmp/$( echo ${JUNK} | cut -d'.' -f2 ).eml ; done
cd ${HOME}/
sa-learn --spam ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/Maildir/.Junk.LearnSpam/cur/*
#
# Learn Non-Spam from Maildir folder Junk/LearnHam
#
cd ${HOME}/Maildir/.Junk.LearnHam/cur/
for HAM in $( ls ); do zcat ${HAM} > ${HOME}/sa-learn-tmp/$( echo ${HAM} | cut -d'.' -f2 ).eml ; done
cd ${HOME}/
sa-learn --ham ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/Maildir/.Junk.LearnHam/cur/*
</syntaxhighlight>

= Alternative 2: Maileingangsserver mit Spamfilter nutzen =

Zusätzlich zu den vorkonfigurierte Maileingangsservern betriebt Hostsharing seit einigen Jahren einen zweiten Satz von Maileingangsservern, bei denen Spamassassin bereits beim Annehmen einer E-Mail ausgeführt wird. Eingehende Nachrichten mit eindeutiger Bewertung als Spam werden bereits im SMTP-Dialog abgewiesen. Nachrichten mit einem Spam-Score über 5 Punkten werden angenommen und zugestellt. Spamassassin für die Bewertung für diese Nachrichten in die Header der Nachricht ein, zum Beispiel:

<syntaxhighlight lang=bash>
X-Spam-Flag: YES
X-Spam-Score: 6.263
X-Spam-Level: ******
</syntaxhighlight>

Anhand dieser Zeilen kann man in Roundcube Filter einrichten, die die Nachrichten beim Eintreffen der Nachricht in einen Spam-Ordner mit verdächtigen Nachrichten verschieben (siehe später folgenden Abschnitt).

== Eingangsserver konfigurieren ==

Um die Maileingangsserver mit Spamassassin lassen sich pro Domain konfigurieren, indem die MX-Records im DNS-Zonefile gegenüber dem Default-Zonefile angepasst werden.

Im Zonefile entfällt der Platzhalter "{MX_RR}". Stattdessen werden die folgenden MX-Records eingefügt:

<syntaxhighlight lang=bash>
{DOM_HOSTNAME}. IN MX 10 smailin1.hostsharing.net.
{DOM_HOSTNAME}. IN MX 10 smailin2.hostsharing.net.
{DOM_HOSTNAME}. IN MX 10 smailin3.hostsharing.net.
</syntaxhighlight>

Zur Änderung der DNS-Zone siehe: https://www.hostsharing.net/doc/managed-operations-platform/zonefile/
Wer sich die Aktion auf der Shell nicht zutraut, möge bitte den "Webmaster on Demand" beauftragen.

== Spam-Ordner ==

Mit dem folgenden Filter können Nachrichten, die von Spamassassin markiert wurden, automatisch in einen Spam-Ordner verschoben werden.

[[Datei:2025-02-07 Sievefilter-Spam.png|960x480px|links|alternativtext=Screenshot Filterregel zum Spam Aussortieren|Filter in Roundcube einrichten]]

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

Spamfilter

2025-02-07T14:06:43Z

Peh00: /* Spamassassin Konfigurieren */

Einrichtung, Konfiguration und Optimierung eines Spamfilters auf den Hostsharing Servern. Der Artikel beschreibt zwei Möglichkeiten:

1. Die Einrichtung von Apamassassin für das persönliche Postfach

2. Die Nutzung der "smailin"-Server für eine komplette Domain

= Alternative 1: Persönlichen Spamfilter einrichten =

Hier geht es darum, wie Personen mit (grundlegenden) kenntnissen in der Shell-Bedienung für ihr persönliches Postfach einen Spam-Filter einrichten können.

== Spamassassin Konfigurieren ==

Der Spamfilter "Spamassassin" ist bei HS vorinstalliert und kann wie auf der Seite [[Procmail]] beschrieben für eine Mailbox eingebunden werden.
Alternativ kann "spamc", das Kommando zur Nutzung des Spamassassin-Daemon, auch einfach in der Datei ".forward" eines Mail-Users aufgerufen werden:

<syntaxhighlight lang=bash>
"|/usr/bin/spamc -U /var/run/spamd -e /usr/lib/dovecot/deliver"
</syntaxhighlight>

Der Effekt: Spammassassin schreibt seine Testergebnisse in die Headerzeilen jeder E-Mail und leitet die E-Mails weiter an das Programm "deliver" aus dem Dovecot-Paket. Das Sortieren von Spam-EMail in einen Spam-Ordner lässt sich mit Sieve-Filtern umsetzen.

In dieser Variante kann man Spamassassin individuell konfigurieren. Dazu legt man im $HOME des Mailbox-Account ein Verzeichnis "$HOME/.spamassassin" an. Die Konfiguration erfolgt in der Datei "$HOME/.spamassassin/user_prefs".

Konfigurationsbeispiel:

<syntaxhighlight lang=bash>
required_score 3.8
report_safe 0
use_bayes 1
bayes_auto_learn 1
skip_rbl_checks 0
use_razor2 1
use_pyzor 1
</syntaxhighlight>

Wenn der Bayesfilter eingeschaltet ist, macht es Sinn den Filter mit den Befehlen

<syntaxhighlight lang=bash>
sa-learn --spam <platzhalter-spam-nachricht>
sa-learn --ham <platzhalter-erwünschte-nachricht>
</syntaxhighlight>

anzulernen.

= Alternative 2: Maileingangsserver mit Spamfilter nutzen =

Zusätzlich zu den vorkonfigurierte Maileingangsservern betriebt Hostsharing seit einigen Jahren einen zweiten Satz von Maileingangsservern, bei denen Spamassassin bereits beim Annehmen einer E-Mail ausgeführt wird. Eingehende Nachrichten mit eindeutiger Bewertung als Spam werden bereits im SMTP-Dialog abgewiesen. Nachrichten mit einem Spam-Score über 5 Punkten werden angenommen und zugestellt. Spamassassin für die Bewertung für diese Nachrichten in die Header der Nachricht ein, zum Beispiel:

<syntaxhighlight lang=bash>
X-Spam-Flag: YES
X-Spam-Score: 6.263
X-Spam-Level: ******
</syntaxhighlight>

Anhand dieser Zeilen kann man in Roundcube Filter einrichten, die die Nachrichten beim Eintreffen der Nachricht in einen Spam-Ordner mit verdächtigen Nachrichten verschieben (siehe später folgenden Abschnitt).

== Eingangsserver konfigurieren ==

Um die Maileingangsserver mit Spamassassin lassen sich pro Domain konfigurieren, indem die MX-Records im DNS-Zonefile gegenüber dem Default-Zonefile angepasst werden.

Im Zonefile entfällt der Platzhalter "{MX_RR}". Stattdessen werden die folgenden MX-Records eingefügt:

<syntaxhighlight lang=bash>
{DOM_HOSTNAME}. IN MX 10 smailin1.hostsharing.net.
{DOM_HOSTNAME}. IN MX 10 smailin2.hostsharing.net.
{DOM_HOSTNAME}. IN MX 10 smailin3.hostsharing.net.
</syntaxhighlight>

Zur Änderung der DNS-Zone siehe: https://www.hostsharing.net/doc/managed-operations-platform/zonefile/
Wer sich die Aktion auf der Shell nicht zutraut, möge bitte den "Webmaster on Demand" beauftragen.

== Spam-Ordner ==

Mit dem folgenden Filter können Nachrichten, die von Spamassassin markiert wurden, automatisch in einen Spam-Ordner verschoben werden.

[[Datei:2025-02-07 Sievefilter-Spam.png|960x480px|links|alternativtext=Screenshot Filterregel zum Spam Aussortieren|Filter in Roundcube einrichten]]

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

Spamfilter

2025-02-07T14:03:09Z

Peh00: /* Spamassassin Konfigurieren */

Einrichtung, Konfiguration und Optimierung eines Spamfilters auf den Hostsharing Servern. Der Artikel beschreibt zwei Möglichkeiten:

1. Die Einrichtung von Apamassassin für das persönliche Postfach

2. Die Nutzung der "smailin"-Server für eine komplette Domain

= Alternative 1: Persönlichen Spamfilter einrichten =

Hier geht es darum, wie Personen mit (grundlegenden) kenntnissen in der Shell-Bedienung für ihr persönliches Postfach einen Spam-Filter einrichten können.

== Spamassassin Konfigurieren ==

Der Spamfilter "Spamassassin" ist bei HS vorinstalliert und kann wie auf der Seite [[Procmail]] beschrieben für eine Mailbox eingebunden werden.
Alternativ kann "spamc", das Kommando zur Nutzung des Spamassassin-Daemon, auch einfach in der Datei ".forward" eines Mail-Users aufgerufen werden:

<syntaxhighlight lang=bash>
"|/usr/bin/spamc -U /var/run/spamd -e /usr/lib/dovecot/deliver"
</syntaxhighlight>

Der Effekt: Spammassassin schreibt seine Testergebnisse in die Headerzeilen jeder E-Mail und leitet die E-Mails weiter an das Programm "deliver" aus dem Dovecot-Paket. Das Sortieren von Spam-EMail in einen Spam-Ordner lässt sich mit Sieve-Filtern umsetzen.

In dieser Variante kann man Spamassassin individuell konfigurieren. Dazu legt man im $HOME des Mailbox-Account ein Verzeichnis "$HOME/.spamassassin" an. Die Konfiguration erfolgt in der Datei "$HOME/.spamassassin/user_prefs".

Konfigurationsbeispiel:

<syntaxhighlight lang=bash>
required_score 3.8
report_safe 0
use_bayes 1
bayes_auto_learn 1
skip_rbl_checks 0
use_razor2 1
use_pyzor 1
</syntaxhighlight>

= Alternative 2: Maileingangsserver mit Spamfilter nutzen =

Zusätzlich zu den vorkonfigurierte Maileingangsservern betriebt Hostsharing seit einigen Jahren einen zweiten Satz von Maileingangsservern, bei denen Spamassassin bereits beim Annehmen einer E-Mail ausgeführt wird. Eingehende Nachrichten mit eindeutiger Bewertung als Spam werden bereits im SMTP-Dialog abgewiesen. Nachrichten mit einem Spam-Score über 5 Punkten werden angenommen und zugestellt. Spamassassin für die Bewertung für diese Nachrichten in die Header der Nachricht ein, zum Beispiel:

<syntaxhighlight lang=bash>
X-Spam-Flag: YES
X-Spam-Score: 6.263
X-Spam-Level: ******
</syntaxhighlight>

Anhand dieser Zeilen kann man in Roundcube Filter einrichten, die die Nachrichten beim Eintreffen der Nachricht in einen Spam-Ordner mit verdächtigen Nachrichten verschieben (siehe später folgenden Abschnitt).

== Eingangsserver konfigurieren ==

Um die Maileingangsserver mit Spamassassin lassen sich pro Domain konfigurieren, indem die MX-Records im DNS-Zonefile gegenüber dem Default-Zonefile angepasst werden.

Im Zonefile entfällt der Platzhalter "{MX_RR}". Stattdessen werden die folgenden MX-Records eingefügt:

<syntaxhighlight lang=bash>
{DOM_HOSTNAME}. IN MX 10 smailin1.hostsharing.net.
{DOM_HOSTNAME}. IN MX 10 smailin2.hostsharing.net.
{DOM_HOSTNAME}. IN MX 10 smailin3.hostsharing.net.
</syntaxhighlight>

Zur Änderung der DNS-Zone siehe: https://www.hostsharing.net/doc/managed-operations-platform/zonefile/
Wer sich die Aktion auf der Shell nicht zutraut, möge bitte den "Webmaster on Demand" beauftragen.

== Spam-Ordner ==

Mit dem folgenden Filter können Nachrichten, die von Spamassassin markiert wurden, automatisch in einen Spam-Ordner verschoben werden.

[[Datei:2025-02-07 Sievefilter-Spam.png|960x480px|links|alternativtext=Screenshot Filterregel zum Spam Aussortieren|Filter in Roundcube einrichten]]

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

Spamfilter

2025-02-07T13:57:04Z

Peh00: Intro

Spamfilter

2025-02-07T13:55:24Z

Peh00:

Einrichtung, Konfiguration und Optimierung eines Spamfilters auf den Hostsharing Servern.

= Alternative 1: Persönlichen Spamfilter einrichten =

Hier geht es darum, wie Personen mit (grundlegenden) kenntnissen in der Shell-Bedienung für ihr persönliches Postfach einen Spam-Filter einrichten können.

== Spamassassin Konfigurieren ==

Der Spamfilter "Spamassassin" ist bei HS vorinstalliert und kann wie auf der Seite [[Procmail]] beschrieben für eine Mailbox eingebunden werden.
Alternativ kann "spamc", das Kommando zur Nutzung des Spamassassin-Daemon, auch einfach in der Datei ".forward" eines Mail-Users aufgerufen werden:

<syntaxhighlight lang=bash>
"|/usr/bin/spamc -U /var/run/spamd -e /usr/lib/dovecot/deliver"
</syntaxhighlight>

Der Effekt: Spammassassin schreibt seine Testergebnisse in die Headerzeilen jeder E-Mail und leitet die E-Mails weiter an das Programm "deliver" aus dem Dovecot-Paket. Das Sortieren von Spam-EMail in einen Spam-Ordner lässt sich mit Sieve-Filtern umsetzen.

= Alternative 2: Maileingangsserver mit Spamfilter nutzen =

Zusätzlich zu den vorkonfigurierte Maileingangsservern betriebt Hostsharing seit einigen Jahren einen zweiten Satz von Maileingangsservern, bei denen Spamassassin bereits beim Annehmen einer E-Mail ausgeführt wird. Eingehende Nachrichten mit eindeutiger Bewertung als Spam werden bereits im SMTP-Dialog abgewiesen. Nachrichten mit einem Spam-Score über 5 Punkten werden angenommen und zugestellt. Spamassassin für die Bewertung für diese Nachrichten in die Header der Nachricht ein, zum Beispiel:

<syntaxhighlight lang=bash>
X-Spam-Flag: YES
X-Spam-Score: 6.263
X-Spam-Level: ******
</syntaxhighlight>

Anhand dieser Zeilen kann man in Roundcube Filter einrichten, die die Nachrichten beim Eintreffen der Nachricht in einen Spam-Ordner mit verdächtigen Nachrichten verschieben (siehe später folgenden Abschnitt).

== Eingangsserver konfigurieren ==

Um die Maileingangsserver mit Spamassassin lassen sich pro Domain konfigurieren, indem die MX-Records im DNS-Zonefile gegenüber dem Default-Zonefile angepasst werden.

Im Zonefile entfällt der Platzhalter "{MX_RR}". Stattdessen werden die folgenden MX-Records eingefügt:

<syntaxhighlight lang=bash>
{DOM_HOSTNAME}. IN MX 10 smailin1.hostsharing.net.
{DOM_HOSTNAME}. IN MX 10 smailin2.hostsharing.net.
{DOM_HOSTNAME}. IN MX 10 smailin3.hostsharing.net.
</syntaxhighlight>

Zur Änderung der DNS-Zone siehe: https://www.hostsharing.net/doc/managed-operations-platform/zonefile/
Wer sich die Aktion auf der Shell nicht zutraut, möge bitte den "Webmaster on Demand" beauftragen.

== Spam-Ordner ==

Mit dem folgenden Filter können Nachrichten, die von Spamassassin markiert wurden, automatisch in einen Spam-Ordner verschoben werden.

[[Datei:2025-02-07 Sievefilter-Spam.png|960x480px|links|alternativtext=Screenshot Filterregel zum Spam Aussortieren|Filter in Roundcube einrichten]]

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

Spamfilter

2025-02-07T13:53:46Z

Peh00: /* Maileingangsserver mit Spamfilter nutzen */

Einrichtung, Konfiguration und Optimierung eines Spamfilters auf den Hostsharing Servern.

= Persönlichen Spamfilter einrichten =

Hier geht es darum, wie Personen mit (grundlegenden) kenntnissen in der Shell-Bedienung für ihr persönliches Postfach einen Spam-Filter einrichten können.

== Spamassassin Konfigurieren ==

Der Spamfilter "Spamassassin" ist bei HS vorinstalliert und kann wie auf der Seite [[Procmail]] beschrieben für eine Mailbox eingebunden werden.
Alternativ kann "spamc", das Kommando zur Nutzung des Spamassassin-Daemon, auch einfach in der Datei ".forward" eines Mail-Users aufgerufen werden:

<syntaxhighlight lang=bash>
"|/usr/bin/spamc -U /var/run/spamd -e /usr/lib/dovecot/deliver"
</syntaxhighlight>

Der Effekt: Spammassassin schreibt seine Testergebnisse in die Headerzeilen jeder E-Mail und leitet die E-Mails weiter an das Programm "deliver" aus dem Dovecot-Paket. Das Sortieren von Spam-EMail in einen Spam-Ordner lässt sich mit Sieve-Filtern umsetzen.

= Maileingangsserver mit Spamfilter nutzen =

Zusätzlich zu den vorkonfigurierte Maileingangsservern betriebt Hostsharing seit einigen Jahren einen zweiten Satz von Maileingangsservern, bei denen Spamassassin bereits beim Annehmen einer E-Mail ausgeführt wird. Eingehende Nachrichten mit eindeutiger Bewertung als Spam werden bereits im SMTP-Dialog abgewiesen. Nachrichten mit einem Spam-Score über 5 Punkten werden angenommen und zugestellt. Spamassassin für die Bewertung für diese Nachrichten in die Header der Nachricht ein, zum Beispiel:

<syntaxhighlight lang=bash>
X-Spam-Flag: YES
X-Spam-Score: 6.263
X-Spam-Level: ******
</syntaxhighlight>

Anhand dieser Zeilen kann man in Roundcube Filter einrichten, die die Nachrichten beim Eintreffen der Nachricht in einen Spam-Ordner mit verdächtigen Nachrichten verschieben (siehe später folgenden Abschnitt).

== Eingangsserver konfigurieren ==

Um die Maileingangsserver mit Spamassassin lassen sich pro Domain konfigurieren, indem die MX-Records im DNS-Zonefile gegenüber dem Default-Zonefile angepasst werden.

Im Zonefile entfällt der Platzhalter "{MX_RR}". Stattdessen werden die folgenden MX-Records eingefügt:

<syntaxhighlight lang=bash>
{DOM_HOSTNAME}. IN MX 10 smailin1.hostsharing.net.
{DOM_HOSTNAME}. IN MX 10 smailin2.hostsharing.net.
{DOM_HOSTNAME}. IN MX 10 smailin3.hostsharing.net.
</syntaxhighlight>

Zur Änderung der DNS-Zone siehe: https://www.hostsharing.net/doc/managed-operations-platform/zonefile/
Wer sich die Aktion auf der Shell nicht zutraut, möge bitte den "Webmaster on Demand" beauftragen.

== Spam-Ordner ==

Mit dem folgenden Filter können Nachrichten, die von Spamassassin markiert wurden, automatisch in einen Spam-Ordner verschoben werden.

[[Datei:2025-02-07 Sievefilter-Spam.png|960x480px|links|alternativtext=Screenshot Filterregel zum Spam Aussortieren|Filter in Roundcube einrichten]]

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

Spamfilter

2025-02-07T13:45:23Z

Peh00:

Einrichtung, Konfiguration und Optimierung eines Spamfilters auf den Hostsharing Servern.

= Persönlichen Spamfilter einrichten =

Hier geht es darum, wie Personen mit (grundlegenden) kenntnissen in der Shell-Bedienung für ihr persönliches Postfach einen Spam-Filter einrichten können.

== Spamassassin Konfigurieren ==

Der Spamfilter "Spamassassin" ist bei HS vorinstalliert und kann wie auf der Seite [[Procmail]] beschrieben für eine Mailbox eingebunden werden.
Alternativ kann "spamc", das Kommando zur Nutzung des Spamassassin-Daemon, auch einfach in der Datei ".forward" eines Mail-Users aufgerufen werden:

<syntaxhighlight lang=bash>
"|/usr/bin/spamc -U /var/run/spamd -e /usr/lib/dovecot/deliver"
</syntaxhighlight>

Der Effekt: Spammassassin schreibt seine Testergebnisse in die Headerzeilen jeder E-Mail und leitet die E-Mails weiter an das Programm "deliver" aus dem Dovecot-Paket. Das Sortieren von Spam-EMail in einen Spam-Ordner lässt sich mit Sieve-Filtern umsetzen.

= Maileingangsserver mit Spamfilter nutzen =

Zusätzlich zu den vorkonfigurierte maileingangsservern betriebt Hostsharing seit einigen Jahren einen zweiten Satz von Maileingangsservern, bei denen Spamassassin bereits beim Annehmen einer E-Mail ausgeführt wird. Eingehende Nachrichten mit eindeutiger Bewertung als Spam werden bereits im SMTP-Dialog abgewiesen. Nachrichten mit einem Spam-Score über 5 Punkten werden angenommen und zugestellt. Spamassassin für die Bewertung für diese Nachrichten in die Header der Nachricht ein, zum Beispiel:

<syntaxhighlight lang=bash>
X-Spam-Flag: YES
X-Spam-Score: 6.263
X-Spam-Level: ******
</syntaxhighlight>

Anhand dieser Zeilen kann man in Roundcube Filter einrichten, die die Nachrichten beim Eintreffen der Nachricht in einen Spam-Ordner mit verdächtigen Nachrichten verschieben (siehe folgender Abschnitt).

== Spam-Ordner ==

Mit dem folgenden Filter können Nachrichten, die von Spamassassin markiert wurden, automatisch in einen Spam-Ordner verschoben werden.

[[Datei:2025-02-07 Sievefilter-Spam.png|960x480px|links|alternativtext=Screenshot Filterregel zum Spam Aussortieren|Filter in Roundcube einrichten]]

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

Spamfilter

2025-02-07T13:29:15Z

Peh00: Screenshot Sieve Filter in Roundcube

Datei:2025-02-07 Sievefilter-Spam.png

2025-02-07T13:23:23Z

Peh00: Eigener Screenshot der Roundcube Installation bei Hostsharing Sieve Filter zum Aussortieren von Nachrichten mit "X-Spam"-Headern

== Beschreibung ==
Eigener Screenshot der Roundcube Installation bei Hostsharing

Sieve Filter zum Aussortieren von Nachrichten mit "X-Spam"-Headern

Spamfilter

2025-02-07T13:21:26Z

Peh00: Seite aufgeräumt

Spamfilter

2025-02-07T13:01:54Z

Peh00: Typo

Einrichtung, Konfiguration und Optimierung eines Spamfilters auf den Hostsharing Servern.

= Spamassassin Konfigurieren =

Der Spamfilter "Spamassassin" ist bei HS vorinstalliert und kann wie auf der Seite [[Procmail]] beschrieben für eine Mailbox eingebunden werden.
Alternativ kann "spamc", das Kommando zur Nutzung des Spamassassin-Daemon, auch einfach in der Datei ".forward" eines Mail-Users aufgerufen werden:

<syntaxhighlight lang=bash>
"|/usr/bin/spamc -U /var/run/spamd -e /usr/lib/dovecot/deliver"
</syntaxhighlight>

Der Effekt: Spammassassin schreibt seine Testergebnisse in die Headerzeilen jeder E-Mail und leitet die E-Mails weiter an das Programm "deliver" aus dem Dovecot-Paket. Das Sortieren von Spam-EMail in einen Spam-Ordner lässt sich mit Sieve-Filtern umsetzen.

ToDo: Anpassung Konfiguration, Filtertraining

= Mitteilungen über aussortierte Emails erzeugen lassen =

Spamcheck Verzeichnis im Homeverzeichnis anlegen,

<syntaxhighlight lang=bash>
mkdir spamcheck
cd spamcheck
</syntaxhighlight>

und dort drei Skriptdateien anlegen und deren Voreinstellungen anpassen:

<syntaxhighlight lang=bash line>
cat > check <<EOF
#!/bin/sh
#----------------------------------------------------------------------------------------
# send spam mailfolder infomail
# (c) 04/2004 by ff, webmaster@ff-newmedia.net
#----------------------------------------------------------------------------------------
#set -x
version="0.4 0405201035 (modified)"
mailuser=$1
mailpath="Maildir/.Spam/"
checkmaildir="spamcheck/checkmaildir"
listmaildir="spamcheck/listmaildir"
mailhost="h02"
maildomain="hostsharing.net"
purgetime="7"

if ($checkmaildir $mailpath)
then
mailbox_status=`$listmaildir $mailpath`
# send infomail
(
echo "From: spamcheck <admin@xyz00.$maildomain>"
echo "To: $mailuser <$mailuser@$mailhost.$maildomain>"
echo "Subject: Status des Spam-Ordners"
echo
echo
echo "$mailbox_status"
echo
echo
echo "Bitte pruefen ob evtl. erwuenschte Nachrichten aussortiert wurden."
echo "Zugriff auf das Postfach ist IMAP oder Webmail moeglich."
echo "(https://webmail.hostsharing.net)"
echo
echo
echo "-- "
echo "created by spamcheck $version"
)|/usr/lib/sendmail $mailuser@$mailhost.$maildomain
else
exit 1
fi

exit 0
EOF
</syntaxhighlight>

<syntaxhighlight lang=bash line>
cat > checkmaildir <<EOF
#!/usr/bin/perl
#----------------------------------------------------------------------------------------
# send spam mailfolder infomail - check if maildir exists
# (c) 05/2004 by ff, webmaster@ff-newmedia.net
# based on mdfrm (c) 1996, Matthew C. Mead
#----------------------------------------------------------------------------------------

$maildir = shift;

if (!$maildir) {
$maildir = $ENV{'MAILDIR'};
}

if (!$maildir) {
$maildir = "$ENV{'HOME'}/.Maildir";
}

$maildir =~ s/^=/$ENV{'HOME'}\/Mail\//;

# Kein Spamordner vorhanden - Errorcode 1
if (!(-d $maildir && -r $maildir && -x $maildir && -d "$maildir/cur" &&
-r "$maildir/cur" && -x "$maildir/cur" && -d "$maildir/new" &&
-r "$maildir/new" && -x "$maildir/new")) {
exit 1;
}

# Anderenfalls nachsehen ob Mails vorhanden sind
opendir(DIR, "$maildir/cur");
@tmpfiles = map{$_ = "$maildir/cur/$_"} grep{!/(^\.$)|(^\.\.$)/} readdir(DIR);
@msgfiles = @tmpfiles;
closedir(DIR);
opendir(DIR, "$maildir/new");
@tmpfiles = map{$_ = "$maildir/new/$_"} grep{!/(^\.$)|(^\.\.$)/} readdir(DIR);
push(@msgfiles, @tmpfiles);
closedir(DIR);

# Wenn keine Mails vorhanden - Errorcode 1
if (!@msgfiles) {
exit 1;
}

# Wenn Mails vorhanden - Errorcode 0
exit 0;
EOF
</syntaxhighlight>

<syntaxhighlight lang=bash line>
cat > listmaildir <<EOF
#!/usr/bin/perl
#----------------------------------------------------------------------------------------
# send spam mailfolder infomail - list maildir contents
# (c) 05/2004 by ff, webmaster@ff-newmedia.net
# based on mdfrm (c) 1996, Matthew C. Mead.
#----------------------------------------------------------------------------------------
$hours = 24; #Anzeigen von Mails, deren mtime hoechstens $hours Stunden in der Vergangenheit liegt

use Date::Parse;
use Date::Format;

$maildir = shift;

if ($maildir eq "-h") {
print "usage: mdfrm /path/to/Maildir\n";
print " mdfrm =Maildir == mdfrm ~/Mail/Maildir\n";
print " otherwise, mdfrm defaults to \$MAILDIR\n";
print " otherwise, mdfrm defaults to ~/.Maildir\n";
exit;
}

if (!$maildir) {
$maildir = $ENV{'MAILDIR'};
}

if (!$maildir) {
$maildir = "$ENV{'HOME'}/.Maildir";
}

$maildir =~ s/^=/$ENV{'HOME'}\/Mail\//;

if (!(-d $maildir && -r $maildir && -x $maildir && -d "$maildir/cur" &&
-r "$maildir/cur" && -x "$maildir/cur" && -d "$maildir/new" &&
-r "$maildir/new" && -x "$maildir/new")) {
# faellt weg, da checkmaildir bereits ueberprueft
# print "Kein Spamordner in \"$maildir\" vorhanden. Sie haben offensichtlich noch keine Spammails erhalten.\n";
exit 1;
}

opendir(DIR, "$maildir/cur");
@tmpfiles = map{$_ = "$maildir/cur/$_"} grep{!/(^\.$)|(^\.\.$)/} readdir(DIR);
@msgfiles = @tmpfiles;
closedir(DIR);
opendir(DIR, "$maildir/new");
@tmpfiles = map{$_ = "$maildir/new/$_"} grep{!/(^\.$)|(^\.\.$)/} readdir(DIR);
push(@msgfiles, @tmpfiles);
closedir(DIR);

@msgs = ( );

foreach $file (@msgfiles) {
# wirkliches Alter der Mail
$mtime = (stat($file))[9];

$from = "";
$subject = "";
$date = 0;
$hits = 0;

open(INPUT, sprintf("zcat %s |",$file));

FILEINPUT:
while(<INPUT>) {

if (/^From:\s+(.*)$/i) {
$from = $1;
next FILEINPUT;
}

if (/^Subject:\s+(.*)$/i) {
$subject = $1;
next FILEINPUT;
}

if (/^Date:\s+(.*)$/i) {
$date = $1;
next FILEINPUT;
}

if (/^X-Spam-Status: Yes, hits=+(.*)$/i) {
$hits = $1;
next FILEINPUT;
}

if (/^\s*$/) {
last FILEINPUT;
}

if ($from && $subject && $date && $hits) {
last FILEINPUT;
}

}

close(INPUT);

@tmp = ( str2time($date), $from, $subject, $mtime, $hits );
push(@msgs, [ @tmp ]);
}

$oldest = time - $hours * 3600; # Berechnen des Timestamps now - $hours

$o = 0;

foreach $msg (@msgs){
if ($msg->[3] >= $oldest) { # Innerhalb der letzten $hours aussortierte Mails
$o++;
}

$i++; # alle Mails
}

if ($i==0) { # Wenn keine Mail da sind, Errorcode 1
exit 1;
}

print("Insgesamt befinden sich ", $i, " E-Mails in Ihrem Trash-Ordner.\n");
print("In den letzen ", $hours, " Stunden wurden ", $o, " Spam-E-Mails
aussortiert.\n\n");
if ($o==0) { exit 0; }
print("Datum (mtime) Absender Betreff Hits\n");
print("-----------------------------------------------------------------------");

foreach $msg (sort {$b->[3] <=> $a->[3]} @msgs) { # Sortierung vorher auf 0/0
if ($msg->[3] >= $oldest) {
if ($msg->[1] =~ /\s*"*([^"]*)"*\s*\<[a-zA-Z0-9._%-=]+@[a-zA-Z0-9._%-=]+\>/) {
$from = $1;
} elsif ($msg->[1] =~ /[a-zA-z0-9._%-=]+@[a-zA-Z0-9._%-=]+.*$"*([^"]*)"*$/) {
$from = $1;
} else {
$from = $msg->[1];
}

# Datum ausgeben
if (time2str("%d",$msg->[3]) <=> $olddate) {
print("\n");
}

# Urspruengliches aus der Mail extrahiertes Datum, sinnlos weil oft gefaelscht
# printf("%-12s ", time2str("%d.%m.%y %H:%M",$msg->[0]));
printf("%-12s ", time2str("%d.%m.%y %H:%M",$msg->[3]));

$olddate = time2str("%d",$msg->[3]);

# From ausgeben
if (length($from) <= 20) {
printf("%-20s ", $from);
} else {
printf("%-.20s ", $from);
}

# um *****SPAM***** bereinigtes Subject ausgeben
@sub = $msg->[2];
if (length(@sub) <= 27) {
printf("%-27s ", @sub);
} else {
printf("%-.27s ", @sub);
}

# Punkte
if (length($msg->[4]) <= 4) {
printf("%-4s\n", $msg->[4]);
} else {
printf("%-.4s\n", $msg->[4]);
}

}
}

exit 0;
EOF
</syntaxhighlight>

Und diese ausführbar machen:
<syntaxhighlight lang=bash>
chmod a+x check checkmaildir listmaildir
</syntaxhighlight>

Anschließend einen [[Cron]]job anlegen, der check für den Mailboxuser aufruft:

<syntaxhighlight lang=bash>
#Spam Verzeichnis checken
51 5 * * * sleep $[ ($RANDOM % 120) ]; spamcheck/check xyz00-otto
</syntaxhighlight>

= Automatisches löschen aussortierter Emails =

ToDo: Emails nach einer bestimmten Zeit löschen.

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

Nextcloud

2025-02-03T12:56:06Z

Peh00: fix logrotate.service

= 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-27.1.2.zip
unzip nextcloud-27.1.2.zip
rm nextcloud-27.1.2.zip
mkdir data tmp
chmod 700 data tmp
</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. '''In Verbindung mit einem Managed Webspace''' muss für Redis als eigener Serverdienst RAM gebucht werden und ist '''kostenpflichtig'''. Siehe zu Kosten im Webspace Konfigurator unter: https://www.hostsharing.net/angebote/managed-webspace/ – '''Arbeitsspeicher für eigene Serverdienste'''.

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>

Mit einem weiteren Timer für die regelmäßigen Hintergrundaufgaben von Nextcloud lässt sie sich noch etwas beschleunigen:

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

[Service]
Type=oneshot
ExecStart=php8.2 /home/pacs/xyz00/users/cloud/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.

[[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/updater
xyz00-cloud@h00:~/nextcloud/updater$ chmod u+x updater.phar
xyz00-cloud@h00:~/nextcloud/updater$ ./updater.phar
</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
</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
</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 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>

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

DKIM

2025-01-08T11:04:14Z

Peh00: Neuer Domainkey fuer DKIM

[[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 ddes 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 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]

Mlmmj

2025-01-03T11:43:07Z

Peh00: fix link

[http://www.mlmmj.org/ mlmmj], angeblich eine Abkürzung für "Mailing List Management Made Joyful", ist ein Programm, mit dem in einem Hostsharing Paket E-Mail-Verteiler realisiert werden kann.

Wer noch nicht weiß, was ein E-Mail-Verteiler machen soll oder wie, lese vielleicht auch den Wikipedia-Artikel:
[http://de.wikipedia.org/wiki/Mailingliste Mailingliste]

Eine leistungsfähigere Alternative zu mlmmj könnte [[Mailman_3_installieren|Mailman 3]] sein.

Diese Anleitung beschreibt die Einrichtung einer Mailingliste für eine Domain in einem Hostsharing-Webspace.

== Voraussetzungen ==

Das Debian Paket [http://packages.debian.org/search?keywords=mlmmj mlmmj] ist auf den Shared-Hosting-Servern bereits installiert. (Wer die Software selbst kompilieren möchte kann aktuellen Source-Code bei [https://codeberg.org/mlmmj/mlmmj codeberg.org] finden.)

Für den Betrieb der Mailingliste empfiehlt sich das Anlegen eines eigenen Users für diesen Zweck mit hsadmin.

In dieser Anleitung heißt das Paket ''xyz00'' und der für Mailinglisten eingesetzte User ''xyz00-list''.

Die E-Mail-Adresse der einzurichtende Mailing-Liste soll ''discuss@example.org'' sein. Den lokalen Teil dieser Adresse, ''discuss'', ist der Listenname. Der Listenname darf auf keinen Fall das Plus-Zeichen (+) enthalten, weil dies ein Sonderbedeutung für die Listensteuerung hat: ''mlmmj'' wird nämlich Befehle der Abonnenten über erweiterte Adressen annehmen, wie z.B. ''discuss+help@example.org''.

Die Domain ''example.org'' muss dazu bei einem beliebigen User im Paket ''xyz00'' [[aufgeschaltet]] sein. ("Aufgeschaltet" bedeutet, daß diese Domain bei Hostsharing gehostet wird und der Domainname als Verzeichnis /home/pacs/xyz00/*User*/doms/example.org/ erscheint.)

== Einrichtung ==

Ich melde mich über SSH auf der Hostsharing-Console als der Paketuser ''xyz00'' an.

Im Shell kann ich dann durch den Befehl ''hsscript -i'' das Verwaltungswerkzeug [[hsadmin]] interaktiv ausführen:

<syntaxhighlight lang=shell>
xyz00@h03:~$ hsscript -i
Password: *************
xyz00@hsadmin>
</syntaxhighlight>

In ''hsadmin'' werden User und E-Mail-Adresse angelegt.

<syntaxhighlight lang=shell>
xyz00@hsadmin> user.add({set:{name:'xyz00-list',comment:'Mailingliste Discuss',shell:'/bin/bash',password:'geheimnis'}})
xyz00@hsadmin> emailaddress.add({set:{target:'xyz00-list',localpart:'discuss',domain:'example.org'}})
xyz00@hsadmin> bye
</syntaxhighlight>

Mit dem Parameter "target" wird die für diese Adresse eingehende Post zunächst in das Postfach des Users xyz00-list abgelegt.

Für den User xyz00-list lege ich in seinem Heimat-Verzeichnis das Unterverzeichnis <tt>mlmmj</tt> an:

<syntaxhighlight lang=shell>
mkdir /home/pacs/xyz00/users/list/mlmmj
</syntaxhighlight>

Dann lege ich die Mailingliste mit folgendem Kommando an:

<syntaxhighlight lang=shell>
mlmmj-make-ml -L discuss -s /home/pacs/xyz00/users/list/mlmmj
</syntaxhighlight>

Das Skript ''mlmmj-make-ml'' fragt weitere Parameter der Mailingliste ab:

<syntaxhighlight lang=output line>
The Domain for the List? [] : example.org
The emailaddress of the list owner? [postmaster] : webmaster@example.org
For the list texts you can choose between the following languages or
give an absolute path to a directory containing the texts.
Available languages:
cz da de en es fr it nl ru
The path to texts for the list? [en] : de
</syntaxhighlight>

Das skript ''mlmmj-make-ml'' legt daraufhin unter "/home/pacs/xyz00/users/list/mlmmj" ein Verzeichnis "discuss" an, das die Datenstruktur zur Verwaltung der Mailingliste enthält.

Weitere Konfigurationen der Liste erfolgen durch das Anlegen von Dateien im
Verzeichnis "/home/pacs/xyz00/users/list/mlmmj/discuss/control".
Die Konfigurationsmöglichkeiten finden Sie auf der [http://mlmmj.org/TUNABLES.html Internetseite von mlmmj].

Damit mlmmj die Verteilung der Post übernimmt, muß ich im Heimat-Verzeichnis des users xyz00-list die Datei <tt>.forward</tt> mit folgenden Inhalt (INKLUSIVE der Anführungszeichen!) erstellen:

<syntaxhighlight lang=shell>
"|/usr/bin/mlmmj-receive -L /home/pacs/xyz00/users/list/mlmmj/discuss/"
</syntaxhighlight>

(Ja, ''receive'' schreibt sich mit ''-ei-'', aber mlmmj hält einen symbolischen Link bereit für diejenigen, die in englischer Rechtschreibung unsicher sind:)

<syntaxhighlight lang=shell>
xyz00-list@h03:~$ ls -la /usr/bin/mlmmj-rec*
-rwxr-xr-x 1 root root 27104 Sep 25 2018 /usr/bin/mlmmj-receive
lrwxrwxrwx 1 root root 13 Sep 25 2018 /usr/bin/mlmmj-recieve -> mlmmj-receive
</syntaxhighlight>

Die <tt>.forward</tt>-Datei sorgt dafür, dass eingehende E-Mails an das User-Postfach an das Programm ''mlmmj-recieve'' übergeben werden.

Für regelmäßige Aufgaben der Listen-Managers definiere ich den systemd timer wie folgt (immer noch als ''xyz00-list''):

~/.config/systemd/user/mlmmj.service
<syntaxhighlight lang=ini>
[Unit]
Description=mlmmj maintenance

[Service]
Type=oneshot
ExecStart=/usr/bin/mlmmj-maintd -d /home/pacs/xyz00/users/list/mlmmj -F
</syntaxhighlight>

~/.config/systemd/user/mlmmj.timer
<syntaxhighlight lang=ini>
[Unit]
Description=mlmmj maintenance

[Timer]
OnCalendar=*/4:28
Persistent=True

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

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

Zum Schluss rufe ich das Skript mlmmj-sub auf, um die E-Mail-Adressen der gewünschten Abonnenten des Verteilers einzutragen:

<syntaxhighlight lang=shell>
/usr/bin/mlmmj-sub -L /home/pacs/xyz00/users/list/mlmmj/discuss -a klaus.muster@gmx.de -c
/usr/bin/mlmmj-sub -L /home/pacs/xyz00/users/list/mlmmj/discuss -a sabine.beispiel@arcor.de -c
</syntaxhighlight>

Dabei bewirkt "-c", dass der Abonnent eine Begrüßungs-Nachricht erhält. Alternativ kann man "-C" (großes C) angeben: dann muss der Abonnent das Abo durch Antworten auf die Nachricht bestätigen.

== weitere Optionen ==

Noch ein paar Dinge, die Sie möglicherweise einstellen wollen:

Ein Prefix in der Betreffzeile setzen, z.B.: "[discuss]".

<syntaxhighlight lang=shell>
echo "[discuss]" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/prefix
</syntaxhighlight>

Wenn die Liste nur E-Mails von eingetragenen Abonnenten weiterleiten soll:

<syntaxhighlight lang=shell>
touch /home/pacs/xyz00/users/list/mlmmj/discuss/control/subonlypost
</syntaxhighlight>

Damit der Listen-Owner weitere Abonnements bestätigen muss:

<syntaxhighlight lang=shell>
touch /home/pacs/xyz00/users/list/mlmmj/discuss/control/submod
</syntaxhighlight>

Einen "Reply-To:"-Header setzen, damit Antwort-Mails standardmäßig an die Mailing-Liste gehen:

<syntaxhighlight lang=shell>
echo "Reply-To:" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/delheaders
echo "Reply-To: discuss@example.org" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/customheaders
</syntaxhighlight>

Beim Massenversand, z.B. bei Newslettern, nutzen Sie bitte möglichst den dedizierten Postausgangsserver für den Massenversand. Dadurch tragen Sie dazu bei, die Reputation unserer regulären Ausgangsserver aufrechtzuerhalten.

Um dies zu tun, setzen Sie den SMTP-Port entsprechend:

<syntaxhighlight lang=shell>
echo "4025" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/smtpport
</syntaxhighlight>

Weitere Konfigurationsvariante des Ausgangsserver sind unter https://www.hostsharing.net/doc/managed-operations-platform/email/ zu finden.

Weitere Möglichkeiten finden Sie (wie oben bereits angegeben)
auf der [http://mlmmj.org/TUNABLES.html Internetseite von mlmmj].

=== Achtung: DKIM ===

Mlmmj gibt die Möglichkeit, mit '''delheaders''' und '''customheaders''' die Header der durchgeleiteten Mail umfangreich zu ändern. Allerdings tragen Mails heute häufig kryptografische Signaturen der sendenden Mailserver. Eine DKIM-Signatur sichert damit in der Regel die Integrität des Body der Mail sowie der Header ''Subject:'', ''From:'', ''To:'', ''Date:'', ''From'', und oft auch ''Reply-To:''.

Wird zum Beispiel mit einem Prefix das Subject geändert oder ein Footer angehängt, macht dies die DKIM-Signatur ungültig. Das ist für viele Mailprovider ein Grund die Nachricht abzuweisen. (siehe auch Diskussions-Seite zum Artikel)

== Zur Konfiguration im Browser ==

Die Original-Distribution von ''mlmmj'' enthält ein paar einfache PHP- und Perl-Skripte. Das sind Beispiele für Subscribe-/Unsubscribe-Formulare, ein Admin-Formular zum Eintragen und Löschen von Abonnements und eine Seite mit der gesamten Listen-Konfiguration.

Wer es sich ansehen möchte:

Als Paket-Admin eine Domain aufschalten:
<syntaxhighlight lang=shell>
hsscript -u xyz00 -e "domain.add({set:{name:'lists.example.org',user:'xyz00-list'}})"
</syntaxhighlight>
Und weiter als "xyz00-list".

Download der neuesten Version der Sourcen von mlmmj von http://mlmmj.org/downloads/ (noch besser: Download des aktuellen Debian-Pakets von [https://packages.debian.org/bookworm/all/mlmmj-php-web-admin/download debian.org]: da sind einige veraltete PHP-Ausdrücke schon herausgepatcht) und diese in einem temporären Verzeichnis entpacken (mit tar oder dpkg-deb).

Unter "/mlmmj-$versionsnummer/contrib/web/php-admin/", oder beim .deb-Paket unter "usr/share/mlmmj-...", findet sich die PHP-Admin-Anwendung. Also ...

* den Inhalt diese Verzeichnisses nach "/home/pacs/xyz00/users/list/doms/lists.example.org/" packen;
* in "/home/pacs/xyz00/users/list/doms/lists.example.org/conf/config.php" die Variable "$topdir" anpassen;
* die Dateien aus "/home/pacs/xyz00/users/list/doms/lists.example.org/htdocs/" nach "/home/pacs/xyz00/users/list/doms/lists.example.org/htdocs-ssl/" verschieben;
* Beim .deb-Paket die config.php, die templates/ und die tunables.pl aus etc/ nach example.org/conf/ verschieben;
* in "/home/pacs/xyz00/users/list/mlmmj" und in "/home/pacs/xyz00/users/list/doms/lists.example.org/htdocs-ssl/" eine ".htaccess" mit folgendem Inhalt ablegen:
<syntaxhighlight lang=apache line>
Require valid-user
AuthType Basic
AuthName "mlmmj web-interface"
AuthUserFile /home/pacs/xyz00/users/list/doms/lists.example.org/etc/htpasswd
</syntaxhighlight>
* Und schließlich die "htpasswd"-Datei anlegen.

cd /home/pacs/xyz00/users/list/doms/lists.example.org/etc/
htpasswd -c htpasswd listadmin

* Ein Passwort angeben.

Nun enthält diese PHP-Anwendung, wenn man sie nicht dem Debian-Paket entnommen hat, leider noch eine Zeile, die schon seit PHP 7 nicht mehr lauffähig ist. Also muß man noch

* in <tt>.../htdocs-ssl/index.php</tt> folgende Änderung vornehmen:
<syntaxhighlight lang=diff line>
@@ -38,4 +38,5 @@
# use scandir to have alphabetical order
foreach (scandir($topdir) as $file) {
- if (!ereg("^\.",$file))
+# ereg obsolete!! Vormals: if (!ereg("^\.",$file))
+ if (!preg_match('/^\./',$file))
{
</syntaxhighlight>
und das Ergebnis auf https://lists.example.org anschauen.

== Mehrere Mailinglisten betreiben ==

Wenn mehrere Mailinglisten in einem Account und mit einer Admin-Oberfläche betrieben werden soll, empfiehlt sich die Nutzung von Procmail für den Aufruf von ''mlmmj'' für die jeweiligen Liste mit ihrem Daten-Verzeichnis.

Dazu trägt man in der Datei <tt>.forward</tt> statt des Aufrufs von ''mlmmj-recieve'' einen Aufruf von ''procmail'' ein:

<syntaxhighlight lang=shell>
|/usr/bin/procmail
</syntaxhighlight>

Die Konfiguration von Procmail kann generisch erfolgen. Dazu legt man eine Datei <tt>.procmailrc</tt> mit folgendem Inhalt ins $HOME des Users:

<syntaxhighlight lang=shell>
SHELL=/bin/sh
HOMEDIR=/home/pacs/xyz00/users/list
MAILDIR=/home/pacs/xyz00/users/list/Maildir
PMDIR=/home/pacs/xyz00/users/list
VERBOSE=yes
LOGFILE=/home/pacs/xyz00/users/list/var/procmail.log
DEFAULT

:0:
* ^X-Original-To: ()\/[^@+]+
|/usr/bin/mlmmj-receive -F -L /home/pacs/xyz00/users/list/mlmmj/${MATCH}/

:0
{ EXITCODE 67 }
</syntaxhighlight>

Bitte dafür sorgen, dass das Verzeichnis ''/home/pacs/xyz00/users/list/var'' existiert.

Der kryptische reguläre Ausdruck hinter dem Header ''X-Original-To:'' passt auf den Beginn der E-Mail-Adresse bis zum ersten ''@''- oder ''+''-Zeichen. In der Variable ''MATCH'' steht also der Name der Mailingliste, d.h. der Name der Verzeichnisses, in dem die Liste verwaltet wird.

Sehr wichtig ist die Zeile ''DEFAULT'' zu Beginn der ''.procmailrc''. Die Variable ''DEFAULT'' wird von ''procmail'' gesetzt. Wir sorgen mit dieser Zeile dafür, dass sie wieder undefiniert ist. Diese Variable wird intern von ''mlmmj'' benutzt, wenn sie gesetzt ist. Das führt in Kombination mit ''procmail'' zu Fehlfunktionen (vgl. Links).

===Groß- und Kleinschreibung===

Achtung, mit der Groß- und Kleinschreibung von Listennamen gibt es bei dieser Procmail-Lösung eine kleine Tücke. Procmail übernimmt in die Variable $MATCH genau die in der X-Original-To-Headerzeile vorgefundene Schreibweise, und diese kann denkbarerweise "Listen-Name" oder "listen-name" oder "Listen-name" sein. <tt>mlmmj</tt> hingegen wird diesen Wert in Unix-Manier mit dem genauen Verzeichnisnamen <tt>${HOME}/mlmmj/listen-name</tt> vergleichen, und bei unterschiedlicher Schreibweise die Mail nicht verteilen.

====Lösung 1====

Eine teilweise Lösung besteht darin, den Listennamen in dem <tt>mlmmj</tt>-Aufruf in der <tt>.procmailrc</tt> in Kleinbuchstaben umzuschreiben. Dann lautet das Rezept so:

<syntaxhighlight lang=shell>
:0:
* ^X-Original-To: ()\/[^@+]+
|/usr/bin/mlmmj-receive -F -L /home/pacs/xyz00/users/list/mlmmj/$(echo ${MATCH} | tr [:upper:] [:lower:])/
</syntaxhighlight>

Der Rest der Datei muß gleich bleiben, wie weiter oben angezeigt.

In diesem Fall müssen aber alle Mailing-Listen ohne Großbuchstaben im Namen angelegt werden!

(Man kann auch in <tt>${HOME}/mlmmj/</tt> durch kleingeschriebene Symlinks großgeschriebene Listennamen ansprechbar machen:

<syntaxhighlight lang=output>
xyz00-list@h02:~$ ls -lA mlmmj/
total 8
-rw-r--r-- 1 xyz00-list xyz00 148 Feb 1 16:56 .htaccess
lrwxrwxrwx 1 xyz00-list xyz00 10 Feb 2 18:01 mitglieder -> Mitglieder
drwxr-xr-x 15 xyz00-list xyz00 4096 Feb 2 16:53 Mitglieder
</syntaxhighlight>

====Lösung 2====

Bash kann bei der Auflösung von Variablen die Groß- und Kleinschreibung manipulieren. (Siehe dazu bei der Zeichenfolge <tt>,,</tt> in <tt>man bash</tt>.) Dann ist <tt>$(echo ${MATCH} | tr [:upper:] [:lower:])</tt> gleichbedeutend mit <tt>${MATCH,,}</tt>. Allerdings braucht procmail einige Überredung, um Bash zu verwenden.

<syntaxhighlight lang=shell>
SHELL=/bin/bash
SHELLMETAS=&|<>~;?*[{
HOMEDIR= ...

...

:0:
* ^X-Original-To: ()\/[^@+]+
|/usr/bin/mlmmj-receive -F -L /home/pacs/xyz00/users/list/mlmmj/${MATCH,,}/
</syntaxhighlight>

Die Tücke ist, daß procmail den in SHELL angegebenen Shell nur dann verwendet, wenn die Befehlszeile eines der in SHELLMETAS angegebenen Zeichen enthält. Und das '|' am Anfang der Zeile zählt dabei nicht! In diesem Beispiel ist es das Zeichen <tt>{</tt>, das den Einsatz von Bash auslöst.

Beide Lösungen scheinen zu funktionieren; Angabe ohne Gewähr.

== Links ==

* http://mlmmj.org/ Projektseite
* https://codeberg.org/mlmmj mlmmj auf Codeberg
* https://github.com/tchapi/mlmmj-simple-web-interface ein Admin-Interface in NodeJS
* [https://web.archive.org/web/20221228110514/https://www.tablix.org/~avian/blog/archives/2010/04/the_faulty_default/ https://www.tablix.org/~avian/blog/archives/2010/04/the_faulty_default/ (via web.archive.org)] Nutzung von mlmmj in Verbindung mit Procmail
* [https://gist.github.com/kboss/7c9593f0fd9219406226c4f11256b98a Einfaches Python-Script zum Massenimport aus einem Texfile.] Geht bestimmt auch eleganter mit purem Bash
* Ein Self-Service zum Subscriben/Unsubscriben lässt sich in Form von Mail-to-Links in Webseiten einbinden. Beispiele gibt es bei Hostsharing für die öffentlichen "public"-Mailinglisten: https://www.hostsharing.net/lists/public-discussion/ . Alternativ auf https://github.com/hblasum/mlmmj-php-web-simplified ein Webfrontend mit dem sich Benutzerinnen und Benutzer selbst ein-/austragen können (Vereinfachung von mlmmj-php-web von Christoph Thiel).

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Mailinglisten]]
[[Kategorie:E-Mail]]