staging.inyokaproject.org

Mit Common Voice stellt Mozilla den weltweit größten öffentlichen Datensatz menschlicher Stimmen bereit – kostenlos und für jeden nutzbar. Mozilla hat Version 17.0 seines Datensatzes veröffentlicht.

Der Markt für Spracherkennung wird von den ganz großen Namen kommerzieller Anbieter dominiert: Amazon, Apple, Google, Microsoft. Darum hat Mozilla im Jahr 2017 das Projekt Common Voice gestartet. Mit Common Voice bietet Mozilla eine kostenlose Alternative an, zu der jeder beitragen kann und die jedem zur Verfügung steht. Damit möchte Mozilla Innovation und Wettbewerb in der Sprachtechnologie auf Basis von Maschinenlernen fördern.

Mit dem vor kurzem veröffentlichten Common Voice Corpus 17.0 wächst der deutschsprachige Datensatz von 1.403 auf 1.424 Stunden an. Wer bereits den Common Voice Corpus 16.1 besitzt, kann wie immer auch nur ein sogenanntes Delta Segment mit den Unterschieden zur Vorversion herunterladen. Für Deutsch würde das den Download von 33,4 GB auf 625 MB reduzieren.

Insgesamt deckt Mozilla Common Voice mit der neuen Version jetzt 124 Sprachen mit insgesamt 31.176 aufgenommenen Stunden ab, was Mozilla Common Voice zum vielfältigsten mehrsprachigen Sprachkorpus der Welt macht.

Zum Download der Mozilla Common Voice Datensätze

Der Beitrag Mozilla veröffentlicht Common Voice Corpus 17.0 erschien zuerst auf soeren-hentzschel.at.

Erst im Februar hatte Mozilla in Zusammenarbeit mit Onerep Mozilla Monitor Plus in den USA gestartet. Diese Zusammenarbeit kommt nun zu einem unerwarteten Ende.

Das ist Mozilla Monitor (Plus)

Mozillas kostenfreier Dienst Mozilla Monitor zeigt nach Eingabe einer E-Mail-Adresse an, ob diese Teil eines bekannten Datendiebstahls in der Vergangenheit war. Neben dem Zeitpunkt des Diebstahls und dem Zeitpunkt des Bekanntwerdens wird auch angegeben, welche Daten gestohlen worden sind, zum Beispiel E-Mail-Adressen, Benutzernamen oder Passwörter. Darüber hinaus nennt Mozilla Monitor allgemeine Tipps, welche man in Betracht ziehen sollte, wenn man von einem Datendiebstahl betroffen ist.

Anfang Februar dieses Jahres ist Mozilla Monitor Plus gestartet, bisher nur in den USA. Damit können persönliche Informationen von über 190 Personen-Suchmaschinen entfernt werden – einer laut Mozilla 240 Milliarden Dollar schweren Industrie, welche mit der Bildung von Profilen und dem Verkauf dieser Daten Profit generiert. Hierfür arbeitet Mozilla mit dem Dienstleister Onerep zusammen.

Ende der Zusammenarbeit mit Onerep

Nach einem Bericht von Brian Krebs, Journalist und Betreiber des Sicherheits-Blogs Krebs on Security, hat der Gründer und CEO von Onerep, Dimitiri Shelest, seit 2010 selbst zahlreiche solcher Personen-Suchmaschinen ins Leben gerufen. In diese ist er größtenteils nicht mehr involviert, ist mit Nuwber allerdings nach wie vor an einer beteiligt.

Auch wenn für Nutzer von Mozilla Monitor Plus durch die Verbindung keine direkte Problematik entstand, hat Mozilla das Thema damit kommentiert, dass die finanziellen Interessen und Aktivitäten des CEOs von Onerep nicht den Werten von Mozilla entsprechen. Mozilla Monitor Plus wird es weiterhin geben, aber Mozilla soll an einem „Übergangsplan“ arbeiten, welcher „den Kunden eine nahtlose Erfahrung bietet und ihre Interessen weiterhin an die erste Stelle setzt“. Weitere Details wurden keine genannt. Denkbar wäre, dass Mozilla die gleiche Dienstleistung in Zukunft über einen anderen Anbieter abwickeln wird.

Der Beitrag Mozilla Monitor Plus: Mozilla beendet Zusammenarbeit mit Onerep erschien zuerst auf soeren-hentzschel.at.

