netcup News

Studenten bilden Schüler e.V. (StudyTutors) – Referenzstory

01.04.2025, Kategorie: Kooperation

In diesem Beitrag zeigen wir (Studenten bilden Schüler), wie wir den von netcup bereitgestellten Server für unsere Vereinsinfrastruktur benutzen. Konkret hosten wir aktuell ein Wiki, in dem wir den Informationsverlust zwischen wechselnden Vorständen zu minimieren versuchen. Außerdem sind weitere Services, wie etwa Mattermost oder eigens geschriebene Tools, angedacht, um auf dem Server deployed zu werden.

Autor: Dominik Geißler, Studenten bilden Schüler e.V.

Über StudyTutors

Wir von StudyTutors haben es uns zum Ziel gemacht, den Zugang zu individueller Bildung unabhängig vom
finanziellen oder sozialen Stand der Familien zu gestalten. Dazu geben wir in mittlerweile über 50
Universitätsstädten kostenlose 1:1 Nachhilfe für Familien, die sich eine reguläre Nachhilfe nicht leisten können.
Dazu sind wir in sogenannte Standorte unterteilt, die sehr autark arbeiten und durch die Standortleitung mit
dem Bundesvorstand in Kontakt stehen. Der Bundesvorstand kümmert sich deshalb weniger um die Nachhilfe
selbst, sondern um allerlei Belange, etwa der Vereinsausrichtung, Finanzierung oder Infrastruktur.

Motivation

Über einige Jahre ist es immer wieder aufgefallen, dass wir, gerade auch durch den großen Wachstum des
Vereins während der Corona-Zeit, häufig bestimmte Fehler wieder machen, Sachen vergessen oder einige
Personen ein Wissensmonopol haben, was nach deren Austritt natürlich zu füllen ist. Um dem gegenzuwirken
haben wir uns entschieden, ein Wiki zu erstellen, welches eine Sammelstelle für dieses ganze Wissen, die
Abläufe, Fehler, etc. sein soll.
Das Wiki sollte self-hosted sein, damit wir die Flexibilität und den Datenschutz garantieren können. Dafür
nutzen wir den von netcup gesponsorten Server.

Wie hostet man ein Wiki?

Um das Wiki zu hosten, haben wir uns für Wiki.js entschieden, welches ein sehr vielseitiges open-source Wiki
bietet, das man auf dem eigenen Server hosten kann.
Es gibt verschiedene Möglichkeiten das Wiki zu hosten, zum Beispiel in einem Docker-Container (also einem
in sich abgeschlossenen Umfeld), eine direkte Installation oder in einem Cluster. Wir haben uns dafür
entschieden, einen Docker-Container zu nehmen, da es einfach zu installieren aber auch gut zu verwalten ist.
So kann man, wenn mehrere Services parallel laufen, diese durch Container gut verwalten.
Für das Wiki brauchen wir drei verschiedene Komponenten: Das Wiki selbst, eine Datenbank in welcher die auf
dem Wiki eingetragenen Informationen gespeichert werden und einen Update-Companion (also eine
Software, die uns bei Updates hilft). Zudem erstellen wir ein SSL-Zertifikat, damit wir HTTPS benutzen können.
Für die Docker-Container müssen wir zunächst Docker installieren. Das machen wir, indem wir über den
Package Manager von unserer Linux-Distro (apt) die nötigen Pakete installieren:

# Update alle Pakete
sudo apt -qqy update

# Installiere die notwendigen Pakete
sudo apt install -qqy ca-certificates curl gnupg lsb-release

# Registriere die Docker Package Registry
sudo mkdir -p /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# Installiere Docker
sudo apt -qqy install docker-ce docker-ce-cli containerd.io docker-compose-plugin

Für die Container benötigt es dann noch etwas an Konfiguration. Wir brauchen einen Ordner, der die
Konfigurationsdateien beinhaltet, wie auch einige Einstellungen für die Datenbank:

# Ordner für unsere Konfigurationsdateien
mkdir -p /etc/wiki

