Bildquelle: KI-generiert

In unserem ersten Artikel zur Serie DIY / Softwareentwicklung haben wir aufgezeigt wie eine Infrastruktur für selbst gehostete Softwareentwicklungskomponenten aussehen kann. Danach haben wir euch mitgenommen und aufgezeigt was für Probleme bei vermeintlich einfachen Aufgaben wie dem Umzug auf eine SSD passieren können. Nun wollen wir auf den Betrieb und die Aktualisierung der Komponenten eingehen. Im Kontext zunehmender Sicherheitsrisiken durch automatisierte Angriffe und KI-gestützte Tools ist ein aktueller Stand der Software essenziell um Schwachstellen zeitnah zu schließen.

Im folgenden Beitrag betrachten wir das Thema exemplarisch am Beispiel der Artefaktverwaltung Sonatype Nexus Repository.

Komponenten für eine selbst gehostete Infrastruktur findet ihr unter: https://ezwl.de/wishlist/softwareentwicklung_infrastruktur.

Beispiel: Sonatype Nexus Repository

Zunächst orientieren wir uns am offiziellem Vorgehen des Softwareherstellers:
https://help.sonatype.com/en/upgrade-nexus-repository.html

Auf Basis der Dokumentation leiten wir unser eigenes Vorgehen ab (zunächst manuell). Wichtig ist dabei die saubere Trennung in Installationsverzeichnis (z. B. /opt/nexus) und Datenverzeichnis (z. B. /opt/sonatype-work/nexus-3).

Ablauf

• Existiert eine neue Version?
• Release Notes prüfen
  • Ist das Update für die eigene Umgebung relevant?
  • Sind manuelle Migrationsschritte erforderlich?
• Download und Entpacken der aktuellen Version
• Service stoppen
• Sicherung des Datenverzeichnisses
• Vergleich von Konfigurationsdateien
  • (z. B. nexus.vmoptions und jetty-https.xml)
• Aktualisierung des Installationsverzeichnisses
• Service starten und Log-Ausgabe prüfen

Beispielhafte Linux-Kommandos

#Service stoppen
systemctl stop nexus.service
#Download der Software
wget -P ~/Downloads/ https://download.sonatype.com/nexus/3/nexus-3.92.3-01-linux-aarch_64.tar.gz
#Entpacken
tar xzf ~/Downloads/nexus-3.92.3-01-linux-aarch_64.tar.gz
#Verzeichnis prüfen
ls -la ./nexus-3.92.3-01
#Sicherung des Datenverzeichnis (inkl. DB)
tar czf /mnt/nas/backup/nexus-backup-$(date +%F).tar.gz /opt/sonatype-work/nexus3
#Löschen der alten Version / rollierendes Vorgehen
rm -r /opt/nexus_old
#Aktuelle Instanz umbenennen / bleibt erhalten
mv /opt/nexus /opt/nexus_old
#verschieben der neuen Dateien ins Installationsverzeichnis
mv ~/Downloads/nexus-3.92.3-01 /opt/nexus
#Setzen des Owners
chown -R nexus:nexus /opt/nexus
#Alten keystore kopieren / übernehmen
cp /opt/nexus_old/etc/ssl/keystore.jks /opt/nexus/etc/ssl/
#Überschreiben der Jetty-Konfiguration
mv /opt/nexus/etc/jetty/jetty-https.xml /opt/nexus/etc/jetty/jetty-https.xml_oldcp /opt/nexus_old/etc/jetty/jetty-https.xml /opt/nexus/etc/jetty/
#Start des Service
systemctl start nexus.service
#Prüfen / beobachten des Logs
tail -f /opt/sonatype-work/nexus3/log/nexus.log

Hinweis: Im Beispiel wird von einem wiederkehrenden Update-Zyklus ausgegangen, weshalb ein vorheriges Installationsverzeichnis unter Umständen bereits existiert.

Fazit

Das beschriebene Vorgehen zeigt ein manuelles Update-Szenario für Sonatype Nexus Repository – konkret hier auf die Version 3.92.3-01.

Zur weiteren Verbesserung bzw. für produktive Umgebungen bietet sich eine Automatisierung an, z. B. über Shell-Skripte, Cronjobs oder Tools wie Ansible.

