VMware WorkspaceOne Boxer – Mails als Privat markieren (wie in Outlook)

Über die Boxer App lassen sich bequem Nachrichten bequem per S/MIME verschlüsseln oder aber auch entsprechend Klassifizieren.
Was mir im Standard gefehlt hat, war dass man Nachrichten nicht wie in Outlook einfach als „Privat“ markieren kann. Da gibt es erstmal nur die Klassifikation der Wichtigkeit „Hoch“.  In den Assignment Einstellungen im WS1 Portal lässt sich aber auch das Klassifizieren von Nachrichten konfigurieren.

Ich beschreibe hier in kürze, wie ihr die Privat Markierung (für Outlook) nachbauen könnt.

Wie funktioniert in Outlook das „Privat“ markieren?

Um zu verstehen wie Outlook die Privat markierung überhaupt feststellt schauen wir uns den E-Mail Header an:


Date: Thu, 4 Aug 2022 16:48:03 +0200
From: Constantin Lotz &lt;<a href="mailto:Constantin.Lotz@xxxxx">Constantin.Lotz@xxxxx</a>&gt;
To: Constantin Lotz &lt;<a href="mailto:Constantin.Lotz@xxxx">Constantin.Lotz@xxxx</a>&gt;
Message-ID: &lt;4DB995C8-1CD9-4B85-BCB5-2C11388F602F@xxxxx&gt;
Subject: Privat iPhone (Privat)
X-Mailer: VMwareBoxer 22.07.0 DEV BUILD 9139
Sensitivity: private
X-Boxer-MessageId: 4DB995C8-1CD9-4B85-BCB5-2C11388F602F@xxxx
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="62ebdc23_327b23c6_1e3"

Hier seht ihr, dass der Header einen Wert „Sensitivity: private“ enthält. Dies ist das entscheidende Header Element.

In Outlook sieht dass dann so aus:

 

Wie bekommen wir dies nun in WorkspaceOne Boxer konfiguriert?

Beim Zuweisen der Boxer App (für iOS und Android identisch – muss aber separat eingerichtet werden) könnt ihr in den Email Settings die „Email Classification“ auswählen.

Hier besteht die Möglichkeit die Azure Information Protection Labels zu verwenden, was aber nur bei Nutzung von O365 Sinn macht (korrigiert mich, wenn ich da falsch liege).

Wir aktivieren die Email Classification und setzen bei Markings folgenden JSON String ein:


[
{
"Rank": 1,
"DisplayName": "Privat",
"Description": "Diese E-Mail als Privat markieren.",
"Subject": "(Privat)",
"TopBody": "Klassifikation: Privat",
"BottomBody": "Klassifikation: Privat",
"XHeader": "private"
},
{
"Rank": 2,
"DisplayName": "Vertraulich",
"Description": "Diese E-Mail bitte vertraulich behandeln.",
"Subject": "(Vertraulich)",
"TopBody": "Klassifikation: Vertraulich",
"BottomBody": "Klassifikation: Vertraulich",
"XHeader": "Confidential"
}
]

Hier könnt ihr nach belieben eigene Klassifikationen hinzufügen. Wichtig für die Outlook „Privat“ Markierung ist allerdings der Header. Dieser muss auf private stehen. („XHeader“: „private“)
Über „Define x-header“ geben wir an, wie der Header Wert aussehen soll. Dies muss „Sensitivity“ sein, wie ihr gleich sehen werdet.

Anschließend die Konfiguration speichern. Auf dem Mobilgerät müsst ihr die Boxer App einmal de-, und wieder installieren. Das ist der sauberste Weg, bis die Einstellung greift.

Mail in Boxer App nun als Privat kennzeichnen

In der Boxer App habt ihr beim Schreiben einer neuen Nachricht anschließend ein kleines Schild in der unteren Leiste über die ihr die Klassifikation vornehmen könnt.

Leider sieht man bei eingehenden Nachrichten nach wie vor nicht, ob die Mail als Privat markiert ist oder nicht. Allerdings: Wenn Sie Privat markiert ist, sieht man es zwar nicht – beim Antworten bleibt die E-Mail aber Privat. Also die Klassifikation wird dann nicht entfernt.

VMware UAG – SEG Configuration Issues (ERR05_INVALID_SEG_HOST_NAME)

Hi there,

i’ve noticed a bug in the UEG 2106.1 when you have specified a wrong SEG Hostname in the first place.

