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!

SystemRescue Linux – Referenzstory

16.03.2023, Kategorie: Kooperation

Dieser Beitrag beschreibt wie SystemRescue zwei von netcup gesponserte VPS 1000 Server zur hochverfügbaren
und weltweiten Bereitstellung von großen Dateien zum Download nutzt.

Autor: Gerd v. Egidy (SystemRescue)

Über SystemRescue

SystemRescue (früher: SystemRescueCD) ist eine Linux-Distribution mit dem speziellen Fokus auf Diagnose und Reparatur von Computerproblemen, wie z.B. nicht mehr bootenden Systemen, defekten Dateisystemen, etc. Aber es sind auch Programme für Backup, Imaging, Hardware-Fehlererkennung und zur Automatisierung von Administrationsaufgaben enthalten.

Es startet als Live-System direkt von einem USB-Stick, DVD oder über das Netzwerk und muss nicht vorher auf der Festplatte installiert werden. Auf allen netcup Servern kann SystemRescue direkt als eines der offiziellen Boot-Images aus dem Server Control Panel (SCP) heraus gestartet werden.

SystemRescue wird seit 2003 kontinuierlich von einem internationalen Team weiterentwickelt.

Downloads und Mirror-Konzept

SystemRescue wird als .iso-Images mit momentan etwa 750 MB Größe veröffentlicht. Diese .iso-Dateien müssen von den über die ganze Welt verstreuten Nutzern heruntergeladen werden können. Bisher wird dafür der Anbieter SourceForge verwendet, dessen Download-Geschwindigkeiten in letzter Zeit aber öfters zu
Wünschen übrig lassen, so dass der Download je nach Tageszeit und zugewiesenem Server auch mal länger als 15 Minuten dauern kann.

Das soll jetzt verbessert werden. Zum einen hat sich der Content Delivery Network (CDN) Provider Fastly bereiterklärt die Dateien von SystemRescue zu hosten. Allerdings gilt das Angebot von Fastly nur für ein begrenztes Übertragungsvolumen. Daher, und um nicht alleine von einem Anbieter abhängig zu sein, baut SystemRescue parallel, u.a. mit Hilfe von netcup, eine eigene Mirror-Infrastruktur für die Downloads auf.

Weltweit verteilt gibt es viele Universitäten, Netzwerkprovider und Firmen die Dateien von OpenSource-Projekten herunterladen und wieder zum Download für andere Nutzer in Ihrer Nähe bereitstellen. Dies wird Mirror-Server genannt und ist ein in der OpenSource-Welt seit vielen Jahren etabliertes Konzept. Allerdings ist es für die
Endanwender aufwendiger einen geeigneten Mirror-Server in Ihrer Nähe aus einer großen Liste heraus auszusuchen. Gleichzeitig ist es für eine Distribution wie SystemRescue nötig zu überwachen welche von den Mirror-Servern gut erreichbar sind und über aktuelle Daten verfügen.

Beide Aufgaben werden von dem Programm MirrorManager, entwickelt als Teil des Fedora-Projekts, gelöst. MirrorManager ist so aufgebaut dass jede Distribution einen zentralen Server betreibt auf dem eine Liste aller Mirror-Server gepflegt wird. Von dort aus werden diese regelmäßig abgefragt und so auf Erreichbarkeit und Aktualität geprüft. Diese Serverliste wird dann mit einer Länderliste von IP-Netzen und AS-Nummern verknüpft, so dass für jede mögliche IP eines Nutzers die nächstgelegenen Mirror-Server ermittelt werden.

Diese Aufgaben übernimmt ein von netcup gesponserter VPS 1000 G10.

Mirror-Redirector

Möchte ein Nutzer die aktuelle Version von SystemRescue herunterladen, soll er nur einen Link anklicken und dann automatisch zu dem ihm am nächsten gelegenen Mirror-Server weitergeleitet werden. Diese Weiterleitung wird anhand der von MirrorManager wie oben beschrieben erstellten Liste gemacht.

Während ein kurzzeitiger Ausfall des MirrorManager-Servers nur bedeutet dass zeitweise keine neuen Mirror-Server mehr hinzugefügt werden können, würde ein Ausfall des Redirectors bedeuten, dass die Nutzer SystemRescue nicht mehr herunterladen können. Daher werden an die Zuverlässigkeit des Mirror-Redirector-Dienstes erhöhte Anforderungen gestellt.

