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.

Gitea installieren

Vor ein paar Jahren schrieb ich eine Anleitung, in der es darum ging Gogs zu installieren. Schon damals hatte sich eine Abspaltung unter dem Namen Gitea herausgelöst, welche einen Community zentrierten Ansatz bei der Entwicklung fuhr. Gitea ist eine vollwertige Lösung, welche einen Git-Server, eine Weboberfläche und weitere Entwicklerwerkzeuge, wie einen Bugtracker und eine Wiki bereitstellt.

Gitea

Zur Installation von Gitea muss im ersten Schritt Git installiert werden:

apt-get install git

Nachdem dies geschehen ist, wird ein Nutzer für Gitea angelegt und in dessen Kontext gewechselt:

adduser --disabled-password --gecos "" git
su git
cd

Nun kann Gitea heruntergeladen werden. Dazu muss der passende Download-Link über die Projektseite ermittelt werden:

wget https://dl.gitea.io/gitea/1.8.3/gitea-1.8.3-linux-amd64

Im Normalfall sollte hierbei die Linux-AMD64-Version genutzt werden. Nach dem Download kann Gitea für den ersten Testlauf gestartet werden:

mkdir gitea
mv gitea-1.8.3-linux-amd64 gitea/gitea
cd gitea
chmod 755 gitea
./gitea

Nach dem Start kann Gitea im Browser unter der URL aufgerufen werden:

http://example.org:3000/

Sobald der erste Testlauf erfolgreich durchgeführt wurde, sollte Gitea wieder beendet werden. Im nächsten Schritt muss die systemd-Unit eingerichtet werden, welche dafür sorgt, dass der Service automatisch gestartet wird. Dazu wird im ersten Schritt die entsprechende Datei angelegt:

nano /etc/systemd/system/gitea.service

Diese Datei wird nun mit folgendem Inhalt befüllt:

[Unit]
Description=Gitea (Git with a cup of tea)
After=syslog.target
After=network.target
#After=mysqld.service
#After=postgresql.service
#After=memcached.service
#After=redis.service

[Service]
# Modify these two values and uncomment them if you have
# repos with lots of files and get an HTTP error 500 because
# of that
###
#LimitMEMLOCK=infinity
#LimitNOFILE=65535

Type=simple
User=git
Group=git
WorkingDirectory=/home/git/gitea
ExecStart=/home/git/gitea/gitea web
Restart=always
Environment=USER=git HOME=/home/git

# If you want to bind Gitea to a port below 1024 uncomment
# the two values below
###
#CapabilityBoundingSet=CAP_NET_BIND_SERVICE
#AmbientCapabilities=CAP_NET_BIND_SERVICE

[Install]
WantedBy=multi-user.target

Nachdem die systemd-Unit angelegt wurde, kann sie aktiviert und gestartet werden:

systemctl enable gitea
systemctl start gitea

Damit wird Gitea automatisch gestartet und läuft als Service im Hintergrund. Im Browser kann Gitea nun aufgerufen werden und installiert werden. Dazu wird der Anmelden-Button in der Weboberfläche gedrückt oder alternativ die URL:

http://example.org:3000/install

aufgerufen. In der Installationsroutine wird unter anderem die Datenbank-Verbindung definiert und es besteht die Möglichkeit einen administrativen Nutzer anzulegen. Für kleinere Installation kann SQLite3 als Datenbank-Backend bedenkenlos genutzt werden.

Sollten Fehler bei der Installation des Services oder bei Gitea aufgetreten sein, so lohnt es sich in das systemd-Log mittels:

systemctl status gitea

hineinzuschauen. Das Gitea-eigenen Logs befindet sich bei dieser Installation unter /home/git/gitea/log/:

/home/git/gitea/log/gitea.log 
/home/git/gitea/log/http.log 
/home/git/gitea/log/xorm.log

The Twelve-Factor App

Softwareentwicklung ist ein komplexes Pflaster. Da ist es praktisch, wenn der geneigte Entwickler eine Methodologie an die Hand bekommt, welche das Ergebnis der Entwicklung verbessert. Eine solche Methodologie ist die The Twelve-Factor App. Diese ursprünglich 2011 vorgestellte Methodologie kommt mit besagten zwölf Punkten aus. Diese führen von der Codebasis über die Abhängigkeiten bis hin zum Deployment. Zielgruppe der Methodologie sind Applikationen, welche als Service laufen.

12factor.net

