ubuntuusers.de

23. März 2024

Bei KDE wurde kürzlich eine Sicherheitslücke bekannt, die wohl erstmal offen bleiben wird. Komponenten aus dem KDE-Store, der sich an verschiedenen Stellen hinter der Schaltfläche “Neue holen…” in verschiedenen KDE-Komponenten verbirgt, können Schadcode enthalten und in den Benutzerdaten wüten.

Im konkreten Fall handelte es sich nicht um einen absichtlichen Angriff. Es handelte sich lediglich um einen Fehler. Die Ursache liegt in einer KDE-Funktionalität. Benutzer von Plasma können über den KDE-Store Themes, Widgets und Miniprogramme beziehen. Diese werden zwar nur mit Benutzerrechten installiert, können aber funktionsbedingt ziemlich uneingeschränkt Skripte etc. im jeweiligen Home-Verzeichnis ausführen. KDE benötigt dies, da nicht alle Themes und Miniprogramme über die Distributionen paketiert werden können.

Der Vorfall zeigt einmal mehr, dass Linux auf dem Desktop ein ziemlicher Ponyhof ist. Wenn man es schonungslos auf den Punkt bringt, sieht es so aus: Die KDE-Entwickler bauen eine Sideload-Option für bösartigen Code ein, es fällt jahrelang niemandem auf und nachdem es dann doch auffällt, ist die erste Reaktion im Tenor: “Da kann man nichts machen, ohne die Funktionalität einzuschränken”. Die Nutzer müssen einfach aufpassen und vielleicht kann es eine Warnung geben. Eine Kuratierung wäre wünschenswert, ist aber nicht so schnell umsetzbar und bindet Ressourcen.

Die Nachlässigkeit bei KDE ist die eine Seite der Medaille. Sie ist vermutlich auch deshalb nicht so schlimm, weil diese KDE-Funktion nie besonders exzessiv genutzt wurde und die meisten Anwender mit dem arbeiten, was standardmäßig mitgeleifert wird, weil das bei KDE schon sehr viel ist. Kombiniert wird diese Nachlässigkeit bei KDE mit der immer noch völlig unterschätzten Gefahr fehlender Rechtebeschränkungen innerhalb des Benutzerverzeichnisses. Immer noch geben sich zu viele Linux-Anwender der Illusion hin, dass Schadcode nur dann gefährlich ist, wenn er mit Administratorrechten ausgeführt wird. Ein massiver Datenverlust im Home-Verzeichnis reicht bei nachlässigen Backups aus (und die meisten Anwender sind nachlässig bei Backups). Programme werden unter Linux traditionell kaum eingehegt, sondern können im Home-Verzeichnis nach Belieben schalten und walten.

Machen wir uns nichts vor. Im Falle eines größeren Malware-Drucks wären solche Funktionen fatal und würden massiv ausgenutzt.

Der Artikel Kommentar: Sicherheitsprobleme bei KDE erschien zuerst auf Curius

22. März 2024

In den letzten Blogposts habe ich gezeigt, wie ich mein privates VPN mit openVPN aufsetze. In diesem Post wiederhole ich das - nur eben mit Wireguard.

OpenVPN und Wireguard können auch problemlos nebeneinander laufen, wenn sie verschiedene Netzmasken benutzen. So hat man jeweils ein Fall-Back-Netz, mit dem man die Clients noch erreichen kann.

Auf dem Handy verbraucht openVPN mehr Strom, weil die Kryptosachen stärker sind. Wireguard ist da schlanker bei ausreichender Verschlüsselung.

VPN

Mein Wireguard-VPN soll unter den Netzen 10.3.3.0/24 und fd04:bab0:3::/64 laufen. Alle Clients sollen sich gegenseitig sehen und anpingen können. Auf Wunsch soll der gesamte Traffic über das VPN geroutet werden.

Installation

Unter Ubuntu lässt sich Wireguard auf Server und Clients wie folgt installieren:

#Ubuntu
apt install wireguard
 
#Arch, btw
pacman -S wireguard-tools

Schlüssel erzeugen

Auf meiner Zertifikationsinstanz (oder auf jedem anderen Rechner) erstelle ich mir einen neuen Ordner und erzeuge für den Server sowie für jeden Client ein Paar aus privatem und öffentlichem Schlüssel.

sudo bash
umask 077 && wg genkey | tee server-private.key | wg pubkey > server-public.key
umask 077 && wg genkey | tee client1-private.key | wg pubkey > client1-public.key
umask 077 && wg genkey | tee client2-private.key | wg pubkey > client2-public.key
umask 077 && wg genkey | tee client3-private.key | wg pubkey > client3-public.key

Die Inhalte der Schlüsseldateien werden gleich plaintext in die Configdateien geschrieben.

Server aufsetzen

Nach der Installation existiert das Verzeichnis /etc/wireguard. In diesem Verzeichnis liegen die .conf-Dateien der VPNs, egal ob Server oder Client. Der Name der .conf-Datei entscheidet über den Namen der Interfaceschnittstelle. Benenne ich die Datei foobar.conf, so wird ein Tunneldevice mit dem Namen foobar erzeugt. Die Datei tun0.conf erzeugt ein Interface mit dem Namen tun0. Standardmäßig (also in den Manuals im Netz) werden für Wireguard wg0-Interfaces erzeugt.

Wir erzeugen also die Datei wg0.conf und geben ihr folgenden Inhalt:

# ---------- Server Config ----------
[Interface]
## welche IP4-Adresse hat der Server im Tunnel?
Address = 10.3.3.1/24

## welche IPv6-Adresse hat der Server im Tunnel?
Address = fd04:bab0:3::1/64 

# Wenn ihr iptables nutzt, dann wird hier das NAT zum Internet klargemacht
# Mein Device heisst eth0, eures auch? ansonsten ändern!
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -s 10.3.3.0/24 -o eth0 -j MASQUERADE; ip6tables -A FORWARD -i wg0 -j ACCEPT; ip6tables -t nat -A POSTROUTING -s fd04:bab0:3::/64 -o eth0 -j MASQUERADE 
# Sobald der VPN beendet wird, werden die iptables Regeln rückgängig gemacht
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -s 10.3.3.0/24 -o eth0 -j MASQUERADE; ip6tables -D FORWARD -i wg0 -j ACCEPT; ip6tables -t nat -D POSTROUTING -s fd04:bab0:3::/64 -o eth0 -j MASQUERADE

# Hier kommt der private Key des Servers hin, in Plaintext
PrivateKey = OHUJätschibätschifasfdeg92wz4CvFqlWWUW74dfgM5+zPfuEU=
# Auf welchem Port soll der Server lauschen?
# Diesen Port in der Firewall freigeben!
ListenPort = 45881 

## Für jeden Client kommt hier eine eigene Identifikation
[Peer] # Client1
# Schreibe hier den öffentlichen Schlüssel des Client1 hinein
PublicKey = AfuckAfDfejoqfooobaaarmHILbtoxReB6ZjzNuMtyYNxlM= 
# Mit welchen IP4 und IPv6-Adressen soll sich der Client verbinden?
# Hier müssen ein /32  und /128 verwendet werden (= genau 1 IP-Adresse erlaubt)
AllowedIPs = 10.3.3.2/32, fd04:bab0:3::2/128 


# Hier wiederholt sich das Ganze für Client2
[Peer] # CLient2
# Client public key
PublicKey = 1xejE9Z2OnkqkuckuckFcOsoLA623M1yRr+7/v7SmAtP36UmG8=  
# IPs client can connect as (IPv4 /32  and IPv6 /128)
AllowedIPs = 10.3.3.3/32, fd04:bab0:3::3/128 

[Peer] # Client3
# Client public key
PublicKey = sCid523sdfXwQHoErOyXyIk8UNEz36aff7+R9MIU8Xm4wc=  
# IPs client can connect as (IPv4 /32  and IPv6 /128)
AllowedIPs = 10.3.3.4/32, fd04:bab0:3::4/128 
  • Der Server lauscht unter IP4 und IPv6 auf Port 45881. Ihr könnt auch irgendeinen anderen Port auswählen.
  • Der Server wird unter den Adressen 10.3.3.1/24 und fd04:bab0:3::1/64 über den Tunnel ereichbar sein. Ebenso haben derzeit 3 Clients Zugriff, wobei jeder Client eine fixe IP4 und IPv6 im Tunnelnetz erhält.
  • Bei den AllowedIPs ist euch sicherlich aufgefallen, dass bei IP4 ein /32 und bei IPv6 ein /128 hinter die Adresse geschrieben werden muss.
    • Auf dem Server fungiert AllowedIPs ähnlich wie ein Router und gibt an, wohin der Datenverkehr geroutet werden soll. Daher genügt die Angabe von /32 oder eben /128 (genau eine IP-Adresse).
    • In der gleich folgenden Client-Config fungiert AllowedIPs wie eine Access-Controll-List. Daher muss in der Client-Config ein /24 bzw. /64 definiert werden, um alles von 10.3.3.* bzw. fd04:bab0:3:: zu akzeptieren.
  • Soll ein weiterer Client hinzugefügt werden, muss in der Server-Config ein neuer [Peer]-Block mit dem puplic key des neuen Clients hinzugefügt werden.

Server starten

Ähnlich wie bei openVPN liest systemd das Verzeichnis /etc/wireguard aus und macht alle dort befindlichen MY-VPN.conf-Dateien verfügbar über den Service wg-quick@MY-VPN.service.

Wir können unseren wg0-Server starten mittels:

# Starten
systemctl start wg-quick@wg0.service
# Logs ansehen
journalctl -u wg-quick@wg0.service -f

Firewall anpassen

Falls ihr eine Firewall benutzt (und ich hoffe doch sehr, dass dies der Fall ist), muss diese für Wireguard angepasst werden. Einerseits muss der Server-Port freigegeben werden (ich habe da ja 45881), anderseits müssen wir intern NAT einrichten, wenn der Internetverkehr über den Tunnel geroutet werden soll.

iptables

Die iptables-Firewall muss auf dem Server und auf den Clients angepasst werden, damit openVPN funktioniert:

## Akzeptiere Pakete von den wg+ Interfaces
iptables -A INPUT -i wg+ -j ACCEPT
iptables -A FORWARD -i wg+ -j ACCEPT

## auf dem Server muss Port 45881 tcp/udp geöffnet werden
iptables -A INPUT -i eth0 -p tcp --dport 45881 -j ACCEPT
iptables -A INPUT -i eth0 -p udp --dport 45881 -j ACCEPT

Wenn euer Device nicht eth0 heisst, müsst ihr den Befehl entsprechend anpassen.

ufw

Die ufw-Firewall muss auf dem Server angepasst werden, damit Wireguard funktioniert. Zunächst muss der Serverport freigegeben werden:

sudo ufw allow 45881

Anschließend müssen drei weitere Dateien editiert werden, damit das Netz funktioniert.

  1. /etc/default/ufw
nano /etc/default/ufw 

DEFAULT_FORWARD_POLICY="ACCEPT"

2a. /etc/ufw/before.rules, füge die folgenden Zeilen vor der *filter-Sektion ein, um das NAT für IPv4 zu aktivieren:

nano /etc/ufw/before.rules

# NAT-Tabelle hinzufügen
*nat
:POSTROUTING ACCEPT [0:0]
# OpenVPN-Regeln hinzufügen
-A POSTROUTING -s 10.3.3.0/24 -o eth0 -j MASQUERADE
COMMIT

2b. /etc/ufw/before6.rules, füge die folgenden Zeilen vor der *filter-Sektion ein, um das NAT für IPv6 zu aktivieren:

nano /etc/ufw/before6.rules

# NAT-Tabelle hinzufügen
*nat
:POSTROUTING ACCEPT [0:0]
# OpenVPN-Regeln hinzufügen
-A POSTROUTING -s fd04:bab0:3::/64 -o eth0 -j MASQUERADE
COMMIT

Wenn euer Device nicht eth0 heisst, müsst ihr den Befehl entsprechend anpassen. Und falls ihr diese Einstellung gerade getroffen habt, könnt ihr in der wg0.conf des Servers die Parameter PostUp und PostUp wieder auskommentieren.

  1. /etc/ufw/sysctl.conf
nano /etc/ufw/sysctl.conf

net/ipv4/ip_forward=1
net/ipv6/conf/default/forwarding=1
net/ipv6/conf/all/forwarding=1

Client einrichten

Auf den Clients erzeugen wir ebenfalls die Datei /etc/wireguard/wg0.conf und geben ihr diesen Inhalt:

# -------- Client Config ------------------
[Interface]
# IP4 Adresse des Clients, so wie in der Server-Config angegeben (/32!)
# Dieser Client bekommt 10.3.3.2
Address = 10.3.3.2/32 
# IPv6 Adresse des Clients (use /128!)
# Dieser Client bekommt fd04:bab0:3::2
Address = fd04:bab0:3::2/128 
# Der Private Key von Client1 im Plaintext
PrivateKey = GNJJAJT0MQnxRHga8Rzp/hLGoCtsefljhelahDks6EMD8Vw= 


[Peer]
# Wie ist der Server erreichbar? Adresse und Port
#Endpoint = [2a02:08:15:4500:fckafd:4]:45881
#Endpoint = 192.168.0.1:45881
Endpoint = vpn.myserver.org:45881

# Der öffentliche Schlüssel des Servers im Plaintext
PublicKey = emV/wFCKAFD4WIyakB/JEi7jp9wH7zBCi81W+qjuMkWc= 

# Sende alle x Sekunden einen Ping an das Netz 
# um den Tunnel aufrecht zu erhalten. 
# Sollte NIE auf dem Server gesetzt werden, 
# sondern nur dort, wo auch "Endpoint" definiert ist. 
# Also hier im Client...
PersistentKeepalive = 5

# Was soll durch den Tunnel geroutet werden?
## Option 1: nur Tunnelkrams durch den Tunnel routen
AllowedIPs = 10.3.3.0/24, fd04:3::/64 
## Option 2: ALLES durch den Tunnel routen
#AllowedIPs = 0.0.0.0/0, ::/0 
  • Diese Datei muss ich nun bei jedem Client nach dem selben Muster anlegen.
  • Der Client erhält seine fest IP4 und IPv6 über den Tunnel
  • Dieses Mal müssen unter Address jeweils ein /32 bzw /128 vergeben werden (= 1 IP Adresse).
    • Der Parameter AllowedIPs fungiert im Clientmodus wie eine Access-Controll-List. Daher wird an dieser Stelle wieder ein /24 bzw. /64 definiert, um alles von 10.3.3.* bzw. fd04:bab0:3:: über den Tunnel zu routen.
  • Soll der gesamte Datenverkehr über den VPN-Tunnel geroutet werden, muss die zweite AllowedIPs-Zeile aktiviert (und die darüberstehende auskommentiert) werden.

Android

Für mein Handy erstelle mich mir wie oben beschrieben ein Schlüsselpaar und generiere mir eine Clientconfig wie oben, wobei ich die zweite AllowedIPs-Option wähle (alles übers VPN routen). Diese wg0.conf übertrage ich per KDE Connect auf mein Handy.

Als App installiere ich mittels F-Droid WG Tunnel von Zane Schepke, da die Original-Wireguard-App Ende 2023 aus dem F-Droid-Repository geflogen ist (weil sie einen integrierten Aktualisierer bekommen hat, der standardmäßig aktiviert ist und nicht transparent angibt, von wo aus er Aktualisierungen herunterlädt; noch fragt er um Zustimmung).

Jetzt kann ich einfach die übertragene wg0.conf-Datei in der App importieren, und alles funktioniert bestens. Ok, in den App-Einstellungen musste ich noch “Tunnel on untrusted wifi” und “Tunnel on mobile data” aktivieren, dann hat es aber sofort funktioniert.

“Tunnel on untrusted wifi” und “Tunnel on mobile data” aktivieren

Weblinks


Diskussion per Matrix unter https://matrix.to/#/#produnis-blog:tchncs.de

 

Mozilla hat Firefox 124.0.1 veröffentlicht und behebt damit zwei kritische Sicherheitslücken, welche im Rahmen des Hacking-Wettbewerbs Pwn2Own demonstriert worden sind.

Download Mozilla Firefox 124.0.1

Wieder einmal fand ein Pwn2Own-Wettbewerb im Rahmen der CanSecWest Sicherheitskonferenz in Vancouver statt. Und wie bereits im Vorfeld erwartet, hat Mozilla in Form eines schnellen Updates (weniger als 24 Stunden) auf die Firefox betreffenden Ergebnisse reagiert. Firefox 124.0.1 behebt zwei Sicherheitslücken, welche Mozilla beide als kritisch einstuft. Ebenfalls in diesem Zusammenhang veröffentlicht wurde Firefox ESR 115.9.1.

Der Beitrag Sicherheits-Update Firefox 124.0.1 veröffentlicht erschien zuerst auf soeren-hentzschel.at.

20. März 2024

Mozilla hat Firefox 124 für Windows, Apple macOS und Linux veröffentlicht. Dieser Artikel fasst die wichtigsten Neuerungen zusammen – wie immer auf diesem Blog weit ausführlicher als auf anderen Websites.

Download Mozilla Firefox für Microsoft Windows, Apple macOS und Linux

Offene Tabs in Firefox View sortieren

Die mit Firefox 106 eingeführte und mit Firefox 119 stark verbesserte Funktion Firefox View hatte mit Firefox 123 eine Suchfunktion sowie verbesserte Performance erhalten. Firefox 124 bringt eine weitere Verbesserung: Im Reiter der offenen Tabs ist es ab sofort möglich, diese wahlweise nach der neuesten Aktivität oder nach der Tab-Reihenfolge zu sortieren.

Plattform-Verbesserungen auf Apple macOS

Firefox auf macOS nutzt nun endlich auch die native Vollbild-Schnittstelle des Apple-Betriebssystems, womit sich Firefox in bestimmten Aspekten mehr so verhält, wie man es unter macOS erwartet.

Seit macOS 14 zeigt das Apple-Betriebssystem ein Kamera-Symbol in der Menüleiste an, wenn der Kamera-Zugriff für eine Website aktiviert ist. Firefox selbst zeigt ebenfalls ein Kamera-Symbol in der Menüleiste an. Über die neue Option privacy.webrtc.showIndicatorsOnMacos14AndAbove in about:config auf false kann der Indikator, der von Firefox kommt, auf macOS 14 und höher deaktiviert werden.

Die Schriftgröße in Dialogen auf macOS war bisher sehr klein. Hier verwendet Firefox ab sofort eine etwas größere Schrift.

Sonstige Endnutzer-Neuerungen von Firefox 124

Die Textcursor-Steuerung, welche durch Drücken der Taste F7 aktiviert werden kann, funktioniert jetzt auch in PDF-Dateien.

Die Suchmaschine Qwant steht nicht mehr nur bei Verwendung der französischen Sprache, sondern ab sofort auch für Nutzer anderer Sprachen in Frankreich sowie für Nutzer in der Schweiz, Belgien, Italien, den Niederlanden sowie Spanien standardmäßig zur Verfügung.

Für Nutzer, welche die separate Suchleiste aktiviert, aber seit mindestens 120 Tagen nicht genutzt haben, wird diese automatisch aus der Oberfläche entfernt.

Firefox geht jetzt besser mit Änderungen der Netzverbindung um, zum Beispiel bei Aktivierung respektive Deaktivierung eines VPNs oder DNS-over-HTTPS, sodass Firefox bei einem Wechsel nicht mehr erst einmal eine Zeit lang benötigt, um wieder erfolgreich Verbindungen zu Websites aufbauen zu können.

Die Jump List in der Taskleiste von Windows wird nun effizienter befüllt, was die Performance verbessern sollte.

Für Nutzer in den USA gibt es, sofern gesponserte Vorschläge in der Adressleiste aktiviert sind, jetzt auch Suchvorschläge von Yelp.

Mehr Sicherheit für Firefox-Nutzer

Auch in Firefox 124 wurden wieder mehrere Sicherheitslücken geschlossen. Alleine aus Gründen der Sicherheit ist ein Update auf Firefox 124 daher für alle Nutzer dringend empfohlen.

Verbesserungen der Entwicklerwerkzeuge

Mit Firefox 122 hatte Mozilla die Tastatur-Steuerung des Regeln-Panels im Inspektor-Werkzeug überarbeitet. Diese Änderung wurde in Firefox 122.0.1 aufgrund von Nutzer-Feedback standardmäßig wieder rückgängig gemacht und eine Option in about:config implementiert, über welche man das gewünschte Verhalten steuern kann. Firefox 124 ergänzt eine sichtbare Option in den Einstellungen der Entwicklerwerkzeuge.

Das Netzwerkanalyse-Werkzeug zeigt jetzt auch Ressourcen an, welche über das file://-Protokoll geladen werden.

Performance-Verbesserungen gab es für das Regeln-Panel des Inspektors bei vielen zutreffenden CSS-Regeln sowie für die Darstellung von Objekten in der Konsole.

Verbesserungen der Webplattform

Auf CSS-Seite neu ist die Unterstützung von text-wrap: wrap und text-wrap: nowrap. Die Pseudo-Elemente ::first-letter und ::first-line können außerdem jetzt auch für das <text>-Element in SVG-Grafiken verwendet werden.

Firefox unterstützt jetzt AbortSignal.any. Außerdem können jetzt HTTP(S) sowie relative URLs für die Erstellung von WebSockets genutzt werden.

Für Entwickler von Firefox-Erweiterungen wurde ein neues WebExtension-Event hinzugefügt, worüber Erweiterungen Informationen erhalten können, wenn eine Performance-Warnung ausgegeben wird.

Weitere Neuerungen für Entwickler von Websites lassen sich in den MDN Web Docs nachlesen.

Der Beitrag Mozilla veröffentlicht Firefox 124 erschien zuerst auf soeren-hentzschel.at.

19. März 2024

Die MZLA Technologies Corporation hat mit Thunderbird 115.9 ein planmäßiges Update für seinen Open Source E-Mail-Client veröffentlicht.

Neuerungen von Thunderbird 115.9

Mit dem Update auf Thunderbird 115.9 hat die MZLA Technologies Corporation ein planmäßiges Update für seinen Open Source E-Mail-Client veröffentlicht. Das Update bringt diverse Fehlerbehebungen und Verbesserungen unter der Haube, welche sich in den Release Notes (engl.) nachlesen lassen. Auch wurden diverse Sicherheitslücken geschlossen.

Der Beitrag Thunderbird 115.9 veröffentlicht erschien zuerst auf soeren-hentzschel.at.

Im letzten Blogpost habe ich beschrieben, wie ich mein privates Netz mit openVPN aufbaue. In diesem Post möchte ich zeigen, wie man Android-Geräte dem Netz hinzufügen kann, und was ich tun musste, damit der Server korrekt auf IPv4 und IPv6-Anfragen lauscht.

IPv6

Mein Heimserver, der die VPNs aufbaut, ist sowohl per IPv4 als auch per IPv6 erreichbar. Da das Mobilnetz an Handy und Tablet fast ausschließlich IPv6 nutzt, ist es eine gute Idee, auf beiden Netzen zu lauschen. Damit der openVPN-Server sowohl per IPv4 als auch per IPv6 auf Anfragen antwortet, ändere ich in der Server-Config die Stelle

proto udp

auf

proto udp6

UDP6 antwortet mit anderer Adresse

Bei mir gab es das Problem, dass udp6 nicht mit der IP-Adresse auf Anfragen antwortet, an welche die Anfrage abgeschickt wurde. Mein Server hat beispielsweise die feste IPv6 2002:bla:fasel::4/64. Mein Handy sendet nun aus dem Mobilnetz (da gibt es nur IPv6) an diese Adresse seine Anfrage, aber der Server antwortet mit einer neuen IPv6, z.B. 2002:bla:fasel:ätschi:bätsch:4/64. In diesem Falle kommt keine Verbindung zu Stande (das scheint schon länger und immer wieder ein Problem mit UDP zu sein).

Die Lösung besteht darin, in der Server-Config die Zeile multihome zu ergänzen.

proto udp6
multihome

Die Option stellt sicher, dass die UDP-Antwortpakete immer von der Adresse gesendet werden, an welche der Client seine Anfragen gestellt hat.

IPv6-ULA einrichten.

Bislang bekommen alle Clients eine IP4 aus dem 10.5.5.0/24 Bereich, wobei ich über das ccd-Verzeichnis jedem Client eine feste IP gegeben habe. Da ich den Server nun auch aus dem IPv6-Netz heraus erreichbar gemacht habe, verteile ich über mein VPN zusätzlich IPv6-ULA-Adressen aus dem Bereich fd04:bab0::/64, so dass alle Clients auch per IPv6 ansprechbar sind.

Hierfür ergänze ich die Server-Config um folgende Zeilen:

server-ipv6 fd04:bab0::/64        # ULA IPv6 Subnetz für OpenVPN-Clients
push "route-ipv6 fd04:bab0::/64"  # ULA IPv6 Subnetz an die Clients weitergeben

Ebenfalls ergänze ich im ccd-Verzeichnis die Dateien aller Clients um folgende Zeile:

ifconfig-ipv6-push fd04:bab0::xyz/64

wobei ich für xyz jeweils die selbe Ziffer nehme wie im IPv4 Netz.

Nach einem Neustart des VPN-Servers erhalten alle Clients automatisch eine 10.5.5.0/24 sowie eine fd04:bab0::/64-Adresse und können sich gegenseitig über IPv4 oder IPv6 anpingen. An den Client-Configs muss nichts geändert werden.

IPv6 Internet durch den Tunnel routen

Damit auch das globale IPv6-Internet durch den Tunnel geroutet werden kann, müssen die Firewallregeln angepasst werden.

iptables

# iptables
ip6tables -t nat -D POSTROUTING -s fd04:bab0::/64 -o eth0 -j MASQUERADE

ufw

Für IPv6 muss die Datei /etc/ufw/before6.rules angepasst werden. Füge die folgenden Zeilen vor der *filter-Sektion ein, um das NAT für IPv6 zu aktivieren:

nano /etc/ufw/before6.rules

# NAT-Tabelle hinzufügen
*nat
:POSTROUTING ACCEPT [0:0]
# OpenVPN-Regeln hinzufügen
-A POSTROUTING -s fd04:bab0::/64 -o eth0 -j MASQUERADE
COMMIT

Zertifikate erstellen

Damit Handy und Tablet das VPN nutzen können, benötigen sie wieder gültige Zertifikate und den ta.key des VPNs (siehe letzter Blogpost).

Dazu wechsle ich auf meine Zertifikationsinstanz und erstelle wie gewohnt Zertifiakte für Handy und Tablet, z.B. so:

sudo bash
cd /etc/easy-rsa
easyrsa gen-req handy nopass
easyrsa sign-req client handy

easyrsa gen-req tablet nopass
easyrsa sign-req client tablet

Zertifikat für Android umwandeln

Wir können Androids Zertifikateverwaltung nutzen, um die Zertifikate halbwegs “sicher” auf den Geräten zu verwalten. Hierfür bündeln wir

  • /etc/easy-rsa/pki/private/handy.key
  • /etc/easy-rsa/pki/issued/handy.crt
  • /etc/easy-rsa/pki/ca.crt

in einer PKCS-Datei mit dem Namen handy.p12, die wir dann später am Handy importieren können. Der dazugeöhrige Befehl lautet:

openssl pkcs12 -export -in CERT -inkey KEY -certfile CA -name CLIENTNAME -out OUTPUT.p12

In meinem Fall also

openssl pkcs12 -export -in pki/issued/handy.crt -inkey pki/private/handy.key -certfile pki/ca.crt -name handy -out handy.p12

Ihr werdet nach einem Export-Passwort gefragt. Denkt euch irgendetwas halbwegs sicheres aus. Am Handy muss später dieses Passwort beim Import eingegeben werden.

Die erzeugte PKCS-Datei handy.p12 sowie der ta.key des VPN müssen nun auf das Handy kopiert werden. Ich nutze hierfür meine Nextcloud, KDE Connect oder eine E-Mail an mich selbst.

  • Ist die Datei handy.p12 auf das Handy kopiert, klicke ich am Handy auf eben diese Datei, um die Zertifikate in den Android-Zertifikatespeicher aufzunehmen. Hierbei muss das oben erwähnte Passwort eingegeben werden.
  • Die Datei ta.key kopiere ich an eine Stelle meines Handys, die ich mir merken kann, z.B. “Dokumente/OpenVPN”

openVPN for Android

Für Android steht z.B. über F-Droid das Paket von blinkt zur Verfügung, siehe https://f-droid.org/packages/de.blinkt.openvpn/

  • In der Client-App erstelle ich ein neues Profil mit dem Namen “test” (Name ist ja egal).
  • Im Reiter “Basic” klicke ich bei “Client Certificate” auf den Select-Button. So kann ich das eben in Android importierte Zertifikat auswählen.

importierte Zertifikate im Androidspeicher
  • Im Reiter “Server List” trage ich meinen Server ein und wähle unter “Protocol” UDP.

Serveradresse und Protocol “UDP”
  • Unter dem Reiter “Authentication/Encryption” müssen folgende Einstellungen getroffen werden:
    • bei TLS-Settings entferne ich den Haken bei “Certificate Hostname Check”

kein “Certificate Hostname Check”
  • dafür setze ich den Haken bei “Use Control Channel Authentication/Encryption”
    • als “TLS Auth/TLS Encrpytion File” wähle ich den auf das Handy kopierten ta.key
    • als “Authentication/encryption method” wähle ich Encryption (--tls-crypt)

TLS Auth/TLS Encrpytion File ist ta.key und Encryption --tls-crypt
  • bei “Encryption ciphers” trage ich (gemäß meiner Server-Config) AES-256-CBC:AES-256-GCM ein.

Encryption ciphers auf AES-256-CBC:AES-256-GCM

Das funktioniert wunderbar, und mein Handy kann sich mit meinem VPN verbinden.

erfolgreich verbunden

Jetzt können sich alle Clients (auch die Mobilgeräte über IPv6) mit dem Server verbinden und sich gegenseitig anpingen.

gesamten Verkehr der Mobilgeräte über das VPN routen

Im Reiter “Routing” können bei Bedarf die Haken bei “Use default Route” für IPv4 und IPv6 gesetzt werden. Dann wird der gesamte Datenverkehr des Handys über das VPN geroutet. Die Server-Config muss dafür nicht angefasst werden.

alles übers VPN routen

Das ist sehr vorteilhaft, z.B. wenn man in einem ranzigen WLAN unterwegs ist (McDoof, Bahn, etc.) oder im Ausland dennoch “Sportschau” übers Netz schauen möchte. Auch funktioniert KDE Connect bestens über das VPN, was für meinen Büro-PC sehr gut ist.

Möchtet ihr auch bei anderen Clients (z.B. beim Laptop) den gesamten Datenverkehr durch das VPN routen, müsst ihr in dessen Client-Config folgende Zeile ergänzen:

redirect-gateway def1 # leitet gesamten Datenverkehr über das VPN

Das def1 steht für “default route” und muss nicht weiter angepasst werden. Nun läuft auch am Laptop alles über das VPN.

Weblinks


Diskussion per Matrix unter https://matrix.to/#/#produnis-blog:tchncs.de

 

Nutzer von Firefox auf openSUSE sehen derzeit sämtliche Erweiterungen deaktiviert. Schuld ist eine Änderung seitens der Linux-Distribution.

Firefox-Nutzer, welche die Linux-Distribution openSUSE nutzen, können derzeit nicht ihre Firefox-Erweiterungen verwenden. Die Ursache hierfür ist eine Änderung des crypto-policies-Paketes, welche openSUSE ausgerollt hat und nicht kompatibel mit Firefox ist. Betroffene Nutzer sollten auf ein Update warten, welche diese Änderung wieder rückgängig macht. Vom Entfernen und erneuten Installieren der Firefox-Erweiterungen wird abgeraten, da hierdurch die Konfigurationen der jeweiligen Erweiterungen verloren gehen.

Update 14.50 Uhr: Mittlerweile hat openSUSE auf das Problem reagiert und das betroffene Paket erneut aktualisiert. Damit tritt das Problem nicht länger auf.

Der Beitrag openSUSE-Update sorgt für deaktivierte Erweiterungen in Firefox erschien zuerst auf soeren-hentzschel.at.

18. März 2024

Wenn ich über Rolling-Release-Distributionen und den Wartungsaufwand von Linux schreibe, kommen zuverlässig Kommentare, dass das alles kein Problem sei und man selbst seit x Jahren mit der Distribution y ohne Neuinstallation arbeitet. Kann sein. Muss es nicht. Vor allem aber fehlt es an Planbarkeit.

Ende Februar hat KDE das lange angekündigte Mega Release veröffentlicht. Dabei handelt es sich um die gleichzeitige Aktualisierung des Plasma-Desktops auf Version 6 und der nun auf Qt 6 basierenden Applikationssammlung. Im Gegensatz zu früheren Versionssprüngen ist KDE hier ein grundsolides Release gelungen. Es gibt sinnvolle Verbesserungen, keine großen Brüche, keine signifikanten Funktionseinbußen und vor allem keine riesigen Buglisten. Hier hat KDE definitiv dazugelernt.

Für ein paar Tage war dann Ruhe. Schließlich mussten die Entwickler erst testen, dann bauen und die QA musste auch noch drüber laufen. Aber letzte Woche wurde Plasma 6 und alles was dazu gehört in openSUSE Tumbleweed verteilt. Das geschah ohne Zeitplan und ohne große Ankündigung. Wem das gerade nicht in den Kram passte, weil er das System gerade dringend für einen Arbeitsprozess oder ähnliches benötigte, der konnte ab diesem Tag nur noch das Aktualisieren und Neuinstallieren von Paketen einstellen. Sicherheitsupdates kommen dann natürlich auch nicht mehr. Rolling Release heißt eben auch unweigerlich mitrollen.

Das Update selbst ruckelte sehr stark. Das berichten viele Nutzer. Die Probleme – das möchte ich ausdrücklich betonen – lagen nicht bei KDE, sondern bei der Update-Routine von openSUSE. Der eigentliche Vorgang über zypper brach bei Anwendern mit laufender Wayland-Session mittendrin ab. Wer dann nicht auf TTY wechselte und dort das Update beendete, hatte ein inkonsistentes System und landete bestenfalls nach einem Neustart wieder bei Plasma 5. Größere Probleme waren dann noch fehlende Übergänge bei SDDM, weshalb hier entweder die Konfigurationsmöglichkeit verloren ging oder gleich alle Pakete. Die automatische Entsperrung von KWallet über PAM funktionierte nicht mehr und die Desktopsuche Baloo hing in einem Mix aus 5 und 6 fest. Hinzu kamen kleinere und größere Probleme mit einzelnen Programmen. Je nach Einschätzung des Aufwandes konnte man sich dann entweder einzeln auf Fehlersuche begeben (wobei ein Unfallauto immer ein Unfallauto bleibt) oder neu installieren. Das Zurückspringen über Snapper und ein erneuter Versuch brachte letztlich meist ein ähnliches Ergebnis, ist also nicht die Lösung.

Jetzt wird natürlich wieder jemand schreiben, mit der Distribution xyz wäre das nicht passiert, man hätte nur dies und jenes beachten müssen usw. usf.

Aber meiner Ansicht nach zeigt diese fehlerhaften Aktualisierung wieder verschiedene Punkte:

  • RR-Verteilungen sind nur für den unkritischen privaten Gebrauch geeignet. Solche Großupdates sind nicht planbar, nicht vorhersehbar und nicht verschiebbar. Das macht RR-Distributionen für den produktiven Einsatz ungeeignet.
  • Die klassische Paketverwaltung mit ihren systemimmanenten Problemen ist am Ende ihres Entwicklungszyklus angelangt. Bessere Übergänge bei openSUSE hätten manches verhindert, aber das System aus tausenden Paketen mit fein definierten Abhängigkeiten und Überleitungen ist ein fehleranfälliges Konstrukt. Ein festes Image aus Basissystem und Desktop plus Anwendungsprogrammen hätte diese Probleme beim Update nicht verursacht.
  • Linux ist und bleibt wartungsintensiver als vergleichbare Systeme.

Der Artikel Kommentar: Die Tücken von Rolling-Release-Distributionen erschien zuerst auf Curius

16. März 2024

In diesem Blogpost zeige ich Schritt für Schritt, wie ich mein privates openVPN-Netzwerk aufgebaut habe. Zu dem Thema gibt es übrigens eine sehr empfehlenswerte Podcastfolge von Request for Comments, in welcher Clemens Schrimpe ausführlich über VPN spricht.

Mein VPN soll die IPs 10.5.5.0/24 verwenden und eigentlich “nur” dazu dienen, die Clients miteinander zu verbinden. Es kann aber auch easy der gesamte Internettraffic über dass VPN geleitet werden.

Hardware

Folgende Geräte kommen zum Einsatz:

  • Master-CA- ist die Zertifikationsinstanz, welche die Zertifikate ausstellt und signiert. Dies übernimmt mein Desktoprechner zuhause
  • openVPN-Server - das übernimmit mein Homeserver
  • Clients - mein Desktoprechner, mein Laptop sowie mein Büro-PC

