Ist eine HDD für VSAN nicht „berechtigt“ kann sie nicht als Datenplatte zum Kapazitäts-Tier beitragen. In diesem Fall lag das offenkundig daran, dass trotz zuvor per GUI entfernter Datastores offenbar noch VMFS-Partitionen vorhanden waren, die die Verwendung für VSAN verhinderten. Dies wiederrum kann dann der Fall sein, wenn einer VMFS-Partition (beim ESXi-Setup automatisch so konfiguriert) zur Aufnahme von Coredumps im Dateisystem dient oder als Scratch-Location. Die betreffenden Partitionen müssen also manuell entfernt werden.

Trotzdem soll an dieser Stelle noch auf die vSAN-Fehlersuchbefehle der RVC (Ruby vSphere Console) hingewiesen werden Diese startet man auf der Windows-vCenter-Version mit …

~%PROGRAMFILES%\VMware\Infrastructure\VirtualCenter Server\support\rvc\rvc.bat

… und an der  vCenter Server Appliance

rvc root@localhost

So findet man z.B. mit

vsan.disks_info <Host>

schnell heraus, welche Disks für vSAN „ineligible“ sind. Auch hier ist ersichtlich: der Grund dass die betreffenden Disks nicht für VSAN „claim-bar“ sind besteht darin, dass VMFS-Volumes auf den Disks existieren.

Korrespondieren diese nicht mittelbar mit einem Datastore, den man meist über die GUi erfolgreich entfernen kann, kann man diese mit dem Tool „partedUtil“ per SSH oder ESX-Shell löschen, wobei man sich aber anhand der Geräte und Partitionsnamen ganz sicher sein muss, auch die richtigen Partitionen zu löschen, wie z. B.

partedUtil delete „/dev/disks/t10.ATA_____WD5003ABYX2D88_______________________LEN______WD2DWMAYP6589359“ 1

Sollte das nicht funktionieren, hilft zum Löschen der Partition nur noch die „harte Tour“ mittels

dd if=/dev/zero of=“/dev/disks/<DISK>“ bs=512 count=34 conv=notrunc

Wurden alle “störrischen” Partitionen entfernt, muss man 1 Mal den Adapter neu scannen mit

esxcli storage core adapter rescan –all

.. und die Disks sollten anschließend für VSAN nutzbar.

Wie kann so etwas überhaupt passieren? Ein Host im vCenter-Inventory ist „disconnected“, lässt sich aber weder „connecten“ noch ganz entfernen und neu hinzufügen, da sämtliche Kontextmenüs ausgegraut sind? Dieses Szenario ist weder aus der Luft gegriffen, noch stammt es aus der VMware Knowledge Base, sondern aus dem echten Leben.

Ich betreibe 3 ESXi-Hosts in einem kleinen DRS/HA-Cluster. Zwei davon booteten von einem USB-Stick, einer noch von einer lokalen SATA-Platte. Nun hatte ich zum Demonstrationszwecken seit langem geplant, ein kleines VSAN einzurichten und aus diesem Grund drei preiswerte SSDs für das Cache-Tier besorgt, sowie die zwei plattenlosen Hosts mit einer magnetischen Disk aus der Krabbelkiste bestückt. Bei VSAN muss das Kapazitäts-Tier über mindestens so viele Disks verfügen, wie das Cache-Tier also mindestens je Eine. Nun musste aber noch die SATA-Disk des besagten ESXi-Host für VSAN verfügbar gemacht werden.

Die lokalen VMFS-Partitionen ließen sich zwar durch Entfernen der korrespondierendem Datastores im Web-Client entfernen, bzw. in einem hartnäckigen Fall von der Kommandozeile mit  …

partedUtil delete „<disk> <part-nr.>”