Wer Projekte per git auf dem aktuellen Stand halten will, aber sonst nicht viel mit git macht, braucht immer mal wieder dieselben Befehle, um die notwendigen Aktualisierungen durchzuführen. Da sind dann immer wieder diese Leute, die dann ein paar Befehle rüber werfen, aber nicht wirklich zwei klärende Worte zum Zusammenhang hinzufügen. Das Problem ist zwar damit vielleicht aus der Welt, aber es ist nichts damit gewonnen. Konfuzius rotierte im Grabe!

Gib einem Mensch einen Fisch und du ernährst ihn für einen Tag. Lehre einen Menschen zu fischen und du ernährst ihn für sein Leben.

Konfuzius

Wenn die Mehrzahl der EmpfehlerInnen nach dieser Maxime handeln würden, wäre das Frustrationspotential auf Myriaden von Webseiten und Foren nicht so hoch. Das musste ich mal los werden.

Ich gehe am praktischen Beispiel des Fediverse Servers Friendica vor. Den geübten Umgang mit z.B. Linux und der Konsole bzw der Shell Bash setze ich voraus. Ebenso ein installiertes git .

Git und das Repo

Das Software Repository, oft auch nur Repository oder Repo genannt, von Friendica liegt z.B. auf https://github.com/friendica/friendica . Das ist der Speicherort, auf dem die Software liegt und von Entwicklern gepflegt, programmiert und aktualisiert wird. Git ist eine Software, die gleichzeitig verschiedene Versionen von Dateien verwalten kann und für die Softwareentwicklung entwickelt wurde. Kurz gesagt ermöglicht sie es sehr einfach recht komplexe Version- Upgrades oder Downgrades absolut korrekt durchzuführen, so dass als Ergebnis immer eine saubere und lauffähige Version der Software bzw des Quellcodes herauskommt.
Mehr zum Thema git

Schritt 1: Die Software installieren – Das Repo clonen

Ich nehme mal an, du willst Friendica auf deinem Server installieren und hast das Webverzeichnis für deine Domain www.MeineDomain.de eingerichtet, das sich z.B. unter /var/web/MeineDomain/htdocs befindet. Und genau hier willst du Friendica installieren, daher wechselst du in dieses Verzeichnis. Das Verzeichnis muss komplett leer sein, sonst weigert sich git die Dateien hier abzulegen.

Der Befehl der dafür vorgeschlagen wird, ist oft

git clone https://github.com/friendica/friendica

ABER! Dieser würde dir in deinem /var/web/MeineDomain/htdocs/ Verzeichnis ein Unterverzeichnis friendica /var/web/MeineDomain/htdocs/friendica/anlegen und dort alle Dateien und Verzeichnisse ablegen. Und dein Server wäre dann nur unter www.MeineDomain.de/friendica/ erreichbar. Aber du möchtest, dass der Friendica Server unter www.MeineDomain.de erreichbar ist.

Daher musst du dem vorgeschlagenen Befehl noch ein Leerzeichen (Trenner) und einen Punkt (repräsentiert immer das aktuelle Verzeichnis) mitgeben, mit dem du angibst, dass die Dateien im aktuellen Verzeichnis abgelegt werden. Und dann sieht das so aus:

git clone https://github.com/friendica/friendica .

Damit liegt nun die Software, genauer gesagt die stable (früher master) Version, auf deinem Server und du kannst mit der Konfiguration und Einrichtung beginnen. Die Dokumentation dazu findest du unter https://wiki.friendi.ca/ .

Da die Addons für Friendica ein einem extra Repo https://github.com/friendica/friendica-addons liegen, müssen diese natürlich mit den gleichen Schritten eingerichtet und später dann auch aktualisiert werden.

Schritt 2: Aktualisierungen

In so einem Software Repo wird in den meisten Fällen nicht nur eine Software Version gepflegt, sondern meist mehrere. Eigentlich sind immer stable und develop bzw origin/stable und origin/develop verfügbar. Wie oben schon erwähnt hieß stable früher standardmäßig master, aber in modernen Repos gibt es nur noch den Namen stable oder öfter main. Hintergründe Bei Friendica heisst die aktuelle stabile Version stable.

Info: Für Friendica ist ein wenig mehr erforderlich. Die kompletten Befehle führe ich weiter unten auf. Aus Gründen der Verständlichkeit vereinfache ich die Vorgehensweise hier.

Ganz allgemein: Um deine Software zu aktualisieren wechselst du zukünftig in dein Verzeichnis /var/web/MeineDomain/htdocs/ und gibst den Befehl ein

