SM-Appliance: Migration von 1.4.x nach 1.5

Nach dem Release der neuen SMA-Version 1.5 steht bei vielen Kunden das Update auf der To-Do-Liste.

Die ursprünglichen Planungen, das SMA-Update auch über die interne Aktualisierungsfunktionalität bereitzustellen, mussten leider aufgegeben werden. Die Änderungen im Basissystem und die vielen verschiedenen Konfigurationen, die bei den Kunden vorzufinden sind (physische / virtuelle Appliance, Netzwerkkonfiguration, Festplattenkonfiguration), machen ein sicheres Inplace-Update sehr komplex. Die oberste Prämisse ist immer, ein "Bricking" der aktuellen Installation und damit einhergehende potenzielle Datenverluste zu verhindern. Dies lässt sich mit einem Inplace-Update über drei Major-Releases nur schwerlich gewährleisten.

Zwar besteht die Möglichkeit, die SMA zu sichern, jedoch enthält dieses monolithische Backup auch diverse Dateien, die nicht mit Debian 12 kompatibel sind. Daher wurde beschlossen, die Migration über das parallele Aufsetzen einer neuen SMA und den anschließenden Umzug von den Appliance-Einstellungen sowie von i-doit und / oder Checkmk durchzuführen. Zusätzlich kann man auf diesem Weg auch alten Ballast abwerfen. Beispielsweise kann bei der Installation direkt auf Hardware die Migration genutzt werden, um eine Virtualisierungslösung (zum Beispiel VMware oder Proxmox) als Basis zu verwenden, sodass auch Funktionalitäten wie Hochverfügbarkeit, Snapshots oder mehrere parallel installierte Appliances genutzt werden können. Für die Durchführung der Arbeiten benötigt man lediglich ein SSH-fähiges Terminal (wie zum Beispiel PuTTY oder die Power Shell) sowie einen Browser.

Die Migration lässt sich in vier Abschnitte unterteilen:

Schritt 1

Deployment und Grundkonfiguration der neuen SMA

Die SMA wird in der aktuellen Version wie auch bisher als virtuelle Appliance im OVA-Format zur Verfügung gestellt. Andere Installationsmethoden (zum Beispiel für die direkte Installation auf einem Cloudserver) sind in der Entwicklung. Ein wichtiger Punkt ist das Anpassen der durch die OVA vorgegebenen Hardwarekonfiguration (Anzahl der CPUs, Speicherkapazität und Festplattengröße). Hier ist es sinnvoll, sich an den Werten der alten SMA zu orientieren.

Nach dem ersten Start kann man über die physische Konsole wie gewohnt das Systempasswort setzen und erste Anpassungen vornehmen. Dies wäre zum Beispiel der richtige Zeitpunkt, um die Netzwerkeinstellungen (standardmäßig DHCP) zu modifizieren. Welche IP-Adresse sollte man wählen? Im Zielzustand ist es natürlich sinnvoll, die IP der abzulösenden SMA zu nutzen. Dadurch erspart man sich verschiedene Anpassungen, zum Beispiel im DNS oder in der Firewall. Für den Interimsbetrieb während der Grundkonfiguration kann man eine beliebige freie IP-Adresse nutzen.

i-doit

Um später per SSH auf den i-doit-Container zugreifen zu können, muss in der Appliance-Konfiguration ein Passwort für den idoituser gesetzt werden:

Checkmk

Für Checkmk sollten bereits Sites in der gleichen Version und mit dem gleichen Namen sowie Passwort wie auf der alten SMA angelegt werden.

Nach einem Test, ob man per SSH auf die Appliance zugreifen kann, ist die neue SMA einsatzbereit:

ssh NEUE-SMA-IP -l SITENAME -p 23 # Zugriff auf Checkmk, Passwort ist das initiale cmkadmin-Passwort
ssh NEUE-SMA-IP -l idoituser -p 24 # Zugriff auf i-doit

Schritt 2

Vorbereitende Maßnahmen auf der abzulösenden SMA

Neben der Grundkonfiguration der neuen SMA sind auch einige migrationsvorbereitende Schritte auf dem alten SMA-System durchzuführen.

Als Erstes sollte auch im Vorfeld an ein Backup der alten SMA gedacht werden (per SMA-Backup-Funktion oder per Snapshot), denn wie ein altes Sprichwort sagt: "Man hat schon Pferde vor der Apotheke k***en sehen."

i-doit

Wenn Sie i-doit nutzen, muss sichergestellt werden, dass die i-doit-Version mindestens 30 beträgt, da mit der neuen SMA PHP 8.2 und MariaDB 10.11 mitgeliefert werden. Auch die genutzten Add-ons sollten entsprechend aktualisiert werden.

Etwaige aktive i-doit-Cronjobs sollten deaktiviert werden, um zu verhindern, dass nach der Migration auf der alten SMA noch i-doit-Daten verändert werden. Die Cronjobs sind meistens unter /etc/cron.d zu finden; dort sollten in den betreffenden Dateien die entsprechenden Cronjobs auskommentiert werden.

Um den Zugriff vom und auf das zu migrierende i-doit zu verhindern, kann der Webserver ausgeschaltet werden. Dazu folgenden Befehl als idoituser per SSH auf der alten SMA im i-doit-Container ausführen:

sudo systemctl stop apache2.service

Checkmk

Eine aktive Checkmk-Site muss mindestens Version 2.1.0p31 aufweisen, damit sie migriert werden kann; ältere Versionen stehen unter Debian 12 nicht zur Verfügung.