After catching some logs you will see the following error in the installer-script.log of the Archive:


2021-08-23 16:33:03 uag.domain.de Installer jar exited with status 0 for action LOAD_CONFIG_FROM_API
2021-08-23 16:33:03 uag.domain.de Validating SEG SSL configuration.
2021-08-23 16:33:04 uag.domain.de SSL keystore is supplied from API.
2021-08-23 16:33:04 uag.domain.de SEG SSL configuration verified successfully. SEG in UAG is configured with SSL enabled.
2021-08-23 16:33:04 uag.domain.de Kerberos authentication is enabled for this MEM configuration.
2021-08-23 16:33:04 uag.domain.de The file '/opt/vmware/seg/config/seg-jvm-args.conf' exists, Value for property '-Dextract.executable.from.jar' is ''.
2021-08-23 16:33:04 uag.domain.de Validating SEG server hostname from API response against SNI configured hostname
2021-08-23 16:33:04 uag.domain.de The file '/opt/vmware/seg/config/restart-validation.properties' exists, Value for property 'airwatch.server.hostname' is 'cn1108.awmdm.com'.
2021-08-23 16:33:04 uag.domain.de The file '/opt/vmware/seg/config/restart-validation.properties' exists, Value for property 'enable.status.overwrite' is 'false'.
2021-08-23 16:33:04 uag.domain.de Overwriting status file is disabled. Error code: ERR05_INVALID_SEG_HOST_NAME, Error message: The SNI hostname 'cn1108.awmdm.com' does not match with that received from API 'mdm03.domain.de'
2021-08-23 16:33:04 uag.domain.de Running clean up..
2021-08-23 16:33:04 uag.domain.de Exiting the container with FAILED status

So I’ve messed up writing the wrong SEG Host Name, but the wizard is keeping the config file and does not overwrite the hostname with any further names.

How to fix ?

That’s an easy one: Just rename the mentioned restart-validation.properties file and resave the Secure Email Gateway Settings. The docker build process will then recreate the container with the correct settings as entered.


mv /opt/vmware/docker/seg/container/config/restart-validation.properties /opt/vmware/docker/seg/container/config/restart-validation.properties.old

 

Azure Stack HCI – Performance Benchmark 6 Node Dell AX-740XD Cluster

Einleitung

Hyperkonvergente Systeme sind immer weiter im Trend und erobern auch die deutschen Rechenzentren. Eher neu ist die HCI Lösung von Microsoft: Azure Stack HCI, die (erst) seit Ende Dezember 2020 auf dem Markt ist. Hierbei handelt es sich um ein eigenes Betriebssystem (auf Basis von Server 2019) welches rein für die Hyper-V Dienste ausgelegt ist und sich funktional von den klassischen Windows-Server Varianten in Zukunft auf die Virtualisierung abheben soll. So gibt es Azure Stack HCI nur als Core-Installation (also ohne GUI) – die Bedienung soll per Windows Admin Center oder rein per Powershell erfolgen. Neu ist auch das Lizenzierungsmodell, wo Microsoft auf eine Gebühr von 10€/Monat pro CPU Kern veranschlagt. Hier möchte man anscheinend ähnlich der Konkurrenz auch am Hypervisor verdienen.

Da die Software relativ neu ist, findet man aktuell leider relativ schwer Benchmarks oder Performancedaten von Systemaufbauten, die nicht rein für Marketingzwecke ausgerichtet sind. Daher habe ich mich entschieden hier einige Ergebnisse als Orientierung zu präsentieren. Getestet wird ein für Azure Stack HCI zertifiziertes System von Dell in Form von AX-740XD Systemen, die nach Best-Practise konfiguriert wurden. Das Betriebssystem der Server war die zum Zeitpunkt aktuellste Azure Stack HCI Version. (Patchstand Mai 2021).

Hardwareaufbau

Als Aufbau dienen 6 Dell AX-740XD Server mit folgender SSD/Fullflash Konfiguration:
Für das OS werden die BOSS Karten verwendet. Als Cache Karten werden je 2 x NVME verwendet. Für den Kapazitäts-Tier werden je 6 x SSD verwendet.