das klappt aber zur Laufzeit nicht für alle Partitionen. Da ohnehin klar war, dass ESXi zum Zwecke der VSAN-Umstellung auf einem USB-Datenträger neu installiert werde musste, habe ich die ESXi-Neuinstallation – dank vorhandener Host-Profile und existentem Distributed vSwitch ist die Re-Konfiguration nach dem Basis-Setup ja schnell erledigt – eingeleitet, bevor ich dem Host sauber aus dem Inventory entfernt hatte, eine kleine Nachlässigkeit. Da ich den neu installierten Host unter gleichem Namen ins vCenter aufnehmen wollte, scheiterte dies natürlich an der vorhandenen Karteileiche.

Was also tun? Einen ersten Versuch startete ich mit der neuen DCLI der VCSA-Appliance. Hier empfiehlt es sich aus Bequemlichkeit zunächst mit

dcli +interactive

den interaktiven Modus anzusteuern. Leider funktionierten nach einem ersten

dcli> host list

weder

dcli> host connect –host <hostname>

noch

dcli> host delete –host <hostname>

Letzte Rettung brachte dann wieder mal die bei mir inzwischen favorisierte PowerCLI.

Hier stellt man mit

Connect-VIServer

zunächst eine Verbindung zum vCenter her (das kann interaktiv erfolgen oder durch direkte Angabe des vCenter-Namens und der Credentials) …

… und entfernt dann den Host mit

Remove-VMHost -VMHost <hostname>

Möchte man in einer vSphere-Umgebung nicht mehr benötigte VMFS-Datastores unmounten und/oder ganz entfernen oder möchte man die Backend-seitigen LUNs hinter einem Datastore reorganisieren oder löschen, was ebenfalls mit dem Löschen des Datastores einher geht, sind zuvor in der vSphere-Umgebungen folgende Punkte zu überprüfen. Aber Achtung: beim Entfernern von LUNs müssen unbedingt folgende Bedingung geprüft werden:

• es dürfen keine VMs oder Templates dem Datastore liegen,
• der Datastore darf nicht mehr Mitglied eines Datastore Clusters sein
• der Datastore darf nicht von Storage DRS verwaltet werden,
• Der Datastore darf nicht Datastore Heartbeats für HA verwendet werden
• Storage I/O Control muss für diese Datastore deaktiviert sein.

Trotzdem ist es manchmal nicht möglich, einen VMFS-Datastore erfolgreich zu entfernen. Man bekommt dann einer Fehlermeldung der Art

„The resource ‚Datastore Name: datastore7-SAS-hv3-A VMFS uuid: 585a846d-3c03ab29-cb32-002564bb1d55‘ is in use. Cannot remove volume ‚Datastore Name: datastore7-SAS-hv3-A VMFS uuid: 585a846d-3c03ab29-cb32-002564bb1d55‘ because „file system is busy“. Correct the problem and retry the operation.“

Das wiederum kann daran liegen, dass der Datastore als “diagnostic coredump partition“ konfiguriert ist. Hierbei handelt es sich um ein mit ESXi 5.5 eingeführtes Feature, um Coredumps in einer Datei in einem File auf einem Datastore speichern zu können. In manchen Fällen wird eine solche Datei automatisch erzeugt, was verhindert, dass der Datastore entfernt werden kann.
Ob solche Dump-Files existieren, findet man schnell auf der Kommandozeile durch Eingabe von

esxcli system coredump file list

heraus. In der Ausgabe erkennt man die UUID des ESXi-Hosts, der die Datei gelockt hat. Der hintere Teil der UUID ist die MAC-Adresse von vmnic0, was eine eindeutige Identifikation des Hosts zulässt.

Zum Entfernern der coredump-Datei verbindet man sich per SSH mit diesem Host und löscht dann die Datei mit

esxcli system coredump file remove –force

Egal ob man nun traditionellen SAN-Storage der führenden Storage-Hersteller oder softwaredefinierten hyperkonvergenten Storage (Datacore, Nutanix, Simplivity, Starwind & Co oder eine Open-Source-SDN-Lösung) anbindet, komm beim Storage-Design immer wieder die Frage auf, viele virtuelle Maschinen (also VMDK-Dateien) man auf einer LUN unterbringen kann und soll.

