seit August 2007: Freiberufler

Projekte (Auszug)

Nachfolgend eine kleine Auswahl der durchgeführten Projekte in chronologisch absteigender Reihenfolge:

Incapsula Webapplication Firewall

Kunde: Merck KGaA (Darmstadt)
Projektlaufzeit: 12 Monate
Referenzen auf Anfrage

Situation

Die kommerzielle Imperva/Incapsula Webapplication Firewall (WAF) soll für alle Merck Webserver weltweit verpflichtend eingesetzt werden.

Lösungen

Aus der Vielzahl der Funktionen, welche die cloud-basierte Incapsula WAF bietet, wurden die relevanten ermittelt und gruppiert (z.B. Geo-Blocking).

Incapsula WAF kann neben dem Zugriff über eine Weboberfläche auch per REST-API gesteuert werden. Leider bietet die Weboberfläche der Incapsula WAF keine fein granulierte Zugriffsrechte an.

Für das Merck WAF Support Team wurde eine interne WebApp erstellt, die dem Team Zugriff auf die wichtigsten Funktionen bietet.

Die WebApp interagiert per REST mit der Incapsula WAF.

Dies ermöglicht z.B. automatische, konsistente und nachvollziehbare Deployments der WAF-Regeln.

Aus dieser WebApp können auch automatische Deployments der erforderlichen Änderungen dee DNS-Einträge getriggert werden.

Spezielle Lösungen für einzelne Websites werden manuell über die Weboberfläche der Incapsula WAF konfiguriert.

Zusätzlich laufen im Hintergrund Monitoringprogramme, die regelmäßig prüfen, ob die WAF Regeln den Vorgaben entsprechen und entsprechende Compliance Reports erstellen.

Logdateien der WAF werden zentral ausgewertet. Die Ergebnisse der Logauswertung werden auf einen internen Webserver für die Websitebetreiber dargestellt.

Weiterhin werden Securityreports aus den Logdateien erstellt und den Merck internen Security-Teams zur Verfügung gestellt.

Das komplette System wurde an ein internes Team übergeben.


Eingesetzte Technologie

• Linux (SLES 12)
• Perl 5
• Python 3
• Incapsula Webapplication Firewall
• DNS
• TLS/SSL
• Apache/Nginx
• HTML/CSS (barrierefrei und reponsive) - Zurb Foundation for Sites
• Webservices (REST)
• JSON
• Logging (Log::Log4perl)
• Subversion (SVN)

Ergebnisse

Gut dokumentiertes und funktionierendes System, das von internen, fest angestellten Mitarbeitern weiter verwendet werden kann.

Das interne Merck WAF Support Team kann Standard Aufgaben (ohne großen Schulungsaufwand) über die interne WebApp einfach starten.
Die Betreiber der Webserver benötigen keinen Zugriff auf die WAF.
Spezielle Lösungen für einzelne Websites können individuell von geschulten internen Mitarbeitern des Merck WAF Teams konfiguriert werden.

99% Prozent der Webserver im Scope konnten erfolgreich und nahezu reibungslos auf Incapsula WAF umgstellt werden.

Hochverfügbare Linux LDAP Server und Perl-Programme im IAM-Bereich

Kunde: Merck KGaA (Darmstadt)
Projektlaufzeit: 60 Monate
Referenzen auf Anfrage

Situation

Komplexes System hochverfügbarer LDAP Server und zahlreiche Perl-Skripten von unterschiedlichen Entwicklern.

Probleme/Ziele

Änderungen an bestehenden Programmen, Datenexporten, Zugriffsberechtigungen, Synchronisationen usw. waren nur umständlich und oft mit hohem Zeitaufwand möglich.
Die Kundenzufriedenheit und -akzeptanz war eher gering.


Lösungen/Tasks (Auszug)


A) Server- und Servicesmigrationen

Umstellung von Windows LDAP Server auf OpenLDAP Server unter SLES inklusive Tests.


B) Datenexporte

Anpassung und Weiterentwicklung bestehender Datenexporte im CSV, JSON, XML oder XLS-Format
Transport und Bereitstellung der exportierten Daten per sFTP (Server und Client)

C) Datenimporte

Anpassung und Weiterentwicklung bestehender Datenimporte aus internen Systemen (SAP, Oracle)

D) Datensynchronisation

