nmap TCP-Connect-Scan

Nachdem ich im letzten Beitrag über den SYN-Scan geschrieben habe, folgt heute ein kurzer Beitrag über einen weiteren Scan-Typ. Der SYN-Scan wurde auch als halboffener Scan beschrieben, da er den Three-Way-Handshake nicht vervollständigt und somit keinerlei Kommunikation zustande kommen kann. Dem entgegen steht der TCP-Connect-Scan.

Wie der Name bereits sagt, wird hierbei eine komplette TCP-Sitzung aufgebaut und die Verbindung anschließen vom Client beendet.

Zum Aufbau der Verbindung müssen entsprechend mehr Pakete gesendet und vom Server verarbeitet werden. Gleichzeitig besteht somit auch eine größere Chance, dass Log-Systeme diesen Scan erkennen und dies protokollieren. Auch ist, bei gleichem Ergebnis, die Scan-Dauer höher. Dieser Scan-Typ ist somit nicht ganz so „geräuschlos“ wie der SYN-Scan. Anders als dieser benötigt der TCP-Connect-Scan jedoch keine administrativen Berechtigungen, was auf manchen Systemen von Vorteil sein kann.

#Syntax für einen TCP-Connect-Scan
nmap -sT 192.168.0.119

Im Wireshark stellt sich der TCP-Connect-Scan folgendermaßen darf. Der Übersichtlichkeit halber, habe ich hier auf den offenen Port 443 gefilter.

Zu erkennen ist der Three-Way-Handshake und ein anschließender Reset der Verbindung durch den Client. Auch dem TCP-Connect-Scan geht eine ICMP-Host-Discovery voraus, sofern diese nicht durch einen Parameter deaktiviert wurde.
Falls das System nicht auf ICMP-Anfragen reagiert, kann man nmap mitteilen, dass man den Host als „online“ behandeln möchte. In diesem Fall versucht nmap keine Host-Erkennung und fängt direkt an das Ziel zu scannen.

#Syntax für einen Scan ohne Host-Erkennung
nmap -Pn 192.168.0.119

Time-to-Live bei verschiedenen Betriebssystemen

Anhand der Time-to-Live (TTL) kann man in manchen Fällen auf das Zielbetriebssystem schließen. Hintergrund ist, dass verschiedenen Betriebssysteme verschiedene Standardwerte für die TTL haben. Da die TTL bei einem Ping mit zurückgemeldet werden muss, kann man so die ein oder andere Information über das Zielsystem erhalten.

Ohne viele Geschreibe, hier die „Ergebnisse“ aus dem Homelab

Schon anhand dieses einfachen Beispiels ist das Verhalten gut zu erkennen. Natürlich ist dieses nicht in Stein gemeißelt. Die Werte können verändert werden und können sich auch, je nach Betriebssystemversion, unterscheiden. Es ist eher als kleine Hilfestellung gedacht, um mit einfachen Mitteln einen unbekannten Host im eigenen Netzwerk grob zu identifizieren. Der ein oder andere Kollege wird über diesen „Kniff“ auch staunen.

Nachfolgend noch eine kleine Tabelle verschiedener Betriebssystemen und deren Standard TTL.

SystemTTL
Windows 95/98/ME32
Linux/MacOS/FreeBSD64
Windows 7/8/10128
Solaris255
Standard TTL verschiedener Betriebssysteme

Logischerweise funktioniert diese Methode nur in lokalen Netzwerken, bzw. bei bekanntem Hop-Count. Übers Internet lassen sich Dienste so jedenfalls nicht genauer identifizieren.

nmap SYN-Scan

Das Tool nmap ist wohl einer des bekanntesten Netzwerkscanner und erfreut sich, spätestens seit der Implementation der WSL 2, nicht nur bei Linux-Administratoren, großer Beliebtheit.

Zwar gibt es ein passendes Frontend namens Zenmap, jedoch geht, für mein Empfinden, damit ein Teil der „Leichtigkeit“ dieses Tools verloren. Die für einen Scan benötigte Befehlszeile ist eben schneller getippt, als ein Frontend konfiguriert, sogar inklusive dem Start über die WSL.

Beim ersten Aufruf des Programms wird man dann aber regelrecht erschlagen, Scantypen, Host-Detektion, IDS-Evasion und noch viele andere Parameter sind in der Hilfe aufgelistet.

Die wichtigsten Kommandos und ihre Bedeutung und Anwendung möchte ich in dieser Serie erläutern.

Einsteig

