Hostsharing Wiki - Benutzerbeiträge [de]

Nameserver

2019-12-11T07:26:53Z

Ara00-wp: /* Bug */ Präzisierung

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:

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

Jede Nutzung eines Dienstes (z.B. E-Mail, 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.

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.

===Häufige Frage===
Manchmal werden im Domainbestellsystem Einträge für secondary Domainserver nicht angenommen. Das könnte daran liegen, dass die nötigen Schritte nicht in der nötigen Reihenfolge abgearbeitet wurden.

Anleitung: [https://doc.hostsharing.net/users/anleitung/domain.html Domain bestellen]

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

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

FAQ

2019-12-08T16:51:14Z

Ara00-wp: /* Email */ Schreibweise für eMail, Email zu E-Mail vereinheitlicht

{{HSDoku-Links}}

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

== Domains ==

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

:Das ist nicht möglich.

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

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

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

== E-Mail ==

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

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

=== Nutzung der E-Mail Postfächer in HS Paketen ===
:Kann ich E-Mail-Adr deren Domain in einem WEB-Paket ist in einem SW-Paket nutzen?

:Ja, folgende beiden Möglichkeiten gibt es a) Die Subdomain mail.example.org ins SW legen und per Catch-All von @example.org nach @mail.example.org leiten und dort passende E-Mail-Adressen Postfächer einrichten. (Leichter nachträglich einzurichten.) b) Die Domain example.org im SW aufschalten und www.example.org im WEB aufschalten. E-Mail dann direkt im SW abhandeln. (Technisch besser.)

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

== WWW ==

=== Meine Webseite ist nicht erreichbar ===

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

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

:siehe [[Speicherbelegung]].

=== kein Verzeichnislisting anzeigen ===

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

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

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

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

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

== Datenbank ==

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

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

mysql -u xyz00_dbuser -p xyz00_dbname < name_des_dumps.
Jetzt dein Passwort der Datenbank angeben.

== Host / Server ==

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

:Wie man sowas findet:

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

2. apropos stichwort eingeben,

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

== Pakete allg. ==

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

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

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

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

Für Windows-Nutzer:

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

Generell raten wir von FTP aus Sicherheitsgründen ab.

[[Kategorie:HSDoku]]

FAQ

2019-12-08T16:49:51Z

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

{{HSDoku-Links}}

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

== Domains ==

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

:Das ist nicht möglich.

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

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

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

== Email ==

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

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

=== Nutzung der E-Mail Postfächer in HS Paketen ===
:Kann ich E-Mail-Adr deren Domain in einem WEB-Paket ist in einem SW-Paket nutzen?

:Ja, folgende beiden Möglichkeiten gibt es a) Die Subdomain mail.example.org ins SW legen und per Catch-All von @example.org nach @mail.example.org leiten und dort passende E-Mail-Adressen Postfächer einrichten. (Leichter nachträglich einzurichten.) b) Die Domain example.org im SW aufschalten und www.example.org im WEB aufschalten. E-Mail dann direkt im SW abhandeln. (Technisch besser.)

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

== WWW ==

=== Meine Webseite ist nicht erreichbar ===

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

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

:siehe [[Speicherbelegung]].

=== kein Verzeichnislisting anzeigen ===

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

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

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

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

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

== Datenbank ==

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

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

mysql -u xyz00_dbuser -p xyz00_dbname < name_des_dumps.
Jetzt dein Passwort der Datenbank angeben.

== Host / Server ==

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

:Wie man sowas findet:

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

2. apropos stichwort eingeben,

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

== Pakete allg. ==

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

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

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

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

Für Windows-Nutzer:

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

Generell raten wir von FTP aus Sicherheitsgründen ab.

[[Kategorie:HSDoku]]

DAViCal installieren

2019-12-08T16:48:38Z

Ara00-wp: /* Beispiel Thunderbird */

== Allgemein ==
=== Beschreibung ===
[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.

Das CalDAV-Protokoll bietet viele Funktionen, die noch nicht von allen Clients unterstützt werden, darunter Serien, Erinnerungen, Einladungen, Ressourcen, Arbeitsgruppen etc.

DAViCal ist in PHP geschrieben, lizensiert unter GPL.

DAViCal erlaubt auch über das WebDAV-Protokoll Kalender zu lesen, aber nicht zu modifizieren.

=== Voraussetzungen ===

DAViCal erfordert folgende technische Ressourcen:
* PostgreSQL
* Webserver mit PHP5
* Perl für den Installationsvorgang
* Ein Dateisystem mit erweiterten Attributen.

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.

== Installation ==

=== Design ===

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.

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.

=== Subdomain aufschalten ===

Im Folgenden werden folgende Domainkonfigurationsdaten als Beispiel verwendet:

{| class="wikitable"
|- class="hintergrundfarbe5"
! Typ !! Wert !! Beschreibung
|-
| Subdomain || <tt>cal.example.org</tt> || Die Subdomain, unter der ein DAViCal-Server laufen soll
|-
| Domain-Admin || <tt>xyz00-hans</tt> || Der User, dem die Subdomain delegiert wurde
|}

=== Quellen ===

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.

Die jeweils neusten Versionen befinden sich unter:
* DAViCal: http://debian.mcmillan.net.nz/packages/davical/
* AWL: http://debian.mcmillan.net.nz/packages/awl/

Hier jeweils die Source-Dateien (<tt>*.tar.gz</tt>) benutzen.

==== Download ====

<pre><nowiki>
$ cd ~/doms/cal.example.org/var
$ wget http://debian.mcmillan.net.nz/packages/awl/awl-0.53.tar.gz
$ wget http://debian.mcmillan.net.nz/packages/davical/davical-1.1.1.tar.gz
</nowiki></pre>

==== Auspacken ====

Um die Dateien für den Betrieb in der Serverumgebung lesbar zu machen, die Dateierzeungsmaske temporär auf 022 setzen:

<pre><nowiki>
$ umask 022
</nowiki></pre>

Dann die heruntergeladenen Tarballs mit <tt>tar</tt> auspacken:

<pre><nowiki>
$ tar xfvz awl-0.46.tar.gz
$ tar xfvz davical-0.9.9.4.tar.gz
</nowiki></pre>

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

<pre><nowiki>
$ ln -s awl-0.53 awl
$ ln -s davical-1.1.1 davical
</nowiki></pre>

Und zum Schluß die ursprüngliche Dateierzeugungsmaske wiederherstellen:

<pre><nowiki>
$ umask 077
</nowiki></pre>

=== PostgreSQL vorbereiten ===

DAViCal benötigt eine eigene PostgreSQL-Datenbank sowie 2 Datenbanknutzer.

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.

==== Datenbank und Datenbanknutzer anlegen ====

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.

{| class="wikitable"
|- class="hintergrundfarbe5"
! Typ !! Wert !! Beschreibung
|-
| DB-Admin || <tt>xyz00_davical_dba</tt> || Der PostgreSQL-Nutzer, dem die Datenbank gehört und der administrative Tätigkeiten durchführt.
|-
| DB-Nutzer || <tt>xyz00_davical_app</tt> || Der PostgreSQL-Nutzername, den DAViCal benutzt, um in der Datenbank zu lesen und zu schreiben.
|-
| Datenbank || <tt>xyz00_davical</tt> || Die PostgreSQL-Datenbank, die DAViCals Daten enthält.
|}

==== Umgebungsvariablen und PostgreSQL-Paßwort ====

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.

<pre><nowiki>
$ su xyz00
$ hsadmin -c postgresqluser.add --set:name=xyz00_davical_dba --set:password=geheim
$ hsadmin -c postgresqluser.add --set:name=xyz00_davical_app --set:password=geheim
</nowiki></pre>

Als Besitzer der DAViCal-Datenbank <tt>xyz00_davical_dba</tt> angeben; als Zeichenkodierung ist das Default <tt>UTF-8</tt> richtig:

<pre><nowiki>
$ hsadmin -c postgresqldb.add --set:name=xyz00_davical --set:owner=xyz00_davical_dba
$ exit
</nowiki></pre>

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.

<pre><nowiki>
$ echo "localhost:5432:*:xyz00_davical_dba:geheimes_passwort" >> ~/.pgpass
$ echo "localhost:5432:*:xyz00_davical_app:geheimes_passwort" >> ~/.pgpass
$ chmod 0600 ~/.pgpass
</nowiki></pre>

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.

<pre><nowiki>
$ PGHOST=localhost
$ PGUSER=xyz00_davical_dba
$ PGDATABASE=xyz00_davical
$ export PGHOST PGUSER PGDATABASE
</nowiki></pre>

==== PL/pgSQL installieren ====

In der Datenbank wird die prozedurale Sprache PL/pgSQL benötigt. Diese wird durch den folgenden Befehl angelegt:

<pre><nowiki>
$ psql -A -c "CREATE LANGUAGE plpgsql;"
</nowiki></pre>

==== Datenbank-Tabellen anlegen und initialisieren ====

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.

<pre><nowiki>
$ psql -A -f awl/dba/awl-tables.sql
$ psql -A -f awl/dba/schema-management.sql
$ psql -A -f davical/dba/davical.sql
$ ./davical/dba/update-davical-database –dbhost=${PGHOST} –dbuser=${PGUSER} –dbname=${PGDATABASE} --appuser=${PGDATABASE}_app
$ psql -A -f davical/dba/base-data.sql
</nowiki></pre>

Für den DAViCal-Admin muß noch ein Passwort gesetzt werden – '<tt>**</tt>' vor dem Passwort ist hier wichtig.

<pre><nowiki>
$ psql -A -c "UPDATE usr SET password = '**geheim' WHERE user_no = 1;"
</nowiki></pre>

=== Konfiguration ===

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.

<pre><nowiki>
$ cat > davical/config/config.php
$c->pg_connect[] = "dbname=xyz00_davical user=xyz00_davical_app host=localhost";
$c->use_persistent = true;
$c->sysabbr = 'cal@example.org';
$c->admin_email = 'admin@cal.example.org';
$c->system_name = 'CalDAV Server example.org';
$c->default_locale = 'de_DE';
$c->template_usr = array( 'active' => true,
'locale' => 'de_DE',
'date_format_type' => 'E',
'email_ok' => date('Y-m-d')
);
^D
</nowiki></pre>

=== Fast-CGI-Patch ===

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.

In der Shared-Hosting-Umgebung von Hostsharing kann die notwendige Anpassung über eine Rewrite-Anweisung in der <tt>.htaccess</tt>-Datei gemacht werden:

<pre><nowiki>
$ cd ~/doms/cal.example.org/var/davical/htdocs
$ cat >> .htaccess
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization},L]
^D
</nowiki></pre>

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:

<pre><nowiki>
$ chmod 0644 .htaccess
</nowiki></pre>

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

