Orthodoxe Dateimanager

Unendliche Mannigfaltigkeit in unendlicher Kombination. Frei nach diesem Grundprinzip der vulkanischen Philosophie könnte der geneigte Nutzer auch die Vielfalt der Dateimanager betrachten.

Neben den mit den Betriebssystemen mitgelieferten Dateimanagern, wie dem Explorer unter Windows oder dem Finder unter macOS, existieren viele weitere Dateimanager, mit teils recht unterschiedlichen Herangehensweisen.

Eine Klasse von Dateimanagern stellen die orthodoxen Dateimanager, auch Zwei-Panel-Datei-Manager genannt, dar. Diese nutzen ein Konzept, welches insbesondere dann seine Vorteile ausspielt, wenn viel und oft mit Dateien gearbeitet wird und eine flexible Arbeitsweise gewünscht ist.

Mit ihrer charakteristischen Zwei-Panel-Architektur und tastaturzentrierten Bedienung bieten sie eine Effizienz, die moderne grafische Dateimanager selten erreichen.

Definition

Orthodoxe Dateimanager verdanken ihre Bezeichnung nicht einer religiösen Konnotation, sondern ihrer Treue zu den etablierten Designprinzipien des Norton Commander, welcher erstmals 1986 erschien.

Der Begriff Orthodox File Manager (OFM) wurde durch Nikolai Bezroukov 1996 geprägt und bezeichnet die standardisierte Implementierung der Zwei-Panel-Philosophie:

I introduced the term „orthodox file managers“ in 1996 (see OFM Bulletin 1998) …

Das zentrale Element eines orthodoxen Dateimanagers sind zwei symmetrische Verzeichnisfenster (Panels), die es ermöglichen, Dateien direkt zwischen Quell- und Zielverzeichnis zu verwalten. Eines der beiden Panels ist aktiv (Quelle), das andere passiv (Ziel). Sämtliche Befehle beziehen sich auf dieses Verhältnis.

OFMs bieten einen einheitlichen Funktionsumfang: Kopieren, Verschieben, Löschen und Umbenennen über klar strukturierte Menüs und vordefinierte Shortcuts.

Die vollständige Tastaturbedienung steht im Vordergrund und erlaubt es, sämtliche Operationen ohne Maus durchzuführen. Die Belegung entspricht auch heute noch größtenteils denen des Norton Commanders:

F1: Hilfe
F2: Benutzermenü
F3: Datei betrachten
F4: Datei bearbeiten
F5: Kopieren
F6: Verschieben/Umbenennen
F7: Verzeichnis erstellen
F8: Löschen
F9: Menüleiste aktivieren
F10: Beenden
Tab: Zwischen Panels wechseln
Einfügen: Dateien markieren

Auch Archivformate wie ZIP oder TAR werden meist direkt unterstützt, oft so, als wären sie normale Verzeichnisse. Hierbei ist die Rede von virtuellen Dateisystemen. Diese abstrahieren verschiedene Speicherquellen, Archive, FTP-Server oder Cloud-Speicher und binden sie transparent als Verzeichnisse ein.

Ergänzt wird dieser Ansatz durch integrierte Dateibetrachter und Editoren, sodass viele Aufgaben innerhalb des Dateimanagers, ohne einen Rückgriff auf andere Anwendungen, erledigt werden können.

Orthodoxe Dateimanager sind eng mit der nativen Shell des Systems verbunden. Pfade und Befehle lassen sich direkt, innerhalb des Dateimanagers, an die Kommandozeile übergeben.

Trotz der Standardisierung der Kommandos und des generellen Aussehens ist die Anpassbarkeit ein weiteres Merkmal orthodoxer Dateimanager. Tastenkombinationen, Menüstrukturen und das Erscheinungsbild lassen sich in vielen Fällen an persönliche Bedürfnisse anpassen.

Spezifikationen

Nikolai Bezroukov prägte nicht nur den Begriff des orthodoxen Dateimanagers, sondern überführte diese Philosophie in einige Spezifikationen.

Die OFM-Spezifikation von 1999 hatte das Ziel, diese Philosophie zu standardisieren. Sie legt Grundfunktionen und Interaktionsmuster fest, um eine langfristig tragfähige Basis für Entwickler und Anwender zu schaffen.

Nach dem ursprünglichen OFM-Standard von 1999 wurde im Jahr 2004 eine Erweiterung veröffentlicht.

Ziel war es, neben dem fest etablierten Grundkonzept auch fortgeschrittene Funktionen wie Filter, benutzerdefinierte Sortierung und Archivverwaltung zu normieren.

Die letzte Erweiterung stammt aus dem Jahr 2012. Zu den wesentlichen Erweiterungen zählen flexible Panel-Größen, erweiterte Skriptintegration mit Variablenzugriff sowie die Vorbereitung auf Funktionen wie Tabs und Plugin-gesteuerte Dateiansichten.

Um übermäßige Komplexität zu vermeiden, wurden nur Features aufgenommen, die sich in mindestens einem Jahr realer Nutzung bewährt hatten.

Seitdem wurde die Spezifikation nicht weiter überarbeitet. Dennoch lieferte sie wichtige Impulse und eine Orientierung für die Praxis.

Geschichte

Einer der ersten Dateimanager mit textbasierter, aber visuell strukturierter Oberfläche war PathMinder von Albert Nurick und Brittain Fraley. Dieser erschien im Jahr 1984. Einen Monat nach der Veröffentlichung erschien mit DualView ebenfalls ein textbasierter Dateimanager.

Mit XTree erschien 1985 ein weiterer Vertreter, welcher ähnlich wie PathMinder eine Art Baumstruktur darstellte.

Der De-facto-Standard der orthodoxen Dateimanager wurde 1986 mit dem Norton Commander definiert, der durch geschicktes Marketing und technische Verfeinerung stilbildend wirkte.

Gestartet wurde die Arbeit am Norton Commander von John Socha im Jahr 1986. Zu dieser Zeit trug das Projekt den Namen Visual DOS bzw. VDOS:

I started work on what became known as the Norton Commander in the fall of 1984 while I was still a graduate student in Applied Physics at Cornell University. The first versions were entirely in assembly language, but that was too time-consuming, so I soon switched to a blend of C and assembly language at a time when most „real programmers“ wouldn’t touch C.


At the time I called it Visual DOS, with the abbreviation of VDOS instead of the usual two-letter abbreviations used at the time.

Norton Commander 1.0 erschien im Mai 1986 und definierte die Grundprinzipien, die bis heute Gültigkeit haben. Auch bot er erstmals einen integrierten Viewer und Editor, wodurch komplette Workflows ohne Anwendungswechsel möglich wurden.

Die Version 3.0 von 1989 gilt als Höhepunkt der DOS-Ära mit Hypertext-Hilfe und dem legendären Sternenhimmel-Bildschirmschoner.

Inspiriert vom Norton Commander erschienen ab Ende der 1980er-Jahre weitere orthodoxe Dateimanager wie der Volkov Commander oder der DOS Navigator.

In der Unix- bzw. Linux-Welt entstand 1994 mit dem Midnight Commander, von Miguel de Icaza, einer der bekanntesten orthodoxen Dateimanager.

Auch für Systeme wie OS/2 wurden orthodoxe Dateimanager entwickelt, wenngleich diese heute nur noch eine geringe Nutzerschaft aufweisen.

Vom Terminal zur GUI

Neben den textbasierten orthodoxen Dateimanagern entstanden mit dem Aufkommen von Windows auch grafische Umsetzungen dieses Konzepts.

Hier sind Entwicklungen wie der Windows Commander (1993), welcher später zum Total Commander wurde, sowie die Umsetzung des Norton Commander für Windows (1998) zu nennen.

Unter Linux entstanden grafische OFMs, wie der GNOME-Commander und Krusader.

OFMs im Einzelporträt

Heutzutage werden eine Vielfalt von orthodoxen Dateimanagern für unterschiedliche Systeme aktiv entwickelt und vorangetrieben.

Neben den hier vorgestellten orthodoxen Dateimanagern existieren unzählige weitere – von kleineren Prototypen bis zu ausgewachsenen kommerziellen Varianten.

Grundsätzlich müssen zwei Formen unterschieden werden. Die klassischen auf einer Terminal UI (TUI) basierten Dateimanager und die auf einer grafischen UI (GUI) basierten Dateimanager.

TUI-basierte Implementationen

Zu den TUI-basierten Implementationen würde aus heutiger Sicht auch der Norton Commander gehören.

Selbst im Zeitalter grafischer Systeme und Bildschirmauflösungen jenseits der 4K haben solche Dateimanager nach wie vor ihre Berechtigung.

Sei es auf der Nutzung im Terminal oder auf entfernten Rechnern per SSH.

Far Manager

Der Far Manager wurde 1996 von Eugene Roshal, seines Zeichens Schöpfer des RAR-Formats, entwickelt. Seit 2007 ist er freie Software unter der modifizierten BSD-Lizenz und wird aktiv entwickelt.

Er ist ein textbasierter orthodoxer Dateimanager für Windows, der die Tradition des Norton Commanders in die moderne Windows-Ära überträgt.

Der Far Manager erinnert an den Norton Commander

Die Zwei-Panel-Struktur wird durch eine Kommandozeile am unteren Rand ergänzt, die eine direkte Ausführung der Befehle ermöglicht. Dabei wird eine Art Autovervollständigung geboten.

Die Oberfläche unterstützt verschiedene Farbschemata und kann detailliert angepasst werden. Moderne Features wie Drag & Drop innerhalb des Dateimanagers werden, trotz der Konsolennatur, unterstützt.

Daneben verfügt der Far Manager über einen integrierten Text-Editor sowie einen Viewer. Auch die Unterstützung für Archiv-Formate und deren Einbindung ist gegeben.

Mit seinem umfangreichen Plugin-System und der Fokussierung auf Effizienz richtet er sich an erfahrene Anwender.

Verfügbar ist der Dateimanager für Windows, jeweils in einer x64 und einer ARM64-Version. Es existiert auch eine Linux-Portierung des Managers.

Midnight Commander

Der Midnight Commander gilt auf dem Terminal unter Unix- und Linux-Systemen als Standard-OFM. Erstmalig veröffentlicht wurde er im Jahre 1994 durch Miguel de Icaza, welcher später das GNOME-Projekt mitbegründete.

Der Midnight Commander unter macOS

Als GNU-Software unter der GPL in Version 3 veröffentlicht, läuft er in Textterminals und bietet seine volle Funktionalität sowohl lokal als auch über SSH-Verbindungen.

Seine Entwicklung kam mehrere Jahre zum Erliegen, aber seit 2009 wurde er mit der Version 4.6.2 wieder aktiv weiterentwickelt.

Die VFS-Implementierung unterstützt SSH, SFTP, FTP und zahlreiche Archivformate.

Für die direkte Arbeit mit Dateien steht ein eingebauter Texteditor zur Verfügung. Er bietet unter anderem Syntax-Highlighting für viele Programmiersprachen.

Ergänzt wird der Editor durch einen Viewer, der Text- und Binärdateien unterstützt. Die integrierte Suchfunktion hilft beim Auffinden von Dateien im Verzeichnisbaum. Die Farbgebung ist anpassbar, und verschiedene Skins stehen zur Verfügung.

Trotz der text-basierten Natur bietet der Midnight Commander eine Maus-Unterstützung in modernen Terminal-Emulatoren.

Unter Linux-Systemen kann der Midnight Commander über den Paketmanager installiert werden. Für macOS gilt das Gleiche, etwa über Homebrew. Daneben existiert mit mcwin32 eine Windows-Portierung des Dateimanagers.

GUI-basierte Implementationen

Neben den terminal-basierten Implementationen existiert eine große Auswahl an GUI-basierten Implementationen des OFM-Paradigmas.

Linux

In der Linux-Welt existierten einige historische OFMs, wie der Tux Commander, emelFM2 oder Sunflower, welche mittlerweile mehr oder weniger inaktiv sind. Gleichzeitig existieren dort aktiv weiterentwickelte orthodoxe Dateimanager.

GNOME Commander

Der GNOME Commander wurde ursprünglich 2001 vorgestellt und richtet sich an Nutzer der GNOME-Desktop-Umgebung. Die Anwendung ist in C++ geschrieben und nutzt GTK für die grafische Oberfläche. Interessant ist dass mittlerweile eine Reimplementation in Rust vorgenommen wird.

GNOME Commander unter Ubuntu

GNOME Commander integriert sich gut in GTK-basierte Desktop-Umgebungen. Standardmäßig glänzt er in einem Norton Commander-Blau.

Der Dateimanager ist eng in die GNOME-Desktopumgebung integriert und nutzt das zugrunde liegende GIO-Framework als Abstraktionsschicht für Dateien und andere Ressourcen.

Der Archivzugriff ist im GNOME Commander nicht so komfortabel gelöst wie in anderen orthodoxen Dateimanagern, da sie hier auf externe Tools verlassen wird und keine Integration in ein virtuelles Dateisystem erfolgt.

Daneben bietet der Dateimanager Unterstützung für erweiterte Dateiattribute, darunter Eigentümer, Benutzergruppen, Zugriffsrechte und Zeitstempel.

Ein Lesezeichen- und Favoritensystem erlaubt es, häufig genutzte Pfade als Schnellzugriffe zu speichern und wieder aufzurufen.

Weiterhin unterstützt der Dateimanager entfernte Verbindungen, was den Zugriff auf SSH-, SFTP-, FTP-, SMB-, sowie WebDAV-Server ermöglicht.

Das Projekt ist unter der GPL in Version 2 lizenziert und wird aktiv auf GitLab gepflegt.

Installiert werden kann der GNOME Commander über den jeweiligen Paketmanager der Linux-Distribution.

Krusader

Krusader wurde im Jahr 2000 vorgestellt und bietet eine moderne, grafische Interpretation der orthodoxen Dateimanager-Philosophie. Die Oberfläche integriert sich nahtlos in KDE und nutzt dessen Design-Sprache. Tabs, Toolbars und Kontextmenüs sind vollständig anpassbar.

Krusader unter Ubuntu

Die C++-Implementierung nutzt KDE-Frameworks, was den Zugriff auf verschiedenste Dateisysteme und Ressourcen ermöglicht. Dadurch lassen sich Netzwerkpfade und Archive wie reguläre Ordner behandeln.

Die Archiv-Unterstützung ist dank der KDE-Bibliotheken sehr breit aufgestellt: Krusader kann mit nahezu allen gängigen Archivformaten umgehen, darunter ZIP, RAR, 7Z und TAR. Die Archive lassen sich direkt durchsuchen und bei Bedarf entpacken oder erstellen.

Die Suchfunktion erlaubt nicht nur das schnelle Auffinden von Dateien, sondern auch die inhaltsbasierte Suche.

Zur Vorschau von Dateien nutzt Krusader den einen kombinierten Viewer und Editor.

Für Dateivergleiche steht eine eingebaute Synchronisationsfunktion mit grafischer Oberfläche zur Verfügung, die Unterschiede zwischen Verzeichnissen übersichtlich darstellt und verschiedene Synchronisationsmodi anbietet.

Andere Funktionen wie die Mehrfachumbennenung werden über externe Werkzeuge wie KRename realisiert.

Krusader ist unter der GPL lizenziert und kann über den Paketmanager installiert oder alternativ bezogen werden.

macOS

Auch für das macOS stehen eine Reihe von orthodoxen Dateimanagern zur Verfügung, darunter auch solche, die besonderen Wert auf eine gelungene Integration in das System legen.

Commander One

Commander One wurde 2015 von Eltima Software (jetzt Electronic Team) veröffentlicht und ist ein orthodoxer Dateimanager für macOS. Er kombiniert die klassische Zwei-Panel-Struktur mit einer modernen Cocoa-Oberfläche.

Die Zwei-Panel-Ansicht ist zentrales Element, ergänzt durch Toolbar, Pfadleiste und Dateidetails. Der Dateimanager unterstützt macOS-Finder-Tags, Quick Look und bietet native Hotkey-Unterstützung.

Die Anwendung wurde in Swift entwickelt und ist sowohl in einer kostenlosen Grundversion als auch in einer kostenpflichtigen Pro-Variante mit erweiterten Funktionen erhältlich.

Commander One

Klassische OFM-Funktionstasten werden weitgehend unterstützt, ebenso wie Drag & Drop und Kontextmenüs im Stil des macOS-Finders. Auch die einfache Möglichkeit versteckte Dateien anzuzeigen ist positiv hervorzuheben.

In der Pro-Version wartet Commander One mit erweiterten Archivfunktionen auf. Archive in Formaten wie ZIP, RAR, 7z oder TAR lassen sich nicht nur extrahieren, sondern auch direkt erstellen. Hinzu kommt eine leistungsfähige Cloud-Integration, die unter anderem Google Drive, Dropbox, OneDrive, Amazon S3 und WebDAV unterstützt. Auch Apples iCloud ist sinnvoll eingebunden.

Für den Zugriff auf entfernte Server bietet Commander One integrierte Clients für FTP, SFTP und SCP. Ein eingebautes Terminal-Fenster ermöglicht den direkten Zugriff auf die Shell, ohne die Anwendung zu verlassen.

Allerdings muss hier berücksichtigt werden, dass es Unterschiede zwischen der Version aus dem App Store und der von der Webseite des Herstellers gibt. Aufgrund der Sandbox-Beschränkungen sind einige Funktionen nur in der Version des Herstellers verfügbar. Dazu zählen z. B. das Beenden von Prozessen, das Mounten von iOS-Geräten und das Ignorieren der System-Einstellungen für die Funktionstasten.

Neben dem Bezug über den App Store kann Commander One auch direkt über die Webseite des Herstellers bezogen werden.

Marta

Marta ist ein moderner und minimalistisch gestalteter Zwei-Panel-Dateimanager für macOS, der 2017 als Indie-Projekt von Yan Zhulanow vorgestellt wurde.

Geschrieben in Swift und vollständig nativ, vereint Marta orthodoxe Bedienphilosophie mit der Ästhetik und Performance moderner Apple-Systeme.

Marta

Das Zwei-Panel-Layout steht im Fokus, unterstützt durch eine konfigurierbare Statusleiste und eine leistungsfähige Kommandozeile. Klassische OFM-Funktionstasten werden weitgehend unterstützt.

Ein modular aufgebautes Plugin-System, das derzeit auf Lua-Basis entwickelt wird, erlaubt die individuelle Erweiterung der Funktionalität. Daneben existiert seit der ersten Version eine Swift-API.

Bereits integriert ist eine Unterstützung für Archivformate wie ZIP, TAR, RAR und 7z, die sich direkt als virtuelle Verzeichnisse öffnen lassen.