Nmap erwartet mindestens einen Parameter in Form einer IP-Adresse oder eines Netzwerks in CIDR-Schreibweise. Der Scan ganzer Netzwerke ist zwar ohne Weiteres möglich, jedoch kann dies, abhängig von der Scan-Einstellung, recht lange dauern. Der Einfachheit halber nehme ich in nachfolgenden Beispielen immer nur eine Adresse.

#Aufruf von nmap mit einer Zieladresse als Parameter
nmap 192.168.0.119

Wird nmap wie im obigen Beispiel aufgerufen, wird ein sogenannter SYN-Scan durchgeführt.
Wie der Name schon sagt, werden hierfür SYN-Pakete an den angegebenen Zielhost gesendet um einen TCP-Verbindungsaufbau (Three-Way-Handshake) zur simulieren. Wie das auf der Gegenseite aussieht, kann man in nachfolgendem Screenshot erkennen.

Ist ein Port verfügbar, wird der Server eine entsprechende Antwort, mit gesetzten SYN und ACK-Flag, senden. Anhand dieser Antwort weiß nmap dann, dass der Port erreichbar ist. Lauscht auf der Seite des Zielhosts kein Dienst kann kein SYN-ACK gesendet werden. Was jedoch möglich ist, ist das Übermitteln eines ICMP-Paketes mit dem Statuscode 3 an den vermeintlichen Client. Anhand dieser Informationen kann nmap den Portzustand ebenfalls interpretieren.

Damit ist die Arbeit von nmap bereits beendet. Es werden keine weiteren Anfragen an den Zielhost gesendet und das empfangene SYN-ACK auch nicht bestätigt. Die Kommunikation versackt sozusagen auf halber Strecke.

Der Vorteil des SYN-Scan liegt in seiner Einfachheit. Für den Zielhost erscheint die Anfrage als valide Clientanfrage zum Aufbau einer Verbindung. Zusätzlich hat eine einzelnen SYN-Anfrage erstmal gute Chancen durch eine Firewall, oder ein anderes Sicherheitssystem hindurch zu gelangen. Da SYN-Pakete im Grunde leere Datenpakete sind, können diese auch sehr schnell und massenhaft versendet werden.

Im oben gezeigten Screenshot sind noch ganz zu Beginn des Mitschnitts drei ICMP-Pakete zu erkennen. Diese nutzt nmap um vor Beginn eines Scans eine Host Erkennung durchzuführen. Ist der angegebene Zielhost offline, bzw. antwortet nicht auf ICMP-Pakete, wird der Scan abgebrochen.

Homelab 3 Installation vCenter

Die Lab-Umgebung sollte möglichst vom eigentlichen Heimnetz getrennt werden, sodass hierfür die Konfiguration eines entsprechenden vSwitches, nebst der benötigten Portgruppen auf dem ESX notwendig war. Das eigentliche Routing und Firewalling erfolgt dann mittels pfSense.
Die ursprüngliche Idee, eine lokale Windows Domäne aufzuziehen, habe ich relativ schnell verworfen, da die Hardware des Odroid dem nicht gewaschen scheint. Sicherlich ist der Betrieb einzelner Windows VMs ohne Weiteres möglich, jedoch wollte ich mich erstmal mit der neuen Umgebung vertraut machen. Eine Windows Domäne kann auch später noch folgen.

Die Installation der pfSense verlief ohne Probleme und relativ zügig. Um das Routing aus aus meinem Heimnetzwerk zu ermöglichen, habe ich manuelle Routing-Einträge auf meinem PC hinzugefügt. Anschließend habe ich ein paar grundlegenden Regeln in der Firewall erstellt und getestet.

Der nächste Schritt war die Bereitstellung einer vCenter-Appliance um eine möglichst „realitätsnahe“ Umgebung zu erzeugen. Kaum eine VMware-Umgebung kommt ohne eine solche Appliance aus, da sie eine Vielzahl an Management- und Überwachungsfunktionen mitbringt.
Um diese jedoch bereitstellen zu können benötigt man DNS. Zwar kann man das Ganze auch „irgendwie“ mittels Einträgen in die hosts-Datei hinbiegen, ich halte das aber für Bastelei. Leider sieht man auch in produktiven Umgebungen immer wieder solche „Workarounds“ und wundert sich dann über ein nicht erklärbares Systemverhalten.
Glücklicherweise bietet pfSense einen eigenen DNS-Resolver, welchem man mittels Overwrites individuelle Einträge hinzufügen kann. Die benötigten Einträge für die neue vCenter-Appliance, sowie den ESX-Server waren schnell angelegt. Zusätzlich habe ich gleich noch einen Eintrag für die Firewall erstellt.