@@ -101,10 +101,10 @@
/**
* Get HTTP Auth to work with PHP+FastCGI
*/
if ( !isset($_SERVER['AUTHORIZATION']) && isset($_SERVER['HTTP_AUTHORIZATION']) && !empty($_SERVER['HTTP_AUTHORIZATION']))
$_SERVER['AUTHORIZATION'] = $_SERVER['HTTP_AUTHORIZATION'];
- if (isset($_SERVER["AUTHORIZATION"]) && !empty($_SERVER["AUTHORIZATION"])) {
- list ($type, $cred) = split (" ", $_SERVER['AUTHORIZATION']);
+ if (isset($_SERVER["REDIRECT_HTTP_AUTHORIZATION"]) && !empty($_SERVER["REDIRECT_HTTP_AUTHORIZATION"])) {
+ list ($type, $cred) = explode (" ", $_SERVER['REDIRECT_HTTP_AUTHORIZATION']);
if ($type == 'Basic') {
list ($user, $pass) = explode (":", base64_decode($cred));
$_SERVER['PHP_AUTH_USER'] = $user; }

=== Webspace aktivieren ===

Schließlich muß die Installation noch mit dem Webspace verknüpft werden.
<pre><nowiki>
$ cd ~/doms/cal.example.org
$ rm -r htdocs-ssl
$ ln -s var/davical/htdocs htdocs-ssl
</nowiki></pre>

[[Bild:DAViCAl-home.png‎|miniatur|400px|right|Die Login-Seite der DAViCal-Web-Oberfläche]]

Die URL des User-Interfaces lautet jetzt '''<tt><nowiki>https://cal.example.org/</nowiki></tt>'''.

Wenn alles richtig gemacht wurde, erscheint an dieser URL die Login-Seite.

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.

== Nutzung ==

=== User anlegen und konfigurieren ===

Im User-Interface muß man sich als Admin (oder Nutzer mit Adminrechten) einloggen um neue Nutzer anzulegen.

Um einen neuen Nutzer anzulegen: '''Menu''' → '''User Functions''' → '''Create Principal'''

{| class="wikitable"
|- class="hintergrundfarbe5"
! Feld !! Wert !! Beschreibung
|-
| Principal ID || ''New Principal'' || Bei neuen Nutzern wird das Feld automatisch beim Anlegen gefüllt
|-
| Username || hans || Nutzername für den Kalender. Der Username ist Bestandteil der Kalender-URL
|-
| Change Password || geheimespasswort ||
|-
| Confirm Password || geheimespasswort ||
|-
| Fullname || Hans Meier || Der Name des Nutzers
|-
| Email Address || hans@example.org || Über die E-Mail-Adresse ist der Nutzer für andere Nutzer im System zu finden, z.B. für Einladungen
|-
| Locale || Deutsch ||
|-
| Date Format Style || European ||
|-
| Principal Type || Person || Üblicherweise Person für einen natürlichen Nutzer (hier können auch Ressourcen und Gruppen angelegt werden)
|-
| Administrator || – || Falls der User Adminrechte bekommen soll
|-
| Active || X || Soll der Nutzer aktiv geführt werden?
|}

Beim Anlegen des '''ersten''' Nutzers erscheint eine Fehlermeldung:

ERROR: SQL error "23505" - ERROR: duplicate key value violates unique constraint "principal_pkey""
Home calendar added. 

Dies ist ein Bug. Siehe auch [http://lists.morphoss.com/pipermail/davical-dev/2011/000117.html Thread in Dev-Mailingliste].

Zum Umgehen des Bugs einfach den Nutzer nochmal anlegen und dann funktioniert alles ;-)

=== Zugriff über Client-Programme ===

Der Zugriff auf den Kalender erfolgt über die URL: '''<tt><nowiki>https://cal.example.org/caldav.php/user/home</nowiki></tt>'''

* user = Name des angelegte Nutzers, also z.B. '''<tt>hans</tt>'''
* 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

==== Beispiel Thunderbird ====

Ist in Thunderbird die Lightning-Erweiterung installiert, dann kann der Kalender folgendermaßen eingerichtet werden:

'''Menu''' → '''Datei''' → '''Neu''' → '''Kalender'''

Auf den Folgenden Seiten ist auszuwählen:
* ''Im Netzwerk''
* ''CalDAV''
* Spezifische Angaben
** Name: z.B. ''hans@example''
** Farbe: auswählen in welcher Farbe der Kalender angezeigt werden soll
** Alarm: ja
** Email: E-Mail auswählen

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.

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.

===== Mehrere Kalender auf gleichem Server =====

Hat man mehrere Kalender auf dem gleichen Server – 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].

Diesen Bug kann man relativ einfach umgehen, indem man weitere Subdomains anlegt, die auf die gleiche Installation verweisen, also z.B.

<pre><nowiki>
$ cd /home/doms/example.org/subs-ssl
$ mkdir cal1
$ mkdir cal2
</nowiki></pre>

und jeweils eine <tt>.htaccess</tt> in die neuen Verzeichnis mit folgendem Inhalt schreibt:

<pre><nowiki>
RewriteEngine on
RewriteRule ^.htaccess$ - [F]
RewriteRule ^(.*)$ https://cal.example.org/$1 [P]
</nowiki></pre>

Nicht vergessen:

<pre><nowiki>
chmod 0644 cal1/.htaccess
chmod 0644 cal2/.htaccess
</nowiki></pre>

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:

* '''<tt><nowiki>https://cal.example.org/caldav.php/hans/home</nowiki></tt>'''
* '''<tt><nowiki>https://cal1.example.org/caldav.php/hans/work</nowiki></tt>'''
* '''<tt><nowiki>https://cal2.example.org/caldav.php/maria/home</nowiki></tt>'''

== URL Rewriting für kürzere URL's ==

TODO: .htaccess Beispiel

== Weiterführende Links ==

* WIKI von DAViCal: http://wiki.davical.org
** [http://wiki.davical.org/w/CalDAV_Clients CalDAV Clients]

* Alternativen
** [[RadicaleCalDAVServer]]
** [[ChandlerServer]]

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:CalDAV]]

DAViCal installieren

2019-12-08T16:47:44Z

Ara00-wp: /* User anlegen und konfigurieren */

== Allgemein ==
=== Beschreibung ===
[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.

Das CalDAV-Protokoll bietet viele Funktionen, die noch nicht von allen Clients unterstützt werden, darunter Serien, Erinnerungen, Einladungen, Ressourcen, Arbeitsgruppen etc.

DAViCal ist in PHP geschrieben, lizensiert unter GPL.

DAViCal erlaubt auch über das WebDAV-Protokoll Kalender zu lesen, aber nicht zu modifizieren.

=== Voraussetzungen ===

DAViCal erfordert folgende technische Ressourcen:
* PostgreSQL
* Webserver mit PHP5
* Perl für den Installationsvorgang
* Ein Dateisystem mit erweiterten Attributen.

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.

== Installation ==

=== Design ===

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.

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.

=== Subdomain aufschalten ===

Im Folgenden werden folgende Domainkonfigurationsdaten als Beispiel verwendet:

{| class="wikitable"
|- class="hintergrundfarbe5"
! Typ !! Wert !! Beschreibung
|-
| Subdomain || <tt>cal.example.org</tt> || Die Subdomain, unter der ein DAViCal-Server laufen soll
|-
| Domain-Admin || <tt>xyz00-hans</tt> || Der User, dem die Subdomain delegiert wurde
|}

=== Quellen ===

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.

Die jeweils neusten Versionen befinden sich unter:
* DAViCal: http://debian.mcmillan.net.nz/packages/davical/
* AWL: http://debian.mcmillan.net.nz/packages/awl/

Hier jeweils die Source-Dateien (<tt>*.tar.gz</tt>) benutzen.

==== Download ====

<pre><nowiki>
$ cd ~/doms/cal.example.org/var
$ wget http://debian.mcmillan.net.nz/packages/awl/awl-0.53.tar.gz
$ wget http://debian.mcmillan.net.nz/packages/davical/davical-1.1.1.tar.gz
</nowiki></pre>

==== Auspacken ====

Um die Dateien für den Betrieb in der Serverumgebung lesbar zu machen, die Dateierzeungsmaske temporär auf 022 setzen:

<pre><nowiki>
$ umask 022
</nowiki></pre>

Dann die heruntergeladenen Tarballs mit <tt>tar</tt> auspacken:

<pre><nowiki>
$ tar xfvz awl-0.46.tar.gz
$ tar xfvz davical-0.9.9.4.tar.gz
</nowiki></pre>

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

<pre><nowiki>
$ ln -s awl-0.53 awl
$ ln -s davical-1.1.1 davical
</nowiki></pre>

Und zum Schluß die ursprüngliche Dateierzeugungsmaske wiederherstellen:

<pre><nowiki>
$ umask 077
</nowiki></pre>

=== PostgreSQL vorbereiten ===

DAViCal benötigt eine eigene PostgreSQL-Datenbank sowie 2 Datenbanknutzer.

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.

==== Datenbank und Datenbanknutzer anlegen ====

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.

{| class="wikitable"
|- class="hintergrundfarbe5"
! Typ !! Wert !! Beschreibung
|-
| DB-Admin || <tt>xyz00_davical_dba</tt> || Der PostgreSQL-Nutzer, dem die Datenbank gehört und der administrative Tätigkeiten durchführt.
|-
| DB-Nutzer || <tt>xyz00_davical_app</tt> || Der PostgreSQL-Nutzername, den DAViCal benutzt, um in der Datenbank zu lesen und zu schreiben.
|-
| Datenbank || <tt>xyz00_davical</tt> || Die PostgreSQL-Datenbank, die DAViCals Daten enthält.
|}

==== Umgebungsvariablen und PostgreSQL-Paßwort ====

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.

<pre><nowiki>
$ su xyz00
$ hsadmin -c postgresqluser.add --set:name=xyz00_davical_dba --set:password=geheim
$ hsadmin -c postgresqluser.add --set:name=xyz00_davical_app --set:password=geheim
</nowiki></pre>

Als Besitzer der DAViCal-Datenbank <tt>xyz00_davical_dba</tt> angeben; als Zeichenkodierung ist das Default <tt>UTF-8</tt> richtig:

<pre><nowiki>
$ hsadmin -c postgresqldb.add --set:name=xyz00_davical --set:owner=xyz00_davical_dba
$ exit
</nowiki></pre>

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.

<pre><nowiki>
$ echo "localhost:5432:*:xyz00_davical_dba:geheimes_passwort" >> ~/.pgpass
$ echo "localhost:5432:*:xyz00_davical_app:geheimes_passwort" >> ~/.pgpass
$ chmod 0600 ~/.pgpass
</nowiki></pre>

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.

<pre><nowiki>
$ PGHOST=localhost
$ PGUSER=xyz00_davical_dba
$ PGDATABASE=xyz00_davical
$ export PGHOST PGUSER PGDATABASE
</nowiki></pre>

==== PL/pgSQL installieren ====

In der Datenbank wird die prozedurale Sprache PL/pgSQL benötigt. Diese wird durch den folgenden Befehl angelegt:

<pre><nowiki>
$ psql -A -c "CREATE LANGUAGE plpgsql;"
</nowiki></pre>

==== Datenbank-Tabellen anlegen und initialisieren ====

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.

<pre><nowiki>
$ psql -A -f awl/dba/awl-tables.sql
$ psql -A -f awl/dba/schema-management.sql
$ psql -A -f davical/dba/davical.sql
$ ./davical/dba/update-davical-database –dbhost=${PGHOST} –dbuser=${PGUSER} –dbname=${PGDATABASE} --appuser=${PGDATABASE}_app
$ psql -A -f davical/dba/base-data.sql
</nowiki></pre>

Für den DAViCal-Admin muß noch ein Passwort gesetzt werden – '<tt>**</tt>' vor dem Passwort ist hier wichtig.

<pre><nowiki>
$ psql -A -c "UPDATE usr SET password = '**geheim' WHERE user_no = 1;"
</nowiki></pre>

=== Konfiguration ===

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.

<pre><nowiki>
$ cat > davical/config/config.php
$c->pg_connect[] = "dbname=xyz00_davical user=xyz00_davical_app host=localhost";
$c->use_persistent = true;
$c->sysabbr = 'cal@example.org';
$c->admin_email = 'admin@cal.example.org';
$c->system_name = 'CalDAV Server example.org';
$c->default_locale = 'de_DE';
$c->template_usr = array( 'active' => true,
'locale' => 'de_DE',
'date_format_type' => 'E',
'email_ok' => date('Y-m-d')
);
^D
</nowiki></pre>

=== Fast-CGI-Patch ===

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.

In der Shared-Hosting-Umgebung von Hostsharing kann die notwendige Anpassung über eine Rewrite-Anweisung in der <tt>.htaccess</tt>-Datei gemacht werden:

<pre><nowiki>
$ cd ~/doms/cal.example.org/var/davical/htdocs
$ cat >> .htaccess
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization},L]
^D
</nowiki></pre>

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:

<pre><nowiki>
$ chmod 0644 .htaccess
</nowiki></pre>

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

@@ -101,10 +101,10 @@
/**
* Get HTTP Auth to work with PHP+FastCGI
*/
if ( !isset($_SERVER['AUTHORIZATION']) && isset($_SERVER['HTTP_AUTHORIZATION']) && !empty($_SERVER['HTTP_AUTHORIZATION']))
$_SERVER['AUTHORIZATION'] = $_SERVER['HTTP_AUTHORIZATION'];
- if (isset($_SERVER["AUTHORIZATION"]) && !empty($_SERVER["AUTHORIZATION"])) {
- list ($type, $cred) = split (" ", $_SERVER['AUTHORIZATION']);
+ if (isset($_SERVER["REDIRECT_HTTP_AUTHORIZATION"]) && !empty($_SERVER["REDIRECT_HTTP_AUTHORIZATION"])) {
+ list ($type, $cred) = explode (" ", $_SERVER['REDIRECT_HTTP_AUTHORIZATION']);
if ($type == 'Basic') {
list ($user, $pass) = explode (":", base64_decode($cred));
$_SERVER['PHP_AUTH_USER'] = $user; }

=== Webspace aktivieren ===

Schließlich muß die Installation noch mit dem Webspace verknüpft werden.
<pre><nowiki>
$ cd ~/doms/cal.example.org
$ rm -r htdocs-ssl
$ ln -s var/davical/htdocs htdocs-ssl
</nowiki></pre>

[[Bild:DAViCAl-home.png‎|miniatur|400px|right|Die Login-Seite der DAViCal-Web-Oberfläche]]

Die URL des User-Interfaces lautet jetzt '''<tt><nowiki>https://cal.example.org/</nowiki></tt>'''.

Wenn alles richtig gemacht wurde, erscheint an dieser URL die Login-Seite.

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.

== Nutzung ==

=== User anlegen und konfigurieren ===

Im User-Interface muß man sich als Admin (oder Nutzer mit Adminrechten) einloggen um neue Nutzer anzulegen.

Um einen neuen Nutzer anzulegen: '''Menu''' → '''User Functions''' → '''Create Principal'''

{| class="wikitable"
|- class="hintergrundfarbe5"
! Feld !! Wert !! Beschreibung
|-
| Principal ID || ''New Principal'' || Bei neuen Nutzern wird das Feld automatisch beim Anlegen gefüllt
|-
| Username || hans || Nutzername für den Kalender. Der Username ist Bestandteil der Kalender-URL
|-
| Change Password || geheimespasswort ||
|-
| Confirm Password || geheimespasswort ||
|-
| Fullname || Hans Meier || Der Name des Nutzers
|-
| Email Address || hans@example.org || Über die E-Mail-Adresse ist der Nutzer für andere Nutzer im System zu finden, z.B. für Einladungen
|-
| Locale || Deutsch ||
|-
| Date Format Style || European ||
|-
| Principal Type || Person || Üblicherweise Person für einen natürlichen Nutzer (hier können auch Ressourcen und Gruppen angelegt werden)
|-
| Administrator || – || Falls der User Adminrechte bekommen soll
|-
| Active || X || Soll der Nutzer aktiv geführt werden?
|}

Beim Anlegen des '''ersten''' Nutzers erscheint eine Fehlermeldung:

ERROR: SQL error "23505" - ERROR: duplicate key value violates unique constraint "principal_pkey""
Home calendar added. 

Dies ist ein Bug. Siehe auch [http://lists.morphoss.com/pipermail/davical-dev/2011/000117.html Thread in Dev-Mailingliste].

Zum Umgehen des Bugs einfach den Nutzer nochmal anlegen und dann funktioniert alles ;-)

=== Zugriff über Client-Programme ===

Der Zugriff auf den Kalender erfolgt über die URL: '''<tt><nowiki>https://cal.example.org/caldav.php/user/home</nowiki></tt>'''

* user = Name des angelegte Nutzers, also z.B. '''<tt>hans</tt>'''
* 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

==== Beispiel Thunderbird ====

Ist in Thunderbird die Lightning-Erweiterung installiert, dann kann der Kalender folgendermaßen eingerichtet werden:

'''Menu''' → '''Datei''' → '''Neu''' → '''Kalender'''

Auf den Folgenden Seiten ist auszuwählen:
* ''Im Netzwerk''
* ''CalDAV''
* Spezifische Angaben
** Name, z.B. ''hans@example''
** Farbe: auswählen in welcher Farbe der Kalender angezeigt werden soll
** Alarm: ja
** Email: Email auswählen

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.

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.

===== Mehrere Kalender auf gleichem Server =====

Hat man mehrere Kalender auf dem gleichen Server – 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].

Diesen Bug kann man relativ einfach umgehen, indem man weitere Subdomains anlegt, die auf die gleiche Installation verweisen, also z.B.

<pre><nowiki>
$ cd /home/doms/example.org/subs-ssl
$ mkdir cal1
$ mkdir cal2
</nowiki></pre>

und jeweils eine <tt>.htaccess</tt> in die neuen Verzeichnis mit folgendem Inhalt schreibt:

<pre><nowiki>
RewriteEngine on
RewriteRule ^.htaccess$ - [F]
RewriteRule ^(.*)$ https://cal.example.org/$1 [P]
</nowiki></pre>

Nicht vergessen:

<pre><nowiki>
chmod 0644 cal1/.htaccess
chmod 0644 cal2/.htaccess
</nowiki></pre>

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:

* '''<tt><nowiki>https://cal.example.org/caldav.php/hans/home</nowiki></tt>'''
* '''<tt><nowiki>https://cal1.example.org/caldav.php/hans/work</nowiki></tt>'''
* '''<tt><nowiki>https://cal2.example.org/caldav.php/maria/home</nowiki></tt>'''

== URL Rewriting für kürzere URL's ==

TODO: .htaccess Beispiel

== Weiterführende Links ==

* WIKI von DAViCal: http://wiki.davical.org
** [http://wiki.davical.org/w/CalDAV_Clients CalDAV Clients]

* Alternativen
** [[RadicaleCalDAVServer]]
** [[ChandlerServer]]

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:CalDAV]]

Mailman Installieren

2019-12-08T16:46:28Z

Ara00-wp: /* Anleitung */

== Vorab: Die Wahl von Mailman 2 ==

Mailman 2 hängt von Python 2.7 ab und wird damit voraussichtlich nur noch eine begrenzte Nutzungsdauer haben. Mailman 3 ist jetzt verfügbar (siehe [[Mailman_3_installieren]]), aber deutlich schwerer und komplexer im Betrieb. Es gibt auch weniger leistungsfähige Software, um E-Mail-Verteiler zu betreiben, wie beispielsweise mlmmj. Für eine Diskussion der Situation im Oktober 2019, siehe das HS-Support-Archiv ab [https://lists.hostsharing.net/archiv/support/2019-October/067243.html hier.]

== Mailman 2 installieren ==

(zuletzt getestet mit mailman-2.1.29; Installation durch Paketuser)

Vielen Dank an alle Benutzer, die Verbesserungen beisteuern!

=== Unter welchem Account installieren? ===

Mailman kann vom Paketadmin (beipsielsweise "xyz00") oder von einem Paketuser (bspw. "xyz00-listen") installiert werden. Letzteres ist dringend empfohlen, denn Mailman vom Paketadmin installiert wird, haben ausnahmslos alle Paketuser direkten Zugriff auf die Mailman-Daten, und bei Sicherheitslücken in Mailman wäre eventuell eine Rechte-Eskalierung auf Paketadmin-Ebene potentiell zu befürchten.

Dem Paketuser, unter dem Mailman installiert wird, können mehrere Subdomains aufschaltet werden, und Mailinglisten können auch die Domainnamen verwenden, die anderen Paketusern gehören.

Vorteil der Installation als Paketuser ist, dass nur dieser direkten Zugriff auf die Mailmandaten hat und mailman ohne Paketadminrechte läuft. Während der Emailauslieferung gelten (wie immer bei der Mailweiterleitung durch .forward-Dateien oder durch procmail) die Rechte des Paketusers, dem die Mailman-Installation gehört.

Nachteil der Installation als Paketuser ist lediglich, dass die Paketdomain mit dem SSL Zertifikat von Hostsharing nicht genutzt werden kann.

=== Einen User und eine Domain anlegen ===

Unter admin.hostsharing.net als xyz00 anmelden; den User xyz00-listen erzeugen; die Domain listen.example.com mit "Domain-User" xyz00-listen anlegen. Aus admin.hostsharing.net abmelden.

Mit [[Login_mit_SSH|SSH]] an hostsharing.net als xyz00-listen anmelden. Die Redirect-Zeile aus ~/doms/listen.example.com/htdocs-ssl/.htaccess löschen:

~$ echo "" > ~/doms/listen.example.com/htdocs-ssl/.htaccess

Die Default-Subdomains www.* löschen:

~$ rm -r doms/listen.example.com/subs/www/
~$ rm -r doms/listen.example.com/subs-ssl/www/

=== Sourcen besorgen und entpacken ===

Unter http://www.gnu.org/software/mailman/ die aktuelle Software besorgen. Dort findet sich ein Link zu den 2er-Versionen von Mailman (http://ftp.gnu.org/gnu/mailman/). Die letzte Version downloaden ...

~$ wget http://ftp.gnu.org/gnu/mailman/mailman-2.1.29.tgz

... und entpacken:

~$ tar -xzvf mailman-2.1.29.tgz

Ab diesem Augenblick gibt es ein Verzeichnis namens 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.)

=== var-Verzeichnis für Log-Dateien anlegen ===

Bei der Installation als Paketuser (xyz00-listen):
~$ cd && mkdir -p mailman/var
~$ chmod 02775 mailman/var