Anpassung, Weiter- und Neuentwicklung von Datensynchronisationen zu internen Lotus Notes-, Active Directory- und Oracle LDAP-Servern.
Anpassung, Weiter- und Neuentwicklung von Datensynchronisationen zu externen Dienstleistern (Amadeus- und Concure Travel Management, SAP und viele weitere)


E) Generalisierung und Vereinfachung aller Dienste

Vereinheitlichung der zahllosen Skripte durch modulare, wiederverwendbare und einfach zu nutzende Komponenten. Nahezu alle alten Skripte konnten durch die Module abgelöst werden. Die Entwicklungszeit für neue Exports konnte dramatisch verkürzt werden (Stunden statt Wochen).

Dank Generalisierung konnte der komplette Service- und Supportbereich erheblich schneller, einfacher, kostengünstiger und dazu kundenorientierter aufgestellt werden.

F) Logging und Monitoring

Entwicklung und Aufbau eines Logging- und Monitoring-Frameworks, das für alle Exporte, Importe und Webservices verwendet wird.
Das verbesserte Logging vereinfacht die Fehlersuche und -behebung in Perlprogrammen erheblich.
Weiterhin wurde ein Icinga-Monitoring-System für Linux-Server aufgesetzt. Die Fehlerausgaben der o.g. Perlprogramme können im Monitoring angezeigt werden.

G) Moderne Protokolle/Webservices

Neuentwicklung von REST und SOAP Webservices zwecks Zugriff auf die LDAP-Daten für verschiedene Anwendungen.
Mit Hilfe der Webservices werden externe Mitarbeiter, Special User, Mailverteiler, Räume, Equipment und Mailboxen verwaltet.


Eingesetzte Technologie (Auszug)

• Linux (SLES11/12)
• Perl 5
• CPAN
• Logging (Log::Log4perl)
• OpenLDAP
• Apache
• TLS/SSL
• CSV
• JSON
• XML
• Webservices (REST)
  Webservices/SOAP
• Subversion (SVN)

Ergebnisse

Gut dokumentiertes, stabiles und funktionierendes System, das von internen, fest angestellten Mitarbeitern weiter verwendet werden kann.


Erhebliche Kosteneinsparungen bei gleichzeitig höherer Kundenzufriedenheit.

De-Mail - Linux-Administration

Kunde: 1und1 AG, Karlsruhe
Projektlaufzeit: 7 Monate
Referenzen auf Anfrage

Situation

1und1 will als De-Mail Anbieter bis Anfang 2013 akkreditiert werden. Hierzu muss eine komplett neue hochverfügbare und sichere Infrastruktur (ca. 600 Server) gemäß den Anforderungen BSI-Grundschutz und De-Mail Gesetz in zwei räumlich getrennten Rechenzentren geplant, dokumentiert und implementiert werden.

Probleme/Ziele

Aufbau einer hochverfügbaren Infra-Struktur mit verschieden Umgebungen (Dev, QA, Pre-Live, Live).
Die Vorbereitung zur Akkreditierung als De-Mail-Anbieter erfordert umfassende Dokumentation der Architektur, der Abläufe und Rollen, der Software und der Hardware.

Für die Durchführung des Projekts werden Freiberufler mit umfassenden Linux-HA-Kenntnissen benötigt, die in der Lage sind, in Zusammenarbeit mit internen Fachabteilungen und Architekten und externen Auditoren selbständig zu planen, Ergebnisse zu kommunizieren und zertifizierungssicher zu dokumentieren und zu implementieren.

Lösungen

Ein Auswahl der von mir bearbeiteten Teilbereiche.

A) Konzeption und Implementierung IT-Basisinfrastruktur - Zeitdienst (NTP)
Eine grundlegende Anforderung im De-Mail Umfeld ist die Nutzung von authentischen Zeitquellen.
Hier wurden pro Rechenzentrum jeweils eine Meinberg Lantime DCF-77 und eine Meinberg Lantime GPS Appliance eingesetzt. Zusätzlich dienen die bereits vorhanden 1und1 NTP-Server als Rettungsanker.

Alle Server im De-Mail Umfeld verwenden diese Appliances und die 1und1 NTP Server als Zeitquellen. Diese Konfiguration wird sowohl durch den Betriebssysteminstaller (Kickstart, Preseed) als auch durch Puppet-Code sichergestellt.

Sowohl Appliances als auch NTP-Clients auf den De-Mail Servern werden mit Standard-Nagios Plugins überwacht (Monitoring).