Wer noch ein Stück weiter gehen möchte, kann ebenso NTP auf der pfSense aktivieren um einen zentralen Zeitserver für das Netzwerk bereitzustellen. DHCP oder sonstige Dienste habe ich vorerst nicht konfiguriert. Die Adressvergabe in meiner Lab-Umgebung erfolgt komplett mittels statischer IPv4-Adressen.

Die Installation der kleinsten vCenter-Appliance verlief dann auch überwiegend unauffällig….bis auf die Zeit.

Der Odroid ist mit seinem Celeron Prozessor nicht unbedingt leistungsstark und brauch für alles etwas länger. Allein die jetzt laufenden Dienste lasten die CPU schon gut aus. Der Start des vCenters bringt die CPU zum Anschlag. Wenn es dann einmal läuft, ist es einigermaßen performant. Ausnahmsweise ist der Arbeitsspeicher mal nicht das Problem, von den 32GB sind noch gut 26GB frei.

DEB Paket unter WSL erstellen

Nachdem ich ein kleines Script angepassst hatte, wollte ich dieses in ein DEB-Paket überführen. Da ich zu diesem Zeitpunkt nur einen Windows 10 PC mit WSL zur Verfügung hatte wollte ich diesen, eigentlich trivialen Job, dort ausführen.

Beim Aufruf des Befehls kam es zu einer Fehlermeldung, die ich so nicht erwartet hatte…

#Befehl zur Erstellung des DEB-Pakets
dpkg-deb --build tolles_script_0.1
dpkg-deb: error: control directory has bad permissions 777 (must be >=0755 and <=0775)

Ist ja kein Problem, schnell die Dateirechte entsprechend angepasst und nochmal versucht…Pustekuchen. Zwar scheint das Ändern der Rechte mittels „chmod“ grundlegend zu funktionieren, jedoch läuft der Befehl weiterhin auf die gleiche Fehlermeldung.

„chmod“ selbst meldet dabei jedoch keine Probleme.

Schnell vermute ich die WSL als Ursache und tatsächlich scheint es dort „Optimierungsbedarf“ zu geben. Auch Microsoft hat das erkannt und hält einen entsprechenden Artikel in der WSL-Dokumentation parat.

Advanced settings configuration in WSL | Microsoft Docs

Das Verhalten des WSL lässt sich anhand einer Konfigurationsdatei an die Erfordernisse anpassen. Dazu muss die entsprechende Datei erstellt und mit den gewünschten Optionen befüllt werden.

#erstellen der WSL-Konfigdatei
nano /etc/wsl.conf

Der Dateizugriff unter Linux und Windows ist grundsätzlich verschieden, Windows „versteht“ die vom Subsystem gesetzten Optionen nicht und kann diese somit auch nicht abbilden.

Beim überfliegen der Dokumentation fällt einem folgende, standardmäßig deaktivierte Einstellung auf.

ParameterBeschreibungStandardwert
metadataWhether metadata is added to Windows files to
support Linux system permissions
disabled

Das klingt genau nach dem was wir suchen. Die Einstellung setzt man anschließend in der Konfigurationsdatei.

#wsl.conf Beispielkonfiguration
[automount]
enabled = true
root = /mnt/
options = "metadata"

Nach der Aktivierung der Option ist es notwendig das Linux-Subsystem einmal komplett neu zustarten. Am schnellsten geht das mittels Neustart des Dienstes mit der Powershell. Achtung: Hierfür sind Administratorrechte notwendig. Sind diese nicht vorhanden, ist auch ein Neustart des PCs möglich!

#Neustart des WSL-Dienstes in Powershell
Get-Service LxssManager | Restart-Service

Anschließend setzen wir die Dateiberechtigungen erneut:

chmod 755 tolles_script_0.1/DEBIAN/ && chmod 755 tolles_script_0.1/DEBIAN/control

Zuletzt wird der Befehl zur Erstellung des DEB-Paketes neu ausgeführt. Und siehe da, keine Fehlermeldung mehr und ein hoffentlich funktionsfähiges DEB-Paket.

dpkg-deb --build tolles_script_0.1
dpkg-deb: building package 'tolles_script_0.1' in 'tolles_script_0.1.deb'

Als WSL nutze ich übrigens Kali Linux. Ich bin mir aber sicher, dass das Problem auch bei anderen Distributionen auftritt.

Ahnenforschung 2 Wie anfangen?

