Der Microsoft Internet Explorer spielt heute keine Rolle mehr – sollte man meinen. Auf Grund von fehlerhaft implementiertem User-Agent-Sniffing auf zu vielen Websites, welche Firefox 110 und höher als Internet Explorer 11 erkennen, sah sich Mozilla gezwungen, den User-Agent von Firefox zu ändern.

Mit jedem Besuch sendet der Browser einen sogenannten User-Agent an die jeweilige Website. Dieser beinhaltet vor allem eine Information darüber, welches Betriebssystem und welcher Browser genutzt wird. Es ist allerschlechteste Praxis einer Website, den User-Agent auszulesen, um Entscheidungen über Funktionalität oder implementierte Code-Pfade zu treffen – und doch machen genau das sehr viele Websites.

Um das Risiko dafür zu minimieren, aber auch aus Privatsphäre-Gründen, um den digitalen Fingerabdruck zu reduzieren, wurde der User-Agent im Laufe der Zeit immer weiter reduziert oder bestimmte Daten auf einen festen Wert eingefroren, was den User-Agent heute bewusst weniger nützlich macht als noch vor vielen Jahren. Andererseits muss jede Änderung mit sehr großer Vorsicht durchgeführt werden, weil die kleinste Änderung auf Grund des zuvor beschriebenen User-Agent-Sniffings wieder neue Kompatibilitätsprobleme auf Websites verursachen kann.

Ein Beispiel für fehlerhaft implementiertes User-Agent-Sniffing ist die Erkennung des Internet Explorers in Version 11. Dessen User-Agent sieht wie folgt aus:

Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; AS; rv:11.0) like Gecko

Einige Websites prüfen stumpf auf das Vorkommen von rv:11 im User-Agent, um daraus zu folgern, dass der Internet Explorer 11 genutzt wird. Das Problem? So hätte der User-Agent von Firefox 110 ausgesehen:

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:110.0) Gecko/20100101 Firefox/110.0

Websites, welche lediglich eine primitive Prüfung wie die eben genannte durchführen, würden damit Firefox 110 als Internet Explorer 11 identifizieren – mit teils schwerwiegenden Folgen, weil diese Websites unter Umständen plötzlich völlig falsche Code-Pfade nutzen und daher nicht mehr korrekt funktionieren.

Aus diesem Grund hat Mozilla einen weiteren Teil des User-Agents von Firefox eingefroren, wie schon das Mozilla/5.0 zu Beginn oder die Version der Browser-Engine Gecko/20100101, zumindest temporär.

Beginnend mit Firefox 110 wird der Teil nach rv: auch in neueren Versionen die Versionsnummer 109 anzeigen, während die hintere Versionsnummer weiterhin korrekterweise die jeweils aktuelle Firefox-Version anzeigen wird. Daraus ergibt sich für Firefox 110 der folgende User-Agent:

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:109.0) Gecko/20100101 Firefox/110.0

Da dieses Problem naturgemäß wieder verschwinden wird, sobald Firefox die Versionsnummer 120 erreicht, wird Mozilla diese Anpassung des User-Agents mit Firefox 120 allerdings wieder entfernen. Firefox 120 wird nach aktueller Planung am 21. November 2023 erscheinen.

Der Beitrag Wegen des Internet Explorers 11: Mozilla ändert User-Agent von Firefox erschien zuerst auf soeren-hentzschel.at.

Viele der Technologien, die wir heutzutage einsetzen, haben eine lange Geschichte hinter sich. Moderne Ansätze, sie nachzurüsten, können in bestimmten Szenarien jedoch unangenehme Auswirkungen haben. Ein kleines Beispiel möchte ich euch heute vorstellen.