Als Projekt von Freiwilligen verfügt SystemRescue nicht über ein Rund um die Uhr erreichbares Notfallteam. Die kritische Infrastruktur muss daher so ausgelegt sein, dass sie für einige Zeit vollautomatisch auf Ausfälle reagieren kann.

Hochverfügbarkeit

Auch wenn netcup Lösungen zur Hochverfügbarkeit wie Failover IPs und mehrere Serverstandorte im Programm hat, bot sich für SystemRescue eine andere Lösung an.

Der Mirror-Redirector-Dienst läuft dabei gleichzeitig auf einem weiteren von netcup gesponserten VPS 1000 G10, als auch auf einem ähnlichen Server beim Anbieter OVH. Im Normalfall sind beide Server unter dem selben DNS-Hostnamen als gleichwertige A- und AAAA-Einträge konfiguriert. Die Nutzer werden dadurch zufällig zu einem der beiden Server weitergeleitet. Für die Funktion des Redirects werden nur wenige Bytes übertragen, daher ist eine geografische Zuordnung der Nutzer etc. an dieser Stelle nicht notwendig.

Der Hostname wird dabei vom DNS-Dienst Amazon Route 53 verwaltet. Dort läuft ein Überwachungsdienst der permanent beide Server von verschiedenen Standorten aus per HTTPS anspricht und so prüft ob sie erreichbar sind und die erwartete Antwort zurückliefern. Sollte ein Server nicht antworten oder einen Fehlercode
liefern, wird er sofort aus den DNS-Antworten entfernt. Dieses Prinzip wird DNS Failover genannt. Selbstverständlich kann ein Server auch z.B. für geplante Wartungsarbeiten gezielt aus dem DNS-Eintrag entfernt werden.

Das DNS Failover in Kombination mit den 2 VPS bei verschiedenen Anbietern verspricht eine sehr hohe Verfügbarkeit bei gleichzeitig überschaubarem Mehraufwand für die Hochverfügbarkeit.

Automatische Konfiguration & Rollout

SystemRescue verwendet bereits seit Jahren erfolgreich Ansible für das Konfigurationsmanagement der Server. Es erlaubt die Konfiguration auf allen Servern einheitlich zu halten, die Konfiguration bei Bedarf schnell wiederherzustellen und alle Änderungen mit git sauber zu pflegen und zu dokumentieren.

Ganz dem OpenSource-Gedanken folgend werden auch diese Daten veröffentlicht und können von Interessierten wiederverwendet, angepasst und verbessert werden. Nur einige private Daten wie Passwörter und IP-Listen sind in einem mit git-crypt verschlüsselten privaten Submodule-Repository abgelegt.

Auf Gitlab kann man den Fortschritt bei der Implementation der hier beschriebenen Funktionen beobachten oder bei Interesse auch Fragen stellen oder sich mit einbringen.

Section 77 e.V. – Referenzstory

27.01.2023, Kategorie: Kooperation

In diesem Beitrag wird anhand eines konkreten Projektes erklärt, für was der Verein Section 77 e.V. einen VPS Server 2000 nutzt. Ziel ist es, einen Überblick zu bekommen, wie vielseitig netcup Produkte angewendet werden können. Der Verein Section 77 e.V. mit Sitz in Offenburg (Deutschland) organisierte vier Workshops, an denen die Teilnehmenden aktiv Umweltsensoren zusammenbauen, programmieren und in Betrieb nehmen konnten. 

Autor: Tobias Paepke, Section 77 e.V.

Im Frühjahr 2021 hat Section77 e.V. im Rahmen der Sanierung des Quartiers Bahnhof- Schlachthof eine Mikroprojektförderung erhalten. Das hat uns ermöglicht, ein professionelles LoRaWAN-Gateway sowie das Material für Umweltsensoren anzuschaffen. In Workshops boten wir interessierten Bürgerinnen und Bürgern die Möglichkeit, die Sensoren mit der Unterstützung unserer Mitglieder zusammenzubauen, zu programmieren und in Betrieb zu nehmen. Mit einem engmaschigen Umweltmessnetzwerk wollten wir die Luftqualität im Offenburger Sanierungsgebiet erfassen und Menschen für Sensorik und Citizen Science begeistern.