Für den Zeitdienst wurde ein Betriebs- und Notfallhandbuch von mir erstellt.

B) Konzeption und Implementierung IT-Basisinfrastruktur - Sichere Namensauflösung (DNS)

Eine grundlegende Anforderung im De-Mail Umfeld ist die Nutzung sicherer Namensauflösung.

Hier müssen vier Szenarien unterschieden werden:

1. DNS-Primary und Secondaries als Authorative Nameservers für De-Mail
2. DNS-Primary und Secondaries für die Namen und IP-Adressen der internen Server
3. DNS-Primary und Secondaries für die Namen und IP-Adressen der Managementinterfaces
4. DNS-Recursor für Zugriffe auf externe Seiten, z.B. Paymentsysteme

In allen vier Fällen wurde BIND9 als DNS-Server eingesetzt.

Alle DNS-Informationen für die Primaries befinden sich bereits in einer zentralen Inventarisierungsdatenbank und werden auch in dieser gepflegt. Aktualisierungen der DNS-Primaries erfolgen durch ein von mir erstelltes Perl Programm, welches die Datenbank regelmäßig abfragt, BIND9 Konfigurationsdateien erstellt und diese in einem Subversion-Repository ablegt. Secondaries werden über DNS-Notifies aktualisiert.

Die DNS Primaries wurden als hochverfügbare hidden primaries auf Servern mit DRBD und Heartbeat konzipiert und implementiert.

Die Konfigurationsdateien für Primaries und Secondaries werden mit Puppet verteilt.
Alle Server im De-Mail Umfeld verwenden die aufgeführten Namensdienste. Die Konfiguration wird sowohl durch die automatische Betriebssysteminstallation (Kickstart, Preseed) als auch durch Puppet-Code sichergestellt.

Alle DNS-Server werden mit Standard Nagios-Plugins überwacht. Zusätzlich kann die Performance mittels DSC (A DNS Statistics Collector) gemessen werden.

Für die Namensdienste wurden die Betriebs- und Notfallhandbücher von mir erstellt.

C) Konzeption der Betriebs- und Notfallhandbücher De-Mail

Betriebs- und Notfallhandbücher und die darin enthaltenen Anleitungen zum Debuggen bzw. Troubleshooting sind eine wesentliche Anforderung für eine erfolgreiche Akkreditierung.
Ausgehend von den bereits vorhandenen 1und1 Notfallhandbüchern habe ich in Absprache mit den internen Sicherheitsverantwortlichen und externen Auditoren Notfallhandbücher für die o.g. NTP und DNS Dienste erstellt.

Die Struktur der beiden Betriebs- und Notfallhandbücher dient als Grundlage für die weiteren Notfall- und Betriebshandbücher für das gesamte Projekt.

D) Konzeption und Implementierung IT-Basisinfrastruktur - Minimales Betriebssystem

Eine grundlegende Anforderung im De-Mail Umfeld ist die Installation eines minimalen Betriebssystems und die Kontrolle des Zugriffs auf die Server.

Informationen über alle Server im De-Mail Umfeld werden in einer einer zentralen Inventarisierungsdatenbank gepflegt.

Zugriffsberechtigungen (Rollen) werden in einem zentralen Verzeichnisdienst (LDAP) verwaltet. Der Verzeichnisdienst enthält auch Informationen, welche Rolle auf welchen Server zugreifen darf. Die SSH-Keys der Mitglieder einer Gruppe sind ebenfalls im LDAP hinterlegt.

Alle Server im De-Mail Umfeld werden automatisch und unbeaufsichtigt installiert und provisioniert.

Die automatische Installation wird durch Kickstart bzw. Preseed Dateien gesteuert.

Diese Kickstart bzw. Preseed Dateien installieren ein minimales Debian bzw. RedHat5 Betriebssystem, partitionieren die Festplatten (LVM, DRBD), konfigurieren u.a. Netzwerkeinstellungen (Bonding, Managementinterfaces), SSHD, Softwarerepositories, DNS, NTP, Puppetclient und die LDAP-Clients des User- und Rollenmanagements.

Die Kickstart bzw. Preseed Dateien werden mit von mir erstellten Programmen (Perl und Ruby) erzeugt, welche Informationen aus der Inventarisierungsdatenbank und LDAP nutzen.
Nach der grundlegenden Installation und sicheren Konfiguration der Server erfolgt die weitere Konfiguration per Puppet.

