Projekte

@rtus (Artus) ist ein Vorgangsbearbeitungssystem (VBS) zur Dokumentation polizeilicher Vorgänge und strafrechtlicher Ereignisse. Das System ermöglicht die systematische Eingabe, Verwaltung und Analyse erhobener Daten. Entwickelt wird @rtus von Dataport, einem IT-Dienstleister der öffentlichen Verwaltung.

Der Landesbetrieb Daten und Information (LDI) verantwortet die Einführung und den Betrieb für Rheinland-Pfalz und das Saarland. In diesem Kontext wurde ich als externer Spezialist zur Unterstützung des Projekts hinzugezogen.

Mein Aufgabenbereich umfasste die Systemadministration der Linux-Serverumgebung, die auf RHEL und Debian basiert, sowie die Automatisierung von Bereitstellungs- und Wartungsprozessen mittels Ansible. Ein besonderer Fokus lag auf der Weiterentwicklung der bestehenden Ansible Collection: Ich optimierte die Performance, entwickelte neue Plugins in Python und implementierte zusätzliche Rollen. Bestehende Komponenten wurden refaktoriert, um eine bessere Idempotenz zu gewährleisten.

Die technische Realisierung beinhaltete die Administration und Automatisierung der @rtus-Backend-Server auf JBoss/Wildfly-Basis. Parallel dazu führte ich Teammitglieder in Ansible und Git ein, um sie zur eigenständigen Weiterentwicklung der Infrastruktur zu befähigen.

Nachdem am 30. Juni 2024 CentOS 7 nun sein End-of-Life (EOL) erreicht hatte und noch einige VMs damit vorhanden waren, musste eine Alternative her. CentOS 8 war keine Option mehr, da dieses bereits am 31. Dezember 2021 eingestellt wurde und ebenfalls sein EOL damit erreichte. CentOS Stream wäre eine Option gewesen, ist aber ein ganz anderes Konzept als seine Vorgänger. Für eine Produktivumgebung auf Grund des Rolling Release nicht geeignet, da es weniger stabil und vorhersehbar ist. Also kam nur noch eine Migration zu RHEL, SUSE, Oracle oder den freien Alternativen Rocky Linux und AlmaLinux in Frage. Auf Grund der freien Verwendbarkeit, der besseren Werkzeuge, der besseren Dokumentation und der vorhandenen freien Spiegelserver, habe ich mich für AlmaLinux entschieden.

Als erstes wurde also das CentOS 7 mit den CentOS-Repos von AlmaLinux versehen, Updates durchgeführt und mit Leapp auf AlmaLinux 8 angehoben. Hier konnten jetzt die installierten Programme geupdatet und danach das System auf AlmaLinux 9 weiter angehoben werden. Zum Schluss wurden wieder die installierten Programme geupdatet und verschieden Fehler behoben, so das wieder ein sicheres und funktionsfähiges System vorhanden war. Dies musste leider auf allen Systemen händisch erledigt werden, da diese unterschiedlich konfiguriert waren und jedes seine eigenen Probleme hatte.

Die Migration auf AlmaLinux sicherte eine stabile Basis für die nächsten Jahre. Updates und vor allem Sicherheitsupdates sind wieder möglich und alle installierten Programme sind wieder auf einem aktuellen Stand. Zum Schluss wurden die Server in den Ansible-Update-Job aufgenommen und werden jetzt regelmäßig aktuell gehalten.

Mit stetig wachsender Serveranzahl wurde die monatliche Server-Wartung zunehmend zeitintensiver. Um Wartungsaufgaben zu automatisieren und die Gesamtzeit zu reduzieren, fiel die gemeinschaftliche Entscheidung, Ansible für die Linux-Server in der heterogenen Windows-Linux-Infrastruktur einzuführen.

Ich implementierte einen Ansible-Server auf Debian-Basis mit Semaphore UI als Benutzeroberfläche. Die Integration mit dem bestehenden GitLab-Server ermöglichte eine strukturierte Entwicklung der Ansible Collections mit separatem Entwicklungs-Branch und temporären Feature-Branches. Semaphore UI bezog die Collections ausschließlich aus dem stabilen Main-Branch.