Für den komfortablen Zugriff auf häufig verwendete Pfade stehen Favoriten sowie eine durchsuchbare Verlaufsfunktion zur Verfügung. Ein integriertes Terminal ist vorhanden und kann optional angezeigt bzw. versteckt werden.

Die Konfiguration erfolgt über Marco-Dateien, ein für Marta entwickeltes Format, dass die Konfiguration allerdings unnötig umständlich erscheinen lässt.

Die Software ist kostenlos, wird aktiv weiterentwickelt und kann über die offizielle Webseite oder Homebrew bezogen werden.

Nimble Commander

Nimble Commander ist ein weiterer ressourcenschonender und klassisch orientierter Zwei-Panel-Dateimanager für macOS. Die Anwendung wurde in Objective-C++ entwickelt und ist nativ für macOS geschrieben.

Nimble Commander

Im Zentrum steht ein übersichtliches Zwei-Fenster-Layout, das Terminal-Fenster ist nicht in dieses integriert, sondern kann über das „View“-Menü als Overlay aktiviert werden.

Daneben stehen Funktionen zur Dateiverwaltung wie Suchen, Umbenennen oder die Arbeit mit Archiven zur Verfügung. Nimble Commander unterstützt viele Archivformate, darunter ZIP, TAR, GZ, BZ2 und weitere Formate.

Auch ermöglicht der Nimble Commander es, in den Admin-Modus zu wechseln und mit entsprechenden Rechten zu arbeiten.

Die Konfiguration bietet zahlreiche Anpassungsmöglichkeiten, von Tastenkürzeln über Dateitypen bis hin zum Erscheinungsbild.

Nimble Commander ist unter der GPL in Version 3 lizenziert, damit freie Software, und kann über die offizielle Webseite, den App Store oder Homebrew bezogen werden.

Windows

Nachdem DOS über Jahre hinweg als bevorzugte Plattform orthodoxer Dateimanager gedient hatte, erfolgte mit dem Aufstieg grafischer Betriebssysteme eine allmähliche Migration dieser Gattung in die Windows-Welt – meist als Neuentwicklungen mit vertrautem Bedienkonzept.

Altap Salamander

Der Altap Salamander wurde ursprünglich 1997 unter dem Namen Servant Salamander von Petr Šolín und Pavel Schreib veröffentlicht und zählt zu den ältesten grafischen orthodoxen Dateimanagern für Windows. Entwickelt in Tschechien, bot das Programm von Beginn an eine schlanke, schnelle Alternative zum Windows Explorer.

Der Altap Salamander unter Windows

Altap Salamander kombiniert klassische Zwei-Panel-Ansicht mit einer aufgeräumten und funktionalen Benutzeroberfläche.

Die integrierte Archivunterstützung erlaubt den direkten Zugriff auf Formate wie ZIP, RAR, ISO oder CAB. Mit eingebauten Clients für FTP, FTPS, SFTP und SCP können Dateioperationen auch im Netzwerk durchgeführt werden.

Werkzeuge zur Dateiverwaltung runden das Paket ab. Dazu gehören Funktionen zum Verzeichnisvergleich, zur Datei-Synchronisation sowie zur Berechnung und Prüfung von Prüfsummen und die Suche.

Ein interner Viewer unterstützt die Anzeige im Text- und Binärmodus, während der genutzte Editor sich frei konfigurieren lässt. Durch das Plugin-System lässt sich der Funktionsumfang erweitern.

Während der Dateimanager lange Zeit als Shareware vertrieben wurde, wurde er nach dem Kauf von Altap durch Fine zu freier Software. Die freigegebene Variante, genannt Open Salamander, findet sich auf GitHub und ist unter GPL in Version 2 lizenziert.

Derzeit ist keine aktive Weiterentwicklung erkennbar, was darauf hindeutet, dass das Projekt momentan pausiert.

Technisch gesehen ist die Anwendung ein Kind seiner Zeit: eine reine WinAPI-Anwendung, ohne moderne C++-Paradigmen wie RAII, Smart Pointers oder STL; dafür mit reichlich tschechischen Kommentaren im Code.

Bezogen werden kann der Altap Salamander über die offizielle Seite des Herstellers.

FreeCommander XE

FreeCommander XE ist ein orthodoxer Dateimanager für Windows, der seit den frühen 2000er-Jahren entwickelt wird.

Die Anwendung wurde von Marek Jasinski initiiert und richtet sich an Nutzer, die ein flexibles, Zwei-Panel-basiertes Werkzeug für Dateiverwaltung unter Windows suchen.

FreeCommander XE

FreeCommander XE wurde in Delphi entwickelt und läuft nativ unter Windows. Das Programm wird aktiv weiterentwickelt und ist sowohl als kostenlose Version als auch in einer Donator-Version verfügbar. Diese Donator-Version scheint aktuell die 64-Bit Version zu umfassen.

Die Oberfläche orientiert sich an klassischen Prinzipien orthodoxer Dateimanager, wurde aber mit modernen Windows-Elementen angereichert. Zwei horizontal oder vertikal teilbare Panels bilden das zentrale Layout. Tabs, anpassbare Toolbars und farbige Dateiansichten sorgen für Übersichtlichkeit.

Eine eingebaute Kommandozeile, Kontextmenüs und Drag & Drop sind ebenso vorhanden wie Einstellungen zur Nutzeranpassung.

Für die Organisation und den Abgleich von Dateien steht ein integriertes Tool für Dateivergleich und Verzeichnis-Synchronisation zur Verfügung.

Die Archivunterstützung umfasst gängige Formate wie ZIP, RAR, CAB und 7z. Der Zugriff erfolgt je nach Format direkt oder über externe Anwendungen.

Die Netzwerkfunktionen ermöglichen den Zugriff auf Netzwerkpfade, UNC-Freigaben sowie FTP- und SFTP-Server.

Ein interner Viewer erlaubt die Anzeige und Bearbeitung von Texten, Bildern und Daten. Als Editor wird eine externe Anwendung konfiguriert.

Ein Batch-Umbenennungstool mit Unterstützung für reguläre Ausdrücke ermöglicht das gleichzeitige Umbenennen vieler Dateien.

Die Anwendung ist Freeware und kann über die offizielle Webseite bezogen werden.

Total Commander

1993, ursprünglich als Windows Commander gestartet, musste Christian Ghisler das Programm nach einer Aufforderung von Microsoft aus markenrechtlichen Gründen umbenennen. Total Commander gilt als einer der bekanntesten orthodoxen Dateimanagern für Windows.

Total Commander

Die Oberfläche von Total Commander ist funktional und anpassbar. Die klassische Zwei-Panel-Ansicht lässt sich durch verschiedene Ansichtsmodi ergänzen, von einfachen Dateilisten bis zu detaillierten Spaltenansichten. Die Symbolleisten sind vollständig konfigurierbar, und Nutzer können praktisch jeden Aspekt der Oberfläche ihren Bedürfnissen anpassen.

Die integrierte Archiv-Unterstützung erlaubt den direkten Zugriff auf Formate wie ZIP, RAR, 7Z, TAR, GZ und viele weitere. Ein FTP/SFTP-Client ist ebenfalls integriert und unterstützt neben klassischem FTP auch FTPS, SFTP und WebDAV. Verbindungen können gespeichert, organisiert und über Bookmarks schnell aufgerufen werden.

Die Such- und Filterfunktionen bieten Unterstützung für reguläre Ausdrücke, Volltextsuche im Dateiinhalt und einen integrierten Duplikat-Finder. Zusätzlich erlauben Schnellfilter das sofortige Eingrenzen angezeigter Dateien in Echtzeit.

Ein integriertes Synchronisationswerkzeug unterstützt verschiedene Abgleichmodi, darunter bidirektionale und asymmetrische Synchronisation, während das Multi-Rename-Tool Funktionen zum gleichzeitigen Umbenennen von mehreren Dateien bietet.

Mit dem integrieren Viewer können Textdatei bis zu 8192 Petabyte betrachtet werden. Auch Bilder und Multimedia-Inhalte können direkt angezeigt werden.

Total Commander verfügt über ein umfangreiches Plugin-System, das verschiedene Plugin-Typen unterscheidet.

Packer-Plugins (WCX) erweitern die Unterstützung für Archivformate.

Dateisystem-Plugins (WFX) ermöglichen den Zugriff auf alternative Datenquellen außerhalb des regulären Dateisystems, etwa auf FTP-Server, WebDAV, Cloudspeicher, die Windows-Registry oder laufende Prozesse. Diese Ressourcen erscheinen innerhalb des Dateimanagers wie normale Verzeichnisse.

Lister-Plugins (WLX) ermöglichen die Anzeige spezieller Dateiformate im internen Betrachter, z. B. für Multimedia-, Office- oder CAD-Dateien.

Inhalts-Plugins (WDX) stellen zusätzliche Dateieigenschaften bereit, die z. B. in benutzerdefinierten Spalten angezeigt oder für Such- und Filterfunktionen verwendet werden können.

Bezogen werden kann Total Commander über die offizielle Webseite. Dort kann ebenfalls eine Lizenz erworben werden.

Plattformübergreifend OFMs

Neben den bisher vorgestellten orthodoxen Dateimanagern, die meist auf ein einzelnes Betriebssystem beschränkt sind, existieren auch plattformübergreifende Lösungen.

Double Commander

Double Commander, dessen erste Version 2006 erschien, versteht sich als plattformübergreifende Lösung eines orthodoxen Dateimanagers. Die in Object Pascal geschriebene Anwendung bietet native Binaries für Linux, macOS und Windows.

Double Commander unter macOS

Die Bedienelemente sind größer und klarer als bei vielen Konkurrenten, was der Benutzerfreundlichkeit zugutekommt, allerdings auch als klobig empfunden werden kann. Tabs ermöglichen das Arbeiten mit mehreren Verzeichnissen pro Panel.

Die Oberfläche ist anpassbar, vom Farbschemata über Symbolleisten hin zu Tastenkombinationen.

Die Archiv-Unterstützung umfasst eine breite Palette von Formaten wie ZIP, 7Z oder TAR.

Die erweiterte Suchfunktion erlaubt nicht nur Dateinamen- und Pfadsuche, sondern auch die Nutzung von regulären Ausdrücken sowie die Suche im Dateiinhalt.

Eine integrierte Synchronisationsfunktion mit grafischer Darstellung erleichtert das Vergleichen und Angleichen von Verzeichnissen.

Abgerundet wird der Funktionsumfang durch einen integrierten Viewer, der Texte, Bilder und Dateien anzeigen kann.

Der Dateimanager nutzt die Total Commander Plugin-API, sodass Total Commander-Plugins unter Windows auch im Double Commander genutzt werden können.

Der Double Commander ist unter der GPL in Version 2 lizenziert und kann über die offizielle Seite bezogen werden.

muCommander

muCommander ist ein plattformunabhängiger, Java-basierter orthodoxer Dateimanager, der 2002 veröffentlicht wurde. Er setzt auf ein klassisches Zwei-Panel-Layout und ist besonders für Nutzer interessant, die einen leichtgewichtigen Dateimanager auf unterschiedlichen Betriebssystemen wie Windows, Linux, macOS oder BSD nutzen möchten.

muCommander unter macOS

Zwei Panels stehen im Fokus, ergänzt durch eine Shell, Pfadleisten, Toolbar, Statusanzeigen und ein Menüband. Das Design lässt sich über verschiedene Styles konfigurieren, ist aber nicht auf native Optik ausgelegt.

Der Funktionsumfang umfasst integrierte Unterstützung für zahlreiche Netzwerkprotokolle wie FTP, SFTP, SMB, HTTP, Amazon S3 und Bonjour. Auch Archivformate wie ZIP, TAR, GZip und BZip2 werden unterstützt und lassen sich direkt wie normale Verzeichnisse durchsuchen.

Praktische Funktionen wie Favoriten und eine Verlaufsansicht erleichtern den Zugriff auf häufig verwendete oder zuletzt besuchte Pfade. Der integrierte Dateibetrachter erlaubt die Vorschau von Text-, Binär- und Bilddateien.

Das Programm ist unter der GPL lizenziert und wird aktiv als Open-Source-Projekt gepflegt. Es kann über die offizielle Webseite, oder je nach System über den Paketmanager bezogen werden.

Mobile Adaptierung

Neben orthodoxen Dateimanagern für Desktop-Systeme existieren auch Lösungen für mobile Systeme, allem voran Android.

Allerdings sind solche Dateimanager unter Android und iOS eher selten, da diese Plattformen restriktiver im Umgang mit dem Dateisystemzugriff und Benutzeroberflächenparadigmen sind.

So existiert eine Umsetzung des Total Commander für Android, welche als Freeware vertrieben wird.

Der Total Commander unter Android

Ein weiterer mobiler Vertreter findet sich mit dem Ghost Commander, welcher ebenfalls das OFM-Paradigma implementiert, dies allerdings noch konsequenter umsetzt.

Ghost Commander

iOS-Beschränkungen verhindern echte orthodoxe Implementierungen. App-Sandboxing und File-System-Zugriffsbeschränkungen machen die charakteristischen Features nur schwer umsetzbar.

Daneben stellt sich im mobilen Bereich die Frage nach der Sinnhaftigkeit solcher Implementierungen, da die Vorteile wie eine schnelle Bedienung über die Tastatur, wenn überhaupt, nur in bestimmten Setups zum Tragen kommen.

Fazit

Orthodoxe Dateimanager repräsentieren ein Konzept, das sich über fast vier Jahrzehnte bewährt hat. Ihre Effizienz, Konsistenz und Erweiterbarkeit machen sie zu unverzichtbaren Werkzeugen für Power-User, Entwickler und Systemadministratoren.

Die Philosophie der tastaturorientierten, effizienten Dateiverwaltung bleibt relevant für all jene, die täglich mit großen Mengen von Dateien arbeiten müssen.

Besonders interessant ist, dass trotz des Alters dieses Konzepts die Entwicklung sehr aktiv ist. Heutige Implementierungen werden kontinuierlich weiterentwickelt und an aktuelle Bedürfnisse angepasst.

Diese Einheitlichkeit im Bedienkonzept, bedingt durch die informelle Standardisierung, sorgt dafür, dass Nutzer beim Wechsel zwischen verschiedenen orthodoxen Dateimanagern kaum Einarbeitungszeit benötigen.

Welcher orthodoxe Dateimanager für wen geeignet ist, ist eine Frage der persönlichen Präferenz. Hier kann nach Betriebssystem vorselektiert werden und auch die Frage, ob es freie Software oder auch ein kommerzielles Produkt sein darf, entscheidet.

Gemeinsam haben alle hier vorgestellten Dateimanager eine gewisse Basisfunktionalität. Die Differenzierung der einzelnen Dateimanager fängt meist erst bei den komplexen Features an.

Während z. B. der Total Commander mit vielen Funktionalitäten glänzt und über ein reichhaltiges Pluginangebot verfügt, kann er für einige Nutzer altgebacken oder überladen wirken.

Nicht alle orthodoxen Dateimanager sind in die eigene Landessprache übersetzt, sodass auch dies ein Entscheidungskriterium sein kann.

Unter Linux bieten sich je nach gewählter Desktop-Umgebung der GNOME Commander oder Krusader an, während macOS mit Commander One, Marta und dem Nimble Commander über gut integrierte Dateimanager verfügt. Auch für Windows-Nutzer stehen mehrere orthodoxe Dateimanager zur Verfügung, die nativ auf dem System laufen.

Wer betriebssystemübergreifend unterwegs ist, kann auf Multiplattform-Manager wie den Double Commander oder den muCommander zurückgreifen.

Je nach individuellen Anforderungen kann auch die Nutzung terminalbasierter Varianten wie des Far Managers oder des Midnight Commander eine sinnvolle Alternative darstellen.

Welche Lösung am besten passt, lässt sich meist erst im praktischen Einsatz beurteilen; eine individuelle Erprobung ist daher unerlässlich.

Zusammenfassend lässt sich sagen, dass orthodoxe Dateimanager ein effizientes Arbeiten mit vielen Dateien und komplexen Verzeichnisstrukturen ermöglichen; ganz ohne den Umweg über mausgesteuerte Bedienkonzepte. Dies spart Zeit, schont die Nerven und steigert die Produktivität.

Dieser Artikel erschien ursprünglich auf Golem.de und ist hier in einer alternativen Variante zu finden.

Paketmanager – Software-Installation und Aktualisierung

Paketmanager haben den Prozess der Software-Installation und Aktualisierung vereinfacht und viele Probleme der Vergangenheit gelöst. Heute sind sie ein integraler Bestandteil vieler Systeme. Während der durchschnittliche Windows-Nutzer wahrscheinlich weniger mit der Begrifflichkeit eines Paketmanagers anfangen kann, sieht es bei Nutzern unixoider Systeme meist anders aus.

Vor allem bei Linux-Systemen sind sie ein essenzieller Bestandteil der allermeisten Distributionen und kommen hier in den unterschiedlichsten Formen vor. Mittlerweile haben sie sich allerdings darüber hinaus ausgebreitet und sind heute auch unter macOS und Windows zu finden.

Über diese Grenzen hinaus haben sich Paketmanager auch in anderen Bereichen etabliert hat, beispielsweise im Paket- und Abhängigkeitsmanagement innerhalb der Softwareentwicklung.

Unabhängig vom spezifischen Paketmanager folgen diese in der Regel einem ähnlichen Ablauf: Ein Nutzer beabsichtigt, eine Anwendung bzw. ein Paket zu installieren. Der Paketmanager identifiziert die erforderlichen Abhängigkeiten und installiert diese zusammen mit der gewünschten Software.

Definition

Doch was zeichnet einen Paketmanager aus? Grundsätzlich handelt es sich bei einem solchen um ein Werkzeug oder eine Sammlung an Werkzeugen, die dazu dient Software zu installieren, sie zu aktualisieren und wieder zu entfernen. Im Idealfall ist diese Entfernung rückstandslos. Auch die Konfiguration der Software ist eine Fähigkeit, welche von vielen Paketmanagementsystemen beherrscht wird.

Ziel ist es meist, die manuelle Installation und Verwaltung von Software unnötig zu machen, sodass diese im Idealfall immer über den Paketmanager bezogen werden kann.

Neben der eigentlichen Bereitstellung der gewünschten Software, ist ein wichtiger Teil des Paketmanagements die Installation und Verwaltung der Abhängigkeiten, welche von der Software benötigt werden. Dies umfasst beispielsweise die Handhabung verschiedener Versionen von Bibliotheken, die erforderlich sind, wenn mehrere installierte Anwendungen unterschiedliche Versionen einer Bibliothek benötigen.