Die Ahnenforschung, oder auch Genealogie ist ein sehr zeitintensives, aber auch erfüllendes Hobby. Dank der voranschreitenden Digitalisierung von Akten wird es Zusehens einfacher an relevante Informationen zu gelangen.

Dies hat aber auch einen Nachteil, gerade als Einsteiger wird man regelrecht erschlagen von all den Möglichkeiten und weiß nicht so richtig wie man vorgehen soll. Hierfür möchte ich einen kleinen Einstieg geben, welcher auf meinen persönlichen Erfahrungen beruht. Der Beitrag richtet sich an Interessierte, die bisher kaum oder keine Berührungspunkte mit dem Thema hatten.

1. Ein Ziel definieren

Was möchte ich überhaupt mit meinen Nachforschungen erreichen? Hier sollte man unterscheiden, ob man die Vergangenheit einer einzelnen Person aufarbeiten möchte, oder ob das Ziel die Erstellung eines möglichst umfangreichen Stammbaums sein soll. Es erscheint logisch, dass der Aufwand für letzteres wesentlich höher ist.

Ursprünglich war ich nur auf der Suche nach Informationen zu einer Person, nämlich meinen Urgroßvater. Diese Suche kann man in groben Schritten im entsprechenden Beitrag verfolgen. Dabei bin ich jedoch auf eine Fülle anderer interessanter Informationen gestoßen, sodass aus der Einzelpersonensuche mittlerweile ein kleinerer Stammbaum geworden ist.
Um es am Anfang einigermaßen übersichtlich zu halten, empfehle ich, die Suche bei einer bestimmten Person zu beginnen, komplizierter wird es von ganz allein.

2. Daten sammeln und ordnen

Die erste und meiner Meinung nach beste Informationsquelle sind noch lebende Verwandte.
Alle Informationen, die diese Personen beisteuern können sollten schriftlich festgehalten werden. Je genauer die Daten aufgenommen werden können umso besser. Falls kein genaues Datum bekannt ist, sollte eine grobe Jahresangabe ergänzt werden. Dies hilft später bei der Einordnung.

Nachfolgend die wichtigsten Informationen, die zu erfragen sind:

  • alle Namen die ihr bekommen könnt. Bei Frauen nach Möglichkeit zusätzlich die Mädchennamen
  • Geburts-, Hochzeits- und Sterbedaten, sowie im Idealfall die dazugehörigen Orte
  • Angaben zur Mutter und zum Vater
  • Angaben zu Geschwistern, z.B die ungefähre Anzahl an Brüdern oder Schwestern, im Idealfall auch hier inklusive den wichtigen Daten
  • Briefe, Einträge in Poesiealben, Tagebücher, Feldpost
  • andere Dokumente wie z.B. Gesellen- und Meisterbriefe, Studienunterlagen oder Zeugnisse, Ein- Ausreiseunterlagen, Fahrkarten etc.

Mit diesem Berg an Unterlagen habt ihr schon mal einen guten Start. Dabei der Recherche sicherlich auch das ein oder andere Foto zum Vorschein kommt, sollte dies ebenso erfasst werden.

3. Daten digitalisieren

Als erstes sollten alle Dokumente digitalisiert werden. Am einfachsten und schnellsten geschieht das mittels Smartphone, Tablet oder Digitalkamera. Achtet dabei auf eine ausreichende Beleuchtung und erfasst möglichst alle Informationen. Dies gilt sowohl für Textdokumente, als auch Fotos.
Arbeitet nach Möglichkeit nur selten mit den original Dokumenten, da diese oft schon etwas älter sind und sicherlich keine Lagerung unter Idealbedingungen erfahren haben.
Die Digitalisierung der Dokumente bringt einen weiteren wichtigen Vorteil mit sich. Fotos können Nachcoloriert und repariert werden, Dokumente können für eine bessere Lesbarkeit vergrößert werden und auch das Verteilen von Bildern an Verwandte sowie in Foren (zum Beispiel für Übersetzungen) ist einfacher.

4. Recherchedienste nutzen

Nachdem nun alle Primärquellen befragt und alle Dokumente gefunden und digitalisiert wurden, beginnt die eigentliche Recherchearbeit. Hierfür bieten sich verschiedene Dienst im Internet an. Sehr gute Erfahrungen habe ich mit Ancestry gemacht. In dieser Datenbank sind eine Vielzahl genealogischer Daten erfasst. Mit etwas Glück findet ihr sehr schnell erste Ergebnisse. Ich habe hier die Heiratsurkunde meiner Urgroßeltern, sowie die Gefallenenmeldung meines Urgroßvaters gefunden. Dies waren für mich sehr wichtige und emotional Funde, da beide Dokumente als verschollen galten.