Bei der Installation als Paketadmin (xyz00):
~$ cd && mkdir var/mailman
~$ chmod 02775 var/mailman

=== Mailman konfigurieren ===

In das Source-Verzeichnis wechseln:

~$ cd mailman-2.1.29

Bei der Installation als Paketuser (xyz00-listen):
~/mailman-2.1.29$ ./configure --prefix=/home/pacs/xyz00/users/listen/mailman \
--with-username=xyz00-listen \
--with-groupname=xyz00 \
--with-var-prefix=/home/pacs/xyz00/users/listen/mailman/var \
--with-cgi-gid=xyz00 \
--with-mail-gid=xyz00

Bei der Installation als Paketadmin (xyz00):
~/mailman-2.1.29$ ./configure --prefix=/home/pacs/xyz00/mailman \
--with-username=xyz00 \
--with-groupname=xyz00 \
--with-var-prefix=/home/pacs/xyz00/var/mailman \
--with-cgi-gid=xyz00 \
--with-mail-gid=nogroup

(Die Rückwärtsschrägstriche "\" am Zeilenende bedeuten, dass der Befehl in der nächsten Zeile weitergeht. Alternativ können alle Argumente in eine Zeile getippt werden.)

=== Mailman kompilieren ===

~/mailman-2.1.29$ make
~/mailman-2.1.29$ make install

=== Datenrechte prüfen ===

Sicherheitshalber die Dateirechte durch Mailmans mitgeliefertes Tool prüfen und ggf. korrigieren lassen:

~/mailman-2.1.29$ cd ..
~$ mailman/bin/check_perms -f

== Die neue Mailman-Installation konfigurieren ==

=== Konfigurationsdatei mm_cfg.py editieren ===

~$ nano mailman/Mailman/mm_cfg.py

Eine Beispielkonfiguration für listen.example.com könnte so aussehen:

[...]
##################################################
# Put YOUR site-specific settings below this line.
# -*- python -*-

DEFAULT_HOST_NAME = 'listen.example.com'
DEFAULT_EMAIL_HOST = 'listen.example.com'
DEFAULT_URL_HOST = 'listen.example.com'
add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)
add_virtualhost(zweite.listendomain.com, zweite.listendomain.com)

DEFAULT_SERVER_LANGUAGE = 'de'

DEFAULT_URL_PATTERN = 'http://%s/'

# Es wird der HS Mailversand für Bulkmail verwendet:
SMTPHOST = 'localhost'
SMTPPORT = 4587
SMTP_AUTH = True
SMTP_USER = 'xyz00-listen'
SMTP_PASSWD = 'das-passwort-des-o.-g.-users'
SMTP_USE_TLS = True

In ~/mailman/Mailman/Defaults.py sieht man, was in mm_cfg.py alles angepasst werden kann.

=== CGI-Programme in die Domain kopieren ===

Bei der Installation als Paketuser (xyz00-listen):

Die fertig kompilierten CGIs von Mailman müssen in das CGI-Verzeichnis der Domain (oder der Domains), auf der das Webfrontend von Mailman laufen soll, kopiert werden. Symbolische Links sind nicht ausreichend.