Ein Paket umfasst in solchen Systemen, neben der eigentlichen Anwendung, eine Reihe von zusätzlichen Metadaten, welche als Informationen über das Paket und der Verwaltung dienen.

Daneben führen die Systeme Buch über installierte Software, was z. B. bei der Aktualisierung installierter Anwendungen von Belang ist.

Typen von Paketmanagern

Paketmanager lassen sich in verschiedene Typen einteilen. Einerseits existieren systemgebundene Paketmanager wie das Advanced Packaging Tool (APT), die integraler Bestandteil des jeweiligen Betriebssystems sind und eine konfliktfreie Installation von Anwendungen gewährleisten.

Ziel dieser Paketmanager ist die Softwareverwaltung für den Nutzer des Systems. Auch ist es bei diesen systemspezifischen Paketmanagern in den meisten Fällen so, dass Abhängigkeiten wie Bibliotheken im Idealfall nur einmal installiert werden.

Eine weitere Art von Paketmanagementsystemen sind App Stores. Hier steht jede Applikation für sich und wird mitsamt ihrer Abhängigkeiten installiert. Das bedeutet, dass z. B. Bibliotheken immer wieder mitgeliefert werden. Hier wird in der Theorie Speicherplatz verschenkt, da häufig verwendete Bibliotheken mehrfach vorhanden sein können.

Eine letzte und trotzdem in ihrer Wichtigkeit nicht zu unterschätzende Kategorie von Paketmanagern sind sprachspezifische Paketmanager. Bei diesen geht es um das Paket- und Abhängigkeitsmanagement von Bibliotheken im Rahmen der Softwareentwicklung. Beispiele für diese Manager sind Maven, Cargo und NPM. Sie werden vor allem in den vergangenen Jahren verstärkt eingesetzt. Einen Überblick über diese sprachspezifischen Paketmanager bietet die Webseite libraries.io.

Am Anfang war der Code

In frühen Systemen existierten keine Paketmanager im heutigen Sinne. Entweder wurden die mitgelieferten Systemwerkzeuge genutzt, oder die benötigte Software lag im Quelltext vor und wurde anschließend kompiliert und installiert.

Eine Applikation wird kompiliert

Im Laufe der Zeit wurden nicht nur die Systeme komplexer, sondern auch die auf ihr genutzten Anwendungen. Mithilfe von Build Automation Tools wie Make, wurde es möglich Software anhand des sogenannten Makefiles zu bauen. Allerdings wurde auch hier vorausgesetzt, dass die benötigten Abhängigkeiten auf dem System vorhanden waren.

Über den Befehl make kann der entsprechende Vorgang angestoßen werden. Damit vereinfachten Makefiles die Erzeugung der Software. Statt den Compiler, dazugehörige Linker und weitere Werkzeuge selbst aufrufen zu müssen, fungiert das Makefile als Mittler.

Abhängigkeiten

Im ersten Moment scheint es, als ob die Installation der Software aus dem Quelltext leicht von der Hand geht. Der Quelltext muss bezogen werden und anschließend kann die Applikation kompiliert und installiert werden.

Allerdings steht ein Programm meist nicht für sich, sondern ist auf gewisse Abhängigkeiten, wie verwendete Bibliotheken angewiesen. Sind diese Abhängigkeiten in einer falschen Version installiert, oder nicht vorhanden, schlägt die Erstellung der Applikation fehl.

Ein weiteres Problem ist, dass unixoide Systeme nicht unbedingt identisch sind und sich in kleineren und größeren Feinheiten unterschieden. Eine Lösung für diese Probleme bieten Werkzeuge wie autoconf vom GNU-Projekt und später CMake.

Über diese Build-Automatisierungstools wird das benötigte Makefile generiert, welches dann auf die Eigenheiten des eigentlichen Systems angepasst ist. So wird unter anderem überprüft, ob die benötigten Abhängigkeiten vorhanden sind und unter Umständen abgebrochen, wenn dies nicht der Fall ist.

Bislang nicht betrachtet wurde die Deinstallation einer Anwendung. Neben den eigentlichen Anwendungsdateien, eventuellen Bibliotheken und Konfigurationsdateien können hierzu auch Dateien zählen, welche während der Laufzeit der Anwendung erzeugt wurden.

Diese von Hand zu entfernen, ist im besten Fall ein zeitaufwendiger Prozess. Spätestens an dieser Stelle erweist sich ein funktionierendes Paketmanagementsystem als Segen.

Quell- vs. Binärpakete

Bei dem oben beschriebenen Verfahren wurde die Software direkt auf dem System kompiliert. Dies hat einige Vorteile. So kann die jeweilige Software mit entsprechender CPU-Optimierung kompiliert werden und somit optimal auf das System abgestimmt werden. Allerdings nimmt ein solcher Vorgang Zeit in Anspruch, vorwiegend bei der Kompilierung größerer Softwarepakete wie einem Browser.

Bei Paketmanagern wird hier die Unterscheidung zwischen Quell- und Binärpaketen getroffen. Quellpakete enthalten den Quellcode der Anwendung und werden direkt auf dem Rechner des Nutzers kompiliert.

Binärpakete hingegen enthalten eine vorkompilierte Anwendung, welche auf eine bestimmte Architektur optimiert ist. Damit muss das Paket nur noch vom Paketmanager heruntergeladen, entpackt und installiert werden. Neben der fehlenden Optimierung auf den konkreten CPU-Typ haben Binärpakete weitere Nachteile. Viele Anwendungen verfügen über bestimmte Schalter zu Compile-Zeit, um bestimmte Module und Funktionalitäten in die Anwendung zu integrieren. Ist dies während der Erstellung des Binärpaketes nicht geschehen, so kann das Modul bzw. die gewünschte Funktionalität nicht ohne Weiteres genutzt werden.

Anfänge der Paketmanager

Mit der Idee der Paketierung war der Gedanke zu einem Paketmanager nicht mehr weit. Auch wenn solche Manager unter Linux gängig wurden, gab es sie in Ansätzen bereits davor.

Einer der ersten Paketmanager war das System Management Interface Tool (SMIT) für AIX, welches mit der Version 3.0 von AIX im Jahr 1989 Einzug hielt. Unter der Oberfläche wurde für diese Aufgabe installp als Backend genutzt.

Im Linux-Bereich zählte das package management system (pms) zu den ersten Paketmanagern. Dieses erschien in Version 1.0 Mitte des Jahres 1994. Genutzt wurde dieses in der Distribution Bogus Linux. Dies führte historisch betrachtet unter anderem zum RPM-Paketmanager, welcher ursprünglich von Red Hat stammt und 1995 mit Red Hat Linux 2.0 ausgeliefert wurde.

In einen ähnlichen Zeitrahmen fallen die Entwicklung des Debian Package Managers, der vom StopAlop, einem weiteren Paketmanager aus der Frühzeit der Paketmanager, inspiriert wurde.

Die erste Version des Debian Package Managers wurde 1994 von Ian Murdock entwickelt, damals noch in Form eines Shellskriptes. Aus diesem entstand im Laufe der Jahre das dpkg der Neuzeit.

Aus diesen Low-Level-Paketmanagern entwickelten sich schließlich Systeme, welche Repositorys der verfügbaren Software bereithielten und diese zur Installation derselben nutzten, sodass auch das Problem der Paketbeschaffung bzw. der eigenen Paketierung in den meisten Fällen gelöst war.

Im Jahr 1995 begannen viele Paketmanager mit der Implementierung eines Workflows, der mit dem Herunterladen des Pakets beginnt und die automatische Auflösung sowie Installation von Abhängigkeiten beinhaltet.

Neben eigentlichen Applikationen wurden Systempaketmanager auch genutzt, um Bibliotheken und andere Funktionalität bestimmter Programmiersprachen wie Python über diese zu installieren. Heutzutage wird dies mehrheitlich über sprachspezifische Paketmanager gelöst.

Low-Level- und High-Level-Paketmanager

Werkzeuge wie dpkg, zählen wie oben bereits erwähnt zu den Low-Level-Paketmanagern. Zwar vereinfachen sie die Installation von Paketen, aber aus Sicht des Nutzers, sind immer noch viele manuelle Schritte notwendig, um das System auf einem aktuellen Stand zu halten.

Low-Level-Paketmanager samt Herkunft und High-Level-Paketmanager

Hier kommen High-Level-Paketmanager ins Spiel. Diese vereinfachen die Bedienung und dienen sozusagen als Frontend für den eigentlichen Nutzer. Daneben gruppieren sie Operationen der zugrundeliegenden Low-Level-Paketmanager.

Neben dem traditionellen Weg, Software als Archiv auszuliefern, wurde mit den Paketmanagern für die jeweiligen Distributionen ein zentrales Repository mit Software geschaffen, welches von der jeweiligen Distribution gepflegt wurde.

Interessant an diesem zentralen Repositorys ist, dass die Software, welche in diesen vorliegt, technisch betrachtet ein Fork der Originale ist. Der Vorteil dieser Vorgehensweise ist die Entkopplung, sodass eine Distribution eigene Aktualisierungen für eine Anwendung bereitstellen kann. Dies gilt auch für den Fall, dass die Software nicht mehr aktiv unterstützt wird.

Auch wenn von einem zentralen Repository die Rede ist, sieht es in den eigentlichen Distributionen meist etwas differenzierter aus. Unter Ubuntu z. B. existieren die Repositories Main, Universe, Restricted und Multiverse.

Das Main-Repository umfasst von Canonical unterstützte freie Software, die als grundlegend und essenziell für das System angesehen wird. Das Universe-Repository wird von der Community gepflegt und enthält ebenfalls freie Software, die von Nutzern beigetragen und verwaltet wird.

Im Restricted-Repository finden sich proprietäre Treiber für Geräte, die aus lizenzrechtlichen Gründen nicht im Main-Repository enthalten sind. Schließlich existiert noch das Multiverse-Repository, das Software beinhaltet, die durch Urheberrecht oder andere rechtliche Fragen eingeschränkt ist und deshalb spezielle Vereinbarungen für die Nutzung oder Verbreitung erfordert.

Daneben liegen für die unterschiedlichen Repositorys verschiedene Spiegelserver vor, welche die Pakete redundant und geografisch verteilt vorhalten.

Auch Abhängigkeiten werden von High-Level-Paketmanagern wesentlich sinnvoller behandelt. Während eine Paketinstallation per dpkg verlangt, dass alle Abhängigkeiten installiert sind, übernimmt apt diese Aufgabe automatisch. Hierbei werden die Abhängigkeiten in die korrekte Reihenfolge gebracht, bezogen und anschließend installiert.

Durch die zentralen Repositorys ist es über wenige Befehle möglich, den kompletten Softwarebestand zu aktualisieren. Auch der Wegfall von Abhängigkeiten wird bemerkt und so werden nicht mehr benötigte Pakete auf Wunsch automatisch deinstalliert.

Anatomie eines Paketmanagmentsystems

Einige Eigenschaften, welche ein Paket ausmachen, wurden bereits beschrieben. Trotzdem soll an dieser Stelle genauer auf die Anatomie eines Pakets und des Managementsystems dahinter eingegangen werden. Hierbei wird dpkg als Beispiel herangezogen.

Der Debian Package Manager ist dafür verantwortlich, ein Paket zu installieren und wieder zu deinstallieren. Hierzu wird die DEB-Datei, welche das Paket darstellt, im ersten Schritt entpackt und anschließend ein Pre-Install-Skript ausgeführt.

Nach dessen Ausführung werden die Komponenten des Paketes an die korrekten Stellen im Dateisystem kopiert und anschließend das Post-Install-Skript ausgeführt. Bei der Deinstallation läuft dieser Vorgang ähnlich ab. Auch hier werden wieder Pre– und Post-Remove-Skripte durchgeführt. Daneben verwaltet dpkg eine Datenbank der installierten Pakete.

Im Einzelnen besteht ein DEB-Paket aus dem sogenannten Debian-Binary. In dieser Datei ist die Version des Dateiformates hinterlegt. Dies sollte bei aktuellen Distributionen immer 2.0 sein. Trotz ihres Namens handelt es sich um eine gewöhnliche Textdatei.

Ein entpacktes DEB-Archiv mit dem control-Ordner

Anschließend folgen zwei Archive, eines für die Meta-Informationen und eines für die eigentlichen Daten. Bei den Archiven werden zwei unterschiedliche Archivierungsverfahren unterstützt. So kann im Falle des control-Archivs das Archiv als control.tar.gz oder control.tar.xz vorliegen.

Das control-Archiv enthält mehrere wichtige Dateien. Die erste Datei ist die Datei control. Diese enthält Informationen über das Paket wie Paketname, Version, Abhängigkeiten, Konflikte, Beschreibung und mehr.

Für das Paket nginx-common sieht diese Datei beispielhaft wie folgt aus:

Package: nginx-common
Source: nginx
Version: 1.24.0-2
Architecture: all
Maintainer: Debian Nginx Maintainers 
Installed-Size: 306
Depends: debconf (>= 0.5) | debconf-2.0, nginx (>= 1.24.0-2), nginx (<< 1.24.0-2.1~)
Suggests: fcgiwrap, nginx-doc, ssl-cert
Breaks: nginx (<< 1.22.1-8)
Replaces: nginx (<< 1.22.1-8)
Section: httpd
Priority: optional
Multi-Arch: foreign
Homepage: https://nginx.org
Description: small, powerful, scalable web/proxy server - common files
 Nginx ("engine X") is a high-performance web and reverse proxy server
 created by Igor Sysoev. It can be used both as a standalone web server
 and as a proxy to reduce the load on back-end HTTP or mail servers.
 .
 This package contains base configuration files used by all versions of
 nginx.

Daneben sind die entsprechenden Pre- und Postskripte enthalten (preinst, postinst, prerm, postrm). Diese Skripte werden verwendet, um spezielle Aufgaben auszuführen, die für das Paket notwendig sind, wie das Konfigurieren von Systemdiensten oder das Aktualisieren von Konfigurationsdateien.

Die Datei conffiles enthält eine Liste von Konfigurationsdateien, die vom Paketmanagementsystem während einer Aktualisierung behandelt werden, um benutzerdefinierte Änderungen zu erhalten.

Über die Datei md5sums, eine Liste von MD5-Prüfsummen für die Dateien, die im Paket enthalten sind, kann die Integrität dieser überprüft werden.

Der entpackte data-Ordner in einem DEB-Archiv

Die eigentlichen Daten des DEB-Archives finden sich im data-Archiv (data.tar.gz oder data.tar.xz). Dieses Archiv enthält die Dateien, die zum System hinzugefügt werden, wenn das Paket installiert wird. Die Dateien in diesem Archiv werden relativ zum Wurzelverzeichnis des Ziel-Dateisystems extrahiert.

Paketdatenbank

Neben den eigentlichen Paketen nimmt die Paketdatenbank einen großen Stellenwert ein. Die Paketdatenbank von Debian und darauf basierenden Distributionen wird von dpkg verwaltet und speichert Informationen über alle installierten, gelöschten oder sonst wie bekannten Pakete auf dem System. Die Datenbank befindet sich im Verzeichnis /var/lib/dpkg/ und besteht aus mehreren Dateien und Verzeichnissen, die verschiedene Aspekte der Paketverwaltung abdecken.

Die Datei /var/lib/dpkg/status enthält den aktuellen Status aller Pakete. Sie listet Pakete auf, die installiert sind, deren Installation erwartet wird, die zur Deinstallation oder vollständigen Entfernung markiert sind, und so weiter. Für jedes Paket enthält diese Datei Metadaten wie Version, Architektur, Abhängigkeiten, Beschreibung und vieles mehr.

Die Paketdatenbank des Debian Package Managers

Die Datei /var/lib/dpkg/available enthält Informationen über verfügbare Pakete, aus den Repositorys. Diese Datei wird z. B. durch den Befehl apt update aktualisiert.

Das Verzeichnis /var/lib/dpkg/info/ enthält spezifische Dateien für jedes Paket, wie Konfigurationsskripte. Diese Dateien werden von dpkg während der Installation und Deinstallation verwendet, um sicherzustellen, dass diese Prozesse korrekt durchgeführt werden.

Die Paketdatenbank wird von dpkg und anderen Frontends wie APT, Aptitude oder Synaptic verwendet, um Paketoperationen durchzuführen. Es ist wichtig, dass diese Datenbank konsistent und unbeschädigt bleibt, da Inkonsistenzen zu Problemen bei der Paketverwaltung führen können.

Die Konsistenz der Paketdatenbank in Debian-basierten Systemen wird durch eine Kombination aus Designentscheidungen, Dateisystemtransaktionen und Sperrmechanismen sichergestellt.

Welche Version darf es sein?

Eine Paketverwaltung im Distributionsumfeld, kann trotz ihrer Vorteile, einige Herausforderungen mit sich bringen. Je nach der Politik der gewählten Distribution kann es sein, dass nur bestimmte und unter Umständen veraltete Versionen gepflegt werden. Dies ist z. B. bei Debian Stable der Fall, während bei anderen Distributionen wie bei Arch Linux immer die neusten Anwendungen, dank des Rolling Releases-Prozesses, mitgeliefert werden.

Die Nutzung eines Paketmanagers kann dazu führen, dass Nutzer weniger Kontrolle über spezifische Konfigurationen der installierten Software haben, da viele Einstellungen bereits festgelegt wurden.

Die Sicherheit hängt zudem von der Vertrauenswürdigkeit der Softwarequellen, den sogenannten Repositorys, ab. Eine Kompromittierung eines Repositorys kann die Verbreitung schädlicher Software begünstigen. Trotz verschiedener Sicherheitsmaßnahmen kann ein solches Risiko nicht gänzlich ausgeschlossen werden.

Paketmanager je Betriebssystem

Neben der grauen Theorie werden Paketmanager natürlich auch genutzt. Hierfür stehen je nach Betriebssystem unterschiedlichste Paketmanager zur Verfügung, von deinen einige nachfolgend vorgestellt werden sollen.

Linux

Unter Linux existieren eine Vielzahl an Paketmanagern. Zu den häufigeren verwendeten gehört sicherlich dpkg mitsamt seiner Frontends, wie APT. Auf Debian basierende Distributionen wie Ubuntu nutzten dieses System ebenfalls.

Ein weiterer bekannter Paketmanager ist RPM, welcher unter anderem bei Red Hat Linux zum Tragen kommt. RPM steht hierbei für RPM Package Manager, welcher ursprünglich als Red Hat Package Manager bezeichnet wurde.