Ein weitere möglicher Anlaufpunkt ist myHeritage. Der Funktionsumfang ist vergleichbar mit dem von Ancestry, allerdings kommen die Recherchequellen eher aus dem amerikanischen Raum. Unterlagen zur deutschen Vergangenheit sind dort zwar ebenso zu finden, jedoch in wesentlich geringerer Stückzahl. Die oben genannten Dokumente habe ich dort bisher nicht gefunden. Es schadet aber natürlich nicht, einen Blick zu riskieren. Zusätzlich bietet myHeritage die Möglichkeit Schwarz-Weiß-Fotos zu colorieren, Fotos zu reparieren und mittels KI-animierte Portraits eurer Verwandten zu erstellen.

Darüber hinaus gibt es auch noch weitere Online-Dienste und Programme, welche ihr für eure Recherche nutzen könnt, auf diese werde ich jedoch nicht in diesem Beitrag eingehen.

Sobald ihr euch für einen Dienst, oder ein Programm entschieden habt, solltet ihr einen Stammbaum anlegen. Anschließend tragt ihr alle Informationen, zu allen für euch relevanten Personen ein. Im Bedarfsfall könnt ihr auch die von euch fotografierten Dokumente und Fotos hochladen und habt so eine komplette Übersicht über euren Forschungsstand

5. weiter Quellen und Recherchemöglichkeiten

Sind die Quellen bei den Online Diensten vorerst erschöpft, solltet ihr die Archive der in Frage kommenden Städte ins Auge fassen. Oft wurden die Bestände bereits digitalisiert und es ist möglich den Zugriff zu beantragen. Ich habe dies für die Stadt Görlitz getan, wobei die Beantragung sehr einfach per Mail erfolgen konnte.

Benötigt ihr Informationen zu Verwandten, welche in den Weltkriegen gedient haben ist die Personenkartei das Bundesarchiv unbedingt zu empfehlen.
Hierfür ist ein Identitätsnachweis und das Ausfüllen eine Benutzungsantrags notwendig. Die Kolleginnen und Kollegen des Bundesarchivs übernehmen dann, für ein kleines Entgelt, die Recherchearbeit. Die Bearbeitung euerer Anfrage dauert oft mehrere Monate, teils hört man auch von Bearbeitungszeiten von bis zu zwei Jahren. Oft lohnt sich das Warten aber, da hier sehr viele und vor allem interessante Informationen zu finden sind.

Als Ergänzung kann man parallel oder nachträglich beim Militärarchiv anfragen, wobei auch hier eine entsprechende Wartezeit berücksichtigt werden muss.

Neben den offiziellen Stellen gibt es noch einige Organisationen und Vereine, welche beachtet werden sollten. Hierzu zählen unter anderem der Suchdienst des Deutschen Roten Kreuz, der Volksbund sowie der Verein Russlands Kriegsgräber.

6. Sackgassen vermeiden und lösen

Auch der beste Ahnenforscher wird mal in eine Sackgasse kommen und keinen Ausweg wissen. Für diesen Fall empfehle ich einen Blick in das Forum Ahnenforschung.
Nachdem ihr euch dort registriert und kurz vorgestellt habt, könnt ihr ein neues Thema eröffnen, in dem ihr eure Suchfrage und bisherigen Erkenntnisse möglichst präzise formuliert. Meiner Erfahrung nach sind die Forumsmitglieder sehr hilfsbereit und freundlich.
Ein Forum ist aber immer ein Geben und Nehmen, sofern ihr also neue Informationen durch das Forum erhalten habt, sollte ihr diesen den Mithelfern nicht vorenthalten.

7. Lese- und Deutungshilfen

Unterlagen aus dem deutschsprachigen Raum sind oft in Sütterlin geschrieben. Vorgedruckte Dokumente sind dabei oft noch gut lesbar, wohingegen handschriftliche Notizen schwieriger zu entziffern sind. Falls euch die im Wikipedia Artikel enthaltene Schrifttafel nicht weiterhilft, möchte ich nochmal auf der Forum Ahnenforschung verweisen. Dort gibt es einen extra Bereich für die Übersetzung und Lesehilfe. Auch hier konnte mir schon sehr gut weitergeholfen werden.

8. Fazit

Das Thema Ahnenforschung ist viel umfangreicher als man zuerst glauben mag. Ich hoffe, dass der Einstieg verständlich war und die erhoffte Orientierung bieten kann.
Mittels der genannten Informationsquellen solltet ihr zumindest die ersten neuen Hinweise zur Euren Verwandten finden können.