Schritt 3

Datenmigration

i-doit

Die für i-doit benötigten Dateidaten liegen größtenteils unter /var/www/html/i-doit. Ausnahmen sind etwaige Cronjobs, die üblicherweise unter /etc/cron.d zu finden sind, sowie CA-Zertifikate, die standardmäßig unter /usr/local/share/ca-certificates gespeichert werden.

Die Migration kann auch gut dazu genutzt werden, alten Ballast loszuwerden. Ein beliebter Kandidat sind dabei die Log- und Temp-Verzeichnisse /var/www/html/i-doit/log sowie /var/www/html/i-doit/temp. Hier können alle nicht mehr benötigten Logdateien und alle Temp-Dateien gelöscht werden.

Folgende Befehle nach dem Einloggen per SSH auf der neuen SMA migrieren die Dateidaten von der alten SMA:

# Temporären Migrationsordner erstellen
sudo install -m 1777 -d /preserve/sma-migration

# Daten per SSH holen  
sudo scp -P 24 -r idoituser@ALTE-SMA:/var/www/html/i-doit/ /preserve/sma-migration/

# Daten ins Ziel kopieren  
sudo cp -r /preserve/sma-migration/i-doit /var/www/html/

# Rechte neu setzen  
cd /var/www/html/i-doit/  
sudo chown www-data:www-data -R .  
sudo find . -type d -exec chmod 775 {} \;  
sudo find . -type f -exec chmod 664 {} \;

Nach der Dateimigration muss auch die Datenbank migriert werden. Dazu werden im ersten Schritt auf der alten SMA beide relevanten Datenbanken gesichert. Das für den Zugriff benötigte MySQL-Passwort (im Folgenden PASSWORT_ALT genannt) findet man in der Datei /var/www/html/i-doit/src/config.inc.php:

# Erstellen eines Datenbank-Dumps auf der alten SMA 
sudo mysqldump -u root -p idoit_system > /preserve/idoit_system.sql  
sudo mysqldump -u root -p idoit_data > /preserve/idoit_data.sql

Nun können diese Datenbanken auf dem neuen i-doit eingespielt werden, und die Rechte sollten entsprechend gesetzt werden:

# Daten per SSH holen  
scp -P 24 idoituser@ALTE-SMA:/preserve/idoit_*.sql /preserve/sma-migration/

# Dump einspielen   
mysql -u root -p idoit_system < /preserve/sma-migration/idoit_system.sql  
mysql -u root -p idoit_data < /preserve/sma-migration/idoit_data.sql

# Rechte anpassen 
mysql -u root -p
ALTER USER 'root'@'127.0.0.1' IDENTIFIED BY 'PASSWORT_ALT';
GRANT ALL PRIVILEGES ON idoit_system.* TO 'idoit'@'localhost' IDENTIFIED BY 'PASSWORT_ALT';  
GRANT ALL PRIVILEGES ON idoit_data.* TO 'idoit'@'localhost' IDENTIFIED BY 'PASSWORT_ALT';  
exit;

Zum Abschluss sollten noch die Cronjobs migriert werden. Dafür kann seit der SMA 1.5 auch die Datei /etc/cron.d/customer-cronjobs genutzt werden, die persistent auch Container-Updates überlebt. Auch etwaige CA-Zertifikate können vom Altsystem migriert werden.

Damit ist i-doit vollständig migriert. Wenn der Funktionstest über die Oberfläche erfolgreich verläuft, können in /tmp das i-doit-Verzeichnis sowie die beiden Datenbank-Dumps gelöscht werden.

Checkmk

Für Checkmk müssen im Wesentlichen nur auf der neuen SMA die Sites als der jeweilige Site-User über SSH mit den Checkmk-Bordmitteln gesichert und wieder eingespielt werden:

# Als Site-User auf der alten SMA
omd backup /preserve/DATUM-SITE-NAME-backup.tar.gz

# Als Site-User auf der neuen SMA
sudo install -m 1777 -d /preserve/sma-migration
scp -P 23 SITEUSER@ALTE-SMA:/preserve/DATUM-SITE-NAME-backup.tar.gz /preserve/sma-migration/
omd restore --reuse --kill /preserve/sma-migration/DATUM-SITE-NAME-backup.tar.gz

Eventuell muss noch der Nullmailer konfiguriert werden:

sudo dpkg-reconfigure -p low nullmailer

Aufräumen

Zum Abschluss können nach erfolgreichem Test noch die Migrationsdaten wieder aufgeräumt werden:

sudo rm -rf /preserve/sma-migration

Schritt 4

Außerdienststellung der alten SMA und Inbetriebnahme der neuen SMA

Damit ist der Großteil der Migration abgeschlossen. Es bleiben letzte Restarbeiten:

Einrichtung des SMA Backups (CIFS-Freigaben und Sicherungsjobs)
Einbinden des SSL-Zertifikats
Einrichtung der LDAP-Anbindung
Online-Registrierung der neuen SMA
Abschalten der alten SMA
Übernahme der Netzwerkkonfiguration aus der alten SMA

Da all das wie bislang funktioniert, sei hier lediglich auf die bestehende Knowledge Base verwiesen: https://smdocu.atlassian.net/wiki/spaces/SMA/.

Falls es bei der Migration zu unvorhergesehen Herausforderungen kommen sollte, können Sie sich natürlich jederzeit im Rahmen Ihrer Supportverträge vertrauensvoll an uns wenden.

Autor: Robert Frießleben

Leistungen von SHD