git pull

und dein Friendica wird auf den neusten Stand gebracht. (Addons nicht vergessen)

Schritt 3: Versionen und branches

Nun gibt es wie oben schon geschrieben meist mindestens 2 Versionen. Die stable und die development Version. Die Versionen in git werden branches genannt. Welche branches du hast, kannst du ganz einfach herausfinden mit den Befehlen

Welche Branches liegen (remote) auf dem Software Repo
git branch -r

ergibt z.B. so eine Ausgabe

 origin/2022.09-rc
 origin/2022.12-rc
 origin/2023.03-rc
 origin/2023.05-rc
 origin/2023.09-rc
 origin/2024.03-rc
 origin/HEAD -> origin/develop
 origin/develop
 origin/stable

Welche Branches liegen (lokal) deinem Server
git branch -a

Um zu einem anderen branch bzw Version zu wechseln, gibst du einfach z.B. ein

git checkout develop um auf die Entwicklerversion zu wechseln
git checkout stable um auf die stabile Hauptversion zu wechseln.

Allerdings sollte so ein Wechsel immer gut durchdacht sein, denn oftmals kann das weitere Abhängigkeiten haben, wie zum Beispiel bei Friendica irgendwelche Updates von Datenstrukturen in der Datenbank. Älter Versionen kennen neuere Datenbankstrukturen nicht und das wird dann vermutlich zu Fehlern führen. Prüfe stehts!

Schritt 4: Updates und Versionen – development, stable & RC

Es gibt also die development Version, die immer die neusten Funktionen und Features hat, die aktiv entwickelt werden und daher mit einer hohen Wahrscheinlichkeit Fehler enthalten, die noch korrigiert (gefixt) werden müssen. Und die stabile stable Version, die zum produktiven Einsatz freigegeben wurde.

Dann gibt es oft noch RC (Release Candiates) Versionen. Zum Beispiel eine 2024.04-RC . Das ist eine aktuelle development Version, zu der keine neuen Features dazu kommen (Feature Freeze) und die zur nächsten stabilen Version werden soll. Diese Version ist mit einer öffentlichen Beta Version vergleichbar, die zur Verfügung gestellt wird, damit sie von vielen getestet und eventuelle Fehler behoben werden können. Wenn dann alle Fehler behoben sind, dann wird diese 2024.04-RC Version in die stable Version überführt.

Das heißt, wenn die Aktualisierung des eigenen Friendica Servers immer auf das branch stable eingestellt ist, dann wird beim nächsten git pull der Server automatisch auf die neuste Version aktualisiert. Wurde zuvor auf z.B. auf das RC 2024.04-RC branch gewechselt, muss natürlich dann aktiv auf das stable branch wieder zurück gewechselt werden. git checkout stable & git pull

Friendica per Git aktualisieren

Bei Friendica gibt es wie beschrieben noch das addon Verzeichnis und zusätzlich noch den Composer, der Abhängigkeiten von bestimmten Softwarebibliotheken verwaltet und sicherstellt, dass die richtigen Versionen auf deinem Server liegen. Daher müssen bei einer Aktualisierung mindestens folgende Befehle eingegeben werden.

Ausgehend dass du dich in deinem deinem Verzeichnis /var/web/MeineDomain/htdocs befindest:

git pull https://github.com/friendica/friendica.git
bin/composer.phar install --no-dev 
cd addon 
git pull https://github.com/friendica/friendica-addons.git 

weitere nützliche Git Befehle

git fetch – Die Liste der Branches vom Repo holen
git checkout <branch name> – Den Branch wechseln
git stash – Local commits „verwerfen“
git checkout -b <NAME> – Lokal einen neuen Branch <NAME> erstellen
git branch -D <NAME> – Lokalen Branch <NAME> löschen
git push origin --delete <NAME> – Den remote Branch <NAME> löschen
git branch -r – Remote Branches anzeigen lassen
git branch -a – Lokale Branches anzeigen lassen
git remote prune origin – Löscht alle lokalen Branches, die auch nicht mehr auf dem remote Repo sind
git gc --auto – Garbage Collection. führt Aufräumarbeiten durch (komprimiert Revisionen, entfernt lose/unzugängliche Objekte). Mit der Option –auto wird zunächst festgestellt, ob Maßnahmen erforderlich sind, und wenn dies nicht der Fall ist, wird das Programm beendet, ohne etwas zu tun.