Craig Younkins hat in seinem Blog auf Medium ein kurzes Szenario beschrieben, das verschlüsseltes DNS (DoH/DoT) und NTP involviert. Normalerweise gibt es bei so einem Setup wenig Probleme: der Client synchronisiert seine Zeit über NTP, kann Abweichungen ausgleichen und seine DNS-Anfragen über TLS-verschlüsselte Verbindungen abwickeln. Dabei hat der Client jederzeit seine vertrauenswürdigen Zertifikate lokal gespeichert, ebenso die Standardserver für NTP, die üblicherweise durch einen Hostname nach dem Muster *.pool.ntp.org adressiert werden.

Das Problem

Der Fallstrick: vergisst der Client die Zeit komplett, kann er in einem Deadlock landen und gegebenenfalls die Zeit nicht mehr synchronisieren. So ein Szenario kann auftreten, wenn ein System ausgeschaltet wurde und keine Real-Time-Clock in der Hardware verbaut wurde, die über eine eigene Batterieversorgung (i. d. R. Knopfzelle) verfügt. Bei einigen günstigen Routern bzw. IoT-Geräten wie dem Raspberry Pi ist das der Fall.

Findet das System keinen Anhaltspunkt über die aktuelle Zeit, so startet es, je nach Implementierung, meist beim Unix-Timestamp 1 bzw. am 01.01.1970. Dies kann jedoch in Verbindung mit TLS eine gefährliche Wirkung entfalten, da für die Zertifikatsvalidierung auf das aktuelle Datum zurückgegriffen wird – schließlich verfügen die meisten Zertifikate über einen festen Gültigkeitszeitraum, der nur wenige Monate umfasst.

Das Ergebnis: alle mit TLS abgewickelten DNS-Anfragen über die NTP-Server schlagen fehl. Dabei ist hervorzuheben, dass NTP selber unverschlüsselt weiterhin abläuft, es können lediglich die IP-Adressen der Server nicht ermittelt werden.

Lösungen

Damit soetwas nicht passiert, können Administratoren auf verschiedene Art und Weise vorbeugen. Eine erste Möglichkeit wäre, wie im Artikel beschrieben, das Hinterlegen von IP-Adressen im NTP-Client. Damit umgeht man DoH/DoT und kann direkt mit der NTP-Synchronisation fortfahren. Nachteil dieser Variante ist jedoch, dass es einerseits nur wenige NTP-Server mit wirklich statischen Adressen gibt (einer der wenigen Anbieter ist z. B. die NIST) und andererseits NTP generell eher auf Hostnames arbeitet, um z. B. einen Lastausgleich sicherzustellen.

Die zweite Variante wäre der Einsatz spezieller DHCP-Optionen wie Option 42, mit der beim Bezug der Netzwerkkonfiguration auch durch den DHCP-Server bestimmte IPv4-Adressen empfohlen werden können. In der Regel handelt es sich um lokale IPv4-Adressen, wenn lokal ein eigener NTP-Server betrieben wird, der seine Zeit mit höherrangigen Servern wiederum synchronisiert. DHCPv6 verfügt mit Option 56 über ein Äquivalent. (Q, RFC 2132 sec. 8.3., RFC 5908)

Es gibt allerdings auch spannendere Methoden: so ist der Ansatz von tlsdate, die Zeit über den TLS-Handshake von Internetdiensten wie Google oder Wikipedia zu extrahieren. Darüber hinaus wird momentan bei der IETF die Entwicklung von roughtime vorangetrieben, das hierfür ein eigenes kryptographisches Protokoll einsetzt. (Q, draft-ietf-ntp-roughtime-07, Artikel von Cloudflare)

Wer ein Dateisystem wie ext4 nutzt, findet darüber hinaus im Superblock aus dem vergangenen Mount hilfreiche Zeitangaben. Diese mount time und write time werden nämlich in der Regel bei jedem Mount und Schreibvorgang gesetzt und können als Anhaltspunkt für die Systemzeit des vergangenen Starts dienen - genug, um bei regelmäßig verwendeten Systemen immerhin die DoH-Anfrage für die initiale NTP-Namensauflösung abzuwickeln. (Q)

