Hostsharing Wiki - Benutzerbeiträge [de]

Spamfilter

2026-04-08T12:30:49Z

Chg93-hsdoku: /* Filtern lernen teilnehmen */

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

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

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

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

= Alternative 1: Maileingangsserver mit Spamfilter nutzen =

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

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

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

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

== Eingangsserver konfigurieren ==

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

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

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

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

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

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

Die folgende Ausgabe wird erwartet:

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

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

== Filtern lernen teilnehmen ==
Wer auch am lernen des Filters mitwirken möchte der sendet den/die Benutzername/n xyz00-name (das ist der eMail Benutzername) an :
service (at) hostsharing (dot) net

= Alternative 2: Persönlichen Spamfilter einrichten =

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

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

== Spamassassin Konfigurieren ==

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

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

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

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

Konfigurationsbeispiel:

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

== Bayesfilter anlernen ==

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

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

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

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

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

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

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

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

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

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

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

= Alternative 3: SecureMX zubuchen =

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

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

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

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

Spamfilter

2026-04-08T12:30:12Z

Chg93-hsdoku: /* Filtern leren teilnehmen */

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

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

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

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

= Alternative 1: Maileingangsserver mit Spamfilter nutzen =

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

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

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

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

== Eingangsserver konfigurieren ==

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

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

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

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

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

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

Die folgende Ausgabe wird erwartet:

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

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

== Filtern lernen teilnehmen ==
Wer auch am lernen des Filters mitwirken möchte der senden den/die Benutzername/n xyz00-name (das ist der eMail Benutzername) an :
service (at) hostsharing (dot) net

= Alternative 2: Persönlichen Spamfilter einrichten =

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

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

== Spamassassin Konfigurieren ==

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

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

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

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

Konfigurationsbeispiel:

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

== Bayesfilter anlernen ==

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

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

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

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

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

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

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

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

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

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

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

= Alternative 3: SecureMX zubuchen =

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

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

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

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

Spamfilter

2026-04-08T12:15:41Z

Chg93-hsdoku: Filtern lernen bei xmailin

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").

== Filtern leren teilnehmen ==
Wer auch am lernen des Filters mitwirken möchte der senden den/die Benuztername/n xyz00-name an service (at) hostsharing (dot) net

= Alternative 2: Persönlichen Spamfilter einrichten =

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

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

== Spamassassin Konfigurieren ==

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

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

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

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

Konfigurationsbeispiel:

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

== Bayesfilter anlernen ==

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

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

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

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

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

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

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

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

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

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

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

= Alternative 3: SecureMX zubuchen =

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

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

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

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

Benutzer:Chg93-hsdoku

2026-01-05T09:01:48Z

Chg93-hsdoku:

[[Bild:Christian-guenter.jpg‎|miniatur|100px|right|Christian Günter]]
Christian Günter seit Feb 2001 bei HS, also ein Mitglied der ersten Stunden.

.

Zonefile

2025-06-02T10:22:08Z

Chg93-hsdoku: /* Fehler beim Übernehmen */

Die technische Dokumentation befindet sich hier: https://www.hostsharing.net/doc/managed-operations-platform/zonefile/