MediaType BusType Usage Model FriendlyName Kapazität Anzahl Insgesamt Anzahl  pro Server
SSD SATA Boot-Drive SSDSCKKB240G8R DELLBOSS VD 223.57 GB 12 2
SSD SAS Auto-Select (Capacity) KPM5XRUG3T84 TOSHIBA KPM5XRUG3T84 3.49 TB 36 6
SSD PCIe Journal (Cache) Dell Express Flash NVMe P4610 1.6TB SFF Dell Express Flash NVMe P4610 1.6TB SFF 1.46 TB 12 2

Herstellerangaben und theoretische max-Werte

Da es kaum Vergleichswerte bei solchen Systemen gibt, ziehen wir als Vergleich die Herstellerangaben heran. So haben wir zumindest einen Richtwert, der uns hilft das System zu validieren. Um nähere Spezifikationen zu den möglichen Schreib/Lesewerten und IOPS zu bekommen, müssen wir uns nun die Modelle etwas genauer anschauen. Die 3,49 TB SSD ist zwar laut Beschreibung von TOSHIBA – hinter dem Namen versteckt sich aber der Hersteller Kioxia und genau folgendes Modell: PM5-R Series. Auf der Herstellerseite finden wir dann auch Angaben zu den theoretischen Werten:

Technische Daten vom Hersteller
Man beachte, dass die Herstellerangaben unter Verwendung von Dual Port 12GB SAS gemessen wurde, was in unserem S2D/Azure Stack HCI Konstrukt nicht der Fall ist und die SSD „lediglich“ über einen SAS Port angeschlossen ist. Daher sind unsere Ergebnisse in der Praxis etwas geringer. Als einzelne SSD eingebunden und Formatiert mit 64k ReFS haben wir mit CrystalDiskMark für die KPM5XRUG3T84 folgende Werte erhalten:

Crystaldisk Benchmark SSD Crystaldisk Benchmark SSD

Für die P4610 von Dell finden wir direkt bei Dell in einem DataSheet die vergleichbaren Daten:

Technische Daten Dell NVME

Netzwerk

Netzwerkseitig sind die Systeme mit 4 x 25GB über 2 Dual Port „Mellanox ConnectX-4 Lx 25GbE SFP28“ Karten mit je einem DELL SF5212F verbunden.
Als Technologie für die Storagereplikation verwenden wir RDMA.

Storageübersicht

Windows Admin Center Storagepool

In Summe haben wir einen Storagepool den wir auf 6 Volumes (1 pro Host) aufteilen. Für alle Volumes verwenden wir einen Three-Way-Mirror, für maximale Performance.

Windows Admin Center Volumes

Testmöglichkeiten

Es gibt 2 verschiedene Testmöglichkeiten um den Cluster auf Herz und Iops zu testen.

VMFleet war früher das gängige Tool und es gibt dazu auch gute Beschreibungen wie von DataOn. Es ist etwas umständlich zu konfigurieren, aber hat es mehrere VM’s erzeugt und in diesen dann diskspd ausgeführt. Dies wäre meiner Ansicht nach zumindest ein Test wo der Realität am nächsten kommt. Laut Microsoft (Azure Stack HCI Support) ist VMFleet allerdings nicht mehr supported was Benchmarks angeht.

Präferierte Variante: StartWorkload.ps1
Hier muss lediglich DiskSpd heruntergeladen werden und keinerlei extra VM’s erzeugt werden. Das Tool verschiebt die ClusterStorage’s und verteilt diese auf die Hosts und startet dann DiskSpd auf jedem Host für sein Cluster-Volume.

Zu Beginn müssen wir erstmal 3 benötigte Tools herunterladen:

watch-cluster.ps1
start-workload.ps1
diskspd.exe

Alle Tools packen wir in einen Ordner, diskspd muss zuvor noch entpackt werden.

Watch-Cluster

In einem Powershellfenster auf dem Host starten wir Watch-Cluster, welches uns die Storagewerte live liefert. Das Tool ist deutlich genauer als z.B. das Windows Admin Center.
Um alle Daten in einem Fenster angezeigt zu bekommen muss man in der Regel die Schriftgröße des Powershellfensters auf 10 oder 11 herabsetzen 🙂

 .\watch-cluster.ps1 -sets *

Start-Workload

Mit Start-Workload können wir nun verschiedene Szenarien durchprobieren. Wenn man diese aufzeichnen möchte, lohnt sich ggf. auch die Aufnahme der Performancecounter .

4K 100% Read with minimal Latency to identify if we have a latency issue

.\Start-Workload.ps1 -DiskSpdpath "C:\Temp\Diskspd.exe"

