© pryzmat / 123RF.com

In vielen Unternehmen finden sich alte Setups aus grauer Vorzeit, die noch immer eine wichtige Rolle spielen, deren Wartung aber zunehmend zum Problem gerät. Ein Beispiel zeigt, wie man sie einhegt und idealerweise durch Updates loswird.

Ein typischer Albtraum eines Systemadministrators spielt sich ungefähr so ab: Kurz nach Antritt eines neuen Jobs stolpert er über einen Server sichtlich älteren Datums. Der bereits seit einiger Zeit in der Firma beschäftigte Kollege vermag die Frage, wofür die Kiste gut sei, allerdings nicht zu beantworten. So wirklich wisse das niemand, der Server sei ein Relikt aus grauer Vorzeit. Von jenen, die ihn noch aktiv administriert haben, sei im Unternehmen längst keiner mehr tätig. Es werde lediglich davor gewarnt, das Konstrukt zu verändern oder sich darauf auch nur einzuloggen: Irgendein wichtiger Dienst, der keinesfalls ausfallen dürfe, sei darauf noch beheimatet.

Kurze Zeit später fällt im Rahmen der ersten Bereitschaft des neuen Admins aber eben dieser Server aus, und Debugging-Versuche scheitern schon daran, dass die Anmeldung auf dem System nicht funktioniert. An dieser Stelle wacht der Administrator hoffentlich schweißgebadet auf, und das Ganze war nur ein Nachtmahr. In vielen Unternehmen sind Geisterserver (Abbildung 1) jedoch kein Albtraum, sondern traurige Realität, und zwar in allerlei Spielarten und Variationen – tickende Zeitbomben in der Standardgröße 19 Zoll.

Abbildung 1: Auch alte Computer gehen irgendwann den Weg alles Irdischen. Wer den passenden Zeitpunkt fürs Abschalten alter Systeme verpasst, geht große betriebliche Risiken ein. Quelle: Jeramey Jannene

Entsprechende Systeme stehen in Konzernen ebenso wie in Klein- und Kleinstunternehmen, dort allerdings deutlich häufiger. In Großunternehmen findet sich erfahrungsgemäß früher oder später jemand, der die Notbremse zieht und einen Plan schmiedet, um gammelige Hardware mitsamt ihrer ebensolchen Software in den Ruhestand zu schicken. Oft genug passiert das allein deshalb, weil Admins im Konzern keine Lust auf das Blame Game haben, das vielerorts im Falle eines Ausfalls praktisch unvermeidlich wäre.

Dieses Korrektiv fehlt in kleineren Unternehmen, und so nimmt das Unglück seinen Lauf. Dabei erscheint es in vielen Farben und Formen: Mal stoßen Ganoven von außen auf alte und schlecht gesicherte Systeme, deren Daten sie umgehend abzweigen. In anderen Fällen verabschiedet sich nach langjährigem Betrieb plötzlich die Hardware ins Jenseits, typischerweise eine Festplatte, und es fehlt jegliches Backup. Öfter, als man denkt, läuft alte Software aufgrund eines Bugs nach Jahren plötzlich Amok. Ganz gleich, was den plötzlichen Ausfall hervorruft: Nicht selten steht im Anschluss die gesamte produktive Arbeit im Unternehmen still.

Vermeiden lässt sich ein derartiger plötzlicher Knalleffekt nur durch präventive Maßnahmen. Die aber sind spezifisch und für den jeweiligen Einzelfall zu planen. Dieser Artikel zeigt die Möglichkeiten auf und verrät, welche Vorbereitungen unter welchen Bedingungen notwendig oder sinnvoll sind. In vielen Fällen braucht es ein mehrstufiges Konzept, das den bestehenden Betrieb zunächst absichert und daraufhin die Migration weg vom prähistorischen Equipment geordnet ablaufen lässt.

Den Ist-Stand erheben

Am Anfang aller Überlegungen zum Beseitigen von Altlasten steht die genaue Analyse der Situation. Das klingt wie eine Binsenweisheit, und trotzdem gehen gerade in kleineren Unternehmen die Macher oft eher unstrukturiert an die Sache heran. Das rächt sich im Zweifelsfall, entweder durch Ausfälle oder noch schlimmer durch Datenverluste.

