https://wiki.hostsharing.net/api.php?action=feedcontributions&feedformat=atom&user=Apc00Hostsharing Wiki - Benutzerbeiträge [de]2026-04-25T20:08:53ZBenutzerbeiträgeMediaWiki 1.43.8https://wiki.hostsharing.net/index.php?title=Verwalten_der_Zonendaten&diff=5116Verwalten der Zonendaten2020-04-15T10:23:35Z<p>Apc00: /* Expansion der Platzhalter */ Da hat {HEADER} gefehlt.</p>
<hr />
<div>{{Kerndoku|https://doc.hostsharing.net/users/administration/zonefile/index.html}}<br />
<br />
Das Zonenfile für eine Domain enthält die Konfiguration des Domain Name Service ([[DNS]]), d.h. der [[Nameserver]] der Domain. Es wird hinterlegt, welche Hostnamen innerhalb der Domain existieren und auf welche IP-Adressen diese zeigen. Außerdem wird hierüber auch gesteuert, an welches System Mails für die Domain geliefert werden sollen. Für einfache und unkomplizierte Änderungen bitte in [[Simple Zonefile Howto]] schauen.<br />
<br />
{{Textkasten|rot|Achtung|Aufgrund der zentralen Bedeutung sollten Änderungen nur mit Vorsicht vorgenommen werden, da eine fehlerhafte Einstellung dazu führen kann, dass die Webseite nicht mehr im Internet abgerufen werden kann oder Mails verloren gehen!}}<br />
<br />
== Aktives Zonefile ==<br />
<br />
Die gerade aktive Konfiguration einer Domain example.com ist in /etc/bind/pri.example.com zu finden ([[Zonefile]]).<br />
<br />
Im Standardfall sieht es vollständig expandiert wie folgt aus:<br />
<br />
<pre><nowiki>example.com. IN SOA h00.hostsharing.net. hostmaster.hostsharing.net. (<br />
1303649373 ; serial secs since Jan 1 1970<br />
6H ; refresh (>=10000)<br />
1H ; retry (>=1800)<br />
1W ; expire<br />
1H ; minimum<br />
)<br />
<br />
example.com. IN NS dns1.hostsharing.net.<br />
example.com. IN NS dns2.hostsharing.net.<br />
example.com. IN NS dns3.hostsharing.net.<br />
<br />
example.com. IN MX 30 mailin1.hostsharing.net.<br />
example.com. IN MX 30 mailin2.hostsharing.net.<br />
example.com. IN MX 30 mailin3.hostsharing.net.<br />
<br />
example.com. IN A 83.223.95.160<br />
example.com. IN AAAA 2a01:37:1000::53df:5fa0:0<br />
<br />
example.com. IN TXT "v=spf1 include:spf.hostsharing.net ?all"<br />
<br />
*.example.com. IN MX 30 mailin1.hostsharing.net.<br />
*.example.com. IN MX 30 mailin2.hostsharing.net.<br />
*.example.com. IN MX 30 mailin3.hostsharing.net.<br />
<br />
*.example.com. IN A 83.223.95.160<br />
*.example.com. IN AAAA 2a01:37:1000::53df:5fa0:0<br />
<br />
*.example.com. IN TXT "v=spf1 include:spf.hostsharing.net ?all"<br />
</nowiki></pre><br />
<br />
== Logfile und Kontrolle==<br />
<br />
Die Logfiles des Nameservers sind im Verzeichnis /var/log/named einsehbar. Das aktuelle Log wird unter dem Namen named.log angelegt. Dieses wird beim Neustart des DNS-Servers immer neu angelegt und zeigt bei einer erfolgreichen Änderung etwa folgenden Inhalt:<br />
<br />
Oct 11 18:32:21.400 info: zone example.org/IN: loaded serial 1065889567<br />
Oct 11 18:32:21.435 info: zone example.org/IN: sending notifies (serial 1065889567)<br />
Oct 11 18:32:21.755 info: client 213.133.116.2#57100: transfer of 'example.org/IN': <br />
AXFR-style IXFR started<br />
Oct 11 18:32:22.264 info: client 62.75.149.27#45282: transfer of 'example.org/IN': <br />
AXFR-style IXFR started<br />
<br />
Die Zeilen bedeuten jeweils:<br />
<br />
* Das geänderte Zonefile wurde vom DNS-Server erfolgreich geladen<br />
* Der lokale Server sendet eine Benachrichtigung an die Secondaries, damit diese die Änderung ebenfalls übernehmen können.<br />
<br />
Tippfehler oder falsche Angaben im Zonefile werden hier ebenfalls gemeldet.<br />
<br />
<pre><br />
-------- Original-Nachricht --------<br />
Betreff: [Global] DNS Zonenfile Änderungen<br />
Datum: Thu, 4 Mar 2010 08:30:34 +0100<br />
<br />
Moin Moin,<br />
<br />
aus gegebenem Anlass: Immer wieder kommt es vor, dass jemand sein<br />
Zonenfile ändert, und es (scheinbar) funktioniert. Tage oder Wochen<br />
später dann sind die Domains nicht mehr erreichbar und es heißt "in den<br />
letzten ... Tagen/Wochen habe ich aber gar nichts mehr geändert". Das mag<br />
auch gut sein - ist mir auch selbst schon passiert, gerade wenn es um<br />
"mal eben schnell noch ... " ging.<br />
<br />
Nur ist der Fehler dann aber schon vor Tagen/Wochen passiert, und solange<br />
die Datensätze nicht abgelaufen (expired) sind, sind sie - die alten -<br />
noch im DNS System vorhanden. Die neuen aber, die aus der o.g. Änderung,<br />
sind bei einem Fehler im Zonenfile nie ins DNS System hinein gekommen!<br />
<br />
Was also tun? Zunächst kann man nach einer Änderung in einer<br />
Shell beobachten, ob es zu Fehlermeldungen kommt:<br />
<br />
tail -f /var/log/named/named.log <br />
<br />
oder ggf nur Zeilen, in denen die eigene Domain (z.B. example.com)<br />
vorkommt:<br />
<br />
tail -f /var/log/named/named.log | grep example.com<br />
<br />
Diese Log-Datei ist daher genau aus diese Grunde auch auf dem<br />
Server lesbar.<br />
<br />
Auch sollte die in den DNS-Servern befindliche Seriennummer mit der<br />
aktuellen in der Zonendatei verglichen werden:<br />
<br />
dig -t SOA @dns1 example.com | grep '^example.com.*SOA' | awk '{ print $7 }'<br />
<br />
grep serial /etc/bind/pri.example.com | awk '{ print $1 }' <br />
</pre><br />
<br />
== Eigenes Zonenfile ==<br />
<br />
Wer ein eigenes Zonefile installieren möchte, um diverse Anwendungsfälle zu realisieren (Verweise auf extern gelagerte Subdomains, Anbindung externer Server, Verwendung eigener Mailserver), kann '''pro Domain''' ein eigenes Zonefile erstellen. Dieses befindet sich im Verzeichnis '''~/doms/example.com/etc''' mit den Namen '''pri.example.com''' (example.com steht hier als Beispiel für den wahren Domainnamen). Ein Neuanlegen oder eine Änderung dieser Datei führt zu einer baldigen Änderung der Nameservereinträge für die Domain.<br />
<br />
{{Textkasten|rot|Warnung!|Das nicht sachgemäße Erstellen eines eigenen Zonefiles kann zur Nichterreichbarkeit der eigenen Domain und zum Verlust von Mails führen!}}<br />
<br />
Eine Anleitung für die eher einfachen und oft gewünschten Änderungen findet sich in [[Simple Zonefile Howto]].<br />
<br />
Folgende Platzhalter können und sollten in eigenen Zonenfiles verwendet werden. Sie ermöglichen uns das Ändern der DNS-Konfiguration, ohne dass der Domain-Admin sein Zonefile anpassen muss.<br />
<br />
=== Komplexe Platzhalter ===<br />
<br />
<pre><br />
{DEFAULT_ZONEFILE} :=<br />
{HEADER}<br />
{SOA_RR}<br />
{NS_RR}<br />
{MX_RR} <br />
{A_RR}<br />
{WILDCARD_MX_RR}<br />
{WILDCARD_A_RR}<br />
<br />
{HEADER} :=<br />
$TTL {TTL}<br />
<br />
{SOA_RR} :=<br />
{DOM_HOSTNAME}. IN SOA {SOA_HOSTNAME}. {SOA_EMAIL}. (<br />
{SIO} ; serial secs since Jan 1 1970<br />
{REFRESH} ; refresh (>=10000)<br />
{RETRY} ; retry (>=1800)<br />
{EXPIRE} ; expire<br />
{MINIMUM} ; minimum<br />
)<br />
<br />
{NS_RR} :=<br />
{DOM_HOSTNAME}. IN NS {DNS1_HOSTNAME}.<br />
{DOM_HOSTNAME}. IN NS {DNS2_HOSTNAME}.<br />
{DOM_HOSTNAME}. IN NS {DNS3_HOSTNAME}.<br />
<br />
{MX_RR} :=<br />
{DOM_HOSTNAME}. IN MX 30 {MX1_HOSTNAME}.<br />
{DOM_HOSTNAME}. IN MX 30 {MX2_HOSTNAME}.<br />
{DOM_HOSTNAME}. IN MX 30 {MX3_HOSTNAME}.<br />
<br />
{A_RR} :=<br />
{DOM_HOSTNAME}. IN A {DOM_IPNUMBER}<br />
<br />
{WILDCARD_MX_RR} :=<br />
*.{DOM_HOSTNAME}. IN MX 30 {MX1_HOSTNAME}.<br />
*.{DOM_HOSTNAME}. IN MX 30 {MX2_HOSTNAME}.<br />
*.{DOM_HOSTNAME}. IN MX 30 {MX3_HOSTNAME}.<br />
<br />
{WILDCARD_A_RR} :=<br />
*.{DOM_HOSTNAME}. IN A {DOM_IPNUMBER}<br />
</pre><br />
<br />
=== Atomare Platzhalter ===<br />
<br />
<pre><br />
{TTL} := 6H<br />
{SOA_HOSTNAME} := <HIVE>.hostsharing.net<br />
{SOA_EMAIL}:= hostmaster.hostsharing.net<br />
{SIO} := <SEKUNDEN><br />
{REFRESH} := 6H<br />
{RETRY} := 1H<br />
{EXPIRE} := 1W<br />
{MINIMUM} := 1H<br />
<br />
{DNS1_HOSTNAME} := dns1.hostsharing.net<br />
{DNS2_HOSTNAME} := dns2.hostsharing.net<br />
{DNS3_HOSTNAME} := dns3.hostsharing.net<br />
<br />
{MX1_HOSTNAME} := mailin1.hostsharing.net<br />
{MX2_HOSTNAME} := mailin2.hostsharing.net<br />
{MX3_HOSTNAME} := mailin3.hostsharing.net<br />
<br />
{DOM_HOSTNAME} := <FQDN><br />
{DOM_IPNUMBER} := <IP><br />
</pre><br />
<br />
Hierbei stehen<br />
* <Sekunden> für die Anzahl der Sekunden, welche seit dem 01.01.1970 vergangen sind<br />
* <FQDN> für den vollständigen, qualifizierten Domainnamen der Domain<br />
* <IP> für die der Domain zugewiesene IP-Adresse<br />
<br />
Diese Werte werden von Hostsharing verwaltet.<br />
<br />
=== Expansion der Platzhalter ===<br />
<br />
Der Platzhalter für das Gesamtzonefile {DEFAULT_ZONFILE} wird folgermaßen expandiert.<br />
<br />
Zunächst werden die komplexen Platzhalter ersetzt:<br />
<br />
<pre><br />
$TTL {TTL}<br />
<br />
{DOM_HOSTNAME}. IN SOA {SOA_HOSTNAME}. {SOA_EMAIL}. (<br />
{SIO} ; serial secs since Jan 1 1970<br />
{REFRESH} ; refresh (>=10000)<br />
{RETRY} ; retry (>=1800)<br />
{EXPIRE} ; expire<br />
{MINIMUM} ; minimum<br />
)<br />
<br />
{DOM_HOSTNAME}. IN NS {DNS1_HOSTNAME}.<br />
{DOM_HOSTNAME}. IN NS {DNS2_HOSTNAME}.<br />
{DOM_HOSTNAME}. IN NS {DNS3_HOSTNAME}.<br />
<br />
{DOM_HOSTNAME}. IN MX 30 {MX1_HOSTNAME}.<br />
{DOM_HOSTNAME}. IN MX 30 {MX2_HOSTNAME}.<br />
{DOM_HOSTNAME}. IN MX 30 {MX3_HOSTNAME}.<br />
<br />
{DOM_HOSTNAME}. IN A {DOM_IPNUMBER}<br />
<br />
*.{DOM_HOSTNAME}. IN MX 30 {MX1_HOSTNAME}.<br />
*.{DOM_HOSTNAME}. IN MX 30 {MX2_HOSTNAME}.<br />
*.{DOM_HOSTNAME}. IN MX 30 {MX3_HOSTNAME}.<br />
<br />
*.{DOM_HOSTNAME}. IN A {DOM_IPNUMBER}<br />
</pre><br />
<br />
Anschließend werden die atomaren Platzhalter ersetzt:<br />
<br />
<pre><br />
$TTL 6H<br />
<br />
<FQDN>. IN SOA <HIVE>.hostsharing.net. hostmaster.hostsharing.net. (<br />
<SEKUNDEN> ; serial secs since Jan 1 1970<br />
6H ; refresh (>=10000)<br />
1H ; retry (>=1800)<br />
1W ; expire<br />
1H ; minimum<br />
)<br />
<br />
<FQDN>. IN NS dns1.hostsharing.net.<br />
<FQDN>. IN NS dns2.hostsharing.net.<br />
<FQDN>. IN NS dns3.hostsharing.net.<br />
<br />
<FQDN>. IN MX 30 mail1.hostsharing.net.<br />
<FQDN>. IN MX 30 mail2.hostsharing.net.<br />
<FQDN>. IN MX 30 mail3.hostsharing.net.<br />
<br />
<FQDN>. IN A <IP><br />
<br />
*.<FQDN>. IN MX 30 mail1.hostsharing.net.<br />
*.<FQDN>. IN MX 30 mail2.hostsharing.net.<br />
*.<FQDN>. IN MX 30 mail3.hostsharing.net.<br />
<br />
*.<FQDN>. IN A <IP><br />
</pre><br />
<br />
== Das Zonefile deaktivieren/zurücksetzen ==<br />
<br />
In ~/doms/example.com/etc das vorhandene Zonefile (pri.example.com) komplett leeren (ist dann 0 Bytes groß). Dann kommt der Robot vorbei, löscht pri.example.com und setzt alles auf Standardwerte zurück.<br />
<br />
----<br />
[[Kategorie:HSDoku]]<br />
[[Kategorie:Domains]]<br />
[[Kategorie:Zonefile]]<br />
[[Kategorie:DNS]]</div>Apc00https://wiki.hostsharing.net/index.php?title=Mailman_Installieren&diff=4996Mailman Installieren2019-10-14T06:44:45Z<p>Apc00: Gliederung</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 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 />
=== Email Adressen einrichten ===<br />
<br />
Sobald ein neuer Verteiler angelegt worden ist, sendet Mailman eine Mail an den dabei eingetragenen Listenadministrator. Diese 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 Mails an Mailman werden an erweiterte ''E-Mail-Adressen'' des Mailman-Users xyz00-listen geschickt. Diese Adressen haben die form xyz00-listen'''+'''<liste>[_funktion]. 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'' werden durch [https://doc.hostsharing.net/users/administration/hsadmin/index.html hsadmin (bzw. das Befehlszeielentool 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 Paßworts 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 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 Emailadressen 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>Apc00https://wiki.hostsharing.net/index.php?title=Mailman_Installieren&diff=4995Mailman Installieren2019-10-14T06:43:38Z<p>Apc00: Warnung zur begrenzten Lebensdauer von MM2 vorne hinzugefügt.</p>
<hr />
<div>== 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 />
=== Vorne weg: 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 />
=== 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 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 />
=== Email Adressen einrichten ===<br />
<br />
Sobald ein neuer Verteiler angelegt worden ist, sendet Mailman eine Mail an den dabei eingetragenen Listenadministrator. Diese 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 Mails an Mailman werden an erweiterte ''E-Mail-Adressen'' des Mailman-Users xyz00-listen geschickt. Diese Adressen haben die form xyz00-listen'''+'''<liste>[_funktion]. 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'' werden durch [https://doc.hostsharing.net/users/administration/hsadmin/index.html hsadmin (bzw. das Befehlszeielentool 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 Paßworts 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 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 Emailadressen 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>Apc00https://wiki.hostsharing.net/index.php?title=Mailman_Installieren&diff=4842Mailman Installieren2019-03-14T13:09:11Z<p>Apc00: /* Sourcen besorgen und entpacken */</p>
<hr />
<div>== Mailman 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 />
Mailman kann vom Paketadmin (beipsielsweise "xyz00") oder von einem Paketuser (bspw. "xyz00-listen") installiert werden. Letzteres ist dringend empfohlen, denn 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:<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:<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:<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: <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 />
=== Email Adressen einrichten ===<br />
<br />
Sobald ein neuer Verteiler angelegt worden ist, sendet Mailman eine Mail an den dabei eingetragenen Listenadministrator. Diese 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 Mails an Mailman werden an erweiterte ''E-Mail-Adressen'' des Mailman-Users xyz00-listen geschickt. Diese Adressen haben die form xyz00-listen'''+'''<liste>[_funktion]. 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'' werden durch [https://doc.hostsharing.net/users/administration/hsadmin/index.html hsadmin (bzw. das Befehlszeielentool 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 Paßworts 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 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 Emailadressen 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 statt Paketadmin: https://lists.hostsharing.net/archiv/support/2009-June/019414.html<br><br />
Ältere Anleitung für Installation als Domain-Admin: <http://lists.hostsharing.net/archiv/support/2005-January/012426.html><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>Apc00https://wiki.hostsharing.net/index.php?title=Mailman_Installieren&diff=4841Mailman Installieren2019-03-14T13:08:30Z<p>Apc00: </p>
<hr />
<div>== Mailman 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 />
Mailman kann vom Paketadmin (beipsielsweise "xyz00") oder von einem Paketuser (bspw. "xyz00-listen") installiert werden. Letzteres ist dringend empfohlen, denn 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 Mailman 2 Versionen (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:<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:<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:<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: <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 />
=== Email Adressen einrichten ===<br />
<br />
Sobald ein neuer Verteiler angelegt worden ist, sendet Mailman eine Mail an den dabei eingetragenen Listenadministrator. Diese 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 Mails an Mailman werden an erweiterte ''E-Mail-Adressen'' des Mailman-Users xyz00-listen geschickt. Diese Adressen haben die form xyz00-listen'''+'''<liste>[_funktion]. 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'' werden durch [https://doc.hostsharing.net/users/administration/hsadmin/index.html hsadmin (bzw. das Befehlszeielentool 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 Paßworts 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 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 Emailadressen 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 statt Paketadmin: https://lists.hostsharing.net/archiv/support/2009-June/019414.html<br><br />
Ältere Anleitung für Installation als Domain-Admin: <http://lists.hostsharing.net/archiv/support/2005-January/012426.html><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>Apc00https://wiki.hostsharing.net/index.php?title=Mailman_Installieren&diff=4840Mailman Installieren2019-03-14T13:07:31Z<p>Apc00: /* Mailman-Icons in die Domains kopieren */</p>
<hr />
<div>== Mailman 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 />
Mailman kann vom Paketadmin (beipsielsweise "xyz00") oder von einem Paketuser (bspw. "xyz00-listen") installiert werden. Letzteres ist dringend empfohlen, denn 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 Mailman 2 Versionen (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:<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:<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:<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: <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 />
=== Email Adressen einrichten ===<br />
<br />
Sobald ein neuer Verteiler angelegt worden ist, sendet Mailman eine Mail an den dabei eingetragenen Listenadministrator. Diese 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 Mails an Mailman werden an erweiterte ''E-Mail-Adressen'' des Mailman-Users xyz00-listen geschickt. Diese Adressen haben die form xyz00-listen'''+'''<liste>[_funktion]. 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'' werden durch [https://doc.hostsharing.net/users/administration/hsadmin/index.html hsadmin (bzw. das Befehlszeielentool 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 Paßworts 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 Mail an die Adresse mailman-subscribe@lists.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/lists.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@lists.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 lists.example.com sowohl als URL für das Webfrontend wie auch als Hostpart für Emailadressen verwendet. (Was für separate aufgeschaltete Domains wie z.B. lists.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 = 'lists.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 statt Paketadmin: https://lists.hostsharing.net/archiv/support/2009-June/019414.html<br><br />
Ältere Anleitung für Installation als Domain-Admin: <http://lists.hostsharing.net/archiv/support/2005-January/012426.html><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>Apc00https://wiki.hostsharing.net/index.php?title=Mailman_Installieren&diff=4839Mailman Installieren2019-03-14T13:07:15Z<p>Apc00: /* Einen User und eine Domain anlegen */</p>
<hr />
<div>== Mailman 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 />
Mailman kann vom Paketadmin (beipsielsweise "xyz00") oder von einem Paketuser (bspw. "xyz00-listen") installiert werden. Letzteres ist dringend empfohlen, denn 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 Mailman 2 Versionen (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:<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:<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:<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: <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/lists.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 />
=== Email Adressen einrichten ===<br />
<br />
Sobald ein neuer Verteiler angelegt worden ist, sendet Mailman eine Mail an den dabei eingetragenen Listenadministrator. Diese 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 Mails an Mailman werden an erweiterte ''E-Mail-Adressen'' des Mailman-Users xyz00-listen geschickt. Diese Adressen haben die form xyz00-listen'''+'''<liste>[_funktion]. 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'' werden durch [https://doc.hostsharing.net/users/administration/hsadmin/index.html hsadmin (bzw. das Befehlszeielentool 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 Paßworts 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 Mail an die Adresse mailman-subscribe@lists.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/lists.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@lists.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 lists.example.com sowohl als URL für das Webfrontend wie auch als Hostpart für Emailadressen verwendet. (Was für separate aufgeschaltete Domains wie z.B. lists.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 = 'lists.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 statt Paketadmin: https://lists.hostsharing.net/archiv/support/2009-June/019414.html<br><br />
Ältere Anleitung für Installation als Domain-Admin: <http://lists.hostsharing.net/archiv/support/2005-January/012426.html><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>Apc00https://wiki.hostsharing.net/index.php?title=Mailman_Installieren&diff=4838Mailman Installieren2019-03-14T13:06:45Z<p>Apc00: Nur example.com ist als Beispielsdomainname freigegeben.</p>
<hr />
<div>== Mailman 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 />
Mailman kann vom Paketadmin (beipsielsweise "xyz00") oder von einem Paketuser (bspw. "xyz00-listen") installiert werden. Letzteres ist dringend empfohlen, denn 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/lists.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 Mailman 2 Versionen (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:<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:<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:<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: <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/lists.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 />
=== Email Adressen einrichten ===<br />
<br />
Sobald ein neuer Verteiler angelegt worden ist, sendet Mailman eine Mail an den dabei eingetragenen Listenadministrator. Diese 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 Mails an Mailman werden an erweiterte ''E-Mail-Adressen'' des Mailman-Users xyz00-listen geschickt. Diese Adressen haben die form xyz00-listen'''+'''<liste>[_funktion]. 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'' werden durch [https://doc.hostsharing.net/users/administration/hsadmin/index.html hsadmin (bzw. das Befehlszeielentool 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 Paßworts 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 Mail an die Adresse mailman-subscribe@lists.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/lists.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@lists.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 lists.example.com sowohl als URL für das Webfrontend wie auch als Hostpart für Emailadressen verwendet. (Was für separate aufgeschaltete Domains wie z.B. lists.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 = 'lists.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 statt Paketadmin: https://lists.hostsharing.net/archiv/support/2009-June/019414.html<br><br />
Ältere Anleitung für Installation als Domain-Admin: <http://lists.hostsharing.net/archiv/support/2005-January/012426.html><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>Apc00https://wiki.hostsharing.net/index.php?title=Mailman_Installieren&diff=4837Mailman Installieren2019-03-14T13:01:41Z<p>Apc00: /* Administration */</p>
<hr />
<div>Was noch jemand ergänzen müsste:<br />
* Eine generische virtuser/alias Konfiguration finden und dokumentieren. <br><br />
http://listes.rezo.net/how.php<br> http://www.gnu.org/software/mailman/mailman-install/mail-server.html<br />
<br />
* Skriptautomatisierung updaten <br> http://hs.andreasloesch.de/pac-mm-install<br />
<br />
<br />
== Mailman 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 />
Mailman kann vom Paketadmin (beipsielsweise "xyz00") oder von einem Paketuser (bspw. "xyz00-listen") installiert werden. Letzteres ist dringend empfohlen, denn 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.de 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.de/htdocs-ssl/.htaccess löschen:<br />
<br />
~$ echo "" > ~/doms/lists.example.de/htdocs-ssl/.htaccess<br />
<br />
Die Default-Subdomains www.* löschen:<br />
<br />
~$ rm -r doms/listen.example.de/subs/www/<br />
~$ rm -r doms/listen.example.de/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 Mailman 2 Versionen (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:<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:<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.de 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.de'<br />
DEFAULT_EMAIL_HOST = 'listen.example.de'<br />
DEFAULT_URL_HOST = 'listen.example.de'<br />
add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)<br />
add_virtualhost(zweite.listendomain.de, zweite.listendomain.de)<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:<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.de/cgi-ssl/mailman<br />
~$ cp mailman/cgi-bin/* doms/listen.example.de/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.de/cgi/mailman/*<br />
<br />
Bei der Installation als Paketadmin: <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.de/cgi-ssl<br />
~/doms/listen.example.de/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.de/htdocs-ssl<br />
~/doms/listen.example.de/htdocs-ssl$ ln -s ../../../mailman/icons<br />
<br />
oder<br />
<br />
~$ cp -R mailman/icons doms/lists.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.de/cgi-bin/mailman, sondern auch unter https://listen.example.de erreichbar ist.<br />
<br />
Dazu werden in ~/doms/listen.example.de/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 />
=== Email Adressen einrichten ===<br />
<br />
Sobald ein neuer Verteiler angelegt worden ist, sendet Mailman eine Mail an den dabei eingetragenen Listenadministrator. Diese 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 Mails an Mailman werden an erweiterte ''E-Mail-Adressen'' des Mailman-Users xyz00-listen geschickt. Diese Adressen haben die form xyz00-listen'''+'''<liste>[_funktion]. 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'' werden durch [https://doc.hostsharing.net/users/administration/hsadmin/index.html hsadmin (bzw. das Befehlszeielentool 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 Paßworts vom Paketadmin xyz00; dann können diese Befehle eingegeben werden:]<br />
emailaddress.add ({set:{domain:'listen.example.de',localpart:'mailman',target:'xyz00-listen+mailman'}})<br />
emailaddress.add ({set:{domain:'listen.example.de',localpart:'mailman-admin',target:'xyz00-listen+mailman-admin'}})<br />
emailaddress.add ({set:{domain:'listen.example.de',localpart:'mailman-bounces',target:'xyz00-listen+mailman-bounces'}})<br />
emailaddress.add ({set:{domain:'listen.example.de',localpart:'mailman-confirm',target:'xyz00-listen+mailman-confirm'}})<br />
emailaddress.add ({set:{domain:'listen.example.de',localpart:'mailman-join',target:'xyz00-listen+mailman-join'}})<br />
emailaddress.add ({set:{domain:'listen.example.de',localpart:'mailman-leave',target:'xyz00-listen+mailman-leave'}})<br />
emailaddress.add ({set:{domain:'listen.example.de',localpart:'mailman-owner',target:'xyz00-listen+mailman-owner'}})<br />
emailaddress.add ({set:{domain:'listen.example.de',localpart:'mailman-request',target:'xyz00-listen+mailman-request'}})<br />
emailaddress.add ({set:{domain:'listen.example.de',localpart:'mailman-subscribe',target:'xyz00-listen+mailman-subscribe'}})<br />
emailaddress.add ({set:{domain:'listen.example.de',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 Mail an die Adresse mailman-subscribe@lists.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.de/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.de/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.de/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/lists.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@lists.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 lists.example.com sowohl als URL für das Webfrontend wie auch als Hostpart für Emailadressen verwendet. (Was für separate aufgeschaltete Domains wie z.B. lists.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 = 'lists.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 statt Paketadmin: https://lists.hostsharing.net/archiv/support/2009-June/019414.html<br><br />
Ältere Anleitung für Installation als Domain-Admin: <http://lists.hostsharing.net/archiv/support/2005-January/012426.html><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>Apc00https://wiki.hostsharing.net/index.php?title=Mailman_Installieren&diff=4836Mailman Installieren2019-03-13T16:41:59Z<p>Apc00: /* Email Adressen einrichten */</p>
<hr />
<div>Was noch jemand ergänzen müsste:<br />
* Eine generische virtuser/alias Konfiguration finden und dokumentieren. <br><br />
http://listes.rezo.net/how.php<br> http://www.gnu.org/software/mailman/mailman-install/mail-server.html<br />
<br />
* Skriptautomatisierung updaten <br> http://hs.andreasloesch.de/pac-mm-install<br />
<br />
<br />
== Mailman 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 />
Mailman kann vom Paketadmin (beipsielsweise "xyz00") oder von einem Paketuser (bspw. "xyz00-listen") installiert werden. Letzteres ist dringend empfohlen, denn 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.de 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.de/htdocs-ssl/.htaccess löschen:<br />
<br />
~$ echo "" > ~/doms/lists.example.de/htdocs-ssl/.htaccess<br />
<br />
Die Default-Subdomains www.* löschen:<br />
<br />
~$ rm -r doms/listen.example.de/subs/www/<br />
~$ rm -r doms/listen.example.de/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 Mailman 2 Versionen (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:<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:<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.de 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.de'<br />
DEFAULT_EMAIL_HOST = 'listen.example.de'<br />
DEFAULT_URL_HOST = 'listen.example.de'<br />
add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)<br />
add_virtualhost(zweite.listendomain.de, zweite.listendomain.de)<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:<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.de/cgi-ssl/mailman<br />
~$ cp mailman/cgi-bin/* doms/listen.example.de/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.de/cgi/mailman/*<br />
<br />
Bei der Installation als Paketadmin: <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.de/cgi-ssl<br />
~/doms/listen.example.de/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.de/htdocs-ssl<br />
~/doms/listen.example.de/htdocs-ssl$ ln -s ../../../mailman/icons<br />
<br />
oder<br />
<br />
~$ cp -R mailman/icons doms/lists.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.de/cgi-bin/mailman, sondern auch unter https://listen.example.de erreichbar ist.<br />
<br />
Dazu werden in ~/doms/listen.example.de/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 />
=== Email Adressen einrichten ===<br />
<br />
Sobald ein neuer Verteiler angelegt worden ist, sendet Mailman eine Mail an den dabei eingetragenen Listenadministrator. Diese 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 Mails an Mailman werden an erweiterte ''E-Mail-Adressen'' des Mailman-Users xyz00-listen geschickt. Diese Adressen haben die form xyz00-listen'''+'''<liste>[_funktion]. 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'' werden durch [https://doc.hostsharing.net/users/administration/hsadmin/index.html hsadmin (bzw. das Befehlszeielentool 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 Paßworts vom Paketadmin xyz00; dann können diese Befehle eingegeben werden:]<br />
emailaddress.add ({set:{domain:'listen.example.de',localpart:'mailman',target:'xyz00-listen+mailman'}})<br />
emailaddress.add ({set:{domain:'listen.example.de',localpart:'mailman-admin',target:'xyz00-listen+mailman-admin'}})<br />
emailaddress.add ({set:{domain:'listen.example.de',localpart:'mailman-bounces',target:'xyz00-listen+mailman-bounces'}})<br />
emailaddress.add ({set:{domain:'listen.example.de',localpart:'mailman-confirm',target:'xyz00-listen+mailman-confirm'}})<br />
emailaddress.add ({set:{domain:'listen.example.de',localpart:'mailman-join',target:'xyz00-listen+mailman-join'}})<br />
emailaddress.add ({set:{domain:'listen.example.de',localpart:'mailman-leave',target:'xyz00-listen+mailman-leave'}})<br />
emailaddress.add ({set:{domain:'listen.example.de',localpart:'mailman-owner',target:'xyz00-listen+mailman-owner'}})<br />
emailaddress.add ({set:{domain:'listen.example.de',localpart:'mailman-request',target:'xyz00-listen+mailman-request'}})<br />
emailaddress.add ({set:{domain:'listen.example.de',localpart:'mailman-subscribe',target:'xyz00-listen+mailman-subscribe'}})<br />
emailaddress.add ({set:{domain:'listen.example.de',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 Mail an die Adresse mailman-subscribe@lists.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 />
Administriert werden Listen über http://lists.example.com/admin/<listenname> und entweder dem Listenpasswort oder dem Site-Passwort.<br />
<br />
Als erstes sollte man die Liste "mailman" selbst abonnieren. (http://lists.example.com/admin/mailman)<br />
<br />
Bis auf das Anwenden der sitelist.cfg werden auch alle weiteren Listen nach obigem Schema angelegt, oder (bis auf das anlegen der virtusertable Einträge und aliase) über das Mailman Webinterface.<br />
<br />
Das war's. Mailman ist jetzt fertig installiert und müsste sogar funktionieren ;)<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/lists.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@lists.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 lists.example.com sowohl als URL für das Webfrontend wie auch als Hostpart für Emailadressen verwendet. (Was für separate aufgeschaltete Domains wie z.B. lists.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 = 'lists.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 statt Paketadmin: https://lists.hostsharing.net/archiv/support/2009-June/019414.html<br><br />
Ältere Anleitung für Installation als Domain-Admin: <http://lists.hostsharing.net/archiv/support/2005-January/012426.html><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>Apc00https://wiki.hostsharing.net/index.php?title=Mailman_Installieren&diff=4835Mailman Installieren2019-03-13T16:39:33Z<p>Apc00: /* Email Adressen einrichten */</p>
<hr />
<div>Was noch jemand ergänzen müsste:<br />
* Eine generische virtuser/alias Konfiguration finden und dokumentieren. <br><br />
http://listes.rezo.net/how.php<br> http://www.gnu.org/software/mailman/mailman-install/mail-server.html<br />
<br />
* Skriptautomatisierung updaten <br> http://hs.andreasloesch.de/pac-mm-install<br />
<br />
<br />
== Mailman 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 />
Mailman kann vom Paketadmin (beipsielsweise "xyz00") oder von einem Paketuser (bspw. "xyz00-listen") installiert werden. Letzteres ist dringend empfohlen, denn 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.de 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.de/htdocs-ssl/.htaccess löschen:<br />
<br />
~$ echo "" > ~/doms/lists.example.de/htdocs-ssl/.htaccess<br />
<br />
Die Default-Subdomains www.* löschen:<br />
<br />
~$ rm -r doms/listen.example.de/subs/www/<br />
~$ rm -r doms/listen.example.de/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 Mailman 2 Versionen (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:<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:<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.de 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.de'<br />
DEFAULT_EMAIL_HOST = 'listen.example.de'<br />
DEFAULT_URL_HOST = 'listen.example.de'<br />
add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)<br />
add_virtualhost(zweite.listendomain.de, zweite.listendomain.de)<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:<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.de/cgi-ssl/mailman<br />
~$ cp mailman/cgi-bin/* doms/listen.example.de/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.de/cgi/mailman/*<br />
<br />
Bei der Installation als Paketadmin: <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.de/cgi-ssl<br />
~/doms/listen.example.de/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.de/htdocs-ssl<br />
~/doms/listen.example.de/htdocs-ssl$ ln -s ../../../mailman/icons<br />
<br />
oder<br />
<br />
~$ cp -R mailman/icons doms/lists.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.de/cgi-bin/mailman, sondern auch unter https://listen.example.de erreichbar ist.<br />
<br />
Dazu werden in ~/doms/listen.example.de/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 />
=== Email Adressen einrichten ===<br />
<br />
Sobald ein neuer Verteiler angelegt worden ist, sendet Mailman eine Mail an den dabei eingetragenen Listenadministrator. Diese 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 Mails an Mailman werden an erweiterte ''E-Mail-Adressen'' des Mailman-Users xyz00-listen geschickt. Diese Adressen haben die form xyz00-listen'''+'''<liste>[_funktion]. 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'' werden durch [https://doc.hostsharing.net/users/administration/hsadmin/index.html hsadmin (bzw. das Befehlszeielentool 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 Paßworts vom Paketadmin xyz00; dann können diese Befehle eingegeben werden:]<br />
emailaddress.add ({set:{domain:'listen.example.de',localpart:'mailman',target:'xyz00-listen+mailman'}})<br />
emailaddress.add ({set:{domain:'listen.example.de',localpart:'mailman-admin',target:'xyz00-listen+mailman-admin'}})<br />
emailaddress.add ({set:{domain:'listen.example.de',localpart:'mailman-bounces',target:'xyz00-listen+mailman-bounces'}})<br />
emailaddress.add ({set:{domain:'listen.example.de',localpart:'mailman-confirm',target:'xyz00-listen+mailman-confirm'}})<br />
emailaddress.add ({set:{domain:'listen.example.de',localpart:'mailman-join',target:'xyz00-listen+mailman-join'}})<br />
emailaddress.add ({set:{domain:'listen.example.de',localpart:'mailman-leave',target:'xyz00-listen+mailman-leave'}})<br />
emailaddress.add ({set:{domain:'listen.example.de',localpart:'mailman-owner',target:'xyz00-listen+mailman-owner'}})<br />
emailaddress.add ({set:{domain:'listen.example.de',localpart:'mailman-request',target:'xyz00-listen+mailman-request'}})<br />
emailaddress.add ({set:{domain:'listen.example.de',localpart:'mailman-subscribe',target:'xyz00-listen+mailman-subscribe'}})<br />
emailaddress.add ({set:{domain:'listen.example.de',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 Mail an die Adresse mailman-subscribe@lists.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 />
# Add forward files for mailman lists.<br />
#<br />
if [ "$1" = "" ] ; then<br />
echo "Syntax: $0 listname\n" <br />
exit<br />
fi<br />
if [ "$2" != "" ] ; then<br />
echo "Syntax: $0 listname\n" <br />
exit<br />
fi<br />
if [ "`pwd`" != "`echo ~`" ] ; then<br />
echo "Run this script from your home directory.\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 />
Administriert werden Listen über http://lists.example.com/admin/<listenname> und entweder dem Listenpasswort oder dem Site-Passwort.<br />
<br />
Als erstes sollte man die Liste "mailman" selbst abonnieren. (http://lists.example.com/admin/mailman)<br />
<br />
Bis auf das Anwenden der sitelist.cfg werden auch alle weiteren Listen nach obigem Schema angelegt, oder (bis auf das anlegen der virtusertable Einträge und aliase) über das Mailman Webinterface.<br />
<br />
Das war's. Mailman ist jetzt fertig installiert und müsste sogar funktionieren ;)<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/lists.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@lists.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 lists.example.com sowohl als URL für das Webfrontend wie auch als Hostpart für Emailadressen verwendet. (Was für separate aufgeschaltete Domains wie z.B. lists.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 = 'lists.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 statt Paketadmin: https://lists.hostsharing.net/archiv/support/2009-June/019414.html<br><br />
Ältere Anleitung für Installation als Domain-Admin: <http://lists.hostsharing.net/archiv/support/2005-January/012426.html><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>Apc00https://wiki.hostsharing.net/index.php?title=Mailman_Installieren&diff=4834Mailman Installieren2019-03-13T16:36:27Z<p>Apc00: /* Einen User und eine Domain anlegen */</p>
<hr />
<div>Was noch jemand ergänzen müsste:<br />
* Eine generische virtuser/alias Konfiguration finden und dokumentieren. <br><br />
http://listes.rezo.net/how.php<br> http://www.gnu.org/software/mailman/mailman-install/mail-server.html<br />
<br />
* Skriptautomatisierung updaten <br> http://hs.andreasloesch.de/pac-mm-install<br />
<br />
<br />
== Mailman 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 />
Mailman kann vom Paketadmin (beipsielsweise "xyz00") oder von einem Paketuser (bspw. "xyz00-listen") installiert werden. Letzteres ist dringend empfohlen, denn 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.de 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.de/htdocs-ssl/.htaccess löschen:<br />
<br />
~$ echo "" > ~/doms/lists.example.de/htdocs-ssl/.htaccess<br />
<br />
Die Default-Subdomains www.* löschen:<br />
<br />
~$ rm -r doms/listen.example.de/subs/www/<br />
~$ rm -r doms/listen.example.de/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 Mailman 2 Versionen (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:<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:<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.de 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.de'<br />
DEFAULT_EMAIL_HOST = 'listen.example.de'<br />
DEFAULT_URL_HOST = 'listen.example.de'<br />
add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)<br />
add_virtualhost(zweite.listendomain.de, zweite.listendomain.de)<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:<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.de/cgi-ssl/mailman<br />
~$ cp mailman/cgi-bin/* doms/listen.example.de/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.de/cgi/mailman/*<br />
<br />
Bei der Installation als Paketadmin: <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.de/cgi-ssl<br />
~/doms/listen.example.de/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.de/htdocs-ssl<br />
~/doms/listen.example.de/htdocs-ssl$ ln -s ../../../mailman/icons<br />
<br />
oder<br />
<br />
~$ cp -R mailman/icons doms/lists.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.de/cgi-bin/mailman, sondern auch unter https://listen.example.de erreichbar ist.<br />
<br />
Dazu werden in ~/doms/listen.example.de/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 />
=== Email Adressen einrichten ===<br />
<br />
Sobald ein neuer Verteiler angelegt worden ist, sendet Mailman eine Mail an den dabei eingetragenen Listenadministrator. Diese 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 Mails an Mailman werden an erweiterte ''E-Mail-Adressen'' des Mailman-Users xyz00-listen geschickt. Diese Adressen haben die form xyz00-listen'''+'''<liste>[_funktion]. 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'' werden durch [https://doc.hostsharing.net/users/administration/hsadmin/index.html hsadmin (bzw. das Befehlszeielentool 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 Paßworts vom Paketadmin xyz00; dann können diese Befehle eingegeben werden:]<br />
emailaddress.add ({set:{domain:'listen.example.de',localpart:'mailman',target:'xyz00-listen+mailman'}})<br />
emailaddress.add ({set:{domain:'listen.example.de',localpart:'mailman-admin',target:'xyz00-listen+mailman-admin'}})<br />
emailaddress.add ({set:{domain:'listen.example.de',localpart:'mailman-bounces',target:'xyz00-listen+mailman-bounces'}})<br />
emailaddress.add ({set:{domain:'listen.example.de',localpart:'mailman-confirm',target:'xyz00-listen+mailman-confirm'}})<br />
emailaddress.add ({set:{domain:'listen.example.de',localpart:'mailman-join',target:'xyz00-listen+mailman-join'}})<br />
emailaddress.add ({set:{domain:'listen.example.de',localpart:'mailman-leave',target:'xyz00-listen+mailman-leave'}})<br />
emailaddress.add ({set:{domain:'listen.example.de',localpart:'mailman-owner',target:'xyz00-listen+mailman-owner'}})<br />
emailaddress.add ({set:{domain:'listen.example.de',localpart:'mailman-request',target:'xyz00-listen+mailman-request'}})<br />
emailaddress.add ({set:{domain:'listen.example.de',localpart:'mailman-subscribe',target:'xyz00-listen+mailman-subscribe'}})<br />
emailaddress.add ({set:{domain:'listen.example.de',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 Mail an die Adresse mailman-subscribe@lists.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/createforwards mit folgendem Inhalt zu erstellen:<br />
<br />
#!/bin/sh<br />
# Add forward files for mailman lists.<br />
#<br />
if [ "$1" = "" ] ; then<br />
echo "Syntax: $0 listname\n" <br />
exit<br />
fi<br />
if [ "$2" != "" ] ; then<br />
echo "Syntax: $0 listname\n" <br />
exit<br />
fi<br />
if [ "`pwd`" != "`echo ~`" ] ; then<br />
echo "Run this script from your home directory.\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 />
Die Erweiterung dieses Skripts um die hsscript-Befehle wird dem Leser als Aufgabe überlassen.<br />
<br />
=== Administration ===<br />
<br />
Administriert werden Listen über http://lists.example.com/admin/<listenname> und entweder dem Listenpasswort oder dem Site-Passwort.<br />
<br />
Als erstes sollte man die Liste "mailman" selbst abonnieren. (http://lists.example.com/admin/mailman)<br />
<br />
Bis auf das Anwenden der sitelist.cfg werden auch alle weiteren Listen nach obigem Schema angelegt, oder (bis auf das anlegen der virtusertable Einträge und aliase) über das Mailman Webinterface.<br />
<br />
Das war's. Mailman ist jetzt fertig installiert und müsste sogar funktionieren ;)<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/lists.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@lists.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 lists.example.com sowohl als URL für das Webfrontend wie auch als Hostpart für Emailadressen verwendet. (Was für separate aufgeschaltete Domains wie z.B. lists.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 = 'lists.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 statt Paketadmin: https://lists.hostsharing.net/archiv/support/2009-June/019414.html<br><br />
Ältere Anleitung für Installation als Domain-Admin: <http://lists.hostsharing.net/archiv/support/2005-January/012426.html><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>Apc00https://wiki.hostsharing.net/index.php?title=Mailman_Installieren&diff=4833Mailman Installieren2019-03-13T16:36:08Z<p>Apc00: /* Einen User und eine Domain anlegen */</p>
<hr />
<div>Was noch jemand ergänzen müsste:<br />
* Eine generische virtuser/alias Konfiguration finden und dokumentieren. <br><br />
http://listes.rezo.net/how.php<br> http://www.gnu.org/software/mailman/mailman-install/mail-server.html<br />
<br />
* Skriptautomatisierung updaten <br> http://hs.andreasloesch.de/pac-mm-install<br />
<br />
<br />
== Mailman 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 />
Mailman kann vom Paketadmin (beipsielsweise "xyz00") oder von einem Paketuser (bspw. "xyz00-listen") installiert werden. Letzteres ist dringend empfohlen, denn 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.de 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.de/htdocs-ssl/.htaccess löschen:<br />
<br />
~$ echo "" > ~/doms/lists.example.de/htdocs-ssl/.htaccess<br />
<br />
Die Default-Subdomains www.* löschen:<br />
<br />
~$ rm -r doms/listen.example.de/subs/www/<br />
~$ rm -r doms/listen.example.de/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 Mailman 2 Versionen (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:<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:<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.de 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.de'<br />
DEFAULT_EMAIL_HOST = 'listen.example.de'<br />
DEFAULT_URL_HOST = 'listen.example.de'<br />
add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)<br />
add_virtualhost(zweite.listendomain.de, zweite.listendomain.de)<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:<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.de/cgi-ssl/mailman<br />
~$ cp mailman/cgi-bin/* doms/listen.example.de/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.de/cgi/mailman/*<br />
<br />
Bei der Installation als Paketadmin: <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.de/cgi-ssl<br />
~/doms/listen.example.de/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.de/htdocs-ssl<br />
~/doms/listen.example.de/htdocs-ssl$ ln -s ../../../mailman/icons<br />
<br />
oder<br />
<br />
~$ cp -R mailman/icons doms/lists.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.de/cgi-bin/mailman, sondern auch unter https://listen.example.de erreichbar ist.<br />
<br />
Dazu werden in ~/doms/listen.example.de/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 />
=== Email Adressen einrichten ===<br />
<br />
Sobald ein neuer Verteiler angelegt worden ist, sendet Mailman eine Mail an den dabei eingetragenen Listenadministrator. Diese 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 Mails an Mailman werden an erweiterte ''E-Mail-Adressen'' des Mailman-Users xyz00-listen geschickt. Diese Adressen haben die form xyz00-listen'''+'''<liste>[_funktion]. 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'' werden durch [https://doc.hostsharing.net/users/administration/hsadmin/index.html hsadmin (bzw. das Befehlszeielentool 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 Paßworts vom Paketadmin xyz00; dann können diese Befehle eingegeben werden:]<br />
emailaddress.add ({set:{domain:'listen.example.de',localpart:'mailman',target:'xyz00-listen+mailman'}})<br />
emailaddress.add ({set:{domain:'listen.example.de',localpart:'mailman-admin',target:'xyz00-listen+mailman-admin'}})<br />
emailaddress.add ({set:{domain:'listen.example.de',localpart:'mailman-bounces',target:'xyz00-listen+mailman-bounces'}})<br />
emailaddress.add ({set:{domain:'listen.example.de',localpart:'mailman-confirm',target:'xyz00-listen+mailman-confirm'}})<br />
emailaddress.add ({set:{domain:'listen.example.de',localpart:'mailman-join',target:'xyz00-listen+mailman-join'}})<br />
emailaddress.add ({set:{domain:'listen.example.de',localpart:'mailman-leave',target:'xyz00-listen+mailman-leave'}})<br />
emailaddress.add ({set:{domain:'listen.example.de',localpart:'mailman-owner',target:'xyz00-listen+mailman-owner'}})<br />
emailaddress.add ({set:{domain:'listen.example.de',localpart:'mailman-request',target:'xyz00-listen+mailman-request'}})<br />
emailaddress.add ({set:{domain:'listen.example.de',localpart:'mailman-subscribe',target:'xyz00-listen+mailman-subscribe'}})<br />
emailaddress.add ({set:{domain:'listen.example.de',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 Mail an die Adresse mailman-subscribe@lists.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/createforwards mit folgendem Inhalt zu erstellen:<br />
<br />
#!/bin/sh<br />
# Add forward files for mailman lists.<br />
#<br />
if [ "$1" = "" ] ; then<br />
echo "Syntax: $0 listname\n" <br />
exit<br />
fi<br />
if [ "$2" != "" ] ; then<br />
echo "Syntax: $0 listname\n" <br />
exit<br />
fi<br />
if [ "`pwd`" != "`echo ~`" ] ; then<br />
echo "Run this script from your home directory.\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 />
Die Erweiterung dieses Skripts um die hsscript-Befehle wird dem Leser als Aufgabe überlassen.<br />
<br />
=== Administration ===<br />
<br />
Administriert werden Listen über http://lists.example.com/admin/<listenname> und entweder dem Listenpasswort oder dem Site-Passwort.<br />
<br />
Als erstes sollte man die Liste "mailman" selbst abonnieren. (http://lists.example.com/admin/mailman)<br />
<br />
Bis auf das Anwenden der sitelist.cfg werden auch alle weiteren Listen nach obigem Schema angelegt, oder (bis auf das anlegen der virtusertable Einträge und aliase) über das Mailman Webinterface.<br />
<br />
Das war's. Mailman ist jetzt fertig installiert und müsste sogar funktionieren ;)<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/lists.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@lists.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 lists.example.com sowohl als URL für das Webfrontend wie auch als Hostpart für Emailadressen verwendet. (Was für separate aufgeschaltete Domains wie z.B. lists.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 = 'lists.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 statt Paketadmin: https://lists.hostsharing.net/archiv/support/2009-June/019414.html<br><br />
Ältere Anleitung für Installation als Domain-Admin: <http://lists.hostsharing.net/archiv/support/2005-January/012426.html><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>Apc00https://wiki.hostsharing.net/index.php?title=Mailman_Installieren&diff=4832Mailman Installieren2019-03-13T16:34:41Z<p>Apc00: /* Email Adressen einrichten */</p>
<hr />
<div>Was noch jemand ergänzen müsste:<br />
* Eine generische virtuser/alias Konfiguration finden und dokumentieren. <br><br />
http://listes.rezo.net/how.php<br> http://www.gnu.org/software/mailman/mailman-install/mail-server.html<br />
<br />
* Skriptautomatisierung updaten <br> http://hs.andreasloesch.de/pac-mm-install<br />
<br />
<br />
== Mailman 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 />
Mailman kann vom Paketadmin (beipsielsweise "xyz00") oder von einem Paketuser (bspw. "xyz00-listen") installiert werden. Letzteres ist dringend empfohlen, denn 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.de mit "Domain-User" xyz00-listen anlegen. Aus admin.hostsharing.net abmelden.<br />
<br />
Mit ssh an hostsharing.net als xyz00-listen anmelden. Die Redirect-Zeile aus ~/doms/listen.example.de/htdocs-ssl/.htaccess löschen:<br />
<br />
~$ echo "" > ~/doms/lists.example.de/htdocs-ssl/.htaccess<br />
<br />
Die Default-Subdomains www.* löschen:<br />
<br />
~$ rm -r doms/listen.example.de/subs/www/<br />
~$ rm -r doms/listen.example.de/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 Mailman 2 Versionen (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:<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:<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.de 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.de'<br />
DEFAULT_EMAIL_HOST = 'listen.example.de'<br />
DEFAULT_URL_HOST = 'listen.example.de'<br />
add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)<br />
add_virtualhost(zweite.listendomain.de, zweite.listendomain.de)<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:<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.de/cgi-ssl/mailman<br />
~$ cp mailman/cgi-bin/* doms/listen.example.de/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.de/cgi/mailman/*<br />
<br />
Bei der Installation als Paketadmin: <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.de/cgi-ssl<br />
~/doms/listen.example.de/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.de/htdocs-ssl<br />
~/doms/listen.example.de/htdocs-ssl$ ln -s ../../../mailman/icons<br />
<br />
oder<br />
<br />
~$ cp -R mailman/icons doms/lists.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.de/cgi-bin/mailman, sondern auch unter https://listen.example.de erreichbar ist.<br />
<br />
Dazu werden in ~/doms/listen.example.de/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 />
=== Email Adressen einrichten ===<br />
<br />
Sobald ein neuer Verteiler angelegt worden ist, sendet Mailman eine Mail an den dabei eingetragenen Listenadministrator. Diese 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 Mails an Mailman werden an erweiterte ''E-Mail-Adressen'' des Mailman-Users xyz00-listen geschickt. Diese Adressen haben die form xyz00-listen'''+'''<liste>[_funktion]. 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'' werden durch [https://doc.hostsharing.net/users/administration/hsadmin/index.html hsadmin (bzw. das Befehlszeielentool 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 Paßworts vom Paketadmin xyz00; dann können diese Befehle eingegeben werden:]<br />
emailaddress.add ({set:{domain:'listen.example.de',localpart:'mailman',target:'xyz00-listen+mailman'}})<br />
emailaddress.add ({set:{domain:'listen.example.de',localpart:'mailman-admin',target:'xyz00-listen+mailman-admin'}})<br />
emailaddress.add ({set:{domain:'listen.example.de',localpart:'mailman-bounces',target:'xyz00-listen+mailman-bounces'}})<br />
emailaddress.add ({set:{domain:'listen.example.de',localpart:'mailman-confirm',target:'xyz00-listen+mailman-confirm'}})<br />
emailaddress.add ({set:{domain:'listen.example.de',localpart:'mailman-join',target:'xyz00-listen+mailman-join'}})<br />
emailaddress.add ({set:{domain:'listen.example.de',localpart:'mailman-leave',target:'xyz00-listen+mailman-leave'}})<br />
emailaddress.add ({set:{domain:'listen.example.de',localpart:'mailman-owner',target:'xyz00-listen+mailman-owner'}})<br />
emailaddress.add ({set:{domain:'listen.example.de',localpart:'mailman-request',target:'xyz00-listen+mailman-request'}})<br />
emailaddress.add ({set:{domain:'listen.example.de',localpart:'mailman-subscribe',target:'xyz00-listen+mailman-subscribe'}})<br />
emailaddress.add ({set:{domain:'listen.example.de',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 Mail an die Adresse mailman-subscribe@lists.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/createforwards mit folgendem Inhalt zu erstellen:<br />
<br />
#!/bin/sh<br />
# Add forward files for mailman lists.<br />
#<br />
if [ "$1" = "" ] ; then<br />
echo "Syntax: $0 listname\n" <br />
exit<br />
fi<br />
if [ "$2" != "" ] ; then<br />
echo "Syntax: $0 listname\n" <br />
exit<br />
fi<br />
if [ "`pwd`" != "`echo ~`" ] ; then<br />
echo "Run this script from your home directory.\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 />
Die Erweiterung dieses Skripts um die hsscript-Befehle wird dem Leser als Aufgabe überlassen.<br />
<br />
=== Administration ===<br />
<br />
Administriert werden Listen über http://lists.example.com/admin/<listenname> und entweder dem Listenpasswort oder dem Site-Passwort.<br />
<br />
Als erstes sollte man die Liste "mailman" selbst abonnieren. (http://lists.example.com/admin/mailman)<br />
<br />
Bis auf das Anwenden der sitelist.cfg werden auch alle weiteren Listen nach obigem Schema angelegt, oder (bis auf das anlegen der virtusertable Einträge und aliase) über das Mailman Webinterface.<br />
<br />
Das war's. Mailman ist jetzt fertig installiert und müsste sogar funktionieren ;)<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/lists.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@lists.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 lists.example.com sowohl als URL für das Webfrontend wie auch als Hostpart für Emailadressen verwendet. (Was für separate aufgeschaltete Domains wie z.B. lists.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 = 'lists.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 statt Paketadmin: https://lists.hostsharing.net/archiv/support/2009-June/019414.html<br><br />
Ältere Anleitung für Installation als Domain-Admin: <http://lists.hostsharing.net/archiv/support/2005-January/012426.html><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>Apc00https://wiki.hostsharing.net/index.php?title=Mailman_Installieren&diff=4831Mailman Installieren2019-03-13T16:29:11Z<p>Apc00: /* Email Adressen einrichten */</p>
<hr />
<div>Was noch jemand ergänzen müsste:<br />
* Eine generische virtuser/alias Konfiguration finden und dokumentieren. <br><br />
http://listes.rezo.net/how.php<br> http://www.gnu.org/software/mailman/mailman-install/mail-server.html<br />
<br />
* Skriptautomatisierung updaten <br> http://hs.andreasloesch.de/pac-mm-install<br />
<br />
<br />
== Mailman 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 />
Mailman kann vom Paketadmin (beipsielsweise "xyz00") oder von einem Paketuser (bspw. "xyz00-listen") installiert werden. Letzteres ist dringend empfohlen, denn 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.de mit "Domain-User" xyz00-listen anlegen. Aus admin.hostsharing.net abmelden.<br />
<br />
Mit ssh an hostsharing.net als xyz00-listen anmelden. Die Redirect-Zeile aus ~/doms/listen.example.de/htdocs-ssl/.htaccess löschen:<br />
<br />
~$ echo "" > ~/doms/lists.example.de/htdocs-ssl/.htaccess<br />
<br />
Die Default-Subdomains www.* löschen:<br />
<br />
~$ rm -r doms/listen.example.de/subs/www/<br />
~$ rm -r doms/listen.example.de/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 Mailman 2 Versionen (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:<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:<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.de 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.de'<br />
DEFAULT_EMAIL_HOST = 'listen.example.de'<br />
DEFAULT_URL_HOST = 'listen.example.de'<br />
add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)<br />
add_virtualhost(zweite.listendomain.de, zweite.listendomain.de)<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:<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.de/cgi-ssl/mailman<br />
~$ cp mailman/cgi-bin/* doms/listen.example.de/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.de/cgi/mailman/*<br />
<br />
Bei der Installation als Paketadmin: <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.de/cgi-ssl<br />
~/doms/listen.example.de/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.de/htdocs-ssl<br />
~/doms/listen.example.de/htdocs-ssl$ ln -s ../../../mailman/icons<br />
<br />
oder<br />
<br />
~$ cp -R mailman/icons doms/lists.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.de/cgi-bin/mailman, sondern auch unter https://listen.example.de erreichbar ist.<br />
<br />
Dazu werden in ~/doms/listen.example.de/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 />
=== Email Adressen einrichten ===<br />
<br />
Sobald ein neuer Verteiler angelegt worden ist, sendet Mailman eine Mail an den dabei eingetragenen Listenadministrator. Diese 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 Mails an Mailman werden an erweiterte ''E-Mail-Adressen'' des Mailman-Users xyz00-listen geschickt. Diese Adressen haben die form xyz00-listen'''+'''<liste>[_funktion]. 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'' werden durch [https://doc.hostsharing.net/users/administration/hsadmin/index.html hsadmin (bzw. das Befehlszeielentool 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 Paßworts vom Paketadmin xyz00; dann können diese Befehle eingegeben werden:]<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman',target:'xyz00-listen+mailman'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-admin',target:'xyz00-listen+mailman-admin'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-bounces',target:'xyz00-listen+mailman-bounces'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-confirm',target:'xyz00-listen+mailman-confirm'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-join',target:'xyz00-listen+mailman-join'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-leave',target:'xyz00-listen+mailman-leave'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-owner',target:'xyz00-listen+mailman-owner'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-request',target:'xyz00-listen+mailman-request'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-subscribe',target:'xyz00-listen+mailman-subscribe'}})<br />
emailaddress.add ({set:{domain:'lists.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 Mail an die Adresse mailman-subscribe@lists.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/createforwards mit folgendem Inhalt zu erstellen:<br />
<br />
#!/bin/sh<br />
# Add forward files for mailman lists.<br />
#<br />
if [ "$1" = "" ] ; then<br />
echo "Syntax: $0 listname\n" <br />
exit<br />
fi<br />
if [ "$2" != "" ] ; then<br />
echo "Syntax: $0 listname\n" <br />
exit<br />
fi<br />
if [ "`pwd`" != "`echo ~`" ] ; then<br />
echo "Run this script from your home directory.\n" <br />
exit<br />
fi<br />
echo "\"|/home/pacs/apc00/users/lists/mailman/mail/mailman post $1\"" > .forward+$1<br />
echo "\"|/home/pacs/apc00/users/lists/mailman/mail/mailman admin $1\"" > .forward+$1-admin<br />
echo "\"|/home/pacs/apc00/users/lists/mailman/mail/mailman bounces $1\"" > .forward+$1-bounces<br />
echo "\"|/home/pacs/apc00/users/lists/mailman/mail/mailman confirm $1\"" > .forward+$1-confirm<br />
echo "\"|/home/pacs/apc00/users/lists/mailman/mail/mailman join $1\"" > .forward+$1-join<br />
echo "\"|/home/pacs/apc00/users/lists/mailman/mail/mailman leave $1\"" > .forward+$1-leave<br />
echo "\"|/home/pacs/apc00/users/lists/mailman/mail/mailman owner $1\"" > .forward+$1-owner<br />
echo "\"|/home/pacs/apc00/users/lists/mailman/mail/mailman request $1\"" > .forward+$1-request<br />
echo "\"|/home/pacs/apc00/users/lists/mailman/mail/mailman subscribe $1\"" > .forward+$1-subscribe<br />
echo "\"|/home/pacs/apc00/users/lists/mailman/mail/mailman unsubscribe $1\"" > .forward+$1-unsubscribe<br />
exit<br />
<br />
=== Administration ===<br />
<br />
Administriert werden Listen über http://lists.example.com/admin/<listenname> und entweder dem Listenpasswort oder dem Site-Passwort.<br />
<br />
Als erstes sollte man die Liste "mailman" selbst abonnieren. (http://lists.example.com/admin/mailman)<br />
<br />
Bis auf das Anwenden der sitelist.cfg werden auch alle weiteren Listen nach obigem Schema angelegt, oder (bis auf das anlegen der virtusertable Einträge und aliase) über das Mailman Webinterface.<br />
<br />
Das war's. Mailman ist jetzt fertig installiert und müsste sogar funktionieren ;)<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/lists.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@lists.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 lists.example.com sowohl als URL für das Webfrontend wie auch als Hostpart für Emailadressen verwendet. (Was für separate aufgeschaltete Domains wie z.B. lists.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 = 'lists.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 statt Paketadmin: https://lists.hostsharing.net/archiv/support/2009-June/019414.html<br><br />
Ältere Anleitung für Installation als Domain-Admin: <http://lists.hostsharing.net/archiv/support/2005-January/012426.html><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>Apc00https://wiki.hostsharing.net/index.php?title=Autorenportal&diff=4828Autorenportal2019-03-08T15:46:02Z<p>Apc00: /* Für den Leser schreiben! */</p>
<hr />
<div>Das Hostsharing-Wiki ist ein gemeinsames Projekt der Hostsharing-Mitglieder, in dem wir die Dokumentation der Dienste von Hostsharing überarbeiten und auf den aktuellen Stand bringen möchten. Auf dieser Seite findest du Informationen dazu, wie du dich daran beteiligen kannst.<br />
<br />
== Erste Schritte ==<br />
<br />
'''Anmelden'''<br />
<br />
Das Wiki verwendet den Single-Sign-On-Dienst von Hostsharing, sodass Du Dich im Wiki mit jedem gültigen [[User]] (Benutzernamen) eines Servers von Hostsharing anmelden kannst. Du kannst Dir natürlich für die Nutzung des Wikis einen eigenen [[User]] in einem Deiner Pakete anlegen, zum Beispiel xyz00-wiki oder xyz00-hsdoku.<br />
<br />
'''Benutzereinstellungen'''<br />
<br />
Nachdem du dich im Wiki angemeldet hast, ist es sinnvoll, wenn du zunächst deine Benutzereinstellungen anpasst (der Link [[Spezial:Einstellungen | Einstellungen]] - nur sichtbar, wenn Du angemeldet bist). Mindestens deine E-Mail-Adresse solltest du eintragen, denn dann kannst du Seiten im Wiki beobachten und Nachrichten bekommen, wenn eine von dir beobachtete Seite geändert wurde.<br />
<br />
Du solltest dich außerdem auf der Hostsharing-Mailingliste (nicht öffentliche Liste) [https://lists.hostsharing.net/mailman/listinfo/website/ website@hostsharing.net] anmelden. Dort diskutieren wir über die Weiterentwicklung der Dokumentation.<br />
<br />
== Wo ist Arbeit nötig? ==<br />
<br />
<div style="margin-left:2em;font-style:italic">Die wichtigsten Links: [[:Kategorie:Baustelle|Baustelle]]n, [[Hostsharing_Wiki:Wunschliste Installationsanleitungen|Wunschliste Installationsanleitungen]], [[Ideen für das Wiki]], [[Fehler im Wiki]]</div><br />
<br />
Ganz konkret kannst du zum Beispiel schauen, welche Seiten hier im Wiki als [[:Kategorie:Baustelle|Baustelle]] gekennzeichnet sind und diese überarbeiten. Oder du erstellst eine ganz neue Dokumentation zu einem Thema.<br />
<br />
Natürlich kannst du auch als Benutzer die Dokumentation lesen und in der Diskussion der entsprechenden Seite darauf hinweisen, wo aus deiner Sicht Verbesserungen notwendig sind. Um eine Seite als Baustelle zu kennzeichnen, trage einfach folgendes ganz am Anfang der Seite ein:<br />
<br />
<nowiki>{{Baustelle}}</nowiki><br />
<br />
Am Anfang der Seite erscheint dann ein entsprechender Hinweis und die Seite wird in die [[:Kategorie:Baustelle|Liste der Baustellen]] aufgenommen.<br />
<br />
== Konventionen ==<br />
<br />
Wenn du an der Dokumentation arbeitest, solltest du unsere [[Hilfe:Hostsharing_Wiki_Konventionen|Konventionen]] und [[Hilfe:Guter_Stil|Hinweise zu gutem Stil]] beachten.<br />
<br />
== Umgang mit der Wiki-Software ==<br />
<br />
Wir verwenden als Software [http://www.mediawiki.org/ MediaWiki]. Nachfolgend einige Links auf Hinweise dazu, wie du im Wiki Texte formatierst und Links anlegst. Gefahrlos ausprobieren kannst du die Wiki-Funktionen auf der Seite [[Sandkasten]], diese ist explizit zum Experimentieren gedacht.<br />
<br />
* [[Hilfe:Textgestaltung|Textformatierung im Wiki]]<br />
* [[Hilfe:Link|Links anlegen]]<br />
<br />
== Für den Leser schreiben! ==<br />
<br />
Entgegen der langjährigen Tradition in Akademie und Technik, schreiben wir hier vor allem für diejenigen Leser*innen, die noch nicht das wissen, was wir als Autoren wissen. Deshalb immer beim Schreiben von Dokumentation daran denken, daß der Leser womöglich zum allerersten Mal eine Einrichtung vornehmen will, die uns quasi selbstverständlich ist. Das bedeutet, daß die Anleitungen in diesem Wiki mit '''genauer Terminologie''' und ohne allzuviele Abkürzungen '''ausführlich''' sagen sollen, was der Leser machen muß.<br />
<br />
*Falsch: "Dann über die Shell die entsprechenden Rewrite-Zeilen in die .htaccess einfügen."<br />
*Besser: "Dann mit ssh als Paketuser xyz00-username an example.com anmelden und folgende Zeilen in die Datei ~/doms/example.com/htdocs-ssl/.htaccess einfügen: ..."<br />
<br />
----<br />
[[Kategorie:Hilfe]]<br />
[[Kategorie:Hostsharing Wiki]]</div>Apc00https://wiki.hostsharing.net/index.php?title=Autorenportal&diff=4827Autorenportal2019-03-08T15:45:19Z<p>Apc00: </p>
<hr />
<div>Das Hostsharing-Wiki ist ein gemeinsames Projekt der Hostsharing-Mitglieder, in dem wir die Dokumentation der Dienste von Hostsharing überarbeiten und auf den aktuellen Stand bringen möchten. Auf dieser Seite findest du Informationen dazu, wie du dich daran beteiligen kannst.<br />
<br />
== Erste Schritte ==<br />
<br />
'''Anmelden'''<br />
<br />
Das Wiki verwendet den Single-Sign-On-Dienst von Hostsharing, sodass Du Dich im Wiki mit jedem gültigen [[User]] (Benutzernamen) eines Servers von Hostsharing anmelden kannst. Du kannst Dir natürlich für die Nutzung des Wikis einen eigenen [[User]] in einem Deiner Pakete anlegen, zum Beispiel xyz00-wiki oder xyz00-hsdoku.<br />
<br />
'''Benutzereinstellungen'''<br />
<br />
Nachdem du dich im Wiki angemeldet hast, ist es sinnvoll, wenn du zunächst deine Benutzereinstellungen anpasst (der Link [[Spezial:Einstellungen | Einstellungen]] - nur sichtbar, wenn Du angemeldet bist). Mindestens deine E-Mail-Adresse solltest du eintragen, denn dann kannst du Seiten im Wiki beobachten und Nachrichten bekommen, wenn eine von dir beobachtete Seite geändert wurde.<br />
<br />
Du solltest dich außerdem auf der Hostsharing-Mailingliste (nicht öffentliche Liste) [https://lists.hostsharing.net/mailman/listinfo/website/ website@hostsharing.net] anmelden. Dort diskutieren wir über die Weiterentwicklung der Dokumentation.<br />
<br />
== Wo ist Arbeit nötig? ==<br />
<br />
<div style="margin-left:2em;font-style:italic">Die wichtigsten Links: [[:Kategorie:Baustelle|Baustelle]]n, [[Hostsharing_Wiki:Wunschliste Installationsanleitungen|Wunschliste Installationsanleitungen]], [[Ideen für das Wiki]], [[Fehler im Wiki]]</div><br />
<br />
Ganz konkret kannst du zum Beispiel schauen, welche Seiten hier im Wiki als [[:Kategorie:Baustelle|Baustelle]] gekennzeichnet sind und diese überarbeiten. Oder du erstellst eine ganz neue Dokumentation zu einem Thema.<br />
<br />
Natürlich kannst du auch als Benutzer die Dokumentation lesen und in der Diskussion der entsprechenden Seite darauf hinweisen, wo aus deiner Sicht Verbesserungen notwendig sind. Um eine Seite als Baustelle zu kennzeichnen, trage einfach folgendes ganz am Anfang der Seite ein:<br />
<br />
<nowiki>{{Baustelle}}</nowiki><br />
<br />
Am Anfang der Seite erscheint dann ein entsprechender Hinweis und die Seite wird in die [[:Kategorie:Baustelle|Liste der Baustellen]] aufgenommen.<br />
<br />
== Konventionen ==<br />
<br />
Wenn du an der Dokumentation arbeitest, solltest du unsere [[Hilfe:Hostsharing_Wiki_Konventionen|Konventionen]] und [[Hilfe:Guter_Stil|Hinweise zu gutem Stil]] beachten.<br />
<br />
== Umgang mit der Wiki-Software ==<br />
<br />
Wir verwenden als Software [http://www.mediawiki.org/ MediaWiki]. Nachfolgend einige Links auf Hinweise dazu, wie du im Wiki Texte formatierst und Links anlegst. Gefahrlos ausprobieren kannst du die Wiki-Funktionen auf der Seite [[Sandkasten]], diese ist explizit zum Experimentieren gedacht.<br />
<br />
* [[Hilfe:Textgestaltung|Textformatierung im Wiki]]<br />
* [[Hilfe:Link|Links anlegen]]<br />
<br />
== Für den Leser schreiben! ==<br />
<br />
Entgegen der langjährigen Tradition in Akademie und Technik, schreiben wir hier vor allem für diejenigen Leser*innen, die noch nicht das wissen, was wir als Autoren wissen. Deshalb immer beim Schreiben von Dokumentation daran denken, daß der Leser womöglich zum allerersten Mal eine Einrichtung vornehmen wollen, die uns quasi selbstverständlich ist. Das bedeutet, daß die Anleitungen in diesem Wiki mit '''genauer Terminologie''' und ohne allzuviele Abkürzungen '''ausführlich''' sagen sollen, was der Leser machen muß.<br />
<br />
*Falsch: "Dann über die Shell die entsprechenden Rewrite-Zeilen in die .htaccess einfügen."<br />
*Besser: "Dann mit ssh als Paketuser xyz00-username an example.com anmelden und folgende Zeilen in die Datei ~/doms/example.com/htdocs-ssl/.htaccess einfügen: ..."<br />
<br />
----<br />
[[Kategorie:Hilfe]]<br />
[[Kategorie:Hostsharing Wiki]]</div>Apc00https://wiki.hostsharing.net/index.php?title=E-Mail&diff=4826E-Mail2019-03-08T15:08:28Z<p>Apc00: /* Aressierung und Weiterleitungen */</p>
<hr />
<div>{{HSDoku-Links}}<br />
<br />
{{Baustelle}}<br />
<br />
{{Kerndoku|https://doc.hostsharing.net/users/administration/email/index.html}}<br />
<br />
Die (auch das) '''E-Mail''' (kurz ''Mail'', von englisch ''electronic mail'': „elektronische Post“ oder „elektronischer Brief“), manchmal als '''E-Post''' oder '''E-Brief''' bezeichnet, ist eine auf elektronischem Weg in [[Rechnernetz|Computernetzwerken]] übertragene [[Nachricht]].<br />
<br />
E-Mail wird – noch vor dem [[World Wide Web]] – als wichtigster und meistgenutzter Dienst des [[Internet]]s angesehen.<br />
<br />
<br />
== Weitergehende Konfigurationsmöglichkeiten ==<br />
<br />
* Es können [[Mailinglisten]] eingerichtet werden.<br />
<br />
* IMAP Konten lassen sich mit [[ImapCopy]] zu HS kopieren.<br />
<br />
== E-Mail-Infrastruktur ==<br />
<br />
Wir nutzen [http://www.postfix.org/ Postfix] als [[Mail Transfer Agent]](MTA) bzw. Mailserver. Diese Software dient dazu, eingehende Mails den lokalen Usern des Servers zuzuordnen, an interne oder externe Server zuzustellen.<br />
<br />
E-Mails werden vom Mailsystem im Verzeichnis Maildir des jeweiligen User-Accounts abgelegt (der Name ist systemweit eingestellt und kann nicht verändert werden). <br />
<br />
Damit sind die Mails im normalen Backup enthalten und gehen auch in die Quota des Paketes ein. Das Verzeichnis wird automatisch angelegt, wenn die erste E-Mail dort abgelegt wird. <br />
<br />
Ist das Verzeichnis Maildir nicht angelegt, liefern E-Mail-Clients oder Webmail-Clients aufgrund des fehlenden Verzeichnisses eine Fehlermeldung. <br />
Dies kann verhindert werden, indem auf der Shell in dem entsprechenden User-Account folgender Befehl ausführt wird:<br />
<br />
<pre> maildirmake Maildir</pre><br />
<br />
== Aressierung und Weiterleitungen ==<br />
<br />
Hostsharing unterschedet zwischen E-Mail-Adresse und Mailbox.<br />
<br />
Eine E-Mail-Adresse gibt an, wie eine eingehende Nachricht auszuliefern ist.<br />
<br />
Eine Mailbox ist ein Ort, wo erhaltene E-Mails lagern, bis ein User sie lesen will,<br />
typischerweise indem er mittels seiner Client-Software die Mails mit IMAP oder POP3<br />
abholt und anzeigt.<br />
<br />
In Hostsharing hat jeder User, ob Paketadmin oder Paketuser, eine Mailbox. E-Mail-Adressen<br />
können unabhängig von tatsächlichen Usern eingerichtet werden.<br />
<br />
=== E-Mail-Adressen ===<br />
<br />
Eine E-Mail-Adresse ist in Hostsharing eine<br />
Kennung der üblichen Form <code>userimbreitestensinn@domain</code>,<br />
zusammen mit einer Zielangabe, das heißt, mit der Angabe, wohin eine mit dieser<br />
Kennung adressierten E-Mail geliefert<br />
werden soll. Bei Einrichtung einer E-Mail-Adresse in Hostsharing kann ein Ziel eine Mailbox<br />
sein, oder aber eine andere E-Mail-Adresse (mit einer beliebigen Domain, ob bei Hostsharing<br />
gehostet oder extern). Eine E-Mail-Adresse kann mehrere Ziele haben: dann wird die<br />
eingehende Mail zur Auslieferung vervielfacht.<br />
<br />
Es werden n:m-Verknüpfungen zwischen E-Mail-Adressen und Mailboxen ermöglicht. Das heißt,<br />
mehrere E-Mail-Adressen können dieselbe Mailbox als Ziel haben, und eine E-Mail-Adresse<br />
kann mehrere Mailboxen als Ziele haben.<br />
<br />
=== E-Mail-Aliases ===<br />
<br />
Ein E-Mail-Alias ist, ähnlich wie eine E-Mail-Adresse, mit einer Angabe verbunden, wie<br />
mit einer entsprechend adressierten E-Mail bei Eingang zu verfahren ist. Ein E-Mail-Alias<br />
in Hostsharing ist nicht an eine bestimmte Domain gebunden, wohl aber an ein bestimmtes<br />
Paket. Daher beginnen alle Aliase mit einem Pakennamen (plus Bindestrich) in der Form xyz00-... (Damit kann ein Alias gleichlautend mit der Mailbox eines Paketusers sein: in diesem Fall hat der Alias<br />
Vorrang; eine so geleitete Mail wird nicht in die Mailbox geliefert, sondern entsprechend dem zum Alias gehörenden Ziel.)<br />
<br />
Das Ziel eines E-Mail-Alias ist <br />
allerdings flexibler als das Ziel einer E-Mail-Adresse, und erlaubt beispielsweise, eingehende<br />
Mails durch Programme verarbeiten zu lassen. Damit kann man unter anderem Mailverteiler flexibel definieren.<br />
<br />
Insgesamt kann man damit komplex E-Mail-Setups konfigurieren. E-Mail-Aliases werden deshalb als<br />
Werkzeug für Administratoren angeboten; der Endverbraucher wird in der Regel keine Aliases benötigen.<br />
<br />
=== Formal ===<br />
<br />
==== E-Mail-Adresse ====<br />
:Form = <code>localpart@domainpart</code><br /><br />
:Beispiel = username@example.com<br /><br />
:Ziel = Liste von (mehreren):<br />
:* E-Mail-Adresse (intern oder extern)<br />
:* E-Mail-Alias<br />
:* Mailbox<br />
<br />
==== E-Mail-Alias ====<br />
:Form = <code>xyz00-aliasname</code><br /><br />
:Ziel = Liste von (mehreren):<br />
:* E-Mail-Adresse (intern oder extern)<br />
:* E-Mail-Alias<br />
:* Mailbox<br />
:* spezielle Funktion (Pipe, dateibasierter Verteiler, ...)<br />
<br />
==== Mailbox ====<br />
:Form = <code>xyz00</code><br /><br />
:Form = <code>xyz00-username</code><br /><br />
:*kann per [[POP3]] und/oder [[IMAP]] abgerufen werden<br />
:*kann per [[Sieve]] gefiltert werden<br />
:*kann durch .forward-Datei(en) umgelenkt werden<br />
<br />
=== Bemerkungen ===<br />
<br />
Wenn E-Mail-Alias gleich wie eine Mailbox-Bezeichnung lautet,<br />
hat der Alias Vorrang. Um ankommende E-Mails dennoch in die Mailbox liefern zu lassen, <br />
kann als Ziel eines Aliases die Mailbox-Bezeichnung mit vorangestelltem Backslash<br />
angegeben werden (z. B. "\xyz00-username").<br />
<br />
== Weiterführende Links ==<br />
<br />
[[HS-Mailrouting]]<br />
<br />
----<br />
[[Kategorie:HSDoku]]<br />
[[Kategorie:E-Mail]]<br />
[[Kategorie:Glossar]]</div>Apc00https://wiki.hostsharing.net/index.php?title=Mailman_Installieren&diff=4825Mailman Installieren2019-03-07T15:42:04Z<p>Apc00: /* Mailinglisten einrichten */</p>
<hr />
<div>Was noch jemand ergänzen müsste:<br />
* Eine generische virtuser/alias Konfiguration finden und dokumentieren. <br><br />
http://listes.rezo.net/how.php<br> http://www.gnu.org/software/mailman/mailman-install/mail-server.html<br />
<br />
* Skriptautomatisierung updaten <br> http://hs.andreasloesch.de/pac-mm-install<br />
<br />
<br />
== Mailman 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 />
Mailman kann vom Paketadmin (beipsielsweise "xyz00") oder von einem Paketuser (bspw. "xyz00-listen") installiert werden. Letzteres ist dringend empfohlen, denn 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.de mit "Domain-User" xyz00-listen anlegen. Aus admin.hostsharing.net abmelden.<br />
<br />
Mit ssh an hostsharing.net als xyz00-listen anmelden. Die Redirect-Zeile aus ~/doms/listen.example.de/htdocs-ssl/.htaccess löschen:<br />
<br />
~$ echo "" > ~/doms/lists.example.de/htdocs-ssl/.htaccess<br />
<br />
Die Default-Subdomains www.* löschen:<br />
<br />
~$ rm -r doms/listen.example.de/subs/www/<br />
~$ rm -r doms/listen.example.de/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 Mailman 2 Versionen (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:<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:<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.de 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.de'<br />
DEFAULT_EMAIL_HOST = 'listen.example.de'<br />
DEFAULT_URL_HOST = 'listen.example.de'<br />
add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)<br />
add_virtualhost(zweite.listendomain.de, zweite.listendomain.de)<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:<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.de/cgi-ssl/mailman<br />
~$ cp mailman/cgi-bin/* doms/listen.example.de/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.de/cgi/mailman/*<br />
<br />
Bei der Installation als Paketadmin: <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.de/cgi-ssl<br />
~/doms/listen.example.de/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.de/htdocs-ssl<br />
~/doms/listen.example.de/htdocs-ssl$ ln -s ../../../mailman/icons<br />
<br />
oder<br />
<br />
~$ cp -R mailman/icons doms/lists.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.de/cgi-bin/mailman, sondern auch unter https://listen.example.de erreichbar ist.<br />
<br />
Dazu werden in ~/doms/listen.example.de/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 />
=== Email Adressen einrichten ===<br />
<br />
Sobald ein neuer Verteiler angelegt worden ist, sendet Mailman eine Mail an den dabei eingetragenen Listenadministrator. Diese 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 Mails an Mailman werden an erweiterte ''E-Mail-Adressen'' des Mailman-Users xyz00-listen geschickt. Diese Adressen haben die form xyz00-listen'''+'''<liste>[_funktion]. 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 />
Die ''E-Mail-Adressen'' werden durch hsadmin (bzw. das Befehlszeielentool hsscript) eingerichtet; die ''.forward-Dateien'' werden durch Shell-Befehle angelegt.<br />
<br />
<!-- TC continue rewrite from here --><br />
Bei der Installation als Paketuser erfolgt die Einrichtung der Emailadressen per hsadmin und .forward Dateien.<br />
Anlegen mittels [[hsadmin|hsadmin CLI]]: [https://doc.hostsharing.net/users/administration/hsadmin/index.html]<br />
<br />
Beispiel für lists.example.com und Paketuser xyz00-listen.<br />
<br />
A) virtusertable:<br />
hsscript -u xyz00 -i<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman',target:'xyz00-listen+mailman'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-admin',target:'xyz00-listen+mailman-admin'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-bounces',target:'xyz00-listen+mailman-bounces'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-confirm',target:'xyz00-listen+mailman-confirm'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-join',target:'xyz00-listen+mailman-join'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-leave',target:'xyz00-listen+mailman-leave'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-owner',target:'xyz00-listen+mailman-owner'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-request',target:'xyz00-listen+mailman-request'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-subscribe',target:'xyz00-listen+mailman-subscribe'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-unsubscribe',target:'xyz00-listen+mailman-unsubscribe'}})<br />
<br />
Im Homeverzeichnis des Users xyz00-listen werden anschließend entsprechende .forward-Dateien angelegt. Die Dateinamen und Inhalte dieser Dateien definieren den Aufruf von Mailman und die Aktion, die das Programm ausführen soll. Zum Beispiel wird die .forward-Datei '''.forward+mailman''' verwendet, wenn die Adresse mailman@lists.example.com eine Mail erhält. In der .forward-Datei steht nun der Aufruf mit dem Programm, an das die Mail übergeben wird, die gewünschte Aktion und der Namen der Liste:<br />
<br />
/home/pacs/xyz00/users/listen/mailman/mail/mailman [Aktion] [Listenname]<br />
<br />
So wird das definiert für alle Aktionen für die Liste '''mailman'''.<br />
<br />
B) .forward Dateien:<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 />
=== Administration ===<br />
<br />
Administriert werden Listen über http://lists.example.com/admin/<listenname> und entweder dem Listenpasswort oder dem Site-Passwort.<br />
<br />
Als erstes sollte man die Liste "mailman" selbst abonnieren. (http://lists.example.com/admin/mailman)<br />
<br />
Bis auf das Anwenden der sitelist.cfg werden auch alle weiteren Listen nach obigem Schema angelegt, oder (bis auf das anlegen der virtusertable Einträge und aliase) über das Mailman Webinterface.<br />
<br />
Das war's. Mailman ist jetzt fertig installiert und müsste sogar funktionieren ;)<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/lists.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@lists.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 lists.example.com sowohl als URL für das Webfrontend wie auch als Hostpart für Emailadressen verwendet. (Was für separate aufgeschaltete Domains wie z.B. lists.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 = 'lists.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 statt Paketadmin: https://lists.hostsharing.net/archiv/support/2009-June/019414.html<br><br />
Ältere Anleitung für Installation als Domain-Admin: <http://lists.hostsharing.net/archiv/support/2005-January/012426.html><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>Apc00https://wiki.hostsharing.net/index.php?title=Mailman_Installieren&diff=4824Mailman Installieren2019-03-07T15:02:09Z<p>Apc00: /* Cronjobs einrichten */</p>
<hr />
<div>Was noch jemand ergänzen müsste:<br />
* Eine generische virtuser/alias Konfiguration finden und dokumentieren. <br><br />
http://listes.rezo.net/how.php<br> http://www.gnu.org/software/mailman/mailman-install/mail-server.html<br />
<br />
* Skriptautomatisierung updaten <br> http://hs.andreasloesch.de/pac-mm-install<br />
<br />
<br />
== Mailman 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 />
Mailman kann vom Paketadmin (beipsielsweise "xyz00") oder von einem Paketuser (bspw. "xyz00-listen") installiert werden. Letzteres ist dringend empfohlen, denn 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.de mit "Domain-User" xyz00-listen anlegen. Aus admin.hostsharing.net abmelden.<br />
<br />
Mit ssh an hostsharing.net als xyz00-listen anmelden. Die Redirect-Zeile aus ~/doms/listen.example.de/htdocs-ssl/.htaccess löschen:<br />
<br />
~$ echo "" > ~/doms/lists.example.de/htdocs-ssl/.htaccess<br />
<br />
Die Default-Subdomains www.* löschen:<br />
<br />
~$ rm -r doms/listen.example.de/subs/www/<br />
~$ rm -r doms/listen.example.de/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 Mailman 2 Versionen (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:<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:<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.de 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.de'<br />
DEFAULT_EMAIL_HOST = 'listen.example.de'<br />
DEFAULT_URL_HOST = 'listen.example.de'<br />
add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)<br />
add_virtualhost(zweite.listendomain.de, zweite.listendomain.de)<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:<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.de/cgi-ssl/mailman<br />
~$ cp mailman/cgi-bin/* doms/listen.example.de/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.de/cgi/mailman/*<br />
<br />
Bei der Installation als Paketadmin: <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.de/cgi-ssl<br />
~/doms/listen.example.de/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.de/htdocs-ssl<br />
~/doms/listen.example.de/htdocs-ssl$ ln -s ../../../mailman/icons<br />
<br />
oder<br />
<br />
~$ cp -R mailman/icons doms/lists.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.de/cgi-bin/mailman, sondern auch unter https://listen.example.de erreichbar ist.<br />
<br />
Dazu werden in ~/doms/listen.example.de/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 />
=== Als erste Liste die "mailman" "site list" einrichten ===<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 />
Neue Liste anlegen:<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 />
Nur für die "mailman site list": Konfigurationsvorgaben laden.<br />
<br />
~$ mailman/bin/config_list -i ~/mailman/var/data/sitelist.cfg mailman<br />
<br />
Bei der Installation als Paketadmin:<br />
~$ mailman/bin/config_list -i ~/var/mailman/data/sitelist.cfg mailman<br />
<br />
(Diese Konfigurationsdatei nicht auf eigene Listen anwenden.)<br />
<br />
=== Email Adressen einrichten === <br />
<br />
Bei der Installation als Paketuser erfolgt die Einrichtung der Emailadressen per hsadmin (virtusertable) und .forward Dateien.<br />
Anlegen mittels [[hsadmin|hsadmin CLI]]: [https://doc.hostsharing.net/users/administration/hsadmin/index.html]<br />
<br />
Beispiel für lists.example.com und Paketuser xyz00-listen.<br />
<br />
A) virtusertable:<br />
hsscript -u xyz00 -i<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman',target:'xyz00-listen+mailman'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-admin',target:'xyz00-listen+mailman-admin'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-bounces',target:'xyz00-listen+mailman-bounces'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-confirm',target:'xyz00-listen+mailman-confirm'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-join',target:'xyz00-listen+mailman-join'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-leave',target:'xyz00-listen+mailman-leave'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-owner',target:'xyz00-listen+mailman-owner'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-request',target:'xyz00-listen+mailman-request'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-subscribe',target:'xyz00-listen+mailman-subscribe'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-unsubscribe',target:'xyz00-listen+mailman-unsubscribe'}})<br />
<br />
Im Homeverzeichnis des Users xyz00-listen werden anschließend entsprechende .forward-Dateien angelegt. Die Dateinamen und Inhalte dieser Dateien definieren den Aufruf von Mailman und die Aktion, die das Programm ausführen soll. Zum Beispiel wird die .forward-Datei '''.forward+mailman''' verwendet, wenn die Adresse mailman@lists.example.com eine Mail erhält. In der .forward-Datei steht nun der Aufruf mit dem Programm, an das die Mail übergeben wird, die gewünschte Aktion und der Namen der Liste:<br />
<br />
/home/pacs/xyz00/users/listen/mailman/mail/mailman [Aktion] [Listenname]<br />
<br />
So wird das definiert für alle Aktionen für die Liste '''mailman'''.<br />
<br />
B) .forward Dateien:<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 />
=== Administration ===<br />
<br />
Administriert werden Listen über http://lists.example.com/admin/<listenname> und entweder dem Listenpasswort oder dem Site-Passwort.<br />
<br />
Als erstes sollte man die Liste "mailman" selbst abonnieren. (http://lists.example.com/admin/mailman)<br />
<br />
Bis auf das Anwenden der sitelist.cfg werden auch alle weiteren Listen nach obigem Schema angelegt, oder (bis auf das anlegen der virtusertable Einträge und aliase) über das Mailman Webinterface.<br />
<br />
Das war's. Mailman ist jetzt fertig installiert und müsste sogar funktionieren ;)<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/lists.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@lists.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 lists.example.com sowohl als URL für das Webfrontend wie auch als Hostpart für Emailadressen verwendet. (Was für separate aufgeschaltete Domains wie z.B. lists.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 = 'lists.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 statt Paketadmin: https://lists.hostsharing.net/archiv/support/2009-June/019414.html<br><br />
Ältere Anleitung für Installation als Domain-Admin: <http://lists.hostsharing.net/archiv/support/2005-January/012426.html><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>Apc00https://wiki.hostsharing.net/index.php?title=Mailman_Installieren&diff=4823Mailman Installieren2019-03-06T12:51:46Z<p>Apc00: /* Konfigurationsdatei mm_cfg.py editieren */</p>
<hr />
<div>Was noch jemand ergänzen müsste:<br />
* Eine generische virtuser/alias Konfiguration finden und dokumentieren. <br><br />
http://listes.rezo.net/how.php<br> http://www.gnu.org/software/mailman/mailman-install/mail-server.html<br />
<br />
* Skriptautomatisierung updaten <br> http://hs.andreasloesch.de/pac-mm-install<br />
<br />
<br />
== Mailman 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 />
Mailman kann vom Paketadmin (beipsielsweise "xyz00") oder von einem Paketuser (bspw. "xyz00-listen") installiert werden. Letzteres ist dringend empfohlen, denn 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.de mit "Domain-User" xyz00-listen anlegen. Aus admin.hostsharing.net abmelden.<br />
<br />
Mit ssh an hostsharing.net als xyz00-listen anmelden. Die Redirect-Zeile aus ~/doms/listen.example.de/htdocs-ssl/.htaccess löschen:<br />
<br />
~$ echo "" > ~/doms/lists.example.de/htdocs-ssl/.htaccess<br />
<br />
Die Default-Subdomains www.* löschen:<br />
<br />
~$ rm -r doms/listen.example.de/subs/www/<br />
~$ rm -r doms/listen.example.de/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 Mailman 2 Versionen (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:<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:<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.de 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.de'<br />
DEFAULT_EMAIL_HOST = 'listen.example.de'<br />
DEFAULT_URL_HOST = 'listen.example.de'<br />
add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)<br />
add_virtualhost(zweite.listendomain.de, zweite.listendomain.de)<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:<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.de/cgi-ssl/mailman<br />
~$ cp mailman/cgi-bin/* doms/listen.example.de/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.de/cgi/mailman/*<br />
<br />
Bei der Installation als Paketadmin: <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.de/cgi-ssl<br />
~/doms/listen.example.de/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.de/htdocs-ssl<br />
~/doms/listen.example.de/htdocs-ssl$ ln -s ../../../mailman/icons<br />
<br />
oder<br />
<br />
~$ cp -R mailman/icons doms/lists.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.de/cgi-bin/mailman, sondern auch unter https://listen.example.de erreichbar ist.<br />
<br />
Dazu werden in ~/doms/listen.example.de/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 />
* * * * * ~/mailman/bin/qrunner -o -r All<br />
47 * * * * rm -f ~/var/mailman/logs/qrunner<br />
(Queuebearbeitung alle Minute, löschen der Verarbeitungslogs in der 47ten Minute jeder Std.)<br />
<br />
Dies übernimmt die Funktion des qrunner-Dämons, der bei Mailman normalerweise laufen würde.<br />
Das Logfile wird gelöscht, da es sonst sehr schnell sehr groß wird.<br />
<br />
Zudem müssen noch die Cronjobs aus ~/mailman/cron/crontab.in eingefügt 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 />
=== Als erste Liste die "mailman" "site list" einrichten ===<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 />
Neue Liste anlegen:<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 />
Nur für die "mailman site list": Konfigurationsvorgaben laden.<br />
<br />
~$ mailman/bin/config_list -i ~/mailman/var/data/sitelist.cfg mailman<br />
<br />
Bei der Installation als Paketadmin:<br />
~$ mailman/bin/config_list -i ~/var/mailman/data/sitelist.cfg mailman<br />
<br />
(Diese Konfigurationsdatei nicht auf eigene Listen anwenden.)<br />
<br />
=== Email Adressen einrichten === <br />
<br />
Bei der Installation als Paketuser erfolgt die Einrichtung der Emailadressen per hsadmin (virtusertable) und .forward Dateien.<br />
Anlegen mittels [[hsadmin|hsadmin CLI]]: [https://doc.hostsharing.net/users/administration/hsadmin/index.html]<br />
<br />
Beispiel für lists.example.com und Paketuser xyz00-listen.<br />
<br />
A) virtusertable:<br />
hsscript -u xyz00 -i<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman',target:'xyz00-listen+mailman'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-admin',target:'xyz00-listen+mailman-admin'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-bounces',target:'xyz00-listen+mailman-bounces'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-confirm',target:'xyz00-listen+mailman-confirm'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-join',target:'xyz00-listen+mailman-join'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-leave',target:'xyz00-listen+mailman-leave'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-owner',target:'xyz00-listen+mailman-owner'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-request',target:'xyz00-listen+mailman-request'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-subscribe',target:'xyz00-listen+mailman-subscribe'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-unsubscribe',target:'xyz00-listen+mailman-unsubscribe'}})<br />
<br />
Im Homeverzeichnis des Users xyz00-listen werden anschließend entsprechende .forward-Dateien angelegt. Die Dateinamen und Inhalte dieser Dateien definieren den Aufruf von Mailman und die Aktion, die das Programm ausführen soll. Zum Beispiel wird die .forward-Datei '''.forward+mailman''' verwendet, wenn die Adresse mailman@lists.example.com eine Mail erhält. In der .forward-Datei steht nun der Aufruf mit dem Programm, an das die Mail übergeben wird, die gewünschte Aktion und der Namen der Liste:<br />
<br />
/home/pacs/xyz00/users/listen/mailman/mail/mailman [Aktion] [Listenname]<br />
<br />
So wird das definiert für alle Aktionen für die Liste '''mailman'''.<br />
<br />
B) .forward Dateien:<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 />
=== Administration ===<br />
<br />
Administriert werden Listen über http://lists.example.com/admin/<listenname> und entweder dem Listenpasswort oder dem Site-Passwort.<br />
<br />
Als erstes sollte man die Liste "mailman" selbst abonnieren. (http://lists.example.com/admin/mailman)<br />
<br />
Bis auf das Anwenden der sitelist.cfg werden auch alle weiteren Listen nach obigem Schema angelegt, oder (bis auf das anlegen der virtusertable Einträge und aliase) über das Mailman Webinterface.<br />
<br />
Das war's. Mailman ist jetzt fertig installiert und müsste sogar funktionieren ;)<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/lists.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@lists.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 lists.example.com sowohl als URL für das Webfrontend wie auch als Hostpart für Emailadressen verwendet. (Was für separate aufgeschaltete Domains wie z.B. lists.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 = 'lists.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 statt Paketadmin: https://lists.hostsharing.net/archiv/support/2009-June/019414.html<br><br />
Ältere Anleitung für Installation als Domain-Admin: <http://lists.hostsharing.net/archiv/support/2005-January/012426.html><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>Apc00https://wiki.hostsharing.net/index.php?title=Mailman_Installieren&diff=4822Mailman Installieren2019-03-06T12:51:22Z<p>Apc00: /* Konfiguration */</p>
<hr />
<div>Was noch jemand ergänzen müsste:<br />
* Eine generische virtuser/alias Konfiguration finden und dokumentieren. <br><br />
http://listes.rezo.net/how.php<br> http://www.gnu.org/software/mailman/mailman-install/mail-server.html<br />
<br />
* Skriptautomatisierung updaten <br> http://hs.andreasloesch.de/pac-mm-install<br />
<br />
<br />
== Mailman 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 />
Mailman kann vom Paketadmin (beipsielsweise "xyz00") oder von einem Paketuser (bspw. "xyz00-listen") installiert werden. Letzteres ist dringend empfohlen, denn 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.de mit "Domain-User" xyz00-listen anlegen. Aus admin.hostsharing.net abmelden.<br />
<br />
Mit ssh an hostsharing.net als xyz00-listen anmelden. Die Redirect-Zeile aus ~/doms/listen.example.de/htdocs-ssl/.htaccess löschen:<br />
<br />
~$ echo "" > ~/doms/lists.example.de/htdocs-ssl/.htaccess<br />
<br />
Die Default-Subdomains www.* löschen:<br />
<br />
~$ rm -r doms/listen.example.de/subs/www/<br />
~$ rm -r doms/listen.example.de/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 Mailman 2 Versionen (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:<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:<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 lists.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.de'<br />
DEFAULT_EMAIL_HOST = 'listen.example.de'<br />
DEFAULT_URL_HOST = 'listen.example.de'<br />
add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)<br />
add_virtualhost(zweite.listendomain.de, zweite.listendomain.de)<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:<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.de/cgi-ssl/mailman<br />
~$ cp mailman/cgi-bin/* doms/listen.example.de/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.de/cgi/mailman/*<br />
<br />
Bei der Installation als Paketadmin: <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.de/cgi-ssl<br />
~/doms/listen.example.de/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.de/htdocs-ssl<br />
~/doms/listen.example.de/htdocs-ssl$ ln -s ../../../mailman/icons<br />
<br />
oder<br />
<br />
~$ cp -R mailman/icons doms/lists.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.de/cgi-bin/mailman, sondern auch unter https://listen.example.de erreichbar ist.<br />
<br />
Dazu werden in ~/doms/listen.example.de/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 />
* * * * * ~/mailman/bin/qrunner -o -r All<br />
47 * * * * rm -f ~/var/mailman/logs/qrunner<br />
(Queuebearbeitung alle Minute, löschen der Verarbeitungslogs in der 47ten Minute jeder Std.)<br />
<br />
Dies übernimmt die Funktion des qrunner-Dämons, der bei Mailman normalerweise laufen würde.<br />
Das Logfile wird gelöscht, da es sonst sehr schnell sehr groß wird.<br />
<br />
Zudem müssen noch die Cronjobs aus ~/mailman/cron/crontab.in eingefügt 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 />
=== Als erste Liste die "mailman" "site list" einrichten ===<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 />
Neue Liste anlegen:<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 />
Nur für die "mailman site list": Konfigurationsvorgaben laden.<br />
<br />
~$ mailman/bin/config_list -i ~/mailman/var/data/sitelist.cfg mailman<br />
<br />
Bei der Installation als Paketadmin:<br />
~$ mailman/bin/config_list -i ~/var/mailman/data/sitelist.cfg mailman<br />
<br />
(Diese Konfigurationsdatei nicht auf eigene Listen anwenden.)<br />
<br />
=== Email Adressen einrichten === <br />
<br />
Bei der Installation als Paketuser erfolgt die Einrichtung der Emailadressen per hsadmin (virtusertable) und .forward Dateien.<br />
Anlegen mittels [[hsadmin|hsadmin CLI]]: [https://doc.hostsharing.net/users/administration/hsadmin/index.html]<br />
<br />
Beispiel für lists.example.com und Paketuser xyz00-listen.<br />
<br />
A) virtusertable:<br />
hsscript -u xyz00 -i<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman',target:'xyz00-listen+mailman'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-admin',target:'xyz00-listen+mailman-admin'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-bounces',target:'xyz00-listen+mailman-bounces'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-confirm',target:'xyz00-listen+mailman-confirm'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-join',target:'xyz00-listen+mailman-join'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-leave',target:'xyz00-listen+mailman-leave'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-owner',target:'xyz00-listen+mailman-owner'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-request',target:'xyz00-listen+mailman-request'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-subscribe',target:'xyz00-listen+mailman-subscribe'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-unsubscribe',target:'xyz00-listen+mailman-unsubscribe'}})<br />
<br />
Im Homeverzeichnis des Users xyz00-listen werden anschließend entsprechende .forward-Dateien angelegt. Die Dateinamen und Inhalte dieser Dateien definieren den Aufruf von Mailman und die Aktion, die das Programm ausführen soll. Zum Beispiel wird die .forward-Datei '''.forward+mailman''' verwendet, wenn die Adresse mailman@lists.example.com eine Mail erhält. In der .forward-Datei steht nun der Aufruf mit dem Programm, an das die Mail übergeben wird, die gewünschte Aktion und der Namen der Liste:<br />
<br />
/home/pacs/xyz00/users/listen/mailman/mail/mailman [Aktion] [Listenname]<br />
<br />
So wird das definiert für alle Aktionen für die Liste '''mailman'''.<br />
<br />
B) .forward Dateien:<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 />
=== Administration ===<br />
<br />
Administriert werden Listen über http://lists.example.com/admin/<listenname> und entweder dem Listenpasswort oder dem Site-Passwort.<br />
<br />
Als erstes sollte man die Liste "mailman" selbst abonnieren. (http://lists.example.com/admin/mailman)<br />
<br />
Bis auf das Anwenden der sitelist.cfg werden auch alle weiteren Listen nach obigem Schema angelegt, oder (bis auf das anlegen der virtusertable Einträge und aliase) über das Mailman Webinterface.<br />
<br />
Das war's. Mailman ist jetzt fertig installiert und müsste sogar funktionieren ;)<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/lists.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@lists.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 lists.example.com sowohl als URL für das Webfrontend wie auch als Hostpart für Emailadressen verwendet. (Was für separate aufgeschaltete Domains wie z.B. lists.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 = 'lists.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 statt Paketadmin: https://lists.hostsharing.net/archiv/support/2009-June/019414.html<br><br />
Ältere Anleitung für Installation als Domain-Admin: <http://lists.hostsharing.net/archiv/support/2005-January/012426.html><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>Apc00https://wiki.hostsharing.net/index.php?title=Mailman_Installieren&diff=4821Mailman Installieren2019-03-06T12:24:23Z<p>Apc00: /* Installation */</p>
<hr />
<div>Was noch jemand ergänzen müsste:<br />
* Eine generische virtuser/alias Konfiguration finden und dokumentieren. <br><br />
http://listes.rezo.net/how.php<br> http://www.gnu.org/software/mailman/mailman-install/mail-server.html<br />
<br />
* Skriptautomatisierung updaten <br> http://hs.andreasloesch.de/pac-mm-install<br />
<br />
<br />
== Mailman 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 />
Mailman kann vom Paketadmin (beipsielsweise "xyz00") oder von einem Paketuser (bspw. "xyz00-listen") installiert werden. Letzteres ist dringend empfohlen, denn 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.de mit "Domain-User" xyz00-listen anlegen. Aus admin.hostsharing.net abmelden.<br />
<br />
Mit ssh an hostsharing.net als xyz00-listen anmelden. Die Redirect-Zeile aus ~/doms/listen.example.de/htdocs-ssl/.htaccess löschen:<br />
<br />
~$ echo "" > ~/doms/lists.example.de/htdocs-ssl/.htaccess<br />
<br />
Die Default-Subdomains www.* löschen:<br />
<br />
~$ rm -r doms/listen.example.de/subs/www/<br />
~$ rm -r doms/listen.example.de/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 Mailman 2 Versionen (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:<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:<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 />
== Konfiguration ==<br />
<br />
=== mm_cfg.py ===<br />
<br />
Konfigurationsdatei editieren:<br />
<br />
~$ nano mailman/Mailman/mm_cfg.py<br />
<br />
Eine Beispielkonfiguration für lists.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 = 'lists.example.com'<br />
DEFAULT_EMAIL_HOST = 'lists.example.com'<br />
DEFAULT_URL_HOST = 'lists.example.com'<br />
add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)<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-users'<br />
SMTP_USE_TLS = True<br />
<br />
<br />
In ~/mailman/Mailman/Defaults.py seht ihr, was man in mm_cfg.py alles einstellen kann.<br />
<br />
=== CGIs in die Domains ===<br />
<br />
Bei der Installation als Paketuser: Die CGIs müssen in das jeweilige Domain-Verzeichnis, auf denen das Mailman Webfrontend laufen soll, kopiert werden. Ein Verlinken ist nicht möglich. Zusätzlich muss das sticky-Flag entfernt werden.<br />
<br />
~$ mkdir ~/doms/lists.example.com/cgi/mailman<br />
~$ cp mailman/cgi-bin/* doms/lists.example.com/cgi/mailman/<br />
~$ chmod g-s ~/doms/lists.example.com/cgi/mailman/*<br />
<br />
Bei der Installation als Paketadmin: CGIs in alle Domain-Verzeichnisse linken, auf denen das Mailman Webfrontend laufen soll. <br />
<br />
~$ cd doms/lists.example.com/cgi<br />
~/doms/lists.example.com/cgi$ ln -s ../../../mailman/cgi-bin mailman<br />
<br />
=== Icons in die Domains ===<br />
<br />
Die Icons können wahlweise verlinkt oder kopiert werden.<br />
<br />
~$ cd doms/lists.example.com/htdocs<br />
~/doms/lists.example.com/htdocs$ ln -s ../../../mailman/icons<br />
<br />
oder kopieren<br />
<br />
~$ cp -R mailman/icons doms/lists.example.com/htdocs/<br />
<br />
=== .htaccess ===<br />
<br />
Bei einer extra Mailman Domain dafür sorgen, dass Mailman auch unter lists.example.com statt unter lists.example.com/cgi-bin/mailman erreichbar ist.<br />
In ~/doms/lists.example.com/htdocs/.htaccess folgendes eintragen (bitte RewriteCond für Icons beachten; ohne wird der Pfad für diese auch gemappt, was nicht korrekt ist):<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 />
<br />
Wenn Mailman z.B. auf der www Domain läuft und unter www.example.com/mailman statt www.example.com/cgi-bin/mailman erreichbar sein soll, hilft folgendes in der ~/doms/example.com/subs/www/.htaccess:<br />
<br />
RewriteEngine On<br />
RewriteRule ^mailman/(.*)$ /cgi-bin/mailman/$1<br />
RewriteRule ^/cgi-bin/mailman/$ /cgi-bin/mailman/listinfo<br />
<br />
(Die DEFAULT_URL_PATTERN Zeile in der mm_cfg.py kann für diesen Fall einfach auskommentiert werden.)<br />
<br />
=== Passwort setzen ===<br />
<br />
~$ mailman/bin/mmsitepass<br />
<br />
=== Cronjobs einrichten ===<br />
<br />
In die [[Cron |Crontab]] wird z.B. eingetragen:<br />
<br />
* * * * * ~/mailman/bin/qrunner -o -r All<br />
47 * * * * rm -f ~/var/mailman/logs/qrunner<br />
(Queuebearbeitung alle Minute, löschen der Verarbeitungslogs in der 47ten Minute jeder Std.)<br />
<br />
Dies übernimmt die Funktion des qrunner-Dämons, der bei Mailman normalerweise laufen würde.<br />
Das Logfile wird gelöscht, da es sonst sehr schnell sehr groß wird.<br />
<br />
Zudem müssen noch die Cronjobs aus ~/mailman/cron/crontab.in eingefügt 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 />
=== Als erste Liste die "mailman" "site list" einrichten ===<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 />
Neue Liste anlegen:<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 />
Nur für die "mailman site list": Konfigurationsvorgaben laden.<br />
<br />
~$ mailman/bin/config_list -i ~/mailman/var/data/sitelist.cfg mailman<br />
<br />
Bei der Installation als Paketadmin:<br />
~$ mailman/bin/config_list -i ~/var/mailman/data/sitelist.cfg mailman<br />
<br />
(Diese Konfigurationsdatei nicht auf eigene Listen anwenden.)<br />
<br />
=== Email Adressen einrichten === <br />
<br />
Bei der Installation als Paketuser erfolgt die Einrichtung der Emailadressen per hsadmin (virtusertable) und .forward Dateien.<br />
Anlegen mittels [[hsadmin|hsadmin CLI]]: [https://doc.hostsharing.net/users/administration/hsadmin/index.html]<br />
<br />
Beispiel für lists.example.com und Paketuser xyz00-listen.<br />
<br />
A) virtusertable:<br />
hsscript -u xyz00 -i<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman',target:'xyz00-listen+mailman'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-admin',target:'xyz00-listen+mailman-admin'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-bounces',target:'xyz00-listen+mailman-bounces'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-confirm',target:'xyz00-listen+mailman-confirm'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-join',target:'xyz00-listen+mailman-join'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-leave',target:'xyz00-listen+mailman-leave'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-owner',target:'xyz00-listen+mailman-owner'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-request',target:'xyz00-listen+mailman-request'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-subscribe',target:'xyz00-listen+mailman-subscribe'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-unsubscribe',target:'xyz00-listen+mailman-unsubscribe'}})<br />
<br />
Im Homeverzeichnis des Users xyz00-listen werden anschließend entsprechende .forward-Dateien angelegt. Die Dateinamen und Inhalte dieser Dateien definieren den Aufruf von Mailman und die Aktion, die das Programm ausführen soll. Zum Beispiel wird die .forward-Datei '''.forward+mailman''' verwendet, wenn die Adresse mailman@lists.example.com eine Mail erhält. In der .forward-Datei steht nun der Aufruf mit dem Programm, an das die Mail übergeben wird, die gewünschte Aktion und der Namen der Liste:<br />
<br />
/home/pacs/xyz00/users/listen/mailman/mail/mailman [Aktion] [Listenname]<br />
<br />
So wird das definiert für alle Aktionen für die Liste '''mailman'''.<br />
<br />
B) .forward Dateien:<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 />
=== Administration ===<br />
<br />
Administriert werden Listen über http://lists.example.com/admin/<listenname> und entweder dem Listenpasswort oder dem Site-Passwort.<br />
<br />
Als erstes sollte man die Liste "mailman" selbst abonnieren. (http://lists.example.com/admin/mailman)<br />
<br />
Bis auf das Anwenden der sitelist.cfg werden auch alle weiteren Listen nach obigem Schema angelegt, oder (bis auf das anlegen der virtusertable Einträge und aliase) über das Mailman Webinterface.<br />
<br />
Das war's. Mailman ist jetzt fertig installiert und müsste sogar funktionieren ;)<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/lists.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@lists.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 lists.example.com sowohl als URL für das Webfrontend wie auch als Hostpart für Emailadressen verwendet. (Was für separate aufgeschaltete Domains wie z.B. lists.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 = 'lists.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 statt Paketadmin: https://lists.hostsharing.net/archiv/support/2009-June/019414.html<br><br />
Ältere Anleitung für Installation als Domain-Admin: <http://lists.hostsharing.net/archiv/support/2005-January/012426.html><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>Apc00https://wiki.hostsharing.net/index.php?title=Mailman_Installieren&diff=4818Mailman Installieren2019-03-04T17:48:32Z<p>Apc00: /* Sourcen besorgen und entpacken */</p>
<hr />
<div>Was noch jemand ergänzen müsste:<br />
* Eine generische virtuser/alias Konfiguration finden und dokumentieren. <br><br />
http://listes.rezo.net/how.php<br> http://www.gnu.org/software/mailman/mailman-install/mail-server.html<br />
<br />
* Skriptautomatisierung updaten <br> http://hs.andreasloesch.de/pac-mm-install<br />
<br />
<br />
== Installation == <br />
<br />
Installationsanleitung von Mailman<br><br />
(zuletzt getestet mit mailman-2.1.12 in eigenem Paketuser)<br />
<br />
Vielen Dank an alle Benutzer die Verbesserungen beisteuern!<br />
<br />
Mailman kann vom Paketadmin oder vom Paketuser installiert werden. Wenn er vom Paketadmin installiert wird, haben jedoch 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 />
Zur Separation von Paketadminrechten und anderen Paketusern ist es vorzuziehen Mailman in einem Paketuser Account zu installieren. (Bspw. xyz00-listen) Und diesem separaten User ggf mehrere lists.*.* Subdomains aufzuschalten.<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 werden (wie immer bei .forward) die Rechte des Zielusers angenommen. (So läuft das auch bei procmail.)<br />
<br />
Nachteil der Installation als Paketuser ist lediglich, dass bisher so nicht die Paketdomain mit dem SSL Zertifikat von Hostsharing genutzt werden kann.<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 Mailman 2 Versionen (http://ftp.gnu.org/gnu/mailman/). Die letzte Version downloaden und auf der Shell entpacken mit diesem Befehl:<br />
<br />
~$ tar -xzvf mailman-2.1.12.tgz<br />
<br />
Ab diesem Augenblick gibt es ein Verzeichnis namens mailman-2.1.12/. Darin liegt die nunmehr entpackte ''Quellcode'' der Mailman-Software. Nach dem Kompilieren (folgt unten) wird es ''zusätzlich'' das Verzeichnis mailman/ geben: darin liegt dann die fertig kompilierte, gebrauchsfähige Mailman-Software.<br />
<br />
=== Log-Verzeichnis anlegen ===<br />
<br />
Bei der Installation als Paketuser:<br />
~$ cd && mkdir -p mailman/var<br />
~$ chmod 02775 mailman/var<br />
<br />
Bei der Installation als Paketadmin:<br />
~$ cd && mkdir var/mailman<br />
~$ chmod 02775 var/mailman<br />
<br />
=== Kompilieren ===<br />
<br />
Braucht einige Optionen, die anzupassen sind.<br />
<br />
~$ cd mailman-2.1.12<br />
<br />
Bei der Installation als Paketuser:<br />
~/mailman-2.1.12$ ./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:<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 />
(die \ bedeuten, dass alles in eine Zeile gehört, bzw. die Returns nicht interpretiert werden sollen.)<br />
<br />
<br />
Anschließend:<br />
<br />
~/mailman-2.1.12$ make<br />
~/mailman-2.1.12$ make install<br />
<br />
=== Datenrechte prüfen ===<br />
<br />
Sicherheitshalber die Dateirechte prüfen (und ggf. korrigieren) lassen:<br />
<br />
~/mailman-2.1.12$ cd .. <br />
~$ mailman/bin/check_perms -f<br />
<br />
== Konfiguration ==<br />
<br />
=== mm_cfg.py ===<br />
<br />
Konfigurationsdatei editieren:<br />
<br />
~$ nano mailman/Mailman/mm_cfg.py<br />
<br />
Eine Beispielkonfiguration für lists.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 = 'lists.example.com'<br />
DEFAULT_EMAIL_HOST = 'lists.example.com'<br />
DEFAULT_URL_HOST = 'lists.example.com'<br />
add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)<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-users'<br />
SMTP_USE_TLS = True<br />
<br />
<br />
In ~/mailman/Mailman/Defaults.py seht ihr, was man in mm_cfg.py alles einstellen kann.<br />
<br />
=== CGIs in die Domains ===<br />
<br />
Bei der Installation als Paketuser: Die CGIs müssen in das jeweilige Domain-Verzeichnis, auf denen das Mailman Webfrontend laufen soll, kopiert werden. Ein Verlinken ist nicht möglich. Zusätzlich muss das sticky-Flag entfernt werden.<br />
<br />
~$ mkdir ~/doms/lists.example.com/cgi/mailman<br />
~$ cp mailman/cgi-bin/* doms/lists.example.com/cgi/mailman/<br />
~$ chmod g-s ~/doms/lists.example.com/cgi/mailman/*<br />
<br />
Bei der Installation als Paketadmin: CGIs in alle Domain-Verzeichnisse linken, auf denen das Mailman Webfrontend laufen soll. <br />
<br />
~$ cd doms/lists.example.com/cgi<br />
~/doms/lists.example.com/cgi$ ln -s ../../../mailman/cgi-bin mailman<br />
<br />
=== Icons in die Domains ===<br />
<br />
Die Icons können wahlweise verlinkt oder kopiert werden.<br />
<br />
~$ cd doms/lists.example.com/htdocs<br />
~/doms/lists.example.com/htdocs$ ln -s ../../../mailman/icons<br />
<br />
oder kopieren<br />
<br />
~$ cp -R mailman/icons doms/lists.example.com/htdocs/<br />
<br />
=== .htaccess ===<br />
<br />
Bei einer extra Mailman Domain dafür sorgen, dass Mailman auch unter lists.example.com statt unter lists.example.com/cgi-bin/mailman erreichbar ist.<br />
In ~/doms/lists.example.com/htdocs/.htaccess folgendes eintragen (bitte RewriteCond für Icons beachten; ohne wird der Pfad für diese auch gemappt, was nicht korrekt ist):<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 />
<br />
Wenn Mailman z.B. auf der www Domain läuft und unter www.example.com/mailman statt www.example.com/cgi-bin/mailman erreichbar sein soll, hilft folgendes in der ~/doms/example.com/subs/www/.htaccess:<br />
<br />
RewriteEngine On<br />
RewriteRule ^mailman/(.*)$ /cgi-bin/mailman/$1<br />
RewriteRule ^/cgi-bin/mailman/$ /cgi-bin/mailman/listinfo<br />
<br />
(Die DEFAULT_URL_PATTERN Zeile in der mm_cfg.py kann für diesen Fall einfach auskommentiert werden.)<br />
<br />
=== Passwort setzen ===<br />
<br />
~$ mailman/bin/mmsitepass<br />
<br />
=== Cronjobs einrichten ===<br />
<br />
In die [[Cron |Crontab]] wird z.B. eingetragen:<br />
<br />
* * * * * ~/mailman/bin/qrunner -o -r All<br />
47 * * * * rm -f ~/var/mailman/logs/qrunner<br />
(Queuebearbeitung alle Minute, löschen der Verarbeitungslogs in der 47ten Minute jeder Std.)<br />
<br />
Dies übernimmt die Funktion des qrunner-Dämons, der bei Mailman normalerweise laufen würde.<br />
Das Logfile wird gelöscht, da es sonst sehr schnell sehr groß wird.<br />
<br />
Zudem müssen noch die Cronjobs aus ~/mailman/cron/crontab.in eingefügt 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 />
=== Als erste Liste die "mailman" "site list" einrichten ===<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 />
Neue Liste anlegen:<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 />
Nur für die "mailman site list": Konfigurationsvorgaben laden.<br />
<br />
~$ mailman/bin/config_list -i ~/mailman/var/data/sitelist.cfg mailman<br />
<br />
Bei der Installation als Paketadmin:<br />
~$ mailman/bin/config_list -i ~/var/mailman/data/sitelist.cfg mailman<br />
<br />
(Diese Konfigurationsdatei nicht auf eigene Listen anwenden.)<br />
<br />
=== Email Adressen einrichten === <br />
<br />
Bei der Installation als Paketuser erfolgt die Einrichtung der Emailadressen per hsadmin (virtusertable) und .forward Dateien.<br />
Anlegen mittels [[hsadmin|hsadmin CLI]]: [https://doc.hostsharing.net/users/administration/hsadmin/index.html]<br />
<br />
Beispiel für lists.example.com und Paketuser xyz00-listen.<br />
<br />
A) virtusertable:<br />
hsscript -u xyz00 -i<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman',target:'xyz00-listen+mailman'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-admin',target:'xyz00-listen+mailman-admin'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-bounces',target:'xyz00-listen+mailman-bounces'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-confirm',target:'xyz00-listen+mailman-confirm'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-join',target:'xyz00-listen+mailman-join'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-leave',target:'xyz00-listen+mailman-leave'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-owner',target:'xyz00-listen+mailman-owner'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-request',target:'xyz00-listen+mailman-request'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-subscribe',target:'xyz00-listen+mailman-subscribe'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-unsubscribe',target:'xyz00-listen+mailman-unsubscribe'}})<br />
<br />
Im Homeverzeichnis des Users xyz00-listen werden anschließend entsprechende .forward-Dateien angelegt. Die Dateinamen und Inhalte dieser Dateien definieren den Aufruf von Mailman und die Aktion, die das Programm ausführen soll. Zum Beispiel wird die .forward-Datei '''.forward+mailman''' verwendet, wenn die Adresse mailman@lists.example.com eine Mail erhält. In der .forward-Datei steht nun der Aufruf mit dem Programm, an das die Mail übergeben wird, die gewünschte Aktion und der Namen der Liste:<br />
<br />
/home/pacs/xyz00/users/listen/mailman/mail/mailman [Aktion] [Listenname]<br />
<br />
So wird das definiert für alle Aktionen für die Liste '''mailman'''.<br />
<br />
B) .forward Dateien:<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 />
=== Administration ===<br />
<br />
Administriert werden Listen über http://lists.example.com/admin/<listenname> und entweder dem Listenpasswort oder dem Site-Passwort.<br />
<br />
Als erstes sollte man die Liste "mailman" selbst abonnieren. (http://lists.example.com/admin/mailman)<br />
<br />
Bis auf das Anwenden der sitelist.cfg werden auch alle weiteren Listen nach obigem Schema angelegt, oder (bis auf das anlegen der virtusertable Einträge und aliase) über das Mailman Webinterface.<br />
<br />
Das war's. Mailman ist jetzt fertig installiert und müsste sogar funktionieren ;)<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/lists.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@lists.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 lists.example.com sowohl als URL für das Webfrontend wie auch als Hostpart für Emailadressen verwendet. (Was für separate aufgeschaltete Domains wie z.B. lists.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 = 'lists.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 statt Paketadmin: https://lists.hostsharing.net/archiv/support/2009-June/019414.html<br><br />
Ältere Anleitung für Installation als Domain-Admin: <http://lists.hostsharing.net/archiv/support/2005-January/012426.html><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>Apc00https://wiki.hostsharing.net/index.php?title=Mailman_Installieren&diff=4817Mailman Installieren2019-03-04T14:02:10Z<p>Apc00: Doch nicht</p>
<hr />
<div>Was noch jemand ergänzen müsste:<br />
* Eine generische virtuser/alias Konfiguration finden und dokumentieren. <br><br />
http://listes.rezo.net/how.php<br> http://www.gnu.org/software/mailman/mailman-install/mail-server.html<br />
<br />
* Skriptautomatisierung updaten <br> http://hs.andreasloesch.de/pac-mm-install<br />
<br />
<br />
== Installation == <br />
<br />
Installationsanleitung von Mailman<br><br />
(zuletzt getestet mit mailman-2.1.12 in eigenem Paketuser)<br />
<br />
Vielen Dank an alle Benutzer die Verbesserungen beisteuern!<br />
<br />
Mailman kann vom Paketadmin oder vom Paketuser installiert werden. Wenn er vom Paketadmin installiert wird, haben jedoch 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 />
Zur Separation von Paketadminrechten und anderen Paketusern ist es vorzuziehen Mailman in einem Paketuser Account zu installieren. (Bspw. xyz00-listen) Und diesem separaten User ggf mehrere lists.*.* Subdomains aufzuschalten.<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 werden (wie immer bei .forward) die Rechte des Zielusers angenommen. (So läuft das auch bei procmail.)<br />
<br />
Nachteil der Installation als Paketuser ist lediglich, dass bisher so nicht die Paketdomain mit dem SSL Zertifikat von Hostsharing genutzt werden kann.<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 Mailman 2 Versionen (http://ftp.gnu.org/gnu/mailman/). Die letzte Version downloaden und auf der Shell entpacken mit diesem Befehl:<br />
<br />
~$ tar -xzvf mailman-2.1.12.tgz<br />
<br />
=== Log-Verzeichnis anlegen ===<br />
<br />
Bei der Installation als Paketuser:<br />
~$ cd && mkdir -p mailman/var<br />
~$ chmod 02775 mailman/var<br />
<br />
Bei der Installation als Paketadmin:<br />
~$ cd && mkdir var/mailman<br />
~$ chmod 02775 var/mailman<br />
<br />
=== Kompilieren ===<br />
<br />
Braucht einige Optionen, die anzupassen sind.<br />
<br />
~$ cd mailman-2.1.12<br />
<br />
Bei der Installation als Paketuser:<br />
~/mailman-2.1.12$ ./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:<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 />
(die \ bedeuten, dass alles in eine Zeile gehört, bzw. die Returns nicht interpretiert werden sollen.)<br />
<br />
<br />
Anschließend:<br />
<br />
~/mailman-2.1.12$ make<br />
~/mailman-2.1.12$ make install<br />
<br />
=== Datenrechte prüfen ===<br />
<br />
Sicherheitshalber die Dateirechte prüfen (und ggf. korrigieren) lassen:<br />
<br />
~/mailman-2.1.12$ cd .. <br />
~$ mailman/bin/check_perms -f<br />
<br />
== Konfiguration ==<br />
<br />
=== mm_cfg.py ===<br />
<br />
Konfigurationsdatei editieren:<br />
<br />
~$ nano mailman/Mailman/mm_cfg.py<br />
<br />
Eine Beispielkonfiguration für lists.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 = 'lists.example.com'<br />
DEFAULT_EMAIL_HOST = 'lists.example.com'<br />
DEFAULT_URL_HOST = 'lists.example.com'<br />
add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)<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-users'<br />
SMTP_USE_TLS = True<br />
<br />
<br />
In ~/mailman/Mailman/Defaults.py seht ihr, was man in mm_cfg.py alles einstellen kann.<br />
<br />
=== CGIs in die Domains ===<br />
<br />
Bei der Installation als Paketuser: Die CGIs müssen in das jeweilige Domain-Verzeichnis, auf denen das Mailman Webfrontend laufen soll, kopiert werden. Ein Verlinken ist nicht möglich. Zusätzlich muss das sticky-Flag entfernt werden.<br />
<br />
~$ mkdir ~/doms/lists.example.com/cgi/mailman<br />
~$ cp mailman/cgi-bin/* doms/lists.example.com/cgi/mailman/<br />
~$ chmod g-s ~/doms/lists.example.com/cgi/mailman/*<br />
<br />
Bei der Installation als Paketadmin: CGIs in alle Domain-Verzeichnisse linken, auf denen das Mailman Webfrontend laufen soll. <br />
<br />
~$ cd doms/lists.example.com/cgi<br />
~/doms/lists.example.com/cgi$ ln -s ../../../mailman/cgi-bin mailman<br />
<br />
=== Icons in die Domains ===<br />
<br />
Die Icons können wahlweise verlinkt oder kopiert werden.<br />
<br />
~$ cd doms/lists.example.com/htdocs<br />
~/doms/lists.example.com/htdocs$ ln -s ../../../mailman/icons<br />
<br />
oder kopieren<br />
<br />
~$ cp -R mailman/icons doms/lists.example.com/htdocs/<br />
<br />
=== .htaccess ===<br />
<br />
Bei einer extra Mailman Domain dafür sorgen, dass Mailman auch unter lists.example.com statt unter lists.example.com/cgi-bin/mailman erreichbar ist.<br />
In ~/doms/lists.example.com/htdocs/.htaccess folgendes eintragen (bitte RewriteCond für Icons beachten; ohne wird der Pfad für diese auch gemappt, was nicht korrekt ist):<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 />
<br />
Wenn Mailman z.B. auf der www Domain läuft und unter www.example.com/mailman statt www.example.com/cgi-bin/mailman erreichbar sein soll, hilft folgendes in der ~/doms/example.com/subs/www/.htaccess:<br />
<br />
RewriteEngine On<br />
RewriteRule ^mailman/(.*)$ /cgi-bin/mailman/$1<br />
RewriteRule ^/cgi-bin/mailman/$ /cgi-bin/mailman/listinfo<br />
<br />
(Die DEFAULT_URL_PATTERN Zeile in der mm_cfg.py kann für diesen Fall einfach auskommentiert werden.)<br />
<br />
=== Passwort setzen ===<br />
<br />
~$ mailman/bin/mmsitepass<br />
<br />
=== Cronjobs einrichten ===<br />
<br />
In die [[Cron |Crontab]] wird z.B. eingetragen:<br />
<br />
* * * * * ~/mailman/bin/qrunner -o -r All<br />
47 * * * * rm -f ~/var/mailman/logs/qrunner<br />
(Queuebearbeitung alle Minute, löschen der Verarbeitungslogs in der 47ten Minute jeder Std.)<br />
<br />
Dies übernimmt die Funktion des qrunner-Dämons, der bei Mailman normalerweise laufen würde.<br />
Das Logfile wird gelöscht, da es sonst sehr schnell sehr groß wird.<br />
<br />
Zudem müssen noch die Cronjobs aus ~/mailman/cron/crontab.in eingefügt 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 />
=== Als erste Liste die "mailman" "site list" einrichten ===<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 />
Neue Liste anlegen:<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 />
Nur für die "mailman site list": Konfigurationsvorgaben laden.<br />
<br />
~$ mailman/bin/config_list -i ~/mailman/var/data/sitelist.cfg mailman<br />
<br />
Bei der Installation als Paketadmin:<br />
~$ mailman/bin/config_list -i ~/var/mailman/data/sitelist.cfg mailman<br />
<br />
(Diese Konfigurationsdatei nicht auf eigene Listen anwenden.)<br />
<br />
=== Email Adressen einrichten === <br />
<br />
Bei der Installation als Paketuser erfolgt die Einrichtung der Emailadressen per hsadmin (virtusertable) und .forward Dateien.<br />
Anlegen mittels [[hsadmin|hsadmin CLI]]: [https://doc.hostsharing.net/users/administration/hsadmin/index.html]<br />
<br />
Beispiel für lists.example.com und Paketuser xyz00-listen.<br />
<br />
A) virtusertable:<br />
hsscript -u xyz00 -i<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman',target:'xyz00-listen+mailman'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-admin',target:'xyz00-listen+mailman-admin'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-bounces',target:'xyz00-listen+mailman-bounces'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-confirm',target:'xyz00-listen+mailman-confirm'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-join',target:'xyz00-listen+mailman-join'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-leave',target:'xyz00-listen+mailman-leave'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-owner',target:'xyz00-listen+mailman-owner'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-request',target:'xyz00-listen+mailman-request'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-subscribe',target:'xyz00-listen+mailman-subscribe'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-unsubscribe',target:'xyz00-listen+mailman-unsubscribe'}})<br />
<br />
Im Homeverzeichnis des Users xyz00-listen werden anschließend entsprechende .forward-Dateien angelegt. Die Dateinamen und Inhalte dieser Dateien definieren den Aufruf von Mailman und die Aktion, die das Programm ausführen soll. Zum Beispiel wird die .forward-Datei '''.forward+mailman''' verwendet, wenn die Adresse mailman@lists.example.com eine Mail erhält. In der .forward-Datei steht nun der Aufruf mit dem Programm, an das die Mail übergeben wird, die gewünschte Aktion und der Namen der Liste:<br />
<br />
/home/pacs/xyz00/users/listen/mailman/mail/mailman [Aktion] [Listenname]<br />
<br />
So wird das definiert für alle Aktionen für die Liste '''mailman'''.<br />
<br />
B) .forward Dateien:<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 />
=== Administration ===<br />
<br />
Administriert werden Listen über http://lists.example.com/admin/<listenname> und entweder dem Listenpasswort oder dem Site-Passwort.<br />
<br />
Als erstes sollte man die Liste "mailman" selbst abonnieren. (http://lists.example.com/admin/mailman)<br />
<br />
Bis auf das Anwenden der sitelist.cfg werden auch alle weiteren Listen nach obigem Schema angelegt, oder (bis auf das anlegen der virtusertable Einträge und aliase) über das Mailman Webinterface.<br />
<br />
Das war's. Mailman ist jetzt fertig installiert und müsste sogar funktionieren ;)<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/lists.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@lists.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 lists.example.com sowohl als URL für das Webfrontend wie auch als Hostpart für Emailadressen verwendet. (Was für separate aufgeschaltete Domains wie z.B. lists.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 = 'lists.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 statt Paketadmin: https://lists.hostsharing.net/archiv/support/2009-June/019414.html<br><br />
Ältere Anleitung für Installation als Domain-Admin: <http://lists.hostsharing.net/archiv/support/2005-January/012426.html><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>Apc00https://wiki.hostsharing.net/index.php?title=Mailman_Installieren&diff=4816Mailman Installieren2019-03-04T13:57:45Z<p>Apc00: Symlink "mailman" erstellen!</p>
<hr />
<div>Was noch jemand ergänzen müsste:<br />
* Eine generische virtuser/alias Konfiguration finden und dokumentieren. <br><br />
http://listes.rezo.net/how.php<br> http://www.gnu.org/software/mailman/mailman-install/mail-server.html<br />
<br />
* Skriptautomatisierung updaten <br> http://hs.andreasloesch.de/pac-mm-install<br />
<br />
<br />
== Installation == <br />
<br />
Installationsanleitung von Mailman<br><br />
(zuletzt getestet mit mailman-2.1.12 in eigenem Paketuser)<br />
<br />
Vielen Dank an alle Benutzer die Verbesserungen beisteuern!<br />
<br />
Mailman kann vom Paketadmin oder vom Paketuser installiert werden. Wenn er vom Paketadmin installiert wird, haben jedoch 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 />
Zur Separation von Paketadminrechten und anderen Paketusern ist es vorzuziehen Mailman in einem Paketuser Account zu installieren. (Bspw. xyz00-listen) Und diesem separaten User ggf mehrere lists.*.* Subdomains aufzuschalten.<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 werden (wie immer bei .forward) die Rechte des Zielusers angenommen. (So läuft das auch bei procmail.)<br />
<br />
Nachteil der Installation als Paketuser ist lediglich, dass bisher so nicht die Paketdomain mit dem SSL Zertifikat von Hostsharing genutzt werden kann.<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 Mailman 2 Versionen (http://ftp.gnu.org/gnu/mailman/). Die letzte Version downloaden und auf der Shell entpacken mit diesem Befehl:<br />
<br />
~$ tar -xzvf mailman-2.1.12.tgz<br />
<br />
Einen symbolischen Link auf das resultierende Software-Verzeichnis erstellen:<br />
<br />
~$ ln -s mailman-2.1.12 mailman<br />
<br />
=== Log-Verzeichnis anlegen ===<br />
<br />
Bei der Installation als Paketuser:<br />
~$ cd && mkdir -p mailman/var<br />
~$ chmod 02775 mailman/var<br />
<br />
Bei der Installation als Paketadmin:<br />
~$ cd && mkdir var/mailman<br />
~$ chmod 02775 var/mailman<br />
<br />
=== Kompilieren ===<br />
<br />
Braucht einige Optionen, die anzupassen sind.<br />
<br />
~$ cd mailman-2.1.12<br />
<br />
Bei der Installation als Paketuser:<br />
~/mailman-2.1.12$ ./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:<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 />
(die \ bedeuten, dass alles in eine Zeile gehört, bzw. die Returns nicht interpretiert werden sollen.)<br />
<br />
<br />
Anschließend:<br />
<br />
~/mailman-2.1.12$ make<br />
~/mailman-2.1.12$ make install<br />
<br />
=== Datenrechte prüfen ===<br />
<br />
Sicherheitshalber die Dateirechte prüfen (und ggf. korrigieren) lassen:<br />
<br />
~/mailman-2.1.12$ cd .. <br />
~$ mailman/bin/check_perms -f<br />
<br />
== Konfiguration ==<br />
<br />
=== mm_cfg.py ===<br />
<br />
Konfigurationsdatei editieren:<br />
<br />
~$ nano mailman/Mailman/mm_cfg.py<br />
<br />
Eine Beispielkonfiguration für lists.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 = 'lists.example.com'<br />
DEFAULT_EMAIL_HOST = 'lists.example.com'<br />
DEFAULT_URL_HOST = 'lists.example.com'<br />
add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)<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-users'<br />
SMTP_USE_TLS = True<br />
<br />
<br />
In ~/mailman/Mailman/Defaults.py seht ihr, was man in mm_cfg.py alles einstellen kann.<br />
<br />
=== CGIs in die Domains ===<br />
<br />
Bei der Installation als Paketuser: Die CGIs müssen in das jeweilige Domain-Verzeichnis, auf denen das Mailman Webfrontend laufen soll, kopiert werden. Ein Verlinken ist nicht möglich. Zusätzlich muss das sticky-Flag entfernt werden.<br />
<br />
~$ mkdir ~/doms/lists.example.com/cgi/mailman<br />
~$ cp mailman/cgi-bin/* doms/lists.example.com/cgi/mailman/<br />
~$ chmod g-s ~/doms/lists.example.com/cgi/mailman/*<br />
<br />
Bei der Installation als Paketadmin: CGIs in alle Domain-Verzeichnisse linken, auf denen das Mailman Webfrontend laufen soll. <br />
<br />
~$ cd doms/lists.example.com/cgi<br />
~/doms/lists.example.com/cgi$ ln -s ../../../mailman/cgi-bin mailman<br />
<br />
=== Icons in die Domains ===<br />
<br />
Die Icons können wahlweise verlinkt oder kopiert werden.<br />
<br />
~$ cd doms/lists.example.com/htdocs<br />
~/doms/lists.example.com/htdocs$ ln -s ../../../mailman/icons<br />
<br />
oder kopieren<br />
<br />
~$ cp -R mailman/icons doms/lists.example.com/htdocs/<br />
<br />
=== .htaccess ===<br />
<br />
Bei einer extra Mailman Domain dafür sorgen, dass Mailman auch unter lists.example.com statt unter lists.example.com/cgi-bin/mailman erreichbar ist.<br />
In ~/doms/lists.example.com/htdocs/.htaccess folgendes eintragen (bitte RewriteCond für Icons beachten; ohne wird der Pfad für diese auch gemappt, was nicht korrekt ist):<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 />
<br />
Wenn Mailman z.B. auf der www Domain läuft und unter www.example.com/mailman statt www.example.com/cgi-bin/mailman erreichbar sein soll, hilft folgendes in der ~/doms/example.com/subs/www/.htaccess:<br />
<br />
RewriteEngine On<br />
RewriteRule ^mailman/(.*)$ /cgi-bin/mailman/$1<br />
RewriteRule ^/cgi-bin/mailman/$ /cgi-bin/mailman/listinfo<br />
<br />
(Die DEFAULT_URL_PATTERN Zeile in der mm_cfg.py kann für diesen Fall einfach auskommentiert werden.)<br />
<br />
=== Passwort setzen ===<br />
<br />
~$ mailman/bin/mmsitepass<br />
<br />
=== Cronjobs einrichten ===<br />
<br />
In die [[Cron |Crontab]] wird z.B. eingetragen:<br />
<br />
* * * * * ~/mailman/bin/qrunner -o -r All<br />
47 * * * * rm -f ~/var/mailman/logs/qrunner<br />
(Queuebearbeitung alle Minute, löschen der Verarbeitungslogs in der 47ten Minute jeder Std.)<br />
<br />
Dies übernimmt die Funktion des qrunner-Dämons, der bei Mailman normalerweise laufen würde.<br />
Das Logfile wird gelöscht, da es sonst sehr schnell sehr groß wird.<br />
<br />
Zudem müssen noch die Cronjobs aus ~/mailman/cron/crontab.in eingefügt 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 />
=== Als erste Liste die "mailman" "site list" einrichten ===<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 />
Neue Liste anlegen:<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 />
Nur für die "mailman site list": Konfigurationsvorgaben laden.<br />
<br />
~$ mailman/bin/config_list -i ~/mailman/var/data/sitelist.cfg mailman<br />
<br />
Bei der Installation als Paketadmin:<br />
~$ mailman/bin/config_list -i ~/var/mailman/data/sitelist.cfg mailman<br />
<br />
(Diese Konfigurationsdatei nicht auf eigene Listen anwenden.)<br />
<br />
=== Email Adressen einrichten === <br />
<br />
Bei der Installation als Paketuser erfolgt die Einrichtung der Emailadressen per hsadmin (virtusertable) und .forward Dateien.<br />
Anlegen mittels [[hsadmin|hsadmin CLI]]: [https://doc.hostsharing.net/users/administration/hsadmin/index.html]<br />
<br />
Beispiel für lists.example.com und Paketuser xyz00-listen.<br />
<br />
A) virtusertable:<br />
hsscript -u xyz00 -i<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman',target:'xyz00-listen+mailman'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-admin',target:'xyz00-listen+mailman-admin'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-bounces',target:'xyz00-listen+mailman-bounces'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-confirm',target:'xyz00-listen+mailman-confirm'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-join',target:'xyz00-listen+mailman-join'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-leave',target:'xyz00-listen+mailman-leave'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-owner',target:'xyz00-listen+mailman-owner'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-request',target:'xyz00-listen+mailman-request'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-subscribe',target:'xyz00-listen+mailman-subscribe'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-unsubscribe',target:'xyz00-listen+mailman-unsubscribe'}})<br />
<br />
Im Homeverzeichnis des Users xyz00-listen werden anschließend entsprechende .forward-Dateien angelegt. Die Dateinamen und Inhalte dieser Dateien definieren den Aufruf von Mailman und die Aktion, die das Programm ausführen soll. Zum Beispiel wird die .forward-Datei '''.forward+mailman''' verwendet, wenn die Adresse mailman@lists.example.com eine Mail erhält. In der .forward-Datei steht nun der Aufruf mit dem Programm, an das die Mail übergeben wird, die gewünschte Aktion und der Namen der Liste:<br />
<br />
/home/pacs/xyz00/users/listen/mailman/mail/mailman [Aktion] [Listenname]<br />
<br />
So wird das definiert für alle Aktionen für die Liste '''mailman'''.<br />
<br />
B) .forward Dateien:<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 />
=== Administration ===<br />
<br />
Administriert werden Listen über http://lists.example.com/admin/<listenname> und entweder dem Listenpasswort oder dem Site-Passwort.<br />
<br />
Als erstes sollte man die Liste "mailman" selbst abonnieren. (http://lists.example.com/admin/mailman)<br />
<br />
Bis auf das Anwenden der sitelist.cfg werden auch alle weiteren Listen nach obigem Schema angelegt, oder (bis auf das anlegen der virtusertable Einträge und aliase) über das Mailman Webinterface.<br />
<br />
Das war's. Mailman ist jetzt fertig installiert und müsste sogar funktionieren ;)<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/lists.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@lists.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 lists.example.com sowohl als URL für das Webfrontend wie auch als Hostpart für Emailadressen verwendet. (Was für separate aufgeschaltete Domains wie z.B. lists.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 = 'lists.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 statt Paketadmin: https://lists.hostsharing.net/archiv/support/2009-June/019414.html<br><br />
Ältere Anleitung für Installation als Domain-Admin: <http://lists.hostsharing.net/archiv/support/2005-January/012426.html><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>Apc00https://wiki.hostsharing.net/index.php?title=Diskussion:Mailman_Installieren&diff=4318Diskussion:Mailman Installieren2017-03-15T14:56:21Z<p>Apc00: /* Don't try this at home! */</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 installiert werden."<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)</div>Apc00https://wiki.hostsharing.net/index.php?title=Diskussion:Mailman_Installieren&diff=4317Diskussion:Mailman Installieren2017-03-15T14:52:43Z<p>Apc00: Neuer Abschnitt /* Don't try this at home! */</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 installiert werden."<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-bindestrich-okay"'}})<br />
emailalias.add ({set:{name:'xyz00-listname_ohne_bindestriche_admin',target:'"|/home/pacs/xyz00/mailman/mail/mailman admin listname-bindestrich-okay"'}})<br />
emailalias.add ({set:{name:'xyz00-listname_ohne_bindestriche_bounce',target:'"|/home/pacs/xyz00/mailman/mail/mailman bounce listname-bindestrich-okay"'}})<br />
emailalias.add ({set:{name:'xyz00-listname_ohne_bindestriche_confirm',target:'"|/home/pacs/xyz00/mailman/mail/mailman confirm listname-bindestrich-okay"'}})<br />
emailalias.add ({set:{name:'xyz00-listname_ohne_bindestriche_join',target:'"|/home/pacs/xyz00/mailman/mail/mailman join listname-bindestrich-okay"'}})<br />
emailalias.add ({set:{name:'xyz00-listname_ohne_bindestriche_leave',target:'"|/home/pacs/xyz00/mailman/mail/mailman leave listname-bindestrich-okay"'}})<br />
emailalias.add ({set:{name:'xyz00-listname_ohne_bindestriche_owner',target:'"|/home/pacs/xyz00/mailman/mail/mailman owner listname-bindestrich-okay"'}})<br />
emailalias.add ({set:{name:'xyz00-listname_ohne_bindestriche_request',target:'"|/home/pacs/xyz00/mailman/mail/mailman request listname-bindestrich-okay"'}})<br />
emailalias.add ({set:{name:'xyz00-listname_ohne_bindestriche_subscribe',target:'"|/home/pacs/xyz00/mailman/mail/mailman subscribe listname-bindestrich-okay"'}})<br />
emailalias.add ({set:{name:'xyz00-listname_ohne_bindestriche_unsubscribe',target:'"|/home/pacs/xyz00/mailman/mail/mailman unsubscribe listname-bindestrich-okay"'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'listname-bindestrich-okay',target:'xyz00-listname_ohne_bindestriche'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'listname-bindestrich-okay-admin',target:'xyz00-listname_ohne_bindestriche_admin'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'listname-bindestrich-okay-bounces',target:'xyz00-listname_ohne_bindestriche_bounces'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'listname-bindestrich-okay-confirm',target:'xyz00-listname_ohne_bindestriche_confirm'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'listname-bindestrich-okay-join',target:'xyz00-listname_ohne_bindestriche_join'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'listname-bindestrich-okay-leave',target:'xyz00-listname_ohne_bindestriche_leave'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'listname-bindestrich-okay-owner',target:'xyz00-listname_ohne_bindestriche_owner'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'listname-bindestrich-okay-request',target:'xyz00-listname_ohne_bindestriche_request'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'listname-bindestrich-okay-subscribe',target:'xyz00-listname_ohne_bindestriche_subscribe'}})<br />
emailaddress.add ({set:{domain:'lists.example.com',localpart:'listname-bindestrich-okay-unsubscribe',target:'xyz00-listname_ohne_bindestriche_unsubscribe'}})<br />
<br />
Okay? Okay! [[Benutzer:Apc00|Tony Crawford (apc00)]] ([[Benutzer Diskussion:Apc00|Diskussion]]) 15:52, 15. Mär. 2017 (CET)</div>Apc00https://wiki.hostsharing.net/index.php?title=Nameserver&diff=3909Nameserver2014-06-09T12:23:42Z<p>Apc00: Verweis siehe auch -> zonenedateien hinzugefügt</p>
<hr />
<div>Für Domains, die bei Hostsharing registriert sind, gibt es drei redundante Nameserver, die auf Anfrage die Zuordnung Domainname (z.B. www.example.com) -> IP-Adresse (z.B. 1.2.3.4) vornehmen. Diese Nameserver stehen aus Gründen der Zuverlässigkeit und Ausfallsicherheit in drei verschiedenen autonomen Systemen (AS siehe http://de.wikipedia.org/wiki/Autonomes_System) an verschiedenen Standorten. Die Namen dieser Nameserver lauten:<br />
<br />
* dns1.hostsharing.net<br />
* dns2.hostsharing.net<br />
* dns3.hostsharing.net<br />
<br />
Jede Nutzung eines Dienstes (z.B. Email, WWW, FTP, SSH und viele andere) im Internet, die über den Domainnamen des zugehörigen Rechners erfolgt, benötigt einen Nameserver, der die Frage nach der IP-Adresse des Rechners beantwortet.<br />
<br />
Ohne Nameserver kann der Dienst natürlich auch erreicht werden, und zwar direkt über seine IP-Adresse. Aber nur die Existenz des Nameservers erlaubt es, den Dienst über seinen Domainnamen aufzurufen.<br />
<br />
== Siehe auch ==<br />
[[Verwalten der Zonendaten]]<br />
<br />
[[Kategorie:HSDoku]]<br />
[[Kategorie:Zonefile]]<br />
[[Kategorie:Domains]]<br />
[[Kategorie:Glossar]]</div>Apc00https://wiki.hostsharing.net/index.php?title=DAViCal_installieren&diff=3600DAViCal installieren2013-06-19T16:10:47Z<p>Apc00: </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: http://debian.mcmillan.net.nz/packages/davical/<br />
* AWL: http://debian.mcmillan.net.nz/packages/awl/<br />
<br />
Hier jeweils die Source-Dateien (<tt>*.tar.gz</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 Email-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: Email 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 />
<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>Apc00https://wiki.hostsharing.net/index.php?title=DAViCal_installieren&diff=3599DAViCal installieren2013-06-19T15:53:30Z<p>Apc00: </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: http://debian.mcmillan.net.nz/packages/davical/<br />
* AWL: http://debian.mcmillan.net.nz/packages/awl/<br />
<br />
Hier jeweils die Source-Dateien (<tt>*.tar.gz</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 />
[[Bild:DAViCAl-home.png|miniatur|400px|right|Screenshot DAViCal Einloggen]]<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 />
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 der Login-Screen.<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 Email-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: Email 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 />
<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>Apc00https://wiki.hostsharing.net/index.php?title=DAViCal_installieren&diff=3598DAViCal installieren2013-06-19T14:35:02Z<p>Apc00: /* PostgreSQL vorbereiten */</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: http://debian.mcmillan.net.nz/packages/davical/<br />
* AWL: http://debian.mcmillan.net.nz/packages/awl/<br />
<br />
Hier jeweils die Source-Dateien (<tt>*.tar.gz</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 />
==== 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 />
DAViCal enthält ein eigenes Installations-Skript, das die PostgreSQL-Tabellen anlegt und initialisiert. Dies liegt unter <tt>davical/dba/create-database.sh</tt>. Hier wird aber davon ausgegegangen, daß man Adminrechte hat, was in der Shared-Hosting-Umgebung nicht der Fall ist.<br />
<br />
Das Anlegen der Datenbank, der -Nuter und kreieren von PL/pgSQL wurde bereits oben beschrieben. Darüberhinaus sind noch folgende Befehle auszuführen. Diese können in dieser Form einfach nacheinander ausgeführt werden, wenn wie oben beschrieben die <tt>PG*</tt> Umgebungsvariablen gesetzt wurden und die <tt>.pgpass</tt>-Datei gefüllt 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 />
The database is version 8.4 currently at revision 1.2.9. <br />
No patches were applied. <br />
Supported locales updated. <br />
Updated view: dav_principal.sql applied. <br />
CalDAV functions updated. <br />
RRULE functions updated. <br />
Database permissions updated. <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 kann über eine <tt>config.php</tt> konfigriert werden. Eine Beispiel-Datei ist unten abgebildet. Details sind im [http://wiki.davical.org/w/Configuration DAViCal-Wiki] zu finden.<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 Header normalerweise nicht weitergeleitet. Dieses Problem wird auch im DAViCal-Wiki in einem entsprechenden [http://wiki.davical.org/w/FastCGI FAQ-Eintrag] behandelt, aber dort unter der Annahme gelöst, daß man Adminrechte hat.<br />
<br />
In der Shared-Hosting-Umgebung von Hostsharing kann dies auch über ein Redirect in der <tt>.htaccess</tt>-Datei gemacht gelöst werden:<br />
<br />
<pre><nowiki><br />
$ cd /home/doms/cal.example.org/htdocs-ssl<br />
$ cat >> .htaccess<br />
RewriteEngine on<br />
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization},L]<br />
^D<br />
</nowiki></pre><br />
<br />
Diese Regel muß die letzte in der <tt>.htaccess</tt> sein. Die Datei muß für alle lesbar sein:<br />
<br />
<pre><nowiki><br />
$ chmod 0644 .htaccess<br />
</nowiki></pre><br />
<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 />
@@ -87,8 +87,8 @@<br />
/**<br />
* Get HTTP Auth to work with PHP+FastCGI<br />
*/<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 />
[[Bild:DAViCAl-home.png|miniatur|400px|right|Screenshot DAViCal Einloggen]]<br />
=== Webspace aktivieren ===<br />
<br />
Schließlich muß die Installation noch mit dem Webspace verknüpft werden.<br />
<pre><nowiki><br />
$ cd /home/doms/cal.example.org<br />
$ rm htdocs-ssl<br />
$ ln -s var/davical/htdocs htdocs-ssl<br />
</nowiki></pre><br />
<br />
Die URL des User-Interfaces lautet: '''<tt><nowiki>https://cal.example.org</nowiki></tt>'''<br />
<br />
Wenn alles richtig gemacht wurde, erscheint der Login-Screen.<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 Email-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: Email 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 />
<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>Apc00https://wiki.hostsharing.net/index.php?title=DAViCal_installieren&diff=3597DAViCal installieren2013-06-19T14:02:33Z<p>Apc00: /* Quellen */</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: http://debian.mcmillan.net.nz/packages/davical/<br />
* AWL: http://debian.mcmillan.net.nz/packages/awl/<br />
<br />
Hier jeweils die Source-Dateien (<tt>*.tar.gz</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 />
Es wird eine eigene PostgreSQL-Datenbank benötigt, sowie 2 Datenbanknutzer.<br />
<br />
==== Datenbank und -Nutzer anlegen ====<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 administrative Tätigkeiten durchführt<br />
|-<br />
| DB-Nutzer || <tt>xyz00_davical_app</tt> || Der PostgreSQL-Nutzer, der über DAViCal auf die Datenbank lesen/schreibend zugreift<br />
|-<br />
| Datenbank || <tt>xyz00_davical</tt> || Die Datenbank, die alle Daten für den DAViCal-Server enthält<br />
|}<br />
<br />
==== Umgebungsvariablen und <tt>.pgpass</tt> ====<br />
Die Nutzer und die Datenbank können über [[Hsadmin]] angelegt werden. Dabei wird <tt>xyz00_davical_dba</tt> als Datenbank-Besitzer angegeben. Als Zeichensatz <tt>UTF-8</tt> (Default) auswählen.<br />
<br />
Sowohl für die weitere Installation, als auch für den Betrieb des Servers ist es am besten die Passwörter in die <tt>[http://www.postgresql.org/docs/9.0/interactive/libpq-pgpass.html .pgpass]</tt>-Datei zu schreiben, dann müssen sie nicht innerhalb der PHP-Dateien angebenen werden, bzw. 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 />
Darüberhinaus werden noch Umgebungsvariablen gesetzt, so daß beim Aufruf von <tt>psql</tt> über die Kommandozeile Datenbankname/Nutzer nicht eingegeben werden müssen. Diese Angaben sind nach Beenden der Shell-Sitzung automatisch zurückgesetzt.<br />
<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 kann folgendermaßen angelegt werden:<br />
<br />
<pre><nowiki><br />
$ psql -A -c "CREATE LANGUAGE plpgsql;"<br />
</nowiki></pre><br />
<br />
=== Datenbank-Tabellen anlegen und initialisieren ===<br />
<br />
DAViCal enthält ein eigenes Installations-Skript, das die PostgreSQL-Tabellen anlegt und initialisiert. Dies liegt unter <tt>davical/dba/create-database.sh</tt>. Hier wird aber davon ausgegegangen, daß man Adminrechte hat, was in der Shared-Hosting-Umgebung nicht der Fall ist.<br />
<br />
Das Anlegen der Datenbank, der -Nuter und kreieren von PL/pgSQL wurde bereits oben beschrieben. Darüberhinaus sind noch folgende Befehle auszuführen. Diese können in dieser Form einfach nacheinander ausgeführt werden, wenn wie oben beschrieben die <tt>PG*</tt> Umgebungsvariablen gesetzt wurden und die <tt>.pgpass</tt>-Datei gefüllt 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 />
The database is version 8.4 currently at revision 1.2.9. <br />
No patches were applied. <br />
Supported locales updated. <br />
Updated view: dav_principal.sql applied. <br />
CalDAV functions updated. <br />
RRULE functions updated. <br />
Database permissions updated. <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 kann über eine <tt>config.php</tt> konfigriert werden. Eine Beispiel-Datei ist unten abgebildet. Details sind im [http://wiki.davical.org/w/Configuration DAViCal-Wiki] zu finden.<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 Header normalerweise nicht weitergeleitet. Dieses Problem wird auch im DAViCal-Wiki in einem entsprechenden [http://wiki.davical.org/w/FastCGI FAQ-Eintrag] behandelt, aber dort unter der Annahme gelöst, daß man Adminrechte hat.<br />
<br />
In der Shared-Hosting-Umgebung von Hostsharing kann dies auch über ein Redirect in der <tt>.htaccess</tt>-Datei gemacht gelöst werden:<br />
<br />
<pre><nowiki><br />
$ cd /home/doms/cal.example.org/htdocs-ssl<br />
$ cat >> .htaccess<br />
RewriteEngine on<br />
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization},L]<br />
^D<br />
</nowiki></pre><br />
<br />
Diese Regel muß die letzte in der <tt>.htaccess</tt> sein. Die Datei muß für alle lesbar sein:<br />
<br />
<pre><nowiki><br />
$ chmod 0644 .htaccess<br />
</nowiki></pre><br />
<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 />
@@ -87,8 +87,8 @@<br />
/**<br />
* Get HTTP Auth to work with PHP+FastCGI<br />
*/<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 />
[[Bild:DAViCAl-home.png|miniatur|400px|right|Screenshot DAViCal Einloggen]]<br />
=== Webspace aktivieren ===<br />
<br />
Schließlich muß die Installation noch mit dem Webspace verknüpft werden.<br />
<pre><nowiki><br />
$ cd /home/doms/cal.example.org<br />
$ rm htdocs-ssl<br />
$ ln -s var/davical/htdocs htdocs-ssl<br />
</nowiki></pre><br />
<br />
Die URL des User-Interfaces lautet: '''<tt><nowiki>https://cal.example.org</nowiki></tt>'''<br />
<br />
Wenn alles richtig gemacht wurde, erscheint der Login-Screen.<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 Email-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: Email 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 />
<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>Apc00https://wiki.hostsharing.net/index.php?title=DAViCal_installieren&diff=3596DAViCal installieren2013-06-19T13:45:09Z<p>Apc00: /* Subdomain aufschalten */</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 />
Für DAViCal werden neben dem eigentlichen Sourcecode des Projekts noch die PHP-Library [http://andrew.mcmillan.net.nz/projects/awl ''Andrew's Web Libraries''] benötigt. Beides findet sich auf derselben Webseite.<br />
<br />
Die jeweils neuste Versionen befinden sich unter<br />
* DAViCal: http://debian.mcmillan.net.nz/packages/davical/<br />
* AWL: http://debian.mcmillan.net.nz/packages/awl/<br />
<br />
Hier jeweils die Source-Dateien *.tar.gz benutzen<br />
<br />
==== Download ====<br />
<br />
<pre><nowiki><br />
$ cd /home/doms/cal.example.org/var<br />
$ wget http://debian.mcmillan.net.nz/packages/awl/awl-0.46.tar.gz<br />
$ wget http://debian.mcmillan.net.nz/packages/davical/davical-0.9.9.4.tar.gz<br />
</nowiki></pre><br />
<br />
==== Auspacken ====<br />
Um die Dateien für den Betrieb in der Serverumgebung lesbar zu machen wird die Dateierzeungsmaske temporär auf 022 gesetzt.<br />
<br />
Symbolische Links erzeugen generische Verzeichnise <tt>davical</tt> und <tt>awl</tt>, die auf die jeweils installierte Version zeigen. Dies erleichtert spätere Versionswechsel.<br />
<pre><nowiki><br />
$ umask 022<br />
$ tar xfvz awl-0.46.tar.gz<br />
$ tar xfvz davical-0.9.9.4.tar.gz<br />
$ ln -s awl-0.46 awl<br />
$ ln -s davical-0.9.9.4 davical<br />
$ umask 077<br />
</nowiki></pre><br />
<br />
=== PostgreSQL vorbereiten ===<br />
<br />
Es wird eine eigene PostgreSQL-Datenbank benötigt, sowie 2 Datenbanknutzer.<br />
<br />
==== Datenbank und -Nutzer anlegen ====<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 administrative Tätigkeiten durchführt<br />
|-<br />
| DB-Nutzer || <tt>xyz00_davical_app</tt> || Der PostgreSQL-Nutzer, der über DAViCal auf die Datenbank lesen/schreibend zugreift<br />
|-<br />
| Datenbank || <tt>xyz00_davical</tt> || Die Datenbank, die alle Daten für den DAViCal-Server enthält<br />
|}<br />
<br />
==== Umgebungsvariablen und <tt>.pgpass</tt> ====<br />
Die Nutzer und die Datenbank können über [[Hsadmin]] angelegt werden. Dabei wird <tt>xyz00_davical_dba</tt> als Datenbank-Besitzer angegeben. Als Zeichensatz <tt>UTF-8</tt> (Default) auswählen.<br />
<br />
Sowohl für die weitere Installation, als auch für den Betrieb des Servers ist es am besten die Passwörter in die <tt>[http://www.postgresql.org/docs/9.0/interactive/libpq-pgpass.html .pgpass]</tt>-Datei zu schreiben, dann müssen sie nicht innerhalb der PHP-Dateien angebenen werden, bzw. 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 />
Darüberhinaus werden noch Umgebungsvariablen gesetzt, so daß beim Aufruf von <tt>psql</tt> über die Kommandozeile Datenbankname/Nutzer nicht eingegeben werden müssen. Diese Angaben sind nach Beenden der Shell-Sitzung automatisch zurückgesetzt.<br />
<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 kann folgendermaßen angelegt werden:<br />
<br />
<pre><nowiki><br />
$ psql -A -c "CREATE LANGUAGE plpgsql;"<br />
</nowiki></pre><br />
<br />
=== Datenbank-Tabellen anlegen und initialisieren ===<br />
<br />
DAViCal enthält ein eigenes Installations-Skript, das die PostgreSQL-Tabellen anlegt und initialisiert. Dies liegt unter <tt>davical/dba/create-database.sh</tt>. Hier wird aber davon ausgegegangen, daß man Adminrechte hat, was in der Shared-Hosting-Umgebung nicht der Fall ist.<br />
<br />
Das Anlegen der Datenbank, der -Nuter und kreieren von PL/pgSQL wurde bereits oben beschrieben. Darüberhinaus sind noch folgende Befehle auszuführen. Diese können in dieser Form einfach nacheinander ausgeführt werden, wenn wie oben beschrieben die <tt>PG*</tt> Umgebungsvariablen gesetzt wurden und die <tt>.pgpass</tt>-Datei gefüllt 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 />
The database is version 8.4 currently at revision 1.2.9. <br />
No patches were applied. <br />
Supported locales updated. <br />
Updated view: dav_principal.sql applied. <br />
CalDAV functions updated. <br />
RRULE functions updated. <br />
Database permissions updated. <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 kann über eine <tt>config.php</tt> konfigriert werden. Eine Beispiel-Datei ist unten abgebildet. Details sind im [http://wiki.davical.org/w/Configuration DAViCal-Wiki] zu finden.<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 Header normalerweise nicht weitergeleitet. Dieses Problem wird auch im DAViCal-Wiki in einem entsprechenden [http://wiki.davical.org/w/FastCGI FAQ-Eintrag] behandelt, aber dort unter der Annahme gelöst, daß man Adminrechte hat.<br />
<br />
In der Shared-Hosting-Umgebung von Hostsharing kann dies auch über ein Redirect in der <tt>.htaccess</tt>-Datei gemacht gelöst werden:<br />
<br />
<pre><nowiki><br />
$ cd /home/doms/cal.example.org/htdocs-ssl<br />
$ cat >> .htaccess<br />
RewriteEngine on<br />
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization},L]<br />
^D<br />
</nowiki></pre><br />
<br />
Diese Regel muß die letzte in der <tt>.htaccess</tt> sein. Die Datei muß für alle lesbar sein:<br />
<br />
<pre><nowiki><br />
$ chmod 0644 .htaccess<br />
</nowiki></pre><br />
<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 />
@@ -87,8 +87,8 @@<br />
/**<br />
* Get HTTP Auth to work with PHP+FastCGI<br />
*/<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 />
[[Bild:DAViCAl-home.png|miniatur|400px|right|Screenshot DAViCal Einloggen]]<br />
=== Webspace aktivieren ===<br />
<br />
Schließlich muß die Installation noch mit dem Webspace verknüpft werden.<br />
<pre><nowiki><br />
$ cd /home/doms/cal.example.org<br />
$ rm htdocs-ssl<br />
$ ln -s var/davical/htdocs htdocs-ssl<br />
</nowiki></pre><br />
<br />
Die URL des User-Interfaces lautet: '''<tt><nowiki>https://cal.example.org</nowiki></tt>'''<br />
<br />
Wenn alles richtig gemacht wurde, erscheint der Login-Screen.<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 Email-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: Email 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 />
<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>Apc00https://wiki.hostsharing.net/index.php?title=DAViCal_installieren&diff=3595DAViCal installieren2013-06-19T13:42:26Z<p>Apc00: /* Design */</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 />
Für diese Anleitung werden folgende Daten als Konvention angenommen<br />
<br />
{| class="wikitable"<br />
|- class="hintergrundfarbe5"<br />
! Typ !! Wert !! Beschreibung<br />
|-<br />
| (Sub)-Domain || <tt>cal.example.org</tt> || Die Sub-Domain unter der der DAViCal-Server betrieben wird<br />
|-<br />
| Domain-Admin || <tt>xyz00-hans</tt> || Der User, dem die Sub-Domain delegiert wurde<br />
|}<br />
<br />
=== Quellen ===<br />
<br />
Für DAViCal werden neben dem eigentlichen Sourcecode des Projekts noch die PHP-Library [http://andrew.mcmillan.net.nz/projects/awl ''Andrew's Web Libraries''] benötigt. Beides findet sich auf derselben Webseite.<br />
<br />
Die jeweils neuste Versionen befinden sich unter<br />
* DAViCal: http://debian.mcmillan.net.nz/packages/davical/<br />
* AWL: http://debian.mcmillan.net.nz/packages/awl/<br />
<br />
Hier jeweils die Source-Dateien *.tar.gz benutzen<br />
<br />
==== Download ====<br />
<br />
<pre><nowiki><br />
$ cd /home/doms/cal.example.org/var<br />
$ wget http://debian.mcmillan.net.nz/packages/awl/awl-0.46.tar.gz<br />
$ wget http://debian.mcmillan.net.nz/packages/davical/davical-0.9.9.4.tar.gz<br />
</nowiki></pre><br />
<br />
==== Auspacken ====<br />
Um die Dateien für den Betrieb in der Serverumgebung lesbar zu machen wird die Dateierzeungsmaske temporär auf 022 gesetzt.<br />
<br />
Symbolische Links erzeugen generische Verzeichnise <tt>davical</tt> und <tt>awl</tt>, die auf die jeweils installierte Version zeigen. Dies erleichtert spätere Versionswechsel.<br />
<pre><nowiki><br />
$ umask 022<br />
$ tar xfvz awl-0.46.tar.gz<br />
$ tar xfvz davical-0.9.9.4.tar.gz<br />
$ ln -s awl-0.46 awl<br />
$ ln -s davical-0.9.9.4 davical<br />
$ umask 077<br />
</nowiki></pre><br />
<br />
=== PostgreSQL vorbereiten ===<br />
<br />
Es wird eine eigene PostgreSQL-Datenbank benötigt, sowie 2 Datenbanknutzer.<br />
<br />
==== Datenbank und -Nutzer anlegen ====<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 administrative Tätigkeiten durchführt<br />
|-<br />
| DB-Nutzer || <tt>xyz00_davical_app</tt> || Der PostgreSQL-Nutzer, der über DAViCal auf die Datenbank lesen/schreibend zugreift<br />
|-<br />
| Datenbank || <tt>xyz00_davical</tt> || Die Datenbank, die alle Daten für den DAViCal-Server enthält<br />
|}<br />
<br />
==== Umgebungsvariablen und <tt>.pgpass</tt> ====<br />
Die Nutzer und die Datenbank können über [[Hsadmin]] angelegt werden. Dabei wird <tt>xyz00_davical_dba</tt> als Datenbank-Besitzer angegeben. Als Zeichensatz <tt>UTF-8</tt> (Default) auswählen.<br />
<br />
Sowohl für die weitere Installation, als auch für den Betrieb des Servers ist es am besten die Passwörter in die <tt>[http://www.postgresql.org/docs/9.0/interactive/libpq-pgpass.html .pgpass]</tt>-Datei zu schreiben, dann müssen sie nicht innerhalb der PHP-Dateien angebenen werden, bzw. 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 />
Darüberhinaus werden noch Umgebungsvariablen gesetzt, so daß beim Aufruf von <tt>psql</tt> über die Kommandozeile Datenbankname/Nutzer nicht eingegeben werden müssen. Diese Angaben sind nach Beenden der Shell-Sitzung automatisch zurückgesetzt.<br />
<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 kann folgendermaßen angelegt werden:<br />
<br />
<pre><nowiki><br />
$ psql -A -c "CREATE LANGUAGE plpgsql;"<br />
</nowiki></pre><br />
<br />
=== Datenbank-Tabellen anlegen und initialisieren ===<br />
<br />
DAViCal enthält ein eigenes Installations-Skript, das die PostgreSQL-Tabellen anlegt und initialisiert. Dies liegt unter <tt>davical/dba/create-database.sh</tt>. Hier wird aber davon ausgegegangen, daß man Adminrechte hat, was in der Shared-Hosting-Umgebung nicht der Fall ist.<br />
<br />
Das Anlegen der Datenbank, der -Nuter und kreieren von PL/pgSQL wurde bereits oben beschrieben. Darüberhinaus sind noch folgende Befehle auszuführen. Diese können in dieser Form einfach nacheinander ausgeführt werden, wenn wie oben beschrieben die <tt>PG*</tt> Umgebungsvariablen gesetzt wurden und die <tt>.pgpass</tt>-Datei gefüllt 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 />
The database is version 8.4 currently at revision 1.2.9. <br />
No patches were applied. <br />
Supported locales updated. <br />
Updated view: dav_principal.sql applied. <br />
CalDAV functions updated. <br />
RRULE functions updated. <br />
Database permissions updated. <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 kann über eine <tt>config.php</tt> konfigriert werden. Eine Beispiel-Datei ist unten abgebildet. Details sind im [http://wiki.davical.org/w/Configuration DAViCal-Wiki] zu finden.<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 Header normalerweise nicht weitergeleitet. Dieses Problem wird auch im DAViCal-Wiki in einem entsprechenden [http://wiki.davical.org/w/FastCGI FAQ-Eintrag] behandelt, aber dort unter der Annahme gelöst, daß man Adminrechte hat.<br />
<br />
In der Shared-Hosting-Umgebung von Hostsharing kann dies auch über ein Redirect in der <tt>.htaccess</tt>-Datei gemacht gelöst werden:<br />
<br />
<pre><nowiki><br />
$ cd /home/doms/cal.example.org/htdocs-ssl<br />
$ cat >> .htaccess<br />
RewriteEngine on<br />
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization},L]<br />
^D<br />
</nowiki></pre><br />
<br />
Diese Regel muß die letzte in der <tt>.htaccess</tt> sein. Die Datei muß für alle lesbar sein:<br />
<br />
<pre><nowiki><br />
$ chmod 0644 .htaccess<br />
</nowiki></pre><br />
<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 />
@@ -87,8 +87,8 @@<br />
/**<br />
* Get HTTP Auth to work with PHP+FastCGI<br />
*/<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 />
[[Bild:DAViCAl-home.png|miniatur|400px|right|Screenshot DAViCal Einloggen]]<br />
=== Webspace aktivieren ===<br />
<br />
Schließlich muß die Installation noch mit dem Webspace verknüpft werden.<br />
<pre><nowiki><br />
$ cd /home/doms/cal.example.org<br />
$ rm htdocs-ssl<br />
$ ln -s var/davical/htdocs htdocs-ssl<br />
</nowiki></pre><br />
<br />
Die URL des User-Interfaces lautet: '''<tt><nowiki>https://cal.example.org</nowiki></tt>'''<br />
<br />
Wenn alles richtig gemacht wurde, erscheint der Login-Screen.<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 Email-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: Email 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 />
<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>Apc00https://wiki.hostsharing.net/index.php?title=Domainverwaltung&diff=3594Domainverwaltung2013-06-18T16:41:33Z<p>Apc00: /* Adresse von Owner / Admin-C ändern */</p>
<hr />
<div>{{HSDoku-DomainLinks}}<br />
<br />
= Lokale Subdomains =<br />
<br />
Subdomains sind Domains unterhalb der Hauptdomain. Also das www in www.example.com, test in test.example.com usw. Bei Hostsharing können beliebig viele verschiedene Subdomains angelegt werden.<br />
<br />
== Lokale Subdomains durch Unterverzeichnis in <tt>doms/''domain''/subs/</tt> ==<br />
<br />
Man kann eine Subdomain erstellen, indem man unter <tt>[[~/]]doms/''example.org''/subs/</tt> ein Unterverzeichnis erstellt.<br />
<br />
Ein Unterverzeichnis mit dem Namen <tt>[[~/]]doms/''example.org''/subs/''muster''</tt> ergibt beispielsweise die Subdomain <tt>muster.example.org</tt>.<br />
<br />
== Lokale Subdomains durch Aufschalten; Delegieren ==<br />
<br />
"Aufschalten" bedeutet in der Hostsharing-Doku, daß eine Subdomain so eingerichtet wird, daß sie neben der Hauptdomain eine eigene Existenz führt, sowohl als Verzeichnis unter <tt>[[~/]]doms/</tt> als auch im DNS.<br />
<br />
Eine Subdomain wie muster.example.org kann dabei im gleichen Paket mit der Hauptdomain example.org oder ib einem anderen Paket aufgeschaltet werden.<br />
<br />
* Wenn die Subdomain zum gleichen Paket wie die übergeordnete Domain gehören soll, kann sie der Paket-Admin mittels [[HSAdmin]] einrichten.<br />
<br />
* Wenn die Subdomain zu einem anderen Paket des gleichen HS-Mitglieds gehören soll, kann sie der Paket-Admin unter seinem Mitgliedsaccount (hsh00-xyz) mittels [[HSAdmin]] einrichten.<br />
<br />
* Wenn die Subdomain an ein anderes Mitglied delegiert werden soll, müssen sich beide Mitglieder mit diesem Wunsch an den Hostsharing-Service wenden. Der Hostsharing-Service richtet die Subdomain ein, wenn ihm übereinstimmende Willenserklärungen der beteiligten Mitglieder vorliegen.<br />
<br />
= Eine bestehende Domain einem neuen Domain-Admin oder einem anderen Paket zuordnen =<br />
<br />
Um eine Domain zu verschieben, also einem anderen Admin zuzuordnen, wird grundsätzlich über HSAdmin die Domain gelöscht und neu angelegt. Da die eigentliche Registrierung über das [http://www.domain-bestellsystem.de Domainbestellsystem] erfolgt, bleibt der Eigentümer der Domain unverändert.<br />
<br />
'''Achtung:''' Das Verzeichnis <tt>~/doms/''example.org''/, also alle Dateien im Webspace, wird bei dieser Aktion komplett gelöscht! Der Bestand muß vorher manuell gesichert werden (zum Beispiel als <tt>tar</tt>-Archiv)! Auch die Mailadressen der betreffenden Domain gehen verloren und müssen ggf. neu eingetragen werden!<br />
<br />
Der Hostsharing-Service (service@hostsharing.net) kann auch Verschiebungen mit minimalen Ausfallzeiten bei aufwandsabhängiger Abrechnung gemäß dem Hostmaster-Stundensatz durchführen.<br />
<br />
= Status der Domaineinrichtung =<br />
Der Status eines Domaineinrichtungsvorgangs kann mit dem hsadmin-[[WebFrontend]] oder mit [[hsadmin]] in der [[Shell]] eingesehen werden:<br />
<br />
<pre><br />
hsadmin -c domain.search<br />
</pre><br />
<br />
= Adresse von Owner / Admin-C ändern =<br />
Um die Adressdaten des Domain-Inhabers zu ändern, aktualisiere den zugehörigen [[Handle]] im [https://www.domain-bestellsystem.de Domain-Bestellsystem].<br />
<br />
= Eigene Verwaltung der Zonefiles =<br />
Siehe [[Verwalten der Zonendaten]].<br />
<br />
<br />
[[Kategorie:HSDoku]]<br />
[[Kategorie:Domains]]<br />
[[Kategorie:Hsadmin]]</div>Apc00https://wiki.hostsharing.net/index.php?title=Domainverwaltung&diff=3593Domainverwaltung2013-06-18T16:40:20Z<p>Apc00: /* Status der Domaineinrichtung */</p>
<hr />
<div>{{HSDoku-DomainLinks}}<br />
<br />
= Lokale Subdomains =<br />
<br />
Subdomains sind Domains unterhalb der Hauptdomain. Also das www in www.example.com, test in test.example.com usw. Bei Hostsharing können beliebig viele verschiedene Subdomains angelegt werden.<br />
<br />
== Lokale Subdomains durch Unterverzeichnis in <tt>doms/''domain''/subs/</tt> ==<br />
<br />
Man kann eine Subdomain erstellen, indem man unter <tt>[[~/]]doms/''example.org''/subs/</tt> ein Unterverzeichnis erstellt.<br />
<br />
Ein Unterverzeichnis mit dem Namen <tt>[[~/]]doms/''example.org''/subs/''muster''</tt> ergibt beispielsweise die Subdomain <tt>muster.example.org</tt>.<br />
<br />
== Lokale Subdomains durch Aufschalten; Delegieren ==<br />
<br />
"Aufschalten" bedeutet in der Hostsharing-Doku, daß eine Subdomain so eingerichtet wird, daß sie neben der Hauptdomain eine eigene Existenz führt, sowohl als Verzeichnis unter <tt>[[~/]]doms/</tt> als auch im DNS.<br />
<br />
Eine Subdomain wie muster.example.org kann dabei im gleichen Paket mit der Hauptdomain example.org oder ib einem anderen Paket aufgeschaltet werden.<br />
<br />
* Wenn die Subdomain zum gleichen Paket wie die übergeordnete Domain gehören soll, kann sie der Paket-Admin mittels [[HSAdmin]] einrichten.<br />
<br />
* Wenn die Subdomain zu einem anderen Paket des gleichen HS-Mitglieds gehören soll, kann sie der Paket-Admin unter seinem Mitgliedsaccount (hsh00-xyz) mittels [[HSAdmin]] einrichten.<br />
<br />
* Wenn die Subdomain an ein anderes Mitglied delegiert werden soll, müssen sich beide Mitglieder mit diesem Wunsch an den Hostsharing-Service wenden. Der Hostsharing-Service richtet die Subdomain ein, wenn ihm übereinstimmende Willenserklärungen der beteiligten Mitglieder vorliegen.<br />
<br />
= Eine bestehende Domain einem neuen Domain-Admin oder einem anderen Paket zuordnen =<br />
<br />
Um eine Domain zu verschieben, also einem anderen Admin zuzuordnen, wird grundsätzlich über HSAdmin die Domain gelöscht und neu angelegt. Da die eigentliche Registrierung über das [http://www.domain-bestellsystem.de Domainbestellsystem] erfolgt, bleibt der Eigentümer der Domain unverändert.<br />
<br />
'''Achtung:''' Das Verzeichnis <tt>~/doms/''example.org''/, also alle Dateien im Webspace, wird bei dieser Aktion komplett gelöscht! Der Bestand muß vorher manuell gesichert werden (zum Beispiel als <tt>tar</tt>-Archiv)! Auch die Mailadressen der betreffenden Domain gehen verloren und müssen ggf. neu eingetragen werden!<br />
<br />
Der Hostsharing-Service (service@hostsharing.net) kann auch Verschiebungen mit minimalen Ausfallzeiten bei aufwandsabhängiger Abrechnung gemäß dem Hostmaster-Stundensatz durchführen.<br />
<br />
= Status der Domaineinrichtung =<br />
Der Status eines Domaineinrichtungsvorgangs kann mit dem hsadmin-[[WebFrontend]] oder mit [[hsadmin]] in der [[Shell]] eingesehen werden:<br />
<br />
<pre><br />
hsadmin -c domain.search<br />
</pre><br />
<br />
= Adresse von Owner / Admin-C ändern =<br />
Die Änderung der Adressdaten erfolgt, indem die Adressdaten des zugehörigen [[Handles]] im [https://www.domain-bestellsystem.de Domain-Bestellsystem] aktualisiert werden.<br />
<br />
= Eigene Verwaltung der Zonefiles =<br />
Siehe [[Verwalten der Zonendaten]].<br />
<br />
<br />
[[Kategorie:HSDoku]]<br />
[[Kategorie:Domains]]<br />
[[Kategorie:Hsadmin]]</div>Apc00https://wiki.hostsharing.net/index.php?title=Domainverwaltung&diff=3592Domainverwaltung2013-06-18T16:34:44Z<p>Apc00: /* Domains neu zuordnen (Domain-Admin ändern, Paketzuordnung ändern) */</p>
<hr />
<div>{{HSDoku-DomainLinks}}<br />
<br />
= Lokale Subdomains =<br />
<br />
Subdomains sind Domains unterhalb der Hauptdomain. Also das www in www.example.com, test in test.example.com usw. Bei Hostsharing können beliebig viele verschiedene Subdomains angelegt werden.<br />
<br />
== Lokale Subdomains durch Unterverzeichnis in <tt>doms/''domain''/subs/</tt> ==<br />
<br />
Man kann eine Subdomain erstellen, indem man unter <tt>[[~/]]doms/''example.org''/subs/</tt> ein Unterverzeichnis erstellt.<br />
<br />
Ein Unterverzeichnis mit dem Namen <tt>[[~/]]doms/''example.org''/subs/''muster''</tt> ergibt beispielsweise die Subdomain <tt>muster.example.org</tt>.<br />
<br />
== Lokale Subdomains durch Aufschalten; Delegieren ==<br />
<br />
"Aufschalten" bedeutet in der Hostsharing-Doku, daß eine Subdomain so eingerichtet wird, daß sie neben der Hauptdomain eine eigene Existenz führt, sowohl als Verzeichnis unter <tt>[[~/]]doms/</tt> als auch im DNS.<br />
<br />
Eine Subdomain wie muster.example.org kann dabei im gleichen Paket mit der Hauptdomain example.org oder ib einem anderen Paket aufgeschaltet werden.<br />
<br />
* Wenn die Subdomain zum gleichen Paket wie die übergeordnete Domain gehören soll, kann sie der Paket-Admin mittels [[HSAdmin]] einrichten.<br />
<br />
* Wenn die Subdomain zu einem anderen Paket des gleichen HS-Mitglieds gehören soll, kann sie der Paket-Admin unter seinem Mitgliedsaccount (hsh00-xyz) mittels [[HSAdmin]] einrichten.<br />
<br />
* Wenn die Subdomain an ein anderes Mitglied delegiert werden soll, müssen sich beide Mitglieder mit diesem Wunsch an den Hostsharing-Service wenden. Der Hostsharing-Service richtet die Subdomain ein, wenn ihm übereinstimmende Willenserklärungen der beteiligten Mitglieder vorliegen.<br />
<br />
= Eine bestehende Domain einem neuen Domain-Admin oder einem anderen Paket zuordnen =<br />
<br />
Um eine Domain zu verschieben, also einem anderen Admin zuzuordnen, wird grundsätzlich über HSAdmin die Domain gelöscht und neu angelegt. Da die eigentliche Registrierung über das [http://www.domain-bestellsystem.de Domainbestellsystem] erfolgt, bleibt der Eigentümer der Domain unverändert.<br />
<br />
'''Achtung:''' Das Verzeichnis <tt>~/doms/''example.org''/, also alle Dateien im Webspace, wird bei dieser Aktion komplett gelöscht! Der Bestand muß vorher manuell gesichert werden (zum Beispiel als <tt>tar</tt>-Archiv)! Auch die Mailadressen der betreffenden Domain gehen verloren und müssen ggf. neu eingetragen werden!<br />
<br />
Der Hostsharing-Service (service@hostsharing.net) kann auch Verschiebungen mit minimalen Ausfallzeiten bei aufwandsabhängiger Abrechnung gemäß dem Hostmaster-Stundensatz durchführen.<br />
<br />
= Status der Domaineinrichtung =<br />
Der Domaineinrichtungs-Status kann mit dem hsadmin-[[WebFrontend]] eingesehen werden oder mit [[hsadmin]] auf der Kommandozeile der [[Shell]]:<br />
<br />
<pre><br />
hsadmin -c domain.search<br />
</pre><br />
<br />
= Adresse von Owner / Admin-C ändern =<br />
Die Änderung der Adressdaten erfolgt, indem die Adressdaten des zugehörigen [[Handles]] im [https://www.domain-bestellsystem.de Domain-Bestellsystem] aktualisiert werden.<br />
<br />
= Eigene Verwaltung der Zonefiles =<br />
Siehe [[Verwalten der Zonendaten]].<br />
<br />
<br />
[[Kategorie:HSDoku]]<br />
[[Kategorie:Domains]]<br />
[[Kategorie:Hsadmin]]</div>Apc00https://wiki.hostsharing.net/index.php?title=Domainverwaltung&diff=3591Domainverwaltung2013-06-18T16:27:10Z<p>Apc00: </p>
<hr />
<div>{{HSDoku-DomainLinks}}<br />
<br />
= Lokale Subdomains =<br />
<br />
Subdomains sind Domains unterhalb der Hauptdomain. Also das www in www.example.com, test in test.example.com usw. Bei Hostsharing können beliebig viele verschiedene Subdomains angelegt werden.<br />
<br />
== Lokale Subdomains durch Unterverzeichnis in <tt>doms/''domain''/subs/</tt> ==<br />
<br />
Man kann eine Subdomain erstellen, indem man unter <tt>[[~/]]doms/''example.org''/subs/</tt> ein Unterverzeichnis erstellt.<br />
<br />
Ein Unterverzeichnis mit dem Namen <tt>[[~/]]doms/''example.org''/subs/''muster''</tt> ergibt beispielsweise die Subdomain <tt>muster.example.org</tt>.<br />
<br />
== Lokale Subdomains durch Aufschalten; Delegieren ==<br />
<br />
"Aufschalten" bedeutet in der Hostsharing-Doku, daß eine Subdomain so eingerichtet wird, daß sie neben der Hauptdomain eine eigene Existenz führt, sowohl als Verzeichnis unter <tt>[[~/]]doms/</tt> als auch im DNS.<br />
<br />
Eine Subdomain wie muster.example.org kann dabei im gleichen Paket mit der Hauptdomain example.org oder ib einem anderen Paket aufgeschaltet werden.<br />
<br />
* Wenn die Subdomain zum gleichen Paket wie die übergeordnete Domain gehören soll, kann sie der Paket-Admin mittels [[HSAdmin]] einrichten.<br />
<br />
* Wenn die Subdomain zu einem anderen Paket des gleichen HS-Mitglieds gehören soll, kann sie der Paket-Admin unter seinem Mitgliedsaccount (hsh00-xyz) mittels [[HSAdmin]] einrichten.<br />
<br />
* Wenn die Subdomain an ein anderes Mitglied delegiert werden soll, müssen sich beide Mitglieder mit diesem Wunsch an den Hostsharing-Service wenden. Der Hostsharing-Service richtet die Subdomain ein, wenn ihm übereinstimmende Willenserklärungen der beteiligten Mitglieder vorliegen.<br />
<br />
= Domains neu zuordnen (Domain-Admin ändern, Paketzuordnung ändern) =<br />
<br />
Eine Domain-Verschiebung (neu zuordnen) wird ebenfalls über die DNS Delegation gemacht und erfolgt grundsätzlich über HSAdmin durch Löschen und Neuanlegen der Domain. Da die eigentliche Registrierung über das [http://www.domain-bestellsystem.de Domainbestellsystem] erfolgt, bleibt der Eigentümer der betreffenden Domain durch die Löschung über HSAdmin unverändert.<br />
<br />
'''Achtung:''' Das ~/doms/example.org Verzeichnis, also alle Dateien im Webspace werden bei dieser Aktion komplett gelöscht. Sie müssen vorher manuell (am Besten in einem tar-archiv) gesichert werden! Auch die Zuordnung von Mailadressen der betreffenden Domain geht verloren und muß ggf. neu eingetragen werden.<br />
<br />
Der Hostsharing-Service (service@hostsharing.net) kann auch Verschiebungen mit minimalen Ausfallzeiten durchführen, bei aufwandsabhängiger Abrechnung gemäß dem Hostmaster-Stundensatz.<br />
<br />
= Status der Domaineinrichtung =<br />
Der Domaineinrichtungs-Status kann mit dem hsadmin-[[WebFrontend]] eingesehen werden oder mit [[hsadmin]] auf der Kommandozeile der [[Shell]]:<br />
<br />
<pre><br />
hsadmin -c domain.search<br />
</pre><br />
<br />
= Adresse von Owner / Admin-C ändern =<br />
Die Änderung der Adressdaten erfolgt, indem die Adressdaten des zugehörigen [[Handles]] im [https://www.domain-bestellsystem.de Domain-Bestellsystem] aktualisiert werden.<br />
<br />
= Eigene Verwaltung der Zonefiles =<br />
Siehe [[Verwalten der Zonendaten]].<br />
<br />
<br />
[[Kategorie:HSDoku]]<br />
[[Kategorie:Domains]]<br />
[[Kategorie:Hsadmin]]</div>Apc00https://wiki.hostsharing.net/index.php?title=DAViCal_installieren&diff=3590DAViCal installieren2013-06-18T16:24:17Z<p>Apc00: klarere, genauere Sätze</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>''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 den übrigen Domaininhalten isoliert werden kann, z.B. php-Konfiguration oder auch anderen Domain-Admin.<br />
<br />
=== Subdomain aufschalten ===<br />
<br />
Für diese Anleitung werden folgende Daten als Konvention angenommen<br />
<br />
{| class="wikitable"<br />
|- class="hintergrundfarbe5"<br />
! Typ !! Wert !! Beschreibung<br />
|-<br />
| (Sub)-Domain || <tt>cal.example.org</tt> || Die Sub-Domain unter der der DAViCal-Server betrieben wird<br />
|-<br />
| Domain-Admin || <tt>xyz00-hans</tt> || Der User, dem die Sub-Domain delegiert wurde<br />
|}<br />
<br />
=== Quellen ===<br />
<br />
Für DAViCal werden neben dem eigentlichen Sourcecode des Projekts noch die PHP-Library [http://andrew.mcmillan.net.nz/projects/awl ''Andrew's Web Libraries''] benötigt. Beides findet sich auf derselben Webseite.<br />
<br />
Die jeweils neuste Versionen befinden sich unter<br />
* DAViCal: http://debian.mcmillan.net.nz/packages/davical/<br />
* AWL: http://debian.mcmillan.net.nz/packages/awl/<br />
<br />
Hier jeweils die Source-Dateien *.tar.gz benutzen<br />
<br />
==== Download ====<br />
<br />
<pre><nowiki><br />
$ cd /home/doms/cal.example.org/var<br />
$ wget http://debian.mcmillan.net.nz/packages/awl/awl-0.46.tar.gz<br />
$ wget http://debian.mcmillan.net.nz/packages/davical/davical-0.9.9.4.tar.gz<br />
</nowiki></pre><br />
<br />
==== Auspacken ====<br />
Um die Dateien für den Betrieb in der Serverumgebung lesbar zu machen wird die Dateierzeungsmaske temporär auf 022 gesetzt.<br />
<br />
Symbolische Links erzeugen generische Verzeichnise <tt>davical</tt> und <tt>awl</tt>, die auf die jeweils installierte Version zeigen. Dies erleichtert spätere Versionswechsel.<br />
<pre><nowiki><br />
$ umask 022<br />
$ tar xfvz awl-0.46.tar.gz<br />
$ tar xfvz davical-0.9.9.4.tar.gz<br />
$ ln -s awl-0.46 awl<br />
$ ln -s davical-0.9.9.4 davical<br />
$ umask 077<br />
</nowiki></pre><br />
<br />
=== PostgreSQL vorbereiten ===<br />
<br />
Es wird eine eigene PostgreSQL-Datenbank benötigt, sowie 2 Datenbanknutzer.<br />
<br />
==== Datenbank und -Nutzer anlegen ====<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 administrative Tätigkeiten durchführt<br />
|-<br />
| DB-Nutzer || <tt>xyz00_davical_app</tt> || Der PostgreSQL-Nutzer, der über DAViCal auf die Datenbank lesen/schreibend zugreift<br />
|-<br />
| Datenbank || <tt>xyz00_davical</tt> || Die Datenbank, die alle Daten für den DAViCal-Server enthält<br />
|}<br />
<br />
==== Umgebungsvariablen und <tt>.pgpass</tt> ====<br />
Die Nutzer und die Datenbank können über [[Hsadmin]] angelegt werden. Dabei wird <tt>xyz00_davical_dba</tt> als Datenbank-Besitzer angegeben. Als Zeichensatz <tt>UTF-8</tt> (Default) auswählen.<br />
<br />
Sowohl für die weitere Installation, als auch für den Betrieb des Servers ist es am besten die Passwörter in die <tt>[http://www.postgresql.org/docs/9.0/interactive/libpq-pgpass.html .pgpass]</tt>-Datei zu schreiben, dann müssen sie nicht innerhalb der PHP-Dateien angebenen werden, bzw. 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 />
Darüberhinaus werden noch Umgebungsvariablen gesetzt, so daß beim Aufruf von <tt>psql</tt> über die Kommandozeile Datenbankname/Nutzer nicht eingegeben werden müssen. Diese Angaben sind nach Beenden der Shell-Sitzung automatisch zurückgesetzt.<br />
<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 kann folgendermaßen angelegt werden:<br />
<br />
<pre><nowiki><br />
$ psql -A -c "CREATE LANGUAGE plpgsql;"<br />
</nowiki></pre><br />
<br />
=== Datenbank-Tabellen anlegen und initialisieren ===<br />
<br />
DAViCal enthält ein eigenes Installations-Skript, das die PostgreSQL-Tabellen anlegt und initialisiert. Dies liegt unter <tt>davical/dba/create-database.sh</tt>. Hier wird aber davon ausgegegangen, daß man Adminrechte hat, was in der Shared-Hosting-Umgebung nicht der Fall ist.<br />
<br />
Das Anlegen der Datenbank, der -Nuter und kreieren von PL/pgSQL wurde bereits oben beschrieben. Darüberhinaus sind noch folgende Befehle auszuführen. Diese können in dieser Form einfach nacheinander ausgeführt werden, wenn wie oben beschrieben die <tt>PG*</tt> Umgebungsvariablen gesetzt wurden und die <tt>.pgpass</tt>-Datei gefüllt 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 />
The database is version 8.4 currently at revision 1.2.9. <br />
No patches were applied. <br />
Supported locales updated. <br />
Updated view: dav_principal.sql applied. <br />
CalDAV functions updated. <br />
RRULE functions updated. <br />
Database permissions updated. <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 kann über eine <tt>config.php</tt> konfigriert werden. Eine Beispiel-Datei ist unten abgebildet. Details sind im [http://wiki.davical.org/w/Configuration DAViCal-Wiki] zu finden.<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 Header normalerweise nicht weitergeleitet. Dieses Problem wird auch im DAViCal-Wiki in einem entsprechenden [http://wiki.davical.org/w/FastCGI FAQ-Eintrag] behandelt, aber dort unter der Annahme gelöst, daß man Adminrechte hat.<br />
<br />
In der Shared-Hosting-Umgebung von Hostsharing kann dies auch über ein Redirect in der <tt>.htaccess</tt>-Datei gemacht gelöst werden:<br />
<br />
<pre><nowiki><br />
$ cd /home/doms/cal.example.org/htdocs-ssl<br />
$ cat >> .htaccess<br />
RewriteEngine on<br />
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization},L]<br />
^D<br />
</nowiki></pre><br />
<br />
Diese Regel muß die letzte in der <tt>.htaccess</tt> sein. Die Datei muß für alle lesbar sein:<br />
<br />
<pre><nowiki><br />
$ chmod 0644 .htaccess<br />
</nowiki></pre><br />
<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 />
@@ -87,8 +87,8 @@<br />
/**<br />
* Get HTTP Auth to work with PHP+FastCGI<br />
*/<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 />
[[Bild:DAViCAl-home.png|miniatur|400px|right|Screenshot DAViCal Einloggen]]<br />
=== Webspace aktivieren ===<br />
<br />
Schließlich muß die Installation noch mit dem Webspace verknüpft werden.<br />
<pre><nowiki><br />
$ cd /home/doms/cal.example.org<br />
$ rm htdocs-ssl<br />
$ ln -s var/davical/htdocs htdocs-ssl<br />
</nowiki></pre><br />
<br />
Die URL des User-Interfaces lautet: '''<tt><nowiki>https://cal.example.org</nowiki></tt>'''<br />
<br />
Wenn alles richtig gemacht wurde, erscheint der Login-Screen.<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 Email-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: Email 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 />
<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>Apc00https://wiki.hostsharing.net/index.php?title=Domainverwaltung&diff=3589Domainverwaltung2013-06-18T16:19:53Z<p>Apc00: Sätze klarer und eindeutiger formuliert</p>
<hr />
<div>{{HSDoku-DomainLinks}}<br />
<br />
= Lokale Subdomains =<br />
<br />
Subdomains sind Domains unterhalb der Hauptdomain. Also das www in www.example.com, test in test.example.com usw. Bei Hostsharing können beliebig viele verschiedene Subdomains angelegt werden.<br />
<br />
== Lokale Subdomains durch Unterverzeichnis in doms/'domain'/subs/ ==<br />
<br />
Man kann eine Subdomain erstellen, indem man unter [[~/]]doms/'example.org'/subs/ ein Unterverzeichnis erstellt.<br />
<br />
Ein Unterverzeichnis mit dem Namen [[~/]]doms/'example.org'/subs/muster ergibt beispielsweise die Subdomain muster.example.org.<br />
<br />
== Lokale Subdomains durch Aufschalten; Delegieren ==<br />
<br />
"Aufschalten" bedeutet in der Hostsharing-Doku, daß eine Subdomain so eingerichtet wird, daß sie neben der Hauptdomain eine eigene Existenz führt, sowohl als Verzeichnis unter [[~/]]doms/ als auch im DNS.<br />
<br />
Eine Subdomain wie muster.example.org kann dabei im gleichen Paket mit der Hauptdomain example.org oder ib einem anderen Paket aufgeschaltet werden.<br />
<br />
* Wenn die Subdomain zum gleichen Paket wie die übergeordnete Domain gehören soll, kann sie der Paket-Admin mittels [[HSAdmin]] einrichten.<br />
<br />
* Wenn die Subdomain zu einem anderen Paket des gleichen HS-Mitglieds gehören soll, kann sie der Paket-Admin unter seinem Mitgliedsaccount (hsh00-xyz) mittels [[HSAdmin]] einrichten.<br />
<br />
* Wenn die Subdomain an ein anderes Mitglied delegiert werden soll, müssen sich beide Mitglieder mit diesem Wunsch an den Hostsharing-Service wenden. Der Hostsharing-Service richtet die Subdomain ein, wenn ihm übereinstimmende Willenserklärungen der beteiligten Mitglieder vorliegen.<br />
<br />
= Domains neu zuordnen (Domain-Admin ändern, Paketzuordnung ändern) =<br />
<br />
Eine Domain-Verschiebung (neu zuordnen) wird ebenfalls über die DNS Delegation gemacht und erfolgt grundsätzlich über HSAdmin durch Löschen und Neuanlegen der Domain. Da die eigentliche Registrierung über das [http://www.domain-bestellsystem.de Domainbestellsystem] erfolgt, bleibt der Eigentümer der betreffenden Domain durch die Löschung über HSAdmin unverändert.<br />
<br />
'''Achtung:''' Das ~/doms/example.org Verzeichnis, also alle Dateien im Webspace werden bei dieser Aktion komplett gelöscht. Sie müssen vorher manuell (am Besten in einem tar-archiv) gesichert werden! Auch die Zuordnung von Mailadressen der betreffenden Domain geht verloren und muß ggf. neu eingetragen werden.<br />
<br />
Der Hostsharing-Service (service@hostsharing.net) kann auch Verschiebungen mit minimalen Ausfallzeiten durchführen, bei aufwandsabhängiger Abrechnung gemäß dem Hostmaster-Stundensatz.<br />
<br />
= Status der Domaineinrichtung =<br />
Der Domaineinrichtungs-Status kann mit dem hsadmin-[[WebFrontend]] eingesehen werden oder mit [[hsadmin]] auf der Kommandozeile der [[Shell]]:<br />
<br />
<pre><br />
hsadmin -c domain.search<br />
</pre><br />
<br />
= Adresse von Owner / Admin-C ändern =<br />
Die Änderung der Adressdaten erfolgt, indem die Adressdaten des zugehörigen [[Handles]] im [https://www.domain-bestellsystem.de Domain-Bestellsystem] aktualisiert werden.<br />
<br />
= Eigene Verwaltung der Zonefiles =<br />
Siehe [[Verwalten der Zonendaten]].<br />
<br />
<br />
[[Kategorie:HSDoku]]<br />
[[Kategorie:Domains]]<br />
[[Kategorie:Hsadmin]]</div>Apc00https://wiki.hostsharing.net/index.php?title=DAViCal_installieren&diff=3588DAViCal installieren2013-06-18T16:04:43Z<p>Apc00: Sätze klarer formuliert</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 aufgeschalteten Subdomain über SSL betrieben wird. Für andere Konfigurationen, wie z.B. Installation in einer Subdomain im <tt>sub</tt>-Verzeichnis müssen kleine Anpassungen vorgenommen werden.<br />
<br />
Der Vorteil einer Installation in einer aufgeschalteten Subdomain ist, daß die Installation leicht von den übrigen Domaininhalten isoliert werden kann, z.B. php-Konfiguration oder auch anderen Domain-Admin.<br />
<br />
=== Subdomain aufschalten ===<br />
<br />
Für diese Anleitung werden folgende Daten als Konvention angenommen<br />
<br />
{| class="wikitable"<br />
|- class="hintergrundfarbe5"<br />
! Typ !! Wert !! Beschreibung<br />
|-<br />
| (Sub)-Domain || <tt>cal.example.org</tt> || Die Sub-Domain unter der der DAViCal-Server betrieben wird<br />
|-<br />
| Domain-Admin || <tt>xyz00-hans</tt> || Der User, dem die Sub-Domain delegiert wurde<br />
|}<br />
<br />
=== Quellen ===<br />
<br />
Für DAViCal werden neben dem eigentlichen Sourcecode des Projekts noch die PHP-Library [http://andrew.mcmillan.net.nz/projects/awl ''Andrew's Web Libraries''] benötigt. Beides findet sich auf derselben Webseite.<br />
<br />
Die jeweils neuste Versionen befinden sich unter<br />
* DAViCal: http://debian.mcmillan.net.nz/packages/davical/<br />
* AWL: http://debian.mcmillan.net.nz/packages/awl/<br />
<br />
Hier jeweils die Source-Dateien *.tar.gz benutzen<br />
<br />
==== Download ====<br />
<br />
<pre><nowiki><br />
$ cd /home/doms/cal.example.org/var<br />
$ wget http://debian.mcmillan.net.nz/packages/awl/awl-0.46.tar.gz<br />
$ wget http://debian.mcmillan.net.nz/packages/davical/davical-0.9.9.4.tar.gz<br />
</nowiki></pre><br />
<br />
==== Auspacken ====<br />
Um die Dateien für den Betrieb in der Serverumgebung lesbar zu machen wird die Dateierzeungsmaske temporär auf 022 gesetzt.<br />
<br />
Symbolische Links erzeugen generische Verzeichnise <tt>davical</tt> und <tt>awl</tt>, die auf die jeweils installierte Version zeigen. Dies erleichtert spätere Versionswechsel.<br />
<pre><nowiki><br />
$ umask 022<br />
$ tar xfvz awl-0.46.tar.gz<br />
$ tar xfvz davical-0.9.9.4.tar.gz<br />
$ ln -s awl-0.46 awl<br />
$ ln -s davical-0.9.9.4 davical<br />
$ umask 077<br />
</nowiki></pre><br />
<br />
=== PostgreSQL vorbereiten ===<br />
<br />
Es wird eine eigene PostgreSQL-Datenbank benötigt, sowie 2 Datenbanknutzer.<br />
<br />
==== Datenbank und -Nutzer anlegen ====<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 administrative Tätigkeiten durchführt<br />
|-<br />
| DB-Nutzer || <tt>xyz00_davical_app</tt> || Der PostgreSQL-Nutzer, der über DAViCal auf die Datenbank lesen/schreibend zugreift<br />
|-<br />
| Datenbank || <tt>xyz00_davical</tt> || Die Datenbank, die alle Daten für den DAViCal-Server enthält<br />
|}<br />
<br />
==== Umgebungsvariablen und <tt>.pgpass</tt> ====<br />
Die Nutzer und die Datenbank können über [[Hsadmin]] angelegt werden. Dabei wird <tt>xyz00_davical_dba</tt> als Datenbank-Besitzer angegeben. Als Zeichensatz <tt>UTF-8</tt> (Default) auswählen.<br />
<br />
Sowohl für die weitere Installation, als auch für den Betrieb des Servers ist es am besten die Passwörter in die <tt>[http://www.postgresql.org/docs/9.0/interactive/libpq-pgpass.html .pgpass]</tt>-Datei zu schreiben, dann müssen sie nicht innerhalb der PHP-Dateien angebenen werden, bzw. 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 />
Darüberhinaus werden noch Umgebungsvariablen gesetzt, so daß beim Aufruf von <tt>psql</tt> über die Kommandozeile Datenbankname/Nutzer nicht eingegeben werden müssen. Diese Angaben sind nach Beenden der Shell-Sitzung automatisch zurückgesetzt.<br />
<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 kann folgendermaßen angelegt werden:<br />
<br />
<pre><nowiki><br />
$ psql -A -c "CREATE LANGUAGE plpgsql;"<br />
</nowiki></pre><br />
<br />
=== Datenbank-Tabellen anlegen und initialisieren ===<br />
<br />
DAViCal enthält ein eigenes Installations-Skript, das die PostgreSQL-Tabellen anlegt und initialisiert. Dies liegt unter <tt>davical/dba/create-database.sh</tt>. Hier wird aber davon ausgegegangen, daß man Adminrechte hat, was in der Shared-Hosting-Umgebung nicht der Fall ist.<br />
<br />
Das Anlegen der Datenbank, der -Nuter und kreieren von PL/pgSQL wurde bereits oben beschrieben. Darüberhinaus sind noch folgende Befehle auszuführen. Diese können in dieser Form einfach nacheinander ausgeführt werden, wenn wie oben beschrieben die <tt>PG*</tt> Umgebungsvariablen gesetzt wurden und die <tt>.pgpass</tt>-Datei gefüllt 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 />
The database is version 8.4 currently at revision 1.2.9. <br />
No patches were applied. <br />
Supported locales updated. <br />
Updated view: dav_principal.sql applied. <br />
CalDAV functions updated. <br />
RRULE functions updated. <br />
Database permissions updated. <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 kann über eine <tt>config.php</tt> konfigriert werden. Eine Beispiel-Datei ist unten abgebildet. Details sind im [http://wiki.davical.org/w/Configuration DAViCal-Wiki] zu finden.<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 Header normalerweise nicht weitergeleitet. Dieses Problem wird auch im DAViCal-Wiki in einem entsprechenden [http://wiki.davical.org/w/FastCGI FAQ-Eintrag] behandelt, aber dort unter der Annahme gelöst, daß man Adminrechte hat.<br />
<br />
In der Shared-Hosting-Umgebung von Hostsharing kann dies auch über ein Redirect in der <tt>.htaccess</tt>-Datei gemacht gelöst werden:<br />
<br />
<pre><nowiki><br />
$ cd /home/doms/cal.example.org/htdocs-ssl<br />
$ cat >> .htaccess<br />
RewriteEngine on<br />
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization},L]<br />
^D<br />
</nowiki></pre><br />
<br />
Diese Regel muß die letzte in der <tt>.htaccess</tt> sein. Die Datei muß für alle lesbar sein:<br />
<br />
<pre><nowiki><br />
$ chmod 0644 .htaccess<br />
</nowiki></pre><br />
<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 />
@@ -87,8 +87,8 @@<br />
/**<br />
* Get HTTP Auth to work with PHP+FastCGI<br />
*/<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 />
[[Bild:DAViCAl-home.png|miniatur|400px|right|Screenshot DAViCal Einloggen]]<br />
=== Webspace aktivieren ===<br />
<br />
Schließlich muß die Installation noch mit dem Webspace verknüpft werden.<br />
<pre><nowiki><br />
$ cd /home/doms/cal.example.org<br />
$ rm htdocs-ssl<br />
$ ln -s var/davical/htdocs htdocs-ssl<br />
</nowiki></pre><br />
<br />
Die URL des User-Interfaces lautet: '''<tt><nowiki>https://cal.example.org</nowiki></tt>'''<br />
<br />
Wenn alles richtig gemacht wurde, erscheint der Login-Screen.<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 Email-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: Email 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 />
<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>Apc00https://wiki.hostsharing.net/index.php?title=Mailman_Installieren&diff=2779Mailman Installieren2010-12-29T18:44:38Z<p>Apc00: /* Installation */</p>
<hr />
<div>Was noch jemand ergänzen müsste:<br />
* Eine generische virtuser/alias Konfiguration finden und dokumentieren. <br><br />
http://listes.rezo.net/how.php<br> http://www.gnu.org/software/mailman/mailman-install/mail-server.html<br />
<br />
* Skriptautomatisierung updaten <br> http://hs.andreasloesch.de/pac-mm-install<br />
<br />
<br />
== Installation == <br />
<br />
Installationsanleitung von Mailman<br><br />
(zuletzt getestet mit mailman-2.1.12 in eigenem Paketuser)<br />
<br />
Vielen Dank an alle Benutzer die Verbesserungen beisteuern!<br />
<br />
Mailman kann vom Paketadmin oder vom Paketuser installiert werden. Wenn er vom Paketadmin installiert wird, haben jedoch 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 />
Zur Separation von Paketadminrechten und anderen Paketusern ist es vorzuziehen Mailman in einem Paketuser Account zu installieren. (Bspw. xyz00-listen) Und diesem separaten User ggf mehrere lists.*.* Subdomains aufzuschalten.<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 werden (wie immer bei .forward) die Rechte des Zielusers angenommen. (So läuft das auch bei procmail.)<br />
<br />
Nachteil der Installation als Paketuser ist lediglich, dass bisher so nicht die Paketdomain mit dem SSL Zertifikat von Hostsharing genutzt werden kann.<br />
<br />
=== Sourcen besorgen und entpacken ===<br />
<br />
Unter http://www.gnu.org/software/mailman/ die aktuelle Software besorgen.<br />
<br />
~$ tar -xzvf mailman-2.1.12.tgz<br />
<br />
=== Log-Verzeichnis anlegen ===<br />
<br />
Bei der Installation als Paketuser:<br />
~$ mkdir -p mailman/var<br />
~$ chmod 02775 mailman/var<br />
<br />
Bei der Installation als Paketadmin:<br />
~$ mkdir var/mailman<br />
~$ chmod 02775 var/mailman<br />
<br />
=== Kompilieren ===<br />
<br />
Braucht einige Optionen, die anzupassen sind.<br />
<br />
~$ cd mailman-2.1.12<br />
<br />
Bei der Installation als Paketuser:<br />
~/mailman-2.1.12$ ./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:<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 />
(die \ bedeuten, dass alles in eine Zeile gehört, bzw. die Returns nicht interpretiert werden sollen.)<br />
<br />
<br />
Anschließend:<br />
<br />
~/mailman-2.1.12$ make<br />
~/mailman-2.1.12$ make install<br />
<br />
=== Datenrechte prüfen ===<br />
<br />
Sicherheitshalber die Dateirechte prüfen (und ggf. korrigieren) lassen:<br />
<br />
~/mailman-2.1.12$ cd .. <br />
~$ mailman/bin/check_perms -f<br />
<br />
== Konfiguration ==<br />
<br />
=== mm_cfg.py ===<br />
<br />
Konfigurationsdatei editieren:<br />
<br />
~$ nano mailman/Mailman/mm_cfg.py<br />
<br />
Eine Beispielkonfiguration für lists.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 = 'lists.example.com'<br />
DEFAULT_EMAIL_HOST = 'lists.example.com'<br />
DEFAULT_URL_HOST = 'lists.example.com'<br />
add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)<br />
<br />
DEFAULT_SERVER_LANGUAGE = 'de'<br />
<br />
DEFAULT_URL_PATTERN = 'http://%s/'<br />
<br />
In ~/mailman/Mailman/Defaults.py seht ihr, was man in mm_cfg.py alles einstellen kann.<br />
<br />
=== CGIs in die Domains ===<br />
<br />
Bei der Installation als Paketuser: Die CGIs müssen in das jeweilige Domain-Verzeichnis, auf denen das Mailman Webfrontend laufen soll, kopiert werden. Ein Verlinken ist nicht möglich. Zusätzlich muss das sticky-Flag entfernt werden.<br />
<br />
~$ mkdir ~/doms/lists.example.com/cgi/mailman<br />
~$ cp mailman/cgi-bin/* doms/lists.example.com/cgi/mailman/<br />
~$ chmod g-s ~/doms/lists.example.com/cgi/mailman/*<br />
<br />
Bei der Installation als Paketadmin: CGIs in alle Domain-Verzeichnisse linken, auf denen das Mailman Webfrontend laufen soll. <br />
<br />
~$ cd doms/lists.example.com/cgi<br />
~/doms/lists.example.com/cgi$ ln -s ../../../mailman/cgi-bin mailman<br />
<br />
=== Icons in die Domains ===<br />
<br />
Die Icons können wahlweise verlinkt oder kopiert werden.<br />
<br />
~$ cd doms/lists.example.com/htdocs<br />
~/doms/lists.example.com/htdocs$ ln -s ../../../mailman/icons<br />
<br />
oder kopieren<br />
<br />
~$ cp -R mailman/icons doms/lists.example.com/htdocs/<br />
<br />
=== .htaccess ===<br />
<br />
Bei einer extra Mailman Domain dafür sorgen, dass Mailman auch unter lists.example.com statt unter lists.example.com/cgi-bin/mailman erreichbar ist.<br />
In ~/doms/lists.example.com/htdocs/.htaccess folgendes eintragen (bitte RewriteCond für Icons beachten; ohne wird der Pfad für diese auch gemappt, was nicht korrekt ist):<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 />
<br />
Wenn Mailman z.B. auf der www Domain läuft und unter www.example.com/mailman statt www.example.com/cgi-bin/mailman erreichbar sein soll, hilft folgendes in der ~/doms/example.com/subs/www/.htaccess:<br />
<br />
RewriteEngine On<br />
RewriteRule ^mailman/(.*)$ /cgi-bin/mailman/$1<br />
RewriteRule ^/cgi-bin/mailman/$ /cgi-bin/mailman/listinfo<br />
<br />
(Die DEFAULT_URL_PATTERN Zeile in der mm_cfg.py kann für diesen Fall einfach auskommentiert werden.)<br />
<br />
=== Passwort setzen ===<br />
<br />
~$ mailman/bin/mmsitepass<br />
<br />
=== Cronjobs einrichten ===<br />
<br />
In die [[Cron |Crontab]] wird z.B. eingetragen:<br />
<br />
* * * * * ~/mailman/bin/qrunner -o -r All<br />
47 * * * * rm -f ~/var/mailman/logs/qrunner<br />
(Queuebearbeitung alle Minute, löschen der Verarbeitungslogs in der 47ten Minute jeder Std.)<br />
<br />
Dies übernimmt die Funktion des qrunner-Dämons, der bei Mailman normalerweise laufen würde.<br />
Das Logfile wird gelöscht, da es sonst sehr schnell sehr groß wird.<br />
<br />
Zudem müssen noch die Cronjobs aus ~/mailman/cron/crontab.in eingefügt werden. <br />
<br />
crontab -l > mycronjobs.tmp<br />
cat ~/mailman/cron/crontab.in >> mycronjobs.tmp<br />
crontab mycronjobs.tmp<br />
<br />
<br />
== Mailinglisten einrichten ==<br />
<br />
=== Als erste Liste die "mailman" "site list" Einrichten ===<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 />
Neue Liste anlegen:<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 />
Nur für die "mailman site list": Konfigurationsvorgaben laden.<br />
<br />
~$ mailman/bin/config_list -i ~/mailman/var/data/sitelist.cfg mailman<br />
<br />
Bei der Installation als Paketadmin:<br />
~$ mailman/bin/config_list -i ~/var/mailman/data/sitelist.cfg mailman<br />
<br />
(Diese Konfigurationsdatei nicht auf eigene Listen anwenden.)<br />
<br />
=== Email Adressen einrichten === <br />
<br />
Bei der Installation als Paketuser erfolgt die Einrichtung der Emailadressen per hsadmin (virtusertable) und .forward Dateien.<br />
Anlegen mittels [[hsadmin|hsadmin CLI]].<br />
<br />
Beispiel für lists.example.com und Paketuser XYZ00-listen.<br />
<br />
A) virtusertable:<br />
hsadmin -c emailaddress.add -s localpart=mailman -s domain=lists.example.com -s 'target=XYZ00-listen+mailman'<br />
hsadmin -c emailaddress.add -s localpart=mailman-admin -s domain=lists.example.com -s 'target=XYZ00-listen+mailman-admin'<br />
hsadmin -c emailaddress.add -s localpart=mailman-bounces -s domain=lists.example.com -s 'target=XYZ00-listen+mailman-bounces'<br />
hsadmin -c emailaddress.add -s localpart=mailman-confirm -s domain=lists.example.com -s 'target=XYZ00-listen+mailman-confirm'<br />
hsadmin -c emailaddress.add -s localpart=mailman-join -s domain=lists.example.com -s 'target=XYZ00-listen+mailman-join'<br />
hsadmin -c emailaddress.add -s localpart=mailman-leave -s domain=lists.example.com -s 'target=XYZ00-listen+mailman-leave'<br />
hsadmin -c emailaddress.add -s localpart=mailman-owner -s domain=lists.example.com -s 'target=XYZ00-listen+mailman-owner'<br />
hsadmin -c emailaddress.add -s localpart=mailman-request -s domain=lists.example.com -s 'target=XYZ00-listen+mailman-request'<br />
hsadmin -c emailaddress.add -s localpart=mailman-subscribe -s domain=lists.example.com -s 'target=XYZ00-listen+mailman-subscribe'<br />
hsadmin -c emailaddress.add -s localpart=mailman-unsubscribe -s domain=lists.example.com -s 'target=XYZ00-listen+mailman-unsubscribe'<br />
<br />
Im Homeverzeichnis des Users XYZ00-listen werden anschließend entsprechende .forward-Dateien angelegt.<br />
<br />
B) .forward Dateien:<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 />
<br />
Bei der Installation als Paketadmin XYZ00 erfolgt die Einrichtung hingegen per hsadmin (virtusertable) und hsadmin (aliases) so:<br />
<br />
A) virtusertable:<br />
hsadmin -c emailaddress.add -s localpart=mailman -s domain=lists.example.com -s 'target=XYZ00-mailman'<br />
hsadmin -c emailaddress.add -s localpart=mailman-admin -s domain=lists.example.com -s 'target=XYZ00-mailman-admin'<br />
hsadmin -c emailaddress.add -s localpart=mailman-bounces -s domain=lists.example.com -s 'target=XYZ00-mailman-bounces'<br />
hsadmin -c emailaddress.add -s localpart=mailman-confirm -s domain=lists.example.com -s 'target=XYZ00-mailman-confirm'<br />
hsadmin -c emailaddress.add -s localpart=mailman-join -s domain=lists.example.com -s 'target=XYZ00-mailman-join'<br />
hsadmin -c emailaddress.add -s localpart=mailman-leave -s domain=lists.example.com -s 'target=XYZ00-mailman-leave'<br />
hsadmin -c emailaddress.add -s localpart=mailman-owner -s domain=lists.example.com -s 'target=XYZ00-mailman-owner'<br />
hsadmin -c emailaddress.add -s localpart=mailman-request -s domain=lists.example.com -s 'target=XYZ00-mailman-request'<br />
hsadmin -c emailaddress.add -s localpart=mailman-subscribe -s domain=lists.example.com -s 'target=XYZ00-mailman-subscribe'<br />
hsadmin -c emailaddress.add -s localpart=mailman-unsubscribe -s domain=lists.example.com -s 'target=XYZ00-mailman-unsubscribe'<br />
<br />
''Hinweis: Die e-Mail Adressen und die Targets, welche noch in den Aliasen definiert werden müssen, können von Domain und Mailingliste unterschiedlich sein bzw. müssen bei mehreren identische Listen unterschiedlich sein!''<br />
<br />
Die bei den Mail-Adressen oben angegebenen Aliase werden mit [[hsadmin|hsadmin CLI]] angelegt.<br />
<br />
B) aliase:<br />
hsadmin -c emailalias.add -s name='XYZ00-mailman' -s 'target="|/home/pacs/XYZ00/mailman/mail/mailman post mailman"'<br />
hsadmin -c emailalias.add -s name='XYZ00-mailman-admin' -s 'target="|/home/pacs/XYZ00/mailman/mail/mailman admin mailman"'<br />
hsadmin -c emailalias.add -s name='XYZ00-mailman-bounces' -s 'target="|/home/pacs/XYZ00/mailman/mail/mailman bounces mailman"'<br />
hsadmin -c emailalias.add -s name='XYZ00-mailman-confirm' -s 'target="|/home/pacs/XYZ00/mailman/mail/mailman confirm mailman"'<br />
hsadmin -c emailalias.add -s name='XYZ00-mailman-join' -s 'target="|/home/pacs/XYZ00/mailman/mail/mailman join mailman"'<br />
hsadmin -c emailalias.add -s name='XYZ00-mailman-leave' -s 'target="|/home/pacs/XYZ00/mailman/mail/mailman leave mailman"'<br />
hsadmin -c emailalias.add -s name='XYZ00-mailman-owner' -s 'target="|/home/pacs/XYZ00/mailman/mail/mailman owner mailman"'<br />
hsadmin -c emailalias.add -s name='XYZ00-mailman-request' -s 'target="|/home/pacs/XYZ00/mailman/mail/mailman request mailman"'<br />
hsadmin -c emailalias.add -s name='XYZ00-mailman-subscribe' -s 'target="|/home/pacs/XYZ00/mailman/mail/mailman subscribe mailman"'<br />
hsadmin -c emailalias.add -s name='XYZ00-mailman-unsubscribe' -s 'target="|/home/pacs/XYZ00/mailman/mail/mailman unsubscribe mailman"'<br />
<br />
''Hinweis: Die Aliase und die Targets können von Domain und Mailingliste unterschiedlich sein bzw. müssen bei mehreren identische Listen unterschiedlich sein! Des Weiteren ist der Pfad zur Mailman Installation anzupassen.''<br />
<br />
=== Administration ===<br />
<br />
Administriert werden Listen über http://lists.example.com/admin/<listenname> und entweder dem Listenpasswort oder dem Site-Passwort.<br />
<br />
Als erstes sollte man die Liste "mailman" selber abbonieren. (http://lists.example.com/admin/mailman)<br />
<br />
Bis auf das Anwenden der sitelist.cfg werden auch alle weiteren Listen nach obigem Schema angelegt, oder (bis auf das anlegen der virtusertable Einträge und aliase) über das Mailman Webinterface.<br />
<br />
<br />
Das war's. Mailman ist jetzt fertig installiert und müsste sogar funktionieren ;)<br />
<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/lists.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@lists.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 lists.example.com sowohl als URL für das Webfrontend wie auch als Hostpart für Emailadressen verwendet. (Was für separate aufgeschaltete Domains wie z.B. lists.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 = 'lists.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 statt Paketadmin:<br />
https://lists.hostsharing.net/archiv/support/2009-June/019414.html<br />
<br />
Ältere Anleitung für Installation als Domain-Admin: <http://lists.hostsharing.net/archiv/support/2005-January/012426.html><br />
<br />
Laufenlassen mit event:<br />
Download und Doku auf <http://al000.hostsharing.net/mailman/mmhs/><br />
<br />
Die "Mutter der Mailman-Installations-Doku" <http://al000.hostsharing.net/mailman/><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]]</div>Apc00https://wiki.hostsharing.net/index.php?title=Diskussion:MySQL&diff=2767Diskussion:MySQL2010-10-25T11:56:25Z<p>Apc00: /* Unverständlicher Satz */</p>
<hr />
<div>== Unverständlicher Satz ==<br />
Im Abschnitt "Paketadmin" steht, "Wir richten den User mit Datenbanken ein, weil das am einfachsten ist." Wer ist wir? Welchen User? Was ist mit "mit" gemeint: "mit Hilfe von", oder "gleichzeitig mit", oder was?<br />
[[Benutzer:Apc00|Apc00]] 11:46, 25. Okt. 2010 (CEST)<br />
<br />
----<br />
<br />
Wir = Du der Benutzer und Leser des Artikels<br />
<br />
mit = der Seite die sich hinter dem Link Datenbank verbirgt<br />
<br />
So verstehe ich das<br />
<br />
--[[Benutzer:Chg00-hsdoku|Christian Günter]] 12:17, 25. Okt. 2010 (CEST)<br />
:Ich kann dir leider nicht folgen. Wie würdest du dann einen allgemein verständlichen Satz daraus machen? Um welchen Link soll es sich jetzt handeln? Bisher war in dem Artikel kein Hinweis auf hsadmin, falls du das meinst -- und hsadmin hat verschiedene Links für User und für Datenbanken. Vorschlag, um nicht länger zu nerven: Wie wär's, wenn ich den Satz einfach streiche?<br />
:[[Benutzer:Apc00|Tony Crawford (apc00)]] 13:50, 25. Okt. 2010 (CEST)<br />
<br />
:: Ach so, es soll heißen: "Um User einzurichten, siehe die Anleitung auf der Seite [[Datenbanken]]." Jetzt verstehe ich.<br />
<br />
:: In dem Fall gibt's eine große Überschneidung zwischen den zwei Seiten. Da braucht's eine redaktionelle Entscheidung über die Gliederung, die ich mir nicht zutraue. Danke für die Lesehilfe.<br />
<br />
::--[[Benutzer:Apc00|Tony Crawford (apc00)]] 13:56, 25. Okt. 2010 (CEST)</div>Apc00https://wiki.hostsharing.net/index.php?title=Diskussion:MySQL&diff=2766Diskussion:MySQL2010-10-25T11:50:53Z<p>Apc00: /* Unverständlicher Satz */</p>
<hr />
<div>== Unverständlicher Satz ==<br />
Im Abschnitt "Paketadmin" steht, "Wir richten den User mit Datenbanken ein, weil das am einfachsten ist." Wer ist wir? Welchen User? Was ist mit "mit" gemeint: "mit Hilfe von", oder "gleichzeitig mit", oder was?<br />
[[Benutzer:Apc00|Apc00]] 11:46, 25. Okt. 2010 (CEST)<br />
<br />
----<br />
<br />
Wir = Du der Benutzer und Leser des Artikels<br />
<br />
mit = der Seite die sich hinter dem Link Datenbank verbirgt<br />
<br />
So verstehe ich das<br />
<br />
--[[Benutzer:Chg00-hsdoku|Christian Günter]] 12:17, 25. Okt. 2010 (CEST)<br />
:Ich kann dir leider nicht folgen. Wie würdest du dann einen allgemein verständlichen Satz daraus machen? Um welchen Link soll es sich jetzt handeln? Bisher war in dem Artikel kein Hinweis auf hsadmin, falls du das meinst -- und hsadmin hat verschiedene Links für User und für Datenbanken. Vorschlag, um nicht länger zu nerven: Wie wär's, wenn ich den Satz einfach streiche?<br />
[[Benutzer:Apc00|Tony Crawford (apc00)]] 13:50, 25. Okt. 2010 (CEST)</div>Apc00https://wiki.hostsharing.net/index.php?title=Diskussion:MySQL&diff=2765Diskussion:MySQL2010-10-25T11:48:26Z<p>Apc00: /* Unverständlicher Satz */</p>
<hr />
<div>== Unverständlicher Satz ==<br />
Im Abschnitt "Paketadmin" steht, "Wir richten den User mit Datenbanken ein, weil das am einfachsten ist." Wer ist wir? Welchen User? Was ist mit "mit" gemeint: "mit Hilfe von", oder "gleichzeitig mit", oder was?<br />
[[Benutzer:Apc00|Apc00]] 11:46, 25. Okt. 2010 (CEST)<br />
<br />
----<br />
<br />
Wir = Du der Benutzer und Leser des Artikels<br />
<br />
mit = der Seite die sich hinter dem Link Datenbank verbirgt<br />
<br />
So verstehe ich das<br />
<br />
--[[Benutzer:Chg00-hsdoku|Christian Günter]] 12:17, 25. Okt. 2010 (CEST)<br />
:Ich kann dir leider nicht folgen. Wie würdest du dann einen allgemein verständlichen Satz daraus machen? Um welchen Link soll es sich jetzt handeln? Bisher war in dem Artikel kein Hinweis auf hsadmin, falls du das meinst -- und hsadmin hat verschiedene Links für User und für Datenbanken. Vorschlag, um nicht länger zu nerven: Wie wär's, wenn ich den Satz einfach streiche?</div>Apc00https://wiki.hostsharing.net/index.php?title=MySQL&diff=2763MySQL2010-10-25T09:57:57Z<p>Apc00: /* MySQL-User */</p>
<hr />
<div><br />
== Server ==<br />
<br />
Wir haben pro Host einen einzelnen MySQL Datenbankserver. Der Zugriff erfolgt über den Hostnamen <code>localhost</code> und den Port 3306 (default). Außerdem kann der Server über den Socket <code>/var/run/mysqld/mysqld.sock</code> erreicht werden.<br />
<br />
Die Anzahl der in Hostsharing Dynamic-Web-Paketen verwendbaren MySQL-Datenbanken ist an sich nicht begrenzt. Der damit verbrauchte Speicherplatz geht in aber die Quota des Paketes mit ein, so dass hierüber eine indirekte Begrenzung vorliegt. Alle Datenbanken eines Paketes müssen mit dem Paketnamen und einem Underscore beginnen, also z.B. <code>xyz00_datenbank</code>.<br />
== MySQL-User ==<br />
<br />
{{Textkasten|gruen||Die Benutzernamen, die MySQL erkennt, stehen in keiner Beziehung zu den Unix-Benutzernamen der Hostsharing-Systeme, also den Namen, die für den [[shell]]-Zugang verwendet werden.}}<br />
<br />
Die Ausnahme ist der Benutzername des Paketadmins: der Name des MySQL-Administrators im Paket entspricht dem Benutzernamen des Paketadmins (z. B. '''xyz00'''). Das ist eine Konvention, die wir gewählt haben, damit der Paket-Admin seinen Namen für den MySQL-Zugang nicht vergessen kann.<br />
<br />
Weitere MySQL-Usernamen können aus dem Paket-Admin-Namen, einem Unterstrich, und einer freien Zeichenfolge gebildet werden. Also kann der Paketadmin '''xyz00''' weitere User der Form '''xyz00_abc''' einrichten. Beachte die Differenz zu Domain-Admin-Namen, die nicht mit Unterstrich, sondern mit Bindestrich gebildet werden ('''xyz00''' -> '''xyz00-abc''').<br />
<br />
=== Paketadmin ===<br />
<br />
Der Paketadmin hat mit seinem Account sehr weitgehende administrative Rechte in MySQL und sollte dementsprechend mit Umsicht genutzt werden. Er kann mit seinem Account im Administrationswerkzeug [[hsadmin]] unter anderem:<br />
<br />
* Datenbanken anlegen und löschen<br />
* Datenbank-Benutzer anlegen und löschen<br />
<br />
Bevor man in seinem Paket MySQL benutzen kann, muss man als ersten Schritt einen Datenbank-Administrator einrichten. Das ist zwingend notwendig. Es kann ein MySQL-User mit dem Kürzel des Paketadmins (<code>xyz00</code>) sein. Es können allerdings auch beliebing viele Datenbank-Administratoren nach dem Namensschema <code>xyz00_...</code> angelegt werden. Wir richten den User mit [[Datenbanken]] ein, weil das am einfachsten ist.<br />
<br />
=== Weitere Benutzer anlegen ===<br />
<br />
Du kannst Dir weitere Benutzer für MySQL anlegen. Wir empfehlen Dir das ausdrücklich, weil es eine gute Idee ist, den mächtigen Zugang des Paketadmins nur für administrative Zwecke zu benutzen. Schließlich will man nicht immer den mächtigen Account des Paketadmins in seinen Skripten verwenden. Für einzelne Aufgaben kannst Du verschiedene Benutzer anlegen, denen Du natürlich auch verschiedene Rechte geben kannst, z.B. nur Rechte an bestimmten Datenbanken oder zur Ausführung bestimmter Kommandos.<br />
<br />
Wir legen noch einen User an:<br />
<br />
siehe [[Datenbanken]]<br />
<br />
=== Der MySQL-Monitor ===<br />
<br />
Mit den neu angelegten User-Accounts können wir nun in den MySQL-Monitor wechseln, in dem die MySQL-Befehle eingegeben und verarbeitet werden. Der Monitor wird mit dem Befehl <code>mysql</code> 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 -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 Monitor wieder verlässt.<br />
=== Datenbank anlegen === <br />
<br />
geht nun auch mit [[hsadmin]] siehe [[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 <code>xyz00</code>:<br />
* <code>xyz00_otto</code><br />
* <code>xyz00_anna</code><br />
* <code>xyz00_db_fuer_hans</code><br />
<br />
=== Rechte vergeben ===<br />
<br />
Allen Benutzern, außer dem Paketadmin, müssen wir noch Rechte geben, sonst können sie gar nichts machen. Das erledigt man mit dem Befehl <code>GRANT</code>.<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 <code>GRANT ALL</code> kann man einem User auch alle Kommandorechte zuweisen.<br />
<br />
Alle Aufgaben können wir jetzt in Zukunft vom User <code>xyz00_otto</code> erledigen lassen.<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 />
[[Kategorie:HSDoku]]<br />
[[Kategorie:Datenbanken]]<br />
[[Kategorie:Glossar]]</div>Apc00https://wiki.hostsharing.net/index.php?title=MySQL&diff=2762MySQL2010-10-25T09:56:20Z<p>Apc00: /* MySQL-User */</p>
<hr />
<div><br />
== Server ==<br />
<br />
Wir haben pro Host einen einzelnen MySQL Datenbankserver. Der Zugriff erfolgt über den Hostnamen <code>localhost</code> und den Port 3306 (default). Außerdem kann der Server über den Socket <code>/var/run/mysqld/mysqld.sock</code> erreicht werden.<br />
<br />
Die Anzahl der in Hostsharing Dynamic-Web-Paketen verwendbaren MySQL-Datenbanken ist an sich nicht begrenzt. Der damit verbrauchte Speicherplatz geht in aber die Quota des Paketes mit ein, so dass hierüber eine indirekte Begrenzung vorliegt. Alle Datenbanken eines Paketes müssen mit dem Paketnamen und einem Underscore beginnen, also z.B. <code>xyz00_datenbank</code>.<br />
== MySQL-User ==<br />
<br />
{{Textkasten|gruen||Die Benutzernamen, die MySQL erkennt, stehen in keiner Beziehung zu den Unix-Benutzernamen der Hostsharing-Systeme, also den Namen, die für den [[shell]]-Zugang verwendet werden.}}<br />
<br />
Die Ausnahme ist der Benutzername des Paketadmins: der Name des MySQL-Administrators im Paket entspricht dem Benutzernamen des Paketadmins (xyz00). Das ist eine Konvention, die wir gewählt haben, damit der Paket-Admin seinen Namen für den MySQL-Zugang nicht vergessen kann.<br />
<br />
Weitere MySQL-Usernamen können aus dem Paket-Admin-Namen, einem Unterstrich, und eine freie Zeichenfolge gebildet werden. Also kann der Paketadmin '''xyz00''' weitere User der Form '''xyz00_abc''' einrichten. Beachte die Differenz zu Domain-Admin-Namen, die nicht mit Unterstrich, sondern mit Bindestrich gebildet werden ('''xyz00''' -> '''xyz00-abc''').<br />
<br />
=== Paketadmin ===<br />
<br />
Der Paketadmin hat mit seinem Account sehr weitgehende administrative Rechte in MySQL und sollte dementsprechend mit Umsicht genutzt werden. Er kann mit seinem Account im Administrationswerkzeug [[hsadmin]] unter anderem:<br />
<br />
* Datenbanken anlegen und löschen<br />
* Datenbank-Benutzer anlegen und löschen<br />
<br />
Bevor man in seinem Paket MySQL benutzen kann, muss man als ersten Schritt einen Datenbank-Administrator einrichten. Das ist zwingend notwendig. Es kann ein MySQL-User mit dem Kürzel des Paketadmins (<code>xyz00</code>) sein. Es können allerdings auch beliebing viele Datenbank-Administratoren nach dem Namensschema <code>xyz00_...</code> angelegt werden. Wir richten den User mit [[Datenbanken]] ein, weil das am einfachsten ist.<br />
<br />
=== Weitere Benutzer anlegen ===<br />
<br />
Du kannst Dir weitere Benutzer für MySQL anlegen. Wir empfehlen Dir das ausdrücklich, weil es eine gute Idee ist, den mächtigen Zugang des Paketadmins nur für administrative Zwecke zu benutzen. Schließlich will man nicht immer den mächtigen Account des Paketadmins in seinen Skripten verwenden. Für einzelne Aufgaben kannst Du verschiedene Benutzer anlegen, denen Du natürlich auch verschiedene Rechte geben kannst, z.B. nur Rechte an bestimmten Datenbanken oder zur Ausführung bestimmter Kommandos.<br />
<br />
Wir legen noch einen User an:<br />
<br />
siehe [[Datenbanken]]<br />
<br />
=== Der MySQL-Monitor ===<br />
<br />
Mit den neu angelegten User-Accounts können wir nun in den MySQL-Monitor wechseln, in dem die MySQL-Befehle eingegeben und verarbeitet werden. Der Monitor wird mit dem Befehl <code>mysql</code> 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 -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 Monitor wieder verlässt.<br />
=== Datenbank anlegen === <br />
<br />
geht nun auch mit [[hsadmin]] siehe [[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 <code>xyz00</code>:<br />
* <code>xyz00_otto</code><br />
* <code>xyz00_anna</code><br />
* <code>xyz00_db_fuer_hans</code><br />
<br />
=== Rechte vergeben ===<br />
<br />
Allen Benutzern, außer dem Paketadmin, müssen wir noch Rechte geben, sonst können sie gar nichts machen. Das erledigt man mit dem Befehl <code>GRANT</code>.<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 <code>GRANT ALL</code> kann man einem User auch alle Kommandorechte zuweisen.<br />
<br />
Alle Aufgaben können wir jetzt in Zukunft vom User <code>xyz00_otto</code> erledigen lassen.<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 />
[[Kategorie:HSDoku]]<br />
[[Kategorie:Datenbanken]]<br />
[[Kategorie:Glossar]]</div>Apc00https://wiki.hostsharing.net/index.php?title=Diskussion:MySQL&diff=2761Diskussion:MySQL2010-10-25T09:46:23Z<p>Apc00: Die Seite wurde neu angelegt: „== Unverständlicher Satz == Im Abschnitt "Paketadmin" steht, "Wir richten den User mit Datenbanken ein, weil das am einfachsten ist." Wer ist wir? Welchen User? …“</p>
<hr />
<div>== Unverständlicher Satz ==<br />
Im Abschnitt "Paketadmin" steht, "Wir richten den User mit Datenbanken ein, weil das am einfachsten ist." Wer ist wir? Welchen User? Was ist mit "mit" gemeint: "mit Hilfe von", oder "gleichzeitig mit", oder was?<br />
[[Benutzer:Apc00|Apc00]] 11:46, 25. Okt. 2010 (CEST)</div>Apc00https://wiki.hostsharing.net/index.php?title=Procmail&diff=2716Procmail2010-07-24T13:07:43Z<p>Apc00: /* Abwesenheitsbenachrichtigung (vacation) */ Angabe des Adressaten im Rezept mit ^TO_... ersetzt</p>
<hr />
<div>Procmail ist ein mächtiger Filter, der für viele komplexe Aufgaben verwendet werden kann. So sind z.B. variable Weiterleitungen und das einbinden eines Spamfilters machbar. Mehr dazu unter www.procmail.org und auf dem Server in den Manpages zu procmail, procmailrc und procmailex.<br />
<br />
=== Eingehende Emails an Procmail weiterleiten ===<br />
<br />
Zur Nutzung von procmail wird im Homedirectory des Users eine Datei .forward angelegt, die nur aus einer Zeile besteht:<br />
<br />
"|/usr/bin/procmail"<br />
<br />
Damit werden alle Mails an das Programm procmail übergeben und die Auslieferung kann nun über die Datei ~/.procmailrc konfiguriert werden.<br />
<br />
=== Procmail konfigurieren ===<br />
<br />
Das nachfolgende Beispiel zeigt wie ein [[Spamfilter]] eingebunden werden kann, und Emails automatisch in IMAP-Folder (Verzeichnisse) einsortiert werden können.<br />
<br />
==== Verzeichnisse anlegen ====<br />
<br />
Die angesprochenen Emailverzeichnisse sollten vorher angelegt worden sein, falls sie noch nicht existieren ist dies z.B. mit dem Befehle maildirmake möglich:<br />
<br />
maildirmake Maildir<br />
maildirmake -f Trash Maildir<br />
maildirmake -f Spam Maildir<br />
maildirmake -f Hostsharing Maildir<br />
<br />
Alternativ können die Verzeichnisse auch über die Webmail-Oberfläche anlgelegt werden. Es ist übrigens korrekt, dass die Folder beim Anlegen ohne einen führenden Punkt im Namen erstellt werden, in der .procmailrc aber mit Punkt angegeben werden.<br />
<br />
==== .procmailrc ====<br />
<br />
Eine beispielhafte .procmailrc:<br />
<pre><br />
## Logging abstellen<br />
COMSAT=no<br />
LOGABSTRACT=no<br />
VERBOSE=no<br />
LOGFILE=procmail.log<br />
<br />
## Spamassassin für alle Mails aufrufen...<br />
# Hier wird der systemweite Spamassassin-Daemon benutzt.<br />
:0fw<br />
| /usr/bin/spamc -U /var/run/spamd<br />
## ...und Spam in den Spam Folder aussortieren<br />
:0<br />
* ^X-Spam-Flag: YES<br />
Maildir/.Spam/<br />
<br />
## Bsp. Mailinglisten von Hostsharing in eine extra Box<br />
#:0<br />
#* ^TO_(support|technik|website)@hostsharing\.net<br />
#Maildir/.Hostsharing/<br />
<br />
# Alle nicht ausgefilterten Mails landen in der normalen Mailbox<br />
</pre><br />
<br />
==== Abwesenheitsbenachrichtigung (vacation) ====<br />
<br />
Zunächst im Home-Ordner eine Datei vacation.msg erstellen, deren Text als Nachricht verschickt werden soll.<br />
<br />
Dann in die .procmailrc folgende Zeilen einfügen:<br />
<pre><br />
SHELL=/bin/sh<br />
FORMAIL=/usr/bin/formail<br />
SENDMAIL=/usr/sbin/sendmail<br />
:0 Whc: vacation.lock<br />
* ^TO_myself@example.com<br />
# Nur E-Mails, die an meine Adresse adressiert sind<br />
* !^FROM_DAEMON<br />
# Daemons (Mailinglisten) ausschließen<br />
* !^X-Loop: myself@example.com<br />
# Loop vermeiden: eigene E-Mail ausschließen<br />
| formail -rD 8192 vacation.cache<br />
# Adresse des Senders im Cache speichern<br />
:0 ehc<br />
# e: letztes recipe trifft nicht zu (Adresse noch nicht im Cache vorhanden)<br />
| ($FORMAIL -rA "Precedence: junk" -A "X-Loop: myself@example.com" ; /bin/cat vacation.msg ) | $SENDMAIL -oi -t -f myself@example.com<br />
</pre><br />
<br />
Nun wird eine E-Mail mit dem Inhalt der Datei vacation.msg und dem Absender myself@example.com an die Absender empfangener Emails geschickt. Allerdings nur, wenn die Adresse noch nicht in der vacation.cache-Datei vorhanden war. Damit wird vermieden, dass ein Absender immer wieder die Abwesenheitsnachricht erhält.<br />
<br />
=== Links zu weiteren Procmail Beispielen und Tipps ===<br />
<br />
http://pm-doc.sourceforge.net/pm-tips.html<br />
<br />
http://lipas.uwasa.fi/~ts/info/proctips.html (Timo's procmail tips and recipes)<br />
<br />
[[Kategorie:HSDoku]]<br />
[[Kategorie:E-Mail]]<br />
[[Kategorie:Glossar]]<br />
[[Kategorie:Installationsanleitungen]]<br />
[[Kategorie:Software]]</div>Apc00