Etherpad unter Ubuntu installieren

Bei Etherpad handelt es sich um einen Editor für kollaboratives Schreiben, welcher selbst gehostet werden kann. Soll Etherpad unter Ubuntu gehostet werden, muss im ersten Schritt Node.js installiert werden:

apt install -y libssl-dev
curl -sL https://deb.nodesource.com/setup_14.x | bash -
apt install -y nodejs

Anschließend wird ein Nutzer für Etherpad angelegt und in diesen gewechselt werden und dort der Quellcode für Etherpad heruntergeladen und initial einmal gestartet und dann mittels Strg + C wieder beendet:

adduser --disabled-login --gecos "" etherpad
su - etherpad
git clone --branch master https://github.com/ether/etherpad-lite.git
cd etherpad-lite
npm install sqlite3
src/bin/run.sh

Nun werden einige Konfigurationen vorgenommen. Im Groben werden die Datenbank, die Authentifikation, Vorbereitungen für den Reverse Proxy, die Nutzer und die maximale Länge von einzufügendem Inhalt und das Log konfiguriert:

nano etherpad-lite/settings.json

Die Änderungen sind in ihrer Reihenfolge in der Konfigurationsdatei angegeben:

...

"dbType": "sqlite",
"dbSettings": {
  "filename": "var/sqlite.db"
},

...

"requireAuthentication": true,

...

"trustProxy": true,

...

"users": {
"admin": {
  // 1) "password" can be replaced with "hash" if you install ep_hash_auth
  // 2) please note that if password is null, the user will not be created
  "password": "example",
  "is_admin": true
},
"user": {
  // 1) "password" can be replaced with "hash" if you install ep_hash_auth
  // 2) please note that if password is null, the user will not be created
  "password": "example",
  "is_admin": false
}
},

...

"socketIo": {
/*
 * Maximum permitted client message size (in bytes). All messages from
 * clients that are larger than this will be rejected. Large values make it
 * possible to paste large amounts of text, and plugins may require a larger
 * value to work properly, but increasing the value increases susceptibility
 * to denial of service attacks (malicious clients can exhaust memory).
 */
"maxHttpBufferSize": 1048576
},

...