Eine pauschale Empfehlung vom VMware gibt es dazu nämlich nicht, weil sich die Frage pauschal nicht eindeutig beantworten lässt. Im Übrigen lassen sich unsere folgenden Empfehlungen und Überlegungen prinzipiell bzw. zum Teil auch auf andere Virtualisierungslösungen wie Linux/KVM oder VMware übertagen. Nicht alle hierbei zu berücksichtigen Aspekte sind VMware-spezifisch.

Fünf-Punkte-Plan

Sieht man mal ganz von der Frage ab, dass die Anzahl an VMs, die die eigene Storage-Landschaft hinsichtlich der „Packungsdichte“ (VMware empfiehlt Virtualisierungsraten von 4 bis 8) auf den Hosts überhaupt maximal aufnehmen kann, ist sind beim Sizing der Datastores, bzw. der LUN-Größen am Backend stets folgende Punkte zu berücksichtigen:

1. Die LUN ist bei traditionellem Storage immer der begrenzende Faktor für die „Eigenschaften“ des Datastores, also VMs mit unterschiedlichen Workload-Charakteristiken gehören zunächst nicht auf die gleiche LUN.
2. Andererseits profitieren möglicherweise VMs von VMDKs auf der gleichen LUN, wenn deren Workloads miteinander im Zusammenhang stehen.
3. Ferner ist die Anzahl verfügbarer LUNs (Pfade) pro Host begrenzt. Bis ESXi 6 sind 256, ab ESXi 6,5 512 LUNs erlaubt, wobei jeder Pfad extra zählt. Ist also jede LUN z. B. über 4 Pfade erreichbar, reduziert sich die Zahl nutzbarer LUNs auf 64. Gibt es dann noch Datastores mit mehreren Extents, reduziert sich die Anzahl nutzbarer LUNs weiter. Ist aber die Anzahl der hinsichtlich der Konsolidierungsrate nutzbarer VMs deutlich größer, führt schon kein Weg daran vorbei, mehrere VMs auf einer LUN unterzubringen.
4. Bei der Auswahl der LUN-Charakteristik ist außerdem zu berücksichtigen, ob das das Storage-Aarray VMwares „vSphere Storage APIs Array Integration“ (VAAI) unterstützt und z. B. Storage-Operationen wie „Clone Blocks/Full Copy /XCOPY“, „ATS“ (Atomic Test & Set) zur Vermeidung von SCSI Reservations, „Zero Blocks/Same Writer“ oder Thin-Provisioning auf das Storage-System offloaden kann. Seit ESX 5.1 kann der ESXi-Host übrigens Informationen zum Storage-Back-end senden, welche Blöcke im Datastore nicht mehr mit VMs-Daten belegt sind, etwa weil eine VM beispielsweise gelöscht oder migriert wurde. Seit vSphere 6,5 kann das so genannte Reclaiming im Zusammenhang mit VMFS 6 sogar automatisch erfolgen. Es ist also z. B. nicht sinnvoll, VMs mit VMware-Thin-Provisiong auf vom Storage thin provisionierte LUNs zu platzieren, um nur ein Beispiel zu nennen.

Damit aber nicht genug. Die Anzahl pro LUN sinnvoller VMs wird noch durch weitere diffizilere Eigenschaften begrenzt. So beschränkt z. B. auch die IO-Queue innerhalb von VMware die Anzahl der VMs pro Datastore. So besitzt jeder ESXi-Host eine Queue-Tiefe von 32 Kommandos pro VMFS-Datastore.