Fazit

Verschiedene komplexe Komponenten wie DoH/DoT und NTP können bei bestimmten Randbedingungen zu Situationen führen, die man bei der Erstkonfiguration vermutlich nicht vor Augen hatte. Wer jedoch mit dafür anfälligen Systemen ohne Real-Time-Clock arbeitet, kann auf verschiedene Strategien zur Abhilfe setzen: einerseits können Anhaltspunkte für die Zeit aus dem vergangenen Start gesucht werden oder zunehmend Protokolle genutzt werden, die genau dieses Problem adressieren.

Wenn alles normal läuft, dann läuft alles normal. Aber was ist schon normal. Für die außergewöhnlichen Momente, wie z.B. eine große Last auf dem Server, gibt es schöne Parameter, die man System Daemons mitgeben kann. Eines davon ist CPUQuota=XYZ%

Unter Debian werden die Systemdienste, die mit systemctl start/stop/reload/daemon-reload usw gesteuert werden unter /etc/systemd/system/ als Dateien gespeichert. Diese sehen dann z.B. so aus (zur Unbrauchbarkeit veränderter ttrss Service)

[Unit]
Description=ttrss_backend
After=network.target mysql.service postgresql.service

[Service]
User=www-dieter
ExecStart=/PFADERSATZ/update_daemon2.php --tasks 3 --intervall 10800 --quiet
StandardOutput=null
CPUQuota=20%

[Install]
WantedBy=multi-user.target

Dieser Dienst mit systemctl start ttrss.service gestartete Dienst, startet einen Daemon, der alle 10800 Sekunden neue Daten aus dem Netz zieht.

Betrachtung bei einer CPU

Damit der Server sich nicht selbst überlastet, bekommt der Dienst (Service) eine CPU Quota mit (CPUQuota), der dafür sorgt, dass die CPU relativ, also in in Abhängigkeit der gerade stattfindenden CPU Nutzung, nicht mehr als 20% der CPU genutzt werden.

In der Realität sieht das mit CPUQuota=20% so aus:

CPU wird gerade zu 0% genutzt = ttrss bekommt 20% der CPU
CPU wird gerade zu 90% genutzt = ttrss bekommt 10% der CPU
CPU wird gerade zu 70% genutzt = ttrss bekommt 20% der CPU
CPU wird gerade zu 85% genutzt = ttrss bekommt 15% der CPU

Multi CPU System

Sind mehr CPUs in einem System gilt für jede CPU 100%. Das bedeutet

1 CPU = 100% verfügbar
2 CPUs = 200%
3 CPUs = 300%

Setzt mal also bei 3 CPUs CPUQuota=144% bekommt der Dienst auch 144% der CPUs (falls verfügbar). Wenn weniger CPU Power zur Verfügung steht, dann natürlich auch weniger.

Ich bin mir nicht sicher, aber es sieht bei einer oberflächlichen Betrachtung aus, als würden mehrere Threads eines solchen Services auch auf mehrere CPUs verteilt werden, aber dennoch mit dem Limit 20% über alle CPUs. Was ja auch eine schöne Sache ist.

Wird CPUQuota=0 gesetzt, wird diese Funktion deaktiviert.

Auszug aus der Definition
zu finden mit dem Konsolenbefehl man systemd.resource-control

Assign the specified CPU time quota to the processes executed. Takes a percentage value, suffixed with “%". The percentage specifies how much CPU time the unit shall get at maximum, relative to the total CPU time available on one CPU. Use values > 100% for allotting CPU time on more than one CPU. This controls the “cpu.max” attribute on the unified control group hierarchy and “cpu.cfs_quota_us” on legacy. For details about these control group attributes, see Control Groups v2[2] and CFS Bandwidth Control[4]. Setting CPUQuota= to an empty value unsets the quota.