Eine zentrale Rolle spielt bei der Bestandsaufnahme das Erfassen der dringendsten Punkte und ihre Priorisierung. Handelt es sich um besonders alte Hardware, birgt ein Ausfall einzelner Komponenten ein großes Risiko. Läuft hingegen alte Software in virtuellen Instanzen, ist das Thema Hardware von eher untergeordnetem Interesse. Selbst von einem betagten Virtualisierungs-Host lässt sich eine Instanz meist relativ gut auf ein anderes System umziehen. Hier steht eher der Sicherheitsaspekt im Vordergrund – dann allerdings mit noch mehr Dringlichkeit als bei Hardware, die Sie kurz vor dem Dahinscheiden wähnen.

Passende Fragen zur Analyse der Sachlage sind zum Beispiel: Wie alt ist die betreffende Hardware? Welche Teile und Komponenten sind darin verbaut, und seit wann laufen sie? Ebenso kritisch ist die Frage nach den betroffenen Diensten. Welche Services stellt die fragliche Hardware bereit, und welche anderen Dienste im Unternehmen verwenden sie? Gibt es Abhängigkeiten von den sehr alten Systemen zu weiteren Servern, Diensten oder anderen Vorrichtungen im Unternehmen?

Der Autor dieses Artikels erinnert sich beispielsweise an einen Fall, bei dem die zentrale Steuerung einer “smarten” Türschließanlage aus grauer Vorzeit auf einem uralten Virtualisierungs-Host beheimatet war. Ein neuer Mitarbeiter prüfte nicht sorgfältig genug, wozu dieses System diente, und räumte es kurzerhand ab. Danach war es eine ganze Weile nicht mehr möglich, die eigentlich zentral gesteuerten Türen im Unternehmen zu bedienen. Stattdessen musste man sämtliche Mitarbeiter flott mit echten Schlüsseln ausstatten. Die Konsolidierung alter Infrastruktur ist wichtig und richtig, nicht aber auf diese Art und Weise.

Rückt darüber hinaus das Thema Sicherheit in den Fokus, sind insbesondere die möglichen Verbindungen und die genutzten Versionen relevant. Hängt ein Dienst direkt und offen im Internet, gilt es, das Alter der fraglichen Software zu prüfen und abzuklären, und ob dafür Sicherheitswarnungen etwa in Form von CVEs vorliegen. Falls ja, ist es aus administrativer Sicht höchste Eisenbahn – mit einiger Wahrscheinlichkeit erfordert die Situation ein sofortiges Eingreifen. Das kann schon darin bestehen, dass Sie prüfen, ob das betroffene System seine Internet-Verbindung wirklich noch braucht oder ob es sich so umbauen lässt, dass ein rein lokaler Zugriff genügt.

Optionen erörtern

An die Bestandsaufnahme schließt sich das Erörtern der möglichen Auswege an. Die hängen stark von der jeweiligen Situation ab und sind individuell. Haben Sie ein gut gepflegtes System vor der Nase, das allerdings – direkt oder über den Umweg der Virtualisierung – noch auf alter Hardware läuft, lässt sich die Migration noch einigermaßen leicht meistern. Eine VM ziehen Sie schlicht auf einen anderen Computing-Knoten um, auch wenn Sie den erst bauen müssen. Werkzeuge, die auf echtem, aber altem Blech laufen, lassen sich oft recht unkompliziert in eine VM verschieben. Die größten Gefahren wären damit schon gebannt.

Die Regel ist eine solche Situation jedoch nicht. Wahrscheinlicher bekommen Sie es mit alter Hardware zu tun, die genauso uralte Software benutzt. Hier präsentiert sich die Software regelmäßig als der größere Stressfaktor, weil Probleme mit Sicherheitsbezug gegeben sind. Wie erwähnt, steht im ersten Schritt das Senken des operativen Risikos auf dem Plan – beispielsweise, die Verbindung des Systems ins Internet zu kappen. Was sich von außen nicht erreichen lässt, kann auch niemand hacken.