Installieren

Zunächst installiere ich die benötigten Pakete:

sudo apt install openvpn easy-rasa

Ich nutze Arch, btw, daher nutze ich Pacman:

pacman -S openvpn easy-rsa 

Zertifikate anlegen

Bevor es wirklich los gehen kann, müssen die grundlegenden Zertifikate erstellt werden.

Master CA

Wir sind unsere eigene Zertifikationsinstanz, die alle weiteren Zertifikate für Server und Clients signiert. Diese Zertifikationsinstanz sollte auf einer anderen Maschine laufen als dem openVPN Server. Daher nutze ich meinen Desktop-PC zu hause dafür.

Wir erstellen zunächst das passende Verzeichnis unter /etc/easy-rsa

sudo bash
mkdir /etc/easy-rsa
cd /etc/easy-rsa

… und erzeugen hier das Master-CA ca.crt:

export EASYRSA=$(pwd)
easyrsa init-pki
easyrsa build-ca

Denke dir ein starkes Passwort für das Master-CA aus, und gib dir einen Common Name, ich habe da “Produnis” gewählt.

Die Datei ca.crt liegt nun im Unterordner pki/

Serverzertifikat

Jetzt legen wir die Zertifikate für unseren openVPN-Server an und signieren sie mit unserem Master-CA:

easyrsa gen-req SERVERNAME nopass
easyrsa sign-req server SERVERNAME

Wir müssen die Aktion mit yes bestätigen und das eben erzeugte Passwort des Master-CA eingeben.

Das erzeugte und signierte Zertifikat für den openVPN-Server liegt nun in pki/private/SERVERNAME.key bereit. Ebenfalls liegt dort die Datei pki/private/ca.key. Diese benötigen wir später noch, um weitere Zertifikate zu signieren.

Der openVPN-Server benötigt noch weitere Dateien für die Verschlüsslung des Netzwerks. Da diese Dateien auch von den Clients benötigt werden, erzeuge ich mir ein eigenes Verzeichnis hierfür, welches so heisst, wie das VPN-Netz, das ich erzeugen möchte. In meinem Fall soll das Netzwerk “produnis” heissen. Der Name ist egal, aber so verliert man nicht die Übersicht.

mkdir /etc/easy-rsa/produnis

# diffie hellman für Perfect Forward Secrecy (PFS)
openssl dhparam -out /etc/easy-rsa/produnis/dh.pem 2048

# HMAC key um Man-in-the-Middle-Angriffe zu unterbinden
openvpn --genkey secret /etc/easy-rsa/produnis/ta.key

Jetzt kopieren wir alles auf den openVPN-Server. Folgende Dateien werden dort benötigt:

  • /etc/easy-rsa/pki/private/SERVERNAME.key
  • /etc/easy-rsa/pki/issued/SERVERNAME.crt
  • /etc/easy-rsa/pki/ca.crt
  • /etc/easy-rsa/produnis/dh.pem
  • /etc/easy-rsa/produnis/ta.key

Ich kopiere die Dateien zunächst ins /tmp-Verzeichnis des Servers.

scp /etc/easy-rsa/pki/private/SERVERNAME.key /etc/easy-rsa/pki/issued/SERVERNAME.crt /etc/easy-rsa/pki/ca.crt /etc/easy-rsa/produnis/dh.pem /etc/easy-rsa/produnis/ta.key user@server:/tmp 

Server einrichten

Verbinde dich auf den Server und erstelle ein Unterverzeichnis in /etc/openvpn/server/, das wie das VPN-Netz heisst. Ich hatte ja produnis als Netznamen gewählt.

ssh user@server
sudo bash
mkdir /etc/openvpn/server/NETZNAME

In diesen Ordner verschiebe ich die kopierten Dateien.

mv /tmp/SERVERNAME.key /tmp/SERVERNAME.crt /tmp/ca.crt /tmp/dh.pem /tmp/ta.key /etc/openvpn/server/NETZNAME/

Im “Hauptordner” /etc/openvpn/server/ erstelle ich die Datei produnis.conf mit folgendem Inhalt:

port 1194
proto udp
dev tun
server 10.5.5.0 255.255.255.0 

# ihr müsst "produnis" durch eure Namen ersetzen
ca /etc/openvpn/server/produnis/ca.crt
cert /etc/openvpn/server/produnis/produnis.crt
key /etc/openvpn/server/produnis/produnis.key  # This file should be kept secret
dh /etc/openvpn/server/produnis/dh.pem
tls-crypt /etc/openvpn/server/produnis/ta.key

client-to-client # damit sich die clients untereinander sehen können
ifconfig-pool-persist /etc/openvpn/server/produnis/ipp.txt
keepalive 10 120
cipher AES-256-CBC
max-clients 5
persist-key
persist-tun
status /etc/openvpn/server/produnis/openvpn-status.log
verb 3
explicit-exit-notify 1

Stelle sicher, dass openVPN auf alle Dateien zugreifen kann:

chown openvpn:network -R /etc/openvpn/server

Starte den Server mittels

openvpn /etc/openvpn/server/produnis.conf

Systemd

Alle Konfigurationsdateien liegen in /etc/openvpn/server/, z.B. /etc/openvpn/server/produnis.conf. Die passende systemd-Service-Unit heisst nun genauso wie die .conf-Datei (nur ohne .conf) openvpn-server@servername.service.

In meinem Fall also

systemctl start openvpn-server@produnis.service
systemctl status openvpn-server@produnis.service

Clients hinzufügen

Auf der Master-CA-Maschine erzeugen wir nun weitere Zertifikate für jeden Client.

sudo bash
cd /etc/easy-rsa
easyrsa gen-req CLIENTNAME nopass
easyrsa sign-req client CLIENTNAME

Wir müssen die Aktion mit yes bestätigen und das oben erzeugte Passwort des Master-CA eingeben.

Jetzt können wieder alle Dateien auf den Client übertragen werden. Benötigt werden

  • /etc/easy-rsa/pki/private/CLIENTNAME.key
  • /etc/easy-rsa/pki/issued/CLIENTNAME.crt
  • /etc/easy-rsa/pki/ca.crt
  • /etc/easy-rsa/produnis/ta.key

Ich kopiere diese Dateien zunächst ins /tmp-Verzeichnis auf dem Client:

scp /etc/easy-rsa/pki/issued/CLIENTNAME.crt /etc/easy-rsa/pki/private/CLIENTNAME.key /etc/easy-rsa/pki/ca.crt /etc/easy-rsa/produnis/ta.key user@client:/tmp

Konfiguration der Clients

Auf dem Client erstelle ich im Ordner /etc/openvpn/client/ einen Unterordner produnis. In diesen lege ich alle Zertifikate.

ssh user@client
sudo bash
mkdir /etc/openvpn/client/produnis
mv /tmp/ca.crt /tmp/ta.key /tmp/CLIENTNAME.key /tmp/CLIENTNAME.crt /etc/openvpn/client/produnis/

Im “Hauptordner” /etc/openvpn/client/ erstelle ich die Datei produnis.conf mit folgendem Inhalt:

client
dev tun
proto udp

remote mein.server.de 1194  # ersetze mit Adresse des openVPN-Server
ca /etc/openvpn/client/produnis/ca.crt
cert /etc/openvpn/client/produnis/CLIENTNAME.crt
key /etc/openvpn/client/produnis/CLIENTNAME.key
tls-crypt /etc/openvpn/client/produnis/ta.key
cipher AES-256-CBC
resolv-retry infinite
nobind
persist-key
persist-tun
tun-mtu 1350 # Unitymedia/Vodafone
verb 3

Stelle sicher, dass openVPN auf alle Dateien zugreifen kann:

chown openvpn:network -R /etc/openvpn/client

Starte den Client mittels

openvpn /etc/openvpn/client/produnis.conf

Mit Systemd starten

Alle Konfigurationsdateien liegen in /etc/openvpn/client/, z.B. /etc/openvpn/client/produnis.conf. Die passende systemd-Service-Unit heisst nun genauso wie die .conf-Datei (nur ohne .conf) openvpn-client@produnis.service.

In meinem Fall also wieder

sudo systemctl start openvpn-client@produnis.service
sudo systemctl status openvpn-client@produnis.service

statische IP-Adresse für die Clients festlegen

Dies ist eine Art DHCP-light, wir teilen jedem Client eine feste IP innerhalb des VPN-Netzes zu.

Erstelle auf dem Server ein Unterverzeichnis ccd (client config dir) und lege dort je eine Datei für jeden Client an.

mkdir /etc/openvpn/server/produnis/ccd
cd  /etc/openvpn/server/produnis/ccd
nano CLIENTNAME

CLIENTNAME ist dabei der Name, den du beim Erzeugen der Zertifikate verwendet hast. Anhand des Zertifikats erkennt der Server den Client.

In die Datei schreibst du:

ifconfig-push 10.5.5.x 10.5.5.1

wobei du x durch die gewünschte IP ersetzt. Die zweite IP ist die des VPN-Servers, also immer 10.5.5.1.

Damit der Server über unsere IP-Listen Bescheid weiss, muss /etc/openvpn/server/produnis.conf um folgende Zeile erweitert werden:

client-config-dir /etc/openvpn/server/produnis/ccd

Anschließend muss openVPN neu gestartet werden, z.B. mittels

systemctl restart openvpn-server@produnis.service

Firewall anpassen

Falls ihr eine Firewall benutzt (und ich hoffe doch sehr, dass dies der Fall ist), muss diese für openVPN angepasst werden. Einerseits müssen Ports freigegeben werden (standardmäßig 1194 udp), anderseits müssen wir intern NAT einrichten, wenn der Internetverkehr über den Tunnel geroutet werden soll.

iptables

Die iptables-Firewall muss auf dem Server und auf den Clients angepasst werden, damit openVPN funktioniert:

## openvpn general settings für Server und Client
iptables -A INPUT -i tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -j ACCEPT

## nur auf dem Server nächste Zeile ausführen
## Dies setzt das NAT auf, damit Internet durch den Tunnel geroutet wird
#iptables -t nat -A POSTROUTING -s 10.5.5.0/24 -o eth0 -j MASQUERADE 

## auf Server und Client muss Port 1194 fuer openVPN geöffnet werden
iptables -A INPUT -i eth0 -p udp --destination-port 1194 -j ACCEPT

Wenn euer Device nicht eth0 heisst, müsst ihr den Befehl entsprechend anpassen.

ufw

Die ufw-Firewall muss auf dem Server und auf den Clients angepasst werden, damit openVPN funktioniert:

# openVPN
sudo ufw allow 1194
sudo ufw allow out 1194/udp

Auf dem Server müssen noch drei weitere Einstellungen getroffen werden, damit das Netz funktioniert.

  1. /etc/default/ufw
nano /etc/default/ufw 

DEFAULT_FORWARD_POLICY="ACCEPT"
  1. /etc/ufw/before.rules, füge die folgenden Zeilen vor der *filter-Sektion ein, um das NAT zu aktivieren:
nano /etc/ufw/before.rules

# NAT-Tabelle hinzufügen
*nat
:POSTROUTING ACCEPT [0:0]
# OpenVPN-Regeln hinzufügen
-A POSTROUTING -s 10.5.5.0/24 -o eth0 -j MASQUERADE
COMMIT

Wenn euer Device nicht eth0 heisst, müsst ihr den Befehl entsprechend anpassen.

  1. /etc/ufw/sysctl.conf
nano /etc/ufw/sysctl.conf

net/ipv4/ip_forward=1
net/ipv6/conf/default/forwarding=1
net/ipv6/conf/all/forwarding=1

Fertig

Jetzt sollten sich alle Clients mit dem Server verbinden und sich untereinander “sehen” können. Da jeder Client von mir eine fest IP-Adresse zugewiesen bekommen hat, kann ich nun easy per ssh von Client zu Client oder auf den Server verbinden. Genau so, wie ich es wollte.

gesamten Traffic über das VPN routen

Damit ein Client seinen gesamten Traffic über den VPN tunnelt, muss in der Client-Config folgende Zeile ergänzt werden:

redirect-gateway def1 # leitet gesamten Datenverkehr über das VPN

Das def1 steht für “default route” und muss nicht weiter angepasst werden.

siehe auch

  • Im nächsten Blogpost zeige ich, wie ich Handy und Tablet unter Android dem VPN hinzugefügt und IPv6 aktiviert habe.
  • Weil es so schön war, hab ich alles nochmal mit Wireguard nachgebaut.

