Kurz notiert: es gibt Situationen, in denen man Pfade auflösen, also relative Pfade in absolute umwandeln möchte. Für Anwender, die dabei Konstruktionen mit pwd und kompliziertes Parsing umgehen wollen, bietet sich realpath aus den GNU Coreutils an.

Die Bedienung ist denkbar einfach: realpath nimmt beliebig viele Pfade als Argumente auf und gibt die absoluten Pfade zeilenweise aus. Dabei werden standardmäßig auch Symlinks aufgelöst, sodass der „wahre“ Pfad, im Programmkontext auch physischer Pfad genannt, angezeigt wird.

Mit einigen Zusatzoptionen, die sich in der Manpage realpath(1) finden lassen, kann weiterhin das Verhalten angepasst werden. Hier sei zum Beispiel -e erwähnt, das einen strikteren Modus aktiviert und überprüft, ob das letzte Element im Pfad überhaupt existiert – stanardmäßig ist dies nicht der Fall. Mit -s kann die bereits beschriebene Auflösung von Symlinks deaktiviert werden.

Alles in allem, ein hilfreiches Werkzeug, besonders für Shellscripte. Der Quelltext von realpath ist auch überschaubar und beispielsweise auf GitHub zu finden.

2017 schrieb ich über die Einrichtung von DNSCrypt in Debian, mittlerweile nutze ich aber DNS-over-TLS (DoT) mit einem eigenen server. Sowohl auf Server-, als auch auf Client-Seite nutze ich knot-resolver.

Einrichtung

Server

Zuerst muss das Paket knot-resolver installiert werden:

apt install knot-resolver

Danach muss /etc/knot-resolver/kresd.conf editiert werden:

net.listen('127.0.0.1', 53)
net.listen('IP4', 853, { kind = 'tls' })
net.listen('IP6', 853, { kind = 'tls' })
user('knot-resolver','knot-resolver')
cache.size = 2*GB

modules = {
  'view',
  'hints > iterate',
  'serve_stale < cache',
  'workarounds < iterate'
}

Statt IP4 und IP6 muss natürlich die IP-Adresse eingegeben werden, auf der der server über DoT erreichbar sein soll. Ggf. muss man natürlich auch noch den Port 853 in der firewall für Zugriffe von Außen freigeben.

Anschließend aktiviert man den server folgendermaßen:

systemctl enable --now kresd@{1..4}.service

Zugriff auf TLS-Zertifkate

Ohne weitere Konfiguration benutzt kresd selbstsignierte Zertifikate für DoT. Ich habe auf meinem server bereits Zertifikate von Let’s Encrypt und möchte diese auch für DoT nutzen. Um die Zertifikate für kresd erreichbar zu machen habe ich ein kleines Skript geschrieben:

cp /etc/letsencrypt/live/mdosch.de/privkey.pem /var/lib/knot-resolver
cp /etc/letsencrypt/live/mdosch.de/fullchain.pem /var/lib/knot-resolver
chown -R knot-resolver:knot-resolver /var/lib/knot-resolver 
chmod 700 /var/lib/knot-resolver
systemctl restart kresd@{1..4}.service

Die Pfade der Zertifikate sind natürlich anzupassen und das Skript muss nach dem Speichern ausführbar gemacht werden:

chmod +x /pfad/zum/script.sh

Damit das Skript auch ausgeführt wird wenn certbot die Zertifikate erneuert, lasse ich es mittels --renew-hook aufrufen.

Nun muss die Konfiguration abgeändert werden (Zeile 1) damit kresd die Zertifikate auch nutzt:

net.tls("/var/lib/knot-resolver/fullchain.pem", "/var/lib/knot-resolver/privkey.pem")
net.listen('127.0.0.1', 53)
net.listen('IP4', 853, { kind = 'tls' })
net.listen('IP6', 853, { kind = 'tls' })
user('knot-resolver','knot-resolver')
cache.size = 2*GB

modules = {    
  'view',                   
  'hints > iterate',         
  'serve_stale < cache',     
  'workarounds < iterate'
}

Danach muss kresd neu gestart werden:

systemctl restart kresd@{1..4}.service

Werbung und Tracking filtern

Ich möchte Werbung und Tracking direkt auf DNS-Ebene blocken und nutze dafür die Blocklisten von hBlock. Wenn man das hBlock-repo klont und dort make hosts ausführt erhält man u.a. eine Datei hosts_rpz.txt im Ordner dist. Diese Datei kann kresd einlesen und die dort gelisteten hosts bei DNS-Abfragen blockieren. Die Konfiguration muss folgendermaßen angepasst werden (Zeilen 13 und 16):

net.tls("/var/lib/knot-resolver/fullchain.pem", "/var/lib/knot-resolver/privkey.pem")
net.listen('127.0.0.1', 53)
net.listen('IP4', 853, { kind = 'tls' })
net.listen('IP6', 853, { kind = 'tls' })
user('knot-resolver','knot-resolver')
cache.size = 2*GB

modules = {    
  'view',                   
  'hints > iterate',         
  'serve_stale < cache',     
  'workarounds < iterate',
  'policy'
}

