Softwareentwicklung – Betrieb und Aktualisierung selbst gehosteter Systeme

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.

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 maneull). 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.