BenchmarkBenchmark  Benchmark

4K 100% Read (Maximize IOPS), we don’t care too much about Latency:

.\Start-Workload.ps1 -DiskSpdpath "C:\Temp\DiskSpd" -o 32

BenchmarkBenchmark

4K 100% Write  – Expect to have much less IOPS then 100% Read

Die Daten werden bei einem Three-Way-Mirror noch auf 3 weiteren Fault Domains geschrieben, nicht zu vergessen…

.\Start-Workload.ps1 -DiskSpdpath "C:\Temp\DiskSpd" -w 100

BenchmarkBenchmarkBenchmark

128K 100% Read –  Maximize Throughput on Reads

Nun testen wir mit der Blockgröße von 128K und einer Queuetiefe von 32 (Outstanding IO’s). Hier haben wir dann zwar nicht unbedingt viele IO’s jedoch einen sehr hohen Durchsatz.

.\Start-Workload.ps1 -DiskSpdpath "C:\Temp\DiskSpd" -B 128K -o 32

BenchmarkBenchmark Benchmark Benchmark Benchmark

128K 100% Write-  Maximize Throughput on Writes

Gleiches Spiel nur schreibend.

.\Start-Workload.ps1 -DiskSpdpath "C:\Temp\DiskSpd" -B 128K -o 32 -w 100

BenchmarkBenchmark  Benchmark Benchmark Benchmark

Netzwerkauslastung

Kombinierte Auslastung aller 25GbE Ports der beiden Switches (pro Switch):

Benchmark Benchmark

In Summe kommen wir beim Lesen (4k) auf ungefähr 234 Gbit/s über alle Ports gerechnet. Das wären pro Server 39 Gbit/s die dann auf die 4 Karten verteilt werden.

Die Switche & Netzwerkkarten haben wir in Tests nur durch Livemigrationen höher ausgelastet bekommen. Ein guter Test ist eine Blanko VM mit 80% der maximal verfügbaren Ram-Menge des Hosts auszustatten (z.B. 500GB) und dann per Livemigration auf einen anderen Host zu migrieren. Das funktioniert per RDMA ziemlich gut und flott – speziell wenn die SMB Limits korrekt richtig gesetzt sind. In unserem Fall haben sich so VM’s mit 500 GB Arbeitsspeicher in wenigen Sekunden per Livemigration auf einen anderen Host migrieren lassen, was die Netzwerkkarten an ihr Limit bringt 😉

Auffälligkeiten

Bei kleinen Blockgrößen (4K) haben wir es immer geschafft die CPU’s der Hosts auf Vollast (80-100%) zu fahren, was bei 2 Sockel Xeon(R) Gold 6248R Systemen schon ganz ordentlich ist. Die CPU ist in diesem Fall der Flaschenhals – zumal noch kein anderer Workloud (VM’s) auf dem Cluster läuft. Im Realbetrieb ist hier natürlich eine etwas geringere Leistung zu erwarten. Bei den großen 128K Blöcken war die CPU nur zu ca. 20% ausgelastet. Hier haben wir gesehen, dass die SSD’s dann auch an ihre Grenzen gekommen, was sich auch gut an den höheren Latenzen auf SSD Ebene bestätigt hat.

Powershell – Die zugrunde liegende Verbindung wurde geschlossen: Unerwarteter Fehler beim Senden…

Beim Abfragen von Webservices über Powershell kommt es immer wieder mal zu folgender Fehlermeldung:

PS N:\> Invoke-Webrequest -Uri https://tls-v1-2.badssl.com:1012/
Invoke-Webrequest : Die zugrunde liegende Verbindung wurde geschlossen: Unerwarteter Fehler beim Senden..
In Zeile:1 Zeichen:1
+ Invoke-Webrequest -Uri https://tls-v1-2.badssl.com:1012/
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebExc
eption
+ FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

So wirklich schlau wird man aus der Meldung „Die zugrunde liegende Verbindung wurde geschlossen: Unerwarteter Fehler beim Senden..“ jetzt auf den ersten Blick nicht. (In Englisch: The underlying connection was closed: An unexpected error occurred on a send..)
Der Fehler tritt bei Problemen mit der TLS Verschlüsselung auf. Speziell wenn der Client (also die Powershell in diesem Fall) mit einer nicht unterstützten TLS Version beim Server ankommt.
Bei Windows Server 2016, 2012R2 oder älteren Windows Client Betriebssystemen ist die Standard Verschlüsselung TLS 1.1/1.0 welche von vielen Betreibern von Websites mittlerweile wegen der Sicherheit deaktiviert wurde.
Bein Windows Server 2019 und Windows 10 (1909) hatte ich bei Tests mit dem Powershell Invoke-Webrequest standardmäßig TLS 1.2 vorgefunden.

