Wohnort 82xxx, Deutschland EDV-Erfahrung seit 1984 Verfügbar ab 23.04.12 zu 100%, Vor-Ort-Einsatz 100% möglich
| Deutsch | |
| Englisch | |
| Französisch | Grundkenntnisse (Schule) |
| Alpha | |
| Digital | |
| HP | |
| PC | |
| PDP | |
| SUN | |
| VAX |
| Echtzeitbetriebssysteme | RTE-3, RTE-4/B, RTE-6/VM |
| HPUX | |
| MS-DOS | |
| SUN OS, Solaris | |
| Unix | |
| VMS | |
| Windows |
| Assembler | Intel, Alpha |
| C | 19 Jahre, sehr solide Kenntnisse |
| C++ | |
| Emacs | |
| Fortran | insbesondere Koppelung FORTRAN/C/Assembler |
| Imake, GNU-Make, Make-Maker etc... | |
| Maschinensprachen | x86 und Alpha |
| Perl | |
| PL/SQL | |
| Qt | |
| Scriptsprachen | |
| Shell | |
| TeX, LaTeX |
| B-Tree | |
| IMAGE/1000 | Entwicklung sekundärer Zugriff über B-Bäume |
| MySQL | |
| Oracle | 7.x, 8.x, 9.x, ProC, OCI, BLOBs |
| SQL |
| CICS | |
| Ethernet | |
| Internet, Intranet | |
| LAN, LAN Manager | |
| LU6.2 | |
| Message Queuing | |
| RPC | |
| SNA | |
| TCP/IP | |
| Token Ring | |
| Windows Netzwerk | |
| Winsock |
Zugangskennungen für Datenbank-Accounts und Netzwerkressourcen sollen ersetzt werden durch im laufenden Betrieb zu ändernde Zugangskennungen. Berechtigte Anwendungen sollen diese veränderten Zugangskennungen automatisch erhalten, manipulierte Anwendungen sollen erkannt und abgewiesen werden. Ebenso sollen sicherheitskritische DLLs der Anwendungen gegen Manipulation geschützt werden können.
Der Verteildienst liest nun die für ihn verschlüsselte Liste der Zugangskennungen und entschlüsselt sie mit seinem privaten Schlüssels. Ebenso liest er aus der Datenbank die Liste der frei geschalteten Anwendungen. Er wartet dann auf Anfragen der Anwendungen.
Die Anwendungen ihrerseits erfragen ihre Zugangskennungen durch den Aufruf einer ebenfalls neu entwickelten DLL. Die DLL stellt nun fest, welches Programm den laufenden Prozess erzeugt hat und ermittelt seinen Namen und seine Signatur (MD5-Hash). Mit diesen Informationen wendet sich die DLL an den Passwort-Verteildienst, der in der Liste der frei geschalteten Anwendungen nachsieht, ob diese Anwendung überhaupt frei geschaltet ist und ob für diese Anwendung sicherheitskritische DLLs vorgeschrieben sind. Der
Dienst liefert dann entweder direkt die für das anfragende Programm hinterlegte Zugangskennung, lehnt die Anfrage ab oder er erfragt die Signaturen (MD5-Hashes) der sicherheitskritischen Anwendungs-DLLs und überprüft, ob diese frei geschaltet sind, bevor er sich für Beantworten oder Ablehnen entscheidet.
Die gewählte Lösung hat den Vorteil, dass sie sehr schnell ist, weil der Passwort-Verteildienst alle benötigten Informationen in seinem Adressraum hält und so im laufenden Betrieb kein Datenbank-Zugriff nötig ist.
Nun kann es natürlich passieren, dass die Zugangskennungen verändert worden sind, entweder durch einen Menschen oder durch einen automatisierten Vorgang. Das dazu benutzte Administrationswerkzeug ändert aber nicht nur die Zugangskennungen, sondern es erstellt auch die neue Liste der Zugangskennungen und legt sie, für die frei geschalteten Verteildienste verschlüsselt, in der Datenbank ab.
Da der einzelne Verteildienst davon nichts mitbekommen hat liefert er nun im guten Glauben eine falsche Antwort an die nächste anfragende Anwendung. Alles, was die Anwendung dann tun muss ist einfach noch mal zu fragen. Der Verteildienst führt Buch über die an ihn gestellten Anfragen und betrachtet eine in einem kurzen Zeitfenster wiederholt gestellte Anfrage einer Anwendung als "Misstrauensvotum" und liest die für ihn verschlüsselte Liste der Zugangskennungen erneut aus der Datenbank. Diese zweite Anfrage beantwortet er dann richtig, mit der inzwischen neu festgelegten Zugangskennung. In der gleichen Weise erfährt der einzelne Verteildienst auch, wenn neue Anwendungen oder DLLs frei geschaltet wurden. Der Administrator muss sich nicht darum kümmern, dass die einzelnen Verteildienste die Freischaltlisten oder Listen der Zugangskennungen neu lesen, die verteilen sich automatisch.
Zur Speicherung der verschlüsselten Zugangslisten in der Datenbank wurden BLOBs gewählt, weil es dann keine Größenbeschränkungen gibt und die Listen mit einem einzigen Datenbankzugriff gelesen werden können.
Bei manchen dieser Daten ist schon aus dem Dateinamen der Mandant zu erkennen, bei anderen ist dieses Wissen aus der Datenbank zu extrahieren. Aus Protokollen werden mandantenspezifische Auszüge erstellt. So entsteht für jeden Tag und für jeden Mandanten ein komprimiertes Archiv. Die nicht angetasteten Originalversionen der Protokolle landen ebenso wie Protokolle, die keinem Mandanten zugeordnet werden können, in einem "Lumpensammler"-Archiv.
Diese Tagesarchive werden dann je nach der Archivierungsstrategie des einzelnen Mandanten über TSM archiviert. So können die unterschiedlichen Aufbewahrungsfristen eingehalten werden, ohne unnötige Kosten zu verursachen.
und unerwünschte Gefährdungspotentiale zur Folge hatten, z.B.:
Das ORACLE-Online-Backup wurde erst nach dem file system backup durchgeführt, so dass jeweils die am Vortag erzeugten Datenbank-Dateien gesichert wurden mit der Folge, dass bei einem Wiederaufsetzen nach einem crash unnötigerweise die redo logs des gesamten Vortages eingespielt werden mußten, um die Datenbank auf den Zeitpunkt des nächtlichen Backups zu bringen.
Dazu kommen dann noch die redo logs bis zum Zeitpunkt des Crashs. Die für eine disaster recovery benötigte Zeit wird so unnötig lang.
Die via management class im TSM festgelegten Aufbewahrungsstrategien der Online-Backups und des Datenpools waren nicht aufeinander abgestimmt. So entstehen unnötige Kosten, denen kein Nutzen gegenüber steht.
Zusätzlich zu den Online-Backup-Dateien und den redo logs der ORACLE-Datenbank wurden auch noch die "lebendigen" ORACLE-Datenbankdateien (die tablespaces, *.dbf) über das reguläre file system backup mit gesichert. Das bringt nur Kosten, keinen Nutzen, denn aus den tablespace-Dateien einer laufenden Datenbank kann man die Datenbank nicht rekonstruieren.
Die Kosten sind erheblich, weil die tablespace-Dateien eine beträchtliche Größe erreichen und sich laufend ändern, also jede Nacht erneut gesichert werden.
Obendrein ist dieses Vorgehen noch massiv gefährlich: Um das System nach einem etwaigen Crash wieder aufzusetzen wird man aus Zeitgründen mit der Datenbank beginnen: Erst das Zurücksichern des Online-Backups der Datenbank und der redo logs. Während die Datenbank dann durch Einspielen der redo logs nach vorne gerollt wird, um auf den aktuellen Stand zu kommen wird parallel dazu durch Rücksicherung des Backups das file system wieder hergestellt. Sind nun in in dem file system backup auch noch die "lebendigen" Datenbank-Dateien, die tablespace files, mit gesichert worden, so überschreiben diese nun die gerade eben mühsam wieder hergestellte Datenbank. Die Datenbank ist dann korrupt und das nächste disaster nimmt seinen Lauf.
Um einen möglichst schnellen Wiederanlauf nach einer Störung sicherstellen zu können wurden mehrere (tägliche) Generationen der durch das Online-Backup der Datenbank erzeugten Tablespace-Dateien neben der TSM-Sicherung auch noch direkt auf dem Plattenspeicher vorgehalten. Wegen der rasch ansteigenden Datenvolumina war die Notwendigkeit neue Platten anzuschaffen absehbar.
Durch Kompression der Online-Backups nach der TSM-Sicherung konnte diese Neuanschaffung von Platten vermieden werden. Der bei Tablespace-Dateien erreichbare Kompressionsfaktor ist sehr hoch. Zwar muss immer noch genügend Plattenplatz für eine unkomprimierte Sicherungsversion vorgehalten werden, aber halt eben nur für eine Version, nicht für mehrere.
Software: perl, shell, TSMAufbau und Betrieb einer Integrationstestumgebung, um die beim Kunden entwickelten Softwarepakete auf ihre Verträglichkeit in Bezug auf Installation und Betrieb zu testen. Entwicklung einer Installationsoberfläche, die die für die Installation benötigten Daten (z.B. Art der Hostanbindung, Vernetzung der Server untereinander etc.) nach Möglichkeit selbst herausfindet und sonst erfragt. Diese Angaben werden einer rigorosen Verifikation unterzogen (z.B. Prüfung der Kommunikation der ORACLE-Datenbanken untereinander für die Replikation) bevor die eigentliche Installation erfolgt. Besonderer Wert wurde dabei gelegt auf die Reduzierung der down time und die Nachvollziehbarkeit.
Software: Unix, SINIX-Z, NT4.0, W2K, shell, perl, C, pkgaddDesign, Entwicklung und Betrieb eines Überwachungssystems, welches die
auf einem Server installierten Softwarekomponenten (Datenbank,
elektronisches Journal, file transfer, Host-Datenbankanbindung etc.)
im laufenden Betrieb überwacht und bei Abweichungen vom Sollzustand
nach Möglichkeit selbständig geeignete Maßnahmen ergreift (z.B.
Restart eines gecrashten daemons), zumindest aber Alarm schlägt. Der
Service Control Monitor konfiguriert sich selbst beim Booten des
Servers, er schaut nach, welche Komponenten installiert und deswegen
zu überwachen sind. Dabei ist eine differenzierte zeitliche Steuerung
implementiert, so müssen manche Komponenten nur tagsüber laufen, und
manche Fehlerzustände werden erst dann kritisch, wenn sie über einen
längeren Zeitraum anhalten (z.B. Übertragung aufgelaufener
Offline-Umsätze in die Host-Datenbank).
Software: Unix, SINIX-Z, NT4.0, W2K, C, perl, shellDer Kunde betreibt ein komplexes Netz, bestehend aus mehreren Hosts,
ca. 650 Servern und 8.500 SB-Geräten, verteilt auf ca. 100 rechtlich
autonome Einheiten. Die SB-Geräte schreiben auf den jeweiligen Servern
log files, aus denen man den Zustand der SNA-Verbindung erkennen kann.
Ziel des Vorhabens war es, diese Daten auf den Kundensystemen zu
erfassen und zentral verfügbar zu machen, um Auswertungen nach
folgenden Kriterien zu ermöglichen:
* Erkennen von Schwachstellen im Netz (z.B. überlastete Router)
* Analyse von Wiederanlaufproblemen nach Netzzusammenbrüchen
* Erkennen von Lastproblemen (zu lange Antwortzeiten/SNA-Timeouts)
* Erkennen problematischer Server
* Erkennen problematischer Konfigurationen oder Gerätekombinationen
Die Auswertungen können dazu in einer Vielfalt von Formen erstellt
werden, tabellarisch oder grafisch.
Software: C, perlDesign, Entwicklung, Einführung und Betrieb eines automatischen,
bedienerlosen, hostgestützten Fernwartungssystems für ca. 650
Anwendungsserver (Unix, NT4.0 und W2K). Die Jobs werden dabei auf
einem bestimmten Server ("master server") erstellt: Alle benötigten
Dateien werden in einen Verzeichnisbaum kopiert, auch ein
Script oder Programm namens "AutoAction". Dieser Verzeichnisbaum wird
in einem komprimiertes tar-file zusammengepackt und das dann zur
Verhinderung von Mißbrauch mit einer elektronischen Signatur versehen.
Dann wird es in eine Hostdatenbank geladen, dabei wird festgelegt,
für welche Server dieser Job bestimmt ist. Eine gezielte Auswahl
einzelner Server ist ebenso möglich wie eine Auswahl nach Kriterien
(z.B. "alle NT4.0-Server mit der Softwarekomponente XYZ"). Ebenso wird
ein Freischaltdatum und ein Verfallsdatum festgelegt. Die
Anwendungsserver fragen automatisch regelmäßig beim Host nach, ob ein
solcher Fernwartungsjob für sie bereitgestellt wurde und laden den
gegebenfalls herunter. Wegen der rechtlichen Autonomie der einzelnen
Kunden haben die die Möglichkeit, gezielt einzelne Jobs oder ganze
Jobklassen in Bezug auf das automatische Herunterladen oder in Bezug
auf die automatische Ausführung zu sperren.
Nach dem Herunterladen wird die elektronische Signatur überprüft und
das Archiv dann ausgepackt, so daß wieder der gleiche Verzeichnisbaum
wie auf dem master server entsteht. Anschließend wird das AutoAction
script ausgeführt. Dabei entstehende Rückmeldungen werden auf dem
gleichen Weg (über die Host-Datenbank) auf den master Server
übertragen, so daß dort sofort erkannt werden kann, ob dieser Job auch
wirklich auf allen Servern fehlerfrei gelaufen ist. Nur die wenigen
Server, die sich pathologisch verhalten haben müssen dann manuell
kontrolliert werden.
Es ist auch möglich, zusätzlich zu dem AutoAction Script auch noch ein
FailureRevert Script einzupacken, welches bei einem etwaigen Scheitern
des AutoAction Scriptes auf halben Weg steckengebliebene Änderungen
rückgängig macht, damit der Server bis zur manuellen Wartung in einem
stabilen Zustand verbleibt (weiterläuft, zwar ohne die Änderung, aber
wenigstens überhaupt).
Die Stärken des Systems treten vor allem bei Stichtagsumstellungen und
Notfall-Wartungsmaßnahmen hervor. Oder etwa, wenn zu überprüfen ist, ob
auch wirklich alle 45.000 Clients mit einer bestimmten Softwareversion
ausgestattet sind, bevor man sich trauen kann, ein neues Hostprogramm
freizuschalten.
Sehr nützlich ist das System auch, wenn ein Server neu installiert
wird: Nach der Installation der Software werden automatisch die
neuesten Patches aus der Hostdatenbank nachgeladen und installiert.
Software: C, perl, SNA
Ziel war die Erstellung eines Simulators zur Ausbildung von
Schiffsbesatzungen in Bezug auf die Radarnavigation. Jede Besatzung
sieht das eigene Radarbild und kann es durch Änderung der
Radarreichweite etc. beeinflussen. Jede Besatzung fährt das eigene
Schiff (Ruderlage, Maschinenleistung etc.). Alle zusammen sollen in
einer vorgegebenen Zeit ein bestimmtes Fahrmanöver durchführen (z.B.
bestimmte Formationswechsel). Der Ausbilder kann sich von seinem
Arbeitsplatz aus die Anzeigen der einzelnen Schiffsbesatzungen
anzeigen lassen und mit den Besatzungen kommunizieren (via Headset).
Er kann die Übung jederzeit stoppen und beeinflussen (z.B. Standort
eines Schiffes ändern). Ebenso kann der Ausbilder "verwaiste" Schiffe
fahren, damit mehr Schiffe an Übungen teilnehmen können als
tatsächliche Crews vorhanden sind. Die gesamte Übung einschließlich
aller Aktionen der einzelnen Besatzungen wird protokolliert und kann
gemeinsam in einem Übungsraum über einen Beamer nachvollzogen werden,
damit Fehler der Besatzungen gemeinsam besprochen werden können.
Bestandteil des Systems ist ein map editor, mit dem pseudorealistische
Küstenlinien erstellt werden können. Genau modelliert dort, wo die
exakte Küstenlinie benötigt wird, sonst anhand weniger Stützpunkte
automatisch generiert.
Das System lief auf Standard-Workstations, zunächst unter X.10, dann
unter X.11. Bei der mangelnden Leistungsfähigkeit der Hardware damals
waren Klimmzüge nötig, um ein akzeptables Zeitverhalten hinzubekommen
(Küstenlinie clippen, Radarbild zeichnen, Kollisionsprüfung).
Software: C, X.10, X.11Ausgangslage war ein notleidendes Softwareprojekt:
Der Kunde hatte von einem inzwischen in Konkurs gegangenen
ausländischen Softwarehaus einen Simulator für Kriegsschiffe
entwickeln lassen, in dem der Einsatz der Waffensysteme trainiert
werden sollte. Eine zentrale Komponente des Systems ("postal
service"), zuständig für den Nachrichtenaustausch der einzelnen
Komponenten des Simulators, war dem Normalbetrieb zwar gewachsen,
brach aber zusammen, sobald es im Vorfeld von Kampfhandlungen hektisch
wurde und das Nachrichtenaufkommen daher steil anstieg (z.B. Betätigen
von Schaltern, Tasten etc.). Das ursprüngliche Entwicklungsteam war
nicht mehr greifbar, die Dokumentation rudimentär.
Das erste Teilprojekt war eine rigorose statische Analyse des
vorliegenden postal services, um die Schwachstellen aufzudecken:
Designfehler, die Flaschenhälse bewirkten und so zu deadlocks führten.
Ergebnis war eine Dokumentation mit den gewonnen Erkenntnissen und
einem Kapitel "Wege aus dem Sumpf", in dem Lösungsvorschläge
aufgezeigt wurden.
Zweiter Schritt war eine Neuentwicklung des postal services, der keine
Schwachstellen mehr aufgewiesen hat und dadurch jedem
Nachrichtenaufkommen gewachsen war. Erreicht wurde dies durch
geschickten Einsatz von Interprozeß-Kommunikation und dynamisch
vergrößerbare Ringspeicher im shared memory mit Zugriffssteuerung
durch Semaphore.
Software: C, X.11, Unix, IPCUm das Verhalten von Kernkraftwerken im laufenden Betrieb simulieren
zu können, insbesondere bei Störungen, wird die Fortpflanzung von
Störungen in der Anlage durch von Ingenieuren a priori erstellte
Ursachen-Folgendiagramme beschrieben. Um diese Diagramme maschinell
weiterverarbeiten und zu einem zur Laufzeit des Reaktors ständig mit
den aktuellen Daten zu fütternden Modell zu kommen werden diese
Diagramme zunächst per Hand in einen Quelltext übersetzt, der einer
speziell entwickelten Grammatik genügen muß. Das ist ein wegen der
ungewohnten Grammatik zeitaufwändiger Prozeß mit vielen Roundtrips
(editieren, übersetzen, Fehler beheben, wieder übersetzen etc.). Zur
Erleichterung dieser nervtötenden Arbeit wurde im ersten Schritt ein
syntaxgesteuerter Editor geschrieben, der vor dem Start die Grammatik
einliest und dann nur noch solche Texte als Eingabe akzeptiert, die
der Grammatik genügen. In einem Menü werden die an der Stelle des
Cursors zulässigen Terminalsymbole angegeben, über Syntaxfehler kann
man den Cursor nicht hinwegbewegen. Wenn man den Cursor an das Ende
des Textes bewegen kann, dann ist der Text bis dahin syntaktisch
korrekt, wenn ein besonderes Terminalsymbol ("Ende des Textes") an
dieser Stelle zulässig ist, dann ist der Text auch vollständig. Damit
war das Problem der Syntaxfehler gelöst, aber es war noch nicht
sichergestellt, daß das Diagramm auch wirklich korrekt übertragen
wurde, also nicht zum Beispiel ein Und-Gatter statt einem Oder-Gatter
eingegeben wurde.
Dieses Problem wurde dadurch gelöst, daß in der Grammatik zusätzliche,
besondere Regeln eingebaut wurden, durch die alleine durch das
Eingeben des Textes auf einem Grafikbildschirm das entsprechende
Diagramm mit aufgebaut werden kann. Wenn das so entstandene Diagramm
am Ende des Textes mit dem Quelldiagramm übereinstimmt, dann ist der
Text korrekt eingegeben worden.
Diese automatisch erstellten Diagramme wurden dann auch zur
Rückdokumentation für den TÜV eingesetzt.
Software: FORTRAN, C, GKS, X.11Mehr als 3.000 Kunden, 75.000 eingetragene IT-Experten, davon 10.500 mit Schwerpunkt Engineering, und über 1.000.000 abgewickelte Projektanfragen: GULP Information Services ist die wichtigste Quelle für die Besetzung von IT-/Engineering-Projekten mit externen Spezialisten im deutschsprachigen Raum.
© Copyright GULP Information Services GmbH, Ridlerstraße 37, D-80339 München
Tel. +49-89-500316-300, Fax +49-89-500316-999, E-Mail: info@gulp.de
