Archiv der Kategorie: Uncategorized

Routing mit Linux in virtuellen Umgebungen

Veröffentlicht am von
Antwort

Vor 4 Jahren hatte ich einen Blog geschrieben, wie man einen Microsoft Hyper-V Server 2016 als Router “verwenden” kann.

Natürlich stellt man sich dabei die Frage, wieso man das tun sollte? Zum einen ist der Hyper-V Server von Microsoft kostenlos und hat als Mitglied der Windows Server Core Familie geringere Systemanforderungen.

Es gibt hier eine Alternative, dazu müssen wir aber die Windows-Welt verlassen und uns Linux anschauen. Ich selbst bin historisch mit SUSE Linux verbunden, daher habe ich für diese Lösung openSUSE Leap 15.2 verwendet.

Als Ausgangslage haben wir die gleichen Voraussetzungen wie im Blog damals, also gleiche Netzwerke, IP-Adressen und die FRITZ!box usw. Also einfach mal den Blog nochmals anschauen, dort ist auch die Konfiguration der FRITZ!box selbst beschrieben.

Ausgangslage

Hier eine kurze Zusammenfassung davon:

  • Server mit 3 Netzwerkkarten (172.16.16.253, 192.168.110.0 und 192.168.120.1)
  • Fritz!BOX für den Internet-Zugang
  • Netzwerk an der FRITZ!box ist 172.16.16.0/24, das Gateway ist immer die 1 (also die FRITZ!box selbst)

Konfiguration der Linux VM

Für die VM unter Hyper-V habe ich die folgenden Parameter verwendet:

  • Hyper-V Generation 2 VM mit deaktiviertem Secure Boot
  • 2 CPUs
  • Dynamischer Hauptspeicher mit 1GB Start und maximal 2GB, im Betrieb läuft die VM mit grob 800MB
  • 64GB Festplatte (wobei hier auch weniger ausreichend ist), da die VHDX aber dynamisch ist, stellen die 64GB kein Problem dar
  • Zum Start nur einen Netzwerk-Adapter, wobei im Verlauf der Konfiguration weitere hinzugefügt werden

Die folgende Abbildung zeigt eine Übersicht der VM.

image

Installation openSUSE Leap 15.2 in der VM

Für die Installation wird das ISO-Image gemounted und die VM gestartet.

image

Im nun folgenden Menü Installation auswählen und den Dingen seinen Lauf lassen.

image

Da die VM über den einen Adapter eine IP-Adresse vom DHCP-Server bekommen hat, ist das Linux Setup in der Lage ggf. notwendige Updates aus dem Netz zu laden. Nach knapp 2min erscheint die Auswahl zur Konfiguration der Tastatur und der Lizenzvereinbarung. Ich verwende gerne VMs in englischer Sprache (English US) dazu aber eine Tastatur mit den deutschen (QWERTZ) Layout.

image

Hier dann auf Next drücken. Im nun folgenden Menü können wir auf eine Aktivierung von Online Repositories für unseren Zweck verzichten, also No auswählen.

image

Da wir einen schlanken Server wollen, treffen wir die Auswahl Server bei der Abfrage der System Role. Damit  haben wir zwar keine Oberfläche, können aber auf YaST zurück greifen, der alle notwendigen Aufgaben für uns erledigen kann.

image

Weiter geht es mit Next mit dem Vorschlag der Partitionierung die wir so übernehmen können.

image

Hier ebenfalls mit Next die Installation fortsetzen. Als Zeitzone wähle ich Europe und Germany und drücke abermals den Next Button.

Der Benutzer der im nächsten Schritt angelegt wird, findet später seine Verwendung für alle Aufrufe mit sudo.

image

Mit der Übersicht der gewählten Parameter kann die Installation starten.

image

Die gut 800 Pakete mit knapp 2GB Gesamtgröße installiert das Setup relativ schnell, für einen Kaffee reicht es aber trotzdem Smile

Konfiguration der Netzwerk-Adapter

Nach dem Neustart kann das ISO von der VM entfernt werden und die Anmeldung erfolgen.

image

YaST wird danach mit dem sudo Befehl gestartet und alle weiteren Schritte erfolgen im YaST Control Center unter System / Network Settings.

image

Als erstes verpassen wir der Netzwerkkarte eine feste IP (172.16.16.253/24). Dazu wird mit Edit die Konfiguration bearbeitet. Innerhalb von YaST springt man mit der TAB-Taste zwischen den einzelnen Menüpunkten hin und her. Zusätzlich zur IP-Adresse setze ich auch gleich den Hostnamen.

image

Mit Next bekommen wir wieder die Übersicht über die gemachten Einstellungen.