Im Anschluss empfiehlt sich der Umzug auf andere Hardware, möglicherweise in Form einer Migration in eine virtuelle Maschine. Dabei stehen mehrere Ansätze zur Verfügung: Der einfachste Weg besteht meist darin, das alte System temporär offline zu nehmen und zunächst ein Abbild des dortigen Datenträgers zu erzeugen. Das nutzen Sie danach als RAW-Gerät oder – nach der Konvertierung ins QCOW2-Format – als Festplatte für eine KVM-Instanz. Möglicherweise müssen Sie die Einstellungen für Geräte wie die Netzwerkadapter anpassen. In jedem Fall bietet dieser Prozess eine gute Möglichkeit, sich von Uralthardware zu verabschieden.

Die Migration alter Software auf neue Hardware stellt aber nur einen Zwischenschritt dar. Haben Sie sie vollzogen, folgt direkt die nächste Aufgabe: das Aktualisieren der Software selbst. Dabei hat es sich bewährt, einen Klon der produktiven Instanz für Experimente zu erstellen und daraufhin die einzelnen Komponenten Stück für Stück zu aktualisieren, bis Sie bei zeitgenössischen Versionen ankommen. Das klappt freilich nur, wenn es sämtliche beteiligten Softwarekomponenten noch gibt. Alles, was darüber hinausgeht, bedarf der genauen Betrachtung im Einzelfall.

Praxisbeispiel

Wie die Rettung eines alten Setups konkret aussehen kann, verdeutlicht ein Beispiel aus der Praxis des Autors. Die Ausgangssituation zeigte sich denkbar alltäglich: Ein mittelständisches Unternehmen hatte vor etlichen Jahren eine klassische NAS-Appliance erworben, vorrangig für das Anlegen von Backups der wenigen firmeneigenen Computer. Das ist grundsätzlich löblich – immerhin fällt das Thema Backup per se in vielen KMU schon aus Mangel an Know-how und an Wissen um die schiere Notwendigkeit unter den Tisch.

NAS-Appliances von Synology und Qnap besitzen den großen Vorteil, dass sie mit einer grafischen, einfach zu bedienenden Oberfläche daherkommen. Geht es also bloß darum, ein Macbook per Time Machine an ein Netzlaufwerk anzubinden oder das NAS als Sicherungsziel für ein Backup-Werkzeug unter Windows zu hinterlegen, liegt das selbst für wenig computeraffine Kleinstunternehmer durchaus im Bereich des Möglichen.

Dabei blieb es im konkreten Fall aber nicht, denn ein Mitarbeiter des Unternehmens, der über etwas mehr IT-Wissen verfügte als seine Kollegen, hatte vor vielen Jahren der Versuchung nicht widerstehen können und im App-Marketplace des NAS-Herstellers gestöbert. Dort stieß er auf eine fertig vorbereitete CRM-Appliance. Weil das Unternehmen seinerzeit ohnehin auf der Suche nach einer Möglichkeit war, die eigenen Kundendaten zu speichern und zu verwalten, wählte man kurzerhand den Weg des geringsten Widerstands: Man installierte mit wenigen Mausklicks die SugarCRM-Appliance des Herstellers auf dem lokalen NAS. Bei dem Mittelständler lief davor wie danach allerdings beinahe alles schief, was in der Theorie schieflaufen kann. Das galt sowohl für die Ebene der Software als auch für jene der Hardware.

Los ging die Malaise bereits beim Zusammenstellen der Hardware, die im Speicherkistchen vor sich hin werkelte. Aus Mangel an Wissen und aus finanziellen Überlegungen heraus hatte man das Gerät nicht fertig konfektioniert vom Hersteller erworben, also als Bundle aus Gerät und Festplatten. Das wäre zwar möglich gewesen, hätte das Budget aber stärker belastet als die tatsächlich angeschaffte Lösung. Weil in KMU das Geld chronisch knapp ist, entschied man sich stattdessen für eine Bastellösung: Man kaufte das eigentliche NAS und die Massenspeicher dafür separat voneinander.

Beim Beschaffen der Festplatten – zwei 2-TByte-Platten für den Betrieb als RAID 1 – achtete das Unternehmen jedoch nicht darauf, für den Dauerbetrieb in einem NAS geeignete Disks (Abbildung 3) zu beschaffen. Die wären vermutlich in Summe mit dem NAS ebenso teuer gewesen wie das Bundle des Herstellers. Also werkelten vor Ort zwei Desktop-Festplatten (Abbildung 2) vor sich hin, die sich laut Datenblatt nicht für den Dauerbetrieb eigneten [1]. Sehr zur Überraschung des Autors versahen Sie aber nach wie vor klaglos ihren Dienst. Das muss jedoch eher als glücklicher Zufall gelten, zumal das Gerät zum Zeitpunkt der ersten Untersuchungen bereits seit über sieben Jahren im Betrieb war.