Falls es zu Fehlermeldungen und größeren Problemen kommt, dann sind folgende Befehle hilfreich. ABER bitte vorher das Handbuch dazu lesen !!! Nicht einfach per Copy n Paste von hier benutzen! Sonst selber schuld!
git reset --hard
git clean -df -x

Views: 17

The post Git Leitfaden für Beginner first appeared on Dem hoergen Blog.

Dies ist mein Erfahrungsbericht der Chemnitzer Linux-Tage 2024. Es war mal wieder eine sehr schöne Veranstaltung.

Die Anreise

Im vergangenen Jahr hatte mich die Deutsche Bahn in Chemnitz sitzengelassen und ich musste mit einem kurzfristig angemieteten Leihwagen heimfahren.

Da die Deutsche Bahn und die Gewerkschaft Deutscher Lokomotivführer sich noch immer nicht auf einen neuen Tarifvertrag einigen können und ich mich nicht erneut über eine schlechte Verbindung ärgern wollte, bin ich dieses Jahr mit dem eigenen Pkw gefahren.

Am Freitag um 13:30 Uhr ging die Reise los. Mit viel Verkehr, Baustellen und Stau waren ich etwa 4,5 Stunden später im Hotel, wo ich direkt über Stoeps gestolpert bin.

Wir spazierten vom Residenz Hotel Chemnitz zum Veranstaltungsgebäude, um uns anzumelden und unsere Badges zu empfangen. Damit ersparten wir uns das Warten in der Schlange am Samstagmorgen.

Am Hörsaalgebäude traf ich schon erste vertraute Gesichter, wie z.B. Andreas, welcher fleißig beim Aufbau geholfen hat. Hier haben wir uns auch mit Michael von der Aspicon GmbH getroffen, mit dem ich für Sonntag einen Vortrag geplant hatte. Wir sind gemeinsam in die Stadt gegangen, um uns bei Speis und Trank kennenzulernen und den Abend zu verplaudern.

Der Samstag

Um 07:00 Uhr begann ich den Tag mit dem Frühstück. So war der erste Hunger bereits gestillt, als der Frühstücksraum sich zu füllen begann. Bekannte Gesichter und nerdige T-Shirts verrieten, dass es sich bei sehr vielen der Gäste um Besucher der Chemnitzer Linux-Tage handelte.

Die 20 Minuten zum Veranstaltungsort wurden auch diesmal wieder zu Fuß zurückgelegt. Und der erste Konferenztag konnte beginnen.

Um 10:00 Uhr war ich an der Reihe und durfte in einem rappelvollen Raum V6 meinen „::1“-Vortrag halten. An dieser Stelle euch allen nochmal vielen Dank für eure Teilnahme. Ich hoffe, ihr hattet so viel Spaß wie ich und konntet ein paar neue Eindrücke gewinnen.

Es hat mich gefreut, auch nach dem Vortrag noch einige Fragen beantworten zu können und über IPv6 zu fachsimpeln. Ganz nebenbei konnte ich auch noch die Frage eines Red Hat-Kunden beantworten. Darüber freute sich dieser sehr, bleibt ihm der Support eine zufriedenstellende Antwort doch seit langer Zeit schuldig. Es ist halt stets eine gute Erfahrung, einen TAM zu treffen.

Die Chemnitzer Linux-Tage gibt es übrigens schon seit 25 Jahren. Da eine Veranstaltung aufgrund der Pandemie ausfallen musste, findet die 25. Veranstaltung allerdings erst im nächsten Jahr am 22. und 23. März statt.

20-jähriges Jubiläum feiert in diesem Jahr Ubuntu, weshalb der Community-Stand dieses Jahr besonders schön geschmückt war und toddy mehrfach mit Luftschlangen gefesselt wurde.

Ich genieße die Zeit unter gleichgesinnten Nerds oder wie Stoeps es ausdrückte: „Endlich wieder unter normalen Menschen“. Mich hat es dieses Jahr sehr gefreut, auch viele jüngere Gesichter zu sehen. So sehr ich mich freue, auch die gleichen alten Nasen immer wiederzutreffen ist es doch schön, dass die Gemeinschaft nicht einfach alt wird, sondern auch junge Menschen mit Interesse, Motivation und Freude an Open Source nachwachsen.

Da die Hörsäle hier bei den Vorträgen meist aus allen Nähten platzen, hatte ich mich im Vorfeld als Sessionleitung für die drei Vorträge