Im Laufe der Zeit wurde der RPM Package Manager weiterentwickelt und verbessert. Das RPM-Format selbst wurde standardisiert, und es wurden Werkzeuge wie YUM (Yellowdog Updater, Modified) und später DNF (Dandified Yum) entwickelt, die als Frontends für RPM dienen und zusätzliche Funktionen wie einfachere Abhängigkeitsauflösung und automatische Updates bieten.

Daneben existieren weitere Paketmanagementsysteme wie Pacman unter Arch Linux. Üblicherweise ist das Paketverwaltungssystem eines der Systeme, die näher betrachtet werden, wenn sich intensiver mit einer Distribution auseinandersetzt wird.

Neben diesen gewöhnlichen Paketmanagern gibt es auch neue Konzepte, wie Nix und NixOS, welche deklarative Ansätze für die Paketverwaltung nutzen.

Snap, Flatpak und Co.

In der Linux-Welt sind zusätzlich zu den Systempaketmanagern weitere Paketformate entstanden, die darauf abzielen, Softwarepakete unabhängiger von den einzelnen Distributionen zu gestalten.

Unter Ubuntu ist das Snap-Format stark vertreten, bei anderen Distributionen hingegen Flatpack. Snap und Flatpak sind moderne Paketmanagement- und Bereitstellungssysteme, die das Ziel haben, die Installation und Verwaltung von Software auf Linux-Systemen zu vereinfachen und zu vereinheitlichen. Sie ergänzen traditionelle Paketmanager wie APT und bieten einige Vorteile.

Snap ist ein Paketformat, das von Canonical entwickelt wurde. Snap-Pakete sind in sich geschlossene Softwarepakete, die alle notwendigen Abhängigkeiten enthalten, um auf einer Vielzahl von Linux-Distributionen zu laufen. Das Snap-System verwendet ein zentrales Repository namens Snap Store, in dem der Nutzer Software suchen und installieren kann.

Snaps sind in der Regel größer als traditionelle Pakete, da sie alle Abhängigkeiten enthalten, bieten dafür aber andere Vorteile. So laufen Snaps in einer Sandbox-Umgebung, die die Sicherheit erhöht, indem sie den Zugriff der Anwendung auf das System beschränkt.

Durch den Dienst snapd, werden Snaps automatisch aktualisiert, was die Wartung vereinfacht. Aus Entwicklersicht können Anwendungen leichter veröffentlicht und aktualisiert werden, da nicht diese nicht auf die Paketverwaltung der einzelnen Distributionen angewiesen sind.

Flatpak ist ein ähnliches System, entwickelt von der unabhängigen Community. Es zielt ebenfalls darauf ab, distributionsübergreifend Software bereitzustellen und verwendet für die Verteilung von Softwarepaketen sogenannte Remotes wie Flathub. Flatpaks können auf einer Vielzahl von Linux-Distributionen laufen. Ähnlich wie Snaps bieten Flatpaks eine Sandbox-Umgebung, die die Sicherheit verbessern soll.

Beide Systeme, Snap und Flatpak, tragen in der Theorie dazu bei, die Fragmentierung im Linux-Ökosystem zu verringern und die Softwareverteilung zu vereinfachen. Sie bieten eine Plattform für Entwickler, um ihre Anwendungen einem breiteren Publikum zur Verfügung zu stellen. Der Nutzer kann über diese Systeme Anwendungen unabhängig von der spezifischen Linux-Distribution installieren.

AppImage ist ein weiteres Format für portable Softwarepakete unter Linux. Im Gegensatz zu Snap und Flatpak wird bei AppImages keine Installation durchgeführt. Stattdessen sind AppImages eigenständige ausführbare Dateien, die alle Abhängigkeiten enthalten und direkt ausgeführt werden können.

macOS

Unter macOS existieren neben dem integrierten App Store, welcher 2011 eingeführt wurde, weitere Paketmanager, bei denen es sich um Community-Projekte handelt.

Der App Store unter macOS

Der App Store selbst ist im Gegensatz zu seinem iOS-Pendant nicht verpflichtend zu nutzen. Auch wenn unsignierte Software mittlerweile nur nach einigen Warnmeldungen gestartet werden kann.

Bei den Community-Projekten stechen die Werkzeuge MacPorts und Homebrew hervor. MacPorts, früher unter dem Namen DarwinPorts bekannt, ist seit 2002 verfügbar und liegt mittlerweile in Version 2.8.1 vor.

MacPorts ist darauf ausgelegt, für jeden Port alle Abhängigkeiten selbst aus dem Quelltext zu kompilieren und zu verwalten. Dies führt zu einer größeren Isolation und Konsistenz, kann aber auch die Nutzung von mehr Speicherplatz und längere Installationszeiten bedeuten.

Der Paketmanager Homebrew wurde 2009 von Max Howell entwickelt. Homebrew versucht, wo möglich, vorhandene Systembibliotheken zu nutzen und installiert nur Abhängigkeiten die darüber hinaus benötigt werden. Dies kann zu schnelleren Installationen führen, birgt aber auch das Risiko eines Konfliktes mit Systembibliotheken.

Homebrew wird oft als benutzerfreundlicher wahrgenommen, mit einfacheren Befehlen und einer einfacheren Installation. Daneben verfügt es über eine breite Unterstützung für Binärpakete, die auf eine schnelle Installation abzielen und das Softwareangebot erweitern.

Die Anwendung der jeweiligen Paketmanager bleibt hierbei dem Nutzer überlassen, je nach dem gewünschten Anwendungszweck. So benötigt MacPorts Administratorrechte, während Homebrew in den meisten Fällen ohne solche auskommt. Genutzt werden beide Paketmanager über das Terminal.

Windows

An Windows ist der Erfolg der Paketmanager ebenfalls nicht vorbeigegangen. So wurde schon seit Windows Vista die Applikation Pkgmgr.exe mitgeliefert. Dabei handelte es sich um einen Paketmanager zur Installation und Deinstallation von Paketen.

Allerdings war dieser Paketmanager nicht für den Nutzer des Systems gedacht. Stattdessen diente er dazu, Komponenten des Betriebssystems zu installieren. Später wurde dieses System insbesondere durch DISM (Deployment Image Servicing and Management) abgelöst.

Neben dem Microsoft Store, welcher als App Store fungiert, existieren auch für Windows eine Reihe von Community getriebenen Paketmanagern. Hier wären unter anderem Chocolatey und Scoop zu nennen. Microsoft hat mit dem Windows Package Manager (winget) ebenfalls einen solchen Paketmanager vorgestellt. Eine detaillierte Betrachtung dieser Paketmanager findet sich auf Golem.de.

Daneben existieren auch Client-Managment-Plattformen, wie ACMP, welche für die Nutzer die Softwareinstallation aus einem Katalog ermöglichen und meist im geschäftlichen Umfeld zu finden sind.

Mobile Systeme

Während Systeme wie die PDAs von Palm überwiegend von Hand mit Apps bestückt wurden, sah dies bei den großen mobilen Systemen der Neuzeit, namentlich Android und iOS anders aus. Hier gab es bereits zu Beginn entsprechende
App Stores.

Google Play

Unter Android war dies der Android Market, welcher schließlich in Google Play aufging, unter iOS der App Store, welcher mit der Version iOS 2 (iPhone OS 2.0) seinen ersten Auftritt hatte.

Software kann über diese App Stores installiert, aktualisiert und deinstalliert werden. Im Unterschied zu reinen Paketmanagement-Lösungen bieten diese App Stores zusätzliche Dienste. Sie wickeln unter anderem Zahlungen ab, was sowohl In-App-Käufe als auch Abonnements einschließt.

Im Android-Bereich existieren daneben weitere alternative App Stores, wie der F-Droid App Store, welcher auf freie Software spezialisiert ist. Unter iOS ist dies bislang nicht ohne Jailbreak möglich. Dies soll sich allerdings durch den Digital Markets Act in der EU ändern.

Auch andere mobile Ökosysteme nutzen ihre jeweiligen App Stores wie Amazon, Samsung und Huawei.

Fazit

Ian Murdock, einer der Mitbegründer des Debian-Projektes, nannte Paketmanager einmal den größten einzelnen Fortschritt, welchen Linux der Industrie bescherte.

Sie erleichtern die Handhabung von Abhängigkeiten und Kompatibilitätsproblemen, die sonst für den Nutzer eine Herausforderung darstellen könnten. Mit dieser Idee haben sie viele Domänen erobert.

So begegnet uns das Konzept der Paketierung immer wieder, z. B. bei Docker-Containern. Auch bei neuen Programmiersprachen, wie Rust, wird das Paketmanagement gleich mitgedacht.

Paketmanager nehmen eine wichtige Rolle ein, indem sie die Installation, Aktualisierung und Entfernung von Softwarepaketen auf effiziente und benutzerfreundliche Weise ermöglichen und uns so auch in Zukunft begleiten werden.

In Zukunft wird auch verstärkt der Fokus auf unveränderliche Systeme und containerisierte Anwendungen gerichtet sein. Dieser Ansatz hat in jüngster Zeit mit Technologien wie Podman und Co. den Weg zurück auf den Desktop gefunden und spiegelt die wachsende Präferenz für isolierte, konsistente und portable Anwendungsumgebungen wider.

Dieser Artikel erschien ursprünglich auf Golem.de und ist hier in einer alternativen Variante zu finden.

State of Matter

Der Smarthome-Standard Matter ist gekommen, um den Markt aufzurollen. Doch wie sieht es mit der Umsetzung aus und kann der Standard seinem Versprechen gerecht werden?

Nachdem der Standard, knapp drei Jahre in der Entwicklung war, wurde er schlussendlich im November 2022 offiziell auf einem Launch-Event in Amsterdam vorgestellt.

Bereits damals kündigten viele Hersteller ihre Unterstützung an. In der sich für den Matter-Standard zuständig zeichnenden Connectivity Standards Alliance (CSA), finden sich über 500 Firmen, die unter dem Dach der Organisation vereint sind.

Darunter sind klingende Namen, wie Amazon, Apple, Google, Nordic Semiconductor, NXP Semiconductors, Samsung, Silicon Labs und viele mehr. Doch wie sieht es aus mit der Unterstützung des Standards?

Android und iOS

Matter unterstützt sogenannte Multi-Admin-Funktionalität. Dies bedeutet, dass eine Matter-Installation von unterschiedlichsten Geräten gesteuert werden kann. Für diese Steuerung wurde in unterschiedlichste Betriebssysteme mittlerweile entsprechende Unterstützung eingebaut. Diese wird meist im Rahmen der jeweiligen Smarthome-Strategie der Hersteller ausgestaltet.

So ist die Matter-Unterstützung unter iOS in die Home-App integriert. Eingeführt wurde diese Unterstützung mit der Version 16.1 von iOS. Mit diesen Updates im Oktober 2022, wurden auch andere Systeme wie watchOS mit einer Matter-Unterstützung versehen.

Unter Android wurde die Unterstützung für Matter ab Version 8.1 eingeführt, sofern die Play-Dienste ab Version 22.48.14 installiert sind. Auch hier kann das Smarthome unter Nutzung des Matter-Standards über die Home-App genutzt werden.

Smarthome-Ökosysteme

Interessant ist auch die Unterstützung der jeweiligen Home-App von Google und Apple auf dem Konkurrenzsystem. So sind die Home-Apps von Apple und Google auch auf Android respektive iOS verfügbar und unterstützen dort ebenfalls den Matter-Standard.

Andere Ökosysteme für Smarthomes sind mittlerweile ebenfalls auf den Matter-Standard angepasst. So unterstützt SmartThings von Samsung seit einiger Zeit Matter unter iOS und Android. Allerdings ist diese Unterstützung nicht komplett. So werden unter anderem Bridges, welche im Matter-Standard vorgesehen sind, durch die App noch nicht unterstützt.

Bridges dienen zur Anbindung von nicht direkt kompatiblen Systemen, an ein Matter kompatibles System. Ein solche definiert sich im Standard dadurch, dass sie ein Matter-Knoten darstellt, welcher ein oder mehrere Nicht-Matter-Geräte darstellt.

Die Alexa-App unterstützt, analog zu den anderen Systemen, seit einiger Zeit den Matter-Standard. Dies ging einher mit der Aktualisierung vieler Alexa-Echo-Geräte, insbesondere in den neuen Generationen der Gerätereihe. Mit Home Assistant verfügen Open Source-Lösungen mittlerweile auch über Unterstützung für Matter.

Border-Router und Controller

Bei Matter wird für die Kommunikation der Geräte untereinander Wi-Fi, Ethernet oder Thread benutzt; für die Kommissionierung Bluetooth LE. Näheres dazu findet sich im entsprechenden Hintergrundartikel.

Ein komplexes Matter-Netzwerk

Thread versteht sich als selbstheilendes Mesh-Netzwerk. Es ist darauf ausgelegt, Geräte miteinander zu verbinden, welche eine geringe Datenrate benötigen und möglichst wenig Energie verbrauchen sollen. Das Protokoll besticht durch sein simples Design und ermöglicht niedrige Latenzen.

Basierend auf IPv6 wird somit bei Matter ein Netz gebildet, über welches die unterschiedlichen Geräte miteinander kommunizieren. Zur Anbindung eines Thread-Netzwerks an das Matter-Ökosystem werden Border-Router benötigt, welche die Verbindung zum hauseigenen LAN herstellt.

In vielen Haushalten müssen diese allerdings nicht extra angeschafft werden, da bestehende Geräte, wie einige Smart-Speaker von Amazon, per Update zu solchen Border-Routern aktualisiert werden konnten.

Hintergrund hierfür ist, dass Thread auf IEEE 802.15.4 aufsetzt, bei welchem es sich um einen Standard für kabellose Netzwerke mit geringen Datenraten handelt. In IEEE 802.15.4 ist die Bitübertragungsschicht (Physical Layer) und die Data-Link-Schicht definiert.

Neben Thread setzt unter anderem auch ZigBee, ebenfalls ein Mesh-Protokoll, auf IEEE 802.15.4 auf, was eine Aktualisierung solcher Geräte, hin zu Thread, perspektivisch möglich macht. Damit sind viele Funkchips welche ZigBee unterstützen in der Theorie für Thread geeignet.

Apple hat die Unterstützung für Matter mit der HomePod-Version 16.1 implementiert. Auch der Apple TV kann in bestimmten Generationen als Border-Router verwendet werden. Aktuell werden der Apple TV 4K in der zweiten und dritten Generation neben dem HomePod Mini und dem HomePod in der zweiten Generation unterstützt.

Bei Amazon wurde mittlerweile eine kleine Armada an Geräten mit einer Matter-Unterstützung ausgestattet. So unterstützt der Echo der vierten Generation die Thread-Funktechnik und kann als Border-Router verwendet werden. Daneben können die Geräte Echo, Echo Plus und die Echo Dot-Serie als Matter-Controller verwendet werden. Hier wird gewöhnlich ab der zweiten und dritten Generation der Geräte eine Unterstützung geliefert.

Die eero-Router, hergestellt von einer Tochterfirma von Amazon, können als Border-Router genutzt werden. Hier findet sich eine entsprechende Unterstützung in den Modellen eero 6, eero 6+, eero Pro, eero Pro 6E und eero Pro 6.

Google verfügt über eine Reihe von Geräten, welche mittlerweile Matter unterstützen und als Border-Router genutzt werden können. So werden die Smart-Speaker Google Home, Google Home Mini, Nest Mini, Nest Audio und die Displays Nest Hub (1. Generation), Nest Hub (2. Generation) und der Nest Hub Max unterstützt. Auch der Nest Wifi Pro (Wi-Fi 6E) Router verfügt über eine entsprechende Unterstützung.

Neben den Geräten von Big Tech, finden sich in vielen Haushalten, Router der Firma AVM, namentlich die FRITZ!Box. Die neuen Modelle 5690 XGS & 5690 Pro, welche noch in diesem Jahr erscheinen sollen, verfügen neben dem von AVM bevorzugten DECT ULE auch über Unterstützung für ZigBee. Basierend auf dieser Möglichkeit, soll eine spätere Matter-Unterstützung Einzug halten. Das FRITZ!Smart Gateway soll in Zukunft ebenfalls Unterstützung für Matter erhalten.

Daneben finden sich einige andere Hersteller, welche mittlerweile entsprechende Unterstützung bzw. Border-Router liefern, namentlich der Aeotec Smart Home Hub, einige Geräte der Nanoleaf-Produktpalette und der Samsung SmartThings Hub in Version 3.

Bei anderen Geräten, wie dem Dirigera-Hub von Ikea, fehlt eine angekündigte Unterstützung immer noch.

Hardware

Doch wie sieht es bei den Herstellern der eigentlichen Smarthome-Geräte aus? Erst durch sie wird das Smarthome steuer- und erfahrbar. Neben den Konzernen Apple, Amazon und Google, welche sich in vielen Fällen mit entsprechender Software-Unterstützung und dem Bau von Border-Routern und Controllern beschäftigen, existieren auch die Firmen, welche Sensoren und Aktoren liefern.

In diesem Feld sind unter anderem Aeotec, Eve Systems, Signify und einige andere Anbieter unterwegs. Dagegen haben Hersteller, wie Belkin, ihre Unterstützung für Matter mittlerweile zurückgezogen.

Ein Sensor von Fibaro

Firmen wie Fibaro, haben sich trotz einer großen Auswahl an Smarthome-Produkten bisher nicht zu Matter geäußert. Doch wie sieht es bei den Herstellern im Einzelnen aus?

Aeotec

Aeotec, hervorgegangen aus den Aeon Labs, ist mittlerweile eine Firma mit Hauptsitz in Hamburg. Bekannt geworden ist die Firma primär durch Smarthome-Geräte, welche den Z-Wave-Standard unterstützten.

Mit dem Aeotec Smart Home Hub liefert Aeotec einen zu Matter und dem Thread-Funkstandard kompatiblen Hub. Der ZigBee-Stick, mit dem Namen Zi-Stick, soll in Zukunft, per Update, auch das Thread-Protokoll unterstützen.

Ansonsten setzen die Aktoren und Sensoren von Aeotec nicht auf Matter, sondern auf das Z-Wave-Protokoll und die entsprechende Funktechnik auf.

Eltako

Im professionellen Bereich bietet die Firma Eltako mittlerweile Matter zertifizierte Geräte an. Hier handelt es sich unter anderem um Beschattungsaktoren, ein Stromstoß-Schaltrelais und Dimmaktoren.

Damit ist es möglich, bestehende Installationen über Matter einzubinden. Neben der Matter-Integration verfügen sie unter anderem über eine REST-API, sowie eine Apple Home-Integration.

Eve Systems