Abbildung 2: Western-Digital-Laufwerke der Red-Serie eignen sich, wie auf dem Aufkleber gut zu sehen, für den NAS-Betrieb. Weil sie etwas teurer sind, greifen gerade KMUs aber lieber zu billigeren und ungeeigneten Alternativen. Quelle: Western Digital

Abbildung 3: Die Blue-Serie von Western Digital umfasst eine Reihe solider Festplatten für Desktops. In NAS-Geräten haben diese Disks allerdings nichts zu suchen, denn ihnen fehlt die Eignung für den Dauerbetrieb. Quelle: Western Digital

Quasi als Sahnehäubchen stellte sich zudem heraus, dass die Festplatten zwar wie geplant Backups der Notebooks des Unternehmens enthielten. Für das CRM, das auf dem Gerät quasi als Nebendienst mitlief, fehlten allerdings jegliche Datensicherungen. Technisch wären sie durchaus einzurichten gewesen, denn das NAS hatte eine integrierte Funktion für verschlüsselte Backups in der Cloud, konkret in AWS S3. Doch das hatte man – einmal mehr aus Unkenntnis – gar nicht erst eingerichtet.

Die schlechten Nachrichten im Hinblick auf das fragliche Gerät rissen damit noch nicht ab. Auf Seiten der Software lag ebenso einiges im Argen. Das CRM als Zusatzdienst auf dem NAS hatte sich vor vielen Jahren relativ einfach in Betrieb nehmen lassen, aber irgendwelche Wartungsarbeiten gab es seither weder an der Hard- noch an der Software. 2023 lief deshalb noch immer die ursprünglich installierte Version SugarCRM 6.1.3 (Abbildung 4).

Abbildung 4: SugarCRM in der Community Edition war lange eine beliebte CRM-Option, existiert in dieser Form aber schon seit sieben Jahren gar nicht mehr. Wer auf ein solches Setup stößt, muss schleunigst handeln. Quelle: SugarCRM

Was das konkret bedeutet, sollen zwei Fakten verdeutlichen. Zum einen lagen zwischen der aktuellsten SugarCRM-Ausgabe und der auf dem NAS laufenden Version über 40 Releases, darunter vier Major-Versionen bis hoch auf SugarCRM 6.5. Zum anderen existiert die auf dem NAS betriebene Community Edition von SugarCRM schon seit Jahren gar nicht mehr: Die letzte veröffentlichte Version 6.5.25 stammt aus dem Jahr 2017. Seither steht SugarCRM ausschließlich in einer proprietären Form zur Verfügung, die Open-Source-Variante erhält keinerlei Updates mehr. Der gleichnamige Hersteller [2] hat sogar sämtliche Hinweise auf das einstige Open-Source-Projekt von seinen Systemen getilgt. Daher ist es nicht mehr möglich, ältere Versionen aus dem Netz herunterzuladen – was sich wenig später als großes Problem herausstellen sollte.

Immerhin: Das NAS besaß keine direkte Verbindung zum Internet. Der Mitarbeiter, der das System vor vielen Jahren installiert hatte, handelte zumindest in dieser Hinsicht geistesgegenwärtig und konfigurierte die darauf laufenden Dienste so, dass sie nur aus dem lokalen Netzwerk zu erreichen waren. Unmittelbare Gefahr durch Angreifer drohte insofern nicht. Sämtliche anderen Faktoren wogen zusammen jedoch schwer genug, um sofortigen Handlungsbedarf auszulösen.

Erschwerend kam hinzu, dass der verantwortliche Mitarbeiter inzwischen aus dem Unternehmen ausgeschieden war. Im Falle eines Problems, egal welcher Art, hätte es im Betrieb also niemanden mehr gegeben, der noch korrigierend hätte eingreifen können.

Ausgangssituation