Viel Spaß bei der Suche und hoffentlich viele spannende und aufschlussreiche Entdeckungen.

Ahnenforschung 1 der unbekannte Urgroßvater

In meiner nachfolgenden Betrachtung geht es um meinen Urgroßvater Martin Fregin, welcher am 11.11.1906 in Lepuwek/Lublin in Ostpreußen das Licht der Welt erblickte. Er war das jüngste von 10 Kindern der Eheleute Ludwig und Pauline Fregin geb. Lutz.

Die Familie zog es ca. 1908 in die Nähe von Elbing, genauer gesagt in den Ort Buchwalde, wo Ludwig Fregin ein größeres landwirtschaftliches Anwesen außerhalb des Ortes in Richtung Lichteinen erwarb.
Dieses Grundstück verkaufte er während der Hyperinflation im Jahr 1923 und erwarb einige Tage später mit dem Erlös, der freilich nur noch ein Bruchteil wert war, ein kleineres landwirtschaftliches Anwesen. Sein Sohn Martin trat in die Fußstapfen seines Vater und begann eine Lehre als Müller.

In den darauffolgenden Jahren lernte Martin seine zukünftige Frau, die Zigarrenmacherin Frieda Neumann kennen. Beide Heirateten am 5. Juli 1933 in Königsberg. Dabei entstand das einzige mir bekannte Foto von meinem Urgroßvater.

das einzige bekannte Foto meiner Urgroßeltern, 1933

Die originale Heiratsurkunde aus Königsberg konnte ich in einem Archiv ausfindig machen.

Hochzeitsurkunde aus Königsberg, 1933

Die junge Familie bezog eine Wohnung in Elbing im äußeren Mühlendamm 13, an welche sich meine Oma auch noch erinnert. Auch im Einwohnerbuch der Stadt Elbing von 1934 findet sich diese Adresse.

Karte von Elbing, 1911

Den nächsten Anhaltspunkt gibt die Auskunft des Bundesarchivs für Angehörige der Wehrmacht. Zwar wird kein konkretes Einzugsdatum genannt, es ist jedoch bekannt das er 1939 als Schütze in das Infanterie-Regiment 400 eingegliedert wurde. Die übergeordnete Division marschierte über Graudenz Richtung Warschau bis in das Vorfeld der Festung Modlin. Dort erlebte sie das Ende des Polenfeldzugs. Martin erlebte dies nicht, er lag, aufgrund einer Fußverletzung im Reserve Lazarett 1 Königsberg/Preußen. Leider sind mir keine weiteren Hinweise über seine Zeit im Lazarett bekannt. Nach der Wiederherstellung seine Frontverwendungsfähigkeit wurde er am 2.Dezember 1939 zurück zur Truppe beordert.

Im Jahr 1940 erfolgte dann die Versetzung in die 6. Kompanie des Infanterie-Regiments 371. Diese Einheit war der 161. Infanterie-Division unterstellt, welche zur 9. Armee gehörte.

Diese Einheit marschierte anschließend mit der Heeresgruppe Mitte Richtung Russland.
Im September tobten die Kämpfe um Cholm, während derer Martin von Splittern einer Artilleriegranate in den linken Oberschenkel getroffen wurde. Aufgrund seiner nur leichten Verletzung, verblieb er bei der Truppe.

Weniger glücklich verliefen die Winterkämpfe um Rschew. Auf der Personenkartei ist folgendes vermerkt:

Auszug aus der Personenkartei der Wehrmacht

4.1.42 Wolynowo gefallen. Granatsplitter Kopf
Grablage: Jowek Pjatiletka bei Trotzkoje an der Wolga zwischen Subzoff und Staritza

Meine Recherche ergab einige interessante Informationen. Dank frei verfügbaren Kartenmaterials aus der Zeit und mittels Berichten von Zeitzeugen konnte ich die Umstände ein wenig besser beleuchten. Hilfreich war hier vor allem der Tätigkeitsbericht des Divisions Arztes der 161. Infanterie Division vom 21.06.1941 bis 01.07.1944.

Für den betreffenden Zeitraum wurde dort niedergeschrieben:

02.01.1942
Wagenhalteplatz wird wegen weiteren Zurücknehmens der H.K.L. nach Batjukowo, der H.V.Pl. von Alexina (Aleßina) nach Trojtzkoje befohlen.
Div.-Stabs-Quartier Trojtzkoje. Die San.-Komp.1/241 befindet sich auf dem Marsch.
Hinter ihr marschieren die unterstellten Teile einer Fahrkolonne mit 200 Verwundeten.

