Hostsharing Wiki - Benutzerbeiträge [de]

Gitea

2020-11-15T16:02:44Z

Hsh-michaelhoennig: keyserver keys.gnupg.net und @reboot für gitea selbst

== Gitea installieren ==

[https://gitea.io/en-us/ Gitea] ist ein einfacher, selbst gehosteter Git-Service wie GitHub oder GitLab. Die Software ist ein Fork von Gogs und ebenfalls in der Programmiersprache Go geschrieben. Gitea benötigt wenig Ressourcen. Um Gitea auf der Hostsharing Plattform nutzen zu können, benötigt man entweder einen Managed Server oder man muss für seinen Managed Webspace einen Daemon hinzubuchen.

Gitea unterstützt verschiedene Datenbanken. Wir gehen in dieser Anleitung davon aus, dass PostgreSQL benutzt wird.

=== Vorbereitung der Installation ===

Um Gitea auf der Managed Operation Platform von Hostsharing zu installieren, ist folgende Vorbereitung erforderlich.

1. Anlegen eines Domain-Benutzers. In unserem Beispiel <code>xyz00-gitea</code>.

2. Anlegen einer Domain. In unserem Beispiel <code>gitea.hs-example.de</code>.

3. Anlegen eines Datenbank-Benutzers. Hier <code>xyz00_giteadbuser</code>.

4. Anlegen einer Datenbank. Hier <code>xyz00_giteadb</code>.

Auf der Kommandozeile kann man dies folgendermaßen erledigen.

Man loggt sich als Paketbenutzer ein und startet die Kommandozeilenversion von HSAdmin mit dem Befehl <code>hsscript</code>:

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

Anschließend kann man die Vorbereitungsschritte 1 bis 4 erledigen:

xyz00@hsadmin> user.add({set:{name:'xyz00-gitea',password:'geheim',shell:'/bin/bash'}})
xyz00@hsadmin> domain.add({set:{name:'gitea.hs-example.de',user:'xyz00-gitea'}})
xyz00@hsadmin> postgresqluser.add({set:{name:'xyz00_giteadbuser',password:'geheim'}})
xyz00@hsadmin> postgresqldb.add({set:{name:'xyz00_giteadb',owner:'xyz00_giteadbuser'}})

=== Installation von Gitea ===

Gitea wird als Binary zur Verfügung gestellt.
Wir installieren das Binary im Verzeichnis des Domain-Benutzers.
Wenn wir als Paketbenutzer eingeloggt sind, können wir den Benutzer folgendermaßen wechseln:

sudo -u xyz00-gitea -i

Nun laden wir das passende Binary herunter.
Auf der Website https://dl.gitea.io/gitea/ finden Sie das jeweils aktuelle Binary (hier die 64-Bit-Version,
für die shared Server h01 bis h08 bitte die 32-Bit-Version gitea-1.7.0-linux-i386 herunterladen).

wget -O gitea https://dl.gitea.io/gitea/1.7.0/gitea-1.7.0-linux-amd64
chmod +x gitea

Wir laden die GPG-Signatur herunter und überprüfen sie:

wget https://dl.gitea.io/gitea/1.7.0/gitea-1.7.0-linux-amd64.asc
gpg --keyserver keys.gnupg.net --recv 7C9E68152594688862D62AF62D9AE806EC1592E2
gpg --verify gitea-1.7.0-linux-amd64.asc gitea

Nun können wir Gitea testweise starten:

./gitea web

Der Webserver von Gitea startet auf dem Port 3000. Das werden wir später ändern.

Der Server kann mit Ctrl-C beendet werden.

=== Konfiguration der Domain ===

Zunächst wechseln wir in das Verzeichnis <code>doms/gitea.hs-example.de</code> und löschen den Ordner für die Subdomain 'www':

rm -rf subs/www
rm -rf subs-ssl/www

Anschließend tragen wir die Umleitung auf HTTPS ein, falls dies nicht schon geschehen ist.

vi htdocs/.htaccess

Der Eintrag muss lauten:

Redirect permanent / https://gitea.hs-example.com/

Dann legen wir die Datei <code>htdocs-ssl/.htaccess</code> mit folgendem Inhalt an:

DirectoryIndex disabled
RewriteEngine on
RewriteBase /
RewriteRule ^(.*) http://localhost:31580/$1 [proxy,last]