Weblinks


Diskussion per Matrix unter https://matrix.to/#/#produnis-blog:tchncs.de

 

15. März 2024

Mozilla hat bekannt gegeben, dass der Mozilla Location Service als Alternative zum Geolocation-Service von Google eingestellt wird.

Für die Positionsbestimmung auf Websites über die Geolocation-API verwenden Browser einen sogenannten Geolokalisierungs-Dienst. Auch Mozilla hat mit dem Mozilla Location Service (MLS) einen solchen Dienst im November 2013 gestartet. Dieser wurde seit März 2015 bis zuletzt im November 2023 standardmäßig anstelle des Google-Dienstes in Nightly- und frühen Beta-Versionen von Firefox als Dienst für die Geolocation-API verwendet. Finale Firefox-Versionen hatten zu jeder Zeit standardmäßig den Google-Dienst genutzt. Auch in finalen Firefox-Versionen wird der Mozilla Location Service für die Bestimmung der Suchregion verwendet, welche unter anderem dafür verantwortlich ist, welche Suchmaschinen standardmäßig zur Verfügung stehen.

Die Daten hat Mozilla dabei von der Community erhalten. So gab es ursprünglich mit dem Mozilla Stumbler eine eigene Android-App, welche GPS-Daten auf Grundlage von Bluetooth-Beacons, Mobilfunkmasten und WLAN-Zugangspunkten für den Mozilla Location Service sammelte. Auch in Firefox 35 für Android wurde im Jahr 2015 eine entsprechende Funktion integriert. Im Jahr 2019 war Skyhook Holdings, Inc. allerdings der Meinung, Mozilla verletzte deren Patente. Mozilla einigte sich, um einen Rechtsstreit zu vermeiden, was Änderungen an den MLS-Richtlinien zur Folge hatte und weitere Investitionen und einen Ausbau erschwerten. Insbesondere eine mögliche kommerzielle Verwendung des Mozilla Location Services wurde damit erheblich eingeschränkt. Mit Veröffentlichung von Android 10 im gleichen Jahr funktionierte außerdem die Stumbler-App nicht mehr, welche 2021 schließlich offiziell eingestellt worden war. Dementsprechend ist auch die Genauigkeit des Mozilla Location Services in den letzten Jahren gesunken. Nun hat Mozilla die Einstellung des Projekts bekannt gegeben.

Neue API-Keys werden bereits keine mehr ausgestellt. Ab dem 27. März werden keine Daten mehr über die API entgegengenommen und keine neuen Exports mehr als Download bereitgestellt. Am 10. April werden die Downloads gelöscht. Ab dem 12. Juni wird der Mozilla Location Service nur noch für Mozillas Anwendungsfälle zur Verfügung stehen. Am 31. Juli wird schließlich das GitHub-Repository archiviert werden.

Der Beitrag Mozilla Location Service wird eingestellt erschien zuerst auf soeren-hentzschel.at.

14. März 2024

Mozilla hat noch einmal sein Bekenntnis erneuert, anders als Google und damit stellvertretend auch für andere Entwickler von Chromium-basierten Browsern, parallel zur Unterstützung des Manifest v3 auch Erweiterungen mit dem Manifest v2 langfristig weiter in Firefox zu unterstützen.

Entwickler von Browser-Erweiterungen nutzen die sogenannte WebExtension-Architektur. Dabei gibt es die ältere Version des Standards, das sogenannte Manifest v2, und dessen Weiterentwicklung, das Manifest v3. Firefox unterstützt seit Veröffentlichung von Firefox 109 im Januar 2023 das Manifest v3 zu großen Teilen.

Während Google seinen Plan aktiv vorantreibt, die Unterstützung für das Manifest v2 ab Sommer 2024 für Privatanwender und ab Juni 2025 für Enterprise-Nutzer einzustellen, hat Mozilla noch einmal bestätigt, keine Pläne zu haben, die Unterstützung für das Manifest v2 in Firefox in absehbarer Zukunft einzustellen. Und selbst, wenn Mozilla die Entscheidung irgendwann überdenken sollte, verspricht Mozilla, dies mit einem Vorlauf von mindestens einem Jahr anzukündigen.

Firefox wird auch weiterhin DOM-basierte Hintergrundscripte in Form von Event Pages sowie blockierende WebRequests im Manifest v3 unterstützen – zwei Features, welche Google mit dem Manifest v3 gestrichen hat und damit Entwickler von Erweiterungen für Chromium-basierte Browser einschränkt.

Der Beitrag Mozilla bekräftigt langfristige Manifest v2-Unterstützung in Firefox erschien zuerst auf soeren-hentzschel.at.

11. März 2024

Firefox besitzt eine Übersetzungsfunktion für Websites, welche im Gegensatz zu Cloud-Übersetzern wie Google Translate lokal arbeitet, die eingegebenen Texte also nicht an einen fremden Server sendet. Nun hat Mozilla weitere unterstützte Sprachen aktiviert.

Firefox wird seit Version 118 standardmäßig mit einer lokalen Funktion zur maschinellen Übersetzung von Websites für den Browser ausgeliefert. Das bedeutet, dass die Übersetzung vollständig im Browser geschieht und keine zu übersetzenden Inhalte an einen Datenriesen wie Google oder Microsoft übermittelt werden müssen. Dabei unterstützt Firefox bisher die Übersetzung aus und in die folgenden Sprachen: Deutsch, Englisch, Französisch, Italienisch, Spanisch, Portugiesisch, Niederländisch, Polnisch sowie Bulgarisch.

Ab sofort werden weitere Sprachen unterstützt. So kann Firefox nun Websites auf Estnisch in andere Sprachen und umgekehrt übersetzen. Websites in den folgenden Sprachen können außerdem jetzt in eine der anderen unterstützten Sprachen übersetzt werden, aber noch nicht umgekehrt: Finnisch, Griechisch, Russisch, Slowenisch, Türkisch, Ukrainisch sowie Ungarisch.

Da die Sprachmodelle über die Remote-Einstellungen von Firefox bereitgestellt werden, ist die Unterstützung neuer Sprachen an kein Firefox-Update gebunden und funktioniert direkt in jedem Firefox mit aktivierter Übersetzungsfunktion.

Nightly-Versionen von Firefox unterstützen noch weitere Sprachen, deren Übersetzungsqualität aber von Mozilla als noch nicht gut genug beurteilt wurde, um diese jetzt schon in Beta- oder gar finalen Firefox-Versionen zu aktivieren. Da Übersetzungen in Firefox aktuell immer den Weg über Englisch gehen, steht Englisch in dieser Liste stellvertretend für alle unterstützten Sprachen, aus denen oder in die übersetzt werden soll.

Der Beitrag Übersetzungsfunktion von Firefox spricht jetzt weitere Sprachen erschien zuerst auf soeren-hentzschel.at.

7. März 2024

Es gibt unzählige Möglichkeiten, die Web-Werbung zu minimieren. Die c’t hat kürzlich ausführlich zum Thema berichtet, aber die entsprechenden Artikel befinden sich auf heise.de hinter einer Paywall. Und heise.de ist ja mittlerweile auch eine Seite, die gefühlt mindestens so viel Werbung in ihre Texte einbaut wie spiegel.de. Das ist schon eine Leistung … Entsprechend lahm ist der Seitenaufbau im Webbrowser.

Egal, alles, was Sie wissen müssen, um zuhause einigermaßen werbefrei zu surfen, erfahren Sie auch hier — kostenlos und werbefrei :-)

Auf dem Bild ist ein Raspberry Pi 3B+ mit angeschlossenem USB-WLAN-Adapter und Netzwerkkabel zu sehen. Der WLAN-Adapter ist über einen der USB-Ports verbunden, während das gelbe Ethernet-Kabel in den LAN-Port eingesteckt ist. Der Raspberry Pi wird zusätzlich über ein schwarzes Micro-USB-Kabel mit Strom versorgt.
Raspberry Pi 3B+ mit USB-WLAN-Adapter

Konzept

Die Idee ist simpel: Parallel zum lokalen Netzwerk zuhause richten Sie mit einem Raspberry Pi ein zweites WLAN ein. Das zweite Netz verwendet nicht nur einen anderen IP-Adressbereich, sondern hat auch einen eigenen Domain Name Server, der alle bekannten Ad-Ausliefer-Sites blockiert. Jeder Zugriff auf eine derartige Seite liefert sofort eine Null-Antwort. Sie glauben gar nicht, wie schnell die Startseite von heise.de, spiegel.de etc. dann lädt!

Alle Geräte im Haushalt haben jetzt die Wahl: sie können im vorhandenen WLAN des Internet-Routers bleiben, oder in das WLAN des Raspberry Pis wechseln. (Bei mir zuhause hat dieses WLAN den eindeutigen Namen/SSID wlan-without-ads.)

Das Bild zeigt ein Netzwerkdiagramm, in dem ein Raspberry Pi verwendet wird, um ein nahezu werbefreies WLAN-Netzwerk zu erstellen. Der Raspberry Pi ist über eine Ethernet-Buchse mit der IP-Adresse 192.168.178.123 an einen WLAN-Router (z.B. FritzBox) angeschlossen. Zusätzlich ist ein USB-WLAN-Adapter mit der IP-Adresse 10.3.141.1 verbunden, der das Netzwerk "wlan-without-ads" bereitstellt. Verschiedene Geräte wie ein Smartphone, Tablet und Notebook sind drahtlos mit diesem Netzwerk verbunden, erkennbar an den gestrichelten Linien und ihren jeweiligen IP-Adressen.
RaspAP auf dem Raspberry Pi spannt ein eigenes (beinahe) werbefreies WLAN auf

Zur Realisierung dieser Idee brauchen Sie einen Raspberry Pi — am besten nicht das neueste Modell: dessen Rechenleistung und Stromverbrauch sind zu höher als notwendig! Ich habe einen Raspberry Pi 3B+ aus dem Keller geholt. Auf dem Pi installieren Sie zuerst Raspbian OS Lite und dann RaspAP. Sie schließen den Pi mit einem Kabel an das lokale Netzwerk an. Der WLAN-Adapter des Raspberry Pis realisiert den Hotspot und spannt das werbefreie lokale Zweit-Netzwerk auf. Die Installation dauert ca. 15 Minuten.

Raspberry Pi OS Lite installieren

Zur Installation der Lite-Version von Raspberry Pi OS laden Sie sich das Programm Raspberry Pi Imager von https://www.raspberrypi.com/software/ herunter und führen es aus. Damit übertragen Sie Raspberry Pi OS Lite auf eine SD-Karte. (Eine SD-Karte mit 8 GiB reicht.) Am besten führen Sie gleich im Imager eine Vorweg-Konfiguration durch und stellen einen Login-Namen, das Passwort und einen Hostnamen ein. Sie können auch gleich den SSH-Server aktivieren — dann können Sie alle weiteren Arbeiten ohne Tastatur und Monitor durchführen. Führen Sie aber keine WLAN-Konfiguration durch!

Mit der SD-Karten nehmen Sie den Raspberry Pi in Betrieb. Der Pi muss per Netzwerkkabel mit dem lokalen Netzwerk verbunden sein. Melden Sie sich an (wahlweise mit Monitor + Tastatur oder per SSH) und führen Sie ein Update durch (sudo apt update und sudo apt full-upgrade).

RaspAP installieren

RaspAP steht für Raspberry Pi Access Point. Sein Setup-Programm installiert eine Weboberfläche, in der Sie unzählige Details und Funktionen Ihres WLAN-Routers einstellen können. Dazu zählen:

  • Verwendung als WLAN-Router oder -Repeater
  • freie Auswahl des WLAN-Adapters
  • frei konfigurierbarer DHCP-Server
  • Ad-Blocking-Funktion
  • VPN-Server (OpenVPN, WireGuard)
  • VPN-Client (ExpressVPN, Mullvad VPN, NordVPN)

An dieser Stelle geht es nur um die Ad-Blocking-Funktionen, die standardmäßig aktiv sind. Zur Installation laden Sie das Setup-Script herunter, kontrollieren kurz mit less, dass das Script wirklich so aussieht, als würde es wie versprochen RaspAP installieren, und führen es schließlich aus.

Die Rückfragen, welche Features installiert werden sollen, können Sie grundsätzlich alle mit [Return] beantworten. Das VPN-Client-Feature ist nur zweckmäßig, wenn Sie über Zugangsdaten zu einem kommerziellen VPN-Dienst verfügen und Ihr Raspberry Pi diesen VPN-Service im WLAN weitergeben soll. (Das ist ein großartiger Weg, z.B. ein TV-Gerät via VPN zu nutzen.)

