Hostsharing Wiki - Benutzerbeiträge [de]

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

TLS Zertifikat mit LEGO

2024-12-23T12:41:18Z

Peh00: /* regelmäßige Verlängerung */

= TLS Zertifikat mit LEGO =

Für den zentralen Apache Webserver werden bei Hostsharing automatisch TLS Zertifikate über den Dienst "Lets Encrypt" erzeugt und verlängert. Das wird über die Domain-Option "letsencrypt" gesteuert.

Teilweise will man aber eigene Serverdienste betreiben, die nicht über HTTP hinter dem Apache-Proxy erreichbar sind. Beispiele dafür sind ein eigener XMPP Server oder ein Mumble Server. Für diese Server können die Nutzer:innen der Hostsharing Plattform sehr leicht TLS Zertifikate erzeugen, indem sie den zentral installierten LEGO-Bot nutzen.

== Einrichtung ==

Zunächst muss eine Domain vorhanden sein, auf die das Zertifikat ausgestellt werden soll und die im Webspace über HTTP erreichbar ist.

Ich nutze hier den Service-User "xyz00-mumble" als Beispiel. Bei diesem User sei die Domain "mumble.hs-example.de" aufgeschaltet.

Dann lösche ich bei der Domain die HTTP-Weiterleitungen und die www-Subdomain:

<syntaxhighlight lang=shell line>
rm -rf ~/doms/mumble.hs-example.de/subs/www \
~/doms/mumble.hs-example.de/subs-ssl/www \
~/doms/mumble.hs-example.de/htdocs/.htaccess \
~/doms/mumble.hs-example.de/htdocs-ssl/.htaccess
</syntaxhighlight>
Das erste Zertifikat wird mit dem folgenden Befehl erzeugt:
<syntaxhighlight lang=shell line>
/usr/bin/lego -d mumble.hs-example.de -a \
--email webmaster@mumble.hs-example.de -k ec256 \
--http.webroot $HOME/doms/mumble.hs-example.de/htdocs \
--http run
</syntaxhighlight>
Bei der erfolgreichen Ausführung diese Befehls wurde ein verstecktes Verzeichnis ".lego" angelegt. In diesem Verzeichnis befinden sich die Daten zum neu angelegten Letsencrypt-Account und das Zertifikat mit dem zugehörigen private key.

Die Daten des Zertifikates kann man wie folgt auslesen:
<syntaxhighlight lang=shell line>
openssl x509 -in .lego/certificates/mumble.hs-example.de.crt -noout -text
</syntaxhighlight>

== regelmäßige Verlängerung ==

Für die automatische Verlängerung des Zertifikats können wir einen Cronjob aufsetzen, der zum Beispiel täglich oder wöchentlich läuft:

<syntaxhighlight lang=shell line>
$ cat bin/lego-renew
#!/bin/bash
HOME=/home/pacs/xyz00/users/mumble
/usr/bin/lego -d mumble.hs-example.de -a \
--email webmaster@mumble.hs-example.de -k ec256 \
--http.webroot $HOME/doms/mumble.hs-example.de/htdocs \
--http renew
</syntaxhighlight>

Die Ausführung des Skriptes wird über einen systemd timer gesteuert:

''~/.config/systemd/user/lego_certificate.service''

<syntaxhighlight lang=ini line>
[Unit]
Description=renew lego certificate

[Service]
Type=oneshot
ExecStart=%h/bin/lego-renew
</syntaxhighlight>

''~/.config/systemd/user/lego_certificate.timer''

<syntaxhighlight lang=ini line>
[Unit]
Description=timer for lego certificate

[Timer]
OnCalendar=Thu 4:34
Persistent=True

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

Den Timer aktivieren und starten:

<syntaxhighlight lang=shell>
systemctl --user enable lego_certificate.timer
systemctl --user start lego_certificate.timer
</syntaxhighlight>

TLS Zertifikat mit LEGO

2024-12-23T12:39:14Z

Peh00: regelmäßige Verlängerung braucht sicher kein PHP

= TLS Zertifikat mit LEGO =

Für den zentralen Apache Webserver werden bei Hostsharing automatisch TLS Zertifikate über den Dienst "Lets Encrypt" erzeugt und verlängert. Das wird über die Domain-Option "letsencrypt" gesteuert.

Teilweise will man aber eigene Serverdienste betreiben, die nicht über HTTP hinter dem Apache-Proxy erreichbar sind. Beispiele dafür sind ein eigener XMPP Server oder ein Mumble Server. Für diese Server können die Nutzer:innen der Hostsharing Plattform sehr leicht TLS Zertifikate erzeugen, indem sie den zentral installierten LEGO-Bot nutzen.

== Einrichtung ==

Zunächst muss eine Domain vorhanden sein, auf die das Zertifikat ausgestellt werden soll und die im Webspace über HTTP erreichbar ist.

Ich nutze hier den Service-User "xyz00-mumble" als Beispiel. Bei diesem User sei die Domain "mumble.hs-example.de" aufgeschaltet.

Dann lösche ich bei der Domain die HTTP-Weiterleitungen und die www-Subdomain:

<syntaxhighlight lang=shell line>
rm -rf ~/doms/mumble.hs-example.de/subs/www \
~/doms/mumble.hs-example.de/subs-ssl/www \
~/doms/mumble.hs-example.de/htdocs/.htaccess \
~/doms/mumble.hs-example.de/htdocs-ssl/.htaccess
</syntaxhighlight>
Das erste Zertifikat wird mit dem folgenden Befehl erzeugt:
<syntaxhighlight lang=shell line>
/usr/bin/lego -d mumble.hs-example.de -a \
--email webmaster@mumble.hs-example.de -k ec256 \
--http.webroot $HOME/doms/mumble.hs-example.de/htdocs \
--http run
</syntaxhighlight>
Bei der erfolgreichen Ausführung diese Befehls wurde ein verstecktes Verzeichnis ".lego" angelegt. In diesem Verzeichnis befinden sich die Daten zum neu angelegten Letsencrypt-Account und das Zertifikat mit dem zugehörigen private key.

Die Daten des Zertifikates kann man wie folgt auslesen:
<syntaxhighlight lang=shell line>
openssl x509 -in .lego/certificates/mumble.hs-example.de.crt -noout -text
</syntaxhighlight>

== regelmäßige Verlängerung ==

Für die automatische Verlängerung des Zertifikats können wir einen Cronjob aufsetzen, der zum Beispiel täglich oder wöchentlich läuft:

<syntaxhighlight lang=shell line>
$ cat bin/lego-renew
#!/bin/bash
HOME=/home/pacs/xyz00/users/mumble
/usr/bin/lego -d mumble.hs-example.de -a \
--email webmaster@mumble.hs-example.de -k ec256 \
--http.webroot $HOME/doms/mumble.hs-example.de/htdocs \
--http renew
</syntaxhighlight>

Die Ausführung des Skriptes wird über einen systemd timer gesteuert:

''~/.config/systemd/user/lego_certificate.service''

<syntaxhighlight lang=ini line>
[Unit]
Description=renew lego certificate

[Service]
Type=oneshot
ExecStart=/home/pacs/xyz00/users/mumble/bin/lego-renew
</syntaxhighlight>