image

In den Einstellungen System / Network Settings / Hostname / DNS trage ich nochmals einen statischen Hostnamen ein und dazu noch die beiden im Netzwerk vorhandenen DNS-Server.

Mit Quit wird YaST beendet und die VM heruntergefahren, was wieder mit einem sudo shutdown erfolgt. Das Herunterfahren der VM ist notwendig, da ich zwei weitere  Netzwerk-Adapter hinzufüge die mit den Netzen 192.168.110.0/24 und 192.168.120.0/24 konfiguriert werden.

image

Der Trick, nur einen der beiden neuen Netzwerk-Adapter zu verbinden funktioniert unter Linux leider nicht, beide werden als Not Connected dargestellt. Nach dem Start der VM sind beide Netzwerk-Adapter zusätzlich sichtbar und können konfiguriert werden.

image

Welcher nun der richtige Adapter ist, lässt sich über die MAC-Adresse herausfinden.

image

Der Adapter eth1 bekommt nun die IP-Adresse 192.168.110.1/24 und dient zukünftig als Gateway für dieses Subnetz.

image

Analog dazu Adapter eth2 mit der Konfiguration 192.168.120.1/24 hier die Zusammenfassung aller Netzwerk-Adapter.

image

Was fehlt nun eigentlich noch? Richtig, wir haben das Routing selbst nicht aktiviert und ein Gateway ist ebenfalls noch nicht konfiguriert. Das erfolgt in den nächsten beiden Schritten.

Gateway und Routing

Die bisher gemachten Konfigurationen kann man mit der Auswahl von Next einfach mal schreiben lassen und hat diese damit gesichert.

Danach sind wir wieder im YaST Control Center unter System / Network Settings unterwegs.

image

Dort wird unter Network Settings / Routing die Weiterleitung für IPv4 aktiviert (wer hier IPv6 benötigt, bitte zusätzliche diese Option auswählen).

image

Damit fehlt nur noch das Gateway und das ist im YaST in der Textversion nach meiner Meinung fies versteckt.

Der Dialog zur Konfiguration ist unter System / Network Settings / Routing und dann unter der Option Add zu finden.

image

Hier wird das Gateway 172.16.16.1 für den Adapter mit der IP-Adresse 172.16.16.253 konfiguriert und damit die Konfiguration abgeschlossen.

Wer will, kann die VM nochmals neustarten. Bei mir hat es ohne diesen geklappt und der Router war fast fertig, denn natürlich muss noch die Firewall konfiguriert werden, sonst geht bei der Einstellung default nur der Ping durch.

Konfiguration der Firewall

Die Firewall in openSUSE verwendet Zonen, die eine Sammlung von geöffneten Ports und Protokollen darstellen. Ich habe die Firewall auf trusted gesetzt, damit ist ein interner Datenverkehr ohne weiteren Einschränkungen möglich.

image

Dazu werden die Netzwerk-Adapter mittels YaST von der Zone default in die Zone trusted geändert.

image

Enjoy it, b!

Windows 10 Hello mit dem Small Business Server

Veröffentlicht am von
1

Mit Hello in Windows 10 existieren eine Reihe von biometrischen Alternativen um sich an einem Windows System zu authentifizieren. Prinzipiell funktioniert Windows Hello auf einem dafür ausgelegten Gerät out-of-the-box. Wird aber das Gerät in einer Domäne (zum Beispiel Windows Server 2012 R2 Active Directory) betrieben, dann muss dort nochmals Hello über GPOs aktiviert werden.

Genau diesen Fall hatte ich kürzlich bei einem Kunden, welcher (nachdem sein Surface Book) in die Domäne aufgenommen wurde, dass Fehlen von Windows Hello bemängelte.

Ausgangssituation

  1. Windows Server 2012R2 (Small Business Essentials) basiertes Active Directory
  2. Windows 10 (1709 Build) Hello fähiges Gerät (Microsoft Surface Book)

Durchgeführte Schritte

Die Planungen für Windows Hello auf der Microsoft Webseite gehen eigentlich von einem Windows Server 2016 basierten Active Directory aus, was ich aber nicht habe und dazu handelt es sich hier um ein reines On-premises Deploment in dem ein Windows Server 2012 Domain Controller ausreicht, ja sogar Windows Server 2008 R2 als Domain und Forrest functional level würde hier noch funktionieren.

image

Damit ist es nicht notwendig die Domain des SBE auf Windows Server 2016 zu bringen und es genügt lediglich die GPOs entsprechend zu aktualisieren.

  1. Download der Gruppenrichtlinien für Windows 10 Build 1709
  2. Update / Einspielen der Gruppenrichtlinien auf dem Domain Controller (Windows Server 2012R2)
  3. Konfiguration der GPO