Hat der Storage z. B. eine durchschnittliche Latenz von 5ms für alle IOs, so lassen sich die theoretisch maximal möglichen IOPS berechnen, bevor der Server zusätzliche Latenzen durch ein Überlaufen der Queue erfährt: 1 (host) * 32 (Kommandos pro Queue) * 1000 ms/5ms = durchschnittliche Latenz = 6400 IOPS. Mit 6400 IOPS könnte man dann z. B. 10 sehr aktive VMs mit je 640 IOPS pro VM auf den Datastore packen. Der Wert berechnet sich stets pro ESX Host. Verteilt man also seine VMs gleichmäßig auf die ESX Server, kann man aus Performance-Sicht natürlich deutlich mehr als 10 VMs auf einen Datastore legen.

Die Neuerungen in Kubernetes 1.6 betreffen vor allem Skalierung und Automatisierung. So unterstützt Kubernetes 1.6 nun bis zu 5.000 Knoten und insgesamt ca. 150.000 Pods. Diese enorme Erweiterung wird durch das von CoreOS stammende etcd v3 ermöglicht.

Weitere Neuerungen

Mit dem „Federeration“-Feature lassen sich nun mehrere Cluster über einen API-Endpunkt ansprechen, sogar dann, wenn sie in verschiedenen Rechenzentren stehen. Darüber hinaus haben die Entwickler in Kubernetes 1.6 die Ablaufplanung, um Pods besser abgestimmt bereitstellen zu können, optimiert. So können Nutzer nun Pods mit

Node affinity/anti-affinity

nur auf bestimmten, auf Labels basierenden Nodes, aufsetzen. Dabei können sie mit „taints and tolerations“ markieren, welche Nodes für Pods nicht bereit stehen.

Neu ist auch, dass der Scheduler nun Regeln beherrscht, um Pods in bestimmten Zonen, basierend auf einer vorgegebenen Fehlertoleranz oder auf Nodes eines bestimmten Nutzers zu starten. Nutzer können aber auch eigene Scheduler erstellen. Darüber hinaus haben die Entwickler das Runtime-Interface, den etcd v3 (s. o) und die Daemon-Sets aktualisiert.

Storage-Bereitstellung

Ferner hat das Entwickler-Team die automatisierte Bereitstellung von Storage verbessert. So sind in Version 1.6 nun StorageClass und die dynamische Volume-Provisionierung als stabil gekennzeichnet. Damit können Nutzer jetzt Storage nach Bedarf erzeugen, so dass die bisher erforderliche Vorprovisionierung nicht mehr nötig ist. Per Default installiert Kubernetes 1.6 die StorageClass-Objekte für AWS, Azure, GCP, OpenStack und VMware vSphere, unterstützt aber zusätzlich auch ScaleIO (Plugin), Portworx (Plugin) und NFSv3, NFSv4 sowie GlusterFS (mit den COS Node Image).

Alpha und Beta

Neu eingeführt wurden einige Funktionen im Alpha-Stadium wie „Out-of-tree cloud provider“, „Per-pod-eviction“, die „Pod Injection Policy“ und „Custom metrics“. Dafür haben einige ältere Alpha-Features jetzt Beta-Status erlangt wie z. B. Das CLI-Tool „kubefed“. Es kann jetzt „kube-dns“ automatisch konfigurieren.

Ebenfalls neu im Beta-Stadium ist die rollenbasierte Zugriffskontrolle (RBAC). Administratoren damit nun fein granular bestimmen, welche Nutzer welche Komponenten eines Kubernetes-Clusters kontrollieren können. Dabei wird auch das ebenfalls als Beta-Version gekennzeichnete CLI-Tool kubeadm unterstützt.

Kubernetes ist unter der Apache License 2.0 veröffentlich und kann von Github heruntergeladen werden.

Entwickler, die in der Lage sind Cloud-Anwendungen zu schreiben sind derzeit hoch gefragt aber kaum verfügbar. Die Non-Profit-Organisation Cloud Foundry Foundation will die Lage nun mit einem neuen Zertifizierungsprogramm verbessern.