Zur Reduzierung des monatlichen Wartungsaufwands und gleichzeitigen Aktualisierung der Linux-Server entwickelte ich eine Collection mit zwei zentralen Rollen: tägliche Updates und wöchentliche bedarfsgesteuerte Neustarts. Das System startete Server intelligent nur bei tatsächlichem Bedarf neu. Die Wartung reduzierte sich dadurch auf eine simple Überprüfung der Job-History im Ansible-Server statt manueller Einzelupdates.

Die Entwicklungsabteilung erkannte das Potenzial und bat um Unterstützung bei der Optimierung des Arbeitsspeicherverbrauchs ihrer IIS-Anwendungen. Daraufhin entwickelte ich eine weitere Collection mit spezialisierten Rollen für das koordinierte App-Pool-Recycling. Die Lösung berücksichtigte Abhängigkeiten und implementierte intelligente Wartezeiten zwischen den Neustarts. Die nächtliche Ausführung dieser Automatisierung sorgte für deutlich verbesserte Performance und Stabilität während der Arbeitszeiten.

Das Ansible-System reduzierte den Wartungsaufwand erheblich, steigerte die Systemstabilität und schuf Kapazitäten für andere wichtige Aufgaben.

Als erstes Projekt nach meiner Einstellung bei der Strehlow übernahm ich die Modernisierung des Windows-Deployment-Servers, der sich in einem kritischen Zustand befand. Die Ausgangslage war problematisch: Der Server verteilte eine veraltete Windows-10-Version ohne separaten Update-Task, wodurch Updates während des Deployments unkontrolliert und danach noch ewig liefen. Die Hauptsoftware SaniVision wurde aufgrund ihrer Komplexität manuell dateiweise installiert, was zeitaufwendig und fehleranfällig war. Zusätzliche Software lag zwar aktualisiert auf dem Share, war aber nicht in WDS integriert. Bei bestimmten Hardwaremodellen wurden die Netzwerkkarten nach dem PXE-Boot nicht erkannt, wodurch USB-C-Adapter als Workaround nötig wurden. Touchpads und andere Hardware funktionierten ebenfalls nicht im Windows PE.

Phase 1: Stabilisierung des Bestandssystems

Zunächst reparierte ich den bestehenden Share durch Integration einer aktuellen Windows-10-Version und Korrektur der vorhandenen Software-Installationen und Skripte. Parallel entwickelte ich die erste Version eines PowerShell-Skripts zur automatisierten Installation der komplexen SaniVision-Software.

Phase 2: Strukturierter Neuaufbau

Ein komplett neuer Share mit ordentlicher Struktur wurde erstellt und Windows 11 integriert. Alle nötigen Windows-PE-Treiber wurden implementiert, wodurch Standard-Netzwerkanschlüsse und Touchpads im Windows Deployment Wizard verfügbar wurden. Die Task-Sequenzen wurden optimiert und ein Update-Task aktiviert. Das SaniVision-Skript wurde überarbeitet, neue Installationsskripte für weitere Software hinzugefügt und die grafische Darstellung zur besseren Fehlererkennung verbessert. Der erste Share blieb als Fallback-System erhalten.

Phase 3: Optimierung und Automatisierung

Basierend auf den gewonnenen Erkenntnissen wurde ein dritter, hochoptimierter Share erstellt. Die Skripte erhielten Abhängigkeitserkennung und verbesserte Fehlerbehandlung. Ein intelligenter Update-Mechanismus wurde implementiert: Neue Versionen mussten nur noch in das entsprechende Verzeichnis kopiert werden, das Skript erkannte automatisch die höchste Version und installierte diese. Hardware-Erkennungsskripte ermöglichten es, dass Treiber-Tasks nur noch gerätespezifisch notwendige Treiber installierten. Dies reduzierte die Anzahl der Task-Sequenzen auf eine einzige Standard-Sequenz statt mehrerer gerätespezifischer Varianten. Der erste Share wurde bei Fertigstellung dieser Phase endgültig gelöscht.