policy.add(policy.rpz(policy.DENY, '/pfad/zu/hosts_rpz.txt'))

Danach muss kresd wieder neu gestart werden:

systemctl restart kresd@{1..4}.service

Rekursives Blocken

Einige Trackingfirmen nutzen für ihre Kunden subdomains um die üblichen Schutzmaßnahmen zu umgehen, z.B. zn0lxkzethotizctx-bahn.siteintercept.qualtrics.com. Um den Schutz vor Tracking zu verbessern kann man auch rekursiv alle subdomains der domains in der Blockliste sperren.

Mit Hilfe von hBlock kann man eine Blockliste erstellen, die über wildcards auch die Subdomains umfasst:

hblock --output ./hosts_rpz.txt --header none --footer none --redirection '.' --template '%D CNAME %R\n*.%D CNAME %R' --comment ';' --filter-subdomains

Durch rekursives Blocken wird aber auch eine zufällig generierte subdomain in der Form <random>-dnsotls-ds.metric.gstatic.com geblockt, die bei Benutzung von DoT in Android genutzt wird. Um die resultierende Fehlermeldung in Android zu vermeiden wird diese subdomain gezielt erlaubt und folgendes in /etc/knot-resolver/kresd.conf eingetragen:

policy.add(policy.pattern(
	policy.PASS,
	'%w+%-dnsotls%-ds\006metric\007gstatic\003com\000$'
))

Client

Linux

Auf dem client muss ebenfalls das Paket knot-resolver installiert werden:

apt install knot-resolver

Die Konfiguration /etc/knot-resolver/kresd.conf gestaltet sich auf dem client recht simpel:

net.listen('127.0.0.1', 53, { kind = 'dns' })

modules = {
        'policy',
}

policy.add(policy.all(policy.TLS_FORWARD({
    {'5.181.50.75', hostname='mdosch.de'},
    {'2a03:4000:3f:1c8:8839:33ff:feba:fe4a', hostname='mdosch.de'},
})))

Die IPs und der hostname müssen natürlich gegen eure IPs und domain ausgetauscht werden.

Auch hier muss kresd aktiviert werden:

systemctl enable --now kresd@{1..4}.service

Anschließend muss man dem System mitteilen, den DNS-forwarder unter 127.0.0.1:53 zu nutzen. Das tut man indem man die Datei /etc/resolv.conf folgendermaßen editiert:

nameserver 127.0.0.1

Ggf. muss man noch den NetworkManager zähmen, damit dieser nicht die Datei /etc/resolv.conf überschreibt.

Android

Unter Android kann der DoT server folgendermaßen konfiguriert werden:

Einstellungen → Netzwerk & Internet → Erweitert → Privates DNS

Dort ist dann die domain, in meinem Fall z.B. mdosch.de, einzutragen.

Test

Zum testen kann man den Befehl dig aus dem Paket bind9-dnsutils nutzen. Mit z.B. dig debian.org bekommt man folgende Ausgabe:

dig debian.org      

; <<>> DiG 9.17.19-1-Debian <<>> debian.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13249
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;debian.org.			IN	A

;; ANSWER SECTION:
debian.org.		280	IN	A	128.31.0.62
debian.org.		280	IN	A	130.89.148.77
debian.org.		280	IN	A	149.20.4.15

;; Query time: 240 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Sun Oct 31 11:00:57 CET 2021
;; MSG SIZE  rcvd: 87

Hier wurde die domain debian.org erfolgreich aufgelöst und die Zeile ;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP) zeigt, dass der lokale DNS-forwarder benutzt wurde.

Man kann natürlich auch Webseiten, wie z.B. dnsleaktest.com, benutzen um zu sehen welche DNS-server benutzt werden.

Mit dig google-analytics.com kann getestet werden ob das Blocken von Werbung und Tracking auch funktioniert:

dig google-analytics.com

; <<>> DiG 9.17.19-1-Debian <<>> @127.0.0.1 google-analytics.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 19517
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;google-analytics.com.		IN	A

;; Query time: 220 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Sun Oct 31 11:03:38 CET 2021
;; MSG SIZE  rcvd: 49

Hier wurde google-analytics nicht aufgelöst (status: SERVFAIL), die Blockliste wird also genutzt.

Updates

• 2022-03-06: Abschnitt Rekursives Blocken hinzugefügt.

apt install knot-resolver

net.listen('127.0.0.1', 53)
net.listen('IP4', 853, { kind = 'tls' })
net.listen('IP6', 853, { kind = 'tls' })
user('knot-resolver','knot-resolver')
cache.size = 2*GB

modules = {
  'view',
  'hints > iterate',
  'serve_stale < cache',
  'workarounds < iterate'
}

systemctl enable --now kresd@{1..4}.service

cp /etc/letsencrypt/live/mdosch.de/privkey.pem /var/lib/knot-resolver
cp /etc/letsencrypt/live/mdosch.de/fullchain.pem /var/lib/knot-resolver
chown -R knot-resolver:knot-resolver /var/lib/knot-resolver 
chmod 700 /var/lib/knot-resolver
systemctl restart kresd@{1..4}.service

