Hostsharing Wiki - Benutzerbeiträge [de]

Observatory by Mozilla

2018-10-19T09:33:12Z

Hsh00-peh: Schlagworte XSS und CSP im text

== Sicherheits-Scan mit Rating ==

[https://observatory.mozilla.org/ Das Observatory von Mozilla] scannt Websites und analysiert die Implementierung von wichtigen Sicherheits-Features für das HTTP-Protokoll. Insbesondere geht es um zusätzliche HTTP-Header, die bei der Vermeidung von XSS-Angriffen und anderen helfen. Eine Content Security Policy (CSP) sorgt dafür, dass keine bösartigen Inhalte von dritter Seite nachgeladen werden. Auf der Ergebnisseite werden Webmaster darüber informiert, wie ihre Website abgeschnitten hat. Neben einem Rating von A bis F (analog der US-amerikanischen Schulnoten) erfährt man auf der Ergebnisseite, wie man die Sicherheit der eigenen Website verbessern kann.

Mozilla hat die Sicherheitshinweise in ausführlichen [https://infosec.mozilla.org/guidelines/web_security.html Guidelines] zusammengefasst.

== Snippet für A+ Rating ==

Die Header zur Verbesserung der Sicherheit können in der Apache-Konfiguration gesetzt werden. Zum Beispiel in der Datei [[.htaccess]]

Mit der folgenden Konfiguration erzielt die Homepage von Hostsharing beim Rating ein A+:

Header set Content-Security-Policy "default-src 'none'; font-src 'self'; img-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; base-uri 'self'; form-action 'self'; frame-ancestors 'none'"
Header set X-Content-Type-Options "nosniff"
Header set X-Frame-Options "DENY"
Header set X-XSS-Protection "1; mode=block"

== Meta-Tag Snippet für A+ Rating ==

Die Header können teilweise auch im HTML-Code der Website gesetzt werden.

Mit diesen Meta-Tags im Header erzielt man ebenfalls ein A+-Rating:

<meta http-equiv="Content-Security-Policy" content="default-src 'none'; object-src 'none'; font-src 'self'; img-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; base-uri 'self'; form-action 'self'; frame-ancestors 'none'">
<meta http-equiv="X-XSS-Protection" content="1; mode=block">
<meta http-equiv="X-Content-Type-Options" content="nosniff">
<meta http-equiv="X-Frame-Options" content="DENY">
<meta http-equiv="Referrer-Policy" content="no-referrer, strict-origin-when-cross-origin">

Wagtail installieren

2018-10-02T11:07:44Z

Hsh00-peh:

{{Textkasten|gelb|bitte nicht als Paketuser|Dieser Artikel beschreibt kurz und knapp die Installation eine Python-basieren CMS auf der Hostsharing-Plattform. Allerdings sind unsere Best-practices nicht berücksichtigt.

Bitte nicht die Paket-Domain verwenden. Sie wird abgekündigt und künftig für interne Zwecke genutzt.

Bitte keine Anwendungen als Paket-User betreiben: Für jede Anwendung erst einen eigenen User anlegen und für den User eine Domain aufschalten.}}

Am Beispiel der Domain xyz00.hostsharing.net des Users xyz00.
Die Installation in diesem Beispiel wird mit dem Paketadmin xyz00 durchgeführt

xyz00 ist durch das tatsächliche Paketkürzel zu ersetzen.

Installation einer eigenen Pythonumgebung und Installation von wagtail:
<pre>
mkdir wagtail
cd wagtail/
virtualenv -p python3 virtualenv
virtualenv/bin/pip install wagtail
</pre>

Anlegen des Projekts "mysite":
<pre>
virtualenv/bin/wagtail start mysite
</pre>

Zusätzlich sind individuelle Settings in der Anwendungskonfiguration
(z.B. production.py) zu hinterlegen, z.B. die zu verwendende Datenbank.

Aufruf von migrate und collectstatic, um die Datenbank zu initialisieren und die statischen Dateien bereitzustellen:
<pre>
cd mysite
../virtualenv/bin/python3 ./manage.py migrate
../virtualenv/bin/python3 ./manage.py collectstatic
</pre>

Anlegen eines symbolischen Links zur Auslieferung der statischen Inhalte:
<pre>
cd ~/doms/xyz00.hostsharing.net/htdocs-ssl
ln -s /home/pacs/xyz00/wagtail/mysite/static static
</pre>

In dem Ordner /home/doms/xyz00.hostsharing.net/ eine .htaccess mit folgendem Inhalt anlegen:
<pre>
PassengerPython /home/pacs/xyz00/wagtail/virtualenv/bin/python3
SetEnv DJANGO_SETTINGS_MODULE mysite.settings.production
SetEnv PYTHONPATH /home/pacs/xyz00/wagtail/mysite/
</pre>

Unter dem Ordner app-ssl die Datei passenger_wsgi.py anlegen und mit folgendem Inhalt
füllen, um Passenger mit der Anwendung zu verdrahten:
<pre>
from mysite.wsgi import application
</pre>

Unter dem Ordner ein Verzeichnis "tmp" anlegen und eine leere Datei "restart.txt" anlgen.
Ein "touch" startet die Applikation neu:

<pre>
mkdir app-ssl/tmp
touch app-ssl/tmp/restart.txt
</pre>

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]

Wagtail installieren

2018-10-02T11:07:00Z

Hsh00-peh: Best practices

{{Textkasten|gelb|bitte nicht als Paketuser|Dieser Artikel beschreibt gut die Installation eine Python-basieren CMS auf der Hostsharing-Plattform. Allerdings sind unsere Best-practices nicht berücksichtigt.

Bitte nicht die Paket-Domain verwenden. Sie wird abgekündigt und künftig für interne Zwecke genutzt.

Bitte keine Anwendungen als Paket-User betreiben: Für jede Anwendung erst einen eigenen User anlegen und für den User eine Domain aufschalten.}}

Am Beispiel der Domain xyz00.hostsharing.net des Users xyz00.
Die Installation in diesem Beispiel wird mit dem Paketadmin xyz00 durchgeführt

xyz00 ist durch das tatsächliche Paketkürzel zu ersetzen.

Installation einer eigenen Pythonumgebung und Installation von wagtail:
<pre>
mkdir wagtail
cd wagtail/
virtualenv -p python3 virtualenv
virtualenv/bin/pip install wagtail
</pre>

Anlegen des Projekts "mysite":
<pre>
virtualenv/bin/wagtail start mysite
</pre>

Zusätzlich sind individuelle Settings in der Anwendungskonfiguration
(z.B. production.py) zu hinterlegen, z.B. die zu verwendende Datenbank.

Aufruf von migrate und collectstatic, um die Datenbank zu initialisieren und die statischen Dateien bereitzustellen:
<pre>
cd mysite
../virtualenv/bin/python3 ./manage.py migrate
../virtualenv/bin/python3 ./manage.py collectstatic
</pre>

Anlegen eines symbolischen Links zur Auslieferung der statischen Inhalte:
<pre>
cd ~/doms/xyz00.hostsharing.net/htdocs-ssl
ln -s /home/pacs/xyz00/wagtail/mysite/static static
</pre>

In dem Ordner /home/doms/xyz00.hostsharing.net/ eine .htaccess mit folgendem Inhalt anlegen:
<pre>
PassengerPython /home/pacs/xyz00/wagtail/virtualenv/bin/python3
SetEnv DJANGO_SETTINGS_MODULE mysite.settings.production
SetEnv PYTHONPATH /home/pacs/xyz00/wagtail/mysite/
</pre>

Unter dem Ordner app-ssl die Datei passenger_wsgi.py anlegen und mit folgendem Inhalt
füllen, um Passenger mit der Anwendung zu verdrahten:
<pre>
from mysite.wsgi import application
</pre>

Unter dem Ordner ein Verzeichnis "tmp" anlegen und eine leere Datei "restart.txt" anlgen.
Ein "touch" startet die Applikation neu:

<pre>
mkdir app-ssl/tmp
touch app-ssl/tmp/restart.txt
</pre>

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]

Stretch

2018-06-28T14:41:40Z

Hsh00-peh: Python3

== Upgrade auf Debian Stretch ==

In ersten und zweinten Quartal führt das Hostsharing-Team die vorbereitenden Arbeiten für das Upgrade
der Hostsharing-Server auf Debian Stretch (Debian 9.x) durch.

Während der Vorbereitungen werden wir die Mitglieder und Nutzer.innen unserer Plattform
auf dieser Wiki-Seite über unsere Erfahrungen informieren.

Ende Juni wird auf dieser Seite dokumentiert sein, welche Änderungen durch das Upgrade
notwendig werden und welche Vorbereitungen die Nutzer.innen treffen sollten.

Das Upgrade der Webspaces und Managed Server wird im Juni 2018 beginnen.

Folgende Software ist insbesondere betroffen:

== MySQL wird ersetzt durch MariaDB ==

=== Ersatz durch MariaDB ===

Mit dem Upgrade wird der Datenbankserver Mysql durch den MariaDB Server in der Version 10.1 ersetzt. MariaDB ist in Zukunft die Standard-MySQL-Variante in Debian.

Es sind aus der Sicht von Applikationen keine Inkompatibilitäten zwischen MariaDB Server 10.1 und Mysql Server 5.5 bekannt.
Der Ersatz sollte damit keine Probleme bereiten.

=== Sehr alte MySQL Passworte ===

Bereits mit MySQL Version 4.1 wurde ein neues Hashverfahren für die Passworte der MySQL-User eingeführt. Schon seit längerer Zeit verwenden wir bei Hostsharing das neue Hashverfahren. Passworte der MySQL-User werden mit HSAdmin im "neuen" Hashverfahren gespeichert. Es kann jedoch sein, dass in alten Paketen noch MySQL-User mit einem alten 16-Bytes-Password existieren.

Mit dem Upgrade werden neuere MySQL-Client-Bibliothen verwendet, die teilweise das alte Passwort-Format nicht mehr unterstützen. Das kann insbesondere PHP-Anwendungen betreffen. Das Problem wird gelöst, indem das Passwort der MySQL-User mit HSAdmin neu definiert wird.

Unsere Empfehlung ist, das bekannte Passwort '''vor''' dem Upgrade neu zu setzen.

Für Freunde der Konsole mit hsscript:

<pre>
mysqluser.update({where:{name:'xyz00_example'},set:{password:'geheim'}})
</pre>
(Dokumentation zu hsscript: https://doc.hostsharing.net/users/administration/hsadmin/index.html )

oder im Webfrontend unter https://admin.hostsharing.net , unter der Paketkennung xyz00 und MySQL-User.

In seltenen Ausnahmefällen kann es vorkommen, dass mit sehr alten MySQL-Clients auf die Datenbanken zugegriffen werden soll und dass diese MySQL-Clients das aktuelle Passwort-Format nicht unterstützen. In diesem Fall kann die MySQL-Funktion "OLD_PASSWORD" benutzt werden, um ein Passwort im alten Format zu erzeugen. Siehe dazu: https://mariadb.com/kb/en/library/set-password/

== PHP Update auf Version 7.0 ==

Mit dem Upgrade wird die Version von PHP von 5.6 auf 7.0 angehoben. Ohne weitere Aktion werden die PHP-Anwendungen nach dem Upgrade mit PHP 7.0 laufen.

Um für die Anpassung der gehosteten PHP-Anwendungen eine Übergangszeit anzubieten,
werden wir es ermöglichen über eine Domain-Option PHP pro Domain wieder auf PHP 5.6
zurückzusetzen. Die Domain-Optionen erreicht man, wenn man sich als Paket-Administrator (5-stellige Userkennung der Form "xyz00") oder Hostsharing-Mitglied (3-stellige Userkennung der Form "xyz") in HSAdmin unter [https://admin.hostsharing.net] anmeldet. Dort wählt man links den Bereich der Web-Pakete aus und im Bereich das Paket, das die Domain enthält. Im rechten Bereich oben wählt man dann Domains und in der Tabelle die gewünschte Domain. Mit dem "edit"-Icon rechts oben kann dann der Dialog zum Ändern der Domain-Optionen aufgerufen werden.

PHP 5.6 wird maximal bis Ende 2018 zur Verfügung stehen. Danach endet die Unterstützung dieser Version durch die PHP-Entwickler.

== Update auf Java 8 ==

In Debian 9 ist Java 8 als Java-Virtuelle-Maschine enthalten. Die vorhandenen Java 7-Pakete aus Debian 8 werden mit dem Upgrade deinstalliert.

Nutzer von Java-Anwendugnen auf den Hostsharing-Servern sollten vor dem Upgrade ihre Anwendungen so umstellen, dass die Anwendungen mit dem bereits seit längerem installierten Java 8 aus den Debian Backports laufen.

Ähnlich verhält es sich mit dem Debian-seitig installierten Apache Tomcat: Tomcat in der Version 7 entfällt. Auf unseren Servern ist neben Tomcat 7 auch Tomcat 8 installiert. Bitte alle Webanwendungen, die den zentral installierten Tomcat nutzen auf die Tomcat 8-Installation umstellen. Tomcat 8 wird im Zuge des Upgrades auf Tomcat 8.5 angehoben.

== Python ==

Das alte Python 3.4 wird durch Python 3.5 ersetzt. Das bedeutet, dass jedes Python3-Virtualenv nach dem Update neu
angelegt werden muss.

== Perl==

Es scheint mit der neuen Perl Version nicht mehr standardmäßig das aktuelle Verzeichnis für Module ausgelesen zu werden.
Deshalb kann es ggf. notwendig sein in den Perl-Scripten ein

<pre>
use lib '.';
</pre>

einzufügen.

== Update des OpenSSH Servers ==
DSA-Keys sind standardmäßig deaktiviert und werden seitens Hostsharing aus Sicherheitsgründen nicht aktiviert.
DSA-Keys gelten als unsicher und sollten daher nicht verwendet werden.
Ein Login unter der Verwendung von DSA-Keys ist nach dem Upgrade auf Debian Stretch nicht mehr möglich.

Es sollte geprüft werden, ob DSA-Keys verwendet werden. Dies erkennt man z.B. daran, das am Anfang der Datei des öffentlichen Schlüssels "ssh-dsa" steht.

Werden noch DSA-Keys verwendet, muss zwingend ein neuer Schlüssel wie folgt erstellt werden:

'''Für Freunde der Kommandozeile unter Linux'''

Neuen Key erzeugen:
<pre>
ssh-keygen -t rsa -b 4096
</pre>
Kopieren des öffentlichen Schlüssels auf den Server:
<pre>
ssh-copy-id -i /home/ich/.ssh/id_rsa xyz00@xyz00.hostsharing.de
</pre>
oder als Domainadmin:
<pre>
ssh-copy-id -i /home/ich/.ssh/id_rsa xyz00-ich@xyz00.hostsharing.de
</pre>

'''Für Windows:'''

PuttyGen, das bei der Intallation von Putty in der Regel mit installiert wird:

https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html

erzeugt einen neuen Schlüssel.
Es sollte ein Schlüssel des Typs "SSH2-RSA" generiert werden.

----
[[Kategorie:Upgrade Jessie zu Stretch]]
[[Kategorie:Glossar]]

Stretch

2018-06-19T18:36:46Z

Hsh00-peh: /* PHP Update auf Version 7.0 */

== Upgrade auf Debian Stretch ==

In ersten und zweinten Quartal führt das Hostsharing-Team die vorbereitenden Arbeiten für das Upgrade
der Hostsharing-Server auf Debian Stretch (Debian 9.x) durch.

Während der Vorbereitungen werden wir die Mitglieder und Nutzer.innen unserer Plattform
auf dieser Wiki-Seite über unsere Erfahrungen informieren.

Ende Juni wird auf dieser Seite dokumentiert sein, welche Änderungen durch das Upgrade
notwendig werden und welche Vorbereitungen die Nutzer.innen treffen sollten.

Das Upgrade der Webspaces und Managed Server wird im Juni 2018 beginnen.

Folgende Software ist insbesondere betroffen:

== MySQL wird ersetzt durch MariaDB ==

=== Ersatz durch MariaDB ===

Mit dem Upgrade wird der Datenbankserver Mysql durch den MariaDB Server in der Version 10.1 ersetzt. MariaDB ist in Zukunft die Standard-MySQL-Variante in Debian.

Es sind aus der Sicht von Applikationen keine Inkompatibilitäten zwischen MariaDB Server 10.1 und Mysql Server 5.5 bekannt.
Der Ersatz sollte damit keine Probleme bereiten.

=== Sehr alte MySQL Passworte ===

Bereits mit MySQL Version 4.1 wurde ein neues Hashverfahren für die Passworte der MySQL-User eingeführt. Schon seit längerer Zeit verwenden wir bei Hostsharing das neue Hashverfahren. Passworte der MySQL-User werden mit HSAdmin im "neuen" Hashverfahren gespeichert. Es kann jedoch sein, dass in alten Paketen noch MySQL-User mit einem alten 16-Bytes-Password existieren.

Mit dem Upgrade werden neuere MySQL-Client-Bibliothen verwendet, die teilweise das alte Passwort-Format nicht mehr unterstützen. Das kann insbesondere PHP-Anwendungen betreffen. Das Problem wird gelöst, indem das Passwort der MySQL-User mit HSAdmin neu definiert wird.

In seltenen Ausnahmefällen kann es vorkommen, dass mit sehr alten MySQL-Clients auf die Datenbanken zugegriffen werden soll und dass diese MySQL-Clients das aktuelle Passwort-Format nicht unterstützen. In diesem Fall kann die MySQL-Funktion "OLD_PASSWORD" benutzt werden, um ein Passwort im alten Format zu erzeugen. Siehe dazu: https://mariadb.com/kb/en/library/set-password/

== PHP Update auf Version 7.0 ==

Mit dem Upgrade wird die Version von PHP von 5.6 auf 7.0 angehoben. Ohne weitere Aktion werden die PHP-Anwendungen nach dem Upgrade mit PHP 7.0 laufen.

Um für die Anpassung der gehosteten PHP-Anwendungen eine Übergangszeit anzubieten,
werden wir es ermöglichen über eine Domain-Option PHP pro Domain wieder auf PHP 5.6
zurückzusetzen. Die Domain-Optionen erreicht man, wenn man sich als Paket-Administrator (5-stellige Userkennung der Form "xyz00") oder Hostsharing-Mitglied (3-stellige Userkennung der Form "xyz") in HSAdmin unter [https://admin.hostsharing.net] anmeldet. Dort wählt man links den Bereich der Web-Pakete aus und im Bereich das Paket, das die Domain enthält. Im rechten Bereich oben wählt man dann Domains und in der Tabelle die gewünschte Domain. Mit dem "edit"-Icon rechts oben kann dann der Dialog zum Ändern der Domain-Optionen aufgerufen werden.

PHP 5.6 wird maximal bis Ende 2018 zur Verfügung stehen. Danach endet die Unterstützung dieser Version durch die PHP-Entwickler.

== Java Update auf Version 8.0 ==

In Debian 9 ist Java 8 als Java-Virtuelle-Maschine enthalten. Die vorhandenen Java 7-Pakete aus Debian 8 werden mit dem Upgrade deinstalliert.

Nutzer von Java-Anwendugnen auf den Hostsharing-Servern sollten vor dem Upgrade ihr Anwendungen so umstellen, dass die Anwendungen mit dem bereits seit längerem installierten Java 8 aus den Debian Backports laufen.

Ähnlich verhält es sich mit dem Debian-seitig installierten Apache Tomcat: Tomcat in der Version 7 entfällt. Auf unseren Servern ist neben Tomcat 7 auch Tomcat 8 installiert. Bitte alle Webanwendungen, die den zentral installierten Tomcat nutzen auf die Tomcat 8-Installation umstellen. Tomcat 8 wird im Zuge des Upgrades auf Tomcat 8.5 angehoben.

== Update des OpenSSH Servers ==
DSA-Keys sind standardmäßig deaktiviert und werden seitens Hostsharing aus Sicherheitsgründen nicht aktiviert.
DSA-Keys gelten als unsicher und sollten daher nicht verwendet werden.
Ein Login unter der Verwendung von DSA-Keys ist nach dem Upgrade auf Debian Stretch nicht mehr möglich.

Es sollte geprüft werden, ob DSA-Keys verwendet werden. Dies erkennt man z.B. daran, das am Anfang der Datei des öffentlichen Schlüssels "ssh-dsa" steht.

Werden noch DSA-Keys verwendet, muss zwingend ein neuer Schlüssel wie folgt erstellt werden:

'''Für Freunde der Kommandozeile unter Linux'''

Neuen Key erzeugen:
<pre>
ssh-keygen -t rsa -b 4096
</pre>
Kopieren des öffentlichen Schlüssels auf den Server:
<pre>
ssh-copy-id -i /home/ich/.ssh/id_rsa xyz00@xyz00.hostsharing.de
</pre>
oder als Domainadmin:
<pre>
ssh-copy-id -i /home/ich/.ssh/id_rsa xyz00-ich@xyz00.hostsharing.de
</pre>

'''Für Windows:'''

PuttyGen, das bei der Intallation von Putty in der Regel mit installiert wird:

https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html

erzeugt einen neuen Schlüssel.
Es sollte ein Schlüssel des Typs "SSH2-RSA" generiert werden.

----
[[Kategorie:Upgrade Jessie zu Stretch]]
[[Kategorie:Glossar]]

Stretch

2018-06-19T18:29:16Z

Hsh00-peh: /* Upgrade auf Debian Stretch */

Stretch

2018-06-14T12:25:22Z

Hsh00-peh: /* Java Update auf Version 8.0 */

== Upgrade auf Debian Stretch ==

In ersten Quartal führt das Hostsharing-Team die vorbereitenden Arbeiten für das Upgrade
der Hostsharing-Server auf Debian Stretch (Debian 9.x) durch.

Während der Vorbereitungen werden wir die Mitglieder und Nutzer.innen unserer Plattform
auf dieser Wiki-Seite über die Vorbereitungen informieren.

Ende März wird auf dieser Seite dokumentiert sein, welche Änderungen durch das Upgrade
notwendig werden und welche Vorbereitungen die Nutzer.innen treffen sollten.

Das Upgrade der Webspaces und Managed Server wird im April 2018 beginnen.

Folgende Software ist insbesondere betroffen:

== MySQL wird ersetzt durch MariaDB ==

=== Ersatz durch MariaDB ===

Mit dem Upgrade wird der Datenbankserver Mysql durch den MariaDB Server in der Version 10.1 ersetzt. MariaDB ist in Zukunft die Standard-MySQL-Variante in Debian.

Es sind aus der Sicht von Applikationen keine Inkompatibilitäten zwischen MariaDB Server 10.1 und Mysql Server 5.5 bekannt.
Der Ersatz sollte damit keine Probleme bereiten.

=== Sehr alte MySQL Passworte ===

Bereits mit MySQL Version 4.1 wurde ein neues Hashverfahren für die Passworte der MySQL-User eingeführt. Schon seit längerer Zeit verwenden wir bei Hostsharing das neue Hashverfahren. Passworte der MySQL-User werden mit HSAdmin im "neuen" Hashverfahren gespeichert. Es kann jedoch sein, dass in alten Paketen noch MySQL-User mit einem alten 16-Bytes-Password existieren.

Mit dem Upgrade werden neuere MySQL-Client-Bibliothen verwendet, die teilweise das alte Passwort-Format nicht mehr unterstützen. Das kann insbesondere PHP-Anwendungen betreffen. Das Problem wird gelöst, indem das Passwort der MySQL-User mit HSAdmin neu definiert wird.

In seltenen Ausnahmefällen kann es vorkommen, dass mit sehr alten MySQL-Clients auf die Datenbanken zugegriffen werden soll und dass diese MySQL-Clients das aktuelle Passwort-Format nicht unterstützen. In diesem Fall kann die MySQL-Funktion "OLD_PASSWORD" benutzt werden, um ein Passwort im alten Format zu erzeugen. Siehe dazu: https://mariadb.com/kb/en/library/set-password/

== PHP Update auf Version 7.0 ==

== Java Update auf Version 8.0 ==

In Debian 9 ist Java 8 als Java-Virtuelle-Maschine enthalten. Die vorhandenen Java 7-Pakete aus Debian 8 werden mit dem Upgrade deinstalliert.

Nutzer von Java-Anwendugnen auf den Hostsharing-Servern sollten vor dem Upgrade ihr Anwendungen so umstellen, dass die Anwendungen mit dem bereits seit längerem installierten Java 8 aus den Debian Backports laufen.

Ähnlich verhält es sich mit dem Debian-seitig installierten Apache Tomcat: Tomcat in der Version 7 entfällt. Auf unseren Servern ist neben Tomcat 7 auch Tomcat 8 installiert. Bitte alle Webanwendungen, die den zentral installierten Tomcat nutzen auf die Tomcat 8-Installation umstellen. Tomcat 8 wird im Zuge des Upgrades auf Tomcat 8.5 angehoben.

== Update des OpenSSH Servers ==
DSA-Keys sind standardmäßig deaktiviert und werden seitens Hostsharing aus Sicherheitsgründen nicht aktiviert.
DSA-Keys gelten als unsicher und sollten daher nicht verwendet werden.
Ein Login unter der Verwendung von DSA-Keys ist nach dem Upgrade auf Debian Stretch nicht mehr möglich.

Es sollte geprüft werden, ob DSA-Keys verwendet werden. Dies erkennt man z.B. daran, das am Anfang der Datei des öffentlichen Schlüssels "ssh-dsa" steht.

Werden noch DSA-Keys verwendet, muss zwingend ein neuer Schlüssel wie folgt erstellt werden:

'''Für Freunde der Kommandozeile unter Linux'''

Neuen Key erzeugen:
<pre>
ssh-keygen -t rsa -b 4096
</pre>
Kopieren des öffentlichen Schlüssels auf den Server:
<pre>
ssh-copy-id -i /home/ich/.ssh/id_rsa xyz00@xyz00.hostsharing.de
</pre>
oder als Domainadmin:
<pre>
ssh-copy-id -i /home/ich/.ssh/id_rsa xyz00-ich@xyz00.hostsharing.de
</pre>

'''Für Windows:'''

PuttyGen, das bei der Intallation von Putty in der Regel mit installiert wird:

https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html

erzeugt einen neuen Schlüssel.
Es sollte ein Schlüssel des Typs "SSH2-RSA" generiert werden.

----
[[Kategorie:Upgrade Jessie zu Stretch]]
[[Kategorie:Glossar]]

Stretch

2018-06-14T12:17:47Z

Hsh00-peh: MySQL OLD_PASSWORD Problematik

== Upgrade auf Debian Stretch ==

In ersten Quartal führt das Hostsharing-Team die vorbereitenden Arbeiten für das Upgrade
der Hostsharing-Server auf Debian Stretch (Debian 9.x) durch.

Während der Vorbereitungen werden wir die Mitglieder und Nutzer.innen unserer Plattform
auf dieser Wiki-Seite über die Vorbereitungen informieren.

Ende März wird auf dieser Seite dokumentiert sein, welche Änderungen durch das Upgrade
notwendig werden und welche Vorbereitungen die Nutzer.innen treffen sollten.

Das Upgrade der Webspaces und Managed Server wird im April 2018 beginnen.

Folgende Software ist insbesondere betroffen:

== MySQL wird ersetzt durch MariaDB ==

=== Ersatz durch MariaDB ===

Mit dem Upgrade wird der Datenbankserver Mysql durch den MariaDB Server in der Version 10.1 ersetzt. MariaDB ist in Zukunft die Standard-MySQL-Variante in Debian.

Es sind aus der Sicht von Applikationen keine Inkompatibilitäten zwischen MariaDB Server 10.1 und Mysql Server 5.5 bekannt.
Der Ersatz sollte damit keine Probleme bereiten.

=== Sehr alte MySQL Passworte ===

Bereits mit MySQL Version 4.1 wurde ein neues Hashverfahren für die Passworte der MySQL-User eingeführt. Schon seit längerer Zeit verwenden wir bei Hostsharing das neue Hashverfahren. Passworte der MySQL-User werden mit HSAdmin im "neuen" Hashverfahren gespeichert. Es kann jedoch sein, dass in alten Paketen noch MySQL-User mit einem alten 16-Bytes-Password existieren.

Mit dem Upgrade werden neuere MySQL-Client-Bibliothen verwendet, die teilweise das alte Passwort-Format nicht mehr unterstützen. Das kann insbesondere PHP-Anwendungen betreffen. Das Problem wird gelöst, indem das Passwort der MySQL-User mit HSAdmin neu definiert wird.

In seltenen Ausnahmefällen kann es vorkommen, dass mit sehr alten MySQL-Clients auf die Datenbanken zugegriffen werden soll und dass diese MySQL-Clients das aktuelle Passwort-Format nicht unterstützen. In diesem Fall kann die MySQL-Funktion "OLD_PASSWORD" benutzt werden, um ein Passwort im alten Format zu erzeugen. Siehe dazu: https://mariadb.com/kb/en/library/set-password/

== PHP Update auf Version 7.0 ==

== Java Update auf Version 8.0 ==

== Update des OpenSSH Servers ==
DSA-Keys sind standardmäßig deaktiviert und werden seitens Hostsharing aus Sicherheitsgründen nicht aktiviert.
DSA-Keys gelten als unsicher und sollten daher nicht verwendet werden.
Ein Login unter der Verwendung von DSA-Keys ist nach dem Upgrade auf Debian Stretch nicht mehr möglich.

Es sollte geprüft werden, ob DSA-Keys verwendet werden. Dies erkennt man z.B. daran, das am Anfang der Datei des öffentlichen Schlüssels "ssh-dsa" steht.

Werden noch DSA-Keys verwendet, muss zwingend ein neuer Schlüssel wie folgt erstellt werden:

'''Für Freunde der Kommandozeile unter Linux'''

Neuen Key erzeugen:
<pre>
ssh-keygen -t rsa -b 4096
</pre>
Kopieren des öffentlichen Schlüssels auf den Server:
<pre>
ssh-copy-id -i /home/ich/.ssh/id_rsa xyz00@xyz00.hostsharing.de
</pre>
oder als Domainadmin:
<pre>
ssh-copy-id -i /home/ich/.ssh/id_rsa xyz00-ich@xyz00.hostsharing.de
</pre>

'''Für Windows:'''

PuttyGen, das bei der Intallation von Putty in der Regel mit installiert wird:

https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html

erzeugt einen neuen Schlüssel.
Es sollte ein Schlüssel des Typs "SSH2-RSA" generiert werden.

----
[[Kategorie:Upgrade Jessie zu Stretch]]
[[Kategorie:Glossar]]

Gnusocial

2018-06-11T13:10:42Z

Hsh00-peh: typo, htaccess

= Gnusocial installieren =

== Vorbereitungen ==

In ''hsadmin'', zum Beispiel mit ''hsscript'':

''hsadmin''-Shell starten mit:

hsscript -u xyz00 -i
Password: ********

Dann nacheinander anlegen:

* Linux User als Domain-Administrator
* Subdomain ''social.example.org''
* MySQL-User
* MySQL Datenbank

xyz00@hsadmin> user.add({set:{name:'xyz00-social',password:'geheim',shell:'/bin/bash',comment:'GNU Social'}})
xyz00@hsadmin> domain.add({set:{name:'social.example.org',user:'xyz00-social'}})
xyz00@hsadmin> mysqluser.add({set:{name:'xyz00_social',password:'geheim'}})
xyz00@hsadmin> mysqldb.add({set:{name:'xyz00_social',owner:'xyz00_social'}})

== GNUSocial installieren ==

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

ssh -l xyz00-social xyz00.hostsharing.net

''htdocs-ssl'' Verzeichnis vorbereiten

cd doms/blog.example.org
rm -rf subs/www subs-ssl/www
cd doms/blog.example.org/htdocs-ssl
rm .htaccess

GNUSocial downloaden & entpacken z.b. im htdocs-ssl Verzeichnis

wget -O - https://git.gnu.io/gnu/gnu-social/-/archive/master/gnu-social-master.tar.gz |tar -xz --strip 1
mv htaccess.sample .htaccess

== GNUSocial konfigurieren ==

Im Browser auf die Seite
https://social.example.org/install.php gehen und den Anweisungen folgen.

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Blog]]
[[Kategorie:CMS]]

Gnusocial

2018-06-11T13:08:06Z

Hsh00-peh: GNUSocial installieren

= Gnusocial installieren =

== Vorbereitungen ==

In ''hsadmin'', zum Beispiel mit ''hsscript'':

''hsadmin''-Shell starten mit:

hsscript -u xyz00 -i
Password: ********

Dann nacheinander anlegen:

* Linux User als Domain-Administrator
* Subdomain ''social.example.org''
* MySQL-User
* MySQL Datenbank

xyz00@hsadmin> user.add({set:{name:'xyz00-social',password:'geheim',shell:'/bin/bash',comment:'GNU Social'}})
xyz00@hsadmin> domain.add({set:{name:'social.example.org',user:'xyz00-social'}})
xyz00@hsadmin> mysqluser.add({set:{name:'xyz00_social',password:'geheim'}})
xyz00@hsadmin> mysqldb.add({set:{name:'xyz00_social',owner:'xyz00_social'}})

== Wordpress installieren ==

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

ssh -l xyz00-social xyz00.hostsharing.net

''htdocs-ssl'' Verzeichnis vorbereiten

cd doms/blog.example.org
rm -rf subs/www subs-ssl/www
cd doms/blog.example.org/htdocs-ssl
rm .htaccess

GNUSocial downloaden & entpacken z.b. im htdocs-ssl Verzeichnis

wget -O - https://git.gnu.io/gnu/gnu-social/-/archive/master/gnu-social-master.tar.gz |tar -xz --strip 1

== GNUSocial konfigurieren ==

Im Browser auf die Seite
https://social.example.org/install.php gehen und den Anweisungen folgen.

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Blog]]
[[Kategorie:CMS]]