Cloud Foundry ist eine quelloffene Platform-as-a-Service (PaaS), die im Wesentlichen von der Cloud Foundry Foundation getragen wird. Die zugrunde liegende Software wurde ursprünglich von VMware entwickelt und später an Pivotal Software übergeben, ein Joint Venture mit der Konzernmutter EMC und General Electric. Im Jahr 2015 wurde das Projekt von Pivotal geöffnet und in die Cloud Foundry Foundation, eine unabhängige Non-Profit-Organisation überführt, die als kollaboratives Projekt unter dem Dach der Linux Foundation beheimatet ist, von dieser aber weitgehend unabhängig agiert.

Cloud Foundry versteht sich im Hinblick auf den Open-Source-Kern gern als das PaaS-Pendant zu OpenStack (IaaS).

Cloud Foundry Certified Developer

Da laut Aussage der Cloud Foundry Foundation ein eklatanter Mangels an fähigen Cloud-Entwicklern herrscht, startet die Stiftung nun unter dem Titel Cloud Foundry Certified Developer eine Initiative zur Zertifizierung von Entwicklern von Cloud-Anwendungen.

Das Programm soll aber gemeinsam mit der Linux Foundation angeboten werden. Ein genauer Starttermin ist noch nicht bekannt; er soll aber auf dem im kommenden Juni stattfindenden Cloud Foundry Summit Silicon Valley 2017 bekannt gegeben.

Die neue Cloud Foundry-Zertifizierung soll Distributions-unabhängig sein und erfolgreichen Absolventen als Nachweis über Praxiserfahrung mit Cloud-Foundry-Implementationen dienen. Kurse zur Cloud Foundry-Zertifizierung für Entwickler sollen online angeboten werden, damit Schulung und Zertifizierung standortunabhängig überall auf der Welt möglich ist.

Das Paket

Das Paket besteht aus einem kostenlosen Einführungskurs auf der edX-Plattform, einem E-Learning-Kurs „Cloud Foundry für Entwickler“« zum Selbststudium, sowie einem Schulungspartnerprogramm, einschließlich lizenziertem Material für Präsenz-Cloud-Foundry-Kurse für Entwickler. Dieses wird von den Mitgliedsunternehmen Dell EMC, EngineerBetter, IBM, Pivotal, Resilient Scale, SAP, Stark and Wayne und Swisscom angeboten.

Teilnehmer, die eine erfolgsabhängige Prüfung bestehen erhalten die „Cloud Foundry Certified Developer“-Zertifizierung.
Die Anmeldung zum kostenlosen Einführungskurs auf edx.org soll ab Anfang Mai möglich sein. Der E-Learning-Kurs „Cloud Foundry for Developers“ zum Selbststudium soll ab dem 13. Juni für 500 US-Dollar erhältlich sein.

Die bis zu vier Stunden dauernde Zertifizierungsprüfung kann ebenfalls online zu einem Preis von 300 Dollar abgelegt werden oder direkt auf dem vom 13. bis 15. Juni 2017 stattfindenden Cloud Foundry Summit Silicon Valley.

Der Red Hat Product Security Risk Report für 2016 liegt jetzt vor und geht auf die Analyse von Red Hats eigenem Security-Team zurück. Der Report ist eine Auflistung der im jeweils zurückliegenden Jahr bekannt gewordenen und geschlossenen Sicherheitslücken für die wichtigsten Produkte. Der vollständige Bericht kann als PDF-Datei kostenfrei von Red Hat heruntergeladen werden.

Schadensklassen

Red Hat klassifiziert die gefundenen Sicherheitslücken dabei nach ihren potentiellen Auswirkungen in die Kategorien Low, Moderate, High und Critical.

Neben (wenigen) schwerwiegenden Lücken, die jeweils mit einem eigenen Namen versehen auch jenseits der Community für Aufmerksamkeit sorgen, sind die namenlosen kleineren Lücken in der Mehrzahl und betreffen z. B. Web-Browser und einige wenige Desktop-Anwendungen.