Merken Sie sich die Portnummer 31580.
Sie wird später bei der Konfiguration von Gitea gebraucht.
Die Portnummer bekommen Sie vom Hostmaster, wenn Sie für Ihren Webspace einen Serverdienst (Daemon) buchen.
Wenn Sie einen Managed Server haben, können Sie selbst die Portnummer auswählen.

Damit ist die Konfiguration von Apache abgeschlossen.

=== Konfiguration von Gitea ===

Wir editieren nun die Konfigurationsdatei von Gitea <code>app.ini</code>.
Sie befindet sich in dem Verzeichnis <code>~/custom/conf</code>.

'''ACHTUNG''': Sie können die Konfiguration teilweise auch über das Webinterface durchführen. Starten Sie dazu Gitea, wie oben beschrieben, und versuchen Sie einen Benutzer zu registrieren. Daraufhin öffnet sich der Konfigurationsdialog. Sie müssen den Gitea-Benutzer, den Namen der Datenbank, den Datenbank-Benutzer und sein Passwort parat haben.

Die Konfigurationsdatei beginnt mit allgemeinen Einträgen:

APP_NAME = Gitea: Git with a cup of tea
RUN_USER = xyz00-gitea
RUN_MODE = prod

Im Abschnitt [database] folgen die Angaben zur Datenbank:

[database]
DB_TYPE = postgres
HOST = 127.0.0.1:5432
NAME = xyz00_giteadb
USER = xyz00_giteadbuser
PASSWD = geheim
SSL_MODE = disable
PATH = data/gitea.db

Es folgt der Pfad zu den Git-Repositorys und die Server-Konfiguration:

[repository]
ROOT = /home/pacs/xyz00/users/gitea/gitea-repositories

[server]
PROTOCOL = http
SSH_DOMAIN = gitea.hs-example.de
DOMAIN = gitea.hs-example.de
HTTP_ADDR = localhost
HTTP_PORT = 31580
ROOT_URL = https://gitea.hs-example.de/
DISABLE_SSH = false
SSH_PORT = 22
LFS_START_SERVER = true

Sie können nun Gitea starten:

./gitea web

Der Git-Service ist dann im Browser unter der Adresse gitea.hs-example.de erreichbar.

=== Start- und Stopp-Skripte einrichten ===

Zum Schluss müssen Sie noch Start- und Stoppskripte einrichten und Monit konfigurieren.

Das Startskript speichern Sie unter dem Pfad <code>~/bin/gitea-start.sh</code> ab.
Es hat folgenden Inhalt:

#!/bin/bash
export HOME=/home/pacs/xyz00/users/gitea
export PATH=$HOME/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
export PID=$HOME/.gitea.pid
cd $HOME
exec $HOME/gitea web >$HOME/custom/logs/gitea.log 2>&1 &
echo $! > $PID

Das Stoppskript speichern Sie unter dem Pfad <code>~/bin/gitea-stop.sh</code> an.
Es hat folgenden Inhalt:

#!/bin/bash
export HOME=/home/pacs/xyz00/users/gitea
export PATH=$HOME/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
export PID=$HOME/.gitea.pid
cd $HOME

if [ -f $PID ] ; then
kill $( cat $PID );
sleep 20 ;
kill -9 $( cat $PID ) >/dev/null 2>&1 ;
rm $PID ;
fi

Monit ist ein Programm zur Überwachung eines Servers oder eines Dienstes.
Das Programm erwartet im Verzeichnis des Domain-Benutzers die Datei <code>~/.monitrc</code> mit der entsprechenden Konfiguration.
Legen Sie die Datei mit folgendem Inhalt an:

set daemon 600
set logfile /home/pacs/xyz00/users/gitea/custom/logs/monit.log
set mailserver localhost
set alert webmaster@gitea.hs-example.de
#
check process gitead with pidfile /home/pacs/xyz00/users/gitea/.gitea.pid
start program "/home/pacs/xyz00/users/gitea/bin/gitea-start.sh"
stop program "/home/pacs/xyz00/users/gitea/bin/gitea-stop.sh"

Nun können Sie noch die Rotation der Logfiles konfigurieren.
Dies geschieht in der Datei <code>~/.logrotate</code>:

/home/pacs/xyz00/users/gitea/custom/logs/gitea.log {
copytruncate
daily
rotate 7
compress
missingok
}
/home/pacs/xyz00/users/gitea/custom/logs/monit.log {
copytruncate
monthly
rotate 2
compress
missingok
}

Damit gitea auch nach einem Server-Neustart neu gestartet wird und auch die Konfiguration für logrotate und monit eingelesen werden, müssen Sie folgenden Eintrag in der crontab der Domain-Benutzers machen:

# m h dom mon dow command
HOME=/home/pacs/xyz00/users/gitea
PATH=$HOME/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
PID=$HOME/.gitea.pid
@reboot /usr/bin/monit -c $HOME/.monitrc > /dev/null
@reboot $HOME/gitea-start.sh
51 1 * * * /usr/sbin/logrotate -s $HOME/.logrotate.state $HOME/.logrotate

Wichtig sind die @reboot-Einträge, die automatisch nach einem Neustart des Hosts ausgeführt werden.
Die Uhrzeit für die Logrotation können Sie beliebig einstellen.

Abschließend können Sie Ihre Gitea-Instanz starten:

~/bin/gitea-start.sh

NodeJS

2017-11-27T15:24:05Z

Hsh-michaelhoennig: /* Binärinstallation */ Fehlermeldung"libstdc++.so.6: cannot open shared object file" hinzugefügt, auch für die Suche

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

Bitte auf die bei der Installation ausgegebenen Zeilen am Ende achten,
denn neuere nvm-Versionen benötigen ggf. etwas andere Schritte zur sofortigen Aktivierung.

=== Installation von NodeJS ===

Zunächst prüfen, ob ein 32bit oder 64bit Linux auf dem jeweiligen Hostsharing-Host installiert ist:

dpkg --print-architecture

==== Binärinstallation ====

Diese Variante funktioniert bei Hostsharing nur auf amd64 Systemen (64bit Linux auf 64bit CPU).

$ nvm install 4
$ nvm alias default 4

installiert (zum Beispiel) sehr einfach NodeJS in der Version 4.8.6 (27.11.2017).

analog für die Version 6.x:

$ nvm install 6
$ nvm alias default 6

Hinweis: Auf i386 Systemen würde von nvn immer ein 64bit Node installiert werden,
das führt dann zu der Fehlermeldung: "libstdc++.so.6: cannot open shared object file".

==== Soucecode-basierte Installation auf einem 32bit Linux ====

Diese Variante funktioniert sowohl auf amd64 als auch auf i386 Systemen (32bit Linux auf 64bit CPU).

$ nvm install -s 8.9.1 --dest-cpu=ia32
$ nvm alias default 8.9.1

Die Sourcecode-basierte Installation benötigt temporär sehr viel Speicherplatz und bis zu 1 Stunde für Downloads und Kompilation.
Der Speicherplatz kann nach Fertigstellung wieder freigegeben werden, z.B.:

$ rm -r ~/.node ~/.nvm/.cache/src/node-v8.9.1

==== Überprüfung der Installation ====

Der Befehl

$ node -v

gibt die Version des aktiven 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]]

NodeJS

2017-11-27T14:54:47Z

Hsh-michaelhoennig: Überschriftenstruktur verbessert

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

Bitte auf die bei der Installation ausgegebenen Zeilen am Ende achten,
denn neuere nvm-Versionen benötigen ggf. etwas andere Schritte zur sofortigen Aktivierung.

=== Installation von NodeJS ===

Zunächst prüfen, ob ein 32bit oder 64bit Linux auf dem jeweiligen Hostsharing-Host installiert ist:

dpkg --print-architecture

==== Binärinstallation ====

Diese Variante funktioniert bei Hostsharing nur auf amd64 Systemen (64bit Linux auf 64bit CPU).

$ nvm install 4
$ nvm alias default 4

installiert (zum Beispiel) sehr einfach NodeJS in der Version 4.8.6 (27.11.2017).

analog für die Version 6.x:

$ nvm install 6
$ nvm alias default 6

==== Soucecode-basierte Installation auf einem 32bit Linux ====

Diese Variante funktioniert sowohl auf amd64 als auch auf i386 Systemen (32bit Linux auf 64bit CPU).

