https://wiki.hostsharing.net/api.php?action=feedcontributions&feedformat=atom&user=Apc00-tonyHostsharing Wiki - Benutzerbeiträge [de]2026-04-25T21:11:28ZBenutzerbeiträgeMediaWiki 1.43.8https://wiki.hostsharing.net/index.php?title=Traffic&diff=7319Traffic2025-03-24T13:21:48Z<p>Apc00-tony: /* Viel Traffic durch Login-Versuche auf Wordpress-Seiten */ Tippfehler behoben. Für den Fall, daß jemand cuttet und pästet.</p>
<hr />
<div>Als Traffic bezeichnet man Datenverkehr zwischen zwei Computersystemen.<br />
<br />
Dies beinhaltet [[Logging#HTTP-Traffic|Web]], [[Logging#Mail-Traffic|Mail]] und [[Logging#FTP-Traffic|FTP]] Verbindungen.<br />
<br />
==Traffic Ursachen erkennen==<br />
<br />
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:<br />
<br />
Als erstes einfach mal den Log ansehen und durchscrollen.<br />
<br />
<syntaxhighlight lang=shell><br />
less ~/var/web.log<br />
less ~/var/web.log-yesterday<br />
</syntaxhighlight><br />
<br />
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.<br />
<br />
==Webzugriffe analysieren==<br />
<br />
Diese Idee von Michael Hierweck: Wie bekomme ich heraus, welche Web-Zugriffe für mein Traffic-Volumen<br />
maßgeblich verantwortlich sind?<br />
<br />
<syntaxhighlight lang=shell line><br />
cat $HOME/var/web.log |cut -d ' ' -f11 | grep -o '[0-9]*' | sort -n |uniq -c |sed -e's/^ *//' \<br />
|while read FACTOR SUM; do<br />
echo "$((${FACTOR} * ${SUM})) ${FACTOR} ${SUM}";<br />
done |sort -n<br />
</syntaxhighlight><br />
* Zeile 1: Traffic aus dem Log extrahieren, sortieren, zählen.<br />
* Zeile 2: über die Einträge wandern<br />
* Zeile 3: Produkt aus Zugriffen und Einzelvolumen berechnen<br />
* Zeile 4: Ausgabe von Produkt, Zugriffen und Einzelvolume je Zugriff<br />
* Zeile 5: sortieren<br />
<br />
Das Ganze als Einzeiler zum Kopieren, Einfügen und Ausführen im Terminal:<br />
<syntaxhighlight lang=shell><br />
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<br />
</syntaxhighlight><br />
<br />
Dieser Skript gibt den Traffic aus, den gleichförmige Einzelzugriffe generieren, die größten Brocken stehen unten. Z.B.:<br />
<br />
<syntaxhighlight lang=output line><br />
219558 6 36593<br />
232288 14 16592<br />
239998 22 10909<br />
270812 2 135406<br />
304520 5 60904<br />
318248 14 22732<br />
559062 14 39933<br />
602760 20 30138<br />
711496 8 88937<br />
2325929 101 23029<br />
2351668 29 81092<br />
</syntaxhighlight><br />
<br />
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:<br />
<br />
<syntaxhighlight lang=shell><br />
grep 81092 $HOME/var/web.log | less<br />
</syntaxhighlight><br />
<br />
=== Wenn ich dieses Script öfter brauche ... ===<br />
<br />
lohnt es sich, daraus ein kleines Programm zu machen.<br />
Dazu einfach<br />
<br />
* Texteditor Eurer Wahl öffnen<br />
* Script-Text hier kopieren und in den Editor einfügen<br />
Hier noch mal eine etwas erweiterte Version<br />
<syntaxhighlight lang=shell line><br />
#!/bin/bash<br />
echo ---------------------------------------------------------------<br />
echo ------------- Top 10 Traffic_Verusacher heute -----------------<br />
echo ---------------------------------------------------------------<br />
echo Gesamtvolumen, Zugriffe, Einzelvolumen<br />
cat $HOME/var/web.log |cut -d ' ' -f11 | grep -o '[0-9]*' | sort -n |uniq -c |sed -e's/^ *//' \<br />
|while read FACTOR SUM; do<br />
echo "$((${FACTOR} * ${SUM})) ${FACTOR} ${SUM}";<br />
done |sort -n -r|head -10<br />
<br />
echo <br />
echo ---------------------------------------------------------------<br />
echo ------------- Top 10 Traffic_Verusacher gestern ---------------<br />
echo ---------------------------------------------------------------<br />
echo <br />
echo Gesamtvolumen, Zugriffe, Einzelvolumen<br />
cat $HOME/var/web.log-yesterday |cut -d ' ' -f11 | grep -o '[0-9]*' | sort -n |uniq -c |sed -e's/^ *//' \<br />
|while read FACTOR SUM; do<br />
echo "$((${FACTOR} * ${SUM})) ${FACTOR} ${SUM}";<br />
done |sort -n -r|head -10<br />
echo<br />
echo Sie koennen nun nach dem Versacher suchen, indem sie die <br />
echo Logfiles des Tages nach dem Einzelvolumen durchsuchen<br />
echo 'Befehl: grep 81092 $HOME/var/web.log | less'<br />
</syntaxhighlight><br />
* Script als Datei ohne Erweiterung unter einem griffigen Namen wie "volumenauswertung" speichern<br />
* Scriptdatei in das Home-Verzeichnis des Paket-Users auf dem Server laden.<br />
* 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) <br />
<br />
Nun kann man dieses Script jederzeit mit ./volumenauswertung starten.<br />
<br />
== Wie erkenne ich, welche Webseite gestern am meisten Traffic Volumen hatte? ==<br />
<br />
Dieser Einzeiler sollte es zeigen (Datum entsprechend ändern):<br />
<br />
<syntaxhighlight lang=shell><br />
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<br />
</syntaxhighlight><br />
<br />
== Wie bekomme ich IPs mit massenhaften Web-Zugriffen erkannt und gesperrt? ==<br />
<br />
IPs mit mehrstelligen Zugriffen werden so gefunden (Hier alle IPs mit vierstelligen Zugriffen, beachte die Ziffer 4 im Ausdruck "egrep '^[0-9]{4,} .*$'"):<br />
<syntaxhighlight lang=shell><br />
cat ${HOME}/var/web.log |cut -d ' ' -f2 | sort | uniq -c |sed -e's/^ *//' | egrep '^[0-9]{4,} .*$'<br />
</syntaxhighlight><br />
Als Paketadmin alle IPs mit 10.000 und mehr Web-Zugriffen aus dem<br />
heutigen Log filtern und dafür Sperreinträge erzeugen, die man in die<br />
.htaccess kopieren kann:<br />
<br />
<syntaxhighlight lang=shell line><br />
cat ${HOME}/var/web.log |cut -d ' ' -f2 |sort |uniq -c \<br />
|sed -e's/^ *//' | egrep '^[0-9]{5,} .*$' |cut -d ' ' -f 2 \<br />
|xargs -n1 -r -I XXX echo "deny from XXX"<br />
</syntaxhighlight><br />
<br />
* Zeile 1: Log auswerten und IPs extrahieren und zählen<br />
* 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.<br />
* Zeile 3: Einträge erzeugen<br />
<br />
== Troubleshooting ==<br />
=== Viel Traffic durch Login-Versuche auf Wordpress-Seiten ===<br />
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.<br />
<br />
<syntaxhighlight lang=shell><br />
cd /home/pacs/<xyz00>/users/<user>/doms/<domain><br />
vi .htaccess<br />
</syntaxhighlight><br />
<br />
Wir geben zur Datei ''.htaccess'' den folgenden Inhalt hinzu.<br />
<br />
<syntaxhighlight lang=shell><br />
<Files wp-login.php><br />
AuthName "Protect against silly robots, User username, Pw s3cr3t"<br />
AuthType Basic<br />
AuthUserFile /home/pacs/<xyz00>/users/<user>/doms/<domain>/.htpasswd<br />
Require valid-user<br />
</Files> <br />
</syntaxhighlight><br />
<br />
Wir generieren den Hash für das Passwort ''s3cr3t'' für den Benutzer ''username'' mit dem ''htpasswd'' Tool auf folgende Weise.<br />
<br />
<syntaxhighlight lang=shell><br />
cd /home/pacs/<xyz00>/users/<user>/doms/<domain><br />
htpasswd -b -c .htpasswd username s3cr3t<br />
</syntaxhighlight><br />
<br />
Falls das Benutzer-Formular der Wordpress-Instanz im Browser über die Adresse ''<domain>/wp-login.php'' erreichbar ist, werden wir in Zukunft als Erstes von Apache und als Zweites von Wordpress nach Benutzer und Passwort gefragt.<br />
<br />
[[Kategorie:HSDoku]]<br />
[[Kategorie:Glossar]]<br />
[[Kategorie:Traffic]]<br />
[[Kategorie:WebStatistik]]</div>Apc00-tonyhttps://wiki.hostsharing.net/index.php?title=Diskussion:Mlmmj&diff=7201Diskussion:Mlmmj2025-01-03T12:17:33Z<p>Apc00-tony: /* Mlmmj und DKIM */ Added explanation of script</p>
<hr />
<div>= Mlmmj und DKIM =<br />
<br />
Testweise habe ich E-Mail so geändert, dass sie "sauber" von Listenserver als Absender kommen und an den Empfänger gehen.<br />
<br />
Ein Skript zum Umschreiben des From:-Header:<br />
<br />
$ cat bin/receive-message <br />
#!/bin/bash<br />
sed -e "s/^From:\([^<]*\)<.*/From:\1<$1@hs-example.de>/"|/usr/bin/mlmmj-recieve -L /home/pacs/xyz00/users/lists/mlmmj/$1/<br />
<br />
Damit wird vor der Übergabe an Mlmmj die From:-Zeile einer eingehenden Listenmail so umgeschrieben, daß der Realname erhalten bleibt und die Adresse mit der des Verteilers ersetzt wird – also bspw. von <code><nowiki>From: "Hinz Kunz" <hinzkunz@example.com></nowiki></code> in <code><nowiki>From: "Hinz Kunz" <meinverteiler@hs-example.de></nowiki></code>. (Der Name des Verteilers ergibt sich aus dem Parameter $1: siehe den Aufruf von receive-message in der .procmailrc unten.)<br />
<br />
.forward und .procmailrc:<br />
<br />
$ cat .forward <br />
"|/usr/bin/procmail -p"<br />
<br />
$ cat .procmailrc <br />
SHELL=/bin/sh<br />
HOMEDIR=/home/pacs/xyz00/users/lists<br />
MAILDIR=/home/pacs/xyz00/users/lists/Maildir<br />
PMDIR=/home/pacs/xyz00/users/lists<br />
VERBOSE=yes<br />
LOGFILE=/home/pacs/xyz00/users/lists/var/procmail.log<br />
DEFAULT<br />
<br />
:0:<br />
* ^X-Original-To: ()\/[^@+]+<br />
|/home/pacs/xyz00/users/lists/bin/receive-message ${MATCH}<br />
<br />
:0<br />
{ EXITCODE 67 }<br />
<br />
Im "control"-Ordner sorge ich dafür, dass der To:-Header, die Message-ID und die DKIM-Signatur gelöscht werden:<br />
<br />
$ cat delheaders <br />
DKIM-Signature:<br />
To:<br />
Message-ID:<br />
<br />
$ touch addtohdr<br />
<br />
Das Flag "addtohdr" sorgt dafür, dass mlmmj einen To:-Header an den endgültigen Empfänger der E-Mail einfügt.</div>Apc00-tonyhttps://wiki.hostsharing.net/index.php?title=Vorlage:Veraltet&diff=7143Vorlage:Veraltet2024-12-03T11:57:15Z<p>Apc00-tony: Änderung 7142 von Apc00-tony (Diskussion) rückgängig gemacht.</p>
<hr />
<div><noinclude><br />
== Verwendung ==<br />
<br />
Um eine Seite als veraltet zu kennzeichnen, gib einfach am Anfang der Seite folgendes ein:<br />
<br />
<nowiki>{{Veraltet}}</nowiki><br />
<br />
Dadurch erscheint folgender Hinweis am Anfang der Seite; außerdem wird die Seite automatisch in die Kategorie "Baustelle" aufgenommen:<br />
</noinclude><br />
{{Textkasten|rot|Veraltet|Der Grund steht in der [[{{TALKPAGENAME}}|Diskussionsseite]]}}<br />
<br />
<br />
<includeonly>[[Kategorie:Baustelle]]</includeonly><noinclude><br />
<br />
<br />
[[Kategorie:Textkasten]]<br />
<br />
</noinclude></div>Apc00-tonyhttps://wiki.hostsharing.net/index.php?title=Vorlage:Veraltet&diff=7142Vorlage:Veraltet2024-12-03T11:56:53Z<p>Apc00-tony: </p>
<hr />
<div><noinclude><br />
== Verwendung ==<br />
<br />
Um eine Seite als veraltet zu kennzeichnen, gib einfach am Anfang der Seite folgendes ein:<br />
<br />
<nowiki>{{Veraltet}}</nowiki><br />
<br />
Dadurch erscheint folgender Hinweis am Anfang der Seite; außerdem wird die Seite automatisch in die Kategorie "Baustelle" aufgenommen:<br />
</noinclude><br />
{{Textkasten|rot|Veraltet|Der Grund steht in der [[{{TALKPAGENAME}}|Diskussionsseite]].}}<br />
<br />
<br />
<includeonly>[[Kategorie:Baustelle]]</includeonly><noinclude><br />
<br />
<br />
[[Kategorie:Textkasten]]<br />
<br />
</noinclude></div>Apc00-tonyhttps://wiki.hostsharing.net/index.php?title=Cron&diff=7141Cron2024-12-03T11:49:59Z<p>Apc00-tony: Zeichensetzung</p>
<hr />
<div>Cron wird ersetzt durch [[Prozessmanagement mit systemd im Userspace#Zeitgesteuerte_Ausführung_mit_systemd|Systemd Timer]].<br />
<br />
{{Veraltet}}<br />
{{Löschkandidat}}<br />
<br />
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.<br />
=== Crontab ===<br />
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.<br />
<br />
Anzeigen der aktuellen Konfiguration:<br />
<syntaxhighlight lang=shell><br />
crontab -l<br />
</syntaxhighlight><br />
Löschen der kompletten Konfiguration:<br />
<syntaxhighlight lang=shell><br />
crontab -r<br />
</syntaxhighlight><br />
Ändern der Konfiguration:<br />
<syntaxhighlight lang=shell><br />
crontab -e<br />
</syntaxhighlight><br />
Crontab von einer Datei starten:<br />
<syntaxhighlight lang=shell><br />
crontab myjob<br />
</syntaxhighlight><br />
Der beim Editieren verwendete Editor wird durch die Umgebungsvariablen EDITOR und VISUAL bestimmt. Der Default ist vi. Alternativ kann man folgenden Weg gehen:<br />
<syntaxhighlight lang=shell><br />
xyz00@hopi:~$crontab -l > myjobs<br />
</syntaxhighlight><br />
Dann die Datei myjobs mit einem beliebigen Editor anpassen. Anschließend den cronjob von der Datei myjobs starten und die Datei löschen:<br />
<syntaxhighlight lang=shell><br />
xyz00@hopi:~$ crontab myjobs<br />
<br />
xyz00@hopi:~$ rm myjobs<br />
</syntaxhighlight><br />
=== Dateiformat ===<br />
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:<br />
<syntaxhighlight lang=shell><br />
* Minute (0-59)<br />
* Stunde (0-23)<br />
* Tag des Monats (1-31)<br />
* Monat (1-12 oder JAN-DEC)<br />
* Wochentag (0-7; 0 und 7 entsprechen jeweils Sonntag oder SUN-SAT) <br />
</syntaxhighlight><br />
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).<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Umgebungsvariablen ===<br />
Folgende Umgebungsvariablen können in der crontab-Datei gesetzt werden:<br />
<br />
<syntaxhighlight lang=ini line><br />
PWD<br />
<br />
LOGNAME<br />
<br />
SHLVL<br />
<br />
SHELL<br />
<br />
HOME<br />
<br />
PATH<br />
<br />
MAILTO<br />
</syntaxhighlight><br />
<br />
=== Beispiel ===<br />
<syntaxhighlight lang=shell line><br />
# Alle Meldungen per Mail an diesen User schicken<br />
MAILTO=xyz00<br />
<br />
# bei einem Neustart des Servers soll der Monit Dienst gestartet werden<br />
@reboot rm -f $HOME/var/run/* && /usr/bin/monit -c "$HOME/.monitrc"<br />
<br />
# Fuenf Minuten nach Mitternacht<br />
5 0 * * * $HOME/bin/daily.job >> $HOME/tmp/out 2>&1<br />
<br />
# Um 14:15 an jedem Monatsersten<br />
15 14 1 * * $HOME/bin/monthly<br />
<br />
# 0:23, 2:23, 4:23, 6:23 ... 22:23<br />
23 0-23/2 * * * echo "run 23 minutes after midn, 2am, 4am ..., everyday"<br />
<br />
# Jeden Sonntag um 4:05<br />
5 4 * * sun echo "run at 5 after 4 every sunday"<br />
<br />
# Jeden Freitag und jeden 1. des Monats um 4:05<br />
5 4 1 * 5 echo "run at 5 after 4 every friday and every 1st"<br />
</syntaxhighlight><br />
Eine vollständige Beschreibung ist in der Manpage vorhanden: man 5 crontab.<br />
<br />
=== Performancehinweise ===<br />
<br />
Da Cronjobs einen erheblichen Teil der Systemlast ausmachen, sollen die folgenden Grundregeln beachtet werden:<br />
<br />
* Jobs wenn möglich über Nacht laufen lassen.<br />
* Priorität des Jobs mit nice reduzieren.<br />
* Glatte Minutenwerte (0,5,10,15,20,...) vermeiden. Statt */10 kann man auch 7-57/10 verwenden. <br />
<br />
=== Fehlerquellen ===<br />
<br />
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.<br />
<br />
Login-Shell: /usr/local/bin/su wird zuerst gefunden.<br />
<br />
cron: /bin/su wird zuerst gefunden.<br />
<br />
Wenn Cronjobs nicht ausgeführt werden, dann befinden sich die aufgerufenen Programme häufig auch in anderen Verzeichnissen.<br />
<br />
----<br />
[[Kategorie:HSDoku]]<br />
[[Kategorie:Glossar]]</div>Apc00-tonyhttps://wiki.hostsharing.net/index.php?title=Mlmmj&diff=6661Mlmmj2024-05-31T14:34:23Z<p>Apc00-tony: /* Lösung 2 */</p>
<hr />
<div>[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.<br />
<br />
Wer noch nicht weiß, was ein E-Mail-Verteiler machen soll oder wie, lese veilleicht auch den Wikipedia-Artikel:<br />
[http://de.wikipedia.org/wiki/Mailingliste Mailingliste]<br />
<br />
Eine leistungsfähigere Alternative zu mlmmj könnte [[Mailman_3_installieren|Mailman 3]] sein.<br />
<br />
Diese Anleitung beschreibt die Einrichtung einer Mailingliste für eine Domain in einem Hostsharing-Webspace.<br />
<br />
== Voraussetzungen ==<br />
<br />
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.)<br />
<br />
Für den Betrieb der Mailingliste empfiehlt sich das Anlegen eines eigenen Users für diesen Zweck mit hsadmin.<br />
<br />
In dieser Anleitung heißt das Paket ''xyz00'' und der für Mailinglisten eingesetzte User ''xyz00-list''.<br />
<br />
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''.<br />
<br />
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.)<br />
<br />
== Einrichtung ==<br />
<br />
Ich melde mich über SSH auf der Hostsharing-Console als der Paketuser ''xyz00'' an.<br />
<br />
Im Shell kann ich dann durch den Befehl ''hsscript -i'' das Verwaltungswerkzeug [[hsadmin]] interaktiv ausführen:<br />
<br />
xyz00@h03:~$ hsscript -i<br />
Password: *************<br />
xyz00@hsadmin> <br />
<br />
In ''hsadmin'' werden User und E-Mail-Adresse angelegt.<br />
<br />
<syntaxhighlight lang=shell><br />
xyz00@hsadmin> user.add({set:{name:'xyz00-list',comment:'Mailingliste Discuss',shell:'/bin/bash',password:'geheimnis'}})<br />
xyz00@hsadmin> emailaddress.add({set:{target:'xyz00-list',localpart:'discuss',domain:'example.org'}})<br />
xyz00@hsadmin> bye<br />
</syntaxhighlight><br />
<br />
Mit dem Parameter "target" wird die für diese Adresse eingehende Post zunächst in das Postfach des Users xyz00-list abgelegt.<br />
<br />
Für den User xyz00-list lege ich in seinem Heimat-Verzeichnis das Unterverzeichnis <tt>mlmmj</tt> an:<br />
<br />
mkdir /home/pacs/xyz00/users/list/mlmmj<br />
<br />
Dann lege ich die Mailingliste mit folgendem Kommando an:<br />
<br />
mlmmj-make-ml -L discuss -s /home/pacs/xyz00/users/list/mlmmj<br />
<br />
Das Skript ''mlmmj-make-ml'' fragt weitere Parameter der Mailingliste ab:<br />
<br />
The Domain for the List? [] : example.org<br />
The emailaddress of the list owner? [postmaster] : webmaster@example.org<br />
For the list texts you can choose between the following languages or<br />
give an absolute path to a directory containing the texts.<br />
Available languages:<br />
cz da de en es fr it nl ru<br />
The path to texts for the list? [en] : de<br />
<br />
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.<br />
<br />
Weitere Konfigurationen der Liste erfolgen durch das Anlegen von Dateien im<br />
Verzeichnis "/home/pacs/xyz00/users/list/mlmmj/discuss/control".<br />
Die Konfigurationsmöglichkeiten finden Sie auf der [http://mlmmj.org/docs/tunables/ Internetseite von mlmmj].<br />
<br />
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:<br />
<br />
"|/usr/bin/mlmmj-recieve -L /home/pacs/xyz00/users/list/mlmmj/discuss/"<br />
<br />
(Ja, ''receive'' schreibt sich mit ''-ei-'', aber mlmmj hält einen symbolischen Link bereit für diejenigen, die in englischer Rechtschreibung unsicher sind:)<br />
<br />
<syntaxhighlight lang=shell><br />
xyz00-list@h03:~$ ls -la /usr/bin/mlmmj-rec*<br />
-rwxr-xr-x 1 root root 27104 Sep 25 2018 /usr/bin/mlmmj-receive<br />
lrwxrwxrwx 1 root root 13 Sep 25 2018 /usr/bin/mlmmj-recieve -> mlmmj-receive<br />
</syntaxhighlight><br />
<br />
Die <tt>.forward</tt>-Datei sorgt dafür, dass eingehende E-Mails an das User-Postfach an das Programm ''mlmmj-recieve'' übergeben werden.<br />
<br />
Für regelmäßige Aufgaben der Listen-Managers definiere ich die<br />
[[Cron|crontab]] wie folgt (immer noch als ''xyz00-list''):<br />
<br />
xyz00-list@h03:~$ crontab -e<br />
<br />
<syntaxhighlight lang=shell line><br />
MAILTO=webmaster@example.org<br />
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin<br />
HOME=/home/pacs/xyz00/users/list<br />
SHELL=/bin/bash<br />
LANG=en_US.UTF-8<br />
# m h dom mon dow command<br />
28 */4 * * * /usr/bin/mlmmj-maintd -d /home/pacs/xyz00/users/list/mlmmj -F<br />
</syntaxhighlight><br />
<br />
Zum Schluss rufe ich das Skript mlmmj-sub auf, um die E-Mail-Adressen der gewünschten Abonnenten des Verteilers einzutragen:<br />
<br />
/usr/bin/mlmmj-sub -L /home/pacs/xyz00/users/list/mlmmj/discuss -a klaus.muster@gmx.de -c <br />
/usr/bin/mlmmj-sub -L /home/pacs/xyz00/users/list/mlmmj/discuss -a sabine.beispiel@arcor.de -c <br />
<br />
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.<br />
<br />
== weitere Optionen ==<br />
<br />
Noch ein paar Dinge, die Sie möglicherweise einstellen wollen:<br />
<br />
Ein Prefix in der Betreffzeile setzen, z.B.: "[discuss]".<br />
<br />
echo "[discuss]" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/prefix<br />
<br />
Wenn die Liste nur E-Mails von eingetragenen Abonnenten weiterleiten soll:<br />
<br />
touch /home/pacs/xyz00/users/list/mlmmj/discuss/control/subonlypost<br />
<br />
Damit der Listen-Owner weitere Abonnements bestätigen muss:<br />
<br />
touch /home/pacs/xyz00/users/list/mlmmj/discuss/control/submod<br />
<br />
Einen "Reply-To:"-Header setzen, damit Antwort-Mails standardmäßig an die Mailing-Liste gehen:<br />
<br />
echo "Reply-To:" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/delheaders<br />
echo "Reply-To: discuss@example.org" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/customheaders<br />
<br />
Weitere Möglichkeiten finden Sie (wie oben bereits angegeben) <br />
auf der [http://mlmmj.org/docs/tunables/ Internetseite von mlmmj].<br />
<br />
=== Achtung: DKIM ===<br />
<br />
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:''.<br />
<br />
Wird zum Beispiel mit einem Prefix das Subject geändert oder ein Footer angehängt, macht dies die DKIM-Signatur ungültig. Das ist für viele Mailprovider ein Grund die Nachricht abzuweisen.<br />
<br />
== Zur Konfiguration im Browser ==<br />
<br />
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.<br />
<br />
Wer es sich ansehen möchte:<br />
<br />
Als Paket-Admin eine Domain aufschalten:<br />
<syntaxhighlight lang=shell><br />
hsscript -u xyz00 -e "domain.add({set:{name:'lists.example.org',user:'xyz00-list'}})"<br />
</syntaxhighlight><br />
Und weiter als "xyz00-list".<br />
<br />
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).<br />
<br />
Unter "/mlmmj-$versionsnummer/contrib/web/php-admin/", oder beim .deb-Paket unter "usr/share/mlmmj-...", findet sich die PHP-Admin-Anwendung. Also ...<br />
<br />
* den Inhalt diese Verzeichnisses nach "/home/pacs/xyz00/users/list/doms/lists.example.org/" packen;<br />
* in "/home/pacs/xyz00/users/list/doms/lists.example.org/conf/config.php" die Variable "$topdir" anpassen;<br />
* 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;<br />
* Beim .deb-Paket die config.php, die templates/ und die tunables.pl aus etc/ nach example.org/conf/ verschieben;<br />
* 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: <br />
<syntaxhighlight lang=apache line><br />
Require valid-user<br />
AuthType Basic<br />
AuthName "mlmmj web-interface"<br />
AuthUserFile /home/pacs/xyz00/users/list/doms/lists.example.org/etc/htpasswd<br />
</syntaxhighlight><br />
* Und schließlich die "htpasswd"-Datei anlegen.<br />
<br />
cd /home/pacs/xyz00/users/list/doms/lists.example.org/etc/<br />
htpasswd -c htpasswd listadmin<br />
<br />
* Ein Passwort angeben.<br />
<br />
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<br />
<br />
* in <tt>.../htdocs-ssl/index.php</tt> folgende Änderung vornehmen:<br />
<syntaxhighlight lang=diff line><br />
@@ -38,4 +38,5 @@<br />
# use scandir to have alphabetical order <br />
foreach (scandir($topdir) as $file) {<br />
- if (!ereg("^\.",$file))<br />
+# ereg obsolete!! Vormals: if (!ereg("^\.",$file))<br />
+ if (!preg_match('/^\./',$file))<br />
{<br />
</syntaxhighlight><br />
und das Ergebnis auf https://lists.example.org anschauen.<br />
<br />
== Mehrere Mailinglisten betreiben ==<br />
<br />
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.<br />
<br />
Dazu trägt man in der Datei <tt>.forward</tt> statt des Aufrufs von ''mlmmj-recieve'' einen Aufruf von ''procmail'' ein:<br />
<br />
<br />
|/usr/bin/procmail<br />
<br />
Die Konfiguration von Procmail kann generisch erfolgen. Dazu legt man eine Datei <tt>.procmailrc</tt> mit folgendem Inhalt ins $HOME des Users:<br />
<br />
SHELL=/bin/sh<br />
HOMEDIR=/home/pacs/xyz00/users/list<br />
MAILDIR=/home/pacs/xyz00/users/list/Maildir<br />
PMDIR=/home/pacs/xyz00/users/list<br />
VERBOSE=yes<br />
LOGFILE=/home/pacs/xyz00/users/list/var/procmail.log<br />
DEFAULT<br />
<br />
:0:<br />
* ^X-Original-To: ()\/[^@+]+<br />
|/usr/bin/mlmmj-receive -F -L /home/pacs/xyz00/users/list/mlmmj/${MATCH}/<br />
<br />
:0<br />
{ EXITCODE 67 }<br />
<br />
Bitte dafür sorgen, dass das Verzeichnis ''/home/pacs/xyz00/users/list/var'' existiert.<br />
<br />
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.<br />
<br />
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).<br />
<br />
===Groß- und Kleinschreibung===<br />
<br />
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.<br />
<br />
====Lösung 1====<br />
<br />
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:<br />
<br />
:0:<br />
* ^X-Original-To: ()\/[^@+]+<br />
|/usr/bin/mlmmj-receive -F -L /home/pacs/xyz00/users/list/mlmmj/$(echo ${MATCH} | tr [:upper:] [:lower:])/<br />
<br />
Der Rest der Datei muß gleich bleiben, wie weiter oben angezeigt.<br />
<br />
In diesem Fall müssen aber alle Mailing-Listen ohne Großbuchstaben im Namen angelegt werden!<br />
<br />
(Man kann auch in <tt>${HOME}/mlmmj/</tt> durch kleingeschriebene Symlinks großgeschriebene Listennamen ansprechbar machen:<br />
<br />
xyz00-list@h02:~$ ls -lA mlmmj/<br />
total 8<br />
-rw-r--r-- 1 xyz00-list xyz00 148 Feb 1 16:56 .htaccess<br />
lrwxrwxrwx 1 xyz00-list xyz00 10 Feb 2 18:01 mitglieder -> Mitglieder<br />
drwxr-xr-x 15 xyz00-list xyz00 4096 Feb 2 16:53 Mitglieder<br />
<br />
====Lösung 2====<br />
<br />
Bash kann bei der Auflösung von Variablen die Groß- und Kleinschreibung manipulieren. (Siehe dazu bei der Zeichenfolge <tt>,,</tt> in <tt>man bash</tt>.) Dann ist <tt>$(echo ${MATCH} | tr [:upper:] [:lower:])</tt> gleichbedeutend mit <tt>${MATCH,,}</tt>. Allerdings braucht procmail einige Überredung, um Bash zu verwenden.<br />
<br />
SHELL=/bin/bash<br />
SHELLMETAS=&|<>~;?*[{<br />
HOMEDIR= ...<br />
<br />
...<br />
<br />
:0:<br />
* ^X-Original-To: ()\/[^@+]+<br />
|/usr/bin/mlmmj-receive -F -L /home/pacs/xyz00/users/list/mlmmj/${MATCH,,}/<br />
<br />
Die Tücke ist, daß procmail den in SHELL angegebenen Shell nur dann verwendet, wenn die Befehlszeile eines der in SHELLMETAS angegebenen Zeichen enthält. Und das '|' am Anfang der Zeile zählt dabei nicht! In diesem Beispiel ist es das Zeichen <tt>{</tt>, das den Einsatz von Bash auslöst.<br />
<br />
Beide Lösungen scheinen zu funktionieren; Angabe ohne Gewähr.<br />
<br />
== Links ==<br />
<br />
* http://mlmmj.org/ Projektseite<br />
* https://codeberg.org/mlmmj mlmmj auf Codeberg<br />
* https://github.com/tchapi/mlmmj-simple-web-interface ein Admin-Interface in NodeJS<br />
* [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<br />
* [https://gist.github.com/kboss/7c9593f0fd9219406226c4f11256b98a Einfaches Python-Script zum Massenimport aus einem Texfile.] Geht bestimmt auch eleganter mit purem Bash<br />
* Ein Self-Service zum Subscriben/Unsubscriben lässt sich in Form von Mail-to-Links in Webseiten einbinden. Beispiele gibt es bei Hostsharing für die öffentlichen "public"-Mailinglisten: https://www.hostsharing.net/lists/public-discussion/ . Alternativ auf https://github.com/hblasum/mlmmj-php-web-simplified ein Webfrontend mit dem sich Benutzerinnen und Benutzer selbst ein-/austragen können (Vereinfachung von mlmmj-php-web von Christoph Thiel).<br />
<br />
----<br />
[[Kategorie:HSDoku]]<br />
[[Kategorie:Installationsanleitungen]]<br />
[[Kategorie:Software]]<br />
[[Kategorie:Mailinglisten]]<br />
[[Kategorie:E-Mail]]</div>Apc00-tonyhttps://wiki.hostsharing.net/index.php?title=Mlmmj&diff=6660Mlmmj2024-05-31T14:33:40Z<p>Apc00-tony: /* Lösung 2 */</p>
<hr />
<div>[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.<br />
<br />
Wer noch nicht weiß, was ein E-Mail-Verteiler machen soll oder wie, lese veilleicht auch den Wikipedia-Artikel:<br />
[http://de.wikipedia.org/wiki/Mailingliste Mailingliste]<br />
<br />
Eine leistungsfähigere Alternative zu mlmmj könnte [[Mailman_3_installieren|Mailman 3]] sein.<br />
<br />
Diese Anleitung beschreibt die Einrichtung einer Mailingliste für eine Domain in einem Hostsharing-Webspace.<br />
<br />
== Voraussetzungen ==<br />
<br />
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.)<br />
<br />
Für den Betrieb der Mailingliste empfiehlt sich das Anlegen eines eigenen Users für diesen Zweck mit hsadmin.<br />
<br />
In dieser Anleitung heißt das Paket ''xyz00'' und der für Mailinglisten eingesetzte User ''xyz00-list''.<br />
<br />
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''.<br />
<br />
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.)<br />
<br />
== Einrichtung ==<br />
<br />
Ich melde mich über SSH auf der Hostsharing-Console als der Paketuser ''xyz00'' an.<br />
<br />
Im Shell kann ich dann durch den Befehl ''hsscript -i'' das Verwaltungswerkzeug [[hsadmin]] interaktiv ausführen:<br />
<br />
xyz00@h03:~$ hsscript -i<br />
Password: *************<br />
xyz00@hsadmin> <br />
<br />
In ''hsadmin'' werden User und E-Mail-Adresse angelegt.<br />
<br />
<syntaxhighlight lang=shell><br />
xyz00@hsadmin> user.add({set:{name:'xyz00-list',comment:'Mailingliste Discuss',shell:'/bin/bash',password:'geheimnis'}})<br />
xyz00@hsadmin> emailaddress.add({set:{target:'xyz00-list',localpart:'discuss',domain:'example.org'}})<br />
xyz00@hsadmin> bye<br />
</syntaxhighlight><br />
<br />
Mit dem Parameter "target" wird die für diese Adresse eingehende Post zunächst in das Postfach des Users xyz00-list abgelegt.<br />
<br />
Für den User xyz00-list lege ich in seinem Heimat-Verzeichnis das Unterverzeichnis <tt>mlmmj</tt> an:<br />
<br />
mkdir /home/pacs/xyz00/users/list/mlmmj<br />
<br />
Dann lege ich die Mailingliste mit folgendem Kommando an:<br />
<br />
mlmmj-make-ml -L discuss -s /home/pacs/xyz00/users/list/mlmmj<br />
<br />
Das Skript ''mlmmj-make-ml'' fragt weitere Parameter der Mailingliste ab:<br />
<br />
The Domain for the List? [] : example.org<br />
The emailaddress of the list owner? [postmaster] : webmaster@example.org<br />
For the list texts you can choose between the following languages or<br />
give an absolute path to a directory containing the texts.<br />
Available languages:<br />
cz da de en es fr it nl ru<br />
The path to texts for the list? [en] : de<br />
<br />
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.<br />
<br />
Weitere Konfigurationen der Liste erfolgen durch das Anlegen von Dateien im<br />
Verzeichnis "/home/pacs/xyz00/users/list/mlmmj/discuss/control".<br />
Die Konfigurationsmöglichkeiten finden Sie auf der [http://mlmmj.org/docs/tunables/ Internetseite von mlmmj].<br />
<br />
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:<br />
<br />
"|/usr/bin/mlmmj-recieve -L /home/pacs/xyz00/users/list/mlmmj/discuss/"<br />
<br />
(Ja, ''receive'' schreibt sich mit ''-ei-'', aber mlmmj hält einen symbolischen Link bereit für diejenigen, die in englischer Rechtschreibung unsicher sind:)<br />
<br />
<syntaxhighlight lang=shell><br />
xyz00-list@h03:~$ ls -la /usr/bin/mlmmj-rec*<br />
-rwxr-xr-x 1 root root 27104 Sep 25 2018 /usr/bin/mlmmj-receive<br />
lrwxrwxrwx 1 root root 13 Sep 25 2018 /usr/bin/mlmmj-recieve -> mlmmj-receive<br />
</syntaxhighlight><br />
<br />
Die <tt>.forward</tt>-Datei sorgt dafür, dass eingehende E-Mails an das User-Postfach an das Programm ''mlmmj-recieve'' übergeben werden.<br />
<br />
Für regelmäßige Aufgaben der Listen-Managers definiere ich die<br />
[[Cron|crontab]] wie folgt (immer noch als ''xyz00-list''):<br />
<br />
xyz00-list@h03:~$ crontab -e<br />
<br />
<syntaxhighlight lang=shell line><br />
MAILTO=webmaster@example.org<br />
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin<br />
HOME=/home/pacs/xyz00/users/list<br />
SHELL=/bin/bash<br />
LANG=en_US.UTF-8<br />
# m h dom mon dow command<br />
28 */4 * * * /usr/bin/mlmmj-maintd -d /home/pacs/xyz00/users/list/mlmmj -F<br />
</syntaxhighlight><br />
<br />
Zum Schluss rufe ich das Skript mlmmj-sub auf, um die E-Mail-Adressen der gewünschten Abonnenten des Verteilers einzutragen:<br />
<br />
/usr/bin/mlmmj-sub -L /home/pacs/xyz00/users/list/mlmmj/discuss -a klaus.muster@gmx.de -c <br />
/usr/bin/mlmmj-sub -L /home/pacs/xyz00/users/list/mlmmj/discuss -a sabine.beispiel@arcor.de -c <br />
<br />
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.<br />
<br />
== weitere Optionen ==<br />
<br />
Noch ein paar Dinge, die Sie möglicherweise einstellen wollen:<br />
<br />
Ein Prefix in der Betreffzeile setzen, z.B.: "[discuss]".<br />
<br />
echo "[discuss]" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/prefix<br />
<br />
Wenn die Liste nur E-Mails von eingetragenen Abonnenten weiterleiten soll:<br />
<br />
touch /home/pacs/xyz00/users/list/mlmmj/discuss/control/subonlypost<br />
<br />
Damit der Listen-Owner weitere Abonnements bestätigen muss:<br />
<br />
touch /home/pacs/xyz00/users/list/mlmmj/discuss/control/submod<br />
<br />
Einen "Reply-To:"-Header setzen, damit Antwort-Mails standardmäßig an die Mailing-Liste gehen:<br />
<br />
echo "Reply-To:" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/delheaders<br />
echo "Reply-To: discuss@example.org" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/customheaders<br />
<br />
Weitere Möglichkeiten finden Sie (wie oben bereits angegeben) <br />
auf der [http://mlmmj.org/docs/tunables/ Internetseite von mlmmj].<br />
<br />
=== Achtung: DKIM ===<br />
<br />
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:''.<br />
<br />
Wird zum Beispiel mit einem Prefix das Subject geändert oder ein Footer angehängt, macht dies die DKIM-Signatur ungültig. Das ist für viele Mailprovider ein Grund die Nachricht abzuweisen.<br />
<br />
== Zur Konfiguration im Browser ==<br />
<br />
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.<br />
<br />
Wer es sich ansehen möchte:<br />
<br />
Als Paket-Admin eine Domain aufschalten:<br />
<syntaxhighlight lang=shell><br />
hsscript -u xyz00 -e "domain.add({set:{name:'lists.example.org',user:'xyz00-list'}})"<br />
</syntaxhighlight><br />
Und weiter als "xyz00-list".<br />
<br />
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).<br />
<br />
Unter "/mlmmj-$versionsnummer/contrib/web/php-admin/", oder beim .deb-Paket unter "usr/share/mlmmj-...", findet sich die PHP-Admin-Anwendung. Also ...<br />
<br />
* den Inhalt diese Verzeichnisses nach "/home/pacs/xyz00/users/list/doms/lists.example.org/" packen;<br />
* in "/home/pacs/xyz00/users/list/doms/lists.example.org/conf/config.php" die Variable "$topdir" anpassen;<br />
* 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;<br />
* Beim .deb-Paket die config.php, die templates/ und die tunables.pl aus etc/ nach example.org/conf/ verschieben;<br />
* 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: <br />
<syntaxhighlight lang=apache line><br />
Require valid-user<br />
AuthType Basic<br />
AuthName "mlmmj web-interface"<br />
AuthUserFile /home/pacs/xyz00/users/list/doms/lists.example.org/etc/htpasswd<br />
</syntaxhighlight><br />
* Und schließlich die "htpasswd"-Datei anlegen.<br />
<br />
cd /home/pacs/xyz00/users/list/doms/lists.example.org/etc/<br />
htpasswd -c htpasswd listadmin<br />
<br />
* Ein Passwort angeben.<br />
<br />
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<br />
<br />
* in <tt>.../htdocs-ssl/index.php</tt> folgende Änderung vornehmen:<br />
<syntaxhighlight lang=diff line><br />
@@ -38,4 +38,5 @@<br />
# use scandir to have alphabetical order <br />
foreach (scandir($topdir) as $file) {<br />
- if (!ereg("^\.",$file))<br />
+# ereg obsolete!! Vormals: if (!ereg("^\.",$file))<br />
+ if (!preg_match('/^\./',$file))<br />
{<br />
</syntaxhighlight><br />
und das Ergebnis auf https://lists.example.org anschauen.<br />
<br />
== Mehrere Mailinglisten betreiben ==<br />
<br />
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.<br />
<br />
Dazu trägt man in der Datei <tt>.forward</tt> statt des Aufrufs von ''mlmmj-recieve'' einen Aufruf von ''procmail'' ein:<br />
<br />
<br />
|/usr/bin/procmail<br />
<br />
Die Konfiguration von Procmail kann generisch erfolgen. Dazu legt man eine Datei <tt>.procmailrc</tt> mit folgendem Inhalt ins $HOME des Users:<br />
<br />
SHELL=/bin/sh<br />
HOMEDIR=/home/pacs/xyz00/users/list<br />
MAILDIR=/home/pacs/xyz00/users/list/Maildir<br />
PMDIR=/home/pacs/xyz00/users/list<br />
VERBOSE=yes<br />
LOGFILE=/home/pacs/xyz00/users/list/var/procmail.log<br />
DEFAULT<br />
<br />
:0:<br />
* ^X-Original-To: ()\/[^@+]+<br />
|/usr/bin/mlmmj-receive -F -L /home/pacs/xyz00/users/list/mlmmj/${MATCH}/<br />
<br />
:0<br />
{ EXITCODE 67 }<br />
<br />
Bitte dafür sorgen, dass das Verzeichnis ''/home/pacs/xyz00/users/list/var'' existiert.<br />
<br />
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.<br />
<br />
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).<br />
<br />
===Groß- und Kleinschreibung===<br />
<br />
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.<br />
<br />
====Lösung 1====<br />
<br />
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:<br />
<br />
:0:<br />
* ^X-Original-To: ()\/[^@+]+<br />
|/usr/bin/mlmmj-receive -F -L /home/pacs/xyz00/users/list/mlmmj/$(echo ${MATCH} | tr [:upper:] [:lower:])/<br />
<br />
Der Rest der Datei muß gleich bleiben, wie weiter oben angezeigt.<br />
<br />
In diesem Fall müssen aber alle Mailing-Listen ohne Großbuchstaben im Namen angelegt werden!<br />
<br />
(Man kann auch in <tt>${HOME}/mlmmj/</tt> durch kleingeschriebene Symlinks großgeschriebene Listennamen ansprechbar machen:<br />
<br />
xyz00-list@h02:~$ ls -lA mlmmj/<br />
total 8<br />
-rw-r--r-- 1 xyz00-list xyz00 148 Feb 1 16:56 .htaccess<br />
lrwxrwxrwx 1 xyz00-list xyz00 10 Feb 2 18:01 mitglieder -> Mitglieder<br />
drwxr-xr-x 15 xyz00-list xyz00 4096 Feb 2 16:53 Mitglieder<br />
<br />
====Lösung 2====<br />
<br />
Bash kann bei der Auflösung von Variablen die Groß- und Kleinschreibung manipulieren. (Siehe dazu bei der Zeichenfolge <tt>,,</tt> in <tt>man bash</tt>.) Dann ist <tt>$(echo ${MATCH} | tr [:upper:] [:lower:])</tt> gleichbedeutend mit <tt>${MATCH,,}</tt>. Allerdings braucht procmail einige Überredung, um Bash zu verwenden.<br />
<br />
SHELL=/bin/bash<br />
SHELLMETAS=&|<>~;?*[{<br />
HOMEDIR= ...<br />
<br />
...<br />
<br />
:0:<br />
* ^X-Original-To: ()\/[^@+]+<br />
|/usr/bin/mlmmj-receive -F -L /home/pacs/xyz00/users/list/mlmmj/${MATCH,,}/<br />
<br />
Die Tücke ist, daß procmail den in SHELL angegebenen Shell nur dann verwendet, wenn in der Befehlszeile eines der in SHELLMETAS angegebenen Zeichen enthält. Und das '|' am Anfang der Zeile zählt dabei nicht! In diesem Beispiel ist es das Zeichen <tt>{</tt>, das den Einsatz von Bash auslöst.<br />
<br />
Beide Lösungen scheinen zu funktionieren; Angabe ohne Gewähr.<br />
<br />
== Links ==<br />
<br />
* http://mlmmj.org/ Projektseite<br />
* https://codeberg.org/mlmmj mlmmj auf Codeberg<br />
* https://github.com/tchapi/mlmmj-simple-web-interface ein Admin-Interface in NodeJS<br />
* [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<br />
* [https://gist.github.com/kboss/7c9593f0fd9219406226c4f11256b98a Einfaches Python-Script zum Massenimport aus einem Texfile.] Geht bestimmt auch eleganter mit purem Bash<br />
* Ein Self-Service zum Subscriben/Unsubscriben lässt sich in Form von Mail-to-Links in Webseiten einbinden. Beispiele gibt es bei Hostsharing für die öffentlichen "public"-Mailinglisten: https://www.hostsharing.net/lists/public-discussion/ . Alternativ auf https://github.com/hblasum/mlmmj-php-web-simplified ein Webfrontend mit dem sich Benutzerinnen und Benutzer selbst ein-/austragen können (Vereinfachung von mlmmj-php-web von Christoph Thiel).<br />
<br />
----<br />
[[Kategorie:HSDoku]]<br />
[[Kategorie:Installationsanleitungen]]<br />
[[Kategorie:Software]]<br />
[[Kategorie:Mailinglisten]]<br />
[[Kategorie:E-Mail]]</div>Apc00-tonyhttps://wiki.hostsharing.net/index.php?title=Mlmmj&diff=6659Mlmmj2024-05-31T14:31:13Z<p>Apc00-tony: /* Groß- und Kleinschreibung */</p>
<hr />
<div>[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.<br />
<br />
Wer noch nicht weiß, was ein E-Mail-Verteiler machen soll oder wie, lese veilleicht auch den Wikipedia-Artikel:<br />
[http://de.wikipedia.org/wiki/Mailingliste Mailingliste]<br />
<br />
Eine leistungsfähigere Alternative zu mlmmj könnte [[Mailman_3_installieren|Mailman 3]] sein.<br />
<br />
Diese Anleitung beschreibt die Einrichtung einer Mailingliste für eine Domain in einem Hostsharing-Webspace.<br />
<br />
== Voraussetzungen ==<br />
<br />
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.)<br />
<br />
Für den Betrieb der Mailingliste empfiehlt sich das Anlegen eines eigenen Users für diesen Zweck mit hsadmin.<br />
<br />
In dieser Anleitung heißt das Paket ''xyz00'' und der für Mailinglisten eingesetzte User ''xyz00-list''.<br />
<br />
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''.<br />
<br />
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.)<br />
<br />
== Einrichtung ==<br />
<br />
Ich melde mich über SSH auf der Hostsharing-Console als der Paketuser ''xyz00'' an.<br />
<br />
Im Shell kann ich dann durch den Befehl ''hsscript -i'' das Verwaltungswerkzeug [[hsadmin]] interaktiv ausführen:<br />
<br />
xyz00@h03:~$ hsscript -i<br />
Password: *************<br />
xyz00@hsadmin> <br />
<br />
In ''hsadmin'' werden User und E-Mail-Adresse angelegt.<br />
<br />
<syntaxhighlight lang=shell><br />
xyz00@hsadmin> user.add({set:{name:'xyz00-list',comment:'Mailingliste Discuss',shell:'/bin/bash',password:'geheimnis'}})<br />
xyz00@hsadmin> emailaddress.add({set:{target:'xyz00-list',localpart:'discuss',domain:'example.org'}})<br />
xyz00@hsadmin> bye<br />
</syntaxhighlight><br />
<br />
Mit dem Parameter "target" wird die für diese Adresse eingehende Post zunächst in das Postfach des Users xyz00-list abgelegt.<br />
<br />
Für den User xyz00-list lege ich in seinem Heimat-Verzeichnis das Unterverzeichnis <tt>mlmmj</tt> an:<br />
<br />
mkdir /home/pacs/xyz00/users/list/mlmmj<br />
<br />
Dann lege ich die Mailingliste mit folgendem Kommando an:<br />
<br />
mlmmj-make-ml -L discuss -s /home/pacs/xyz00/users/list/mlmmj<br />
<br />
Das Skript ''mlmmj-make-ml'' fragt weitere Parameter der Mailingliste ab:<br />
<br />
The Domain for the List? [] : example.org<br />
The emailaddress of the list owner? [postmaster] : webmaster@example.org<br />
For the list texts you can choose between the following languages or<br />
give an absolute path to a directory containing the texts.<br />
Available languages:<br />
cz da de en es fr it nl ru<br />
The path to texts for the list? [en] : de<br />
<br />
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.<br />
<br />
Weitere Konfigurationen der Liste erfolgen durch das Anlegen von Dateien im<br />
Verzeichnis "/home/pacs/xyz00/users/list/mlmmj/discuss/control".<br />
Die Konfigurationsmöglichkeiten finden Sie auf der [http://mlmmj.org/docs/tunables/ Internetseite von mlmmj].<br />
<br />
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:<br />
<br />
"|/usr/bin/mlmmj-recieve -L /home/pacs/xyz00/users/list/mlmmj/discuss/"<br />
<br />
(Ja, ''receive'' schreibt sich mit ''-ei-'', aber mlmmj hält einen symbolischen Link bereit für diejenigen, die in englischer Rechtschreibung unsicher sind:)<br />
<br />
<syntaxhighlight lang=shell><br />
xyz00-list@h03:~$ ls -la /usr/bin/mlmmj-rec*<br />
-rwxr-xr-x 1 root root 27104 Sep 25 2018 /usr/bin/mlmmj-receive<br />
lrwxrwxrwx 1 root root 13 Sep 25 2018 /usr/bin/mlmmj-recieve -> mlmmj-receive<br />
</syntaxhighlight><br />
<br />
Die <tt>.forward</tt>-Datei sorgt dafür, dass eingehende E-Mails an das User-Postfach an das Programm ''mlmmj-recieve'' übergeben werden.<br />
<br />
Für regelmäßige Aufgaben der Listen-Managers definiere ich die<br />
[[Cron|crontab]] wie folgt (immer noch als ''xyz00-list''):<br />
<br />
xyz00-list@h03:~$ crontab -e<br />
<br />
<syntaxhighlight lang=shell line><br />
MAILTO=webmaster@example.org<br />
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin<br />
HOME=/home/pacs/xyz00/users/list<br />
SHELL=/bin/bash<br />
LANG=en_US.UTF-8<br />
# m h dom mon dow command<br />
28 */4 * * * /usr/bin/mlmmj-maintd -d /home/pacs/xyz00/users/list/mlmmj -F<br />
</syntaxhighlight><br />
<br />
Zum Schluss rufe ich das Skript mlmmj-sub auf, um die E-Mail-Adressen der gewünschten Abonnenten des Verteilers einzutragen:<br />
<br />
/usr/bin/mlmmj-sub -L /home/pacs/xyz00/users/list/mlmmj/discuss -a klaus.muster@gmx.de -c <br />
/usr/bin/mlmmj-sub -L /home/pacs/xyz00/users/list/mlmmj/discuss -a sabine.beispiel@arcor.de -c <br />
<br />
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.<br />
<br />
== weitere Optionen ==<br />
<br />
Noch ein paar Dinge, die Sie möglicherweise einstellen wollen:<br />
<br />
Ein Prefix in der Betreffzeile setzen, z.B.: "[discuss]".<br />
<br />
echo "[discuss]" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/prefix<br />
<br />
Wenn die Liste nur E-Mails von eingetragenen Abonnenten weiterleiten soll:<br />
<br />
touch /home/pacs/xyz00/users/list/mlmmj/discuss/control/subonlypost<br />
<br />
Damit der Listen-Owner weitere Abonnements bestätigen muss:<br />
<br />
touch /home/pacs/xyz00/users/list/mlmmj/discuss/control/submod<br />
<br />
Einen "Reply-To:"-Header setzen, damit Antwort-Mails standardmäßig an die Mailing-Liste gehen:<br />
<br />
echo "Reply-To:" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/delheaders<br />
echo "Reply-To: discuss@example.org" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/customheaders<br />
<br />
Weitere Möglichkeiten finden Sie (wie oben bereits angegeben) <br />
auf der [http://mlmmj.org/docs/tunables/ Internetseite von mlmmj].<br />
<br />
=== Achtung: DKIM ===<br />
<br />
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:''.<br />
<br />
Wird zum Beispiel mit einem Prefix das Subject geändert oder ein Footer angehängt, macht dies die DKIM-Signatur ungültig. Das ist für viele Mailprovider ein Grund die Nachricht abzuweisen.<br />
<br />
== Zur Konfiguration im Browser ==<br />
<br />
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.<br />
<br />
Wer es sich ansehen möchte:<br />
<br />
Als Paket-Admin eine Domain aufschalten:<br />
<syntaxhighlight lang=shell><br />
hsscript -u xyz00 -e "domain.add({set:{name:'lists.example.org',user:'xyz00-list'}})"<br />
</syntaxhighlight><br />
Und weiter als "xyz00-list".<br />
<br />
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).<br />
<br />
Unter "/mlmmj-$versionsnummer/contrib/web/php-admin/", oder beim .deb-Paket unter "usr/share/mlmmj-...", findet sich die PHP-Admin-Anwendung. Also ...<br />
<br />
* den Inhalt diese Verzeichnisses nach "/home/pacs/xyz00/users/list/doms/lists.example.org/" packen;<br />
* in "/home/pacs/xyz00/users/list/doms/lists.example.org/conf/config.php" die Variable "$topdir" anpassen;<br />
* 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;<br />
* Beim .deb-Paket die config.php, die templates/ und die tunables.pl aus etc/ nach example.org/conf/ verschieben;<br />
* 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: <br />
<syntaxhighlight lang=apache line><br />
Require valid-user<br />
AuthType Basic<br />
AuthName "mlmmj web-interface"<br />
AuthUserFile /home/pacs/xyz00/users/list/doms/lists.example.org/etc/htpasswd<br />
</syntaxhighlight><br />
* Und schließlich die "htpasswd"-Datei anlegen.<br />
<br />
cd /home/pacs/xyz00/users/list/doms/lists.example.org/etc/<br />
htpasswd -c htpasswd listadmin<br />
<br />
* Ein Passwort angeben.<br />
<br />
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<br />
<br />
* in <tt>.../htdocs-ssl/index.php</tt> folgende Änderung vornehmen:<br />
<syntaxhighlight lang=diff line><br />
@@ -38,4 +38,5 @@<br />
# use scandir to have alphabetical order <br />
foreach (scandir($topdir) as $file) {<br />
- if (!ereg("^\.",$file))<br />
+# ereg obsolete!! Vormals: if (!ereg("^\.",$file))<br />
+ if (!preg_match('/^\./',$file))<br />
{<br />
</syntaxhighlight><br />
und das Ergebnis auf https://lists.example.org anschauen.<br />
<br />
== Mehrere Mailinglisten betreiben ==<br />
<br />
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.<br />
<br />
Dazu trägt man in der Datei <tt>.forward</tt> statt des Aufrufs von ''mlmmj-recieve'' einen Aufruf von ''procmail'' ein:<br />
<br />
<br />
|/usr/bin/procmail<br />
<br />
Die Konfiguration von Procmail kann generisch erfolgen. Dazu legt man eine Datei <tt>.procmailrc</tt> mit folgendem Inhalt ins $HOME des Users:<br />
<br />
SHELL=/bin/sh<br />
HOMEDIR=/home/pacs/xyz00/users/list<br />
MAILDIR=/home/pacs/xyz00/users/list/Maildir<br />
PMDIR=/home/pacs/xyz00/users/list<br />
VERBOSE=yes<br />
LOGFILE=/home/pacs/xyz00/users/list/var/procmail.log<br />
DEFAULT<br />
<br />
:0:<br />
* ^X-Original-To: ()\/[^@+]+<br />
|/usr/bin/mlmmj-receive -F -L /home/pacs/xyz00/users/list/mlmmj/${MATCH}/<br />
<br />
:0<br />
{ EXITCODE 67 }<br />
<br />
Bitte dafür sorgen, dass das Verzeichnis ''/home/pacs/xyz00/users/list/var'' existiert.<br />
<br />
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.<br />
<br />
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).<br />
<br />
===Groß- und Kleinschreibung===<br />
<br />
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.<br />
<br />
====Lösung 1====<br />
<br />
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:<br />
<br />
:0:<br />
* ^X-Original-To: ()\/[^@+]+<br />
|/usr/bin/mlmmj-receive -F -L /home/pacs/xyz00/users/list/mlmmj/$(echo ${MATCH} | tr [:upper:] [:lower:])/<br />
<br />
Der Rest der Datei muß gleich bleiben, wie weiter oben angezeigt.<br />
<br />
In diesem Fall müssen aber alle Mailing-Listen ohne Großbuchstaben im Namen angelegt werden!<br />
<br />
(Man kann auch in <tt>${HOME}/mlmmj/</tt> durch kleingeschriebene Symlinks großgeschriebene Listennamen ansprechbar machen:<br />
<br />
xyz00-list@h02:~$ ls -lA mlmmj/<br />
total 8<br />
-rw-r--r-- 1 xyz00-list xyz00 148 Feb 1 16:56 .htaccess<br />
lrwxrwxrwx 1 xyz00-list xyz00 10 Feb 2 18:01 mitglieder -> Mitglieder<br />
drwxr-xr-x 15 xyz00-list xyz00 4096 Feb 2 16:53 Mitglieder<br />
<br />
====Lösung 2====<br />
<br />
Bash kann bei der Auflösung von Variablen die Groß- und Kleinschreibung manipulieren. (Siehe dazu bei der Zeichenfolge <tt>,,</tt> in <tt>man bash</tt>.) Dann ist <code>$(echo ${MATCH} | tr [:upper:] [:lower:])</code> gleichbedeutend mit <code>${MATCH,,}</code>. Allerdings braucht procmail einige Überredung, um Bash zu verwenden.<br />
<br />
SHELL=/bin/bash<br />
SHELLMETAS=&|<>~;?*[{<br />
HOMEDIR= ...<br />
<br />
...<br />
<br />
:0:<br />
* ^X-Original-To: ()\/[^@+]+<br />
|/usr/bin/mlmmj-receive -F -L /home/pacs/xyz00/users/list/mlmmj/${MATCH,,}/<br />
<br />
Die Tücke ist, daß procmail den in SHELL angegebenen Shell nur dann verwendet, wenn in der Befehlszeile eines der in SHELLMETAS angegebenen Zeichen enthält. Und das '|' am Anfang der Zeile zählt dabei nicht! In diesem Beispiel ist es das Zeichen <tt>{</tt>, das den Einsatz von Bash auslöst.<br />
<br />
Beide Lösungen scheinen zu funktionieren; Angabe ohne Gewähr.<br />
<br />
== Links ==<br />
<br />
* http://mlmmj.org/ Projektseite<br />
* https://codeberg.org/mlmmj mlmmj auf Codeberg<br />
* https://github.com/tchapi/mlmmj-simple-web-interface ein Admin-Interface in NodeJS<br />
* [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<br />
* [https://gist.github.com/kboss/7c9593f0fd9219406226c4f11256b98a Einfaches Python-Script zum Massenimport aus einem Texfile.] Geht bestimmt auch eleganter mit purem Bash<br />
* Ein Self-Service zum Subscriben/Unsubscriben lässt sich in Form von Mail-to-Links in Webseiten einbinden. Beispiele gibt es bei Hostsharing für die öffentlichen "public"-Mailinglisten: https://www.hostsharing.net/lists/public-discussion/ . Alternativ auf https://github.com/hblasum/mlmmj-php-web-simplified ein Webfrontend mit dem sich Benutzerinnen und Benutzer selbst ein-/austragen können (Vereinfachung von mlmmj-php-web von Christoph Thiel).<br />
<br />
----<br />
[[Kategorie:HSDoku]]<br />
[[Kategorie:Installationsanleitungen]]<br />
[[Kategorie:Software]]<br />
[[Kategorie:Mailinglisten]]<br />
[[Kategorie:E-Mail]]</div>Apc00-tonyhttps://wiki.hostsharing.net/index.php?title=Mlmmj&diff=6658Mlmmj2024-05-31T14:24:44Z<p>Apc00-tony: /* Mehrere Mailinglisten betreiben */</p>
<hr />
<div>[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.<br />
<br />
Wer noch nicht weiß, was ein E-Mail-Verteiler machen soll oder wie, lese veilleicht auch den Wikipedia-Artikel:<br />
[http://de.wikipedia.org/wiki/Mailingliste Mailingliste]<br />
<br />
Eine leistungsfähigere Alternative zu mlmmj könnte [[Mailman_3_installieren|Mailman 3]] sein.<br />
<br />
Diese Anleitung beschreibt die Einrichtung einer Mailingliste für eine Domain in einem Hostsharing-Webspace.<br />
<br />
== Voraussetzungen ==<br />
<br />
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.)<br />
<br />
Für den Betrieb der Mailingliste empfiehlt sich das Anlegen eines eigenen Users für diesen Zweck mit hsadmin.<br />
<br />
In dieser Anleitung heißt das Paket ''xyz00'' und der für Mailinglisten eingesetzte User ''xyz00-list''.<br />
<br />
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''.<br />
<br />
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.)<br />
<br />
== Einrichtung ==<br />
<br />
Ich melde mich über SSH auf der Hostsharing-Console als der Paketuser ''xyz00'' an.<br />
<br />
Im Shell kann ich dann durch den Befehl ''hsscript -i'' das Verwaltungswerkzeug [[hsadmin]] interaktiv ausführen:<br />
<br />
xyz00@h03:~$ hsscript -i<br />
Password: *************<br />
xyz00@hsadmin> <br />
<br />
In ''hsadmin'' werden User und E-Mail-Adresse angelegt.<br />
<br />
<syntaxhighlight lang=shell><br />
xyz00@hsadmin> user.add({set:{name:'xyz00-list',comment:'Mailingliste Discuss',shell:'/bin/bash',password:'geheimnis'}})<br />
xyz00@hsadmin> emailaddress.add({set:{target:'xyz00-list',localpart:'discuss',domain:'example.org'}})<br />
xyz00@hsadmin> bye<br />
</syntaxhighlight><br />
<br />
Mit dem Parameter "target" wird die für diese Adresse eingehende Post zunächst in das Postfach des Users xyz00-list abgelegt.<br />
<br />
Für den User xyz00-list lege ich in seinem Heimat-Verzeichnis das Unterverzeichnis <tt>mlmmj</tt> an:<br />
<br />
mkdir /home/pacs/xyz00/users/list/mlmmj<br />
<br />
Dann lege ich die Mailingliste mit folgendem Kommando an:<br />
<br />
mlmmj-make-ml -L discuss -s /home/pacs/xyz00/users/list/mlmmj<br />
<br />
Das Skript ''mlmmj-make-ml'' fragt weitere Parameter der Mailingliste ab:<br />
<br />
The Domain for the List? [] : example.org<br />
The emailaddress of the list owner? [postmaster] : webmaster@example.org<br />
For the list texts you can choose between the following languages or<br />
give an absolute path to a directory containing the texts.<br />
Available languages:<br />
cz da de en es fr it nl ru<br />
The path to texts for the list? [en] : de<br />
<br />
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.<br />
<br />
Weitere Konfigurationen der Liste erfolgen durch das Anlegen von Dateien im<br />
Verzeichnis "/home/pacs/xyz00/users/list/mlmmj/discuss/control".<br />
Die Konfigurationsmöglichkeiten finden Sie auf der [http://mlmmj.org/docs/tunables/ Internetseite von mlmmj].<br />
<br />
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:<br />
<br />
"|/usr/bin/mlmmj-recieve -L /home/pacs/xyz00/users/list/mlmmj/discuss/"<br />
<br />
(Ja, ''receive'' schreibt sich mit ''-ei-'', aber mlmmj hält einen symbolischen Link bereit für diejenigen, die in englischer Rechtschreibung unsicher sind:)<br />
<br />
<syntaxhighlight lang=shell><br />
xyz00-list@h03:~$ ls -la /usr/bin/mlmmj-rec*<br />
-rwxr-xr-x 1 root root 27104 Sep 25 2018 /usr/bin/mlmmj-receive<br />
lrwxrwxrwx 1 root root 13 Sep 25 2018 /usr/bin/mlmmj-recieve -> mlmmj-receive<br />
</syntaxhighlight><br />
<br />
Die <tt>.forward</tt>-Datei sorgt dafür, dass eingehende E-Mails an das User-Postfach an das Programm ''mlmmj-recieve'' übergeben werden.<br />
<br />
Für regelmäßige Aufgaben der Listen-Managers definiere ich die<br />
[[Cron|crontab]] wie folgt (immer noch als ''xyz00-list''):<br />
<br />
xyz00-list@h03:~$ crontab -e<br />
<br />
<syntaxhighlight lang=shell line><br />
MAILTO=webmaster@example.org<br />
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin<br />
HOME=/home/pacs/xyz00/users/list<br />
SHELL=/bin/bash<br />
LANG=en_US.UTF-8<br />
# m h dom mon dow command<br />
28 */4 * * * /usr/bin/mlmmj-maintd -d /home/pacs/xyz00/users/list/mlmmj -F<br />
</syntaxhighlight><br />
<br />
Zum Schluss rufe ich das Skript mlmmj-sub auf, um die E-Mail-Adressen der gewünschten Abonnenten des Verteilers einzutragen:<br />
<br />
/usr/bin/mlmmj-sub -L /home/pacs/xyz00/users/list/mlmmj/discuss -a klaus.muster@gmx.de -c <br />
/usr/bin/mlmmj-sub -L /home/pacs/xyz00/users/list/mlmmj/discuss -a sabine.beispiel@arcor.de -c <br />
<br />
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.<br />
<br />
== weitere Optionen ==<br />
<br />
Noch ein paar Dinge, die Sie möglicherweise einstellen wollen:<br />
<br />
Ein Prefix in der Betreffzeile setzen, z.B.: "[discuss]".<br />
<br />
echo "[discuss]" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/prefix<br />
<br />
Wenn die Liste nur E-Mails von eingetragenen Abonnenten weiterleiten soll:<br />
<br />
touch /home/pacs/xyz00/users/list/mlmmj/discuss/control/subonlypost<br />
<br />
Damit der Listen-Owner weitere Abonnements bestätigen muss:<br />
<br />
touch /home/pacs/xyz00/users/list/mlmmj/discuss/control/submod<br />
<br />
Einen "Reply-To:"-Header setzen, damit Antwort-Mails standardmäßig an die Mailing-Liste gehen:<br />
<br />
echo "Reply-To:" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/delheaders<br />
echo "Reply-To: discuss@example.org" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/customheaders<br />
<br />
Weitere Möglichkeiten finden Sie (wie oben bereits angegeben) <br />
auf der [http://mlmmj.org/docs/tunables/ Internetseite von mlmmj].<br />
<br />
=== Achtung: DKIM ===<br />
<br />
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:''.<br />
<br />
Wird zum Beispiel mit einem Prefix das Subject geändert oder ein Footer angehängt, macht dies die DKIM-Signatur ungültig. Das ist für viele Mailprovider ein Grund die Nachricht abzuweisen.<br />
<br />
== Zur Konfiguration im Browser ==<br />
<br />
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.<br />
<br />
Wer es sich ansehen möchte:<br />
<br />
Als Paket-Admin eine Domain aufschalten:<br />
<syntaxhighlight lang=shell><br />
hsscript -u xyz00 -e "domain.add({set:{name:'lists.example.org',user:'xyz00-list'}})"<br />
</syntaxhighlight><br />
Und weiter als "xyz00-list".<br />
<br />
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).<br />
<br />
Unter "/mlmmj-$versionsnummer/contrib/web/php-admin/", oder beim .deb-Paket unter "usr/share/mlmmj-...", findet sich die PHP-Admin-Anwendung. Also ...<br />
<br />
* den Inhalt diese Verzeichnisses nach "/home/pacs/xyz00/users/list/doms/lists.example.org/" packen;<br />
* in "/home/pacs/xyz00/users/list/doms/lists.example.org/conf/config.php" die Variable "$topdir" anpassen;<br />
* 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;<br />
* Beim .deb-Paket die config.php, die templates/ und die tunables.pl aus etc/ nach example.org/conf/ verschieben;<br />
* 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: <br />
<syntaxhighlight lang=apache line><br />
Require valid-user<br />
AuthType Basic<br />
AuthName "mlmmj web-interface"<br />
AuthUserFile /home/pacs/xyz00/users/list/doms/lists.example.org/etc/htpasswd<br />
</syntaxhighlight><br />
* Und schließlich die "htpasswd"-Datei anlegen.<br />
<br />
cd /home/pacs/xyz00/users/list/doms/lists.example.org/etc/<br />
htpasswd -c htpasswd listadmin<br />
<br />
* Ein Passwort angeben.<br />
<br />
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<br />
<br />
* in <tt>.../htdocs-ssl/index.php</tt> folgende Änderung vornehmen:<br />
<syntaxhighlight lang=diff line><br />
@@ -38,4 +38,5 @@<br />
# use scandir to have alphabetical order <br />
foreach (scandir($topdir) as $file) {<br />
- if (!ereg("^\.",$file))<br />
+# ereg obsolete!! Vormals: if (!ereg("^\.",$file))<br />
+ if (!preg_match('/^\./',$file))<br />
{<br />
</syntaxhighlight><br />
und das Ergebnis auf https://lists.example.org anschauen.<br />
<br />
== Mehrere Mailinglisten betreiben ==<br />
<br />
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.<br />
<br />
Dazu trägt man in der Datei <tt>.forward</tt> statt des Aufrufs von ''mlmmj-recieve'' einen Aufruf von ''procmail'' ein:<br />
<br />
<br />
|/usr/bin/procmail<br />
<br />
Die Konfiguration von Procmail kann generisch erfolgen. Dazu legt man eine Datei <tt>.procmailrc</tt> mit folgendem Inhalt ins $HOME des Users:<br />
<br />
SHELL=/bin/sh<br />
HOMEDIR=/home/pacs/xyz00/users/list<br />
MAILDIR=/home/pacs/xyz00/users/list/Maildir<br />
PMDIR=/home/pacs/xyz00/users/list<br />
VERBOSE=yes<br />
LOGFILE=/home/pacs/xyz00/users/list/var/procmail.log<br />
DEFAULT<br />
<br />
:0:<br />
* ^X-Original-To: ()\/[^@+]+<br />
|/usr/bin/mlmmj-receive -F -L /home/pacs/xyz00/users/list/mlmmj/${MATCH}/<br />
<br />
:0<br />
{ EXITCODE 67 }<br />
<br />
Bitte dafür sorgen, dass das Verzeichnis ''/home/pacs/xyz00/users/list/var'' existiert.<br />
<br />
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.<br />
<br />
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).<br />
<br />
===Groß- und Kleinschreibung===<br />
<br />
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.<br />
<br />
====Lösung 1====<br />
<br />
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:<br />
<br />
:0:<br />
* ^X-Original-To: ()\/[^@+]+<br />
|/usr/bin/mlmmj-receive -F -L /home/pacs/xyz00/users/list/mlmmj/$(echo ${MATCH} | tr [:upper:] [:lower:])/<br />
<br />
Der Rest der Datei muß gleich bleiben, wie weiter oben angezeigt.<br />
<br />
In diesem Fall müssen aber alle Mailing-Listen ohne Großbuchstaben im Namen angelegt werden!<br />
<br />
(Man kann auch in <tt>${HOME}/mlmmj/</tt> durch kleingeschriebene Symlinks großgeschriebene Listennamen ansprechbar machen:<br />
<br />
xyz00-list@h02:~$ ls -lA mlmmj/<br />
total 8<br />
-rw-r--r-- 1 xyz00-list xyz00 148 Feb 1 16:56 .htaccess<br />
lrwxrwxrwx 1 xyz00-list xyz00 10 Feb 2 18:01 mitglieder -> Mitglieder<br />
drwxr-xr-x 15 xyz00-list xyz00 4096 Feb 2 16:53 Mitglieder<br />
<br />
====Lösung 2====<br />
<br />
Bash kann bei der Auflösung von Variablen die Groß- und Kleinschreibung manipulieren. (Siehe dazu bei der Zeichenfolge <tt>,,</tt> in <tt>man bash</tt>.) Dann ist <code>$(echo ${MATCH} | tr [:upper:] [:lower:])</code> gleichbedeutend mit <code>${MATCH,,}</code>. Allerdings braucht procmail einige Überredung, um Bash zu verwenden.<br />
<br />
SHELL=/bin/bash<br />
SHELLMETAS=&|<>~;?*[{<br />
<br />
<br />
...<br />
<br />
<br />
HOMEDIR=/home/pacs/xyz00/users/list<br />
MAILDIR=/home/pacs/xyz00/users/list/Maildir<br />
PMDIR=/home/pacs/xyz00/users/list<br />
VERBOSE=yes<br />
LOGFILE=/home/pacs/xyz00/users/list/var/procmail.log<br />
DEFAULT<br />
<br />
:0:<br />
* ^X-Original-To: ()\/[^@+]+<br />
|/usr/bin/mlmmj-receive -F -L /home/pacs/xyz00/users/list/mlmmj/${MATCH}/<br />
<br />
:0<br />
{ EXITCODE 67 }<br />
<br />
<br />
Beides scheint zu funktionieren; Angabe ohne Gewähr.)<br />
<br />
== Links ==<br />
<br />
* http://mlmmj.org/ Projektseite<br />
* https://codeberg.org/mlmmj mlmmj auf Codeberg<br />
* https://github.com/tchapi/mlmmj-simple-web-interface ein Admin-Interface in NodeJS<br />
* [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<br />
* [https://gist.github.com/kboss/7c9593f0fd9219406226c4f11256b98a Einfaches Python-Script zum Massenimport aus einem Texfile.] Geht bestimmt auch eleganter mit purem Bash<br />
* Ein Self-Service zum Subscriben/Unsubscriben lässt sich in Form von Mail-to-Links in Webseiten einbinden. Beispiele gibt es bei Hostsharing für die öffentlichen "public"-Mailinglisten: https://www.hostsharing.net/lists/public-discussion/ . Alternativ auf https://github.com/hblasum/mlmmj-php-web-simplified ein Webfrontend mit dem sich Benutzerinnen und Benutzer selbst ein-/austragen können (Vereinfachung von mlmmj-php-web von Christoph Thiel).<br />
<br />
----<br />
[[Kategorie:HSDoku]]<br />
[[Kategorie:Installationsanleitungen]]<br />
[[Kategorie:Software]]<br />
[[Kategorie:Mailinglisten]]<br />
[[Kategorie:E-Mail]]</div>Apc00-tonyhttps://wiki.hostsharing.net/index.php?title=PHP&diff=6419PHP2024-02-15T11:50:32Z<p>Apc00-tony: /* Alternative: PATH Variable setzen */ Format</p>
<hr />
<div>PHP wird bei Hostsharing per FastCGI ausgeführt. Dafür wird in jedem Domainverzeichnis unter "fastcgi/" und "fastcgi-ssl/" eine "hs-phpstub"-Datei angelegt. Der Apache Webserver ist konfiguriert .php Dateien über diesen "Stub" mit den Rechten des Users auszuführen.<br />
<br />
Zur Wiederherstellung des originalen "hs-phpstub" ist dieser zentral im Verzeichnis <br />
<br />
/usr/local/src/phpstub<br />
<br />
abgelegt.<br />
<br />
Anwender, die lediglich PHP-Dateien hochgeladen haben, brauchen ausdrücklich keine eigene php.ini.<br />
<br />
=== Auswahl der PHP-Version === <br />
<br />
In HSAdmin kann pro Domain festgelegt werden, welche PHP-Version der "hs-phpstub" für das Ausführen von PHP-Skripten verwendet. Zur Zeit werden die PHP-Version 8.2, 8.1, 8.0 und 7.4 unterstützt.<br />
<br />
=== Anpassung der PHP Konfiguration === <br />
<br />
Die Datei "php.ini" wird zur Konfiguration des PHP-Intergreters verwendet. Die Voreinstellungen können pro Domain überschrieben werden. Dazu legt der Domain-Administrator im Verzeichnis "fastcgi-ssl/" (bzw. "fastcgi/") eine eigene Datei "php.ini" an.<br />
<br />
Der komplette Pfad zu dieser Datei lautet zum Beispiel<br />
(für den Webspace "xyz00" den Domain-User "xyz00-meinbenutzer" und die Domain "meinedomain.de"):<br />
<br />
/home/pacs/xyz00/users/meinbenutzer/doms/meinedomain.de/fastcgi-ssl/php.ini <br />
<br />
In dieser Datei müssen nicht alle Konfigurationsoptionen von PHP definiert sein, sondern nur die, die sich gegenüber der Standard php.ini ändern sollen. Diese liegt in /etc/php/VERSIONSNUMMER/cgi und kann dort eingesehen werden.<br />
<br />
'''Achtung:''' Kommentare nicht mit # einleiten (kann zu unerwarteten Fehlkonfigurationen führen), Kommentarzeichen ist das Semikolon ";".<br />
<br />
Häufig anzupassen sind z.B.:<br />
<br />
* die Content-Type charset= Vorgabe für den HTTP Header.<br />
<br />
* der maximal verwendbare Hauptspeicher (memory_limit).<br />
<br />
* die maximale Größe hochgeladener Dateien (post_max_size).<br />
<br />
* die aktiven Extensions.<br />
<br />
<br />
Beispiel einer php.ini: <br />
<br />
<pre><br />
------8< SCHNIPP >8------<br />
[..]<br />
memory_limit = 128M (default)<br />
post_max_size = 8M (default)<br />
upload_max_filesize = 2M (default)<br />
display_errors = Off (default)<br />
log_errors = Off (default)<br />
error_log = /home/pacs/xyz00/users/meinbenutzer/doms/meinedomain.de/fastcgi-ssl/php_errors.log<br />
<br />
[..]<br />
default_charset = "UTF-8"<br />
; (ist sonst iso-8859-1)<br />
; Der charset kann aber wiederum durch einen Funktionsaufruf<br />
; header("Content-Type: text/html; charset=iso-8859-1")<br />
; im PHP-Skript überschrieben werden (sofern output_buffering = On).<br />
------8< SCHNIPP >8------<br />
</pre><br />
<br />
'''Beachte:''' Eine geänderte php.ini Konfiguration wird mit FastCGI erst übernommen, wenn die PHP Prozesse des Users (die über längere Zeit laufen bleiben) neu gestartet werden.<br />
<br />
Man kann ein Neustarten der PHP Prozesse mit dem folgenden Kommando erzwingen:<br />
<br />
killall -u $USER -r php<br />
<br />
$USER enhält als Umgebungsvariable den aktuell angemeldeten Benutzer und muss nicht durch den Benutzernamen (xyz00 oder xyz00-user) ersetzt werden. Nur die Prozesse des angemeldeten Users $USER werden gelöscht. "-r" bewirkt, dass der Ausdruck "php" als regulärer Ausdruck interpretiert wird. Intern heißen die sichtbaren Prozesse nicht "php" sondern beispielsweise "php7.4"<br />
<br />
=== PHP Sicherheit ===<br />
<br />
==== open_basedir ====<br />
<br />
Sofern der PHP Parameter open_basdir nicht gesetzt ist (Vorgabe) können (kompromittierte) php Skripte an alle Dateien des Users kommen, ohne einen extra Shellzugang installieren zu müssen und dadurch entdeckt zu werden.<br />
<br />
Die Passwortabfrage von Hsadmin bringt eine Abhilfe für die zentralen Dienste. (Sofern Du dein Passwort nicht in eine Datei schreibst und die Abfrage so wieder ausschaltest, wovon besser abzusehen ist.) Doch alle Daten auf die Du als Benutzer zugreifen kannst sind prinzipiell den PHP-Skripten ausgeliefert.<br />
<br />
Mit open_basedir wird festgelegt in welchen Verzeichnissen PHP Skripte lesen und schreiben dürfen. Geprüft wird dabei ob der zu öffnende Pfad mit dem angegebene Pfad beginnt. Es ist daher wichtig ob sich am Ende ein "/" befindet oder nicht. Ein open_basedir von /home/doms/example.org/subs/www (ohne /) erlaubt somit z.B. auch Zugriffe auf die Subdomain www2 etc.<br />
<br />
Beispielzeile für die php.ini:<br />
open_basedir = /home/doms/example.org/subs/<br />
<br />
Wenn man mehrere Subdomains hat und diese isolieren möchte, ist dies durch Aufschaltung von lokalen Subdomains auf verschiedene User möglich. (Siehe https://doc.hostsharing.net/users/administration/domain/index.html )<br />
<br />
==== Sicherheitskritische Funktionen ====<br />
<br />
Weitere Dinge die deaktiviert werden sollten, wenn sie nicht benötigt werden, was im allgemeinen der Fall ist, sind: Das öffnen von URLs als Dateien,<br />
<br />
allow_url_fopen = Off<br />
<br />
und die Ausführung von Systembefehlen.<br />
<br />
disable_functions = show_source, system, passthru, shell_exec, exec, phpinfo, popen, proc_open<br />
<br />
<br />
=== eigene PHP Konfigurationen und verschiedene nebeneinander verwenden ===<br />
<br />
Um verschiedene PHP Konfigurationen nebeneinander zu verwenden, kopierst Du einen eigenen "phpstub" in ein Unterzeichnis von (fast)cgi(-ssl) und mappst (Einträge in der .htaccess) nach Belieben deine PHP Dateien darauf. <br />
So können beliebig viele Konfigurationen bei einer Domain nebeneinander genutzt werden.<br />
<br />
==== Beispiel muster.example.com ==== <br />
<pre><br />
mkdir ~/doms/example.com/fastcgi/muster<br />
cp ~/doms/example.com/fastcgi/phpstub ~/doms/example.com/fastcgi/muster/phpstub<br />
<br />
und wenn benötigt:<br />
vi ~/doms/example.com/fastcgi/muster/php.ini<br />
</pre><br />
<br />
Anschließend muss der Apache Webserver noch angewiesen werden auch diese bestimmte Konfiguration von PHP zu verwenden. Dazu werden der [[.htaccess]] Datei im DocumentRoot der Sub-Domain zwei Zeilen hinzugefügt bzw. eine .htaccess mit den zwei Zeilen angelegt. <br />
Im Beispiel handelt es sich um die Domain muster.example.com, also:<br />
<br />
<pre><br />
cd ~/doms/example.com/subs/muster<br />
vi .htaccess<br />
<br />
AddType application/x-httpd-phpfastcgi .php<br />
Action application/x-httpd-phpfastcgi /fastcgi-bin/muster/phpstub<br />
</pre><br />
<br />
== Vorinstallierte PHP Version wechseln ==<br />
<br />
Hostsharing stellt neben der aktuellen Standardversion PHP 8.2 auch die Versionen PHP 7.4, 8.0 und 8.1 zur Verfügung.<br />
<br />
<br />
===PHP 8.2 für ssh-Zugang per Shell aktivieren===<br />
<br />
Möchte man an der Shell immer /usr/bin/php8.0 statt /usr/bin/php aufrufen, dann kann der Befehl auch in die Datei "~/.profile" ergänzt werden mit der Zeile: <br />
<pre>alias php='/usr/bin/php8.0'</pre><br />
<br />
Nach Aktualisierung der Datei "~/.profile" noch eingeben <br />
<pre>$ source ~/.profile</pre><br />
Dann sollte der Aufruf php -v die version php 8.0 zurückgeben. <br />
<br />
Gleiches gilt natürlich auch andere bei HS verfügbare PHP Versionen.<br />
<br />
==== Alternative: <tt>PATH</tt> Variable setzen ====<br />
<br />
Eine Alternative ist die Nutzung einer alternativen Verlinkung und das setzen eines eigenen Pfades<br />
Composer, oder andere php Scripte können auch als Programme php aufrufen, wenn sie dazu die Version aus <tt>/usr/bin/env</tt> nutzen, bekommen Sie die Standard PHP version geliefert, beispielsweise php7.4.<br />
Dieser Aufruf umgeht jeglichen Alias in <tt>~/.profile</tt> oder <tt>~/.bash_profile</tt>.<br />
Welche verlinkung in <tt>/usr/bin/env</tt> gesetzt ist lässt sich überprüfen durch den Befehl:<br />
<pre>$ which php</pre><br />
sollte ergeben:<br />
<pre>/usr/bin/php</pre> (und dies ist verlinkt mit irgendeiner System PHP Version zum Beispiel php7.4<br />
<br />
Anstelle der Nutzung also eines Alias wird nun einfach ein symbolischer Link an eine gewünschte Position gesetzt, zum Beispiel mit:<br />
<pre>$ mkdir /home/doms/example.com/app/php8.2</pre><br />
<pre>$ ln -s /usr/bin/php8.2 /home/doms/example.com/app/php8.2/<strong>php</strong></pre> (wichtig, es muss hier als "php" benannt werden"<br />
Nun wird der Pfad um diesen Punkt erweitert:<br />
in <tt>~/.profile</tt> oder <tt>~/.bash_profile</tt><br />
<pre>PATH="/home/doms/example.com/app/php8.2:$PATH"</pre><br />
Nun liegt der Pfad noch vor dem Systempfad, was sich durch den Befehl<br />
<pre>$ echo $PATH</pre> überprüfen lässt:<br />
hier steht jetzt so etwas wie:<br />
<pre><strong>/home/doms/example.com/app/php8.2</strong>:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games</pre><br />
das heißt, bevor der Aufruf des Befehls php in /usr/bin/ danach sucht, hat er das Script "php" schon in dem neu erstellten Ordner gefunden und ruft diesen auf.<br />
Diese <tt>PATH</tt> Variable funktioniert nun natürlich genauso für alle Bash / cli Eingaben und ersetzt die Vergabe von Alias.<br />
<pre>$ which php</pre> ergibt nun:<br />
<pre>/home/doms/example.com/app/php8.2/php</pre><br />
<br />
== Eigene PHP Version ==<br />
Es kann auch eine eigene PHP Version im Paket installiert werden.<br />
Eine Kurzanleitung ist unter [[Eigene_PHP_Version]] beschrieben.<br />
<br />
== Eigener PHP FPM Prozess ==<br />
<br />
auf einem Managed Server kann jeder Nutzer nach belieben auch php-fpm als eigenen Prozess starten.<br />
Ein paar Notizen dazu finden sich auf der Seite [[PHP_FPM]].<br />
<br />
----<br />
[[Kategorie:HSDoku]]<br />
[[Kategorie:Installationsanleitungen]]<br />
[[Kategorie:Software]]<br />
[[Kategorie:Glossar]]<br />
[[Kategorie:WWW]]</div>Apc00-tonyhttps://wiki.hostsharing.net/index.php?title=DAViCal_installieren&diff=6418DAViCal installieren2024-02-14T13:51:47Z<p>Apc00-tony: /* Quellen */ Source now at davical.org.</p>
<hr />
<div>== Allgemein ==<br />
=== Beschreibung ===<br />
[http://www.davical.org/ DAViCal] ist ein Server für die Verwaltung von Kalendern über das [http://caldav.calconnect.org/ CalDAV-Protokoll]. Die Kalenderdaten können mit allen CalDAV-fähigen Client-Programmen gelesen und geschrieben werden, z.B. Thunderbird mit [http://www.mozilla.org/projects/calendar/lightning/ Lightning], Evolution, Mulberry, iCal, oder iPhone.<br />
<br />
Das CalDAV-Protokoll bietet viele Funktionen, die noch nicht von allen Clients unterstützt werden, darunter Serien, Erinnerungen, Einladungen, Ressourcen, Arbeitsgruppen etc.<br />
<br />
DAViCal ist in PHP geschrieben, lizensiert unter GPL.<br />
<br />
DAViCal erlaubt auch über das WebDAV-Protokoll Kalender zu lesen, aber nicht zu modifizieren.<br />
<br />
=== Voraussetzungen ===<br />
<br />
DAViCal erfordert folgende technische Ressourcen:<br />
* PostgreSQL<br />
* Webserver mit PHP5<br />
* Perl für den Installationsvorgang<br />
* Ein Dateisystem mit erweiterten Attributen.<br />
<br />
Die Installations-Anleitung auf der Projekt-Homepage geht davon aus, daß mal als Administrator auf den Server zugreifen kann. Die Anleitung hier beschreibt, wie man konkret DAViCal in der Shared-Hosting-Umgebung bei Hostsharing installiert und betreibt.<br />
<br />
== Installation ==<br />
<br />
=== Design ===<br />
<br />
Diese Installationsanleitung beschreibt, wie DAViCal in einer eigens dafür [[Domainverwaltung#Lokale_Subdomains_durch_Aufschalten.3B_Delegieren|aufgeschalteten Subdomain]] über SSL betrieben wird. Für andere Konfigurationen, wie z.B. die Installation von DAViCal in einer als Unterverzeichnis von <tt>~/doms/''domain''/subs/</tt> erstellten Subdomain, muß dieses Verfahren leicht angepaßt werden.<br />
<br />
Der Vorteil einer Installation in einer aufgeschalteten Subdomain ist, daß die Installation leicht von anderen Domaininhalten, PHP-Konfigurationen, oder sogar von anderen Domain-Administratoren, isoliert werden kann.<br />
<br />
=== Subdomain aufschalten ===<br />
<br />
Im Folgenden werden folgende Domainkonfigurationsdaten als Beispiel verwendet:<br />
<br />
{| class="wikitable"<br />
|- class="hintergrundfarbe5"<br />
! Typ !! Wert !! Beschreibung<br />
|-<br />
| Subdomain || <tt>cal.example.org</tt> || Die Subdomain, unter der ein DAViCal-Server laufen soll<br />
|-<br />
| Domain-Admin || <tt>xyz00-hans</tt> || Der User, dem die Subdomain delegiert wurde<br />
|}<br />
<br />
=== Quellen ===<br />
<br />
Neben dem Sourcecode vom eigentlichen DAViCal-Programm wird auch die PHP-Bibliothek [http://andrew.mcmillan.net.nz/projects/awl ''Andrew's Web Libraries''] benötigt. Diese stammt vom gleichen Entwickler.<br />
<br />
Die jeweils neusten Versionen befinden sich unter:<br />
* DAViCal: https://www.davical.org/downloads/<br />
* AWL: https://www.davical.org/downloads/<br />
<br />
Hier jeweils die Source-Dateien (<tt>*.tar.xz</tt>) benutzen.<br />
<br />
==== Download ====<br />
<br />
<pre><nowiki><br />
$ cd ~/doms/cal.example.org/var<br />
$ wget http://debian.mcmillan.net.nz/packages/awl/awl-0.53.tar.gz<br />
$ wget http://debian.mcmillan.net.nz/packages/davical/davical-1.1.1.tar.gz<br />
</nowiki></pre><br />
<br />
==== Auspacken ====<br />
<br />
Um die Dateien für den Betrieb in der Serverumgebung lesbar zu machen, die Dateierzeungsmaske temporär auf 022 setzen:<br />
<br />
<pre><nowiki><br />
$ umask 022<br />
</nowiki></pre><br />
<br />
Dann die heruntergeladenen Tarballs mit <tt>tar</tt> auspacken:<br />
<br />
<pre><nowiki><br />
$ tar xfvz awl-0.46.tar.gz<br />
$ tar xfvz davical-0.9.9.4.tar.gz<br />
</nowiki></pre><br />
<br />
Dann zwei symbolische Links mit den generischen Namen <tt>davical</tt> und <tt>awl</tt> erzeugen, die auf die installierten Versionen zeigen (dies erleichtert einen späteren Versionswechsel):<br />
<br />
<pre><nowiki><br />
$ ln -s awl-0.53 awl<br />
$ ln -s davical-1.1.1 davical<br />
</nowiki></pre><br />
<br />
Und zum Schluß die ursprüngliche Dateierzeugungsmaske wiederherstellen:<br />
<br />
<pre><nowiki><br />
$ umask 077<br />
</nowiki></pre><br />
<br />
=== PostgreSQL vorbereiten ===<br />
<br />
DAViCal benötigt eine eigene PostgreSQL-Datenbank sowie 2 Datenbanknutzer.<br />
<br />
<br />
DAViCal enthält ein eigenes Installations-Skript, das die erforderlichen Datenbank, Datenbanknutzer, prozedurale Sprache, und Datenbanktabellen anlegt und initialisiert. Dies liegt unter <tt>davical/dba/create-database.sh</tt>. Allerdings basiert das Skript auf der Annahme, daß man Superuser-Rechte hat, was in der Shared-Hosting-Umgebung nicht der Fall ist. In diesem Abschnitt wird deshalb beschrieben, wie man die entsprechenden Vorgänge in Hostsharing "von Hand" bewerkstelligt.<br />
<br />
==== Datenbank und Datenbanknutzer anlegen ====<br />
<br />
In dieser Anleitung werden folgende Namen für die Datenbank und deren Nutzer verwendet. Das Paket-Kürzel <tt>xyz00</tt> ist natürlich durch das des betreffenden Pakets zu ersetzen.<br />
<br />
{| class="wikitable"<br />
|- class="hintergrundfarbe5"<br />
! Typ !! Wert !! Beschreibung<br />
|-<br />
| DB-Admin || <tt>xyz00_davical_dba</tt> || Der PostgreSQL-Nutzer, dem die Datenbank gehört und der administrative Tätigkeiten durchführt.<br />
|-<br />
| DB-Nutzer || <tt>xyz00_davical_app</tt> || Der PostgreSQL-Nutzername, den DAViCal benutzt, um in der Datenbank zu lesen und zu schreiben.<br />
|-<br />
| Datenbank || <tt>xyz00_davical</tt> || Die PostgreSQL-Datenbank, die DAViCals Daten enthält.<br />
|}<br />
<br />
==== Umgebungsvariablen und PostgreSQL-Paßwort ====<br />
<br />
Die Nutzer und die Datenbank können über [[Hsadmin]] angelegt werden. Siehe dazu die Anleitungen auf der Seite [[PostgreSQL]] und [[Datenbanken]]. Diese Schritte müssen ggf. vom Paket-Admin vorgenommen werden.<br />
<br />
<pre><nowiki><br />
$ su xyz00<br />
$ hsadmin -c postgresqluser.add --set:name=xyz00_davical_dba --set:password=geheim<br />
$ hsadmin -c postgresqluser.add --set:name=xyz00_davical_app --set:password=geheim<br />
</nowiki></pre><br />
<br />
Als Besitzer der DAViCal-Datenbank <tt>xyz00_davical_dba</tt> angeben; als Zeichenkodierung ist das Default <tt>UTF-8</tt> richtig:<br />
<br />
<pre><nowiki><br />
$ hsadmin -c postgresqldb.add --set:name=xyz00_davical --set:owner=xyz00_davical_dba<br />
$ exit<br />
</nowiki></pre><br />
<br />
Sowohl für die weitere Installation als auch für den Betrieb des Servers ist es am einfachsten, die Passwörter in eine <tt>[http://www.postgresql.org/docs/9.0/interactive/libpq-pgpass.html .pgpass]</tt>-Datei zu schreiben: so müssen sie weder in den PHP-Dateien angegeben noch während der Installation manuell eingegeben werden.<br />
<br />
<pre><nowiki><br />
$ echo "localhost:5432:*:xyz00_davical_dba:geheimes_passwort" >> ~/.pgpass<br />
$ echo "localhost:5432:*:xyz00_davical_app:geheimes_passwort" >> ~/.pgpass<br />
$ chmod 0600 ~/.pgpass<br />
</nowiki></pre><br />
<br />
Zur weiteren Bequemlichkeit Umgebungsvariablen setzen, so daß beim Aufruf von <tt>psql</tt> über die Kommandozeile keine Datenbank- und Nutzernamen eingegeben werden müssen. Diese Angaben gehen mit Beenden der Shell-Sitzung verloren.<br />
<br />
<pre><nowiki><br />
$ PGHOST=localhost <br />
$ PGUSER=xyz00_davical_dba<br />
$ PGDATABASE=xyz00_davical <br />
$ export PGHOST PGUSER PGDATABASE <br />
</nowiki></pre><br />
<br />
==== PL/pgSQL installieren ====<br />
<br />
In der Datenbank wird die prozedurale Sprache PL/pgSQL benötigt. Diese wird durch den folgenden Befehl angelegt:<br />
<br />
<pre><nowiki><br />
$ psql -A -c "CREATE LANGUAGE plpgsql;"<br />
</nowiki></pre><br />
<br />
==== Datenbank-Tabellen anlegen und initialisieren ====<br />
<br />
Die folgenden Befehle zum Anlegen der Datenbanktabellen können in dieser Form einfach nacheinander ausgeführt werden, wenn wie oben beschrieben die Umgebungsvariablen <tt>PGHOST</tt>, <tt>PGUSER</tt> und <tt>PGDATABASE</tt> gesetzt wurden und die <tt>.pgpass</tt>-Datei geschrieben wurde.<br />
<br />
<pre><nowiki><br />
$ psql -A -f awl/dba/awl-tables.sql<br />
$ psql -A -f awl/dba/schema-management.sql<br />
$ psql -A -f davical/dba/davical.sql<br />
$ ./davical/dba/update-davical-database –dbhost=${PGHOST} –dbuser=${PGUSER} –dbname=${PGDATABASE} --appuser=${PGDATABASE}_app<br />
$ psql -A -f davical/dba/base-data.sql<br />
</nowiki></pre><br />
<br />
Für den DAViCal-Admin muß noch ein Passwort gesetzt werden &ndash; '<tt>**</tt>' vor dem Passwort ist hier wichtig.<br />
<br />
<pre><nowiki><br />
$ psql -A -c "UPDATE usr SET password = '**geheim' WHERE user_no = 1;"<br />
</nowiki></pre><br />
<br />
=== Konfiguration ===<br />
<br />
DAViCal wird durch Angaben in der PHP-Datei <tt>davical/config/config.php</tt> konfiguriert. Der folgende Befehl erzeugt eine Beispiel-Datei; weitere Beispiele befinden sich im Verzeichnis <tt>davical/config/</tt>. Die Konfigurationsparameter sind im [http://wiki.davical.org/w/Configuration DAViCal-Wiki] beschrieben.<br />
<br />
<pre><nowiki><br />
$ cat > davical/config/config.php<br />
$c->pg_connect[] = "dbname=xyz00_davical user=xyz00_davical_app host=localhost"; <br />
$c->use_persistent = true; <br />
$c->sysabbr = 'cal@example.org'; <br />
$c->admin_email = 'admin@cal.example.org'; <br />
$c->system_name = 'CalDAV Server example.org'; <br />
$c->default_locale = 'de_DE'; <br />
$c->template_usr = array( 'active' => true, <br />
'locale' => 'de_DE', <br />
'date_format_type' => 'E', <br />
'email_ok' => date('Y-m-d') <br />
); <br />
^D<br />
</nowiki></pre><br />
<br />
=== Fast-CGI-Patch ===<br />
<br />
Bei der Benutzung von Fast-CGI werden die HTTP_AUTHORIZATION-Zeilen der HTTP-Anfragen normalerweise nicht weitergeleitet. Dieses Problem wird auch im DAViCal-Wiki in einem entsprechenden [http://wiki.davical.org/w/FastCGI FAQ-Eintrag] behandelt. Die dort angeführte Lösung beruht allerdings wieder einmal auf der Annahme, daß man Superuser-Rechte hat.<br />
<br />
In der Shared-Hosting-Umgebung von Hostsharing kann die notwendige Anpassung über eine Rewrite-Anweisung in der <tt>.htaccess</tt>-Datei gemacht werden:<br />
<br />
<pre><nowiki><br />
$ cd ~/doms/cal.example.org/var/davical/htdocs<br />
$ cat >> .htaccess<br />
RewriteEngine On<br />
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization},L]<br />
^D<br />
</nowiki></pre><br />
<br />
Zur Zeit enthält die mit DAViCal mitgelieferte Datei <tt>.htaccess</tt> nur auskommentierte Beispielanweisungen. Für alle Fälle sollte man aber darauf achten, daß man den bestehenden Inhalt von <tt>.htaccess</tt> nicht überschreibt: d.h. die neuen Eingaben mit <tt>>></tt> der bestehenden Datei '''anhängen'''. Die neue Rewrite-Regel muß die letzte Regel in der <tt>.htaccess</tt> sein. Die Datei muß zudem für Apache lesbar sein:<br />
<br />
<pre><nowiki><br />
$ chmod 0644 .htaccess<br />
</nowiki></pre><br />
<br />
Darüberhinaus muß noch die Datei <tt>davical/inc/HTTPAuthSession.php</tt> angepasst werden. Hier ist die Variable <tt>$_SERVER["AUTHORIZATION"]</tt> ersetzt werden durch <tt>$_SERVER["REDIRECT_HTTP_AUTHORIZATION"]</tt>. Außerdem gibt es noch einen Bug: Es wird an einer Stelle <tt>split()</tt> statt <tt>explode</tt> benutzt. <tt>split()</tt> ist seit PHP 5.3.0 ''deprecated''.<br />
<br />
@@ -101,10 +101,10 @@<br />
/**<br />
* Get HTTP Auth to work with PHP+FastCGI<br />
*/<br />
if ( !isset($_SERVER['AUTHORIZATION']) && isset($_SERVER['HTTP_AUTHORIZATION']) && !empty($_SERVER['HTTP_AUTHORIZATION']))<br />
$_SERVER['AUTHORIZATION'] = $_SERVER['HTTP_AUTHORIZATION'];<br />
<span style="background-color:lightsalmon">- if (isset($_SERVER["<span style="color:red">AUTHORIZATION</span>"]) && !empty($_SERVER["<span style="color:red">AUTHORIZATION</span>"])) {</span><br />
<span style="background-color:lightsalmon">- list ($type, $cred) = <span style="color:red">split</span> (" ", $_SERVER['<span style="color:red">AUTHORIZATION</span>']);</span><br />
<span style="background-color:lightgreen">+ if (isset($_SERVER["<span style="color:green">REDIRECT_HTTP_AUTHORIZATION</span>"]) && !empty($_SERVER["<span style="color:green">REDIRECT_HTTP_AUTHORIZATION</span>"])) {</span><br />
<span style="background-color:lightgreen">+ list ($type, $cred) = <span style="color:green">explode</span> (" ", $_SERVER['<span style="color:green">REDIRECT_HTTP_AUTHORIZATION</span>']);</span><br />
if ($type == 'Basic') {<br />
list ($user, $pass) = explode (":", base64_decode($cred));<br />
$_SERVER['PHP_AUTH_USER'] = $user; }<br />
<br />
<br />
=== Webspace aktivieren ===<br />
<br />
Schließlich muß die Installation noch mit dem Webspace verknüpft werden.<br />
<pre><nowiki><br />
$ cd ~/doms/cal.example.org<br />
$ rm -r htdocs-ssl<br />
$ ln -s var/davical/htdocs htdocs-ssl<br />
</nowiki></pre><br />
<br />
[[Bild:DAViCAl-home.png|miniatur|400px|right|Die Login-Seite der DAViCal-Web-Oberfläche]]<br />
<br />
Die URL des User-Interfaces lautet jetzt '''<tt><nowiki>https://cal.example.org/</nowiki></tt>'''.<br />
<br />
Wenn alles richtig gemacht wurde, erscheint an dieser URL die Login-Seite.<br />
<br />
Falls nicht, sorge mit <tt>chmod a+rx var/davical/htdocs</tt> dafür, daß das Verzeichnis für Apache lesbar ist, und kontrolliere notfalls auch die Rechte der darin befindlichen Dateien.<br />
<br />
== Nutzung ==<br />
<br />
=== User anlegen und konfigurieren ===<br />
<br />
Im User-Interface muß man sich als Admin (oder Nutzer mit Adminrechten) einloggen um neue Nutzer anzulegen.<br />
<br />
Um einen neuen Nutzer anzulegen: '''Menu''' &rarr; '''User Functions''' &rarr; '''Create Principal'''<br />
<br />
{| class="wikitable"<br />
|- class="hintergrundfarbe5"<br />
! Feld !! Wert !! Beschreibung<br />
|-<br />
| Principal ID || ''New Principal'' || Bei neuen Nutzern wird das Feld automatisch beim Anlegen gefüllt<br />
|-<br />
| Username || hans || Nutzername für den Kalender. Der Username ist Bestandteil der Kalender-URL<br />
|-<br />
| Change Password || geheimespasswort || <br />
|-<br />
| Confirm Password || geheimespasswort || <br />
|-<br />
| Fullname || Hans Meier || Der Name des Nutzers<br />
|-<br />
| Email Address || hans@example.org || Über die E-Mail-Adresse ist der Nutzer für andere Nutzer im System zu finden, z.B. für Einladungen<br />
|-<br />
| Locale || Deutsch || <br />
|-<br />
| Date Format Style || European || <br />
|-<br />
| Principal Type || Person || Üblicherweise Person für einen natürlichen Nutzer (hier können auch Ressourcen und Gruppen angelegt werden)<br />
|-<br />
| Administrator || &ndash; || Falls der User Adminrechte bekommen soll<br />
|-<br />
| Active || X || Soll der Nutzer aktiv geführt werden?<br />
|}<br />
<br />
Beim Anlegen des '''ersten''' Nutzers erscheint eine Fehlermeldung: <br />
<br />
<span style="background-color:lightsalmon">ERROR: SQL error "23505" - ERROR: duplicate key value violates unique constraint "principal_pkey"" <br />
Home calendar added. </span><br />
<br />
Dies ist ein Bug. Siehe auch [http://lists.morphoss.com/pipermail/davical-dev/2011/000117.html Thread in Dev-Mailingliste].<br />
<br />
Zum Umgehen des Bugs einfach den Nutzer nochmal anlegen und dann funktioniert alles ;-)<br />
<br />
=== Zugriff über Client-Programme ===<br />
<br />
Der Zugriff auf den Kalender erfolgt über die URL: '''<tt><nowiki>https://cal.example.org/caldav.php/user/home</nowiki></tt>'''<br />
<br />
* user = Name des angelegte Nutzers, also z.B. '''<tt>hans</tt>'''<br />
* home = Name des angelegten Kalenders; dies ist standardmäßig '''<tt>home</tt>'''. Andere Kalender (''collection'') können im User-Interface vom Nutzer angelegt werden, oder durch einen Client, der MKCALENDAR implementiert hat, so z.B. iCal oder Mulberry<br />
<br />
==== Beispiel Thunderbird ====<br />
<br />
Ist in Thunderbird die Lightning-Erweiterung installiert, dann kann der Kalender folgendermaßen eingerichtet werden:<br />
<br />
'''Menu''' &rarr; '''Datei''' &rarr; '''Neu''' &rarr; '''Kalender'''<br />
<br />
Auf den Folgenden Seiten ist auszuwählen:<br />
* ''Im Netzwerk''<br />
* ''CalDAV''<br />
* Spezifische Angaben<br />
** Name: z.B. ''hans@example''<br />
** Farbe: auswählen in welcher Farbe der Kalender angezeigt werden soll<br />
** Alarm: ja<br />
** Email: E-Mail auswählen<br />
<br />
Zusätzlich wird es wahrscheinlich noch eine Wahrnung geben, daß das SSL-Zertifikat ungültig ist, da in der Standard Hostsharing Konfiguration das hostsharing-Zertifikat ausgeliefert wird. Dieses muß dann noch importiert und akzeptiert werden.<br />
<br />
Thunderbird fragt dann noch nach Nuternamen und Passwort und wenn man erlaubt diese im Programm zu speichern, dann loggt sich Thunderbird zukünfitg selbständig ein.<br />
<br />
===== Mehrere Kalender auf gleichem Server =====<br />
<br />
Hat man mehrere Kalender auf dem gleichen Server &ndash; also z.B. mehrere User oder für einen User mehrere ''collections'', dann kann Thunderbird diese nicht unterscheiden. Der Passwort-Manager arbeitet auf Grundlage der Domain. Siehe auch [https://bugzilla.mozilla.org/show_bug.cgi?id=247486 Bugzilla].<br />
<br />
Diesen Bug kann man relativ einfach umgehen, indem man weitere Subdomains anlegt, die auf die gleiche Installation verweisen, also z.B.<br />
<br />
<pre><nowiki><br />
$ cd /home/doms/example.org/subs-ssl<br />
$ mkdir cal1<br />
$ mkdir cal2<br />
</nowiki></pre><br />
<br />
und jeweils eine <tt>.htaccess</tt> in die neuen Verzeichnis mit folgendem Inhalt schreibt:<br />
<br />
<pre><nowiki><br />
RewriteEngine on<br />
RewriteRule ^.htaccess$ - [F]<br />
RewriteRule ^(.*)$ https://cal.example.org/$1 [P]<br />
</nowiki></pre><br />
<br />
Nicht vergessen:<br />
<br />
<pre><nowiki><br />
chmod 0644 cal1/.htaccess<br />
chmod 0644 cal2/.htaccess<br />
</nowiki></pre><br />
<br />
<br />
Hat man z.B. für User <tt>hans</tt> die Kalender <tt>home</tt> und <tt>work</tt> und für User <tt>maria</tt> den Kalender <tt>home</tt> und möchte diese aus derselben Thunderbird-Instanz benutzen, können folgende URL's in Thundebrird konfiguriert werden:<br />
<br />
* '''<tt><nowiki>https://cal.example.org/caldav.php/hans/home</nowiki></tt>'''<br />
* '''<tt><nowiki>https://cal1.example.org/caldav.php/hans/work</nowiki></tt>'''<br />
* '''<tt><nowiki>https://cal2.example.org/caldav.php/maria/home</nowiki></tt>'''<br />
<br />
== URL Rewriting für kürzere URL's ==<br />
<br />
TODO: .htaccess Beispiel<br />
<br />
== Weiterführende Links ==<br />
<br />
* WIKI von DAViCal: http://wiki.davical.org<br />
** [http://wiki.davical.org/w/CalDAV_Clients CalDAV Clients]<br />
<br />
* Alternativen<br />
** [[RadicaleCalDAVServer]]<br />
** [[ChandlerServer]]<br />
<br />
----<br />
[[Kategorie:HSDoku]]<br />
[[Kategorie:Installationsanleitungen]]<br />
[[Kategorie:CalDAV]]</div>Apc00-tonyhttps://wiki.hostsharing.net/index.php?title=Benutzer:Apc00-tony/Dynamisches_DNS&diff=6414Benutzer:Apc00-tony/Dynamisches DNS2024-02-08T19:12:40Z<p>Apc00-tony: Veraltet-tag bei Adminsitration</p>
<hr />
<div>Update 2023: Ich habe die Verwaltung über Befehlszeile durch eine PHP-Web-Oberfläche ersetzt; Details irgendwo ... ah, [https://ddns.crawfords.de/verwaltung/ddnsadminhints?name=acanthus_crawford_berlin hier]. Meine Hostsharing-DDNS-Lösung läuft übrigens schon lange einwandfrei; ich benutze sie dazu, ein VPN zwischen meinen Fritz!Box-LANS zu Hause und im Büro zu realisieren sowie um auf ein Backup- und Music-Server (ein Raspberry Pi) zu Hause von unterwegs zuzugreifen.<br />
<br />
((Provisorischer Vorspann: Auf Grund einer Mailing-Listen-Diskussion habe ich angefangen, Dynamisches DNS über einen CGI-Skript bei Hostsharing zu realisieren. Meine Lösung habe ich dann vorgestellt; sie wurde für nicht ausreichend selbsterklärend befunden und fand wenig Akzeptanz. Hier also der Versuch, die Sache zu dokumentieren.))<br />
<br />
Mit der regelmäßigen Aufnahme von benutzerspezifischen Zonefiles in seiner DNS-Konfiguration bietet Hostsharing alles, was man braucht, um &bdquo;dynamisches DNS&ldquo; in Eigenregie zu realisieren.<br />
<br />
Das heißt, wenn ich mindestens eine Domain bei Hostsharing verwalte, und mindestens eine Einwahlverbindung (oder DSL-Verbindung) ins Internet mit wechselnder IP-Adresse über irgendeinen ISP für meinen Arbeitsplatzrechner zu Hause betreibe, dann kann ich dem Arbeitsplatzrechner über die DNS-Server von Hostsharing einen vollqualifizieren Domainnamen zuweisen, der der jeweiligen IP-Adresse meiner Einwahlleitung zugeordnet ist.<br />
<br />
<pre><br />
<br />
(ASCII-Art-Diagramm der beschriebenen Konstellation)<br />
<br />
</pre><br />
<br />
Im Folgenden wird eine real existierende Implementierung von Dynamischem DNS (&bdquo;DDNS&ldquo;) beschrieben. Die verschiedenen Elemente könnten durchaus anders realisiert werden; die beschriebene Implementierung könnte durchaus verbessert werden. Sie dient hier der Illustration.<br />
<br />
In der folgenden Beschreibung werden diese Beispielwerte benutzt:<br />
* Ein Hostsharing-Mitglied hat ein Account als Paket-Admin mit Kennung xyz00.<br />
* Im Paket xyz00 gibt es einen Domain-Admin namens xyz00-benutzername.<br />
* Dieser Domain-Admin verwaltet bei Hostsharing die Domains example.com und beispiel.de.<br />
* Ein Benutzer hat zu Hause (oder im Büro) einen Arbeitsplatzrechner hinter der marktüblichen DSL-Leitung, die von seinem ISP bereitgestellt wird.<br />
* Dieser Arbeitsplatzrechner (oder der Router, der seine Internetverbindung steuert) bekommt vom ISP immer wechselnde IP-Adressen zugewiesen.<br />
* Dennoch möchte der Benutzer seinen Arbeitsplatzrechner aus dem Internet unter dem Hostnamen einwahl.example.com ansprechen können.<br />
<br />
Dazu kann ein System wie Hostsharing, das authoritative DNS-Informationen für viele Domains bereitstellt, auch veränderliche DNS-Information über dynamisch verbundene Rechner verwalten &ndash; sofern das ressourcenschonend gemacht werden kann ohne andere Funktionen zu stören.<br />
<br />
== Aufgaben des Servers ==<br />
<br />
Um einem Rechner mit wechselnder IP-Adresse einen DDNS-Eintrag zu bieten, muß der Hostsharing-Server folgendes leisten (in ungefährer Reihenfolge der Ereignisse):<br />
<br />
# Eine Anfrage entgegennehmen, beispielsweise über HTTPS, von einem entfernten Rechner, der einen DNS-Eintrag für seine momentane IP-Adresse wünscht. <br />
# Prüfen, ob die Anfrage einen berechtigten DDNS-Dienst-Usernamen mit zugehörigem Paßwort enthält.<br />
# Prüfen, ob die Anfrage einen gültigen Domainnamen betrifft, den der Server bieten darf.<br />
# Prüfen, ob die Domain example.com demselben Benutzer gehört, unter dessen Namen der Dynamisches-DNS-Server läuft.<br />
# Eine gültige [[Zonefile]] mit &ndash; neben dem bisherigen Inhalt &ndash; einem A-Eintrag für einwahl.example.com in /home/pacs/xyz00/users/benutzername/doms/example.com/pri.example.com schreiben.<br />
# Dem Client eine Bestätigung oder ggf. eine Fehlermeldung als Antwort senden.<br />
# In irgendeiner Datenbank den momentan eingestellter Status all seiner DDNS-Einträge speichern.<br />
# In einer Logdatei protokollieren, daß obiges getan wurde, oder ggf. welche Fehler traten auf.<br />
<br />
== Aufgaben des Clients ==<br />
Bevor ich anfange, meinen Arbeitsplatzrechner so zu konfigurieren, daß er bei welchem Server auch immer einen DDNS-Eintrag anfordert, muß ich mich als verantwortlicher Benutzer dieses Rechners und der dazugehörigen Internetverbindung &ndash; das heißt, als Mensch &ndash; mit dem Betreiber des dynamisches-DNS-Servers vereinbaren, daß ich das darf und welchen Eintrag ich bekommen kann. Im Folgenden wird vorausgesetzt, daß solche Vereinbarungen getroffen und die Parameter geklärt wurden.<br />
<br />
Der DDNS-Client muß aus Server-Sicht nur wenig leisten:<br />
<br />
# Eine Anfrage senden, beispielsweise über HTTPS, an einen entfernten Rechner, der einen Eintrag ins DNS für die momentane IP-Adresse des Clients vornehmen kann.<br />Diese Anfrage muß einem festgelegten Format entsprechen und muß gültige Werte für die Authorisation des Clients, den gewünschten Domainnamen, und eventuell andere Parameter enthalten.<br />
# Eine Antwort des Servers entgegennehmen und als Erfolgs- oder Fehlermeldung auswerten.<br />
# Von überflüssigen Anfragen absehen: das heißt bei Erfolg, nicht wiederholt den gleichen Eintrag erneut wünschen; bei Fehlern, nicht die gleiche fehlerhafte Anfrage erneut schicken.<br />
<br />
== Kommunikation zwischen Client und Server ==<br />
<br />
Ein einziges Nachrichtenpaar von Anfrage und Antwort genügt, um einen DDNS-Eintrag einzurichten: Der Client teilt die IP-Adresse und den Domainnamen mit, die in einem DNS-Eintrag verbunden werden sollen; der Server bestätigt den Auftrag.<br />
<br />
In der Beispielimplementierung erfolgt die Kommunikation über HTTP, und die Anfrage des Clients könnte so aussehen:<br />
<br />
GET /cgi-bin/ddns?hostname=einwahl.example.com&myip=87.65.43.21 HTTP/1.1<br />
Host: ddns.beispiel.de<br />
User-Agent: Fritz!Box DDNS/1.0.1<br />
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==<br />
<br />
Bei Erhalt dieser Anfrage ruft Apache das CGI-Programm .../doms/ddns.beispiel.de/cgi-ssl/ddns auf. Das Fragezeichen trennt den Programmnamen von einem "Query-String", in dem zwei Metavariablen definiert und übergeben werden. Die erste Metavariable, hostname, hat den Wert "einwahl.example.com"; die zweite, myip, hat den Wert "87.65.43.21".<br />
<br />
Das Server-Programm, hier ''ddns'', prüft diese Informationen auf Form und Berechtigung, und schreibt gegebenenfalls einen entsprechenden Eintrag in einer Zonefile. Es schreibt auch verschiedene Informationen in die Standardausgabe. Wenn es die Standardausgabe geschlossen wird &ndash; also spätestens bei Programmende &ndash; schickt Apache diese Informationen als Antwort an den anfragenden Rechner zurück.<br />
<br />
Im Falle unserer Beispielimplementierung sieht die Antwort bei Erfolg so aus: <br />
<br />
HTTP/1.1 200 OK<br />
Date: Wed, 22 Apr 2020 08:35:15 GMT<br />
Server: Apache<br />
Content-Length: 17<br />
Content-Type: text/plain; charset=ISO-8859-1<br />
<br />
good 87.65.43.21<br />
<br />
=== Das DDNS-Protokoll von DynDNS.org ===<br />
<br />
In den 90er Jahren, bevor das Internet so durchgehend vergeschäftlicht wurde, boten einige Organisationen kostenlose DDNS-Dienste an. Ein sehr beliebtes Angebot war das von DynDNS.org. Das DDNS-Protokoll von diesem Dienst wurde sogar in Einwahl-Routern einprogrammiert und der Dienst wurde von ISPs und Router-Herstellern als Leistungsmerkmal beworben.<br />
<br />
DynDNS.org gehört inzwischen Oracle und bietet keine kostenlose Dienste mehr. Dennoch wird das DDNS-Protokoll von DynDNS.org in der vorliegenden Beispielimplementierung übernommen in der Hoffnung, daß die Kompatibilität mit einigen gängigen Einwahl-Routern von Vorteil sein kann. Es gibt noch eine kurze Online-Dokumentation der [https://help.dyn.com/remote-access-api/perform-update/ Anfrage] und [https://help.dyn.com/remote-access-api/perform-update/ Antwortnachrichten].<br />
<br />
Das gesammte Protokoll sieht einen einzigen Nachrichtenaustausch aus Anfrage und Antwort vor. Die Anfrage kann mehrere Argumente enthalten; die Antwort kann verschiedene Code-Wörtern enthalten. Übrigens können in einer einzigen Anfrage mehrere DNS-Einträge gewünscht werden. In diesem Fall kann die Antwort mehrzeilig ausfallen.<br />
<br />
Das Verhalten von Server und Client bei künftigen Kommunikationsvorgängen wird unter Umständen von vorangegangenen Kommunikationsergebnissen beeinflußt: nach wiederholten fehlerhaften oder redundanten Anfragen kann der Server weitere Anfragen des Benutzers verweigern; nach wiederholten Fehlermeldungen sollte ein Client aufhören, immer dieselbe Anfrage zu schicken. Und für den Fall, daß mehrere Clients dynamische DNS-Einträge in derselben Domain example.com bestellen, muß der Server den Stand aller Client-Einträge intern speichern, damit er nicht mit einer neuen Zonefile einen früher erstellten Eintrag löscht. Zu diesen Fragen siehe den Abschnitt '''[[#Sukzessive_Kommunikationsabläufe]]''' nach der Beschreibung von Anfragen und Antworten unten.<br />
<br />
====Anfrage====<br />
<br />
Die Anfrage in Form eines URL übergibt dem DDNS-Programm in einem 'Query-String' einige Metavariablen. Das heißt, in einem URL der Form<br />
<br />
<nowiki>https://benutzername:passwort@ddns.beisiel.de/cgi-bin/ddns?hostname=einwahl.example.com&myip=87.65.43.21</nowiki><br />
<br />
signalisert das Fragezeichen, daß ein Query-String folgt. In einem solchen Query-String können in der Beispielimplementierung folgende Metavariablen definiert werden:<br />
<br />
{| class="wikitable"<br />
|- class="hintergrundfarbe5"<br />
! Variable !! Beispiel !! Bemerkungen<br />
|-<br />
| hostname || <tt>hostname=einwahl.example.com</tt><br /><div style="font-size:smaller;"><tt>hostname=eins.example.com,zwei.example.com[,...]</tt></div> ||<br />
Muß ein vollständig qualifizierter Domain-Name ("FQDN") sein; <tt>example.com</tt> muß eine vom Besitzer des DDNS-Programms verwaltete Domain sein. Genaugenommen kann der Wert eine durch Kommata gegliederte Liste mehrerer gültiger Domainnamen sein, falls mehrere Einträge mit derselben IP-Adresse gewünscht werden.<br />
|-<br />
| myip || <tt>myip=87.65.43.21</tt>||<br />
Kann entfallen; kann vom Server ignoriert werden. Maßgeblich ist dann die IP-Adresse des Absenders, wie sie vom Web-Server mitgeteilt wird.<br />
|-<br />
| mx || <tt>mx=87.65.43.21</tt><br /><tt>mx=NOCHG</tt><br /> ||<br />
Neben dem A-Eintrag möchte der Client auch einen MX-Eintrag. Der Wert <tt>NOCHG</tt> (für &bdquo;no change&ldquo;) bedeutet, der bestehende MX-Eintrag (oder seine Abwesenheit) soll nicht geändert werden. <br />
|-<br />
| backmx || <tt>backmx=YES</tt><br /><tt>backmx=NOCHG</tt><br /><tt>backmx=NO</tt> ||<br />
Falls <tt>YES</tt>, wird ein zweiter MX-Eintrag erzeugt, der <tt>einwahl.example.com</tt> als Mail-Server für <tt>einwahl.example.com</tt> nennt. Dieser Eintrag hat eine niedrigere Präferenzzahl (also eine höhere Priorität) als der mit <tt>mx</tt> angeforderten Eintrag.<br />
|-<br />
| wildcard || <tt>wildcard=ON</tt><br /><tt>wildcard=NOCHG</tt><br /><tt>wildcard=OFF</tt> ||<br />
Neben dem A-Eintrag für den Domainnamen <tt>einwahl.example.com</tt> wünscht der Client auch einen Eintrag für beliebige Subdomains, also <tt>*.einwahl.example.com</tt>, mit der gleichen IP-Adresse.<br />
|-<br />
| offline ||<tt>offline=YES</tt><br /><tt>offline=NOCHG</tt>||<br />
Falls <tt>YES</tt>, wird ein DNS-Eintrag für <tt>einwahl.example.com</tt> aus der Zonefile getilgt. Gegebenenfalls wird der Hostname dann auf Grund eines parallelen Wildcard-Eintrags für <tt>*.example.com</tt> einer anderen IP-Adresse zugeordnet werden.<br />
|}<br />
<br />
<!-- IPv6? --><br />
<br />
Alle Parameter bis auf hostname können entfallen. Bei nichtdokumentierten Argumenten ist das Verhalten undefiniert&trade;.<br />
<br />
====Antwort====<br />
<br />
Die Antwort auf eine erfolgreiche HTTP-Anfrage besteht im häufigsten Fall aus einigen Header-Zeilen, gefolgt vom Inhalt der gewünschten Text- oder andere Datei. Ein Status-Code in der ersten Header-Zeile gibt an, ob die Anfrage bedient werden kann oder kreist andernfalls den Grund für die Enttäuschung ein.<br />
<br />
Die vorliegende Beispielimplementierung von DDNS schickt einen der üblichen HTTP-Status-Codes "200 OK" oder "500 Internal Server Error", gefolgt von einer kurzen Textnachricht nach dem HTTP-Header. Bei diesem Programm ist &ndash; laut Gebrauchshinweise von DynDNS.org &ndash; ''nicht'' der Status-Code im Header, sondern der Inhalt der Nachricht die definierte, maßgebliche Ergebnismeldung des Programms.<br />
<br />
{| class="wikitable"<br />
|- class="hintergrundfarbe5"<br />
! Meldung !! Bedeutung !! Bemerkungen<br />
|-<br />
| <tt>good&nbsp;&lt;IP&nbsp;number&gt;</tt> ||<br />
Der gewünschte DNS-Eintrag wurde erfolgreich in einer Zonefile eingetragen. <br />
|| Es kann natürlich noch einige Minuten dauern, bis die Zonefile vom Hostsharing-Roboter abgelesen wird und der Inhalt in die BIND-Konfiguration übernommen.<br />
|-<br />
| <tt>good&nbsp;0.0.0.0</tt> ||<br />
Das Argument <tt>offline=YES</tt> wurde empfangen und verarbeitet.<br />
|| Der Domainname hat also keinen dynamischen DNS-Eintrag mehr.<br />
|-<br />
<!-- We don't do this!<br />
| <tt>good&nbsp;127.0.0.1</tt> ||<br />
Die Anfrage entsprach nicht den Erfordernissen des Servers.<br />
|| Trotz des Worts <tt>good</tt> war die Anfrage nicht erfolgreich, falls in der Rückmeldung die IP-Adresse mit <tt>127.0.0.1</tt> angegeben wird. Dieser verwirrende Fehlercode ist aus unerklärlichen Gründen in der Spezifikation von DynDNS.org so definiert.<br />
|-<br />
--><br />
| <tt>nochg&nbsp;&lt;IP&nbsp;number&gt;</tt> ||<br />
Der gewünschte DNS-Eintrag war bereits vorhanden. <br />
|| Der Server selbst macht keine DNS-Abfrage, um das zu vermitteln: die &bdquo;no change&ldquo;-Antwort besagt nur, daß eine Anfrage für diesen Eintrag bereits mit Erfolg quittiert wurde.<br />
|-<br />
| <tt>notfqdn</tt> ||<br />
Fehlschlag: der gewünschte Domainname ist nicht gültig, oder es wurde keiner angegeben.<br />
|| ...<br />
|-<br />
| <tt>nohost</tt> ||<br />
Fehlschlag: der gewünschte Domainname ist gehört nicht zu denen, die für diesen Benutzer des DDNS-Dienstes konfiguriert sind.<br />
|| Siehe den Abschnitt [[#Administration|Administration]] weiter unten.<br />
|-<br />
| <tt>badauth</tt> ||<br />
Fehlschlag: Die Kombination von Benutzernamen und Paßwort entsprach keinem DDNS-Account, oder das Account ist momentan gesperrt.<br />
|| Ein gesperrtes Account kann nur der Domain-Admin mittels des Administrationswerkzeugs wieder freigeben: siehe den Abschnit [[#Administration|Administration]] weiter unten.<br />
|-<br />
| <tt>abuse</tt> ||<br />
Fehlschlag: der gewünschte Domainname ist wegen vorangeganger Fehlschläge oder überflüssiger Aufrufe gesperrt.<br />
|| Siehe den Abschnitt [[#Sukzessive_Kommunikationsabläufe|Sukzessive Kommunikationsabläufe]] unten.<br />
|-<br />
| <tt>911</tt> ||<br />
Fehlschlag: Das Server-Programm hat einen internen Fehler festgestellt.<br />
|| Das Problem liegt nicht in der Anfrage an sich.<br />
|}<br />
<br />
Man kann sich durchaus eine sinnreichere Kommunikation zwischen Client und Server vorstellen, doch das hier beschriebene Protokoll ist eben von DynDNS.org verwendet worden und wird in gängigen Routern implementiert, also wird es in der vorliegenden DDNS-Implementierung nachgebildet.<br />
<br />
=== Sukzessive Kommunikationsabläufe ===<br />
Der Server muß sich zwischen einzelnen Aufrufen einiges merken, um Ressourcen zu schonen und um zu verhindern, daß einmal vergebene DDNS-Einträge von neuen Anfragen, die dieselbe übergeordnete Domain betreffen, durch Überschreiben verlorengehen.<br />
<br />
==== Mißbrauch und Benutzersperrung ====<br />
Zur Schonung von Ressourcen muß sich die Implementierung weigern, sich mit zuvielen fehlerhaften oder auch nur überflüssigen Anfragen zu beschäftigen. Dazu führt der Server eine Strichliste über solche Anfragen jedes Clients und sperrt nach einer bestimmten Anzahl solcher Anfragen den Benutzernamen oder einzelne Domainnamen gegen die weitere Nutzung des Dienstes.<br />
<br />
Mißbrauchspunkte gegen einen einzelnen Domainnamen gibt es für:<br />
* eine Anfrage, die keinen neuen DNS-Eintrag (und keine Änderung oder Löschung eines Eintrags) erfordert, sondern bestehende Merkmale nur wiederholt<br />
<br />
Mißbrauchspunkte gegen einen Benutzernamen gibt es für:<br />
* die Angabe eines Domainnamens, der in der Dienstkonfiguration dem anfragenden Benutzernamen nicht zugeordnet ist<br />
* die Angabe eines Domainnamen in einer Domain, die nicht demselben Hostsharing-Domain-Admin gehört, der den DDNS-Dienst anbietet<br />
* die Angabe eines Domainnamens, der in der Dienstkonfiguration bereits wegen mißbräuchlicher Anfragen gesperrt ist (siehe oben)<br />
<br />
Um eine Sperrung aufzuheben, wird in der Regel eine Handlung durch den Administrator erforderlich sein.<br />
<br />
==== Mehrere dynamische Subdomains in derselben Domain ====<br />
Sobald zwei verschiedene DDNS-Einträge in derselben Domain verlangt werden &ndash; beispielsweise home.example.com und office.example.com &ndash; wird es notwendig, bei jeder neuen Zonefile für example.com eventuell frühere Einträge zu konservieren. Der Rechner zu Hause weiß beim Bestellen seines DDNS-Eintrags nichts vom Rechner im Büro und umgekehrt. Der Server muß in irgendeiner Form über bereits vergebene Einträge Buch führen und bei einer neuen Anfrage, die example.com betrifft, alle bereits aktiven DDNS-Einträge für example.com mit in die neue Zonefile aufnehmen &ndash auch wenn sie auf Anfragen verschiedener Benutzer zurückgehen.<br />
<br />
==== Datenbank ====<br />
In der Beispielimplementierung werden diese Informationen in einer SQLite-Datenbank gespeichert.<br />
<br />
== Sicherheit ==<br />
=== Rechte ===<br />
Die '''Benutzerrechte''' werden durch das Hostsharing-System kontrolliert. Sowohl das CGI-Programm als auch das [[#Administration|Administrationswerkzeug]] werden mit den Rechten des Domain-Admins (xyz00-benutzername in unserem Beispiel) ausgeführt, also kann dieses Programm nur die Domains bearbeiten, die von xyz00-benutzername verwaltet werden.<br />
<br />
=== Authentifizierung ===<br />
In der Beispielimplementierung (wie auch seinerzeit bei DynDNS.org) wird das CGI-Programm durch einen .htaccess-Eintrag geschützt, der HTTP-Basic-Authentication vorschreibt. Also wird das Programm eigentlich mit einem URL der form<br />
<br />
<nowiki>https://ddnsaccount:passwort@ddns.example.com/cgi-bin/ddns?hostname=...</nowiki><br />
<br />
aufgerufen.<br />
<br />
=== Verschlüsselung ===<br />
Das CGI-Programm sollte nur in example.com/cgi-ssl/ installiert werden, nicht in example.com/cgi/. Damit ist die Kommunikation zwischen Client und Server durch SSL verschlüsselt.<br />
<br />
== Administration ==<br />
<br />
Der Verwalter des DDNS-Programms trägt berechtigte Benutzer und die ihnen zugeteilten Domainnamen in die Datenbank des Programms ein mit Hilfe eines kleinen Hilfsprogramms. Das ist im vorliegenden Fall ein menügesteuertes Programm für die Befehlszeile, daß die naheliegenden Funktionen anbietet: Account hinzufügen, löschen, sperren, entsperren, Paßwort setzen, ändern; Domainnamen hinzufügen, ändern, entsperren, löschen; Accounts und Domainnamen mit aktuellem Status auflisten. Die Funktionen sind auch über Befehlszeilenargumente verfügbar, also skriptfähig.<br />
<br />
Eine Übersicht der Funktionen des Administrationswerkzeugs gibt dieses selbst aus:<br />
<br />
'''Achtung, veraltet: inzwischen ist die Verwaltungsoberfläche für<br />
die hier beschriebene Implementierung web-basiert.'''<br />
<br />
<pre><br />
xyz00-benutzername@h02:~$ bin/ddnsadmin -h<br />
ddnsadmin.pl: Verwaltungswerkzeug für ddns<br />
<br />
Verwendung:<br />
ddnsadmin -A{[ahlusf]} [<Account>] [-f <DB-Datei>]<br />
ddnsadmin -D{[ahlsf]} [<Domain>] -A <Account> [-f <DB-Datei>]<br />
ddnsadmin -E <Einstellung> <Wert> [-f <DB-Datei>]<br />
ddnsadmin [-f <DB-Datei>] [-n]<br />
<br />
Wenn keine Option oder nur -f <DB-Datei> angegeben wird, bietet<br />
ddnsadmin.pl eine interaktive Menüoberfläche.<br />
<br />
Optionen:<br />
-f <DB-Datei> Angegebene Datenbankdatei verwenden<br />
-n Neue, leere Datenbank erzeugen<br />
-Aa [<Account>] Account(s) auflisten<br />
-Ah <Account> <Paßwort> Account hinzufügen<br />
-A{lsf} <Account> Account löschen, sperren, freigeben<br />
-Au <Account> <Name> Account umbenennen<br />
-A <Account> -Da [<Domain>] Domain(s) auflisten<br />
-A <Account> -D{hlsf} <Domain> Domain hinzufügen,<br />
löschen, sperren, freigeben<br />
-E <Einstellung> <Wert> Einstellung ändern<br />
-h Diese Übersicht ausgeben<br />
<br />
Einstellungen: <br />
maxacctabuse Anzahl der mißbräuchlichen Aufrufe,<br />
bevor ein Account gesperrt wird<br />
maxhostabuse Anzahl der mißbräuchlichen Aufrufe,<br />
bevor ein Domainname gesperrt wird<br />
safeinterval Mindestabstand zwischen redundanten Aufrufen<br />
(in Sekunden)<br />
cgihost Server, der das DDNS-Skript bereithält<br />
<br />
xyz00-benutzername@h02:~$ <br />
</pre><br />
<br />
Eine Auflistung des momentanen Inhalts der DDNS-Datenbank durch das Administrationswerkzeug könnte beispielsweise so aussehen:<br />
<br />
<pre><br />
xyz00-benutzername@h02:~$ bin/ddnsadmin.pl -Aa<br />
1. papst Mißbrauch: 0; gesperrt: nein<br />
avignon.example.com<br />
zuletzt aktiv am Sun Apr 26 22:24:49 2020<br />
mit IP-Nr. 87.65.43.21; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 0; gesperrt: nein<br />
vatican.beispiel.de<br />
zuletzt aktiv am Sun Apr 26 22:24:49 2020<br />
mit IP-Nr. 87.65.43.21; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 0; gesperrt: nein<br />
2. kaiser Mißbrauch: 4; gesperrt: ja<br />
augsburg.beispiel.de<br />
zuletzt aktiv am Fri Apr 24 16:13:49 2020<br />
mit IP-Nr. 64.82.31.75; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 0; gesperrt: ja<br />
3. luther Mißbrauch: 1; gesperrt: nein<br />
wittenberg.example.com<br />
zuletzt aktiv am Mon Apr 27 10:12:49 2020<br />
mit IP-Nr. 78.56.34.12; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 1; gesperrt: nein<br />
xyz00-benutzername@h02:~$<br />
</pre><br />
<br />
Das DDNS-Account &bdquo;kaiser&ldquo; in dieser Auflistung ist wohl auf Grund fehlerhafter Anfragen automatisch gesperrt worden. Der Inhaber wird sich wohl bald melden, um nach Korrektur seiner Client-Konfiguration die Aufhebung der Sperre zu wünschen.<br />
<br />
=== Log ===<br />
Alle Anfragen werden in einer täglich wechselnden Log-Datei protokolliert, entweder schlicht oder ausführlich, je nachdem, ob eine Variable <tt>verbose</tt> wahr ist.<br />
Ein ausführlicher Log-Eintrag sieht so aus:<br />
<br />
Sun Apr 26 20:21:45 2020 ddns aufgerufen von papst<br />
unter 84.185.97.8<br />
URL: <nowiki>https://ddns.example.com/cgi-bin/ddns.cgi?hostname=<br />
avignon.example.com,vatican.beispiel.de&<br />
myip=84.185.97.8</nowiki><br />
Verwende IP 84.185.97.8 (= 1421435144)<br />
DB-Version: 1<br />
Skript und DB exklusiv geöffnet<br />
avignon.example.com: IP: 84.185.97.8; MX: 0; Backup-MX: nein;<br />
Wildcard: nein; Mißbrauch: 0; gesperrt: nein <br />
vatican.beispiel.de: IP: 84.185.97.8; MX: 0; Backup-MX: nein;<br />
Wildcard: nein; Mißbrauch: 0; gesperrt: nein <br />
Betroffene Zonen: example.com, beispiel.de<br />
Temporärdatei example.com_hxNa.new geschrieben<br />
Zonendatei /home/pacs/xyz00/users/benutzername/doms/example.com/<br />
etc/pri.example.com eingestellt<br />
Temporärdatei beispiel.de_6HcO.new geschrieben<br />
Zonendatei /home/pacs/xyz00/users/benutzername/doms/beispiel.de/<br />
etc/pri.beispiel.de eingestellt<br />
Abgeschlossen: Fertig<br />
<br />
Wenn <tt>verbose</tt> auf falsch gesetzt ist, sind die Log-Einträge einzeilig.</div>Apc00-tonyhttps://wiki.hostsharing.net/index.php?title=Mlmmj&diff=6411Mlmmj2024-02-04T12:28:38Z<p>Apc00-tony: Paar Details aus E-Mail-Diskussion hinzugefügt</p>
<hr />
<div>[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.<br />
<br />
Wer noch nicht weiß, was ein E-Mail-Verteiler machen soll oder wie, lese veilleicht auch den Wikipedia-Artikel:<br />
[http://de.wikipedia.org/wiki/Mailingliste Mailingliste]<br />
<br />
Eine leistungsfähigere Alternative zu mlmmj könnte [[Mailman_3_installieren|Mailman 3]] sein.<br />
<br />
Diese Anleitung beschreibt die Einrichtung einer Mailingliste für eine Domain in einem Hostsharing-Webspace.<br />
<br />
== Voraussetzungen ==<br />
<br />
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.)<br />
<br />
Für den Betrieb der Mailingliste empfiehlt sich das Anlegen eines eigenen Users für diesen Zweck mit hsadmin.<br />
<br />
In dieser Anleitung heißt das Paket ''xyz00'' und der für Mailinglisten eingesetzte User ''xyz00-list''.<br />
<br />
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''.<br />
<br />
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.)<br />
<br />
== Einrichtung ==<br />
<br />
Ich melde mich über SSH auf der Hostsharing-Console als der Paketuser ''xyz00'' an.<br />
<br />
Im Shell kann ich dann durch den Befehl ''hsscript -i'' das Verwaltungswerkzeug [[hsadmin]] interaktiv ausführen:<br />
<br />
xyz00@h03:~$ hsscript -i<br />
Password: *************<br />
xyz00@hsadmin> <br />
<br />
In ''hsadmin'' werden User und E-Mail-Adresse angelegt.<br />
<br />
xyz00@hsadmin> user.add({set:{name:'xyz00-list',comment:'Mailingliste Discuss',shell:'/bin/bash',password:'geheimnis'}})<br />
xyz00@hsadmin> emailaddress.add({set:{target:'xyz00-list',localpart:'discuss',domain:'example.org'}})<br />
xyz00@hsadmin> bye<br />
<br />
Mit dem Parameter "target" wird die für diese Adresse eingehende Post zunächst in das Postfach des Users xyz00-list abgelegt.<br />
<br />
Für den User xyz00-list lege ich in seinem Heimat-Verzeichnis das Unterverzeichnis <tt>mlmmj</tt> an:<br />
<br />
mkdir /home/pacs/xyz00/users/list/mlmmj<br />
<br />
Dann lege ich die Mailingliste mit folgendem Kommando an:<br />
<br />
mlmmj-make-ml -L discuss -s /home/pacs/xyz00/users/list/mlmmj<br />
<br />
Das Skript ''mlmmj-make-ml'' fragt weitere Parameter der Mailingliste ab:<br />
<br />
The Domain for the List? [] : example.org<br />
The emailaddress of the list owner? [postmaster] : webmaster@example.org<br />
For the list texts you can choose between the following languages or<br />
give an absolute path to a directory containing the texts.<br />
Available languages:<br />
cz da de en es fr it nl ru<br />
The path to texts for the list? [en] : de<br />
<br />
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.<br />
<br />
Weitere Konfigurationen der Liste erfolgen durch das Anlegen von Dateien im<br />
Verzeichnis "/home/pacs/xyz00/users/list/mlmmj/discuss/control".<br />
Die Konfigurationsmöglichkeiten finden Sie auf der [http://mlmmj.org/docs/tunables/ Internetseite von mlmmj].<br />
<br />
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:<br />
<br />
"|/usr/bin/mlmmj-recieve -L /home/pacs/xyz00/users/list/mlmmj/discuss/"<br />
<br />
(Ja, ''receive'' schreibt sich mit ''-ei-'', aber mlmmj hält einen symbolischen Link bereit für diejenigen, die in englischer Rechtschreibung unsicher sind:)<br />
<br />
xyz00-list@h03:~$ ls -la /usr/bin/mlmmj-rec*<br />
-rwxr-xr-x 1 root root 27104 Sep 25 2018 /usr/bin/mlmmj-receive<br />
lrwxrwxrwx 1 root root 13 Sep 25 2018 /usr/bin/mlmmj-recieve -> mlmmj-receive<br />
<br />
Die <tt>.forward</tt>-Datei sorgt dafür, dass eingehende E-Mails an das User-Postfach an das Programm ''mlmmj-recieve'' übergeben werden.<br />
<br />
Für regelmäßige Aufgaben der Listen-Managers definiere ich die<br />
[[Cron|crontab]] wie folgt (immer noch als ''xyz00-list''):<br />
<br />
xyz00-list@h03:~$ crontab -e<br />
<br />
MAILTO=webmaster@example.org<br />
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin<br />
HOME=/home/pacs/xyz00/users/list<br />
SHELL=/bin/bash<br />
LANG=en_US.UTF-8<br />
# m h dom mon dow command<br />
28 */4 * * * /usr/bin/mlmmj-maintd -d /home/pacs/xyz00/users/list/mlmmj -F<br />
<br />
Zum Schluss rufe ich das Skript mlmmj-sub auf, um die E-Mail-Adressen der gewünschten Abonnenten des Verteilers einzutragen:<br />
<br />
/usr/bin/mlmmj-sub -L /home/pacs/xyz00/users/list/mlmmj/discuss -a klaus.muster@gmx.de -c <br />
/usr/bin/mlmmj-sub -L /home/pacs/xyz00/users/list/mlmmj/discuss -a sabine.beispiel@arcor.de -c <br />
<br />
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.<br />
<br />
== weitere Optionen ==<br />
<br />
Noch ein paar Dinge, die Sie möglicherweise einstellen wollen:<br />
<br />
Ein Prefix in der Betreffzeile setzen, z.B.: "[discuss]".<br />
<br />
echo "[discuss]" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/prefix<br />
<br />
Wenn die Liste nur E-Mails von eingetragenen Abonnenten weiterleiten soll:<br />
<br />
touch /home/pacs/xyz00/users/list/mlmmj/discuss/control/subonlypost<br />
<br />
Damit der Listen-Owner weitere Abonnements bestätigen muss:<br />
<br />
touch /home/pacs/xyz00/users/list/mlmmj/discuss/control/submod<br />
<br />
Einen "Reply-To:"-Header setzen, damit Antwort-Mails standardmäßig an die Mailing-Liste gehen:<br />
<br />
echo "Reply-To:" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/delheaders<br />
echo "Reply-To: discuss@example.org" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/customheaders<br />
<br />
Weitere Möglichkeiten finden Sie (wie oben bereits angegeben) <br />
auf der [http://mlmmj.org/docs/tunables/ Internetseite von mlmmj].<br />
<br />
== Zur Konfiguration im Browser ==<br />
<br />
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.<br />
<br />
Wer es sich ansehen möchte:<br />
<br />
Als Paket-Admin eine Domain aufschalten:<br />
<br />
hsscript -u xyz00 -e "domain.add({set:{name:'lists.example.org',user:'xyz00-list'}})"<br />
<br />
Und weiter als "xyz00-list".<br />
<br />
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).<br />
<br />
Unter "/mlmmj-$versionsnummer/contrib/web/php-admin/", oder beim .deb-Paket unter "usr/share/mlmmj-...", findet sich die PHP-Admin-Anwendung. Also ...<br />
<br />
* den Inhalt diese Verzeichnisses nach "/home/pacs/xyz00/users/list/doms/lists.example.org/" packen;<br />
* in "/home/pacs/xyz00/users/list/doms/lists.example.org/conf/config.php" die Variable "$topdir" anpassen;<br />
* 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;<br />
* Beim .deb-Paket die config.php, die templates/ und die tunables.pl aus etc/ nach example.org/conf/ verschieben;<br />
* 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: <br />
<br />
Require valid-user<br />
AuthType Basic<br />
AuthName "mlmmj web-interface"<br />
AuthUserFile /home/pacs/xyz00/users/list/doms/lists.example.org/etc/htpasswd<br />
<br />
* Und schließlich die "htpasswd"-Datei anlegen.<br />
<br />
cd /home/pacs/xyz00/users/list/doms/lists.example.org/etc/<br />
htpasswd -c htpasswd listadmin<br />
<br />
* Ein Passwort angeben.<br />
<br />
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<br />
<br />
* in <tt>.../htdocs-ssl/index.php</tt> folgende Änderung vornehmen:<br />
<br />
@@ -38,4 +38,5 @@<br />
# use scandir to have alphabetical order <br />
foreach (scandir($topdir) as $file) {<br />
- if (!ereg("^\.",$file))<br />
+# ereg obsolete!! Vormals: if (!ereg("^\.",$file))<br />
+ if (!preg_match('/^\./',$file))<br />
{<br />
<br />
und das Ergebnis auf https://lists.example.org anschauen.<br />
<br />
== Mehrere Mailinglisten betreiben ==<br />
<br />
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.<br />
<br />
Dazu trägt man in der Datei <tt>.forward</tt> statt des Aufrufs von ''mlmmj-recieve'' einen Aufruf von ''procmail'' ein:<br />
<br />
|/usr/bin/procmail<br />
<br />
Die Konfiguration von Procmail kann generisch erfolgen. Dazu legt man eine Datei <tt>.procmailrc</tt> mit folgendem Inhalt ins $HOME des Users:<br />
<br />
SHELL=/bin/sh<br />
HOMEDIR=/home/pacs/xyz00/users/list<br />
MAILDIR=/home/pacs/xyz00/users/list/Maildir<br />
PMDIR=/home/pacs/xyz00/users/list<br />
VERBOSE=yes<br />
LOGFILE=/home/pacs/xyz00/users/list/var/procmail.log<br />
DEFAULT<br />
<br />
:0:<br />
* ^X-Original-To: ()\/[^@+]+<br />
|/usr/bin/mlmmj-receive -F -L /home/pacs/xyz00/users/list/mlmmj/${MATCH}/<br />
<br />
:0<br />
{ EXITCODE 67 }<br />
<br />
<br />
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.<br />
<br />
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).<br />
<br />
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.<br />
<br />
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:<br />
<br />
:0:<br />
* ^X-Original-To: ()\/[^@+]+<br />
|/usr/bin/mlmmj-receive -F -L /home/pacs/xyz00/users/list/mlmmj/$(echo ${MATCH} | tr [:upper:] [:lower:])/<br />
<br />
Der Rest der Datei muß gleich bleiben, wie weiter oben angezeigt.<br />
<br />
In diesem Fall müssen aber alle Mailing-Listen ohne Großbuchstaben im Namen angelegt werden!<br />
<br />
(Man kann auch in <tt>${HOME}/mlmmj/</tt> durch kleingeschriebene Symlinks großgeschriebene Listennamen ansprechbar machen:<br />
<br />
xyz00-list@h02:~$ ls -lA mlmmj/<br />
total 8<br />
-rw-r--r-- 1 xyz00-list xyz00 148 Feb 1 16:56 .htaccess<br />
lrwxrwxrwx 1 xyz00-list xyz00 10 Feb 2 18:01 mitglieder -> Mitglieder<br />
drwxr-xr-x 15 xyz00-list xyz00 4096 Feb 2 16:53 Mitglieder<br />
<br />
Das scheint zu funktionieren; Angabe ohne Gewähr.)<br />
<br />
== Links ==<br />
<br />
* http://mlmmj.org/ Projektseite<br />
* https://codeberg.org/mlmmj mlmmj auf Codeberg<br />
* https://github.com/tchapi/mlmmj-simple-web-interface ein Admin-Interface in NodeJS<br />
* https://www.tablix.org/~avian/blog/archives/2010/04/the_faulty_default/ Nutzung von mlmmj in Verbindung mit Procmail<br />
<br />
----<br />
[[Kategorie:HSDoku]]<br />
[[Kategorie:Installationsanleitungen]]<br />
[[Kategorie:Software]]<br />
[[Kategorie:Mailinglisten]]<br />
[[Kategorie:E-Mail]]</div>Apc00-tonyhttps://wiki.hostsharing.net/index.php?title=Mlmmj&diff=6410Mlmmj2024-02-03T10:04:04Z<p>Apc00-tony: /* Zur Konfiguration im Browser */</p>
<hr />
<div>[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.<br />
<br />
Wer noch nicht weiß, was ein E-Mail-Verteiler machen soll oder wie, lese veilleicht auch den Wikipedia-Artikel:<br />
[http://de.wikipedia.org/wiki/Mailingliste Mailingliste]<br />
<br />
Eine leistungsfähigere Alternative zu mlmmj könnte [[Mailman_3_installieren|Mailman 3]] sein.<br />
<br />
Diese Anleitung beschreibt die Einrichtung einer Mailingliste für eine Domain in einem Hostsharing-Webspace.<br />
<br />
== Voraussetzungen ==<br />
<br />
Das Debian Paket [http://packages.debian.org/search?keywords=mlmmj mlmmj] ist auf den Shared-Hosting-Servern bereits installiert.<br />
<br />
Für den Betrieb der Mailingliste empfiehlt sich das Anlegen eines eigenen Users für diesen Zweck mit hsadmin.<br />
<br />
In dieser Anleitung heißt das Paket ''xyz00'' und der für Mailinglisten eingesetzte User ''xyz00-list''.<br />
<br />
Die E-Mail-Adresse der einzurichtende Mailing-Liste soll ''discuss@example.org'' sein.<br />
<br />
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.)<br />
<br />
== Einrichtung ==<br />
<br />
Ich melde mich über SSH auf der Hostsharing-Console als der Paketuser ''xyz00'' an.<br />
<br />
Im Shell kann ich dann durch den Befehl ''hsscript -i'' das Verwaltungswerkzeug [[hsadmin]] interaktiv ausführen:<br />
<br />
xyz00@h03:~$ hsscript -i<br />
Password: *************<br />
xyz00@hsadmin> <br />
<br />
In ''hsadmin'' werden User und E-Mail-Adresse angelegt.<br />
<br />
xyz00@hsadmin> user.add({set:{name:'xyz00-list',comment:'Mailingliste Discuss',shell:'/bin/bash',password:'geheimnis'}})<br />
xyz00@hsadmin> emailaddress.add({set:{target:'xyz00-list',localpart:'discuss',domain:'example.org'}})<br />
xyz00@hsadmin> bye<br />
<br />
Mit dem Parameter "target" wird die für diese Adresse eingehende Post zunächst in das Postfach des Users xyz00-list abgelegt.<br />
<br />
Für den User xyz00-list lege ich in seinem Heimat-Verzeichnis das Unterverzeichnis <tt>mlmmj</tt> an:<br />
<br />
mkdir /home/pacs/xyz00/users/list/mlmmj<br />
<br />
Dann lege ich die Mailingliste mit folgendem Kommando an:<br />
<br />
mlmmj-make-ml -L discuss -s /home/pacs/xyz00/users/list/mlmmj<br />
<br />
Das Skript ''mlmmj-make-ml'' fragt weitere Parameter der Mailingliste ab:<br />
<br />
The Domain for the List? [] : example.org<br />
The emailaddress of the list owner? [postmaster] : webmaster@example.org<br />
For the list texts you can choose between the following languages or<br />
give an absolute path to a directory containing the texts.<br />
Available languages:<br />
cz da de en es fr it nl ru<br />
The path to texts for the list? [en] : de<br />
<br />
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.<br />
<br />
Weitere Konfigurationen der Liste erfolgen durch das Anlegen von Dateien im<br />
Verzeichnis "/home/pacs/xyz00/users/list/mlmmj/discuss/control".<br />
Die Konfigurationsmöglichkeiten finden Sie auf der [http://mlmmj.org/docs/tunables/ Internetseite von mlmmj].<br />
<br />
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:<br />
<br />
"|/usr/bin/mlmmj-recieve -L /home/pacs/xyz00/users/list/mlmmj/discuss/"<br />
<br />
(Ja, ''receive'' schreibt sich mit ''-ei-'', aber mlmmj hält einen symbolischen Link bereit für diejenigen, die in englischer Rechtschreibung unsicher sind:)<br />
<br />
xyz00-list@h03:~$ ls -la /usr/bin/mlmmj-rec*<br />
-rwxr-xr-x 1 root root 27104 Sep 25 2018 /usr/bin/mlmmj-receive<br />
lrwxrwxrwx 1 root root 13 Sep 25 2018 /usr/bin/mlmmj-recieve -> mlmmj-receive<br />
<br />
Die <tt>.forward</tt>-Datei sorgt dafür, dass eingehende E-Mails an das User-Postfach an das Programm ''mlmmj-recieve'' übergeben werden.<br />
<br />
Für regelmäßige Aufgaben der Listen-Managers definiere ich die<br />
[[Cron|crontab]] wie folgt (immer noch als ''xyz00-list''):<br />
<br />
xyz00-list@h03:~$ crontab -e<br />
<br />
MAILTO=webmaster@example.org<br />
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin<br />
HOME=/home/pacs/xyz00/users/list<br />
SHELL=/bin/bash<br />
LANG=en_US.UTF-8<br />
# m h dom mon dow command<br />
28 */4 * * * /usr/bin/mlmmj-maintd -d /home/pacs/xyz00/users/list/mlmmj -F<br />
<br />
Zum Schluss rufe ich das Skript mlmmj-sub auf, um die E-Mail-Adressen der gewünschten Abonnenten des Verteilers einzutragen:<br />
<br />
/usr/bin/mlmmj-sub -L /home/pacs/xyz00/users/list/mlmmj/discuss -a klaus.muster@gmx.de -c <br />
/usr/bin/mlmmj-sub -L /home/pacs/xyz00/users/list/mlmmj/discuss -a sabine.beispiel@arcor.de -c <br />
<br />
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.<br />
<br />
== weitere Optionen ==<br />
<br />
Noch ein paar Dinge, die Sie möglicherweise einstellen wollen:<br />
<br />
Ein Prefix in der Betreffzeile setzen, z.B.: "[discuss]".<br />
<br />
echo "[discuss]" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/prefix<br />
<br />
Wenn die Liste nur E-Mails von eingetragenen Abonnenten weiterleiten soll:<br />
<br />
touch /home/pacs/xyz00/users/list/mlmmj/discuss/control/subonlypost<br />
<br />
Damit der Listen-Owner weitere Abonnements bestätigen muss:<br />
<br />
touch /home/pacs/xyz00/users/list/mlmmj/discuss/control/submod<br />
<br />
Einen "Reply-To:"-Header setzen, damit Antwort-Mails standardmäßig an die Mailing-Liste gehen:<br />
<br />
echo "Reply-To:" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/delheaders<br />
echo "Reply-To: discuss@example.org" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/customheaders<br />
<br />
Weitere Möglichkeiten finden Sie (wie oben bereits angegeben) <br />
auf der [http://mlmmj.org/docs/tunables/ Internetseite von mlmmj].<br />
<br />
== Zur Konfiguration im Browser ==<br />
<br />
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.<br />
<br />
Wer es sich ansehen möchte:<br />
<br />
Als Paket-Admin eine Domain aufschalten:<br />
<br />
hsscript -u xyz00 -e "domain.add({set:{name:'lists.example.org',user:'xyz00-list'}})"<br />
<br />
Und weiter als "xyz00-list".<br />
<br />
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).<br />
<br />
Unter "/mlmmj-$versionsnummer/contrib/web/php-admin/", oder beim .deb-Paket unter "usr/share/mlmmj-...", findet sich die PHP-Admin-Anwendung. Also ...<br />
<br />
* den Inhalt diese Verzeichnisses nach "/home/pacs/xyz00/users/list/doms/lists.example.org/" packen;<br />
* in "/home/pacs/xyz00/users/list/doms/lists.example.org/conf/config.php" die Variable "$topdir" anpassen;<br />
* 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;<br />
* Beim .deb-Paket die config.php, die templates/ und die tunables.pl aus etc/ nach example.org/conf/ verschieben;<br />
* 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: <br />
<br />
Require valid-user<br />
AuthType Basic<br />
AuthName "mlmmj web-interface"<br />
AuthUserFile /home/pacs/xyz00/users/list/doms/lists.example.org/etc/htpasswd<br />
<br />
* Und schließlich die "htpasswd"-Datei anlegen.<br />
<br />
cd /home/pacs/xyz00/users/list/doms/lists.example.org/etc/<br />
htpasswd -c htpasswd listadmin<br />
<br />
* Ein Passwort angeben.<br />
<br />
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<br />
<br />
* in <tt>.../htdocs-ssl/index.php</tt> folgende Änderung vornehmen:<br />
<br />
@@ -38,4 +38,5 @@<br />
# use scandir to have alphabetical order <br />
foreach (scandir($topdir) as $file) {<br />
- if (!ereg("^\.",$file))<br />
+# ereg obsolete!! Vormals: if (!ereg("^\.",$file))<br />
+ if (!preg_match('/^\./',$file))<br />
{<br />
<br />
und das Ergebnis auf https://lists.example.org anschauen.<br />
<br />
== Mehrere Mailinglisten betreiben ==<br />
<br />
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.<br />
<br />
Dazu trägt man in der Datei <tt>.forward</tt> statt des Aufrufs von ''mlmmj-recieve'' einen Aufruf von ''procmail'' ein:<br />
<br />
|/usr/bin/procmail<br />
<br />
Die Konfiguration von Procmail kann generisch erfolgen. Dazu legt man eine Datei <tt>.procmailrc</tt> mit folgendem Inhalt ins $HOME des Users:<br />
<br />
SHELL=/bin/sh<br />
HOMEDIR=/home/pacs/xyz00/users/list<br />
MAILDIR=/home/pacs/xyz00/users/list/Maildir<br />
PMDIR=/home/pacs/xyz00/users/list<br />
VERBOSE=yes<br />
LOGFILE=/home/pacs/xyz00/users/list/var/procmail.log<br />
DEFAULT<br />
<br />
:0:<br />
* ^X-Original-To: ()\/[^@+]+<br />
|/usr/bin/mlmmj-receive -F -L /home/pacs/xyz00/users/list/mlmmj/${MATCH}/<br />
<br />
:0<br />
{ EXITCODE 67 }<br />
<br />
<br />
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.<br />
<br />
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).<br />
<br />
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.<br />
<br />
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:<br />
<br />
:0:<br />
* ^X-Original-To: ()\/[^@+]+<br />
|/usr/bin/mlmmj-receive -F -L /home/pacs/xyz00/users/list/mlmmj/$(echo ${MATCH} | tr A-Z a-z)/<br />
<br />
Der Rest der Datei muß gleich bleiben, wie weiter oben angezeigt.<br />
<br />
In diesem Fall müssen aber alle Mailing-Listen ohne Großbuchstaben im Namen angelegt werden!<br />
<br />
(Man kann auch in <tt>${HOME}/mlmmj/</tt> durch kleingeschriebene Symlinks großgeschriebene Listennamen ansprechbar machen:<br />
<br />
xyz00-list@h02:~$ ls -lA mlmmj/<br />
total 8<br />
-rw-r--r-- 1 xyz00-list xyz00 148 Feb 1 16:56 .htaccess<br />
lrwxrwxrwx 1 xyz00-list xyz00 10 Feb 2 18:01 mitglieder -> Mitglieder<br />
drwxr-xr-x 15 xyz00-list xyz00 4096 Feb 2 16:53 Mitglieder<br />
<br />
Das scheint zu funktionieren; Angabe ohne Gewähr.)<br />
<br />
== Links ==<br />
<br />
* http://mlmmj.org/ Projektseite<br />
* https://codeberg.org/mlmmj mlmmj auf Codeberg<br />
* https://github.com/tchapi/mlmmj-simple-web-interface ein Admin-Interface in NodeJS<br />
* https://www.tablix.org/~avian/blog/archives/2010/04/the_faulty_default/ Nutzung von mlmmj in Verbindung mit Procmail<br />
<br />
----<br />
[[Kategorie:HSDoku]]<br />
[[Kategorie:Installationsanleitungen]]<br />
[[Kategorie:Software]]<br />
[[Kategorie:Mailinglisten]]<br />
[[Kategorie:E-Mail]]</div>Apc00-tonyhttps://wiki.hostsharing.net/index.php?title=Mlmmj&diff=6409Mlmmj2024-02-03T09:57:47Z<p>Apc00-tony: /* Zur Konfiguration im Browser */</p>
<hr />
<div>[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.<br />
<br />
Wer noch nicht weiß, was ein E-Mail-Verteiler machen soll oder wie, lese veilleicht auch den Wikipedia-Artikel:<br />
[http://de.wikipedia.org/wiki/Mailingliste Mailingliste]<br />
<br />
Eine leistungsfähigere Alternative zu mlmmj könnte [[Mailman_3_installieren|Mailman 3]] sein.<br />
<br />
Diese Anleitung beschreibt die Einrichtung einer Mailingliste für eine Domain in einem Hostsharing-Webspace.<br />
<br />
== Voraussetzungen ==<br />
<br />
Das Debian Paket [http://packages.debian.org/search?keywords=mlmmj mlmmj] ist auf den Shared-Hosting-Servern bereits installiert.<br />
<br />
Für den Betrieb der Mailingliste empfiehlt sich das Anlegen eines eigenen Users für diesen Zweck mit hsadmin.<br />
<br />
In dieser Anleitung heißt das Paket ''xyz00'' und der für Mailinglisten eingesetzte User ''xyz00-list''.<br />
<br />
Die E-Mail-Adresse der einzurichtende Mailing-Liste soll ''discuss@example.org'' sein.<br />
<br />
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.)<br />
<br />
== Einrichtung ==<br />
<br />
Ich melde mich über SSH auf der Hostsharing-Console als der Paketuser ''xyz00'' an.<br />
<br />
Im Shell kann ich dann durch den Befehl ''hsscript -i'' das Verwaltungswerkzeug [[hsadmin]] interaktiv ausführen:<br />
<br />
xyz00@h03:~$ hsscript -i<br />
Password: *************<br />
xyz00@hsadmin> <br />
<br />
In ''hsadmin'' werden User und E-Mail-Adresse angelegt.<br />
<br />
xyz00@hsadmin> user.add({set:{name:'xyz00-list',comment:'Mailingliste Discuss',shell:'/bin/bash',password:'geheimnis'}})<br />
xyz00@hsadmin> emailaddress.add({set:{target:'xyz00-list',localpart:'discuss',domain:'example.org'}})<br />
xyz00@hsadmin> bye<br />
<br />
Mit dem Parameter "target" wird die für diese Adresse eingehende Post zunächst in das Postfach des Users xyz00-list abgelegt.<br />
<br />
Für den User xyz00-list lege ich in seinem Heimat-Verzeichnis das Unterverzeichnis <tt>mlmmj</tt> an:<br />
<br />
mkdir /home/pacs/xyz00/users/list/mlmmj<br />
<br />
Dann lege ich die Mailingliste mit folgendem Kommando an:<br />
<br />
mlmmj-make-ml -L discuss -s /home/pacs/xyz00/users/list/mlmmj<br />
<br />
Das Skript ''mlmmj-make-ml'' fragt weitere Parameter der Mailingliste ab:<br />
<br />
The Domain for the List? [] : example.org<br />
The emailaddress of the list owner? [postmaster] : webmaster@example.org<br />
For the list texts you can choose between the following languages or<br />
give an absolute path to a directory containing the texts.<br />
Available languages:<br />
cz da de en es fr it nl ru<br />
The path to texts for the list? [en] : de<br />
<br />
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.<br />
<br />
Weitere Konfigurationen der Liste erfolgen durch das Anlegen von Dateien im<br />
Verzeichnis "/home/pacs/xyz00/users/list/mlmmj/discuss/control".<br />
Die Konfigurationsmöglichkeiten finden Sie auf der [http://mlmmj.org/docs/tunables/ Internetseite von mlmmj].<br />
<br />
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:<br />
<br />
"|/usr/bin/mlmmj-recieve -L /home/pacs/xyz00/users/list/mlmmj/discuss/"<br />
<br />
(Ja, ''receive'' schreibt sich mit ''-ei-'', aber mlmmj hält einen symbolischen Link bereit für diejenigen, die in englischer Rechtschreibung unsicher sind:)<br />
<br />
xyz00-list@h03:~$ ls -la /usr/bin/mlmmj-rec*<br />
-rwxr-xr-x 1 root root 27104 Sep 25 2018 /usr/bin/mlmmj-receive<br />
lrwxrwxrwx 1 root root 13 Sep 25 2018 /usr/bin/mlmmj-recieve -> mlmmj-receive<br />
<br />
Die <tt>.forward</tt>-Datei sorgt dafür, dass eingehende E-Mails an das User-Postfach an das Programm ''mlmmj-recieve'' übergeben werden.<br />
<br />
Für regelmäßige Aufgaben der Listen-Managers definiere ich die<br />
[[Cron|crontab]] wie folgt (immer noch als ''xyz00-list''):<br />
<br />
xyz00-list@h03:~$ crontab -e<br />
<br />
MAILTO=webmaster@example.org<br />
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin<br />
HOME=/home/pacs/xyz00/users/list<br />
SHELL=/bin/bash<br />
LANG=en_US.UTF-8<br />
# m h dom mon dow command<br />
28 */4 * * * /usr/bin/mlmmj-maintd -d /home/pacs/xyz00/users/list/mlmmj -F<br />
<br />
Zum Schluss rufe ich das Skript mlmmj-sub auf, um die E-Mail-Adressen der gewünschten Abonnenten des Verteilers einzutragen:<br />
<br />
/usr/bin/mlmmj-sub -L /home/pacs/xyz00/users/list/mlmmj/discuss -a klaus.muster@gmx.de -c <br />
/usr/bin/mlmmj-sub -L /home/pacs/xyz00/users/list/mlmmj/discuss -a sabine.beispiel@arcor.de -c <br />
<br />
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.<br />
<br />
== weitere Optionen ==<br />
<br />
Noch ein paar Dinge, die Sie möglicherweise einstellen wollen:<br />
<br />
Ein Prefix in der Betreffzeile setzen, z.B.: "[discuss]".<br />
<br />
echo "[discuss]" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/prefix<br />
<br />
Wenn die Liste nur E-Mails von eingetragenen Abonnenten weiterleiten soll:<br />
<br />
touch /home/pacs/xyz00/users/list/mlmmj/discuss/control/subonlypost<br />
<br />
Damit der Listen-Owner weitere Abonnements bestätigen muss:<br />
<br />
touch /home/pacs/xyz00/users/list/mlmmj/discuss/control/submod<br />
<br />
Einen "Reply-To:"-Header setzen, damit Antwort-Mails standardmäßig an die Mailing-Liste gehen:<br />
<br />
echo "Reply-To:" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/delheaders<br />
echo "Reply-To: discuss@example.org" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/customheaders<br />
<br />
Weitere Möglichkeiten finden Sie (wie oben bereits angegeben) <br />
auf der [http://mlmmj.org/docs/tunables/ Internetseite von mlmmj].<br />
<br />
== Zur Konfiguration im Browser ==<br />
<br />
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.<br />
<br />
Wer es sich ansehen möchte:<br />
<br />
Als Paket-Admin eine Domain aufschalten:<br />
<br />
hsscript -u xyz00 -e "domain.add({set:{name:'lists.example.org',user:'xyz00-list'}})"<br />
<br />
Und weiter als "xyz00-list".<br />
<br />
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).<br />
<br />
Unter "/mlmmj-$versionsnummer/contrib/web/php-admin/", oder beim .deb-Paket unter "usr/share/mlmmj-...", findet sich die PHP-Admin-Anwendung. Also ...<br />
<br />
* den Inhalt diese Verzeichnisses nach "/home/pacs/xyz00/users/list/doms/lists.example.org/" packen;<br />
* in "/home/pacs/xyz00/users/list/doms/lists.example.org/conf/config.php" die Variable "$topdir" anpassen;<br />
* 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;<br />
* Beim .deb-Paket die config.php, die templates/ und die tunables.pl aus etc/ nach example.org/conf/ verschieben;<br />
* 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: <br />
<br />
Require valid-user<br />
AuthType Basic<br />
AuthName "mlmmj web-interface"<br />
AuthUserFile /home/pacs/xyz00/users/list/doms/lists.example.org/etc/htpasswd<br />
<br />
* Und schließlich die "htpasswd"-Datei anlegen.<br />
<br />
cd /home/pacs/xyz00/users/list/doms/lists.example.org/etc/<br />
htpasswd -c htpasswd listadmin<br />
<br />
* Ein Passwort angeben.<br />
<br />
Nun enthält diese PHP-Anwendung leider noch eine Zeile, die schon seit PHP 7 nicht mehr lauffähig ist. Also muß man noch<br />
<br />
* in <tt>.../htdocs-ssl/index.php</tt> folgende Änderung vornehmen:<br />
<br />
@@ -38,4 +38,5 @@<br />
# use scandir to have alphabetical order <br />
foreach (scandir($topdir) as $file) {<br />
- if (!ereg("^\.",$file))<br />
+# ereg obsolete!! Vormals: if (!ereg("^\.",$file))<br />
+ if (!preg_match('/^\./',$file))<br />
{<br />
<br />
und das Ergebnis auf https://lists.example.org anschauen.<br />
<br />
== Mehrere Mailinglisten betreiben ==<br />
<br />
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.<br />
<br />
Dazu trägt man in der Datei <tt>.forward</tt> statt des Aufrufs von ''mlmmj-recieve'' einen Aufruf von ''procmail'' ein:<br />
<br />
|/usr/bin/procmail<br />
<br />
Die Konfiguration von Procmail kann generisch erfolgen. Dazu legt man eine Datei <tt>.procmailrc</tt> mit folgendem Inhalt ins $HOME des Users:<br />
<br />
SHELL=/bin/sh<br />
HOMEDIR=/home/pacs/xyz00/users/list<br />
MAILDIR=/home/pacs/xyz00/users/list/Maildir<br />
PMDIR=/home/pacs/xyz00/users/list<br />
VERBOSE=yes<br />
LOGFILE=/home/pacs/xyz00/users/list/var/procmail.log<br />
DEFAULT<br />
<br />
:0:<br />
* ^X-Original-To: ()\/[^@+]+<br />
|/usr/bin/mlmmj-receive -F -L /home/pacs/xyz00/users/list/mlmmj/${MATCH}/<br />
<br />
:0<br />
{ EXITCODE 67 }<br />
<br />
<br />
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.<br />
<br />
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).<br />
<br />
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.<br />
<br />
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:<br />
<br />
:0:<br />
* ^X-Original-To: ()\/[^@+]+<br />
|/usr/bin/mlmmj-receive -F -L /home/pacs/xyz00/users/list/mlmmj/$(echo ${MATCH} | tr A-Z a-z)/<br />
<br />
Der Rest der Datei muß gleich bleiben, wie weiter oben angezeigt.<br />
<br />
In diesem Fall müssen aber alle Mailing-Listen ohne Großbuchstaben im Namen angelegt werden!<br />
<br />
(Man kann auch in <tt>${HOME}/mlmmj/</tt> durch kleingeschriebene Symlinks großgeschriebene Listennamen ansprechbar machen:<br />
<br />
xyz00-list@h02:~$ ls -lA mlmmj/<br />
total 8<br />
-rw-r--r-- 1 xyz00-list xyz00 148 Feb 1 16:56 .htaccess<br />
lrwxrwxrwx 1 xyz00-list xyz00 10 Feb 2 18:01 mitglieder -> Mitglieder<br />
drwxr-xr-x 15 xyz00-list xyz00 4096 Feb 2 16:53 Mitglieder<br />
<br />
Das scheint zu funktionieren; Angabe ohne Gewähr.)<br />
<br />
== Links ==<br />
<br />
* http://mlmmj.org/ Projektseite<br />
* https://codeberg.org/mlmmj mlmmj auf Codeberg<br />
* https://github.com/tchapi/mlmmj-simple-web-interface ein Admin-Interface in NodeJS<br />
* https://www.tablix.org/~avian/blog/archives/2010/04/the_faulty_default/ Nutzung von mlmmj in Verbindung mit Procmail<br />
<br />
----<br />
[[Kategorie:HSDoku]]<br />
[[Kategorie:Installationsanleitungen]]<br />
[[Kategorie:Software]]<br />
[[Kategorie:Mailinglisten]]<br />
[[Kategorie:E-Mail]]</div>Apc00-tonyhttps://wiki.hostsharing.net/index.php?title=Mlmmj&diff=6408Mlmmj2024-02-03T09:56:24Z<p>Apc00-tony: /* Zur Konfiguration im Browser */ web-admin aus debian</p>
<hr />
<div>[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.<br />
<br />
Wer noch nicht weiß, was ein E-Mail-Verteiler machen soll oder wie, lese veilleicht auch den Wikipedia-Artikel:<br />
[http://de.wikipedia.org/wiki/Mailingliste Mailingliste]<br />
<br />
Eine leistungsfähigere Alternative zu mlmmj könnte [[Mailman_3_installieren|Mailman 3]] sein.<br />
<br />
Diese Anleitung beschreibt die Einrichtung einer Mailingliste für eine Domain in einem Hostsharing-Webspace.<br />
<br />
== Voraussetzungen ==<br />
<br />
Das Debian Paket [http://packages.debian.org/search?keywords=mlmmj mlmmj] ist auf den Shared-Hosting-Servern bereits installiert.<br />
<br />
Für den Betrieb der Mailingliste empfiehlt sich das Anlegen eines eigenen Users für diesen Zweck mit hsadmin.<br />
<br />
In dieser Anleitung heißt das Paket ''xyz00'' und der für Mailinglisten eingesetzte User ''xyz00-list''.<br />
<br />
Die E-Mail-Adresse der einzurichtende Mailing-Liste soll ''discuss@example.org'' sein.<br />
<br />
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.)<br />
<br />
== Einrichtung ==<br />
<br />
Ich melde mich über SSH auf der Hostsharing-Console als der Paketuser ''xyz00'' an.<br />
<br />
Im Shell kann ich dann durch den Befehl ''hsscript -i'' das Verwaltungswerkzeug [[hsadmin]] interaktiv ausführen:<br />
<br />
xyz00@h03:~$ hsscript -i<br />
Password: *************<br />
xyz00@hsadmin> <br />
<br />
In ''hsadmin'' werden User und E-Mail-Adresse angelegt.<br />
<br />
xyz00@hsadmin> user.add({set:{name:'xyz00-list',comment:'Mailingliste Discuss',shell:'/bin/bash',password:'geheimnis'}})<br />
xyz00@hsadmin> emailaddress.add({set:{target:'xyz00-list',localpart:'discuss',domain:'example.org'}})<br />
xyz00@hsadmin> bye<br />
<br />
Mit dem Parameter "target" wird die für diese Adresse eingehende Post zunächst in das Postfach des Users xyz00-list abgelegt.<br />
<br />
Für den User xyz00-list lege ich in seinem Heimat-Verzeichnis das Unterverzeichnis <tt>mlmmj</tt> an:<br />
<br />
mkdir /home/pacs/xyz00/users/list/mlmmj<br />
<br />
Dann lege ich die Mailingliste mit folgendem Kommando an:<br />
<br />
mlmmj-make-ml -L discuss -s /home/pacs/xyz00/users/list/mlmmj<br />
<br />
Das Skript ''mlmmj-make-ml'' fragt weitere Parameter der Mailingliste ab:<br />
<br />
The Domain for the List? [] : example.org<br />
The emailaddress of the list owner? [postmaster] : webmaster@example.org<br />
For the list texts you can choose between the following languages or<br />
give an absolute path to a directory containing the texts.<br />
Available languages:<br />
cz da de en es fr it nl ru<br />
The path to texts for the list? [en] : de<br />
<br />
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.<br />
<br />
Weitere Konfigurationen der Liste erfolgen durch das Anlegen von Dateien im<br />
Verzeichnis "/home/pacs/xyz00/users/list/mlmmj/discuss/control".<br />
Die Konfigurationsmöglichkeiten finden Sie auf der [http://mlmmj.org/docs/tunables/ Internetseite von mlmmj].<br />
<br />
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:<br />
<br />
"|/usr/bin/mlmmj-recieve -L /home/pacs/xyz00/users/list/mlmmj/discuss/"<br />
<br />
(Ja, ''receive'' schreibt sich mit ''-ei-'', aber mlmmj hält einen symbolischen Link bereit für diejenigen, die in englischer Rechtschreibung unsicher sind:)<br />
<br />
xyz00-list@h03:~$ ls -la /usr/bin/mlmmj-rec*<br />
-rwxr-xr-x 1 root root 27104 Sep 25 2018 /usr/bin/mlmmj-receive<br />
lrwxrwxrwx 1 root root 13 Sep 25 2018 /usr/bin/mlmmj-recieve -> mlmmj-receive<br />
<br />
Die <tt>.forward</tt>-Datei sorgt dafür, dass eingehende E-Mails an das User-Postfach an das Programm ''mlmmj-recieve'' übergeben werden.<br />
<br />
Für regelmäßige Aufgaben der Listen-Managers definiere ich die<br />
[[Cron|crontab]] wie folgt (immer noch als ''xyz00-list''):<br />
<br />
xyz00-list@h03:~$ crontab -e<br />
<br />
MAILTO=webmaster@example.org<br />
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin<br />
HOME=/home/pacs/xyz00/users/list<br />
SHELL=/bin/bash<br />
LANG=en_US.UTF-8<br />
# m h dom mon dow command<br />
28 */4 * * * /usr/bin/mlmmj-maintd -d /home/pacs/xyz00/users/list/mlmmj -F<br />
<br />
Zum Schluss rufe ich das Skript mlmmj-sub auf, um die E-Mail-Adressen der gewünschten Abonnenten des Verteilers einzutragen:<br />
<br />
/usr/bin/mlmmj-sub -L /home/pacs/xyz00/users/list/mlmmj/discuss -a klaus.muster@gmx.de -c <br />
/usr/bin/mlmmj-sub -L /home/pacs/xyz00/users/list/mlmmj/discuss -a sabine.beispiel@arcor.de -c <br />
<br />
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.<br />
<br />
== weitere Optionen ==<br />
<br />
Noch ein paar Dinge, die Sie möglicherweise einstellen wollen:<br />
<br />
Ein Prefix in der Betreffzeile setzen, z.B.: "[discuss]".<br />
<br />
echo "[discuss]" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/prefix<br />
<br />
Wenn die Liste nur E-Mails von eingetragenen Abonnenten weiterleiten soll:<br />
<br />
touch /home/pacs/xyz00/users/list/mlmmj/discuss/control/subonlypost<br />
<br />
Damit der Listen-Owner weitere Abonnements bestätigen muss:<br />
<br />
touch /home/pacs/xyz00/users/list/mlmmj/discuss/control/submod<br />
<br />
Einen "Reply-To:"-Header setzen, damit Antwort-Mails standardmäßig an die Mailing-Liste gehen:<br />
<br />
echo "Reply-To:" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/delheaders<br />
echo "Reply-To: discuss@example.org" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/customheaders<br />
<br />
Weitere Möglichkeiten finden Sie (wie oben bereits angegeben) <br />
auf der [http://mlmmj.org/docs/tunables/ Internetseite von mlmmj].<br />
<br />
== Zur Konfiguration im Browser ==<br />
<br />
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.<br />
<br />
Wer es sich ansehen möchte:<br />
<br />
Als Paket-Admin eine Domain aufschalten:<br />
<br />
hsscript -u xyz00 -e "domain.add({set:{name:'lists.example.org',user:'xyz00-list'}})"<br />
<br />
Und weiter als "xyz00-list".<br />
<br />
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]: da sind einige veraltete PHP-Ausdrücke schon herausgepatcht) und diese in einem temporären Verzeichnis entpacken (mit tar oder dpkg-deb).<br />
<br />
Unter "/mlmmj-$versionsnummer/contrib/web/php-admin/", oder beim .deb-Paket unter "usr/share/mlmmj-...", findet sich die PHP-Admin-Anwendung. Also ...<br />
<br />
* den Inhalt diese Verzeichnisses nach "/home/pacs/xyz00/users/list/doms/lists.example.org/" packen;<br />
* in "/home/pacs/xyz00/users/list/doms/lists.example.org/conf/config.php" die Variable "$topdir" anpassen;<br />
* 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;<br />
* Beim .deb-Paket die config.php, die templates/ und die tunables.pl aus etc/ nach example.org/conf/ verschieben;<br />
* 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: <br />
<br />
Require valid-user<br />
AuthType Basic<br />
AuthName "mlmmj web-interface"<br />
AuthUserFile /home/pacs/xyz00/users/list/doms/lists.example.org/etc/htpasswd<br />
<br />
* Und schließlich die "htpasswd"-Datei anlegen.<br />
<br />
cd /home/pacs/xyz00/users/list/doms/lists.example.org/etc/<br />
htpasswd -c htpasswd listadmin<br />
<br />
* Ein Passwort angeben.<br />
<br />
Nun enthält diese PHP-Anwendung leider noch eine Zeile, die schon seit PHP 7 nicht mehr lauffähig ist. Also muß man noch<br />
<br />
* in <tt>.../htdocs-ssl/index.php</tt> folgende Änderung vornehmen:<br />
<br />
@@ -38,4 +38,5 @@<br />
# use scandir to have alphabetical order <br />
foreach (scandir($topdir) as $file) {<br />
- if (!ereg("^\.",$file))<br />
+# ereg obsolete!! Vormals: if (!ereg("^\.",$file))<br />
+ if (!preg_match('/^\./',$file))<br />
{<br />
<br />
und das Ergebnis auf https://lists.example.org anschauen.<br />
<br />
== Mehrere Mailinglisten betreiben ==<br />
<br />
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.<br />
<br />
Dazu trägt man in der Datei <tt>.forward</tt> statt des Aufrufs von ''mlmmj-recieve'' einen Aufruf von ''procmail'' ein:<br />
<br />
|/usr/bin/procmail<br />
<br />
Die Konfiguration von Procmail kann generisch erfolgen. Dazu legt man eine Datei <tt>.procmailrc</tt> mit folgendem Inhalt ins $HOME des Users:<br />
<br />
SHELL=/bin/sh<br />
HOMEDIR=/home/pacs/xyz00/users/list<br />
MAILDIR=/home/pacs/xyz00/users/list/Maildir<br />
PMDIR=/home/pacs/xyz00/users/list<br />
VERBOSE=yes<br />
LOGFILE=/home/pacs/xyz00/users/list/var/procmail.log<br />
DEFAULT<br />
<br />
:0:<br />
* ^X-Original-To: ()\/[^@+]+<br />
|/usr/bin/mlmmj-receive -F -L /home/pacs/xyz00/users/list/mlmmj/${MATCH}/<br />
<br />
:0<br />
{ EXITCODE 67 }<br />
<br />
<br />
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.<br />
<br />
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).<br />
<br />
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.<br />
<br />
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:<br />
<br />
:0:<br />
* ^X-Original-To: ()\/[^@+]+<br />
|/usr/bin/mlmmj-receive -F -L /home/pacs/xyz00/users/list/mlmmj/$(echo ${MATCH} | tr A-Z a-z)/<br />
<br />
Der Rest der Datei muß gleich bleiben, wie weiter oben angezeigt.<br />
<br />
In diesem Fall müssen aber alle Mailing-Listen ohne Großbuchstaben im Namen angelegt werden!<br />
<br />
(Man kann auch in <tt>${HOME}/mlmmj/</tt> durch kleingeschriebene Symlinks großgeschriebene Listennamen ansprechbar machen:<br />
<br />
xyz00-list@h02:~$ ls -lA mlmmj/<br />
total 8<br />
-rw-r--r-- 1 xyz00-list xyz00 148 Feb 1 16:56 .htaccess<br />
lrwxrwxrwx 1 xyz00-list xyz00 10 Feb 2 18:01 mitglieder -> Mitglieder<br />
drwxr-xr-x 15 xyz00-list xyz00 4096 Feb 2 16:53 Mitglieder<br />
<br />
Das scheint zu funktionieren; Angabe ohne Gewähr.)<br />
<br />
== Links ==<br />
<br />
* http://mlmmj.org/ Projektseite<br />
* https://codeberg.org/mlmmj mlmmj auf Codeberg<br />
* https://github.com/tchapi/mlmmj-simple-web-interface ein Admin-Interface in NodeJS<br />
* https://www.tablix.org/~avian/blog/archives/2010/04/the_faulty_default/ Nutzung von mlmmj in Verbindung mit Procmail<br />
<br />
----<br />
[[Kategorie:HSDoku]]<br />
[[Kategorie:Installationsanleitungen]]<br />
[[Kategorie:Software]]<br />
[[Kategorie:Mailinglisten]]<br />
[[Kategorie:E-Mail]]</div>Apc00-tonyhttps://wiki.hostsharing.net/index.php?title=Mlmmj&diff=6407Mlmmj2024-02-03T09:48:21Z<p>Apc00-tony: /* Mehrere Mailinglisten betreiben */ Tücken bei Procmail</p>
<hr />
<div>[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.<br />
<br />
Wer noch nicht weiß, was ein E-Mail-Verteiler machen soll oder wie, lese veilleicht auch den Wikipedia-Artikel:<br />
[http://de.wikipedia.org/wiki/Mailingliste Mailingliste]<br />
<br />
Eine leistungsfähigere Alternative zu mlmmj könnte [[Mailman_3_installieren|Mailman 3]] sein.<br />
<br />
Diese Anleitung beschreibt die Einrichtung einer Mailingliste für eine Domain in einem Hostsharing-Webspace.<br />
<br />
== Voraussetzungen ==<br />
<br />
Das Debian Paket [http://packages.debian.org/search?keywords=mlmmj mlmmj] ist auf den Shared-Hosting-Servern bereits installiert.<br />
<br />
Für den Betrieb der Mailingliste empfiehlt sich das Anlegen eines eigenen Users für diesen Zweck mit hsadmin.<br />
<br />
In dieser Anleitung heißt das Paket ''xyz00'' und der für Mailinglisten eingesetzte User ''xyz00-list''.<br />
<br />
Die E-Mail-Adresse der einzurichtende Mailing-Liste soll ''discuss@example.org'' sein.<br />
<br />
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.)<br />
<br />
== Einrichtung ==<br />
<br />
Ich melde mich über SSH auf der Hostsharing-Console als der Paketuser ''xyz00'' an.<br />
<br />
Im Shell kann ich dann durch den Befehl ''hsscript -i'' das Verwaltungswerkzeug [[hsadmin]] interaktiv ausführen:<br />
<br />
xyz00@h03:~$ hsscript -i<br />
Password: *************<br />
xyz00@hsadmin> <br />
<br />
In ''hsadmin'' werden User und E-Mail-Adresse angelegt.<br />
<br />
xyz00@hsadmin> user.add({set:{name:'xyz00-list',comment:'Mailingliste Discuss',shell:'/bin/bash',password:'geheimnis'}})<br />
xyz00@hsadmin> emailaddress.add({set:{target:'xyz00-list',localpart:'discuss',domain:'example.org'}})<br />
xyz00@hsadmin> bye<br />
<br />
Mit dem Parameter "target" wird die für diese Adresse eingehende Post zunächst in das Postfach des Users xyz00-list abgelegt.<br />
<br />
Für den User xyz00-list lege ich in seinem Heimat-Verzeichnis das Unterverzeichnis <tt>mlmmj</tt> an:<br />
<br />
mkdir /home/pacs/xyz00/users/list/mlmmj<br />
<br />
Dann lege ich die Mailingliste mit folgendem Kommando an:<br />
<br />
mlmmj-make-ml -L discuss -s /home/pacs/xyz00/users/list/mlmmj<br />
<br />
Das Skript ''mlmmj-make-ml'' fragt weitere Parameter der Mailingliste ab:<br />
<br />
The Domain for the List? [] : example.org<br />
The emailaddress of the list owner? [postmaster] : webmaster@example.org<br />
For the list texts you can choose between the following languages or<br />
give an absolute path to a directory containing the texts.<br />
Available languages:<br />
cz da de en es fr it nl ru<br />
The path to texts for the list? [en] : de<br />
<br />
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.<br />
<br />
Weitere Konfigurationen der Liste erfolgen durch das Anlegen von Dateien im<br />
Verzeichnis "/home/pacs/xyz00/users/list/mlmmj/discuss/control".<br />
Die Konfigurationsmöglichkeiten finden Sie auf der [http://mlmmj.org/docs/tunables/ Internetseite von mlmmj].<br />
<br />
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:<br />
<br />
"|/usr/bin/mlmmj-recieve -L /home/pacs/xyz00/users/list/mlmmj/discuss/"<br />
<br />
(Ja, ''receive'' schreibt sich mit ''-ei-'', aber mlmmj hält einen symbolischen Link bereit für diejenigen, die in englischer Rechtschreibung unsicher sind:)<br />
<br />
xyz00-list@h03:~$ ls -la /usr/bin/mlmmj-rec*<br />
-rwxr-xr-x 1 root root 27104 Sep 25 2018 /usr/bin/mlmmj-receive<br />
lrwxrwxrwx 1 root root 13 Sep 25 2018 /usr/bin/mlmmj-recieve -> mlmmj-receive<br />
<br />
Die <tt>.forward</tt>-Datei sorgt dafür, dass eingehende E-Mails an das User-Postfach an das Programm ''mlmmj-recieve'' übergeben werden.<br />
<br />
Für regelmäßige Aufgaben der Listen-Managers definiere ich die<br />
[[Cron|crontab]] wie folgt (immer noch als ''xyz00-list''):<br />
<br />
xyz00-list@h03:~$ crontab -e<br />
<br />
MAILTO=webmaster@example.org<br />
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin<br />
HOME=/home/pacs/xyz00/users/list<br />
SHELL=/bin/bash<br />
LANG=en_US.UTF-8<br />
# m h dom mon dow command<br />
28 */4 * * * /usr/bin/mlmmj-maintd -d /home/pacs/xyz00/users/list/mlmmj -F<br />
<br />
Zum Schluss rufe ich das Skript mlmmj-sub auf, um die E-Mail-Adressen der gewünschten Abonnenten des Verteilers einzutragen:<br />
<br />
/usr/bin/mlmmj-sub -L /home/pacs/xyz00/users/list/mlmmj/discuss -a klaus.muster@gmx.de -c <br />
/usr/bin/mlmmj-sub -L /home/pacs/xyz00/users/list/mlmmj/discuss -a sabine.beispiel@arcor.de -c <br />
<br />
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.<br />
<br />
== weitere Optionen ==<br />
<br />
Noch ein paar Dinge, die Sie möglicherweise einstellen wollen:<br />
<br />
Ein Prefix in der Betreffzeile setzen, z.B.: "[discuss]".<br />
<br />
echo "[discuss]" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/prefix<br />
<br />
Wenn die Liste nur E-Mails von eingetragenen Abonnenten weiterleiten soll:<br />
<br />
touch /home/pacs/xyz00/users/list/mlmmj/discuss/control/subonlypost<br />
<br />
Damit der Listen-Owner weitere Abonnements bestätigen muss:<br />
<br />
touch /home/pacs/xyz00/users/list/mlmmj/discuss/control/submod<br />
<br />
Einen "Reply-To:"-Header setzen, damit Antwort-Mails standardmäßig an die Mailing-Liste gehen:<br />
<br />
echo "Reply-To:" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/delheaders<br />
echo "Reply-To: discuss@example.org" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/customheaders<br />
<br />
Weitere Möglichkeiten finden Sie (wie oben bereits angegeben) <br />
auf der [http://mlmmj.org/docs/tunables/ Internetseite von mlmmj].<br />
<br />
== Zur Konfiguration im Browser ==<br />
<br />
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.<br />
<br />
Wer es sich ansehen möchte:<br />
<br />
Als Paket-Admin eine Domain aufschalten:<br />
<br />
hsscript -u xyz00 -e "domain.add({set:{name:'lists.example.org',user:'xyz00-list'}})"<br />
<br />
Und weiter als "xyz00-list".<br />
<br />
Download der neuesten Version der Sourcen von mlmmj von http://mlmmj.org/downloads/ und diese in einem temporären Verzeichnis entpacken.<br />
<br />
Unter "/mlmmj-$versionsnummer/contrib/web/php-admin/" findet sich die PHP-Admin-Anwendung. Also ... <br />
<br />
* den Inhalt diese Verzeichnisses nach "/home/pacs/xyz00/users/list/doms/lists.example.org/" packen;<br />
* in "/home/pacs/xyz00/users/list/doms/lists.example.org/conf/config.php" die Variable "$topdir" anpassen;<br />
* 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;<br />
* 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: <br />
<br />
Require valid-user<br />
AuthType Basic<br />
AuthName "mlmmj web-interface"<br />
AuthUserFile /home/pacs/xyz00/users/list/doms/lists.example.org/etc/htpasswd<br />
<br />
* Und schließlich die "htpasswd"-Datei anlegen.<br />
<br />
cd /home/pacs/xyz00/users/list/doms/lists.example.org/etc/<br />
htpasswd -c htpasswd listadmin<br />
<br />
* Ein Passwort angeben.<br />
<br />
Nun enthält diese PHP-Anwendung leider noch eine Zeile, die schon seit PHP 7 nicht mehr lauffähig ist. Also muß man noch<br />
<br />
* in <tt>.../htdocs-ssl/index.php</tt> folgende Änderung vornehmen:<br />
<br />
@@ -38,4 +38,5 @@<br />
# use scandir to have alphabetical order <br />
foreach (scandir($topdir) as $file) {<br />
- if (!ereg("^\.",$file))<br />
+# ereg obsolete!! Vormals: if (!ereg("^\.",$file))<br />
+ if (!preg_match('/^\./',$file))<br />
{<br />
<br />
und das Ergebnis auf https://lists.example.org anschauen.<br />
<br />
== Mehrere Mailinglisten betreiben ==<br />
<br />
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.<br />
<br />
Dazu trägt man in der Datei <tt>.forward</tt> statt des Aufrufs von ''mlmmj-recieve'' einen Aufruf von ''procmail'' ein:<br />
<br />
|/usr/bin/procmail<br />
<br />
Die Konfiguration von Procmail kann generisch erfolgen. Dazu legt man eine Datei <tt>.procmailrc</tt> mit folgendem Inhalt ins $HOME des Users:<br />
<br />
SHELL=/bin/sh<br />
HOMEDIR=/home/pacs/xyz00/users/list<br />
MAILDIR=/home/pacs/xyz00/users/list/Maildir<br />
PMDIR=/home/pacs/xyz00/users/list<br />
VERBOSE=yes<br />
LOGFILE=/home/pacs/xyz00/users/list/var/procmail.log<br />
DEFAULT<br />
<br />
:0:<br />
* ^X-Original-To: ()\/[^@+]+<br />
|/usr/bin/mlmmj-receive -F -L /home/pacs/xyz00/users/list/mlmmj/${MATCH}/<br />
<br />
:0<br />
{ EXITCODE 67 }<br />
<br />
<br />
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.<br />
<br />
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).<br />
<br />
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.<br />
<br />
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:<br />
<br />
:0:<br />
* ^X-Original-To: ()\/[^@+]+<br />
|/usr/bin/mlmmj-receive -F -L /home/pacs/xyz00/users/list/mlmmj/$(echo ${MATCH} | tr A-Z a-z)/<br />
<br />
Der Rest der Datei muß gleich bleiben, wie weiter oben angezeigt.<br />
<br />
In diesem Fall müssen aber alle Mailing-Listen ohne Großbuchstaben im Namen angelegt werden!<br />
<br />
(Man kann auch in <tt>${HOME}/mlmmj/</tt> durch kleingeschriebene Symlinks großgeschriebene Listennamen ansprechbar machen:<br />
<br />
xyz00-list@h02:~$ ls -lA mlmmj/<br />
total 8<br />
-rw-r--r-- 1 xyz00-list xyz00 148 Feb 1 16:56 .htaccess<br />
lrwxrwxrwx 1 xyz00-list xyz00 10 Feb 2 18:01 mitglieder -> Mitglieder<br />
drwxr-xr-x 15 xyz00-list xyz00 4096 Feb 2 16:53 Mitglieder<br />
<br />
Das scheint zu funktionieren; Angabe ohne Gewähr.)<br />
<br />
== Links ==<br />
<br />
* http://mlmmj.org/ Projektseite<br />
* https://codeberg.org/mlmmj mlmmj auf Codeberg<br />
* https://github.com/tchapi/mlmmj-simple-web-interface ein Admin-Interface in NodeJS<br />
* https://www.tablix.org/~avian/blog/archives/2010/04/the_faulty_default/ Nutzung von mlmmj in Verbindung mit Procmail<br />
<br />
----<br />
[[Kategorie:HSDoku]]<br />
[[Kategorie:Installationsanleitungen]]<br />
[[Kategorie:Software]]<br />
[[Kategorie:Mailinglisten]]<br />
[[Kategorie:E-Mail]]</div>Apc00-tonyhttps://wiki.hostsharing.net/index.php?title=Mlmmj&diff=6406Mlmmj2024-02-02T11:26:15Z<p>Apc00-tony: /* Zur Konfiguration im Browser */ diff verbessert</p>
<hr />
<div>[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.<br />
<br />
Wer noch nicht weiß, was ein E-Mail-Verteiler machen soll oder wie, lese veilleicht auch den Wikipedia-Artikel:<br />
[http://de.wikipedia.org/wiki/Mailingliste Mailingliste]<br />
<br />
Eine leistungsfähigere Alternative zu mlmmj könnte [[Mailman_3_installieren|Mailman 3]] sein.<br />
<br />
Diese Anleitung beschreibt die Einrichtung einer Mailingliste für eine Domain in einem Hostsharing-Webspace.<br />
<br />
== Voraussetzungen ==<br />
<br />
Das Debian Paket [http://packages.debian.org/search?keywords=mlmmj mlmmj] ist auf den Shared-Hosting-Servern bereits installiert.<br />
<br />
Für den Betrieb der Mailingliste empfiehlt sich das Anlegen eines eigenen Users für diesen Zweck mit hsadmin.<br />
<br />
In dieser Anleitung heißt das Paket ''xyz00'' und der für Mailinglisten eingesetzte User ''xyz00-list''.<br />
<br />
Die E-Mail-Adresse der einzurichtende Mailing-Liste soll ''discuss@example.org'' sein.<br />
<br />
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.)<br />
<br />
== Einrichtung ==<br />
<br />
Ich melde mich über SSH auf der Hostsharing-Console als der Paketuser ''xyz00'' an.<br />
<br />
Im Shell kann ich dann durch den Befehl ''hsscript -i'' das Verwaltungswerkzeug [[hsadmin]] interaktiv ausführen:<br />
<br />
xyz00@h03:~$ hsscript -i<br />
Password: *************<br />
xyz00@hsadmin> <br />
<br />
In ''hsadmin'' werden User und E-Mail-Adresse angelegt.<br />
<br />
xyz00@hsadmin> user.add({set:{name:'xyz00-list',comment:'Mailingliste Discuss',shell:'/bin/bash',password:'geheimnis'}})<br />
xyz00@hsadmin> emailaddress.add({set:{target:'xyz00-list',localpart:'discuss',domain:'example.org'}})<br />
xyz00@hsadmin> bye<br />
<br />
Mit dem Parameter "target" wird die für diese Adresse eingehende Post zunächst in das Postfach des Users xyz00-list abgelegt.<br />
<br />
Für den User xyz00-list lege ich in seinem Heimat-Verzeichnis das Unterverzeichnis <tt>mlmmj</tt> an:<br />
<br />
mkdir /home/pacs/xyz00/users/list/mlmmj<br />
<br />
Dann lege ich die Mailingliste mit folgendem Kommando an:<br />
<br />
mlmmj-make-ml -L discuss -s /home/pacs/xyz00/users/list/mlmmj<br />
<br />
Das Skript ''mlmmj-make-ml'' fragt weitere Parameter der Mailingliste ab:<br />
<br />
The Domain for the List? [] : example.org<br />
The emailaddress of the list owner? [postmaster] : webmaster@example.org<br />
For the list texts you can choose between the following languages or<br />
give an absolute path to a directory containing the texts.<br />
Available languages:<br />
cz da de en es fr it nl ru<br />
The path to texts for the list? [en] : de<br />
<br />
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.<br />
<br />
Weitere Konfigurationen der Liste erfolgen durch das Anlegen von Dateien im<br />
Verzeichnis "/home/pacs/xyz00/users/list/mlmmj/discuss/control".<br />
Die Konfigurationsmöglichkeiten finden Sie auf der [http://mlmmj.org/docs/tunables/ Internetseite von mlmmj].<br />
<br />
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:<br />
<br />
"|/usr/bin/mlmmj-recieve -L /home/pacs/xyz00/users/list/mlmmj/discuss/"<br />
<br />
(Ja, ''receive'' schreibt sich mit ''-ei-'', aber mlmmj hält einen symbolischen Link bereit für diejenigen, die in englischer Rechtschreibung unsicher sind:)<br />
<br />
xyz00-list@h03:~$ ls -la /usr/bin/mlmmj-rec*<br />
-rwxr-xr-x 1 root root 27104 Sep 25 2018 /usr/bin/mlmmj-receive<br />
lrwxrwxrwx 1 root root 13 Sep 25 2018 /usr/bin/mlmmj-recieve -> mlmmj-receive<br />
<br />
Die <tt>.forward</tt>-Datei sorgt dafür, dass eingehende E-Mails an das User-Postfach an das Programm ''mlmmj-recieve'' übergeben werden.<br />
<br />
Für regelmäßige Aufgaben der Listen-Managers definiere ich die<br />
[[Cron|crontab]] wie folgt (immer noch als ''xyz00-list''):<br />
<br />
xyz00-list@h03:~$ crontab -e<br />
<br />
MAILTO=webmaster@example.org<br />
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin<br />
HOME=/home/pacs/xyz00/users/list<br />
SHELL=/bin/bash<br />
LANG=en_US.UTF-8<br />
# m h dom mon dow command<br />
28 */4 * * * /usr/bin/mlmmj-maintd -d /home/pacs/xyz00/users/list/mlmmj -F<br />
<br />
Zum Schluss rufe ich das Skript mlmmj-sub auf, um die E-Mail-Adressen der gewünschten Abonnenten des Verteilers einzutragen:<br />
<br />
/usr/bin/mlmmj-sub -L /home/pacs/xyz00/users/list/mlmmj/discuss -a klaus.muster@gmx.de -c <br />
/usr/bin/mlmmj-sub -L /home/pacs/xyz00/users/list/mlmmj/discuss -a sabine.beispiel@arcor.de -c <br />
<br />
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.<br />
<br />
== weitere Optionen ==<br />
<br />
Noch ein paar Dinge, die Sie möglicherweise einstellen wollen:<br />
<br />
Ein Prefix in der Betreffzeile setzen, z.B.: "[discuss]".<br />
<br />
echo "[discuss]" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/prefix<br />
<br />
Wenn die Liste nur E-Mails von eingetragenen Abonnenten weiterleiten soll:<br />
<br />
touch /home/pacs/xyz00/users/list/mlmmj/discuss/control/subonlypost<br />
<br />
Damit der Listen-Owner weitere Abonnements bestätigen muss:<br />
<br />
touch /home/pacs/xyz00/users/list/mlmmj/discuss/control/submod<br />
<br />
Einen "Reply-To:"-Header setzen, damit Antwort-Mails standardmäßig an die Mailing-Liste gehen:<br />
<br />
echo "Reply-To:" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/delheaders<br />
echo "Reply-To: discuss@example.org" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/customheaders<br />
<br />
Weitere Möglichkeiten finden Sie (wie oben bereits angegeben) <br />
auf der [http://mlmmj.org/docs/tunables/ Internetseite von mlmmj].<br />
<br />
== Zur Konfiguration im Browser ==<br />
<br />
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.<br />
<br />
Wer es sich ansehen möchte:<br />
<br />
Als Paket-Admin eine Domain aufschalten:<br />
<br />
hsscript -u xyz00 -e "domain.add({set:{name:'lists.example.org',user:'xyz00-list'}})"<br />
<br />
Und weiter als "xyz00-list".<br />
<br />
Download der neuesten Version der Sourcen von mlmmj von http://mlmmj.org/downloads/ und diese in einem temporären Verzeichnis entpacken.<br />
<br />
Unter "/mlmmj-$versionsnummer/contrib/web/php-admin/" findet sich die PHP-Admin-Anwendung. Also ... <br />
<br />
* den Inhalt diese Verzeichnisses nach "/home/pacs/xyz00/users/list/doms/lists.example.org/" packen;<br />
* in "/home/pacs/xyz00/users/list/doms/lists.example.org/conf/config.php" die Variable "$topdir" anpassen;<br />
* 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;<br />
* 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: <br />
<br />
Require valid-user<br />
AuthType Basic<br />
AuthName "mlmmj web-interface"<br />
AuthUserFile /home/pacs/xyz00/users/list/doms/lists.example.org/etc/htpasswd<br />
<br />
* Und schließlich die "htpasswd"-Datei anlegen.<br />
<br />
cd /home/pacs/xyz00/users/list/doms/lists.example.org/etc/<br />
htpasswd -c htpasswd listadmin<br />
<br />
* Ein Passwort angeben.<br />
<br />
Nun enthält diese PHP-Anwendung leider noch eine Zeile, die schon seit PHP 7 nicht mehr lauffähig ist. Also muß man noch<br />
<br />
* in <tt>.../htdocs-ssl/index.php</tt> folgende Änderung vornehmen:<br />
<br />
@@ -38,4 +38,5 @@<br />
# use scandir to have alphabetical order <br />
foreach (scandir($topdir) as $file) {<br />
- if (!ereg("^\.",$file))<br />
+# ereg obsolete!! Vormals: if (!ereg("^\.",$file))<br />
+ if (!preg_match('/^\./',$file))<br />
{<br />
<br />
und das Ergebnis auf https://lists.example.org anschauen.<br />
<br />
== Mehrere Mailinglisten betreiben ==<br />
<br />
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.<br />
<br />
Dazu trägt man in der Date ''.forward'' statt des Aufrufs von ''mlmmj-recieve'' einen Aufruf von ''procmail'' ein:<br />
<br />
|/usr/bin/procmail<br />
<br />
Die Konfiguration von Procmail kann generisch erfolgen. Dazu legt man eine Datei ''.procmailrc'' mit folgendem Inhalt ins $HOME des Users:<br />
<br />
SHELL=/bin/sh<br />
HOMEDIR=/home/pacs/xyz00/users/list<br />
MAILDIR=/home/pacs/xyz00/users/list/Maildir<br />
PMDIR=/home/pacs/xyz00/users/list<br />
VERBOSE=yes<br />
LOGFILE=/home/pacs/xyz00/users/list/var/procmail.log<br />
DEFAULT<br />
<br />
:0:<br />
* ^X-Original-To: ()\/[^@+]+<br />
|/usr/bin/mlmmj-receive -F -L /home/pacs/xyz00/users/list/mlmmj/${MATCH}/<br />
<br />
:0<br />
{ EXITCODE 67 }<br />
<br />
<br />
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.<br />
<br />
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).<br />
<br />
== Links ==<br />
<br />
* http://mlmmj.org/ Projektseite<br />
* https://codeberg.org/mlmmj mlmmj auf Codeberg<br />
* https://github.com/tchapi/mlmmj-simple-web-interface ein Admin-Interface in NodeJS<br />
* https://www.tablix.org/~avian/blog/archives/2010/04/the_faulty_default/ Nutzung von mlmmj in Verbindung mit Procmail<br />
<br />
----<br />
[[Kategorie:HSDoku]]<br />
[[Kategorie:Installationsanleitungen]]<br />
[[Kategorie:Software]]<br />
[[Kategorie:Mailinglisten]]<br />
[[Kategorie:E-Mail]]</div>Apc00-tonyhttps://wiki.hostsharing.net/index.php?title=Mlmmj&diff=6405Mlmmj2024-02-02T11:24:15Z<p>Apc00-tony: /* Zur Konfiguration im Browser */ Patch vonnöten</p>
<hr />
<div>[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.<br />
<br />
Wer noch nicht weiß, was ein E-Mail-Verteiler machen soll oder wie, lese veilleicht auch den Wikipedia-Artikel:<br />
[http://de.wikipedia.org/wiki/Mailingliste Mailingliste]<br />
<br />
Eine leistungsfähigere Alternative zu mlmmj könnte [[Mailman_3_installieren|Mailman 3]] sein.<br />
<br />
Diese Anleitung beschreibt die Einrichtung einer Mailingliste für eine Domain in einem Hostsharing-Webspace.<br />
<br />
== Voraussetzungen ==<br />
<br />
Das Debian Paket [http://packages.debian.org/search?keywords=mlmmj mlmmj] ist auf den Shared-Hosting-Servern bereits installiert.<br />
<br />
Für den Betrieb der Mailingliste empfiehlt sich das Anlegen eines eigenen Users für diesen Zweck mit hsadmin.<br />
<br />
In dieser Anleitung heißt das Paket ''xyz00'' und der für Mailinglisten eingesetzte User ''xyz00-list''.<br />
<br />
Die E-Mail-Adresse der einzurichtende Mailing-Liste soll ''discuss@example.org'' sein.<br />
<br />
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.)<br />
<br />
== Einrichtung ==<br />
<br />
Ich melde mich über SSH auf der Hostsharing-Console als der Paketuser ''xyz00'' an.<br />
<br />
Im Shell kann ich dann durch den Befehl ''hsscript -i'' das Verwaltungswerkzeug [[hsadmin]] interaktiv ausführen:<br />
<br />
xyz00@h03:~$ hsscript -i<br />
Password: *************<br />
xyz00@hsadmin> <br />
<br />
In ''hsadmin'' werden User und E-Mail-Adresse angelegt.<br />
<br />
xyz00@hsadmin> user.add({set:{name:'xyz00-list',comment:'Mailingliste Discuss',shell:'/bin/bash',password:'geheimnis'}})<br />
xyz00@hsadmin> emailaddress.add({set:{target:'xyz00-list',localpart:'discuss',domain:'example.org'}})<br />
xyz00@hsadmin> bye<br />
<br />
Mit dem Parameter "target" wird die für diese Adresse eingehende Post zunächst in das Postfach des Users xyz00-list abgelegt.<br />
<br />
Für den User xyz00-list lege ich in seinem Heimat-Verzeichnis das Unterverzeichnis <tt>mlmmj</tt> an:<br />
<br />
mkdir /home/pacs/xyz00/users/list/mlmmj<br />
<br />
Dann lege ich die Mailingliste mit folgendem Kommando an:<br />
<br />
mlmmj-make-ml -L discuss -s /home/pacs/xyz00/users/list/mlmmj<br />
<br />
Das Skript ''mlmmj-make-ml'' fragt weitere Parameter der Mailingliste ab:<br />
<br />
The Domain for the List? [] : example.org<br />
The emailaddress of the list owner? [postmaster] : webmaster@example.org<br />
For the list texts you can choose between the following languages or<br />
give an absolute path to a directory containing the texts.<br />
Available languages:<br />
cz da de en es fr it nl ru<br />
The path to texts for the list? [en] : de<br />
<br />
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.<br />
<br />
Weitere Konfigurationen der Liste erfolgen durch das Anlegen von Dateien im<br />
Verzeichnis "/home/pacs/xyz00/users/list/mlmmj/discuss/control".<br />
Die Konfigurationsmöglichkeiten finden Sie auf der [http://mlmmj.org/docs/tunables/ Internetseite von mlmmj].<br />
<br />
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:<br />
<br />
"|/usr/bin/mlmmj-recieve -L /home/pacs/xyz00/users/list/mlmmj/discuss/"<br />
<br />
(Ja, ''receive'' schreibt sich mit ''-ei-'', aber mlmmj hält einen symbolischen Link bereit für diejenigen, die in englischer Rechtschreibung unsicher sind:)<br />
<br />
xyz00-list@h03:~$ ls -la /usr/bin/mlmmj-rec*<br />
-rwxr-xr-x 1 root root 27104 Sep 25 2018 /usr/bin/mlmmj-receive<br />
lrwxrwxrwx 1 root root 13 Sep 25 2018 /usr/bin/mlmmj-recieve -> mlmmj-receive<br />
<br />
Die <tt>.forward</tt>-Datei sorgt dafür, dass eingehende E-Mails an das User-Postfach an das Programm ''mlmmj-recieve'' übergeben werden.<br />
<br />
Für regelmäßige Aufgaben der Listen-Managers definiere ich die<br />
[[Cron|crontab]] wie folgt (immer noch als ''xyz00-list''):<br />
<br />
xyz00-list@h03:~$ crontab -e<br />
<br />
MAILTO=webmaster@example.org<br />
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin<br />
HOME=/home/pacs/xyz00/users/list<br />
SHELL=/bin/bash<br />
LANG=en_US.UTF-8<br />
# m h dom mon dow command<br />
28 */4 * * * /usr/bin/mlmmj-maintd -d /home/pacs/xyz00/users/list/mlmmj -F<br />
<br />
Zum Schluss rufe ich das Skript mlmmj-sub auf, um die E-Mail-Adressen der gewünschten Abonnenten des Verteilers einzutragen:<br />
<br />
/usr/bin/mlmmj-sub -L /home/pacs/xyz00/users/list/mlmmj/discuss -a klaus.muster@gmx.de -c <br />
/usr/bin/mlmmj-sub -L /home/pacs/xyz00/users/list/mlmmj/discuss -a sabine.beispiel@arcor.de -c <br />
<br />
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.<br />
<br />
== weitere Optionen ==<br />
<br />
Noch ein paar Dinge, die Sie möglicherweise einstellen wollen:<br />
<br />
Ein Prefix in der Betreffzeile setzen, z.B.: "[discuss]".<br />
<br />
echo "[discuss]" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/prefix<br />
<br />
Wenn die Liste nur E-Mails von eingetragenen Abonnenten weiterleiten soll:<br />
<br />
touch /home/pacs/xyz00/users/list/mlmmj/discuss/control/subonlypost<br />
<br />
Damit der Listen-Owner weitere Abonnements bestätigen muss:<br />
<br />
touch /home/pacs/xyz00/users/list/mlmmj/discuss/control/submod<br />
<br />
Einen "Reply-To:"-Header setzen, damit Antwort-Mails standardmäßig an die Mailing-Liste gehen:<br />
<br />
echo "Reply-To:" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/delheaders<br />
echo "Reply-To: discuss@example.org" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/customheaders<br />
<br />
Weitere Möglichkeiten finden Sie (wie oben bereits angegeben) <br />
auf der [http://mlmmj.org/docs/tunables/ Internetseite von mlmmj].<br />
<br />
== Zur Konfiguration im Browser ==<br />
<br />
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.<br />
<br />
Wer es sich ansehen möchte:<br />
<br />
Als Paket-Admin eine Domain aufschalten:<br />
<br />
hsscript -u xyz00 -e "domain.add({set:{name:'lists.example.org',user:'xyz00-list'}})"<br />
<br />
Und weiter als "xyz00-list".<br />
<br />
Download der neuesten Version der Sourcen von mlmmj von http://mlmmj.org/downloads/ und diese in einem temporären Verzeichnis entpacken.<br />
<br />
Unter "/mlmmj-$versionsnummer/contrib/web/php-admin/" findet sich die PHP-Admin-Anwendung. Also ... <br />
<br />
* den Inhalt diese Verzeichnisses nach "/home/pacs/xyz00/users/list/doms/lists.example.org/" packen;<br />
* in "/home/pacs/xyz00/users/list/doms/lists.example.org/conf/config.php" die Variable "$topdir" anpassen;<br />
* 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;<br />
* 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: <br />
<br />
Require valid-user<br />
AuthType Basic<br />
AuthName "mlmmj web-interface"<br />
AuthUserFile /home/pacs/xyz00/users/list/doms/lists.example.org/etc/htpasswd<br />
<br />
* Und schließlich die "htpasswd"-Datei anlegen.<br />
<br />
cd /home/pacs/xyz00/users/list/doms/lists.example.org/etc/<br />
htpasswd -c htpasswd listadmin<br />
<br />
* Ein Passwort angeben.<br />
<br />
Nun enthält diese PHP-Anwendung leider noch eine Zeile, die schon seit PHP 7 nicht mehr lauffähig ist. Also muß man noch<br />
<br />
* in <tt>.../htdocs-ssl/index.php</tt> folgende Änderung vornehmen:<br />
<br />
@@ -38,6 +38,7 @@<br />
# use scandir to have alphabetical order <br />
foreach (scandir($topdir) as $file) {<br />
- if (!ereg("^\.",$file))<br />
+# ereg obsolete!! Vormals: if (!ereg("^\.",$file))<br />
+ if (!preg_match('/^\./',$file))<br />
{<br />
$lists .= "<p>".htmlentities($file)."<br/>\n";<br />
$lists .= "<a href=\"edit.php?list=".urlencode($file)."\">Config</a> - <a href=\"subscribers.php?list=".urlencode($file)."\">Subscribers</a>\n";<br />
<br />
<br />
und das Ergebnis auf https://lists.example.org anschauen.<br />
<br />
== Mehrere Mailinglisten betreiben ==<br />
<br />
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.<br />
<br />
Dazu trägt man in der Date ''.forward'' statt des Aufrufs von ''mlmmj-recieve'' einen Aufruf von ''procmail'' ein:<br />
<br />
|/usr/bin/procmail<br />
<br />
Die Konfiguration von Procmail kann generisch erfolgen. Dazu legt man eine Datei ''.procmailrc'' mit folgendem Inhalt ins $HOME des Users:<br />
<br />
SHELL=/bin/sh<br />
HOMEDIR=/home/pacs/xyz00/users/list<br />
MAILDIR=/home/pacs/xyz00/users/list/Maildir<br />
PMDIR=/home/pacs/xyz00/users/list<br />
VERBOSE=yes<br />
LOGFILE=/home/pacs/xyz00/users/list/var/procmail.log<br />
DEFAULT<br />
<br />
:0:<br />
* ^X-Original-To: ()\/[^@+]+<br />
|/usr/bin/mlmmj-receive -F -L /home/pacs/xyz00/users/list/mlmmj/${MATCH}/<br />
<br />
:0<br />
{ EXITCODE 67 }<br />
<br />
<br />
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.<br />
<br />
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).<br />
<br />
== Links ==<br />
<br />
* http://mlmmj.org/ Projektseite<br />
* https://codeberg.org/mlmmj mlmmj auf Codeberg<br />
* https://github.com/tchapi/mlmmj-simple-web-interface ein Admin-Interface in NodeJS<br />
* https://www.tablix.org/~avian/blog/archives/2010/04/the_faulty_default/ Nutzung von mlmmj in Verbindung mit Procmail<br />
<br />
----<br />
[[Kategorie:HSDoku]]<br />
[[Kategorie:Installationsanleitungen]]<br />
[[Kategorie:Software]]<br />
[[Kategorie:Mailinglisten]]<br />
[[Kategorie:E-Mail]]</div>Apc00-tonyhttps://wiki.hostsharing.net/index.php?title=Mlmmj&diff=6403Mlmmj2024-02-01T15:38:01Z<p>Apc00-tony: Wiki-links</p>
<hr />
<div>[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.<br />
<br />
Wer noch nicht weiß, was ein E-Mail-Verteiler machen soll oder wie, lese veilleicht auch den Wikipedia-Artikel:<br />
[http://de.wikipedia.org/wiki/Mailingliste Mailingliste]<br />
<br />
Eine leistungsfähigere Alternative zu mlmmj könnte [[Mailman_3_installieren|Mailman 3]] sein.<br />
<br />
Diese Anleitung beschreibt die Einrichtung einer Mailingliste für eine Domain in einem Hostsharing-Webspace.<br />
<br />
== Voraussetzungen ==<br />
<br />
Das Debian Paket [http://packages.debian.org/search?keywords=mlmmj mlmmj] ist auf den Shared-Hosting-Servern bereits installiert.<br />
<br />
Für den Betrieb der Mailingliste empfiehlt sich das Anlegen eines eigenen Users für diesen Zweck mit hsadmin.<br />
<br />
In dieser Anleitung heißt das Paket ''xyz00'' und der für Mailinglisten eingesetzte User ''xyz00-list''.<br />
<br />
Die E-Mail-Adresse der einzurichtende Mailing-Liste soll ''discuss@example.org'' sein.<br />
<br />
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.)<br />
<br />
== Einrichtung ==<br />
<br />
Ich melde mich über SSH auf der Hostsharing-Console als der Paketuser ''xyz00'' an.<br />
<br />
Im Shell kann ich dann durch den Befehl ''hsscript -i'' das Verwaltungswerkzeug [[hsadmin]] interaktiv ausführen:<br />
<br />
xyz00@h03:~$ hsscript -i<br />
Password: *************<br />
xyz00@hsadmin> <br />
<br />
In ''hsadmin'' werden User und E-Mail-Adresse angelegt.<br />
<br />
xyz00@hsadmin> user.add({set:{name:'xyz00-list',comment:'Mailingliste Discuss',shell:'/bin/bash',password:'geheimnis'}})<br />
xyz00@hsadmin> emailaddress.add({set:{target:'xyz00-list',localpart:'discuss',domain:'example.org'}})<br />
xyz00@hsadmin> bye<br />
<br />
Mit dem Parameter "target" wird die für diese Adresse eingehende Post zunächst in das Postfach des Users xyz00-list abgelegt.<br />
<br />
Für den User xyz00-list lege ich in seinem Heimat-Verzeichnis das Unterverzeichnis <tt>mlmmj</tt> an:<br />
<br />
mkdir /home/pacs/xyz00/users/list/mlmmj<br />
<br />
Dann lege ich die Mailingliste mit folgendem Kommando an:<br />
<br />
mlmmj-make-ml -L discuss -s /home/pacs/xyz00/users/list/mlmmj<br />
<br />
Das Skript ''mlmmj-make-ml'' fragt weitere Parameter der Mailingliste ab:<br />
<br />
The Domain for the List? [] : example.org<br />
The emailaddress of the list owner? [postmaster] : webmaster@example.org<br />
For the list texts you can choose between the following languages or<br />
give an absolute path to a directory containing the texts.<br />
Available languages:<br />
cz da de en es fr it nl ru<br />
The path to texts for the list? [en] : de<br />
<br />
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.<br />
<br />
Weitere Konfigurationen der Liste erfolgen durch das Anlegen von Dateien im<br />
Verzeichnis "/home/pacs/xyz00/users/list/mlmmj/discuss/control".<br />
Die Konfigurationsmöglichkeiten finden Sie auf der [http://mlmmj.org/docs/tunables/ Internetseite von mlmmj].<br />
<br />
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:<br />
<br />
"|/usr/bin/mlmmj-recieve -L /home/pacs/xyz00/users/list/mlmmj/discuss/"<br />
<br />
(Ja, ''receive'' schreibt sich mit ''-ei-'', aber mlmmj hält einen symbolischen Link bereit für diejenigen, die in englischer Rechtschreibung unsicher sind:)<br />
<br />
xyz00-list@h03:~$ ls -la /usr/bin/mlmmj-rec*<br />
-rwxr-xr-x 1 root root 27104 Sep 25 2018 /usr/bin/mlmmj-receive<br />
lrwxrwxrwx 1 root root 13 Sep 25 2018 /usr/bin/mlmmj-recieve -> mlmmj-receive<br />
<br />
Die <tt>.forward</tt>-Datei sorgt dafür, dass eingehende E-Mails an das User-Postfach an das Programm ''mlmmj-recieve'' übergeben werden.<br />
<br />
Für regelmäßige Aufgaben der Listen-Managers definiere ich die<br />
[[Cron|crontab]] wie folgt (immer noch als ''xyz00-list''):<br />
<br />
xyz00-list@h03:~$ crontab -e<br />
<br />
MAILTO=webmaster@example.org<br />
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin<br />
HOME=/home/pacs/xyz00/users/list<br />
SHELL=/bin/bash<br />
LANG=en_US.UTF-8<br />
# m h dom mon dow command<br />
28 */4 * * * /usr/bin/mlmmj-maintd -d /home/pacs/xyz00/users/list/mlmmj -F<br />
<br />
Zum Schluss rufe ich das Skript mlmmj-sub auf, um die E-Mail-Adressen der gewünschten Abonnenten des Verteilers einzutragen:<br />
<br />
/usr/bin/mlmmj-sub -L /home/pacs/xyz00/users/list/mlmmj/discuss -a klaus.muster@gmx.de -c <br />
/usr/bin/mlmmj-sub -L /home/pacs/xyz00/users/list/mlmmj/discuss -a sabine.beispiel@arcor.de -c <br />
<br />
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.<br />
<br />
== weitere Optionen ==<br />
<br />
Noch ein paar Dinge, die Sie möglicherweise einstellen wollen:<br />
<br />
Ein Prefix in der Betreffzeile setzen, z.B.: "[discuss]".<br />
<br />
echo "[discuss]" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/prefix<br />
<br />
Wenn die Liste nur E-Mails von eingetragenen Abonnenten weiterleiten soll:<br />
<br />
touch /home/pacs/xyz00/users/list/mlmmj/discuss/control/subonlypost<br />
<br />
Damit der Listen-Owner weitere Abonnements bestätigen muss:<br />
<br />
touch /home/pacs/xyz00/users/list/mlmmj/discuss/control/submod<br />
<br />
Einen "Reply-To:"-Header setzen, damit Antwort-Mails standardmäßig an die Mailing-Liste gehen:<br />
<br />
echo "Reply-To:" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/delheaders<br />
echo "Reply-To: discuss@example.org" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/customheaders<br />
<br />
Weitere Möglichkeiten finden Sie (wie oben bereits angegeben) <br />
auf der [http://mlmmj.org/docs/tunables/ Internetseite von mlmmj].<br />
<br />
== Zur Konfiguration im Browser ==<br />
<br />
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.<br />
<br />
Wer es sich ansehen möchte:<br />
<br />
Als Paket-Admin eine Domain aufschalten:<br />
<br />
hsscript -u xyz00 -e "domain.add({set:{name:'lists.example.org',user:'xyz00-list'}})"<br />
<br />
Und weiter als "xyz00-list".<br />
<br />
Download der neuesten Version der Sourcen von mlmmj von http://mlmmj.org/downloads/ und diese in einem temporären Verzeichnis entpacken.<br />
<br />
Unter "/mlmmj-$versionsnummer/contrib/web/php-admin/" findet sich die PHP-Admin-Anwendung.<br />
<br />
Also den Inhalt diese Verzeichnisses nach "/home/pacs/xyz00/users/list/doms/lists.example.org/" packen,<br />
* in "/home/pacs/xyz00/users/list/doms/lists.example.org/conf/config.php" die Variable "$topdir" anpassen<br />
* 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<br />
* 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: <br />
<br />
Require valid-user<br />
AuthType Basic<br />
AuthName "mlmmj web-interface"<br />
AuthUserFile /home/pacs/xyz00/users/list/doms/lists.example.org/etc/htpasswd<br />
<br />
Und schließlich die "htpasswd"-Datei anlegen.<br />
<br />
cd /home/pacs/xyz00/users/list/doms/lists.example.org/etc/<br />
htpasswd -c htpasswd listadmin<br />
<br />
Ein Passwort angeben und auf<br />
https://lists.example.org schauen.<br />
<br />
== Mehrere Mailinglisten betreiben ==<br />
<br />
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.<br />
<br />
Dazu trägt man in der Date ''.forward'' statt des Aufrufs von ''mlmmj-recieve'' einen Aufruf von ''procmail'' ein:<br />
<br />
|/usr/bin/procmail<br />
<br />
Die Konfiguration von Procmail kann generisch erfolgen. Dazu legt man eine Datei ''.procmailrc'' mit folgendem Inhalt ins $HOME des Users:<br />
<br />
SHELL=/bin/sh<br />
HOMEDIR=/home/pacs/xyz00/users/list<br />
MAILDIR=/home/pacs/xyz00/users/list/Maildir<br />
PMDIR=/home/pacs/xyz00/users/list<br />
VERBOSE=yes<br />
LOGFILE=/home/pacs/xyz00/users/list/var/procmail.log<br />
DEFAULT<br />
<br />
:0:<br />
* ^X-Original-To: ()\/[^@+]+<br />
|/usr/bin/mlmmj-receive -F -L /home/pacs/xyz00/users/list/mlmmj/${MATCH}/<br />
<br />
:0<br />
{ EXITCODE 67 }<br />
<br />
<br />
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.<br />
<br />
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).<br />
<br />
== Links ==<br />
<br />
* http://mlmmj.org/ Projektseite<br />
* https://codeberg.org/mlmmj mlmmj auf Codeberg<br />
* https://github.com/tchapi/mlmmj-simple-web-interface ein Admin-Interface in NodeJS<br />
* https://www.tablix.org/~avian/blog/archives/2010/04/the_faulty_default/ Nutzung von mlmmj in Verbindung mit Procmail<br />
<br />
----<br />
[[Kategorie:HSDoku]]<br />
[[Kategorie:Installationsanleitungen]]<br />
[[Kategorie:Software]]<br />
[[Kategorie:Mailinglisten]]<br />
[[Kategorie:E-Mail]]</div>Apc00-tonyhttps://wiki.hostsharing.net/index.php?title=Mlmmj&diff=6402Mlmmj2024-02-01T14:10:41Z<p>Apc00-tony: /* mlmmj */ Gliederung</p>
<hr />
<div>[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.<br />
<br />
Wer noch nicht weiß, was ein E-Mail-Verteiler machen soll oder wie, lese veilleicht auch den Wikipedia-Artikel:<br />
[http://de.wikipedia.org/wiki/Mailingliste Mailingliste]<br />
<br />
Eine leistungsfähigere Alternative zu mlmmj könnte [[Mailman_3_installieren|Mailman 3]] sein.<br />
<br />
Diese Anleitung beschreibt die Einrichtung einer Mailingliste für eine Domain in einem Hostsharing-Webspace.<br />
<br />
== Voraussetzungen ==<br />
<br />
Das Debian Paket [http://packages.debian.org/search?keywords=mlmmj mlmmj] ist auf den Shared-Hosting-Servern bereits installiert.<br />
<br />
Für den Betrieb der Mailingliste empfiehlt sich das Anlegen eines eigenen Users für diesen Zweck mit hsadmin.<br />
<br />
In dieser Anleitung heißt das Paket ''xyz00'' und der für Mailinglisten eingesetzte User ''xyz00-list''.<br />
<br />
Die E-Mail-Adresse der einzurichtende Mailing-Liste soll ''discuss@example.org'' sein.<br />
<br />
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.)<br />
<br />
== Einrichtung ==<br />
<br />
Ich melde mich über SSH auf der Hostsharing-Console als der Paketuser ''xyz00'' an.<br />
<br />
Im Shell kann ich dann durch den Befehl ''hsscript -i'' das Verwaltungswerkzeug ''hsadmin'' interaktiv ausführen:<br />
<br />
xyz00@h03:~$ hsscript -i<br />
Password: *************<br />
xyz00@hsadmin> <br />
<br />
In ''hsadmin'' werden User und E-Mail-Adresse angelegt.<br />
<br />
xyz00@hsadmin> user.add({set:{name:'xyz00-list',comment:'Mailingliste Discuss',shell:'/bin/bash',password:'geheimnis'}})<br />
xyz00@hsadmin> emailaddress.add({set:{target:'xyz00-list',localpart:'discuss',domain:'example.org'}})<br />
xyz00@hsadmin> bye<br />
<br />
Mit dem Parameter "target" wird die für diese Adresse eingehende Post zunächst in das Postfach des Users xyz00-list abgelegt.<br />
<br />
Für den User xyz00-list lege ich in seinem Heimat-Verzeichnis das Unterverzeichnis "mlmmj" an:<br />
<br />
mkdir /home/pacs/xyz00/users/list/mlmmj<br />
<br />
Dann lege ich die Mailingliste mit folgendem Kommando an:<br />
<br />
mlmmj-make-ml -L discuss -s /home/pacs/xyz00/users/list/mlmmj<br />
<br />
Das Skript ''mlmmj-make-ml'' fragt weitere Parameter der Mailingliste ab:<br />
<br />
The Domain for the List? [] : example.org<br />
The emailaddress of the list owner? [postmaster] : webmaster@example.org<br />
For the list texts you can choose between the following languages or<br />
give an absolute path to a directory containing the texts.<br />
Available languages:<br />
cz da de en es fr it nl ru<br />
The path to texts for the list? [en] : de<br />
<br />
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.<br />
<br />
Weitere Konfigurationen der Liste erfolgen durch das Anlegen von Dateien im<br />
Verzeichnis "/home/pacs/xyz00/users/list/mlmmj/discuss/control".<br />
Die Konfigurationsmöglichkeiten finden Sie auf der [http://mlmmj.org/docs/tunables/ Internetseite von mlmmj].<br />
<br />
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:<br />
<br />
"|/usr/bin/mlmmj-recieve -L /home/pacs/xyz00/users/list/mlmmj/discuss/"<br />
<br />
(Ja, ''receive'' schreibt sich mit ''-ei-'', aber mlmmj hält einen symbolischen Link bereit für diejenigen, die in englischer Rechtschreibung unsicher sind:)<br />
<br />
xyz00-list@h03:~$ ls -la /usr/bin/mlmmj-rec*<br />
-rwxr-xr-x 1 root root 27104 Sep 25 2018 /usr/bin/mlmmj-receive<br />
lrwxrwxrwx 1 root root 13 Sep 25 2018 /usr/bin/mlmmj-recieve -> mlmmj-receive<br />
<br />
Die <tt>.forward</tt>-Datei sorgt dafür, dass eingehende E-Mails an das User-Postfach an das Programm ''mlmmj-recieve'' übergeben werden.<br />
<br />
Für regelmäßige Aufgaben der Listen-Managers definiere ich die<br />
crontab wie folgt (immer noch als ''xyz00-list''):<br />
<br />
xyz00-list@h03:~$ crontab -e<br />
<br />
MAILTO=webmaster@example.org<br />
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin<br />
HOME=/home/pacs/xyz00/users/list<br />
SHELL=/bin/bash<br />
LANG=en_US.UTF-8<br />
# m h dom mon dow command<br />
28 */4 * * * /usr/bin/mlmmj-maintd -d /home/pacs/xyz00/users/list/mlmmj -F<br />
<br />
Zum Schluss rufe ich das Skript mlmmj-sub auf, um die E-Mail-Adressen der gewünschten Abonnenten des Verteilers einzutragen:<br />
<br />
/usr/bin/mlmmj-sub -L /home/pacs/xyz00/users/list/mlmmj/discuss -a klaus.muster@gmx.de -c <br />
/usr/bin/mlmmj-sub -L /home/pacs/xyz00/users/list/mlmmj/discuss -a sabine.beispiel@arcor.de -c <br />
<br />
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.<br />
<br />
== weitere Optionen ==<br />
<br />
Noch ein paar Dinge, die Sie möglicherweise einstellen wollen:<br />
<br />
Ein Prefix in der Betreffzeile setzen, z.B.: "[discuss]".<br />
<br />
echo "[discuss]" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/prefix<br />
<br />
Wenn die Liste nur E-Mails von eingetragenen Abonnenten weiterleiten soll:<br />
<br />
touch /home/pacs/xyz00/users/list/mlmmj/discuss/control/subonlypost<br />
<br />
Damit der Listen-Owner weitere Abonnements bestätigen muss:<br />
<br />
touch /home/pacs/xyz00/users/list/mlmmj/discuss/control/submod<br />
<br />
Einen "Reply-To:"-Header setzen, damit Antwort-Mails standardmäßig an die Mailing-Liste gehen:<br />
<br />
echo "Reply-To:" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/delheaders<br />
echo "Reply-To: discuss@example.org" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/customheaders<br />
<br />
Weitere Möglichkeiten finden Sie (wie oben bereits angegeben) <br />
auf der [http://mlmmj.org/docs/tunables/ Internetseite von mlmmj].<br />
<br />
== Zur Konfiguration im Browser ==<br />
<br />
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.<br />
<br />
Wer es sich ansehen möchte:<br />
<br />
Als Paket-Admin eine Domain aufschalten:<br />
<br />
hsscript -u xyz00 -e "domain.add({set:{name:'lists.example.org',user:'xyz00-list'}})"<br />
<br />
Und weiter als "xyz00-list".<br />
<br />
Download der neuesten Version der Sourcen von mlmmj von http://mlmmj.org/downloads/ und diese in einem temporären Verzeichnis entpacken.<br />
<br />
Unter "/mlmmj-$versionsnummer/contrib/web/php-admin/" findet sich die PHP-Admin-Anwendung.<br />
<br />
Also den Inhalt diese Verzeichnisses nach "/home/pacs/xyz00/users/list/doms/lists.example.org/" packen,<br />
* in "/home/pacs/xyz00/users/list/doms/lists.example.org/conf/config.php" die Variable "$topdir" anpassen<br />
* 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<br />
* 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: <br />
<br />
Require valid-user<br />
AuthType Basic<br />
AuthName "mlmmj web-interface"<br />
AuthUserFile /home/pacs/xyz00/users/list/doms/lists.example.org/etc/htpasswd<br />
<br />
Und schließlich die "htpasswd"-Datei anlegen.<br />
<br />
cd /home/pacs/xyz00/users/list/doms/lists.example.org/etc/<br />
htpasswd -c htpasswd listadmin<br />
<br />
Ein Passwort angeben und auf<br />
https://lists.example.org schauen.<br />
<br />
== Mehrere Mailinglisten betreiben ==<br />
<br />
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.<br />
<br />
Dazu trägt man in der Date ''.forward'' statt des Aufrufs von ''mlmmj-recieve'' einen Aufruf von ''procmail'' ein:<br />
<br />
|/usr/bin/procmail<br />
<br />
Die Konfiguration von Procmail kann generisch erfolgen. Dazu legt man eine Datei ''.procmailrc'' mit folgendem Inhalt ins $HOME des Users:<br />
<br />
SHELL=/bin/sh<br />
HOMEDIR=/home/pacs/xyz00/users/list<br />
MAILDIR=/home/pacs/xyz00/users/list/Maildir<br />
PMDIR=/home/pacs/xyz00/users/list<br />
VERBOSE=yes<br />
LOGFILE=/home/pacs/xyz00/users/list/var/procmail.log<br />
DEFAULT<br />
<br />
:0:<br />
* ^X-Original-To: ()\/[^@+]+<br />
|/usr/bin/mlmmj-receive -F -L /home/pacs/xyz00/users/list/mlmmj/${MATCH}/<br />
<br />
:0<br />
{ EXITCODE 67 }<br />
<br />
<br />
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.<br />
<br />
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).<br />
<br />
== Links ==<br />
<br />
* http://mlmmj.org/ Projektseite<br />
* https://codeberg.org/mlmmj mlmmj auf Codeberg<br />
* https://github.com/tchapi/mlmmj-simple-web-interface ein Admin-Interface in NodeJS<br />
* https://www.tablix.org/~avian/blog/archives/2010/04/the_faulty_default/ Nutzung von mlmmj in Verbindung mit Procmail<br />
<br />
----<br />
[[Kategorie:HSDoku]]<br />
[[Kategorie:Installationsanleitungen]]<br />
[[Kategorie:Software]]<br />
[[Kategorie:Mailinglisten]]<br />
[[Kategorie:E-Mail]]</div>Apc00-tonyhttps://wiki.hostsharing.net/index.php?title=Mlmmj&diff=6401Mlmmj2024-02-01T14:08:45Z<p>Apc00-tony: Gliederung</p>
<hr />
<div>[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.<br />
<br />
Wer noch nicht weiß, was ein E-Mail-Verteiler machen soll oder wie, lese veilleicht auch den Wikipedia-Artikel:<br />
[http://de.wikipedia.org/wiki/Mailingliste Mailingliste]<br />
<br />
Eine leistungsfähigere Alternative zu mlmmj könnte [[Mailman_3_installieren|Mailman 3]] sein.<br />
<br />
Diese Anleitung beschreibt die Einrichtung einer Mailingliste für eine Domain in einem Hostsharing-Webspace.<br />
<br />
== mlmmj ==<br />
<br />
Das Debian Paket [http://packages.debian.org/search?keywords=mlmmj mlmmj] ist auf den Shared-Hosting-Servern bereits installiert.<br />
<br />
=== Voraussetzungen ===<br />
<br />
Für den Betrieb der Mailingliste empfiehlt sich das Anlegen eines eigenen Users für diesen Zweck mit hsadmin.<br />
<br />
In dieser Anleitung heißt das Paket ''xyz00'' und der für Mailinglisten eingesetzte User ''xyz00-list''.<br />
<br />
Die E-Mail-Adresse der einzurichtende Mailing-Liste soll ''discuss@example.org'' sein.<br />
<br />
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.)<br />
<br />
=== Einrichtung ===<br />
<br />
Ich melde mich über SSH auf der Hostsharing-Console als der Paketuser ''xyz00'' an.<br />
<br />
Im Shell kann ich dann durch den Befehl ''hsscript -i'' das Verwaltungswerkzeug ''hsadmin'' interaktiv ausführen:<br />
<br />
xyz00@h03:~$ hsscript -i<br />
Password: *************<br />
xyz00@hsadmin> <br />
<br />
In ''hsadmin'' werden User und E-Mail-Adresse angelegt.<br />
<br />
xyz00@hsadmin> user.add({set:{name:'xyz00-list',comment:'Mailingliste Discuss',shell:'/bin/bash',password:'geheimnis'}})<br />
xyz00@hsadmin> emailaddress.add({set:{target:'xyz00-list',localpart:'discuss',domain:'example.org'}})<br />
xyz00@hsadmin> bye<br />
<br />
Mit dem Parameter "target" wird die für diese Adresse eingehende Post zunächst in das Postfach des Users xyz00-list abgelegt.<br />
<br />
Für den User xyz00-list lege ich in seinem Heimat-Verzeichnis das Unterverzeichnis "mlmmj" an:<br />
<br />
mkdir /home/pacs/xyz00/users/list/mlmmj<br />
<br />
Dann lege ich die Mailingliste mit folgendem Kommando an:<br />
<br />
mlmmj-make-ml -L discuss -s /home/pacs/xyz00/users/list/mlmmj<br />
<br />
Das Skript ''mlmmj-make-ml'' fragt weitere Parameter der Mailingliste ab:<br />
<br />
The Domain for the List? [] : example.org<br />
The emailaddress of the list owner? [postmaster] : webmaster@example.org<br />
For the list texts you can choose between the following languages or<br />
give an absolute path to a directory containing the texts.<br />
Available languages:<br />
cz da de en es fr it nl ru<br />
The path to texts for the list? [en] : de<br />
<br />
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.<br />
<br />
Weitere Konfigurationen der Liste erfolgen durch das Anlegen von Dateien im<br />
Verzeichnis "/home/pacs/xyz00/users/list/mlmmj/discuss/control".<br />
Die Konfigurationsmöglichkeiten finden Sie auf der [http://mlmmj.org/docs/tunables/ Internetseite von mlmmj].<br />
<br />
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:<br />
<br />
"|/usr/bin/mlmmj-recieve -L /home/pacs/xyz00/users/list/mlmmj/discuss/"<br />
<br />
(Ja, ''receive'' schreibt sich mit ''-ei-'', aber mlmmj hält einen symbolischen Link bereit für diejenigen, die in englischer Rechtschreibung unsicher sind:)<br />
<br />
xyz00-list@h03:~$ ls -la /usr/bin/mlmmj-rec*<br />
-rwxr-xr-x 1 root root 27104 Sep 25 2018 /usr/bin/mlmmj-receive<br />
lrwxrwxrwx 1 root root 13 Sep 25 2018 /usr/bin/mlmmj-recieve -> mlmmj-receive<br />
<br />
Die <tt>.forward</tt>-Datei sorgt dafür, dass eingehende E-Mails an das User-Postfach an das Programm ''mlmmj-recieve'' übergeben werden.<br />
<br />
Für regelmäßige Aufgaben der Listen-Managers definiere ich die<br />
crontab wie folgt (immer noch als ''xyz00-list''):<br />
<br />
xyz00-list@h03:~$ crontab -e<br />
<br />
MAILTO=webmaster@example.org<br />
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin<br />
HOME=/home/pacs/xyz00/users/list<br />
SHELL=/bin/bash<br />
LANG=en_US.UTF-8<br />
# m h dom mon dow command<br />
28 */4 * * * /usr/bin/mlmmj-maintd -d /home/pacs/xyz00/users/list/mlmmj -F<br />
<br />
Zum Schluss rufe ich das Skript mlmmj-sub auf, um die E-Mail-Adressen der gewünschten Abonnenten des Verteilers einzutragen:<br />
<br />
/usr/bin/mlmmj-sub -L /home/pacs/xyz00/users/list/mlmmj/discuss -a klaus.muster@gmx.de -c <br />
/usr/bin/mlmmj-sub -L /home/pacs/xyz00/users/list/mlmmj/discuss -a sabine.beispiel@arcor.de -c <br />
<br />
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.<br />
<br />
=== weitere Konfiguration ===<br />
<br />
Noch ein paar Dinge, die Sie möglicherweise einstellen wollen:<br />
<br />
Ein Prefix in der Betreffzeile setzen, z.B.: "[discuss]".<br />
<br />
echo "[discuss]" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/prefix<br />
<br />
Wenn die Liste nur E-Mails von eingetragenen Abonnenten weiterleiten soll:<br />
<br />
touch /home/pacs/xyz00/users/list/mlmmj/discuss/control/subonlypost<br />
<br />
Damit der Listen-Owner weitere Abonnements bestätigen muss:<br />
<br />
touch /home/pacs/xyz00/users/list/mlmmj/discuss/control/submod<br />
<br />
Einen "Reply-To:"-Header setzen, damit Antwort-Mails standardmäßig an die Mailing-Liste gehen:<br />
<br />
echo "Reply-To:" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/delheaders<br />
echo "Reply-To: discuss@example.org" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/customheaders<br />
<br />
Weitere Möglichkeiten finden Sie (wie oben bereits angegeben) <br />
auf der [http://mlmmj.org/docs/tunables/ Internetseite von mlmmj].<br />
<br />
=== Konfiguration im Browser ===<br />
<br />
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.<br />
<br />
Wer es sich ansehen möchte:<br />
<br />
Als Paket-Admin eine Domain aufschalten:<br />
<br />
hsscript -u xyz00 -e "domain.add({set:{name:'lists.example.org',user:'xyz00-list'}})"<br />
<br />
Und weiter als "xyz00-list".<br />
<br />
Download der neuesten Version der Sourcen von mlmmj von http://mlmmj.org/downloads/ und diese in einem temporären Verzeichnis entpacken.<br />
<br />
Unter "/mlmmj-$versionsnummer/contrib/web/php-admin/" findet sich die PHP-Admin-Anwendung.<br />
<br />
Also den Inhalt diese Verzeichnisses nach "/home/pacs/xyz00/users/list/doms/lists.example.org/" packen,<br />
* in "/home/pacs/xyz00/users/list/doms/lists.example.org/conf/config.php" die Variable "$topdir" anpassen<br />
* 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<br />
* 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: <br />
<br />
Require valid-user<br />
AuthType Basic<br />
AuthName "mlmmj web-interface"<br />
AuthUserFile /home/pacs/xyz00/users/list/doms/lists.example.org/etc/htpasswd<br />
<br />
Und schließlich die "htpasswd"-Datei anlegen.<br />
<br />
cd /home/pacs/xyz00/users/list/doms/lists.example.org/etc/<br />
htpasswd -c htpasswd listadmin<br />
<br />
Ein Passwort angeben und auf<br />
https://lists.example.org schauen.<br />
<br />
== Mehrere Mailinglisten betreiben ==<br />
<br />
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.<br />
<br />
Dazu trägt man in der Date ''.forward'' statt des Aufrufs von ''mlmmj-recieve'' einen Aufruf von ''procmail'' ein:<br />
<br />
|/usr/bin/procmail<br />
<br />
Die Konfiguration von Procmail kann generisch erfolgen. Dazu legt man eine Datei ''.procmailrc'' mit folgendem Inhalt ins $HOME des Users:<br />
<br />
SHELL=/bin/sh<br />
HOMEDIR=/home/pacs/xyz00/users/list<br />
MAILDIR=/home/pacs/xyz00/users/list/Maildir<br />
PMDIR=/home/pacs/xyz00/users/list<br />
VERBOSE=yes<br />
LOGFILE=/home/pacs/xyz00/users/list/var/procmail.log<br />
DEFAULT<br />
<br />
:0:<br />
* ^X-Original-To: ()\/[^@+]+<br />
|/usr/bin/mlmmj-receive -F -L /home/pacs/xyz00/users/list/mlmmj/${MATCH}/<br />
<br />
:0<br />
{ EXITCODE 67 }<br />
<br />
<br />
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.<br />
<br />
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).<br />
<br />
== Links ==<br />
<br />
* http://mlmmj.org/ Projektseite<br />
* https://codeberg.org/mlmmj mlmmj auf Codeberg<br />
* https://github.com/tchapi/mlmmj-simple-web-interface ein Admin-Interface in NodeJS<br />
* https://www.tablix.org/~avian/blog/archives/2010/04/the_faulty_default/ Nutzung von mlmmj in Verbindung mit Procmail<br />
<br />
----<br />
[[Kategorie:HSDoku]]<br />
[[Kategorie:Installationsanleitungen]]<br />
[[Kategorie:Software]]<br />
[[Kategorie:Mailinglisten]]<br />
[[Kategorie:E-Mail]]</div>Apc00-tonyhttps://wiki.hostsharing.net/index.php?title=Mailman_Installieren&diff=6400Mailman Installieren2024-02-01T14:07:25Z<p>Apc00-tony: Lede: Mailman 2 obsolet!</p>
<hr />
<div>Achtung! Mailman 2 benötigt Python 2.7; das wird von den bei Hostsharing aktiven aktuellen Debian GNU/Linux-Betriebssystemen '''nicht mehr unterstützt'''.<br />
<br />
Alternativen sind [[Mailman_3_installieren|Mailman 3]] und [[mlmmj]].<br />
<br />
Adieu, Mailman 2, es war sehr schön mit dir.<br />
<br />
<br />
== Vorab: Die Wahl von Mailman 2 ==<br />
<br />
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.]<br />
<br />
== Mailman 2 installieren == <br />
<br />
(zuletzt getestet mit mailman-2.1.29; Installation durch Paketuser)<br />
<br />
Vielen Dank an alle Benutzer, die Verbesserungen beisteuern!<br />
<br />
=== Unter welchem Account installieren? ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Nachteil der Installation als Paketuser ist lediglich, dass die Paketdomain mit dem SSL Zertifikat von Hostsharing nicht genutzt werden kann.<!-- Aktualisieren? --><br />
<br />
=== Einen User und eine Domain anlegen ===<br />
<br />
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.<br />
<br />
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:<br />
<br />
~$ echo "" > ~/doms/listen.example.com/htdocs-ssl/.htaccess<br />
<br />
Die Default-Subdomains www.* löschen:<br />
<br />
~$ rm -r doms/listen.example.com/subs/www/<br />
~$ rm -r doms/listen.example.com/subs-ssl/www/<br />
<br />
=== Sourcen besorgen und entpacken ===<br />
<br />
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 ...<br />
<br />
~$ wget http://ftp.gnu.org/gnu/mailman/mailman-2.1.29.tgz<br />
<br />
... und entpacken:<br />
<br />
~$ tar -xzvf mailman-2.1.29.tgz<br />
<br />
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.)<br />
<br />
=== var-Verzeichnis für Log-Dateien anlegen ===<br />
<br />
Bei der Installation als Paketuser (xyz00-listen):<br />
~$ cd && mkdir -p mailman/var<br />
~$ chmod 02775 mailman/var<br />
<br />
Bei der Installation als Paketadmin (xyz00):<br />
~$ cd && mkdir var/mailman<br />
~$ chmod 02775 var/mailman<br />
<br />
=== Mailman konfigurieren ===<br />
<br />
In das Source-Verzeichnis wechseln:<br />
<br />
~$ cd mailman-2.1.29<br />
<br />
Bei der Installation durch den Paketuser (xyz00-listen):<br />
~/mailman-2.1.29$ ./configure --prefix=/home/pacs/xyz00/users/listen/mailman \<br />
--with-username=xyz00-listen \<br />
--with-groupname=xyz00 \<br />
--with-var-prefix=/home/pacs/xyz00/users/listen/mailman/var \<br />
--with-cgi-gid=xyz00 \<br />
--with-mail-gid=xyz00<br />
<br />
Bei der Installation durch den Paketadmin (xyz00):<br />
~/mailman-2.1.29$ ./configure --prefix=/home/pacs/xyz00/mailman \<br />
--with-username=xyz00 \<br />
--with-groupname=xyz00 \<br />
--with-var-prefix=/home/pacs/xyz00/var/mailman \<br />
--with-cgi-gid=xyz00 \<br />
--with-mail-gid=nogroup<br />
<br />
(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.)<br />
<br />
=== Mailman kompilieren ===<br />
<br />
~/mailman-2.1.29$ make<br />
~/mailman-2.1.29$ make install<br />
<br />
=== Datenrechte prüfen ===<br />
<br />
Sicherheitshalber die Dateirechte durch Mailmans mitgeliefertes Tool prüfen und ggf. korrigieren lassen:<br />
<br />
~/mailman-2.1.29$ cd .. <br />
~$ mailman/bin/check_perms -f<br />
<br />
== Die neue Mailman-Installation konfigurieren ==<br />
<br />
=== Konfigurationsdatei <tt>mm_cfg.py</tt> editieren ===<br />
<br />
~$ nano mailman/Mailman/mm_cfg.py<br />
<br />
Eine Beispielkonfiguration für listen.example.com könnte so aussehen:<br />
<br />
[...]<br />
##################################################<br />
# Put YOUR site-specific settings below this line.<br />
# -*- python -*-<br />
<br />
DEFAULT_HOST_NAME = 'listen.example.com'<br />
DEFAULT_EMAIL_HOST = 'listen.example.com'<br />
DEFAULT_URL_HOST = 'listen.example.com'<br />
add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)<br />
add_virtualhost(zweite.listendomain.com, zweite.listendomain.com)<br />
<br />
DEFAULT_SERVER_LANGUAGE = 'de'<br />
<br />
DEFAULT_URL_PATTERN = 'http://%s/'<br />
<br />
# Es wird der HS Mailversand für Bulkmail verwendet:<br />
SMTPHOST = 'localhost'<br />
SMTPPORT = 4587 <br />
SMTP_AUTH = True<br />
SMTP_USER = 'xyz00-listen'<br />
SMTP_PASSWD = 'das-passwort-des-o.-g.-users'<br />
SMTP_USE_TLS = True<br />
<br />
<br />
In <tt>~/mailman/Mailman/Defaults.py</tt> sieht man, was in mm_cfg.py alles angepasst werden kann.<br />
<br />
==== Mailman gegen Subscription Spam härten ====<br />
<br />
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:<br />
<br />
Die Idee kommt von https://www.ralfj.de/blog/2018/06/02/mailman-subscription-spam.html<br />
<br />
Auf der Kommandozeile ein zufälliges Secret-String erstellen:<br />
openssl rand -base64 18<br />
<br />
Und dann in die Konfigurationsdatei den erzeugten String einfügen:<br />
<br />
SUBSCRIBE_FORM_SECRET = '<Secret-String>'<br />
<br />
=== CGI-Programme in die Domain kopieren ===<br />
<br />
Bei der Installation als Paketuser (xyz00-listen):<br />
<br />
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.<br />
<br />
~$ mkdir ~/doms/listen.example.com/cgi-ssl/mailman<br />
~$ cp mailman/cgi-bin/* doms/listen.example.com/cgi-ssl/mailman/<br />
<br />
Zusätzlich muss das sticky-Flag von den kopierten Dateien entfernt werden:<br />
<br />
~$ chmod g-s ~/doms/listen.example.com/cgi/mailman/*<br />
<br />
Bei der Installation als Paketadmin (xyz00): <br />
<br />
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: <br />
<br />
~$ cd doms/listen.example.com/cgi-ssl<br />
~/doms/listen.example.com/cgi-ssl$ ln -s ../../../mailman/cgi-bin mailman<br />
<br />
=== Mailman-Icons in die Domains kopieren ===<br />
<br />
Die Icons können wahlweise verlinkt oder kopiert werden:<br />
<br />
~$ cd doms/listen.example.com/htdocs-ssl<br />
~/doms/listen.example.com/htdocs-ssl$ ln -s ../../../mailman/icons<br />
<br />
oder<br />
<br />
~$ cp -R mailman/icons doms/listen.example.com/htdocs-ssl/<br />
<br />
=== Die Datei .htaccess bearbeiten ===<br />
<br />
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.<br />
<br />
Dazu werden in <tt><nowiki>~/doms/listen.example.com/htdocs-ssl/.htaccess</nowiki></tt> folgende Rewrite-Anweisungen eintragen.<br />
<br />
RewriteEngine On<br />
RewriteCond %{REQUEST_URI} !^/icons/<br />
RewriteRule ^(.*)$ /cgi-bin/mailman/$1<br />
RewriteRule ^/cgi-bin/mailman/$ /cgi-bin/mailman/listinfo<br />
<br />
Beachte dabei die zweite Zeile: Anfragen für Icons sollen ''nicht'' umgeschrieben werden.<br />
<br />
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>:<br />
<br />
RewriteEngine On<br />
RewriteCond %{REQUEST_URI} !^/icons/<br />
RewriteRule ^mailman/(.*)$ /cgi-bin/mailman/$1<br />
RewriteRule ^/cgi-bin/mailman/$ /cgi-bin/mailman/listinfo<br />
<br />
(In diesem Fall kann die Zeile <tt>DEFAULT_URL_PATTERN...</tt> in der <tt>mm_cfg.py</tt> auskommentiert werden.)<br />
<br />
=== Hauptpasswort setzen ===<br />
<br />
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: <br />
<br />
~$ mailman/bin/mmsitepass<br />
<br />
=== Cronjobs einrichten ===<br />
<br />
In die [[Cron |Crontab]] werden Befehle eingetragen, um die Mail-Warteschlange abzuarbeiten, Logs zu löschen, usw.:<br />
<br />
# Warteschlange jede Minute bearbeiten:<br />
* * * * * ~/mailman/bin/qrunner -o -r All<br />
# Verarbeitungslogs in der 47ten Minute jeder Stunde löschen:<br />
47 * * * * rm -f ~/var/mailman/logs/qrunner<br />
<br />
Damit übernimmt cron die Funktion des qrunner-Dämons, der normalerweise auf einem Mailman-Server laufen sollte.<br />
<br />
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:<br />
<br />
47 * * * * rm -f ~/mailman/var/logs/qrunner<br />
<br />
... entsprechend dem beim Konfigurieren angegebenen <tt>var</tt>-Verzeichnis, siehe oben.<br />
<br />
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:<br />
<br />
crontab -l > mycronjobs.tmp<br />
cat ~/mailman/cron/crontab.in >> mycronjobs.tmp<br />
crontab mycronjobs.tmp<br />
<br />
== Mailinglisten einrichten ==<br />
<br />
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 <br />
<br />
MAILMAN_SITE_LIST = 'sitelistname'<br />
<br />
in der Konfigurationsdatei <tt>mailman/Mailman/mm_cfg.py</tt> eingetragen werden.<br />
<br />
=== Den Hauptverteiler "mailman" anlegen ===<br />
<br />
Die "site list" mit dem Namen "mailman" ist die Mailingliste der lokalen Mailman-Administratoren. Sie wird zur einwandfreien Funktion von Mailman benötigt.<br />
<br />
Mit dem Mailman-Befehl newlist den Verteiler anlegen:<br />
<br />
~$ mailman/bin/newlist mailman<br />
Enter the email of the person running the list: admin@xyz00.hostsharing.net<br />
Initial mailman password:<br />
<br />
(Der Befehl newlist kann – alternativ zur Weboberfläche – später benutzt werden, um gewöhnliche Mailinglisten anzulegen.)<br />
<br />
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.)<br />
<br />
Falls mailman vom Paketuser (bspw. "xyz00-listen") installiert wurde:<br />
<br />
~$ mailman/bin/config_list -i ~/mailman/var/data/sitelist.cfg mailman<br />
<br />
Falls mailman vom Paketadmin ("xyz00") installiert wurde:<br />
<br />
~$ mailman/bin/config_list -i ~/var/mailman/data/sitelist.cfg mailman<br />
<br />
Diese Konfigurationsdatei soll '''nicht''' auf gewöhnliche Mailinglisten anwendet werden.<br />
<br />
=== E-Mail Adressen bei Mailman einrichten ===<br />
<br />
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. <br />
<br />
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.<br />
<br />
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.)<br />
<br />
hsscript -u xyz00 -i<br />
[hsscript verlangt die Eingabe des Passworts vom Paketadmin xyz00; dann können diese Befehle eingegeben werden:]<br />
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman',target:'xyz00-listen+mailman'}})<br />
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-admin',target:'xyz00-listen+mailman-admin'}})<br />
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-bounces',target:'xyz00-listen+mailman-bounces'}})<br />
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-confirm',target:'xyz00-listen+mailman-confirm'}})<br />
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-join',target:'xyz00-listen+mailman-join'}})<br />
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-leave',target:'xyz00-listen+mailman-leave'}})<br />
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-owner',target:'xyz00-listen+mailman-owner'}})<br />
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-request',target:'xyz00-listen+mailman-request'}})<br />
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-subscribe',target:'xyz00-listen+mailman-subscribe'}})<br />
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-unsubscribe',target:'xyz00-listen+mailman-unsubscribe'}})<br />
<br />
Die korrekte Einrichtung der E-Mail-Adressen kann in der Web-Oberfläche von hsadmin kontrolliert werden.<br />
<br />
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:<br />
<br />
"|/home/pacs/xyz00/users/listen/mailman/mail/mailman [Befehl] [Listenname]"<br />
<br />
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.<br />
<br />
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.)<br />
<br />
echo 'admin@xyz00.hostsharing.net' > .forward # Weiterleitung von cron Fehlern etc an Paketadmin.<br />
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman post mailman"' > .forward+mailman<br />
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman admin mailman"' > .forward+mailman-admin<br />
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman bounces mailman"' > .forward+mailman-bounces<br />
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman confirm mailman"' > .forward+mailman-confirm<br />
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman join mailman"' > .forward+mailman-join<br />
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman leave mailman"' > .forward+mailman-leave<br />
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman owner mailman"' > .forward+mailman-owner<br />
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman request mailman"' > .forward+mailman-request<br />
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman subscribe mailman"' > .forward+mailman-subscribe<br />
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman unsubscribe mailman"' > .forward+mailman-unsubscribe<br />
<br />
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/mailmanaddresses</tt> mit folgendem Inhalt zu erstellen:<br />
<br />
<pre><br />
#!/bin/bash<br />
# Add e-mail addresses and dot-forward files for mailman lists.<br />
#<br />
<br />
# All the sanity checks.<br />
<br />
if [ "$3" = "" -o "$2" = "" -o "$1" = "" ] ; then<br />
echo "Syntax: $0 listname domainname listowner\n" <br />
exit<br />
fi<br />
<br />
if [ "$4" != "" ] ; then<br />
echo "Syntax: $0 listname domainname listowner\n" <br />
exit<br />
fi<br />
<br />
if [ "`pwd`" != "`echo ~`" ] ; then<br />
echo "Run this script from your home directory.\n" <br />
exit<br />
fi<br />
<br />
if [ ! -d "../${3:6}" ] ; then<br />
echo "There's no user named $3."<br />
exit<br />
else<br />
echo "You may be asked for a password for $3."<br />
fi<br />
<br />
if [ ! -d "./mailman/Mailman" ] ; then<br />
echo "Are you sure you have a Mailman installation?"<br />
exit<br />
fi<br />
<br />
# hsscript fails with a "no result" and 255 if $2 (domain name) is not valid.<br />
# It also fails if a requested address already exists.<br />
# scriptexpr contains the expanded variables. Avoid spaces, because it's unquoted in the hsscript call.<br />
<br />
# Add the base list address and its forward file:<br />
scriptexpr="emailaddress.add({set:{localpart:\"$1\",target:\"xyz00-lists+$1\",domain:\"$2\"}})"<br />
hsscript -r$3 -u$3 -e $scriptexpr<br />
if [ "$?" != "0" ] ; then echo "hsscript failed to add address with localpart $1" ; exit ; fi<br />
echo "\"|/home/pacs/xyz00/users/lists/mailman/mail/mailman post $1\"" > .forward+$1<br />
if [ "$?" != "0" ] ; then echo "failed to create a forward file for posts" ; exit ; fi<br />
<br />
# Now do the same for all the suffixes<br />
for subpart in admin bounces confirm join leave owner request subscribe unsubscribe<br />
do<br />
scriptexpr="emailaddress.add({set:{localpart:\"$1-${subpart}\",target:\"xyz00-lists+$1-${subpart}\",domain:\"$2\"}})"<br />
hsscript -r$3 -u$3 -e $scriptexpr<br />
if [ "$?" != "0" ] ; then echo "hsscript failed on subpart ${subpart}" ; exit ; fi<br />
echo "\"|/home/pacs/xyz00/users/lists/mailman/mail/mailman $subpart $1\"" > .forward+$1-$subpart<br />
if [ "$?" != "0" ] ; then echo "failed to create a forward file for ${subpart}" ; exit ; fi<br />
done<br />
<br />
echo "$0 ran to the end and finished with $?"<br />
exit<br />
</pre><br />
Der Skript muß als ausführbar gekennzeichnet werden:<br />
<br />
~$ chmod u+x bin/mailmanaddresses<br />
<br />
Die Erstellung eines Skripts um die Adressen wieder zu entfernen wird dem Leser überlassen.<br />
(Der hsscript-Befehl lautet <tt>hsscript -r<listenowner> -u<listenowner> -e 'emailaddress.remove({where:{localpart:"<listenname[-suffix]>",target:"<mailman-owner+listenname-suffix",domain:"dommainname"}})'</tt>.)<br />
<br />
=== Administration ===<br />
<br />
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.<br />
<br />
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:<br />
<br />
~$ mailman/bin/newlist <Listenname><br />
<br />
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.<br />
<br />
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].<br />
<br />
== Feintuning == <br />
<br />
Wer will, kann auch noch etwas Platz sparen. Die normale Mailmaninstallation schlägt mit über 20 MB zu Buche...<br />
<br />
Mit den folgenden Tips kann man das auf ca. 6 MB reduzieren :)<br />
<br />
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!<br />
<br />
* ~/mailman/cgi-bin und ~/mailman/icons können gelöscht werden, falls sie an andere Stelle kopiert worden sind.<br />
* Die nicht benötigten Sprachen in ~/mailman/messages löschen.<br />
* Die nicht benötigten Sprachen in ~/mailman/templates löschen (bis auf englisch).<br />
* ~/mailman/tests kann, soweit ich das sehe, komplett gelöscht werden.<br />
* Falls man koreanisch und japanisch nicht braucht, kann man folgendes machen:<br />
* in ~/mailman/bin/paths.py, ~/mailman/cron/paths.py und ~/mailman/scripts/paths.py die Zeilen:<br />
<br />
# In a normal interactive Python environment, the japanese.pth and korean.pth<br />
# files would be imported automatically. But because we inhibit the importing<br />
# of the site module, we need to be explicit about importing these codecs.<br />
if not jaok:<br />
import japanese<br />
# As of KoreanCodecs 2.0.5, you had to do the second import to get the Korean<br />
# codecs installed, however leave the first import in there in case an upgrade<br />
# changes this.<br />
if not kook:<br />
import korean<br />
import korean.aliases<br />
<br />
auskommentieren.<br />
<br />
Dann kann man ~/mailman/pythonlib/japanese, ~/mailman/pythonlib/korean, ~/mailman/pythonlib/korean.pth sowie ~/mailman/pythonlib/lib löschen.<br />
<br />
Man kann auch noch die Debug-Informationen aus den binaries strippen:<br />
<br />
strip ~/mailman/mail/mailman<br />
strip ~/mailman/cgi-bin/*<br />
<br />
Falls die CGIs nicht gesymlinkt wurden:<br />
<br />
strip ~/doms/listen.example.com/cgi/mailman/*<br />
<br />
== Multidomainfähigkeit ==<br />
<br />
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.<br />
<br />
=== Anleitung ===<br />
<br />
Logischerweise muss das Webfrontend (die CGIs) auf allen Domains installiert werden.<br />
<br />
Wenn man nun Mailinglisten mit newlist neu anlegt, muss man den Hostnamen für das Webfontend mit angeben, und zwar so:<br />
<br />
~$ mailman/bin/newlist listenname@listen.example.com<br />
<br />
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.)<br />
<br />
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:<br />
<br />
Also z.B.<br />
DEFAULT_URL_HOST = 'www.example.com'<br />
DEFAULT_EMAIL_HOST = 'listen.example.com'<br />
add_virtualhost(DEFAULT_URL_HOST,DEFAULT_EMAIL_HOST)<br />
<br />
und<br />
add_virtualhost('www.zoopnet.de', 'lists.zoopnet.de')<br />
<br />
Das bedeutet, dass Mailman per default davon ausgeht, dass alle Listen für die Domain example.com sind.<br />
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.<br />
<br />
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.<br />
<br />
<br />
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. :)<br />
<br />
=== Probleme ===<br />
<br />
Verschiedene Listen mit gleichem Namen (also z.B. liste@example1.com und liste@example2.com) sind mit Mailman 2.1 leider nicht möglich.<br />
<br />
<br />
== Tips und Tricks ==<br />
<br />
=== URL Änderungen ===<br />
Nach URL Änderungen stimmen Links im Web-Interface nicht mehr und Listen werden nicht mehr angezeigt.<br />
Es sind dann, zusätzlich zur Anpassung der mm_cfg.py, schon bestehende Listen und Archive mit folgendem Befehl zu aktualisieren:<br />
~/mailman/bin/withlist -l -r fix_url <Listen_Name> -v -u <Neue_Url><br />
<Listen_Name> steht für die Mailingliste, die bearbeitet werden soll. <Neue_Url> für die neue URL/Webadresse des Webinterfaces.<br />
<br />
=== Weitere Cron-Jobs zur Mailinglisten Verwaltung ===<br />
<br />
Folgende Cronjobs helfen bei der Verwaltung und sind User freundlich:<br />
<br />
< In Arbeit ><br />
<br />
== Referenzen ==<br />
<br />
Lösung zur installation als Domainadmin (xyz00-listen) statt Paketadmin (xyz00): https://lists.hostsharing.net/archiv/support/2009-June/019414.html<br><br />
<br />
Ältere Anleitung für Installation als Domain-Admin (xyz00-listen): <http://lists.hostsharing.net/archiv/support/2005-January/012426.html><br><br />
<br />
"Kleine Tools" auf http://hs.andreasloesch.de/, wobei das 'pac-mm-install' wahrscheinlich nicht aktuell (genug) ist<br><br />
<br />
----<br />
[[Kategorie:HSDoku]]<br />
[[Kategorie:Installationsanleitungen]]<br />
[[Kategorie:Software]]<br />
[[Kategorie:Mailinglisten]]<br />
[[Kategorie:E-Mail]]<br />
[[Kategorie:Python]]</div>Apc00-tonyhttps://wiki.hostsharing.net/index.php?title=Mlmmj&diff=6389Mlmmj2024-01-31T16:32:33Z<p>Apc00-tony: Hauptteil auf Lesbarkeit überarbeitet</p>
<hr />
<div>== Mailing List Management Made Joyful ==<br />
<br />
[http://www.mlmmj.org/ mlmmj] ist ein Programm, mit dem in einem Hostsharing Paket E-Mail-Verteiler realisiert werden kann.<br />
<br />
Wer noch nicht weiß, was ein E-Mail-Verteiler machen soll oder wie, lese veilleicht auch den Wikipedia-Artikel:<br />
[http://de.wikipedia.org/wiki/Mailingliste Mailingliste]<br />
<br />
Eine leistungsfähigere Alternative zu mlmmj könnte [[Mailman_3_installieren|Mailman 3]] sein.<br />
<br />
Diese Anleitung beschreibt die Einrichtung einer Mailingliste für eine Domain in einem Hostsharing-Webspace.<br />
<br />
== mlmmj ==<br />
<br />
Das Debian Paket [http://packages.debian.org/search?keywords=mlmmj mlmmj] ist auf den Shared-Hosting-Servern bereits installiert.<br />
<br />
=== Voraussetzungen ===<br />
<br />
Für den Betrieb der Mailingliste empfiehlt sich das Anlegen eines eigenen Users für diesen Zweck mit hsadmin.<br />
<br />
In dieser Anleitung heißt das Paket ''xyz00'' und der für Mailinglisten eingesetzte User ''xyz00-list''.<br />
<br />
Die E-Mail-Adresse der einzurichtende Mailing-Liste soll ''discuss@example.org'' sein.<br />
<br />
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.)<br />
<br />
=== Einrichtung ===<br />
<br />
Ich melde mich über SSH auf der Hostsharing-Console als der Paketuser ''xyz00'' an.<br />
<br />
Im Shell kann ich dann durch den Befehl ''hsscript -i'' das Verwaltungswerkzeug ''hsadmin'' interaktiv ausführen:<br />
<br />
xyz00@h03:~$ hsscript -i<br />
Password: *************<br />
xyz00@hsadmin> <br />
<br />
In ''hsadmin'' werden User und E-Mail-Adresse angelegt.<br />
<br />
xyz00@hsadmin> user.add({set:{name:'xyz00-list',comment:'Mailingliste Discuss',shell:'/bin/bash',password:'geheimnis'}})<br />
xyz00@hsadmin> emailaddress.add({set:{target:'xyz00-list',localpart:'discuss',domain:'example.org'}})<br />
xyz00@hsadmin> bye<br />
<br />
Mit dem Parameter "target" wird die für diese Adresse eingehende Post zunächst in das Postfach des Users xyz00-list abgelegt.<br />
<br />
Für den User xyz00-list lege ich in seinem Heimat-Verzeichnis das Unterverzeichnis "mlmmj" an:<br />
<br />
mkdir /home/pacs/xyz00/users/list/mlmmj<br />
<br />
Dann lege ich die Mailingliste mit folgendem Kommando an:<br />
<br />
mlmmj-make-ml -L discuss -s /home/pacs/xyz00/users/list/mlmmj<br />
<br />
Das Skript ''mlmmj-make-ml'' fragt weitere Parameter der Mailingliste ab:<br />
<br />
The Domain for the List? [] : example.org<br />
The emailaddress of the list owner? [postmaster] : webmaster@example.org<br />
For the list texts you can choose between the following languages or<br />
give an absolute path to a directory containing the texts.<br />
Available languages:<br />
cz da de en es fr it nl ru<br />
The path to texts for the list? [en] : de<br />
<br />
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.<br />
<br />
Weitere Konfigurationen der Liste erfolgen durch das Anlegen von Dateien im<br />
Verzeichnis "/home/pacs/xyz00/users/list/mlmmj/discuss/control".<br />
Die Konfigurationsmöglichkeiten finden Sie auf der [http://mlmmj.org/docs/tunables/ Internetseite von mlmmj].<br />
<br />
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:<br />
<br />
"|/usr/bin/mlmmj-recieve -L /home/pacs/xyz00/users/list/mlmmj/discuss/"<br />
<br />
(Ja, ''receive'' schreibt sich mit ''-ei-'', aber mlmmj hält einen symbolischen Link bereit für diejenigen, die in englischer Rechtschreibung unsicher sind:)<br />
<br />
xyz00-list@h03:~$ ls -la /usr/bin/mlmmj-rec*<br />
-rwxr-xr-x 1 root root 27104 Sep 25 2018 /usr/bin/mlmmj-receive<br />
lrwxrwxrwx 1 root root 13 Sep 25 2018 /usr/bin/mlmmj-recieve -> mlmmj-receive<br />
<br />
Die <tt>.forward</tt>-Datei sorgt dafür, dass eingehende E-Mails an das User-Postfach an das Programm ''mlmmj-recieve'' übergeben werden.<br />
<br />
Für regelmäßige Aufgaben der Listen-Managers definiere ich die<br />
crontab wie folgt (immer noch als ''xyz00-list''):<br />
<br />
xyz00-list@h03:~$ crontab -e<br />
<br />
MAILTO=webmaster@example.org<br />
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin<br />
HOME=/home/pacs/xyz00/users/list<br />
SHELL=/bin/bash<br />
LANG=en_US.UTF-8<br />
# m h dom mon dow command<br />
28 */4 * * * /usr/bin/mlmmj-maintd -d /home/pacs/xyz00/users/list/mlmmj -F<br />
<br />
Zum Schluss rufe ich das Skript mlmmj-sub auf, um die E-Mail-Adressen der gewünschten Abonnenten des Verteilers einzutragen:<br />
<br />
/usr/bin/mlmmj-sub -L /home/pacs/xyz00/users/list/mlmmj/discuss -a klaus.muster@gmx.de -c <br />
/usr/bin/mlmmj-sub -L /home/pacs/xyz00/users/list/mlmmj/discuss -a sabine.beispiel@arcor.de -c <br />
<br />
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.<br />
<br />
=== weitere Konfiguration ===<br />
<br />
Noch ein paar Dinge, die Sie möglicherweise einstellen wollen:<br />
<br />
Ein Prefix in der Betreffzeile setzen, z.B.: "[discuss]".<br />
<br />
echo "[discuss]" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/prefix<br />
<br />
Wenn die Liste nur E-Mails von eingetragenen Abonnenten weiterleiten soll:<br />
<br />
touch /home/pacs/xyz00/users/list/mlmmj/discuss/control/subonlypost<br />
<br />
Damit der Listen-Owner weitere Abonnements bestätigen muss:<br />
<br />
touch /home/pacs/xyz00/users/list/mlmmj/discuss/control/submod<br />
<br />
Einen "Reply-To:"-Header setzen, damit Antwort-Mails standardmäßig an die Mailing-Liste gehen:<br />
<br />
echo "Reply-To:" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/delheaders<br />
echo "Reply-To: discuss@example.org" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/customheaders<br />
<br />
Weitere Möglichkeiten finden Sie (wie oben bereits angegeben) <br />
auf der [http://mlmmj.org/docs/tunables/ Internetseite von mlmmj].<br />
<br />
=== Konfiguration im Browser ===<br />
<br />
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.<br />
<br />
Wer es sich ansehen möchte:<br />
<br />
Als Paket-Admin eine Domain aufschalten:<br />
<br />
hsscript -u xyz00 -e "domain.add({set:{name:'lists.example.org',user:'xyz00-list'}})"<br />
<br />
Und weiter als "xyz00-list".<br />
<br />
Download der neuesten Version der Sourcen von mlmmj von http://mlmmj.org/downloads/ und diese in einem temporären Verzeichnis entpacken.<br />
<br />
Unter "/mlmmj-$versionsnummer/contrib/web/php-admin/" findet sich die PHP-Admin-Anwendung.<br />
<br />
Also den Inhalt diese Verzeichnisses nach "/home/pacs/xyz00/users/list/doms/lists.example.org/" packen,<br />
* in "/home/pacs/xyz00/users/list/doms/lists.example.org/conf/config.php" die Variable "$topdir" anpassen<br />
* 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<br />
* 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: <br />
<br />
Require valid-user<br />
AuthType Basic<br />
AuthName "mlmmj web-interface"<br />
AuthUserFile /home/pacs/xyz00/users/list/doms/lists.example.org/etc/htpasswd<br />
<br />
Und schließlich die "htpasswd"-Datei anlegen.<br />
<br />
cd /home/pacs/xyz00/users/list/doms/lists.example.org/etc/<br />
htpasswd -c htpasswd listadmin<br />
<br />
Ein Passwort angeben und auf<br />
https://lists.example.org schauen.<br />
<br />
== Mehrere Mailinglisten betreiben ==<br />
<br />
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.<br />
<br />
Dazu trägt man in der Date ''.forward'' statt des Aufrufs von ''mlmmj-recieve'' einen Aufruf von ''procmail'' ein:<br />
<br />
|/usr/bin/procmail<br />
<br />
Die Konfiguration von Procmail kann generisch erfolgen. Dazu legt man eine Datei ''.procmailrc'' mit folgendem Inhalt ins $HOME des Users:<br />
<br />
SHELL=/bin/sh<br />
HOMEDIR=/home/pacs/xyz00/users/list<br />
MAILDIR=/home/pacs/xyz00/users/list/Maildir<br />
PMDIR=/home/pacs/xyz00/users/list<br />
VERBOSE=yes<br />
LOGFILE=/home/pacs/xyz00/users/list/var/procmail.log<br />
DEFAULT<br />
<br />
:0:<br />
* ^X-Original-To: ()\/[^@+]+<br />
|/usr/bin/mlmmj-receive -F -L /home/pacs/xyz00/users/list/mlmmj/${MATCH}/<br />
<br />
:0<br />
{ EXITCODE 67 }<br />
<br />
<br />
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.<br />
<br />
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).<br />
<br />
== Links ==<br />
<br />
* http://mlmmj.org/ Projektseite<br />
* https://codeberg.org/mlmmj mlmmj auf Codeberg<br />
* https://github.com/tchapi/mlmmj-simple-web-interface ein Admin-Interface in NodeJS<br />
* https://www.tablix.org/~avian/blog/archives/2010/04/the_faulty_default/ Nutzung von mlmmj in Verbindung mit Procmail<br />
<br />
----<br />
[[Kategorie:HSDoku]]<br />
[[Kategorie:Installationsanleitungen]]<br />
[[Kategorie:Software]]<br />
[[Kategorie:Mailinglisten]]<br />
[[Kategorie:E-Mail]]</div>Apc00-tonyhttps://wiki.hostsharing.net/index.php?title=Mailman_Installieren&diff=6276Mailman Installieren2023-11-10T17:14:53Z<p>Apc00-tony: /* E-Mail Adressen bei Mailman einrichten */</p>
<hr />
<div>== Vorab: Die Wahl von Mailman 2 ==<br />
<br />
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.]<br />
<br />
== Mailman 2 installieren == <br />
<br />
(zuletzt getestet mit mailman-2.1.29; Installation durch Paketuser)<br />
<br />
Vielen Dank an alle Benutzer, die Verbesserungen beisteuern!<br />
<br />
=== Unter welchem Account installieren? ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Nachteil der Installation als Paketuser ist lediglich, dass die Paketdomain mit dem SSL Zertifikat von Hostsharing nicht genutzt werden kann.<!-- Aktualisieren? --><br />
<br />
=== Einen User und eine Domain anlegen ===<br />
<br />
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.<br />
<br />
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:<br />
<br />
~$ echo "" > ~/doms/listen.example.com/htdocs-ssl/.htaccess<br />
<br />
Die Default-Subdomains www.* löschen:<br />
<br />
~$ rm -r doms/listen.example.com/subs/www/<br />
~$ rm -r doms/listen.example.com/subs-ssl/www/<br />
<br />
=== Sourcen besorgen und entpacken ===<br />
<br />
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 ...<br />
<br />
~$ wget http://ftp.gnu.org/gnu/mailman/mailman-2.1.29.tgz<br />
<br />
... und entpacken:<br />
<br />
~$ tar -xzvf mailman-2.1.29.tgz<br />
<br />
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.)<br />
<br />
=== var-Verzeichnis für Log-Dateien anlegen ===<br />
<br />
Bei der Installation als Paketuser (xyz00-listen):<br />
~$ cd && mkdir -p mailman/var<br />
~$ chmod 02775 mailman/var<br />
<br />
Bei der Installation als Paketadmin (xyz00):<br />
~$ cd && mkdir var/mailman<br />
~$ chmod 02775 var/mailman<br />
<br />
=== Mailman konfigurieren ===<br />
<br />
In das Source-Verzeichnis wechseln:<br />
<br />
~$ cd mailman-2.1.29<br />
<br />
Bei der Installation durch den Paketuser (xyz00-listen):<br />
~/mailman-2.1.29$ ./configure --prefix=/home/pacs/xyz00/users/listen/mailman \<br />
--with-username=xyz00-listen \<br />
--with-groupname=xyz00 \<br />
--with-var-prefix=/home/pacs/xyz00/users/listen/mailman/var \<br />
--with-cgi-gid=xyz00 \<br />
--with-mail-gid=xyz00<br />
<br />
Bei der Installation durch den Paketadmin (xyz00):<br />
~/mailman-2.1.29$ ./configure --prefix=/home/pacs/xyz00/mailman \<br />
--with-username=xyz00 \<br />
--with-groupname=xyz00 \<br />
--with-var-prefix=/home/pacs/xyz00/var/mailman \<br />
--with-cgi-gid=xyz00 \<br />
--with-mail-gid=nogroup<br />
<br />
(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.)<br />
<br />
=== Mailman kompilieren ===<br />
<br />
~/mailman-2.1.29$ make<br />
~/mailman-2.1.29$ make install<br />
<br />
=== Datenrechte prüfen ===<br />
<br />
Sicherheitshalber die Dateirechte durch Mailmans mitgeliefertes Tool prüfen und ggf. korrigieren lassen:<br />
<br />
~/mailman-2.1.29$ cd .. <br />
~$ mailman/bin/check_perms -f<br />
<br />
== Die neue Mailman-Installation konfigurieren ==<br />
<br />
=== Konfigurationsdatei <tt>mm_cfg.py</tt> editieren ===<br />
<br />
~$ nano mailman/Mailman/mm_cfg.py<br />
<br />
Eine Beispielkonfiguration für listen.example.com könnte so aussehen:<br />
<br />
[...]<br />
##################################################<br />
# Put YOUR site-specific settings below this line.<br />
# -*- python -*-<br />
<br />
DEFAULT_HOST_NAME = 'listen.example.com'<br />
DEFAULT_EMAIL_HOST = 'listen.example.com'<br />
DEFAULT_URL_HOST = 'listen.example.com'<br />
add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)<br />
add_virtualhost(zweite.listendomain.com, zweite.listendomain.com)<br />
<br />
DEFAULT_SERVER_LANGUAGE = 'de'<br />
<br />
DEFAULT_URL_PATTERN = 'http://%s/'<br />
<br />
# Es wird der HS Mailversand für Bulkmail verwendet:<br />
SMTPHOST = 'localhost'<br />
SMTPPORT = 4587 <br />
SMTP_AUTH = True<br />
SMTP_USER = 'xyz00-listen'<br />
SMTP_PASSWD = 'das-passwort-des-o.-g.-users'<br />
SMTP_USE_TLS = True<br />
<br />
<br />
In <tt>~/mailman/Mailman/Defaults.py</tt> sieht man, was in mm_cfg.py alles angepasst werden kann.<br />
<br />
==== Mailman gegen Subscription Spam härten ====<br />
<br />
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:<br />
<br />
Die Idee kommt von https://www.ralfj.de/blog/2018/06/02/mailman-subscription-spam.html<br />
<br />
Auf der Kommandozeile ein zufälliges Secret-String erstellen:<br />
openssl rand -base64 18<br />
<br />
Und dann in die Konfigurationsdatei den erzeugten String einfügen:<br />
<br />
SUBSCRIBE_FORM_SECRET = '<Secret-String>'<br />
<br />
=== CGI-Programme in die Domain kopieren ===<br />
<br />
Bei der Installation als Paketuser (xyz00-listen):<br />
<br />
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.<br />
<br />
~$ mkdir ~/doms/listen.example.com/cgi-ssl/mailman<br />
~$ cp mailman/cgi-bin/* doms/listen.example.com/cgi-ssl/mailman/<br />
<br />
Zusätzlich muss das sticky-Flag von den kopierten Dateien entfernt werden:<br />
<br />
~$ chmod g-s ~/doms/listen.example.com/cgi/mailman/*<br />
<br />
Bei der Installation als Paketadmin (xyz00): <br />
<br />
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: <br />
<br />
~$ cd doms/listen.example.com/cgi-ssl<br />
~/doms/listen.example.com/cgi-ssl$ ln -s ../../../mailman/cgi-bin mailman<br />
<br />
=== Mailman-Icons in die Domains kopieren ===<br />
<br />
Die Icons können wahlweise verlinkt oder kopiert werden:<br />
<br />
~$ cd doms/listen.example.com/htdocs-ssl<br />
~/doms/listen.example.com/htdocs-ssl$ ln -s ../../../mailman/icons<br />
<br />
oder<br />
<br />
~$ cp -R mailman/icons doms/listen.example.com/htdocs-ssl/<br />
<br />
=== Die Datei .htaccess bearbeiten ===<br />
<br />
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.<br />
<br />
Dazu werden in <tt><nowiki>~/doms/listen.example.com/htdocs-ssl/.htaccess</nowiki></tt> folgende Rewrite-Anweisungen eintragen.<br />
<br />
RewriteEngine On<br />
RewriteCond %{REQUEST_URI} !^/icons/<br />
RewriteRule ^(.*)$ /cgi-bin/mailman/$1<br />
RewriteRule ^/cgi-bin/mailman/$ /cgi-bin/mailman/listinfo<br />
<br />
Beachte dabei die zweite Zeile: Anfragen für Icons sollen ''nicht'' umgeschrieben werden.<br />
<br />
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>:<br />
<br />
RewriteEngine On<br />
RewriteCond %{REQUEST_URI} !^/icons/<br />
RewriteRule ^mailman/(.*)$ /cgi-bin/mailman/$1<br />
RewriteRule ^/cgi-bin/mailman/$ /cgi-bin/mailman/listinfo<br />
<br />
(In diesem Fall kann die Zeile <tt>DEFAULT_URL_PATTERN...</tt> in der <tt>mm_cfg.py</tt> auskommentiert werden.)<br />
<br />
=== Hauptpasswort setzen ===<br />
<br />
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: <br />
<br />
~$ mailman/bin/mmsitepass<br />
<br />
=== Cronjobs einrichten ===<br />
<br />
In die [[Cron |Crontab]] werden Befehle eingetragen, um die Mail-Warteschlange abzuarbeiten, Logs zu löschen, usw.:<br />
<br />
# Warteschlange jede Minute bearbeiten:<br />
* * * * * ~/mailman/bin/qrunner -o -r All<br />
# Verarbeitungslogs in der 47ten Minute jeder Stunde löschen:<br />
47 * * * * rm -f ~/var/mailman/logs/qrunner<br />
<br />
Damit übernimmt cron die Funktion des qrunner-Dämons, der normalerweise auf einem Mailman-Server laufen sollte.<br />
<br />
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:<br />
<br />
47 * * * * rm -f ~/mailman/var/logs/qrunner<br />
<br />
... entsprechend dem beim Konfigurieren angegebenen <tt>var</tt>-Verzeichnis, siehe oben.<br />
<br />
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:<br />
<br />
crontab -l > mycronjobs.tmp<br />
cat ~/mailman/cron/crontab.in >> mycronjobs.tmp<br />
crontab mycronjobs.tmp<br />
<br />
== Mailinglisten einrichten ==<br />
<br />
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 <br />
<br />
MAILMAN_SITE_LIST = 'sitelistname'<br />
<br />
in der Konfigurationsdatei <tt>mailman/Mailman/mm_cfg.py</tt> eingetragen werden.<br />
<br />
=== Den Hauptverteiler "mailman" anlegen ===<br />
<br />
Die "site list" mit dem Namen "mailman" ist die Mailingliste der lokalen Mailman-Administratoren. Sie wird zur einwandfreien Funktion von Mailman benötigt.<br />
<br />
Mit dem Mailman-Befehl newlist den Verteiler anlegen:<br />
<br />
~$ mailman/bin/newlist mailman<br />
Enter the email of the person running the list: admin@xyz00.hostsharing.net<br />
Initial mailman password:<br />
<br />
(Der Befehl newlist kann – alternativ zur Weboberfläche – später benutzt werden, um gewöhnliche Mailinglisten anzulegen.)<br />
<br />
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.)<br />
<br />
Falls mailman vom Paketuser (bspw. "xyz00-listen") installiert wurde:<br />
<br />
~$ mailman/bin/config_list -i ~/mailman/var/data/sitelist.cfg mailman<br />
<br />
Falls mailman vom Paketadmin ("xyz00") installiert wurde:<br />
<br />
~$ mailman/bin/config_list -i ~/var/mailman/data/sitelist.cfg mailman<br />
<br />
Diese Konfigurationsdatei soll '''nicht''' auf gewöhnliche Mailinglisten anwendet werden.<br />
<br />
=== E-Mail Adressen bei Mailman einrichten ===<br />
<br />
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. <br />
<br />
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.<br />
<br />
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.)<br />
<br />
hsscript -u xyz00 -i<br />
[hsscript verlangt die Eingabe des Passworts vom Paketadmin xyz00; dann können diese Befehle eingegeben werden:]<br />
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman',target:'xyz00-listen+mailman'}})<br />
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-admin',target:'xyz00-listen+mailman-admin'}})<br />
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-bounces',target:'xyz00-listen+mailman-bounces'}})<br />
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-confirm',target:'xyz00-listen+mailman-confirm'}})<br />
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-join',target:'xyz00-listen+mailman-join'}})<br />
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-leave',target:'xyz00-listen+mailman-leave'}})<br />
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-owner',target:'xyz00-listen+mailman-owner'}})<br />
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-request',target:'xyz00-listen+mailman-request'}})<br />
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-subscribe',target:'xyz00-listen+mailman-subscribe'}})<br />
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-unsubscribe',target:'xyz00-listen+mailman-unsubscribe'}})<br />
<br />
Die korrekte Einrichtung der E-Mail-Adressen kann in der Web-Oberfläche von hsadmin kontrolliert werden.<br />
<br />
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:<br />
<br />
"|/home/pacs/xyz00/users/listen/mailman/mail/mailman [Befehl] [Listenname]"<br />
<br />
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.<br />
<br />
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.)<br />
<br />
echo 'admin@xyz00.hostsharing.net' > .forward # Weiterleitung von cron Fehlern etc an Paketadmin.<br />
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman post mailman"' > .forward+mailman<br />
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman admin mailman"' > .forward+mailman-admin<br />
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman bounces mailman"' > .forward+mailman-bounces<br />
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman confirm mailman"' > .forward+mailman-confirm<br />
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman join mailman"' > .forward+mailman-join<br />
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman leave mailman"' > .forward+mailman-leave<br />
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman owner mailman"' > .forward+mailman-owner<br />
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman request mailman"' > .forward+mailman-request<br />
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman subscribe mailman"' > .forward+mailman-subscribe<br />
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman unsubscribe mailman"' > .forward+mailman-unsubscribe<br />
<br />
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/mailmanaddresses</tt> mit folgendem Inhalt zu erstellen:<br />
<br />
<pre><br />
#!/bin/bash<br />
# Add e-mail addresses and dot-forward files for mailman lists.<br />
#<br />
<br />
# All the sanity checks.<br />
<br />
if [ "$3" = "" -o "$2" = "" -o "$1" = "" ] ; then<br />
echo "Syntax: $0 listname domainname listowner\n" <br />
exit<br />
fi<br />
<br />
if [ "$4" != "" ] ; then<br />
echo "Syntax: $0 listname domainname listowner\n" <br />
exit<br />
fi<br />
<br />
if [ "`pwd`" != "`echo ~`" ] ; then<br />
echo "Run this script from your home directory.\n" <br />
exit<br />
fi<br />
<br />
if [ ! -d "../${3:6}" ] ; then<br />
echo "There's no user named $3."<br />
exit<br />
else<br />
echo "You may be asked for a password for $3."<br />
fi<br />
<br />
if [ ! -d "./mailman/Mailman" ] ; then<br />
echo "Are you sure you have a Mailman installation?"<br />
exit<br />
fi<br />
<br />
# hsscript fails with a "no result" and 255 if $2 (domain name) is not valid.<br />
# It also fails if a requested address already exists.<br />
# scriptexpr contains the expanded variables. Avoid spaces, because it's unquoted in the hsscript call.<br />
<br />
# Add the base list address and its forward file:<br />
scriptexpr="emailaddress.add({set:{localpart:\"$1\",target:\"xyz00-lists+$1\",domain:\"$2\"}})"<br />
hsscript -r$3 -u$3 -e $scriptexpr<br />
if [ "$?" != "0" ] ; then echo "hsscript failed to add address with localpart $1" ; exit ; fi<br />
echo "\"|/home/pacs/xyz00/users/lists/mailman/mail/mailman post $1\"" > .forward+$1<br />
if [ "$?" != "0" ] ; then echo "failed to create a forward file for posts" ; exit ; fi<br />
<br />
# Now do the same for all the suffixes<br />
for subpart in admin bounces confirm join leave owner request subscribe unsubscribe<br />
do<br />
scriptexpr="emailaddress.add({set:{localpart:\"$1-${subpart}\",target:\"xyz00-lists+$1-${subpart}\",domain:\"$2\"}})"<br />
hsscript -r$3 -u$3 -e $scriptexpr<br />
if [ "$?" != "0" ] ; then echo "hsscript failed on subpart ${subpart}" ; exit ; fi<br />
echo "\"|/home/pacs/xyz00/users/lists/mailman/mail/mailman $subpart $1\"" > .forward+$1-$subpart<br />
if [ "$?" != "0" ] ; then echo "failed to create a forward file for ${subpart}" ; exit ; fi<br />
done<br />
<br />
echo "$0 ran to the end and finished with $?"<br />
exit<br />
</pre><br />
Der Skript muß als ausführbar gekennzeichnet werden:<br />
<br />
~$ chmod u+x bin/mailmanaddresses<br />
<br />
Die Erstellung eines Skripts um die Adressen wieder zu entfernen wird dem Leser überlassen.<br />
(Der hsscript-Befehl lautet <tt>hsscript -r<listenowner> -u<listenowner> -e 'emailaddress.remove({where:{localpart:"<listenname[-suffix]>",target:"<mailman-owner+listenname-suffix",domain:"dommainname"}})'</tt>.)<br />
<br />
=== Administration ===<br />
<br />
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.<br />
<br />
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:<br />
<br />
~$ mailman/bin/newlist <Listenname><br />
<br />
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.<br />
<br />
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].<br />
<br />
== Feintuning == <br />
<br />
Wer will, kann auch noch etwas Platz sparen. Die normale Mailmaninstallation schlägt mit über 20 MB zu Buche...<br />
<br />
Mit den folgenden Tips kann man das auf ca. 6 MB reduzieren :)<br />
<br />
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!<br />
<br />
* ~/mailman/cgi-bin und ~/mailman/icons können gelöscht werden, falls sie an andere Stelle kopiert worden sind.<br />
* Die nicht benötigten Sprachen in ~/mailman/messages löschen.<br />
* Die nicht benötigten Sprachen in ~/mailman/templates löschen (bis auf englisch).<br />
* ~/mailman/tests kann, soweit ich das sehe, komplett gelöscht werden.<br />
* Falls man koreanisch und japanisch nicht braucht, kann man folgendes machen:<br />
* in ~/mailman/bin/paths.py, ~/mailman/cron/paths.py und ~/mailman/scripts/paths.py die Zeilen:<br />
<br />
# In a normal interactive Python environment, the japanese.pth and korean.pth<br />
# files would be imported automatically. But because we inhibit the importing<br />
# of the site module, we need to be explicit about importing these codecs.<br />
if not jaok:<br />
import japanese<br />
# As of KoreanCodecs 2.0.5, you had to do the second import to get the Korean<br />
# codecs installed, however leave the first import in there in case an upgrade<br />
# changes this.<br />
if not kook:<br />
import korean<br />
import korean.aliases<br />
<br />
auskommentieren.<br />
<br />
Dann kann man ~/mailman/pythonlib/japanese, ~/mailman/pythonlib/korean, ~/mailman/pythonlib/korean.pth sowie ~/mailman/pythonlib/lib löschen.<br />
<br />
Man kann auch noch die Debug-Informationen aus den binaries strippen:<br />
<br />
strip ~/mailman/mail/mailman<br />
strip ~/mailman/cgi-bin/*<br />
<br />
Falls die CGIs nicht gesymlinkt wurden:<br />
<br />
strip ~/doms/listen.example.com/cgi/mailman/*<br />
<br />
== Multidomainfähigkeit ==<br />
<br />
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.<br />
<br />
=== Anleitung ===<br />
<br />
Logischerweise muss das Webfrontend (die CGIs) auf allen Domains installiert werden.<br />
<br />
Wenn man nun Mailinglisten mit newlist neu anlegt, muss man den Hostnamen für das Webfontend mit angeben, und zwar so:<br />
<br />
~$ mailman/bin/newlist listenname@listen.example.com<br />
<br />
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.)<br />
<br />
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:<br />
<br />
Also z.B.<br />
DEFAULT_URL_HOST = 'www.example.com'<br />
DEFAULT_EMAIL_HOST = 'listen.example.com'<br />
add_virtualhost(DEFAULT_URL_HOST,DEFAULT_EMAIL_HOST)<br />
<br />
und<br />
add_virtualhost('www.zoopnet.de', 'lists.zoopnet.de')<br />
<br />
Das bedeutet, dass Mailman per default davon ausgeht, dass alle Listen für die Domain example.com sind.<br />
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.<br />
<br />
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.<br />
<br />
<br />
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. :)<br />
<br />
=== Probleme ===<br />
<br />
Verschiedene Listen mit gleichem Namen (also z.B. liste@example1.com und liste@example2.com) sind mit Mailman 2.1 leider nicht möglich.<br />
<br />
<br />
== Tips und Tricks ==<br />
<br />
=== URL Änderungen ===<br />
Nach URL Änderungen stimmen Links im Web-Interface nicht mehr und Listen werden nicht mehr angezeigt.<br />
Es sind dann, zusätzlich zur Anpassung der mm_cfg.py, schon bestehende Listen und Archive mit folgendem Befehl zu aktualisieren:<br />
~/mailman/bin/withlist -l -r fix_url <Listen_Name> -v -u <Neue_Url><br />
<Listen_Name> steht für die Mailingliste, die bearbeitet werden soll. <Neue_Url> für die neue URL/Webadresse des Webinterfaces.<br />
<br />
=== Weitere Cron-Jobs zur Mailinglisten Verwaltung ===<br />
<br />
Folgende Cronjobs helfen bei der Verwaltung und sind User freundlich:<br />
<br />
< In Arbeit ><br />
<br />
== Referenzen ==<br />
<br />
Lösung zur installation als Domainadmin (xyz00-listen) statt Paketadmin (xyz00): https://lists.hostsharing.net/archiv/support/2009-June/019414.html<br><br />
<br />
Ältere Anleitung für Installation als Domain-Admin (xyz00-listen): <http://lists.hostsharing.net/archiv/support/2005-January/012426.html><br><br />
<br />
"Kleine Tools" auf http://hs.andreasloesch.de/, wobei das 'pac-mm-install' wahrscheinlich nicht aktuell (genug) ist<br><br />
<br />
----<br />
[[Kategorie:HSDoku]]<br />
[[Kategorie:Installationsanleitungen]]<br />
[[Kategorie:Software]]<br />
[[Kategorie:Mailinglisten]]<br />
[[Kategorie:E-Mail]]<br />
[[Kategorie:Python]]</div>Apc00-tonyhttps://wiki.hostsharing.net/index.php?title=Mailman_Installieren&diff=6275Mailman Installieren2023-11-10T17:04:49Z<p>Apc00-tony: /* E-Mail Adressen bei Mailman einrichten */</p>
<hr />
<div>== Vorab: Die Wahl von Mailman 2 ==<br />
<br />
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.]<br />
<br />
== Mailman 2 installieren == <br />
<br />
(zuletzt getestet mit mailman-2.1.29; Installation durch Paketuser)<br />
<br />
Vielen Dank an alle Benutzer, die Verbesserungen beisteuern!<br />
<br />
=== Unter welchem Account installieren? ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Nachteil der Installation als Paketuser ist lediglich, dass die Paketdomain mit dem SSL Zertifikat von Hostsharing nicht genutzt werden kann.<!-- Aktualisieren? --><br />
<br />
=== Einen User und eine Domain anlegen ===<br />
<br />
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.<br />
<br />
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:<br />
<br />
~$ echo "" > ~/doms/listen.example.com/htdocs-ssl/.htaccess<br />
<br />
Die Default-Subdomains www.* löschen:<br />
<br />
~$ rm -r doms/listen.example.com/subs/www/<br />
~$ rm -r doms/listen.example.com/subs-ssl/www/<br />
<br />
=== Sourcen besorgen und entpacken ===<br />
<br />
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 ...<br />
<br />
~$ wget http://ftp.gnu.org/gnu/mailman/mailman-2.1.29.tgz<br />
<br />
... und entpacken:<br />
<br />
~$ tar -xzvf mailman-2.1.29.tgz<br />
<br />
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.)<br />
<br />
=== var-Verzeichnis für Log-Dateien anlegen ===<br />
<br />
Bei der Installation als Paketuser (xyz00-listen):<br />
~$ cd && mkdir -p mailman/var<br />
~$ chmod 02775 mailman/var<br />
<br />
Bei der Installation als Paketadmin (xyz00):<br />
~$ cd && mkdir var/mailman<br />
~$ chmod 02775 var/mailman<br />
<br />
=== Mailman konfigurieren ===<br />
<br />
In das Source-Verzeichnis wechseln:<br />
<br />
~$ cd mailman-2.1.29<br />
<br />
Bei der Installation durch den Paketuser (xyz00-listen):<br />
~/mailman-2.1.29$ ./configure --prefix=/home/pacs/xyz00/users/listen/mailman \<br />
--with-username=xyz00-listen \<br />
--with-groupname=xyz00 \<br />
--with-var-prefix=/home/pacs/xyz00/users/listen/mailman/var \<br />
--with-cgi-gid=xyz00 \<br />
--with-mail-gid=xyz00<br />
<br />
Bei der Installation durch den Paketadmin (xyz00):<br />
~/mailman-2.1.29$ ./configure --prefix=/home/pacs/xyz00/mailman \<br />
--with-username=xyz00 \<br />
--with-groupname=xyz00 \<br />
--with-var-prefix=/home/pacs/xyz00/var/mailman \<br />
--with-cgi-gid=xyz00 \<br />
--with-mail-gid=nogroup<br />
<br />
(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.)<br />
<br />
=== Mailman kompilieren ===<br />
<br />
~/mailman-2.1.29$ make<br />
~/mailman-2.1.29$ make install<br />
<br />
=== Datenrechte prüfen ===<br />
<br />
Sicherheitshalber die Dateirechte durch Mailmans mitgeliefertes Tool prüfen und ggf. korrigieren lassen:<br />
<br />
~/mailman-2.1.29$ cd .. <br />
~$ mailman/bin/check_perms -f<br />
<br />
== Die neue Mailman-Installation konfigurieren ==<br />
<br />
=== Konfigurationsdatei <tt>mm_cfg.py</tt> editieren ===<br />
<br />
~$ nano mailman/Mailman/mm_cfg.py<br />
<br />
Eine Beispielkonfiguration für listen.example.com könnte so aussehen:<br />
<br />
[...]<br />
##################################################<br />
# Put YOUR site-specific settings below this line.<br />
# -*- python -*-<br />
<br />
DEFAULT_HOST_NAME = 'listen.example.com'<br />
DEFAULT_EMAIL_HOST = 'listen.example.com'<br />
DEFAULT_URL_HOST = 'listen.example.com'<br />
add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)<br />
add_virtualhost(zweite.listendomain.com, zweite.listendomain.com)<br />
<br />
DEFAULT_SERVER_LANGUAGE = 'de'<br />
<br />
DEFAULT_URL_PATTERN = 'http://%s/'<br />
<br />
# Es wird der HS Mailversand für Bulkmail verwendet:<br />
SMTPHOST = 'localhost'<br />
SMTPPORT = 4587 <br />
SMTP_AUTH = True<br />
SMTP_USER = 'xyz00-listen'<br />
SMTP_PASSWD = 'das-passwort-des-o.-g.-users'<br />
SMTP_USE_TLS = True<br />
<br />
<br />
In <tt>~/mailman/Mailman/Defaults.py</tt> sieht man, was in mm_cfg.py alles angepasst werden kann.<br />
<br />
==== Mailman gegen Subscription Spam härten ====<br />
<br />
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:<br />
<br />
Die Idee kommt von https://www.ralfj.de/blog/2018/06/02/mailman-subscription-spam.html<br />
<br />
Auf der Kommandozeile ein zufälliges Secret-String erstellen:<br />
openssl rand -base64 18<br />
<br />
Und dann in die Konfigurationsdatei den erzeugten String einfügen:<br />
<br />
SUBSCRIBE_FORM_SECRET = '<Secret-String>'<br />
<br />
=== CGI-Programme in die Domain kopieren ===<br />
<br />
Bei der Installation als Paketuser (xyz00-listen):<br />
<br />
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.<br />
<br />
~$ mkdir ~/doms/listen.example.com/cgi-ssl/mailman<br />
~$ cp mailman/cgi-bin/* doms/listen.example.com/cgi-ssl/mailman/<br />
<br />
Zusätzlich muss das sticky-Flag von den kopierten Dateien entfernt werden:<br />
<br />
~$ chmod g-s ~/doms/listen.example.com/cgi/mailman/*<br />
<br />
Bei der Installation als Paketadmin (xyz00): <br />
<br />
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: <br />
<br />
~$ cd doms/listen.example.com/cgi-ssl<br />
~/doms/listen.example.com/cgi-ssl$ ln -s ../../../mailman/cgi-bin mailman<br />
<br />
=== Mailman-Icons in die Domains kopieren ===<br />
<br />
Die Icons können wahlweise verlinkt oder kopiert werden:<br />
<br />
~$ cd doms/listen.example.com/htdocs-ssl<br />
~/doms/listen.example.com/htdocs-ssl$ ln -s ../../../mailman/icons<br />
<br />
oder<br />
<br />
~$ cp -R mailman/icons doms/listen.example.com/htdocs-ssl/<br />
<br />
=== Die Datei .htaccess bearbeiten ===<br />
<br />
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.<br />
<br />
Dazu werden in <tt><nowiki>~/doms/listen.example.com/htdocs-ssl/.htaccess</nowiki></tt> folgende Rewrite-Anweisungen eintragen.<br />
<br />
RewriteEngine On<br />
RewriteCond %{REQUEST_URI} !^/icons/<br />
RewriteRule ^(.*)$ /cgi-bin/mailman/$1<br />
RewriteRule ^/cgi-bin/mailman/$ /cgi-bin/mailman/listinfo<br />
<br />
Beachte dabei die zweite Zeile: Anfragen für Icons sollen ''nicht'' umgeschrieben werden.<br />
<br />
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>:<br />
<br />
RewriteEngine On<br />
RewriteCond %{REQUEST_URI} !^/icons/<br />
RewriteRule ^mailman/(.*)$ /cgi-bin/mailman/$1<br />
RewriteRule ^/cgi-bin/mailman/$ /cgi-bin/mailman/listinfo<br />
<br />
(In diesem Fall kann die Zeile <tt>DEFAULT_URL_PATTERN...</tt> in der <tt>mm_cfg.py</tt> auskommentiert werden.)<br />
<br />
=== Hauptpasswort setzen ===<br />
<br />
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: <br />
<br />
~$ mailman/bin/mmsitepass<br />
<br />
=== Cronjobs einrichten ===<br />
<br />
In die [[Cron |Crontab]] werden Befehle eingetragen, um die Mail-Warteschlange abzuarbeiten, Logs zu löschen, usw.:<br />
<br />
# Warteschlange jede Minute bearbeiten:<br />
* * * * * ~/mailman/bin/qrunner -o -r All<br />
# Verarbeitungslogs in der 47ten Minute jeder Stunde löschen:<br />
47 * * * * rm -f ~/var/mailman/logs/qrunner<br />
<br />
Damit übernimmt cron die Funktion des qrunner-Dämons, der normalerweise auf einem Mailman-Server laufen sollte.<br />
<br />
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:<br />
<br />
47 * * * * rm -f ~/mailman/var/logs/qrunner<br />
<br />
... entsprechend dem beim Konfigurieren angegebenen <tt>var</tt>-Verzeichnis, siehe oben.<br />
<br />
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:<br />
<br />
crontab -l > mycronjobs.tmp<br />
cat ~/mailman/cron/crontab.in >> mycronjobs.tmp<br />
crontab mycronjobs.tmp<br />
<br />
== Mailinglisten einrichten ==<br />
<br />
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 <br />
<br />
MAILMAN_SITE_LIST = 'sitelistname'<br />
<br />
in der Konfigurationsdatei <tt>mailman/Mailman/mm_cfg.py</tt> eingetragen werden.<br />
<br />
=== Den Hauptverteiler "mailman" anlegen ===<br />
<br />
Die "site list" mit dem Namen "mailman" ist die Mailingliste der lokalen Mailman-Administratoren. Sie wird zur einwandfreien Funktion von Mailman benötigt.<br />
<br />
Mit dem Mailman-Befehl newlist den Verteiler anlegen:<br />
<br />
~$ mailman/bin/newlist mailman<br />
Enter the email of the person running the list: admin@xyz00.hostsharing.net<br />
Initial mailman password:<br />
<br />
(Der Befehl newlist kann – alternativ zur Weboberfläche – später benutzt werden, um gewöhnliche Mailinglisten anzulegen.)<br />
<br />
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.)<br />
<br />
Falls mailman vom Paketuser (bspw. "xyz00-listen") installiert wurde:<br />
<br />
~$ mailman/bin/config_list -i ~/mailman/var/data/sitelist.cfg mailman<br />
<br />
Falls mailman vom Paketadmin ("xyz00") installiert wurde:<br />
<br />
~$ mailman/bin/config_list -i ~/var/mailman/data/sitelist.cfg mailman<br />
<br />
Diese Konfigurationsdatei soll '''nicht''' auf gewöhnliche Mailinglisten anwendet werden.<br />
<br />
=== E-Mail Adressen bei Mailman einrichten ===<br />
<br />
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. <br />
<br />
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.<br />
<br />
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.)<br />
<br />
hsscript -u xyz00 -i<br />
[hsscript verlangt die Eingabe des Passworts vom Paketadmin xyz00; dann können diese Befehle eingegeben werden:]<br />
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman',target:'xyz00-listen+mailman'}})<br />
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-admin',target:'xyz00-listen+mailman-admin'}})<br />
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-bounces',target:'xyz00-listen+mailman-bounces'}})<br />
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-confirm',target:'xyz00-listen+mailman-confirm'}})<br />
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-join',target:'xyz00-listen+mailman-join'}})<br />
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-leave',target:'xyz00-listen+mailman-leave'}})<br />
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-owner',target:'xyz00-listen+mailman-owner'}})<br />
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-request',target:'xyz00-listen+mailman-request'}})<br />
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-subscribe',target:'xyz00-listen+mailman-subscribe'}})<br />
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-unsubscribe',target:'xyz00-listen+mailman-unsubscribe'}})<br />
<br />
Die korrekte Einrichtung der E-Mail-Adressen kann in der Web-Oberfläche von hsadmin kontrolliert werden.<br />
<br />
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:<br />
<br />
"|/home/pacs/xyz00/users/listen/mailman/mail/mailman [Befehl] [Listenname]"<br />
<br />
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.<br />
<br />
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.)<br />
<br />
echo 'admin@xyz00.hostsharing.net' > .forward # Weiterleitung von cron Fehlern etc an Paketadmin.<br />
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman post mailman"' > .forward+mailman<br />
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman admin mailman"' > .forward+mailman-admin<br />
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman bounces mailman"' > .forward+mailman-bounces<br />
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman confirm mailman"' > .forward+mailman-confirm<br />
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman join mailman"' > .forward+mailman-join<br />
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman leave mailman"' > .forward+mailman-leave<br />
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman owner mailman"' > .forward+mailman-owner<br />
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman request mailman"' > .forward+mailman-request<br />
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman subscribe mailman"' > .forward+mailman-subscribe<br />
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman unsubscribe mailman"' > .forward+mailman-unsubscribe<br />
<br />
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/mailmanaddresses</tt> mit folgendem Inhalt zu erstellen:<br />
<br />
<pre><br />
#!/bin/bash<br />
# Add e-mail addresses and dot-forward files for mailman lists.<br />
#<br />
<br />
# All the sanity checks.<br />
<br />
if [ "$3" = "" -o "$2" = "" -o "$1" = "" ] ; then<br />
echo "Syntax: $0 listname domainname listowner\n" <br />
exit<br />
fi<br />
<br />
if [ "$4" != "" ] ; then<br />
echo "Syntax: $0 listname domainname listowner\n" <br />
exit<br />
fi<br />
<br />
if [ "`pwd`" != "`echo ~`" ] ; then<br />
echo "Run this script from your home directory.\n" <br />
exit<br />
fi<br />
<br />
if [ ! -d "../${3:6}" ] ; then<br />
echo "There's no user named $3."<br />
exit<br />
else<br />
echo "You may be asked for a password for $3."<br />
fi<br />
<br />
if [ ! -d "./mailman/Mailman" ] ; then<br />
echo "Are you sure you have a Mailman installation?"<br />
exit<br />
fi<br />
<br />
# hsscript fails with a "no result" and 255 if $2 (domain name) is not valid.<br />
# It also fails if a requested address already exists.<br />
# scriptexpr contains the expanded variables. Avoid spaces, because it's unquoted in the hsscript call.<br />
<br />
# Add the base list address and its forward file:<br />
scriptexpr="emailaddress.add({set:{localpart:\"$1\",target:\"xyz00-lists+$1\",domain:\"$2\"}})"<br />
hsscript -r$3 -u$3 -e $scriptexpr<br />
if [ "$?" != "0" ] ; then echo "hsscript failed to add address with localpart $1" ; exit ; fi<br />
echo "\"|/home/pacs/xyz00/users/lists/mailman/mail/mailman post $1\"" > .forward+$1<br />
if [ "$?" != "0" ] ; then echo "failed to create a forward file for posts" ; exit ; fi<br />
<br />
# Now do the same for all the suffixes<br />
for subpart in admin bounces confirm join leave owner request subscribe unsubscribe<br />
do<br />
scriptexpr="emailaddress.add({set:{localpart:\"$1-${subpart}\",target:\"xyz00-lists+$1-${subpart}\",domain:\"$2\"}})"<br />
hsscript -r$3 -u$3 -e $scriptexpr<br />
if [ "$?" != "0" ] ; then echo "hsscript failed on subpart ${subpart}" ; exit ; fi<br />
echo "\"|/home/pacs/xyz00/users/lists/mailman/mail/mailman $subpart $1\"" > .forward+$1-$subpart<br />
if [ "$?" != "0" ] ; then echo "failed to create a forward file for ${subpart}" ; exit ; fi<br />
done<br />
<br />
echo "$0 ran to the end and finished with $?"<br />
exit<br />
</pre><br />
Der Skript muß natürlich als ausführbar gekennzeichnet werden:<br />
<br />
~$ chmod u+x bin/mailmanaddresses<br />
<br />
Um .<br />
<br />
=== Administration ===<br />
<br />
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.<br />
<br />
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:<br />
<br />
~$ mailman/bin/newlist <Listenname><br />
<br />
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.<br />
<br />
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].<br />
<br />
== Feintuning == <br />
<br />
Wer will, kann auch noch etwas Platz sparen. Die normale Mailmaninstallation schlägt mit über 20 MB zu Buche...<br />
<br />
Mit den folgenden Tips kann man das auf ca. 6 MB reduzieren :)<br />
<br />
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!<br />
<br />
* ~/mailman/cgi-bin und ~/mailman/icons können gelöscht werden, falls sie an andere Stelle kopiert worden sind.<br />
* Die nicht benötigten Sprachen in ~/mailman/messages löschen.<br />
* Die nicht benötigten Sprachen in ~/mailman/templates löschen (bis auf englisch).<br />
* ~/mailman/tests kann, soweit ich das sehe, komplett gelöscht werden.<br />
* Falls man koreanisch und japanisch nicht braucht, kann man folgendes machen:<br />
* in ~/mailman/bin/paths.py, ~/mailman/cron/paths.py und ~/mailman/scripts/paths.py die Zeilen:<br />
<br />
# In a normal interactive Python environment, the japanese.pth and korean.pth<br />
# files would be imported automatically. But because we inhibit the importing<br />
# of the site module, we need to be explicit about importing these codecs.<br />
if not jaok:<br />
import japanese<br />
# As of KoreanCodecs 2.0.5, you had to do the second import to get the Korean<br />
# codecs installed, however leave the first import in there in case an upgrade<br />
# changes this.<br />
if not kook:<br />
import korean<br />
import korean.aliases<br />
<br />
auskommentieren.<br />
<br />
Dann kann man ~/mailman/pythonlib/japanese, ~/mailman/pythonlib/korean, ~/mailman/pythonlib/korean.pth sowie ~/mailman/pythonlib/lib löschen.<br />
<br />
Man kann auch noch die Debug-Informationen aus den binaries strippen:<br />
<br />
strip ~/mailman/mail/mailman<br />
strip ~/mailman/cgi-bin/*<br />
<br />
Falls die CGIs nicht gesymlinkt wurden:<br />
<br />
strip ~/doms/listen.example.com/cgi/mailman/*<br />
<br />
== Multidomainfähigkeit ==<br />
<br />
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.<br />
<br />
=== Anleitung ===<br />
<br />
Logischerweise muss das Webfrontend (die CGIs) auf allen Domains installiert werden.<br />
<br />
Wenn man nun Mailinglisten mit newlist neu anlegt, muss man den Hostnamen für das Webfontend mit angeben, und zwar so:<br />
<br />
~$ mailman/bin/newlist listenname@listen.example.com<br />
<br />
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.)<br />
<br />
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:<br />
<br />
Also z.B.<br />
DEFAULT_URL_HOST = 'www.example.com'<br />
DEFAULT_EMAIL_HOST = 'listen.example.com'<br />
add_virtualhost(DEFAULT_URL_HOST,DEFAULT_EMAIL_HOST)<br />
<br />
und<br />
add_virtualhost('www.zoopnet.de', 'lists.zoopnet.de')<br />
<br />
Das bedeutet, dass Mailman per default davon ausgeht, dass alle Listen für die Domain example.com sind.<br />
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.<br />
<br />
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.<br />
<br />
<br />
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. :)<br />
<br />
=== Probleme ===<br />
<br />
Verschiedene Listen mit gleichem Namen (also z.B. liste@example1.com und liste@example2.com) sind mit Mailman 2.1 leider nicht möglich.<br />
<br />
<br />
== Tips und Tricks ==<br />
<br />
=== URL Änderungen ===<br />
Nach URL Änderungen stimmen Links im Web-Interface nicht mehr und Listen werden nicht mehr angezeigt.<br />
Es sind dann, zusätzlich zur Anpassung der mm_cfg.py, schon bestehende Listen und Archive mit folgendem Befehl zu aktualisieren:<br />
~/mailman/bin/withlist -l -r fix_url <Listen_Name> -v -u <Neue_Url><br />
<Listen_Name> steht für die Mailingliste, die bearbeitet werden soll. <Neue_Url> für die neue URL/Webadresse des Webinterfaces.<br />
<br />
=== Weitere Cron-Jobs zur Mailinglisten Verwaltung ===<br />
<br />
Folgende Cronjobs helfen bei der Verwaltung und sind User freundlich:<br />
<br />
< In Arbeit ><br />
<br />
== Referenzen ==<br />
<br />
Lösung zur installation als Domainadmin (xyz00-listen) statt Paketadmin (xyz00): https://lists.hostsharing.net/archiv/support/2009-June/019414.html<br><br />
<br />
Ältere Anleitung für Installation als Domain-Admin (xyz00-listen): <http://lists.hostsharing.net/archiv/support/2005-January/012426.html><br><br />
<br />
"Kleine Tools" auf http://hs.andreasloesch.de/, wobei das 'pac-mm-install' wahrscheinlich nicht aktuell (genug) ist<br><br />
<br />
----<br />
[[Kategorie:HSDoku]]<br />
[[Kategorie:Installationsanleitungen]]<br />
[[Kategorie:Software]]<br />
[[Kategorie:Mailinglisten]]<br />
[[Kategorie:E-Mail]]<br />
[[Kategorie:Python]]</div>Apc00-tonyhttps://wiki.hostsharing.net/index.php?title=Mailman_Installieren&diff=6274Mailman Installieren2023-11-10T17:03:05Z<p>Apc00-tony: /* E-Mail Adressen bei Mailman einrichten */ Updated script</p>
<hr />
<div>== Vorab: Die Wahl von Mailman 2 ==<br />
<br />
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.]<br />
<br />
== Mailman 2 installieren == <br />
<br />
(zuletzt getestet mit mailman-2.1.29; Installation durch Paketuser)<br />
<br />
Vielen Dank an alle Benutzer, die Verbesserungen beisteuern!<br />
<br />
=== Unter welchem Account installieren? ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Nachteil der Installation als Paketuser ist lediglich, dass die Paketdomain mit dem SSL Zertifikat von Hostsharing nicht genutzt werden kann.<!-- Aktualisieren? --><br />
<br />
=== Einen User und eine Domain anlegen ===<br />
<br />
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.<br />
<br />
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:<br />
<br />
~$ echo "" > ~/doms/listen.example.com/htdocs-ssl/.htaccess<br />
<br />
Die Default-Subdomains www.* löschen:<br />
<br />
~$ rm -r doms/listen.example.com/subs/www/<br />
~$ rm -r doms/listen.example.com/subs-ssl/www/<br />
<br />
=== Sourcen besorgen und entpacken ===<br />
<br />
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 ...<br />
<br />
~$ wget http://ftp.gnu.org/gnu/mailman/mailman-2.1.29.tgz<br />
<br />
... und entpacken:<br />
<br />
~$ tar -xzvf mailman-2.1.29.tgz<br />
<br />
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.)<br />
<br />
=== var-Verzeichnis für Log-Dateien anlegen ===<br />
<br />
Bei der Installation als Paketuser (xyz00-listen):<br />
~$ cd && mkdir -p mailman/var<br />
~$ chmod 02775 mailman/var<br />
<br />
Bei der Installation als Paketadmin (xyz00):<br />
~$ cd && mkdir var/mailman<br />
~$ chmod 02775 var/mailman<br />
<br />
=== Mailman konfigurieren ===<br />
<br />
In das Source-Verzeichnis wechseln:<br />
<br />
~$ cd mailman-2.1.29<br />
<br />
Bei der Installation durch den Paketuser (xyz00-listen):<br />
~/mailman-2.1.29$ ./configure --prefix=/home/pacs/xyz00/users/listen/mailman \<br />
--with-username=xyz00-listen \<br />
--with-groupname=xyz00 \<br />
--with-var-prefix=/home/pacs/xyz00/users/listen/mailman/var \<br />
--with-cgi-gid=xyz00 \<br />
--with-mail-gid=xyz00<br />
<br />
Bei der Installation durch den Paketadmin (xyz00):<br />
~/mailman-2.1.29$ ./configure --prefix=/home/pacs/xyz00/mailman \<br />
--with-username=xyz00 \<br />
--with-groupname=xyz00 \<br />
--with-var-prefix=/home/pacs/xyz00/var/mailman \<br />
--with-cgi-gid=xyz00 \<br />
--with-mail-gid=nogroup<br />
<br />
(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.)<br />
<br />
=== Mailman kompilieren ===<br />
<br />
~/mailman-2.1.29$ make<br />
~/mailman-2.1.29$ make install<br />
<br />
=== Datenrechte prüfen ===<br />
<br />
Sicherheitshalber die Dateirechte durch Mailmans mitgeliefertes Tool prüfen und ggf. korrigieren lassen:<br />
<br />
~/mailman-2.1.29$ cd .. <br />
~$ mailman/bin/check_perms -f<br />
<br />
== Die neue Mailman-Installation konfigurieren ==<br />
<br />
=== Konfigurationsdatei <tt>mm_cfg.py</tt> editieren ===<br />
<br />
~$ nano mailman/Mailman/mm_cfg.py<br />
<br />
Eine Beispielkonfiguration für listen.example.com könnte so aussehen:<br />
<br />
[...]<br />
##################################################<br />
# Put YOUR site-specific settings below this line.<br />
# -*- python -*-<br />
<br />
DEFAULT_HOST_NAME = 'listen.example.com'<br />
DEFAULT_EMAIL_HOST = 'listen.example.com'<br />
DEFAULT_URL_HOST = 'listen.example.com'<br />
add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)<br />
add_virtualhost(zweite.listendomain.com, zweite.listendomain.com)<br />
<br />
DEFAULT_SERVER_LANGUAGE = 'de'<br />
<br />
DEFAULT_URL_PATTERN = 'http://%s/'<br />
<br />
# Es wird der HS Mailversand für Bulkmail verwendet:<br />
SMTPHOST = 'localhost'<br />
SMTPPORT = 4587 <br />
SMTP_AUTH = True<br />
SMTP_USER = 'xyz00-listen'<br />
SMTP_PASSWD = 'das-passwort-des-o.-g.-users'<br />
SMTP_USE_TLS = True<br />
<br />
<br />
In <tt>~/mailman/Mailman/Defaults.py</tt> sieht man, was in mm_cfg.py alles angepasst werden kann.<br />
<br />
==== Mailman gegen Subscription Spam härten ====<br />
<br />
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:<br />
<br />
Die Idee kommt von https://www.ralfj.de/blog/2018/06/02/mailman-subscription-spam.html<br />
<br />
Auf der Kommandozeile ein zufälliges Secret-String erstellen:<br />
openssl rand -base64 18<br />
<br />
Und dann in die Konfigurationsdatei den erzeugten String einfügen:<br />
<br />
SUBSCRIBE_FORM_SECRET = '<Secret-String>'<br />
<br />
=== CGI-Programme in die Domain kopieren ===<br />
<br />
Bei der Installation als Paketuser (xyz00-listen):<br />
<br />
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.<br />
<br />
~$ mkdir ~/doms/listen.example.com/cgi-ssl/mailman<br />
~$ cp mailman/cgi-bin/* doms/listen.example.com/cgi-ssl/mailman/<br />
<br />
Zusätzlich muss das sticky-Flag von den kopierten Dateien entfernt werden:<br />
<br />
~$ chmod g-s ~/doms/listen.example.com/cgi/mailman/*<br />
<br />
Bei der Installation als Paketadmin (xyz00): <br />
<br />
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: <br />
<br />
~$ cd doms/listen.example.com/cgi-ssl<br />
~/doms/listen.example.com/cgi-ssl$ ln -s ../../../mailman/cgi-bin mailman<br />
<br />
=== Mailman-Icons in die Domains kopieren ===<br />
<br />
Die Icons können wahlweise verlinkt oder kopiert werden:<br />
<br />
~$ cd doms/listen.example.com/htdocs-ssl<br />
~/doms/listen.example.com/htdocs-ssl$ ln -s ../../../mailman/icons<br />
<br />
oder<br />
<br />
~$ cp -R mailman/icons doms/listen.example.com/htdocs-ssl/<br />
<br />
=== Die Datei .htaccess bearbeiten ===<br />
<br />
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.<br />
<br />
Dazu werden in <tt><nowiki>~/doms/listen.example.com/htdocs-ssl/.htaccess</nowiki></tt> folgende Rewrite-Anweisungen eintragen.<br />
<br />
RewriteEngine On<br />
RewriteCond %{REQUEST_URI} !^/icons/<br />
RewriteRule ^(.*)$ /cgi-bin/mailman/$1<br />
RewriteRule ^/cgi-bin/mailman/$ /cgi-bin/mailman/listinfo<br />
<br />
Beachte dabei die zweite Zeile: Anfragen für Icons sollen ''nicht'' umgeschrieben werden.<br />
<br />
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>:<br />
<br />
RewriteEngine On<br />
RewriteCond %{REQUEST_URI} !^/icons/<br />
RewriteRule ^mailman/(.*)$ /cgi-bin/mailman/$1<br />
RewriteRule ^/cgi-bin/mailman/$ /cgi-bin/mailman/listinfo<br />
<br />
(In diesem Fall kann die Zeile <tt>DEFAULT_URL_PATTERN...</tt> in der <tt>mm_cfg.py</tt> auskommentiert werden.)<br />
<br />
=== Hauptpasswort setzen ===<br />
<br />
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: <br />
<br />
~$ mailman/bin/mmsitepass<br />
<br />
=== Cronjobs einrichten ===<br />
<br />
In die [[Cron |Crontab]] werden Befehle eingetragen, um die Mail-Warteschlange abzuarbeiten, Logs zu löschen, usw.:<br />
<br />
# Warteschlange jede Minute bearbeiten:<br />
* * * * * ~/mailman/bin/qrunner -o -r All<br />
# Verarbeitungslogs in der 47ten Minute jeder Stunde löschen:<br />
47 * * * * rm -f ~/var/mailman/logs/qrunner<br />
<br />
Damit übernimmt cron die Funktion des qrunner-Dämons, der normalerweise auf einem Mailman-Server laufen sollte.<br />
<br />
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:<br />
<br />
47 * * * * rm -f ~/mailman/var/logs/qrunner<br />
<br />
... entsprechend dem beim Konfigurieren angegebenen <tt>var</tt>-Verzeichnis, siehe oben.<br />
<br />
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:<br />
<br />
crontab -l > mycronjobs.tmp<br />
cat ~/mailman/cron/crontab.in >> mycronjobs.tmp<br />
crontab mycronjobs.tmp<br />
<br />
== Mailinglisten einrichten ==<br />
<br />
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 <br />
<br />
MAILMAN_SITE_LIST = 'sitelistname'<br />
<br />
in der Konfigurationsdatei <tt>mailman/Mailman/mm_cfg.py</tt> eingetragen werden.<br />
<br />
=== Den Hauptverteiler "mailman" anlegen ===<br />
<br />
Die "site list" mit dem Namen "mailman" ist die Mailingliste der lokalen Mailman-Administratoren. Sie wird zur einwandfreien Funktion von Mailman benötigt.<br />
<br />
Mit dem Mailman-Befehl newlist den Verteiler anlegen:<br />
<br />
~$ mailman/bin/newlist mailman<br />
Enter the email of the person running the list: admin@xyz00.hostsharing.net<br />
Initial mailman password:<br />
<br />
(Der Befehl newlist kann – alternativ zur Weboberfläche – später benutzt werden, um gewöhnliche Mailinglisten anzulegen.)<br />
<br />
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.)<br />
<br />
Falls mailman vom Paketuser (bspw. "xyz00-listen") installiert wurde:<br />
<br />
~$ mailman/bin/config_list -i ~/mailman/var/data/sitelist.cfg mailman<br />
<br />
Falls mailman vom Paketadmin ("xyz00") installiert wurde:<br />
<br />
~$ mailman/bin/config_list -i ~/var/mailman/data/sitelist.cfg mailman<br />
<br />
Diese Konfigurationsdatei soll '''nicht''' auf gewöhnliche Mailinglisten anwendet werden.<br />
<br />
=== E-Mail Adressen bei Mailman einrichten ===<br />
<br />
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. <br />
<br />
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.<br />
<br />
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.)<br />
<br />
hsscript -u xyz00 -i<br />
[hsscript verlangt die Eingabe des Passworts vom Paketadmin xyz00; dann können diese Befehle eingegeben werden:]<br />
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman',target:'xyz00-listen+mailman'}})<br />
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-admin',target:'xyz00-listen+mailman-admin'}})<br />
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-bounces',target:'xyz00-listen+mailman-bounces'}})<br />
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-confirm',target:'xyz00-listen+mailman-confirm'}})<br />
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-join',target:'xyz00-listen+mailman-join'}})<br />
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-leave',target:'xyz00-listen+mailman-leave'}})<br />
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-owner',target:'xyz00-listen+mailman-owner'}})<br />
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-request',target:'xyz00-listen+mailman-request'}})<br />
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-subscribe',target:'xyz00-listen+mailman-subscribe'}})<br />
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-unsubscribe',target:'xyz00-listen+mailman-unsubscribe'}})<br />
<br />
Die korrekte Einrichtung der E-Mail-Adressen kann in der Web-Oberfläche von hsadmin kontrolliert werden.<br />
<br />
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:<br />
<br />
"|/home/pacs/xyz00/users/listen/mailman/mail/mailman [Befehl] [Listenname]"<br />
<br />
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.<br />
<br />
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.)<br />
<br />
echo 'admin@xyz00.hostsharing.net' > .forward # Weiterleitung von cron Fehlern etc an Paketadmin.<br />
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman post mailman"' > .forward+mailman<br />
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman admin mailman"' > .forward+mailman-admin<br />
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman bounces mailman"' > .forward+mailman-bounces<br />
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman confirm mailman"' > .forward+mailman-confirm<br />
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman join mailman"' > .forward+mailman-join<br />
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman leave mailman"' > .forward+mailman-leave<br />
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman owner mailman"' > .forward+mailman-owner<br />
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman request mailman"' > .forward+mailman-request<br />
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman subscribe mailman"' > .forward+mailman-subscribe<br />
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman unsubscribe mailman"' > .forward+mailman-unsubscribe<br />
<br />
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/mailmanaddresses</tt> mit folgendem Inhalt zu erstellen:<br />
<br />
<pre><br />
#!/bin/bash<br />
# Add e-mail addresses and dot-forward files for mailman lists.<br />
#<br />
<br />
# All the sanity checks.<br />
<br />
if [ "$3" = "" -o "$2" = "" -o "$1" = "" ] ; then<br />
echo "Syntax: $0 listname domainname listowner\n" <br />
exit<br />
fi<br />
<br />
if [ "$4" != "" ] ; then<br />
echo "Syntax: $0 listname domainname listowner\n" <br />
exit<br />
fi<br />
<br />
if [ "`pwd`" != "`echo ~`" ] ; then<br />
echo "Run this script from your home directory.\n" <br />
exit<br />
fi<br />
<br />
if [ ! -d "../${3:6}" ] ; then<br />
echo "There's no user named $3."<br />
exit<br />
else<br />
echo "You may be asked for a password for $3."<br />
fi<br />
<br />
if [ ! -d "./mailman/Mailman" ] ; then<br />
echo "Are you sure you have a Mailman installation?"<br />
exit<br />
fi<br />
<br />
# hsscript fails with a "no result" and 255 if $2 (domain name) is not valid.<br />
# It also fails if a requested address already exists.<br />
# scriptexpr contains the expanded variables. Avoid spaces, because it's unquoted in the hsscript call.<br />
<br />
# Add the base list address and its forward file:<br />
scriptexpr="emailaddress.add({set:{localpart:\"$1\",target:\"apc00-lists+$1\",domain:\"$2\"}})"<br />
hsscript -r$3 -u$3 -e $scriptexpr<br />
if [ "$?" != "0" ] ; then echo "hsscript failed to add address with localpart $1" ; exit ; fi<br />
echo "\"|/home/pacs/apc00/users/lists/mailman/mail/mailman post $1\"" > .forward+$1<br />
if [ "$?" != "0" ] ; then echo "failed to create a forward file for posts" ; exit ; fi<br />
<br />
# Now do the same for all the suffixes<br />
for subpart in admin bounces confirm join leave owner request subscribe unsubscribe<br />
do<br />
scriptexpr="emailaddress.add({set:{localpart:\"$1-${subpart}\",target:\"apc00-lists+$1-${subpart}\",domain:\"$2\"}})"<br />
hsscript -r$3 -u$3 -e $scriptexpr<br />
if [ "$?" != "0" ] ; then echo "hsscript failed on subpart ${subpart}" ; exit ; fi<br />
echo "\"|/home/pacs/apc00/users/lists/mailman/mail/mailman $subpart $1\"" > .forward+$1-$subpart<br />
if [ "$?" != "0" ] ; then echo "failed to create a forward file for ${subpart}" ; exit ; fi<br />
done<br />
<br />
echo "$0 ran to the end and finished with $?"<br />
exit<br />
</pre><br />
Der Skript muß natürlich als ausführbar gekennzeichnet werden:<br />
<br />
~$ chmod u+x bin/mailmanaddresses<br />
<br />
Die Erweiterung dieses Skripts um die <tt>hsscript</tt>-Befehle wird dem geneigten Leser als Aufgabe überlassen.<br />
<br />
=== Administration ===<br />
<br />
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.<br />
<br />
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:<br />
<br />
~$ mailman/bin/newlist <Listenname><br />
<br />
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.<br />
<br />
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].<br />
<br />
== Feintuning == <br />
<br />
Wer will, kann auch noch etwas Platz sparen. Die normale Mailmaninstallation schlägt mit über 20 MB zu Buche...<br />
<br />
Mit den folgenden Tips kann man das auf ca. 6 MB reduzieren :)<br />
<br />
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!<br />
<br />
* ~/mailman/cgi-bin und ~/mailman/icons können gelöscht werden, falls sie an andere Stelle kopiert worden sind.<br />
* Die nicht benötigten Sprachen in ~/mailman/messages löschen.<br />
* Die nicht benötigten Sprachen in ~/mailman/templates löschen (bis auf englisch).<br />
* ~/mailman/tests kann, soweit ich das sehe, komplett gelöscht werden.<br />
* Falls man koreanisch und japanisch nicht braucht, kann man folgendes machen:<br />
* in ~/mailman/bin/paths.py, ~/mailman/cron/paths.py und ~/mailman/scripts/paths.py die Zeilen:<br />
<br />
# In a normal interactive Python environment, the japanese.pth and korean.pth<br />
# files would be imported automatically. But because we inhibit the importing<br />
# of the site module, we need to be explicit about importing these codecs.<br />
if not jaok:<br />
import japanese<br />
# As of KoreanCodecs 2.0.5, you had to do the second import to get the Korean<br />
# codecs installed, however leave the first import in there in case an upgrade<br />
# changes this.<br />
if not kook:<br />
import korean<br />
import korean.aliases<br />
<br />
auskommentieren.<br />
<br />
Dann kann man ~/mailman/pythonlib/japanese, ~/mailman/pythonlib/korean, ~/mailman/pythonlib/korean.pth sowie ~/mailman/pythonlib/lib löschen.<br />
<br />
Man kann auch noch die Debug-Informationen aus den binaries strippen:<br />
<br />
strip ~/mailman/mail/mailman<br />
strip ~/mailman/cgi-bin/*<br />
<br />
Falls die CGIs nicht gesymlinkt wurden:<br />
<br />
strip ~/doms/listen.example.com/cgi/mailman/*<br />
<br />
== Multidomainfähigkeit ==<br />
<br />
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.<br />
<br />
=== Anleitung ===<br />
<br />
Logischerweise muss das Webfrontend (die CGIs) auf allen Domains installiert werden.<br />
<br />
Wenn man nun Mailinglisten mit newlist neu anlegt, muss man den Hostnamen für das Webfontend mit angeben, und zwar so:<br />
<br />
~$ mailman/bin/newlist listenname@listen.example.com<br />
<br />
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.)<br />
<br />
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:<br />
<br />
Also z.B.<br />
DEFAULT_URL_HOST = 'www.example.com'<br />
DEFAULT_EMAIL_HOST = 'listen.example.com'<br />
add_virtualhost(DEFAULT_URL_HOST,DEFAULT_EMAIL_HOST)<br />
<br />
und<br />
add_virtualhost('www.zoopnet.de', 'lists.zoopnet.de')<br />
<br />
Das bedeutet, dass Mailman per default davon ausgeht, dass alle Listen für die Domain example.com sind.<br />
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.<br />
<br />
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.<br />
<br />
<br />
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. :)<br />
<br />
=== Probleme ===<br />
<br />
Verschiedene Listen mit gleichem Namen (also z.B. liste@example1.com und liste@example2.com) sind mit Mailman 2.1 leider nicht möglich.<br />
<br />
<br />
== Tips und Tricks ==<br />
<br />
=== URL Änderungen ===<br />
Nach URL Änderungen stimmen Links im Web-Interface nicht mehr und Listen werden nicht mehr angezeigt.<br />
Es sind dann, zusätzlich zur Anpassung der mm_cfg.py, schon bestehende Listen und Archive mit folgendem Befehl zu aktualisieren:<br />
~/mailman/bin/withlist -l -r fix_url <Listen_Name> -v -u <Neue_Url><br />
<Listen_Name> steht für die Mailingliste, die bearbeitet werden soll. <Neue_Url> für die neue URL/Webadresse des Webinterfaces.<br />
<br />
=== Weitere Cron-Jobs zur Mailinglisten Verwaltung ===<br />
<br />
Folgende Cronjobs helfen bei der Verwaltung und sind User freundlich:<br />
<br />
< In Arbeit ><br />
<br />
== Referenzen ==<br />
<br />
Lösung zur installation als Domainadmin (xyz00-listen) statt Paketadmin (xyz00): https://lists.hostsharing.net/archiv/support/2009-June/019414.html<br><br />
<br />
Ältere Anleitung für Installation als Domain-Admin (xyz00-listen): <http://lists.hostsharing.net/archiv/support/2005-January/012426.html><br><br />
<br />
"Kleine Tools" auf http://hs.andreasloesch.de/, wobei das 'pac-mm-install' wahrscheinlich nicht aktuell (genug) ist<br><br />
<br />
----<br />
[[Kategorie:HSDoku]]<br />
[[Kategorie:Installationsanleitungen]]<br />
[[Kategorie:Software]]<br />
[[Kategorie:Mailinglisten]]<br />
[[Kategorie:E-Mail]]<br />
[[Kategorie:Python]]</div>Apc00-tonyhttps://wiki.hostsharing.net/index.php?title=Benutzer:Apc00-tony/Dynamisches_DNS&diff=6229Benutzer:Apc00-tony/Dynamisches DNS2023-09-11T14:36:09Z<p>Apc00-tony: </p>
<hr />
<div>Update 2023: Ich habe die Verwaltung über Befehlszeile durch eine PHP-Web-Oberfläche ersetzt; Details irgendwo ... ah, [https://ddns.crawfords.de/verwaltung/ddnsadminhints?name=acanthus_crawford_berlin hier]. Meine Hostsharing-DDNS-Lösung läuft übrigens schon lange einwandfrei; ich benutze sie dazu, ein VPN zwischen meinen Fritz!Box-LANS zu Hause und im Büro zu realisieren sowie um auf ein Backup- und Music-Server (ein Raspberry Pi) zu Hause von unterwegs zuzugreifen.<br />
<br />
((Provisorischer Vorspann: Auf Grund einer Mailing-Listen-Diskussion habe ich angefangen, Dynamisches DNS über einen CGI-Skript bei Hostsharing zu realisieren. Meine Lösung habe ich dann vorgestellt; sie wurde für nicht ausreichend selbsterklärend befunden und fand wenig Akzeptanz. Hier also der Versuch, die Sache zu dokumentieren.))<br />
<br />
Mit der regelmäßigen Aufnahme von benutzerspezifischen Zonefiles in seiner DNS-Konfiguration bietet Hostsharing alles, was man braucht, um &bdquo;dynamisches DNS&ldquo; in Eigenregie zu realisieren.<br />
<br />
Das heißt, wenn ich mindestens eine Domain bei Hostsharing verwalte, und mindestens eine Einwahlverbindung (oder DSL-Verbindung) ins Internet mit wechselnder IP-Adresse über irgendeinen ISP für meinen Arbeitsplatzrechner zu Hause betreibe, dann kann ich dem Arbeitsplatzrechner über die DNS-Server von Hostsharing einen vollqualifizieren Domainnamen zuweisen, der der jeweiligen IP-Adresse meiner Einwahlleitung zugeordnet ist.<br />
<br />
<pre><br />
<br />
(ASCII-Art-Diagramm der beschriebenen Konstellation)<br />
<br />
</pre><br />
<br />
Im Folgenden wird eine real existierende Implementierung von Dynamischem DNS (&bdquo;DDNS&ldquo;) beschrieben. Die verschiedenen Elemente könnten durchaus anders realisiert werden; die beschriebene Implementierung könnte durchaus verbessert werden. Sie dient hier der Illustration.<br />
<br />
In der folgenden Beschreibung werden diese Beispielwerte benutzt:<br />
* Ein Hostsharing-Mitglied hat ein Account als Paket-Admin mit Kennung xyz00.<br />
* Im Paket xyz00 gibt es einen Domain-Admin namens xyz00-benutzername.<br />
* Dieser Domain-Admin verwaltet bei Hostsharing die Domains example.com und beispiel.de.<br />
* Ein Benutzer hat zu Hause (oder im Büro) einen Arbeitsplatzrechner hinter der marktüblichen DSL-Leitung, die von seinem ISP bereitgestellt wird.<br />
* Dieser Arbeitsplatzrechner (oder der Router, der seine Internetverbindung steuert) bekommt vom ISP immer wechselnde IP-Adressen zugewiesen.<br />
* Dennoch möchte der Benutzer seinen Arbeitsplatzrechner aus dem Internet unter dem Hostnamen einwahl.example.com ansprechen können.<br />
<br />
Dazu kann ein System wie Hostsharing, das authoritative DNS-Informationen für viele Domains bereitstellt, auch veränderliche DNS-Information über dynamisch verbundene Rechner verwalten &ndash; sofern das ressourcenschonend gemacht werden kann ohne andere Funktionen zu stören.<br />
<br />
== Aufgaben des Servers ==<br />
<br />
Um einem Rechner mit wechselnder IP-Adresse einen DDNS-Eintrag zu bieten, muß der Hostsharing-Server folgendes leisten (in ungefährer Reihenfolge der Ereignisse):<br />
<br />
# Eine Anfrage entgegennehmen, beispielsweise über HTTPS, von einem entfernten Rechner, der einen DNS-Eintrag für seine momentane IP-Adresse wünscht. <br />
# Prüfen, ob die Anfrage einen berechtigten DDNS-Dienst-Usernamen mit zugehörigem Paßwort enthält.<br />
# Prüfen, ob die Anfrage einen gültigen Domainnamen betrifft, den der Server bieten darf.<br />
# Prüfen, ob die Domain example.com demselben Benutzer gehört, unter dessen Namen der Dynamisches-DNS-Server läuft.<br />
# Eine gültige [[Zonefile]] mit &ndash; neben dem bisherigen Inhalt &ndash; einem A-Eintrag für einwahl.example.com in /home/pacs/xyz00/users/benutzername/doms/example.com/pri.example.com schreiben.<br />
# Dem Client eine Bestätigung oder ggf. eine Fehlermeldung als Antwort senden.<br />
# In irgendeiner Datenbank den momentan eingestellter Status all seiner DDNS-Einträge speichern.<br />
# In einer Logdatei protokollieren, daß obiges getan wurde, oder ggf. welche Fehler traten auf.<br />
<br />
== Aufgaben des Clients ==<br />
Bevor ich anfange, meinen Arbeitsplatzrechner so zu konfigurieren, daß er bei welchem Server auch immer einen DDNS-Eintrag anfordert, muß ich mich als verantwortlicher Benutzer dieses Rechners und der dazugehörigen Internetverbindung &ndash; das heißt, als Mensch &ndash; mit dem Betreiber des dynamisches-DNS-Servers vereinbaren, daß ich das darf und welchen Eintrag ich bekommen kann. Im Folgenden wird vorausgesetzt, daß solche Vereinbarungen getroffen und die Parameter geklärt wurden.<br />
<br />
Der DDNS-Client muß aus Server-Sicht nur wenig leisten:<br />
<br />
# Eine Anfrage senden, beispielsweise über HTTPS, an einen entfernten Rechner, der einen Eintrag ins DNS für die momentane IP-Adresse des Clients vornehmen kann.<br />Diese Anfrage muß einem festgelegten Format entsprechen und muß gültige Werte für die Authorisation des Clients, den gewünschten Domainnamen, und eventuell andere Parameter enthalten.<br />
# Eine Antwort des Servers entgegennehmen und als Erfolgs- oder Fehlermeldung auswerten.<br />
# Von überflüssigen Anfragen absehen: das heißt bei Erfolg, nicht wiederholt den gleichen Eintrag erneut wünschen; bei Fehlern, nicht die gleiche fehlerhafte Anfrage erneut schicken.<br />
<br />
== Kommunikation zwischen Client und Server ==<br />
<br />
Ein einziges Nachrichtenpaar von Anfrage und Antwort genügt, um einen DDNS-Eintrag einzurichten: Der Client teilt die IP-Adresse und den Domainnamen mit, die in einem DNS-Eintrag verbunden werden sollen; der Server bestätigt den Auftrag.<br />
<br />
In der Beispielimplementierung erfolgt die Kommunikation über HTTP, und die Anfrage des Clients könnte so aussehen:<br />
<br />
GET /cgi-bin/ddns?hostname=einwahl.example.com&myip=87.65.43.21 HTTP/1.1<br />
Host: ddns.beispiel.de<br />
User-Agent: Fritz!Box DDNS/1.0.1<br />
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==<br />
<br />
Bei Erhalt dieser Anfrage ruft Apache das CGI-Programm .../doms/ddns.beispiel.de/cgi-ssl/ddns auf. Das Fragezeichen trennt den Programmnamen von einem "Query-String", in dem zwei Metavariablen definiert und übergeben werden. Die erste Metavariable, hostname, hat den Wert "einwahl.example.com"; die zweite, myip, hat den Wert "87.65.43.21".<br />
<br />
Das Server-Programm, hier ''ddns'', prüft diese Informationen auf Form und Berechtigung, und schreibt gegebenenfalls einen entsprechenden Eintrag in einer Zonefile. Es schreibt auch verschiedene Informationen in die Standardausgabe. Wenn es die Standardausgabe geschlossen wird &ndash; also spätestens bei Programmende &ndash; schickt Apache diese Informationen als Antwort an den anfragenden Rechner zurück.<br />
<br />
Im Falle unserer Beispielimplementierung sieht die Antwort bei Erfolg so aus: <br />
<br />
HTTP/1.1 200 OK<br />
Date: Wed, 22 Apr 2020 08:35:15 GMT<br />
Server: Apache<br />
Content-Length: 17<br />
Content-Type: text/plain; charset=ISO-8859-1<br />
<br />
good 87.65.43.21<br />
<br />
=== Das DDNS-Protokoll von DynDNS.org ===<br />
<br />
In den 90er Jahren, bevor das Internet so durchgehend vergeschäftlicht wurde, boten einige Organisationen kostenlose DDNS-Dienste an. Ein sehr beliebtes Angebot war das von DynDNS.org. Das DDNS-Protokoll von diesem Dienst wurde sogar in Einwahl-Routern einprogrammiert und der Dienst wurde von ISPs und Router-Herstellern als Leistungsmerkmal beworben.<br />
<br />
DynDNS.org gehört inzwischen Oracle und bietet keine kostenlose Dienste mehr. Dennoch wird das DDNS-Protokoll von DynDNS.org in der vorliegenden Beispielimplementierung übernommen in der Hoffnung, daß die Kompatibilität mit einigen gängigen Einwahl-Routern von Vorteil sein kann. Es gibt noch eine kurze Online-Dokumentation der [https://help.dyn.com/remote-access-api/perform-update/ Anfrage] und [https://help.dyn.com/remote-access-api/perform-update/ Antwortnachrichten].<br />
<br />
Das gesammte Protokoll sieht einen einzigen Nachrichtenaustausch aus Anfrage und Antwort vor. Die Anfrage kann mehrere Argumente enthalten; die Antwort kann verschiedene Code-Wörtern enthalten. Übrigens können in einer einzigen Anfrage mehrere DNS-Einträge gewünscht werden. In diesem Fall kann die Antwort mehrzeilig ausfallen.<br />
<br />
Das Verhalten von Server und Client bei künftigen Kommunikationsvorgängen wird unter Umständen von vorangegangenen Kommunikationsergebnissen beeinflußt: nach wiederholten fehlerhaften oder redundanten Anfragen kann der Server weitere Anfragen des Benutzers verweigern; nach wiederholten Fehlermeldungen sollte ein Client aufhören, immer dieselbe Anfrage zu schicken. Und für den Fall, daß mehrere Clients dynamische DNS-Einträge in derselben Domain example.com bestellen, muß der Server den Stand aller Client-Einträge intern speichern, damit er nicht mit einer neuen Zonefile einen früher erstellten Eintrag löscht. Zu diesen Fragen siehe den Abschnitt '''[[#Sukzessive_Kommunikationsabläufe]]''' nach der Beschreibung von Anfragen und Antworten unten.<br />
<br />
====Anfrage====<br />
<br />
Die Anfrage in Form eines URL übergibt dem DDNS-Programm in einem 'Query-String' einige Metavariablen. Das heißt, in einem URL der Form<br />
<br />
<nowiki>https://benutzername:passwort@ddns.beisiel.de/cgi-bin/ddns?hostname=einwahl.example.com&myip=87.65.43.21</nowiki><br />
<br />
signalisert das Fragezeichen, daß ein Query-String folgt. In einem solchen Query-String können in der Beispielimplementierung folgende Metavariablen definiert werden:<br />
<br />
{| class="wikitable"<br />
|- class="hintergrundfarbe5"<br />
! Variable !! Beispiel !! Bemerkungen<br />
|-<br />
| hostname || <tt>hostname=einwahl.example.com</tt><br /><div style="font-size:smaller;"><tt>hostname=eins.example.com,zwei.example.com[,...]</tt></div> ||<br />
Muß ein vollständig qualifizierter Domain-Name ("FQDN") sein; <tt>example.com</tt> muß eine vom Besitzer des DDNS-Programms verwaltete Domain sein. Genaugenommen kann der Wert eine durch Kommata gegliederte Liste mehrerer gültiger Domainnamen sein, falls mehrere Einträge mit derselben IP-Adresse gewünscht werden.<br />
|-<br />
| myip || <tt>myip=87.65.43.21</tt>||<br />
Kann entfallen; kann vom Server ignoriert werden. Maßgeblich ist dann die IP-Adresse des Absenders, wie sie vom Web-Server mitgeteilt wird.<br />
|-<br />
| mx || <tt>mx=87.65.43.21</tt><br /><tt>mx=NOCHG</tt><br /> ||<br />
Neben dem A-Eintrag möchte der Client auch einen MX-Eintrag. Der Wert <tt>NOCHG</tt> (für &bdquo;no change&ldquo;) bedeutet, der bestehende MX-Eintrag (oder seine Abwesenheit) soll nicht geändert werden. <br />
|-<br />
| backmx || <tt>backmx=YES</tt><br /><tt>backmx=NOCHG</tt><br /><tt>backmx=NO</tt> ||<br />
Falls <tt>YES</tt>, wird ein zweiter MX-Eintrag erzeugt, der <tt>einwahl.example.com</tt> als Mail-Server für <tt>einwahl.example.com</tt> nennt. Dieser Eintrag hat eine niedrigere Präferenzzahl (also eine höhere Priorität) als der mit <tt>mx</tt> angeforderten Eintrag.<br />
|-<br />
| wildcard || <tt>wildcard=ON</tt><br /><tt>wildcard=NOCHG</tt><br /><tt>wildcard=OFF</tt> ||<br />
Neben dem A-Eintrag für den Domainnamen <tt>einwahl.example.com</tt> wünscht der Client auch einen Eintrag für beliebige Subdomains, also <tt>*.einwahl.example.com</tt>, mit der gleichen IP-Adresse.<br />
|-<br />
| offline ||<tt>offline=YES</tt><br /><tt>offline=NOCHG</tt>||<br />
Falls <tt>YES</tt>, wird ein DNS-Eintrag für <tt>einwahl.example.com</tt> aus der Zonefile getilgt. Gegebenenfalls wird der Hostname dann auf Grund eines parallelen Wildcard-Eintrags für <tt>*.example.com</tt> einer anderen IP-Adresse zugeordnet werden.<br />
|}<br />
<br />
<!-- IPv6? --><br />
<br />
Alle Parameter bis auf hostname können entfallen. Bei nichtdokumentierten Argumenten ist das Verhalten undefiniert&trade;.<br />
<br />
====Antwort====<br />
<br />
Die Antwort auf eine erfolgreiche HTTP-Anfrage besteht im häufigsten Fall aus einigen Header-Zeilen, gefolgt vom Inhalt der gewünschten Text- oder andere Datei. Ein Status-Code in der ersten Header-Zeile gibt an, ob die Anfrage bedient werden kann oder kreist andernfalls den Grund für die Enttäuschung ein.<br />
<br />
Die vorliegende Beispielimplementierung von DDNS schickt einen der üblichen HTTP-Status-Codes "200 OK" oder "500 Internal Server Error", gefolgt von einer kurzen Textnachricht nach dem HTTP-Header. Bei diesem Programm ist &ndash; laut Gebrauchshinweise von DynDNS.org &ndash; ''nicht'' der Status-Code im Header, sondern der Inhalt der Nachricht die definierte, maßgebliche Ergebnismeldung des Programms.<br />
<br />
{| class="wikitable"<br />
|- class="hintergrundfarbe5"<br />
! Meldung !! Bedeutung !! Bemerkungen<br />
|-<br />
| <tt>good&nbsp;&lt;IP&nbsp;number&gt;</tt> ||<br />
Der gewünschte DNS-Eintrag wurde erfolgreich in einer Zonefile eingetragen. <br />
|| Es kann natürlich noch einige Minuten dauern, bis die Zonefile vom Hostsharing-Roboter abgelesen wird und der Inhalt in die BIND-Konfiguration übernommen.<br />
|-<br />
| <tt>good&nbsp;0.0.0.0</tt> ||<br />
Das Argument <tt>offline=YES</tt> wurde empfangen und verarbeitet.<br />
|| Der Domainname hat also keinen dynamischen DNS-Eintrag mehr.<br />
|-<br />
<!-- We don't do this!<br />
| <tt>good&nbsp;127.0.0.1</tt> ||<br />
Die Anfrage entsprach nicht den Erfordernissen des Servers.<br />
|| Trotz des Worts <tt>good</tt> war die Anfrage nicht erfolgreich, falls in der Rückmeldung die IP-Adresse mit <tt>127.0.0.1</tt> angegeben wird. Dieser verwirrende Fehlercode ist aus unerklärlichen Gründen in der Spezifikation von DynDNS.org so definiert.<br />
|-<br />
--><br />
| <tt>nochg&nbsp;&lt;IP&nbsp;number&gt;</tt> ||<br />
Der gewünschte DNS-Eintrag war bereits vorhanden. <br />
|| Der Server selbst macht keine DNS-Abfrage, um das zu vermitteln: die &bdquo;no change&ldquo;-Antwort besagt nur, daß eine Anfrage für diesen Eintrag bereits mit Erfolg quittiert wurde.<br />
|-<br />
| <tt>notfqdn</tt> ||<br />
Fehlschlag: der gewünschte Domainname ist nicht gültig, oder es wurde keiner angegeben.<br />
|| ...<br />
|-<br />
| <tt>nohost</tt> ||<br />
Fehlschlag: der gewünschte Domainname ist gehört nicht zu denen, die für diesen Benutzer des DDNS-Dienstes konfiguriert sind.<br />
|| Siehe den Abschnitt [[#Administration|Administration]] weiter unten.<br />
|-<br />
| <tt>badauth</tt> ||<br />
Fehlschlag: Die Kombination von Benutzernamen und Paßwort entsprach keinem DDNS-Account, oder das Account ist momentan gesperrt.<br />
|| Ein gesperrtes Account kann nur der Domain-Admin mittels des Administrationswerkzeugs wieder freigeben: siehe den Abschnit [[#Administration|Administration]] weiter unten.<br />
|-<br />
| <tt>abuse</tt> ||<br />
Fehlschlag: der gewünschte Domainname ist wegen vorangeganger Fehlschläge oder überflüssiger Aufrufe gesperrt.<br />
|| Siehe den Abschnitt [[#Sukzessive_Kommunikationsabläufe|Sukzessive Kommunikationsabläufe]] unten.<br />
|-<br />
| <tt>911</tt> ||<br />
Fehlschlag: Das Server-Programm hat einen internen Fehler festgestellt.<br />
|| Das Problem liegt nicht in der Anfrage an sich.<br />
|}<br />
<br />
Man kann sich durchaus eine sinnreichere Kommunikation zwischen Client und Server vorstellen, doch das hier beschriebene Protokoll ist eben von DynDNS.org verwendet worden und wird in gängigen Routern implementiert, also wird es in der vorliegenden DDNS-Implementierung nachgebildet.<br />
<br />
=== Sukzessive Kommunikationsabläufe ===<br />
Der Server muß sich zwischen einzelnen Aufrufen einiges merken, um Ressourcen zu schonen und um zu verhindern, daß einmal vergebene DDNS-Einträge von neuen Anfragen, die dieselbe übergeordnete Domain betreffen, durch Überschreiben verlorengehen.<br />
<br />
==== Mißbrauch und Benutzersperrung ====<br />
Zur Schonung von Ressourcen muß sich die Implementierung weigern, sich mit zuvielen fehlerhaften oder auch nur überflüssigen Anfragen zu beschäftigen. Dazu führt der Server eine Strichliste über solche Anfragen jedes Clients und sperrt nach einer bestimmten Anzahl solcher Anfragen den Benutzernamen oder einzelne Domainnamen gegen die weitere Nutzung des Dienstes.<br />
<br />
Mißbrauchspunkte gegen einen einzelnen Domainnamen gibt es für:<br />
* eine Anfrage, die keinen neuen DNS-Eintrag (und keine Änderung oder Löschung eines Eintrags) erfordert, sondern bestehende Merkmale nur wiederholt<br />
<br />
Mißbrauchspunkte gegen einen Benutzernamen gibt es für:<br />
* die Angabe eines Domainnamens, der in der Dienstkonfiguration dem anfragenden Benutzernamen nicht zugeordnet ist<br />
* die Angabe eines Domainnamen in einer Domain, die nicht demselben Hostsharing-Domain-Admin gehört, der den DDNS-Dienst anbietet<br />
* die Angabe eines Domainnamens, der in der Dienstkonfiguration bereits wegen mißbräuchlicher Anfragen gesperrt ist (siehe oben)<br />
<br />
Um eine Sperrung aufzuheben, wird in der Regel eine Handlung durch den Administrator erforderlich sein.<br />
<br />
==== Mehrere dynamische Subdomains in derselben Domain ====<br />
Sobald zwei verschiedene DDNS-Einträge in derselben Domain verlangt werden &ndash; beispielsweise home.example.com und office.example.com &ndash; wird es notwendig, bei jeder neuen Zonefile für example.com eventuell frühere Einträge zu konservieren. Der Rechner zu Hause weiß beim Bestellen seines DDNS-Eintrags nichts vom Rechner im Büro und umgekehrt. Der Server muß in irgendeiner Form über bereits vergebene Einträge Buch führen und bei einer neuen Anfrage, die example.com betrifft, alle bereits aktiven DDNS-Einträge für example.com mit in die neue Zonefile aufnehmen &ndash auch wenn sie auf Anfragen verschiedener Benutzer zurückgehen.<br />
<br />
==== Datenbank ====<br />
In der Beispielimplementierung werden diese Informationen in einer SQLite-Datenbank gespeichert.<br />
<br />
== Sicherheit ==<br />
=== Rechte ===<br />
Die '''Benutzerrechte''' werden durch das Hostsharing-System kontrolliert. Sowohl das CGI-Programm als auch das [[#Administration|Administrationswerkzeug]] werden mit den Rechten des Domain-Admins (xyz00-benutzername in unserem Beispiel) ausgeführt, also kann dieses Programm nur die Domains bearbeiten, die von xyz00-benutzername verwaltet werden.<br />
<br />
=== Authentifizierung ===<br />
In der Beispielimplementierung (wie auch seinerzeit bei DynDNS.org) wird das CGI-Programm durch einen .htaccess-Eintrag geschützt, der HTTP-Basic-Authentication vorschreibt. Also wird das Programm eigentlich mit einem URL der form<br />
<br />
<nowiki>https://ddnsaccount:passwort@ddns.example.com/cgi-bin/ddns?hostname=...</nowiki><br />
<br />
aufgerufen.<br />
<br />
=== Verschlüsselung ===<br />
Das CGI-Programm sollte nur in example.com/cgi-ssl/ installiert werden, nicht in example.com/cgi/. Damit ist die Kommunikation zwischen Client und Server durch SSL verschlüsselt.<br />
<br />
== Administration ==<br />
<br />
Der Verwalter des DDNS-Programms trägt berechtigte Benutzer und die ihnen zugeteilten Domainnamen in die Datenbank des Programms ein mit Hilfe eines kleinen Hilfsprogramms. Das ist im vorliegenden Fall ein menügesteuertes Programm für die Befehlszeile, daß die naheliegenden Funktionen anbietet: Account hinzufügen, löschen, sperren, entsperren, Paßwort setzen, ändern; Domainnamen hinzufügen, ändern, entsperren, löschen; Accounts und Domainnamen mit aktuellem Status auflisten. Die Funktionen sind auch über Befehlszeilenargumente verfügbar, also skriptfähig.<br />
<br />
Eine Übersicht der Funktionen des Administrationswerkzeugs gibt dieses selbst aus:<br />
<br />
<pre><br />
xyz00-benutzername@h02:~$ bin/ddnsadmin -h<br />
ddnsadmin.pl: Verwaltungswerkzeug für ddns<br />
<br />
Verwendung:<br />
ddnsadmin -A{[ahlusf]} [<Account>] [-f <DB-Datei>]<br />
ddnsadmin -D{[ahlsf]} [<Domain>] -A <Account> [-f <DB-Datei>]<br />
ddnsadmin -E <Einstellung> <Wert> [-f <DB-Datei>]<br />
ddnsadmin [-f <DB-Datei>] [-n]<br />
<br />
Wenn keine Option oder nur -f <DB-Datei> angegeben wird, bietet<br />
ddnsadmin.pl eine interaktive Menüoberfläche.<br />
<br />
Optionen:<br />
-f <DB-Datei> Angegebene Datenbankdatei verwenden<br />
-n Neue, leere Datenbank erzeugen<br />
-Aa [<Account>] Account(s) auflisten<br />
-Ah <Account> <Paßwort> Account hinzufügen<br />
-A{lsf} <Account> Account löschen, sperren, freigeben<br />
-Au <Account> <Name> Account umbenennen<br />
-A <Account> -Da [<Domain>] Domain(s) auflisten<br />
-A <Account> -D{hlsf} <Domain> Domain hinzufügen,<br />
löschen, sperren, freigeben<br />
-E <Einstellung> <Wert> Einstellung ändern<br />
-h Diese Übersicht ausgeben<br />
<br />
Einstellungen: <br />
maxacctabuse Anzahl der mißbräuchlichen Aufrufe,<br />
bevor ein Account gesperrt wird<br />
maxhostabuse Anzahl der mißbräuchlichen Aufrufe,<br />
bevor ein Domainname gesperrt wird<br />
safeinterval Mindestabstand zwischen redundanten Aufrufen<br />
(in Sekunden)<br />
cgihost Server, der das DDNS-Skript bereithält<br />
<br />
xyz00-benutzername@h02:~$ <br />
</pre><br />
<br />
Eine Auflistung des momentanen Inhalts der DDNS-Datenbank durch das Administrationswerkzeug könnte beispielsweise so aussehen:<br />
<br />
<pre><br />
xyz00-benutzername@h02:~$ bin/ddnsadmin.pl -Aa<br />
1. papst Mißbrauch: 0; gesperrt: nein<br />
avignon.example.com<br />
zuletzt aktiv am Sun Apr 26 22:24:49 2020<br />
mit IP-Nr. 87.65.43.21; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 0; gesperrt: nein<br />
vatican.beispiel.de<br />
zuletzt aktiv am Sun Apr 26 22:24:49 2020<br />
mit IP-Nr. 87.65.43.21; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 0; gesperrt: nein<br />
2. kaiser Mißbrauch: 4; gesperrt: ja<br />
augsburg.beispiel.de<br />
zuletzt aktiv am Fri Apr 24 16:13:49 2020<br />
mit IP-Nr. 64.82.31.75; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 0; gesperrt: ja<br />
3. luther Mißbrauch: 1; gesperrt: nein<br />
wittenberg.example.com<br />
zuletzt aktiv am Mon Apr 27 10:12:49 2020<br />
mit IP-Nr. 78.56.34.12; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 1; gesperrt: nein<br />
xyz00-benutzername@h02:~$<br />
</pre><br />
<br />
Das DDNS-Account &bdquo;kaiser&ldquo; in dieser Auflistung ist wohl auf Grund fehlerhafter Anfragen automatisch gesperrt worden. Der Inhaber wird sich wohl bald melden, um nach Korrektur seiner Client-Konfiguration die Aufhebung der Sperre zu wünschen.<br />
<br />
=== Log ===<br />
Alle Anfragen werden in einer täglich wechselnden Log-Datei protokolliert, entweder schlicht oder ausführlich, je nachdem, ob eine Variable <tt>verbose</tt> wahr ist.<br />
Ein ausführlicher Log-Eintrag sieht so aus:<br />
<br />
Sun Apr 26 20:21:45 2020 ddns aufgerufen von papst<br />
unter 84.185.97.8<br />
URL: <nowiki>https://ddns.example.com/cgi-bin/ddns.cgi?hostname=<br />
avignon.example.com,vatican.beispiel.de&<br />
myip=84.185.97.8</nowiki><br />
Verwende IP 84.185.97.8 (= 1421435144)<br />
DB-Version: 1<br />
Skript und DB exklusiv geöffnet<br />
avignon.example.com: IP: 84.185.97.8; MX: 0; Backup-MX: nein;<br />
Wildcard: nein; Mißbrauch: 0; gesperrt: nein <br />
vatican.beispiel.de: IP: 84.185.97.8; MX: 0; Backup-MX: nein;<br />
Wildcard: nein; Mißbrauch: 0; gesperrt: nein <br />
Betroffene Zonen: example.com, beispiel.de<br />
Temporärdatei example.com_hxNa.new geschrieben<br />
Zonendatei /home/pacs/xyz00/users/benutzername/doms/example.com/<br />
etc/pri.example.com eingestellt<br />
Temporärdatei beispiel.de_6HcO.new geschrieben<br />
Zonendatei /home/pacs/xyz00/users/benutzername/doms/beispiel.de/<br />
etc/pri.beispiel.de eingestellt<br />
Abgeschlossen: Fertig<br />
<br />
Wenn <tt>verbose</tt> auf falsch gesetzt ist, sind die Log-Einträge einzeilig.</div>Apc00-tonyhttps://wiki.hostsharing.net/index.php?title=Benutzer:Apc00-tony/Dynamisches_DNS&diff=6228Benutzer:Apc00-tony/Dynamisches DNS2023-09-11T14:35:40Z<p>Apc00-tony: </p>
<hr />
<div>Update 2023: Ich habe die Verwaltung über Befehlszeile durch eine PHP-Web-Oberfläche ersetzt; Details irgendwo ... ah, [https://ddns.crawfords.de/verwaltung/ddnsadminhints?name=host_domain_tld hier]. Meine Hostsharing-DDNS-Lösung läuft übrigens schon lange einwandfrei; ich benutze sie dazu, ein VPN zwischen meinen Fritz!Box-LANS zu Hause und im Büro zu realisieren sowie um auf ein Backup- und Music-Server (ein Raspberry Pi) zu Hause von unterwegs zuzugreifen.<br />
<br />
((Provisorischer Vorspann: Auf Grund einer Mailing-Listen-Diskussion habe ich angefangen, Dynamisches DNS über einen CGI-Skript bei Hostsharing zu realisieren. Meine Lösung habe ich dann vorgestellt; sie wurde für nicht ausreichend selbsterklärend befunden und fand wenig Akzeptanz. Hier also der Versuch, die Sache zu dokumentieren.))<br />
<br />
Mit der regelmäßigen Aufnahme von benutzerspezifischen Zonefiles in seiner DNS-Konfiguration bietet Hostsharing alles, was man braucht, um &bdquo;dynamisches DNS&ldquo; in Eigenregie zu realisieren.<br />
<br />
Das heißt, wenn ich mindestens eine Domain bei Hostsharing verwalte, und mindestens eine Einwahlverbindung (oder DSL-Verbindung) ins Internet mit wechselnder IP-Adresse über irgendeinen ISP für meinen Arbeitsplatzrechner zu Hause betreibe, dann kann ich dem Arbeitsplatzrechner über die DNS-Server von Hostsharing einen vollqualifizieren Domainnamen zuweisen, der der jeweiligen IP-Adresse meiner Einwahlleitung zugeordnet ist.<br />
<br />
<pre><br />
<br />
(ASCII-Art-Diagramm der beschriebenen Konstellation)<br />
<br />
</pre><br />
<br />
Im Folgenden wird eine real existierende Implementierung von Dynamischem DNS (&bdquo;DDNS&ldquo;) beschrieben. Die verschiedenen Elemente könnten durchaus anders realisiert werden; die beschriebene Implementierung könnte durchaus verbessert werden. Sie dient hier der Illustration.<br />
<br />
In der folgenden Beschreibung werden diese Beispielwerte benutzt:<br />
* Ein Hostsharing-Mitglied hat ein Account als Paket-Admin mit Kennung xyz00.<br />
* Im Paket xyz00 gibt es einen Domain-Admin namens xyz00-benutzername.<br />
* Dieser Domain-Admin verwaltet bei Hostsharing die Domains example.com und beispiel.de.<br />
* Ein Benutzer hat zu Hause (oder im Büro) einen Arbeitsplatzrechner hinter der marktüblichen DSL-Leitung, die von seinem ISP bereitgestellt wird.<br />
* Dieser Arbeitsplatzrechner (oder der Router, der seine Internetverbindung steuert) bekommt vom ISP immer wechselnde IP-Adressen zugewiesen.<br />
* Dennoch möchte der Benutzer seinen Arbeitsplatzrechner aus dem Internet unter dem Hostnamen einwahl.example.com ansprechen können.<br />
<br />
Dazu kann ein System wie Hostsharing, das authoritative DNS-Informationen für viele Domains bereitstellt, auch veränderliche DNS-Information über dynamisch verbundene Rechner verwalten &ndash; sofern das ressourcenschonend gemacht werden kann ohne andere Funktionen zu stören.<br />
<br />
== Aufgaben des Servers ==<br />
<br />
Um einem Rechner mit wechselnder IP-Adresse einen DDNS-Eintrag zu bieten, muß der Hostsharing-Server folgendes leisten (in ungefährer Reihenfolge der Ereignisse):<br />
<br />
# Eine Anfrage entgegennehmen, beispielsweise über HTTPS, von einem entfernten Rechner, der einen DNS-Eintrag für seine momentane IP-Adresse wünscht. <br />
# Prüfen, ob die Anfrage einen berechtigten DDNS-Dienst-Usernamen mit zugehörigem Paßwort enthält.<br />
# Prüfen, ob die Anfrage einen gültigen Domainnamen betrifft, den der Server bieten darf.<br />
# Prüfen, ob die Domain example.com demselben Benutzer gehört, unter dessen Namen der Dynamisches-DNS-Server läuft.<br />
# Eine gültige [[Zonefile]] mit &ndash; neben dem bisherigen Inhalt &ndash; einem A-Eintrag für einwahl.example.com in /home/pacs/xyz00/users/benutzername/doms/example.com/pri.example.com schreiben.<br />
# Dem Client eine Bestätigung oder ggf. eine Fehlermeldung als Antwort senden.<br />
# In irgendeiner Datenbank den momentan eingestellter Status all seiner DDNS-Einträge speichern.<br />
# In einer Logdatei protokollieren, daß obiges getan wurde, oder ggf. welche Fehler traten auf.<br />
<br />
== Aufgaben des Clients ==<br />
Bevor ich anfange, meinen Arbeitsplatzrechner so zu konfigurieren, daß er bei welchem Server auch immer einen DDNS-Eintrag anfordert, muß ich mich als verantwortlicher Benutzer dieses Rechners und der dazugehörigen Internetverbindung &ndash; das heißt, als Mensch &ndash; mit dem Betreiber des dynamisches-DNS-Servers vereinbaren, daß ich das darf und welchen Eintrag ich bekommen kann. Im Folgenden wird vorausgesetzt, daß solche Vereinbarungen getroffen und die Parameter geklärt wurden.<br />
<br />
Der DDNS-Client muß aus Server-Sicht nur wenig leisten:<br />
<br />
# Eine Anfrage senden, beispielsweise über HTTPS, an einen entfernten Rechner, der einen Eintrag ins DNS für die momentane IP-Adresse des Clients vornehmen kann.<br />Diese Anfrage muß einem festgelegten Format entsprechen und muß gültige Werte für die Authorisation des Clients, den gewünschten Domainnamen, und eventuell andere Parameter enthalten.<br />
# Eine Antwort des Servers entgegennehmen und als Erfolgs- oder Fehlermeldung auswerten.<br />
# Von überflüssigen Anfragen absehen: das heißt bei Erfolg, nicht wiederholt den gleichen Eintrag erneut wünschen; bei Fehlern, nicht die gleiche fehlerhafte Anfrage erneut schicken.<br />
<br />
== Kommunikation zwischen Client und Server ==<br />
<br />
Ein einziges Nachrichtenpaar von Anfrage und Antwort genügt, um einen DDNS-Eintrag einzurichten: Der Client teilt die IP-Adresse und den Domainnamen mit, die in einem DNS-Eintrag verbunden werden sollen; der Server bestätigt den Auftrag.<br />
<br />
In der Beispielimplementierung erfolgt die Kommunikation über HTTP, und die Anfrage des Clients könnte so aussehen:<br />
<br />
GET /cgi-bin/ddns?hostname=einwahl.example.com&myip=87.65.43.21 HTTP/1.1<br />
Host: ddns.beispiel.de<br />
User-Agent: Fritz!Box DDNS/1.0.1<br />
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==<br />
<br />
Bei Erhalt dieser Anfrage ruft Apache das CGI-Programm .../doms/ddns.beispiel.de/cgi-ssl/ddns auf. Das Fragezeichen trennt den Programmnamen von einem "Query-String", in dem zwei Metavariablen definiert und übergeben werden. Die erste Metavariable, hostname, hat den Wert "einwahl.example.com"; die zweite, myip, hat den Wert "87.65.43.21".<br />
<br />
Das Server-Programm, hier ''ddns'', prüft diese Informationen auf Form und Berechtigung, und schreibt gegebenenfalls einen entsprechenden Eintrag in einer Zonefile. Es schreibt auch verschiedene Informationen in die Standardausgabe. Wenn es die Standardausgabe geschlossen wird &ndash; also spätestens bei Programmende &ndash; schickt Apache diese Informationen als Antwort an den anfragenden Rechner zurück.<br />
<br />
Im Falle unserer Beispielimplementierung sieht die Antwort bei Erfolg so aus: <br />
<br />
HTTP/1.1 200 OK<br />
Date: Wed, 22 Apr 2020 08:35:15 GMT<br />
Server: Apache<br />
Content-Length: 17<br />
Content-Type: text/plain; charset=ISO-8859-1<br />
<br />
good 87.65.43.21<br />
<br />
=== Das DDNS-Protokoll von DynDNS.org ===<br />
<br />
In den 90er Jahren, bevor das Internet so durchgehend vergeschäftlicht wurde, boten einige Organisationen kostenlose DDNS-Dienste an. Ein sehr beliebtes Angebot war das von DynDNS.org. Das DDNS-Protokoll von diesem Dienst wurde sogar in Einwahl-Routern einprogrammiert und der Dienst wurde von ISPs und Router-Herstellern als Leistungsmerkmal beworben.<br />
<br />
DynDNS.org gehört inzwischen Oracle und bietet keine kostenlose Dienste mehr. Dennoch wird das DDNS-Protokoll von DynDNS.org in der vorliegenden Beispielimplementierung übernommen in der Hoffnung, daß die Kompatibilität mit einigen gängigen Einwahl-Routern von Vorteil sein kann. Es gibt noch eine kurze Online-Dokumentation der [https://help.dyn.com/remote-access-api/perform-update/ Anfrage] und [https://help.dyn.com/remote-access-api/perform-update/ Antwortnachrichten].<br />
<br />
Das gesammte Protokoll sieht einen einzigen Nachrichtenaustausch aus Anfrage und Antwort vor. Die Anfrage kann mehrere Argumente enthalten; die Antwort kann verschiedene Code-Wörtern enthalten. Übrigens können in einer einzigen Anfrage mehrere DNS-Einträge gewünscht werden. In diesem Fall kann die Antwort mehrzeilig ausfallen.<br />
<br />
Das Verhalten von Server und Client bei künftigen Kommunikationsvorgängen wird unter Umständen von vorangegangenen Kommunikationsergebnissen beeinflußt: nach wiederholten fehlerhaften oder redundanten Anfragen kann der Server weitere Anfragen des Benutzers verweigern; nach wiederholten Fehlermeldungen sollte ein Client aufhören, immer dieselbe Anfrage zu schicken. Und für den Fall, daß mehrere Clients dynamische DNS-Einträge in derselben Domain example.com bestellen, muß der Server den Stand aller Client-Einträge intern speichern, damit er nicht mit einer neuen Zonefile einen früher erstellten Eintrag löscht. Zu diesen Fragen siehe den Abschnitt '''[[#Sukzessive_Kommunikationsabläufe]]''' nach der Beschreibung von Anfragen und Antworten unten.<br />
<br />
====Anfrage====<br />
<br />
Die Anfrage in Form eines URL übergibt dem DDNS-Programm in einem 'Query-String' einige Metavariablen. Das heißt, in einem URL der Form<br />
<br />
<nowiki>https://benutzername:passwort@ddns.beisiel.de/cgi-bin/ddns?hostname=einwahl.example.com&myip=87.65.43.21</nowiki><br />
<br />
signalisert das Fragezeichen, daß ein Query-String folgt. In einem solchen Query-String können in der Beispielimplementierung folgende Metavariablen definiert werden:<br />
<br />
{| class="wikitable"<br />
|- class="hintergrundfarbe5"<br />
! Variable !! Beispiel !! Bemerkungen<br />
|-<br />
| hostname || <tt>hostname=einwahl.example.com</tt><br /><div style="font-size:smaller;"><tt>hostname=eins.example.com,zwei.example.com[,...]</tt></div> ||<br />
Muß ein vollständig qualifizierter Domain-Name ("FQDN") sein; <tt>example.com</tt> muß eine vom Besitzer des DDNS-Programms verwaltete Domain sein. Genaugenommen kann der Wert eine durch Kommata gegliederte Liste mehrerer gültiger Domainnamen sein, falls mehrere Einträge mit derselben IP-Adresse gewünscht werden.<br />
|-<br />
| myip || <tt>myip=87.65.43.21</tt>||<br />
Kann entfallen; kann vom Server ignoriert werden. Maßgeblich ist dann die IP-Adresse des Absenders, wie sie vom Web-Server mitgeteilt wird.<br />
|-<br />
| mx || <tt>mx=87.65.43.21</tt><br /><tt>mx=NOCHG</tt><br /> ||<br />
Neben dem A-Eintrag möchte der Client auch einen MX-Eintrag. Der Wert <tt>NOCHG</tt> (für &bdquo;no change&ldquo;) bedeutet, der bestehende MX-Eintrag (oder seine Abwesenheit) soll nicht geändert werden. <br />
|-<br />
| backmx || <tt>backmx=YES</tt><br /><tt>backmx=NOCHG</tt><br /><tt>backmx=NO</tt> ||<br />
Falls <tt>YES</tt>, wird ein zweiter MX-Eintrag erzeugt, der <tt>einwahl.example.com</tt> als Mail-Server für <tt>einwahl.example.com</tt> nennt. Dieser Eintrag hat eine niedrigere Präferenzzahl (also eine höhere Priorität) als der mit <tt>mx</tt> angeforderten Eintrag.<br />
|-<br />
| wildcard || <tt>wildcard=ON</tt><br /><tt>wildcard=NOCHG</tt><br /><tt>wildcard=OFF</tt> ||<br />
Neben dem A-Eintrag für den Domainnamen <tt>einwahl.example.com</tt> wünscht der Client auch einen Eintrag für beliebige Subdomains, also <tt>*.einwahl.example.com</tt>, mit der gleichen IP-Adresse.<br />
|-<br />
| offline ||<tt>offline=YES</tt><br /><tt>offline=NOCHG</tt>||<br />
Falls <tt>YES</tt>, wird ein DNS-Eintrag für <tt>einwahl.example.com</tt> aus der Zonefile getilgt. Gegebenenfalls wird der Hostname dann auf Grund eines parallelen Wildcard-Eintrags für <tt>*.example.com</tt> einer anderen IP-Adresse zugeordnet werden.<br />
|}<br />
<br />
<!-- IPv6? --><br />
<br />
Alle Parameter bis auf hostname können entfallen. Bei nichtdokumentierten Argumenten ist das Verhalten undefiniert&trade;.<br />
<br />
====Antwort====<br />
<br />
Die Antwort auf eine erfolgreiche HTTP-Anfrage besteht im häufigsten Fall aus einigen Header-Zeilen, gefolgt vom Inhalt der gewünschten Text- oder andere Datei. Ein Status-Code in der ersten Header-Zeile gibt an, ob die Anfrage bedient werden kann oder kreist andernfalls den Grund für die Enttäuschung ein.<br />
<br />
Die vorliegende Beispielimplementierung von DDNS schickt einen der üblichen HTTP-Status-Codes "200 OK" oder "500 Internal Server Error", gefolgt von einer kurzen Textnachricht nach dem HTTP-Header. Bei diesem Programm ist &ndash; laut Gebrauchshinweise von DynDNS.org &ndash; ''nicht'' der Status-Code im Header, sondern der Inhalt der Nachricht die definierte, maßgebliche Ergebnismeldung des Programms.<br />
<br />
{| class="wikitable"<br />
|- class="hintergrundfarbe5"<br />
! Meldung !! Bedeutung !! Bemerkungen<br />
|-<br />
| <tt>good&nbsp;&lt;IP&nbsp;number&gt;</tt> ||<br />
Der gewünschte DNS-Eintrag wurde erfolgreich in einer Zonefile eingetragen. <br />
|| Es kann natürlich noch einige Minuten dauern, bis die Zonefile vom Hostsharing-Roboter abgelesen wird und der Inhalt in die BIND-Konfiguration übernommen.<br />
|-<br />
| <tt>good&nbsp;0.0.0.0</tt> ||<br />
Das Argument <tt>offline=YES</tt> wurde empfangen und verarbeitet.<br />
|| Der Domainname hat also keinen dynamischen DNS-Eintrag mehr.<br />
|-<br />
<!-- We don't do this!<br />
| <tt>good&nbsp;127.0.0.1</tt> ||<br />
Die Anfrage entsprach nicht den Erfordernissen des Servers.<br />
|| Trotz des Worts <tt>good</tt> war die Anfrage nicht erfolgreich, falls in der Rückmeldung die IP-Adresse mit <tt>127.0.0.1</tt> angegeben wird. Dieser verwirrende Fehlercode ist aus unerklärlichen Gründen in der Spezifikation von DynDNS.org so definiert.<br />
|-<br />
--><br />
| <tt>nochg&nbsp;&lt;IP&nbsp;number&gt;</tt> ||<br />
Der gewünschte DNS-Eintrag war bereits vorhanden. <br />
|| Der Server selbst macht keine DNS-Abfrage, um das zu vermitteln: die &bdquo;no change&ldquo;-Antwort besagt nur, daß eine Anfrage für diesen Eintrag bereits mit Erfolg quittiert wurde.<br />
|-<br />
| <tt>notfqdn</tt> ||<br />
Fehlschlag: der gewünschte Domainname ist nicht gültig, oder es wurde keiner angegeben.<br />
|| ...<br />
|-<br />
| <tt>nohost</tt> ||<br />
Fehlschlag: der gewünschte Domainname ist gehört nicht zu denen, die für diesen Benutzer des DDNS-Dienstes konfiguriert sind.<br />
|| Siehe den Abschnitt [[#Administration|Administration]] weiter unten.<br />
|-<br />
| <tt>badauth</tt> ||<br />
Fehlschlag: Die Kombination von Benutzernamen und Paßwort entsprach keinem DDNS-Account, oder das Account ist momentan gesperrt.<br />
|| Ein gesperrtes Account kann nur der Domain-Admin mittels des Administrationswerkzeugs wieder freigeben: siehe den Abschnit [[#Administration|Administration]] weiter unten.<br />
|-<br />
| <tt>abuse</tt> ||<br />
Fehlschlag: der gewünschte Domainname ist wegen vorangeganger Fehlschläge oder überflüssiger Aufrufe gesperrt.<br />
|| Siehe den Abschnitt [[#Sukzessive_Kommunikationsabläufe|Sukzessive Kommunikationsabläufe]] unten.<br />
|-<br />
| <tt>911</tt> ||<br />
Fehlschlag: Das Server-Programm hat einen internen Fehler festgestellt.<br />
|| Das Problem liegt nicht in der Anfrage an sich.<br />
|}<br />
<br />
Man kann sich durchaus eine sinnreichere Kommunikation zwischen Client und Server vorstellen, doch das hier beschriebene Protokoll ist eben von DynDNS.org verwendet worden und wird in gängigen Routern implementiert, also wird es in der vorliegenden DDNS-Implementierung nachgebildet.<br />
<br />
=== Sukzessive Kommunikationsabläufe ===<br />
Der Server muß sich zwischen einzelnen Aufrufen einiges merken, um Ressourcen zu schonen und um zu verhindern, daß einmal vergebene DDNS-Einträge von neuen Anfragen, die dieselbe übergeordnete Domain betreffen, durch Überschreiben verlorengehen.<br />
<br />
==== Mißbrauch und Benutzersperrung ====<br />
Zur Schonung von Ressourcen muß sich die Implementierung weigern, sich mit zuvielen fehlerhaften oder auch nur überflüssigen Anfragen zu beschäftigen. Dazu führt der Server eine Strichliste über solche Anfragen jedes Clients und sperrt nach einer bestimmten Anzahl solcher Anfragen den Benutzernamen oder einzelne Domainnamen gegen die weitere Nutzung des Dienstes.<br />
<br />
Mißbrauchspunkte gegen einen einzelnen Domainnamen gibt es für:<br />
* eine Anfrage, die keinen neuen DNS-Eintrag (und keine Änderung oder Löschung eines Eintrags) erfordert, sondern bestehende Merkmale nur wiederholt<br />
<br />
Mißbrauchspunkte gegen einen Benutzernamen gibt es für:<br />
* die Angabe eines Domainnamens, der in der Dienstkonfiguration dem anfragenden Benutzernamen nicht zugeordnet ist<br />
* die Angabe eines Domainnamen in einer Domain, die nicht demselben Hostsharing-Domain-Admin gehört, der den DDNS-Dienst anbietet<br />
* die Angabe eines Domainnamens, der in der Dienstkonfiguration bereits wegen mißbräuchlicher Anfragen gesperrt ist (siehe oben)<br />
<br />
Um eine Sperrung aufzuheben, wird in der Regel eine Handlung durch den Administrator erforderlich sein.<br />
<br />
==== Mehrere dynamische Subdomains in derselben Domain ====<br />
Sobald zwei verschiedene DDNS-Einträge in derselben Domain verlangt werden &ndash; beispielsweise home.example.com und office.example.com &ndash; wird es notwendig, bei jeder neuen Zonefile für example.com eventuell frühere Einträge zu konservieren. Der Rechner zu Hause weiß beim Bestellen seines DDNS-Eintrags nichts vom Rechner im Büro und umgekehrt. Der Server muß in irgendeiner Form über bereits vergebene Einträge Buch führen und bei einer neuen Anfrage, die example.com betrifft, alle bereits aktiven DDNS-Einträge für example.com mit in die neue Zonefile aufnehmen &ndash auch wenn sie auf Anfragen verschiedener Benutzer zurückgehen.<br />
<br />
==== Datenbank ====<br />
In der Beispielimplementierung werden diese Informationen in einer SQLite-Datenbank gespeichert.<br />
<br />
== Sicherheit ==<br />
=== Rechte ===<br />
Die '''Benutzerrechte''' werden durch das Hostsharing-System kontrolliert. Sowohl das CGI-Programm als auch das [[#Administration|Administrationswerkzeug]] werden mit den Rechten des Domain-Admins (xyz00-benutzername in unserem Beispiel) ausgeführt, also kann dieses Programm nur die Domains bearbeiten, die von xyz00-benutzername verwaltet werden.<br />
<br />
=== Authentifizierung ===<br />
In der Beispielimplementierung (wie auch seinerzeit bei DynDNS.org) wird das CGI-Programm durch einen .htaccess-Eintrag geschützt, der HTTP-Basic-Authentication vorschreibt. Also wird das Programm eigentlich mit einem URL der form<br />
<br />
<nowiki>https://ddnsaccount:passwort@ddns.example.com/cgi-bin/ddns?hostname=...</nowiki><br />
<br />
aufgerufen.<br />
<br />
=== Verschlüsselung ===<br />
Das CGI-Programm sollte nur in example.com/cgi-ssl/ installiert werden, nicht in example.com/cgi/. Damit ist die Kommunikation zwischen Client und Server durch SSL verschlüsselt.<br />
<br />
== Administration ==<br />
<br />
Der Verwalter des DDNS-Programms trägt berechtigte Benutzer und die ihnen zugeteilten Domainnamen in die Datenbank des Programms ein mit Hilfe eines kleinen Hilfsprogramms. Das ist im vorliegenden Fall ein menügesteuertes Programm für die Befehlszeile, daß die naheliegenden Funktionen anbietet: Account hinzufügen, löschen, sperren, entsperren, Paßwort setzen, ändern; Domainnamen hinzufügen, ändern, entsperren, löschen; Accounts und Domainnamen mit aktuellem Status auflisten. Die Funktionen sind auch über Befehlszeilenargumente verfügbar, also skriptfähig.<br />
<br />
Eine Übersicht der Funktionen des Administrationswerkzeugs gibt dieses selbst aus:<br />
<br />
<pre><br />
xyz00-benutzername@h02:~$ bin/ddnsadmin -h<br />
ddnsadmin.pl: Verwaltungswerkzeug für ddns<br />
<br />
Verwendung:<br />
ddnsadmin -A{[ahlusf]} [<Account>] [-f <DB-Datei>]<br />
ddnsadmin -D{[ahlsf]} [<Domain>] -A <Account> [-f <DB-Datei>]<br />
ddnsadmin -E <Einstellung> <Wert> [-f <DB-Datei>]<br />
ddnsadmin [-f <DB-Datei>] [-n]<br />
<br />
Wenn keine Option oder nur -f <DB-Datei> angegeben wird, bietet<br />
ddnsadmin.pl eine interaktive Menüoberfläche.<br />
<br />
Optionen:<br />
-f <DB-Datei> Angegebene Datenbankdatei verwenden<br />
-n Neue, leere Datenbank erzeugen<br />
-Aa [<Account>] Account(s) auflisten<br />
-Ah <Account> <Paßwort> Account hinzufügen<br />
-A{lsf} <Account> Account löschen, sperren, freigeben<br />
-Au <Account> <Name> Account umbenennen<br />
-A <Account> -Da [<Domain>] Domain(s) auflisten<br />
-A <Account> -D{hlsf} <Domain> Domain hinzufügen,<br />
löschen, sperren, freigeben<br />
-E <Einstellung> <Wert> Einstellung ändern<br />
-h Diese Übersicht ausgeben<br />
<br />
Einstellungen: <br />
maxacctabuse Anzahl der mißbräuchlichen Aufrufe,<br />
bevor ein Account gesperrt wird<br />
maxhostabuse Anzahl der mißbräuchlichen Aufrufe,<br />
bevor ein Domainname gesperrt wird<br />
safeinterval Mindestabstand zwischen redundanten Aufrufen<br />
(in Sekunden)<br />
cgihost Server, der das DDNS-Skript bereithält<br />
<br />
xyz00-benutzername@h02:~$ <br />
</pre><br />
<br />
Eine Auflistung des momentanen Inhalts der DDNS-Datenbank durch das Administrationswerkzeug könnte beispielsweise so aussehen:<br />
<br />
<pre><br />
xyz00-benutzername@h02:~$ bin/ddnsadmin.pl -Aa<br />
1. papst Mißbrauch: 0; gesperrt: nein<br />
avignon.example.com<br />
zuletzt aktiv am Sun Apr 26 22:24:49 2020<br />
mit IP-Nr. 87.65.43.21; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 0; gesperrt: nein<br />
vatican.beispiel.de<br />
zuletzt aktiv am Sun Apr 26 22:24:49 2020<br />
mit IP-Nr. 87.65.43.21; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 0; gesperrt: nein<br />
2. kaiser Mißbrauch: 4; gesperrt: ja<br />
augsburg.beispiel.de<br />
zuletzt aktiv am Fri Apr 24 16:13:49 2020<br />
mit IP-Nr. 64.82.31.75; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 0; gesperrt: ja<br />
3. luther Mißbrauch: 1; gesperrt: nein<br />
wittenberg.example.com<br />
zuletzt aktiv am Mon Apr 27 10:12:49 2020<br />
mit IP-Nr. 78.56.34.12; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 1; gesperrt: nein<br />
xyz00-benutzername@h02:~$<br />
</pre><br />
<br />
Das DDNS-Account &bdquo;kaiser&ldquo; in dieser Auflistung ist wohl auf Grund fehlerhafter Anfragen automatisch gesperrt worden. Der Inhaber wird sich wohl bald melden, um nach Korrektur seiner Client-Konfiguration die Aufhebung der Sperre zu wünschen.<br />
<br />
=== Log ===<br />
Alle Anfragen werden in einer täglich wechselnden Log-Datei protokolliert, entweder schlicht oder ausführlich, je nachdem, ob eine Variable <tt>verbose</tt> wahr ist.<br />
Ein ausführlicher Log-Eintrag sieht so aus:<br />
<br />
Sun Apr 26 20:21:45 2020 ddns aufgerufen von papst<br />
unter 84.185.97.8<br />
URL: <nowiki>https://ddns.example.com/cgi-bin/ddns.cgi?hostname=<br />
avignon.example.com,vatican.beispiel.de&<br />
myip=84.185.97.8</nowiki><br />
Verwende IP 84.185.97.8 (= 1421435144)<br />
DB-Version: 1<br />
Skript und DB exklusiv geöffnet<br />
avignon.example.com: IP: 84.185.97.8; MX: 0; Backup-MX: nein;<br />
Wildcard: nein; Mißbrauch: 0; gesperrt: nein <br />
vatican.beispiel.de: IP: 84.185.97.8; MX: 0; Backup-MX: nein;<br />
Wildcard: nein; Mißbrauch: 0; gesperrt: nein <br />
Betroffene Zonen: example.com, beispiel.de<br />
Temporärdatei example.com_hxNa.new geschrieben<br />
Zonendatei /home/pacs/xyz00/users/benutzername/doms/example.com/<br />
etc/pri.example.com eingestellt<br />
Temporärdatei beispiel.de_6HcO.new geschrieben<br />
Zonendatei /home/pacs/xyz00/users/benutzername/doms/beispiel.de/<br />
etc/pri.beispiel.de eingestellt<br />
Abgeschlossen: Fertig<br />
<br />
Wenn <tt>verbose</tt> auf falsch gesetzt ist, sind die Log-Einträge einzeilig.</div>Apc00-tonyhttps://wiki.hostsharing.net/index.php?title=Benutzer:Apc00-tony/Dynamisches_DNS&diff=6227Benutzer:Apc00-tony/Dynamisches DNS2023-09-11T14:33:55Z<p>Apc00-tony: Update 2023</p>
<hr />
<div>Update 2023: Ich habe die Verwaltung über Befehlszeile durch eine PHP-Web-Oberfläche ersetzt; Details irgendwo ... ah, [http://hier https://ddns.crawfords.de/verwaltung/ddnsadminhints?name=acanthus_crawford_berlin]. Meine Hostsharing-DDNS-Lösung läuft übrigens schon lange einwandfrei; ich benutze sie dazu, ein VPN zwischen meinen Fritz!Box-LANS zu Hause und im Büro zu realisieren sowie um auf ein Backup- und Music-Server (ein Raspberry Pi) zu Hause von unterwegs zuzugreifen.<br />
<br />
((Provisorischer Vorspann: Auf Grund einer Mailing-Listen-Diskussion habe ich angefangen, Dynamisches DNS über einen CGI-Skript bei Hostsharing zu realisieren. Meine Lösung habe ich dann vorgestellt; sie wurde für nicht ausreichend selbsterklärend befunden und fand wenig Akzeptanz. Hier also der Versuch, die Sache zu dokumentieren.))<br />
<br />
Mit der regelmäßigen Aufnahme von benutzerspezifischen Zonefiles in seiner DNS-Konfiguration bietet Hostsharing alles, was man braucht, um &bdquo;dynamisches DNS&ldquo; in Eigenregie zu realisieren.<br />
<br />
Das heißt, wenn ich mindestens eine Domain bei Hostsharing verwalte, und mindestens eine Einwahlverbindung (oder DSL-Verbindung) ins Internet mit wechselnder IP-Adresse über irgendeinen ISP für meinen Arbeitsplatzrechner zu Hause betreibe, dann kann ich dem Arbeitsplatzrechner über die DNS-Server von Hostsharing einen vollqualifizieren Domainnamen zuweisen, der der jeweiligen IP-Adresse meiner Einwahlleitung zugeordnet ist.<br />
<br />
<pre><br />
<br />
(ASCII-Art-Diagramm der beschriebenen Konstellation)<br />
<br />
</pre><br />
<br />
Im Folgenden wird eine real existierende Implementierung von Dynamischem DNS (&bdquo;DDNS&ldquo;) beschrieben. Die verschiedenen Elemente könnten durchaus anders realisiert werden; die beschriebene Implementierung könnte durchaus verbessert werden. Sie dient hier der Illustration.<br />
<br />
In der folgenden Beschreibung werden diese Beispielwerte benutzt:<br />
* Ein Hostsharing-Mitglied hat ein Account als Paket-Admin mit Kennung xyz00.<br />
* Im Paket xyz00 gibt es einen Domain-Admin namens xyz00-benutzername.<br />
* Dieser Domain-Admin verwaltet bei Hostsharing die Domains example.com und beispiel.de.<br />
* Ein Benutzer hat zu Hause (oder im Büro) einen Arbeitsplatzrechner hinter der marktüblichen DSL-Leitung, die von seinem ISP bereitgestellt wird.<br />
* Dieser Arbeitsplatzrechner (oder der Router, der seine Internetverbindung steuert) bekommt vom ISP immer wechselnde IP-Adressen zugewiesen.<br />
* Dennoch möchte der Benutzer seinen Arbeitsplatzrechner aus dem Internet unter dem Hostnamen einwahl.example.com ansprechen können.<br />
<br />
Dazu kann ein System wie Hostsharing, das authoritative DNS-Informationen für viele Domains bereitstellt, auch veränderliche DNS-Information über dynamisch verbundene Rechner verwalten &ndash; sofern das ressourcenschonend gemacht werden kann ohne andere Funktionen zu stören.<br />
<br />
== Aufgaben des Servers ==<br />
<br />
Um einem Rechner mit wechselnder IP-Adresse einen DDNS-Eintrag zu bieten, muß der Hostsharing-Server folgendes leisten (in ungefährer Reihenfolge der Ereignisse):<br />
<br />
# Eine Anfrage entgegennehmen, beispielsweise über HTTPS, von einem entfernten Rechner, der einen DNS-Eintrag für seine momentane IP-Adresse wünscht. <br />
# Prüfen, ob die Anfrage einen berechtigten DDNS-Dienst-Usernamen mit zugehörigem Paßwort enthält.<br />
# Prüfen, ob die Anfrage einen gültigen Domainnamen betrifft, den der Server bieten darf.<br />
# Prüfen, ob die Domain example.com demselben Benutzer gehört, unter dessen Namen der Dynamisches-DNS-Server läuft.<br />
# Eine gültige [[Zonefile]] mit &ndash; neben dem bisherigen Inhalt &ndash; einem A-Eintrag für einwahl.example.com in /home/pacs/xyz00/users/benutzername/doms/example.com/pri.example.com schreiben.<br />
# Dem Client eine Bestätigung oder ggf. eine Fehlermeldung als Antwort senden.<br />
# In irgendeiner Datenbank den momentan eingestellter Status all seiner DDNS-Einträge speichern.<br />
# In einer Logdatei protokollieren, daß obiges getan wurde, oder ggf. welche Fehler traten auf.<br />
<br />
== Aufgaben des Clients ==<br />
Bevor ich anfange, meinen Arbeitsplatzrechner so zu konfigurieren, daß er bei welchem Server auch immer einen DDNS-Eintrag anfordert, muß ich mich als verantwortlicher Benutzer dieses Rechners und der dazugehörigen Internetverbindung &ndash; das heißt, als Mensch &ndash; mit dem Betreiber des dynamisches-DNS-Servers vereinbaren, daß ich das darf und welchen Eintrag ich bekommen kann. Im Folgenden wird vorausgesetzt, daß solche Vereinbarungen getroffen und die Parameter geklärt wurden.<br />
<br />
Der DDNS-Client muß aus Server-Sicht nur wenig leisten:<br />
<br />
# Eine Anfrage senden, beispielsweise über HTTPS, an einen entfernten Rechner, der einen Eintrag ins DNS für die momentane IP-Adresse des Clients vornehmen kann.<br />Diese Anfrage muß einem festgelegten Format entsprechen und muß gültige Werte für die Authorisation des Clients, den gewünschten Domainnamen, und eventuell andere Parameter enthalten.<br />
# Eine Antwort des Servers entgegennehmen und als Erfolgs- oder Fehlermeldung auswerten.<br />
# Von überflüssigen Anfragen absehen: das heißt bei Erfolg, nicht wiederholt den gleichen Eintrag erneut wünschen; bei Fehlern, nicht die gleiche fehlerhafte Anfrage erneut schicken.<br />
<br />
== Kommunikation zwischen Client und Server ==<br />
<br />
Ein einziges Nachrichtenpaar von Anfrage und Antwort genügt, um einen DDNS-Eintrag einzurichten: Der Client teilt die IP-Adresse und den Domainnamen mit, die in einem DNS-Eintrag verbunden werden sollen; der Server bestätigt den Auftrag.<br />
<br />
In der Beispielimplementierung erfolgt die Kommunikation über HTTP, und die Anfrage des Clients könnte so aussehen:<br />
<br />
GET /cgi-bin/ddns?hostname=einwahl.example.com&myip=87.65.43.21 HTTP/1.1<br />
Host: ddns.beispiel.de<br />
User-Agent: Fritz!Box DDNS/1.0.1<br />
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==<br />
<br />
Bei Erhalt dieser Anfrage ruft Apache das CGI-Programm .../doms/ddns.beispiel.de/cgi-ssl/ddns auf. Das Fragezeichen trennt den Programmnamen von einem "Query-String", in dem zwei Metavariablen definiert und übergeben werden. Die erste Metavariable, hostname, hat den Wert "einwahl.example.com"; die zweite, myip, hat den Wert "87.65.43.21".<br />
<br />
Das Server-Programm, hier ''ddns'', prüft diese Informationen auf Form und Berechtigung, und schreibt gegebenenfalls einen entsprechenden Eintrag in einer Zonefile. Es schreibt auch verschiedene Informationen in die Standardausgabe. Wenn es die Standardausgabe geschlossen wird &ndash; also spätestens bei Programmende &ndash; schickt Apache diese Informationen als Antwort an den anfragenden Rechner zurück.<br />
<br />
Im Falle unserer Beispielimplementierung sieht die Antwort bei Erfolg so aus: <br />
<br />
HTTP/1.1 200 OK<br />
Date: Wed, 22 Apr 2020 08:35:15 GMT<br />
Server: Apache<br />
Content-Length: 17<br />
Content-Type: text/plain; charset=ISO-8859-1<br />
<br />
good 87.65.43.21<br />
<br />
=== Das DDNS-Protokoll von DynDNS.org ===<br />
<br />
In den 90er Jahren, bevor das Internet so durchgehend vergeschäftlicht wurde, boten einige Organisationen kostenlose DDNS-Dienste an. Ein sehr beliebtes Angebot war das von DynDNS.org. Das DDNS-Protokoll von diesem Dienst wurde sogar in Einwahl-Routern einprogrammiert und der Dienst wurde von ISPs und Router-Herstellern als Leistungsmerkmal beworben.<br />
<br />
DynDNS.org gehört inzwischen Oracle und bietet keine kostenlose Dienste mehr. Dennoch wird das DDNS-Protokoll von DynDNS.org in der vorliegenden Beispielimplementierung übernommen in der Hoffnung, daß die Kompatibilität mit einigen gängigen Einwahl-Routern von Vorteil sein kann. Es gibt noch eine kurze Online-Dokumentation der [https://help.dyn.com/remote-access-api/perform-update/ Anfrage] und [https://help.dyn.com/remote-access-api/perform-update/ Antwortnachrichten].<br />
<br />
Das gesammte Protokoll sieht einen einzigen Nachrichtenaustausch aus Anfrage und Antwort vor. Die Anfrage kann mehrere Argumente enthalten; die Antwort kann verschiedene Code-Wörtern enthalten. Übrigens können in einer einzigen Anfrage mehrere DNS-Einträge gewünscht werden. In diesem Fall kann die Antwort mehrzeilig ausfallen.<br />
<br />
Das Verhalten von Server und Client bei künftigen Kommunikationsvorgängen wird unter Umständen von vorangegangenen Kommunikationsergebnissen beeinflußt: nach wiederholten fehlerhaften oder redundanten Anfragen kann der Server weitere Anfragen des Benutzers verweigern; nach wiederholten Fehlermeldungen sollte ein Client aufhören, immer dieselbe Anfrage zu schicken. Und für den Fall, daß mehrere Clients dynamische DNS-Einträge in derselben Domain example.com bestellen, muß der Server den Stand aller Client-Einträge intern speichern, damit er nicht mit einer neuen Zonefile einen früher erstellten Eintrag löscht. Zu diesen Fragen siehe den Abschnitt '''[[#Sukzessive_Kommunikationsabläufe]]''' nach der Beschreibung von Anfragen und Antworten unten.<br />
<br />
====Anfrage====<br />
<br />
Die Anfrage in Form eines URL übergibt dem DDNS-Programm in einem 'Query-String' einige Metavariablen. Das heißt, in einem URL der Form<br />
<br />
<nowiki>https://benutzername:passwort@ddns.beisiel.de/cgi-bin/ddns?hostname=einwahl.example.com&myip=87.65.43.21</nowiki><br />
<br />
signalisert das Fragezeichen, daß ein Query-String folgt. In einem solchen Query-String können in der Beispielimplementierung folgende Metavariablen definiert werden:<br />
<br />
{| class="wikitable"<br />
|- class="hintergrundfarbe5"<br />
! Variable !! Beispiel !! Bemerkungen<br />
|-<br />
| hostname || <tt>hostname=einwahl.example.com</tt><br /><div style="font-size:smaller;"><tt>hostname=eins.example.com,zwei.example.com[,...]</tt></div> ||<br />
Muß ein vollständig qualifizierter Domain-Name ("FQDN") sein; <tt>example.com</tt> muß eine vom Besitzer des DDNS-Programms verwaltete Domain sein. Genaugenommen kann der Wert eine durch Kommata gegliederte Liste mehrerer gültiger Domainnamen sein, falls mehrere Einträge mit derselben IP-Adresse gewünscht werden.<br />
|-<br />
| myip || <tt>myip=87.65.43.21</tt>||<br />
Kann entfallen; kann vom Server ignoriert werden. Maßgeblich ist dann die IP-Adresse des Absenders, wie sie vom Web-Server mitgeteilt wird.<br />
|-<br />
| mx || <tt>mx=87.65.43.21</tt><br /><tt>mx=NOCHG</tt><br /> ||<br />
Neben dem A-Eintrag möchte der Client auch einen MX-Eintrag. Der Wert <tt>NOCHG</tt> (für &bdquo;no change&ldquo;) bedeutet, der bestehende MX-Eintrag (oder seine Abwesenheit) soll nicht geändert werden. <br />
|-<br />
| backmx || <tt>backmx=YES</tt><br /><tt>backmx=NOCHG</tt><br /><tt>backmx=NO</tt> ||<br />
Falls <tt>YES</tt>, wird ein zweiter MX-Eintrag erzeugt, der <tt>einwahl.example.com</tt> als Mail-Server für <tt>einwahl.example.com</tt> nennt. Dieser Eintrag hat eine niedrigere Präferenzzahl (also eine höhere Priorität) als der mit <tt>mx</tt> angeforderten Eintrag.<br />
|-<br />
| wildcard || <tt>wildcard=ON</tt><br /><tt>wildcard=NOCHG</tt><br /><tt>wildcard=OFF</tt> ||<br />
Neben dem A-Eintrag für den Domainnamen <tt>einwahl.example.com</tt> wünscht der Client auch einen Eintrag für beliebige Subdomains, also <tt>*.einwahl.example.com</tt>, mit der gleichen IP-Adresse.<br />
|-<br />
| offline ||<tt>offline=YES</tt><br /><tt>offline=NOCHG</tt>||<br />
Falls <tt>YES</tt>, wird ein DNS-Eintrag für <tt>einwahl.example.com</tt> aus der Zonefile getilgt. Gegebenenfalls wird der Hostname dann auf Grund eines parallelen Wildcard-Eintrags für <tt>*.example.com</tt> einer anderen IP-Adresse zugeordnet werden.<br />
|}<br />
<br />
<!-- IPv6? --><br />
<br />
Alle Parameter bis auf hostname können entfallen. Bei nichtdokumentierten Argumenten ist das Verhalten undefiniert&trade;.<br />
<br />
====Antwort====<br />
<br />
Die Antwort auf eine erfolgreiche HTTP-Anfrage besteht im häufigsten Fall aus einigen Header-Zeilen, gefolgt vom Inhalt der gewünschten Text- oder andere Datei. Ein Status-Code in der ersten Header-Zeile gibt an, ob die Anfrage bedient werden kann oder kreist andernfalls den Grund für die Enttäuschung ein.<br />
<br />
Die vorliegende Beispielimplementierung von DDNS schickt einen der üblichen HTTP-Status-Codes "200 OK" oder "500 Internal Server Error", gefolgt von einer kurzen Textnachricht nach dem HTTP-Header. Bei diesem Programm ist &ndash; laut Gebrauchshinweise von DynDNS.org &ndash; ''nicht'' der Status-Code im Header, sondern der Inhalt der Nachricht die definierte, maßgebliche Ergebnismeldung des Programms.<br />
<br />
{| class="wikitable"<br />
|- class="hintergrundfarbe5"<br />
! Meldung !! Bedeutung !! Bemerkungen<br />
|-<br />
| <tt>good&nbsp;&lt;IP&nbsp;number&gt;</tt> ||<br />
Der gewünschte DNS-Eintrag wurde erfolgreich in einer Zonefile eingetragen. <br />
|| Es kann natürlich noch einige Minuten dauern, bis die Zonefile vom Hostsharing-Roboter abgelesen wird und der Inhalt in die BIND-Konfiguration übernommen.<br />
|-<br />
| <tt>good&nbsp;0.0.0.0</tt> ||<br />
Das Argument <tt>offline=YES</tt> wurde empfangen und verarbeitet.<br />
|| Der Domainname hat also keinen dynamischen DNS-Eintrag mehr.<br />
|-<br />
<!-- We don't do this!<br />
| <tt>good&nbsp;127.0.0.1</tt> ||<br />
Die Anfrage entsprach nicht den Erfordernissen des Servers.<br />
|| Trotz des Worts <tt>good</tt> war die Anfrage nicht erfolgreich, falls in der Rückmeldung die IP-Adresse mit <tt>127.0.0.1</tt> angegeben wird. Dieser verwirrende Fehlercode ist aus unerklärlichen Gründen in der Spezifikation von DynDNS.org so definiert.<br />
|-<br />
--><br />
| <tt>nochg&nbsp;&lt;IP&nbsp;number&gt;</tt> ||<br />
Der gewünschte DNS-Eintrag war bereits vorhanden. <br />
|| Der Server selbst macht keine DNS-Abfrage, um das zu vermitteln: die &bdquo;no change&ldquo;-Antwort besagt nur, daß eine Anfrage für diesen Eintrag bereits mit Erfolg quittiert wurde.<br />
|-<br />
| <tt>notfqdn</tt> ||<br />
Fehlschlag: der gewünschte Domainname ist nicht gültig, oder es wurde keiner angegeben.<br />
|| ...<br />
|-<br />
| <tt>nohost</tt> ||<br />
Fehlschlag: der gewünschte Domainname ist gehört nicht zu denen, die für diesen Benutzer des DDNS-Dienstes konfiguriert sind.<br />
|| Siehe den Abschnitt [[#Administration|Administration]] weiter unten.<br />
|-<br />
| <tt>badauth</tt> ||<br />
Fehlschlag: Die Kombination von Benutzernamen und Paßwort entsprach keinem DDNS-Account, oder das Account ist momentan gesperrt.<br />
|| Ein gesperrtes Account kann nur der Domain-Admin mittels des Administrationswerkzeugs wieder freigeben: siehe den Abschnit [[#Administration|Administration]] weiter unten.<br />
|-<br />
| <tt>abuse</tt> ||<br />
Fehlschlag: der gewünschte Domainname ist wegen vorangeganger Fehlschläge oder überflüssiger Aufrufe gesperrt.<br />
|| Siehe den Abschnitt [[#Sukzessive_Kommunikationsabläufe|Sukzessive Kommunikationsabläufe]] unten.<br />
|-<br />
| <tt>911</tt> ||<br />
Fehlschlag: Das Server-Programm hat einen internen Fehler festgestellt.<br />
|| Das Problem liegt nicht in der Anfrage an sich.<br />
|}<br />
<br />
Man kann sich durchaus eine sinnreichere Kommunikation zwischen Client und Server vorstellen, doch das hier beschriebene Protokoll ist eben von DynDNS.org verwendet worden und wird in gängigen Routern implementiert, also wird es in der vorliegenden DDNS-Implementierung nachgebildet.<br />
<br />
=== Sukzessive Kommunikationsabläufe ===<br />
Der Server muß sich zwischen einzelnen Aufrufen einiges merken, um Ressourcen zu schonen und um zu verhindern, daß einmal vergebene DDNS-Einträge von neuen Anfragen, die dieselbe übergeordnete Domain betreffen, durch Überschreiben verlorengehen.<br />
<br />
==== Mißbrauch und Benutzersperrung ====<br />
Zur Schonung von Ressourcen muß sich die Implementierung weigern, sich mit zuvielen fehlerhaften oder auch nur überflüssigen Anfragen zu beschäftigen. Dazu führt der Server eine Strichliste über solche Anfragen jedes Clients und sperrt nach einer bestimmten Anzahl solcher Anfragen den Benutzernamen oder einzelne Domainnamen gegen die weitere Nutzung des Dienstes.<br />
<br />
Mißbrauchspunkte gegen einen einzelnen Domainnamen gibt es für:<br />
* eine Anfrage, die keinen neuen DNS-Eintrag (und keine Änderung oder Löschung eines Eintrags) erfordert, sondern bestehende Merkmale nur wiederholt<br />
<br />
Mißbrauchspunkte gegen einen Benutzernamen gibt es für:<br />
* die Angabe eines Domainnamens, der in der Dienstkonfiguration dem anfragenden Benutzernamen nicht zugeordnet ist<br />
* die Angabe eines Domainnamen in einer Domain, die nicht demselben Hostsharing-Domain-Admin gehört, der den DDNS-Dienst anbietet<br />
* die Angabe eines Domainnamens, der in der Dienstkonfiguration bereits wegen mißbräuchlicher Anfragen gesperrt ist (siehe oben)<br />
<br />
Um eine Sperrung aufzuheben, wird in der Regel eine Handlung durch den Administrator erforderlich sein.<br />
<br />
==== Mehrere dynamische Subdomains in derselben Domain ====<br />
Sobald zwei verschiedene DDNS-Einträge in derselben Domain verlangt werden &ndash; beispielsweise home.example.com und office.example.com &ndash; wird es notwendig, bei jeder neuen Zonefile für example.com eventuell frühere Einträge zu konservieren. Der Rechner zu Hause weiß beim Bestellen seines DDNS-Eintrags nichts vom Rechner im Büro und umgekehrt. Der Server muß in irgendeiner Form über bereits vergebene Einträge Buch führen und bei einer neuen Anfrage, die example.com betrifft, alle bereits aktiven DDNS-Einträge für example.com mit in die neue Zonefile aufnehmen &ndash auch wenn sie auf Anfragen verschiedener Benutzer zurückgehen.<br />
<br />
==== Datenbank ====<br />
In der Beispielimplementierung werden diese Informationen in einer SQLite-Datenbank gespeichert.<br />
<br />
== Sicherheit ==<br />
=== Rechte ===<br />
Die '''Benutzerrechte''' werden durch das Hostsharing-System kontrolliert. Sowohl das CGI-Programm als auch das [[#Administration|Administrationswerkzeug]] werden mit den Rechten des Domain-Admins (xyz00-benutzername in unserem Beispiel) ausgeführt, also kann dieses Programm nur die Domains bearbeiten, die von xyz00-benutzername verwaltet werden.<br />
<br />
=== Authentifizierung ===<br />
In der Beispielimplementierung (wie auch seinerzeit bei DynDNS.org) wird das CGI-Programm durch einen .htaccess-Eintrag geschützt, der HTTP-Basic-Authentication vorschreibt. Also wird das Programm eigentlich mit einem URL der form<br />
<br />
<nowiki>https://ddnsaccount:passwort@ddns.example.com/cgi-bin/ddns?hostname=...</nowiki><br />
<br />
aufgerufen.<br />
<br />
=== Verschlüsselung ===<br />
Das CGI-Programm sollte nur in example.com/cgi-ssl/ installiert werden, nicht in example.com/cgi/. Damit ist die Kommunikation zwischen Client und Server durch SSL verschlüsselt.<br />
<br />
== Administration ==<br />
<br />
Der Verwalter des DDNS-Programms trägt berechtigte Benutzer und die ihnen zugeteilten Domainnamen in die Datenbank des Programms ein mit Hilfe eines kleinen Hilfsprogramms. Das ist im vorliegenden Fall ein menügesteuertes Programm für die Befehlszeile, daß die naheliegenden Funktionen anbietet: Account hinzufügen, löschen, sperren, entsperren, Paßwort setzen, ändern; Domainnamen hinzufügen, ändern, entsperren, löschen; Accounts und Domainnamen mit aktuellem Status auflisten. Die Funktionen sind auch über Befehlszeilenargumente verfügbar, also skriptfähig.<br />
<br />
Eine Übersicht der Funktionen des Administrationswerkzeugs gibt dieses selbst aus:<br />
<br />
<pre><br />
xyz00-benutzername@h02:~$ bin/ddnsadmin -h<br />
ddnsadmin.pl: Verwaltungswerkzeug für ddns<br />
<br />
Verwendung:<br />
ddnsadmin -A{[ahlusf]} [<Account>] [-f <DB-Datei>]<br />
ddnsadmin -D{[ahlsf]} [<Domain>] -A <Account> [-f <DB-Datei>]<br />
ddnsadmin -E <Einstellung> <Wert> [-f <DB-Datei>]<br />
ddnsadmin [-f <DB-Datei>] [-n]<br />
<br />
Wenn keine Option oder nur -f <DB-Datei> angegeben wird, bietet<br />
ddnsadmin.pl eine interaktive Menüoberfläche.<br />
<br />
Optionen:<br />
-f <DB-Datei> Angegebene Datenbankdatei verwenden<br />
-n Neue, leere Datenbank erzeugen<br />
-Aa [<Account>] Account(s) auflisten<br />
-Ah <Account> <Paßwort> Account hinzufügen<br />
-A{lsf} <Account> Account löschen, sperren, freigeben<br />
-Au <Account> <Name> Account umbenennen<br />
-A <Account> -Da [<Domain>] Domain(s) auflisten<br />
-A <Account> -D{hlsf} <Domain> Domain hinzufügen,<br />
löschen, sperren, freigeben<br />
-E <Einstellung> <Wert> Einstellung ändern<br />
-h Diese Übersicht ausgeben<br />
<br />
Einstellungen: <br />
maxacctabuse Anzahl der mißbräuchlichen Aufrufe,<br />
bevor ein Account gesperrt wird<br />
maxhostabuse Anzahl der mißbräuchlichen Aufrufe,<br />
bevor ein Domainname gesperrt wird<br />
safeinterval Mindestabstand zwischen redundanten Aufrufen<br />
(in Sekunden)<br />
cgihost Server, der das DDNS-Skript bereithält<br />
<br />
xyz00-benutzername@h02:~$ <br />
</pre><br />
<br />
Eine Auflistung des momentanen Inhalts der DDNS-Datenbank durch das Administrationswerkzeug könnte beispielsweise so aussehen:<br />
<br />
<pre><br />
xyz00-benutzername@h02:~$ bin/ddnsadmin.pl -Aa<br />
1. papst Mißbrauch: 0; gesperrt: nein<br />
avignon.example.com<br />
zuletzt aktiv am Sun Apr 26 22:24:49 2020<br />
mit IP-Nr. 87.65.43.21; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 0; gesperrt: nein<br />
vatican.beispiel.de<br />
zuletzt aktiv am Sun Apr 26 22:24:49 2020<br />
mit IP-Nr. 87.65.43.21; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 0; gesperrt: nein<br />
2. kaiser Mißbrauch: 4; gesperrt: ja<br />
augsburg.beispiel.de<br />
zuletzt aktiv am Fri Apr 24 16:13:49 2020<br />
mit IP-Nr. 64.82.31.75; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 0; gesperrt: ja<br />
3. luther Mißbrauch: 1; gesperrt: nein<br />
wittenberg.example.com<br />
zuletzt aktiv am Mon Apr 27 10:12:49 2020<br />
mit IP-Nr. 78.56.34.12; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 1; gesperrt: nein<br />
xyz00-benutzername@h02:~$<br />
</pre><br />
<br />
Das DDNS-Account &bdquo;kaiser&ldquo; in dieser Auflistung ist wohl auf Grund fehlerhafter Anfragen automatisch gesperrt worden. Der Inhaber wird sich wohl bald melden, um nach Korrektur seiner Client-Konfiguration die Aufhebung der Sperre zu wünschen.<br />
<br />
=== Log ===<br />
Alle Anfragen werden in einer täglich wechselnden Log-Datei protokolliert, entweder schlicht oder ausführlich, je nachdem, ob eine Variable <tt>verbose</tt> wahr ist.<br />
Ein ausführlicher Log-Eintrag sieht so aus:<br />
<br />
Sun Apr 26 20:21:45 2020 ddns aufgerufen von papst<br />
unter 84.185.97.8<br />
URL: <nowiki>https://ddns.example.com/cgi-bin/ddns.cgi?hostname=<br />
avignon.example.com,vatican.beispiel.de&<br />
myip=84.185.97.8</nowiki><br />
Verwende IP 84.185.97.8 (= 1421435144)<br />
DB-Version: 1<br />
Skript und DB exklusiv geöffnet<br />
avignon.example.com: IP: 84.185.97.8; MX: 0; Backup-MX: nein;<br />
Wildcard: nein; Mißbrauch: 0; gesperrt: nein <br />
vatican.beispiel.de: IP: 84.185.97.8; MX: 0; Backup-MX: nein;<br />
Wildcard: nein; Mißbrauch: 0; gesperrt: nein <br />
Betroffene Zonen: example.com, beispiel.de<br />
Temporärdatei example.com_hxNa.new geschrieben<br />
Zonendatei /home/pacs/xyz00/users/benutzername/doms/example.com/<br />
etc/pri.example.com eingestellt<br />
Temporärdatei beispiel.de_6HcO.new geschrieben<br />
Zonendatei /home/pacs/xyz00/users/benutzername/doms/beispiel.de/<br />
etc/pri.beispiel.de eingestellt<br />
Abgeschlossen: Fertig<br />
<br />
Wenn <tt>verbose</tt> auf falsch gesetzt ist, sind die Log-Einträge einzeilig.</div>Apc00-tonyhttps://wiki.hostsharing.net/index.php?title=Benutzer:Apc00-tony/Dynamisches_DNS&diff=6226Benutzer:Apc00-tony/Dynamisches DNS2023-09-11T14:26:08Z<p>Apc00-tony: </p>
<hr />
<div>Update 2023: Ich habe die Verwaltung über Befehlszeile durch eine PHP-Web-Oberfläche ersetzt; Details irgendwo ... Meine Hostsharing-DDNS-Lösung läuft übrigens schon lange einwandfrei; ich benutze sie dazu, ein VPN zwischen meinen Fritz!Box-LANS zu Hause und im Büro zu realisieren sowie um auf ein Backup- und Music-Server (ein Raspberry Pi) zu Hause von unterwegs zuzugreifen.<br />
<br />
((Provisorischer Vorspann: Auf Grund einer Mailing-Listen-Diskussion habe ich angefangen, Dynamisches DNS über einen CGI-Skript bei Hostsharing zu realisieren. Meine Lösung habe ich dann vorgestellt; sie wurde für nicht ausreichend selbsterklärend befunden und fand wenig Akzeptanz. Hier also der Versuch, die Sache zu dokumentieren.))<br />
<br />
Mit der regelmäßigen Aufnahme von benutzerspezifischen Zonefiles in seiner DNS-Konfiguration bietet Hostsharing alles, was man braucht, um &bdquo;dynamisches DNS&ldquo; in Eigenregie zu realisieren.<br />
<br />
Das heißt, wenn ich mindestens eine Domain bei Hostsharing verwalte, und mindestens eine Einwahlverbindung (oder DSL-Verbindung) ins Internet mit wechselnder IP-Adresse über irgendeinen ISP für meinen Arbeitsplatzrechner zu Hause betreibe, dann kann ich dem Arbeitsplatzrechner über die DNS-Server von Hostsharing einen vollqualifizieren Domainnamen zuweisen, der der jeweiligen IP-Adresse meiner Einwahlleitung zugeordnet ist.<br />
<br />
<pre><br />
<br />
(ASCII-Art-Diagramm der beschriebenen Konstellation)<br />
<br />
</pre><br />
<br />
Im Folgenden wird eine real existierende Implementierung von Dynamischem DNS (&bdquo;DDNS&ldquo;) beschrieben. Die verschiedenen Elemente könnten durchaus anders realisiert werden; die beschriebene Implementierung könnte durchaus verbessert werden. Sie dient hier der Illustration.<br />
<br />
In der folgenden Beschreibung werden diese Beispielwerte benutzt:<br />
* Ein Hostsharing-Mitglied hat ein Account als Paket-Admin mit Kennung xyz00.<br />
* Im Paket xyz00 gibt es einen Domain-Admin namens xyz00-benutzername.<br />
* Dieser Domain-Admin verwaltet bei Hostsharing die Domains example.com und beispiel.de.<br />
* Ein Benutzer hat zu Hause (oder im Büro) einen Arbeitsplatzrechner hinter der marktüblichen DSL-Leitung, die von seinem ISP bereitgestellt wird.<br />
* Dieser Arbeitsplatzrechner (oder der Router, der seine Internetverbindung steuert) bekommt vom ISP immer wechselnde IP-Adressen zugewiesen.<br />
* Dennoch möchte der Benutzer seinen Arbeitsplatzrechner aus dem Internet unter dem Hostnamen einwahl.example.com ansprechen können.<br />
<br />
Dazu kann ein System wie Hostsharing, das authoritative DNS-Informationen für viele Domains bereitstellt, auch veränderliche DNS-Information über dynamisch verbundene Rechner verwalten &ndash; sofern das ressourcenschonend gemacht werden kann ohne andere Funktionen zu stören.<br />
<br />
== Aufgaben des Servers ==<br />
<br />
Um einem Rechner mit wechselnder IP-Adresse einen DDNS-Eintrag zu bieten, muß der Hostsharing-Server folgendes leisten (in ungefährer Reihenfolge der Ereignisse):<br />
<br />
# Eine Anfrage entgegennehmen, beispielsweise über HTTPS, von einem entfernten Rechner, der einen DNS-Eintrag für seine momentane IP-Adresse wünscht. <br />
# Prüfen, ob die Anfrage einen berechtigten DDNS-Dienst-Usernamen mit zugehörigem Paßwort enthält.<br />
# Prüfen, ob die Anfrage einen gültigen Domainnamen betrifft, den der Server bieten darf.<br />
# Prüfen, ob die Domain example.com demselben Benutzer gehört, unter dessen Namen der Dynamisches-DNS-Server läuft.<br />
# Eine gültige [[Zonefile]] mit &ndash; neben dem bisherigen Inhalt &ndash; einem A-Eintrag für einwahl.example.com in /home/pacs/xyz00/users/benutzername/doms/example.com/pri.example.com schreiben.<br />
# Dem Client eine Bestätigung oder ggf. eine Fehlermeldung als Antwort senden.<br />
# In irgendeiner Datenbank den momentan eingestellter Status all seiner DDNS-Einträge speichern.<br />
# In einer Logdatei protokollieren, daß obiges getan wurde, oder ggf. welche Fehler traten auf.<br />
<br />
== Aufgaben des Clients ==<br />
Bevor ich anfange, meinen Arbeitsplatzrechner so zu konfigurieren, daß er bei welchem Server auch immer einen DDNS-Eintrag anfordert, muß ich mich als verantwortlicher Benutzer dieses Rechners und der dazugehörigen Internetverbindung &ndash; das heißt, als Mensch &ndash; mit dem Betreiber des dynamisches-DNS-Servers vereinbaren, daß ich das darf und welchen Eintrag ich bekommen kann. Im Folgenden wird vorausgesetzt, daß solche Vereinbarungen getroffen und die Parameter geklärt wurden.<br />
<br />
Der DDNS-Client muß aus Server-Sicht nur wenig leisten:<br />
<br />
# Eine Anfrage senden, beispielsweise über HTTPS, an einen entfernten Rechner, der einen Eintrag ins DNS für die momentane IP-Adresse des Clients vornehmen kann.<br />Diese Anfrage muß einem festgelegten Format entsprechen und muß gültige Werte für die Authorisation des Clients, den gewünschten Domainnamen, und eventuell andere Parameter enthalten.<br />
# Eine Antwort des Servers entgegennehmen und als Erfolgs- oder Fehlermeldung auswerten.<br />
# Von überflüssigen Anfragen absehen: das heißt bei Erfolg, nicht wiederholt den gleichen Eintrag erneut wünschen; bei Fehlern, nicht die gleiche fehlerhafte Anfrage erneut schicken.<br />
<br />
== Kommunikation zwischen Client und Server ==<br />
<br />
Ein einziges Nachrichtenpaar von Anfrage und Antwort genügt, um einen DDNS-Eintrag einzurichten: Der Client teilt die IP-Adresse und den Domainnamen mit, die in einem DNS-Eintrag verbunden werden sollen; der Server bestätigt den Auftrag.<br />
<br />
In der Beispielimplementierung erfolgt die Kommunikation über HTTP, und die Anfrage des Clients könnte so aussehen:<br />
<br />
GET /cgi-bin/ddns?hostname=einwahl.example.com&myip=87.65.43.21 HTTP/1.1<br />
Host: ddns.beispiel.de<br />
User-Agent: Fritz!Box DDNS/1.0.1<br />
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==<br />
<br />
Bei Erhalt dieser Anfrage ruft Apache das CGI-Programm .../doms/ddns.beispiel.de/cgi-ssl/ddns auf. Das Fragezeichen trennt den Programmnamen von einem "Query-String", in dem zwei Metavariablen definiert und übergeben werden. Die erste Metavariable, hostname, hat den Wert "einwahl.example.com"; die zweite, myip, hat den Wert "87.65.43.21".<br />
<br />
Das Server-Programm, hier ''ddns'', prüft diese Informationen auf Form und Berechtigung, und schreibt gegebenenfalls einen entsprechenden Eintrag in einer Zonefile. Es schreibt auch verschiedene Informationen in die Standardausgabe. Wenn es die Standardausgabe geschlossen wird &ndash; also spätestens bei Programmende &ndash; schickt Apache diese Informationen als Antwort an den anfragenden Rechner zurück.<br />
<br />
Im Falle unserer Beispielimplementierung sieht die Antwort bei Erfolg so aus: <br />
<br />
HTTP/1.1 200 OK<br />
Date: Wed, 22 Apr 2020 08:35:15 GMT<br />
Server: Apache<br />
Content-Length: 17<br />
Content-Type: text/plain; charset=ISO-8859-1<br />
<br />
good 87.65.43.21<br />
<br />
=== Das DDNS-Protokoll von DynDNS.org ===<br />
<br />
In den 90er Jahren, bevor das Internet so durchgehend vergeschäftlicht wurde, boten einige Organisationen kostenlose DDNS-Dienste an. Ein sehr beliebtes Angebot war das von DynDNS.org. Das DDNS-Protokoll von diesem Dienst wurde sogar in Einwahl-Routern einprogrammiert und der Dienst wurde von ISPs und Router-Herstellern als Leistungsmerkmal beworben.<br />
<br />
DynDNS.org gehört inzwischen Oracle und bietet keine kostenlose Dienste mehr. Dennoch wird das DDNS-Protokoll von DynDNS.org in der vorliegenden Beispielimplementierung übernommen in der Hoffnung, daß die Kompatibilität mit einigen gängigen Einwahl-Routern von Vorteil sein kann. Es gibt noch eine kurze Online-Dokumentation der [https://help.dyn.com/remote-access-api/perform-update/ Anfrage] und [https://help.dyn.com/remote-access-api/perform-update/ Antwortnachrichten].<br />
<br />
Das gesammte Protokoll sieht einen einzigen Nachrichtenaustausch aus Anfrage und Antwort vor. Die Anfrage kann mehrere Argumente enthalten; die Antwort kann verschiedene Code-Wörtern enthalten. Übrigens können in einer einzigen Anfrage mehrere DNS-Einträge gewünscht werden. In diesem Fall kann die Antwort mehrzeilig ausfallen.<br />
<br />
Das Verhalten von Server und Client bei künftigen Kommunikationsvorgängen wird unter Umständen von vorangegangenen Kommunikationsergebnissen beeinflußt: nach wiederholten fehlerhaften oder redundanten Anfragen kann der Server weitere Anfragen des Benutzers verweigern; nach wiederholten Fehlermeldungen sollte ein Client aufhören, immer dieselbe Anfrage zu schicken. Und für den Fall, daß mehrere Clients dynamische DNS-Einträge in derselben Domain example.com bestellen, muß der Server den Stand aller Client-Einträge intern speichern, damit er nicht mit einer neuen Zonefile einen früher erstellten Eintrag löscht. Zu diesen Fragen siehe den Abschnitt '''[[#Sukzessive_Kommunikationsabläufe]]''' nach der Beschreibung von Anfragen und Antworten unten.<br />
<br />
====Anfrage====<br />
<br />
Die Anfrage in Form eines URL übergibt dem DDNS-Programm in einem 'Query-String' einige Metavariablen. Das heißt, in einem URL der Form<br />
<br />
<nowiki>https://benutzername:passwort@ddns.beisiel.de/cgi-bin/ddns?hostname=einwahl.example.com&myip=87.65.43.21</nowiki><br />
<br />
signalisert das Fragezeichen, daß ein Query-String folgt. In einem solchen Query-String können in der Beispielimplementierung folgende Metavariablen definiert werden:<br />
<br />
{| class="wikitable"<br />
|- class="hintergrundfarbe5"<br />
! Variable !! Beispiel !! Bemerkungen<br />
|-<br />
| hostname || <tt>hostname=einwahl.example.com</tt><br /><div style="font-size:smaller;"><tt>hostname=eins.example.com,zwei.example.com[,...]</tt></div> ||<br />
Muß ein vollständig qualifizierter Domain-Name ("FQDN") sein; <tt>example.com</tt> muß eine vom Besitzer des DDNS-Programms verwaltete Domain sein. Genaugenommen kann der Wert eine durch Kommata gegliederte Liste mehrerer gültiger Domainnamen sein, falls mehrere Einträge mit derselben IP-Adresse gewünscht werden.<br />
|-<br />
| myip || <tt>myip=87.65.43.21</tt>||<br />
Kann entfallen; kann vom Server ignoriert werden. Maßgeblich ist dann die IP-Adresse des Absenders, wie sie vom Web-Server mitgeteilt wird.<br />
|-<br />
| mx || <tt>mx=87.65.43.21</tt><br /><tt>mx=NOCHG</tt><br /> ||<br />
Neben dem A-Eintrag möchte der Client auch einen MX-Eintrag. Der Wert <tt>NOCHG</tt> (für &bdquo;no change&ldquo;) bedeutet, der bestehende MX-Eintrag (oder seine Abwesenheit) soll nicht geändert werden. <br />
|-<br />
| backmx || <tt>backmx=YES</tt><br /><tt>backmx=NOCHG</tt><br /><tt>backmx=NO</tt> ||<br />
Falls <tt>YES</tt>, wird ein zweiter MX-Eintrag erzeugt, der <tt>einwahl.example.com</tt> als Mail-Server für <tt>einwahl.example.com</tt> nennt. Dieser Eintrag hat eine niedrigere Präferenzzahl (also eine höhere Priorität) als der mit <tt>mx</tt> angeforderten Eintrag.<br />
|-<br />
| wildcard || <tt>wildcard=ON</tt><br /><tt>wildcard=NOCHG</tt><br /><tt>wildcard=OFF</tt> ||<br />
Neben dem A-Eintrag für den Domainnamen <tt>einwahl.example.com</tt> wünscht der Client auch einen Eintrag für beliebige Subdomains, also <tt>*.einwahl.example.com</tt>, mit der gleichen IP-Adresse.<br />
|-<br />
| offline ||<tt>offline=YES</tt><br /><tt>offline=NOCHG</tt>||<br />
Falls <tt>YES</tt>, wird ein DNS-Eintrag für <tt>einwahl.example.com</tt> aus der Zonefile getilgt. Gegebenenfalls wird der Hostname dann auf Grund eines parallelen Wildcard-Eintrags für <tt>*.example.com</tt> einer anderen IP-Adresse zugeordnet werden.<br />
|}<br />
<br />
<!-- IPv6? --><br />
<br />
Alle Parameter bis auf hostname können entfallen. Bei nichtdokumentierten Argumenten ist das Verhalten undefiniert&trade;.<br />
<br />
====Antwort====<br />
<br />
Die Antwort auf eine erfolgreiche HTTP-Anfrage besteht im häufigsten Fall aus einigen Header-Zeilen, gefolgt vom Inhalt der gewünschten Text- oder andere Datei. Ein Status-Code in der ersten Header-Zeile gibt an, ob die Anfrage bedient werden kann oder kreist andernfalls den Grund für die Enttäuschung ein.<br />
<br />
Die vorliegende Beispielimplementierung von DDNS schickt einen der üblichen HTTP-Status-Codes "200 OK" oder "500 Internal Server Error", gefolgt von einer kurzen Textnachricht nach dem HTTP-Header. Bei diesem Programm ist &ndash; laut Gebrauchshinweise von DynDNS.org &ndash; ''nicht'' der Status-Code im Header, sondern der Inhalt der Nachricht die definierte, maßgebliche Ergebnismeldung des Programms.<br />
<br />
{| class="wikitable"<br />
|- class="hintergrundfarbe5"<br />
! Meldung !! Bedeutung !! Bemerkungen<br />
|-<br />
| <tt>good&nbsp;&lt;IP&nbsp;number&gt;</tt> ||<br />
Der gewünschte DNS-Eintrag wurde erfolgreich in einer Zonefile eingetragen. <br />
|| Es kann natürlich noch einige Minuten dauern, bis die Zonefile vom Hostsharing-Roboter abgelesen wird und der Inhalt in die BIND-Konfiguration übernommen.<br />
|-<br />
| <tt>good&nbsp;0.0.0.0</tt> ||<br />
Das Argument <tt>offline=YES</tt> wurde empfangen und verarbeitet.<br />
|| Der Domainname hat also keinen dynamischen DNS-Eintrag mehr.<br />
|-<br />
<!-- We don't do this!<br />
| <tt>good&nbsp;127.0.0.1</tt> ||<br />
Die Anfrage entsprach nicht den Erfordernissen des Servers.<br />
|| Trotz des Worts <tt>good</tt> war die Anfrage nicht erfolgreich, falls in der Rückmeldung die IP-Adresse mit <tt>127.0.0.1</tt> angegeben wird. Dieser verwirrende Fehlercode ist aus unerklärlichen Gründen in der Spezifikation von DynDNS.org so definiert.<br />
|-<br />
--><br />
| <tt>nochg&nbsp;&lt;IP&nbsp;number&gt;</tt> ||<br />
Der gewünschte DNS-Eintrag war bereits vorhanden. <br />
|| Der Server selbst macht keine DNS-Abfrage, um das zu vermitteln: die &bdquo;no change&ldquo;-Antwort besagt nur, daß eine Anfrage für diesen Eintrag bereits mit Erfolg quittiert wurde.<br />
|-<br />
| <tt>notfqdn</tt> ||<br />
Fehlschlag: der gewünschte Domainname ist nicht gültig, oder es wurde keiner angegeben.<br />
|| ...<br />
|-<br />
| <tt>nohost</tt> ||<br />
Fehlschlag: der gewünschte Domainname ist gehört nicht zu denen, die für diesen Benutzer des DDNS-Dienstes konfiguriert sind.<br />
|| Siehe den Abschnitt [[#Administration|Administration]] weiter unten.<br />
|-<br />
| <tt>badauth</tt> ||<br />
Fehlschlag: Die Kombination von Benutzernamen und Paßwort entsprach keinem DDNS-Account, oder das Account ist momentan gesperrt.<br />
|| Ein gesperrtes Account kann nur der Domain-Admin mittels des Administrationswerkzeugs wieder freigeben: siehe den Abschnit [[#Administration|Administration]] weiter unten.<br />
|-<br />
| <tt>abuse</tt> ||<br />
Fehlschlag: der gewünschte Domainname ist wegen vorangeganger Fehlschläge oder überflüssiger Aufrufe gesperrt.<br />
|| Siehe den Abschnitt [[#Sukzessive_Kommunikationsabläufe|Sukzessive Kommunikationsabläufe]] unten.<br />
|-<br />
| <tt>911</tt> ||<br />
Fehlschlag: Das Server-Programm hat einen internen Fehler festgestellt.<br />
|| Das Problem liegt nicht in der Anfrage an sich.<br />
|}<br />
<br />
Man kann sich durchaus eine sinnreichere Kommunikation zwischen Client und Server vorstellen, doch das hier beschriebene Protokoll ist eben von DynDNS.org verwendet worden und wird in gängigen Routern implementiert, also wird es in der vorliegenden DDNS-Implementierung nachgebildet.<br />
<br />
=== Sukzessive Kommunikationsabläufe ===<br />
Der Server muß sich zwischen einzelnen Aufrufen einiges merken, um Ressourcen zu schonen und um zu verhindern, daß einmal vergebene DDNS-Einträge von neuen Anfragen, die dieselbe übergeordnete Domain betreffen, durch Überschreiben verlorengehen.<br />
<br />
==== Mißbrauch und Benutzersperrung ====<br />
Zur Schonung von Ressourcen muß sich die Implementierung weigern, sich mit zuvielen fehlerhaften oder auch nur überflüssigen Anfragen zu beschäftigen. Dazu führt der Server eine Strichliste über solche Anfragen jedes Clients und sperrt nach einer bestimmten Anzahl solcher Anfragen den Benutzernamen oder einzelne Domainnamen gegen die weitere Nutzung des Dienstes.<br />
<br />
Mißbrauchspunkte gegen einen einzelnen Domainnamen gibt es für:<br />
* eine Anfrage, die keinen neuen DNS-Eintrag (und keine Änderung oder Löschung eines Eintrags) erfordert, sondern bestehende Merkmale nur wiederholt<br />
<br />
Mißbrauchspunkte gegen einen Benutzernamen gibt es für:<br />
* die Angabe eines Domainnamens, der in der Dienstkonfiguration dem anfragenden Benutzernamen nicht zugeordnet ist<br />
* die Angabe eines Domainnamen in einer Domain, die nicht demselben Hostsharing-Domain-Admin gehört, der den DDNS-Dienst anbietet<br />
* die Angabe eines Domainnamens, der in der Dienstkonfiguration bereits wegen mißbräuchlicher Anfragen gesperrt ist (siehe oben)<br />
<br />
Um eine Sperrung aufzuheben, wird in der Regel eine Handlung durch den Administrator erforderlich sein.<br />
<br />
==== Mehrere dynamische Subdomains in derselben Domain ====<br />
Sobald zwei verschiedene DDNS-Einträge in derselben Domain verlangt werden &ndash; beispielsweise home.example.com und office.example.com &ndash; wird es notwendig, bei jeder neuen Zonefile für example.com eventuell frühere Einträge zu konservieren. Der Rechner zu Hause weiß beim Bestellen seines DDNS-Eintrags nichts vom Rechner im Büro und umgekehrt. Der Server muß in irgendeiner Form über bereits vergebene Einträge Buch führen und bei einer neuen Anfrage, die example.com betrifft, alle bereits aktiven DDNS-Einträge für example.com mit in die neue Zonefile aufnehmen &ndash auch wenn sie auf Anfragen verschiedener Benutzer zurückgehen.<br />
<br />
==== Datenbank ====<br />
In der Beispielimplementierung werden diese Informationen in einer SQLite-Datenbank gespeichert.<br />
<br />
== Sicherheit ==<br />
=== Rechte ===<br />
Die '''Benutzerrechte''' werden durch das Hostsharing-System kontrolliert. Sowohl das CGI-Programm als auch das [[#Administration|Administrationswerkzeug]] werden mit den Rechten des Domain-Admins (xyz00-benutzername in unserem Beispiel) ausgeführt, also kann dieses Programm nur die Domains bearbeiten, die von xyz00-benutzername verwaltet werden.<br />
<br />
=== Authentifizierung ===<br />
In der Beispielimplementierung (wie auch seinerzeit bei DynDNS.org) wird das CGI-Programm durch einen .htaccess-Eintrag geschützt, der HTTP-Basic-Authentication vorschreibt. Also wird das Programm eigentlich mit einem URL der form<br />
<br />
<nowiki>https://ddnsaccount:passwort@ddns.example.com/cgi-bin/ddns?hostname=...</nowiki><br />
<br />
aufgerufen.<br />
<br />
=== Verschlüsselung ===<br />
Das CGI-Programm sollte nur in example.com/cgi-ssl/ installiert werden, nicht in example.com/cgi/. Damit ist die Kommunikation zwischen Client und Server durch SSL verschlüsselt.<br />
<br />
== Administration ==<br />
<br />
Der Verwalter des DDNS-Programms trägt berechtigte Benutzer und die ihnen zugeteilten Domainnamen in die Datenbank des Programms ein mit Hilfe eines kleinen Hilfsprogramms. Das ist im vorliegenden Fall ein menügesteuertes Programm für die Befehlszeile, daß die naheliegenden Funktionen anbietet: Account hinzufügen, löschen, sperren, entsperren, Paßwort setzen, ändern; Domainnamen hinzufügen, ändern, entsperren, löschen; Accounts und Domainnamen mit aktuellem Status auflisten. Die Funktionen sind auch über Befehlszeilenargumente verfügbar, also skriptfähig.<br />
<br />
Eine Übersicht der Funktionen des Administrationswerkzeugs gibt dieses selbst aus:<br />
<br />
<pre><br />
xyz00-benutzername@h02:~$ bin/ddnsadmin -h<br />
ddnsadmin.pl: Verwaltungswerkzeug für ddns<br />
<br />
Verwendung:<br />
ddnsadmin -A{[ahlusf]} [<Account>] [-f <DB-Datei>]<br />
ddnsadmin -D{[ahlsf]} [<Domain>] -A <Account> [-f <DB-Datei>]<br />
ddnsadmin -E <Einstellung> <Wert> [-f <DB-Datei>]<br />
ddnsadmin [-f <DB-Datei>] [-n]<br />
<br />
Wenn keine Option oder nur -f <DB-Datei> angegeben wird, bietet<br />
ddnsadmin.pl eine interaktive Menüoberfläche.<br />
<br />
Optionen:<br />
-f <DB-Datei> Angegebene Datenbankdatei verwenden<br />
-n Neue, leere Datenbank erzeugen<br />
-Aa [<Account>] Account(s) auflisten<br />
-Ah <Account> <Paßwort> Account hinzufügen<br />
-A{lsf} <Account> Account löschen, sperren, freigeben<br />
-Au <Account> <Name> Account umbenennen<br />
-A <Account> -Da [<Domain>] Domain(s) auflisten<br />
-A <Account> -D{hlsf} <Domain> Domain hinzufügen,<br />
löschen, sperren, freigeben<br />
-E <Einstellung> <Wert> Einstellung ändern<br />
-h Diese Übersicht ausgeben<br />
<br />
Einstellungen: <br />
maxacctabuse Anzahl der mißbräuchlichen Aufrufe,<br />
bevor ein Account gesperrt wird<br />
maxhostabuse Anzahl der mißbräuchlichen Aufrufe,<br />
bevor ein Domainname gesperrt wird<br />
safeinterval Mindestabstand zwischen redundanten Aufrufen<br />
(in Sekunden)<br />
cgihost Server, der das DDNS-Skript bereithält<br />
<br />
xyz00-benutzername@h02:~$ <br />
</pre><br />
<br />
Eine Auflistung des momentanen Inhalts der DDNS-Datenbank durch das Administrationswerkzeug könnte beispielsweise so aussehen:<br />
<br />
<pre><br />
xyz00-benutzername@h02:~$ bin/ddnsadmin.pl -Aa<br />
1. papst Mißbrauch: 0; gesperrt: nein<br />
avignon.example.com<br />
zuletzt aktiv am Sun Apr 26 22:24:49 2020<br />
mit IP-Nr. 87.65.43.21; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 0; gesperrt: nein<br />
vatican.beispiel.de<br />
zuletzt aktiv am Sun Apr 26 22:24:49 2020<br />
mit IP-Nr. 87.65.43.21; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 0; gesperrt: nein<br />
2. kaiser Mißbrauch: 4; gesperrt: ja<br />
augsburg.beispiel.de<br />
zuletzt aktiv am Fri Apr 24 16:13:49 2020<br />
mit IP-Nr. 64.82.31.75; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 0; gesperrt: ja<br />
3. luther Mißbrauch: 1; gesperrt: nein<br />
wittenberg.example.com<br />
zuletzt aktiv am Mon Apr 27 10:12:49 2020<br />
mit IP-Nr. 78.56.34.12; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 1; gesperrt: nein<br />
xyz00-benutzername@h02:~$<br />
</pre><br />
<br />
Das DDNS-Account &bdquo;kaiser&ldquo; in dieser Auflistung ist wohl auf Grund fehlerhafter Anfragen automatisch gesperrt worden. Der Inhaber wird sich wohl bald melden, um nach Korrektur seiner Client-Konfiguration die Aufhebung der Sperre zu wünschen.<br />
<br />
=== Log ===<br />
Alle Anfragen werden in einer täglich wechselnden Log-Datei protokolliert, entweder schlicht oder ausführlich, je nachdem, ob eine Variable <tt>verbose</tt> wahr ist.<br />
Ein ausführlicher Log-Eintrag sieht so aus:<br />
<br />
Sun Apr 26 20:21:45 2020 ddns aufgerufen von papst<br />
unter 84.185.97.8<br />
URL: <nowiki>https://ddns.example.com/cgi-bin/ddns.cgi?hostname=<br />
avignon.example.com,vatican.beispiel.de&<br />
myip=84.185.97.8</nowiki><br />
Verwende IP 84.185.97.8 (= 1421435144)<br />
DB-Version: 1<br />
Skript und DB exklusiv geöffnet<br />
avignon.example.com: IP: 84.185.97.8; MX: 0; Backup-MX: nein;<br />
Wildcard: nein; Mißbrauch: 0; gesperrt: nein <br />
vatican.beispiel.de: IP: 84.185.97.8; MX: 0; Backup-MX: nein;<br />
Wildcard: nein; Mißbrauch: 0; gesperrt: nein <br />
Betroffene Zonen: example.com, beispiel.de<br />
Temporärdatei example.com_hxNa.new geschrieben<br />
Zonendatei /home/pacs/xyz00/users/benutzername/doms/example.com/<br />
etc/pri.example.com eingestellt<br />
Temporärdatei beispiel.de_6HcO.new geschrieben<br />
Zonendatei /home/pacs/xyz00/users/benutzername/doms/beispiel.de/<br />
etc/pri.beispiel.de eingestellt<br />
Abgeschlossen: Fertig<br />
<br />
Wenn <tt>verbose</tt> auf falsch gesetzt ist, sind die Log-Einträge einzeilig.</div>Apc00-tonyhttps://wiki.hostsharing.net/index.php?title=Benutzer_Diskussion:Apc00-tony&diff=5362Benutzer Diskussion:Apc00-tony2021-01-12T20:19:14Z<p>Apc00-tony: </p>
<hr />
<div>Laß es raus!<br />
--[[Benutzer:Apc00-tony|Apc00-tony]] 20:45, 8. Sep. 2009 (CEST)</div>Apc00-tonyhttps://wiki.hostsharing.net/index.php?title=MySQL&diff=5235MySQL2020-06-02T16:14:49Z<p>Apc00-tony: Tote Links im Vorspann ersetzt</p>
<hr />
<div>{{Textkasten|gruen|Hinweis:|Datenbanken in der HS Kern-Dokumentation:<br />
https://doc.hostsharing.net/einstieg/datenbank.html<br />
}}<br />
<br />
== Datenbank anlegen ==<br />
<br />
erfolgt mit [https://doc.hostsharing.net/users/administration/hsadmin/index.html hsadmin] siehe [https://doc.hostsharing.net/users/administration/datenbanken/index.html Datenbanken].<br />
<br />
Datenbanknamen in MySQL beginnen bei Hostsharing immer mit dem Namen des Pakets, gefolgt von einem Unterstrich; danach folgt der frei wählbare eigentliche Name.<br />
<br />
Beispiele gültiger Datenbanken für ein Paket <b>xyz00</b>:<br />
* <b>xyz00_otto</b><br />
* <b>xyz00_anna</b><br />
* <b>xyz00_db_fuer_hans</b><br />
<br />
== Administration ==<br />
<br />
Die Administration einer Mysql-Datenbank (das Verwalten von Tabellen) erfolgt üblicherweise mit [https://phpmyadmin.hostsharing.net/current/ PhpMyAdmin]<br />
<br />
== Der MySQL Command Line Client ==<br />
<br />
Mit einem Datenbanknutzer kann auch direkt im [https://dev.mysql.com/doc/refman/5.7/en/mysql.html MySQL Command Line Client] gearbeitet werden, in dem die MySQL-Befehle eingegeben und verarbeitet werden. Der Client wird auf der [[Shell]] mit dem Befehl <b>mysql</b> aufgerufen. Es ist hier übrigens egal, ob wir als Paketadmin oder als Domainadmin eingeloggt sind, denn MySQL-User und UNIX-Accounts haben keinen Zusammenhang. Wir können mit jedem UNIX-Account, also auch als normaler Domainadmin auf jeden Datenbank-Account zugreifen – auch auf den Paketadmin-Account.<br />
<br />
Da wir uns mit Benutzernamen und Passwort anmelden müssen, verwenden wir die Optionen -u (und danach den Benutzernamen) und -p. Das Passwort geben wir nicht in dieser Kommandozeile an, denn sonst ist es für andere User sichtbar. Wenn wir nach -p nichts angeben, werden wir von mysql danach gefragt und geben es dann an.<br />
<br />
<pre><nowiki><br />
xyz00@hopi$ mysql -u xyz00_otto -p<br />
Enter password: password<br />
Welcome to the MySQL monitor. Commands end with ; or \g.<br />
Your MySQL connection id is 1257230 to server version: 3.23.49-log<br />
Type 'help;' or '\h' for help. Type '\c' to clear the buffer.<br />
mysql><br />
</nowiki></pre><br />
<br />
Nun können wir MySQL-Befehle eingeben. Zu beachten ist, dass man nach einem Kommando mit einem ; abschließen muss. Es gibt einige Ausnahmen, wo man das nicht braucht, z.B. beim Befehl QUIT, mit dem man den Client wieder verlässt.<br />
<br />
=== Rechte an der Datenbank vergeben ===<br />
<br />
Optional kann man weitere Datenbank-User anlegen, denen man nur dedizierte Rechte für die neue Datenbank erteilt. Dafür werden die normalen SQL-Befehle verwendet. Der Datenbankadmin muss sich mit Hilfe des Kommandozeilen-Werkzeugs mysql mit der Datenbank verbinden und dann die Rechte wie gewünscht vergeben:<br />
<br />
xyz00@host:~$ mysql -u xyz00-otto -p<br />
Enter password:<br />
Welcome to the MySQL ...<br />
<br />
mysql> GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, REFERENCES, INDEX, ALTER ON xyz00_beispiel.* TO xyz00_beispiel;<br />
Query OK, 0 rows affected (0.01 sec)<br />
<br />
mysql> exit<br />
Bye<br />
<br />
Mit dem obigen GRANT-Befehl werden dem Benutzer alle Rechte an der Datenbank gegeben. In der Regel wird dies nicht notwendig sein; es ist sicherer, dem Benutzer nur die tatsächlich benötigten Rechte einzuräumen. Eine Auflistung der verschiedenen Rechte befindet sich in der MySQL-Dokumentation zum GRANT-Befehl.<br />
<br />
=== Datenbank testen ===<br />
<br />
Jetzt sollte der Benutzer die Datenbank nutzen können:<br />
<br />
xyz00@host:~$ mysql -D xyz00_beispiel -u xyz00_beispiel -p<br />
Enter password:<br />
Welcome to the MySQL ...<br />
<br />
Ausprobieren, kann man dies Beispielsweise durch das Anlegen und Löschen einer Tabelle:<br />
<br />
mysql> create table test(id INT);<br />
Query OK, 0 rows affected (0.86 sec)<br />
<br />
mysql> show tables;<br />
+--------------------------+<br />
| Tables_in_xyz00_beispiel |<br />
+--------------------------+<br />
| test |<br />
+--------------------------+<br />
1 row in set<br />
<br />
mysql> drop table test;<br />
Query ok, 0 rows affected (0.00 sec)<br />
<br />
mysql> exit<br />
Bye<br />
<br />
Das Anlegen und Löschen einer Tabelle funktioniert dabei natürlich nur, wenn dem Benutzer auch tatsächlich die dafür nötigen Rechte eingeräumt wurden. In der Regel wird ein Benutzerkonto, das für die Verwendung in einer Web-Anwendung eingerichtet wurde, diese Rechte nicht benötigen. Es ist dann sicherer, diese Rechte auch nicht zu vergeben.<br />
<br />
=== Rechte vergeben ===<br />
<br />
Allen Benutzern, außer dem Datenbank-Administrator, müssen wir noch Rechte geben, sonst können sie gar nichts machen. Das erledigt man mit dem Befehl <b>GRANT</b>.<br />
<br />
<pre><nowiki><br />
mysql>GRANT SELECT, INSERT, DELETE, UPDATE ON xyz00_meinedatenbank.* TO xyz00_otto;<br />
</nowiki></pre><br />
<br />
Hinter der Datenbank verwenden wir .*, um alle Tabellen der Datenbank zu inkludieren. <br />
<br />
Mit <b>GRANT ALL</b> kann man einem User auch alle Kommandorechte zuweisen.<br />
<br />
Alle Aufgaben können wir jetzt in Zukunft vom User <b>xyz00_otto</b> erledigen lassen.<br />
<br />
=== Import eines Mysql-Dump in eine leere Datenbank ===<br />
<br />
Wurde eine Mysql Datenbank in eine Datei exportiert (als eine Folge von SQL-Befehle in einer Textdatei, hier mit dem Namen backup_xyz.sql) , kann sie mit folgendem Befehl auf der Shell in die Datenbank xyz00_beispiel des Benutzers xyz00_beispiel importiert werden:<br />
<br />
mysql --user xyz00_beispiel -p xyz00_beispiel < backup_xyz00_beispiel.sql<br />
<br />
=== Export einer Mysql Datenbank in eine Textdatei ===<br />
<br />
Um eine Datenbank auf der Shell in eine Textdatei zu exportieren, dient dieser Befehl:<br />
mysqldump --user xyz00_beispiel -p xyz00_beispiel > backup_xyz00_beispiel.sql<br />
<br />
== Verschiedenes ==<br />
<br />
* Web-Frontend: [http://www.phpmyadmin.net phpMyAdmin] ist unter https://phpmyadmin.hostsharing.net/current erreichbar.<br />
* Online-Dokumentation: Die Online-Doku zu MySQL gibt es unter http://dev.mysql.com/doc/. Auf dieser Site gibt es auch mehrere Fassungen der kompletten Doku zum Downloaden.<br />
<br />
<br />
----<br />
[[Kategorie:HSDoku]]<br />
[[Kategorie:Datenbanken]]<br />
[[Kategorie:Mysql]]</div>Apc00-tonyhttps://wiki.hostsharing.net/index.php?title=Mailman_Installieren&diff=5226Mailman Installieren2020-05-14T20:37:34Z<p>Apc00-tony: <tt> und <nowiki></p>
<hr />
<div>== Vorab: Die Wahl von Mailman 2 ==<br />
<br />
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.]<br />
<br />
== Mailman 2 installieren == <br />
<br />
(zuletzt getestet mit mailman-2.1.29; Installation durch Paketuser)<br />
<br />
Vielen Dank an alle Benutzer, die Verbesserungen beisteuern!<br />
<br />
=== Unter welchem Account installieren? ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Nachteil der Installation als Paketuser ist lediglich, dass die Paketdomain mit dem SSL Zertifikat von Hostsharing nicht genutzt werden kann.<!-- Aktualisieren? --><br />
<br />
=== Einen User und eine Domain anlegen ===<br />
<br />
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.<br />
<br />
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:<br />
<br />
~$ echo "" > ~/doms/listen.example.com/htdocs-ssl/.htaccess<br />
<br />
Die Default-Subdomains www.* löschen:<br />
<br />
~$ rm -r doms/listen.example.com/subs/www/<br />
~$ rm -r doms/listen.example.com/subs-ssl/www/<br />
<br />
=== Sourcen besorgen und entpacken ===<br />
<br />
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 ...<br />
<br />
~$ wget http://ftp.gnu.org/gnu/mailman/mailman-2.1.29.tgz<br />
<br />
... und entpacken:<br />
<br />
~$ tar -xzvf mailman-2.1.29.tgz<br />
<br />
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.)<br />
<br />
=== var-Verzeichnis für Log-Dateien anlegen ===<br />
<br />
Bei der Installation als Paketuser (xyz00-listen):<br />
~$ cd && mkdir -p mailman/var<br />
~$ chmod 02775 mailman/var<br />
<br />
Bei der Installation als Paketadmin (xyz00):<br />
~$ cd && mkdir var/mailman<br />
~$ chmod 02775 var/mailman<br />
<br />
=== Mailman konfigurieren ===<br />
<br />
In das Source-Verzeichnis wechseln:<br />
<br />
~$ cd mailman-2.1.29<br />
<br />
Bei der Installation durch den Paketuser (xyz00-listen):<br />
~/mailman-2.1.29$ ./configure --prefix=/home/pacs/xyz00/users/listen/mailman \<br />
--with-username=xyz00-listen \<br />
--with-groupname=xyz00 \<br />
--with-var-prefix=/home/pacs/xyz00/users/listen/mailman/var \<br />
--with-cgi-gid=xyz00 \<br />
--with-mail-gid=xyz00<br />
<br />
Bei der Installation durch den Paketadmin (xyz00):<br />
~/mailman-2.1.29$ ./configure --prefix=/home/pacs/xyz00/mailman \<br />
--with-username=xyz00 \<br />
--with-groupname=xyz00 \<br />
--with-var-prefix=/home/pacs/xyz00/var/mailman \<br />
--with-cgi-gid=xyz00 \<br />
--with-mail-gid=nogroup<br />
<br />
(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.)<br />
<br />
=== Mailman kompilieren ===<br />
<br />
~/mailman-2.1.29$ make<br />
~/mailman-2.1.29$ make install<br />
<br />
=== Datenrechte prüfen ===<br />
<br />
Sicherheitshalber die Dateirechte durch Mailmans mitgeliefertes Tool prüfen und ggf. korrigieren lassen:<br />
<br />
~/mailman-2.1.29$ cd .. <br />
~$ mailman/bin/check_perms -f<br />
<br />
== Die neue Mailman-Installation konfigurieren ==<br />
<br />
=== Konfigurationsdatei <tt>mm_cfg.py</tt> editieren ===<br />
<br />
~$ nano mailman/Mailman/mm_cfg.py<br />
<br />
Eine Beispielkonfiguration für listen.example.com könnte so aussehen:<br />
<br />
[...]<br />
##################################################<br />
# Put YOUR site-specific settings below this line.<br />
# -*- python -*-<br />
<br />
DEFAULT_HOST_NAME = 'listen.example.com'<br />
DEFAULT_EMAIL_HOST = 'listen.example.com'<br />
DEFAULT_URL_HOST = 'listen.example.com'<br />
add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)<br />
add_virtualhost(zweite.listendomain.com, zweite.listendomain.com)<br />
<br />
DEFAULT_SERVER_LANGUAGE = 'de'<br />
<br />
DEFAULT_URL_PATTERN = 'http://%s/'<br />
<br />
# Es wird der HS Mailversand für Bulkmail verwendet:<br />
SMTPHOST = 'localhost'<br />
SMTPPORT = 4587 <br />
SMTP_AUTH = True<br />
SMTP_USER = 'xyz00-listen'<br />
SMTP_PASSWD = 'das-passwort-des-o.-g.-users'<br />
SMTP_USE_TLS = True<br />
<br />
<br />
In <tt>~/mailman/Mailman/Defaults.py</tt> sieht man, was in mm_cfg.py alles angepasst werden kann.<br />
<br />
=== CGI-Programme in die Domain kopieren ===<br />
<br />
Bei der Installation als Paketuser (xyz00-listen):<br />
<br />
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.<br />
<br />
~$ mkdir ~/doms/listen.example.com/cgi-ssl/mailman<br />
~$ cp mailman/cgi-bin/* doms/listen.example.com/cgi-ssl/mailman/<br />
<br />
Zusätzlich muss das sticky-Flag von den kopierten Dateien entfernt werden:<br />
<br />
~$ chmod g-s ~/doms/listen.example.com/cgi/mailman/*<br />
<br />
Bei der Installation als Paketadmin (xyz00): <br />
<br />
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: <br />
<br />
~$ cd doms/listen.example.com/cgi-ssl<br />
~/doms/listen.example.com/cgi-ssl$ ln -s ../../../mailman/cgi-bin mailman<br />
<br />
=== Mailman-Icons in die Domains kopieren ===<br />
<br />
Die Icons können wahlweise verlinkt oder kopiert werden:<br />
<br />
~$ cd doms/listen.example.com/htdocs-ssl<br />
~/doms/listen.example.com/htdocs-ssl$ ln -s ../../../mailman/icons<br />
<br />
oder<br />
<br />
~$ cp -R mailman/icons doms/listen.example.com/htdocs-ssl/<br />
<br />
=== Die Datei .htaccess bearbeiten ===<br />
<br />
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.<br />
<br />
Dazu werden in <tt><nowiki>~/doms/listen.example.com/htdocs-ssl/.htaccess</nowiki></tt> folgende Rewrite-Anweisungen eintragen.<br />
<br />
RewriteEngine On<br />
RewriteCond %{REQUEST_URI} !^/icons/<br />
RewriteRule ^(.*)$ /cgi-bin/mailman/$1<br />
RewriteRule ^/cgi-bin/mailman/$ /cgi-bin/mailman/listinfo<br />
<br />
Beachte dabei die zweite Zeile: Anfragen für Icons sollen ''nicht'' umgeschrieben werden.<br />
<br />
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>:<br />
<br />
RewriteEngine On<br />
RewriteCond %{REQUEST_URI} !^/icons/<br />
RewriteRule ^mailman/(.*)$ /cgi-bin/mailman/$1<br />
RewriteRule ^/cgi-bin/mailman/$ /cgi-bin/mailman/listinfo<br />
<br />
(In diesem Fall kann die Zeile <tt>DEFAULT_URL_PATTERN...</tt> in der <tt>mm_cfg.py</tt> auskommentiert werden.)<br />
<br />
=== Hauptpasswort setzen ===<br />
<br />
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: <br />
<br />
~$ mailman/bin/mmsitepass<br />
<br />
=== Cronjobs einrichten ===<br />
<br />
In die [[Cron |Crontab]] werden Befehle eingetragen, um die Mail-Warteschlange abzuarbeiten, Logs zu löschen, usw.:<br />
<br />
# Warteschlange jede Minute bearbeiten:<br />
* * * * * ~/mailman/bin/qrunner -o -r All<br />
# Verarbeitungslogs in der 47ten Minute jeder Stunde löschen:<br />
47 * * * * rm -f ~/var/mailman/logs/qrunner<br />
<br />
Damit übernimmt cron die Funktion des qrunner-Dämons, der normalerweise auf einem Mailman-Server laufen sollte.<br />
<br />
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:<br />
<br />
47 * * * * rm -f ~/mailman/var/logs/qrunner<br />
<br />
... entsprechend dem beim Konfigurieren angegebenen <tt>var</tt>-Verzeichnis, siehe oben.<br />
<br />
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:<br />
<br />
crontab -l > mycronjobs.tmp<br />
cat ~/mailman/cron/crontab.in >> mycronjobs.tmp<br />
crontab mycronjobs.tmp<br />
<br />
== Mailinglisten einrichten ==<br />
<br />
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 <br />
<br />
MAILMAN_SITE_LIST = 'sitelistname'<br />
<br />
in der Konfigurationsdatei <tt>mailman/Mailman/mm_cfg.py</tt> eingetragen werden.<br />
<br />
=== Den Hauptverteiler "mailman" anlegen ===<br />
<br />
Die "site list" mit dem Namen "mailman" ist die Mailingliste der lokalen Mailman-Administratoren. Sie wird zur einwandfreien Funktion von Mailman benötigt.<br />
<br />
Mit dem Mailman-Befehl newlist den Verteiler anlegen:<br />
<br />
~$ mailman/bin/newlist mailman<br />
Enter the email of the person running the list: admin@xyz00.hostsharing.net<br />
Initial mailman password:<br />
<br />
(Der Befehl newlist kann – alternativ zur Weboberfläche – später benutzt werden, um gewöhnliche Mailinglisten anzulegen.)<br />
<br />
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.)<br />
<br />
Falls mailman vom Paketuser (bspw. "xyz00-listen") installiert wurde:<br />
<br />
~$ mailman/bin/config_list -i ~/mailman/var/data/sitelist.cfg mailman<br />
<br />
Falls mailman vom Paketadmin ("xyz00") installiert wurde:<br />
<br />
~$ mailman/bin/config_list -i ~/var/mailman/data/sitelist.cfg mailman<br />
<br />
Diese Konfigurationsdatei soll '''nicht''' auf gewöhnliche Mailinglisten anwendet werden.<br />
<br />
=== E-Mail Adressen bei Mailman einrichten ===<br />
<br />
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. <br />
<br />
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.<br />
<br />
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.)<br />
<br />
hsscript -u xyz00 -i<br />
[hsscript verlangt die Eingabe des Passworts vom Paketadmin xyz00; dann können diese Befehle eingegeben werden:]<br />
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman',target:'xyz00-listen+mailman'}})<br />
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-admin',target:'xyz00-listen+mailman-admin'}})<br />
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-bounces',target:'xyz00-listen+mailman-bounces'}})<br />
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-confirm',target:'xyz00-listen+mailman-confirm'}})<br />
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-join',target:'xyz00-listen+mailman-join'}})<br />
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-leave',target:'xyz00-listen+mailman-leave'}})<br />
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-owner',target:'xyz00-listen+mailman-owner'}})<br />
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-request',target:'xyz00-listen+mailman-request'}})<br />
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-subscribe',target:'xyz00-listen+mailman-subscribe'}})<br />
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-unsubscribe',target:'xyz00-listen+mailman-unsubscribe'}})<br />
<br />
Die korrekte Einrichtung der E-Mail-Adressen kann in der Web-Oberfläche von hsadmin kontrolliert werden.<br />
<br />
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:<br />
<br />
"|/home/pacs/xyz00/users/listen/mailman/mail/mailman [Befehl] [Listenname]"<br />
<br />
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.<br />
<br />
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.)<br />
<br />
echo 'admin@xyz00.hostsharing.net' > .forward # Weiterleitung von cron Fehlern etc an Paketadmin.<br />
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman post mailman"' > .forward+mailman<br />
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman admin mailman"' > .forward+mailman-admin<br />
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman bounces mailman"' > .forward+mailman-bounces<br />
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman confirm mailman"' > .forward+mailman-confirm<br />
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman join mailman"' > .forward+mailman-join<br />
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman leave mailman"' > .forward+mailman-leave<br />
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman owner mailman"' > .forward+mailman-owner<br />
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman request mailman"' > .forward+mailman-request<br />
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman subscribe mailman"' > .forward+mailman-subscribe<br />
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman unsubscribe mailman"' > .forward+mailman-unsubscribe<br />
<br />
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:<br />
<br />
#!/bin/sh<br />
# .forward-Dateien für einen Verteiler unter Mailman einrichten.<br />
#<br />
if [ "$1" = "" ] ; then<br />
echo "Aufruf: $0 Listenname\n" <br />
exit<br />
fi<br />
if [ "$2" != "" ] ; then<br />
echo "Aufruf: $0 Listenname\n" <br />
exit<br />
fi<br />
if [ "`pwd`" != "`echo ~`" ] ; then<br />
echo "Diesen Befehl vom Home-Verzeichnis aus aufrufen.\n" <br />
exit<br />
fi<br />
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman post $1\"" > .forward+$1<br />
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman admin $1\"" > .forward+$1-admin<br />
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman bounces $1\"" > .forward+$1-bounces<br />
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman confirm $1\"" > .forward+$1-confirm<br />
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman join $1\"" > .forward+$1-join<br />
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman leave $1\"" > .forward+$1-leave<br />
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman owner $1\"" > .forward+$1-owner<br />
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman request $1\"" > .forward+$1-request<br />
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman subscribe $1\"" > .forward+$1-subscribe<br />
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman unsubscribe $1\"" > .forward+$1-unsubscribe<br />
exit<br />
<br />
Der Skript muß natürlich als ausführbar gekennzeichnet werden:<br />
<br />
~$ chmod u+x bin/addforwards<br />
<br />
Die Erweiterung dieses Skripts um die <tt>hsscript</tt>-Befehle wird dem geneigten Leser als Aufgabe überlassen.<br />
<br />
=== Administration ===<br />
<br />
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.<br />
<br />
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:<br />
<br />
~$ mailman/bin/newlist <Listenname><br />
<br />
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.<br />
<br />
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].<br />
<br />
== Feintuning == <br />
<br />
Wer will, kann auch noch etwas Platz sparen. Die normale Mailmaninstallation schlägt mit über 20 MB zu Buche...<br />
<br />
Mit den folgenden Tips kann man das auf ca. 6 MB reduzieren :)<br />
<br />
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!<br />
<br />
* ~/mailman/cgi-bin und ~/mailman/icons können gelöscht werden, falls sie an andere Stelle kopiert worden sind.<br />
* Die nicht benötigten Sprachen in ~/mailman/messages löschen.<br />
* Die nicht benötigten Sprachen in ~/mailman/templates löschen (bis auf englisch).<br />
* ~/mailman/tests kann, soweit ich das sehe, komplett gelöscht werden.<br />
* Falls man koreanisch und japanisch nicht braucht, kann man folgendes machen:<br />
* in ~/mailman/bin/paths.py, ~/mailman/cron/paths.py und ~/mailman/scripts/paths.py die Zeilen:<br />
<br />
# In a normal interactive Python environment, the japanese.pth and korean.pth<br />
# files would be imported automatically. But because we inhibit the importing<br />
# of the site module, we need to be explicit about importing these codecs.<br />
if not jaok:<br />
import japanese<br />
# As of KoreanCodecs 2.0.5, you had to do the second import to get the Korean<br />
# codecs installed, however leave the first import in there in case an upgrade<br />
# changes this.<br />
if not kook:<br />
import korean<br />
import korean.aliases<br />
<br />
auskommentieren.<br />
<br />
Dann kann man ~/mailman/pythonlib/japanese, ~/mailman/pythonlib/korean, ~/mailman/pythonlib/korean.pth sowie ~/mailman/pythonlib/lib löschen.<br />
<br />
Man kann auch noch die Debug-Informationen aus den binaries strippen:<br />
<br />
strip ~/mailman/mail/mailman<br />
strip ~/mailman/cgi-bin/*<br />
<br />
Falls die CGIs nicht gesymlinkt wurden:<br />
<br />
strip ~/doms/listen.example.com/cgi/mailman/*<br />
<br />
== Multidomainfähigkeit ==<br />
<br />
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.<br />
<br />
=== Anleitung ===<br />
<br />
Logischerweise muss das Webfrontend (die CGIs) auf allen Domains installiert werden.<br />
<br />
Wenn man nun Mailinglisten mit newlist neu anlegt, muss man den Hostnamen für das Webfontend mit angeben, und zwar so:<br />
<br />
~$ mailman/bin/newlist listenname@listen.example.com<br />
<br />
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.)<br />
<br />
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:<br />
<br />
Also z.B.<br />
DEFAULT_URL_HOST = 'www.example.com'<br />
DEFAULT_EMAIL_HOST = 'listen.example.com'<br />
add_virtualhost(DEFAULT_URL_HOST,DEFAULT_EMAIL_HOST)<br />
<br />
und<br />
add_virtualhost('www.zoopnet.de', 'lists.zoopnet.de')<br />
<br />
Das bedeutet, dass Mailman per default davon ausgeht, dass alle Listen für die Domain example.com sind.<br />
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.<br />
<br />
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.<br />
<br />
<br />
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. :)<br />
<br />
=== Probleme ===<br />
<br />
Verschiedene Listen mit gleichem Namen (also z.B. liste@example1.com und liste@example2.com) sind mit Mailman 2.1 leider nicht möglich.<br />
<br />
<br />
== Tips und Tricks ==<br />
<br />
=== URL Änderungen ===<br />
Nach URL Änderungen stimmen Links im Web-Interface nicht mehr und Listen werden nicht mehr angezeigt.<br />
Es sind dann, zusätzlich zur Anpassung der mm_cfg.py, schon bestehende Listen und Archive mit folgendem Befehl zu aktualisieren:<br />
~/mailman/bin/withlist -l -r fix_url <Listen_Name> -v -u <Neue_Url><br />
<Listen_Name> steht für die Mailingliste, die bearbeitet werden soll. <Neue_Url> für die neue URL/Webadresse des Webinterfaces.<br />
<br />
=== Weitere Cron-Jobs zur Mailinglisten Verwaltung ===<br />
<br />
Folgende Cronjobs helfen bei der Verwaltung und sind User freundlich:<br />
<br />
< In Arbeit ><br />
<br />
== Referenzen ==<br />
<br />
Lösung zur installation als Domainadmin (xyz00-listen) statt Paketadmin (xyz00): https://lists.hostsharing.net/archiv/support/2009-June/019414.html<br><br />
<br />
Ältere Anleitung für Installation als Domain-Admin (xyz00-listen): <http://lists.hostsharing.net/archiv/support/2005-January/012426.html><br><br />
<br />
"Kleine Tools" auf http://hs.andreasloesch.de/, wobei das 'pac-mm-install' wahrscheinlich nicht aktuell (genug) ist<br><br />
<br />
----<br />
[[Kategorie:HSDoku]]<br />
[[Kategorie:Installationsanleitungen]]<br />
[[Kategorie:Software]]<br />
[[Kategorie:Mailinglisten]]<br />
[[Kategorie:E-Mail]]</div>Apc00-tonyhttps://wiki.hostsharing.net/index.php?title=Mailman_Installieren&diff=5225Mailman Installieren2020-05-14T16:29:45Z<p>Apc00-tony: /* E-Mail Adressen bei Mailman einrichten */</p>
<hr />
<div>== Vorab: Die Wahl von Mailman 2 ==<br />
<br />
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.]<br />
<br />
== Mailman 2 installieren == <br />
<br />
(zuletzt getestet mit mailman-2.1.29; Installation durch Paketuser)<br />
<br />
Vielen Dank an alle Benutzer, die Verbesserungen beisteuern!<br />
<br />
=== Unter welchem Account installieren? ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Nachteil der Installation als Paketuser ist lediglich, dass die Paketdomain mit dem SSL Zertifikat von Hostsharing nicht genutzt werden kann.<!-- Aktualisieren? --><br />
<br />
=== Einen User und eine Domain anlegen ===<br />
<br />
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.<br />
<br />
Mit [[Login_mit_SSH|SSH]] an hostsharing.net als xyz00-listen anmelden. Die Redirect-Zeile aus ~/doms/listen.example.com/htdocs-ssl/.htaccess löschen:<br />
<br />
~$ echo "" > ~/doms/listen.example.com/htdocs-ssl/.htaccess<br />
<br />
Die Default-Subdomains www.* löschen:<br />
<br />
~$ rm -r doms/listen.example.com/subs/www/<br />
~$ rm -r doms/listen.example.com/subs-ssl/www/<br />
<br />
=== Sourcen besorgen und entpacken ===<br />
<br />
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 ...<br />
<br />
~$ wget http://ftp.gnu.org/gnu/mailman/mailman-2.1.29.tgz<br />
<br />
... und entpacken:<br />
<br />
~$ tar -xzvf mailman-2.1.29.tgz<br />
<br />
Ab diesem Augenblick gibt es ein Verzeichnis namens mailman-2.1.29/. 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 mailman/ liegen. (Dieses Verzeichnis wird beim Konfigurieren der Source als "prefix" angegeben.)<br />
<br />
=== var-Verzeichnis für Log-Dateien anlegen ===<br />
<br />
Bei der Installation als Paketuser (xyz00-listen):<br />
~$ cd && mkdir -p mailman/var<br />
~$ chmod 02775 mailman/var<br />
<br />
Bei der Installation als Paketadmin (xyz00):<br />
~$ cd && mkdir var/mailman<br />
~$ chmod 02775 var/mailman<br />
<br />
=== Mailman konfigurieren ===<br />
<br />
In das Source-Verzeichnis wechseln:<br />
<br />
~$ cd mailman-2.1.29<br />
<br />
Bei der Installation als Paketuser (xyz00-listen):<br />
~/mailman-2.1.29$ ./configure --prefix=/home/pacs/xyz00/users/listen/mailman \<br />
--with-username=xyz00-listen \<br />
--with-groupname=xyz00 \<br />
--with-var-prefix=/home/pacs/xyz00/users/listen/mailman/var \<br />
--with-cgi-gid=xyz00 \<br />
--with-mail-gid=xyz00<br />
<br />
Bei der Installation als Paketadmin (xyz00):<br />
~/mailman-2.1.29$ ./configure --prefix=/home/pacs/xyz00/mailman \<br />
--with-username=xyz00 \<br />
--with-groupname=xyz00 \<br />
--with-var-prefix=/home/pacs/xyz00/var/mailman \<br />
--with-cgi-gid=xyz00 \<br />
--with-mail-gid=nogroup<br />
<br />
(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.)<br />
<br />
=== Mailman kompilieren ===<br />
<br />
~/mailman-2.1.29$ make<br />
~/mailman-2.1.29$ make install<br />
<br />
=== Datenrechte prüfen ===<br />
<br />
Sicherheitshalber die Dateirechte durch Mailmans mitgeliefertes Tool prüfen und ggf. korrigieren lassen:<br />
<br />
~/mailman-2.1.29$ cd .. <br />
~$ mailman/bin/check_perms -f<br />
<br />
== Die neue Mailman-Installation konfigurieren ==<br />
<br />
=== Konfigurationsdatei mm_cfg.py editieren ===<br />
<br />
~$ nano mailman/Mailman/mm_cfg.py<br />
<br />
Eine Beispielkonfiguration für listen.example.com könnte so aussehen:<br />
<br />
[...]<br />
##################################################<br />
# Put YOUR site-specific settings below this line.<br />
# -*- python -*-<br />
<br />
DEFAULT_HOST_NAME = 'listen.example.com'<br />
DEFAULT_EMAIL_HOST = 'listen.example.com'<br />
DEFAULT_URL_HOST = 'listen.example.com'<br />
add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)<br />
add_virtualhost(zweite.listendomain.com, zweite.listendomain.com)<br />
<br />
DEFAULT_SERVER_LANGUAGE = 'de'<br />
<br />
DEFAULT_URL_PATTERN = 'http://%s/'<br />
<br />
# Es wird der HS Mailversand für Bulkmail verwendet:<br />
SMTPHOST = 'localhost'<br />
SMTPPORT = 4587 <br />
SMTP_AUTH = True<br />
SMTP_USER = 'xyz00-listen'<br />
SMTP_PASSWD = 'das-passwort-des-o.-g.-users'<br />
SMTP_USE_TLS = True<br />
<br />
<br />
In ~/mailman/Mailman/Defaults.py sieht man, was in mm_cfg.py alles angepasst werden kann.<br />
<br />
=== CGI-Programme in die Domain kopieren ===<br />
<br />
Bei der Installation als Paketuser (xyz00-listen):<br />
<br />
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.<br />
<br />
~$ mkdir ~/doms/listen.example.com/cgi-ssl/mailman<br />
~$ cp mailman/cgi-bin/* doms/listen.example.com/cgi-ssl/mailman/<br />
<br />
Zusätzlich muss das sticky-Flag von den kopierten Dateien entfernt werden:<br />
<br />
~$ chmod g-s ~/doms/listen.example.com/cgi/mailman/*<br />
<br />
Bei der Installation als Paketadmin (xyz00): <br />
<br />
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: <br />
<br />
~$ cd doms/listen.example.com/cgi-ssl<br />
~/doms/listen.example.com/cgi-ssl$ ln -s ../../../mailman/cgi-bin mailman<br />
<br />
=== Mailman-Icons in die Domains kopieren ===<br />
<br />
Die Icons können wahlweise verlinkt oder kopiert werden:<br />
<br />
~$ cd doms/listen.example.com/htdocs-ssl<br />
~/doms/listen.example.com/htdocs-ssl$ ln -s ../../../mailman/icons<br />
<br />
oder<br />
<br />
~$ cp -R mailman/icons doms/listen.example.com/htdocs-ssl/<br />
<br />
=== Die Datei .htaccess bearbeiten ===<br />
<br />
Bei einer dedizierten Mailman-Domain sollte man dafür sorgen, dass Mailman nicht nur unter https://listen.example.com/cgi-bin/mailman, sondern auch unter https://listen.example.com erreichbar ist.<br />
<br />
Dazu werden in ~/doms/listen.example.com/htdocs-ssl/.htaccess folgende Rewrite-Anweisungen eintragen.<br />
<br />
RewriteEngine On<br />
RewriteCond %{REQUEST_URI} !^/icons/<br />
RewriteRule ^(.*)$ /cgi-bin/mailman/$1<br />
RewriteRule ^/cgi-bin/mailman/$ /cgi-bin/mailman/listinfo<br />
<br />
Beachte dabei die zweite Zeile: Anfragen für Icons sollen ''nicht'' umgeschrieben werden.<br />
<br />
Wenn Mailman z.B. auf einer als Unterverzeichnis angelegten Subdomain läuft und unter https://www.example.com/mailman statt https://www.example.com/cgi-bin/mailman erreichbar sein soll, hilft folgendes in der ~/doms/example.com/subs-ssl/www/.htaccess:<br />
<br />
RewriteEngine On<br />
RewriteCond %{REQUEST_URI} !^/icons/<br />
RewriteRule ^mailman/(.*)$ /cgi-bin/mailman/$1<br />
RewriteRule ^/cgi-bin/mailman/$ /cgi-bin/mailman/listinfo<br />
<br />
(In diesem Fall kann die Zeile DEFAULT_URL_PATTERN... in der mm_cfg.py auskommentiert werden.)<br />
<br />
=== Hauptpasswort setzen ===<br />
<br />
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: <br />
<br />
~$ mailman/bin/mmsitepass<br />
<br />
=== Cronjobs einrichten ===<br />
<br />
In die [[Cron |Crontab]] werden Befehle eingetragen, um die Mail-Warteschlange abzuarbeiten, Logs zu löschen, usw.:<br />
<br />
# Warteschlange jede Minute bearbeiten:<br />
* * * * * ~/mailman/bin/qrunner -o -r All<br />
# Verarbeitungslogs in der 47ten Minute jeder Stunde löschen:<br />
47 * * * * rm -f ~/var/mailman/logs/qrunner<br />
<br />
Damit übernimmt cron die Funktion des qrunner-Dämons, der normalerweise auf einem Mailman-Server laufen sollte.<br />
<br />
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:<br />
<br />
47 * * * * rm -f ~/mailman/var/logs/qrunner<br />
<br />
... entsprechend dem beim Konfigurieren angegebenen var-Verzeichnis, siehe oben.<br />
<br />
Zudem müssen noch die von Mailman ohnehin vorgesehenen cron-Aufträge aus ~/mailman/cron/crontab.in dem crontab des Users angehängt werden:<br />
<br />
crontab -l > mycronjobs.tmp<br />
cat ~/mailman/cron/crontab.in >> mycronjobs.tmp<br />
crontab mycronjobs.tmp<br />
<br />
== Mailinglisten einrichten ==<br />
<br />
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 <br />
<br />
MAILMAN_SITE_LIST = 'sitelistname'<br />
<br />
in der Konfigurationsdatei mailman/Mailman/mm_cfg.py eingetragen werden.<br />
<br />
=== Den Hauptverteiler "mailman" anlegen ===<br />
<br />
Die "site list" mit dem Namen "mailman" ist die Mailingliste der lokalen Mailman-Administratoren. Sie wird zur einwandfreien Funktion von Mailman benötigt.<br />
<br />
Mit dem Mailman-Befehl newlist den Verteiler anlegen:<br />
<br />
~$ mailman/bin/newlist mailman<br />
Enter the email of the person running the list: admin@xyz00.hostsharing.net<br />
Initial mailman password:<br />
<br />
(Der Befehl newlist kann – alternativ zur Weboberfläche – später benutzt werden, um gewöhnliche Mailinglisten anzulegen.)<br />
<br />
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.)<br />
<br />
Falls mailman vom Paketuser (bspw. "xyz00-listen") installiert wurde:<br />
<br />
~$ mailman/bin/config_list -i ~/mailman/var/data/sitelist.cfg mailman<br />
<br />
Falls mailman vom Paketadmin ("xyz00") installiert wurde:<br />
<br />
~$ mailman/bin/config_list -i ~/var/mailman/data/sitelist.cfg mailman<br />
<br />
Diese Konfigurationsdatei soll '''nicht''' auf gewöhnliche Mailinglisten anwendet werden.<br />
<br />
=== E-Mail Adressen bei Mailman einrichten ===<br />
<br />
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 xyz00-listen'''+'''<liste>[_funktion]. 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. <br />
<br />
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.<br />
<br />
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.)<br />
<br />
hsscript -u xyz00 -i<br />
[hsscript verlangt die Eingabe des Passworts vom Paketadmin xyz00; dann können diese Befehle eingegeben werden:]<br />
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman',target:'xyz00-listen+mailman'}})<br />
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-admin',target:'xyz00-listen+mailman-admin'}})<br />
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-bounces',target:'xyz00-listen+mailman-bounces'}})<br />
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-confirm',target:'xyz00-listen+mailman-confirm'}})<br />
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-join',target:'xyz00-listen+mailman-join'}})<br />
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-leave',target:'xyz00-listen+mailman-leave'}})<br />
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-owner',target:'xyz00-listen+mailman-owner'}})<br />
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-request',target:'xyz00-listen+mailman-request'}})<br />
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-subscribe',target:'xyz00-listen+mailman-subscribe'}})<br />
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-unsubscribe',target:'xyz00-listen+mailman-unsubscribe'}})<br />
<br />
Die korrekte Einrichtung der E-Mail-Adressen kann in der Web-Oberfläche von hsadmin kontrolliert werden.<br />
<br />
Für jede der soeben eingerichteten Adressen wird nun eine .forward-Datei im Homeverzeichnis des Users xyz00-listen angelegt. Die Dateinamen bestehen aus der Zeichenfolge ".forward+" gefolgt vom Namen der ausführen soll. Der Inhalt der jeweiligen .forward-Datei legt die Weiterleitung der Mail durch einen Pipe an Mailman fest, mit dem jeweiligen Befehl als Argument:<br />
<br />
"|/home/pacs/xyz00/users/listen/mailman/mail/mailman [Befehl] [Listenname]"<br />
<br />
Zum Beispiel wird die .forward-Datei .forward+mailman-subscribe verwendet, wenn eine E-Mail an die Adresse mailman-subscribe@listen.example.com eingeht. Aufgrund der oben eingerichteten E-Mail-Adresse mit dem Ziel "xyz00-listen+mailman-subscribe" wertet der Mail-Transfer-Agent die .forward-Datei .forward+mailman-subscribe 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.<br />
<br />
Das folgende Beispiel zeigt die Befehle, mit denen an der Befehlszeilenaufforderung der Shell die .forward-Dateien für die Hauptliste "mailman" eingerichtet werden. (Für spätere Mailinglisten wird in den Argumenten und in den Namen der .forward-Dateien "mailman" durch den Namen der Mailingliste ersetzt, jedoch '''nicht''' in der Pfadangabe zum Mailman-Programm selbst; diese ändert sich ja nicht.)<br />
<br />
echo 'admin@xyz00.hostsharing.net' > .forward # Weiterleitung von cron Fehlern etc an Paketadmin.<br />
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman post mailman"' > .forward+mailman<br />
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman admin mailman"' > .forward+mailman-admin<br />
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman bounces mailman"' > .forward+mailman-bounces<br />
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman confirm mailman"' > .forward+mailman-confirm<br />
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman join mailman"' > .forward+mailman-join<br />
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman leave mailman"' > .forward+mailman-leave<br />
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman owner mailman"' > .forward+mailman-owner<br />
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman request mailman"' > .forward+mailman-request<br />
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman subscribe mailman"' > .forward+mailman-subscribe<br />
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman unsubscribe mailman"' > .forward+mailman-unsubscribe<br />
<br />
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 ~/bin/addforwards mit folgendem Inhalt zu erstellen:<br />
<br />
#!/bin/sh<br />
# .forward-Dateien für einen Verteiler unter Mailman einrichten.<br />
#<br />
if [ "$1" = "" ] ; then<br />
echo "Aufruf: $0 Listenname\n" <br />
exit<br />
fi<br />
if [ "$2" != "" ] ; then<br />
echo "Aufruf: $0 Listenname\n" <br />
exit<br />
fi<br />
if [ "`pwd`" != "`echo ~`" ] ; then<br />
echo "Diesen Befehl vom Home-Verzeichnis aus aufrufen.\n" <br />
exit<br />
fi<br />
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman post $1\"" > .forward+$1<br />
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman admin $1\"" > .forward+$1-admin<br />
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman bounces $1\"" > .forward+$1-bounces<br />
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman confirm $1\"" > .forward+$1-confirm<br />
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman join $1\"" > .forward+$1-join<br />
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman leave $1\"" > .forward+$1-leave<br />
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman owner $1\"" > .forward+$1-owner<br />
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman request $1\"" > .forward+$1-request<br />
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman subscribe $1\"" > .forward+$1-subscribe<br />
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman unsubscribe $1\"" > .forward+$1-unsubscribe<br />
exit<br />
<br />
Der Skript muß natürlich als ausführbar gekennzeichnet werden:<br />
<br />
~$ chmod u+x bin/addforwards<br />
<br />
Die Erweiterung dieses Skripts um die hsscript-Befehle wird dem Leser als Aufgabe überlassen.<br />
<br />
=== Administration ===<br />
<br />
Als erstes sollte man als Administrator der neuen Mailman-Installation die Liste "mailman" selbst abonnieren. Die Liste "mailman" kann aber unter https://listen.example.com/mailman/admin/mailman verwaltet werden.<br />
<br />
Die Hauptseite der Mailman-Web-Verwaltung ist in unserem Beispiel (mit den oben angegebenen Rewrite-Anweisungen in der Datei .htaccess) https://listen.example.com/mailman/admin/. Diese Seite enthält Links zu den bisher eingerichteten Mailinglisten (außer "mailman") und einen Link, um neue Mailinglisten anzulegen (https://listen.example.com/mailman/create). Das Anlegen einer neuen Mailingliste geschieht entweder über diesen Link oder (wie oben) in der Shell mit dem Befehl:<br />
<br />
~$ mailman/bin/newlist <Listenname><br />
<br />
In beiden Fällen müssen zusätzlich die E-Mail-Adressen und die .forward-Dateien wie bei dem Einrichten der Liste "mailman" nach Verfahren im obigen Abschnitt angelegt werden.<br />
<br />
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].<br />
<br />
== Feintuning == <br />
<br />
Wer will, kann auch noch etwas Platz sparen. Die normale Mailmaninstallation schlägt mit über 20 MB zu Buche...<br />
<br />
Mit den folgenden Tips kann man das auf ca. 6 MB reduzieren :)<br />
<br />
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!<br />
<br />
* ~/mailman/cgi-bin und ~/mailman/icons können gelöscht werden, falls sie an andere Stelle kopiert worden sind.<br />
* Die nicht benötigten Sprachen in ~/mailman/messages löschen.<br />
* Die nicht benötigten Sprachen in ~/mailman/templates löschen (bis auf englisch).<br />
* ~/mailman/tests kann, soweit ich das sehe, komplett gelöscht werden.<br />
* Falls man koreanisch und japanisch nicht braucht, kann man folgendes machen:<br />
* in ~/mailman/bin/paths.py, ~/mailman/cron/paths.py und ~/mailman/scripts/paths.py die Zeilen:<br />
<br />
# In a normal interactive Python environment, the japanese.pth and korean.pth<br />
# files would be imported automatically. But because we inhibit the importing<br />
# of the site module, we need to be explicit about importing these codecs.<br />
if not jaok:<br />
import japanese<br />
# As of KoreanCodecs 2.0.5, you had to do the second import to get the Korean<br />
# codecs installed, however leave the first import in there in case an upgrade<br />
# changes this.<br />
if not kook:<br />
import korean<br />
import korean.aliases<br />
<br />
auskommentieren.<br />
<br />
Dann kann man ~/mailman/pythonlib/japanese, ~/mailman/pythonlib/korean, ~/mailman/pythonlib/korean.pth sowie ~/mailman/pythonlib/lib löschen.<br />
<br />
Man kann auch noch die Debug-Informationen aus den binaries strippen:<br />
<br />
strip ~/mailman/mail/mailman<br />
strip ~/mailman/cgi-bin/*<br />
<br />
Falls die CGIs nicht gesymlinkt wurden:<br />
<br />
strip ~/doms/listen.example.com/cgi/mailman/*<br />
<br />
== Multidomainfähigkeit ==<br />
<br />
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.<br />
<br />
=== Anleitung ===<br />
<br />
Logischerweise muss das Webfrontend (die CGIs) auf allen Domains installiert werden.<br />
<br />
Wenn man nun Mailinglisten mit newlist neu anlegt, muss man den Hostnamen für das Webfontend mit angeben, und zwar so:<br />
<br />
~$ mailman/bin/newlist listenname@listen.example.com<br />
<br />
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.)<br />
<br />
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:<br />
<br />
Also z.B.<br />
DEFAULT_URL_HOST = 'www.example.com'<br />
DEFAULT_EMAIL_HOST = 'listen.example.com'<br />
add_virtualhost(DEFAULT_URL_HOST,DEFAULT_EMAIL_HOST)<br />
<br />
und<br />
add_virtualhost('www.zoopnet.de', 'lists.zoopnet.de')<br />
<br />
Das bedeutet, dass Mailman per default davon ausgeht, dass alle Listen für die Domain example.com sind.<br />
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.<br />
<br />
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.<br />
<br />
<br />
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. :)<br />
<br />
=== Probleme ===<br />
<br />
Verschiedene Listen mit gleichem Namen (also z.B. liste@example1.com und liste@example2.com) sind mit Mailman 2.1 leider nicht möglich.<br />
<br />
<br />
== Tips und Tricks ==<br />
<br />
=== URL Änderungen ===<br />
Nach URL Änderungen stimmen Links im Web-Interface nicht mehr und Listen werden nicht mehr angezeigt.<br />
Es sind dann, zusätzlich zur Anpassung der mm_cfg.py, schon bestehende Listen und Archive mit folgendem Befehl zu aktualisieren:<br />
~/mailman/bin/withlist -l -r fix_url <Listen_Name> -v -u <Neue_Url><br />
<Listen_Name> steht für die Mailingliste, die bearbeitet werden soll. <Neue_Url> für die neue URL/Webadresse des Webinterfaces.<br />
<br />
=== Weitere Cron-Jobs zur Mailinglisten Verwaltung ===<br />
<br />
Folgende Cronjobs helfen bei der Verwaltung und sind User freundlich:<br />
<br />
< In Arbeit ><br />
<br />
== Referenzen ==<br />
<br />
Lösung zur installation als Domainadmin (xyz00-listen) statt Paketadmin (xyz00): https://lists.hostsharing.net/archiv/support/2009-June/019414.html<br><br />
<br />
Ältere Anleitung für Installation als Domain-Admin (xyz00-listen): <http://lists.hostsharing.net/archiv/support/2005-January/012426.html><br><br />
<br />
"Kleine Tools" auf http://hs.andreasloesch.de/, wobei das 'pac-mm-install' wahrscheinlich nicht aktuell (genug) ist<br><br />
<br />
----<br />
[[Kategorie:HSDoku]]<br />
[[Kategorie:Installationsanleitungen]]<br />
[[Kategorie:Software]]<br />
[[Kategorie:Mailinglisten]]<br />
[[Kategorie:E-Mail]]</div>Apc00-tonyhttps://wiki.hostsharing.net/index.php?title=Diskussion:Mailman_Installieren&diff=5224Diskussion:Mailman Installieren2020-05-14T16:00:11Z<p>Apc00-tony: </p>
<hr />
<div>Sehr schön; sauberer gegliedert als die Vorversion. <br />
<br />
Ein paar Vorschläge dennoch:<br />
<br />
"Mailman kann als Paketadmin oder Paketuser installiert werden."<br />
<br />
* "Paket-Admin", "Paketadmin": Ich wäre dafür, wir würden überall im Wiki die Schreibweise "Paket-Admin" verwenden. Einfach als konservativer Umgang mit Wortschöpfungen. Andere Meinungen?<br />
<br />
* "Paketuser" ist auf der Seite [[User-Arten]] nicht definiert. Sollte es hier wohl "Domain-Admin" heißen?<br />
<br />
* Syntax: Strenggenommen kann Mailman nur als Softwareprogramm installiert werden, nicht als Paket-Admin oder als Domain-Admin. Alternativer Satzbau: "Mailman kann vom Paket-Admin oder von einem Domain-Admin installiert werden." Oder: "Mailman kann man als Paket-Admin oder als Domain-Admin installieren."<br />
<br />
== Verzeichnisstruktur ==<br />
<br />
Als Verzeichnisname fuer die Mailman Installation wird in der Anleitung teilweise "mailman" und teilweise "mailman-2.1.12" verwendet. Ist das beabsichtigt? Bin mir nicht sicher, aber ich vermute, dass es einheitlich "mailman-2.1.12" heissen sollte. Z.B.<br />
<br />
~$ mkdir -p mailman-2.1.12/var<br />
~$ chmod 02775 mailman-2.1.12/var<br />
<br />
statt:<br />
~$ mkdir -p mailman/var<br />
~$ chmod 02775 mailman/var<br />
<br />
<br />
oder:<br />
<br />
~/mailman-2.1.12$ ./configure --prefix=/home/pacs/XYZ00/mailman-2.1.12 \<br />
--with-username=XYZ00 \<br />
--with-groupname=XYZ00 \<br />
--with-var-prefix=/home/pacs/XYZ00/var/mailman-2.1.12 \<br />
--with-cgi-gid=XYZ00 \<br />
--with-mail-gid=nogroup<br />
<br />
satt:<br />
<br />
~/mailman-2.1.12$ ./configure --prefix=/home/pacs/XYZ00/mailman \<br />
--with-username=XYZ00 \<br />
--with-groupname=XYZ00 \<br />
--with-var-prefix=/home/pacs/XYZ00/var/mailman \<br />
--with-cgi-gid=XYZ00 \<br />
--with-mail-gid=nogroup<br />
<br />
: Nein, das ist Absicht. Unter "mailman-2.1.12" liegen die entpackten Sourcen, wohingegen nach "mailman" installiert wird. --[[Benutzer:Daz00-daniel|Daz00-daniel]] 13:33, 6. Okt. 2009 (CEST)<br />
<br />
== Don't try this at home! ==<br />
<br />
Also bitte nicht mehr Mailman als Paketadmin installieren und nicht mehr mittels Aliases die Mails auf Mailman pipen.<br />
<br />
Und nicht mehr die E-Mail-Adressen und Aliases auf diese Art einrichten:<br />
<br />
hsscript -u xyz00 -i<br />
emailalias.add ({set:{name:'xyz00-listname_ohne_bindestriche',target:'"|/home/pacs/xyz00/mailman/mail/mailman post listname-bindestriche-okay"'}})<br />
emailalias.add ({set:{name:'xyz00-listname_ohne_bindestriche_admin',target:'"|/home/pacs/xyz00/mailman/mail/mailman admin listname-bindestriche-okay"'}})<br />
emailalias.add ({set:{name:'xyz00-listname_ohne_bindestriche_bounce',target:'"|/home/pacs/xyz00/mailman/mail/mailman bounce listname-bindestriche-okay"'}})<br />
emailalias.add ({set:{name:'xyz00-listname_ohne_bindestriche_confirm',target:'"|/home/pacs/xyz00/mailman/mail/mailman confirm listname-bindestriche-okay"'}})<br />
emailalias.add ({set:{name:'xyz00-listname_ohne_bindestriche_join',target:'"|/home/pacs/xyz00/mailman/mail/mailman join listname-bindestriche-okay"'}})<br />
emailalias.add ({set:{name:'xyz00-listname_ohne_bindestriche_leave',target:'"|/home/pacs/xyz00/mailman/mail/mailman leave listname-bindestriche-okay"'}})<br />
emailalias.add ({set:{name:'xyz00-listname_ohne_bindestriche_owner',target:'"|/home/pacs/xyz00/mailman/mail/mailman owner listname-bindestriche-okay"'}})<br />
emailalias.add ({set:{name:'xyz00-listname_ohne_bindestriche_request',target:'"|/home/pacs/xyz00/mailman/mail/mailman request listname-bindestriche-okay"'}})<br />
emailalias.add ({set:{name:'xyz00-listname_ohne_bindestriche_subscribe',target:'"|/home/pacs/xyz00/mailman/mail/mailman subscribe listname-bindestriche-okay"'}})<br />
emailalias.add ({set:{name:'xyz00-listname_ohne_bindestriche_unsubscribe',target:'"|/home/pacs/xyz00/mailman/mail/mailman unsubscribe listname-bindestriche-okay"'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'listname-bindestriche-okay',target:'xyz00-listname_ohne_bindestriche'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'listname-bindestriche-okay-admin',target:'xyz00-listname_ohne_bindestriche_admin'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'listname-bindestriche-okay-bounces',target:'xyz00-listname_ohne_bindestriche_bounces'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'listname-bindestriche-okay-confirm',target:'xyz00-listname_ohne_bindestriche_confirm'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'listname-bindestriche-okay-join',target:'xyz00-listname_ohne_bindestriche_join'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'listname-bindestriche-okay-leave',target:'xyz00-listname_ohne_bindestriche_leave'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'listname-bindestriche-okay-owner',target:'xyz00-listname_ohne_bindestriche_owner'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'listname-bindestriche-okay-request',target:'xyz00-listname_ohne_bindestriche_request'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'listname-bindestriche-okay-subscribe',target:'xyz00-listname_ohne_bindestriche_subscribe'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'listname-bindestriche-okay-unsubscribe',target:'xyz00-listname_ohne_bindestriche_unsubscribe'}})<br />
<br />
Und dabei nicht die doppelten Anführungszeichen bei dem Alias-Ziel beachten.<br />
<br />
Okay? Okay! [[Benutzer:Apc00|Tony Crawford (apc00)]] ([[Benutzer Diskussion:Apc00|Diskussion]]) 15:52, 15. Mär. 2017 (CET)<br />
<br />
== XYZ00 in Versalien? ==<br />
<br />
Wir schreiben xyz00 im ganzen Wiki klein, nur hier nicht. Das kann doch geändert werden, oder gibt es etwas, das dagegen spricht? --[[Benutzer:Deg00-m.website|ChristofT]] ([[Benutzer Diskussion:Deg00-m.website|Diskussion]]) 12:39, 2. Sep. 2017 (CEST)<br />
:Ich denke: Es MUSS klein geschrieben werden, sonst kommt noch jemand auf die Idee, Paket-Nutzer oder -Verzeichnisnamen müssten gross geschrieben sein. das wäre ein Missverständnis. --[[Benutzer:Hsh00-peh|Peter]] ([[Benutzer Diskussion:Hsh00-peh|Diskussion]]) 19:38, 2. Sep. 2017 (CEST)<br />
::Alles klar, habe es ersetzt --[[Benutzer:Deg00-m.website|ChristofT]] ([[Benutzer Diskussion:Deg00-m.website|Diskussion]]) 19:11, 16. Sep. 2017 (CEST)</div>Apc00-tonyhttps://wiki.hostsharing.net/index.php?title=Benutzer:Apc00-tony/sandbox&diff=5217Benutzer:Apc00-tony/sandbox2020-05-05T15:09:22Z<p>Apc00-tony: Apc00-tony verschob die Seite Benutzer:Apc00-tony/sandbox nach Benutzer:Apc00-tony/Dynamisches DNS: Inhalt relativ ausgereift und ich will den Link einsetzen.</p>
<hr />
<div>#WEITERLEITUNG [[Benutzer:Apc00-tony/Dynamisches DNS]]</div>Apc00-tonyhttps://wiki.hostsharing.net/index.php?title=Benutzer:Apc00-tony/Dynamisches_DNS&diff=5216Benutzer:Apc00-tony/Dynamisches DNS2020-05-05T15:09:21Z<p>Apc00-tony: Apc00-tony verschob die Seite Benutzer:Apc00-tony/sandbox nach Benutzer:Apc00-tony/Dynamisches DNS: Inhalt relativ ausgereift und ich will den Link einsetzen.</p>
<hr />
<div>((Provisorischer Vorspann: Auf Grund einer Mailing-Listen-Diskussion habe ich angefangen, Dynamisches DNS über einen CGI-Skript bei Hostsharing zu realisieren. Meine Lösung habe ich dann vorgestellt; sie wurde für nicht ausreichend selbsterklärend befunden und fand wenig Akzeptanz. Hier also der Versuch, die Sache zu dokumentieren.))<br />
<br />
Mit der regelmäßigen Aufnahme von benutzerspezifischen Zonefiles in seiner DNS-Konfiguration bietet Hostsharing alles, was man braucht, um &bdquo;dynamisches DNS&ldquo; in Eigenregie zu realisieren.<br />
<br />
Das heißt, wenn ich mindestens eine Domain bei Hostsharing verwalte, und mindestens eine Einwahlverbindung (oder DSL-Verbindung) ins Internet mit wechselnder IP-Adresse über irgendeinen ISP für meinen Arbeitsplatzrechner zu Hause betreibe, dann kann ich dem Arbeitsplatzrechner über die DNS-Server von Hostsharing einen vollqualifizieren Domainnamen zuweisen, der der jeweiligen IP-Adresse meiner Einwahlleitung zugeordnet ist.<br />
<br />
<pre><br />
<br />
(ASCII-Art-Diagramm der beschriebenen Konstellation)<br />
<br />
</pre><br />
<br />
Im Folgenden wird eine real existierende Implementierung von Dynamischem DNS (&bdquo;DDNS&ldquo;) beschrieben. Die verschiedenen Elemente könnten durchaus anders realisiert werden; die beschriebene Implementierung könnte durchaus verbessert werden. Sie dient hier der Illustration.<br />
<br />
In der folgenden Beschreibung werden diese Beispielwerte benutzt:<br />
* Ein Hostsharing-Mitglied hat ein Account als Paket-Admin mit Kennung xyz00.<br />
* Im Paket xyz00 gibt es einen Domain-Admin namens xyz00-benutzername.<br />
* Dieser Domain-Admin verwaltet bei Hostsharing die Domains example.com und beispiel.de.<br />
* Ein Benutzer hat zu Hause (oder im Büro) einen Arbeitsplatzrechner hinter der marktüblichen DSL-Leitung, die von seinem ISP bereitgestellt wird.<br />
* Dieser Arbeitsplatzrechner (oder der Router, der seine Internetverbindung steuert) bekommt vom ISP immer wechselnde IP-Adressen zugewiesen.<br />
* Dennoch möchte der Benutzer seinen Arbeitsplatzrechner aus dem Internet unter dem Hostnamen einwahl.example.com ansprechen können.<br />
<br />
Dazu kann ein System wie Hostsharing, das authoritative DNS-Informationen für viele Domains bereitstellt, auch veränderliche DNS-Information über dynamisch verbundene Rechner verwalten &ndash; sofern das ressourcenschonend gemacht werden kann ohne andere Funktionen zu stören.<br />
<br />
== Aufgaben des Servers ==<br />
<br />
Um einem Rechner mit wechselnder IP-Adresse einen DDNS-Eintrag zu bieten, muß der Hostsharing-Server folgendes leisten (in ungefährer Reihenfolge der Ereignisse):<br />
<br />
# Eine Anfrage entgegennehmen, beispielsweise über HTTPS, von einem entfernten Rechner, der einen DNS-Eintrag für seine momentane IP-Adresse wünscht. <br />
# Prüfen, ob die Anfrage einen berechtigten DDNS-Dienst-Usernamen mit zugehörigem Paßwort enthält.<br />
# Prüfen, ob die Anfrage einen gültigen Domainnamen betrifft, den der Server bieten darf.<br />
# Prüfen, ob die Domain example.com demselben Benutzer gehört, unter dessen Namen der Dynamisches-DNS-Server läuft.<br />
# Eine gültige [[Zonefile]] mit &ndash; neben dem bisherigen Inhalt &ndash; einem A-Eintrag für einwahl.example.com in /home/pacs/xyz00/users/benutzername/doms/example.com/pri.example.com schreiben.<br />
# Dem Client eine Bestätigung oder ggf. eine Fehlermeldung als Antwort senden.<br />
# In irgendeiner Datenbank den momentan eingestellter Status all seiner DDNS-Einträge speichern.<br />
# In einer Logdatei protokollieren, daß obiges getan wurde, oder ggf. welche Fehler traten auf.<br />
<br />
== Aufgaben des Clients ==<br />
Bevor ich anfange, meinen Arbeitsplatzrechner so zu konfigurieren, daß er bei welchem Server auch immer einen DDNS-Eintrag anfordert, muß ich mich als verantwortlicher Benutzer dieses Rechners und der dazugehörigen Internetverbindung &ndash; das heißt, als Mensch &ndash; mit dem Betreiber des dynamisches-DNS-Servers vereinbaren, daß ich das darf und welchen Eintrag ich bekommen kann. Im Folgenden wird vorausgesetzt, daß solche Vereinbarungen getroffen und die Parameter geklärt wurden.<br />
<br />
Der DDNS-Client muß aus Server-Sicht nur wenig leisten:<br />
<br />
# Eine Anfrage senden, beispielsweise über HTTPS, an einen entfernten Rechner, der einen Eintrag ins DNS für die momentane IP-Adresse des Clients vornehmen kann.<br />Diese Anfrage muß einem festgelegten Format entsprechen und muß gültige Werte für die Authorisation des Clients, den gewünschten Domainnamen, und eventuell andere Parameter enthalten.<br />
# Eine Antwort des Servers entgegennehmen und als Erfolgs- oder Fehlermeldung auswerten.<br />
# Von überflüssigen Anfragen absehen: das heißt bei Erfolg, nicht wiederholt den gleichen Eintrag erneut wünschen; bei Fehlern, nicht die gleiche fehlerhafte Anfrage erneut schicken.<br />
<br />
== Kommunikation zwischen Client und Server ==<br />
<br />
Ein einziges Nachrichtenpaar von Anfrage und Antwort genügt, um einen DDNS-Eintrag einzurichten: Der Client teilt die IP-Adresse und den Domainnamen mit, die in einem DNS-Eintrag verbunden werden sollen; der Server bestätigt den Auftrag.<br />
<br />
In der Beispielimplementierung erfolgt die Kommunikation über HTTP, und die Anfrage des Clients könnte so aussehen:<br />
<br />
GET /cgi-bin/ddns?hostname=einwahl.example.com&myip=87.65.43.21 HTTP/1.1<br />
Host: ddns.beispiel.de<br />
User-Agent: Fritz!Box DDNS/1.0.1<br />
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==<br />
<br />
Bei Erhalt dieser Anfrage ruft Apache das CGI-Programm .../doms/ddns.beispiel.de/cgi-ssl/ddns auf. Das Fragezeichen trennt den Programmnamen von einem "Query-String", in dem zwei Metavariablen definiert und übergeben werden. Die erste Metavariable, hostname, hat den Wert "einwahl.example.com"; die zweite, myip, hat den Wert "87.65.43.21".<br />
<br />
Das Server-Programm, hier ''ddns'', prüft diese Informationen auf Form und Berechtigung, und schreibt gegebenenfalls einen entsprechenden Eintrag in einer Zonefile. Es schreibt auch verschiedene Informationen in die Standardausgabe. Wenn es die Standardausgabe geschlossen wird &ndash; also spätestens bei Programmende &ndash; schickt Apache diese Informationen als Antwort an den anfragenden Rechner zurück.<br />
<br />
Im Falle unserer Beispielimplementierung sieht die Antwort bei Erfolg so aus: <br />
<br />
HTTP/1.1 200 OK<br />
Date: Wed, 22 Apr 2020 08:35:15 GMT<br />
Server: Apache<br />
Content-Length: 17<br />
Content-Type: text/plain; charset=ISO-8859-1<br />
<br />
good 87.65.43.21<br />
<br />
=== Das DDNS-Protokoll von DynDNS.org ===<br />
<br />
In den 90er Jahren, bevor das Internet so durchgehend vergeschäftlicht wurde, boten einige Organisationen kostenlose DDNS-Dienste an. Ein sehr beliebtes Angebot war das von DynDNS.org. Das DDNS-Protokoll von diesem Dienst wurde sogar in Einwahl-Routern einprogrammiert und der Dienst wurde von ISPs und Router-Herstellern als Leistungsmerkmal beworben.<br />
<br />
DynDNS.org gehört inzwischen Oracle und bietet keine kostenlose Dienste mehr. Dennoch wird das DDNS-Protokoll von DynDNS.org in der vorliegenden Beispielimplementierung übernommen in der Hoffnung, daß die Kompatibilität mit einigen gängigen Einwahl-Routern von Vorteil sein kann. Es gibt noch eine kurze Online-Dokumentation der [https://help.dyn.com/remote-access-api/perform-update/ Anfrage] und [https://help.dyn.com/remote-access-api/perform-update/ Antwortnachrichten].<br />
<br />
Das gesammte Protokoll sieht einen einzigen Nachrichtenaustausch aus Anfrage und Antwort vor. Die Anfrage kann mehrere Argumente enthalten; die Antwort kann verschiedene Code-Wörtern enthalten. Übrigens können in einer einzigen Anfrage mehrere DNS-Einträge gewünscht werden. In diesem Fall kann die Antwort mehrzeilig ausfallen.<br />
<br />
Das Verhalten von Server und Client bei künftigen Kommunikationsvorgängen wird unter Umständen von vorangegangenen Kommunikationsergebnissen beeinflußt: nach wiederholten fehlerhaften oder redundanten Anfragen kann der Server weitere Anfragen des Benutzers verweigern; nach wiederholten Fehlermeldungen sollte ein Client aufhören, immer dieselbe Anfrage zu schicken. Und für den Fall, daß mehrere Clients dynamische DNS-Einträge in derselben Domain example.com bestellen, muß der Server den Stand aller Client-Einträge intern speichern, damit er nicht mit einer neuen Zonefile einen früher erstellten Eintrag löscht. Zu diesen Fragen siehe den Abschnitt '''[[#Sukzessive_Kommunikationsabläufe]]''' nach der Beschreibung von Anfragen und Antworten unten.<br />
<br />
====Anfrage====<br />
<br />
Die Anfrage in Form eines URL übergibt dem DDNS-Programm in einem 'Query-String' einige Metavariablen. Das heißt, in einem URL der Form<br />
<br />
<nowiki>https://benutzername:passwort@ddns.beisiel.de/cgi-bin/ddns?hostname=einwahl.example.com&myip=87.65.43.21</nowiki><br />
<br />
signalisert das Fragezeichen, daß ein Query-String folgt. In einem solchen Query-String können in der Beispielimplementierung folgende Metavariablen definiert werden:<br />
<br />
{| class="wikitable"<br />
|- class="hintergrundfarbe5"<br />
! Variable !! Beispiel !! Bemerkungen<br />
|-<br />
| hostname || <tt>hostname=einwahl.example.com</tt><br /><div style="font-size:smaller;"><tt>hostname=eins.example.com,zwei.example.com[,...]</tt></div> ||<br />
Muß ein vollständig qualifizierter Domain-Name ("FQDN") sein; <tt>example.com</tt> muß eine vom Besitzer des DDNS-Programms verwaltete Domain sein. Genaugenommen kann der Wert eine durch Kommata gegliederte Liste mehrerer gültiger Domainnamen sein, falls mehrere Einträge mit derselben IP-Adresse gewünscht werden.<br />
|-<br />
| myip || <tt>myip=87.65.43.21</tt>||<br />
Kann entfallen; kann vom Server ignoriert werden. Maßgeblich ist dann die IP-Adresse des Absenders, wie sie vom Web-Server mitgeteilt wird.<br />
|-<br />
| mx || <tt>mx=87.65.43.21</tt><br /><tt>mx=NOCHG</tt><br /> ||<br />
Neben dem A-Eintrag möchte der Client auch einen MX-Eintrag. Der Wert <tt>NOCHG</tt> (für &bdquo;no change&ldquo;) bedeutet, der bestehende MX-Eintrag (oder seine Abwesenheit) soll nicht geändert werden. <br />
|-<br />
| backmx || <tt>backmx=YES</tt><br /><tt>backmx=NOCHG</tt><br /><tt>backmx=NO</tt> ||<br />
Falls <tt>YES</tt>, wird ein zweiter MX-Eintrag erzeugt, der <tt>einwahl.example.com</tt> als Mail-Server für <tt>einwahl.example.com</tt> nennt. Dieser Eintrag hat eine niedrigere Präferenzzahl (also eine höhere Priorität) als der mit <tt>mx</tt> angeforderten Eintrag.<br />
|-<br />
| wildcard || <tt>wildcard=ON</tt><br /><tt>wildcard=NOCHG</tt><br /><tt>wildcard=OFF</tt> ||<br />
Neben dem A-Eintrag für den Domainnamen <tt>einwahl.example.com</tt> wünscht der Client auch einen Eintrag für beliebige Subdomains, also <tt>*.einwahl.example.com</tt>, mit der gleichen IP-Adresse.<br />
|-<br />
| offline ||<tt>offline=YES</tt><br /><tt>offline=NOCHG</tt>||<br />
Falls <tt>YES</tt>, wird ein DNS-Eintrag für <tt>einwahl.example.com</tt> aus der Zonefile getilgt. Gegebenenfalls wird der Hostname dann auf Grund eines parallelen Wildcard-Eintrags für <tt>*.example.com</tt> einer anderen IP-Adresse zugeordnet werden.<br />
|}<br />
<br />
<!-- IPv6? --><br />
<br />
Alle Parameter bis auf hostname können entfallen. Bei nichtdokumentierten Argumenten ist das Verhalten undefiniert&trade;.<br />
<br />
====Antwort====<br />
<br />
Die Antwort auf eine erfolgreiche HTTP-Anfrage besteht im häufigsten Fall aus einigen Header-Zeilen, gefolgt vom Inhalt der gewünschten Text- oder andere Datei. Ein Status-Code in der ersten Header-Zeile gibt an, ob die Anfrage bedient werden kann oder kreist andernfalls den Grund für die Enttäuschung ein.<br />
<br />
Die vorliegende Beispielimplementierung von DDNS schickt einen der üblichen HTTP-Status-Codes "200 OK" oder "500 Internal Server Error", gefolgt von einer kurzen Textnachricht nach dem HTTP-Header. Bei diesem Programm ist &ndash; laut Gebrauchshinweise von DynDNS.org &ndash; ''nicht'' der Status-Code im Header, sondern der Inhalt der Nachricht die definierte, maßgebliche Ergebnismeldung des Programms.<br />
<br />
{| class="wikitable"<br />
|- class="hintergrundfarbe5"<br />
! Meldung !! Bedeutung !! Bemerkungen<br />
|-<br />
| <tt>good&nbsp;&lt;IP&nbsp;number&gt;</tt> ||<br />
Der gewünschte DNS-Eintrag wurde erfolgreich in einer Zonefile eingetragen. <br />
|| Es kann natürlich noch einige Minuten dauern, bis die Zonefile vom Hostsharing-Roboter abgelesen wird und der Inhalt in die BIND-Konfiguration übernommen.<br />
|-<br />
| <tt>good&nbsp;0.0.0.0</tt> ||<br />
Das Argument <tt>offline=YES</tt> wurde empfangen und verarbeitet.<br />
|| Der Domainname hat also keinen dynamischen DNS-Eintrag mehr.<br />
|-<br />
<!-- We don't do this!<br />
| <tt>good&nbsp;127.0.0.1</tt> ||<br />
Die Anfrage entsprach nicht den Erfordernissen des Servers.<br />
|| Trotz des Worts <tt>good</tt> war die Anfrage nicht erfolgreich, falls in der Rückmeldung die IP-Adresse mit <tt>127.0.0.1</tt> angegeben wird. Dieser verwirrende Fehlercode ist aus unerklärlichen Gründen in der Spezifikation von DynDNS.org so definiert.<br />
|-<br />
--><br />
| <tt>nochg&nbsp;&lt;IP&nbsp;number&gt;</tt> ||<br />
Der gewünschte DNS-Eintrag war bereits vorhanden. <br />
|| Der Server selbst macht keine DNS-Abfrage, um das zu vermitteln: die &bdquo;no change&ldquo;-Antwort besagt nur, daß eine Anfrage für diesen Eintrag bereits mit Erfolg quittiert wurde.<br />
|-<br />
| <tt>notfqdn</tt> ||<br />
Fehlschlag: der gewünschte Domainname ist nicht gültig, oder es wurde keiner angegeben.<br />
|| ...<br />
|-<br />
| <tt>nohost</tt> ||<br />
Fehlschlag: der gewünschte Domainname ist gehört nicht zu denen, die für diesen Benutzer des DDNS-Dienstes konfiguriert sind.<br />
|| Siehe den Abschnitt [[#Administration|Administration]] weiter unten.<br />
|-<br />
| <tt>badauth</tt> ||<br />
Fehlschlag: Die Kombination von Benutzernamen und Paßwort entsprach keinem DDNS-Account, oder das Account ist momentan gesperrt.<br />
|| Ein gesperrtes Account kann nur der Domain-Admin mittels des Administrationswerkzeugs wieder freigeben: siehe den Abschnit [[#Administration|Administration]] weiter unten.<br />
|-<br />
| <tt>abuse</tt> ||<br />
Fehlschlag: der gewünschte Domainname ist wegen vorangeganger Fehlschläge oder überflüssiger Aufrufe gesperrt.<br />
|| Siehe den Abschnitt [[#Sukzessive_Kommunikationsabläufe|Sukzessive Kommunikationsabläufe]] unten.<br />
|-<br />
| <tt>911</tt> ||<br />
Fehlschlag: Das Server-Programm hat einen internen Fehler festgestellt.<br />
|| Das Problem liegt nicht in der Anfrage an sich.<br />
|}<br />
<br />
Man kann sich durchaus eine sinnreichere Kommunikation zwischen Client und Server vorstellen, doch das hier beschriebene Protokoll ist eben von DynDNS.org verwendet worden und wird in gängigen Routern implementiert, also wird es in der vorliegenden DDNS-Implementierung nachgebildet.<br />
<br />
=== Sukzessive Kommunikationsabläufe ===<br />
Der Server muß sich zwischen einzelnen Aufrufen einiges merken, um Ressourcen zu schonen und um zu verhindern, daß einmal vergebene DDNS-Einträge von neuen Anfragen, die dieselbe übergeordnete Domain betreffen, durch Überschreiben verlorengehen.<br />
<br />
==== Mißbrauch und Benutzersperrung ====<br />
Zur Schonung von Ressourcen muß sich die Implementierung weigern, sich mit zuvielen fehlerhaften oder auch nur überflüssigen Anfragen zu beschäftigen. Dazu führt der Server eine Strichliste über solche Anfragen jedes Clients und sperrt nach einer bestimmten Anzahl solcher Anfragen den Benutzernamen oder einzelne Domainnamen gegen die weitere Nutzung des Dienstes.<br />
<br />
Mißbrauchspunkte gegen einen einzelnen Domainnamen gibt es für:<br />
* eine Anfrage, die keinen neuen DNS-Eintrag (und keine Änderung oder Löschung eines Eintrags) erfordert, sondern bestehende Merkmale nur wiederholt<br />
<br />
Mißbrauchspunkte gegen einen Benutzernamen gibt es für:<br />
* die Angabe eines Domainnamens, der in der Dienstkonfiguration dem anfragenden Benutzernamen nicht zugeordnet ist<br />
* die Angabe eines Domainnamen in einer Domain, die nicht demselben Hostsharing-Domain-Admin gehört, der den DDNS-Dienst anbietet<br />
* die Angabe eines Domainnamens, der in der Dienstkonfiguration bereits wegen mißbräuchlicher Anfragen gesperrt ist (siehe oben)<br />
<br />
Um eine Sperrung aufzuheben, wird in der Regel eine Handlung durch den Administrator erforderlich sein.<br />
<br />
==== Mehrere dynamische Subdomains in derselben Domain ====<br />
Sobald zwei verschiedene DDNS-Einträge in derselben Domain verlangt werden &ndash; beispielsweise home.example.com und office.example.com &ndash; wird es notwendig, bei jeder neuen Zonefile für example.com eventuell frühere Einträge zu konservieren. Der Rechner zu Hause weiß beim Bestellen seines DDNS-Eintrags nichts vom Rechner im Büro und umgekehrt. Der Server muß in irgendeiner Form über bereits vergebene Einträge Buch führen und bei einer neuen Anfrage, die example.com betrifft, alle bereits aktiven DDNS-Einträge für example.com mit in die neue Zonefile aufnehmen &ndash auch wenn sie auf Anfragen verschiedener Benutzer zurückgehen.<br />
<br />
==== Datenbank ====<br />
In der Beispielimplementierung werden diese Informationen in einer SQLite-Datenbank gespeichert.<br />
<br />
== Sicherheit ==<br />
=== Rechte ===<br />
Die '''Benutzerrechte''' werden durch das Hostsharing-System kontrolliert. Sowohl das CGI-Programm als auch das [[#Administration|Administrationswerkzeug]] werden mit den Rechten des Domain-Admins (xyz00-benutzername in unserem Beispiel) ausgeführt, also kann dieses Programm nur die Domains bearbeiten, die von xyz00-benutzername verwaltet werden.<br />
<br />
=== Authentifizierung ===<br />
In der Beispielimplementierung (wie auch seinerzeit bei DynDNS.org) wird das CGI-Programm durch einen .htaccess-Eintrag geschützt, der HTTP-Basic-Authentication vorschreibt. Also wird das Programm eigentlich mit einem URL der form<br />
<br />
<nowiki>https://ddnsaccount:passwort@ddns.example.com/cgi-bin/ddns?hostname=...</nowiki><br />
<br />
aufgerufen.<br />
<br />
=== Verschlüsselung ===<br />
Das CGI-Programm sollte nur in example.com/cgi-ssl/ installiert werden, nicht in example.com/cgi/. Damit ist die Kommunikation zwischen Client und Server durch SSL verschlüsselt.<br />
<br />
== Administration ==<br />
<br />
Der Verwalter des DDNS-Programms trägt berechtigte Benutzer und die ihnen zugeteilten Domainnamen in die Datenbank des Programms ein mit Hilfe eines kleinen Hilfsprogramms. Das ist im vorliegenden Fall ein menügesteuertes Programm für die Befehlszeile, daß die naheliegenden Funktionen anbietet: Account hinzufügen, löschen, sperren, entsperren, Paßwort setzen, ändern; Domainnamen hinzufügen, ändern, entsperren, löschen; Accounts und Domainnamen mit aktuellem Status auflisten. Die Funktionen sind auch über Befehlszeilenargumente verfügbar, also skriptfähig.<br />
<br />
Eine Übersicht der Funktionen des Administrationswerkzeugs gibt dieses selbst aus:<br />
<br />
<pre><br />
xyz00-benutzername@h02:~$ bin/ddnsadmin -h<br />
ddnsadmin.pl: Verwaltungswerkzeug für ddns<br />
<br />
Verwendung:<br />
ddnsadmin -A{[ahlusf]} [<Account>] [-f <DB-Datei>]<br />
ddnsadmin -D{[ahlsf]} [<Domain>] -A <Account> [-f <DB-Datei>]<br />
ddnsadmin -E <Einstellung> <Wert> [-f <DB-Datei>]<br />
ddnsadmin [-f <DB-Datei>] [-n]<br />
<br />
Wenn keine Option oder nur -f <DB-Datei> angegeben wird, bietet<br />
ddnsadmin.pl eine interaktive Menüoberfläche.<br />
<br />
Optionen:<br />
-f <DB-Datei> Angegebene Datenbankdatei verwenden<br />
-n Neue, leere Datenbank erzeugen<br />
-Aa [<Account>] Account(s) auflisten<br />
-Ah <Account> <Paßwort> Account hinzufügen<br />
-A{lsf} <Account> Account löschen, sperren, freigeben<br />
-Au <Account> <Name> Account umbenennen<br />
-A <Account> -Da [<Domain>] Domain(s) auflisten<br />
-A <Account> -D{hlsf} <Domain> Domain hinzufügen,<br />
löschen, sperren, freigeben<br />
-E <Einstellung> <Wert> Einstellung ändern<br />
-h Diese Übersicht ausgeben<br />
<br />
Einstellungen: <br />
maxacctabuse Anzahl der mißbräuchlichen Aufrufe,<br />
bevor ein Account gesperrt wird<br />
maxhostabuse Anzahl der mißbräuchlichen Aufrufe,<br />
bevor ein Domainname gesperrt wird<br />
safeinterval Mindestabstand zwischen redundanten Aufrufen<br />
(in Sekunden)<br />
cgihost Server, der das DDNS-Skript bereithält<br />
<br />
xyz00-benutzername@h02:~$ <br />
</pre><br />
<br />
Eine Auflistung des momentanen Inhalts der DDNS-Datenbank durch das Administrationswerkzeug könnte beispielsweise so aussehen:<br />
<br />
<pre><br />
xyz00-benutzername@h02:~$ bin/ddnsadmin.pl -Aa<br />
1. papst Mißbrauch: 0; gesperrt: nein<br />
avignon.example.com<br />
zuletzt aktiv am Sun Apr 26 22:24:49 2020<br />
mit IP-Nr. 87.65.43.21; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 0; gesperrt: nein<br />
vatican.beispiel.de<br />
zuletzt aktiv am Sun Apr 26 22:24:49 2020<br />
mit IP-Nr. 87.65.43.21; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 0; gesperrt: nein<br />
2. kaiser Mißbrauch: 4; gesperrt: ja<br />
augsburg.beispiel.de<br />
zuletzt aktiv am Fri Apr 24 16:13:49 2020<br />
mit IP-Nr. 64.82.31.75; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 0; gesperrt: ja<br />
3. luther Mißbrauch: 1; gesperrt: nein<br />
wittenberg.example.com<br />
zuletzt aktiv am Mon Apr 27 10:12:49 2020<br />
mit IP-Nr. 78.56.34.12; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 1; gesperrt: nein<br />
xyz00-benutzername@h02:~$<br />
</pre><br />
<br />
Das DDNS-Account &bdquo;kaiser&ldquo; in dieser Auflistung ist wohl auf Grund fehlerhafter Anfragen automatisch gesperrt worden. Der Inhaber wird sich wohl bald melden, um nach Korrektur seiner Client-Konfiguration die Aufhebung der Sperre zu wünschen.<br />
<br />
=== Log ===<br />
Alle Anfragen werden in einer täglich wechselnden Log-Datei protokolliert, entweder schlicht oder ausführlich, je nachdem, ob eine Variable <tt>verbose</tt> wahr ist.<br />
Ein ausführlicher Log-Eintrag sieht so aus:<br />
<br />
Sun Apr 26 20:21:45 2020 ddns aufgerufen von papst<br />
unter 84.185.97.8<br />
URL: <nowiki>https://ddns.example.com/cgi-bin/ddns.cgi?hostname=<br />
avignon.example.com,vatican.beispiel.de&<br />
myip=84.185.97.8</nowiki><br />
Verwende IP 84.185.97.8 (= 1421435144)<br />
DB-Version: 1<br />
Skript und DB exklusiv geöffnet<br />
avignon.example.com: IP: 84.185.97.8; MX: 0; Backup-MX: nein;<br />
Wildcard: nein; Mißbrauch: 0; gesperrt: nein <br />
vatican.beispiel.de: IP: 84.185.97.8; MX: 0; Backup-MX: nein;<br />
Wildcard: nein; Mißbrauch: 0; gesperrt: nein <br />
Betroffene Zonen: example.com, beispiel.de<br />
Temporärdatei example.com_hxNa.new geschrieben<br />
Zonendatei /home/pacs/xyz00/users/benutzername/doms/example.com/<br />
etc/pri.example.com eingestellt<br />
Temporärdatei beispiel.de_6HcO.new geschrieben<br />
Zonendatei /home/pacs/xyz00/users/benutzername/doms/beispiel.de/<br />
etc/pri.beispiel.de eingestellt<br />
Abgeschlossen: Fertig<br />
<br />
Wenn <tt>verbose</tt> auf falsch gesetzt ist, sind die Log-Einträge einzeilig.</div>Apc00-tonyhttps://wiki.hostsharing.net/index.php?title=Benutzer:Apc00-tony/Dynamisches_DNS&diff=5202Benutzer:Apc00-tony/Dynamisches DNS2020-04-29T10:03:13Z<p>Apc00-tony: /* Administration */</p>
<hr />
<div>((Provisorischer Vorspann: Auf Grund einer Mailing-Listen-Diskussion habe ich angefangen, Dynamisches DNS über einen CGI-Skript bei Hostsharing zu realisieren. Meine Lösung habe ich dann vorgestellt; sie wurde für nicht ausreichend selbsterklärend befunden und fand wenig Akzeptanz. Hier also der Versuch, die Sache zu dokumentieren.))<br />
<br />
Mit der regelmäßigen Aufnahme von benutzerspezifischen Zonefiles in seiner DNS-Konfiguration bietet Hostsharing alles, was man braucht, um &bdquo;dynamisches DNS&ldquo; in Eigenregie zu realisieren.<br />
<br />
Das heißt, wenn ich mindestens eine Domain bei Hostsharing verwalte, und mindestens eine Einwahlverbindung (oder DSL-Verbindung) ins Internet mit wechselnder IP-Adresse über irgendeinen ISP für meinen Arbeitsplatzrechner zu Hause betreibe, dann kann ich dem Arbeitsplatzrechner über die DNS-Server von Hostsharing einen vollqualifizieren Domainnamen zuweisen, der der jeweiligen IP-Adresse meiner Einwahlleitung zugeordnet ist.<br />
<br />
<pre><br />
<br />
(ASCII-Art-Diagramm der beschriebenen Konstellation)<br />
<br />
</pre><br />
<br />
Im Folgenden wird eine real existierende Implementierung von Dynamischem DNS (&bdquo;DDNS&ldquo;) beschrieben. Die verschiedenen Elemente könnten durchaus anders realisiert werden; die beschriebene Implementierung könnte durchaus verbessert werden. Sie dient hier der Illustration.<br />
<br />
In der folgenden Beschreibung werden diese Beispielwerte benutzt:<br />
* Ein Hostsharing-Mitglied hat ein Account als Paket-Admin mit Kennung xyz00.<br />
* Im Paket xyz00 gibt es einen Domain-Admin namens xyz00-benutzername.<br />
* Dieser Domain-Admin verwaltet bei Hostsharing die Domains example.com und beispiel.de.<br />
* Ein Benutzer hat zu Hause (oder im Büro) einen Arbeitsplatzrechner hinter der marktüblichen DSL-Leitung, die von seinem ISP bereitgestellt wird.<br />
* Dieser Arbeitsplatzrechner (oder der Router, der seine Internetverbindung steuert) bekommt vom ISP immer wechselnde IP-Adressen zugewiesen.<br />
* Dennoch möchte der Benutzer seinen Arbeitsplatzrechner aus dem Internet unter dem Hostnamen einwahl.example.com ansprechen können.<br />
<br />
Dazu kann ein System wie Hostsharing, das authoritative DNS-Informationen für viele Domains bereitstellt, auch veränderliche DNS-Information über dynamisch verbundene Rechner verwalten &ndash; sofern das ressourcenschonend gemacht werden kann ohne andere Funktionen zu stören.<br />
<br />
== Aufgaben des Servers ==<br />
<br />
Um einem Rechner mit wechselnder IP-Adresse einen DDNS-Eintrag zu bieten, muß der Hostsharing-Server folgendes leisten (in ungefährer Reihenfolge der Ereignisse):<br />
<br />
# Eine Anfrage entgegennehmen, beispielsweise über HTTPS, von einem entfernten Rechner, der einen DNS-Eintrag für seine momentane IP-Adresse wünscht. <br />
# Prüfen, ob die Anfrage einen berechtigten DDNS-Dienst-Usernamen mit zugehörigem Paßwort enthält.<br />
# Prüfen, ob die Anfrage einen gültigen Domainnamen betrifft, den der Server bieten darf.<br />
# Prüfen, ob die Domain example.com demselben Benutzer gehört, unter dessen Namen der Dynamisches-DNS-Server läuft.<br />
# Eine gültige [[Zonefile]] mit &ndash; neben dem bisherigen Inhalt &ndash; einem A-Eintrag für einwahl.example.com in /home/pacs/xyz00/users/benutzername/doms/example.com/pri.example.com schreiben.<br />
# Dem Client eine Bestätigung oder ggf. eine Fehlermeldung als Antwort senden.<br />
# In irgendeiner Datenbank den momentan eingestellter Status all seiner DDNS-Einträge speichern.<br />
# In einer Logdatei protokollieren, daß obiges getan wurde, oder ggf. welche Fehler traten auf.<br />
<br />
== Aufgaben des Clients ==<br />
Bevor ich anfange, meinen Arbeitsplatzrechner so zu konfigurieren, daß er bei welchem Server auch immer einen DDNS-Eintrag anfordert, muß ich mich als verantwortlicher Benutzer dieses Rechners und der dazugehörigen Internetverbindung &ndash; das heißt, als Mensch &ndash; mit dem Betreiber des dynamisches-DNS-Servers vereinbaren, daß ich das darf und welchen Eintrag ich bekommen kann. Im Folgenden wird vorausgesetzt, daß solche Vereinbarungen getroffen und die Parameter geklärt wurden.<br />
<br />
Der DDNS-Client muß aus Server-Sicht nur wenig leisten:<br />
<br />
# Eine Anfrage senden, beispielsweise über HTTPS, an einen entfernten Rechner, der einen Eintrag ins DNS für die momentane IP-Adresse des Clients vornehmen kann.<br />Diese Anfrage muß einem festgelegten Format entsprechen und muß gültige Werte für die Authorisation des Clients, den gewünschten Domainnamen, und eventuell andere Parameter enthalten.<br />
# Eine Antwort des Servers entgegennehmen und als Erfolgs- oder Fehlermeldung auswerten.<br />
# Von überflüssigen Anfragen absehen: das heißt bei Erfolg, nicht wiederholt den gleichen Eintrag erneut wünschen; bei Fehlern, nicht die gleiche fehlerhafte Anfrage erneut schicken.<br />
<br />
== Kommunikation zwischen Client und Server ==<br />
<br />
Ein einziges Nachrichtenpaar von Anfrage und Antwort genügt, um einen DDNS-Eintrag einzurichten: Der Client teilt die IP-Adresse und den Domainnamen mit, die in einem DNS-Eintrag verbunden werden sollen; der Server bestätigt den Auftrag.<br />
<br />
In der Beispielimplementierung erfolgt die Kommunikation über HTTP, und die Anfrage des Clients könnte so aussehen:<br />
<br />
GET /cgi-bin/ddns?hostname=einwahl.example.com&myip=87.65.43.21 HTTP/1.1<br />
Host: ddns.beispiel.de<br />
User-Agent: Fritz!Box DDNS/1.0.1<br />
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==<br />
<br />
Bei Erhalt dieser Anfrage ruft Apache das CGI-Programm .../doms/ddns.beispiel.de/cgi-ssl/ddns auf. Das Fragezeichen trennt den Programmnamen von einem "Query-String", in dem zwei Metavariablen definiert und übergeben werden. Die erste Metavariable, hostname, hat den Wert "einwahl.example.com"; die zweite, myip, hat den Wert "87.65.43.21".<br />
<br />
Das Server-Programm, hier ''ddns'', prüft diese Informationen auf Form und Berechtigung, und schreibt gegebenenfalls einen entsprechenden Eintrag in einer Zonefile. Es schreibt auch verschiedene Informationen in die Standardausgabe. Wenn es die Standardausgabe geschlossen wird &ndash; also spätestens bei Programmende &ndash; schickt Apache diese Informationen als Antwort an den anfragenden Rechner zurück.<br />
<br />
Im Falle unserer Beispielimplementierung sieht die Antwort bei Erfolg so aus: <br />
<br />
HTTP/1.1 200 OK<br />
Date: Wed, 22 Apr 2020 08:35:15 GMT<br />
Server: Apache<br />
Content-Length: 17<br />
Content-Type: text/plain; charset=ISO-8859-1<br />
<br />
good 87.65.43.21<br />
<br />
=== Das DDNS-Protokoll von DynDNS.org ===<br />
<br />
In den 90er Jahren, bevor das Internet so durchgehend vergeschäftlicht wurde, boten einige Organisationen kostenlose DDNS-Dienste an. Ein sehr beliebtes Angebot war das von DynDNS.org. Das DDNS-Protokoll von diesem Dienst wurde sogar in Einwahl-Routern einprogrammiert und der Dienst wurde von ISPs und Router-Herstellern als Leistungsmerkmal beworben.<br />
<br />
DynDNS.org gehört inzwischen Oracle und bietet keine kostenlose Dienste mehr. Dennoch wird das DDNS-Protokoll von DynDNS.org in der vorliegenden Beispielimplementierung übernommen in der Hoffnung, daß die Kompatibilität mit einigen gängigen Einwahl-Routern von Vorteil sein kann. Es gibt noch eine kurze Online-Dokumentation der [https://help.dyn.com/remote-access-api/perform-update/ Anfrage] und [https://help.dyn.com/remote-access-api/perform-update/ Antwortnachrichten].<br />
<br />
Das gesammte Protokoll sieht einen einzigen Nachrichtenaustausch aus Anfrage und Antwort vor. Die Anfrage kann mehrere Argumente enthalten; die Antwort kann verschiedene Code-Wörtern enthalten. Übrigens können in einer einzigen Anfrage mehrere DNS-Einträge gewünscht werden. In diesem Fall kann die Antwort mehrzeilig ausfallen.<br />
<br />
Das Verhalten von Server und Client bei künftigen Kommunikationsvorgängen wird unter Umständen von vorangegangenen Kommunikationsergebnissen beeinflußt: nach wiederholten fehlerhaften oder redundanten Anfragen kann der Server weitere Anfragen des Benutzers verweigern; nach wiederholten Fehlermeldungen sollte ein Client aufhören, immer dieselbe Anfrage zu schicken. Und für den Fall, daß mehrere Clients dynamische DNS-Einträge in derselben Domain example.com bestellen, muß der Server den Stand aller Client-Einträge intern speichern, damit er nicht mit einer neuen Zonefile einen früher erstellten Eintrag löscht. Zu diesen Fragen siehe den Abschnitt '''[[#Sukzessive_Kommunikationsabläufe]]''' nach der Beschreibung von Anfragen und Antworten unten.<br />
<br />
====Anfrage====<br />
<br />
Die Anfrage in Form eines URL übergibt dem DDNS-Programm in einem 'Query-String' einige Metavariablen. Das heißt, in einem URL der Form<br />
<br />
<nowiki>https://benutzername:passwort@ddns.beisiel.de/cgi-bin/ddns?hostname=einwahl.example.com&myip=87.65.43.21</nowiki><br />
<br />
signalisert das Fragezeichen, daß ein Query-String folgt. In einem solchen Query-String können in der Beispielimplementierung folgende Metavariablen definiert werden:<br />
<br />
{| class="wikitable"<br />
|- class="hintergrundfarbe5"<br />
! Variable !! Beispiel !! Bemerkungen<br />
|-<br />
| hostname || <tt>hostname=einwahl.example.com</tt><br /><div style="font-size:smaller;"><tt>hostname=eins.example.com,zwei.example.com[,...]</tt></div> ||<br />
Muß ein vollständig qualifizierter Domain-Name ("FQDN") sein; <tt>example.com</tt> muß eine vom Besitzer des DDNS-Programms verwaltete Domain sein. Genaugenommen kann der Wert eine durch Kommata gegliederte Liste mehrerer gültiger Domainnamen sein, falls mehrere Einträge mit derselben IP-Adresse gewünscht werden.<br />
|-<br />
| myip || <tt>myip=87.65.43.21</tt>||<br />
Kann entfallen; kann vom Server ignoriert werden. Maßgeblich ist dann die IP-Adresse des Absenders, wie sie vom Web-Server mitgeteilt wird.<br />
|-<br />
| mx || <tt>mx=87.65.43.21</tt><br /><tt>mx=NOCHG</tt><br /> ||<br />
Neben dem A-Eintrag möchte der Client auch einen MX-Eintrag. Der Wert <tt>NOCHG</tt> (für &bdquo;no change&ldquo;) bedeutet, der bestehende MX-Eintrag (oder seine Abwesenheit) soll nicht geändert werden. <br />
|-<br />
| backmx || <tt>backmx=YES</tt><br /><tt>backmx=NOCHG</tt><br /><tt>backmx=NO</tt> ||<br />
Falls <tt>YES</tt>, wird ein zweiter MX-Eintrag erzeugt, der <tt>einwahl.example.com</tt> als Mail-Server für <tt>einwahl.example.com</tt> nennt. Dieser Eintrag hat eine niedrigere Präferenzzahl (also eine höhere Priorität) als der mit <tt>mx</tt> angeforderten Eintrag.<br />
|-<br />
| wildcard || <tt>wildcard=ON</tt><br /><tt>wildcard=NOCHG</tt><br /><tt>wildcard=OFF</tt> ||<br />
Neben dem A-Eintrag für den Domainnamen <tt>einwahl.example.com</tt> wünscht der Client auch einen Eintrag für beliebige Subdomains, also <tt>*.einwahl.example.com</tt>, mit der gleichen IP-Adresse.<br />
|-<br />
| offline ||<tt>offline=YES</tt><br /><tt>offline=NOCHG</tt>||<br />
Falls <tt>YES</tt>, wird ein DNS-Eintrag für <tt>einwahl.example.com</tt> aus der Zonefile getilgt. Gegebenenfalls wird der Hostname dann auf Grund eines parallelen Wildcard-Eintrags für <tt>*.example.com</tt> einer anderen IP-Adresse zugeordnet werden.<br />
|}<br />
<br />
<!-- IPv6? --><br />
<br />
Alle Parameter bis auf hostname können entfallen. Bei nichtdokumentierten Argumenten ist das Verhalten undefiniert&trade;.<br />
<br />
====Antwort====<br />
<br />
Die Antwort auf eine erfolgreiche HTTP-Anfrage besteht im häufigsten Fall aus einigen Header-Zeilen, gefolgt vom Inhalt der gewünschten Text- oder andere Datei. Ein Status-Code in der ersten Header-Zeile gibt an, ob die Anfrage bedient werden kann oder kreist andernfalls den Grund für die Enttäuschung ein.<br />
<br />
Die vorliegende Beispielimplementierung von DDNS schickt einen der üblichen HTTP-Status-Codes "200 OK" oder "500 Internal Server Error", gefolgt von einer kurzen Textnachricht nach dem HTTP-Header. Bei diesem Programm ist &ndash; laut Gebrauchshinweise von DynDNS.org &ndash; ''nicht'' der Status-Code im Header, sondern der Inhalt der Nachricht die definierte, maßgebliche Ergebnismeldung des Programms.<br />
<br />
{| class="wikitable"<br />
|- class="hintergrundfarbe5"<br />
! Meldung !! Bedeutung !! Bemerkungen<br />
|-<br />
| <tt>good&nbsp;&lt;IP&nbsp;number&gt;</tt> ||<br />
Der gewünschte DNS-Eintrag wurde erfolgreich in einer Zonefile eingetragen. <br />
|| Es kann natürlich noch einige Minuten dauern, bis die Zonefile vom Hostsharing-Roboter abgelesen wird und der Inhalt in die BIND-Konfiguration übernommen.<br />
|-<br />
| <tt>good&nbsp;0.0.0.0</tt> ||<br />
Das Argument <tt>offline=YES</tt> wurde empfangen und verarbeitet.<br />
|| Der Domainname hat also keinen dynamischen DNS-Eintrag mehr.<br />
|-<br />
<!-- We don't do this!<br />
| <tt>good&nbsp;127.0.0.1</tt> ||<br />
Die Anfrage entsprach nicht den Erfordernissen des Servers.<br />
|| Trotz des Worts <tt>good</tt> war die Anfrage nicht erfolgreich, falls in der Rückmeldung die IP-Adresse mit <tt>127.0.0.1</tt> angegeben wird. Dieser verwirrende Fehlercode ist aus unerklärlichen Gründen in der Spezifikation von DynDNS.org so definiert.<br />
|-<br />
--><br />
| <tt>nochg&nbsp;&lt;IP&nbsp;number&gt;</tt> ||<br />
Der gewünschte DNS-Eintrag war bereits vorhanden. <br />
|| Der Server selbst macht keine DNS-Abfrage, um das zu vermitteln: die &bdquo;no change&ldquo;-Antwort besagt nur, daß eine Anfrage für diesen Eintrag bereits mit Erfolg quittiert wurde.<br />
|-<br />
| <tt>notfqdn</tt> ||<br />
Fehlschlag: der gewünschte Domainname ist nicht gültig, oder es wurde keiner angegeben.<br />
|| ...<br />
|-<br />
| <tt>nohost</tt> ||<br />
Fehlschlag: der gewünschte Domainname ist gehört nicht zu denen, die für diesen Benutzer des DDNS-Dienstes konfiguriert sind.<br />
|| Siehe den Abschnitt [[#Administration|Administration]] weiter unten.<br />
|-<br />
| <tt>badauth</tt> ||<br />
Fehlschlag: Die Kombination von Benutzernamen und Paßwort entsprach keinem DDNS-Account, oder das Account ist momentan gesperrt.<br />
|| Ein gesperrtes Account kann nur der Domain-Admin mittels des Administrationswerkzeugs wieder freigeben: siehe den Abschnit [[#Administration|Administration]] weiter unten.<br />
|-<br />
| <tt>abuse</tt> ||<br />
Fehlschlag: der gewünschte Domainname ist wegen vorangeganger Fehlschläge oder überflüssiger Aufrufe gesperrt.<br />
|| Siehe den Abschnitt [[#Sukzessive_Kommunikationsabläufe|Sukzessive Kommunikationsabläufe]] unten.<br />
|-<br />
| <tt>911</tt> ||<br />
Fehlschlag: Das Server-Programm hat einen internen Fehler festgestellt.<br />
|| Das Problem liegt nicht in der Anfrage an sich.<br />
|}<br />
<br />
Man kann sich durchaus eine sinnreichere Kommunikation zwischen Client und Server vorstellen, doch das hier beschriebene Protokoll ist eben von DynDNS.org verwendet worden und wird in gängigen Routern implementiert, also wird es in der vorliegenden DDNS-Implementierung nachgebildet.<br />
<br />
=== Sukzessive Kommunikationsabläufe ===<br />
Der Server muß sich zwischen einzelnen Aufrufen einiges merken, um Ressourcen zu schonen und um zu verhindern, daß einmal vergebene DDNS-Einträge von neuen Anfragen, die dieselbe übergeordnete Domain betreffen, durch Überschreiben verlorengehen.<br />
<br />
==== Mißbrauch und Benutzersperrung ====<br />
Zur Schonung von Ressourcen muß sich die Implementierung weigern, sich mit zuvielen fehlerhaften oder auch nur überflüssigen Anfragen zu beschäftigen. Dazu führt der Server eine Strichliste über solche Anfragen jedes Clients und sperrt nach einer bestimmten Anzahl solcher Anfragen den Benutzernamen oder einzelne Domainnamen gegen die weitere Nutzung des Dienstes.<br />
<br />
Mißbrauchspunkte gegen einen einzelnen Domainnamen gibt es für:<br />
* eine Anfrage, die keinen neuen DNS-Eintrag (und keine Änderung oder Löschung eines Eintrags) erfordert, sondern bestehende Merkmale nur wiederholt<br />
<br />
Mißbrauchspunkte gegen einen Benutzernamen gibt es für:<br />
* die Angabe eines Domainnamens, der in der Dienstkonfiguration dem anfragenden Benutzernamen nicht zugeordnet ist<br />
* die Angabe eines Domainnamen in einer Domain, die nicht demselben Hostsharing-Domain-Admin gehört, der den DDNS-Dienst anbietet<br />
* die Angabe eines Domainnamens, der in der Dienstkonfiguration bereits wegen mißbräuchlicher Anfragen gesperrt ist (siehe oben)<br />
<br />
Um eine Sperrung aufzuheben, wird in der Regel eine Handlung durch den Administrator erforderlich sein.<br />
<br />
==== Mehrere dynamische Subdomains in derselben Domain ====<br />
Sobald zwei verschiedene DDNS-Einträge in derselben Domain verlangt werden &ndash; beispielsweise home.example.com und office.example.com &ndash; wird es notwendig, bei jeder neuen Zonefile für example.com eventuell frühere Einträge zu konservieren. Der Rechner zu Hause weiß beim Bestellen seines DDNS-Eintrags nichts vom Rechner im Büro und umgekehrt. Der Server muß in irgendeiner Form über bereits vergebene Einträge Buch führen und bei einer neuen Anfrage, die example.com betrifft, alle bereits aktiven DDNS-Einträge für example.com mit in die neue Zonefile aufnehmen &ndash auch wenn sie auf Anfragen verschiedener Benutzer zurückgehen.<br />
<br />
==== Datenbank ====<br />
In der Beispielimplementierung werden diese Informationen in einer SQLite-Datenbank gespeichert.<br />
<br />
== Sicherheit ==<br />
=== Rechte ===<br />
Die '''Benutzerrechte''' werden durch das Hostsharing-System kontrolliert. Sowohl das CGI-Programm als auch das [[#Administration|Administrationswerkzeug]] werden mit den Rechten des Domain-Admins (xyz00-benutzername in unserem Beispiel) ausgeführt, also kann dieses Programm nur die Domains bearbeiten, die von xyz00-benutzername verwaltet werden.<br />
<br />
=== Authentifizierung ===<br />
In der Beispielimplementierung (wie auch seinerzeit bei DynDNS.org) wird das CGI-Programm durch einen .htaccess-Eintrag geschützt, der HTTP-Basic-Authentication vorschreibt. Also wird das Programm eigentlich mit einem URL der form<br />
<br />
<nowiki>https://ddnsaccount:passwort@ddns.example.com/cgi-bin/ddns?hostname=...</nowiki><br />
<br />
aufgerufen.<br />
<br />
=== Verschlüsselung ===<br />
Das CGI-Programm sollte nur in example.com/cgi-ssl/ installiert werden, nicht in example.com/cgi/. Damit ist die Kommunikation zwischen Client und Server durch SSL verschlüsselt.<br />
<br />
== Administration ==<br />
<br />
Der Verwalter des DDNS-Programms trägt berechtigte Benutzer und die ihnen zugeteilten Domainnamen in die Datenbank des Programms ein mit Hilfe eines kleinen Hilfsprogramms. Das ist im vorliegenden Fall ein menügesteuertes Programm für die Befehlszeile, daß die naheliegenden Funktionen anbietet: Account hinzufügen, löschen, sperren, entsperren, Paßwort setzen, ändern; Domainnamen hinzufügen, ändern, entsperren, löschen; Accounts und Domainnamen mit aktuellem Status auflisten. Die Funktionen sind auch über Befehlszeilenargumente verfügbar, also skriptfähig.<br />
<br />
Eine Übersicht der Funktionen des Administrationswerkzeugs gibt dieses selbst aus:<br />
<br />
<pre><br />
xyz00-benutzername@h02:~$ bin/ddnsadmin -h<br />
ddnsadmin.pl: Verwaltungswerkzeug für ddns<br />
<br />
Verwendung:<br />
ddnsadmin -A{[ahlusf]} [<Account>] [-f <DB-Datei>]<br />
ddnsadmin -D{[ahlsf]} [<Domain>] -A <Account> [-f <DB-Datei>]<br />
ddnsadmin -E <Einstellung> <Wert> [-f <DB-Datei>]<br />
ddnsadmin [-f <DB-Datei>] [-n]<br />
<br />
Wenn keine Option oder nur -f <DB-Datei> angegeben wird, bietet<br />
ddnsadmin.pl eine interaktive Menüoberfläche.<br />
<br />
Optionen:<br />
-f <DB-Datei> Angegebene Datenbankdatei verwenden<br />
-n Neue, leere Datenbank erzeugen<br />
-Aa [<Account>] Account(s) auflisten<br />
-Ah <Account> <Paßwort> Account hinzufügen<br />
-A{lsf} <Account> Account löschen, sperren, freigeben<br />
-Au <Account> <Name> Account umbenennen<br />
-A <Account> -Da [<Domain>] Domain(s) auflisten<br />
-A <Account> -D{hlsf} <Domain> Domain hinzufügen,<br />
löschen, sperren, freigeben<br />
-E <Einstellung> <Wert> Einstellung ändern<br />
-h Diese Übersicht ausgeben<br />
<br />
Einstellungen: <br />
maxacctabuse Anzahl der mißbräuchlichen Aufrufe,<br />
bevor ein Account gesperrt wird<br />
maxhostabuse Anzahl der mißbräuchlichen Aufrufe,<br />
bevor ein Domainname gesperrt wird<br />
safeinterval Mindestabstand zwischen redundanten Aufrufen<br />
(in Sekunden)<br />
cgihost Server, der das DDNS-Skript bereithält<br />
<br />
xyz00-benutzername@h02:~$ <br />
</pre><br />
<br />
Eine Auflistung des momentanen Inhalts der DDNS-Datenbank durch das Administrationswerkzeug könnte beispielsweise so aussehen:<br />
<br />
<pre><br />
xyz00-benutzername@h02:~$ bin/ddnsadmin.pl -Aa<br />
1. papst Mißbrauch: 0; gesperrt: nein<br />
avignon.example.com<br />
zuletzt aktiv am Sun Apr 26 22:24:49 2020<br />
mit IP-Nr. 87.65.43.21; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 0; gesperrt: nein<br />
vatican.beispiel.de<br />
zuletzt aktiv am Sun Apr 26 22:24:49 2020<br />
mit IP-Nr. 87.65.43.21; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 0; gesperrt: nein<br />
2. kaiser Mißbrauch: 4; gesperrt: ja<br />
augsburg.beispiel.de<br />
zuletzt aktiv am Fri Apr 24 16:13:49 2020<br />
mit IP-Nr. 64.82.31.75; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 0; gesperrt: ja<br />
3. luther Mißbrauch: 1; gesperrt: nein<br />
wittenberg.example.com<br />
zuletzt aktiv am Mon Apr 27 10:12:49 2020<br />
mit IP-Nr. 78.56.34.12; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 1; gesperrt: nein<br />
xyz00-benutzername@h02:~$<br />
</pre><br />
<br />
Das DDNS-Account &bdquo;kaiser&ldquo; in dieser Auflistung ist wohl auf Grund fehlerhafter Anfragen automatisch gesperrt worden. Der Inhaber wird sich wohl bald melden, um nach Korrektur seiner Client-Konfiguration die Aufhebung der Sperre zu wünschen.<br />
<br />
=== Log ===<br />
Alle Anfragen werden in einer täglich wechselnden Log-Datei protokolliert, entweder schlicht oder ausführlich, je nachdem, ob eine Variable <tt>verbose</tt> wahr ist.<br />
Ein ausführlicher Log-Eintrag sieht so aus:<br />
<br />
Sun Apr 26 20:21:45 2020 ddns aufgerufen von papst<br />
unter 84.185.97.8<br />
URL: <nowiki>https://ddns.example.com/cgi-bin/ddns.cgi?hostname=<br />
avignon.example.com,vatican.beispiel.de&<br />
myip=84.185.97.8</nowiki><br />
Verwende IP 84.185.97.8 (= 1421435144)<br />
DB-Version: 1<br />
Skript und DB exklusiv geöffnet<br />
avignon.example.com: IP: 84.185.97.8; MX: 0; Backup-MX: nein;<br />
Wildcard: nein; Mißbrauch: 0; gesperrt: nein <br />
vatican.beispiel.de: IP: 84.185.97.8; MX: 0; Backup-MX: nein;<br />
Wildcard: nein; Mißbrauch: 0; gesperrt: nein <br />
Betroffene Zonen: example.com, beispiel.de<br />
Temporärdatei example.com_hxNa.new geschrieben<br />
Zonendatei /home/pacs/xyz00/users/benutzername/doms/example.com/<br />
etc/pri.example.com eingestellt<br />
Temporärdatei beispiel.de_6HcO.new geschrieben<br />
Zonendatei /home/pacs/xyz00/users/benutzername/doms/beispiel.de/<br />
etc/pri.beispiel.de eingestellt<br />
Abgeschlossen: Fertig<br />
<br />
Wenn <tt>verbose</tt> auf falsch gesetzt ist, sind die Log-Einträge einzeilig.</div>Apc00-tonyhttps://wiki.hostsharing.net/index.php?title=Benutzer:Apc00-tony/Dynamisches_DNS&diff=5201Benutzer:Apc00-tony/Dynamisches DNS2020-04-29T09:36:50Z<p>Apc00-tony: /* Mißbrauch und Benutzersperrung */</p>
<hr />
<div>((Provisorischer Vorspann: Auf Grund einer Mailing-Listen-Diskussion habe ich angefangen, Dynamisches DNS über einen CGI-Skript bei Hostsharing zu realisieren. Meine Lösung habe ich dann vorgestellt; sie wurde für nicht ausreichend selbsterklärend befunden und fand wenig Akzeptanz. Hier also der Versuch, die Sache zu dokumentieren.))<br />
<br />
Mit der regelmäßigen Aufnahme von benutzerspezifischen Zonefiles in seiner DNS-Konfiguration bietet Hostsharing alles, was man braucht, um &bdquo;dynamisches DNS&ldquo; in Eigenregie zu realisieren.<br />
<br />
Das heißt, wenn ich mindestens eine Domain bei Hostsharing verwalte, und mindestens eine Einwahlverbindung (oder DSL-Verbindung) ins Internet mit wechselnder IP-Adresse über irgendeinen ISP für meinen Arbeitsplatzrechner zu Hause betreibe, dann kann ich dem Arbeitsplatzrechner über die DNS-Server von Hostsharing einen vollqualifizieren Domainnamen zuweisen, der der jeweiligen IP-Adresse meiner Einwahlleitung zugeordnet ist.<br />
<br />
<pre><br />
<br />
(ASCII-Art-Diagramm der beschriebenen Konstellation)<br />
<br />
</pre><br />
<br />
Im Folgenden wird eine real existierende Implementierung von Dynamischem DNS (&bdquo;DDNS&ldquo;) beschrieben. Die verschiedenen Elemente könnten durchaus anders realisiert werden; die beschriebene Implementierung könnte durchaus verbessert werden. Sie dient hier der Illustration.<br />
<br />
In der folgenden Beschreibung werden diese Beispielwerte benutzt:<br />
* Ein Hostsharing-Mitglied hat ein Account als Paket-Admin mit Kennung xyz00.<br />
* Im Paket xyz00 gibt es einen Domain-Admin namens xyz00-benutzername.<br />
* Dieser Domain-Admin verwaltet bei Hostsharing die Domains example.com und beispiel.de.<br />
* Ein Benutzer hat zu Hause (oder im Büro) einen Arbeitsplatzrechner hinter der marktüblichen DSL-Leitung, die von seinem ISP bereitgestellt wird.<br />
* Dieser Arbeitsplatzrechner (oder der Router, der seine Internetverbindung steuert) bekommt vom ISP immer wechselnde IP-Adressen zugewiesen.<br />
* Dennoch möchte der Benutzer seinen Arbeitsplatzrechner aus dem Internet unter dem Hostnamen einwahl.example.com ansprechen können.<br />
<br />
Dazu kann ein System wie Hostsharing, das authoritative DNS-Informationen für viele Domains bereitstellt, auch veränderliche DNS-Information über dynamisch verbundene Rechner verwalten &ndash; sofern das ressourcenschonend gemacht werden kann ohne andere Funktionen zu stören.<br />
<br />
== Aufgaben des Servers ==<br />
<br />
Um einem Rechner mit wechselnder IP-Adresse einen DDNS-Eintrag zu bieten, muß der Hostsharing-Server folgendes leisten (in ungefährer Reihenfolge der Ereignisse):<br />
<br />
# Eine Anfrage entgegennehmen, beispielsweise über HTTPS, von einem entfernten Rechner, der einen DNS-Eintrag für seine momentane IP-Adresse wünscht. <br />
# Prüfen, ob die Anfrage einen berechtigten DDNS-Dienst-Usernamen mit zugehörigem Paßwort enthält.<br />
# Prüfen, ob die Anfrage einen gültigen Domainnamen betrifft, den der Server bieten darf.<br />
# Prüfen, ob die Domain example.com demselben Benutzer gehört, unter dessen Namen der Dynamisches-DNS-Server läuft.<br />
# Eine gültige [[Zonefile]] mit &ndash; neben dem bisherigen Inhalt &ndash; einem A-Eintrag für einwahl.example.com in /home/pacs/xyz00/users/benutzername/doms/example.com/pri.example.com schreiben.<br />
# Dem Client eine Bestätigung oder ggf. eine Fehlermeldung als Antwort senden.<br />
# In irgendeiner Datenbank den momentan eingestellter Status all seiner DDNS-Einträge speichern.<br />
# In einer Logdatei protokollieren, daß obiges getan wurde, oder ggf. welche Fehler traten auf.<br />
<br />
== Aufgaben des Clients ==<br />
Bevor ich anfange, meinen Arbeitsplatzrechner so zu konfigurieren, daß er bei welchem Server auch immer einen DDNS-Eintrag anfordert, muß ich mich als verantwortlicher Benutzer dieses Rechners und der dazugehörigen Internetverbindung &ndash; das heißt, als Mensch &ndash; mit dem Betreiber des dynamisches-DNS-Servers vereinbaren, daß ich das darf und welchen Eintrag ich bekommen kann. Im Folgenden wird vorausgesetzt, daß solche Vereinbarungen getroffen und die Parameter geklärt wurden.<br />
<br />
Der DDNS-Client muß aus Server-Sicht nur wenig leisten:<br />
<br />
# Eine Anfrage senden, beispielsweise über HTTPS, an einen entfernten Rechner, der einen Eintrag ins DNS für die momentane IP-Adresse des Clients vornehmen kann.<br />Diese Anfrage muß einem festgelegten Format entsprechen und muß gültige Werte für die Authorisation des Clients, den gewünschten Domainnamen, und eventuell andere Parameter enthalten.<br />
# Eine Antwort des Servers entgegennehmen und als Erfolgs- oder Fehlermeldung auswerten.<br />
# Von überflüssigen Anfragen absehen: das heißt bei Erfolg, nicht wiederholt den gleichen Eintrag erneut wünschen; bei Fehlern, nicht die gleiche fehlerhafte Anfrage erneut schicken.<br />
<br />
== Kommunikation zwischen Client und Server ==<br />
<br />
Ein einziges Nachrichtenpaar von Anfrage und Antwort genügt, um einen DDNS-Eintrag einzurichten: Der Client teilt die IP-Adresse und den Domainnamen mit, die in einem DNS-Eintrag verbunden werden sollen; der Server bestätigt den Auftrag.<br />
<br />
In der Beispielimplementierung erfolgt die Kommunikation über HTTP, und die Anfrage des Clients könnte so aussehen:<br />
<br />
GET /cgi-bin/ddns?hostname=einwahl.example.com&myip=87.65.43.21 HTTP/1.1<br />
Host: ddns.beispiel.de<br />
User-Agent: Fritz!Box DDNS/1.0.1<br />
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==<br />
<br />
Bei Erhalt dieser Anfrage ruft Apache das CGI-Programm .../doms/ddns.beispiel.de/cgi-ssl/ddns auf. Das Fragezeichen trennt den Programmnamen von einem "Query-String", in dem zwei Metavariablen definiert und übergeben werden. Die erste Metavariable, hostname, hat den Wert "einwahl.example.com"; die zweite, myip, hat den Wert "87.65.43.21".<br />
<br />
Das Server-Programm, hier ''ddns'', prüft diese Informationen auf Form und Berechtigung, und schreibt gegebenenfalls einen entsprechenden Eintrag in einer Zonefile. Es schreibt auch verschiedene Informationen in die Standardausgabe. Wenn es die Standardausgabe geschlossen wird &ndash; also spätestens bei Programmende &ndash; schickt Apache diese Informationen als Antwort an den anfragenden Rechner zurück.<br />
<br />
Im Falle unserer Beispielimplementierung sieht die Antwort bei Erfolg so aus: <br />
<br />
HTTP/1.1 200 OK<br />
Date: Wed, 22 Apr 2020 08:35:15 GMT<br />
Server: Apache<br />
Content-Length: 17<br />
Content-Type: text/plain; charset=ISO-8859-1<br />
<br />
good 87.65.43.21<br />
<br />
=== Das DDNS-Protokoll von DynDNS.org ===<br />
<br />
In den 90er Jahren, bevor das Internet so durchgehend vergeschäftlicht wurde, boten einige Organisationen kostenlose DDNS-Dienste an. Ein sehr beliebtes Angebot war das von DynDNS.org. Das DDNS-Protokoll von diesem Dienst wurde sogar in Einwahl-Routern einprogrammiert und der Dienst wurde von ISPs und Router-Herstellern als Leistungsmerkmal beworben.<br />
<br />
DynDNS.org gehört inzwischen Oracle und bietet keine kostenlose Dienste mehr. Dennoch wird das DDNS-Protokoll von DynDNS.org in der vorliegenden Beispielimplementierung übernommen in der Hoffnung, daß die Kompatibilität mit einigen gängigen Einwahl-Routern von Vorteil sein kann. Es gibt noch eine kurze Online-Dokumentation der [https://help.dyn.com/remote-access-api/perform-update/ Anfrage] und [https://help.dyn.com/remote-access-api/perform-update/ Antwortnachrichten].<br />
<br />
Das gesammte Protokoll sieht einen einzigen Nachrichtenaustausch aus Anfrage und Antwort vor. Die Anfrage kann mehrere Argumente enthalten; die Antwort kann verschiedene Code-Wörtern enthalten. Übrigens können in einer einzigen Anfrage mehrere DNS-Einträge gewünscht werden. In diesem Fall kann die Antwort mehrzeilig ausfallen.<br />
<br />
Das Verhalten von Server und Client bei künftigen Kommunikationsvorgängen wird unter Umständen von vorangegangenen Kommunikationsergebnissen beeinflußt: nach wiederholten fehlerhaften oder redundanten Anfragen kann der Server weitere Anfragen des Benutzers verweigern; nach wiederholten Fehlermeldungen sollte ein Client aufhören, immer dieselbe Anfrage zu schicken. Und für den Fall, daß mehrere Clients dynamische DNS-Einträge in derselben Domain example.com bestellen, muß der Server den Stand aller Client-Einträge intern speichern, damit er nicht mit einer neuen Zonefile einen früher erstellten Eintrag löscht. Zu diesen Fragen siehe den Abschnitt '''[[#Sukzessive_Kommunikationsabläufe]]''' nach der Beschreibung von Anfragen und Antworten unten.<br />
<br />
====Anfrage====<br />
<br />
Die Anfrage in Form eines URL übergibt dem DDNS-Programm in einem 'Query-String' einige Metavariablen. Das heißt, in einem URL der Form<br />
<br />
<nowiki>https://benutzername:passwort@ddns.beisiel.de/cgi-bin/ddns?hostname=einwahl.example.com&myip=87.65.43.21</nowiki><br />
<br />
signalisert das Fragezeichen, daß ein Query-String folgt. In einem solchen Query-String können in der Beispielimplementierung folgende Metavariablen definiert werden:<br />
<br />
{| class="wikitable"<br />
|- class="hintergrundfarbe5"<br />
! Variable !! Beispiel !! Bemerkungen<br />
|-<br />
| hostname || <tt>hostname=einwahl.example.com</tt><br /><div style="font-size:smaller;"><tt>hostname=eins.example.com,zwei.example.com[,...]</tt></div> ||<br />
Muß ein vollständig qualifizierter Domain-Name ("FQDN") sein; <tt>example.com</tt> muß eine vom Besitzer des DDNS-Programms verwaltete Domain sein. Genaugenommen kann der Wert eine durch Kommata gegliederte Liste mehrerer gültiger Domainnamen sein, falls mehrere Einträge mit derselben IP-Adresse gewünscht werden.<br />
|-<br />
| myip || <tt>myip=87.65.43.21</tt>||<br />
Kann entfallen; kann vom Server ignoriert werden. Maßgeblich ist dann die IP-Adresse des Absenders, wie sie vom Web-Server mitgeteilt wird.<br />
|-<br />
| mx || <tt>mx=87.65.43.21</tt><br /><tt>mx=NOCHG</tt><br /> ||<br />
Neben dem A-Eintrag möchte der Client auch einen MX-Eintrag. Der Wert <tt>NOCHG</tt> (für &bdquo;no change&ldquo;) bedeutet, der bestehende MX-Eintrag (oder seine Abwesenheit) soll nicht geändert werden. <br />
|-<br />
| backmx || <tt>backmx=YES</tt><br /><tt>backmx=NOCHG</tt><br /><tt>backmx=NO</tt> ||<br />
Falls <tt>YES</tt>, wird ein zweiter MX-Eintrag erzeugt, der <tt>einwahl.example.com</tt> als Mail-Server für <tt>einwahl.example.com</tt> nennt. Dieser Eintrag hat eine niedrigere Präferenzzahl (also eine höhere Priorität) als der mit <tt>mx</tt> angeforderten Eintrag.<br />
|-<br />
| wildcard || <tt>wildcard=ON</tt><br /><tt>wildcard=NOCHG</tt><br /><tt>wildcard=OFF</tt> ||<br />
Neben dem A-Eintrag für den Domainnamen <tt>einwahl.example.com</tt> wünscht der Client auch einen Eintrag für beliebige Subdomains, also <tt>*.einwahl.example.com</tt>, mit der gleichen IP-Adresse.<br />
|-<br />
| offline ||<tt>offline=YES</tt><br /><tt>offline=NOCHG</tt>||<br />
Falls <tt>YES</tt>, wird ein DNS-Eintrag für <tt>einwahl.example.com</tt> aus der Zonefile getilgt. Gegebenenfalls wird der Hostname dann auf Grund eines parallelen Wildcard-Eintrags für <tt>*.example.com</tt> einer anderen IP-Adresse zugeordnet werden.<br />
|}<br />
<br />
<!-- IPv6? --><br />
<br />
Alle Parameter bis auf hostname können entfallen. Bei nichtdokumentierten Argumenten ist das Verhalten undefiniert&trade;.<br />
<br />
====Antwort====<br />
<br />
Die Antwort auf eine erfolgreiche HTTP-Anfrage besteht im häufigsten Fall aus einigen Header-Zeilen, gefolgt vom Inhalt der gewünschten Text- oder andere Datei. Ein Status-Code in der ersten Header-Zeile gibt an, ob die Anfrage bedient werden kann oder kreist andernfalls den Grund für die Enttäuschung ein.<br />
<br />
Die vorliegende Beispielimplementierung von DDNS schickt einen der üblichen HTTP-Status-Codes "200 OK" oder "500 Internal Server Error", gefolgt von einer kurzen Textnachricht nach dem HTTP-Header. Bei diesem Programm ist &ndash; laut Gebrauchshinweise von DynDNS.org &ndash; ''nicht'' der Status-Code im Header, sondern der Inhalt der Nachricht die definierte, maßgebliche Ergebnismeldung des Programms.<br />
<br />
{| class="wikitable"<br />
|- class="hintergrundfarbe5"<br />
! Meldung !! Bedeutung !! Bemerkungen<br />
|-<br />
| <tt>good&nbsp;&lt;IP&nbsp;number&gt;</tt> ||<br />
Der gewünschte DNS-Eintrag wurde erfolgreich in einer Zonefile eingetragen. <br />
|| Es kann natürlich noch einige Minuten dauern, bis die Zonefile vom Hostsharing-Roboter abgelesen wird und der Inhalt in die BIND-Konfiguration übernommen.<br />
|-<br />
| <tt>good&nbsp;0.0.0.0</tt> ||<br />
Das Argument <tt>offline=YES</tt> wurde empfangen und verarbeitet.<br />
|| Der Domainname hat also keinen dynamischen DNS-Eintrag mehr.<br />
|-<br />
<!-- We don't do this!<br />
| <tt>good&nbsp;127.0.0.1</tt> ||<br />
Die Anfrage entsprach nicht den Erfordernissen des Servers.<br />
|| Trotz des Worts <tt>good</tt> war die Anfrage nicht erfolgreich, falls in der Rückmeldung die IP-Adresse mit <tt>127.0.0.1</tt> angegeben wird. Dieser verwirrende Fehlercode ist aus unerklärlichen Gründen in der Spezifikation von DynDNS.org so definiert.<br />
|-<br />
--><br />
| <tt>nochg&nbsp;&lt;IP&nbsp;number&gt;</tt> ||<br />
Der gewünschte DNS-Eintrag war bereits vorhanden. <br />
|| Der Server selbst macht keine DNS-Abfrage, um das zu vermitteln: die &bdquo;no change&ldquo;-Antwort besagt nur, daß eine Anfrage für diesen Eintrag bereits mit Erfolg quittiert wurde.<br />
|-<br />
| <tt>notfqdn</tt> ||<br />
Fehlschlag: der gewünschte Domainname ist nicht gültig, oder es wurde keiner angegeben.<br />
|| ...<br />
|-<br />
| <tt>nohost</tt> ||<br />
Fehlschlag: der gewünschte Domainname ist gehört nicht zu denen, die für diesen Benutzer des DDNS-Dienstes konfiguriert sind.<br />
|| Siehe den Abschnitt [[#Administration|Administration]] weiter unten.<br />
|-<br />
| <tt>badauth</tt> ||<br />
Fehlschlag: Die Kombination von Benutzernamen und Paßwort entsprach keinem DDNS-Account, oder das Account ist momentan gesperrt.<br />
|| Ein gesperrtes Account kann nur der Domain-Admin mittels des Administrationswerkzeugs wieder freigeben: siehe den Abschnit [[#Administration|Administration]] weiter unten.<br />
|-<br />
| <tt>abuse</tt> ||<br />
Fehlschlag: der gewünschte Domainname ist wegen vorangeganger Fehlschläge oder überflüssiger Aufrufe gesperrt.<br />
|| Siehe den Abschnitt [[#Sukzessive_Kommunikationsabläufe|Sukzessive Kommunikationsabläufe]] unten.<br />
|-<br />
| <tt>911</tt> ||<br />
Fehlschlag: Das Server-Programm hat einen internen Fehler festgestellt.<br />
|| Das Problem liegt nicht in der Anfrage an sich.<br />
|}<br />
<br />
Man kann sich durchaus eine sinnreichere Kommunikation zwischen Client und Server vorstellen, doch das hier beschriebene Protokoll ist eben von DynDNS.org verwendet worden und wird in gängigen Routern implementiert, also wird es in der vorliegenden DDNS-Implementierung nachgebildet.<br />
<br />
=== Sukzessive Kommunikationsabläufe ===<br />
Der Server muß sich zwischen einzelnen Aufrufen einiges merken, um Ressourcen zu schonen und um zu verhindern, daß einmal vergebene DDNS-Einträge von neuen Anfragen, die dieselbe übergeordnete Domain betreffen, durch Überschreiben verlorengehen.<br />
<br />
==== Mißbrauch und Benutzersperrung ====<br />
Zur Schonung von Ressourcen muß sich die Implementierung weigern, sich mit zuvielen fehlerhaften oder auch nur überflüssigen Anfragen zu beschäftigen. Dazu führt der Server eine Strichliste über solche Anfragen jedes Clients und sperrt nach einer bestimmten Anzahl solcher Anfragen den Benutzernamen oder einzelne Domainnamen gegen die weitere Nutzung des Dienstes.<br />
<br />
Mißbrauchspunkte gegen einen einzelnen Domainnamen gibt es für:<br />
* eine Anfrage, die keinen neuen DNS-Eintrag (und keine Änderung oder Löschung eines Eintrags) erfordert, sondern bestehende Merkmale nur wiederholt<br />
<br />
Mißbrauchspunkte gegen einen Benutzernamen gibt es für:<br />
* die Angabe eines Domainnamens, der in der Dienstkonfiguration dem anfragenden Benutzernamen nicht zugeordnet ist<br />
* die Angabe eines Domainnamen in einer Domain, die nicht demselben Hostsharing-Domain-Admin gehört, der den DDNS-Dienst anbietet<br />
* die Angabe eines Domainnamens, der in der Dienstkonfiguration bereits wegen mißbräuchlicher Anfragen gesperrt ist (siehe oben)<br />
<br />
Um eine Sperrung aufzuheben, wird in der Regel eine Handlung durch den Administrator erforderlich sein.<br />
<br />
==== Mehrere dynamische Subdomains in derselben Domain ====<br />
Sobald zwei verschiedene DDNS-Einträge in derselben Domain verlangt werden &ndash; beispielsweise home.example.com und office.example.com &ndash; wird es notwendig, bei jeder neuen Zonefile für example.com eventuell frühere Einträge zu konservieren. Der Rechner zu Hause weiß beim Bestellen seines DDNS-Eintrags nichts vom Rechner im Büro und umgekehrt. Der Server muß in irgendeiner Form über bereits vergebene Einträge Buch führen und bei einer neuen Anfrage, die example.com betrifft, alle bereits aktiven DDNS-Einträge für example.com mit in die neue Zonefile aufnehmen &ndash auch wenn sie auf Anfragen verschiedener Benutzer zurückgehen.<br />
<br />
==== Datenbank ====<br />
In der Beispielimplementierung werden diese Informationen in einer SQLite-Datenbank gespeichert.<br />
<br />
== Sicherheit ==<br />
=== Rechte ===<br />
Die '''Benutzerrechte''' werden durch das Hostsharing-System kontrolliert. Sowohl das CGI-Programm als auch das [[#Administration|Administrationswerkzeug]] werden mit den Rechten des Domain-Admins (xyz00-benutzername in unserem Beispiel) ausgeführt, also kann dieses Programm nur die Domains bearbeiten, die von xyz00-benutzername verwaltet werden.<br />
<br />
=== Authentifizierung ===<br />
In der Beispielimplementierung (wie auch seinerzeit bei DynDNS.org) wird das CGI-Programm durch einen .htaccess-Eintrag geschützt, der HTTP-Basic-Authentication vorschreibt. Also wird das Programm eigentlich mit einem URL der form<br />
<br />
<nowiki>https://ddnsaccount:passwort@ddns.example.com/cgi-bin/ddns?hostname=...</nowiki><br />
<br />
aufgerufen.<br />
<br />
=== Verschlüsselung ===<br />
Das CGI-Programm sollte nur in example.com/cgi-ssl/ installiert werden, nicht in example.com/cgi/. Damit ist die Kommunikation zwischen Client und Server durch SSL verschlüsselt.<br />
<br />
== Administration ==<br />
<br />
Der Verwalter des DDNS-Programms trägt berechtigte Benutzer und die ihnen zugeteilten Domainnamen in die Datenbank des Programms ein mit Hilfe eines kleinen Hilfsprogramms. Das ist im vorliegenden Fall ein menügesteuertes Programm für die Befehlszeile, daß die naheliegenden Funktionen anbietet: Account hinzufügen, löschen, sperren, entsperren, Paßwort setzen, ändern; Domainnamen hinzufügen, ändern, entsperren, löschen; Accounts und Domainnamen mit aktuellem Status auflisten. Die Funktionen sind auch über Befehlszeilenargumente verfügbar, also skriptfähig.<br />
<br />
Eine Auflistung des momentanen Inhalts der DDNS-Datenbank durch das Administrationswerkzeug könnte beispielsweise so aussehen:<br />
<br />
xyz00-benutzername@h02:~$ bin/ddnsadmin.pl -Aa<br />
1. papst Mißbrauch: 0; gesperrt: nein<br />
avignon.example.com<br />
zuletzt aktiv am Sun Apr 26 22:24:49 2020<br />
mit IP-Nr. 87.65.43.21; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 0; gesperrt: nein<br />
vatican.beispiel.de<br />
zuletzt aktiv am Sun Apr 26 22:24:49 2020<br />
mit IP-Nr. 87.65.43.21; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 0; gesperrt: nein<br />
2. kaiser Mißbrauch: 4; gesperrt: ja<br />
augsburg.beispiel.de<br />
zuletzt aktiv am Fri Apr 24 16:13:49 2020<br />
mit IP-Nr. 64.82.31.75; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 0; gesperrt: ja<br />
3. luther Mißbrauch: 1; gesperrt: nein<br />
wittenberg.example.com<br />
zuletzt aktiv am Mon Apr 27 10:12:49 2020<br />
mit IP-Nr. 78.56.34.12; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 1; gesperrt: nein<br />
xyz00-benutzername@h02:~$<br />
<br />
Das DDNS-Account &bdquo;kaiser&ldquo; in dieser Auflistung ist wohl auf Grund fehlerhafter Anfragen automatisch gesperrt worden. Der Inhaber wird sich wohl bald melden, um nach Korrektur seiner Client-Konfiguration die Aufhebung der Sperre zu wünschen.<br />
<br />
=== Log ===<br />
Alle Anfragen werden in einer täglich wechselnden Log-Datei protokolliert, entweder schlicht oder ausführlich, je nachdem, ob eine Variable <tt>verbose</tt> wahr ist.<br />
Ein ausführlicher Log-Eintrag sieht so aus:<br />
<br />
Sun Apr 26 20:21:45 2020 ddns aufgerufen von papst<br />
unter 84.185.97.8<br />
URL: <nowiki>https://ddns.example.com/cgi-bin/ddns.cgi?hostname=<br />
avignon.example.com,vatican.beispiel.de&<br />
myip=84.185.97.8</nowiki><br />
Verwende IP 84.185.97.8 (= 1421435144)<br />
DB-Version: 1<br />
Skript und DB exklusiv geöffnet<br />
avignon.example.com: IP: 84.185.97.8; MX: 0; Backup-MX: nein;<br />
Wildcard: nein; Mißbrauch: 0; gesperrt: nein <br />
vatican.beispiel.de: IP: 84.185.97.8; MX: 0; Backup-MX: nein;<br />
Wildcard: nein; Mißbrauch: 0; gesperrt: nein <br />
Betroffene Zonen: example.com, beispiel.de<br />
Temporärdatei example.com_hxNa.new geschrieben<br />
Zonendatei /home/pacs/xyz00/users/benutzername/doms/example.com/<br />
etc/pri.example.com eingestellt<br />
Temporärdatei beispiel.de_6HcO.new geschrieben<br />
Zonendatei /home/pacs/xyz00/users/benutzername/doms/beispiel.de/<br />
etc/pri.beispiel.de eingestellt<br />
Abgeschlossen: Fertig<br />
<br />
Wenn <tt>verbose</tt> auf falsch gesetzt ist, sind die Log-Einträge einzeilig.</div>Apc00-tonyhttps://wiki.hostsharing.net/index.php?title=Benutzer:Apc00-tony/Dynamisches_DNS&diff=5200Benutzer:Apc00-tony/Dynamisches DNS2020-04-29T09:35:24Z<p>Apc00-tony: /* Antwort */</p>
<hr />
<div>((Provisorischer Vorspann: Auf Grund einer Mailing-Listen-Diskussion habe ich angefangen, Dynamisches DNS über einen CGI-Skript bei Hostsharing zu realisieren. Meine Lösung habe ich dann vorgestellt; sie wurde für nicht ausreichend selbsterklärend befunden und fand wenig Akzeptanz. Hier also der Versuch, die Sache zu dokumentieren.))<br />
<br />
Mit der regelmäßigen Aufnahme von benutzerspezifischen Zonefiles in seiner DNS-Konfiguration bietet Hostsharing alles, was man braucht, um &bdquo;dynamisches DNS&ldquo; in Eigenregie zu realisieren.<br />
<br />
Das heißt, wenn ich mindestens eine Domain bei Hostsharing verwalte, und mindestens eine Einwahlverbindung (oder DSL-Verbindung) ins Internet mit wechselnder IP-Adresse über irgendeinen ISP für meinen Arbeitsplatzrechner zu Hause betreibe, dann kann ich dem Arbeitsplatzrechner über die DNS-Server von Hostsharing einen vollqualifizieren Domainnamen zuweisen, der der jeweiligen IP-Adresse meiner Einwahlleitung zugeordnet ist.<br />
<br />
<pre><br />
<br />
(ASCII-Art-Diagramm der beschriebenen Konstellation)<br />
<br />
</pre><br />
<br />
Im Folgenden wird eine real existierende Implementierung von Dynamischem DNS (&bdquo;DDNS&ldquo;) beschrieben. Die verschiedenen Elemente könnten durchaus anders realisiert werden; die beschriebene Implementierung könnte durchaus verbessert werden. Sie dient hier der Illustration.<br />
<br />
In der folgenden Beschreibung werden diese Beispielwerte benutzt:<br />
* Ein Hostsharing-Mitglied hat ein Account als Paket-Admin mit Kennung xyz00.<br />
* Im Paket xyz00 gibt es einen Domain-Admin namens xyz00-benutzername.<br />
* Dieser Domain-Admin verwaltet bei Hostsharing die Domains example.com und beispiel.de.<br />
* Ein Benutzer hat zu Hause (oder im Büro) einen Arbeitsplatzrechner hinter der marktüblichen DSL-Leitung, die von seinem ISP bereitgestellt wird.<br />
* Dieser Arbeitsplatzrechner (oder der Router, der seine Internetverbindung steuert) bekommt vom ISP immer wechselnde IP-Adressen zugewiesen.<br />
* Dennoch möchte der Benutzer seinen Arbeitsplatzrechner aus dem Internet unter dem Hostnamen einwahl.example.com ansprechen können.<br />
<br />
Dazu kann ein System wie Hostsharing, das authoritative DNS-Informationen für viele Domains bereitstellt, auch veränderliche DNS-Information über dynamisch verbundene Rechner verwalten &ndash; sofern das ressourcenschonend gemacht werden kann ohne andere Funktionen zu stören.<br />
<br />
== Aufgaben des Servers ==<br />
<br />
Um einem Rechner mit wechselnder IP-Adresse einen DDNS-Eintrag zu bieten, muß der Hostsharing-Server folgendes leisten (in ungefährer Reihenfolge der Ereignisse):<br />
<br />
# Eine Anfrage entgegennehmen, beispielsweise über HTTPS, von einem entfernten Rechner, der einen DNS-Eintrag für seine momentane IP-Adresse wünscht. <br />
# Prüfen, ob die Anfrage einen berechtigten DDNS-Dienst-Usernamen mit zugehörigem Paßwort enthält.<br />
# Prüfen, ob die Anfrage einen gültigen Domainnamen betrifft, den der Server bieten darf.<br />
# Prüfen, ob die Domain example.com demselben Benutzer gehört, unter dessen Namen der Dynamisches-DNS-Server läuft.<br />
# Eine gültige [[Zonefile]] mit &ndash; neben dem bisherigen Inhalt &ndash; einem A-Eintrag für einwahl.example.com in /home/pacs/xyz00/users/benutzername/doms/example.com/pri.example.com schreiben.<br />
# Dem Client eine Bestätigung oder ggf. eine Fehlermeldung als Antwort senden.<br />
# In irgendeiner Datenbank den momentan eingestellter Status all seiner DDNS-Einträge speichern.<br />
# In einer Logdatei protokollieren, daß obiges getan wurde, oder ggf. welche Fehler traten auf.<br />
<br />
== Aufgaben des Clients ==<br />
Bevor ich anfange, meinen Arbeitsplatzrechner so zu konfigurieren, daß er bei welchem Server auch immer einen DDNS-Eintrag anfordert, muß ich mich als verantwortlicher Benutzer dieses Rechners und der dazugehörigen Internetverbindung &ndash; das heißt, als Mensch &ndash; mit dem Betreiber des dynamisches-DNS-Servers vereinbaren, daß ich das darf und welchen Eintrag ich bekommen kann. Im Folgenden wird vorausgesetzt, daß solche Vereinbarungen getroffen und die Parameter geklärt wurden.<br />
<br />
Der DDNS-Client muß aus Server-Sicht nur wenig leisten:<br />
<br />
# Eine Anfrage senden, beispielsweise über HTTPS, an einen entfernten Rechner, der einen Eintrag ins DNS für die momentane IP-Adresse des Clients vornehmen kann.<br />Diese Anfrage muß einem festgelegten Format entsprechen und muß gültige Werte für die Authorisation des Clients, den gewünschten Domainnamen, und eventuell andere Parameter enthalten.<br />
# Eine Antwort des Servers entgegennehmen und als Erfolgs- oder Fehlermeldung auswerten.<br />
# Von überflüssigen Anfragen absehen: das heißt bei Erfolg, nicht wiederholt den gleichen Eintrag erneut wünschen; bei Fehlern, nicht die gleiche fehlerhafte Anfrage erneut schicken.<br />
<br />
== Kommunikation zwischen Client und Server ==<br />
<br />
Ein einziges Nachrichtenpaar von Anfrage und Antwort genügt, um einen DDNS-Eintrag einzurichten: Der Client teilt die IP-Adresse und den Domainnamen mit, die in einem DNS-Eintrag verbunden werden sollen; der Server bestätigt den Auftrag.<br />
<br />
In der Beispielimplementierung erfolgt die Kommunikation über HTTP, und die Anfrage des Clients könnte so aussehen:<br />
<br />
GET /cgi-bin/ddns?hostname=einwahl.example.com&myip=87.65.43.21 HTTP/1.1<br />
Host: ddns.beispiel.de<br />
User-Agent: Fritz!Box DDNS/1.0.1<br />
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==<br />
<br />
Bei Erhalt dieser Anfrage ruft Apache das CGI-Programm .../doms/ddns.beispiel.de/cgi-ssl/ddns auf. Das Fragezeichen trennt den Programmnamen von einem "Query-String", in dem zwei Metavariablen definiert und übergeben werden. Die erste Metavariable, hostname, hat den Wert "einwahl.example.com"; die zweite, myip, hat den Wert "87.65.43.21".<br />
<br />
Das Server-Programm, hier ''ddns'', prüft diese Informationen auf Form und Berechtigung, und schreibt gegebenenfalls einen entsprechenden Eintrag in einer Zonefile. Es schreibt auch verschiedene Informationen in die Standardausgabe. Wenn es die Standardausgabe geschlossen wird &ndash; also spätestens bei Programmende &ndash; schickt Apache diese Informationen als Antwort an den anfragenden Rechner zurück.<br />
<br />
Im Falle unserer Beispielimplementierung sieht die Antwort bei Erfolg so aus: <br />
<br />
HTTP/1.1 200 OK<br />
Date: Wed, 22 Apr 2020 08:35:15 GMT<br />
Server: Apache<br />
Content-Length: 17<br />
Content-Type: text/plain; charset=ISO-8859-1<br />
<br />
good 87.65.43.21<br />
<br />
=== Das DDNS-Protokoll von DynDNS.org ===<br />
<br />
In den 90er Jahren, bevor das Internet so durchgehend vergeschäftlicht wurde, boten einige Organisationen kostenlose DDNS-Dienste an. Ein sehr beliebtes Angebot war das von DynDNS.org. Das DDNS-Protokoll von diesem Dienst wurde sogar in Einwahl-Routern einprogrammiert und der Dienst wurde von ISPs und Router-Herstellern als Leistungsmerkmal beworben.<br />
<br />
DynDNS.org gehört inzwischen Oracle und bietet keine kostenlose Dienste mehr. Dennoch wird das DDNS-Protokoll von DynDNS.org in der vorliegenden Beispielimplementierung übernommen in der Hoffnung, daß die Kompatibilität mit einigen gängigen Einwahl-Routern von Vorteil sein kann. Es gibt noch eine kurze Online-Dokumentation der [https://help.dyn.com/remote-access-api/perform-update/ Anfrage] und [https://help.dyn.com/remote-access-api/perform-update/ Antwortnachrichten].<br />
<br />
Das gesammte Protokoll sieht einen einzigen Nachrichtenaustausch aus Anfrage und Antwort vor. Die Anfrage kann mehrere Argumente enthalten; die Antwort kann verschiedene Code-Wörtern enthalten. Übrigens können in einer einzigen Anfrage mehrere DNS-Einträge gewünscht werden. In diesem Fall kann die Antwort mehrzeilig ausfallen.<br />
<br />
Das Verhalten von Server und Client bei künftigen Kommunikationsvorgängen wird unter Umständen von vorangegangenen Kommunikationsergebnissen beeinflußt: nach wiederholten fehlerhaften oder redundanten Anfragen kann der Server weitere Anfragen des Benutzers verweigern; nach wiederholten Fehlermeldungen sollte ein Client aufhören, immer dieselbe Anfrage zu schicken. Und für den Fall, daß mehrere Clients dynamische DNS-Einträge in derselben Domain example.com bestellen, muß der Server den Stand aller Client-Einträge intern speichern, damit er nicht mit einer neuen Zonefile einen früher erstellten Eintrag löscht. Zu diesen Fragen siehe den Abschnitt '''[[#Sukzessive_Kommunikationsabläufe]]''' nach der Beschreibung von Anfragen und Antworten unten.<br />
<br />
====Anfrage====<br />
<br />
Die Anfrage in Form eines URL übergibt dem DDNS-Programm in einem 'Query-String' einige Metavariablen. Das heißt, in einem URL der Form<br />
<br />
<nowiki>https://benutzername:passwort@ddns.beisiel.de/cgi-bin/ddns?hostname=einwahl.example.com&myip=87.65.43.21</nowiki><br />
<br />
signalisert das Fragezeichen, daß ein Query-String folgt. In einem solchen Query-String können in der Beispielimplementierung folgende Metavariablen definiert werden:<br />
<br />
{| class="wikitable"<br />
|- class="hintergrundfarbe5"<br />
! Variable !! Beispiel !! Bemerkungen<br />
|-<br />
| hostname || <tt>hostname=einwahl.example.com</tt><br /><div style="font-size:smaller;"><tt>hostname=eins.example.com,zwei.example.com[,...]</tt></div> ||<br />
Muß ein vollständig qualifizierter Domain-Name ("FQDN") sein; <tt>example.com</tt> muß eine vom Besitzer des DDNS-Programms verwaltete Domain sein. Genaugenommen kann der Wert eine durch Kommata gegliederte Liste mehrerer gültiger Domainnamen sein, falls mehrere Einträge mit derselben IP-Adresse gewünscht werden.<br />
|-<br />
| myip || <tt>myip=87.65.43.21</tt>||<br />
Kann entfallen; kann vom Server ignoriert werden. Maßgeblich ist dann die IP-Adresse des Absenders, wie sie vom Web-Server mitgeteilt wird.<br />
|-<br />
| mx || <tt>mx=87.65.43.21</tt><br /><tt>mx=NOCHG</tt><br /> ||<br />
Neben dem A-Eintrag möchte der Client auch einen MX-Eintrag. Der Wert <tt>NOCHG</tt> (für &bdquo;no change&ldquo;) bedeutet, der bestehende MX-Eintrag (oder seine Abwesenheit) soll nicht geändert werden. <br />
|-<br />
| backmx || <tt>backmx=YES</tt><br /><tt>backmx=NOCHG</tt><br /><tt>backmx=NO</tt> ||<br />
Falls <tt>YES</tt>, wird ein zweiter MX-Eintrag erzeugt, der <tt>einwahl.example.com</tt> als Mail-Server für <tt>einwahl.example.com</tt> nennt. Dieser Eintrag hat eine niedrigere Präferenzzahl (also eine höhere Priorität) als der mit <tt>mx</tt> angeforderten Eintrag.<br />
|-<br />
| wildcard || <tt>wildcard=ON</tt><br /><tt>wildcard=NOCHG</tt><br /><tt>wildcard=OFF</tt> ||<br />
Neben dem A-Eintrag für den Domainnamen <tt>einwahl.example.com</tt> wünscht der Client auch einen Eintrag für beliebige Subdomains, also <tt>*.einwahl.example.com</tt>, mit der gleichen IP-Adresse.<br />
|-<br />
| offline ||<tt>offline=YES</tt><br /><tt>offline=NOCHG</tt>||<br />
Falls <tt>YES</tt>, wird ein DNS-Eintrag für <tt>einwahl.example.com</tt> aus der Zonefile getilgt. Gegebenenfalls wird der Hostname dann auf Grund eines parallelen Wildcard-Eintrags für <tt>*.example.com</tt> einer anderen IP-Adresse zugeordnet werden.<br />
|}<br />
<br />
<!-- IPv6? --><br />
<br />
Alle Parameter bis auf hostname können entfallen. Bei nichtdokumentierten Argumenten ist das Verhalten undefiniert&trade;.<br />
<br />
====Antwort====<br />
<br />
Die Antwort auf eine erfolgreiche HTTP-Anfrage besteht im häufigsten Fall aus einigen Header-Zeilen, gefolgt vom Inhalt der gewünschten Text- oder andere Datei. Ein Status-Code in der ersten Header-Zeile gibt an, ob die Anfrage bedient werden kann oder kreist andernfalls den Grund für die Enttäuschung ein.<br />
<br />
Die vorliegende Beispielimplementierung von DDNS schickt einen der üblichen HTTP-Status-Codes "200 OK" oder "500 Internal Server Error", gefolgt von einer kurzen Textnachricht nach dem HTTP-Header. Bei diesem Programm ist &ndash; laut Gebrauchshinweise von DynDNS.org &ndash; ''nicht'' der Status-Code im Header, sondern der Inhalt der Nachricht die definierte, maßgebliche Ergebnismeldung des Programms.<br />
<br />
{| class="wikitable"<br />
|- class="hintergrundfarbe5"<br />
! Meldung !! Bedeutung !! Bemerkungen<br />
|-<br />
| <tt>good&nbsp;&lt;IP&nbsp;number&gt;</tt> ||<br />
Der gewünschte DNS-Eintrag wurde erfolgreich in einer Zonefile eingetragen. <br />
|| Es kann natürlich noch einige Minuten dauern, bis die Zonefile vom Hostsharing-Roboter abgelesen wird und der Inhalt in die BIND-Konfiguration übernommen.<br />
|-<br />
| <tt>good&nbsp;0.0.0.0</tt> ||<br />
Das Argument <tt>offline=YES</tt> wurde empfangen und verarbeitet.<br />
|| Der Domainname hat also keinen dynamischen DNS-Eintrag mehr.<br />
|-<br />
<!-- We don't do this!<br />
| <tt>good&nbsp;127.0.0.1</tt> ||<br />
Die Anfrage entsprach nicht den Erfordernissen des Servers.<br />
|| Trotz des Worts <tt>good</tt> war die Anfrage nicht erfolgreich, falls in der Rückmeldung die IP-Adresse mit <tt>127.0.0.1</tt> angegeben wird. Dieser verwirrende Fehlercode ist aus unerklärlichen Gründen in der Spezifikation von DynDNS.org so definiert.<br />
|-<br />
--><br />
| <tt>nochg&nbsp;&lt;IP&nbsp;number&gt;</tt> ||<br />
Der gewünschte DNS-Eintrag war bereits vorhanden. <br />
|| Der Server selbst macht keine DNS-Abfrage, um das zu vermitteln: die &bdquo;no change&ldquo;-Antwort besagt nur, daß eine Anfrage für diesen Eintrag bereits mit Erfolg quittiert wurde.<br />
|-<br />
| <tt>notfqdn</tt> ||<br />
Fehlschlag: der gewünschte Domainname ist nicht gültig, oder es wurde keiner angegeben.<br />
|| ...<br />
|-<br />
| <tt>nohost</tt> ||<br />
Fehlschlag: der gewünschte Domainname ist gehört nicht zu denen, die für diesen Benutzer des DDNS-Dienstes konfiguriert sind.<br />
|| Siehe den Abschnitt [[#Administration|Administration]] weiter unten.<br />
|-<br />
| <tt>badauth</tt> ||<br />
Fehlschlag: Die Kombination von Benutzernamen und Paßwort entsprach keinem DDNS-Account, oder das Account ist momentan gesperrt.<br />
|| Ein gesperrtes Account kann nur der Domain-Admin mittels des Administrationswerkzeugs wieder freigeben: siehe den Abschnit [[#Administration|Administration]] weiter unten.<br />
|-<br />
| <tt>abuse</tt> ||<br />
Fehlschlag: der gewünschte Domainname ist wegen vorangeganger Fehlschläge oder überflüssiger Aufrufe gesperrt.<br />
|| Siehe den Abschnitt [[#Sukzessive_Kommunikationsabläufe|Sukzessive Kommunikationsabläufe]] unten.<br />
|-<br />
| <tt>911</tt> ||<br />
Fehlschlag: Das Server-Programm hat einen internen Fehler festgestellt.<br />
|| Das Problem liegt nicht in der Anfrage an sich.<br />
|}<br />
<br />
Man kann sich durchaus eine sinnreichere Kommunikation zwischen Client und Server vorstellen, doch das hier beschriebene Protokoll ist eben von DynDNS.org verwendet worden und wird in gängigen Routern implementiert, also wird es in der vorliegenden DDNS-Implementierung nachgebildet.<br />
<br />
=== Sukzessive Kommunikationsabläufe ===<br />
Der Server muß sich zwischen einzelnen Aufrufen einiges merken, um Ressourcen zu schonen und um zu verhindern, daß einmal vergebene DDNS-Einträge von neuen Anfragen, die dieselbe übergeordnete Domain betreffen, durch Überschreiben verlorengehen.<br />
<br />
==== Mißbrauch und Benutzersperrung ====<br />
Zur Schonung von Ressourcen muß sich die Implementierung weigern, sich mit zuvielen fehlerhaften oder auch nur überflüssigen Anfragen zu beschäftigen. Dazu führt eine Strichliste über solche Anfragen jedes Clients und sperrt nach einer bestimmten Anzahl solcher Anfragen den Benutzernamen oder einzelne Domainnamen gegen die weitere Nutzung des Dienstes.<br />
<br />
Mißbrauchspunkte gegen einen einzelnen Domainnamen gibt es für:<br />
* eine Anfrage, die keinen neuen DNS-Eintrag (und keine Änderung oder Löschung eines Eintrags) erfordert, sondern bestehende Merkmale nur wiederholt<br />
<br />
Mißbrauchspunkte gegen einen Benutzernamen gibt es für:<br />
* die Angabe eines Domainnamens, der in der Dienstkonfiguration dem anfragenden Benutzernamen nicht zugeordnet ist<br />
* die Angabe eines Domainnamen in einer Domain, die nicht demselben Hostsharing-Domain-Admin gehört, der den DDNS-Dienst anbietet<br />
* die Angabe eines Domainnamens, der in der Dienstkonfiguration bereits wegen mißbräuchlicher Anfragen gesperrt ist (siehe oben)<br />
<br />
Um eine Sperrung aufzuheben, wird in der Regel eine Handlung durch den Administrator erforderlich sein.<br />
<br />
==== Mehrere dynamische Subdomains in derselben Domain ====<br />
Sobald zwei verschiedene DDNS-Einträge in derselben Domain verlangt werden &ndash; beispielsweise home.example.com und office.example.com &ndash; wird es notwendig, bei jeder neuen Zonefile für example.com eventuell frühere Einträge zu konservieren. Der Rechner zu Hause weiß beim Bestellen seines DDNS-Eintrags nichts vom Rechner im Büro und umgekehrt. Der Server muß in irgendeiner Form über bereits vergebene Einträge Buch führen und bei einer neuen Anfrage, die example.com betrifft, alle bereits aktiven DDNS-Einträge für example.com mit in die neue Zonefile aufnehmen &ndash auch wenn sie auf Anfragen verschiedener Benutzer zurückgehen.<br />
<br />
==== Datenbank ====<br />
In der Beispielimplementierung werden diese Informationen in einer SQLite-Datenbank gespeichert.<br />
<br />
== Sicherheit ==<br />
=== Rechte ===<br />
Die '''Benutzerrechte''' werden durch das Hostsharing-System kontrolliert. Sowohl das CGI-Programm als auch das [[#Administration|Administrationswerkzeug]] werden mit den Rechten des Domain-Admins (xyz00-benutzername in unserem Beispiel) ausgeführt, also kann dieses Programm nur die Domains bearbeiten, die von xyz00-benutzername verwaltet werden.<br />
<br />
=== Authentifizierung ===<br />
In der Beispielimplementierung (wie auch seinerzeit bei DynDNS.org) wird das CGI-Programm durch einen .htaccess-Eintrag geschützt, der HTTP-Basic-Authentication vorschreibt. Also wird das Programm eigentlich mit einem URL der form<br />
<br />
<nowiki>https://ddnsaccount:passwort@ddns.example.com/cgi-bin/ddns?hostname=...</nowiki><br />
<br />
aufgerufen.<br />
<br />
=== Verschlüsselung ===<br />
Das CGI-Programm sollte nur in example.com/cgi-ssl/ installiert werden, nicht in example.com/cgi/. Damit ist die Kommunikation zwischen Client und Server durch SSL verschlüsselt.<br />
<br />
== Administration ==<br />
<br />
Der Verwalter des DDNS-Programms trägt berechtigte Benutzer und die ihnen zugeteilten Domainnamen in die Datenbank des Programms ein mit Hilfe eines kleinen Hilfsprogramms. Das ist im vorliegenden Fall ein menügesteuertes Programm für die Befehlszeile, daß die naheliegenden Funktionen anbietet: Account hinzufügen, löschen, sperren, entsperren, Paßwort setzen, ändern; Domainnamen hinzufügen, ändern, entsperren, löschen; Accounts und Domainnamen mit aktuellem Status auflisten. Die Funktionen sind auch über Befehlszeilenargumente verfügbar, also skriptfähig.<br />
<br />
Eine Auflistung des momentanen Inhalts der DDNS-Datenbank durch das Administrationswerkzeug könnte beispielsweise so aussehen:<br />
<br />
xyz00-benutzername@h02:~$ bin/ddnsadmin.pl -Aa<br />
1. papst Mißbrauch: 0; gesperrt: nein<br />
avignon.example.com<br />
zuletzt aktiv am Sun Apr 26 22:24:49 2020<br />
mit IP-Nr. 87.65.43.21; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 0; gesperrt: nein<br />
vatican.beispiel.de<br />
zuletzt aktiv am Sun Apr 26 22:24:49 2020<br />
mit IP-Nr. 87.65.43.21; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 0; gesperrt: nein<br />
2. kaiser Mißbrauch: 4; gesperrt: ja<br />
augsburg.beispiel.de<br />
zuletzt aktiv am Fri Apr 24 16:13:49 2020<br />
mit IP-Nr. 64.82.31.75; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 0; gesperrt: ja<br />
3. luther Mißbrauch: 1; gesperrt: nein<br />
wittenberg.example.com<br />
zuletzt aktiv am Mon Apr 27 10:12:49 2020<br />
mit IP-Nr. 78.56.34.12; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 1; gesperrt: nein<br />
xyz00-benutzername@h02:~$<br />
<br />
Das DDNS-Account &bdquo;kaiser&ldquo; in dieser Auflistung ist wohl auf Grund fehlerhafter Anfragen automatisch gesperrt worden. Der Inhaber wird sich wohl bald melden, um nach Korrektur seiner Client-Konfiguration die Aufhebung der Sperre zu wünschen.<br />
<br />
=== Log ===<br />
Alle Anfragen werden in einer täglich wechselnden Log-Datei protokolliert, entweder schlicht oder ausführlich, je nachdem, ob eine Variable <tt>verbose</tt> wahr ist.<br />
Ein ausführlicher Log-Eintrag sieht so aus:<br />
<br />
Sun Apr 26 20:21:45 2020 ddns aufgerufen von papst<br />
unter 84.185.97.8<br />
URL: <nowiki>https://ddns.example.com/cgi-bin/ddns.cgi?hostname=<br />
avignon.example.com,vatican.beispiel.de&<br />
myip=84.185.97.8</nowiki><br />
Verwende IP 84.185.97.8 (= 1421435144)<br />
DB-Version: 1<br />
Skript und DB exklusiv geöffnet<br />
avignon.example.com: IP: 84.185.97.8; MX: 0; Backup-MX: nein;<br />
Wildcard: nein; Mißbrauch: 0; gesperrt: nein <br />
vatican.beispiel.de: IP: 84.185.97.8; MX: 0; Backup-MX: nein;<br />
Wildcard: nein; Mißbrauch: 0; gesperrt: nein <br />
Betroffene Zonen: example.com, beispiel.de<br />
Temporärdatei example.com_hxNa.new geschrieben<br />
Zonendatei /home/pacs/xyz00/users/benutzername/doms/example.com/<br />
etc/pri.example.com eingestellt<br />
Temporärdatei beispiel.de_6HcO.new geschrieben<br />
Zonendatei /home/pacs/xyz00/users/benutzername/doms/beispiel.de/<br />
etc/pri.beispiel.de eingestellt<br />
Abgeschlossen: Fertig<br />
<br />
Wenn <tt>verbose</tt> auf falsch gesetzt ist, sind die Log-Einträge einzeilig.</div>Apc00-tonyhttps://wiki.hostsharing.net/index.php?title=Benutzer:Apc00-tony/Dynamisches_DNS&diff=5199Benutzer:Apc00-tony/Dynamisches DNS2020-04-29T09:33:23Z<p>Apc00-tony: /* Antwort */</p>
<hr />
<div>((Provisorischer Vorspann: Auf Grund einer Mailing-Listen-Diskussion habe ich angefangen, Dynamisches DNS über einen CGI-Skript bei Hostsharing zu realisieren. Meine Lösung habe ich dann vorgestellt; sie wurde für nicht ausreichend selbsterklärend befunden und fand wenig Akzeptanz. Hier also der Versuch, die Sache zu dokumentieren.))<br />
<br />
Mit der regelmäßigen Aufnahme von benutzerspezifischen Zonefiles in seiner DNS-Konfiguration bietet Hostsharing alles, was man braucht, um &bdquo;dynamisches DNS&ldquo; in Eigenregie zu realisieren.<br />
<br />
Das heißt, wenn ich mindestens eine Domain bei Hostsharing verwalte, und mindestens eine Einwahlverbindung (oder DSL-Verbindung) ins Internet mit wechselnder IP-Adresse über irgendeinen ISP für meinen Arbeitsplatzrechner zu Hause betreibe, dann kann ich dem Arbeitsplatzrechner über die DNS-Server von Hostsharing einen vollqualifizieren Domainnamen zuweisen, der der jeweiligen IP-Adresse meiner Einwahlleitung zugeordnet ist.<br />
<br />
<pre><br />
<br />
(ASCII-Art-Diagramm der beschriebenen Konstellation)<br />
<br />
</pre><br />
<br />
Im Folgenden wird eine real existierende Implementierung von Dynamischem DNS (&bdquo;DDNS&ldquo;) beschrieben. Die verschiedenen Elemente könnten durchaus anders realisiert werden; die beschriebene Implementierung könnte durchaus verbessert werden. Sie dient hier der Illustration.<br />
<br />
In der folgenden Beschreibung werden diese Beispielwerte benutzt:<br />
* Ein Hostsharing-Mitglied hat ein Account als Paket-Admin mit Kennung xyz00.<br />
* Im Paket xyz00 gibt es einen Domain-Admin namens xyz00-benutzername.<br />
* Dieser Domain-Admin verwaltet bei Hostsharing die Domains example.com und beispiel.de.<br />
* Ein Benutzer hat zu Hause (oder im Büro) einen Arbeitsplatzrechner hinter der marktüblichen DSL-Leitung, die von seinem ISP bereitgestellt wird.<br />
* Dieser Arbeitsplatzrechner (oder der Router, der seine Internetverbindung steuert) bekommt vom ISP immer wechselnde IP-Adressen zugewiesen.<br />
* Dennoch möchte der Benutzer seinen Arbeitsplatzrechner aus dem Internet unter dem Hostnamen einwahl.example.com ansprechen können.<br />
<br />
Dazu kann ein System wie Hostsharing, das authoritative DNS-Informationen für viele Domains bereitstellt, auch veränderliche DNS-Information über dynamisch verbundene Rechner verwalten &ndash; sofern das ressourcenschonend gemacht werden kann ohne andere Funktionen zu stören.<br />
<br />
== Aufgaben des Servers ==<br />
<br />
Um einem Rechner mit wechselnder IP-Adresse einen DDNS-Eintrag zu bieten, muß der Hostsharing-Server folgendes leisten (in ungefährer Reihenfolge der Ereignisse):<br />
<br />
# Eine Anfrage entgegennehmen, beispielsweise über HTTPS, von einem entfernten Rechner, der einen DNS-Eintrag für seine momentane IP-Adresse wünscht. <br />
# Prüfen, ob die Anfrage einen berechtigten DDNS-Dienst-Usernamen mit zugehörigem Paßwort enthält.<br />
# Prüfen, ob die Anfrage einen gültigen Domainnamen betrifft, den der Server bieten darf.<br />
# Prüfen, ob die Domain example.com demselben Benutzer gehört, unter dessen Namen der Dynamisches-DNS-Server läuft.<br />
# Eine gültige [[Zonefile]] mit &ndash; neben dem bisherigen Inhalt &ndash; einem A-Eintrag für einwahl.example.com in /home/pacs/xyz00/users/benutzername/doms/example.com/pri.example.com schreiben.<br />
# Dem Client eine Bestätigung oder ggf. eine Fehlermeldung als Antwort senden.<br />
# In irgendeiner Datenbank den momentan eingestellter Status all seiner DDNS-Einträge speichern.<br />
# In einer Logdatei protokollieren, daß obiges getan wurde, oder ggf. welche Fehler traten auf.<br />
<br />
== Aufgaben des Clients ==<br />
Bevor ich anfange, meinen Arbeitsplatzrechner so zu konfigurieren, daß er bei welchem Server auch immer einen DDNS-Eintrag anfordert, muß ich mich als verantwortlicher Benutzer dieses Rechners und der dazugehörigen Internetverbindung &ndash; das heißt, als Mensch &ndash; mit dem Betreiber des dynamisches-DNS-Servers vereinbaren, daß ich das darf und welchen Eintrag ich bekommen kann. Im Folgenden wird vorausgesetzt, daß solche Vereinbarungen getroffen und die Parameter geklärt wurden.<br />
<br />
Der DDNS-Client muß aus Server-Sicht nur wenig leisten:<br />
<br />
# Eine Anfrage senden, beispielsweise über HTTPS, an einen entfernten Rechner, der einen Eintrag ins DNS für die momentane IP-Adresse des Clients vornehmen kann.<br />Diese Anfrage muß einem festgelegten Format entsprechen und muß gültige Werte für die Authorisation des Clients, den gewünschten Domainnamen, und eventuell andere Parameter enthalten.<br />
# Eine Antwort des Servers entgegennehmen und als Erfolgs- oder Fehlermeldung auswerten.<br />
# Von überflüssigen Anfragen absehen: das heißt bei Erfolg, nicht wiederholt den gleichen Eintrag erneut wünschen; bei Fehlern, nicht die gleiche fehlerhafte Anfrage erneut schicken.<br />
<br />
== Kommunikation zwischen Client und Server ==<br />
<br />
Ein einziges Nachrichtenpaar von Anfrage und Antwort genügt, um einen DDNS-Eintrag einzurichten: Der Client teilt die IP-Adresse und den Domainnamen mit, die in einem DNS-Eintrag verbunden werden sollen; der Server bestätigt den Auftrag.<br />
<br />
In der Beispielimplementierung erfolgt die Kommunikation über HTTP, und die Anfrage des Clients könnte so aussehen:<br />
<br />
GET /cgi-bin/ddns?hostname=einwahl.example.com&myip=87.65.43.21 HTTP/1.1<br />
Host: ddns.beispiel.de<br />
User-Agent: Fritz!Box DDNS/1.0.1<br />
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==<br />
<br />
Bei Erhalt dieser Anfrage ruft Apache das CGI-Programm .../doms/ddns.beispiel.de/cgi-ssl/ddns auf. Das Fragezeichen trennt den Programmnamen von einem "Query-String", in dem zwei Metavariablen definiert und übergeben werden. Die erste Metavariable, hostname, hat den Wert "einwahl.example.com"; die zweite, myip, hat den Wert "87.65.43.21".<br />
<br />
Das Server-Programm, hier ''ddns'', prüft diese Informationen auf Form und Berechtigung, und schreibt gegebenenfalls einen entsprechenden Eintrag in einer Zonefile. Es schreibt auch verschiedene Informationen in die Standardausgabe. Wenn es die Standardausgabe geschlossen wird &ndash; also spätestens bei Programmende &ndash; schickt Apache diese Informationen als Antwort an den anfragenden Rechner zurück.<br />
<br />
Im Falle unserer Beispielimplementierung sieht die Antwort bei Erfolg so aus: <br />
<br />
HTTP/1.1 200 OK<br />
Date: Wed, 22 Apr 2020 08:35:15 GMT<br />
Server: Apache<br />
Content-Length: 17<br />
Content-Type: text/plain; charset=ISO-8859-1<br />
<br />
good 87.65.43.21<br />
<br />
=== Das DDNS-Protokoll von DynDNS.org ===<br />
<br />
In den 90er Jahren, bevor das Internet so durchgehend vergeschäftlicht wurde, boten einige Organisationen kostenlose DDNS-Dienste an. Ein sehr beliebtes Angebot war das von DynDNS.org. Das DDNS-Protokoll von diesem Dienst wurde sogar in Einwahl-Routern einprogrammiert und der Dienst wurde von ISPs und Router-Herstellern als Leistungsmerkmal beworben.<br />
<br />
DynDNS.org gehört inzwischen Oracle und bietet keine kostenlose Dienste mehr. Dennoch wird das DDNS-Protokoll von DynDNS.org in der vorliegenden Beispielimplementierung übernommen in der Hoffnung, daß die Kompatibilität mit einigen gängigen Einwahl-Routern von Vorteil sein kann. Es gibt noch eine kurze Online-Dokumentation der [https://help.dyn.com/remote-access-api/perform-update/ Anfrage] und [https://help.dyn.com/remote-access-api/perform-update/ Antwortnachrichten].<br />
<br />
Das gesammte Protokoll sieht einen einzigen Nachrichtenaustausch aus Anfrage und Antwort vor. Die Anfrage kann mehrere Argumente enthalten; die Antwort kann verschiedene Code-Wörtern enthalten. Übrigens können in einer einzigen Anfrage mehrere DNS-Einträge gewünscht werden. In diesem Fall kann die Antwort mehrzeilig ausfallen.<br />
<br />
Das Verhalten von Server und Client bei künftigen Kommunikationsvorgängen wird unter Umständen von vorangegangenen Kommunikationsergebnissen beeinflußt: nach wiederholten fehlerhaften oder redundanten Anfragen kann der Server weitere Anfragen des Benutzers verweigern; nach wiederholten Fehlermeldungen sollte ein Client aufhören, immer dieselbe Anfrage zu schicken. Und für den Fall, daß mehrere Clients dynamische DNS-Einträge in derselben Domain example.com bestellen, muß der Server den Stand aller Client-Einträge intern speichern, damit er nicht mit einer neuen Zonefile einen früher erstellten Eintrag löscht. Zu diesen Fragen siehe den Abschnitt '''[[#Sukzessive_Kommunikationsabläufe]]''' nach der Beschreibung von Anfragen und Antworten unten.<br />
<br />
====Anfrage====<br />
<br />
Die Anfrage in Form eines URL übergibt dem DDNS-Programm in einem 'Query-String' einige Metavariablen. Das heißt, in einem URL der Form<br />
<br />
<nowiki>https://benutzername:passwort@ddns.beisiel.de/cgi-bin/ddns?hostname=einwahl.example.com&myip=87.65.43.21</nowiki><br />
<br />
signalisert das Fragezeichen, daß ein Query-String folgt. In einem solchen Query-String können in der Beispielimplementierung folgende Metavariablen definiert werden:<br />
<br />
{| class="wikitable"<br />
|- class="hintergrundfarbe5"<br />
! Variable !! Beispiel !! Bemerkungen<br />
|-<br />
| hostname || <tt>hostname=einwahl.example.com</tt><br /><div style="font-size:smaller;"><tt>hostname=eins.example.com,zwei.example.com[,...]</tt></div> ||<br />
Muß ein vollständig qualifizierter Domain-Name ("FQDN") sein; <tt>example.com</tt> muß eine vom Besitzer des DDNS-Programms verwaltete Domain sein. Genaugenommen kann der Wert eine durch Kommata gegliederte Liste mehrerer gültiger Domainnamen sein, falls mehrere Einträge mit derselben IP-Adresse gewünscht werden.<br />
|-<br />
| myip || <tt>myip=87.65.43.21</tt>||<br />
Kann entfallen; kann vom Server ignoriert werden. Maßgeblich ist dann die IP-Adresse des Absenders, wie sie vom Web-Server mitgeteilt wird.<br />
|-<br />
| mx || <tt>mx=87.65.43.21</tt><br /><tt>mx=NOCHG</tt><br /> ||<br />
Neben dem A-Eintrag möchte der Client auch einen MX-Eintrag. Der Wert <tt>NOCHG</tt> (für &bdquo;no change&ldquo;) bedeutet, der bestehende MX-Eintrag (oder seine Abwesenheit) soll nicht geändert werden. <br />
|-<br />
| backmx || <tt>backmx=YES</tt><br /><tt>backmx=NOCHG</tt><br /><tt>backmx=NO</tt> ||<br />
Falls <tt>YES</tt>, wird ein zweiter MX-Eintrag erzeugt, der <tt>einwahl.example.com</tt> als Mail-Server für <tt>einwahl.example.com</tt> nennt. Dieser Eintrag hat eine niedrigere Präferenzzahl (also eine höhere Priorität) als der mit <tt>mx</tt> angeforderten Eintrag.<br />
|-<br />
| wildcard || <tt>wildcard=ON</tt><br /><tt>wildcard=NOCHG</tt><br /><tt>wildcard=OFF</tt> ||<br />
Neben dem A-Eintrag für den Domainnamen <tt>einwahl.example.com</tt> wünscht der Client auch einen Eintrag für beliebige Subdomains, also <tt>*.einwahl.example.com</tt>, mit der gleichen IP-Adresse.<br />
|-<br />
| offline ||<tt>offline=YES</tt><br /><tt>offline=NOCHG</tt>||<br />
Falls <tt>YES</tt>, wird ein DNS-Eintrag für <tt>einwahl.example.com</tt> aus der Zonefile getilgt. Gegebenenfalls wird der Hostname dann auf Grund eines parallelen Wildcard-Eintrags für <tt>*.example.com</tt> einer anderen IP-Adresse zugeordnet werden.<br />
|}<br />
<br />
<!-- IPv6? --><br />
<br />
Alle Parameter bis auf hostname können entfallen. Bei nichtdokumentierten Argumenten ist das Verhalten undefiniert&trade;.<br />
<br />
====Antwort====<br />
<br />
Die Antwort auf eine erfolgreiche HTTP-Anfrage besteht im häufigsten Fall aus einigen Header-Zeilen, gefolgt vom Inhalt der gewünschten Text- oder andere Datei. Ein Status-Code in der ersten Header-Zeile gibt an, ob die Anfrage bedient werden kann oder kreist andernfalls den Grund für die Enttäuschung ein.<br />
<br />
Die vorliegende Beispielimplementierung von DDNS schickt einen der üblichen HTTP-Status-Codes "200 OK" oder "500 Internal Server Error", gefolgt von einer kurzen Textnachricht nach dem HTTP-Header. Bei diesem Programm ist &ndash; laut Gebrauchshinweise von DynDNS.org &ndash; ''nicht'' der Status-Code im Header, sondern der Inhalt der Nachricht die definierte, maßgebliche Ergebnismeldung des Programms.<br />
<br />
{| class="wikitable"<br />
|- class="hintergrundfarbe5"<br />
! Meldung !! Bedeutung !! Bemerkungen<br />
|-<br />
| <tt>good&nbsp;&lt;IP&nbsp;number&gt;</tt> ||<br />
Der gewünschte DNS-Eintrag wurde erfolgreich in einer Zonefile eingetragen. <br />
|| Es kann natürlich noch einige Minuten dauern, bis die Zonefile vom Hostsharing-Roboter abgelesen wird und der Inhalt in die BIND-Konfiguration übernommen.<br />
|-<br />
| <tt>good&nbsp;0.0.0.0</tt> ||<br />
Das Argument <tt>offline=YES</tt> wurde empfangen und verarbeitet.<br />
|| Der Domainname hat also keinen dynamischen DNS-Eintrag mehr.<br />
|-<br />
<!-- We don't do this!<br />
| <tt>good&nbsp;127.0.0.1</tt> ||<br />
Die Anfrage entsprach nicht den Erfordernissen des Servers.<br />
|| Trotz des Worts <tt>good</tt> war die Anfrage nicht erfolgreich, falls in der Rückmeldung die IP-Adresse mit <tt>127.0.0.1</tt> angegeben wird. Dieser verwirrende Fehlercode ist aus unerklärlichen Gründen in der Spezifikation von DynDNS.org so definiert.<br />
|-<br />
--><br />
| <tt>nochg&nbsp;&lt;IP&nbsp;number&gt;</tt> ||<br />
Der gewünschte DNS-Eintrag war bereits vorhanden. <br />
|| Der Server selbst macht keine DNS-Abfrage, um das zu vermitteln: die &bdquo;no change&ldquo;-Antwort besagt nur, daß eine Anfrage für diesen Eintrag bereits mit Erfolg quittiert wurde.<br />
|-<br />
| <tt>notfqdn</tt> ||<br />
Fehlschlag: der gewünschte Domainname ist nicht gültig, oder es wurde keiner angegeben.<br />
|| ...<br />
|-<br />
| <tt>nohost</tt> ||<br />
Fehlschlag: der gewünschte Domainname ist gehört nicht zu denen, die für diesen Benutzer des DDNS-Dienstes konfiguriert sind.<br />
|| Siehe den Abschnitt [[#Administration|Administration]] weiter unten.<br />
|-<br />
| <tt>badauth</tt> ||<br />
Fehlschlag: Die Kombination von Benutzernamen und Paßwort entsprach keinem DDNS-Account, oder das Account ist momentan gesperrt.<br />
|| Ein gesperrtes Account kann nur der Domain-Admin mittels des Administrationswerkzeugs wieder freigeben: siehe den Abschnit [[#Administration|Administration]] weiter unten.<br />
|-<br />
| <tt>abuse</tt> ||<br />
Fehlschlag: der gewünschte Domainname ist wegen vorangeganger Fehlschläge oder überflüssiger Aufrufe gesperrt.<br />
|| Siehe den Abschnitt [[Sukzessive_Kommunikationsabläufe|Sukzessive Kommunikationsabläufe]] unten.<br />
|-<br />
| <tt>911</tt> ||<br />
Fehlschlag: Das Server-Programm hat einen internen Fehler festgestellt.<br />
|| Das Problem liegt nicht in der Anfrage an sich.<br />
|}<br />
<br />
Man kann sich durchaus eine sinnreichere Kommunikation zwischen Client und Server vorstellen, doch das hier beschriebene Protokoll ist eben von DynDNS.org verwendet worden und wird in gängigen Routern implementiert, also wird es in der vorliegenden DDNS-Implementierung nachgebildet.<br />
<br />
=== Sukzessive Kommunikationsabläufe ===<br />
Der Server muß sich zwischen einzelnen Aufrufen einiges merken, um Ressourcen zu schonen und um zu verhindern, daß einmal vergebene DDNS-Einträge von neuen Anfragen, die dieselbe übergeordnete Domain betreffen, durch Überschreiben verlorengehen.<br />
<br />
==== Mißbrauch und Benutzersperrung ====<br />
Zur Schonung von Ressourcen muß sich die Implementierung weigern, sich mit zuvielen fehlerhaften oder auch nur überflüssigen Anfragen zu beschäftigen. Dazu führt eine Strichliste über solche Anfragen jedes Clients und sperrt nach einer bestimmten Anzahl solcher Anfragen den Benutzernamen oder einzelne Domainnamen gegen die weitere Nutzung des Dienstes.<br />
<br />
Mißbrauchspunkte gegen einen einzelnen Domainnamen gibt es für:<br />
* eine Anfrage, die keinen neuen DNS-Eintrag (und keine Änderung oder Löschung eines Eintrags) erfordert, sondern bestehende Merkmale nur wiederholt<br />
<br />
Mißbrauchspunkte gegen einen Benutzernamen gibt es für:<br />
* die Angabe eines Domainnamens, der in der Dienstkonfiguration dem anfragenden Benutzernamen nicht zugeordnet ist<br />
* die Angabe eines Domainnamen in einer Domain, die nicht demselben Hostsharing-Domain-Admin gehört, der den DDNS-Dienst anbietet<br />
* die Angabe eines Domainnamens, der in der Dienstkonfiguration bereits wegen mißbräuchlicher Anfragen gesperrt ist (siehe oben)<br />
<br />
Um eine Sperrung aufzuheben, wird in der Regel eine Handlung durch den Administrator erforderlich sein.<br />
<br />
==== Mehrere dynamische Subdomains in derselben Domain ====<br />
Sobald zwei verschiedene DDNS-Einträge in derselben Domain verlangt werden &ndash; beispielsweise home.example.com und office.example.com &ndash; wird es notwendig, bei jeder neuen Zonefile für example.com eventuell frühere Einträge zu konservieren. Der Rechner zu Hause weiß beim Bestellen seines DDNS-Eintrags nichts vom Rechner im Büro und umgekehrt. Der Server muß in irgendeiner Form über bereits vergebene Einträge Buch führen und bei einer neuen Anfrage, die example.com betrifft, alle bereits aktiven DDNS-Einträge für example.com mit in die neue Zonefile aufnehmen &ndash auch wenn sie auf Anfragen verschiedener Benutzer zurückgehen.<br />
<br />
==== Datenbank ====<br />
In der Beispielimplementierung werden diese Informationen in einer SQLite-Datenbank gespeichert.<br />
<br />
== Sicherheit ==<br />
=== Rechte ===<br />
Die '''Benutzerrechte''' werden durch das Hostsharing-System kontrolliert. Sowohl das CGI-Programm als auch das [[#Administration|Administrationswerkzeug]] werden mit den Rechten des Domain-Admins (xyz00-benutzername in unserem Beispiel) ausgeführt, also kann dieses Programm nur die Domains bearbeiten, die von xyz00-benutzername verwaltet werden.<br />
<br />
=== Authentifizierung ===<br />
In der Beispielimplementierung (wie auch seinerzeit bei DynDNS.org) wird das CGI-Programm durch einen .htaccess-Eintrag geschützt, der HTTP-Basic-Authentication vorschreibt. Also wird das Programm eigentlich mit einem URL der form<br />
<br />
<nowiki>https://ddnsaccount:passwort@ddns.example.com/cgi-bin/ddns?hostname=...</nowiki><br />
<br />
aufgerufen.<br />
<br />
=== Verschlüsselung ===<br />
Das CGI-Programm sollte nur in example.com/cgi-ssl/ installiert werden, nicht in example.com/cgi/. Damit ist die Kommunikation zwischen Client und Server durch SSL verschlüsselt.<br />
<br />
== Administration ==<br />
<br />
Der Verwalter des DDNS-Programms trägt berechtigte Benutzer und die ihnen zugeteilten Domainnamen in die Datenbank des Programms ein mit Hilfe eines kleinen Hilfsprogramms. Das ist im vorliegenden Fall ein menügesteuertes Programm für die Befehlszeile, daß die naheliegenden Funktionen anbietet: Account hinzufügen, löschen, sperren, entsperren, Paßwort setzen, ändern; Domainnamen hinzufügen, ändern, entsperren, löschen; Accounts und Domainnamen mit aktuellem Status auflisten. Die Funktionen sind auch über Befehlszeilenargumente verfügbar, also skriptfähig.<br />
<br />
Eine Auflistung des momentanen Inhalts der DDNS-Datenbank durch das Administrationswerkzeug könnte beispielsweise so aussehen:<br />
<br />
xyz00-benutzername@h02:~$ bin/ddnsadmin.pl -Aa<br />
1. papst Mißbrauch: 0; gesperrt: nein<br />
avignon.example.com<br />
zuletzt aktiv am Sun Apr 26 22:24:49 2020<br />
mit IP-Nr. 87.65.43.21; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 0; gesperrt: nein<br />
vatican.beispiel.de<br />
zuletzt aktiv am Sun Apr 26 22:24:49 2020<br />
mit IP-Nr. 87.65.43.21; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 0; gesperrt: nein<br />
2. kaiser Mißbrauch: 4; gesperrt: ja<br />
augsburg.beispiel.de<br />
zuletzt aktiv am Fri Apr 24 16:13:49 2020<br />
mit IP-Nr. 64.82.31.75; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 0; gesperrt: ja<br />
3. luther Mißbrauch: 1; gesperrt: nein<br />
wittenberg.example.com<br />
zuletzt aktiv am Mon Apr 27 10:12:49 2020<br />
mit IP-Nr. 78.56.34.12; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 1; gesperrt: nein<br />
xyz00-benutzername@h02:~$<br />
<br />
Das DDNS-Account &bdquo;kaiser&ldquo; in dieser Auflistung ist wohl auf Grund fehlerhafter Anfragen automatisch gesperrt worden. Der Inhaber wird sich wohl bald melden, um nach Korrektur seiner Client-Konfiguration die Aufhebung der Sperre zu wünschen.<br />
<br />
=== Log ===<br />
Alle Anfragen werden in einer täglich wechselnden Log-Datei protokolliert, entweder schlicht oder ausführlich, je nachdem, ob eine Variable <tt>verbose</tt> wahr ist.<br />
Ein ausführlicher Log-Eintrag sieht so aus:<br />
<br />
Sun Apr 26 20:21:45 2020 ddns aufgerufen von papst<br />
unter 84.185.97.8<br />
URL: <nowiki>https://ddns.example.com/cgi-bin/ddns.cgi?hostname=<br />
avignon.example.com,vatican.beispiel.de&<br />
myip=84.185.97.8</nowiki><br />
Verwende IP 84.185.97.8 (= 1421435144)<br />
DB-Version: 1<br />
Skript und DB exklusiv geöffnet<br />
avignon.example.com: IP: 84.185.97.8; MX: 0; Backup-MX: nein;<br />
Wildcard: nein; Mißbrauch: 0; gesperrt: nein <br />
vatican.beispiel.de: IP: 84.185.97.8; MX: 0; Backup-MX: nein;<br />
Wildcard: nein; Mißbrauch: 0; gesperrt: nein <br />
Betroffene Zonen: example.com, beispiel.de<br />
Temporärdatei example.com_hxNa.new geschrieben<br />
Zonendatei /home/pacs/xyz00/users/benutzername/doms/example.com/<br />
etc/pri.example.com eingestellt<br />
Temporärdatei beispiel.de_6HcO.new geschrieben<br />
Zonendatei /home/pacs/xyz00/users/benutzername/doms/beispiel.de/<br />
etc/pri.beispiel.de eingestellt<br />
Abgeschlossen: Fertig<br />
<br />
Wenn <tt>verbose</tt> auf falsch gesetzt ist, sind die Log-Einträge einzeilig.</div>Apc00-tonyhttps://wiki.hostsharing.net/index.php?title=Benutzer:Apc00-tony/Dynamisches_DNS&diff=5198Benutzer:Apc00-tony/Dynamisches DNS2020-04-29T09:31:38Z<p>Apc00-tony: /* Antwort */</p>
<hr />
<div>((Provisorischer Vorspann: Auf Grund einer Mailing-Listen-Diskussion habe ich angefangen, Dynamisches DNS über einen CGI-Skript bei Hostsharing zu realisieren. Meine Lösung habe ich dann vorgestellt; sie wurde für nicht ausreichend selbsterklärend befunden und fand wenig Akzeptanz. Hier also der Versuch, die Sache zu dokumentieren.))<br />
<br />
Mit der regelmäßigen Aufnahme von benutzerspezifischen Zonefiles in seiner DNS-Konfiguration bietet Hostsharing alles, was man braucht, um &bdquo;dynamisches DNS&ldquo; in Eigenregie zu realisieren.<br />
<br />
Das heißt, wenn ich mindestens eine Domain bei Hostsharing verwalte, und mindestens eine Einwahlverbindung (oder DSL-Verbindung) ins Internet mit wechselnder IP-Adresse über irgendeinen ISP für meinen Arbeitsplatzrechner zu Hause betreibe, dann kann ich dem Arbeitsplatzrechner über die DNS-Server von Hostsharing einen vollqualifizieren Domainnamen zuweisen, der der jeweiligen IP-Adresse meiner Einwahlleitung zugeordnet ist.<br />
<br />
<pre><br />
<br />
(ASCII-Art-Diagramm der beschriebenen Konstellation)<br />
<br />
</pre><br />
<br />
Im Folgenden wird eine real existierende Implementierung von Dynamischem DNS (&bdquo;DDNS&ldquo;) beschrieben. Die verschiedenen Elemente könnten durchaus anders realisiert werden; die beschriebene Implementierung könnte durchaus verbessert werden. Sie dient hier der Illustration.<br />
<br />
In der folgenden Beschreibung werden diese Beispielwerte benutzt:<br />
* Ein Hostsharing-Mitglied hat ein Account als Paket-Admin mit Kennung xyz00.<br />
* Im Paket xyz00 gibt es einen Domain-Admin namens xyz00-benutzername.<br />
* Dieser Domain-Admin verwaltet bei Hostsharing die Domains example.com und beispiel.de.<br />
* Ein Benutzer hat zu Hause (oder im Büro) einen Arbeitsplatzrechner hinter der marktüblichen DSL-Leitung, die von seinem ISP bereitgestellt wird.<br />
* Dieser Arbeitsplatzrechner (oder der Router, der seine Internetverbindung steuert) bekommt vom ISP immer wechselnde IP-Adressen zugewiesen.<br />
* Dennoch möchte der Benutzer seinen Arbeitsplatzrechner aus dem Internet unter dem Hostnamen einwahl.example.com ansprechen können.<br />
<br />
Dazu kann ein System wie Hostsharing, das authoritative DNS-Informationen für viele Domains bereitstellt, auch veränderliche DNS-Information über dynamisch verbundene Rechner verwalten &ndash; sofern das ressourcenschonend gemacht werden kann ohne andere Funktionen zu stören.<br />
<br />
== Aufgaben des Servers ==<br />
<br />
Um einem Rechner mit wechselnder IP-Adresse einen DDNS-Eintrag zu bieten, muß der Hostsharing-Server folgendes leisten (in ungefährer Reihenfolge der Ereignisse):<br />
<br />
# Eine Anfrage entgegennehmen, beispielsweise über HTTPS, von einem entfernten Rechner, der einen DNS-Eintrag für seine momentane IP-Adresse wünscht. <br />
# Prüfen, ob die Anfrage einen berechtigten DDNS-Dienst-Usernamen mit zugehörigem Paßwort enthält.<br />
# Prüfen, ob die Anfrage einen gültigen Domainnamen betrifft, den der Server bieten darf.<br />
# Prüfen, ob die Domain example.com demselben Benutzer gehört, unter dessen Namen der Dynamisches-DNS-Server läuft.<br />
# Eine gültige [[Zonefile]] mit &ndash; neben dem bisherigen Inhalt &ndash; einem A-Eintrag für einwahl.example.com in /home/pacs/xyz00/users/benutzername/doms/example.com/pri.example.com schreiben.<br />
# Dem Client eine Bestätigung oder ggf. eine Fehlermeldung als Antwort senden.<br />
# In irgendeiner Datenbank den momentan eingestellter Status all seiner DDNS-Einträge speichern.<br />
# In einer Logdatei protokollieren, daß obiges getan wurde, oder ggf. welche Fehler traten auf.<br />
<br />
== Aufgaben des Clients ==<br />
Bevor ich anfange, meinen Arbeitsplatzrechner so zu konfigurieren, daß er bei welchem Server auch immer einen DDNS-Eintrag anfordert, muß ich mich als verantwortlicher Benutzer dieses Rechners und der dazugehörigen Internetverbindung &ndash; das heißt, als Mensch &ndash; mit dem Betreiber des dynamisches-DNS-Servers vereinbaren, daß ich das darf und welchen Eintrag ich bekommen kann. Im Folgenden wird vorausgesetzt, daß solche Vereinbarungen getroffen und die Parameter geklärt wurden.<br />
<br />
Der DDNS-Client muß aus Server-Sicht nur wenig leisten:<br />
<br />
# Eine Anfrage senden, beispielsweise über HTTPS, an einen entfernten Rechner, der einen Eintrag ins DNS für die momentane IP-Adresse des Clients vornehmen kann.<br />Diese Anfrage muß einem festgelegten Format entsprechen und muß gültige Werte für die Authorisation des Clients, den gewünschten Domainnamen, und eventuell andere Parameter enthalten.<br />
# Eine Antwort des Servers entgegennehmen und als Erfolgs- oder Fehlermeldung auswerten.<br />
# Von überflüssigen Anfragen absehen: das heißt bei Erfolg, nicht wiederholt den gleichen Eintrag erneut wünschen; bei Fehlern, nicht die gleiche fehlerhafte Anfrage erneut schicken.<br />
<br />
== Kommunikation zwischen Client und Server ==<br />
<br />
Ein einziges Nachrichtenpaar von Anfrage und Antwort genügt, um einen DDNS-Eintrag einzurichten: Der Client teilt die IP-Adresse und den Domainnamen mit, die in einem DNS-Eintrag verbunden werden sollen; der Server bestätigt den Auftrag.<br />
<br />
In der Beispielimplementierung erfolgt die Kommunikation über HTTP, und die Anfrage des Clients könnte so aussehen:<br />
<br />
GET /cgi-bin/ddns?hostname=einwahl.example.com&myip=87.65.43.21 HTTP/1.1<br />
Host: ddns.beispiel.de<br />
User-Agent: Fritz!Box DDNS/1.0.1<br />
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==<br />
<br />
Bei Erhalt dieser Anfrage ruft Apache das CGI-Programm .../doms/ddns.beispiel.de/cgi-ssl/ddns auf. Das Fragezeichen trennt den Programmnamen von einem "Query-String", in dem zwei Metavariablen definiert und übergeben werden. Die erste Metavariable, hostname, hat den Wert "einwahl.example.com"; die zweite, myip, hat den Wert "87.65.43.21".<br />
<br />
Das Server-Programm, hier ''ddns'', prüft diese Informationen auf Form und Berechtigung, und schreibt gegebenenfalls einen entsprechenden Eintrag in einer Zonefile. Es schreibt auch verschiedene Informationen in die Standardausgabe. Wenn es die Standardausgabe geschlossen wird &ndash; also spätestens bei Programmende &ndash; schickt Apache diese Informationen als Antwort an den anfragenden Rechner zurück.<br />
<br />
Im Falle unserer Beispielimplementierung sieht die Antwort bei Erfolg so aus: <br />
<br />
HTTP/1.1 200 OK<br />
Date: Wed, 22 Apr 2020 08:35:15 GMT<br />
Server: Apache<br />
Content-Length: 17<br />
Content-Type: text/plain; charset=ISO-8859-1<br />
<br />
good 87.65.43.21<br />
<br />
=== Das DDNS-Protokoll von DynDNS.org ===<br />
<br />
In den 90er Jahren, bevor das Internet so durchgehend vergeschäftlicht wurde, boten einige Organisationen kostenlose DDNS-Dienste an. Ein sehr beliebtes Angebot war das von DynDNS.org. Das DDNS-Protokoll von diesem Dienst wurde sogar in Einwahl-Routern einprogrammiert und der Dienst wurde von ISPs und Router-Herstellern als Leistungsmerkmal beworben.<br />
<br />
DynDNS.org gehört inzwischen Oracle und bietet keine kostenlose Dienste mehr. Dennoch wird das DDNS-Protokoll von DynDNS.org in der vorliegenden Beispielimplementierung übernommen in der Hoffnung, daß die Kompatibilität mit einigen gängigen Einwahl-Routern von Vorteil sein kann. Es gibt noch eine kurze Online-Dokumentation der [https://help.dyn.com/remote-access-api/perform-update/ Anfrage] und [https://help.dyn.com/remote-access-api/perform-update/ Antwortnachrichten].<br />
<br />
Das gesammte Protokoll sieht einen einzigen Nachrichtenaustausch aus Anfrage und Antwort vor. Die Anfrage kann mehrere Argumente enthalten; die Antwort kann verschiedene Code-Wörtern enthalten. Übrigens können in einer einzigen Anfrage mehrere DNS-Einträge gewünscht werden. In diesem Fall kann die Antwort mehrzeilig ausfallen.<br />
<br />
Das Verhalten von Server und Client bei künftigen Kommunikationsvorgängen wird unter Umständen von vorangegangenen Kommunikationsergebnissen beeinflußt: nach wiederholten fehlerhaften oder redundanten Anfragen kann der Server weitere Anfragen des Benutzers verweigern; nach wiederholten Fehlermeldungen sollte ein Client aufhören, immer dieselbe Anfrage zu schicken. Und für den Fall, daß mehrere Clients dynamische DNS-Einträge in derselben Domain example.com bestellen, muß der Server den Stand aller Client-Einträge intern speichern, damit er nicht mit einer neuen Zonefile einen früher erstellten Eintrag löscht. Zu diesen Fragen siehe den Abschnitt '''[[#Sukzessive_Kommunikationsabläufe]]''' nach der Beschreibung von Anfragen und Antworten unten.<br />
<br />
====Anfrage====<br />
<br />
Die Anfrage in Form eines URL übergibt dem DDNS-Programm in einem 'Query-String' einige Metavariablen. Das heißt, in einem URL der Form<br />
<br />
<nowiki>https://benutzername:passwort@ddns.beisiel.de/cgi-bin/ddns?hostname=einwahl.example.com&myip=87.65.43.21</nowiki><br />
<br />
signalisert das Fragezeichen, daß ein Query-String folgt. In einem solchen Query-String können in der Beispielimplementierung folgende Metavariablen definiert werden:<br />
<br />
{| class="wikitable"<br />
|- class="hintergrundfarbe5"<br />
! Variable !! Beispiel !! Bemerkungen<br />
|-<br />
| hostname || <tt>hostname=einwahl.example.com</tt><br /><div style="font-size:smaller;"><tt>hostname=eins.example.com,zwei.example.com[,...]</tt></div> ||<br />
Muß ein vollständig qualifizierter Domain-Name ("FQDN") sein; <tt>example.com</tt> muß eine vom Besitzer des DDNS-Programms verwaltete Domain sein. Genaugenommen kann der Wert eine durch Kommata gegliederte Liste mehrerer gültiger Domainnamen sein, falls mehrere Einträge mit derselben IP-Adresse gewünscht werden.<br />
|-<br />
| myip || <tt>myip=87.65.43.21</tt>||<br />
Kann entfallen; kann vom Server ignoriert werden. Maßgeblich ist dann die IP-Adresse des Absenders, wie sie vom Web-Server mitgeteilt wird.<br />
|-<br />
| mx || <tt>mx=87.65.43.21</tt><br /><tt>mx=NOCHG</tt><br /> ||<br />
Neben dem A-Eintrag möchte der Client auch einen MX-Eintrag. Der Wert <tt>NOCHG</tt> (für &bdquo;no change&ldquo;) bedeutet, der bestehende MX-Eintrag (oder seine Abwesenheit) soll nicht geändert werden. <br />
|-<br />
| backmx || <tt>backmx=YES</tt><br /><tt>backmx=NOCHG</tt><br /><tt>backmx=NO</tt> ||<br />
Falls <tt>YES</tt>, wird ein zweiter MX-Eintrag erzeugt, der <tt>einwahl.example.com</tt> als Mail-Server für <tt>einwahl.example.com</tt> nennt. Dieser Eintrag hat eine niedrigere Präferenzzahl (also eine höhere Priorität) als der mit <tt>mx</tt> angeforderten Eintrag.<br />
|-<br />
| wildcard || <tt>wildcard=ON</tt><br /><tt>wildcard=NOCHG</tt><br /><tt>wildcard=OFF</tt> ||<br />
Neben dem A-Eintrag für den Domainnamen <tt>einwahl.example.com</tt> wünscht der Client auch einen Eintrag für beliebige Subdomains, also <tt>*.einwahl.example.com</tt>, mit der gleichen IP-Adresse.<br />
|-<br />
| offline ||<tt>offline=YES</tt><br /><tt>offline=NOCHG</tt>||<br />
Falls <tt>YES</tt>, wird ein DNS-Eintrag für <tt>einwahl.example.com</tt> aus der Zonefile getilgt. Gegebenenfalls wird der Hostname dann auf Grund eines parallelen Wildcard-Eintrags für <tt>*.example.com</tt> einer anderen IP-Adresse zugeordnet werden.<br />
|}<br />
<br />
<!-- IPv6? --><br />
<br />
Alle Parameter bis auf hostname können entfallen. Bei nichtdokumentierten Argumenten ist das Verhalten undefiniert&trade;.<br />
<br />
====Antwort====<br />
<br />
Die Antwort auf eine erfolgreiche HTTP-Anfrage besteht im häufigsten Fall aus einigen Header-Zeilen, gefolgt vom Inhalt der gewünschten Text- oder andere Datei. Ein Status-Code in der ersten Header-Zeile gibt an, ob die Anfrage bedient werden kann oder kreist andernfalls den Grund für die Enttäuschung ein.<br />
<br />
Die vorliegende Beispielimplementierung von DDNS schickt einen der üblichen HTTP-Status-Codes "200 OK" oder "500 Internal Server Error", gefolgt von einer kurzen Textnachricht nach dem HTTP-Header. Bei diesem Programm ist &ndash; laut Gebrauchshinweise von DynDNS.org &ndash; ''nicht'' der Status-Code im Header, sondern der Inhalt der Nachricht die definierte, maßgebliche Ergebnismeldung des Programms.<br />
<br />
{| class="wikitable"<br />
|- class="hintergrundfarbe5"<br />
! Meldung !! Bedeutung !! Bemerkungen<br />
|-<br />
| <tt>good&nbsp;&lt;IP&nbsp;number&gt;</tt> ||<br />
Der gewünschte DNS-Eintrag wurde erfolgreich in einer Zonefile eingetragen. <br />
|| Es kann natürlich noch einige Minuten dauern, bis die Zonefile vom Hostsharing-Roboter abgelesen wird und der Inhalt in die BIND-Konfiguration übernommen.<br />
|-<br />
| <tt>good&nbsp;0.0.0.0</tt> ||<br />
Das Argument <tt>offline=YES</tt> wurde empfangen und verarbeitet.<br />
|| Der Domainname hat also keinen dynamischen DNS-Eintrag mehr.<br />
|-<br />
| <tt>good&nbsp;127.0.0.1</tt> ||<br />
Die Anfrage entsprach nicht den Erfordernissen des Servers.<br />
|| Trotz des Worts <tt>good</tt> war die Anfrage nicht erfolgreich, falls in der Rückmeldung die IP-Adresse mit <tt>127.0.0.1</tt> angegeben wird. Dieser verwirrende Fehlercode ist aus unerklärlichen Gründen in der Spezifikation von DynDNS.org so definiert.<br />
|-<br />
| <tt>nochg&nbsp;&lt;IP&nbsp;number&gt;</tt> ||<br />
Der gewünschte DNS-Eintrag war bereits vorhanden. <br />
|| Der Server selbst macht keine DNS-Abfrage, um das zu vermitteln: die &bdquo;no change&ldquo;-Antwort besagt nur, daß eine Anfrage für diesen Eintrag bereits mit Erfolg quittiert wurde.<br />
|-<br />
| <tt>notfqdn</tt> ||<br />
Fehlschlag: der gewünschte Domainname ist nicht gültig, oder es wurde keiner angegeben.<br />
|| ...<br />
|-<br />
| <tt>nohost</tt> ||<br />
Fehlschlag: der gewünschte Domainname ist gehört nicht zu denen, die für diesen Benutzer des DDNS-Dienstes konfiguriert sind.<br />
|| Siehe den Abschnitt [[#Administration|Administration]] weiter unten.<br />
|-<br />
| <tt>badauth</tt> ||<br />
Fehlschlag: Die Kombination von Benutzernamen und Paßwort entsprach keinem DDNS-Account, oder das Account ist momentan gesperrt.<br />
|| Ein gesperrtes Account kann nur der Domain-Admin mittels des Administrationswerkzeugs wieder freigeben: siehe den Abschnit [[#Administration|Administration]] weiter unten.<br />
|-<br />
| <tt>abuse</tt> ||<br />
Fehlschlag: der gewünschte Domainname ist wegen vorangeganger Fehlschläge oder überflüssiger Aufrufe gesperrt.<br />
|| Siehe den Abschnitt [[Sukzessive_Kommunikationsabläufe|Sukzessive Kommunikationsabläufe]] unten.<br />
|-<br />
| <tt>911</tt> ||<br />
Fehlschlag: Das Server-Programm hat einen internen Fehler festgestellt.<br />
|| Das Problem liegt nicht in der Anfrage an sich.<br />
|}<br />
<br />
Man kann sich durchaus eine sinnreichere Kommunikation zwischen Client und Server vorstellen, doch das hier beschriebene Protokoll ist eben von DynDNS.org verwendet worden und wird in gängigen Routern implementiert, also wird es in der vorliegenden DDNS-Implementierung nachgebildet.<br />
<br />
=== Sukzessive Kommunikationsabläufe ===<br />
Der Server muß sich zwischen einzelnen Aufrufen einiges merken, um Ressourcen zu schonen und um zu verhindern, daß einmal vergebene DDNS-Einträge von neuen Anfragen, die dieselbe übergeordnete Domain betreffen, durch Überschreiben verlorengehen.<br />
<br />
==== Mißbrauch und Benutzersperrung ====<br />
Zur Schonung von Ressourcen muß sich die Implementierung weigern, sich mit zuvielen fehlerhaften oder auch nur überflüssigen Anfragen zu beschäftigen. Dazu führt eine Strichliste über solche Anfragen jedes Clients und sperrt nach einer bestimmten Anzahl solcher Anfragen den Benutzernamen oder einzelne Domainnamen gegen die weitere Nutzung des Dienstes.<br />
<br />
Mißbrauchspunkte gegen einen einzelnen Domainnamen gibt es für:<br />
* eine Anfrage, die keinen neuen DNS-Eintrag (und keine Änderung oder Löschung eines Eintrags) erfordert, sondern bestehende Merkmale nur wiederholt<br />
<br />
Mißbrauchspunkte gegen einen Benutzernamen gibt es für:<br />
* die Angabe eines Domainnamens, der in der Dienstkonfiguration dem anfragenden Benutzernamen nicht zugeordnet ist<br />
* die Angabe eines Domainnamen in einer Domain, die nicht demselben Hostsharing-Domain-Admin gehört, der den DDNS-Dienst anbietet<br />
* die Angabe eines Domainnamens, der in der Dienstkonfiguration bereits wegen mißbräuchlicher Anfragen gesperrt ist (siehe oben)<br />
<br />
Um eine Sperrung aufzuheben, wird in der Regel eine Handlung durch den Administrator erforderlich sein.<br />
<br />
==== Mehrere dynamische Subdomains in derselben Domain ====<br />
Sobald zwei verschiedene DDNS-Einträge in derselben Domain verlangt werden &ndash; beispielsweise home.example.com und office.example.com &ndash; wird es notwendig, bei jeder neuen Zonefile für example.com eventuell frühere Einträge zu konservieren. Der Rechner zu Hause weiß beim Bestellen seines DDNS-Eintrags nichts vom Rechner im Büro und umgekehrt. Der Server muß in irgendeiner Form über bereits vergebene Einträge Buch führen und bei einer neuen Anfrage, die example.com betrifft, alle bereits aktiven DDNS-Einträge für example.com mit in die neue Zonefile aufnehmen &ndash auch wenn sie auf Anfragen verschiedener Benutzer zurückgehen.<br />
<br />
==== Datenbank ====<br />
In der Beispielimplementierung werden diese Informationen in einer SQLite-Datenbank gespeichert.<br />
<br />
== Sicherheit ==<br />
=== Rechte ===<br />
Die '''Benutzerrechte''' werden durch das Hostsharing-System kontrolliert. Sowohl das CGI-Programm als auch das [[#Administration|Administrationswerkzeug]] werden mit den Rechten des Domain-Admins (xyz00-benutzername in unserem Beispiel) ausgeführt, also kann dieses Programm nur die Domains bearbeiten, die von xyz00-benutzername verwaltet werden.<br />
<br />
=== Authentifizierung ===<br />
In der Beispielimplementierung (wie auch seinerzeit bei DynDNS.org) wird das CGI-Programm durch einen .htaccess-Eintrag geschützt, der HTTP-Basic-Authentication vorschreibt. Also wird das Programm eigentlich mit einem URL der form<br />
<br />
<nowiki>https://ddnsaccount:passwort@ddns.example.com/cgi-bin/ddns?hostname=...</nowiki><br />
<br />
aufgerufen.<br />
<br />
=== Verschlüsselung ===<br />
Das CGI-Programm sollte nur in example.com/cgi-ssl/ installiert werden, nicht in example.com/cgi/. Damit ist die Kommunikation zwischen Client und Server durch SSL verschlüsselt.<br />
<br />
== Administration ==<br />
<br />
Der Verwalter des DDNS-Programms trägt berechtigte Benutzer und die ihnen zugeteilten Domainnamen in die Datenbank des Programms ein mit Hilfe eines kleinen Hilfsprogramms. Das ist im vorliegenden Fall ein menügesteuertes Programm für die Befehlszeile, daß die naheliegenden Funktionen anbietet: Account hinzufügen, löschen, sperren, entsperren, Paßwort setzen, ändern; Domainnamen hinzufügen, ändern, entsperren, löschen; Accounts und Domainnamen mit aktuellem Status auflisten. Die Funktionen sind auch über Befehlszeilenargumente verfügbar, also skriptfähig.<br />
<br />
Eine Auflistung des momentanen Inhalts der DDNS-Datenbank durch das Administrationswerkzeug könnte beispielsweise so aussehen:<br />
<br />
xyz00-benutzername@h02:~$ bin/ddnsadmin.pl -Aa<br />
1. papst Mißbrauch: 0; gesperrt: nein<br />
avignon.example.com<br />
zuletzt aktiv am Sun Apr 26 22:24:49 2020<br />
mit IP-Nr. 87.65.43.21; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 0; gesperrt: nein<br />
vatican.beispiel.de<br />
zuletzt aktiv am Sun Apr 26 22:24:49 2020<br />
mit IP-Nr. 87.65.43.21; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 0; gesperrt: nein<br />
2. kaiser Mißbrauch: 4; gesperrt: ja<br />
augsburg.beispiel.de<br />
zuletzt aktiv am Fri Apr 24 16:13:49 2020<br />
mit IP-Nr. 64.82.31.75; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 0; gesperrt: ja<br />
3. luther Mißbrauch: 1; gesperrt: nein<br />
wittenberg.example.com<br />
zuletzt aktiv am Mon Apr 27 10:12:49 2020<br />
mit IP-Nr. 78.56.34.12; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 1; gesperrt: nein<br />
xyz00-benutzername@h02:~$<br />
<br />
Das DDNS-Account &bdquo;kaiser&ldquo; in dieser Auflistung ist wohl auf Grund fehlerhafter Anfragen automatisch gesperrt worden. Der Inhaber wird sich wohl bald melden, um nach Korrektur seiner Client-Konfiguration die Aufhebung der Sperre zu wünschen.<br />
<br />
=== Log ===<br />
Alle Anfragen werden in einer täglich wechselnden Log-Datei protokolliert, entweder schlicht oder ausführlich, je nachdem, ob eine Variable <tt>verbose</tt> wahr ist.<br />
Ein ausführlicher Log-Eintrag sieht so aus:<br />
<br />
Sun Apr 26 20:21:45 2020 ddns aufgerufen von papst<br />
unter 84.185.97.8<br />
URL: <nowiki>https://ddns.example.com/cgi-bin/ddns.cgi?hostname=<br />
avignon.example.com,vatican.beispiel.de&<br />
myip=84.185.97.8</nowiki><br />
Verwende IP 84.185.97.8 (= 1421435144)<br />
DB-Version: 1<br />
Skript und DB exklusiv geöffnet<br />
avignon.example.com: IP: 84.185.97.8; MX: 0; Backup-MX: nein;<br />
Wildcard: nein; Mißbrauch: 0; gesperrt: nein <br />
vatican.beispiel.de: IP: 84.185.97.8; MX: 0; Backup-MX: nein;<br />
Wildcard: nein; Mißbrauch: 0; gesperrt: nein <br />
Betroffene Zonen: example.com, beispiel.de<br />
Temporärdatei example.com_hxNa.new geschrieben<br />
Zonendatei /home/pacs/xyz00/users/benutzername/doms/example.com/<br />
etc/pri.example.com eingestellt<br />
Temporärdatei beispiel.de_6HcO.new geschrieben<br />
Zonendatei /home/pacs/xyz00/users/benutzername/doms/beispiel.de/<br />
etc/pri.beispiel.de eingestellt<br />
Abgeschlossen: Fertig<br />
<br />
Wenn <tt>verbose</tt> auf falsch gesetzt ist, sind die Log-Einträge einzeilig.</div>Apc00-tonyhttps://wiki.hostsharing.net/index.php?title=Benutzer:Apc00-tony/Dynamisches_DNS&diff=5197Benutzer:Apc00-tony/Dynamisches DNS2020-04-29T09:30:22Z<p>Apc00-tony: /* Antwort */</p>
<hr />
<div>((Provisorischer Vorspann: Auf Grund einer Mailing-Listen-Diskussion habe ich angefangen, Dynamisches DNS über einen CGI-Skript bei Hostsharing zu realisieren. Meine Lösung habe ich dann vorgestellt; sie wurde für nicht ausreichend selbsterklärend befunden und fand wenig Akzeptanz. Hier also der Versuch, die Sache zu dokumentieren.))<br />
<br />
Mit der regelmäßigen Aufnahme von benutzerspezifischen Zonefiles in seiner DNS-Konfiguration bietet Hostsharing alles, was man braucht, um &bdquo;dynamisches DNS&ldquo; in Eigenregie zu realisieren.<br />
<br />
Das heißt, wenn ich mindestens eine Domain bei Hostsharing verwalte, und mindestens eine Einwahlverbindung (oder DSL-Verbindung) ins Internet mit wechselnder IP-Adresse über irgendeinen ISP für meinen Arbeitsplatzrechner zu Hause betreibe, dann kann ich dem Arbeitsplatzrechner über die DNS-Server von Hostsharing einen vollqualifizieren Domainnamen zuweisen, der der jeweiligen IP-Adresse meiner Einwahlleitung zugeordnet ist.<br />
<br />
<pre><br />
<br />
(ASCII-Art-Diagramm der beschriebenen Konstellation)<br />
<br />
</pre><br />
<br />
Im Folgenden wird eine real existierende Implementierung von Dynamischem DNS (&bdquo;DDNS&ldquo;) beschrieben. Die verschiedenen Elemente könnten durchaus anders realisiert werden; die beschriebene Implementierung könnte durchaus verbessert werden. Sie dient hier der Illustration.<br />
<br />
In der folgenden Beschreibung werden diese Beispielwerte benutzt:<br />
* Ein Hostsharing-Mitglied hat ein Account als Paket-Admin mit Kennung xyz00.<br />
* Im Paket xyz00 gibt es einen Domain-Admin namens xyz00-benutzername.<br />
* Dieser Domain-Admin verwaltet bei Hostsharing die Domains example.com und beispiel.de.<br />
* Ein Benutzer hat zu Hause (oder im Büro) einen Arbeitsplatzrechner hinter der marktüblichen DSL-Leitung, die von seinem ISP bereitgestellt wird.<br />
* Dieser Arbeitsplatzrechner (oder der Router, der seine Internetverbindung steuert) bekommt vom ISP immer wechselnde IP-Adressen zugewiesen.<br />
* Dennoch möchte der Benutzer seinen Arbeitsplatzrechner aus dem Internet unter dem Hostnamen einwahl.example.com ansprechen können.<br />
<br />
Dazu kann ein System wie Hostsharing, das authoritative DNS-Informationen für viele Domains bereitstellt, auch veränderliche DNS-Information über dynamisch verbundene Rechner verwalten &ndash; sofern das ressourcenschonend gemacht werden kann ohne andere Funktionen zu stören.<br />
<br />
== Aufgaben des Servers ==<br />
<br />
Um einem Rechner mit wechselnder IP-Adresse einen DDNS-Eintrag zu bieten, muß der Hostsharing-Server folgendes leisten (in ungefährer Reihenfolge der Ereignisse):<br />
<br />
# Eine Anfrage entgegennehmen, beispielsweise über HTTPS, von einem entfernten Rechner, der einen DNS-Eintrag für seine momentane IP-Adresse wünscht. <br />
# Prüfen, ob die Anfrage einen berechtigten DDNS-Dienst-Usernamen mit zugehörigem Paßwort enthält.<br />
# Prüfen, ob die Anfrage einen gültigen Domainnamen betrifft, den der Server bieten darf.<br />
# Prüfen, ob die Domain example.com demselben Benutzer gehört, unter dessen Namen der Dynamisches-DNS-Server läuft.<br />
# Eine gültige [[Zonefile]] mit &ndash; neben dem bisherigen Inhalt &ndash; einem A-Eintrag für einwahl.example.com in /home/pacs/xyz00/users/benutzername/doms/example.com/pri.example.com schreiben.<br />
# Dem Client eine Bestätigung oder ggf. eine Fehlermeldung als Antwort senden.<br />
# In irgendeiner Datenbank den momentan eingestellter Status all seiner DDNS-Einträge speichern.<br />
# In einer Logdatei protokollieren, daß obiges getan wurde, oder ggf. welche Fehler traten auf.<br />
<br />
== Aufgaben des Clients ==<br />
Bevor ich anfange, meinen Arbeitsplatzrechner so zu konfigurieren, daß er bei welchem Server auch immer einen DDNS-Eintrag anfordert, muß ich mich als verantwortlicher Benutzer dieses Rechners und der dazugehörigen Internetverbindung &ndash; das heißt, als Mensch &ndash; mit dem Betreiber des dynamisches-DNS-Servers vereinbaren, daß ich das darf und welchen Eintrag ich bekommen kann. Im Folgenden wird vorausgesetzt, daß solche Vereinbarungen getroffen und die Parameter geklärt wurden.<br />
<br />
Der DDNS-Client muß aus Server-Sicht nur wenig leisten:<br />
<br />
# Eine Anfrage senden, beispielsweise über HTTPS, an einen entfernten Rechner, der einen Eintrag ins DNS für die momentane IP-Adresse des Clients vornehmen kann.<br />Diese Anfrage muß einem festgelegten Format entsprechen und muß gültige Werte für die Authorisation des Clients, den gewünschten Domainnamen, und eventuell andere Parameter enthalten.<br />
# Eine Antwort des Servers entgegennehmen und als Erfolgs- oder Fehlermeldung auswerten.<br />
# Von überflüssigen Anfragen absehen: das heißt bei Erfolg, nicht wiederholt den gleichen Eintrag erneut wünschen; bei Fehlern, nicht die gleiche fehlerhafte Anfrage erneut schicken.<br />
<br />
== Kommunikation zwischen Client und Server ==<br />
<br />
Ein einziges Nachrichtenpaar von Anfrage und Antwort genügt, um einen DDNS-Eintrag einzurichten: Der Client teilt die IP-Adresse und den Domainnamen mit, die in einem DNS-Eintrag verbunden werden sollen; der Server bestätigt den Auftrag.<br />
<br />
In der Beispielimplementierung erfolgt die Kommunikation über HTTP, und die Anfrage des Clients könnte so aussehen:<br />
<br />
GET /cgi-bin/ddns?hostname=einwahl.example.com&myip=87.65.43.21 HTTP/1.1<br />
Host: ddns.beispiel.de<br />
User-Agent: Fritz!Box DDNS/1.0.1<br />
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==<br />
<br />
Bei Erhalt dieser Anfrage ruft Apache das CGI-Programm .../doms/ddns.beispiel.de/cgi-ssl/ddns auf. Das Fragezeichen trennt den Programmnamen von einem "Query-String", in dem zwei Metavariablen definiert und übergeben werden. Die erste Metavariable, hostname, hat den Wert "einwahl.example.com"; die zweite, myip, hat den Wert "87.65.43.21".<br />
<br />
Das Server-Programm, hier ''ddns'', prüft diese Informationen auf Form und Berechtigung, und schreibt gegebenenfalls einen entsprechenden Eintrag in einer Zonefile. Es schreibt auch verschiedene Informationen in die Standardausgabe. Wenn es die Standardausgabe geschlossen wird &ndash; also spätestens bei Programmende &ndash; schickt Apache diese Informationen als Antwort an den anfragenden Rechner zurück.<br />
<br />
Im Falle unserer Beispielimplementierung sieht die Antwort bei Erfolg so aus: <br />
<br />
HTTP/1.1 200 OK<br />
Date: Wed, 22 Apr 2020 08:35:15 GMT<br />
Server: Apache<br />
Content-Length: 17<br />
Content-Type: text/plain; charset=ISO-8859-1<br />
<br />
good 87.65.43.21<br />
<br />
=== Das DDNS-Protokoll von DynDNS.org ===<br />
<br />
In den 90er Jahren, bevor das Internet so durchgehend vergeschäftlicht wurde, boten einige Organisationen kostenlose DDNS-Dienste an. Ein sehr beliebtes Angebot war das von DynDNS.org. Das DDNS-Protokoll von diesem Dienst wurde sogar in Einwahl-Routern einprogrammiert und der Dienst wurde von ISPs und Router-Herstellern als Leistungsmerkmal beworben.<br />
<br />
DynDNS.org gehört inzwischen Oracle und bietet keine kostenlose Dienste mehr. Dennoch wird das DDNS-Protokoll von DynDNS.org in der vorliegenden Beispielimplementierung übernommen in der Hoffnung, daß die Kompatibilität mit einigen gängigen Einwahl-Routern von Vorteil sein kann. Es gibt noch eine kurze Online-Dokumentation der [https://help.dyn.com/remote-access-api/perform-update/ Anfrage] und [https://help.dyn.com/remote-access-api/perform-update/ Antwortnachrichten].<br />
<br />
Das gesammte Protokoll sieht einen einzigen Nachrichtenaustausch aus Anfrage und Antwort vor. Die Anfrage kann mehrere Argumente enthalten; die Antwort kann verschiedene Code-Wörtern enthalten. Übrigens können in einer einzigen Anfrage mehrere DNS-Einträge gewünscht werden. In diesem Fall kann die Antwort mehrzeilig ausfallen.<br />
<br />
Das Verhalten von Server und Client bei künftigen Kommunikationsvorgängen wird unter Umständen von vorangegangenen Kommunikationsergebnissen beeinflußt: nach wiederholten fehlerhaften oder redundanten Anfragen kann der Server weitere Anfragen des Benutzers verweigern; nach wiederholten Fehlermeldungen sollte ein Client aufhören, immer dieselbe Anfrage zu schicken. Und für den Fall, daß mehrere Clients dynamische DNS-Einträge in derselben Domain example.com bestellen, muß der Server den Stand aller Client-Einträge intern speichern, damit er nicht mit einer neuen Zonefile einen früher erstellten Eintrag löscht. Zu diesen Fragen siehe den Abschnitt '''[[#Sukzessive_Kommunikationsabläufe]]''' nach der Beschreibung von Anfragen und Antworten unten.<br />
<br />
====Anfrage====<br />
<br />
Die Anfrage in Form eines URL übergibt dem DDNS-Programm in einem 'Query-String' einige Metavariablen. Das heißt, in einem URL der Form<br />
<br />
<nowiki>https://benutzername:passwort@ddns.beisiel.de/cgi-bin/ddns?hostname=einwahl.example.com&myip=87.65.43.21</nowiki><br />
<br />
signalisert das Fragezeichen, daß ein Query-String folgt. In einem solchen Query-String können in der Beispielimplementierung folgende Metavariablen definiert werden:<br />
<br />
{| class="wikitable"<br />
|- class="hintergrundfarbe5"<br />
! Variable !! Beispiel !! Bemerkungen<br />
|-<br />
| hostname || <tt>hostname=einwahl.example.com</tt><br /><div style="font-size:smaller;"><tt>hostname=eins.example.com,zwei.example.com[,...]</tt></div> ||<br />
Muß ein vollständig qualifizierter Domain-Name ("FQDN") sein; <tt>example.com</tt> muß eine vom Besitzer des DDNS-Programms verwaltete Domain sein. Genaugenommen kann der Wert eine durch Kommata gegliederte Liste mehrerer gültiger Domainnamen sein, falls mehrere Einträge mit derselben IP-Adresse gewünscht werden.<br />
|-<br />
| myip || <tt>myip=87.65.43.21</tt>||<br />
Kann entfallen; kann vom Server ignoriert werden. Maßgeblich ist dann die IP-Adresse des Absenders, wie sie vom Web-Server mitgeteilt wird.<br />
|-<br />
| mx || <tt>mx=87.65.43.21</tt><br /><tt>mx=NOCHG</tt><br /> ||<br />
Neben dem A-Eintrag möchte der Client auch einen MX-Eintrag. Der Wert <tt>NOCHG</tt> (für &bdquo;no change&ldquo;) bedeutet, der bestehende MX-Eintrag (oder seine Abwesenheit) soll nicht geändert werden. <br />
|-<br />
| backmx || <tt>backmx=YES</tt><br /><tt>backmx=NOCHG</tt><br /><tt>backmx=NO</tt> ||<br />
Falls <tt>YES</tt>, wird ein zweiter MX-Eintrag erzeugt, der <tt>einwahl.example.com</tt> als Mail-Server für <tt>einwahl.example.com</tt> nennt. Dieser Eintrag hat eine niedrigere Präferenzzahl (also eine höhere Priorität) als der mit <tt>mx</tt> angeforderten Eintrag.<br />
|-<br />
| wildcard || <tt>wildcard=ON</tt><br /><tt>wildcard=NOCHG</tt><br /><tt>wildcard=OFF</tt> ||<br />
Neben dem A-Eintrag für den Domainnamen <tt>einwahl.example.com</tt> wünscht der Client auch einen Eintrag für beliebige Subdomains, also <tt>*.einwahl.example.com</tt>, mit der gleichen IP-Adresse.<br />
|-<br />
| offline ||<tt>offline=YES</tt><br /><tt>offline=NOCHG</tt>||<br />
Falls <tt>YES</tt>, wird ein DNS-Eintrag für <tt>einwahl.example.com</tt> aus der Zonefile getilgt. Gegebenenfalls wird der Hostname dann auf Grund eines parallelen Wildcard-Eintrags für <tt>*.example.com</tt> einer anderen IP-Adresse zugeordnet werden.<br />
|}<br />
<br />
<!-- IPv6? --><br />
<br />
Alle Parameter bis auf hostname können entfallen. Bei nichtdokumentierten Argumenten ist das Verhalten undefiniert&trade;.<br />
<br />
====Antwort====<br />
<br />
Die Antwort auf eine erfolgreiche HTTP-Anfrage besteht im häufigsten Fall aus einigen Header-Zeilen, gefolgt vom Inhalt der gewünschten Text- oder andere Datei. Ein Status-Code in der ersten Header-Zeile gibt an, ob die Anfrage bedient werden kann oder kreist andernfalls den Grund für die Enttäuschung ein.<br />
<br />
Die vorliegende Beispielimplementierung von DDNS schickt einen der üblichen HTTP-Status-Codes "200 OK" oder "500 Internal Server Error", gefolgt von einer kurzen Textnachricht nach dem HTTP-Header. Bei diesem Programm ist &ndash; laut Gebrauchshinweise von DynDNS.org &ndash; ''nicht'' der Status-Code im Header, sondern der Inhalt der Nachricht die definierte, maßgebliche Ergebnismeldung des Programms.<br />
<br />
{| class="wikitable"<br />
|- class="hintergrundfarbe5"<br />
! Meldung !! Bedeutung !! Bemerkungen<br />
|-<br />
| <tt>good&nbsp;&lt;IP&nbsp;number&gt;</tt> ||<br />
Der gewünschte DNS-Eintrag wurde erfolgreich in einer Zonefile eingetragen. <br />
|| Es kann natürlich noch einige Minuten dauern, bis die Zonefile vom Hostsharing-Roboter abgelesen wird und der Inhalt in die BIND-Konfiguration übernommen.<br />
|-<br />
| <tt>good&nbsp;0.0.0.0</tt> ||<br />
Das Argument <tt>offline=YES</tt> wurde empfangen und verarbeitet.<br />
|| Der Domainnamen hat also keinen dynamischen DNS-Eintrag mehr.<br />
|-<br />
| <tt>good&nbsp;127.0.0.1</tt> ||<br />
Die Anfrage entsprach nicht den Erfordernissen des Servers.<br />
|| Trotz des Worts <tt>good</tt> war die Anfrage nicht erfolgreich, falls in der Rückmeldung die IP-Adresse mit <tt>127.0.0.1</tt> angegeben wird. Dieser verwirrende Fehlercode ist aus unerklärlichen Gründen in der Spezifikation von DynDNS.org so definiert.<br />
|-<br />
| <tt>nochg&nbsp;&lt;IP&nbsp;number&gt;</tt> ||<br />
Der gewünschte DNS-Eintrag war bereits vorhanden. <br />
|| Der Server selbst macht keine DNS-Abfrage, um das zu vermitteln: die &bdquo;no change&ldquo;-Antwort besagt nur, daß eine Anfrage für diesen Eintrag bereits mit Erfolg quittiert wurde.<br />
|-<br />
| <tt>notfqdn</tt> ||<br />
Fehlschlag: der gewünschte Domainname ist nicht gültig, oder es wurde keiner angegeben.<br />
|| ...<br />
|-<br />
| <tt>nohost</tt> ||<br />
Fehlschlag: der gewünschte Domainname ist gehört nicht zu denen, die für diesen Benutzer des DDNS-Dienstes konfiguriert sind.<br />
|| Siehe den Abschnitt [[#Administration|Administration]] weiter unten.<br />
|-<br />
| <tt>badauth</tt> ||<br />
Fehlschlag: Die Kombination von Benutzernamen und Paßwort entsprach keinem DDNS-Account, oder das Account ist momentan gesperrt.<br />
|| Ein gesperrtes Account kann nur der Domain-Admin mittels des Administrationswerkzeugs wieder freigeben: siehe den Abschnit [[#Administration|Administration]] weiter unten.<br />
|-<br />
| <tt>abuse</tt> ||<br />
Fehlschlag: der gewünschte Domainname ist wegen vorangeganger Fehlschläge oder überflüssiger Aufrufe gesperrt.<br />
|| Siehe den Abschnitt [[Sukzessive_Kommunikationsabläufe|Sukzessive Kommunikationsabläufe]] unten.<br />
|-<br />
| <tt>911</tt> ||<br />
Fehlschlag: Das Server-Programm hat einen internen Fehler festgestellt.<br />
|| Das Problem liegt nicht in der Anfrage an sich.<br />
|}<br />
<br />
Man kann sich durchaus eine sinnreichere Kommunikation zwischen Client und Server vorstellen, doch das hier beschriebene Protokoll ist eben von DynDNS.org verwendet worden und wird in gängigen Routern implementiert, also wird es in der vorliegenden DDNS-Implementierung nachgebildet.<br />
<br />
=== Sukzessive Kommunikationsabläufe ===<br />
Der Server muß sich zwischen einzelnen Aufrufen einiges merken, um Ressourcen zu schonen und um zu verhindern, daß einmal vergebene DDNS-Einträge von neuen Anfragen, die dieselbe übergeordnete Domain betreffen, durch Überschreiben verlorengehen.<br />
<br />
==== Mißbrauch und Benutzersperrung ====<br />
Zur Schonung von Ressourcen muß sich die Implementierung weigern, sich mit zuvielen fehlerhaften oder auch nur überflüssigen Anfragen zu beschäftigen. Dazu führt eine Strichliste über solche Anfragen jedes Clients und sperrt nach einer bestimmten Anzahl solcher Anfragen den Benutzernamen oder einzelne Domainnamen gegen die weitere Nutzung des Dienstes.<br />
<br />
Mißbrauchspunkte gegen einen einzelnen Domainnamen gibt es für:<br />
* eine Anfrage, die keinen neuen DNS-Eintrag (und keine Änderung oder Löschung eines Eintrags) erfordert, sondern bestehende Merkmale nur wiederholt<br />
<br />
Mißbrauchspunkte gegen einen Benutzernamen gibt es für:<br />
* die Angabe eines Domainnamens, der in der Dienstkonfiguration dem anfragenden Benutzernamen nicht zugeordnet ist<br />
* die Angabe eines Domainnamen in einer Domain, die nicht demselben Hostsharing-Domain-Admin gehört, der den DDNS-Dienst anbietet<br />
* die Angabe eines Domainnamens, der in der Dienstkonfiguration bereits wegen mißbräuchlicher Anfragen gesperrt ist (siehe oben)<br />
<br />
Um eine Sperrung aufzuheben, wird in der Regel eine Handlung durch den Administrator erforderlich sein.<br />
<br />
==== Mehrere dynamische Subdomains in derselben Domain ====<br />
Sobald zwei verschiedene DDNS-Einträge in derselben Domain verlangt werden &ndash; beispielsweise home.example.com und office.example.com &ndash; wird es notwendig, bei jeder neuen Zonefile für example.com eventuell frühere Einträge zu konservieren. Der Rechner zu Hause weiß beim Bestellen seines DDNS-Eintrags nichts vom Rechner im Büro und umgekehrt. Der Server muß in irgendeiner Form über bereits vergebene Einträge Buch führen und bei einer neuen Anfrage, die example.com betrifft, alle bereits aktiven DDNS-Einträge für example.com mit in die neue Zonefile aufnehmen &ndash auch wenn sie auf Anfragen verschiedener Benutzer zurückgehen.<br />
<br />
==== Datenbank ====<br />
In der Beispielimplementierung werden diese Informationen in einer SQLite-Datenbank gespeichert.<br />
<br />
== Sicherheit ==<br />
=== Rechte ===<br />
Die '''Benutzerrechte''' werden durch das Hostsharing-System kontrolliert. Sowohl das CGI-Programm als auch das [[#Administration|Administrationswerkzeug]] werden mit den Rechten des Domain-Admins (xyz00-benutzername in unserem Beispiel) ausgeführt, also kann dieses Programm nur die Domains bearbeiten, die von xyz00-benutzername verwaltet werden.<br />
<br />
=== Authentifizierung ===<br />
In der Beispielimplementierung (wie auch seinerzeit bei DynDNS.org) wird das CGI-Programm durch einen .htaccess-Eintrag geschützt, der HTTP-Basic-Authentication vorschreibt. Also wird das Programm eigentlich mit einem URL der form<br />
<br />
<nowiki>https://ddnsaccount:passwort@ddns.example.com/cgi-bin/ddns?hostname=...</nowiki><br />
<br />
aufgerufen.<br />
<br />
=== Verschlüsselung ===<br />
Das CGI-Programm sollte nur in example.com/cgi-ssl/ installiert werden, nicht in example.com/cgi/. Damit ist die Kommunikation zwischen Client und Server durch SSL verschlüsselt.<br />
<br />
== Administration ==<br />
<br />
Der Verwalter des DDNS-Programms trägt berechtigte Benutzer und die ihnen zugeteilten Domainnamen in die Datenbank des Programms ein mit Hilfe eines kleinen Hilfsprogramms. Das ist im vorliegenden Fall ein menügesteuertes Programm für die Befehlszeile, daß die naheliegenden Funktionen anbietet: Account hinzufügen, löschen, sperren, entsperren, Paßwort setzen, ändern; Domainnamen hinzufügen, ändern, entsperren, löschen; Accounts und Domainnamen mit aktuellem Status auflisten. Die Funktionen sind auch über Befehlszeilenargumente verfügbar, also skriptfähig.<br />
<br />
Eine Auflistung des momentanen Inhalts der DDNS-Datenbank durch das Administrationswerkzeug könnte beispielsweise so aussehen:<br />
<br />
xyz00-benutzername@h02:~$ bin/ddnsadmin.pl -Aa<br />
1. papst Mißbrauch: 0; gesperrt: nein<br />
avignon.example.com<br />
zuletzt aktiv am Sun Apr 26 22:24:49 2020<br />
mit IP-Nr. 87.65.43.21; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 0; gesperrt: nein<br />
vatican.beispiel.de<br />
zuletzt aktiv am Sun Apr 26 22:24:49 2020<br />
mit IP-Nr. 87.65.43.21; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 0; gesperrt: nein<br />
2. kaiser Mißbrauch: 4; gesperrt: ja<br />
augsburg.beispiel.de<br />
zuletzt aktiv am Fri Apr 24 16:13:49 2020<br />
mit IP-Nr. 64.82.31.75; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 0; gesperrt: ja<br />
3. luther Mißbrauch: 1; gesperrt: nein<br />
wittenberg.example.com<br />
zuletzt aktiv am Mon Apr 27 10:12:49 2020<br />
mit IP-Nr. 78.56.34.12; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 1; gesperrt: nein<br />
xyz00-benutzername@h02:~$<br />
<br />
Das DDNS-Account &bdquo;kaiser&ldquo; in dieser Auflistung ist wohl auf Grund fehlerhafter Anfragen automatisch gesperrt worden. Der Inhaber wird sich wohl bald melden, um nach Korrektur seiner Client-Konfiguration die Aufhebung der Sperre zu wünschen.<br />
<br />
=== Log ===<br />
Alle Anfragen werden in einer täglich wechselnden Log-Datei protokolliert, entweder schlicht oder ausführlich, je nachdem, ob eine Variable <tt>verbose</tt> wahr ist.<br />
Ein ausführlicher Log-Eintrag sieht so aus:<br />
<br />
Sun Apr 26 20:21:45 2020 ddns aufgerufen von papst<br />
unter 84.185.97.8<br />
URL: <nowiki>https://ddns.example.com/cgi-bin/ddns.cgi?hostname=<br />
avignon.example.com,vatican.beispiel.de&<br />
myip=84.185.97.8</nowiki><br />
Verwende IP 84.185.97.8 (= 1421435144)<br />
DB-Version: 1<br />
Skript und DB exklusiv geöffnet<br />
avignon.example.com: IP: 84.185.97.8; MX: 0; Backup-MX: nein;<br />
Wildcard: nein; Mißbrauch: 0; gesperrt: nein <br />
vatican.beispiel.de: IP: 84.185.97.8; MX: 0; Backup-MX: nein;<br />
Wildcard: nein; Mißbrauch: 0; gesperrt: nein <br />
Betroffene Zonen: example.com, beispiel.de<br />
Temporärdatei example.com_hxNa.new geschrieben<br />
Zonendatei /home/pacs/xyz00/users/benutzername/doms/example.com/<br />
etc/pri.example.com eingestellt<br />
Temporärdatei beispiel.de_6HcO.new geschrieben<br />
Zonendatei /home/pacs/xyz00/users/benutzername/doms/beispiel.de/<br />
etc/pri.beispiel.de eingestellt<br />
Abgeschlossen: Fertig<br />
<br />
Wenn <tt>verbose</tt> auf falsch gesetzt ist, sind die Log-Einträge einzeilig.</div>Apc00-tonyhttps://wiki.hostsharing.net/index.php?title=Benutzer:Apc00-tony/Dynamisches_DNS&diff=5196Benutzer:Apc00-tony/Dynamisches DNS2020-04-29T08:25:00Z<p>Apc00-tony: /* Antwort */</p>
<hr />
<div>((Provisorischer Vorspann: Auf Grund einer Mailing-Listen-Diskussion habe ich angefangen, Dynamisches DNS über einen CGI-Skript bei Hostsharing zu realisieren. Meine Lösung habe ich dann vorgestellt; sie wurde für nicht ausreichend selbsterklärend befunden und fand wenig Akzeptanz. Hier also der Versuch, die Sache zu dokumentieren.))<br />
<br />
Mit der regelmäßigen Aufnahme von benutzerspezifischen Zonefiles in seiner DNS-Konfiguration bietet Hostsharing alles, was man braucht, um &bdquo;dynamisches DNS&ldquo; in Eigenregie zu realisieren.<br />
<br />
Das heißt, wenn ich mindestens eine Domain bei Hostsharing verwalte, und mindestens eine Einwahlverbindung (oder DSL-Verbindung) ins Internet mit wechselnder IP-Adresse über irgendeinen ISP für meinen Arbeitsplatzrechner zu Hause betreibe, dann kann ich dem Arbeitsplatzrechner über die DNS-Server von Hostsharing einen vollqualifizieren Domainnamen zuweisen, der der jeweiligen IP-Adresse meiner Einwahlleitung zugeordnet ist.<br />
<br />
<pre><br />
<br />
(ASCII-Art-Diagramm der beschriebenen Konstellation)<br />
<br />
</pre><br />
<br />
Im Folgenden wird eine real existierende Implementierung von Dynamischem DNS (&bdquo;DDNS&ldquo;) beschrieben. Die verschiedenen Elemente könnten durchaus anders realisiert werden; die beschriebene Implementierung könnte durchaus verbessert werden. Sie dient hier der Illustration.<br />
<br />
In der folgenden Beschreibung werden diese Beispielwerte benutzt:<br />
* Ein Hostsharing-Mitglied hat ein Account als Paket-Admin mit Kennung xyz00.<br />
* Im Paket xyz00 gibt es einen Domain-Admin namens xyz00-benutzername.<br />
* Dieser Domain-Admin verwaltet bei Hostsharing die Domains example.com und beispiel.de.<br />
* Ein Benutzer hat zu Hause (oder im Büro) einen Arbeitsplatzrechner hinter der marktüblichen DSL-Leitung, die von seinem ISP bereitgestellt wird.<br />
* Dieser Arbeitsplatzrechner (oder der Router, der seine Internetverbindung steuert) bekommt vom ISP immer wechselnde IP-Adressen zugewiesen.<br />
* Dennoch möchte der Benutzer seinen Arbeitsplatzrechner aus dem Internet unter dem Hostnamen einwahl.example.com ansprechen können.<br />
<br />
Dazu kann ein System wie Hostsharing, das authoritative DNS-Informationen für viele Domains bereitstellt, auch veränderliche DNS-Information über dynamisch verbundene Rechner verwalten &ndash; sofern das ressourcenschonend gemacht werden kann ohne andere Funktionen zu stören.<br />
<br />
== Aufgaben des Servers ==<br />
<br />
Um einem Rechner mit wechselnder IP-Adresse einen DDNS-Eintrag zu bieten, muß der Hostsharing-Server folgendes leisten (in ungefährer Reihenfolge der Ereignisse):<br />
<br />
# Eine Anfrage entgegennehmen, beispielsweise über HTTPS, von einem entfernten Rechner, der einen DNS-Eintrag für seine momentane IP-Adresse wünscht. <br />
# Prüfen, ob die Anfrage einen berechtigten DDNS-Dienst-Usernamen mit zugehörigem Paßwort enthält.<br />
# Prüfen, ob die Anfrage einen gültigen Domainnamen betrifft, den der Server bieten darf.<br />
# Prüfen, ob die Domain example.com demselben Benutzer gehört, unter dessen Namen der Dynamisches-DNS-Server läuft.<br />
# Eine gültige [[Zonefile]] mit &ndash; neben dem bisherigen Inhalt &ndash; einem A-Eintrag für einwahl.example.com in /home/pacs/xyz00/users/benutzername/doms/example.com/pri.example.com schreiben.<br />
# Dem Client eine Bestätigung oder ggf. eine Fehlermeldung als Antwort senden.<br />
# In irgendeiner Datenbank den momentan eingestellter Status all seiner DDNS-Einträge speichern.<br />
# In einer Logdatei protokollieren, daß obiges getan wurde, oder ggf. welche Fehler traten auf.<br />
<br />
== Aufgaben des Clients ==<br />
Bevor ich anfange, meinen Arbeitsplatzrechner so zu konfigurieren, daß er bei welchem Server auch immer einen DDNS-Eintrag anfordert, muß ich mich als verantwortlicher Benutzer dieses Rechners und der dazugehörigen Internetverbindung &ndash; das heißt, als Mensch &ndash; mit dem Betreiber des dynamisches-DNS-Servers vereinbaren, daß ich das darf und welchen Eintrag ich bekommen kann. Im Folgenden wird vorausgesetzt, daß solche Vereinbarungen getroffen und die Parameter geklärt wurden.<br />
<br />
Der DDNS-Client muß aus Server-Sicht nur wenig leisten:<br />
<br />
# Eine Anfrage senden, beispielsweise über HTTPS, an einen entfernten Rechner, der einen Eintrag ins DNS für die momentane IP-Adresse des Clients vornehmen kann.<br />Diese Anfrage muß einem festgelegten Format entsprechen und muß gültige Werte für die Authorisation des Clients, den gewünschten Domainnamen, und eventuell andere Parameter enthalten.<br />
# Eine Antwort des Servers entgegennehmen und als Erfolgs- oder Fehlermeldung auswerten.<br />
# Von überflüssigen Anfragen absehen: das heißt bei Erfolg, nicht wiederholt den gleichen Eintrag erneut wünschen; bei Fehlern, nicht die gleiche fehlerhafte Anfrage erneut schicken.<br />
<br />
== Kommunikation zwischen Client und Server ==<br />
<br />
Ein einziges Nachrichtenpaar von Anfrage und Antwort genügt, um einen DDNS-Eintrag einzurichten: Der Client teilt die IP-Adresse und den Domainnamen mit, die in einem DNS-Eintrag verbunden werden sollen; der Server bestätigt den Auftrag.<br />
<br />
In der Beispielimplementierung erfolgt die Kommunikation über HTTP, und die Anfrage des Clients könnte so aussehen:<br />
<br />
GET /cgi-bin/ddns?hostname=einwahl.example.com&myip=87.65.43.21 HTTP/1.1<br />
Host: ddns.beispiel.de<br />
User-Agent: Fritz!Box DDNS/1.0.1<br />
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==<br />
<br />
Bei Erhalt dieser Anfrage ruft Apache das CGI-Programm .../doms/ddns.beispiel.de/cgi-ssl/ddns auf. Das Fragezeichen trennt den Programmnamen von einem "Query-String", in dem zwei Metavariablen definiert und übergeben werden. Die erste Metavariable, hostname, hat den Wert "einwahl.example.com"; die zweite, myip, hat den Wert "87.65.43.21".<br />
<br />
Das Server-Programm, hier ''ddns'', prüft diese Informationen auf Form und Berechtigung, und schreibt gegebenenfalls einen entsprechenden Eintrag in einer Zonefile. Es schreibt auch verschiedene Informationen in die Standardausgabe. Wenn es die Standardausgabe geschlossen wird &ndash; also spätestens bei Programmende &ndash; schickt Apache diese Informationen als Antwort an den anfragenden Rechner zurück.<br />
<br />
Im Falle unserer Beispielimplementierung sieht die Antwort bei Erfolg so aus: <br />
<br />
HTTP/1.1 200 OK<br />
Date: Wed, 22 Apr 2020 08:35:15 GMT<br />
Server: Apache<br />
Content-Length: 17<br />
Content-Type: text/plain; charset=ISO-8859-1<br />
<br />
good 87.65.43.21<br />
<br />
=== Das DDNS-Protokoll von DynDNS.org ===<br />
<br />
In den 90er Jahren, bevor das Internet so durchgehend vergeschäftlicht wurde, boten einige Organisationen kostenlose DDNS-Dienste an. Ein sehr beliebtes Angebot war das von DynDNS.org. Das DDNS-Protokoll von diesem Dienst wurde sogar in Einwahl-Routern einprogrammiert und der Dienst wurde von ISPs und Router-Herstellern als Leistungsmerkmal beworben.<br />
<br />
DynDNS.org gehört inzwischen Oracle und bietet keine kostenlose Dienste mehr. Dennoch wird das DDNS-Protokoll von DynDNS.org in der vorliegenden Beispielimplementierung übernommen in der Hoffnung, daß die Kompatibilität mit einigen gängigen Einwahl-Routern von Vorteil sein kann. Es gibt noch eine kurze Online-Dokumentation der [https://help.dyn.com/remote-access-api/perform-update/ Anfrage] und [https://help.dyn.com/remote-access-api/perform-update/ Antwortnachrichten].<br />
<br />
Das gesammte Protokoll sieht einen einzigen Nachrichtenaustausch aus Anfrage und Antwort vor. Die Anfrage kann mehrere Argumente enthalten; die Antwort kann verschiedene Code-Wörtern enthalten. Übrigens können in einer einzigen Anfrage mehrere DNS-Einträge gewünscht werden. In diesem Fall kann die Antwort mehrzeilig ausfallen.<br />
<br />
Das Verhalten von Server und Client bei künftigen Kommunikationsvorgängen wird unter Umständen von vorangegangenen Kommunikationsergebnissen beeinflußt: nach wiederholten fehlerhaften oder redundanten Anfragen kann der Server weitere Anfragen des Benutzers verweigern; nach wiederholten Fehlermeldungen sollte ein Client aufhören, immer dieselbe Anfrage zu schicken. Und für den Fall, daß mehrere Clients dynamische DNS-Einträge in derselben Domain example.com bestellen, muß der Server den Stand aller Client-Einträge intern speichern, damit er nicht mit einer neuen Zonefile einen früher erstellten Eintrag löscht. Zu diesen Fragen siehe den Abschnitt '''[[#Sukzessive_Kommunikationsabläufe]]''' nach der Beschreibung von Anfragen und Antworten unten.<br />
<br />
====Anfrage====<br />
<br />
Die Anfrage in Form eines URL übergibt dem DDNS-Programm in einem 'Query-String' einige Metavariablen. Das heißt, in einem URL der Form<br />
<br />
<nowiki>https://benutzername:passwort@ddns.beisiel.de/cgi-bin/ddns?hostname=einwahl.example.com&myip=87.65.43.21</nowiki><br />
<br />
signalisert das Fragezeichen, daß ein Query-String folgt. In einem solchen Query-String können in der Beispielimplementierung folgende Metavariablen definiert werden:<br />
<br />
{| class="wikitable"<br />
|- class="hintergrundfarbe5"<br />
! Variable !! Beispiel !! Bemerkungen<br />
|-<br />
| hostname || <tt>hostname=einwahl.example.com</tt><br /><div style="font-size:smaller;"><tt>hostname=eins.example.com,zwei.example.com[,...]</tt></div> ||<br />
Muß ein vollständig qualifizierter Domain-Name ("FQDN") sein; <tt>example.com</tt> muß eine vom Besitzer des DDNS-Programms verwaltete Domain sein. Genaugenommen kann der Wert eine durch Kommata gegliederte Liste mehrerer gültiger Domainnamen sein, falls mehrere Einträge mit derselben IP-Adresse gewünscht werden.<br />
|-<br />
| myip || <tt>myip=87.65.43.21</tt>||<br />
Kann entfallen; kann vom Server ignoriert werden. Maßgeblich ist dann die IP-Adresse des Absenders, wie sie vom Web-Server mitgeteilt wird.<br />
|-<br />
| mx || <tt>mx=87.65.43.21</tt><br /><tt>mx=NOCHG</tt><br /> ||<br />
Neben dem A-Eintrag möchte der Client auch einen MX-Eintrag. Der Wert <tt>NOCHG</tt> (für &bdquo;no change&ldquo;) bedeutet, der bestehende MX-Eintrag (oder seine Abwesenheit) soll nicht geändert werden. <br />
|-<br />
| backmx || <tt>backmx=YES</tt><br /><tt>backmx=NOCHG</tt><br /><tt>backmx=NO</tt> ||<br />
Falls <tt>YES</tt>, wird ein zweiter MX-Eintrag erzeugt, der <tt>einwahl.example.com</tt> als Mail-Server für <tt>einwahl.example.com</tt> nennt. Dieser Eintrag hat eine niedrigere Präferenzzahl (also eine höhere Priorität) als der mit <tt>mx</tt> angeforderten Eintrag.<br />
|-<br />
| wildcard || <tt>wildcard=ON</tt><br /><tt>wildcard=NOCHG</tt><br /><tt>wildcard=OFF</tt> ||<br />
Neben dem A-Eintrag für den Domainnamen <tt>einwahl.example.com</tt> wünscht der Client auch einen Eintrag für beliebige Subdomains, also <tt>*.einwahl.example.com</tt>, mit der gleichen IP-Adresse.<br />
|-<br />
| offline ||<tt>offline=YES</tt><br /><tt>offline=NOCHG</tt>||<br />
Falls <tt>YES</tt>, wird ein DNS-Eintrag für <tt>einwahl.example.com</tt> aus der Zonefile getilgt. Gegebenenfalls wird der Hostname dann auf Grund eines parallelen Wildcard-Eintrags für <tt>*.example.com</tt> einer anderen IP-Adresse zugeordnet werden.<br />
|}<br />
<br />
<!-- IPv6? --><br />
<br />
Alle Parameter bis auf hostname können entfallen. Bei nichtdokumentierten Argumenten ist das Verhalten undefiniert&trade;.<br />
<br />
====Antwort====<br />
<br />
Die Antwort auf eine erfolgreiche HTTP-Anfrage besteht im häufigsten Fall aus einigen Header-Zeilen, gefolgt vom Inhalt der gewünschten Text- oder andere Datei. Ein Status-Code in der ersten Header-Zeile gibt an, ob die Anfrage bedient werden kann oder kreist andernfalls den Grund für die Enttäuschung ein.<br />
<br />
Die vorliegende Beispielimplementierung von DDNS schickt einen der üblichen HTTP-Status-Codes "200 OK" oder "500 Internal Server Error", gefolgt von einer kurzen Textnachricht nach dem HTTP-Header. Bei diesem Programm ist &ndash; laut Gebrauchshinweise von DynDNS.org &ndash; ''nicht'' der Status-Code im Header, sondern der Inhalt der Nachricht die definierte, maßgebliche Ergebnismeldung des Programms.<br />
<br />
{| class="wikitable"<br />
|- class="hintergrundfarbe5"<br />
! Meldung !! Bedeutung !! Bemerkungen<br />
|-<br />
| <tt>good&nbsp;&lt;IP&nbsp;number&gt;</tt> ||<br />
Der gewünschte DNS-Eintrag wurde erfolgreich in einer Zonefile eingetragen. <br />
|| Es kann natürlich noch einige Minuten dauern, bis die Zonefile vom Hostsharing-Roboter abgelesen wird und der Inhalt in die BIND-Konfiguration übernommen.<br />
|-<br />
| <tt>good&nbsp;0.0.0.0</tt> ||<br />
Das Argument <tt>offline=YES</tt> wurde empfangen und verarbeitet.<br />
|| Der Domainnamen hat also keinen dynamischen DNS-Eintrag mehr.<br />
|-<br />
| <tt>good&nbsp;127.0.0.1</tt> ||<br />
Die Anfrage entsprach nicht den Erfordernissen des Servers.<br />
|| Trotz des Worts <tt>good</tt> war die Anfrage nicht erfolgreich, falls in der Rückmeldung die IP-Adresse mit <tt>127.0.0.1</tt> angegeben wird. Dieser verwirrende Fehlercode ist aus unerklärlichen Gründen in der Spezifikation von DynDNS.org so definiert.<br />
|-<br />
| <tt>nochg&nbsp;&lt;IP&nbsp;number&gt;</tt> ||<br />
Der gewünschte DNS-Eintrag war bereits vorhanden. <br />
|| Der Server selbst macht keine DNS-Abfrage, um das zu vermitteln: die &bdquo;no change&ldquo;-Antwort besagt nur, daß eine Anfrage für diesen Eintrag bereits mit Erfolg quittiert wurde.<br />
|-<br />
| <tt>notfqdn</tt> ||<br />
Fehlschlag: der gewünschte Domainname ist nicht gültig, oder es wurde keiner angegeben.<br />
|| ...<br />
|-<br />
| <tt>nohost</tt> ||<br />
Fehlschlag: der gewünschte Domainname ist gehört nicht zu denen, die für diesen Benutzer des DDNS-Dienstes konfiguriert sind.<br />
|| Siehe den Abschnitt [[#Administration|Administration]] weiter unten.<br />
|-<br />
| <tt>badauth</tt> ||<br />
Fehlschlag: Die Kombination von Benutzernamen und Paßwort entsprach keinem DDNS-Account, oder das Account ist momentan gesperrt.<br />
|| Ein gesperrtes Account kann nur der Domain-Admin mittels des Administrationswerkzeugs wieder freigeben: siehe den Abschnit [[#Administration|Administration]] weiter unten.<br />
|-<br />
| <tt>abuse</tt> ||<br />
Fehlschlag: der gewünschte Domainname ist wegen vorangeganger Fehlschläge oder überflüssiger Aufrufe gesperrt.<br />
|| Siehe den Abschnitt '''Sukzessive Kommunikationsvorgänge''' unten.<br />
|-<br />
| <tt>911</tt> ||<br />
Fehlschlag: Das Server-Programm hat einen internen Fehler festgestellt.<br />
|| Das Problem liegt nicht in der Anfrage an sich.<br />
|}<br />
<br />
Man kann sich durchaus eine sinnreichere Kommunikation zwischen Client und Server vorstellen, doch das hier beschriebene Protokoll ist eben von DynDNS.org verwendet worden und wird in gängigen Routern implementiert, also wird es in der vorliegenden DDNS-Implementierung nachgebildet.<br />
<br />
=== Sukzessive Kommunikationsabläufe ===<br />
Der Server muß sich zwischen einzelnen Aufrufen einiges merken, um Ressourcen zu schonen und um zu verhindern, daß einmal vergebene DDNS-Einträge von neuen Anfragen, die dieselbe übergeordnete Domain betreffen, durch Überschreiben verlorengehen.<br />
<br />
==== Mißbrauch und Benutzersperrung ====<br />
Zur Schonung von Ressourcen muß sich die Implementierung weigern, sich mit zuvielen fehlerhaften oder auch nur überflüssigen Anfragen zu beschäftigen. Dazu führt eine Strichliste über solche Anfragen jedes Clients und sperrt nach einer bestimmten Anzahl solcher Anfragen den Benutzernamen oder einzelne Domainnamen gegen die weitere Nutzung des Dienstes.<br />
<br />
Mißbrauchspunkte gegen einen einzelnen Domainnamen gibt es für:<br />
* eine Anfrage, die keinen neuen DNS-Eintrag (und keine Änderung oder Löschung eines Eintrags) erfordert, sondern bestehende Merkmale nur wiederholt<br />
<br />
Mißbrauchspunkte gegen einen Benutzernamen gibt es für:<br />
* die Angabe eines Domainnamens, der in der Dienstkonfiguration dem anfragenden Benutzernamen nicht zugeordnet ist<br />
* die Angabe eines Domainnamen in einer Domain, die nicht demselben Hostsharing-Domain-Admin gehört, der den DDNS-Dienst anbietet<br />
* die Angabe eines Domainnamens, der in der Dienstkonfiguration bereits wegen mißbräuchlicher Anfragen gesperrt ist (siehe oben)<br />
<br />
Um eine Sperrung aufzuheben, wird in der Regel eine Handlung durch den Administrator erforderlich sein.<br />
<br />
==== Mehrere dynamische Subdomains in derselben Domain ====<br />
Sobald zwei verschiedene DDNS-Einträge in derselben Domain verlangt werden &ndash; beispielsweise home.example.com und office.example.com &ndash; wird es notwendig, bei jeder neuen Zonefile für example.com eventuell frühere Einträge zu konservieren. Der Rechner zu Hause weiß beim Bestellen seines DDNS-Eintrags nichts vom Rechner im Büro und umgekehrt. Der Server muß in irgendeiner Form über bereits vergebene Einträge Buch führen und bei einer neuen Anfrage, die example.com betrifft, alle bereits aktiven DDNS-Einträge für example.com mit in die neue Zonefile aufnehmen &ndash auch wenn sie auf Anfragen verschiedener Benutzer zurückgehen.<br />
<br />
==== Datenbank ====<br />
In der Beispielimplementierung werden diese Informationen in einer SQLite-Datenbank gespeichert.<br />
<br />
== Sicherheit ==<br />
=== Rechte ===<br />
Die '''Benutzerrechte''' werden durch das Hostsharing-System kontrolliert. Sowohl das CGI-Programm als auch das [[#Administration|Administrationswerkzeug]] werden mit den Rechten des Domain-Admins (xyz00-benutzername in unserem Beispiel) ausgeführt, also kann dieses Programm nur die Domains bearbeiten, die von xyz00-benutzername verwaltet werden.<br />
<br />
=== Authentifizierung ===<br />
In der Beispielimplementierung (wie auch seinerzeit bei DynDNS.org) wird das CGI-Programm durch einen .htaccess-Eintrag geschützt, der HTTP-Basic-Authentication vorschreibt. Also wird das Programm eigentlich mit einem URL der form<br />
<br />
<nowiki>https://ddnsaccount:passwort@ddns.example.com/cgi-bin/ddns?hostname=...</nowiki><br />
<br />
aufgerufen.<br />
<br />
=== Verschlüsselung ===<br />
Das CGI-Programm sollte nur in example.com/cgi-ssl/ installiert werden, nicht in example.com/cgi/. Damit ist die Kommunikation zwischen Client und Server durch SSL verschlüsselt.<br />
<br />
== Administration ==<br />
<br />
Der Verwalter des DDNS-Programms trägt berechtigte Benutzer und die ihnen zugeteilten Domainnamen in die Datenbank des Programms ein mit Hilfe eines kleinen Hilfsprogramms. Das ist im vorliegenden Fall ein menügesteuertes Programm für die Befehlszeile, daß die naheliegenden Funktionen anbietet: Account hinzufügen, löschen, sperren, entsperren, Paßwort setzen, ändern; Domainnamen hinzufügen, ändern, entsperren, löschen; Accounts und Domainnamen mit aktuellem Status auflisten. Die Funktionen sind auch über Befehlszeilenargumente verfügbar, also skriptfähig.<br />
<br />
Eine Auflistung des momentanen Inhalts der DDNS-Datenbank durch das Administrationswerkzeug könnte beispielsweise so aussehen:<br />
<br />
xyz00-benutzername@h02:~$ bin/ddnsadmin.pl -Aa<br />
1. papst Mißbrauch: 0; gesperrt: nein<br />
avignon.example.com<br />
zuletzt aktiv am Sun Apr 26 22:24:49 2020<br />
mit IP-Nr. 87.65.43.21; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 0; gesperrt: nein<br />
vatican.beispiel.de<br />
zuletzt aktiv am Sun Apr 26 22:24:49 2020<br />
mit IP-Nr. 87.65.43.21; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 0; gesperrt: nein<br />
2. kaiser Mißbrauch: 4; gesperrt: ja<br />
augsburg.beispiel.de<br />
zuletzt aktiv am Fri Apr 24 16:13:49 2020<br />
mit IP-Nr. 64.82.31.75; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 0; gesperrt: ja<br />
3. luther Mißbrauch: 1; gesperrt: nein<br />
wittenberg.example.com<br />
zuletzt aktiv am Mon Apr 27 10:12:49 2020<br />
mit IP-Nr. 78.56.34.12; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 1; gesperrt: nein<br />
xyz00-benutzername@h02:~$<br />
<br />
Das DDNS-Account &bdquo;kaiser&ldquo; in dieser Auflistung ist wohl auf Grund fehlerhafter Anfragen automatisch gesperrt worden. Der Inhaber wird sich wohl bald melden, um nach Korrektur seiner Client-Konfiguration die Aufhebung der Sperre zu wünschen.<br />
<br />
=== Log ===<br />
Alle Anfragen werden in einer täglich wechselnden Log-Datei protokolliert, entweder schlicht oder ausführlich, je nachdem, ob eine Variable <tt>verbose</tt> wahr ist.<br />
Ein ausführlicher Log-Eintrag sieht so aus:<br />
<br />
Sun Apr 26 20:21:45 2020 ddns aufgerufen von papst<br />
unter 84.185.97.8<br />
URL: <nowiki>https://ddns.example.com/cgi-bin/ddns.cgi?hostname=<br />
avignon.example.com,vatican.beispiel.de&<br />
myip=84.185.97.8</nowiki><br />
Verwende IP 84.185.97.8 (= 1421435144)<br />
DB-Version: 1<br />
Skript und DB exklusiv geöffnet<br />
avignon.example.com: IP: 84.185.97.8; MX: 0; Backup-MX: nein;<br />
Wildcard: nein; Mißbrauch: 0; gesperrt: nein <br />
vatican.beispiel.de: IP: 84.185.97.8; MX: 0; Backup-MX: nein;<br />
Wildcard: nein; Mißbrauch: 0; gesperrt: nein <br />
Betroffene Zonen: example.com, beispiel.de<br />
Temporärdatei example.com_hxNa.new geschrieben<br />
Zonendatei /home/pacs/xyz00/users/benutzername/doms/example.com/<br />
etc/pri.example.com eingestellt<br />
Temporärdatei beispiel.de_6HcO.new geschrieben<br />
Zonendatei /home/pacs/xyz00/users/benutzername/doms/beispiel.de/<br />
etc/pri.beispiel.de eingestellt<br />
Abgeschlossen: Fertig<br />
<br />
Wenn <tt>verbose</tt> auf falsch gesetzt ist, sind die Log-Einträge einzeilig.</div>Apc00-tonyhttps://wiki.hostsharing.net/index.php?title=Benutzer:Apc00-tony/Dynamisches_DNS&diff=5195Benutzer:Apc00-tony/Dynamisches DNS2020-04-29T08:19:45Z<p>Apc00-tony: /* Antwort */</p>
<hr />
<div>((Provisorischer Vorspann: Auf Grund einer Mailing-Listen-Diskussion habe ich angefangen, Dynamisches DNS über einen CGI-Skript bei Hostsharing zu realisieren. Meine Lösung habe ich dann vorgestellt; sie wurde für nicht ausreichend selbsterklärend befunden und fand wenig Akzeptanz. Hier also der Versuch, die Sache zu dokumentieren.))<br />
<br />
Mit der regelmäßigen Aufnahme von benutzerspezifischen Zonefiles in seiner DNS-Konfiguration bietet Hostsharing alles, was man braucht, um &bdquo;dynamisches DNS&ldquo; in Eigenregie zu realisieren.<br />
<br />
Das heißt, wenn ich mindestens eine Domain bei Hostsharing verwalte, und mindestens eine Einwahlverbindung (oder DSL-Verbindung) ins Internet mit wechselnder IP-Adresse über irgendeinen ISP für meinen Arbeitsplatzrechner zu Hause betreibe, dann kann ich dem Arbeitsplatzrechner über die DNS-Server von Hostsharing einen vollqualifizieren Domainnamen zuweisen, der der jeweiligen IP-Adresse meiner Einwahlleitung zugeordnet ist.<br />
<br />
<pre><br />
<br />
(ASCII-Art-Diagramm der beschriebenen Konstellation)<br />
<br />
</pre><br />
<br />
Im Folgenden wird eine real existierende Implementierung von Dynamischem DNS (&bdquo;DDNS&ldquo;) beschrieben. Die verschiedenen Elemente könnten durchaus anders realisiert werden; die beschriebene Implementierung könnte durchaus verbessert werden. Sie dient hier der Illustration.<br />
<br />
In der folgenden Beschreibung werden diese Beispielwerte benutzt:<br />
* Ein Hostsharing-Mitglied hat ein Account als Paket-Admin mit Kennung xyz00.<br />
* Im Paket xyz00 gibt es einen Domain-Admin namens xyz00-benutzername.<br />
* Dieser Domain-Admin verwaltet bei Hostsharing die Domains example.com und beispiel.de.<br />
* Ein Benutzer hat zu Hause (oder im Büro) einen Arbeitsplatzrechner hinter der marktüblichen DSL-Leitung, die von seinem ISP bereitgestellt wird.<br />
* Dieser Arbeitsplatzrechner (oder der Router, der seine Internetverbindung steuert) bekommt vom ISP immer wechselnde IP-Adressen zugewiesen.<br />
* Dennoch möchte der Benutzer seinen Arbeitsplatzrechner aus dem Internet unter dem Hostnamen einwahl.example.com ansprechen können.<br />
<br />
Dazu kann ein System wie Hostsharing, das authoritative DNS-Informationen für viele Domains bereitstellt, auch veränderliche DNS-Information über dynamisch verbundene Rechner verwalten &ndash; sofern das ressourcenschonend gemacht werden kann ohne andere Funktionen zu stören.<br />
<br />
== Aufgaben des Servers ==<br />
<br />
Um einem Rechner mit wechselnder IP-Adresse einen DDNS-Eintrag zu bieten, muß der Hostsharing-Server folgendes leisten (in ungefährer Reihenfolge der Ereignisse):<br />
<br />
# Eine Anfrage entgegennehmen, beispielsweise über HTTPS, von einem entfernten Rechner, der einen DNS-Eintrag für seine momentane IP-Adresse wünscht. <br />
# Prüfen, ob die Anfrage einen berechtigten DDNS-Dienst-Usernamen mit zugehörigem Paßwort enthält.<br />
# Prüfen, ob die Anfrage einen gültigen Domainnamen betrifft, den der Server bieten darf.<br />
# Prüfen, ob die Domain example.com demselben Benutzer gehört, unter dessen Namen der Dynamisches-DNS-Server läuft.<br />
# Eine gültige [[Zonefile]] mit &ndash; neben dem bisherigen Inhalt &ndash; einem A-Eintrag für einwahl.example.com in /home/pacs/xyz00/users/benutzername/doms/example.com/pri.example.com schreiben.<br />
# Dem Client eine Bestätigung oder ggf. eine Fehlermeldung als Antwort senden.<br />
# In irgendeiner Datenbank den momentan eingestellter Status all seiner DDNS-Einträge speichern.<br />
# In einer Logdatei protokollieren, daß obiges getan wurde, oder ggf. welche Fehler traten auf.<br />
<br />
== Aufgaben des Clients ==<br />
Bevor ich anfange, meinen Arbeitsplatzrechner so zu konfigurieren, daß er bei welchem Server auch immer einen DDNS-Eintrag anfordert, muß ich mich als verantwortlicher Benutzer dieses Rechners und der dazugehörigen Internetverbindung &ndash; das heißt, als Mensch &ndash; mit dem Betreiber des dynamisches-DNS-Servers vereinbaren, daß ich das darf und welchen Eintrag ich bekommen kann. Im Folgenden wird vorausgesetzt, daß solche Vereinbarungen getroffen und die Parameter geklärt wurden.<br />
<br />
Der DDNS-Client muß aus Server-Sicht nur wenig leisten:<br />
<br />
# Eine Anfrage senden, beispielsweise über HTTPS, an einen entfernten Rechner, der einen Eintrag ins DNS für die momentane IP-Adresse des Clients vornehmen kann.<br />Diese Anfrage muß einem festgelegten Format entsprechen und muß gültige Werte für die Authorisation des Clients, den gewünschten Domainnamen, und eventuell andere Parameter enthalten.<br />
# Eine Antwort des Servers entgegennehmen und als Erfolgs- oder Fehlermeldung auswerten.<br />
# Von überflüssigen Anfragen absehen: das heißt bei Erfolg, nicht wiederholt den gleichen Eintrag erneut wünschen; bei Fehlern, nicht die gleiche fehlerhafte Anfrage erneut schicken.<br />
<br />
== Kommunikation zwischen Client und Server ==<br />
<br />
Ein einziges Nachrichtenpaar von Anfrage und Antwort genügt, um einen DDNS-Eintrag einzurichten: Der Client teilt die IP-Adresse und den Domainnamen mit, die in einem DNS-Eintrag verbunden werden sollen; der Server bestätigt den Auftrag.<br />
<br />
In der Beispielimplementierung erfolgt die Kommunikation über HTTP, und die Anfrage des Clients könnte so aussehen:<br />
<br />
GET /cgi-bin/ddns?hostname=einwahl.example.com&myip=87.65.43.21 HTTP/1.1<br />
Host: ddns.beispiel.de<br />
User-Agent: Fritz!Box DDNS/1.0.1<br />
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==<br />
<br />
Bei Erhalt dieser Anfrage ruft Apache das CGI-Programm .../doms/ddns.beispiel.de/cgi-ssl/ddns auf. Das Fragezeichen trennt den Programmnamen von einem "Query-String", in dem zwei Metavariablen definiert und übergeben werden. Die erste Metavariable, hostname, hat den Wert "einwahl.example.com"; die zweite, myip, hat den Wert "87.65.43.21".<br />
<br />
Das Server-Programm, hier ''ddns'', prüft diese Informationen auf Form und Berechtigung, und schreibt gegebenenfalls einen entsprechenden Eintrag in einer Zonefile. Es schreibt auch verschiedene Informationen in die Standardausgabe. Wenn es die Standardausgabe geschlossen wird &ndash; also spätestens bei Programmende &ndash; schickt Apache diese Informationen als Antwort an den anfragenden Rechner zurück.<br />
<br />
Im Falle unserer Beispielimplementierung sieht die Antwort bei Erfolg so aus: <br />
<br />
HTTP/1.1 200 OK<br />
Date: Wed, 22 Apr 2020 08:35:15 GMT<br />
Server: Apache<br />
Content-Length: 17<br />
Content-Type: text/plain; charset=ISO-8859-1<br />
<br />
good 87.65.43.21<br />
<br />
=== Das DDNS-Protokoll von DynDNS.org ===<br />
<br />
In den 90er Jahren, bevor das Internet so durchgehend vergeschäftlicht wurde, boten einige Organisationen kostenlose DDNS-Dienste an. Ein sehr beliebtes Angebot war das von DynDNS.org. Das DDNS-Protokoll von diesem Dienst wurde sogar in Einwahl-Routern einprogrammiert und der Dienst wurde von ISPs und Router-Herstellern als Leistungsmerkmal beworben.<br />
<br />
DynDNS.org gehört inzwischen Oracle und bietet keine kostenlose Dienste mehr. Dennoch wird das DDNS-Protokoll von DynDNS.org in der vorliegenden Beispielimplementierung übernommen in der Hoffnung, daß die Kompatibilität mit einigen gängigen Einwahl-Routern von Vorteil sein kann. Es gibt noch eine kurze Online-Dokumentation der [https://help.dyn.com/remote-access-api/perform-update/ Anfrage] und [https://help.dyn.com/remote-access-api/perform-update/ Antwortnachrichten].<br />
<br />
Das gesammte Protokoll sieht einen einzigen Nachrichtenaustausch aus Anfrage und Antwort vor. Die Anfrage kann mehrere Argumente enthalten; die Antwort kann verschiedene Code-Wörtern enthalten. Übrigens können in einer einzigen Anfrage mehrere DNS-Einträge gewünscht werden. In diesem Fall kann die Antwort mehrzeilig ausfallen.<br />
<br />
Das Verhalten von Server und Client bei künftigen Kommunikationsvorgängen wird unter Umständen von vorangegangenen Kommunikationsergebnissen beeinflußt: nach wiederholten fehlerhaften oder redundanten Anfragen kann der Server weitere Anfragen des Benutzers verweigern; nach wiederholten Fehlermeldungen sollte ein Client aufhören, immer dieselbe Anfrage zu schicken. Und für den Fall, daß mehrere Clients dynamische DNS-Einträge in derselben Domain example.com bestellen, muß der Server den Stand aller Client-Einträge intern speichern, damit er nicht mit einer neuen Zonefile einen früher erstellten Eintrag löscht. Zu diesen Fragen siehe den Abschnitt '''[[#Sukzessive_Kommunikationsabläufe]]''' nach der Beschreibung von Anfragen und Antworten unten.<br />
<br />
====Anfrage====<br />
<br />
Die Anfrage in Form eines URL übergibt dem DDNS-Programm in einem 'Query-String' einige Metavariablen. Das heißt, in einem URL der Form<br />
<br />
<nowiki>https://benutzername:passwort@ddns.beisiel.de/cgi-bin/ddns?hostname=einwahl.example.com&myip=87.65.43.21</nowiki><br />
<br />
signalisert das Fragezeichen, daß ein Query-String folgt. In einem solchen Query-String können in der Beispielimplementierung folgende Metavariablen definiert werden:<br />
<br />
{| class="wikitable"<br />
|- class="hintergrundfarbe5"<br />
! Variable !! Beispiel !! Bemerkungen<br />
|-<br />
| hostname || <tt>hostname=einwahl.example.com</tt><br /><div style="font-size:smaller;"><tt>hostname=eins.example.com,zwei.example.com[,...]</tt></div> ||<br />
Muß ein vollständig qualifizierter Domain-Name ("FQDN") sein; <tt>example.com</tt> muß eine vom Besitzer des DDNS-Programms verwaltete Domain sein. Genaugenommen kann der Wert eine durch Kommata gegliederte Liste mehrerer gültiger Domainnamen sein, falls mehrere Einträge mit derselben IP-Adresse gewünscht werden.<br />
|-<br />
| myip || <tt>myip=87.65.43.21</tt>||<br />
Kann entfallen; kann vom Server ignoriert werden. Maßgeblich ist dann die IP-Adresse des Absenders, wie sie vom Web-Server mitgeteilt wird.<br />
|-<br />
| mx || <tt>mx=87.65.43.21</tt><br /><tt>mx=NOCHG</tt><br /> ||<br />
Neben dem A-Eintrag möchte der Client auch einen MX-Eintrag. Der Wert <tt>NOCHG</tt> (für &bdquo;no change&ldquo;) bedeutet, der bestehende MX-Eintrag (oder seine Abwesenheit) soll nicht geändert werden. <br />
|-<br />
| backmx || <tt>backmx=YES</tt><br /><tt>backmx=NOCHG</tt><br /><tt>backmx=NO</tt> ||<br />
Falls <tt>YES</tt>, wird ein zweiter MX-Eintrag erzeugt, der <tt>einwahl.example.com</tt> als Mail-Server für <tt>einwahl.example.com</tt> nennt. Dieser Eintrag hat eine niedrigere Präferenzzahl (also eine höhere Priorität) als der mit <tt>mx</tt> angeforderten Eintrag.<br />
|-<br />
| wildcard || <tt>wildcard=ON</tt><br /><tt>wildcard=NOCHG</tt><br /><tt>wildcard=OFF</tt> ||<br />
Neben dem A-Eintrag für den Domainnamen <tt>einwahl.example.com</tt> wünscht der Client auch einen Eintrag für beliebige Subdomains, also <tt>*.einwahl.example.com</tt>, mit der gleichen IP-Adresse.<br />
|-<br />
| offline ||<tt>offline=YES</tt><br /><tt>offline=NOCHG</tt>||<br />
Falls <tt>YES</tt>, wird ein DNS-Eintrag für <tt>einwahl.example.com</tt> aus der Zonefile getilgt. Gegebenenfalls wird der Hostname dann auf Grund eines parallelen Wildcard-Eintrags für <tt>*.example.com</tt> einer anderen IP-Adresse zugeordnet werden.<br />
|}<br />
<br />
<!-- IPv6? --><br />
<br />
Alle Parameter bis auf hostname können entfallen. Bei nichtdokumentierten Argumenten ist das Verhalten undefiniert&trade;.<br />
<br />
====Antwort====<br />
<br />
Die Antwort auf eine erfolgreiche HTTP-Anfrage besteht im häufigsten Fall aus einigen Header-Zeilen, gefolgt vom Inhalt der gewünschten Text- oder andere Datei. Ein Status-Code in der ersten Header-Zeile gibt an, ob die Anfrage bedient werden kann oder kreist andernfalls den Grund für die Enttäuschung ein.<br />
<br />
Die vorliegende Beispielimplementierung von DDNS schickt einen der üblichen HTTP-Status-Codes "200 OK" oder "500 Internal Server Error", gefolgt von einer kurzen Textnachricht nach dem HTTP-Header. Bei diesem Programm ist &ndash; laut Gebrauchshinweise von DynDNS.org &ndash; ''nicht'' der Status-Code im Header, sondern der Inhalt der Nachricht die definierte, maßgebliche Ergebnismeldung des Programms.<br />
<br />
{| class="wikitable"<br />
|- class="hintergrundfarbe5"<br />
! Meldung !! Bedeutung !! Bemerkungen<br />
|-<br />
| <tt>good&nbsp;&lt;IP&nbsp;number&gt;</tt> ||<br />
Der gewünschte DNS-Eintrag wurde erfolgreich in einer Zonefile eingetragen. <br />
|| Es kann natürlich noch einige Minuten dauern, bis die Zonefile vom Hostsharing-Roboter abgelesen wird und der Inhalt in die BIND-Konfiguration übernommen.<br />
|-<br />
| <tt>good&nbsp;0.0.0.0</tt> ||<br />
Das Argument <tt>offline=YES</tt> wurde empfangen und verarbeitet.<br />
|| Der Domainnamen hat also keinen dynamischen DNS-Eintrag mehr.<br />
|-<br />
| <tt>good&nbsp;127.0.0.1</tt> ||<br />
Die Anfrage entsprach nicht den Erfordernissen des Servers.<br />
|| Trotz des Worts <tt>good</tt> war die Anfrage nicht erfolgreich, falls in der Rückmeldung die IP-Adresse mit <tt>127.0.0.1</tt> angegeben wird. Dieser verwirrende Fehlercode ist aus unerklärlichen Gründen in der Spezifikation von DynDNS.org so definiert.<br />
|-<br />
| <tt>nochg&nbsp;&lt;IP&nbsp;number&gt;</tt> ||<br />
Der gewünschte DNS-Eintrag war bereits vorhanden. <br />
|| Der Server selbst macht keine DNS-Abfrage, um das zu vermitteln: die &bdquo;no change&ldquo;-Antwort besagt nur, daß eine Anfrage für diesen Eintrag bereits mit Erfolg quittiert wurde.<br />
|-<br />
| <tt>notfqdn</tt> ||<br />
Fehlschlag: der gewünschte Domainname ist nicht gültig, oder es wurde keiner angegeben.<br />
|| ...<br />
|-<br />
| <tt>nohost</tt> ||<br />
Fehlschlag: der gewünschte Domainname ist gehört nicht zu denen, die für diesen Benutzer des DDNS-Dienstes konfiguriert sind.<br />
|| Siehe den Abschnitt '''Administration''' weiter unten.<br />
|-<br />
| <tt>abuse</tt> ||<br />
Fehlschlag: der gewünschte Domainname ist wegen vorangeganger Fehlschläge oder überflüssiger Aufrufe gesperrt.<br />
|| Siehe den Abschnitt '''Sukzessive Kommunikationsvorgänge''' unten.<br />
|-<br />
| <tt>911</tt> ||<br />
Fehlschlag: Das Server-Programm hat einen internen Fehler festgestellt.<br />
|| Das Problem liegt nicht in der Anfrage an sich.<br />
|}<br />
<br />
Man kann sich durchaus eine sinnreichere Kommunikation zwischen Client und Server vorstellen, doch das hier beschriebene Protokoll ist eben von DynDNS.org verwendet worden und wird in gängigen Routern implementiert, also wird es in der vorliegenden DDNS-Implementierung nachgebildet.<br />
<br />
=== Sukzessive Kommunikationsabläufe ===<br />
Der Server muß sich zwischen einzelnen Aufrufen einiges merken, um Ressourcen zu schonen und um zu verhindern, daß einmal vergebene DDNS-Einträge von neuen Anfragen, die dieselbe übergeordnete Domain betreffen, durch Überschreiben verlorengehen.<br />
<br />
==== Mißbrauch und Benutzersperrung ====<br />
Zur Schonung von Ressourcen muß sich die Implementierung weigern, sich mit zuvielen fehlerhaften oder auch nur überflüssigen Anfragen zu beschäftigen. Dazu führt eine Strichliste über solche Anfragen jedes Clients und sperrt nach einer bestimmten Anzahl solcher Anfragen den Benutzernamen oder einzelne Domainnamen gegen die weitere Nutzung des Dienstes.<br />
<br />
Mißbrauchspunkte gegen einen einzelnen Domainnamen gibt es für:<br />
* eine Anfrage, die keinen neuen DNS-Eintrag (und keine Änderung oder Löschung eines Eintrags) erfordert, sondern bestehende Merkmale nur wiederholt<br />
<br />
Mißbrauchspunkte gegen einen Benutzernamen gibt es für:<br />
* die Angabe eines Domainnamens, der in der Dienstkonfiguration dem anfragenden Benutzernamen nicht zugeordnet ist<br />
* die Angabe eines Domainnamen in einer Domain, die nicht demselben Hostsharing-Domain-Admin gehört, der den DDNS-Dienst anbietet<br />
* die Angabe eines Domainnamens, der in der Dienstkonfiguration bereits wegen mißbräuchlicher Anfragen gesperrt ist (siehe oben)<br />
<br />
Um eine Sperrung aufzuheben, wird in der Regel eine Handlung durch den Administrator erforderlich sein.<br />
<br />
==== Mehrere dynamische Subdomains in derselben Domain ====<br />
Sobald zwei verschiedene DDNS-Einträge in derselben Domain verlangt werden &ndash; beispielsweise home.example.com und office.example.com &ndash; wird es notwendig, bei jeder neuen Zonefile für example.com eventuell frühere Einträge zu konservieren. Der Rechner zu Hause weiß beim Bestellen seines DDNS-Eintrags nichts vom Rechner im Büro und umgekehrt. Der Server muß in irgendeiner Form über bereits vergebene Einträge Buch führen und bei einer neuen Anfrage, die example.com betrifft, alle bereits aktiven DDNS-Einträge für example.com mit in die neue Zonefile aufnehmen &ndash auch wenn sie auf Anfragen verschiedener Benutzer zurückgehen.<br />
<br />
==== Datenbank ====<br />
In der Beispielimplementierung werden diese Informationen in einer SQLite-Datenbank gespeichert.<br />
<br />
== Sicherheit ==<br />
=== Rechte ===<br />
Die '''Benutzerrechte''' werden durch das Hostsharing-System kontrolliert. Sowohl das CGI-Programm als auch das [[#Administration|Administrationswerkzeug]] werden mit den Rechten des Domain-Admins (xyz00-benutzername in unserem Beispiel) ausgeführt, also kann dieses Programm nur die Domains bearbeiten, die von xyz00-benutzername verwaltet werden.<br />
<br />
=== Authentifizierung ===<br />
In der Beispielimplementierung (wie auch seinerzeit bei DynDNS.org) wird das CGI-Programm durch einen .htaccess-Eintrag geschützt, der HTTP-Basic-Authentication vorschreibt. Also wird das Programm eigentlich mit einem URL der form<br />
<br />
<nowiki>https://ddnsaccount:passwort@ddns.example.com/cgi-bin/ddns?hostname=...</nowiki><br />
<br />
aufgerufen.<br />
<br />
=== Verschlüsselung ===<br />
Das CGI-Programm sollte nur in example.com/cgi-ssl/ installiert werden, nicht in example.com/cgi/. Damit ist die Kommunikation zwischen Client und Server durch SSL verschlüsselt.<br />
<br />
== Administration ==<br />
<br />
Der Verwalter des DDNS-Programms trägt berechtigte Benutzer und die ihnen zugeteilten Domainnamen in die Datenbank des Programms ein mit Hilfe eines kleinen Hilfsprogramms. Das ist im vorliegenden Fall ein menügesteuertes Programm für die Befehlszeile, daß die naheliegenden Funktionen anbietet: Account hinzufügen, löschen, sperren, entsperren, Paßwort setzen, ändern; Domainnamen hinzufügen, ändern, entsperren, löschen; Accounts und Domainnamen mit aktuellem Status auflisten. Die Funktionen sind auch über Befehlszeilenargumente verfügbar, also skriptfähig.<br />
<br />
Eine Auflistung des momentanen Inhalts der DDNS-Datenbank durch das Administrationswerkzeug könnte beispielsweise so aussehen:<br />
<br />
xyz00-benutzername@h02:~$ bin/ddnsadmin.pl -Aa<br />
1. papst Mißbrauch: 0; gesperrt: nein<br />
avignon.example.com<br />
zuletzt aktiv am Sun Apr 26 22:24:49 2020<br />
mit IP-Nr. 87.65.43.21; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 0; gesperrt: nein<br />
vatican.beispiel.de<br />
zuletzt aktiv am Sun Apr 26 22:24:49 2020<br />
mit IP-Nr. 87.65.43.21; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 0; gesperrt: nein<br />
2. kaiser Mißbrauch: 4; gesperrt: ja<br />
augsburg.beispiel.de<br />
zuletzt aktiv am Fri Apr 24 16:13:49 2020<br />
mit IP-Nr. 64.82.31.75; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 0; gesperrt: ja<br />
3. luther Mißbrauch: 1; gesperrt: nein<br />
wittenberg.example.com<br />
zuletzt aktiv am Mon Apr 27 10:12:49 2020<br />
mit IP-Nr. 78.56.34.12; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 1; gesperrt: nein<br />
xyz00-benutzername@h02:~$<br />
<br />
Das DDNS-Account &bdquo;kaiser&ldquo; in dieser Auflistung ist wohl auf Grund fehlerhafter Anfragen automatisch gesperrt worden. Der Inhaber wird sich wohl bald melden, um nach Korrektur seiner Client-Konfiguration die Aufhebung der Sperre zu wünschen.<br />
<br />
=== Log ===<br />
Alle Anfragen werden in einer täglich wechselnden Log-Datei protokolliert, entweder schlicht oder ausführlich, je nachdem, ob eine Variable <tt>verbose</tt> wahr ist.<br />
Ein ausführlicher Log-Eintrag sieht so aus:<br />
<br />
Sun Apr 26 20:21:45 2020 ddns aufgerufen von papst<br />
unter 84.185.97.8<br />
URL: <nowiki>https://ddns.example.com/cgi-bin/ddns.cgi?hostname=<br />
avignon.example.com,vatican.beispiel.de&<br />
myip=84.185.97.8</nowiki><br />
Verwende IP 84.185.97.8 (= 1421435144)<br />
DB-Version: 1<br />
Skript und DB exklusiv geöffnet<br />
avignon.example.com: IP: 84.185.97.8; MX: 0; Backup-MX: nein;<br />
Wildcard: nein; Mißbrauch: 0; gesperrt: nein <br />
vatican.beispiel.de: IP: 84.185.97.8; MX: 0; Backup-MX: nein;<br />
Wildcard: nein; Mißbrauch: 0; gesperrt: nein <br />
Betroffene Zonen: example.com, beispiel.de<br />
Temporärdatei example.com_hxNa.new geschrieben<br />
Zonendatei /home/pacs/xyz00/users/benutzername/doms/example.com/<br />
etc/pri.example.com eingestellt<br />
Temporärdatei beispiel.de_6HcO.new geschrieben<br />
Zonendatei /home/pacs/xyz00/users/benutzername/doms/beispiel.de/<br />
etc/pri.beispiel.de eingestellt<br />
Abgeschlossen: Fertig<br />
<br />
Wenn <tt>verbose</tt> auf falsch gesetzt ist, sind die Log-Einträge einzeilig.</div>Apc00-tonyhttps://wiki.hostsharing.net/index.php?title=Benutzer:Apc00-tony/Dynamisches_DNS&diff=5194Benutzer:Apc00-tony/Dynamisches DNS2020-04-27T09:04:08Z<p>Apc00-tony: /* Antwort */</p>
<hr />
<div>((Provisorischer Vorspann: Auf Grund einer Mailing-Listen-Diskussion habe ich angefangen, Dynamisches DNS über einen CGI-Skript bei Hostsharing zu realisieren. Meine Lösung habe ich dann vorgestellt; sie wurde für nicht ausreichend selbsterklärend befunden und fand wenig Akzeptanz. Hier also der Versuch, die Sache zu dokumentieren.))<br />
<br />
Mit der regelmäßigen Aufnahme von benutzerspezifischen Zonefiles in seiner DNS-Konfiguration bietet Hostsharing alles, was man braucht, um &bdquo;dynamisches DNS&ldquo; in Eigenregie zu realisieren.<br />
<br />
Das heißt, wenn ich mindestens eine Domain bei Hostsharing verwalte, und mindestens eine Einwahlverbindung (oder DSL-Verbindung) ins Internet mit wechselnder IP-Adresse über irgendeinen ISP für meinen Arbeitsplatzrechner zu Hause betreibe, dann kann ich dem Arbeitsplatzrechner über die DNS-Server von Hostsharing einen vollqualifizieren Domainnamen zuweisen, der der jeweiligen IP-Adresse meiner Einwahlleitung zugeordnet ist.<br />
<br />
<pre><br />
<br />
(ASCII-Art-Diagramm der beschriebenen Konstellation)<br />
<br />
</pre><br />
<br />
Im Folgenden wird eine real existierende Implementierung von Dynamischem DNS (&bdquo;DDNS&ldquo;) beschrieben. Die verschiedenen Elemente könnten durchaus anders realisiert werden; die beschriebene Implementierung könnte durchaus verbessert werden. Sie dient hier der Illustration.<br />
<br />
In der folgenden Beschreibung werden diese Beispielwerte benutzt:<br />
* Ein Hostsharing-Mitglied hat ein Account als Paket-Admin mit Kennung xyz00.<br />
* Im Paket xyz00 gibt es einen Domain-Admin namens xyz00-benutzername.<br />
* Dieser Domain-Admin verwaltet bei Hostsharing die Domains example.com und beispiel.de.<br />
* Ein Benutzer hat zu Hause (oder im Büro) einen Arbeitsplatzrechner hinter der marktüblichen DSL-Leitung, die von seinem ISP bereitgestellt wird.<br />
* Dieser Arbeitsplatzrechner (oder der Router, der seine Internetverbindung steuert) bekommt vom ISP immer wechselnde IP-Adressen zugewiesen.<br />
* Dennoch möchte der Benutzer seinen Arbeitsplatzrechner aus dem Internet unter dem Hostnamen einwahl.example.com ansprechen können.<br />
<br />
Dazu kann ein System wie Hostsharing, das authoritative DNS-Informationen für viele Domains bereitstellt, auch veränderliche DNS-Information über dynamisch verbundene Rechner verwalten &ndash; sofern das ressourcenschonend gemacht werden kann ohne andere Funktionen zu stören.<br />
<br />
== Aufgaben des Servers ==<br />
<br />
Um einem Rechner mit wechselnder IP-Adresse einen DDNS-Eintrag zu bieten, muß der Hostsharing-Server folgendes leisten (in ungefährer Reihenfolge der Ereignisse):<br />
<br />
# Eine Anfrage entgegennehmen, beispielsweise über HTTPS, von einem entfernten Rechner, der einen DNS-Eintrag für seine momentane IP-Adresse wünscht. <br />
# Prüfen, ob die Anfrage einen berechtigten DDNS-Dienst-Usernamen mit zugehörigem Paßwort enthält.<br />
# Prüfen, ob die Anfrage einen gültigen Domainnamen betrifft, den der Server bieten darf.<br />
# Prüfen, ob die Domain example.com demselben Benutzer gehört, unter dessen Namen der Dynamisches-DNS-Server läuft.<br />
# Eine gültige [[Zonefile]] mit &ndash; neben dem bisherigen Inhalt &ndash; einem A-Eintrag für einwahl.example.com in /home/pacs/xyz00/users/benutzername/doms/example.com/pri.example.com schreiben.<br />
# Dem Client eine Bestätigung oder ggf. eine Fehlermeldung als Antwort senden.<br />
# In irgendeiner Datenbank den momentan eingestellter Status all seiner DDNS-Einträge speichern.<br />
# In einer Logdatei protokollieren, daß obiges getan wurde, oder ggf. welche Fehler traten auf.<br />
<br />
== Aufgaben des Clients ==<br />
Bevor ich anfange, meinen Arbeitsplatzrechner so zu konfigurieren, daß er bei welchem Server auch immer einen DDNS-Eintrag anfordert, muß ich mich als verantwortlicher Benutzer dieses Rechners und der dazugehörigen Internetverbindung &ndash; das heißt, als Mensch &ndash; mit dem Betreiber des dynamisches-DNS-Servers vereinbaren, daß ich das darf und welchen Eintrag ich bekommen kann. Im Folgenden wird vorausgesetzt, daß solche Vereinbarungen getroffen und die Parameter geklärt wurden.<br />
<br />
Der DDNS-Client muß aus Server-Sicht nur wenig leisten:<br />
<br />
# Eine Anfrage senden, beispielsweise über HTTPS, an einen entfernten Rechner, der einen Eintrag ins DNS für die momentane IP-Adresse des Clients vornehmen kann.<br />Diese Anfrage muß einem festgelegten Format entsprechen und muß gültige Werte für die Authorisation des Clients, den gewünschten Domainnamen, und eventuell andere Parameter enthalten.<br />
# Eine Antwort des Servers entgegennehmen und als Erfolgs- oder Fehlermeldung auswerten.<br />
# Von überflüssigen Anfragen absehen: das heißt bei Erfolg, nicht wiederholt den gleichen Eintrag erneut wünschen; bei Fehlern, nicht die gleiche fehlerhafte Anfrage erneut schicken.<br />
<br />
== Kommunikation zwischen Client und Server ==<br />
<br />
Ein einziges Nachrichtenpaar von Anfrage und Antwort genügt, um einen DDNS-Eintrag einzurichten: Der Client teilt die IP-Adresse und den Domainnamen mit, die in einem DNS-Eintrag verbunden werden sollen; der Server bestätigt den Auftrag.<br />
<br />
In der Beispielimplementierung erfolgt die Kommunikation über HTTP, und die Anfrage des Clients könnte so aussehen:<br />
<br />
GET /cgi-bin/ddns?hostname=einwahl.example.com&myip=87.65.43.21 HTTP/1.1<br />
Host: ddns.beispiel.de<br />
User-Agent: Fritz!Box DDNS/1.0.1<br />
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==<br />
<br />
Bei Erhalt dieser Anfrage ruft Apache das CGI-Programm .../doms/ddns.beispiel.de/cgi-ssl/ddns auf. Das Fragezeichen trennt den Programmnamen von einem "Query-String", in dem zwei Metavariablen definiert und übergeben werden. Die erste Metavariable, hostname, hat den Wert "einwahl.example.com"; die zweite, myip, hat den Wert "87.65.43.21".<br />
<br />
Das Server-Programm, hier ''ddns'', prüft diese Informationen auf Form und Berechtigung, und schreibt gegebenenfalls einen entsprechenden Eintrag in einer Zonefile. Es schreibt auch verschiedene Informationen in die Standardausgabe. Wenn es die Standardausgabe geschlossen wird &ndash; also spätestens bei Programmende &ndash; schickt Apache diese Informationen als Antwort an den anfragenden Rechner zurück.<br />
<br />
Im Falle unserer Beispielimplementierung sieht die Antwort bei Erfolg so aus: <br />
<br />
HTTP/1.1 200 OK<br />
Date: Wed, 22 Apr 2020 08:35:15 GMT<br />
Server: Apache<br />
Content-Length: 17<br />
Content-Type: text/plain; charset=ISO-8859-1<br />
<br />
good 87.65.43.21<br />
<br />
=== Das DDNS-Protokoll von DynDNS.org ===<br />
<br />
In den 90er Jahren, bevor das Internet so durchgehend vergeschäftlicht wurde, boten einige Organisationen kostenlose DDNS-Dienste an. Ein sehr beliebtes Angebot war das von DynDNS.org. Das DDNS-Protokoll von diesem Dienst wurde sogar in Einwahl-Routern einprogrammiert und der Dienst wurde von ISPs und Router-Herstellern als Leistungsmerkmal beworben.<br />
<br />
DynDNS.org gehört inzwischen Oracle und bietet keine kostenlose Dienste mehr. Dennoch wird das DDNS-Protokoll von DynDNS.org in der vorliegenden Beispielimplementierung übernommen in der Hoffnung, daß die Kompatibilität mit einigen gängigen Einwahl-Routern von Vorteil sein kann. Es gibt noch eine kurze Online-Dokumentation der [https://help.dyn.com/remote-access-api/perform-update/ Anfrage] und [https://help.dyn.com/remote-access-api/perform-update/ Antwortnachrichten].<br />
<br />
Das gesammte Protokoll sieht einen einzigen Nachrichtenaustausch aus Anfrage und Antwort vor. Die Anfrage kann mehrere Argumente enthalten; die Antwort kann verschiedene Code-Wörtern enthalten. Übrigens können in einer einzigen Anfrage mehrere DNS-Einträge gewünscht werden. In diesem Fall kann die Antwort mehrzeilig ausfallen.<br />
<br />
Das Verhalten von Server und Client bei künftigen Kommunikationsvorgängen wird unter Umständen von vorangegangenen Kommunikationsergebnissen beeinflußt: nach wiederholten fehlerhaften oder redundanten Anfragen kann der Server weitere Anfragen des Benutzers verweigern; nach wiederholten Fehlermeldungen sollte ein Client aufhören, immer dieselbe Anfrage zu schicken. Und für den Fall, daß mehrere Clients dynamische DNS-Einträge in derselben Domain example.com bestellen, muß der Server den Stand aller Client-Einträge intern speichern, damit er nicht mit einer neuen Zonefile einen früher erstellten Eintrag löscht. Zu diesen Fragen siehe den Abschnitt '''[[#Sukzessive_Kommunikationsabläufe]]''' nach der Beschreibung von Anfragen und Antworten unten.<br />
<br />
====Anfrage====<br />
<br />
Die Anfrage in Form eines URL übergibt dem DDNS-Programm in einem 'Query-String' einige Metavariablen. Das heißt, in einem URL der Form<br />
<br />
<nowiki>https://benutzername:passwort@ddns.beisiel.de/cgi-bin/ddns?hostname=einwahl.example.com&myip=87.65.43.21</nowiki><br />
<br />
signalisert das Fragezeichen, daß ein Query-String folgt. In einem solchen Query-String können in der Beispielimplementierung folgende Metavariablen definiert werden:<br />
<br />
{| class="wikitable"<br />
|- class="hintergrundfarbe5"<br />
! Variable !! Beispiel !! Bemerkungen<br />
|-<br />
| hostname || <tt>hostname=einwahl.example.com</tt><br /><div style="font-size:smaller;"><tt>hostname=eins.example.com,zwei.example.com[,...]</tt></div> ||<br />
Muß ein vollständig qualifizierter Domain-Name ("FQDN") sein; <tt>example.com</tt> muß eine vom Besitzer des DDNS-Programms verwaltete Domain sein. Genaugenommen kann der Wert eine durch Kommata gegliederte Liste mehrerer gültiger Domainnamen sein, falls mehrere Einträge mit derselben IP-Adresse gewünscht werden.<br />
|-<br />
| myip || <tt>myip=87.65.43.21</tt>||<br />
Kann entfallen; kann vom Server ignoriert werden. Maßgeblich ist dann die IP-Adresse des Absenders, wie sie vom Web-Server mitgeteilt wird.<br />
|-<br />
| mx || <tt>mx=87.65.43.21</tt><br /><tt>mx=NOCHG</tt><br /> ||<br />
Neben dem A-Eintrag möchte der Client auch einen MX-Eintrag. Der Wert <tt>NOCHG</tt> (für &bdquo;no change&ldquo;) bedeutet, der bestehende MX-Eintrag (oder seine Abwesenheit) soll nicht geändert werden. <br />
|-<br />
| backmx || <tt>backmx=YES</tt><br /><tt>backmx=NOCHG</tt><br /><tt>backmx=NO</tt> ||<br />
Falls <tt>YES</tt>, wird ein zweiter MX-Eintrag erzeugt, der <tt>einwahl.example.com</tt> als Mail-Server für <tt>einwahl.example.com</tt> nennt. Dieser Eintrag hat eine niedrigere Präferenzzahl (also eine höhere Priorität) als der mit <tt>mx</tt> angeforderten Eintrag.<br />
|-<br />
| wildcard || <tt>wildcard=ON</tt><br /><tt>wildcard=NOCHG</tt><br /><tt>wildcard=OFF</tt> ||<br />
Neben dem A-Eintrag für den Domainnamen <tt>einwahl.example.com</tt> wünscht der Client auch einen Eintrag für beliebige Subdomains, also <tt>*.einwahl.example.com</tt>, mit der gleichen IP-Adresse.<br />
|-<br />
| offline ||<tt>offline=YES</tt><br /><tt>offline=NOCHG</tt>||<br />
Falls <tt>YES</tt>, wird ein DNS-Eintrag für <tt>einwahl.example.com</tt> aus der Zonefile getilgt. Gegebenenfalls wird der Hostname dann auf Grund eines parallelen Wildcard-Eintrags für <tt>*.example.com</tt> einer anderen IP-Adresse zugeordnet werden.<br />
|}<br />
<br />
<!-- IPv6? --><br />
<br />
Alle Parameter bis auf hostname können entfallen. Bei nichtdokumentierten Argumenten ist das Verhalten undefiniert&trade;.<br />
<br />
====Antwort====<br />
<br />
Die Antwort auf eine erfolgreiche HTTP-Anfrage besteht im häufigsten Fall aus einigen Header-Zeilen, gefolgt vom Inhalt der gewünschten Text- oder andere Datei. Ein Status-Code in der ersten Header-Zeile gibt an, ob die Anfrage bedient werden kann oder kreist andernfalls den Grund für die Enttäuschung ein.<br />
<br />
Die vorliegende Beispielimplementierung von DDNS schickt einen der üblichen HTTP-Status-Codes "200 OK" oder "500 Internal Server Error", gefolgt von einer kurzen Textnachricht nach dem HTTP-Header. Bei diesem Programm ist &ndash; laut Gebrauchshinweise von DynDNS.org &ndash; ''nicht'' der Status-Code im Header, sondern der Inhalt der Nachricht die definierte, maßgebliche Ergebnismeldung des Programms.<br />
<br />
{| class="wikitable"<br />
|- class="hintergrundfarbe5"<br />
! Meldung !! Bedeutung !! Bemerkungen<br />
|-<br />
| <tt>good&nbsp;&lt;IP&nbsp;number&gt;</tt> ||<br />
Der gewünschte DNS-Eintrag wurde erfolgreich in einer Zonefile eingetragen. <br />
|| Es kann natürlich noch einige Minuten dauern, bis die Zonefile vom Hostsharing-Roboter abgelesen wird und der Inhalt in die BIND-Konfiguration übernommen.<br />
|-<br />
| <tt>good&nbsp;127.0.0.1</tt> ||<br />
Die Anfrage entsprach nicht den Erfordernissen des Servers.<br />
|| Trotz des Worts <tt>good</tt> war die Anfrage nicht erfolgreich, falls in der Rückmeldung die IP-Adresse mit <tt>127.0.0.1</tt> angegeben wird. Dieser verwirrende Fehlercode ist aus unerklärlichen Gründen in der Spezifikation von DynDNS.org so definiert.<br />
|-<br />
| <tt>nochg&nbsp;&lt;IP&nbsp;number&gt;</tt> ||<br />
Der gewünschte DNS-Eintrag war bereits vorhanden. <br />
|| Der Server selbst macht keine DNS-Abfrage, um das zu vermitteln: die &bdquo;no change&ldquo;-Antwort besagt nur, daß eine Anfrage für diesen Eintrag bereits mit Erfolg quittiert wurde.<br />
|-<br />
| <tt>notfqdn</tt> ||<br />
Fehlschlag: der gewünschte Domainname ist nicht gültig, oder es wurde keiner angegeben.<br />
|| ...<br />
|-<br />
| <tt>nohost</tt> ||<br />
Fehlschlag: der gewünschte Domainname ist gehört nicht zu denen, die für diesen Benutzer des DDNS-Dienstes konfiguriert sind.<br />
|| Siehe den Abschnitt '''Administration''' weiter unten.<br />
|-<br />
| <tt>abuse</tt> ||<br />
Fehlschlag: der gewünschte Domainname ist wegen vorangeganger Fehlschläge oder überflüssiger Aufrufe gesperrt.<br />
|| Siehe den Abschnitt '''Sukzessive Kommunikationsvorgänge''' unten.<br />
|-<br />
| <tt>911</tt> ||<br />
Fehlschlag: Das Server-Programm hat einen internen Fehler festgestellt.<br />
|| Das Problem liegt nicht in der Anfrage an sich.<br />
|}<br />
<br />
Man kann sich durchaus eine sinnreichere Kommunikation zwischen Client und Server vorstellen, doch das hier beschriebene Protokoll ist eben von DynDNS.org verwendet worden und wird in gängigen Routern implementiert, also wird es in der vorliegenden DDNS-Implementierung nachgebildet.<br />
<br />
=== Sukzessive Kommunikationsabläufe ===<br />
Der Server muß sich zwischen einzelnen Aufrufen einiges merken, um Ressourcen zu schonen und um zu verhindern, daß einmal vergebene DDNS-Einträge von neuen Anfragen, die dieselbe übergeordnete Domain betreffen, durch Überschreiben verlorengehen.<br />
<br />
==== Mißbrauch und Benutzersperrung ====<br />
Zur Schonung von Ressourcen muß sich die Implementierung weigern, sich mit zuvielen fehlerhaften oder auch nur überflüssigen Anfragen zu beschäftigen. Dazu führt eine Strichliste über solche Anfragen jedes Clients und sperrt nach einer bestimmten Anzahl solcher Anfragen den Benutzernamen oder einzelne Domainnamen gegen die weitere Nutzung des Dienstes.<br />
<br />
Mißbrauchspunkte gegen einen einzelnen Domainnamen gibt es für:<br />
* eine Anfrage, die keinen neuen DNS-Eintrag (und keine Änderung oder Löschung eines Eintrags) erfordert, sondern bestehende Merkmale nur wiederholt<br />
<br />
Mißbrauchspunkte gegen einen Benutzernamen gibt es für:<br />
* die Angabe eines Domainnamens, der in der Dienstkonfiguration dem anfragenden Benutzernamen nicht zugeordnet ist<br />
* die Angabe eines Domainnamen in einer Domain, die nicht demselben Hostsharing-Domain-Admin gehört, der den DDNS-Dienst anbietet<br />
* die Angabe eines Domainnamens, der in der Dienstkonfiguration bereits wegen mißbräuchlicher Anfragen gesperrt ist (siehe oben)<br />
<br />
Um eine Sperrung aufzuheben, wird in der Regel eine Handlung durch den Administrator erforderlich sein.<br />
<br />
==== Mehrere dynamische Subdomains in derselben Domain ====<br />
Sobald zwei verschiedene DDNS-Einträge in derselben Domain verlangt werden &ndash; beispielsweise home.example.com und office.example.com &ndash; wird es notwendig, bei jeder neuen Zonefile für example.com eventuell frühere Einträge zu konservieren. Der Rechner zu Hause weiß beim Bestellen seines DDNS-Eintrags nichts vom Rechner im Büro und umgekehrt. Der Server muß in irgendeiner Form über bereits vergebene Einträge Buch führen und bei einer neuen Anfrage, die example.com betrifft, alle bereits aktiven DDNS-Einträge für example.com mit in die neue Zonefile aufnehmen &ndash auch wenn sie auf Anfragen verschiedener Benutzer zurückgehen.<br />
<br />
==== Datenbank ====<br />
In der Beispielimplementierung werden diese Informationen in einer SQLite-Datenbank gespeichert.<br />
<br />
== Sicherheit ==<br />
=== Rechte ===<br />
Die '''Benutzerrechte''' werden durch das Hostsharing-System kontrolliert. Sowohl das CGI-Programm als auch das [[#Administration|Administrationswerkzeug]] werden mit den Rechten des Domain-Admins (xyz00-benutzername in unserem Beispiel) ausgeführt, also kann dieses Programm nur die Domains bearbeiten, die von xyz00-benutzername verwaltet werden.<br />
<br />
=== Authentifizierung ===<br />
In der Beispielimplementierung (wie auch seinerzeit bei DynDNS.org) wird das CGI-Programm durch einen .htaccess-Eintrag geschützt, der HTTP-Basic-Authentication vorschreibt. Also wird das Programm eigentlich mit einem URL der form<br />
<br />
<nowiki>https://ddnsaccount:passwort@ddns.example.com/cgi-bin/ddns?hostname=...</nowiki><br />
<br />
aufgerufen.<br />
<br />
=== Verschlüsselung ===<br />
Das CGI-Programm sollte nur in example.com/cgi-ssl/ installiert werden, nicht in example.com/cgi/. Damit ist die Kommunikation zwischen Client und Server durch SSL verschlüsselt.<br />
<br />
== Administration ==<br />
<br />
Der Verwalter des DDNS-Programms trägt berechtigte Benutzer und die ihnen zugeteilten Domainnamen in die Datenbank des Programms ein mit Hilfe eines kleinen Hilfsprogramms. Das ist im vorliegenden Fall ein menügesteuertes Programm für die Befehlszeile, daß die naheliegenden Funktionen anbietet: Account hinzufügen, löschen, sperren, entsperren, Paßwort setzen, ändern; Domainnamen hinzufügen, ändern, entsperren, löschen; Accounts und Domainnamen mit aktuellem Status auflisten. Die Funktionen sind auch über Befehlszeilenargumente verfügbar, also skriptfähig.<br />
<br />
Eine Auflistung des momentanen Inhalts der DDNS-Datenbank durch das Administrationswerkzeug könnte beispielsweise so aussehen:<br />
<br />
xyz00-benutzername@h02:~$ bin/ddnsadmin.pl -Aa<br />
1. papst Mißbrauch: 0; gesperrt: nein<br />
avignon.example.com<br />
zuletzt aktiv am Sun Apr 26 22:24:49 2020<br />
mit IP-Nr. 87.65.43.21; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 0; gesperrt: nein<br />
vatican.beispiel.de<br />
zuletzt aktiv am Sun Apr 26 22:24:49 2020<br />
mit IP-Nr. 87.65.43.21; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 0; gesperrt: nein<br />
2. kaiser Mißbrauch: 4; gesperrt: ja<br />
augsburg.beispiel.de<br />
zuletzt aktiv am Fri Apr 24 16:13:49 2020<br />
mit IP-Nr. 64.82.31.75; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 0; gesperrt: ja<br />
3. luther Mißbrauch: 1; gesperrt: nein<br />
wittenberg.example.com<br />
zuletzt aktiv am Mon Apr 27 10:12:49 2020<br />
mit IP-Nr. 78.56.34.12; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 1; gesperrt: nein<br />
xyz00-benutzername@h02:~$<br />
<br />
Das DDNS-Account &bdquo;kaiser&ldquo; in dieser Auflistung ist wohl auf Grund fehlerhafter Anfragen automatisch gesperrt worden. Der Inhaber wird sich wohl bald melden, um nach Korrektur seiner Client-Konfiguration die Aufhebung der Sperre zu wünschen.<br />
<br />
=== Log ===<br />
Alle Anfragen werden in einer täglich wechselnden Log-Datei protokolliert, entweder schlicht oder ausführlich, je nachdem, ob eine Variable <tt>verbose</tt> wahr ist.<br />
Ein ausführlicher Log-Eintrag sieht so aus:<br />
<br />
Sun Apr 26 20:21:45 2020 ddns aufgerufen von papst<br />
unter 84.185.97.8<br />
URL: <nowiki>https://ddns.example.com/cgi-bin/ddns.cgi?hostname=<br />
avignon.example.com,vatican.beispiel.de&<br />
myip=84.185.97.8</nowiki><br />
Verwende IP 84.185.97.8 (= 1421435144)<br />
DB-Version: 1<br />
Skript und DB exklusiv geöffnet<br />
avignon.example.com: IP: 84.185.97.8; MX: 0; Backup-MX: nein;<br />
Wildcard: nein; Mißbrauch: 0; gesperrt: nein <br />
vatican.beispiel.de: IP: 84.185.97.8; MX: 0; Backup-MX: nein;<br />
Wildcard: nein; Mißbrauch: 0; gesperrt: nein <br />
Betroffene Zonen: example.com, beispiel.de<br />
Temporärdatei example.com_hxNa.new geschrieben<br />
Zonendatei /home/pacs/xyz00/users/benutzername/doms/example.com/<br />
etc/pri.example.com eingestellt<br />
Temporärdatei beispiel.de_6HcO.new geschrieben<br />
Zonendatei /home/pacs/xyz00/users/benutzername/doms/beispiel.de/<br />
etc/pri.beispiel.de eingestellt<br />
Abgeschlossen: Fertig<br />
<br />
Wenn <tt>verbose</tt> auf falsch gesetzt ist, sind die Log-Einträge einzeilig.</div>Apc00-tonyhttps://wiki.hostsharing.net/index.php?title=Benutzer:Apc00-tony/Dynamisches_DNS&diff=5193Benutzer:Apc00-tony/Dynamisches DNS2020-04-27T08:57:44Z<p>Apc00-tony: /* Administration */</p>
<hr />
<div>((Provisorischer Vorspann: Auf Grund einer Mailing-Listen-Diskussion habe ich angefangen, Dynamisches DNS über einen CGI-Skript bei Hostsharing zu realisieren. Meine Lösung habe ich dann vorgestellt; sie wurde für nicht ausreichend selbsterklärend befunden und fand wenig Akzeptanz. Hier also der Versuch, die Sache zu dokumentieren.))<br />
<br />
Mit der regelmäßigen Aufnahme von benutzerspezifischen Zonefiles in seiner DNS-Konfiguration bietet Hostsharing alles, was man braucht, um &bdquo;dynamisches DNS&ldquo; in Eigenregie zu realisieren.<br />
<br />
Das heißt, wenn ich mindestens eine Domain bei Hostsharing verwalte, und mindestens eine Einwahlverbindung (oder DSL-Verbindung) ins Internet mit wechselnder IP-Adresse über irgendeinen ISP für meinen Arbeitsplatzrechner zu Hause betreibe, dann kann ich dem Arbeitsplatzrechner über die DNS-Server von Hostsharing einen vollqualifizieren Domainnamen zuweisen, der der jeweiligen IP-Adresse meiner Einwahlleitung zugeordnet ist.<br />
<br />
<pre><br />
<br />
(ASCII-Art-Diagramm der beschriebenen Konstellation)<br />
<br />
</pre><br />
<br />
Im Folgenden wird eine real existierende Implementierung von Dynamischem DNS (&bdquo;DDNS&ldquo;) beschrieben. Die verschiedenen Elemente könnten durchaus anders realisiert werden; die beschriebene Implementierung könnte durchaus verbessert werden. Sie dient hier der Illustration.<br />
<br />
In der folgenden Beschreibung werden diese Beispielwerte benutzt:<br />
* Ein Hostsharing-Mitglied hat ein Account als Paket-Admin mit Kennung xyz00.<br />
* Im Paket xyz00 gibt es einen Domain-Admin namens xyz00-benutzername.<br />
* Dieser Domain-Admin verwaltet bei Hostsharing die Domains example.com und beispiel.de.<br />
* Ein Benutzer hat zu Hause (oder im Büro) einen Arbeitsplatzrechner hinter der marktüblichen DSL-Leitung, die von seinem ISP bereitgestellt wird.<br />
* Dieser Arbeitsplatzrechner (oder der Router, der seine Internetverbindung steuert) bekommt vom ISP immer wechselnde IP-Adressen zugewiesen.<br />
* Dennoch möchte der Benutzer seinen Arbeitsplatzrechner aus dem Internet unter dem Hostnamen einwahl.example.com ansprechen können.<br />
<br />
Dazu kann ein System wie Hostsharing, das authoritative DNS-Informationen für viele Domains bereitstellt, auch veränderliche DNS-Information über dynamisch verbundene Rechner verwalten &ndash; sofern das ressourcenschonend gemacht werden kann ohne andere Funktionen zu stören.<br />
<br />
== Aufgaben des Servers ==<br />
<br />
Um einem Rechner mit wechselnder IP-Adresse einen DDNS-Eintrag zu bieten, muß der Hostsharing-Server folgendes leisten (in ungefährer Reihenfolge der Ereignisse):<br />
<br />
# Eine Anfrage entgegennehmen, beispielsweise über HTTPS, von einem entfernten Rechner, der einen DNS-Eintrag für seine momentane IP-Adresse wünscht. <br />
# Prüfen, ob die Anfrage einen berechtigten DDNS-Dienst-Usernamen mit zugehörigem Paßwort enthält.<br />
# Prüfen, ob die Anfrage einen gültigen Domainnamen betrifft, den der Server bieten darf.<br />
# Prüfen, ob die Domain example.com demselben Benutzer gehört, unter dessen Namen der Dynamisches-DNS-Server läuft.<br />
# Eine gültige [[Zonefile]] mit &ndash; neben dem bisherigen Inhalt &ndash; einem A-Eintrag für einwahl.example.com in /home/pacs/xyz00/users/benutzername/doms/example.com/pri.example.com schreiben.<br />
# Dem Client eine Bestätigung oder ggf. eine Fehlermeldung als Antwort senden.<br />
# In irgendeiner Datenbank den momentan eingestellter Status all seiner DDNS-Einträge speichern.<br />
# In einer Logdatei protokollieren, daß obiges getan wurde, oder ggf. welche Fehler traten auf.<br />
<br />
== Aufgaben des Clients ==<br />
Bevor ich anfange, meinen Arbeitsplatzrechner so zu konfigurieren, daß er bei welchem Server auch immer einen DDNS-Eintrag anfordert, muß ich mich als verantwortlicher Benutzer dieses Rechners und der dazugehörigen Internetverbindung &ndash; das heißt, als Mensch &ndash; mit dem Betreiber des dynamisches-DNS-Servers vereinbaren, daß ich das darf und welchen Eintrag ich bekommen kann. Im Folgenden wird vorausgesetzt, daß solche Vereinbarungen getroffen und die Parameter geklärt wurden.<br />
<br />
Der DDNS-Client muß aus Server-Sicht nur wenig leisten:<br />
<br />
# Eine Anfrage senden, beispielsweise über HTTPS, an einen entfernten Rechner, der einen Eintrag ins DNS für die momentane IP-Adresse des Clients vornehmen kann.<br />Diese Anfrage muß einem festgelegten Format entsprechen und muß gültige Werte für die Authorisation des Clients, den gewünschten Domainnamen, und eventuell andere Parameter enthalten.<br />
# Eine Antwort des Servers entgegennehmen und als Erfolgs- oder Fehlermeldung auswerten.<br />
# Von überflüssigen Anfragen absehen: das heißt bei Erfolg, nicht wiederholt den gleichen Eintrag erneut wünschen; bei Fehlern, nicht die gleiche fehlerhafte Anfrage erneut schicken.<br />
<br />
== Kommunikation zwischen Client und Server ==<br />
<br />
Ein einziges Nachrichtenpaar von Anfrage und Antwort genügt, um einen DDNS-Eintrag einzurichten: Der Client teilt die IP-Adresse und den Domainnamen mit, die in einem DNS-Eintrag verbunden werden sollen; der Server bestätigt den Auftrag.<br />
<br />
In der Beispielimplementierung erfolgt die Kommunikation über HTTP, und die Anfrage des Clients könnte so aussehen:<br />
<br />
GET /cgi-bin/ddns?hostname=einwahl.example.com&myip=87.65.43.21 HTTP/1.1<br />
Host: ddns.beispiel.de<br />
User-Agent: Fritz!Box DDNS/1.0.1<br />
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==<br />
<br />
Bei Erhalt dieser Anfrage ruft Apache das CGI-Programm .../doms/ddns.beispiel.de/cgi-ssl/ddns auf. Das Fragezeichen trennt den Programmnamen von einem "Query-String", in dem zwei Metavariablen definiert und übergeben werden. Die erste Metavariable, hostname, hat den Wert "einwahl.example.com"; die zweite, myip, hat den Wert "87.65.43.21".<br />
<br />
Das Server-Programm, hier ''ddns'', prüft diese Informationen auf Form und Berechtigung, und schreibt gegebenenfalls einen entsprechenden Eintrag in einer Zonefile. Es schreibt auch verschiedene Informationen in die Standardausgabe. Wenn es die Standardausgabe geschlossen wird &ndash; also spätestens bei Programmende &ndash; schickt Apache diese Informationen als Antwort an den anfragenden Rechner zurück.<br />
<br />
Im Falle unserer Beispielimplementierung sieht die Antwort bei Erfolg so aus: <br />
<br />
HTTP/1.1 200 OK<br />
Date: Wed, 22 Apr 2020 08:35:15 GMT<br />
Server: Apache<br />
Content-Length: 17<br />
Content-Type: text/plain; charset=ISO-8859-1<br />
<br />
good 87.65.43.21<br />
<br />
=== Das DDNS-Protokoll von DynDNS.org ===<br />
<br />
In den 90er Jahren, bevor das Internet so durchgehend vergeschäftlicht wurde, boten einige Organisationen kostenlose DDNS-Dienste an. Ein sehr beliebtes Angebot war das von DynDNS.org. Das DDNS-Protokoll von diesem Dienst wurde sogar in Einwahl-Routern einprogrammiert und der Dienst wurde von ISPs und Router-Herstellern als Leistungsmerkmal beworben.<br />
<br />
DynDNS.org gehört inzwischen Oracle und bietet keine kostenlose Dienste mehr. Dennoch wird das DDNS-Protokoll von DynDNS.org in der vorliegenden Beispielimplementierung übernommen in der Hoffnung, daß die Kompatibilität mit einigen gängigen Einwahl-Routern von Vorteil sein kann. Es gibt noch eine kurze Online-Dokumentation der [https://help.dyn.com/remote-access-api/perform-update/ Anfrage] und [https://help.dyn.com/remote-access-api/perform-update/ Antwortnachrichten].<br />
<br />
Das gesammte Protokoll sieht einen einzigen Nachrichtenaustausch aus Anfrage und Antwort vor. Die Anfrage kann mehrere Argumente enthalten; die Antwort kann verschiedene Code-Wörtern enthalten. Übrigens können in einer einzigen Anfrage mehrere DNS-Einträge gewünscht werden. In diesem Fall kann die Antwort mehrzeilig ausfallen.<br />
<br />
Das Verhalten von Server und Client bei künftigen Kommunikationsvorgängen wird unter Umständen von vorangegangenen Kommunikationsergebnissen beeinflußt: nach wiederholten fehlerhaften oder redundanten Anfragen kann der Server weitere Anfragen des Benutzers verweigern; nach wiederholten Fehlermeldungen sollte ein Client aufhören, immer dieselbe Anfrage zu schicken. Und für den Fall, daß mehrere Clients dynamische DNS-Einträge in derselben Domain example.com bestellen, muß der Server den Stand aller Client-Einträge intern speichern, damit er nicht mit einer neuen Zonefile einen früher erstellten Eintrag löscht. Zu diesen Fragen siehe den Abschnitt '''[[#Sukzessive_Kommunikationsabläufe]]''' nach der Beschreibung von Anfragen und Antworten unten.<br />
<br />
====Anfrage====<br />
<br />
Die Anfrage in Form eines URL übergibt dem DDNS-Programm in einem 'Query-String' einige Metavariablen. Das heißt, in einem URL der Form<br />
<br />
<nowiki>https://benutzername:passwort@ddns.beisiel.de/cgi-bin/ddns?hostname=einwahl.example.com&myip=87.65.43.21</nowiki><br />
<br />
signalisert das Fragezeichen, daß ein Query-String folgt. In einem solchen Query-String können in der Beispielimplementierung folgende Metavariablen definiert werden:<br />
<br />
{| class="wikitable"<br />
|- class="hintergrundfarbe5"<br />
! Variable !! Beispiel !! Bemerkungen<br />
|-<br />
| hostname || <tt>hostname=einwahl.example.com</tt><br /><div style="font-size:smaller;"><tt>hostname=eins.example.com,zwei.example.com[,...]</tt></div> ||<br />
Muß ein vollständig qualifizierter Domain-Name ("FQDN") sein; <tt>example.com</tt> muß eine vom Besitzer des DDNS-Programms verwaltete Domain sein. Genaugenommen kann der Wert eine durch Kommata gegliederte Liste mehrerer gültiger Domainnamen sein, falls mehrere Einträge mit derselben IP-Adresse gewünscht werden.<br />
|-<br />
| myip || <tt>myip=87.65.43.21</tt>||<br />
Kann entfallen; kann vom Server ignoriert werden. Maßgeblich ist dann die IP-Adresse des Absenders, wie sie vom Web-Server mitgeteilt wird.<br />
|-<br />
| mx || <tt>mx=87.65.43.21</tt><br /><tt>mx=NOCHG</tt><br /> ||<br />
Neben dem A-Eintrag möchte der Client auch einen MX-Eintrag. Der Wert <tt>NOCHG</tt> (für &bdquo;no change&ldquo;) bedeutet, der bestehende MX-Eintrag (oder seine Abwesenheit) soll nicht geändert werden. <br />
|-<br />
| backmx || <tt>backmx=YES</tt><br /><tt>backmx=NOCHG</tt><br /><tt>backmx=NO</tt> ||<br />
Falls <tt>YES</tt>, wird ein zweiter MX-Eintrag erzeugt, der <tt>einwahl.example.com</tt> als Mail-Server für <tt>einwahl.example.com</tt> nennt. Dieser Eintrag hat eine niedrigere Präferenzzahl (also eine höhere Priorität) als der mit <tt>mx</tt> angeforderten Eintrag.<br />
|-<br />
| wildcard || <tt>wildcard=ON</tt><br /><tt>wildcard=NOCHG</tt><br /><tt>wildcard=OFF</tt> ||<br />
Neben dem A-Eintrag für den Domainnamen <tt>einwahl.example.com</tt> wünscht der Client auch einen Eintrag für beliebige Subdomains, also <tt>*.einwahl.example.com</tt>, mit der gleichen IP-Adresse.<br />
|-<br />
| offline ||<tt>offline=YES</tt><br /><tt>offline=NOCHG</tt>||<br />
Falls <tt>YES</tt>, wird ein DNS-Eintrag für <tt>einwahl.example.com</tt> aus der Zonefile getilgt. Gegebenenfalls wird der Hostname dann auf Grund eines parallelen Wildcard-Eintrags für <tt>*.example.com</tt> einer anderen IP-Adresse zugeordnet werden.<br />
|}<br />
<br />
<!-- IPv6? --><br />
<br />
Alle Parameter bis auf hostname können entfallen. Bei nichtdokumentierten Argumenten ist das Verhalten undefiniert&trade;.<br />
<br />
====Antwort====<br />
<br />
Die Antwort auf eine erfolgreiche HTTP-Anfrage besteht im häufigsten Fall aus einigen Header-Zeilen, gefolgt vom Inhalt der gewünschten Text- oder andere Datei. Ein Status-Code in der ersten Header-Zeile gibt an, ob die Anfrage bedient werden kann oder kreist andernfalls den Grund für die Enttäuschung ein.<br />
<br />
Die vorliegende Beispielimplementierung von DDNS schickt einen der üblichen HTTP-Status-Codes "200 OK" oder "500 Internal Server Error", gefolgt von einer kurzen Textnachricht nach dem HTTP-Header. Bei diesem Programm ist &ndash; laut Gebrauchshinweise von DynDNS.org &ndash; ''nicht'' der Status-Code im Header, sondern der Inhalt der Nachricht die definierte, maßgebliche Ergebnismeldung des Programms.<br />
<br />
{| class="wikitable"<br />
|- class="hintergrundfarbe5"<br />
! Meldung !! Bedeutung !! Bemerkungen<br />
|-<br />
| <tt>good&nbsp;&lt;IP&nbsp;number&gt;</tt> ||<br />
Der gewünschte DNS-Eintrag wurde erfolgreich in einer Zonefile eingetragen. <br />
|| Es kann natürlich noch einige Minuten dauern, bis die Zonefile vom Hostsharing-Roboter abgelesen wird und der Inhalt in die BIND-Konfiguration übernommen.<br />
|-<br />
| <tt>nochg&nbsp;&lt;IP&nbsp;number&gt;</tt> ||<br />
Der gewünschte DNS-Eintrag war bereits vorhanden. <br />
|| Der Server selbst macht keine DNS-Abfrage, um das zu vermitteln: die &bdquo;no change&ldquo;-Antwort besagt nur, daß eine Anfrage für diesen Eintrag bereits mit Erfolg quittiert wurde.<br />
|-<br />
| <tt>notfqdn</tt> ||<br />
Fehlschlag: der gewünschte Domainname ist nicht gültig, oder es wurde keiner angegeben.<br />
|| ...<br />
|-<br />
| <tt>nohost</tt> ||<br />
Fehlschlag: der gewünschte Domainname ist gehört nicht zu denen, die für diesen Benutzer des DDNS-Dienstes konfiguriert sind.<br />
|| Siehe den Abschnitt '''Administration''' weiter unten.<br />
|-<br />
| <tt>abuse</tt> ||<br />
Fehlschlag: der gewünschte Domainname ist wegen vorangeganger Fehlschläge oder überflüssiger Aufrufe gesperrt.<br />
|| Siehe den Abschnitt '''Sukzessive Kommunikationsvorgänge''' unten.<br />
|-<br />
| <tt>911</tt> ||<br />
Fehlschlag: Das Server-Programm hat einen internen Fehler festgestellt.<br />
|| Das Problem liegt nicht in der Anfrage an sich.<br />
|}<br />
<br />
Man kann sich durchaus eine sinnreichere Kommunikation zwischen Client und Server vorstellen, doch das hier beschriebene Protokoll ist eben von DynDNS.org verwendet worden und wird in gängigen Routern implementiert, also wird es in der vorliegenden DDNS-Implementierung nachgebildet.<br />
<br />
=== Sukzessive Kommunikationsabläufe ===<br />
Der Server muß sich zwischen einzelnen Aufrufen einiges merken, um Ressourcen zu schonen und um zu verhindern, daß einmal vergebene DDNS-Einträge von neuen Anfragen, die dieselbe übergeordnete Domain betreffen, durch Überschreiben verlorengehen.<br />
<br />
==== Mißbrauch und Benutzersperrung ====<br />
Zur Schonung von Ressourcen muß sich die Implementierung weigern, sich mit zuvielen fehlerhaften oder auch nur überflüssigen Anfragen zu beschäftigen. Dazu führt eine Strichliste über solche Anfragen jedes Clients und sperrt nach einer bestimmten Anzahl solcher Anfragen den Benutzernamen oder einzelne Domainnamen gegen die weitere Nutzung des Dienstes.<br />
<br />
Mißbrauchspunkte gegen einen einzelnen Domainnamen gibt es für:<br />
* eine Anfrage, die keinen neuen DNS-Eintrag (und keine Änderung oder Löschung eines Eintrags) erfordert, sondern bestehende Merkmale nur wiederholt<br />
<br />
Mißbrauchspunkte gegen einen Benutzernamen gibt es für:<br />
* die Angabe eines Domainnamens, der in der Dienstkonfiguration dem anfragenden Benutzernamen nicht zugeordnet ist<br />
* die Angabe eines Domainnamen in einer Domain, die nicht demselben Hostsharing-Domain-Admin gehört, der den DDNS-Dienst anbietet<br />
* die Angabe eines Domainnamens, der in der Dienstkonfiguration bereits wegen mißbräuchlicher Anfragen gesperrt ist (siehe oben)<br />
<br />
Um eine Sperrung aufzuheben, wird in der Regel eine Handlung durch den Administrator erforderlich sein.<br />
<br />
==== Mehrere dynamische Subdomains in derselben Domain ====<br />
Sobald zwei verschiedene DDNS-Einträge in derselben Domain verlangt werden &ndash; beispielsweise home.example.com und office.example.com &ndash; wird es notwendig, bei jeder neuen Zonefile für example.com eventuell frühere Einträge zu konservieren. Der Rechner zu Hause weiß beim Bestellen seines DDNS-Eintrags nichts vom Rechner im Büro und umgekehrt. Der Server muß in irgendeiner Form über bereits vergebene Einträge Buch führen und bei einer neuen Anfrage, die example.com betrifft, alle bereits aktiven DDNS-Einträge für example.com mit in die neue Zonefile aufnehmen &ndash auch wenn sie auf Anfragen verschiedener Benutzer zurückgehen.<br />
<br />
==== Datenbank ====<br />
In der Beispielimplementierung werden diese Informationen in einer SQLite-Datenbank gespeichert.<br />
<br />
== Sicherheit ==<br />
=== Rechte ===<br />
Die '''Benutzerrechte''' werden durch das Hostsharing-System kontrolliert. Sowohl das CGI-Programm als auch das [[#Administration|Administrationswerkzeug]] werden mit den Rechten des Domain-Admins (xyz00-benutzername in unserem Beispiel) ausgeführt, also kann dieses Programm nur die Domains bearbeiten, die von xyz00-benutzername verwaltet werden.<br />
<br />
=== Authentifizierung ===<br />
In der Beispielimplementierung (wie auch seinerzeit bei DynDNS.org) wird das CGI-Programm durch einen .htaccess-Eintrag geschützt, der HTTP-Basic-Authentication vorschreibt. Also wird das Programm eigentlich mit einem URL der form<br />
<br />
<nowiki>https://ddnsaccount:passwort@ddns.example.com/cgi-bin/ddns?hostname=...</nowiki><br />
<br />
aufgerufen.<br />
<br />
=== Verschlüsselung ===<br />
Das CGI-Programm sollte nur in example.com/cgi-ssl/ installiert werden, nicht in example.com/cgi/. Damit ist die Kommunikation zwischen Client und Server durch SSL verschlüsselt.<br />
<br />
== Administration ==<br />
<br />
Der Verwalter des DDNS-Programms trägt berechtigte Benutzer und die ihnen zugeteilten Domainnamen in die Datenbank des Programms ein mit Hilfe eines kleinen Hilfsprogramms. Das ist im vorliegenden Fall ein menügesteuertes Programm für die Befehlszeile, daß die naheliegenden Funktionen anbietet: Account hinzufügen, löschen, sperren, entsperren, Paßwort setzen, ändern; Domainnamen hinzufügen, ändern, entsperren, löschen; Accounts und Domainnamen mit aktuellem Status auflisten. Die Funktionen sind auch über Befehlszeilenargumente verfügbar, also skriptfähig.<br />
<br />
Eine Auflistung des momentanen Inhalts der DDNS-Datenbank durch das Administrationswerkzeug könnte beispielsweise so aussehen:<br />
<br />
xyz00-benutzername@h02:~$ bin/ddnsadmin.pl -Aa<br />
1. papst Mißbrauch: 0; gesperrt: nein<br />
avignon.example.com<br />
zuletzt aktiv am Sun Apr 26 22:24:49 2020<br />
mit IP-Nr. 87.65.43.21; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 0; gesperrt: nein<br />
vatican.beispiel.de<br />
zuletzt aktiv am Sun Apr 26 22:24:49 2020<br />
mit IP-Nr. 87.65.43.21; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 0; gesperrt: nein<br />
2. kaiser Mißbrauch: 4; gesperrt: ja<br />
augsburg.beispiel.de<br />
zuletzt aktiv am Fri Apr 24 16:13:49 2020<br />
mit IP-Nr. 64.82.31.75; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 0; gesperrt: ja<br />
3. luther Mißbrauch: 1; gesperrt: nein<br />
wittenberg.example.com<br />
zuletzt aktiv am Mon Apr 27 10:12:49 2020<br />
mit IP-Nr. 78.56.34.12; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 1; gesperrt: nein<br />
xyz00-benutzername@h02:~$<br />
<br />
Das DDNS-Account &bdquo;kaiser&ldquo; in dieser Auflistung ist wohl auf Grund fehlerhafter Anfragen automatisch gesperrt worden. Der Inhaber wird sich wohl bald melden, um nach Korrektur seiner Client-Konfiguration die Aufhebung der Sperre zu wünschen.<br />
<br />
=== Log ===<br />
Alle Anfragen werden in einer täglich wechselnden Log-Datei protokolliert, entweder schlicht oder ausführlich, je nachdem, ob eine Variable <tt>verbose</tt> wahr ist.<br />
Ein ausführlicher Log-Eintrag sieht so aus:<br />
<br />
Sun Apr 26 20:21:45 2020 ddns aufgerufen von papst<br />
unter 84.185.97.8<br />
URL: <nowiki>https://ddns.example.com/cgi-bin/ddns.cgi?hostname=<br />
avignon.example.com,vatican.beispiel.de&<br />
myip=84.185.97.8</nowiki><br />
Verwende IP 84.185.97.8 (= 1421435144)<br />
DB-Version: 1<br />
Skript und DB exklusiv geöffnet<br />
avignon.example.com: IP: 84.185.97.8; MX: 0; Backup-MX: nein;<br />
Wildcard: nein; Mißbrauch: 0; gesperrt: nein <br />
vatican.beispiel.de: IP: 84.185.97.8; MX: 0; Backup-MX: nein;<br />
Wildcard: nein; Mißbrauch: 0; gesperrt: nein <br />
Betroffene Zonen: example.com, beispiel.de<br />
Temporärdatei example.com_hxNa.new geschrieben<br />
Zonendatei /home/pacs/xyz00/users/benutzername/doms/example.com/<br />
etc/pri.example.com eingestellt<br />
Temporärdatei beispiel.de_6HcO.new geschrieben<br />
Zonendatei /home/pacs/xyz00/users/benutzername/doms/beispiel.de/<br />
etc/pri.beispiel.de eingestellt<br />
Abgeschlossen: Fertig<br />
<br />
Wenn <tt>verbose</tt> auf falsch gesetzt ist, sind die Log-Einträge einzeilig.</div>Apc00-tonyhttps://wiki.hostsharing.net/index.php?title=Benutzer:Apc00-tony/Dynamisches_DNS&diff=5192Benutzer:Apc00-tony/Dynamisches DNS2020-04-27T08:56:15Z<p>Apc00-tony: /* Administration */</p>
<hr />
<div>((Provisorischer Vorspann: Auf Grund einer Mailing-Listen-Diskussion habe ich angefangen, Dynamisches DNS über einen CGI-Skript bei Hostsharing zu realisieren. Meine Lösung habe ich dann vorgestellt; sie wurde für nicht ausreichend selbsterklärend befunden und fand wenig Akzeptanz. Hier also der Versuch, die Sache zu dokumentieren.))<br />
<br />
Mit der regelmäßigen Aufnahme von benutzerspezifischen Zonefiles in seiner DNS-Konfiguration bietet Hostsharing alles, was man braucht, um &bdquo;dynamisches DNS&ldquo; in Eigenregie zu realisieren.<br />
<br />
Das heißt, wenn ich mindestens eine Domain bei Hostsharing verwalte, und mindestens eine Einwahlverbindung (oder DSL-Verbindung) ins Internet mit wechselnder IP-Adresse über irgendeinen ISP für meinen Arbeitsplatzrechner zu Hause betreibe, dann kann ich dem Arbeitsplatzrechner über die DNS-Server von Hostsharing einen vollqualifizieren Domainnamen zuweisen, der der jeweiligen IP-Adresse meiner Einwahlleitung zugeordnet ist.<br />
<br />
<pre><br />
<br />
(ASCII-Art-Diagramm der beschriebenen Konstellation)<br />
<br />
</pre><br />
<br />
Im Folgenden wird eine real existierende Implementierung von Dynamischem DNS (&bdquo;DDNS&ldquo;) beschrieben. Die verschiedenen Elemente könnten durchaus anders realisiert werden; die beschriebene Implementierung könnte durchaus verbessert werden. Sie dient hier der Illustration.<br />
<br />
In der folgenden Beschreibung werden diese Beispielwerte benutzt:<br />
* Ein Hostsharing-Mitglied hat ein Account als Paket-Admin mit Kennung xyz00.<br />
* Im Paket xyz00 gibt es einen Domain-Admin namens xyz00-benutzername.<br />
* Dieser Domain-Admin verwaltet bei Hostsharing die Domains example.com und beispiel.de.<br />
* Ein Benutzer hat zu Hause (oder im Büro) einen Arbeitsplatzrechner hinter der marktüblichen DSL-Leitung, die von seinem ISP bereitgestellt wird.<br />
* Dieser Arbeitsplatzrechner (oder der Router, der seine Internetverbindung steuert) bekommt vom ISP immer wechselnde IP-Adressen zugewiesen.<br />
* Dennoch möchte der Benutzer seinen Arbeitsplatzrechner aus dem Internet unter dem Hostnamen einwahl.example.com ansprechen können.<br />
<br />
Dazu kann ein System wie Hostsharing, das authoritative DNS-Informationen für viele Domains bereitstellt, auch veränderliche DNS-Information über dynamisch verbundene Rechner verwalten &ndash; sofern das ressourcenschonend gemacht werden kann ohne andere Funktionen zu stören.<br />
<br />
== Aufgaben des Servers ==<br />
<br />
Um einem Rechner mit wechselnder IP-Adresse einen DDNS-Eintrag zu bieten, muß der Hostsharing-Server folgendes leisten (in ungefährer Reihenfolge der Ereignisse):<br />
<br />
# Eine Anfrage entgegennehmen, beispielsweise über HTTPS, von einem entfernten Rechner, der einen DNS-Eintrag für seine momentane IP-Adresse wünscht. <br />
# Prüfen, ob die Anfrage einen berechtigten DDNS-Dienst-Usernamen mit zugehörigem Paßwort enthält.<br />
# Prüfen, ob die Anfrage einen gültigen Domainnamen betrifft, den der Server bieten darf.<br />
# Prüfen, ob die Domain example.com demselben Benutzer gehört, unter dessen Namen der Dynamisches-DNS-Server läuft.<br />
# Eine gültige [[Zonefile]] mit &ndash; neben dem bisherigen Inhalt &ndash; einem A-Eintrag für einwahl.example.com in /home/pacs/xyz00/users/benutzername/doms/example.com/pri.example.com schreiben.<br />
# Dem Client eine Bestätigung oder ggf. eine Fehlermeldung als Antwort senden.<br />
# In irgendeiner Datenbank den momentan eingestellter Status all seiner DDNS-Einträge speichern.<br />
# In einer Logdatei protokollieren, daß obiges getan wurde, oder ggf. welche Fehler traten auf.<br />
<br />
== Aufgaben des Clients ==<br />
Bevor ich anfange, meinen Arbeitsplatzrechner so zu konfigurieren, daß er bei welchem Server auch immer einen DDNS-Eintrag anfordert, muß ich mich als verantwortlicher Benutzer dieses Rechners und der dazugehörigen Internetverbindung &ndash; das heißt, als Mensch &ndash; mit dem Betreiber des dynamisches-DNS-Servers vereinbaren, daß ich das darf und welchen Eintrag ich bekommen kann. Im Folgenden wird vorausgesetzt, daß solche Vereinbarungen getroffen und die Parameter geklärt wurden.<br />
<br />
Der DDNS-Client muß aus Server-Sicht nur wenig leisten:<br />
<br />
# Eine Anfrage senden, beispielsweise über HTTPS, an einen entfernten Rechner, der einen Eintrag ins DNS für die momentane IP-Adresse des Clients vornehmen kann.<br />Diese Anfrage muß einem festgelegten Format entsprechen und muß gültige Werte für die Authorisation des Clients, den gewünschten Domainnamen, und eventuell andere Parameter enthalten.<br />
# Eine Antwort des Servers entgegennehmen und als Erfolgs- oder Fehlermeldung auswerten.<br />
# Von überflüssigen Anfragen absehen: das heißt bei Erfolg, nicht wiederholt den gleichen Eintrag erneut wünschen; bei Fehlern, nicht die gleiche fehlerhafte Anfrage erneut schicken.<br />
<br />
== Kommunikation zwischen Client und Server ==<br />
<br />
Ein einziges Nachrichtenpaar von Anfrage und Antwort genügt, um einen DDNS-Eintrag einzurichten: Der Client teilt die IP-Adresse und den Domainnamen mit, die in einem DNS-Eintrag verbunden werden sollen; der Server bestätigt den Auftrag.<br />
<br />
In der Beispielimplementierung erfolgt die Kommunikation über HTTP, und die Anfrage des Clients könnte so aussehen:<br />
<br />
GET /cgi-bin/ddns?hostname=einwahl.example.com&myip=87.65.43.21 HTTP/1.1<br />
Host: ddns.beispiel.de<br />
User-Agent: Fritz!Box DDNS/1.0.1<br />
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==<br />
<br />
Bei Erhalt dieser Anfrage ruft Apache das CGI-Programm .../doms/ddns.beispiel.de/cgi-ssl/ddns auf. Das Fragezeichen trennt den Programmnamen von einem "Query-String", in dem zwei Metavariablen definiert und übergeben werden. Die erste Metavariable, hostname, hat den Wert "einwahl.example.com"; die zweite, myip, hat den Wert "87.65.43.21".<br />
<br />
Das Server-Programm, hier ''ddns'', prüft diese Informationen auf Form und Berechtigung, und schreibt gegebenenfalls einen entsprechenden Eintrag in einer Zonefile. Es schreibt auch verschiedene Informationen in die Standardausgabe. Wenn es die Standardausgabe geschlossen wird &ndash; also spätestens bei Programmende &ndash; schickt Apache diese Informationen als Antwort an den anfragenden Rechner zurück.<br />
<br />
Im Falle unserer Beispielimplementierung sieht die Antwort bei Erfolg so aus: <br />
<br />
HTTP/1.1 200 OK<br />
Date: Wed, 22 Apr 2020 08:35:15 GMT<br />
Server: Apache<br />
Content-Length: 17<br />
Content-Type: text/plain; charset=ISO-8859-1<br />
<br />
good 87.65.43.21<br />
<br />
=== Das DDNS-Protokoll von DynDNS.org ===<br />
<br />
In den 90er Jahren, bevor das Internet so durchgehend vergeschäftlicht wurde, boten einige Organisationen kostenlose DDNS-Dienste an. Ein sehr beliebtes Angebot war das von DynDNS.org. Das DDNS-Protokoll von diesem Dienst wurde sogar in Einwahl-Routern einprogrammiert und der Dienst wurde von ISPs und Router-Herstellern als Leistungsmerkmal beworben.<br />
<br />
DynDNS.org gehört inzwischen Oracle und bietet keine kostenlose Dienste mehr. Dennoch wird das DDNS-Protokoll von DynDNS.org in der vorliegenden Beispielimplementierung übernommen in der Hoffnung, daß die Kompatibilität mit einigen gängigen Einwahl-Routern von Vorteil sein kann. Es gibt noch eine kurze Online-Dokumentation der [https://help.dyn.com/remote-access-api/perform-update/ Anfrage] und [https://help.dyn.com/remote-access-api/perform-update/ Antwortnachrichten].<br />
<br />
Das gesammte Protokoll sieht einen einzigen Nachrichtenaustausch aus Anfrage und Antwort vor. Die Anfrage kann mehrere Argumente enthalten; die Antwort kann verschiedene Code-Wörtern enthalten. Übrigens können in einer einzigen Anfrage mehrere DNS-Einträge gewünscht werden. In diesem Fall kann die Antwort mehrzeilig ausfallen.<br />
<br />
Das Verhalten von Server und Client bei künftigen Kommunikationsvorgängen wird unter Umständen von vorangegangenen Kommunikationsergebnissen beeinflußt: nach wiederholten fehlerhaften oder redundanten Anfragen kann der Server weitere Anfragen des Benutzers verweigern; nach wiederholten Fehlermeldungen sollte ein Client aufhören, immer dieselbe Anfrage zu schicken. Und für den Fall, daß mehrere Clients dynamische DNS-Einträge in derselben Domain example.com bestellen, muß der Server den Stand aller Client-Einträge intern speichern, damit er nicht mit einer neuen Zonefile einen früher erstellten Eintrag löscht. Zu diesen Fragen siehe den Abschnitt '''[[#Sukzessive_Kommunikationsabläufe]]''' nach der Beschreibung von Anfragen und Antworten unten.<br />
<br />
====Anfrage====<br />
<br />
Die Anfrage in Form eines URL übergibt dem DDNS-Programm in einem 'Query-String' einige Metavariablen. Das heißt, in einem URL der Form<br />
<br />
<nowiki>https://benutzername:passwort@ddns.beisiel.de/cgi-bin/ddns?hostname=einwahl.example.com&myip=87.65.43.21</nowiki><br />
<br />
signalisert das Fragezeichen, daß ein Query-String folgt. In einem solchen Query-String können in der Beispielimplementierung folgende Metavariablen definiert werden:<br />
<br />
{| class="wikitable"<br />
|- class="hintergrundfarbe5"<br />
! Variable !! Beispiel !! Bemerkungen<br />
|-<br />
| hostname || <tt>hostname=einwahl.example.com</tt><br /><div style="font-size:smaller;"><tt>hostname=eins.example.com,zwei.example.com[,...]</tt></div> ||<br />
Muß ein vollständig qualifizierter Domain-Name ("FQDN") sein; <tt>example.com</tt> muß eine vom Besitzer des DDNS-Programms verwaltete Domain sein. Genaugenommen kann der Wert eine durch Kommata gegliederte Liste mehrerer gültiger Domainnamen sein, falls mehrere Einträge mit derselben IP-Adresse gewünscht werden.<br />
|-<br />
| myip || <tt>myip=87.65.43.21</tt>||<br />
Kann entfallen; kann vom Server ignoriert werden. Maßgeblich ist dann die IP-Adresse des Absenders, wie sie vom Web-Server mitgeteilt wird.<br />
|-<br />
| mx || <tt>mx=87.65.43.21</tt><br /><tt>mx=NOCHG</tt><br /> ||<br />
Neben dem A-Eintrag möchte der Client auch einen MX-Eintrag. Der Wert <tt>NOCHG</tt> (für &bdquo;no change&ldquo;) bedeutet, der bestehende MX-Eintrag (oder seine Abwesenheit) soll nicht geändert werden. <br />
|-<br />
| backmx || <tt>backmx=YES</tt><br /><tt>backmx=NOCHG</tt><br /><tt>backmx=NO</tt> ||<br />
Falls <tt>YES</tt>, wird ein zweiter MX-Eintrag erzeugt, der <tt>einwahl.example.com</tt> als Mail-Server für <tt>einwahl.example.com</tt> nennt. Dieser Eintrag hat eine niedrigere Präferenzzahl (also eine höhere Priorität) als der mit <tt>mx</tt> angeforderten Eintrag.<br />
|-<br />
| wildcard || <tt>wildcard=ON</tt><br /><tt>wildcard=NOCHG</tt><br /><tt>wildcard=OFF</tt> ||<br />
Neben dem A-Eintrag für den Domainnamen <tt>einwahl.example.com</tt> wünscht der Client auch einen Eintrag für beliebige Subdomains, also <tt>*.einwahl.example.com</tt>, mit der gleichen IP-Adresse.<br />
|-<br />
| offline ||<tt>offline=YES</tt><br /><tt>offline=NOCHG</tt>||<br />
Falls <tt>YES</tt>, wird ein DNS-Eintrag für <tt>einwahl.example.com</tt> aus der Zonefile getilgt. Gegebenenfalls wird der Hostname dann auf Grund eines parallelen Wildcard-Eintrags für <tt>*.example.com</tt> einer anderen IP-Adresse zugeordnet werden.<br />
|}<br />
<br />
<!-- IPv6? --><br />
<br />
Alle Parameter bis auf hostname können entfallen. Bei nichtdokumentierten Argumenten ist das Verhalten undefiniert&trade;.<br />
<br />
====Antwort====<br />
<br />
Die Antwort auf eine erfolgreiche HTTP-Anfrage besteht im häufigsten Fall aus einigen Header-Zeilen, gefolgt vom Inhalt der gewünschten Text- oder andere Datei. Ein Status-Code in der ersten Header-Zeile gibt an, ob die Anfrage bedient werden kann oder kreist andernfalls den Grund für die Enttäuschung ein.<br />
<br />
Die vorliegende Beispielimplementierung von DDNS schickt einen der üblichen HTTP-Status-Codes "200 OK" oder "500 Internal Server Error", gefolgt von einer kurzen Textnachricht nach dem HTTP-Header. Bei diesem Programm ist &ndash; laut Gebrauchshinweise von DynDNS.org &ndash; ''nicht'' der Status-Code im Header, sondern der Inhalt der Nachricht die definierte, maßgebliche Ergebnismeldung des Programms.<br />
<br />
{| class="wikitable"<br />
|- class="hintergrundfarbe5"<br />
! Meldung !! Bedeutung !! Bemerkungen<br />
|-<br />
| <tt>good&nbsp;&lt;IP&nbsp;number&gt;</tt> ||<br />
Der gewünschte DNS-Eintrag wurde erfolgreich in einer Zonefile eingetragen. <br />
|| Es kann natürlich noch einige Minuten dauern, bis die Zonefile vom Hostsharing-Roboter abgelesen wird und der Inhalt in die BIND-Konfiguration übernommen.<br />
|-<br />
| <tt>nochg&nbsp;&lt;IP&nbsp;number&gt;</tt> ||<br />
Der gewünschte DNS-Eintrag war bereits vorhanden. <br />
|| Der Server selbst macht keine DNS-Abfrage, um das zu vermitteln: die &bdquo;no change&ldquo;-Antwort besagt nur, daß eine Anfrage für diesen Eintrag bereits mit Erfolg quittiert wurde.<br />
|-<br />
| <tt>notfqdn</tt> ||<br />
Fehlschlag: der gewünschte Domainname ist nicht gültig, oder es wurde keiner angegeben.<br />
|| ...<br />
|-<br />
| <tt>nohost</tt> ||<br />
Fehlschlag: der gewünschte Domainname ist gehört nicht zu denen, die für diesen Benutzer des DDNS-Dienstes konfiguriert sind.<br />
|| Siehe den Abschnitt '''Administration''' weiter unten.<br />
|-<br />
| <tt>abuse</tt> ||<br />
Fehlschlag: der gewünschte Domainname ist wegen vorangeganger Fehlschläge oder überflüssiger Aufrufe gesperrt.<br />
|| Siehe den Abschnitt '''Sukzessive Kommunikationsvorgänge''' unten.<br />
|-<br />
| <tt>911</tt> ||<br />
Fehlschlag: Das Server-Programm hat einen internen Fehler festgestellt.<br />
|| Das Problem liegt nicht in der Anfrage an sich.<br />
|}<br />
<br />
Man kann sich durchaus eine sinnreichere Kommunikation zwischen Client und Server vorstellen, doch das hier beschriebene Protokoll ist eben von DynDNS.org verwendet worden und wird in gängigen Routern implementiert, also wird es in der vorliegenden DDNS-Implementierung nachgebildet.<br />
<br />
=== Sukzessive Kommunikationsabläufe ===<br />
Der Server muß sich zwischen einzelnen Aufrufen einiges merken, um Ressourcen zu schonen und um zu verhindern, daß einmal vergebene DDNS-Einträge von neuen Anfragen, die dieselbe übergeordnete Domain betreffen, durch Überschreiben verlorengehen.<br />
<br />
==== Mißbrauch und Benutzersperrung ====<br />
Zur Schonung von Ressourcen muß sich die Implementierung weigern, sich mit zuvielen fehlerhaften oder auch nur überflüssigen Anfragen zu beschäftigen. Dazu führt eine Strichliste über solche Anfragen jedes Clients und sperrt nach einer bestimmten Anzahl solcher Anfragen den Benutzernamen oder einzelne Domainnamen gegen die weitere Nutzung des Dienstes.<br />
<br />
Mißbrauchspunkte gegen einen einzelnen Domainnamen gibt es für:<br />
* eine Anfrage, die keinen neuen DNS-Eintrag (und keine Änderung oder Löschung eines Eintrags) erfordert, sondern bestehende Merkmale nur wiederholt<br />
<br />
Mißbrauchspunkte gegen einen Benutzernamen gibt es für:<br />
* die Angabe eines Domainnamens, der in der Dienstkonfiguration dem anfragenden Benutzernamen nicht zugeordnet ist<br />
* die Angabe eines Domainnamen in einer Domain, die nicht demselben Hostsharing-Domain-Admin gehört, der den DDNS-Dienst anbietet<br />
* die Angabe eines Domainnamens, der in der Dienstkonfiguration bereits wegen mißbräuchlicher Anfragen gesperrt ist (siehe oben)<br />
<br />
Um eine Sperrung aufzuheben, wird in der Regel eine Handlung durch den Administrator erforderlich sein.<br />
<br />
==== Mehrere dynamische Subdomains in derselben Domain ====<br />
Sobald zwei verschiedene DDNS-Einträge in derselben Domain verlangt werden &ndash; beispielsweise home.example.com und office.example.com &ndash; wird es notwendig, bei jeder neuen Zonefile für example.com eventuell frühere Einträge zu konservieren. Der Rechner zu Hause weiß beim Bestellen seines DDNS-Eintrags nichts vom Rechner im Büro und umgekehrt. Der Server muß in irgendeiner Form über bereits vergebene Einträge Buch führen und bei einer neuen Anfrage, die example.com betrifft, alle bereits aktiven DDNS-Einträge für example.com mit in die neue Zonefile aufnehmen &ndash auch wenn sie auf Anfragen verschiedener Benutzer zurückgehen.<br />
<br />
==== Datenbank ====<br />
In der Beispielimplementierung werden diese Informationen in einer SQLite-Datenbank gespeichert.<br />
<br />
== Sicherheit ==<br />
=== Rechte ===<br />
Die '''Benutzerrechte''' werden durch das Hostsharing-System kontrolliert. Sowohl das CGI-Programm als auch das [[#Administration|Administrationswerkzeug]] werden mit den Rechten des Domain-Admins (xyz00-benutzername in unserem Beispiel) ausgeführt, also kann dieses Programm nur die Domains bearbeiten, die von xyz00-benutzername verwaltet werden.<br />
<br />
=== Authentifizierung ===<br />
In der Beispielimplementierung (wie auch seinerzeit bei DynDNS.org) wird das CGI-Programm durch einen .htaccess-Eintrag geschützt, der HTTP-Basic-Authentication vorschreibt. Also wird das Programm eigentlich mit einem URL der form<br />
<br />
<nowiki>https://ddnsaccount:passwort@ddns.example.com/cgi-bin/ddns?hostname=...</nowiki><br />
<br />
aufgerufen.<br />
<br />
=== Verschlüsselung ===<br />
Das CGI-Programm sollte nur in example.com/cgi-ssl/ installiert werden, nicht in example.com/cgi/. Damit ist die Kommunikation zwischen Client und Server durch SSL verschlüsselt.<br />
<br />
== Administration ==<br />
<br />
Der Verwalter des DDNS-Programms trägt berechtigte Benutzer und die ihnen zugeteilten Domainnamen in die Datenbank des Programms ein mit Hilfe eines kleinen Hilfsprogramms. Das ist im vorliegenden Fall ein menügesteuertes Programm für die Befehlszeile, daß die naheliegenden Funktionen anbietet: Account hinzufügen, löschen, sperren, entsperren, Paßwort setzen, ändern; Domainnamen hinzufügen, ändern, entsperren, löschen; Accounts und Domainnamen mit aktuellem Status auflisten. Die Funktionen sind auch über Befehlszeilenargumente verfügbar, also skriptfähig.<br />
<br />
Eine Auflistung des momentanen Inhalts der DDNS-Datenbank durch das Administrationswerkzeug könnte beispielsweise so aussehen:<br />
<br />
xyz00-benutzername@h02:~$ bin/ddnsadmin.pl -Aa<br />
1. papst Mißbrauch: 0; gesperrt: nein<br />
avignon.example.com<br />
zuletzt aktiv am Sun Apr 26 22:24:49 2020<br />
mit IP-Nr. 87.65.43.21; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 0; gesperrt: nein<br />
vatican.beispiel.de<br />
zuletzt aktiv am Sun Apr 26 22:24:49 2020<br />
mit IP-Nr. 87.65.43.21; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 0; gesperrt: nein<br />
2. kaiser Mißbrauch: 4; gesperrt: ja<br />
augsburg.beispiel.de<br />
zuletzt aktiv am Sun Apr 27 10:13:49 2020<br />
mit IP-Nr. 64.82.31.75; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 0; gesperrt: ja<br />
3. luther Mißbrauch: 1; gesperrt: nein<br />
wittenberg.example.com<br />
zuletzt aktiv am Sun Apr 26 18:12:49 2020<br />
mit IP-Nr. 78.56.34.12; MX: 0; Backup-MX: nein;<br />
Subdomains: nein; Mißbrauch: 1; gesperrt: nein<br />
xyz00-benutzername@h02:~$<br />
<br />
Das DDNS-Account &bdquo;kaiser&ldquo; in dieser Auflistung ist wohl auf Grund fehlerhafter Anfragen automatisch gesperrt worden. Der Inhaber wird sich wohl bald melden, um nach Korrektur seiner Client-Konfiguration die Aufhebung der Sperre zu wünschen.<br />
<br />
=== Log ===<br />
Alle Anfragen werden in einer täglich wechselnden Log-Datei protokolliert, entweder schlicht oder ausführlich, je nachdem, ob eine Variable <tt>verbose</tt> wahr ist.<br />
Ein ausführlicher Log-Eintrag sieht so aus:<br />
<br />
Sun Apr 26 20:21:45 2020 ddns aufgerufen von papst<br />
unter 84.185.97.8<br />
URL: <nowiki>https://ddns.example.com/cgi-bin/ddns.cgi?hostname=<br />
avignon.example.com,vatican.beispiel.de&<br />
myip=84.185.97.8</nowiki><br />
Verwende IP 84.185.97.8 (= 1421435144)<br />
DB-Version: 1<br />
Skript und DB exklusiv geöffnet<br />
avignon.example.com: IP: 84.185.97.8; MX: 0; Backup-MX: nein;<br />
Wildcard: nein; Mißbrauch: 0; gesperrt: nein <br />
vatican.beispiel.de: IP: 84.185.97.8; MX: 0; Backup-MX: nein;<br />
Wildcard: nein; Mißbrauch: 0; gesperrt: nein <br />
Betroffene Zonen: example.com, beispiel.de<br />
Temporärdatei example.com_hxNa.new geschrieben<br />
Zonendatei /home/pacs/xyz00/users/benutzername/doms/example.com/<br />
etc/pri.example.com eingestellt<br />
Temporärdatei beispiel.de_6HcO.new geschrieben<br />
Zonendatei /home/pacs/xyz00/users/benutzername/doms/beispiel.de/<br />
etc/pri.beispiel.de eingestellt<br />
Abgeschlossen: Fertig<br />
<br />
Wenn <tt>verbose</tt> auf falsch gesetzt ist, sind die Log-Einträge einzeilig.</div>Apc00-tonyhttps://wiki.hostsharing.net/index.php?title=Benutzer:Apc00-tony/Dynamisches_DNS&diff=5191Benutzer:Apc00-tony/Dynamisches DNS2020-04-27T08:25:33Z<p>Apc00-tony: /* Authentifizierung */</p>
<hr />
<div>((Provisorischer Vorspann: Auf Grund einer Mailing-Listen-Diskussion habe ich angefangen, Dynamisches DNS über einen CGI-Skript bei Hostsharing zu realisieren. Meine Lösung habe ich dann vorgestellt; sie wurde für nicht ausreichend selbsterklärend befunden und fand wenig Akzeptanz. Hier also der Versuch, die Sache zu dokumentieren.))<br />
<br />
Mit der regelmäßigen Aufnahme von benutzerspezifischen Zonefiles in seiner DNS-Konfiguration bietet Hostsharing alles, was man braucht, um &bdquo;dynamisches DNS&ldquo; in Eigenregie zu realisieren.<br />
<br />
Das heißt, wenn ich mindestens eine Domain bei Hostsharing verwalte, und mindestens eine Einwahlverbindung (oder DSL-Verbindung) ins Internet mit wechselnder IP-Adresse über irgendeinen ISP für meinen Arbeitsplatzrechner zu Hause betreibe, dann kann ich dem Arbeitsplatzrechner über die DNS-Server von Hostsharing einen vollqualifizieren Domainnamen zuweisen, der der jeweiligen IP-Adresse meiner Einwahlleitung zugeordnet ist.<br />
<br />
<pre><br />
<br />
(ASCII-Art-Diagramm der beschriebenen Konstellation)<br />
<br />
</pre><br />
<br />
Im Folgenden wird eine real existierende Implementierung von Dynamischem DNS (&bdquo;DDNS&ldquo;) beschrieben. Die verschiedenen Elemente könnten durchaus anders realisiert werden; die beschriebene Implementierung könnte durchaus verbessert werden. Sie dient hier der Illustration.<br />
<br />
In der folgenden Beschreibung werden diese Beispielwerte benutzt:<br />
* Ein Hostsharing-Mitglied hat ein Account als Paket-Admin mit Kennung xyz00.<br />
* Im Paket xyz00 gibt es einen Domain-Admin namens xyz00-benutzername.<br />
* Dieser Domain-Admin verwaltet bei Hostsharing die Domains example.com und beispiel.de.<br />
* Ein Benutzer hat zu Hause (oder im Büro) einen Arbeitsplatzrechner hinter der marktüblichen DSL-Leitung, die von seinem ISP bereitgestellt wird.<br />
* Dieser Arbeitsplatzrechner (oder der Router, der seine Internetverbindung steuert) bekommt vom ISP immer wechselnde IP-Adressen zugewiesen.<br />
* Dennoch möchte der Benutzer seinen Arbeitsplatzrechner aus dem Internet unter dem Hostnamen einwahl.example.com ansprechen können.<br />
<br />
Dazu kann ein System wie Hostsharing, das authoritative DNS-Informationen für viele Domains bereitstellt, auch veränderliche DNS-Information über dynamisch verbundene Rechner verwalten &ndash; sofern das ressourcenschonend gemacht werden kann ohne andere Funktionen zu stören.<br />
<br />
== Aufgaben des Servers ==<br />
<br />
Um einem Rechner mit wechselnder IP-Adresse einen DDNS-Eintrag zu bieten, muß der Hostsharing-Server folgendes leisten (in ungefährer Reihenfolge der Ereignisse):<br />
<br />
# Eine Anfrage entgegennehmen, beispielsweise über HTTPS, von einem entfernten Rechner, der einen DNS-Eintrag für seine momentane IP-Adresse wünscht. <br />
# Prüfen, ob die Anfrage einen berechtigten DDNS-Dienst-Usernamen mit zugehörigem Paßwort enthält.<br />
# Prüfen, ob die Anfrage einen gültigen Domainnamen betrifft, den der Server bieten darf.<br />
# Prüfen, ob die Domain example.com demselben Benutzer gehört, unter dessen Namen der Dynamisches-DNS-Server läuft.<br />
# Eine gültige [[Zonefile]] mit &ndash; neben dem bisherigen Inhalt &ndash; einem A-Eintrag für einwahl.example.com in /home/pacs/xyz00/users/benutzername/doms/example.com/pri.example.com schreiben.<br />
# Dem Client eine Bestätigung oder ggf. eine Fehlermeldung als Antwort senden.<br />
# In irgendeiner Datenbank den momentan eingestellter Status all seiner DDNS-Einträge speichern.<br />
# In einer Logdatei protokollieren, daß obiges getan wurde, oder ggf. welche Fehler traten auf.<br />
<br />
== Aufgaben des Clients ==<br />
Bevor ich anfange, meinen Arbeitsplatzrechner so zu konfigurieren, daß er bei welchem Server auch immer einen DDNS-Eintrag anfordert, muß ich mich als verantwortlicher Benutzer dieses Rechners und der dazugehörigen Internetverbindung &ndash; das heißt, als Mensch &ndash; mit dem Betreiber des dynamisches-DNS-Servers vereinbaren, daß ich das darf und welchen Eintrag ich bekommen kann. Im Folgenden wird vorausgesetzt, daß solche Vereinbarungen getroffen und die Parameter geklärt wurden.<br />
<br />
Der DDNS-Client muß aus Server-Sicht nur wenig leisten:<br />
<br />
# Eine Anfrage senden, beispielsweise über HTTPS, an einen entfernten Rechner, der einen Eintrag ins DNS für die momentane IP-Adresse des Clients vornehmen kann.<br />Diese Anfrage muß einem festgelegten Format entsprechen und muß gültige Werte für die Authorisation des Clients, den gewünschten Domainnamen, und eventuell andere Parameter enthalten.<br />
# Eine Antwort des Servers entgegennehmen und als Erfolgs- oder Fehlermeldung auswerten.<br />
# Von überflüssigen Anfragen absehen: das heißt bei Erfolg, nicht wiederholt den gleichen Eintrag erneut wünschen; bei Fehlern, nicht die gleiche fehlerhafte Anfrage erneut schicken.<br />
<br />
== Kommunikation zwischen Client und Server ==<br />
<br />
Ein einziges Nachrichtenpaar von Anfrage und Antwort genügt, um einen DDNS-Eintrag einzurichten: Der Client teilt die IP-Adresse und den Domainnamen mit, die in einem DNS-Eintrag verbunden werden sollen; der Server bestätigt den Auftrag.<br />
<br />
In der Beispielimplementierung erfolgt die Kommunikation über HTTP, und die Anfrage des Clients könnte so aussehen:<br />
<br />
GET /cgi-bin/ddns?hostname=einwahl.example.com&myip=87.65.43.21 HTTP/1.1<br />
Host: ddns.beispiel.de<br />
User-Agent: Fritz!Box DDNS/1.0.1<br />
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==<br />
<br />
Bei Erhalt dieser Anfrage ruft Apache das CGI-Programm .../doms/ddns.beispiel.de/cgi-ssl/ddns auf. Das Fragezeichen trennt den Programmnamen von einem "Query-String", in dem zwei Metavariablen definiert und übergeben werden. Die erste Metavariable, hostname, hat den Wert "einwahl.example.com"; die zweite, myip, hat den Wert "87.65.43.21".<br />
<br />
Das Server-Programm, hier ''ddns'', prüft diese Informationen auf Form und Berechtigung, und schreibt gegebenenfalls einen entsprechenden Eintrag in einer Zonefile. Es schreibt auch verschiedene Informationen in die Standardausgabe. Wenn es die Standardausgabe geschlossen wird &ndash; also spätestens bei Programmende &ndash; schickt Apache diese Informationen als Antwort an den anfragenden Rechner zurück.<br />
<br />
Im Falle unserer Beispielimplementierung sieht die Antwort bei Erfolg so aus: <br />
<br />
HTTP/1.1 200 OK<br />
Date: Wed, 22 Apr 2020 08:35:15 GMT<br />
Server: Apache<br />
Content-Length: 17<br />
Content-Type: text/plain; charset=ISO-8859-1<br />
<br />
good 87.65.43.21<br />
<br />
=== Das DDNS-Protokoll von DynDNS.org ===<br />
<br />
In den 90er Jahren, bevor das Internet so durchgehend vergeschäftlicht wurde, boten einige Organisationen kostenlose DDNS-Dienste an. Ein sehr beliebtes Angebot war das von DynDNS.org. Das DDNS-Protokoll von diesem Dienst wurde sogar in Einwahl-Routern einprogrammiert und der Dienst wurde von ISPs und Router-Herstellern als Leistungsmerkmal beworben.<br />
<br />
DynDNS.org gehört inzwischen Oracle und bietet keine kostenlose Dienste mehr. Dennoch wird das DDNS-Protokoll von DynDNS.org in der vorliegenden Beispielimplementierung übernommen in der Hoffnung, daß die Kompatibilität mit einigen gängigen Einwahl-Routern von Vorteil sein kann. Es gibt noch eine kurze Online-Dokumentation der [https://help.dyn.com/remote-access-api/perform-update/ Anfrage] und [https://help.dyn.com/remote-access-api/perform-update/ Antwortnachrichten].<br />
<br />
Das gesammte Protokoll sieht einen einzigen Nachrichtenaustausch aus Anfrage und Antwort vor. Die Anfrage kann mehrere Argumente enthalten; die Antwort kann verschiedene Code-Wörtern enthalten. Übrigens können in einer einzigen Anfrage mehrere DNS-Einträge gewünscht werden. In diesem Fall kann die Antwort mehrzeilig ausfallen.<br />
<br />
Das Verhalten von Server und Client bei künftigen Kommunikationsvorgängen wird unter Umständen von vorangegangenen Kommunikationsergebnissen beeinflußt: nach wiederholten fehlerhaften oder redundanten Anfragen kann der Server weitere Anfragen des Benutzers verweigern; nach wiederholten Fehlermeldungen sollte ein Client aufhören, immer dieselbe Anfrage zu schicken. Und für den Fall, daß mehrere Clients dynamische DNS-Einträge in derselben Domain example.com bestellen, muß der Server den Stand aller Client-Einträge intern speichern, damit er nicht mit einer neuen Zonefile einen früher erstellten Eintrag löscht. Zu diesen Fragen siehe den Abschnitt '''[[#Sukzessive_Kommunikationsabläufe]]''' nach der Beschreibung von Anfragen und Antworten unten.<br />
<br />
====Anfrage====<br />
<br />
Die Anfrage in Form eines URL übergibt dem DDNS-Programm in einem 'Query-String' einige Metavariablen. Das heißt, in einem URL der Form<br />
<br />
<nowiki>https://benutzername:passwort@ddns.beisiel.de/cgi-bin/ddns?hostname=einwahl.example.com&myip=87.65.43.21</nowiki><br />
<br />
signalisert das Fragezeichen, daß ein Query-String folgt. In einem solchen Query-String können in der Beispielimplementierung folgende Metavariablen definiert werden:<br />
<br />
{| class="wikitable"<br />
|- class="hintergrundfarbe5"<br />
! Variable !! Beispiel !! Bemerkungen<br />
|-<br />
| hostname || <tt>hostname=einwahl.example.com</tt><br /><div style="font-size:smaller;"><tt>hostname=eins.example.com,zwei.example.com[,...]</tt></div> ||<br />
Muß ein vollständig qualifizierter Domain-Name ("FQDN") sein; <tt>example.com</tt> muß eine vom Besitzer des DDNS-Programms verwaltete Domain sein. Genaugenommen kann der Wert eine durch Kommata gegliederte Liste mehrerer gültiger Domainnamen sein, falls mehrere Einträge mit derselben IP-Adresse gewünscht werden.<br />
|-<br />
| myip || <tt>myip=87.65.43.21</tt>||<br />
Kann entfallen; kann vom Server ignoriert werden. Maßgeblich ist dann die IP-Adresse des Absenders, wie sie vom Web-Server mitgeteilt wird.<br />
|-<br />
| mx || <tt>mx=87.65.43.21</tt><br /><tt>mx=NOCHG</tt><br /> ||<br />
Neben dem A-Eintrag möchte der Client auch einen MX-Eintrag. Der Wert <tt>NOCHG</tt> (für &bdquo;no change&ldquo;) bedeutet, der bestehende MX-Eintrag (oder seine Abwesenheit) soll nicht geändert werden. <br />
|-<br />
| backmx || <tt>backmx=YES</tt><br /><tt>backmx=NOCHG</tt><br /><tt>backmx=NO</tt> ||<br />
Falls <tt>YES</tt>, wird ein zweiter MX-Eintrag erzeugt, der <tt>einwahl.example.com</tt> als Mail-Server für <tt>einwahl.example.com</tt> nennt. Dieser Eintrag hat eine niedrigere Präferenzzahl (also eine höhere Priorität) als der mit <tt>mx</tt> angeforderten Eintrag.<br />
|-<br />
| wildcard || <tt>wildcard=ON</tt><br /><tt>wildcard=NOCHG</tt><br /><tt>wildcard=OFF</tt> ||<br />
Neben dem A-Eintrag für den Domainnamen <tt>einwahl.example.com</tt> wünscht der Client auch einen Eintrag für beliebige Subdomains, also <tt>*.einwahl.example.com</tt>, mit der gleichen IP-Adresse.<br />
|-<br />
| offline ||<tt>offline=YES</tt><br /><tt>offline=NOCHG</tt>||<br />
Falls <tt>YES</tt>, wird ein DNS-Eintrag für <tt>einwahl.example.com</tt> aus der Zonefile getilgt. Gegebenenfalls wird der Hostname dann auf Grund eines parallelen Wildcard-Eintrags für <tt>*.example.com</tt> einer anderen IP-Adresse zugeordnet werden.<br />
|}<br />
<br />
<!-- IPv6? --><br />
<br />
Alle Parameter bis auf hostname können entfallen. Bei nichtdokumentierten Argumenten ist das Verhalten undefiniert&trade;.<br />
<br />
====Antwort====<br />
<br />
Die Antwort auf eine erfolgreiche HTTP-Anfrage besteht im häufigsten Fall aus einigen Header-Zeilen, gefolgt vom Inhalt der gewünschten Text- oder andere Datei. Ein Status-Code in der ersten Header-Zeile gibt an, ob die Anfrage bedient werden kann oder kreist andernfalls den Grund für die Enttäuschung ein.<br />
<br />
Die vorliegende Beispielimplementierung von DDNS schickt einen der üblichen HTTP-Status-Codes "200 OK" oder "500 Internal Server Error", gefolgt von einer kurzen Textnachricht nach dem HTTP-Header. Bei diesem Programm ist &ndash; laut Gebrauchshinweise von DynDNS.org &ndash; ''nicht'' der Status-Code im Header, sondern der Inhalt der Nachricht die definierte, maßgebliche Ergebnismeldung des Programms.<br />
<br />
{| class="wikitable"<br />
|- class="hintergrundfarbe5"<br />
! Meldung !! Bedeutung !! Bemerkungen<br />
|-<br />
| <tt>good&nbsp;&lt;IP&nbsp;number&gt;</tt> ||<br />
Der gewünschte DNS-Eintrag wurde erfolgreich in einer Zonefile eingetragen. <br />
|| Es kann natürlich noch einige Minuten dauern, bis die Zonefile vom Hostsharing-Roboter abgelesen wird und der Inhalt in die BIND-Konfiguration übernommen.<br />
|-<br />
| <tt>nochg&nbsp;&lt;IP&nbsp;number&gt;</tt> ||<br />
Der gewünschte DNS-Eintrag war bereits vorhanden. <br />
|| Der Server selbst macht keine DNS-Abfrage, um das zu vermitteln: die &bdquo;no change&ldquo;-Antwort besagt nur, daß eine Anfrage für diesen Eintrag bereits mit Erfolg quittiert wurde.<br />
|-<br />
| <tt>notfqdn</tt> ||<br />
Fehlschlag: der gewünschte Domainname ist nicht gültig, oder es wurde keiner angegeben.<br />
|| ...<br />
|-<br />
| <tt>nohost</tt> ||<br />
Fehlschlag: der gewünschte Domainname ist gehört nicht zu denen, die für diesen Benutzer des DDNS-Dienstes konfiguriert sind.<br />
|| Siehe den Abschnitt '''Administration''' weiter unten.<br />
|-<br />
| <tt>abuse</tt> ||<br />
Fehlschlag: der gewünschte Domainname ist wegen vorangeganger Fehlschläge oder überflüssiger Aufrufe gesperrt.<br />
|| Siehe den Abschnitt '''Sukzessive Kommunikationsvorgänge''' unten.<br />
|-<br />
| <tt>911</tt> ||<br />
Fehlschlag: Das Server-Programm hat einen internen Fehler festgestellt.<br />
|| Das Problem liegt nicht in der Anfrage an sich.<br />
|}<br />
<br />
Man kann sich durchaus eine sinnreichere Kommunikation zwischen Client und Server vorstellen, doch das hier beschriebene Protokoll ist eben von DynDNS.org verwendet worden und wird in gängigen Routern implementiert, also wird es in der vorliegenden DDNS-Implementierung nachgebildet.<br />
<br />
=== Sukzessive Kommunikationsabläufe ===<br />
Der Server muß sich zwischen einzelnen Aufrufen einiges merken, um Ressourcen zu schonen und um zu verhindern, daß einmal vergebene DDNS-Einträge von neuen Anfragen, die dieselbe übergeordnete Domain betreffen, durch Überschreiben verlorengehen.<br />
<br />
==== Mißbrauch und Benutzersperrung ====<br />
Zur Schonung von Ressourcen muß sich die Implementierung weigern, sich mit zuvielen fehlerhaften oder auch nur überflüssigen Anfragen zu beschäftigen. Dazu führt eine Strichliste über solche Anfragen jedes Clients und sperrt nach einer bestimmten Anzahl solcher Anfragen den Benutzernamen oder einzelne Domainnamen gegen die weitere Nutzung des Dienstes.<br />
<br />
Mißbrauchspunkte gegen einen einzelnen Domainnamen gibt es für:<br />
* eine Anfrage, die keinen neuen DNS-Eintrag (und keine Änderung oder Löschung eines Eintrags) erfordert, sondern bestehende Merkmale nur wiederholt<br />
<br />
Mißbrauchspunkte gegen einen Benutzernamen gibt es für:<br />
* die Angabe eines Domainnamens, der in der Dienstkonfiguration dem anfragenden Benutzernamen nicht zugeordnet ist<br />
* die Angabe eines Domainnamen in einer Domain, die nicht demselben Hostsharing-Domain-Admin gehört, der den DDNS-Dienst anbietet<br />
* die Angabe eines Domainnamens, der in der Dienstkonfiguration bereits wegen mißbräuchlicher Anfragen gesperrt ist (siehe oben)<br />
<br />
Um eine Sperrung aufzuheben, wird in der Regel eine Handlung durch den Administrator erforderlich sein.<br />
<br />
==== Mehrere dynamische Subdomains in derselben Domain ====<br />
Sobald zwei verschiedene DDNS-Einträge in derselben Domain verlangt werden &ndash; beispielsweise home.example.com und office.example.com &ndash; wird es notwendig, bei jeder neuen Zonefile für example.com eventuell frühere Einträge zu konservieren. Der Rechner zu Hause weiß beim Bestellen seines DDNS-Eintrags nichts vom Rechner im Büro und umgekehrt. Der Server muß in irgendeiner Form über bereits vergebene Einträge Buch führen und bei einer neuen Anfrage, die example.com betrifft, alle bereits aktiven DDNS-Einträge für example.com mit in die neue Zonefile aufnehmen &ndash auch wenn sie auf Anfragen verschiedener Benutzer zurückgehen.<br />
<br />
==== Datenbank ====<br />
In der Beispielimplementierung werden diese Informationen in einer SQLite-Datenbank gespeichert.<br />
<br />
== Sicherheit ==<br />
=== Rechte ===<br />
Die '''Benutzerrechte''' werden durch das Hostsharing-System kontrolliert. Sowohl das CGI-Programm als auch das [[#Administration|Administrationswerkzeug]] werden mit den Rechten des Domain-Admins (xyz00-benutzername in unserem Beispiel) ausgeführt, also kann dieses Programm nur die Domains bearbeiten, die von xyz00-benutzername verwaltet werden.<br />
<br />
=== Authentifizierung ===<br />
In der Beispielimplementierung (wie auch seinerzeit bei DynDNS.org) wird das CGI-Programm durch einen .htaccess-Eintrag geschützt, der HTTP-Basic-Authentication vorschreibt. Also wird das Programm eigentlich mit einem URL der form<br />
<br />
<nowiki>https://ddnsaccount:passwort@ddns.example.com/cgi-bin/ddns?hostname=...</nowiki><br />
<br />
aufgerufen.<br />
<br />
=== Verschlüsselung ===<br />
Das CGI-Programm sollte nur in example.com/cgi-ssl/ installiert werden, nicht in example.com/cgi/. Damit ist die Kommunikation zwischen Client und Server durch SSL verschlüsselt.<br />
<br />
== Administration ==<br />
<br />
Der Verwalter des DDNS-Programms trägt berechtigte Benutzer und die ihnen zugeteilten Domainnamen in die Datenbank des Programms ein mit Hilfe eines kleinen Hilfsprogramms. Das ist im vorliegenden Fall ein menügesteuertes Programm für die Befehlszeile, daß die naheliegenden Funktionen anbietet: Account hinzufügen, löschen, sperren, entsperren, Paßwort setzen, ändern; Domainnamen hinzufügen, ändern, entsperren, löschen; Accounts und Domainnamen mit aktuellem Status auflisten. Die Funktionen sind auch über Befehlszeilenargumente verfügbar, also skriptfähig.<br />
<br />
=== Log ===<br />
Alle Anfragen werden in einer täglich wechselnden Log-Datei protokolliert, entweder schlicht oder ausführlich, je nachdem, ob eine Variable <tt>verbose</tt> wahr ist.<br />
Ein ausführlicher Log-Eintrag sieht so aus:<br />
<br />
Sun Apr 26 20:21:45 2020 ddns aufgerufen von papst<br />
unter 84.185.97.8<br />
URL: <nowiki>https://ddns.example.com/cgi-bin/ddns.cgi?hostname=<br />
avignon.example.com,vatican.beispiel.de&<br />
myip=84.185.97.8</nowiki><br />
Verwende IP 84.185.97.8 (= 1421435144)<br />
DB-Version: 1<br />
Skript und DB exklusiv geöffnet<br />
avignon.example.com: IP 84.185.97.8; MX 0; Backup-MX 0;<br />
Wildcard 0; Mißbrauch 0; gesperrt 0 <br />
vatican.beispiel.de: IP 84.185.97.8; MX 0; Backup-MX 0;<br />
Wildcard 0; Mißbrauch 0; gesperrt 0 <br />
Betroffene Zonen: example.com, beispiel.de<br />
Temporärdatei example.com_hxNa.new geschrieben<br />
Zonendatei /home/pacs/xyz00/users/benutzername/doms/example.com/<br />
etc/pri.example.com eingestellt<br />
Temporärdatei beispiel.de_6HcO.new geschrieben<br />
Zonendatei /home/pacs/xyz00/users/benutzername/doms/beispiel.de/<br />
etc/pri.beispiel.de eingestellt<br />
Abgeschlossen: Fertig<br />
<br />
ölkölkj</div>Apc00-tony