~$ mkdir ~/doms/listen.example.com/cgi-ssl/mailman
~$ cp mailman/cgi-bin/* doms/listen.example.com/cgi-ssl/mailman/

Zusätzlich muss das sticky-Flag von den kopierten Dateien entfernt werden:

~$ chmod g-s ~/doms/listen.example.com/cgi/mailman/*

Bei der Installation als Paketadmin (xyz00):

Die CGI-Programme können im Mailman-Verzeichnis bleiben. Im CGI-Verzeichnis von jeder Domain, auf der das Mailman-Webfrontend laufen soll, werden symbolische Links dazu erstellt:

~$ cd doms/listen.example.com/cgi-ssl
~/doms/listen.example.com/cgi-ssl$ ln -s ../../../mailman/cgi-bin mailman

=== Mailman-Icons in die Domains kopieren ===

Die Icons können wahlweise verlinkt oder kopiert werden:

~$ cd doms/listen.example.com/htdocs-ssl
~/doms/listen.example.com/htdocs-ssl$ ln -s ../../../mailman/icons

oder

~$ cp -R mailman/icons doms/listen.example.com/htdocs-ssl/

=== Die Datei .htaccess bearbeiten ===

Bei einer dedizierten Mailman-Domain sollte man dafür sorgen, dass Mailman nicht nur unter https://listen.example.com/cgi-bin/mailman, sondern auch unter https://listen.example.com erreichbar ist.

Dazu werden in ~/doms/listen.example.com/htdocs-ssl/.htaccess folgende Rewrite-Anweisungen eintragen.

RewriteEngine On
RewriteCond %{REQUEST_URI} !^/icons/
RewriteRule ^(.*)$ /cgi-bin/mailman/$1
RewriteRule ^/cgi-bin/mailman/$ /cgi-bin/mailman/listinfo

Beachte dabei die zweite Zeile: Anfragen für Icons sollen ''nicht'' umgeschrieben werden.

Wenn Mailman z.B. auf einer als Unterverzeichnis angelegten Subdomain läuft und unter 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:

RewriteEngine On
RewriteCond %{REQUEST_URI} !^/icons/
RewriteRule ^mailman/(.*)$ /cgi-bin/mailman/$1
RewriteRule ^/cgi-bin/mailman/$ /cgi-bin/mailman/listinfo

(In diesem Fall kann die Zeile DEFAULT_URL_PATTERN... in der mm_cfg.py auskommentiert werden.)

=== Hauptpasswort setzen ===

Das "site password" ist in Mailman eine Art Generalschlüssel: es wird neben dem jeweiligen Admin- oder Moderator-Passwort überall in der Weboberfläche für sämtliche Mailing-Listen akzeptiert. Also vorsichtig wählen! Das "site password" einrichten mit dem Befehl:

~$ mailman/bin/mmsitepass

=== Cronjobs einrichten ===

In die [[Cron |Crontab]] werden Befehle eingetragen, um die Mail-Warteschlange abzuarbeiten, Logs zu löschen, usw.:

# Warteschlange jede Minute bearbeiten:
* * * * * ~/mailman/bin/qrunner -o -r All
# Verarbeitungslogs in der 47ten Minute jeder Stunde löschen:
47 * * * * rm -f ~/var/mailman/logs/qrunner

Damit übernimmt cron die Funktion des qrunner-Dämons, der normalerweise auf einem Mailman-Server laufen sollte.

Das Logfile wird stündlich gelöscht, da es sonst sehr schnell sehr groß wird. Falls Mailman von einem Paketuser (bspw. "xyz00-listen") installiert wurde, sollte die letzte Zeile im Beispiel oben so lauten:

47 * * * * rm -f ~/mailman/var/logs/qrunner

... entsprechend dem beim Konfigurieren angegebenen var-Verzeichnis, siehe oben.

Zudem müssen noch die von Mailman ohnehin vorgesehenen cron-Aufträge aus ~/mailman/cron/crontab.in dem crontab des Users angehängt werden:

crontab -l > mycronjobs.tmp
cat ~/mailman/cron/crontab.in >> mycronjobs.tmp
crontab mycronjobs.tmp

== Mailinglisten einrichten ==

Jetzt läuft die Software; nun können die eigentlichen Verteiler angelegt werden. Als erster '''muß''' ein Hauptverteiler ("site list") eingerichtet werden. Dieser Verteiler dient u.a. als Absender der Paßwort-Erinnerungen an die Abonnenten aller Mailinglisten. Er hat standardmäßig den Namen "mailman". Falls ein anderer Name verwendet werden soll, muß dieser mit der Anweisung

MAILMAN_SITE_LIST = 'sitelistname'

in der Konfigurationsdatei mailman/Mailman/mm_cfg.py eingetragen werden.

=== Den Hauptverteiler "mailman" anlegen ===

Die "site list" mit dem Namen "mailman" ist die Mailingliste der lokalen Mailman-Administratoren. Sie wird zur einwandfreien Funktion von Mailman benötigt.

Mit dem Mailman-Befehl newlist den Verteiler anlegen:

~$ mailman/bin/newlist mailman
Enter the email of the person running the list: admin@xyz00.hostsharing.net
Initial mailman password:

(Der Befehl newlist kann – alternativ zur Weboberfläche – später benutzt werden, um gewöhnliche Mailinglisten anzulegen.)

Nur dieses eine Mal für die "site list" müssen wir die Konfigurationsvorgaben laden. (Gewöhnliche Mailinglisten werden später über die Weboberfläche konfiguriert.)

Falls mailman vom Paketuser (bspw. "xyz00-listen") installiert wurde:

~$ mailman/bin/config_list -i ~/mailman/var/data/sitelist.cfg mailman

Falls mailman vom Paketadmin ("xyz00") installiert wurde:

~$ mailman/bin/config_list -i ~/var/mailman/data/sitelist.cfg mailman

Diese Konfigurationsdatei soll '''nicht''' auf gewöhnliche Mailinglisten anwendet werden.

=== E-Mail Adressen bei Mailman einrichten ===

Sobald ein neuer Verteiler angelegt worden ist, sendet Mailman eine E-Mail an den dabei eingetragenen Listenadministrator. Diese E-Mail enthält die Anweisung, E-Mail-Aliases für den neuen Verteiler und für die verschiedenen Mailman-Funktionen anzulegen. Bei Hostsharing wird die Zustellung von E-Mails an Mailman anders geregelt: alle E-Mails an Mailman werden an erweiterte ''E-Mail-Adressen'' des Mailman-Users xyz00-listen geschickt. Diese Adressen haben die form xyz00-listen'''+'''<liste>[_funktion]. E-Mails an diese Adressen werden dann durch Pipe-Anweisungen in ''.forward-Dateien'' im Home-Verzeichnis des Mailman-Users mit den entsprechenden Argumenten an Mailman übergeben.

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.

Das folgende Beispiel zeigt die Befehle, mit denen in einer interaktiven hsscript-Sitzung die E-Mail-Adressen für die Hauptliste "mailman" eingerichtet werden. (Für spätere Mailinglisten wird in den Argumenten "mailman" durch den Namen der Mailingliste ersetzt.)

hsscript -u xyz00 -i
[hsscript verlangt die Eingabe des Passworts vom Paketadmin xyz00; dann können diese Befehle eingegeben werden:]
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman',target:'xyz00-listen+mailman'}})
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-admin',target:'xyz00-listen+mailman-admin'}})
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-bounces',target:'xyz00-listen+mailman-bounces'}})
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-confirm',target:'xyz00-listen+mailman-confirm'}})
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-join',target:'xyz00-listen+mailman-join'}})
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-leave',target:'xyz00-listen+mailman-leave'}})
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-owner',target:'xyz00-listen+mailman-owner'}})
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-request',target:'xyz00-listen+mailman-request'}})
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-subscribe',target:'xyz00-listen+mailman-subscribe'}})
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-unsubscribe',target:'xyz00-listen+mailman-unsubscribe'}})

Die korrekte Einrichtung der E-Mail-Adressen kann in der Web-Oberfläche von hsadmin kontrolliert werden.

Für jede der soeben eingerichteten Adressen wird nun eine .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:

"|/home/pacs/xyz00/users/listen/mailman/mail/mailman [Befehl] [Listenname]"

Zum Beispiel wird die .forward-Datei .forward+mailman-subscribe verwendet, wenn eine E-Mail an die Adresse mailman-subscribe@listen.example.com eingeht. Aufgrund der oben eingerichteten E-Mail-Adresse mit dem Ziel "xyz00-listen+mailman-subscribe" wertet der Mail-Transfer-Agent die .forward-Datei .forward+mailman-subscribe im Home-Verzeichnis des Users xyz00-listen aus, und entsprechend ihrem Inhalt wird die Mail an die Mailman-Software mit den Argumenten "subscribe mailman" übergeben.

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

echo 'admin@xyz00.hostsharing.net' > .forward # Weiterleitung von cron Fehlern etc an Paketadmin.
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman post mailman"' > .forward+mailman
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman admin mailman"' > .forward+mailman-admin
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman bounces mailman"' > .forward+mailman-bounces
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman confirm mailman"' > .forward+mailman-confirm
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman join mailman"' > .forward+mailman-join
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman leave mailman"' > .forward+mailman-leave
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman owner mailman"' > .forward+mailman-owner
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman request mailman"' > .forward+mailman-request
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman subscribe mailman"' > .forward+mailman-subscribe
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman unsubscribe mailman"' > .forward+mailman-unsubscribe

Die vielen Befehle können von dieser Anleitung kopiert und nach Anpassung auf den tatsächlichen Unsernamen in die SSH-Sitzung kopiert werden. Noch leichter ist es, mit einem Editor einen Shell-Skript namens ~/bin/addforwards mit folgendem Inhalt zu erstellen:

#!/bin/sh
# .forward-Dateien für einen Verteiler unter Mailman einrichten.
#
if [ "$1" = "" ] ; then
echo "Aufruf: $0 Listenname\n"
exit
fi
if [ "$2" != "" ] ; then
echo "Aufruf: $0 Listenname\n"
exit
fi
if [ "`pwd`" != "`echo ~`" ] ; then
echo "Diesen Befehl vom Home-Verzeichnis aus aufrufen.\n"
exit
fi
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman post $1\"" > .forward+$1
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman admin $1\"" > .forward+$1-admin
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman bounces $1\"" > .forward+$1-bounces
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman confirm $1\"" > .forward+$1-confirm
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman join $1\"" > .forward+$1-join
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman leave $1\"" > .forward+$1-leave
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman owner $1\"" > .forward+$1-owner
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman request $1\"" > .forward+$1-request
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman subscribe $1\"" > .forward+$1-subscribe
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman unsubscribe $1\"" > .forward+$1-unsubscribe
exit

Der Skript muß natürlich als ausführbar gekennzeichnet werden:

~$ chmod u+x bin/addforwards

Die Erweiterung dieses Skripts um die hsscript-Befehle wird dem Leser als Aufgabe überlassen.

=== Administration ===

Als erstes sollte man als Administrator der neuen Mailman-Installation die Liste "mailman" selbst abonnieren. Die Liste "mailman" kann aber unter https://listen.example.com/mailman/admin/mailman verwaltet werden.

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:

~$ mailman/bin/newlist <Listenname>

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.

Für die Verwaltung der Mailinglisten im Alltag, d.h. den Umgang mit Bounces, Spam, Abonnenten usw., siehe u.a. die [https://wiki.list.org/ Mailman-Wiki].

== Feintuning ==

Wer will, kann auch noch etwas Platz sparen. Die normale Mailmaninstallation schlägt mit über 20 MB zu Buche...

Mit den folgenden Tips kann man das auf ca. 6 MB reduzieren :)

Es kann natürlich sein, dass ich zuviel lösche, aber bei mir funktioniert's. Wenn ihr also sicher(er) sein wollt, dass euch der Mailman nicht um die Ohren fliegt, macht das nicht!

* ~/mailman/cgi-bin und ~/mailman/icons können gelöscht werden, falls sie an andere Stelle kopiert worden sind.
* Die nicht benötigten Sprachen in ~/mailman/messages löschen.
* Die nicht benötigten Sprachen in ~/mailman/templates löschen (bis auf englisch).
* ~/mailman/tests kann, soweit ich das sehe, komplett gelöscht werden.
* Falls man koreanisch und japanisch nicht braucht, kann man folgendes machen:
* in ~/mailman/bin/paths.py, ~/mailman/cron/paths.py und ~/mailman/scripts/paths.py die Zeilen:

# In a normal interactive Python environment, the japanese.pth and korean.pth
# files would be imported automatically. But because we inhibit the importing
# of the site module, we need to be explicit about importing these codecs.
if not jaok:
import japanese
# As of KoreanCodecs 2.0.5, you had to do the second import to get the Korean
# codecs installed, however leave the first import in there in case an upgrade
# changes this.
if not kook:
import korean
import korean.aliases

auskommentieren.

Dann kann man ~/mailman/pythonlib/japanese, ~/mailman/pythonlib/korean, ~/mailman/pythonlib/korean.pth sowie ~/mailman/pythonlib/lib löschen.

Man kann auch noch die Debug-Informationen aus den binaries strippen:

strip ~/mailman/mail/mailman
strip ~/mailman/cgi-bin/*

Falls die CGIs nicht gesymlinkt wurden:

strip ~/doms/listen.example.com/cgi/mailman/*

== Multidomainfähigkeit ==

Seit Mailman 2.x kann eine Mailman-Installation unter gewissen Einschränkungen für mehrere Domains verwendet werden. Hier soll kurz gezeigt werden, was geht und wie es geht.

=== Anleitung ===

Logischerweise muss das Webfrontend (die CGIs) auf allen Domains installiert werden.

Wenn man nun Mailinglisten mit newlist neu anlegt, muss man den Hostnamen für das Webfontend mit angeben, und zwar so:

~$ mailman/bin/newlist listenname@listen.example.com

Es ist ggf. wichtig, dass in der mm_cfg.py eine entsprechende add_virtualhost-Direktive für www.example.com steht, die der Frontend-URL einen Host-Part für die Mailadressen zuordnet. Ist eine solche Direktive nicht vorhanden, so wird listen.example.com sowohl als URL für das Webfrontend wie auch als Hostpart für E-Mailadressen verwendet. (Was für separate aufgeschaltete Domains wie z.B. listen.example.com gerade zutrifft.)

Liegt das Frondend nicht auf der Maildomain ist es wichtig, dass ihr Mailman sagt, für welches die zugehörige Maildomain ist. Dies tut ihr in der Datei ~/mailman/Mailman/mm_cfg.py:

Also z.B.
DEFAULT_URL_HOST = 'www.example.com'
DEFAULT_EMAIL_HOST = 'listen.example.com'
add_virtualhost(DEFAULT_URL_HOST,DEFAULT_EMAIL_HOST)

und
add_virtualhost('www.zoopnet.de', 'lists.zoopnet.de')

Das bedeutet, dass Mailman per default davon ausgeht, dass alle Listen für die Domain example.com sind.
Alle weiteren add_virtualhost-Direktiven ordnen einem Hostnamen für das Webfrontend (z.B. www.zoopnet.de) einen Hostpart für die Adresse der Mailinglisten (z.B. lists.zoopnet.de) zu.

Tip von Raimund Specht: Lässt man den zweiten Parameter weg, also schreibt z.B. add_virtualhost('www.example.org'), dann benutzt Mailman als Hostpart alles was nach dem ersten Punkt steht, hier also example.org als Maildomain.

Prinzipiell war's das. Man muss die Listeneinträge natürlich immer in die richtige virtusertable eintragen, und für gleichnamige Mailinglisten auf verschiedenen Domains (mailman@*) verschidene +Ergänzungen bzw. aliase verwenden. :)

=== Probleme ===

Verschiedene Listen mit gleichem Namen (also z.B. liste@example1.com und liste@example2.com) sind mit Mailman 2.1 leider nicht möglich.

== Tips und Tricks ==

=== URL Änderungen ===
Nach URL Änderungen stimmen Links im Web-Interface nicht mehr und Listen werden nicht mehr angezeigt.
Es sind dann, zusätzlich zur Anpassung der mm_cfg.py, schon bestehende Listen und Archive mit folgendem Befehl zu aktualisieren:
~/mailman/bin/withlist -l -r fix_url <Listen_Name> -v -u <Neue_Url>
<Listen_Name> steht für die Mailingliste, die bearbeitet werden soll. <Neue_Url> für die neue URL/Webadresse des Webinterfaces.

=== Weitere Cron-Jobs zur Mailinglisten Verwaltung ===

Folgende Cronjobs helfen bei der Verwaltung und sind User freundlich:

< In Arbeit >

== Referenzen ==

Lösung zur installation als Domainadmin (xyz00-listen) statt Paketadmin (xyz00): https://lists.hostsharing.net/archiv/support/2009-June/019414.html 

Ältere Anleitung für Installation als Domain-Admin (xyz00-listen): <http://lists.hostsharing.net/archiv/support/2005-January/012426.html> 

"Kleine Tools" auf http://hs.andreasloesch.de/, wobei das 'pac-mm-install' wahrscheinlich nicht aktuell (genug) ist 

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

Mailman Installieren

2019-12-08T16:43:40Z

Ara00-wp: /* Email Adressen einrichten */

== Vorab: Die Wahl von Mailman 2 ==

Mailman 2 hängt von Python 2.7 ab und wird damit voraussichtlich nur noch eine begrenzte Nutzungsdauer haben. Mailman 3 ist jetzt verfügbar (siehe [[Mailman_3_installieren]]), aber deutlich schwerer und komplexer im Betrieb. Es gibt auch weniger leistungsfähige Software, um E-Mail-Verteiler zu betreiben, wie beispielsweise mlmmj. Für eine Diskussion der Situation im Oktober 2019, siehe das HS-Support-Archiv ab [https://lists.hostsharing.net/archiv/support/2019-October/067243.html hier.]

== Mailman 2 installieren ==

(zuletzt getestet mit mailman-2.1.29; Installation durch Paketuser)

Vielen Dank an alle Benutzer, die Verbesserungen beisteuern!

=== Unter welchem Account installieren? ===

Mailman kann vom Paketadmin (beipsielsweise "xyz00") oder von einem Paketuser (bspw. "xyz00-listen") installiert werden. Letzteres ist dringend empfohlen, denn Mailman vom Paketadmin installiert wird, haben ausnahmslos alle Paketuser direkten Zugriff auf die Mailman-Daten, und bei Sicherheitslücken in Mailman wäre eventuell eine Rechte-Eskalierung auf Paketadmin-Ebene potentiell zu befürchten.

Dem Paketuser, unter dem Mailman installiert wird, können mehrere Subdomains aufschaltet werden, und Mailinglisten können auch die Domainnamen verwenden, die anderen Paketusern gehören.

Vorteil der Installation als Paketuser ist, dass nur dieser direkten Zugriff auf die Mailmandaten hat und mailman ohne Paketadminrechte läuft. Während der Emailauslieferung gelten (wie immer bei der Mailweiterleitung durch .forward-Dateien oder durch procmail) die Rechte des Paketusers, dem die Mailman-Installation gehört.

Nachteil der Installation als Paketuser ist lediglich, dass die Paketdomain mit dem SSL Zertifikat von Hostsharing nicht genutzt werden kann.

=== Einen User und eine Domain anlegen ===

Unter admin.hostsharing.net als xyz00 anmelden; den User xyz00-listen erzeugen; die Domain listen.example.com mit "Domain-User" xyz00-listen anlegen. Aus admin.hostsharing.net abmelden.

Mit [[Login_mit_SSH|SSH]] an hostsharing.net als xyz00-listen anmelden. Die Redirect-Zeile aus ~/doms/listen.example.com/htdocs-ssl/.htaccess löschen:

~$ echo "" > ~/doms/listen.example.com/htdocs-ssl/.htaccess

Die Default-Subdomains www.* löschen:

~$ rm -r doms/listen.example.com/subs/www/
~$ rm -r doms/listen.example.com/subs-ssl/www/

=== Sourcen besorgen und entpacken ===

Unter http://www.gnu.org/software/mailman/ die aktuelle Software besorgen. Dort findet sich ein Link zu den 2er-Versionen von Mailman (http://ftp.gnu.org/gnu/mailman/). Die letzte Version downloaden ...

~$ wget http://ftp.gnu.org/gnu/mailman/mailman-2.1.29.tgz

... und entpacken:

~$ tar -xzvf mailman-2.1.29.tgz

Ab diesem Augenblick gibt es ein Verzeichnis namens 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.)