Eve Systems, früher als Elgato Systems bekannt, bietet Smarthome-Geräte für unterschiedlichste Bereiche an. Mittlerweile werden von der Firma auch erste Matter-Geräte angeboten.

Der Bewegungssensor Eve Motion

Darunter fallen die schaltbare Steckdose Eve Energy, die Kontaktsenoren Eve Door & Window und der Bewegungssensor Eve Motion. Teilweise agieren die Geräte als Matter-Controller sowie als Border-Router für das Thread-Protokoll.

Die Produkte Eve Shutter Switch und Eve Flare unterstützen bereits das Thread-Protokoll und sollen mit einem späteren Update, entsprechende Matter-Unterstützung erhalten. Das Gleiche soll auch für die Produkte Eve MotionBlinds, Eve Thermo, Eve Light Switch, Eve Weather und Eve Room gelten. Für diese Geräte war eine entsprechende Unterstützung bis Ende 2022 angekündigt, wurde allerdings bisher noch nicht ausgeliefert.

Govee

Govee ist seit 2017 im Smarthome-Bereich tätig und hat unterschiedlichste Produkte wie LED-Streifen und Sensoren im Angebot. Bekannt geworden sind sie auch durch eine kurzzeitige Auslistung bei Amazon, was wohl auf das Verpackungsdesign einiger Produkte zurückzuführen war. Diese besaßen eine auffällige Ähnlichkeit mit den Philips Hue-Produkten von Signify.

Mit dem Govee RGBIC LED Strip M1 hat Govee mittlerweile sein erstes Matter fähiges Produkt auf den Markt gebracht.

Leviton

Der nordamerikanische Hersteller Leviton, ist in Europa, aufgrund seines Zuschnitts auf den amerikanischen Markt, eher weniger bekannt. Dafür liefert er in seiner Heimat entsprechende Hardware mit Matter-Unterstützung.

Zu dieser gehört ein Smart Switch, eine schaltbare Steckdose und einige Dimmer. Konkret sind dies die Geräte Smart Wi-Fi 2nd Gen D26HD Dimmer, D215S Switch, D215P Mini Plug-In Switch und der D23LP Mini Plug-In Dimmer, welche über ein entsprechendes Firmware-Update aktualisiert werden können.

Andere Geräte von Leviton, sollen in Zukunft per Update in den Genuss einer Matter-Unterstützung kommen.

Nanoleaf

Nanoleaf wurde 2012 gegründet und finanzierte erste Produkte über Kickstarter. Mittlerweile liefern sie eine Reihe von ausgefallenen Beleuchtungslösungen.

Nanoleaf stellt ungewöhnliche Beleuchtungslösungen her

Neue Produkte, wie der Essentials Matter Lightstrip und die Essentials Matter Smart Bulb, sind von Werk aus mit einer Matter-Unterstützung versehen und können in entsprechende Ökosysteme eingebunden werden.

Bestehende Produkte der Essentials-Reihe können nicht per Update auf den Matter-Standard gehoben werden, da dies seitens der Hardware nicht unterstützt wird. Ob die Produktreihen Elements, Lines und Shapes eine entsprechende Aktualisierung auf Matter erhalten ist zurzeit noch unklar. Angebunden werden diese Systeme per WLAN. Daneben arbeiten diese Geräte bereits heute als Thread-Border-Router.

Signify

Das unter der Marke Philips vertriebene Lichtsystem Hue, ist bereits seit 2012 auf dem Markt. Entwickelt und vertrieben wird es von dem mittlerweile unabhängigen Unternehmen Signify, welches früher unter dem Namen Philips Lighting firmierte.

Das System, welches auf ZigBee basiert, ist so zumindest funktechnisch unter Umständen auf Thread aktualisierbar. Die Leuchtmittel sollen allerdings nach Aussage von George Yianni, seines Zeichens Head of Technology Philips Hue bei Signify nicht auf Thread aktualisiert werden.

Hier wird seitens Signify die Strategie gefahren, nur den Hue Hub mit einer Matter-Unterstützung zu versehen. In der FAQ wird dies wie folgt beschrieben:

Alle Philips Hue Lampen und intelligentes Zubehör wie der Hue Dimmschalter und Hue Smart Button funktionieren mit Matter, wenn sie über die Philips Hue Bridge verbunden sind. Die einzigen Ausnahmen sind die Philips Hue Play HDMI-Sync Box und der Tap Dial Switch.

Auch dieses Update lässt allerdings noch auf sich warten, bzw. findet sich in einer Beta-Version, welche für Entwickler freigegeben wurde.

Der Hintergrund für diese Herangehensweise ist, dass die Hue-Bridge nicht nur als einfache Verbindung zwischen dem WLAN und den angeschlossenen ZigBee-Geräten gesehen wird, sondern als Zentrale für Abläufe und Automatisierungen.

Solche Funktionalitäten sollen nicht direkt in die Leuchtmittel eingebaut werden. Es wird befürchtet, damit die Komplexität des Systems zu erhöhen. Auch die Entscheidung, die Geräte mittelfristig nicht auf Thread umzurüsten, wird entsprechend begründet. Hier wird argumentiert, dass das entsprechende Mesh-Netzwerk über ZigBee im Laufe der Jahre produktionsreif gemacht wurde. Bei Thread steht die Befürchtung im Raum, dass hier noch viele Kinderkrankheiten und Inkompatibilitäten zu beheben sind, bis ein vergleichbarer Stand, wie mit der aktuellen Implementierung erreicht werden kann.

Mittlerweile ebenfalls zu Signify gehörend ist das ehemalige Start-up Wiz, welches auch Beleuchtungslösungen anbietet. Diese werden per WLAN angebunden und arbeiten ohne Bridge.

Bei Wiz wird Matter bei Leuchtmitteln und Smart Plugs, welche ab dem zweiten Quartal 2021 produziert worden sind, unterstützt. Die entsprechenden Updates für die meisten Bestandsgeräte sind hierbei mittlerweile erschienen.

SwitchBot

Die 2016 gegründete Firma befasst sich mit der Entwicklung von Smarthome-Geräten, wie Schlössern, Kameras und Schaltern.

Mit dem SwitchBot Hub 2 brachte sie ihr erstes Matter fähiges Produkt auf den Markt. Über diesen können andere Geräte wie SwitchBot Curtain ebenfalls per Matter angebunden werden.

Weitere Produkte sollen folgen, sind aber im Moment noch in Entwicklung. Hier sind Erscheinungstermine für das dritte und vierte Quartal 2023 anvisiert.

TP-Link

Neben Netzwerkprodukten bietet der chinesische Hersteller TP-Link mittlerweile auch eine Palette von Smarthome-Produkten an. Diese firmieren unter den Marken bzw. Unternehmen Tapo und Kasa.

Anfang des Jahres wurde mit dem Tapo P125M, einer schaltbaren Steckdose, ein Matter fähiges Produkt aus dieser Produktreihe vorgestellt.

In Zukunft sollen Matter-Updates für weitere Steckdosen, Schalter, Leuchtmittel und Thermostate erscheinen.

Tridonic

Tridonic, eine zur Zumtobel Group gehörende Firma, ist vorwiegend im professionellen Bereich bekannt. Auch hier wird an Matter-Lösungen gearbeitet, bzw. solche werden angeboten.

Die Matter-Produkte von Tridonic

Hierbei werden ein Wireless Matter Treiber, mit 24 V Konstantspannung, erhältlich in 35 W, 60 W, 100 W, 150 W, sowie ein Wireless Matter to DALI Passivmodul und ein Wireless Matter to DALI SR Modul angeboten. Über die Wireless-Module können bestehende Systeme nachgerüstet und somit Beleuchtungen Matter fähig gemacht werden.

Angebunden sind die Module per Thread. Für diese Module wurden Updates angekündigt, welche unter anderem die Änderung der Farbtemperatur möglich machen sollen, sobald dies vom Matter-Standard unterstützt wird.

Xiaomi

Unter der Marke bzw. der Tochterfirma Aqara bietet Xiaomi mittlerweile ebenfalls Matter kompatible Geräte an.

So unterstützt der Hub M2, ab der Firmware Version 4.0.0 Matter in einer Betaversion. Dabei dient dieser dann auch als Bridge, für Nicht-Matter-Geräte, wie die angeschlossenen ZigBee-Geräte. Das Update dient der Einbindung des Hubs in Matter-Umgebungen, ändert allerdings nichts am verwendeten Funkstandard im Hub selbst. Auch der Hub M1S wurde mittlerweile mit einem entsprechenden Update versehen, welches die Matter-Unterstützung im Beta-Stadium nachrüstet.

Neben diesen Hubs existieren im Portfolio von Aqara einige andere Hubs, wie der Hub E1 oder die Camera Hub-Serie. Auch diese sollen perspektivisch Updates für Matter erhalten. Angekündigt waren diese Updates für den Lauf des Jahres 2023.

Allterco

Während die Firma Allterco den wenigsten ein Begriff ist, sieht es bei der Marke Shelly anders aus. Unter dieser werden günstige Smarthome-Komponenten wie schaltbare Steckdosen, Unterputzschalter, Sensoren und einige andere Produkte angeboten.

Der Shelly Plug S

Angesteuert werden die Geräte meist per WLAN oder Bluetooth. Für die Produkte der Plus- und Pro-Reihe wurde Unterstützung für Matter für das zweite Quartal 2023 angekündigt. Allerdings wurde die Veröffentlichung zu diesem Zeitpunkt wieder abgesagt und auf die Zukunft verschoben. Damit ist unklar, wann mit ersten Matter-Geräten unter der Marke Shelly zu rechnen ist.

Bosch

Die Firma Bosch mischt beim Smarthome mit dem System Bosch Smart Home mit. Anfang des Jahres wurde angekündigt, dass das System kompatibel mit dem Matter-Standard sein wird.

So wurde mitgeteilt, dass unter anderem der Smart Home Controller II Matter unterstützen wird. Aktuell wird allerdings nur beschrieben, dass die Geräte auf den Standard vorbereitet sind. Ein kostenloses Update soll später folgen.

Ikea

Der schwedische Möbelproduzent wollte mit dem Dirigera einen Hub mit Matter-Unterstützung auf den Markt bringen. Während der Hub seit Ende 2022 erworben werden kann, sieht es mit dem entsprechenden Update bisher weniger erfreulich aus.

Dieses sollte im ersten Halbjahr des Jahres 2023 erscheinen. Andere Smarthome-Geräte aus dem IKEA-Bestand unterstützen gegenwärtig kein Matter. Auch entsprechende Ankündigungen sind bisher nicht erfolgt.

Da die IKEA Produkte auf ZigBee aufsetzen, wäre, wenn die entsprechenden Funkcontroller dies zulassen, ein Update auf Thread im Rahmen der Matter-Unterstützung denkbar.

Nuki

Die Firma Nuki ist vorwiegend für ihre Türschlösser bekannt. Die Kommunikation der Schlösser läuft über das Bluetooth Low Energy-Protokoll, welche auch über die Nuki Bridge eingebunden werden können und damit indirekt per WLAN ansteuerbar sind.

Eines der Smart Locks von Nuki

Auch wenn die Firma bisher keine Matter-Produkte anbietet, wurde bereits an ersten Prototypen gearbeitet. Eine Aktualisierung bestehender Produkte auf den Matter Standard ist hierbei nicht geplant.

Schneider Electric

Der französische Konzern Schneider Electric hat seine Pläne für Matter mittlerweile verkündet. So sollen die neuste Generation der Wiser Gateways mit Matter kompatibel sein. Dieses dient als Bridge für die angeschlossenen ZigBee-Geräte. Auch die Wiser Home-App soll in Zukunft mit einer entsprechenden Unterstützung versehen werden.

Die ersten Produkte, welche Matter unterstützen sollten, sind das Wiser Gateway und der Wiser Smart Plug. Allerdings ist dies bisher aus den Spezifikationen der Produkte nicht ersichtlich.

Shortcut Labs

Shortcut Labs, eine schwedische Firma, entwickelt und vertreibt mit Flic einen smarten Bluetooth-Taster und dem Flic Hub eine zentrale Steuerungsmöglichkeit für Smarthome-Geräte.

Zur Matter-Unterstützung hat sich Shortcut Labs vor etlichen Monaten geäußert. Diese ist für das Jahr 2023 anvisiert und soll sich auf sämtliche Produkte der Hub-Serie erstrecken. Bisher sind allerdings noch keinerlei Updates für diese Produkte verfügbar.

Weitere Hersteller

Neben den besprochenen Hersteller existieren noch andere Hersteller, welche das eine oder andere Matter fähige Produkt in ihrem Portfolio haben oder solche angekündigt haben. Zu diesen gehören unter anderem Mediola, Netatmo, Sonnof und Ubisys.

Interessant ist auch die angekündigte Unterstützung von Smart-TVs der Hersteller LG und Samsung. Diese sollen in Zukunft über Matter-Unterstützung verfügen und sich so zur Steuerung von Matter-Geräten eignen.

Fazit

Nach einigen Startschwierigkeiten, finden sich nun die ersten Hersteller, welche fertige Produkte für den neuen Standard ausliefern.

Allerdings scheint es auch, dass viele Hersteller die Komplexität von Matter unterschätzt haben und hier auf einen späteren Einstieg in den Markt hinarbeiten. Hier hat Matter bis zu einer entsprechenden Durchdringung des Marktes noch einiges vor sich.

Gemeinsam haben die Ankündigungen, dass sich die Matter-Unterstützung meist verspätet und gar ganz abgekündigt werden.

Ob hier die Komplexität, des doch recht umfangreichen Standards, unterschätzt wurde, darüber kann nur spekuliert werden. Daneben bedeutet eine Unterstützung für Matter nicht automatisch volle Kompatibilität. So wird auf den Echo-Geräten, in den ersten Iterationen, nur eine Handvoll Produktkategorien des Standards unterstützt. Namentlich sind dies Lampen, Schalter und Steckdosen.

Dies führt z. B. zu dem Problem, dass Matter-Bridges im Amazon-Kontext aktuell nicht genutzt werden können. Das Gleiche gilt für SmartThings von Samsung.

So fühlt sich der Matter-Start in vielen Fällen holprig an und kommt nur Stück für Stück voran. Es bleibt abzuwarten, ob hier in Zukunft, nachdem der Standard etabliert ist, Besserung kommt.

Die Einfachheit, welche dem Endbenutzer versprochen wurde, erstreckt sich leider nicht auf die Implementation seitens der Hersteller. Dies zeigt, wie herausfordernd es ist, einen neuen Standard in einem bereits etablierten Markt zu implementieren. Trotz der Versprechen von einfacher Handhabung und nahtloser Kompatibilität ist die Realität oft eine andere. Die Implementierung von Matter erfordert eine genaue Planung und sorgfältige Ausführung. Viele Hersteller scheinen sich noch in der Anfangsphase dieses Prozesses zu befinden.

Allerdings sollte berücksichtigt werden, dass diese anfänglichen Herausforderungen nicht unbedingt auf langfristige Probleme hindeuten. Sie könnten viel mehr als Wachstumsschmerzen betrachtet werden, die oft mit der Einführung neuer Technologien einhergehen.

Ein bedeutsamer Aspekt, der im Kontext von Smarthome-Installationen hervorgehoben werden sollte, ist die Langlebigkeit einer solchen. Sie ist nicht auf einen kurzen Zeitraum von wenigen Jahren ausgelegt, sondern soll teilweise Jahrzehnte genutzt werden. Hier muss der Matter-Standard sich ein entsprechendes Vertrauen erarbeiten und die Hersteller eine langfristige Unterstützung bereitstellen.

Dieser Artikel erschien ursprünglich auf Golem.de und ist hier in einer alternativen Variante zu finden.

DNS-Technologien im Überblick

Das altehrwürdige Domain Name System ist seit mittlerweile fast vierzig Jahren einer der Grundpfeiler des Internets. Daneben erblicken neue Technologien rund um das DNS das Licht der Welt und entsprechende Unterstützung zieht in die Betriebssysteme ein.

Einleitung

Damit Pakete für das Internetprotokoll in Version 4 und 6 durch das Internet versendet werden können, sind Endpunkte, wie Clients und Server, mit Adressen versehen.

Über diese Adressen können die Dienste eines Servers abgerufen werden, so z. B. der Aufruf einer Webseite. Während IPv4-Adressen wie 192.168.15.15 noch übersichtlich scheinen, sieht es bei IPv6-Adressen wie der Adresse 2001:0db8:3c4d:0015:0000:1507:1503:1a2b anders aus.

Menschen sind nicht sonderlich gut darin, sich Zahlen zu merken, sodass eine andere Adressierung für die entsprechenden Endpunkte geschaffen werden musste. Gelöst wurde das Problem durch das Domain Name System, welches gerne als Telefonbuch des Internets bezeichnet wird.

Damit können Domains wie example.org auf eine entsprechende IP-Adresse abgebildet werden. Durch dieses Mapping vereinfacht sich die Nutzung und Adressierung im Internet.

Hierarchie im System

Wird eine Domain wie example.org aufgerufen, so wird ein DNS-Server abgefragt, der einem daraufhin den Domainnamen zu einer IP-Adresse auflöst.

Das gesamte Domain Name System ist hierarchisch aufgebaut. Auf der obersten Ebene befinden sich die autoritativen Nameserver für die Root-Zone. Diese sind dreizehn an der Zahl und tragen die Namen A bis M. Sie liefern die entsprechende Root-Zone aus, bei welcher es sich um einen knapp 2 MB großen Datenblob handelt.

In diesem enthalten ist eine Liste der autoritativen Nameserver für jede Top-Level-Domain. Damit verweist die Root-Zone auf DNS-Server, welche für einzelne Top-Level-Domains wie .de, .org oder .net zuständig sind.

Die Hierarchie im Domain Name System

Die Nameserver für die einzelnen Top-Level-Domains verweisen für eine angefragte Domain wiederum auf autoritative Nameserver, welche für diese Domain zuständig sind. In der Theorie kann diese Hierarchie mit jeder Ebene einer Domain, wie z. B. Subdomains, fortgesetzt werden.

Autoritative und cachende Nameserver

Besagte autoritative Nameserver sind dafür verantwortlich, verbindliche Aussagen zu einer Zone, wie einer Domäne oder einer ganzen Top-Level-Domain zu treffen. Was der autoritative Nameserver mitteilt, ist die objektive Wahrheit im Domain Name System.

Da es aus Gesichtspunkten wie der Lastverteilung und der Antwortgeschwindigkeit eher unpraktikabel ist, alle Anfragen zu einer bestimmten Zone nur von den autoritativen Nameservern beantwortet zu lassen, existieren cachende Nameserver.