Die Schritte im Detail

Einspielen der GPOs für Windows 10 Build 1709 (Schritt 2)

Nachdem ich die GPOs heruntergeladen habe, installiere ich diese und kopiere sie mit dem folgenden Befehl in den SysVol Ordner auf dem DC.

Da der DC in englischer Sprache betrieben wird, kommen noch die entsprechenden Pakete hier dazu (2te Zeile).

c:\temp> xcopy "\Program Files (x86)\Microsoft Group Policy\Windows 10 Fall Creators Update (1709)\PolicyDefinitions\*" "%LOGONSERVER%\SysVol\%USERDNSDOMAIN%\Policies\PolicyDefinitions\"

c:\temp> xcopy "\Program Files (x86)\Microsoft Group Policy\Windows 10 Fall Creators Update (1709)\PolicyDefinitions\en-US\*" "%LOGONSERVER%\SysVol\%USERDNSDOMAIN%\Policies\PolicyDefinitions\en-US\"

Damit kennt nun auch der Windows Server 2012R2 die Richtlinien von Windows 10 Build 1709 und wir können Hello konfigurieren.

Konfiguration von Hello über eine GPO (Schritt 3)

Als erstes habe ich eine GPO mit dem Namen “_ Windows Hello for Business“ erstellt und in dieser die folgenden Einstellungen gemacht.

image

Die GPO wurde im Root der Domäne verlinkt. Damit die GPO auch von den PCs gelesen werden kann, habe ich die Domain Computers noch hinzugefügt.

image

Nach dem nächsten GPO refresh hatten alle Geräte die Policy bekommen und ermöglichten die anschließende Konfiguration von Hello (Gesicht oder Finger).

Enjoy it, b!

Moving Hyper-V Replikas

Veröffentlicht am von
Antwort

Seit der Hyper-V Version in Windows Server 2012 R2 lassen sich VMs im laufenden Betrieb auch ohne Failover Cluster verschieben. Das ist ziemlich Klasse und aus Sicht eines Schwaben schon ein Mega-Lob Winking smile Darüber hinaus gibt es noch die Möglichkeit eine Hyper-V Replikation zu erweitern (Extended Hyper-V Replication), also eine replizierte VM nochmals auf einen weiteren Hyper-V Host zu replizieren. Man hat damit also zwei Kopien einer VM.

Will man nun eine dieser Kopien verschieben, muss man auf eine Kleinigkeit aufpassen. Nach dem Verschieben muss nämlich, der Replica-Server angepasst werden. Ich zeige den Ablauf an einem Beispiel, damit klarer wird was ich meine.

Allgemein

Ich benenne meine Hyper-V Replikas immer um, indem ich ein “!” voran stelle. Die erste Replikation bekommt ein ! und die zweite Replikation !!, also:

  1. vm.sbsland.local (aktive VM)
  2. !vm.sbsland.local (erste Replika)
  3. !!vm.sbsland.local (zweite Replika)

Ausgangsituation

Wir haben eine VM (vm.sbsland.local) welche über insgesamt 3 Hosts repliziert wird.

image

Die VM (vm.sbsland.local) läuft auf dem Hyper-V Host 1 (cnoc.whisky.local) und wird von dort auf den Hyper-V Host 2 (nevis.whisky.local) repliziert. Auf diesem Host (nevis.whisky.local) wurde dann wiederum eine erweiterte Replikation (Extended Replication) auf den Hyper-V Host 3 (skye.whisky.local) eingerichtet.

Auf den Hyper-V Hosts sieht das nun wie folgt aus. Neben PowerShell habe ich noch jeweils den Hyper-V Manager / Replikation für die VM dargestellt.

cnoc.whisky.local:image

image

nevis.whisky.local:
image

image

Hier sehen wir neben der ersten (primary) Replikation auch die erweiterte (extended) Replikation.

skye.whisky.local:
image

image

Zielumgebung

Nun wollen wir den Hyper-V Host 2 (nevis.whisky.local) durch einen neuen Hyper-V Host ersetzen (mull.whisky.local). Eine erste Idee wäre natürlich einfach die Hyper-V Replikationen neu ein zu richten, das wollen wir aber nicht! Wir verschieben einfach die erste Replika der VM (!vm.sbsland.local) auf den neuen Hyper-V Host (mull.whisky.local).

image

Wie in der Abbildung zu sehen ist, wird die erste Replika (!vm.sbsland.local) der VM auf den neuen Host verschoben. Das kann über das Hyper-V Management oder aber über den folgenden PowerShell-Befehl erfolgen.

