Da ich ständig vergesse, wie man auf einem VMware standard vSwitch CDP bzw. LLDP konfiguriert um Uplinks von/zu physischen Switches schnell und einfach nachvollziehen zu können:
Per SSH auf den ESXi verbinden und folgenden esxcli Befehl ausführen:
esxcli network vswitch standard set --cdp-status=both -v vSwitch0
--cdp-status=both konfiguriert den vSwitch sowohl für’s empfangen, als auch senden von CDP/LLDP Paketen.
Mit dem Parameter -v <vSwitch> wird der Name des zu konfigurierenden vSwitch angegeben.
Alternativ geht das auch per esxcfg:
esxcfg-vswitch -B both vSwitch0
Das war schon alles, nun kann man ganz einfach auf den physischen Switches die CDP/LLDP Infos abrufen.
Z.B. auf HPE (Aruba) Switches:
show cdp neighbors
show lldp info remote-device
Häufig liest man online, dass es nicht möglich ist (oder zumindest nicht supported) auf standard vSwitches CDP/LLDP zu aktivieren. Über den vSphere Client oder den ESXi Host client geht das auch (soweit ich weiß) tatsächlich nicht. Dort heißt es dann bei den vmnics auch „CDP/LLDP steht auf diesem physischen Netzwerkadapter nicht zur Verfügung.“
Im Linux Kernel sind seit 2.6.3irgendwas drei verschiedene I/O Scheduler enthalten. Der Klassiker NOOP, Deadline und der „moderne“ CFQ. So ein I/O Scheduler besitzt immer einen eigenen Algorithmus, um Lese- und Schreibrequests zu verarbeiten und an das Device für die physische Abarbeitung zu übergeben.
Mit „cat /sys/block/sda/queue/scheduler“ lässt sich der aktuelle Scheduler anzeigen
NOOP
Der NOOP-Scheduler ist ein vergleichsweise einfaches Ablaufmodell, das einfach alle I/O Requests in einer einzigen FIFO-Queue verwaltet und weitergibt. Es gibt in dieser Queue Request Merging, um und Seek-Times zu vermeiden, aber z.B. eine Sortierung findet nicht statt.
Deadline
Der Deadline-Scheduler ist gebaut um die „Starvation“ von Requests zu verhindern, also App-Timeouts durch *_WAIT zu vermeiden. Dazu werden in einer komplizierten Struktur Request mit einer Expiration Time versehen und in verschiedene Queues abgearbeitet. Dabei wird versucht, die Antwortzeiten für jeden Eintrag einzuhalten.
CFQ
Der „Completely fair queuing“ Scheduler ist zugleich der komplexeste, mächtigste und Standard-Scheduler des Kernels. Der Algorithmus versucht eine faire Aufteilung der vorhandenen I/Os auf alle Prozesse gleicher Priorität. Die „Fairness“ bezieht sich dabei auf die zeitliche Länge der Time-Slots und nicht auf die verwendete Bandbreite. Sequentielle Anfragen werden im gleichen Slot als immer eine höheren Durchsatz erzielen als ein Prozess mit random-Writes (welche durch Seek-times verlangsamt wird).
Dafür hat CFQ als einziger Scheduler die Möglichkeit, Prozesse in Prioritätsklassen einzuteilen. Von RT (RealTime) bis I (Idle) sind verschiedene abstufingen möglich.
Welchen nehme ich?
Wie immer in der IT gibt es hierauf keine eindeutige Antwort. In aller Regel ist der von der jeweligen Distribution ausgelieferte (und getestete) Modus eine gute Wahl.
In speziellen Szenarien, wie zum Beispiel extrem hoher random I/O Last bei vielen CPU-Kernen, kann die Umstellung auf einen anderen Scheduler aber etwas mehr Durchsatz (meint: mehr I/Ops) bewirken.
Wir empfehlen oft den Deadline Scheduler für Storages mit vielen SSDs, weil dieser nicht so viel Rechenzeit für das Mergen benötigt. SSDs sind oft schneller mit der Antwort fertig, als viele hunderte Merge-Operationen brauchen um abgesetzt zu werden. Noch schneller wäre NOOP, aber da ist die Gefahr groß, das ein Prozess mit exessiver I/O Nutzung alls anderen Operationen blockiert.
Die Änderung ist sofort aktiv, aber nicht persistent. Um die Umstellung über den nächsten Reboot zu retten, muss man dem Kernel den Startparameter elevator= mitgeben.
Unter Debian (beispielweise) passiert das in der /etc/default/grub in der Zeile
Windows Updates nach dem 10.8.2021 erfordern standardmäßig Administratorrechte, um Druckertreiber installieren oder aktualisieren zu können. Bisher konnten Benutzer ohne Administratorrechte:
Neue Netzwerkdrucker mithilfe von Treibern auf einem Printserver installieren
Aktualisieren vorhandener Druckertreiber mit Treibern vom Printserver
Das geht jetzt nicht mehr. Stattdessen kommt die gute alte Vertrauensfrage und der Admin muss seine Credentials eingeben. Das ist auch unabhängig von den Einstellungen in der GPO.
Lösung
Ein Registry-Eintrag stellt das „alte“ Verhalten wieder her. Leider einschließlich der Sicherheitslücke bei der Installation von Druckertreiber, die es einem Hacker erlaubt weitere DLL-Dateien an einen Druckertreiber anzuhängen.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Printers\PointAndPrint]
"RestrictDriverInstallationToAdministrators"=dword:00000000
Aus uns nicht erfindlichen Gründen kann man im vSphere Client den Konfigurationseintrag Syslog.global.logdir nicht ohne Fehlermeldung ändern. Wenn man das versucht erhält man die spannende Fehlermeldung „Ein allgemeiner Systemfehler ist aufgetreten: Internal error“
Man erreicht den Eintrag im vSphere Client auf dem Host > Konfigurieren > System/Erweiterte Systemeinstellungen > Bearbeiten
Lösung
Man kann den Eintrag problemlos an der Console via esxcli setzen. Das geht sowohl via SSH als auch remote. Das „neue“ Verzeichnis muss auch schon existieren, sonst beschwert sich esxcli.
mkdir /vmfs/volumes/<NEUESVOLUME>/logs
esxcli system syslog config set --logdir=/vmfs/volumes/<NEUESVOLUME>/logs
Nach der Änderung muss Syslogd neu geladen werden. Das tut das GUI eigentlich automatisch, aber an der Konsole müssen wir etwas nachhelfen:
Microsoft hat zu Beginn des Jahres die Auswahl „niemals“ aus der Gültig-Bis Auswahl für geheime Clientschlüssel bei neuen AzureAD Apps entfernt. Hier ist im Azure WebGUI die Auswahl seither nur noch bis „2 Jahre“ möglich.
Die Auswahl ist auf bis zu 24 Monate eingeschränk
Die Limitierung beschränkt sich aber auf das GUI, die PowerShell kann weiterhin geheime Clientschlüssel erstellen, die deutlich länger gültig sind.
Lösung
Sofern die App selbst schon im WebGUI erstellt ist (Neue Registrierung > Name, URL > Registrieren) lässt sich für diese App schnell ein Secret erstellen.
AzureAD Anwendung geheimen Clientschlüssel via PowerShell hinzufügen, mit deutlich längerer Laufzeit
# Mit AAD Verbinden
Connect-AzureAD
# Apps auflisten, passende ObjectId kopieren
Get-AzureADApplication
# "Gültig von" und "bis" holen
$startDate = Get-Date
$endDate = $startDate.AddYears(99)
# Secret erstellen lassen
$aadAppsecret01 = New-AzureADApplicationPasswordCredential -ObjectId <ID> -StartDate $startDate -EndDate $endDate -CustomKeyIdentifier <ANZEIGENAME-DES-SECRETS>
# Secret anzeigen (um es zu kopieren und sicher zu verwahren)
echo $aadAppsecret01.Value