1. Never ever break userspace – was das in der Praxis bedeutet von Wolfram Sang
2. DIY Verified Boot in 2024 von Marco Felsch und
3. VirtualBox Meets KVM von Julian Stecklina

gemeldet. So war mir ein guter Platz im Raum sicher. Ich danke den drei Referenten für ihre interessanten Vorträge.

Am Abend waren alle Aussteller, Helfer und Referenten zum gemütlichen Beisammensein in die Mensa eingeladen, welche schräg gegenüber dem Veranstaltungsgebäude liegt. Hier gab es ein reichhaltiges Angebot an warmem und kaltem Essen sowie eine Auswahl verschiedenster Getränke. Vielleicht ist es in der Zukunft möglich, die Getränke zu kühlen. Dann wird das Bier nicht so schnell warm und schmeckt länger gut.

Ich schätze es sehr, mich auf Konferenzen mit alten und neuen Bekannten auszutauschen, zu fachsimpeln und ganz allgemein angeregte Gespräche zu führen. Das musikalische Rahmenprogramm traf auch in diesem Jahr nicht meinen Geschmack. Ich würde mir etwas Hintergrundberieselung wünschen, um sich gut unterhalten zu können. Doch sind Geschmäcker verschieden und ich erkenne durchaus an, was das Organisations-Team der Chemnitzer Linux-Tage hier Jahr für Jahr auf die Beine stellt. Euch allen vielen Dank für euren unermüdlichen Einsatz.

Der Sonntag

Nach einem frühen Frühstück und Check-out ging es heute mit dem Auto zum Veranstaltungsgelände. Noch vor dem zweiten Kaffee wurden hier die Folien für den nächsten Vortrag nochmal geprüft. Um 10:00 Uhr war es wieder soweit. Diesmal durfte ich zusammen mit Michael den Vortrag „Mit Ansible Collections & Workflows gegen das Playbook-Chaos“ halten.

@Michael: „Es hat mir gut gefallen, mit dir einen Vortrag zu halten. Das können wir gerne wiederholen.“

Beim Mittagessen habe ich dann auch noch Christian getroffen. Für ihn waren es die ersten Chemnitzer Linux-Tage und auch ihm haben sie sehr gut gefallen.

Und wie immer war die Zeit auch viel zu schnell wieder vorbei. So habe ich Henning zwar kurz gesehen, doch für mehr als ein kurzes „Hi und Tschüss, bis zum nächsten Mal“ reichte es diesmal leider nicht.

Die Heimreise

Auch die schönsten Chemnitzer Linux-Tage gehen vorbei. Doch im Auto sitzend freute ich mich auch schon darauf, meine Familie wiederzusehen. Die Straße war frei und nach nur 3 Stunden 20 Minuten war ich wieder daheim. Zum Vergleich, mit der Bahn wäre ich je nach Verbindung erst nach 5,5-6,5 Stunden daheim gewesen, wenn alles nach Plan fährt.

So konnte ich mehr Zeit vor Ort verbringen und war rechtzeitig daheim, um noch etwas Zeit mit meinem Sohn zu verbringen, bevor dieser ins Bett ging.

Fazit

Es war schön. Ich hoffe, ihr seid alle wieder gut heimgekommen und behaltet auch diese Chemnitzer Linux-Tage in guter Erinnerung.

Weitere Berichte über die CLT 2024

• Chemnitzer Linux-Tage 2024 – Rückblick (Andreas Scherbaum)
• Chemnitzer Linux Tage 2024 (Christian Stankowic)
• Wir waren bei den CLT2024 (TUXEDO Computers)
• IT-Klassentreffen in Sachsen (Hostsharing eG)
• Ein Kurzbericht von unserem Besuch der CLT2024 (Linux User Group Nürnberg)

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.

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.

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

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

# ---------- 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 

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

## 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

sudo ufw allow 45881

nano /etc/default/ufw 

DEFAULT_FORWARD_POLICY="ACCEPT"

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

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

nano /etc/ufw/sysctl.conf

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

# -------- 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 

Weblinks

• https://www.wireguard.com/
• https://www.timoschindler.de/tag/arch-linux/
• https://github.com/zaneschepke/wgtunnel
• https://git.zilium.de/-/snippets/8
• https://android.stackexchange.com/questions/254262/why-isnt-wireguard-available-on-f-droid
• https://requestforcomments.de/archives/682

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.

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.

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.

proto udp

proto udp6