Wie kann man per Powershell die TLS Verschlüsselung ändern?

Über folgende Befehle vor dem Invoke-Webrequest bzw. Invoke-RestMethod kann die TLS Version gesteuert werden.

TLS 1.2

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

TLS 1.1

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls11

TLS 1 ( 1.0 )

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls

Beispiel

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
$a = Invoke-Webrequest -Uri https://tls-v1-2.badssl.com:1012/

Dies kann man über folgende URL’s auch direkt testen (Quelle: Stackexchange.com):

This subdomain and port only supports TLSv1.2

https://tls-v1-2.badssl.com:1012/

This subdomain and port only supports TLSv1.1

https://tls-v1-1.badssl.com:1011/

This subdomain and port only supports TLSv1.0

https://tls-v1-0.badssl.com:1010/

Nützliche Links

IISCrypto

Mit dem kostenfreien Tool IISCrypto lässt sich speziell der IIS aber auch die Grundlegenden Systemstandards und TLS Protokolle definieren.

Cipherlist

Unter Cipherlist bekommt man jeweils immer die aktuellen SSL Einstellungen für viele Webserver, wie apache2, nginx, oder auch andere Dienste.

Ähnliche Fehlermeldungen

Auch bei der PowerShell Gallery muss man mittlerweile TLS 1.2 einsetzen. Ansonsten bekommt ihr folgende Fehlermeldung:

Install-Module -Name SqlServer
WARNUNG: Unable to resolve package source 'https://www.powershellgallery.com/api/v2'.
PackageManagement\Install-Package : Für die angegebenen Suchkriterien und den Paketnamen "SqlServer" wurde keine
Übereinstimmung gefunden. Verwenden Sie Get-PSRepository, um alle verfügbaren, registrierten Paketquellen anzuzeigen.
In C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\1.0.0.1\PSModule.psm1:1772 Zeichen:21
+ ... $null = PackageManagement\Install-Package @PSBoundParameters
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (Microsoft.Power....InstallPackage:InstallPackage) [Install-Package], Ex
ception
+ FullyQualifiedErrorId : NoMatchFoundForCriteria,Microsoft.PowerShell.PackageManagement.Cmdlets.InstallPackage

Philips Fernseher – Ins Service Menü gelangen (55PUS6401/12)

Wer das Service Menü der Philips sucht, kann folgende Tastenkombinationen über die Fernbedienung ausprobieren:

0 + 6 + 2 + 5 + 9 + 6 + Menu/Info/Status
0 + 6 + 2 + 5 + 9 + 7 + Menu/Info/Status
0 + 6 + 1 + 5 + 9 + 6 + Menu
0 + 6 + 1 + 5 + 9 + 7 + Menu
1 + 6 + 2 + 5 + 9 + 6 + Menu/Status
1 + 2 + 3 + 6 + 5 + 4

Die Menüeinträge können mit CURSOR HOCH/RUNTER angesprochen werden. Die Einträge selbst mit CURSOR LINKS/Rechts verändert werden.
Manche Einstellungen können aktiviert und deaktiviert werden, dazu die OK Taste drücken.
Achtung: Nur anfassen, wenn man weiß was man macht! Falsche Einstellungen können das Gerät beschädigen!

Linux – Recursiv Dateien in Unterordnern entpacken und löschen

Entpacken von allen Archiven in ihren eigenen Unterordnern:

find /pfad/Ordner -name '*.rar' -execdir unrar e -o- {} \;

Aufklärung der Parameter für unrar:
e = extract (alternativ x = behält die Verzeichnisstruktur)
-o- = Kein überschreiben von Dateien, wenn diese schon existieren.
Anschließend löschen wir alle Dateien die dem Winrar Dateimuster (.rar; .r01; usw…) entsprechen:

find . -type f -name "*.r??" -exec rm {} \;

Dell Inspiron 3480 – Under the hood

Da die Spezifikationen des Dell Inspiron 3480 nicht 100%ig wiederspiegeln, welche Anschlüsse auf dem Mainboard noch frei sind, habe ich mir erlaubt ein paar Screenshots des aufgeschraubten Gerätes zu zeigen.