Das Ergebnis war eine vollständig automatisierte, unbeaufsichtigte Installation mit minimaler Fehlerquote. Die Deployment-Zeit wurde erheblich verkürzt, die Wartung vereinfacht und die Zuverlässigkeit des gesamten Systems deutlich gesteigert.

Die Überarbeitung des WDS-Servers hatte einen weiteren positiven Effekt. Installationen und Skripte, die als Workaround zu PDQ Deploy & Inventory ausgelagert und dort nach jeder Windows-Installation manuell angestoßen werden mussten, konnten wieder in den WDS-Server integriert werden. Dadurch wurde die klare Aufgabentrennung beider Systeme wiederhergestellt. Der WDS-Server übernahm fortan alle allgemeinen Installationen, während PDQ sich ausschließlich auf Updates und spezielle Installationen sowie Skripte konzentrierte.

Die Firma SCHUBERTH GmbH beauftragte uns mit der Entwicklung eines Deployment-Systems zur schnellen und einheitlichen Installation ihrer Thin-Clients. Die Anforderungen umfassten eine Linux-basierte Lösung mit automatischem Login und sofortigem Start des vorkonfigurierten VMware Horizon Clients.

Nach anfänglichen Verzögerungen übernahm ich federführend die Entwicklung. Die Lösung basierte auf Debian mit Preseed-Automatisierungen. Ich entwickelte ein Skript, das automatisch alle benötigten Komponenten zu einem bootfähigen ISO-Image zusammenstellte. Der Prozess umfasste die Konfiguration einer Preseed-Datei für die Debian-Einstellungen sowie die Integration verschiedener Mechanismen für die Horizon-Client-Installation, Autostart-Funktionen und Login-Skripte. Das Skript modifizierte eine Standard-Debian-ISO, indem es die erforderlichen Verzeichnisstrukturen erstellte, alle notwendigen Dateien integrierte, das GRUB-Menü anpasste und daraus ein neues ISO-Image generierte. Mit diesem Image konnten beliebig viele bootfähige USB-Sticks mit identischem Installationsergebnis erstellt werden.

Der Installationsprozess verlief vollständig automatisiert: Nach dem Booten vom USB-Stick konnte über das GRUB-Menü die unbeaufsichtigte Installation gestartet werden. Der Debian-Installer arbeitete alle Schritte selbstständig ab, wobei die Late-Commands die Installation des Horizon Clients sowie die Implementierung aller erforderlichen Skripte und Systemanpassungen übernahmen.

Im Produktivbetrieb startete das System automatisch, ein Überwachungsskript prüfte und korrigierte bei Bedarf Systemeinstellungen. Ein eingeschränkter Benutzer wurde automatisch angemeldet, woraufhin der Horizon Client im Vollbildmodus startete. Ein Monitoring-Skript überwachte kontinuierlich die Client-Ausführung und initiierte bei Beendigung sofort das Herunterfahren des Systems.

Die Lösung vereinfachte die Administration erheblich, defekte Systeme konnten innerhalb weniger Minuten neu installiert werden, aufwendige Fehleranalysen entfielen. Endanwender profitierten von der nahtlosen Integration, da sie direkt mit ihrer gewohnten VMware-Horizon-Umgebung arbeiten konnten, ohne Linux-Kenntnisse zu benötigen. Die Installation der Thin-Clients erfolgte selbstständig durch die SCHUBERTH-Administratoren, während wir für Anpassungen und Erweiterungen weiterhin zur Verfügung standen.

Die Geschäftsführung der LOOMA GmbH entschied sich für eine strategische Neuausrichtung, weg vom klassischen Systemhaus mit stundenbasierter Abrechnung, Wartungsverträgen und reaktivem Support, hin zu einem MSP-Modell mit fixen Preisen für Hardware und Managed Services inklusive proaktivem Support und automatisierten Prozessen.

Die Planungsphase fokussierte sich auf die Entwicklung der verschiedenen Service-Pakete und die Auswahl geeigneter Werkzeuge für Monitoring und Verwaltung. Kritische Fragestellungen wurden erarbeitet: Wie können bestehende Kundenprobleme proaktiv gelöst werden? Welche Mehrwerte entstehen für die Kunden? Rechtliche Aspekte wie Haftungsfragen bei Schäden oder Kundeninsolvenz wurden ebenso berücksichtigt wie die Herausforderung, Bestandskunden vom neuen Modell zu überzeugen und deren vorhandene Infrastruktur zu integrieren. Eine weiter wichtige Frage entwickelte sich während der Planungsphase: Was, wenn die Infrastruktur eines bestehenden oder neuen Kunden, nicht in das MSP-Modell integriert werden kann? Wer muss dann den Support für diese Komponenten übernehmen?