=== var-Verzeichnis für Log-Dateien anlegen ===

Bei der Installation als Paketuser (xyz00-listen):
~$ cd && mkdir -p mailman/var
~$ chmod 02775 mailman/var

Bei der Installation als Paketadmin (xyz00):
~$ cd && mkdir var/mailman
~$ chmod 02775 var/mailman

=== Mailman konfigurieren ===

In das Source-Verzeichnis wechseln:

~$ cd mailman-2.1.29

Bei der Installation als Paketuser (xyz00-listen):
~/mailman-2.1.29$ ./configure --prefix=/home/pacs/xyz00/users/listen/mailman \
--with-username=xyz00-listen \
--with-groupname=xyz00 \
--with-var-prefix=/home/pacs/xyz00/users/listen/mailman/var \
--with-cgi-gid=xyz00 \
--with-mail-gid=xyz00

Bei der Installation als Paketadmin (xyz00):
~/mailman-2.1.29$ ./configure --prefix=/home/pacs/xyz00/mailman \
--with-username=xyz00 \
--with-groupname=xyz00 \
--with-var-prefix=/home/pacs/xyz00/var/mailman \
--with-cgi-gid=xyz00 \
--with-mail-gid=nogroup

(Die Rückwärtsschrägstriche "\" am Zeilenende bedeuten, dass der Befehl in der nächsten Zeile weitergeht. Alternativ können alle Argumente in eine Zeile getippt werden.)

=== Mailman kompilieren ===

~/mailman-2.1.29$ make
~/mailman-2.1.29$ make install

=== Datenrechte prüfen ===

Sicherheitshalber die Dateirechte durch Mailmans mitgeliefertes Tool prüfen und ggf. korrigieren lassen:

~/mailman-2.1.29$ cd ..
~$ mailman/bin/check_perms -f

== Die neue Mailman-Installation konfigurieren ==

=== Konfigurationsdatei mm_cfg.py editieren ===

~$ nano mailman/Mailman/mm_cfg.py

Eine Beispielkonfiguration für listen.example.com könnte so aussehen:

[...]
##################################################
# Put YOUR site-specific settings below this line.
# -*- python -*-

DEFAULT_HOST_NAME = 'listen.example.com'
DEFAULT_EMAIL_HOST = 'listen.example.com'
DEFAULT_URL_HOST = 'listen.example.com'
add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)
add_virtualhost(zweite.listendomain.com, zweite.listendomain.com)

DEFAULT_SERVER_LANGUAGE = 'de'

DEFAULT_URL_PATTERN = 'http://%s/'

# Es wird der HS Mailversand für Bulkmail verwendet:
SMTPHOST = 'localhost'
SMTPPORT = 4587
SMTP_AUTH = True
SMTP_USER = 'xyz00-listen'
SMTP_PASSWD = 'das-passwort-des-o.-g.-users'
SMTP_USE_TLS = True

In ~/mailman/Mailman/Defaults.py sieht man, was in mm_cfg.py alles angepasst werden kann.

=== CGI-Programme in die Domain kopieren ===

Bei der Installation als Paketuser (xyz00-listen):

Die fertig kompilierten CGIs von Mailman müssen in das CGI-Verzeichnis der Domain (oder der Domains), auf der das Webfrontend von Mailman laufen soll, kopiert werden. Symbolische Links sind nicht ausreichend.