# Erstelle ein Secret für die Datenbank
openssl rand -base64 32 > /etc/wiki/.db-secret

# Erstelle ein internes Docker-Netzwerk für unser Wiki
docker network create wikinet

# Erstelle ein Volume (einen Datenspeicher) für die Datenbank
docker volume create pgdata

# Last but not least, erstelle die Container
docker create --name=db \
  -e POSTGRES_DB=wiki \
  -e POSTGRES_USER=wiki \
  -e POSTGRES_PASSWORD_FILE=/etc/wiki/.db-secret \
  -v /etc/wiki/.db-secret:/etc/wiki/.db-secret:ro \
  -v pgdata:/var/lib/postgresql/data \
  --restart=unless-stopped \
  -h db \
  --network=wikinet \
  postgres:15

docker create --name=wiki \
  -e DB_TYPE=postgres \
  -e DB_HOST=db \
  -e DB_PORT=5432 \
  -e DB_PASS_FILE=/etc/wiki/.db-secret \
  -v /etc/wiki/.db-secret:/etc/wiki/.db-secret:ro \
  -e DB_USER=wiki \
  -e DB_NAME=wiki \
  -e UPGRADE_COMPANION=1 \
  --restart=unless-stopped \
  -h wiki \
  --network=wikinet \
  -p 80:3000 -p 443:3443 \
  ghcr.io/requarks/wiki:2

docker create --name=wiki-update-companion \
  -v /var/run/docker.sock:/var/run/docker.sock:ro \
  --restart=unless-stopped \
  -h wiki-update-companion \
  --network=wikinet \
  ghcr.io/requarks/wiki-update-companion:latest

Zu guter Letzt müssen wir noch unsere Firewall anpassen, damit wir auf den Dockercontainer zugreifen
können.

# Erlaube HTTP, HTTPS und SSH-Ports
sudo ufw allow ssh
sudo ufw allow http
sudo ufw allow https
sudo ufw --force enable

Jetzt können die Container und somit das Wiki gestartet werden:

docker start db
docker start wiki
docker start wiki-update-companion

Und voilà – das Wiki läuft nicht nur sondern kann über die Server-IP auch von außerhalb erreicht werden.

Um eine eigene Subdomain zu haben, haben wir in unserem Domain Management Service in Netlify einen neuen CNAME-Eintrag hinzugefügt, welcher auf die Adresse des Servers zeigt.

In der Wiki-Oberfläche haben wir danach weitere Einstellungen, etwa automatische Backups, gemacht und
konnten direkt losschreiben.
Zum jetzigen Zeitpunkt hat unser Wiki knapp 40 Seiten und 25 Benutzer. Da wir durch das Wiki weitere
genutzte Tools einstellen konnten, ist das nicht nur für die zukünftigen Vorstände eine super Sache, um nicht
die selben Fehler zu wiederholen, aber auch für uns jetzt, da wir weniger Tools managen müssen

Und wie geht’s jetzt weiter?

Das Potential des Servers und unsere Ideen sind noch lange nicht ausgeschöpft. Zu diesem Zeitpunkt läuft auf
dem Server neben dem Wiki auf die Demoversion der Slack-ähnlichen Kommunikationsplattform Mattermost.
Diese wollen wir als einfachere Kommunikationsmöglichkeit für den Bundesvorstand, aber auch für Standorte,
benutzen. Dies bringt allerdings auch einige technisch sehr interessante Probleme, die die Anfrage, welche
vorher nur direkt an den Docker-Container ging, durch einen Reverse-Proxy nun an die richtige Adresse
verteilen muss.
Außerdem möchten wir noch eigene Scripts und Services hosten, die gewisse Prozesse der Verwaltung
vereinfachen oder ganz automatisieren.
Wir danken an dieser Stelle netcup noch einmal ganz herzlich für die Bereitstellung des Servers, erst dadurch
konnten wir einige alte ineffiziente Prozesse überholen und uns somit den wichtigeren Aufgaben widmen:
Den Kindern eine Chance auf Bildung zu geben!