Wie man sieht gibt es
1 x M.2 Anschluss
1 x 2,5 HDD Sata Anschluss
sowie
2 x SODIMM Bänke für DDR 4 Speicher

den Akku sowie die Mainboard Batterie lassen sich noch eigenständig tauschen und sind zum Glück nicht verklebt.

Schrauben für den Einbau einer 2,5 Zoll Festplatte liegen sogar am Klebeband befestigt bei.

FATA: Module wireguard not found – Kernel modul fixen

Ich spare mir die Erläuterung was wireguard ist und macht, das gibt es denke ich zur genüge.

Was man wissen sollte ist: Wireguard ist nicht direkt im Linux Kernel enthalten, und basiert auf einer Erweiterung (Modul) dazu.
Das bedeutet, wenn man Wireguard installiert und anschließend Updates des Kernel macht, kann es sein das Wireguard nicht mehr funktioniert. Dann muss nämlich das Kernel-Modul neu (für die neue Kernel Version) kompiliert werden.

Beim Installieren unter Debian 9 kam ich auf folgende Meldung:

Vorbereitung zum Entpacken von .../12-wireguard_0.0.20190905-1_all.deb ...
Entpacken von wireguard (0.0.20190905-1) ...
make (4.1-9.1) wird eingerichtet ...
sudo (1.8.19p1-2.1) wird eingerichtet ...
linux-headers-4.9.0-11-common (4.9.189-3) wird eingerichtet ...
wireguard-tools (0.0.20190905-1) wird eingerichtet ...
linux-compiler-gcc-6-x86 (4.9.189-3) wird eingerichtet ...
dkms (2.3-2) wird eingerichtet ...
linux-kbuild-4.9 (4.9.189-3) wird eingerichtet ...
Trigger für libc-bin (2.24-11+deb9u4) werden verarbeitet ...
libfakeroot:amd64 (1.21-3.1) wird eingerichtet ...
Trigger für systemd (232-25+deb9u11) werden verarbeitet ...
wireguard-dkms (0.0.20190905-1) wird eingerichtet ...
Loading new wireguard-0.0.20190905 DKMS files...
Building for 4.9.0-4-amd64
Module build for kernel 4.9.0-4-amd64 was skipped since the
kernel headers for this kernel does not seem to be installed.
linux-headers-4.9.0-11-amd64 (4.9.189-3) wird eingerichtet ...
fakeroot (1.21-3.1) wird eingerichtet ...
update-alternatives: /usr/bin/fakeroot-sysv wird verwendet, um /usr/bin/fakeroot (fakeroot) im automatischen Modus bereitzustellen
wireguard (0.0.20190905-1) wird eingerichtet ...
Module build for kernel 4.9.0-4-amd64 was skipped since the
kernel headers for this kernel does not seem to be installed.

  Ein Reconfigure des Modules brachte auch keine Besserung:

# dpkg-reconfigure wireguard-dkms
-------- Uninstall Beginning --------
Module: wireguard
Version: 0.0.20190905
Kernel: 4.9.0-11-amd64 (x86_64)
-------------------------------------
Status: Before uninstall, this module version was ACTIVE on this kernel.
wireguard.ko:
- Uninstallation
- Deleting from: /lib/modules/4.9.0-11-amd64/updates/dkms/
- Original module
- No original module was found for this module on this kernel.
- Use the dkms install command to reinstall any previous module version.
depmod.....
DKMS: uninstall completed.
------------------------------
Deleting module version: 0.0.20190905
completely from the DKMS tree.
------------------------------
Done.
Loading new wireguard-0.0.20190905 DKMS files...
Building for 4.9.0-4-amd64
Module build for kernel 4.9.0-4-amd64 was skipped since the
kernel headers for this kernel does not seem to be installed.

  Testen ob das Wireguard Module geladen ist:

modprobe wireguard
modprobe: FATAL: Module wireguard not found in directory /lib/modules/4.9.0-4-amd64

 Ursache: Die notwendigen Pakete zum Kompilieren waren nicht vorhanden.

Lösung: Fehlenden Pakete installieren und ein Reconfigure des wireguard-modules machen.

