Hostsharing Wiki - Benutzerbeiträge [de]

Ecartis Installieren

2014-04-27T19:05:34Z

Sie00:

{{Textkasten|rot|Achtung:|Ecartis ist der aktuellen Debian Version nicht mehr enthalten und auch das Original-Projekt scheint nicht mehr zu existieren. Eine Neuinstallation von Ecartis ist daher nicht mehr zu empfehlen.}}

{{Textkasten|rot|Achtung 2:|Nach der Wheezy-Umstellung (4/2014) fehlen Ecartis die Module aus /usr/lib/ecartis/modules/. Lösung: Private Kopie in der lokalen Ecartis-Instalation ablegen, und den Pfad in ecartis.cfg eintragen. Quelle: http://sie00.hostsharing.net/ecartis-modules.tgz Der Druck wächst, auf ein anderes Tool umzusteigen.}}

== Mailinglisten mit ecartis ==

[http://www.ecartis.org/ Ecartis] ist ein Programm, mit dem Bei Hostsharing EMail-Verteiler realisiert werden können.

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

Alternative: [[Mailman]], [[mlmmj]]

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

== ecartis ==

=== Einrichten ===

Zunächst muss eine eigene Installation der Ecartis-Software in das Hostsharing-Paket kopiert werden.

Rufe dazu als Paket-Admin auf:

cp -rL /usr/lib/ecartis $HOME
mkdir $HOME/ecartis/queue

Und um fremde Blicke auf die E-Mail-Adressen der Teilnehmer/innen zu verhindern:

chmod -R o-rwx $HOME/ecartis

Im Verzeichnis ''ecartis'' befindet sich die Konfigurationsdatei ecartis.cfg, welche den Listenmanager steuert.

=== Konfiguration ===

==== ecartis.cfg ====

Für den Listenmanager müssen nun in ecartis.cfg mehrere Variablen angepasst werden.
Eine detailierte Beschreibung der einzelnen Optionen gibt es unter: http://www.ecartis.org/variables.html].

Hier die notwendigen Einstellungen in ecartis.cfg:

listserver-address = ecartis@example.com
listserver-admin = postmaster@example.com
listserver-root = /home/pacs/xyz00/ecartis
listserver-conf = /home/pacs/xyz00/ecartis
listserver-data = /home/pacs/xyz00/ecartis
listserver-modules = /home/pacs/xyz00/ecartis/modules

==== E-Mail Adresse ====

Im Folgenden benutze ich den Paket-User ''xyz00'' als Empfänger für alle E-Mails, die an Ecartis gehen. Die Verteilung erfolgt in der Datei ''.procmailrc''.

Zunächst stelle ich sicher, dass für den Paket-User kein EMail-Alias eingerichtet ist, bzw. ich lösche es:

hsadmin --call:emailalias.search
hsadmin --call:emailalias.delete --where:name=xyz00

Dann richte ich die Adresse des Mailinglisten-Managers selbst ein:

hsadmin --call:emailaddress.add --set:target=xyz00 --set:localpart=ecartis --set:domain=example.com

In der Datei ''$HOME/.procmailrc'' trage ich ein (siehe auch [[Procmail]]):

:0
* ^X-Original-To: ecartis@example.com
|$HOME/ecartis/ecartis

=== Test ===

Damit ist das Mailinglistensystem erreichbar und eine E-Mail an ecartis@example.com mit dem Inhalt help schickt uns die Datei ecartis.hlp zurück, die man später natürlich an seine Bedürfnisse anpassen kann.

Einrichten einer Mailingliste

== Mailinglisten ==

=== Einrichten ===

Man fügt nun den einzelnen Listenmanagern Listen hinzu. Dazu wechselt man in das Verzeichnis des jeweiligen Listenmanagers.

Aufruf:

cd $HOME/ecartis
./ecartis -newlist NAMEDERLISTE

Dann wird man nach dem Administrator der einzurichtenden Liste gefragt und nach der Eingabe der E-Mail-Adresse erhält man eine Liste von Aliases.

Folgendes gibt uns der Befehl zurück:

Aliases for 'testmailingliste' mailing list.
testmailingliste: "|/home/pacs/xyz00/mailinglist/ecartis -s testmailingliste"
testmailingliste-request: "|/home/pacs/xyz00/mailinglist/ecartis -r testmailingliste"
testmailingliste-repost: "|/home/pacs/xyz00/mailinglist/ecartis -a testmailingliste"
testmailingliste-admins: "|/home/pacs/xyz00/mailinglist/ecartis -admins testmailingliste"
testmailingliste-moderators: "|/home/pacs/xyz00/mailinglist/ecartis -moderators testmailingliste"
testmailingliste-bounce: "|/home/pacs/xyz00/mailinglist/ecartis -bounce testmailingliste"

Diese Aliases setze ich nicht in dieser Form um, sondern nutze den ''recipient_delimiter'' von Postfix und die ''.procmailrc'':

==== Aliases ersetzen ====

Durch den Aufruf von ''ecartis -newlist'' wurde eine Konfigurationsdatei für die neue Mailingliste angelegt.
Die Datei heißt ''$HOME/ecartis/lists/testmailingliste/config''.

Hier ändere ich zunächst die folgenden Einträge:

reply-to = testmailingliste@example.com
administrivia-address = testmailingliste+admins@example.com
moderator = testmailingliste+moderators@example.com
send-as = testmailingliste+bounce@example.com

Bitte das "+"-Plus-Zeichen im Localpart der EMail-Adressen beachten!

Mit hsadmin lege ich eine EMail-Adresse an:

hsadmin --call:emailaddress.add --set:localpart=testmailingliste --set:domain=example.com --set:target=xyz00

Statt der Aliases mache die folgenden Einträge in die ''.procmailrc'':

:0
* ^X-Original-To: testmailingliste@example.com
|$HOME/ecartis/ecartis -s testmailingliste
:0
* ^X-Original-To: testmailingliste\+request@example.com
|$HOME/ecartis/ecartis -r testmailingliste
:0
* ^X-Original-To: testmailingliste\+repost@example.com
|$HOME/ecartis/ecartis -a testmailingliste
:0
* ^X-Original-To: testmailingliste\+admins@example.com
|$HOME/ecartis/ecartis -admins testmailingliste
:0
* ^X-Original-To: testmailingliste\+moderators@example.com
|$HOME/ecartis/ecartis -moderators testmailingliste
:0
* ^X-Original-To: testmailingliste\+bounce@example.com
|$HOME/ecartis/ecartis -bounce testmailingliste

Jetzt gibt es eine offene Liste mit der Adresse testmailingliste@example.com, an der man sich mit einer E-Mail an testmailingliste+request@example.com mit dem Inhalt subscribe anmelden kann.

Konfigurieren einer Mailingliste

Jeder Listenmanager besitzt ein Unterverzeichnis /lists, in welchem die zugehörigen Listen verwaltet werden. Jeder Mailingliste wird ein Verzeichnis unterhalb dieses Verzeichnisses zugeordnet. Es hat den Namen der Mailingliste. Die Konfigurationsdatei für die einzelnen Listen heißt config und ist dort abgelegt. Eine detaillierte Beschreibung der einzelnen Optionen gibt es unter: [http://www.ecartis.org/variables.html].

=== Konfiguration ===

Hier nur die wichtigsten Einstellungen, die man konfigurieren sollte:

* list-owner = der Eigentümer der Liste
* subject-tag = eine Zeichenfolge die im Betreff vorangestellt wird (wie [global] bei unserer global(at)hostsharing.net Mailingliste)
* description = eine Beschreibung der Liste
* reply-to = Adresse der Liste (in unserem Beispiel: testmailingliste@example.com)
* administrivia-address = in unserem Beispiel testmailingliste+admins@example.com
* humanize-mime = false
* humanize-quotedprintable = true

Sorgen gemeinsam für eine ordentliche Handhabung von Umlauten, sie werden verstanden und es werden passende Header generiert.

* mbox-archive-path = wenn man möchte, kann man alle Mails, die über die Liste verschickt werden, archivieren
* subscribe-mode = hier gibt es 3 mögliche Einstellungen:
*# open - Der Benutzer meldet sich per subscribe an und wird direkt in die Liste eingetragen
*# confirm - Der Benutzer muss die Anmeldung anhand einer zugeschickten Mail bestätigen
*# closed - Die Anmeldung muss vom Listenadmin erlaubt werden
* unsubscribe-mode = hier gibt es 3 mögliche Einstellungen:
*# open - Der Benutzer meldet sich per unsubscribe ab und wird direkt aus der Liste ausgetragen
*# confirm - Der Benutzer muss die Abmeldung anhand einer zugeschickten Mail bestätigen
*# closed - Die Abmeldung muss vom Listenadmin erlaubt werden

=== Unterschiedliche Mailinglistentypen ===

==== offene Liste ====

Offene Liste bedeutet, dass jeder an die Liste schreiben kann, die dann an alle eingetragenen E-Mail-Adressen verteilt wird (Beispiel: global(at)hostsharing.net).
Dies ist der Standard bei der Einrichtung einer Liste und benötigt keine besonderen Einstellungen

==== geschlossene Liste ====

bedeutet, dass nur E-Mails von den Eingetragenen verteilt werden. Diese Listenart wird auch als member-only bezeichnet (Beispiel: members(at)hostsharing.net).

Hierfür müssen folgende Optionen gesetzt werden:

closed-post = true

Sinnvoll ist außerdem confirm oder closed bei subscribe-mode und unsubscribe-mode einzutragen.

==== moderierte Liste ====

bedeutet, dass E-Mails von jemandem authorisiert werden müssen, bevor sie verteilt werden. Wird in den meisten Fällen für Newsletter o.ä. verwendet, wo man als Betreiber den Eingetragenen E-Mails schicken will, aber eine Kommunikation der Eingetragenen untereinander nicht gewollt ist (Beispiel: global-announce(at)hostsharing.net).

Hierfür müssen folgende Optionen gesetzt werden:

moderated = yes
moderate-include-queue = true
moderator = testmailingliste+moderators@example.com

Sinnvoll ist außerdem confirm oder closed bei subscribe-mode und unsubscribe-mode einzutragen.

=== Autorisierung ===
Für die Authorisierung gibt es mehrere Möglichkeiten:

admin-approvepost = true

Damit werden alle E-Mails der Listenadministratoren direkt verschickt. Es wird nur überprüft, ob die Absender-E-Mail-Adresse übereinstimmt, da diese aber sehr leicht gefälscht werden kann, ist es nur ein sehr schwacher Schutz.

post-password = geheimesPasswort

Das setzt das Passwort für diese Liste auf geheimesPasswort und nur E-Mails mit der folgenden Zeile im Header der E-Mail werden verteilt: X-posting-pass: geheimesPasswort

Wenn man keine der beiden Optionen benutzt, dann wird die E-Mail zuerst an den Administrator der Liste geschickt, der sie bestätigen muss.

== Weitere Möglichkeiten ==

=== Verschiedene Domains ===

Wenn man für verschiedene seiner Domains eigenständige Mailinglistensysteme betreiben will, so kann man das Verzeichnis ''ecartis'' als Vorlage verwenden und beliebig kopieren. Dann sind natürlich die EMail-Adresse und die Einträge in der ''.procmailrc'' zur Steuerung des Listenmanagers per E-Mail ebenfalls zu kopieren und entsprechend anzupassen.

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

TLS / SSL

2013-12-29T20:19:48Z

Sie00:

Hostsharing besitzt ein SSL-Zertifikat, das von den Mitgliedern für https:// Zugriffe genutzt werden kann (Voreinstellung). Wenn es außerhalb der Paketdomain verwendet wird muss dieses Zertifikat im Browser jedoch explizit akzeptiert werden, da es für die Domain *.hostsharing.net ausgestellt ist. Der Browser meldet dann, dass das Zertifikat nicht zur aufgerufenen Domain passt.

== Standardkonfiguration ==

Neu aufgeschaltete Domains haben standardmäßig für die Verzeichnisse htdocs, subs, cgi und fastcgi getrennte *-ssl Ordner. Damit sind SSL-Inhalte sauber und sicher von Nicht-SSL Inhalten getrennt.

Bei Domains, die schon vor der Einführung des SSL Features bestanden, sind die Verzeichnisse subs-ssl, cgi-ssl und fastcgi-ssl standardmäßig als symbolische Links auf die entsprechenden nicht-ssl Verzeichnisse angelegt worden. Diese Symlinks stellen die Kompatibilität mit der früheren SSL Option her. Damals gab es nur einen Ordner für http und https.

Wer SSL und Nicht-SSL nun sauber trennen möchte oder ganz andere Inhalte anbieten möchte kann die Symlinks löschen und durch Verzeichnisse ersetzen. Bei der Paketdomain ist dabei zu beachten, dass die Rechte neu angelegter Verzeichnisse noch anzupassen sind, wenn die SSL Verzeichnisse nicht für alle User zugänglich sein sollen.

Wer hingegen SSL und Nicht-SSL Seiten innerhalb eines Verzeichnisbaums verwalten möchte, kann umgekehrt die SSL Verzeichnisse löschen und (ggf. auch nur selektiv für einige Unterverzeichnisse) Symlinks auf die Nicht-SSL Verzeichnisse anlegen.

Die Symlinks erlauben es die Seiten sowohl mit als auch ohne SSL abzurufen. Konfigurations- bzw. Administrationsseiten z.B. lassen sich dadurch sehr einfach manuell auch per https:// erreichen.

Möchte man den Zugriff auf bestimmte Seiten nur mit SSL erlauben und automatisch auf SSL umschalten, muss dies noch durch entsprechende [[.htaccess]] Dateien für die betroffenen Verzeichnisse konfiguriert werden.

== Eigene SSL Zertifikate ==

Möchte man, dass eine eigene Domain ohne Fehlermeldungen per SSL erreichbar ist, benötigt man ein eigenes Zertifikat von einer Zertifizierungsstelle, die von den Browsern standardmäßig anerkannt wird.

Zudem benötigt man eine eigene IP-Nummer, da dies die Voraussetzung zur Nutzung von ssl-Verschlüsselung ist. Deshalb ist auch nur ein Zertifikat pro Paket möglich.

Zunächst muss man als Paket-Admin einen Private Key erzeugen und dann einen CSR (Certificate Signing Request - mit dem Private Key erzeugte Anforderung für ein Zertifikat). Wie das genau funktioniert, ist meistens von Seiten der Zertifizierungsstelle beschrieben.

Man kann aber auch ein kleines Skript nutzen, das Michael Hierweck aufgrund von einer Anleitung von Michaels Hönnig zur Erzeugung von Zertifikaten geschrieben hat:

<pre><nowiki>
#! /bin/sh

#Nur Zugriffe für den Owner erlauben
umask u=rwx,g=,o=

#Zertifikat erzeugen
openssl req -new -x509 -keyout ~/etc/cakey.pem -out ~/etc/careq.pem $*
openssl rsa <~/etc/cakey.pem >~/etc/https.new
cat ~/etc/careq.pem >>~/etc/https.new

#Temporäre Dateien löschen
rm ~/etc/cakey.pem
rm ~/etc/careq.pem

#Altes Zertifikat sichern
cp ~/etc/https.pem ~/etc/https.old
</nowiki></pre>

Es können weitere Parameter angeben werden, z.B. -days 370.

Die Domain oder Wildcard (*.domain.TLD) für die das Zertifikat gilt, wird auf die Frage als Common Name angegeben.

Anschließend wird der Zertifizierungsstelle der csr übermittelt. Die Datei, die man dann von der Zertifizierungsstelle erhält, muss in das Verzeichnis /etc des Paketadmins kopiert werden. Das neue Zertifikat muss dann noch manuell aktiviert werden, d.h. in https.pem umbenannt werden. Damit kann man dies zu einem beliebigen späteren Zeitpunkt tun und das Zertifikat vorher prüfen.

''' Per Auftrag an service@ muss um Aktivierung des neuen Zertifikats gebeten werden. '''

== Kostenlose SSL-Zertifikate von StartSSL ==

Heise hat unter der URL
http://www.heise.de/security/artikel/Die-Praxis-881280.html
den Vorgang dokumentiert, wie man ein Zertifikat erhält,
das von StartSSL ausgestellt wurde und somit im Browser auch keine Warnmeldung verursacht.

Mit den Zeilen

<pre><nowiki>
$> openssl genrsa -out example.com.key 2048
$> openssl req -new -key example.com.key -out example.com.csr
...
</nowiki></pre>

erstellt man sich ein Certificate Signing Request (CSR).

Wenn man dann auf https://www.startssl.com/ die "Express Lane" benutzt (privates Zertifikat erzeugen, im Browser installieren, einloggen, Zertifikat anfragen -> "Skip" beim erzeugen -> CSR in Formular kopieren) bekommt man am Ende zwei Dateien:

<pre><nowiki>
sub.class1.server.ca.pem
ca.pem
</nowiki></pre>

sowie das Zertifikat zum Kopieren/Einfügen in eine Datei ssl.crt.

Dieses Zertifikat und der private Schlüssel müssen in einer Datei zusammengefasst werden;
gleichzeitig sollte der Erfolg der Aktion mit openssl überprüft werden:

<pre><nowiki>
$> cat example.com.key ssl.crt > ~/etc/https.pem
$> openssl s_server -cert https.pem -www
Using default temp DH parameters
Using default temp ECDH parameters
ACCEPT
^C
$>
</nowiki></pre>

Außerdem muss die Datei '''sub.class1.server.ca.pem''' per SFTP nach ~/etc/ hochgeladen werden.

''' Per Auftrag an service@ muss um Aktivierung des neuen Zertifikats https.pem, sowie des Zwischenzertifikats sub.class1.server.ca.pem gebeten werden. '''

Hier kann man das Zertifikat nach der Aktivierung testen:

<pre>
http://www.digicert.com/help/
</pre>

----
[[Kategorie:HSDoku]]
[[Kategorie:WWW]]
[[Kategorie:Glossar]]
[[Kategorie:ToDo-Kerndoku]]

TLS / SSL

2013-12-29T17:49:26Z

Sie00:

Hostsharing besitzt ein SSL-Zertifikat, das von den Mitgliedern für https:// Zugriffe genutzt werden kann (Voreinstellung). Wenn es außerhalb der Paketdomain verwendet wird muss dieses Zertifikat im Browser jedoch explizit akzeptiert werden, da es für die Domain *.hostsharing.net ausgestellt ist. Der Browser meldet dann, dass das Zertifikat nicht zur aufgerufenen Domain passt.

== Standardkonfiguration ==

Neu aufgeschaltete Domains haben standardmäßig für die Verzeichnisse htdocs, subs, cgi und fastcgi getrennte *-ssl Ordner. Damit sind SSL-Inhalte sauber und sicher von Nicht-SSL Inhalten getrennt.

Bei Domains, die schon vor der Einführung des SSL Features bestanden, sind die Verzeichnisse subs-ssl, cgi-ssl und fastcgi-ssl standardmäßig als symbolische Links auf die entsprechenden nicht-ssl Verzeichnisse angelegt worden. Diese Symlinks stellen die Kompatibilität mit der früheren SSL Option her. Damals gab es nur einen Ordner für http und https.

Wer SSL und Nicht-SSL nun sauber trennen möchte oder ganz andere Inhalte anbieten möchte kann die Symlinks löschen und durch Verzeichnisse ersetzen. Bei der Paketdomain ist dabei zu beachten, dass die Rechte neu angelegter Verzeichnisse noch anzupassen sind, wenn die SSL Verzeichnisse nicht für alle User zugänglich sein sollen.

Wer hingegen SSL und Nicht-SSL Seiten innerhalb eines Verzeichnisbaums verwalten möchte, kann umgekehrt die SSL Verzeichnisse löschen und (ggf. auch nur selektiv für einige Unterverzeichnisse) Symlinks auf die Nicht-SSL Verzeichnisse anlegen.

Die Symlinks erlauben es die Seiten sowohl mit als auch ohne SSL abzurufen. Konfigurations- bzw. Administrationsseiten z.B. lassen sich dadurch sehr einfach manuell auch per https:// erreichen.

Möchte man den Zugriff auf bestimmte Seiten nur mit SSL erlauben und automatisch auf SSL umschalten, muss dies noch durch entsprechende [[.htaccess]] Dateien für die betroffenen Verzeichnisse konfiguriert werden.

== Eigene SSL Zertifikate ==

Möchte man, dass eine eigene Domain ohne Fehlermeldungen per SSL erreichbar ist, benötigt man ein eigenes Zertifikat von einer Zertifizierungsstelle, die von den Browsern standardmäßig anerkannt wird.

Zudem benötigt man eine eigene IP-Nummer, da dies die Voraussetzung zur Nutzung von ssl-Verschlüsselung ist. Deshalb ist auch nur ein Zertifikat pro Paket möglich.

Zunächst muss man als Paket-Admin einen Private Key erzeugen und dann einen CSR (Certificate Signing Request - mit dem Private Key erzeugte Anforderung für ein Zertifikat). Wie das genau funktioniert, ist meistens von Seiten der Zertifizierungsstelle beschrieben.

Man kann aber auch ein kleines Skript nutzen, das Michael Hierweck aufgrund von einer Anleitung von Michaels Hönnig zur Erzeugung von Zertifikaten geschrieben hat:

<pre><nowiki>
#! /bin/sh

#Nur Zugriffe für den Owner erlauben
umask u=rwx,g=,o=

#Zertifikat erzeugen
openssl req -new -x509 -keyout ~/etc/cakey.pem -out ~/etc/careq.pem $*
openssl rsa <~/etc/cakey.pem >~/etc/https.new
cat ~/etc/careq.pem >>~/etc/https.new

#Temporäre Dateien löschen
rm ~/etc/cakey.pem
rm ~/etc/careq.pem

#Altes Zertifikat sichern
cp ~/etc/https.pem ~/etc/https.old
</nowiki></pre>

Es können weitere Parameter angeben werden, z.B. -days 370.

Die Domain oder Wildcard (*.domain.TLD) für die das Zertifikat gilt, wird auf die Frage als Common Name angegeben.

Anschließend wird der Zertifizierungsstelle der csr übermittelt. Die Datei, die man dann von der Zertifizierungsstelle erhält, muss in das Verzeichnis /etc des Paketadmins kopiert werden. Das neue Zertifikat muss dann noch manuell aktiviert werden, d.h. in https.pem umbenannt werden. Damit kann man dies zu einem beliebigen späteren Zeitpunkt tun und das Zertifikat vorher prüfen.

''' Per Auftrag an service@ muss um Aktivierung des neuen Zertifikats gebeten werden. '''

== Kostenlose SSL-Zertifikate von StartSSL ==

Heise hat unter der URL
http://www.heise.de/security/artikel/Die-Praxis-881280.html
den Vorgang dokumentiert, wie man ein Zertifikat erhält,
das von StartSSL ausgestellt wurde und somit im Browser auch keine Warnmeldung verursacht.

Mit den Zeilen

<pre><nowiki>
$> openssl genrsa -out example.com.key 2048
$> openssl req -new -key example.com.key -out example.com.csr
...
</nowiki></pre>

erstellt man sich ein Certificate Signing Request (CSR).

Wenn man dann auf https://www.startssl.com/ die "Express Lane" benutzt (privates Zertifikat erzeugen, im Browser installieren, einloggen, Zertifikat anfragen -> "Skip" beim erzeugen -> CSR in Formular kopieren) bekommt man am Ende zwei Dateien:

<pre><nowiki>
sub.class1.server.ca.pem
ca.pem
</nowiki></pre>

sowie das Zertifikat zum Kopieren/Einfügen in eine Datei ssl.crt.

Dieses Zertifikat und der private Schlüssel müssen in einer Datei zusammengefasst werden;
gleichzeitig sollte der Erfolg der Aktion mit openssl überprüft werden:

<pre><nowiki>
$> cat example.com.key ssl.crt > ~/etc/https.pem
$> openssl s_server -cert https.pem -www
Using default temp DH parameters
Using default temp ECDH parameters
ACCEPT
^C
$>
</nowiki></pre>

''' Per Auftrag an service@ muss um Aktivierung des neuen Zertifikats gebeten werden. '''

Hier kann man das Zertifikat testen:

<pre>
http://www.digicert.com/help/
</pre>

----
[[Kategorie:HSDoku]]
[[Kategorie:WWW]]
[[Kategorie:Glossar]]
[[Kategorie:ToDo-Kerndoku]]

TLS / SSL

2013-12-29T17:48:31Z

Sie00:

Hostsharing besitzt ein SSL-Zertifikat, das von den Mitgliedern für https:// Zugriffe genutzt werden kann (Voreinstellung). Wenn es außerhalb der Paketdomain verwendet wird muss dieses Zertifikat im Browser jedoch explizit akzeptiert werden, da es für die Domain *.hostsharing.net ausgestellt ist. Der Browser meldet dann, dass das Zertifikat nicht zur aufgerufenen Domain passt.

== Standardkonfiguration ==

Neu aufgeschaltete Domains haben standardmäßig für die Verzeichnisse htdocs, subs, cgi und fastcgi getrennte *-ssl Ordner. Damit sind SSL-Inhalte sauber und sicher von Nicht-SSL Inhalten getrennt.

Bei Domains, die schon vor der Einführung des SSL Features bestanden, sind die Verzeichnisse subs-ssl, cgi-ssl und fastcgi-ssl standardmäßig als symbolische Links auf die entsprechenden nicht-ssl Verzeichnisse angelegt worden. Diese Symlinks stellen die Kompatibilität mit der früheren SSL Option her. Damals gab es nur einen Ordner für http und https.

Wer SSL und Nicht-SSL nun sauber trennen möchte oder ganz andere Inhalte anbieten möchte kann die Symlinks löschen und durch Verzeichnisse ersetzen. Bei der Paketdomain ist dabei zu beachten, dass die Rechte neu angelegter Verzeichnisse noch anzupassen sind, wenn die SSL Verzeichnisse nicht für alle User zugänglich sein sollen.

Wer hingegen SSL und Nicht-SSL Seiten innerhalb eines Verzeichnisbaums verwalten möchte, kann umgekehrt die SSL Verzeichnisse löschen und (ggf. auch nur selektiv für einige Unterverzeichnisse) Symlinks auf die Nicht-SSL Verzeichnisse anlegen.

Die Symlinks erlauben es die Seiten sowohl mit als auch ohne SSL abzurufen. Konfigurations- bzw. Administrationsseiten z.B. lassen sich dadurch sehr einfach manuell auch per https:// erreichen.

Möchte man den Zugriff auf bestimmte Seiten nur mit SSL erlauben und automatisch auf SSL umschalten, muss dies noch durch entsprechende [[.htaccess]] Dateien für die betroffenen Verzeichnisse konfiguriert werden.

== Eigene SSL Zertifikate ==

Möchte man, dass eine eigene Domain ohne Fehlermeldungen per SSL erreichbar ist, benötigt man ein eigenes Zertifikat von einer Zertifizierungsstelle, die von den Browsern standardmäßig anerkannt wird.

Zudem benötigt man eine eigene IP-Nummer, da dies die Voraussetzung zur Nutzung von ssl-Verschlüsselung ist. Deshalb ist auch nur ein Zertifikat pro Paket möglich.

Zunächst muss man als Paket-Admin einen Private Key erzeugen und dann einen CSR (Certificate Signing Request - mit dem Private Key erzeugte Anforderung für ein Zertifikat). Wie das genau funktioniert, ist meistens von Seiten der Zertifizierungsstelle beschrieben.

Man kann aber auch ein kleines Skript nutzen, das Michael Hierweck aufgrund von einer Anleitung von Michaels Hönnig zur Erzeugung von Zertifikaten geschrieben hat:

<pre><nowiki>
#! /bin/sh

#Nur Zugriffe für den Owner erlauben
umask u=rwx,g=,o=

#Zertifikat erzeugen
openssl req -new -x509 -keyout ~/etc/cakey.pem -out ~/etc/careq.pem $*
openssl rsa <~/etc/cakey.pem >~/etc/https.new
cat ~/etc/careq.pem >>~/etc/https.new

#Temporäre Dateien löschen
rm ~/etc/cakey.pem
rm ~/etc/careq.pem

#Altes Zertifikat sichern
cp ~/etc/https.pem ~/etc/https.old
</nowiki></pre>

Es können weitere Parameter angeben werden, z.B. -days 370.

Die Domain oder Wildcard (*.domain.TLD) für die das Zertifikat gilt, wird auf die Frage als Common Name angegeben.

Anschließend wird der Zertifizierungsstelle der csr übermittelt. Die Datei, die man dann von der Zertifizierungsstelle erhält, muss in das Verzeichnis /etc des Paketadmins kopiert werden. Das neue Zertifikat muss dann noch manuell aktiviert werden, d.h. in https.pem umbenannt werden. Damit kann man dies zu einem beliebigen späteren Zeitpunkt tun und das Zertifikat vorher prüfen.

''' Per Auftrag an service@ muss um Aktivierung des neuen Zertifikats gebeten werden. '''

== Kostenlose SSL-Zertifikate von StartSSL ==

Heise hat unter der URL
http://www.heise.de/security/artikel/Die-Praxis-881280.html
den Vorgang dokumentiert, wie man ein Zertifikat erhält,
das von StartSSL ausgestellt wurde und somit im Browser auch keine Warnmeldung verursacht.

Mit den Zeilen

<pre><nowiki>
$> openssl genrsa -out example.com.key 2048
$> openssl req -new -key example.com.key -out example.com.csr
...
</nowiki></pre>

erstellt man sich ein Certificate Signing Request (CSR).

Wenn man dann auf https://www.startssl.com/ die "Express Lane" benutzt (privates Zertifikat erzeugen, im Browser installieren, einloggen, Zertifikat anfragen -> "Skip" beim erzeugen -> CSR in Formular kopieren) bekommt man am Ende zwei Dateien:

<pre><nowiki>
sub.class1.server.ca.pem
ca.pem
</nowiki></pre>

sowie das Zertifikat zum Kopieren/Einfügen in eine Datei ssl.crt.

Dieses Zertifikat und der private Schlüssel müssen in einer Datei zusammengefasst werden;
gleichzeitig sollte der Erfolg der Aktion mit openssl überprüft werden:

<pre><nowiki>
$> cat example.com.key ssl.crt > ~/etc/https.pem
$> openssl s_server -cert https.pem -www
Using default temp DH parameters
Using default temp ECDH parameters
ACCEPT
^C
$>
</nowiki></pre>

''' Per Auftrag an service@ muss um Aktivierung des neuen Zertifikats gebeten werden. '''

Hier kann man das Zertifikat testen:

<pre><nowiki>
http://www.digicert.com/help/
</nowiki></pre>

----
[[Kategorie:HSDoku]]
[[Kategorie:WWW]]
[[Kategorie:Glossar]]
[[Kategorie:ToDo-Kerndoku]]

TLS / SSL

2013-12-28T17:42:43Z

Sie00: Anleitng zur Nutzung eines Gratis-Zertifikats von StartSSL.com

Hostsharing besitzt ein SSL-Zertifikat, das von den Mitgliedern für https:// Zugriffe genutzt werden kann (Voreinstellung). Wenn es außerhalb der Paketdomain verwendet wird muss dieses Zertifikat im Browser jedoch explizit akzeptiert werden, da es für die Domain *.hostsharing.net ausgestellt ist. Der Browser meldet dann, dass das Zertifikat nicht zur aufgerufenen Domain passt.

== Standardkonfiguration ==

Neu aufgeschaltete Domains haben standardmäßig für die Verzeichnisse htdocs, subs, cgi und fastcgi getrennte *-ssl Ordner. Damit sind SSL-Inhalte sauber und sicher von Nicht-SSL Inhalten getrennt.

Bei Domains, die schon vor der Einführung des SSL Features bestanden, sind die Verzeichnisse subs-ssl, cgi-ssl und fastcgi-ssl standardmäßig als symbolische Links auf die entsprechenden nicht-ssl Verzeichnisse angelegt worden. Diese Symlinks stellen die Kompatibilität mit der früheren SSL Option her. Damals gab es nur einen Ordner für http und https.

Wer SSL und Nicht-SSL nun sauber trennen möchte oder ganz andere Inhalte anbieten möchte kann die Symlinks löschen und durch Verzeichnisse ersetzen. Bei der Paketdomain ist dabei zu beachten, dass die Rechte neu angelegter Verzeichnisse noch anzupassen sind, wenn die SSL Verzeichnisse nicht für alle User zugänglich sein sollen.

Wer hingegen SSL und Nicht-SSL Seiten innerhalb eines Verzeichnisbaums verwalten möchte, kann umgekehrt die SSL Verzeichnisse löschen und (ggf. auch nur selektiv für einige Unterverzeichnisse) Symlinks auf die Nicht-SSL Verzeichnisse anlegen.

Die Symlinks erlauben es die Seiten sowohl mit als auch ohne SSL abzurufen. Konfigurations- bzw. Administrationsseiten z.B. lassen sich dadurch sehr einfach manuell auch per https:// erreichen.

Möchte man den Zugriff auf bestimmte Seiten nur mit SSL erlauben und automatisch auf SSL umschalten, muss dies noch durch entsprechende [[.htaccess]] Dateien für die betroffenen Verzeichnisse konfiguriert werden.

== Eigene SSL Zertifikate ==

Möchte man, dass eine eigene Domain ohne Fehlermeldungen per SSL erreichbar ist, benötigt man ein eigenes Zertifikat von einer Zertifizierungsstelle, die von den Browsern standardmäßig anerkannt wird.

Zudem benötigt man eine eigene IP-Nummer, da dies die Voraussetzung zur Nutzung von ssl-Verschlüsselung ist. Deshalb ist auch nur ein Zertifikat pro Paket möglich.

Zunächst muss man als Paket-Admin einen Private Key erzeugen und dann einen CSR (Certificate Signing Request - mit dem Private Key erzeugte Anforderung für ein Zertifikat). Wie das genau funktioniert, ist meistens von Seiten der Zertifizierungsstelle beschrieben.

Man kann aber auch ein kleines Skript nutzen, das Michael Hierweck aufgrund von einer Anleitung von Michaels Hönnig zur Erzeugung von Zertifikaten geschrieben hat:

<pre><nowiki>
#! /bin/sh

#Nur Zugriffe für den Owner erlauben
umask u=rwx,g=,o=

#Zertifikat erzeugen
openssl req -new -x509 -keyout ~/etc/cakey.pem -out ~/etc/careq.pem $*
openssl rsa <~/etc/cakey.pem >~/etc/https.new
cat ~/etc/careq.pem >>~/etc/https.new

#Temporäre Dateien löschen
rm ~/etc/cakey.pem
rm ~/etc/careq.pem

#Altes Zertifikat sichern
cp ~/etc/https.pem ~/etc/https.old
</nowiki></pre>

Es können weitere Parameter angeben werden, z.B. -days 370.

Die Domain oder Wildcard (*.domain.TLD) für die das Zertifikat gilt, wird auf die Frage als Common Name angegeben.

Anschließend wird der Zertifizierungsstelle der csr übermittelt. Die Datei, die man dann von der Zertifizierungsstelle erhält, muss in das Verzeichnis /etc des Paketadmins kopiert werden. Das neue Zertifikat muss dann noch manuell aktiviert werden, d.h. in https.pem umbenannt werden. Damit kann man dies zu einem beliebigen späteren Zeitpunkt tun und das Zertifikat vorher prüfen.

''' Per Auftrag an service@ muss um Aktivierung des neuen Zertifikats gebeten werden. '''

== Kostenlose SSL-Zertifikate von StartSSL ==

Heise hat unter der URL
http://www.heise.de/security/artikel/Die-Praxis-881280.html
den Vorgang dokumentiert, wie man ein Zertifikat erhält,
das von StartSSL ausgestellt wurde und somit im Browser auch keine Warnmeldung verursacht.

Mit den Zeilen

<pre><nowiki>
$> openssl genrsa -out example.com.key 2048
$> openssl req -new -key example.com.key -out example.com.csr
...
</nowiki></pre>

erstellt man sich ein Certificate Signing Request (CSR).

Wenn man dann auf https://www.startssl.com/ die "Express Lane" benutzt (privates Zertifikat erzeugen, im Browser installieren, einloggen, Zertifikat anfragen -> "Skip" beim erzeugen -> CSR in Formular kopieren) bekommt man am Ende zwei Dateien:

<pre><nowiki>
sub.class1.server.ca.pem
ca.pem
</nowiki></pre>

sowie das Zertifikat zum Kopieren/Einfügen in eine Datei ssl.crt.

Dieses Zertifikat und der private Schlüssel müssen in einer Datei zusammengefasst werden;
gleichzeitig sollte der Erfolg der Aktion mit openssl überprüft werden:

<pre><nowiki>
$> cat example.com.key ssl.crt > ~/etc/https.pem
$> openssl s_server -cert https.pem -www
Using default temp DH parameters
Using default temp ECDH parameters
ACCEPT
^C
$>
</nowiki></pre>

''' Per Auftrag an service@ muss um Aktivierung des neuen Zertifikats gebeten werden. '''

----
[[Kategorie:HSDoku]]
[[Kategorie:WWW]]
[[Kategorie:Glossar]]
[[Kategorie:ToDo-Kerndoku]]

Django installieren

2012-04-14T22:17:10Z

Sie00: "djangoprojekt/" fehlte im django.fcgi script

===Installation Djangobibliothek===
Die Djangobibliotheken werden in einer Virtualenv-Umgebung installiert. Vorraussetzung ist ein auf dem System installiertes python mit einem virtualenv-Paket
Zunächst wird die Virtualenvumgebung erstellt:
<pre>
xyz00-doms:~$ virtualenv djangoenv
New python executable in djangoenv/bin/python
Installing setuptools............done.
</pre>
Dann werden die Django-Bibliotheken in die eben erstellte Virtualenvumgebung installiert.
<pre>
xyz-doms:~$ djangoenv/bin/easy_install django
Searching for django
Reading http://pypi.python.org/simple/django/
Reading http://www.djangoproject.com/
Best match: Django 1.3
.
.
.
Finished processing dependencies for django
</pre>
Testen, ob Django installiert ist:
<pre>
xyz-doms:~$ djangoenv/bin/python
Python 2.6.6 (r266:84292, Dec 27 2010, 00:02:40)
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import django
>>>
</pre>

===Django-Projekt===
Dann wird das Django Projekt im Bereich einer Domain abgelegt.
<pre>
xyz-doms:~$ cd ~/doms/example.com/
xyz-doms:~$ /path_to_djangoenv/djangoenv/bin/django-admin.py startproject djangoprojekt
</pre>
Jetzt kann man unter Verwendung des Pythons der Virtualenv testen, ob Django läuft.
<pre>
xyz00: /path_to_djangoenv/djangoenv/bin/python manage.py runserver
Validating models...

0 errors found
Django version 1.3, using settings 'mysite.settings'
Development server is running at http://127.0.0.1:8000/
Quit the server with CONTROL-C.
</pre>
... und die ''settings.py'' an die Hostsharing-Pfade angepasst.

===Nutzung mit FastCGI===
Zunächst richtet man den FastCGI-Skript (django.fcgi) ein und legt es im fastcgi-Verzeichnis ab und macht es ausführbar:

<pre>
#!/path_to_djangoenv/djangoenv/bin/python

import os, sys
os.chdir("/path_to_doms/doms/example.com/djangoprojekt/")
os.environ['DJANGO_SETTINGS_MODULE']= "djangoprojekt.settings"
sys.path.insert(0, "/path_to_doms/doms/example.com/djangoprojekt/")
from django.core.servers.fastcgi import runfastcgi
runfastcgi(method="threaded", daemonize="false")
</pre>

Das Djangoprojekt sollte jetzt unter example.com/fastcgi-bin/django.fcgi erreichbar sein.

===Nutzung mit WSGI via flup===
Zunächst richtet man den FastCGI-Skript (django.fcgi) ein und legt es im fastcgi-Verzeichnis ab und macht es ausführbar:

<pre>
#!/path_to_djangoenv/djangoenv/bin/python

import os, sys
os.chdir("/path_to_doms/doms/example.com/django")
os.environ['DJANGO_SETTINGS_MODULE']= "djangoprojekt.settings"
sys.path.insert(0, "/path_to_doms/doms/example.com/django")
sys.path.insert(0, "/path_to_doms/doms/example.com/django/djangoprojekt")

from flup.server.fcgi import WSGIServer
from django.core.handlers.wsgi import WSGIHandler
WSGIServer(WSGIHandler()).run()
</pre>

Das Djangoprojekt sollte jetzt unter example.com/fastcgi-bin/django.fcgi erreichbar sein.
Tipp: Manchmal werden Änderungen in den Quellen, insbesondere der settings.py nicht übernommen. Dann hilft es den Zeitstempel der Datei django.fcgi mit touch zu aktualisieren.

===Apache Weiterleitung===
Nun wird das Djangoprojekt unter www.example.com verfügbar gemacht.
Hierfür wird eine .htaccess im entsprechenden Domainverzeichnis angelegt:

<pre>
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ /fastcgi-bin/django.fcgi/$1 [QSA,L]
</pre>

Nun sollte die Seite unter (www.)example.com erreichbar sein.

[[Kategorie:Installationsanleitungen]]