Im Normalfall wird für eine bei Hostsharing liegende Domain (in diesem Beispiel <code lang="en" xml:lang="en">example.com</code> die Konfiguration der {{lang|en|[[Nameserver]]}} automatisch erledigt. Die zugehörige Konfigurationsdatei wird englisch {{lang|en|[[zonefile]]}} oder auf Deutsch Zonendatei genannt.

== Eigene Zonendateien ==
Die Konfiguration kann man anpassen durch das Anlegen oder Ändern eines [[Verwalten_der_Zonendaten|eigenen {{lang|en|zonefile}}]]. Diese Textdatei findet man als <code lang="en" xml:lang="en">/home/doms/example.com/etc/pri.example.com</code> auf dem Server. In dieser Datei kann man diverse Platzhalter verwenden, die erlauben, Dinge automatisch erledigen zu lassen. Da individuelle Zonendateien über ein automatisch ablaufendes Programm nur auf Anforderung ins System übernommen werden, kann man aus dem Vorhandensein oder Fehlen dieser Datei keine Schlüsse ziehen, ob sie bereits übernommen wurde oder womöglich nach dem Übernehmen gelöscht wurde,

== Fehler beim Übernehmen ==
Eine eigene Zonendatei kann fehlerhaft sein und beim Übernehemn kann theoretisch auch etwas schief laufen. Dann wird möglichwerweise eine fehlerhafte Datei <code lang="en" xml:lang="en">/etc/bind/pri.example.com</code> erzeugt (keine Leseberechtigung für Benutzer) und mit einer kleinen Zeitverzögerung den {{lang|en|Nameserver}}n angeboten. Solange das der Fall ist, findet man die entsprechenden Fehlermeldungen in der Textdatei <code lang="en" xml:lang="en">/var/log/named/named.log</code> und nach einer erfolgreichen Übernahme eine Erfolgsmeldung. Keine Meldung nach einer Änderung deutet darauf hin, daß (noch) nichts übernommen wurde.

== Standard-Zonendatei ==
Auch die Standard-{{lang|en|zonefile}} wird über Platzhalter generiert. In ihrer allgemeinen Form, also mit Platzhaltern, findet man sie ''wo?'' auf dem Server.

== Standard-Zonendatei herstellen lassen ==
Wer die Standardkonfiguration für die eigene Domain wieder herstellen möchte, leert das vorhandene {{lang|en|zonefile}} <code lang="en" xml:lang="en">~/doms/example.com/etc/pri.example.com</code> komplett. Es muß danach 0 Byte groß sein. Dann läßt man die Datei ins System übernehmen, wobei sie automatisch gelöscht wird.

== Siehe auch ==
[[Verwalten der Zonendaten]]


[[Kategorie:HSDoku]]
[[Kategorie:Zonefile]]
[[Kategorie:Domains]]
[[Kategorie:DNS]]

Zonefile

2025-06-02T10:20:56Z

Chg93-hsdoku: /etc/bind entfernt da kein lese zugriff mehr

Die technische Dokumentation befindet sich hier: https://www.hostsharing.net/doc/managed-operations-platform/zonefile/

Im Normalfall wird für eine bei Hostsharing liegende Domain (in diesem Beispiel <code lang="en" xml:lang="en">example.com</code> die Konfiguration der {{lang|en|[[Nameserver]]}} automatisch erledigt. Die zugehörige Konfigurationsdatei wird englisch {{lang|en|[[zonefile]]}} oder auf Deutsch Zonendatei genannt.

== Eigene Zonendateien ==
Die Konfiguration kann man anpassen durch das Anlegen oder Ändern eines [[Verwalten_der_Zonendaten|eigenen {{lang|en|zonefile}}]]. Diese Textdatei findet man als <code lang="en" xml:lang="en">/home/doms/example.com/etc/pri.example.com</code> auf dem Server. In dieser Datei kann man diverse Platzhalter verwenden, die erlauben, Dinge automatisch erledigen zu lassen. Da individuelle Zonendateien über ein automatisch ablaufendes Programm nur auf Anforderung ins System übernommen werden, kann man aus dem Vorhandensein oder Fehlen dieser Datei keine Schlüsse ziehen, ob sie bereits übernommen wurde oder womöglich nach dem Übernehmen gelöscht wurde,

== Fehler beim Übernehmen ==
Eine eigene Zonendatei kann fehlerhaft sein und beim Übernehemn kann theoretisch auch etwas schief laufen. Dann wird möglichwerweise eine fehlerhafte Datei <code lang="en" xml:lang="en">/etc/bind/pri.example.com</code> erzeugt und mit einer kleinen Zeitverzögerung den {{lang|en|Nameserver}}n angeboten. Solange das der Fall ist, findet man die entsprechenden Fehlermeldungen der der Textdatei <code lang="en" xml:lang="en">/var/log/named/named.log</code> und nach einer erfolgreichen Übernahme eine Erfolgsmeldung. Keine Meldung nach einer Änderung deutet darauf hin, daß (noch) nichts übernommen wurde.

== Standard-Zonendatei ==
Auch die Standard-{{lang|en|zonefile}} wird über Platzhalter generiert. In ihrer allgemeinen Form, also mit Platzhaltern, findet man sie ''wo?'' auf dem Server.

== Standard-Zonendatei herstellen lassen ==
Wer die Standardkonfiguration für die eigene Domain wieder herstellen möchte, leert das vorhandene {{lang|en|zonefile}} <code lang="en" xml:lang="en">~/doms/example.com/etc/pri.example.com</code> komplett. Es muß danach 0 Byte groß sein. Dann läßt man die Datei ins System übernehmen, wobei sie automatisch gelöscht wird.

== Siehe auch ==
[[Verwalten der Zonendaten]]


[[Kategorie:HSDoku]]
[[Kategorie:Zonefile]]
[[Kategorie:Domains]]
[[Kategorie:DNS]]

Domainregistrierung

2025-04-10T09:28:37Z

Chg93-hsdoku: /* Neuregistrierung oder Transfer zu Hostsharing (KK) */

{{HSDoku-DomainLinks}}
__NOTOC__

=== Erst eine neue Domain über HSAdmin einrichten, dann über das Domain-Bestellsystem registrieren oder von einem anderen Provider transferieren ===

Wird eine neue Domain registriert oder von einem anderen Provider zu Hostsharing transferiert, sollte im Normalfall die Domain bei Hostsharing über HSAdmin eingerichtet werden, bevor die Registrierung letztlich eingeleitet bzw. aktualisiert wird. Sonst kann es zu Problemen beim Konnektieren der Domain kommen.

= Einrichten der Domain auf den HS Servern =

{{Kerndoku|https://www.hostsharing.net/doc/managed-operations-platform/domain/#domainverwaltung}}

Der Domainname muss im Punicode Format angelegt werden aus münster.de wird xn--mnster-3ya.de .

Bei diesem Vorgang werden die Verzeichnisse für die Domain im eigenen Paket angelegt und die Domain wird auf die Mail, Web- und Nameserver von HS [[Aufschaltung|aufgeschaltet]]. Letzteres (das Nameserver-Update) ist Voraussetzung für den nächsten Schritt.

= Domainregistrierung oder eingehender Transfer ([[KK]]) =

== Bei fremdem Provider registrierte Domain zum Transfer freischalten ==

Falls die Domain bisher bei einem anderen Provider gehostet ist, muss diesem die Transfer-Absicht mitgeteilt werden. Dafür gibt es bei den jeweiligen Providern etablierte Verfahren, die dort zu erfragen sind. Üblicherweise bekommt man dort einen AuthCode für die Domain mitgeteilt. Gibt es kein etabliertes Verfahren, so kann man wie folgt verfahren:

* Formlos per Brief/Fax den Transfer ankündigen und um Zustimmung bitten, z.B.:

<syntaxhighlight lang=output line>
Hiermit kündige ich als Owner/Admin-C den Transfer (KK) der
Domain example.com zur Hostsharing eG, vertreten durch den Registrar
RegistryGate GmbH, an. Ich bitte, dem folgenden Transferantrag zuzustimmen.
</syntaxhighlight>

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

== Neuregistrierung oder Transfer zu Hostsharing ([[KK]]) ==

Die Vorgehensweise ist unter https://www.hostsharing.net/doc/managed-operations-platform/domain/#domainverwaltung beschrieben.

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

<syntaxhighlight lang=output line>
dns1.hostsharing.net
dns2.hostsharing.net
dns3.hostsharing.net
</syntaxhighlight>

= 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. Die Einrichtung weiterer E-Mail-Adressen ist unter https://doc.hostsharing.net/einstieg/email.html beschrieben.

[[Kategorie:HSDoku]]
[[Kategorie:Domains]]
[[Kategorie:Hsadmin]]

Gitea

2025-03-11T18:37:10Z

Chg93-hsdoku: /* Gitea installieren */ Daemon -> RAM

== Gitea installieren ==

[https://gitea.io/en-us/ Gitea] ist ein einfacher, selbst gehosteter Git-Service wie GitHub oder GitLab. Die Software ist ein Fork von Gogs und ebenfalls in der Programmiersprache Go geschrieben. Gitea benötigt wenig Ressourcen.
Die hier beschriebene Installation benötigt bei Hostsharing die Paket-Option "RAM". Benötigt werden min. 128 MB. Im Managed Webspace ist diese Option kostenpflichtig: https://www.hostsharing.net/angebote/managed-webspace/ gebucht werden muss der RAM auch bei einem Managed-Server.
Gitea unterstützt verschiedene Datenbanken. Wir gehen in dieser Anleitung davon aus, dass PostgreSQL benutzt wird.

=== Vorbereitung der Installation ===

Um Gitea auf der Managed Operation Platform von Hostsharing zu installieren, ist folgende Vorbereitung erforderlich.

# Anlegen eines Domain-Benutzers. In unserem Beispiel <code>xyz00-gitea</code>.
# Anlegen einer Domain. In unserem Beispiel <code>gitea.hs-example.de</code>.
# Anlegen eines Datenbank-Benutzers. Hier <code>xyz00_giteadbuser</code>.
# Anlegen einer Datenbank. Hier <code>xyz00_giteadb</code>.

Auf der Kommandozeile kann man dies folgendermaßen erledigen.

Man loggt sich als Paketbenutzer ein und startet die Kommandozeilenversion von HSAdmin mit dem Befehl <code>hsscript</code>:

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

Anschließend kann man die Vorbereitungsschritte 1 bis 4 erledigen:

<syntaxhighlight lang=shell>
xyz00@hsadmin> user.add({set:{name:'xyz00-gitea',password:'geheim',shell:'/bin/bash'}})
xyz00@hsadmin> domain.add({set:{name:'gitea.hs-example.de',user:'xyz00-gitea'}})
xyz00@hsadmin> postgresqluser.add({set:{name:'xyz00_giteadbuser',password:'geheim'}})
xyz00@hsadmin> postgresqldb.add({set:{name:'xyz00_giteadb',owner:'xyz00_giteadbuser'}})
</syntaxhighlight>

=== Installation von Gitea ===

Gitea wird als Binary zur Verfügung gestellt.
Wir installieren das Binary im Verzeichnis des Domain-Benutzers.
Wenn wir als Paketbenutzer eingeloggt sind, können wir den Benutzer folgendermaßen wechseln:

<syntaxhighlight lang=shell>
sudo -u xyz00-gitea -i
</syntaxhighlight>

Nun laden wir das passende Binary herunter.
Auf der Website https://dl.gitea.io/gitea/ finden Sie das jeweils aktuelle Binary (hier die 64-Bit-Version,
für die shared Server h01 bis h08 bitte die 32-Bit-Version gitea-1.7.0-linux-i386 herunterladen).

<syntaxhighlight lang=shell>
wget -O gitea https://dl.gitea.io/gitea/1.7.0/gitea-1.7.0-linux-amd64
chmod +x gitea
</syntaxhighlight>

Wir laden die GPG-Signatur herunter und überprüfen sie:

<syntaxhighlight lang=shell>
wget https://dl.gitea.io/gitea/1.7.0/gitea-1.7.0-linux-amd64.asc
gpg --keyserver keys.openpgp.org --recv 7C9E68152594688862D62AF62D9AE806EC1592E2
gpg --verify gitea-1.7.0-linux-amd64.asc gitea
</syntaxhighlight>

Nun können wir Gitea testweise starten:

<syntaxhighlight lang=shell>
./gitea web
</syntaxhighlight>

Der Webserver von Gitea startet auf dem Port 3000. Das werden wir später ändern.

Der Server kann mit Ctrl-C beendet werden.

=== Konfiguration der Domain ===

Zunächst wechseln wir in das Verzeichnis <code>doms/gitea.hs-example.de</code> und löschen den Ordner für die Subdomain 'www':

<syntaxhighlight lang=shell>
rm -rf subs/www
rm -rf subs-ssl/www
</syntaxhighlight>

Anschließend tragen wir die Umleitung auf HTTPS ein, falls dies nicht schon geschehen ist.

<syntaxhighlight lang=shell>
vi htdocs/.htaccess
</syntaxhighlight>

Der Eintrag muss lauten:

<syntaxhighlight lang=apache>
Redirect permanent / https://gitea.hs-example.com/
</syntaxhighlight>

Dann legen wir die Datei <code>htdocs-ssl/.htaccess</code> mit folgendem Inhalt an:

<syntaxhighlight lang=apache>
DirectoryIndex disabled
RewriteEngine on
RewriteBase /
RewriteRule ^(.*) http://localhost:31580/$1 [proxy,last]
</syntaxhighlight>

Merken Sie sich die Portnummer 31580.
Sie wird später bei der Konfiguration von Gitea gebraucht.
Die Portnummer bekommen Sie vom Hostmaster, wenn Sie für Ihren Webspace RAM buchen.
Wenn Sie einen Managed Server haben, können Sie selbst die Portnummer auswählen.

Damit ist die Konfiguration von Apache abgeschlossen.

=== Konfiguration von Gitea ===

Wir editieren nun die Konfigurationsdatei von Gitea <code>app.ini</code>.
Sie befindet sich in dem Verzeichnis <code>~/custom/conf</code>.

'''ACHTUNG''': Sie können die Konfiguration teilweise auch über das Webinterface durchführen. Starten Sie dazu Gitea, wie oben beschrieben, und versuchen Sie einen Benutzer zu registrieren. Daraufhin öffnet sich der Konfigurationsdialog. Sie müssen den Gitea-Benutzer, den Namen der Datenbank, den Datenbank-Benutzer und sein Passwort parat haben.

Die Konfigurationsdatei beginnt mit allgemeinen Einträgen:

<syntaxhighlight lang=shell>
APP_NAME = Gitea: Git with a cup of tea
RUN_USER = xyz00-gitea
RUN_MODE = prod
</syntaxhighlight>

Im Abschnitt [database] folgen die Angaben zur Datenbank:

<syntaxhighlight lang=ini>
[database]
DB_TYPE = postgres
HOST = 127.0.0.1:5432
NAME = xyz00_giteadb
USER = xyz00_giteadbuser
PASSWD = geheim
SSL_MODE = disable
PATH = data/gitea.db
</syntaxhighlight>

Es folgt der Pfad zu den Git-Repositorys und die Server-Konfiguration:

<syntaxhighlight lang=ini>
[repository]
ROOT = /home/pacs/xyz00/users/gitea/gitea-repositories

[server]
PROTOCOL = http
SSH_DOMAIN = gitea.hs-example.de
DOMAIN = gitea.hs-example.de
HTTP_ADDR = localhost
HTTP_PORT = 31580
ROOT_URL = https://gitea.hs-example.de/
DISABLE_SSH = false
SSH_PORT = 22
LFS_START_SERVER = true
</syntaxhighlight>

Für das Schreiben der Log Datei können Sie folgendes konfigurieren:

<syntaxhighlight lang=ini>
[log]
MODE = file
LEVEL = info
ROOT_PATH = /home/pacs/xyz00/users/gitea/custom/logs/
ROUTER = file
LOG_ROTATE = false
</syntaxhighlight>

'''ACHTUNG''': Bitte prüfen Sie, ob der Ordner zum Speichern der Log-Dateien von Gitea vorhanden ist. Bei Bedarf erstellen Sie die Ordnerstruktur entsprechend.

<syntaxhighlight lang=shell>
mkdir -p /home/pacs/xyz00/users/gitea/custom/logs
</syntaxhighlight>

Sie können nun Gitea starten:

<syntaxhighlight lang=shell>
./gitea web
</syntaxhighlight>

Der Git-Service ist dann im Browser unter der Adresse gitea.hs-example.de erreichbar.

=== Service einrichten ===

Zum Schluss müssen Sie noch den Service zum Starten von Gitea einrichten.

Das Service Skript speichern Sie unter dem Pfad <code>~/.config/systemd/user/gitea.service</code> ab.
Es hat folgenden Inhalt:

<syntaxhighlight lang=ini>
Description=Gitea

[Service]
Type=simple
Restart=on-abort
WorkingDirectory=%h
ExecStart=%h/gitea web

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

Nun können Sie noch die Rotation der Logfiles konfigurieren.
Dies geschieht in der Datei <code>~/.logrotate</code>:

<syntaxhighlight lang=ini>
/home/pacs/xyz00/users/gitea/custom/logs/gitea.log {
copytruncate
daily
rotate 7
compress
missingok
}
</syntaxhighlight>

Damit logrotate regelmäßig ausgeführt wird, müssen Sie folgenden systemd Timer für denv Domain-Benutzers einrichten:

<code>~/.config/systemd/user/gitea_logrotate.service</code>
<syntaxhighlight lang=ini>
[Unit]
Description=rotate gittea logs

[Service]
Type=oneshot
ExecStart=/usr/sbin/logrotate -s /home/pacs/xyz00/users/gitea/.logrotate.state /home/pacs/xyz00/users/gitea/.logrotate
</syntaxhighlight>

<code>~/.config/systemd/user/gitea_logrotate.timer</code>
<syntaxhighlight lang=ini>
[Unit]
Description=rotate gittea logs

[Timer]
OnCalendar=1:51
Persistent=True

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

Timer aktivieren und starten:
<syntaxhighlight lang=bash>
$ systemctl --user enable gitea_logrotate.timer
$ systemctl --user start gitea_logrotate.timer
</syntaxhighlight>

Die Uhrzeit für die Logrotation können Sie beliebig einstellen.

Abschließend können Sie Ihre Gitea-Instanz starten:

<syntaxhighlight lang=bash>
export XDG_RUNTIME_DIR=/run/user/$UID
systemctl --user start gitea
</syntaxhighlight>

'''ACHTUNG''': Bitte beachten Sie, dass für die Ausführung von Benutzerskripten mit systemctl für den aktuellen Benutzer im hsadmin die Shell "/bin/bash" konfiguriert sein muss.

=== Anmeldung über LDAP einrichten ===

Ohne weitere Konfiguration, können nun lokale Benutzer angelegt werden.

Falls Sie die Benutzerverwaltung noch an ein LDAP Verzeichnis anschließen wollen, können Sie diese Schritte ausführen:

Sie finden hier die Informationen zum Einrichten eines OpenLDAP Dienstes: [[OpenLDAP]]

Gehen Sie in der Weboberfläche von Git in die Administration, und dort in den Reiter "Authentifizierungsquellen", oder direkt auf dem Link https://git.hs-example.de/-/admin/auths

Dort sollten dann folgende Werte eingetragen werden:
* Authentifizierungstyp: LDAP (via BindDN)
* Host: <code>localhost</code> (bzw. der Name des Servers, auf dem OpenLDAP erreichbar ist)
* Port: <code>30389</code> (bzw. der Port auf dem OpenLDAP erreichbar ist)
* DN binden: <code>cn=admin,dc=hs-example,dc=de</code> (Der Benutzer der Zugriff auf alle Benutzer hat)
* Passwort binden: Das Passwort von dem DN Benutzer
* Basis für Benutzersuche: <code>ou=users,dc=hs-example,dc=de</code>
* Benutzerfilter: <code>(&(objectClass=inetOrgPerson)(uid=%s))</code>
* Admin-Filter: <code>(memberof=cn=admins,ou=groups,dc=hs-example,dc=de)</code> (diese Benutzer haben Admin Rechte in Gitea)
* Benutzernamens-Attribute: <code>DN</code>
* Vornamensattribut: <code>givenName</code>
* Nachnamensattribut: <code>sn</code>
* E-Mail-Attribut: <code>mail</code>

Hier noch ein Screenshot:

[[Datei:Gitea_LDAP_Einrichtung.png|500px]]

=== Default Branches ohne Force Push ===

In den Einstellungen von jedem Repository kann unter "Branches" eine Regel z.B. für den Hauptbranch erstellt werden, damit entweder nur Pull Requests und kein direkter Push erlaubt ist, oder dass Push erlaubt ist, aber kein Verändern der Historie mit force push.

Über diese SQL Befehl können die Einstellungen überprüft werden:

Zeige alle Repositories, die noch keine Regel für den Hauptbranch haben:

<syntaxhighlight lang=sql>
SELECT r.id, owner_name, lower_name, r.default_branch
FROM repository r
WHERE NOT EXISTS (
SELECT 1
FROM protected_branch pb
WHERE pb.repo_id = r.id AND pb.branch_name = r.default_branch
);
</syntaxhighlight>

Zeige die Regeln für die Hauptbranches:

<syntaxhighlight lang=sql>
SELECT r.id, owner_name, lower_name, r.default_branch, pb.can_push, pb.required_approvals
FROM repository r JOIN protected_branch pb ON pb.repo_id = r.id AND pb.branch_name = r.default_branch;
</syntaxhighlight>

== weiterführende Links ==

* [https://gitea.io/ Gitea Webseite]
* [https://docs.gitea.io/ Dokumentation von Gitea]
* [https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/gitea Ansible Playbook für Hostsharing]

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]
[[Kategorie:Software]]
[[Kategorie:Projektmanagement]]
[[Kategorie:Projektverwaltung]]

Hsadmin-mail

2025-01-09T14:40:15Z

Chg93-hsdoku:

{{Textkasten|rot|Hinweis:|Inhalt ist nun in der HS Dokumentation.
https://www.hostsharing.net/doc/managed-operations-platform/tutorials/email-einrichten/
}}

---
[[Kategorie:Glossar]]

Mono bei Hostsharing

2025-01-03T16:08:24Z

Chg93-hsdoku: /* Mono und fastcgi Server im Produktiveinsatz */ systemd

== Allgemein ==

Mono [https://www.mono-project.com/] ist ein Open Source .NET Framework und ermöglicht es, .NET Anwendungen in C# unter Linux auszuführen.

== Mono bei Hostsharing ==

Momentan ist Mono nicht zentral auf den Hostsharing Servern installiert.

Mono wird als Debian Paket bereitgestellt, siehe https://packages.debian.org/de/buster/mono-complete

Das könnten wir bei Bedarf einrichten, allerdings ist die Version von Mono in unserem aktuell verwendeten Debian 10 (Buster) schon ziemlich alt (Mono 5.18).

Das ist ganz normal, bei nodejs/npm sieht es ähnlich aus, weil die Entwicklung solcher Projekte etwas schneller fortschreitet als die Debian Releases, die auf Stabilität bedacht sind.

== Mono lokal im Benutzer installieren ==

Es gibt aber einen Weg, ein binäres Paket im eigenen Benutzerverzeichnis zu installieren,
welches die gewünschte Funktionalität einer ziemlich aktuellen Mono Version (Mono 6.8) bietet.

Das binäre Paket kann hier heruntergeladen werden: https://download.solidcharity.com/tarballs/tpokorra/mono/mono-6.8.0.105.bin.debian10.tar.gz

Es enthält eine env.sh Datei, die ausgeführt werden muss, um die entsprechenden Pfade zu aktivieren.

Beispiel:

<syntaxhighlight lang=shell>
cd ~
wget https://download.solidcharity.com/tarballs/tpokorra/mono/mono-6.8.0.105.bin.debian10.tar.gz

echo "Prüfen der Hash Summe sollte OK zeigen:"
echo "f2c27f11141f81a131b6417084c31ab3ae9d050aab8f13d75b406b377a7a1c670bdfc386f276317115e791af0ad34842 *mono-6.8.0.105.bin.debian10.tar.gz" | sha384sum --check

tar xzf mono-6.8.0.105.bin.debian10.tar.gz
ln -s mono-6.8.0.105 mono
source mono/env.sh
mono --version
Mono JIT compiler version 6.8.0.105 (Debian 6.8.0.105+dfsg-3 Sun Dec 13 21:52:01 CET 2020)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
TLS: __thread
SIGSEGV: altstack
Notifications: epoll
Architecture: amd64
Disabled: none
Misc: softdebug
Interpreter: yes
LLVM: supported, not enabled.
Suspend: hybrid
GC: sgen (concurrent by default)
</syntaxhighlight>

=== Beschreibung zur Erstellung des binären Pakets ===

Natürlich muss man immer hinterfragen, ob man fremden binären Paketen vertraut. Alternativ kann man anhand der folgenden Anleitung das binäre Paket gegebenenfalls selber herstellen:

Zuerst werden aktuelle Mono Pakete für Debian Buster benötigt. Diese können aus den Quellen der Mono Pakete von Debian Bullseye für Debian Buster gebaut werden.
Die entsprechenden Skripte liegen hier: https://github.com/tpokorra/lbs-mono/tree/master/mono und https://github.com/tpokorra/lbs-mono/tree/master/xsp
Beim XSP wurde allerdings eine neuere Version verwendet (4.7.1) als momentan von Debian bereitgestellt wird (4.2, siehe https://packages.debian.org/de/bullseye/mono-xsp).

Es gibt ein Bash Skript [https://github.com/tpokorra/lbs-mono/blob/master/mono2bintarball/setup.sh] und ein Python Skript [https://github.com/tpokorra/lbs-mono/blob/master/mono2bintarball/mono2bintarball.py].
Diese werden auf einem Build Server ausgeführt, und es werden die folgenden Schritte ausgeführt:

* Es werden die Namen der aktuell installierten Pakete auf dem Hostsharing Server heruntergeladen.
* Dann wird eine Liste angefertigt von Paketen, die wir lokal installieren wollen für Mono.
* Dann werden lokal die gewünschten Mono Pakete installiert.
* Dann werden die Pakete, die installiert worden sind, mit den Paketen auf dem Hostsharing Server abgeglichen. Die Inhalte der zusätzlichen Pakete werden in das binäre Paket gepackt.
* Auch einige spezifische Mono Dateien, die teilweise erst mit den Installationsskripten installiert wurden (z.B. aot Cache, config Dateien), werden in das binäre Paket gepackt.
* Die Pfade in den bash Skripten zum Starten von Mono werden angepasst, damit es im Benutzerverzeichnis ausgeführt werden kann.
* Es wird eine env.sh Datei dazu gepackt.

== Mono Anwendung mit xsp debuggen ==

Man kann eine Mono Anwendung direkt mit xsp ausführen, ohne den Umweg über den Apache. Das kann beim Debuggen nützlich sein.

Beispiel:

index.aspx
<syntaxhighlight lang=html>
<%@ Page Language="C#" %>
<html xmlns="www.w3.org/1999/xhtml">
<%@ Import Namespace="System" %>
<head runat="server">
<title></title>
</head>
<body>
<div>
<%
Response.Write( "Hello World<br/>");
Response.Write( String.Format("Current Time is {0}<br/>", DateTime.Now));
%>
</div>
</body>
</syntaxhighlight>

Um Kompilierfehler im Browser zu sehen, diese Datei anlegen:

web.config
<syntaxhighlight lang=html>
<configuration>
<system.web>
<customErrors mode="Off"/>
</system.web>
</configuration>
</syntaxhighlight>

Eigene IP Adresse herausfinden:
<syntaxhighlight lang=shell>
ping -4 xyz00.hostsharing.net
</syntaxhighlight>
Nun kann der Server mit dieser IP Adresse gestartet werden:
<syntaxhighlight lang=shell>
xsp4 --port=8080 --address=aa.bbb.cc.ddd
</syntaxhighlight>
Die Seite ist nun über http://xyz00.hostsharing.net:8080 erreichbar.

== Mono und fastcgi Server im Produktiveinsatz ==

Für den produktiven Einsatz benutzt man den fastcgi Server.

Dazu muss man entsprechend RAM für den Webspace buchen, und beim Service um einen freien Port bitten. Wir benutzen im Beispiel den Port 4001.

bin/start-mono.sh
<syntaxhighlight lang=shell>
#!/bin/bash

cd $HOME/aspnetapp
. $HOME/mono/env.sh
exec fastcgi-mono-server4 \
/socket=tcp:127.0.0.1:4001 \
/applications=/:$HOME/aspnetapp \
--logfile=$HOME/var/log/monoserver.log \
--loglevels=All \
--verbose \
> /dev/null 2>&1 &
echo $! > $HOME/var/run/mono.pid
</syntaxhighlight>

bin/stop-mono.sh
<syntaxhighlight lang=shell>
#!/bin/bash

kill -QUIT $( cat $HOME/var/run/mono.pid )
</syntaxhighlight>

.monitrc
<syntaxhighlight lang=shell>
set daemon 60 with start delay 10
set logfile /home/pacs/xyz00/users/meinuser/var/log/monit.log
set idfile /home/pacs/xyz00/users/meinuser/var/run/monit.id
set statefile /home/pacs/xyz00/users/meinuser/var/run/monit.state
set mailserver localhost
set mail-format { from: monit@xyz00.hostsharing.net }
check process mono with pidfile /home/pacs/xyz00/users/meinuser/var/run/mono.pid
start program "/home/pacs/xyz00/users/meinuser/bin/start-mono.sh"
stop program "/home/pacs/xyz00/users/meinuser/bin/stop-mono.sh"
</syntaxhighlight>

Es sollten die entsprechenden leeren Verzeichnisse erstellt werden, und die Rechte für .monitrc geändert werden:
<syntaxhighlight lang=shell>
mkdir -p $HOME/var/log
mkdir -p $HOME/var/run
chmod 600 .monitrc
</syntaxhighlight>

Und dann noch einen systemd service für Monit anlegen:

''~/.config/systemd/user/monit.service''
<syntaxhighlight lang=ini>
[Unit]
Description=monit

[Service]
Type=forking
ExecStartPre=rm -f %h/.monit.id
ExecStart=/usr/bin/monit -c %h/.monitrc

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

Service aktivieren und starten:

<syntaxhighlight lang=shell>
$ systemctl --user enable monit.service
$ systemctl --user start monit.service
</syntaxhighlight>

Nun muss noch dem Apache mitgeteilt werden, wie er auf den fastcgi Server zugreift:

doms/meine-domain.de/subs-ssl/www/.htaccess
<syntaxhighlight lang=apache>
DirectoryIndex index.aspx
RewriteEngine on
RewriteBase /
RewriteRule ^(.*) fcgi://127.0.0.1:4001/$1 [proxy,last]
</syntaxhighlight>

Dann sollte unter https://www.meinedomain.de/ die Mono Applikation erreichbar sein!

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Mono]]
[[Kategorie:Eigene Daemons]]

Monit installieren

2025-01-03T15:36:47Z

Chg93-hsdoku: /* Monit Starten und Stoppen */

[[Kategorie:Installationsanleitungen]]
[[Kategorie:eigene Daemons]]
[[Kategorie:Managed Server]]
== Über Monit ==
Monit ist ein ressourcensparendes Programm zur Überwachung eines Server oder von [[Daemon|Diensten ("Daemons")]] auf einem Server.

Es fragt regelmäßig den Zustand des zu überwachenden Prozesses ab und kann bei einem Absturz den Prozess selbstständig neu starten. Für Betriebssystem-Ressourcen, wie Festplatten-Kapazität oder CPU- und RAM-Auslastung, können Schwellwerte angegeben werden, bei deren Überschreitung Monit per E-Mail alarmiert und in eine Log-Datei protokolliert.

In dieser Beschreibung wird der Start des Servers und von Monit durch den Paketadmin angenommen. Sollte ein davon verschiedener Domain-Admin der "Befehlshaber" sein, so müssen die Pfade entsprechend korrigiert werden. Von "/home/pacs/xyz00" zu "/home/pacs/xyz00/users/user".

{{Textkasten|rot|Besser systemd benutzen|Achtung: wir empfehlen nicht mehr den Einsatz von monit als Prozessmanager. Alle Anwendungen sollten mit [[Prozessmanagement mit systemd im Userspace|Systemd im Userspace]] gestartet werden. Monit kann weiterhin zur Überwachung des Servers eingesetzt werden.}}

== Konfiguration ==

Monit sucht seine Konfiguration beim Start zuerst in der Datei ~/.monitrc im Homeverzeichnis des Users, der monit startet.

Wir erstellen also diese Datei im Hauptverzeichnis des Users und sorgen dafür, dass sie nur von diesem gelesen und beschrieben werden kann:

<syntaxhighlight lang=shell>
xyz00@hxx:~$ cd
xyz00@hxx:~$ touch .monitrc
xyz00@hxx:~$ chmod 0600 .monitrc
xyz00@hxx:~$ edit .monitrc
</syntaxhighlight>

Und füllen sie mit folgendem Inhalt:

<syntaxhighlight lang=shell>
set daemon 600
set logfile /home/pacs/xyz00/var/monit.log
set mailserver localhost
set alert admin@example.tld

check process apache2 with pidfile /home/pacs/xyz00/etc/apache2/run/apache2.pid
start program "/bin/bash -c '/home/pacs/xyz00/etc/apache2/apache2_start'"
stop program "/bin/bash -c '/home/pacs/xyz00/etc/apache2/apache2_stop'"
if failed host example.tld port 8080 with timeout 60 seconds then restart
</syntaxhighlight>

'''Achtung:''' Dieses Beispiel geht davon aus, dass die entsprechenden Start- und Stopskripte existieren und der Pfad zum pidfile des Apachen stimmt.

== Monit Starten und Stoppen ==

Wird nun per systemd realisiert dazu

noch einen systemd service für Monit anlegen:

''~/.config/systemd/user/monit.service''
<syntaxhighlight lang=ini>
[Unit]
Description=monit

[Service]
Type=exec
ExecStartPre=rm -f %h/.monit.id
ExecStart=/usr/bin/monit -c %h/.monitrc

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

Service aktivieren und starten:

<syntaxhighlight lang=shell>
$ systemctl --user enable monit.service
$ systemctl --user start monit.service
</syntaxhighlight>

== Managed Server monitoren ==

Bei der Nutzung eines Managed Server ist das Hostsharing-Mitglied selbst dafür verantwortlich, die Ressourcen des Servers
ausreichend zu dimensionieren. Monit kann helfen Engpässe zu entdecken.

Mit den folgenden Zeilen in der .monitrc wird bei der Überschreitung von bestimmten Schwellwerten beim Load,
bei der RAM- und CPU-Auslastung und der Festplatten-Auslastung der E-Mail alarmiert und ins monit.log protokolliert:

<syntaxhighlight lang=shell line>
check system h00.hostsharing.net
if loadavg (1min) > 5 then alert
if loadavg (5min) > 3 then alert
if memory usage > 85% then alert
if cpu usage (user) > 70% then alert
if cpu usage (system) > 30% then alert
if cpu usage (wait) > 20% then alert

check device datafs with path /dev/vda2
if failed permission 0660 then alert
if failed uid root then alert
if failed gid "disk" then alert
if space usage > 85 % then alert
if inode usage > 85 % then alert
</syntaxhighlight>

== Logfiles kontrollieren ==

Monit loggt entsprechend der Konfiguration seine "Taten" in ~/var/monit.log

Damit das Logfile nicht zu groß wird, benutzen wir '''logrotate''', das von [[cron]] aufgerufen wird, einmal pro Woche das Logfile komprimiert und zwei alte Versionen hält. Dazu erstellen wir die Konfigdatei .logrotate im Hauptverzeichnis des Users:

<syntaxhighlight lang=shell>
touch .logrotate
</syntaxhighlight>

Darin schreiben wir:

<syntaxhighlight lang=shell line>
compress

/home/pacs/xyz00/var/monit.log {
rotate 2
weekly
}
</syntaxhighlight>

Nun brauchen wir noch einen Aufruf von logrotate durch [[cron]]. Bitte beachten, logrotate merkt sich den letzten Zustand der Logdatei in einem Statusfile. Das muss in der [[Cron#Crontab|crontab]] mit angegeben werden. Wir editieren die crontab und schreiben:

<syntaxhighlight lang=shell line>
27 7 * * 5 logrotate -s /home/pacs/xyz00/.logrotate_state /home/pacs/xyz00/.logrotate
</syntaxhighlight>

Damit wird jeden Freitag um 7:27 Uhr das monit.log "rotiert". '''Achtung:''' bitte einen anderen Tag und eine andere Uhrzeit wählen, damit nicht alle logrotates zur gleichen Zeit starten.

== externe Links ==

* [https://www.mmonit.com/monit/ Monit Homepage]
* [https://www.mmonit.com/monit/documentation/monit.html Monit Dokumentation]
* [https://www.mmonit.com/wiki/ Monit Wiki]

Monit installieren

2025-01-03T14:25:24Z

Chg93-hsdoku: /* Monit Starten und Stoppen */ mit systemd

[[Kategorie:Installationsanleitungen]]
[[Kategorie:eigene Daemons]]
[[Kategorie:Managed Server]]
== Über Monit ==
Monit ist ein ressourcensparendes Programm zur Überwachung eines Server oder von [[Daemon|Diensten ("Daemons")]] auf einem Server.

Es fragt regelmäßig den Zustand des zu überwachenden Prozesses ab und kann bei einem Absturz den Prozess selbstständig neu starten. Für Betriebssystem-Ressourcen, wie Festplatten-Kapazität oder CPU- und RAM-Auslastung, können Schwellwerte angegeben werden, bei deren Überschreitung Monit per E-Mail alarmiert und in eine Log-Datei protokolliert.

In dieser Beschreibung wird der Start des Servers und von Monit durch den Paketadmin angenommen. Sollte ein davon verschiedener Domain-Admin der "Befehlshaber" sein, so müssen die Pfade entsprechend korrigiert werden. Von "/home/pacs/xyz00" zu "/home/pacs/xyz00/users/user".

{{Textkasten|rot|Besser systemd benutzen|Achtung: wir empfehlen nicht mehr den Einsatz von monit. Alle Anwendungen sollten mit [[Prozessmanagement mit systemd im Userspace|Systemd im Userspace]] laufen.}}

== Konfiguration ==

Monit sucht seine Konfiguration beim Start zuerst in der Datei ~/.monitrc im Homeverzeichnis des Users, der monit startet.

Wir erstellen also diese Datei im Hauptverzeichnis des Users und sorgen dafür, dass sie nur von diesem gelesen und beschrieben werden kann:

<syntaxhighlight lang=shell>
xyz00@hxx:~$ cd
xyz00@hxx:~$ touch .monitrc
xyz00@hxx:~$ chmod 0600 .monitrc
xyz00@hxx:~$ edit .monitrc
</syntaxhighlight>

Und füllen sie mit folgendem Inhalt:

<syntaxhighlight lang=shell>
set daemon 600
set logfile /home/pacs/xyz00/var/monit.log
set mailserver localhost
set alert admin@example.tld

check process apache2 with pidfile /home/pacs/xyz00/etc/apache2/run/apache2.pid
start program "/bin/bash -c '/home/pacs/xyz00/etc/apache2/apache2_start'"
stop program "/bin/bash -c '/home/pacs/xyz00/etc/apache2/apache2_stop'"
if failed host example.tld port 8080 with timeout 60 seconds then restart
</syntaxhighlight>

'''Achtung:''' Dieses Beispiel geht davon aus, dass die entsprechenden Start- und Stopskripte existieren und der Pfad zum pidfile des Apachen stimmt.

== Monit Starten und Stoppen ==

Wird nun per systemd realisiert dazu

noch einen systemd service für Monit anlegen:

''~/.config/systemd/user/monit.service''
<syntaxhighlight lang=ini>
[Unit]
Description=monit

[Service]
Type=exec
ExecStart=rm -f $HOME/var/run/monit.id && /usr/bin/monit -c "$HOME/.monitrc"
</syntaxhighlight>

Service aktivieren und starten:

<syntaxhighlight lang=shell>
$ systemctl --user enable monit.service
$ systemctl --user start monit.service
</syntaxhighlight>

== Managed Server monitoren ==

Bei der Nutzung eines Managed Server ist das Hostsharing-Mitglied selbst dafür verantwortlich, die Ressourcen des Servers
ausreichend zu dimensionieren. Monit kann helfen Engpässe zu entdecken.

Mit den folgenden Zeilen in der .monitrc wird bei der Überschreitung von bestimmten Schwellwerten beim Load,
bei der RAM- und CPU-Auslastung und der Festplatten-Auslastung der E-Mail alarmiert und ins monit.log protokolliert:

<syntaxhighlight lang=shell line>
check system h00.hostsharing.net
if loadavg (1min) > 5 then alert
if loadavg (5min) > 3 then alert
if memory usage > 85% then alert
if cpu usage (user) > 70% then alert
if cpu usage (system) > 30% then alert
if cpu usage (wait) > 20% then alert

check device datafs with path /dev/vda2
if failed permission 0660 then alert
if failed uid root then alert
if failed gid "disk" then alert
if space usage > 85 % then alert
if inode usage > 85 % then alert
</syntaxhighlight>

== Logfiles kontrollieren ==

Monit loggt entsprechend der Konfiguration seine "Taten" in ~/var/monit.log

Damit das Logfile nicht zu groß wird, benutzen wir '''logrotate''', das von [[cron]] aufgerufen wird, einmal pro Woche das Logfile komprimiert und zwei alte Versionen hält. Dazu erstellen wir die Konfigdatei .logrotate im Hauptverzeichnis des Users:

<syntaxhighlight lang=shell>
touch .logrotate
</syntaxhighlight>

Darin schreiben wir:

<syntaxhighlight lang=shell line>
compress

/home/pacs/xyz00/var/monit.log {
rotate 2
weekly
}
</syntaxhighlight>

Nun brauchen wir noch einen Aufruf von logrotate durch [[cron]]. Bitte beachten, logrotate merkt sich den letzten Zustand der Logdatei in einem Statusfile. Das muss in der [[Cron#Crontab|crontab]] mit angegeben werden. Wir editieren die crontab und schreiben:

<syntaxhighlight lang=shell line>
27 7 * * 5 logrotate -s /home/pacs/xyz00/.logrotate_state /home/pacs/xyz00/.logrotate
</syntaxhighlight>

Damit wird jeden Freitag um 7:27 Uhr das monit.log "rotiert". '''Achtung:''' bitte einen anderen Tag und eine andere Uhrzeit wählen, damit nicht alle logrotates zur gleichen Zeit starten.

== externe Links ==

* [https://www.mmonit.com/monit/ Monit Homepage]
* [https://www.mmonit.com/monit/documentation/monit.html Monit Dokumentation]
* [https://www.mmonit.com/wiki/ Monit Wiki]

Tomcat Installieren

2025-01-02T16:02:35Z

Chg93-hsdoku: /* Spezielle Installation bei Hostsharing */ RAM buchen

Apache Tomcat installieren

== Allgemein ==

[http://tomcat.apache.org/ Apache Tomcat] ist ein Webserver (HTTP-Server), der in der Programmiersprache Java entwickelt ist. Er dient in erster Linie dazu, dynamische Web-Anwendungen zu betreiben, die ebenfalls in Java programmiert sind. Basis-Technologien sind [http://de.wikipedia.org/wiki/Servlet Java-Servlets] und [http://de.wikipedia.org/wiki/JSP Java Server Pages (JSP)].

Mit Hilfe von Apache Tomcat ist bei Hostsharing das Hosting von komplexen Java Web-Applikationen problemlos möglich.

== Spezielle Installation bei Hostsharing ==

In jedem dynamischen Webhosting-Paket der Hostsharing eG können einer (oder mehrere) Tomcat-Webserver betrieben werden.

Die hier beschriebene Installation benötigt bei Hostsharing die Paket-Option "RAM". Benötigt werden min. 512 MB. Im Managed Webspace ist diese Option kostenpflichtig: https://www.hostsharing.net/angebote/managed-webspace/ gebucht werden muss der RAM auch bei einem Managed-Server.

Diese Anleitung dokumentiert die Installation des Apache Tomcat Servers als Service-User in einem WEB-Paket bei Hostsharing. Mit der Einrichtung der Option "eigener Serverdienst" werden für die Paket-IP-Adresse einer oder mehrere IP-Ports reserviert. An diese Ports wird der eigene Serverdienst (also der Tomcat-Server) am Localhost-Interface gebunden.

Bei der Anmeldung (bei service(at)hostsharing.net bitte angeben:

# den Service User, mit dessen Rechten der Tomcat-Dienst laufen soll (also zum Beispiel "xyz00-tomcat")
# wieviele IP-Ports reserviert werden sollen (in der folgenden Anleitung verwenden wir drei nicht-privilegierte Ports:
* 38005 als "Shutdown"-Schnittstelle
* 38006 für eine AJP-Listener

== Installation ==

Vorbemerkung: Mit Debian 12 ('Bookworm') wird Tomcat 10 von der Distribution mitgeliefert.

Auf den Hostsharing-Servern ist das Debian-Paket "tomcat10-user" installiert. Es stellt den
Apache Tomcat Server in der Version 10.1.x für den Betrieb als normaler (nicht privilegierter) User bereit.
Dabei wird die zentral installierte Tomcat-Software benutzt, die über Betriebssystem-Updates mit Sicherheits-Updates versorgt wird.

Für die Installation der Konfigurations-Dateien in Heimat-Verzeichnis des Benutzers wird folgender Befehl
mit den Rechten des Service-Users aufgerufen:

<syntaxhighlight lang="bash">
xyz00-tomcat@h00:~$ tomcat10-instance-create tomcat
</syntaxhighlight>

Ich bevorzuge das catalina.sh-Startskript zum Testen:

<syntaxhighlight lang="bash">
xyz00-tomcat@h00:~$ cp /usr/share/tomcat10/bin/catalina.sh tomcat/bin/
</syntaxhighlight>

Dieser Befehl legt ein Verzeichnis "tomcat" mit der üblichen Dateistruktur für einen Tomcat-Server an:

<syntaxhighlight lang="bash">
bin
bin/catalina.sh
bin/setenv.sh
bin/shutdown.sh
bin/startup.sh
conf
conf/catalina.properties
conf/context.xml
conf/jaspic-providers.xml
conf/logging.properties
conf/server.xml
conf/tomcat-users.xml
conf/web.xml
logs
policy
policy/catalina.policy
temp
webapps
work
</syntaxhighlight>

In der Hauptsache muss die Konfigurationsdatei "server.xml" im Verzeichnis "~/tomcat/conf/" angepasst werden.

Beispiel für eine minimale "server.xml":

<syntaxhighlight lang="xml" line>
<?xml version="1.0" encoding="UTF-8"?>
<Server port="38005" shutdown="SHUTDOWN">
<Listener className="org.apache.catalina.startup.VersionLoggerListener" />
<Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" />
<Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />
<Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />
<Listener className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" />
<GlobalNamingResources>
<Resource name="UserDatabase" auth="Container"
type="org.apache.catalina.UserDatabase"
description="User database that can be updated and saved"
factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
pathname="conf/tomcat-users.xml" />
</GlobalNamingResources>
<Service name="Catalina">
<Connector protocol="AJP/1.3" address="127.0.0.1" port="38006" redirectPort="443" secretRequired="false" />
<Engine name="Catalina" defaultHost="localhost">
<Realm className="org.apache.catalina.realm.LockOutRealm">
<Realm className="org.apache.catalina.realm.UserDatabaseRealm" resourceName="UserDatabase"/>
</Realm>
<Host name="localhost" appBase="../webapps" unpackWARs="true" autoDeploy="true"></Host>
</Engine>
</Service>
</Server>
</syntaxhighlight>

Angepasst werden müssen:
* die beiden IP-Ports (im Beispiel 38005 und 38006 am Localhost-Interface)

== Deployment einer Anwendung ==

In der Beispiel-Konfiguration wurde das Verzeichnis ''$HOME/webapps/'' für die Anwendungen konfiguriert. Wir legen dieses Verzeichnis an und kopieren eine minimale Anwendung hinein:

<syntaxhighlight lang="bash">
mkdir -p $HOME/webapps/hello/WEB-INF/
</syntaxhighlight>

Dort legen wir die Datei ~/webapps/hello/WEB-INF/web.xml mit folgendem Inhalt an:

<syntaxhighlight lang="xml" line>
<?xml version="1.0" encoding="UTF-8"?>
<web-app
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
id="WebApp_ID" version="3.0">
</web-app>
</syntaxhighlight>

Dazu eine einfache JSP-Datei ~/webapps/hello/index.jsp:

<syntaxhighlight lang="html" line>
<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
<!DOCTYPE html>
<html lang="de-de">
<body>
<h1>Hallo Welt</h1>
<p>Java Version: <%= System.getProperty("java.version") %></p>
</body>
</html>
</syntaxhighlight>

Nun können wir die HTTP-Requests, die an eine Domain im Paket gesendet werden, an den Tomcat weiterleiten.
Das funktioniert über eine ''.htaccess''-Datei, zum Beispiel im Verzeichnis ''~/doms/hs-example.de/htdocs-ssl'':

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

Achtung der IP-Port 38006 muss hier wieder angepasst werden!

Dadurch ist die Mini-Anwendung unter der URL "https://hs-example.de/hello/" erreichbar.

== Start des Tomcat Servers ==

Der Tomcat kann über die Skripte in "~/tomcat/bin/" gestartet und gestoppt werden.

<syntaxhighlight lang="bash">
cd ~/tomcat
./bin/startup.sh
</syntaxhighlight>

Log-Ausgaben des Servers sind in "~/tomcat/logs/catalina.out" zu finden.

Damit der Tomcat bei einem Reboot der Hostsharing-Server automatisch gestartet wird,
konfigurieren wir den Prozessmonitor ''systemd'' entsprechend.

Wir legen ein Verzeichnis für die Konfiguration des ''systemd'' an und legen eine Unit-Konfiguration für einen Service dort ab:

<syntaxhighlight lang="bash">
mkdir -p ~/.config/systemd/user
</syntaxhighlight>

Die Unit-Datei ''~/.config/systemd/user/tomcat.service''

<syntaxhighlight lang="ini" line>
[Unit]
Description=Tomcat User Service

[Service]
WorkingDirectory=%h/tomcat
Environment="PATH=/usr/local/bin:/usr/bin:/bin"
Environment="JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64"
Environment="JAVA_OPTS=-Xms256M -Xmx512M"
ExecStart=%h/tomcat/bin/catalina.sh run
StandardOutput=append:%h/tomcat/logs/catalina.log
StandardError=inherit
Restart=always
PrivateTmp=true
NoNewPrivileges=true

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

Auf Wunsch kann ''SystemD'' RAM- und CPU-Ressourcen begrenzen. Dazu wird der Abschnitt ''Service'' ergänzt:

<syntaxhighlight lang="ini" line>
[Service]
...
MemoryAccounting=true
CPUAccounting=true
MemoryHigh=512M
MemoryMax=768M
CPUQuota=50%
</syntaxhighlight>

Die letzte Aufgabe ist das Einrichten der Bereinigung für die Log-Dateien.

Dazu lege ich die Konfigurationsdatei ''.logrotate'' im $HOME-Verzeichnis an:

<syntaxhighlight lang="bash" line>
/home/pacs/xyz00/users/tomcat/tomcat/logs/catalina.log {
copytruncate
compress
rotate 5
daily
missingok
}
</syntaxhighlight>

Für die Bereinigung der Log-Dateien noch zwei systemd-Timer:

~/.config/systemd/user/logrotate.service
<syntaxhighlight lang="bash" line>
[Unit]
Description=rotate tomcat logs

[Service]
Type=oneshot
ExecStart=/usr/sbin/logrotate -s /home/pacs/xyz00/users/tomcat/.logrotate.state /home/pacs/xyz00/users/tomcat/.logrotate
</syntaxhighlight>

~/.config/systemd/user/logrotate.timer
<syntaxhighlight lang="ini" line>
[Unit]
Description=rotate tomcat logs

[Timer]
OnCalendar=1:1
Persistent=True

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

~/.config/systemd/user/delete_old_logs.service
<syntaxhighlight lang="bash" line>
[Unit]
Description=delete old log files

[Service]
Type=oneshot
ExecStart=/usr/bin/find /home/pacs/xyz00/users/tomcat/tomcat/logs -type f -mmin +10080 -delete
</syntaxhighlight>

~/.config/systemd/user/delete_old_logs.timer
<syntaxhighlight lang="ini" line>
[Unit]
Description=delete old log files

[Timer]
OnCalendar=14:3
Persistent=True

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

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

Dann gehen wir daran unsere Anwendungen im Tomcat zu deployen.

== Links ==

*[http://tomcat.apache.org/ Apache Tomcat Homepage (Englisch)]
*[http://tomcat.apache.org/tomcat-9.0-doc/index.html Apache Tomcat Dokumentation (Version 9.0, Englisch)]
*[http://wiki.apache.org/tomcat/FrontPage Apache Tomcat Wiki (Englisch)]
*[https://github.com/tpokorra/Hostsharing-Ansible-Tomcat Ansible Playbook für Hostsharing]

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]
[[Kategorie:Software]]
[[Kategorie:Java]]
[[Kategorie:Eigene Daemons]]

Matrix Synapse installieren

2025-01-02T15:55:48Z

Chg93-hsdoku: Ram buchen

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

{{Textkasten|gelb|Work in Progress|Leider funktioniert die Server-zu-Server-Kommunikation von Synapse hinter dem Apache-Proxy mit den genannten Rewrite-Rules nicht. Bitten Sie dazu den Service, Ihren Apache VHost individuell für den Matrix Server anzupassen.}}

Die hier beschriebene Installation benötigt bei Hostsharing die Paket-Option "RAM". Benötigt werden min. 512 MB. Im Managed Webspace ist diese Option kostenpflichtig: https://www.hostsharing.net/angebote/managed-webspace/ gebucht werden muss der RAM auch bei einem Managed-Server.
Wir empfehlen für den Betrieb einen ''Managed Server''.

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

== Vorbereitungen ==

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

Verwendeter IP-Port für den Server-Dienst:
# Synapse: localhost:32801

== Installation von Synapse ==

Installationsanleitung basierend auf https://matrix-org.github.io/synapse/latest/setup/installation.html#installing-as-a-python-module-from-pypi

Auf Debian Buster muss ein neueres Python, z.B. Python 3.9 installiert werden, siehe [https://wiki.hostsharing.net/index.php?title=Eigenes_Python_installieren#Installation_mit_pyenv Eigenes Python mit pyenv installieren].

Als User ''xyz00-matrix" ein Python3 virtualenv mit Python 3.9 erstellen

<syntaxhighlight lang="shell">
mkdir -p ~/synapse
cd ~/synapse
pipenv install --python 3.9.18
</syntaxhighlight>

Synapse und Postgres-Dependencies installieren

<syntaxhighlight lang="shell">
cd ~/synapse
pipenv shell
pipenv install matrix-synapse[postgres]
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
cd ~/synapse
pipenv run python -m synapse.app.homeserver --server-name beispiel.de --config-path homeserver.yaml --generate-config --report-stats=no
</syntaxhighlight>

== Konfiguration von Synapse ==

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

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

<syntaxhighlight lang=yaml line>
- port: 32801
tls: false
bind_addresses: ['::1', '127.0.0.1']
type: http
x_forwarded: true
</syntaxhighlight>

Postgres-Datenbank:
<syntaxhighlight lang=yaml line>
database:
# The database engine name
name: "psycopg2"
# Arguments to pass to the engine
args:
host: "localhost"
database: "xyz00_matrixdb"
user: "xyz00_matrixuser"
password: "meinPasswort"
cp_min: 5
cp_max: 10
</syntaxhighlight>

== Starten der Dienste ==

Der ''Synapse''-Dienst wird hier als Service-Unit im SystemD des Users eingetragen.

Lege dazu die folgende Datei an: ''~/.config/systemd/user/synapse.service'' mit dem Inhalt:
<syntaxhighlight lang="ini" line>
[Unit]
Description=Synapse

[Service]
Type=simple
WorkingDirectory=%h/synapse
Environment=LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so.2
ExecStart=pipenv run python -m synapse.app.homeserver --config-path=%h/synapse/homeserver.yaml

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

Durch Aufruf der folgenden Kommandos wird der Dienst aktiviert und gestartet:
<syntaxhighlight lang="shell" lines>
systemctl --user daemon-reload
systemctl --user enable synapse.service
systemctl --user start synapse.service
</syntaxhighlight>
== Einrichten des Apache VHost ==

Die ''~/doms/matrix.beispiel.de/.htaccess'' mit dem Editor der Wahl öffnen und
folgende Konfiguration einfügen:
<syntaxhighlight lang=apache line>
DirectoryIndex disabled
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule .* http://localhost:32801%{REQUEST_URI} [NE,proxy]
RequestHeader set X-Forwarded-Proto "https"
</syntaxhighlight>
== Well-Known unter beispiel.de ==

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

https://beispiel.de/.well-known/matrix/server
<syntaxhighlight lang=json line>
{
"m.server": "matrix.beispiel.de:443"
}
</syntaxhighlight>

https://beispiel.de/.well-known/matrix/client
<syntaxhighlight lang=json line>
{
"m.homeserver": {
"base_url": "https://matrix.beispiel.de"
},
"m.identity_server": {
"base_url": "https://vector.im"
}
}
</syntaxhighlight>

Für die muss noch der CORS-Header Access-Control-Allow-Origin "*" gesetzt werden, damit die Datei aus beliebigem Riot-Web im Browser abrufbar ist. Dazu in den Ordner .well-known/matrix/ folgende .htaccess anlegen:
<syntaxhighlight lang=apache line>
<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin "*"
</IfModule>
</syntaxhighlight>

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

== Update von Synapse ==

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

oder falls Synapse mit pip verwaltet wird:

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

<syntaxhighlight lang=shell>
monit stop synapse
#... updaten ...
monit start synapse
</syntaxhighlight>

Wenn die Föderation für den Synapse Server aktiviert ist, kann mit dem [https://federationtester.matrix.org/ Matrix Federation Tester] die eigene Instanz auf die laufende Version geprüft werden. Als Server nicht matrix.example.org eingeben, sondern den öffentlichen Namen, wo auch die Benutzernamen drauf laufen, z.B. example.org

Ansonsten ist die laufende Version auch über die URL https://matrix.example.org/_synapse/admin/v1/server_version zu erfahren.

== Element-Web ==

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

* Account und Domain anlegen (separat von der Synapse-Domain)
* [https://github.com/element-hq/element-web/releases/latest aktuelles element-web release] .tgz herunterladen
* Symlink von htdocs-ssl auf entpacktes element-web-Verzeichnis
* config.sample.json in config.json kopieren und Matrix-Homeserver-Einträge anpassen
* Piwik aus config.json entfernen

== SAML mit Synapse ==

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

Das Paket xmlsec1 muss installiert sein:

<syntaxhighlight lang=shell>
$ xmlsec1 --version
xmlsec1 1.2.23 (openssl)
</syntaxhighlight>

Das Python-Paket pysaml2 installieren

<syntaxhighlight lang=shell>
cd ~/synapse
pipenv shell
pipenv install pysaml2
</syntaxhighlight>

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

<syntaxhighlight lang=yaml line>
# Once SAML support is enabled, a metadata file will be exposed at
# https://<server>:<port>/_matrix/saml2/metadata.xml, which you may be able to
# use to configure your SAML IdP with. Alternatively, you can manually configure
# the IdP to use an ACS location of
# https://<server>:<port>/_matrix/saml2/authn_response.
#
saml2_config:
sp_config:
# point this to the IdP's metadata. You can use either a local file or
# (preferably) a URL.
metadata:
#local: ["saml2/idp.xml"]
remote:
- url: https://login.beispiel.de/simplesaml/saml2/idp/metadata.php
</syntaxhighlight>
Wichtig ist außerdem, dass die public_baseurl in der homeserver.yaml gesetzt ist, damit Synapse weiß, wie es erreichbar ist und dies in seine SP-Metadaten einbauen kann:
<syntaxhighlight lang=yaml line>
public_baseurl: https://matrix.beispiel.de/
</syntaxhighlight>
Die Service-Provider-Konfiguration als XML bekommt man von Synapse dann wie schon in der homeserver.yaml als Kommentar beschrieben, unter https://matrix.beispiel.de/_matrix/saml2/metadata.xml

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

== Federation Sender Worker für Synapse ==

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

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

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

In der homeserver.yaml die Worker-Konfiguration aktivieren:
<syntaxhighlight lang=yaml line>
## Worker ##
worker_app: synapse.app.homeserver
daemonize: true
</syntaxhighlight>

und dazugehörige Listener (Abschnitt listener:) aktivieren:
<syntaxhighlight lang=yaml line>
# The TCP replication port
- port: 32892
bind_address: '127.0.0.1'
type: replication
# The HTTP replication port
- port: 32893
bind_address: '127.0.0.1'
type: http
resources:
- names: [replication]
</syntaxhighlight>

Funktionen, die Worker machen sollen, in der homeserver.yaml deaktivieren:
<syntaxhighlight lang=yaml line>
# disable federation sending here, use worker for it
send_federation: False
</syntaxhighlight>
Dann Verzeichnis synapse/workers anlegen, darin federation_sender.yaml:
<syntaxhighlight lang=yaml line>
worker_app: synapse.app.federation_sender

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

worker_daemonize: True
worker_pid_file: /home/pacs/xyz00/users/matrix/synapse/federation_sender.pid
worker_log_config: /home/pacs/xyz00/users/matrix/synapse/federation_sender.log.config
</syntaxhighlight>
.monitrc um worker erweitern:
<syntaxhighlight lang=shell line>
check process federation_sender with pidfile /home/pacs/xyz00/users/matrix/synapse/federation_sender.pid
start program "/bin/bash -c 'export VIRTUAL_ENV=$HOME/synapse/env && export PATH=$VIRTUAL_ENV/bin:$PATH && cd $HOME/synapse && synctl -w workers/federation_sender.yaml start'"
stop program "/bin/bash -c '/bin/kill $( cat $HOME/synapse/federation_sender.pid )'"
</syntaxhighlight>
Monit neu laden und synapse und federation_sender neustarten:

<syntaxhighlight lang=shell>
monit reload
monit restart all
</syntaxhighlight>

Nach Updates ebenfalls immer Hauptprozess und alle Worker neustarten

<syntaxhighlight lang=shell>
monit restart all
</syntaxhighlight>

== Sliding Sync Proxy ==
Zum Zeitpunkt dieser Anleitung werden aktiv neue Element Anwendungen (Element X) und ein neues Syncverfahren entwickelt um Matrix performanter und weniger ressourcenhungrig zu machen. Bei stärkerer Matrix Nutzung können die neuen Anwendungen besonders mobil schon eine große Entlastung sein.

<strong>Ende 2024 wurden grundlegende Funktionen direkt in Synapse implementiert. Der Proxy wird nicht länger weiterentwickelt und sollte deinstalliert werden (nicht vergessen die .well-known zurück zu ändern).</strong> Auch der 3rdparty Server [[Conduit]] bringt nativ Support für Sliding Sync.</strong>

== Links ==

* https://matrix.org/docs/projects/server/synapse
* https://github.com/element-hq/synapse
* https://github.com/element-hq/synapse/blob/master/INSTALL.md
* https://github.com/matrix-org/sliding-sync
* https://matrix.org/docs/spec/
* https://www.hostsharing.net/loesungen/matrix/
* https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/synapse
* https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/element

[[Kategorie:Messenger]]
[[Kategorie:Software]]
[[Kategorie:Eigene Daemons]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]

CAS Authentication Server

2025-01-02T15:51:16Z

Chg93-hsdoku: /* Einrichtung des Tomcat */ RAM buchen

= CAS Authentication Server =

Der CAS Server ("Central Authentication Service" oder "CAS Authentication Server") ist eine SSO- ("Single Sign On") Lösung.

CAS ist für große, verteilte Deployments von Web-Anwendungen geeignet. Er stammt aus dem Universitätsumfeld in den USA. Er wurde bei der Yale Universität entwickelt und wird aktuell bei JA-SIG / Apereo als freie Software unter der Apache Lizenz gepflegt. [1], [2]

Die Hostsharing eG nutzt CAS seit Jahren als Login-Lösung insbesondere für die Administrationswerkzeuge von [[Hsadmin|HSAdmin]].

Dieser Beitrag erläutert die Installation von CAS in einem Hostsharing Webspace und die Konfiguration von Beispielanwendungen zum Login mit CAS. Als Nutzerdatenbank wird ein vorhandener Nutzerstamm in einer SQL-Datenbank benutzt.

== Erste Installation ==

Die aktuelle stabile Version des CAS Server ist v6.6.7 (Stand August 2024: v7.0.6). Diese Version erfordert Java 11. Die empfohlene Installation eines Standalone-CAS erfolgt über das WAR Overlay Projekt [3]. Eine ausführliche Deployment-Anleitung (leider noch für Version 5.x) findet sich bei [https://www.newschool.edu/ The New School] [4]. Eine Anleitung für die aktuelle Version 6.6.x ist unter [10] verfügbar.

=== Service-User und Domain ===

Zunächst werden mit HSAdmin ein User und eine Domain eingerichtet. Darauf achten, dass der User eine gültige Login-Shell erhält, hier die Bash (''/bin/bash'').

<syntaxhighlight lang="bash">
xyz00@h50:~$ hsscript -i
xyz00@hsadmin> user.add({set:{name:'xyz00-login',shell:'/bin/bash',password:'***'}})
xyz00@hsadmin> domain.add({set:{user:'xyz00-login',name:'login.hs-example.de'}})
xyz00@hsadmin> bye
</syntaxhighlight>

=== Einrichtung des Tomcat ===

Die hier beschriebene Installation benötigt bei Hostsharing die Paket-Option "RAM". Benötigt werden min. 512 MB. Im Managed Webspace ist diese Option kostenpflichtig: https://www.hostsharing.net/angebote/managed-webspace/ gebucht werden muss der RAM auch bei einem Managed-Server.
Bei der Anmeldung (bei service(at)hostsharing.net bitte den Service User ''xyz00-login'' und die gewünschte Anzahl IP-Ports angeben). Hier verwenden wir die Ports 31530, 31531 und 31532.

Weiter geht es als User ''xyz00-login''

Einrichten eines Apache Tomcat 9 (Stand August 2024: [[Tomcat Installieren|Apache Tomcat 10]]) im Userspace:

<syntaxhighlight lang="output">
xyz00-login@h50:~$ tomcat9-instance-create tomcat9
You are about to create a Tomcat instance in directory 'tomcat9'
Warning: HTTP port 8080 appears to be in use.
Type <ENTER> to continue, <CTRL-C> to abort.
</syntaxhighlight>

Mit <Enter> bestätigen, dann wird eine Tomcat-Konfiguration im neuen Verzeichnis $HOME/tomcat9 angelegt.

Die ''server.xml'' im Verzeichnis $HOME/tomcat9/conf wird angepasst:

<syntaxhighlight lang="xml" line>
<?xml version="1.0" encoding="UTF-8"?>
<Server port="31530" shutdown="SHUTDOWN">

<Listener className="org.apache.catalina.startup.VersionLoggerListener" />
<Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" />
<Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />
<Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />
<Listener className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" />

<GlobalNamingResources>
<Resource name="UserDatabase" auth="Container" type="org.apache.catalina.UserDatabase"
description="User database that can be updated and saved"
factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
pathname="conf/tomcat-users.xml" />
</GlobalNamingResources>

<Service name="Catalina">
<Connector address="localhost" port="31531" protocol="AJP/1.3" redirectPort="443" secretRequired="false" />
<Engine name="Catalina" defaultHost="localhost">
<Realm className="org.apache.catalina.realm.LockOutRealm">
<Realm className="org.apache.catalina.realm.UserDatabaseRealm" resourceName="UserDatabase"/>
</Realm>
<Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true">
</Host>
</Engine>
</Service>
</Server>
</syntaxhighlight>

Insbesondere die beiden Angaben ''port="31530"'' und ''port="31531"'' müssen angepasst werden!

In der Datei ''setenv.sh'' im Verzeichnis $HOME/tomcat9/bin ergänzenen wir den Pfad zur Java 11 Installation als Variable $JAVA_HOME (für 32-Bit bzw. für 64-Bit Systeme), dazu den Pfad für eine Datei mit der Prozess-ID Prozess-Id und eine System-Property in den Java-Opts mit dem Verzeichnis-Pfad, in dem wir später die CAS-Konfiguration ablegen:

<syntaxhighlight lang="bash">
# export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-i386
export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64
export JAVA_OPTS="-Djava.awt.headless=true -Dcas.standalone.configurationDirectory=/home/pacs/xyz00/users/login/cas/conf"
</syntaxhighlight>

Ich kopiere zum Testen gern noch das Startskript ''catalina.sh'' in die Installation des Tomcat:

<syntaxhighlight lang="bash">
xyz00-login@h50:~$ cp /usr/share/tomcat9/bin/catalina.sh $HOME/tomcat9/bin/
xyz00-login@h50:~$ cd tomcat9/
xyz00-login@h50:~/tomcat9$ ./bin/catalina.sh run
Using CATALINA_BASE: /home/pacs/xyz00/users/login/tomcat9
Using CATALINA_HOME: /usr/share/tomcat9
Using CATALINA_TMPDIR: /home/pacs/xyz00/users/login/tomcat9/temp
Using JRE_HOME: /usr/lib/jvm/default-java
Using CLASSPATH: /usr/share/tomcat9/bin/bootstrap.jar:/usr/share/tomcat9/bin/tomcat-juli.jar
<6>Server version name: Apache Tomcat/9.0.31 (Debian)
[...]
<6>Server startup in [75] milliseconds
</syntaxhighlight>

Tomcat läuft, abbrechen mit <Ctrl-C>

=== Konfiguration des Apache als Proxy ===

<syntaxhighlight lang="bash">
cd ~/doms/login.hs-example.de/
rm -rf subs/www subs-ssl/www
</syntaxhighlight>

Bearbeiten der ~/doms/login.hs-example.de/htdocs-ssl/.htaccess

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

Achtung: der Port 31531 ist wieder durch den Port des AJP-Listeners in der eigenen Tomcat-Konfiguration zu ersetzen.

=== CAS Basisinstallation ===

Auschecken des CAS Overlay Projektes (TODO: Warum nicht ```git checkout 6.6```? Typo?)

<syntaxhighlight lang="bash">
mkdir git
cd git
git clone https://github.com/apereo/cas-overlay-template.git
cd cas-overlay-template/
git fetch
git checkout 6.0
</syntaxhighlight>

Anlegen von Verzeichnissen für die spätere Konfiguration des CAS Server

<syntaxhighlight lang="bash">
cd
mkdir -p cas/conf
mkdir -p cas/services
</syntaxhighlight>

Ins Verzeichnis ''~/cas/conf'' legen wir eine Datei ''cas.properties'' mit folgendem Inhalt:

<syntaxhighlight lang="ini" line>
cas.server.name=https://login.hs-example.de
cas.server.prefix=${cas.server.name}/cas
cas.serviceRegistry.json.location=file:/home/pacs/xyz00/users/login/cas/services
logging.config=file:/home/pacs/xyz00/users/login/cas/conf/log4j2.xml
</syntaxhighlight>

Die Datei ''log4j2.xml'' kopieren wir aus ''~/git/cas-overlay-template/etc/cas/config/''

<syntaxhighlight lang="bash">
cp ~/git/cas-overlay-template/etc/cas/config/ ~/cas/conf/
</syntaxhighlight>

In der log4j2.xml passen wir den Wert für die Variable ''baseDir'' (etwa Zeile 5) an:

<syntaxhighlight lang="xml">
<Property name="baseDir">/home/pacs/xyz00/users/login/tomcat9/logs</Property>
</syntaxhighlight>

Build und Deployment der Web-Applikation

<syntaxhighlight lang="bash">
./build.sh package
cd
cp ~/git/cas-overlay-template/build/libs/cas.war ~/tomcat9/webapps/
</syntaxhighlight>

Nach einer erneuten Start des Tomcat ist das CAS-Login unter
https://login.hs-example.de/cas/ erreichbar.

Ein Login mit der Kennung ''casuser'' und dem Passwort ''Mellon'' sollte erfolgreich sein.

== Erweiterte Konfiguration des CAS ==

Die Funktionalität des CAS Server ist modular erweiterbar. Im ersten Schritt erweitern wir den CAS um eine Service Registry. Für unsere einfache Standalone-Installation nutzen wir die JSON-File-Registry

=== JSON Service Registry ===

Erweiterungen werden in der Datei ''build.gradle'' im Abschnitt ''dependencies'' eingetragen. Die Datei liegt im Wurzelverzeichnis des Git-Repositories für unser CAS Overlay (''~/git/cas-overlay-template/'').

Der betreffende Ausschnitt der Datei:

<syntaxhighlight lang="java" line>
dependencies {
// [...] Teile ausgespart

/**
* CAS dependencies and modules may be listed here.
*
* There is no need to specify the version number for each dependency
* since versions are all resolved and controlled by the dependency management
* plugin via the CAS bom.
**/

// email notification, service registry
implementation "org.apereo.cas:cas-server-core-notifications"
implementation "org.apereo.cas:cas-server-support-json-service-registry"

// jdbc datasource
implementation "org.apereo.cas:cas-server-support-jdbc-drivers"
implementation "org.apereo.cas:cas-server-support-jdbc"

// password reset
implementation "org.apereo.cas:cas-server-support-pm-webflow"
implementation "org.apereo.cas:cas-server-support-pm-jdbc"

// openid-connect / oidc
implementation "org.apereo.cas:cas-server-support-oidc"

/**
* Do NOT modify the lines below or else you will risk breaking the build.
*/
implementation "org.apereo.cas:cas-server-core-api-configuration-model"
implementation "org.apereo.cas:cas-server-webapp-init"

// [...] Teile ausgespart
}
</syntaxhighlight>

Wir bauen das cas.war mit den folgenden Befehlen neu:

<syntaxhighlight lang="bash">
cd ~/git/cas-overlay-template
./build.sh package
cp ~/git/cas-overlay-template/build/libs/cas.war ~/tomcat9/webapps/
</syntaxhighlight>

Der Pfad zur Service-Registry war in der oben erstellten ''cas.properties'' bereits enthalten.
Nun legen wir einen ersten Service an, in meinem Fall eine Nextcloud-Installation. Die Datei heißt
''hsexamplecloud-1000001.json'' und wird im Verzeichnis ''~/cas/services/'' abgelegt. Der Inhalt:

<syntaxhighlight lang="json" line>
{
"@class" : "org.apereo.cas.services.RegexRegisteredService",
"serviceId" : "^https://cloud.hs-example.de.*",
"name" : "hsexamplecloud",
"id" : 1000001,
"description" : "Nextcloud HS-Example",
"evaluationOrder" : 10000
}
</syntaxhighlight>

Der Name der Datei setzt sich aus Service-Name und Service-Id zusammen!

Die Konfiguration des CAS-Login in der Nextcloud erfolgt über die entsprechende "App" in Nextcloud.
Die Parameter sind wie folgt:

[[Datei:Cas-nextcloud-app.png]]

Die "Dienst-URL" im Screenshot ist: ''https://cloud.hs-example.de/index.php/apps/user_cas/login''

Die Anmeldung mit der Kennung ''casuser'' und dem Passwort ''Mellon'' sollte nun von der Nextcloud-Loginseite über den Link zum CAS-Login möglich sein.

=== Authentifizierung gegen JDBC Datenbank ===

Wir erweitern wieder die Datei ''build.gradle'' im Abschnitt ''dependencies''.

<syntaxhighlight lang="java" line>
dependencies {
compile "org.apereo.cas:cas-server-webapp${project.appServer}:${casServerVersion}"
// Other CAS dependencies/modules may be listed here...
compile "org.apereo.cas:cas-server-support-json-service-registry:${project.'cas.version'}"
compile "org.apereo.cas:cas-server-support-jdbc-drivers:${project.'cas.version'}"
compile "org.apereo.cas:cas-server-support-jdbc:${project.'cas.version'}"
}
</syntaxhighlight>

''cas-server-support-jdbc-drivers'' liefert JDBC-Treiber für die gängigen Open-Source Datenbanksysteme. ''org.apereo.cas:cas-server-support-jdbc'' liefert das eigentliche CAS-Authentication Backend.

Zur Konfiguration wird die Datei ''cas.properties'' im Verzeichnis ''~/cas/conf/'' erweitert:

<syntaxhighlight lang="java" line>
cas.server.name=https://login.hs-example.de
cas.server.prefix=${cas.server.name}/cas
cas.serviceRegistry.json.location=file:/home/pacs/xyz00/users/login/cas/services
logging.config=file:/home/pacs/xyz00/users/login/cas/conf/log4j2.xml
logging.level.org.apereo=DEBUG
cas.authn.jdbc.query[0].sql=SELECT * FROM USERS WHERE UID=?
cas.authn.jdbc.query[0].url=jdbc:postgresql://localhost/xyz00_cas
cas.authn.jdbc.query[0].dialect=org.hibernate.dialect.PostgreSQL92Dialect
cas.authn.jdbc.query[0].user=xyz00_cas
cas.authn.jdbc.query[0].password=Ein_schlechtes_Passwort
cas.authn.jdbc.query[0].driverClass=org.postgresql.Driver
cas.authn.jdbc.query[0].fieldPassword=PSW
cas.authn.jdbc.query[0].passwordEncoder.type=BCRYPT
cas.authn.jdbc.query[0].passwordEncoder.characterEncoding=UTF-8
cas.authn.accept.users=
</syntaxhighlight>

Hier ein Beispiel für eine PostgreSQL-Datenbank mit einer Tabelle ''USERS'' mit den Spalten ''UID'' und ''PSW''. Die Spalte ''UID'' enthält den Login-Namen des Users, die Spalte ''PSW'' das Passwort mit dem BCrypt-Algorithmus verschlüsselt.

Die Zeile ''cas.authn.accept.users='' deaktiviert das Default-Login als User ''casuser'' mit Passwort ''Mellon''.

Achtung: Das Spring-Security Framework erwartet das BCrypt-Passwort mit der Kennung ''$2a$'' als erste Zeichen des Passwortfeldes. Die PHP-Funktion ''password_hash'' schreibt ''$2y$'' Wenn eine PHP-Passwort-Datenbank genutzt wird, muss hier ggf. eine VIEW in der Datenbank helfen.

== Grafische Anpassung der CAS Login-Seiten ==

Die Anpassungen der Login-Seite und anderer Teile der Browser-Anwendung ist vorgesehen. Eine Anleitung findet sich unter Link [7] und [4].

== Links ==

[1] https://de.wikipedia.org/wiki/Central_Authentication_Service

[2] https://www.apereo.org/projects/cas

[3] https://github.com/apereo/cas-overlay-template

[4] https://dacurry-tns.github.io/deploying-apereo-cas/

[5] https://apereo.github.io/2017/02/22/cas51-dbauthn-tutorial/

[6] https://apereo.github.io/2017/02/02/cas51-authn-handlers/

[7] https://apereo.github.io/2018/06/10/cas-userinterface-customizations/

[8] https://apereo.github.io/tags/#CAS

[9] https://iam.uconn.edu/java-cas-client-installation-and-configuration/

[10] https://fawnoos.com/2022/08/06/cas66-gettingstarted-overlay/

[11] https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/cas Ansible Playbook

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]
[[Kategorie:Software]]
[[Kategorie:SSO]]
[[Kategorie:Java]]
[[Kategorie:Eigene Daemons]]

Aliases

2024-12-20T15:58:08Z

Chg93-hsdoku:

{{Textkasten|rot|Hinweis:|Inhalt ist nun in der HS Dokumentation.
https://www.hostsharing.net/doc/managed-operations-platform/hsadmin/emailaliases/
}}

---
[[Kategorie:Glossar]]

Diskussion:Pakete

2024-12-20T15:54:30Z

Chg93-hsdoku: /* Baustelle entfernt */

Als Baustelle da noch keine Links eingefügt.
: Gibt es eigentlich DOM/R noch? Auf der homepage läuft der Link dazu ins Leere --[[Benutzer:Deg00-m.website|ChristofT]] 22:44, 19. Feb. 2009 (UTC)

== Fluss der Ideen ==

Hi. Hier sehe ich gerade, dass der "Fluss der Ideen" genau umgekehrt zum Text auf dieser Seite verläuft. Normalerweise geht man vom Allgemeinen zum Speziellen. Hier ist es umgekehrt, bzw. ein Mischmasch. Dann: was soll "Weiterführende Links" als Unterpunkt von "Kombination von SW und DW"? Das ist sinnfrei! Ich will jetzt nicht nachvollziehen, wer das verbrochen hat, aber wenn man editiert, sollte man keine Baustellen hinterlassen. Diese Seite werde ich demnächst hier ändern. --[[Benutzer:Deg00-m.website|ChristofT]] 12:56, 4. Jun. 2010 (CEST)

== Reihenfolge und Kombination erweitert ==

Moin, hab die Reihenfolge (allgemein -> spziell) umgestellt und den Teil Kombination DW+SW etwas erwetiert, mit den Schritten die ich auch bei meinen Paketen zur Zeit anwende.
Hier fehlen noch ein paar Details, die steuere ich demnächst noch bei. --[[Benutzer:Al000-hs]] 11:28, 23. Feb. 2011
:Bitte bei den Diskussionsbeiträgen immer an die Signatur denken. --[[Benutzer:Ubl00|Ubl00]] 10:36, 23. Apr. 2011 (CEST)

== Freigabe so ? ==

Hallo,
habe einige Links noch eingefügt und Kleinigkeiten ergänzt.
Sowie die Sonderbehandlungvon xyz00.hostsharing.net beseitigt.

Christof, wollen wir die Seite so erst mal wieder frei geben?
Bis der Inhalt unter der Kern Doku auf der HP erscheint wird es wohl noch dauern :-)
--[[Benutzer:Chg00-hsdoku|Christian Günter]] ([[Benutzer Diskussion:Chg00-hsdoku|Diskussion]]) 10:11, 9. Jul. 2012 (CEST)

Baustelle entfernt. Sobald die KernDoku da ist wird die Seite gelöscht.
--[[Benutzer:Chg00-hsdoku|Christian Günter]] ([[Benutzer Diskussion:Chg00-hsdoku|Diskussion]]) 14:19, 27. Aug. 2012 (CEST)

== Wieder Baustelle ==

Christian hat in members@ darauf hingewiesen, dass die Paketnamen veraltet sind. Vollkommen richtig. Pakete müssen allgemein beschrieben werden, es können wahrscheinlich keine aktuell in der Preisliste vorhandenen Paketnamen verwendet werden. --[[Benutzer:Deg00-m.website|ChristofT]] ([[Benutzer Diskussion:Deg00-m.website|Diskussion]]) 17:14, 12. Dez. 2016 (CET)
: Gibt es überhaupt noch SW Pakete? --[[Benutzer:Deg00-m.website|ChristofT]] ([[Benutzer Diskussion:Deg00-m.website|Diskussion]]) 17:20, 12. Dez. 2016 (CET)

== Baustelle entfernt ==
Aktuell ist die Bezeichnug WebPaket xyz00 voll gültig. Ich habe den Link zur Kerndoku aktualisiert daher wieder freigabe.

Diskussion:Pakete

2024-12-20T15:53:39Z

Chg93-hsdoku:

Als Baustelle da noch keine Links eingefügt.
: Gibt es eigentlich DOM/R noch? Auf der homepage läuft der Link dazu ins Leere --[[Benutzer:Deg00-m.website|ChristofT]] 22:44, 19. Feb. 2009 (UTC)

== Fluss der Ideen ==

Hi. Hier sehe ich gerade, dass der "Fluss der Ideen" genau umgekehrt zum Text auf dieser Seite verläuft. Normalerweise geht man vom Allgemeinen zum Speziellen. Hier ist es umgekehrt, bzw. ein Mischmasch. Dann: was soll "Weiterführende Links" als Unterpunkt von "Kombination von SW und DW"? Das ist sinnfrei! Ich will jetzt nicht nachvollziehen, wer das verbrochen hat, aber wenn man editiert, sollte man keine Baustellen hinterlassen. Diese Seite werde ich demnächst hier ändern. --[[Benutzer:Deg00-m.website|ChristofT]] 12:56, 4. Jun. 2010 (CEST)

== Reihenfolge und Kombination erweitert ==

Moin, hab die Reihenfolge (allgemein -> spziell) umgestellt und den Teil Kombination DW+SW etwas erwetiert, mit den Schritten die ich auch bei meinen Paketen zur Zeit anwende.
Hier fehlen noch ein paar Details, die steuere ich demnächst noch bei. --[[Benutzer:Al000-hs]] 11:28, 23. Feb. 2011
:Bitte bei den Diskussionsbeiträgen immer an die Signatur denken. --[[Benutzer:Ubl00|Ubl00]] 10:36, 23. Apr. 2011 (CEST)

== Freigabe so ? ==

Hallo,
habe einige Links noch eingefügt und Kleinigkeiten ergänzt.
Sowie die Sonderbehandlungvon xyz00.hostsharing.net beseitigt.

Christof, wollen wir die Seite so erst mal wieder frei geben?
Bis der Inhalt unter der Kern Doku auf der HP erscheint wird es wohl noch dauern :-)
--[[Benutzer:Chg00-hsdoku|Christian Günter]] ([[Benutzer Diskussion:Chg00-hsdoku|Diskussion]]) 10:11, 9. Jul. 2012 (CEST)

Baustelle entfernt. Sobald die KernDoku da ist wird die Seite gelöscht.
--[[Benutzer:Chg00-hsdoku|Christian Günter]] ([[Benutzer Diskussion:Chg00-hsdoku|Diskussion]]) 14:19, 27. Aug. 2012 (CEST)

== Wieder Baustelle ==

Christian hat in members@ darauf hingewiesen, dass die Paketnamen veraltet sind. Vollkommen richtig. Pakete müssen allgemein beschrieben werden, es können wahrscheinlich keine aktuell in der Preisliste vorhandenen Paketnamen verwendet werden. --[[Benutzer:Deg00-m.website|ChristofT]] ([[Benutzer Diskussion:Deg00-m.website|Diskussion]]) 17:14, 12. Dez. 2016 (CET)
: Gibt es überhaupt noch SW Pakete? --[[Benutzer:Deg00-m.website|ChristofT]] ([[Benutzer Diskussion:Deg00-m.website|Diskussion]]) 17:20, 12. Dez. 2016 (CET)

== Baustelle entfernt ==
Aktuell ist die Bezeichnug WebPaket xyz00 voll gültig. Ich habe dne Link zur Kerndoku aktualisiert daher wieder freiegabe.

Pakete

2024-12-20T15:50:33Z

Chg93-hsdoku: link zur Kerndoku

{{HSDoku-Links}}

{{Kerndoku|https://www.hostsharing.net/doc/managed-operations-platform/webpaket/}}

Ein Paket ist technisch eine Unix Gruppe auf einem Hostsharing [[Hive]]. Alle Leistungen von Hostsharing Servern werden in Paketen gebündelt, die eine definierte Leistung beinhalten. Alle Pakete können durch Optionen aufgewertet werden.

Jedes Paket hat eine Bezeichnung in der Form xyz00. Sie besteht aus dem bei der ersten Paketeinrichtung frei wählbaren Präfix und einem zweistelligen Zähler.

Entsprechend ist

* der Name des Paketadmins xyz00
* das Paketverzeichnis /home/pacs/xyz00/
* die Paketdomain xyz00.hostsharing.net

Die Paketdomain kann für alle Zugriffe auf das Paket benutzt werden, beispielsweise für den Upload von Daten mittels FTP oder SCP und für das Einloggen über ssh.

Konkretere Informationen und die Zugangsdaten enthält die Willkommens-E-Mail, die Du Nach der Bestellung eines Paketes erhältst.

Ein Paket kann u.a. für Webseiten,Content-Management-Systeme, Web-Shops genutzt werden, die (CPU und I/O intensiv, und dennoch performant) mit Hilfe von Programmen und Datenbanken im Paket dynamisch erzeugt werden.

Ein Paket eignet sich ebenfalls für statische Daten und Webseiten, die aus statischen HTML Dateien bestehen. Insbesondere E-Mail Postfächer, (CVS) Quellcode, Up/Downloads, Bildergalerien und andere wichtige Daten, die ständig verfügbar und auf Backups und Stand-by Servern gesichert sein sollen.

= Weiterführende Links =
[[WEB-Paket]]<br>
[[DomainManagement]]<br>
[[Pakettraffic]]<br>
[[Eventhandler]]

----
[[Kategorie:Pakete bei HS]]
[[Kategorie:HSDoku]]
[[Kategorie:Glossar]]
[[Kategorie:ToDo-Kerndoku]]
[[Kategorie:Traffic]]

Nextcloud

2024-12-06T12:16:47Z

Chg93-hsdoku: /* Redis Cache */ RAM für eigene Serverdineste - statt DAEMON

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

hsscript -u xyz00 -i
Password: ********

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>

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=php8.2 /home/pacs/xyz00/users/cloud/nextcloud/cron.php
</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. <strong>aus diesem Grund ist das automatische Setup durch das Plugin bei Hostsharing nicht möglich!</strong>

==== 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)<br>
2. falls noch nicht erstellt: <code>mkdir -p ~/.config/systemd/user</code><br>
3. mit Lieblingseditor die Datei <code>~/.config/systemd/user/notify_push.service</code> anlegen:<br>
<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:<br><code>export XDG_RUNTIME_DIR=/run/user/$UID</code><br>
6. den neuen systemd-Dienst automatisch bei Systemstart, sowie jetzt sofort starten:<br><code>systemctl enable --now --user notify_push</code><br>
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><br>
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. <br><br>

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

FAQ

2024-11-19T13:11:04Z

Chg93-hsdoku: /* Wie ändere Ich Adress-Daten vom Domain Inhaber / Admin? (whois) */

{{HSDoku-Links}}

FAQ heißt Frequently Asked Questions - Fragen, die immer wieder gestellt werden. Hier ist der Platz, sie zu beantworten.

== Domains ==

=== Domain bei anderem Provider, Subdomain bei HS und umgekehrt ===
:Fall A -> Domain example.com bei Anbieter XY
:Subdomain test.example.com bei Hostsharing
:Was ist zu tun?
:* Bei Anbieter XY sollten DNS-Einträge geschaltet werden, damit Hostsharing die Subdomain verwalten kann:

:test.example.com. IN NS dns1.hostsharing.net.
:test.example.com. IN NS dns2.hostsharing.net.
:test.example.com. IN NS dns3.hostsharing.net.

:* Bei Hostsharing kann die Domain test.example.com nun via HSAdmin hinzugefügt werden. Im Domainbestellsystem ist keine Aktion erforderlich, da es sich nicht um eine Domain-Registrierung handelt.

:Welche Voraussetzungen sind zu erfüllen?
:Anbieter XY muss die entsprechend DNS-Schaltung ermöglichen.

:Welche Kosten fallen an?
:Bei Hostsharing fallen keine Kosten an, abgesehen vom Webspace- und Traffic-Bedarf des Angebots unter test.example.com.

:Fall B -> Domain example.com bei Hostsharing
:Subdomain test.example.com bei Anbieter XY

:Was ist zu tun?
:* Bei Hostsharing sollten über die Zonefile-Verwaltung DNS-Einträge geschaltet werden, so dass der Anbieter XY die Subdomain verwalten kann.

:test.example.com. IN NS <DNS-Server 1 des Anbieters>
:test.example.com. IN NS <DNS-Server 2 des Anbieters>
:...

:Die Angaben sind bei dem entsprechenden Anbieter zu erfragen.
:* Die Subdomain kann anschließend bei bei Anbieter XY geschaltet werden.

:Welche Voraussetzungen sind zu erfüllen?
:Anbieter XY muss Aufschaltung von Subdomains unterstützen.

:Welche Kosten fallen an?
:Bei Hostsharing fallen keine Kosten an, abgesehen vom ohnehin zu leistenden Entgelt für die Domain example.com.

=== Wie komme ich an einen Auth Code für eine hier gehostete .com/.de Domain? ===

: Kann im Account des [https://domain-bestellsystem.de Domain-Bestellsystem ] selbst abgefragt, bzw. erzeugt werden:
"Auftragsübersicht" wählen, dort die Domain anklicken, unter "Ausführbare Aktionen". (nicht im KK-Center.)

=== Was sind CNO-Domains? ===
:CNO steht für "COM", "NET" und "ORG". Im Gegensatz zu DE-Domains,welche auf ".de" enden (z.B. hostsharing.de), enden CNO - Domains auf ".com", ".net" oder ".org" (z.B. hostsharing.net).
:Im Allgemeinen steht .com für ein kommerzielles Angebot und .org für eine nicht kommerzielle Organisation. Die Endung .net wird heute oft genutzt, wenn die entsprechende .com - Domain bereits vergeben ist und ist weit verbreitet.

=== Wie mache ich zwei Domain-Verzeichnisse identisch, die zwei unterschiedlichen usern gehören? ===

:Das ist nicht möglich.

=== Wie ändere ich den Domain Admin ? ===

:Als Domainadmin informiere Deinen Paketadmin.
:Als Paketadmin siehe https://doc.hostsharing.net/users/administration/domain/index.html.

=== Wie ändere Ich Adress-Daten vom Domain Inhaber / Admin? (whois)===
Im Feb 2010 wurden an alle HS Mitglieder die Zugangsdaten für unser
[https://domain-bestellsystem.de Domain-Bestellsystem ] versendet.
Dort kann auch die gesamte Adresse oder nur Telefon und E-Mail Daten geändert werden.
Wer diese Zugangsdaten nicht mehr hat kurze E-Mail an service@hostsharing.net
:Nach der Anmeldung auf Menüpunkt "Handleverwaltung"
:Dann bei "Suchen" die HandleID und bei im Feld "Handle-ID" auswählen -> Button "suchen"
:Die aktuelle HandleID über Menü "Auftragsübersicht" und dann auf die "Domain" klicken.
: ggf auch die Stammdaten bei eigenen Änderungen anpassen.

== E-Mail ==

=== Meine E-Mail wurde abgelehnt, obwohl sie kleiner als 128 MB ist ===
:Du hast nicht bedacht, dass der Anhang durch die Kodierung an Größe zunimmt. Siehe [[Größenbeschränkung von E-Mails]]

=== Was bedeutet die Fehlermeldung <strong>554 hop-count exceeded</strong> in einer E-Mail ? ===
: Eine E-Mail ist zwischen zwei Adressen weitergeleitet und es entstand eine Weiterleitungsschleife. Im Mailserver gibt es die Einstellung: hopcount_limit = 50. Wenn eine Mail über 50 Emailserver ging, dann wird die gebounced. Damit verhindert man solche Schleifen.

=== Eigener Mailserver: status=bounced host mailin[x].hostsharing.net ... said: Relay access denied===
:Wer einen eigenen Mailserver zum Einliefern von E-Mail benutzt und über die Mailserver von Hostsharing als Relayhost (weiterleitenden Mailserver) senden möchte, liefert die Mail an das Paket xyz00.hostsharing.net. Dabei ist unbedingt zu vermeiden, dass der einliefernde Mailserver MX-Lookups macht. Bei Postfix geht das, indem der Relayhost in der Konfiguration eckigen Klammern angegeben wird: relayhost = [xyz01.hostsharing.net]
:Siehe https://lists.hostsharing.net/archiv/global-announce/2012-October/000566.html

== WWW ==

=== Meine Webseite ist nicht erreichbar ===

: Schau auf http://status.hostsharing.net - da kannst Du sehen, ob es ein Problem auf dem Server von HS gibt. Siehe [[Überwachung der HS-Dienste]]

=== Wieviel Speicherplatz haben meine User in meinem Paket belegt? ===

:siehe [[Speicherbelegung]].

=== Wieviel Speicherplatz im Hauptspeicher ist pro Anwendung in meinem Paket belegt? ===

:siehe [[RAM Belegung]].

=== kein Verzeichnislisting anzeigen ===

: Am elegantesten erledigt man das mit einer [[.htaccess]] Datei.
: Eine andere Möglichkeit besteht darin, einfach eine Datei index.html in das Verzeichnis zu legen. Sie kann leer sein oder einen Hinweis der Art: Diese Seite wurde absichtlich leer gelassen enthalten.

=== Wie unterscheide ich, ob ein Script per https angesprochen wurde? ===

:Weil https über einen eigenen Port läuft, ist das recht einfach. Diese php-Abfrage prüft das ab:
<syntaxhighlight lang=php>
$cfgPmaAbsoluteUri = 'http'.(($_SERVER['SERVER_PORT']==443)?'s':'').'://hostsharing.net/';
</syntaxhighlight>
:und baut entweder ein s in den String ein oder eben nichts ('').
:Das Ergebnis ist dann entweder 'http://hostsharing.net' oder 'https://hostsharing.net'.
:
:Mehr auch unter [[.htaccess]] oder ggf auch [[TLS_/_SSL|SSL]] .

=== winscp installiert, bekomme aber anstatt eines Zugriffs nur die Warnung: "Public key packet not received" ===

: Dein Programm kann nur/ist auf Protokoll Version 1.5 eingestellt. Du brauchst aber Protokoll Version 2.0.

== Datenbank ==

=== Wie bekomme ich meinen dump in die mysql-Datenbank? ===

:Du kopierst den dump auf den hs Rechner. Egal wohin!
:Dann:

<syntaxhighlight lang=shell>
mysql -u xyz00_dbuser -p xyz00_dbname < name_des_dumps
# Jetzt dein Passwort der Datenbank angeben.
</syntaxhighlight>

== Host / Server ==

=== Wie heißt auf dem Host das Kommando, welches ...? ===
=== Haben wir auf unserm Server ein Programm für ... ? ===

:Wie man sowas findet:

:Finde ein möglichst spezielles Stichwort zum Thema (vorzugsweise in englisch):
<syntaxhighlight lang=output>
1. auf unserem Server einloggen,

2. apropos stichwort eingeben,

3. für jedes interessant klingende Programm man Programmname eingeben, lesen.
</syntaxhighlight>

== Pakete allg. ==

=== Sind für Pakete auch besondere Konfigurationen zu erhalten? ===

Da die Betreuung von Sonderkonfigurationen einen erheblichen Aufwand bedeutet, versuchen wir diese Wünsche entweder in die Standardkonfiguration einzubauen oder zumindest konfigurierbar zu machen. Die Entscheidung treffen in letzter Instanz die Hostmaster.

=== Welche Parameter müssen angegeben werden, wenn über FTP auf ein Paket zugegriffen werden soll? ===

Der Zugriff ist entweder über die IP-Nummer oder dem Domainnamen (z.B. ftp.example.com) möglich. Username und Passwort wurden bei bei der Einrichtung des Paketes mitgeteilt oder selbst vergeben.

Für Windows-Nutzer:

Für die Datenübertragung immer auf Unix einstellen wenn die Option vorhanden ist (z.b. bei WS-FTP). Scripte und Konfigurationsdateien IMMER im ASCII-Modus übertragen! Sonst können sie evtl. nicht richtig verwendet werden.

Generell raten wir von FTP aus Sicherheitsgründen ab.

[[Kategorie:HSDoku]]

Simple Zonefile Howto

2024-09-13T09:31:48Z

Chg93-hsdoku: /* alle Web-Inhalte soll auf externe IP-Adresse verweisen */ DKIM

In diesem Howto werden einfachere Standardanwendungen für eigene Zonefiles behandelt. Tiefer gehende Erläuterungen finden sich in [[Verwalten der Zonendaten]].

Normalerweise wird von Hostsharing die Konfiguration der Nameserver automatisch erledigt. Das ist einer angepassten Lösung grundsätzlich vorzuziehen. Es entlastet den Anwender von der Pflicht, sein Zonefile bei technischen Änderungen zu überprüfen. Sollte dennoch ein benutzerspezifisches Zonefile erforderlich sein, so verringert der Einsatz möglichst mächtiger Platzhalter den späteren Anpassungsbedarf. In vielen Fällen genügt es, den Platzhalter für das Standardzonefile um eigene Einträge zu ergänzen.

Ist die Verwendung eines angepassten Zonefiles erforderlich, z.B. zur Realisation von DNS-Verweisen auf extern gelagerte Subdomains, der Anbindung externer Server oder der Verwendung eigener Mailserver, kann '''pro Domain''' ein eigenes Zonefile erstellt werden. Dieses befindet sich im Verzeichnis '''[[~/]]doms/example.com/etc''' und trägt den Namen '''pri.example.com''' (example.com steht hier als Beispiel für den wahren Domainnamen). Das Neuanlegen oder eine Änderung dieser Datei führt zu einer baldigen Änderung der Nameservereinträge für die Domain.

{{Textkasten|rot|Warnung!|Das nicht sachgemäße Erstellen eines eigenen Zonefiles kann zur Nichterreichbarkeit der eigenen Domain und zum Verlust von Mails führen! '''Insbesondere sei auf die Fehlerquelle gesetzter bzw. nicht gesetzter abschließender Punkte hingewiesen'''.}}

== alle Web-Inhalte soll auf externe IP-Adresse verweisen ==

Das komplette Zonefile sieht so aus:

<syntaxhighlight lang=apache line>
{HEADER}
{SOA_RR}
{NS_RR}
{MX_RR}
{SPF_RR}
{DKIM_RR}
{WILDCARD_MX_RR}
{WILDCARD_SPF_RR}
{DOM_HOSTNAME}. IN A 1.2.3.4
{DOM_HOSTNAME}. IN AAAA 1.2.3.4.....
*.{DOM_HOSTNAME}. IN A 1.2.3.4
*.{DOM_HOSTNAME}. IN AAAA 1.2.3.4.....
</syntaxhighlight>

1.2.3.4 ist durch die externe IPV4-Adresse zu ersetzten, 1.2.3.4... durch die externe IPv6-Adresse.

== Subdomain zuhause.example.com über Anbieter wie dyndns ==

Die Subdomain zuhause.example.com soll über einen Anbieter à la dyndns laufen. Das komplette Zonefile sieht so aus:

<syntaxhighlight lang=apache line>
{DEFAULT_ZONEFILE}
zuhause.{DOM_HOSTNAME}. IN CNAME example.dyndns.org.
</syntaxhighlight>

== Externer Mailserver ==

Wir wollen einen Mailserver extern betreiben, z.B. bei einem Cloud-Anbieter (Mails, Kontakte und Termine schon gecloudt?) oder im Büro. Wir übernehmen also erstmal alles, was {DEFAULT_ZONFILE} liefern würde, außer den MX Resource Records:

<syntaxhighlight lang=apache line>
{HEADER}
{SOA_RR}
{NS_RR}
{A_RR}
{AAAA_RR}
{SPF_RR}
{WILDCARD_A_RR}
{WILDCARD_AAAA_RR}
{WILDCARD_SPF_RR}
</syntaxhighlight>

Nun definieren wir den Mailserver, d.h., wir fügen diese Zeile hinzu:

<syntaxhighlight lang=apache line>
mail.{DOM_HOSTNAME}. IN MX 30 my.cloud.provider.example.com.
</syntaxhighlight>

Oder per fester IP, d.h., wir fügen alternativ diese Zeile hinzu:

<syntaxhighlight lang=apache line>
mail.{DOM_HOSTNAME}. IN A 1.2.3.4
</syntaxhighlight>

Dann legen wir die MX-Konfiguration fest, die besagt, welcher Mailserver für diese Domain zuständig ist (weitere Zeile wird hinzugefügt):

<syntaxhighlight lang=apache line>
{DOM_HOSTNAME}. IN MX 30 mail.{DOM_HOSTNAME}.
</syntaxhighlight>

Wenn wir Mails auch für Subdomains wollen, brauchen wir zusätzlich:

<syntaxhighlight lang=apache line>
*.{DOM_HOSTNAME}. IN MX 30 mail.{DOM_HOSTNAME}.
</syntaxhighlight>

;Achtung
Damit das interne {{lang|en|mailrouting}} innerhalb des Pakets für die Domain so funktioniert, daß keine lokal eingelieferten {{lang|en|e-mails}} an Mailboxen im Paket zugestellt werden, muß darauf geachtet werden, daß im Paket selber keine {{lang|en|e-mail}}-Adressen für die Domain defniert sind. Standardmäßig werden beim Einrichten einer Domain die Adressen:
<syntaxhighlight lang=output line>
abuse@...
postmaster@...
webmaster@...
</syntaxhighlight>
[https://doc.hostsharing.net/users/administration/domain/index.html Domain]. Bei der oben angeführten MX-Konfiguration müssen diese mit [https://doc.hostsharing.net/users/administration/hsadmin/index.html hsadmin] wieder gelöscht werden.

[[Kategorie:HSDoku]]
[[Kategorie:Zonefile]]
[[Kategorie:DNS]]

Goaccess

2024-07-16T09:17:56Z

Chg93-hsdoku: /* Installation */ aktuelle Version 1.9.3

Um den [[Traffic]] des Pakets beziehungweise die Einträge der [[Logging|Logdateien]] im grafischen Blick zu halten, falls das Vorgehen im gerade wenn unerwartet eine Mail mit erhöhtem Datenvolumen kommt (im terminal oder als webpage) bietet sich das tool goaccess an (https://goaccess.io/download). Es ist ein sehr schlankes tool was gerade mal 690kB im Download des tar.gz wiegt (Version 1.7)

[[Datei:Goacess.png|rahmenlos|Screenshot Goaccess]]

==Installation==

(Dieser Teil kann ausgelassen werden: Auf Managed Servern mit Debian Buster ist Goaccess Version 1.2 vorinstalliert, bei Debian Bookworm ist es Goaccess Version 1.7).

Die Installation ist erst einmal sehr einfach, daher kann es fast so installiert werden wie auf goaccess.io/download beschrieben:
eingeloggt als Paketadmin z.B. per ssh xyz00
Da wir als Paketadmin keine Programme für alle installieren kann ein lokales Directory für die Installation des Programms (und ähnlicher angelegt werden:
z.B. /home/pacs/xyz00/usr
<syntaxhighlight lang="shell">
mkdir usr
</syntaxhighlight>
um dann automatisch dorthin auch ein /bin Ordner anzulegen (wird durch configure danach gemacht)
und auch den PATH anpassen, damit Programme hier in bin direkt ausgeführt werden.
<syntaxhighlight lang="shell">
echo 'export PATH="$HOME/usr/bin:$PATH"' >>.bashrc
</syntaxhighlight>
leider wird .bashrc nicht immer gelesen wenn wir mit ssh einloggen, wir müssen es in .bash_profile festlegen:
<syntaxhighlight lang="shell">
echo '[[ -f ~/.bashrc ]] && . ~/.bashrc' >> ~/.bash_profile
</syntaxhighlight>
nun sind wir bereit für die Installation:
<syntaxhighlight lang="shell">
wget https://tar.goaccess.io/goaccess-1.9.3.tar.gz
tar -xzvf goaccess-1.9.3.tar.gz
cd goaccess-1.9.3/
</syntaxhighlight>
Eine Systemweite Installation wird mangels Berechtigung nicht funktionieren. Damit configure direkt unseren Pfad anlegt, befehlen wir das Installationsdirectory $HOME als prefix

<syntaxhighlight lang="shell">
~/goaccess-1.9.3$ ./configure --enable-utf8 --enable-geoip=legacy --prefix=$HOME/usr
~/goaccess-1.9.3$ make
~/goaccess-1.9.3# make install
</syntaxhighlight>
Nun liegt $HOME//usr/bin/goaccess in unserem PATH an erster Stelle
ein Aufruf von
<syntaxhighlight lang="shell">
goaccess --version
</syntaxhighlight>
sollte das zeigen
<syntaxhighlight lang="output" line>
GoAccess - 1.9.3.
For more details visit: https://goaccess.io/
Copyright (C) 2009-2022 by Gerardo Orellana
Build configure arguments:
--enable-utf8
--enable-geoip=legacy
</syntaxhighlight>

==Anwendung==
Dann, nach der Installation beginnt der hostsharingspezifische Teil, denn das file web.log, welches alle aktuellen logs der letzten zwei Tage beinhaltet beginnt nicht mit Datum und Uhrzeit, sondern mit den Domainnamen, was für goaccess zu Verwirrung führt.
=== Pipe mit zcat ===
Am leichtesten ist die Nutzung einer Pipe für die Prozessierung der gzip2 gezippten logfiles die alle nach dem Schema:
web-subdomain.example.com-YYYYMMDD-hhmm.log.gz im Ordner $HOME/var liegen.
Eine Auswertung des Weblogs von example.com z.B. vom 14.02.2023 liegt unter /home/pacs/xyz00/var/web-example.com-20230215-0139.log.gz vor
Die Auswertung muss also entzippt werden, das geht on-the-fly mit zcat
<syntaxhighlight lang="shell">
zcat /home/pacs/xyz00/var/web-example.com-20230215-0139.log.gz
</syntaxhighlight>
=== Wildcards ===
zcat kann sehr gut mit Wildcards umgehen, der Aufruf

<syntaxhighlight lang="shell">
zcat ~/var/web*.log.gz | goaccess -o webstat.html --log-format=COMBINED -
</syntaxhighlight>
zum Beispiel fasst alle logfiles aller Domains und aller Tage zusammen.
Es geht auch nur eine Domain: '''''"var/web-example.com*.log.gz"''''' oder nur den Januar 2023: '''''"var/web*202301*log.gz"''''' (es sollte beachtet werden, dass natürlich immer die Datei, die dann am Tag früh morgens (bei mir ist das zwischen 01:38h und 01:40h) erstellt wird natürlich für den vorherigen Tag ist. Das heißt in der 20230101 ist vor allem der 31.12. geloggt

=== Auswertung mit goaccess ===
<syntaxhighlight lang="shell">
zcat ... | goaccess -o webstat.html --log-format=COMBINED -
</syntaxhighlight>
legt eine Datei webstat.html im aktuellen Ordner ab, diese kann dann zum Beispiel heruntergeladen werden, oder in einer Domain erreichbar gemacht werden. '''Empfehlung:''' Datei per scp heruntergeladen, auf dem eigenen, geschützten Rechner angeschaut, und schnell vernichtet.
== Finetuning ==
=== Anonymisierte IPs ===
Um nur anonymisierte IPs anzeigen zu lassen kann das zusätzliche Flag --anonymize-ip verwendet werden

<syntaxhighlight lang="shell">
zcat ... | goaccess ... --anonymize-ip -
</syntaxhighlight>

In der Doku ist beschrieben wie die IP Adresse noch gröber anonymisiert werden kann.
=== Aktuellere Geo Location ===
Um die aktuellere Version der Geolocations zu verwenden muss bei

<syntaxhighlight lang="shell">
./configure ... --enable-geoip=mmdb ...
</syntaxhighlight>

statt legacy verwendet werden. Dafür gibt es eine kostenlose Länder[https://db-ip.com/db/download/ip-to-country-lite] oder Städte[https://db-ip.com/db/download/ip-to-city-lite] lite-Version unter CC BY 4.0. Falls diese nicht genau genug sind, gibt es auch kommerzielle Alternativen vom selben Anbieter.

Die Datenbank sollte im mmdb format heruntergeladen werden. Der direkte Downloadlink kann von oben direkt kopiert werden. Der Download Befehl auf der Konsole könnte bspw so aussehen (Datum und Version beachten! ggf. Link selbst einfügen). Zum heutigen Stand hatte die lite-cities Datenbank eine Größe von rund 100 MB.

<syntaxhighlight lang="shell">
wget https://download.db-ip.com/free/dbip-city-lite-2023-02.mmdb.gz
gzip -d dbip-city-lite-2023-02.mmdb.gz
</syntaxhighlight>

Beim Ausführen von goaccess muss dann auch immer angegeben werden welche IP Datenbank verwendet werden soll. Dies geht mit folgendem zusätzlichen Flag (ggf. Pfad der db anpassen)
<syntaxhighlight lang="shell">
zcat ... | goaccess ... --geoip-database=dbip-city-lite-2023-02.mmdb -
</syntaxhighlight>

=== Automatisierung pro Domain des Paketes ===

Mit dem folgenden kleinen shell script kann in einer logs.example.com (muss ersetzt werden!) Domain die statischen html files zum ansehen hinterlegt werden. Diese sollten dort nicht ohne Login ausgeliefert werden und nicht ohne https. Grundsätzlich könnte goaccess die logs auch live aufbereiten, die Komprimierung könnte dort jedoch ggf in der neusten Version ein Hindernis darstellen.

<syntaxhighlight lang="shell" line>
#inhalt generate-logs.sh
logdom=logs.example.com
for dom in $(ls $HOME/var/ | cut -c5- | rev | cut -c22- | rev | sort | uniq) # list domain names
do
echo ${dom}
zcat $HOME/var/web-$dom-*.log.gz | goaccess -o $HOME/doms/$logdom/htdocs-ssl/$dom.html --log-format=COMBINED --anonymize-ip --geoip-database=dbip-city-lite-2023-02.mmdb --ignore-crawler --unknowns-as-crawlers -
done
</syntaxhighlight>

Erklärung des scripts: Zuerst wird die logdomain auf der die Dateien abgelegt werden sollen festgelegt. Dann wird via find im Ordner /home/doms nach Dateien vom Typ Link gesucht, dessen Linkziel genauso beginnt wie das home des aktuellen users (der Paketuser). Es listet also alle domains, welche im aktuellen Paket Verwendung finden und iteriert über diese indem es die aktuelle Iteration in der Variablen dom speichert. Die nächste Zeile entfernt den Pfad vor dem Domainnamen, sodass die Variable nur noch den reinen Domainnamen beinhaltet. Der echo Befehl ist nur zur Übersicht beim manuellen ausführen und kann nach Wunsch mit # auskommentiert werden. Anschließend wird wie gewohnt (für jede Domain nacheinander) goaccess aufgerufen und für jede Domain eine eigene html Datei erzeugt. Eventuell muss der goaccess Befehl noch an die eigenen Wünsche angepasst werden.

Mit einem [[cron]] Eintrag könnte dieses Script regelmäßig aufgerufen werden. z.B.:

<syntaxhighlight lang="shell" line>
10 02 * * * sh ~/generate-logs.sh > /dev/null
</syntaxhighlight>

== Warnung: Datenschutz ==
Man beachte, dass die Auswertungen Datenschutzrelevante Inhalte wie die IP Adresse und die aufgerufenen Pfade enthalten daher kann es nicht ausreichen nur die IPs zu anonymisieren. Bei einer Nextcloud Instanz beinhalten die Pfade z.B. häufig auch den Username und somit ggf. den Klarnamen. Entsprechend sollte diese Auswertung nicht öffentlich (ohne Passwortschutz) zugänglich gemacht werden. Siehe dazu [[.htaccess#Passwortschutz_f.C3.BCr_Dateien|Passwortschutz mit htaccess]].

== Weitere WebStatistik Tools bei HS ==

* [[AWStats_installieren|AWStat]]
* [[Goaccess]]
* [[Matomo Installieren|Matomo]]

[[Kategorie:Traffic]]
[[Kategorie:WebStatistik]]

Spamfilter

2024-06-18T14:02:13Z

Chg93-hsdoku: /* Mitteilungen über aussortierte Emails erzeugen lassen */ zcat wegen gezipen Mails

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 --headers -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 ich mit Sieve-Filtern umsetzten.

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

Procmail

2024-06-13T12:07:30Z

Chg93-hsdoku: /* Links zu weiteren Procmail Beispielen und Tipps */ link leifer 404

Procmail ist ein mächtiger Filter, der für viele komplexe Aufgaben verwendet werden kann. So sind z.B. variable Weiterleitungen und das Einbinden eines Spamfilters machbar. Mehr dazu unter www.procmail.org und auf dem Server in den Manpages zu procmail, procmailrc und procmailex.

Das Standard-Mail-Zustellungsprogramm (Local Delivery Agent - LDA) bei Hostsharing ist <tt>deliver</tt> aus dem <tt>dovecot</tt>-Paket. Hier können Filter über [[Managesieve]] angelegt und z.B. über [[Roundcube - Filter|Webmail konfiguriert]] werden. Procmail sollte nur noch von fortgeschrittenen Nutzern für komplexe Filteraufgaben benutzt werden.

=== Eingehende Emails an Procmail weiterleiten ===

Zur Nutzung von procmail wird im Homedirectory des Users eine Datei .forward angelegt, die nur aus einer Zeile besteht:

"|/usr/bin/procmail"

Damit werden alle Mails an das Programm procmail übergeben und die Auslieferung kann nun über die Datei [[Managesieve#Zusammenarbeit_mit_Procmail|~/.procmailrc]] konfiguriert werden.

=== Procmail konfigurieren ===

Das nachfolgende Beispiel zeigt wie ein [[Spamfilter]] eingebunden werden kann, und Emails automatisch in IMAP-Folder (Verzeichnisse) einsortiert werden können.

==== Verzeichnisse anlegen ====

Die angesprochenen Emailverzeichnisse sollten vorher angelegt worden sein, falls sie noch nicht existieren ist dies z.B. mit dem Befehle maildirmake möglich:

maildirmake Maildir
maildirmake -f Trash Maildir
maildirmake -f Spam Maildir
maildirmake -f Hostsharing Maildir

Alternativ können die Verzeichnisse auch über die Webmail-Oberfläche anlgelegt werden. Es ist übrigens korrekt, dass die Folder beim Anlegen ohne einen führenden Punkt im Namen erstellt werden, in der .procmailrc aber mit Punkt angegeben werden.

==== .procmailrc ====

Eine beispielhafte .procmailrc:
<pre>
## Logging abstellen
COMSAT=no
LOGABSTRACT=no
VERBOSE=no
LOGFILE=procmail.log
## falls passwd die default Shell des Benutzers ist, ist die folgende Zeile wichtig:
SHELL=/bin/bash

## Spamassassin für alle Mails aufrufen...
# Hier wird der systemweite Spamassassin-Daemon benutzt.
:0fw
| /usr/bin/spamc -U /var/run/spamd
## ...und Spam in den Spam Folder aussortieren
:0
* ^X-Spam-Flag: YES
Maildir/.Spam/

## Bsp. Mailinglisten von Hostsharing in eine extra Box
#:0
#* ^TO_(support|technik|website)@hostsharing\.net
#Maildir/.Hostsharing/

# Alle nicht ausgefilterten Mails landen in der normalen Mailbox
</pre>

Möchte man die Mails mit Sieve filtern lassen, will man am Ende von .procmailrc evtl. das Programm "[[Managesieve#Zusammenarbeit_mit_Procmail|deliver]]" aufrufen lassen.

==== Abwesenheitsbenachrichtigung (vacation) ====

Zunächst im Home-Ordner eine Datei vacation.msg erstellen, deren Text als Nachricht verschickt werden soll.

Dann in die .procmailrc folgende Zeilen einfügen:
<pre>
SHELL=/bin/sh
FORMAIL=/usr/bin/formail
SENDMAIL=/usr/sbin/sendmail
:0 Whc: vacation.lock
* ^TO_myself@example.com
# Nur E-Mails, die an meine Adresse adressiert sind
* !^FROM_DAEMON
# Daemons (Mailinglisten) ausschließen
* !^X-Loop: myself@example.com
# Loop vermeiden: eigene E-Mail ausschließen
| formail -rD 8192 vacation.cache
# Adresse des Senders im Cache speichern
:0 ehc
# e: letztes recipe trifft nicht zu (Adresse noch nicht im Cache vorhanden)
| ($FORMAIL -rA "Precedence: junk" -A "X-Loop: myself@example.com" ; /bin/cat vacation.msg ) | $SENDMAIL -oi -t -f myself@example.com
</pre>

Nun wird eine E-Mail mit dem Inhalt der Datei vacation.msg und dem Absender myself@example.com an die Absender empfangener Emails geschickt. Allerdings nur, wenn die Adresse noch nicht in der vacation.cache-Datei vorhanden war. Damit wird vermieden, dass ein Absender immer wieder die Abwesenheitsnachricht erhält.

=== Links zu weiteren Procmail Beispielen und Tipps ===

http://pm-doc.sourceforge.net/doc/

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

SSH-Hostkeys

2024-04-03T14:34:02Z

Chg93-hsdoku: neuer Link

Die Hashes (Fingerprints) der Hostsharing-Server befinden sich hier:

https://www.hostsharing.net/doc/managed-operations-platform/hostkeys/

---
[[Kategorie:HSDoku]]

Domainregistrierung

2024-03-18T09:14:53Z

Chg93-hsdoku: /* Einrichten der Domain auf den HS Servern */

{{HSDoku-DomainLinks}}
__NOTOC__

=== Erst eine neue Domain über HSAdmin einrichten, dann über das Domain-Bestellsystem registrieren oder von einem anderen Provider transferieren ===

Wird eine neue Domain registriert oder von einem anderen Provider zu Hostsharing transferiert, sollte im Normalfall die Domain bei Hostsharing über HSAdmin eingerichtet werden, bevor die Registrierung letztlich eingeleitet bzw. aktualisiert wird. Sonst kann es zu Problemen beim Konnektieren der Domain kommen.

= Einrichten der Domain auf den HS Servern =

{{Kerndoku|https://www.hostsharing.net/doc/managed-operations-platform/domain/#domainverwaltung}}

Der Domainname muss im Punicode Format angelegt werden aus münster.de wird xn--mnster-3ya.de .

Bei diesem Vorgang werden die Verzeichnisse für die Domain im eigenen Paket angelegt und die Domain wird auf die Mail, Web- und Nameserver von HS [[Aufschaltung|aufgeschaltet]]. Letzteres (das Nameserver-Update) ist Voraussetzung für den nächsten Schritt.

= Domainregistrierung oder eingehender Transfer ([[KK]]) =

== Bei fremdem Provider registrierte Domain zum Transfer freischalten ==

Falls die Domain bisher bei einem anderen Provider gehostet ist, muss diesem die Transfer-Absicht mitgeteilt werden. Dafür gibt es bei den jeweiligen Providern etablierte Verfahren, die dort zu erfragen sind. Üblicherweise bekommt man dort einen AuthCode für die Domain mitgeteilt. Gibt es kein etabliertes Verfahren, so kann man wie folgt verfahren:

* Formlos per Brief/Fax den Transfer ankündigen und um Zustimmung bitten, z.B.:
<pre>
Hiermit kündige ich als Owner/Admin-C den Transfer (KK) der
Domain example.com zur Hostsharing eG, vertreten durch den Registrar
RegistryGate GmbH, an. Ich bitte, dem folgenden Transferantrag zuzustimmen.
</pre>

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

== Neuregistrierung oder Transfer zu Hostsharing ([[KK]]) ==

Die Vorgehensweise ist unter https://doc.hostsharing.net/einstieg/domain.html beschrieben.

* 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

= 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. Die Einrichtung weiterer E-Mail-Adressen ist unter https://doc.hostsharing.net/einstieg/email.html beschrieben.

[[Kategorie:HSDoku]]
[[Kategorie:Domains]]
[[Kategorie:Hsadmin]]

DKIM

2024-03-18T09:13:04Z

Chg93-hsdoku: /* Links */

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

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

Zur Veröffentlichung des Domainkey muss ein individuell angepastes Zonefile der E-Mail-Domain erweitert werden. Es müssen entweder der Platzhalter

{DEFAULT_ZONEFILE}

oder der Platzhalter

{DKIM_RR}

enthalten sein.

Ein nicht vorhandenes Zonefile im etc-Verzeichnis der Domain ist gleichbedeutend mit einem Zonefile,
das die Zeile "{DEFAULT_ZONEFILE}" als einzige Zeile enthält.

Änderungen am Zonefile aktiviert der Domain-Administrator (hier User "xyz00-doms") durch ein "touch" auf diese Datei (auch wenn die Datei nicht vorhanden ist):

xyz00-doms@h97:~$ touch doms/hs-example.de/etc/pri.hs-example.de
xyz00-doms@h97:~$

Nach einer erfolgreichen Veröffentlichung des Domainkey (ca. 3 Minuten nach dem "touch") liefert der Befehl

$ dig -t TXT +short default._domainkey.hs-example.de @dns1.hostsharing.net

("hs-example.de" durch die eigene Domain ersetzen) einen Schlüssel in der Form:

v=DKIM1; h=sha256; k=rsa; s=email; " "p=MIIBIjAN [...]"

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

== Links ==

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

DKIM

2024-03-18T09:12:13Z

Chg93-hsdoku: /* Links */

DKIM

2024-03-18T09:11:05Z

Chg93-hsdoku: /* Links */

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

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

Zur Veröffentlichung des Domainkey muss ein individuell angepastes Zonefile der E-Mail-Domain erweitert werden. Es müssen entweder der Platzhalter

{DEFAULT_ZONEFILE}

oder der Platzhalter

{DKIM_RR}

enthalten sein.

Ein nicht vorhandenes Zonefile im etc-Verzeichnis der Domain ist gleichbedeutend mit einem Zonefile,
das die Zeile "{DEFAULT_ZONEFILE}" als einzige Zeile enthält.

Änderungen am Zonefile aktiviert der Domain-Administrator (hier User "xyz00-doms") durch ein "touch" auf diese Datei (auch wenn die Datei nicht vorhanden ist):

xyz00-doms@h97:~$ touch doms/hs-example.de/etc/pri.hs-example.de
xyz00-doms@h97:~$

Nach einer erfolgreichen Veröffentlichung des Domainkey (ca. 3 Minuten nach dem "touch") liefert der Befehl

$ dig -t TXT +short default._domainkey.hs-example.de @dns1.hostsharing.net

("hs-example.de" durch die eigene Domain ersetzen) einen Schlüssel in der Form:

v=DKIM1; h=sha256; k=rsa; s=email; " "p=MIIBIjAN [...]"

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

== 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://doc.hostsharing.net/referenz/domain/domain-optionen.html Hostsharing-Dokumentation Domain-Optionen]

Verwalten der Zonendaten

2024-03-18T09:09:29Z

Chg93-hsdoku: Link Kerndoku

{{Kerndoku|https://www.hostsharing.net/doc/managed-operations-platform/zonefile/}}

Das Zonenfile für eine Domain enthält die Konfiguration des Domain Name Service ([[DNS]]), d.h. der [[Nameserver]] der Domain. Es wird hinterlegt, welche Hostnamen innerhalb der Domain existieren und auf welche IP-Adressen diese zeigen. Außerdem wird hierüber auch gesteuert, an welches System Mails für die Domain geliefert werden sollen. Für einfache und unkomplizierte Änderungen bitte in [[Simple Zonefile Howto]] schauen.

{{Textkasten|rot|Achtung|Aufgrund der zentralen Bedeutung sollten Änderungen nur mit Vorsicht vorgenommen werden, da eine fehlerhafte Einstellung dazu führen kann, dass die Webseite nicht mehr im Internet abgerufen werden kann oder Mails verloren gehen!}}

== Aktives Zonefile ==

Die gerade aktive Konfiguration einer Domain example.com ist in /etc/bind/pri.example.com zu finden ([[Zonefile]]).

Im Standardfall sieht es vollständig expandiert wie folgt aus:

<pre><nowiki>example.com. IN SOA h00.hostsharing.net. hostmaster.hostsharing.net. (
1303649373 ; serial secs since Jan 1 1970
6H ; refresh (>=10000)
1H ; retry (>=1800)
1W ; expire
1H ; minimum
)

example.com. IN NS dns1.hostsharing.net.
example.com. IN NS dns2.hostsharing.net.
example.com. IN NS dns3.hostsharing.net.

example.com. IN MX 30 mailin1.hostsharing.net.
example.com. IN MX 30 mailin2.hostsharing.net.
example.com. IN MX 30 mailin3.hostsharing.net.

example.com. IN A 83.223.95.160
example.com. IN AAAA 2a01:37:1000::53df:5fa0:0

example.com. IN TXT "v=spf1 include:spf.hostsharing.net ?all"

*.example.com. IN MX 30 mailin1.hostsharing.net.
*.example.com. IN MX 30 mailin2.hostsharing.net.
*.example.com. IN MX 30 mailin3.hostsharing.net.

*.example.com. IN A 83.223.95.160
*.example.com. IN AAAA 2a01:37:1000::53df:5fa0:0

*.example.com. IN TXT "v=spf1 include:spf.hostsharing.net ?all"
</nowiki></pre>

== Logfile und Kontrolle==

Die Logfiles des Nameservers sind im Verzeichnis /var/log/named einsehbar. Das aktuelle Log wird unter dem Namen named.log angelegt. Dieses wird beim Neustart des DNS-Servers immer neu angelegt und zeigt bei einer erfolgreichen Änderung etwa folgenden Inhalt:

Oct 11 18:32:21.400 info: zone example.org/IN: loaded serial 1065889567
Oct 11 18:32:21.435 info: zone example.org/IN: sending notifies (serial 1065889567)
Oct 11 18:32:21.755 info: client 213.133.116.2#57100: transfer of 'example.org/IN':
AXFR-style IXFR started
Oct 11 18:32:22.264 info: client 62.75.149.27#45282: transfer of 'example.org/IN':
AXFR-style IXFR started

Die Zeilen bedeuten jeweils:

* Das geänderte Zonefile wurde vom DNS-Server erfolgreich geladen
* Der lokale Server sendet eine Benachrichtigung an die Secondaries, damit diese die Änderung ebenfalls übernehmen können.

Tippfehler oder falsche Angaben im Zonefile werden hier ebenfalls gemeldet.

<pre>
-------- Original-Nachricht --------
Betreff: [Global] DNS Zonenfile Änderungen
Datum: Thu, 4 Mar 2010 08:30:34 +0100

Moin Moin,

aus gegebenem Anlass: Immer wieder kommt es vor, dass jemand sein
Zonenfile ändert, und es (scheinbar) funktioniert. Tage oder Wochen
später dann sind die Domains nicht mehr erreichbar und es heißt "in den
letzten ... Tagen/Wochen habe ich aber gar nichts mehr geändert". Das mag
auch gut sein - ist mir auch selbst schon passiert, gerade wenn es um
"mal eben schnell noch ... " ging.

Nur ist der Fehler dann aber schon vor Tagen/Wochen passiert, und solange
die Datensätze nicht abgelaufen (expired) sind, sind sie - die alten -
noch im DNS System vorhanden. Die neuen aber, die aus der o.g. Änderung,
sind bei einem Fehler im Zonenfile nie ins DNS System hinein gekommen!

Was also tun? Zunächst kann man nach einer Änderung in einer
Shell beobachten, ob es zu Fehlermeldungen kommt:

tail -f /var/log/named/named.log

oder ggf nur Zeilen, in denen die eigene Domain (z.B. example.com)
vorkommt:

tail -f /var/log/named/named.log | grep example.com

Diese Log-Datei ist daher genau aus diese Grunde auch auf dem
Server lesbar.

Auch sollte die in den DNS-Servern befindliche Seriennummer mit der
aktuellen in der Zonendatei verglichen werden:

dig -t SOA @dns1 example.com | grep '^example.com.*SOA' | awk '{ print $7 }'

grep serial /etc/bind/pri.example.com | awk '{ print $1 }'
</pre>

== Eigenes Zonenfile ==

Wer ein eigenes Zonefile installieren möchte, um diverse Anwendungsfälle zu realisieren (Verweise auf extern gelagerte Subdomains, Anbindung externer Server, Verwendung eigener Mailserver), kann '''pro Domain''' ein eigenes Zonefile erstellen. Dieses befindet sich im Verzeichnis '''~/doms/example.com/etc''' mit den Namen '''pri.example.com''' (example.com steht hier als Beispiel für den wahren Domainnamen). Ein Neuanlegen oder eine Änderung dieser Datei führt zu einer baldigen Änderung der Nameservereinträge für die Domain.

{{Textkasten|rot|Warnung!|Das nicht sachgemäße Erstellen eines eigenen Zonefiles kann zur Nichterreichbarkeit der eigenen Domain und zum Verlust von Mails führen!}}

Eine Anleitung für die eher einfachen und oft gewünschten Änderungen findet sich in [[Simple Zonefile Howto]].

Folgende Platzhalter können und sollten in eigenen Zonenfiles verwendet werden. Sie ermöglichen uns das Ändern der DNS-Konfiguration, ohne dass der Domain-Admin sein Zonefile anpassen muss.

=== Komplexe Platzhalter ===

<pre>
{DEFAULT_ZONEFILE} :=
{HEADER}
{SOA_RR}
{NS_RR}
{MX_RR}
{A_RR}
{WILDCARD_MX_RR}
{WILDCARD_A_RR}

{HEADER} :=
$TTL {TTL}

{SOA_RR} :=
{DOM_HOSTNAME}. IN SOA {SOA_HOSTNAME}. {SOA_EMAIL}. (
{SIO} ; serial secs since Jan 1 1970
{REFRESH} ; refresh (>=10000)
{RETRY} ; retry (>=1800)
{EXPIRE} ; expire
{MINIMUM} ; minimum
)

{NS_RR} :=
{DOM_HOSTNAME}. IN NS {DNS1_HOSTNAME}.
{DOM_HOSTNAME}. IN NS {DNS2_HOSTNAME}.
{DOM_HOSTNAME}. IN NS {DNS3_HOSTNAME}.

{MX_RR} :=
{DOM_HOSTNAME}. IN MX 30 {MX1_HOSTNAME}.
{DOM_HOSTNAME}. IN MX 30 {MX2_HOSTNAME}.
{DOM_HOSTNAME}. IN MX 30 {MX3_HOSTNAME}.

{A_RR} :=
{DOM_HOSTNAME}. IN A {DOM_IPNUMBER}

{WILDCARD_MX_RR} :=
*.{DOM_HOSTNAME}. IN MX 30 {MX1_HOSTNAME}.
*.{DOM_HOSTNAME}. IN MX 30 {MX2_HOSTNAME}.
*.{DOM_HOSTNAME}. IN MX 30 {MX3_HOSTNAME}.

{WILDCARD_A_RR} :=
*.{DOM_HOSTNAME}. IN A {DOM_IPNUMBER}
</pre>

=== Atomare Platzhalter ===

<pre>
{TTL} := 6H
{SOA_HOSTNAME} := <HIVE>.hostsharing.net
{SOA_EMAIL}:= hostmaster.hostsharing.net
{SIO} := <SEKUNDEN>
{REFRESH} := 6H
{RETRY} := 1H
{EXPIRE} := 1W
{MINIMUM} := 1H

{DNS1_HOSTNAME} := dns1.hostsharing.net
{DNS2_HOSTNAME} := dns2.hostsharing.net
{DNS3_HOSTNAME} := dns3.hostsharing.net

{MX1_HOSTNAME} := mailin1.hostsharing.net
{MX2_HOSTNAME} := mailin2.hostsharing.net
{MX3_HOSTNAME} := mailin3.hostsharing.net

{DOM_HOSTNAME} := <FQDN>
{DOM_IPNUMBER} := <IP>

{DKIM_RR} := <siehe https://wiki.hostsharing.net/index.php?title=DKIM>
{SPF_RR} := "v=spf1 include:spf.hostsharing.net ?all"

</pre>

Hierbei stehen
* <Sekunden> für die Anzahl der Sekunden, welche seit dem 01.01.1970 vergangen sind
* <FQDN> für den vollständigen, qualifizierten Domainnamen der Domain
* <IP> für die der Domain zugewiesene IP-Adresse

Diese Werte werden von Hostsharing verwaltet.

=== Expansion der Platzhalter ===

Der Platzhalter für das Gesamtzonefile {DEFAULT_ZONFILE} wird folgermaßen expandiert.

Zunächst werden die komplexen Platzhalter ersetzt:

<pre>
$TTL {TTL}

{DOM_HOSTNAME}. IN SOA {SOA_HOSTNAME}. {SOA_EMAIL}. (
{SIO} ; serial secs since Jan 1 1970
{REFRESH} ; refresh (>=10000)
{RETRY} ; retry (>=1800)
{EXPIRE} ; expire
{MINIMUM} ; minimum
)

{DOM_HOSTNAME}. IN NS {DNS1_HOSTNAME}.
{DOM_HOSTNAME}. IN NS {DNS2_HOSTNAME}.
{DOM_HOSTNAME}. IN NS {DNS3_HOSTNAME}.

{DOM_HOSTNAME}. IN MX 30 {MX1_HOSTNAME}.
{DOM_HOSTNAME}. IN MX 30 {MX2_HOSTNAME}.
{DOM_HOSTNAME}. IN MX 30 {MX3_HOSTNAME}.

{DOM_HOSTNAME}. IN A {DOM_IPNUMBER}

*.{DOM_HOSTNAME}. IN MX 30 {MX1_HOSTNAME}.
*.{DOM_HOSTNAME}. IN MX 30 {MX2_HOSTNAME}.
*.{DOM_HOSTNAME}. IN MX 30 {MX3_HOSTNAME}.

*.{DOM_HOSTNAME}. IN A {DOM_IPNUMBER}
</pre>

Anschließend werden die atomaren Platzhalter ersetzt:

<pre>
$TTL 6H

<FQDN>. IN SOA <HIVE>.hostsharing.net. hostmaster.hostsharing.net. (
<SEKUNDEN> ; serial secs since Jan 1 1970
6H ; refresh (>=10000)
1H ; retry (>=1800)
1W ; expire
1H ; minimum
)

<FQDN>. IN NS dns1.hostsharing.net.
<FQDN>. IN NS dns2.hostsharing.net.
<FQDN>. IN NS dns3.hostsharing.net.

<FQDN>. IN MX 30 mail1.hostsharing.net.
<FQDN>. IN MX 30 mail2.hostsharing.net.
<FQDN>. IN MX 30 mail3.hostsharing.net.

<FQDN>. IN A <IP>

*.<FQDN>. IN MX 30 mail1.hostsharing.net.
*.<FQDN>. IN MX 30 mail2.hostsharing.net.
*.<FQDN>. IN MX 30 mail3.hostsharing.net.

*.<FQDN>. IN A <IP>
</pre>

== Das Zonefile deaktivieren/zurücksetzen ==

In ~/doms/example.com/etc das vorhandene Zonefile (pri.example.com) komplett leeren (ist dann 0 Bytes groß). Dann kommt der Robot vorbei, löscht pri.example.com und setzt alles auf Standardwerte zurück.

----
[[Kategorie:HSDoku]]
[[Kategorie:Domains]]
[[Kategorie:Zonefile]]
[[Kategorie:DNS]]

Nextcloud

2023-10-23T10:21:48Z

Chg93-hsdoku: /* Nextcloud installieren */ V27.1.2

Joomla installieren

2023-06-14T13:56:09Z

Chg93-hsdoku: /* Joomla konfigurieren */

= Joomla bei HS =

== Vorbereitungen ==

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

''hsadmin''-Shell starten mit:

hsscript -u xyz00 -i
Password: ********

Dann nacheinander anlegen:

* Linux User als Domain-Administrator
* Subdomain ''joomla.hs-example.de''
* MySQL-User
* MySQL Datenbank

xyz00@hsadmin> user.add({set:{name:'xyz00-joomla',password:'geheim',shell:'/bin/bash',comment:'Joomla CMS'}})
xyz00@hsadmin> domain.add({set:{name:'joomla.hs-example.de',user:'xyz00-joomla'}})
xyz00@hsadmin> mysqluser.add({set:{name:'xyz00_joomlauser',password:'geheim'}})
xyz00@hsadmin> mysqldb.add({set:{name:'xyz00_joomladb',owner:'xyz00_joomlauser'}})

== Joomla installieren ==

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

ssh -l xyz00-joomla xyz00.hostsharing.net

Und dann Joomla herunterladen und in den Webspace entpacken:

cd doms/joomla.hs-example.de/htdocs-ssl
rm .htaccess

wget https://downloads.joomla.org/de/cms/joomla4/4-3-2/Joomla_4-3-2-Stable-Full_Package.tar.gz?format=gz
tar xvzf Joomla_4-3-2-Stable-Full_Package.tar.gz?format=gz

== Joomla für HS anpassen ==

doms/joomla.hs-example.de/fastcgi

vi php.ini

[PHP]
upload_max_filesize=20M
max_execution_time=300
post_max_size=20M
memory_limit=128M

== Joomla konfigurieren ==

Im Browser auf die Seite
https://joomla.hs-example.de/index.php gehen und den Anweisungen folgen.
(Bilder leider noch von der 3.x Version)

[[Datei:Joomla1.jpg]]
[[Datei:Joomla2.jpg]]
[[Datei:Joomla3a.jpg]]
[[Datei:Joomla3b.jpg]]
[[Datei:Joomla4.jpg]]

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

Joomla installieren

2023-06-14T13:52:07Z

Chg93-hsdoku: /* Joomla installieren */ 4.3.2 Bilder nicht aktualisert

= Joomla bei HS =

== Vorbereitungen ==

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

''hsadmin''-Shell starten mit:

hsscript -u xyz00 -i
Password: ********

Dann nacheinander anlegen:

* Linux User als Domain-Administrator
* Subdomain ''joomla.hs-example.de''
* MySQL-User
* MySQL Datenbank

xyz00@hsadmin> user.add({set:{name:'xyz00-joomla',password:'geheim',shell:'/bin/bash',comment:'Joomla CMS'}})
xyz00@hsadmin> domain.add({set:{name:'joomla.hs-example.de',user:'xyz00-joomla'}})
xyz00@hsadmin> mysqluser.add({set:{name:'xyz00_joomlauser',password:'geheim'}})
xyz00@hsadmin> mysqldb.add({set:{name:'xyz00_joomladb',owner:'xyz00_joomlauser'}})

== Joomla installieren ==

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

ssh -l xyz00-joomla xyz00.hostsharing.net

Und dann Joomla herunterladen und in den Webspace entpacken:

cd doms/joomla.hs-example.de/htdocs-ssl
rm .htaccess

wget https://downloads.joomla.org/de/cms/joomla4/4-3-2/Joomla_4-3-2-Stable-Full_Package.tar.gz?format=gz
tar xvzf Joomla_4-3-2-Stable-Full_Package.tar.gz?format=gz

== Joomla für HS anpassen ==

doms/joomla.hs-example.de/fastcgi

vi php.ini

[PHP]
upload_max_filesize=20M
max_execution_time=300
post_max_size=20M
memory_limit=128M

== Joomla konfigurieren ==

Im Browser auf die Seite
https://joomla.hs-example.de/index.php gehen und den Anweisungen folgen.

[[Datei:Joomla1.jpg]]
[[Datei:Joomla2.jpg]]
[[Datei:Joomla3a.jpg]]
[[Datei:Joomla3b.jpg]]
[[Datei:Joomla4.jpg]]

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

Collabora Online

2023-05-11T12:25:17Z

Chg93-hsdoku: /* Collabora konfigurieren */

= Collabora installieren =

== Vorbereitungen ==

Voraussetzungen sind folgende Punkte:

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

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

3. Die APP ''Nextcloud Office'' erst installieren wenn der Service die Bestätigung gesendet hat, dass die Aktivierung erfolgt ist.

== Collabora installieren ==

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

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

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

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

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

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

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

== Collabora konfigurieren ==

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

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

[[Bild:Nextcloud-Office-Menue.png]]

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

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

$ dig xyz00.hostsharing.net

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

;; ANSWER SECTION:
xyz00.hostsharing.net. 3807 IN A 83.223.79.177

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

Weitere Einstellungen können individuell noch vorgenommen werden.

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

Collabora Online

2023-05-11T12:24:13Z

Chg93-hsdoku: /* Collabora installieren */ Neues Bild Suche

= Collabora installieren =

== Vorbereitungen ==

Voraussetzungen sind folgende Punkte:

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

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

3. Die APP ''Nextcloud Office'' erst installieren wenn der Service die Bestätigung gesendet hat, dass die Aktivierung erfolgt ist.

== Collabora installieren ==

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

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

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

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

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

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

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

== Collabora konfigurieren ==

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

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

[[Bild:Hs-collabora-config.jpg]]

Hier muss nun die PaketDomain entsprechend Eingetragen werden.
Wobei '''xyz00'''.hostsharing.net durch Ihr Paket Kürzel zu ersetzten ist.
Es wird kein Port eingetragen!
Anschließend einmal auf den Button ''Anwenden'' klicken.
[[Bild:Hs-collabora-pacdomain.jpg]]

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

$ dig xyz00.hostsharing.net

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

;; ANSWER SECTION:
xyz00.hostsharing.net. 3807 IN A 83.223.79.177

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

Weitere Einstellungen können individuell noch vorgenommen werden.

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

Datei:Nextcloud-Office-URL.png

2023-05-11T12:22:26Z

Chg93-hsdoku:

Datei:Nextcloud-Office-Menue.png

2023-05-11T12:22:12Z

Chg93-hsdoku:

Datei:Nextcloud-Office-Suche.png

2023-05-11T12:21:39Z

Chg93-hsdoku:

Collabora Online

2023-05-11T12:03:44Z

Chg93-hsdoku: /* Collabora installieren */ Nextcloud Office

= Collabora installieren =

== Vorbereitungen ==

Voraussetzungen sind folgende Punkte:

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

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

3. Die APP ''Nextcloud Office'' erst installieren wenn der Service die Bestätigung gesendet hat, dass die Aktivierung erfolgt ist.

== Collabora installieren ==

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

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

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

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

3. Im '''Suchfeld''' oben "collabora" eingeben
[[Datei:Hs-collabora-suche.jpg]]

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

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

== Collabora konfigurieren ==

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

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

[[Bild:Hs-collabora-config.jpg]]

Hier muss nun die PaketDomain entsprechend Eingetragen werden.
Wobei '''xyz00'''.hostsharing.net durch Ihr Paket Kürzel zu ersetzten ist.
Es wird kein Port eingetragen!
Anschließend einmal auf den Button ''Anwenden'' klicken.
[[Bild:Hs-collabora-pacdomain.jpg]]

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

$ dig xyz00.hostsharing.net

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

;; ANSWER SECTION:
xyz00.hostsharing.net. 3807 IN A 83.223.79.177

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

Weitere Einstellungen können individuell noch vorgenommen werden.

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

Collabora Online

2023-05-11T12:03:05Z

Chg93-hsdoku: /* Vorbereitungen */

= Collabora installieren =

== Vorbereitungen ==

Voraussetzungen sind folgende Punkte:

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

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

3. Die APP ''Nextcloud Office'' erst installieren wenn der Service die Bestätigung gesendet hat, dass die Aktivierung erfolgt ist.

== Collabora installieren ==

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

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

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

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

3. Im '''Suchfeld''' oben "collabora" eingeben
[[Datei:Hs-collabora-suche.jpg]]

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

Damit ist die APP Collabora Online installiert und muss nun noch konfiguriert werden.

== Collabora konfigurieren ==

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

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

[[Bild:Hs-collabora-config.jpg]]

Hier muss nun die PaketDomain entsprechend Eingetragen werden.
Wobei '''xyz00'''.hostsharing.net durch Ihr Paket Kürzel zu ersetzten ist.
Es wird kein Port eingetragen!
Anschließend einmal auf den Button ''Anwenden'' klicken.
[[Bild:Hs-collabora-pacdomain.jpg]]

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

$ dig xyz00.hostsharing.net

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

;; ANSWER SECTION:
xyz00.hostsharing.net. 3807 IN A 83.223.79.177

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

Weitere Einstellungen können individuell noch vorgenommen werden.

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

Redis

2023-02-16T15:58:04Z

Chg93-hsdoku: /* Konfiguration */ daemonize yes/no, absolute Pfade

== Redis installieren ==

'''Redis''' ist ein einfacher Datenspeicher für Schlüssel-Wert-Paare. Datensätze werden jeweils unter einem Schlüssel abgelegt. Die Daten werden jeweils im Hauptspeicher gehalten und nur zu konfigurierbaren Zeitpunkten auf die Festplatte gesichert.

Redis-Datenbanken werden häufig zur Speicherung von Warteschlangen benutzt. In Redis werden Aufträge gespeichert, die asynchron von Hintergrundprogrammen abgearbeitet werden.

=== Konfiguration ===

Redis ist auf den Hostsharing-Servern vorinstalliert. Für die Nutzung muss lediglich eine Konfigurationsdatei angelegt werden und ein Hitergrundprogramm gestartet werden.

Im folgenden wird für den User ''xyz00-service'' ein Redis-Dienst eingerichtet.
Der User ''xyz00-service'' ist in HSAdmin mit ''/bin/bash'' als Shell eingerichtet.

Nach dem Login als ''xyz00-service'' lege ich Verzeichnisse ''~/redis/etc'' und ''~/redis/var'' an:

xyz00-service@h00:~$ mkdir redis
xyz00-service@h00:~$ mkdir redis/etc
xyz00-service@h00:~$ mkdir redis/var

Im etc-Verzeichnis wird die Konfigurationsdatei ''redis.conf'' für den Redis-Dienst abgelegt.

Eine Beispiel-Konfiguration ist:

daemonize yes
pidfile /home/pacs/XYZ00/users/NAME/redis/var/redis-server.pid
requirepass 'generiertes-passwort'
bind 127.0.0.1
port 33033
tcp-backlog 128
timeout 300
loglevel notice
logfile /home/pacs/XYZ00/users/NAME/redis/var/redis.log
databases 16
save 900 1
save 300 10
save 60 10000
slave-serve-stale-data yes
appendonly no
dbfilename dump.rdb
dir /home/pacs/XYZ00/users/NAME/redis/var

Der Redis-Dienst ist über die Server-lokale Netzwerk-Adresse 127.0.0.1 erreichbar und mit einem Passwort geschützt. Der Port ''33033'' für die Netzwerk-Schnittstelle muss ggf. angepasst werden.

Der Dienst wird gestartet mit:

xyz00-service@h00:~/redis$ /usr/bin/redis-server etc/redis.conf

Mit Ctrl-C kann der Dienst wieder gestoppt werden.

Alternativ kann der zugriff auf Redis über einen Unixsocket erfolgen. Dann entfällt die Zeile 'bind 127.0.0.1' in der Konfiguration, der port wird auf 0 gesetzt. Stattdessen wir ein Unixsocket konfiguriert:

unixsocket var/redis-server.sock
unixsocketperm 700
port 0
daemonize no

=== Einrichtung als Server-Dienst ===

'''Redis''' soll über den Systemdienst '''SystemD''' automatisch im Hintergrund gestartet werden.

Dazu wird im Verzeichnis ''~/.config/systemd/user'' eine Datei ''redis.service'' mit dem folgenden Inhalt angelegt:

[Unit]
Description=Redis Service

[Service]
WorkingDirectory=%h/redis
Environment="PATH=/usr/local/bin:/usr/bin:/bin"
ExecStart=/usr/bin/redis-server %h/redis/etc/redis.conf
Restart=always
PrivateTmp=true
NoNewPrivileges=true

[Install]
WantedBy=default.target

Die Datei wird mit den folgenden Shell-Kommandos geladen und aktiviert:

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

Mit den Kommandos

systemctl --user status
systemctl --user status redis.service

kann der Status des Dienstes ermittelt werden.

=== Links ===

* [https://redis.io/ Internetseite des Redis Projekts]

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

Mastodon bei Hostsharing

2022-11-21T11:50:50Z

Chg93-hsdoku: /* Starten der Dienste */ mastodon -> live

Mastodon ist ein verteilter Microblogging Dienst, der das ActivityPub-Protokoll verwendet.

Wenn man nur wenige Nutzer oder gar nur für sich selbst einen Einstiegspunkt ins "Fediverse" schaffen will, kann sich auch die Ressourcen-schonende Alternative [[Pleroma]] anbieten.

Diese Anleitung beschreibt, wie man Mastodon auf der Managed Hosting Plattform von Hostsharing installieren kann.

Hostsharing selbst nutzt die Hosting Plattform und betreibt zwei Mastodon Instanzen:
* https://geno.social
* https://hostsharing.coop

Der Autor dieser Seite betreibt:
* https://krefeld.life

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

== Vorbereitungen ==

Mit Hilfe von HSAdmin wird angelegt:
# Ein User als Service-User mit ''/bin/bash'' als Shell, zum Beispiel Beispiel: ''xyz00-mastodon''
# Eine Domain mit ''xyz00-mastodon'' als Domain-Administrator, zum Beispiel ''beispiel.social''
# Einen Postgresql-User ''xyz00_mastuser'' mit Passwort ''meinPasswort''
# Eine Postgresql-Datenbank ''xyz00_mastdb'' mit Datenbank-Owner ''xyz00_mastuser''

Verwendete IP-Ports der Server-Dienste:
# Monit: localhost:32001
# Redis: localhost:32002
# Mastodon-Web: localhost:32003
# Mastodon-Streaming: localhost:32004

== Konfiguration des Redis Server ==

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

daemonize yes
pidfile /home/pacs/xyz00/users/mastodon/redis/var/redis-server.pid
requirepass <hierhin-gehoert-ein-redis-passwort>
port 32002
tcp-backlog 128
bind 127.0.0.1
timeout 300
loglevel notice
logfile /home/pacs/xyz00/users/mastodon/redis/var/redis.log
databases 16
save 900 1
save 300 10
save 60 10000
slave-serve-stale-data yes
appendonly no
dbfilename dump.rdb
dir /home/pacs/xyz00/users/mastodon/redis/var

== Installation von NodeJS ==

Als User 'xyz00-mastodon'': Installation von ''nvm'' und ''nodejs'' (Version 12) nach der Anleitung [[NodeJS]]

Installation von ''yarn'' mit:

npm install -g yarn

== Installation von Ruby ==

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

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

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

starte neue Shell:

exec bash

Überprüfe rbenv-Installation

type rbenv

Installiere ruby-build als rbenv-Plugin

git clone https://github.com/rbenv/ruby-build.git ~/.rbenv/plugins/ruby-build

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

rbenv install 2.7.2

== Installation der Mastodon Software ==

Weiterhin Als User ''xyz00-mastodon'':

cd ~
git clone https://github.com/tootsuite/mastodon.git live
cd ~/live

Die stabile Version auschecken:

git checkout $(git tag -l | grep -v 'rc[0-9]*$' | sort -V | tail -n 1)

Ruby Pakete installieren:

gem install bundler
bundle install -j$(getconf _NPROCESSORS_ONLN) --deployment --without development test

Node.js Pakete installieren:

yarn install --pure-lockfile

== Konfiguration der Mastodon Software ==

Anlegen einer Datei ''/home/pacs/xyz00/users/mastodon/live/.env.production'' mit dem folgenden Inhalt:

REDIS_HOST=localhost
REDIS_PORT=32002
REDIS_PASSWORD=<hierhin-gehoert-ein-redis-passwort>
DB_HOST=localhost
DB_USER=xyz00_mastuser
DB_NAME=xyz00_mastdb
DB_PASS=meinPasswort
DB_PORT=5432
LOCAL_DOMAIN=beispiel.social
SECRET_KEY_BASE=12ab..
OTP_SECRET=34ef..
VAPID_PRIVATE_KEY=ABCD..
VAPID_PUBLIC_KEY=EFGH..
DEFAULT_LOCALE=de
SMTP_SERVER=localhost
SMTP_PORT=25
SMTP_FROM_ADDRESS=notifications@beispiel.social
SMTP_AUTH_METHOD=none
SMTP_OPENSSL_VERIFY_MODE=none
STREAMING_CLUSTER_NUM=1

Die Zufallswerte für die Variablen SECRET_KEY_BASE und OTP_SECRET erzeugt man durch zwei Aufrufe des Kommandos

RAILS_ENV=production bundle exec rake secret

Die Werte für VAPID_PRIVATE_KEY und VAPID_PUBLIC_KEY erzeugt das Kommando

RAILS_ENV=production bundle exec rake mastodon:webpush:generate_vapid_key

Initialisieren der Datenbank:

export SAFETY_ASSURED=1
RAILS_ENV=production bundle exec rails db:schema:load
RAILS_ENV=production bundle exec rails db:seed

Erzeugen der Web-Resourcen

RAILS_ENV=production bundle exec rails assets:precompile

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

set daemon 60
with start delay 120
set logfile /home/pacs/xyz00/users/mastodon/monit/var/monit.log
set idfile /home/pacs/xyz00/users/mastodon/monit/var/monit.id
set statefile /home/pacs/xyz00/users/mastodon/monit/var/monit.state
set mailserver localhost
set mail-format { from: monit@beispiel.social }
set alert mastodon@beispiel.social
set httpd port 32001 address xyz00.hostsharing.net
allow mostodon:monitpassword
check process redis with pidfile /home/pacs/xyz00/users/mastodon/redis/var/redis-server.pid
start program "/usr/bin/redis-server /home/pacs/xyz00/users/mastodon/redis/etc/redis.conf"
stop program "/bin/bash -c '/bin/kill $( cat /home/pacs/xyz00/users/mastodon/redis/var/redis-server.pid )'"
check process mstdn_web with pidfile /home/pacs/xyz00/users/mastodon/live/var/puma.pid
depends redis
start program "/bin/bash -c 'export RAILS_ENV=production && export HOME=/home/pacs/xyz00/users/mastodon && cd $HOME/live && ( $HOME/.rbenv/shims/bundle exec puma -C config/puma.rb -e production -b tcp://127.0.0.1:32003 >$HOME/live/var/puma.log 2>&1 & echo $! > $HOME/live/var/puma.pid )'"
stop program "/bin/bash -c '/bin/kill $( cat /home/pacs/xyz00/users/mastodon/live/var/puma.pid )'"
check process mstdn_sidekiq with pidfile /home/pacs/xyz00/users/mastodon/live/var/sidekiq.pid
depends redis
start program "/bin/bash -c 'export RAILS_ENV=production && export DB_POOL=5 && export HOME=/home/pacs/xyz00/users/mastodon && cd $HOME/live && ( $HOME/.rbenv/shims/bundle exec sidekiq -c 5 -q default -q mailers -q pull -q push -q scheduler >$HOME/live/var/sidekiq.log 2>&1 & echo $! > $HOME/live/var/sidekiq.pid )'"
stop program "/bin/bash -c '/bin/kill $( cat /home/pacs/xyz00/users/mastodon/live/var/sidekiq.pid )'"
check process mstdn_streaming with pidfile /home/pacs/xyz00/users/mastodon/live/var/streaming.pid
depends redis
start program "/bin/bash -c 'export HOME=/home/pacs/xyz00/users/mastodon && export NVM_DIR="$HOME/.nvm" && export NVM_BIN=/home/pacs/xyz00/users/mastodon/.nvm/versions/node/v12.22.1/bin && export NODE_ENV=production && export PORT=32004 && export BIND=127.0.0.1 && cd $HOME/live && ( $HOME/.nvm/versions/node/v12.22.1/bin/node streaming/index.js >$HOME/live/var/streaming.log 2>&1 & echo $! > $HOME/live/var/streaming.pid )'"
stop program "/bin/bash -c '/bin/kill $( cat /home/pacs/xyz00/users/mastodon/live/var/streaming.pid )'"

== Einrichten des Apache VHost ==

cd ~/doms/beispiel.social
rm -rf htdocs-ssl subs/www subs-ssl/www
ln -s ~/live/public htdocs-ssl
touch htdocs-ssl/.htaccess

Dann die ''htdocs-ssl/.htaccess'' mit dem Editor der Wahl öffnen und
folgende Konfiguration einfügen:

DirectoryIndex disabled
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_URI} ^/api/v1/streaming [NC]
RewriteRule .* ws://localhost:32004%{REQUEST_URI} [proxy]
RequestHeader set X-Forwarded-Proto "https"
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule .* http://localhost:32003%{REQUEST_URI} [proxy]
RequestHeader set X-Forwarded-Proto "https"

== Cronjobs ==

''Cron'' wird für zwei Aufgaben genutzt:
* Start von monit nach einem Server Reboot
* Aufräumen von alten Resourcen

Einrichten der crontab mit ''cronttab -e''

HOME=/home/pacs/xyz00/users/mastodon
MAILTO=mastodon@beispiel.social
RAILS_ENV=production
NUM_DAYS=31

@reboot /usr/bin/monit -c $HOME/.monitrc
18 4 * * * cd $HOME/live && $HOME/live/bin/tootctl media remove

== Volltextsuche ==

In der installierten Version gibt es noch keine Volltextsuche. Es kann lediglich nach Nutzerkennungen und Hastags gesucht werden. Für die Volltextsuche kann optional Elasticsearch installiert werden.

* [[Elasticsearch]] bei Hostsharing
* https://docs.joinmastodon.org/admin/optional/elasticsearch/

== Instanz einrichten ==
Nach der Installation kann man sich auf https://beispiel.social einen Benutzer einrichten.

Auf der Kommandozeile:

RAILS_ENV=production bin/tootctl accounts create \
alice \
--email alice@example.com \
--confirmed \
--role admin

Weitere Einrichtung sollte vorgenommen werden, z.B. eine Beschreibung der Instanz hinterlegen, siehe https://docs.joinmastodon.org/admin/setup/

== Mastodon Updates ==

siehe:
* https://github.com/tootsuite/mastodon/releases

(hier für das Update auf die Mastodon Version v2.8.0 mit Ruby 2.6.1)

=== Ruby ===

cd ~/.rbenv
git pull
cd ~/.rbenv/plugins/ruby-build
git pull
cd
rbenv install -l
rbenv install 2.6.1
rbenv global 2.6.1

=== Mastodon ===

cd ~/mastodon/live
git fetch
git checkout v2.8.0
gem update --system
bundle install
yarn install
RAILS_ENV=production bundle exec rails db:migrate
RAILS_ENV=production bundle exec rails assets:precompile

Restart Mastodon!

== Links ==

* [https://joinmastodon.org/ Offizielle Webseite von Mastodon]
* im Archiv: https://github.com/mastodon/documentation/blob/archive/Running-Mastodon/Production-guide.md
* aktuell: https://docs.joinmastodon.org/admin/install/
* https://krinetzki.de/2017/04/installation-von-mastodon-auf-debian-8-jessie/
* [https://github.com/tpokorra/Hostsharing-Ansible-Mastodon Ansible Playbook für Hostsharing]

[[Kategorie:Installationsanleitungen]]
[[Kategorie:Fediverse]]
[[Kategorie:Activitypub]]
[[Kategorie:Ansible Playbook]]

PHP

2022-11-08T16:32:47Z

Chg93-hsdoku: /* phpstub für PHP 8.1 aktivieren */

PHP wird heute bei HS standardmäßig per FastCGI vorkonfiguriert. Dafür wird in jedem Domainverzeichnis unter fastcgi/ eine phpstub Datei angelegt und der Apache Webserver ist konfiguriert .php Dateien über diesen "Stub" mit den Rechten des Users auszuführen.

Zur Wiederherstellung des originalen phpstub ist dieser zentral abgelegt als

/usr/local/src/phpstub

Anwender, die lediglich PHP-Dateien hochgeladen haben, brauchen ausdrücklich keine eigene php.ini.

=== Anpassung der PHP Grundkonfiguration ===

Um die PHP Konfiguration an eigene Bedürfnisse anzupassen, legt man eine Konfigurationsdatei namens php.ini im fastcgi Verzeichnis der Domain an (für https:// entsprechend im -ssl Verzeichnis) z.B.: /home/pacs/xyz00/users/meinbenutzer/doms/meinedomain.de/fastcgi-ssl/php.ini. In dieser Datei müssen nicht alle Konfigurationsoptionen von PHP definiert sein, sondern nur die, die sich gegenüber der Standard php.ini ändern sollen. Diese liegt in /etc/php/VERSION/cgi und kann dort eingesehen werden.

'''Achtung:''' Kommentare nicht mit # einleiten (kann zu unerwarteten Fehlkonfigurationen führen), Kommentarzeichen ist das Semikolon ";".

Häufig anzupassen sind z.B.:

* die Content-Type charset= Vorgabe für den HTTP Header.

* der maximal verwendbare Hauptspeicher (memory_limit).

* die maximale Größe hochgeladener Dateien (post_max_size).

* die aktiven Extensions.

Beispiel einer php.ini:

<pre>
------8< SCHNIPP >8------
[..]
memory_limit = 128M (default)
post_max_size = 8M (default)
upload_max_filesize = 2M (default)
display_errors = Off (default)
log_errors = Off (default)
error_log = /home/pacs/xyz00/users/meinbenutzer/doms/meinedomain.de/fastcgi-ssl/php_errors.log

[..]
default_charset = "UTF-8"
; (ist sonst iso-8859-1)
; Der charset kann aber wiederum durch einen Funktionsaufruf
; header("Content-Type: text/html; charset=iso-8859-1")
; im PHP-Skript überschrieben werden (sofern output_buffering = On).
------8< SCHNIPP >8------
</pre>

'''Beachte:''' Eine geänderte php.ini Konfiguration wird mit FastCGI erst übernommen, wenn die PHP Prozesse des Users (die über längere Zeit laufen bleiben) neu gestartet werden.

Die Brechstange, mit der das Neustarten der PHP Prozesse erzwungen werden kann, ist diese zu killen:
<pre>
killall -u $USER -r php
</pre>
$USER = ist der aktuell angemeldeten Benutzer und muss nicht durch den Benutzernamen (xyz00 oder xyz00-user) ersetzt werden. Nur die Prozesse des angemeldeten Users $USER werden gelöscht. "-r" bewirkt, dass der Ausdruck "php" als regulärer Ausdruck interpretiert wird. Intern heißen die sichtbaren Prozesse nicht "php" sondern beispielsweise "php7.2"

=== PHP Sicherheit ===

==== open_basedir ====

Sofern der PHP Parameter open_basdir nicht gesetzt ist (Vorgabe) können (kompromittierte) php Skripte an alle Dateien des Users kommen, ohne einen extra Shellzugang installieren zu müssen und dadurch entdeckt zu werden.

Die Passwortabfrage von Hsadmin bringt eine Abhilfe für die zentralen Dienste. (Sofern Du dein Passwort nicht in eine Datei schreibst und die Abfrage so wieder ausschaltest, wovon besser abzusehen ist.) Doch alle Daten auf die Du als Benutzer zugreifen kannst sind prinzipiell den PHP-Skripten ausgeliefert.

Mit open_basedir wird festgelegt in welchen Verzeichnissen PHP Skripte lesen und schreiben dürfen. Geprüft wird dabei ob der zu öffnende Pfad mit dem angegebene Pfad beginnt. Es ist daher wichtig ob sich am Ende ein "/" befindet oder nicht. Ein open_basedir von /home/doms/example.org/subs/www (ohne /) erlaubt somit z.B. auch Zugriffe auf die Subdomain www2 etc.

Beispielzeile für die php.ini:
open_basedir = /home/doms/example.org/subs/

Wenn man mehrere Subdomains hat und diese isolieren möchte, ist dies durch Aufschaltung von lokalen Subdomains auf verschiedene User möglich. (Siehe https://doc.hostsharing.net/users/administration/domain/index.html )

==== Sicherheitskritische Funktionen ====

Weitere Dinge die deaktiviert werden sollten, wenn sie nicht benötigt werden, was im allgemeinen der Fall ist, sind: Das öffnen von URLs als Dateien,

allow_url_fopen = Off

und die Ausführung von Systembefehlen.

disable_functions = show_source, system, passthru, shell_exec, exec, phpinfo, popen, proc_open

=== eigene PHP Konfigurationen und verschiedene nebeneinander verwenden ===

Um verschiedene PHP Konfigurationen nebeneinander zu verwenden, kopierst Du den phpstub in ein Unterzeichnis von (fast)cgi(-ssl) und mappst (Einträge in der .htaccess) nach Belieben deine PHP Dateien darauf.
So können beliebig viele Konfigurationen bei einer Domain nebeneinander genutzt werden.

==== Beispiel muster.example.com ====
<pre>
mkdir ~/doms/example.com/fastcgi/muster
cp ~/doms/example.com/fastcgi/phpstub ~/doms/example.com/fastcgi/muster/phpstub

und wenn benötigt:
vi ~/doms/example.com/fastcgi/muster/php.ini
</pre>

Anschließend muss der Apache Webserver noch angewiesen werden auch diese bestimmte Konfiguration von PHP zu verwenden. Dazu werden der [[.htaccess]] Datei im DocumentRoot der Sub-Domain zwei Zeilen hinzugefügt bzw. eine .htaccess mit den zwei Zeilen angelegt.
Im Beispiel handelt es sich um die Domain muster.example.com, also:

<pre>
cd ~/doms/example.com/subs/muster
vi .htaccess

AddType application/x-httpd-phpfastcgi .php
Action application/x-httpd-phpfastcgi /fastcgi-bin/muster/phpstub
</pre>

== Vorinstallierte PHP Version wechseln ==
Hostsharing bietet neben der aktuellen Standardversion 7.4 auch PHP 7.0, 7.1, 7.2, 7.3 und 8.0, 8.1 an.

Um die Version zu wechseln, genügt es, den jeweiligen phpstub auszutauschen. Version 7.3 liegt unter <code>/usr/local/src/phpstub/phpstub73</code>; das Versionformat ist entsprechend <code>/usr/local/src/phpstub/phpstubXX</code>.

===phpstub für PHP 8.0 kopieren===

<pre>
$ cp /usr/local/src/phpstub/phpstub80 ~/doms/example.com/fastcgi/
$ cp /usr/local/src/phpstub/phpstub80 ~/doms/example.com/fastcgi-ssl/
</pre>

===phpstub für PHP 8.0 aktivieren===

Die .htaccess sollte möglichst zentral im Verzeichnisbaum abgelegt werden:
~/doms/example.com/.htaccess
Damit durch Anwendungs eigene .htaccess Dateien (Wordpress, Nextcloud etc.) nicht unbeabsichtigt die php Einstellungen verloren gehen.
In der zentralen <code>.htaccess</code> eines Ordners genügt es, die PHP Dateizuordnung zu überschreiben:

<pre>
AddType application/x-httpd-php80 .php
Action application/x-httpd-php80 /fastcgi-bin/phpstub80
</pre>

Damit wird für den aktuellen Ordner und alle Unterordner PHP 8.0 verwendet.

Auf die gleiche Weise können auch PHP 7.1, PHP 7.2 ,PHP 7.3 oder PHP 8.1 aktiviert werden.

== Eigene PHP Version ==
Es kann auch eine eigene PHP Version im Paket installiert werden.
Eine kurz Anleitung ist unter [[Eigene_PHP_Version]] beschrieben.

== Eigener PHP FPM Prozess ==

auf einem Managed Server kann jeder Nutzer nach belieben auch php-fpm als eigenen Prozess starten.
Ein paar Notizen dazu finden sich auf der Seite [[PHP_FPM]].

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

PHP

2022-11-08T16:31:46Z

Chg93-hsdoku: /* Vorinstallierte PHP Version wechseln */

PHP wird heute bei HS standardmäßig per FastCGI vorkonfiguriert. Dafür wird in jedem Domainverzeichnis unter fastcgi/ eine phpstub Datei angelegt und der Apache Webserver ist konfiguriert .php Dateien über diesen "Stub" mit den Rechten des Users auszuführen.

Zur Wiederherstellung des originalen phpstub ist dieser zentral abgelegt als

/usr/local/src/phpstub

Anwender, die lediglich PHP-Dateien hochgeladen haben, brauchen ausdrücklich keine eigene php.ini.

=== Anpassung der PHP Grundkonfiguration ===

Um die PHP Konfiguration an eigene Bedürfnisse anzupassen, legt man eine Konfigurationsdatei namens php.ini im fastcgi Verzeichnis der Domain an (für https:// entsprechend im -ssl Verzeichnis) z.B.: /home/pacs/xyz00/users/meinbenutzer/doms/meinedomain.de/fastcgi-ssl/php.ini. In dieser Datei müssen nicht alle Konfigurationsoptionen von PHP definiert sein, sondern nur die, die sich gegenüber der Standard php.ini ändern sollen. Diese liegt in /etc/php/VERSION/cgi und kann dort eingesehen werden.

'''Achtung:''' Kommentare nicht mit # einleiten (kann zu unerwarteten Fehlkonfigurationen führen), Kommentarzeichen ist das Semikolon ";".

Häufig anzupassen sind z.B.:

* die Content-Type charset= Vorgabe für den HTTP Header.

* der maximal verwendbare Hauptspeicher (memory_limit).

* die maximale Größe hochgeladener Dateien (post_max_size).

* die aktiven Extensions.

Beispiel einer php.ini:

<pre>
------8< SCHNIPP >8------
[..]
memory_limit = 128M (default)
post_max_size = 8M (default)
upload_max_filesize = 2M (default)
display_errors = Off (default)
log_errors = Off (default)
error_log = /home/pacs/xyz00/users/meinbenutzer/doms/meinedomain.de/fastcgi-ssl/php_errors.log

[..]
default_charset = "UTF-8"
; (ist sonst iso-8859-1)
; Der charset kann aber wiederum durch einen Funktionsaufruf
; header("Content-Type: text/html; charset=iso-8859-1")
; im PHP-Skript überschrieben werden (sofern output_buffering = On).
------8< SCHNIPP >8------
</pre>

'''Beachte:''' Eine geänderte php.ini Konfiguration wird mit FastCGI erst übernommen, wenn die PHP Prozesse des Users (die über längere Zeit laufen bleiben) neu gestartet werden.

Die Brechstange, mit der das Neustarten der PHP Prozesse erzwungen werden kann, ist diese zu killen:
<pre>
killall -u $USER -r php
</pre>
$USER = ist der aktuell angemeldeten Benutzer und muss nicht durch den Benutzernamen (xyz00 oder xyz00-user) ersetzt werden. Nur die Prozesse des angemeldeten Users $USER werden gelöscht. "-r" bewirkt, dass der Ausdruck "php" als regulärer Ausdruck interpretiert wird. Intern heißen die sichtbaren Prozesse nicht "php" sondern beispielsweise "php7.2"

=== PHP Sicherheit ===

==== open_basedir ====

Sofern der PHP Parameter open_basdir nicht gesetzt ist (Vorgabe) können (kompromittierte) php Skripte an alle Dateien des Users kommen, ohne einen extra Shellzugang installieren zu müssen und dadurch entdeckt zu werden.

Die Passwortabfrage von Hsadmin bringt eine Abhilfe für die zentralen Dienste. (Sofern Du dein Passwort nicht in eine Datei schreibst und die Abfrage so wieder ausschaltest, wovon besser abzusehen ist.) Doch alle Daten auf die Du als Benutzer zugreifen kannst sind prinzipiell den PHP-Skripten ausgeliefert.

Mit open_basedir wird festgelegt in welchen Verzeichnissen PHP Skripte lesen und schreiben dürfen. Geprüft wird dabei ob der zu öffnende Pfad mit dem angegebene Pfad beginnt. Es ist daher wichtig ob sich am Ende ein "/" befindet oder nicht. Ein open_basedir von /home/doms/example.org/subs/www (ohne /) erlaubt somit z.B. auch Zugriffe auf die Subdomain www2 etc.

Beispielzeile für die php.ini:
open_basedir = /home/doms/example.org/subs/

Wenn man mehrere Subdomains hat und diese isolieren möchte, ist dies durch Aufschaltung von lokalen Subdomains auf verschiedene User möglich. (Siehe https://doc.hostsharing.net/users/administration/domain/index.html )

==== Sicherheitskritische Funktionen ====

Weitere Dinge die deaktiviert werden sollten, wenn sie nicht benötigt werden, was im allgemeinen der Fall ist, sind: Das öffnen von URLs als Dateien,

allow_url_fopen = Off

und die Ausführung von Systembefehlen.

disable_functions = show_source, system, passthru, shell_exec, exec, phpinfo, popen, proc_open

=== eigene PHP Konfigurationen und verschiedene nebeneinander verwenden ===

Um verschiedene PHP Konfigurationen nebeneinander zu verwenden, kopierst Du den phpstub in ein Unterzeichnis von (fast)cgi(-ssl) und mappst (Einträge in der .htaccess) nach Belieben deine PHP Dateien darauf.
So können beliebig viele Konfigurationen bei einer Domain nebeneinander genutzt werden.

==== Beispiel muster.example.com ====
<pre>
mkdir ~/doms/example.com/fastcgi/muster
cp ~/doms/example.com/fastcgi/phpstub ~/doms/example.com/fastcgi/muster/phpstub

und wenn benötigt:
vi ~/doms/example.com/fastcgi/muster/php.ini
</pre>

Anschließend muss der Apache Webserver noch angewiesen werden auch diese bestimmte Konfiguration von PHP zu verwenden. Dazu werden der [[.htaccess]] Datei im DocumentRoot der Sub-Domain zwei Zeilen hinzugefügt bzw. eine .htaccess mit den zwei Zeilen angelegt.
Im Beispiel handelt es sich um die Domain muster.example.com, also:

<pre>
cd ~/doms/example.com/subs/muster
vi .htaccess

AddType application/x-httpd-phpfastcgi .php
Action application/x-httpd-phpfastcgi /fastcgi-bin/muster/phpstub
</pre>

== Vorinstallierte PHP Version wechseln ==
Hostsharing bietet neben der aktuellen Standardversion 7.4 auch PHP 7.0, 7.1, 7.2, 7.3 und 8.0, 8.1 an.

Um die Version zu wechseln, genügt es, den jeweiligen phpstub auszutauschen. Version 7.3 liegt unter <code>/usr/local/src/phpstub/phpstub73</code>; das Versionformat ist entsprechend <code>/usr/local/src/phpstub/phpstubXX</code>.

===phpstub für PHP 8.0 kopieren===

<pre>
$ cp /usr/local/src/phpstub/phpstub80 ~/doms/example.com/fastcgi/
$ cp /usr/local/src/phpstub/phpstub80 ~/doms/example.com/fastcgi-ssl/
</pre>

===phpstub für PHP 8.0 aktivieren===

Die .htaccess sollte möglichst zentral im Verzeichnisbaum abgelegt werden:
~/doms/example.com/.htaccess
Damit durch Anwendungs eigene .htaccess Dateien (Wordpress, Nextcloud etc.) nicht unbeabsichtigt die php Einstellungen verloren gehen.
In der zentralen <code>.htaccess</code> eines Ordners genügt es, die PHP Dateizuordnung zu überschreiben:

<pre>
AddType application/x-httpd-php80 .php
Action application/x-httpd-php80 /fastcgi-bin/phpstub80
</pre>

Damit wird für den aktuellen Ordner und alle Unterordner PHP 8.0 verwendet.

Auf die gleiche Weise können auch PHP 7.1, PHP 7.2 oder PHP 7.3 aktiviert werden.

== Eigene PHP Version ==
Es kann auch eine eigene PHP Version im Paket installiert werden.
Eine kurz Anleitung ist unter [[Eigene_PHP_Version]] beschrieben.

== Eigener PHP FPM Prozess ==

auf einem Managed Server kann jeder Nutzer nach belieben auch php-fpm als eigenen Prozess starten.
Ein paar Notizen dazu finden sich auf der Seite [[PHP_FPM]].

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

.htaccess

2022-10-24T09:32:19Z

Chg93-hsdoku: /* Passwortschutz für Dateien */

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

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

== Einstellen von MIME-Typen ==

# Download von Zertifikaten ermöglichen:
AddType application/x-x509-ca-cert .crt

== Einstellen des im HTTP Header angegebenen Zeichensatzes ==

für .html Dateien:
AddCharset UTF-8 .html

# oder
AddDefaultCharset UTF-8

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

== Einstellen von Datei Handlern ==

AddType application/x-httpd-phpcgi .php
Action application/x-httpd-phpcgi /fastcgi-bin/phpstub

==Passwortschutz für Dateien==

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

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

xyz00-doms@hopi$ cd ~/doms/example.com/etc
xyz00-doms@hopi$ htpasswd -c .htpasswd peter
New password: *****
Re-type new password: *****
xyz00-doms@hopi$

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

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

xyz00-doms@hopi$ locate htpasswd
/usr/sbin/htpasswd
xyz00-doms@hopi$ /usr/sbin/htpasswd -c .htpasswd peter

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

xyz00-doms@hopi$ htpasswd .htpasswd petra
New password: *****
Re-type new password: *****
xyz00-doms@hopi$

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

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

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

order allow,deny
allow from all
require valid-user
Authname "Privater Bereich, bitte Anmelden."
Authtype Basic
AuthUserFile /home/doms/example.com/etc/.htpasswd

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

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

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

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

== Redirects ==

Redirect permanent / http://www.example.com/

== Rewrite Rules ==

RewriteEngine On
RewriteRule ^mailman/(.*)$ /cgi-bin/mailman/$1

== Nur SSL erlauben und automatisch umschalten ==

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

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

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

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

Beispiel:
Redirect permanent / https://www.example.org/

Um alle http Requests nach https weiter zu leiten:

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

==Verzeichnislisting ausschalten==

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

Die Einstellung
IndexIgnore *
sorgt dafür, dass alle Datein Unterhalb des Speicherortes der .htaccess Datei für das Verzeichnislisting ignoriert werden.

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

== Gesperrte Optionen ==

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

Nextcloud

2022-08-25T12:01:37Z

Chg93-hsdoku: /* Nextcloud installieren */

Speicherbelegung

2022-07-22T09:37:04Z

Chg93-hsdoku: /* Paketspeicher */

== Paketspeicher ==

Der im gesamten Paket zur Verfügung stehende bzw genutzte Speicher kann wie folgt abgefragt werden:

Einloggen als Paketadmin

{{Textkasten|gruen||xyz00@h01:~$ pac-du-quota}}
Es wird der Speicherplatz (NVMe SSD) und der Zusatz-Speicherplatz (HDD) angezeigt.

oder

{{Textkasten|gruen||xyz00@h01:~$ quota -gs}}
(g > wir nutzen Gruppenquota, s > für Ausgabe in MB). Die Felder bedeuten:

{| class="wikitable" style="margin: 0em 0em 0em 2em; font-size:1em;"
|- style="background-color:orange;"
!Feld !! Bedeutung
|- style="background-color:#CAE1FF;"
|blocks || KB belegt
|- style="background-color:#B9D3EE;"
|quota || normales (gebuchtes) Limit in KB; "soft quota"
|- style="background-color:#CAE1FF;"
|limit || maximales (temporär toleriertes) Limit in KB; "hard quota"
|- style="background-color:#B9D3EE;"
|grace || Anzahl der Tage, die man noch über "quota" bleiben darf (ist nur gesetzt, wenn blocks>quota)
|- style="background-color:#CAE1FF;"
|files ||Anzahl der INodes (entspricht nicht immer, aber fast einem File. Lediglich Hardlinks verbrauchen nur einen INode pro "realer" Datei)
|- style="background-color:#B9D3EE;"
|quota ||normales Limit der INode-Anzahl
|- style="background-color:#CAE1FF;"
|limit ||maximales Limit der INode-Anzahl
|- style="background-color:#B9D3EE;"
|grace || Anzahl der Tage, die man noch über "INode-quota" bleiben darf (ist nur gesetzt, wenn quota überschritten ist)
|-
|}

Um zu prüfen, ob ein Paket die Quota bald erreicht oder schon überschritten hat, muss man '''blocks''' mit '''quota''' in Verhältnis setzen. Wenn '''blocks > quota''', beginnt die ''grace period'', während der ein weiterer Anstieg des Speicherverbrauchs noch toleriert wird. In jedem Fall gilt '''blocks < limit''': die "hard quota" kann nicht überschritten werden und liegt z.B. bei 150% der "soft quota".

Der genutzte Speicher nur für den Paketadmin selbst kann mit '''du''' abgefragt werden: Einloggen als Paket-Admin und '''du -h''' eingeben. Der Befehl listet die aktuellen Größen der einzelnen Verzeichnisse auf und am Ende den gesamt belegten Plattenplatz in MB.

{{Textkasten|gruen||'''Achtung:''' Die Auflistung (mit '''du''') erfolgt ohne den Speicherplatz der User, für deren Verzeichnisse der Paketadmin kein Zugriffsrecht hat, ohne Dateien in /tmp/ und ohne Datenbanken!}}

An dieser Stelle unser Danke an die Mitglieder Andreas Loesch und Timotheus Pokorra die das hervorragende Skript 'pac-du-quota' bereit gestellt haben.

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

Speicherbelegung

2022-07-22T09:14:49Z

Chg93-hsdoku: /* Paketspeicher */

== Paketspeicher ==

Der im gesamten Paket zur Verfügung stehende Speicher kann wie folgt abgefragt werden:

Einloggen als Paketadmin und '''quota -gs''' eingeben (wir nutzen Gruppenquota, s für Ausgabe in MB). Die Felder bedeuten:

{| class="wikitable" style="margin: 0em 0em 0em 2em; font-size:1em;"
|- style="background-color:orange;"
!Feld !! Bedeutung
|- style="background-color:#CAE1FF;"
|blocks || KB belegt
|- style="background-color:#B9D3EE;"
|quota || normales (gebuchtes) Limit in KB; "soft quota"
|- style="background-color:#CAE1FF;"
|limit || maximales (temporär toleriertes) Limit in KB; "hard quota"
|- style="background-color:#B9D3EE;"
|grace || Anzahl der Tage, die man noch über "quota" bleiben darf (ist nur gesetzt, wenn blocks>quota)
|- style="background-color:#CAE1FF;"
|files ||Anzahl der INodes (entspricht nicht immer, aber fast einem File. Lediglich Hardlinks verbrauchen nur einen INode pro "realer" Datei)
|- style="background-color:#B9D3EE;"
|quota ||normales Limit der INode-Anzahl
|- style="background-color:#CAE1FF;"
|limit ||maximales Limit der INode-Anzahl
|- style="background-color:#B9D3EE;"
|grace || Anzahl der Tage, die man noch über "INode-quota" bleiben darf (ist nur gesetzt, wenn quota überschritten ist)
|-
|}

Um zu prüfen, ob ein Paket die Quota bald erreicht oder schon überschritten hat, muss man '''blocks''' mit '''quota''' in Verhältnis setzen. Wenn '''blocks > quota''', beginnt die ''grace period'', während der ein weiterer Anstieg des Speicherverbrauchs noch toleriert wird. In jedem Fall gilt '''blocks < limit''': die "hard quota" kann nicht überschritten werden und liegt z.B. bei 150% der "soft quota".

Der genutzte Speicher für den Paketadmin selbst kann mit '''du''' abgefragt werden: Einloggen als Paket-Admin und '''du -h''' eingeben. Der Befehl listet die aktuellen Größen der einzelnen Verzeichnisse auf und am Ende den gesamt belegten Plattenplatz in MB.

{{Textkasten|gruen||'''Achtung:''' Die Auflistung (mit '''du''') erfolgt ohne den Speicherplatz der User, für deren Verzeichnisse der Paketadmin kein Zugriffsrecht hat, ohne Dateien in /tmp/ und ohne Datenbanken!}}

Will man eine Übersicht über die Speicherbelegung aller User im Paket, verwendet man den Hostsharing-eigenen Befehl '''du-pac'''. Achtung dort wird aktuell nur der SSD Speicher angezeigt.

Von unserem Mitglied Andreas Loesch, mit Anpassungen von Timotheus Pokorra, gibt es dazu außerdem das hervorragende Skript '''pac-du-quota''', welches die Speicherplatzübersicht von NVMe SSD und unseren STORAGE HDD aller User eines Hostsharing-Paketes auflistet.

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

CiviCRM installieren

2022-05-20T13:41:36Z

Chg93-hsdoku: /* Installation mit Ansible */ playbook-install.yml

== Allgemein ==

[https://civicrm.org/de CiviCRM] ist eine Verwaltungssoftware für Non-Profit-Organisationen, Verbände, Stiftungen, Vereine usw.

CRM steht für Customer-Relationship-Management bzw. Constituent-Relationship-Management, also das Verwalten der Beziehung zu Spendern, Freiwilligen, Unterstützern, Newsletterabonnenten usw.

CiviCRM ist in PHP geschrieben. Es ist keine eigenständige Anwendung, und muss daher entweder auf Wordpress, Drupal oder Joomla installiert werden. Von den Entwicklern wird Drupal empfohlen.

== Technische Details ==

Es gibt ein Ansible Skript, das die Installationsschritte für Drupal und CiviCRM automatisiert durchführt.

Die Quellen für das Ansible Skript können hier eingesehen werden: https://github.com/tpokorra/Hostsharing-Ansible-CiviCRM/

Es wird zuerst Drupal 9 eingerichtet, und dann die deutsche Version von CiviCRM 5.41 installiert.

== Installation mit Ansible ==

Folgende Schritte sind im Benutzer xyz00 auszuführen:

$ touch .hsadmin.properties
$ chmod 600 .hsadmin.properties
$ vi .hsadmin.properties

Es muss in diese Datei das Passwort des Paketadministrators, also von xyz00, eingetragen werden. Das ist das gleiche Passwort, das auf https://admin.hostsharing.net funktioniert.

xyz00.passWord=insertpkgadminpasswordhere

Folgende Schritte sind auf dem lokalen Rechner auszuführen, um CiviCRM mit Hilfe des Ansible Skripts in den eigenen Hostsharing Benutzer zu installieren:

Klonen des Repositories:

$ git clone https://github.com/tpokorra/Hostsharing-Ansible-CiviCRM.git

Dann muss die Datei inventory kopiert werden, und entsprechend angepasst werden:

$ cd Hostsharing-Ansible-CiviCRM
$ cp inventory.yml my.inventory.yml
$ vi my.inventory.yml

In der my.inventory.yml müssen die entsprechenden Werte eingerichtet werden.

Eine Fehlerquelle sind zu lange Namen für user, denn dann kommt die Datenbankverwaltung von hsadmin aus dem Tritt. Bei einem Namen mit 13 Zeichen treten zumindest Fehler auf...

Es wird vorausgesetzt, dass auf dem lokalen Rechner Ansible installiert ist.

Dann kann die Installation vom lokalen Rechner aus gestartet werden:

$ ansible-playbook -i my.inventory.yml playbook-install.yml -k -K

Es kann auch die Option -k weggelassen werden, wenn man sich über einen SSH Key mit xyz00@xyz00.hostsharing.net verbindet.

== Einrichtung ==

Nach der Installation kann die Seite hier erreicht werden: https://civicrm.example.org

Bitte mit dem Benutzer und dem Passwort anmelden, die in der Datei my.inventory angegeben wurden.

Dann zu CiviCRM gehen, und unter Administration / Verwaltungskonsole auf Systemstatus klicken. Dort wird man auf weitere Dinge hingewiesen, die noch eingerichtet werden müssen, z.B. das Standard-Postfach und die Daten der eigenen Organisation.

[[Datei:Civicrm einrichtung.png|800px]]

== Updates ==

Updates werden hier beschrieben:
* für Drupal: https://www.drupal.org/docs/updating-drupal/updating-drupal-core-via-composer
* für CiviCRM: https://docs.civicrm.org/sysadmin/en/latest/upgrade/drupal8/

Es gibt auch ein Playbook im Ansible Verzeichnis. Dieses sollte aber nur als Anleitung genommen werden.
https://github.com/tpokorra/Hostsharing-Ansible-CiviCRM/blob/main/playbook-update.yml

Updates sollten immer erst auf einem Testsystem durchgeführt werden. Vor der Durchführung eines Updates auf dem Produktivsystem sollte ein Backup erstellt werden, das im Fall eines Problems wiederhergestellt werden kann.

== Links ==
*[https://civicrm.org/ Englische Webseite des CiviCRM Projekts]
*[https://sfe-ev.org/ Software für Engagierte e.V.: CiviCRM Support in Deutschland]
*[https://github.com/tpokorra/Hostsharing-Ansible-CiviCRM-Drupal Ansible Playbook für Hostsharing (Drupal)]
*[https://github.com/tpokorra/Hostsharing-Ansible-CiviCRM-WordPress Ansible Playbook für Hostsharing (WordPress)]

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