So gab es in 2016 in allen Versionen von Red Hat Enterprise Linux rund 50 kritische Sicherheitslücken die in 38 entsprechenden Sicherheitsmeldungen kumulierten. Alle betroffenen Pakete in Red Hat Enterprise Linux wurden von Red Hat noch am Tag der Bekanntgabe oder spätestens einen Tag danach aktualisiert; bei anderen Produkten ließ sich Red Hat dagegen etwas länger Zeit. Konkret erhielten hier 76% der Pakete ein Update am selben oder folgenden Tag. Spätestens nach einer Woche waren 98% der gemeldeten Sicherheitslücken behoben.

In Summe hat das Sicherheitsteam 2016 rund 1300 Sicherheitslücken bearbeitet und dazu 600 Sicherheitsmeldungen heraus gegeben. Untersucht wurden insgesamt sogar 2600 potentielle Sicherheitslücken, rund 600 mehr als 2015. Allerdings hatten die Hälfte davon keine Auswirkung, bzw. Bedeutung für Produkte von Red Hat.

Embargo

Red Hat wünscht sich, dass jede potenzielle Sicherheitslücke vor der allgemeinen Veröffentlichung den eigenen Entwicklern bekannt gemacht wird und spricht sich für vergleichsweise kurze Zeitspannen zwischen Mitteilung und Veröffentlichung aus. Dieses so genannten „Embargo“ solle nach den Vorstellungen von Red Hat möglichst kurz sein, damit die Lücke für potentielle Angreifer möglichst wenig „einbringt“.

Die Red-Hat-Entwickler sind allerdings 2016 nach eigener Aussage nur in 29% der Fälle in den Genuss eines Embargos gekommen. In nahezu alle anderen Fällen wurde Red Hat von der jeweiligen Veröffentlichung überrascht, sodass die eigenen Entwickler nur noch „reagieren“ konnten. Dabei bezog das Red-Hat-Team 65,5 Prozent aller Sicherheitslücken selbst aus Mailinglisten, 12,8 Prozent fanden über persönliche Beziehungen ihren Weg zu den Sicherheitsexperten von Red Hat und 10,6 Prozent wurden von Entwicklern bei Red Hat intern gemeldet, also Entwicklern, die bei Red Hat selbst beschäftigt sind oder von Red Hat bezahlt werden. Andere Quellen spielten kaum einer Rolle.

Red Hat hat rund zehn Monate nach der letzten Aktualisierung Version 6.9 seiner Unternehmens-Distribution veröffentlicht.

Wie bei RHEL üblich ändert sich dabei die Hauptversion des Kernels – bei Red Hat Enterprise Linux 6.x ist das 2.6.32 – nicht. Red Hat implementiert dringend benötigte Aktualisierungen, wie die mit RHEL 6.9 großzügig erweiterte Hardware-Unterstützung, mit Hilfe von Backports.

Der verbesserte Hardware-Support erleichtert einen möglichst reibungslosen Wechsel auf RHEL 7 und bringt unter anderem Treiber für RealTek RTS5250S SD4.0 und Marwell 88SE9230-Controller mit. Neu in RHEL 6.0 ist auch das Tool cpuid.

Weitere Neuerungen

Neu in RHEL 6.9 sind zudem Verbesserungen bei den Virtualisierungsfunktionen und im Cluster-Bereich. Im Bereich Virtualisierung hat Red Hat z. B. die Geschwindigkeit des Hyper-V-Storage-Treibers verbessert. Ebenfalls neu ist, dass der Netzwerkmanager jetzt auch eine manuelle DNS-Konfiguration unterstützt.