chmod +x /pfad/zum/script.sh

net.tls("/var/lib/knot-resolver/fullchain.pem", "/var/lib/knot-resolver/privkey.pem")
net.listen('127.0.0.1', 53)
net.listen('IP4', 853, { kind = 'tls' })
net.listen('IP6', 853, { kind = 'tls' })
user('knot-resolver','knot-resolver')
cache.size = 2*GB

modules = {    
  'view',                   
  'hints > iterate',         
  'serve_stale < cache',     
  'workarounds < iterate'
}

systemctl restart kresd@{1..4}.service

net.tls("/var/lib/knot-resolver/fullchain.pem", "/var/lib/knot-resolver/privkey.pem")
net.listen('127.0.0.1', 53)
net.listen('IP4', 853, { kind = 'tls' })
net.listen('IP6', 853, { kind = 'tls' })
user('knot-resolver','knot-resolver')
cache.size = 2*GB

modules = {    
  'view',                   
  'hints > iterate',         
  'serve_stale < cache',     
  'workarounds < iterate',
  'policy'
}

policy.add(policy.rpz(policy.DENY, '/pfad/zu/hosts_rpz.txt'))

systemctl restart kresd@{1..4}.service

hblock --output ./hosts_rpz.txt --header none --footer none --redirection '.' --template '%D CNAME %R\n*.%D CNAME %R' --comment ';' --filter-subdomains

policy.add(policy.pattern(
	policy.PASS,
	'%w+%-dnsotls%-ds\006metric\007gstatic\003com\000$'
))

apt install knot-resolver

net.listen('127.0.0.1', 53, { kind = 'dns' })

modules = {
        'policy',
}

policy.add(policy.all(policy.TLS_FORWARD({
    {'5.181.50.75', hostname='mdosch.de'},
    {'2a03:4000:3f:1c8:8839:33ff:feba:fe4a', hostname='mdosch.de'},
})))

systemctl enable --now kresd@{1..4}.service

Fr, 29. Oktober 2021, Ralf Hersel

Der neueste Fedora Release wurde gestern beim Fedora-Meeting als "GO" für die Veröffentlichung in der nächsten Woche erklärt. Fedora 35 wird am 2. November ausgeliefert, nachdem der ursprüngliche Termin am 19. Oktober und der Nachfolgetermin am 26. Oktober aufgrund von ungelösten Problemen nicht eingehalten werden konnten. Das ist nicht so schlimm wie Fedoras berüchtigte Verspätungen von vor vielen Jahren, und zumindest setzt das Team dieses Mal eher auf Qualität als auf Pünktlichkeit.


Fedora 35 Workstation nutzt die kürzlich veröffentlichte GNOME 41 Desktop-Umgebung, um dort die neuesten Desktop-Verbesserungen bereitzustellen, von denen viele von Red Hats Ingenieuren entwickelt wurden. Auf der Desktop-Seite wird PipeWire weiterhin für alle Audio-Bedürfnisse verwendet, während WirePlumber der Standard-Sitzungsmanager geworden ist. Fedora 35 enthält viele Paketaktualisierungen, von Python 3.10 über PHP 8.0 bis hin zu Perl 5.34 und den neuesten XWayland-, Mesa- und anderen Verbesserungen.

Quelle: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/AXGQCCE66LTSVJXWULKBT4DOMAWJM2BD/

Mo, 25. Oktober 2021, Ralf Hersel

Es ist wieder so weit: Canonical startet den Entwicklungszyklus der nächsten Ubuntu-LTS-Version, in diesem Fall Ubuntu 22.04 LTS (Jammy Jellyfish). Ab jetzt können Interessierte, Tester und Anwendungsentwickler die täglichen Builds für Jammy Jellyfish herunterladen.

Neben Ubuntu, das Desktop-Varianten für 64-Bit- und ARM64-Architekturen (AArch64) anbietet, findet man auch tägliche Builds für die Varianten Kubuntu, Xubuntu, Lubuntu, Ubuntu MATE, Ubuntu Budgie und Ubuntu Kylin.

Wie üblich basieren diese täglichen Builds auf der letzten Ubuntu-Version, Ubuntu 21.10 (Impish Indri). Das bedeutet, dass diese auf dem Linux-Kernel 5.13 basieren und grösstenteils die gleichen Paketversionen, Artworks und Desktop-Umgebungen enthalten. Während des Entwicklungszyklus von Ubuntu 22.04 LTS erwarten wir einige der neuesten GNU/Linux-Technologien und Open-Source-Software, angefangen mit dem Übergang zu OpenSSL 3.0, Go 1.18, Ruby 3.0, DPDK 21.11 und OpenLDAP 2.6.

Der neue Installer wird voraussichtlich Googles Flutter SDK verwenden. Beim Desktop können wir GNOME 42 erwarten, der am 23. März 2022 veröffentlicht werden soll, sowie den Linux 5.17 Kernel, der Anfang März erscheinen sollte.

Quelle: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2021-October/001302.html