Wordpress

2018-06-11T13:04:34Z

Hsh00-peh: Änderungen für https als Default

= Wordpress in 5 Minuten =

== Vorbereitungen ==

In ''hsadmin'', zum Beispiel mit ''hsscript'':

''hsadmin''-Shell starten mit:

hsscript -u xyz00 -i
Password: ********

Dann nacheinander anlegen:

* Linux User als Domain-Administrator
* Subdomain ''blog.example.org''
* MySQL-User
* MySQL Datenbank

xyz00@hsadmin> user.add({set:{name:'xyz00-blog',password:'geheim',shell:'/bin/bash',comment:'Wordpress Blog'}})
xyz00@hsadmin> domain.add({set:{name:'blog.example.org',user:'xyz00-blog'}})
xyz00@hsadmin> mysqluser.add({set:{name:'xyz00_wpuser',password:'geheim'}})
xyz00@hsadmin> mysqldb.add({set:{name:'xyz00_wpdb',owner:'xyz00_wpuser'}})

== Wordpress installieren ==

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

ssh -l xyz00-blog xyz00.hostsharing.net

''htdocs'' Verzeichnis vorbereiten

cd doms/blog.example.org
rm -rf subs/www subs-ssl/www
cd doms/blog.example.org/htdocs-ssl
rm .htaccess

Wordpress downloaden & entpacken z.b. im htdocs-ssl Verzeichnis

wget -O - http://wordpress.org/latest.tar.gz |tar -xz --strip 1

== Wordpress konfigurieren ==

Im Browser auf die Seite
http://blog.example.org gehen und den Anweisungen folgen.

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Blog]]
[[Kategorie:CMS]]

Mastodon bei Hostsharing

2018-04-09T13:30:17Z

Hsh00-peh: /* Einrichten des Apache VHost */

{{Textkasten|rot|Baustelle|Diese Seite ist noch nicht fertig.}}

{{Textkasten|gelb|Für Managed Server|Ein funktionierender Mastodon-Server erfordert mehrere laufende Server-Dienste. Für den Betrieb ist ein Managed Server sinnvoll.}}

== Vorbereitungen ==

Mit Hilfe von HSAdmin wird angelegt:
# Ein User als Service-User mit ''/bin/bash'' als Shell, zum Beispiel Beispiel: ''xyz00-mastodon''
# Eine Domain mit ''xyz00-mastodon'' als Domain-Administrator, zum Beispiel ''beispiel.social''
# Einen Postgresql-User ''xyz00_mastuser'' mit Passwort ''meinPasswort''
# Eine Postgresql-Datenbank ''xyz00_mastdb'' mit Datenbank-Owner ''xyz00_mastuser''

== Installation von NodeJS ==

Als User 'xyz00-mastodon'': Installation von ''nvm'' und ''nodejs'' (Version 6) nach der Anleitung [[NodeJS]]

Installation von ''yarn'' mit:

npm install -g yarn

== Installation von Ruby ==

Als User ''xyz00-mastodon'': Installation von Ruby mit ''rbenv'' mit folgenden Befehlen:

Zunächst ''rbenv'' and ''ruby-build'':

git clone https://github.com/rbenv/rbenv.git ~/.rbenv
cd ~/.rbenv && src/configure && make -C src
echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bashrc
echo 'eval "$(rbenv init -)"' >> ~/.bashrc

starte neue Shell:

exec bash

Überprüfe rbenv-Installation

type rbenv

Installiere ruby-build als rbenv-Plugin

git clone https://github.com/rbenv/ruby-build.git ~/.rbenv/plugins/ruby-build

Nun kann die benötigte Ruby-Bersion installiert werden:

rbenv install 2.5.0

== Installation der Mastodon Software ==

Weiterhin Als User ''xyz00-mastodon'':

cd ~
git clone https://github.com/tootsuite/mastodon.git live
cd ~/live

Die stabile Version auschecken:

git checkout $(git tag -l | grep -v 'rc[0-9]*$' | sort -V | tail -n 1)

Ruby Pakete installieren:

gem install bundler
bundle install -j$(getconf _NPROCESSORS_ONLN) --deployment --without development test

Node.js Pakete installieren:

yarn install --pure-lockfile

== Einrichten des Apache VHost ==

cd ~/doms/beispiel.social
rm -rf htdocs-ssl subs/www subs-ssl/www
ln -s ~/live/public htdocs-ssl
touch htdocs-ssl/.htaccess

Dann die ''htdocs-ssl/.htaccess'' mit dem Editor der Wahl öffnen und
folgende Konfiguration einfügen:

DirectoryIndex disabled
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_URI} ^/api/v1/streaming [NC]
RewriteRule .* ws://localhost:4000%{REQUEST_URI} [proxy]
RequestHeader set X-Forwarded-Proto "https"
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule .* http://localhost:3000%{REQUEST_URI} [proxy]
RequestHeader set X-Forwarded-Proto "https"

Die Ports 3000 und 4000 sind die Voreinstellung von Mastodon und sollten angepasst werden.

== Links ==

* https://github.com/tootsuite/documentation/blob/master/Running-Mastodon/Production-guide.md
* https://krinetzki.de/2017/04/installation-von-mastodon-auf-debian-8-jessie/
[[Kategorie:Installationsanleitungen]]

Mastodon bei Hostsharing

2018-04-09T13:25:31Z

Hsh00-peh: /* Installation der Mastodon Software */

{{Textkasten|rot|Baustelle|Diese Seite ist noch nicht fertig.}}

{{Textkasten|gelb|Für Managed Server|Ein funktionierender Mastodon-Server erfordert mehrere laufende Server-Dienste. Für den Betrieb ist ein Managed Server sinnvoll.}}

== Vorbereitungen ==

Mit Hilfe von HSAdmin wird angelegt:
# Ein User als Service-User mit ''/bin/bash'' als Shell, zum Beispiel Beispiel: ''xyz00-mastodon''
# Eine Domain mit ''xyz00-mastodon'' als Domain-Administrator, zum Beispiel ''beispiel.social''
# Einen Postgresql-User ''xyz00_mastuser'' mit Passwort ''meinPasswort''
# Eine Postgresql-Datenbank ''xyz00_mastdb'' mit Datenbank-Owner ''xyz00_mastuser''

== Installation von NodeJS ==

Als User 'xyz00-mastodon'': Installation von ''nvm'' und ''nodejs'' (Version 6) nach der Anleitung [[NodeJS]]

Installation von ''yarn'' mit:

npm install -g yarn

== Installation von Ruby ==

Als User ''xyz00-mastodon'': Installation von Ruby mit ''rbenv'' mit folgenden Befehlen:

Zunächst ''rbenv'' and ''ruby-build'':

git clone https://github.com/rbenv/rbenv.git ~/.rbenv
cd ~/.rbenv && src/configure && make -C src
echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bashrc
echo 'eval "$(rbenv init -)"' >> ~/.bashrc

starte neue Shell:

exec bash

Überprüfe rbenv-Installation

type rbenv

Installiere ruby-build als rbenv-Plugin

git clone https://github.com/rbenv/ruby-build.git ~/.rbenv/plugins/ruby-build

Nun kann die benötigte Ruby-Bersion installiert werden:

rbenv install 2.5.0

== Installation der Mastodon Software ==

Weiterhin Als User ''xyz00-mastodon'':

cd ~
git clone https://github.com/tootsuite/mastodon.git live
cd ~/live

Die stabile Version auschecken:

git checkout $(git tag -l | grep -v 'rc[0-9]*$' | sort -V | tail -n 1)

Ruby Pakete installieren:

gem install bundler
bundle install -j$(getconf _NPROCESSORS_ONLN) --deployment --without development test

Node.js Pakete installieren:

yarn install --pure-lockfile

== Einrichten des Apache VHost ==

== Links ==

* https://github.com/tootsuite/documentation/blob/master/Running-Mastodon/Production-guide.md
* https://krinetzki.de/2017/04/installation-von-mastodon-auf-debian-8-jessie/
[[Kategorie:Installationsanleitungen]]

Mastodon bei Hostsharing

2018-04-09T13:23:36Z

Hsh00-peh: /* Installation der Mastodon Software */

{{Textkasten|rot|Baustelle|Diese Seite ist noch nicht fertig.}}

{{Textkasten|gelb|Für Managed Server|Ein funktionierender Mastodon-Server erfordert mehrere laufende Server-Dienste. Für den Betrieb ist ein Managed Server sinnvoll.}}

== Vorbereitungen ==

Mit Hilfe von HSAdmin wird angelegt:
# Ein User als Service-User mit ''/bin/bash'' als Shell, zum Beispiel Beispiel: ''xyz00-mastodon''
# Eine Domain mit ''xyz00-mastodon'' als Domain-Administrator, zum Beispiel ''beispiel.social''
# Einen Postgresql-User ''xyz00_mastuser'' mit Passwort ''meinPasswort''
# Eine Postgresql-Datenbank ''xyz00_mastdb'' mit Datenbank-Owner ''xyz00_mastuser''

== Installation von NodeJS ==

Als User 'xyz00-mastodon'': Installation von ''nvm'' und ''nodejs'' (Version 6) nach der Anleitung [[NodeJS]]

Installation von ''yarn'' mit:

npm install -g yarn

== Installation von Ruby ==

Als User ''xyz00-mastodon'': Installation von Ruby mit ''rbenv'' mit folgenden Befehlen:

Zunächst ''rbenv'' and ''ruby-build'':

git clone https://github.com/rbenv/rbenv.git ~/.rbenv
cd ~/.rbenv && src/configure && make -C src
echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bashrc
echo 'eval "$(rbenv init -)"' >> ~/.bashrc

starte neue Shell:

exec bash

Überprüfe rbenv-Installation

type rbenv

Installiere ruby-build als rbenv-Plugin

git clone https://github.com/rbenv/ruby-build.git ~/.rbenv/plugins/ruby-build

Nun kann die benötigte Ruby-Bersion installiert werden:

rbenv install 2.5.0

== Installation der Mastodon Software ==

Weiterhin Als User ''xyz00-mastodon'':

cd ~
git clone https://github.com/tootsuite/mastodon.git live
cd ~/live

Die stabile Version auschecken:

git checkout $(git tag -l | grep -v 'rc[0-9]*$' | sort -V | tail -n 1)

Ruby Pakete installieren:

gem install bundler
bundle install -j$(getconf _NPROCESSORS_ONLN) --deployment --without development test

Node.js Pakete installieren:

yarn install --pure-lockfile

== Links ==

* https://github.com/tootsuite/documentation/blob/master/Running-Mastodon/Production-guide.md
* https://krinetzki.de/2017/04/installation-von-mastodon-auf-debian-8-jessie/
[[Kategorie:Installationsanleitungen]]

Mastodon bei Hostsharing

2018-04-06T15:57:12Z

Hsh00-peh:

Mastodon bei Hostsharing

2018-04-06T15:41:15Z

Hsh00-peh: /* Installation von Ruby */

{{Textkasten|rot|Baustelle|Diese Seite ist noch nicht fertig.}}

{{Textkasten|gelb|Für Managed Server|Ein funktionierender Mastodon-Server erfodert mehrere laufende Server-Dienste. Für den Betrieb ist ein Managed Server sinnvoll.}}

== Vorbereitungen ==

Mit Hilfe von HSAdmin wird angelegt:
# Ein User als Service-User mit ''/bin/bash'' als Shell, zum Beispiel Beispiel: ''xyz00-mastodon''
# Eine Domain mit ''xyz00-mastodon'' als Domain-Administrator, zum Beispiel ''beispiel.social''
# Einen Postgresql-User ''xyz00_mastuser'' mit Passwort ''meinPasswort''
# Eine Postgresql-Datenbank ''xyz00_mastdb'' mit Datenbank-Owner ''xyz00_mastuser''

== Installation von NodeJS ==

Als User 'xyz00-mastodon'': Installation von ''nvm'' und ''nodejs'' (Version 6) nach der Anleitung [[NodeJS]]

Installation von ''yarn'' mit:

npm install -g yarn

== Installation von Ruby ==

Als User ''xyz00-mastodon'': Installation von Ruby mit ''rbenv'' mit folgenden Befehlen:

Zunächst ''rbenv'' and ''ruby-build'':

git clone https://github.com/rbenv/rbenv.git ~/.rbenv
cd ~/.rbenv && src/configure && make -C src
echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bashrc
echo 'eval "$(rbenv init -)"' >> ~/.bashrc

starte neue Shell:

exec bash

Überprüfe rbenv-Installation

type rbenv

Installiere ruby-build als rbenv-Plugin

git clone https://github.com/rbenv/ruby-build.git ~/.rbenv/plugins/ruby-build

Nun kann die benötigte Ruby-Bersion installiert werden:

rbenv install 2.5.0

== Links ==

* https://github.com/tootsuite/documentation/blob/master/Running-Mastodon/Production-guide.md
* https://krinetzki.de/2017/04/installation-von-mastodon-auf-debian-8-jessie/
[[Kategorie:Installationsanleitungen]]

Mastodon bei Hostsharing

2018-04-06T15:40:23Z

Hsh00-peh:

{{Textkasten|rot|Baustelle|Diese Seite ist noch nicht fertig.}}

{{Textkasten|gelb|Für Managed Server|Ein funktionierender Mastodon-Server erfodert mehrere laufende Server-Dienste. Für den Betrieb ist ein Managed Server sinnvoll.}}

== Vorbereitungen ==

Mit Hilfe von HSAdmin wird angelegt:
# Ein User als Service-User mit ''/bin/bash'' als Shell, zum Beispiel Beispiel: ''xyz00-mastodon''
# Eine Domain mit ''xyz00-mastodon'' als Domain-Administrator, zum Beispiel ''beispiel.social''
# Einen Postgresql-User ''xyz00_mastuser'' mit Passwort ''meinPasswort''
# Eine Postgresql-Datenbank ''xyz00_mastdb'' mit Datenbank-Owner ''xyz00_mastuser''

== Installation von NodeJS ==

Als User 'xyz00-mastodon'': Installation von ''nvm'' und ''nodejs'' (Version 6) nach der Anleitung [[NodeJS]]

Installation von ''yarn'' mit:

npm install -g yarn

== Installation von Ruby ==

Als User 'xyz00-mastodon'': Installation von Ruby mit ''rbenv'' mit folgenden Befehlen:

Zunächst ''rbenv'' and ''ruby-build'':

git clone https://github.com/rbenv/rbenv.git ~/.rbenv
cd ~/.rbenv && src/configure && make -C src
echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bashrc
echo 'eval "$(rbenv init -)"' >> ~/.bashrc

starte neue Shell:

exec bash

Überprüfe rbenv-Installation

type rbenv

Installiere ruby-build als rbenv-Plugin

git clone https://github.com/rbenv/ruby-build.git ~/.rbenv/plugins/ruby-build

Nun kann die benötigte Ruby-Bersion installiert werden:

rbenv install 2.5.0

== Links ==

* https://github.com/tootsuite/documentation/blob/master/Running-Mastodon/Production-guide.md
* https://krinetzki.de/2017/04/installation-von-mastodon-auf-debian-8-jessie/
[[Kategorie:Installationsanleitungen]]

Mastodon bei Hostsharing

2018-04-06T15:14:22Z

Hsh00-peh: /* Installation von NodeJS */

Mastodon bei Hostsharing

2018-04-06T15:11:21Z

Hsh00-peh: /* Installation von NodeJS */

Mastodon bei Hostsharing

2018-04-06T14:58:33Z

Hsh00-peh:

Mastodon bei Hostsharing

2018-04-06T14:48:01Z