In diesem Zusammenhang habe ich auch die hochverfügbaren Bootserver (DHCP,TFTP) mit DRBD und Heartbeat konzeptioniert und implementiert und die Notfall- und Betriebshandbücher erstellt.

E) Konzeption und Implementierung IT-Basisinfrastruktur - Sicherstellung der Integrität und Authentizität von Softwarepaketen

Eine grundlegende Anforderung im De-Mail Umfeld ist Sicherstellung der Integrität und Authentizität von Softwarepaketen. Jegliche Software im De-Mail Umfeld wird daher paketiert (RPM, deb), mit Prüfsummen versehen, signiert und in rollen- und umgebungsspezifischen Repositories zur Verteilung bereitgestellt.

Die Software für die Verwaltung der rollen ? und umgebungsspezifischen Repositories, den Upload/Import der Softwarepakete, wurde von mir in Perl erstellt. Diese Software kann auch mit unpaketierten Dateien, wie Firmwareimages, Java WAR files usw. umgehen.

In diesem Zusammenhang habe ich auch die hochverfügbaren Reposerver mit Apache, DRBD und
Heartbeat konzeptioniert und implementiert und die Notfall- und Betriebshandbücher erstellt.

F) Implementierung MySQL Server Primary-Primary Replikation

Innerhalb des De-Mail Projekts werden hochverfügbare MySQL-Cluster mit Primary-Primary Replikation eingesetzt. Da für einige Teams des Projekts nicht genügend Personalkapazitäten vorhanden war, wurde mir die Implementierung der MySQL-Server nach Vorgabe übertragen. Diese MySQL Server werden mit Standard-Nagios Plugins überwacht.

Eingesetzte Technologie

• Linux (Debian, RedHat5)
• ISC-DHCP
• ISC-Bind
• DRBD
• Heartbeat
• Apache
• Perl, CPAN (DBI, Net::DNS)
• Ruby 1.8
• Bash
• Puppet 2.7
• Nagios
• Subversion
• MySQL
• PAM
• reprepro, createrepro
• Twiki

Ergebnisse

Gut dokumentiertes und funktionierendes System, das von internen, fest angestellten Mitarbeitern weiterentwickelt und betreut werden kann.

Die Reposerver-Software wird auch für andere 1und1 Projekte verwendet.

Die De-Mail-Zertifizierungsurkunde des Bundesamtes für Sicherheit in der Informationstechnik wurde im März 2013 übergeben. Das Projekt wurde also erfolgreich durchgeführt.

Betreuung und Weiterentwicklung T-NetLife - Web-basiertes Netzwerk­management

Kunde: T-Systems, Darmstadt

Projektlaufzeit: 12 Monate

Referenzen auf Anfrage

Situation

T-NetLife, ein ITIL konformes, Web-basiertes Netzwerkmanagementsystem stellt Überwachung und Steuerungsfunktionen (OAM-Funktionen - Operation, Administration, Maintenance) für ein MPLS basiertes Netzwerk, das als Outsourcing Projekt im Auftrag einer bundesdeutschen Bank be­trieben wird, zur Verfü­gung.

Aktuell werden von T-NetLife ca. 18.000 Netzwerkkomponenten (Router und Switche) an rund 9.000 Stand­orten ge­managed.

T-NetLife sammelt und speichert umfangreiche Informationen über die Netznutzung, -auslastung, -fehler und -ereignisse per SNMP und Telnet in mehreren MySQL Datenbanken und erstellt aus den gewonnenen Daten ansprechende graphische allgemeine und benutzerspezifische Statistiken und Reporte.

Alle Netzwerkkomponenten werden automatisch dokumentiert und in einer Netzwerktopologie, die auch die Standorte berücksichtigt, graphisch dargestellt.

Zusätzlich bietet T-NetLife umfassende Möglichkeiten Konfigurationsänderungen an den aktiven Netzwerk­komponenten durchzuführen.

Alle Funktionen von T-NetLife können von den Benutzern über ein modernes AJAX-Webinterface komforta­bel genutzt werden.

T-NetLife, eine Eigenentwicklung von T-Systems, ist in der dynamischen Programmiersprache Perl geschrie­ben und verwendet in hohem Umfang Open Source Software, insbesondere LAMP-Stack (Linux, Apache, MySQL, Perl), zahlreiche CPAN-Module, Javascript-Bibliotheken wie jQuery und overLIB und Hochverfüg­barkeitslösungen wie Heartbeat und DRBD.