proto udp6
multihome

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

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

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

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

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

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

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

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

Weblinks

• https://wiki.archlinux.org/title/OpenVPN
• https://f-droid.org/packages/de.blinkt.openvpn/
• https://github.com/schwabe/ics-openvpn
• https://community.openvpn.net/openvpn/ticket/442
• https://requestforcomments.de/archives/682

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.

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.

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.

sudo apt install openvpn easy-rasa

pacman -S openvpn easy-rsa 

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

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

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

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

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 

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

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

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

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

openvpn /etc/openvpn/server/produnis.conf

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

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

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

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/

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

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

openvpn /etc/openvpn/client/produnis.conf

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

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

ifconfig-push 10.5.5.x 10.5.5.1

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

systemctl restart openvpn-server@produnis.service

## 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

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

nano /etc/default/ufw 

DEFAULT_FORWARD_POLICY="ACCEPT"

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

nano /etc/ufw/sysctl.conf

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

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

Weblinks

• https://wiki.archlinux.org/title/OpenVPN
• https://wiki.archlinux.org/index.php/Easy-RSA
• https://www.itsfullofstars.de/2018/09/openvpn-assign-static-ip-to-client/
• https://bbs.archlinux.org/viewtopic.php?id=293930
• https://requestforcomments.de/archives/682

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

 

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.

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.

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.

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)

Weitere hyperblog Artikel zum Thema

pipewire

Views: 36

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

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.

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

Weitere hyperblog Artikel zum Thema

vim

Views: 47

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.

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.

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?

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.

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! 🎶 🤓

Danke, dass du das hier via RSS liest! :)

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:

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

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:

• Keepalived and HAProxy in IBM Documentation
• Chapter 1.3. keepalived and haproxy in RHEL 7 Documentation

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

• https://de.wikipedia.org/wiki/Domain_Name_System
• https://de.wikipedia.org/wiki/Hypertext_Transfer_Protocol
• https://de.wikipedia.org/wiki/Host_(HTTP-Header-Feld)
• https://de.wikipedia.org/wiki/Resource_Record
• https://www.rfc-editor.org/rfc/rfc2606.html
• https://www.rfc-editor.org/rfc/rfc3849.html
• https://www.rfc-editor.org/rfc/rfc5737.html
• https://www.haproxy.org/
• https://www.haproxy.com/blog/introduction-to-haproxy-maps
• https://keepalived.org/
• Keepalived and HAProxy in IBM Documentation
• Chapter 1.3. keepalived and haproxy in RHEL 7 Documentation

Mit dem Taschenrechner Taschencomputer Sharp PC-1500 von meinem Vater habe ich vor Dekaden (ca. 2) angefangen zu programmieren. Ganz simpel in Basic. Haengen geblieben ist auf jeden Fall das “goto” *in Nostalgie schwelg*

Einen Weiterleitungsservice (bzw. Kurz-URL-Dienst ) wie bitly wollte ich schon lange selbst hosten. Open Source Varianten gibt es ja einige .

Aber warum noch eine weitere Software einsetzen, wenn es auch einfach™ mit Hugo geht, was ich sowieso schon nutze?

Im Folgenden stelle ich 3 Varianten vor, einmal die native Version mit Aliases (wenigster Aufwand, aber auch Voraussetzung fuer die beiden anderen Varianten), dann via einem Apache Webserver und .htaccess-Dateien (mittlerer Aufwand, Apache muss natuerlich eingesetzt werden) und zuletzt via einem nginx Webserver und inkludierten Dateien (hoechster Aufwand, nginx muss natuerlich eingesetzt werden).

Aliases #

Das folgende ist abgeguckt von Dan North (von dort kam auch die Inspiration fuer das alles hier) und nutzt das Hugo Alias Template .

Im Prinzip nutze ich dafuer eine eigene Sektion unter content namens goto.

Fuer die goto-Uebersichtsseite nutze ich dazu ein list.html Template:

1
2
3
4
5

{{ define "main" }}
  {{ partial "title.html" . }}
  {{ .Content }}
  {{ partial "goto-list.html" . }}
{{ end }}

title.html enthaelt quasi nur die Ueberschrift und .Content den Text auf dieser Uebersichtsseite. Spannend ist das Partial goto-list.html:

Hierdurch werden nur die Shortlinks in der Uebersicht angezeigt, die den Parameter public auf true gesetzt haben. Eine Beispieldatei ist z.B. diese hier, die dann dort auch angezeigt wird:

1
2
3
4
5

---
title: "Linkshrubbery"
public: true
target: https://ls.uxg.ch
---

Der Rest der Magic passiert dann auf der Detailseite, hier wird die Markdowndatei via des Alias Templates in eine kleine HTML-Datei umgewandelt, die dann mit Hilfe von dem <meta> http-equiv Attribut eine Weiterleitung auf das target macht:

1
2

{{- /* https://dannorth.net/hugo-redirects/ */ -}}
{{- template "alias.html" (dict "Permalink" .Params.target) -}}

Soweit so gut, dieses “Feature” nutze ich auch in vielen alten Eintraegen, damit auch weiterhin Weiterleitungen funktionieren.

Leider hat das einen Nachteil, denn es ist keine “richtige” Weiterleitung. Z.B. wird curl es nicht als Weiterleitung erkennen , da der Status-Code keine 3xy ist.

Apache #

Diese Variante habe ich mir von Til Seiffert abgeguckt . Dort wird eine .htaccess-Datei genutzt, um alle Hugo Aliases in einer Datei zu sammeln und damit eine “richtige” und schnellere Weiterleitung zu bekommen.

In meinem Anwendungsfall brauche ich das nicht fuer alle Aliases, sondern eben nur fuer die in der Sektion goto, aber die Vorgehensweise ist aehnlich.

Zur Nutzung muss die hugo.toml , genauer outputFormats und mediaTypes erweitert werden:

[outputFormats.htaccess]
  baseName       = ".htaccess"
  isPlainText    = true
  mediaType      = "text/htaccess"
  notAlternative = true

[mediaTypes."text/htaccess"]
  suffixes = ""

Zudem muss noch im Front matter der content/goto/_index.md festgelegt werden, dass fuer diese Sektion “html” und “htaccess” ausgegeben werden soll, aber kein “rss”, was erstmal der Standard fuer Sektionen ist:

---
title: "goto"
# no rss here please, but html and htaccess
outputs:
- html
- htaccess
---

Die eigentliche .htaccess fuer die Sektion goto sieht dann wie folgt aus (hier wird eine Hugo Page Methode namens File genutzt):

1
2
3
4

RewriteEngine On
{{ range .Pages -}}
Redirect 302 ./{{ with .File }}{{ .BaseFileName }}{{ end }}(\/?)$ {{ .Params.target }}
{{ end -}}

Ich habe hier den HTTP-Statuscode 302 gewaehlt, da sich die Ziele theoretisch aendern koennen (und nginx diesen Code auch nutzt fuer die temporaere Weiterleitung). 307 waere auch eine Moeglichkeit.

Da ich nicht Apache als Webserver einsetze, kann ich nicht garantieren, dass das auch alles so klappt. Aber mit der .htaccess in einem Verzeichnis sollte™ das gehen. Wenn nicht, gerne Bescheid geben.

nginx #

Da ich als Webserver nginx einsetze und hierbei die Nutzung von .htaccess-Dateien keine gute Idee ist, habe ich mir was anderes ueberlegt.

Die Vorgehensweise aehnelt hier sehr der Apache-Variante, denn auch hier muessen outputFormats und mediaTypes in der hugo_toml hinzugefuegt werden:

[outputFormats.nginx]
  baseName       = "nginx"
  isPlainText    = true
  mediaType      = "text/conf"
  notAlternative = true

[mediaTypes."text/conf"]
  suffixes = ["conf"]

Wie bei Apache auch wollen wir diese Datei ja nur in der Sektion goto haben, daher tragen wir auch nur im Front matter der content/goto/_index.md folgendes ein:

---
title: "goto"
# no rss here please, but html, htaccess and nginx
outputs:
- html
- htaccess
- nginx
---

Und definieren zu guter Letzt noch eine nginx.conf (Doku ):

1
2
3

{{- range .Pages -}}
rewrite ./{{ with .File }}{{ .BaseFileName }}{{ end }}(\/?)$ {{ .Params.target }} redirect;
{{ end -}}

So, jetzt wird es spannend. Wie bekommt nginx jetzt diese Regeln mit? Eine .htaccess koennen wir ja nicht einsetzen.
Aber wir koennen include nutzen ! Das geht auch, wenn die Datei leer ist, allerdings leider nicht, wenn die Datei nicht vorhanden ist.

Entweder wird also der Ordner goto und eine leere nginx.conf angelegt, oder wir passen die nginx Config erst an, wenn die Website mit hugo gebaut wurde.