Neben dem englischen Original existieren eine Reihe von Übersetzungen; unter anderem in die deutsche Sprache. Gelesen werden kann die Dokumentation der Methodologie unter 12factor.net. Lizenziert ist die Webseite unter der MIT-Lizenz und damit freie Software. Der Quelltext ist auf GitHub zu finden.

Services unter systemd einrichten

Das Init-System systemd ist mittlerweile in vielen Linux-Distributionen angekommen. Auch unter Ubuntu ist es seit Version 15.04 integriert. Ein Vorteil des neuen Systems ist, das Services, im Gegensatz zum alten Init-System, relativ unkompliziert erstellt werden können. Dazu muss eine sogenannte Unit erstellt werden. Bei einer Unit handelt es sich um eine Textdatei mit einer entsprechenden Konfiguration. Neben den Units für die Konfiguration eines Services existieren weitere Unit-Typen wie z.B. die Typen mit der Endung .path oder .network. In diesem Artikel soll es allerdings nur um die Units vom Typ Service gehen.

Die Units liegen in unterschiedlichen Orten im Dateisystem. Die vom System vorinstallierten Units sind im Ordner /lib/systemd/system/ zu finden. Eigene Services werden im Ordner /etc/systemd/system/ hinterlegt. Hier können allerdings nur Nutzer mit administrativen Rechten entsprechende Service hinterlegen. Soll ein nicht privilegierter Nutzer eine Unit angelegen, so muss er diese im Verzeichnis ~/.config/systemd/user/ hinterlegen. In den meisten Fällen werden Units für Services im Dateisystem unter dem Pfad /etc/systemd/system/ angelegt. In diesem Ordner soll nun eine Datei für die Unit angelegt werden:

nano languagetool.service

Beispielhaft könnte eine solche Unit wie folgt aussehen:

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

[Service]
Type=simple
User=languagetool
Group=languagetool
WorkingDirectory=/home/languagetool/server
ExecStart=/usr/bin/java -cp /home/languagetool/server/languagetool-server.jar org.languagetool.server.HTTPServer --config languagetool.cfg --port 3001 --allow-origin "*"
Restart=always
Environment=USER=git HOME=/home/languagetool

[Install]
WantedBy=multi-user.target

Die Unit unterteilt sich in unterschiedliche Bereiche, in diesem Beispiel sind dies Unit, Service und Install. Der Bereich Service ist hierbei nur in Units vom Typ Service zu finden. Im Bereich Unit sind eine kurze Beschreibung des Services und die Abhängigkeiten der Unit hinterlegt. Dabei wird definiert, welche Systeme bereits gestartet sein müssen, bevor der Service gestartet wird. Ein Target entspricht dabei einer Gruppe von Diensten, meist mit einer bestimmten Bedeutung, wie z.B. das Target für die Herstellung der Netzwerkkonnektivität (network-online.target).

In der Service-Gruppe wird der Typ des Services und der Nutzer und die Gruppe definiert, mit welchem bzw. welcher er starten soll. Daneben wird das Arbeitsverzeichnis und die Kommandozeile zur Ausführung des Services definiert. Weiterhin kann das Verhalten des Service, über den Parameter Restart, weiter definiert werden. So kann angegeben werden, dass der Service nach seiner Beendigung wieder neugestartet wird.

In der Install-Sektion wird angeben, wann der Service gestartet werden soll. Das multi-user.target entspricht dem klassischen Start eines normalen Linux-Systems. Ist die Unit definiert, kann sie aktiviert und der Service gestartet werden:

systemctl enable languagetool
systemctl start languagetool

Die Option enable sorgt dafür das die entsprechende Unit aktiviert wird. Dies führt dazu das sie je nach Konfiguration z.B. automatisch beim Systemstart oder bei dem Anschluss bestimmter Hardware gestartet wird. Unter bestimmten Systemen wie Ubuntu, kann der Service auch über das service-Kommando gestartet werden:

service languagetool start

Neben den Optionen enable und start für systemctl, existieren weitere Optionen zur Steuerung der Units. Dies sind unter anderem stop, zum Stoppen des Services und disable zur Deaktivierung der Unit. Mit der Option status, kann der Status eines Service erfragt werden:

systemctl status languagetool

Anschließend erhält der Nutzer den aktuellen Status des Service. Eine weitere wichtige Option ist restart um einen Service manuell neuzustarten. Mithilfe der systemd-Units lassen sich somit schnell Services in ein Linux-System einbinden.