Diese Nameserver, stehen z. B. beim Internet Service Provider und beantworten die DNS-Anfragen der Kunden. Kann eine solche DNS-Anfrage nicht aus dem Cache beantwortet werden, so wird wiederum der autoritative Nameserver angefragt und das Ergebnis für weitere Anfragen im Cache gehalten.

Nach Ablauf der Time to Live (TTL), welche in der Zone definiert ist, wird der Cache invalidiert und bei der nächsten Anfrage wieder der autoritative Nameserver befragt.

Zonen im Detail

In einer Zone können unterschiedlichste sogenannte Resource Records, kurz Records angelegt werden. Eine Zone, welche die entsprechende Konfiguration enthält, könnte wie folgt aussehen:

$ORIGIN example.org.
$TTL 3600
; SOA Records
@		IN	SOA	dns.example.org. 2022061900 86400 10800 3600000 3600
; NS Records
@		IN	NS	ns-1.example.org.
@		IN	NS	ns-2.example.org.
@		IN	NS	ns-3.example.org.
; MX Records
@		IN	MX	10 mail.example.org.
; A Records
@		IN	A	10.1.1.1
; AAAA Records
@		IN	AAAA	2001:db8:123:4567::1
; CNAME Records
api		IN	CNAME	www
www		IN	CNAME	example.org.

In der Zonen-Datei sind eine Reihe von Resource Record-Typen definiert, welche bestimmten Zwecken dienen. Von diesen Typen ist eine größere Anzahl definiert, von denen hier ein auszugsweiser Überblick gegeben werden soll.

A

Der A-Record definiert die IPv4-Adresse des Hosts. Mit diesem wird der Hostname schlussendlich der entsprechenden IPv4-Adresse zugeordnet.

AAAA

Wie beim A-Record ordnet auch der AAAA-Record dem Host eine IP-Adresse zu. In diesem Fall wird allerdings eine IPv6-Adresse zugeordnet.

CNAME

Bei CNAME handelt es sich um die Abkürzung für Canonical Name record. Mit diesem Record kann einer Domain ein weiterer Name zugeordnet werden. Dies kann genutzt werden, um Subdomains wie api.example.org anzulegen.

In einer beispielhaften Konfiguration würde dies dann wie folgt aussehen:

$ORIGIN example.org.
info    IN	CNAME	www
www		IN	A	192.168.1.1
www		IN	AAAA	2a01:4f8:262:5103::1

Hier wird die Subdomain info.example.org per CNAME auf die Subdomain www.example.org verwiesen, welche wiederum per A- und AAAA-Record auf die entsprechenden IP-Adressen des Hosts verweist.

MX

Der MX-Record ist ein wichtiger Record-Typ im Domain Name System, weil er dafür sorgt, dass E-Mails den entsprechenden Empfänger erreichen. Dazu definiert er den entsprechenden Mailserver, welcher für eine Domain zuständig ist:

; MX Records
@		IN	MX	10 mail.example.org.

Damit kann per DNS ermittelt werden, wie der Mailserver erreichbar ist und die entsprechende E-Mail zugestellt werden.

NS

Der NS-Record bzw. die NS-Records definieren die für die Domain zuständigen Nameserver. Bei einem bei Hetzner gehosteten Server, könnte das Ganze wie folgt aussehen:

; NS Records
@		IN	NS	helium.ns.hetzner.de.
@		IN	NS	hydrogen.ns.hetzner.com.
@		IN	NS	oxygen.ns.hetzner.com.

Die dort angegebenen Server sind die autoritativen Nameserver, da die entsprechenden Auskünfte, die diese Server erteilen, für die konfigurierte Domain verbindlich sind.

PTR

Ein PTR-Record, kurz für Pointer record, dient dazu, ein Reverse DNS Lookup zu ermöglichen. Das bedeutet, dass zu einer IP-Adresse der entsprechende DNS-Name ermittelt wird.

Wichtig ist diese Art der Konfiguration unter anderem bei der Bereitstellung von Mailservern.

SOA

SOA-Records, welche ein Kürzel für Start Of Authority darstellen, dienen der Darstellung bestimmter Informationen wie der primären Nameserver oder der Bereitstellung von Informationen, wie der TTL, für andere DNS-Server.

; SOA Records
@		IN	SOA	hydrogen.ns.hetzner.com. dns.hetzner.com. 2022121602 86400 10800 3600000 3600

TXT

Der TXT-Record ist ein relativ universeller Record im Domain Name System, mit welchem maschinenlesbare Daten im DNS hinterlegt werden können:

; TXT Records
@		IN	TXT	"v=spf1 redirect=example.org"

Genutzt wird diese Möglichkeit für unterschiedliche Techniken, wie im E-Mail-System mit DMARC oder dem Sender Policy Framework (SPF).

Probleme im Domain Name System

Das Domain Name System funktioniert in den Grundzügen, so wie es seit 1983 definiert wurde. Allerdings wirft diese Architektur auch einige Probleme auf.

In der klassischen DNS-Variante über UDP oder TCP, findet die komplette Kommunikation unverschlüsselt statt und stellt somit auch aus Sicht des Datenschutzes bzw. der Privatsphäre ein Problem dar.

Daneben sind die DNS-Responses nicht vor Änderungen geschützt und können somit ohne Wissen des Empfängers manipuliert werden.

Auch DDoS-Attacken in Form einer DNS Amplification Attack lassen sich bedingt durch die Gegebenheiten im Domain Name System durchführen. Hierbei wird die Zieladresse mit Datenverkehr von DNS-Servern belastet. Dies funktioniert, da der Angreifer eine DNS-Anfrage mit einer gefälschten IP-Adresse stellt und die Antwort somit beim eigentlichen Ziel der Attacke aufläuft. Der Angreifer benötigt in einem solchen Fall wenig Bandbreite, da die Antwort des DNS-Servers meist wesentlich größer ausfällt, als die Anfrage.

Ein weiteres Problem sind sogenannte Broken Resolvers. Dies ist insbesondere bei einigen Internet Service Providern der Fall, bei denen Dinge wie die TTL, also die Gültigkeit einer DNS-Antwort nicht berücksichtigt werden. Daneben existieren auch solche Resolver, die bei nicht vorhanden Domains nicht mit NXDOMAIN antworten, sondern stattdessen auf eine eigene Webseite umleiten.

Dieses Problem kann schon mit dem ursprünglichen Domain Name System verhindert, werden, indem alternative DNS-Server genutzt werden. Grundsätzlich erschweren solche Broken Resolvers die Fehlerfindung und beeinflussen die Funktionalität des Domain Name System.

Eine Fehlermeldung in Chrome, welche auf Probleme mit der DNS-Konfiguration hinweist

Interessant ist hier die Unterstützung durch Browser, wie Chrome, welcher bei Inkonsistenzen mit dem DNS-Server entsprechende Hinweise in Form einer spezifischen Fehlermeldung gibt.

Verbesserungen am System

Die Schwächen des Domain Name Systems sind nicht unberücksichtigt geblieben und so gab es im Laufe der Zeit immer wieder Verbesserungen, um das eine oder andere Problem zu beseitigen und das Domain Name System zu verbessern.

Dies fing schon in der Frühzeit des DNS an, als neben der ursprünglichen Möglichkeit per UDP Anfragen zu stellen, dies auch per TCP abgewickelt werden sollte. Hintergrund war es hier unter anderem DNS-Responses, welche größer als 512 Byte sind, versenden zu können.

Daneben wurde zur Erweiterung der DNS-Responses über UDP der Extension Mechanismus for DNS, kurz EDNS, definiert. Über diesen Mechanismus ist es möglich, mehr als 512 Byte per UDP zu übertragen. Genutzt wird dies unter anderem bei DNSSEC.

Bei der gewöhnlichen Nutzung wird in den meisten Fällen, aufgrund des geringeren Overheads, UDP genutzt. Nur in Fällen, in denen z. B. größere Datenmengen im Spiel sind, wird TCP genutzt.

TSIG und DNSSEC

Eine Sicherheitstechnologie in Bezug auf DNS ist TSIG, welches mit der RFC 2845 spezifiziert wurde. Das Kürzel steht für Transaction Signatures und ist ein Verfahren zur Absicherung von DNS-Updates z. B. bei dynamischem DNS.

Eine weitere Erweiterung des DNS sind die Domain Name System Security Extensions kurz DNSSEC. Mittels DNSSEC soll die Authentizität und Integrität von DNS-Daten gewährleistet werden.

Das bedeutet bei DNSSEC, dass die Übertragung selbst nicht verschlüsselt ist, sondern nur sichergestellt wird, dass die enthaltenden Daten korrekt und unverändert sind. Die Verbreitung von DNSSEC hat dabei in den vergangenen Jahren zugenommen.

Technologien für neue Anforderungen

Während Technologien wie DNSSEC und TSIG, bestimmte Anwendungszwecke im Auge haben, ist das Bewusstsein für Datenschutz und Privatsphäre im Laufe der letzten Jahre und Jahrzehnte gewachsen, sodass Lösungen entwickelt wurden, welche unverschlüsseltes DNS ersetzen oder ergänzen sollen.

Die neu entwickelten Protokolle und Technologien, welche in den vergangenen Jahren entwickelt wurden, hören auf so illustre Kürzel wie DoT, DoH oder DoQ.

Die unterschiedlichen DNS-Varianten im Laufe der Zeit

Interessant ist hier ein kurzer Rückblick auf die Geschichte des DNS-Protokolls. Als dieses ursprünglich zum Einsatz kam, setzte das Protokoll auf UDP auf, sodass die erste DNS-Version als DNS over UDP bezeichnet werden kann.

Mit der RFC 1123 aus dem Jahre 1989 wurde schließlich begonnen TCP für DNS-Anfragen zu nutzen, sodass DNS over TCP geboren war. Sowohl die UDP als auch die TCP Variante nutzen den Port 53.

DNS over TLS

DNS over TLS, kurz DoT, wurde im Mai 2016 im Rahmen der RFC 7858 standardisiert und wird genutzt, um DNS-Abfragen mittels TLS zu verschlüsseln. Es handelt sich hierbei nur um eine Transport- und um keine Ende-zu-Ende-Verschlüsselung.

DNS über TLS

Bei DoT wird zu dem DNS-Server eine Verbindung über TCP aufgebaut und diese mittels TLS abgesichert. Bedingt durch die Transportverschlüsselung können die DNS-Einträge nicht mehr zwischen den Knoten manipuliert werden. Der standardmäßig vorgesehene Port für DoT ist 853.

Wie auch bei DNS over HTTPS, werden bei dieser Variante DNS-Verstärkungsangriffe weitestgehend unterbunden.

Gegenüber unverschlüsseltem DNS erzeugt die Verschlüsslung per TLS einen gewissen Overhead, welcher sich auf die Geschwindigkeit der DNS-Anfrage auswirkt.

Im Gegensatz zu DNS über HTTPS soll diese Variante in der Praxis schneller sein. Allerdings gibt es je nach Implementierung unter Umständen Probleme, die meist von einem nicht korrekt implementierten Standard herrühren.

Bedingt durch den fest definierten Standardport für DoT (853), lässt sich dieses Protokoll relativ einfach blockieren. In einem solchen Fall kann auf andere DNS-Protokolle geschwenkt oder alternativ auf unverschlüsseltes DNS gesetzt werden.

DNS over HTTPS

Eine weitere Variante, welche ähnlich dem DNS over TLS funktioniert, ist DNS over HTTPS. Dieses wurde in der RFC 8484 standardisiert.

DNS über HTTPS

DoH läuft über den gleichen Port, wie gewöhnliches HTTPS, den Port 443. Damit kann von Außen keine Unterscheidung getroffen werden, ob es sich um DNS-Anfragen oder normalen HTTPS-Datenverkehr handeln.

Der Grund hierfür ist darin zu suchen, dass der Datenverkehr bzw. die Informationen der DNS-Abfrage über das Hypertext Transfer Protocol gesendet werden.

Damit wird eine Blockierung entsprechender DNS-Abfragen über dieses Verfahren erschwert. Allerdings leidet auch hier wieder die Performanz im Vergleich zu gewöhnlichem unverschlüsselten DNS.

Eine Spielart von DNS over HTTPS ist das relativ neue DNS-over-HTTP/3 kurz DoH3, welches wie HTTP/3 als Transportprotokoll QUIC anstatt von TCP nutzt. Dies darf allerdings nicht mit DNS over QUIC verwechselt werden.

DNS over QUIC

Zu den neueren Ideen bzw. Technologien bei der DNS-Abfrage gehört DNS over QUIC. Ziel von DoQ ist es, die Latenzen zu verringern, bei gleichzeitiger Nutzung einer verschlüsselten Verbindung.

DNS über QUIC

Definiert ist DoQ in der RFC 9250. Grundlage für das Protokoll ist QUIC, welches als Transportschicht TCP ersetzt und in dieser Form auch bei HTTP/3 genutzt wird.

Ziel von DoQ ist, dass dieses Protokoll auch für autoritative Nameserver verwendet werden kann. Damit soll eine möglichst breite Anzahl an Nutzungsmöglichkeiten im Zusammenhang, mit dem Domain Name System abgebildet werden können.

Da DoQ über den zugewiesenen Port 853 läuft, ist auch hier technisch gesehen eine einfache Blockierung möglich. Allerdings definiert die RFC hier im Abschnitt Port Selection:

In the stub to recursive scenario, the use of port 443 as a mutually agreed alternative port can be operationally beneficial, since port 443 is used by many services using QUIC and HTTP-3 and is thus less likely to be blocked than other ports

Unterstützung auf Serverseite

Damit DNS-Dienste, über welche Protokolle auch immer, im Internet genutzt werden können, muss die entsprechende Server-Software die gewünschten Protokolle unterstützen.

Neben BIND, dem Platzhirsch unter den DNS-Server, existieren noch weitere DNS-Server von denen bezüglich ihrer Fähigkeiten noch Unbound und der Windows Server kurz beleuchtet werden sollen.

DNS over TLS DNS over HTTPS DNS over QUIC
BIND ab Version 9.17 ab Version 9.17
Unbound ab Version 1.7.3 ab Version 1.12.0
Windows Server (DNS) ab Windows Server 2022

Bei BIND zogen mit der Version 9.17, welche im Jahr 2020 erschien, der Support für DoT und DoH (in einer experimentellen Version) ein. Eine Unterstützung für DNS over QUIC, steht im Moment noch aus.

Unbound liefert seit der im Juni 2018 erschienen Version 1.7.3 eine Unterstützung für DNS over TLS aus. Mit der im Oktober 2020 erschienen Version 1.12.0 wurde die Unterstützung für DNS over HTTPS implementiert. An der Umsetzung von DNS over QUIC in Unbound wird im Moment noch gearbeitet.

Ab dem Windows Server 2022 wird DNS over HTTPS offiziell unterstützt. Bei DNS over TLS und DNS over QUIC ist bisher keine Unterstützung im Windows Server vorhanden.

Linux

Neben der Unterstützung auf Serverseite ist auch die Unterstützung auf Client-Seite, in Form von Betriebssystemen auf dem Desktop, als auch im Bereich der mobilen Betriebssysteme wichtig.

In den meisten Linux-Distributionen, welche Systemd nutzen, kann dies über systemd-resolved erledigt werden. Dieser unterstützt ab der Version 239 opportunistisches DNS over TLS und ab der Version 243 striktes DNS over TLS.

Hier kann z. B. unter Ubuntu in der Konsole die entsprechende Konfigurationsdatei editiert werden:

nano /etc/systemd/resolved.conf

Dort sollte die Einstellung:

DNSOverTLS=yes

hinzugefügt werden. Anschließend können über den normalen Netzwerkdialog, DoT-fähige DNS-Server eingetragen werden:

9.9.9.9, 149.112.112.112

In diesem Fall sind es die DNS-Server von Quad9. Anschließend laufen die DNS-Abfragen per DoT über die gewählten DNS-Server.

macOS

Seit macOS 11, welches mit dem Namen Big Sur auf den Markt kam, unterstützt macOS neben DNS over TLS auch DNS over HTTPS.

Aktiviert werden können die gewünschten Einstellungen über Konfigurationsprofile. Dazu muss ein entsprechendes Profil heruntergeladen und anschließend installiert werden.

Das Profil unter macOS

Die Konfigurationsprofile befinden sich in den Systemeinstellungen unter macOS. Nach der Aktivierung kann über das Terminal überprüft werden, ob die entsprechenden Einstellungen aktiv sind:

sudo tcpdump -i any "port 853 and host 9.9.9.9 or host 149.112.112.112"

Bei der Nutzung von DoH sollte der Port im Befehl auf 443 geändert werden. Nachdem der Befehl abgesetzt wurde, sollte Netzwerkverkehr zu dem Quad9-DNS-Server im Dump auftauchen.

Windows

Unter Windows 10 wird, seit dem Build 19628, DNS over HTTPS unterstützt. Dazu muss in der Registry der Pfad:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters

aufgerufen werden und dort ein Parameter vom Typ DWORD erstellt werden. Dieser trägt den Namen EnableAutoDoh sowie den Wert 2. Anschließend sollte ein Neustart des Rechners durchgeführt werden.

Die Einstellungen im Registrierungs-Editor

Nun können in den Einstellungen für den jeweiligen Netzwerkadapter die passenden DNS-Server mit einer entsprechenden Unterstützung für DoH eingestellt werden:

9.9.9.9, 149.112.112.112

Unter Windows 11 können die Einstellungen für DoH bequem über die Netzwerkeinstellungen eingestellt werden, nachdem dort die passenden DNS-Server hinterlegt sind, kann dort unter DNS over HTTPS das Feature aktiviert werden.

Neben DoH unterstützt Windows 11 auch DNS over TLS. Dazu werden in den Netzwerkeinstellungen die entsprechenden DNS-Server hinterlegt und das DNS over HTTPS-Feature deaktiviert.

Nun muss die Kommandozeile geöffnet werden und dort müssen die Befehle:

netsh dns add global dot=yes​
netsh dns add encryption server=9.9.9.9 dothost=: autoupgrade=yes
netsh dns add encryption server=149.112.112.112 dothost=: autoupgrade=yes

eingegeben werden. Das Kommando:

netsh dns add encryption

muss hierbei für jeden DNS-Server für die IPv4- und IPv6-Adresse wiederholt werden. Abgeschlossen wird das Prozedere mittels:

ipconfig /flushdns
netsh dns show global

Der letztere Befehl zeigt an, ob die Einstellungen für DNS over TLS aktiviert wurden. DNS over QUIC wird unter Windows vom System selbst bisher noch nicht unterstützt.