Move-VM -Name !vm.sbsland.local -DestinationHost mull.whisky.local -IncludeStorage -DestinationStoragePath 'd:\replicated virtual machines'

image

Nun haben wir auf dem Hyper-V Host 2 NEU (mull.whisky.local) die VM, aber noch mit dem alten Hyper-V Host 2 (nevis.whisky.local) eingetragenen Replika Server. Nach Ablauf des Intervalls für die Hyper-V Replikation geht diese in den Zustand Warning bzw. Critical.

image

Damit die Replikation wieder in Gang gesetzt werden kann, muss in der Konfiguration der !vm.sbsland.local der alte Hyper-V Host 2 (nevis.whisky.local) gegen den neuen Hyper-V Host (mull.whisky.local) ersetzt werden. Was über das Hyper-V Management oder über den folgenden PowerShell-Befehl erfolgen kann:

Set-VMReplication -VMName vm.sbsland.local -ReplicaServerName mull.whisky.local

Der Befehl muss dazu auf dem Hyper-V Host 1 (cnoc.whisky.local) ausgeführt werden.

image

Danach recht ein Resume-VMReplication um die Replikation wieder in Gang zu setzen.

image

image

So, nun läuft es wieder.

Enjoy it, b!

3Ware/LSI: 9750 / 9261 (ver)wechsel dich …

Veröffentlicht am von
Antwort

Eine tolle Eigenschaft von 3Ware RAID Controllern ist seit Jahren die Tatsache, dass Metadaten des RAIDs auf allen Festplatten gespeichert und unter den Controller Serien aufwärts kompatibel sind. Ich habe unter anderem RAID-Sets von einen 9550 auf einen 9650 und danach auf einen 9750 migriert, immer mit dem folgenden Prozess (Windows):

  1. (Zusätzlicher) Einbau des neuen Controllers in den Server
  2. Start des Betriebssystems und laden des neuen Treibers
  3. Shutdown des Servers
  4. Trennen der Multilane-Kabel vom alten Controller und Ausbau desselben
  5. Umstecken des neuen in den Slot des alten Controllers und aufstecken der Mutlilane-Kabel
  6. Start des Servers und fertig (ggf. entfernen des alten Controllers als verstecktes Gerät aus dem Geräte Manager)

Da ich wieder einen Upgrade, dieses Mal unter Windows Server 2012 durchführen wollte und inzwischen der 9750 direkt mit einem LSI Treiber erkannt wird, habe ich mir die Schritte 1 bis 3 gespart und sofort den Controller eingesteckt und umgebaut. Allerdings erwartete mich in diesem Zug eine grausige Überraschung.

Der Server startet also mit dem neuen Controller neu, und anstatt sich mit 3ware 9750 zu melden sehe ich am Bildschirm die Meldung LSI WebBIOS und dazu die Nummer 9261, und darüber hinaus insgesamt 6 nicht initialisierte Disks. Zuerst traute ich meinen Augen nicht, und suchte sofort den Karton in dem der Controller geliefert wurde: Alles 3Ware 9750, die Anleitungen, die Verpackung und auch die Software. Sogar auf dem Controller war ein kleiner Aufkleber mit der Modellnummer 9750-8i vorhanden. Auch ein erneuter Start des Servers setzte dem Spuk kein Ende – wieder erschien die LSI WebBIOS Meldung und 6 nicht initialisierte Platten.

Gut, dachte ich mir – es sind ja heute zwei 3Ware 9750 Controller gekommen – also schnell den anderen Controller eingebaut: Wieder mit dem gleichen Ergebnis – LSI 9261-8i …

Ein Anruf beim Distributor brachte hier ebenfalls keine Klarheit, aber dessen Support macht sich auf die Suche und fand noch mehrere “falsche” 3Ware 9750 Controller mit LSI 9261 BIOS. Der Umtausch war kein Problem, aber der RAID war nicht mehr initialisierbar – obwohl ich im LSI WebBIOS keine Aktionen durchgeführt hatte. Die Daten konnten lediglich wieder per Datensicherung hergestellt werden….

Einige Recherche im Internet hat zu Tage gefördert das wohl der 3Ware 9750 und der LSI 9261 auf dem gleichen Chip (LSISAS2108 RoC) von LSI basieren und entsprechend Rebranded werden, also auch noch von Intel, Dell oder IBM angeboten sind … leider mit nicht untereinander kompatibler Logik der Metadaten, was eine weitere Verwendung des RAIDs verhindert!

Hier noch ein paar Links:

Deswegen gilt wie immer – save early, save often ..

Enjoy it, b!