Example: CPUQuota=20% ensures that the executed processes will never get more than 20% CPU time on one CPU.

Fr, 30. Dezember 2022, Fabian Schaar

Zum Ende des Jahres hat das Siduction-Projekt eine neue Version der gemeinschaftlich entwickelten Distribution veröffentlicht. Durch die Bindung an den rollenden „unstable“-Zweig von Debian GNU/Linux handelt es sich dabei um ein fortlaufend aktualisiertes Betriebssystem. Entgegen anderer rollender Distributionen setzt Siduction stark auf die eigene Gemeinschaft und versucht dabei, nicht in elitäre Verhaltensmuster zu verfallen.

Ein rollendes Debian mit langer Geschichte

Siduction hat eine lange Tradition: Ursprünglich von der einst Knoppix-basierten Distribution Kanotix abstammend, spaltete sich eine Gruppe von Entwicklern nach einem dortigen Kurswechsel von der zuvor rollenden Distro ab und kochte fortan mit „Sidux“ ein eigenes Süppchen.

Durch anhaltende Probleme mit dem beigeordneten Sidux e.V. wurde die Distribution einige Jahre später in „Aptosid“ umbenannt. Im Jahre 2011 folgte daraufhin ein weiterer Fork und Siduction entstand als Community-fokussiertes Sid-Derivat.

Heute weist Siduction eine treue Nutzergemeinschaft auf, auch wenn es nicht unbedingt in den Linux-Mainstream gezählt werden kann. Das mag vielleicht auch daran liegen, dass sich die Distribution nicht wirklich an blutige Anfänger, sondern eher an ambitionierte Anwender richtet, wobei natürlich jeder willkommen ist, die Software zu nutzen und ein Teil der Gemeinschaft zu werden.

Debian Sid und Siduction sorgen für aktuellste Software

Nach einem eher ruhigen vergangenen Jahr stellt Siduction 2022.1 „Masters of War“ die erste Veröffentlichung seit Monaten dar. Mit dem Codenamen besinnt sich das Entwicklerteam auf frühere Namesgebungen der eigenen Veröffentlichungen: „Masters of War“ bezieht sich auf den 1963 veröffentlichten Song von Bob Dylan -- warum genau dieses Lied als Namespate gewählt wurde, erklärt sich angesichts der momentanen Weltlage wohl von selbst.

Die aktuelle Veröffentlichung kommt mit einigen interessanten Änderungen und neuen Funktionen daher. Unterstützend wirkt dabei auch das angenehme Artwork, das auf das kommende Debian „Bookworm“-Hintergrundbild anspielt und die bisherige visuelle Identität der Distribution wahrt.

Auch wenn Versionsveröffentlichungen bei rollenden GNU/Linux-Distributionen eine weniger zentrale Rolle einnehmen als bei ihren statisch herausgebrachten Kollegen, sind neue Hauptveröffentlichungen gerade bei Siduction sehr gern gesehen, erleichtern sie doch den Einstieg in die Distribution.

Neueinsteigern und interessierten älteren Hasen stehen dabei Installationsabbilder mit den grafischen Oberflächen KDE Plasma in der topaktuellen Version 5.26.4 (KDE Frameworks 5.101, KDE Gear 22.12), Xfce in der jüngst herausgekommenen Ausgabe 4.18 sowie mit der leichtgewichtigen Arbeitsumgebung LXQt in Version 1.2.0 bereit.

Wer es minimaler mag, kann auf die Xorg-Variante mit Calamares als grafischem Installationsprogramm oder die noch abgespecktere noX-Edition zurückgreifen. Letztere muss allerdings im Textmodus auf die Platte gebannt werden.