Jedenfalls sieht meine nginx Config in etwa so aus:

server {
  # [...]
  server_name uxg.ch;
  location / {
    include /path/to/goto/nginx.conf;
  }
}

Nice!

Weiteres #

Hier noch ein paar weitere Anpassungsmoeglichkeiten bzw. Ideen.

Public vs. private #

Im Prinzip koennen auch alle Weiterleitungen oeffentlich sein, dann kann sich der Aufwand mit dem Parameter “public” auch gespart werden.

Allerdings verwende ich den nun und muss mich daher auch drum kuemmern, dass nicht aus Versehen was in den RSS Feeds, der Sitemap oder sonst wo auftaucht.

RSS #

Fuer die Sektion goto habe ich ja im Front matter schon keine RSS-Feeds erlaubt (und damit den Default ueberschrieben ), siehe Apache-Variante bzw nginx-Variante.

Sitemap #

Die Standard sitemap.xml habe ich sowieso schon angepasst, falls ich Seiten habe, die ich mit dem Parameter “exclude” eben nicht in der Sitemap haben will (siehe GitHub Issue #653 dazu). Fuer die Sektion goto kam dann noch ein Zusatz dazu.

Komplett sieht das dann so aus:

Cleanup #

Theoretisch brauchen wir mit Einsatz von Apache oder nginx die Alias-Dateien nicht mehr, also koennte die Datei layouts/goto/single.html auch geloescht werden.

“Anonym” weiterleiten #

Um “anonym”, also ohne Referrer auf andere Websites weiterzuleiten (auch Dereferrer genannt), kann das <meta> name Attribut genutzt werden.

Fuer ein Codebeispiel siehe redirect.html#L9 oder diesen curl-Aufruf:

$ curl -L "https://url.scriptsez.net?https://uxg.ch"
<html><head><meta name="referrer" content="no-referrer" /><meta http-equiv=refresh content="0;url='https://uxg.ch'"></head></html>

Entweder kann also im Prinzip das Alias-Template um diese Zeile erweitert werden oder im Webserver der entsprechende Parameter gesetzt werden.

QR-Code #

Als kleine™ Spielerei koennte jetzt noch an jeden “goto” ein QR-Code dran geklebt werden. Z.B. koennte neben der nginx Datei auch noch fuer jeden Link eine Textdatei erstellt werden, die den Link enthaelt. Ein Script koennte dann vor dem Bauen der Website mit hugo via find ueber all diese Textdateien drueberlaufen und mit einem Text-QR-Code ersetzen, die dann z.B. mit readfile eingebunden werden.

Ja, richtig gelesen, QR-Codes muessen nicht unbedingt Bilder sein, sondern koennen auch aus Text bestehen. qrencode bringt sowas auch schon mit:

qrencode -t UTF8i "https://uxg.ch" | sed 's/[ \t]*$//;/^$/d'

Ein kleiner Shortcode dazu:

Und damit sieht das ganze dann so aus:

    █▀▀▀▀▀█  █▀█▀ █▀▀▀▀▀█
    █ ███ █ ▄█▄▄  █ ███ █
    █ ▀▀▀ █ ▀ █ █ █ ▀▀▀ █
    ▀▀▀▀▀▀▀ ▀▄█ █ ▀▀▀▀▀▀▀
    ▀█▄▄ ▀▀▀ ▀   ▄  ▀█▄▄
    ▀█▄▄▀ ▀▀█▄██▀█▀█▄▄█▀
    ▀ ▀   ▀▀▄▀ ▀▀▄  ▄▄▄▀▄
    █▀▀▀▀▀█ ██▀▀▀█▄▀ ▄█▀
    █ ███ █  █▀▀ ▀███▀▄▀▀
    █ ▀▀▀ █ ▄▀▄█▀█▀████▀▀
    ▀▀▀▀▀▀▀ ▀  ▀▀ ▀▀ ▀ ▀

Geil! Ausgelesen werden koennen diese z.B. mit einer meiner Lieblings-Android-Apps: Binary Eye

Update (2025-01-17): Oder es wird einfach die naechste Hugo Version abgewartet, wo ein Shortcode zur Generierung von QR-Codes jetzt einfach nativ enthalten ist. Mega geil, love it! 😍

Die kleine™ Spielerei habe ich somit nun auch eingebaut 🎉

Danke, dass du das hier via RSS liest! :)