Eine Einführung in Ansible findet sich unter:
Red Hat Ansible Tutorial

Unseren nächsten Artikel planen wir die angerissene Automatisierung über Ansible.

Der Beitrag Softwareentwicklung – Betrieb und Aktualisierung selbst gehosteter Systeme erschien zuerst auf DasKIAS.

Bildquelle: KI-generiert

KI-gestützte Rettung einer GitLab-Instanz

In einem vorherigen Artikel zu Infrastrukturkomponenten der Softwareentwicklung hatten wir bereits erwähnt, dass unser Raspberry Pi auf eine SSD umgestellt werden sollte. Gesagt, getan: In Zeiten von KI wirkt vieles erstaunlich einfach. Der schnelle Startversuch erfolgte über das Klonen des Laufwerks und einen anschließenden Reboot.

Was danach folgte, gehört allerdings zu den klassischen Momenten, die jedes DIY-Projekt früher oder später bereithält.

Nach Anpassung der Bootreihenfolge und der UUIDs trat jedoch der Super-GAU ein: Das System bootete nicht mehr. Genau dieser Punkt gehört zum Basteln dazu – Dinge selbst umzusetzen bedeutet eben auch, Fehler zu provozieren, sie zu verstehen und daran zu wachsen. Dieser Artikel beschreibt genau diesen Weg und die dabei gewonnenen Erfahrungen.

Nach einem kurzen Brainstorming fiel die Entscheidung für einen pragmatischen Ansatz: eine Neuinstallation von Ubuntu 26.04 auf der SSD und anschließend die Migration der bestehenden GitLab-Instanz. Das vorherige System basierte auf Ubuntu 24.04, wodurch einzelne Fallstricke vorprogrammiert waren.

Wichtig dabei: Ein Backup der relevanten Daten war vorhanden, sodass kein kompletter Neuaufbau notwendig war. Genau hier liegt ein zentraler Punkt: Automatisierte Backups sind essenziell. Technische Defekte oder Probleme nach Softwareupdates sind keine Seltenheit.

Vorgehen

• Installation Ubuntu 26.04
• Gitlab wiederhestellen
• Backup durchführen und automatisieren

Installation Ubuntu 26.04

Mit Hilfe von Raspberry Pi Imager ist das quasi ein Selbstläufer und bedeutet nur ein wenig Geduld.

GitLab wiederherstellen

Zunächst wurde GitLab in der Version 18.11 neu installiert:

sudo apt install -y curl ca-certificates gnupg

curl -fsSL https://packages.gitlab.com/gpg.key | sudo gpg --dearmor -o /usr/share/keyrings/gitlab.gpg

echo "deb [signed-by=/usr/share/keyrings/gitlab.gpg] https://packages.gitlab.com/gitlab/gitlab-ce/ubuntu/ noble main" | sudo tee /etc/apt/sources.list.d/gitlab-ce.list

sudo EXTERNAL_URL="http://gitlab.local" apt install gitlab-ce

Das neue System soll sich nahtlos in unsere bestehende Infrastruktur integrieren. Daher soll der alte Zustand so gut wie möglich wiederhergestellt werden. Daher wurde die gitlab.rb anhand des Backups angeglichen. Zusätzlich wurden SSL-Zertifikate sowie die Datei gitlab-secrets.json übernommen.

Das Verzeichnis /var/opt/gitlab/ wurde aus dem Backup wiederhergestellt. Dabei traten zunächst Probleme mit den Dateiberechtigungen auf.

Berechtigungen und Re-Konfiguration

Zur Behebung wurden die Verzeichnisberechtigungen korrigiert und anschließend erneut eine Re-Konfiguration durchgeführt. Der Befehl gitlab-ctl reconfigure setzt einige Berechtigungen automatisch, aber die Vorbedingungen müssen stimmen. Nach mehreren Versuchen funktionierte der Prozess stabil. Die Logs (gitlab-ctl tail) lieferten die notwendigen Informationen welche Verzeichnisberechtigungen nicht korrekt waren.

Probleme nach dem ersten Start

Finally?

Bildquelle: Screenshot GitLab Anmeldebildschirm