Die Umsetzung erfolgte schrittweise mit drei Kernservices: Managed Workplace, Managed Security und Managed Server. Für gleichbleibende und kundenspezifische Windows-Installationen wurde ein WDS-Server eingesetzt, der per Netzwerk (PXE) mehrere Geräte gleichzeitig provisionieren konnte. Als Monitoring-Lösung wurde Anfangs Paessler PRTG, final aber Zabbix implementiert. Als RMM-Lösung kam nach Verwendung von ManageEngine und SolarWinds schließlich Datto RMM zum Einsatz. Ein eigenes Ticketsystem wurde mit n8n/Zapier und Bubble entwickelt, das automatisierte Prozesse über APIs und Webhooks ausführen konnte und später um KI-Unterstützung erweitert wurde. Dies ermöglichte die Abbildung der MSP-Pakete, sowie spezialisierter Services wie Telematikinfrastruktur (TI) für Praxen. Die Sicherheitsarchitektur basierte auf Sophos-Produkten mit zentraler Verwaltung über Sophos Central, während Netzwerkkomponenten von Ubiquiti zentral über die Ubiquiti Cloud gemanagt wurden. Die bestehenden Office-Installationen und Exchange Server der Kunden wurden nach Microsoft 365 migriert.

Wie bereits in der Planungsphase vermutet, waren die Kundenreaktion gemischt. Während einige Bestandskunden das neue Modell ablehnten und wechselten, konnten sowohl andere bestehende als auch neue Kunden erfolgreich für das MSP-Modell gewonnen werden. Basierend auf ersten Erfahrungen wurden die Services kontinuierlich optimiert. Die sorgfältige Vorbereitung ermöglichte sofort eine proaktive Problemlösung und Früherkennung von Störungen. Automatisierungen wie zentral gesteuerte Windows-Updates reduzierten den Arbeitsaufwand erheblich und garantierten den Kunden stabile, sichere Systeme.

Die EQO Energiekonzepte GmbH verzeichnete mehrere Diebstähle auf den Baustellen ihrer Solarparks und beauftragte uns mit der Entwicklung eines mobilen Überwachungssystems. Die Anforderungen waren klar definiert: Das System sollte unauffällig, aber schnell und unkompliziert vor Ort installierbar sein. Da auf allen Baustellen Baustrom verfügbar war, konnte eine Standard-230-Volt-Installation realisiert werden.

Nach Erstellung eines detaillierten Komponentenplans und Abstimmung mit dem Kunden erfolgte die technische Umsetzung. Das System basierte auf einem LTE-Router für die Internetverbindung und Ubiquiti-Komponenten für die Überwachung: ein PoE-Switch, ein Cloud-Key für Verwaltung und Cloud-Upload sowie verschiedene Ubiquiti-Kameras. Alle Komponenten wurden in einem abschließbaren Verteilerkasten auf einem Lochblech montiert und mit Kabelbindern fixiert.

Die Konfiguration ermöglichte automatische Aufnahmen bei Bewegungserkennung mit direktem Upload in die Ubiquiti-Cloud. Bei Auslösung erhielten die Verantwortlichen E-Mail-Benachrichtigungen mit eingebundenen Bildausschnitten der Aufnahmen. Nach einer ausführlichen Einweisung übernahm der EQO-Mitarbeiter selbstständig den Auf- und Abbau des Systems an wechselnden Standorten.

Trotz gelegentlicher Fehlalarme durch Wildtiere, Wind oder Schnee erfüllte das System seinen Zweck: Unerlaubte Zutritte und Diebstähle wurden dokumentiert, wodurch diese teilweise verhindert oder zumindest so aufgezeichnet werden konnten, dass Kennzeichen oder Personen identifizierbar waren. Die Sicherheit auf den Baustellen wurde nachhaltig verbessert.