Welche Funktionen Sie wirklich verwenden, können Sie immer noch später entscheiden. Das folgende Listing ist stark gekürzt. Die Ausführung des Setup-Scripts dauert mehrere Minuten, weil eine Menge Pakete installiert werden.

wget https://install.raspap.com -O raspap-setup.sh
less raspap-setup.sh
bash raspap-setup.sh

The Quick Installer will guide you through a few easy steps
Using GitHub repository: RaspAP/raspap-webgui 3.0.7 branch
Configuration directory: /etc/raspap
lighttpd root: /var/www/html? [Y/n]:
Installing lighttpd directory: /var/www/html
Complete installation with these values? [Y/n]:
Enable HttpOnly for session cookies? [Y/n]:
Enable RaspAP control service (Recommended)? [Y/n]:
Install ad blocking and enable list management? [Y/n]:
Install OpenVPN and enable client configuration? [Y/n]:
Install WireGuard and enable VPN tunnel configuration? [Y/n]:
Enable VPN provider client configuration? [Y/n]: n
The system needs to be rebooted as a final step. Reboot now? [Y/n]

Wenn alles gut geht, gibt es nach dem Neustart des Raspberry Pi ein neues WLAN mit dem Namen raspi-webgui. Das Passwort lautet ChangeMe.

Sobald Sie Ihr Notebook (oder ein anderes Gerät) mit diesem WLAN verbunden haben, öffnen Sie in einem Webbrowser die Seite http://10.3.141.1 (mit http, nicht https!) und melden sich mit den folgenden Daten an:

Username: admin
Passwort: secret

In der Weboberfläche sollten Sie als Erstes zwei Dinge ändern: das Admin-Passwort und das WLAN-Passwort:

  • Zur Veränderung des Admin-Passworts klicken Sie auf das User-Icon rechts oben in der Weboberfläche, geben einmal das voreingestellte Passwort secret und dann zweimal Ihr eigenes Passwort an.
  • Die Eckdaten des WLANs finden Sie im Dialogblatt Hotspot. Das Passwort können Sie im Dialogblatt Security verändern.

Das Bild zeigt die Benutzeroberfläche von RaspAP, einem Konfigurationstool für einen Raspberry Pi Hotspot. Im Fokus stehen die "Basic settings" für den Hotspot, darunter die Auswahl des Interfaces (wlan0), die SSID und der Wireless Mode (802.11g - 2.4 GHz). Außerdem ist der Kanal auf 1 eingestellt und es gibt Buttons zum Speichern der Einstellungen, zum Stoppen und zum Neustarten des Hotspots.
Die Weboberfläche von RaspAP mit den Hotspot-Einstellungen
Das Bild zeigt die Benutzeroberfläche einer Ad-Blocking-Konfiguration in einem Webbrowser. Im Abschnitt "Blocklist settings" ist die Option "Enable blocklists" aktiviert, um DNS-Anfragen für Werbung und Tracking zu blockieren. Es wird angezeigt, dass die Hostnamen- und Domänen-Blocklisten zuletzt vor drei Wochen aktualisiert wurden. Unten gibt es Buttons zum Speichern der Einstellungen und zum Neustarten des Ad-Blockings.
Bei den Ad-Block-Einstellungen sind keine Änderungen erforderlich. Es schadet aber nicht, hin und wieder die Ad-Blocking-Liste zu erneuern.

RaspAP verwendet automatisch den WLAN-Namen (den Service Set Identifier) raspi-webgui. Auf der Einstellungsseite Hotspot können Sie einen anderen Namen einstellen. Ich habe wie gesagt wlan-without-ads verwendet. Danach müssen sich alle Clients neu anmelden. Fertig!

USB-WLAN-Adapter

Leider hat der lokale WLAN-Adapter des Raspberry Pis keine großartige Reichweite. Für’s Wohnzimmer oder eine kleine Wohnung reicht es, für größere Wohnungen oder gar ein Einfamilienhaus aber nicht. Abhilfe schafft ein USB-WLAN-Antenne. Das Problem: Es ist nicht einfach, ein Modell zu finden, das vom Linux-Kernel auf Anhieb unterstützt wird. Ich habe zuhause drei USB-WLAN-Adapter. Zwei haben sich als zu alt erwiesen (kein WPA, inkompatibel mit manchen Client-Geräten etc.); der dritte Adapter (BrosTrend AC650) wird auf Amazon als Raspberry-Pi-kompatibel beworben, womit ich auch schon in die Falle getappt bin. Ja, es gibt einen Treiber, der ist aber nicht im Linux-Kernel inkludiert, sondern muss manuell installiert werden:

https://github.com/ElectricRCAircraftGuy/BrosTrendWifiAdapterSoftware

Immerhin gelang die Installation unter Raspberry Pi OS Lite auf Anhieb mit dem folgenden, auf GitHub dokumentierten Kommando:

sh -c 'busybox wget deb.trendtechcn.com/install \
       -O /tmp/install && sh /tmp/install'

Mit dem nächsten Neustart erkennt Linux den WLAN-Adapter und kann ihn nutzen. Das ändert aber nichts daran, dass mich die Installation von Treibern von dubiosen Seiten unglücklich macht, dass die Treiberinstallation nach jedem Kernel-Update wiederholt werden muss und dass die manuelle Treiberinstallationen bei manchen Linux-Distributionen gar nicht möglich ist (LibreELEC, Home Assistant etc.).

Wenn Sie gute Erfahrungen mit einem USB-WLAN-Adapter gemacht haben, hinterlassen Sie bitte einen kurzen Kommentar!

Sobald RaspAP den WLAN-Adapter kennt, bedarf es nur weniger Mausklicks in der RaspAP-Weboberfläche, um diesen Adapter für den Hotspot zu verwenden.

Alternativ können Sie den internen WLAN-Adapter auch ganz deaktivieren. Dazu bauen Sie in config.txt die folgende Zeile ein und starten den Raspberry Pi dann neu.

# Datei /boot/firmware/config.txt
...
dtoverlay=disable-wifi

Danach kennt Raspberry Pi OS nur noch den USB-WLAN-Adapter, eine Verwechslung ist ausgeschlossen.

Vorteile

Der größte Vorteil von RaspAP als Ad-Blocker ist aus meiner Sicht seine Einfachheit: Der Werbeblocker kann mit minimalem Konfigurationsaufwand von jedem Gerät im Haushalt genutzt werden (Opt-In-Modell). Sollte RaspAP für eine Website zu restriktiv sein, dauert es nur wenige Sekunden, um zurück in das normale WLAN zu wechseln. Bei mir zuhause waren alle Familienmitglieder schnell überzeugt.

Nachteile

  • Der Raspberry Pi muss per Ethernet-Kabel mit dem lokalen Netzwerk verbunden werden.
  • Manche Seiten sind so schlau, dass sie das Fehlen der Werbung bemerken und dann nicht funktionieren. Es ist prinzipbedingt unmöglich, für solche Seiten eine Ausnahmeregel zu definieren. Sie müssen in das normale WLAN wechseln, damit die Seite funktioniert.

  • youtube-Werbung kann nicht geblockt werden, weil Google so schlau ist, die Werbefilme vom eigenen Server und nicht von einem anderen Server zuzuspielen. youtube.com selbst zu blocken würde natürlich helfen und außerdem eine Menge Zeit sparen, schießt aber vielleicht doch über das Ziel hinaus.

  • Mit RaspAP sind Sie in einem eigenen privaten Netz, NICHT im lokalen Netz Ihres Internet-Routers. Sie können daher mit Geräten, die sich im wlan-without-ads befinden, nicht auf andere Geräte zugreifen, die mit Ihrem lokalen Router (FritzBox etc.) verbunden sind. Das betrifft NAS-Geräte, Raspberry Pis mit Home Assistant oder anderen Anwendungen etc.

Keine Werbeeinnahmen mehr für Seitenbetreiber?

Mir ist klar, dass sich viele Seiten zumindest teilweise über Werbung finanzieren. Das wäre aus meiner Sicht voll OK. Aber das Ausmaß ist unerträglich geworden: Mittlerweile blinkt beinahe zwischen jedem Absatz irgendein sinnloses Inserat. Werbefilme vervielfachen das Download-Volumen der Seiten, der Lüfter heult, ich kann mich nicht mehr auf den Text konzentrieren, den ich lese. Es geht einfach nicht mehr.

Viele Seiten bieten mir Pur-Abos an (also Werbeverzicht gegen Bezahlung). Diesbezüglich war https://derstandard.at ein Pionier, und tatsächlich habe ich genau dort schon vor vielen Jahren mein einziges Pur-Abo abgeschlossen. In diesem Fall ist es auch ein Ausdruck meiner Dankbarkeit für gute Berichterstattung. Früher habe ich für die gedruckte Zeitung bezahlt, jetzt eben für die Online-Nutzung.

Mein Budget reicht aber nicht aus, dass ich solche Abos für alle Seiten abschließen kann, die ich gelegentlich besuche: heise.de, golem.de, phoronix, zeit.de, theguardian.com usw. Ganz abgesehen davon, dass das nicht nur teuer wäre, sondern auch administrativ mühsam. Ich verwende diverse Geräte, alle paar Wochen muss ich mich neu anmelden, damit die Seiten wissen, dass ich zahlender Kunde bin. Das ist bei derstandard.at schon mühsam genug. Wenn ich zehn derartige Abos hätte, würde ich alleine an dieser Stelle schon verzweifeln.

Wenn sich Zeitungs- und Online-News-Herausgeber aber zu einem Site-übergreifenden Abrechnungsmodell zusammenschließen könnten (Aufteilung der monatlichen Abo-Gebühr nach Seitenzugriffen), würde ich mir das vielleicht überlegen. Das ist aber sowieso nur ein Wunschtraum.

Aber so, wie es aktuell aussieht, funktioniert nur alles oder nichts. Mit RaspAP kann ich die Werbung nicht für manche Seiten freischalten. Eine Reduktion des Werbeaufkommens auf ein vernünftiges Maß funktioniert auch nicht. Gut, dann schalte ich die Werbung — soweit technisch möglich — eben ganz ab.

6. März 2024

Wie Golem schreibt, erwägen wohl mittlerweile viele BenutzerInnen den Schritt auf Linux, statt von Window 10 auf Windows 11 und eventuell später auf irgendwelche monatliche Abo Varianten zu wechseln.

Da ich seit über 25 Jahren Linux auf dem Desktop nutze und immer noch absolut begeistert bin, würde ich jeden Menschen immer wieder ermutigen das auch auszuprobieren.

Um einige Zeit verschwendende Diskussionen zu vermeiden ein paar Punkte vorweg:

  1. Wer wenig visuelle Veränderungen haben will entscheidet sich für eine Linux Distribution mit KDE/Plasma z.B. die Distribution Kubuntu oder aus Deutschland das Tuxedo OS oder Mint oder eine andere Linux Distributionen
  2. Um nicht komplett ins kalte Wasser springen zu müssen, können so ziemlich alle Linux Distributionen auf einen USB Stick „installiert“ (Live-USB Stick) werden und von dort einfach mal gestartet und ausprobiert werden. Ein USB Stick ist zwar langsam, aber es geht erst mal dabei nicht um Geschwindigkeit, sondern darum, ob es läuft und einen ersten Eindruck zu bekommen. Und zum Thema Geschwindigkeit: Ein installiertes Linux ist in 99% der Fälle wesentlich schneller als ein installiertes Windows.
  3. Viele nutzen bereits schon Opensource Software, die hauptsächlich für Linux entwickelt wird. Da ist der Umstieg super einfach. Weil es gar kein Umstieg ist. Das prominenteste Beispiel dafür ist der Mozilla Firefox Browser.
  4. Viele sind über die Jahre so darauf getrimmt worden, dass sie z.B. auf Microsoft Office nicht verzichten können. Das ist aber reine Gehirnwäsche. Libreoffice bietet für 99% der Menschen mehr Funktionen, als sie tatsächlich nutzen.
  5. Eine Sache, die mir immer wieder auffällt, wenn Menschen den Wechsel von Windows zu Linux erwägen ist, dass sie aufgrund der erweiterten Möglichkeiten plötzlich vorgefertigte Funktionsanforderungen stellen, die sie zuvor noch nie hatten bzw die unter Windows nur sehr sehr umständlich möglich sind. Hier bitte die Kirche im Dorf lassen, oder sich selbst um diese hoch individualisierten Lösungen kümmern bzw die Suchmaschine dazu konsultieren. Vermutlich gibt es diese Lösung schon.
  6. Natürlich ändern sich bei einem Betriebssystemwechsel auch häufig die Namen bestimmter Softwarekomponenten. Aber auch die Eingewöhnungsphase ist recht kurz. Ich spreche da aus Erfahrung mit Menschen, die teils einfach so spontan Linux haben wollten und bis heute sehr glücklich damit sind.
  7. Ich habe im Laufe der Zeit ein paar einfach verständliche Erklär-Videos zum Thema Linux und Linux und Musikproduktion auf meinem Musikproduktions Kanal „Odo Sendaidokai“ produziert, die ich hier für alle interessierten Menschen verlinke. Und wer sich für Musikproduktion generell interessiert, ist natürlich gerne eingeladen den Kanal zu abonnieren. Seit längerer Zeit produziere ich die Videos auf Deutsch und Englisch. Inklusive regelmäßiger Livestreams auf Deutsch, in denen ich meist Tracks von Anfang an produziere bzw auch Vieles erkläre. Zum Thema Musikproduktion betreibe ich zusätzlich noch das Blog „Klangwerk“.
  8. Für die Musikproduktion unter Linux ist für dich Pipewire natürlich sehr interessant und dafür habe ich hier im Blog auch noch einige erklärende Artikel.