Die Analyse vor Ort offenbarte schnell die größten Gefahren. Einerseits war damit zu rechnen, dass die Festplatten irgendwann den Geist aufgeben würden; ihre Lebenserwartung war bereits deutlich überschritten. Eine Migration der für den Unternehmenserfolg kritischen Daten war deshalb unerlässlich. Gleichzeitig war das CRM im Unternehmen aber ein zentraler Dienst. Die Daten per se waren zwar wichtig. Allerdings wären sie ohne die grafische Oberfläche des CRMs für das kleine Unternehmen nicht annähernd so nützlich gewesen wie innerhalb des CRMs selbst. Hinzu kam die Tatsache, dass ein klassisches NAS nicht gerade viele Werkzeuge bietet, um direkt auf dem Gerät Probleme aus der Welt zu schaffen oder Aktualisierungen auszuführen.

Weil SugarCRM CE seitens seiner Entwickler längst abgekündigt war, hatte außerdem der Anbieter des NAS die Appliance verworfen. Es gab zwar eine alternative Lösung, die aber keinen Pfad für eine unmittelbare Migration aufwies. Dementsprechend wäre eine Migration auf dem Gerät selbst für die Mitarbeiter des Unternehmens technisch schlicht nicht zu leisten gewesen. Sie hätte sich ohnehin kompliziert gestaltet: Zentrale Komponenten wie PHP oder Nginx hatte der NAS-Hersteller nämlich als Bestandteil seiner Appliance und in speziell für das Betriebssystem des NAS präparierter Form ausgeliefert. Auf dem NAS selbst lief jedoch keine Standard-Distribution, sondern eine Art Embedded Linux. Eine Shell gab es zwar, aber zentrale Werkzeuge standen lediglich über Busybox bereit. Das Einspielen von Updates scheiterte an deren mangelnder Verfügbarkeit ebenso wie an der Inkompatibilität zu praktisch allen gängigen Linux-Distribution. Nach etlichen Tests und vielen Gesprächen entschied man sich deshalb für ein mehrgliedriges Verfahren.

Im Fokus lag dabei primär die Sicherheit der Daten des CRMs. Hier hatte es der Hersteller den betroffenen Administratoren immerhin einigermaßen leicht gemacht und ein standardkompatibles MySQL verbaut. Zudem stand »mysql« auf der Kommandozeile zur Verfügung. SugarCRM hatte seine gesamten Nutzdaten in einer Datenbank in MySQL gespeichert, die sich über die Standardwerkzeuge des DBMS leicht in eine Datei ausgeben und auf ein anderes System kopieren ließ. Allerdings war es für die Befehle »ssh« und »scp« nötig, das aktuelle SSH auf einem Macbook zunächst so zu konfigurieren, dass es ältere Algorithmen für längst als unsicher und veraltet geltende SSH-Schlüssel akzeptierte. Nachdem die Admins diese Klippe umschifft hatten, lag ein vollständiges Backup der Daten aus SugarCRM CE vor. Damit reduzierte sich die unmittelbare Gefahr durch ausfallende Hardware deutlich.

Ganz nebenbei gebannt war dadurch außerdem die von einem Diebstahl des Geräts ausgehende Gefahr. Am Standort der Firma mitten in Berlin könnte es durchaus vorkommen, dass Räuber in ein Ladenlokal einbrechen und alles mitnehmen, was sie flott versilbern zu können glauben. Daraus hätte vor dem Anlegen des Backups ein kompletter Super-GAU für das Unternehmen resultiert, die Daten wären mit hoher Wahrscheinlichkeit vollständig und unwiederbringlich verloren gewesen. Das hätte nicht nur die Arbeitsfähigkeit und damit die Existenz des Unternehmens gefährdet, sondern darüber hinaus eine Meldepflicht beim Landesbeauftragten für Datenschutz ausgelöst und potenziell zu einer Strafe geführt.

Die DSGVO macht keine genauen Vorgaben im Hinblick darauf, mit welchen Mitteln Daten technisch vor dem Totalverlust zu schützen sind. Sie schreibt aber vor, Methoden auf der Höhe der Zeit zu verwenden. Davon hätte bei einem NAS ohne Backups mit eklatanten Lecks in der Firmware allerdings in keinem Szenario die Rede sein können – weder bei einem digitalen Einbruch in das Gerät noch bei einem Hardwarediebstahl.

Softwarearchäologie