Bei den Cluster-Funktionen ist erwähnenswert, dass die Pacemaker-Agents nun Oracle 11g unterstützen. Ferner hat Red Hat das Paket „clufter“ auf die Version 0.59.8 aktualisiert. Gleich mehrere Aktualisierungen hat zudem auch „luci“-Interface erhalten.

Neu ist auch, dass RHEL 6.9 Updates für TLS 1.2 erhalten hat, die im Prinzip gleich mehrere Bereiche innerhalb der Distribution betreffen. Verbessert wird dadurch unter anderem die sichere Kommunikation. Dabei bietet RHEl 6.9 nun auch Support für die aktuellen PCI-DSS-Standards. Außerdem ist es möglich, innerhalb der IdM- und Verzeichnisservern ältere Versionen von TLS verbieten.
Weitere Einzelheiten zu den Neuerungen lassen sich den Releae Notes entnehmen.

Endspurt

Anfang Mai wird RHEL 6 in so genannte Production Phase 3 übergehen. Das bedeutet, dass RHEL 6 zwar weiterhin Korrekturen erhält, Red Hat aber nicht mehr aktiv neue Server-Features oder Hardware-Treiber entwickelt. Das endgültige Support-Ende für RHEL 6 steht dann Ende 2020 an.

Wie bei Red Hat üblich kann RHEL 6.9 über Red Hats Content Delivery Network Red Hat Network (RHN) bezogen werden. Bestandskunden erhalten RHEL 6.9 im Verlauf des regulären Updates. Darüber hinaus gibt es ISO-Images, die ebenfalls nur mit einem gültigen RHN-Konto zugänglich sind. Die Distribution steht wahlweise in Form einer Minimal-CD oder als DVD-ISO bereit. Ergänzend gibt es eine Supplementary-DVD mit weiteren Paketen für erweiterte Funktionalität. RHEL 6.89 gibt es nur für die Architekturen x86_64 und i386.

Sämtliche Neuerungen von Samba 4.6 lassen sich im Detail dem Changelog entnehmen. Die Entwickler haben aber auch eine Reihe von Korrekturen vorgenommen:

Korrekturen

Eine ganze Reihe von Verbesserungen erhielt z. B. die Datenbank ctdb. Ferner wurde in winbind das Verfahren zur Ermittlung der Gruppenmitgliedschaft eines Benutzers verbessert. Die primäre Gruppe lässt sich nun aus den Unix-Attributen des Benutzers bestimmen. Korrekturen erhielt darüber hinaus auch das DNS-Unterkommando von „samba-tool“.

Ferner wird die Option „fruit:resource“ in „vfs_fruit“ in Samba 4.6 nicht mehr ignoriert. In Version 4.5 war dies der Fall, weil der Parser der Konfiguration einen Rechtschreibfehler enthielt, der mit Version 4.6 korrigiert wurde. Anwender müssen aber ihre Konfigurationsdatei überprüfen und die Option entweder entfernen oder auf den Standardwert „file“ setzen, weil es sonst passieren könnte, dass MacOS-Clients nicht auf die Ressourcen-Fork-Daten von Dateien zugreifen können.

Darüber hinaus wird eine Falschschreibung der Option „ressource“ (statt „resource“) in Samba 4.6 noch akzeptiert, was in der kommenden Version nicht mehr der Fall sein soll.

Neuerungen

Bei den Neuerungen ist zu erwähnen, dass der Parameter „inherit owner“ in der Datei smb.conf die zusätzliche Option „unix only“ erhielt. Der Parameter „inherit owner“ weist den smbd an, als Eigentümer einer Datei den Eigentümer des Verzeichnisses zu verwenden. Dies erlaubt quasi das Einrichten einer Art Quota für Verzeichnisse.

Ferner erhielt die Kerberos Client-Operationen einen neuern Parameter „kerberos encryption types“. Darüber ist das Hochladen von Druckertreibern jetzt von Windows 10-Clients aus möglich.

