netcup News

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

01.04.2025, Kategorie: Kooperation

Studenten bilden Schüler Sponsoring

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.

Studenten bilden Schüler Wiki Startseite

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.

Studenten bilden Schüler CNAME Eintrag

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

Grafik VPS Server für SystemRescue LinuxDieser 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

section 77_news.pngIn 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.

Um diese Infrastruktur zu verwalten und zu überwachen, hat netcup uns einen virtuellen Server kostenfrei zu Verfügung gestellt.

Über das Projekt

Im Rahmen des Projektes haben wir insgesamt vier Workshops veranstaltet, bei denen wir in Summe 28 Sensoren aufgebaut haben.
Die Workshops richteten sich primär an Personen, die im Sanierungsgebiet wohnen. Daher haben wir den Workshop inhaltlich so gestaltet, dass er auch ohne technische Vorkenntnisse erfolgreich absolviert werden konnte.

Umweltsensoren in ihren einzelnen Bestandteilen

Wir haben dazu eine bereits bestehende Platine etwas modifiziert und an unsere Anforderungen angepasst. Die Teilnehmenden mussten so nur noch ein paar Lötpunkte setzen – ganz ohne wäre es nicht das Gleiche gewesen.
Die Software haben wir dann gemeinsam auf den Mikrocontroller aufgespielt und die Elektronik in das selbst entworfene und 3D-gedruckte Gehäuse eingesetzt. Alle Teilnehmenden hatten zum Ende des Workshops einen funktionierenden Feinstaubsensor in Händen!

Durch die Fördermittel aus dem Mikroprojekt konnten wir ein LoRaWAN-Gateway beschaffen, welches wir nun auf dem Dach unseres Hackspaces betreiben. Die Workshopteilnehmenden werden so mit LoRaWAN versorgt.

Umweltsensor in Betrieb an Masten

Diese Feinstaubsensoren werden über die von netcup bereitgestellten VPS 2000 G9 VM überwacht und als Einstiegspunkt zur Administration des Gateways genutzt. Weiterhin werden Daten zur weiteren Auswertung auf dem Server gespeichert, um mithilfe von OpenSource Software wie Grafana, Prometheus und InfluxDB ausgewertet zu werden.

Im Rahmen des Mikroprojektes kam der Kontakt zu den Technischen Betrieben Offenburg (TBO)  zustande. Diese sind u. a. für die Müllentsorgung im Stadtgebiet Offenburg zuständig und waren gerade dabei, die Mülleimer im Stadtgebiet mit Füllstandsensoren zu versehen. Die Kosten für eine Überprüfungsfahrt (“Ist die Tonne voll genug, so dass sich eine Leerung lohnt?”) liegen fast gleichauf mit der Leerung selbst. Über fernabfragende Füllstandsensoren können die Fahrten aber gezielt geplant werden. Die TBO war sehr froh, dass wir unser Gateway gerade zum richtigen Zeitpunkt in Betrieb genommen haben, weil sie so ihren Piloten mit LoRaWAN anbinden konnten. Neben der geringeren Strahlung durch LoRaWAN ist im Gegensatz zu Mobilfunk der Energiebedarf auch viel geringer, so dass die Batterien deutlich seltener getauscht werden müssen. Der Pilot lief so gut, dass die TBO sich nun entschieden hat, die Tonnen mit LoRaWAN anzubinden.

Insgesamt haben wir 28 Haushalte im Sanierungsgebiet mit Feinstaubsensoren versorgt. Feinstaubsensoren, deren Daten per opensensemap.org  für alle zur Verfügung stehen und das dortige Sensornetzwerk verdichten. Durch das LoRaWAN-Gateway auf dem Dach werden nicht nur diese Sensoren versorgt, sondern auch die Füllstandsensoren der Mülltonnen und weitere Sensoren im Stadtgebiet.

Durch die Unterstützung von netcup haben wir die Möglichkeit, als Inkubator für weitere Projekte wie Lösungen auf Basis von LoRaWan und anderen IoT-Geräten zu dienen abseits der ausgetretenen Pfade und anderen Cloud-Lösungen.
Es entstehen in der Community weitere Ideen, die sich um aktuelle Themen wie Balkonkraftwerke oder Automatisierung des Smart Homes drehen.