Hier die Liste der Linux Erklär-Videos:

  1. Linux Supersonic from Zero to Hero Musikproduktion | DE (16.01.2024)
  2. Bitwig Linux Musicproduction 11/2023 | deutsch (19.11.2023)
  3. Musikproduktion mit Linux (auch Bitwig) (12.07.2021)
  4. Windows VST mit Bitwig unter Linux (02.10.2021)
  5. Bitwig JackAudio OBS Linux (Deutsch) – UPDATE 2022 Pipewire ist jetzt der Standard (15.11.2020)

The post Linux statt Windows auf dem Desktop – Nicht nur Musikproduktion first appeared on Dem hoergen Blog.

Die MZLA Technologies Corporation hat mit Thunderbird 115.8.1 ein Sicherheits- und Fehlerbehebungs-Update für seinen Open Source E-Mail-Client veröffentlicht.

Neuerungen von Thunderbird 115.8.1

Mit dem Update auf Thunderbird 115.8.1 hat die MZLA Technologies Corporation ein Update für seinen Open Source E-Mail-Client veröffentlicht und behebt damit mehrere Probleme, welche sich in den Release Notes (engl.) nachlesen lassen. Auch eine Sicherheitslücke wurde mit Thunderbird 115.8.1 behoben.

Der Beitrag Sicherheits-Update Thunderbird 115.8.1 veröffentlicht erschien zuerst auf soeren-hentzschel.at.

5. März 2024


Manchmal ist die Denke einfach zu kompliziert. Da wollte ich in vim einen Bereich möglichst effizient mit runden Klammern versehen und habe eine Weile rum gemurgst, bis ich dann die einfache Lösung gefunden habe:

  1. Bereich auswählen mit v und z.B. $ bis zum Zeilenende
  2. dann c drücken
  3. () schreiben
  4. ESC drücken und
  5. ein großes (shift) P drücken

also v$c()<ESC>P

Und alles ist schön umklammert.

Wenn es egal ist den Bereich visuell zu markieren, dann geht es auch ohne das v und das $ (bis Zeilenende) muss nach dem c eingegeben werden. (Danke Rebeka!)

c$()<ESC>P oder gleich C()<ESC>P

Weitere Varianten wären:

  1. Bis zum nächsten Vorkommen z.B. des Buchstabens „m“ cfm()<ESC>P
  2. Vom vorherigem Vorkommen eines „t“ bis zum nächsten Vorkommen eines „m“ Ftcfm()<ESC>P
  3. Wenn mitten im Wort gestartet wird, das natürlich auch umklammert werden soll, als erstes ein b tippen z.B. bC()<ESC>P
  4. Die nächsten 3 Worte c3w()<ESC>P oder eben bc3w()<ESC>P

The post Vim – Bereiche mit Klammern umschließen first appeared on Dem hoergen Blog.

Mozilla hat Firefox 123.0.1 veröffentlicht und behebt damit mehrere Probleme der Vorgängerversion.

Download Mozilla Firefox 123.0.1

Mit dem Update auf Firefox 123.0.1 behebt Mozilla ein Problem, welches bei Verwendung mancher Themes verursachte, dass bei einer Website, die von Firefox übersetzt wurde, in der Adressleiste die Sprache nicht erkennbar war, in welche übersetzt worden ist.

Ein anderes behobenes Darstellungsproblem betrifft das Entwicklerwerkzeug „Web-Speicher“, bei welchem der Text in markierten Zeilen nur schwer zu lesen war.

Firefox 123.0.1 behebt auch mehrere Webkompatibilitätsprobleme. So wurde das change-Event nicht mehr ausgelöst, wenn ein textarea-Element geleert worden ist. Konische Farbverläufe wurden unter Windows mit aktivierter Hardwarebeschleunigung nicht mehr korrekt dargestellt. Außerdem wurde ein Fehler im JIT-Compiler der JavaScript-Engine behoben, bei dem String.prototype.lastIndexOf einen falschen Rückgabewert lieferte, wenn der Suchtext leer war.

Ein weiteres behobenes Problem betrifft Flatpak-Nutzer unter Linux, für welche andere Wörterbücher als en-US nicht mehr funktionierten.

Schließlich wurde noch ein Problem der chinesischen Firefox-Variante behoben, welches verursachte, dass auf der Seite, die beim Öffnen eines neuen Tabs erscheint, nur noch eine Fehlermeldung zu sehen war.

Der Beitrag Mozilla veröffentlicht Firefox 123.0.1 erschien zuerst auf soeren-hentzschel.at.

3. März 2024

Da ich mehrere Rechner nutze, habe ich die Angewohnheit bestimmte Dinge beispielsweise mit dem Notebook anzufangen, dann eine Pause zu machen (weil ich zum Beispiel schlafen will) und dann mit einem meiner normalen Rechner weiterzumachen. An sich kein Problem, allerdings fehlt mir in solch einem Fall oft der Verlauf der Befehle, die ich in der Shell ausgeführt habe.

Daher habe ich mir nun Atuin zugelegt. Hierbei handelt es sich nicht um die Schildkröte, sondern um ein Tool, welches die Historie einer Shell lokal in einer SQLite-Datenbank speichert, deren Inhalt man mit anderen Rechnern synchronisieren kann.

Die Einträge in dieser Datenbank werden um diverse Informationen erweitert. Zum Beispiel dem Exit Code, Current Working Directory und so weiter. Die Suche innerhalb der Einträge erfolgt in der Standardkonfiguration “fuzzy”.

Für die Synchronisation zwischen mehreren Rechnern wird ein Server, den die Entwicklerin von Atuin zur Verfügung stellt, genutzt. Die Übertragung der Daten erfolgt hierbei mittels E2EE. Wer ihr nicht vertraut, kann entweder einen solchen Server selbst hosten (https://docs.atuin.sh/self-hosting/server-setup/) oder Atuin nur lokal nutzen. Letzteres hat im Grunde dann nur den Vorteil der besseren Suche.

Es gibt auch noch andere Tools zur Synchronisation von bereits ausgeführten Befehlen in der Shell. Zum Beispiel https://github.com/cantino/mcfly. Aber als jemand der jeden Roman von Terry Pratchett besitzt und gelesen hat, musste ich mich einfach für Atuin entscheiden.

1. März 2024

Vor ein paar Tagen wurde KDE Plasma 6 veröffentlicht. Nur wenige Tage später fragen sich schon die ersten Nutzer warum beispielsweise Arch Linux diese neue Version noch nicht anbietet.

Bei einer rollenden Distribution geht es primär nicht darum, dass bestimmte Updates so schnell wie möglich in den Paketquellen angeboten werden. Es geht darum, dass Updates nach und nach über die gleichen Paketquellen angeboten werden. Es geht also nicht darum wer den ersten Platz bei einem Wettrennen hat. Mit OpenSuse Slowroll soll es daher auch eine Distribution geben, die rollt, aber bei der Updates vergleichsweise langsam angeboten werden.

Im Falle von Arch Linux wird somit in der Regel auch nie erste Hauptversion eines neuen Kernels (z. B. 6.0) über die offiziellen Paketquellen angeboten, sondern in der Regel immer erst das erste “Minor-Update” (z. B. 6.0.1). Ich vermute, das wird bei KDE Plasma 6 auch der Fall sein. Vor nächster Woche wird Plasma 6 also vermutlich nicht in den offiziellen Paketquellen von Arch Linux erscheinen. Wenn aus Sicht der Entwickler von Arch Linux weitere Gründe gegen ein Update auf Plasma 6 sprechen, wird es vermutlich sogar noch länger dauern.

Heute will ich mal nicht mit einem eigenen Artikel langweilen, sondern nur auf einen anderen Artikel hinweisen. Dieser hat zwar direkt nichts mit Linux oder OSS zu tun und ist auch noch in englischer Sprache verfasst, aber ich hoffe um Nachsicht.

Otto, eines der Mitglieder von Codeberg, hat kürzlich einen Artikel bezüglich des Fediverse veröffentlicht, den ich recht interessant finde. Ohne ihn bewerten zu wollen.

Bei Codeberg handelt es sich um eine Alternative zu Github, die auch für die Entwicklung von Projekten genutzt wird, die unter Linux verwendete werden. Also zumindest so gesehen passt das Ganze doch zu Linux und OSS. Zumal ein Großteil aller Fediverse-Nutzer Linux oder OSS im Allgemeinen nutzen werden. Vergesst das mit der Nachsicht somit einfach. ;-)

Mein PinePhone in der Community Edition: UBports hat das letzte Update im Sommer 2021 empfangen. Es hängt auf Ubuntu 16.04 (2021-08-20) fest.

Nun habe ich mir überlegt mir das aktuelle Ubuntu Touch 20.04 herunterzuladen und es dann von der MicroSD-Karte zu starten.
Ich gehe auf die UT Projektseite https://gitlab.com/ook37/pinephone-pro-debos/-/releases und lade die Datei ubuntu-touch-pinephone-img-arm64.raw.xz herunter. Downloadseite

Ich schreibe das Image ohne es zu entpacken auf meine MicroSD-Karte.

andi@X230:~$ xzcat Downloads/ubuntu-touch-pinephone-img-arm64.raw.xz | sudo dd bs=8M status=progress of=/dev/mmcblk0

Das PinePhone bootet von der MicroSD-Karte. In den Systemeinstellungen -> Info -> Betriebssystem wird mir Ubuntu 16.04 (2021-08-20) angezeigt. Das ist die gleiche Version wie das von meinem instalierten UT auf dem PinePhone.
Wo ist Ubuntu Touch 20.04, gab es seit 2021 keine Aktualisierungen?

28. Februar 2024

Kurz notiert: heute wurde die Desktopumgebung Plasma 6 aus dem KDE-Projekt freigegeben. Mit dem Umstieg auf Qt 6 und den einhergehenden Arbeiten ist es nach knapp 10 Jahren der erste große Major-Release (KDE Plasma 5 wurde 2014 veröffentlicht). Eine weitere wegweisende Änderung ist, dass der Fokus nun klar auf dem Display-Server Wayland liegt, der auch nun zur Standardeinstellung wurde. X11 wird jedoch weiterhin unterstützt.

Eine Auswahl der weiteren Änderungen:

  • Es gibt einen neuen Overview-Effekt.
  • Durch Wayland wird nun auch HDR unterstützt.
  • Es gibt neue Filter zur Unterstützung bei Farbenblindheit.
  • Das Einstellungsprogramm wurde überarbeitet.
  • Der bekannte KDE Cube ist zurück.
  • Neue Standardeinstellungen:
    • Dateien/Verzeichnisse werden nun mit einem Klick ausgewählt und mit einem Doppelklick geöffnet.
    • Das Panel ist nun standardmäßig schwebend.
    • Thumbnail-Grid ist nun der Standard-Task-Switcher.
    • Scrollen auf dem Desktop führt nun nicht mehr zum Wechsel der virtuellen Desktops.

Auch die KDE-Anwendungen erfahren umfangreiche Updates. All diese Informationen können im Release Announcement nachvollzogen werden.