Ebenfalls neu ist, dass der Netlogon-Server nun auf mehrere Prozesse aufgeteilt laufen kann. Vorher war nur ein Prozess möglich. Außerdem lauscht Netlogon jetzt an einem anderen TCP-Port, nicht mehr am gleichen Port wie die übrigen RPC-Dienste, wobei der Port für diese Dienste jetzt außerdem konfigurierbar ist.

Performance-Steigerungen

Darüber hinaus konnten die Entwickler die Geschwindigkeit der LDB-Datenbank steigern, in der letztendlich das Active Directory gespeichert ist. Auch die Replikation zu anderen Active Directory-Servern soll jetzt deutlich schneller gehen.

Update

Wer eine aktuelle Samba-Version 4.5 auf die neue Version updaten möchte, muss zwingend folgende Hinweise der Entwickler beachten: nach Aussage der Entwickler verwenden viele Nutzer immer noch eine ungültige, bzw. fehlerhafte ID-Mapping-Konfiguration. Die lässt sich mit einem neuen, vom Samba-Team veröffentlichten Testtool „testparm“ überprüfen. Wer ein Update plant, sollte testparm daher nach dem Update, bzw. im Anschluss an eine etwaige Anpassung der Konfigurationsdatei ausführen.

Ferner müssen Nutzer von BSD-Systemen noch die von „vfs_fruit“ genutzten erweiterten Attribute umbenennen, wenn sie die Standardeinstellung „fruit:metadata = netatalk“ verwenden. Auch dazu hat das Samba-Team ein Programm „mvxattr“ geschrieben.

VMware ist seit dem Jahr 2008 Mitglied der Linux Foundation und verstärkt nun als Gold-Unterstützer sein Engagement in der Linux Foundation. Der Virtualisierungsanbieter engagiert sich bekanntlich auch in vielen anderen Initiativen, Stiftungen und Projekten rund um die Themen Virtualisierung und Cloud-Computing.

Laut Aussage von Dirk Hohndel – zuletzt bei VMware beschäftigt, davor über 15 Jahre IBMs Open-Source-Technikchef und früher einer der ersten Führungsmitarbeiter von Suse – will VMware in Zukunft noch enger mit der Open-Source-Gemeinschaft zusammenarbeiten.

VMware verspricht sich von der Kooperation verbesserte Lösungen und Dienste für die eigenen Kunden. Die weitaus meisten Appliance-Lösungen von VMware – meist Ergänzungen für die Kern-Produkte – basieren auf Suse Linux Enterprise. Insgesamt will VMware als Gold-Mitglied die Interaktion mit der Gemeinschaft intensivieren und auch die eigenen Beiträge deutlich erhören.

Alte Wunden

Dass die Initiative zur Intensivierung der Zusammenarbeit von VMware ausgeht ist bemerkenswert, weil die Gemütslage zwischen VMware und der Linux Community bis ins letzte Jahr hinein nicht ganz ungetrübt war.

Zur Erinnerung: der Kernel-Entwickler Christoph Hellwig hatte wegen eines länger schwelenden Streits um eine mögliche GPL-Verletzung seitens VMware beim ESXi-Kernel in Hamburg ein Verfahren gegen VMware angestrengt, das aber 2016 in erster Instanz mit einer Niederlage Hellwigs endete. Das Gericht hatte Hellwigs Klage abgewiesen, weil nach Ansicht des Gerichts kein ausreichender Anteil Hellwigs am Copyright der betroffenen Kernel-Teile erkennbar war.

Die „angebliche“ Copyright-Verletzung am Linux-Kernel durch VMware ist aber auch in der Community umstritten. Zumindest waren und sind sich die meisten Linux-Kernel-Entwickler darin einig, eine derartige Klage nicht angestrengt zu haben. Hohndel – selbst Kernel-Entwickler der ersten Stunde – hatte die Hintergründe zu diesem Rechtsstreit in einem Interview auf Linux.com näher erläutert.