Vom Eis war die Kuh damit noch nicht. So sehr sich der Inhaber des Unternehmens auch einzureden versuchte, durch die nun angelegten Backups sei doch irgendwie alles wieder in Ordnung: Ein wandelndes Softwaremuseum ist stets eine Last und nie ein Asset. An oberster Stelle muss dementsprechend immer das Ziel stehen, das Setup durch eine aktuelle Lösung zu ersetzen, statt nur die drängendsten Probleme zu beseitigen.

Trotz der Backups konnten die Festplatten schließlich noch immer ausfallen, was das CRM augenblicklich offline genommen und die Produktivität der Firma erheblich eingeschränkt hätte. Auch an den eklatanten Sicherheitslücken im Gerät hatte das Anlegen von Backups ja nichts geändert. Wäre es etwa jemandem gelungen, sich in das obendrein schlecht gesicherte WLAN vor Ort einzuloggen, hätte der Angreifer das NAS aufgrund der fehlenden Systemaktualisierungen ohne viel Aufwand kompromittieren können.

Der Update-Marathon war folglich keineswegs beendet. In den Mittelpunkt rückte nach der ersten Sicherung stattdessen ein konkreter Plan zum Abschalten des lokalen CRMs und des in die Jahre gekommenen Systems an sich. Ein solcher Vorgang setzte jedoch voraus, dass das Unternehmen über einen adäquaten Ersatz für das CRM verfügte.

Das stellte sich als deutlich schwieriger heraus als eingangs vermutet: Weil es SugarCRM schon eine ganze Weile nicht mehr gab, fanden sich keine Anbieter von Hosted-CRM-Lösungen, die eine Migration von der alten SugarCRM-CE-Version noch unterstützten. Eine solche SaaS-Lösung wäre schon deshalb wünschenswert gewesen, weil niemand mehr im Unternehmen arbeitete, der die Pflege eines selbst gehosteten CRM-Systems sicherstellen konnte. Daten importieren konnten die meisten Online-Anbieter aber nur aus der kommerziellen aktuellen Variante von SugarCRM oder dessen inoffiziellem Nachfolger SuiteCRM [3].

Dennoch kristallisierte sich an dieser Stelle ein erfolgversprechender Ansatz heraus: Gelänge es, die Uralt-Installation von SugarCRM 6.1 zunächst auf 6.5 zu aktualisieren, stünde ein Upgrade-Pfad zu SuiteCRM 7 offen, von der ein Umweg zu SuiteCRM 8 führen würde (Abbildung 5). Aus den beschriebenen Gründen erwies sich ein solches Unterfangen auf dem NAS-Gerät selbst allerdings als völlig unrealistisch. Die tatsächliche Softwarearchäologie begann hier also erst so richtig.

Abbildung 5: Der inoffizielle Nachfolger von SugarCRM ist SuiteCRM. Ein Upgrade-Pfad von SugarCRM 6.5 auf SuiteCRM 7 existiert zwar. Wer aber SugarCRM 6.5 nicht hat, geht im Netz erst einmal auf die Suche nach den verstreuten Patch-Paketen. Quelle: SuiteCRM

Blast from the past

Der Schlachtplan sah folgendermaßen aus: Zunächst galt es, das Setup des NAS mit Standardmitteln und vor allem einer Standarddistribution so gut nachzubauen, dass sich das uralte CRM darin tatsächlich betreiben ließ. Dann würden die Admins die Distribution einerseits und das CRM andererseits sukzessive aktualisieren, sodass sie letztlich bei aktuellen Versionen landeten. Von da aus boten sich zumindest die Optionen, das dann aktuelle CRM weiter selbst zu betreiben oder die Migration in ein gehostetes CRM vorzunehmen.

Dass er im Jahr 2023 nochmal ein Debian GNU/Linux 9 installieren würde, hatte der Autor nicht erwartet. Der Prozess stellte sich insgesamt aber als weniger problematisch heraus als anfänglich vermutet. In einer virtuellen Instanz entstand zunächst ein “Stretch”, dessen Versionsstände denen des NAS einigermaßen ähnlich waren und in dem das CRM-Setup einen Klon erhielt. Dazu landete das zuvor gezogene Datenbank-Backup in einer lokalen MySQL-Instanz. Die Nginx-Konfiguration des NAS schaffte es ebenso in die neu angelegte “alte” VM. Nach etwas Bastelei begrüßte den Administrator tatsächlich der Login des Uralt-Sugar-CRMs, diesmal jedoch in der VM und nicht auf dem NAS. Dann startete ein Marathon aus Aktualisierungen: Von PHP 5.6 und MySQL 5.5 aus stand zunächst das Update auf Debian 10 an. Das allerdings wäre für das installierte SugarCRM zu neu gewesen, weswegen es vorab auf die Version 6.2 zu heben war.