$ nvm install -s 8.9.1 --dest-cpu=ia32
$ nvm alias default 8.9.1

Die Sourcecode-basierte Installation benötigt temporär sehr viel Speicherplatz und bis zu 1 Stunde für Downloads und Kompilation.
Der Speicherplatz kann nach Fertigstellung wieder freigegeben werden, z.B.:

$ rm -r ~/.node ~/.nvm/.cache/src/node-v8.9.1

==== Überprüfung der Installation ====

Der Befehl

$ node -v

gibt die Version des aktiven 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-27T14:41:02Z

Hsh-michaelhoennig: /* Konfiguriation / .htaccess */

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

NodeJS

2017-11-27T14:35:14Z

Hsh-michaelhoennig: /* Installation von NodeJS */ Sourcecode-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.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"

Bitte auf die bei der Installation ausgegebenen Zeilen am Ende achten,
denn neuere nvm-Versionen benötigen ggf. etwas andere Schritte zur sofortigen Aktivierung.

=== Installation von NodeJS ===

Zunächst prüfen, ob ein 32bit oder 64bit Linux auf dem jeweiligen Hostsharing-Host installiert ist:

dpkg --print-architecture

=== i386 ===

Es sind nur Sourcecode-basierte Installationen möglich, weil nvm offensichtlich nur die 64bit CPU sieht, nicht aber, dass nur ein 32bit Linux läuft.

=== amd64 ===

Es können auch Binärinstallationen (vorkompiliertes Node) verwendet werden.

=== Binärinstallation ===

$ nvm install 4
$ nvm alias default 4

installiert (zum Beispiel) sehr einfach NodeJS in der Version 4.8.6 (27.11.2017).

analog für die Version 6.x:

$ nvm install 6
$ nvm alias default 6

=== Soucecode-basierte Installation auf einem 32bit Linux ===

$ nvm install -s 8.9.1 --dest-cpu=ia32
$ nvm alias default 8.9.1

Die Sourcecode-basierte Installation benötigt temporär sehr viel Speicherplatz und bis zu 1 Stunde für Downloads und Kompilation.
Der Speicherplatz kann nach Fertigstellung wieder freigegeben werden, z.B.:

$ rm -r ~/.node ~/.nvm/.cache/src/node-v8.9.1

=== Sonstiges ===

Der Befehl

$ node -v

gibt die Version des aktiven 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]]

NodeJS

2017-11-27T14:23:03Z

Hsh-michaelhoennig: /* Installation von nvm */ sofortige Aktivierung bei neueren nvm Versionen

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

Bitte auf die bei der Installation ausgegebenen Zeilen am Ende achten,
denn neuere nvm-Versionen benötigen ggf. etwas andere Schritte zur sofortigen Aktivierung.

=== 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-27T14:09:47Z

Hsh-michaelhoennig: /* Konfiguriation */

Phusion Passenger

2017-11-27T14:09:38Z

Hsh-michaelhoennig: /* Aktivierung / .htaccess */

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

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

2017-11-27T14:09:13Z

Hsh-michaelhoennig: Korrektur bzgl. Aktivierung von Phusion Passenger

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

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

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.

NodeJS

2017-11-27T14:02:48Z

Hsh-michaelhoennig: /* NodeJS Web-Applikation */ Hinweis: zum app deaktivieren: löschen

RadicaleCalDAVServer

2017-11-27T08:25:52Z

Hsh-michaelhoennig: /* Passenger Konfiguration */ Phusuon Passenger Link

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

Etherpad Installieren

2017-11-27T08:25:04Z

Hsh-michaelhoennig: /* Konfiguration für Apache und Passenger */ Link auf Phusion Passenger

= Etherpad Lite installieren =

Etherpad ist eine JavaScript-Anwendung mit der mehrere Bearbeiter gleichzeitig einen Text im Browser editieren können.

Mit Hilfe von Etherpad können zum Beispiel die Teilnehmer einer Telefonkonferenz gemeinsam an einem Text-Dokument arbeiten.

== Vorbereitung ==

Als Paket-Admin ''xyz00'' werden mit HSAdmin ein User angelegt und eine Domain aufgeschaltet. Eine produktive Installation von Etherpad braucht zusätzlich einen MySQL-User und eine MySQL-Datenbank.