~$ mkdir ~/doms/listen.example.com/cgi-ssl/mailman
~$ cp mailman/cgi-bin/* doms/listen.example.com/cgi-ssl/mailman/

Zusätzlich muss das sticky-Flag von den kopierten Dateien entfernt werden:

~$ chmod g-s ~/doms/listen.example.com/cgi/mailman/*

Bei der Installation als Paketadmin (xyz00):

Die CGI-Programme können im Mailman-Verzeichnis bleiben. Im CGI-Verzeichnis von jeder Domain, auf der das Mailman-Webfrontend laufen soll, werden symbolische Links dazu erstellt:

~$ cd doms/listen.example.com/cgi-ssl
~/doms/listen.example.com/cgi-ssl$ ln -s ../../../mailman/cgi-bin mailman

=== Mailman-Icons in die Domains kopieren ===

Die Icons können wahlweise verlinkt oder kopiert werden:

~$ cd doms/listen.example.com/htdocs-ssl
~/doms/listen.example.com/htdocs-ssl$ ln -s ../../../mailman/icons

oder

~$ cp -R mailman/icons doms/listen.example.com/htdocs-ssl/

=== Die Datei .htaccess bearbeiten ===

Bei einer dedizierten Mailman-Domain sollte man dafür sorgen, dass Mailman nicht nur unter https://listen.example.com/cgi-bin/mailman, sondern auch unter https://listen.example.com erreichbar ist.

Dazu werden in ~/doms/listen.example.com/htdocs-ssl/.htaccess folgende Rewrite-Anweisungen eintragen.

RewriteEngine On
RewriteCond %{REQUEST_URI} !^/icons/
RewriteRule ^(.*)$ /cgi-bin/mailman/$1
RewriteRule ^/cgi-bin/mailman/$ /cgi-bin/mailman/listinfo

Beachte dabei die zweite Zeile: Anfragen für Icons sollen ''nicht'' umgeschrieben werden.

Wenn Mailman z.B. auf einer als Unterverzeichnis angelegten Subdomain läuft und unter 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:

RewriteEngine On
RewriteCond %{REQUEST_URI} !^/icons/
RewriteRule ^mailman/(.*)$ /cgi-bin/mailman/$1
RewriteRule ^/cgi-bin/mailman/$ /cgi-bin/mailman/listinfo

(In diesem Fall kann die Zeile DEFAULT_URL_PATTERN... in der mm_cfg.py auskommentiert werden.)

=== Hauptpasswort setzen ===

Das "site password" ist in Mailman eine Art Generalschlüssel: es wird neben dem jeweiligen Admin- oder Moderator-Passwort überall in der Weboberfläche für sämtliche Mailing-Listen akzeptiert. Also vorsichtig wählen! Das "site password" einrichten mit dem Befehl:

~$ mailman/bin/mmsitepass

=== Cronjobs einrichten ===

In die [[Cron |Crontab]] werden Befehle eingetragen, um die Mail-Warteschlange abzuarbeiten, Logs zu löschen, usw.:

# Warteschlange jede Minute bearbeiten:
* * * * * ~/mailman/bin/qrunner -o -r All
# Verarbeitungslogs in der 47ten Minute jeder Stunde löschen:
47 * * * * rm -f ~/var/mailman/logs/qrunner

Damit übernimmt cron die Funktion des qrunner-Dämons, der normalerweise auf einem Mailman-Server laufen sollte.

Das Logfile wird stündlich gelöscht, da es sonst sehr schnell sehr groß wird. Falls Mailman von einem Paketuser (bspw. "xyz00-listen") installiert wurde, sollte die letzte Zeile im Beispiel oben so lauten:

47 * * * * rm -f ~/mailman/var/logs/qrunner

... entsprechend dem beim Konfigurieren angegebenen var-Verzeichnis, siehe oben.

Zudem müssen noch die von Mailman ohnehin vorgesehenen cron-Aufträge aus ~/mailman/cron/crontab.in dem crontab des Users angehängt werden:

crontab -l > mycronjobs.tmp
cat ~/mailman/cron/crontab.in >> mycronjobs.tmp
crontab mycronjobs.tmp

== Mailinglisten einrichten ==

Jetzt läuft die Software; nun können die eigentlichen Verteiler angelegt werden. Als erster '''muß''' ein Hauptverteiler ("site list") eingerichtet werden. Dieser Verteiler dient u.a. als Absender der Paßwort-Erinnerungen an die Abonnenten aller Mailinglisten. Er hat standardmäßig den Namen "mailman". Falls ein anderer Name verwendet werden soll, muß dieser mit der Anweisung

MAILMAN_SITE_LIST = 'sitelistname'

in der Konfigurationsdatei mailman/Mailman/mm_cfg.py eingetragen werden.

=== Den Hauptverteiler "mailman" anlegen ===

Die "site list" mit dem Namen "mailman" ist die Mailingliste der lokalen Mailman-Administratoren. Sie wird zur einwandfreien Funktion von Mailman benötigt.

Mit dem Mailman-Befehl newlist den Verteiler anlegen:

~$ mailman/bin/newlist mailman
Enter the email of the person running the list: admin@xyz00.hostsharing.net
Initial mailman password:

(Der Befehl newlist kann – alternativ zur Weboberfläche – später benutzt werden, um gewöhnliche Mailinglisten anzulegen.)

Nur dieses eine Mal für die "site list" müssen wir die Konfigurationsvorgaben laden. (Gewöhnliche Mailinglisten werden später über die Weboberfläche konfiguriert.)

Falls mailman vom Paketuser (bspw. "xyz00-listen") installiert wurde:

~$ mailman/bin/config_list -i ~/mailman/var/data/sitelist.cfg mailman

Falls mailman vom Paketadmin ("xyz00") installiert wurde:

~$ mailman/bin/config_list -i ~/var/mailman/data/sitelist.cfg mailman

Diese Konfigurationsdatei soll '''nicht''' auf gewöhnliche Mailinglisten anwendet werden.

=== E-Mail Adressen bei Mailman einrichten ===

Sobald ein neuer Verteiler angelegt worden ist, sendet Mailman eine E-Mail an den dabei eingetragenen Listenadministrator. Diese E-Mail enthält die Anweisung, E-Mail-Aliases für den neuen Verteiler und für die verschiedenen Mailman-Funktionen anzulegen. Bei Hostsharing wird die Zustellung von E-Mails an Mailman anders geregelt: alle E-Mails an Mailman werden an erweiterte ''E-Mail-Adressen'' des Mailman-Users xyz00-listen geschickt. Diese Adressen haben die form xyz00-listen'''+'''<liste>[_funktion]. E-Mails an diese Adressen werden dann durch Pipe-Anweisungen in ''.forward-Dateien'' im Home-Verzeichnis des Mailman-Users mit den entsprechenden Argumenten an Mailman übergeben.

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.

Das folgende Beispiel zeigt die Befehle, mit denen in einer interaktiven hsscript-Sitzung die E-Mail-Adressen für die Hauptliste "mailman" eingerichtet werden. (Für spätere Mailinglisten wird in den Argumenten "mailman" durch den Namen der Mailingliste ersetzt.)

hsscript -u xyz00 -i
[hsscript verlangt die Eingabe des Passworts vom Paketadmin xyz00; dann können diese Befehle eingegeben werden:]
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman',target:'xyz00-listen+mailman'}})
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-admin',target:'xyz00-listen+mailman-admin'}})
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-bounces',target:'xyz00-listen+mailman-bounces'}})
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-confirm',target:'xyz00-listen+mailman-confirm'}})
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-join',target:'xyz00-listen+mailman-join'}})
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-leave',target:'xyz00-listen+mailman-leave'}})
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-owner',target:'xyz00-listen+mailman-owner'}})
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-request',target:'xyz00-listen+mailman-request'}})
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-subscribe',target:'xyz00-listen+mailman-subscribe'}})
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-unsubscribe',target:'xyz00-listen+mailman-unsubscribe'}})

Die korrekte Einrichtung der E-Mail-Adressen kann in der Web-Oberfläche von hsadmin kontrolliert werden.

Für jede der soeben eingerichteten Adressen wird nun eine .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:

"|/home/pacs/xyz00/users/listen/mailman/mail/mailman [Befehl] [Listenname]"

Zum Beispiel wird die .forward-Datei .forward+mailman-subscribe verwendet, wenn eine E-Mail an die Adresse mailman-subscribe@listen.example.com eingeht. Aufgrund der oben eingerichteten E-Mail-Adresse mit dem Ziel "xyz00-listen+mailman-subscribe" wertet der Mail-Transfer-Agent die .forward-Datei .forward+mailman-subscribe im Home-Verzeichnis des Users xyz00-listen aus, und entsprechend ihrem Inhalt wird die Mail an die Mailman-Software mit den Argumenten "subscribe mailman" übergeben.

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

echo 'admin@xyz00.hostsharing.net' > .forward # Weiterleitung von cron Fehlern etc an Paketadmin.
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman post mailman"' > .forward+mailman
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman admin mailman"' > .forward+mailman-admin
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman bounces mailman"' > .forward+mailman-bounces
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman confirm mailman"' > .forward+mailman-confirm
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman join mailman"' > .forward+mailman-join
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman leave mailman"' > .forward+mailman-leave
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman owner mailman"' > .forward+mailman-owner
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman request mailman"' > .forward+mailman-request
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman subscribe mailman"' > .forward+mailman-subscribe
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman unsubscribe mailman"' > .forward+mailman-unsubscribe

Die vielen Befehle können von dieser Anleitung kopiert und nach Anpassung auf den tatsächlichen Unsernamen in die SSH-Sitzung kopiert werden. Noch leichter ist es, mit einem Editor einen Shell-Skript namens ~/bin/addforwards mit folgendem Inhalt zu erstellen:

#!/bin/sh
# .forward-Dateien für einen Verteiler unter Mailman einrichten.
#
if [ "$1" = "" ] ; then
echo "Aufruf: $0 Listenname\n"
exit
fi
if [ "$2" != "" ] ; then
echo "Aufruf: $0 Listenname\n"
exit
fi
if [ "`pwd`" != "`echo ~`" ] ; then
echo "Diesen Befehl vom Home-Verzeichnis aus aufrufen.\n"
exit
fi
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman post $1\"" > .forward+$1
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman admin $1\"" > .forward+$1-admin
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman bounces $1\"" > .forward+$1-bounces
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman confirm $1\"" > .forward+$1-confirm
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman join $1\"" > .forward+$1-join
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman leave $1\"" > .forward+$1-leave
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman owner $1\"" > .forward+$1-owner
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman request $1\"" > .forward+$1-request
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman subscribe $1\"" > .forward+$1-subscribe
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman unsubscribe $1\"" > .forward+$1-unsubscribe
exit

Der Skript muß natürlich als ausführbar gekennzeichnet werden:

~$ chmod u+x bin/addforwards

Die Erweiterung dieses Skripts um die hsscript-Befehle wird dem Leser als Aufgabe überlassen.

=== Administration ===

Als erstes sollte man als Administrator der neuen Mailman-Installation die Liste "mailman" selbst abonnieren. Die Liste "mailman" kann aber unter https://listen.example.com/mailman/admin/mailman verwaltet werden.

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:

~$ mailman/bin/newlist <Listenname>

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.

Für die Verwaltung der Mailinglisten im Alltag, d.h. den Umgang mit Bounces, Spam, Abonnenten usw., siehe u.a. die [https://wiki.list.org/ Mailman-Wiki].

== Feintuning ==

Wer will, kann auch noch etwas Platz sparen. Die normale Mailmaninstallation schlägt mit über 20 MB zu Buche...

Mit den folgenden Tips kann man das auf ca. 6 MB reduzieren :)

Es kann natürlich sein, dass ich zuviel lösche, aber bei mir funktioniert's. Wenn ihr also sicher(er) sein wollt, dass euch der Mailman nicht um die Ohren fliegt, macht das nicht!

* ~/mailman/cgi-bin und ~/mailman/icons können gelöscht werden, falls sie an andere Stelle kopiert worden sind.
* Die nicht benötigten Sprachen in ~/mailman/messages löschen.
* Die nicht benötigten Sprachen in ~/mailman/templates löschen (bis auf englisch).
* ~/mailman/tests kann, soweit ich das sehe, komplett gelöscht werden.
* Falls man koreanisch und japanisch nicht braucht, kann man folgendes machen:
* in ~/mailman/bin/paths.py, ~/mailman/cron/paths.py und ~/mailman/scripts/paths.py die Zeilen:

# In a normal interactive Python environment, the japanese.pth and korean.pth
# files would be imported automatically. But because we inhibit the importing
# of the site module, we need to be explicit about importing these codecs.
if not jaok:
import japanese
# As of KoreanCodecs 2.0.5, you had to do the second import to get the Korean
# codecs installed, however leave the first import in there in case an upgrade
# changes this.
if not kook:
import korean
import korean.aliases

auskommentieren.

Dann kann man ~/mailman/pythonlib/japanese, ~/mailman/pythonlib/korean, ~/mailman/pythonlib/korean.pth sowie ~/mailman/pythonlib/lib löschen.

Man kann auch noch die Debug-Informationen aus den binaries strippen:

strip ~/mailman/mail/mailman
strip ~/mailman/cgi-bin/*

Falls die CGIs nicht gesymlinkt wurden:

strip ~/doms/listen.example.com/cgi/mailman/*

== Multidomainfähigkeit ==

Seit Mailman 2.x kann eine Mailman-Installation unter gewissen Einschränkungen für mehrere Domains verwendet werden. Hier soll kurz gezeigt werden, was geht und wie es geht.

=== Anleitung ===

Logischerweise muss das Webfrontend (die CGIs) auf allen Domains installiert werden.

Wenn man nun Mailinglisten mit newlist neu anlegt, muss man den Hostnamen für das Webfontend mit angeben, und zwar so:

~$ mailman/bin/newlist listenname@listen.example.com

Es ist ggf. wichtig, dass in der mm_cfg.py eine entsprechende add_virtualhost-Direktive für www.example.com steht, die der Frontend-URL einen Host-Part für die Mailadressen zuordnet. Ist eine solche Direktive nicht vorhanden, so wird listen.example.com sowohl als URL für das Webfrontend wie auch als Hostpart für Emailadressen verwendet. (Was für separate aufgeschaltete Domains wie z.B. listen.example.com gerade zutrifft.)

Liegt das Frondend nicht auf der Maildomain ist es wichtig, dass ihr Mailman sagt, für welches die zugehörige Maildomain ist. Dies tut ihr in der Datei ~/mailman/Mailman/mm_cfg.py:

Also z.B.
DEFAULT_URL_HOST = 'www.example.com'
DEFAULT_EMAIL_HOST = 'listen.example.com'
add_virtualhost(DEFAULT_URL_HOST,DEFAULT_EMAIL_HOST)

und
add_virtualhost('www.zoopnet.de', 'lists.zoopnet.de')

Das bedeutet, dass Mailman per default davon ausgeht, dass alle Listen für die Domain example.com sind.
Alle weiteren add_virtualhost-Direktiven ordnen einem Hostnamen für das Webfrontend (z.B. www.zoopnet.de) einen Hostpart für die Adresse der Mailinglisten (z.B. lists.zoopnet.de) zu.

Tip von Raimund Specht: Lässt man den zweiten Parameter weg, also schreibt z.B. add_virtualhost('www.example.org'), dann benutzt Mailman als Hostpart alles was nach dem ersten Punkt steht, hier also example.org als Maildomain.

Prinzipiell war's das. Man muss die Listeneinträge natürlich immer in die richtige virtusertable eintragen, und für gleichnamige Mailinglisten auf verschiedenen Domains (mailman@*) verschidene +Ergänzungen bzw. aliase verwenden. :)

=== Probleme ===

Verschiedene Listen mit gleichem Namen (also z.B. liste@example1.com und liste@example2.com) sind mit Mailman 2.1 leider nicht möglich.

== Tips und Tricks ==

=== URL Änderungen ===
Nach URL Änderungen stimmen Links im Web-Interface nicht mehr und Listen werden nicht mehr angezeigt.
Es sind dann, zusätzlich zur Anpassung der mm_cfg.py, schon bestehende Listen und Archive mit folgendem Befehl zu aktualisieren:
~/mailman/bin/withlist -l -r fix_url <Listen_Name> -v -u <Neue_Url>
<Listen_Name> steht für die Mailingliste, die bearbeitet werden soll. <Neue_Url> für die neue URL/Webadresse des Webinterfaces.

=== Weitere Cron-Jobs zur Mailinglisten Verwaltung ===

Folgende Cronjobs helfen bei der Verwaltung und sind User freundlich:

< In Arbeit >

== Referenzen ==

Lösung zur installation als Domainadmin (xyz00-listen) statt Paketadmin (xyz00): https://lists.hostsharing.net/archiv/support/2009-June/019414.html 

Ältere Anleitung für Installation als Domain-Admin (xyz00-listen): <http://lists.hostsharing.net/archiv/support/2005-January/012426.html> 

"Kleine Tools" auf http://hs.andreasloesch.de/, wobei das 'pac-mm-install' wahrscheinlich nicht aktuell (genug) ist 

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

Greylisting

2019-12-08T16:40:07Z

Ara00-wp:

Greylisting ist eine Methode, von Spambots eingelieferte E-Mail abzuweisen. Dabei macht sich die Methode das Verhalten primitiver Spambots zunutze, E-Mail einfach bei einem Mailserver einzuliefern, aber sich dann nicht mehr um dessen Antworten zu kümmern. Dadurch unterscheiden sich Spambots von richtigen Mailservern.

Bei Greylisting wird die erste E-Mail eines Absenders immer zurückgewiesen und der sendende Mailserver aufgefordert, nach einer Zeitspanne noch mal zu senden. Wenn die E-Mail ein zweites Mal eingeliefert wird, nimmt das System die E-Mail an und speichert gleichzeitig den Absender in einer Datenbank. E-Mails von dieser Quelle werden dann zukünftig ohne Verzögerung weiter verarbeitet.

Weiter Einzelheiten findet man im Artikel der [[wikipedia:de:Greylisting|Wikipedia über Greylisting]].

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

Nameserver

2019-12-08T16:35:48Z

Ara00-wp: aktuelles

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:

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

Jede Nutzung eines Dienstes (z.B. E-Mail, 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.

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.

===Bug===
Manchmal regiert im Domainbestellsystem '''fuzzy logic''' und Einträge für secondary Domainserver werden nicht gleich angenommen. Es brauch schon mal einen vierten Versuch, aber dann klappts.

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

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

Nameserver

2019-12-08T16:33:04Z

Ara00-wp:

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:

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

Jede Nutzung eines Dienstes (z.B. E-Mail, 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.

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.

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

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

Mlmmj

2019-12-08T16:32:06Z

Ara00-wp: /* mlmmj */