Im Gegensatz zum regulären Debian Sid (oder „unstable“) verwendet Siduction stets den aktuellsten Linux-Kernel mit eigenen Patches, hauptsächlich aus der Backstube des Kernel-Bäckers Torsten Wohlfarth. Ein besonderes Augenmerk wird bei den Siduction-Kerneln auf den Anwendungsbereich des Linux-Desktop gelegt. Zum Zeitpunkt der Veröffentlichung liefert Siduction 2022.1 Linux in Version 6.1 aus, wobei sich auch die regulären Debian-Kernel sowie ältere Veröffentlichungsstände installieren lassen.

Nützliches für den Hobby-Admin

Neben den Sprüngen in den Versionsständen bringt die neue Siduction-Ausgabe drei wesentliche neue Änderungen mit: Einerseits erleichtert der „Siduction chroot helper“ nun den eigentlich etwas umständlichen Prozess, von einem Live-Medium aus auf eine bereits bestehende Festplatteninstallation zu wechseln.

Konkret liefert Siduction hier einen Schnellstarter über den Schreibtisch der Live-Oberfläche aus; ein Nutzer kann einfach darauf klicken und wird nach einer Warnmeldung und einer kurzen grafischen Abfrage direkt in eine chroot-Umgebung weitergeleitet.

Das ist gerade bei einer rollenden Distribution ein wahrer Segen, immerhin lassen sich ein paar Probleme nur von außen Lösen, zum Beispiel, wenn es um das Init-System oder den Bootloader geht.

Des Weiteren integriert die neue Version die alternative Paketverwaltung „nala“ besser in das System. Diese wird in den Veröffentlichungshinweisen als „apt on steroids“ beschrieben und sei vor allem übersichtlicher aber auch schneller als das althergebrachte apt aus der Debian-Welt.

Die Befehle, mit denen man nala herumkommandiert, gleichen denen von apt sehr, wodurch sich das Werkzeug leicht als Ersatz nutzen lässt. In seiner standardmäßigen Konfiguration ist nala auf Sid ausgelegt, was Siduction sehr entgegenkommen dürfte.

Wer lieber auf die gewohnten Lösungen rund um apt setzt, kann das natürlich auch weiterhin tun. Für Einsteiger wurde ein Abschnitt zu nala im umfassenden Siduction-Handbuch hinzugefügt. Dieses führt Endanwender oftmals sehr ausgiebig in Siduction ein und hilft bei vielen Kleinigkeiten, insbesondere, was die fortlaufende Administration des eigenen Systems angeht.

Eine weitere Neuerung betrifft „Snapper“, das dem ein oder anderen vielleicht von openSUSE bekannt vorkommen könnte. Snapper erleichtert kurz zusammengefasst die Handhabung von btrfs-Snapshots, über die sich ein (rollendes) System problemlos auf einen früheren Zustand zurückfahren lässt. Voraussetzung dafür ist natürlich eine Installation, die das b-tree-Dateisystem (kurz btrfs) verwendet. Das lässt sich, gerade bei einer Installation auf der gesamten Festplatte, vergleichsweise einfach über den mitgelieferten Calamares-Installer einrichten.

„The community based OS“

Genauere Informationen zur aktuellen Veröffentlichung bieten die offiziellen Release Notes von Ferdinand Thommes (aka devil). Wer sich als Neueinsteiger für Siduction, das freundliche rollende Debian, interessiert, sollte einen Blick auf das Siduction-Handbuch werfen. Dieses steht in deutscher und englischer Sprache zur Verfügung.

Weitere Anlaufstellen bieten das Forum und die IRC- bzw. Matrix-Kanäle des Projekts. Dort ist nicht nur Platz für Hilfegesuche und Bitten; Anwenderinnen und Anwender können sich auch aktiv an der zukünftigen Entwicklung von Siduction beteiligen.

Die aktuelle Version kann von der offiziellen Webseite des Projekts heruntergeladen werden:
https://siduction.org/installation-media/

Quellen:

Offizielle Veröffentlichungshinweise für Siduction 2022.1:
https://siduction.org/2022/12/release-notes-fur-siduction-2022-1-masters-of-war/