Problem

Praktisch alle wichtigen Entwickler und Administratoren und damit auch deren Know-How haben das Unter­nehmen verlassen.

Lösungen

A) Bestandsaufnahme und Dokumentation

Als erster Schritt wurden die Anzahl und Funktionalität der von T-NetLife genutzten Server und der auf die­sen auf diesen Servern verteilten T-NetLife Software ermittelt und in einem Trac Wiki in englischer Sprache dokumentiert.

In einem weiteren Schritt wurden die Serverkonfigurationen und T-NetLife Software in ein Source Code Ma­nagement (Subversion) überführt.

Hierfür wurden von mir entwickelte Linux-Shell- und Perl-Programme eingesetzt, die diese Projekt­phase deutlich verkürzt haben.

B) Aufbau einer Entwicklungs- und Testumgebung

Die Ergebnisse der Bestandsaufnahme und Dokumentation konnten zum Aufbau einer Entwick­lungs- und Test­umgebung, einem Nachbau der Wirkumgebung, genutzt werden.

Besondere Herausforderungen waren die Abbildung einer großen Produktivumgebung auf eine klei­ne Test­umgebung, z.B.. sehr heterogene Apache oder MySQL Konfigurationen, die exakte Nachbil­dung der Software­ausstattung (RPM) und die Einbindung unterschiedlicher Netzwerk­komponenten.

Alle Service­konfigurationen und Software der Test- und Entwicklungsumgebung werden in einem eigenem Source Code Management-System (Subversion) verwaltet.

C) Konfigurationsmanagement - Software Roll-Out - Deployment

Die bestehende Software Roll-Out-Lösung Lösung der T-NetLife Software wurde von mir an den Workflow der Test- und Entwicklungsumgebung angepasst, so das getestete Software automatisch auf alle T-NetLife Server ausgerollt werden kann.

In diesem Projektabschnitt, habe ich auch Perl-Programme entwickelt, die testen, ob der Roll-Out erfolgreich und vollständig ausgeführt wurde.

Dank des Einsatzes oben genannten Source Code Management Systems können auch Roll-Backs einfach und erfolgreich durchgeführt werden.

D) Wartung, Optimierung und Trouble-Shooting Linux Server und Datenbanken

T-NetLife Software arbeitet sehr eng mit dem Betriebssystem CentOS zusammen, nutzt MySQL-Datenbanken und Apache (mod_perl) intensiv und benötigt eine hochverfügbare Umgebung.

Während der gesamten Projektlaufzeit habe ich Third Level Support für die Open-Source-Hoch­ver­füg­barkeits­technologien DRBD + MySQL + Heartbeat und DRBD +Apache + Heartbeat auf CentOS 5 Servern geleistet.

E) Monitoring der T-NetLife Server und Dienste

Eine Lösung zur Überwachung und Dokumentation der Verfügbarkeit der T-NetLife Server und Dienste stand nicht zur Verfügung.

In einem zweistufigen Verfahren zur Ermittlung von Engpässen wurde zunächst Munin als kleine Lösung für einige besonders kritische Server und Dienste eingesetzt.

In einer zweiten Stufe wurde das Monitoring auf alle T-NetLife Server und Dienste ausgeweitet und mit Nagios realisiert. Zur Überwachung der T-NetLife Software habe ich Nagios Plugins in Perl entwickelt und ge­testet. Insgesamt wurden knapp 1.000 Checks von verfügbarer Fest­platten­kapazität über DRBD- und Heartbeat-Status bis zu MySQL Performance Daten installiert.

F) Weiterentwicklung und Verbesserung bestehender Perl Software

Die Einführung neuer Netzwerkkomponenten und Kundenanforderungen und -beschwerden führte zu um­fangreichen Änderungen und Erweiterungen der T-NetLife Software.

In Zusammenarbeit mit weiteren Software-Entwicklern des Teams habe ich Perl-Programme und Bibliothe­ken, die SQL- oder SNMP Queries ausführen, überarbeitet, erweitert und neu erstellt.

Durch den Einsatz eines Profilers (Devel::NYTProf) konnte ich Laufzeit und Ressourcen­verbrauch der Perl Programme deutlich senken.

Die Einführung des Perl Loging Frameworks Log::Log4perl für die gesamte T-NetLife Software half Fehler im laufenden Betrieb auf zu spüren und zu beseitigen.