Nach dem ersten Moment der Erleichterung folgte schnell die Ernüchterung: Es wurden zunächst keine Projekte angezeigt. Im Adminbereich waren die Projekte jedoch vorhanden und auch die API-Endpunkte lieferten korrekte Ergebnisse. Die GitLab-Oberfläche selbst deutete dennoch auf ein weiter bestehendes Problem hin. Das Vorgehen ist also nicht gescheitert, erfordert aber weitere Schritte.

Die Analyse der Logs führte zu folgenden Schritten:

sudo gitlab-rake gitlab:check

Die dabei identifizierten Hinweise wurden umgesetzt und sind der Übernahme aus dem Backup geschuldet.

sudo gitlab-psql -d gitlabhq_production -c "ALTER DATABASE gitlabhq_production REFRESH COLLATION VERSION;"

sudo gitlab-rake db:migrate RAILS_ENV=production

Ergebnis

Nach einem Neustart des GitLab-Services, erneutem Reconfigure und einem finalen Restart waren alle Projekte wieder verfügbar.

Der abschließende Schritt war die Absicherung des Systems durch ein funktionierendes Backup sowie die Automatisierung zukünftiger Sicherungen. Gleichzeitig ergaben sich wichtige Lessons Learned: Zusätzlich zum Systembackup sollte auch ein dediziertes GitLab-Backup über sudo gitlab-backup create STRATEGY=copy fest in den Backup-Prozess integriert werden.

In diesem Sinne: Always back up your data!

Bildquelle: KI-generiert

Der Beitrag GitLab SSD Super-Gau erschien zuerst auf DasKIAS.

Bildquelle: KI-generiert

Vom Alleinkämpfer zum Teammitglied

Wie so oft gilt: Sobald etwas eine bestimmte Größe oder einen gewissen Reifegrad erreicht, wird es komplexer. Wer ein Softwareprojekt allein umsetzt, benötigt – abgesehen von einer Entwicklungsumgebung / IDE – erst einmal nichts weiter.

Sobald ein Projekt im Team umgesetzt wird, sollten Zeit und Gedanken in eine gemeinsame Basis investiert werden. Gerade kleine Teams stehen dabei vor der Frage: Wie organisiert man das Ganze sinnvoll?

Verfügbarkeit vs. Sicherheit

Ein zentraler Punkt dabei ist der Spagat zwischen Verfügbarkeit und Sicherheit. Dienste vollständig über die Cloud also direkt im Internet zu nutzen klingt dabei verlockend. Bedenken muss man dabei auch den Aspekt der Sicherheit. Ein Dienst im Internet ermöglicht eine Vielzahl an Angriffsflächen. Themen wie Datenschutz, Portscans, unzureichend gesicherte Dienste oder fehlende Verschlüsselung sollten nicht unterschätzt werden.

Eine rein interne Infrastruktur mit Zugriff über VPN wirkt in kleinen Teams möglicherweise überdimensioniert, beschränkt jedoch die Angriffsvektoren rapide und senkt dadurch mögliche Risiken.

• Dienste sind nicht direkt aus dem Internet erreichbar
• Zugriff kann gezielt eingeschränkt werden
• Sensible Daten bleiben im eigenen Netzwerk

Gerade für kleine Teams kann das ein pragmatischer und sicherer Einstieg sein.

DIY Infrastruktur für kleine Teams

Für den Start muss es nicht sofort eine komplexe Serverlandschaft sein. Oft reicht einfache und kostengünstige Hardware. Sei es ein alter Server, der nicht mehr genutzt wird oder wie wir später zeigen ein Einplatinencomputer wie ein Raspberry Pi oder andere PI Varianten (Banana Pi, Rock Pi, …). Sie bieten genügend Leistung für typische Aufgaben im Bereich der Softwareentwicklung für Teams und vieles Weitere.

Wichtiger als die Hardware ist dabei ein durchdachtes Setup:

• Regelmäßige Updates
• Absicherung von Zugängen (SSH-Keys statt Passwörter)
• Firewall-Regeln
• Backups

Unverzichtbare Werkzeuge

Versionsverwaltung

Ein Versionsverwaltungssystem ist der erste und wichtigste Baustein. Waren früher Tools wie CVS und SVN beliebt wird heute häufig Gitlab eingesetzt. Neben der eigentlichen Versionsverwaltung bietet es zusätzliche Funktionen, z. B.:

• Benutzer- und Rechteverwaltung
• Issue-Tracking
• CI/CD-Pipelines

Gerade die Rechteverwaltung ist ein wichtiger Sicherheitsaspekt, um den Zugriff auf Code gezielt zu steuern.

Build- und Automatisierungsprozesse

Für automatisierte Builds und Deployments kann neben integrierten Lösungen (wie o. g. Gitlab) auch ein separates Tool wie Jenkins genutzt werden. Vorteile sind u. a.:

• ein schneller Einstieg
• flexible Erweiterbarkeit
• gute Dokumentation

Wichtig ist hierbei, auch die Build-Infrastruktur abzusichern, da sie häufig Zugriff auf sensible Daten (z. B. Zugangsdaten oder Schlüssel) hat.

Artefaktverwaltung

Ein oft unterschätzter aber auch relevanter Faktor ist ein Artefakt-Repository wie Sonatype Nexus Repository.

Hier können:

• erzeugte Artefakte zentral bereitgestellt werden
• externe Abhängigkeiten kontrolliert verwaltet werden
• Versionen nachvollziehbar archiviert werden

Gerade aus Sicherheitssicht ist es sinnvoll, Abhängigkeiten nicht direkt aus dem Internet zu beziehen, sondern zentral geprüft bereitzustellen. Die Quellen lassen sich zudem gezielt beschränken.

Security First

Die Sicherheit muss von Anfang an mitgedacht werden. Auch wenn es zunächst wie überflüssiger Aufwand wirkt – Security First sollte von vorne bedacht werden. Nachträgliche Anpassungen sind meist deutlich aufwendiger und schwerer zu implementieren.

Einige grundlegende Maßnahmen:

• Dienste nicht unnötig öffentlich erreichbar machen
• Zugriff über VPN oder eingeschränkte Netzwerke ermöglichen
• Regelmäßige Updates und Patches einspielen
• Backups automatisieren und regelmäßig testen
• Zugriffe und Änderungen protokollieren

Praxisbeispiel

Anhand unseres kleinen Teams beschreiben wir eine kompakte Infrastruktur im 10-Zoll-Netzwerkschrank*. Ein solcher Netzwerkschrank benötigt wenig Platz, sorgt für Ordnung, schützt die Hardware und ist in Verbindung mit den beschriebenen Raspberry Pi völlig ausreichend.

• Drei Raspberry Pi übernehmen unterschiedliche Aufgaben als zentrale Server
• Ein NAS* wird für Backups verwendet
• Ein Switch* und Patchpanel* sorgt für die interne Vernetzung

Optional kann das Setup um eine USV* erweitert werden (um z. B. Stromausfälle zu überbrücken).

Die beschriebenen Infrasturktur-Services könnte man z. B. wie folgt aufteilen:

• Raspberry Pi 1: Versionsverwaltung (Gitlab)
• Raspberry Pi 2: CI und Build-Prozesse (Jenkins) + Artefakt Repository (Nexus)
• Raspberry Pi 3: Zusatzdienste wie Monitoring und VPN

Ein solcher Aufbau ist vergleichsweise kostengünstig, überschaubar in der Wartung und gleichzeitig flexibel genug für stetig wachsende Herausforderungen.

Im Bild dargestellt ist unser – noch nicht ganz aufgeräumtes – Beispiel-Setup. Da die Infrastruktur kontinuierlich weiterentwickelt wird, erfolgt aktuell beispielsweise die Umstellung des Raspberry Pi für die Versionsverwaltung auf eine SSD, um neue Szenarien zu ermöglichen und für zukünftige Anforderungen besser gerüstet zu sein (fehlt daher im Bild).

Für eine bessere Strukturierung bei optimaler Platzausnutzung bietet ein spezielles Raspberry Pi Rack z. B. von GeekPi an*.

* Affiliante Link: Als Amazon-Partner verdienen wir an qualifizierten Verkäufen. Weitere Infos unter partnernet.amazon.de

Der Beitrag Softwareentwicklung – Wenn aus einer Idee etwas Ernstes wird erschien zuerst auf DasKIAS.