Siduction-Handbuch:
https://manual.siduction.org/

Siduction-Forum:
https://forum.siduction.org/

Zur Siduction-Geschichte:
https://siduction.org/2011/08/warum-wir-aptosid-forken/

Bild:

Siduction Logo von Andreas Weber, Coruja via Wikimedia Commons; CC BY-SA:
https://commons.wikimedia.org/wiki/File:Siduction_Logo.svg

Moderne Touchpads und Touchscreens erkennen wenn mehere Finger auf das entsprechende Gerät gelegt werden. So ist es schon länger möglich mehr als nur die Maus von rechts nach links oder im Browser die Seite von oben nach unten zu schieben. Das nennt sich dann Gesten oder auf englisch Gestures oder ab 2 Fingern, eigentlich ab 3 gleichzeitig dann Multitouchgestures. Fenster mit einem Wisch minimieren, maximieren, schliessen, Vollbild, alle Fenster anzeigen usw usf.

Wer so ein Gerät, Notebook mit Touchpad, externes Touchpad oder einen Touchscreen hat, wil eigentlich von diesen Featuren profitieren, denn das reduziert den Wechsel zur Tastatur, oder das Rumgeschiebe mit der Maus oder sogar die Bewegung auf dem Touchpad/-screen selbst. Beispiele wie das aussieht sind auf der Projektseite zu sehen.

Vorweg sei gesagt, dass diese Lösung hier nicht mit dem neuen Displayserver Wayland getestet sind und dort vermutlich nicht laufen. Gedacht ist diese Lösung für den X11 Server (Standard). Ich habe sie unter Kubuntu 22.04 LTS erfolgreich eingerichtet, auch wenn die meisten Beschreibungen mit Ubuntu betitelt sind.
Für KDE gibt es eine weitere Konfiguration, die ich selbst aber nicht nutze.

Die Installation ist recht einfach.

Es muss ein Treiber “Touchégg” installiert werden. Ein 3 Zeiler, in dem erst das Software Repository hinzugefügt, dann die Quellen aktualisiert und schließlich die Anwendung installiert wird. Bitte zur Sicherheit der Installationsanweisung auf der Projektseite folgen. Diese Anweisungen stimmten zur Erstellungszeit des Artikels.

sudo add-apt-repository ppa:touchegg/stable
sudo apt update
sudo apt install touchegg

Für andere Linuxdistributionen sind die entsprechenden Aktionen ebenfalls auf der Projektseite aufgeführt.

Danach das graphische Konfigurationsprogramm “Touché” per Flathub mit dem Programm Discover installieren.

Der Systemdienst touchegg sollte gestartet werden. Wenn du nicht weisst, wie das geht, dann kannst du einfach deinen Computer neu starten. Oder du versuchst es auf der Konsole mit dem Befehl sudo systemctl start touchegg.service

Weitere Informationen

1. In Touché können Tastenkürzel angegeben werden. Dort kann man dann nach Herzenslust alle möglichen Tastenkürzel angeben, die auch in den Systemeinstellungen für diverse Aktionen hinterlegt sind, wie z.B. Strg+F10 um alle Fenster anzuzeigen.
2. Ich habe hier im Blog schon mal einen Artikel über das Thema Gesten geschrieben und wie ich das manueller direkt über libinput konfiguriert habe
3. Leider gibt es keine wirklich einfache bzw universelle Methode herauszufinden, wieviele Finger (touches) das Touchpad oder der Touchscreen unterstützt. Einige benutzen xinput (wie in meinem alten Blogartikel beschrieben), andere benutzen die geist-tools, die aber bei mir mit einem Pythonfehler den Dienst quittierten. Eine vielleicht noch hilfreiche Quelle mit Informationen ist das Archlinux Wiki
4. Ansonsten einfach ausprobieren. Mehr als dass es nicht funktioniert, kann eigentlich nicht passieren.