Hostsharing Wiki - Benutzerbeiträge [de]

Kategorie:HSDoku

2026-02-07T17:45:42Z

Deg00-m.website: fix Link zu doc

In dieser Kategorie (sollten) alle Seiten des Wiki zu finden sein, die sich mit der Dokumentation von HS im weitesten Sinne befassen.

Die '''offizielle''' Kerndokumentation von Hostsharing ist hier: https://doc.hostsharing.net/

Traffic

2025-03-25T19:52:29Z

Deg00-m.website: /* Viel Traffic durch Login-Versuche auf Wordpress-Seiten */ tilde expansion funktioniert nur auf der shell, nicht in apache configfiles

Als Traffic bezeichnet man Datenverkehr zwischen zwei Computersystemen.

Dies beinhaltet [[Logging#HTTP-Traffic|Web]], [[Logging#Mail-Traffic|Mail]] und [[Logging#FTP-Traffic|FTP]] Verbindungen.

==Traffic Ursachen erkennen==

Hostsharing teilt per Mail mit, wenn der tägliche Durchschnitt an gebuchtem Traffic überschritten wurde. In der Mail steht, welches Paket den Traffic verursacht hat und die Warnung, dass Konsequenzen für die Monatsabrechnungen entstehen können. Wer nicht selbst die Ursachen des zusätzlichen Traffic kennt, kann sie mit folgenden Methoden ergründen:

Als erstes einfach mal den Log ansehen und durchscrollen.

<syntaxhighlight lang=shell>
less ~/var/web.log
less ~/var/web.log-yesterday
</syntaxhighlight>

Da kann man oft schon alleine durch Ansehen gleichförmige Strukturen erkennen, z.B. massenhafte Login-Versuche auf einen Wordpress Blog, die sehr viel Traffic generieren.

==Webzugriffe analysieren==

Diese Idee von Michael Hierweck: Wie bekomme ich heraus, welche Web-Zugriffe für mein Traffic-Volumen
maßgeblich verantwortlich sind?

<syntaxhighlight lang=shell line>
cat $HOME/var/web.log |cut -d ' ' -f11 | grep -o '[0-9]*' | sort -n |uniq -c |sed -e's/^ *//' \
|while read FACTOR SUM; do
echo "$((${FACTOR} * ${SUM})) ${FACTOR} ${SUM}";
done |sort -n
</syntaxhighlight>
* Zeile 1: Traffic aus dem Log extrahieren, sortieren, zählen.
* Zeile 2: über die Einträge wandern
* Zeile 3: Produkt aus Zugriffen und Einzelvolumen berechnen
* Zeile 4: Ausgabe von Produkt, Zugriffen und Einzelvolume je Zugriff
* Zeile 5: sortieren

Das Ganze als Einzeiler zum Kopieren, Einfügen und Ausführen im Terminal:
<syntaxhighlight lang=shell>
cat $HOME/var/web.log |cut -d ' ' -f11 | grep -o '[0-9]*' | sort -n |uniq -c |sed -e's/^ *//'|while read FACTOR SUM; do echo "$((${FACTOR} * ${SUM})) ${FACTOR} ${SUM}";done |sort -n
</syntaxhighlight>

Dieser Skript gibt den Traffic aus, den gleichförmige Einzelzugriffe generieren, die größten Brocken stehen unten. Z.B.:

<syntaxhighlight lang=output line>
219558 6 36593
232288 14 16592
239998 22 10909
270812 2 135406
304520 5 60904
318248 14 22732
559062 14 39933
602760 20 30138
711496 8 88937
2325929 101 23029
2351668 29 81092
</syntaxhighlight>

Ganz unten sieht man, dass 29 Zugriffe mit je 81092 Bytes zusammen 2351668 Bytes Traffic gekostet haben. In diesem Fall kann man nun ganz simpel im Log nach der dritten Zahl greppen und in less anzeigen, z.B. so:

<syntaxhighlight lang=shell>
grep 81092 $HOME/var/web.log | less
</syntaxhighlight>

=== Wenn ich dieses Script öfter brauche ... ===

lohnt es sich, daraus ein kleines Programm zu machen.
Dazu einfach

* Texteditor Eurer Wahl öffnen
* Script-Text hier kopieren und in den Editor einfügen
Hier noch mal eine etwas erweiterte Version
<syntaxhighlight lang=shell line>
#!/bin/bash
echo ---------------------------------------------------------------
echo ------------- Top 10 Traffic_Verusacher heute -----------------
echo ---------------------------------------------------------------
echo Gesamtvolumen, Zugriffe, Einzelvolumen
cat $HOME/var/web.log |cut -d ' ' -f11 | grep -o '[0-9]*' | sort -n |uniq -c |sed -e's/^ *//' \
|while read FACTOR SUM; do
echo "$((${FACTOR} * ${SUM})) ${FACTOR} ${SUM}";
done |sort -n -r|head -10

echo
echo ---------------------------------------------------------------
echo ------------- Top 10 Traffic_Verusacher gestern ---------------
echo ---------------------------------------------------------------
echo
echo Gesamtvolumen, Zugriffe, Einzelvolumen
cat $HOME/var/web.log-yesterday |cut -d ' ' -f11 | grep -o '[0-9]*' | sort -n |uniq -c |sed -e's/^ *//' \
|while read FACTOR SUM; do
echo "$((${FACTOR} * ${SUM})) ${FACTOR} ${SUM}";
done |sort -n -r|head -10
echo
echo Sie koennen nun nach dem Versacher suchen, indem sie die
echo Logfiles des Tages nach dem Einzelvolumen durchsuchen
echo 'Befehl: grep 81092 $HOME/var/web.log | less'
</syntaxhighlight>
* Script als Datei ohne Erweiterung unter einem griffigen Namen wie "volumenauswertung" speichern
* Scriptdatei in das Home-Verzeichnis des Paket-Users auf dem Server laden.
* Permission x zufügen, um das Skript ausführbar zu machen.(In WinSCP: Rechtsklick auf Datei, Eigenschaften-Dialog öffnen, X-Eigenschaft für den Eigentümer setzen)

Nun kann man dieses Script jederzeit mit ./volumenauswertung starten.

== Wie erkenne ich, welche Webseite gestern am meisten Traffic Volumen hatte? ==

Dieser Einzeiler sollte es zeigen (Datum entsprechend ändern):

<syntaxhighlight lang=shell>
for f in ${HOME}/var/web-*-20230401*; do echo $f; gunzip -c $f | perl -nE '/\[.+\] ".+" \d+ (\d+)/; $sum += $1; END { printf("%.1f", $sum/1024/1024); print " MB\n"}'; done
</syntaxhighlight>

== Wie bekomme ich IPs mit massenhaften Web-Zugriffen erkannt und gesperrt? ==

IPs mit mehrstelligen Zugriffen werden so gefunden (Hier alle IPs mit vierstelligen Zugriffen, beachte die Ziffer 4 im Ausdruck "egrep '^[0-9]{4,} .*$'"):
<syntaxhighlight lang=shell>
cat ${HOME}/var/web.log |cut -d ' ' -f2 | sort | uniq -c |sed -e's/^ *//' | egrep '^[0-9]{4,} .*$'
</syntaxhighlight>
Als Paketadmin alle IPs mit 10.000 und mehr Web-Zugriffen aus dem
heutigen Log filtern und dafür Sperreinträge erzeugen, die man in die
.htaccess kopieren kann:

<syntaxhighlight lang=shell line>
cat ${HOME}/var/web.log |cut -d ' ' -f2 |sort |uniq -c \
|sed -e's/^ *//' | egrep '^[0-9]{5,} .*$' |cut -d ' ' -f 2 \
|xargs -n1 -r -I XXX echo "deny from XXX"
</syntaxhighlight>

* Zeile 1: Log auswerten und IPs extrahieren und zählen
* Zeile 2: Filtern (Mit der Anweisung '''egrep '^[0-9]{5,} .*$'''' werden durch die Ziffer 5 nur die gefundenen Einträge mit einer fünfstelligen Anzahl von Zugriffen gefunden. Ändert man 5 in 4, werden analog alle Einträge mit vierstelligen Zugriffszahlen gefunden.
* Zeile 3: Einträge erzeugen

== Troubleshooting ==
=== Viel Traffic durch Login-Versuche auf Wordpress-Seiten ===
Login-Versuche auf Wordpress-Seiten können viel Traffic verursachen. Auf folgende Weise können wir diesen Traffic vermeiden, weil stumpfe Login-Roboter nicht an der [https://httpd.apache.org/docs/2.4/howto/auth.html Basic Authentication von Apache] vorbei kommen. Wir editieren die Datei '.htaccess' im Domainverzeichnis:

<syntaxhighlight lang=shell>
cd ~/doms/example.com
edit .htaccess
</syntaxhighlight>

Im Editor geben wir der Datei ''.htaccess'' den folgenden Inhalt hinzu.

<syntaxhighlight lang=shell>
<Files wp-login.php>
AuthName "Protect against silly robots, User username, Pw s3cr3t"
AuthType Basic
AuthUserFile /home/doms/example.com/.htpasswd
Require valid-user
</Files>
</syntaxhighlight>

Wir generieren den Hash für das Passwort ''s3cr3t'' für den Benutzer ''username'' mit dem ''htpasswd'' Tool auf folgende Weise:

<syntaxhighlight lang=shell>
cd ~/doms/example.com
htpasswd -b -c .htpasswd username s3cr3t
</syntaxhighlight>

Danach existiert die Datei '~/doms/example.com/.htpasswd', mit der Apache den Benutzer und das Passwort prüft.

Falls das Benutzer-Formular der Wordpress-Instanz im Browser über die Adresse ''example.com/wp-login.php'' erreichbar ist, werden wir in Zukunft als Erstes von Apache und als Zweites von Wordpress nach Benutzer und Passwort gefragt.

[[Kategorie:HSDoku]]
[[Kategorie:Glossar]]
[[Kategorie:Traffic]]
[[Kategorie:WebStatistik]]

Traffic

2025-03-25T18:10:42Z

Deg00-m.website: /* Troubleshooting */

Als Traffic bezeichnet man Datenverkehr zwischen zwei Computersystemen.

Dies beinhaltet [[Logging#HTTP-Traffic|Web]], [[Logging#Mail-Traffic|Mail]] und [[Logging#FTP-Traffic|FTP]] Verbindungen.

==Traffic Ursachen erkennen==

Hostsharing teilt per Mail mit, wenn der tägliche Durchschnitt an gebuchtem Traffic überschritten wurde. In der Mail steht, welches Paket den Traffic verursacht hat und die Warnung, dass Konsequenzen für die Monatsabrechnungen entstehen können. Wer nicht selbst die Ursachen des zusätzlichen Traffic kennt, kann sie mit folgenden Methoden ergründen:

Als erstes einfach mal den Log ansehen und durchscrollen.

<syntaxhighlight lang=shell>
less ~/var/web.log
less ~/var/web.log-yesterday
</syntaxhighlight>

Da kann man oft schon alleine durch Ansehen gleichförmige Strukturen erkennen, z.B. massenhafte Login-Versuche auf einen Wordpress Blog, die sehr viel Traffic generieren.

==Webzugriffe analysieren==

Diese Idee von Michael Hierweck: Wie bekomme ich heraus, welche Web-Zugriffe für mein Traffic-Volumen
maßgeblich verantwortlich sind?

<syntaxhighlight lang=shell line>
cat $HOME/var/web.log |cut -d ' ' -f11 | grep -o '[0-9]*' | sort -n |uniq -c |sed -e's/^ *//' \
|while read FACTOR SUM; do
echo "$((${FACTOR} * ${SUM})) ${FACTOR} ${SUM}";
done |sort -n
</syntaxhighlight>
* Zeile 1: Traffic aus dem Log extrahieren, sortieren, zählen.
* Zeile 2: über die Einträge wandern
* Zeile 3: Produkt aus Zugriffen und Einzelvolumen berechnen
* Zeile 4: Ausgabe von Produkt, Zugriffen und Einzelvolume je Zugriff
* Zeile 5: sortieren

Das Ganze als Einzeiler zum Kopieren, Einfügen und Ausführen im Terminal:
<syntaxhighlight lang=shell>
cat $HOME/var/web.log |cut -d ' ' -f11 | grep -o '[0-9]*' | sort -n |uniq -c |sed -e's/^ *//'|while read FACTOR SUM; do echo "$((${FACTOR} * ${SUM})) ${FACTOR} ${SUM}";done |sort -n
</syntaxhighlight>

Dieser Skript gibt den Traffic aus, den gleichförmige Einzelzugriffe generieren, die größten Brocken stehen unten. Z.B.:

<syntaxhighlight lang=output line>
219558 6 36593
232288 14 16592
239998 22 10909
270812 2 135406
304520 5 60904
318248 14 22732
559062 14 39933
602760 20 30138
711496 8 88937
2325929 101 23029
2351668 29 81092
</syntaxhighlight>

Ganz unten sieht man, dass 29 Zugriffe mit je 81092 Bytes zusammen 2351668 Bytes Traffic gekostet haben. In diesem Fall kann man nun ganz simpel im Log nach der dritten Zahl greppen und in less anzeigen, z.B. so:

<syntaxhighlight lang=shell>
grep 81092 $HOME/var/web.log | less
</syntaxhighlight>

=== Wenn ich dieses Script öfter brauche ... ===

lohnt es sich, daraus ein kleines Programm zu machen.
Dazu einfach

* Texteditor Eurer Wahl öffnen
* Script-Text hier kopieren und in den Editor einfügen
Hier noch mal eine etwas erweiterte Version
<syntaxhighlight lang=shell line>
#!/bin/bash
echo ---------------------------------------------------------------
echo ------------- Top 10 Traffic_Verusacher heute -----------------
echo ---------------------------------------------------------------
echo Gesamtvolumen, Zugriffe, Einzelvolumen
cat $HOME/var/web.log |cut -d ' ' -f11 | grep -o '[0-9]*' | sort -n |uniq -c |sed -e's/^ *//' \
|while read FACTOR SUM; do
echo "$((${FACTOR} * ${SUM})) ${FACTOR} ${SUM}";
done |sort -n -r|head -10

echo
echo ---------------------------------------------------------------
echo ------------- Top 10 Traffic_Verusacher gestern ---------------
echo ---------------------------------------------------------------
echo
echo Gesamtvolumen, Zugriffe, Einzelvolumen
cat $HOME/var/web.log-yesterday |cut -d ' ' -f11 | grep -o '[0-9]*' | sort -n |uniq -c |sed -e's/^ *//' \
|while read FACTOR SUM; do
echo "$((${FACTOR} * ${SUM})) ${FACTOR} ${SUM}";
done |sort -n -r|head -10
echo
echo Sie koennen nun nach dem Versacher suchen, indem sie die
echo Logfiles des Tages nach dem Einzelvolumen durchsuchen
echo 'Befehl: grep 81092 $HOME/var/web.log | less'
</syntaxhighlight>
* Script als Datei ohne Erweiterung unter einem griffigen Namen wie "volumenauswertung" speichern
* Scriptdatei in das Home-Verzeichnis des Paket-Users auf dem Server laden.
* Permission x zufügen, um das Skript ausführbar zu machen.(In WinSCP: Rechtsklick auf Datei, Eigenschaften-Dialog öffnen, X-Eigenschaft für den Eigentümer setzen)

Nun kann man dieses Script jederzeit mit ./volumenauswertung starten.

== Wie erkenne ich, welche Webseite gestern am meisten Traffic Volumen hatte? ==

Dieser Einzeiler sollte es zeigen (Datum entsprechend ändern):

<syntaxhighlight lang=shell>
for f in ${HOME}/var/web-*-20230401*; do echo $f; gunzip -c $f | perl -nE '/\[.+\] ".+" \d+ (\d+)/; $sum += $1; END { printf("%.1f", $sum/1024/1024); print " MB\n"}'; done
</syntaxhighlight>

== Wie bekomme ich IPs mit massenhaften Web-Zugriffen erkannt und gesperrt? ==

IPs mit mehrstelligen Zugriffen werden so gefunden (Hier alle IPs mit vierstelligen Zugriffen, beachte die Ziffer 4 im Ausdruck "egrep '^[0-9]{4,} .*$'"):
<syntaxhighlight lang=shell>
cat ${HOME}/var/web.log |cut -d ' ' -f2 | sort | uniq -c |sed -e's/^ *//' | egrep '^[0-9]{4,} .*$'
</syntaxhighlight>
Als Paketadmin alle IPs mit 10.000 und mehr Web-Zugriffen aus dem
heutigen Log filtern und dafür Sperreinträge erzeugen, die man in die
.htaccess kopieren kann:

<syntaxhighlight lang=shell line>
cat ${HOME}/var/web.log |cut -d ' ' -f2 |sort |uniq -c \
|sed -e's/^ *//' | egrep '^[0-9]{5,} .*$' |cut -d ' ' -f 2 \
|xargs -n1 -r -I XXX echo "deny from XXX"
</syntaxhighlight>

* Zeile 1: Log auswerten und IPs extrahieren und zählen
* Zeile 2: Filtern (Mit der Anweisung '''egrep '^[0-9]{5,} .*$'''' werden durch die Ziffer 5 nur die gefundenen Einträge mit einer fünfstelligen Anzahl von Zugriffen gefunden. Ändert man 5 in 4, werden analog alle Einträge mit vierstelligen Zugriffszahlen gefunden.
* Zeile 3: Einträge erzeugen

== Troubleshooting ==
=== Viel Traffic durch Login-Versuche auf Wordpress-Seiten ===
Login-Versuche auf Wordpress-Seiten können viel Traffic verursachen. Auf folgende Weise können wir diesen Traffic vermeiden, weil stumpfe Login-Roboter nicht an der [https://httpd.apache.org/docs/2.4/howto/auth.html Basic Authentication von Apache] vorbei kommen. Wir editieren die Datei '.htaccess' im Domainverzeichnis:

<syntaxhighlight lang=shell>
cd ~/doms/example.com
edit .htaccess
</syntaxhighlight>

Im Editor geben wir der Datei ''.htaccess'' den folgenden Inhalt hinzu.

<syntaxhighlight lang=shell>
<Files wp-login.php>
AuthName "Protect against silly robots, User username, Pw s3cr3t"
AuthType Basic
AuthUserFile /home/doms/example.com/.htpasswd
Require valid-user
</Files>
</syntaxhighlight>

Wir generieren den Hash für das Passwort ''s3cr3t'' für den Benutzer ''username'' mit dem ''htpasswd'' Tool auf folgende Weise:

<syntaxhighlight lang=shell>
cd ~/doms/example.com
htpasswd -b -c .htpasswd username s3cr3t
</syntaxhighlight>

Danach existiert die Datei '/home/doms/example.com/.htpasswd', mit der der Apache das Benutzer und Passwort prüfen kann.

Falls das Benutzer-Formular der Wordpress-Instanz im Browser über die Adresse ''example.com/wp-login.php'' erreichbar ist, werden wir in Zukunft als Erstes von Apache und als Zweites von Wordpress nach Benutzer und Passwort gefragt.

[[Kategorie:HSDoku]]
[[Kategorie:Glossar]]
[[Kategorie:Traffic]]
[[Kategorie:WebStatistik]]

Traffic

2025-03-25T09:48:34Z

Deg00-m.website: /* Viel Traffic durch Login-Versuche auf Wordpress-Seiten */ symlinks zu domain-verzeichnis verwendet, example.com

Als Traffic bezeichnet man Datenverkehr zwischen zwei Computersystemen.

Dies beinhaltet [[Logging#HTTP-Traffic|Web]], [[Logging#Mail-Traffic|Mail]] und [[Logging#FTP-Traffic|FTP]] Verbindungen.

==Traffic Ursachen erkennen==

Hostsharing teilt per Mail mit, wenn der tägliche Durchschnitt an gebuchtem Traffic überschritten wurde. In der Mail steht, welches Paket den Traffic verursacht hat und die Warnung, dass Konsequenzen für die Monatsabrechnungen entstehen können. Wer nicht selbst die Ursachen des zusätzlichen Traffic kennt, kann sie mit folgenden Methoden ergründen:

Als erstes einfach mal den Log ansehen und durchscrollen.

<syntaxhighlight lang=shell>
less ~/var/web.log
less ~/var/web.log-yesterday
</syntaxhighlight>

Da kann man oft schon alleine durch Ansehen gleichförmige Strukturen erkennen, z.B. massenhafte Login-Versuche auf einen Wordpress Blog, die sehr viel Traffic generieren.

==Webzugriffe analysieren==

Diese Idee von Michael Hierweck: Wie bekomme ich heraus, welche Web-Zugriffe für mein Traffic-Volumen
maßgeblich verantwortlich sind?

<syntaxhighlight lang=shell line>
cat $HOME/var/web.log |cut -d ' ' -f11 | grep -o '[0-9]*' | sort -n |uniq -c |sed -e's/^ *//' \
|while read FACTOR SUM; do
echo "$((${FACTOR} * ${SUM})) ${FACTOR} ${SUM}";
done |sort -n
</syntaxhighlight>
* Zeile 1: Traffic aus dem Log extrahieren, sortieren, zählen.
* Zeile 2: über die Einträge wandern
* Zeile 3: Produkt aus Zugriffen und Einzelvolumen berechnen
* Zeile 4: Ausgabe von Produkt, Zugriffen und Einzelvolume je Zugriff
* Zeile 5: sortieren

Das Ganze als Einzeiler zum Kopieren, Einfügen und Ausführen im Terminal:
<syntaxhighlight lang=shell>
cat $HOME/var/web.log |cut -d ' ' -f11 | grep -o '[0-9]*' | sort -n |uniq -c |sed -e's/^ *//'|while read FACTOR SUM; do echo "$((${FACTOR} * ${SUM})) ${FACTOR} ${SUM}";done |sort -n
</syntaxhighlight>

Dieser Skript gibt den Traffic aus, den gleichförmige Einzelzugriffe generieren, die größten Brocken stehen unten. Z.B.:

<syntaxhighlight lang=output line>
219558 6 36593
232288 14 16592
239998 22 10909
270812 2 135406
304520 5 60904
318248 14 22732
559062 14 39933
602760 20 30138
711496 8 88937
2325929 101 23029
2351668 29 81092
</syntaxhighlight>

Ganz unten sieht man, dass 29 Zugriffe mit je 81092 Bytes zusammen 2351668 Bytes Traffic gekostet haben. In diesem Fall kann man nun ganz simpel im Log nach der dritten Zahl greppen und in less anzeigen, z.B. so:

<syntaxhighlight lang=shell>
grep 81092 $HOME/var/web.log | less
</syntaxhighlight>

=== Wenn ich dieses Script öfter brauche ... ===

lohnt es sich, daraus ein kleines Programm zu machen.
Dazu einfach

* Texteditor Eurer Wahl öffnen
* Script-Text hier kopieren und in den Editor einfügen
Hier noch mal eine etwas erweiterte Version
<syntaxhighlight lang=shell line>
#!/bin/bash
echo ---------------------------------------------------------------
echo ------------- Top 10 Traffic_Verusacher heute -----------------
echo ---------------------------------------------------------------
echo Gesamtvolumen, Zugriffe, Einzelvolumen
cat $HOME/var/web.log |cut -d ' ' -f11 | grep -o '[0-9]*' | sort -n |uniq -c |sed -e's/^ *//' \
|while read FACTOR SUM; do
echo "$((${FACTOR} * ${SUM})) ${FACTOR} ${SUM}";
done |sort -n -r|head -10

echo
echo ---------------------------------------------------------------
echo ------------- Top 10 Traffic_Verusacher gestern ---------------
echo ---------------------------------------------------------------
echo
echo Gesamtvolumen, Zugriffe, Einzelvolumen
cat $HOME/var/web.log-yesterday |cut -d ' ' -f11 | grep -o '[0-9]*' | sort -n |uniq -c |sed -e's/^ *//' \
|while read FACTOR SUM; do
echo "$((${FACTOR} * ${SUM})) ${FACTOR} ${SUM}";
done |sort -n -r|head -10
echo
echo Sie koennen nun nach dem Versacher suchen, indem sie die
echo Logfiles des Tages nach dem Einzelvolumen durchsuchen
echo 'Befehl: grep 81092 $HOME/var/web.log | less'
</syntaxhighlight>
* Script als Datei ohne Erweiterung unter einem griffigen Namen wie "volumenauswertung" speichern
* Scriptdatei in das Home-Verzeichnis des Paket-Users auf dem Server laden.
* Permission x zufügen, um das Skript ausführbar zu machen.(In WinSCP: Rechtsklick auf Datei, Eigenschaften-Dialog öffnen, X-Eigenschaft für den Eigentümer setzen)

Nun kann man dieses Script jederzeit mit ./volumenauswertung starten.

== Wie erkenne ich, welche Webseite gestern am meisten Traffic Volumen hatte? ==

Dieser Einzeiler sollte es zeigen (Datum entsprechend ändern):

<syntaxhighlight lang=shell>
for f in ${HOME}/var/web-*-20230401*; do echo $f; gunzip -c $f | perl -nE '/\[.+\] ".+" \d+ (\d+)/; $sum += $1; END { printf("%.1f", $sum/1024/1024); print " MB\n"}'; done
</syntaxhighlight>

== Wie bekomme ich IPs mit massenhaften Web-Zugriffen erkannt und gesperrt? ==

IPs mit mehrstelligen Zugriffen werden so gefunden (Hier alle IPs mit vierstelligen Zugriffen, beachte die Ziffer 4 im Ausdruck "egrep '^[0-9]{4,} .*$'"):
<syntaxhighlight lang=shell>
cat ${HOME}/var/web.log |cut -d ' ' -f2 | sort | uniq -c |sed -e's/^ *//' | egrep '^[0-9]{4,} .*$'
</syntaxhighlight>
Als Paketadmin alle IPs mit 10.000 und mehr Web-Zugriffen aus dem
heutigen Log filtern und dafür Sperreinträge erzeugen, die man in die
.htaccess kopieren kann:

<syntaxhighlight lang=shell line>
cat ${HOME}/var/web.log |cut -d ' ' -f2 |sort |uniq -c \
|sed -e's/^ *//' | egrep '^[0-9]{5,} .*$' |cut -d ' ' -f 2 \
|xargs -n1 -r -I XXX echo "deny from XXX"
</syntaxhighlight>

* Zeile 1: Log auswerten und IPs extrahieren und zählen
* Zeile 2: Filtern (Mit der Anweisung '''egrep '^[0-9]{5,} .*$'''' werden durch die Ziffer 5 nur die gefundenen Einträge mit einer fünfstelligen Anzahl von Zugriffen gefunden. Ändert man 5 in 4, werden analog alle Einträge mit vierstelligen Zugriffszahlen gefunden.
* Zeile 3: Einträge erzeugen

== Troubleshooting ==
=== Viel Traffic durch Login-Versuche auf Wordpress-Seiten ===
Login-Versuche auf Wordpress-Seiten können viel Traffic verursachen. Auf folgende Weise können wir diesen Traffic vermeiden, weil stumpfe Login-Roboter nicht an der [https://httpd.apache.org/docs/2.4/howto/auth.html Basic Authentication von Apache] vorbei kommen. Wir editieren die Datei '.htaccess' im Webroot der Domain:

<syntaxhighlight lang=shell>
cd ~/doms/example.com/htdocs-ssl
</syntaxhighlight>

<syntaxhighlight lang=shell>
edit .htaccess
</syntaxhighlight>

Im Editor geben wir der Datei ''.htaccess'' den folgenden Inhalt hinzu. Wenn Wordpress bereits eine '.htaccess'-Datei angelegt hat, dann oberhalb des Strings '# BEGIN WordPress', ab dem WP seine eigenen Einstellungen schreibt:

<syntaxhighlight lang=shell>
<Files wp-login.php>
AuthName "Protect against silly robots, User username, Pw s3cr3t"
AuthType Basic
AuthUserFile /home/doms/example.com/.htpasswd
Require valid-user
</Files>
</syntaxhighlight>

Wir generieren den Hash für das Passwort ''s3cr3t'' für den Benutzer ''username'' mit dem ''htpasswd'' Tool auf folgende Weise:

<syntaxhighlight lang=shell>
cd ~/doms/example.com
htpasswd -b -c .htpasswd username s3cr3t
</syntaxhighlight>

Danach existiert die Datei '/home/doms/example.com/.htpasswd', mit der der Apache das Benutzer und Passwort prüfen kann.

Falls das Benutzer-Formular der Wordpress-Instanz im Browser über die Adresse ''example.com/wp-login.php'' erreichbar ist, werden wir in Zukunft als Erstes von Apache und als Zweites von Wordpress nach Benutzer und Passwort gefragt.

[[Kategorie:HSDoku]]
[[Kategorie:Glossar]]
[[Kategorie:Traffic]]
[[Kategorie:WebStatistik]]

Umstellung von Daemon-Diensten auf systemd

2024-12-03T08:57:50Z

Deg00-m.website: /* Rückblick auf Bearbeitung von Cronjobs */ Erklärung Übersicht Cronjobs

== Anlass dieser Anleitung ==

Ab November 2024 unterstützt die Managed Plattform ein RAM Kontingent pro Managed Webspace. Mitglieder buchen für ihre Webspaces jeweils ein RAM Kontingent in Schritten von jeweils 128 Megabyte. Das unterstützt uns besser bei der verursachergerechten Verteilung der Hardwarekosten, als es vorher mit einer Pauschale pro Serverdienst der Fall war. Änderungen des RAM Kontingents für einen Webspace nimmt der Service unter [mailto:service@hostsharing.net service@hostsharing.net] entgegen, wie es bei anderen Paketoptionen die Vorgehensweise ist.

Damit die RAM Kontingente funktionieren, müssen im Managed Webspace alle Anwendungen, die im Userspace laufen, auf systemd umgestellt werden. Das betrifft Anwendungen, die bisher über z.B. cronjob, supervisor oder monit gestartet wurden.

Siehe auch unsere [[Systemd im Userspace]] Dokumentation.

== Praktische Umstellung ==

Für eine Übergangsphase steht jedem Managed Webspace genügend RAM zur Verfügung, um eigene Serverdienste zu starten.
Nach der Umstellung aller Dienste auf systemd wird dann das tatsächlich benötigte RAM-Kontingent ermittelt und gebucht.

=== cronjob ===

==== Rückblick auf Bearbeitung von Cronjobs ====
Mit dem Befehl <code>crontab -l</code> können die eigenen Cronjobs aufgelistet werden.

Mit dem Befehl <code>crontab -e</code> bearbeiten wir unsere Hintergrundjobs.

Wenn am Anfang einer Zeile das Rautezeichen # eingesetzt wird, dann ist die Zeile deaktiviert.

Eine Übersicht über die Cronjobs der einzelnen Benutzer eines Webpaketes xyz00 lässt sich so ausgeben, wenn in der Shell des Paket-Benutzers xyz00 folgender Befehl ausgeführt wird:

<syntaxhighlight lang="bash">
cd users/; for U in *; do echo "=== $USER-$U"; sudo -u $USER-$U crontab -l | grep -v "#"; done
</syntaxhighlight>

Auf der Seite [[Cron]] werden weitere Einzelheiten beschrieben.

==== Umstellung auf systemd Timer ====

Hier ist eine schöne Übersicht mit Beispielen: https://documentation.suse.com/smart/systems-management/html/systemd-working-with-timers/index.html#systemd-timer-catchup

==== Beispiel: Nextcloud Hintergrund Job ====

Hier haben wir ein Beispiel für einen Nextcloud Hintergrund Job, der alle 5 Minuten läuft, und in der crontab eingetragen ist:

<syntaxhighlight lang="crontab">
*/5 * * * * /usr/bin/php $HOME/nextcloud/cron.php
</syntaxhighlight>

Wir deaktivieren diesen Cronjob, in dem wir ein # vor die Zeile setzen, wie oben beschrieben.

Nun muss ggfs. das Verzeichnis für systemd angelegt werden:

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

Nun wird die Datei für den oneshot Dienst angelegt:

<syntaxhighlight lang="bash">
nano $HOME/.config/systemd/user/nextcloud-job.service
</syntaxhighlight>

mit diesem Inhalt:

<syntaxhighlight lang="ini">
[Unit]
Description=Nextcloud Hintergrundjob

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

{{Textkasten|gelb|Beachte|Statt $HOME muss %h benutzt werden!}}

Nun wird die Datei für den Timer angelegt:

<syntaxhighlight lang="bash">
nano $HOME/.config/systemd/user/nextcloud-job.timer
</syntaxhighlight>

mit diesem Inhalt:

<syntaxhighlight lang="ini">
[Unit]
Description=Timer für Nextcloud Hintergrundjob

[Timer]
OnCalendar=*:0/5
RandomizedDelaySec=30

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

Nun soll der Timer noch aktiviert und gestartet werden:

<syntaxhighlight lang="bash">
systemctl --user daemon-reload
systemctl --user enable nextcloud-job.timer --now
</syntaxhighlight>

==== Beispiel: Logrotate aufrufen ====

Hier haben wir ein Beispiel für einen Logrotate Job, der einmal in der Nacht aufgerufen wird, und in der crontab eingetragen ist:

<syntaxhighlight lang="crontab">
13 1 * * * /usr/sbin/logrotate -s $HOME/.logrotate.state $HOME/.logrotate
</syntaxhighlight>

Wir deaktivieren diesen Cronjob, in dem wir ein # vor die Zeile setzen, wie oben beschrieben.

Nun muss ggfs. das Verzeichnis für systemd angelegt werden:

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

Nun wird die Datei für den oneshot Dienst angelegt:

<syntaxhighlight lang="bash">
nano $HOME/.config/systemd/user/logrotate-job.service
</syntaxhighlight>

mit diesem Inhalt:

<syntaxhighlight lang="ini">
[Unit]
Description=Logrotate Job

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

{{Textkasten|gelb|Beachte|Statt $HOME muss %h benutzt werden!}}

Nun wird die Datei für den Timer angelegt:

<syntaxhighlight lang="bash">
nano $HOME/.config/systemd/user/logrotate-job.timer
</syntaxhighlight>

mit diesem Inhalt:

<syntaxhighlight lang="ini">
[Unit]
Description=Timer für Logrotate Job

[Timer]
OnCalendar=01:13
RandomizedDelaySec=300
Persistent=true

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

Nun soll der Timer noch aktiviert und gestartet werden:

<syntaxhighlight lang="bash">
systemctl --user daemon-reload
systemctl --user enable logrotate-job.timer --now
</syntaxhighlight>

=== Monit ===

==== Beispiel: Redis ====

Hier haben wir eine Datei <code>.monitrc</code>, mit der ein Redis Dienst betrieben wird:

<syntaxhighlight lang="monit">
set daemon 60
with start delay 120
set logfile /home/pacs/xyz00/nextcloud/var/monit.log
set idfile /home/pacs/xyz00/nextcloud/var/monit.id
set statefile /home/pacs/xyz00/nextcloud/var/monit.state
set mailserver localhost
set mail-format { from: webmaster@example.org }
set alert webmaster@example.org
set httpd port 12345 address xyz00.hostsharing.net
allow monit:topsecret
check process redis with pidfile /home/pacs/xyz00/nextcloud/redis/var/redis-server.pid
start program "/usr/bin/redis-server /home/pacs/xyz00/nextcloud/redis/etc/redis.conf"
stop program "/bin/bash -c '/bin/kill $( cat /home/pacs/xyz00/nextcloud/redis/var/redis-server.pid )'"
</syntaxhighlight>

Der Start von monit nach einem Reboot des Servers wird verhindert, indem die entsprechende Zeile gelöscht wird:

<syntaxhighlight lang="bash">
crontab -e

entferne diese Zeile:
@reboot /usr/bin/monit -c $HOME/.monitrc
</syntaxhighlight>

Die Dienste werden gestoppt:

<syntaxhighlight lang="bash">
killall -u $USER -KILL monit
killall -u $USER -KILL redis-server
</syntaxhighlight>

Nun muss ggfs. das Verzeichnis für systemd angelegt werden:

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

Nun wird die Datei für den Redis Dienst angelegt:

<syntaxhighlight lang="bash">
nano $HOME/.config/systemd/user/redis.service
</syntaxhighlight>

<syntaxhighlight lang="ini">
[Unit]
Description=Redis Service
After=network-online.target

[Service]
WorkingDirectory=%h/redis/var
ExecStart=/usr/bin/redis-server %h/redis/etc/redis.conf
Restart=always
PrivateTmp=true
NoNewPrivileges=true
StandardOutput=append:%h/var/log/redis.log
StandardError=inherit

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

Es muss noch die folgende Zeile aus <code>redis/etc/redis.conf</code> entfernt werden:

<syntaxhighlight lang="conf">
daemonize yes
</syntaxhighlight>

Nun soll der Dienst aktiviert und gestartet werden:

<syntaxhighlight lang="bash">
systemctl --user enable redis.service --now
</syntaxhighlight>

==== Beispiel: Apache ====

Es wurden in der Vergangenheit Start- und Stoppskripte empfohlen. Die Startskripte wurden dann um verschiedene Aktionen ergänzt.

Da empfehlen wir, die sonstigen Aktionen in ein eigenes Skript auszulagern, das mit der Direktive <code>ExecStartPre=</code> gestartet wird.
Dann kann der eigentliche Prozess mit <code>ExecStart=</code> gestartet werden, und wird dann auch entsprechend beendet. Dann ist kein Stopp-Skript erforderlich.

Es kann aber auch mit <code>ExecStop</code> ein Stopp-Skript ausgeführt werden.

=== supervisor ===

Bei supervisor wird z.B. in der Datei <code>~/supervisor/etc/supervisord.conf</code> ein Redis Dienst konfiguriert:

<syntaxhighlight lang="ini">
[program:redis]
command=/usr/bin/redis-server /home/pacs/xyz00/test/loomio/redis/etc/redis.conf
stderr_logfile = /home/pacs/xyz00/users/test/supervisor/log/redis-stderr.log
stdout_logfile = /home/pacs/xyz00/users/test/supervisor/log/redis-stdout.log
</syntaxhighlight>

Das muss entsprechend durch einen systemd Dienst ersetzt werden, siehe der Abschnitt bei der Umstellung von monit auf systemd.

== Ermittlung und Buchung des benötigten RAM Kontingent ==

siehe [[Prozessmanagement_mit_systemd_im_Userspace#RAM_Kontingent_eines_Webspace|RAM Kontingent eines Webspace]]

----
[[Kategorie:Systemd]]

Umstellung von Daemon-Diensten auf systemd

2024-12-03T08:54:36Z

Deg00-m.website: /* Rückblick auf Bearbeitung von Cronjobs */ Cronjobs auflisten auch für Zsh und ohne Kommentare

== Anlass dieser Anleitung ==

Ab November 2024 unterstützt die Managed Plattform ein RAM Kontingent pro Managed Webspace. Mitglieder buchen für ihre Webspaces jeweils ein RAM Kontingent in Schritten von jeweils 128 Megabyte. Das unterstützt uns besser bei der verursachergerechten Verteilung der Hardwarekosten, als es vorher mit einer Pauschale pro Serverdienst der Fall war. Änderungen des RAM Kontingents für einen Webspace nimmt der Service unter [mailto:service@hostsharing.net service@hostsharing.net] entgegen, wie es bei anderen Paketoptionen die Vorgehensweise ist.

Damit die RAM Kontingente funktionieren, müssen im Managed Webspace alle Anwendungen, die im Userspace laufen, auf systemd umgestellt werden. Das betrifft Anwendungen, die bisher über z.B. cronjob, supervisor oder monit gestartet wurden.

Siehe auch unsere [[Systemd im Userspace]] Dokumentation.

== Praktische Umstellung ==

Für eine Übergangsphase steht jedem Managed Webspace genügend RAM zur Verfügung, um eigene Serverdienste zu starten.
Nach der Umstellung aller Dienste auf systemd wird dann das tatsächlich benötigte RAM-Kontingent ermittelt und gebucht.

=== cronjob ===

==== Rückblick auf Bearbeitung von Cronjobs ====
Mit dem Befehl <code>crontab -l</code> können die eigenen Cronjobs aufgelistet werden.

Mit dem Befehl <code>crontab -e</code> bearbeiten wir unsere Hintergrundjobs.

Wenn am Anfang einer Zeile das Rautezeichen # eingesetzt wird, dann ist die Zeile deaktiviert.

Eine Übersicht über die Cronjobs der einzelnen Benutzer eines Webspace lässt sich so ausgeben, als Paket-Benutzer xyz00:

<syntaxhighlight lang="bash">
cd users/; for U in *; do echo "=== $USER-$U"; sudo -u $USER-$U crontab -l | grep -v "#"; done
</syntaxhighlight>

Auf der Seite [[Cron]] werden weitere Einzelheiten beschrieben.

==== Umstellung auf systemd Timer ====

Hier ist eine schöne Übersicht mit Beispielen: https://documentation.suse.com/smart/systems-management/html/systemd-working-with-timers/index.html#systemd-timer-catchup

==== Beispiel: Nextcloud Hintergrund Job ====

Hier haben wir ein Beispiel für einen Nextcloud Hintergrund Job, der alle 5 Minuten läuft, und in der crontab eingetragen ist:

<syntaxhighlight lang="crontab">
*/5 * * * * /usr/bin/php $HOME/nextcloud/cron.php
</syntaxhighlight>

Wir deaktivieren diesen Cronjob, in dem wir ein # vor die Zeile setzen, wie oben beschrieben.

Nun muss ggfs. das Verzeichnis für systemd angelegt werden:

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

Nun wird die Datei für den oneshot Dienst angelegt:

<syntaxhighlight lang="bash">
nano $HOME/.config/systemd/user/nextcloud-job.service
</syntaxhighlight>

mit diesem Inhalt:

<syntaxhighlight lang="ini">
[Unit]
Description=Nextcloud Hintergrundjob

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

{{Textkasten|gelb|Beachte|Statt $HOME muss %h benutzt werden!}}

Nun wird die Datei für den Timer angelegt:

<syntaxhighlight lang="bash">
nano $HOME/.config/systemd/user/nextcloud-job.timer
</syntaxhighlight>

mit diesem Inhalt:

<syntaxhighlight lang="ini">
[Unit]
Description=Timer für Nextcloud Hintergrundjob

[Timer]
OnCalendar=*:0/5
RandomizedDelaySec=30

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

Nun soll der Timer noch aktiviert und gestartet werden:

<syntaxhighlight lang="bash">
systemctl --user daemon-reload
systemctl --user enable nextcloud-job.timer --now
</syntaxhighlight>

==== Beispiel: Logrotate aufrufen ====

Hier haben wir ein Beispiel für einen Logrotate Job, der einmal in der Nacht aufgerufen wird, und in der crontab eingetragen ist:

<syntaxhighlight lang="crontab">
13 1 * * * /usr/sbin/logrotate -s $HOME/.logrotate.state $HOME/.logrotate
</syntaxhighlight>

Wir deaktivieren diesen Cronjob, in dem wir ein # vor die Zeile setzen, wie oben beschrieben.

Nun muss ggfs. das Verzeichnis für systemd angelegt werden:

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

Nun wird die Datei für den oneshot Dienst angelegt:

<syntaxhighlight lang="bash">
nano $HOME/.config/systemd/user/logrotate-job.service
</syntaxhighlight>

mit diesem Inhalt:

<syntaxhighlight lang="ini">
[Unit]
Description=Logrotate Job

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

{{Textkasten|gelb|Beachte|Statt $HOME muss %h benutzt werden!}}

Nun wird die Datei für den Timer angelegt:

<syntaxhighlight lang="bash">
nano $HOME/.config/systemd/user/logrotate-job.timer
</syntaxhighlight>

mit diesem Inhalt:

<syntaxhighlight lang="ini">
[Unit]
Description=Timer für Logrotate Job

[Timer]
OnCalendar=01:13
RandomizedDelaySec=300
Persistent=true

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

Nun soll der Timer noch aktiviert und gestartet werden:

<syntaxhighlight lang="bash">
systemctl --user daemon-reload
systemctl --user enable logrotate-job.timer --now
</syntaxhighlight>

=== Monit ===

==== Beispiel: Redis ====

Hier haben wir eine Datei <code>.monitrc</code>, mit der ein Redis Dienst betrieben wird:

<syntaxhighlight lang="monit">
set daemon 60
with start delay 120
set logfile /home/pacs/xyz00/nextcloud/var/monit.log
set idfile /home/pacs/xyz00/nextcloud/var/monit.id
set statefile /home/pacs/xyz00/nextcloud/var/monit.state
set mailserver localhost
set mail-format { from: webmaster@example.org }
set alert webmaster@example.org
set httpd port 12345 address xyz00.hostsharing.net
allow monit:topsecret
check process redis with pidfile /home/pacs/xyz00/nextcloud/redis/var/redis-server.pid
start program "/usr/bin/redis-server /home/pacs/xyz00/nextcloud/redis/etc/redis.conf"
stop program "/bin/bash -c '/bin/kill $( cat /home/pacs/xyz00/nextcloud/redis/var/redis-server.pid )'"
</syntaxhighlight>

Der Start von monit nach einem Reboot des Servers wird verhindert, indem die entsprechende Zeile gelöscht wird:

<syntaxhighlight lang="bash">
crontab -e

entferne diese Zeile:
@reboot /usr/bin/monit -c $HOME/.monitrc
</syntaxhighlight>

Die Dienste werden gestoppt:

<syntaxhighlight lang="bash">
killall -u $USER -KILL monit
killall -u $USER -KILL redis-server
</syntaxhighlight>

Nun muss ggfs. das Verzeichnis für systemd angelegt werden:

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

Nun wird die Datei für den Redis Dienst angelegt:

<syntaxhighlight lang="bash">
nano $HOME/.config/systemd/user/redis.service
</syntaxhighlight>

<syntaxhighlight lang="ini">
[Unit]
Description=Redis Service
After=network-online.target

[Service]
WorkingDirectory=%h/redis/var
ExecStart=/usr/bin/redis-server %h/redis/etc/redis.conf
Restart=always
PrivateTmp=true
NoNewPrivileges=true
StandardOutput=append:%h/var/log/redis.log
StandardError=inherit

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

Es muss noch die folgende Zeile aus <code>redis/etc/redis.conf</code> entfernt werden:

<syntaxhighlight lang="conf">
daemonize yes
</syntaxhighlight>

Nun soll der Dienst aktiviert und gestartet werden:

<syntaxhighlight lang="bash">
systemctl --user enable redis.service --now
</syntaxhighlight>

==== Beispiel: Apache ====

Es wurden in der Vergangenheit Start- und Stoppskripte empfohlen. Die Startskripte wurden dann um verschiedene Aktionen ergänzt.

Da empfehlen wir, die sonstigen Aktionen in ein eigenes Skript auszulagern, das mit der Direktive <code>ExecStartPre=</code> gestartet wird.
Dann kann der eigentliche Prozess mit <code>ExecStart=</code> gestartet werden, und wird dann auch entsprechend beendet. Dann ist kein Stopp-Skript erforderlich.

Es kann aber auch mit <code>ExecStop</code> ein Stopp-Skript ausgeführt werden.

=== supervisor ===

Bei supervisor wird z.B. in der Datei <code>~/supervisor/etc/supervisord.conf</code> ein Redis Dienst konfiguriert:

<syntaxhighlight lang="ini">
[program:redis]
command=/usr/bin/redis-server /home/pacs/xyz00/test/loomio/redis/etc/redis.conf
stderr_logfile = /home/pacs/xyz00/users/test/supervisor/log/redis-stderr.log
stdout_logfile = /home/pacs/xyz00/users/test/supervisor/log/redis-stdout.log
</syntaxhighlight>

Das muss entsprechend durch einen systemd Dienst ersetzt werden, siehe der Abschnitt bei der Umstellung von monit auf systemd.

== Ermittlung und Buchung des benötigten RAM Kontingent ==

siehe [[Prozessmanagement_mit_systemd_im_Userspace#RAM_Kontingent_eines_Webspace|RAM Kontingent eines Webspace]]

----
[[Kategorie:Systemd]]

Cron

2024-12-03T01:47:00Z

Deg00-m.website:

Cron wird ersetzt durch [[Prozessmanagement mit systemd im Userspace#Zeitgesteuerte_Ausführung_mit_systemd|Systemd Timer]]

{{Veraltet}}
{{Löschkandidat}}

Cron ist ein UNIX-Dienst, mit dem regelmäßige Jobs ausgeführt werden können, ohne dass der Benutzer dabei am System angemeldet sein muss. Dazu wird mit dem Kommando crontab die Konfiguration erstellt, aus der das System entnehmen kann, welches Kommando zu welcher Zeit auszuführen ist. Den Rest erledigt dann ein Systemprozess, der jede Minute überprüft, ob für einen User ein Job auszuführen ist.
=== Crontab ===
Mit crontab wird sowohl das Kommando zum Erstellen, Ändern und Löschen der eigenen Konfiguration als auch das dabei benutzte Dateiformat bezeichnet. Deshalb bekommt man die Beschreibung des Kommandos mit man 1 crontab und die Beschreibung des Formates mit man 5 crontab angezeigt.

Anzeigen der aktuellen Konfiguration:
<syntaxhighlight lang=shell>
crontab -l
</syntaxhighlight>
Löschen der kompletten Konfiguration:
<syntaxhighlight lang=shell>
crontab -r
</syntaxhighlight>
Ändern der Konfiguration:
<syntaxhighlight lang=shell>
crontab -e
</syntaxhighlight>
Crontab von einer Datei starten:
<syntaxhighlight lang=shell>
crontab myjob
</syntaxhighlight>
Der beim Editieren verwendete Editor wird durch die Umgebungsvariablen EDITOR und VISUAL bestimmt. Der Default ist vi. Alternativ kann man folgenden Weg gehen:
<syntaxhighlight lang=shell>
xyz00@hopi:~$crontab -l > myjobs
</syntaxhighlight>
Dann die Datei myjobs mit einem beliebigen Editor anpassen. Anschließend den cronjob von der Datei myjobs starten und die Datei löschen:
<syntaxhighlight lang=shell>
xyz00@hopi:~$ crontab myjobs

xyz00@hopi:~$ rm myjobs
</syntaxhighlight>
=== Dateiformat ===
Kommentare werden mit # am Zeilenanfang gekennzeichnet. Eine Befehlszeile in der Crontab-Datei besteht aus sechs durch Leerzeichen getrennten Feldern, wobei die ersten fünf Felder den Zeitpunkt der Ausführung festlegen und der Rest der Zeile das auszuführende Kommando bestimmt. Die ersten fünf Felder sind:
<syntaxhighlight lang=shell>
* Minute (0-59)
* Stunde (0-23)
* Tag des Monats (1-31)
* Monat (1-12 oder JAN-DEC)
* Wochentag (0-7; 0 und 7 entsprechen jeweils Sonntag oder SUN-SAT)
</syntaxhighlight>
Ein Stern * steht dabei für alle möglichen Werte eines Feldes. Die Felder können auch als Bereich (z.B. 2-4) und Liste (z.B. 3,6,8) angegeben werden. Auch lassen sich Schrittweiten für ein Feld angeben(z.B. */2). Dies kann auch kombiniert werden (z.B. 4-54/10).

Das dritte und fünfte Feld können beide den Tag der Ausführung bezeichnen. Sind beide gesetzt, also nicht *, so wird der Job ausgeführt, wenn einer der beiden Bedingungen erfüllt ist.

Statt einer Zeitangabe kann auch <code>@reboot</code> verwendet werden. In diesem Fall wird z.B. ein Dienst nach dem Neustart des Servers wieder gestartet.

=== Umgebungsvariablen ===
Folgende Umgebungsvariablen können in der crontab-Datei gesetzt werden:

<syntaxhighlight lang=ini line>
PWD

LOGNAME

SHLVL

SHELL

HOME

PATH

MAILTO
</syntaxhighlight>

=== Beispiel ===
<syntaxhighlight lang=shell line>
# Alle Meldungen per Mail an diesen User schicken
MAILTO=xyz00

# bei einem Neustart des Servers soll der Monit Dienst gestartet werden
@reboot rm -f $HOME/var/run/* && /usr/bin/monit -c "$HOME/.monitrc"

# Fuenf Minuten nach Mitternacht
5 0 * * * $HOME/bin/daily.job >> $HOME/tmp/out 2>&1

# Um 14:15 an jedem Monatsersten
15 14 1 * * $HOME/bin/monthly

# 0:23, 2:23, 4:23, 6:23 ... 22:23
23 0-23/2 * * * echo "run 23 minutes after midn, 2am, 4am ..., everyday"

# Jeden Sonntag um 4:05
5 4 * * sun echo "run at 5 after 4 every sunday"

# Jeden Freitag und jeden 1. des Monats um 4:05
5 4 1 * 5 echo "run at 5 after 4 every friday and every 1st"
</syntaxhighlight>
Eine vollständige Beschreibung ist in der Manpage vorhanden: man 5 crontab.

=== Performancehinweise ===

Da Cronjobs einen erheblichen Teil der Systemlast ausmachen, sollen die folgenden Grundregeln beachtet werden:

* Jobs wenn möglich über Nacht laufen lassen.
* Priorität des Jobs mit nice reduzieren.
* Glatte Minutenwerte (0,5,10,15,20,...) vermeiden. Statt */10 kann man auch 7-57/10 verwenden.

=== Fehlerquellen ===

Manchmal funktioniert ein Script interaktiv in der Shell ohne Probleme, wird aber beim Eintrag in die Crontab anscheinend nicht ausgeführt. Eine Ursache kann die fehlerhafte Spezifikation der Ausführungszeit in der Crontab sein. Außerdem haben die Login-Shell und cron unterschiedliche Umgebungsvariablen. Neben dem aktuellen Arbeitsverzeichnis kann PATH unterschiedlich für cron und die Login-Shell sein.

Login-Shell: /usr/local/bin/su wird zuerst gefunden.

cron: /bin/su wird zuerst gefunden.

Wenn Cronjobs nicht ausgeführt werden, dann befinden sich die aufgerufenen Programme häufig auch in anderen Verzeichnissen.

----
[[Kategorie:HSDoku]]
[[Kategorie:Glossar]]

Cron

2024-12-03T01:45:33Z

Deg00-m.website:

Cron wird ersetzt durch [[Prozessmanagement mit systemd im Userspace#Zeitgesteuerte_Ausf%C3%BChrung_mit_systemd Systemd-Timer|Systemd Timer]]

{{Veraltet}}
{{Löschkandidat}}

Cron ist ein UNIX-Dienst, mit dem regelmäßige Jobs ausgeführt werden können, ohne dass der Benutzer dabei am System angemeldet sein muss. Dazu wird mit dem Kommando crontab die Konfiguration erstellt, aus der das System entnehmen kann, welches Kommando zu welcher Zeit auszuführen ist. Den Rest erledigt dann ein Systemprozess, der jede Minute überprüft, ob für einen User ein Job auszuführen ist.
=== Crontab ===
Mit crontab wird sowohl das Kommando zum Erstellen, Ändern und Löschen der eigenen Konfiguration als auch das dabei benutzte Dateiformat bezeichnet. Deshalb bekommt man die Beschreibung des Kommandos mit man 1 crontab und die Beschreibung des Formates mit man 5 crontab angezeigt.

Anzeigen der aktuellen Konfiguration:
<syntaxhighlight lang=shell>
crontab -l
</syntaxhighlight>
Löschen der kompletten Konfiguration:
<syntaxhighlight lang=shell>
crontab -r
</syntaxhighlight>
Ändern der Konfiguration:
<syntaxhighlight lang=shell>
crontab -e
</syntaxhighlight>
Crontab von einer Datei starten:
<syntaxhighlight lang=shell>
crontab myjob
</syntaxhighlight>
Der beim Editieren verwendete Editor wird durch die Umgebungsvariablen EDITOR und VISUAL bestimmt. Der Default ist vi. Alternativ kann man folgenden Weg gehen:
<syntaxhighlight lang=shell>
xyz00@hopi:~$crontab -l > myjobs
</syntaxhighlight>
Dann die Datei myjobs mit einem beliebigen Editor anpassen. Anschließend den cronjob von der Datei myjobs starten und die Datei löschen:
<syntaxhighlight lang=shell>
xyz00@hopi:~$ crontab myjobs

xyz00@hopi:~$ rm myjobs
</syntaxhighlight>
=== Dateiformat ===
Kommentare werden mit # am Zeilenanfang gekennzeichnet. Eine Befehlszeile in der Crontab-Datei besteht aus sechs durch Leerzeichen getrennten Feldern, wobei die ersten fünf Felder den Zeitpunkt der Ausführung festlegen und der Rest der Zeile das auszuführende Kommando bestimmt. Die ersten fünf Felder sind:
<syntaxhighlight lang=shell>
* Minute (0-59)
* Stunde (0-23)
* Tag des Monats (1-31)
* Monat (1-12 oder JAN-DEC)
* Wochentag (0-7; 0 und 7 entsprechen jeweils Sonntag oder SUN-SAT)
</syntaxhighlight>
Ein Stern * steht dabei für alle möglichen Werte eines Feldes. Die Felder können auch als Bereich (z.B. 2-4) und Liste (z.B. 3,6,8) angegeben werden. Auch lassen sich Schrittweiten für ein Feld angeben(z.B. */2). Dies kann auch kombiniert werden (z.B. 4-54/10).

Das dritte und fünfte Feld können beide den Tag der Ausführung bezeichnen. Sind beide gesetzt, also nicht *, so wird der Job ausgeführt, wenn einer der beiden Bedingungen erfüllt ist.

Statt einer Zeitangabe kann auch <code>@reboot</code> verwendet werden. In diesem Fall wird z.B. ein Dienst nach dem Neustart des Servers wieder gestartet.

=== Umgebungsvariablen ===
Folgende Umgebungsvariablen können in der crontab-Datei gesetzt werden:

<syntaxhighlight lang=ini line>
PWD

LOGNAME

SHLVL

SHELL

HOME

PATH

MAILTO
</syntaxhighlight>

=== Beispiel ===
<syntaxhighlight lang=shell line>
# Alle Meldungen per Mail an diesen User schicken
MAILTO=xyz00

# bei einem Neustart des Servers soll der Monit Dienst gestartet werden
@reboot rm -f $HOME/var/run/* && /usr/bin/monit -c "$HOME/.monitrc"

# Fuenf Minuten nach Mitternacht
5 0 * * * $HOME/bin/daily.job >> $HOME/tmp/out 2>&1

# Um 14:15 an jedem Monatsersten
15 14 1 * * $HOME/bin/monthly

# 0:23, 2:23, 4:23, 6:23 ... 22:23
23 0-23/2 * * * echo "run 23 minutes after midn, 2am, 4am ..., everyday"

# Jeden Sonntag um 4:05
5 4 * * sun echo "run at 5 after 4 every sunday"

# Jeden Freitag und jeden 1. des Monats um 4:05
5 4 1 * 5 echo "run at 5 after 4 every friday and every 1st"
</syntaxhighlight>
Eine vollständige Beschreibung ist in der Manpage vorhanden: man 5 crontab.

=== Performancehinweise ===

Da Cronjobs einen erheblichen Teil der Systemlast ausmachen, sollen die folgenden Grundregeln beachtet werden:

* Jobs wenn möglich über Nacht laufen lassen.
* Priorität des Jobs mit nice reduzieren.
* Glatte Minutenwerte (0,5,10,15,20,...) vermeiden. Statt */10 kann man auch 7-57/10 verwenden.

=== Fehlerquellen ===

Manchmal funktioniert ein Script interaktiv in der Shell ohne Probleme, wird aber beim Eintrag in die Crontab anscheinend nicht ausgeführt. Eine Ursache kann die fehlerhafte Spezifikation der Ausführungszeit in der Crontab sein. Außerdem haben die Login-Shell und cron unterschiedliche Umgebungsvariablen. Neben dem aktuellen Arbeitsverzeichnis kann PATH unterschiedlich für cron und die Login-Shell sein.

Login-Shell: /usr/local/bin/su wird zuerst gefunden.

cron: /bin/su wird zuerst gefunden.

Wenn Cronjobs nicht ausgeführt werden, dann befinden sich die aufgerufenen Programme häufig auch in anderen Verzeichnissen.

----
[[Kategorie:HSDoku]]
[[Kategorie:Glossar]]

Cron

2024-12-03T01:42:21Z

Deg00-m.website:

{{Veraltet}}
{{Löschkandidat}}

Cron wird ersetzt durch [https://wiki.hostsharing.net/index.php?title=Prozessmanagement_mit_systemd_im_Userspace#Zeitgesteuerte_Ausf%C3%BChrung_mit_systemd Systemd-Timer]

Cron ist ein UNIX-Dienst, mit dem regelmäßige Jobs ausgeführt werden können, ohne dass der Benutzer dabei am System angemeldet sein muss. Dazu wird mit dem Kommando crontab die Konfiguration erstellt, aus der das System entnehmen kann, welches Kommando zu welcher Zeit auszuführen ist. Den Rest erledigt dann ein Systemprozess, der jede Minute überprüft, ob für einen User ein Job auszuführen ist.
=== Crontab ===
Mit crontab wird sowohl das Kommando zum Erstellen, Ändern und Löschen der eigenen Konfiguration als auch das dabei benutzte Dateiformat bezeichnet. Deshalb bekommt man die Beschreibung des Kommandos mit man 1 crontab und die Beschreibung des Formates mit man 5 crontab angezeigt.

Anzeigen der aktuellen Konfiguration:
<syntaxhighlight lang=shell>
crontab -l
</syntaxhighlight>
Löschen der kompletten Konfiguration:
<syntaxhighlight lang=shell>
crontab -r
</syntaxhighlight>
Ändern der Konfiguration:
<syntaxhighlight lang=shell>
crontab -e
</syntaxhighlight>
Crontab von einer Datei starten:
<syntaxhighlight lang=shell>
crontab myjob
</syntaxhighlight>
Der beim Editieren verwendete Editor wird durch die Umgebungsvariablen EDITOR und VISUAL bestimmt. Der Default ist vi. Alternativ kann man folgenden Weg gehen:
<syntaxhighlight lang=shell>
xyz00@hopi:~$crontab -l > myjobs
</syntaxhighlight>
Dann die Datei myjobs mit einem beliebigen Editor anpassen. Anschließend den cronjob von der Datei myjobs starten und die Datei löschen:
<syntaxhighlight lang=shell>
xyz00@hopi:~$ crontab myjobs

xyz00@hopi:~$ rm myjobs
</syntaxhighlight>
=== Dateiformat ===
Kommentare werden mit # am Zeilenanfang gekennzeichnet. Eine Befehlszeile in der Crontab-Datei besteht aus sechs durch Leerzeichen getrennten Feldern, wobei die ersten fünf Felder den Zeitpunkt der Ausführung festlegen und der Rest der Zeile das auszuführende Kommando bestimmt. Die ersten fünf Felder sind:
<syntaxhighlight lang=shell>
* Minute (0-59)
* Stunde (0-23)
* Tag des Monats (1-31)
* Monat (1-12 oder JAN-DEC)
* Wochentag (0-7; 0 und 7 entsprechen jeweils Sonntag oder SUN-SAT)
</syntaxhighlight>
Ein Stern * steht dabei für alle möglichen Werte eines Feldes. Die Felder können auch als Bereich (z.B. 2-4) und Liste (z.B. 3,6,8) angegeben werden. Auch lassen sich Schrittweiten für ein Feld angeben(z.B. */2). Dies kann auch kombiniert werden (z.B. 4-54/10).

Das dritte und fünfte Feld können beide den Tag der Ausführung bezeichnen. Sind beide gesetzt, also nicht *, so wird der Job ausgeführt, wenn einer der beiden Bedingungen erfüllt ist.

Statt einer Zeitangabe kann auch <code>@reboot</code> verwendet werden. In diesem Fall wird z.B. ein Dienst nach dem Neustart des Servers wieder gestartet.

=== Umgebungsvariablen ===
Folgende Umgebungsvariablen können in der crontab-Datei gesetzt werden:

<syntaxhighlight lang=ini line>
PWD

LOGNAME

SHLVL

SHELL

HOME

PATH

MAILTO
</syntaxhighlight>

=== Beispiel ===
<syntaxhighlight lang=shell line>
# Alle Meldungen per Mail an diesen User schicken
MAILTO=xyz00

# bei einem Neustart des Servers soll der Monit Dienst gestartet werden
@reboot rm -f $HOME/var/run/* && /usr/bin/monit -c "$HOME/.monitrc"

# Fuenf Minuten nach Mitternacht
5 0 * * * $HOME/bin/daily.job >> $HOME/tmp/out 2>&1

# Um 14:15 an jedem Monatsersten
15 14 1 * * $HOME/bin/monthly

# 0:23, 2:23, 4:23, 6:23 ... 22:23
23 0-23/2 * * * echo "run 23 minutes after midn, 2am, 4am ..., everyday"

# Jeden Sonntag um 4:05
5 4 * * sun echo "run at 5 after 4 every sunday"

# Jeden Freitag und jeden 1. des Monats um 4:05
5 4 1 * 5 echo "run at 5 after 4 every friday and every 1st"
</syntaxhighlight>
Eine vollständige Beschreibung ist in der Manpage vorhanden: man 5 crontab.

=== Performancehinweise ===

Da Cronjobs einen erheblichen Teil der Systemlast ausmachen, sollen die folgenden Grundregeln beachtet werden:

* Jobs wenn möglich über Nacht laufen lassen.
* Priorität des Jobs mit nice reduzieren.
* Glatte Minutenwerte (0,5,10,15,20,...) vermeiden. Statt */10 kann man auch 7-57/10 verwenden.

=== Fehlerquellen ===

Manchmal funktioniert ein Script interaktiv in der Shell ohne Probleme, wird aber beim Eintrag in die Crontab anscheinend nicht ausgeführt. Eine Ursache kann die fehlerhafte Spezifikation der Ausführungszeit in der Crontab sein. Außerdem haben die Login-Shell und cron unterschiedliche Umgebungsvariablen. Neben dem aktuellen Arbeitsverzeichnis kann PATH unterschiedlich für cron und die Login-Shell sein.

Login-Shell: /usr/local/bin/su wird zuerst gefunden.

cron: /bin/su wird zuerst gefunden.

Wenn Cronjobs nicht ausgeführt werden, dann befinden sich die aufgerufenen Programme häufig auch in anderen Verzeichnissen.

----
[[Kategorie:HSDoku]]
[[Kategorie:Glossar]]

Diskussion:Cron

2024-12-03T01:41:02Z

Deg00-m.website:

Crontabs werden ersetzt durch Systemd Timers, die Seite sollte also gelöscht werden, wenn Cron weg ist. --[[Benutzer:Deg00-m.website|ChristofT]] ([[Benutzer Diskussion:Deg00-m.website|Diskussion]]) 01:58, 3. Dez. 2024 (CET)

Prozessmanagement mit systemd im Userspace

2024-12-03T01:18:05Z

Deg00-m.website: /* Einrichten des »timer-files« */

== Über systemd ==
''systemd'' ist seit einigen Jahren das Init-System aller gängigen Linux-Distributionen. Der ''init''-Prozess hat im laufenden System die Prozessnummer "1". Er verwaltet alle anderen Prozesse als Kind-Prozesse.

Auch ein normaler Account ohne besondere Privilegien kann systemd nutzen, um Prozesse im Userspace zu starten und zu kontrollieren. Auf der Hostsharing Managed Operations Platform kann jeder Account mit einer gültigen Login-Shell Dienste unter der Kontrolle von systemd starten.

Im Hostsharing Managed Webspace ist es zwingend, systemd als Prozessmonitor für eigene Serverdienste zu nutzen; auf einem Hostsharing Managed Server ist es die empfohlene Vorgehensweise ("Best practice").

== Eigene Serverdienste mit systemd ==

Die systemd-Konfiguration wird in dem Verzeichnis des Benutzers eingerichtet, unter dem die Anwendung laufen soll.
In diesem Beispiel soll die Anwendung GotoSocial unter der Benutzerkennung von ''xyz00-service'' laufen.
Nachdem die Anwendung im Benutzer ''xyz00-service'' installiert wurde, erfolgt nun die Konfiguration von systemd in demselben Benutzer.

Benutzer, die systemd steuern sollen, müssen über eine gültige Shell verfügen, so dass man sich per ''ssh'' oder vom Paketadmin mit dem Befehl ''sudo -i -u xyz00-service'' anmelden kann.
Die Umgebungsvariable ''XDG_RUNTIME_DIR'' sollte im Environment des Users gesetzt sein, wenn man erfolgreich angemeldet ist. Das testet man mit

<syntaxhighlight lang="bash">
echo $XDG_RUNTIME_DIR
</syntaxhighlight>

Die Ausgabe sollte sein:

<syntaxhighlight lang="bash">
xyz00-service@h01:~$ echo $XDG_RUNTIME_DIR
/run/user/112345
xyz00-service@h01:~$
</syntaxhighlight>

Dabei wird statt ''112345'' eine andere Zahl erscheinen. Diese Zahl ist die numerische User-Id des Users ''xyz00-service'' im System.

=== systemd Units ===

Die systemd-Units für einen User werden im Verzeichnis ''$HOME/.config/systemd/user/'' verwaltet. Dieser Pfad ist fest vorgegeben. Der Pfad muss bei einem neuen Benutzer angelegt werden.

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

In diesem Verzeichnis wird für jeden Service eine Datei mit der Endung ''.service'' angelegt. In diesem Beispiel ist dies eine GotoSocial-Instanz. GotoSocial ist ein einfaches Binärprogramm, das in der Programmiersprache ''Go'' programmiert ist.

<syntaxhighlight lang="ini" line>
[Unit]
Description=GotoSocial Service
#After=my-redis.service

[Service]
Type=simple
WorkingDirectory=%h/gotosocial
Environment="PATH=/usr/local/bin:/usr/bin:/bin"
ExecStart=%h/gotosocial/gotosocial --config-path %h/gotosocial/config.yaml server start
StandardOutput=append:%h/var/gotosocial.log
StandardError=inherit
Restart=always
PrivateTmp=true

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

Folgende Eigenschaften sind einstellbar:

; After: Hier kann eingestellt werden, welcher Dienst bereits laufen muss, bevor dieser Dienst gestartet wird. Wenn GotoSocial eine Redis-Instanz benötigt, könnte das entsprechend eingestellt werden.
; Type=simple : ''simple'' ist die Voreinstellung und kann weggelassen werden. Evtl. braucht man auch ''forking'', wenn ein Dienst als Daemon im Hintergrund startet. Wenn man die Wahl hat, sollte man den Dienst immer im Vordergrund starten und nicht forken.
; WorkingDirectory : ist das Verzeichnis, in dem der Dienst gestartet wird. %h ist in dieser Datei eine Abkürzung für das Home-Verzeichnis des Users.
; Environment : Hier wird die Variable ''PATH'' definiert. Man kann mehrere Einträge des Namens ''Environment'' eintragen und bei Bedarf eine beliebige Anzahl von Environment-Variablen definieren.
; ExecStart : Das Programm, das als Dienst ausgeführt wird. Man kann eine komplette Kommandozeile angeben.
; StandardOutput : Eine Log-Datei, in die die Standardausgabe des laufenden Dienstes geschrieben wird.
; StandardError : Entsprechend zu ''StandardOutput''. Mit ''inherit'' wird die Datei von ''StandardOutput'' geerbt.
; Restart=always : Der Dienst soll grundsätzlich neu gestartet werden, wenn der Prozess unerwartet beendet wird.
; PrivateTmp=true : ''/tmp'' und ''/var/tmp'' werden temporär im Namespace gemountet, so dass sie nicht mit anderen Prozessen geteilt werden.
; WantedBy : sollte im Usermodus von systemd meistens ''default.target'' sein. Andere Targets sind z.B. ''base.target'' oder ''timers.target''. Für eine komplette Liste: <code>systemctl list-units --user --type=target</code>

==== RAM- und CPU-Limits ====

Auf Wunsch kann man die RAM- und CPU-Ressourcen für den Dienst begrenzen. Dazu trägt man weitere Eigenschaften im Abschnitt ''Service'' ein:

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

; MemoryHigh : Weiches RAM-Limit, das ggf. überschritten werden kann, wenn es unvermeidlich ist.
; MemoryMax : Hartes, absolutes RAM-Limit.
; CPUQuota : Maximale Belegung eines CPU-Threads in Prozent. Werte über 100% sind sinnvoll, wenn mehr als ein CPU-Thread verfügbar ist.

==== Ausführliche Dokumentation der Direktiven ====
Eine ausführliche Dokumentation der Direktiven findet sich hier:

https://www.freedesktop.org/software/systemd/man/latest/systemd.directives.html

=== systemd Unit starten und stoppen ===

Nachdem die systemd-Unit definiert ist, soll der Dienst gestartet werden.
Für die Verwaltung des Dienstes stehen die folgenden Kommandos zur Verfügung:

==== Reload ====

<syntaxhighlight lang="bash">
systemctl --user daemon-reload
</syntaxhighlight>

Die Konfigurationsdateien im Verzeichnis ''$HOME/.config/systemd/user/'' werden neu eingelesen. Dieses Kommando ist nach jeder Änderung einer ''.service''-Datei nötig.

==== Start und Stopp ====

<syntaxhighlight lang="bash">
systemctl --user start gotosocial.service
</syntaxhighlight>

bzw.

<syntaxhighlight lang="bash">
systemctl --user stop gotosocial.service
</syntaxhighlight>

sind die Kommandos zum Starten und Beenden des Dienstes.

==== Enable und Disable ====

Wenn ein Dienst nach einem Reboot des Servers automatisch gestartet werden soll, muss er aktiviert werden:

<syntaxhighlight lang="bash">
systemctl --user enable gotosocial.service
</syntaxhighlight>

Wenn er nicht automatisch nach einem Reboot starten soll, muss der Dienst entsprechend deaktiviert werden:

<syntaxhighlight lang="bash">
systemctl --user disable gotosocial.service
</syntaxhighlight>

sind die Kommandos, die den Dienst für einen Reboot des Servers aktivieren bzw. deaktivieren.

==== Status ====

<syntaxhighlight lang="bash">
systemctl --user status
</syntaxhighlight>

oder

<syntaxhighlight lang="bash">
systemctl --user status gotosocial.service
</syntaxhighlight>

zeigen den Status aller Dienste des Users bzw. eines bestimmten Dienstes an.

== Zeitgesteuerte Ausführung mit systemd ==

Mit Hilfe von systemd können auch wiederkehrende Aufgaben zeitgesteuert automatisiert werden.
Cronjobs, die früher für solche Zwecke benutzt wurden, lassen sich also durch systemd Units ersetzen.
Neben dem »service-file« wird dazu eine weitere Unit, nämlich ein »timer-file«, mit der Endung ».timer« angelegt und aktiviert.

=== Einrichten des »service-files« ===

<syntaxhighlight lang=bash>
$ cat $HOME/.config/systemd/user/my-cleanup.service

[Unit]
Description=My Cleanup Service

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

=== Testen ===

<syntaxhighlight lang=bash>
$ systemctl --user start my-cleanup.service
</syntaxhighlight>

=== Einrichten des »timer-files« ===

<syntaxhighlight lang=bash>
$ cat $HOME/.config/systemd/user/my-cleanup.timer

[Unit]
Description=Daily My Cleanup Timer

[Timer]
OnCalendar=daily
RandomizedDelaySec=3600
Persistent=true

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

Der RandomizedDelay bewirkt, dass der Prozess zufällig im Zeitraum einer Stunde gestartet wird.
Wenn mehrere Timer-Aufgaben täglich (daily) auf einem System gestartet werden, verhindert diese Einstellung, dass alle Prozesse exakt zur gleichen Zeit starten und das System eventuell überlasten.

Die zufällige Verzögerung sollte in einem sinnvollen Verhältnis zur Frequenz der Zeitsteuerung erfolgen.
Bei täglich ausgeführten Aufgaben mag eine Stunde (3600 Sekunden) sinnvoll sein.
Bei Aufgaben, die stündlich ausgeführt werden, wählt man eine kürzere Verzögerung, zum Beispiel fünf Minuten.

Die Syntax der Datei lässt sich mit diesem Befehl prüfen:

<syntaxhighlight lang=bash>
systemd-analyze verify $HOME/.config/systemd/user/my-cleanup.timer
</syntaxhighlight>

Einzelne Kalendereinträge lassen sich mit Erklärung ausgeben:

<syntaxhighlight lang=bash>
systemd-analyze calendar '*:0/2'
</syntaxhighlight>

Eine ausführliche Dokumentation der Direktiven findet sich hier:

https://www.freedesktop.org/software/systemd/man/latest/systemd.timer.html

=== Aktivieren der zeitgesteuerten Ausführung ===

Der Timer muss noch aktiviert und gestartet werden:

<syntaxhighlight lang=bash>
$ systemctl --user enable my-cleanup.timer --now
</syntaxhighlight>

== RAM Kontingent eines Webspace ==

Den aktuell belegten RAM eines Webspace ''xyz00'' kann man sich mit dem Befehl

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

ansehen.

Etwa in der fünften Zeile der Ausgabe findet man eine Angabe der Form:

<syntaxhighlight lang="bash">
Memory: 58.4M (max: 14.8G available: 14.8G)
</syntaxhighlight>

Hier sind aktuell 58,4 Megabyte RAM genutzt, es sind 14,8 Gigabyte RAM für den Webspace verfügbar. Der verfügbare RAM ist das gebuchte Kontingent. Das gebuchte Kontigent wird im Shared Hosting deutlich kleiner sein.

Das RAM Kontingent wird in Schritten von jeweils 128 Ḿegabyte gebucht. Änderungen des RAM Kontingents für einen Webspace nimmt der Service unter [mailto:service@hostsharing.net service@hostsharing.net] entgegen, wie es bei anderen Paketoptionen die Vorgehensweise ist.

= weiterführende Links =

* https://www.freedesktop.org/software/systemd/man/latest/systemd.directives.html
* https://www.freedesktop.org/software/systemd/man/latest/systemd.timer.html
* https://documentation.suse.com/smart/systems-management/html/systemd-working-with-timers/index.html#systemd-timer-catchup
* https://wiki.archlinux.org/title/Systemd/Timers#As_a_cron_replacement

----
[[Kategorie:systemd]]
[[Kategorie:Eigene Daemons]]

Vorlage:HSDoku-Links

2024-12-03T01:03:59Z

Deg00-m.website: Systemd Prozessmanagement ersetzt Cron

<noinclude>
Diese Vorlage dient dazu, eine Leiste mit Toplinks für die HS-Doku anzuzeigen:

{{HSDoku-Links}}

Diese Leiste ist ein Ersatz für die Toplinks der alten HS-Doku und funktioniert zusammen mit dem Konzept der Weiterführenden Links. Siehe [[Hostsharing_Wiki_Konventionen#Weiterf.C3.BChrende_Links | Konventionen]]. Sie wirkt wie ein Portal, sie sollte nur auf der Hauptseite und den Seiten zu finden sein, auf die sie direkt verlinkt. Wenn ich als Betrachter sie sehe, weiß ich, dass ich "ganz oben" bin. Man erkennt auch, dass sie nur auf den Seiten richtig funktioniert, auf die sie zeigt, weil dann der entsprechende Link schwarz wird und nicht mehr aufzurufen ist.

== Verwendung ==
Gib einfach am Anfang der Seite folgendes ein:

<nowiki>{{HSDoku-Links}}</nowiki>
[[Kategorie:Vorlage]]
[[Kategorie:Navigationsleiste]]
</noinclude><includeonly>{{Navigationsleiste
|TITEL= [[Hostsharing Dokumentation – die Hauptbereiche]]
|INHALT=
[[Einstieg bei Hostsharing|Einstieg]] |
[[Hsadmin]] |
[[Pakete]] |
[[User]] |
[[Domains]] |
[[Prozessmanagement mit systemd im Userspace|Systemd]] |
[[Logging]] |
[[E-Mail]] |
[[WWW]]<br>
[[Datenbanken]] |
[[Backup & Restore]] |
[[:Kategorie:Installationsanleitungen|Installationsanleitungen]] |
[[FAQ]] |
[[Bugtracker]]
}}</includeonly>

Cron

2024-12-03T01:00:48Z

Deg00-m.website:

{{Veraltet}}

Cron wird ersetzt durch [https://wiki.hostsharing.net/index.php?title=Prozessmanagement_mit_systemd_im_Userspace#Zeitgesteuerte_Ausf%C3%BChrung_mit_systemd Systemd-Timer]

Cron ist ein UNIX-Dienst, mit dem regelmäßige Jobs ausgeführt werden können, ohne dass der Benutzer dabei am System angemeldet sein muss. Dazu wird mit dem Kommando crontab die Konfiguration erstellt, aus der das System entnehmen kann, welches Kommando zu welcher Zeit auszuführen ist. Den Rest erledigt dann ein Systemprozess, der jede Minute überprüft, ob für einen User ein Job auszuführen ist.
=== Crontab ===
Mit crontab wird sowohl das Kommando zum Erstellen, Ändern und Löschen der eigenen Konfiguration als auch das dabei benutzte Dateiformat bezeichnet. Deshalb bekommt man die Beschreibung des Kommandos mit man 1 crontab und die Beschreibung des Formates mit man 5 crontab angezeigt.

Anzeigen der aktuellen Konfiguration:
<syntaxhighlight lang=shell>
crontab -l
</syntaxhighlight>
Löschen der kompletten Konfiguration:
<syntaxhighlight lang=shell>
crontab -r
</syntaxhighlight>
Ändern der Konfiguration:
<syntaxhighlight lang=shell>
crontab -e
</syntaxhighlight>
Crontab von einer Datei starten:
<syntaxhighlight lang=shell>
crontab myjob
</syntaxhighlight>
Der beim Editieren verwendete Editor wird durch die Umgebungsvariablen EDITOR und VISUAL bestimmt. Der Default ist vi. Alternativ kann man folgenden Weg gehen:
<syntaxhighlight lang=shell>
xyz00@hopi:~$crontab -l > myjobs
</syntaxhighlight>
Dann die Datei myjobs mit einem beliebigen Editor anpassen. Anschließend den cronjob von der Datei myjobs starten und die Datei löschen:
<syntaxhighlight lang=shell>
xyz00@hopi:~$ crontab myjobs

xyz00@hopi:~$ rm myjobs
</syntaxhighlight>
=== Dateiformat ===
Kommentare werden mit # am Zeilenanfang gekennzeichnet. Eine Befehlszeile in der Crontab-Datei besteht aus sechs durch Leerzeichen getrennten Feldern, wobei die ersten fünf Felder den Zeitpunkt der Ausführung festlegen und der Rest der Zeile das auszuführende Kommando bestimmt. Die ersten fünf Felder sind:
<syntaxhighlight lang=shell>
* Minute (0-59)
* Stunde (0-23)
* Tag des Monats (1-31)
* Monat (1-12 oder JAN-DEC)
* Wochentag (0-7; 0 und 7 entsprechen jeweils Sonntag oder SUN-SAT)
</syntaxhighlight>
Ein Stern * steht dabei für alle möglichen Werte eines Feldes. Die Felder können auch als Bereich (z.B. 2-4) und Liste (z.B. 3,6,8) angegeben werden. Auch lassen sich Schrittweiten für ein Feld angeben(z.B. */2). Dies kann auch kombiniert werden (z.B. 4-54/10).

Das dritte und fünfte Feld können beide den Tag der Ausführung bezeichnen. Sind beide gesetzt, also nicht *, so wird der Job ausgeführt, wenn einer der beiden Bedingungen erfüllt ist.

Statt einer Zeitangabe kann auch <code>@reboot</code> verwendet werden. In diesem Fall wird z.B. ein Dienst nach dem Neustart des Servers wieder gestartet.

=== Umgebungsvariablen ===
Folgende Umgebungsvariablen können in der crontab-Datei gesetzt werden:

<syntaxhighlight lang=ini line>
PWD

LOGNAME

SHLVL

SHELL

HOME

PATH

MAILTO
</syntaxhighlight>

=== Beispiel ===
<syntaxhighlight lang=shell line>
# Alle Meldungen per Mail an diesen User schicken
MAILTO=xyz00

# bei einem Neustart des Servers soll der Monit Dienst gestartet werden
@reboot rm -f $HOME/var/run/* && /usr/bin/monit -c "$HOME/.monitrc"

# Fuenf Minuten nach Mitternacht
5 0 * * * $HOME/bin/daily.job >> $HOME/tmp/out 2>&1

# Um 14:15 an jedem Monatsersten
15 14 1 * * $HOME/bin/monthly

# 0:23, 2:23, 4:23, 6:23 ... 22:23
23 0-23/2 * * * echo "run 23 minutes after midn, 2am, 4am ..., everyday"

# Jeden Sonntag um 4:05
5 4 * * sun echo "run at 5 after 4 every sunday"

# Jeden Freitag und jeden 1. des Monats um 4:05
5 4 1 * 5 echo "run at 5 after 4 every friday and every 1st"
</syntaxhighlight>
Eine vollständige Beschreibung ist in der Manpage vorhanden: man 5 crontab.

=== Performancehinweise ===

Da Cronjobs einen erheblichen Teil der Systemlast ausmachen, sollen die folgenden Grundregeln beachtet werden:

* Jobs wenn möglich über Nacht laufen lassen.
* Priorität des Jobs mit nice reduzieren.
* Glatte Minutenwerte (0,5,10,15,20,...) vermeiden. Statt */10 kann man auch 7-57/10 verwenden.

=== Fehlerquellen ===

Manchmal funktioniert ein Script interaktiv in der Shell ohne Probleme, wird aber beim Eintrag in die Crontab anscheinend nicht ausgeführt. Eine Ursache kann die fehlerhafte Spezifikation der Ausführungszeit in der Crontab sein. Außerdem haben die Login-Shell und cron unterschiedliche Umgebungsvariablen. Neben dem aktuellen Arbeitsverzeichnis kann PATH unterschiedlich für cron und die Login-Shell sein.

Login-Shell: /usr/local/bin/su wird zuerst gefunden.

cron: /bin/su wird zuerst gefunden.

Wenn Cronjobs nicht ausgeführt werden, dann befinden sich die aufgerufenen Programme häufig auch in anderen Verzeichnissen.

----
[[Kategorie:HSDoku]]
[[Kategorie:Glossar]]

Diskussion:Cron

2024-12-03T00:58:32Z

Deg00-m.website: Die Seite wurde neu angelegt: „Crontabs werden ersetzt durch Systemd Timers --~~~~“

Crontabs werden ersetzt durch Systemd Timers --[[Benutzer:Deg00-m.website|ChristofT]] ([[Benutzer Diskussion:Deg00-m.website|Diskussion]]) 01:58, 3. Dez. 2024 (CET)

Cron

2024-12-03T00:57:41Z

Deg00-m.website: Cron ist veraltet

{{Veraltet}}

Cron ist ein UNIX-Dienst, mit dem regelmäßige Jobs ausgeführt werden können, ohne dass der Benutzer dabei am System angemeldet sein muss. Dazu wird mit dem Kommando crontab die Konfiguration erstellt, aus der das System entnehmen kann, welches Kommando zu welcher Zeit auszuführen ist. Den Rest erledigt dann ein Systemprozess, der jede Minute überprüft, ob für einen User ein Job auszuführen ist.
=== Crontab ===
Mit crontab wird sowohl das Kommando zum Erstellen, Ändern und Löschen der eigenen Konfiguration als auch das dabei benutzte Dateiformat bezeichnet. Deshalb bekommt man die Beschreibung des Kommandos mit man 1 crontab und die Beschreibung des Formates mit man 5 crontab angezeigt.

Anzeigen der aktuellen Konfiguration:
<syntaxhighlight lang=shell>
crontab -l
</syntaxhighlight>
Löschen der kompletten Konfiguration:
<syntaxhighlight lang=shell>
crontab -r
</syntaxhighlight>
Ändern der Konfiguration:
<syntaxhighlight lang=shell>
crontab -e
</syntaxhighlight>
Crontab von einer Datei starten:
<syntaxhighlight lang=shell>
crontab myjob
</syntaxhighlight>
Der beim Editieren verwendete Editor wird durch die Umgebungsvariablen EDITOR und VISUAL bestimmt. Der Default ist vi. Alternativ kann man folgenden Weg gehen:
<syntaxhighlight lang=shell>
xyz00@hopi:~$crontab -l > myjobs
</syntaxhighlight>
Dann die Datei myjobs mit einem beliebigen Editor anpassen. Anschließend den cronjob von der Datei myjobs starten und die Datei löschen:
<syntaxhighlight lang=shell>
xyz00@hopi:~$ crontab myjobs

xyz00@hopi:~$ rm myjobs
</syntaxhighlight>
=== Dateiformat ===
Kommentare werden mit # am Zeilenanfang gekennzeichnet. Eine Befehlszeile in der Crontab-Datei besteht aus sechs durch Leerzeichen getrennten Feldern, wobei die ersten fünf Felder den Zeitpunkt der Ausführung festlegen und der Rest der Zeile das auszuführende Kommando bestimmt. Die ersten fünf Felder sind:
<syntaxhighlight lang=shell>
* Minute (0-59)
* Stunde (0-23)
* Tag des Monats (1-31)
* Monat (1-12 oder JAN-DEC)
* Wochentag (0-7; 0 und 7 entsprechen jeweils Sonntag oder SUN-SAT)
</syntaxhighlight>
Ein Stern * steht dabei für alle möglichen Werte eines Feldes. Die Felder können auch als Bereich (z.B. 2-4) und Liste (z.B. 3,6,8) angegeben werden. Auch lassen sich Schrittweiten für ein Feld angeben(z.B. */2). Dies kann auch kombiniert werden (z.B. 4-54/10).

Das dritte und fünfte Feld können beide den Tag der Ausführung bezeichnen. Sind beide gesetzt, also nicht *, so wird der Job ausgeführt, wenn einer der beiden Bedingungen erfüllt ist.

Statt einer Zeitangabe kann auch <code>@reboot</code> verwendet werden. In diesem Fall wird z.B. ein Dienst nach dem Neustart des Servers wieder gestartet.

=== Umgebungsvariablen ===
Folgende Umgebungsvariablen können in der crontab-Datei gesetzt werden:

<syntaxhighlight lang=ini line>
PWD

LOGNAME

SHLVL

SHELL

HOME

PATH

MAILTO
</syntaxhighlight>

=== Beispiel ===
<syntaxhighlight lang=shell line>
# Alle Meldungen per Mail an diesen User schicken
MAILTO=xyz00

# bei einem Neustart des Servers soll der Monit Dienst gestartet werden
@reboot rm -f $HOME/var/run/* && /usr/bin/monit -c "$HOME/.monitrc"

# Fuenf Minuten nach Mitternacht
5 0 * * * $HOME/bin/daily.job >> $HOME/tmp/out 2>&1

# Um 14:15 an jedem Monatsersten
15 14 1 * * $HOME/bin/monthly

# 0:23, 2:23, 4:23, 6:23 ... 22:23
23 0-23/2 * * * echo "run 23 minutes after midn, 2am, 4am ..., everyday"

# Jeden Sonntag um 4:05
5 4 * * sun echo "run at 5 after 4 every sunday"

# Jeden Freitag und jeden 1. des Monats um 4:05
5 4 1 * 5 echo "run at 5 after 4 every friday and every 1st"
</syntaxhighlight>
Eine vollständige Beschreibung ist in der Manpage vorhanden: man 5 crontab.

=== Performancehinweise ===

Da Cronjobs einen erheblichen Teil der Systemlast ausmachen, sollen die folgenden Grundregeln beachtet werden:

* Jobs wenn möglich über Nacht laufen lassen.
* Priorität des Jobs mit nice reduzieren.
* Glatte Minutenwerte (0,5,10,15,20,...) vermeiden. Statt */10 kann man auch 7-57/10 verwenden.

=== Fehlerquellen ===

Manchmal funktioniert ein Script interaktiv in der Shell ohne Probleme, wird aber beim Eintrag in die Crontab anscheinend nicht ausgeführt. Eine Ursache kann die fehlerhafte Spezifikation der Ausführungszeit in der Crontab sein. Außerdem haben die Login-Shell und cron unterschiedliche Umgebungsvariablen. Neben dem aktuellen Arbeitsverzeichnis kann PATH unterschiedlich für cron und die Login-Shell sein.

Login-Shell: /usr/local/bin/su wird zuerst gefunden.

cron: /bin/su wird zuerst gefunden.

Wenn Cronjobs nicht ausgeführt werden, dann befinden sich die aufgerufenen Programme häufig auch in anderen Verzeichnissen.

----
[[Kategorie:HSDoku]]
[[Kategorie:Glossar]]

Umstellung von Daemon-Diensten auf systemd

2024-12-02T22:22:58Z

Deg00-m.website: /* Beispiel: Nextcloud Hintergrund Job */

== Anlass dieser Anleitung ==

Ab November 2024 unterstützt die Managed Plattform ein RAM Kontingent pro Managed Webspace. Mitglieder buchen für ihre Webspaces jeweils ein RAM Kontingent in Schritten von jeweils 128 Megabyte. Das unterstützt uns besser bei der verursachergerechten Verteilung der Hardwarekosten, als es vorher mit einer Pauschale pro Serverdienst der Fall war. Änderungen des RAM Kontingents für einen Webspace nimmt der Service unter [mailto:service@hostsharing.net service@hostsharing.net] entgegen, wie es bei anderen Paketoptionen die Vorgehensweise ist.

Damit die RAM Kontingente funktionieren, müssen im Managed Webspace alle Anwendungen, die im Userspace laufen, auf systemd umgestellt werden. Das betrifft Anwendungen, die bisher über z.B. cronjob, supervisor oder monit gestartet wurden.

Siehe auch unsere [[Systemd im Userspace]] Dokumentation.

== Praktische Umstellung ==

Für eine Übergangsphase steht jedem Managed Webspace genügend RAM zur Verfügung, um eigene Serverdienste zu starten.
Nach der Umstellung aller Dienste auf systemd wird dann das tatsächlich benötigte RAM-Kontingent ermittelt und gebucht.

=== cronjob ===

==== Rückblick auf Bearbeitung von Cronjobs ====
Mit dem Befehl <code>crontab -l</code> können die eigenen Cronjobs aufgelistet werden.

Mit dem Befehl <code>crontab -e</code> bearbeiten wir unsere Hintergrundjobs.

Wenn am Anfang einer Zeile das Rautezeichen # eingesetzt wird, dann ist die Zeile deaktiviert.

Auf der Seite [[Cron]] werden weitere Einzelheiten beschrieben.

==== Umstellung auf systemd Timer ====

Hier ist eine schöne Übersicht mit Beispielen: https://documentation.suse.com/smart/systems-management/html/systemd-working-with-timers/index.html#systemd-timer-catchup

==== Beispiel: Nextcloud Hintergrund Job ====

Hier haben wir ein Beispiel für einen Nextcloud Hintergrund Job, der alle 5 Minuten läuft, und in der crontab eingetragen ist:

<syntaxhighlight lang="crontab">
*/5 * * * * /usr/bin/php $HOME/nextcloud/cron.php
</syntaxhighlight>

Wir deaktivieren diesen Cronjob, in dem wir ein # vor die Zeile setzen, wie oben beschrieben.

Nun muss ggfs. das Verzeichnis für systemd angelegt werden:

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

Nun wird die Datei für den oneshot Dienst angelegt:

<syntaxhighlight lang="bash">
nano $HOME/.config/systemd/user/nextcloud-job.service
</syntaxhighlight>

mit diesem Inhalt:

<syntaxhighlight lang="ini">
[Unit]
Description=Nextcloud Hintergrundjob

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

{{Textkasten|gelb|Beachte|Statt $HOME muss %h benutzt werden!}}

Nun wird die Datei für den Timer angelegt:

<syntaxhighlight lang="bash">
nano $HOME/.config/systemd/user/nextcloud-job.timer
</syntaxhighlight>

mit diesem Inhalt:

<syntaxhighlight lang="ini">
[Unit]
Description=Timer für Nextcloud Hintergrundjob

[Timer]
OnCalendar=*:0/5
RandomizedDelaySec=30

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

Nun soll der Timer noch aktiviert und gestartet werden:

<syntaxhighlight lang="bash">
systemctl --user daemon-reload
systemctl --user enable nextcloud-job.timer --now
</syntaxhighlight>

==== Beispiel: Logrotate aufrufen ====

Hier haben wir ein Beispiel für einen Logrotate Job, der einmal in der Nacht aufgerufen wird, und in der crontab eingetragen ist:

<syntaxhighlight lang="crontab">
13 1 * * * /usr/sbin/logrotate -s $HOME/.logrotate.state $HOME/.logrotate
</syntaxhighlight>

Wir deaktivieren diesen Cronjob, in dem wir ein # vor die Zeile setzen, wie oben beschrieben.

Nun muss ggfs. das Verzeichnis für systemd angelegt werden:

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

Nun wird die Datei für den oneshot Dienst angelegt:

<syntaxhighlight lang="bash">
nano $HOME/.config/systemd/user/logrotate-job.service
</syntaxhighlight>

mit diesem Inhalt:

<syntaxhighlight lang="ini">
[Unit]
Description=Logrotate Job

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

{{Textkasten|gelb|Beachte|Statt $HOME muss %h benutzt werden!}}

Nun wird die Datei für den Timer angelegt:

<syntaxhighlight lang="bash">
nano $HOME/.config/systemd/user/logrotate-job.timer
</syntaxhighlight>

mit diesem Inhalt:

<syntaxhighlight lang="ini">
[Unit]
Description=Timer für Logrotate Job

[Timer]
OnCalendar=01:13
RandomizedDelaySec=300
Persistent=true

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

Nun soll der Timer noch aktiviert und gestartet werden:

<syntaxhighlight lang="bash">
systemctl --user daemon-reload
systemctl --user enable logrotate-job.timer --now
</syntaxhighlight>

=== Monit ===

==== Beispiel: Redis ====

Hier haben wir eine Datei <code>.monitrc</code>, mit der ein Redis Dienst betrieben wird:

<syntaxhighlight lang="monit">
set daemon 60
with start delay 120
set logfile /home/pacs/xyz00/nextcloud/var/monit.log
set idfile /home/pacs/xyz00/nextcloud/var/monit.id
set statefile /home/pacs/xyz00/nextcloud/var/monit.state
set mailserver localhost
set mail-format { from: webmaster@example.org }
set alert webmaster@example.org
set httpd port 12345 address xyz00.hostsharing.net
allow monit:topsecret
check process redis with pidfile /home/pacs/xyz00/nextcloud/redis/var/redis-server.pid
start program "/usr/bin/redis-server /home/pacs/xyz00/nextcloud/redis/etc/redis.conf"
stop program "/bin/bash -c '/bin/kill $( cat /home/pacs/xyz00/nextcloud/redis/var/redis-server.pid )'"
</syntaxhighlight>

Der Start von monit nach einem Reboot des Servers wird verhindert, indem die entsprechende Zeile gelöscht wird:

<syntaxhighlight lang="bash">
crontab -e

entferne diese Zeile:
@reboot /usr/bin/monit -c $HOME/.monitrc
</syntaxhighlight>

Die Dienste werden gestoppt:

<syntaxhighlight lang="bash">
killall -u $USER -KILL monit
killall -u $USER -KILL redis-server
</syntaxhighlight>

Nun muss ggfs. das Verzeichnis für systemd angelegt werden:

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

Nun wird die Datei für den Redis Dienst angelegt:

<syntaxhighlight lang="bash">
nano $HOME/.config/systemd/user/redis.service
</syntaxhighlight>

<syntaxhighlight lang="ini">
[Unit]
Description=Redis Service
After=network-online.target

[Service]
WorkingDirectory=%h/redis/var
ExecStart=/usr/bin/redis-server %h/redis/etc/redis.conf
Restart=always
PrivateTmp=true
NoNewPrivileges=true
StandardOutput=append:%h/var/log/redis.log
StandardError=inherit

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

Es muss noch die folgende Zeile aus <code>redis/etc/redis.conf</code> entfernt werden:

<syntaxhighlight lang="conf">
daemonize yes
</syntaxhighlight>

Nun soll der Dienst aktiviert und gestartet werden:

<syntaxhighlight lang="bash">
systemctl --user enable redis.service --now
</syntaxhighlight>

==== Beispiel: Apache ====

Es wurden in der Vergangenheit Start- und Stoppskripte empfohlen. Die Startskripte wurden dann um verschiedene Aktionen ergänzt.

Da empfehlen wir, die sonstigen Aktionen in ein eigenes Skript auszulagern, das mit der Direktive <code>ExecStartPre=</code> gestartet wird.
Dann kann der eigentliche Prozess mit <code>ExecStart=</code> gestartet werden, und wird dann auch entsprechend beendet. Dann ist kein Stopp-Skript erforderlich.

Es kann aber auch mit <code>ExecStop</code> ein Stopp-Skript ausgeführt werden.

=== supervisor ===

Bei supervisor wird z.B. in der Datei <code>~/supervisor/etc/supervisord.conf</code> ein Redis Dienst konfiguriert:

<syntaxhighlight lang="ini">
[program:redis]
command=/usr/bin/redis-server /home/pacs/xyz00/test/loomio/redis/etc/redis.conf
stderr_logfile = /home/pacs/xyz00/users/test/supervisor/log/redis-stderr.log
stdout_logfile = /home/pacs/xyz00/users/test/supervisor/log/redis-stdout.log
</syntaxhighlight>

Das muss entsprechend durch einen systemd Dienst ersetzt werden, siehe der Abschnitt bei der Umstellung von monit auf systemd.

== Ermittlung und Buchung des benötigten RAM Kontingent ==

siehe [[Prozessmanagement_mit_systemd_im_Userspace#RAM_Kontingent_eines_Webspace|RAM Kontingent eines Webspace]]

----
[[Kategorie:Systemd]]

Mlmmj

2024-03-31T16:17:15Z

Deg00-m.website: /* weitere Optionen */ DKIM

[http://www.mlmmj.org/ mlmmj], angeblich eine Abkürzung für "Mailing List Management Made Joyful", ist ein Programm, mit dem in einem Hostsharing Paket E-Mail-Verteiler realisiert werden kann.

Wer noch nicht weiß, was ein E-Mail-Verteiler machen soll oder wie, lese veilleicht auch den Wikipedia-Artikel:
[http://de.wikipedia.org/wiki/Mailingliste Mailingliste]

Eine leistungsfähigere Alternative zu mlmmj könnte [[Mailman_3_installieren|Mailman 3]] sein.

Diese Anleitung beschreibt die Einrichtung einer Mailingliste für eine Domain in einem Hostsharing-Webspace.

== Voraussetzungen ==

Das Debian Paket [http://packages.debian.org/search?keywords=mlmmj mlmmj] ist auf den Shared-Hosting-Servern bereits installiert. (Wer die Software selbst kompilieren möchte kann aktuellen Source-Code bei [https://codeberg.org/mlmmj/mlmmj|codeberg.org] finden.)

Für den Betrieb der Mailingliste empfiehlt sich das Anlegen eines eigenen Users für diesen Zweck mit hsadmin.

In dieser Anleitung heißt das Paket ''xyz00'' und der für Mailinglisten eingesetzte User ''xyz00-list''.

Die E-Mail-Adresse der einzurichtende Mailing-Liste soll ''discuss@example.org'' sein. Den lokalen Teil dieser Adresse, ''discuss'', ist der Listenname. Der Listenname darf auf keinen Fall das Plus-Zeichen (+) enthalten, weil dies ein Sonderbedeutung für die Listensteuerung hat: ''mlmmj'' wird nämlich Befehle der Abonnenten über erweiterte Adressen annehmen, wie z.B. ''discuss+help@example.org''.

Die Domain ''example.org'' muss dazu bei einem beliebigen User im Paket ''xyz00'' [[aufgeschaltet]] sein. ("Aufgeschaltet" bedeutet, daß diese Domain bei Hostsharing gehostet wird und der Domainname als Verzeichnis /home/pacs/xyz00/*User*/doms/example.org/ erscheint.)

== Einrichtung ==

Ich melde mich über SSH auf der Hostsharing-Console als der Paketuser ''xyz00'' an.

Im Shell kann ich dann durch den Befehl ''hsscript -i'' das Verwaltungswerkzeug [[hsadmin]] interaktiv ausführen:

xyz00@h03:~$ hsscript -i
Password: *************
xyz00@hsadmin>

In ''hsadmin'' werden User und E-Mail-Adresse angelegt.

xyz00@hsadmin> user.add({set:{name:'xyz00-list',comment:'Mailingliste Discuss',shell:'/bin/bash',password:'geheimnis'}})
xyz00@hsadmin> emailaddress.add({set:{target:'xyz00-list',localpart:'discuss',domain:'example.org'}})
xyz00@hsadmin> bye

Mit dem Parameter "target" wird die für diese Adresse eingehende Post zunächst in das Postfach des Users xyz00-list abgelegt.

Für den User xyz00-list lege ich in seinem Heimat-Verzeichnis das Unterverzeichnis <tt>mlmmj</tt> an:

mkdir /home/pacs/xyz00/users/list/mlmmj

Dann lege ich die Mailingliste mit folgendem Kommando an:

mlmmj-make-ml -L discuss -s /home/pacs/xyz00/users/list/mlmmj

Das Skript ''mlmmj-make-ml'' fragt weitere Parameter der Mailingliste ab:

The Domain for the List? [] : example.org
The emailaddress of the list owner? [postmaster] : webmaster@example.org
For the list texts you can choose between the following languages or
give an absolute path to a directory containing the texts.
Available languages:
cz da de en es fr it nl ru
The path to texts for the list? [en] : de

Das skript ''mlmmj-make-ml'' legt daraufhin unter "/home/pacs/xyz00/users/list/mlmmj" ein Verzeichnis "discuss" an, das die Datenstruktur zur Verwaltung der Mailingliste enthält.

Weitere Konfigurationen der Liste erfolgen durch das Anlegen von Dateien im
Verzeichnis "/home/pacs/xyz00/users/list/mlmmj/discuss/control".
Die Konfigurationsmöglichkeiten finden Sie auf der [http://mlmmj.org/docs/tunables/ Internetseite von mlmmj].

Damit mlmmj die Verteilung der Post übernimmt, muß ich im Heimat-Verzeichnis des users xyz00-list die Datei <tt>.forward</tt> mit folgenden Inhalt (INKLUSIVE der Anführungszeichen!) erstellen:

"|/usr/bin/mlmmj-recieve -L /home/pacs/xyz00/users/list/mlmmj/discuss/"

(Ja, ''receive'' schreibt sich mit ''-ei-'', aber mlmmj hält einen symbolischen Link bereit für diejenigen, die in englischer Rechtschreibung unsicher sind:)

xyz00-list@h03:~$ ls -la /usr/bin/mlmmj-rec*
-rwxr-xr-x 1 root root 27104 Sep 25 2018 /usr/bin/mlmmj-receive
lrwxrwxrwx 1 root root 13 Sep 25 2018 /usr/bin/mlmmj-recieve -> mlmmj-receive

Die <tt>.forward</tt>-Datei sorgt dafür, dass eingehende E-Mails an das User-Postfach an das Programm ''mlmmj-recieve'' übergeben werden.

Für regelmäßige Aufgaben der Listen-Managers definiere ich die
[[Cron|crontab]] wie folgt (immer noch als ''xyz00-list''):

xyz00-list@h03:~$ crontab -e

MAILTO=webmaster@example.org
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin
HOME=/home/pacs/xyz00/users/list
SHELL=/bin/bash
LANG=en_US.UTF-8
# m h dom mon dow command
28 */4 * * * /usr/bin/mlmmj-maintd -d /home/pacs/xyz00/users/list/mlmmj -F

Zum Schluss rufe ich das Skript mlmmj-sub auf, um die E-Mail-Adressen der gewünschten Abonnenten des Verteilers einzutragen:

/usr/bin/mlmmj-sub -L /home/pacs/xyz00/users/list/mlmmj/discuss -a klaus.muster@gmx.de -c
/usr/bin/mlmmj-sub -L /home/pacs/xyz00/users/list/mlmmj/discuss -a sabine.beispiel@arcor.de -c

Dabei bewirkt "-c", dass der Abonnent eine Begrüßungs-Nachricht erhält. Alternativ kann man "-C" (großes C) angeben: dann muss der Abonnent das Abo durch Antworten auf die Nachricht bestätigen.

== weitere Optionen ==

Noch ein paar Dinge, die Sie möglicherweise einstellen wollen:

Ein Prefix in der Betreffzeile setzen, z.B.: "[discuss]".

echo "[discuss]" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/prefix

Wenn die Liste nur E-Mails von eingetragenen Abonnenten weiterleiten soll:

touch /home/pacs/xyz00/users/list/mlmmj/discuss/control/subonlypost

Damit der Listen-Owner weitere Abonnements bestätigen muss:

touch /home/pacs/xyz00/users/list/mlmmj/discuss/control/submod

Einen "Reply-To:"-Header setzen, damit Antwort-Mails standardmäßig an die Mailing-Liste gehen:

echo "Reply-To:" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/delheaders
echo "Reply-To: discuss@example.org" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/customheaders

Weitere Möglichkeiten finden Sie (wie oben bereits angegeben)
auf der [http://mlmmj.org/docs/tunables/ Internetseite von mlmmj].

=== Achtung: DKIM ===

Mlmmj gibt die Möglichkeit, mit '''delheaders''' und '''customheaders''' die Header der durchgeleiteten Mail umfangreich zu ändern. Allerdings tragen Mails heute häufig kryptografische Signaturen der sendenden Mailserver. Eine DKIM-Signatur sichert damit in der Regel die Integrität des Body der Mail sowie der Header ''Subject:'', ''From:'', ''To:'', ''Date:'', ''From'', und oft auch ''Reply-To:''.

Wird zum Beispiel mit einem Prefix das Subject geändert oder ein Footer angehängt, macht dies die DKIM-Signatur ungültig. Das ist für manche Mailprovider ein Signal für Spam.

== Zur Konfiguration im Browser ==

Die Original-Distribution von ''mlmmj'' enthält ein paar einfache PHP- und Perl-Skripte. Das sind Beispiele für Subscribe-/Unsubscribe-Formulare, ein Admin-Formular zum Eintragen und Löschen von Abonnements und eine Seite mit der gesamten Listen-Konfiguration.

Wer es sich ansehen möchte:

Als Paket-Admin eine Domain aufschalten:

hsscript -u xyz00 -e "domain.add({set:{name:'lists.example.org',user:'xyz00-list'}})"

Und weiter als "xyz00-list".

Download der neuesten Version der Sourcen von mlmmj von http://mlmmj.org/downloads/ (noch besser: Download des aktuellen Debian-Pakets von [https://packages.debian.org/bookworm/all/mlmmj-php-web-admin/download debian.org]: da sind einige veraltete PHP-Ausdrücke schon herausgepatcht) und diese in einem temporären Verzeichnis entpacken (mit tar oder dpkg-deb).

Unter "/mlmmj-$versionsnummer/contrib/web/php-admin/", oder beim .deb-Paket unter "usr/share/mlmmj-...", findet sich die PHP-Admin-Anwendung. Also ...

* den Inhalt diese Verzeichnisses nach "/home/pacs/xyz00/users/list/doms/lists.example.org/" packen;
* in "/home/pacs/xyz00/users/list/doms/lists.example.org/conf/config.php" die Variable "$topdir" anpassen;
* die Dateien aus "/home/pacs/xyz00/users/list/doms/lists.example.org/htdocs/" nach "/home/pacs/xyz00/users/list/doms/lists.example.org/htdocs-ssl/" verschieben;
* Beim .deb-Paket die config.php, die templates/ und die tunables.pl aus etc/ nach example.org/conf/ verschieben;
* in "/home/pacs/xyz00/users/list/mlmmj" und in "/home/pacs/xyz00/users/list/doms/lists.example.org/htdocs-ssl/" eine ".htaccess" mit folgendem Inhalt ablegen:

Require valid-user
AuthType Basic
AuthName "mlmmj web-interface"
AuthUserFile /home/pacs/xyz00/users/list/doms/lists.example.org/etc/htpasswd

* Und schließlich die "htpasswd"-Datei anlegen.

cd /home/pacs/xyz00/users/list/doms/lists.example.org/etc/
htpasswd -c htpasswd listadmin

* Ein Passwort angeben.

Nun enthält diese PHP-Anwendung, wenn man sie nicht dem Debian-Paket entnommen hat, leider noch eine Zeile, die schon seit PHP 7 nicht mehr lauffähig ist. Also muß man noch

* in <tt>.../htdocs-ssl/index.php</tt> folgende Änderung vornehmen:

@@ -38,4 +38,5 @@
# use scandir to have alphabetical order
foreach (scandir($topdir) as $file) {
- if (!ereg("^\.",$file))
+# ereg obsolete!! Vormals: if (!ereg("^\.",$file))
+ if (!preg_match('/^\./',$file))
{

und das Ergebnis auf https://lists.example.org anschauen.

== Mehrere Mailinglisten betreiben ==

Wenn mehrere Mailinglisten in einem Account und mit einer Admin-Oberfläche betrieben werden soll, empfiehlt sich die Nutzung von Procmail für den Aufruf von ''mlmmj'' für die jeweiligen Liste mit ihrem Daten-Verzeichnis.

Dazu trägt man in der Datei <tt>.forward</tt> statt des Aufrufs von ''mlmmj-recieve'' einen Aufruf von ''procmail'' ein:

|/usr/bin/procmail

Die Konfiguration von Procmail kann generisch erfolgen. Dazu legt man eine Datei <tt>.procmailrc</tt> mit folgendem Inhalt ins $HOME des Users:

SHELL=/bin/sh
HOMEDIR=/home/pacs/xyz00/users/list
MAILDIR=/home/pacs/xyz00/users/list/Maildir
PMDIR=/home/pacs/xyz00/users/list
VERBOSE=yes
LOGFILE=/home/pacs/xyz00/users/list/var/procmail.log
DEFAULT

:0:
* ^X-Original-To: ()\/[^@+]+
|/usr/bin/mlmmj-receive -F -L /home/pacs/xyz00/users/list/mlmmj/${MATCH}/

:0
{ EXITCODE 67 }

Bitte dafür sorgen, dass das Verzeichnis ''/home/pacs/xyz00/users/list/var'' existiert.

Der kryptische reguläre Ausdruck hinter dem Header ''X-Original-To:'' passt auf den Beginn der E-Mail-Adresse bis zum ersten ''@''- oder ''+''-Zeichen. In der Variable ''MATCH'' steht also der Name der Mailingliste, d.h. der Name der Verzeichnisses, in dem die Liste verwaltet wird.

Sehr wichtig ist die Zeile ''DEFAULT'' zu Beginn der ''.procmailrc''. Die Variable ''DEFAULT'' wird von ''procmail'' gesetzt. Wir sorgen mit dieser Zeile dafür, dass sie wieder undefiniert ist. Diese Variable wird intern von ''mlmmj'' benutzt, wenn sie gesetzt ist. Das führt in Kombination mit ''procmail'' zu Fehlfunktionen (vgl. Links).

Achtung, mit der Groß- und Kleinschreibung von Listennamen gibt es bei dieser Procmail-Lösung eine kleine Tücke. Procmail übernimmt in die Variable $MATCH genau die in der X-Original-To-Headerzeile vorgefundene Schreibweise, und diese kann denkbarerweise "Listen-Name" oder "listen-name" oder "Listen-name" sein. <tt>mlmmj</tt> hingegen wird diesen Wert in Unix-Manier mit dem genauen Verzeichnisnamen <tt>${HOME}/mlmmj/listen-name</tt> vergleichen, und bei unterschiedlicher Schreibweise die Mail nicht verteilen.

Eine teilweise Lösung besteht darin, den Listennamen in dem <tt>mlmmj</tt>-Aufruf in der <tt>.procmailrc</tt> in Kleinbuchstaben umzuschreiben. Dann lautet das Rezept so:

:0:
* ^X-Original-To: ()\/[^@+]+
|/usr/bin/mlmmj-receive -F -L /home/pacs/xyz00/users/list/mlmmj/$(echo ${MATCH} | tr [:upper:] [:lower:])/

Der Rest der Datei muß gleich bleiben, wie weiter oben angezeigt.

In diesem Fall müssen aber alle Mailing-Listen ohne Großbuchstaben im Namen angelegt werden!

(Man kann auch in <tt>${HOME}/mlmmj/</tt> durch kleingeschriebene Symlinks großgeschriebene Listennamen ansprechbar machen:

xyz00-list@h02:~$ ls -lA mlmmj/
total 8
-rw-r--r-- 1 xyz00-list xyz00 148 Feb 1 16:56 .htaccess
lrwxrwxrwx 1 xyz00-list xyz00 10 Feb 2 18:01 mitglieder -> Mitglieder
drwxr-xr-x 15 xyz00-list xyz00 4096 Feb 2 16:53 Mitglieder

Das scheint zu funktionieren; Angabe ohne Gewähr.)

== Links ==

* http://mlmmj.org/ Projektseite
* https://codeberg.org/mlmmj mlmmj auf Codeberg
* https://github.com/tchapi/mlmmj-simple-web-interface ein Admin-Interface in NodeJS
* [https://web.archive.org/web/20221228110514/https://www.tablix.org/~avian/blog/archives/2010/04/the_faulty_default/ https://www.tablix.org/~avian/blog/archives/2010/04/the_faulty_default/ (via web.archive.org)] Nutzung von mlmmj in Verbindung mit Procmail
* [https://gist.github.com/kboss/7c9593f0fd9219406226c4f11256b98a Einfaches Python-Script zum Massenimport aus einem Texfile.] Geht bestimmt auch eleganter mit purem Bash

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

Mlmmj

2024-02-10T03:41:32Z

Deg00-m.website: /* Mehrere Mailinglisten betreiben */

[http://www.mlmmj.org/ mlmmj], angeblich eine Abkürzung für "Mailing List Management Made Joyful", ist ein Programm, mit dem in einem Hostsharing Paket E-Mail-Verteiler realisiert werden kann.

Wer noch nicht weiß, was ein E-Mail-Verteiler machen soll oder wie, lese veilleicht auch den Wikipedia-Artikel:
[http://de.wikipedia.org/wiki/Mailingliste Mailingliste]

Eine leistungsfähigere Alternative zu mlmmj könnte [[Mailman_3_installieren|Mailman 3]] sein.

Diese Anleitung beschreibt die Einrichtung einer Mailingliste für eine Domain in einem Hostsharing-Webspace.

== Voraussetzungen ==

Das Debian Paket [http://packages.debian.org/search?keywords=mlmmj mlmmj] ist auf den Shared-Hosting-Servern bereits installiert. (Wer die Software selbst kompilieren möchte kann aktuellen Source-Code bei [https://codeberg.org/mlmmj/mlmmj|codeberg.org] finden.)

Für den Betrieb der Mailingliste empfiehlt sich das Anlegen eines eigenen Users für diesen Zweck mit hsadmin.

In dieser Anleitung heißt das Paket ''xyz00'' und der für Mailinglisten eingesetzte User ''xyz00-list''.

Die E-Mail-Adresse der einzurichtende Mailing-Liste soll ''discuss@example.org'' sein. Den lokalen Teil dieser Adresse, ''discuss'', ist der Listenname. Der Listenname darf auf keinen Fall das Plus-Zeichen (+) enthalten, weil dies ein Sonderbedeutung für die Listensteuerung hat: ''mlmmj'' wird nämlich Befehle der Abonnenten über erweiterte Adressen annehmen, wie z.B. ''discuss+help@example.org''.

Die Domain ''example.org'' muss dazu bei einem beliebigen User im Paket ''xyz00'' [[aufgeschaltet]] sein. ("Aufgeschaltet" bedeutet, daß diese Domain bei Hostsharing gehostet wird und der Domainname als Verzeichnis /home/pacs/xyz00/*User*/doms/example.org/ erscheint.)

== Einrichtung ==

Ich melde mich über SSH auf der Hostsharing-Console als der Paketuser ''xyz00'' an.

Im Shell kann ich dann durch den Befehl ''hsscript -i'' das Verwaltungswerkzeug [[hsadmin]] interaktiv ausführen:

xyz00@h03:~$ hsscript -i
Password: *************
xyz00@hsadmin>

In ''hsadmin'' werden User und E-Mail-Adresse angelegt.

xyz00@hsadmin> user.add({set:{name:'xyz00-list',comment:'Mailingliste Discuss',shell:'/bin/bash',password:'geheimnis'}})
xyz00@hsadmin> emailaddress.add({set:{target:'xyz00-list',localpart:'discuss',domain:'example.org'}})
xyz00@hsadmin> bye

Mit dem Parameter "target" wird die für diese Adresse eingehende Post zunächst in das Postfach des Users xyz00-list abgelegt.

Für den User xyz00-list lege ich in seinem Heimat-Verzeichnis das Unterverzeichnis <tt>mlmmj</tt> an:

mkdir /home/pacs/xyz00/users/list/mlmmj

Dann lege ich die Mailingliste mit folgendem Kommando an:

mlmmj-make-ml -L discuss -s /home/pacs/xyz00/users/list/mlmmj

Das Skript ''mlmmj-make-ml'' fragt weitere Parameter der Mailingliste ab:

The Domain for the List? [] : example.org
The emailaddress of the list owner? [postmaster] : webmaster@example.org
For the list texts you can choose between the following languages or
give an absolute path to a directory containing the texts.
Available languages:
cz da de en es fr it nl ru
The path to texts for the list? [en] : de

Das skript ''mlmmj-make-ml'' legt daraufhin unter "/home/pacs/xyz00/users/list/mlmmj" ein Verzeichnis "discuss" an, das die Datenstruktur zur Verwaltung der Mailingliste enthält.

Weitere Konfigurationen der Liste erfolgen durch das Anlegen von Dateien im
Verzeichnis "/home/pacs/xyz00/users/list/mlmmj/discuss/control".
Die Konfigurationsmöglichkeiten finden Sie auf der [http://mlmmj.org/docs/tunables/ Internetseite von mlmmj].

Damit mlmmj die Verteilung der Post übernimmt, muß ich im Heimat-Verzeichnis des users xyz00-list die Datei <tt>.forward</tt> mit folgenden Inhalt (INKLUSIVE der Anführungszeichen!) erstellen:

"|/usr/bin/mlmmj-recieve -L /home/pacs/xyz00/users/list/mlmmj/discuss/"

(Ja, ''receive'' schreibt sich mit ''-ei-'', aber mlmmj hält einen symbolischen Link bereit für diejenigen, die in englischer Rechtschreibung unsicher sind:)

xyz00-list@h03:~$ ls -la /usr/bin/mlmmj-rec*
-rwxr-xr-x 1 root root 27104 Sep 25 2018 /usr/bin/mlmmj-receive
lrwxrwxrwx 1 root root 13 Sep 25 2018 /usr/bin/mlmmj-recieve -> mlmmj-receive

Die <tt>.forward</tt>-Datei sorgt dafür, dass eingehende E-Mails an das User-Postfach an das Programm ''mlmmj-recieve'' übergeben werden.

Für regelmäßige Aufgaben der Listen-Managers definiere ich die
[[Cron|crontab]] wie folgt (immer noch als ''xyz00-list''):

xyz00-list@h03:~$ crontab -e

MAILTO=webmaster@example.org
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin
HOME=/home/pacs/xyz00/users/list
SHELL=/bin/bash
LANG=en_US.UTF-8
# m h dom mon dow command
28 */4 * * * /usr/bin/mlmmj-maintd -d /home/pacs/xyz00/users/list/mlmmj -F

Zum Schluss rufe ich das Skript mlmmj-sub auf, um die E-Mail-Adressen der gewünschten Abonnenten des Verteilers einzutragen:

/usr/bin/mlmmj-sub -L /home/pacs/xyz00/users/list/mlmmj/discuss -a klaus.muster@gmx.de -c
/usr/bin/mlmmj-sub -L /home/pacs/xyz00/users/list/mlmmj/discuss -a sabine.beispiel@arcor.de -c

Dabei bewirkt "-c", dass der Abonnent eine Begrüßungs-Nachricht erhält. Alternativ kann man "-C" (großes C) angeben: dann muss der Abonnent das Abo durch Antworten auf die Nachricht bestätigen.

== weitere Optionen ==

Noch ein paar Dinge, die Sie möglicherweise einstellen wollen:

Ein Prefix in der Betreffzeile setzen, z.B.: "[discuss]".

echo "[discuss]" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/prefix

Wenn die Liste nur E-Mails von eingetragenen Abonnenten weiterleiten soll:

touch /home/pacs/xyz00/users/list/mlmmj/discuss/control/subonlypost

Damit der Listen-Owner weitere Abonnements bestätigen muss:

touch /home/pacs/xyz00/users/list/mlmmj/discuss/control/submod

Einen "Reply-To:"-Header setzen, damit Antwort-Mails standardmäßig an die Mailing-Liste gehen:

echo "Reply-To:" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/delheaders
echo "Reply-To: discuss@example.org" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/customheaders

Weitere Möglichkeiten finden Sie (wie oben bereits angegeben)
auf der [http://mlmmj.org/docs/tunables/ Internetseite von mlmmj].

== Zur Konfiguration im Browser ==

Die Original-Distribution von ''mlmmj'' enthält ein paar einfache PHP- und Perl-Skripte. Das sind Beispiele für Subscribe-/Unsubscribe-Formulare, ein Admin-Formular zum Eintragen und Löschen von Abonnements und eine Seite mit der gesamten Listen-Konfiguration.

Wer es sich ansehen möchte:

Als Paket-Admin eine Domain aufschalten:

hsscript -u xyz00 -e "domain.add({set:{name:'lists.example.org',user:'xyz00-list'}})"

Und weiter als "xyz00-list".

Download der neuesten Version der Sourcen von mlmmj von http://mlmmj.org/downloads/ (noch besser: Download des aktuellen Debian-Pakets von [https://packages.debian.org/bookworm/all/mlmmj-php-web-admin/download debian.org]: da sind einige veraltete PHP-Ausdrücke schon herausgepatcht) und diese in einem temporären Verzeichnis entpacken (mit tar oder dpkg-deb).

Unter "/mlmmj-$versionsnummer/contrib/web/php-admin/", oder beim .deb-Paket unter "usr/share/mlmmj-...", findet sich die PHP-Admin-Anwendung. Also ...

* den Inhalt diese Verzeichnisses nach "/home/pacs/xyz00/users/list/doms/lists.example.org/" packen;
* in "/home/pacs/xyz00/users/list/doms/lists.example.org/conf/config.php" die Variable "$topdir" anpassen;
* die Dateien aus "/home/pacs/xyz00/users/list/doms/lists.example.org/htdocs/" nach "/home/pacs/xyz00/users/list/doms/lists.example.org/htdocs-ssl/" verschieben;
* Beim .deb-Paket die config.php, die templates/ und die tunables.pl aus etc/ nach example.org/conf/ verschieben;
* in "/home/pacs/xyz00/users/list/mlmmj" und in "/home/pacs/xyz00/users/list/doms/lists.example.org/htdocs-ssl/" eine ".htaccess" mit folgendem Inhalt ablegen:

Require valid-user
AuthType Basic
AuthName "mlmmj web-interface"
AuthUserFile /home/pacs/xyz00/users/list/doms/lists.example.org/etc/htpasswd

* Und schließlich die "htpasswd"-Datei anlegen.

cd /home/pacs/xyz00/users/list/doms/lists.example.org/etc/
htpasswd -c htpasswd listadmin

* Ein Passwort angeben.

Nun enthält diese PHP-Anwendung, wenn man sie nicht dem Debian-Paket entnommen hat, leider noch eine Zeile, die schon seit PHP 7 nicht mehr lauffähig ist. Also muß man noch

* in <tt>.../htdocs-ssl/index.php</tt> folgende Änderung vornehmen:

@@ -38,4 +38,5 @@
# use scandir to have alphabetical order
foreach (scandir($topdir) as $file) {
- if (!ereg("^\.",$file))
+# ereg obsolete!! Vormals: if (!ereg("^\.",$file))
+ if (!preg_match('/^\./',$file))
{

und das Ergebnis auf https://lists.example.org anschauen.

== Mehrere Mailinglisten betreiben ==

Wenn mehrere Mailinglisten in einem Account und mit einer Admin-Oberfläche betrieben werden soll, empfiehlt sich die Nutzung von Procmail für den Aufruf von ''mlmmj'' für die jeweiligen Liste mit ihrem Daten-Verzeichnis.

Dazu trägt man in der Datei <tt>.forward</tt> statt des Aufrufs von ''mlmmj-recieve'' einen Aufruf von ''procmail'' ein:

|/usr/bin/procmail

Die Konfiguration von Procmail kann generisch erfolgen. Dazu legt man eine Datei <tt>.procmailrc</tt> mit folgendem Inhalt ins $HOME des Users:

SHELL=/bin/sh
HOMEDIR=/home/pacs/xyz00/users/list
MAILDIR=/home/pacs/xyz00/users/list/Maildir
PMDIR=/home/pacs/xyz00/users/list
VERBOSE=yes
LOGFILE=/home/pacs/xyz00/users/list/var/procmail.log
DEFAULT

:0:
* ^X-Original-To: ()\/[^@+]+
|/usr/bin/mlmmj-receive -F -L /home/pacs/xyz00/users/list/mlmmj/${MATCH}/

:0
{ EXITCODE 67 }

Bitte dafür sorgen, dass das Verzeichnis ''/home/pacs/xyz00/users/list/var'' existiert.

Der kryptische reguläre Ausdruck hinter dem Header ''X-Original-To:'' passt auf den Beginn der E-Mail-Adresse bis zum ersten ''@''- oder ''+''-Zeichen. In der Variable ''MATCH'' steht also der Name der Mailingliste, d.h. der Name der Verzeichnisses, in dem die Liste verwaltet wird.

Sehr wichtig ist die Zeile ''DEFAULT'' zu Beginn der ''.procmailrc''. Die Variable ''DEFAULT'' wird von ''procmail'' gesetzt. Wir sorgen mit dieser Zeile dafür, dass sie wieder undefiniert ist. Diese Variable wird intern von ''mlmmj'' benutzt, wenn sie gesetzt ist. Das führt in Kombination mit ''procmail'' zu Fehlfunktionen (vgl. Links).

Achtung, mit der Groß- und Kleinschreibung von Listennamen gibt es bei dieser Procmail-Lösung eine kleine Tücke. Procmail übernimmt in die Variable $MATCH genau die in der X-Original-To-Headerzeile vorgefundene Schreibweise, und diese kann denkbarerweise "Listen-Name" oder "listen-name" oder "Listen-name" sein. <tt>mlmmj</tt> hingegen wird diesen Wert in Unix-Manier mit dem genauen Verzeichnisnamen <tt>${HOME}/mlmmj/listen-name</tt> vergleichen, und bei unterschiedlicher Schreibweise die Mail nicht verteilen.

Eine teilweise Lösung besteht darin, den Listennamen in dem <tt>mlmmj</tt>-Aufruf in der <tt>.procmailrc</tt> in Kleinbuchstaben umzuschreiben. Dann lautet das Rezept so:

:0:
* ^X-Original-To: ()\/[^@+]+
|/usr/bin/mlmmj-receive -F -L /home/pacs/xyz00/users/list/mlmmj/$(echo ${MATCH} | tr [:upper:] [:lower:])/

Der Rest der Datei muß gleich bleiben, wie weiter oben angezeigt.

In diesem Fall müssen aber alle Mailing-Listen ohne Großbuchstaben im Namen angelegt werden!

(Man kann auch in <tt>${HOME}/mlmmj/</tt> durch kleingeschriebene Symlinks großgeschriebene Listennamen ansprechbar machen:

xyz00-list@h02:~$ ls -lA mlmmj/
total 8
-rw-r--r-- 1 xyz00-list xyz00 148 Feb 1 16:56 .htaccess
lrwxrwxrwx 1 xyz00-list xyz00 10 Feb 2 18:01 mitglieder -> Mitglieder
drwxr-xr-x 15 xyz00-list xyz00 4096 Feb 2 16:53 Mitglieder

Das scheint zu funktionieren; Angabe ohne Gewähr.)

== Links ==

* http://mlmmj.org/ Projektseite
* https://codeberg.org/mlmmj mlmmj auf Codeberg
* https://github.com/tchapi/mlmmj-simple-web-interface ein Admin-Interface in NodeJS
* https://www.tablix.org/~avian/blog/archives/2010/04/the_faulty_default/ Nutzung von mlmmj in Verbindung mit Procmail

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

Mlmmj

2023-10-18T10:35:37Z

Deg00-m.website: /* Links */ Sourcen auf Codeberg

== Mailing List Management Made Joyful ==

[http://www.mlmmj.org/ mlmmj] ist ein Programm, mit dem in einem Hostsharing Paket E-Mail-Verteiler realisiert werden kann.

Vergleichen Sie dazu auch den Wikipedia-Artikel:
[http://de.wikipedia.org/wiki/Mailingliste Mailingliste]

Alternative: [[Mailman_3_installieren]]

Diese Anleitung beschreibt die Installation einer Mailingliste in einem Hostsharing Webspace für eine Domain.

== mlmmj ==

=== Voraussetzungen ===

Das Debian Paket [http://packages.debian.org/search?keywords=mlmmj mlmmj] ist auf den Shared-Hosting-Servern bereits installiert.

Für den Betrieb der Mailingliste empfehle ich das Anlegen eines Users für diesen Zweck mit hsadmin.

Sei mein Paket ''xyz00'' und der User ''xyz00-list''.

Sei meine Domain ''example.org'' und die E-Mail-Adresse für die Liste ''discuss@example.org''.

Die Domain muss bei einem beliebigen User im Paket ''xyz00'' aufgeschaltet sein. Die E-Mail-Adresse wird ebenfalls mit hsadmin eingerichtet. Das Target ist der User ''xyz00-list''.

Hier werden User und E-Mail-Adresse mit Hilfe des hsadmin-Interpreters ''hsscript'' angelegt:

xyz00@h03:~$ hsscript -i
Password: *************
xyz00@hsadmin> user.add({set:{name:'xyz00-list',comment:'Mailingliste Discuss',shell:'/bin/bash',password:'geheimnis'}})
xyz00@hsadmin> emailaddress.add({set:{target:'xyz00-list',localpart:'discuss',domain:'example.org'}})
xyz00@hsadmin> bye

=== Einrichtung ===

Ich melde mich auf der Linux-Kommandozeile als User ''xyz00-list'' an.

Für den User lege ich in seinem Heimat-Verzeichnis das Unterverzeichnis "mlmmj" an:

mkdir /home/pacs/xyz00/users/list/mlmmj

Dann lege ich die Mailingliste mit folgendem Kommando an:

mlmmj-make-ml -L discuss -s /home/pacs/xyz00/users/list/mlmmj

Das Skript fragt weitere Parameter der Mailingliste ab:

The Domain for the List? [] : example.org
The emailaddress of the list owner? [postmaster] : webmaster@example.org
For the list texts you can choose between the following languages or
give a absolute path to a directory containing the texts.
Available languages:
cz da de en es fr it nl ru
The path to texts for the list? [en] : de

Damit ist unter "/home/pacs/xyz00/users/list/mlmmj" ein Verzeichnis "discuss" angelegt,
das die Datenstruktur zur Verwaltung der Mailingliste enthält.

Weitere Konfigurationen der Liste erfolgen durch das Anlegen von Dateien im
Verzeichnis "/home/pacs/xyz00/users/list/mlmmj/discuss/control".
Die Konfigurationsmöglichkeiten finden Sie auf der [http://mlmmj.org/docs/tunables/ Internetseite von mlmmj]

Für den User lege ich in seinem Heimat-Verzeichnis die Datei ".forward" mit folgenden Inhalt an (Achtung, die Anführungszeichen nicht vergessen!):

"|/usr/bin/mlmmj-recieve -L /home/pacs/xyz00/users/list/mlmmj/discuss/"

Diese Datei sorgt dafür, dass eingehende E-Mail für die Liste an das Programm ''mlmmj-recieve''
übergeben und dort verarbeitet werden.

Für regelmäßige Aufgaben der Listen-Managers definiere ich die
crontab wie folgt (immer noch als ''xyz00-list''):

MAILTO=webmaster@example.org
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin
HOME=/home/pacs/xyz00/users/list
SHELL=/bin/bash
LANG=en_US.UTF-8
# m h dom mon dow command
28 */4 * * * /usr/bin/mlmmj-maintd -d /home/pacs/xyz00/users/list/mlmmj -F

Zum Schluss trage ich noch die gewünschten E-Mail-Adressen ein:

/usr/bin/mlmmj-sub -L /home/pacs/xyz00/users/list/mlmmj/discuss -a klaus.muster@gmx.de -c
/usr/bin/mlmmj-sub -L /home/pacs/xyz00/users/list/mlmmj/discuss -a sabine.beispiel@arcor.de -c

Dabei bewirkt "-c", dass der Abonnent eine Begrüßungs-Nachricht erhält. Alternativ kann man "-C" (großes Ce)
angeben. Dann muss der Abonnent das Abo durch Antworten auf die Nachricht bestätigen.

=== weitere Konfiguration ===

Noch ein paar Dinge, die Sie möglicherweise einstellen wollen:

Ein Prefix in der Betreffzeile setzen, z.B.: "[discuss]".

echo "[discuss]" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/prefix

Die Liste darf nur E-Mails von eingetragenen Abonnenten weiterleiten:

touch /home/pacs/xyz00/users/list/mlmmj/discuss/control/subonlypost

Das Abonnement muss vom Listen-Owner bestätigt werden:

touch /home/pacs/xyz00/users/list/mlmmj/discuss/control/submod

Einen "Reply-To:"-Header setzen, so dass Antwort-EMails immer an den Verteiler gehen:

echo "Reply-To:" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/delheaders
echo "Reply-To: discuss@example.org" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/customheaders

Weitere Möglichkeiten finden Sie (wie oben bereits angegeben)
auf der [http://mlmmj.org/docs/tunables/ Internetseite von mlmmj]

=== Konfiguration im Browser ===

Die Original-Distribution von ''mlmmj'' enthält ein paar einfache PHP- und Perl-Skripte.
Das sind Beispiele für Subscribe-/Unsubscribe-Formulare, ein Admin-Formular zum Eintragen und Löschen
von Abonnements und eine Seite mit der gesamten Listen-Konfiguration.

Wer es sich ansehen möchte:

Als Paket-Admin eine Domain aufschalten:

hsscript -u xyz00 -e "domain.add({set:{name:'lists.example.org',user:'xyz00-list'}})"

Und weiter als "xyz00-list".

Download der neuesten Version der Sourcen von mlmmj von http://mlmmj.org/downloads/ und diese in einem temporären Verzeichnis entpacken.

Unter "/mlmmj-$versionsnummer/contrib/web/php-admin/" findet sich die PHP-Admin-Anwendung.

Also den Inhalt diese Verzeichnisses nach "/home/pacs/xyz00/users/list/doms/lists.example.org/" packen,
* in "/home/pacs/xyz00/users/list/doms/lists.example.org/conf/config.php" die Variable "$topdir" anpassen
* die Dateien aus "/home/pacs/xyz00/users/list/doms/lists.example.org/htdocs/" nach "/home/pacs/xyz00/users/list/doms/lists.example.org/htdocs-ssl/" verschieben
* in "/home/pacs/xyz00/users/list/mlmmj" und in "/home/pacs/xyz00/users/list/doms/lists.example.org/htdocs-ssl/" eine ".htaccess" mit folgendem Inhalt ablegen:

Require valid-user
AuthType Basic
AuthName "mlmmj web-interface"
AuthUserFile /home/pacs/xyz00/users/list/doms/lists.example.org/etc/htpasswd

Und schließlich die "htpasswd"-Datei anlegen.

cd /home/pacs/xyz00/users/list/doms/lists.example.org/etc/
htpasswd -c htpasswd listadmin

Ein Passwort angeben und auf
https://lists.example.org schauen.

== Mehrere Mailinglisten betreiben ==

Wenn mehrere Mailinglisten in einem Account und mit einer Admin-Oberfläche betrieben werden soll, empfiehlt sich die Nutzung von Procmail für den Aufruf von ''mlmmj'' für die jeweiligen Liste mit ihrem Daten-Verzeichnis.

Dazu trägt man in der Date ''.forward'' statt des Aufrufs von ''mlmmj-recieve'' einen Aufruf von ''procmail'' ein:

|/usr/bin/procmail

Die Konfiguration von Procmail kann generisch erfolgen. Dazu legt man eine Datei ''.procmailrc'' mit folgendem Inhalt ins $HOME des Users:

SHELL=/bin/sh
HOMEDIR=/home/pacs/xyz00/users/list
MAILDIR=/home/pacs/xyz00/users/list/Maildir
PMDIR=/home/pacs/xyz00/users/list
VERBOSE=yes
LOGFILE=/home/pacs/xyz00/users/list/var/procmail.log
DEFAULT

:0:
* ^X-Original-To: ()\/[^@+]+
|/usr/bin/mlmmj-receive -F -L /home/pacs/xyz00/users/list/mlmmj/${MATCH}/

:0
{ EXITCODE 67 }

Der kryptische reguläre Ausdruck hinter dem Header ''X-Original-To:'' passt auf den Beginn der E-Mail-Adresse bis zum ersten ''@''- oder ''+''-Zeichen. In der Variable ''MATCH'' steht also der Name der Mailingliste, d.h. der Name der Verzeichnisses, in dem die Liste verwaltet wird.

Sehr wichtig ist die Zeile ''DEFAULT'' zu Beginn der ''.procmailrc''. Die Variable ''DEFAULT'' wird von ''procmail'' gesetzt. Wir sorgen mit dieser Zeile dafür, dass sie wieder undefiniert ist. Diese Variable wird intern von ''mlmmj'' benutzt, wenn sie gesetzt ist. Das führt in Kombination mit ''procmail'' zu Fehlfunktionen (vgl. Links).

== Links ==

* http://mlmmj.org/ Projektseite
* https://codeberg.org/mlmmj mlmmj auf Codeberg
* https://github.com/tchapi/mlmmj-simple-web-interface ein Admin-Interface in NodeJS
* https://www.tablix.org/~avian/blog/archives/2010/04/the_faulty_default/ Nutzung von mlmmj in Verbindung mit Procmail

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

Domainregistrierung

2022-09-27T08:56:26Z

Deg00-m.website: /* 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://doc.hostsharing.net/#kap-ref-domain}}

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

Nextcloud

2022-06-10T08:21:38Z

Deg00-m.website: /* weiterführende Links */ HS-Nextcloud-Reseller

= 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

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'}})

== Nextcloud installieren ==

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

ssh -l xyz00-cloud xyz00.hostsharing.net

''htdocs'' Verzeichnis vorbereiten

cd
mkdir nextcloud
cd doms/cloud.example.org
rm -rf subs/www subs-ssl/www htdocs-ssl
ln -s $HOME/nextcloud htdocs-ssl

Nextcloud herunterladen und entpacken.

cd
wget https://download.nextcloud.com/server/releases/nextcloud-24.0.0.zip
unzip nextcloud-24.0.0.zip
rm nextcloud-24.0.0.zip
mkdir data tmp
chmod 700 data tmp

== Nextcloud konfigurieren ==

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

memory_limit=512M
session.save_path=/home/pacs/xyz00/users/cloud/tmp

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.

== 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 ist auf den Hostsharing-Servern vorinstalliert und wird von den Nextcloud-Entwicklern empfohlen. '''In Verbindung mit einem Managed Webspace''' muss Redis als eigener Server '''Daemon''' angemeldet werden und ist '''kostenpflichtig'''. Siehe zu Kosten im Webspace Konfigurator unter: https://www.hostsharing.net/angebote/managed-webspace/ – '''1 individueller Serverdienst''' (Daemons).

Mit dem Hostsharing-Service wird ein IP-Port für die Nutzung von Redis vereinbart.

Für den Redis-Dienst lege ich folgende Struktur an:

cd ~
mkdir -p ~/redis/etc
mkdir -p ~/redis/var

In ''~/redis/etc'' lege ich eine Konfigurationsdatei ''redis.conf'' für den Redis-Dienst ab:

daemonize yes
pidfile /home/pacs/xyz00/users/cloud/redis/var/redis-server.pid
requirepass mein-redis-passwort
unixsocket /home/pacs/xyz00/users/cloud/redis/var/redis-server.sock
unixsocketperm 700
port 0
tcp-backlog 128
timeout 300
loglevel notice
logfile /home/pacs/xyz00/users/cloud/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/cloud/redis/var

Den Start und das Monitoring des Redis-Dienstes übernimmt ''monit''. Hier eine geeignete Datei ''~/.monitrc'':

set daemon 60
with start delay 20
set logfile /home/pacs/xyz00/users/cloud/monit/var/monit.log
set idfile /home/pacs/xyz00/users/cloud/monit/var/monit.id
set statefile /home/pacs/xyz00/users/cloud/monit/var/monit.state
set httpd unixsocket /home/pacs/xyz00/users/cloud/monit/var/monit.sock
permission 600
allow monit:mein-monit-passwort
check process redis with pidfile /home/pacs/xyz00/users/cloud/redis/var/redis-server.pid
start program "/usr/bin/redis-server /home/pacs/xyz00/users/cloud/redis/etc/redis.conf"
stop program "/bin/bash -c '/bin/kill $( cat /home/pacs/xyz00/users/cloud/redis/var/redis-server.pid )'"

Zugriffsrechte für die Datei ''~/.monitrc'' setzen:

cd ~
chmod 600 .monitrc

Verzeichnis für ''monit'' anlegen:

cd ~
mkdir -p monit/var

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

'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,
),

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

compress
/home/pacs/xyz00/users/cloud/redis/var/redis.log {
rotate 5
daily
missingok
}
/home/pacs/xyz00/users/cloud/monit/var/monit.log {
rotate 2
weekly
missingok
}

Eine Crontab sorgt für den Start von Monit und das tägliche Rotieren der Logdateien:

# m h dom mon dow command
HOME=/home/pacs/xyz00/users/cloud
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
MAILTO=webmaster@example.com
@reboot /usr/bin/monit -c $HOME/.monitrc
1 1 * * * /usr/sbin/logrotate -s $HOME/.logrotate.state $HOME/.logrotate
*/5 * * * * /usr/bin/php $HOME/nextcloud/cron.php

Die letzte Zeile der ''crontab'' enthält den Cronjob für die regelmäßigen Hintergrundprozesse der Nextcloud. Durch die Erledigung dieser Aufgaben mit Cron lässt sich die Nextcloud ebenfalls etwas beschleunigen.

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

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

cd nextcloud/
php occ fulltextsearch:index --output

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:

cd nextcloud/
php occ fulltextsearch:live -q

Die Monit Konfiguration dafür sieht so aus:

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

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

~/.monitrc (siehe oben von der Redis Installation) entsprechend ergänzen:
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"

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

xyz00-cloud@h00:~/nextcloud/updater$ chmod u+x updater.phar
xyz00-cloud@h00:~/nextcloud/updater$ ./updater.phar

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]

Wartungsmodus per Shell ein- oder ausschalten:

xyz00-cloud@h00:~/nextcloud$ php occ maintenance:mode --on
xyz00-cloud@h00:~/nextcloud$ php occ maintenance:mode --off

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

xyz00-cloud@h00:~/nextcloud$ php occ db:add-missing-indices
xyz00-cloud@h00:~/nextcloud$ php occ db:add-missing-primary-keys
xyz00-cloud@h00:~/nextcloud$ php occ db:convert-filecache-bigint

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:

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

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

# 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

= 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://github.com/tpokorra/Hostsharing-Ansible-Nextcloud Ansible Playbook für Hostsharing]

= Nextcloud Reseller bei HS =

[https://nextcloud.ossaas.de Ossass]

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

Traffic

2021-11-14T06:20:30Z

Deg00-m.website: /* Webzugriffe analysieren */ Skript als Einzeiler

Mlmmj

2021-10-09T07:19:46Z

Deg00-m.website: /* Konfiguration im Browser */

== Mailing List Management Made Joyful ==

[http://www.mlmmj.org/ mlmmj] ist ein Programm, mit dem in einem Hostsharing Paket E-Mail-Verteiler realisiert werden kann.

Vergleichen Sie dazu auch den Wikipedia-Artikel:
[http://de.wikipedia.org/wiki/Mailingliste Mailingliste]

Alternative: [[Mailman_3_installieren]]

Diese Anleitung beschreibt die Installation einer Mailingliste in einem Hostsharing Webspace für eine Domain.

== mlmmj ==

=== Voraussetzungen ===

Das Debian Paket [http://packages.debian.org/search?keywords=mlmmj mlmmj] ist auf den Shared-Hosting-Servern bereits installiert.

Für den Betrieb der Mailingliste empfehle ich das Anlegen eines Users für diesen Zweck mit hsadmin.

Sei mein Paket ''xyz00'' und der User ''xyz00-list''.

Sei meine Domain ''example.org'' und die E-Mail-Adresse für die Liste ''discuss@example.org''.

Die Domain muss bei einem beliebigen User im Paket ''xyz00'' aufgeschaltet sein. Die E-Mail-Adresse wird ebenfalls mit hsadmin eingerichtet. Das Target ist der User ''xyz00-list''.

Hier werden User und E-Mail-Adresse mit Hilfe des hsadmin-Interpreters ''hsscript'' angelegt:

xyz00@h03:~$ hsscript -i
Password: *************
xyz00@hsadmin> user.add({set:{name:'xyz00-list',comment:'Mailingliste Discuss',shell:'/bin/bash',password:'geheimnis'}})
xyz00@hsadmin> emailaddress.add({set:{target:'xyz00-list',localpart:'discuss',domain:'example.org'}})
xyz00@hsadmin> bye

=== Einrichtung ===

Ich melde mich auf der Linux-Kommandozeile als User ''xyz00-list'' an.

Für den User lege ich in seinem Heimat-Verzeichnis das Unterverzeichnis "mlmmj" an:

mkdir /home/pacs/xyz00/users/list/mlmmj

Dann lege ich die Mailingliste mit folgendem Kommando an:

mlmmj-make-ml -L discuss -s /home/pacs/xyz00/users/list/mlmmj

Das Skript fragt weitere Parameter der Mailingliste ab:

The Domain for the List? [] : example.org
The emailaddress of the list owner? [postmaster] : webmaster@example.org
For the list texts you can choose between the following languages or
give a absolute path to a directory containing the texts.
Available languages:
cz da de en es fr it nl ru
The path to texts for the list? [en] : de

Damit ist unter "/home/pacs/xyz00/users/list/mlmmj" ein Verzeichnis "discuss" angelegt,
das die Datenstruktur zur Verwaltung der Mailingliste enthält.

Weitere Konfigurationen der Liste erfolgen durch das Anlegen von Dateien im
Verzeichnis "/home/pacs/xyz00/users/list/mlmmj/discuss/control".
Die Konfigurationsmöglichkeiten finden Sie auf der [http://mlmmj.org/docs/tunables/ Internetseite von mlmmj]

Für den User lege ich in seinem Heimat-Verzeichnis die Datei ".forward" mit folgenden Inhalt an (Achtung, die Anführungszeichen nicht vergessen!):

"|/usr/bin/mlmmj-recieve -L /home/pacs/xyz00/users/list/mlmmj/discuss/"

Diese Datei sorgt dafür, dass eingehende E-Mail für die Liste an das Programm ''mlmmj-recieve''
übergeben und dort verarbeitet werden.

Für regelmäßige Aufgaben der Listen-Managers definiere ich die
crontab wie folgt (immer noch als ''xyz00-list''):

MAILTO=webmaster@example.org
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin
HOME=/home/pacs/xyz00/users/list
SHELL=/bin/bash
LANG=en_US.UTF-8
# m h dom mon dow command
28 */4 * * * /usr/bin/mlmmj-maintd -d /home/pacs/xyz00/users/list/mlmmj -F

Zum Schluss trage ich noch die gewünschten E-Mail-Adressen ein:

/usr/bin/mlmmj-sub -L /home/pacs/xyz00/users/list/mlmmj/discuss -a klaus.muster@gmx.de -c
/usr/bin/mlmmj-sub -L /home/pacs/xyz00/users/list/mlmmj/discuss -a sabine.beispiel@arcor.de -c

Dabei bewirkt "-c", dass der Abonnent eine Begrüßungs-Nachricht erhält. Alternativ kann man "-C" (großes Ce)
angeben. Dann muss der Abonnent das Abo durch Antworten auf die Nachricht bestätigen.

=== weitere Konfiguration ===

Noch ein paar Dinge, die Sie möglicherweise einstellen wollen:

Ein Prefix in der Betreffzeile setzen, z.B.: "[discuss]".

echo "[discuss]" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/prefix

Die Liste darf nur E-Mails von eingetragenen Abonnenten weiterleiten:

touch /home/pacs/xyz00/users/list/mlmmj/discuss/control/subonlypost

Das Abonnement muss vom Listen-Owner bestätigt werden:

touch /home/pacs/xyz00/users/list/mlmmj/discuss/control/submod

Einen "Reply-To:"-Header setzen, so dass Antwort-EMails immer an den Verteiler gehen:

echo "Reply-To:" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/delheaders
echo "Reply-To: discuss@example.org" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/customheaders

Weitere Möglichkeiten finden Sie (wie oben bereits angegeben)
auf der [http://mlmmj.org/docs/tunables/ Internetseite von mlmmj]

=== Konfiguration im Browser ===

Die Original-Distribution von ''mlmmj'' enthält ein paar einfache PHP- und Perl-Skripte.
Das sind Beispiele für Subscribe-/Unsubscribe-Formulare, ein Admin-Formular zum Eintragen und Löschen
von Abonnements und eine Seite mit der gesamten Listen-Konfiguration.

Wer es sich ansehen möchte:

Als Paket-Admin eine Domain aufschalten:

hsscript -u xyz00 -e "domain.add({set:{name:'lists.example.org',user:'xyz00-list'}})"

Und weiter als "xyz00-list".

Download der neuesten Version der Sourcen von mlmmj von http://mlmmj.org/downloads/ und diese in einem temporären Verzeichnis entpacken.

Unter "/mlmmj-$versionsnummer/contrib/web/php-admin/" findet sich die PHP-Admin-Anwendung.

Also den Inhalt diese Verzeichnisses nach "/home/pacs/xyz00/users/list/doms/lists.example.org/" packen,
* in "/home/pacs/xyz00/users/list/doms/lists.example.org/conf/config.php" die Variable "$topdir" anpassen
* die Dateien aus "/home/pacs/xyz00/users/list/doms/lists.example.org/htdocs/" nach "/home/pacs/xyz00/users/list/doms/lists.example.org/htdocs-ssl/" verschieben
* in "/home/pacs/xyz00/users/list/mlmmj" und in "/home/pacs/xyz00/users/list/doms/lists.example.org/htdocs-ssl/" eine ".htaccess" mit folgendem Inhalt ablegen:

Require valid-user
AuthType Basic
AuthName "mlmmj web-interface"
AuthUserFile /home/pacs/xyz00/users/list/doms/lists.example.org/etc/htpasswd

Und schließlich die "htpasswd"-Datei anlegen.

cd /home/pacs/xyz00/users/list/doms/lists.example.org/etc/
htpasswd -c htpasswd listadmin

Ein Passwort angeben und auf
https://lists.example.org schauen.

== Mehrere Mailinglisten betreiben ==

Wenn mehrere Mailinglisten in einem Account und mit einer Admin-Oberfläche betrieben werden soll, empfiehlt sich die Nutzung von Procmail für den Aufruf von ''mlmmj'' für die jeweiligen Liste mit ihrem Daten-Verzeichnis.

Dazu trägt man in der Date ''.forward'' statt des Aufrufs von ''mlmmj-recieve'' einen Aufruf von ''procmail'' ein:

|/usr/bin/procmail -p

Die Konfiguration von Procmail kann generisch erfolgen. Dazu legt man eine Datei ''.procmailrc'' mit folgendem Inhalt ins $HOME des Users:

SHELL=/bin/sh
HOMEDIR=/home/pacs/xyz00/users/list
MAILDIR=/home/pacs/xyz00/users/list/Maildir
PMDIR=/home/pacs/xyz00/users/list
VERBOSE=yes
LOGFILE=/home/pacs/xyz00/users/list/var/procmail.log
DEFAULT

:0:
* ^X-Original-To: ()\/[^@+]+
|/usr/bin/mlmmj-receive -F -L /home/pacs/xyz00/users/list/mlmmj/${MATCH}/

:0
{ EXITCODE 67 }

Der kryptische reguläre Ausdruck hinter dem Header ''X-Original-To:'' passt auf den Beginn der E-Mail-Adresse bis zum ersten ''@''- oder ''+''-Zeichen. In der Variable ''MATCH'' steht also der Name der Mailingliste, d.h. der Name der Verzeichnisses, in dem die Liste verwaltet wird.

Sehr wichtig ist die Zeile ''DEFAULT'' zu Beginn der ''.procmailrc''. Die Variable ''DEFAULT'' wird von ''procmail'' gesetzt. Wir sorgen mit dieser Zeile dafür, dass sie wieder undefiniert ist. Diese Variable wird intern von ''mlmmj'' benutzt, wenn sie gesetzt ist. Das führt in Kombination mit ''procmail'' zu Fehlfunktionen (vgl. Links).

== Links ==

* http://mlmmj.org/ Projektseite
* https://gitlab.com/mlmmj/ mlmmj auf Gitlab
* https://github.com/tchapi/mlmmj-simple-web-interface ein Admin-Interface in NodeJS
* https://www.tablix.org/~avian/blog/archives/2010/04/the_faulty_default/ Nutzung von mlmmj in Verbindung mit Procmail

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

Mlmmj

2021-10-09T06:55:51Z

Deg00-m.website: /* Mehrere Mailinglisten betreiben */ Typo

== Mailing List Management Made Joyful ==

[http://www.mlmmj.org/ mlmmj] ist ein Programm, mit dem in einem Hostsharing Paket E-Mail-Verteiler realisiert werden kann.

Vergleichen Sie dazu auch den Wikipedia-Artikel:
[http://de.wikipedia.org/wiki/Mailingliste Mailingliste]

Alternative: [[Mailman_3_installieren]]

Diese Anleitung beschreibt die Installation einer Mailingliste in einem Hostsharing Webspace für eine Domain.

== mlmmj ==

=== Voraussetzungen ===

Das Debian Paket [http://packages.debian.org/search?keywords=mlmmj mlmmj] ist auf den Shared-Hosting-Servern bereits installiert.

Für den Betrieb der Mailingliste empfehle ich das Anlegen eines Users für diesen Zweck mit hsadmin.

Sei mein Paket ''xyz00'' und der User ''xyz00-list''.

Sei meine Domain ''example.org'' und die E-Mail-Adresse für die Liste ''discuss@example.org''.

Die Domain muss bei einem beliebigen User im Paket ''xyz00'' aufgeschaltet sein. Die E-Mail-Adresse wird ebenfalls mit hsadmin eingerichtet. Das Target ist der User ''xyz00-list''.

Hier werden User und E-Mail-Adresse mit Hilfe des hsadmin-Interpreters ''hsscript'' angelegt:

xyz00@h03:~$ hsscript -i
Password: *************
xyz00@hsadmin> user.add({set:{name:'xyz00-list',comment:'Mailingliste Discuss',shell:'/bin/bash',password:'geheimnis'}})
xyz00@hsadmin> emailaddress.add({set:{target:'xyz00-list',localpart:'discuss',domain:'example.org'}})
xyz00@hsadmin> bye

=== Einrichtung ===

Ich melde mich auf der Linux-Kommandozeile als User ''xyz00-list'' an.

Für den User lege ich in seinem Heimat-Verzeichnis das Unterverzeichnis "mlmmj" an:

mkdir /home/pacs/xyz00/users/list/mlmmj

Dann lege ich die Mailingliste mit folgendem Kommando an:

mlmmj-make-ml -L discuss -s /home/pacs/xyz00/users/list/mlmmj

Das Skript fragt weitere Parameter der Mailingliste ab:

The Domain for the List? [] : example.org
The emailaddress of the list owner? [postmaster] : webmaster@example.org
For the list texts you can choose between the following languages or
give a absolute path to a directory containing the texts.
Available languages:
cz da de en es fr it nl ru
The path to texts for the list? [en] : de

Damit ist unter "/home/pacs/xyz00/users/list/mlmmj" ein Verzeichnis "discuss" angelegt,
das die Datenstruktur zur Verwaltung der Mailingliste enthält.

Weitere Konfigurationen der Liste erfolgen durch das Anlegen von Dateien im
Verzeichnis "/home/pacs/xyz00/users/list/mlmmj/discuss/control".
Die Konfigurationsmöglichkeiten finden Sie auf der [http://mlmmj.org/docs/tunables/ Internetseite von mlmmj]

Für den User lege ich in seinem Heimat-Verzeichnis die Datei ".forward" mit folgenden Inhalt an (Achtung, die Anführungszeichen nicht vergessen!):

"|/usr/bin/mlmmj-recieve -L /home/pacs/xyz00/users/list/mlmmj/discuss/"

Diese Datei sorgt dafür, dass eingehende E-Mail für die Liste an das Programm ''mlmmj-recieve''
übergeben und dort verarbeitet werden.

Für regelmäßige Aufgaben der Listen-Managers definiere ich die
crontab wie folgt (immer noch als ''xyz00-list''):

MAILTO=webmaster@example.org
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin
HOME=/home/pacs/xyz00/users/list
SHELL=/bin/bash
LANG=en_US.UTF-8
# m h dom mon dow command
28 */4 * * * /usr/bin/mlmmj-maintd -d /home/pacs/xyz00/users/list/mlmmj -F

Zum Schluss trage ich noch die gewünschten E-Mail-Adressen ein:

/usr/bin/mlmmj-sub -L /home/pacs/xyz00/users/list/mlmmj/discuss -a klaus.muster@gmx.de -c
/usr/bin/mlmmj-sub -L /home/pacs/xyz00/users/list/mlmmj/discuss -a sabine.beispiel@arcor.de -c

Dabei bewirkt "-c", dass der Abonnent eine Begrüßungs-Nachricht erhält. Alternativ kann man "-C" (großes Ce)
angeben. Dann muss der Abonnent das Abo durch Antworten auf die Nachricht bestätigen.

=== weitere Konfiguration ===

Noch ein paar Dinge, die Sie möglicherweise einstellen wollen:

Ein Prefix in der Betreffzeile setzen, z.B.: "[discuss]".

echo "[discuss]" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/prefix

Die Liste darf nur E-Mails von eingetragenen Abonnenten weiterleiten:

touch /home/pacs/xyz00/users/list/mlmmj/discuss/control/subonlypost

Das Abonnement muss vom Listen-Owner bestätigt werden:

touch /home/pacs/xyz00/users/list/mlmmj/discuss/control/submod

Einen "Reply-To:"-Header setzen, so dass Antwort-EMails immer an den Verteiler gehen:

echo "Reply-To:" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/delheaders
echo "Reply-To: discuss@example.org" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/customheaders

Weitere Möglichkeiten finden Sie (wie oben bereits angegeben)
auf der [http://mlmmj.org/docs/tunables/ Internetseite von mlmmj]

=== Konfiguration im Browser ===

Die Original-Distribution von ''mlmmj'' enthält ein paar einfache PHP- und Perl-Skripte.
Das sind Beispiele für Subscribe-/Unsubscribe-Formulare, ein Admin-Formular zum Eintragen und Löschen
von Abonnements und eine Seite mit der gesamten Listen-Konfiguration.

Wer es sich ansehen möchte:

Als Paket-Admin eine Domain aufschalten:

hsscript -u xyz00 -e "domain.add({set:{name:'lists.example.org',user:'xyz00-list'}})"

Und weiter als "xyz00-list".

Download von http://mlmmj.org/releases/mlmmj-1.2.18.0.tar.gz auspacken.

Unter "/mlmmj-1.2.18.0/contrib/web/php-admin/" finden Sie im Paket die PHP-Admin-Anwendung.

Also den Inhalt diese Verzeichnisses nach "/home/pacs/xyz00/users/list/doms/lists.example.org/" packen,
* in "/home/pacs/xyz00/users/list/doms/lists.example.org/conf/config.php" die Variable "$topdir" anpassen
* die Dateien aus "/home/pacs/xyz00/users/list/doms/lists.example.org/htdocs/" nach "/home/pacs/xyz00/users/list/doms/lists.example.org/htdocs-ssl/" verschieben
* in "/home/pacs/xyz00/users/list/mlmmj" und in "/home/pacs/xyz00/users/list/doms/lists.example.org/htdocs-ssl/" eine ".htaccess" mit folgendem Inhalt ablegen:

Require valid-user
AuthType Basic
AuthName "mlmmj web-interface"
AuthUserFile /home/pacs/xyz00/users/list/doms/lists.example.org/etc/htpasswd

Und schließlich die "htpasswd"-Datei anlegen.

cd /home/pacs/xyz00/users/list/doms/lists.example.org/etc/
htpasswd -c htpasswd listadmin

Ein Passwort angeben und auf
https://lists.example.org schauen.

== Mehrere Mailinglisten betreiben ==

Wenn mehrere Mailinglisten in einem Account und mit einer Admin-Oberfläche betrieben werden soll, empfiehlt sich die Nutzung von Procmail für den Aufruf von ''mlmmj'' für die jeweiligen Liste mit ihrem Daten-Verzeichnis.

Dazu trägt man in der Date ''.forward'' statt des Aufrufs von ''mlmmj-recieve'' einen Aufruf von ''procmail'' ein:

|/usr/bin/procmail -p

Die Konfiguration von Procmail kann generisch erfolgen. Dazu legt man eine Datei ''.procmailrc'' mit folgendem Inhalt ins $HOME des Users:

SHELL=/bin/sh
HOMEDIR=/home/pacs/xyz00/users/list
MAILDIR=/home/pacs/xyz00/users/list/Maildir
PMDIR=/home/pacs/xyz00/users/list
VERBOSE=yes
LOGFILE=/home/pacs/xyz00/users/list/var/procmail.log
DEFAULT

:0:
* ^X-Original-To: ()\/[^@+]+
|/usr/bin/mlmmj-receive -F -L /home/pacs/xyz00/users/list/mlmmj/${MATCH}/

:0
{ EXITCODE 67 }

Der kryptische reguläre Ausdruck hinter dem Header ''X-Original-To:'' passt auf den Beginn der E-Mail-Adresse bis zum ersten ''@''- oder ''+''-Zeichen. In der Variable ''MATCH'' steht also der Name der Mailingliste, d.h. der Name der Verzeichnisses, in dem die Liste verwaltet wird.

Sehr wichtig ist die Zeile ''DEFAULT'' zu Beginn der ''.procmailrc''. Die Variable ''DEFAULT'' wird von ''procmail'' gesetzt. Wir sorgen mit dieser Zeile dafür, dass sie wieder undefiniert ist. Diese Variable wird intern von ''mlmmj'' benutzt, wenn sie gesetzt ist. Das führt in Kombination mit ''procmail'' zu Fehlfunktionen (vgl. Links).

== Links ==

* http://mlmmj.org/ Projektseite
* https://gitlab.com/mlmmj/ mlmmj auf Gitlab
* https://github.com/tchapi/mlmmj-simple-web-interface ein Admin-Interface in NodeJS
* https://www.tablix.org/~avian/blog/archives/2010/04/the_faulty_default/ Nutzung von mlmmj in Verbindung mit Procmail

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

Gitolite installieren

2021-10-02T08:21:55Z

Deg00-m.website:

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

Gitolite (https://gitolite.com/gitolite/index.html) ist leichtgewichtiger Server für Git Repositories, der in einem HS Webpaket läuft, ohne dass ein Server (mit eigenem Daemon und Port etc.) installiert sein muss. Es macht in einem Webpaket gehostete Repos über SSH zugänglich. Gitolite ist gut geeignet,wenn eine überschaubare Anzahl Repos und User verwaltet werden soll, es wird gesteuert über ein einziges Configfile und Public-Keys die alle zusammen über Git versioniert sind.

== Gitolite einzurichten ist sehr einfach ==

Du brauchst ein SSH-Keypair ('admin'), das dem Gitolite-Admin den Zugang ermöglicht. Dessen Publickey kopiest du in das homedir deines HS-Users.

Per SSH da eingeloggt, schreibst du:

gitolite setup -pk admin.pub

Damit ist Gitolite in dem Webpaket bereits installiert. Es hat die Konfigurationsdatei '.gitolite.rc' und das Verzeichnis '/repositories' erstellt.

In '/repositories' sind bereits zwei Repos eingerichtet, gitolite-admin.git und testing.git.

== Konfiguration ==

Du kannst nun von außerhalb das Admin Repo auf deinen Computer klonen (Achtung, ungeprüft):

git clone xyz00@xyz00.hostsharing.net:gitolite-adminadmin.git

In dem Repo finden sich die zwei Verzeichnisse ''conf'' und ''keydir''.

=== User ===

User entstehen durch gleichnamige Dateien (mit der Endung '.pub') mit den Public-Keys der User im Verzeichnis 'keydir':

me@on-my-computer ~/gitolite-admin » ls keydir
admin.pub anton.pub berta.pub jenkins.pub josef.pub

=== Repositories und Zugriffsrechte ===

Die Konfiguration der Repos und der Zugriffsrechte schreibt man in conf/gitolite.conf, darin kann man auch Gruppen definieren (deren Namen beginnen mit '@'):

# Gruppen
@programmierer = anton josef
@reader = jenkins gitweb anton

# Hier stehen die Repos

repo gitolite-admin
RW+ = admin

repo example.de
RW+ = @programmierer
R = @reader

repo example-data
R = @reader
RW+ = @programmierer

repo example-blog
RW+ = anton berta

Man definiert also einfach ein neues Repo und die Zugriffsrechte mit
einem Eintrag in gitolite.conf.

=== Konfiguration versionieren und pushen ===

Das kann man nun wie in Git üblich committen und pushen:

git add -A
git commit -m "Start Gitolite Administration"
git push

Und dann passiert folgendes: Gitolite packt die Keys der User in .ssh/authorized_keys mit einem Command voran, das die Gitolite Shell aufruft.

== Verwendung ==

Und je nachdem wie es in gitolite.conf definiert wurde, haben die User jetzt per SSH Zugriff auf die Repositories, sie können sich einloggen, bekommen aber nur ein Listing zu sehen, das ihre Repos zeigt.

Beachte den Verweis auf das Identity-file:

me@on-my-computer » ssh -i admin xyz00@xyz00.hostsharing.net
PTY allocation request failed on channel 0
hello admin, this is xyz@h00 running gitolite3 3.6.11-2 (Debian) on git 2.20.1

R W gitolite-admin
R W example.de
R W example-data
R W example-blog
Connection to deg01.hostsharing.net closed.

Die User können die Repos klonen, und – wenn erlaubt – bearbeiten und wieder pushen.

Gitolite installieren

2021-10-02T08:20:13Z

Deg00-m.website:

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
Gitolite ist leichtgewichtiger Server für Git Repositories, der in einem HS Webpaket läuft, ohne dass ein Server (mit eigenem Daemon und Port etc.) installiert sein muss. Es macht in einem Webpaket gehostete Repos über SSH zugänglich. Gitolite ist gut geeignet,wenn eine überschaubare Anzahl Repos und User verwaltet werden soll, es wird gesteuert über ein einziges Configfile und Public-Keys die alle zusammen über Git versioniert sind.

== Gitolite einzurichten ist sehr einfach ==

Du brauchst ein SSH-Keypair ('admin'), das dem Gitolite-Admin den Zugang ermöglicht. Dessen Publickey kopiest du in das homedir deines HS-Users.

Per SSH da eingeloggt, schreibst du:

gitolite setup -pk admin.pub

Damit ist Gitolite in dem Webpaket bereits installiert. Es hat die Konfigurationsdatei '.gitolite.rc' und das Verzeichnis '/repositories' erstellt.

In '/repositories' sind bereits zwei Repos eingerichtet, gitolite-admin.git und testing.git.

== Konfiguration ==

Du kannst nun von außerhalb das Admin Repo auf deinen Computer klonen (Achtung, ungeprüft):

git clone xyz00@xyz00.hostsharing.net:gitolite-adminadmin.git

In dem Repo finden sich die zwei Verzeichnisse ''conf'' und ''keydir''.

=== User ===

User entstehen durch gleichnamige Dateien (mit der Endung '.pub') mit den Public-Keys der User im Verzeichnis 'keydir':

me@on-my-computer ~/gitolite-admin » ls keydir
admin.pub anton.pub berta.pub jenkins.pub josef.pub

=== Repositories und Zugriffsrechte ===

Die Konfiguration der Repos und der Zugriffsrechte schreibt man in conf/gitolite.conf, darin kann man auch Gruppen definieren (deren Namen beginnen mit '@'):

# Gruppen
@programmierer = anton josef
@reader = jenkins gitweb anton

# Hier stehen die Repos

repo gitolite-admin
RW+ = admin

repo example.de
RW+ = @programmierer
R = @reader

repo example-data
R = @reader
RW+ = @programmierer

repo example-blog
RW+ = anton berta

Man definiert also einfach ein neues Repo und die Zugriffsrechte mit
einem Eintrag in gitolite.conf.

=== Konfiguration versionieren und pushen ===

Das kann man nun wie in Git üblich committen und pushen:

git add -A
git commit -m "Start Gitolite Administration"
git push

Und dann passiert folgendes: Gitolite packt die Keys der User in .ssh/authorized_keys mit einem Command voran, das die Gitolite Shell aufruft.

== Verwendung ==

Und je nachdem wie es in gitolite.conf definiert wurde, haben die User jetzt per SSH Zugriff auf die Repositories, sie können sich einloggen, bekommen aber nur ein Listing zu sehen, das ihre Repos zeigt.

Beachte den Verweis auf das Identity-file:

me@on-my-computer » ssh -i admin xyz00@xyz00.hostsharing.net
PTY allocation request failed on channel 0
hello admin, this is xyz@h00 running gitolite3 3.6.11-2 (Debian) on git 2.20.1

R W gitolite-admin
R W example.de
R W example-data
R W example-blog
Connection to deg01.hostsharing.net closed.

Die User können die Repos klonen, und – wenn erlaubt – bearbeiten und wieder pushen.

Diskussion:Login mit SSH

2021-09-29T08:29:23Z

Deg00-m.website: Neuer Abschnitt /* Login mit SSH-Keypairs beschreiben */

Anleitung für windowsbenutzer fehlt-werde ich nachreichen-Jochen (01:42, 18. Feb. 2009 Dgy00)

== Login mit SSH-Keypairs beschreiben ==

Beschreibung von ssh-keygen, ssh-copy-id und authorized_keys und der entsprechenden Funktionalität fehlt hier. --[[Benutzer:Deg00-m.website|ChristofT]] ([[Benutzer Diskussion:Deg00-m.website|Diskussion]]) 10:29, 29. Sep. 2021 (CEST)

Login mit SSH

2021-09-29T08:27:09Z

Deg00-m.website: Baustelle

{{Baustelle}}

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

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

Username: '''xyz00'''

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

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

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

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

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

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

== Login ==

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

ssh xyz00@xyz00.hostsharing.net

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

<pre><nowiki>
Last login: Fri Apr 19 06:43:45 2002 from p5081f0c7.dip.t-dialin.net on pts/7

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

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

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

xyz0@hopi:~$ █
</nowiki></pre>

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

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

== Passwort ändern ==

Eine Änderung des Passwortes geht dem Befehl passwd:

<pre><nowiki>
xyz00@hopi:~$ passwd

Changing password for xyz00

(current) UNIX password: ALTESPASSWORT

Enter new UNIX password: NEUESPASSWORT

Retype new UNIX password: NEUESPASSWORT

passwd: password updated successfully

xyz00@hopi:~$ █

</nowiki></pre>

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

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

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

==Sitzung beenden==

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

<pre><nowiki>
xyz00@hopi:~$ exit
logout
Connection to xyz00.hostsharing.net closed.
</nowiki></pre>

== Zusätzliche Möglichkeiten ==

== Bestimmte Shell Kommandos automatisch ausführen ==

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

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

== welcher Editor in der shell ==

1. manuell Einloggen und:
<pre>
VISUAL=nano
export VISUAL
EDITOR=nano
export EDITOR
</pre>

2. in der bash geht es auch kürzer:
<pre>export EDITOR=nano
export VISUAL=nano

3. automatisch bei jedem Login

Mit obigen Kommandos in der ~/.bash_profile-Datei.
</pre>

==Weiterführende Links==

[[HS-Server:SSH-Hostkeys]]

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

Gitolite installieren

2021-09-29T08:25:28Z

Deg00-m.website:

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
Gitolite ist eine Art Server für Git Repositories ohne dass ein Server (mit eigenem Daemon und Port etc.) installiert sein muss. Es macht in einem Webpaket gehostete Repos über SSH zugänglich. Ist gut für eine Handvoll Repos und ein paar User, wird gesteuert über ein Configfile und Public-Keys die alle zusammen über Git versioniert sind.

Gitolite einzurichten ist sehr einfach (wenn man rausbekommen hat wie es funktioniert).

Du brauchst ein SSH-Keypair ('admin'), das dem Gitolite-Admin den Zugang ermöglicht. Dessen Publickey kopiest du in das homedir deines HS-Users.

Per SSH da eingeloggt, schreibst du:

gitolite setup -pk admin.pub

Damit ist Gitolite in dem Webpaket installiert. Es hat die Konfigurationsdatei '.gitolite.rc' und das Verzeichnis '/repositories' erstellt.

In '/repositories' sind bereits zwei Repos eingerichtet, gitolite-admin.git und testing.git.

Du kannst nun von außerhalb das Admin Repo auf deinen Computer klonen (achtung, ungeprüft):

git clone xyz00@xyz00.hostsharing.net:gitolite-adminadmin.git

In dem Repo finden sich die zwei Verzeichnisse conf und keydir.

Die Konfiguration der Repos und der Zugriffsrechte schreibt man in conf/gitolite.conf, darin kann man auch Gruppen definieren (deren Namen beginnen mit '@'):

# Gruppen
@programmierer = anton josef
@reader = jenkins gitweb anton

# Hier stehen die Repos

repo gitolite-admin
RW+ = admin

repo example.de
RW+ = @programmierer
R = @reader

repo example-data
R = @reader
RW+ = @programmierer

repo example-blog
RW+ = anton berta

Man definiert also einfach ein neues Repo und die Zugriffsrechte mit
einem Eintrag in gitolite.conf.

User entstehen durch gleichnamige Dateien (mit der Endung '.pub') mit den Public-Keys der User im Verzeichnis 'keydir':

me@on-my-computer ~/gitolite-admin » ls keydir
admin.pub anton.pub berta.pub jenkins.pub josef.pub

Das kann man nun wie in Git üblich committen und pushen:

git add -A
git commit -m "Start Gitolite Administration"
git push

Und dann passiert folgendes: Gitolite packt die Keys der User in .ssh/authorized_keys mit einem Command voran, das die Gitolite Shell aufruft.

Und je nachdem wie es in gitolite.conf definiert wurde, haben die User jetzt per SSH Zugriff auf die Repositories, sie können sich einloggen, bekommen aber nur ein Listing zu sehen, das ihre Repos zeigt.

Beachte den Verweis auf das Identity-file:

me@on-my-computer » ssh -i admin xyz00@xyz00.hostsharing.net
PTY allocation request failed on channel 0
hello admin, this is xyz@h00 running gitolite3 3.6.11-2 (Debian) on git 2.20.1

R W gitolite-admin
R W example.de
R W example-data
R W example-blog
Connection to deg01.hostsharing.net closed.

Die User können die Repos klonen, und – wenn erlaubt – bearbeiten und wieder pushen.

Gitolite installieren

2021-09-29T08:23:04Z

Deg00-m.website: Kategorie

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
Gitolite ist eine Art Server für Git Repositories ohne dass ein Server (mit eigenem Daemon und Port etc.) installiert sein muss. Es macht in einem Webpaket gehostete Repos über SSH zugänglich. Ist gut für eine Handvoll Repos und ein paar User, wird gesteuert über ein Configfile und Public-Keys die alle zusammen über Git versioniert sind.

Gitolite einzurichten ist sehr einfach (wenn man rausbekommen hat wie es funktioniert).

Du brauchst ein SSH-Keypair ('admin'), das den später Gitolite-Admin Zugang ermöglicht. Dessen Publickey kopiest du in das homedir deines HS-Users.

Per SSH da eingeloggt, schreibst du:

gitolite setup -pk admin.pub

Damit ist Gitolite in dem Webpaket installiert. Es hat die Konfigurationsdatei '.gitolite.rc' und das Verzeichnis '/repositories' erstellt.

In '/repositories' sind bereits zwei Repos eingerichtet, gitolite-admin.git und testing.git.

Du kannst nun von außerhalb das Admin Repo auf deinen Computer klonen (achtung, ungeprüft):

git clone xyz00@xyz00.hostsharing.net:gitolite-adminadmin.git

In dem Repo finden sich die zwei Verzeichnisse conf und keydir.

Die Konfiguration der Repos und der Zugriffsrechte schreibt man in conf/gitolite.conf, darin kann man auch Gruppen definieren (deren Namen beginnen mit '@'):

# Gruppen
@programmierer = anton josef
@reader = jenkins gitweb anton

# Hier stehen die Repos

repo gitolite-admin
RW+ = admin

repo example.de
RW+ = @programmierer
R = @reader

repo example-data
R = @reader
RW+ = @programmierer

repo example-blog
RW+ = anton berta

Man definiert also einfach ein neues Repo und die Zugriffsrechte mit
einem Eintrag in gitolite.conf.

User entstehen durch gleichnamige Dateien (mit der Endung '.pub') mit den Public-Keys der User im Verzeichnis 'keydir':

me@on-my-computer ~/gitolite-admin » ls keydir
admin.pub anton.pub berta.pub jenkins.pub josef.pub

Das kann man nun wie in Git üblich committen und pushen:

git add -A
git commit -m "Start Gitolite Administration"
git push

Und dann passiert folgendes: Gitolite packt die Keys der User in .ssh/authorized_keys mit einem Command voran, das die Gitolite Shell aufruft.

Und je nachdem wie es in gitolite.conf definiert wurde, haben die User jetzt per SSH Zugriff auf die Repositories, sie können sich einloggen, bekommen aber nur ein Listing zu sehen, das ihre Repos zeigt.

Beachte den Verweis auf das Identity-file:

me@on-my-computer » ssh -i admin xyz00@xyz00.hostsharing.net
PTY allocation request failed on channel 0
hello admin, this is xyz@h00 running gitolite3 3.6.11-2 (Debian) on git 2.20.1

R W gitolite-admin
R W example.de
R W example-data
R W example-blog
Connection to deg01.hostsharing.net closed.

Die User können die Repos klonen, und – wenn erlaubt – bearbeiten und wieder pushen.

Gitolite installieren

2021-09-29T08:21:35Z

Deg00-m.website: Gitolite installieren, erster Entwurf

Gitolite ist eine Art Server für Git Repositories ohne dass ein Server (mit eigenem Daemon und Port etc.) installiert sein muss. Es macht in einem Webpaket gehostete Repos über SSH zugänglich. Ist gut für eine Handvoll Repos und ein paar User, wird gesteuert über ein Configfile und Public-Keys die alle zusammen über Git versioniert sind.

Gitolite einzurichten ist sehr einfach (wenn man rausbekommen hat wie es funktioniert).

Du brauchst ein SSH-Keypair ('admin'), das den später Gitolite-Admin Zugang ermöglicht. Dessen Publickey kopiest du in das homedir deines HS-Users.

Per SSH da eingeloggt, schreibst du:

gitolite setup -pk admin.pub

Damit ist Gitolite in dem Webpaket installiert. Es hat die Konfigurationsdatei '.gitolite.rc' und das Verzeichnis '/repositories' erstellt.

In '/repositories' sind bereits zwei Repos eingerichtet, gitolite-admin.git und testing.git.

Du kannst nun von außerhalb das Admin Repo auf deinen Computer klonen (achtung, ungeprüft):

git clone xyz00@xyz00.hostsharing.net:gitolite-adminadmin.git

In dem Repo finden sich die zwei Verzeichnisse conf und keydir.

Die Konfiguration der Repos und der Zugriffsrechte schreibt man in conf/gitolite.conf, darin kann man auch Gruppen definieren (deren Namen beginnen mit '@'):

# Gruppen
@programmierer = anton josef
@reader = jenkins gitweb anton

# Hier stehen die Repos

repo gitolite-admin
RW+ = admin

repo example.de
RW+ = @programmierer
R = @reader

repo example-data
R = @reader
RW+ = @programmierer

repo example-blog
RW+ = anton berta

Man definiert also einfach ein neues Repo und die Zugriffsrechte mit
einem Eintrag in gitolite.conf.

User entstehen durch gleichnamige Dateien (mit der Endung '.pub') mit den Public-Keys der User im Verzeichnis 'keydir':

me@on-my-computer ~/gitolite-admin » ls keydir
admin.pub anton.pub berta.pub jenkins.pub josef.pub

Das kann man nun wie in Git üblich committen und pushen:

git add -A
git commit -m "Start Gitolite Administration"
git push

Und dann passiert folgendes: Gitolite packt die Keys der User in .ssh/authorized_keys mit einem Command voran, das die Gitolite Shell aufruft.

Und je nachdem wie es in gitolite.conf definiert wurde, haben die User jetzt per SSH Zugriff auf die Repositories, sie können sich einloggen, bekommen aber nur ein Listing zu sehen, das ihre Repos zeigt.

Beachte den Verweis auf das Identity-file:

me@on-my-computer » ssh -i admin xyz00@xyz00.hostsharing.net
PTY allocation request failed on channel 0
hello admin, this is xyz@h00 running gitolite3 3.6.11-2 (Debian) on git 2.20.1

R W gitolite-admin
R W example.de
R W example-data
R W example-blog
Connection to deg01.hostsharing.net closed.

Die User können die Repos klonen, und – wenn erlaubt – bearbeiten und wieder pushen.

Diskussion:Mnogosearch installieren

2021-09-29T06:42:54Z

Deg00-m.website: Neuer Abschnitt /* Baustelle Kompilieren */

== Baustelle Kompilieren ==

Typo 3 ist veraltet, die Kompilierung sollte generisch beschrieben werden.

Mnogosearch installieren

2021-09-29T06:41:49Z

Deg00-m.website: /* Kompilieren der Mnogosearch aus den Sourcen */

== Die Suchmaschine für die eigene Webseite ==

[http://www.mnogosearch.org/ Mnogosearch] ist eine Suchmaschine, die für die eigene Webseite verwendet werden kann. Sie ist für Webseiten bis einige tausend Seiten und Traffic, wie er auf einem Shared-Webserver vorkommt, gut geeignet. Die Software muss aus den Sourcen selbst [[#Kompilieren der Mnogosearch aus den Sourcen|kompiliert]] werden und kann mit Datenbanken wie Sqlite3, Mysql oder Postgresql eingesetzt werden.

Hier wird eine Grundinstallation beschrieben. Mnogosearch ist eine sehr umfangreiche Software mit mannigfaltigen Konfigurationsmöglichkeiten. Für die weitergehende Konfiguration muss auf die Dokumentation von [http://www.mnogosearch.org/ Mnogosearch] verwiesen werden.

Mnogosearch ist sehr mächtig und kann vor allen Dingen mit Unicode umgehen, es können viele Dinge eingestellt werden. In dieser Konfiguration funktioniert der indexer als "Crawler", er surft die eigene Webseite ab und speichert die Einträge für spätere Suchergebnisse. Dabei beachtet er die /robots.txt.

Es können aber auch das Dateisystem und verschiedene Dokumentarten durchsucht werden, es können Bereiche der Webseite ausgeschlossen werden und es können Sektionen in Webseiten definiert werden, die für die Auflistung der Suchergebnisse als wichtiger gewertet werden. Diese Dinge müssen zusätzlich konfiguriert werden. Dies ist nur eine Grundkonfiguration, die aber in den meisten Fällen ausreichen dürfte.

== Konfiguration ==

Für die Datenbank und die Konfigurationsdatei wird am besten pro Domain ein Verzeichnis "mnogosearch" eingerichtet und da die Konfigurationsdatei indexer.conf erstellt. Diese Datei kann auch von /etc/mnogosearch/indexer.conf kopiert werden und muss dann entsprechend geändert werden.

<pre>
# cd /home/doms/example.com
# mkdir mnogosearch
# cd mnogosearch
# touch indexer.conf
# edit indexer.conf
</pre>

=== Inhalt von indexer.conf ===

Dies ist die stark gekürzte und auf Notwendiges reduzierte Fassung. Ganz zu Beginn wird die Datenbankdatei und am Ende der zu indizierende Webserver definiert:

<pre>
###########################################################################
# DBAddr <URL-style database description>
# Options (type, host, database name, port, user and password)
# to connect to SQL database.
# Should be used before any other commands.
# Has global effect for whole config file.
# Format:
#DBAddr <DBType>:[//[DBUser[:DBPass]@]DBHost[:DBPort]]/DBName/[?dbmode=mode]

DBAddr sqlite://mnogo:@/home/doms/example.com/mnogosearch/mnogosearch.db/?dbmode=multi

# Default LocalCharset is iso-8859-1 (latin1).

# Full UNICODE
# Folgendes auskommentieren für iso-8859-1
LocalCharset UTF-8

###########################################################################
# StopwordFile <filename>
# Load stop words from the given text file. You may specify either absolute
# file name or a name relative to mnoGoSearch /etc directory. You may use
# several StopwordFile commands.
#
StopwordFile stopwords/de.sl

#######################################################################
# HTTPHeader <header>
# You may add your desired headers in indexer HTTP request.
# You should not use "If-Modified-Since","Accept-Charset" headers,
# these headers are composed by indexer itself.
# "User-Agent: mnoGoSearch/version" is sent too, but you may override it.
# Command has global effect for all configuration file.
#
HTTPHeader "User-Agent: example.com-indexer"

##########################################################################
# Section 2.
# URL control configuration.

# Allow Configuration
# Examples
# Allow everything:
#Allow *
# Allow everything but .php .cgi .pl extensions case insensitively using regex:
#Allow NoMatch Regex \.php$|\.cgi$|\.pl$
# Allow .HTM extension case sensitively:
#Allow Case *.HTM

Allow *.html

##########################################################################
#Disallow [Match|NoMatch] [NoCase|Case] [String|Regex] <arg> [<arg> ... ]
#
# Examples:
# Disallow URLs that are not in udm.net domains using "string" match:
#Disallow NoMatch *.udm.net/*
# Disallow any except known extensions and directory index using "regex" match:
#Disallow NoMatch Regex \/$|\.htm$|\.html$|\.shtml$|\.phtml$|\.php$|\.txt$
# Exclude cgi-bin and non-parsed-headers using "string" match:
#Disallow */cgi-bin/* *.cgi */nph-*
# Exclude anything with '?' sign in URL. Note that '?' sign has a
# special meaning in "string" match, so we have to use "regex" match here:
#Disallow Regex \?

# Exclude some known extensions using fast "String" match:
Disallow *.b *.sh *.md5 *.rpm
Disallow *.arj *.tar *.zip *.tgz *.gz *.z *.bz2
Disallow *.lha *.lzh *.rar *.zoo *.ha *.tar.Z
Disallow *.gif *.jpg *.jpeg *.bmp *.tiff *.tif *.xpm *.xbm *.pcx
Disallow *.vdo *.mpeg *.mpe *.mpg *.avi *.movie *.mov *.wmv
Disallow *.mid *.mp3 *.rm *.ram *.wav *.aiff *.ra
Disallow *.vrml *.wrl *.png *.ico *.psd *.dat
Disallow *.exe *.com *.cab *.dll *.bin *.class *.ex_
Disallow *.tex *.texi *.xls *.doc *.texinfo
Disallow *.rtf *.pdf *.cdf *.ps
Disallow *.ai *.eps *.ppt *.hqx
Disallow *.cpt *.bms *.oda *.tcl
Disallow *.o *.a *.la *.so
Disallow *.pat *.pm *.m4 *.am *.css
Disallow *.map *.aif *.sit *.sea
Disallow *.m3u *.qt

# Exclude Apache directory list in different sort order using "string" match:
Disallow *D=A *D=D *M=A *M=D *N=A *N=D *S=A *S=D

# More complicated case. RAR .r00-.r99, ARJ a00-a99 files
# and UNIX shared libraries. We use "Regex" match type here:
Disallow Regex \.r[0-9][0-9]$ \.a[0-9][0-9]$ \.so\.[0-9]$

################################################################
# Section 3.
# Mime types and external parsers.

################################################################
#AddType [String|Regex] [Case|NoCase] <mime type> <arg> [<arg>...]
# This command associates filename extensions (for services
# that don't automatically include them) with their mime types.
# Currently "file:" protocol uses these commands.
# Use optional first two parameter to choose comparison type.
# Default type is "String" "NoCase" (case sensitive string match with
# '?' and '*' wildcards for one and several characters correspondingly).
#
AddType image/x-xpixmap *.xpm
AddType image/x-xbitmap *.xbm
AddType image/gif *.gif

AddType text/plain *.txt *.pl *.js *.h *.c *.pm *.e
AddType text/html *.html *.htm

AddType text/rtf *.rtf
AddType application/pdf *.pdf
AddType application/msword *.doc
AddType application/vnd.ms-excel *.xls
AddType text/x-postscript *.ps

# Default unknown type for other extensions:
AddType application/unknown *.*

# Use ParserTimeOut to specify amount of time for parser execution
# to avoid possible indexer hang.

ParserTimeOut 300

#######################################################################
# Section 5.
# Servers configuration.

#######################################################################
# Document sections.
#
# Format is:
#
# Section <string> <number> <maxlen> [clone] [sep] [{expr} {repl}]
#
# where <string> is a section name and <number> is section ID
# between 0 and 255. Use 0 if you don't want to index some of
# these sections. It is better to use different sections IDs
# for different documents parts. In this case during search
# time you'll be able to give different weight to each part
# or even disallow some sections at a search time.
# <maxlen> argument contains a maximum length of section
# which will be stored in database.
# "clone" is an optional parameter describing whether this
# section should affect clone detection. It can
# be "DetectClone" or "cdon", or "NoDetectClone" or "cdoff".
# By default, url.* section values are not taken in account
# for clone detection, while any other sections take part
# in clone detection.
# "sep" is an optional argument to specify a separator between
# parts of the same section. It is a space character by default.
# "expr" and "repl" can be used to extract user defined sections,
# for example pieces of text between the given tags. "expr" is
# a regular expression, "repl" is a replacement with $1, $2, etc
# meta-characters designating matches "expr" matches.

# Standard HTML sections: body, title

Section body 1 256
Section title 2 128

# META tags
# For example <META NAME="KEYWORDS" CONTENT="xxxx">
#

Section meta.keywords 3 128
Section meta.description 4 128

# HTTP headers example, let's store "Server" HTTP header
#
#
#Section header.server 5 64

# Document's URL parts

Section url.file 6 0
Section url.path 7 0
Section url.host 8 0
Section url.proto 9 0

# CrossWords

Section crosswords 10 0

#
# If you use CachedCopy for smart excerpts (see below),
# please keep Charset section active.
#
Section Charset 11 32

Section Content-Type 12 64
Section Content-Language 13 16

# Uncomment the following lines if you want tag attributes
# to be indexed

#Section attribute.alt 14 128
#Section attribute.label 15 128
#Section attribute.summary 16 128
#Section attribute.title 17 128
#Section attribute.face 27 0

# Uncomment the following lines if you want use NewsExtensions
# You may add any Newsgroups header to be indexed and stored in urlinfo table

#Section References 18 0
#Section Message-ID 19 0
#Section Parent-ID 20 0

# Uncomment the following lines if you want index MP3 tags.
#Section MP3.Song 21 128
#Section MP3.Album 22 128
#Section MP3.Artist 23 128
#Section MP3.Year 24 128

# Comment this line out if you don't want to store "cached copies"
# to generate smart excerpts at search time.
# Don't forget to keep "Charset" section active if you use cached copies.
# NOTE: 3.2.18 has limits for CachedCopy size, 32000 for Ibase and
# 15000 for Mimer. Other databases do not have limits.
# If indexer fails with 'string too long' error message then reduce
# this number. This will be fixed in the future versions.
#
Section CachedCopy 25 64000

# A user defined section example.
# Extract text between <h1> and </h1> tags:
#Section h1 26 128 "<h1>(.*)</h1>" $1

#########################################################################
#Server [Method] [SubSection] <URL> [alias]
# This is the main command of the indexer.conf file. It's used
# to describe web-space you want to index. It also inserts
# given URL into database to use it as a start point.
# You may use "Server" command as many times as a number of different
# servers or their parts you want to index.

# To index whole server "www.example.com":
Server http://www.example.com/
</pre>

'''Unbedingt im ganzen Dokument example.com durch den eigenen Domainnamen ersetzen!'''

=== Datenbank erstellen ===

Die Datenbank wird mit dem Programm '''indexer''' erstellt. Dabei muss indexer natürlich (und wie bei jedem Aufruf) der Pfad zur eigenen Konfiguration mitgeteilt werden.

<pre>
# /usr/sbin/indexer -Ecreate /home/doms/example.com/mnogosearch/indexer.conf
</pre>

==== Erster Indexlauf ====

<pre>
# /usr/sbin/indexer -a /home/doms/example.com/mnogosearch/indexer.conf
</pre>

Mit diesem Befehl wird die Datenbank gefüllt. Wir haben in der Konfigurationsdatei definiert, dass alle Seiten mit der Endung .html unter http://www.example.com/ durchsucht und indiziert werden.

Die Option -a ersetzt alle vorhandenen Einträge.

=== Die Suche auf der eigenen Webseite ===

Damit die Suche funktionieren kann, legen wir einen symbolischen Link zu dem Suchprogramm /usr/lib/cgi-bin/search.cgi in das eigene cgi-Verzeichnis:

<pre>
# ln -s /usr/lib/cgi-bin/search.cgi /home/doms/example.com/cgi/search.cgi
</pre>

Das zugehörige Suchformular kann entweder von /etc/mnogosearch/search.htm in das eigene Webverzeichnis kopiert (mit der Endung "zhtml" - siehe weiter unten) und anschließend editiert werden. Wichtig ist der Verweis auf die eigene Datenbankdatei in der Sektion "variables" ganz zu Beginn:

:'''DBAddr sqlite://mnogo:@/home/doms/example.com/mnogosearch/mnogosearch.db/?dbmode=multi'''

==== Minimales Suchformular in Deutsch ====

Folgendes Formular ist bereits eingedeutscht und kann direkt als /home/doms/example.com/subs/www/suche.zhtml abgespeichert werden (man beachte die Endung "zhtml"):

<pre><nowiki>
# start



<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=$&(BrowserCharset)" />
<title>Suche: $&(q)</title>
<style type="text/css">
body { background-color: #fff; }
a { color: #00c; }
div.center { text-align: center; }
table.grey { background-color: #eee; width: 100%; }
table.white { background-color: #fff; width: 100%; }
img.logo { border: none; }
</style>
</head>

<body>

<div class="center">
<form method="get" action="">
<table class="grey" summary="">
<tr>
<td>
<br /> Suche nach:
<INPUT TYPE="text" NAME="q" VALUE="$&(q)" SIZE=50 />
<INPUT TYPE="submit" NAME="cmd" VALUE="Suche!" />
<br /><br />
</td>
</tr>
</table>
</form>
</div>




<table bgcolor=#EEEEEE width=100% border=0>
<tr>
<td>
<small>Suche nach <b>$&(q)</b>.</small>
<small>Gefunden: <b>$&(WE)</b>.</small>
</td>
<td>
<small>Ergebnisse <b>$(first)-$(last)</b> von <B>$(total)</B>.</small>
<small>Die Suche dauerte <b>$(SearchTime)</b> Sekunden</small>
</td>
</tr>
<tr><td colspan="2">
Sortieren:
<!IF NAME="s" CONTENT="DRP">
<a href="$(FirstPage)&s=RPD">Relevanz</a> | <b>Datum</b> | <a href="$(FirstPage)&s=SRPD&su=title">Titel</a>
<!ELSEIF NAME="s" CONTENT="SRPD">
<a href="$(FirstPage)&s=RPD">Relevanz</a> | <a href="$(FirstPage)&s=DRP">Datum</a> | <b>Titel</b>
<!ELSE>
<b>Relevanz</b> | <a href="$(FirstPage)&s=DRP">Datum</a> | <a href="$(FirstPage)&s=SRPD&su=title">Titel</a>
<!ENDIF>
</td></tr>
</table>
<br />




<DL>
<!IFNOT NAME="Alias" CONTENT=""><!COPY NAME="URL" CONTENT="Alias"><!ENDIF>
<!IF NAME="fmt" CONTENT="url">
<DT>$(Order).
<a href="$(URL)">$(URL:40)</a>
<small>[<b>$(Score)</b>]</small>
<!ELSEIF NAME="fmt" CONTENT="short">
<DT>$(Order).
<a href="$(URL)">
<!IF NAME="Title" CONTENT="">$(URL:40)<!ELSE>$&(Title)<!ENDIF>
</a>
<small>[<b>$(Score)</b>]</small>
<!ELSE>
<DT>$(Order).
<a href="$(URL)">
<!IF NAME="Title" CONTENT="">$(URL:40)<!ELSE>$&(Title)<!ENDIF>
</a>
<small>
[
<b>$(Score)</b>
<!IFNOT NAME="Pop_Rank" CONTENT="0.00000">Popularity: <b>$(Pop_Rank)</b><!ENDIF>
]
</small>
<DD>
<table width=60%>
<tr>
<td>
<small>$&(Body)...</small>
</td>
</tr>
<tr>
<td>
<UL>
<li>
<small>
<A HREF="$(URL)">$(URL:40)</A>
<font color="#008800">
- $(Content-Length) bytes [$(Content-Type)]
- $(Last-Modified)
<!IFNOT NAME="stored_href" CONTENT="">
<DD><small>[<a href="$(stored_href)">Cached copy</a>]</small></DD>
<!ENDIF>
<!IFNOT NAME="sitelimit_href" CONTENT="">
<!IFGT NAME="PerSite" CONTENT="0">
<DD><small>
[<a href="$(sitelimit_href)">More results from this site ($(PerSite) total) </a>]
</small></DD>
<!ENDIF>
<!ENDIF>
</font>
</small>
<BR>
$(CL)
</UL>
$(STORED)

</td>
</tr>
</table>

<!ENDIF>
</DL>



<table width=100% bgcolor=#FFFFFF>
<tr>
<td align=center>
<TABLE BORDER=0>
<TR><TD><small>Ergebnis Seiten: <TD> </TD></TD>$(NL)$(NB)$(NR)</TD></TR>
</TABLE>
</td>
</tr>
</table>



<!IFNOT NAME="Alias" CONTENT=""><!COPY NAME="URL" CONTENT="Alias"><!ENDIF>
<li>
<small>
<A HREF="$(URL)">$(URL:40)</A>
<font color="#008800">
- $(Content-Length) bytes
- $(Last-Modified)
</font>
</small>



<TD><small><A HREF="$(NH)"><< Vorherige</A></TD>



<TD><small><FONT COLOR=gray><< Vorherige</FONT></TD>



<TD><small><A HREF="$(NH)">$(NP)</A></TD>



<TD><small>$(NP)</TD>



<TD><small><A HREF="$(NH)">Nächste >></A></TD>



<TD><small><FONT COLOR=gray>Nächste >></FONT></TD>



<!IFNOT NAME="WS" CONTENT="">
Meinten Sie <b><a href="?q=$%(WS)">$(WS)</a></b>?
<!ENDIF>
<table bgcolor=#EEEEEE width=100%>
<tr>
<td>
<small>Suche nach <b>$&(q)</b>.</small>
<small>Suchergebnisse: <b>$&(WE)</b></small>
</td>
</tr>
</table>

<p>
Sorry, Ihre Suche nach <b>$&(q)</b> hat kein Ergebnis.<br>
Es wurden keine Dokumente gefunden, die <b>"$&(q)" enthalten</b>.<br>

<p>
Hinweise:
<UL>
<LI> Stellen Sie sicher, dass Ihre Wörter richtig geschrieben sind.
<LI> Versuchen Sie andere Suchworte.
<LI> Versuchen Sie allgemeinere Suchwörter.
</UL>



<div class="center">Bitte geben Sie eines oder mehrere Wörter ein und dücken Sie Suche.</div>



<CENTER>
<FONT COLOR="#FF0000">Es ist ein Fehler aufgetreten!</FONT>
<P><B>$(E)</B>
</CENTER>



<table class="grey" summary="">
<tr><td> </td></tr>
</table>

</body>
</html>



<BASE HREF="$(URL)">

<table border="1" cellpadding="2" cellspacing="0"><tr>
<td><b>Document ID:</b> $(ID)</td>
<td><b>Last modified:</b> $(Last-Modified)</td>
<td><b>Language:</b> $(Content-Language)</td>
<td><b>Charset:</b> $(Charset)</td>
<td><b>Size:</b> $(Content-Length)</td>
</tr></table>
<hr>



$^(document)





</nowiki></pre>

==== suche.zhtml sucht search.cgi ====

Das Suchformular hat keine "action" definiert, es wird per .htaccess an '''search.cgi''' als Template übergeben:

Wenn noch nicht vorhanden, im gleichen Verzeichnis, in dem das Suchformulat liegt (in diesem Fall ~/doms/example.com/subs/www), eine Datei .htaccess erstellen und editieren:

<pre>
# touch .htaccess
# edit .htaccess
</pre>

Und da folgendes reinschreiben (vorausgesetzt, das Formular heißt suche.zhtml):

<pre>
AddType text/html .zhtml
AddHandler zhtml .zhtml
Action zhtml /home/doms/example.com/cgi/search.cgi
</pre>

Nun kann das Suchformular im Browser angezeigt und verwendet werden:

<nowiki>http://www.example.com/suche.zhtml</nowiki>

Es gibt etliche weitere Möglichkeiten, search.cgi zu benutzen, sie stehen in der Dokumentation.

=== Cronjob zum Update der Suchdatenbank in der Nacht ===

Sollten sich die Webseiten öfter mal ändern, ist es sinnvoll, die Suchdatenbank nachts zu aktualisieren. Die Datei für die eigenen Cronjobs wird editiert:

<pre>
# crontab -e
</pre>

und reingeschrieben wird das:

<pre>
# suche mnogosearch indexer
19 23 * * * nice indexer /home/doms/example.com/mnogosearch/indexer.conf
</pre>

'''Bitte eine andere Uhrzeit wählen, damit nicht alle indexer-Jobs um 23:19 Uhr anlaufen!!!'''

== Kompilieren der Mnogosearch aus den Sourcen ==

{{Baustelle}}

Diese Anleitung ist sehr auf die Zusammenarbeit mit dem CMS TYPO3 ausgerichtet. So sind zum Beispiel die Konfigurationseinstellungen zum kompilieren aus dem Manual der TYPO3 Extension [http://typo3.org/documentation/document-library/extension-manuals/mnogosearch/2.2.2/view/1/3/ mnogosearch] entnommen.
Im Grunde bin ich einfach den Anweisungen dort gefolgt, mußte aber wegen HS-spezifischen Gründen an manchen Stellen einen anderen Weg gehen.

Ich habe Mnogosearch mit einem Domainuser kompiliert. Ich denke das das grundsätzlich auch mit einem Paketadmin funktioniert, aber eventuell zu unsicher ist.

=== Runterladen und auspacken ===
Zuerst wechseln wir ins Homeverzeichnis (~) des Users, laden uns den Quellcode runter und entpacken das Archiv.

<pre>
cd ~
// stets die neueste Version benutzen
wget http://www.mnogosearch.org/Download/mnogosearch-3.3.9.tar.gz
tar xvf mnogosearch-3.3.9.tar.gz
</pre>

=== Anpassen der Dateien ===

Sollte man ausschließend eine MySQL Datenbank verwenden, muß vor dem kompilieren die Dateien ./configure.in und ./configure bearbeiten.
In beiden Dateien suchen wir nach dem String ''HAVE_PGSQL'' und ändern die ''1'' in eine ''0''.
<pre>
cd mnogosearch-3.3.9
$yourEditor configure.in
AC_DEFINE([HAVE_PGSQL], [1], [Define if you want to use PostgreSQL])
</pre>

=== Configure ===
'''Hinweis:''' Hier gibt es zwei wichtige Änderungen gegenüber des Manuals.
* der Installationpfad muss angepasst werden, da wir keine Schreibrechte für /opt/ besitzen
* der Pfad zu der Datei mysql.h muss angegeben werden

<pre>
./configure --prefix=/path/to/user/home/opt/mnogosearch --with-mysql=/usr --disable-mp3 --disable-news --without-debug --with-pgsql=no --with-freetds=no --with-oracle8=no --with-oracle8i=no --with-iodbc=no --with-unixODBC=no --with-db2=no --with-solid=no --with-openlink=no --with-easysoft=no --with-sapdb=no --with-ibase=no --with-ctlib=no --with-zlib --disable-syslog
</pre>

=== Kompilieren und Installation der Suchengine ===
Bevor es zum kompilieren kommen, müssen wir noch eine erzeugte Datei bearbeiten und ändern dort den String
''/* #undef HAVE_PGSQL */'' in ''#undef HAVE_PGSQL''.
<pre>
cd mnogosearch-3.3.9
$yourEditor include/udm_autoconf.h
</pre>

Jetzt kompilieren und installieren wir Mnogosearch
<pre>
make
make install
</pre>

=== Kompilieren und Installation der PHP Extension ===
'''Hinweis:'''
* der Pfad zur Suchengine muss angepasst werden (ist derselbe Pfad wie in dem --prefix Argument)

<pre>
cd ~/mnogosearch-3.3.9/php
phpize
./configure --with-mnogosearch=/path/to/user/home/opt/mnogosearch
</pre>

Jetzt müssen wir die Datei ''php_mnogo.c'' editieren und den String ''#undef HAVE_PGSQL'' in eine neue Zeile unterhalb von ''#include "php.h"'' einfügen.

Jetzt können wir die Extension bauen.

<pre>
make
</pre>

Die PHP Extension liegt jetzt in dem Ordner ~/mnogosearch-3.3.9/php/modules. Am Besten kopiert man sich die Extension in den CGI Ordner einer Domain oder ebenfalls nach ~/opt.

Um die Extension nun nutzen zu können, editieren wir die eigene ''php-cgi-fcgi.ini'' und fügen am Ende
<pre>
extension=relativer/Pfad/vom/PHP-Extension/Verzeichnis/zu/mnogosearch.so
</pre>
ein.

Das aktuelle Extension Dir erhält man so:
<pre>
php -i | grep extension_dir
</pre>

Von diesem Verzeichnis ausgehend hangelt man sich bis zu dem Verzeichnis, in das man eben die PHP Extension kopiert hat.
Das ist notwendig, da in PHP 5.2 keine multiplen Extension Dirs in der php.ini eingetragen werden können. Eigene Extensions können nur relativ referenziert werden.

Das Ergbnis sollte man noch in einer mittels phpinfo überprüfen. Wenn alles funktioniert hat, sollte in der Übersicht ''mnogosearch'' auftauchen. Ist dies nicht der Fall empfielt es sich das Errorlog von PHP anzuschalten und zu schauen, was schief läuft. Oft liegt das einfach an dem falschen relativen Pfad zur Extension.

Den weiteren Installationablauf entnimmt man am Besten dem Manual zur TYPO3 Extension.
nach dem Installieren der Extension in TYPO3 muss man den Pfad zu der Suchengine von /opt/mnogosearch entsprechend anpassen. In unserem Fall wäre das ''/path/to/user/home/opt/mnogosearch''

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

Mnogosearch installieren

2021-09-29T06:39:30Z

Deg00-m.website: /* Installation des Debian Pakets */

== Die Suchmaschine für die eigene Webseite ==

[http://www.mnogosearch.org/ Mnogosearch] ist eine Suchmaschine, die für die eigene Webseite verwendet werden kann. Sie ist für Webseiten bis einige tausend Seiten und Traffic, wie er auf einem Shared-Webserver vorkommt, gut geeignet. Die Software muss aus den Sourcen selbst [[#Kompilieren der Mnogosearch aus den Sourcen|kompiliert]] werden und kann mit Datenbanken wie Sqlite3, Mysql oder Postgresql eingesetzt werden.

Hier wird eine Grundinstallation beschrieben. Mnogosearch ist eine sehr umfangreiche Software mit mannigfaltigen Konfigurationsmöglichkeiten. Für die weitergehende Konfiguration muss auf die Dokumentation von [http://www.mnogosearch.org/ Mnogosearch] verwiesen werden.

Mnogosearch ist sehr mächtig und kann vor allen Dingen mit Unicode umgehen, es können viele Dinge eingestellt werden. In dieser Konfiguration funktioniert der indexer als "Crawler", er surft die eigene Webseite ab und speichert die Einträge für spätere Suchergebnisse. Dabei beachtet er die /robots.txt.

Es können aber auch das Dateisystem und verschiedene Dokumentarten durchsucht werden, es können Bereiche der Webseite ausgeschlossen werden und es können Sektionen in Webseiten definiert werden, die für die Auflistung der Suchergebnisse als wichtiger gewertet werden. Diese Dinge müssen zusätzlich konfiguriert werden. Dies ist nur eine Grundkonfiguration, die aber in den meisten Fällen ausreichen dürfte.

== Konfiguration ==

Für die Datenbank und die Konfigurationsdatei wird am besten pro Domain ein Verzeichnis "mnogosearch" eingerichtet und da die Konfigurationsdatei indexer.conf erstellt. Diese Datei kann auch von /etc/mnogosearch/indexer.conf kopiert werden und muss dann entsprechend geändert werden.

<pre>
# cd /home/doms/example.com
# mkdir mnogosearch
# cd mnogosearch
# touch indexer.conf
# edit indexer.conf
</pre>

=== Inhalt von indexer.conf ===

Dies ist die stark gekürzte und auf Notwendiges reduzierte Fassung. Ganz zu Beginn wird die Datenbankdatei und am Ende der zu indizierende Webserver definiert:

<pre>
###########################################################################
# DBAddr <URL-style database description>
# Options (type, host, database name, port, user and password)
# to connect to SQL database.
# Should be used before any other commands.
# Has global effect for whole config file.
# Format:
#DBAddr <DBType>:[//[DBUser[:DBPass]@]DBHost[:DBPort]]/DBName/[?dbmode=mode]

DBAddr sqlite://mnogo:@/home/doms/example.com/mnogosearch/mnogosearch.db/?dbmode=multi

# Default LocalCharset is iso-8859-1 (latin1).

# Full UNICODE
# Folgendes auskommentieren für iso-8859-1
LocalCharset UTF-8

###########################################################################
# StopwordFile <filename>
# Load stop words from the given text file. You may specify either absolute
# file name or a name relative to mnoGoSearch /etc directory. You may use
# several StopwordFile commands.
#
StopwordFile stopwords/de.sl

#######################################################################
# HTTPHeader <header>
# You may add your desired headers in indexer HTTP request.
# You should not use "If-Modified-Since","Accept-Charset" headers,
# these headers are composed by indexer itself.
# "User-Agent: mnoGoSearch/version" is sent too, but you may override it.
# Command has global effect for all configuration file.
#
HTTPHeader "User-Agent: example.com-indexer"

##########################################################################
# Section 2.
# URL control configuration.

# Allow Configuration
# Examples
# Allow everything:
#Allow *
# Allow everything but .php .cgi .pl extensions case insensitively using regex:
#Allow NoMatch Regex \.php$|\.cgi$|\.pl$
# Allow .HTM extension case sensitively:
#Allow Case *.HTM

Allow *.html

##########################################################################
#Disallow [Match|NoMatch] [NoCase|Case] [String|Regex] <arg> [<arg> ... ]
#
# Examples:
# Disallow URLs that are not in udm.net domains using "string" match:
#Disallow NoMatch *.udm.net/*
# Disallow any except known extensions and directory index using "regex" match:
#Disallow NoMatch Regex \/$|\.htm$|\.html$|\.shtml$|\.phtml$|\.php$|\.txt$
# Exclude cgi-bin and non-parsed-headers using "string" match:
#Disallow */cgi-bin/* *.cgi */nph-*
# Exclude anything with '?' sign in URL. Note that '?' sign has a
# special meaning in "string" match, so we have to use "regex" match here:
#Disallow Regex \?

# Exclude some known extensions using fast "String" match:
Disallow *.b *.sh *.md5 *.rpm
Disallow *.arj *.tar *.zip *.tgz *.gz *.z *.bz2
Disallow *.lha *.lzh *.rar *.zoo *.ha *.tar.Z
Disallow *.gif *.jpg *.jpeg *.bmp *.tiff *.tif *.xpm *.xbm *.pcx
Disallow *.vdo *.mpeg *.mpe *.mpg *.avi *.movie *.mov *.wmv
Disallow *.mid *.mp3 *.rm *.ram *.wav *.aiff *.ra
Disallow *.vrml *.wrl *.png *.ico *.psd *.dat
Disallow *.exe *.com *.cab *.dll *.bin *.class *.ex_
Disallow *.tex *.texi *.xls *.doc *.texinfo
Disallow *.rtf *.pdf *.cdf *.ps
Disallow *.ai *.eps *.ppt *.hqx
Disallow *.cpt *.bms *.oda *.tcl
Disallow *.o *.a *.la *.so
Disallow *.pat *.pm *.m4 *.am *.css
Disallow *.map *.aif *.sit *.sea
Disallow *.m3u *.qt

# Exclude Apache directory list in different sort order using "string" match:
Disallow *D=A *D=D *M=A *M=D *N=A *N=D *S=A *S=D

# More complicated case. RAR .r00-.r99, ARJ a00-a99 files
# and UNIX shared libraries. We use "Regex" match type here:
Disallow Regex \.r[0-9][0-9]$ \.a[0-9][0-9]$ \.so\.[0-9]$

################################################################
# Section 3.
# Mime types and external parsers.

################################################################
#AddType [String|Regex] [Case|NoCase] <mime type> <arg> [<arg>...]
# This command associates filename extensions (for services
# that don't automatically include them) with their mime types.
# Currently "file:" protocol uses these commands.
# Use optional first two parameter to choose comparison type.
# Default type is "String" "NoCase" (case sensitive string match with
# '?' and '*' wildcards for one and several characters correspondingly).
#
AddType image/x-xpixmap *.xpm
AddType image/x-xbitmap *.xbm
AddType image/gif *.gif

AddType text/plain *.txt *.pl *.js *.h *.c *.pm *.e
AddType text/html *.html *.htm

AddType text/rtf *.rtf
AddType application/pdf *.pdf
AddType application/msword *.doc
AddType application/vnd.ms-excel *.xls
AddType text/x-postscript *.ps

# Default unknown type for other extensions:
AddType application/unknown *.*

# Use ParserTimeOut to specify amount of time for parser execution
# to avoid possible indexer hang.

ParserTimeOut 300

#######################################################################
# Section 5.
# Servers configuration.

#######################################################################
# Document sections.
#
# Format is:
#
# Section <string> <number> <maxlen> [clone] [sep] [{expr} {repl}]
#
# where <string> is a section name and <number> is section ID
# between 0 and 255. Use 0 if you don't want to index some of
# these sections. It is better to use different sections IDs
# for different documents parts. In this case during search
# time you'll be able to give different weight to each part
# or even disallow some sections at a search time.
# <maxlen> argument contains a maximum length of section
# which will be stored in database.
# "clone" is an optional parameter describing whether this
# section should affect clone detection. It can
# be "DetectClone" or "cdon", or "NoDetectClone" or "cdoff".
# By default, url.* section values are not taken in account
# for clone detection, while any other sections take part
# in clone detection.
# "sep" is an optional argument to specify a separator between
# parts of the same section. It is a space character by default.
# "expr" and "repl" can be used to extract user defined sections,
# for example pieces of text between the given tags. "expr" is
# a regular expression, "repl" is a replacement with $1, $2, etc
# meta-characters designating matches "expr" matches.

# Standard HTML sections: body, title

Section body 1 256
Section title 2 128

# META tags
# For example <META NAME="KEYWORDS" CONTENT="xxxx">
#

Section meta.keywords 3 128
Section meta.description 4 128

# HTTP headers example, let's store "Server" HTTP header
#
#
#Section header.server 5 64

# Document's URL parts

Section url.file 6 0
Section url.path 7 0
Section url.host 8 0
Section url.proto 9 0

# CrossWords

Section crosswords 10 0

#
# If you use CachedCopy for smart excerpts (see below),
# please keep Charset section active.
#
Section Charset 11 32

Section Content-Type 12 64
Section Content-Language 13 16

# Uncomment the following lines if you want tag attributes
# to be indexed

#Section attribute.alt 14 128
#Section attribute.label 15 128
#Section attribute.summary 16 128
#Section attribute.title 17 128
#Section attribute.face 27 0

# Uncomment the following lines if you want use NewsExtensions
# You may add any Newsgroups header to be indexed and stored in urlinfo table

#Section References 18 0
#Section Message-ID 19 0
#Section Parent-ID 20 0

# Uncomment the following lines if you want index MP3 tags.
#Section MP3.Song 21 128
#Section MP3.Album 22 128
#Section MP3.Artist 23 128
#Section MP3.Year 24 128

# Comment this line out if you don't want to store "cached copies"
# to generate smart excerpts at search time.
# Don't forget to keep "Charset" section active if you use cached copies.
# NOTE: 3.2.18 has limits for CachedCopy size, 32000 for Ibase and
# 15000 for Mimer. Other databases do not have limits.
# If indexer fails with 'string too long' error message then reduce
# this number. This will be fixed in the future versions.
#
Section CachedCopy 25 64000

# A user defined section example.
# Extract text between <h1> and </h1> tags:
#Section h1 26 128 "<h1>(.*)</h1>" $1

#########################################################################
#Server [Method] [SubSection] <URL> [alias]
# This is the main command of the indexer.conf file. It's used
# to describe web-space you want to index. It also inserts
# given URL into database to use it as a start point.
# You may use "Server" command as many times as a number of different
# servers or their parts you want to index.

# To index whole server "www.example.com":
Server http://www.example.com/
</pre>

'''Unbedingt im ganzen Dokument example.com durch den eigenen Domainnamen ersetzen!'''

=== Datenbank erstellen ===

Die Datenbank wird mit dem Programm '''indexer''' erstellt. Dabei muss indexer natürlich (und wie bei jedem Aufruf) der Pfad zur eigenen Konfiguration mitgeteilt werden.

<pre>
# /usr/sbin/indexer -Ecreate /home/doms/example.com/mnogosearch/indexer.conf
</pre>

==== Erster Indexlauf ====

<pre>
# /usr/sbin/indexer -a /home/doms/example.com/mnogosearch/indexer.conf
</pre>

Mit diesem Befehl wird die Datenbank gefüllt. Wir haben in der Konfigurationsdatei definiert, dass alle Seiten mit der Endung .html unter http://www.example.com/ durchsucht und indiziert werden.

Die Option -a ersetzt alle vorhandenen Einträge.

=== Die Suche auf der eigenen Webseite ===

Damit die Suche funktionieren kann, legen wir einen symbolischen Link zu dem Suchprogramm /usr/lib/cgi-bin/search.cgi in das eigene cgi-Verzeichnis:

<pre>
# ln -s /usr/lib/cgi-bin/search.cgi /home/doms/example.com/cgi/search.cgi
</pre>

Das zugehörige Suchformular kann entweder von /etc/mnogosearch/search.htm in das eigene Webverzeichnis kopiert (mit der Endung "zhtml" - siehe weiter unten) und anschließend editiert werden. Wichtig ist der Verweis auf die eigene Datenbankdatei in der Sektion "variables" ganz zu Beginn:

:'''DBAddr sqlite://mnogo:@/home/doms/example.com/mnogosearch/mnogosearch.db/?dbmode=multi'''

==== Minimales Suchformular in Deutsch ====

Folgendes Formular ist bereits eingedeutscht und kann direkt als /home/doms/example.com/subs/www/suche.zhtml abgespeichert werden (man beachte die Endung "zhtml"):

<pre><nowiki>
# start



<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=$&(BrowserCharset)" />
<title>Suche: $&(q)</title>
<style type="text/css">
body { background-color: #fff; }
a { color: #00c; }
div.center { text-align: center; }
table.grey { background-color: #eee; width: 100%; }
table.white { background-color: #fff; width: 100%; }
img.logo { border: none; }
</style>
</head>

<body>

<div class="center">
<form method="get" action="">
<table class="grey" summary="">
<tr>
<td>
<br /> Suche nach:
<INPUT TYPE="text" NAME="q" VALUE="$&(q)" SIZE=50 />
<INPUT TYPE="submit" NAME="cmd" VALUE="Suche!" />
<br /><br />
</td>
</tr>
</table>
</form>
</div>




<table bgcolor=#EEEEEE width=100% border=0>
<tr>
<td>
<small>Suche nach <b>$&(q)</b>.</small>
<small>Gefunden: <b>$&(WE)</b>.</small>
</td>
<td>
<small>Ergebnisse <b>$(first)-$(last)</b> von <B>$(total)</B>.</small>
<small>Die Suche dauerte <b>$(SearchTime)</b> Sekunden</small>
</td>
</tr>
<tr><td colspan="2">
Sortieren:
<!IF NAME="s" CONTENT="DRP">
<a href="$(FirstPage)&s=RPD">Relevanz</a> | <b>Datum</b> | <a href="$(FirstPage)&s=SRPD&su=title">Titel</a>
<!ELSEIF NAME="s" CONTENT="SRPD">
<a href="$(FirstPage)&s=RPD">Relevanz</a> | <a href="$(FirstPage)&s=DRP">Datum</a> | <b>Titel</b>
<!ELSE>
<b>Relevanz</b> | <a href="$(FirstPage)&s=DRP">Datum</a> | <a href="$(FirstPage)&s=SRPD&su=title">Titel</a>
<!ENDIF>
</td></tr>
</table>
<br />




<DL>
<!IFNOT NAME="Alias" CONTENT=""><!COPY NAME="URL" CONTENT="Alias"><!ENDIF>
<!IF NAME="fmt" CONTENT="url">
<DT>$(Order).
<a href="$(URL)">$(URL:40)</a>
<small>[<b>$(Score)</b>]</small>
<!ELSEIF NAME="fmt" CONTENT="short">
<DT>$(Order).
<a href="$(URL)">
<!IF NAME="Title" CONTENT="">$(URL:40)<!ELSE>$&(Title)<!ENDIF>
</a>
<small>[<b>$(Score)</b>]</small>
<!ELSE>
<DT>$(Order).
<a href="$(URL)">
<!IF NAME="Title" CONTENT="">$(URL:40)<!ELSE>$&(Title)<!ENDIF>
</a>
<small>
[
<b>$(Score)</b>
<!IFNOT NAME="Pop_Rank" CONTENT="0.00000">Popularity: <b>$(Pop_Rank)</b><!ENDIF>
]
</small>
<DD>
<table width=60%>
<tr>
<td>
<small>$&(Body)...</small>
</td>
</tr>
<tr>
<td>
<UL>
<li>
<small>
<A HREF="$(URL)">$(URL:40)</A>
<font color="#008800">
- $(Content-Length) bytes [$(Content-Type)]
- $(Last-Modified)
<!IFNOT NAME="stored_href" CONTENT="">
<DD><small>[<a href="$(stored_href)">Cached copy</a>]</small></DD>
<!ENDIF>
<!IFNOT NAME="sitelimit_href" CONTENT="">
<!IFGT NAME="PerSite" CONTENT="0">
<DD><small>
[<a href="$(sitelimit_href)">More results from this site ($(PerSite) total) </a>]
</small></DD>
<!ENDIF>
<!ENDIF>
</font>
</small>
<BR>
$(CL)
</UL>
$(STORED)

</td>
</tr>
</table>

<!ENDIF>
</DL>



<table width=100% bgcolor=#FFFFFF>
<tr>
<td align=center>
<TABLE BORDER=0>
<TR><TD><small>Ergebnis Seiten: <TD> </TD></TD>$(NL)$(NB)$(NR)</TD></TR>
</TABLE>
</td>
</tr>
</table>



<!IFNOT NAME="Alias" CONTENT=""><!COPY NAME="URL" CONTENT="Alias"><!ENDIF>
<li>
<small>
<A HREF="$(URL)">$(URL:40)</A>
<font color="#008800">
- $(Content-Length) bytes
- $(Last-Modified)
</font>
</small>



<TD><small><A HREF="$(NH)"><< Vorherige</A></TD>



<TD><small><FONT COLOR=gray><< Vorherige</FONT></TD>



<TD><small><A HREF="$(NH)">$(NP)</A></TD>



<TD><small>$(NP)</TD>



<TD><small><A HREF="$(NH)">Nächste >></A></TD>



<TD><small><FONT COLOR=gray>Nächste >></FONT></TD>



<!IFNOT NAME="WS" CONTENT="">
Meinten Sie <b><a href="?q=$%(WS)">$(WS)</a></b>?
<!ENDIF>
<table bgcolor=#EEEEEE width=100%>
<tr>
<td>
<small>Suche nach <b>$&(q)</b>.</small>
<small>Suchergebnisse: <b>$&(WE)</b></small>
</td>
</tr>
</table>

<p>
Sorry, Ihre Suche nach <b>$&(q)</b> hat kein Ergebnis.<br>
Es wurden keine Dokumente gefunden, die <b>"$&(q)" enthalten</b>.<br>

<p>
Hinweise:
<UL>
<LI> Stellen Sie sicher, dass Ihre Wörter richtig geschrieben sind.
<LI> Versuchen Sie andere Suchworte.
<LI> Versuchen Sie allgemeinere Suchwörter.
</UL>



<div class="center">Bitte geben Sie eines oder mehrere Wörter ein und dücken Sie Suche.</div>



<CENTER>
<FONT COLOR="#FF0000">Es ist ein Fehler aufgetreten!</FONT>
<P><B>$(E)</B>
</CENTER>



<table class="grey" summary="">
<tr><td> </td></tr>
</table>

</body>
</html>



<BASE HREF="$(URL)">

<table border="1" cellpadding="2" cellspacing="0"><tr>
<td><b>Document ID:</b> $(ID)</td>
<td><b>Last modified:</b> $(Last-Modified)</td>
<td><b>Language:</b> $(Content-Language)</td>
<td><b>Charset:</b> $(Charset)</td>
<td><b>Size:</b> $(Content-Length)</td>
</tr></table>
<hr>



$^(document)





</nowiki></pre>

==== suche.zhtml sucht search.cgi ====

Das Suchformular hat keine "action" definiert, es wird per .htaccess an '''search.cgi''' als Template übergeben:

Wenn noch nicht vorhanden, im gleichen Verzeichnis, in dem das Suchformulat liegt (in diesem Fall ~/doms/example.com/subs/www), eine Datei .htaccess erstellen und editieren:

<pre>
# touch .htaccess
# edit .htaccess
</pre>

Und da folgendes reinschreiben (vorausgesetzt, das Formular heißt suche.zhtml):

<pre>
AddType text/html .zhtml
AddHandler zhtml .zhtml
Action zhtml /home/doms/example.com/cgi/search.cgi
</pre>

Nun kann das Suchformular im Browser angezeigt und verwendet werden:

<nowiki>http://www.example.com/suche.zhtml</nowiki>

Es gibt etliche weitere Möglichkeiten, search.cgi zu benutzen, sie stehen in der Dokumentation.

=== Cronjob zum Update der Suchdatenbank in der Nacht ===

Sollten sich die Webseiten öfter mal ändern, ist es sinnvoll, die Suchdatenbank nachts zu aktualisieren. Die Datei für die eigenen Cronjobs wird editiert:

<pre>
# crontab -e
</pre>

und reingeschrieben wird das:

<pre>
# suche mnogosearch indexer
19 23 * * * nice indexer /home/doms/example.com/mnogosearch/indexer.conf
</pre>

'''Bitte eine andere Uhrzeit wählen, damit nicht alle indexer-Jobs um 23:19 Uhr anlaufen!!!'''

== Kompilieren der Mnogosearch aus den Sourcen ==
Diese Anleitung ist sehr auf die Zusammenarbeit mit dem CMS TYPO3 ausgerichtet. So sind zum Beispiel die Konfigurationseinstellungen zum kompilieren aus dem Manual der TYPO3 Extension [http://typo3.org/documentation/document-library/extension-manuals/mnogosearch/2.2.2/view/1/3/ mnogosearch] entnommen.
Im Grunde bin ich einfach den Anweisungen dort gefolgt, mußte aber wegen HS-spezifischen Gründen an manchen Stellen einen anderen Weg gehen.

Ich habe Mnogosearch mit einem Domainuser kompiliert. Ich denke das das grundsätzlich auch mit einem Paketadmin funktioniert, aber eventuell zu unsicher ist.

=== Runterladen und auspacken ===
Zuerst wechseln wir ins Homeverzeichnis (~) des Users, laden uns den Quellcode runter und entpacken das Archiv.

<pre>
cd ~
// stets die neueste Version benutzen
wget http://www.mnogosearch.org/Download/mnogosearch-3.3.9.tar.gz
tar xvf mnogosearch-3.3.9.tar.gz
</pre>

=== Anpassen der Dateien ===

Sollte man ausschließend eine MySQL Datenbank verwenden, muß vor dem kompilieren die Dateien ./configure.in und ./configure bearbeiten.
In beiden Dateien suchen wir nach dem String ''HAVE_PGSQL'' und ändern die ''1'' in eine ''0''.
<pre>
cd mnogosearch-3.3.9
$yourEditor configure.in
AC_DEFINE([HAVE_PGSQL], [1], [Define if you want to use PostgreSQL])
</pre>

=== Configure ===
'''Hinweis:''' Hier gibt es zwei wichtige Änderungen gegenüber des Manuals.
* der Installationpfad muss angepasst werden, da wir keine Schreibrechte für /opt/ besitzen
* der Pfad zu der Datei mysql.h muss angegeben werden

<pre>
./configure --prefix=/path/to/user/home/opt/mnogosearch --with-mysql=/usr --disable-mp3 --disable-news --without-debug --with-pgsql=no --with-freetds=no --with-oracle8=no --with-oracle8i=no --with-iodbc=no --with-unixODBC=no --with-db2=no --with-solid=no --with-openlink=no --with-easysoft=no --with-sapdb=no --with-ibase=no --with-ctlib=no --with-zlib --disable-syslog
</pre>

=== Kompilieren und Installation der Suchengine ===
Bevor es zum kompilieren kommen, müssen wir noch eine erzeugte Datei bearbeiten und ändern dort den String
''/* #undef HAVE_PGSQL */'' in ''#undef HAVE_PGSQL''.
<pre>
cd mnogosearch-3.3.9
$yourEditor include/udm_autoconf.h
</pre>

Jetzt kompilieren und installieren wir Mnogosearch
<pre>
make
make install
</pre>

=== Kompilieren und Installation der PHP Extension ===
'''Hinweis:'''
* der Pfad zur Suchengine muss angepasst werden (ist derselbe Pfad wie in dem --prefix Argument)

<pre>
cd ~/mnogosearch-3.3.9/php
phpize
./configure --with-mnogosearch=/path/to/user/home/opt/mnogosearch
</pre>

Jetzt müssen wir die Datei ''php_mnogo.c'' editieren und den String ''#undef HAVE_PGSQL'' in eine neue Zeile unterhalb von ''#include "php.h"'' einfügen.

Jetzt können wir die Extension bauen.

<pre>
make
</pre>

Die PHP Extension liegt jetzt in dem Ordner ~/mnogosearch-3.3.9/php/modules. Am Besten kopiert man sich die Extension in den CGI Ordner einer Domain oder ebenfalls nach ~/opt.

Um die Extension nun nutzen zu können, editieren wir die eigene ''php-cgi-fcgi.ini'' und fügen am Ende
<pre>
extension=relativer/Pfad/vom/PHP-Extension/Verzeichnis/zu/mnogosearch.so
</pre>
ein.

Das aktuelle Extension Dir erhält man so:
<pre>
php -i | grep extension_dir
</pre>

Von diesem Verzeichnis ausgehend hangelt man sich bis zu dem Verzeichnis, in das man eben die PHP Extension kopiert hat.
Das ist notwendig, da in PHP 5.2 keine multiplen Extension Dirs in der php.ini eingetragen werden können. Eigene Extensions können nur relativ referenziert werden.

Das Ergbnis sollte man noch in einer mittels phpinfo überprüfen. Wenn alles funktioniert hat, sollte in der Übersicht ''mnogosearch'' auftauchen. Ist dies nicht der Fall empfielt es sich das Errorlog von PHP anzuschalten und zu schauen, was schief läuft. Oft liegt das einfach an dem falschen relativen Pfad zur Extension.

Den weiteren Installationablauf entnimmt man am Besten dem Manual zur TYPO3 Extension.
nach dem Installieren der Extension in TYPO3 muss man den Pfad zu der Suchengine von /opt/mnogosearch entsprechend anpassen. In unserem Fall wäre das ''/path/to/user/home/opt/mnogosearch''

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

Mnogosearch installieren

2021-09-29T06:37:34Z

Deg00-m.website: /* Die Suchmaschine für die eigene Webseite */

== Die Suchmaschine für die eigene Webseite ==

[http://www.mnogosearch.org/ Mnogosearch] ist eine Suchmaschine, die für die eigene Webseite verwendet werden kann. Sie ist für Webseiten bis einige tausend Seiten und Traffic, wie er auf einem Shared-Webserver vorkommt, gut geeignet. Die Software muss aus den Sourcen selbst [[#Kompilieren der Mnogosearch aus den Sourcen|kompiliert]] werden und kann mit Datenbanken wie Sqlite3, Mysql oder Postgresql eingesetzt werden.

Hier wird eine Grundinstallation beschrieben. Mnogosearch ist eine sehr umfangreiche Software mit mannigfaltigen Konfigurationsmöglichkeiten. Für die weitergehende Konfiguration muss auf die Dokumentation von [http://www.mnogosearch.org/ Mnogosearch] verwiesen werden.

Mnogosearch ist sehr mächtig und kann vor allen Dingen mit Unicode umgehen, es können viele Dinge eingestellt werden. In dieser Konfiguration funktioniert der indexer als "Crawler", er surft die eigene Webseite ab und speichert die Einträge für spätere Suchergebnisse. Dabei beachtet er die /robots.txt.

Es können aber auch das Dateisystem und verschiedene Dokumentarten durchsucht werden, es können Bereiche der Webseite ausgeschlossen werden und es können Sektionen in Webseiten definiert werden, die für die Auflistung der Suchergebnisse als wichtiger gewertet werden. Diese Dinge müssen zusätzlich konfiguriert werden. Dies ist nur eine Grundkonfiguration, die aber in den meisten Fällen ausreichen dürfte.

== Installation des Debian Pakets ==

Für die Datenbank und die Konfigurationsdatei wird am besten pro Domain ein Verzeichnis "mnogosearch" eingerichtet und da die Konfigurationsdatei indexer.conf erstellt. Diese Datei kann auch von /etc/mnogosearch/indexer.conf kopiert werden und muss dann entsprechend geändert werden.

<pre>
# cd /home/doms/example.com
# mkdir mnogosearch
# cd mnogosearch
# touch indexer.conf
# edit indexer.conf
</pre>

=== Inhalt von indexer.conf ===

Dies ist die stark gekürzte und auf Notwendiges reduzierte Fassung. Ganz zu Beginn wird die Datenbankdatei und am Ende der zu indizierende Webserver definiert:

<pre>
###########################################################################
# DBAddr <URL-style database description>
# Options (type, host, database name, port, user and password)
# to connect to SQL database.
# Should be used before any other commands.
# Has global effect for whole config file.
# Format:
#DBAddr <DBType>:[//[DBUser[:DBPass]@]DBHost[:DBPort]]/DBName/[?dbmode=mode]

DBAddr sqlite://mnogo:@/home/doms/example.com/mnogosearch/mnogosearch.db/?dbmode=multi

# Default LocalCharset is iso-8859-1 (latin1).

# Full UNICODE
# Folgendes auskommentieren für iso-8859-1
LocalCharset UTF-8

###########################################################################
# StopwordFile <filename>
# Load stop words from the given text file. You may specify either absolute
# file name or a name relative to mnoGoSearch /etc directory. You may use
# several StopwordFile commands.
#
StopwordFile stopwords/de.sl

#######################################################################
# HTTPHeader <header>
# You may add your desired headers in indexer HTTP request.
# You should not use "If-Modified-Since","Accept-Charset" headers,
# these headers are composed by indexer itself.
# "User-Agent: mnoGoSearch/version" is sent too, but you may override it.
# Command has global effect for all configuration file.
#
HTTPHeader "User-Agent: example.com-indexer"

##########################################################################
# Section 2.
# URL control configuration.

# Allow Configuration
# Examples
# Allow everything:
#Allow *
# Allow everything but .php .cgi .pl extensions case insensitively using regex:
#Allow NoMatch Regex \.php$|\.cgi$|\.pl$
# Allow .HTM extension case sensitively:
#Allow Case *.HTM

Allow *.html

##########################################################################
#Disallow [Match|NoMatch] [NoCase|Case] [String|Regex] <arg> [<arg> ... ]
#
# Examples:
# Disallow URLs that are not in udm.net domains using "string" match:
#Disallow NoMatch *.udm.net/*
# Disallow any except known extensions and directory index using "regex" match:
#Disallow NoMatch Regex \/$|\.htm$|\.html$|\.shtml$|\.phtml$|\.php$|\.txt$
# Exclude cgi-bin and non-parsed-headers using "string" match:
#Disallow */cgi-bin/* *.cgi */nph-*
# Exclude anything with '?' sign in URL. Note that '?' sign has a
# special meaning in "string" match, so we have to use "regex" match here:
#Disallow Regex \?

# Exclude some known extensions using fast "String" match:
Disallow *.b *.sh *.md5 *.rpm
Disallow *.arj *.tar *.zip *.tgz *.gz *.z *.bz2
Disallow *.lha *.lzh *.rar *.zoo *.ha *.tar.Z
Disallow *.gif *.jpg *.jpeg *.bmp *.tiff *.tif *.xpm *.xbm *.pcx
Disallow *.vdo *.mpeg *.mpe *.mpg *.avi *.movie *.mov *.wmv
Disallow *.mid *.mp3 *.rm *.ram *.wav *.aiff *.ra
Disallow *.vrml *.wrl *.png *.ico *.psd *.dat
Disallow *.exe *.com *.cab *.dll *.bin *.class *.ex_
Disallow *.tex *.texi *.xls *.doc *.texinfo
Disallow *.rtf *.pdf *.cdf *.ps
Disallow *.ai *.eps *.ppt *.hqx
Disallow *.cpt *.bms *.oda *.tcl
Disallow *.o *.a *.la *.so
Disallow *.pat *.pm *.m4 *.am *.css
Disallow *.map *.aif *.sit *.sea
Disallow *.m3u *.qt

# Exclude Apache directory list in different sort order using "string" match:
Disallow *D=A *D=D *M=A *M=D *N=A *N=D *S=A *S=D

# More complicated case. RAR .r00-.r99, ARJ a00-a99 files
# and UNIX shared libraries. We use "Regex" match type here:
Disallow Regex \.r[0-9][0-9]$ \.a[0-9][0-9]$ \.so\.[0-9]$

################################################################
# Section 3.
# Mime types and external parsers.

################################################################
#AddType [String|Regex] [Case|NoCase] <mime type> <arg> [<arg>...]
# This command associates filename extensions (for services
# that don't automatically include them) with their mime types.
# Currently "file:" protocol uses these commands.
# Use optional first two parameter to choose comparison type.
# Default type is "String" "NoCase" (case sensitive string match with
# '?' and '*' wildcards for one and several characters correspondingly).
#
AddType image/x-xpixmap *.xpm
AddType image/x-xbitmap *.xbm
AddType image/gif *.gif

AddType text/plain *.txt *.pl *.js *.h *.c *.pm *.e
AddType text/html *.html *.htm

AddType text/rtf *.rtf
AddType application/pdf *.pdf
AddType application/msword *.doc
AddType application/vnd.ms-excel *.xls
AddType text/x-postscript *.ps

# Default unknown type for other extensions:
AddType application/unknown *.*

# Use ParserTimeOut to specify amount of time for parser execution
# to avoid possible indexer hang.

ParserTimeOut 300

#######################################################################
# Section 5.
# Servers configuration.

#######################################################################
# Document sections.
#
# Format is:
#
# Section <string> <number> <maxlen> [clone] [sep] [{expr} {repl}]
#
# where <string> is a section name and <number> is section ID
# between 0 and 255. Use 0 if you don't want to index some of
# these sections. It is better to use different sections IDs
# for different documents parts. In this case during search
# time you'll be able to give different weight to each part
# or even disallow some sections at a search time.
# <maxlen> argument contains a maximum length of section
# which will be stored in database.
# "clone" is an optional parameter describing whether this
# section should affect clone detection. It can
# be "DetectClone" or "cdon", or "NoDetectClone" or "cdoff".
# By default, url.* section values are not taken in account
# for clone detection, while any other sections take part
# in clone detection.
# "sep" is an optional argument to specify a separator between
# parts of the same section. It is a space character by default.
# "expr" and "repl" can be used to extract user defined sections,
# for example pieces of text between the given tags. "expr" is
# a regular expression, "repl" is a replacement with $1, $2, etc
# meta-characters designating matches "expr" matches.

# Standard HTML sections: body, title

Section body 1 256
Section title 2 128

# META tags
# For example <META NAME="KEYWORDS" CONTENT="xxxx">
#

Section meta.keywords 3 128
Section meta.description 4 128

# HTTP headers example, let's store "Server" HTTP header
#
#
#Section header.server 5 64

# Document's URL parts

Section url.file 6 0
Section url.path 7 0
Section url.host 8 0
Section url.proto 9 0

# CrossWords

Section crosswords 10 0

#
# If you use CachedCopy for smart excerpts (see below),
# please keep Charset section active.
#
Section Charset 11 32

Section Content-Type 12 64
Section Content-Language 13 16

# Uncomment the following lines if you want tag attributes
# to be indexed

#Section attribute.alt 14 128
#Section attribute.label 15 128
#Section attribute.summary 16 128
#Section attribute.title 17 128
#Section attribute.face 27 0

# Uncomment the following lines if you want use NewsExtensions
# You may add any Newsgroups header to be indexed and stored in urlinfo table

#Section References 18 0
#Section Message-ID 19 0
#Section Parent-ID 20 0

# Uncomment the following lines if you want index MP3 tags.
#Section MP3.Song 21 128
#Section MP3.Album 22 128
#Section MP3.Artist 23 128
#Section MP3.Year 24 128

# Comment this line out if you don't want to store "cached copies"
# to generate smart excerpts at search time.
# Don't forget to keep "Charset" section active if you use cached copies.
# NOTE: 3.2.18 has limits for CachedCopy size, 32000 for Ibase and
# 15000 for Mimer. Other databases do not have limits.
# If indexer fails with 'string too long' error message then reduce
# this number. This will be fixed in the future versions.
#
Section CachedCopy 25 64000

# A user defined section example.
# Extract text between <h1> and </h1> tags:
#Section h1 26 128 "<h1>(.*)</h1>" $1

#########################################################################
#Server [Method] [SubSection] <URL> [alias]
# This is the main command of the indexer.conf file. It's used
# to describe web-space you want to index. It also inserts
# given URL into database to use it as a start point.
# You may use "Server" command as many times as a number of different
# servers or their parts you want to index.

# To index whole server "www.example.com":
Server http://www.example.com/
</pre>

'''Unbedingt im ganzen Dokument example.com durch den eigenen Domainnamen ersetzen!'''

=== Datenbank erstellen ===

Die Datenbank wird mit dem Programm '''indexer''' erstellt. Dabei muss indexer natürlich (und wie bei jedem Aufruf) der Pfad zur eigenen Konfiguration mitgeteilt werden.

<pre>
# /usr/sbin/indexer -Ecreate /home/doms/example.com/mnogosearch/indexer.conf
</pre>

==== Erster Indexlauf ====

<pre>
# /usr/sbin/indexer -a /home/doms/example.com/mnogosearch/indexer.conf
</pre>

Mit diesem Befehl wird die Datenbank gefüllt. Wir haben in der Konfigurationsdatei definiert, dass alle Seiten mit der Endung .html unter http://www.example.com/ durchsucht und indiziert werden.

Die Option -a ersetzt alle vorhandenen Einträge.

=== Die Suche auf der eigenen Webseite ===

Damit die Suche funktionieren kann, legen wir einen symbolischen Link zu dem Suchprogramm /usr/lib/cgi-bin/search.cgi in das eigene cgi-Verzeichnis:

<pre>
# ln -s /usr/lib/cgi-bin/search.cgi /home/doms/example.com/cgi/search.cgi
</pre>

Das zugehörige Suchformular kann entweder von /etc/mnogosearch/search.htm in das eigene Webverzeichnis kopiert (mit der Endung "zhtml" - siehe weiter unten) und anschließend editiert werden. Wichtig ist der Verweis auf die eigene Datenbankdatei in der Sektion "variables" ganz zu Beginn:

:'''DBAddr sqlite://mnogo:@/home/doms/example.com/mnogosearch/mnogosearch.db/?dbmode=multi'''

==== Minimales Suchformular in Deutsch ====

Folgendes Formular ist bereits eingedeutscht und kann direkt als /home/doms/example.com/subs/www/suche.zhtml abgespeichert werden (man beachte die Endung "zhtml"):

<pre><nowiki>
# start



<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=$&(BrowserCharset)" />
<title>Suche: $&(q)</title>
<style type="text/css">
body { background-color: #fff; }
a { color: #00c; }
div.center { text-align: center; }
table.grey { background-color: #eee; width: 100%; }
table.white { background-color: #fff; width: 100%; }
img.logo { border: none; }
</style>
</head>

<body>

<div class="center">
<form method="get" action="">
<table class="grey" summary="">
<tr>
<td>
<br /> Suche nach:
<INPUT TYPE="text" NAME="q" VALUE="$&(q)" SIZE=50 />
<INPUT TYPE="submit" NAME="cmd" VALUE="Suche!" />
<br /><br />
</td>
</tr>
</table>
</form>
</div>




<table bgcolor=#EEEEEE width=100% border=0>
<tr>
<td>
<small>Suche nach <b>$&(q)</b>.</small>
<small>Gefunden: <b>$&(WE)</b>.</small>
</td>
<td>
<small>Ergebnisse <b>$(first)-$(last)</b> von <B>$(total)</B>.</small>
<small>Die Suche dauerte <b>$(SearchTime)</b> Sekunden</small>
</td>
</tr>
<tr><td colspan="2">
Sortieren:
<!IF NAME="s" CONTENT="DRP">
<a href="$(FirstPage)&s=RPD">Relevanz</a> | <b>Datum</b> | <a href="$(FirstPage)&s=SRPD&su=title">Titel</a>
<!ELSEIF NAME="s" CONTENT="SRPD">
<a href="$(FirstPage)&s=RPD">Relevanz</a> | <a href="$(FirstPage)&s=DRP">Datum</a> | <b>Titel</b>
<!ELSE>
<b>Relevanz</b> | <a href="$(FirstPage)&s=DRP">Datum</a> | <a href="$(FirstPage)&s=SRPD&su=title">Titel</a>
<!ENDIF>
</td></tr>
</table>
<br />




<DL>
<!IFNOT NAME="Alias" CONTENT=""><!COPY NAME="URL" CONTENT="Alias"><!ENDIF>
<!IF NAME="fmt" CONTENT="url">
<DT>$(Order).
<a href="$(URL)">$(URL:40)</a>
<small>[<b>$(Score)</b>]</small>
<!ELSEIF NAME="fmt" CONTENT="short">
<DT>$(Order).
<a href="$(URL)">
<!IF NAME="Title" CONTENT="">$(URL:40)<!ELSE>$&(Title)<!ENDIF>
</a>
<small>[<b>$(Score)</b>]</small>
<!ELSE>
<DT>$(Order).
<a href="$(URL)">
<!IF NAME="Title" CONTENT="">$(URL:40)<!ELSE>$&(Title)<!ENDIF>
</a>
<small>
[
<b>$(Score)</b>
<!IFNOT NAME="Pop_Rank" CONTENT="0.00000">Popularity: <b>$(Pop_Rank)</b><!ENDIF>
]
</small>
<DD>
<table width=60%>
<tr>
<td>
<small>$&(Body)...</small>
</td>
</tr>
<tr>
<td>
<UL>
<li>
<small>
<A HREF="$(URL)">$(URL:40)</A>
<font color="#008800">
- $(Content-Length) bytes [$(Content-Type)]
- $(Last-Modified)
<!IFNOT NAME="stored_href" CONTENT="">
<DD><small>[<a href="$(stored_href)">Cached copy</a>]</small></DD>
<!ENDIF>
<!IFNOT NAME="sitelimit_href" CONTENT="">
<!IFGT NAME="PerSite" CONTENT="0">
<DD><small>
[<a href="$(sitelimit_href)">More results from this site ($(PerSite) total) </a>]
</small></DD>
<!ENDIF>
<!ENDIF>
</font>
</small>
<BR>
$(CL)
</UL>
$(STORED)

</td>
</tr>
</table>

<!ENDIF>
</DL>



<table width=100% bgcolor=#FFFFFF>
<tr>
<td align=center>
<TABLE BORDER=0>
<TR><TD><small>Ergebnis Seiten: <TD> </TD></TD>$(NL)$(NB)$(NR)</TD></TR>
</TABLE>
</td>
</tr>
</table>



<!IFNOT NAME="Alias" CONTENT=""><!COPY NAME="URL" CONTENT="Alias"><!ENDIF>
<li>
<small>
<A HREF="$(URL)">$(URL:40)</A>
<font color="#008800">
- $(Content-Length) bytes
- $(Last-Modified)
</font>
</small>



<TD><small><A HREF="$(NH)"><< Vorherige</A></TD>



<TD><small><FONT COLOR=gray><< Vorherige</FONT></TD>



<TD><small><A HREF="$(NH)">$(NP)</A></TD>



<TD><small>$(NP)</TD>



<TD><small><A HREF="$(NH)">Nächste >></A></TD>



<TD><small><FONT COLOR=gray>Nächste >></FONT></TD>



<!IFNOT NAME="WS" CONTENT="">
Meinten Sie <b><a href="?q=$%(WS)">$(WS)</a></b>?
<!ENDIF>
<table bgcolor=#EEEEEE width=100%>
<tr>
<td>
<small>Suche nach <b>$&(q)</b>.</small>
<small>Suchergebnisse: <b>$&(WE)</b></small>
</td>
</tr>
</table>

<p>
Sorry, Ihre Suche nach <b>$&(q)</b> hat kein Ergebnis.<br>
Es wurden keine Dokumente gefunden, die <b>"$&(q)" enthalten</b>.<br>

<p>
Hinweise:
<UL>
<LI> Stellen Sie sicher, dass Ihre Wörter richtig geschrieben sind.
<LI> Versuchen Sie andere Suchworte.
<LI> Versuchen Sie allgemeinere Suchwörter.
</UL>



<div class="center">Bitte geben Sie eines oder mehrere Wörter ein und dücken Sie Suche.</div>



<CENTER>
<FONT COLOR="#FF0000">Es ist ein Fehler aufgetreten!</FONT>
<P><B>$(E)</B>
</CENTER>



<table class="grey" summary="">
<tr><td> </td></tr>
</table>

</body>
</html>



<BASE HREF="$(URL)">

<table border="1" cellpadding="2" cellspacing="0"><tr>
<td><b>Document ID:</b> $(ID)</td>
<td><b>Last modified:</b> $(Last-Modified)</td>
<td><b>Language:</b> $(Content-Language)</td>
<td><b>Charset:</b> $(Charset)</td>
<td><b>Size:</b> $(Content-Length)</td>
</tr></table>
<hr>



$^(document)





</nowiki></pre>

==== suche.zhtml sucht search.cgi ====

Das Suchformular hat keine "action" definiert, es wird per .htaccess an '''search.cgi''' als Template übergeben:

Wenn noch nicht vorhanden, im gleichen Verzeichnis, in dem das Suchformulat liegt (in diesem Fall ~/doms/example.com/subs/www), eine Datei .htaccess erstellen und editieren:

<pre>
# touch .htaccess
# edit .htaccess
</pre>

Und da folgendes reinschreiben (vorausgesetzt, das Formular heißt suche.zhtml):

<pre>
AddType text/html .zhtml
AddHandler zhtml .zhtml
Action zhtml /home/doms/example.com/cgi/search.cgi
</pre>

Nun kann das Suchformular im Browser angezeigt und verwendet werden:

<nowiki>http://www.example.com/suche.zhtml</nowiki>

Es gibt etliche weitere Möglichkeiten, search.cgi zu benutzen, sie stehen in der Dokumentation.

=== Cronjob zum Update der Suchdatenbank in der Nacht ===

Sollten sich die Webseiten öfter mal ändern, ist es sinnvoll, die Suchdatenbank nachts zu aktualisieren. Die Datei für die eigenen Cronjobs wird editiert:

<pre>
# crontab -e
</pre>

und reingeschrieben wird das:

<pre>
# suche mnogosearch indexer
19 23 * * * nice indexer /home/doms/example.com/mnogosearch/indexer.conf
</pre>

'''Bitte eine andere Uhrzeit wählen, damit nicht alle indexer-Jobs um 23:19 Uhr anlaufen!!!'''

== Kompilieren der Mnogosearch aus den Sourcen ==
Diese Anleitung ist sehr auf die Zusammenarbeit mit dem CMS TYPO3 ausgerichtet. So sind zum Beispiel die Konfigurationseinstellungen zum kompilieren aus dem Manual der TYPO3 Extension [http://typo3.org/documentation/document-library/extension-manuals/mnogosearch/2.2.2/view/1/3/ mnogosearch] entnommen.
Im Grunde bin ich einfach den Anweisungen dort gefolgt, mußte aber wegen HS-spezifischen Gründen an manchen Stellen einen anderen Weg gehen.

Ich habe Mnogosearch mit einem Domainuser kompiliert. Ich denke das das grundsätzlich auch mit einem Paketadmin funktioniert, aber eventuell zu unsicher ist.

=== Runterladen und auspacken ===
Zuerst wechseln wir ins Homeverzeichnis (~) des Users, laden uns den Quellcode runter und entpacken das Archiv.

<pre>
cd ~
// stets die neueste Version benutzen
wget http://www.mnogosearch.org/Download/mnogosearch-3.3.9.tar.gz
tar xvf mnogosearch-3.3.9.tar.gz
</pre>

=== Anpassen der Dateien ===

Sollte man ausschließend eine MySQL Datenbank verwenden, muß vor dem kompilieren die Dateien ./configure.in und ./configure bearbeiten.
In beiden Dateien suchen wir nach dem String ''HAVE_PGSQL'' und ändern die ''1'' in eine ''0''.
<pre>
cd mnogosearch-3.3.9
$yourEditor configure.in
AC_DEFINE([HAVE_PGSQL], [1], [Define if you want to use PostgreSQL])
</pre>

=== Configure ===
'''Hinweis:''' Hier gibt es zwei wichtige Änderungen gegenüber des Manuals.
* der Installationpfad muss angepasst werden, da wir keine Schreibrechte für /opt/ besitzen
* der Pfad zu der Datei mysql.h muss angegeben werden

<pre>
./configure --prefix=/path/to/user/home/opt/mnogosearch --with-mysql=/usr --disable-mp3 --disable-news --without-debug --with-pgsql=no --with-freetds=no --with-oracle8=no --with-oracle8i=no --with-iodbc=no --with-unixODBC=no --with-db2=no --with-solid=no --with-openlink=no --with-easysoft=no --with-sapdb=no --with-ibase=no --with-ctlib=no --with-zlib --disable-syslog
</pre>

=== Kompilieren und Installation der Suchengine ===
Bevor es zum kompilieren kommen, müssen wir noch eine erzeugte Datei bearbeiten und ändern dort den String
''/* #undef HAVE_PGSQL */'' in ''#undef HAVE_PGSQL''.
<pre>
cd mnogosearch-3.3.9
$yourEditor include/udm_autoconf.h
</pre>

Jetzt kompilieren und installieren wir Mnogosearch
<pre>
make
make install
</pre>

=== Kompilieren und Installation der PHP Extension ===
'''Hinweis:'''
* der Pfad zur Suchengine muss angepasst werden (ist derselbe Pfad wie in dem --prefix Argument)

<pre>
cd ~/mnogosearch-3.3.9/php
phpize
./configure --with-mnogosearch=/path/to/user/home/opt/mnogosearch
</pre>

Jetzt müssen wir die Datei ''php_mnogo.c'' editieren und den String ''#undef HAVE_PGSQL'' in eine neue Zeile unterhalb von ''#include "php.h"'' einfügen.

Jetzt können wir die Extension bauen.

<pre>
make
</pre>

Die PHP Extension liegt jetzt in dem Ordner ~/mnogosearch-3.3.9/php/modules. Am Besten kopiert man sich die Extension in den CGI Ordner einer Domain oder ebenfalls nach ~/opt.

Um die Extension nun nutzen zu können, editieren wir die eigene ''php-cgi-fcgi.ini'' und fügen am Ende
<pre>
extension=relativer/Pfad/vom/PHP-Extension/Verzeichnis/zu/mnogosearch.so
</pre>
ein.

Das aktuelle Extension Dir erhält man so:
<pre>
php -i | grep extension_dir
</pre>

Von diesem Verzeichnis ausgehend hangelt man sich bis zu dem Verzeichnis, in das man eben die PHP Extension kopiert hat.
Das ist notwendig, da in PHP 5.2 keine multiplen Extension Dirs in der php.ini eingetragen werden können. Eigene Extensions können nur relativ referenziert werden.

Das Ergbnis sollte man noch in einer mittels phpinfo überprüfen. Wenn alles funktioniert hat, sollte in der Übersicht ''mnogosearch'' auftauchen. Ist dies nicht der Fall empfielt es sich das Errorlog von PHP anzuschalten und zu schauen, was schief läuft. Oft liegt das einfach an dem falschen relativen Pfad zur Extension.

Den weiteren Installationablauf entnimmt man am Besten dem Manual zur TYPO3 Extension.
nach dem Installieren der Extension in TYPO3 muss man den Pfad zu der Suchengine von /opt/mnogosearch entsprechend anpassen. In unserem Fall wäre das ''/path/to/user/home/opt/mnogosearch''

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

Hostsharing Wiki:Wunschliste Installationsanleitungen

2021-09-24T12:57:44Z

Deg00-m.website: Anleitung Drupal existiert

Diese Seite listet Software auf, für die im Dokumentations-Wiki noch keine Installationsanleitung existiert, aber von den Nutzern gewünscht wurde.

{{Textkasten|blau|Hinweis für Dokumentations-Autoren:|Wenn du mit der Arbeit an einer der Anleitungen beginnst, dann notiere dies am besten hier bei dem entsprechenden Eintrag, damit sich nicht unnötig zwei Autoren gleichzeitig die Arbeit machen.}}

bei php Staus Anzeige des [[uploadprogress]] anzeigen siehe:

http://pecl.php.net/package/uploadprogress

Kategorie:Installationsanleitungen

2021-09-24T12:56:40Z

Deg00-m.website: Kategorie:HSDoku

{{HSDoku-Links}}
Manche Software wird von vielen unserer Mitglieder verwendet. Deshalb werden hier Installationen dokumentiert, wie sie bei anderen Mitgliedern funktionieren, um die Sache zu erleichtern.

Es gibt auch eine [[Hostsharing_Wiki:Wunschliste Installationsanleitungen|Wunschliste]], in der du Software eintragen kannst, für die du dir eine Installationsanleitung wünscht.

=== Freie und datenschutzfreundliche Software-Alternativen ===

Linksammlungen, die helfen, alternative Software zu finden:

* https://switching.software/
* https://prism-break.org/de/

=== Tools ===
Liste mit Tools, die von Hostsharing Mitgliedern veröffentlicht wurden.

* http://hs.andreasloesch.de

[[Kategorie:HSDoku]]

PHP FPM

2021-09-10T18:40:21Z

Deg00-m.website: /* Start und Monitoring des FPM-Prozess */ Monit verlinkt

= PHP als eigener Prozess =

Normalerweise starten PHP-Prozesse im Managed Webspace als FastCGi-Prozess unter Kontrolle des Apache Webserver. Der Apache übernimmt die Skalierung und startet bei Bedarf weitere Prozesse nach.

Nutzer:innen eines Managed Server können alternativ PHP-FPM Nutzen. Sie starten einen FPM-Prozess unter der eigenen Kontrolle. Dieser Hauptprozess übernimmt die Skalierung und Kontrolliert den Lifecycle von PHP-Prozessen nach den wünschen der Webseitenbetreiber:in.

== Konfiguration von FPM ==

Hier nur ein minimales Beispiel. Für die Optimierung sein auf die entsprechende Originaldokumentation verwiesen.

~/php-fpm$ cat ~/php-fpm/php-fpm.conf

[global]
pid = /home/pacs/xyz00/users/username/php-fpm/php-fpm.pid
error_log = /home/pacs/xyz00/users/username/php-fpm/php-fpm.log

[www]
listen = 127.0.0.1:30080
listen.allowed_clients = 127.0.0.1
pm = dynamic
pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3
;pm.process_idle_timeout = 10s;
;pm.max_requests = 500

== Apache Konfiguration ==

Der FPM-Server wird über das Apache Modul "mod_proxy_fcgi" angesteuert. Dazu legt man im Verzeichnis
~/doms/hs-example.de/ eine Datei .htaccess an.

$ cat doms/hs-example.de/.htaccess
RewriteEngine on
RewriteRule ^(.*)\.php(/.*)? fcgi://127.0.0.1:30080/home/pacs/xyz00/users/username/doms/hs-example.de/htdocs-ssl/ [proxy,last]

== Start und Monitoring des FPM-Prozess ==

Der Prozess kann direkt oder indirekt über einen Eintrag "@reboot" in der Crontab des Website-User gestartet werden. Für das Monitoring bieten sich [[Monit_installieren|Monit]] oder "supervisord" an.

PHP FPM

2021-09-10T12:14:18Z

Deg00-m.website: /* PHP als eigener Prozess */

= PHP als eigener Prozess =

Normalerweise starten PHP-Prozesse im Managed Webspace als FastCGi-Prozess unter Kontrolle des Apache Webserver. Der Apache übernimmt die Skalierung und startet bei Bedarf weitere Prozesse nach.

Nutzer:innen eines Managed Server können alternativ PHP-FPM Nutzen. Sie starten einen FPM-Prozess unter der eigenen Kontrolle. Dieser Hauptprozess übernimmt die Skalierung und Kontrolliert den Lifecycle von PHP-Prozessen nach den wünschen der Webseitenbetreiber:in.

== Konfiguration von FPM ==

Hier nur ein minimales Beispiel. Für die Optimierung sein auf die entsprechende Originaldokumentation verwiesen.

~/php-fpm$ cat ~/php-fpm/php-fpm.conf

[global]
pid = /home/pacs/xyz00/users/username/php-fpm/php-fpm.pid
error_log = /home/pacs/xyz00/users/username/php-fpm/php-fpm.log

[www]
listen = 127.0.0.1:<30080>
listen.allowed_clients = 127.0.0.1
pm = dynamic
pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3
;pm.process_idle_timeout = 10s;
;pm.max_requests = 500

== Apache Konfiguration ==

Der FPM-Server wird über das Apache Modul "mod_proxy_fcgi" angesteuert. Dazu legt man im Verzeichnis
~/doms/hs-example.de/ eine Datei .htaccess an.

$ cat doms/hs-example.de/.htaccess
RewriteEngine on
RewriteRule ^(.*)\.php(/.*)? fcgi://127.0.0.1:30080/home/pacs/xyz00/users/username/doms/hs-example.de/htdocs-ssl/ [proxy,last]

== Start und Monitoring des FPM-Prozess ==

Der Prozess kann direkt oder indirekt über einen Eintrag "@reboot" in der Crontab des Website-User gestartet werden. Für das Monitoring bieten sich "monit" oder "supervisord" an.

DKIM

2021-08-21T09:41:04Z

Deg00-m.website: Kategorisiert

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

{{Textkasten|gelb|Beta|Das Feature ist bei Hostsharing im Beta Test, bitte noch nicht für den produktiven Einsatz nutzen.}}

== 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 Einrichtungsschritte 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 das Zonefile der E-Mail-Domain erweitert werden. Dazu muss in einem individuell angepassten Zonefile die Zeile

{DKIM_RR}

ergänzt werden.

Diese Zeile ist in der Beta-Phase nicht Bestandteil des Default-Zonefile! Domain-Inhaber, die ihr Zonefile bisher nicht angepasst haben, müssen also ein minimales Zonefile der Form

{DEFAULT_ZONEFILE}
{DKIM_RR}

erstellen.

Nach einer erfolgreichen Veröffentlichung des Domainkey liefert der Befehl

$ dig -t TXT +short default._domainkey.hs-example.de

("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 setzen ==

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

[[Datei:dkim-domain.png]]

[[Datei:dkim-option.png]]

== Beta Test ==

Mitglieder, die ihr Zonefile anpassen können, sind herzlich eingeladen am Test teilzunehmen. Das Wiederentfernen der DKIM-Option kann jedoch zu Schwierigkeiten bei der Zustellung ausgehender Mails führen. Das Abstellen 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

Voraussichtlich ab 1. September 2021 werden wir den DNS-Record mit dem DKIM-Schlüssel per Voreinstellung in den Zonefile-Teil "{DEFAULT_ZONEFILE}" aufnehmen. Mitglieder, die keine Anpassungen am Zonefile vorgenommen haben oder die Variable "{DEFAULT_ZONEFILE}" im Zonefile inkludieren können ab diesem Zeitpunkt die Option setzen.

== Links ==

* [https://de.wikipedia.org/wiki/DomainKeys DKIM Artikel der Wikipedia]
* [https://doc.hostsharing.net/referenz/zonefile/ Hostsharing-Dokumentation zur Anpassung des Zonefile]
* [https://doc.hostsharing.net/referenz/domain/domain-optionen.html Hostsharing-Dokumentation Domain-Optionen]

HDD Storage

2021-08-17T09:41:53Z

Deg00-m.website:

Hostsharing bietet ab 1. September 2021 Festplattenspeicher auf klassischen, magnetischen HDD für größere Datenvolumina an. Der zusätzliche Speicher steht im Managed Hosting als zweite Partition unter dem Mountpoint

/home/storage

zur Verfügung.

Wenn für ein Paket (Beispiel ''xyz00'') eine Storage-Quota gebucht ist, wird
unter diesem Mountpoint ein Verzeichnis ''/home/storage/xyz00'' angelegt. Darin werden auch Unterverzeichnisse für jeden User im Webspace ''xyz00'' angelegt, zum Beispiel
''/home/storage/xyz00/users/brunobeispiel''.

In diesen Verzeichnissen hat der jeweilige User die Berechtigung Dateien anzulegen, zu lesen und zu löschen. Weiterhin kann der Systemuser ''httpd'' auf die Dateien lesend zugreifen, so dass sich einzelne Verzeichnisse in das htdocs-Verzeichnis von Domains verlinken lassen. Auf diesem Weg können größere Dateien zum Download angeboten werden.

Nutzerinnen und Nutzer, die selbständig die Zugriffrechte im Unix-Dateisystem sinnvoll und sicher vergeben können, dürfen unter ''/home/storage/xyz00'' gern eigene Verzeichnisstrukturen organiseren. Der Paketadmin ''xyz00'' hat die notwendigen Rechte dazu.

== Dateizugriffsrechte ==

Die Rechteschleuse für den User ''httpd'' ist wie folgt realisiert:

drwxr-x--x 3 xyz00 httpd 19 Aug 13 14:47 /home/storage/xyz00/
drwxr-xr-x 10 xyz00 xyz00 106 Aug 13 14:47 /home/storage/xyz00/users
drwxr-x--- 2 xyz00-brunobeispiel httpd 6 Aug 13 14:47 /home/storage/xyz00/users/brunobeispiel

[[Kategorie:HSDoku]]
[[Kategorie:Storage]]

HDD Storage

2021-08-17T09:41:26Z

Deg00-m.website: Doppelten Titel weg

[[Kategorie:HSDoku]]
[[Kategorie:Storage]]

Hostsharing bietet ab 1. September 2021 Festplattenspeicher auf klassischen, magnetischen HDD für größere Datenvolumina an. Der zusätzliche Speicher steht im Managed Hosting als zweite Partition unter dem Mountpoint

/home/storage

zur Verfügung.

Wenn für ein Paket (Beispiel ''xyz00'') eine Storage-Quota gebucht ist, wird
unter diesem Mountpoint ein Verzeichnis ''/home/storage/xyz00'' angelegt. Darin werden auch Unterverzeichnisse für jeden User im Webspace ''xyz00'' angelegt, zum Beispiel
''/home/storage/xyz00/users/brunobeispiel''.

In diesen Verzeichnissen hat der jeweilige User die Berechtigung Dateien anzulegen, zu lesen und zu löschen. Weiterhin kann der Systemuser ''httpd'' auf die Dateien lesend zugreifen, so dass sich einzelne Verzeichnisse in das htdocs-Verzeichnis von Domains verlinken lassen. Auf diesem Weg können größere Dateien zum Download angeboten werden.

Nutzerinnen und Nutzer, die selbständig die Zugriffrechte im Unix-Dateisystem sinnvoll und sicher vergeben können, dürfen unter ''/home/storage/xyz00'' gern eigene Verzeichnisstrukturen organiseren. Der Paketadmin ''xyz00'' hat die notwendigen Rechte dazu.

== Dateizugriffsrechte ==

Die Rechteschleuse für den User ''httpd'' ist wie folgt realisiert:

drwxr-x--x 3 xyz00 httpd 19 Aug 13 14:47 /home/storage/xyz00/
drwxr-xr-x 10 xyz00 xyz00 106 Aug 13 14:47 /home/storage/xyz00/users
drwxr-x--- 2 xyz00-brunobeispiel httpd 6 Aug 13 14:47 /home/storage/xyz00/users/brunobeispiel

Kategorie:Storage

2021-08-17T09:40:42Z

Deg00-m.website: Die Seite wurde neu angelegt: „Alle Seiten zum Thema 'Storage'“

Alle Seiten zum Thema 'Storage'

HDD Storage

2021-08-17T09:40:08Z

Deg00-m.website: Kategorien

[[Kategorie:HSDoku]]
[[Kategorie:Storage]]

= HDD Storage =

Hostsharing bietet ab 1. September 2021 Festplattenspeicher auf klassischen, magnetischen HDD für größere Datenvolumina an. Der zusätzliche Speicher steht im Managed Hosting als zweite Partition unter dem Mountpoint

/home/storage

zur Verfügung.

Wenn für ein Paket (Beispiel ''xyz00'') eine Storage-Quota gebucht ist, wird
unter diesem Mountpoint ein Verzeichnis ''/home/storage/xyz00'' angelegt. Darin werden auch Unterverzeichnisse für jeden User im Webspace ''xyz00'' angelegt, zum Beispiel
''/home/storage/xyz00/users/brunobeispiel''.

In diesen Verzeichnissen hat der jeweilige User die Berechtigung Dateien anzulegen, zu lesen und zu löschen. Weiterhin kann der Systemuser ''httpd'' auf die Dateien lesend zugreifen, so dass sich einzelne Verzeichnisse in das htdocs-Verzeichnis von Domains verlinken lassen. Auf diesem Weg können größere Dateien zum Download angeboten werden.

Nutzerinnen und Nutzer, die selbständig die Zugriffrechte im Unix-Dateisystem sinnvoll und sicher vergeben können, dürfen unter ''/home/storage/xyz00'' gern eigene Verzeichnisstrukturen organiseren. Der Paketadmin ''xyz00'' hat die notwendigen Rechte dazu.

== Dateizugriffsrechte ==

Die Rechteschleuse für den User ''httpd'' ist wie folgt realisiert:

drwxr-x--x 3 xyz00 httpd 19 Aug 13 14:47 /home/storage/xyz00/
drwxr-xr-x 10 xyz00 xyz00 106 Aug 13 14:47 /home/storage/xyz00/users
drwxr-x--- 2 xyz00-brunobeispiel httpd 6 Aug 13 14:47 /home/storage/xyz00/users/brunobeispiel

Mailman Installieren

2021-07-07T06:37:22Z

Deg00-m.website: /* Mailman gegen Subscription Spam härten */

== Vorab: Die Wahl von Mailman 2 ==

Mailman 2 hängt von Python 2.7 ab und wird damit voraussichtlich nur noch eine begrenzte Nutzungsdauer haben. Mailman 3 ist jetzt verfügbar (siehe [[Mailman_3_installieren]]), aber deutlich schwerer und komplexer im Betrieb. Es gibt auch weniger leistungsfähige Software, um E-Mail-Verteiler zu betreiben, wie beispielsweise [[mlmmj]]. Für eine Diskussion der Situation im Oktober 2019, siehe das HS-Support-Archiv ab [https://lists.hostsharing.net/archiv/support/2019-October/067243.html hier.]

== Mailman 2 installieren ==

(zuletzt getestet mit mailman-2.1.29; Installation durch Paketuser)

Vielen Dank an alle Benutzer, die Verbesserungen beisteuern!

=== Unter welchem Account installieren? ===

Mailman kann vom Paketadmin (beipsielsweise "xyz00") oder von einem Paketuser (bspw. "xyz00-listen") installiert werden. Letzteres ist dringend empfohlen, denn wenn Mailman vom Paketadmin installiert wird, haben ausnahmslos alle Paketuser direkten Zugriff auf die Mailman-Daten, und bei Sicherheitslücken in Mailman wäre eventuell eine Rechte-Eskalierung auf Paketadmin-Ebene potentiell zu befürchten.

Dem Paketuser, unter dem Mailman installiert wird, können mehrere Subdomains aufschaltet werden, und Mailinglisten können auch die Domainnamen verwenden, die anderen Paketusern gehören.

Vorteil der Installation als Paketuser ist, dass nur dieser direkten Zugriff auf die Mailmandaten hat und mailman ohne Paketadminrechte läuft. Während der Emailauslieferung gelten (wie immer bei der Mailweiterleitung durch .forward-Dateien oder durch procmail) die Rechte des Paketusers, dem die Mailman-Installation gehört.

Nachteil der Installation als Paketuser ist lediglich, dass die Paketdomain mit dem SSL Zertifikat von Hostsharing nicht genutzt werden kann.

=== Einen User und eine Domain anlegen ===

Unter admin.hostsharing.net als xyz00 anmelden; den User xyz00-listen erzeugen; die Domain listen.example.com mit "Domain-User" xyz00-listen anlegen. Aus admin.hostsharing.net abmelden.

Mit [[Login_mit_SSH|SSH]] an hostsharing.net als xyz00-listen anmelden. Die Redirect-Zeile aus <tt><nowiki>~/doms/listen.example.com/htdocs-ssl/.htaccess</nowiki></tt> löschen:

~$ echo "" > ~/doms/listen.example.com/htdocs-ssl/.htaccess

Die Default-Subdomains www.* löschen:

~$ rm -r doms/listen.example.com/subs/www/
~$ rm -r doms/listen.example.com/subs-ssl/www/

=== Sourcen besorgen und entpacken ===

Unter http://www.gnu.org/software/mailman/ die aktuelle Software besorgen. Dort findet sich ein Link zu den 2er-Versionen von Mailman (http://ftp.gnu.org/gnu/mailman/). Die letzte Version downloaden ...

~$ wget http://ftp.gnu.org/gnu/mailman/mailman-2.1.29.tgz

... und entpacken:

~$ tar -xzvf mailman-2.1.29.tgz

Ab diesem Augenblick gibt es ein Verzeichnis namens <tt>mailman-2.1.29/</tt>. Darin liegt die nunmehr entpackte ''Quellcode'' der Mailman-Software. Nach dem Kompilieren (folgt unten) wird die fertig kompilierte, gebrauchsfähige Mailman-Software in dem zusätzlich vorhandenen Verzeichnis <tt>mailman/</tt> liegen. (Dieses Verzeichnis wird beim Konfigurieren der Source als "prefix" angegeben.)

=== var-Verzeichnis für Log-Dateien anlegen ===

Bei der Installation als Paketuser (xyz00-listen):
~$ cd && mkdir -p mailman/var
~$ chmod 02775 mailman/var

Bei der Installation als Paketadmin (xyz00):
~$ cd && mkdir var/mailman
~$ chmod 02775 var/mailman

=== Mailman konfigurieren ===

In das Source-Verzeichnis wechseln:

~$ cd mailman-2.1.29

Bei der Installation durch den Paketuser (xyz00-listen):
~/mailman-2.1.29$ ./configure --prefix=/home/pacs/xyz00/users/listen/mailman \
--with-username=xyz00-listen \
--with-groupname=xyz00 \
--with-var-prefix=/home/pacs/xyz00/users/listen/mailman/var \
--with-cgi-gid=xyz00 \
--with-mail-gid=xyz00

Bei der Installation durch den Paketadmin (xyz00):
~/mailman-2.1.29$ ./configure --prefix=/home/pacs/xyz00/mailman \
--with-username=xyz00 \
--with-groupname=xyz00 \
--with-var-prefix=/home/pacs/xyz00/var/mailman \
--with-cgi-gid=xyz00 \
--with-mail-gid=nogroup

(Die Rückwärtsschrägstriche "\" am Zeilenende bedeuten, dass der Befehl in der nächsten Zeile weitergeht. Alternativ können alle Argumente in eine Zeile getippt werden.)

=== Mailman kompilieren ===

~/mailman-2.1.29$ make
~/mailman-2.1.29$ make install

=== Datenrechte prüfen ===

Sicherheitshalber die Dateirechte durch Mailmans mitgeliefertes Tool prüfen und ggf. korrigieren lassen:

~/mailman-2.1.29$ cd ..
~$ mailman/bin/check_perms -f

== Die neue Mailman-Installation konfigurieren ==

=== Konfigurationsdatei <tt>mm_cfg.py</tt> editieren ===

~$ nano mailman/Mailman/mm_cfg.py

Eine Beispielkonfiguration für listen.example.com könnte so aussehen:

[...]
##################################################
# Put YOUR site-specific settings below this line.
# -*- python -*-

DEFAULT_HOST_NAME = 'listen.example.com'
DEFAULT_EMAIL_HOST = 'listen.example.com'
DEFAULT_URL_HOST = 'listen.example.com'
add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)
add_virtualhost(zweite.listendomain.com, zweite.listendomain.com)

DEFAULT_SERVER_LANGUAGE = 'de'

DEFAULT_URL_PATTERN = 'http://%s/'

# Es wird der HS Mailversand für Bulkmail verwendet:
SMTPHOST = 'localhost'
SMTPPORT = 4587
SMTP_AUTH = True
SMTP_USER = 'xyz00-listen'
SMTP_PASSWD = 'das-passwort-des-o.-g.-users'
SMTP_USE_TLS = True

In <tt>~/mailman/Mailman/Defaults.py</tt> sieht man, was in mm_cfg.py alles angepasst werden kann.

==== Mailman gegen Subscription Spam härten ====

Mailman wird gelegentlich von böswilligen Crackern benutzt, die damit sogenannten Subscription Spam erzeugen. Dabei wird eine Mailadresse von Bots an Mailman zur Eintragung übergeben. Diese Mailadresse wird daraufhin brav von Mailman angeschrieben. Wenn das tausende von Mailmans auf der ganzen Welt zugleich machen, wird die Mailadresse zugespammt. Hier ist die Abhilfe:

Die Idee kommt von https://www.ralfj.de/blog/2018/06/02/mailman-subscription-spam.html

Auf der Kommandozeile ein zufälliges Secret-String erstellen:
openssl rand -base64 18

Und dann in die Konfigurationsdatei den erzeugten String einfügen:

SUBSCRIBE_FORM_SECRET = '<Secret-String>'

=== CGI-Programme in die Domain kopieren ===

Bei der Installation als Paketuser (xyz00-listen):

Die fertig kompilierten CGIs von Mailman müssen in das CGI-Verzeichnis der Domain (oder der Domains), auf der das Webfrontend von Mailman laufen soll, kopiert werden. Symbolische Links sind nicht ausreichend.

~$ mkdir ~/doms/listen.example.com/cgi-ssl/mailman
~$ cp mailman/cgi-bin/* doms/listen.example.com/cgi-ssl/mailman/

Zusätzlich muss das sticky-Flag von den kopierten Dateien entfernt werden:

~$ chmod g-s ~/doms/listen.example.com/cgi/mailman/*

Bei der Installation als Paketadmin (xyz00):

Die CGI-Programme können im Mailman-Verzeichnis bleiben. Im CGI-Verzeichnis von jeder Domain, auf der das Mailman-Webfrontend laufen soll, werden symbolische Links dazu erstellt:

~$ cd doms/listen.example.com/cgi-ssl
~/doms/listen.example.com/cgi-ssl$ ln -s ../../../mailman/cgi-bin mailman

=== Mailman-Icons in die Domains kopieren ===

Die Icons können wahlweise verlinkt oder kopiert werden:

~$ cd doms/listen.example.com/htdocs-ssl
~/doms/listen.example.com/htdocs-ssl$ ln -s ../../../mailman/icons

oder

~$ cp -R mailman/icons doms/listen.example.com/htdocs-ssl/

=== Die Datei .htaccess bearbeiten ===

Bei einer dedizierten Mailman-Domain sollte man dafür sorgen, dass Mailman nicht nur unter <tt><nowiki>https://listen.example.com/cgi-bin/mailman</nowiki></tt>, sondern auch unter <tt><nowiki>https://listen.example.com/</nowiki></tt> erreichbar ist.

Dazu werden in <tt><nowiki>~/doms/listen.example.com/htdocs-ssl/.htaccess</nowiki></tt> folgende Rewrite-Anweisungen eintragen.

RewriteEngine On
RewriteCond %{REQUEST_URI} !^/icons/
RewriteRule ^(.*)$ /cgi-bin/mailman/$1
RewriteRule ^/cgi-bin/mailman/$ /cgi-bin/mailman/listinfo

Beachte dabei die zweite Zeile: Anfragen für Icons sollen ''nicht'' umgeschrieben werden.

Wenn Mailman z.B. auf einer als Unterverzeichnis angelegten Subdomain läuft und unter <tt><nowiki>https://www.example.com/mailman</nowiki></tt> statt <tt><nowiki>https://www.example.com/cgi-bin/mailman</nowiki></tt> erreichbar sein soll, hilft folgendes in der <tt><nowiki>~/doms/example.com/subs-ssl/www/.htaccess</nowiki></tt>:

RewriteEngine On
RewriteCond %{REQUEST_URI} !^/icons/
RewriteRule ^mailman/(.*)$ /cgi-bin/mailman/$1
RewriteRule ^/cgi-bin/mailman/$ /cgi-bin/mailman/listinfo

(In diesem Fall kann die Zeile <tt>DEFAULT_URL_PATTERN...</tt> in der <tt>mm_cfg.py</tt> auskommentiert werden.)

=== Hauptpasswort setzen ===

Das "site password" ist in Mailman eine Art Generalschlüssel: es wird neben dem jeweiligen Admin- oder Moderator-Passwort überall in der Weboberfläche für sämtliche Mailing-Listen akzeptiert. Also vorsichtig wählen! Das "site password" einrichten mit dem Befehl:

~$ mailman/bin/mmsitepass

=== Cronjobs einrichten ===

In die [[Cron |Crontab]] werden Befehle eingetragen, um die Mail-Warteschlange abzuarbeiten, Logs zu löschen, usw.:

# Warteschlange jede Minute bearbeiten:
* * * * * ~/mailman/bin/qrunner -o -r All
# Verarbeitungslogs in der 47ten Minute jeder Stunde löschen:
47 * * * * rm -f ~/var/mailman/logs/qrunner

Damit übernimmt cron die Funktion des qrunner-Dämons, der normalerweise auf einem Mailman-Server laufen sollte.

Das Logfile wird stündlich gelöscht, da es sonst sehr schnell sehr groß wird. Falls Mailman von einem Paketuser (bspw. "xyz00-listen") installiert wurde, sollte die letzte Zeile im Beispiel oben so lauten:

47 * * * * rm -f ~/mailman/var/logs/qrunner

... entsprechend dem beim Konfigurieren angegebenen <tt>var</tt>-Verzeichnis, siehe oben.

Zudem müssen noch die von Mailman ohnehin vorgesehenen cron-Aufträge aus <tt>~/mailman/cron/crontab.in</tt> dem crontab des Users angehängt werden:

crontab -l > mycronjobs.tmp
cat ~/mailman/cron/crontab.in >> mycronjobs.tmp
crontab mycronjobs.tmp

== Mailinglisten einrichten ==

Jetzt läuft die Software; nun können die eigentlichen Verteiler angelegt werden. Als erster '''muß''' ein Hauptverteiler ("site list") eingerichtet werden. Dieser Verteiler dient u.a. als Absender der Paßwort-Erinnerungen an die Abonnenten aller Mailinglisten. Er hat standardmäßig den Namen "mailman". Falls ein anderer Name verwendet werden soll, muß dieser mit der Anweisung

MAILMAN_SITE_LIST = 'sitelistname'

in der Konfigurationsdatei <tt>mailman/Mailman/mm_cfg.py</tt> eingetragen werden.

=== Den Hauptverteiler "mailman" anlegen ===

Die "site list" mit dem Namen "mailman" ist die Mailingliste der lokalen Mailman-Administratoren. Sie wird zur einwandfreien Funktion von Mailman benötigt.

Mit dem Mailman-Befehl newlist den Verteiler anlegen:

~$ mailman/bin/newlist mailman
Enter the email of the person running the list: admin@xyz00.hostsharing.net
Initial mailman password:

(Der Befehl newlist kann – alternativ zur Weboberfläche – später benutzt werden, um gewöhnliche Mailinglisten anzulegen.)

Nur dieses eine Mal für die "site list" müssen wir die Konfigurationsvorgaben laden. (Gewöhnliche Mailinglisten werden später über die Weboberfläche konfiguriert.)

Falls mailman vom Paketuser (bspw. "xyz00-listen") installiert wurde:

~$ mailman/bin/config_list -i ~/mailman/var/data/sitelist.cfg mailman

Falls mailman vom Paketadmin ("xyz00") installiert wurde:

~$ mailman/bin/config_list -i ~/var/mailman/data/sitelist.cfg mailman

Diese Konfigurationsdatei soll '''nicht''' auf gewöhnliche Mailinglisten anwendet werden.

=== E-Mail Adressen bei Mailman einrichten ===

Sobald ein neuer Verteiler angelegt worden ist, sendet Mailman eine E-Mail an den dabei eingetragenen Listenadministrator. Diese E-Mail enthält die Anweisung, E-Mail-Aliases für den neuen Verteiler und für die verschiedenen Mailman-Funktionen anzulegen. Bei Hostsharing wird die Zustellung von E-Mails an Mailman anders geregelt: alle E-Mails an Mailman werden an erweiterte ''E-Mail-Adressen'' des Mailman-Users xyz00-listen geschickt. Diese Adressen haben die form <tt>xyz00-listen'''+'''<liste>[_funktion]</tt>. E-Mails an diese Adressen werden dann durch Pipe-Anweisungen in ''.forward-Dateien'' im Home-Verzeichnis des Mailman-Users mit den entsprechenden Argumenten an Mailman übergeben.

Falls Mailman von einem Paketuser (bspw. "xyz00-listen") installiert wurde, werden ''E-Mail-Adressen'' durch [https://doc.hostsharing.net/users/administration/hsadmin/index.html hsadmin (bzw. das Befehlszeilentool hsscript)] eingerichtet; die ''.forward-Dateien'' werden durch [[Login_mit_SSH|Shell-Befehle]] angelegt.

Das folgende Beispiel zeigt die Befehle, mit denen in einer interaktiven hsscript-Sitzung die E-Mail-Adressen für die Hauptliste "mailman" eingerichtet werden. (Für spätere Mailinglisten wird in den Argumenten "mailman" durch den Namen der Mailingliste ersetzt.)

hsscript -u xyz00 -i
[hsscript verlangt die Eingabe des Passworts vom Paketadmin xyz00; dann können diese Befehle eingegeben werden:]
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman',target:'xyz00-listen+mailman'}})
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-admin',target:'xyz00-listen+mailman-admin'}})
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-bounces',target:'xyz00-listen+mailman-bounces'}})
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-confirm',target:'xyz00-listen+mailman-confirm'}})
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-join',target:'xyz00-listen+mailman-join'}})
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-leave',target:'xyz00-listen+mailman-leave'}})
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-owner',target:'xyz00-listen+mailman-owner'}})
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-request',target:'xyz00-listen+mailman-request'}})
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-subscribe',target:'xyz00-listen+mailman-subscribe'}})
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-unsubscribe',target:'xyz00-listen+mailman-unsubscribe'}})

Die korrekte Einrichtung der E-Mail-Adressen kann in der Web-Oberfläche von hsadmin kontrolliert werden.

Für jede der soeben eingerichteten Adressen wird nun eine <tt>.forward</tt>-Datei im Homeverzeichnis des Users xyz00-listen angelegt. Die Dateinamen bestehen aus der Zeichenfolge <tt>.forward+</tt> gefolgt vom Namen der ausführen soll. Der Inhalt der jeweiligen <tt>.forward</tt>-Datei legt die Weiterleitung der Mail durch einen Pipe an Mailman fest, mit dem jeweiligen Befehl als Argument:

"|/home/pacs/xyz00/users/listen/mailman/mail/mailman [Befehl] [Listenname]"

Zum Beispiel wird die <tt>.forward</tt>-Datei .forward+mailman-subscribe verwendet, wenn eine E-Mail an die Adresse <tt>mailman-subscribe@listen.example.com</tt> eingeht. Aufgrund der oben eingerichteten E-Mail-Adresse mit dem Ziel <tt>xyz00-listen+mailman-subscribe</tt> wertet der Mail-Transfer-Agent die <tt>.forward</tt>-Datei <tt>.forward+mailman-subscribe</tt> im Home-Verzeichnis des Users xyz00-listen aus, und entsprechend ihrem Inhalt wird die Mail an die Mailman-Software mit den Argumenten "subscribe mailman" übergeben.

Das folgende Beispiel zeigt die Befehle, mit denen an der Befehlszeilenaufforderung der Shell die <tt>.forward</tt>-Dateien für die Hauptliste "mailman" eingerichtet werden. (Für spätere Mailinglisten wird in den Argumenten und in den Namen der <tt>.forward</tt>-Dateien "mailman" durch den Namen der Mailingliste ersetzt, jedoch '''nicht''' in der Pfadangabe zum Mailman-Programm selbst; diese ändert sich ja nicht.)

echo 'admin@xyz00.hostsharing.net' > .forward # Weiterleitung von cron Fehlern etc an Paketadmin.
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman post mailman"' > .forward+mailman
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman admin mailman"' > .forward+mailman-admin
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman bounces mailman"' > .forward+mailman-bounces
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman confirm mailman"' > .forward+mailman-confirm
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman join mailman"' > .forward+mailman-join
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman leave mailman"' > .forward+mailman-leave
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman owner mailman"' > .forward+mailman-owner
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman request mailman"' > .forward+mailman-request
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman subscribe mailman"' > .forward+mailman-subscribe
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman unsubscribe mailman"' > .forward+mailman-unsubscribe

Die vielen Befehle können von dieser Anleitung kopiert und nach Anpassung auf den tatsächlichen Unsernamen in die SSH-Sitzung kopiert werden. Noch leichter ist es, mit einem Editor einen Shell-Skript namens <tt>~/bin/addforwards</tt> mit folgendem Inhalt zu erstellen:

#!/bin/sh
# .forward-Dateien für einen Verteiler unter Mailman einrichten.
#
if [ "$1" = "" ] ; then
echo "Aufruf: $0 Listenname\n"
exit
fi
if [ "$2" != "" ] ; then
echo "Aufruf: $0 Listenname\n"
exit
fi
if [ "`pwd`" != "`echo ~`" ] ; then
echo "Diesen Befehl vom Home-Verzeichnis aus aufrufen.\n"
exit
fi
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman post $1\"" > .forward+$1
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman admin $1\"" > .forward+$1-admin
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman bounces $1\"" > .forward+$1-bounces
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman confirm $1\"" > .forward+$1-confirm
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman join $1\"" > .forward+$1-join
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman leave $1\"" > .forward+$1-leave
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman owner $1\"" > .forward+$1-owner
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman request $1\"" > .forward+$1-request
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman subscribe $1\"" > .forward+$1-subscribe
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman unsubscribe $1\"" > .forward+$1-unsubscribe
exit

Der Skript muß natürlich als ausführbar gekennzeichnet werden:

~$ chmod u+x bin/addforwards

Die Erweiterung dieses Skripts um die <tt>hsscript</tt>-Befehle wird dem geneigten Leser als Aufgabe überlassen.

=== Administration ===

Als erstes sollte man als Administrator der neuen Mailman-Installation die Liste "mailman" selbst abonnieren. Die Liste "mailman" kann aber unter <tt><nowiki>https://listen.example.com/mailman/admin/mailman</nowiki></tt> verwaltet werden.

Die Hauptseite der Mailman-Web-Verwaltung ist in unserem Beispiel (mit den oben angegebenen Rewrite-Anweisungen in der Datei <tt>.htaccess</tt>) <tt><nowiki>https://listen.example.com/mailman/admin/</nowiki></tt>. Diese Seite enthält Links zu den bisher eingerichteten Mailinglisten (außer "mailman") und einen Link, um neue Mailinglisten anzulegen (<tt><nowiki>https://listen.example.com/mailman/create</nowiki></tt>). Das Anlegen einer neuen Mailingliste geschieht entweder über diesen Link oder (wie oben) in der Shell mit dem Befehl:

~$ mailman/bin/newlist <Listenname>

In beiden Fällen müssen zusätzlich die E-Mail-Adressen und die <tt>.forward</tt>-Dateien wie bei dem Einrichten der Liste "mailman" nach Verfahren im obigen Abschnitt angelegt werden.

Für die Verwaltung der Mailinglisten im Alltag, d.h. den Umgang mit Bounces, Spam, Abonnenten usw., siehe u.a. die [https://wiki.list.org/ Mailman-Wiki].

== Feintuning ==

Wer will, kann auch noch etwas Platz sparen. Die normale Mailmaninstallation schlägt mit über 20 MB zu Buche...

Mit den folgenden Tips kann man das auf ca. 6 MB reduzieren :)

Es kann natürlich sein, dass ich zuviel lösche, aber bei mir funktioniert's. Wenn ihr also sicher(er) sein wollt, dass euch der Mailman nicht um die Ohren fliegt, macht das nicht!

* ~/mailman/cgi-bin und ~/mailman/icons können gelöscht werden, falls sie an andere Stelle kopiert worden sind.
* Die nicht benötigten Sprachen in ~/mailman/messages löschen.
* Die nicht benötigten Sprachen in ~/mailman/templates löschen (bis auf englisch).
* ~/mailman/tests kann, soweit ich das sehe, komplett gelöscht werden.
* Falls man koreanisch und japanisch nicht braucht, kann man folgendes machen:
* in ~/mailman/bin/paths.py, ~/mailman/cron/paths.py und ~/mailman/scripts/paths.py die Zeilen:

# In a normal interactive Python environment, the japanese.pth and korean.pth
# files would be imported automatically. But because we inhibit the importing
# of the site module, we need to be explicit about importing these codecs.
if not jaok:
import japanese
# As of KoreanCodecs 2.0.5, you had to do the second import to get the Korean
# codecs installed, however leave the first import in there in case an upgrade
# changes this.
if not kook:
import korean
import korean.aliases

auskommentieren.

Dann kann man ~/mailman/pythonlib/japanese, ~/mailman/pythonlib/korean, ~/mailman/pythonlib/korean.pth sowie ~/mailman/pythonlib/lib löschen.

Man kann auch noch die Debug-Informationen aus den binaries strippen:

strip ~/mailman/mail/mailman
strip ~/mailman/cgi-bin/*

Falls die CGIs nicht gesymlinkt wurden:

strip ~/doms/listen.example.com/cgi/mailman/*

== Multidomainfähigkeit ==

Seit Mailman 2.x kann eine Mailman-Installation unter gewissen Einschränkungen für mehrere Domains verwendet werden. Hier soll kurz gezeigt werden, was geht und wie es geht.

=== Anleitung ===

Logischerweise muss das Webfrontend (die CGIs) auf allen Domains installiert werden.

Wenn man nun Mailinglisten mit newlist neu anlegt, muss man den Hostnamen für das Webfontend mit angeben, und zwar so:

~$ mailman/bin/newlist listenname@listen.example.com

Es ist ggf. wichtig, dass in der mm_cfg.py eine entsprechende add_virtualhost-Direktive für www.example.com steht, die der Frontend-URL einen Host-Part für die Mailadressen zuordnet. Ist eine solche Direktive nicht vorhanden, so wird listen.example.com sowohl als URL für das Webfrontend wie auch als Hostpart für E-Mailadressen verwendet. (Was für separate aufgeschaltete Domains wie z.B. listen.example.com gerade zutrifft.)

Liegt das Frondend nicht auf der Maildomain ist es wichtig, dass ihr Mailman sagt, für welches die zugehörige Maildomain ist. Dies tut ihr in der Datei ~/mailman/Mailman/mm_cfg.py:

Also z.B.
DEFAULT_URL_HOST = 'www.example.com'
DEFAULT_EMAIL_HOST = 'listen.example.com'
add_virtualhost(DEFAULT_URL_HOST,DEFAULT_EMAIL_HOST)

und
add_virtualhost('www.zoopnet.de', 'lists.zoopnet.de')

Das bedeutet, dass Mailman per default davon ausgeht, dass alle Listen für die Domain example.com sind.
Alle weiteren add_virtualhost-Direktiven ordnen einem Hostnamen für das Webfrontend (z.B. www.zoopnet.de) einen Hostpart für die Adresse der Mailinglisten (z.B. lists.zoopnet.de) zu.

Tip von Raimund Specht: Lässt man den zweiten Parameter weg, also schreibt z.B. add_virtualhost('www.example.org'), dann benutzt Mailman als Hostpart alles was nach dem ersten Punkt steht, hier also example.org als Maildomain.

Prinzipiell war's das. Man muss die Listeneinträge natürlich immer in die richtige virtusertable eintragen, und für gleichnamige Mailinglisten auf verschiedenen Domains (mailman@*) verschidene +Ergänzungen bzw. aliase verwenden. :)

=== Probleme ===

Verschiedene Listen mit gleichem Namen (also z.B. liste@example1.com und liste@example2.com) sind mit Mailman 2.1 leider nicht möglich.

== Tips und Tricks ==

=== URL Änderungen ===
Nach URL Änderungen stimmen Links im Web-Interface nicht mehr und Listen werden nicht mehr angezeigt.
Es sind dann, zusätzlich zur Anpassung der mm_cfg.py, schon bestehende Listen und Archive mit folgendem Befehl zu aktualisieren:
~/mailman/bin/withlist -l -r fix_url <Listen_Name> -v -u <Neue_Url>
<Listen_Name> steht für die Mailingliste, die bearbeitet werden soll. <Neue_Url> für die neue URL/Webadresse des Webinterfaces.

=== Weitere Cron-Jobs zur Mailinglisten Verwaltung ===

Folgende Cronjobs helfen bei der Verwaltung und sind User freundlich:

< In Arbeit >

== Referenzen ==

Lösung zur installation als Domainadmin (xyz00-listen) statt Paketadmin (xyz00): https://lists.hostsharing.net/archiv/support/2009-June/019414.html<br>

Ältere Anleitung für Installation als Domain-Admin (xyz00-listen): <http://lists.hostsharing.net/archiv/support/2005-January/012426.html><br>

"Kleine Tools" auf http://hs.andreasloesch.de/, wobei das 'pac-mm-install' wahrscheinlich nicht aktuell (genug) ist<br>

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

Mailman Installieren

2021-07-07T06:36:54Z

Deg00-m.website: /* Mailman gegen Subscription Spam härten */

Mailman Installieren

2021-07-07T06:33:09Z

Deg00-m.website: /* Die neue Mailman-Installation konfigurieren */

== Vorab: Die Wahl von Mailman 2 ==

Mailman 2 hängt von Python 2.7 ab und wird damit voraussichtlich nur noch eine begrenzte Nutzungsdauer haben. Mailman 3 ist jetzt verfügbar (siehe [[Mailman_3_installieren]]), aber deutlich schwerer und komplexer im Betrieb. Es gibt auch weniger leistungsfähige Software, um E-Mail-Verteiler zu betreiben, wie beispielsweise [[mlmmj]]. Für eine Diskussion der Situation im Oktober 2019, siehe das HS-Support-Archiv ab [https://lists.hostsharing.net/archiv/support/2019-October/067243.html hier.]

== Mailman 2 installieren ==

(zuletzt getestet mit mailman-2.1.29; Installation durch Paketuser)

Vielen Dank an alle Benutzer, die Verbesserungen beisteuern!

=== Unter welchem Account installieren? ===

Mailman kann vom Paketadmin (beipsielsweise "xyz00") oder von einem Paketuser (bspw. "xyz00-listen") installiert werden. Letzteres ist dringend empfohlen, denn wenn Mailman vom Paketadmin installiert wird, haben ausnahmslos alle Paketuser direkten Zugriff auf die Mailman-Daten, und bei Sicherheitslücken in Mailman wäre eventuell eine Rechte-Eskalierung auf Paketadmin-Ebene potentiell zu befürchten.

Dem Paketuser, unter dem Mailman installiert wird, können mehrere Subdomains aufschaltet werden, und Mailinglisten können auch die Domainnamen verwenden, die anderen Paketusern gehören.

Vorteil der Installation als Paketuser ist, dass nur dieser direkten Zugriff auf die Mailmandaten hat und mailman ohne Paketadminrechte läuft. Während der Emailauslieferung gelten (wie immer bei der Mailweiterleitung durch .forward-Dateien oder durch procmail) die Rechte des Paketusers, dem die Mailman-Installation gehört.

Nachteil der Installation als Paketuser ist lediglich, dass die Paketdomain mit dem SSL Zertifikat von Hostsharing nicht genutzt werden kann.

=== Einen User und eine Domain anlegen ===

Unter admin.hostsharing.net als xyz00 anmelden; den User xyz00-listen erzeugen; die Domain listen.example.com mit "Domain-User" xyz00-listen anlegen. Aus admin.hostsharing.net abmelden.

Mit [[Login_mit_SSH|SSH]] an hostsharing.net als xyz00-listen anmelden. Die Redirect-Zeile aus <tt><nowiki>~/doms/listen.example.com/htdocs-ssl/.htaccess</nowiki></tt> löschen:

~$ echo "" > ~/doms/listen.example.com/htdocs-ssl/.htaccess

Die Default-Subdomains www.* löschen:

~$ rm -r doms/listen.example.com/subs/www/
~$ rm -r doms/listen.example.com/subs-ssl/www/

=== Sourcen besorgen und entpacken ===

Unter http://www.gnu.org/software/mailman/ die aktuelle Software besorgen. Dort findet sich ein Link zu den 2er-Versionen von Mailman (http://ftp.gnu.org/gnu/mailman/). Die letzte Version downloaden ...

~$ wget http://ftp.gnu.org/gnu/mailman/mailman-2.1.29.tgz

... und entpacken:

~$ tar -xzvf mailman-2.1.29.tgz

Ab diesem Augenblick gibt es ein Verzeichnis namens <tt>mailman-2.1.29/</tt>. Darin liegt die nunmehr entpackte ''Quellcode'' der Mailman-Software. Nach dem Kompilieren (folgt unten) wird die fertig kompilierte, gebrauchsfähige Mailman-Software in dem zusätzlich vorhandenen Verzeichnis <tt>mailman/</tt> liegen. (Dieses Verzeichnis wird beim Konfigurieren der Source als "prefix" angegeben.)

=== var-Verzeichnis für Log-Dateien anlegen ===

Bei der Installation als Paketuser (xyz00-listen):
~$ cd && mkdir -p mailman/var
~$ chmod 02775 mailman/var

Bei der Installation als Paketadmin (xyz00):
~$ cd && mkdir var/mailman
~$ chmod 02775 var/mailman

=== Mailman konfigurieren ===

In das Source-Verzeichnis wechseln:

~$ cd mailman-2.1.29

Bei der Installation durch den Paketuser (xyz00-listen):
~/mailman-2.1.29$ ./configure --prefix=/home/pacs/xyz00/users/listen/mailman \
--with-username=xyz00-listen \
--with-groupname=xyz00 \
--with-var-prefix=/home/pacs/xyz00/users/listen/mailman/var \
--with-cgi-gid=xyz00 \
--with-mail-gid=xyz00

Bei der Installation durch den Paketadmin (xyz00):
~/mailman-2.1.29$ ./configure --prefix=/home/pacs/xyz00/mailman \
--with-username=xyz00 \
--with-groupname=xyz00 \
--with-var-prefix=/home/pacs/xyz00/var/mailman \
--with-cgi-gid=xyz00 \
--with-mail-gid=nogroup

(Die Rückwärtsschrägstriche "\" am Zeilenende bedeuten, dass der Befehl in der nächsten Zeile weitergeht. Alternativ können alle Argumente in eine Zeile getippt werden.)

=== Mailman kompilieren ===

~/mailman-2.1.29$ make
~/mailman-2.1.29$ make install

=== Datenrechte prüfen ===

Sicherheitshalber die Dateirechte durch Mailmans mitgeliefertes Tool prüfen und ggf. korrigieren lassen:

~/mailman-2.1.29$ cd ..
~$ mailman/bin/check_perms -f

== Die neue Mailman-Installation konfigurieren ==

=== Konfigurationsdatei <tt>mm_cfg.py</tt> editieren ===

~$ nano mailman/Mailman/mm_cfg.py

Eine Beispielkonfiguration für listen.example.com könnte so aussehen:

[...]
##################################################
# Put YOUR site-specific settings below this line.
# -*- python -*-

DEFAULT_HOST_NAME = 'listen.example.com'
DEFAULT_EMAIL_HOST = 'listen.example.com'
DEFAULT_URL_HOST = 'listen.example.com'
add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)
add_virtualhost(zweite.listendomain.com, zweite.listendomain.com)

DEFAULT_SERVER_LANGUAGE = 'de'

DEFAULT_URL_PATTERN = 'http://%s/'

# Es wird der HS Mailversand für Bulkmail verwendet:
SMTPHOST = 'localhost'
SMTPPORT = 4587
SMTP_AUTH = True
SMTP_USER = 'xyz00-listen'
SMTP_PASSWD = 'das-passwort-des-o.-g.-users'
SMTP_USE_TLS = True

In <tt>~/mailman/Mailman/Defaults.py</tt> sieht man, was in mm_cfg.py alles angepasst werden kann.

==== Mailman gegen Subscription Spam härten ====

Die Idee kommt von https://www.ralfj.de/blog/2018/06/02/mailman-subscription-spam.html

Auf der Kommandozeile ein zufälliges Secret-String erstellen:
openssl rand -base64 18

Und dann in die Konfigurationsdatei den erzeugten String einfügen:

SUBSCRIBE_FORM_SECRET = '<Secret-String>'

=== CGI-Programme in die Domain kopieren ===

Bei der Installation als Paketuser (xyz00-listen):

Die fertig kompilierten CGIs von Mailman müssen in das CGI-Verzeichnis der Domain (oder der Domains), auf der das Webfrontend von Mailman laufen soll, kopiert werden. Symbolische Links sind nicht ausreichend.

~$ mkdir ~/doms/listen.example.com/cgi-ssl/mailman
~$ cp mailman/cgi-bin/* doms/listen.example.com/cgi-ssl/mailman/

Zusätzlich muss das sticky-Flag von den kopierten Dateien entfernt werden:

~$ chmod g-s ~/doms/listen.example.com/cgi/mailman/*

Bei der Installation als Paketadmin (xyz00):

Die CGI-Programme können im Mailman-Verzeichnis bleiben. Im CGI-Verzeichnis von jeder Domain, auf der das Mailman-Webfrontend laufen soll, werden symbolische Links dazu erstellt:

~$ cd doms/listen.example.com/cgi-ssl
~/doms/listen.example.com/cgi-ssl$ ln -s ../../../mailman/cgi-bin mailman

=== Mailman-Icons in die Domains kopieren ===

Die Icons können wahlweise verlinkt oder kopiert werden:

~$ cd doms/listen.example.com/htdocs-ssl
~/doms/listen.example.com/htdocs-ssl$ ln -s ../../../mailman/icons

oder

~$ cp -R mailman/icons doms/listen.example.com/htdocs-ssl/

=== Die Datei .htaccess bearbeiten ===

Bei einer dedizierten Mailman-Domain sollte man dafür sorgen, dass Mailman nicht nur unter <tt><nowiki>https://listen.example.com/cgi-bin/mailman</nowiki></tt>, sondern auch unter <tt><nowiki>https://listen.example.com/</nowiki></tt> erreichbar ist.

Dazu werden in <tt><nowiki>~/doms/listen.example.com/htdocs-ssl/.htaccess</nowiki></tt> folgende Rewrite-Anweisungen eintragen.

RewriteEngine On
RewriteCond %{REQUEST_URI} !^/icons/
RewriteRule ^(.*)$ /cgi-bin/mailman/$1
RewriteRule ^/cgi-bin/mailman/$ /cgi-bin/mailman/listinfo

Beachte dabei die zweite Zeile: Anfragen für Icons sollen ''nicht'' umgeschrieben werden.

Wenn Mailman z.B. auf einer als Unterverzeichnis angelegten Subdomain läuft und unter <tt><nowiki>https://www.example.com/mailman</nowiki></tt> statt <tt><nowiki>https://www.example.com/cgi-bin/mailman</nowiki></tt> erreichbar sein soll, hilft folgendes in der <tt><nowiki>~/doms/example.com/subs-ssl/www/.htaccess</nowiki></tt>:

RewriteEngine On
RewriteCond %{REQUEST_URI} !^/icons/
RewriteRule ^mailman/(.*)$ /cgi-bin/mailman/$1
RewriteRule ^/cgi-bin/mailman/$ /cgi-bin/mailman/listinfo

(In diesem Fall kann die Zeile <tt>DEFAULT_URL_PATTERN...</tt> in der <tt>mm_cfg.py</tt> auskommentiert werden.)

=== Hauptpasswort setzen ===

Das "site password" ist in Mailman eine Art Generalschlüssel: es wird neben dem jeweiligen Admin- oder Moderator-Passwort überall in der Weboberfläche für sämtliche Mailing-Listen akzeptiert. Also vorsichtig wählen! Das "site password" einrichten mit dem Befehl:

~$ mailman/bin/mmsitepass

=== Cronjobs einrichten ===

In die [[Cron |Crontab]] werden Befehle eingetragen, um die Mail-Warteschlange abzuarbeiten, Logs zu löschen, usw.:

# Warteschlange jede Minute bearbeiten:
* * * * * ~/mailman/bin/qrunner -o -r All
# Verarbeitungslogs in der 47ten Minute jeder Stunde löschen:
47 * * * * rm -f ~/var/mailman/logs/qrunner

Damit übernimmt cron die Funktion des qrunner-Dämons, der normalerweise auf einem Mailman-Server laufen sollte.

Das Logfile wird stündlich gelöscht, da es sonst sehr schnell sehr groß wird. Falls Mailman von einem Paketuser (bspw. "xyz00-listen") installiert wurde, sollte die letzte Zeile im Beispiel oben so lauten:

47 * * * * rm -f ~/mailman/var/logs/qrunner

... entsprechend dem beim Konfigurieren angegebenen <tt>var</tt>-Verzeichnis, siehe oben.

Zudem müssen noch die von Mailman ohnehin vorgesehenen cron-Aufträge aus <tt>~/mailman/cron/crontab.in</tt> dem crontab des Users angehängt werden:

crontab -l > mycronjobs.tmp
cat ~/mailman/cron/crontab.in >> mycronjobs.tmp
crontab mycronjobs.tmp

== Mailinglisten einrichten ==

Jetzt läuft die Software; nun können die eigentlichen Verteiler angelegt werden. Als erster '''muß''' ein Hauptverteiler ("site list") eingerichtet werden. Dieser Verteiler dient u.a. als Absender der Paßwort-Erinnerungen an die Abonnenten aller Mailinglisten. Er hat standardmäßig den Namen "mailman". Falls ein anderer Name verwendet werden soll, muß dieser mit der Anweisung

MAILMAN_SITE_LIST = 'sitelistname'

in der Konfigurationsdatei <tt>mailman/Mailman/mm_cfg.py</tt> eingetragen werden.

=== Den Hauptverteiler "mailman" anlegen ===

Die "site list" mit dem Namen "mailman" ist die Mailingliste der lokalen Mailman-Administratoren. Sie wird zur einwandfreien Funktion von Mailman benötigt.

Mit dem Mailman-Befehl newlist den Verteiler anlegen:

~$ mailman/bin/newlist mailman
Enter the email of the person running the list: admin@xyz00.hostsharing.net
Initial mailman password:

(Der Befehl newlist kann – alternativ zur Weboberfläche – später benutzt werden, um gewöhnliche Mailinglisten anzulegen.)

Nur dieses eine Mal für die "site list" müssen wir die Konfigurationsvorgaben laden. (Gewöhnliche Mailinglisten werden später über die Weboberfläche konfiguriert.)

Falls mailman vom Paketuser (bspw. "xyz00-listen") installiert wurde:

~$ mailman/bin/config_list -i ~/mailman/var/data/sitelist.cfg mailman

Falls mailman vom Paketadmin ("xyz00") installiert wurde:

~$ mailman/bin/config_list -i ~/var/mailman/data/sitelist.cfg mailman

Diese Konfigurationsdatei soll '''nicht''' auf gewöhnliche Mailinglisten anwendet werden.

=== E-Mail Adressen bei Mailman einrichten ===

Sobald ein neuer Verteiler angelegt worden ist, sendet Mailman eine E-Mail an den dabei eingetragenen Listenadministrator. Diese E-Mail enthält die Anweisung, E-Mail-Aliases für den neuen Verteiler und für die verschiedenen Mailman-Funktionen anzulegen. Bei Hostsharing wird die Zustellung von E-Mails an Mailman anders geregelt: alle E-Mails an Mailman werden an erweiterte ''E-Mail-Adressen'' des Mailman-Users xyz00-listen geschickt. Diese Adressen haben die form <tt>xyz00-listen'''+'''<liste>[_funktion]</tt>. E-Mails an diese Adressen werden dann durch Pipe-Anweisungen in ''.forward-Dateien'' im Home-Verzeichnis des Mailman-Users mit den entsprechenden Argumenten an Mailman übergeben.

Falls Mailman von einem Paketuser (bspw. "xyz00-listen") installiert wurde, werden ''E-Mail-Adressen'' durch [https://doc.hostsharing.net/users/administration/hsadmin/index.html hsadmin (bzw. das Befehlszeilentool hsscript)] eingerichtet; die ''.forward-Dateien'' werden durch [[Login_mit_SSH|Shell-Befehle]] angelegt.

Das folgende Beispiel zeigt die Befehle, mit denen in einer interaktiven hsscript-Sitzung die E-Mail-Adressen für die Hauptliste "mailman" eingerichtet werden. (Für spätere Mailinglisten wird in den Argumenten "mailman" durch den Namen der Mailingliste ersetzt.)

hsscript -u xyz00 -i
[hsscript verlangt die Eingabe des Passworts vom Paketadmin xyz00; dann können diese Befehle eingegeben werden:]
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman',target:'xyz00-listen+mailman'}})
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-admin',target:'xyz00-listen+mailman-admin'}})
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-bounces',target:'xyz00-listen+mailman-bounces'}})
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-confirm',target:'xyz00-listen+mailman-confirm'}})
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-join',target:'xyz00-listen+mailman-join'}})
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-leave',target:'xyz00-listen+mailman-leave'}})
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-owner',target:'xyz00-listen+mailman-owner'}})
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-request',target:'xyz00-listen+mailman-request'}})
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-subscribe',target:'xyz00-listen+mailman-subscribe'}})
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-unsubscribe',target:'xyz00-listen+mailman-unsubscribe'}})

Die korrekte Einrichtung der E-Mail-Adressen kann in der Web-Oberfläche von hsadmin kontrolliert werden.

Für jede der soeben eingerichteten Adressen wird nun eine <tt>.forward</tt>-Datei im Homeverzeichnis des Users xyz00-listen angelegt. Die Dateinamen bestehen aus der Zeichenfolge <tt>.forward+</tt> gefolgt vom Namen der ausführen soll. Der Inhalt der jeweiligen <tt>.forward</tt>-Datei legt die Weiterleitung der Mail durch einen Pipe an Mailman fest, mit dem jeweiligen Befehl als Argument:

"|/home/pacs/xyz00/users/listen/mailman/mail/mailman [Befehl] [Listenname]"

Zum Beispiel wird die <tt>.forward</tt>-Datei .forward+mailman-subscribe verwendet, wenn eine E-Mail an die Adresse <tt>mailman-subscribe@listen.example.com</tt> eingeht. Aufgrund der oben eingerichteten E-Mail-Adresse mit dem Ziel <tt>xyz00-listen+mailman-subscribe</tt> wertet der Mail-Transfer-Agent die <tt>.forward</tt>-Datei <tt>.forward+mailman-subscribe</tt> im Home-Verzeichnis des Users xyz00-listen aus, und entsprechend ihrem Inhalt wird die Mail an die Mailman-Software mit den Argumenten "subscribe mailman" übergeben.

Das folgende Beispiel zeigt die Befehle, mit denen an der Befehlszeilenaufforderung der Shell die <tt>.forward</tt>-Dateien für die Hauptliste "mailman" eingerichtet werden. (Für spätere Mailinglisten wird in den Argumenten und in den Namen der <tt>.forward</tt>-Dateien "mailman" durch den Namen der Mailingliste ersetzt, jedoch '''nicht''' in der Pfadangabe zum Mailman-Programm selbst; diese ändert sich ja nicht.)

echo 'admin@xyz00.hostsharing.net' > .forward # Weiterleitung von cron Fehlern etc an Paketadmin.
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman post mailman"' > .forward+mailman
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman admin mailman"' > .forward+mailman-admin
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman bounces mailman"' > .forward+mailman-bounces
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman confirm mailman"' > .forward+mailman-confirm
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman join mailman"' > .forward+mailman-join
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman leave mailman"' > .forward+mailman-leave
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman owner mailman"' > .forward+mailman-owner
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman request mailman"' > .forward+mailman-request
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman subscribe mailman"' > .forward+mailman-subscribe
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman unsubscribe mailman"' > .forward+mailman-unsubscribe

Die vielen Befehle können von dieser Anleitung kopiert und nach Anpassung auf den tatsächlichen Unsernamen in die SSH-Sitzung kopiert werden. Noch leichter ist es, mit einem Editor einen Shell-Skript namens <tt>~/bin/addforwards</tt> mit folgendem Inhalt zu erstellen:

#!/bin/sh
# .forward-Dateien für einen Verteiler unter Mailman einrichten.
#
if [ "$1" = "" ] ; then
echo "Aufruf: $0 Listenname\n"
exit
fi
if [ "$2" != "" ] ; then
echo "Aufruf: $0 Listenname\n"
exit
fi
if [ "`pwd`" != "`echo ~`" ] ; then
echo "Diesen Befehl vom Home-Verzeichnis aus aufrufen.\n"
exit
fi
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman post $1\"" > .forward+$1
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman admin $1\"" > .forward+$1-admin
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman bounces $1\"" > .forward+$1-bounces
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman confirm $1\"" > .forward+$1-confirm
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman join $1\"" > .forward+$1-join
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman leave $1\"" > .forward+$1-leave
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman owner $1\"" > .forward+$1-owner
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman request $1\"" > .forward+$1-request
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman subscribe $1\"" > .forward+$1-subscribe
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman unsubscribe $1\"" > .forward+$1-unsubscribe
exit

Der Skript muß natürlich als ausführbar gekennzeichnet werden:

~$ chmod u+x bin/addforwards

Die Erweiterung dieses Skripts um die <tt>hsscript</tt>-Befehle wird dem geneigten Leser als Aufgabe überlassen.

=== Administration ===

Als erstes sollte man als Administrator der neuen Mailman-Installation die Liste "mailman" selbst abonnieren. Die Liste "mailman" kann aber unter <tt><nowiki>https://listen.example.com/mailman/admin/mailman</nowiki></tt> verwaltet werden.

Die Hauptseite der Mailman-Web-Verwaltung ist in unserem Beispiel (mit den oben angegebenen Rewrite-Anweisungen in der Datei <tt>.htaccess</tt>) <tt><nowiki>https://listen.example.com/mailman/admin/</nowiki></tt>. Diese Seite enthält Links zu den bisher eingerichteten Mailinglisten (außer "mailman") und einen Link, um neue Mailinglisten anzulegen (<tt><nowiki>https://listen.example.com/mailman/create</nowiki></tt>). Das Anlegen einer neuen Mailingliste geschieht entweder über diesen Link oder (wie oben) in der Shell mit dem Befehl:

~$ mailman/bin/newlist <Listenname>

In beiden Fällen müssen zusätzlich die E-Mail-Adressen und die <tt>.forward</tt>-Dateien wie bei dem Einrichten der Liste "mailman" nach Verfahren im obigen Abschnitt angelegt werden.

Für die Verwaltung der Mailinglisten im Alltag, d.h. den Umgang mit Bounces, Spam, Abonnenten usw., siehe u.a. die [https://wiki.list.org/ Mailman-Wiki].

== Feintuning ==

Wer will, kann auch noch etwas Platz sparen. Die normale Mailmaninstallation schlägt mit über 20 MB zu Buche...

Mit den folgenden Tips kann man das auf ca. 6 MB reduzieren :)

Es kann natürlich sein, dass ich zuviel lösche, aber bei mir funktioniert's. Wenn ihr also sicher(er) sein wollt, dass euch der Mailman nicht um die Ohren fliegt, macht das nicht!

* ~/mailman/cgi-bin und ~/mailman/icons können gelöscht werden, falls sie an andere Stelle kopiert worden sind.
* Die nicht benötigten Sprachen in ~/mailman/messages löschen.
* Die nicht benötigten Sprachen in ~/mailman/templates löschen (bis auf englisch).
* ~/mailman/tests kann, soweit ich das sehe, komplett gelöscht werden.
* Falls man koreanisch und japanisch nicht braucht, kann man folgendes machen:
* in ~/mailman/bin/paths.py, ~/mailman/cron/paths.py und ~/mailman/scripts/paths.py die Zeilen:

# In a normal interactive Python environment, the japanese.pth and korean.pth
# files would be imported automatically. But because we inhibit the importing
# of the site module, we need to be explicit about importing these codecs.
if not jaok:
import japanese
# As of KoreanCodecs 2.0.5, you had to do the second import to get the Korean
# codecs installed, however leave the first import in there in case an upgrade
# changes this.
if not kook:
import korean
import korean.aliases

auskommentieren.

Dann kann man ~/mailman/pythonlib/japanese, ~/mailman/pythonlib/korean, ~/mailman/pythonlib/korean.pth sowie ~/mailman/pythonlib/lib löschen.

Man kann auch noch die Debug-Informationen aus den binaries strippen:

strip ~/mailman/mail/mailman
strip ~/mailman/cgi-bin/*

Falls die CGIs nicht gesymlinkt wurden:

strip ~/doms/listen.example.com/cgi/mailman/*

== Multidomainfähigkeit ==

Seit Mailman 2.x kann eine Mailman-Installation unter gewissen Einschränkungen für mehrere Domains verwendet werden. Hier soll kurz gezeigt werden, was geht und wie es geht.

=== Anleitung ===

Logischerweise muss das Webfrontend (die CGIs) auf allen Domains installiert werden.

Wenn man nun Mailinglisten mit newlist neu anlegt, muss man den Hostnamen für das Webfontend mit angeben, und zwar so:

~$ mailman/bin/newlist listenname@listen.example.com

Es ist ggf. wichtig, dass in der mm_cfg.py eine entsprechende add_virtualhost-Direktive für www.example.com steht, die der Frontend-URL einen Host-Part für die Mailadressen zuordnet. Ist eine solche Direktive nicht vorhanden, so wird listen.example.com sowohl als URL für das Webfrontend wie auch als Hostpart für E-Mailadressen verwendet. (Was für separate aufgeschaltete Domains wie z.B. listen.example.com gerade zutrifft.)

Liegt das Frondend nicht auf der Maildomain ist es wichtig, dass ihr Mailman sagt, für welches die zugehörige Maildomain ist. Dies tut ihr in der Datei ~/mailman/Mailman/mm_cfg.py:

Also z.B.
DEFAULT_URL_HOST = 'www.example.com'
DEFAULT_EMAIL_HOST = 'listen.example.com'
add_virtualhost(DEFAULT_URL_HOST,DEFAULT_EMAIL_HOST)

und
add_virtualhost('www.zoopnet.de', 'lists.zoopnet.de')

Das bedeutet, dass Mailman per default davon ausgeht, dass alle Listen für die Domain example.com sind.
Alle weiteren add_virtualhost-Direktiven ordnen einem Hostnamen für das Webfrontend (z.B. www.zoopnet.de) einen Hostpart für die Adresse der Mailinglisten (z.B. lists.zoopnet.de) zu.

Tip von Raimund Specht: Lässt man den zweiten Parameter weg, also schreibt z.B. add_virtualhost('www.example.org'), dann benutzt Mailman als Hostpart alles was nach dem ersten Punkt steht, hier also example.org als Maildomain.

Prinzipiell war's das. Man muss die Listeneinträge natürlich immer in die richtige virtusertable eintragen, und für gleichnamige Mailinglisten auf verschiedenen Domains (mailman@*) verschidene +Ergänzungen bzw. aliase verwenden. :)

=== Probleme ===

Verschiedene Listen mit gleichem Namen (also z.B. liste@example1.com und liste@example2.com) sind mit Mailman 2.1 leider nicht möglich.

== Tips und Tricks ==

=== URL Änderungen ===
Nach URL Änderungen stimmen Links im Web-Interface nicht mehr und Listen werden nicht mehr angezeigt.
Es sind dann, zusätzlich zur Anpassung der mm_cfg.py, schon bestehende Listen und Archive mit folgendem Befehl zu aktualisieren:
~/mailman/bin/withlist -l -r fix_url <Listen_Name> -v -u <Neue_Url>
<Listen_Name> steht für die Mailingliste, die bearbeitet werden soll. <Neue_Url> für die neue URL/Webadresse des Webinterfaces.

=== Weitere Cron-Jobs zur Mailinglisten Verwaltung ===

Folgende Cronjobs helfen bei der Verwaltung und sind User freundlich:

< In Arbeit >

== Referenzen ==

Lösung zur installation als Domainadmin (xyz00-listen) statt Paketadmin (xyz00): https://lists.hostsharing.net/archiv/support/2009-June/019414.html<br>

Ältere Anleitung für Installation als Domain-Admin (xyz00-listen): <http://lists.hostsharing.net/archiv/support/2005-January/012426.html><br>

"Kleine Tools" auf http://hs.andreasloesch.de/, wobei das 'pac-mm-install' wahrscheinlich nicht aktuell (genug) ist<br>

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

Diskussion:Zonefile

2021-03-20T10:26:17Z

Deg00-m.website: Neuer Abschnitt /* Zonefile für Mailinglisten */

== Zonefile für Mailinglisten ==

Wer Schwierigkeiten hat, Mailinglisten bei Google einzuliefern (landet immer in Spam), hier ist ein angepasstes Zonefile, wie es für die Gambas Mailingliste funktioniert.

Die Google site verification kriegt man in der Google Search Console.

In '~/doms/example.com/etc/pri.example.com'

{DEFAULT_ZONEFILE}
@ IN TXT "google-site-verification=xyzxyzxyzxyzxyzxyzxyzxyzxyzxyzxyzxyzxyzxyzxyz"
@ IN TXT "v=spf1 a mx include:spf.hostsharing.net ~all"

HsadminWeb

2021-01-24T09:06:05Z

Deg00-m.website:

{{Löschkandidat}}

= HSAdmin =

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

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

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

== Kunde/Mitglied ==

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

Dieser Bereich ist nur für den Mitgliedsaccount sichtbar (Drei-Buchstaben-Login)

== Web-Paket ==

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

Dieser Bereich ist nur für den Mitgliedsaccount und den Paketadministrator sichtbar. Der Paketadministrator sieht jeweils nur sein eigenes Paket.

== Domain ==

Die Domains zur Verwaltung von E-Mail Adressen

Benutzer ohne Rolle "Domain-Administrator" können lediglich über den
Link oben rechts, der mit der Nutzerkennung beschriftet ist, ihr Passwort ändern.

Hsadmin

2021-01-24T09:05:10Z

Deg00-m.website: Kerndoku Link

{{Kerndoku|https://doc.hostsharing.net/einstieg/index.html}}

Am 25. Juli 2016 wurde eine neue Web-Oberfläche in Betrieb genommen.

Eine Einführung in die Bedienung findet Ihr auf der Seite [[HsadminWeb]]

---
[[Kategorie:Glossar]]