Für Fragen, Änderungen und Support standen wir dem Unternehmen auch nach der Implementierung weiterhin zur Verfügung.

Die Stadtwerke Wernigerode planten die Einführung eines Digital Signage Systems für zwei Einsatzbereiche: intern für Mitarbeiterinformationen in den Betrieben sowie als Werbesystem in den Kundenzentren. Die Wahl fiel auf Xibo als zentrale Plattform.

Meine Aufgabe in diesem Projekt bestand in der kompletten Servereinrichtung. Als technische Basis wählte ich Debian mit Apache HTTP Server und MySQL. Darauf baute ich das Xibo CMS auf und nahm die erforderlichen Systemkonfigurationen vor.

Die Installation und Anbindung der Xibo Player übernahmen die Administratoren der Stadtwerke in Eigenregie, was eine nahtlose Integration in die bestehende IT-Landschaft gewährleistete.

Nach Projektabschluss blieb ich als 3^rd-Level-Support verfügbar und übernahm die Schulung der Mitarbeiter im Umgang mit dem neuen System. Diese kontinuierliche Betreuung stellte sicher, dass die Stadtwerke das Digital Signage System optimal nutzen und eigenständig Kampagnen erstellen konnten.

Nach 2000 zogen zahlreiche Bundesbehörden und -institutionen nach Berlin um. Der Hauptstadtbeschluss von 1991 hatte einen langwierigen Umzugsprozess in Gang gesetzt, der sich teilweise bis in die späten 2010er Jahre erstreckte. Da sich die Aufgaben und Abläufe bei diesen Projekten weitgehend glichen, fasse ich sie hier zusammen.

Wir waren an mehreren dieser Umzüge in unterschiedlichen Phasen beteiligt. Die Projektumfänge variierten dabei: Bei einigen Behörden übernahmen wir die Vorbereitung der IT-Infrastruktur in Berlin, bei anderen den Abbau der Technik in Bonn. In vielen Fällen begleiteten wir den kompletten Umzugsprozess von der Demontage bis zur Neuinstallation.

Das Aufgabenspektrum umfasste häufig auch die Installation und Einrichtung kompletter Arbeitsplätze. Für diese umfangreichen Rollouts setzten wir anfangs die Remote Installation Services (RIS) ein, später wechselten wir auf die moderneren Windows Deployment Services (WDS). Diese automatisierten Deploymentlösungen, inklusive PowerShell-Scripten, ermöglichten es uns, hunderte von Arbeitsplätzen effizient und standardisiert einzurichten.

Ursprünglich sollte lediglich eine Möglichkeit geschaffen werden, mit der Kunden eigenständig Transportpreise für Sperrgut kalkulieren konnten. Diese Funktion wurde später in einen geschützten Kundenbereich mit Login-Funktion integriert und kontinuierlich erweitert. Nach und nach kamen weitere Features hinzu, darunter die Anmeldung für Abholaufträge und AVIS-Informationen.

Der anfängliche Sperrgutrechner entwickelte sich zu einem umfassenden Transportpreisrechner. Neben Normal- und Sperrgut konnten nun auch Zusatzleistungen wie Same-Day- und Next-Day-Lieferungen sowie Transportversicherungen berechnet werden.

Bereits mit der ersten Version war General Express dem Systempartner GO! Express & Logistics einen Schritt voraus. Die finale Ausbaustufe stellte sogar ein deutschlandweit einzigartiges System dar.

Ich setzte das Portal im Backend mit PHP und MySQL um, für das Frontend kam XHTML, CSS und JavaScript zum Einsatz. Die technische Realisierung erfolgte auf einem PHP-fähigen Webserver mit MySQL-Datenbank bei Strato.

Das Portal erfreute sich großer Beliebtheit bei Kunden aus Berlin und wurde später sogar bundesweit von Kunden der GO! genutzt. Mit kleineren Anpassungen und Erweiterungen blieb es bis zur Geschäftsaufgabe von General Express (2010) erfolgreich im Einsatz.