Durch Einführung von Software-Tests (Test::More) und Überprüfung der Testabdeckung in Zusammenarbeit mit dem Entwicklerteam konnte die Fehlerquote bereits im Vorfeld deutlich gesenkt werden.

Eingesetzte Technologie

• Linux (CentOS 5)

• Perl

• CPAN

• Bash

• Nagios/Munin

• Apache (mod_perl)

• Javascript (jQuery, overLIB)

• MySQL

• SQL

• DRBD

• Heartbeat

• Cisco, HP, Nortel Netzwerkkomponenten

• TFTP

Ergebnis

Gut dokumentiertes und verbessertes System, das von internen, fest angestellten Mitarbeiter weiterentwi­ckelt und be­treut werden kann. Endkunde (Bank) sehr zufrieden mit der Arbeit des neuen Teams.

Perl-Code-Review und Training Financial Reporting

Kunde: ICF-Systems AG, Frankfurt

Situation

Im Bereich Financial Reporting für bankoperative Prozesse werden viele Perl-Programme zwecks Extraktion und Reporting eingesetzt.

Problem

Geänderte Anforderungen bestehender Bankkunden erfordern umfangreiche Erweiterungen der bestehen­den Programme. Neue Mitarbeiter verfügen noch nicht über die erforderlichen Perl-Kenntnisse.

Lösung

In praxis-orientierten In-House Schulungen wurde den neuen Mitarbeitern das notwendige Perl-Know-How vermittelt.

Im einem weiteren Schritt wurden bestehende Programme gemeinsam erweitert, um den neuen Kundenan­forderungen gerecht zur werden.

Eingesetzte Technologie

• Perl

• Windows 2003 Server

• UNIX

• Oracle-Datenbank

Ergebnis

Wartbarer, dokumentierter und getesteter Perl-Code, der die Kundenanforderungen termingerecht erfüllt.

Netzwerk-Migration

Kunde: HP Enterprise Services, Geschäftsstelle Bad Homburg.

Situation

Durch die Übernahme von Arcor durch Vodafone sollen ca. 20 IP-Netze mit mehr als 400 Hosts auf neue Netzwerke migriert werden.

Problem

Neben der großen Anzahl der Netze und Hosts mit unterschiedlichen Betriebssystemen (Solaris, RedHat, HP-UX, AIX) und unterschiedlichen Virtualisierungstechniken (Xen, Zones) sind zahlreiche Netzwerkdienste termingerecht im Produktionsbetrieb umzustellen.

Lösung

Sämtliche Informationen über alte und neue Netze und die dazugehörigen Hosts werden in einer Datenbank gespeichert. Die mit der Durchführung der Migration beauftragten Administratoren können auf die Datenbank über ein graphisches Frontend, das von mir erweitert wurde, zugreifen, benötigte Informationen ermitteln und den Fortschritt der Migration dokumentieren.

Die Umstellung der Netzwerkeinstellungen erfolgte über ein von mir entwickeltes Programm, welches die be­nötigten Netzwerkinformationen aus der Datenbank ermittelt und daraus die neuen Netzwerkkonfigurations­dateien erstellt und verteilt. Ein weiteres von mir erstelltes Programm erzeugt Testprogramme zwecks auto­matischer Prüfung der korrekten Funktion der neuen Netzwerkkonfiguration.

Aus den Informationen der Datenbank werden mit dem Fortschritt der Migration durch ein von mir entwickel­tes Programm automatisch passende neue Zone-Files für den DNS-Server erstellt und verteilt. Ein weiteres von mir erstelltes Programm erzeugt automatische Tests der DNS-Server-Funktionalität vor und nach der Umstellung.

Informationen über verwendete IP-Adressen in Konfigurationsdateien werden mittels eines von mir speziell entwickelten Scanners, der auf allen Hosts nach IP-Adressen in Konfigurationsdateien sucht, ermittelt. Aus den gewonnenen Informationen werden automatisch neue Konfigurationsdateien erstellt und verteilt. Auch hier wird die korrekte Funktion der neuen Konfiguration durch automatisch erstellte Testpro­gramme geprüft.

Eingesetzte Technologie

• Perl, DBI, Perl Tk, Net::SSH, Net::DNS

• Bash

• PostgreSQL

• Bind 9

• Linux (RedHat EL5), Solaris 10, HP-UX, AIX, Windows

Ergebnis

Das Projekt konnte mit nur geringer zeitlicher Verzögerung erfolgreich durchgeführt werden.