Android

Während seit Android 9 (Pie) DNS over TLS bereits verfügbar ist, ist DNS over HTTPS ab Android 11 enthalten und teilweise auch auf einigen Geräten mit Android 10 verfügbar.

Die teilweise Verfügbarkeit unter Android 10 erklärt sich dadurch, dass das entsprechende DNS Resolver Modul unter Android 10 noch optional, aber unter Android 11 verpflichtend zum System dazu gehört. Installiert werden diese Änderungen über ein Google Play-Systemupdate.

In den Einstellungen kann DoT bzw. DoH aktiviert werden

Zur Aktivierung unter Android genügt es in den Systemeinstellungen, die Netzwerkeinstellungen aufzurufen und dort im Punkt Privates DNS, die entsprechenden DNS-Server zu hinterlegen. Hierbei wird, je nach Android-Version, DNS over HTTPS (in der Variante DoH3) gegenüber DNS over TLS bevorzugt, zumindest bei den dem System bekannten DNS-Servern.

iOS

Seit iOS 14, also knapp 2 Jahre später als unter Android, zog in iOS die Unterstützung für DNS over TLS ein. Ebenfalls ab iOS 14 wird DNS over HTTPS unterstützt.

Wie unter macOS, kann die Einstellung über entsprechende Konfigurationsprofile vorgenommen werden. Dazu muss ein Profil auf dem iOS-Gerät heruntergeladen und installiert werden.

Die Installation des Profils erfolgt über die Einstellungen unter iOS

Nachdem das Profil bestätigt und installiert worden ist, wird der DNS-Server in der im Profil hinterlegten Konfiguration genutzt.

Unter iOS existiert die Besonderheit, dass DNS-Abfragen für den Appstore und die Terminalbefehle dig und nslookup per Design nicht über die im Profil hinterlegten DNS-Server abgefragt werden.

Das Profil kommt nicht immer zur Anwendung

Auch gelten die Einstellungen nicht, wenn z. B. iCloud Privat Relay oder eine VPN-Verbindung aktiv sind.

Browser

Neben der betriebssystemseitigen Unterstützung liefern auch die meisten Browser mittlerweile eine Unterstützung für DNS over HTTPS aus. Diese Unterstützung ist unabhängig vom darunterliegenden Betriebssystem.

Die Einstellungen für DNS over HTTPS im Firefox

Im Firefox kann DNS over HTTPS in den Einstellungen unter Allgemein und dort in den Verbindungs-Einstellungen aktiviert werden. Dort kann dann der Punkt DNS über HTTPS aktiviert mitsamt eines Servers ausgewählt werden.

Die Einstellungen zu DoH unter Chrome

Unter Chrome kann DoH über die Einstellungen unter dem Punkt Datenschutz und Sicherheit aktiviert werden. Dort findet sich unter dem Unterpunkt Sicherheit der Punkt Sicheres DNS verwenden.

Router

Auch Router bieten in vielen Fällen Funktionalitäten zur besseren Absicherung von DNS-Abfragen.

So können in der FRITZ!Box entsprechende DNS-Server, welche DoT unterstützen hinterlegt werden. Auf Wunsch kann die FRITZ!Box auch einen Fallback auf unverschlüsseltes DNS durchführen, falls die entsprechenden DoT-Server nicht erreicht werden können. Dies kann zum Beispiel durch entsprechende Firewalls oder beim technischen Ausfall der Server passieren.

Andere Verfahren

Neben den oben beschriebenen Varianten existieren noch weitere DNS-Varianten wie Oblivious DNS bzw. Oblivious DoH, DNS over TOR und DNSCrypt, welche allerdings im weiträumigen Praxiseinsatz eher seltener zu finden sind.

Nachteile der neuen Lösungen

Bei den neuen Lösungen, wie DoT, DoH und DNS over QUIC, existieren eine Reihe von Problemen bzw. Kritikpunkten.

Viele beziehen sich dabei auf gewünschte Eigenschaften der Verfahren, wie die Verschlüsselung, welche es unter anderem erschwert, den DNS-Verkehr zu überwachen. Genutzt wird eine solche Überwachung z. B. in Kinderschutzsoftware, oder im geschäftlichen Umfeld, um den Netzwerkverkehr zu überwachen und entsprechende Policen durchzusetzen.

Je nach Lösung wird dann versucht, die neueren Verfahren zu deaktivieren bzw. dessen Nutzung nicht zuzulassen oder aber eigene Server für die entsprechenden Protokolle zu betreiben, welche wiederum die entsprechen Sperrmöglichkeiten anbieten.

Auch sind die, bei den Verfahren wie DoT oder DoH genutzten, meist zentralen DNS-Server von Google, Cloudflare oder Quad9 ein Problem, da sich dort ein Großteil des DNS-Verkehrs sammelt und dies Begehrlichkeiten wecken oder der Profilbildung dienen kann.

Daneben sollte beachtet werden, dass je nach Implementation bzw. Betriebssystem die Nutzung der verschlüsselten DNS-Varianten nicht immer garantiert ist. Sei es durch ungewollte Downgrades auf unverschlüsseltes DNS oder aber Applikationen wie der Appstore unter iOS, welcher von den DNS-Einstellungen des Systems unabhängig funktioniert. Daneben gibt es in bestimmten Versionen von Android den Fall, dass die Private-DNS-Einstellungen nach dem Aufwachen des Gerätes erst wieder nach einigen Sekunden angewendet werden.

Fazit

DNS-Abfragen müssen heute nicht mehr unverschlüsselt erfolgen, da es eine Reihe von neuen Ideen und Transportprotokollen gibt, welche neben der jeweiligen Vorteile teilweise auch spezifische Nachteile haben.

Mittlerweile findet sich für die Verfahren DNS over TLS und DNS over HTTPS eine breitere Unterstützung in den Betriebssystemen. Dort, wo diese noch nicht verfügbar ist, kann auf DNS-Proxies oder im Spezialfall Browser auf dessen Möglichkeiten zurückgegriffen werden.

DNS over TLS DNS over HTTPS DNS over QUIC
Linux über systemd-resolved (ab Version 239 bzw. 243)
macOS ab macOS 11 (Big Sur) ab macOS 11 (Big Sur)
Windows ab Windows 11 (Build 25158) ab Windows 10 (Build 19628), Windows 11
Android ab Android 9 (Pie) ab Android 11
iOS ab iOS 14 ab iOS 14

Neben der gewöhnlichen DNS Auflösung haben aktuell vorwiegend die Technologien DoT und DoH eine größere Verbreitung erlangt. Spannend wird in Zukunft auch die Entwicklung von DoQ, welches zumindest das Potenzial hat, bestehende Technologien rundum DNS-Abfragen abzulösen.

Allerdings stellt sich bei vielen dieser Protokolle die Frage, welchen DNS-Servern vertraut werden soll, denn das bestehende DNS-System ist ein dezentrales System ohne übermächtige Gatekeeper, während bei Diensten wie DoT und DoH eine Zentralisierung zu beobachten ist.

Dieser Artikel erschien ursprünglich auf Golem.de und ist hier in einer alternativen Variante zu finden.

Matter im Überblick

Im Laufe der letzten Jahre und Jahrzehnte sind einige Smart Home-Standards auf den Markt gekommen. Mit Matter ist nun ein neuer Standard angetreten, welcher den Smart Home-Markt aufrollen möchte.

Doch abseits der für den Endnutzer gedachten Versprechen, welche Vorteile er bringen soll, wird erstaunlich wenig über die technischen Hintergründe gesprochen.

Allerdings helfen diese Hintergründe Matter und seine Möglichkeiten zu verstehen. In diesem Artikel sollen die Hintergründe von Matter beleuchtet und gezeigt werden, wie Matter abseits der Marketingversprechen funktioniert.

Bestehende Standards

Matter ist beileibe nicht der erste Standard, welcher sich mit dem Thema Smart Home beschäftigt. Vor ihm gab und gibt es Standards wie Z-Wave, EnOcean und Zigbee. Letzterer spielt bei Matter organisatorisch eine besondere Rolle.

Je nach Standard werden unterschiedlichste Technologien und Funksysteme genutzt, wie das vermaschte Netzwerk, welches Z-Wave-Geräte untereinander aufbauen.

Das Problem an diesen Systemen ist, dass sie meist zueinander inkompatibel sind. Über Lösungen wie Home Assistant oder Homee können diese unterschiedlichen Systeme zur Zusammenarbeit gebracht werden.

Allerdings wird auch hier in vielen Fällen nur eine begrenzte Anzahl an Hardware unterstützt. Eine allumfassende Lösung stellt dies meist nicht dar.

Auch ins heimische Funknetz eingebundene Geräte werden gerne für die Smart Home-Anwendungen genutzt, welche auch durch ihren günstigen Preis bestechen können.

Aus Sicht von Entwickler sind unterschiedlichste Standards ein Problem. Je nach Firmengröße kann sich nur für einen Standard entschieden werden, da zusätzlich zu unterstützende Standards mehr Entwicklungsaufwand und damit am Ende mehr Kosten bedeuten.

Daneben sind die unterschiedlichen Standards zwar mehr oder weniger gleichwertig, allerdings gibt es eine gewisse Fragmentierung bei den Geräteklassen, so sind Leuchtmittel vorwiegend mit dem Zigbee-Standard verheiratet oder werden über teils obskure Wi-Fi-Lösungen angebunden.

Zwar existieren auch Beleuchtungslösungen für Z-Wave, allerdings sind diese in ihrer Auswahl beschränkt und der Preis ist in vielen Fällen höher als bei den Zigbee-Varianten.

Es gibt es Hersteller, welche mehrere Systeme unterstützen und die gleichen Produkte wie schaltbare Steckdosen in unterschiedlichen Varianten, je nach Smart Home-System, anbieten.

Für den Kunden bedeutet diese Auswahl und die damit verbundenen Probleme wie die Berücksichtigung der Kompatibilität, dass er meist zögerlich zu Smart Home-Produkten greift. Aus Sicht der Hersteller und der Kunden ist dies eine suboptimale Situation: voneinander abgeschirmte Ökosysteme und Geräte, die nur unter Umständen miteinander genutzt werden können.

Smart Home-Markt

Für das Jahr 2022 wird von einem Umsatz im Smart Home-Markt von über einhundert Milliarden Euro ausgegangen.

Allerdings bedingt durch die Fragmentierung des Marktes, entspricht dieser Umsatz nicht dem, der vor einigen Jahren erwartet wurde. So wurde unter anderem von einer höheren Durchdringung des Marktes ausgegangen.

Aktuell nutzen knapp 15 % aller Haushalte, weltweit gesehen, Smart Home-Technik in ihrem Haus oder ihrer Wohnung. Bedingt durch die Vorteile, welche Matter bieten soll und die damit einhergehende Vereinheitlichung, soll dem Smart Home-Markt neues Leben eingehaucht werden.

Das Matter-Versprechen

Matter will die bestehenden Probleme anderer Standards lösen. Der Standard sieht sich als Smart Home-Interoperabilitätsprotokoll und definiert sich als Anwendungsschicht, welche existierende Protokolle wie Thread und Wi-Fi nutzt, um seine Aufgabe, eine Smart Home-Umgebung darzustellen und zu verwalten, zu erfüllen.

Im Grundsatz geht es darum, dass der neue Standard unabhängig von den einzelnen Herstellern sein soll. Auch soll es jedem Hersteller von Hardware möglich sein, den neuen Standard zu implementieren.

Dem Endnutzer wird die Kompatibilität, aller Matter-Geräte untereinander, versprochen. Daneben soll in Zukunft auf proprietäre Bridges und Hubs, welche zur Anbindung bestimmter Systeme genutzt werden, verzichtet werden können.

Eine weitere wichtige Eigenschaft von Matter ist, dass die Steuerung zwar in der Theorie an Cloud-Systeme angebunden werden kann, aber immer lokal funktionieren muss.

Aus Sicht des Datenschutzes und der Betriebssicherheit ist dies eine erfreuliche Entwicklung, da Steuersignale nun nicht mehr die halbe Welt umrunden müssen, bevor sie wieder im eigenen Zuhause ankommen. Auch die Zuverlässigkeit stärkt dies in der Theorie, da auch beim Wegfall der Internetverbindung das eigene Smart Home noch funktioniert.

Für die Einrichtung von Matter-Geräten werden nicht mehr unbedingt die Third-Party-Apps der jeweiligen Hersteller benötigt, sondern diese können zentral über Apps z. B. der Home-App unter iOS hinzugefügt werden.

Connectivity Standards Alliance

Organisatorisch wird der Matter-Standard von der Connectivity Standards Alliance (CSA) betreut. Diese ging aus der Zigbee Alliance, welche 2002 gegründet wurde, hervor, welche sich für den gleichnamigen Zigbee-Standard verantwortlich zeichnet.

Mittlerweile sind über 500 Firmen unter dem Dach der Connectivity Standards Alliance vereint. Dazu gehören Unternehmen wie Amazon, Apple, Comcast, Google, IKEA, Infineon, LG, Nordic Semiconductor und Samsung.

Von der Idee zum Standard

Erste Lebenszeichen des Matter-Standards gab es im Dezember 2019. Damals kündigten unter anderem Amazon, Apple und Samsung sowie die Zigbee Aliance an, dass eine Zusammenarbeit für das Projekt Connected Home over IP beschlossen wurde.

Knapp anderthalb Jahre nach der ersten Ankündigung wurde aus Connected Home over IP schließlich Matter. Im gleichen Zuge wurde durch eine Umbenennung aus der Zigbee Alliance die Connectivity Standards Alliance.

Nach etwa drei Jahren Zeit der Planung und Entwicklung erschien im Oktober 2022 mit der Version 1.0 die erste Iteration des Standards. Hier wurden neben der eigentlichen Standardbeschreibung unterschiedliche Produktkategorien wie Beleuchtungslösungen, Sicherheitssensorik, Thermostate, Türschlösser und einige andere spezifiziert.

Während der Entwicklung gab es bedingt durch Faktoren wie die Coronapandemie und Verzögerungen bei den Gerätetests einige Verschiebungen, welche dann schlussendlich zum Veröffentlichungstermin im Oktober 2022 führten. Im November 2022 wurde Matter offiziell auf einem Launch-Event in Amsterdam vorgestellt.

In der nächsten Iteration des Standards, der Version 2.0, welche im März bzw. April 2024 erscheinen soll, sollen unter anderem die unterstützten Geräte um Klassen wie Staubsauger-Roboter, Rauchmelder, Kameras und einige andere erweitert werden.

Architektur

Aus architektonischer Sicht betrachtet ist Matter ein Applikationsprotokoll, welches auf bestehenden Technologien aufsetzt. Grundlage für das Matter-Protokoll bildet IPv6.

Matter setzt als Applikationsprotokoll auf vorhandenen Technologien auf

Der Matter-Protokollstack selbst besteht aus unterschiedlichsten Schichten, welche jeweils bestimmte fachliche Anforderungen erfüllen.

Die Schichten des Matter-Protokollstack

Die Anwendungsschicht (Application Layer) innerhalb des Matter-Protokollstacks implementiert die dem Gerät eigene Businesslogik. Im Falle einer schaltbaren Steckdose wäre dies die Logik, um das Gerät ein- und auszuschalten. Aktionen in der Anwendungsschicht führen zur Änderung im Datenmodell (Data Model).

Im Datenmodell werden die Daten für das entsprechende Gerät gehalten, z. B. ob das Gerät aktuell angeschaltet ist oder bei einem Leuchtmittel, die aktuell ausgewählte Leuchtfarbe.

Für die Interaktion von Außen werden im Interaction Model bestimmte Interaktionen definiert, welche von Außen geschrieben oder gelesen werden können. Eine solche Interaktion löst dann eine Logik in der Anwendungsschicht des Gerätes aus, um die entsprechenden Aktionen auszulösen.

Über das Interaction Modell kann eine Aktion definiert werden und über die Action Framing-Schicht wird sie schließlich in ein binäres Format serialisiert und dieses an die Security-Schicht übergeben.

In dieser wird die Nachricht verschlüsselt und ein Message Authentication Code angehangen. Damit soll sichergestellt werden, dass die Daten sicher und verschlüsselt zwischen den Instanzen bzw. Geräten übertragen werden.

Damit sind die Daten für die Nachricht serialisiert, verschlüsselt und kryptografisch signiert und werden an die Message Framing-Schicht übergeben, in welcher die endgültige Payload, welche schlussendlich über das Netzwerk verschickt wird, erzeugt wird. In Rahmen dieses Prozesses werden Headerfelder ergänzt, welche unter anderem Routing-Informationen enthalten können.

Anschließend wird das Ganze an die Transportschicht übergeben und findet so seinen Weg durch das Netzwerk, bis es beim definierten Empfänger ankommt. Dort angekommen wird der Matter-Protokollstack in umgekehrter Reihenfolge durchlaufen, bis schlussendlich wieder die eigentliche Nachricht in der Anwendungsschicht verarbeitet werden kann.

Fabric, Nodes und Controller

Im Matter-Standard werden einige Begriffe definiert, deren Wissen um die Bedeutung ein Verständnis des Standards erleichtert.

Ein zentraler Begriff im Matter-Standard ist die Fabric. Bei einer Fabric handelt es sich um einen logischen Verbund von Knoten (Nodes), welche eine gemeinsame Vertrauensbasis (Common Root of Trust) und einen gemeinsamen verteilten Konfigurationsstatus besitzen.

Ein Knoten (Node) ist im Matter-Standard definiert als eine Entität, welche den Matter Protokollstack unterstützt und nach der Kommissionierung über eine Operational Node ID und Node Operational Credentials verfügt.

Eine schaltbare Steckdose

Dabei ist ein Node nicht unbedingt gleichzusetzen mit einem Gerät. Ein Gerät, wie eine schaltbare Steckdose kann in der Theorie mehrere Knoten beinhalten, welche wiederum zu mehreren Fabrics gehören können.

Daneben gibt es im Matter-Standard den Begriff des Controllers. Dieser ist definiert als ein Matter-Knoten, welcher die Berechtigung hat einen oder mehrere Knoten zu kontrollieren. Dies kann z. B. das Smart Home-System sein oder ein iPhone mit der entsprechenden Home-App. Matter unterstützt per Design unterschiedlichste Controller in einem Matter-Netzwerk. Dieses Feature wird als Multi-Admin bezeichnet.

Kerntechnologien

Für Matter-Netzwerke, sind einige Kerntechnologien definiert, welche im Rahmen des Standards genutzt werden.