Hsh00-peh: Die Seite wurde neu angelegt: „{{Textkasten|rot|Baustelle|Diese Seite ist noch nicht fertig.}} {{Textkasten|gelb|Für Managed Server|Ein funktionierender Mastodon-Server erfodert mehrere la…“

{{Textkasten|rot|Baustelle|Diese Seite ist noch nicht fertig.}}

{{Textkasten|gelb|Für Managed Server|Ein funktionierender Mastodon-Server erfodert mehrere laufende Server-Dienste. Für den Betrieb ist ein Managed Server sinnvoll.}}

== Installation von NodeJS ==

== Installation von Ruby ==

== Anlegen einer PostgreSQL Datenbank ==

[[Kategorie:Installationsanleitungen]]

Stretch

2018-03-13T15:48:21Z

Hsh00-peh: /* Update des OpenSSH Servers */

Stretch

2018-03-13T15:47:42Z

Hsh00-peh: /* MySQL wird ersetzt durch MariaDB */

RadicaleCalDAVServer

2018-03-01T15:28:44Z

Hsh00-peh: Radicale 2

= Radicale CalDAV Server =

{{Textkasten|gelb| Anleitung für Radicale 2.x mit Virtualenv in Stichworten: https://lists.hostsharing.net/archiv/support/2018-February/066810.html }}

[http://de.wikipedia.org/wiki/CalDAV CalDAV] ist eine Erweiterung des WebDAV- (und damit des HTTP-) Protokolls, um Kalenderdaten (Termine und Aufgaben) auf einem Server zu speichern.

Apple nutzt diese Protokoll für seine Clients (iCal-Anwendung und Kalender-App auf dem iPhone) und bietet einen entsprechenden Server an. Dadurch gewinnt CalDAV zunehmende Bedeutung.

Wenn man freie Software einsetzen will, bieten sich folgende Anwendungen an:
* Das [http://www.mozilla.org/projects/calendar/lightning/ Lightning-Plugin] für Thunderbird (unter Linux und Windows)
* [https://f-droid.org/repository/browse/?fdid=org.gege.caldavsyncadapter CalDAV Sync Adapter] als Android-App zur Synchronisation des Kalenders
* Der [http://caldavsynchronizer.org/ CaldavSynchronizer] für Outlook

In diesem Artikel wird die Installation eines CalDAV-Server in einem normalen Hostsharing-Paket beschrieben, als leichtgewichtigen Server nutze ich den [http://radicale.org/ Radicale CalDAV Server]. Der Server kann mit Hilfe von Passenger betrieben werden.

In dieser Installationsanleitung wird die Installation für HTTP und HTTPS (Verzeichnisse "app-ssl" und "htdocs-ssl") parallel vorgenommen. Ihr solltet darauf achten, den CalDAV- / Card-Server im produktiven
Betrieb immer nur über HTTPS (also mit SSL-/TLS_Verschlüsselung) anzusprechen. Schliesslich werden Passworte und personenbezogene Daten übertragen!

== Installation ==

=== Vorbereitung ===

Ich lege mit HSAdmin einen User ''xyz00-cal'' an und schalte eine Domain ''cal.example.org'' auf.

=== Download und Installation des Paketes ===

als User ''xyz00-cal'':

<pre>
pip install --user radicale==1.1.6
</pre>

=== Passenger Konfiguration ===

Vor der Nutzung von [[Phusion Passenger]] bitte unbedingt die dortigen Hinweise zur Nutzung beachten.

Wir wechseln in das Domain-Verzeichnis ''~/doms/cal.example.org/''.
Dorthin legen wir die folgende Datei an:

''~/doms/cal.example.org/app/passenger_wsgi.py'' und
''~/doms/cal.example.org/app-ssl/passenger_wsgi.py''

<pre>
#!/usr/bin/env python

import radicale

radicale.log.start()
application = radicale.Application()
</pre>

''~/doms/cal.example.org/htdocs/.htaccess'' und
''~/doms/cal.example.org/htdocs-ssl/.htaccess''

<pre>
AuthType Basic
AuthName "Radicale Calendar Server"
require valid-user
AuthUserFile /home/pacs/xyz00/users/cal/.htpasswd
</pre>

Es fehlt noch das Anlegen der ''~/.htpasswd''-Datei mit den verschlüsselten Passworten der User.
Dazu rufen wir (für die User ''hans'' und ''franz'') folgendes Kommando auf (''htpasswd -c'' erzeugt die Datei):

<pre>
htpasswd -c ~/.htpasswd hans
htpasswd ~/.htpasswd franz
...
</pre>

An dieser Stelle sollte ein Aufruf von ''https://cal.example.org'' im Browser nach Eingabe des Passwortes für ''hans'' oder ''franz'' die folgende Seite liefern: ''Radicale works!''

=== Radicale Konfiguration ===

Zuletzt bleibt noch die Erstellung einer Konfigurationsdatei für den Radicale-Server.
Ein Template für die Datei findet Ihr in ''~/Radicale-0.9/config''.

Hier der Inhalt meiner ''~/.config/radicale/config'':

<pre>
# Config file for Radicale - A simple calendar server
# Place it into ~/.config/radicale/config (user)

[server]
base_prefix = /
can_skip_base_prefix = False
dns_lookup = False

[encoding]
request = utf-8
stock = utf-8

[auth]
type = None

[rights]
type = None

[storage]
type = filesystem
custom_handler =
filesystem_folder = ~/.config/radicale/collections

[logging]
config = ~/.config/radicale/logging
debug = False
full_environment = False
</pre>

Hier der Inhalt meiner ''~/.config/radicale/logging'':

<pre>
[loggers]
keys = root

[handlers]
keys = file

[formatters]
keys = full

[logger_root]
level = INFO
handlers = file

[handler_file]
class = FileHandler
args = ('/home/pacs/xyz00/users/cal/var/radicale.log',)
formatter = full

[formatter_full]
format = %(asctime)s - %(levelname)s: %(message)s
</pre>

== Nutzung der Kalender ==

=== Zugriffsrechte ===

Zu diesem Zeitpunkt können die User ''hans'' und ''franz'' jeweils auf alle Kalender zugreifen. In einer größeren Organisation ist das sicher nicht ausreichend.

Im der oben beschriebenen Konfiguration überlässt man die Zugriffskontrolle am besten dem Apache-Webserver. Das kann man einfach über die bereits vorhandene ''.htaccess''-Datei regeln:

<pre>
AuthType Basic
AuthName "Radicale Calendar Server"
AuthUserFile /home/pacs/xyz00/users/cal/.htpasswd
<FilesMatch "^hans">
require user hans
</FilesMatch>
<FilesMatch "^franz">
require user franz
</FilesMatch>
<FilesMatch "^team">
require valid-user
</FilesMatch>
</pre>

So können beide User jeweils eigene Kalender anlegen, z.B:
* /hans/privat
* /hans/aufgaben
* /franz/kalender

Unter dem Pseudouser ''team'' können gemeinsame Kalender verwaltet werden:
* /team/meetings
* /team/seminarraum

Mit einer zusätzlichen Datei ''.htgroups'' kann man auch komplexere Szenarien implementieren.

=== Client Konfiguration ===

Ich selbst verwende das Lightning-Plugin zu Thunderbird und [https://f-droid.org/packages/at.bitfire.davdroid/ DavDroid] als App zur Synchronisation des Android-Kalenders.

==== Lightning ====

Hier kann man jeden einzelnen Kalender mit seiner vollständigen URL abonnieren.

Über die Funktion "Create Calendar":
# "On the Network"
# "CalDAV" mit "Location": ''https://cal.example.org/franz/privat''
# Namen vergeben und Farbe wählen
# ggf. noch User und Passwort angeben
# das war's

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

RadicaleCalDAVServer

2018-02-06T13:52:16Z

Hsh00-peh: /* Client Konfiguration */

= Radicale CalDAV Server =

[http://de.wikipedia.org/wiki/CalDAV CalDAV] ist eine Erweiterung des WebDAV- (und damit des HTTP-) Protokolls, um Kalenderdaten (Termine und Aufgaben) auf einem Server zu speichern.

Apple nutzt diese Protokoll für seine Clients (iCal-Anwendung und Kalender-App auf dem iPhone) und bietet einen entsprechenden Server an. Dadurch gewinnt CalDAV zunehmende Bedeutung.

Wenn man freie Software einsetzen will, bieten sich folgende Anwendungen an:
* Das [http://www.mozilla.org/projects/calendar/lightning/ Lightning-Plugin] für Thunderbird (unter Linux und Windows)
* [https://f-droid.org/repository/browse/?fdid=org.gege.caldavsyncadapter CalDAV Sync Adapter] als Android-App zur Synchronisation des Kalenders
* Der [http://caldavsynchronizer.org/ CaldavSynchronizer] für Outlook

In diesem Artikel wird die Installation eines CalDAV-Server in einem normalen Hostsharing-Paket beschrieben, als leichtgewichtigen Server nutze ich den [http://radicale.org/ Radicale CalDAV Server]. Der Server kann mit Hilfe von Passenger betrieben werden.

In dieser Installationsanleitung wird die Installation für HTTP und HTTPS (Verzeichnisse "app-ssl" und "htdocs-ssl") parallel vorgenommen. Ihr solltet darauf achten, den CalDAV- / Card-Server im produktiven
Betrieb immer nur über HTTPS (also mit SSL-/TLS_Verschlüsselung) anzusprechen. Schliesslich werden Passworte und personenbezogene Daten übertragen!

== Installation ==

=== Vorbereitung ===

Ich lege mit HSAdmin einen User ''xyz00-cal'' an und schalte eine Domain ''cal.example.org'' auf.

=== Download und Installation des Paketes ===

als User ''xyz00-cal'':

<pre>
pip install --user radicale==1.1.6
</pre>

=== Passenger Konfiguration ===

Vor der Nutzung von [[Phusion Passenger]] bitte unbedingt die dortigen Hinweise zur Nutzung beachten.

Wir wechseln in das Domain-Verzeichnis ''~/doms/cal.example.org/''.
Dorthin legen wir die folgende Datei an:

''~/doms/cal.example.org/app/passenger_wsgi.py'' und
''~/doms/cal.example.org/app-ssl/passenger_wsgi.py''

<pre>
#!/usr/bin/env python

import radicale

radicale.log.start()
application = radicale.Application()
</pre>

''~/doms/cal.example.org/htdocs/.htaccess'' und
''~/doms/cal.example.org/htdocs-ssl/.htaccess''

<pre>
AuthType Basic
AuthName "Radicale Calendar Server"
require valid-user
AuthUserFile /home/pacs/xyz00/users/cal/.htpasswd
</pre>

Es fehlt noch das Anlegen der ''~/.htpasswd''-Datei mit den verschlüsselten Passworten der User.
Dazu rufen wir (für die User ''hans'' und ''franz'') folgendes Kommando auf (''htpasswd -c'' erzeugt die Datei):

<pre>
htpasswd -c ~/.htpasswd hans
htpasswd ~/.htpasswd franz
...
</pre>

An dieser Stelle sollte ein Aufruf von ''https://cal.example.org'' im Browser nach Eingabe des Passwortes für ''hans'' oder ''franz'' die folgende Seite liefern: ''Radicale works!''

=== Radicale Konfiguration ===

Zuletzt bleibt noch die Erstellung einer Konfigurationsdatei für den Radicale-Server.
Ein Template für die Datei findet Ihr in ''~/Radicale-0.9/config''.

Hier der Inhalt meiner ''~/.config/radicale/config'':

<pre>
# Config file for Radicale - A simple calendar server
# Place it into ~/.config/radicale/config (user)

[server]
base_prefix = /
can_skip_base_prefix = False
dns_lookup = False

[encoding]
request = utf-8
stock = utf-8

[auth]
type = None

[rights]
type = None

[storage]
type = filesystem
custom_handler =
filesystem_folder = ~/.config/radicale/collections

[logging]
config = ~/.config/radicale/logging
debug = False
full_environment = False
</pre>

Hier der Inhalt meiner ''~/.config/radicale/logging'':

<pre>
[loggers]
keys = root

[handlers]
keys = file

[formatters]
keys = full

[logger_root]
level = INFO
handlers = file

[handler_file]
class = FileHandler
args = ('/home/pacs/xyz00/users/cal/var/radicale.log',)
formatter = full

[formatter_full]
format = %(asctime)s - %(levelname)s: %(message)s
</pre>

== Nutzung der Kalender ==

=== Zugriffsrechte ===

Zu diesem Zeitpunkt können die User ''hans'' und ''franz'' jeweils auf alle Kalender zugreifen. In einer größeren Organisation ist das sicher nicht ausreichend.

Im der oben beschriebenen Konfiguration überlässt man die Zugriffskontrolle am besten dem Apache-Webserver. Das kann man einfach über die bereits vorhandene ''.htaccess''-Datei regeln:

<pre>
AuthType Basic
AuthName "Radicale Calendar Server"
AuthUserFile /home/pacs/xyz00/users/cal/.htpasswd
<FilesMatch "^hans">
require user hans
</FilesMatch>
<FilesMatch "^franz">
require user franz
</FilesMatch>
<FilesMatch "^team">
require valid-user
</FilesMatch>
</pre>

So können beide User jeweils eigene Kalender anlegen, z.B:
* /hans/privat
* /hans/aufgaben
* /franz/kalender

Unter dem Pseudouser ''team'' können gemeinsame Kalender verwaltet werden:
* /team/meetings
* /team/seminarraum

Mit einer zusätzlichen Datei ''.htgroups'' kann man auch komplexere Szenarien implementieren.

=== Client Konfiguration ===

Ich selbst verwende das Lightning-Plugin zu Thunderbird und [https://f-droid.org/packages/at.bitfire.davdroid/ DavDroid] als App zur Synchronisation des Android-Kalenders.

==== Lightning ====

Hier kann man jeden einzelnen Kalender mit seiner vollständigen URL abonnieren.

Über die Funktion "Create Calendar":
# "On the Network"
# "CalDAV" mit "Location": ''https://cal.example.org/franz/privat''
# Namen vergeben und Farbe wählen
# ggf. noch User und Passwort angeben
# das war's

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

RadicaleCalDAVServer

2018-02-06T13:49:35Z

Hsh00-peh: Android

= Radicale CalDAV Server =

[http://de.wikipedia.org/wiki/CalDAV CalDAV] ist eine Erweiterung des WebDAV- (und damit des HTTP-) Protokolls, um Kalenderdaten (Termine und Aufgaben) auf einem Server zu speichern.

Apple nutzt diese Protokoll für seine Clients (iCal-Anwendung und Kalender-App auf dem iPhone) und bietet einen entsprechenden Server an. Dadurch gewinnt CalDAV zunehmende Bedeutung.

Wenn man freie Software einsetzen will, bieten sich folgende Anwendungen an:
* Das [http://www.mozilla.org/projects/calendar/lightning/ Lightning-Plugin] für Thunderbird (unter Linux und Windows)
* [https://f-droid.org/repository/browse/?fdid=org.gege.caldavsyncadapter CalDAV Sync Adapter] als Android-App zur Synchronisation des Kalenders
* Der [http://caldavsynchronizer.org/ CaldavSynchronizer] für Outlook

In diesem Artikel wird die Installation eines CalDAV-Server in einem normalen Hostsharing-Paket beschrieben, als leichtgewichtigen Server nutze ich den [http://radicale.org/ Radicale CalDAV Server]. Der Server kann mit Hilfe von Passenger betrieben werden.

In dieser Installationsanleitung wird die Installation für HTTP und HTTPS (Verzeichnisse "app-ssl" und "htdocs-ssl") parallel vorgenommen. Ihr solltet darauf achten, den CalDAV- / Card-Server im produktiven
Betrieb immer nur über HTTPS (also mit SSL-/TLS_Verschlüsselung) anzusprechen. Schliesslich werden Passworte und personenbezogene Daten übertragen!

== Installation ==

=== Vorbereitung ===

Ich lege mit HSAdmin einen User ''xyz00-cal'' an und schalte eine Domain ''cal.example.org'' auf.

=== Download und Installation des Paketes ===

als User ''xyz00-cal'':

<pre>
pip install --user radicale==1.1.6
</pre>

=== Passenger Konfiguration ===

Vor der Nutzung von [[Phusion Passenger]] bitte unbedingt die dortigen Hinweise zur Nutzung beachten.

Wir wechseln in das Domain-Verzeichnis ''~/doms/cal.example.org/''.
Dorthin legen wir die folgende Datei an:

''~/doms/cal.example.org/app/passenger_wsgi.py'' und
''~/doms/cal.example.org/app-ssl/passenger_wsgi.py''

<pre>
#!/usr/bin/env python

import radicale

radicale.log.start()
application = radicale.Application()
</pre>

''~/doms/cal.example.org/htdocs/.htaccess'' und
''~/doms/cal.example.org/htdocs-ssl/.htaccess''

<pre>
AuthType Basic
AuthName "Radicale Calendar Server"
require valid-user
AuthUserFile /home/pacs/xyz00/users/cal/.htpasswd
</pre>

Es fehlt noch das Anlegen der ''~/.htpasswd''-Datei mit den verschlüsselten Passworten der User.
Dazu rufen wir (für die User ''hans'' und ''franz'') folgendes Kommando auf (''htpasswd -c'' erzeugt die Datei):

<pre>
htpasswd -c ~/.htpasswd hans
htpasswd ~/.htpasswd franz
...
</pre>

An dieser Stelle sollte ein Aufruf von ''https://cal.example.org'' im Browser nach Eingabe des Passwortes für ''hans'' oder ''franz'' die folgende Seite liefern: ''Radicale works!''

=== Radicale Konfiguration ===

Zuletzt bleibt noch die Erstellung einer Konfigurationsdatei für den Radicale-Server.
Ein Template für die Datei findet Ihr in ''~/Radicale-0.9/config''.

Hier der Inhalt meiner ''~/.config/radicale/config'':

<pre>
# Config file for Radicale - A simple calendar server
# Place it into ~/.config/radicale/config (user)

[server]
base_prefix = /
can_skip_base_prefix = False
dns_lookup = False

[encoding]
request = utf-8
stock = utf-8

[auth]
type = None

[rights]
type = None

[storage]
type = filesystem
custom_handler =
filesystem_folder = ~/.config/radicale/collections

[logging]
config = ~/.config/radicale/logging
debug = False
full_environment = False
</pre>

Hier der Inhalt meiner ''~/.config/radicale/logging'':

<pre>
[loggers]
keys = root

[handlers]
keys = file

[formatters]
keys = full

[logger_root]
level = INFO
handlers = file

[handler_file]
class = FileHandler
args = ('/home/pacs/xyz00/users/cal/var/radicale.log',)
formatter = full

[formatter_full]
format = %(asctime)s - %(levelname)s: %(message)s
</pre>

== Nutzung der Kalender ==

=== Zugriffsrechte ===

Zu diesem Zeitpunkt können die User ''hans'' und ''franz'' jeweils auf alle Kalender zugreifen. In einer größeren Organisation ist das sicher nicht ausreichend.

Im der oben beschriebenen Konfiguration überlässt man die Zugriffskontrolle am besten dem Apache-Webserver. Das kann man einfach über die bereits vorhandene ''.htaccess''-Datei regeln:

<pre>
AuthType Basic
AuthName "Radicale Calendar Server"
AuthUserFile /home/pacs/xyz00/users/cal/.htpasswd
<FilesMatch "^hans">
require user hans
</FilesMatch>
<FilesMatch "^franz">
require user franz
</FilesMatch>
<FilesMatch "^team">
require valid-user
</FilesMatch>
</pre>

So können beide User jeweils eigene Kalender anlegen, z.B:
* /hans/privat
* /hans/aufgaben
* /franz/kalender

Unter dem Pseudouser ''team'' können gemeinsame Kalender verwaltet werden:
* /team/meetings
* /team/seminarraum

Mit einer zusätzlichen Datei ''.htgroups'' kann man auch komplexere Szenarien implementieren.

=== Client Konfiguration ===

Ich selbst verwende das Lightning-Plugin zu Thunderbird und "DavDroid":"https://f-droid.org/packages/at.bitfire.davdroid/" als App zur Synchronisation des Android-Kalenders.

==== Lightning ====

Hier kann man jeden einzelnen Kalender mit seiner vollständigen URL abonnieren.

Über die Funktion "Create Calendar":
# "On the Network"
# "CalDAV" mit "Location": ''https://cal.example.org/franz/privat''
# Namen vergeben und Farbe wählen
# ggf. noch User und Passwort angeben
# das war's

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

RadicaleCalDAVServer

2018-02-06T13:20:20Z

Hsh00-peh:

= Radicale CalDAV Server =

[http://de.wikipedia.org/wiki/CalDAV CalDAV] ist eine Erweiterung des WebDAV- (und damit des HTTP-) Protokolls, um Kalenderdaten (Termine und Aufgaben) auf einem Server zu speichern.

Apple nutzt diese Protokoll für seine Clients (iCal-Anwendung und Kalender-App auf dem iPhone) und bietet einen entsprechenden Server an. Dadurch gewinnt CalDAV zunehmende Bedeutung.

Wenn man freie Software einsetzen will, bieten sich folgende Anwendungen an:
* Das [http://www.mozilla.org/projects/calendar/lightning/ Lightning-Plugin] für Thunderbird (unter Linux und Windows)
* [https://f-droid.org/repository/browse/?fdid=org.gege.caldavsyncadapter CalDAV Sync Adapter] als Android-App zur Synchronisation des Kalenders
* Der [http://caldavsynchronizer.org/ CaldavSynchronizer] für Outlook

In diesem Artikel wird die Installation eines CalDAV-Server in einem normalen Hostsharing-Paket beschrieben, als leichtgewichtigen Server nutze ich den [http://radicale.org/ Radicale CalDAV Server]. Der Server kann mit Hilfe von Passenger betrieben werden.

In dieser Installationsanleitung wird die Installation für HTTP und HTTPS (Verzeichnisse "app-ssl" und "htdocs-ssl") parallel vorgenommen. Ihr solltet darauf achten, den CalDAV- / Card-Server im produktiven
Betrieb immer nur über HTTPS (also mit SSL-/TLS_Verschlüsselung) anzusprechen. Schliesslich werden Passworte und personenbezogene Daten übertragen!

== Installation ==

=== Vorbereitung ===

Ich lege mit HSAdmin einen User ''xyz00-cal'' an und schalte eine Domain ''cal.example.org'' auf.

=== Download und Installation des Paketes ===

als User ''xyz00-cal'':

<pre>
pip install --user radicale==1.1.6
</pre>

=== Passenger Konfiguration ===

Vor der Nutzung von [[Phusion Passenger]] bitte unbedingt die dortigen Hinweise zur Nutzung beachten.

Wir wechseln in das Domain-Verzeichnis ''~/doms/cal.example.org/''.
Dorthin legen wir die folgende Datei an:

''~/doms/cal.example.org/app/passenger_wsgi.py'' und
''~/doms/cal.example.org/app-ssl/passenger_wsgi.py''

<pre>
#!/usr/bin/env python

import radicale

radicale.log.start()
application = radicale.Application()
</pre>

''~/doms/cal.example.org/htdocs/.htaccess'' und
''~/doms/cal.example.org/htdocs-ssl/.htaccess''

<pre>
AuthType Basic
AuthName "Radicale Calendar Server"
require valid-user
AuthUserFile /home/pacs/xyz00/users/cal/.htpasswd
</pre>

Es fehlt noch das Anlegen der ''~/.htpasswd''-Datei mit den verschlüsselten Passworten der User.
Dazu rufen wir (für die User ''hans'' und ''franz'') folgendes Kommando auf (''htpasswd -c'' erzeugt die Datei):

<pre>
htpasswd -c ~/.htpasswd hans
htpasswd ~/.htpasswd franz
...
</pre>

An dieser Stelle sollte ein Aufruf von ''https://cal.example.org'' im Browser nach Eingabe des Passwortes für ''hans'' oder ''franz'' die folgende Seite liefern: ''Radicale works!''

=== Radicale Konfiguration ===

Zuletzt bleibt noch die Erstellung einer Konfigurationsdatei für den Radicale-Server.
Ein Template für die Datei findet Ihr in ''~/Radicale-0.9/config''.

Hier der Inhalt meiner ''~/.config/radicale/config'':

<pre>
# Config file for Radicale - A simple calendar server
# Place it into ~/.config/radicale/config (user)

[server]
base_prefix = /
can_skip_base_prefix = False
dns_lookup = False

[encoding]
request = utf-8
stock = utf-8

[auth]
type = None

[rights]
type = None

[storage]
type = filesystem
custom_handler =
filesystem_folder = ~/.config/radicale/collections

[logging]
config = ~/.config/radicale/logging
debug = False
full_environment = False
</pre>

Hier der Inhalt meiner ''~/.config/radicale/logging'':

<pre>
[loggers]
keys = root

[handlers]
keys = file

[formatters]
keys = full

[logger_root]
level = INFO
handlers = file

[handler_file]
class = FileHandler
args = ('/home/pacs/xyz00/users/cal/var/radicale.log',)
formatter = full

[formatter_full]
format = %(asctime)s - %(levelname)s: %(message)s
</pre>

== Nutzung der Kalender ==

=== Zugriffsrechte ===

Zu diesem Zeitpunkt können die User ''hans'' und ''franz'' jeweils auf alle Kalender zugreifen. In einer größeren Organisation ist das sicher nicht ausreichend.

Im der oben beschriebenen Konfiguration überlässt man die Zugriffskontrolle am besten dem Apache-Webserver. Das kann man einfach über die bereits vorhandene ''.htaccess''-Datei regeln:

<pre>
AuthType Basic
AuthName "Radicale Calendar Server"
AuthUserFile /home/pacs/xyz00/users/cal/.htpasswd
<FilesMatch "^hans">
require user hans
</FilesMatch>
<FilesMatch "^franz">
require user franz
</FilesMatch>
<FilesMatch "^team">
require valid-user
</FilesMatch>
</pre>

So können beide User jeweils eigene Kalender anlegen, z.B:
* /hans/privat
* /hans/aufgaben
* /franz/kalender

Unter dem Pseudouser ''team'' können gemeinsame Kalender verwaltet werden:
* /team/meetings
* /team/seminarraum

Mit einer zusätzlichen Datei ''.htgroups'' kann man auch komplexere Szenarien implementieren.

=== Client Konfiguration ===

Ich selbst verwende das Lightning-Plugin zu Thunderbird und aCal als Android-App.

==== Lightning ====

Hier kann man jeden einzelnen Kalender mit seiner vollständigen URL abonnieren.

Über die Funktion "Create Calendar":
# "On the Network"
# "CalDAV" mit "Location": ''https://cal.example.org/franz/privat''
# Namen vergeben und Farbe wählen
# ggf. noch User und Passwort angeben
# das war's

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

RadicaleCalDAVServer

2018-02-06T12:11:39Z

Hsh00-peh:

= Radicale CalDAV Server =

[http://de.wikipedia.org/wiki/CalDAV CalDAV] ist eine Erweiterung des WebDAV- (und damit des HTTP-) Protokolls, um Kalenderdaten (Termine und Aufgaben) auf einem Server zu speichern.

Apple nutzt diese Protokoll für seine Clients (iCal-Anwendung und Kalender-App auf dem iPhone) und bietet einen entsprechenden Server an. Dadurch gewinnt CalDAV zunehmende Bedeutung.

Wenn man freie Software einsetzen will, bieten sich folgende Anwendungen an:
* Das [http://www.mozilla.org/projects/calendar/lightning/ Lightning-Plugin] für Thunderbird (unter Linux und Windows)
* [https://f-droid.org/repository/browse/?fdid=org.gege.caldavsyncadapter CalDAV Sync Adapter] als Android-App zur Synchronisation des Kalenders
* Der [http://caldavsynchronizer.org/ CaldavSynchronizer] für Outlook

In diesem Artikel wird die Installation eines CalDAV-Server in einem normalen Hostsharing-Paket beschrieben, als leichtgewichtigen Server nutze ich den [http://radicale.org/ Radicale CalDAV Server]. Der Server kann mit Hilfe von Passenger betrieben werden.

In dieser Installationsanleitung wird die Installation für HTTP und HTTPS (Verzeichnisse "app-ssl" und "htdocs-ssl") parallel vorgenommen. Ihr solltet darauf achten, den CalDAV- / Card-Server im produktiven
Betrieb immer nur über HTTPS (also mit SSL-/TLS_Verschlüsselung) anzusprechen. Schliesslich werden Passworte und personenbezogene Daten übertragen!

== Installation ==

=== Vorbereitung ===

Ich lege mit HSAdmin einen User ''xyz00-cal'' an und schalte eine Domain ''cal.example.org'' auf.

=== Download und Installation des Paketes ===

als User ''xyz00-cal'':

<pre>
pip install --user radicale=1.1.6
</pre>

=== Passenger Konfiguration ===

Vor der Nutzung von [[Phusion Passenger]] bitte unbedingt die dortigen Hinweise zur Nutzung beachten.

Wir wechseln in das Domain-Verzeichnis ''~/doms/cal.example.org/''.
Dorthin legen wir die folgende Datei an:

''~/doms/cal.example.org/app/passenger_wsgi.py'' und
''~/doms/cal.example.org/app-ssl/passenger_wsgi.py''

<pre>
#!/usr/bin/env python

import radicale

radicale.log.start()
application = radicale.Application()
</pre>

''~/doms/cal.example.org/htdocs/.htaccess'' und
''~/doms/cal.example.org/htdocs-ssl/.htaccess''

<pre>
AuthType Basic
AuthName "Radicale Calendar Server"
require valid-user
AuthUserFile /home/pacs/xyz00/users/cal/.htpasswd
</pre>

Es fehlt noch das Anlegen der ''~/.htpasswd''-Datei mit den verschlüsselten Passworten der User.
Dazu rufen wir (für die User ''hans'' und ''franz'') folgendes Kommando auf (''htpasswd -c'' erzeugt die Datei):

<pre>
htpasswd -c ~/.htpasswd hans
htpasswd ~/.htpasswd franz
...
</pre>

An dieser Stelle sollte ein Aufruf von ''https://cal.example.org'' im Browser nach Eingabe des Passwortes für ''hans'' oder ''franz'' die folgende Seite liefern: ''Radicale works!''

=== Radicale Konfiguration ===

Zuletzt bleibt noch die Erstellung einer Konfigurationsdatei für den Radicale-Server.
Ein Template für die Datei findet Ihr in ''~/Radicale-0.9/config''.

Hier der Inhalt meiner ''~/.config/radicale/config'':

<pre>
# Config file for Radicale - A simple calendar server
# Place it into ~/.config/radicale/config (user)

[server]
base_prefix = /
can_skip_base_prefix = False
dns_lookup = False

[encoding]
request = utf-8
stock = utf-8

[auth]
type = None

[rights]
type = None

[storage]
type = filesystem
custom_handler =
filesystem_folder = ~/.config/radicale/collections

[logging]
config = ~/.config/radicale/logging
debug = False
full_environment = False
</pre>

Hier der Inhalt meiner ''~/.config/radicale/logging'':

<pre>
[loggers]
keys = root

[handlers]
keys = file

[formatters]
keys = full

[logger_root]
level = INFO
handlers = file

[handler_file]
class = FileHandler
args = ('/home/pacs/xyz00/users/cal/var/radicale.log',)
formatter = full

[formatter_full]
format = %(asctime)s - %(levelname)s: %(message)s
</pre>

== Nutzung der Kalender ==

=== Zugriffsrechte ===

Zu diesem Zeitpunkt können die User ''hans'' und ''franz'' jeweils auf alle Kalender zugreifen. In einer größeren Organisation ist das sicher nicht ausreichend.

Im der oben beschriebenen Konfiguration überlässt man die Zugriffskontrolle am besten dem Apache-Webserver. Das kann man einfach über die bereits vorhandene ''.htaccess''-Datei regeln:

<pre>
AuthType Basic
AuthName "Radicale Calendar Server"
AuthUserFile /home/pacs/xyz00/users/cal/.htpasswd
<FilesMatch "^hans">
require user hans
</FilesMatch>
<FilesMatch "^franz">
require user franz
</FilesMatch>
<FilesMatch "^team">
require valid-user
</FilesMatch>
</pre>

So können beide User jeweils eigene Kalender anlegen, z.B:
* /hans/privat
* /hans/aufgaben
* /franz/kalender

Unter dem Pseudouser ''team'' können gemeinsame Kalender verwaltet werden:
* /team/meetings
* /team/seminarraum

Mit einer zusätzlichen Datei ''.htgroups'' kann man auch komplexere Szenarien implementieren.

=== Client Konfiguration ===

Ich selbst verwende das Lightning-Plugin zu Thunderbird und aCal als Android-App.

==== Lightning ====

Hier kann man jeden einzelnen Kalender mit seiner vollständigen URL abonnieren.

Über die Funktion "Create Calendar":
# "On the Network"
# "CalDAV" mit "Location": ''https://cal.example.org/franz/privat''
# Namen vergeben und Farbe wählen
# ggf. noch User und Passwort angeben
# das war's

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

SSH Rate Limit

2018-01-24T15:21:44Z

Hsh00-peh: ssh Multiplexing gegen Rate Limit

Unsere ssh-Server sind durch Firewall-Regeln geschützt. Ein sogenanntes "Rate-Limit" schützt den Server vor vielen Verbindungsversuchen von einem einzelnen Server aus.

Das Rate-Limit begrenzt die Zugriff (Logins) pro IP-Adresse und
Zeitfenster. Wir schützen hiermit unsere Infrastruktur vor Überlastung
und reduzieren die Gefahr, dass Passwörter durch systematisches
Probieren geknackt werden.

Folgende Staffelung haben wir erfolgreich erprobt:
* mehr als 5 Logins innerhalb von 15 Sekunden
* mehr als 10 Logins innerhalb von 60 Sekunden
* mehr als 25 Logins innerhalb von 300 Sekunden

Diese Begrenzungen führen bei manchen Mitgliedern zu Problemen bei Skripten und Ansible-Playbook zur automatischen Konfiguration.

Abhilfe schafft das sog. ssh-Multiplexing (vgl. Links)

Das Multiplexing wird durch folgende Zeilen in der Datei
$HOME/.ssh/config aktiv:

Host *.hostsharing.net
ControlPath ~/.ssh/cm-%r@%h:%p
ControlMaster auto
ControlPersist 10m

Es wird eine einzige Verbindung zum ssh-Server mit der Paket-IP aufgebaut und für alle ssh-Aufrufe wiederbenutzt. Erst nach 10 Minuten Stillstand wird die Verbindung abgebaut.

=== Links ===

* https://www.nosid.org/tip-ssh-multiplexing.html
* https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Multiplexing (englisch)

Stretch

2018-01-11T18:05:50Z

Hsh00-peh:

Stretch

2018-01-11T18:04:08Z

Hsh00-peh: begonnen

= Upgrade auf Debian Stretch =

In ersten Quartal führt das Hostsharing-Team die vorbereitenden Arbeiten für das Upgrade
der Hostsharing-Server auf Debian Stretch (Debian 9.x) durch.

Während der Vorbereitungen werden wir die Mitglieder und Nutzer.innen unserer Plattform
auf dieser Wiki-Seite über die Vorbereitungen informieren.

Ende März wird auf dieser Seite dokumentiert sein, welche Änderungen durch das Upgrade
notwendig werden und welche Vorbereitungen die Nutzer.innen treffen sollten.

Das Upgrade der Webspaces und Managed Server wird im April 2018 beginnen.

Folgende Software ist insbesondere betroffen:

== MySQL wird ersetzt durch MariaDB ==

== PHP Update auf Version 7.0 ==

== Java Update auf Version 8.0 ==

== Update des OpenSSH Servers ==

----
[[Kategorie:Upgrade Jessie zu Stretch]]
[[Kategorie:Glossar]]

Phusion Passenger

2018-01-08T14:02:33Z

Hsh00-peh: Django als Beispiel

Phusion Passenger ist ein Apache-Plugin zur Integration von Apps auf Domain (vhost) Ebene.
Dabei kann es sich z.B. um [[NodeJS]], [[RubyOnRails]], [[Django|Django]] oder weitere Laufzeitumgebungen handeln.

== Aktivierung / Deaktivierung ==

Sobald im Verzeichnis app bzw. app-ssl unter der aufgeschalteten Domain eine App existiert,
wird dies von Phusion Passenger ausgefürt

Phusion Passenger ist immer für die gesamte aufgeschaltete Domain aktiviert,
die Bereitstellung einer App wirkt also auch auf Subdomains im Verzerichnis 'subs'.
Insbesondere wird damit PHP für die jeweilige Domain deaktiviert.
Statischen Dateien (z.B. index.html) aus htdocs* und subs* sind davon nicht betroffen.
Idealerweise wird daher für jede App eine eigene Subdomain mit HSAdmin aufgeschaltet.

Sobald eine App einmal geladen ist, sind die Settings und Mappings Bestandteil der transienten Apache vhost-Konfiguration.
Änderungen an .htaccess-Settings bzgl. Passenger kommen dann nicht mehr direkt zum Tragen,
weil die .htaccess zu Gunsten der Effizienz dann nicht mehr ausgewertet wird.

Zum deaktivieren einer App muss diese im app und app-ssl Verzeichnis geslöscht werden.

== Konfiguriation / .htaccess ==

Das Plugin ist zwar unabhängig von Einträgen in der .htaccess aktiv,
kann aber über die .htaccess Datei im jeweiligen Domain-Verzeichnis konfiguriert werden,
z.B. in "/home/pacs/xyz00/users/example/doms/example.com/.htaccess":

PassengerNodejs /home/pacs/xyz00/users/example/.nvm/versions/node/v6.11.2/bin/node

(Nähere Informationen bitte den jeweiligen Wiki-Seiten über die spezifischen Laufzeitumgebungen entnehmen.)

== Neueinlesen der Konfiguration / Restart der App ==

Passenger Apps werden wir folgt neu gestartet oder neu geladen:

mkdir app(-ssl)/tmp
touch app(-ssl)/tmp/restart.txt

Das führt nach einer Weile zu einem graceful Restart der App.
D.h. die einzelnen Prozesse werden sukzessive zwischen der Bedienung von HTTP-Requests neu gestartet.
Im Rahmen dieses Restarts sollten geänderte .htaccess Direktiven Wirkung entfalten.
Entsprechendes gilt für Änderungen an der Applikation selbst.

Phusion Passenger

2018-01-08T14:01:39Z

Hsh00-peh:

Phusion Passenger ist ein Apache-Plugin zur Integration von Apps auf Domain (vhost) Ebene.
Dabei kann es sich z.B. um [[NodeJS]], [[RubyOnRails]], [[Django|Django_Installation]] oder weitere Laufzeitumgebungen handeln.

== Aktivierung / Deaktivierung ==

Sobald im Verzeichnis app bzw. app-ssl unter der aufgeschalteten Domain eine App existiert,
wird dies von Phusion Passenger ausgefürt

Phusion Passenger ist immer für die gesamte aufgeschaltete Domain aktiviert,
die Bereitstellung einer App wirkt also auch auf Subdomains im Verzerichnis 'subs'.
Insbesondere wird damit PHP für die jeweilige Domain deaktiviert.
Statischen Dateien (z.B. index.html) aus htdocs* und subs* sind davon nicht betroffen.
Idealerweise wird daher für jede App eine eigene Subdomain mit HSAdmin aufgeschaltet.

Sobald eine App einmal geladen ist, sind die Settings und Mappings Bestandteil der transienten Apache vhost-Konfiguration.
Änderungen an .htaccess-Settings bzgl. Passenger kommen dann nicht mehr direkt zum Tragen,
weil die .htaccess zu Gunsten der Effizienz dann nicht mehr ausgewertet wird.

Zum deaktivieren einer App muss diese im app und app-ssl Verzeichnis geslöscht werden.

== Konfiguriation / .htaccess ==

Das Plugin ist zwar unabhängig von Einträgen in der .htaccess aktiv,
kann aber über die .htaccess Datei im jeweiligen Domain-Verzeichnis konfiguriert werden,
z.B. in "/home/pacs/xyz00/users/example/doms/example.com/.htaccess":

PassengerNodejs /home/pacs/xyz00/users/example/.nvm/versions/node/v6.11.2/bin/node

(Nähere Informationen bitte den jeweiligen Wiki-Seiten über die spezifischen Laufzeitumgebungen entnehmen.)

== Neueinlesen der Konfiguration / Restart der App ==

Passenger Apps werden wir folgt neu gestartet oder neu geladen:

mkdir app(-ssl)/tmp
touch app(-ssl)/tmp/restart.txt

Das führt nach einer Weile zu einem graceful Restart der App.
D.h. die einzelnen Prozesse werden sukzessive zwischen der Bedienung von HTTP-Requests neu gestartet.
Im Rahmen dieses Restarts sollten geänderte .htaccess Direktiven Wirkung entfalten.
Entsprechendes gilt für Änderungen an der Applikation selbst.

Toast paketmanager

2017-12-01T17:51:34Z

Hsh00-peh: /* Toast Paketmanager */

= Toast Paketmanager =

Toast ist eine große Hilfe, wenn eine Software benötigt wird, die bei Hostsharing nicht installiert wird. Das kann vorkommen,
wenn es die richtige Version nicht in der stabilen Debian-Distribution gibt oder wenn andere Gründe gegen eine zentrale Installation sprechen.

[http://toastball.net/toast/ Toast] ist ein einfacher Paket-Manager, der in der Lage ist Source-Tar-Balls herunterzuladen und im Home-Verzeichnis des Users zu installieren.

Die Installation von Toast ist denkbar einfach:

wget -O- http://toastball.net/toast/toast | perl -x - arm toast

Die folgende Zeile gehört in die Datei ".profile":

eval $($HOME/.toast/armed/bin/toast env)

Eine man-Page findet sich unter [http://toastball.net/toast/man http://toastball.net/toast/man]

== PHP7 gefällig? ==

Mit Toast kein Problem:

toast arm http://de1.php.net/distributions/php-7.1.2.tar.gz

Zum Kompilieren des PHP-Stub für Fast-CGI siehe [[Eigene_PHP_Version]]

----
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]

Eigene PHP Version

2017-12-01T17:01:13Z

Hsh00-peh: MySQL Passworte

Falls Anwendungen nach dem Upgrade auf Jessie übergangsweise eine ältere PHP-Version benötigen, kann im Paket eine
eigene Version compiliert werden.

<pre>
mkdir php54
cd php54
wget http://de1.php.net/distributions/php-5.4.45.tar.gz
</pre>

<pre>
./configure --prefix $HOME/php-5.4.45 --enable-mbstring --with-curl
--with-openssl --with-xmlrpc --enable-soap --enable-zip --with-gd
--with-jpeg-dir --with-png-dir --with-freetype-dir --enable-intl
--with-xsl --with-mysqli=/usr/bin/mysql_config --with-pdo-mysql
--enable-pdo=shared --with-pdo-mysql=shared --with-pdo-sqlite=shared
--with-zlib --with-mysql

make
make install
</pre>

Hardlink:
<pre>
ln php-cgi /home/pacs/xyz00/users/xyz/php-5.4.45/bin/php-cgi
</pre>

oder eine eigenes phpstub, falls ein Hardlink nicht erwünscht ist:

Dazu die Dateien aus /usr/local/src/phpstub in folgendes Verzeichnis
kopieren:

<pre>
php/phpstub
</pre>

in der phpstub.c den folgenden Pfad geändert:

<pre>
execl("/home/pacs/xyz00/php-5.4.45/bin/php-cgi", "php", NULL);
make
</pre>

Die erzeugte phpstub als myphpstub in die entsprechenden Domain
fastcgi[-ssl] Verzeichnisse kopieren.

Weiter die
<pre>
/etc/php5/cgi/php.ini
</pre>

nach ./fastcgi kopiert.

'''ACHTUNG:''' killall php -u $USER wirkt nicht, prozesse mit ps aux kontrolliert und kill

Änderung der .htaccess der entsprechenden Domains
<pre>
AddType application/x-httpd-phpfastcgi .php
Action application/x-httpd-phpfastcgi /fastcgi-bin/myphpstub
</pre>

== Mögliche Probleme mit MySQL-Passwort umgehen ==

Alle hsadmin definierte MySQL-Passworte sind aus Kompatibilitätsgründen als 16-Byte-Zeichenkette gespeichert.
Um das zu umgehen, ändern Sie das Passwort mit MySQL-Mitteln:
<pre>
xyz00@h0x:~$ mysql -u xyz00_mysql -p
Enter password:

mysql> SET SESSION old_passwords=0;
mysql> SET PASSWORD FOR 'xyz00_mysql'@'%' = PASSWORD('geheim');
</pre>

Damit wir das Passwort als 41-Byte-Zeichenkette gespeichert.

ACHTUNG: Nach jeder Änderung mit hsadmin wird wieder ein 16-Byte-Hash gespeichert!

----
[[Kategorie:HSDoku]]
[[Kategorie:Upgrade Wheezy zu Jessie]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]

NodeJS

2017-11-27T14:13:36Z

Hsh00-peh: Update Versions

== Eigene NodeJS Installation ==

Die JavaScript-Umgebung NodeJS für das Ausführen von JavaScript auf dem Server unterliegt noch einer rasanten Entwicklung.
Daher ist die Debian-Version, die bei Hostsharing vorinstalliert ist, oft zu alt für aktuelle Software.

Ein kurze Anleitung für die eigene NodeJS-Installation für einen User.

=== Installation von nvm ===

Heute ist die Version v0.33.6 aktuell, siehe auch https://github.com/creationix/nvm/releases

$ touch ~/.profile
$ chmod u+x ~/.profile
$ cd /tmp
$ wget https://raw.githubusercontent.com/creationix/nvm/v0.33.6/install.sh
$ chmod u+x install.sh
$ ./install.sh

An dieser Stelle ab- und wieder anmelden oder die Befehle ausführen:

$ export NVM_DIR="/home/pacs/xyz00/users/example/.nvm"
$ [ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"

=== Installation von NodeJS ===

Mit dem Befehl

$ nvm install 4
$ nvm alias default 4

läßt sich (zum Beispiel) sehr einfach NodeJS in der Version 4.8.6 (27.11.2017) installieren.

analog für die Version 6.x

$ nvm install 6
$ nvm alias default 6

oder 8.x

$ nvm install 8
$ nvm alias default 8

Der Befehl

$ node -v

gibt die Version von NodeJS aus.

=== NodeJS Web-Applikation ===

Zur Integration der eigenen NodeJS-Installation in den Apache erfolgt über das Apache-Modul "Passenger".
Vor der Nutzung dieses Moduls bitte unbedingt die
[[Phusion Passenger|Hinweise zur Nutzung beachten]].

Den Pfad zum node-Binärprogramm konfiguriert man in einer ".htaccess"-Datei im
Verzeichnis der Domain "/home/pacs/xyz00/users/example/doms/example.com/.htaccess":

PassengerNodejs /home/pacs/xyz00/users/example/.nvm/versions/node/v4.8.6/bin/node

bzw.

PassengerNodejs /home/pacs/xyz00/users/example/.nvm/versions/node/v6.12.0/bin/node

Zum Testen kann man eine "app.js" ins Verzeichnis "/home/pacs/xyz00/users/example/doms/example.com/app-ssl/"
ablegen.

Eine minimale "app.js" zur Anzeige der NodeJS Version:

var http = require("http");
http.createServer(function (request, response) {
response.writeHead(200, {'Content-Type': 'text/plain'});
response.write('node version ' + process.version + '\n');
response.end();
}).listen(3000);

Um diese App zu deaktivieren, muss die Datei gelöscht werden.
Es reicht nicht aus, eine etwaige Konfiguration aus der .htaccess zu entfernen.

=== Weitere Installationen ===

Mit dem "Node Package Manager" npm läßt sich weitere Software in die Node-Umgebung installieren:

$ npm install -g gulp

----
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]

Phusion Passenger

2017-11-27T09:38:18Z

Hsh00-peh: typo

Phusion Passenger ist ein Apache-Plugin zur Integration von Apps auf Domain (vhost) Ebene.
Dabei kann es sich z.B. um [[NodeJS]], [[Etherpad installieren|Etherpad]], [[RubyOnRails]] und weiteren Laufzeitumgebungen handeln.

== Aktivierung / .htaccess ==

Das Plugin kann über die .htaccess Datei im jeweiligen Domain-Verzeichnis aktiviert werden.
Z.B. in "/home/pacs/xyz00/users/example/doms/example.com/.htaccess":

PassengerNodejs /home/pacs/xyz00/users/example/.nvm/versions/node/v6.11.2/bin/node

(Nähere Informationen bitte den jeweiligen Wiki-Seiten über die spezifischen Laufzeitumgebungen entnehmen.)

Die Phusion Passenger Aktivierung erfolgt immer für die gesamte aufgeschaltete Domain,
sie wirkt also auch auf Subdomains im Verzerichnis 'subs'.
Insbesondere wird damit PHP für die jeweilige Domain deaktiviert.
Statischen Dateien (z.B. index.html) aus htdocs* und subs* sind davon nicht betroffen.
Idealerweise wird daher für jede App eine eigene Subdomain mit HSAdmin aufgeschaltet.

Sobald eine App einmal geladen ist, sind die Settings und Mappings Bestandteil der transienten Apache vhost-Konfiguration.
Die .htaccess-Settings bzgl. Passenger kommen dann nicht zum Tragen,
weil die .htaccess zu Gunsten der Effizienz dann nicht mehr ausgewertet wird.

== Neueinlesen der Konfiguration / Restart der App ==

Passenger Apps werden wir folgt neu gestartet oder neu geladen:

mkdir app(-ssl)/tmp
touch app(-ssl)/tmp/restart.txt

Das führt nach einer Weile zu einem graceful Restart der App.
D.h. die einzelnen Prozesse werden sukzessive zwischen der Bedienung von HTTP-Requests neu gestartet.
Im Rahmen dieses Restarts sollten geänderte .htaccess Direktiven Wirkung entfalten.
Entsprechendes gilt für Änderungen an der Applikation selbst.

Joomla installieren

2017-11-20T15:23:00Z

Hsh00-peh: https

= Joomla bei HS =

== Vorbereitungen ==

In ''hsadmin'', zum Beispiel mit ''hsscript'':

''hsadmin''-Shell starten mit:

hsscript -u xyz00 -i
Password: ********

Dann nacheinander anlegen:

* Linux User als Domain-Administrator
* Subdomain ''joomla.hs-example.de''
* MySQL-User
* MySQL Datenbank

xyz00@hsadmin> user.add({set:{name:'xyz00-joomla',password:'geheim',shell:'/bin/bash',comment:'Joomla CMS'}})
xyz00@hsadmin> domain.add({set:{name:'joomla.hs-example.de',user:'xyz00-joomla'}})
xyz00@hsadmin> mysqluser.add({set:{name:'xyz00_joomlauser',password:'geheim'}})
xyz00@hsadmin> mysqldb.add({set:{name:'xyz00_joomladb',owner:'xyz00_joomlauser'}})

== Joomla installieren ==

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

ssh -l xyz00-joomla xyz00.hostsharing.net

Und dann Joomla herunterladen und in den Webspace entpacken:

cd doms/joomla.hs-example.de/htdocs-ssl
rm .htaccess

wget https://downloads.joomla.org/de/cms/joomla3/3-7-4/Joomla_3-7.4-Stable-Full_Package.tar.gz?format=gz
tar xvzf Joomla_3-7.4-Stable-Full_Package.tar.gz\?format\=gz

== Joomla für HS anpassen ==

doms/joomla.hs-example.de/fastcgi

vi php.ini

[PHP]
upload_max_filesize=20M
max_execution_time=300
post_max_size=20M
memory_limit=128M

== Joomla konfigurieren ==

Im Browser auf die Seite
https://joomla.hs-example.de/index.php gehen und den Anweisungen folgen.

[[Datei:Joomla1.jpg]]
[[Datei:Joomla2.jpg]]
[[Datei:Joomla3a.jpg]]
[[Datei:Joomla3b.jpg]]
[[Datei:Joomla4.jpg]]

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Blog]]
[[Kategorie:CMS]]

Joomla installieren

2017-11-20T15:22:21Z

Hsh00-peh: https ist default

= Joomla bei HS =

== Vorbereitungen ==

In ''hsadmin'', zum Beispiel mit ''hsscript'':

''hsadmin''-Shell starten mit:

hsscript -u xyz00 -i
Password: ********

Dann nacheinander anlegen:

* Linux User als Domain-Administrator
* Subdomain ''joomla.hs-example.de''
* MySQL-User
* MySQL Datenbank

xyz00@hsadmin> user.add({set:{name:'xyz00-joomla',password:'geheim',shell:'/bin/bash',comment:'Joomla CMS'}})
xyz00@hsadmin> domain.add({set:{name:'joomla.hs-example.de',user:'xyz00-joomla'}})
xyz00@hsadmin> mysqluser.add({set:{name:'xyz00_joomlauser',password:'geheim'}})
xyz00@hsadmin> mysqldb.add({set:{name:'xyz00_joomladb',owner:'xyz00_joomlauser'}})

== Joomla installieren ==

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

ssh -l xyz00-joomla xyz00.hostsharing.net

Und dann Joomla herunterladen und in den Webspace entpacken:

cd doms/joomla.hs-example.de/htdocs-ssl
rm .htaccess

wget https://downloads.joomla.org/de/cms/joomla3/3-7-4/Joomla_3-7.4-Stable-Full_Package.tar.gz?format=gz
tar xvzf Joomla_3-7.4-Stable-Full_Package.tar.gz\?format\=gz

== Joomla für HS anpassen ==

doms/joomla.hs-example.de/fastcgi

vi php.ini

[PHP]
upload_max_filesize=20M
max_execution_time=300
post_max_size=20M
memory_limit=128M

== Joomla konfigurieren ==

Im Browser auf die Seite
http://joomla.hs-example.de/index.php gehen und den Anweisungen folgen.

[[Datei:Joomla1.jpg]]
[[Datei:Joomla2.jpg]]
[[Datei:Joomla3a.jpg]]
[[Datei:Joomla3b.jpg]]
[[Datei:Joomla4.jpg]]

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Blog]]
[[Kategorie:CMS]]

Diskussion:Mailman Installieren

2017-09-02T17:38:04Z

Hsh00-peh: /* XYZ00 in Versalien? */

Sehr schön; sauberer gegliedert als die Vorversion.

Ein paar Vorschläge dennoch:

"Mailman kann als Paketadmin oder Paketuser installiert werden."

* "Paket-Admin", "Paketadmin": Ich wäre dafür, wir würden überall im Wiki die Schreibweise "Paket-Admin" verwenden. Einfach als konservativer Umgang mit Wortschöpfungen. Andere Meinungen?

* "Paketuser" ist auf der Seite [[User-Arten]] nicht definiert. Sollte es hier wohl "Domain-Admin" heißen?

* Syntax: Strenggenommen kann Mailman nur als Softwareprogramm installiert werden, nicht als Paket-Admin oder als Domain-Admin. Alternativer Satzbau: "Mailman kann vom Paket-Admin oder von einem Domain-Admin installiert werden." Oder: "Mailman kann man als Paket-Admin oder als Domain-Admin installiert werden."

== Verzeichnisstruktur ==

Als Verzeichnisname fuer die Mailman Installation wird in der Anleitung teilweise "mailman" und teilweise "mailman-2.1.12" verwendet. Ist das beabsichtigt? Bin mir nicht sicher, aber ich vermute, dass es einheitlich "mailman-2.1.12" heissen sollte. Z.B.

~$ mkdir -p mailman-2.1.12/var
~$ chmod 02775 mailman-2.1.12/var

statt:
~$ mkdir -p mailman/var
~$ chmod 02775 mailman/var

oder:

~/mailman-2.1.12$ ./configure --prefix=/home/pacs/XYZ00/mailman-2.1.12 \
--with-username=XYZ00 \
--with-groupname=XYZ00 \
--with-var-prefix=/home/pacs/XYZ00/var/mailman-2.1.12 \
--with-cgi-gid=XYZ00 \
--with-mail-gid=nogroup

satt:

~/mailman-2.1.12$ ./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

: Nein, das ist Absicht. Unter "mailman-2.1.12" liegen die entpackten Sourcen, wohingegen nach "mailman" installiert wird. --[[Benutzer:Daz00-daniel|Daz00-daniel]] 13:33, 6. Okt. 2009 (CEST)

== Don't try this at home! ==

Also bitte nicht mehr Mailman als Paketadmin installieren und nicht mehr mittels Aliases die Mails auf Mailman pipen.

Und nicht mehr die E-Mail-Adressen und Aliases auf diese Art einrichten:

hsscript -u xyz00 -i
emailalias.add ({set:{name:'xyz00-listname_ohne_bindestriche',target:'"|/home/pacs/xyz00/mailman/mail/mailman post listname-bindestriche-okay"'}})
emailalias.add ({set:{name:'xyz00-listname_ohne_bindestriche_admin',target:'"|/home/pacs/xyz00/mailman/mail/mailman admin listname-bindestriche-okay"'}})
emailalias.add ({set:{name:'xyz00-listname_ohne_bindestriche_bounce',target:'"|/home/pacs/xyz00/mailman/mail/mailman bounce listname-bindestriche-okay"'}})
emailalias.add ({set:{name:'xyz00-listname_ohne_bindestriche_confirm',target:'"|/home/pacs/xyz00/mailman/mail/mailman confirm listname-bindestriche-okay"'}})
emailalias.add ({set:{name:'xyz00-listname_ohne_bindestriche_join',target:'"|/home/pacs/xyz00/mailman/mail/mailman join listname-bindestriche-okay"'}})
emailalias.add ({set:{name:'xyz00-listname_ohne_bindestriche_leave',target:'"|/home/pacs/xyz00/mailman/mail/mailman leave listname-bindestriche-okay"'}})
emailalias.add ({set:{name:'xyz00-listname_ohne_bindestriche_owner',target:'"|/home/pacs/xyz00/mailman/mail/mailman owner listname-bindestriche-okay"'}})
emailalias.add ({set:{name:'xyz00-listname_ohne_bindestriche_request',target:'"|/home/pacs/xyz00/mailman/mail/mailman request listname-bindestriche-okay"'}})
emailalias.add ({set:{name:'xyz00-listname_ohne_bindestriche_subscribe',target:'"|/home/pacs/xyz00/mailman/mail/mailman subscribe listname-bindestriche-okay"'}})
emailalias.add ({set:{name:'xyz00-listname_ohne_bindestriche_unsubscribe',target:'"|/home/pacs/xyz00/mailman/mail/mailman unsubscribe listname-bindestriche-okay"'}})
emailaddress.add ({set:{domain:'lists.example.com',localpart:'listname-bindestriche-okay',target:'xyz00-listname_ohne_bindestriche'}})
emailaddress.add ({set:{domain:'lists.example.com',localpart:'listname-bindestriche-okay-admin',target:'xyz00-listname_ohne_bindestriche_admin'}})
emailaddress.add ({set:{domain:'lists.example.com',localpart:'listname-bindestriche-okay-bounces',target:'xyz00-listname_ohne_bindestriche_bounces'}})
emailaddress.add ({set:{domain:'lists.example.com',localpart:'listname-bindestriche-okay-confirm',target:'xyz00-listname_ohne_bindestriche_confirm'}})
emailaddress.add ({set:{domain:'lists.example.com',localpart:'listname-bindestriche-okay-join',target:'xyz00-listname_ohne_bindestriche_join'}})
emailaddress.add ({set:{domain:'lists.example.com',localpart:'listname-bindestriche-okay-leave',target:'xyz00-listname_ohne_bindestriche_leave'}})
emailaddress.add ({set:{domain:'lists.example.com',localpart:'listname-bindestriche-okay-owner',target:'xyz00-listname_ohne_bindestriche_owner'}})
emailaddress.add ({set:{domain:'lists.example.com',localpart:'listname-bindestriche-okay-request',target:'xyz00-listname_ohne_bindestriche_request'}})
emailaddress.add ({set:{domain:'lists.example.com',localpart:'listname-bindestriche-okay-subscribe',target:'xyz00-listname_ohne_bindestriche_subscribe'}})
emailaddress.add ({set:{domain:'lists.example.com',localpart:'listname-bindestriche-okay-unsubscribe',target:'xyz00-listname_ohne_bindestriche_unsubscribe'}})

Und dabei nicht die doppelten Anführungszeichen bei dem Alias-Ziel beachten.

Okay? Okay! [[Benutzer:Apc00|Tony Crawford (apc00)]] ([[Benutzer Diskussion:Apc00|Diskussion]]) 15:52, 15. Mär. 2017 (CET)

== XYZ00 in Versalien? ==

Wir schreiben xyz00 im ganzen Wiki klein, nur hier nicht. Das kann doch geändert werden, oder gibt es etwas, das dagegen spricht? --[[Benutzer:Deg00-m.website|ChristofT]] ([[Benutzer Diskussion:Deg00-m.website|Diskussion]]) 12:39, 2. Sep. 2017 (CEST)

Ich denke: Es MUSS klein geschrieben werden, sonst kommt noch jemand auf die Idee, Paket-Nutzer oder -Verzeichnisnamen müssten
gross geschrieben sein. das wäre ein Missverständnis. --[[Benutzer:Hsh00-peh|Peter]] ([[Benutzer Diskussion:Hsh00-peh|Diskussion]]) 19:38, 2. Sep. 2017 (CEST)

NodeJS

2017-08-14T15:32:44Z

Hsh00-peh:

== Eigene NodeJS Installation ==

Die JavaScript-Umgebung NodeJS für das Ausführen von JavaScript auf dem Server unterliegt noch einer rasanten Entwicklung.
Daher ist die Debian-Version, die bei Hostsharing vorinstalliert ist, oft zu alt für aktuelle Software.

Ein kurze Anleitung für die eigene NodeJS-Installation für einen User.

=== Installation von nvm ===

Heute ist die Version v0.33.2 aktuell, siehe auch https://github.com/creationix/nvm/releases

$ touch ~/.profile
$ chmod u+x ~/.profile
$ cd /tmp
$ wget https://raw.githubusercontent.com/creationix/nvm/v0.33.2/install.sh
$ chmod u+x install.sh
$ ./install.sh

An dieser Stelle ab- und wieder anmelden oder die Befehle ausführen:

$ export NVM_DIR="/home/pacs/xyz00/users/example/.nvm"
$ [ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"

=== Installation von NodeJS ===

Mit dem Befehl

$ nvm install 4.8.4
$ nvm alias default 4.8.4

läßt sich (zum Beispiel) sehr einfach NodeJS in der Version 4.8.4 installieren.

analog für die Version 6.11.x

$ nvm install 6.11.2
$ nvm alias default 6.11.2

Der Befehl

$ node -v

gibt die Version von NodeJS aus.

=== NodeJS Web-Applikation ===

Zur Nutzung der eigenen NodeJS-Installation mit mit dem Apache-Modul "Passenger"
konfiguriert man den Pfad zum node-Binärprogramm in einer ".htaccess"-Datei im
Verzeichnis der Domain "/home/pacs/xyz00/users/example/doms/example.com/.htaccess":

PassengerNodejs /home/pacs/xyz00/users/example/.nvm/versions/node/v4.8.4/bin/node

bzw.

PassengerNodejs /home/pacs/xyz00/users/example/.nvm/versions/node/v6.11.2/bin/node

Zum Testen kann man eine "app.js" ins Verzeichnis "/home/pacs/xyz00/users/example/doms/example.com/app-ssl/"
ablegen.

Eine minimale "app.js" zur Anzeige der NodeJS Version:

var http = require("http");
http.createServer(function (request, response) {
response.writeHead(200, {'Content-Type': 'text/plain'});
response.write('node version ' + process.version + '\n');
response.end();
}).listen(3000);

=== Weitere Installationen ===

Mit dem "Node Package Manager" npm läßt sich weitere Software in die Node-Umgebung installieren:

$ npm install -g gulp

----
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]

NodeJS

2017-08-14T15:28:26Z

Hsh00-peh: /* Eigene NodeJS Installation */

== Eigene NodeJS Installation ==

Die JavaScript-Umgebung NodeJS für das Ausführen von JavaScript auf dem Server unterliegt noch einer rasanten Entwicklung.
Daher ist die Debian-Version, die bei Hostsharing vorinstalliert ist, oft zu alt für aktuelle Software.

Ein kurze Anleitung für die eigene NodeJS-Installation für einen User.

=== Installation von nvm ===

Heute ist die Version v0.33.2 aktuell, siehe auch https://github.com/creationix/nvm/releases

$ touch ~/.profile
$ chmod u+x ~/.profile
$ cd /tmp
$ wget https://raw.githubusercontent.com/creationix/nvm/v0.33.2/install.sh
$ chmod u+x install.sh
$ ./install.sh

An dieser Stelle ab- und wieder anmelden oder die Befehle ausführen:

$ export NVM_DIR="/home/pacs/xyz00/users/example/.nvm"
$ [ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"

=== Installation von NodeJS ===

Mit dem Befehl

$ nvm install 4.8.4
$ nvm alias default 4.8.4

läßt sich (zum Beispiel) sehr einfach NodeJS in der Version 4.8.4 installieren.

analog für die Version 6.11.x

$ nvm install 6.11.2
$ nvm alias default 6.11.2

Der Befehl

$ node -v

gibt die Version von NodeJS aus.

=== NodeJS Web-Applikation ===

Zur Nutzung der eigenen NodeJS-Installation mit mit dem Apache-Modul "Passenger"
konfiguriert man den Pfad zum node-Binärprogramm in einer ".htaccess"-Datei im
Verzeichnis der Domain "/home/pacs/xyz00/users/example/doms/example.com/.htaccess":

PassengerNodejs /home/pacs/xyz00/users/example/.nvm/versions/node/v4.8.4/bin/node

bzw.

PassengerNodejs /home/pacs/xyz00/users/example/.nvm/versions/node/v6.11.2/bin/node

Zum Testen kann man eine "app.js" ins Verzeichnis "/home/pacs/xyz00/users/example/doms/example.com/app/"
bzw. "/home/pacs/xyz00/users/example/doms/example.com/app-ss/" ablegen.

Eine minimale "app.js" zur Anzeige der NodeJS Version:

var http = require("http");
http.createServer(function (request, response) {
response.writeHead(200, {'Content-Type': 'text/plain'});
response.write('node version ' + process.version + '\n');
response.end();
}).listen(3000);

=== Weitere Installationen ===

Mit dem "Node Package Manager" npm läßt sich weitere Software in die Node-Umgebung installieren:

$ npm install -g gulp

----
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]

NodeJS

2017-08-14T15:27:08Z

Hsh00-peh: Versionnummern aktualisiert

== Eigene NodeJS Installation ==

Die JavaScript-Umgebung NodeJS für das Ausführen von JavaScript auf dem Server unterliegt noch einer rasanten Entwicklung.
Daher ist die Debian-Version, die bei Hostsharing vorinstalliert ist, oft zu alt für aktuelle Software.

Ein kurze Anleitung für die eigene NodeJS-Installation für einen User.

=== Installation von nvm ===

Heute ist die Version v0.33.2 aktuell, siehe auch https://github.com/creationix/nvm/releases

$ cd /tmp
$ wget https://raw.githubusercontent.com/creationix/nvm/v0.33.2/install.sh
$ chmod u+x install.sh
$ ./install.sh

An dieser Stelle ab- und wieder anmelden oder die Befehle ausführen:

$ export NVM_DIR="/home/pacs/xyz00/users/example/.nvm"
$ [ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"

=== Installation von NodeJS ===

Mit dem Befehl

$ nvm install 4.8.4
$ nvm alias default 4.8.4

läßt sich (zum Beispiel) sehr einfach NodeJS in der Version 4.8.4 installieren.

analog für die Version 6.11.x

$ nvm install 6.11.2
$ nvm alias default 6.11.2

Der Befehl

$ node -v

gibt die Version von NodeJS aus.

=== NodeJS Web-Applikation ===

Zur Nutzung der eigenen NodeJS-Installation mit mit dem Apache-Modul "Passenger"
konfiguriert man den Pfad zum node-Binärprogramm in einer ".htaccess"-Datei im
Verzeichnis der Domain "/home/pacs/xyz00/users/example/doms/example.com/.htaccess":

PassengerNodejs /home/pacs/xyz00/users/example/.nvm/versions/node/v4.8.4/bin/node

bzw.

PassengerNodejs /home/pacs/xyz00/users/example/.nvm/versions/node/v6.11.2/bin/node

Zum Testen kann man eine "app.js" ins Verzeichnis "/home/pacs/xyz00/users/example/doms/example.com/app/"
bzw. "/home/pacs/xyz00/users/example/doms/example.com/app-ss/" ablegen.

Eine minimale "app.js" zur Anzeige der NodeJS Version:

var http = require("http");
http.createServer(function (request, response) {
response.writeHead(200, {'Content-Type': 'text/plain'});
response.write('node version ' + process.version + '\n');
response.end();
}).listen(3000);

=== Weitere Installationen ===

Mit dem "Node Package Manager" npm läßt sich weitere Software in die Node-Umgebung installieren:

$ npm install -g gulp

----
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]

Hauptseite

2017-07-06T14:35:50Z

Hsh00-peh: /* Willkommen im Hostsharing-Wiki! */

{{HSDoku-Links}} __NOTOC__

== Willkommen im Hostsharing-Wiki! ==
... der '''inoffiziellen''' Dokumentation der Mitglieder von Hostsharing. Die wichtigsten Themen findest du in der Leiste oben. Alle Themen und Seiten des Wiki erreichst du am besten über die Kategorie [[:Kategorie:HSDoku|HSDoku]].

Die '''offizielle''' Kerndokumentation ist unter:
https://doc.hostsharing.net/users/

Allgemeine Fragen zum Umgang mit den HS Diensten und Angeboten beantwortet die HS Community in der [https://lists.hostsharing.net/mailman/listinfo/support Support Mailingliste] mit der Mailadresse [mailto:support@hostsharing.net support@hostsharing.net]. Fragen, die vertrauliche Themen behandeln (Domainnamen, Benutzernamen, Passwörter etc.) sollten direkt an den [[HS-Service]] gehen, der ansonsten kostenpflichtig ist. Ergänzende Hinweise finden sich in den [https://lists.hostsharing.net/archiv/global-announce/ Global Announces] der Hostmaster und des Vorstandes zu aktuellen Geschehnissen und technischen Änderungen bei Hostsharing.

Du kannst dich mit deinen HS Userdaten einloggen und mithelfen, die Dokumentation zu verbessern. In unserem [[Autorenportal]] findest du Hinweise dazu, wie du dich beteiligen kannst. Was hier ins Wiki gehört, und wie es gemacht wird, ist unter [[Hilfe:Hostsharing_Wiki_Konventionen|Konventionen]] erklärt.

Zum Testen und Rumspielen ist der [[Sandkasten]] da. Und nun viel Freude im Hostsharing Wiki :-)

== Hostsharing Benefits ==

Hostsharing.net ist die professionelle Alternative zur Administration eigener Root Server mit dem Bonus der Redundanz und des gemeinschaftlich organisierten Betriebes:

[[10 Missverständnisse über dedizierte root-Server | Rootserver Missverständnisse]]<br>
[[Rootserver Checkliste]]

----
[[Kategorie:Hostsharing Wiki]]
[[Kategorie:HSDoku]]

Diskussion:TLS mit Let's Encrypt Zertifikat

2017-07-06T13:52:59Z

Hsh00-peh: Antworten an has

Ahoi Peter, sehe schön! Habe die Seite kategorisiert, verschoben zu [[TLS mit Let's Encrypt Zertifikat]] und einen Hinweis auf [[TLS_/_SSL]] gelegt. --[[Benutzer:Deg00-m.website|ChristofT]] ([[Benutzer Diskussion:Deg00-m.website|Diskussion]]) 19:51, 29. Jun. 2017 (CEST)

Die Redirects in den .htaccess Dateien sollten noch erwähnt werden.

Außerdem <del>muss</del> kann man den Ordner www in subs löschen <del>und</del> oder eine .htaccess mit Redirect hineinlegen, wenn man https erzwingen will.

Wenn man das nicht will, stellt sich das Problem bei statischen Seiten, dass in subs/www und subs-ssl/www der gleiche Inhalt vorhanden sein muss. Geht das durch einen Link oder muss man richtig kopieren?
* Link geht, aber Google straft "Duplicate Content" ab, daher besser ein Redirect --[[Benutzer:Hsh00-peh|Peter]] ([[Benutzer Diskussion:Hsh00-peh|Diskussion]]) 15:52, 6. Jul. 2017 (CEST)

Irgendwie muss man auch aufpassen, dass man die vielen .htaccess-Dateien noch überblickt.
* Daher subs/www löschen und zwei .htaccess in htdocs und htdocs-ssl, wenn man die www-Subdomain nutzen möchte --[[Benutzer:Hsh00-peh|Peter]] ([[Benutzer Diskussion:Hsh00-peh|Diskussion]]) 15:52, 6. Jul. 2017 (CEST)

[[Benutzer:Has00|Has00]] ([[Benutzer Diskussion:Has00|Diskussion]]) 08:19, 6. Jul. 2017 (CEST)

Diskussion:TLS / SSL

2017-07-06T13:44:03Z

Hsh00-peh:

Ungeprüft aus alter Dokumentation übernommen. --[[Benutzer:Jrs00-wiki|Jrs00-wiki]] 22:48, 17. Mär. 2009 (UTC)

Habe formatiert und Baustelle entfernt. Wenn Fehler entdeckt werden, können die ja korrigiert werden. Aber so lange da niemend welche entdeckt, sollte es ok sein. --[[Benutzer:Deg00-m.website|ChristofT]] 22:42, 1. Jun. 2009 (UTC)

Baustelle aktiviert:

Da laut Michael Hierweck:
P.S. In dem Dokument stehen einige fragwürdige Dinge. Bitte wieder auf
Baustelle setzen. Leider haben wir ja für die Doku keine Qualitätssicherung.
--[[Benutzer:Chg00-hsdoku|Chg00-hsdoku]] 23:55, 23. Jan. 2010 (CET)

== Überarbeitung ==

Dringend erforderlich da laut Michael Hierweck div Sachen einfach falsch sind.

--[[Benutzer:Chg00-hsdoku|Christian Günter]] 22:16, 13. Apr. 2011 (CEST)

== Warte auf Rückmeldung ==

Hallo Michael,
kannst du Inhaltlich prüfen ob wir die Seite so nun wieder frei gebe können !

--[[Benutzer:Chg00-hsdoku|Christian Günter]] ([[Benutzer Diskussion:Chg00-hsdoku|Diskussion]]) 10:25, 9. Jul. 2012 (CEST)

Kkeine Fehler Rückmeldug erhalten.
Inhaltlich korrekt wenn auch ggf noch nicht ganz verständlich geschrieben.
Da die Seite bald druch die KernDoku ersetzt wurde die Baustelle entfernt.

--[[Benutzer:Chg00-hsdoku|Christian Günter]] ([[Benutzer Diskussion:Chg00-hsdoku|Diskussion]]) 14:24, 27. Aug. 2012 (CEST)

== SSL-Zertifikate von Let’s Encrypt ==

Da steht jetzt im roten Block:

Das Feature wird bei Hostsharing im Juli 2017 per HSAdmin automatisiert. Die neuen Vorgehensweisen sind in TLS mit Let's Encrypt Zertifikat beschrieben. Für Dokumentationszwecke bleibt dieser Passus weiterhin erhalten. Insgesamt sollte aber stets das neue Verfahren verwendet werden.

Sollen wir das alles löschen oder lassen wir das "Für Dokumentationszwecke" stehen? Ich bin eigentlich für Löschen --[[Benutzer:Deg00-m.website|ChristofT]] ([[Benutzer Diskussion:Deg00-m.website|Diskussion]]) 23:08, 5. Jul. 2017 (CEST)

unbedingt löschen! --[[Benutzer:Hsh00-peh|Peter]] ([[Benutzer Diskussion:Hsh00-peh|Diskussion]]) 15:44, 6. Jul. 2017 (CEST)

TLS mit Let's Encrypt Zertifikat

2017-07-05T15:09:51Z

Hsh00-peh: ist freigegeben

'''Let's Encrypt''' ("Laßt uns verschlüsselt") ist eine Zertifizierungsstelle für X509 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.

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

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

Leichtgewichtige Subdomain

2017-06-30T17:37:48Z

Hsh00-peh: eigener User pro (Sub-)Domain mit Anwendung

Eine Subdomains bei Hostsharing wird "leichtgewichtig" genannt, wenn sie durch ein Unterverzeichnis von ~/doms/example.com/subs/ definiert wurde. Dies ist die einfachste Art und Weise, Subdomains zu erstellen, das Verfahren bringt jedoch Nachteile mit sich, wenn der Zugang per [[:Kategorie:Https|Https]] verschlüsselt werden soll.

"Leichtgewichtige Subdomains" sollten nur verwendet werden, wenn eine einzelne Anwendung zur Verwaltung aller dieser Subdomains verwendet wird. Das kann zum Beispiel ein CMS oder eine Multisite-Wordpress-Installation sein.

Wenn unterschiedliche Anwendungen unter Subdomains betrieben werden, sollte
* für jede Subdomain ein eigener User angelegt werden
* und jede Subdomain jeweils beim eigenen User [[Aufschaltung | aufgeschaltet]] sein.

Siehe [[Domainverwaltung#Lokale_Subdomains_durch_Unterverzeichnis_in_doms.2Fdomain.2Fsubs.2F|Domainverwaltung]].

[[Kategorie:HSDoku]]
[[Kategorie:Domains]]
[[Kategorie:Glossar]]

WWW

2017-06-30T17:27:21Z

Hsh00-peh: /* Abbildung von http(s)-Requests auf das Dateisystem */

{{HSDoku-Links}}

Diese Seite gibt Hinweise zur Konfiguration des Webservers und beschreibt Einstellungen, die typischerweise an eigene Bedürfnisse angepasst werden.

== Einstellungen zum HTTP Zugriff ==
Mit .htaccess Dateien können innerhalb der Domainverzeichnisse z.B. Verzeichnisschutz, Filelistings und Umleitungen (Redirects/Rewrites) des Apache Webservers eingestellt werden. Die Konfiguration wird auf der Seite [[.htaccess]] beschrieben.

=== Abbildung von http(s)-Requests auf das Dateisystem<span id="subs"></span> ===
* http(s)-Requests auf example.com werden auf das Verzeichnis ~/doms/example.com/htdocs(-ssl) geroutet. Standardmäßig ist im Verzeichnis ~/doms/example.com/htdocs(-ssl) eine .htaccess-Datei hinterlegt, welche beim Zugriff auf http(s)://example.com eine Weiterleitung auf http(s)://www.example.com auslöst.

* http(s)-Requests auf www.example.com werden auf das Verzeichnis ~/doms/example.com/subs(-ssl)/www geroutet, sofern dieses existiert.

Ansonsten werden diese Requests ebenfalls auf das Verzeichnis ~/doms/example.com/htdocs(-ssl) geroutet. Hierbei gilt www lediglich als
Standardbeispiel, es sind beliebige Subdomainnamen verwendbar. Dies sind sogenannte [[Leichtgewichtige Subdomain|leichtgewichtige Subdomains]].

Für [[Aufschaltung|aufgeschaltete Subdomains]] gilt das oben beschriebene analog. Sie werden intern wie eigene Domains behandelt. Die Subdomain (z.b. sub.example.com) tritt dann an die Stelle von example.com.

=== Anwendungsbeispiel ===
Alle Requests auf Subdomains, für die kein passendes Verzeichnis unterhalb von subs(-ssl) existiert, werden auf htdocs(-ssl) geroutet.

Löscht man nun die Weiterleitung aus dem Verzeichnis htdocs(-ssl) und installiert eine subdomainfähige Webanwendung, etwa gängige Content-Management-Systeme oder Blogs, in htdocs(-ssl) und löscht zudem subs(-ssl)/www, so kann die Webanwendung die Subdomains selbstständig verwalten. Das Einrichten neuer Subdomains innerhalb der Webanwendung erfordert dann keinen Eingriff in die Verzeichnisstrukturen mehr.

== https / SSL / TLS ==
"Secure Socket Layer": Die Nutzung von verschlüsselten https:// Verbindungen und Sicherheitszertifikaten wird auf der Seite [[TLS_/_SSL|SSL]] beschrieben.

== PHP Ausführung ==
PHP Skripte (.php Dateien) werden beim http Zugriff standardmäßig ausgeführt. PHP kann jedoch (und muss oft) an individuelle Bedürfnisse angepasst werden. Die Konfiguration wird auf der Seite [[PHP]] beschrieben.

== Einstellen des im HTTP Header angegebenen Zeichensatzes ==
Die HS Systeme bieten volle Unterstützung für den universellen UTF Zeichensatz. Der Standard Zeichensatz, den der Apache Webserver im Header angibt, ist jedoch auf iso-8859-1 eingestellt. So funktionieren bestehende Webseiten, die im ISO Zeichensatz erstellt wurden, auch weiterhin ohne Modifikation.

Bei neuen Webseiten empfiehlt es sich, diese im UTF-8 Zeichensatz zu speichern, bzw. ist UTF-8 auf modernen Systemen ohnehin der Standardzeichensatz. Damit Webbrowser beim Abbruf von UTF-8-Seiten vom HS Server auch den korrekten UTF-8 Zeichensatz verwenden, muss jedoch entsprechend die Zeichensatzangabe im Header des Apache Webservers auf UTF-8 gestellt werden.

Für .htm(l) und .php Dateien kann dies in der [[.htaccess]] Datei mit Kombination in der php.ini siehe [[PHP|PHP Konfiguration]] eingestellt werden.

== CGI ==
"Common Gateway Interface": Was CGI Scripte sind und wie man sie auf unserem Server ausführen kann steht auf der Seite [[CGI]].

== Überwachung der HS-Dienste ==
Der Status der HS-Server, und damit auch der Status der eigenen Webseiten, wird von außen überwacht und ist unter [[Überwachung der HS-Dienste]] beschrieben.

== robots.txt ==

Die optionale Datei robots.txt dient der Steuerung der Indizierung der Webseiten einer Domain durch Suchmaschinen. Die Datei kann Steuerbefehle für die Robots enthalten, mit denen die Suchmaschinen Webseiten nach Informationen "abgrasen".

'''Achtung: Fehlerhafte oder so nicht gewollte Einträge können dafür sorgen, dass die Webseiten von den Suchmaschinen nicht mehr indiziert werden, also auch nicht mehr mit Suchmaschinen gefunden werden können!'''

Eine [http://http://www.robotstxt.org/ robots.txt]-Datei muss um Wurzelverzeichnis der veröffentlichten Website
abrufbar sein. Wenn die Website unter http://www.example.com erreichbar ist, muss
der Aufruf von http://www.example.com/robots.txt den Inhalt eben dieser Datei liefern.

Bei Hostsharing muss man sie also in den obersten Ordner der jeweiligen Website legen, für die Domain http://www.example.com in unserem Beispiel als [[Domain-Admin]] in den Ordner ~/doms/example.com/subs/www, wenn die Standardeinstellungen verwendet werden.
----
[[Kategorie:HSDoku]]
[[Kategorie:WWW]]

TLS mit Let's Encrypt Zertifikat

2017-06-29T15:58:50Z

Hsh00-peh: /* Let's Encrypt bei Hostsharing */

{{Baustelle}}

{{Textkasten|rot|Achtung:|Das Feature wird bei Hostsharing im Juli 2017 aktiviert.}}

'''Let's Encrypt''' ("Laßt uns verschlüsselt") ist eine Zertifizierungsstelle für X509 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.

=== Weitere Subdomains ===

Hostsharing-Nutzer kennen bisher leichtgewichtige Subdomains, die sich nur durch das Anlegen eines weiteren
Verzeichnisses im gleichen Domain-Verzeichnis 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.

Aus diesem Grund ist in unserer Administration-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.

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 deaktiviert
werden. Für HTTP mit TLS-Verschlüsselung muss ein kostenpflichtiges Wildcard-Zertifikat einer anderen Zertifizierungsstelle
installiert werden. Dabei unterstützt der 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.

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