Mit ''hsscript'' können diese Ressourcen wie folgt angelegt werden:

Als Paketadmin ''xyz00'' aufrufen:<pre>hsscript -i</pre>

In der HSAdmin-Shell gibt man dann ein:

<pre>
xyz00@hsadmin> user.add({set:{name:'xyz00-pad', password:'mein-Geheimwort', shell:'/bin/bash'}})
xyz00@hsadmin> domain.add({set:{name:'pad.example.com', user:'xyz00-pad'}})
xyz00@hsadmin> mysqluser.add({set:{name:'xyz00_padusr', password:'anderes-Geheimwort'}})
xyz00@hsadmin> mysqldb.add({set:{name:'xyz00_paddb', owner:'xyz00_padusr'}})
xyz00@hsadmin> bye
</pre>

== Installation ==

Als Paketadmin ''xyz00'' nimmt man mit <pre>sudo -u xyz00-pad -i</pre> die Rechte des Domain-Administrators ''xyz00-pad'' für die neue Domain ''pad.example.com'' an.

Die Etherpad-Software kann aus dem Git-Repository bei Github ausgecheckt werden:

<pre>
cd
git clone https://github.com/ether/etherpad-lite.git
cd etherpad-lite/
git tag -l
git checkout tags/1.6.1
./bin/run.sh
</pre>

Mit "git checkout tags/1.6.1" wird Release 1.6.1 ausgecheckt, die heute (11.02.2017) aktuelle Version.

Bei der Initialisierung der Anwendung gibt es einige Warnungen, die man ignorieren kann. Wenn die Initialisierung durchgelaufen ist, kann man
unter der URL http://xyz00.hostsharing.net:9001/ schon die die Etherpad-Anwendung ohne Datenbank und ohne die gewünschte Domain sehen.

Wir brechen das ''run.sh''-Skript mit Ctrl-c ab.

== Konfiguration für Apache und Passenger ==

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

Die statischen Dateien der Anwendung werden mit den folgenden Befehlen richtig verlinkt
(immer noch als User ''xyz00-pad''):

<pre>
cd
cd ~/doms/pad.example.com
rm -rf htdocs
rm -rf htdocs-ssl
ln -s ~/etherpad-lite/src/static htdocs
ln -s ~/etherpad-lite/src/static htdocs-ssl
</pre>

Für die Anwendung legen wir in den Verzeichnissen ''~/doms/pad.example.com/app/'' und ''~/doms/pad.example.com/app-ssl/'' eine Datei app.js mit dem folgenden Inhalt an:

<pre>
require('/home/pacs/xyz00/users/pad/etherpad-lite/node_modules/ep_etherpad-lite/node/server.js');
process.chdir('/home/pacs/xyz00/users/pad/etherpad-lite');
</pre>

Zum Schluß wird in der Datei ''~/etherpad-lite/settings.js'' noch die MySQL-Datenbank konfiguriert. Dazu muss der Teil mit ''dbType: mysql'' aktiv (nicht auskommentiert) sein. Etwa wie folgt:

<pre>
"dbType" : "mysql",
"dbSettings" : {
"user" : "xyz00_padusr",
"host" : "localhost",
"password": "anderes-Geheimwort",
"database": "xyz00_paddb",
"charset" : "utf8mb4",
"insecureAuth": "true"
},
</pre>

Die Einstellungen für den ''dbType: dirty'' werden dafür entfernt.

Weiter unten in der Datei kann dann noch ein Admin-User aktiviert werden.

Etherpad sollte nun unter der URL: ''http://pad.example.com/'' erreichbar sein.

== Links ==

*[http://etherpad.org/ Etherpad Homepage (Englisch)]
*[https://github.com/ether/etherpad-lite/ Github Repository (Englisch)]
*[https://github.com/ether/etherpad-lite/wiki/Running-Etherpad-on-Phusion-Passenger Running Etherpad on Phusion Passenger (Englisch)]

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

Phusion Passenger

2017-11-27T08:20:28Z

Hsh-michaelhoennig: Erläuterungen zur Nutzung von Phusiuon Passenger

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

NodeJS

2017-11-27T07:52:55Z

Hsh-michaelhoennig: /* NodeJS Web-Applikation */ Verweis auf Phusion Passenger