Für die Kommunikation der Geräte untereinander wird Wi-Fi, Ethernet oder Thread benutzt, für die Kommissionierung Bluetooth LE.

Bluetooth LE

Bluetooth LE wird im Matter-Standard genutzt, allerdings nicht für die Kommunikation der Geräte untereinander. Stattdessen wird Bluetooth LE für Kommissionierung (commission, im Matter-Standard) der Geräte genutzt.

Nach der Definition des Matter-Standards wird bei der Kommissionierung ein Node in die Fabric eingebracht, also das Gerät dem Matter-Netzwerk hinzugefügt.

Im Rahmen dessen werden die Zugangsdaten des Netzwerkes und andere für die Kommissionierung benötigten Informationen auf das Gerät übertragen.

Im Anwendungsfall würde dies so aussehen, dass der Nutzer einen QR-Code scannt, welcher die Informationen über das Gerät enthält und anschließend die Kommissionierung mittels Bluetooth LE durchgeführt wird.

Diese Informationen müssen nicht unbedingt als QR-Code geliefert werden. In der Theorie kann auch NFC als Technologie benutzt werden oder die enthaltenen Informationen einfach als kodierte Zeichenkette auf dem Gerät aufgedruckt sein oder dem Handbuch beiliegen.

Dies ermöglicht eine einfache Konfiguration und Einbindung der Geräte aus Sicht des Endbenutzers. Ist die Kommissionierung abgeschlossen und das Gerät damit in das Matter-Netzwerk eingebunden, nutzt das Gerät Bluetooth LE nicht mehr.

Anbindung der Smart Home-Geräte

In den meisten praxisnahen Fällen wird die Anbindung von Geräten meist auf die Anbindung per Thread und Wi-Fi hinauslaufen. Bei Wi-Fi im Heimbereich sind alle Geräte mehrheitlich mit einem Access Point verbunden. Bei Thread hingegen handelt es sich um ein vermaschtes Netz, welche über Border-Router mit dem Rest des Netzwerkes verbunden ist.

Thread

In einem Smart Home sind eine Reihe von Aktoren, wie schaltbare Steckdosen und Ähnliches verbaut. Daneben gibt es dann noch Sensorik, z. B. in Form von Temperatur- und Bewegungssensoren.

Sensoren, wie Temperatur oder Bewegungssensoren, laufen mehrheitlich mit Batteriestrom und eignen sich damit nicht für energieintensive Techniken wie Wi-Fi, um ihre Daten von A nach B zu transportieren.

Ein batteriebetriebener Sensor

Hier kommt das Protokoll Thread ins Spiel. Dieses ist darauf ausgelegt, Geräte miteinander zu verbinden, welche eine geringe Datenrate benötigen und möglichst wenig Energie verbrauchen sollen. Das Protokoll besticht durch sein simples Design und ermöglicht geringe Latenzen.

Das Netzwerkprotokoll Thread versteht sich als selbstheilendes Mesh-Netzwerk. Ein Designziel war es unter anderem, dass es keinen Single Point of Failure in einem solchen Netzwerk geben soll, die Übertragung zuverlässig und die Reichweite durch das Routing innerhalb des Thread-Netzwerkes gegeben ist.

Im Rahmen von Matter sollen hunderte bis tausende Produkte über Thread in einem Netzwerk unterstützt werden.

Entwickelt wird das Protokoll seit 2014 von der Thread Group welcher unter anderem ARM Limited, Nest Labs, Samsung und Qualcomm angehören. Die Entwicklung ist seit dem nicht stehen geblieben und so wurden mit Thread 1.3 Funktionalitäten wie vollumfängliches IP-Routing und Service-Discovery hinzugefügt. Diese Funktionalitäten werden für die Nutzung von Thread im Zusammenhang mit Matter benötigt.

Thread setzt auf IEEE 802.15.4 auf, bei welchem es sich um ein Standard für kabellose Netzwerke mit geringen Datenraten handelt. In IEEE 802.15.4 ist die Bitübertragungsschicht (Physical Layer) und die Data-Link-Schicht definiert.

Neben Thread setzt unter anderem auch Zigbee auf IEEE 802.15.4 auf, was ein Update solcher Geräte, hin zu Thread, perspektivisch möglich macht.

Das OSI-Modell

Darüberliegende Schichten, welche z. B. das Routing übernehmen können, müssen dann von anderen Protokollen übernommen werden. An dieser Stelle setzt Thread ein.

Per Thread angebundene Geräte können per IPv6 adressiert werden. Wichtig ist es festzuhalten, dass es sich bei Thread nicht um Matter handelt, sondern Thread ein eigenständiges Funkprotokoll ist, welches wie Wi-Fi der Anwendungsschicht agnostisch gegenübersteht.

Rollenspiele

Bei Thread kann jedes Gerät unterschiedliche Rollen annehmen. So gibt es in einem Thread-Netzwerk, einen Leader, einen oder mehrere Router und die Rolle des Endgerätes.

Jedem Gerät wird mindestens die Rolle des Endgeräts zugewiesen. Das sind solche Geräte, welche einen Befehl in Form eines Datenpaketes erhalten, um diesen auszuführen.

Ein Leader ist eine Rolle, welche nur einmal vergeben wird. Dieser koordiniert das Thread-Netzwerk. Fällt ein Leader aus, so wird automatisch ein neuer Leader bestimmt. Dazu ist es notwendig, dass jederzeit andere Geräte für den bestehenden Leader einspringen können. Die Zustandsinformationen müssen also im Netzwerk aktuell gehalten werden.

Router, leiten Datenpakete im Thread-Netzwerk weiter. Diese Rolle wird dynamisch von den jeweiligen Geräten aktiviert bzw. wieder deaktiviert, wenn z. B. zu viele Router in der Umgebung unterwegs sind. Daneben bieten die Router Funktionalität, wie Security Services, für andere Geräte, die dem Netzwerk beitreten wollen.

Normalerweise nehmen Thread-Geräte nur die Rolle als Endgerät wahr. Wird mehr Reichweite im Netzwerk benötigt, werden einige dieser Geräte automatisch Router in diesem. Das passiert z. B. dann, wenn ein Endgerät keinen Router findet, aber ein Endgerät in der Theorie eine solche Rolle einnehmen kann.

Auf der anderen Seite funktioniert dies auch, wenn sich zu viele Router in einem Bereich befinden und damit zu viel Redundanz vorhanden ist. In diesem Fall stufen sich Geräte in wieder zurück und geben die Router-Rolle auf. Dies ist z. B. dann der Fall, wenn ein Gerät nur noch mit anderen Geräten verbunden ist, welche ebenfalls die Router-Rolle wahrnehmen.

Damit ist das Routerkonzept, im Gegensatz zu Technologien wie Bluetooth Mesh oder Zigbee dynamisch.

FTDs und MTDs

Thread kennt unterschiedliche Typen von Geräten. Einerseits gibt es sogenannte Full Thread Devices (FTD) und sogenannte Minimal Thread Devices (MTD).

Bei den FTDs handelt es sich um autonome Geräte im Thread-Netzwerk, welche Rollen, jenseits der Endgeräte-Rolle, wahrnehmen. Im Normalfall haben diese Geräte entsprechende Hardwareressourcen, wie genügend Speicher et cetera. Im Gegensatz zu den MTDs sind FTDs immer mit dem Thread-Netzwerk verbunden. Infolgedessen sind FTDs meist solche Geräte, welche direkt am Stromnetz angeschlossen sind.

Ein einfaches Thread-Netzwerk

MTDs hingegen sind für solche Geräte gedacht, welche größtenteils über eine Batterie betrieben werden. In diese Kategorien fallen Geräte wie Sensoren und Ähnliche. Diese müssen mit ihren Ressourcen entsprechend haushalten. Sie treten deswegen nur sporadisch mit dem Thread-Netzwerk in Kontakt und befinden sich den Großteil ihrer Betriebszeit im Schlafmodus.

MTDs senden alle ihre Nachrichten zu einem sogenannten Parent-Device und nehmen nur die Rolle als Endgerät im Thread-Netzwerk wahr.

Border-Router

Da im Rahmen von Matter Informationen aus dem Thread-Netzwerk heraus in den Rest des Netzwerkes gelangen müssen, werden hier wieder Router, sogenannte Border-Router benötigt. Diese routen die Informationen aus und in das Thread-Netzwerk.

Im Gegensatz zu anderen Systemen unterstützt Thread mehrere Border-Router, um auch hier wieder einen Single Point of Failure zu vermeiden. Die Funktionalität solcher Border-Router wird und kann von unterschiedlichsten Geräten wahrgenommen werden. Beispiele für solche Geräte sind z. B. Alexa-Geräte oder der HomePod mini von Apple.

Während bei Bridges eine Übersetzung der jeweiligen Daten vorgenommen wird, damit sie vom anderen System verstanden werden, werden bei den Border-Routern nur die entsprechenden Daten vom Thread-Netzwerk in das andere Netzwerk geroutet. Eine Übersetzung derselben findet nicht statt.

Wi-Fi

Neben Thread können Geräte im Matter-Standard auch über Wi-Fi eingebunden werden. Als Übertragungstechnik bietet sich Wi-Fi für Smart Home-Geräte an, welche eine höhere Bandbreite benötigen und meist auch über ein entsprechendes Energiebudget verfügen und zumeist direkt an das Stromnetz angeschlossen sind.

In diese Kategorie fallen unter anderem Videokameras und Türklingeln mit Videoverbindung. Allerdings ist Wi-Fi bzw. ein einzelner Access Point nicht unbedingt dafür gedacht, eine große Menge an Geräten gleichzeitig zu bedienen.

Mit Wi-Fi 6 sind Verbesserungen eingeflossen, um mehr Geräten in einem Netzwerk entsprechende Daten simultan senden zu können, sodass die Nutzung für Smart Home-Geräte auch hier in Zukunft sinnvoller ist.

Distributed Compliance Ledger

Ein interessantes Detail an Matter ist der Distributed Compliance Ledger. In dieser verteilten Datenbank bzw. Blockchain befinden sich kryptografisch abgesicherte Daten über die Geräteherkunft, den Status der Zertifizierung sowie wichtige Einrichtungs- und Betriebsparameter.

Eingesehen werden kann die Datenbank unter anderem über eine entsprechende Weboberfläche. Die verwendete Software dafür kann auf GitHub ebenfalls eingesehen werden.

Gelesen werden kann die Datenbank von jedermann während Schreibzugriffe nur Herstellern im Rahmen ihrer Produkte gestattet sind.

In dieser Datenbank, können Hersteller von Produkten Informationen über diese hinterlegen, damit sie von jedermann gelesen werden können. Auch die Ergebnisse von Compliance Tests werden in diese Datenbank geschrieben. Dasselbe gilt für die Compliance Confirmation der CSA.

Für den Nutzer wird der Distributed Compliance Ledger interessant, um zu erfahren, ob ein Gerät als mit dem Standard konform zertifiziert wurde oder um Modellinformationen wie Firmware- und Hardware-Versionen auszulesen. Auch Zertifikate können über die Datenbank bezogen werden, um lokale Zertifikate zu überprüfen.

Die Netzwerktopologie des Distributed Compliance Ledger

Im Kontext des Ledgers existieren unterschiedliche Knoten. Einer dieser Knoten sind Validator-Knoten welche eine komplette Kopie der Datenbank vorhalten. Nicht jeder Knoten kann ein Validator-Knoten sein, er benötigt hierfür eine Erlaubnis. Auch die Anzahl der Validator-Knoten sollte beschränkt sein.

Ein weiterer Knoten ist der Observer-Knoten. Auch dieser enthält eine komplette Kopie der Datenbank und jeder darf einen solchen Observer-Knoten aufsetzen. Daneben existieren noch andere Knoten wie Sentry-Knoten, welche vor Validator-Knoten stehen können und ein Weg des DDoS-Schutzes sind.

Der Client kann sich nun mit einem dieser Knoten verbinden und die benötigten Informationen erfragen. Die Responses sind kryptografisch abgesichert, sodass es keine Rolle spielt, ob sie von einem Observer– oder einem Validator-Knoten kommen.

Technisch setzt das System auf Tendermint bzw. dem Cosmos SDK auf, welches ein Framework für Blockchains zur Verfügung stellt.

Unterstützung

Matter an sich ist noch ein relativ junger Standard und im Moment ist es noch schwierig kompatible Geräte zu finden, auch wenn teilweise schon Updates und Geräte ausgeliefert worden sind. Dies betrifft z. B. einige Geräte von Eve Systems oder Produkte von Nanoleaf mit Matter-Unterstützung.

Interessant ist die Unterstützung auch vonseiten der Betriebssystemanbieter für mobile Systeme, wie iOS und Android. Mit iOS 16.1 lieferte Apple die Unterstützung für Matter aus. Bei Android lieferte Android 13 die ersten Integrationen für Matter.

Auch Smart Speaker wie die Alexa-Serie von Amazon unterstützen mittlerweile Matter, so wurden bereits Updates für einige Modelle ausgerollt, weitere Modelle sollen Anfang 2023 folgen. Einige Geräte fungieren dann auch als Thread-Border-Router und ermöglichen so die Integration von Smart Home-Geräten. Das Gleiche gilt für HomePod minis und den Apple TV 4K, welche ebenfalls Thread unterstützten.

Auch auf Produktseite fangen immer mehr Hersteller an Support für Matter in ihre Produkte einzubauen, so können Entwickler z. B. mit den Philips Hue-Hubs und Geräten in Verbindung mit Matter erste Tests durchführen.

Lizenz

Wer sich Matter anschauen möchte, kann sich die Spezifikation herunterladen, nachdem einige Daten bei CSA hinterlegt worden sind. Ein frei verfügbarer Download existiert nicht.

Ähnlich sieht es auch beim Thread-Standard aus. Hier werden auch entsprechende Hinweise in der E-Mail gegeben:

Please also note, as per the Thread 1.1 Specification EULA, you are prohibited from sharing the document.

Grundsätzlich handelt es sich bei Matter um einen proprietären Standard, der genutzt werden kann, nachdem eine Zertifizierung durchgeführt und die Mitgliedsgebühren für die Connectivity Standards Alliance gezahlt wurden. Offizieller Quellcode rund um Matter ist auf GitHub zu finden und unter der Apache-Lizenz lizenziert.

Problematisch wird das Lizenzierungsmodell des Matter-Standards für GPL-Software, bedingt durch die jährlich zu leistenden Zahlungen an die Connectivity Standards Alliance, welche mit der GPL nicht vereinbar sind.

Migration auf Matter

Interessant wird es auch, wenn ein bestehendes Smart Home auf Matter umgerüstet werden soll. In einem solchen Fall sind bereits Systeme wie Zigbee oder Z-Wave installiert und die Frage stellt sich, wie diese Systeme umgestellt werden können.

Der einfachste Weg wäre es natürlich alle bestehenden Altgeräte auszubauen und anschließend neue kompatible Matter-Geräte einzubauen. Dies wird, ist den meisten Fällen aus Kostengründen und mangels fehlender Praktikabilität kein Weg sein, der gegangen werden kann.

Im Matter-Standard selbst sind für diesen Fall Bridges vorgesehen, mit welchen diese „Altsysteme“ angebunden werden können. Ein Bridge definiert sich im Matter-Standard dadurch, dass sie ein Matter-Knoten darstellen, welcher eines oder mehrere Nicht-Matter-Geräte darstellt.

Ein komplexes Matter-Netzwerk

Über solche Bridges können schlussendlich bestehende Netzwerke eingebunden werden. Daneben lassen sich einige Produkte, welche z. B. Hardware nach dem 802.15.4-Standard verbaut haben oder aber bereits Thread unterstützen per Softwareupdate so upgraden, dass sie mit dem Matter-Netzwerk kompatibel werden.

Problematisch an solchen Bridge-Lösungen ist, dass die Geräte nicht direkt integriert sind und somit unter Umständen parallele Mesh-Systeme im Smart Home existieren. Aber über solche Bridge-Lösungen ist möglich, Stück für Stück in die neue Matter-Welt zu migrieren und so den Migrations-Big-Bang zu vermeiden.

Ausblick und Fazit

Matter hat sich als neuer Standard aufgestellt, um den Smart Home-Markt aufzurollen. Dass mit neuen Standards die alten Standards nicht unbedingt obsolet werden, hatte schon XKCD in einem seiner bekannteren Comics gezeigt.

Doch wie könnte die Zukunft von Matter aussehen? Da sich praktisch jeder größere Smart Home-Anbieter und andere Firmen wie Apple, Amazon, Google und Samsung an Matter beteiligen, könnte Matter das Potenzial haben, den Markt aufzurollen.

Schlussendlich stellt sich hier die Frage nach den Produkten, die mit Matter-Unterstützung auf den Markt gebracht werden und ob diese die Kundenwünsche erfüllen können.

Auch muss der Standard, der in der Theorie übergreifend unterstützt wird und dessen Geräte unabhängig vom Hersteller genutzt werden können, dies noch in der Praxis beweisen. Im schlimmsten Fall ist der Kunde hier wieder der Leidtragende, weil er kleine und größere Inkompatibilitäten ertragen muss.

Im besten Fall führt der neue Standard zu einer Migration alter Lösungen in Richtung Matter. Der Zigbee-Standard ist praktisch ein Legacy-Standard geworden und Z-Wave wird im schlimmsten Fall einen langsamen Tod sterben, da viele Nutzer zu Matter abwandern werden und Z-Wave es schwer haben wird, gegen diesen Standard zu bestehen.

Auch wenn Z-Wave aufgrund der genutzten Funkfrequenzen kleinere technische Vorteile hat, sind dies wahrscheinlich keine Faktoren, welche sich auf Kundenseite auswirken werden. Auch wenn dies in der Z-Wave Alliance anders gesehen wird:

Matter is bringing a lot of attention to the smart home. This makes it easy to overlook Z-Wave as the most established, trusted, and secure smart home protocol, that also happens to have the largest certified interoperable ecosystem in the market. We firmly expect that Z-Wave will play a key role in connecting devices and delivering the experience users really want.

Im Rahmen des Artikels wurde einige Hintergründe von Matter erläutert, trotzdem wurde Matter nur angerissen, da der Standard auf über achthundert Seiten, viele Details definiert und unterschiedlichste Verfahren im Detail erläutert.

Wenn Matter seine Versprechen halten kann und die Nutzung für den Kunden einfacher ist, könnte es ein Standard sein, der ein Großteil der Nutzer und Hersteller in Zukunft hinter sich vereinen könnte.

Dieser Artikel erschien ursprünglich auf Golem.de und ist hier in einer alternativen Variante zu finden.