KDE Plasma 6 sollte nun sukzessive auch in die Distributionen Einzug halten. Arch Linux ist als Beispiel für einen Rolling Release da schon schnell dabei. Ob und inwiefern komplexe Setups des traditionell sehr einstellbaren Desktop-Systems umgezogen werden können, wird sich dann zeigen. Ein großer Vorteil des KDE-Ansatzes zeigt sich allerdings schon im Release-Announcement: viele der Funktionen können genutzt werden, müssen es aber nicht. Dem Endanwender wird die Wahl überlassen, welche Optionen er nutzen möchte.

26. Februar 2024

Irgendwann bin ich mal ueber Longplayer gestolpert und finde das ja grossartig 😄

Auf der Wikipedia Seite wird z.B. auch As Slow as Possible erwaehnt, auch super.

Vor allem grossartig finde ich, dass das auch gestreamt werden kann .

Noch besser finde ich aber, dass die Streamdatei eine pls Datei ist , die auch einfach mit cat geschrieben werden kann:

cat <<! >~/longplayer.pls
[playlist]
Title1=Longplayer
File1=http://icecast.spc.org:8000/longplayer
NumberOfEntries=1
Length1=-1
!

Und kann dann z.B. mit mpv abgespielt werden (die direkte URL wuerde uebrigens auch gehen):

mpv ~/longplayer.pls # oder direkt
mpv http://icecast.spc.org:8000/longplayer

Musik in der Shell finde ich schon sehr lange sehr spannend! 🎶 🤓

Ubuntu Pro ist eine Updateerweiterung für bestimmte Pakete der bekannten Distribution.
Ubuntu LTS soll so 10 Jahre Abdeckung für über 25.000 Pakete erhalten. Zusätzlich erhältst du Kernel Livepatching, Telefonsupport und Pakete fürs Hardening (NIST-certified FIPS crypto-modules, USG hardening mit CIS and DISA-STIG Profilen und Common Criteria EAL2).

Leider wird für dieses kostenpflichtige Produkt Werbung gemacht, auf dem Terminal und im Ubuntu Update Manager.
Sollte dich das stören, kannst du diese Meldungen mit wenigen Befehlen abschalten.
Alternativ kannst du dich auch einfach für Ubuntu Pro anmelden, denn der Zugang ist für Privatanwender für bis zu fünf Installationen umsonst.

Ubuntu Pro Nachrichten abschalten

sudo pro config set apt_news=false 

Das Abschalten der APT News reicht nicht ganz aus, um dir die Werbeeinblendung zu ersparen.
Du musst zusätzlich eine Datei editieren und deren Inhalt auskommentieren

nano /etc/apt/apt.conf.d/20apt-esm-hook.conf

ubuntu-pro-werbung-abschalten

Ubuntu Advantage deaktivieren oder deinstallieren

Optional kannst du das Ubuntu Advantage Paket entfernen, bzw. die Expanded SecurityMaintenance (ESM) abschalten, wenn du magst.
Ubuntu Advantage war der Vorgänger von Ubuntu Pro
Dieses beinhaltet wie die Pro-Variante Kernel Livepatching, Unterstützung für Landscape oder Zugriff auf eine Wissensdatenbank. Alles Dinge, die für Privatanwender nur bedingt interessant sind.

sudo systemctl disable ubuntu-advantage
#oder
sudo apt remove ubuntu-advantage-tools
# esm hook deaktivieren
sudo mv /etc/apt/apt.conf.d/20apt-esm-hook.conf /etc/apt/apt.conf.d/20apt-esm-hook.conf.disabled

Unterschied Ubuntu Advantage und Ubuntu Pro

Solltest du nun maximal verwirrt sein, was zu welchem Supportmodell gehört und wie es unterstützt wird, hier ein Vergleich von endoflifedate. Ubuntu Pro (Infra-Only) steht in der Tabelle für das alte Ubuntu Advantage.

ubuntu-lts-vs-ubuntu-pro

 

Mit einem Dualstack-Proxy Internet-Protokolle verbinden beschrieb eine Möglichkeit, um von Hosts, welche ausschließlich über IPv6-Adressen verfügen, auf Ziele zugreifen zu können, die ausschließlich über IPv4-Adressen verfügen. In diesem Beitrag betrachte ich die andere Richtung.

Zu diesem Beitrag motiviert hat mich der Kommentar von Matthias. Er schreibt, dass er für den bei einem Cloud-Provider gehosteten Jenkins Build Server IPv4 deaktivieren wollte, um Kosten zu sparen. Dies war jedoch nicht möglich, da Kollegen aus einem Co-Workingspace nur mit IPv4 angebunden sind und den Zugriff verloren hätten.

Doch wie kann man nun ein IPv6-Netzwerk für ausschließlich IPv4-fähige Clients erreichbar machen, ohne für jeden Host eine IPv4-Adresse zu buchen? Dazu möchte ich euch anhand eines einfachen Beispiels eine mögliche Lösung präsentieren.

Vorkenntnisse

Um diesem Text folgen zu können, ist ein grundsätzliches Verständnis von DNS, dessen Resource Records (RR) und des HTTP-Host-Header-Felds erforderlich. Die Kenntnis der verlinkten Wikipedia-Artikel sollte hierfür ausreichend sein.

Umgebung

Zu diesem Proof of Concept gehören:

  • Ein Dualstack-Reverse-Proxy-Server (HAProxy) mit den DNS-RR:
    • haproxy.example.com. IN A 203.0.113.1
    • haproxy.example.com IN AAAA 2001:DB8::1
  • Zwei HTTP-Backend-Server mit den DNS-RR:
    • www1.example.com IN AAAA 2001:DB8::2
    • www2.example.com IN AAAA 2001:DB8::3
  • Zwei DNS-RR:
    • www1.example.com IN A 203.0.113.1
    • www2.example.com IN A 203.0.113.1
  • Ein Client mit einer IPv4-Adresse

Ich habe mich für HAProxy als Reverse-Proxy-Server entschieden, da dieser in allen Linux- und BSD-Distributionen verfügbar sein sollte und mir die HAProxy Maps gefallen, welche ich hier ebenfalls vorstellen möchte.

Der Versuchsaufbau kann wie folgt skizziert werden:

Ein Dualstack-Reverse-Proxy-Server (B) verbindet IPv4-Clients mit IPv6-Backend-Servern

HAProxy-Konfiguration

Für dieses Minimal-Beispiel besteht die HAProxy-Konfiguration aus zwei Dateien, der HAProxy Map hosts.map und der Konfigurationsdatei poc.cfg.

~]$ cat /etc/haproxy/conf.d/hosts.map 
www1.example.com	serversa
www2.example.com	serversb

Eine HAProxy Map besteht aus zwei Spalten. In der ersten Spalte stehen die FQDNs, welche vom HTTP-Client aufgerufen werden können. In der zweiten Spalte steht der Name des Backends aus der HAProxy-Konfiguration, welcher bestimmt, an welche Backend-Server eine eingehende Anfrage weitergeleitet wird. In obigem Beispiel werden Anfragen nach www1.example.com an das Backend serversa und Anfragen nach www2.example.com an das Backend serversb weitergeleitet.

Die HAProxy Maps lassen sich unabhängig von der HAProxy-Konfigurations-Datei pflegen und bereitstellen. Map-Dateien werden in ein Elastic Binary Tree-Format geladen, so dass ein Wert aus einer Map-Datei mit Millionen von Elementen ohne spürbare Leistungseinbußen nachgeschlagen werden kann.

Die HAProxy-Konfigurations-Datei poc.cfg für dieses Minimal-Beispiel ist ähnlich simpel:

~]$ cat /etc/haproxy/conf.d/poc.cfg 
frontend fe_main
	bind :80
	use_backend %[req.hdr(host),lower,map(/etc/haproxy/conf.d/hosts.map)]

backend serversa
	server server1 2001:DB8::1:80
backend serversb
	server server1 2001:DB8::2:80

In der ersten Zeile wird ein Frontend mit Namen fe_main definiert. Zeile 2 bindet Port 80 für den entsprechenden Prozess und Zeile 3 bestimmt, welches Backend für eingehende HTTP-Anfragen zu nutzen ist. Dazu wird der HTTP-Host-Header ausgewertet, falls notwendig, in Kleinbuchstaben umgewandelt. Mithilfe der Datei hosts.map wird nun ermittelt, welches Backend zu verwenden ist.

Die weiteren Zeilen definieren zwei Backends bestehend aus jeweils einem Server, welcher auf Port 80 Anfragen entgegennimmt. In diesem Beispiel sind nur Server mit IPv6-Adressen eingetragen. IPv4-Adressen sind selbstverständlich auch zulässig und beide Versionen können in einem Backend auch gemischt auftreten.

Kann eine HTTP-Anfrage nicht über die hosts.map aufgelöst werden, läuft die Anfrage in diesem Beispiel in einen Fehler. Für diesen Fall kann ein Standard-Backend definiert werden. Siehe hierzu den englischsprachigen Artikel Introduction to HAProxy Maps von Chad Lavoie.

Der Kommunikationsablauf im Überblick und im Detail

Der Kommunikationsablauf im Überblick

Von einem IPv4-Client aus benutze ich curl, um die Seite www1.example.com abzurufen:

~]$ curl -4 -v http://www1.example.com
* processing: http://www1.example.com
*   Trying 203.0.113.1:80...
* Connected to www1.example.com (203.0.113.1) port 80
> GET / HTTP/1.1
> Host: www1.example.com
> User-Agent: curl/8.2.1
> Accept: */*
> 
< HTTP/1.1 200 OK
< server: nginx/1.20.1
< date: Sat, 06 Jan 2024 18:44:22 GMT
< content-type: text/html
< content-length: 5909
< last-modified: Mon, 09 Aug 2021 11:43:42 GMT
< etag: "611114ee-1715"
< accept-ranges: bytes
< 
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
	<head>
		<title>Test Page for the HTTP Server on Red Hat Enterprise Linux</title>

Der FQDN www1.example.com wird mit der IPv4-Adresse 203.0.113.1 aufgelöst, welche dem Host haproxy.example.com gehört. Bei der Zeile Host: www1.example.com handelt es sich um den HTTP-Host-Header, welchen der HAProxy benötigt, um das richtige Backend auszuwählen.

Es ist zu sehen, dass wir eine Antwort von einem NGINX-HTTP-Server erhalten. Der HTML-Quelltext wurde gekürzt.

Damit ist es gelungen, von einem IPv4-Client eine Ressource abzurufen, die von einem IPv6-Server bereitgestellt wird.

Im Access-Log des Backend-Servers mit der IPv6-Adresse 2001:DB8::2 sieht man:

2001:DB8::1 - - [06/Jan/2024:19:44:22 +0100] "GET / HTTP/1.1" 200 5909 "-" "curl/8.2.1" "192.0.2.1"

Die Anfrage erreicht den Backend-Server von der IPv6-Adresse des haproxy.example.com (2001:DB8::1). Die am Ende der Zeile zu sehende IPv4-Adresse (192.0.2.1) gehört dem IPv4-Client, von dem ich die Anfrage gesendet habe.

Gedanken zur Skalierung

In diesem Beispiel sind die Server www1.example.com und www2.example.com über ihre IPv6-Adressen direkt erreichbar. Nur die Client-Anfragen von IPv4-Clients laufen über den Reverse-Proxy. Wenn man es wünscht, kann man selbstverständlich sämtliche Anfragen (von IPv4- und IPv6-Clients) über den Reverse-Proxy laufen lassen.

In kleinen Umgebungen kann man einen Reverse-Proxy wie HAProxy zusammen mit Squid (vgl. Artikel Mit einem Dualstack-Proxy Internet-Protokolle verbinden) auf einem Host laufen lassen. Selbstverständlich kann man sie auch auf separate Hosts verteilen.

Hochverfügbarkeit lässt sich auch hier mit keepalived nachrüsten:

Abschließende Gedanken

Die Internet-Protokolle IPv4 und IPv6 werden wohl noch eine ganze Zeit gemeinsam das Internet bestimmen und parallel existieren. Ich bin mir sogar sicher, dass ich das Ende von IPv4 nicht mehr miterleben werde. Dualstack-(Reverse)-Proxy-Server stellen eine solide und robuste Lösung dar, um beide Welten miteinander zu verbinden.

Sicher bleiben noch ausreichend Herausforderungen übrig. Ich denke da nur an Firewalls, Loadbalancer, NAT und Routing. Und es werden sich auch Fälle finden lassen, in denen Proxyserver nicht infrage kommen. Doch mit diesen Herausforderungen beschäftige ich mich dann in anderen Artikeln.

Quellen und weiterführende Links