''~/.config/systemd/user/lego_certificate.timer''

<syntaxhighlight lang=ini line>
[Unit]
Description=timer for lego certificate

[Timer]
OnCalendar=Thu 4:34
Persistent=True

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

Den Timer aktivieren und starten:

<syntaxhighlight lang=shell>
systemctl --user enable lego_certificate.timer
systemctl --user start lego_certificate.timer
</syntaxhighlight>

Eigenes Python installieren

2021-05-21T08:40:10Z

Peh00: Typo

= Eigenes Python installieren =

Manchmal macht es Sinn eine eigene Python-Umgebung zu installieren. Gründe dafür können sein

* Unabhängigkeit vom System-Python
* Volle Kontrolle über eingesetzte Python-Packages
* Freie Auswahl der Python-Distribution (z. B. die neueste)

Ich empfehle Python mithilfe von [http://www.buildout.org/ buildout] zu installieren. Im folgenden wird die Vorgehensweise erläutert.

== Installation ==

[https://github.com/collective/buildout.python buildout.python] ist ein Projekt auf Github, dass sich zum Ziel gemacht hat, auf (allen) vielen Plattformen diverse Distributionen von Python zu kompilieren. Man klont das Projekt:

git clone git://github.com/collective/buildout.python.git ~/mypython
cd ~/mypython

Nun die buildout.cfg editieren: alle ungewollten Python-Distributionen auskommentieren (auch die pypy). Danach lässt man das Buildout durchlaufen.

python bootstrap.py
bin/buildout

Jetzt wird das Python runtergeladen, kompiliert und installiert.
Es lässt sich folgendermaßen aktivieren:

source ~/mypython/python-x.x/bin/activate

== Alternative ==

Ich kann nicht beurteilen, ob die Variante oben mit Buildout noch zum Ziel führt.
Ein Mitglied hatte Schwierigkeiten damit.

Ich würde (hier Python 3.9) so installieren:

mkdir /home/pacs/xyz00/opt
mkdir /home/pacs/xyz00/build
cd /home/pacs/xyz00/build
wget https://www.python.org/ftp/python/3.9.5/Python-3.9.5.tgz
tar xzf Python-3.9.5.tgz
cd Python-3.9.5
./configure --enable-optimizations --prefix=/home/pacs/xyz00/opt
make
make install
cd ..
rm -rf build

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

Eigenes Python installieren

2021-05-21T08:38:32Z

Peh00: Python mit configure,make

= Eigenes Python installieren =

Manchmal macht es Sinn eine eigene Python-Umgebung zu installieren. Gründe dafür können sein

* Unabhängigkeit vom System-Python
* Volle Kontrolle über eingesetzte Python-Packages
* Freie Auswahl der Python-Distribution (z. B. die neueste)

Ich empfehle Python mithilfe von [http://www.buildout.org/ buildout] zu installieren. Im folgenden wird die Vorgehensweise erläutert.

== Installation ==

[https://github.com/collective/buildout.python buildout.python] ist ein Projekt auf Github, dass sich zum Ziel gemacht hat, auf (allen) vielen Plattformen diverse Distributionen von Python zu kompilieren. Man klont das Projekt:

git clone git://github.com/collective/buildout.python.git ~/mypython
cd ~/mypython

Nun die buildout.cfg editieren: alle ungewollten Python-Distributionen auskommentieren (auch die pypy). Danach lässt man das Buildout durchlaufen.

python bootstrap.py
bin/buildout

Jetzt wird das Python runtergeladen, kompiliert und installiert.
Es lässt sich folgendermaßen aktivieren:

source ~/mypython/python-x.x/bin/activate

== Alternative ==

Ich kann nicht beurteilen, ob die Variante oben mit Buildout noch zum Ziel führt.
Ein Mitglied hatte Schwierigkeiten damit.

Ich würde (hier Python9) so installieren:

mkdir /home/pacs/xyz00/opt
mkdir /home/pacs/xyz00/build
cd /home/pacs/xyz00/build
wget https://www.python.org/ftp/python/3.9.5/Python-3.9.5.tgz
tar xzf Python-3.9.5.tgz
cd Python-3.9.5
./configure --enable-optimizations --prefix=/home/pacs/xyz00/opt
make
make install
cd ..
rm -rf build

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

Matrix Synapse installieren

2020-04-18T12:26:38Z

Peh00: Typo

Der Matrix Server ''Synapse'', der sogenannte 'Homeserver', ist aktuell die einzige vollständige serverseitige Implementierung des Matrix-Protokolls.

{{Textkasten|gelb|Work in Progress|Leider funktioniert die Server-zu-Server-Kommunikation von Synapse hinter dem Apache-Proxy mit den genannten Rewrite-Rules nicht. Bitten Sie dazu den Service, Ihren Apache VHost individuell für den Matrix Server anzupassen.
Weiterhin wird für die aktuelle Version von Synapse Python 3.8 benötigt. Es ist kein Problem sich ein Python 3.8 aus den Sourcen zu kompilieren. Das ist hier nicht noch nicht beschrieben.}}

Synapse wird bei Hostsharing als ''eigener Daemon'' betrieben. Der Betrieb ist im Shared Hosting anmelde- und kostenpflichtig. Daher emfpehlen wir für den Betrieb einen ''Managed Server''.

Diese Anleitung beschreibt, wie man den Matrix-Homeserver Synapse auf der Managed Hosting Plattform von Hostsharing installieren kann. Dabei sind die User-IDs nach dem Schema @user:beispiel.de aufgebaut, der Homeserver an sich ist unter matrix.beispiel.de erreichbar.

== Vorbereitungen ==

Mit Hilfe von HSAdmin werden angelegt:
# Ein User als Service-User mit ''/bin/bash'' als Shell, zum Beispiel Beispiel: ''xyz00-matrix''
# Eine Domain mit ''xyz00-matrix'' als Domain-Administrator, zum Beispiel ''matrix.beispiel.de''
# Einen Postgresql-User ''xyz00_matrixuser'' mit Passwort ''meinPasswort''
# Eine Postgresql-Datenbank ''xyz00_matrixdb'' mit Datenbank-Owner ''xyz00_matrixuser''

Verwendete IP-Ports der Server-Dienste:
# Monit: xyz00.hostsharing.net:32800
# Synapse: localhost:32801

== Installation von Synapse ==

Installationsanleitung basierend auf https://github.com/matrix-org/synapse/blob/master/INSTALL.md#installing-from-source

Als User ''xyz00-matrix" ein Python3 virtualenv erstellen

mkdir -p ~/synapse
virtualenv -p python3 ~/synapse/env
source ~/synapse/env/bin/activate
pip install --upgrade pip
pip install --upgrade setuptools

Synapse und Postgres-Dependencies installieren

pip install matrix-synapse[postgres]

Initiale Konfiguration mit richtigem server-name "beispiel.de" generieren, außerdem im laufenden Betrieb keine Statistiken an Matrix.org senden

cd ~/synapse
python -m synapse.app.homeserver --server-name beispiel.de --config-path homeserver.yaml --generate-config --report-stats=no

== Konfiguration von Synapse ==

In die initial generierte Konfiguration muss noch die Port- und Datenbank-Konfiguration eingetragen werden:

Port: Innerhalb der listener-section den Port 8008 auf 32801 (wie initial definiert) ändern, alles andere beibehalten:

- port: 32801
tls: false
bind_addresses: ['::1', '127.0.0.1']
type: http
x_forwarded: true

Postgres-Datenbank:

database:
# The database engine name
name: "psycopg2"
# Arguments to pass to the engine
args:
host: "localhost"
database: "xyz00_matrixdb"
user: "xyz00_matrixuser"
password: "meinPasswort"
cp_min: 5
cp_max: 10

== Starten der Dienste ==

Zum Start aller notwendigen Dienste wird in dieser Anleitung ''monit'' benutzt. Hier ein Beispiel für eine Datei ''.monitrc'' (überlange Zeilen werden hier im Wiki umgebrochen)

Das monitpassword auf jeden Fall durch ein sicheres Passwort ersetzen:

set daemon 60
with start delay 120
set logfile /home/pacs/xyz00/users/matrix/monit/var/monit.log
set idfile /home/pacs/xyz00/users/matrix/monit/var/monit.id
set statefile /home/pacs/xyz00/users/matrix/monit/var/monit.state
set mailserver localhost
set mail-format { from: monit@matrix.beispiel.de }
set alert matrix@matrix.beispiel.de
set httpd port 32800 address xyz00.hostsharing.net
allow matrix:monitpassword
check process synapse with pidfile /home/pacs/xyz00/users/matrix/synapse/homeserver.pid
start program "/bin/bash -c 'export VIRTUAL_ENV=$HOME/synapse/env && export PATH=$VIRTUAL_ENV/bin:$PATH && cd $HOME/synapse && synctl start'"
stop program "/bin/bash -c '/bin/kill $( cat $HOME/synapse/homeserver.pid )'"

== Cronjobs ==

''Cron'' wird für eine Aufgabe genutzt:
* Start von monit nach einem Server Reboot

Einrichten der crontab mit ''cronttab -e''

HOME=/home/pacs/xyz00/users/matrix
MAILTO=matrix@matrix.beispiel.de

@reboot /usr/bin/monit -c $HOME/.monitrc

== Einrichten des Apache VHost ==

Die ''~/doms/matrix.beispiel.de/.htaccess'' mit dem Editor der Wahl öffnen und
folgende Konfiguration einfügen:

DirectoryIndex disabled
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule .* http://localhost:32801%{REQUEST_URI} [NE,proxy]
RequestHeader set X-Forwarded-Proto "https"

== Well-Known unter beispiel.de ==

Damit die User-Accounts das Format @user:beispiel.de haben, der Server aber unter matrix.beispiel.de erreichbar ist, müssen noch folgende zwei Dateien unter der Domain beispiel.de abgelegt werden:

https://beispiel.de/.well-known/matrix/server
{
"m.server": "matrix.beispiel.de:443"
}

https://beispiel.de/.well-known/matrix/client
{
"m.homeserver": {
"base_url": "https://matrix.beispiel.de"
},
"m.identity_server": {
"base_url": "https://vector.im"
}
}

Für die muss noch der CORS-Header Access-Control-Allow-Origin "*" gesetzt werden, damit die Datei aus beliebigem Riot-Web im Browser abrufbar ist. Dazu in den Ordner .well-known/matrix/ folgende .htaccess anlegen:

Header set Access-Control-Allow-Origin "*"

Die Dokumentation dazu findet man unter https://matrix.org/docs/spec/server_server/r0.1.2#get-well-known-matrix-server und https://matrix.org/docs/spec/client_server/r0.5.0#get-well-known-matrix-client

== Update von Synapse ==

source ~/synapse/env/bin/activate
pip install -U matrix-synapse[postgres]
monit restart synapse

== Riot-Web ==

Riot-Web ist aus Server-Seite eine rein statische html+javascript-Kombination, daher:

* Account und Domain anlegen (separat von der Synapse-Domain)
* aktuelles riot-web release .tgz herunterladen
* Symlink von htdocs-ssl auf entpacktes riot-web-Verzeichnis
* config.sample.json in config.json kopieren und Matrix-Homeserver-Einträge anpassen
* Piwik aus config.json entfernen

== SAML mit Synapse ==

Synapse unterstützt mit Version 1.1.0 SAML. Dazu wie folgt vorgehen:

Das Paket xmlsec1 muss installiert sein:

$ xmlsec1 --version
xmlsec1 1.2.23 (openssl)

Das Python-Paket pysaml2 installieren

source synapse/env/bin/activate
pip install pysaml2

In der homeserver.yaml die SAML-Direktiven einkommentieren, hier mit dem Beispiel eines SAML IdP unter https://login.beispiel.de/simplesaml/saml2/idp/metadata.php:

# Once SAML support is enabled, a metadata file will be exposed at
# https://<server>:<port>/_matrix/saml2/metadata.xml, which you may be able to
# use to configure your SAML IdP with. Alternatively, you can manually configure
# the IdP to use an ACS location of
# https://<server>:<port>/_matrix/saml2/authn_response.
#
saml2_config:
sp_config:
# point this to the IdP's metadata. You can use either a local file or
# (preferably) a URL.
metadata:
#local: ["saml2/idp.xml"]
remote:
- url: https://login.beispiel.de/simplesaml/saml2/idp/metadata.php

Wichtig ist außerdem, dass die public_baseurl in der homeserver.yaml gesetzt ist, damit Synapse weiß, wie es erreichbar ist und dies in seine SP-Metadaten einbauen kann:

public_baseurl: https://matrix.beispiel.de/

Die Service-Provider-Konfiguration als XML bekommt man von Synapse dann wie schon in der homeserver.yaml als Kommentar beschrieben, unter https://matrix.beispiel.de/_matrix/saml2/metadata.xml

Diese dann in den SAML-IdP-importieren und dann sollte der Single-Sign-On via SAML funktionieren.

== Federation Sender Worker für Synapse ==

Zur Parallelisierung bietet Synapse das Konzept "Worker" an, die spezifische Aufgaben übernehmen, damit der Hauptprozess diese nicht durchführen muss.

Details dazu: https://github.com/matrix-org/synapse/blob/master/docs/workers.md

Ein einfach einzurichtender Worker, der auch viel Last abfedert, ist der Federation Sender Worker, da das Verschicken des Federation-Traffics 10-50% der Serverlast ausmacht.

In der homeserver.yaml die Worker-Konfiguration aktivieren:

## Worker ##
worker_app: synapse.app.homeserver
daemonize: true

und dazugehörige Listener (Abschnitt listener:) aktivieren:

# The TCP replication port
- port: 32892
bind_address: '127.0.0.1'
type: replication
# The HTTP replication port
- port: 32893
bind_address: '127.0.0.1'
type: http
resources:
- names: [replication]

Funktionen, die Worker machen sollen, in der homeserver.yaml deaktivieren:

# disable federation sending here, use worker for it
send_federation: False

Dann Verzeichnis synapse/workers anlegen, darin federation_sender.yaml:

worker_app: synapse.app.federation_sender

# The replication listener on the synapse to talk to.
worker_replication_host: 127.0.0.1
worker_replication_port: 32892
worker_replication_http_port: 32893

worker_daemonize: True
worker_pid_file: /home/pacs/xyz00/users/matrix/synapse/federation_sender.pid
worker_log_config: /home/pacs/xyz00/users/matrix/synapse/federation_sender.log.config

.monitrc um worker erweitern:

check process federation_sender with pidfile /home/pacs/xyz00/users/matrix/synapse/federation_sender.pid
start program "/bin/bash -c 'export VIRTUAL_ENV=$HOME/synapse/env && export PATH=$VIRTUAL_ENV/bin:$PATH && cd $HOME/synapse && synctl -w workers/federation_sender.yaml start'"
stop program "/bin/bash -c '/bin/kill $( cat $HOME/synapse/federation_sender.pid )'"

Monit neu laden und synapse und federation_sender neustarten:

monit reload
monit restart all

Nach Updates ebenfalls immer Hauptprozess und alle Worker neustarten

monit restart all

== Links ==

* https://matrix.org/docs/projects/server/synapse
* https://github.com/matrix-org/synapse
* https://github.com/matrix-org/synapse/blob/master/INSTALL.md
* https://matrix.org/docs/spec/

[[Kategorie:Installationsanleitungen]]

Matrix Synapse installieren

2020-04-18T12:25:56Z

Peh00: Zeilenumbruch entfernt

Der Matrix Server ''Synapse'', der sogenannte 'Homeserver', ist aktuell die einzige vollständige serverseitige Implementierung des Matrix-Protokolls.

{{Textkasten|gelb|Work in Progress|Leider funktioniert die Server-zu-Server-Kommunikation von Synapse hinter dem Apache-Proxy mit den genannten Rewrite-Rules nicht. Bitten Sie dazu den Service, Ihren Apache VHost individuell für den Martrix Server anzupassen.
Weiterhin wird für die aktuelle Version von Synapse Python 3.8 benötigt. Es ist kein Problem sich ein Python 3.8 aus den Sourcen zu kompilieren. Das ist hier nicht noch nicht beschrieben.}}

Synapse wird bei Hostsharing als ''eigener Daemon'' betrieben. Der Betrieb ist im Shared Hosting anmelde- und kostenpflichtig. Daher emfpehlen wir für den Betrieb einen ''Managed Server''.

Diese Anleitung beschreibt, wie man den Matrix-Homeserver Synapse auf der Managed Hosting Plattform von Hostsharing installieren kann. Dabei sind die User-IDs nach dem Schema @user:beispiel.de aufgebaut, der Homeserver an sich ist unter matrix.beispiel.de erreichbar.

== Vorbereitungen ==

Mit Hilfe von HSAdmin werden angelegt:
# Ein User als Service-User mit ''/bin/bash'' als Shell, zum Beispiel Beispiel: ''xyz00-matrix''
# Eine Domain mit ''xyz00-matrix'' als Domain-Administrator, zum Beispiel ''matrix.beispiel.de''
# Einen Postgresql-User ''xyz00_matrixuser'' mit Passwort ''meinPasswort''
# Eine Postgresql-Datenbank ''xyz00_matrixdb'' mit Datenbank-Owner ''xyz00_matrixuser''

Verwendete IP-Ports der Server-Dienste:
# Monit: xyz00.hostsharing.net:32800
# Synapse: localhost:32801

== Installation von Synapse ==

Installationsanleitung basierend auf https://github.com/matrix-org/synapse/blob/master/INSTALL.md#installing-from-source

Als User ''xyz00-matrix" ein Python3 virtualenv erstellen

mkdir -p ~/synapse
virtualenv -p python3 ~/synapse/env
source ~/synapse/env/bin/activate
pip install --upgrade pip
pip install --upgrade setuptools

Synapse und Postgres-Dependencies installieren

pip install matrix-synapse[postgres]

Initiale Konfiguration mit richtigem server-name "beispiel.de" generieren, außerdem im laufenden Betrieb keine Statistiken an Matrix.org senden

cd ~/synapse
python -m synapse.app.homeserver --server-name beispiel.de --config-path homeserver.yaml --generate-config --report-stats=no

== Konfiguration von Synapse ==

In die initial generierte Konfiguration muss noch die Port- und Datenbank-Konfiguration eingetragen werden:

Port: Innerhalb der listener-section den Port 8008 auf 32801 (wie initial definiert) ändern, alles andere beibehalten:

- port: 32801
tls: false
bind_addresses: ['::1', '127.0.0.1']
type: http
x_forwarded: true

Postgres-Datenbank:

database:
# The database engine name
name: "psycopg2"
# Arguments to pass to the engine
args:
host: "localhost"
database: "xyz00_matrixdb"
user: "xyz00_matrixuser"
password: "meinPasswort"
cp_min: 5
cp_max: 10

== Starten der Dienste ==

Zum Start aller notwendigen Dienste wird in dieser Anleitung ''monit'' benutzt. Hier ein Beispiel für eine Datei ''.monitrc'' (überlange Zeilen werden hier im Wiki umgebrochen)

Das monitpassword auf jeden Fall durch ein sicheres Passwort ersetzen:

set daemon 60
with start delay 120
set logfile /home/pacs/xyz00/users/matrix/monit/var/monit.log
set idfile /home/pacs/xyz00/users/matrix/monit/var/monit.id
set statefile /home/pacs/xyz00/users/matrix/monit/var/monit.state
set mailserver localhost
set mail-format { from: monit@matrix.beispiel.de }
set alert matrix@matrix.beispiel.de
set httpd port 32800 address xyz00.hostsharing.net
allow matrix:monitpassword
check process synapse with pidfile /home/pacs/xyz00/users/matrix/synapse/homeserver.pid
start program "/bin/bash -c 'export VIRTUAL_ENV=$HOME/synapse/env && export PATH=$VIRTUAL_ENV/bin:$PATH && cd $HOME/synapse && synctl start'"
stop program "/bin/bash -c '/bin/kill $( cat $HOME/synapse/homeserver.pid )'"

== Cronjobs ==

''Cron'' wird für eine Aufgabe genutzt:
* Start von monit nach einem Server Reboot

Einrichten der crontab mit ''cronttab -e''

HOME=/home/pacs/xyz00/users/matrix
MAILTO=matrix@matrix.beispiel.de

@reboot /usr/bin/monit -c $HOME/.monitrc

== Einrichten des Apache VHost ==

Die ''~/doms/matrix.beispiel.de/.htaccess'' mit dem Editor der Wahl öffnen und
folgende Konfiguration einfügen:

DirectoryIndex disabled
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule .* http://localhost:32801%{REQUEST_URI} [NE,proxy]
RequestHeader set X-Forwarded-Proto "https"

== Well-Known unter beispiel.de ==

Damit die User-Accounts das Format @user:beispiel.de haben, der Server aber unter matrix.beispiel.de erreichbar ist, müssen noch folgende zwei Dateien unter der Domain beispiel.de abgelegt werden:

https://beispiel.de/.well-known/matrix/server
{
"m.server": "matrix.beispiel.de:443"
}

https://beispiel.de/.well-known/matrix/client
{
"m.homeserver": {
"base_url": "https://matrix.beispiel.de"
},
"m.identity_server": {
"base_url": "https://vector.im"
}
}

Für die muss noch der CORS-Header Access-Control-Allow-Origin "*" gesetzt werden, damit die Datei aus beliebigem Riot-Web im Browser abrufbar ist. Dazu in den Ordner .well-known/matrix/ folgende .htaccess anlegen:

Header set Access-Control-Allow-Origin "*"

Die Dokumentation dazu findet man unter https://matrix.org/docs/spec/server_server/r0.1.2#get-well-known-matrix-server und https://matrix.org/docs/spec/client_server/r0.5.0#get-well-known-matrix-client

== Update von Synapse ==

source ~/synapse/env/bin/activate
pip install -U matrix-synapse[postgres]
monit restart synapse

== Riot-Web ==

Riot-Web ist aus Server-Seite eine rein statische html+javascript-Kombination, daher:

* Account und Domain anlegen (separat von der Synapse-Domain)
* aktuelles riot-web release .tgz herunterladen
* Symlink von htdocs-ssl auf entpacktes riot-web-Verzeichnis
* config.sample.json in config.json kopieren und Matrix-Homeserver-Einträge anpassen
* Piwik aus config.json entfernen

== SAML mit Synapse ==

Synapse unterstützt mit Version 1.1.0 SAML. Dazu wie folgt vorgehen:

Das Paket xmlsec1 muss installiert sein:

$ xmlsec1 --version
xmlsec1 1.2.23 (openssl)

Das Python-Paket pysaml2 installieren

source synapse/env/bin/activate
pip install pysaml2

In der homeserver.yaml die SAML-Direktiven einkommentieren, hier mit dem Beispiel eines SAML IdP unter https://login.beispiel.de/simplesaml/saml2/idp/metadata.php:

# Once SAML support is enabled, a metadata file will be exposed at
# https://<server>:<port>/_matrix/saml2/metadata.xml, which you may be able to
# use to configure your SAML IdP with. Alternatively, you can manually configure
# the IdP to use an ACS location of
# https://<server>:<port>/_matrix/saml2/authn_response.
#
saml2_config:
sp_config:
# point this to the IdP's metadata. You can use either a local file or
# (preferably) a URL.
metadata:
#local: ["saml2/idp.xml"]
remote:
- url: https://login.beispiel.de/simplesaml/saml2/idp/metadata.php

Wichtig ist außerdem, dass die public_baseurl in der homeserver.yaml gesetzt ist, damit Synapse weiß, wie es erreichbar ist und dies in seine SP-Metadaten einbauen kann:

public_baseurl: https://matrix.beispiel.de/

Die Service-Provider-Konfiguration als XML bekommt man von Synapse dann wie schon in der homeserver.yaml als Kommentar beschrieben, unter https://matrix.beispiel.de/_matrix/saml2/metadata.xml

Diese dann in den SAML-IdP-importieren und dann sollte der Single-Sign-On via SAML funktionieren.

== Federation Sender Worker für Synapse ==

Zur Parallelisierung bietet Synapse das Konzept "Worker" an, die spezifische Aufgaben übernehmen, damit der Hauptprozess diese nicht durchführen muss.

Details dazu: https://github.com/matrix-org/synapse/blob/master/docs/workers.md

Ein einfach einzurichtender Worker, der auch viel Last abfedert, ist der Federation Sender Worker, da das Verschicken des Federation-Traffics 10-50% der Serverlast ausmacht.

In der homeserver.yaml die Worker-Konfiguration aktivieren:

## Worker ##
worker_app: synapse.app.homeserver
daemonize: true

und dazugehörige Listener (Abschnitt listener:) aktivieren:

# The TCP replication port
- port: 32892
bind_address: '127.0.0.1'
type: replication
# The HTTP replication port
- port: 32893
bind_address: '127.0.0.1'
type: http
resources:
- names: [replication]

Funktionen, die Worker machen sollen, in der homeserver.yaml deaktivieren:

# disable federation sending here, use worker for it
send_federation: False

Dann Verzeichnis synapse/workers anlegen, darin federation_sender.yaml:

worker_app: synapse.app.federation_sender

# The replication listener on the synapse to talk to.
worker_replication_host: 127.0.0.1
worker_replication_port: 32892
worker_replication_http_port: 32893

worker_daemonize: True
worker_pid_file: /home/pacs/xyz00/users/matrix/synapse/federation_sender.pid
worker_log_config: /home/pacs/xyz00/users/matrix/synapse/federation_sender.log.config

.monitrc um worker erweitern:

check process federation_sender with pidfile /home/pacs/xyz00/users/matrix/synapse/federation_sender.pid
start program "/bin/bash -c 'export VIRTUAL_ENV=$HOME/synapse/env && export PATH=$VIRTUAL_ENV/bin:$PATH && cd $HOME/synapse && synctl -w workers/federation_sender.yaml start'"
stop program "/bin/bash -c '/bin/kill $( cat $HOME/synapse/federation_sender.pid )'"

Monit neu laden und synapse und federation_sender neustarten:

monit reload
monit restart all

Nach Updates ebenfalls immer Hauptprozess und alle Worker neustarten

monit restart all

== Links ==

* https://matrix.org/docs/projects/server/synapse
* https://github.com/matrix-org/synapse
* https://github.com/matrix-org/synapse/blob/master/INSTALL.md
* https://matrix.org/docs/spec/

[[Kategorie:Installationsanleitungen]]

Matrix Synapse installieren

2020-04-18T12:25:27Z

Peh00: Python 3.8

Der Matrix Server ''Synapse'', der sogenannte 'Homeserver', ist aktuell die einzige vollständige serverseitige Implementierung des Matrix-Protokolls.

{{Textkasten|gelb|Work in Progress|Leider funktioniert die Server-zu-Server-Kommunikation von Synapse hinter dem Apache-Proxy mit den genannten Rewrite-Rules nicht. Bitten Sie dazu den Service,
Ihren Apache VHost individuell für den Martrix Server anzupassen.
Weiterhin wird für die aktuelle Version von Synapse Python 3.8 benötigt. Es ist kein Problem sich ein Python 3.8 aus den Sourcen zu kompilieren. Das ist hier nicht noch nicht beschrieben.}}

Synapse wird bei Hostsharing als ''eigener Daemon'' betrieben. Der Betrieb ist im Shared Hosting anmelde- und kostenpflichtig. Daher emfpehlen wir für den Betrieb einen ''Managed Server''.

Diese Anleitung beschreibt, wie man den Matrix-Homeserver Synapse auf der Managed Hosting Plattform von Hostsharing installieren kann. Dabei sind die User-IDs nach dem Schema @user:beispiel.de aufgebaut, der Homeserver an sich ist unter matrix.beispiel.de erreichbar.

== Vorbereitungen ==

Mit Hilfe von HSAdmin werden angelegt:
# Ein User als Service-User mit ''/bin/bash'' als Shell, zum Beispiel Beispiel: ''xyz00-matrix''
# Eine Domain mit ''xyz00-matrix'' als Domain-Administrator, zum Beispiel ''matrix.beispiel.de''
# Einen Postgresql-User ''xyz00_matrixuser'' mit Passwort ''meinPasswort''
# Eine Postgresql-Datenbank ''xyz00_matrixdb'' mit Datenbank-Owner ''xyz00_matrixuser''

Verwendete IP-Ports der Server-Dienste:
# Monit: xyz00.hostsharing.net:32800
# Synapse: localhost:32801

== Installation von Synapse ==

Installationsanleitung basierend auf https://github.com/matrix-org/synapse/blob/master/INSTALL.md#installing-from-source

Als User ''xyz00-matrix" ein Python3 virtualenv erstellen

mkdir -p ~/synapse
virtualenv -p python3 ~/synapse/env
source ~/synapse/env/bin/activate
pip install --upgrade pip
pip install --upgrade setuptools

Synapse und Postgres-Dependencies installieren

pip install matrix-synapse[postgres]

Initiale Konfiguration mit richtigem server-name "beispiel.de" generieren, außerdem im laufenden Betrieb keine Statistiken an Matrix.org senden

cd ~/synapse
python -m synapse.app.homeserver --server-name beispiel.de --config-path homeserver.yaml --generate-config --report-stats=no

== Konfiguration von Synapse ==

In die initial generierte Konfiguration muss noch die Port- und Datenbank-Konfiguration eingetragen werden:

Port: Innerhalb der listener-section den Port 8008 auf 32801 (wie initial definiert) ändern, alles andere beibehalten:

- port: 32801
tls: false
bind_addresses: ['::1', '127.0.0.1']
type: http
x_forwarded: true

Postgres-Datenbank:

database:
# The database engine name
name: "psycopg2"
# Arguments to pass to the engine
args:
host: "localhost"
database: "xyz00_matrixdb"
user: "xyz00_matrixuser"
password: "meinPasswort"
cp_min: 5
cp_max: 10

== Starten der Dienste ==

Zum Start aller notwendigen Dienste wird in dieser Anleitung ''monit'' benutzt. Hier ein Beispiel für eine Datei ''.monitrc'' (überlange Zeilen werden hier im Wiki umgebrochen)

Das monitpassword auf jeden Fall durch ein sicheres Passwort ersetzen:

set daemon 60
with start delay 120
set logfile /home/pacs/xyz00/users/matrix/monit/var/monit.log
set idfile /home/pacs/xyz00/users/matrix/monit/var/monit.id
set statefile /home/pacs/xyz00/users/matrix/monit/var/monit.state
set mailserver localhost
set mail-format { from: monit@matrix.beispiel.de }
set alert matrix@matrix.beispiel.de
set httpd port 32800 address xyz00.hostsharing.net
allow matrix:monitpassword
check process synapse with pidfile /home/pacs/xyz00/users/matrix/synapse/homeserver.pid
start program "/bin/bash -c 'export VIRTUAL_ENV=$HOME/synapse/env && export PATH=$VIRTUAL_ENV/bin:$PATH && cd $HOME/synapse && synctl start'"
stop program "/bin/bash -c '/bin/kill $( cat $HOME/synapse/homeserver.pid )'"

== Cronjobs ==

''Cron'' wird für eine Aufgabe genutzt:
* Start von monit nach einem Server Reboot

Einrichten der crontab mit ''cronttab -e''

HOME=/home/pacs/xyz00/users/matrix
MAILTO=matrix@matrix.beispiel.de

@reboot /usr/bin/monit -c $HOME/.monitrc

== Einrichten des Apache VHost ==

Die ''~/doms/matrix.beispiel.de/.htaccess'' mit dem Editor der Wahl öffnen und
folgende Konfiguration einfügen:

DirectoryIndex disabled
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule .* http://localhost:32801%{REQUEST_URI} [NE,proxy]
RequestHeader set X-Forwarded-Proto "https"

== Well-Known unter beispiel.de ==

Damit die User-Accounts das Format @user:beispiel.de haben, der Server aber unter matrix.beispiel.de erreichbar ist, müssen noch folgende zwei Dateien unter der Domain beispiel.de abgelegt werden:

https://beispiel.de/.well-known/matrix/server
{
"m.server": "matrix.beispiel.de:443"
}

https://beispiel.de/.well-known/matrix/client
{
"m.homeserver": {
"base_url": "https://matrix.beispiel.de"
},
"m.identity_server": {
"base_url": "https://vector.im"
}
}

Für die muss noch der CORS-Header Access-Control-Allow-Origin "*" gesetzt werden, damit die Datei aus beliebigem Riot-Web im Browser abrufbar ist. Dazu in den Ordner .well-known/matrix/ folgende .htaccess anlegen:

Header set Access-Control-Allow-Origin "*"

Die Dokumentation dazu findet man unter https://matrix.org/docs/spec/server_server/r0.1.2#get-well-known-matrix-server und https://matrix.org/docs/spec/client_server/r0.5.0#get-well-known-matrix-client

== Update von Synapse ==

source ~/synapse/env/bin/activate
pip install -U matrix-synapse[postgres]
monit restart synapse

== Riot-Web ==

Riot-Web ist aus Server-Seite eine rein statische html+javascript-Kombination, daher:

* Account und Domain anlegen (separat von der Synapse-Domain)
* aktuelles riot-web release .tgz herunterladen
* Symlink von htdocs-ssl auf entpacktes riot-web-Verzeichnis
* config.sample.json in config.json kopieren und Matrix-Homeserver-Einträge anpassen
* Piwik aus config.json entfernen

== SAML mit Synapse ==

Synapse unterstützt mit Version 1.1.0 SAML. Dazu wie folgt vorgehen:

Das Paket xmlsec1 muss installiert sein:

$ xmlsec1 --version
xmlsec1 1.2.23 (openssl)

Das Python-Paket pysaml2 installieren

source synapse/env/bin/activate
pip install pysaml2

In der homeserver.yaml die SAML-Direktiven einkommentieren, hier mit dem Beispiel eines SAML IdP unter https://login.beispiel.de/simplesaml/saml2/idp/metadata.php:

# Once SAML support is enabled, a metadata file will be exposed at
# https://<server>:<port>/_matrix/saml2/metadata.xml, which you may be able to
# use to configure your SAML IdP with. Alternatively, you can manually configure
# the IdP to use an ACS location of
# https://<server>:<port>/_matrix/saml2/authn_response.
#
saml2_config:
sp_config:
# point this to the IdP's metadata. You can use either a local file or
# (preferably) a URL.
metadata:
#local: ["saml2/idp.xml"]
remote:
- url: https://login.beispiel.de/simplesaml/saml2/idp/metadata.php

Wichtig ist außerdem, dass die public_baseurl in der homeserver.yaml gesetzt ist, damit Synapse weiß, wie es erreichbar ist und dies in seine SP-Metadaten einbauen kann:

public_baseurl: https://matrix.beispiel.de/

Die Service-Provider-Konfiguration als XML bekommt man von Synapse dann wie schon in der homeserver.yaml als Kommentar beschrieben, unter https://matrix.beispiel.de/_matrix/saml2/metadata.xml

Diese dann in den SAML-IdP-importieren und dann sollte der Single-Sign-On via SAML funktionieren.

== Federation Sender Worker für Synapse ==

Zur Parallelisierung bietet Synapse das Konzept "Worker" an, die spezifische Aufgaben übernehmen, damit der Hauptprozess diese nicht durchführen muss.

Details dazu: https://github.com/matrix-org/synapse/blob/master/docs/workers.md

Ein einfach einzurichtender Worker, der auch viel Last abfedert, ist der Federation Sender Worker, da das Verschicken des Federation-Traffics 10-50% der Serverlast ausmacht.

In der homeserver.yaml die Worker-Konfiguration aktivieren:

## Worker ##
worker_app: synapse.app.homeserver
daemonize: true

und dazugehörige Listener (Abschnitt listener:) aktivieren:

# The TCP replication port
- port: 32892
bind_address: '127.0.0.1'
type: replication
# The HTTP replication port
- port: 32893
bind_address: '127.0.0.1'
type: http
resources:
- names: [replication]

Funktionen, die Worker machen sollen, in der homeserver.yaml deaktivieren:

# disable federation sending here, use worker for it
send_federation: False

Dann Verzeichnis synapse/workers anlegen, darin federation_sender.yaml:

worker_app: synapse.app.federation_sender

# The replication listener on the synapse to talk to.
worker_replication_host: 127.0.0.1
worker_replication_port: 32892
worker_replication_http_port: 32893

worker_daemonize: True
worker_pid_file: /home/pacs/xyz00/users/matrix/synapse/federation_sender.pid
worker_log_config: /home/pacs/xyz00/users/matrix/synapse/federation_sender.log.config

.monitrc um worker erweitern:

check process federation_sender with pidfile /home/pacs/xyz00/users/matrix/synapse/federation_sender.pid
start program "/bin/bash -c 'export VIRTUAL_ENV=$HOME/synapse/env && export PATH=$VIRTUAL_ENV/bin:$PATH && cd $HOME/synapse && synctl -w workers/federation_sender.yaml start'"
stop program "/bin/bash -c '/bin/kill $( cat $HOME/synapse/federation_sender.pid )'"

Monit neu laden und synapse und federation_sender neustarten:

monit reload
monit restart all

Nach Updates ebenfalls immer Hauptprozess und alle Worker neustarten

monit restart all

== Links ==

* https://matrix.org/docs/projects/server/synapse
* https://github.com/matrix-org/synapse
* https://github.com/matrix-org/synapse/blob/master/INSTALL.md
* https://matrix.org/docs/spec/

[[Kategorie:Installationsanleitungen]]

HsadminWeb

2017-11-30T10:43:13Z

Peh00: Link altes Web-Frontend gelöscht

= HSAdmin =

Mit dieser Anwendung werden Hosting-Pakete und Domains bei der Hostsharing eG verwaltet.

Die Anwendung ist zu finden unter: https://admin.hostsharing.net/

Die Bedienung hat sich dahingehend verändert, dass es im linken Bereich
des Fensters Einstiegsobjekte gibt:

== Kunde/Mitglied ==

Mitglieder der Genossenschaft sehen hier Ihre Adress-Daten, Ihre
Bankverbindung und die gebuchten Pakete.

== Web-Paket ==

Die Hosting Pakete zur Administration von Benutzern (als
Postfächer oder Domain-Administratoren),
Administration von Domains und Datenbanken (MySQL, PostgreSQL)

== Domain ==

Die Domains zur Verwaltung von E-Mail Adressen

Benutzer ohne Rolle "Domain-Administrator" können lediglich über den
Link unter Ihrem User-Namen oben rechts ihr Passwort ändern.

Domains

2011-04-23T14:10:41Z

Peh00: Datenbanken und Postfächer werden keine gelöscht.

{{HSDoku-Links}}

Die Domainverwaltung bei Hostsharing ist in zwei unabhängige Bereiche aufgeteilt:
* Das "Domain-Bestellsystem" zur Vergabe von Aufträgen an Registrierungstellen, die über HS abgerechnet werden.
* Die Domaineinrichtung in den HS-Paketen, zur Aufschaltung von Domains auf HS Name-, Mail- und Webserver.

Bei anderen Hostern ist eine Domainbestellung teilweise eine feste Kopplung der Registrierung einer Domain mit Konnektierung und Aufschaltung auf bestimmte Nameserver und Webpakete. HS ist hier wesentlich flexibler. Der über HS angebotene Zugang zur Registrierungsverwaltung "Domain-Bestellsystem" (Domain-Robot Webfrontend) erlaubt es registrierte Domains auf frei wählbare DNS-Server zu konnektieren. Auf den HS Nameservern und Paketen lassen sich gleichzeitig beliebige weltweit registrierbare Domains einrichten. Hostsharing unterstützt damit die Einrichtetung und den Betrieb von Domains die von beliebigen (auch sehr exotischen) Registrierungsstellen verwaltet und abgerechnet werden können.

Typische Domainaktionen beinhalten daher ein paar koordinierte Änderungen in der Domainregistrierung und HS-Einrichtung, wie folgend aufgezeigt.

{{Textkasten|gruen||Der verbreitete Ausdruck KK (Konnektivitätskoordination) ist eigentlich veraltet, neu heißt es CHPROV (change provider).}}

= FAQ =

Zu Domains gibt es [[FAQ#Domains|hier]].

= Domainregistrierung oder eingehender Transfer (KK) =

Soll eine neue Domain registriert oder eingehend transferiert werden, sollte die Domain bei Hostsharing eingerichtet werden, bevor die Registrierung letztlich eingeleitet bzw. aktualisiert wird.

'''1. ggf. bereits registrierte Domain zum Transfer freischalten'''

: Dem vorherigen Provider muss die Transfer-Absicht mitgeteilt werden. Dafür gibt es bei den jeweiligen Providern etablierte Verfahren, die dort zu erfragen sind. Bspw. bekommt man dort eine AuthCode für die Domain mitgeteilt. Gibt es dort kein etabliertes Verfahren, so kann man wie folgt verfahren:

:* Formlos per Brief/Fax den Transfer ankündigen und um Zustimmung bitten, z.B.:
:::"Hiermit kündige ich als Owner/Admin-C den Transfer (KK) der Domain example.com zur Hostsharing eG, vertreten durch den Registrar Internetwire, an.
::: Ich bitte, dem folgenden Transferantrag zuzustimmen."
:* Nach Absendung der Transfer-Ankündigung 3-4 Tage warten, um dem alten Provider Zeit zu geben auf den Transferantrag zu reagieren.
:* Wenn dem Transfer nicht stattgegeben wird, den Registrar der Domain herausfinden (z.B. über die Nameserver oder zuständige Registry) und bitten den Transfer zuzulassen.

'''2. Einrichten der Domain auf den HS Servern'''

Auf der [[Shell|Kommandozeile]]:
hsadmin -c domain.add --set:user="<xyz00-admin>" --set:name="<example.com>"

oder mit dem [[WebFrontend | HSadmin Webfrontend ]].

Bei diesem Vorgang werden die Verzeichnisse für die Domain im eigenen Paket angelegt und die Nameserver von HS erhalten die notwendigen Updates. Letzteres ist Voraussetzung für den nächsten Schritt.

{{Textkasten|gruen|Bei Fehler ... | Bei in [[hsadmin]] hängenden Domainaufträgen bitte Mail an mailto://service@hostsharing.net}}

'''3. Neuregistrierung oder Transfer (KK) einleiten'''

:* Im [http://www.domain-bestellsystem.de Domainbestellsystem] mit dem über HS vergebenen Account anmelden. Es handelt sich dabei nicht um den xyz00 Nutzer sondern der Nutzername ist hs-xyz.

:* Neuregistrierung/Transfer(KK) einleiten. (Für den Transfer ist hier i.d.R. der zuvor in Erfahrung gebrachte AuthCode notwendig.)

:* Bei der allerersten Domainregistrierung im Domainbestellsystem müssen die Hostsharing Nameserver noch manuell eingegeben werden. Es sind dies:

dns1.hostsharing.net
dns2.hostsharing.net
dns3.hostsharing.net

'''4. E-Mail-Adressen der neu eingerichteten Domain'''

Ist die Domain bei Hostsharing aufgeschaltet, sind standardmäßig nur die E-Mail-Adressen webmaster@..., postmaster@... und abuse@... eingerichtet. Weitere Adressen können mit [[Hsadmin-mail]] konfiguriert werden.

= Abgehender Transfer (KK) oder Domainkündigung/-löschung =

Ausgehende Domaintransfers sind unabhängig von den Domaineinrichtungen bei HS möglich. Eine Domainregistrierung kann also über eine andere Registrierungsverwaltung abgerechnet werden und weiter bei HS eingerichtet und betrieben werden. Falls bei einem ausgehendem Transfer eine Domain jedoch auch nicht mehr weiter bei Hostsharing gehostet werden soll aber eine möglichst durchgehende Erreichbarkeit sichergestellt werden soll, ist es wichtig, dass die neuen (externen) DNS-Konnektierungen und Webserveraufschaltungen in Betrieb sind und alle alten DNS Caches ausgelaufen sind, bevor die Einrichtung bei HS entfernt wird.

'''1. Domainlöschung beauftragen bzw. den Transfer freischalten'''

:* Im [http://www.domain-bestellsystem.de Domainbestellsystem] mit dem über HS vergebenen Account anmelden.

:* Die gewünschte Aktion einleiten (Löschung/Transit bzw. Domain für den Transfer freigeben/AuthCode erstellen lassen).

'''2. ggf. Domaintransfer (KK) im externen Abrechnungssystem beauftragen (mit oder ohne externe DNS/Webserver Aufschaltung)'''

:* Hierfür ist i.d.R. der zuvor erstellte AuthCode notwendig.

'''3. ggf. Domaineinrichtung auf den HS Servern entfernen'''

:::<pre>hsadmin -c domain.delete "<example.com>"</pre> oder mit dem HSadmin Webfrontend. Dies entfernt die Domainverzeichnisse aus dem Webserverpaket und die Domain aus dem DNS- und Mailservern bei Hostsharing.

= "Handles" in der Registrierungsverwaltung =

Die verschiednenen Registrierungstellen vergeben i.d.R. automatisch Registrierschlüssel -die sog. "Handles"- für jeden neuen Kontaktdatensatz (owner, admin-c, tech-c, zone-c Datensätze). Diese kann man bei weiteren Registrierungen verwenden um sich auf die gleichen Kontaktdaten zu beziehen. Die Internetwire-internen Handles im Domain-Bestellsystem beginnen mit einer Buchstaben/Zahlenkombination und enden mit @HANDLES.DE. Sie dienen dazu auch Kontaktdatensätze, die bei verschiedenen Registrierungsstellen hinterlegt sind unter einem Handle im Internetwire-System zu verwalten.

= Weitere Domaineinrichtungs-Aktionen =

== eigene Verwaltung der Zonefiles ==

Siehe [[Verwalten der Zonendaten]]. 

== lokale Subdomains aufschalten ==

Lokale Subdomains können:

* vom Domainadmin selbst unter ~/doms/example.net/subs/ durch das Anlegen eines Verzeichnisses erzeugt werden
* vom Paketadmin einem anderen Domainadmin aufgeschaltet werden, auch in einem anderen Paket

:: Es ist empfehlenswert vor Änderungen am Zonefile die Seite [[Verwalten_der_Zonendaten]] aufmerksam zu lesen '''und''' zu verstehen!

:::Die Subdomain muss vom Paket-Admin/Domain-Admin durch folgende Ergänzung '''am Ende''' des Zonefile der Domain delegiert werden:

:::<pre>
:::[...]
:::pic IN NS {HS_DNS1_HOSTNAME}.
:::pic IN NS {HS_DNS2_HOSTNAME}.
:::pic IN NS {HS_DNS3_HOSTNAME}.
:::</pre>

:::Prüfen, ob die Änderung des Zonefiles erfolgreich war:

:::<pre>xyz00-abc@h01> dig @dns1.hostsharing.net "pic.example.org" NS | grep '^pic.example.org'</pre>

:::Bei Ausgabe

:::<pre>
:::pic.example.org. 14400 IN NS dns1.hostsharing.net.
:::pic.example.org. 14400 IN NS dns2.hostsharing.net.
:::pic.example.org. 14400 IN NS dns3.hostsharing.net.
:::</pre>

:::kann mit "Einrichten der Domain auf den HS Servern" per hsadmin oder WebFrontend fortgesetzt werden.

== Domains neu zuordnen (Domain-Admin ändern, Paketzuordnung ändern) ==

Domain-Verschiebungen (neu zuordnen) wird auch über die DNS Delegation gemacht und erfolgen grundsätzlich über HSAdmin durch Löschen und Neuanlegen der Domain vom Paketadmin bzw. den
Paketadmins .

'''Achtung:''' Das ~/doms/example.org Verzeichnis, also alle Dateien im Webspace werden bei dieser Aktion komplett gelöscht. Sie müssen vorher manuell (am Besten in einem tar-archiv) gesichert werden!

Verschiebungen über den HS-Service (service@hostsharing.net), etwa zur Verkürzung des
Ausfallzeiten, sind gemäß Hostmaster-Stundensatz kostenpflichtig.

== Status der Domaineinrichtung ==

Der Domaineinrichtungs-Status kann mit unserem hsadmin-[[WebFrontend]] eingesehen werden oder mit [[hsadmin]] auf der Kommandozeile der [[Shell]]:

<pre>
hsadmin -c domain.search
</pre>

== Adresse von Owner / Admin-C ändern ==

Die Änderung der Adressdaten erfolgt, indem die Adressdaten des zugehörigen Handles im [https://www.domain-bestellsystem.de Domain-Bestellsystem] aktualisiert werden. Die Logindaten
sind im Februar 2010 an alle HS-Mitglieder versand worden.

= Weiterführende Links =

[[Verzeichnis-Struktur]] 

----
[[Kategorie:HSDoku]]
[[Kategorie:Domains]]
[[Kategorie:Hsadmin]]
[[Kategorie:Glossar]]