"logconfig" :
{ "appenders": [
    { "type": "console"
    //, "category": "access"// only logs pad access
    }

  , { "type": "file"
  , "filename": "etherpad.log"
  , "maxLogSize": 1024000
  , "backups": 3 // how many log files there're gonna be at max
    }

...

Anschließend wird der Kontext des Nutzers etherpad verlassen und eine neue Service-Unit für systemd angelegt:

exit
nano /etc/systemd/system/etherpad.service

Diese wird mit folgendem Inhalt befüllt:

[Unit]
Description=Etherpad
After=syslog.target
After=network.target

[Service]
Type=simple
User=etherpad
Group=etherpad
Environment="NODE_ENV=production"
ExecStart=/home/etherpad/etherpad-lite/src/bin/run.sh
Restart=always

[Install]
WantedBy=multi-user.target

Nachdem die Datei angelegt wurde, kann der Service aktiviert und gestartet werden:

systemctl enable etherpad
systemctl start etherpad

Lokal ist der Service nun per HTTP unter dem Port 9001 erreichbar. Damit der Service auch von außen erreichbar ist, kann Nginx als Reverse Proxy konfiguriert werden. Dazu muss die entsprechende Konfiguration hinterlegt werden:

server {
    listen 443 ssl;
    listen [::]:443 ssl;

    ssl_certificate        /etc/letsencrypt/live/example.org/fullchain.pem;
    ssl_certificate_key    /etc/letsencrypt/live/example.org/privkey.pem;

    server_name example.org;

    client_max_body_size 512m;

    location / {

        # Set proxy headers
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # These are important to support WebSockets
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "Upgrade";

        # Make sure to set your Etherpad port number
        proxy_pass http://localhost:9001;
    }
}

Damit steht Etherpad auch von außen unter der entsprechenden Domain zur Verfügung und kann benutzt werden.

Foundry VTT unter Ubuntu als Service installieren

Bei Foundry VTT handelt es sich um eine Virtual Tabletop-Plattform, welche selbst gehostet werden kann. Daneben existieren Versionen für macOS und Windows. Soll Foundry VTT unter Ubuntu gehostet werden, muss im ersten Schritt Node.js installiert werden:

apt install -y libssl-dev
curl -sL https://deb.nodesource.com/setup_14.x | bash -
apt install -y nodejs

Anschließend kann ein Nutzer für Foundry VTT angelegt werden und in diesen gewechselt werden:

adduser --disabled-login --gecos "" foundryvtt
su - foundryvtt
mkdir foundry

Nachdem das aktuelle Release von Foundry VTT heruntergeladen wurde, sollte dieses im Ordner foundry entpackt werden:

cd foundry
unzip foundryvtt.zip
rm foundryvtt.zip

Anschließend wird der Kontext des Nutzers foundryvtt verlassen und eine neue Service-Unit für systemd angelegt:

exit
nano /etc/systemd/system/foundryvtt.service

Diese wird mit folgendem Inhalt befüllt:

[Unit]
Description=Foundry VTT
After=syslog.target
After=network.target

[Service]
Type=simple
User=foundryvtt
Group=foundryvtt
ExecStart=/usr/bin/node /home/foundryvtt/foundry/resources/app/main.js --dataPath=/home/foundryvtt/foundrydata
Restart=always

[Install]
WantedBy=multi-user.target

Nachdem die Datei angelegt wurde, kann der Service aktiviert und gestartet werden:

systemctl enable foundryvtt
systemctl start foundryvtt

Lokal ist der Service nun per HTTP unter dem Port 30000 erreichbar. Damit der Service auch von außen erreichbar ist, kann Nginx als Reverse Proxy konfiguriert werden. Dazu muss die entsprechende Konfiguration hinterlegt werden:

server {
    listen 443 ssl;
    listen [::]:443 ssl;

    ssl_certificate        /etc/letsencrypt/live/example.org/fullchain.pem;
    ssl_certificate_key    /etc/letsencrypt/live/example.org/privkey.pem;

    server_name example.org;

    client_max_body_size 512m;

    location / {

        # Set proxy headers
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # These are important to support WebSockets
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "Upgrade";

        # Make sure to set your Foundry VTT port number
        proxy_pass http://localhost:30000;
    }
}

Damit steht Foundry VTT auch von außen unter der entsprechenden Domain zur Verfügung und kann benutzt werden.

Kalenderdateien mit webcal-Schema herunterladen

Manche Dienste und Webseiten bieten Kalenderdateien über das inoffizielle URL-Schema webcal:// an. Wird nun versucht eine solche URL herunterzuladen:

wget webcal://example.org

erhält der Nutzer in den meisten Fällen die Meldung:

Nicht unterstütztes Schema »webcal«

Abhilfe schafft es in diesem Fall das Schema webcal durch http bzw. https zu ersetzen. Anschließend kann die Datei mit den Kalendereinträgen problemlos heruntergeladen werden.

Reverse Proxy für Gitea konfigurieren

Ein Reverse Proxy liefert eine Ressource, welche er von einem oder mehreren Servern holt, an einen Client aus. Bei Gitea kann es durchaus sinnvoll sein, dieses hinter einem Reverse Proxy zu betreiben. Standardmäßig läuft der Dienst auf dem Port 3000. Möchte der Nutzer ihn über die normalen Ports für HTTP (80) bzw. HTTPS (443) erreichbar machen, könnte das Ganze durchaus über die Konfiguration von Gitea in Verbindung mit der systemd-Unit geschehen.

Allerdings ist ein weiterer Vorteil bei einem Reverse Proxy, das die angefragte Infrastruktur aus der Sicht der Clients versteckt wird. Mittels Nginx kann es solcher Reverse Proxy realisiert werden. Dazu muss die Nginx-Konfiguration für die Domain angepasst werden:

nano /etc/nginx/sites-available/example

In diesem Fall befasst sich die Konfiguration mit der verschlüsselten Kommunikation per HTTPS und der Weiterleitung von unverschlüsselten Verbindung in Richtung der verschlüsselten Verbindung.

server {
  listen 80;
  listen [::]:80;

  server_name example.org;

  return 301 https://$host$request_uri$is_args$args;
}

server {
  listen 443;
  listen [::]:443 default_server;

  ssl on;
  ssl_certificate        /etc/letsencrypt/live/example.org/fullchain.pem;
  ssl_certificate_key    /etc/letsencrypt/live/example.org/privkey.pem;

    server_name org;

    location / {
        proxy_pass http://localhost:3000;
    }
}

Anhand der Konfiguration wird ersichtlich das Gitea auf dem Server unverschlüsselt betrieben werden kann, da die eigentliche Verschlüsselung über HTTPS vom Reverse Proxy, in diesem Fall Nginx, übernommen wird. Nachdem die Konfiguration gespeichert wurde, muss Nginx neugestartet werden:

service nginx restart

Anschließend muss die Gitea-Konfiguration nochmals angepasst werden:

nano /home/git/gitea/custom/conf/app.ini

Dort muss die ROOT_URL nun so definiert werden, wie der Client sie nun sieht. Die ROOT_URL kann von:

ROOT_URL         = https://example.org:3000/

zu:

ROOT_URL         = http://example.org/

geändert werden. Die Werte PROTOCOL, CERT_FILE und KEY_FILE können entfernt werden, da die Verschlüsslung nun von Nginx übernommen wird. Nach der Änderung der Konfiguration muss Gitea ebenfalls neugestartet werden:

service gitea restart

Nachdem die Konfiguration durch geführt wurde, ist Gitea unter zwei URLs erreichbar:

http://example.org:3000/
https://example.org/

Intern läuft Gitea auf dem Port 3000. Damit dieser nicht von außen erreichbar ist, sollte eine entsprechende Firewall-Regel konfiguriert werden.

HTTPS für Gitea aktivieren

Nach der Installation von Gitea läuft dieses standardmäßig über unverschlüsseltes HTTP. Um dies zu ändern muss die app.ini welche sich im Verzeichnis /home/git/gitea/custom/conf/ befindet bearbeitet werden:

nano /home/git/gitea/custom/conf/app.ini

In der Sektion server welche für gewöhnlich wie folgt aussieht:

[server]
SSH_DOMAIN       = localhost
DOMAIN           = localhost
HTTP_PORT        = 3000
ROOT_URL         = http://example.org:3000/
DISABLE_SSH      = false
SSH_PORT         = 22
LFS_START_SERVER = true
LFS_CONTENT_PATH = /home/git/gitea/data/lfs
LFS_JWT_SECRET   = plgd0f1J4RlmWFnk9K4oHeV6Wey_vI55x7uC81Rp5Mc
OFFLINE_MODE     = false

müssen einige Änderungen vorgenommen werden. Die Schlüssel PROTOCOL, CERT_FILE und KEY_FILE müssen hinzugefügt und die ROOT_URL angepasst werden. Danach sollte die server-Sektion in etwa so aussehen:

[server]
SSH_DOMAIN       = localhost
DOMAIN           = localhost
HTTP_PORT        = 3000
PROTOCOL         = https
CERT_FILE        = custom/https/cert.pem
KEY_FILE         = custom/https/key.pem
ROOT_URL         = https://example.org:3000/
DISABLE_SSH      = false
SSH_PORT         = 22
LFS_START_SERVER = true
LFS_CONTENT_PATH = /home/git/gitea/data/lfs
LFS_JWT_SECRET   = plgd0f1J4RlmWFnk9K4oHeV6Wey_vI55x7uC81Rp5Mc
OFFLINE_MODE     = false

Nachdem die Konfiguration gespeichert wurde muss das passende Zertifikat erzeugt werden:

cd /home/git/gitea/custom/
mkdir https
cd https
./gitea cert -ca=true -duration=8760h0m0s -host=example.org

Alternativ und in den meisten Fall sinnvoller ist es allerdings an dieser Stelle Zertifikate von Let’s Encrypt einzubinden. Dazu müssen die Zertifikate für die Domain im ersten Schritt erzeugt werden:

letsencrypt certonly

Anschließend muss die app.ini angepasst werden:

nano /home/git/gitea/custom/conf/app.ini

Dort werden die Werte für CERT_FILE und KEY_FILE so konfiguriert das sie auf die Let’s Encrypt-Zertifikate zeigen:

CERT_FILE    = /etc/letsencrypt/live/example.org/fullchain.pem
KEY_FILE     = /etc/letsencrypt/live/example.org/privkey.pem

Damit ist Gitea nach einem Neustart des Service per HTTPS und damit verschlüsselt erreichbar.