In der Nacht werden die Verwundeten in einer von der Kompanie vorbereiteten Schule untergebracht und versorgt.


03.01.1942
Wagenhalteplatz Batjukowo wird nach Trojtzkoje zurückgenommen.
Die von der Kompanie auf Fahrkolonnen transportierten Verwundeten kommen in Subzow (Subtzow) an und werden der San.-Komp.2/241 und der Krankensammelstelle überwiesen.


Auf diesem Transport vom 30.12. bis 3.1.42 verstarben von den 300 zum Teil Schwerverwundeten drei. Allgemein wurde der Transport, der unter den schwierigsten Verhältnissen bei größter Kälte -unter minus 35° Grad- durchgeführt wurde, von den Verwundeten in den mit Heu ausgepolsterten Hf 1 gut vertragen.

04.01.1942
Wagenhalteplatz Koleßnikowa.
Der H.V.Pl. für den Div.-Abschnitt bleibt in Subzow (Subtzow) bei der San.Komp.2/241.


Die Lage ist begründet durch die guten Straßen und Verbindungen von der H.K.L. nach Subzow (Subtzow) und durch das Fehlen geeigneter
Räumlichkeiten zwischen H.K.L. und Subzow (Subtzow).
In Subzow (Subtzow) besteht außerdem gute Abtransportmöglichkeit.
Krankensammelstelle, Feldlazarett 1/532, Lazarettzüge.

Karte der Gebiete um Subzoff, 1943

Die oben genannten Truppenbewegungen lassen sich sehr gut auf dem Kartenausschnitt nachvollziehen. Der Rückzug des Hauptverbandsplatzes von Alexina im Norden nach Trojtzkoje, ebenso ist der Wagenhalteplatz Kolessnikowa sichtbar.
Der Ort an dem mein Urgroßvater gefallen ist muss Wolykina gewesen sein, in moderneren Karten wird dieser Ort als Volynowo (Wolynovo) beschrieben. Dieser ist ca. 5km vom Hauptverbandsplatz in Trojtzkoje entfernt.
Als Todesursache ist auf der Personenkartei „Granatsplitter Kopf“ vermerkt. Seine sterblichen Überreste könnten dann zum Hauptverbandsplatz transportiert worden und dort bestattet worden sein. Als Grablage wird „Jowek Pjatiletka bei Trotzkoje an der Wolga“ angegeben.

Hier enden meine bisherigen Nachforschungen…

Das nächste was ich klären möchte, ist der Eintrag „Jowek Pjatiletka“ und die Bedeutung dahinter.

HomeLab 2 Übergangsphase

Nach der Kündigung des Hetzner Servers musste ich die Idee des eigenen Labs kurzfristig auf Eis legen. Es mangelte an geeigneter Hardware, die Beschaffung eines HP Microservers erschien mir zu teuer und auch sonstige gebrauchte Hardware entsprach nicht unbedingt meinen Vorstellungen.

Bei meiner Recherche stieß ich durch Zufall auf den Hersteller Odroid, welcher eine Vielzahl von kleinen und kleinsten Systemen anbietet. Darunter befand sich auch, der mittlerweile leider nicht mehr verfügbare Odroid H2+.

Das Gerät kombiniert einen Intel J4115, zwei SO-Dimm Slots mit einer Maximalbestückung von 32GB RAM, zwei 2,5 Gbit/s Realtek LAN Ports, 2x SATA sowie einen 4 x PCIe 2.0 Port, an den man wahlweise eine nVME oder andere Erweiterungen anschließen kann.

Zusätzlich zum eigentlichen Gerät benötigt man noch ein passendes Netzteil (14-20V/4A mit Hohlstecker 5,5mm/2,1mm)
Dabei erfolgt die Versorgung der verwendeten Festplatten direkt über das Board. Hierfür werden spezielle JST-SATA Stromkabel benötigt, welche man sich aber im Notfall auch selbst herstellen kann.
Als Zubehör bietet Odroid unter anderem verschiedenste Plexiglas Steckgehäuse, einen Schalter und Netzteile an.

Vorteil des Odroid H2+ ist für mich der recht geringe Stromverbrauch, das passive Kühlsystem in Kombination mit der geringen Größe.
Das erste Testgerät war schnell mit 32GB RAM und einer 1TB nVME bestückt, ein angepasstes ESXi 6.7 Image habe ich über das Odroid Forum erhalten. Die Anpassungen sind notwendig gewesen, da die Realtek Netzwerktreiber, sowie die nVME-Treiber nicht standardmäßig im ESXi Image enthalten sind. Die benötigten VIBs sind jedoch frei erhältlich und so kann ein jeder das benötigte Custom-Image erstellen.