apt-get install libmnl-dev libelf-dev linux-headers-$(uname -r) build-essential pkg-config
# dpkg-reconfigure wireguard-dkms
------------------------------
Deleting module version: 0.0.20190905
completely from the DKMS tree.
------------------------------
Done.
Loading new wireguard-0.0.20190905 DKMS files...
Building for 4.9.0-11-amd64
Building initial module for 4.9.0-11-amd64

 

Freenas 11 – Fix "Boot failed efi misc device"

In einer frisch angelegten Ubuntu 16.04.4 VM unter der bhyve Virtualisierungsplattform in Freenas hatte ich das Problem, dass die VM nicht korrekt unter UEFI bootete.
Bei jedem Neustart hing die Maschine im EFI und zeigte: „boot failed efi misc device“ an. Wie sich im Freenas Forum herausstellte, ist man nicht der einzige mit dem Problem.
Im Efi selbst kann man dann zwar via „exit“ in in den „Boot Maintenance Manager“ gelangen und unter „Boot File“ auch die grubx64.efi zum Starten auswählen. Allerdings ist das Prozedere beim nächsten Neustart wieder notwendig.
Was ist die Ursache?
Warum auch immer wird der Bootloader unter folgendem Pfad vermutet:

 root@ubuntu:/boot/efi# ls /boot/efi/EFI/BOOT/bootx64.efi
/boot/efi/EFI/BOOT/bootx64.efi

Dies war bei mir nicht der Fall, also musste ich den BOOT Ordner anlegen und kopierte die grubx64.efi als bootx64.efi in das Verzeichnis, sodass es wie folgt aussieht:

mkdir /boot/efi/EFI/BOOT
cp /boot/efi/ubuntu/grubx64.efi /boot/efi/EFI/BOOT/bootx64.efi
root@ubuntu:/boot/efi# tree -L 3 .
.
└── EFI
├── BOOT
│   └── bootx64.efi
└── ubuntu
├── grub.cfg
├── grubx64.efi
├── mmx64.efi
└── shimx64.efi
3 directories, 5 files

Anschließend die VM neustarten um zu prüfen ob alles korrekt funktioniert hat.

HAProxy vor Squid Proxy – Client IP-Adressen weiterleiten

Verwendet man einen Loadbalancer wie z.B. HAProxy um Webzugriffe von Clients auf mehrere Squid Proxy Server zu verteilen, sieht es im access.log des Squid Proxy so aus, als kämen die Zugriffe alle vom HAProxy nicht vom eigentlichen Client. Da das HTTP Forwarding des HAProxy auf Applikationsebene basiert, ist dieses Verhalten korrekt. Wenn man TCP Offloading machen würde, wäre dies wahrscheinlich nicht der Fall.

Um beim HTTP Forwarding dennoch die originale Client-IP im Squid access.log zu sehen, kann man diese über den HTTP Header X-Forwarded-For (Beschreibung) weiterleiten.

In Squid kommen die Requests alle von der IP-Adresse des HAProxy:

1514450659.711  40186 10.0.0.5 TCP_MISS/200 31540 CONNECT images.outbrain.com:443 - HIER_DIRECT/2.19.240.34 -
1514450660.977  40078 10.0.0.5 TCP_MISS/200 3753 CONNECT www.summerhamster.com:443 - HIER_DIRECT/52.27.8.169 -

In HAProxy müssen die folgenden beiden Optionen gesetzt werden. Diese setzen den Header „X-Forwarded-For“ auf die Client IP-Adresse. Dadurch wird die eigentliche Client IP im Header mitgegeben:

option http-server-close
option forwardfor

Der Squid Proxy registriert den veränderten Header, verwirft ihn aber aus Sicherheitsgründen standardmäßig – sofern nicht anderweitig konfiguriert. Also muss in der Konfiguration des Squid der QuellIP des HAProxy vertraut werden. Dies wird dementsprechend über eine acl in der squid.conf angepasst:

acl haproxy src 10.0.0.5
follow_x_forwarded_for allow haproxy

Abschließend den Squid neustarten und den Webzugriff über ein Client testen. Wie man nun im access.log sieht, ist die Client-IP jetzt korrekt weitergeleitet.

1514451557.721      5 10.0.0.10 TCP_MISS/200 910 POST http://ocsp.digicert.com/ - HIER_DIRECT/93.184.220.29 application/ocsp-response
1514451557.749      5 10.0.0.10 TCP_MISS/200 2194 POST http://ocsp2.globalsign.com/gsalphasha2g2 - HIER_DIRECT/104.31.74.124 application/ocsp-response