Bei diesem außergewöhnlichen Projekt ging es darum, die Medien-Communication Server (MeCom) des Deutschen Depeschendienst (ddp, damals noch ProSieben), ohne größere Ausfallzeit vom ProSieben-Rechenzentrum in Unterföhring ins Level-3-Rechenzentrum nach Berlin zu verlegen. Die besondere Herausforderung bestand darin, dass die Server nur innerhalb der redaktionsfreien Zeit transportiert werden konnten und eventuelle Transportschäden sofort zu beheben waren.

Das Zeitfenster war extrem knapp bemessen: Der Ausbau der Server konnte erst beginnen, nachdem sich der letzte Reporter abgemeldet hatte, normalerweise zwischen Mitternacht und ein Uhr morgens. In Berlin mussten die Systeme spätestens um sechs Uhr zum Redaktionsbeginn, allerspätestens jedoch um acht Uhr zum Hauptredaktionsbeginn, wieder vollständig einsatzbereit sein.

Mit einer Strecke von etwa 580 Kilometern zwischen Unterföhring und Berlin, überwiegend auf der Autobahn, würde eine normale Fahrt fünf bis sechs Stunden dauern. Das hätte das Zeitfenster gesprengt. Die Lösung war einfach und effektiv: Mit dem Audi RS6 Avant des Chefs ließ sich die Fahrzeit auf vier bis viereinhalb Stunden reduzieren, wodurch die kritischen Zeitvorgaben eingehalten werden konnten.

Das Projekt gliederte sich in zwei Phasen. In der ersten Phase wurde die komplette Infrastruktur im Berliner Level-3-Rechenzentrum vorbereitet. Netzwerkkomponenten und Verkabelung wurden so eingerichtet, dass die Systemadministratoren von ProSieben während der Transportzeit ihre Netzwerkkonfigurationen anpassen konnten. Die zweite Phase umfasste die Anfahrt nach Unterföhring, den Ausbau der drei MeCom-Server, die Fahrt nach Berlin und den dortigen Einbau.

In der Umsetzung meldete sich der letzte Reporter gegen 0:30 Uhr ab. Nach dem zügigen Ausbau der Server startete die „Fahrt“ um ein Uhr nachts. Nach der Ankunft in Berlin wurden die Server im Rack montiert, in Betrieb genommen und zwei defekte Festplatten ausgetauscht. Punkt sechs Uhr morgens konnte die Redaktion planmäßig ihre Arbeit aufnehmen.

Nachdem Support-Tickets in Papierform häufig verloren gingen oder in Vergessenheit gerieten und der Bearbeitungsstatus nur schwer nachvollziehbar war, fiel im Team die Entscheidung zur Entwicklung eines eigenen digitalen Ticketsystems.

In der Planungsphase wurde ein einfaches Lastenheft erstellt, wobei alle Mitarbeiter ihre Anforderungen und Ideen einbringen konnten. Die technische Umsetzung erfolgte mit PHP, XHTML und CSS, während im Backend eine MySQL-Datenbank für die Datenhaltung sorgte. Als Grundlage diente ein Debian-System mit Apache HTTP Server auf eigener Hardware. Gemeinsam mit einem Kollegen übernahm ich die Einrichtung und Programmierung des Systems. Nach der Fertigstellung wurden die anderen Kollegen in das neue System eingeführt.

Im Laufe der Zeit wurde die Lösung kontinuierlich um zusätzliche Funktionen erweitert. Ein wichtiges Modul war das integrierte Inventarisierungssystem. Dieses verwaltete die von Kunden zugewiesenen Nummernkreise zentral und stellte sicher, dass keine Mehrfachvergaben auftreten konnten. Zuvor gab es immer wieder Dopplungen von Inventarnummern oder Auslassungen ganzer Bereiche.

Was als Lösung für ein Problem begann, entwickelte sich zu einem umfassenden Werkzeug, das weit über die ursprüngliche Ticketverwaltung hinausging. Die Supportabteilung konnte ihre Effizienz deutlich steigern, da Tickets transparent und zentral nachvollziehbar wurden. Das System lief stabil bis zur Liquidierung des Unternehmens, wobei mein Kollege und ich die kontinuierliche Wartung und Pflege übernahmen.