From 2a8dda9fa4305c835c71abc02b4e30d23f5a373e Mon Sep 17 00:00:00 2001 From: Tobias Wieck Date: Sun, 7 Feb 2021 14:41:32 +0000 Subject: [PATCH] Update Eigener Parser --- Eigener-Parser.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Eigener-Parser.md b/Eigener-Parser.md index 6b695dc..99bb04c 100644 --- a/Eigener-Parser.md +++ b/Eigener-Parser.md @@ -5,7 +5,7 @@ Zunächst stellt sich die Frage, warum wird ein programmatischer Parser benötig ## Technologieauswahl Eine Art Parser schien die beste Möglichkeit zu sein, da alle Ausgabedateien von anderer Software generiert wurden. Aufgrund dieser Prämisse könnten sie bestimmt auch wieder einfach eingelesen und verarbeitet werden. -Als Sprache war hier Python die erste Wahl. Python bietet sich enorm gut dafür an, da es nicht nötig ist, feste Datenstrukturen zu erstellen. Alle Typen sind dynamisch. Weiter war es nicht wichtig, ob die Laufzeit optimal ist. Ob der Parser nun 4 Sekunden oder 10 benötigt, war nicht relevant. +Als Sprache war hier Python die erste Wahl. Python bietet sich enorm gut dafür an, da es nicht nötig ist, feste Datenstrukturen zu erstellen. Alle Typen sind dynamisch. Weiter war es nicht wichtig, ob die Laufzeit optimal ist. Ob der Parser nun vier Sekunden oder zehn benötigt, war nicht relevant. ## Stage 1: Präparieren der Eingabedateien Durch die systematische Vorarbeit, die unser Script in Bezug auf die Verzeichnisstruktur erledigt hat, lagen alle Ergebnisse in der gleichen Struktur vor. Die einzige Schwierigkeit war es nun noch, jedem Test einen eindeutigen Namen zu geben, der programmatisch verarbeitet werden kann. Folgendes Schema erschien uns hier sinnvoll. @@ -292,7 +292,7 @@ def write_run_to_db(run): In dieser Funktion werden dann in vier Tabellen alle gesamelten Informationen gespeichert, die Tabellen umfassen zwischen fünf und 37 Spalten. Jeder Run wird hierbei in der `Run` Tabelle gespeichert. Außerdem bekommt jedes Tool ebenfalls seine eigene Tabelle (Lynis, TestSSL und Otseca). Die Tabellen von den Tools werden dann nach und nach gefüllt, und über Fremdschlüssel mit der Primärtabelle verbunden. Zuletzt wird die Transaktion dann geschrieben. # Ergebnisse -Insgesamt lässt sich sagen, dass etwa 30 Regular Expressions nötig waren, um alle gewollten Logfiles über alle Tools zu parsen. Die Laufzeit beträgt hierbei etwa 10 Sekunden, wobei das Einlesen der doch relativ langen Textdateien am längsten benötigt. +Insgesamt lässt sich sagen, dass etwa 30 Regular Expressions nötig waren, um alle gewollten Logfiles über alle Tools zu parsen. Die Laufzeit beträgt hierbei etwa zehn Sekunden, wobei das Einlesen der doch relativ langen Textdateien am längsten benötigt. Der Export als SQlite hat sich im Nachhinein als sehr vorteilhaft entpuppt, da SQlite nativ mit JSON Daten umgehen kann, was sehr leichte Abfragemechanismen erlaubt.