== Mailing List Management Made Joyful ==

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

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

Alternative: [[Mailman]]

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

== mlmmj ==

=== Voraussetzungen ===

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

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

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

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

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

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

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

=== Einrichtung ===

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

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

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

Dann lege ich die Mailingliste mit folgendem Kommando an:

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

Das Skript fragt weitere Parameter der Mailingliste ab:

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

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

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

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

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

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

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

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

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

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

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

=== weitere Konfiguration ===

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

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

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

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

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

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

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

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

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

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

=== Konfiguration im Browser ===

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

Wer es sich ansehen möchte:

Als Paket-Admin eine Domain aufschalten:

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

Und weiter als "xyz00-list".

Download von http://mlmmj.org/releases/mlmmj-1.2.18.0.tar.gz auspacken.

Unter "/mlmmj-1.2.18.0/contrib/web/php-admin/" finden Sie im Paket die PHP-Admin-Anwendung.

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

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

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

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

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

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

Mlmmj

2019-12-08T16:30:38Z

Ara00-wp: /* Voraussetzungen */

== Mailing List Management Made Joyful ==

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

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

Alternative: [[Mailman]]

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

== mlmmj ==

=== Voraussetzungen ===

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

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

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

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

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

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

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

=== Einrichtung ===

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

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

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

Dann lege ich die Mailingliste mit folgendem Kommando an:

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

Das Skript fragt weitere Parameter der Mailingliste ab:

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

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

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

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

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

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

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

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

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

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

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

=== weitere Konfiguration ===

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

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

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

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

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

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

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

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

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

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

=== Konfiguration im Browser ===

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

Wer es sich ansehen möchte:

Als Paket-Admin eine Domain aufschalten:

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

Und weiter als "xyz00-list".

Download von http://mlmmj.org/releases/mlmmj-1.2.18.0.tar.gz auspacken.

Unter "/mlmmj-1.2.18.0/contrib/web/php-admin/" finden Sie im Paket die PHP-Admin-Anwendung.

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

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

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

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

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

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

Mlmmj

2019-12-08T16:30:05Z

Ara00-wp: /* Mailing List Management Made Joyful */

== Mailing List Management Made Joyful ==

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

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

Alternative: [[Mailman]]

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

== mlmmj ==

=== Voraussetzungen ===

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

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

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

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

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

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

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

=== Einrichtung ===

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

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

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

Dann lege ich die Mailingliste mit folgendem Kommando an:

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

Das Skript fragt weitere Parameter der Mailingliste ab:

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

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

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

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

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

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

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

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

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

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

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

=== weitere Konfiguration ===

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

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

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

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

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

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

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

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

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

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

=== Konfiguration im Browser ===

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

Wer es sich ansehen möchte:

Als Paket-Admin eine Domain aufschalten:

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

Und weiter als "xyz00-list".

Download von http://mlmmj.org/releases/mlmmj-1.2.18.0.tar.gz auspacken.

Unter "/mlmmj-1.2.18.0/contrib/web/php-admin/" finden Sie im Paket die PHP-Admin-Anwendung.

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

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

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

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

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

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

TLS mit Let's Encrypt Zertifikat

2019-11-23T17:03:32Z

Ara00-wp: /* Let's Encrypt bei Hostsharing */

"Let's Encrypt" ("Lasst uns verschlüsseln") ist eine Zertifizierungsstelle für X.509 TLS-Zertifikate. Über eine standardisierte Programmierschnittstelle lassen sich bei Let's Encrypt sogenannte Domain-validierte Zertifikate automatisiert
ausstellen und verlängern. Weitere Informationen zu Let's Encrypt finden sich in der [https://de.wikipedia.org/wiki/Let%E2%80%99s_Encrypt Wikipedia (dt.)]

== Let's Encrypt bei Hostsharing ==

Nutzer der Hostsharing-Plattform können TLS mit einem TLS-Zertifikat von Let's Encrypt ohne weiteres Zutun nutzen:

Beim Einrichten einer neuen Domain auf der Hostsharing-Plattform wird automatisch ein TLS Zertifikat erzeugt, das für die Hauptdomain und für die www-Subdomain zu dieser Hauptdomain gültig ist, also zum Beispiel für "beispiel.de" und "www.beispiel.de". Dazu muss der Domain-Inhaber nichts weiter tun.

Wir eine Domain neu eingerichtet, kann es einige Stunden dauern, bevor gültige Zertifikate aufgeschaltet sind und die Browser keine Sicherheitswarnungen mehr zeigen.

=== Weitere Subdomains ===

Viele Hostsharing-Nutzer kennen [[leichtgewichtige Subdomain|leichtgewichtige Subdomains]], die sich nur durch das Anlegen eines weiteren Verzeichnisses im Domain-Verzeichnis ~/doms/example.com/subs/ nutzen lassen. Dieses Feature ist mit Let's Encrypt-Zertifikaten
nicht möglich, denn die Zertifizierungsstelle stellt keine sogenannten Wildcard-Zertifikate aus. Im Zertifikat muss deshalb jede Subdomain explizit angegeben sein und nur [[Aufschaltung|aufgeschaltete Subdomains]] können mit einem solchen Zertifikat abgesichert werden.

Aus diesem Grund ist in unserer Administrations-Anwendung [[HSAdmin]] ein Feld "valid subdomain names" eingeführt worden.
Hier wird eine Liste aller Subdomains angegeben, die für diese Domain genutzt werden sollen (in diesem Apache VHost).
Die Angabe erfolgt als Komma-separierte Liste der Form "www,blog,aktion", wenn neben der Haupdomain "beispiel.de" die Subdomains "www.beispiel.de", "blog.beispiel.de" und "aktion.beispiel.de" gültig sein sollen.

==== Keine Wildcard Zertifikate mit Let's Encrypt möglich ====

Im Feld "valid subdomain names" kann auch "*" für beliebige Subdomains eingegeben werden. Damit erreichen erfahrene
Hostsharing-Nutzer das alte Verhalten leichtgewichtiger Subdomains durch das Anlegen eines Unterverzeichnisses. Dies
ist jedoch nicht in Kombination mit Zertifikaten von Let's Encrypt möglich. Die Domain-Option "letsencrypt" muss dann deaktiviert
werden. Für HTTP mit TLS-Verschlüsselung muss dann ein kostenpflichtiges Wildcard-Zertifikat einer anderen Zertifizierungsstelle
installiert werden. Dabei unterstützt der [[HS-Service|Hostsharing Service]].

=== Migration vorhandener Domains ===

Domains, die zum Zeitpunkt der Umstellung bereits bei Hostsharing eingerichtet sind, werden wie folgt behandelt:
Im Feld "valid subdomain names" ist der Stern "*" eingetragen, damit das bekannte Verhalten für leichtgewichtige Subdomains
erhalten bleibt. Demzufolge ist die Domain-Option "letsencrypt" deaktiviert.

Wenn für eine solche Domain Let's Encrypt-Zertifikate von Hostsharing automatisch ausgestellt werden sollen, sind
mit den Rechten des Paket-Administrators (also zum Beispiel dem User "xyz00") an der Domain zwei Änderungen vorzunehmen:

1. Im Feld "valid subdomain names" müssen alle genutzten Subdomains explizit angegeben werden. Die Liste kann auch leer sein.

2. Die Domain-Option "letsencrypt" wird aktiviert.

In der Regel steht nach wenigen Minuten ein Let's Encrypt-Zertifikat für die Domain zur Verfügung.

=== Berechtigungsprüfung vor Erstellung von Zertifikaten ===

Hostsharing nutzt zum Beantragen von Let's-Encrypt-Zertifikaten das [https://letsencrypt.org/how-it-works/ Validierungsverfahren über HTTP].
Um vorab sicherzustellen, dass der Zertifikatsantrag berechtigt ist, prüft Hostsharing unter anderem, ob die Domain die DNS-Server von Hostsharing nutzt.
Bevor die Let's-Encrypt-Option in HSAdmin aktiviert wird, sollte man - gerade bei erst kürzlich zu Hostsharing umgezogenen Domains - sicherstellen, dass der lokale DNS-Cache auf den Hostsharing-Servern die aktuellen DNS-Informationen vorhält.

Per SSH in das entsprechende Paket eingeloggt, sollte der Befehl (hier am Beispiel der Domain example.com)
<pre>
dig @localhost example.com NS
</pre>

Die Hostsharing-DNS-Server als Ausgabe liefern:
<pre>
;; ANSWER SECTION:
example.com. 3063 IN NS dns1.hostsharing.net.
example.com. 3063 IN NS dns2.hostsharing.net.
example.com. 3063 IN NS dns3.hostsharing.net.
</pre>
=== Monitoring von TLS-Zertifikaten ===

TLS-Zertifikate von Let's Encrypt gelten jeweils nur für 90 Tage. Nach Ablauf von 60 Tagen sollten die Zertifikate
erneuert werden. Dieser Prozess ist automatisiert.

Damit Probleme bei der Erneuerung von Zertifikaten nicht unbemerkt bleiben, haben wir ein Monitoring der
Zertifikat-Restlaufzeiten eingerichtet. Im Falle von automatisch erstellten Let's Encrypt-Zertifikaten kümmern
sich die Hostmaster um Problemfälle. Sie informieren das Mitglied, wenn der Paket- oder Domain-Administrator das
Problem durch eine Konfiguration verursacht hat.

Das Monitoring ist gleichzeitig eine neue Funktion für alle Zertifikate, die Mitglieder uns zur Installation bereitgestellt haben:
Der Paket-Administrator wird ca. 3 Wochen vor Ablauf eines Zertifikates informiert. Dazu bitte ggf. ein E-Mail Alias für
den Paket-User (Beispiel: "xyz00") einrichten, damit die E-Mail mit der Warnung den richtigen Adressaten erreicht.

[[Kategorie:HSDoku]]
[[Kategorie:WWW]]
[[Kategorie:Let’s Encrypt]]
[[Kategorie:Https]]