Die Installation verlief dann auch ohne Probleme und nach wenigen Minuten konnte ich meine neue Testumgebung booten. Die Grundidee der Lab-Umgebung schien vorerst zu funktionieren. Aufgrund der kompakten Abmessungen erschien es mir auch möglich zukünftig mehrere Odroids im Cluster zu nutzen, leider war selbst zu diesem Zeitpunkt die Verfügbarkeit der Hardware schon relativ schlecht, sodass ich dieses Vorhaben auf einen späteren Zeitpunkt verschieben wollte. Ohnehin stand erstmal die Bereitstellung einer einigermaßen tauglichen VMware Umgebung auf dem Plan.

HomeLab 1 Die Anfänge

Seit jeher hatte ich das Verlangen eine einigermaßen sinnvolles HomeLab aufzubauen. Woher dieser Drang rührt, kann ich nicht sagen, aber irgendwie fasziniert mich die Idee.

Die ersten Versuche wurden klassische mit einem RaspberryPi der ersten und zweiten Generation vorgenommen. Dies kann man jedoch für meinen Fall als Spielerei abtun.
Aufgrund meiner beruflichen Tätigkeit arbeite ich zum Großteil mit den Produkten von VMWare. So toll das manchmal auch ist, im Ressoucenbedarf, allein für die Managementfunktionen, ist es mitunter „kompliziert“. Hier unterscheidet sich das HomeLab nicht unbedingt vom großen Rechenzentrum, denn Arbeitsspeicher ist irgendwie immer knapp. Erschwerend kommt beim Privatanwender noch der Kostenaspekt hinzu, da Beschaffung und Betrieb nicht immens teuer sein sollten.

Nach den missglückten RaspberryPi-Versuchen, konnte ich einen geeigneten Dedicated Root Server in der Hetzner Serverbörse ergattern. Für ca. 45€ pro Monat konnte ich so auf immerhin auf einen Intel Xeon 1230v3 mit 8 Thread und bis zu 3,70 GHz, 32GB RAM, sowie 2TB SAS Platten zurückgreifen. Darauf lief ein Standalone VMware ESXi 6.5 (später 6.7) als Typ 1 Hypervisor, welcher wiederum die Basis für eine kleine Testumgebung, nebst pfSense-Firewall, OpenVPN-Server, eigener Nextcloud-Instanz und Active Directory stellt.

Diese Umgebung lief sehr unauffällig, stabil und performant. Später wurde das Konstrukt durch ein Monitoring mittels Grafana ergänzt. Ich konnte sogar einige Test für die Arbeit auf die pfSense– und OpenVPN-Infrastuktur auslagern, da wird zu diesem Zeitpunkt noch kein vollumfängliches Testsystem dafür hatten. Alles in allem war dies ein voller Erfolg und ich war soweit zufrieden…

…ESXi als Standalone ist nun nicht wirklich Praxistauglich. Für die Installation einer vCenter Appliance fehlte es mir an Ressourcen. Vor allem RAM, da die VCSA schon zwischen 8-10GB RAM haben möchte, in neueren Versionen sogar eher 12GB. Erschwerend kam hinzu, dass „mein Server“ nur 32GB RAM ansprechen konnte, der Chipsatz unterstützt einfach nicht mehr. Zusätzlich hatte ich nur einen einzigen Host. Das bedeutet, dass sämtliche interessante Funktionen die so ein vCenter anbietet, nicht für mich realisierbar waren.

Den Todesstoß für diese Art Lab brachte dann ESXi 7.0 mit sich. Die Hardware wurde zum teil nicht mehr unterstützt, was den Weiterbetrieb natürlich empfindlich beeinflusste. Auf Ewig bei ESXi 6.7 verbleiben war keine Option für mich. So kündigte ich „meinen Server“, erstellte ein Backup der wichtigsten Nextcloud Daten und beerdigte das Projekt vorerst.

Hallo Universum…

„Hallo Welt“ kennt ja im Grunde jeder, der wenigstens einen minimalsten Berührungspunkt mit dem Thema Programmieren oder Scripten hatte. Doch die Möglichkeiten moderner Technik sind nahezu unbegrenzt…warum sollte man also beim schnöden „Hallo Welt“ bleiben, wenn es auch ein paar Nummern größer geht?