Mit zu den größten Herausforderungen dabei zählte es, die Update-Pakete für SugarCRM im Netz ausfindig zu machen. Wie schon erwähnt, standen sie auf der Webseite der Autoren nicht mehr zur Verfügung. Gepufferte MD5-Listen auf Google und die spezifische Suche nach Dateinamen führten zum Erfolg, zu guter Letzt waren alle nötigen Patch-Dateien beisammen. Zug um Zug schloss sich danach der Kreislauf aus CRM-Updates und Debian-Updates an. Was sich wie eine kleine Zeitreise im Eiltempo anfühlte, führte am Ende tatsächlich zu einem Debian GNU/Linux 12 mit halbwegs aktuellem PHP, MariaDB und SuiteCRM 8.

Eines der größten Ärgernisse während des gesamten Vorgangs kam dabei aus unerwarteter Richtung: MySQL 5.5 hatte viele an sich unsinnige Eingaben als syntaktisch korrekt akzeptiert. Beispielsweise ist »0000-00-00 00:00:00« kein valides Datum, doch ältere SugarCRM-Versionen tragen es exakt so widerspruchslos als »DATE«-Angabe in die Datenbank ein. Neuere Versionen von MariaDB zeigen sich deutlich rigoroser und verweigern den Start, wenn sie solche Einträge finden.

Ein großer Teil der Update-Arbeit bestand insofern darin, Müll aus der Datenbank zu entfernen oder durch valide Alternativen zu ersetzen. Letztlich brachte Beharrlichkeit über einen langen Zeitraum jedoch den ersehnten Erfolg, und das SugarCRM-Setup des NAS ging auf seine letzte Reise. Die Kiste selbst durchlief dann noch eine Migration (mittels vorbildlichem Migrationsassistenten des NAS-Herstellers) auf neue Hardware, bevor der Inhaber des Unternehmens auch hier den Stecker zog.

Fazit

Der beschriebene Vorgang zum Beseitigen von Altlasten bei Soft- und Hardware ist ein maßgeschneidertes Beispiel für eine sehr individuelle Problemlösung. Manche Details des Vorgehens lassen sich jedoch auch auf andere Situationen gut anwenden, beispielsweise das Nachstellen eines Setups im Labor, also in einer eigens angelegten VM.

Dadurch verschaffen Sie sich einerseits eine Spielwiese und andererseits eine Werkzeugkiste mit Standard-Tools, die gerade bei Appliances und Embedded-Systemen regelmäßig fehlen. Auch das sukzessive Aktualisieren von Datenbanken über separate Versionssprünge dürfte in ähnlich gelagerten Fällen einen vergleichbaren Nutzen entfalten und lässt sich auf andere Arten von Software sinngemäß anwenden.

Jedem Administrator, der sich ein solches Projekt vornimmt, muss jedoch klar sein, dass man hier nicht mit schnellen Fortschritten rechnen darf. Die CRM-Migration verschlang im Beispiel insgesamt fast 15 Arbeitstage, bis ein brauchbares Resultat vorlag. Sie war für den Unternehmer nur dadurch überhaupt zu stemmen, weil er mit dem Autor dieses Artikels befreundet ist und die Migration deshalb zum freundschaftlichen Pauschalpreis vonstattenging.

Im gesamten Prozess steckt insofern zudem ein kategorischer Imperativ: Pflegen Sie Ihre Systeme, und aktualisieren Sie sie regelmäßig, statt sie allmählich verrotten zu lassen. Die Pflege verursacht zwar einen Mehraufwand und (geringe) regelmäßige Kosten, kommt in Summe aber deutlich günstiger als der Betrag, den ein typischer Dienstleister für die CRM-Migration aufgerufen hätte. Wer billig kauft, kauft öfter und teurer – auch bei IT-Infrastruktur. (jcb)